JP2009533952A

JP2009533952A - ＶｏＩＰクライアント情報

Info

Publication number: JP2009533952A
Application number: JP2009505366A
Authority: JP
Inventors: ミルスタインデビッド; ハウエルデビッド; ワンクアンサン; クリドルリンダ; ディー．マルエッグマイケル; チューロン−チャン
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2006-04-10
Filing date: 2007-03-09
Publication date: 2009-09-17
Anticipated expiration: 2027-03-09
Also published as: US20070237131A1; KR20090005321A; EP2005681A4; RU2008140139A; CN101422003B; WO2007120416A1; CN101422003A; JP5193182B2; RU2447596C2; KR101369583B1; EP2005681A1

Abstract

要求された情報を収集し且つＶｏＩＰクライアントまたは他のサービスプロバイダに提供する方法とシステムを提供する。情報照会が受信され且つ処理され、情報照会パーティ（当事者）に送信される適切なコンテキスト情報が特定される。例えば、ＶｏＩＰクライアントのロケーション情報に関する照会が受信され、ＶｏＩＰクライアントのロケーションに関連するコンテキスト情報が収集され且つ提供される。適切なコンテキスト情報が特定されると、適切なコンテキスト情報を提供するための適切なソースが割り出される。様々なパスを利用することによって、その適切なコンテキスト情報がソースから取得される。取得された適切なコンテキスト情報がＶｏＩＰクライアントに提供される。

Description

一般に説明すると、インターネット電話技術システムにおいては、従来の公衆電話交換網（ＰＳＴＮ）ベースの電話技術システムに比べて強化された呼出機能をもつ呼び出し接続を得る機会がユーザに提供されている。しばしばボイスオーバーインターネットプロトコル（ＶｏＩＰ：Voice over Internet Protocol）と呼ばれる典型的なインターネット電話技術システムでは、音声情報は、インターネットプロトコル（ＩＰ）データネットワークを利用する通信のために、パケットと呼ばれる、一連のデータブロックとなるように処理される。ＶｏＩＰ呼び出し通話の期間では、デジタル化された音声は小さなフレームの音声データに変換され、音声データパケットは、送信されて受信された音声データのフレームにＩＰヘッダを追加することによって組み立てられる。

ＶｏＩＰ技術は、通信の柔軟性及び携帯性、マルチメディア通信を確立し且つ制御する能力等の理由で、支持されてきた。ＶｏＩＰ技術は、昔からの電話技術では提供できなかった強化された呼び出し機能及び高度なサービスを提供することができるので、おそらく支持され続けるであろう。

しかしながら、現在のＶｏＩＰ手法においては、ロケーションに関連するコンテキスト情報について照会する方法、あるいはＶｏＩＰ通話を介してかかるコンテキスト情報を取得する方法が提供されていない。

発明の詳細な説明で説明されている単純化された形態でいくつかの概念を紹介するためにこの概要が与えられている。この概要により、請求項に記載された対象の重要な特徴を特定するべきでなく、また、請求項に記載された対象の範囲を決定する際に使用するべきでない。

必要とされる情報を収集し且つＶｏＩＰクライアントまたは他のサービスプロバイダに提供する方法とシステムを提供する。情報に関する照会が、受信され且つ処理され、適切なコンテキスト情報が特定され、その適切なコンテキスト情報が情報照会パーティに送信されることになる。例えば、ＶｏＩＰクライアントのロケーション情報に関する照会が受信され、ＶｏＩＰクライアントのロケーションに関連するコンテキスト情報が収集され且つ提供される。適切なコンテキスト情報を特定すると、その適切なコンテキスト情報を提供するのに適切なソースが割り出される。様々なパスを利用することによって、ソースから適切なコンテキスト情報が取得される。取得された適切なコンテキスト情報がＶｏＩＰクライアントに提供される。

本発明の１態様によると、発呼側クライアントと被発呼側クライアントとの間の通信チャネルを介して情報照会に関連するコンテキスト情報を提供する方法が提供される。被発呼側クライアントに関連する情報に関する照会が受信されてもよい、その照会を受信すると、被発呼側クライアントに関連するコンテキスト情報が取得される。被発呼側クライアントのコンテキスト情報に基づいて、照会に対応する一連の情報が特定され且つ第三機関サービスプロバイダ、被発呼側クライアント、またはサービスプロバイダのローカルストレジ（現地記憶装置）から取得される。取得された一連の情報が発呼側クライアントに提供される。

本発明の別の態様によれば、ＶｏＩＰ通信チャネルを介した照会に応じて情報を提供するコンピュータ実行可能成分を有するコンピュータ読み込み可能な媒体が提供される。コンピュータ実行可能成分は、情報に関する照会を受信する情報管理成分と、第１のクライアントのコンテキスト情報を処理し且つ情報を取得するソースを特定する情報処理成分と、を含む。情報管理成分は、ソースから照会に対応する情報を取得し、且つ取得された情報を第２のクライアントに提供する。情報処理成分は、複数のソースを特定し、且つコンテキスト情報に基づいて最も適切なソースを選択する。情報処理成分がいなかるソースも特定できない場合、情報管理成分は所定のデフォルト情報を送信する。情報処理成分は、取得された情報を追加することによって、コンテキスト情報を更新し、情報管理成分は更新後のコンテキスト情報を送信する。

本発明のさらに別の態様によると、第１のクライアントと第２のクライアントとの間の通信チャネルを介したロケーション（位置）に関連するコンテキスト情報を提供するための方法においては、第１のクライアントのロケーション情報に関する照会が受信されてもよい。第２のクライアントから受信されたコンテキスト情報の一部として情報に関する照会が受信される。コンテキスト情報は第１のクライアントと第２のクライアントとの間のＶｏＩＰ通信チャネルを介した通話に関連する。

上記の照会を受信すると、第１のクライアントに関連する一連のコンテキスト情報が取得されてもよい。ロケーション情報が一連の取得されたコンテキスト情報から入手可能であるかどうかに関して判断される。ロケーション情報が入手可能であるならば、ロケーション情報が第２のクライアントに与えられることになる。１実施形態では、第２のクライアントから受信されたコンテキスト情報に基づいて、第１のクライアントの地理的位置、第１のクライアントのデバイスのＩＰアドレス等のロケーション情報のタイプが特定される。ロケーション情報が利用できない場合、ロケーション情報を取得するための少なくとも１つのソースが、一連の取得されたコンテキスト情報に基づいて割り出されてもよく、少なくとも１つのソースからロケーション情報を取得できる。

添付図面に関連させると、本発明の前述の態様及び多くの付帯的効果は、以下の詳細な説明を参照して理解できるように、容易に認識できるであろう。

全般的に説明すると、本発明は、照会を受けた情報を収集し且つ通信チャネルを介してＶｏＩＰクライアント又は他のサービスプロバイダに提供する方法とシステムに関するものである。より具体的には、本発明は、情報照会に応じてコンテキスト情報を特定し、「構造化階層構造（structured hierarchies）」に従って表されたその特定されたコンテキスト情報を、収集し且つ提供する方法とシステムに関する。本明細書に使用される「構造化階層構造」とは、２つ以上のＶｏＩＰデバイス間で交換されるコンテキスト情報を配置するための事前に定義された組織構造である。例えば、構造化階層構造はＸＭＬネームスペースであってもよい。さらに、ＶｏＩＰ通話は、通話チャネルを介して交換されるコンテキスト情報及び音声情報等の通話に関連する情報のデータストリームである。コンテキスト情報が交換されるとき、コンテキスト情報のいかなる指定された送信パーティもコンテキスト情報の範囲、内容、または量を変えることができ、コンテキスト情報は、決定された通信チャネルパス内の次の受信パーティに伝えられる。本発明は、実例のための構造化階層構造とＩＰ電話技術環境とに関連して説明されるが、関連技術の当業者は,開示された実施形態が事実上実例のためであって、限定として解釈されるべきでないことを十分理解するであろう。

図１を参照すると、様々な「ＶｏＩＰクライアント」間のＩＰ電話サービスを提供するＩＰ電話技術環境（telephony environment; 電話環境、電話回線環境ともいう）１００のブロックダイアグラムが示されている。本明細書に用いられる「ＶｏＩＰクライアント」は個人、組織、会社等の特定のコンタクトポイントを示して、１つ以上の関連付けられたＶｏＩＰデバイス及び固有のＶｏＩＰクライアント識別子を参照する。例えば、単一の個人、関連づけられた５つのＶｏＩＰデバイス、及び固有のＶｏＩＰクライアント識別子が、１つのＶｏＩＰクライアントを集合的に構成している。同様に、５００人の個人及び関連付けられた１，０００以上のＶｏＩＰデバイスを含む会社を、まとめてＶｏＩＰクライアントと称してもよく、そのＶｏＩＰクライアントは固有のＶｏＩＰクライアント識別子によって特定される。その上、ＶｏＩＰデバイスは複数のＶｏＩＰクライアントと関連付けられてもよい。例えば、各々が別々のＶｏＩＰクライアントに関連付けられた３人の異なる個人が生活する常駐域に位置するコンピュータ（ＶｏＩＰデバイス）は、３つのＶｏＩＰクライアントの各々と関連付けられてもよい。デバイスの組合せにかかわらず、ＶｏＩＰクライアントのコンタクトポイントに達する音声システム内で固有のＶｏＩＰクライアント識別子を使用できる。

全般的に説明すると、ＩＰ電話技術環境１００はインターネットや、イントラネットネットワークや、広域ネットワーク（ＷＡＮ）や、ローカルエリアネットワーク（ＬＡＮ）等のＩＰデータネットワーク１０８を含んでもよい。ＩＰ電話技術環境１００は、ＶｏＩＰクライアント１２４，１２５，１３４に対してＶｏＩＰサービスを提供するＶｏＩＰサービスプロバイダ１２６，１３２をさらに含んでもよい。音声情報、メディア情報、及び／又はコンテキスト情報に対応するデータパケットのストリームとしてＶｏＩＰ呼び出し通話を交換できる。以下でさらに詳細に説明するように、コンテキスト情報はＶｏＩＰ通話に関連するメタデータ（情報に関する情報）を含んでおり、デバイスは、コンタクトポイント（例えば、会社の従業員）によって特定される通話、接続ＶｏＩＰクライアント、及び／又は個人のコンタクトポイントで使用される。

また、ＩＰ電話技術環境１００は第三機関ＶｏＩＰサービスプロバイダ１４０を含んでもよい。ＶｏＩＰサービスプロバイダ１２６、１３２、１４０は、入力呼出フィルター、テキストデータ、音声及びメディアデータ統合、統合データ伝送等の様々な呼出し機能をＶｏＩＰ呼び出し通話の一部として提供できる。

ＩＰ電話サービス（例えば、専用網内の内部呼び出し、専用網の外部の外部呼び出し等）及びマルチメディアデータサービスを会社のＬＡＮ１３６に接続したいくつかのＶｏＩＰクライアント１３４に与えて、ＶｏＩＰサービスプロバイダ１３２を会社のＬＡＮ１３６等の専用網と結合してもよい。同様に、ＩＳＰ１２２のクライアントに対するＩＰ電話サービスとＶｏＩＰサービスを提供して、ＶｏＩＰサービスプロバイダ１２６等のＶｏＩＰサービスプロバイダをインターネットサービスプロバイダ（ＩＳＰ：Internet Service Provider）１２２と結合してもよい。

１実施形態では、ＶｏＩＰクライアント１０４、１２４、１２５にインターネットアクセスを与えるために１つ以上のＩＳＰ１０６、１２２が構成され、ＶｏＩＰクライアント１０４、１２４、１２５がインターネット上で確立された通話チャネルを保持することができる。ＩＳＰ１０６、１２２に接続されたＶｏＩＰクライアント１０４、１２４、１２５は、有線及び／又は無線の通信回線を使用できる。さらに、ＶｏＩＰクライアント１０４、１２４、１２５、１３４の各々は通話可能となるようにＰＳＴＮ１１２に接続された旧来のアナログ電話サービス（ＰＯＴＳ）１１５を用いて通信できる。ＰＳＴＮゲートウェイ等のＰＳＴＮインタフェース１１４はＰＳＴＮとＩＰデータネットワーク１０８との間のアクセスを可能にする。ＰＳＴＮインタフェース１１４はＰＳＴＮに対する回路スイッチ型音声トラフィックにＶｏＩＰデータパケットを移すことができ、そして、逆もまた同様である。ＰＳＴＮ１１２は固定電話（landline）装置１１６、モバイル機器１１７等を含むことができる。

固定電話装置１１６などの従来の音声デバイスが、そのクライアントの固有な識別子に基づいてＶｏＩＰクライアントとの接続を要求し、ＶｏＩＰクライアントに関連付けられた適切なＶｏＩＰデバイスが、接続を確立するのに使用されるだろう。１つの実施形態では、ＶｏＩＰクライアントに関連付けられた個人は、どのデバイスがさまざまな条件に基づいて呼び出しを接続（例えば、発呼者、時刻等に基づく接続）する際に使用されるのかを指定できる。

環境１００における上記の構成は単に例示的であることを理解すべきである。様々なＶｏＩＰエンティティを有するいかなる適当な構成も環境１００の一部であってもよいことは、当業者によって十分理解されるだろう。例えば、ＬＡＮ１３６と結合されたＶｏＩＰクライアント１３４は、ＶｏＩＰサービスプロバイダ１３２又はＩＳＰ１０６、１２２のあるなしにかかわらず他のＶｏＩＰクライアント１０４、１２４、１２５、１３４を用いて通信できるだろう。さらに、ＩＳＰ１０６、１２２はクライアントに対してＶｏＩＰサービスを与えることができる。

図２について参照すると、例示的なＶｏＩＰクライアント２００を示すブロックダイアグラムが示されており、ＶｏＩＰクライアント２００は、本発明の実施形態に係るいくつかのＶｏＩＰデバイスと固有のクライアント識別子を含んでいる。ＶｏＩＰデバイス２０２、２０４、２０６の各々はストレージを含んでもよく、そのストレージは、音声メッセージ、アドレス帳、クライアント特定の規則、着呼に関連する優先順位情報等を保持するために、使用される。代わりに、又は更に、例えば、サービスプロバイダによって保持された別々のストレージが、ＶｏＩＰクライアントに関連付けられて、且つＶｏＩＰクライアントに関連する情報を含むＶｏＩＰデバイスの各々によってアクセス可能であってもよい。１実施形態では、無線電話２０２、ＩＰ電話２０４、または適切なＶｏＩＰアプリケーションを有するコンピュータ２０６等のいかなる適当なＶｏＩＰデバイスは、ＶｏＩＰクライアント２００の一部であってもよい。また、ＶｏＩＰクライアント２００は１つ以上の固有のクライアント識別子２０８を保持する。固有のクライアント識別子２０８は、一定であるか、または時間が経つにつれて、変化してもよい。例えば、固有の識別子２０８は呼び出しの各々を交換できる。固有のクライアント識別子は、クライアントを特定し且つＶｏＩＰクライアントと関連付けられたコンタクトポイント（接触点）２１０に接続するのに使用される。固有のクライアント識別子は、ＶｏＩＰクライアント内に含まれるＶｏＩＰデバイスの各々に保持され、そして／または、サービスプロバイダによって保持され、そのサービスプロバイダはＶｏＩＰクライアントに含まれるＶｏＩＰデバイスの各々と関連付けられている。固有のクライアント識別子がサービスプロバイダによって保持される例においては、サービスプロバイダは関連付けられたＶｏＩＰデバイスに関する情報及び入力通信に対して接続すべきデバイスに関する知識を含むことができる。代替実施形態では、ＶｏＩＰクライアント２００は複数のクライアント識別子を保持できる。この実施形態では、固有のクライアント識別子が、呼び出しセッションの各々に対するＶｏＩＰクライアント２００に割り当てられてもよい。

ＰＳＴＮの電話番号と同様に、固有のクライアント識別子を使用してもよい。しかしながら、ホーム電話などの特定のＰＳＴＮデバイスを鳴らすために典型的な電話番号にダイヤルすることの代わりに、固有のクライアント識別子は、ＶｏＩＰクライアントと関連付けられた個人または会社などのコンタクトポイントに到達するのに使用される。クライアントの配置に基づいて、適切なデバイスが、コンタクトポイントに到達するように接続されることになろう。１実施形態では、ＶｏＩＰクライアントに含まれるＶｏＩＰデバイスの各々は、ネットワーク内のそれ自身の物理アドレスまたは固有の装置番号を有することができる。例えば、個人がパーソナルコンピュータ（ＶｏＩＰデバイス）を使用することで電話をPOTSクライアントにする場合、パーソナルコンピュータのＩＰアドレスに関連したＶｏＩＰクライアント識別番号は、結局、ＰＳＴＮにおいて認識可能な電話番号に変換されることになろう。

図３はＶｏＩＰデバイス３００のブロックダイアグラムであり、そのＶｏＩＰデバイス３００は、１つ以上のＶｏＩＰクライアントで関連付けられており、且つ本発明の実施形態と共に使用される。ＶｏＩＰデバイス３００は実施形態として記述されていることを注意すべきである。本発明の実施形態と共に他の様々な構成要素を有するいかなる適当なデバイスも使用できることが十分理解されるであろうＶｏＩＰサービスを利用するために、ＶｏＩＰデバイス３００は様々なタイプのデータパケットを受信し、送信し、処理するのに適当な成分を含むことができる。例えば、ＶｏＩＰデバイス３００はマルチメディア入出力要素３０２とネットワークインタフェース要素３０４を含んでもよい。（オーディオ、ビデオ等を含む）マルチメディアデータ、ユーザ生体認証、テキスト、アプリケーションファイルデータ等を入力し、そして／または、出力するためにマルチメディア入出力要素３０２が構成されてもよい。マルチメディア入出力要素３０２は、マイクロホン、ビデオカメラ、ディスプレイ画面、キーボード、ユーザ生体認識デバイス等のいかなる適当なユーザ入出力要素も含んでもよい。マルチメディア入出力要素３０２は、また、ネットワークインタフェース要素３０４を介してマルチメディアデータを受信し且つ送信できる。ネットワークインタフェース要素３０４は、イーサネット（登録商標）インタフェース、フレーム・リレーインタフェース、ケーブルインタフェース、デジタル加入者回線インタフェース、トークン（優先権信号）・リングインタフェース、無線周波（エアー・インタフェース）等のインタフェースをサポートできる。ＶｏＩＰデバイス３００は、リードオンリーメモリデバイス（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、ハードドライブ、光ドライブ等の永久的及び／または、取り外し可能なストレージを含むハードウェア要素３０６を含むことができる。オペレーティングシステムの操作を制御するプログラム命令及び／又は１つ以上のアプリケーションを記憶し、且つデバイスが含まれるＶｏＩＰクライアントに関連付けられた個人（例えば、音声プロフィール、ユーザ生体認証情報など）と関係があるコンテキスト情報を記憶するように、ストレージが構成されてもよい。１実施形態では、ハードウェア要素３０６はＶｏＩＰインターフェイスカードを含むことができる。ＶｏＩＰインターフェイスカードによって、非ＶｏＩＰデバイスがＶｏＩＰ通話を送受信することができる。

デバイス３００はデバイス３００の操作のためのソフトウェアアプリケーション成分３１０及び様々なＶｏＩＰサービスをサポートするためのＶｏＩＰサービスアプリケーション成分３０８をさらに含むことができる。ＶｏＩＰサービスアプリケーション成分３０８は、データパケットアセンブラ／逆アセンブラアプリケーション、構造化階層構造の構文解析アプリケーション、音声コーダ／デコーダ、（コーデック、）、ビデオＣＯＤＥＣ及びＶｏＩＰサービスを提供する他の適当なアプリケーション等のアプリケーションを含んでもよい。

図４を参照すると、本発明の実施形態に係る、通話チャネルを介した２つの異なったＶｏＩＰクライアントのＶｏＩＰデバイス間の通話フロー４００を例示するブロック図が示されている。接続セットアップ段階の間では、第１のＶｏＩＰクライアント４０６のＶｏＩＰデバイスは、第２のＶｏＩＰクライアント４０８を有する通話チャネルを開始するように要求する。実施形態では、第１のＶｏＩＰクライアント４０６に対するＶｏＩＰサービスプロバイダ４０２（プロバイダー１）は通話チャネルに開始するという要求を受信して、第２のＶｏＩＰクライアント４０６に対するＶｏＩＰサービスプロバイダ４０４（プロバイダー２）に対してその要求を転送する。この実施形態は２つのＶｏＩＰサービスプロバイダと２つのＶｏＩＰクライアントを利用しているが、本発明の実施形態と共にＶｏＩＰクライアント及び／または、サービスプロバイダのいかなる個数と組合せも利用してもよい。例えば、接続を確立する際に１つのサービスプロバイダのみ利用してもよい。さらに別の実施形態では、公用と私設回線を利用して、ＶｏＩＰデバイス間の通信は直接的であってもよいので、その結果、ＶｏＩＰサービスプロバイダの必要性が排除される。ピアツーピアコンテキストでは、ＶｏＩＰデバイス間の通信は、いかなるサービスプロバイダを有しないで、直接的であってもよい。

ＶｏＩＰクライアント、ＶｏＩＰデバイス、及び／または、ＶｏＩＰサービスプロバイダ間で情報交換する際の使用のために選択される種々のプロトコルがある。例えば、セッション開始プロトコル（ＳＩＰ）が信号プロトコルのために選択されるとき、セッション制御情報とメッセージがＳＩＰ信号パス／チャネルを介して変換され、メディアストリームがリアルタイムトランスポートプロトコル（ＲＴＰ：Real-Time Transport Protocol）パス／チャネルを介して交換されることとなる。議論のために、本明細書で用いられる通信チャネルは、いかなるタイプのデータまたは信号交換パス／チャネルを一般に参照する。従って、プロトコルに依存して、接続セットアップフェーズと接続終了フェーズは通話フロー４００中の追加ステップを必要としてもよいことが十分理解されるだろう。

説明を容易にするため、我々は、第１のＶｏＩＰクライアント４０６と第２のＶｏＩＰクライアント４０８の各々が１つのＶｏＩＰデバイスだけを含む実施形態を利用する。従って、本明細書での議論は、２つのＶｏＩＰデバイスの接続について言及している。第１のＶｏＩＰクライアント４０６のデバイスを使用している個人は、呼ばれることになっているクライアントの固有のクライアント識別子を選択又は入力する。プロバイダ１４０２は、要求に含まれる固有のクライアント識別子に基づいて、第１のＶｏＩＰクライアント４０８のデバイスから要求を受信し、終了サービスプロバイダ（例えば、第２のＶｏＩＰクライアント４０８のプロバイダ２４０４）を決定する。そして、その要求はプロバイダ２４０４に対し転送される。この呼び出し開始が、第２のＶｏＩＰクライアントのデバイスに対して送信されることとなる。第１のＶｏＩＰクライアント４０６のデバイスと第２のＶｏＩＰクライアント４０８のデバイスとの間の通話チャネルが確立される。

実施形態では、第１のＶｏＩＰクライアント４０６と第２のＶｏＩＰクライアント４０８のデバイスがデータパケットを交換し始める前に、コンテキスト情報が交換されてもよい。以下により詳細に説明するように、通話に関連付けられた事前に定義された構造に従って、コンテキスト情報がパケット化されてもよい。第１のＶｏＤＰクライアント４０６、第１のＶｏＩＰクライアント４０６のサービスプロバイダ、または異なったデバイス／サービスプロバイダに関連付けられたいかなるデバイスもコンテキスト情報に関する内容に基づいて構造を決定できる。１実施形態では、交換されたコンテキスト情報は、呼出しＶｏＩＰクライアント４０６、デバイス、及び発呼ＶｏＩＰクライアント４０８に関連する情報を含んでもよい。さらに、特定の情報に関する照会がコンテキスト情報の一部として送信されてもよい。例えば、ＶｏＩＰクライアント４０６は、ＶｏＩＰクライアント４０８の地理的なロケーション情報に関する照会を送信することができる。プロバイダ１４０２、または被発呼ＶｏＩＰクライアントは、被発呼ＶｏＩＰクライアントの地理的なロケーション情報を収集し、発呼ＶｏＩＰクライアント４０６に対して収集された情報を与える。１実施形態では、プロバイダ１４０２は、クライアントが呼び出し開始を要求するときに、クライアントの地理的なロケーション情報を有することができる。代わりに、プロバイダ１４０２は、ＶｏＩＰクライアントのロケーション情報を保持する位置のサービスサーバからそのような情報を取得できる。

利用可能なメディアタイプ、発呼側クライアントと被発呼側クライアントの規則等は、接続セットアップ段階の期間中において交換されるコンテキスト情報の一部であってもよい。コンテキスト情報の性質に依存して、第１のＶｏＩＰクライアント４０６のデバイスの１つ、第２のＶｏＩＰクライアント４０８のデバイスの１つ、及び／または、ＶｏＩＰサービスプロバイダ（例えば、プロバイダ１４０２とプロバイダ２４０４）によって、コンテキスト情報が処理され且つ収集されてもよい。１実施形態では、コンテキスト情報を送信する前に、ＶｏＩＰサービスプロバイダ４０２、４０４が、クライアントのコンテキスト情報に対して、何らかの情報を付加し、削除し、そして／または、変更してもよい。

通話チャネルに着手するという要求に応答して、第２のＶｏＩＰクライアント４０８は、通話チャネルを確立するのを求める要求を受け付けるか、又はプロバイダ２４０４を介して要求を拒絶する等の他の適切な行動を実行できる。適切な行動は取得されたコンテキスト情報に基づいて決定されてもよい。通話チャネルが確立されるときは、第１のＶｏＩＰクライアント４０６のデバイスと第２のＶｏＩＰクライアント４０８のデバイスは、データパケットを交換することによって、お互いに通信し始める。以下でさらに詳細に説明するように、通話データパケットとコンテキストデータパケットとを含むデータパケットが、接続されたデバイス間の確立した通話チャネルを介して通信される。

通話データパケットは、例えば、通話、音声データパケット、またはマルチメディアデータパケットに関連するデータを転送する。コンテキストデータパケットは通話データ以外のデータに関連する情報を転送する。一度、通話チャネルが確立されと、第１のＶｏＩＰクライアント４０６又は第２のＶｏＩＰクライアント４０８のどちらか一方が、通話チャネルを終了させるよう要求できる。終了の後に、第１のＶｏＩＰクライアント４０６と第２のＶｏＩＰクライアント４０８との間でいくつかのコンテキスト情報が交換されてもよい。

図５は、本発明の実施形態に係る通信（通話）チャネルを介して使用されるデータパケット構造５００のブロックダイアグラムである。データパケット構造５００は、通話データ（例えば、音声、マルチメディアデータ等）またはコンテキストデータ（例えば、ＶｏＩＰサービスに関連する情報等）を伝えるに利用されるのに適当なＩＰデータパケットに関するデータパケット構造であってもよい。しかしながら、通話データまたはコンテキストデータを伝えるのにいかなる他の適当なデータ構造も利用できる。データパケット構造５００はヘッダ５０２とペイロード５０４を含んでいる。ヘッダ５０２は、対応するデータパケットを送付先に提供する必要情報を含むことができる。さらに、ヘッダ５０２は通話の途中に利用された情報を含むことができる。そのような情報は、通話（例えば、発呼）を特定する通話ＩＤ５０６、発呼側クライアントの固有のクライアント識別子等の送信先ＩＤ５０８、ソースＩＤ５１０（発呼側クライアントまたはデバイス識別子の固有のクライアント識別子）、ペイロード（例えば、通話又はコンテキスト）のタイプを特定するペイロードＩＤ５１２、通話データが関連する個人を特定する個人ＩＤ（図示せず）等を含んでもよい。代替実施形態では、ヘッダ５０２はインターネットプロトコルバージョン及び特にペイロード長に関する情報を含んでもよい。ペイロード５０４は特定された通話に関連する通話またはコンテキストデータを含んでもよい。当業者によって十分理解されるように、TCPヘッダや、ＵＤＰヘッダ等の上部層ヘッダに対して追加ヘッダを使用してもよい。

本発明の１実施形態では、構造化階層構造が、ＶｏＩＰ通話チャネルを介してコンテキスト情報を通信させるために事前に定義されてもよい。コンテキスト情報は、ＶｏＩＰクライアント、ＶｏＩＰデバイス、通話チャネル接続（例えば、コールベーシック）、通話コンテキスト（例えば、コールコンテキスト）等に関連するいかなる情報を含んでもよい。より具体的には、コンテキスト情報は、クライアントの優先、クライアント規則、クライアントのロケーション（例えば、ユーザ位置、デバイス位置等）、生体認証情報、ユーザの秘情報資料、ＶｏＩＰデバイスの機能性、ＶｏＩＰサービスプロバイダ情報、メディアタイプ、メディアパラメータ、呼出し数の優先順位、キーワード、アプリケーションファイルに関連する情報等を含んでもよい。コンテキストデータの性質に依存して、ＶｏＩＰクライアントの各々及び／又はＶｏＩＰサービスプロバイダにおいて、コンテキスト情報が処理され且つ収集されてもよい。１つの態様においては、ＶｏＩＰサービスプロバイダは、コンテキスト情報を送信する前に、ＶｏＩＰクライアントコンテキストデータを追加し、変更し、そして／または、削除できる。例えば、クライアントがそのような情報が送信されるのを認可しない場合、ＶｏＩＰクライアントの秘情報資料は、そのクライアントに関連付けられたＶｏＩＰサービスプロバイダによって削除されるだろう。いくつかの場合では、イントラネットネットワークの外部に最少量のコンテキスト情報が送信される。

図６を参照すると、本発明の実施形態に係る、コンテキスト情報を転送する２つのＶｏＩＰクライアント間における相互作用を示すブロックダイアグラム６００が、示されている。図４の場合ように、本明細書に記載されたその実施形態は、クライアントの各々が、関連付けられた１つのデバイスのみを有し且つこれら２つのデバイス間において接続が生ずるシナリオを利用するだろう。１実施形態では、ＶｏＩＰクライアント６０６とＶｏＩＰクライアント６０８のデバイスはＶｏＩＰ通話チャネルを確立している。どの構造化階層構造がＶｏＩＰクライアント６０６によって、特定のコンテキスト情報を伝えるのに使用されるのを、特定できる。特定された構造化階層構造に関する情報は、どの構造化階層構造がコンテキスト情報を伝達えるのに使用されるか、どのようにして構造化階層構造を特定するか等に関する情報を含んでもよい。対応するコンテキスト情報を交換する前にＶｏＩＰクライアント６０６とＶｏＩＰクライアント６０８との間でそのような情報が交換されることとなる。どの構造化階層構造がコンテキスト情報を伝達するのに使用されるかを特定する情報を受信すると、ＶｏＩＰクライアント６０８は、事前に定義された構造化階層構造（例えば、ＸＭＬネームスペース等）を調べて、特定された構造化階層構造を選択する。１実施形態では、事前に定義された構造化階層構造を、ＶｏＩＰクライアントのグループからアクセス可能な集中化された位置で全体的に記憶し且つ管理することができる。この実施形態では、集中化された位置のユニフォームリソース識別（ＵＲＩ：Uniform Resource Identifier）アドレスがＶｏＩＰクライアント６０６からＶｏＩＰクライアント６０８まで送信されてもよい。

別の実施形態では、ＶｏＩＰクライアントの各々は、いかなるデバイスのローカルストレジ又はすべてのデバイスが共有できる専用ローカルストレジ内に記憶された一連の事前に定義された構造化階層構造を有してもよい。事前に定義された構造化階層構造が宣言され、コンテキスト情報が交換される前にＶｏＩＰクライアント間で一致されてもよい。この様に、コンテキストデータパケットの構造を与える必要性が排除され、その結果、コンテキストデータに対応する送信されたデータパケットの量が低減される。さらに、事前に定義された構造化階層構造を採用することによって、ハードウェア及び／又はソフトウェアから独立した方法でデータパケットを送信できる。

特定された構造化階層構造を読み出す際に、ＶｏＩＰクライアント６０８は、データストリームを受信することになっているので、特定された構造化階層構造に従ってデータストリームに対応するデータパケットが定義される。ＶｏＩＰクライアント６０６は、特定された構造化階層構造に従って表されたコンテキスト情報を送信し始めることができる。１実施形態では、ＶｏＩＰクライアント６０８はコンテキスト情報に関するデータ結合処理を開始する。例えば、特定された構造化階層構造のインスタンスを、受信されたコンテキスト情報を用いて構成することができる。

図７Ａと７Ｂは、本発明の実施形態に係る、ＶｏＩＰエンティティの内のロケーション情報に関する照会に応じて、かかるロケーション情報の収集及び変換を示しているブロック図７００である。１実施形態では、ＶｏＩＰエンティティはＶｏＩＰクライアント、クライアントに関するＶｏＩＰサービスプロバイダ、第３パーティーサービスプロバイダー（例えば、ロケーションサービスプロバイダ）等を含んでもよい。

図７Ａを参照すると、１実施形態では、ＶｏＩＰクライアント６０８は、ＶｏＩＰクライアント６０６に関連する特定のコンテキスト情報に関する照会を送信できる。この実施形態は１つのＶｏＩＰサービスプロバイダと２つのＶｏＩＰクライアントを利用しているが、本発明の実施形態と共にＶｏＩＰクライアント及び／または、サービスプロバイダのいかなる個数と組合せも使用できる。照会はＶｏＩＰクライアント６０６に関するロケーション情報を求めることができる。サービスプロバイダ６０２は、ロケーション情報を含むコンテキスト情報をＶｏＩＰクライアント６０６から取得できる。以下でさらに詳細に説明するように、構造化階層構造は、実施形態におけるいくつかのＶｏＩＰエンティティ間においてコンテキスト情報（コンテキストデータパケット）を伝達するのに利用されることが想定されている。

議論のために、ＶｏＢＰクライアント６０６とＶｏＩＰクライアント６０８がＶｏＩＰサービスプロバイダに対するサービスプロバイダ６０２を有すると仮定する。ロケーションサービスサーバ６１４は特定のタイプに関するロケーション情報をサービスプロバイダ６０２に与えるのに利用可能である。以下でさらに詳細に説明するように、ロケーション情報は、クライアントで定義されたロケーション、デバイスで定義されたロケーション、地理的な位置、仮想的若しくは論理的な位置等に関連する様々なタイプに関する情報を含むことができる。ロケーションサービスサーバ６０２の実施形態は、全地球位置発見システム（GPS：Global Positioning System;衛星利用測位システム、汎世界測位システムともいう）サービスサーバ、ユーザロケーションサービスサーバ（例えば、インターネットロケータサーバ、ネットワーク上のコンファレンシングディレクトリサーバ等）等であってもよい。インターネット位置のサーバが、現在のＩＰアドレスを介して個々のユーザを特定するのに使用されてもよい。１実施形態では、ＶｏＩＰクライアント６０８は、ＶｏＩＰクライアント６０６に関連する特定のコンテキスト情報（例えば、デバイスの地理的ロケーション情報）に関する照会を送信してもよい。サービスプロバイダ６０２は、何のコンテキスト情報が収集されるのか、及び、特定されたコンテキスト情報を取得するためにどの適切なソースがコンタクトされ且つ問い合わせが実行されるのかを特定するための照会について処理する。

適切なソースがＶｏＩＰクライアント６０６である場合、サービスプロバイダ６０２はＶｏＩＰクライアント６０６に対して特定されたコンテキスト情報を要求する。要求を受け取り次第、ＶｏＩＰクライアント６０６は、要求されたコンテキスト情報を収集し且つ収集されたコンテキスト情報を伝達するに使用される構造化階層構造を特定する。収集されたコンテキスト情報は、ＶｏＩＰクライアント６０６から特定された構造化階層構造を利用するプロバイダ１６０２に送信される。適切なソースがロケーションサービスサーバ６１４である場合、サービスプロバイダ６０２はロケーションサービスプロバイダから情報を取得する。１実施形態では、ＶｏＩＰクライアント６０６及びＶｏＩＰクライアント６０８に対するサービスプロバイダ６１６はサービスプロバイダ（サーバ）６０２とロケーションサービスサーバ６１４を含んでもよい。この実施形態では、サービスプロバイダ６１６はロケーション情報をクライアントに与える。

代わりに、上記照会を受信すると、サービスプロバイダ６０２は、様々なソースからのＶｏＩＰクライアント６０６、例えば、個々のユーザの地理的位置、デバイスの地理的位置、ネットワークにおけるデバイスの論理的位置、仮想空間内の個々のユーザの位置等に関連するいかなる容易に利用可能なロケーション情報も、取得し且つ収集する。サービスプロバイダ６０２は、受信されたロケーション情報を処理し、ロケーション情報の所望部分を記憶し、照会に基づいて受信された情報のサブセットを送信してもよい。記憶された情報を将来的に使用してもよい。上記議論したように、サービスプロバイダ６０２は、照会に関連する追加コンテキスト情報を特定し且つ取得し、従って、現在のコンテキスト情報（例えば、以前に取得されたロケーション情報）を更新する。さらに、サービスプロバイダ６０２は、コンテキスト情報を送信する前に取り除かれ、追加され、そして／または、変更される現在のコンテキスト情報の部分を特定して、受信されたコンテキスト情報を更新してもよい。１実施形態では、また、特定された構造化階層構造に関する情報は、サービスプロバイダ６０２に又は直接的にＶｏＩＰクライアント６０６に送信される。特定された構造化階層構造に関する情報は、どの構造化階層構造がコンテキスト情報を伝達するのに使用されるか、どうのようにして構造化階層構造を特定するか等に関する情報を含むことができる。

実施形態では、コンテキスト情報の一部を付加又は削除することによって、サービスプロバイダ６０２はＶｏＩＰクライアント６０８からの照会に応答するに適当な個々の必要性に応じたコンテキスト情報を生成してもよい。例えば、サービスプロバイダ６０２は、特定のタイプのロケーション情報を含むコンテキスト情報及び特定のタイプのロケーション情報に関連する他のコンテキスト情報を生成してもよい。サービスプロバイダ６０２は、ＶｏＩＰクライアント６０８に対して個々の必要性に応じたコンテキスト情報を送信してもよい。代わりに、サービスプロバイダ６０２は、個々の必要性に応じたコンテキスト情報（例えば、ロケーション情報）、または取得されたコンテキスト情報を第三機関SPに送信してもよく、その第三機関SPは受信されたコンテキスト情報をＶｏＩＰクライアント６０８に対して送信する。第三機関ＳＰは、より多くのコンテキスト情報を収集することができ、必要であるならば、情報を追加し、削除し、そして／または、変更することによって、受信されたコンテキスト情報を更新してもよい。

１実施形態では、構造化階層構造を拡張マークアップ言語（ＸＭＬ：Extensible Markup Language）によって定義できる。しかしながら、拡張可能な構造化階層構造を実装し且つ保持するのに適当ないかなる言語によっても、構造化階層構造を定義できることが十分理解されるべきである。一般に説明すると、情報送信のためのツールから独立したクロスプラットフォーム、ソフトウェア、及びハードウェアに対しては、ＸＭＬは周知である。さらに、ＸＭＬは、各々が描写的である属性を含むことができるタグを含むノードの階層的構造化ツリーとしてそのデータを保持する。通常、にＸＭＬネームスペースは、固有の名前をネームスペースに与えるために与えられる。ある場合においては、ネームスペースは、ネームスペースに関するデフォルト情報を含む集中化されたロケーションへのポインタとして使用されてもよい。

実施形態によると、通信チャネルが確立されている間は、ＶｏＩＰクライアント６０６はコンテキスト情報に関するＸＭＬネームスペースを特定できる。例えば、ＸＭＬネームスペース属性を送信側の成分の開始タグに設置することができる。本明細書に示したＸＭＬネームスペース、属性、およびクラスが、本発明の様々な実施形態に関連して使用される構造化階層構造の実施形態として単に与えられていることを理解すべきである。ＶｏＩＰクライアント６０８がＸＭＬネームスペース情報を受信した後に、ＶｏＩＰクライアント６０６は特定されたＸＭＬネームスペースに従って定義された一連のコンテキストデータパケットをＶｏＩＰクライアント６０８に対して送信する。ネームスペースが成分の開始タグ内で定義されるとき、同じプレフィックス（電話の局番）を有するすべての子成分（child elements）が同じネームスペースと関連付けられる。そういうものとして、ＶｏＩＰクライアント６０８とＶｏＩＰクライアント６０６はすべての子成分中のプレフィックスを含まないコンテキスト情報を送信できるので、その結果、コンテキスト情報に対して送信されたデータパケット量が低減される。

図８−図１２Ｂを参照すると、ＶｏＩＰコンテキスト情報に対応する構造化階層構造の様々なクラスと属性を例示するブロックが示されている。様々なＶｏＩＰエンティティ（例えば、クライアント、サービスプロバイダ等）の間で交換されたＶｏＩＰコンテキスト情報は、ＶｏＩＰネームスペース８００に相当してもよい。１実施形態では、ＶｏＩＰネームスペース８００は、ノードの階層的に構造化されたツリーとして表され、各ノードはＶｏＩＰコンテキスト情報のサブセットに対応するサブクラスに対応する。例えば、ＶｏＩＰネームスペース８００は、コールベーシッククラス（Call Basics Class）８０２、コールコンテキストクラス（Call Contexts Class）８１０、デバイスタイプクラス８２０、ＶｏＩＰクライアントクラス８３０等として定義されてもよい。

図９を参照すると、コールベーシッククラス８０２のブロックダイアグラムが示されている。実施形態では、コールベーシッククラス８０２は、通話チャネル接続（例えば、ＰＳＴＮ呼び出し接続、ＶｏＩＰ呼び出し接続等）に関連するＶｏＩＰコンテキスト情報のサブセットに相当してもよい。通話チャネル接続に関連するＶｏＩＰコンテキスト情報のサブセットは、送信元番号（例えば、発呼側のクライアントＩＤ番号）、送信先番号（例えば、被発呼側のクライアントＩＤ番号または電話番号）、呼び出し接続時間、ＶｏＩＰサービスプロバイダ関連情報、及び／又はＩＰアドレス、ＭＡＣアドレス、若しくはネームスペース情報等のＩＳＰ関連情報を含んでもよい。さらに、通話チャネル接続に関連するコンテキスト情報は、（送信先番号の優先順位を定義する）発呼優先情報、呼び出しタイプ情報等を含んでもよい。呼び出しタイプ情報によって、通話チャネルが非常時の通信、放送通信、コンピュータ間通信、POTS通信に対するコンピュータ等に対して確立されているか否が示される。１実施形態では、通話チャネル接続に関連するコンテキスト情報は、感情、音声 (例えば、「ああ」、「おっと」、「ワオ」等）及びグラフィックな符号での顔表情を表す事前に定義された識別子を含むことができる。１実施形態では、コールベーシッククラス８０２は、ＶｏＩＰネームスペース８００のサブツリー構造として定義されてもよく、そのＶｏＩＰネームスペース８００のサブツリー構造は、コール優先８０３、ネームスペース情報８０４、呼び出しタイプ８０５、送信番号８０６、サービスプロバイダ８０７、事前に定義された識別子８０８等のノードを含んでいる。

図１０を参照すると、コールコンテキストクラス８１０のブロック図が示されている。１実施形態では、通話コンテキストに関連するＶｏＩＰコンテキスト情報のサブセットは、コールコンテキストクラス８１０に対応できる。通話コンテキストに関連するコンテキスト情報は、クライアントが提供したキーワード、ドキュメントファイルデータからの特定されたキーワード、通話データパケット（例えば、通話キーワード）からの特定されたキーワード、通話の一部として交換されたドキュメント及び／またはマルチメディアファイルに関するファイル名、（ゲームタイプ及びあるゲームにおける仮想の近接等の）ゲーム関連情報、（特定のファイル、特定の主題、及び特定のクライアントに関連する発呼頻度と期間を含む）使用頻度、並びに（通話に関連するケース番号、事件番号等）のファイル識別番号等の情報を含んでもよい。実施形態によると、コールコンテキストクラス８１０はＶｏＩＰネームスペース８００のサブツリー構造として定義されてもよく、そのＶｏＩＰネームスペース８００のサブツリー構造は、ファイル識別番号８１２、クライアントが供給したキーワード８１３、通話キーワード８１４、利用頻度８１５、通話の主題８１６等に対応するノードを含む。

図１１を参照すると、デバイスタイプクラス８２０のブロック図が示されている。１実施形態では、デバイスタイプクラス８２０は通話チャネル接続に使用されるＶｏＩＰクライアントデバイスに関連するＶｏＩＰコンテキスト情報のサブセットに対応できる。ＶｏＩＰクライアントデバイスに関連するＶｏＩＰコンテキスト情報のサブセットはオーディオ関連情報を含むことができ、そのオーディオ関連情報はＶｏＩＰクライアントデバイスによって生成された音声データを処理するのが必要とされる。オーディオ関連情報は、サンプリングレート、マシンタイプ、出力／入力タイプ、マイクロホン、デジタル信号処理（ＤＳＰ：Digital Signal Processing）カード情報等のデバイスの音声機能性と能力に関連する情報を含むことができる。ＶｏＩＰクライアントデバイスに関連するＶｏＩＰコンテキスト情報のサブセットはビデオ関連情報を含むことができ、そのビデオ関連情報は、ＶｏＩＰクライアントデバイスによって生成されるビデオデータを処理するのが必要とされる。ビデオ関連情報は、解像度、リフレッシュ、ビデオデータのタイプとサイズ、グラフィックカード情報等の情報を含むことができる。ＶｏＩＰクライアントデバイスに関連するコンテキスト情報は、コンピュータシステムのタイプ、プロセッサ情報、ネットワーク帯域幅、無線／有線接続、コンピュータシステムの携帯性、コンピュータシステムの処理設定等の他のデバイス仕様情報を含むことができる。実施形態では、デバイスタイプクラス８２０は、ＶｏＩＰネームスペース８００のサブツリー構造として定義されてもよく、そのＶｏＩＰネームスペース８００のサブツリー構造は、オーディオ８２２、ビデオ８２４、デバイス仕様８２６等に対応するノードを含んでいる。

図１２ＡはＶｏＩＰクライアントクラス８３０のブロック図を示している。実施形態によると、ＶｏＩＰクライアントクラス８３０はＶｏＩＰクライアントに関連するコンテキスト情報のサブセットに対応できる。１実施形態では、ＶｏＩＰクライアントに関連するＶｏＩＰコンテキスト情報のサブセットは、音声プロフィール情報（例えば、個々のユーザの音色及び音声の特性を指定する情報の収集）、デジタル署名情報、並びに生体認識情報を含むことができる。生体認識情報は、生体認識認証、ユーザの強調レベル、ユーザの気分等に関連するユーザ特定情報（例えば、指紋）を含むことができる。ＶｏＩＰクライアントに関連するＶｏＥＰコンテキスト情報のサブセットは、割り当てられた電話番号、（名前、住所、会社等の）ユーザの連絡先、クライアントによって定義された規則、ユーザの好み、デジタル権利管理（ＤＲＭ：digital rights management）、組織内の個々のユーザの階級、階級と関連付けられた優先順位等の情報を含むことができる。階級と関連付けられた優先順位は、電話会議のために優先順位をクライアントに割り当てるのに使用されてもよい。以下でさらに詳細に説明するように、ＶｏＩＰクライアントに関連するＶｏＩＰコンテキスト情報のサブセットはロケーション情報を含むことができる。１実施形態では、ＶｏＩＰクライアントクラス８３０を、ＶｏＩＰネームスペース８００のサブツリー構造として定義でき、そのＶｏＩＰネームスペース８００のサブツリー構造は、ユーザの生体認識８３１、ユーザの好み８３２、クライアント規則８３３、ユーザ識別８３４、メンバ優先順位８３５、ロケーション８４０等に対応するノードを含んでいる。

図１２Ｂを参照すると、ロケーションサブクラス８４０のブロック図が示されている。１実施形態では、ロケーションサブクラス８４０は、ＶｏＩＰクライアントに関連するロケーション情報、個々のユーザ、及び／または、通話チャネル接続に使用されるデバイスに関連するＶｏＩＰコンテキスト情報のサブセットに対応できる。以上のように、サービスプロバイダは、特定のタイプのロケーション情報が取得され又は問い合わせられることに関する事前知識を有することができる。ロケーション情報に関連するＶｏＩＰコンテキスト情報のサブセットは、クライアントの定義ロケーション、ＧＰＳ／三角測量位置（特定のユーザ、デバイス、又はクライアントアカウントの地理的位置）、個々のユーザの論理的又は仮想の位置、クライアントの定義位置、デバイスの定義位置等に関連する情報を含むことができる。ＧＰＳサーバ等から地理的なロケーション情報を取得できる。さらに、ロケーション情報は、デバイスネットワークアドレスとサービスプロバイダの定義位置（例えば、ＶｏＩＰサービスプロバイダはクライアントの位置を定義できる）に関連する情報を含むことができる。デバイスネットワークアドレスは、コンピュータのＩＰアドレス、装置が特定の第三機関サーバ若しくはサービスプロバイダに対してどの程度論理的に近接しているかを定義する論理位置等であってもよい。実施形態では、ＶｏＩＰクライアント８３０のサブツリー構造として、ロケーションサブクラス８２０を定義でき、そのＶｏＩＰクライアント８３０のサブツリー構造は、ユーザの定義位置８４１、ユーザの仮想位置８４２、ユーザ地理的位置８４３、クライアント位置８４４、デバイスの定義位置８４５、デバイス地理的位置８４６、デバイスネットワーク位置８４７等に対応するノードを含んでいる。

図１３は、本発明の実施形態に係る、ロケーション情報の照会に応答してコンテキスト情報を与えるロケーション情報ルーチン１３００を示すフローチャートである。実施形態では、発呼側（発呼側ＶｏＩＰクライアント）のデバイスは、被発呼側（被発呼側ＶｏＩＰクライアント）との通信チャネル接続を開始するように関連サービスプロバイダに要求していてもよい。議論のため、発呼側が接続セットアップ段階の間において被発呼側のロケーション情報の照会をサービスプロバイダに送信すると仮定する。被発呼側のサービスプロバイダは被発呼側のロケーション情報を収集し且つ与える権限を有することができる。しかしながら、通信チャネルを確立する前（例えば、接続セットアップ段階の間）、又は通話若しくは通信チャネルを終了させた後を含み、何時でも、ロケーション情報以外の特定の情報に関する照会を交換することができると想定されている。さらに、照会を受け取り次第、様々なＶｏＩＰエンティティ内で照会に対応するコンテキスト情報を交換できる。ＩＰ環境１００内のいかなる認可ＶｏＩＰエンティティは、照会を受信し且つ照会に応じてコンテキスト情報を与えることができる。

ブロック１３０２で始まると、サービスプロバイダは、被発呼側のロケーション情報に関する照会を含んで、発呼側のコンテキスト情報を取得する。上記したように、コンテキスト情報の内容に基づいて、ＸＭＬネームスペース等の事前に定義された構造化階層構造から少なくとも１つの構造化階層構造を特定できる。サービスプロバイダは発呼側から特定された構造化階層構造を取得できる。ブロック１３０４では、サービスプロバイダは照会に対応する情報を特定する。例えば、発呼側は、コンファレンスコールで通信している被発呼側のデバイスのロケーション情報を要求する。サービスはデバイスの論理的位置（例えば、ＩＰアドレス）に関連するロケーション情報を特定できる。決定ブロック１３０６では、特定された情報が現在入手可能であるかどうかに関して判断される。特定された情報が被発呼側に関連するあらかじめ取得されたコンテキスト情報またはローカルストレジ内の以前に記憶されたコンテキスト情報から入手可能であるかどうかを、サービスプロバイダは判断できる。

特定された情報が現在入手可能である場合、ブロック１３０８では、サービスプロバイダは現在取得された情報を取得できる。特定された情報が現在入手可能でない場合、特定された情報を取得するのに適切なソースがブロック１３１０で特定され且つ指定される。適切なソースは、被発呼側、第三機関サービスサーバ、他のサービスプロバイダ等のいかなるＶｏＩＰエンティティも含むことができる。サービスプロバイダは、適切なソースに連絡して、特定された情報について問い合わせをする。１実施形態では、サービスプロバイダは、ソース側に情報を集めるコンテキスト情報を送ることができる。代替実施形態では、サービスプロバイダは特定された情報の照会に対応するコンテキスト情報をソース（例えば、被発呼側）に送ることができる。特定された情報に入手可能な複数ソースがあるときは、サービスプロバイダは最も適切なソースを判断できる。サービスプロバイダは、特定の情報のための適切なソースを決定するためにプロバイダ規則または論理を事前に定義していてもよい。例えば、ＧＰＳサーバが、ＧＰＳモジュールを備える装置の地理的ロケーション情報に関する適切なソースの一つであってもよい。個々のユーザの携帯電話がモバイル機器の地理的なロケーション情報を与える場合、その装置は適切なソースの１つであってもよい。同様に、ＶｏＩＰクライアントがデバイスの地理的なロケーション情報を保持する場合、ＶｏＩＰクライアントは適切なソースの１つであってもよい。

この実施形態では、サービスプロバイダは発呼側と被発呼側から取得されたコンテキスト情報に基づいて最も適切な１つを選択できる。コンテキスト情報は被発呼側の規則、発呼側の規則、被発呼側の装置情報、被発呼側と関連付けられた対象となる個々のユーザ等を含むことができる。ブロック１３１２では、特定されたソースから情報（例えば、ロケーション情報）が取得される。変形実施形態では、特定された情報に対して入手可能な複数のソースがあるときは、サービスプロバイダは、複数のソースから特定された情報が取得され、取得された情報に基づいて包括的な情報が生成される。ブロック１３１４では、サービスプロバイダ（１３０８）からの取得された情報又はソース（１３１２）からの取得された情報が第２のＶｏＩＰクライアントに与えられる。ルーチン１３００は１３１６で完了する。

例示的実施形態について示し且つ説明してきたが、本発明の趣旨と範囲から逸脱しないで、様々な変更をなすことができることは、十分に理解することができるであろう。

本発明の１態様に係る様々なクライアント間の通話チャネルを確立するＶｏＩＰ環境を示すブロック図である。本発明の１態様に係るＶｏＩＰクライアントを示すブロック図である。本発明の１態様に係るＶｏＩＰデバイスと関連付けられた種々のコンポーネントを示すブロック図である。本発明の１態様に係る通話チャネルを介した２つのＶｏＩＰクライアント間のデータ交換を示すブロック図である。図１のＶｏＩＰ環境内で確立された通信チャネルを介して使用されるデータパケットのブロック図である。本発明の１態様に係る特定された構造化階層構造によって定義されたコンテキスト情報を伝える２つのＶｏＩＰクライアント間の相互作用を示すブロック図である。本発明の１態様に係る照会に応じてコンテキスト情報を収集し且つ提供するＶｏＩＰエンティティ間の相互作用を示すブロック図である。本発明の１態様に係る照会に応じてコンテキスト情報を収集し且つ提供するＶｏＩＰエンティティ間の相互作用を示すブロック図である。本発明の１態様に係るＶｏＩＰコンテキスト情報に対応する様々な属性とクラスの構造化階層構造を示すブロック図である。本発明の１態様に係るＶｏＩＰコンテキスト情報に対応する様々な属性とクラスの構造化階層構造を示すブロック図である。本発明の１態様に係るＶｏＩＰコンテキスト情報に対応する様々な属性とクラスの構造化階層構造を示すブロック図である。本発明の１態様に係るＶｏＩＰコンテキスト情報に対応する様々な属性とクラスの構造化階層構造を示すブロック図である。本発明の１態様に係るＶｏＩＰコンテキスト情報に対応する様々な属性とクラスの構造化階層構造を示すブロック図である。本発明の１態様に係るＶｏＩＰコンテキスト情報に対応する様々な属性とクラスの構造化階層構造を示すブロック図である。本発明の１態様に係るロケーション情報ルーチンを示すフローチャートである。

Claims

発呼側クライアントと被発呼側クライアントとの間の通信チャネルを介した情報照会に関連するコンテキスト情報を提供する方法であって、
前記被発呼側クライアントに関連する情報に関する照会を受信するステップ１３０２と、
前記被発呼側クライアントに関連するコンテキスト情報を取得するステップ１３０２と、
前記被発呼側クライアントのコンテキスト情報に基づいて、前記照会に対応する一連の情報を特定するステップ１３０４と、
収集された前記一連の情報を提供するステップ１３１４と、を含むことを特徴とする方法。
前記一連の情報を特定するステップは前記一連の情報を第三機関から取得するステップを含むことを特徴とする請求項１に記載の方法。
情報に関する前記照会は前記通信チャネルを介した通話の一部であることを特徴とする請求項１に記載の方法。
前記照会に対応する前記一連の情報はロケーション情報を含むことを特徴とする請求項１に記載の方法。
前記ロケーション情報はクライアントで定義されたロケーション情報を含むことを特徴とする請求項４に記載の方法。
前記ロケーション情報はプロバイダで定義されたロケーション情報を含むことを特徴とする請求項４に記載の方法。
第１のクライアントと第２のクライアントとの間のＶｏＩＰ通信チャネルを介した照会に応じて情報を提供するコンピュータ実行可能成分を有するコンピュータ読み込み可能な媒体であって、
情報に関する照会を受信１３０２する情報管理成分と、
前記第１のクライアントのコンテキスト情報を処理し且つ前記情報を得るソースを特定１３０４する情報処理成分と、を含み、
前記情報管理成分が、前記照会に対応する情報を前記ソースから取得１３０８，１３１２し、且つ取得された前記情報を前記第２のクライアントに対して提供する１３１４ことを特徴とするコンピュータ読み込み可能な媒体。
前記情報処理成分は、複数のソースを特定し１３１０、且つ前記コンテキスト情報に基づいて最も適切なソースを選択することを特徴とする請求項７に記載のコンピュータ読み込み可能な媒体。
前記情報照会が前記第２のクライアントから受信されることを特徴とする請求項７に記載のコンピュータ読み込み可能な媒体。
前記情報処理成分がいなかるソースも特定できない場合、前記情報管理成分は所定のデフォルト情報を送信することを特徴とする請求項７に記載のコンピュータ読み込み可能な媒体。
前記情報処理成分は前記取得された情報を追加することによってコンテキスト情報を更新し、前記情報管理成分は当該更新後のコンテキスト情報を送信することを特徴とする請求項７に記載のコンピュータ読み込み可能な媒体。
第１のクライアントと第２のクライアントとの間の通信チャネルを介したロケーションに関連するコンテキスト情報を提供する方法であって、
第１のクライアント４０６，６０６のロケーション情報に関する照会を受信するステップ１３０２と、
前記照会を受信すると、前記第１のクライアントに関連する一連のコンテキスト情報を取得するステップ１３０２と、
前記ロケーション情報が前記取得された一連のコンテキスト情報から入手可能であるか否かを判断するステップ１３０６と、
前記ロケーション情報が入手可能である場合に前記第２のクライアント４０８，６０８に対してロケーション情報を提供するステップ１３１４と、を含むことを特徴とする方法。
前記第２のクライアント４０８，６０８から受信されるコンテキスト情報の一部として前記情報照会が受信されることを特徴とする請求項１２に記載の方法。
前記コンテキスト情報は前記第１のクライアント４０６，６０６と前記第２のクライアント４０８，６０８との間のＶｏＩＰ通信チャネルを介した通話に関連していることを特徴とする請求項１３に記載の方法。
前記第２のクライアント４０８，６０８から受信された前記コンテキスト情報に基づいて前記ロケーション情報のタイプを特定するステップ１３１０をさらに含むことを特徴とする請求項１３に記載の方法。
前記ロケーション情報の前記タイプは前記第１のクライアント４０６，６０６の地理的位置を含むことを特徴とする請求項１５に記載の方法。
前記ロケーション情報のタイプは前記第１のクライアント４０６，６０６のクライアントデバイスのネットワーク位置を含むことを特徴とする請求項１５に記載の方法。
前記ロケーション情報が利用できないで場合、前記一連の取得されたコンテキスト情報に基づいて前記ロケーション情報を取得するための少なくとも一つのソースを判断し、且つ前記少なくとも１つのソースから前記ロケーション情報を取得するステップ１３１０をさらに含むことを特徴とする請求項１２に記載の方法。
前記ロケーション情報の前記少なくとも１つのソースが全地球位置発見システムサーバ６１４を含むことを特徴とする請求項１８に記載の方法。
前記ロケーション情報の前記少なくとも１つのソースがロケーションサービスサーバ６１４を含むことを特徴とする請求項１８に記載の方法。