JP6219310B2 - ワイヤレスディスプレイのためのユーザ入力バックチャネルを介した双方向トンネリング - Google Patents

Description

関連出願

[0001] 本出願は、２０１２年１月６日に出願され、そのすべての内容が参照によりここに組み込まれている米国仮出願番号第６１／５８３，９１４号の利益を主張する。

[0002] 本開示は、ソースデバイスとシンクデバイスとの間でデータを送信するための技法に関しており、より具体的には、シンクデバイスからソースデバイスへのユーザ入力データの送信をサポートする技法およびプロトコルに関する。

[0003] ワイヤレスディスプレイ（ＷＤ）またはＷｉ−Ｆｉディスプレイ（ＷＦＤ）システムは、ソースデバイスおよび１つまたは複数のシンクデバイスを含む。ソースデバイスおよびシンクデバイスの各々は、ワイヤレス通信能力を有するモバイルデバイスまたはワイヤード（ｗｉｒｅｄ）デバイスのどちらかでありうる。ソースおよび（１つまたは複数の）シンクのうちの１つまたは複数は、例えば、モバイル電話、タブレットコンピュータ、ワイヤレス通信カードを有する携帯用コンピュータ、携帯情報端末（ＰＤＡ）、携帯用メディアプレイヤ、または、いわゆる「スマート」フォンおよび「スマート」パッドまたはタブレット、あるいは他のタイプのワイヤレス通信デバイスを含む、無線通信能力を有する他のそのようなデバイスを含むことができる。ソースデバイスおよびシンクデバイスのうちの１つまたは複数はまた、通信能力を含む、テレビ、デスクトップコンピュータ、モニタ、プロジェクタ等のようなワイヤードデバイスも含むことができる。

[0004] ソースデバイスは、音声映像（ＡＶ）データのような、メディアデータを特定のメディア共有セッションに参加する（１つまたは複数の）シンクデバイスのうちの１つまたは複数に伝送する。メディアデータは、ソースデバイスの局所的（local）ディスプレイとシンクデバイスのディスプレイの各々との両方でプレイバックされうる。より具体的には、参加するシンクデバイスの各々は、そのスクリーンおよび音声機器上で受信されたメディアデータをレンダリングする（render）。

[0005] 概して、本開示は、ワイヤレスディスプレイ（ＷＤ）システムにおけるソースデバイスおよび１つまたは複数のシンクデバイスがユーザインタフェースバックチャネル（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ Ｂａｃｋ Ｃｈａｎｎｅｌ：ＵＩＢＣ）をわたる（over）双方向通信をサポートするためにＵＩＢＣを拡張することを有効にする技法に関する。ソースおよびシンクデバイスは、現在開発中にある、ワイヤレスＨＤ、ワイヤレスホームデジタルインタフェース（ＷＨＤＩ）、ＷｉＧｉｇ、ワイヤレスＵＳＢおよびＷｉ−Ｆｉディスプレイ（ＷＦＤ）規格のような、規格に準拠するＷＤ通信技法をインプリメントし（implement）うる。ＷＦＤ規格についての追加の情報は、Ｗｉ−Ｆｉアライアンス技術協会、ディスプレイタスクグループ（Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅ Ｔｅｃｈｎｉｃａｌ Ｃｏｍｍｉｔｔｅｅ， Ｄｉｓｐｌａｙ Ｔａｓｋ Ｇｒｏｕｐ）のＷｉ−Ｆｉアライアンス「Ｗｉ−Ｆｉ Ｄｉｓｐｌａｙ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｄｒａｆｔ ｖｅｒｓｉｏｎ １．３１」に見受けられることができ、これは、全体として参照によりここに組み込まれている。ＷＤシステムは、ソースデバイスが、１つまたは複数のシンクデバイスのうちの１つに接続されている１つまたは複数の周辺装置と通信することを可能にするために拡張されたＵＩＢＣを利用することができる。例えばシンクデバイスおよび／またはシンク周辺装置が、ソースデバイスよりもユーザに近く位置付けられ、その結果、周辺装置のシンクデバイスへの接続をソースデバイスへのものよりも便利にしている場合、ソースデバイスがシンク周辺装置と通信することを有効にすることは有利でありうる。本開示の技法は、ソースがシンクデバイスとのワイヤレス通信範囲内にあるとき、ソースデバイスが周辺のシンクデバイスと通信することができる「ワイヤレスドッキング（wireless docking）」を可能にすることができる。しかしながら現在のＷＦＤ規格は、ソースデバイスが様々なタイプの入力デバイス以外のシンク周辺装置と通信することができるメカニズムを含まない。

[0006] 本開示の態様は、シンクデバイスとして動作するように、ならびにソースデバイスに、およびソースデバイスからＵＩＢＣを使用して周辺データをトンネリングする（tunnel）ように構成された計算デバイスに関する。周辺データをトンネリングするために、ＵＩＢＣは、ユーザ入力の追加の「トンネリング」カテゴリをサポートするように拡張される。例として、ソースおよびシンクデバイスは、シンク周辺装置の周辺デバイスコマンドを含む、周辺データをカプセル化するために追加のトンネリングＵＩＢＣ入力カテゴリを有するＵＩＢＣパケットを利用することができる。ＵＩＢＣトンネリングカテゴリで識別されるＵＩＢＣパケット内の周辺データをカプセル化することによって、周辺装置は、シンクデバイスがＵＩＢＣを使用してソースデバイスに転送する（transfer）ことができる（包括的（generic）とは反対の）本来の周辺インタフェースコマンド（例えば、周辺データの一部を備えることができるＵＳＢ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、およびＰＳ２コマンド）を発する（issue）ことができる。ソースデバイスは、ＵＩＢＣトンネリングされた周辺データをカプセル化解除（decapsulate）することができ、周辺装置が直接ホストに接続されているかのように、いずれかのカプセル化解除されたコマンドおよび／またはデータを解釈することができる。同様に、ソースデバイスは、例えば、ソースデバイスのホストインタフェースコントローラから周辺データを受信し、シンクにカプセル化された周辺データを送信することができる。シンクは、周辺データをカプセル化解除し、シンクに接続されている、周辺装置に周辺データを送信することができる。

[0007] １つの例では、方法は、計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立することと、ＵＩＢＣを使用して、計算デバイスからカプセル化された周辺データを受信することと、周辺データをカプセル化解除することと、を備える。

[0008] 別の例では、方法は、計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立することと、周辺データを受信することと、周辺データをカプセル化することと、ＵＩＢＣを使用して計算デバイスにカプセル化された周辺データを送信することと、を備える。

[0009] 別の例では、第１の計算デバイスは、第２の計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立し、ＵＩＢＣを使用して、第２の計算からカプセル化された周辺データを受信し、周辺データをカプセル化解除するように構成されたユーザインタフェースバックチャネル（ＵＩＢＣ）モジュールを備える。

[0010] 別の例では、第１の計算デバイスは、第２の計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立し、周辺データを受信し、周辺データをカプセル化し、ＵＩＢＣを使用して、第２の計算デバイスにカプセル化された周辺データを送信するように構成されたユーザインタフェースバックチャネル（ＵＩＢＣ）モジュールを備える。

[0011] 別の例では、第１の計算デバイスは、第２の計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立するための手段と、ＵＩＢＣを使用して、第２の計算デバイスからカプセル化された周辺データを受信するための手段と、周辺データをカプセル化解除するための手段と、を備える。

[0012] 別の例では、第１の計算デバイスは、第２の計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立するための手段と、周辺データを受信するための手段と、周辺データをカプセル化するための手段と、ＵＩＢＣを使用して、第２の計算デバイスにカプセル化された周辺データを送信するための手段と、を備える。

[0013] 別の例では、コンピュータ可読記憶媒体は、ソースデバイスにおいて実行されたときに、１つまたは複数のプロセッサに、計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立することと、ＵＩＢＣを使用して、計算デバイスからカプセル化された周辺データを受信することと、周辺データをカプセル化解除することと、を行わせる命令を記憶する。

[0014] 別の例では、コンピュータ可読記憶媒体は、シンクデバイスにおいて実行されたときに、１つまたは複数のプロセッサに、計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立することと、周辺データを受信することと、周辺データをカプセル化することと、ＵＩＢＣを使用して計算デバイスにカプセル化された周辺データを送信することとを行わせる命令を記憶する。

[0015] 本開示の１つまたは複数の例の詳細は、添付図面および以下の記述において述べられている。他の特徴、オブジェクト、および利点は、記述、図面、および特許請求の範囲から明らかになる。

本開示の技法にしたがって、周辺データの双方向トンネリングをインプリメントすることができる、実例となるワイヤレスディスプレイ（ＷＤ）ソース／シンクシステム１００を例示するブロック図である。 本開示の技法にしたがって、周辺データの双方向トンネリングをインプリメントすることができる、実例となるソース／シンクシステム１０１を例示するブロック図である。 ＷＤシステムのためのデータ通信モデルまたはプロトコルスタックの例を例示するブロック図である。 本開示の技法にしたがって、双方向周辺データトンネリングをサポートするＷＦＤシステムの様々なコンポーネントを例示する概略図である。 シンクデバイスとソースデバイスとの間でカプセル化された周辺データを送信するように使用されることができる、双方向トンネリングパケット４００の例を例示する概略図である。 本開示の技法にしたがって、双方向トンネリングパケットのペイロードデータを例示する概略図である。 能力ネゴシエーションセッション（capabilities negotiations session）の一部として、ソースデバイス５２０とシンクデバイス５６０との間の例示的なメッセージ転送シーケンスを例示するブロック図である。 本開示の技法にしたがって能力ネゴシエーションを行うための、ソースデバイス５２０とシンクデバイス５６０との間の実例となるリアルタイムストリーミングプロトコル（ＲＴＳＰ）メッセージ転送シーケンスを例示する概略図である。 本開示の技法にしたがって、カプセル化された周辺データの双方向トンネリングをインプリメントすることができるソースデバイスの例を例示するブロック図である。 ソースデバイスへの、およびソースデバイスからの周辺データの双方向トンネリングをサポートするための技法をインプリメントするシンクデバイスの例を例示するブロック図である。 本開示の技法にしたがって、周辺データの双方向トンネリングをサポートするための技法を例示するフローチャートである。 周辺データの双方向トンネリングをサポートするための技法を例示するフローチャートである。 周辺データの双方向トンネリングをサポートするための技法を例示するフローチャートである。 周辺データの双方向トンネリングをサポートするための技法を例示するフローチャートである。

詳細な説明

[0030] 本開示は、概して、ソースデバイスがシンクデバイスと通信することができるシステムに関する。ソースデバイスおよびシンクデバイスはワイヤレス通信をサポートすることができる。通信セッションの一部として、ソースデバイスは、シンクデバイスに音声および映像データを送信することができ、シンクデバイスは、シンクデバイスで受信されたユーザ入力をワイヤレスソースデバイスに返送することができる。この方法で、シンクデバイスのユーザは、ソースデバイスを制御し、ソースデバイスからシンクデバイスに送信されているコンテンツを制御することができる。

[0031] 本開示の技法にしたがって、携帯電話のような計算デバイスを有するユーザは、オフィスのような環境に歩き込み、その環境で、彼または彼女の主要な処理エンジンとして携帯電話を利用する接続された周辺デバイスのアレイ（array）を有するシンクデバイスを使用することができる。１つの例として、ユーザは、携帯電話に記憶されたファイルを有し、Ｅメールを介してそれらを送信する前にそれらのファイルを編集することを求めうる。しかしながら、ユーザは、より大きなディスプレイとフルサイズのキーボードを有するデスクトップコンピュータ上でそのようなタスクを行うことを好みうる。キーボードに加えて、デスクトップは、ユーザインタフェースデバイス、記憶デバイス、プリンタ、および他のそのような周辺デバイスを含む関連付けられた周辺デバイスのグループを有することができる。本開示の技法にしたがって、ユーザは、携帯電話上でアプリケーションを作動させるためにデスクトップコンピュータを利用することができる。この方法で、処理の大部分が携帯電話で生じている間、ユーザはデスクトップコンピュータ上での動作のユーザエクスペリエンス（user experience）を表示されることができる。そのような動作環境では、処理の大部分がその電話で生じている間にユーザが、デスクトップのエクスペリエンスを忠実に思い起こさせるユーザエクスペリエンスを有するように、その電話は、デスクトップコンピュータの周辺デバイスとインタフェースで接続することができる必要がありうる。

[0032] 本開示の技法は、ユーザ入力チャネル（ＵＩＣ）としても称されうる、ＵＩＢＣをわたった双方向通信を有効にするために、「トンネリング」カテゴリとして称される、新たな入力カテゴリを加えることによって、ユーザ入力バックチャネル（ＵＩＢＣ）を双方向になるように拡張する。したがって、本開示の技法は、いくつかの事例では、ユーザに、複数のシンクデバイスのシンク周辺デバイスのアレイだけでなくそれらのデータにもアクセスすることができる便宜性を与えることができる。明らかになるように、電話およびデスクトップを用いた上記で与えられた具体的な例は、本開示の技法が使用されうる環境およびデバイスの多くの例のうちの１つでしかない。

[0033] ＵＩＣを使用して、シンクデバイスは、不可知の方法（agnostic manner）で、ソースデバイスと、シンクデバイスに接続された周辺装置との間でシンクデバイスに接続された周辺装置のデータを送信および受信することができる。ソースデバイスは、周辺装置から受信されたデータの処理を有効にするためにインストールされたシンクデバイスと関連付けられた周辺装置のドライバを有することができる。いくつかの構成では、シンクデバイスもまた、インストールされているけれども制限された能力を持つ周辺ドライバ（peripheral drivers）を有することができる。シンクデバイスは、本開示で記述されている技法にしたがって、周辺デバイスとインタフェースで接続し、周辺装置に対してデータをカプセル化および回送（forward）することができる。ソースデバイスおよびシンクデバイスは、特定の周辺インタフェース技術の周辺データの双方向トンネリングをサポートするために、トンネリングを利用することにネゴシエートおよび合意するリアルタイムストリーミングプロトコル（ＲＴＳＰ）に基づく制御プロシージャを利用することができる。ソースデバイスおよびシンクデバイスはまた、各シンクデバイス、および各シンクデバイスに接続された周辺装置を識別するためにトンネリングコンテキスト情報を交換することができる。ソースデバイスおよびシンクデバイスは、ＵＩＣ周辺装置をカプセル化し、ＴＣＰ／ＩＰ接続をわたってデータを伝送することができる。ソースデバイスおよびシンクデバイスは、カプセル化された周辺データを送信するときにトンネリングコンテキスト情報を含むＵＩＣ特有ヘッダを送信することができる。共有ヘッダは、そのデータを周辺データとして識別することができ、ヘッダはさらに、特定のシンクデバイスだけでなく特定の周辺装置を識別する情報を含むことができる。

[0034] 図１Ａは、本開示の技法にしたがって、周辺データの双方向トンネリングをインプリメントすることができる、実例となるワイヤレスディスプレイ（ＷＤ）ソース／シンクシステム１００を例示するブロック図である。図１Ａで提示されているように、システム１００は、通信チャネル１５０を介してシンクデバイス１６０と通信するソースデバイス１２０を含む。ソースデバイス１２０は、音声／映像（Ａ／Ｖ）データを記憶するメモリ１２１、ディスプレイ１２２、スピーカ１２３、（エンコーダ１２４としても称される）音声／映像エンコーダ１２４、音声／映像制御モジュール１２５、送信機／受信機（ＴＸ／ＲＸ）ユニット１２６、ホストインタフェースコントローラ１２７（ＨＩＣｓ１２７）、およびドライバ１２８を含むことができる。シンクデバイス１６０は、ディスプレイ１６２、スピーカ１６３、（デコーダ１６４としても称される）音声／映像デコーダ１６４、ホストインタフェースコントローラ１６５（ＨＩＣｓ１６５）、送信機／受信機ユニット１６６、ユニット入力（ＵＩ）デバイス１６７、ユーザ入力処理モジュール（ＵＩＰＭ）１６８、およびドライバ１６９を含むことができる。シンクデバイス１６０は、１つまたは複数の周辺デバイス１７０に接続されることができる。例示されたコンポーネントは、単にソース／シンクシステム１００のための１つの実例となる構成の構成要素となる。他の構成は、例示されるものよりも少ないコンポーネントを含むことができる、あるいは例示されるものよりも追加のコンポーネント含むことができる。

[0035] 図１Ａの例において、ソースデバイス１２０は、ディスプレイ１２２上に音声／映像データの映像部分をディスプレイすることができ、スピーカ１２３で音声／映像データの音声部分を出力することができる。音声／映像データは、メモリ１２１に局所的に記憶され、ファイルサーバ、Ｂｌｕ−ｒａｙ（登録商標）ディスク、またはＤＶＤ、のような外部記憶媒体からアクセスされ、あるいは、インターネットのようなネットワーク接続を介してソースデバイス１２０にストリーミングされることができる。いくつかの事例では、音声／映像データは、ソースデバイス１２０のマイクロフォンおよびカメラを介してリアルタイムに捕捉されうる。音声／映像データは、動画、テレビ番組、または音楽のようなマルチメディアコンテンツを含むことができるけれども、ソースデバイス１２０によって生成されたリアルタイムコンテンツを含むこともできる。そのようなリアルタイムコンテンツは、例えば、ソースデバイス１２０上で作動するアプリケーションによって作り出されうる。より詳細に記述されることになるように、いくつかの事例では、そのようなリアルタイムコンテンツは、いくつかの例において、ユーザが選択するのに利用可能なユーザ入力オプションの映像フレームを含むことができる。いくつかの事例では、音声／映像データは、映像のフレームに重ね合わせられたユーザ入力オプションを有する動画またはＴＶプログラムの映像フレームのような、異なるタイプのコンテンツの組み合わせである映像フレームを含むことができる。

[0036] ディスプレイ１２２およびスピーカ１２３を局所的に介して音声／映像データをレンダリングすることに加えて、ソースデバイス１２０の音声／映像エンコーダ１２４は、音声／映像データを符号化することができ、送信機／受信機ユニット１２６は、シンクデバイス１６０に通信チャネル１５０をわたって符号化されたデータを送信することができる。シンクデバイス１６０の送信機／受信機ユニット１６６は、符号化されたデータを受信し、音声／映像デコーダ１６４は、符号化されたデータを復号し、ディスプレイ１６２およびスピーカ１６３を介して復号されたデータを出力する。この方法で、ディスプレイ１２２およびスピーカ１２３によってレンダリングされている音声および映像データは、同時にディスプレイ１６２およびスピーカ１６３によってレンダリングされうる。音声データおよび映像データはフレーム内で配列され、音声フレームは、レンダリングされるとき、映像フレームと時間同期されうる。

[0037] 音声／映像エンコーダ１２４および音声／映像デコーダ１６４は、ＭＰＥＧ４、Ｐａｒｔ１０、アドバンスト映像コーディング（ＡＶＣ）、または時としてＨ．２６５規格と呼ばれる新興の高効率映像コーディング（ＨＥＶＣ）規格として代わりに称される、ＩＴＵ−Ｔ Ｈ．２６４規格のような、あらゆる数の音声および映像圧縮規格をインプリメントしうる。一般的に言えば、音声／映像デコーダ１６４は、音声／映像エンコーダ１２４の相互コーディング（reciprocal coding）動作を実行するように構成される。図１Ａでは図示されていないけれども、いくつかの態様では、Ａ／Ｖエンコーダ１２４およびＡ／Ｖデコーダ１６４は、各々音声エンコーダおよびデコーダと一体化し、共通のデータストリームまたは別個のデータストリームにおける音声および映像の両方の符号化を取り扱うために、適切なＭＵＸ−ＤＥＭＵＸユニットまたは他のハードウェアおよびソフトウェアを含むことができる。

[0038] 以下でより詳細に記述されることになるように、Ａ／Ｖエンコーダ１２４はまた、上記で記述されたような映像圧縮規格をインプリメントすることに加えて、他の符号化機能を行うこともできる。例えば、Ａ／Ｖエンコーダ１２４は、Ａ／Ｖデータがシンクデバイス１６０に送信される前にＡ／Ｖデータに様々なタイプのメタデータを加えることができる。いくつかの事例では、Ａ／Ｖデータは、符号化された形態でソースデバイス１２０に記憶される、あるいはソースデバイス１２０で受信されることができ、それによりＡ／Ｖエンコーダ１２４によるさらなる圧縮を要求しない。

[0039] 図１Ａは、音声ペイロードデータおよび映像ペイロードデータを別個で搬送する通信チャネル１５０を図示しているけれども、いくつかの事例では、映像ペイロードデータおよび音声ペイロードデータは共通のデータストリームの一部でありうることは理解されるべきである。適用可能である場合、ＭＵＸ−ＤＥＭＵＸユニットは、ＩＴＵ．Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）のような他のプロトコルに従うことができる。音声／映像エンコーダ１２４および音声／映像デコーダ１６４は各々、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらのあらゆる組み合わせとしてインプリメントされうる。音声／映像エンコーダ１２４および音声／映像デコーダ１６４の各々は、１つまたは複数のエンコーダまたはデコーダに含まれることができ、それらのどちらかは、組み合わされたエンコーダ／デコーダ（ＣＯＤＥＣ）の一部として一体化されうる。

[0040] ディスプレイ１２２およびディスプレイ１６２は、ブラウン管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスのような、様々な映像出力デバイスのいずれも備えることができる。スピーカ１２３は、ヘッドフォン、単一スピーカシステム、マルチスピーカシステム、またはサラウンド音響システムのような様々な音声出力デバイスのいずれも備えることができる。加えて、ディスプレイ１２２およびスピーカ１２３は、ソースデバイス１２０の一部として図示され、ディスプレイ１６２およびスピーカ１６３は、シンクデバイス１６０の一部として図示されているけれども、ソースデバイス１２０およびシンクデバイス１６０は、実際にデバイスのシステムでありうる。１つの例として、ディスプレイ１６２はテレビであることができ、スピーカ１６３はサラウンド音響システムであることができ、デコーダ１６４は、ディスプレイ１６２およびスピーカ１６３にワイヤード（ｗｉｒｅｄ）またはワイヤレスのどちらかで接続された外部ボックスの一部であることができる。他の事例では、シンクデバイス１６０は、タブレットコンピュータまたはスマートフォンのような単一デバイスでありうる。また他のケースでは、ソースデバイス１６０およびシンクデバイス１２０は、例えば両方がスマートフォン、タブレットコンピュータである等、類似のデバイスである。このケースでは、１つのデバイスはソースとして動作し、もう一方はシンクとして動作しうる。これらの役割は、後の通信セッションで逆にされる（be reversed）ことさえできる。

[0041] スピーカ１２３およびスピーカ１６３は、ヘッドフォン、単一スピーカシステム、マルチスピーカシステム、またはサラウンド音響システムのような様々な音声出力デバイスのいずれも備えることができる。加えて、ディスプレイ１２２およびスピーカ１６３は、ソースデバイス１２０の一部として図示され、ディスプレイ１６２およびスピーカ１６３は、シンクデバイス１６０の一部として図示されているけれども、ソースデバイス１２０およびシンクデバイス１６０は、実際にデバイスのシステムでありうる。１つの例として、ディスプレイ１６２はテレビであることができ、スピーカ１６３はサラウンド音響システムであることができ、Ａ／Ｖデコーダ１６４は、ディスプレイ１６２およびスピーカ１６３にワイヤードまたはワイヤレスのどちらかで接続された外部ボックスの一部であることができる。

[0042] 他の事例では、シンクデバイス１６０は、タブレットコンピュータまたはスマートフォンのような単一デバイスでありうる。また他のケースでは、ソースデバイス１２０およびシンクデバイス１６０は、例えば両方がスマートフォン、タブレットコンピュータである等、類似のデバイスでありうる。このケースでは、１つのデバイスはソースデバイスとして動作し、もう一方はシンクデバイスとして動作しうる。これらの役割は、後の通信セッションで逆にされることができる。また他のケースでは、ソースデバイス１２０は、スマートフォン、ラップトップ、またはタブレットコンピュータのようなモバイルデバイスを備えることができ、シンクデバイス１６０は、（例えば、ＡＣ電力コードを有する）より固定されたデバイスを備えることができ、そのケースではソースデバイス１２０は、シンクデバイス１６０を介して１つまたは複数の視聴する人（viewer）への表示のために音声および映像データを配信することができる。

[0043] ソースデバイス１２０およびシンクデバイス１６０は、ホストインタフェースコントローラ１２７および１６４をそれぞれ含むことができる。ホストインタフェースコントローラ１２７および１６５は、例えば、ＵＳＢ、ＢＬＵＥＴＯＯＴＨ（登録商標）、セキュアデジタル入力出力（ＳＤＩＯ）、シリアルＡＴアタッチメント（ＳＡＴＡ）、ＦＩＲＥＷＩＲＥデバイス、外部シリアルＡＴＡ（ＥＳＡＴＡ）デバイス、または計算デバイスに接続されうる周辺デバイスのあらゆる他のタイプ等の、様々なインタフェースをわたってソースデバイス１２０およびシンクデバイス１６０が周辺デバイス１７０と通信することを可能にする１つまたは複数のインタフェースコントローラを備えることができる。いくつかの、さらにより具体的な例では、周辺デバイス１７０は、デジタルカメラ、ワイヤレスドック（wireless docks）、セキュアデジタルカードリーダ、外部ハードドライブ、および／またはフラッシュドライブのようなデバイスを含むことができる。

[0044] ドライバ１２８および１６９は、ホストインタフェースコントローラ１２７および１６５をそれぞれ制御することができる。ドライバ１２８および１６９は各々、ソフトウェア、ハードウェア、ファームウェア、またはホストインタフェースコントローラ１２７および１６５を制御するように使用されることができるあらゆる他の技術を備えることができる。いくつかの例では、ドライバ１２８は、周辺デバイス１７０のインタフェースのいくつかまたは全てを使用して接続されるデバイスをサポートすることができるドライバであることができる。ドライバ１６９は、ドライバ１２８と比較されると、ドライバ１２８の機能のサブセットのみを含みうる、「軽量」のドライバを備えることができる。例として、ドライバ１６９は、周辺デバイス１７０の各々の１つまたは複数のインタフェースを列挙し、ＵＩＣデータをカプセル化およびカプセル化解除する能力を含むことができる。しかしながら、ドライバ１６９は、インタフェース特有パケットを解釈する、あるいは周辺デバイス１７０のうちの１つの特定のインタフェースを選択する、能力に欠けうる。この方法で、ドライバ１６９およびホストインタフェースコントローラ１６５は、ドライバ１２８およびホストインタフェースコントローラ１２７と比較されるとより少ない周辺データの処理を行いうる。低減された処理は、その結果として、シンクデバイス１６０が、周辺デバイス１７０と通信するために、より少ない電力を消費すること、および／またはより簡素なハードウェアを使用することを有効にしうる。より簡素なハードウェアおよび／またはシンクデバイス１６０の低減された処理は、いくつかのケースでは、シンクデバイス１６０の電力消費を低減することができる。

[0045] 送信機／受信機ユニット１２６および送信機／受信機ユニット１６６は各々、様々なミキサ、フィルタ、増幅器、および信号変調のために設計された他のコンポーネントを、１つまたは複数のアンテナおよび、データを送信および受信するために設計された他のコンポーネントと同様に含むことができる。通信チャネル１５０は、ソースデバイス１２０からシンクデバイス１６０に映像データを送信するための、あらゆる適した通信媒体または異なる通信媒体の集合を概して表す。通信チャネル１５０は、大抵、比較的短距離の通信チャネルであり、定義された２．４ＧＨｚ、３．６ＧＨｚ、５ＧＨｚ、６０ＧＨｚ、または超高帯域（ＵＷＢ）周波数帯域構造をインプリメントするような、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ等に類似する物理チャネル構造をインプリメントすることができる。しかしながら、通信チャネル１５０は、この点で必ずしも限定されず、無線周波数（ＲＦ）スペクトルまたは１つまたは複数の物理送信ラインのようなあらゆるワイヤレスまたはワイヤード通信媒体、あるいはワイヤレスおよびワイヤード媒体のあらゆる組み合わせを備えることができる。他の例では、通信チャネル１５０は、ワイヤードまたはワイヤレスローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットのようなグローバルネットワークのような、パケットに基づくネットワークの一部を形成さえしうる。加えて、通信チャネル１５０は、ピアツーピアリンクを生成するためにソースデバイス１２０およびシンクデバイス１６０によって使用されうる。

[0046] ソースデバイス１２０およびシンクデバイス１６０は、例えば、リアルタイムストリーミングプロトコル（ＲＴＳＰ）制御メッセージを使用する能力ネゴシエーションにしたがって通信セッションを確立することができる。１つの例では、通信セッションを確立するための要求は、シンクデバイス１６０にソースデバイス１２０によって伝送されうる。一度メディア共有セッションが確立されると、ソースデバイス１２０は、リアルタイム転送プロトコル（ＲＴＰ）を使用して参加しているシンクデバイス１６０に、例えば音声映像（ＡＶ）データのようなメディアデータを送信する。シンクデバイス１６０は、そのディスプレイおよび音声機器（図１Ａには図示せず）上で受信されたメディアデータをレンダリングする。

[0047] ソースデバイス１２０およびシンクデバイス１６０はその後、ＩＥＥＥ８０２．１１ファミリの規格のうちの規格のような通信プロトコルを使用して、通信チャネル１５０をわたって通信することができる。１つの例では、通信チャネル１５０は、ネットワーク通信チャネルでありうる。この例では、通信サービスプロバイダが、ネットワークハブとして基地局を使用して１つまたは複数のネットワークを中心的に動作させ、管理することができる。ソースデバイス１２０およびシンクデバイス１６０は、例えば、ソースデバイス１２０およびシンクデバイス１６０が、ワイヤレスアクセスポイントまたはいわゆるホットスポット（hotspots）のような媒介（intermediary）を使用することなく互いに直接通信するように、Ｗｉ−ＦｉダイレクトまたはＷｉ−Ｆｉディスプレイ（ＷＦＤ）規格にしたがって通信することができる。ソースデバイス１２０およびシンクデバイス１６０はまた、ネットワーク輻輳（congestion）を回避または低減するために、トンネルされた直接リンクセットアップ（ｔｕｎｎｅｌｅｄ ｄｉｒｅｃｔ ｌｉｎｋ ｓｅｔｕｐ）（ＴＤＬＳ）を確立することもできる。ＷＦＤおよびＴＤＬＳは、比較的短距離の通信セッションをセットアップするように意図されている。このコンテキストにおける比較的短距離とは、例えば、雑音のある、または妨害された環境において、デバイス間の距離が約３５メートルよりも小さいまたは約２０メートルよりも小さい等、さらに短くなりうるけれども、約７０メートルよりも小さいことを称しうる。

[0048] 本開示の技法は、時に触れてＷＦＤに関係して記述されうるけれども、これらの技法の態様はまた、他の通信プロトコルとも互換性がありうると考慮される。限定ではなく例としてソースデバイス１２０とシンクデバイスとの間のワイヤレス通信は、直交周波数分割多重（ＯＦＤＭ）技法を利用することができる。幅広い種類の他のワイヤレス通信技法はまた、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、符号分割多元接続（ＣＤＭＡ）、またはＯＦＤＭ、ＦＤＭＡ、ＴＤＭＡ、および／またはＣＤＭＡのあらゆる組み合わせに限定されないけれどもそれらを含み、使用されることができる。

[0049] ソースデバイス１２０から受信されたデータを復号およびレンダリングすることに加えて、シンクデバイス１６０は、ユーザ入力デバイス１６７からユーザ入力を受信することもできる。ユーザ入力デバイス１６７は、例えば、キーボード、マウス、トラックボール（trackball）またはトラックパッド、タッチスクリーン、ボイスコマンド認識モジュール、またはあらゆる他のそのようなユーザ入力デバイスでありうる。ＵＩＰＭ１７２は、ソースデバイス１２０が処理できるデータパケット構造に、ユーザ入力デバイス１７０によって受信されるユーザ入力コマンドをフォーマットする。そのようなデータパケットは、通信チャネル１５０をわたってソースデバイス１２０に送信機／受信機１６６によって送信される。送信機／受信機ユニット１２６は、データパケットを受信し、Ａ／Ｖ制御モジュール１３０は、ユーザ入力デバイス１６７によって受信されたユーザ入力コマンドを解釈するためにデータパケットを解析する。データパケットにおいて受信されたコマンドに基づいて、Ａ／Ｖ制御モジュール１２５は、符号化および送信されているコンテンツを変更しうる。この方法で、シンクデバイス１６０のユーザは、遠隔で、ならびにソースデバイス１２０と直接相互動作することなく、ソースデバイス１２０によって送信されている音声ペイロードデータおよび映像ペイロードデータを制御することができる。

[0050] 加えて、シンクデバイス１６０のユーザは、ソースデバイス１２０上のアプリケーションを開始および制御することができることがある。例えば、シンクデバイス１６０のユーザは、ソースデバイス１２０に記憶された写真編集アプリケーションを開始し、ソースデバイス１２０に局所的に記憶されている写真を編集するためのアプリケーションを使用することができる。シンクデバイス１６０は、実際に写真がソースデバイス１２０で編集されている間に写真がシンクデバイス１６０で局所的に編集されているように見える、ならびに感じるユーザエクスペリエンスをユーザに表示することができる。そのような構成を使用して、デバイスユーザは、いくつかのデバイスで使用する１つのデバイスの能力を活用することができる。例えば、ソースデバイス１２０は、大容量のメモリおよび高性能の処理能力を有するスマートフォンであることができ、ソースデバイス１２０のユーザは、スマートフォンが通常使用される全ての設定および状況においてスマートフォンを使用することができる。動画を視聴しているとき、ユーザは、より大きなディスプレイスクリーンを有するデバイスで動画を視聴することを望み、そのケースでは、シンクデバイス１６０がタブレットコンピュータでありうる。ｅｍａｉｌを伝送またはｅｍａｉｌに応答したいとき、ユーザは、物理的なキーボードを有するデバイスを使用することを望み、そのケースではシンクデバイス１６０はラップトップでありうる。両方の事例において、ユーザがシンクデバイス１６０と相互動作するけれども大量の処理が、依然としてソースデバイス１２０によって行われうる。ソースデバイス１２０およびシンクデバイス１６０は、通信チャネル１５０をわたったあらゆる所与のセッションにおいてデバイスの能力をネゴシエートおよび／または識別するために使用されるデータのような、制御データを送信することによって２方向の相互動作を容易にすることができる。

[0051] いくつかの構成では、Ａ／Ｖ制御モジュール１２５は、ソースデバイス１２５の動作システムによって実施されている動作システムプロセスでありうる。しかしながら他の構成では、Ａ／Ｖ制御モジュール１２５は、ソースデバイス１２０上で作動するアプリケーションのソフトウェアプロセスでありうる。そのような構成では、ユーザ入力コマンドは、ソースデバイス１２０上で作動する動作システムとは反対に、シンクデバイス１６０のユーザがソースデバイス１２０上で作動するアプリケーションと直接相互動作するように、ソフトウェアプロセスによって解釈されうる。動作システムと反対にアプリケーションと直接相互動作することによって、シンクデバイス１６０のユーザは、ソースデバイス１２０の動作システムに生来属していないコマンドのライブラリへのアクセスを有すことができる。加えて、アプリケーションと直接相互動作することは、コマンドが異なるプラットフォーム上で作動するデバイスによってより容易に送信および処理されうることを有効にする。

[0052] ソースデバイス１２０は、ワイヤレスシンクデバイス１６０で適用されるユーザ入力に応答することができる。そのような相互動作のアプリケーション設定では、ワイヤレスシンクデバイス１６０で適用されるユーザ入力は、通信チャネル１５０をわたってワイヤレスディスプレイソースに伝送し返されうる。１つの例では、ＵＩＢＣとしても称される、逆チャネルアーキテクチャは、シンクデバイス１６０がシンクデバイス１６０で適用されるユーザ入力をソースデバイス１２０に送信することを有効にするようにインプリメントされうる。逆チャネルアーキテクチャは、ユーザ入力をトランスポートするためのより上部のレイヤメッセージ、およびシンクデバイス１６０およびソースデバイス１２０でユーザインタフェース能力をネゴシエートするためのより下部のレイヤフレームを含むことができる。ＵＩＢＣは、シンクデバイス１６０とソースデバイス１２０との間のインターネットプロトコル（ＩＰ）トランスポートレイヤをわたって存在しうる。この方法で、ＵＩＢＣは、開放型システム間相互接続（ＯＳＩ）通信モデルにおいてトランスポートレイヤよりも上部にありうる。１つの例では、ＯＳＩ通信は、７つのレイヤ（１−物理、２−データリンク、３−ネットワーク、４−トランスポート、５−セッション、６−プレゼンテーション、および７−アプリケーション）を含む。この例では、トランスポートレイヤよりも上にあることは、レイヤ５、６、および７を称する。信頼性のある送信を促すために、ならびにユーザ入力データを含むデータパケットのシーケンス配信において、ＵＩＢＣは、ＴＣＩＰ／ＩＰまたはＵＤＰのような他のパケットに基づく通信プロトコルの最上部で作動するように構成されうる。ＵＤＰおよびＴＣＰは、ＯＳＩレイヤアーキテクチャと並行で動作しうる。ＴＣＰ／ＩＰは、シンクデバイス１６０およびソースデバイス１２０がパケット損失のイベントにおいて再送信技法をインプリメントすること有効にすることができる。

[0053] 本開示の技法は、概して、例えばシンクデバイス１６０のような、シンクデバイスと関連付けられた入力デバイスのデータおよび入力データを送信するための一方向通信チャネルとしてＷＦＤ規格内で定義されている、ＵＩＢＣを拡張することに関する。本開示の技法は、シンクデバイス１６０に接続された、例えば周辺デバイス１７０のようなシンク周辺装置からソースデバイス１２０に通信チャネル１５０を介して、周辺データを送信するための双方向通信チャネルをサポートすることを含むようにＵＩＢＣを拡張する。同様に、ソースデバイス１２０は、通信チャネル１５０を介して周辺デバイス１７０に周辺データを送信することができる。より具体的には、通信チャネル１５０は、「トンネリング」をサポートするように拡張されうる。本開示のコンテキストでは、トンネリングは、ＵＩＢＣのデータ接続内で周辺データをカプセル化することを称しうる。

[0054] 本開示の技法にしたがって、ソースデバイス１２０またはシンクデバイス１６０は、第１のデバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立し、ＵＩＢＣを使用して第１のデバイスからカプセル化された周辺データを受信し、周辺データをカプセル化解除するように構成されうる。ソースデバイス１２０またはシンクデバイス１６０はまた、本開示の技法にしたがって、第１のデバイスへの双方向ＵＩＢＣを確立し、周辺データを受信し、周辺データをカプセル化し、ならびにＵＩＢＣを使用して第１のデバイスに周辺データを送信するように構成されるＵＩＢＣモジュールを含むこともできる。ソースデバイス１２０またはシンクデバイス１６０はまた、第２の計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立し、周辺データを受信し、周辺データをカプセル化し、ならびにＵＩＢＣを使用して第２の計算デバイスに周辺データを送信するように構成されるＵＩＢＣモジュールを含むこともできる。

[0055] カプセル化された周辺データの双方向送信をサポートするように拡張されていることに加えて、ＵＩＢＣは、クロスプラットフォームのユーザ入力データを含む、様々なタイプのユーザ入力データをトランスポートするように設計されうる。例えば、ソースデバイス１２０は、ｉＯＳ（登録商標）動作システムを作動させ、一方でシンクデバイス１６０は、Ａｎｄｒｏｉｄ（登録商標）またはＷｉｎｄｏｗｓ（登録商標）のような別の動作システムを作動させる。プラットフォームに関わらず、ＵＩＰＭ１６８は、Ａ／Ｖ制御モジュール１２５に理解可能な形態で、受信されたユーザ入力をカプセル化することができる。多くの異なるタイプのユーザ入力フォーマットは、多数の異なるタイプのソースおよびシンクデバイスが、プロトコルを有効に使うことを可能にするように、ＵＩＢＣによってサポートされうる。包括的入力フォーマットは定義され、プラットフォーム特有入力フォーマットは両方ともサポートされ、それにより、ユーザ入力がＵＩＢＣによってソースデバイス１２０とシンクデバイス１６０との間で通信されることができる方法で柔軟性（ｆｌｅｘｉｂｉｌｉｔｙ）を提供する。

[0056] 図１Ａの例では、ソースデバイス１２０は、スマートフォン、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、ＷＩＦＩが有効にされたテレビ、または音声および映像データを送信することができるあらゆる他のデバイスを備えることができる。シンクデバイス１６０は同様に、スマートフォン、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、ＷＩＦＩが有効にされたテレビ、または音声および映像データを受信し、ユーザ入力データを受信することができるあらゆる他のデバイスを備えることができる。いくつかの事例では、シンクデバイス１６０は、ディスプレイ１６２、スピーカ１６３、ＵＩデバイス１６７、Ａ／Ｖエンコーダ１６４、および別個であるけれども対話型のデバイスの全ての部分のような、デバイスのシステムを含むことができる。ソースデバイス１２０は、同様に、単一のデバイスよりもむしろデバイスのシステムでありうる。

[0057] 本開示では、ソースデバイスという用語は、概して、音声／映像データを送信しているデバイスを称するように使用され、シンクデバイスという用語は、概して、ソースデバイスから音声／映像データを受信しているデバイスを称するように使用される。多くのケースでは、ソースデバイス１２０およびシンクデバイス１６０は、ソースとして動作する１つのデバイスとシンクとして動作する他のデバイスとを有する、同様の、または同一のデバイスでありうる。さらに、これらの役割は、異なる通信セッションでは逆にされうる。したがって、１つの通信セッションにおけるシンクデバイスは、後の通信セッションにおけるソースデバイスであることができ、またその逆も同様である。ソースデバイス１２０とシンクデバイス１６０の両方は、通信チャネル１５０をわたったワイヤレス通信をサポートするデバイスでありうる。

[0058] 図１Ｂは、本開示の技法にしたがって、周辺データの双方向トンネリングをインプリメントすることができる、実例となるソース／シンクシステム１０１を例示するブロック図である。ソース／シンクシステム１０１は、ソースデバイス１２０およびシンクデバイス１６０を含み、その各々は、図１Ａに関して上で記述された方法で機能および動作することができる。ソース／シンクシステム１０１はさらに、シンクデバイス１８０を含む。上で記述されたシンクデバイス１６０と同様の方法で、シンクデバイス１８０は、ソースデバイス１２０から音声および映像データを受信することができる。シンクデバイス１６０およびソースデバイス１２０は、確立されたＵＩＣをわたってカプセル化された周辺データを送信および受信することができる。

[0059] いくつかの構成では、シンクデバイス１６０およびシンクデバイス１８０は、互いに独立して動作することができ、ソースデバイス１２０における音声および映像データ出力は、シンクデバイス１６０およびシンクデバイス１８０で同時に出力されうる。代わりの構成では、シンクデバイス１６０は、主要のシンクデバイスであり、シンクデバイス１８０は二次的なシンクデバイスでありうる。そのような実例となる構成では、シンクデバイス１６０およびシンクデバイス１８０は結合され、シンクデバイス１６０が映像データをディスプレイしうる一方で、シンクデバイス１８０は対応する音声データを出力する。

[0060] 図２は、ＷＤシステムのためのデータ通信モデルまたはプロトコルスタックの例を例示するブロック図である。データ通信モデル２００は、インプリメントされるＷＤシステムにおいてソースデバイスとシンクデバイスとの間でデータを送信するために使用されるデータと制御プロトコルとの間の相互動作を例示している。１つの例では、ＷＤシステム１００はデータ通信モデル２００を使用することができる。データ通信モデル２００は、物理（ＰＨＹ）レイヤ２０２、メディアアクセス制御（ＭＡＣ）レイヤ（２０４）、インターネットプロトコル（ＩＰ）２０６、ユーザデータグラムプロトコル（ＵＤＰ）２０８、リアルタイムプロトコル（ＲＴＰ）２１０、ＭＰＥＧ２トランスポートストリーム（ＭＰＥＧ２−ＴＳ）２１２、コンテンツ保護２１４、パケット化エレメンタリストリーム（ＰＥＳ）パケット化２１６、映像コデック（codec）２１８、音声コデック２２０、トランスポート制御プロトコル（ＴＣＰ）２２２、リアルタイムストリーミングプロトコル（ＲＴＳＰ）２２４、双方向周辺データトンネル２２８、ヒューマンインタフェースデバイス定数（ｈｕｍａｎ ｉｎｔｅｒｆａｃｅ ｄｅｖｉｃｅ ｃｏｎｓｔａｎｔｓ）２３０、包括的ユーザ入力２３２、および性能分析２３４を含む。

[0061] 物理レイヤ２０２およびＭＡＣレイヤ２０４は、ＷＤシステムにおける通信のために使用される物理シグナリング、アドレス指定、チャネルアクセス制御を定義することができる。物理レイヤ２０２およびＭＡＣレイヤ２０４は、例えば、２．４ＧＨｚ、３．６ＧＨｚ、５ＧＨｚ、６０ＧＨｚ、で定義された米国連邦通信委員会の帯域のような、通信のために使用される周波数帯域構造、または超高帯域（ＵＷＢ）周波数帯域構造を定義しうる。物理レイヤ２０２およびＭＡＣ２０４は、例えば、アナログおよびデジタル振幅変調技法、周波数変調技法、位相変調技法、およびそれらの組み合わせ、のようなデータ変調技法を定義することもできる。物理レイヤ２０２およびＭＡＣ２０４はまた、例えば時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、符号分割多元接続（ＣＤＭＡ）、またはＯＦＤＭ、ＦＤＭＡ、ＴＤＭＡ、および／またはＣＤＭＡのあらゆる組み合わせのような多重化技法を定義しうる。１つの例では、物理レイヤ２０２および媒体アクセス制御レイヤ２０４は、ＷＦＤによって提供されるもののような、Ｗｉ−Ｆｉ（例えば、ＩＥＥＥ８０２．１１−２００７および８０２．１１ｎ−２００９ｘ）規格によって定義されうる。他の例では、物理レイヤ２０２およびが媒体アクセス制御レイヤ２０４は、ワイヤレスＨＤ、ワイヤレスホームデジタルインタフェース（ＷＨＤＩ）、ＷｉＧｉｇ、およびワイヤレスＵＳＢのいずれかによって定義されうる。

[0062] インターネットプロトコル（ＩＰ）２０６、ユーザデータグラムプロトコル（ＵＤＰ）２０８、リアルタイムプロトコル（ＲＴＰ）２１０、トランスポート制御プロトコル（ＴＣＰ）２２２、リアルタイムストリーミングプロトコル（ＲＴＳＰ）２２４は、ＷＤシステムにおいて使用されるパケット構造およびカプセル化を定義し、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）によって維持されている規格にしたがって定義されうる。

[0063] ＲＴＳＰ２２４は、能力をネゴシエートし、セッションを確立し、セッション維持と管理を行うために、ソースデバイス１２０およびシンクデバイス１６０によって使用されうる。ソースデバイス１２０およびシンクデバイス１６０は、ＵＩＢＣをわたったトンネリングをサポートするために、ソースデバイス１２０およびシンクデバイス１６０の能力をネゴシエートするように、ＲＴＳＰメッセージトランザクション（ｔｒａｎｓａｃｔｉｏｎ）を使用して双方向周辺データトンネル２２８を確立することができる。双方向周辺データトンネル２２８を確立するためのＲＴＳＰネゴシエーションの使用は、メディア共有セッションおよび／またはＵＩＢＣを確立するためのＲＴＳＰネゴシエーションプロセスを使用することに類似しうる。

[0064] 例えば、ソースデバイス１２０は、シンクデバイス１６０に、ソースデバイス１２０にとって興味深い能力のリストを指定する能力要求メッセージ（例えば、ＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ要求メッセージ）を伝送しうる。本開示の技法にしたがって、能力要求メッセージは、ＵＩＢＣをわたったカプセル化された周辺データの双方向トンネリングをサポートする能力を含むことができる。シンクデバイス１６０は、ソースデバイス１２０に、双方向周辺データトンネルをサポートする能力を能力応答メッセージ（例えば、ＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答メッセージ）で応答することができる。例として、能力応答メッセージは、シンクデバイス１６０がＵＩＢＣをわたった周辺データの双方向トンネリングをサポートする場合、「はい」を示しうる。ソースデバイス１２０はその後、シンクデバイス１６０にトンネルが周辺データをカプセル化するために使用されることになることを示す肯定応答要求メッセージ（例えば、ＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ要求メッセージ）を伝送しうる。シンクデバイス１６０は、ソースデバイス１２０に、フィードバックチャネルがメディア共有セッション中に使用されることになることを肯定応答する肯定応答メッセージ（例えば、ＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ応答メッセージ）で応答しうる。一度ソースデバイス１２０およびシンクデバイス１６０がＵＩＣを利用することに合意すると、
[0065] 映像コデック２１８は、ＷＤシステムによって使用されうる映像データコーディング技法を定義しうる。映像コデック２１８は、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ、（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られる）ＩＴＵ−Ｔ Ｈ．２６４、ＶＰ８および高効率映像コーディング（ＨＥＶＣ）のような映像圧縮規格のあらゆる数をインプリメントしうる。いくつかの事例では、ＷＤシステムが圧縮のビデオデータまたは非圧縮のビデオデータのどちらかを使用しうることは留意されるべきである。

[0066] 音声コデック２２０は、ＷＤシステムによって使用されうる音声データコーディング技法を定義しうる。音声データは、Ｄｏｌｂｙおよびデジタルシアターシステムによって発展されたもののようなマルチチャネルフォーマットを使用してコード化されうる。音声データは、圧縮または非圧縮されたフォーマットを使用してコード化されうる。圧縮された音声フォーマットの例は、ＭＰＥＧ−１、２音声レイヤＩＩおよびＩＩＩ、ＡＣ−３、ＡＡＣを含む。非圧縮された音声フォーマットの例は、パルス−コード変調（ＰＣＭ）音声フォーマットを含む。

[0067] パケット化エレメンタリストリーム（ＰＥＳ）パケット化２１６およびＭＰＥＧ２トランスポートストリーム（ＭＰＥＧ２−ＴＳ）２１２は、どのようにコード化された音声および映像データがパケット化および送信されるかを定義することができる。パケット化エレメンタリストリーム（ＰＥＳ）パケット化２１６およびＭＰＥＧ−ＴＳ２１２は、ＭＰＥＧ−２Ｐａｒｔ１にしたがって定義されうる。他の例では、音声および映像データは、他のパケット化およびトランスポートストリームプロトコルにしたがってパケット化および送信されうる。コンテンツ保護２１４は、音声または映像データの認可されていないコピーに対する保護を提供することができる。１つの例では、コンテンツ保護２１４は、高帯域幅デジタルコンテンツ保護２．０仕様にしたがって定義されうる。双方向周辺データトンネル２２８は、どのように周辺データがカプセル化され、送信されるかを定義しうる。

[0068] 図３は、本開示の技法にしたがって、双方向周辺データトンネリングをサポートするＷＦＤシステムの様々なコンポーネントを例示する概略図である。図３の例は、ソースデバイス３０２およびシンクデバイス３５２を含む。ソースデバイス３０２およびシンクデバイス３０２は、ＲＴＳＰ制御チャネル３０４、音声視覚（ＡＶ）チャネル３０６、およびユーザ相互動作チャネル３０８、の３つのチャネルを介して接続されうる。ユーザ相互動作チャネルは、周辺データの双方向トンネリングをさらにサポートしうるＵＩＢＣチャネルを備えることができる。ソースデバイス３０２およびシンクデバイス３５２は、ＡＶチャネル３０６をわたって音声および映像データを伝送および受信することができ、ＲＴＳＰチャネル３０４をわたった能力ネゴシエーションに携わりうる。

[0069] 図３の例では、シンクデバイス３５２は、ＳＤＩＯホストブレイクアウト３６４、ＵＳＢホストブレイクアウト３６６、およびＢＬＵＥＴＯＯＴＨホストブレイクアウト３５８を備えるそれぞれのホストコントローラに接続されうる、ＳＤデバイス３５４、ＵＳＢデバイス３５６、およびＢＬＵＥＴＯＯＴＨデバイス３５８を含む周辺装置を含むことができる。シンクデバイス３０２は、ＳＤＩＯホストドライバ３１４、ＵＳＢホストドライバ３１６、およびＢｌｕｅｔｏｏｔｈホストドライバ３１８のような多くのホストドライバを含むことができる。ＳＤＩＯホストドライバ３１４、ＵＳＢホストドライバ３１６、およびＢｌｕｅｔｏｏｔｈホストドライバ３１８の各々はまた、対応するインタフェースに対するそれぞれのホストインタフェースコントローラを通信または制御することができる。

[0070] ＳＤＩＯホストドライバ３１４、ＵＳＢホストドライバ３１６、Ｂｌｕｅｔｏｏｔｈホストドライバ３１８、ＳＤＩＯホストブレイクアウト３６４、ＵＳＢホストブレイクアウト３６６、およびＢｌｕｅｔｏｏｔｈホストブレイクアウト３６８は、ユーザ相互動作チャネル３０８をわたって、本開示の技法にしたがって、カプセル化された周辺データを伝送または受信することができる。より具体的には、ソースデバイス３０２または／およびシンクデバイス３５２は、ＴＣＰ／ＩＰおよび／またはＵＤＰを使用してカプセル化された周辺データを送信または受信することができる。いくつかの例では、ＳＤＩＯホストブレイクアウト３６５、ＵＳＢホストブレイクアウト３６６、およびＢｌｕｅｔｏｏｔｈホストブレイクアウト、ならびに他のホストブレイクアウト（この例では図示せず）は、ユーザ相互動作チャネル３０８をわたったＵＩＢＣ接続を確立する前にＳＤデバイス３５４、ＵＳＢデバイス３５６、およびＢｌｕｅｔｏｏｔｈデバイス３５８のインタフェースを列挙することができる。

[0071] 別の例では、ソースデバイス３０２は、カプセル化されたＷＦＤデータを受信し、そのデータをカプセル化解除し、ＳＤＩＯホストドライバ３１４、ＵＳＢホストドライバ３１６、および／またはＢＬＵＥＴＯＯＴＨホストドライバ３１８（「ホストドライバ３１４、３１６、３１８」）のような適切なホストドライバにカプセル化解除された周辺データを転送することができる。ソースデバイス３０２は、ホストドライバ３１４、３１６、３１８のうちの１つまたは複数からの追加の周辺データまたはコマンドで応答することができる。ソースデバイス３０２はさらに、ユーザインタフェースチャネル３０８を介してシンクデバイス３５２にデータおよび／またはコマンドを送信することができる。

[0072] 図４は、シンクデバイスとソースデバイスとの間でカプセル化された周辺データを送信するように使用されることができる、双方向トンネリングパケット４００の例を例示する概略図である。データパケットヘッダ４０２の例が図４において例示されている。数０−１５はデータパケットヘッダ４０２内でビット位置を識別し、数０、１６、および３２は、データパケットヘッダ４０２における別個のフィールド間のビットオフセットを識別する。データパケットヘッダ４０２は、バージョンフィールド、タイムスタンプフラグ（「Ｔ」）、リザーブされたフィールド、入力カテゴリフィールド、長さフィールド、およびオプションのタイムスタンプフィールドを含む。図４の例では、バージョンフィールドは、シンクデバイスによってインプリメントされる特定の通信プロトコルのバージョンを示すことができる３ビットフィールドである。バージョンフィールドにおける値は、どのようにペイロードデータ４０４を解析するかと同様に、どのようにデータパケットヘッダ４０２のリマインダを解析するか、をソースデバイスに知らせることができる。タイムスタンプフラグは、任意のタイムスタンプフィールドがデータパケットヘッダ４０２に存在するか否かを示す１ビットフィールドである。タイムスタンプフラグは、例えば、タイムスタンプフィールドが存在することを示すための「１」を含むことができ、タイムスタンプフィールドが存在しないことを示すための「０」を含むことができる。リザーブされたフィールドは、バージョンフィールドにおいて識別される特定のプロトコルの将来のバージョンによる使用のためにリザーブされる８ビットフィールドである。

[0073] 図４の例では、入力カテゴリフィールドは、双方向トンネリングパケット４００に含まれるペイロードデータ４０４のための入力カテゴリを識別するための４ビットフィールドである。入力カテゴリフィールドの値は、ペイロードデータ４０４に含まれるデータのタイプ、およびどのようにペイロードデータ４０４がフォーマットされるかをソースデバイスに識別する。このフォーマットに基づいて、ソースデバイスはどのようにペイロードデータ４０４を解析するかを決定する。ペイロードデータ４０４の構造は、図５に関係して以下でより詳細に論じられる。

[0074] １つの例として、入力カテゴリフィールドは、ペイロードデータ４０４がソースデバイスおよびシンクデバイスの両方によって実施されるプロトコルで定義される包括的情報要素を使用してフォーマットされることを示すための包括的入力カテゴリを識別することができる。別の例として、入力カテゴリフィールドは、ペイロードデータ４０４が、入力データがシンクデバイスにおいて受信されるユーザインタフェースのタイプに基づいてフォーマットされることを示すためのヒューマンインタフェースデバイスコマンド（ＨＩＤＣ）入力カテゴリを識別することができる。別の例として、入力カテゴリフィールドは、ペイロードデータ４０４が、ソースデバイスまたはシンクデバイスのどちらかによって使用されるオペレーティングシステム（ＯＳ）のタイプに基づいてフォーマットされることを示すためのＯＳ特有入力カテゴリを識別することができる。本開示の技法にしたがって、入力カテゴリフィールドはまた、ペイロード４０４が、例えば、図１のソースデバイス１２０またはシンクデバイス１６０からのカプセル化された周辺データを含むことを示すためのトンネリング入力カテゴリを識別することができる。トンネリング入力カテゴリは、包括的ユーザ入力およびＨＩＤＣユーザ入力からそのパケットにおけるペイロードデータを区別する。包括的またはＨＩＤＣユーザ入力のケースでは、シンクデバイスに伝送される後のメディアデータへのユーザ入力の影響は通常、どのようにメディアデータがシンクデバイスにおいてユーザに表示されるか、例えばズームおよびパン（pan）の動作、に関する。

[0075] タイムスタンプフィールドは、存在するとき、ソースデバイスによって生成され、シンクデバイスに送信されるメディアデータに関連付けられたタイムスタンプを含むことができる、任意の１６ビットフィールドを備えることができる。例えば、ソースデバイス１２０は、シンクデバイス１６０にメディアデータパケットを送信する前にメディアデータパケットにタイムスタンプを適用している。存在するとき、データパケットヘッダ４０２におけるタイムスタンプフィールドは、シンクデバイス１６０がソースデバイスに双方向トンネリングパケット４００を送信する前にシンクデバイス１６０において受信される最新のメディアデータパケットを識別するタイムスタンプを含むことができる。他の例では、タイムスタンプフィールドは、シンクデバイス１６０において受信される異なるメディアデータパケットを識別するタイムスタンプを含むことができる。タイムスタンプ値は、ソースデバイスがどのメディアデータパケットがレポートされた性能の低下を経験したかを識別し、ＷＦＤシステムにおける往復遅延（roundtrip delay）を計算することを可能にすることができる。

[0076] 長さフィールドは、双方向トンネリングパケット４００の長さを示すための１６ビットフィールドを備えることができる。長さフィールドの値に基づいて、ソースデバイス１２０は、ＵＩＢＣパケットの終わり、および新たな、後のパケットの始まりを識別することができる。図４において例示されるフィードバックパケット４００におけるフィールドの数およびサイズは単なる説明のためのものである。他の例では、ＵＩＢＣパケットは、図４において例示される双方向トンネリングパケット４００におけるものよりも大きいまたは小さいサイズを有するフィールドを含むことができ、ならびに／あるいは、図４において例示される双方向トンネリングパケット４００よりも多いまたは少ないフィールドを含むことができる。

[0077] 双方向トンネリングパケット４００は、本開示の技法にしたがって、ＵＩＣを介して、シンクデバイス１６０からソースデバイス１２０に（図１Ａ）、またはソースデバイス１２０からシンクデバイス１６０に送信されることができる。この方法で、双方向周辺データトンネルは、シンクデバイス１６０とソースデバイス１２０との間でインプリメントされるＵＩＢＣ逆チャネルアーキテクチャの能力を拡張することができる。ＵＩＢＣ上でピギーバックする（piggyback）ために、「トンネリング」と呼ばれる新たな入力カテゴリが、ＵＩＢＣパケットのペイロードデータがカプセル化された周辺データを含むことを示すためにＷＦＤにおいて定義されるＵＩＢＣデータパケットヘッダを用いて利用されうる。

[0078] ドライバ１２８およびドライバ１６９は、双方向トンネリングパケット４００に、および双方向トンネリングパケット４００から周辺データをカプセル化およびカプセル化解除することを担いうる。ドライバ１２８およびドライバ１６９はまた、双方向トンネリングパケット４００のフォーマットを確認するために、パケットのソースまたは宛先を決定するために、ならびに、例えば周辺デバイス１７０のどの周辺デバイスと双方向トンネリングパケット４００が関連付けられているかを決定するために、双方向トンネリングパケット４００のデータパケットヘッダ４０２のペイロードデータ４０４を調べることができる。

[0079] ソースデバイス１２０またはシンクデバイス１６０がカプセル化された周辺データを受信する例では、ドライバ１２８またはドライバ１６９は、ペイロードデータ４０４をカプセル化解除し、ペイロードデータ４０４に基づいてインタフェース特有パケットを構築することができる。インタフェース特有パケットは、ＵＳＢパケットのようなパケット、またはホストインタフェースコントローラ１２７および１６５が特定のインタフェースをわたって通信するために利用することができる別のデータユニットを備えることができる。ホストインタフェースコントローラ１２７または１６５はさらに、ドライバ１２８またはドライバ１６９が構築するインタフェース特有パケットを解析または処理することができる。例として、ホストインタフェースコントローラ１６５は、周辺デバイス１７０にインタフェース特有パケットを送信することができる。

[0080] 双方向トンネリングパケット４００のフォーマットを有するパケットからインタフェース特有パケットを構築するために、ドライバ１２８またはドライバ１６９は、ペイロードデータ４００のみを残して、双方向トンネリングパケット４００からデータパケットヘッダ４０２を取り除くことができる。ドライバ１２８または１６９はまた、ペイロードデータ４０４にＵＳＢパケットヘッダのようなインタフェース特有ヘッダを加えることができる。ドライバ１２８またはドライバ１６９が双方向トンネリングパケット４００の形態でカプセル化された周辺データを受信する例では、ドライバ１２８または１６９は、双方向トンネリングパケット４００のペイロードデータ４０４がインタフェース特有パケットの一部を備えることを決定することができる。ドライバ１２８または１６９は、単一のインタフェース特有パケットを形成するために双方向のトンネリングパケット４００のフォーマットを有する複数パケットのペイロードを組み合わせることができる。別の例では、ドライバ１２８または１６９は、周辺データを受信し、インタフェース特有パケットに基づいて、双方向トンネリングパケット４００のフォーマットを有するパケットを構築することができる。双方向トンネリングパケットを構築するために、ドライバ１２８は、インタフェース特有パケットからあらゆるインタフェース特有パケットヘッダを取り除き、データパケットヘッダ４０２のフォーマットを有するヘッダを加えることができる。

[0081] ドライバ１２８または１６９はまた、単一のインタフェース特有パケットに基づいて、双方向トンネリングパケット４００のフォーマットを有する複数パケットを構築することができる。ドライバ１２８または１６９は、複数のより小さな部分にインタフェース特有パケットのペイロードを分割し、複数の双方向トンネリングパケットの各々のペイロードデータとしてそのより小さな部分を使用することができる。ドライバ１２８または１６９は、例えば、インタフェース特有パケットのペイロードが大き過ぎて双方向トンネリングパケット４００のペイロードデータ４０４に適合できない場合、複数の双方向トンネリングパケットにインタフェース特有パケットを分割することができる。いくつかの例では、ドライバ１２８または１６９は、ペイロードデータ４０４における同じシンクデバイスの複数の異なるシンク周辺装置のためのデータを含むことができる。

[0082] いくつかの例では、データパケットデータ４０４は、特定の周辺デバイスおよび特定のシンクデバイスを示す情報を含むことができる。シンクデバイスを示す情報は、「逆トンネリング識別子（reverse tunneling identifier）」として称され、特定の周辺デバイスを示す情報は、「回送トンネル識別子（forwarding tunnel identifier）」として称されうる。シンクデバイス１６０がカプセル化された周辺データを受信するとき、シンクデバイス１６０は、周辺デバイス１７０のどの周辺デバイスにペイロードデータ３０４を回送すべきかを決定するために、ペイロードデータ４０４０の回送トンネリング識別子を調べることができる。ソースデバイス１２０が双方向トンネリングパケット４００のフォーマットを有するカプセル化された周辺データを受信するとき、ソースデバイス１２０は、１つよりも多いシンクデバイスが存在するケースで、どの特定のシンクデバイスがそのパケットを送信したかを決定するために、データパケットヘッダ４０２に含まれる逆トンネリング識別子を調べることができる。

[0083] 図５は、本開示の技法にしたがって、双方向トンネリングパケットのペイロードデータを例示する概略図である。図５は、データパケットヘッダ４０２およびペイロードデータ４０４を含む双方向トンネリングパケット４００を例示している。双方向トンネリングパケットのペイロードデータ４０４は、双方向トンネリングパケットに特有であり、例えば、包括的、かつＨＩＤＣ入力カテゴリ値を有するパケットのような、異なる入力カテゴリ値を有するＵＩＢＣパケットとは区別できるフォーマットを有することができる。特に、双方向トンネリングパケット４００のペイロードデータ４０４は、トンネルＩＤフィールド４４０、長さフィールド４４２、および記述フィールド４４６を含むことができる。

[0084] １オクテットのサイズである、トンネルＩＤフィールド４４０の値は、回送トンネリング識別子または逆トンネリング識別子のどちらかの値を示すことができる。トンネルＩＤフィールドの値が転送トンネリング識別子を示しているか逆トンネリング識別子を示しているかは、ソースデバイスがシンクデバイスに双方向トンネリングパケット４００を伝送するか、その逆かに依存する。ソースデバイスがシンクデバイスに双方向トンネリングパケット４００を伝送する場合、トンネルＩＤの値は、どの周辺装置にシンクデバイスが記述フィールド４４６でカプセル化されたデータを伝送すべきかを示す逆トンネリング識別子を備える。シンクデバイスがソースデバイスに双方向トンネリングパケット４００を伝送する場合、トンネルＩＤフィールド４４０の値は、どのシンクデバイスおよびシンクデバイスの周辺装置が記述フィールド４４６でカプセル化されたデータを伝送するかを示す回送トンネリング識別子を示す。

[0085] ソースがシンクに双方向トンネリングパケット４００を伝送するケース、またはその逆のケースのどちらかで、２オクテットのサイズである長さフィールド４４２は、周辺データを含み、かつ長さフィールド４４２に続く記述フィールド４４２の（オクテットでの）サイズを示す。いくつかの例では、ソースデバイスまたはシンクデバイスは、３つのフィールドの複数のセットを含むための十分な余地がペイロードデータに存在する場合、トンネルＩＤ、長さ、および記述フィールドの複数のセットを含むことができる。１つの例として、ソースデバイスは、トンネルＩＤ、長さ、および記述フィールドの複数のセットを含むことができ、各セットは、同じシンクデバイスの異なる周辺装置に関するデータに対応しうる。ペイロードデータ４０４にトンネルＩＤ、長さ、および記述フィールドの複数のセットを含むことは、シンクデバイスの各周辺デバイスのための追加のＵＩＢＣパケットを送信しなければならないオーバーヘッドを回避することができる。

[0086] 図６は、能力ネゴシエーションセッションの一部として、ソースデバイス５２０とシンクデバイス５６０との間の例示的なメッセージ転送シーケンスを例示するブロック図である。ソースデバイス５２０は、概して、図１Ａのソースデバイス１２０に関して上で記述されたものと同じ方法で動作することができ、シンクデバイス５６０は、概して、図１Ａのシンクデバイス１６０に関して上で記述されたものと同じ方法で動作することができる。ソースデバイス５２０およびシンクデバイス５６０が接続を確立した後に、ソースデバイス５２０およびシンクデバイス５６０は、能力ネゴシエーション交換の一部としてそれらの後の通信セッションのために使用されるべきパラメータのセットを決定することができる。いくつかの例では、ソースデバイス５２０およびシンクデバイス５６０は、本開示の技法にしたがって周辺データの双方向トンネリングを使用すべきか否かに関してネゴシエートすることができる。

[0087] ソースデバイス５２０およびシンクデバイス５６０は、メッセージのシーケンスを利用することによって能力をネゴシエートすることができる。メッセージは、例えばＲＴＳＰメッセージでありうる。各ＲＴＳＰメッセージは、簡素なテキスト文字の一続き（plaintext character strings）をさらに備えることができるボディを含むことができる。ネゴシエーションのいずれのステージでも、ＲＴＳＰ要求メッセージの受信側はＲＴＳＰ ＯＫ以外のＲＴＳＰステータスコードを含むＲＴＳＰ応答で応答することができ、このケースでは、メッセージ交換は、パラメータの異なるセットで再試行されることができる、あるいは能力ネゴシエーションセッションが終了されうる。

[0088] ソースデバイス５２０は、シンクデバイス５６０がサポートするＲＴＳＰ方法のセットを決定するために、シンクデバイス５６０に第１のメッセージ（ＲＴＳＰ ＯＰＴＩＯＮ要求メッセージ）を伝送することができる。ソースデバイス５２０からの第１のメッセージの受信の際、シンクデバイス５６０は、シンク５６０によってサポートされているＲＴＳＰ方法をリストする第２のメッセージ（ＲＴＳＰ ＯＰＴＩＯＮ応答メッセージ）で応答することができる。第２のメッセージはまた、ＲＴＳＰ ＯＫステータスコードを含むことができる。

[0089] ソースデバイス５２０に第２のメッセージを伝送した後、シンクデバイス５６０は、ソースデバイス５２０がサポートするＲＴＳＰ方法のセットを決定するために、第３のメッセージ（ＲＴＳＰ ＯＰＴＩＯＮ要求メッセージ）を伝送することができる。シンクデバイス５６０からの第３のメッセージの受信の際、ソースデバイス５２０は、ソースデバイス５２０によってサポートされているＲＴＳＰ方法をリストする第４のメッセージ（ＲＴＳＰ ＯＰＴＩＯＮ応答メッセージ）で応答することができる。第４のメッセージはまた、ＲＴＳＰ ＯＫステータスコードを含むことができる。

[0090] 第４のメッセージを伝送した後、ソースデバイス５２０は、ソースデバイス５２０にとって興味深い能力のリストを指定する第５のメッセージ（例えば、ＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ要求メッセージ）を伝送することができる。シンクデバイス５６０は、第６のメッセージ（ＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答メッセージ）で応答することができる。第６のメッセージは、ＲＴＳＰステータスコードを含むことができる。ＲＴＳＰステータスコードがＯＫである場合、第６のメッセージはまた、シンクデバイス５６０によってサポートされている第５のメッセージに指定されたパラメータへの応答パラメータを含むこともできる。シンクデバイス５６０は、シンクデバイス５６０がサポートしない第５のメッセージにおけるパラメータを無視することができる。

[0091] 第６のメッセージに基づいて、ソース５２０は、通信セッションのために使用されるべきパラメータの最適なセットを決定し、シンクデバイス５６０に第７のメッセージ（ＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ要求メッセージ）を伝送することができる。第７のメッセージは、ソースデバイス５２０とシンクデバイス５６０との間の通信セッション中に使用されるべきパラメータセットを含むことができる。第７のメッセージは、通信セッションをセットアップするためにＲＴＳＰセットアップ要求において使用されるべきユニバーサルリソース識別子（ＵＲＩ）を記述するｗｆｄ−ｐｒｅｓｅｎｔａｔｉｏｎ−ｕｒｌを含むことができる。ｗｆｄ−ｐｒｅｓｅｎｔａｔｉｏｎ−ｕｒｌは、シンクデバイス５６０がセッション確立交換中に後のメッセージのために使用することができるＵＲＩを指定する。このパラメータで指定されるｗｆｄ−ｕｒｌ０およびｗｆｄ−ｕｒｌ１の値は、第７のメッセージ内のｗｆｄ−ｃｌｉｅｎｔ−ｒｔｐ−ｐｏｒｔｓにおけるｒｔｐ−ｐｏｒｔ０値およびｒｔｐ−ｐｏｒｔ１値の値に対応することができる。第７のメッセージの受信の際に、シンクデバイス５６０は、第７のメッセージに指定されているようにパラメータを設定することが成功したかどうかを示すＲＴＳＰステータスコードを有する第８のメッセージで応答することができる。

[0092] 図７は、本開示の技法にしたがって能力ネゴシエーションを行うための、ソースデバイス５２０とシンクデバイス５６０との間の例示的なリアルタイムストリーミングプロトコル（ＲＴＳＰ）メッセージの転送シーケンスを例示する概略図である。ソースデバイス５２０とシンクデバイス５６０との間で伝送されるＲＴＳＰメッセージは、ヘッダと簡素なテキストのボディから成る。ボディのフォーマットは厳格に定義されておらず、本開示の技法にしたがって追加のテキストデータを含むように変更されうる。図７のＲＴＳＰメッセージの各々の中の合間の中のテキストは、各メッセージの例示的なボディを表す。

[0093] 図７の例は、どのようにＲＴＳＰ能力ネゴシエーションがＵＩＢＣをわたった双方向の通信およびトンネリングをサポートするために拡張されうるかを例示している。図７のメッセージ転送シーケンスは、図６に関して上で記述された転送シーケンスのより詳細なビューを提供するように意図されている。しかしながら図７の例では、メッセージシーケンスは、典型的なＵＩＢＣネゴシエーションシーケンスを例示している。しかしながら、図７はまた、双方向トンネリング能力が本開示の技法にしたがってサポートされているように記述されうる。

[0094] ＵＩＢＣ能力ネゴシエーションを開始するために、ソースデバイス５２０はＧＥＴ＿ＰＡＲＡＭＥＴＥＲ要求１ａを送信する。ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ要求１ａを受信することに応答して、シンクデバイス５６０はソースデバイス５２０にＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答１ｂを送信する。ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答１ｂはシンクデバイス５６０がサポートする入力カテゴリのリストを識別する。以前、ＵＩＢＣは、「包括的」および「ＨＩＤＣ（ヒューマンインタフェースデバイスクラス）」、の２つの一般的なカテゴリをサポートしていた。双方向（つまり、ＵＩＣ）通信をサポートするために、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答１ｂは、図７ではＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答１ｂと関係して例示されている追加の「トンネリング」カテゴリを含むように拡張されうる。ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答メッセージ内へのトンネリングカテゴリの包含は、シンクデバイス５６０がシンクデバイス５６０の特定の周辺装置の周辺データの双方向トンネリングをサポートすることをソースデバイス５２０に示すことができる。サポートされた入力カテゴリの各々に関して、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答１ｂはまた、その入力タイプのためのサポートされた能力の関連付けられたリスト（例えば、包括的入力タイプのための「ｇｅｎｅｒｉｃ＿ｃａｐ＿ｌｉｓｔ」およびＨＩＤＣ入力タイプのための「ｈｉｄｃ＿ｃａｐ＿ｌｉｓｔ」）を含むことができる。ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答１ｂはまた、ＴＣＰ／ＩＰポート番号を示すポートフィールドを含むことができる。シンクデバイス５６０は、ポートフィールドの値によって示されるＴＣＰ／ＩＰポート番号でソースデバイス５２０からカプセル化された周辺データを受信することができる。

[0095] 双方向トンネリングをサポートするために、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答メッセージ１ｂはまた、「ｉｎｐｕｔ＿ｉｎｔｅｒｆａｃｅ」フィールドとしても称されうる、入力インタフェースフィールドを含むように拡張されうる。追加のｉｎｐｕｔ＿ｉｎｔｅｒｆａｃｅフィールドはまた、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答１ｂと関係して上で例示されている。入力インタフェースフィールドは、インタフェース値を含むことができる。インタフェース値は、シンクデバイス５６０の周辺デバイスと関連付けられた特定の周辺インタフェースを示すことができる。例として、入力インタフェースフィールドの値は、ＳＤＩＯ、ＵＳＢ、ＢＬＵＥＴＯＯＴＨ、または他の周辺インタフェースのうちの１つを含むことができる。

[0096] 双方向トンネリングをサポートするために、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答メッセージ１ｂはまた、「ｆｏｒｗａｒｄｉｎｇ＿ｔｕｎｎｅｌ＿ＩＤ」としても称されうる、回送トンネル識別子フィールドを含むように拡張されうる。回送トンネル識別子は、ＵＩＢＣ能力ネゴシエーション中に送信されるＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答メッセージのボディの一部を備える追加のテキストのキーの値のペア（入力カテゴリおよび入力インタフェースと共に）を備えることができる。図７の例で、ＲＴＳＰメッセージの新たな回送トンネル識別子のシンタックスは、「ｆｏｒｗａｒｄｉｎｇ＿ｔｕｎｎｅｌ＿ＩＤ＝＃」であることができ、ここにおいて「＃」は、シンクデバイスの特定の周辺デバイスに割り当てられた回送トンネルの値である。

[0097] 回送トンネル識別子フィールドは、シンクデバイス（例えば、シンク５６０）に接続される周辺デバイスのインタフェースまたは特定の周辺デバイスを識別することができる。例として、シンクデバイス５６０のＢＬＵＥＴＯＯＴＨ周辺装置は、「１」の識別子を有しうる一方で、マウスのようなＵＳＢ周辺装置は「３」の識別子を有することができる。回送トンネル識別子は、ＵＩＣを使用してソースデバイスからカプセル化された周辺データを受信するシンクデバイスが、シンク５６０が１つよりも多い接続された周辺装置を有する場合に受信されたＵＩＣ周辺データがどの周辺装置に回送されるべきかを識別することを可能にする。

[0098] いくつかの例では、１つの周辺装置は、シンクデバイス５６０およびソースデバイス５２０が通信することができる複数のエンドポイントを含むことができる。デバイスのエンドポイントは、シンクデバイス５６０と接続された周辺デバイスとの間の１つまたは複数の異なる論理的なデータ接続を表すことができる。例えば、ＵＳＢ周辺装置は、バルクエンドポイント（bulk endpoint）、ならびに等時性エンドポイント（isochronous endpoint）を含むことができる。バルクエンドポイントは、ある特定のデータ転送特性を有する一方で、等時性エンドポイントは、データ転送特性の異なるセットを有することができる。シンク周辺デバイスが複数のエンドポイントを有する例では、シンクデバイス５６０は、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答１ｂにおいて周辺装置の複数のエンドポイントについての情報を通信することができる。シンクデバイス５６０は、複数のポート値のリストを送信することができ、各ポートフィールドは、シンク周辺装置の特定のエンドポイントに対応しうる。シンクデバイス５６０はまた、複数の回送トンネル識別子のリストを送信することができる。各回送トンネル識別子は、シンクデバイス５６０の特定のエンドポイントに対応することができる。

[0099] シンクデバイス５６０のホストインタフェースコントローラ１６５およびドライバ１６９（図１Ａ）は各接続された周辺デバイスの各々のエンドポイントを列挙することができる。シンクデバイス５６０は、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答１ｂがシンクデバイス５６０に接続された特定の周辺デバイスの各々の１つのエンドポイントの各々のリストを含むように、接続された周辺デバイスのエンドポイントを列挙することができる。ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ応答１ｂはまた、エンドポイントの各々に関するタイプ（例えば等時性、バルク等）を識別することができる追加のコンテキスト情報を含むことができる。

[00100] 図７では、メッセージ２ａ「ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＥＱＵＥＳＴ」は、ＲＴＳＰ ＵＩＢＣ能力ネゴシエーションの第２のメッセージの例である。メッセージ１ｂと同様に、メッセージ２ａは、サポートされた入力カテゴリ（例えば、トンネリング）のリスト、およびシンクデバイス５６０がサポートするＵＩＢＣデバイスについての関連するデバイス情報を含む。メッセージ１ｂと同様に、双方向周辺データのカプセル化をサポートするために、メッセージ２ａは「トンネリング」入力カテゴリ含むようにｉｎｐｕｔ＿ｃａｔｅｇｏｒｙ＿ｌｉｓｔフィールドを拡張することができる。サポートされた入力カテゴリの第２のリストのサポートされた入力カテゴリの各々は、サポートされた能力の関連付けられたリスト（例えば、ｇｅｎｅｒｉｃ＿ｃａｐ＿ｌｉｓｔおよびｈｉｄｃ＿ｃａｐ＿ｌｉｓｔ）を有することができる。メッセージ１ｂと同様に、メッセージ２ａはまた、ポートフィールドを含む。ポートフィールドの値は、ソースデバイス５２０が特定のシンク周辺デバイスまたはエンドポイントのためのカプセル化された周辺データを受信することができる特定のポートを示す。図７で例示されている例では、ポートフィールドの値は１００２であり、これは、ソースデバイス５２０がＴＣＰ／ＩＰポート１００２上でシンクデバイス５６０の周辺デバイスについてのカプセル化された周辺データを受信することをサポートすることを示すことができる。

[0100] メッセージ２ａはまた、ソースデバイス５２０によってサポートされる入力カテゴリおよびタイプを識別するけれども、それは、ソースデバイス５２０によってサポートされている全ての入力カテゴリおよび入力タイプの総合的なリストであるわけではない。その代わりに、メッセージ２ａ「ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＥＱＵＥＳＴ」は、シンクデバイス５６０によってサポートされているとして、メッセージ１ｂ「ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＥＳＰＯＮＳＥ」で識別されたそれらの入力カテゴリおよび入力タイプのみを識別することができる。この方法で、メッセージ２ａ、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＥＱＵＥＳＴ、で識別される入力カテゴリおよび入力タイプは、メッセージ１ｂで識別された入力カテゴリおよび入力タイプのサブセットの構成要素となることができる。図７で例示されている例では、メッセージ２ａはまた、入力カテゴリリストにトンネリング入力カテゴリを含む。トンネリング入力カテゴリの包含は、シンクデバイス５６０に、ソースデバイス５２０がまた、カプセル化された周辺データの双方向のトンネリングをサポートすることを示す。

[0101] ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＥＱＵＥＳＴ ２ａで図示されているフィールドに加えて、ソースデバイス５２０は、「ｒｅｖｅｒｓｅ＿ｔｕｎｎｅｌ＿ｉｄ」としても称されうる逆トンネル識別子でＧＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＥＳＰＯＮＳＥ １ｂに応答することができる。逆トンネル識別子は、回送トンネル識別子に類似しうる。逆トンネル識別子は、双方向周辺データカプセル化をサポートするために使用されることができ、ソースデバイス５２０に、シンクデバイス５６０のような特定のシンクデバイスを識別することができる。図７の例では、メッセージデバイス５２０は、「２」の値を有する逆トンネル識別子を含む。各シンクデバイス（例えば、シンクデバイス５６０）は、ＵＩＣパケットの伝送側としてその特定のシンクデバイスを識別するために、ソースデバイス５２０に送信されるあらゆるＵＩＣパケットに逆トンネリング識別子を含むことができる。ソースデバイス５２０が２つ以上のシンクデバイスと通信しているとき、ソースデバイス５２０は、複数のシンクデバイスの各々からのＵＩＣパケットを識別するために逆トンネル識別子値を利用することができる。

[0102] シンクデバイス５６０が、ソースデバイス５２０がメッセージ２ａで送信するＵＩＣパラメータと合意する場合、シンクデバイス５６０は、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＥＳＰＯＮＳＥメッセージ２ｂを送信することができる。ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＥＳＰＯＮＳＥメッセージ２ｂを受信することに応答して、ソースデバイス５２０は、ＵＩＢＣがメッセージ１ａ、１ｂ、および２ａにおいて以前にネゴシエートされたパラメータで有効にされることになることを承認するＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＥＱＵＥＳＴメッセージ３ａを送信することができる。ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＥＱＵＥＳＴメッセージ３ａを受信することに応答して、シンクデバイス５６０は、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＥＳＰＯＮＳＥメッセージ３ｂを送信することができる。ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ ＲＥＳＰＯＮＳＥ３ｂは、シンクデバイス５６０がＵＩＣをわたった通信に携わる準備ができていることをソースデバイス５２０に肯定応答することができる。

[0103] 一度ソースデバイス５２０およびシンクデバイス５６０がＵＩＣパラメータのセットに関して合意したとすると、ソースデバイス５２０およびシンクデバイス５６０はＵＩＣをわたってデータを送信することができる。シンクデバイス５６０およびソースデバイス５２０が両方ともＵＩＣトンネルに合意したために、両方のデバイスはＵＩＣ接続が、一方向とは反対に双方向であるだろうことを知っている。ソースデバイス５２０および５６０は、ＲＴＳＰ能力ネゴシエーション中に合意された（１つまたは複数の）ポートをわたってＵＩＣデータを伝送することができる。各ＵＩＣパケットは、特定のシンクデバイスを示すことができる逆トンネル識別子、またはシンクデバイス５６０に接続された特定の周辺装置または周辺インタフェースを識別することができる回送トンネル識別子を含むことができる。

[0104] ソースデバイス５２０は、１度よりも多く図７で例示されているようにＲＴＳＰ通信およびＵＩＣ能力ネゴシエーションに携わることができる。例として、ソースデバイス５２０は、ソースデバイス５２０が通信している各シンクデバイスに接続された周辺デバイス毎に一度ＲＴＳＰ ＵＩＣ能力ネゴシエーションに携わりうる。複数の能力ネゴシエーションは、各周辺デバイスに異なる回送トンネル識別子を割り当て、ソースデバイス５２０が通信することができる複数のシンクデバイスの各シンクデバイスに逆トンネリング識別子を割り当てるために使用されうる。

[0105] 図８は、本開示の技法にしたがって、カプセル化された周辺データの双方向トンネリングをインプリメントすることができるソースデバイスの例を例示するブロック図である。ソースデバイス６００は、図２で提供されたデータ通信モデルを組み込むＷＤシステムの一部でありうる。ソースデバイス６００は、トランスポート、ストレージ、および／またはディスプレイのためのメディアデータを符号化および／または復号するように構成されうる。ソースデバイス６００は、メモリ６０２、ディスプレイプロセッサ６０４、局所的ディスプレイ６０６、音声プロセッサ６０８、スピーカ６１０、映像エンコーダ６１２、映像パケタイザ（packetizer）６１４、音声エンコーダ６１６、音声パケタイザ６１８、Ａ／Ｖマルチプレクサ（ｍｕｘ）６２０、トランスポートモジュール６２２、モデム６２４、制御モジュール６２６、フィードバックデパケタイザ（de-packetizer）６２８、およびフィードバックモジュール６３０を含む。ソースデバイス６００のコンポーネントは、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらのあらゆる組み合わせのような、様々な適した回路のいずれかとしてインプリメントされうる。

[0106] メモリ６０２は、圧縮または非圧縮されたフォーマットにおいて、メディアデータの形態でＡ／Ｖ画像データを記憶することができる。メモリ６０２は、全体のメディアデータファイルを記憶することができる、あるいは、例えば別のデバイスまたはソースからストリーミングされたメディアデータファイルの一部を単に記憶するより小さなバッファを備えることができる。メモリ６０２は、シンクロナス動的ランダムアクセスメモリ（ＳＤＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電子的に消去可能なプログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、ＦＬＡＳＨメモリ等のようなランダムアクセスメモリ（ＲＡＭ）に限定されないけれども含む、幅広い種類の揮発性または非揮発性メモリのいずれかも備えることができる。メモリ６０２は、メディアデータを、他の種類のデータと同様に、記憶するためのコンピュータ可読記憶媒体を備えることができる。加えて、メモリ６０２は、本開示で記述されている様々な技法を行うことの一部としてプロセッサによって実施されるプログラムコードおよび命令を記憶することができる。

[0107] ディスプレイプロセッサ６０４は、捕捉された映像フレームを取得し、局所的ディスプレイ６０６上の表示のために映像データを処理することができる。ディスプレイ６０６は、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、またはソースデバイス６００のユーザに映像データを表示することができる別のタイプのディスプレイデバイスのような、様々なディスプレイデバイスの１つを備える。

[0108] オーディオプロセッサ６０８は、音声捕捉された音声サンプルを取得し、スピーカ６１０への出力のために音声データを処理することができる。スピーカ６１０は、ヘッドフォン、単一スピーカシステム、マルチスピーカシステム、またはサラウンド音響システムのような様々な音声出力デバイスのいずれも備えることができる。

[0109] 映像エンコーダ６１２は、メモリ６０２から映像データを取得し、所望の映像フォーマットに映像データを符号化することができる。映像エンコーダ６１２は、図２と関係して上で記述された映像コデック２１８の態様をインプリメントするように使用されるハードウェアとソフトウェアの組み合わせでありうる。映像エンコーダ６１２は、ＩＴＵ−Ｔ Ｈ．２６１、ＩＳＯ／ＩＥＣ ＭＰＥＧ−１ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６２またはＩＳＯ／ＩＥＣ ＭＰＥＧ−２ Ｖｉｓｕａｌ、ＩＴＵ−Ｔ Ｈ．２６３、ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ Ｖｉｓｕａｌ、（ＩＳＯ／ＩＥＣ ＭＰＥＧ−４ ＡＶＣとしても知られる）ＩＴＵ−Ｔ Ｈ．２６４、ＶＰ８、および高効率映像コーディング（ＨＥＶＣ）のような映像圧縮規格のあらゆる数にしたがって映像を符号化することができる。いくつかのケースでは、映像エンコーダ６１２は、映像データが損失のない、または損失の多い（lossy）圧縮技法を使用して圧縮されるように映像を符号化することができることは留意されるべきである。

[0110] 映像パケタイザ６１４は、符号化された映像データをパケット化することができる。１つの例では、映像パケタイザ６１４は、ＭＰＥＧ−２Ｐａｒｔ１にしたがって定義されたような符号化された映像データをパケット化することができる。他の例では、映像データは、他のパケット化プロトコルにしたがってパケット化されうる。映像パケタイザ６１４は、図２と関係して上で記述されたパケット化エレメンタリストリーム（ＰＥＳ）パケット化２１６の態様をインプリメントするように使用されるハードウェアとソフトウェアの組み合わせでありうる。

[0111] 音声エンコーダ６１６は、メモリ６０２から音声データを取得し、所望の音声フォーマットに音声データを符号化することができる。音声エンコーダ６１６は、図２と関係して上で記述された音声コデック２２０の態様をインプリメントするように使用されるハードウェアとソフトウェアの組み合わせでありうる。音声データは、Ｄｏｌｂｙおよびデジタルシアターシステムによって発展されたもののようなマルチチャネルフォーマットを使用してコード化されうる。音声データは、圧縮または非圧縮されたフォーマットを使用してコード化されうる。圧縮された音声フォーマットの例は、ＭＰＥＧ−１、２、音声レイヤＩＩおよびＩＩＩ、ＡＣ−３、ＡＡＣを含む。非圧縮された音声フォーマットの例は、パルス−コード変調（ＰＣＭ）音声フォーマットを含む。

[0112] 音声パケタイザ６１８は、符号化された音声データをパケット化することができる。１つの例では、音声パケタイザ６１８は、ＭＰＥＧ―２Ｐａｒｔ１にしたがって定義されたような符号化された音声データをパケット化することができる。他の例では、音声データは、他のパケット化プロトコルにしたがってパケット化されうる。音声パケタイザ６１８は、図２と関係して上で記述されたパケット化エレメンタリストリーム（ＰＥＳ）パケット化２１６の態様をインプリメントするように使用されるハードウェアとソフトウェアの組み合わせでありうる。

[0113] Ａ／Ｖマルチプレクサ６２０は、共有データストリームの一部として映像ペイロードデータおよび音声ペイロードデータを組み合わせるための多重化技法を適用することができる。１つの例では、Ａ／Ｖマルチプレクサ６２０は、ＭＰＥＧ―２Ｐａｒｔ１にしたがって定義されるＭＰＥＧ２トランスポートストリームとしてパケット化されたエレメンタリ映像および音声ストリームをカプセル化することができる。Ａ／Ｖマルチプレクサ６２０は、エラー訂正技法と同様に音声および映像パケットに対して同期を提供することができる。

[0114] トランスポートモジュール６２２は、シンクデバイスへのトランスポートのためにメディアデータを処理することができる。さらにトランスポートモジュール６２２は、シンクデバイスから受信されたパケットを、それらがさらに処理されうるように処理することができる。例えば、トランスポートモジュール６２２は、ＩＰ、ＴＣＰ、ＵＤＰ、ＲＴＰ、およびＲＴＳＰを使用して通信するように構成されうる。例えば、トランスポートモジュール６２２はさらに、シンクデバイスへの、あるいはネットワークをわたった通信のためのＭＰＥＧ２−ＴＳをカプセル化することができる。

[0115] モデム６２４は、ＷＤシステムで利用される物理およびＭＡＣレイヤにしたがって物理およびＭＡＣレイヤ処理を行うように構成されうる。図２を参照して記述されるように。物理およびＭＡＣレイヤは、ＷＤシステムにおける通信のために使用される物理シグナリング、アドレス指定（addressing）、およびチャネルアクセス制御を定義することができる。１つの例では、モデム６２４は、ＷＦＤによって提供されるもののような、Ｗｉ−Ｆｉ（例えば、ＩＥＥＥ ８０２．１１ｘ）規格によって定義された物理およびＭＡＣレイヤのための物理レイヤおよびＭＡＣレイヤ処理を行うように構成されうる。他の例では、モデム６２４は、ワイヤレスＨＤ、ＷｉＭｅｄｉａ、ワイヤレスホームデジタルインタフェース（ＷＨＤＩ）、ＷｉＧｉｇ、およびワイヤレスＵＳＢ、のいずれかのための物理レイヤおよびＭＡＣレイヤ処理を行うように構成されうる。

[0116] 制御モジュール６２６は、ソースデバイス６００通信制御機能を行うように構成されうる。通信制御機能は、シンクデバイスと能力をネゴシエートすることと、シンクデバイスとのセッションを確立することと、ならびにセッション維持および管理に関しうる。制御モジュール６２６は、シンクデバイスと通信するためにＲＴＳＰを使用することができる。さらに、制御モジュール６２６は、ＵＩＢＣ上のトンネリング入力カテゴリをサポートするためにソースデバイス６００およびシンクデバイスの能力をネゴシエートするように、ＲＴＳＰメッセージトランザクションを使用してＵＩＢＣを確立することができる。いくつかの例では、制御モジュール６２６は、本開示の技法にしたがって、カプセル化された周辺データの双方向トンネルを確立することができる。

[0117] ユーザ入力モジュール６２８は、トンネリングパケットを含みうる、ＵＩＢＣパケットから、ヒューマンインタフェースデバイスコマンド（ＨＩＤＣ）、包括的ユーザ入力、ＯＳ特有ユーザ入力、およびカプセル化された情報を解析することができる。１つの例では、ユーザ入力パケットは、図４と関係して記述されたメッセージフォーマットを使用することができる。この例では、ユーザ入力デパケタイザ６２８は、どのようにユーザ入力パケットヘッダにおけるユーザ入力カテゴリフィールドの値に部分的に基づいてユーザ入力パケットを解析するかを決定することができる。１つの例として、ユーザ入力カテゴリフィールドは、フィードバックパケットペイロードデータが包括的情報要素を使用してフォーマットされることを示すために包括的入力カテゴリを識別することができる。別の例として、ユーザ入力カテゴリフィールドは、ヒューマンインタフェースデバイスコマンド（ＨＩＤＣ）入力カテゴリを識別することができる。別の例として、ユーザ入力カテゴリフィールドは、ペイロードデータが、ソースデバイスまたはシンクデバイスのどちらかによって使用されるオペレーティングシステム（ＯＳ）のタイプに基づいてフォーマットされることを示すためのＯＳ特有入力カテゴリを識別することができる。

[0118] 別の例では、ユーザ入力モジュール６２８は、ユーザ入力パケットのヘッダのユーザ入力カテゴリフィールドに基づいてカプセル化された周辺データを識別することができる。ユーザ入力モジュール６２８がカプセル化されたデータを識別する場合、ドライバ６３２は、図４と関係して上で記述された方法で周辺データをカプセル化解除することができる。いくつかの例では、ドライバ６３２は、１つまたは複数の受信されたユーザ入力パケットのペイロードを組み合わせ、組み合わせられたペイロードにインタフェース特有ヘッダを加えることができる。ホストインタフェースコントローラ６３０は、インタフェース特有パケットを処理することができる。いくつかの例では、メモリ６０２は、ディスプレイプロセッサ６０４がデータへの動作を実行することができるように、パケットのデータの少なくともいくつかを記憶することができる。

[0119] ホストインタフェースコントローラ６３０はまた、インタフェース特有パケットを構築することができる。ドライバ６３２は、本開示の技法にしたがって、より小さなパケットにインタフェース特有パケットを分け、ＵＩＣを使用してそのより小さなパケットをカプセル化することができる。ユーザ入力モジュール６２８は、ドライバ６３２からカプセル化された周辺データを受信することができ、トランスポートモジュール６３２は、ＵＩＣをわたり、モデム６２４を使用してカプセルされた周辺装置を送信することができる。

[0120] 図９は、ソースデバイスへの、およびソースデバイスからの周辺データの双方向トンネリングをサポートするための技法をインプリメントするシンクデバイスの例を例示するブロック図である。シンクデバイス７００は、図２で提供されるデータ通信モデルを組み込むＷＤシステムの一部でありうる。１つの例では、シンクデバイス７００は、ソースデバイス６００とのＷＤシステムを形成することができる。シンクデバイス７００は、モデム７０２、トランスポートモジュール７０４、Ａ／Ｖデマルチプレクサ（ｄｅｍｕｘ）７０６、映像デパケタイザ７０８、映像デコーダ７１０、ディスプレイプロセッサ７１２、ディスプレイ７１４、音声デパケタイザ７１６、音声デコーダ７１８、音声プロセッサ７２０、スピーカ７２２、ユーザ入力モジュール７２４、制御モジュール７３０、ドライバ７３４、およびホストインタフェースコントローラ７３６を含む。シンクデバイス７００のコンポーネントは各々、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらのあらゆる組み合わせのような、様々な適した回路のいずれかとしてインプリメントされうる。

[0121] モデム７０２は、ＷＤシステムで利用される物理およびＭＡＣレイヤにしたがって物理およびＭＡＣレイヤ処理を行うように構成されうる。図２を参照して記述されるように。物理およびＭＡＣレイヤは、ＷＤシステムにおける通信のために使用される物理シグナリング、アドレス指定、およびチャネルアクセス制御を定義することができる。１つの例では、モデム７０２は、ＷＦＤによって提供されるもののような、Ｗｉ−Ｆｉ（例えば、ＩＥＥＥ８０２．１１ｘ）規格によって定義された物理およびＭＡＣレイヤのための物理レイヤおよびＭＡＣレイヤ処理を行うように構成されうる。他の例では、モデム７０２は、ワイヤレスＨＤ、ＷｉＭｅｄｉａ、ワイヤレスホームデジタルインタフェース（ＷＨＤＩ）、ＷｉＧｉｇ、およびワイヤレスＵＳＢ、のいずれかのための物理レイヤおよびＭＡＣレイヤ処理を行うように構成されうる。

[0122] トランスポートモジュール７０４は、ソースデバイスから受信されたメディアデータを処理することができる。さらに、トランスポートモジュール７０４は、ソースデバイスへのトランスポートのためにＵＩＢＣパケットを処理することができる。例えば、トランスポートモジュール７０４は、ＩＰ、ＴＣＰ、ＵＤＰ、ＲＴＰ、およびＲＴＳＰを使用して通信するように構成されうる。加えて、トランスポート７０４は、ＩＰ、ＴＣＰ、ＵＤＰ、ＲＴＰ、およびＲＳＴＰパケットのあらゆる組み合わせにおけるタイムスタンプ値を含むことができる。

[0123] Ａ／Ｖデマルチプレクサ７０６は、データストリームから映像ペイロードデータおよび音声ペイロードデータを区別するための逆多重化技法を適用することができる。１つの例では、Ａ／Ｖマルチプレクサ７０６は、ＭＰＥＧ―２Ｐａｒｔ１にしたがって定義されるＭＰＥＧ２トランスポートストリームのパケット化されたエレメンタリ映像および音声ストリームを区別することができる。

[0124] 映像デパケタイザ７０８および映像デコーダ７１０は、ここで記述されているパケット化およびコーディング技法をインプリメントする映像パケタイザおよび映像エンコーダの互恵的（reciprocal）処理を行い、ディスプレイプロセッサ７１２に映像データを出力することができる。

[0125] ディスプレイプロセッサ７１２は、捕捉された映像フレームを取得し、ディスプレイ７１４上での表示のために映像データを処理することができる。ディスプレイ７１４は、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイのような、様々なディスプレイデバイスの１つを備えることができる。

[0126] 音声デパケタイザ７１６および音声デコーダ７１８は、ここで記述されているパケット化およびコーディング技法をインプリメントする音声パケタイザおよび音声エンコーダの互恵的処理を行い、ディスプレイプロセッサ７２０に音声データを出力することができる。

[0127] 音声プロセッサ７２０は、音声デコーダから音声データを取得し、スピーカ７２２への出力のために音声データを処理することができる。スピーカ７２２は、ヘッドフォン、単一スピーカシステム、マルチスピーカシステム、またはサラウンド音響システムのような様々な音声出力デバイスのいずれも備えることができる。

[0128] ユーザ入力デバイス７２４は、例えば、キーボード、マウス、トラックボールまたはトラックパッド、タッチスクリーン、ボイスコマンド認識モジュール、またはあらゆる他のそのようなユーザ入力デバイスによって受信されたユーザ入力コマンドをフォーマットすることができる。１つの例では、ユーザ入力モジュール７２４は、図２と関係して上で記述されたヒューマンインタフェースデバイスコマンド（ＨＩＤＣ）２３０、包括的ユーザ入力２３２、ＯＳ特有ユーザ入力２３４、および双方向周辺データトンネル２２８にしたがって定義されるフォーマットにしたがってユーザ入力コマンドをフォーマットすることができる。

[0129] ユーザ入力モジュール７２４はまた、ユーザ入力パケットのヘッダのユーザ入力フィールドに基づいて、トランスポートモジュール７２４からの周辺データを識別することができる。ドライバ７３４は、ホストインタフェースコントローラが処理し、周辺デバイス７３６に送信することができる１つまたは複数のインタフェース特有パケットに周辺データをカプセル化解除することができる。別の例では、周辺デバイス７３６は、周辺データをホストインタフェースコントローラ７３６に送信することができる。ドライバ７３４は、ホストインタフェースコントローラ７３６を制御、またはホストインタフェースコントローラ７３６と相互動作することができ、双方向ＵＩＣパケットに周辺データをカプセル化することができる。ユーザ入力モジュール７２４は、トランスポートモジュール７０４に双方向ＵＩＣパケットを送信することができ、トランスポートモジュール７０４は、モデム７０２を使用してパケットを送信することができる。

[0130] 制御モジュール７３０は、通信制御機能を行うように構成されうる。通信制御機能は、ソースデバイスと能力をネゴシエートすることと、ソースデバイスとのセッションを確立することと、ならびにセッション維持および管理に関しうる。制御モジュール７３０は、ソースデバイスと通信するためにＲＴＳＰを使用することができる。さらに、制御モジュール７３０は、ＵＩＢＣおよびＵＩＢＣ上のトンネリング入力カテゴリをサポートするためにシンクデバイス７００およびソースデバイスの能力をネゴシエートするように、ＲＴＳＰメッセージトランザクションを使用して周辺データのカプセル化をサポートする、双方向ＵＩＣのような、ＵＩＢＣを確立しうる。双方向ＵＩＣを確立するためのＲＴＳＰネゴシエーションの使用は、メディア共有セッションを確立するためにＲＴＳＰネゴシエーションプロセスを使用することに類似しうる。

[0131] 図１０は、本開示の技法にしたがって、周辺データの双方向トンネリングをサポートするための技法を例示するフローチャートである。本技法では、ソースデバイスは、シンクデバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立することができる（８０１）。ソースデバイスは、ＵＩＢＣを使用してシンクデバイスからカプセル化された周辺データを受信することができる（８０２）。ソースデバイスはその後、周辺データをカプセル化解除することができる（８０３）。いくつかの例では、ソースデバイスは、ソースデバイスのホストインタフェースコントローラ（例えば、図１Ａのホストインタフェースコントローラ１６５および１２７のうちの１つ）にカプセル化解除された周辺データを送信することができる。ソースデバイスはまた、ソースデバイスへのシンクデバイスの周辺デバイスを識別するトンネル識別子値を受信することができる。いくつかの例では、周辺データはＵＩＢＣパケットにカプセル化されうる。いくつかの例では、ソースデバイスはまた、ソースデバイスへのシンクデバイスの周辺デバイスを識別するトンネル識別子値を受信することができる。

[0132] 図１１は、本開示の技法にしたがって、周辺データの双方向トンネリングをサポートするための技法を例示するフローチャートである。本技法では、シンクデバイスは、ソースデバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立することができる（８２１）。シンクデバイスは、ＵＩＢＣを使用してソースデバイスからカプセル化された周辺データを受信することができる（８２２）。シンクデバイスはその後、周辺データをカプセル化解除することができる（８２３）。いくつかの例では、シンクデバイスは周辺デバイス（例えば、図１Ａの周辺デバイス１７０ののうちの１つ）にカプセル化解除された周辺データを送信することができる。いくつかの例では、シンクデバイスはまた、第１のデバイスへの双方向ＵＩＢＣを確立する前にシンクデバイスに接続される周辺デバイスのインタフェースを列挙することができる。いくつかの例では、シンクデバイスは、シンクデバイスの周辺デバイスを識別するソースデバイスからトンネル識別子値を受信することができる。

[0133] カプセル化された周辺データは、ここで記述されているあらゆるメッセージフォーマットにしたがってフォーマットされ、ここで記述されているあらゆるタイプの情報を含むことができる。例えば、周辺データは、図４と関係して記述されたメッセージフォーマットにしたがってフォーマットされうる。

[0134] 図１２は、周辺データの双方向トンネリングをサポートするための技法を例示するフローチャートである。シンクデバイスは、ソースデバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立することができる（９０１）。シンクデバイスは、周辺データを受信し（９０２）、周辺データをカプセル化することができる（９０３）。シンクデバイスはまた、ＵＩＢＣを使用してソースデバイスにカプセル化された周辺データを送信することもできる（９０４）。いくつかの例では、シンクデバイスはシンクデバイスの周辺デバイス（例えば、図１Ａの周辺デバイス１７０のうちの１つ）から周辺データを受信することができる。ある例では、シンクデバイスは、ソースのデバイスへの双方向ＵＩＢＣを確立する前にシンクデバイスに接続されている周辺デバイスのインタフェースを列挙することができる。いくつかの例では、シンクデバイスはまた、シンクデバイスの周辺デバイスを識別するトンネル識別子値をソースデバイスに送信することができる。

[0135] 図１３は、周辺データの双方向トンネリングをサポートするための技法を例示するフローチャートである。ソースデバイスは、シンクデバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立することができる（９２１）。ソースデバイスは、周辺データを受信し（９２２）、周辺データをカプセル化することができる（９２３）。ソースデバイスはまた、ＵＩＢＣを使用してシンクデバイスにカプセル化された周辺データを送信することができる（９２４）。いくつかの例では、ソースデバイスは、ホストインタフェースコントローラ（例えば、図１Ａのホストインタフェースコントローラ１６５および１２７のうちの１つ）から周辺データを受信することもできる。いくつかの例では、ソースデバイスは、シンクデバイスの周辺デバイスを識別するトンネル識別子値をシンクデバイスに送信することができる。

[0136] カプセル化された周辺データは、ここで記述されているあらゆるメッセージフォーマットにしたがってフォーマットされ、ここで記述されているあらゆるタイプの情報を含むことができる。例えば、周辺データは、図４と関係して記述されたメッセージフォーマットにしたがってフォーマットされうる。

[0137] １つまたは複数の例では、記述された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらのあらゆる組み合わせでインプリメントされうる。ソフトウェアでインプリメントされる場合、機能は、コンピュータ可読媒体上で１つまたは複数の命令またはコードとして記憶または送信されうる。コンピュータ可読媒体は、１つの場所から別の場所へのコンピュータプログラムの転送を容易にするあらゆる媒体を含むコンピュータデータ記憶媒体または通信媒体の両方を含みうる。いくつかの例では、コンピュータ可読媒体は、非トランジトリなコンピュータ可読媒体を備えうる。データ記憶媒体は、本開示において記述された技法のインプリメンテーションのための命令、コード、および／またはデータ構造を読み取るために、１つまたは複数のコンピュータ、あるいは１つまたは複数のプロセッサによってアクセスされることができるあらゆる利用可能な媒体でありうる。

[0138] 限定ではなく例として、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置または他の磁気記憶デバイス、フラッシュメモリ、あるいは、データ構造または命令の形態で所望のプログラムコードを記憶または搬送するために使用されることができ、かつコンピュータによってアクセスされうるあらゆる他の媒体のような、非トランジトリな媒体を備えることができる。また、いずれの接続手段もコンピュータ可読媒体と適切に名づけられる。ディスク（ｄｉｓｋ）およびディスク（ｄｉｓｃ）は、ここで使用される場合、コンパクト・ディスク（ｄｉｓｃ）（ＣＤ）、レーザーディスク（登録商標）（ｄｉｓｃ）、光ディスク（ｄｉｓｃ）、デジタル多用途ディスク（ｄｉｓｃ）（ＤＶＤ）、フロッピー（登録商標）ディスク（ｄｉｓｋ）、およびブルーレイ（登録商標）ディスク（ｄｉｓｃ）を含み、ディスク（ｄｉｓｋ）は通常、磁気的にデータを再生するが、ディスク（ｄｉｓｃ）は通常、レーザーを用いて光学的にデータを再生する。上記の組み合わせは、また、コンピュータ可読媒体の範囲内に含まれるべきである。

[0139] コードは、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、あるいは、他の同等な集積またはディスクリートな論理回路、のような１つまたは複数のプロセッサによって実施されうる。したがって、ここで使用されるような「プロセッサ」という用語は、前述の構造、またはここで記述されている技法のインプリメンテーションに適したあらゆる他の構造のいずれかを称しうる。さらに、いくつかの態様では、ここで記述されている機能は、符号化および復号化のために構成された専用ハードウェアモジュールおよび／またはソフトウェアモジュール内で提供されうる、または、組み合わせられたコデックに組み込まれうる。また、技法は、１つまたは複数の回路または論理要素において十分にインプリメントされることができる。

[0140] 本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（例えば、チップセット）を含む、幅広い種類のデバイスまたは装置においてインプリメントされうる。様々なコンポーネント、モジュール、またはユニットは、開示された技法を行うように構成されたデバイスの機能的な態様を強調するために本開示で記述されているけれども、必ずしも異なるハードウェアユニットによる実現を要求しない。むしろ、上で記述されたように、様々なユニットはコデックハードウェアユニットで組み合わせられうる、あるいは、適したソフトウェアおよび／またはファームウェアと関連して、上で記述された１つまたは複数のプロセッサを含む、対話型（interoperative）ハードウェアユニットの集合によって提供されうる。

［0141] 本発明の様々な実施形態が記述されてきた。これらおよび他の実施形態は、特許請求の範囲の範囲内にある。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立することと、
前記ＵＩＢＣを使用して、前記計算デバイスからカプセル化された周辺データを受信することと、
前記周辺データをカプセル化解除することと、
を備える方法。
［Ｃ２］前記計算デバイスは、シンクデバイスを備え、
前記カプセル化された周辺データを受信することは、前記ＵＩＢＣを使用して、ソースデバイスにおいて、前記シンクデバイスから前記カプセル化された周辺データを受信することを備える、Ｃ１に記載の方法。
［Ｃ３］前記ソースデバイスのホストインタフェースコントローラに前記カプセル化解除された周辺データを送信すること、をさらに備える、Ｃ２に記載の方法。
［Ｃ４］前記方法は、
周辺デバイスを識別するトンネル識別子値を受信すること、
をさらに備える、Ｃ１に記載の方法。
［Ｃ５］前記計算デバイスは、ソースデバイスを備え、前記カプセル化された周辺データを受信することは、前記ＵＩＢＣを使用して、シンクデバイスおいて、前記ソースデバイスから前記カプセル化された周辺データを受信することを備える、Ｃ１に記載の方法。
［Ｃ６］前記ソースデバイスへの前記双方向ＵＩＢＣを確立する前に、前記シンクデバイスに接続される周辺デバイスのインタフェースを列挙すること、をさらに備える、Ｃ５に記載の方法。
［Ｃ７］前記シンクデバイスに接続される周辺デバイスに前記カプセル化解除された周辺データを送信すること、
をさらに備える、Ｃ５に記載の方法。
［Ｃ８］前記カプセル化された周辺データは、ＵＩＢＣパケットにカプセル化される、Ｃ１に記載の方法。
［Ｃ９］計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立することと、
周辺データを受信することと、
前記周辺データをカプセル化することと、
前記ＵＩＢＣを使用して、前記計算デバイスに前記カプセル化された周辺データを送信することと、
を備える方法。
［Ｃ１０］前記計算デバイスは、ソースデバイスを備え、前記カプセル化された周辺データを送信することは、前記ＵＩＢＣを使用して、シンクデバイスから前記ソースデバイスに、前記周辺データを送信することを備える、Ｃ９に記載の方法。
［Ｃ１１］前記周辺データを受信することは、前記シンクデバイスの周辺デバイスから前記周辺データを受信することを備える、Ｃ１０に記載の方法。
［Ｃ１２］前記方法は、
前記ソースデバイスへの前記双方向ＵＩＢＣを確立する前に、前記シンクデバイスの周辺デバイスのインタフェースを列挙すること、
をさらに備える、Ｃ１０に記載の方法。
［Ｃ１３］前記方法は、
周辺デバイスを識別するトンネル識別子値を送信すること、
をさらに備える、Ｃ９に記載の方法。
［Ｃ１４］前記計算デバイスは、シンクデバイスを備え、前記カプセル化された周辺データを送信することは、前記ＵＩＢＣを使用して、ソースデバイスから前記シンクデバイスに、前記周辺データを送信することを備える、Ｃ９に記載の方法。
［Ｃ１５］前記周辺データを受信することは、ホストインタフェースコントローラから前記周辺データを受信することを備える、Ｃ１４に記載の方法。
［Ｃ１６］前記カプセル化された周辺データは、ＵＩＢＣパケットにカプセル化される、Ｃ９に記載の方法。
［Ｃ１７］第２の計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立し、
前記ＵＩＢＣを使用して、前記第２の計算デバイスからカプセル化された周辺データを受信し、
前記周辺データをカプセル化解除する、
ように構成されたユーザインタフェースバックチャネル（ＵＩＢＣ）モジュールを備える、第１の計算デバイス。
［Ｃ１８］前記第１の計算デバイスは、ソースデバイスを備え、前記第２の計算デバイスはシンクデバイスを備え、前記カプセル化された周辺データを受信するために、前記ＵＩＢＣモジュールは、
前記ＵＩＢＣを使用して、前記ソースデバイスにおいて、前記シンクデバイスから前記カプセル化された周辺データを受信する、
ように構成される、Ｃ１７に記載の第１の計算デバイス。
［Ｃ１９］前記ＵＩＢＣモジュールは、
前記ソースデバイスのホストインタフェースコントローラに前記カプセル化解除された周辺データを送信する、
ようにさらに構成される、Ｃ１８に記載の第１の計算デバイス。
［Ｃ２０］前記ＵＩＢＣモジュールは、
周辺デバイスを識別するトンネル識別子値を受信する、
ようにさらに構成される、Ｃ１７に記載の第１の計算デバイス。
［Ｃ２１］前記第１の計算デバイスは、シンクデバイスを備え、前記第２の計算デバイスはソースデバイスを備え、前記カプセル化された周辺データを受信するために、前記ＵＩＢＣモジュールは、
前記ＵＩＢＣを使用して、前記シンクデバイスにおいて、前記ソースデバイスから前記カプセル化された周辺データを受信する、
ように構成される、Ｃ１７に記載の第１の計算デバイス。
［Ｃ２２］前記ＵＩＢＣモジュールは、
前記第２のデバイスへの前記双方向ＵＩＢＣを確立する前に、前記シンクデバイスの周辺デバイスのインタフェースを列挙するようにさらに構成される、Ｃ２１に記載の第１の計算デバイス。
［Ｃ２３］前記ＵＩＢＣモジュールは、
前記シンクデバイスに接続される周辺デバイスに前記カプセル化解除された周辺データを送信する、
ようにさらに構成される、Ｃ２１に記載の第１の計算デバイス。
［Ｃ２４］前記カプセル化された周辺データは、ＵＩＢＣパケットにカプセル化される、Ｃ１７に記載の第１の計算デバイス。
［Ｃ２５］第２の計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立し、
周辺データを受信し、
前記周辺データをカプセル化し、
前記ＵＩＢＣを使用して、前記第２の計算デバイスに前記カプセル化された周辺データを送信する、
ように構成されたユーザインタフェースバックチャネル（ＵＩＢＣ）モジュールを備える第１の計算デバイス。
［Ｃ２６］前記第１の計算デバイスは、シンクデバイスを備え、前記第２の計算デバイスはソースデバイスを備え、前記カプセル化された周辺データを送信するために、前記ＵＩＢＣモジュールは、
前記ＵＩＢＣを使用して、前記シンクデバイスから前記ソースデバイスに前記周辺データを送信する、
ように構成される、Ｃ２５に記載の第１の計算デバイス。
［Ｃ２７］前記周辺データを受信するために、前記ＵＩＢＣモジュールは、
前記シンクデバイスの周辺デバイスから前記周辺データを受信するように構成される、Ｃ２６に記載の第１の計算デバイス。
［Ｃ２８］前記ＵＩＢＣモジュールは、
前記ソースデバイスへの前記双方向ＵＩＢＣを確立する前に、前記シンクデバイスに接続される周辺デバイスのインタフェースを列挙する、
ようにさらに構成されるＣ２６に記載の第１の計算デバイス。
［Ｃ２９］前記ＵＩＢＣモジュールは、
周辺デバイスを識別するトンネル識別子値を送信する、
ようにさらに構成される、Ｃ２６に記載の第１の計算デバイス。
［Ｃ３０］前記第１の計算デバイスは、ソースデバイスを備え、前記第２の計算デバイスはシンクデバイスを備え、前記カプセル化された周辺データを受信するために、前記ＵＩＢＣモジュールは、
前記ＵＩＢＣを使用して、前記ソースデバイスにおいて、前記シンクデバイスから前記カプセル化された周辺データを受信する、
ように構成される、Ｃ２５に記載の第１の計算デバイス。
［Ｃ３１］前記周辺データを受信するために、前記ＵＩＢＣモジュールは、
ホストインタフェースコントローラから前記周辺データを受信する、
ようにさらに構成される、Ｃ２５に記載の第１の計算デバイス。
［Ｃ３２］前記カプセル化された周辺データは、ＵＩＢＣパケットにカプセル化される、Ｃ２５に記載の第１の計算デバイス。
［Ｃ３３］第２の計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立するための手段と、
前記ＵＩＢＣを使用して、前記第２の計算デバイスからカプセル化された周辺データを受信するための手段と、
前記周辺データをカプセル化解除するための手段と、
を備える、第１の計算デバイス。
［Ｃ３４］第２の計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立するための手段と、
周辺データを受信するための手段と、
前記周辺データをカプセル化するための手段と、
前記ＵＩＢＣを使用して、前記第２の計算デバイスに前記カプセル化された周辺データを送信するための手段と、
を備える第１の計算デバイス。
［Ｃ３５］命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、１つまたは複数のプロセッサに、
計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立することと、
前記ＵＩＢＣを使用して、前記計算デバイスからカプセル化された周辺データを受信することと、
前記周辺データをカプセル化解除することと、
を行わせる、コンピュータ可読記憶媒体。
［Ｃ３６］命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、１つまたは複数のプロセッサに、
計算デバイスへの双方向ユーザインタフェースバックチャネル（ＵＩＢＣ）を確立することと、
周辺データを受信することと、
前記周辺データをカプセル化することと、
前記ＵＩＢＣを使用して、前記計算デバイスに前記カプセル化された周辺データを送信することと、
を行わせる、コンピュータ可読記憶媒体。

Claims (12)

1. ソースデバイスにおいて、前記ソースデバイスとシンクデバイスとの間のユーザインタフェースバックチャネル（ＵＩＢＣ）を介した双方向通信をサポートするための方法であって、
   前記シンクデバイスへのＵＩＢＣを確立することと、
   前記シンクデバイスの周辺デバイスを識別し、ＵＩＢＣパケットのペイロードデータにおける予め定義されたフィールドに対応する、回送トンネル識別子の値を受信することと、
   少なくとも１つのＵＩＢＣパケットを使用して、前記シンクデバイスから前記周辺デバイスに関連付けられたカプセル化された周辺データを受信することと、
   前記周辺データをカプセル化解除することと、
   前記シンクデバイスを識別する逆トンネル識別子を生成することと、
   前記シンクデバイスに前記逆トンネル識別子を送信することと、
   前記周辺デバイスに関連付けられた追加の周辺データを受信することと、
   前記追加の受信された周辺データをカプセル化することと、
   少なくとも１つのＵＩＢＣパケットを使用して、前記シンクデバイスに前記カプセル化された追加の周辺データを送信することと、
   を備え、
   前記逆トンネル識別子または回送トンネル識別子は、前記ソースデバイスと前記シンクデバイスに接続された前記周辺デバイスとの間の前記双方向通信をサポートするために、複数のＵＩＢＣパケットの前記ペイロードデータに追加される、方法。
2. 前記ソースデバイスのホストインタフェースコントローラに前記カプセル化解除された周辺データを送信すること、をさらに備える、請求項１に記載の方法。
3. シンクデバイスにおいて、ソースデバイスと前記シンクデバイスとの間のユーザインタフェースバックチャネル（ＵＩＢＣ）を介した双方向通信をサポートするための方法であって、
   前記ソースデバイスへのＵＩＢＣを確立することと、
   前記シンクデバイスの周辺デバイスを識別する前記ＵＩＢＣに関連付けられた回送トンネル識別子の値を送信することと、前記回送トンネル識別子の値は、ＵＩＢＣパケットのペイロードデータにおける予め定義されたフィールドに対応し、
   前記周辺デバイスに関連付けられた周辺データを受信することと、
   前記周辺データをカプセル化することと、
   少なくとも１つのＵＩＢＣパケットを使用して、前記ソースデバイスに前記カプセル化された周辺データを送信することと、
   前記ソースデバイスから逆トンネル識別子を受信することと、前記逆トンネル識別子は、前記シンクデバイスを識別し、
   少なくとも１つのＵＩＢＣパケットを使用して、前記ソースデバイスから前記周辺デバイスに関連付けられたカプセル化された周辺データを受信することと、
   前記カプセル化された受信された周辺データをカプセル化解除することと、
   を備え、
   前記逆トンネル識別子または回送トンネル識別子は、前記ソースデバイスと前記シンクデバイスに接続された前記周辺デバイスとの間の前記双方向通信をサポートするために、複数のＵＩＢＣパケットの前記ペイロードデータに追加される、方法。
4. 前記方法は、
   前記ソースデバイスへの前記ＵＩＢＣを確立する前に、前記シンクデバイスの周辺デバイスの１つまたは複数のインタフェースを列挙すること、
   をさらに備える、請求項３に記載の方法。
5. 前記カプセル化された周辺データは、ＵＩＢＣパケットにカプセル化される、請求項１または３に記載の方法。
6. シンクデバイスとの、ユーザインタフェースバックチャネル（ＵＩＢＣ）を介した双方向通信をサポートするためのソースデバイスであって、
   前記シンクデバイスへのＵＩＢＣを確立するための手段と、
   前記シンクデバイスの周辺デバイスを識別し、ＵＩＢＣパケットのペイロードデータにおける予め定義されたフィールドに対応する、前記ＵＩＢＣに関連付けられた回送トンネル識別子の値を受信するための手段と、
   少なくとも１つのＵＩＢＣパケットを使用して、前記シンクデバイスから前記周辺デバイスに関連付けられたカプセル化された周辺データを受信するための手段と、
   前記周辺データをカプセル化解除するための手段と、
   前記シンクデバイスを識別する逆トンネル識別子を生成するための手段と、
   前記シンクデバイスに前記逆トンネル識別子を送信するための手段と、
   前記周辺デバイスに関連付けられた追加の周辺データを受信するための手段と、
   前記追加の周辺データをカプセル化するための手段と、
   少なくとも１つのＵＩＢＣパケットを使用して、前記周辺デバイスに関する前記カプセル化された周辺データを送信するための手段と、
   を備え、
   前記逆トンネル識別子または回送トンネル識別子は、前記ソースデバイスと前記シンクデバイスに接続された前記周辺デバイスとの間の前記双方向通信をサポートするために、複数のＵＩＢＣパケットの前記ペイロードデータに追加される、ソースデバイス。
7. 前記ソースデバイスのホストインタフェースコントローラに前記カプセル化解除された周辺データを送信するための手段、をさらに備える、請求項６に記載のソースデバイス。
8. ソースデバイスへの、ユーザインタフェースバックチャネル（ＵＩＢＣ）を介した双方向通信をサポートするためのシンクデバイスであって、
   前記ソースデバイスへのＵＩＢＣを確立するための手段と、
   前記シンクデバイスの周辺デバイスを識別する前記ＵＩＢＣに関連付けられた回送トンネル識別子の値を送信するための手段と、前記回送トンネル識別子の値は、ＵＩＢＣパケットのペイロードデータにおける予め定義されたフィールドに対応し、
   前記周辺デバイスに関連付けられた周辺データを受信するための手段と、
   前記周辺データをカプセル化するための手段と、
   少なくとも１つのＵＩＢＣパケットを使用して、前記ソースデバイスに前記カプセル化された周辺データを送信するための手段と、
   前記ソースデバイスから逆トンネル識別子を受信するための手段と、前記逆トンネル識別子は、前記シンクデバイスを識別し、
   少なくとも１つのＵＩＢＣパケットを使用して、前記ソースデバイスから追加のカプセル化された周辺データを受信するための手段と、
   前記追加のカプセル化された周辺データをカプセル化解除するための手段と、
   を備え、
   前記逆トンネル識別子または回送トンネル識別子は、前記ソースデバイスと前記シンクデバイスに接続された前記周辺デバイスとの間の前記双方向通信をサポートするために、複数のＵＩＢＣパケットの前記ペイロードデータに追加される、シンクデバイス。
9. 前記ソースデバイスへの前記ＵＩＢＣを確立する前に、前記シンクデバイスの周辺デバイスの１つまたは複数のインタフェースを列挙するための手段、をさらに備える、請求項８に記載のシンクデバイス。
10. 前記カプセル化された周辺データは、ＵＩＢＣパケットにカプセル化される、請求項６に記載のソースデバイス。
11. 前記カプセル化された周辺データは、ＵＩＢＣパケットにカプセル化される、請求項８に記載のシンクデバイス。
12. 記憶された命令を含むコンピュータ可読記憶媒体であって、前記命令は、実行されたとき、１つまたは複数のプロセッサに、請求項１乃至５のいずれか一項に記載のステップを行わせる、コンピュータ可読記憶媒体。

Images