(58)【調査した分野】(Int.Cl.,DB名)
前記送信するステップは、前記少なくとも1つの要求における前記コンテキスト機能に関連する少なくとも1つのサービス・パラメータを決定するステップを含む、請求項1に記載の方法。
前記方法は、前記コンテキスト機能に関連する前記少なくとも1つのサービス・パラメータに基づいて、前記複数のターゲット端末(106)に削除要求指示を送信するステップをさらに含む、請求項2に記載の方法。
前記送信モジュール(124)は、前記サービスが提供されるセルで前記要求をブロードキャストするようにさらに構成される、請求項7に記載の対話システム(102)。
前記送信モジュール(124)は、前記サービス領域において前記要求をブロードキャストするために、ブロードキャスト・センター(110)に前記要求を送信するようにさらに構成される、請求項6乃至8のいずれか1項に記載の対話システム(102)。
前記送信モジュール(124)は、前記サービス・パラメータに基づいて、前記複数のターゲット端末(106)に削除要求指示をブロードキャストするようにさらに構成される、請求項6乃至9のいずれか1項に記載の対話システム(102)。
それぞれ前記ブロードキャストおよび前記送信の前に、前記要求のコンテンツおよび前記少なくとも1つの要求応答を検証するように構成された解析モジュール(122)をさらに含む、請求項6乃至10のいずれか1項に記載の対話システム(102)。
前記少なくとも1つの要求をブロードキャストするステップは、前記少なくとも1つの要求にタグを付けるステップを含み、前記タグは、前記少なくとも1つの要求の信頼性を示す、請求項12に記載のコンピュータ可読媒体。
【発明を実施するための形態】
【0011】
従来、ユーザとの対話は、ソーシャル・ネットワーキング・ポータルおよびアプリケーションを通じて達成され、ユーザは、ポータルにサービスを提供するネットワークを通じて互いに通信することができる。ユーザの識別情報は通常、ポータルのアクセスがユーザに提供される前に認証される。そのようなわずかなポータルにおいて、また、他のユーザにメッセージを送信し、他のユーザのアカウント情報にアクセスするなど、特定の活動がユーザの認証に基づいて可能になる。
【0012】
さらに、従来のソーシャル・ネットワーキング・アプリケーションのほとんどは、場所ベースのサービスで動作せず、たとえばソーシャル・ネットワーキング・ポータルを通じて関連するユーザなど、選択されたユーザのグループにユーザが彼または彼女の場所を開示することが可能になる。次に、ユーザは、また、選択されたグループから他のユーザの場所に関する情報を要求することができる。ユーザ間のそのような対話の間に、対話に関与するすべてのユーザの識別情報は互いに開示され、これはセキュリティ問題につながる可能性がある。たとえば、悪意のあるユーザ、たとえばストーカーまたは泥棒犯は、偽のアカウントを使って別のユーザと関連させることができ、そのユーザの所在を追跡することができる。さらに、特定の従来のソーシャル・ネットワーキング・アプリケーションでは、さまざまな閉じたグループのユーザ間で交換された情報は、閉じたグループのユーザに関連するかどうかに関係なく、アプリケーションの他のすべてのユーザに見える状態にある。そのような、すべてのユーザが情報を見ることができる状態は、特定のユーザにとってプライバシー問題を引き起こす可能性がある。
【0013】
さらに、従来のソーシャル・ネットワーキング・アプリケーションでは、ユーザ・アカウントは、認証されたアクセスが不正操作される可能性があるため、ハッカー攻撃などの攻撃を受けやすい。さらに、ソーシャル・ネットワーキング・アプリケーションの他のユーザに接続されるために、たとえば、サーバにユーザの場所の更新を提供するために、大量のデータがソーシャル・ネットワーキング・アプリケーションによってサーバと絶えず交換される。いつでもユーザがアプリケーションにアクセスするために、大量のデータが交換され、ユーザには膨大なデータ利用コストが生じる。他方では、毎回、アプリケーションにログオンするために認証の詳細を提供することは、ユーザにとって不都合である。さらに、サーバで更新されるユーザに関連するデータは、たとえば悪意のあるユーザによってアクセスすることができ、セキュリティおよびプライバシーの問題につながる可能性がある。
【0014】
本発明は、通信ネットワークにおけるリアルタイム対話に関する。一態様によると、要求元の端末は、通信ネットワークを通じて対話システムに要求を送信することができる。対話システムは、次に、対話システムに関連する複数のターゲット端末に要求を送信し、要求に対する応答を促すことができる。ターゲット端末から受信される、要求応答とも呼ばれる応答は、対話システムによって照合され、要求元の端末にプッシュされる。
【0015】
一態様では、要求元の端末によって対話システムに送信された要求は、リアルタイムに応答が求められる質問である。たとえば、要求元の端末は、ある地点から他の地点への経路を見つける際に、または特定の時間帯に特定の映画館で映画のチケットが入手可能かどうかを認識するために支援を求めることができる。さらに、一態様によると、要求元の端末によって送信された要求に基づいて、対話システムは、要求に関連するコンテキスト機能を決定することができる。一態様では、コンテキスト機能は、要求を送信する間に、要求元の端末による要求と関連させることができる。他の態様では、要求は、コンテキスト機能が欠けている場合があり、対話システムは、要求元の端末から、または以前の対話に基づいて、コンテキスト機能を取得することができる。一実施例では、コンテキスト機能は、映画館の場所でもよい。他の実施例では、コンテキスト機能は、加えて、日時およびユーザ・カテゴリを含むことができる。
【0016】
さらに、一態様では、対話システムは、たとえば、要求の送信に関係する、要求に関連する1つまたは複数のサービス・パラメータを決定することができる。たとえば、サービス・パラメータは、サービス領域と呼ばれる、コンテキスト機能で指定される場所の近辺に一連の領域を含むことができる。サービス・パラメータは、また、受信できる要求応答の数に対する制限を規定する要求応答の制限を含むことができる。さらに、サービス・パラメータは、その中において要求応答が提供されるタイムアウト・ウィンドウを含むことができる。対話システムは、コンテキスト機能が決定されるのと同じ方法でサービス・パラメータを決定できることを理解されるだろう。
【0017】
要求元の端末からの要求は、要求元の端末および対話システムを通信できるように結合するネットワークを通じて対話システムによって受信することができる。対話システムは要求を解析し、ネットワークを通じて、複数のターゲット端末に要求を転送することができる。一態様では、対話システムは、要求を解析し、要求のコンテンツを検証し、要求を送信するためのネットワークのサービスを提供されるセルを識別することができる。さらに一実施例では、コンテキスト機能で指定される場所に基づいて、対話システムは、場所があるセルにサービスを提供する無線基地局(BTS)を決定することができる。
【0018】
さらに、一態様によると、サービス・パラメータに基づいて、対話システムは、要求を送信するためのサービスを提供されるセルにおいてサービス領域を識別することができる。したがって、BTSは、複数のターゲット端末に対して、サービスを提供されるセルのそのサービス領域において要求を送信することができる。そのような状況では、サービス領域内のターゲット端末は、要求を受信することができ、領域外のターゲット端末は要求を受信しなくてもよい。さらに、一態様では、要求の送信の間に、要求元の端末の識別情報は、ターゲット端末に送信されない。
【0019】
本発明の一態様によると、対話システムは、決定されたセルにおいて要求元の端末からの要求をブロードキャストするように構成される。よって、対話システムは、サービス領域において複数のターゲット端末に単一の要求を送信する。一実施例では、対話システムは、ネットワークのブロードキャスト・センターに要求を送信し、これはさらに、BTSを通じてサービス領域において要求をブロードキャストすることができる。
【0020】
サービス領域でブロードキャストされる要求の結果として、対話システムへの要求元の端末またはターゲット端末の場所の更新は必要ではなく、そのために端末のデータ使用量がかなり減る。よって、本発明によると、第1に、場所の対話システムを更新するための端末からのデータのフローが減る。さらに、要求をブロードキャストする結果として、ブロードキャスト・メッセージは通常、無料であるため、ネットワーク・オペレータは、データのダウンロードについてターゲット端末に課金しなくてもよい。さらに、要求元の端末およびターゲット端末に関連する場所および他のパラメータは、対話システムに格納されないため、対話システムは、単純な構造を持つことができる。したがって、対話システムに関連するインフラストラクチャのコストおよび運転コストが大幅に減る。
【0021】
一態様によると、要求は、ブロードキャストされる前に、要求元の端末が属するユーザ・カテゴリのタグを付けられる。たとえば、以前の対話の間に有効な応答を提供した要求元の端末は、「信頼されるユーザ」または「特権ユーザ」として分類することができる。したがって、そのようなユーザから受信された要求は、ユーザ・カテゴリのタグを付けることができる。さまざまなターゲット端末に送信されたタグ付きの要求は、信用できるユーザによって送信されるものと識別することができ、よって、要求に応答するべきかどうかを決定するために、ターゲット端末のユーザが使用することができる。
【0022】
さらに、送信された要求がターゲット端末で受信されると、一態様では、ターゲット端末は、要求がそのターゲット端末を対象とするかどうかを識別することができる。たとえば、ターゲット端末が要求で言及された場所の外にある場合、ターゲット端末は、コンテキスト機能に基づいて、要求がこの端末を対象としていないと識別し、要求を無視および拒否することができる。
【0023】
さらに、要求を受信する対象であるターゲット端末は、要求および要求のコンテンツにアクセスすることができる。一実施例では、要求が質問を含む場合、ターゲット端末のユーザは質問に応答し、対話システムに要求応答を送信することができる。よって、対話システムは、ターゲット端末から複数の要求応答を受信することができる。対話システムは要求応答を解析し、要求応答のコンテンツの妥当性をチェックすることができる。コンテンツを検証したら、対話システムは、要求元の端末に要求応答をプッシュすることができる。一態様では、要求応答を送信するターゲット端末に、要求応答を送信するために事前定義された額のコストを課すことができる。したがって、ターゲット端末のユーザは、応答するべきかどうかを選択することができ、応答するユーザに課金することができる。他の態様では、ターゲット端末に関連する応答のコストは、要求元の端末が負担することができる。
【0024】
一態様では、要求元の端末に対する要求応答の送信は、サービス・パラメータによって管理することができる。たとえば、nが要求応答の制限、つまりサービス・パラメータで指定された送信される要求応答の数の制限である場合、対話システムは、最初のn個の有効な要求応答を要求元の端末に送信することができる。他の実施例では、サービス・パラメータで指定されたタイムアウト・ウィンドウの期限の後に、要求応答が対話システムで受信された場合、対話システムは、その要求応答を拒否するように構成することができる。後者の場合、要求応答をそのように選択的に受信することで、要求元の端末が、たとえば、タイムアウト・ウィンドウの期限の後に受信された場合は意味がないであろう、適切な応答を受信することが可能になる。たとえば、要求が、午後2:00の映画上映のためのチケットの入手可能度について情報を求めることである場合、午後2:05に受信された応答要求は意味がないであろう。
【0025】
さらに、一態様では、たとえば、タイムアウト・ウィンドウの期限が切れて要求が有効でなくなった後、または要求元の端末が適切な応答を受信した後、対話システムは、特定の要求を削除するために、サービス領域においてターゲット端末に削除要求指示を送信することができる。他の態様では、ターゲット端末は、たとえば、要求のサービス・パラメータに基づいて、要求が有効かどうかを決定することができ、要求が無効である場合、要求を削除することができる。
【0026】
さらに、一態様によると、要求にタグを付けるのと同様に、対話システムは、そのユーザ・カテゴリを用いて特定のユーザ・カテゴリに属するターゲット端末からの要求応答にタグを付けることができる。たとえば、以前の対話の間に信用できて有効な応答を提供しているターゲット端末は、「信頼されるユーザ」または「特権ユーザ」として分類することができ、そのようなユーザからの要求応答は、ユーザ・カテゴリのタグを付けることができる。その結果、そのようなタグを持つ要求応答が要求元の端末によって受信されると、情報の確実性、信頼性、および正確性をタグによって示すことができる。
【0027】
前述の態様では、対話システムは、応答するターゲット端末に関連する資格情報を送信せずに、要求元の端末に要求応答を送信することができる。すでに述べたように、要求元の端末の匿名性も維持されるため、要求元の端末とターゲット端末との間の対話は安全であり、対話の当事者の両方にプライバシーが与えられる。さらに、要求元の端末およびターゲット端末の識別情報を隠すことで、要求元の端末のユーザとターゲット端末のユーザとの間で遠慮のない対話が可能になる。さらに、前述の記述から理解されるように、要求への応答に対してターゲット端末に課金することができるが、対話システムからのブロードキャスト要求を受信することについては課金されない。よって、ターゲット端末のユーザによって生じるデータ使用のコストは、かなり減る。さらに、2つの端末のどちらのユーザもアクセスを認証する必要がなく、ターゲット端末はいつでも要求を受信し、要求に対する応答を提供することができる。そのような機能により、要求元の端末とターゲット端末との間で便利かつリアルタイムな対話が促進される。
【0028】
通信ネットワークにおいてリアルタイム対話を達成するためのシステムおよび方法が実装される方法について、図に関して詳細に説明する。任意の数の異なるコンピューティング・システム、環境、および/または構成において、通信ネットワークにおいてリアルタイム対話を達成するための記述されたシステムおよび方法の態様を実装することができるが、実施形態は、以下の代表的なシステム(複数可)の状況において記述されている。
【0029】
記述および図は、本発明の原理を示すにすぎないことを注意されたい。本明細書に明示的に記述して示していないが、本発明の原理を具体化し、その精神および範囲に含まれるさまざまな配置を当業者であれば考案できることを理解されるだろう。さらに、本明細書に詳述したすべての例は、原則として、読者が本発明の原理、およびその技術を推進する発明者(ら)によって提供された概念を理解するのを支援するために、教育のみを目的とすることを明確に意図するものであり、そのような具体的には詳述された例および条件に限定しないものとして解釈するべきである。さらに、本明細書において、本発明の原理、態様、および実施形態を詳述するすべての記述、およびその特定の例は、その等価物を包含することを意図するものである。
【0030】
本明細書で使用する、の間に(during)、間(while)、およびとき(when)という言葉は、開始動作のときに動作が即座に起こることを意味する正確な用語でなく、伝播遅延など、最初の動作と、最初の動作によって開始される反応との間に、小さいが妥当な遅延があってもよいことを当業者は理解されるだろう。さらに、「接続される(connedted)」という言葉は、記述の明瞭さのために最後まで使用されるものであり、直接接続または間接接続のいずれも含むことができる。
【0031】
図1は、本発明の実施形態による、対話システム102を実装するネットワーク環境100を示している。対話システム102は、ネットワーク環境100のリアルタイム対話を促進するように構成されている。対話システム102は、要求元の端末104、およびまとめてターゲット端末106と呼ばれ、個々にターゲット端末106と呼ばれる複数のターゲット端末106−1、106−2・・・106−Nに接続され対話する。対話システム102は、ラップトップ・コンピュータ、デスクトップ・コンピュータ、ノートブック、ワークステーション、メインフレーム・コンピュータ、サーバ、およびネットワーク・サーバなど、さまざまなコンピューティング・システムに実装することができる。要求元の端末104およびターゲット端末106は、他方では、制限なく、デスクトップ・コンピュータ、携帯端末、ラップトップまたは他の携帯用コンピュータ、タブレット型パーソナル・コンピュータ、ネットワーク・コンピュータ、モバイル電話、マルチメディア対応電話、およびスマートフォンを含むことができる。
【0032】
対話システム102、要求元の端末104、およびターゲット端末106は、通信ネットワーク108を通じて互いに通信することができる。通信ネットワーク108は、無線もしくは有線のネットワーク、またはそれらの組み合わせでもよい。一実施例では、通信ネットワーク108は、電気通信ネットワークとして実装することができる。前述の実施例では、通信ネットワーク108は、相互連結され単一の大規模なネットワーク(たとえばインターネットまたはイントラネット)として機能する個々のネットワークの集合でもよい。そのような個別のネットワークの実施例は、限定しないが、グローバル・システム・フォー・モバイル・コミュニケーション(GSM)ネットワーク、ユニバーサル移動体通信システム(UMTS:Universal Mobile Telecommunications System)ネットワーク、パーソナル通信サービス(PCS)ネットワーク、時分割多元接続(TDMA)ネットワーク、符号分割多元接続(CDMA)ネットワーク、次世代ネットワーク(NGN)、IPベースのネットワーク、公衆スイッチ電話ネットワーク(PSTN)、および統合サービス・デジタル網(ISDN)を含む。技術に依存して、通信ネットワーク108は、ゲートウェイ、ルータなどさまざまなネットワーク・エンティティを含むが、そのような詳細は、簡潔さのために省略している。
【0033】
他の実施例では、通信ネットワーク108は、電気通信ネットワークとコンピュータ・ネットワークとの組み合わせとして実装することができる。前述の実施例によると、コンピュータ・ネットワークは、イントラネット、ローカル・エリア・ネットワーク(LAN)、ワイド・エリア・ネットワーク(WAN)、およびインターネットなど、異なるタイプのネットワークの1つとして実装することができる。通信ネットワーク108は、相互に通信するために、たとえば、ハイパーテキスト転送プロトコル(HTTP)、伝送コントロール・プロトコル/インターネット・プロトコル(TCP/IP)、無線アプリケーション・プロトコル(WAP)などさまざまなプロトコルを使用する異なるタイプのネットワークの関連を表す、専用ネットワークまたは共有ネットワークでもよい。さらに、通信ネットワーク108は、ルータ、ブリッジ、サーバ、コンピューティング・デバイス、記憶装置を含む、さまざまなネットワーク・デバイスを含むことができる。さらに他の実施例では、対話システム102と、要求元の端末104と、ターゲット端末106との間の通信は、汎用パケット無線システム(GPRS)またはBluetoothを通じて部分的に達成することができる。
【0034】
さらに、本発明の一態様によると、通信ネットワーク108は、通信ネットワーク108を介して対話システム102に結合されたブロードキャスト・センター110を含むことができる。ブロードキャスト・センター110は、電気通信ネットワークのネットワーク・エンティティでもよく、ブロードキャスト・メッセージの形で情報を送信するように構成できることを理解されるだろう。前述の態様によると、ブロードキャスト・センター110は、情報をブロードキャストするために、ショート・メッセージ・サービス・セル・ブロードキャスト(SMSCB:short messaging service cell broadcast)プロトコルを使用することができる。一実施例では、ブロードキャスト・センター110は、情報をブロードキャストするように構成された、基地局制御装置(BSC)、主交換局(MSC)、無線ネットワーク制御装置、(RNC)、またはゲートウェイGPRSサポート・ノード(GGSN)として実装することができる。さらに、ブロードキャストの機能は、ブロードキャスト・センター110に関して記述しているが、対話システム102は、他の機能とともに同じ機能をサポートするように構成できることを理解されるだろう。そのような実施形態では、対話システム102は、通信ネットワーク108のネットワーク・エンティティに構成することができ、または逆もまた同様である。
【0035】
一態様では、対話システム102は、メモリ114に結合されたプロセッサ(複数可)112を含む。対話システム102は、たとえば、要求元の端末104およびターゲット端末106との通信を促進するためのインターフェース(複数可)116をさらに含む。インターフェース(複数可)116は、たとえば、キーボード、マウス、外部メモリ、およびプリンタなど周辺機器のためのインターフェースなど、さまざまなソフトウェアおよびハードウェアのインターフェースを含むことができる。さらに、インターフェース(複数可)116により、対話システム102が、ウェブ・サーバおよび外部レポジトリなど、他のデバイスと通信することが可能になる。インターフェース(複数可)116は、また、たとえばLAN、ケーブルなどの有線ネットワーク、および、WLAN、セル方式電話、または衛星などのワイヤレス・ネットワークを含む、多種多様なネットワークおよびプロトコル・タイプ内で複数の通信を促進することができる。この目的のために、インターフェース(複数可)116は、1つまたは複数のポートを含むことができる。
【0036】
プロセッサ(複数可)112は、1つまたは複数のマイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、デジタル信号プロセッサ、中央制御装置、ステート・マシン、論理回路および/または運用命令に基づいて信号を操作する任意のデバイスとして実装することができる。他の機能の中で、プロセッサ(複数可)112は、メモリ114に格納されたコンピュータ可読命令を取り込み実行するように構成される。
【0037】
メモリ114は、たとえば、静的ランダム・アクセス・メモリ(SRAM)および動的ランダム・アクセス・メモリ(DRAM)などの揮発性メモリ、ならびに/または読み取り専用メモリ(ROM)、消去可能なプログラマブルROM、フラッシュ・メモリ、ハードディスク、光ディスク、および磁気テープなどの不揮発性メモリなどを含む当技術分野で既知の任意のコンピュータ可読媒体を含むことができる。さらに、メモリ114は、モジュール(複数可)118およびデータ120を含む。
【0038】
モジュール(複数可)118は、たとえば、解析モジュール122、送信モジュール124、分析エンジン126、および他のモジュール(複数可)128を含む。他のモジュール(複数可)128は、対話システム102によって実行されるアプリケーションまたは機能を補足するプログラムまたは暗号化された指示を含むことができる。
【0039】
データ120は、要求データ130、検証データ132、および他のデータ134を含むことができる。他のデータ134は、中でも、モジュール(複数可)118の1つまたは複数のモジュールの実行の結果として処理、受信、または生成されるデータを格納するためのレポジトリとして機能することができる。データ120は、対話システム102の内部に示されているが、データ120は、対話システム102に結合できる外部レポジトリ(図示せず)に存在できることを理解することができる。対話システム102は、データ120から情報を取得するために、インターフェース(複数可)116を通じて外部レポジトリと通信することができる。
【0040】
動作時、すでに述べたように、対話システム102は、要求元の端末104と1つまたは複数のターゲット端末106との間のリアルタイム対話を促進するように構成される。一態様によると、対話システム102は、要求元の端末104から1つまたは複数の要求を受信する。対話システム102は、サービス領域において要求を送信し、これをターゲット端末106によって受信することができる。サービス領域は、後に説明するように、各要求に基づいて、要求を送信するために対話システム102によって識別された領域として理解することができる。次に、1つまたは複数のターゲット端末106はそれぞれ、対話システム102に要求応答を送信することができる。対話システム102は要求応答を解析し、それに応じて、要求元の端末104にそれを転送することができる。
【0041】
対話システム102の動作、ならびに要求元の端末104、ターゲット端末106、およびブロードキャスト・センター110との対話について、
図1、
図1Aおよび
図1Bに関して説明する。
図1Aは、主題の態様によるリアルタイム対話を示す情報の流れ図を示し、ブロードキャスト・センター110は、対話システム102とは別に展開する。他方では、
図1Bは、主題の他の態様によるリアルタイム対話を示す情報の流れ図を示し、ブロードキャスト・センター110の機能は、対話システム102に実装されている。
【0042】
要求元の端末104から対話システム102に対する要求の送信は、
図1Aおよび
図1Bのステップ136およびステップ138にそれぞれ示している。一態様では、対話システム102に送信された要求は、要求元の端末104がリアルタイムに応答を求める質問を含むことができる。たとえば、要求元の端末104は、特定の時間に特定のレストランでスペースを利用可能かどうか、または特定の映画のチケットを映画館の特定の上映について入手可能かどうかを識別する際に支援を求めることができる。一実施例では、要求元の端末104は、ハイパーテキスト転送プロトコル(HTTP)要求、簡易オブジェクト・アクセス・プロトコル(SOAP)要求、簡易メール転送プロトコル(SMTP)要求の形で、またはショート・メッセージ・サービス(SMS)要求の形で、通信ネットワーク108を通じて対話システム102に要求を送信することができる。したがって、一実施例では、対話システム102に対する要求の送信に関連する料金は、要求の形式に基づいて決定することができ、そのような料金は、要求元の端末104に課すことができる。
【0043】
一態様によると、要求は、コンテキスト機能を含むことができる。コンテキスト機能は、一実施例では、名前から分かるように、要求のコンテキストを設定することができる。たとえば、コンテキスト機能は、要求元の端末104が情報を求めている映画館またはレストランの場所でもよい。他の実施例では、コンテキスト機能は、どの要求のコンテキストを設定できるかに基づいて、日付、時間、選択されたユーザ・カテゴリ、および興味でもよい。理解されるように、前述の態様によると、要求元の端末104は、要求とともにコンテキスト機能を送信することができ、分析エンジン126は、要求からコンテキスト機能を決定することができる。
【0044】
他の態様では、対話システム102は、要求に関連するコンテキスト機能を取得することができる。一実施例では、分析エンジン126は、受信された要求についてコンテキスト機能を提供するように、要求元の端末104に促すように構成することができる。他の実施例では、分析エンジン126は、対話システム102と要求元の端末104との間の以前の対話に基づいて、要求に関連するコンテキスト機能を自動的に決定するように構成することができる。前述の実施例では、分析エンジン126は、要求元の端末104とともに識別されたコンテキスト機能をさらに検証することができる。
【0045】
さらに、一態様では、要求に基づいて、1つまたは複数のサービス・パラメータも決定することができる。コンテキスト機能に関して説明したように、サービス・パラメータは、要求を送信する前に、要求元の端末104によって要求に関連させることも、またはコンテキスト機能に関して説明した方法で、対話システム102の分析エンジン126によって決定することもできることを理解されるだろう。サービス・パラメータは、一実施例では、サービス領域における対話システム102からの要求の送信、および要求元の端末104への要求の返信に関係する場合がある。前述の実施例によると、サービス・パラメータは、サービス領域、要求応答の制限、またはタイムアウト・ウィンドウを含むことができる。前述の実施例では、サービス領域は、コンテキスト機能で指定された場所の近辺にある一連の領域として理解することができる。要求応答の制限は、要求に応じて要求元の端末104によって受信できる要求応答の数の制限として理解することができる。タイムアウト・ウィンドウは、要求が発行されてからの時間として理解することができ、要求応答をその時間内に受信しなければならない。
【0046】
一態様によると、要求元の端末104からの要求を受信すると、対話システム102の解析モジュール122は、要求を解析することができる。一実施例では、解析モジュール122は、要求のコンテンツ、および要求のコンテンツの構文を検証することができる。さらに、要求は、さまざまな検証ルールおよび検証データ132のデータに基づいて、解析モジュール122によって解析することができる。さらに、解析モジュール122によって達成された解析に基づいて、分析エンジン126は、要求に関連するコンテキスト機能、および要求のサービス・パラメータを決定することができる。分析エンジン126は、要求データ130に、要求、関連するコンテキスト機能、およびサービス・パラメータを格納することができる。本発明の他の態様では、要求元の端末104は、コンテキスト機能とともに要求を対話システム102に送信することができ、分析エンジン126は、コンテキスト機能に関係する質問を要求元の端末104に提供することができる。
【0047】
他の態様によると、要求を受信すると、分析エンジン126は、たとえば要求元の端末104にサービスを提供するBTSに基づいて、要求元の端末104の場所を決定することができる。前述の態様では、要求元の端末104が、要求がブロードキャストされることになっているサービス領域内に位置すると分析エンジン126が決定する場合、分析エンジン126は、要求元の端末104に特定の排他的な機能を提供することができる。たとえば、そのようなシナリオでは、要求元の端末104に、無料で要求を送り要求応答を受信することを許可することができる。
【0048】
さらに、対話システム102は、サービス・パラメータに基づいて要求をブロードキャストすることができる。たとえば、対話システム102の分析エンジン126は、サービス・パラメータに基づいて、要求がブロードキャストされる要求に関連するサービス領域を識別することができる。前述の実施例では、送信モジュール124は、サービス領域があるサービスが提供されるセルを識別し、それに応じて、メッセージをブロードキャストするために無線基地局(BTS)を選択することができる。一態様では、送信モジュール124は、送信のために要求を転送する前に、ユーザ・カテゴリを用いて要求にタグを付けるように構成することができる。前述の態様では、送信モジュール124は、「特権ユーザ」など、ユーザ・カテゴリを用いて要求にタグを付けることができる。要求に関連するタグは、要求に関連する信頼性を示すことができる。
【0049】
たとえば、映画が終わった後、映画館の所有者は、ユーザから映画および劇場のサービスに関するフィードバックを要求することができる。そのような要求に、たとえば「劇場管理」などのタグが付けられている場合、観客は、それに応答したいかどうかを決定することができる。この実施例では、要求のタグ付けには、申し出を付けることができるため、劇場の所有者は、そこからそのような要求に対する応答が受信されたユーザに、特別な申し出および報酬を提供することができる。他の実施例では、企業団体で重役会議の結論の後に、団体の経営陣から得られた回答が役に立ったかどうかを決定するためにブロードキャストを行うことができる。前述の実施例では、要求に「経営陣フィードバック」というタグを付けることができ、経営陣によって提供された回答に対する評価を要求することができる。
【0050】
その結果、さまざまなユーザ間のリアルタイム対話を達成することができ、そのようなシナリオにおける要求のタグ付けは、要求に応答するべきかどうかに関して決定する際にユーザを支援することができる。たとえば、要求は、要求が以前の対話の間に有効かつ正確な応答を提供したユーザから来ているということを表す「信頼されるユーザ」とタグを付けることができる。そのような場合は、要求は、以前の対話の間に役に立った「信頼されるユーザ」から来ているため、要求を提出されるユーザは、応答する傾向が高くなる可能性がある。
【0051】
要求にタグが付けられると、一態様では、対話システム102は、ブロードキャスト・センター110に要求をプッシュすることができ、これはメッセージをブロードキャストするためにBTSとさらに通信する。前述の態様は、
図1Aのステップ140に示している。他の態様では、
図1Bに示すように、対話システム102は、ステップ144で示すようにサービスが提供されるセルにサービスを提供するBTSを通じてサービス領域において要求を直接的にブロードキャストすることができる。
【0052】
サービス領域においてメッセージをブロードキャストするときに、それぞれ
図1Aおよび
図1Bのステップ142および144に示すように、要求は、サービス領域におけるすべてのターゲット端末によって受信される。ブロードキャスト要求は、異なる場合に異なるターゲット端末106−1、106−2、および106−3に到達するように示されているが、要求はターゲット端末106−1、106−2、および106−3に同時に到達できることを理解されるだろう。要求がターゲット端末106−1、106−2、および106−3にブロードキャストされた結果として、対話を達成するために、要求元の端末104または対話システム102上のターゲット端末106−1、106−2、および106−3の場所の更新は必要ない。その結果、端末のデータ使用量をかなり減らすことができる。さらに、対話システム102は、大量のデータを処理および格納する必要がないため、対話システム102は、単純な構造を持つものとして実装することができる。したがって、対話システム102に関連するインフラストラクチャ・コストおよび運転コストが実質的に減る。
【0053】
一態様では、ターゲット端末106−1、106−2、および106−3のそれぞれで要求が受信されると、各ターゲット端末106は、そのターゲット端末106がメッセージの意図する受信者かどうかを識別することができる。前述の態様では、ターゲット端末106は、コンテキスト機能もしくはサービス・パラメータまたは両方に基づいて、意図する受信者かどうか、自身を識別することができる。たとえば、メッセージがブロードキャストされたサービス領域外にターゲット端末106がいる場合、ターゲット端末106は、要求を拒否することができる。他方では、要求がそのターゲット端末106を対象としているとターゲット端末106が判断した場合、ターゲット端末は要求を受け入れて、ターゲット端末106に関連するグラフィカル・ユーザ・インターフェース(GUI)でユーザに要求を提供することができる。
【0054】
ターゲット端末から情報を要求することに加えて、一態様では、要求元の端末104またはサード・パーティー・ユーザは、ターゲット端末106−1、106−2、および106−3がデータのダウンロードに対して支払いする必要なく、広告に対する要求を使用することができる。一実施例では、サード・パーティーが広告に対する要求を使用している場合、対話システム102は、データ使用に対する料金をサード・パーティーに課すように構成することができる。よって、対話システム102は、また、広告を促進することができ、ターゲット端末106、またはターゲットの受け手は、不必要な経費が軽減される。
【0055】
要求がターゲット端末106−1、106−2、および106−3へブロードキャストされるため、端末104および106の場所を用いてサーバを更新するための要求元の端末104、ならびにターゲット端末106−1、106−2、および106−3からのデータ・フローは、かなり減る。他方では、要求はサービス領域でブロードキャストされるため、ターゲット端末106−1、106−2、および106−3はデータ・ダウンロードについて課金されない。その理由は、メッセージの受信は、ネットワーク・オペレータによって無料で提供されるためである。
【0056】
さらに、ターゲット端末106−1、106−2、および106−3の1つまたは複数は、対話システム102に要求応答を提供することができる。要求応答は、一実施例では、要求において要求元の端末104によって通知された質問に対する回答である場合がある。
図1Aのステップ146および
図1Bのステップ148に示すように、一実施例として、ターゲット端末106−2は、対話システム102に要求応答を提供する。要求に関して説明したのと同じ方法で、要求応答は、ハイパーテキスト転送プロトコル(HTTP)応答、簡易オブジェクト・アクセス・プロトコル(SOAP)応答、簡易メール転送プロトコル(SMTP)応答の形で、またはショート・メッセージ・サービス(SMS)応答の形で、対話システム102に提供することができる。さらに、要求に応答するターゲット端末106−2に課される料金は、応答の形式に基づいて決定することができる。他の実施例では、要求に応答するための料金は、情報を求める要求元の端末104に課すことができる。
【0057】
対話システム102で要求応答を受信すると、
図1Aのステップ146および
図1Bのステップ148として示すように、解析モジュール122は、たとえば、要求応答のコンテンツおよび構文をチェックするために、要求応答を解析することができる、さらに、一態様によると、解析モジュール122は、要求データ130に以前に格納された、サービス・パラメータに対して要求応答を検証することができる。たとえば、nがサービス・パラメータの一部として分析エンジン126によって決定された応答要求の制限である場合、解析モジュール122は、受信された要求応答が応答要求の制限内にあるかどうかをチェックすることができる。要求応答が(n+1)番目または後の要求応答である場合、解析モジュール122は、要求応答を拒否することができる。他の実施例では、タイムアウト・ウィンドウの期限の後に、要求応答が対話システム102によって受信された場合、解析モジュール122は、要求応答を拒否することができる。
【0058】
他方では、要求応答はサービス・パラメータに関して有効であることを解析モジュール122が決定した場合、たとえば、要求応答が、タイムアウト・ウィンドウの期限の前に受信された、または対話システム102によって受信された最初のn個の要求応答の1つである場合、要求応答は、要求元の端末104に送信される。
【0059】
たとえば、サービス・パラメータに対して、解析モジュール122によって行われた妥当性チェックの結果として、対話システム102は、要求に関連する要求応答を受信および維持し、他の応答要求を拒否する。たとえば、要求が特定の映画の上映のためのチケットの入手可能度に関する情報を取得するためのものである場合、そのような情報を持ち、その映画の上映の開始後に受信された要求応答は、要求元の端末104には関係がない。よって、対話システム102により、要求元の端末104とターゲット端末106との間のリアルタイム対話が促進され、これは要求元の端末104のユーザにとって有益である。
【0060】
一態様によると、要求応答が有効かどうかを決定するときに、送信モジュール124は、適切なターゲット端末106に応答承認を送信することができる。これはこの場合、ターゲット端末106−2である。対話システム102の送信モジュール124からターゲット端末106−2への応答承認の送信は、
図1Aのステップ154、および
図1Bのステップ156に示されている。他の態様(図示せず)では、承認応答は、要求元の端末104によって要求応答を受信するときに、適切なターゲット端末106に送信することができる。一態様では、送信モジュール124は、各ターゲット端末106からの無効な要求応答が受信された場合、そのような各ターゲット端末106に応答拒否承認を送信するように構成できることを理解されるだろう。
【0061】
すでに述べたように、応答要求が有効であると判断された場合、送信モジュール124は、要求元の端末104に応答要求を送信することができる。対話システム102から要求元の端末104への応答要求の送信は、
図1Aのステップ150および
図1Bのステップ152に描写している。前述の態様では、送信モジュール124は、応答要求が受信されたときに、要求元の端末104に応答要求を提供するが、他の態様では、送信モジュール124は、受信されたさまざまな応答を照合し、タイムアウト・ウィンドウの期限の後に応答要求をまとめて送信することができる。
【0062】
本発明の一態様によると、要求元の端末104に要求応答をプッシュする前に、送信モジュール124は、そこから要求応答が受信されるターゲット端末106−2に基づいて、ユーザ・カテゴリを用いて要求応答にタグを付けることができる。一実施例では、各要求応答に関連するタグは、その要求応答の正確性または信頼性を示すことができる。よって、要求応答に関連するユーザ・カテゴリのタグに基づいて、要求元の端末104は、要求応答が正確もしくは信用できるか、またはそうでないかを判断することができる。特定のユーザ・カテゴリに関連されるターゲット端末106を識別する目的で、分析エンジン126は、また、要求元の端末104から要求応答についてのフィードバックを促すことができる。
【0063】
たとえば、以前のトランザクションの間に、そこから主に有効な応答が受信されており、要求元の端末104から好意的なフィードバックが受信されているターゲット端末106は、「信頼されるユーザ」という名前のユーザ・カテゴリに属するものとして印を付けることができる。前述の実施例では、要求元の端末104が信頼されるユーザから受信されたとしてタグが付けられた要求応答を受信する場合、要求元の端末104のユーザは、要求応答の情報が信用できると見なすことができる。さらに、対話システム102は、要求元の端末104に応答要求を転送している間、ターゲット端末106から応答要求が受信され、そのターゲット端末106の識別情報を隠すことができる。その結果、対話システム102によって達成される対話は、要求元の端末104およびターゲット端末106のさまざまなユーザに、プライバシーだけでなくセキュリティも提供する。
【0064】
これとは反対に、特定の他のカテゴリに属するものとしてタグを付けられた要求応答は、要求元の端末104のユーザによって無視することができるか、またはより小さい重みを持つことができる。要求元の端末104が、「映画Xは面白いですか?」という質問に対する回答を求める要求を映画館から出て来るターゲット端末106のユーザのグループに送信する実施例について考える。そのような場合は、信頼されるユーザからの応答は、実質的に正確であると見なすことができる。他方では、応答要求に関連する、たとえば「劇場管理」というユーザ・カテゴリが、応答は映画館の所有者のカテゴリに属するユーザからである可能性があることを示している場合、要求元の端末104のユーザは、そのような要求応答を話半分で考えることができる。
【0065】
さらに、一態様によると、送信モジュール124は、サービス・パラメータを監視するように構成することができ、サービス・パラメータに基づいて、送信モジュール124は、削除要求指示を自動的に生成し、要求が以前にブロードキャストされたサービス領域において、削除要求指示をブロードキャストすることができる。削除要求指示を受信すると、ターゲット端末106は、対話システム102から受信された要求を削除することができる。他の態様では、ターゲット端末106は、タイムアウト・ウィンドウなどのサービス・パラメータに基づいて、要求の妥当性を決定するように構成することができる。さらに、要求の妥当性に基づいて、ターゲット端末106は、要求を削除することができる。そのような場合は、送信モジュール124は、削除要求指示を生成および送信する必要がない場合がある。
【0066】
たとえば、送信モジュール124は、応答を受信するためのタイムアウト・ウィンドウの期限が切れているかどうかを監視することができ、タイムアウト・ウィンドウの期限が切れると、送信モジュール124は、削除要求指示を送信することができる。他の実施例では、送信モジュール124は、対話システム102によってn個の有効な要求応答が受信されたかどうかを監視することができ、n番目の有効な要求応答を受信すると、送信モジュール124は、削除要求指示をブロードキャストすることができる。さらに他の実施例では、要求元の端末104のユーザは、要求応答をそれ以上送信しないように対話システム102に指示するために、停止応答入力を発行し、対話システム102にそれを送信することができる。前述の実施例では、要求元の端末104は、必要な情報をすでに受信している場合があり、要求応答をそれ以上必要としない場合がある。そのような状況では、要求元の端末104が停止応答要求を発行した場合、送信モジュール124は、削除要求指示をブロードキャストすることができる。要求のブロードキャストに関して以前に説明したように、削除要求指示は、
図1Aのステップ158および160に示すように、ブロードキャスト・センター110によって、または
図1Bのステップ162に示すように、対話システム102によって、ブロードキャストできることを理解されるだろう。
【0067】
図2は、本発明の実施形態による、通信ネットワークにおけるリアルタイム対話のための方法200を示している。方法200が記述されている順は、制限するものとして解釈されることを意図するものではなく、任意の数の上記方法のブロックを、方法200または代替の方法を実装するために任意の順に組み合わせることができる。さらに、個々のブロックは、本明細書に記述した内容の精神および範囲から逸脱することなく、方法から削除することができる。さらに、方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせに実装することができる。
【0068】
当業者は、プログラムされたコンピュータによって方法200のステップを実行できることを容易に認識するだろう。本明細書において、一部の実施形態は、また、機械またはコンピュータで読み取り可能であり、装置で実行可能またはコンピュータで実行可能なプログラム命令を暗号化する、たとえば、デジタル・データ記憶メディアなど、プログラム記憶装置を包含することを意図するものであり、前述の命令は、記述した方法のステップの一部またはすべてを実行する。プログラム記憶装置は、たとえば、デジタル・メモリ、磁気ディスクや磁気テープなどの磁気記憶メディア、ハード・ドライブ、または光学的に読み取り可能なデジタル・データ記憶メディアなどでもよい。実施形態は、また、方法200の前述のステップを実行するように構成された通信ネットワークおよび通信デバイスの両方を対象にすることを意図するものである。
【0069】
ブロック202を参照すると、要求は、要求元の端末104など、要求元の端末から受信される。要求は、対話システム102によって受信することができる。
【0070】
一態様によると、要求元の端末104で要求を受信すると、要求は、要求が有効かどうかを検証するために解析される。たとえば、要求は、検証データ132に基づいて、解析モジュール122によって解析される。一態様では、要求は、要求のコンテンツもしくは構文、または両方が有効かどうかを検証するために解析することができる。コンテンツが無効だった場合、たとえば、要求が偽の要求であり、乱暴な言葉を含む場合、または要求の構文が正しくない場合、要求は拒否される。
【0071】
他方では、要求が有効な場合、ブロック204で、要求に関連するコンテキスト機能が決定される。一態様では、要求元の端末104は、対話システム102に要求を送信している間に、要求にコンテキスト機能を関連させることができる。そのような場合は、一実施例では、分析エンジン126は、要求に関連するコンテキスト機能を決定することができる。他の態様では、要求元の端末104は、対話システム102に要求を送信することができ、たとえば、コンテキスト機能を提供するために要求元の端末に指示メッセージを送信することによって、またはその要求元の端末104との以前の対話に基づいて、分析エンジン126は、その要求元の端末104から要求に関連するコンテキスト機能を決定することができる。
【0072】
一態様では、要求は、リアルタイムに要求元の端末104によって回答が求められる質問の場合がある。たとえば、要求は、映画の後に映画館から出て来る人々によって、リアルタイムに特定の映画館で上映されている映画についてのフィードバックを取得する質問、または劇場で上演されている特定の演劇のチケットを入手できるかどうかに関してリアルタイムに尋ねる質問を含むことができる。前述の態様では、要求は、要求にコンテキストを提供できるコンテキスト機能を含むことができる。たとえば、コンテキスト機能は、劇場もしくは映画館の場所、または情報が求められる映画または演劇の日付もしくは時間または両方の場合がある。
【0073】
ブロック206で、要求におけるコンテキスト機能に関連する1つまたは複数のサービス・パラメータが決定される。一態様では、サービス・パラメータは、サービス領域、応答要求の制限、またはタイムアウト・ウィンドウを含むことができる。サービス領域は、要求元の端末104が要求を送信する意図がある可能性がある、ネットワーク・オペレータによってサービスが提供されるセル領域の場合がある。応答要求の制限は、要求元の端末104が受信する意図がある可能性がある要求に対する応答の数に対する制限の可能性がある。タイムアウト・ウィンドウは、要求元の端末104が要求に対する応答を受信する意図がある可能性がある時間制限を指定することができる。たとえば、要求元の端末のユーザが特定の上映の映画チケットの入手可能度に関する情報を求めている場合、映画上映の開始後に受信された応答は、関係がないものと理解することができる。さらに、コンテキスト機能に関連するサービス・パラメータは、上記のパラメータまたはそれらの組み合わせの1つの場合があることを理解されるだろう。一実施例では、分析エンジン126は、サービス・パラメータを決定することができる。
【0074】
さらに、ブロック208で、コンテキスト機能に基づいて、要求をブロードキャストするためにサービスが提供されるセルが識別される。一実施例では、分析エンジン126は、コンテキスト機能で指定された場所を識別することができ、場所に基づいて、分析エンジン126は、要求をブロードキャストするためにサービスが提供されるセルを識別することができる。
【0075】
一態様では、要求は、ブロードキャストされる前に、ユーザ・カテゴリのタグを付けることができる。一実施例では、要求に関連するタグに基づいて、受信者のターゲット端末106は、要求の信頼性を決定することができる。要求には、たとえば、「信頼されるユーザ」または「特権ユーザ」などのタグを付けて、要求は、以前の要求に積極的に応答しており、有効かつ有益な情報を提供しているユーザから来ていることを示すことができる。そのような場合は、ターゲット端末106は、要求元の端末104のユーザが属するユーザ・カテゴリに基づいて、要求に応答するべきかどうかを決定することができる。
【0076】
ブロック210で、要求は、サービスが提供されるセルのサービス領域でブロードキャストされる。サービス領域は、サービス・パラメータに基づいて識別することができる。一実施例では、分析エンジン126は、サービスが提供されるセルのサービス領域を決定することができ、送信モジュール124は、サービス領域において要求をブロードキャストすることができる。一態様によると、送信モジュール124は、要求がブロードキャストされるサービス領域の情報とともに、ブロードキャスト・センター110に要求を送信することができる。ブロードキャスト・センター110は、たとえば、サービス領域で動作する無線基地局(BTS)を介して、要求をさらにブロードキャストすることができる。他の態様では、対話システム102は、たとえばBTSを介して、サービス領域において要求を直接的にブロードキャストすることができる。
【0077】
サービス領域において要求をブロードキャストするときに、単一の要求がサービス領域において複数のターゲット端末106に送信される。一態様では、要求を受信するターゲット端末106のそれぞれは、コンテキスト機能もしくはサービス・パラメータまたは両方に基づいて、そのターゲット端末106が要求の意図する受信者か、または要求が誤って受信されたかを判断する。後者の場合、要求は、ターゲット端末106によって拒否される。他方では、前者の場合、要求は承認され、ユーザは、要求で求められた情報に関して、要求に対する適切な応答を提供することができる。
【0078】
要求に応じて、ブロック212で、1つまたは複数の要求応答が、1つまたは複数のターゲット端末106から受信される。一態様では、要求応答は、要求で通知された質問に対する回答を含むことができる。一実施例によると、要求応答は、対話システム102によって受信される。
【0079】
ブロック214で、要求応答のそれぞれは、要求応答の妥当性を検証するために解析される。実施例では、解析モジュール122は、要求応答を解析し、各要求応答のコンテンツが有効かどうかを検証することができる。前述の実施例では、解析モジュール122は、乱暴な言語を含む、または誤った構文を持つ要求応答が拒否されることを保証することができる。
【0080】
さらに、要求応答のそれぞれは、要求のサービス・パラメータに対して妥当性がチェックされる。ブロック216で、要求に関連するタイムアウト・ウィンドウの期限が切れたかどうかが判断される。一実施例では、送信モジュール124は、ブロック216でタイムアウト・ウィンドウの期限の状態を評価するように構成される。タイムアウト・ウィンドウの期限が切れている場合(ブロック216から「はい」の経路)、ブロック218で、サービス領域で削除要求指示がブロードキャストされる。削除要求指示は、要求がもう有効ではないこと、および今後受信される要求応答は関係がないだろうことを、サービス領域においてターゲット端末106に通知するために発行された指示として理解することができる。
【0081】
他方では、タイムアウト・ウィンドウの期限が切れていない場合(ブロック216から「いいえ」の経路)、ブロック220で、要求応答の制限に到達しているかどうかが判定される。たとえば、サービス・パラメータで指定された要求応答の制限がnである場合、n番目の要求応答を受信すると、要求応答の制限に到達したというフラグが付けられる。要求応答の制限に到達した場合(ブロック220から「はい」の経路)、削除要求指示は、ブロック218で、サービス領域でブロードキャストされる。
【0082】
反対に、要求応答の制限に到達していない場合(ブロック220から「いいえ」の経路)、ブロック222で、停止応答入力が要求元の端末104から受信されたかどうかが判定される。一実施例では、必要な情報が以前の要求応答ですでに受信されている場合、または要求元の端末104のユーザが映画の計画を廃棄することを決定した場合、ユーザは、それ以上の要求応答を拒否するために、対話システム102に停止応答入力を送信することができる。一実施例では、分析エンジン126は、停止応答入力が受信されたかどうかを判定することができる。
【0083】
停止応答入力が受信された場合(ブロック222から「はい」の経路)、削除要求指示は、ブロック218で、サービス領域でブロードキャストされる。
【0084】
他の態様では、ターゲット端末106は、サービス・パラメータに基づいて、要求の妥当性を判定するように構成することができる。サービス・パラメータを考慮して要求が無効である場合、ターゲット端末106は、要求を削除することができる。
【0085】
他方では、停止応答入力が受信されていない場合(ブロック222から「いいえ」の経路)、ブロック224で、要求応答は、要求元の端末104に送信される。一実施例では、送信モジュール124は、要求元の端末104に要求応答を送信することができる。
【0086】
一態様によると、要求元の端末104に要求応答を送信している間、要求応答は、そこから要求応答が受信されるターゲット端末106に基づいて、ユーザ・カテゴリのタグを付けることができる。要求応答に関連するユーザ・カテゴリのタグは、要求応答の正確性または信頼性を示すことができ、それに応じて、応答要求の情報をさらに使用することができる。
【0087】
通信ネットワークのリアルタイム対話の態様について、構造的特徴および/または方法に特有の言語で記述したが、添付した請求項は、記述した特定の機能または方法に必ずしも限定されないことを理解されるだろう。むしろ、特定の機能および方法は、通信ネットワークでリアルタイム対話を達成するための態様として開示されている。