(57)【要約】  本発明の態様は、送信側クライアントから受信側クライアントにデータアイテムを送信するためのソフトウェアシステムを対象とする。一実施形態によれば、コマンド対処コンポーネントと処理コンポーネントとを含むソフトウェアコンポーネントが提供される。コマンド対処コンポーネントは、データアイテムを送信するコマンドが受け取られたときにイベントデータを受け入れる。次いで、データアイテムを提示する要求が送信側クライアントから受信側クライアントに送信される。要求が受信されると、処理コンポーネントは、送信側クライアントから送信された命令を使用して、データアイテムを受信側クライアント上で提示させる。
2009539313.tif 000002
【特許請求の範囲】
【請求項１】
送信側クライアントと受信側クライアントとを含むデジタル音声通信環境で、前記送信側クライアントから前記受信側クライアントに通信チャネルを介してデータアイテムを送信する方法であって、
前記データアイテムを呼データと共に前記受信側クライアントに送信するコマンドを生成するための制御を提供すること、
前記制御がアクティブ化されるのに応答して、
前記データアイテムを識別するイベントデータを得ること、
前記データアイテムに前記受信側クライアントからローカルにアクセスできるかどうか判定すること（８１０）、
前記データアイテムに前記受信側クライアントからローカルにアクセスできる場合に、前記データアイテムを前記受信側クライアントに送信せずに、前記データアイテムを提示する要求を送信すること（８１２）、および、
反対に、前記データアイテムに前記受信側クライアントからローカルにアクセスできない場合に、前記データアイテムを提示する要求と共に前記データアイテムを送信すること（８１４）を含むことを特徴とする方法。
【請求項２】
前記制御は、送信側によって制定された規則に基づいて前記データアイテムを自動的に送信させるように構成されたことを特徴とする請求項１に記載の方法。
【請求項３】
前記制御は、呼の間に前記データアイテムを送信させるように構成されたことを特徴とする請求項１に記載の方法。
【請求項４】
前記制御は、前記送信側クライアントと前記受信側クライアントとの間で呼を開始するように構成されたアプリケーションプログラムからアクセス可能なソフトウェアベースの制御であることを特徴とする請求項１に記載の方法。
【請求項５】
前記制御は、前記送信側クライアントと前記受信側クライアントとの間で送信されている会話データにオーディオファイルを多重化させることを特徴とする請求項１に記載の方法。
【請求項６】
前記データアイテムに前記受信側クライアントからローカルにアクセスできるかどうか判定することは、
前記受信側クライアントの機能を記述したコンテキスト情報を受信すること（８０４）、
前記コンテキスト情報を使用して、前記受信側クライアントから利用可能なデータアイテムのパッケージを識別すること（８０８）を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記データアイテムは、表情を描いたグラフィカル表現であることを特徴とする請求項１に記載の方法。
【請求項８】
表情を描いた前記グラフィカル表現は、笑顔、しかめ面、またはウィンクであることを特徴とする請求項７に記載の方法。
【請求項９】
前記データアイテムを提示する要求を送信することは、前記データアイテムを識別するタグをデータストリームに埋め込むことを含むことを特徴とする請求項１に記載の方法。
【請求項１０】
前記要求を前記データアイテムと共に送信することは、前記データアイテムをペイロードとして含むデータパケットを組み立てることを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
前記受信側クライアントに送信される前記データアイテムは、テキスト、オーディオ、画像、またはプロシージャに基づくデータフォーマットとすることができることを特徴とする請求項１に記載の方法。
【請求項１２】
コンピュータ可読命令を備えたコンピュータ可読媒体であって、前記コンピュータ可読命令は、データアイテムを提示する要求を送信側クライアントから受信した受信側クライアント中で実行されたとき、前記データアイテムを提示する方法を実施し、前記方法は、
前記送信側クライアントから得られたデータストリーム中のコンテキスト情報を解析して、前記データアイテムを提示する前記要求が受信されたときを識別すること、
前記データアイテムを前記受信側クライアント上で利用可能にするセマンティクスを記述した選好を識別すること（８６０）、および、
前記識別された選好に従って前記データアイテムを前記受信側クライアント上で提示させること（８６６）を含むことを特徴とするコンピュータ可読媒体。
【請求項１３】
前記データアイテムに関連する命令の実行を妨げるために制限を制定できるようにすることをさらに含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１４】
前記制限は、特権を有するユーザによって制定することができることを特徴とする請求項１３に記載のコンピュータ可読媒体。
【請求項１５】
前記データアイテムを前記受信側クライアント上で利用可能にする前記セマンティクスを記述した選好を識別することは、
前記受信側クライアントが前記データアイテムを提示するように構成されているかどうか判定すること、および、
前記受信側クライアントが前記データアイテムを提示するように構成されていない場合に、受信側からアクセス可能なネットワーク位置に前記データアイテムを記憶することを含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１６】
前記データアイテムを前記受信側クライアント上で提示させることは、
前記データアイテムにローカルにアクセスできるかどうか判定すること（８６２）、
前記データアイテムにローカルにアクセスできる場合に、前記データアイテムを呼び戻すこと（８６４）、および、
前記データアイテムにローカルにアクセスできない場合に、前記送信側クライアントから受信したデータストリームから前記データアイテムを識別することを含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１７】
前記データアイテムを前記受信側クライアント上で提示させること（８６６）は、
前記データアイテムを提示するように構成されたアプリケーションプログラムを識別すること、
前記アプリケーションプログラムを起動すること、および、
前記アプリケーションプログラムによって提供される機能を使用して前記データアイテムを表示することを含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１８】
前記データアイテムを前記受信側クライアント上で提示させること（８６６）は、前記受信側クライアントによって提供されるプログラムインタフェースにプロシージャコールを発行することを含むことを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１９】
送信側クライアントから受信側クライアントに通信チャネルを介してデータアイテムを送信するためのコンピュータ実行可能コンポーネントを有するコンピュータ可読媒体であって、
データアイテムを送信するコマンドが受け取られたときにイベントデータを得る（８０６）ように、かつ、前記データアイテムを提示する要求を前記受信側クライアントに送信するように動作可能なコマンド対処コンポーネントと、
前記データアイテムを提示する要求が前記送信側クライアントから受け取られたときを識別する（８５４）ように、かつ、前記イベントデータに従って前記データアイテムを提示させる（８６６）ように動作可能な処理コンポーネントとを備えることを特徴とするコンピュータ可読媒体。
【請求項２０】
前記データアイテムが前記受信側クライアント上でローカルに利用可能かどうか判定する（８６２）ように、かつ、前記データアイテムがローカルに利用可能な場合に、前記データアイテムが前記送信側クライアントと前記受信側クライアントとの間で送信されることなく前記データアイテムを前記受信側クライアント上で提示させる（８６６）ように構成された最適化コンポーネントをさらに備えることを特徴とする請求項１９に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信側クライアントから受信側クライアントにデータアイテムを送信するためのネットワーク通信に関する。
【背景技術】
【０００２】
一般的に述べると、インターネット電話システムは、従来の公衆交換電話網（ＰＳＴＮ）ベースの電話システムと比較して、向上した通話機能を備えた呼接続（call connection）をユーザが有する機会を提供する。ボイスオーバーインターネットプロトコル（ＶｏＩＰ）としばしば呼ばれる典型的なインターネット電話システムでは、オーディオ情報が、インターネットプロトコル（ＩＰ）データネットワークを利用した通信に向けて、パケットと呼ばれるデータブロックの連続に加工される。ＶｏＩＰ通話の間、デジタル化された音声が音声データの小さいフレームに変換され、送受信される音声データのフレームにＩＰヘッダを追加することによって音声データパケットが組み立てられる。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ＶｏＩＰ技術は、その通信フレキシビリティおよび可搬性や、マルチメディア通信を確立し、制御する能力などにより好まれてきた。ＶｏＩＰ技術はおそらく、従来の電話技術が提供できなかった、向上した通話機能および高度なサービスを提供するその能力により、支持を獲得し続けるであろう。例えば、従来の電話技術は通常、オーディオ通信に限られる。しかし、個人が対話するときに大量の非言語情報が通信される場合があることが、一般に認められている。これに関して、「面と向かっての」通信に関与している個人は、ジェスチャーをしたり様々な表情をしたりする場合があり、これらはそれぞれ、通信に関与している相手に情報を伝える。これらおよび他のタイプの非言語通信は、従来の電話技術を使用した場合には通信されないことがある。
【課題を解決するための手段】
【０００４】
本発明の態様は、送信側クライアントから受信側クライアントにデータアイテムを送信するためのソフトウェアシステムを対象とする。一実施形態によれば、コマンド対処コンポーネントと処理コンポーネントとを含むソフトウェアコンポーネントが提供される。コマンド対処コンポーネントは、データアイテムを送信するコマンドが受け取られたときにイベントデータを受け入れる。次いで、処理コンポーネントは、送信側クライアントから送信された命令を使用して、データアイテムを受信側クライアント上で提示（present）させる。結果として、任意の数の異なるフォーマット（例えばテキスト、オーディオ、画像、および／またはプロシージャなど）に準拠するデータアイテムを、呼と同時に送信することができる。
【０００５】
前述の態様、および本発明に付随する利点の多くは、添付の図面と共に後続の詳細な説明を参照することによってよりよく理解され、より容易に認識されるようになるであろう。
【発明を実施するための最良の形態】
【０００６】
本発明の態様は、送信側クライアントから受信側クライアントにデータアイテムを送信するためのソフトウェアシステムを対象とする。例えば、通信チャネルを介して呼データと同時にデータアイテムを送信して、呼への当事者が通信できる方法を向上させることができる。本発明をＩＰ電話環境との関連で述べるが、本発明は、オーディオを含むどんなタイプのデジタルデータ交換にも等しく適用可能である。したがって、開示する実施形態および実施例は本質的に例示であり、限定として解釈すべきではない。
【０００７】
図１を参照すると、様々な「ＶｏＩＰクライアント」間でＩＰ電話サービスを提供するためのＩＰ電話環境１００のブロック図が示されている。本明細書において「ＶｏＩＰクライアント」または「クライアント」は、個人、組織、アプリケーション（ＢＯＴ）、ガジェット、またはエージェント、会社など、特定のコンタクトポイント（contact point）と、１つまたは複数の関連するＶｏＩＰデバイスと、固有のＶｏＩＰクライアント識別子とを指す。例えば、単一の個人、５つの関連ＶｏＩＰデバイス、および固有ＶｏＩＰクライアント識別子が、集合的にＶｏＩＰクライアントを構成することができる。同様に、５００人の個人および１０００個を超える関連ＶｏＩＰデバイスを含む企業もまた、集合的にＶｏＩＰクライアントと呼ぶことができ、このＶｏＩＰクライアントは、固有ＶｏＩＰクライアント識別子によって識別することができる。さらに、ＶｏＩＰデバイスは複数のＶｏＩＰクライアントに関連することができる。例えば、各自が別々のＶｏＩＰクライアントに関連している３人の異なる個人が住む住居に位置する１台のコンピュータ（ＶｏＩＰデバイス）は、３つのＶｏＩＰクライアントそれぞれに関連することができる。デバイスの組合せにかかわらず、固有ＶｏＩＰクライアント識別子を音声システム内で使用して、ＶｏＩＰクライアントのコンタクトポイントと連絡を取ることができる。
【０００８】
一般的に述べると、ＩＰ電話環境１００は、インターネット、イントラネットネットワーク、ワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）などのＩＰデータネットワーク１０８を含むことができる。ＩＰ電話環境１００はさらに、ＶｏＩＰまたは他のデータ交換サービスをＶｏＩＰクライアント１２４、１２５、１３４に提供するＶｏＩＰサービスプロバイダ１２６、１３２を含むことができる。ＶｏＩＰ通話（call conversation）は、音声情報、メディア情報、および／またはコンテキスト情報に対応するデータパケットのストリームとして交換することができる。後でより詳細に説明するが、コンテキスト情報は、ＶｏＩＰ会話、会話で使用されているデバイス、接続されたＶｏＩＰクライアントのコンタクトポイント、および／または、コンタクトポイントによって識別される個人（例えば企業の従業員）に関係する、メタデータ（情報の情報）を含む。さらに、コンテキスト情報は、電子文書やグラフィカル表現などのデータアイテム、データアイテムをクライアントデバイス上で利用可能にするための命令、および／または、クライアントデバイスから利用可能な機能にアクセスするためのデータアイテムを含むこともできる。
【０００９】
ＩＰ電話環境１００はまた、第三者（third party）ＶｏＩＰサービスプロバイダ１４０を含むことができる。ＶｏＩＰサービスプロバイダ１２６、１３２、１４０は、着信呼フィルタリング、テキストデータ、音声とメディアデータの統合、および統合データの伝送など、様々な通話機能を、ＶｏＩＰ通話の一部として提供することができる。ＶｏＩＰクライアント１０４、１２４、１２５、１３４は、データアイテムの受信とクライアントデバイスから提供される機能の公開とに関する規則および選好に関係する情報を、作成し、維持し、提供することができる。加えて、ＶｏＩＰサービスプロバイダ１２６、１３２、１４０もまた、呼接続が確立された個人（１人または複数）に応じた様々な選好のメタデータ情報の別個のセットを作成し、維持し、提供することができる。
【００１０】
ＶｏＩＰサービスプロバイダ１３２は、社内ＬＡＮ１３６などのプライベートネットワークに結合させることができ、社内ＬＡＮ１３６に通信可能に接続されたいくつかのＶｏＩＰクライアント１３４に、ＩＰ電話サービス（例えばプライベートネットワーク内の内部通話、プライベートネットワーク外の外部通話など）およびマルチメディアデータサービスを提供する。同様に、ＶｏＩＰサービスプロバイダ１２６などのＶｏＩＰサービスプロバイダは、インターネットサービスプロバイダ（ＩＳＰ）１２２に結合することができ、ＩＳＰ１２２のクライアントにＩＰ電話サービスおよびＶｏＩＰサービスを提供する。
【００１１】
一実施形態では、１つまたは複数のＩＳＰ１０６、１２２は、ＶｏＩＰクライアント１０４、１２４、１２５がインターネットを介して確立された会話チャネルを維持できるように、ＶｏＩＰクライアント１０４、１２４、１２５にインターネットアクセスを提供するよう構成されてよい。ＩＳＰ１０６、１２２に接続されたＶｏＩＰクライアント１０４、１２４、１２５は、有線および／または無線の通信回線を使用することができる。さらに、各ＶｏＩＰクライアント１０４、１２４、１２５、１３４は、ＰＳＴＮ１１２または構内交換機（ＰＢＸ）１１３を介してＰＯＴＳ（Ｐｌａｉｎ  Ｏｌｄ  Ｔｅｌｅｐｈｏｎｅ  Ｓｅｒｖｉｃｅ）１１５と通信することもできる。ＰＳＴＮゲートウェイなどのＰＳＴＮインタフェース１１４が、ＰＯＴＳ／ＰＳＴＮとＩＰデータネットワーク１０８との間のアクセスを提供することができる。ＰＳＴＮインタフェース１１４は、ＶｏＩＰデータパケットをＰＳＴＮ用の回路交換音声トラフィックに、またその逆に変換することができる。ＰＳＴＮ１１２は、固定電話（land line）デバイス１１６、モバイルデバイス１１７などを含むことができる。
【００１２】
固定電話１１６などの従来型音声デバイスが、ＶｏＩＰクライアントとの接続を要求することができ、ＶｏＩＰクライアントに関連する適切なＶｏＩＰデバイスが選択されて、従来型音声デバイスとの呼接続が確立されることになる。一実施例では、ＶｏＩＰクライアントに関連する個人は、様々な条件に基づいて、呼を接続する際にどのデバイスが使用されるかを指定することができる（例えば発呼側や時刻などに基づく接続）。さらに、個人は、使用されているデバイスが与えられた場合に、どのタイプのデータアイテムを会話チャネル上で送信できるかを識別することもできる。例として、例えば帯域幅の限られた接続（例えばワイヤレス電話機）を利用するクライアントデバイスにはメモリ集約型データアイテム（例えば画像、ビデオなど）が直接送信されないように、制限を制定することができる。
【００１３】
環境１００における上述した構成は、例に過ぎないことを理解されたい。様々なＶｏＩＰエンティティを含む任意の適した構成を環境１００の一部とすることができることは、当業者には理解されるであろう。例えば、ＬＡＮ１３６に結合されたＶｏＩＰクライアント１３４は、ＶｏＩＰサービスプロバイダ１３２またはＩＳＰ１０６、１２２を使用して、あるいは使用せずに、他のＶｏＩＰクライアント１０４、１２４、１２５、１３４と通信できるものとすることができる。さらに、ＩＳＰ１０６、１２２もまた、そのクライアントにＶｏＩＰサービスを提供することができる。
【００１４】
次に、図２を参照すると、本発明の一実施形態による、いくつかのＶｏＩＰデバイスと固有クライアント識別子とを含む例示的なＶｏＩＰクライアント２００を示すブロック図が示されている。各ＶｏＩＰデバイス２０２、２０４、２０６は、音声メッセージ、アドレス帳、クライアントによって指定された規則、データアイテムを着信呼または発信呼と同時に受信することに関する制限および選好、ならびに／あるいは、クライアントデバイスから利用可能な機能を公開するための規則、着信呼に関係する優先度情報などを維持するのに使用される、記憶装置を備えることができる。別法としてまたはこれに加えて、例えばサービスプロバイダによって維持される、ＶｏＩＰクライアントに関係する情報を含む別個の記憶装置が、ＶｏＩＰクライアントに関連することができ、各ＶｏＩＰデバイスによってアクセス可能とすることができる。一実施形態では、ワイヤレス電話機２０２、ＩＰ電話機２０４、または、適切なＶｏＩＰアプリケーションを備えたコンピュータ２０６など、任意の適したＶｏＩＰデバイスを、ＶｏＩＰクライアント２００の一部とすることができる。ＶｏＩＰクライアント２００はまた、１つまたは複数の固有クライアント識別子２０８を維持する。固有クライアント識別子（１つまたは複数）２０８は、一定であってもよく、時の経過と共に変化してもよい。例えば、固有識別子（１つまたは複数）２０８は、呼ごとに変化することができる。固有クライアント識別子を使用して、クライアントを識別し、ＶｏＩＰクライアントに関連するコンタクトポイント２１０と接続する。固有クライアント識別子は、ＶｏＩＰクライアントに含まれる各ＶｏＩＰデバイス上で維持することができ、かつ／または、ＶｏＩＰクライアントに含まれる各ＶｏＩＰデバイスとの関連を含むサービスプロバイダによって維持することができる。固有クライアント識別子がサービスプロバイダによって維持される場合、サービスプロバイダは、関連する各ＶｏＩＰデバイスに関する情報と、入来した通信のためにどのデバイス（１つまたは複数）に接続すべきかに関する知識とを含むことができる。代替の一実施形態では、ＶｏＩＰクライアント２００は、複数のクライアント識別子を維持することができる。この実施形態では、呼セッションごとに、固有クライアント識別子を一時的にＶｏＩＰクライアント２００に割り当てることができる。
【００１５】
固有クライアント識別子は、ＰＳＴＮにおける電話番号と同様に使用することができる。しかし、通常の電話番号をダイヤルして家庭電話機などの特定ＰＳＴＮデバイスに電話する代わりに、固有クライアント識別子を使用して、個人または会社など、ＶｏＩＰクライアントに関連するコンタクトポイントと連絡を取る。クライアントの構成に基づいて、適切なデバイス（１つまたは複数）が接続されて、コンタクトポイントと連絡を取ることになる。一実施形態では、ＶｏＩＰクライアントに含まれる各ＶｏＩＰデバイスは、ネットワークにおけるそれ自体の物理アドレス、または固有デバイス番号を有することもできる。例えば、個人がパーソナルコンピュータ（ＶｏＩＰデバイス）を使用してＰＯＴＳクライアントに電話をかける場合、ＶｏＩＰクライアント識別番号はパーソナルコンピュータのＩＰアドレスと共に、最終的に、ＰＳＴＮ中で認識可能な電話番号に変換されることになる。
【００１６】
図３は、１つまたは複数のＶｏＩＰクライアントに関連することができ、本発明の実施形態で使用することができるＶｏＩＰデバイス３００のブロック図である。ＶｏＩＰデバイス３００は、例として述べることに留意されたい。他の様々なコンポーネントを備える任意の適したデバイスを、本発明の実施形態において使用できることは理解されるであろう。ＶｏＩＰサービスを利用するために、ＶｏＩＰデバイス３００は、様々なタイプのデータパケットを受信し、送信し、処理するのに適したコンポーネントを備えることができる。例えば、ＶｏＩＰデバイス３００は、マルチメディア入出力コンポーネント３０２およびネットワークインタフェースコンポーネント３０４を備えることができる。マルチメディア入出力コンポーネント３０２は、マルチメディアデータ（オーディオ、ビデオなどを含む）、ユーザバイオメトリクス、テキスト、アプリケーションファイルデータなどを入力および／または出力するように構成されてよい。マルチメディア入出力コンポーネント３０２は、マイクロホン、ビデオカメラ、表示画面、キーボード、ユーザ生体認識デバイスなど、任意の適したユーザ入出力コンポーネントを含むことができる。マルチメディア入出力コンポーネント３０２はまた、ネットワークインタフェースコンポーネント３０４を介してマルチメディアデータを送受信することもできる。ネットワークインタフェースコンポーネント３０４は、イーサネット（登録商標）インタフェース、フレームリレーインタフェース、ケーブルインタフェース、ＤＳＬインタフェース、トークンリングインタフェース、無線周波数（エアインタフェース）などのインタフェースをサポートすることができる。ＶｏＩＰデバイス３００は、読取専用メモリデバイス（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ハードドライブ、光学ドライブなどの永続的および／または取外し可能な記憶装置を含む、ハードウェアコンポーネント３０６を備えることができる。記憶装置は、オペレーティングシステムおよび／あるいは１つまたは複数のアプリケーションの動作を制御するためのプログラム命令を記憶するように構成されてよく、また、デバイスが含まれるＶｏＩＰクライアントに関連する個人に関係するコンテキスト情報（例えば音声プロファイル）を記憶するように構成されてよい。一実施形態では、ハードウェアコンポーネント３０６はＶｏＩＰインタフェースカードを含むことができ、ＶｏＩＰインタフェースカードは、非ＶｏＩＰクライアントデバイスがＶｏＩＰ会話を送受信できるようにする。
【００１７】
デバイス３００はさらに、デバイス３００の動作のためのソフトウェアアプリケーションコンポーネント３１０、および、様々なＶｏＩＰサービスをサポートするためのＶｏＩＰサービスアプリケーションコンポーネント３０８を備えることができる。ＶｏＩＰサービスアプリケーションコンポーネント３０８は、データパケットアセンブラ／ディスアセンブラアプリケーション、構造化階層解析アプリケーション、オーディオコーダ／デコーダ（ＣＯＤＥＣ）、ビデオＣＯＤＥＣなどのアプリケーション、ならびに、ＶｏＩＰおよび他のサービスを提供するための他の適したアプリケーションを含むことができる。ＣＯＤＥＣは、音声プロファイルを使用して、入来オーディオをフィルタにかけ、改善することができる。
【００１８】
図４を参照すると、本発明の一実施形態による、会話チャネルを介した２つの異なるＶｏＩＰクライアントのＶｏＩＰデバイス間の会話フロー４００を示すブロック図が示されている。接続セットアップ段階の間、第１のＶｏＩＰクライアント４０６のＶｏＩＰデバイスが、第２のＶｏＩＰクライアント４０８との会話チャネルを開始するよう要求する。例示的な一実施形態では、第１のＶｏＩＰクライアント４０６に対するＶｏＩＰサービスプロバイダ４０２（プロバイダ１）が、会話チャネルを開始する要求を受信し、この要求を第２のＶｏＩＰクライアント４０８に対するＶｏＩＰサービスプロバイダ４０４（プロバイダ２）に転送する。この実施例では２つのＶｏＩＰサービスプロバイダおよび２つのＶｏＩＰクライアントを利用するが、任意の数および組合せのＶｏＩＰクライアントおよび／またはサービスプロバイダを本発明の実施形態において使用することができる。例えば、接続を確立する際にサービスプロバイダを１つだけ利用してもよい。さらに別の実施例では、ＶｏＩＰデバイス間の通信は、公衆およびプライベートの回線を利用して直接的であってよく、それによりＶｏＩＰサービスプロバイダの必要をなくすことができる。ピアツーピアのコンテキストにおいても、ＶｏＩＰデバイス間の通信は、どんなサービスプロバイダも関与せずに、直接的であってよい。
【００１９】
ＶｏＩＰクライアント、ＶｏＩＰデバイス、および／またはＶｏＩＰサービスプロバイダ、あるいは他のＶｏＩＰエンティティの間で情報を交換する際に使用するために選択することのできるプロトコルには、様々なものがある。例えば、セッション開始プロトコル（ＳＩＰ）がシグナリングプロトコルに選択された場合は、セッション制御情報およびメッセージはＳＩＰシグナリングパス／チャネルを介して交換されることになり、メディアストリームはリアルタイムトランスポートプロトコル（ＲＴＰ）パス／チャネルを介して交換されることになる。考察の目的で、本明細書において通信チャネルは一般に、任意のタイプのデータまたは信号交換パス／チャネルを指す。したがって、プロトコルに応じて、接続セットアップ段階および接続終了段階は、会話フロー４００中で追加のステップを必要とする場合があることは理解されるであろう。
【００２０】
説明を容易にするために、第１のＶｏＩＰクライアント４０６と第２のＶｏＩＰクライアント４０８の両方が、それぞれＶｏＩＰデバイスを１つだけ含む実施例を利用する。したがって、本明細書の説明では、２つのＶｏＩＰデバイスの接続に言及する。第１のＶｏＩＰクライアント４０６のデバイスを使用する個人は、電話をかける相手側クライアントの固有クライアント識別子を選択し、または入力することができる。プロバイダ１  ４０２は、第１のＶｏＩＰクライアント４０６のデバイスからの要求を受信し、要求に含まれる固有クライアント識別子に基づいて、終端サービスプロバイダ（例えば、第２のＶｏＩＰクライアント４０８のプロバイダ２  ４０４）を決定する。次いで、要求はプロバイダ２  ４０４に転送される。この呼の開始は、第２のＶｏＩＰクライアントのデバイスに転送されることになる。次いで、第１のＶｏＩＰクライアント４０６のデバイスと第２のＶｏＩＰクライアント４０８のデバイスとの間の会話チャネルを確立することができる。図８Ａを参照して後でさらに詳細に述べるが、通信チャネルが確立されると、すぐにデータアイテムを送信することができる。結果として、個人は、呼を受信したときにデータアイテムを受信することができる。さらに、通信チャネルが確立されてから通信チャネルが終了するまでのどの時点でも、クライアントデバイスを使用してデータアイテムを交換することができる。
【００２１】
例示的な一実施形態では、第１のＶｏＩＰクライアント４０６と第２のＶｏＩＰクライアント４０８のデバイスがデータパケットの交換を開始する前に、コンテキスト情報を交換することができる。後でより詳細に論じるが、コンテキスト情報は、会話に関連する事前定義済みの構造に従ってパケット化することができる。第１のＶｏＩＰクライアント４０６に関連する任意のデバイス、第１のＶｏＩＰクライアント４０６のサービスプロバイダ、または異なるデバイス／サービスプロバイダが、コンテキスト情報の内容に基づいてこの構造を決定することができる。一実施形態では、交換されるコンテキスト情報は、発呼側ＶｏＩＰクライアント４０６、デバイス、および被呼側ＶｏＩＰクライアント４０８に関係する情報を含むことができる。例えば、被呼側ＶｏＩＰクライアント４０８から送信されるコンテキスト情報は、ＶｏＩＰクライアント４０６を含む様々な潜在的な発呼側ＶｏＩＰクライアントからの着信呼の優先度リスト、データアイテムを交換するためおよびＶｏＩＰクライアントから利用可能な機能にアクセスするための規則および選好などを含むことができる。
【００２２】
利用可能なメディアタイプ、発呼側クライアントおよび被呼側クライアントの規則、ならびに様々なデータアイテムもまた、接続セットアップ段階の間に交換されるコンテキスト情報の一部とすることができる。コンテキスト情報は、コンテキスト情報の性質に応じて、第１のＶｏＩＰクライアント４０６のデバイスの１つ、第２のＶｏＩＰクライアント４０８のデバイスの１つ、ならびに／またはＶｏＩＰサービスプロバイダ（例えばプロバイダ１  ４０２およびプロバイダ２  ４０４）によって処理し、収集することができる。一実施形態では、ＶｏＩＰサービスプロバイダ４０２、４０４は、コンテキスト情報を転送する前に、何らかの情報をクライアントのコンテキスト情報に追加すること、および／またはクライアントのコンテキスト情報から削除することや、入来または送出コンテキスト情報に対するフィルタリングを実施することなどができる。
【００２３】
会話チャネルを開始する要求に応答して、第２のＶｏＩＰクライアント４０８は、会話チャネルを確立するためにこの要求を受諾することができ、あるいは、この要求を拒否することや、データアイテムなどのコンテキスト情報がプロバイダ２  ４０４によって「バッファリング」されるようにすることなど、他の適切なアクションを実行することができる。適切なアクションは、得られたコンテキスト情報に基づいて決定することができる。会話チャネルが確立されると、第１のＶｏＩＰクライアント４０６のデバイスおよび第２のＶｏＩＰクライアント４０８のデバイスは、データパケットを交換することによって相互に通信することを開始する。より詳細に述べるように、会話データパケットおよびコンテキストデータパケットを含むデータパケットが、接続されたデバイス間で、確立された会話チャネルを介して通信される。
【００２４】
会話データパケットは、会話に関係するデータ、例えば音声データパケットまたはマルチメディアデータパケットを搬送する。コンテキストデータパケットは、会話データ以外のデータに関係する情報を搬送する。会話チャネルが確立されると、第１のＶｏＩＰクライアント４０６と第２のＶｏＩＰクライアント４０８のいずれかが、会話チャネルを終了するよう要求することができる。さらに、クライアント４０６と４０８のいずれかが、通話中に、会話に関係のないデータアイテムなど、追加のコンテキスト情報を送信するコマンドを生成することができる。いくらかのコンテキスト情報は、終了後に第１のＶｏＩＰクライアント４０６と第２のＶｏＩＰクライアント４０８との間で交換することができる。
【００２５】
図５は、本発明の一実施形態による、通信（会話）チャネルを介して使用されるデータパケット構造５００のブロック図である。データパケット構造５００は、会話データ（例えば音声、マルチメディアデータなど）またはコンテキストデータ（例えばＶｏＩＰサービスに関係する情報など）の搬送に利用するのに適したＩＰデータパケットのためのデータパケット構造とすることができる。しかし、他の任意の適したデータ構造を利用して、会話データまたはコンテキストデータを搬送することができる。データパケット構造５００は、ヘッダ５０２およびペイロード５０４を含む。ヘッダ５０２は、対応するデータパケットを宛先に送達するのに必要な情報を含むことができる。加えて、ヘッダ５０２は、会話の過程で利用される情報を含むことができる。このような情報は、会話（例えば通話）を識別するための会話ＩＤ５０６、被呼側クライアントの固有クライアント識別子などの宛先ＩＤ５０８、ソースＩＤ５１０（発呼側クライアントの固有クライアント識別子、またはデバイス識別子）、ペイロードのタイプ（例えば会話またはコンテキスト）を識別するためのペイロードＩＤ５１２、会話データの関係する個人を識別するための個人ＩＤ（図示せず）などを含むことができる。代替の一実施形態では、ヘッダ５０２は、インターネットプロトコルバージョンおよびペイロード長に関する情報を特に含むことができる。ペイロード５０４は、識別された会話に関係する会話データまたはコンテキストデータを含むことができる。当業者には理解されるであろうが、ＴＣＰヘッダやＵＤＰヘッダなどの上位層ヘッダのために、追加のヘッダを使用することもできる。
【００２６】
本発明の一実施形態では、ＶｏＩＰ会話チャネルを介してコンテキスト情報を通信するために、構造化された階層を事前定義することができる。コンテキスト情報は、ＶｏＩＰクライアント、ＶＣＤデバイス、会話チャネル接続（例えば呼基本（call basics））、会話コンテキスト（例えば呼コンテキスト）などに関係する任意の情報を含むことができる。より具体的には、コンテキスト情報は、クライアント選好、ＶｏＩＰクライアントから利用可能な機能にアクセスするための規則を含むクライアント規則、データアイテムの送受信に対する制限、クライアントの位置（例えばユーザ位置、デバイス位置など）、バイオメトリクス情報、クライアントの機密情報、ＶｏＩＰデバイスの機能、ＶｏＩＰサービスプロバイダ情報、メディアタイプ、メディアパラメータ、発呼番号優先度、キーワード、アプリケーションファイルに関係する情報などを含むことができる。コンテキスト情報は、コンテキストデータの性質に応じて、各ＶｏＩＰクライアントおよび／またはＶｏＩＰサービスプロバイダで処理し、収集することができる。一態様では、ＶｏＩＰサービスプロバイダは、コンテキスト情報を転送する前に、ＶｏＩＰクライアントのコンテキストデータを追加し、修正し、および／または削除することができる。例えば、クライアントの機密情報は、このような情報が送信されるのをクライアントが許可しない限り、このクライアントに関連するＶｏＩＰサービスプロバイダによって削除されることになる。場合によっては、最小限の量のコンテキスト情報を交換するか、あるいはコンテキスト情報を全く交換しないこともできる。
【００２７】
図６を参照すると、本発明の一実施形態による、コンテキスト情報を転送するための、２つのＶｏＩＰクライアント間の対話を示すブロック図６００が示されている。図４と同様に、ここで述べる実施例では、各クライアントにデバイスが１つだけ関連しており、この２つのデバイス間で接続が行われるシナリオを利用する。一実施形態では、ＶｏＩＰクライアント６０６とＶｏＩＰクライアント６０８のデバイスが、ＶｏＩＰ会話チャネルを確立済みである。あるコンテキスト情報をＶｏＩＰクライアント６０６によって搬送するのにどの構造化階層が使用されることになるかを識別することができる。識別された構造化階層に関する情報は、どの構造化階層がコンテキスト情報の搬送に使用されるか、どのように構造化階層を識別するかなどに関する情報を含むことができる。このような情報は、対応するコンテキスト情報が交換される前にＶｏＩＰクライアント６０６とＶｏＩＰクライアント６０８との間で交換されることになる。ＶｏＩＰクライアント６０８は、どの構造化階層がコンテキスト情報の搬送に使用されるかに関する情報を受信すると、事前定義済みの構造化階層（例えばＸＭＬ名前空間など）を調べて、識別された構造化階層を選択する。一実施形態では、事前定義済みの構造化階層は、ＶｏＩＰクライアントのグループからアクセス可能な集中化された位置で、大域的に記憶し、管理することができる。この実施形態では、集中化された位置のユニフォームリソース識別子（ＵＲＩ）アドレスを、ＶｏＩＰクライアント６０６からＶｏＩＰクライアント６０８に送信することができる。
【００２８】
別の実施形態では、各ＶｏＩＰクライアントは、任意のデバイスのローカル記憶装置に、またはすべてのデバイスが共有できる専用ローカル記憶装置に記憶された、事前定義済みの構造化階層のセットを有することができる。これらの事前定義済みの構造化階層は、コンテキスト情報が交換される前にＶｏＩＰクライアント間で宣言し、同意することができる。このようにすれば、コンテキストデータパケットの構造を提供する必要をなくすことができ、したがって、コンテキストデータに対応する送信データパケットの量が削減される。さらに、事前定義済みの構造化階層を利用することにより、ハードウェアおよび／またはソフトウェアから独立した方式でデータパケットを送信することができる。
【００２９】
識別された構造化階層を取り出すと、ＶｏＩＰクライアント６０８は、データストリームに対応するデータパケットが、識別された構造化階層に従って定義されているような、データストリームの受信を予期している。ＶｏＩＰクライアント６０６は、識別された構造化階層に従って表されたコンテキスト情報の送信を開始することができる。一実施形態では、ＶｏＩＰクライアント６０８は、コンテキスト情報に関してデータバインディングプロセスを開始する。例えば、受信したコンテキスト情報を使用して、識別された構造化階層のインスタンスを構築することができる。
【００３０】
図７を参照すると、本発明の一態様による、様々なサービスプロバイダを介してコンテキスト情報を収集し、転送するための、いくつかのＶｏＩＰエンティティ間の対話を示すブロック図７００が示されている。一実施形態では、コンテキスト情報を送信側と受信側との間で交換することができる。本明細書に述べる送信側は、対応する構造化階層に基づいて表されたコンテキスト情報のセットを収集し、送信することのできる任意のＶｏＩＰエンティティ（例えばクライアント、デバイス、サービスプロバイダ、第三者サービスプロバイダなど）とすることができる。同様に、本明細書に述べる受信側は、コンテキスト情報のセットを送信側に要求することのできる任意のＶｏＩＰエンティティとすることができる。この実施形態では、ＶｏＩＰエンティティは、任意の所与のコンテキスト情報交換において送信側と受信側のいずれにもなる可能性がある。
【００３１】
例示的な一実施形態では、第三者サービスプロバイダ６１０が、ＶｏＩＰサービスプロバイダ６０２、６０４から、ＶｏＩＰクライアント６０６、６０８のコンテキスト情報を受信することができる。説明のために、各クライアントにはデバイスが１つだけ関連し、この２つのデバイス間で接続が行われると仮定する。加えて、ＶｏＩＰクライアント６０６は、ＶｏＩＰサービスプロバイダとしてプロバイダ１  ６０２を有し、追加のＶｏＩＰサービスのために第三者プロバイダ６１０が利用可能である。この実施例では２つのＶｏＩＰサービスプロバイダおよび２つのＶｏＩＰクライアントを利用するが、任意の数および組合せのＶｏＩＰクライアントおよび／またはサービスプロバイダを本発明の実施形態において使用することができる。一実施形態では、ＶｏＩＰクライアント６０６およびＶｏＩＰクライアント６０８のデバイスは、プロバイダ１  ６０２およびプロバイダ２  ６０４を介して会話チャネルを確立済みである。
【００３２】
ＶｏＩＰ会話の間、プロバイダ２  ６０４は、ＶｏＩＰクライアント６０８から得られることになるコンテキスト情報を識別することができる。ＶｏＩＰクライアント６０８は、識別されたコンテキスト情報を収集し、識別されたコンテキスト情報を搬送するのに使用されることになる構造化階層を識別する。収集されたコンテキスト情報は、ＶｏＩＰクライアント６０８からプロバイダ２  ６０４に送信される。このコンテキスト情報送信では、プロバイダ２  ６０４は受信側であり、ＶｏＩＰクライアント６０８は送信側である。プロバイダ２  ６０４は、受信したコンテキスト情報の全部または一部を記憶することや、コンテキスト情報をフィルタにかけることなどができる。さらに、プロバイダ２  ６０４は、必要ならより多くの情報を収集し、この情報に基づいて、受信したコンテキスト情報を更新することもできる。一実施形態では、プロバイダ２  ６０４は、課金情報やレートなど、ＶｏＩＰクライアント６０８に提供されるサービスに関係するサービスプロバイダ情報を追加することができる。同様に、プロバイダ２  ６０４は、受信したコンテキスト情報からコンテキストデータを削除し、および／または修正することもできる。
【００３３】
例示的な一実施形態では、識別された構造化階層に関する情報もまた、プロバイダ２  ６０４に送信される。識別された構造化階層に関する情報は、どの構造化階層がコンテキスト情報の搬送に使用されるか、どのように構造化階層を識別するかなどに関する情報を含むことができる。プロバイダ２  ６０４は、識別された構造化階層に関する情報およびコンテキスト情報をプロバイダ１  ６０２に送信する。この実施例では、プロバイダ２  ６０４はコンテキスト情報の送信側であり、プロバイダ１  ６０２は受信側である。プロバイダ１  ６０２は、必要ならより多くの情報を収集し、受信したコンテキスト情報を更新することができる。さらに、プロバイダ１  ６０２は、受信したコンテキスト情報をＶｏＩＰクライアント６０６に転送する前に、コンテキストデータを追加し、削除し、および／または修正することもできる。プロバイダ１  ６０２は、コンテキスト情報をＶｏＩＰクライアント６０６に送信する。同様に、ＶｏＩＰクライアント６０６はさらに、コンテキスト情報を収集し、プロバイダ１  ６０２およびプロバイダ２  ６０４を介して、収集したコンテキスト情報および対応する構造化階層情報をＶｏＩＰクライアント６０８に送信することができる。
【００３４】
後でより詳細に論じるが、ＶｏＩＰエンティティは、ほぼ同時に送信側と受信側の両方になり得ることを理解されたい。例えば、プロバイダ１  ６０２はまた、コンテキスト情報の第１のセットをＶｏＩＰクライアント６０６から受信すると共に、ＶｏＩＰクライアント６０８に関係するコンテキスト情報の第２のセットをプロバイダ２  ６０４から受信することもできる。コンテキスト情報を受信すると、プロバイダ１  ６０２は、コンテキスト情報の第１のセットをプロバイダ２  ６０４に送信すると共に、コンテキスト情報の第２のセットをプロバイダ２  ６０４から受信する。同様に、ＶｏＩＰクライアント６０６、６０８は、それらのサービスプロバイダからコンテキスト情報を受信すると共に、それらのサービスプロバイダにコンテキスト情報を送信することができる。したがって、会話の前、最中、および後に、ＶｏＩＰエンティティ（例えばプロバイダ１  ６０２、ＶｏＩＰクライアント６０６、プロバイダ２  ６０４、ＶｏＩＰクライアント６０８）の間で、双方向通信チャネルを介してコンテキスト情報が継続的に交換されることになることが企図される。
【００３５】
一実施形態では、プロバイダ１  ６０２は、識別された構造化階層に関する情報およびコンテキスト情報をＶｏＩＰクライアント６０６に送信する。前述のように、ＶｏＩＰクライアント６０６はさらに、識別された構造化階層に従って、受信したコンテキスト情報を処理する。例えば、ＶｏＩＰクライアント６０６は、識別された構造化階層に関する情報を受信すると、事前定義済みの構造化階層を調べて、コンテキスト情報に対する識別された構造化階層を選択する。
【００３６】
一実施形態では、構造化階層は、拡張可能マークアップ言語（ＸＭＬ）によって定義することができる。しかし、構造化階層は、拡張可能な構造化階層を実装し、維持するのに適した任意の言語によって定義できることを理解されたい。一般的に述べると、ＸＭＬは、プラットフォーム横断型の、ソフトウェアおよびハードウェアから独立した情報伝送ツールとして周知である。さらに、ＸＭＬは、階層構造化されたノードツリーとしてそのデータを維持し、各ノードは、記述的属性を含むことのできるタグを備える。ＸＭＬはまた、記述されている基礎をなすデータによって決定できる拡張可能なパターンに従うことができることで周知である。通常、ＸＭＬ名前空間が提供されて、この名前空間に固有名が与えられる。場合によっては、名前空間は、名前空間に関するデフォルト情報を含む集中化された位置へのポインタとして使用することができる。
【００３７】
特定の一実施形態では、ＶｏＩＰクライアント６０６は、コンテキスト情報のＸＭＬ名前空間を識別することができる。例えば、ＸＭＬ名前空間属性は、送信要素の開始タグ中に配置することができる。本明細書に示すＸＭＬ名前空間、属性、およびクラスは、本発明の様々な実施形態と共に使用される構造化階層の例として提供するに過ぎないことを理解されたい。ＶｏＩＰクライアント６０８がＸＭＬ名前空間情報を受信した後、ＶｏＩＰクライアント６０６は、識別されたＸＭＬ名前空間に従って定義されたコンテキストデータパケットのセットを、ＶｏＩＰクライアント６０８に送信する。名前空間が要素の開始タグ中で定義されると、同じ接頭辞を有するすべての子要素は、同じ名前空間に関連付けられる。したがって、ＶｏＩＰクライアント６０８およびＶｏＩＰクライアント６０６は、すべての子要素に接頭辞を含めることなくコンテキスト情報を送信することができ、それにより、コンテキスト情報のために送信されるデータパケットの量を削減することができる。
【００３８】
次に図８Ａ〜８Ｂを参照しながら、送信側がデータアイテムをコンテキスト情報として受信側に送信できるようにすることを対象とする本発明の態様について述べる。これに関して、また一実施形態によれば、データアイテムを会話データと同時に送信するコマンドを生成するための制御が提供される。例えば、会議通話の主題がワードプロセッシング文書などの電子文書に関係する場合、会議通話に関与する１人または複数の受信側に文書または文書の更新バージョンを送信する目的で制御をアクティブ化することができる。文書を識別するコンテキスト情報を構造化階層中で識別することができ、それにより、文書を処理して受信側に提示することを可能にする。通話と同時に送信することのできるデータアイテムの具体的な例について以下に述べるが、他のタイプのデータアイテムを送信することもできること、および以下に提供する例は限定ではなく例示として解釈すべきであることを、当業者等なら理解するであろう。
【００３９】
次に図８Ａを参照しながら、例示的なコマンド対処ルーチン８００について述べる。一般的に述べると、コマンド対処ルーチン８００は、選択されたデータアイテムを送信側クライアントが受信側クライアントに送信できるようにする論理を実施する。初期事項として、コマンド対処ルーチン８００は、ＶｏＩＰ環境で呼を送受信する機能、または他の方法で会話データの交換を容易にする機能を提供するアプリケーションプログラム中で実施することができる。例えば、コマンド対処ルーチン８００が実行される前に、発呼側は、アプリケーションプログラムおよび／またはＶｏＩＰデバイスを使用して、１人または複数の受信側との通信チャネルを確立させることができる。
【００４０】
例に過ぎないが、発呼側は、アプリケーションプログラムによって提供される電子「アドレス帳」から、通話に含まれることになる当事者を識別することができる。次いで、通話の当事者が識別されると、ハードウェアまたはソフトウェアベースの制御を使用して呼を開始することができる。これに関して、ＶｏＩＰクライアントは、様々なデバイスを使用して、通信チャネルを介してデータを送受信することができる。アプリケーションプログラムは、デバイス間の通信を管理し、向上した機能をデバイスに提供するように、構成されてよい。これに関して、送信側は、例えばＶｏＩＰ対応電話機に通信可能に接続されたパーソナルコンピュータからなる機能豊富なＶｏＩＰクライアントを使用することができる。送信側は、通話に含まれることになる当事者を識別し、アプリケーションプログラムから利用可能にされた１つまたは複数のソフトウェア制御（例えばボタン、メニュー項目など）をアクティブ化することによって呼を開始することができる。通信チャネルが確立されると、ＶｏＩＰ電話機を使用して会話データを入力し、受信することができる。別法として、ＶｏＩＰ電話機から利用可能なハードウェア制御（例えばダイヤルパッド）を使用して呼を開始することもできる。この例が示すように、本発明の態様は、任意の数の異なるデバイス構成および機能を有するＶｏＩＰクライアント中で適用することができる。
【００４１】
一実施形態では、アプリケーションプログラムから利用可能な制御により、送信側は、呼が開始したときにデータアイテムを識別して送信することができる。例えば、アプリケーションプログラムは、呼が開始したときに受信側に送信されることになるデータアイテムを送信側が識別できるように、ファイルシステムまたはネットワーク位置を閲覧する機能を提供することができる。さらに、後でさらに詳細に述べるが、パッケージ済みデータアイテムをアプリケーションプログラム内で選択することもできる。いずれの場合でも、呼が開始するのに伴って、任意の数の異なるタイプのデータアイテムを識別して送信することができる。後でさらに詳細に述べるが、呼と同時に送信されるデータアイテムは、オーディオ、テキスト、画像、および／またはプロシージャなどを含む任意の数の異なるフォーマットのものとすることができる。さらに、データアイテムが受信されたとき、データアイテムが受信側に利用可能になるようにコンテキスト情報に対して処理を実施することができる。例えば、呼が開始されたときに送信側がワードプロセッシング文書を送信する場合、受信側クライアントから利用可能なアプリケーションプログラムを構成して、呼が受信されたときに受信コンテキスト情報を処理して自動的にワードプロセッシング文書を提示するようにすることができる。
【００４２】
図８Ａに示すように、コマンド対処ルーチン８００はブロック８０２で開始し、ブロック８０４で、通話で使用されているクライアント間でコンテキスト情報のセットが交換される。一実施形態では、また前述のように、コンテキスト情報は、ＸＭＬ名前空間に従って定義された構造化階層として交換することができる。さらに、初期セットアップ段階の間に（ブロック８０４で）コンテキスト情報がこのようにして交換されるだけでなく、コンテキスト情報は、初期セットアップ段階の後の通話中にも、または通話終了後にも交換することができる。コマンド対処ルーチン８００に関して述べる例示的な実施形態は、２つのクライアント間で行われる対話に焦点を合わせているが、ルーチン８００は、３つ以上のクライアントまたは他のＶｏＩＰエンティティが呼に参与しているとき（例えば会議通話）にも等しく適用可能である。
【００４３】
送信側と受信側との間の通信チャネルは、任意の数の異なるＶｏＩＰエンティティ（例えばクライアント、クライアントデバイス、サービスプロバイダ、第三者サービスプロバイダなど）にわたって確立できることを、よく理解されたい。言い換えれば、ブロック８０４で送信側および受信側に関連するクライアント間で交換されるコンテキスト情報は、コンテキスト情報を転送する１つまたは複数の介在ＶｏＩＰエンティティによって受信される場合がある。したがって、ブロック８０４で交換されるコンテキスト情報は、適切なクライアントにおいて受信される前に、複数回転送される場合がある。
【００４４】
ブロック８０６で、コマンド対処ルーチン８００は、送信側から受信側にデータアイテムを送信するコマンドが受け取られるまで、遊休状態に留まる。前述のように、本発明の態様では、送信側は、呼が開始されたときにデータアイテムを選択して送信することができる。同様に、送信側はまた、通話の進行中にもデータアイテムを選択して受信側に送信するようにすることができる。例えば、会議通話への当事者は、呼が開始されたときに電子文書を受信し、呼の最中に文書を更新し、後で文書の更新バージョンを１人または複数の受信側に送信することができる。データアイテムを送信するコマンドを受け取ったときにイベントデータを得ることができることを、当業者等なら理解するであろう。後でさらに詳細に述べるが、コマンド対処ルーチン８００によって得られるイベントデータは、とりわけ、コマンドの対象であるデータアイテム、受信側の識別などを識別することができる。一実施形態では、このコマンドは、ブロック８０６で、送信側がコマンドを発行するためにユーザインタフェースと対話したときに生成される。別の実施形態では、送信側は、変数に依存する規則に基づいて自動的にコマンドが生成されるようにすることができる。例えば、送信側は、特定の個人から呼を受信したときに、選択されたデータアイテムを自動的に送信する規則を制定することができる。より一般的には、データアイテムを自動的に送信するための、任意の数の異なるタイプの規則を制定できることを、当業者等なら理解するであろう。
【００４５】
通常、会話データと同時に受信側に送信されるデータアイテムは、呼への当事者から発生する。しかし、データアイテムはまた、呼データを受信して転送する第三者サービスプロバイダなど、任意の介在ＶｏＩＰエンティティから発生する場合もある。これに関して、介在ＶｏＩＰエンティティは、事前定義済みの規則に基づいて通話にコンテキスト情報を追加／削除するように構成されてよい。例えば、介在ＶｏＩＰエンティティは、呼に関与する当事者に緊急情報を含む「ブロードキャストメッセージ」が入手可能になるようにするために、追加のコンテキスト情報が既存の通信チャネルを介して送信されるようにすることができる。さらに、介在ＶｏＩＰエンティティが他のタイプのコンテキスト情報を追加／削除することが望ましいであろう他の場合もあることを、当業者等なら理解するであろう。
【００４６】
ハードウェアベースの制御とソフトウェアベースの制御の両方を含む、任意の数の異なる制御を使用して、ブロック８０６で受け取られるコマンドを生成することができる。例えば、ＶｏＩＰ電話機などのデバイスは、送信側が受信側にデータアイテムを送信するのを可能にするハードウェア制御付きで構成されてよい。別の例として、アプリケーションプログラムは、送信側がデータアイテムを選択して送信できるようにするソフトウェアベースの制御を提供することができる。この場合、データアイテムを受信することになる当事者間を送信側が区別できるようにする機能を提供することができる。例えば、一実施形態によれば、選択されない当事者によってデータアイテムが受信されることなく、選択された受信側に送信側がデータアイテムを送信できるようにするソフトウェア制御が提供される。
【００４７】
コマンドが受け取られると、コマンド対処ルーチン８００は、ブロック８０８で、呼セットアップ段階の間に受信されたコンテキスト情報を処理して、受信側クライアントの機能、選好、および規則を評価する。前述のように、呼への当事者は、任意の数の異なるタイプのクライアントを利用する場合があり、各クライアントは、異なるデバイス構成および機能を有する可能性がある。例えば、いくつかの機能豊富なクライアントは、オーディオ、テキスト、画像、および／またはプロシージャを含む（これらに限定されない）、任意の数の異なるフォーマットに準拠するデータアイテムを提示し、または処理することができる。他のクライアントは、より制限されており、例えばオーディオデータしか送受信できない場合がある。受信側によって使用されているクライアントに関連する機能、選好、および規則は、データアイテムがどのように提示されるか、またデータアイテムが提示されるかどうかに影響する場合があるので、クライアントに関連する機能、選好、および規則が識別される。一実施形態によれば、クライアントに関連する機能、選好、および規則は、後で図１２を参照しながらさらに詳細に述べるデバイスタイプクラス９２０中で表されるコンテキスト情報から識別される。
【００４８】
一実施形態では、通話中に、グラフィカル表現および／またはアニメーションのパッケージ済みデータアイテムを送信することができる。例えば、送信側は、本発明により提供される制御を使用して、笑顔、しかめ面、ウィンク、または人間の感情を描いた他の表情を含む（ただしこれらに限定されない）データアイテムのパッケージから、グラフィカル表現および／またはアニメーションを選択することができる。これに関して、呼セットアップ段階で（ブロック８０４で）交換されたコンテキスト情報は、送信側および受信側クライアントから利用可能なデータアイテムのパッケージを識別することができる。一実施形態では、ブロック８０８で実施される処理は、受信側クライアント上でローカルに利用可能なデータアイテムのパッケージを識別することを含む。指定されたデータアイテムが受信側クライアント上でローカルに利用可能な場合は、適切なコマンドの受領に応答して実際のデータアイテムは送信されない。その代わり、受信側クライアントがデータアイテムを呼び戻して提示できるようにする、データアイテムへの参照が送信される。一実施形態では、後で図１０を参照しながらさらに詳細に述べる呼基本クラス９０２によって、会話コンテキストに関係する人間の感情のグラフィカル表現および／またはアニメーションが表される。
【００４９】
別の実施形態では、通話中に、受信側クライアントによって公開されている機能にアクセスするためのパッケージ済みデータアイテムを送信することができる。送信側は、本発明によって提供される制御を使用して、指定されたアクションが受信側クライアント上で行われるようにするためのリモートプロシージャコールを生成することができる。例えば、ワイヤレス電話機など、受信側クライアントに関連するデバイスは、振動する機能、識別されたオーディオファイルを再生することによって呼の着信を示す機能、画像を表示する機能などを維持することができる。デバイスによって提供される機能はプログラミングインタフェースから公開できることを、当業者等なら理解するであろう。一実施形態では、ワイヤレス電話機など、受信側クライアントに関連するデバイスが振動したり、受信したオーディオファイルを再生したり、画像を表示したりなどするようにするリモートプロシージャコールを、送信側クライアントから発行することができる。こうした機能には、呼が開始したときまたは会話データが交換されているときを含む、通信チャネルが確立されているときの任意の時点でアクセスすることができる。これに関して、呼セットアップ段階で（ブロック８０４で）交換されたコンテキスト情報は、受信側クライアントによって公開されている機能を識別することができる。
【００５０】
ブロック８１０で、ブロック８０６で受け取ったコマンドの対象であるデータアイテムに、受信側クライアントからローカルにアクセスできるかどうかが判定される。場合によっては、データアイテムは、受信側クライアント上でローカルに利用可能でないか、あるいは送信側クライアントからしかアクセスできないことがある。例えば、一実施形態では、送信側は、「バックグラウンドミュージック」を提供する目的で、オーディオファイルを呼の中で多重化するコマンドを発行することができる。送信側は、オーディオファイルを識別し、オーディオファイルと呼データとを単一の多重化データストリームの形で送信するための制御を選択する。データアイテムが送信側クライアントからのみ利用可能であるこの場合および他の場合では、ブロック８１０で実施されるテストの結果は「いいえ」であり、コマンド対処ルーチン８００は、後述するブロック８１４に進む。反対に、データアイテムが受信側クライアント上でローカルに利用可能な場合もある。例えば、人間の感情を描いたグラフィカル表現および／またはアニメーション、あるいは他のパッケージ済みデータアイテムならびに関連プロシージャを、複数のクライアントに配信することができる。この場合、選択されたデータアイテムを含むパッケージが受信側クライアントに配信されていれば、データアイテムはローカルに利用可能であると判定される。選択されたデータが受信側クライアント上でローカルに利用可能であるこの場合および他の場合では、ブロック８１０で実施されるテストの結果は「はい」であり、コマンド対処ルーチン８００はブロック８１２に進む。
【００５１】
ブロック８１２で、受信側に利用可能となるデータアイテムを記述するタグが、受信側クライアントに送信されているデータストリームに埋め込まれる。ブロック８１２に到達した場合、送信側によって選択されたデータアイテムに受信側クライアントからローカルにアクセスできると判定されている。この場合、選択されたデータアイテムは送信されないことになる。その代わり、選択されたデータアイテムと関連プロシージャとを記述する「タグ」またはテキストセグメントが、コンテキスト情報として送信側クライアントと受信側クライアントとの間で伝送される。ＸＭＬまたは他の標準化されたフォーマットに準拠するタグを使用して、データアイテムを受信側クライアント上で識別し、提示するセマンティクスを記述できることを、当業者等なら理解するであろう。例えば、ブロック８１２でデータストリームに埋め込まれるタグは、宛先および送信側クライアントのアドレス、処理命令、選択されたデータアイテムの識別などを含むことができる。後でさらに詳細に述べるが、データストリームに埋め込まれたタグを受信すると、データアイテムを受信側に提示する目的でいくつかの命令が実行されるものとすることができる。次いで、コマンド対処ルーチン８００はブロック８１６に進んで終了する。
【００５２】
ブロック８１４で、コマンド対処ルーチン８００は、受信側クライアントに送信されているデータストリームに実際のデータアイテムが含まれるようにする。言い換えれば、ブロック８１４に到達した場合、適切なヘッダ情報とペイロード中で表されたデータアイテムとを含むデータパケットが、受信側クライアントに送信される。一実施形態では、電子文書（例えばワードプロセッシング文書、表計算、パワーポイントプレゼンテーションなど）、グラフィカル表現および／またはアニメーション（絵、画像、アイコンなど）、プロシージャコール、ならびに／あるいは、デジタルに表せる他のデータタイプなどの形のコンテキスト情報を、データストリーム中で送信することができる。別の実施形態では、コンテキスト情報は継続的に、送信されているデータストリームに埋め込まれるかまたは多重化される。例えば、前述のように、送信側は、「バックグラウンドミュージック」を提供する目的で、オーディオファイルを呼の中で多重化するコマンドを発行することができる。この場合、送信側によって識別されたオーディオファイルが、受信側クライアントに送信される会話データと継続的に多重化される。次いで、コマンド対処ルーチン８００はブロック８１６に進んで終了する。
【００５３】
次に図８Ｂを参照しながら、データアイテムを受信側クライアント上で利用可能にするための論理を実施する例示的な処理ルーチン８５０について述べる。図８Ａを参照して上述した説明と同様に、処理ルーチン８５０は、ＶｏＩＰ環境で呼を送受信する機能を提供するアプリケーションプログラム中で実施することができる。これに関して、実行されている処理ルーチン８５０の前に、送信側または受信側は、アプリケーションプログラムを使用して通信チャネルを確立することができる。しかし、図８Ａを参照して上述した説明とは異なり、処理ルーチン８５０は、データアイテムを受信側に利用可能にするための命令を実施する。
【００５４】
図８Ｂに示すように、処理ルーチン８５０はブロック８５２で開始し、ブロック８５４で、データアイテムを提示する要求が送信側クライアントから受信されるまで、遊休状態に留まる。図８Ａを参照して上述したように、本発明の態様は、データアイテムを受信側に提示するかまたは他の方法で利用可能にする、自動的に受け取られるかまたはユーザインタフェースからの入力に基づいて受け取られるコマンドを生成するための制御を提供する。コマンド対処ルーチン８００は、受信側クライアントに送信されるデータストリームに、参照を埋め込む場合もあり、あるいは実際のデータアイテムを埋め込む場合もある。データストリームが受信されたとき、データストリーム中のコンテキスト情報が解析されて、データアイテムを提示する要求が受信されたかどうかが判定される。例えば、データアイテムを提示する命令が、データストリーム中でＸＭＬタグ中に埋め込まれている場合がある。このタイプの情報が受信されたとき、コマンド対処ルーチン８５０は、データアイテムを提示する命令が受信されたと判定し、ブロック８５６に進む。
【００５５】
ブロック８５６で、データルックアップが実施されて、データアイテムを受信側クライアント上で提示する際に存在する可能性のある制限があれば、それらが識別される。前述のように、任意の数の異なるクライアントが呼において使用される場合があり、各クライアントは異なる機能を有する場合がある。場合によっては、受信側クライアントは、送信側クライアントによって送信されたデータアイテムのタイプを提示できないことがある。例えば、送信側は、電子文書または画像を受信側に送信するコマンドを発行することができる。受信側が、ＰＯＴＳ電話機など限られた機能のクライアントデバイスを使用している場合、このデータアイテムを提示することはできない。受信側クライアントがデータアイテムを提示することができないこの場合では、処理ルーチン８５０は、データアイテムのファイル名を識別し、データアイテムが送信されたことを受信側に通知することができる。さらに、介在ＶｏＩＰエンティティが、いくらか後で、記憶済みデータアイテムを音声メールメッセージまたは他の電子通信で受信側に利用可能にすることができる。
【００５６】
受信クライアント上で提示できないデータアイテムは、「バッファリング」して、後で受信側に利用可能にすることができる。これに関して、データアイテムを提示する要求を全く処理せず、将来の使用に向けてデバイス上にまたはサービスプロバイダのローカル記憶装置などに記憶できることも企図される。これに関して、送信側は、指定イベントの発生時にデータアイテムが受信側に送信されるようにする規則を制定することができる。言い換えれば、データアイテムを送信するための規則は、任意の数の異なる変数に基づくことができる。例えば、送信側は、指定期間後にまたは定期的にスケジュールされた間隔で、受信側が「オンライン」であると識別されたときや、データアイテムを提示できる機能豊富なクライアントを受信側が使用していると識別されたときなどに、指定データアイテムが送信されるようにする規則を制定することができる。
【００５７】
データアイテムを受信側に提示することに対して、ポリシーに基づいて制限を課すことができる。例えば、受信側クライアントに送信されているネットワークトラフィックを検索するように、マルウェア防止ソフトウェアを構成することができる。受信側クライアントに送信されたデータアイテムがマルウェア（例えばウイルス、ワーム、スパイウェア、トロイの木馬など）の特徴を示す場合には、データアイテムを提示するかまたは他の方法でデータアイテムに関連する命令を実行することに対して、制限を課すことができる。同様に、受信側は、いくつかのタイプのデータアイテムを提示することに対して、変数に依存する制限を定義することができる。例に過ぎないが、限られた帯域幅の接続を維持するワイヤレス電話機を受信側が使用している場合、メモリ集約型のデータアイテム（例えば画像、ビデオなど）がワイヤレス電話機に送信されないように制限を定義することができる。その代わり、このデータアイテムは介在ＶｏＩＰエンティティによってバッファリングすることができ、後で、例えばより高い帯域幅の接続を維持するクライアントを受信側が使用しているときに、このデータアイテムにアクセスすることができる。別の例として、より高い特権を有するユーザ（例えば親）は、他のユーザ（例えば子供）が送信側から受信できるデータアイテムのタイプに制限を課すことができる。
【００５８】
受信側によって制定された規則に基づいて、データアイテムの提示に対して制限を課すことができる。例えば、前述のように、送信側は、オーディオファイルが送信されて受信側クライアント上で再生されるようにするコマンドを発行することができる。しかし、受信側は、事前定義された期間中のみオーディオファイルの再生を許可するなど、変数に基づいてオーディオファイルの再生を許可する規則を制定することができる。これらの例は、本発明の態様が極めて構成可能であり、特許請求する主題の範囲を逸脱することなく他のタイプの制限および／または規則を定義することもできることを例示する。
【００５９】
判定ブロック８５８で、処理ルーチン８５０は、ブロック８５６で識別された制限があればそれらに基づいて追加の処理が実施されることになるかどうか判定する。前述のように、マルウェアが識別されたときや、ポリシーまたは規則が定義されているときなどに、制限を制定することができる。データアイテムの提示が許可されないこれらの場合には、ブロック８５８で実施されるテストの結果は「いいえ」であると判定され、処理ルーチン８５０はブロック８６８に進んで終了する。データアイテムに関連する命令の実行を妨げる制限が存在しない場合は、処理ルーチン８５０はブロック８６０に進む。
【００６０】
ブロック８６０で、データ構造ルックアップが実施されて、データアイテムがどのように受信側に利用可能にされるかについての選好が識別される。一実施形態では、種々のタイプのデータアイテムがどのように提示され、または他の方法で利用可能にされるかを定義する選好が、受信側によって制定されてよく、あるいはデフォルトで制定されてよい。これに関して、受信されたデータアイテムが指定ファイルタイプ（例えば「．ｄｏｃ」）に準拠する場合は、受信側がデータアイテムにすぐにアクセスできるように特定のアプリケーションプログラム（例えばＭｉｃｒｏｓｏｆｔ  Ｗｏｒｄ（登録商標））を起動させる選好を定義することができる。さらに、変数に依存する選好が、どのデータアイテムが受信側に提示されるかに影響するものとすることもできる。これに関して、受信側は、特定の個人が呼を開始したときにオーディオファイルを関連付けて再生する規則を制定することができる。この場合、送信側から受信されるデータアイテムにかかわらず、受信側によって制定された選好は、呼が開始したときにどのオーディオファイルが再生されるかをオーバーライドすることができる。しかし、任意の数の異なるタイプの変数に依存する他の選好も定義できることを、当業者なら理解するであろう。
【００６１】
図８Ｂに示すように、ブロック８６２で、指定データアイテムが受信側クライアント上でローカルに利用可能かどうかが判定される。ブロック８６２に到達した場合、データアイテムが受信側に提示されるのを妨げるように意図された制限は識別されていない。この場合、処理ルーチン８５０は、ブロック８５４で受信された要求に対処するための命令の実行を許可する。しかし、前述のように、受信側クライアントからローカルにデータアイテムにアクセスできる場合もあり、あるいは実際のデータアイテムがデータストリームに埋め込まれている場合もある。代替の一実施形態では、データアイテムは、ネットワークを介してアクセス可能なデータストアから利用可能な場合もある。いずれの場合でも、データアイテムが受信側クライアント上でローカルに利用可能なときは、ＸＭＬタグを受け取ることができる。これは例えば、送信側クライアントと受信側クライアントの両方で利用可能なデータアイテムパッケージにデータアイテムが含まれている場合に生じることがある。この場合、データアイテムはローカルに利用可能であると判定され、処理ルーチン８５０はブロック８６４に進む。あるいは、実際のデータアイテムがデータストリームに含まれている場合は、データアイテムはローカルに利用可能でないと判定され、処理ルーチンはブロック８６６に進む。
【００６２】
ブロック８６４で、ブロック８５４で受信された要求中で識別されたデータアイテムが、受信側クライアントに利用可能な記憶装置から呼び戻される。前述のように、データアイテムおよび関連機能を記述するタグを、コンテキスト情報として送信側クライアントと受信側クライアントとの間で送信することができる。これに関して、タグは、データアイテムの識別および／またはデータアイテムが位置することのできるパッケージの識別、データアイテムを受信側に提示するための命令などを含む、データアイテムに関連するセマンティクスを記述することができる。ブロック８６４で、送信側クライアントから受信されたタグに含まれるテキストが解析されて、どこにデータアイテムが記憶されているかが識別される。次いでデータアイテムは、提示するかまたは他の方法で利用可能にすることができるように、呼び戻される。
【００６３】
ブロック８６６で、データアイテムが受信側クライアント上で提示されるかまたは他の方法で利用可能にされたとき、送信側によって生成されたコマンドが果たされる。データアイテムを提示することは、受信側によって制定されたかまたはデフォルトで提供された選好を適用することを含むことができる。例えば、前述のように、データアイテムを提示することは、適切なアプリケーションプログラムを識別し、このアプリケーションプログラムを起動し、このアプリケーションプログラムを使用してデータアイテムを表示することを含むことができる。同様に、受信側が現在、適切なアプリケーションプログラムと対話している場合は、データアイテムを提示することは、グラフィカルユーザインタフェースを「リフレッシュ」し、それによりデータアイテムが表示されるようにすることを含むことができる。さらに、データアイテムを提示することは、受信側クライアントからアクセス可能なプログラムインタフェースにプロシージャコールを発行することを含むことができる。例えば、クライアントデバイスが振動したり、識別されたオーディオファイルを再生したり、画像を表示したりなどするようにするための関数を発行することができる。次いで、処理ルーチン８５０はブロック８６８に進んで終了する。
【００６４】
図９〜１３を参照しながら、ＶｏＩＰコンテキスト情報に対応する構造化階層の様々なクラスおよび属性を示すブロック図を示す。前述のように、構造化階層は、２つ以上のＶｏＩＰデバイス間で交換されるコンテキスト情報を構成するための事前定義済みの組織構造である。構造化階層は、様々なクラスおよび属性を再定義することによって、定義し、更新し、および／または修正することができる。様々なＶｏＩＰエンティティ間で交換されるＶｏＩＰコンテキスト情報は、ＶｏＩＰ名前空間９００に対応することができる。一実施形態では、ＶｏＩＰ名前空間９００は、階層構造化されたノードツリーとして表され、各ノードは、ＶｏＩＰコンテキスト情報のサブセットに対応するサブクラスに相当する。例えば、ＶｏＩＰ名前空間９００は、呼基本クラス９０２、呼コンテキストクラス９１０、デバイスタイプクラス９２０、ＶｏＩＰクライアントクラス９３０などを含む階層構造化されたツリーとして定義することができる。
【００６５】
図１０を参照すると、呼基本クラス９０２のブロック図が示されている。例示的な一実施形態では、呼基本クラス９０２は、会話チャネル接続（例えばＰＳＴＮ呼接続、ＶｏＩＰ呼接続など）に関係するＶｏＩＰコンテキスト情報のサブセットに対応することができる。会話チャネル接続に関係するＶｏＩＰコンテキスト情報のサブセットは、発信番号（例えば発呼側のクライアントＩＤ番号）、宛先番号（例えば被呼側のクライアントＩＤ番号または電話番号）、呼接続時間、ＶｏＩＰサービスプロバイダ関係の情報、および／あるいは、ＩＰアドレスやＭＡＣアドレスや名前空間の情報などＩＳＰ関係の情報を含むことができる。加えて、会話チャネル接続に関係するコンテキスト情報は、呼優先度情報（宛先番号の優先レベルを定義する）、呼タイプ情報、データアイテムを送受信するための規則などを含むこともできる。呼タイプ情報は、会話チャネルが、緊急通信、ブロードキャスティング通信、コンピュータからコンピュータへの通信、コンピュータからＰＯＴＳデバイスへの通信などに向けて確立されるのかを示すことができる。一実施形態では、会話チャネル接続に関係するコンテキスト情報は、感情、音（例えば「ああ」「おっと」「うわっ」など）、ならびに表情のグラフィカル表現および／またはアニメーションを表す、事前定義済みの識別子を含むことができる。一実施形態では、呼基本クラス９０２は、ＶｏＩＰ名前空間９００のサブツリー構造として定義することができ、このサブツリー構造は、呼優先度９０３、名前空間情報９０４、呼タイプ９０５、宛先番号９０６、サービスプロバイダ９０７、事前定義済み識別子９０８などのノードを含む。
【００６６】
図１１を参照すると、呼コンテキストクラス９１０のブロック図が示されている。一実施形態では、会話コンテキストに関係するＶｏＩＰコンテキスト情報のサブセットが、呼コンテキストクラス９１０に対応することができる。会話コンテキストに関係するコンテキスト情報は、クライアント、サービスプロバイダ、ネットワークなどから供給されたキーワードなどの情報を含むことができる。会話コンテキストに関係するコンテキスト情報はまた、文書ファイルデータからの識別されたキーワード、会話データパケットからの識別されたキーワード（例えば会話キーワード）、文書のファイル名、および／または会話の一部として交換されるマルチメディアファイル、ゲーム関係の情報（ゲームタイプ、あるゲームにおける仮想近接感（virtual proximity））、使用頻度（あるファイル、ある主題、およびあるクライアントに関係する呼の頻度および継続時間を含む）、ならびに、ファイル識別（会話に関係するケース番号や事項番号など）を特に含むこともできる。例示的な一実施形態によれば、呼コンテキストクラス９１０は、ＶｏＩＰ名前空間９００のサブツリー構造として定義することができ、このサブツリー構造は、ファイル識別９１２、供給されたキーワード９１３、会話キーワード９１４、使用頻度９１５、会話の主題９１６などに対応するノードを含む。
【００６７】
図１２を参照すると、デバイスタイプクラス９２０のブロック図が示されている。一実施形態では、デバイスタイプクラス９２０は、会話チャネル接続に使用されるＶｏＩＰクライアントデバイスに関係するＶｏＩＰコンテキスト情報のサブセットに対応することができる。ＶｏＩＰクライアントデバイスに関係するＶｏＩＰコンテキスト情報のサブセットは、ＶｏＩＰクライアントデバイスによって生成されたオーディオデータを処理するのに必要な場合のあるオーディオ関係の情報を含むことができる。オーディオ関係の情報は、サンプリングレート、マシンタイプ、出入力タイプ、マイクロホン、デジタル信号処理（ＤＳＰ）カード情報、またはデータアイテムを提示する能力など、デバイスのオーディオ機能および能力に関係する情報を含むことができる。ＶｏＩＰクライアントデバイスに関係するＶｏＩＰコンテキスト情報のサブセットは、ＶｏＩＰクライアントデバイスによって生成されたビデオデータを処理するのに必要な場合のあるビデオ関係の情報を含むことができる。ビデオ関係の情報は、ビデオデータの解像度、リフレッシュ、タイプ、およびサイズと、グラフィックカード情報などを含むことができる。ＶｏＩＰクライアントデバイスに関係するコンテキスト情報はさらに、コンピュータシステムのタイプ、プロセッサ情報、ネットワーク帯域幅、無線／有線接続、コンピュータシステムの可搬性、コンピュータシステムの処理設定など、他のデバイス特有の情報を含むこともできる。例示的な一実施形態では、デバイスタイプクラス９２０は、ＶｏＩＰ名前空間９００のサブツリー構造として定義することができ、このサブツリー構造は、オーディオ９２２、ビデオ９２４、デバイス特有９２５などに対応するノードを含む。
【００６８】
図１３を参照すると、ＶｏＩＰクライアントクラス９３０のブロック図が示されている。例示的な一実施形態によれば、ＶｏＩＰクライアントクラス９３０は、ＶｏＩＰクライアントに関係するコンテキスト情報のサブセットに対応することができる。一実施形態では、ＶｏＩＰクライアントに関係するＶｏＩＰコンテキスト情報のサブセットは、音声プロファイル情報（例えば個人ユーザの音および音声に関する特性を指定する情報の集まり）、デジタル署名情報、ならびにバイオメトリック情報を含むことができる。バイオメトリック情報は、生体認証に関係するユーザ識別情報（例えば指紋）、ユーザのストレスレベル、ユーザの気分などを含むことができる。加えて、ＶｏＩＰクライアントに関係するＶｏＩＰコンテキスト情報のサブセットは、位置情報（クライアントによって定義された位置、ＶｏＩＰによって定義された位置、ＧＰＳ／三角測量位置、および個人ユーザの論理的／仮想位置を含む）、割り当てられた電話番号、ユーザコンタクト情報（名前、住所、会社など）、クライアントやサービスプロバイダやネットワークなどによって定義された規則、ユーザ規則および選好、デジタル権利管理（ＤＲＭ）、組織中の個人ユーザのメンバランク（member rank）、メンバランクに関連する優先度などを含むことができる。メンバランクに関連する優先度を使用して、会議通話のためにクライアントに優先度を割り当てることができる。一実施形態では、ＶｏＩＰクライアントクラス９３０は、ＶｏＩＰ名前空間９００のサブツリー構造として定義することができ、このサブツリー構造は、ユーザバイオメトリクス９３１、位置９３２、規則９３３、ユーザ識別９３４、メンバ優先度９３５、クライアント選好９３６などに対応するノードを含む。
【００６９】
例示的な実施形態を図示し、説明したが、本発明の趣旨および範囲を逸脱することなくこれらの実施形態に様々な変更を加えることができることは理解されるであろう。
【図面の簡単な説明】
【００７０】
【図１】本発明の一態様による、様々なクライアント間で会話チャネルを確立するためのＶｏＩＰ環境を示すブロック図である。
【図２】本発明の一態様によるＶｏＩＰクライアントを示すブロック図である。
【図３】本発明の一態様による、ＶｏＩＰデバイスに関連する様々なコンポーネントを示すブロック図である。
【図４】本発明の一態様による、会話チャネルを介した２つのＶｏＩＰクライアント間のデータ交換を示すブロック図である。
【図５】図１のＶｏＩＰ環境で確立された通信チャネルを介して使用されるデータパケットのブロック図である。
【図６】本発明の一態様による、識別された構造化階層によって定義されるコンテキスト情報を転送するための、２つのＶｏＩＰクライアント間の対話を示すブロック図である。
【図７】本発明の一態様による、コンテキスト情報を収集し、転送するための、様々なＶｏＩＰエンティティ間の対話を示すブロック図である。
【図８Ａ】送信側クライアントから受信側クライアントにデータアイテムを送受信するための例示的な流れ図である。
【図８Ｂ】送信側クライアントから受信側クライアントにデータアイテムを送受信するための例示的な流れ図である。
【図９】本発明の一態様による、ＶｏＩＰコンテキスト情報に対応する構造化階層の属性およびクラスを示すブロック図である。
【図１０】本発明の一態様による、ＶｏＩＰコンテキスト情報に対応する構造化階層の属性およびクラスを示すブロック図である。
【図１１】本発明の一態様による、ＶｏＩＰコンテキスト情報に対応する構造化階層の属性およびクラスを示すブロック図である。
【図１２】本発明の一態様による、ＶｏＩＰコンテキスト情報に対応する構造化階層の属性およびクラスを示すブロック図である。
【図１３】本発明の一態様による、ＶｏＩＰコンテキスト情報に対応する構造化階層の属性およびクラスを示すブロック図である。
【図１】
2009539313.tif 000003
【図２】
2009539313.tif 000004
【図３】
2009539313.tif 000005
【図４】
2009539313.tif 000006
【図５】
2009539313.tif 000007
【図６】
2009539313.tif 000008
【図７】
2009539313.tif 000009
【図８Ａ】
2009539313.tif 000010
【図８Ｂ】
2009539313.tif 000011
【図９】
2009539313.tif 000012
【図１０】
2009539313.tif 000013
【図１１】
2009539313.tif 000014
【図１２】
2009539313.tif 000015
【図１３】
2009539313.tif 000016
【国際調査報告】
2009539313.tif 000017
2009539313.tif 000018