JP2014532367A - ワイヤレスディスプレイデバイスのための最小認識モード - Google Patents

Abstract

本開示は、ワイヤレスディスプレイ（ＷＤ）システム中のシンクデバイスが、ソースデバイスの動作とソースデバイスから送信されるメディアデータとを制御することを可能にするための、技法に関する。一例では、方法は、最小認識（ＭＣ）モードで動作することが可能なソースデバイスと、少なくとも１つのシンクデバイスとの間で通信セッションを確立することであって、ＭＣモードが１つまたは複数のレベルを含む、確立することと、シンクデバイスにおいて検出されたトリガ情報に基づいてＭＣモードの特定のレベルをアクティブ化するための信号をシンクデバイスから受信することと、ＭＣモードの特定のレベルに対するソースデバイスの変更された動作に従って、メディアデータをシンクデバイスに送信することとを備える。

Description

本出願は、その内容全体が参照により本明細書に組み込まれる、２０１１年１０月５日に出願された「ＭＩＮＩＭＡＬ ＣＯＧＮＩＴＩＶＥ ＭＯＤＥ ＦＯＲ ＷＩＲＥＬＥＳＳ ＤＩＳＰＬＡＹ ＤＥＶＩＣＥＳ」という表題の、米国仮出願第６１／５４３，６７５号の利益を主張する。

本開示は、ワイヤレスソースデバイスとワイヤレスシンクデバイスとの間でデータを送信することに関する。

ワイヤレスディスプレイ（ＷＤ）システムは、ソースデバイスと１つまたは複数のシンクデバイスとを含む。ソースデバイスとシンクデバイスの各々とは、ワイヤレス通信機能を伴うモバイルデバイスまたは有線デバイスのいずれかであり得る。たとえば、モバイルデバイスとして、ソースデバイスおよびシンクデバイスのうちの１つまたは複数は、携帯電話、ワイヤレス通信カードを伴うポータブルコンピュータ、携帯情報端末（ＰＤＡ）、ポータブルメディアプレーヤ、または、いわゆる「スマート」フォンおよび「スマート」パッドもしくはタブレット、または他のタイプのワイヤレス通信デバイスを含む、ワイヤレス通信機能を伴う他のフラッシュメモリデバイスを備え得る。たとえば、有線デバイスとして、ソースデバイスおよびシンクデバイスのうちの１つまたは複数は、ワイヤレス通信機能を含む、テレビジョン、デスクトップコンピュータ、モニタ、プロジェクタなどを備え得る。

ソースデバイスは、特定の通信セッションに参加しているシンクデバイスのうちの１つまたは複数に、オーディオデータおよび／またはビデオデータなどのメディアデータを送信する。メディアデータは、ソースデバイスのローカルディスプレイと、シンクデバイスのディスプレイの各々の両方において再生され得る。より具体的には、参加しているシンクデバイスの各々は、受信されたメディアデータを、そのディスプレイおよびオーディオ機器上でレンダリング（render）する。いくつかの場合には、シンクデバイスのユーザは、タッチ入力およびリモートコントロール入力などのユーザ入力を、シンクデバイスに与えることができる。ＷＤシステムでは、ユーザ入力は、シンクデバイスからソースデバイスに送信される。ソースデバイスは、シンクデバイスからの受信されたユーザ入力を処理し、シンクデバイスに送信される後続のメディアデータに対してユーザ入力の効果を与える（apply）。

一般に、本開示は、ワイヤレスディスプレイ（ＷＤ）システム中のシンクデバイスが、ソースデバイスの動作とソースデバイスから送信されるメディアデータのタイプとを制御することを可能にするための、技法に関する。いくつかの状況では、ソースデバイス上で動作しているいくつかのアプリケーションのために生成されるオーディオデータおよび／またはビデオデータのようなメディアデータは、たとえば、シンクデバイスのユーザが自動車を運転しているとき、シンクデバイスにおいて望まれないことがある。シンクデバイスは、通信セッションの注意の中心にあることが多いので、シンクデバイスが、通信セッションを終了するだけではなく、ソースデバイスから受信するメディアデータに対する何らかの制御権（control）を有することが有益である。したがって、本技法は、シンクデバイスが、ソースデバイスおよびソースデバイス上で動作しているアプリケーションの動作を修正するようにソースデバイスにシグナリングすることを可能にするための、最小認識（Minimal Cognitive）（ＭＣ）モード機構を提供する。

より具体的には、本技法は、シンクデバイスのホストシステムから検出された事前に定義されたトリガ情報に応答して、ソースデバイス上およびシンクデバイスにおけるユーザ入力デバイス上で動作しているアプリケーションの異なるレベルの動作を定義する、ＭＣモード機構を提供する。ある例として、ホストシステムは、自動車ホストシステムを備えてよく、シンクデバイスは、自動車内にメディアヘッドユニットを備えてよい。事前に定義されたトリガ情報は、環境条件、ユーザの挙動、または、ホストシステム内のシンクデバイスのユーザが、その間はソースデバイスからのあるタイプのメディアデータが望まれない活動を行っていることを示すユーザ入力を含み得る。トリガ情報を検出したことに応答して、シンクデバイスは、ＭＣモードの関連付けられるレベルのアクティブ化をソースデバイスにシグナリングして、ユーザの活動中のソースデバイスの動作を修正する。シンクデバイスにおけるユーザ入力デバイスの動作はまた、ＭＣモードのアクティブ化されたレベルに基づいて修正され得る。

一例では、方法は、ソースデバイスによって、少なくとも１つのシンクデバイスとの接続を確立することであって、ソースデバイスおよびシンクデバイスが１つまたは複数のレベルを含むＭＣモードをサポートする、確立することと、ソースデバイスによって、ＭＣモードのレベルの１つを示す信号をシンクデバイスから受信することであって、ＭＣモードの示されるレベルが、シンクデバイスのホストシステムから検出されたトリガ情報に基づいてシンクデバイスにおいてアクティブ化される、受信することと、ソースデバイスにおいてＭＣモードの示されたレベルをアクティブ化することと、ＭＣモードのアクティブ化されたレベルに対するソースデバイスの修正された動作に従って、シンクデバイスにメディアデータを送信することとを備える。

別の例では、方法は、シンクデバイスによって、ソースデバイスとの接続を確立することであって、ソースデバイスおよびシンクデバイスが１つまたは複数のレベルを含むＭＣモードをサポートする、確立することと、シンクデバイスのホストシステムから検出されたトリガ情報に基づいて、シンクデバイスにおけるＭＣモードのレベルの１つをアクティブ化することと、シンクデバイスにおいてＭＣモードのアクティブ化されたレベルを示す信号をソースデバイスに送信することと、ＭＣモードのアクティブ化されたレベルに対するソースデバイスの修正された動作に従って、シンクデバイスにおいてメディアデータを受信することとを備える。

さらなる例では、ソースデバイスは、メディアデータを記憶するメモリと、少なくとも１つのシンクデバイスとの接続を確立するように構成されるプロセッサとを備え、ソースデバイスおよびシンクデバイスは、１つまたは複数のレベルを含むＭＣモードをサポートする。ソースデバイスのプロセッサはまた、ＭＣモードのレベルの１つを示す信号をシンクデバイスから受信することであって、ＭＣモードの示されるレベルが、シンクデバイスのホストシステムから検出されたトリガ情報に基づいてシンクデバイスにおいてアクティブ化される、受信することと、ソースデバイスにおいてＭＣモードの示されたレベルをアクティブ化することと、ＭＣモードのアクティブ化されたレベルに対するソースデバイスの修正された動作に従って、シンクデバイスにメディアデータを送信することとを行うように構成される。

別の例では、シンクデバイスは、メディアデータを記憶するメモリと、ソースデバイスとの接続を確立するように構成されるプロセッサとを備え、ソースデバイスおよびシンクデバイスは、１つまたは複数のレベルを含むＭＣモードをサポートする。シンクデバイスのプロセッサはさらに、シンクデバイスのホストシステムから検出されたトリガ情報に基づいて、シンクデバイスにおけるＭＣモードのレベルの１つをアクティブ化し、シンクデバイスにおいてＭＣモードのアクティブ化されたレベルを示す信号をソースデバイスに送信し、ＭＣモードのアクティブ化されたレベルに対するソースデバイスの修正された動作に従って、シンクデバイスにおいてメディアデータを受信するように構成される。

さらなる例では、ソースデバイスは、少なくとも１つのシンクデバイスとの接続を確立するための手段であって、ソースデバイスおよびシンクデバイスが１つまたは複数のレベルを含むＭＣモードをサポートする、手段と、ＭＣモードのレベルの１つを示す信号をシンクデバイスから受信するための手段であって、ＭＣモードの示されるレベルが、シンクデバイスのホストシステムから検出されたトリガ情報に基づいてシンクデバイスにおいてアクティブ化される、手段と、ソースデバイスにおいてＭＣモードの示されたレベルをアクティブ化するための手段と、ＭＣモードのアクティブ化されたレベルに対するソースデバイスの修正された動作に従って、シンクデバイスにメディアデータを送信するための手段とを備える。

追加の例では、シンクデバイスは、ソースデバイスとの接続を確立するための手段であって、ソースデバイスおよびシンクデバイスが１つまたは複数のレベルを含むＭＣモードをサポートする、手段と、シンクデバイスのホストシステムから検出されたトリガ情報に基づいて、シンクデバイスにおけるＭＣモードのレベルの１つをアクティブ化するための手段と、シンクデバイスにおいてＭＣモードのアクティブ化されたレベルを示す信号をソースデバイスに送信するための手段と、ＭＣモードのアクティブ化されたレベルに対するソースデバイスの修正された動作に従って、シンクデバイスにおいてメディアデータを受信するための手段とを備える。

別の例では、コンピュータ可読媒体は、ソースデバイスにおいて実行されると、プログラマブルプロセッサに、少なくとも１つのシンクデバイスとの接続を確立することであって、ソースデバイスおよびシンクデバイスが１つまたは複数のレベルを含むＭＣモードをサポートする、確立することと、ＭＣモードのレベルの１つを示す信号をシンクデバイスから受信することであって、ＭＣモードの示されるレベルが、シンクデバイスのホストシステムから検出されたトリガ情報に基づいてシンクデバイスにおいてアクティブ化される、受信することと、ソースデバイスにおいてＭＣモードの示されたレベルをアクティブ化することと、ＭＣモードのアクティブ化されたレベルに対するソースデバイスの修正された動作に従って、シンクデバイスにメディアデータを送信することとを行わせる、命令を備える。

さらなる例では、コンピュータ可読媒体は、シンクデバイスにおいて実行されると、プログラマブルプロセッサに、ソースデバイスとの接続を確立することであって、ソースデバイスおよびシンクデバイスが１つまたは複数のレベルを含むＭＣモードをサポートする、確立することと、シンクデバイスのホストシステムから検出されたトリガ情報に基づいて、シンクデバイスにおけるＭＣモードのレベルの１つをアクティブ化することと、シンクデバイスにおいてＭＣモードのアクティブ化されたレベルを示す信号をソースデバイスに送信することと、ＭＣモードのアクティブ化されたレベルに対するソースデバイスの修正された動作に従って、ソースデバイスからメディアデータを受信することとを行わせる、命令を備える。

本開示の１つまたは複数の例の詳細が、添付の図面および以下の説明に記載される。他の特徴、目的、および利点は、説明および図面から、および特許請求の範囲から明らかになるであろう。

最小認識（ＭＣ）モードをサポートすることが可能なホストシステム内にソースデバイスとシンクデバイスとを含む、ＷＤシステムの例を示すブロック図。 本開示の技法を実装し得るソースデバイスの例を示すブロック図。 本開示の技法を実装し得るホストシステム内のシンクデバイスの例を示すブロック図。 本開示の技法を実装し得る送信機システムと受信機システムとを示すブロック図。 ソースデバイスとシンクデバイスとの間のＭＣモードの機能のネゴシエーションを実行するための例示的なメッセージ転送シーケンスを示す概念図。 ＭＣモードのアクティブ化されたレベルをシンクデバイスからソースデバイスにシグナリングするために使用され得る、例示的なデータパケットを示す概念図。 ＭＣモードをサポートすることが可能なソースデバイスの例示的な動作を示すフローチャート。 ＭＣモードをサポートすることが可能なシンクデバイスの例示的な動作を示すフローチャート。

詳細な説明

本開示は、ワイヤレスディスプレイ（ＷＤ）システム中のシンクデバイスが、ソースデバイスの動作とソースデバイスから送信されるメディアデータのタイプとを制御することを可能にするための、技法に関する。いくつかの状況では、ソースデバイス上で動作しているいくつかのアプリケーションのために生成されるオーディオデータおよび／またはビデオデータのようなメディアデータは、たとえば、シンクデバイスのユーザが運転しているとき、シンクデバイスにおいて望まれないことがある。シンクデバイスは、通信セッションの注意の中心（attention focal point）にあることが多いので、シンクデバイスが、通信セッションを終了するだけではなく、ソースデバイスから受信するメディアデータに対する何らかの制御権を有することが有益である。したがって、本技法は、シンクデバイスが、ソースデバイスおよびソースデバイス上で動作しているアプリケーションの動作を修正するようにソースデバイスにシグナリングすることを可能にするための、最小認識（ＭＣ）モード機構を提供する。

より具体的には、本技法は、シンクデバイスのホストシステムから検出された事前に定義されたトリガ情報に応答して、ソースデバイス上およびシンクデバイスにおけるユーザ入力デバイス上で動作しているアプリケーションの異なるレベルの動作を定義する、ＭＣモード機構を提供する。ある例として、ホストシステムは、自動車ホストシステムを備えてよく、シンクデバイスは、自動車内にメディアヘッドユニットを備えてよい。事前に定義されたトリガ情報は、環境条件、ユーザの挙動、または、ホストシステム内のシンクデバイスのユーザが、その間はソースデバイスからのあるタイプのメディアデータが望まれない活動を行っていることを示すユーザ入力を含み得る。トリガ情報を検出したことに応答して、シンクデバイスは、ＭＣモードの関連付けられるレベルのアクティブ化をソースデバイスにシグナリングして、ユーザの活動中のソースデバイスの動作を修正する。シンクデバイスにおけるユーザ入力デバイスの動作はまた、ＭＣモードのアクティブ化されたレベルに基づいて修正され得る。

図１は、最小認識（ＭＣ）モードをサポートすることが可能なソースデバイス１２０とホストシステム１８０内のシンクデバイス１６０とを含む、ＷＤシステム１００の例を示すブロック図である。図１に示されるように、ＷＤシステム１００は、通信チャネル１５０を介してシンクデバイス１６０と通信するソースデバイス１２０を含む。ホストシステム１８０は、シンクデバイス１６０が動作する環境を備える。

例として、ホストシステム１８０は、少なくとも１つのプロセッサと自動車のユーザとホストシステム１８０との間のインターフェースとしての自動車のコンソール内のディスプレイとを含むメディアヘッドユニットとしてのシンクデバイス１６０を含む、自動車ホストシステムを備え得る。この場合、ソースデバイス１２０は、自動車のユーザに対して表示するために、ホストシステム１８０内のシンクデバイス１６０にメディアデータを提供する、モバイルデバイスを備え得る。別の例として、ホストシステム１８０は、会議場の中のプロジェクタ、モニタ、またはテレビジョンとしてシンクデバイス１６０を含む、会議場ホストシステムを備え得る。この場合、ソースデバイス１２０は、会議場における発表の聴衆に対して表示するために、ホストシステム１８０内のシンクデバイス１６０にメディアデータを提供する、モバイルデバイスを備え得る。

ソースデバイス１２０は、オーディオおよび／またはビデオ（Ａ／Ｖ）データ１２１を記憶するメモリと、ディスプレイ１２２と、スピーカー１２３と、（エンコーダ１２４とも呼ばれる）オーディオおよび／またはビデオ（Ａ／Ｖ）エンコーダ１２４と、オーディオおよび／またはビデオ（Ａ／Ｖ）制御モジュール１２５と、送信機／受信機（ＴＸ／ＲＸ）ユニット１２６とを含み得る。シンクデバイス１６０は、ディスプレイ１６２と、スピーカー１６３と、（デコーダ１６４とも呼ばれる）オーディオおよび／またはビデオ（Ａ／Ｖ）デコーダ１６４と、送信機／受信機ユニット１６６と、ユーザ入力（ＵＩ）デバイス１６７と、ユーザ入力処理モジュール（ＵＩＰＭ：user input processing module）１６８とを含み得る。示されたコンポーネントは、ＷＤシステム１００の１つの例示的な構成をなすにすぎない。他の構成は、示されたコンポーネントよりも少数のコンポーネントを含み得るか、または示されたコンポーネント以外の追加のコンポーネントを含み得る。

図１の例では、ソースデバイス１２０は、Ａ／Ｖデータ１２１のビデオ部分をディスプレイ１２２に表示することができ、かつＡ／Ｖデータ１２１のオーディオ部分をスピーカー１２３に出力することができる。Ａ／Ｖデータ１２１は、ソースデバイス１２０にローカルに記憶され、ファイルサーバ、ハードドライブ、外部メモリ、Ｂｌｕ−ｒａｙ（登録商標）ディスク、ＤＶＤ、または他の物理記憶媒体などの外部記憶媒体からアクセスされ得るか、またはインターネットなどのネットワーク接続を介してソースデバイス１２０にストリーミングされ得る。いくつかの例では、Ａ／Ｖデータ１２１は、ソースデバイス１２０のカメラおよびマイクロフォンを介してリアルタイムでキャプチャされ得る。Ａ／Ｖデータ１２１は、動画、テレビ番組、または音楽などのマルチメディアコンテンツを含み得るが、ソースデバイス１２０によって生成されたリアルタイムコンテンツも含み得る。そのようなリアルタイムコンテンツは、たとえば、ソースデバイス１２０上で動作しているアプリケーションによって生成されてよく、または、たとえば、ビデオ電話セッションの一部としてキャプチャされたビデオデータであってよい。いくつかの例では、そのようなリアルタイムコンテンツは、ユーザが選択することが可能なユーザ入力の選択肢のビデオフレームを含み得る。いくつかの例では、Ａ／Ｖデータ１２１は、ビデオのフレーム上にオーバーレイされたユーザ入力の選択肢を有する動画またはＴＶ番組のビデオフレームのような、異なるタイプのコンテンツの組合せであるビデオフレームを含み得る。

ディスプレイ１２２およびスピーカー１２３を介してローカルにＡ／Ｖデータ１２１をレンダリングすることに加えて、ソースデバイス１２０のＡ／Ｖエンコーダ１２４は、Ａ／Ｖデータ１２１を符号化することができ、送信機／受信機ユニット１２６は、符号化されたデータを通信チャネル１５０を通じてシンクデバイス１６０に送信することができる。シンクデバイス１６０の送信機／受信機ユニット１６６は符号化されたデータを受信し、Ａ／Ｖデコーダ１６４は、符号化されたデータを復号し、復号されたデータをディスプレイ１６２およびスピーカー１６３を介して出力する。このようにして、ディスプレイ１２２およびスピーカー１２３によってレンダリングされているオーディオデータおよびビデオデータは、ディスプレイ１６２およびスピーカー１６３によって同時にレンダリングされ得る。オーディオデータおよびビデオデータはフレーム中で並べられてよく、オーディオフレームは、レンダリングされるとき、ビデオフレームと時間的に同期されてよい。

Ａ／Ｖエンコーダ１２４およびＡ／Ｖデコーダ１６４は、代替的にＭＰＥＧ−４，Ｐａｒｔ１０，Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）と呼ばれるＩＴＵ−Ｔ Ｈ．２６４規格、または新生のｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｖｉｄｅｏ ｃｏｄｉｎｇ（ＨＥＶＣ）規格のような、任意の数のオーディオおよびビデオ圧縮規格を実装し得る。多くの他のタイプのプロプライエタリな（proprietary）または規格化された圧縮技法も使用され得る。一般に、Ａ／Ｖデコーダ１６４は、Ａ／Ｖエンコーダ１２４の逆の（reciprocal）コーディング動作を実行するように構成される。図１には示されないが、いくつかの態様では、Ａ／Ｖエンコーダ１２４およびＡ／Ｖデコーダ１６４は、それぞれオーディオエンコーダおよびオーディオデコーダと統合されてよく、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアとソフトウェアとを含んでよい。

以下でより詳細に説明されるように、Ａ／Ｖエンコーダ１２４は、上で説明されたようにビデオ圧縮規格を実装することに加えて、他の符号化機能も実行し得る。たとえば、Ａ／Ｖエンコーダ１２４は、Ａ／Ｖデータ１２１がシンクデバイス１６０に送信されるより前に、Ａ／Ｖデータ１２１に様々なタイプのメタデータを追加し得る。いくつかの事例では、Ａ／Ｖデータ１２１は、符号化された形態でソースデバイス１２０に記憶されるかまたはソースデバイス１２０において受信され、したがってＡ／Ｖエンコーダ１２４によるさらなる圧縮を必要としないことがある。

図１は、オーディオペイロードデータとビデオペイロードデータとを別々に搬送する通信チャネル１５０を示すが、いくつかの例では、ビデオペイロードデータおよびオーディオペイロードデータは共通のデータストリームの一部であってもよいことを理解されたい。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットはＩＴＵ Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠し得る。Ａ／Ｖエンコーダ１２４およびＡ／Ｖデコーダ１６４は各々、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せとして実装され得る。Ａ／Ｖエンコーダ１２４およびＡ／Ｖデコーダ１６４の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれてよく、そのいずれもが複合エンコーダ／デコーダ（コーデック）の一部として統合されてよい。したがって、ソースデバイス１２０およびシンクデバイス１６０の各々は、本開示の技法のうちの１つまたは複数を実行するように構成された専用の機械を備え得る。

ディスプレイ１２２およびディスプレイ１６２は、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、発光ダイオード（ＬＥＤ）ディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスのような、種々のビデオ出力デバイスのいずれかを備え得る。これらまたは他の例では、ディスプレイ１２２および１６２は、それぞれ発光型ディスプレイまたは透過型ディスプレイであり得る。ディスプレイ１２２およびディスプレイ１６２はまた、それらが同時に入力デバイスとディスプレイデバイスの両方であるような、タッチディスプレイであり得る。そのようなタッチディスプレイは、ユーザがそれぞれのデバイスにユーザ入力を与えることを可能にする、静電容量式、抵抗式、または他のタイプのタッチパネルであり得る。

スピーカー１２３は、ヘッドフォン、シングルスピーカーシステム、マルチスピーカーシステム、またはサラウンドサウンドシステムのような、種々のオーディオ出力デバイスのいずれかを備え得る。加えて、ディスプレイ１２２およびスピーカー１２３はソースデバイス１２０の一部として示されており、ディスプレイ１６２およびスピーカー１６３はシンクデバイス１６０の一部として示されているが、ソースデバイス１２０およびシンクデバイス１６０は、実際は複数のデバイスのシステムであり得る。一例として、ディスプレイ１６２はテレビジョンであってよく、スピーカー１６３はサラウンドサウンドシステムであってよく、デコーダ１６４は、ディスプレイ１６２およびスピーカー１６３に、有線またはワイヤレスのいずれかで接続された、外部ボックスの一部であってよい。他の例では、シンクデバイス１６０は、タブレットコンピュータまたはスマートフォンのような、単一のデバイスであり得る。さらに他の場合、ソースデバイス１２０およびシンクデバイス１６０は同様のデバイスであり、たとえば、両方がスマートフォン、タブレットコンピュータなどである。この場合、一方のデバイスはソースとして動作することができ、他方はシンクとして動作することができる。これらの役割は、後続の通信セッションでは逆になることさえある。さらに他の場合、ソースデバイスは、スマートフォン、ラップトップまたはタブレットコンピュータのような、モバイルデバイスを備えてよく、シンクデバイスは、（たとえば、ＡＣ電源コードを伴う）より固定のデバイスを備えてよく、その場合、ソースデバイスは、シンクデバイスを介した大群衆への提示のためにオーディオデータとビデオデータとを配信することができる。

送信機／受信機ユニット１２６および送信機／受信機ユニット１６６は、それぞれ、様々なミキサと、フィルタと、増幅器と、信号変調のために設計された他のコンポーネントとを含んでよく、さらに、１つまたは複数のアンテナと、データを送信し受信するために設計された他のコンポーネントとを含んでよい。通信チャネル１５０は、全般に、ビデオデータをソースデバイス１２０からシンクデバイス１６０に送信するのに好適な任意の通信媒体、または様々な通信媒体の集合体を表す。通信チャネル１５０は、通常、Ｗｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ（登録商標）などと同様の比較的短距離の通信チャネルである。しかしながら、通信チャネル１５０は、この点において必ずしも限定されるとは限らず、無線周波数（ＲＦ）スペクトルまたは１つまたは複数の物理伝送線路のような任意のワイヤレスまたは有線通信媒体、またはワイヤレス媒体と有線媒体との任意の組合せを備え得る。他の例では、通信チャネル１５０は、有線もしくはワイヤレスローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークのような、パケットベースネットワークの一部を形成することさえある。加えて、通信チャネル１５０は、ピアツーピアリンクを作成するためにソースデバイス１２０とシンクデバイス１６０とによって使用され得る。

ソースデバイス１２０およびシンクデバイス１６０は、たとえば、リアルタイムストリーミングプロトコル（ＲＴＳＰ）制御メッセージを使用した機能のネゴシエーションに従って、通信セッションを確立することができる。ソースデバイス１２０およびシンクデバイス１６０は次いで、ＩＥＥＥ８０２．１１規格ファミリーからの規格のような通信プロトコルを使用して、通信チャネル１５０を通じて通信し得る。ソースデバイス１２０およびシンクデバイス１６０は、たとえば、ソースデバイス１２０およびシンクデバイス１６０が、ワイヤレスアクセスポイントまたはいわゆるホットスポットのような中間物（intermediary）を使用せずに互いに直接通信するように、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ（ＷＦＤ）規格に従って通信し得る。ソースデバイス１２０およびシンクデバイス１６０はまた、ネットワーク輻輳（congestion）を回避または低減するためにトンネルドダイレクトリンクセットアップ（tunneled direct link setup）（ＴＤＬＳ）を確立し得る。ＷＦＤおよびＴＤＬＳは、比較的短距離の通信セッションをセットアップすることを目的とする。この文脈では、比較的短距離とは、たとえば、約７０メートル未満を指すことがあるが、雑音の多いまたは遮るもののある環境では、デバイス間の距離は、約３５メートル未満、または約２０メートル未満のように、さらに短いことがある。

本開示の技法は時々ＷＦＤに関して説明されることがあるが、これらの技法の態様は他の通信プロトコルにも適合し得ることが企図される。限定ではなく例として、ソースデバイス１２０とシンクデバイスとの間のワイヤレス通信は直交周波数分割多重化（ＯＦＤＭ）技法を利用し得る。限定はされないが、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、符号分割多元接続（ＣＤＭＡ）、またはＯＦＤＭ、ＦＤＭＡ、ＴＤＭＡおよび／またはＣＤＭＡの任意の組合せを含む、多種多様な他のワイヤレス通信技法も使用され得る。

ソースデバイス１２０から受信されたデータを復号し、レンダリングすることに加えて、シンクデバイス１６０はまた、ユーザ入力デバイス１６７からユーザ入力を受信することができる。ユーザ入力デバイス１６７は、たとえば、キーボード、マウス、トラックボールもしくはトラックパッド、タッチスクリーン、ボイスコマンド認識モジュール、または他のそのようなユーザ入力デバイスであり得る。ＵＩＰＭ１６８は、ユーザ入力デバイス１６７によって受信されたユーザ入力コマンドを、ソースデバイス１２０が解釈することが可能であるデータパケット構造にフォーマットする。そのようなデータパケットは、送信機／受信機１６６によって、通信チャネル１５０を通じてソースデバイス１２０に送信される。送信機／受信機ユニット１２６はデータパケットを受信し、Ａ／Ｖ制御モジュール１２５は、データパケットを解析し（parse）て、ユーザ入力デバイス１６７によって受信されたユーザ入力コマンドを解釈する。データパケット中で受信されたコマンドに基づいて、Ａ／Ｖ制御モジュール１２５は、符号化および送信されているコンテンツを変更することができる。このようにして、シンクデバイス１６０のユーザが、リモートで、およびソースデバイス１２０と直接対話することなく、ソースデバイス１２０によって送信されているオーディオペイロードデータとビデオペイロードデータとを制御することができる。

加えて、シンクデバイス１６０のユーザは、ソースデバイス１２０上のアプリケーションを起動し、制御することが可能であり得る。たとえば、シンクデバイス１６０のユーザは、ソースデバイス１２０に記憶された写真編集アプリケーションを起動し、そのアプリケーションを使用して、ソースデバイス１２０にローカルに記憶された写真を編集することが可能であり得る。シンクデバイス１６０は、その写真が実際はソースデバイス１２０上で編集されている間、その写真がシンクデバイス１６０上でローカルで編集されているように見え、感じられる、ユーザ体験をユーザにもたらし得る。そのような構成を使用して、デバイスユーザは、いくつかのデバイスとともに使用する１つのデバイスの機能を活用する（leverage）ことが可能であり得る。たとえば、ソースデバイス１２０は、大量のメモリとハイエンド処理能力とを伴うスマートフォンを備え得る。しかしながら、動画を見るとき、ユーザは、より大きいディスプレイスクリーンを伴うデバイス上で動画を見ることを望むことがあり、その場合、シンクデバイス１６０は、タブレットコンピュータまたはさらに大きいディスプレイデバイスもしくはテレビジョンであってよい。電子メールを送信することまたは電子メールに応答することを望むとき、ユーザは、物理キーボードを伴うデバイスを使用することを望むことがあり、その場合、シンクデバイス１６０はラップトップであってよい。どちらの場合にも、ユーザはシンクデバイスと対話しているが、処理の大半（bulk）は依然としてソースデバイス１２０によって実行され得る。ソースデバイスおよびシンクデバイスは、任意の所与のセッションにおいてデバイスの機能のネゴシエーションを行い、かつまたは機能を特定することによって、双方向の対話を支援することができる。

いくつかの構成では、Ａ／Ｖ制御モジュール１２５は、ソースデバイス１２０のオペレーティングシステムによって実行されているオペレーティングシステムプロセスを備え得る。しかしながら、他の構成では、Ａ／Ｖ制御モジュール１２５は、ソースデバイス１２０上で動作しているアプリケーションのソフトウェアプロセスを備え得る。そのような構成では、シンクデバイス１６０のユーザが、ソースデバイス１２０上で動作しているオペレーティングシステムではなく、ソースデバイス１２０上で動作しているアプリケーションと直接対話しているように、ユーザ入力コマンドはソフトウェアプロセスによって解釈されてよい。オペレーティングシステムではなくアプリケーションと直接対話することによって、シンクデバイス１６０のユーザは、ソースデバイス１２０のオペレーティングシステムに対してネイティブでないコマンドのライブラリへのアクセスを有し得る。加えて、アプリケーションと直接対話することにより、コマンドは、異なるプラットフォーム上で動作しているデバイスによってより容易に送信され、処理されることが可能になり得る。

シンクデバイス１６０において与えられたユーザ入力は、通信チャネル１５０を通じてソースデバイス１２０に戻され（be sent back）得る。一例では、シンクデバイス１６０が、シンクデバイス１６０において与えられたユーザ入力をソースデバイス１２０に送信することを可能にするために、ユーザインターフェースバックチャネル（ＵＩＢＣ）とも呼ばれる逆方向チャネルアーキテクチャが実装され得る。逆方向チャネルアーキテクチャは、ユーザ入力をトランスポートするための上位レイヤメッセージと、シンクデバイス１６０およびソースデバイス１２０においてユーザインターフェース機能をネゴシエートするための下位レイヤフレームとを含み得る。ＵＩＢＣは、シンクデバイス１６０とソースデバイス１２０との間のインターネットプロトコル（ＩＰ）トランスポートレイヤの上に存在し得る。このようにして、ＵＩＢＣは、開放型システム間相互接続（ＯＳＩ）通信モデルにおいてトランスポートレイヤの上にあり得る。ユーザ入力データを含んでいるデータパケットの信頼できる送信とシーケンス配信とを促すために、ＵＩＢＣは、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）またはユーザデータグラムプロトコル（ＵＤＰ）のような、他のパケットベース通信プロトコルの上で動作するように構成され得る。ＵＤＰおよびＴＣＰは、ＯＳＩレイヤアーキテクチャにおいて並列に動作することができる。ＴＣＰ／ＩＰは、シンクデバイス１６０およびソースデバイス１２０が、パケットロスの場合に、再送信技法を実施することを可能にできる。

ＵＩＢＣは、クロスプラットフォームユーザ入力データを含む、様々なタイプのユーザ入力データをトランスポートするように設計され得る。たとえば、ソースデバイス１２０はｉＯＳ（登録商標）オペレーティングシステムを実行することができ、シンクデバイス１６０は、Ａｎｄｒｏｉｄ（登録商標）またはＷｉｎｄｏｗｓ（登録商標）のような、別のオペレーティングシステムを実行する。プラットフォームにかかわらず、ＵＩＰＭ１６８は、Ａ／Ｖ制御モジュール１２５にとって理解可能な形態で、受信されたユーザ入力をカプセル化することができる。多くの異なるタイプのソースデバイスおよびシンクデバイスが異なるプラットフォーム上で動作するかどうかにかかわらず、それらのソースデバイスおよびシンクデバイスがプロトコルを活用することを可能にするように、いくつかの異なるタイプのユーザ入力フォーマットがＵＩＢＣによってサポートされ得る。汎用入力フォーマットが定義されてよく、かつプラットフォーム固有入力フォーマットもサポートされてよく、したがって、ユーザ入力がＵＩＢＣによってソースデバイス１２０とシンクデバイス１６０との間で通信され得る方法に柔軟性がもたらされる。

本開示の技法によれば、シンクデバイス１６０は、ソースデバイス１２０の動作および／またはソースデバイス１２０上で動作しているアプリケーションを制御して、レンダリングされソースデバイス１２０から送信されたメディアデータのタイプを修正することができる。いくつかの状況では、ソースデバイス１２０上で動作しているいくつかのアプリケーションのために生成される、電話呼（telephone calls）、テキストメッセージ、および他のＡ／Ｖコンテンツのようなメディアデータは、シンクデバイス１６０において望まれないことがある。たとえば、テキストメッセージ、およびユーザの対話を必要とする他のコンテンツは、シンクデバイス１６０のユーザが運転しているとき、発表を行っているとき、または、その間は気を散らせるもの（distractions）が歓迎されない、かつ／または危険である、何らかの他の活動を行っているとき、望まれないことがある。シンクデバイス１６０は、通信セッションの注意の中心にあることが多いので、シンクデバイス１６０が、通信セッションを単に終了するだけではなく、ソースデバイス１２０から受信するメディアデータに対する何らかの制御権を有することが有益である。したがって、本技法は、シンクデバイス１６０が、ソースデバイス１２０およびソースデバイス１２０上で動作しているアプリケーションの動作を修正するようにソースデバイス１２０にシグナリングすることを可能にするための、最小認識（ＭＣ）モード機構を提供する。

より具体的には、本技法は、ホストシステム１８０から検出された事前に定義されたトリガ情報に応答して、ソースデバイス１２０上およびシンクデバイス１６０におけるユーザ入力デバイス上で動作しているアプリケーションの１つまたは複数のレベルの動作を定義する、ＭＣモード機構を提供する。事前に定義されたトリガ情報は、何らかの環境条件、ユーザの挙動、または、ホストシステム内のシンクデバイス１６０のユーザが、その間はソースデバイス１２０からのあるタイプのメディアデータが望まれない活動を行っていることを示すユーザ入力を含み得る。いくつかの場合には、シンクデバイス１６０は、ホストシステム１８０に含まれる１つまたは複数のセンサからのトリガ情報を検出することがある。たとえば、ホストシステム１８０が自動車ホストシステムを備える場合、トリガ情報は、車線の変更、道を曲がること、悪い気象条件（たとえば、雨または雪）、他の車両が近づいていること、または単に運転していることの、指示を含み得る。別の例として、ホストシステム１８０が会議場ホストシステムを備える場合、トリガ情報は、照明が弱くなったこと（dimming）、複数の人が部屋に入ったこと、または、発表が始まろうとしているというユーザ入力の、指示を含み得る。

トリガ情報を検出したことに応答して、シンクデバイス１６０は、ＭＣモードの関連付けられるレベルのアクティブ化を、ソースデバイス１２０にシグナリングする。ソースデバイス１２０中のＡ／Ｖ制御モジュール１２５は次いで、受信された信号を解析して、シンクデバイス１６０においてアクティブ化されているＭＣモードのレベルを特定する。Ａ／Ｖ制御モジュール１２５は、ソースデバイス１２０において、示されたレベルのＭＣモードをアクティブ化し、ソースデバイス１２０および／またはソースデバイス１２０上で動作しているアプリケーションの動作を修正して、ユーザの活動の間にレンダリングされシンクデバイス１６０に送信されるコンテンツのタイプを変更することができる。ＭＣモードのアクティブ化されたレベルはまた、シンクデバイス１６０におけるＵＩデバイス１６７の動作を修正し、ユーザの活動の間に許容されるユーザ対話のタイプを変更するために、使用され得る。

ＭＣモードの１つまたは複数のレベルの各々は、ソースデバイス１２０および／またはシンクデバイス１６０のどの動作が修正され得るかに従って、規則を規定する。たとえば、ＭＣモードの所与のレベルに対する規則は、Ａ／Ｖ制御モジュール１２５に、ソースデバイス１２０およびソースデバイス１２０上で動作しているアプリケーションの動作を修正させ、あるタイプのメディアデータ、たとえば、電話呼、テキストメッセージ、ならびにオーディオおよび／またはビデオコンテンツのみをレンダリングさせることができる。ＭＣモードの所与のレベルに対する規則はまた、シンクデバイス１６０におけるＵＩデバイス１６７の修正された動作に、シンクデバイス１６０とのあるタイプのユーザ対話のみを許容させてよく、たとえば、ボイスコマンドおよびタッチコマンドを許容させ、ボイスコマンドのみを許容させ、またはコマンドを許容させなくてよい。

ＭＣモードの機能のネゴシエーションは、通信セッションを確立する前、または通信セッションにわたる（throughout）様々な時間において、ソースデバイス１２０とシンクデバイス１６０との間で行われ得る。このネゴシエーションプロセスの一部として、ソースデバイス１２０およびシンクデバイス１６０は、通信セッションに対するＭＣモードを可能にすることに同意し得る。ＭＣモードが有効である場合、シンクデバイス１６０は、ホストシステム１８０から検出されたトリガ情報に基づいて、ＭＣモードのレベルの１つをアクティブ化することができる。シンクデバイス１６０は次いで、ＭＣモードのアクティブ化されたレベルを示す信号をソースデバイス１２０に送信する。ＭＣモードのアクティブ化されたレベルに基づいて、ソースデバイス１２０は、ＭＣモードのアクティブ化されたレベルに対して許容されたタイプのメディアデータのみを処理するように、Ａ／Ｖ制御１２５の動作を修正する。加えて、ＭＣモードのアクティブ化されたレベルに基づいて、シンクデバイス１６０は、ＭＣモードのアクティブ化されたレベルに対して許容されたタイプのユーザ入力のみを受け入れるように、ＵＩデバイス１６７の動作を修正する。

本開示の技法によれば、ソースデバイス１２０およびシンクデバイス１６０は、ＲＴＳＰ制御メッセージを使用して、通信セッションのためのＭＣモードの機能のネゴシエーションを実行することができる。ソースデバイス１２０とシンクデバイス１６０の両方がＭＣモードをサポートする場合、ソースデバイス１２０は、通信セッションに対するＭＣモードを可能にし得る。ＭＣモードが通信セッションに対して有効である場合、シンクデバイス１６０は、通信チャネル１５０を通じて、ＭＣモードのアクティブ化されたレベルをソースデバイス１２０にシグナリングする。いくつかの場合には、シンクデバイス１６０は、ＵＩＢＣを使用して、ＭＣモードのアクティブ化されたレベルをソースデバイス１２０にシグナリングすることができる。他の場合には、シンクデバイス１６０は、ＲＴＳＰ制御メッセージを使用して、ＭＣモードのアクティブ化されたレベルをソースデバイス１２０に示すことができる。

ある例として、ホストシステム１８０は、自動車のコンソール内のメディアヘッドユニットとしてシンクデバイス１６０を含む、自動車ホストシステムを備え得る。ホストシステム１８０は、自動車のいくつかの部分を制御し、自動車のユーザ（たとえば、運転者および／または乗員）とのインターフェースをとるように構成される、自動車のコンピュータシステムを備え得る。メディアヘッドユニットは、少なくとも１つのプロセッサと１つのディスプレイとを含んでよく、ユーザとホストシステム１８０との間のインターフェースとして動作してよい。この場合、ソースデバイス１２０は、自動車のユーザに対して表示するために、ホストシステム１８０内のシンクデバイス１６０にメディアデータを提供する、モバイルデバイスを備え得る。

一例として、ソースデバイス１２０は、自動車のユーザが所有するスマートフォンを備え得る。ユーザが自動車の中にいる間、スマートフォン（すなわち、ソースデバイス１２０）は、ユーザへの表示のために、自動車のコンソール内に埋め込まれたホストシステム１８０のメディアヘッドユニット（すなわち、シンクデバイス１６０）に、メディアデータを送信することができる。ユーザが運転しているとき、すべてのタイプのメディアデータ、特に、ユーザ対話を必要とするメディアデータが運転者への表示のためにシンクデバイス１６０に送信されることは、望ましくないことがある。本開示の技法は、シンクデバイス１６０が、自動車が運転されていること、および／または、運転が行われている環境条件もしくは交通条件という、ホストシステム１８０からのトリガ情報を検出し、トリガ情報と関連付けられるＭＣモードのレベルを決定することを可能にする。シンクデバイス１６０は次いで、その運転条件では気を散らせないものである、または危険ではないデータのみを含むように、ソースデバイス１２０から受信されるメディアデータのタイプを修正するために、ソースデバイス１２０にシグナリングしてＭＣモードのレベルを示すことができる。

別の例では、ホストシステム１８０は、会議場の中のプロジェクタ、モニタ、またはテレビジョンとしてシンクデバイス１６０を含む、会議場ホストシステムを備え得る。ホストシステム１８０は、会議場のいくつかの部分を制御し、会議場のユーザ（たとえば、発表者および／または聴衆）とのインターフェースをとるように構成される、会議場のコンピュータシステムを備え得る。この場合、ソースデバイス１２０は、発表の間に１人または複数の聴衆に対して表示するために、ホストシステム１８０内のシンクデバイス１６０にメディアデータを提供する、モバイルデバイスを備え得る。

一例として、ソースデバイス１２０は、会議場の中の発表者が所有するスマートフォンを備え得る。スマートフォン（すなわち、ソースデバイス１２０）は、聴衆への表示のために、会議場内のホストシステム１８０のプロジェクタ、モニタ、またはテレビジョン（すなわち、シンクデバイス１６０）にメディアデータを送信することができる。ユーザが発表を行っているとき、すべてのタイプのメディアデータ、特に、個人的なメディアデータが発表のすべての聴衆への表示のためにシンクデバイス１６０に送信されることは、望ましくないことがある。本開示の技法は、シンクデバイス１６０が、会議場が聴衆で満たされていること、および／または、会議場において発表が始まっていることという、ホストシステム１８０からのトリガ情報を検出し、トリガ情報と関連付けられるＭＣモードのレベルを決定することを可能にする。シンクデバイス１６０は次いで、個人的なデータまたは発表に関係のないデータのみを含むように、ソースデバイス１２０から受信されるメディアデータのタイプを修正するために、ソースデバイス１２０にシグナリングしてＭＣモードのレベルを示すことができる。

図１の例では、ソースデバイス１２０は、スマートフォン、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、Ｗｉ−Ｆｉ対応テレビジョン、またはオーディオデータとビデオデータとを送信することが可能な任意の他のデバイスを備え得る。ホストシステム１８０内のシンクデバイス１６０は、同様に、スマートフォン、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータ、Ｗｉ−Ｆｉ対応テレビジョン、またはオーディオデータとビデオデータとを受信し、ユーザ入力データを受信することが可能な任意の他のデバイスを備え得る。いくつかの例では、シンクデバイス１６０は、ディスプレイ１６２、スピーカー１６３、ＵＩデバイス１６７、およびＡ／Ｖエンコーダ１６４が、すべて、別個であるが相互動作可能なデバイスの一部であるような、複数のデバイスのシステムを含み得る。ソースデバイス１２０は、同様に、単一のデバイスではなく、複数のデバイスのシステムであり得る。

本開示では、ソースデバイスという用語を、一般に、Ａ／Ｖデータを送信しているデバイスを指すために使用し、シンクデバイスという用語を、一般に、ソースデバイスからＡ／Ｖデータを受信しているデバイスを指すために使用する。多くの場合、ソースデバイス１２０およびシンクデバイス１６０は同様または同等のデバイスであってよく、一方のデバイスがソースとして動作し、他方がシンクとして動作する。その上、異なる通信セッションではこれらの役割が逆になることがある。したがって、１つの通信セッションにおけるシンクデバイスは後続の通信セッションではソースデバイスになることがあり、またはその逆も同様である。

いくつかの例では、ＷＤシステム１００は、シンクデバイス１６０およびホストシステム１８０に加えて、１つまたは複数のホストシステム内に１つまたは複数のシンクデバイスを含み得る。シンクデバイス１６０と同様に、追加のシンクデバイスは、ソースデバイス１２０からＡ／Ｖデータを受信し、かつ確立されたＵＩＢＣを通じてソースデバイス１２０にユーザコマンドを送信し得る。いくつかの構成では、複数のシンクデバイスは互いに独立に動作することができ、ソースデバイス１２０におけるＡ／Ｖデータ出力は、シンクデバイス１６０および追加のシンクデバイスの１つまたは複数において同時に出力され得る。代替構成では、シンクデバイス１６０は主要なシンクデバイスであってよく、追加のシンクデバイスの１つまたは複数は二次的なシンクデバイスであってよい。そのような例示的な構成では、シンクデバイス１６０および追加のシンクデバイスの１つが結合されてよく、シンクデバイス１６０はビデオデータを表示することができ、一方追加のシンクデバイスは対応するオーディオデータを出力する。加えて、いくつかの構成では、シンクデバイス１６０は送信されたビデオデータのみを出力することができ、一方追加のシンクデバイスは送信されたオーディオデータを出力する。

図２は、ソースデバイス２２０の一例を示すブロック図である。ソースデバイス２２０は、図１中のソースデバイス１２０と同様のデバイスであってよく、ソースデバイス１２０と同じ方法で動作し得る。ソースデバイス２２０は、ローカルディスプレイ２２２と、スピーカー２２３と、プロセッサ２３１と、ディスプレイプロセッサ２３５と、オーディプロセッサ２３６と、メモリ２３２と、トランスポートユニット２３３と、ワイヤレスモデム２３４と、ＭＣモードドライバ２４０とを含む。図２に示されるように、ソースデバイス２２０は、トランスポート、記憶、および表示のためにＡ／Ｖデータを符号化および／または復号する１つまたは複数のプロセッサ（すなわち、プロセッサ２３１、ディスプレイプロセッサ２３５、およびオーディオプロセッサ２３６）を含み得る。メディアデータまたはＡ／Ｖデータは、たとえばメモリ２３２に記憶され得る。メモリ２３２は、Ａ／Ｖファイル全体を記憶してよく、または、たとえば、別のデバイスまたはソースからストリーミングされた、Ａ／Ｖファイルの一部分を記憶するにすぎないより小さいバッファを備えてよい。

トランスポートユニット２３３は、符号化されたＡ／Ｖデータをネットワークトランスポートのために処理し得る。たとえば、符号化されたＡ／Ｖデータは、プロセッサ２３１によって処理され、ネットワーク上での通信のためにトランスポートユニット２３３によってネットワークアクセスレイヤ（ＮＡＬ）ユニットにカプセル化され得る。ＮＡＬユニットは、ワイヤレスモデム２３４によってネットワーク接続を介してワイヤレスシンクデバイスに送信され得る。ワイヤレスモデム２３４は、たとえば、ＩＥＥＥ８０２．１１規格ファミリーのうちの１つを実装するように構成されたＷｉ−Ｆｉモデムであり得る。また、ソースデバイス２２０は、Ａ／Ｖデータをローカルで処理し、表示し得る。特に、ディスプレイプロセッサ２３５は、ローカルディスプレイ２２２で表示されるようにビデオデータを処理することができ、かつオーディオプロセッサ２３６は、スピーカー２２３での出力のためにオーディオデータを処理することができる。

図１のソースデバイス１２０に関して上で説明されたように、ソースデバイス２２０は、ユーザ入力コマンドとＭＣモードレベル指示とをシンクデバイスから受信し得る。たとえば、ソースデバイス２２０のワイヤレスモデム２３４は、ＮＡＬユニットなどのカプセル化されたユーザ入力データパケットをシンクデバイスから受信し、カプセル化されたデータユニットをカプセル化解除（decapsulation）のためにトランスポートユニット２３３に送信することができる。トランスポートユニット２３３はＮＡＬユニットからユーザ入力データパケットを抽出することができ、プロセッサ２３１はデータパケットを解析してユーザ入力コマンドを抽出することができる。ユーザ入力コマンドに基づいて、プロセッサ２３１は、ソースデバイス２２０によって処理されているＡ／Ｖデータのタイプを修正する。他の例では、ソースデバイス２２０は、トランスポートユニット２３３からユーザ入力データパケットを受信し、データパケットを解析してユーザ入力コマンドを抽出し、ユーザ入力コマンドに基づいて、ソースデバイス２２０によって処理されているＡ／Ｖデータのタイプを修正するようにプロセッサ２３１に指示する、ユーザ入力ユニットまたはドライバ（図２には示されない）を含み得る。

本開示の技法によれば、ソースデバイス２２０のワイヤレスモデム２３４は、シンクデバイスからのカプセル化されたデータパケットまたは制御メッセージのいずれかにおいて、ＭＣモードレベル指示を受信することができる。ワイヤレスモデム２３４は次いで、ＭＣモードデータパケットまたは制御メッセージをトランスポートユニット２３３に送信することができる。図２に示されるように、ＭＣモードユニット２４０は、ＭＣモードデータパケットまたは制御メッセージをトランスポートユニット２３３から受信し、データパケットまたは制御メッセージを解析してＭＣモードレベルを抽出し、示されたＭＣモードレベルに基づいて、ソースデバイス２２０によって処理されているＡ／Ｖデータのタイプ、たとえば、電話呼、テキストメッセージ、ならびにオーディオおよび／またはビデオコンテンツを修正するようにプロセッサ２３１に指示する。図２ではソースデバイス２２０内の別個のユニットとして示されるが、他の例では、ＭＣモードユニット２４０は、示されるＭＣモードレベルを抽出しＡ／Ｖデータの処理を修正するように、プロセッサ２３１内で動作することができる。このようにして、図１のＡ／Ｖ制御モジュール１２５に関して上で説明された機能は、完全にまたは部分的に、プロセッサ２３１およびＭＣモードユニット２４０によって実装され得る。

本開示で説明されるＭＣモード機構は、事前に定義されたトリガ情報がシンクデバイスによって検出されたことに応答して、ソースデバイス２２０の動作の１つまたは複数の異なるレベルを定義する。ＭＣモードの１つまたは複数のレベルの各々は、ソースデバイス２２０のどの動作が修正され得るかに従って、規則を規定する。たとえば、ＭＣモードの所与のレベルに対する規則は、あるタイプのメディアデータ、たとえば、電話呼、テキストメッセージ、ならびにオーディオおよび／またはビデオコンテンツのみをレンダリングするように、プロセッサ２３１の修正を指示する（direct）ことができる。いくつかの例では、ＭＣモードの所与のレベルに対する規則はまた、あるタイプのユーザ対話のみを許容するように、シンクデバイスにおけるユーザ入力インターフェースの修正を指示することができる。ＭＣモードに含まれるレベルの数は、ＷＤ通信セッション規格、たとえばＷＦＤまたはＴＤＬＳに従って定義され得る。ある例として、ＷＦＤ規格は、ＭＣ−１、ＭＣ−２、およびＭＣ−３という３つの異なるＭＣモードレベルを定義し得る。他の例では、ＭＣモードは、より多数またはより少数のレベルの動作を定義し得る。

ソースデバイス２２０および／またはソースデバイス２２０と通信しているシンクデバイスのベンダー（vender）は、レベルの各々と関連付けられる規則を設定することを担い得る。ベンダーはまた、シンクデバイスにおいて使用されるトリガ情報を割り当てて、レベルの各々を特定することを担い得る。ＭＣモードレベルの各々と関連付けられる規則は、特定のＭＣモードで動作している間にシンクデバイスへの送信のためにプロセッサ２３１によってレンダリングされることが許容される、メディアデータのタイプを規定する。ＭＣモードの異なるレベルに対する設定された規則は、ＭＣモードユニット２４０またはメモリ２３２に記憶され得る。ＭＣモードユニット２４０が、シンクデバイスにおいてアクティブ化されるＭＣモードのレベルの１つを示すデータパケットまたは制御メッセージを受信する場合、ＭＣモードユニット２４０は、ＭＣモードのアクティブ化されたレベルと関連付けられる規則によって許容されるタイプのＡ／Ｖデータ、たとえば、電話呼、テキストメッセージ、ならびにオーディオおよび／またはビデオコンテンツのみを処理するように、プロセッサ２３１の動作を修正する。

以下の表１は、ソースデバイス２２０によってレンダリングされる異なるタイプのメディアデータおよびシンクデバイスによって受信されるユーザ入力に関する、ＭＣ−１、ＭＣ−２、およびＭＣ−３というＭＣモードの３つのレベルの各々に対して設定される例示的な規則を示す。

たとえば、表１によれば、ＭＣ−１レベルにおいて、関連付けられる規則は、ソースデバイス２２０による、電話呼および一般的なＡ／Ｖコンテンツの通常の処理と送信とを許容し得るが、ボイスコマンドテキストメッセージのみをレンダリングするように、プロセッサ２３１の動作を制約し得る。ＭＣ−２レベルにおいて、関連付けられる規則は、ボイスコマンド電話呼とボイスコマンドＡ／Ｖコンテンツとのみをレンダリングし、かつテキストメッセージを何らレンダリングしないように、プロセッサ２３１の動作を制約し得る。加えて、ＭＣ−２レベルと関連付けられる規則は、シンクデバイスにおけるユーザ対話を、ボイスコマンドのみに制約し得る。ＭＣ−３レベルにおいて、関連付けられる規則は、電話呼、テキストメッセージ、またはシンクデバイスへの送信のための一般的なＡ／Ｖコンテンツを何らレンダリングしないように、プロセッサ２３１の動作を制約し得る。加えて、ＭＣ−３レベルと関連付けられる規則は、シンクデバイスにおけるあらゆるユーザ対話を許容できない。他の例では、異なる規則が、ＭＣモードレベルＭＣ−１、ＭＣ−２、およびＭＣ−３の１つまたは複数、または追加のＭＣモードレベルに対して設定され得る。

図２のプロセッサ２３１は、一般に、限定はされないが、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、他の等価な集積回路もしくはディスクリート論理回路、またはそれらの何らかの組合せを含む、多種多様なプロセッサのいずれかを表す。図２のメモリ２３２は、限定はされないが、同期ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）などのランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電気的消去可能プログラマブル読取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリなどを含む、多種多様な揮発性または不揮発性メモリのいずれかを備えてよく、メモリ２３２は、オーディオデータ／ビデオデータならびに他の種類のデータを記憶するためのコンピュータ可読記憶媒体を備えてよい。メモリ２３２は、加えて、本開示で説明される様々な技法を実行することの一部として、プロセッサ２３１によって実行される命令とプログラムコードとを記憶し得る。

図３は、本開示の技法を実装し得るホストシステム３００内のシンクデバイス３６０の例を示すブロック図である。ホストシステム３００は、シンクデバイス１８０が動作する環境を備える。たとえば、ホストシステム３００は、自動車のユーザ、たとえば運転者および乗員に対する表示のための、自動車のコンソール内に埋め込まれたメディアヘッドユニットとしてシンクデバイス３６０を含む、自動車ホストシステムを備え得る。別の例として、ホストシステム３００は、会議場のユーザ、たとえば発表者および聴衆に対する表示のための、会議場の中のプロジェクタ、モニタ、またはテレビジョンとしてシンクデバイス３６０を含む、会議場ホストシステムを備え得る。ホストデバイス３００およびシンクデバイス３６０は、図１のホストデバイス１８０およびシンクデバイス１６０と同様であり得る。

シンクデバイス３６０は、プロセッサ３３１と、メモリ３３２と、トランスポートユニット３３３と、ワイヤレスモデム３３４と、ディスプレイプロセッサ３３５と、ローカルディスプレイ３６２と、オーディオプロセッサ３３６と、スピーカー３６３と、ユーザ入力インターフェース３７６と、ＭＣモードユニット３７８とを含む。シンクデバイス３６０は、ワイヤレスモデム３３４において、ソースデバイスから送信されたカプセル化されたデータユニットを受信する。ワイヤレスモデム３３４は、たとえば、ＩＥＥＥ８０２．１１規格ファミリーからの１つまたは複数の規格を実装するように構成されたＷｉ−Ｆｉモデムであり得る。トランスポートユニット３３３は、カプセル化されたデータユニットをカプセル化解除することができる。たとえば、トランスポートユニット３３３は、カプセル化されたデータユニットから符号化されたビデオデータを抽出し、符号化されたＡ／Ｖデータを、出力のために復号されレンダリングされるように、プロセッサ３３１に送信し得る。ディスプレイプロセッサ３３５は、ローカルディスプレイ３６２上で表示されるように復号されたビデオデータを処理することができ、かつオーディオプロセッサ３３６は、スピーカー３６３上での出力のために復号されたオーディオデータを処理することができる。

オーディオデータとビデオデータとをレンダリングすることに加えて、ワイヤレスシンクデバイス３６０は、ユーザ入力インターフェース３７６を通じてユーザ入力データも受信することができる。ユーザ入力インターフェース３７６は、限定はされないが、タッチディスプレイインターフェース、キーボード、マウス、ボイスコマンドモジュール、（たとえば、カメラベースの入力キャプチャ機能をもつ）ジェスチャーキャプチャデバイス、またはいくつかのユーザ入力デバイスの任意の他のユーザ入力デバイスを含む、いくつかのユーザ入力デバイスのいずれかを表し得る。ユーザ入力インターフェース３７６を通じて受信されたユーザ入力は、プロセッサ３３１によって処理され得る。この処理は、受信されたユーザ入力コマンドを含む、データパケットを生成することを含み得る。生成されると、トランスポートユニット３３３は、そのデータパケットを、ＵＩＢＣを通じたソースデバイスへのネットワークトランスポートのために処理し得る。

本開示の技法によれば、シンクデバイス３６０は、ホストシステム３００からのトリガ情報を検出することができる。ホストシステム３００は、環境条件、ユーザの挙動、および／またはホストシステム３００からのユーザ入力を感知することが可能な、１つまたは複数のセンサ３１２を含み得る。ＭＣモードユニット３７８は、検出されたトリガ情報を処理して、検出されたトリガ情報と関連付けられるＭＣモードのレベルの１つを判定する。ＭＣモードユニット３７８は次いで、シンクデバイス３６０において判定されたレベルのＭＣモードをアクティブ化し、ユーザ入力インターフェース３７６を介した自動車のユーザによって許容される対話のタイプを修正することができ、たとえば、ボイスコマンドおよびタッチコマンドを許容し、ボイスコマンドのみを許容し、またはコマンドを許容しない。図３ではシンクデバイス３６０内の別個のユニットとして示されるが、他の例では、ＭＣモードユニット３７８は、検出されたトリガ情報に基づいてＭＣモードのレベルを判定しアクティブ化するように、プロセッサ３３１内で動作することができる。

ＭＣモードのレベルをアクティブ化すると、ＭＣモードユニット３７８はまた、ＭＣモードのアクティブ化されたレベルを示す信号を生成し、その信号をソースデバイスに送信するように、トランスポートユニット３３３に指示する。一例として、トランスポートユニット３３３は、データパケット内で、ＭＣモードのアクティブ化されたレベルを示し得る。トランスポートユニット３３３は、そのデータパケットを、ＵＩＢＣを通じたソースデバイスへのネットワークトランスポートのために処理し得る。別の例として、トランスポートユニット３３３は、通信チャネルを通じてソースデバイスに送信される制御メッセージ、たとえばＲＴＳＰ制御メッセージ内で、ＭＣモードのアクティブ化されたレベルを示し得る。ソースデバイスは次いで、示されたＭＣモードレベルに基づいて、シンクデバイス３６０に送信されているＡ／Ｖデータのタイプ、たとえば、電話呼、テキストメッセージ、ならびにオーディオおよび／またはビデオコンテンツを修正することができる。

一例として、ホストシステム３００は、自動車のコンソール内のメディアヘッドユニットとしてシンクデバイス３６０を含む、自動車ホストシステムを備え得る。この場合、ホストシステム３００は、自動車のいくつかの部分と自動車のユーザとの対話とを制御するように構成される、自動車のコンピュータシステムを備え得る。ホストシステム３００が自動車ホストシステムを備える場合、トリガ情報は、車線の変更、道を曲がること、悪い気象条件（たとえば、雨または雪）、他の車両が近づいていること、または単に運転していることの、指示を含み得る。いくつかの例では、トリガ情報は、ホストシステム３００中のセンサ３１２の１つを介して、またはユーザ入力インターフェース３７６を介して受信される、特定の環境条件または意図的なユーザの挙動、たとえば、運転していることを示すユーザ入力を備え得る。トリガ情報は、モバイルデバイスまたは他のコンピューティングデバイスを使用するときに、法律、規制、または安全な運転習慣に適合するように規則を定義する、ＭＣモードの具体的なレベルを特定することができる。

別の例では、ホストシステム３００は、会議場の中のプロジェクタ、モニタ、またはテレビジョンとしてシンクデバイス３６０を含む、会議場ホストシステムを備え得る。この場合、ホストシステム３００は、会議場のいくつかの部分を制御し、会議場のユーザ（たとえば、発表者および／または聴衆）とのインターフェースをとるように構成される、会議場のコンピュータシステムを備え得る。ホストシステム３００が会議場を備える場合、トリガ情報は、照明が弱くなったこと、複数の人が部屋に入ったこと、または、発表が始まろうとしているというユーザ入力の、指示を含み得る。いくつかの例では、トリガ情報は、ホストシステム３００中のセンサ３１２の１つを介して、またはユーザ入力インターフェース３７６を介して受信される、意図的なユーザの挙動、たとえば、発表を行っていることを示すユーザ入力を備え得る。この場合、トリガ情報は、発表の間に、個人的なまたは無関係のメディアデータ、たとえば、電話呼、テキストメッセージ、または他のオーディオおよび／もしくはビデオコンテンツを発表のすべての聴衆が見ないことを確実にするように規則を定義する、ＭＣモードの具体的なレベルを特定することができる。

本開示で説明されるＭＣモード機構は、事前に定義されたトリガ情報がホストシステム３００から検出されたことに応答して、シンクデバイス３６０の動作の１つまたは複数の異なるレベルを定義する。ＭＣモードの１つまたは複数のレベルの各々は、シンクデバイス３６０のどの動作が修正され得るかに従って、規則を規定する。たとえば、ＭＣモードの所与のレベルに対する規則は、所与のＭＣモードレベルで動作している間に、シンクデバイス３６０が、どのタイプのメディアデータをソースデバイスから受信するかを決定し得る。加えて、ＭＣモードの所与のレベルに対する規則は、あるタイプのユーザ対話のみを許容するように、たとえば、ボイスコマンドおよびタッチコマンドを許容し、ボイスコマンドのみを許容し、またはコマンドを許容しないように、シンクデバイス３６０におけるユーザ入力インターフェース３７６の修正を指示することができる。図２からのソースデバイス２２０に関して上で説明されたように、ＭＣモードに含まれるレベルの数は、ＷＤ通信セッション規格、たとえばＷＦＤまたはＴＤＬＳに従って定義され得る。

シンクデバイス３６０および／またはシンクデバイス３６０と通信しているソースデバイスのベンダーは、レベルの各々と関連付けられる規則を設定することを担い得る。ベンダーはまた、ホストシステム３００からのトリガ情報を割り当てて、レベルの各々を特定することを担い得る。ＭＣモードの異なるレベルに対する設定された規則およびトリガ情報は、ＭＣモードユニット３７８またはメモリ３３２に記憶され得る。ＭＣモードレベルの各々と関連付けられる規則は、ソースデバイスによってレンダリングされシンクデバイス３６０に送信されることが許容されるメディアデータのタイプと、特定のＭＣモードレベルで動作している間にシンクデバイス３６０において許容されるユーザ対話のタイプとを、規定する。

ＭＣモードユニット３７８が、ホストシステム３００内のセンサ３１２からトリガ情報を受信すると、ＭＣモードユニット３７８は、検出されたトリガ情報と関連付けられるＭＣモードレベルを決定する。ＭＣモードユニット３７８は次いで、シンクデバイス３６０において、ＭＣモードの決定されたレベルをアクティブ化することができる。アクティブ化されたＭＣモードレベルに基づいて、ＭＣモードユニット３７８は、ＭＣモードのアクティブ化されたレベルと関連付けられる規則によって許容されるタイプのユーザ入力と対話とのみを受け入れるように、たとえば、ボイスコマンドおよびタッチコマンドを受け入れ、ボイスコマンドのみを受け入れ、またはコマンドを受け入れないように、ユーザ入力インターフェース３７６の動作を修正する。加えて、ＭＣモードユニット３７８は、ＭＣモードのアクティブ化されたレベルを示す信号を生成し、その信号をソースデバイスに送信して、ＭＣモードレベルで動作している間にレンダリングされシンクデバイス３６０に送信されるデータのタイプを修正するように、トランスポートユニット３３３に指示する。

上の表１に関して、ＭＣ−１レベルにおいて、関連付けられる規則は、シンクデバイス３６０が、ソースデバイスからの電話呼と一般的なＡ／Ｖコンテンツとを受信することを許容し得るが、テキストメッセージをボイスコマンドのみに制約し得る。ＭＣ−２レベルにおいて、関連付けられる規則は、ソースデバイスから受信される電話呼と一般的なＡ／Ｖコンテンツとをボイスコマンドのみに制約し、ソースデバイスからのテキストメッセージを除去することができる。この場合、ＭＣ−２レベルと関連付けられる規則は、ユーザ入力インターフェース３７６を介したソースデバイス３６０におけるすべてのユーザ対話を、ボイスコマンドのみに制約し得る。ＭＣ−３レベルにおいて、関連付けられる規則は、ソースデバイスから受信されたすべての電話呼と、テキストメッセージと、一般的なＡ／Ｖコンテンツとを除去することができる。この場合、ＭＣ−３レベルと関連付けられる規則は、ユーザ入力インターフェース３７６を介したシンクデバイス３６０におけるあらゆるユーザ対話を許容できない。

ホストシステム３００が自動車ホストシステムを備える一例として、表１のＭＣモードレベルによれば、ユーザが良好な条件で運転していることをシンクデバイス３６０がホストシステム３００中のセンサ３１２を介して検出すると、シンクデバイス３６０は、ＭＣ−１のアクティブ化をソースデバイスにシグナリングして、ソースデバイスにおけるテキストメッセージングアプリケーションの動作のみを修正することができる。ユーザが悪い条件（たとえば、交通混雑または悪天候）の中で運転していることをシンクデバイス３６０が検出すると、シンクデバイス３６０は、ＭＣ−２またはＭＣ−３のアクティブ化をソースデバイスにシグナリングして、ソースデバイスにおいて動作しているすべてのメディアデータアプリケーションの動作を修正し、かつシンクデバイス３６０におけるユーザ入力インターフェース３７６の動作を修正することができる。

図３のプロセッサ３３１は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、他の等価な集積回路もしくはディスクリート論理回路、またはそれらの何らかの組合せのような、広範囲のプロセッサのうちの１つまたは複数を備え得る。図３のメモリ３３２は、限定はされないが、同期ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）などのランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）、電気的消去可能プログラマブル読取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリなどを含む、多種多様な揮発性または不揮発性メモリのいずれかを備えてよく、メモリ２３２は、オーディオデータ／ビデオデータならびに他の種類のデータを記憶するためのコンピュータ可読記憶媒体を備えてよい。メモリ３３２は、加えて、本開示で説明される様々な技法を実行することの一部として、プロセッサ３３１によって実行される命令とプログラムコードとを記憶し得る。

図４は、通信チャネル１５０を通じて通信するために、図１の送信機／受信機１２６および送信機／受信機１６６によって使用され得る例示的な送信機システム４１０と受信機システム４５０とを示すブロック図である。送信機システム４１０において、いくつかのデータストリームのトラフィックデータがデータソース４１２から送信（ＴＸ）データプロセッサ４１４に与えられる。各データストリームは、それぞれの送信アンテナを通じて送信され得る。ＴＸデータプロセッサ４１４は、各データストリームのトラフィックデータを、そのデータストリーム用に選択された特定のコーディング方式に基づいてフォーマットし、コーディングし、インターリーブする。各データストリームのコーディングされたデータは、直交周波数分割多重化（ＯＦＤＭ）技法を使用してパイロットデータと多重化され得る。限定はされないが、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、符号分割多元接続（ＣＤＭＡ）、またはＯＦＤＭ、ＦＤＭＡ、ＴＤＭＡおよび／またはＣＤＭＡの任意の組合せを含む、多種多様な他のワイヤレス通信技法も使用され得る。

図４に従って、パイロットデータは通常、知られている方法で処理される知られているデータパターンであり、チャネル応答を推定するために受信機システム４５０において使用され得る。次いで、各データストリームの多重化されたパイロットおよびコーディングされたデータは、変調シンボルを与えるために、そのデータストリーム用に選択された特定の変調方式（たとえば、２位相シフトキーイング（ＢＰＳＫ）、４位相シフトキーイング（ＱＰＳＫ）、Ｍ−ＰＳＫ、またはＭ−ＱＡＭ（直交振幅変調）、ここでＭは２のべき乗（a power of two）であり得る）に基づいて変調（たとえば、シンボルマッピング）される。各データストリームのデータレート、コーディング、および変調は、メモリ４３２に結合され得るプロセッサ４３０によって実行される命令によって決定され得る。

次いで、データストリームの変調シンボルがＴＸ ＭＩＭＯプロセッサ４２０に与えられ、ＴＸ ＭＩＭＯプロセッサ４２０はさらに（たとえば、ＯＦＤＭ用に）その変調シンボルを処理し得る。次いで、ＴＸ ＭＩＭＯプロセッサ４２０は、Ｎ_T個の変調シンボルストリームをＮ_T個の送信機（ＴＭＴＲ）４２２Ａ〜４２２Ｔ（「送信機４２２」）に与え得る。いくつかの態様では、ＴＸ ＭＩＭＯプロセッサ４２０は、データストリームのシンボルと、シンボルの送信元のアンテナとにビームフォーミング重みを適用する。送信機４２２の各々は、それぞれのシンボルストリームを受信し、処理して、１つまたは複数のアナログ信号を与え、さらに、それらのアナログ信号を調整（たとえば、増幅、フィルタリング、およびアップコンバート）して、ＭＩＭＯチャネルを通じて送信するのに適した変調された信号を与え得る。次いで、送信機４２２からのＮ_T個の変調された信号は、それぞれＮ_T個のアンテナ４２４Ａ〜４２４ｔ（「アンテナ４２４」）から送信される。

受信機システム４５０では、送信される変調された信号はＮ_R個のアンテナ４５２Ａ〜４５２Ｒ（「アンテナ４５２」）によって受信され、アンテナ４５２の各々からの受信された信号は、受信機（ＲＣＶＲ）４５４Ａ〜４５４Ｒ（「受信機４５４」）のそれぞれ１つに与えられる。受信機４５４の各々は、それぞれの受信された信号を調整（たとえば、フィルタリング、増幅、およびダウンコンバート）し、調整された信号をデジタル化してサンプルを与え、さらにそれらのサンプルを処理して、対応する「受信」シンボルストリームを与える。次いで、受信（ＲＸ）データプロセッサ４６０は、Ｎ_R個の受信機４５４からＮ_R個の受信シンボルストリームを受信し、特定の受信機処理技法に基づいて処理して、Ｎ_T個の「検出」シンボルストリームを与える。次いで、ＲＸデータプロセッサ４６０は、各検出シンボルストリームを復調し、デインターリーブし、復号して、データストリームのトラフィックデータを復元する。ＲＸデータプロセッサ４６０による処理は、送信機システム４１０におけるＴＸ ＭＩＭＯプロセッサ４２０およびＴＸデータプロセッサ４１４によって実行される処理を補足するものである。

メモリ４７２と結合され得るプロセッサ４７０は、どのプリコーディング行列を使用すべきかを定期的に判定する。逆方向リンクメッセージは、通信リンクおよび／または受信データストリームに関する様々なタイプの情報を備え得る。次いで、逆方向リンクメッセージは、データソース４３６からいくつかのデータストリームのトラフィックデータも受信するＴＸデータプロセッサ４３８によって処理され、変調器４８０によって変調され、送信機４５４によって調整され、送信機システム４１０に戻される。

送信機システム４１０において、受信機システム４５０からの変調された信号は、アンテナ４２４によって受信され、受信機４２２によって調整され、復調器４４０によって復調され、受信機システム４５０によって送信された逆方向リンクメッセージを抽出するためにＲＸデータプロセッサ４４２によって処理される。次いで、プロセッサ４３０は、ビームフォーミング重みを決定するためにどのプリコーディング行列を使用すべきかを決定し、抽出されたメッセージを処理する。

図５は、ソースデバイス５２０とシンクデバイス５６０との間のＭＣモードの機能のネゴシエーションを実行するための例示的なメッセージ転送シーケンスを示す概念図である。ＭＣモードの機能のネゴシエーションは、ソースデバイス５２０とシンクデバイス５６０との間のより大きい通信セッションの確立プロセスの一部として行われ得る。このセッションは、たとえば、基礎をなす接続規格としてＷＦＤまたはＴＤＬＳとともに確立され得る。ＷＦＤまたはＴＤＬＳセッションを確立した後に、シンクデバイス５６０は、ソースデバイス５２０とのＴＣＰ接続を開始することができる。ＴＣＰ接続を確立することの一部として、ソースデバイス５２０とシンクデバイス５６０との間の通信セッションを管理するために、リアルタイムストリーミングプロトコル（ＲＴＳＰ）を実行する制御ポートが確立され得る。

ソースデバイス５２０は、一般に、図１のソースデバイス１２０について上で説明されたのと同じ方法で動作することができ、かつシンクデバイス５６０は、一般に、図１のシンクデバイス１６０について上で説明されたのと同じ方法で動作することができる。ソースデバイス５２０およびシンクデバイス５６０が接続を確立した後、ソースデバイス５２０およびシンクデバイス５６０は、後続の通信セッションのために使用されるべきパラメータのセットを決定し、機能のネゴシエーションの交換の一部としてＭＣモードがサポートされるかどうかを判定することができる。

ソースデバイス５２０およびシンクデバイス５６０は、メッセージのシーケンスを通して機能をネゴシエートし得る。それらのメッセージは、たとえば、リアルタイムストリーミングプロトコル（ＲＴＳＰ）メッセージであり得る。そのネゴシエーションのいずれかの段階において、ＲＴＳＰ要求メッセージの受信側が、ＲＴＳＰ ＯＫ以外のＲＴＳＰステータスコードを含むＲＴＳＰ応答で応答することがあり、その場合、メッセージ交換はパラメータの異なるセットを用いて再試行されてよく、または機能のネゴシエーションのセッションは終了してよい。

ソースデバイス５２０は、シンクデバイス５６０がサポートするＲＴＳＰ方法のセットを決定するために、シンクデバイス５６０にＲＴＳＰ ｏｐｔｉｏｎｓ要求メッセージ５７０を送信することができる。ソースデバイス５２０からメッセージ５７０を受信すると、シンクデバイス５６０は、シンク５６０によってサポートされるＲＴＳＰ方法を列挙する、ＲＴＳＰ ｏｐｔｉｏｎｓ応答メッセージ５７２で応答することができる。メッセージ５７２はまた、ＲＴＳＰ ＯＫステータスコードを含み得る。

ソースデバイス５２０にメッセージ５７２を送信した後に、シンクデバイス５６０は、ソースデバイス５２０がサポートするＲＴＳＰ方法のセットを決定するために、ＲＴＳＰ ｏｐｔｉｏｎｓ要求メッセージ５７４を送信することができる。シンクデバイス５６０からメッセージ５７４を受信すると、ソースデバイス５２０は、ソースデバイス５２０によってサポートされるＲＴＳＰ方法を列挙する、ＲＴＳＰ ｏｐｔｉｏｎｓ応答メッセージ５７６で応答することができる。メッセージ５７６はまた、ＲＴＳＰ ＯＫステータスコードを含み得る。

メッセージ５７６を送信した後に、ソースデバイス５２０は、ソースデバイス５２０に関係のある機能のリストを規定するために、ＲＴＳＰ ｇｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージ５７８を送信することができる。本開示の技法によれば、メッセージ５７８において要求される機能の１つは、シンクデバイス５６０がＭＣモードをサポートすることが可能かどうかである。たとえば、ＭＣモード機能パラメータは、「ｕｉｂｃ＿ｍｃ＿ｍｏｄｅ＿ｃａｐａ」という名称であってよく、ＲＴＳＰ ｇｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージ５７８は次の通りであり得る。

シンクデバイス５６０は、ＲＴＳＰステータスコードを含み得るＲＴＳＰ ｇｅｔ＿ｐａｒａｍｅｔｅｒ応答メッセージ５８０で応答し得る。ＲＴＳＰステータスコードがＯＫである場合、メッセージ５８０は、シンクデバイス５６０によってサポートされる、ＲＴＳＰ ｇｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージ５７８中で規定されたパラメータに対する応答パラメータも含み得る。シンクデバイス５６０は、シンクデバイス５６０がサポートしない、メッセージ５７８中のパラメータを無視することができる。例として、シンクデバイス５６０は、ＲＴＳＰ ｇｅｔ＿ｐａｒａｍｅｔｅｒ応答メッセージ５８０によって応答して、シンクデバイスがＭＣモードをサポートできることを宣言することができ、たとえば、ｕｉｂｃ＿ｍｃ＿ｍｏｄｅ＿ｃａｐａ：ｙｅｓである。シンクデバイス２０の宣言は、以下のように、ＡＢＮＦ（Augmented Backus-Naur Form）（拡張バッカスナウア記法）フォーマットに従い得る。

この場合、ＲＴＳＰ ｇｅｔ＿ｐａｒａｍｅｔｅｒ応答メッセージ５８０は次の通りであり得る。

メッセージ５８０に基づいて、ソース５２０は、通信セッションのために使用されるべきパラメータの最適セットを決定することができ、シンクデバイス５６０にｓｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージ５８２を送信することができる。ｓｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージ５８２は、ソースデバイス５２０とシンクデバイス５６０との間の通信セッション中に使用されるべきパラメータセットを含み得る。たとえば、ソースデバイス５２０とシンクデバイス５６０の両方がＭＣモードをサポートする場合、ソースデバイス５２０は、通信セッションに対するＭＣモードを有効にし得る。ＭＣモードを有効にするために、ソースデバイス５２０は、ＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージ５８２をシンクデバイス５６０に送信して、ＭＣモードが有効にされ通信セッションの間に使用されることを示し、たとえば、ｕｉｂｃ＿ｍｃ＿ｍｏｄｅ＿ｃａｐａ：ｙｅｓである。ＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージ５８２は次の通りであり得る。

メッセージ５８２を受信すると、シンクデバイス５６０は、メッセージ５８２中で規定されたパラメータを設定することが成功していたかどうかを示すＲＴＳＰステータスコードを含むＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ応答メッセージ５８４で応答することができる。たとえば、シンクデバイス５６０が、以前の（earlier）ＲＴＳＰ ｇｅｔ＿ｐａｒａｍｅｔｅｒ応答メッセージ５８０においてＭＣモードのサポートを示す場合、シンクデバイス５６０は、ＭＣモードが通信セッションの間に使用されることを、ソースデバイス５２０に対して肯定的に応答し、たとえば、ｕｉｂｃ＿ｍｃ＿ｍｏｄｅ＿ｃａｐａ：ｙｅｓである。ＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ応答メッセージ５８４は次の通りであり得る。

ＭＣモードが通信セッションに対して有効にされると、シンクデバイス５６０は、シンクデバイス５６０のホストシステムから検出されたトリガ情報に基づいて、ＭＣモードのレベルの１つをアクティブ化し、ＭＣモードのアクティブ化されたレベルをソースデバイス５２０にシグナリングする。一例では、シンクデバイス５６０は、ＲＴＳＰ制御メッセージを使用して、ＭＣモードのアクティブ化されたレベルをソースデバイス５２０に示すことができる。この例では、シンクデバイス５６０は、ＭＣモードレベルパラメータを含むＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージ５８６をソースデバイス１２に送信する。たとえば、ＭＣモードレベルパラメータは、「ｕｉｂｃ＿ｍｃ＿ｍｏｄｅ」という名称であり得る。ＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージ５８６は次の通りであり得る。

ホストシステムから検出されたトリガ情報に基づいて、ＭＣモードの特定のレベル、たとえばＭＣモードレベル２（「ｍｃ−２」）をアクティブ化すると、シンクデバイス５６０は、ＭＣモードのアクティブ化されたレベルを示す信号をソースデバイス５２０に送信し、たとえば、ｕｉｂｃ＿ｍｃ＿ｍｏｄｅ：ｍｃ−２である。ＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージ５８６は次の通りであり得る。

メッセージ５８６を受信すると、シンクデバイス５６０は、メッセージ５８６中で規定されたＭＣモードレベルを設定することが成功していたかどうかを示すＲＴＳＰステータスコードを含むＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ応答メッセージ５８８で応答することができる。たとえば、シンクデバイス５６０が、メッセージ５８６においてＭＣモードのアクティブ化されたレベルとしてｍｃ−２を示す場合、ソースデバイス５２０は、レベル２のＭＣモードが通信セッションの間に使用されることを、シンクデバイス５６０に対して肯定的に応答し、たとえば、ｕｉｂｃ＿ｍｃ＿ｍｏｄｅ：ｍｃ−２である。ＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ応答メッセージ５８８は次の通りであり得る。

他の例では、シンクデバイス５６０およびソースデバイス５２０は、ＭＣモードの特定のレベルのアクティブ化と使用とを示すために、図５に示されるように、ＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒメッセージ５８６と５８８とを交換しなくてよい。別の例では、シンクデバイス５６０は代わりに、ＵＩＢＣを使用して、ＭＣモードのアクティブ化されたレベルをソースデバイス５２０にシグナリングすることができる。ＭＣモードのアクティブ化されたレベルを示すためのＵＩＢＣパケットのフォーマットが、図６に関してより詳しく説明される。上述のように、ソースデバイスとシンクデバイスとの役割は、異なるセッションでは逆になるかまたは変化し得る。通信セッションをセットアップするメッセージの順序は、場合によっては、ソースとして動作するデバイスを定義し、シンクとして動作するデバイスを定義し得る。

図６は、ＭＣモードのアクティブ化されたレベルをシンクデバイスからソースデバイスにシグナリングするために使用され得る、例示的なデータパケット６００を示す概念図である。図１を参照してデータパケット６００の態様が説明されるが、論じられる技法は追加のタイプのＷＤシステムに適用可能であり得る。データパケット６００はデータパケットヘッダ６１０を含んでよく、その後にペイロードデータ６５０が続く。データパケット６００は、たとえば、シンクデバイス１６０において受信されるユーザ入力データをシグナリングするため、または、シンクデバイス１６０においてアクティブ化されるＭＣモードレベルをシグナリングするために、シンクデバイス１６０からソースデバイス１２０に送信され得る。

ペイロードデータ６５０に含まれるデータのタイプ、たとえば、ユーザ入力データまたはＭＣモードレベルデータは、データパケットヘッダ６１０において識別され得る。このようにして、データパケットヘッダ６１０のコンテンツに基づいて、ソースデバイス１２０は、データパケット６００のペイロードデータ６５０を解析して、シンクデバイス１６０からのユーザ入力データまたはＭＣモードレベルデータを識別することができる。本開示で使用する「解析」および「解析する」という用語は、一般に、ビットストリームからデータを抽出するためにビットストリームを分析するプロセスを指す。データを抽出することは、たとえば、ビットストリーム中の情報がどのようにフォーマットされているかを識別することを含み得る。以下でより詳しく説明されるように、データパケットヘッダ６１０は、ペイロードデータ６５０に対して可能な多くのフォーマットの１つを定義することができる。データパケットヘッダ６１０を解析することによって、ソースデバイス１２０は、ペイロードデータ６５０がどのようにフォーマットされているかということと、ユーザ入力コマンドまたはＭＣモードレベル指示を抽出するためにペイロードデータ６５０をどのように解析すべきかということとを判定することができる。

いくつかの例では、データパケットヘッダ６１０は、図６に示されるようにフォーマットされる、１つまたは複数のフィールド６２０を含み得る。フィールド６２０に隣接する番号０〜１５ならびにビットオフセット０、１６、および３２は、データパケットヘッダ６１０内のビット位置を識別することを目的としており、データパケットヘッダ６１０内に含まれている情報を実際に表すことを目的としていない。データパケットヘッダ６１０は、バージョンフィールド６２１と、タイムスタンプフラグ６２２と、予約フィールド６２３と、入力カテゴリーフィールド６２４と、長さフィールド６２５と、任意選択のタイムスタンプフィールド６２６とを含む。図６の例では、バージョンフィールド６２１は、シンクデバイス１６０によって実装されている特定の通信プロトコルのバージョンを示し得る３ビットフィールドである。バージョンフィールド６２１中の値は、データパケットヘッダ６１０の残りをどのように解析すべきか、ならびにペイロードデータ６５０をどのように解析すべきかを、ソースデバイス１２０に通知し得る。

図６の例では、タイムスタンプフラグ（Ｔ）６２２は、タイムスタンプフィールド６２６がデータパケットヘッダ６１０中に存在するかどうかを示す１ビットフィールドである。存在する場合、タイムスタンプフィールド６２６は、ソースデバイス１２０によって生成され、シンクデバイス１６０に送信された、マルチメディアデータに基づくタイムスタンプを含む１６ビットフィールドである。タイムスタンプは、たとえば、ビデオのフレームがシンクデバイス１６０に送信されるより前に、ソースデバイス１２０によってそのフレームに割り当てられる、連続値であり得る。データパケットヘッダ６１０を解析し、タイムスタンプフィールド６２６が存在するかどうか判定すると、ソースデバイス１２０は、タイムスタンプフィールド６２６中に含まれるタイムスタンプを処理する必要があるかどうかを知る。図６の例では、予約フィールド６２３は、バージョンフィールド６２１において識別される特定のプロトコルの今後のバージョンに対して予約された、８ビットフィールドである。

図６の例では、入力カテゴリーフィールド６２４は、ペイロードデータ６５０中に含まれているデータについての入力カテゴリーを識別するための４ビットフィールドである。たとえば、シンクデバイス１６０は、入力カテゴリーを判定するためにユーザ入力データを分類し得る。ユーザ入力データを分類することは、たとえば、コマンドの受信元のデバイスに基づくか、またはコマンド自体の性質に基づき得る。シンクデバイス１６０はまた、入力カテゴリーを判定するためにＭＣモードレベル命令を分類し得る。入力カテゴリーフィールド６２４の値は、場合によってはデータパケットヘッダ６１０の他の情報ととともに、ペイロードデータ６５０がどのようにフォーマットされているかをソースデバイス１２０に対して識別する。このフォーマッティングに基づいて、ソースデバイス１２０は、ペイロードデータ６５０を解析して、ユーザ入力コマンドまたはＭＣモードレベル指示を抽出することができる。

長さフィールド６２５は、データパケット６００の長さを示すための１６ビットフィールドを備え得る。データパケット６００が１６ビットのワードでソースデバイス１２０によって解析されるとき、データパケット６００は１６ビットの整数までパディングされ得る。長さフィールド６２５中に含まれている長さに基づいて、ソースデバイス１２０は、ペイロードデータ６５０の終了（すなわちデータパケット６００の終了）と新しい後続のデータパケットの開始とを識別することができる。

図６の例で与えられるフィールドの様々なサイズは単に説明用であるものとし、それらのフィールドは、図６に示されるものとは異なる数のビットを使用して実装され得るものとする。加えて、データパケットヘッダ６１０は、上で論じられたすべてのフィールドよりも少数のフィールドを含み得るか、または上で論じられない追加のフィールドを使用し得ることも企図される。実際に、本開示の技法は、パケットの様々なデータフィールドのために使用される実際のフォーマットの観点で、柔軟性があり得る。

入力カテゴリー６２４は、多くの可能な入力カテゴリーの１つを識別することができる。１つのそのような入力カテゴリーは、ペイロードデータ６５０のユーザ入力データが、ソースデバイス１２０とシンクデバイス１６０の両方によって実行されているプロトコルにおいて定義されている汎用情報要素を使用してフォーマットされていることを示すための、汎用入力フォーマットであり得る。汎用入力フォーマットは、シンクデバイス１６０のユーザがアプリケーションレベルでソースデバイス１２０と対話することを可能にする、汎用情報要素を利用し得る。

別のそのような入力カテゴリーは、ペイロードデータ６５０のユーザ入力データが、入力データを受信するために使用される入力デバイスのタイプに基づいてフォーマットされていることを示すための、ヒューマンインターフェースデバイスコマンド（ＨＩＤＣ）入力フォーマットであり得る。デバイスのタイプの例は、キーボード、マウス、タッチ入力デバイス、ジョイスティック、カメラ、（カメラベースの入力デバイスなどの）ジェスチャー捕捉デバイス、およびリモートコントロールを含む。入力カテゴリーフィールド６２４中で識別され得る他のタイプの入力カテゴリーは、ペイロードデータ６５０中のユーザデータがシンクデバイス１６０において発生しなかったことを示すための転送入力フォーマット、またはオペレーティングシステム固有フォーマットと、ペイロードデータ６５０がボイスコマンドを含むことを示すためのボイスコマンドフォーマットとを含む。

本開示の技法によれば、さらなる入力カテゴリーは、ペイロードデータ６５０のユーザ入力データが、ソースデバイス１２０とシンクデバイス１６０の両方によって実行されているプロトコルにおいて定義されている命令情報要素を使用してフォーマットされていることを示すための、命令入力フォーマットであり得る。命令入力フォーマットは、シンクデバイス１６０におけるＭＣモードのアクティブ化されたレベルを示す、命令情報要素を利用することができる。

入力カテゴリーフィールド６２４において識別され得る入力カテゴリーが、以下の表２に含まれる。図６の例では入力カテゴリー６２４は４ビットであり、１６個の異なる入力カテゴリーが場合によっては識別され得る。表２は３個の入力カテゴリーを定義し、残りの入力カテゴリーを予約として保持する。

たとえば、命令入力がペイロードデータ６５０中に存在することを、データパケットヘッダ６１０の入力カテゴリーフィールド６２４が示す場合、ペイロードデータ６５０は命令入力フォーマットを有し得る。したがって、ソースデバイス１２０は、命令入力フォーマットに従ってペイロードデータ６５０を解析することができる。ペイロードデータ６５０内での命令入力イベントは、入力イベントヘッダを含み得る。以下の表３は、ＭＣモードレベル命令入力イベント（ＩＥ）に対する命令ＩＥヘッダのフィールドを定義する。

命令ＩＥ識別情報（ＩＤ）フィールドは、命令タイプ、たとえばＭＣモード命令タイプを識別する。命令ＩＥ ＩＤフィールドは、たとえば、長さが１オクテットであってよく、以下の表４から選択された識別情報を含み得る。この例のように、命令ＩＥ ＩＤフィールドが８ビットである場合、（０〜２５５と識別される）２５６個の異なるタイプの命令が識別可能であり得るが、すべての２５６個の識別情報が必ずしも関連付けられた命令タイプを必要とするとは限らない。２５６個のうちの一部は、今後の使用のために予約され得る。表４では、たとえば、命令ＩＥ ＩＤ ０のみが、ＭＣモード命令タイプを示すものとして定義される。命令ＩＥ ＩＤ １〜２５５は、関連付けられた命令タイプを有さないが、今後、命令タイプを割り当てられ得る。

この例では、命令ＩＥ ＩＤがＭＣモード命令タイプを示す場合、命令ＩＥヘッダ中の長さフィールドはＭＣモードレベルコードフィールドの長さを識別し、一方、ＭＣモードレベルコードフィールドは命令を表す情報要素を含む。ＭＣモードレベルコードフィールドのフォーマッティングは、命令ＩＥ ＩＤフィールド中のＭＣモード命令タイプから知られる。したがって、ソースデバイス１２０は、命令ＩＥ ＩＤフィールド中で識別されるＭＣモード命令タイプに基づいて、ＭＣモードレベルコードフィールドのコンテンツを解析し得る。命令ＩＥヘッダの長さフィールドに基づいて、ソースデバイス１２０は、ペイロードデータ６５０中の命令ＩＥの終了を判定し得る。

表４は、各々が命令タイプを識別するために使用され得る対応する命令ＩＥ ＩＤを伴う、命令タイプの一例を与える。上で論じられたように、この例では、命令ＩＥ ＩＤ ０のみが、ＭＣモード命令タイプを示すものとして定義される。表４中の命令ＩＥ ＩＤ １〜２５５は、関連付けられた命令タイプを有さないが、今後、命令タイプを割り当てられ得る。

ＭＣモード命令タイプと関連付けられるＭＣモードレベルコードフィールドは、特定のフォーマットを有し得る。ＭＣモードレベルコードフィールドは、シンクデバイス１６０においてアクティブ化されているＭＣモードのレベルの１つを示すために、以下の表５において識別される情報要素を含み得る。

たとえば、ＭＣモードレベルコード０は、シンクデバイス１６０においてアクティブ化されているＭＣモードレベルがないことを示す。この場合、ソースデバイス１２０の動作を修正するための規則は適用されない。表５によれば、ＭＣモードレベルコード１、２、および３はそれぞれ、ＭＣモードレベルＭＣ−１、ＭＣ−２、およびＭＣ−３がシンクデバイス１６０においてアクティブ化されていることを示す。アクティブ化されたＭＣモードレベルの指示に基づいて、本開示の技法は、アクティブ化されたレベルに対して設定される規則に基づいて、ソースデバイス１２０の動作を修正することができる。

ある例として、ＭＣ−１レベルにおいて、関連付けられる規則は、電話呼および一般的なＡ／Ｖコンテンツの通常の処理とシンクデバイス１６０への送信とを許容し得るが、オーディオベースのテキストメッセージのみをレンダリングするように、ソースデバイス１２０の動作を制約し得る。ＭＣ−２レベルにおいて、関連付けられる規則は、オーディオベースの電話呼と一般的なＡ／Ｖコンテンツとのみをレンダリングし、テキストメッセージを何らレンダリングしないように、ソースデバイス１２０の動作を制約し得る。加えて、ＭＣ−２レベルと関連付けられる規則は、シンクデバイス１６０におけるユーザ対話を、ボイスコマンドのみに制約し得る。ＭＣ−３レベルにおいて、関連付けられる規則は、シンクデバイス１６０への送信のための電話呼、テキストメッセージ、または一般的なＡ／Ｖコンテンツを何らレンダリングしないように、ソースデバイス１２０の動作を制約し得る。加えて、ＭＣ−３レベルと関連付けられる規則は、シンクデバイス１６０におけるあらゆるユーザ対話を許容できない。他の例では、異なる規則が、ＭＣモードレベルＭＣ−１、ＭＣ−２、およびＭＣ−３の１つまたは複数に対して設定され得る。

ＭＣモードレベルコードフィールドは、たとえば、長さが１オクテットであってよく、かつ表５から選択された識別情報を含み得る。この例のように、ＭＣモードレベルコードフィールドが８ビットである場合、（０〜２５５と識別される）２５６個の異なるＭＣモードレベルが識別可能であり得るが、すべての２５６個の識別情報が必ずしも関連付けられたＭＣモードレベルを必要とするとは限らない。２５６個のうちの一部は、今後の使用のために予約され得る。表５において、たとえば、ＭＣモードレベルコード０〜３のみが、異なるＭＣモードレベルを示すものとして定義される。ＭＣモードレベルコード４〜２５５は割り当てられたＭＣモードレベルを有さないが、今後レベルを割り当てられ得る。

図７は、ＭＣモードをサポートすることが可能なソースデバイスの例示的な動作を示すフローチャートである。ＭＣモード動作が、図２からのソースデバイス２２０に関して説明される。他の例では、示される動作は、図１からのソースデバイス１２０を含む、他のソースデバイスによって実行され得る。

ソースデバイス２２０はまず、シンクデバイスと接続を確立する（７００）。たとえば、ソースデバイス２２０が、自身のメディアデータを１つまたは複数の近くのシンクデバイスに通知することができ、または、ソースデバイス２２０のユーザが、特定のシンクデバイスへの接続を手動で設定することができる。接続が確立されると、ソースデバイス２２０は、シンクデバイスと機能ネゴシエーションメッセージを交換し、その接続を通じた通信セッションのパラメータをセットアップする。たとえば、機能ネゴシエーションメッセージは、ＲＴＳＰメッセージを備え得る。本開示の技法によれば、ソースデバイス２２０は、機能要求、たとえばＲＴＳＰ ｇｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージをシンクデバイスに送信して、シンクデバイスがＭＣモードをサポートするかどうか判定する（７０２）。

たとえば、ＲＴＳＰ ｇｅｔ＿ｐａｒａｍｅｔｅｒ応答メッセージにおいて示されるように、シンクデバイスがＭＣモードをサポートしない場合（７０４のいいえの分岐）、ソースデバイス２２０は、ＭＣモードが通信セッションに対して有効ではないことを示す信号、たとえばＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージをシンクデバイスに送信する（７０６）。ソースデバイス２２０は次いで、プロセッサ２３１の通常の動作に従って、メディアデータをレンダリングしシンクデバイスへ送信することができる（７０８）。

たとえば、ＲＴＳＰ ｇｅｔ＿ｐａｒａｍｅｔｅｒ応答メッセージにおいて示されるように、シンクデバイスがＭＣモードをサポートしない場合（７０４のはいの分岐）、ソースデバイス２２０は、ＭＣモードが通信セッションに対して有効であることを示す信号、たとえばＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージをシンクデバイスに送信する（７１０）。ＭＣモードが有効にされると、ソースデバイス２２０は、シンクデバイスにおいてアクティブ化されているＭＣモードのレベルを示す信号を、シンクデバイスから受信することができる（７１２）。たとえば、シンクデバイスは、ホストシステムからトリガ情報を検出していてよく、トリガ情報に基づいて、ＭＣモードのレベルの１つ、たとえばＭＣ−１、ＭＣ−２、またはＭＣ−３をアクティブ化して、シンクデバイスにおいて受信されるメディアデータを修正していてよい。ソースデバイス２２０は、制御メッセージ、たとえばＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージ、またはデータパケット、たとえばＭＣモード命令タイプを伴うＵＩＢＣパケットのうちの１つから、ＭＣモードの示されるレベルを受信することができる。

示されるＭＣモードレベルを受信すると、ソースデバイス２２０内のＭＣモードユニット２４０は、ソースデバイス２２０においてＭＣモードの示されたレベルをアクティブ化する（７１４）。ＭＣモードユニット２４０は次いで、ＭＣモードのアクティブ化されたレベルと関連付けられる規則に従って、ソースデバイス２２０によって処理されるＡ／Ｖデータのタイプ、たとえば、電話呼、テキストメッセージ、ならびにオーディオおよび／またはビデオコンテンツを修正するようにプロセッサ２３１に指示する。ソースデバイス２２０は次いで、ＭＣモードのアクティブ化されたレベルに対して、プロセッサ２３１の修正された動作に従って、メディアデータをレンダリングしシンクデバイスへ送信することができる（７１６）。

図８は、ＭＣモードをサポートすることが可能なシンクデバイスの例示的な動作を示すフローチャートである。ＭＣモード動作が、図３からのシンクデバイス３６０に関して説明される。他の例では、示される動作は、図１からのシンクデバイス１６０を含む、他のシンクデバイスによって実行され得る。

シンクデバイス３６０はまず、ソースデバイスと接続を確立する（８００）。たとえば、シンクデバイス３６０が、近くのソースデバイス２２０からのメディアデータの通知に応答することができ、または、シンクデバイス３６０のユーザが、特定のソースデバイスへの接続を手動で設定することができる。接続が確立されると、シンクデバイス３６０は、ソースデバイスと機能ネゴシエーションメッセージを交換し、その接続を通じた通信セッションのパラメータをセットアップする。たとえば、機能ネゴシエーションメッセージは、ＲＴＳＰメッセージを備え得る。本開示の技法によれば、シンクデバイス３６０は、シンクデバイス３６０がＭＣモードをサポートするかどうかの指示のために、機能要求、たとえばＲＴＳＰ ｇｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージをソースデバイスから受信する（８０２）。

シンクデバイス３６０がＭＣモードをサポートしない場合（８０４のいいえの分岐）、シンクデバイス３６０は、ＭＣモードがサポートされないことを示す機能応答、たとえばＲＴＳＰ ｇｅｔ＿ｐａｒａｍｅｔｅｒ応答メッセージを、ソースデバイスに送信する（８０６）。シンクデバイス３６０は次いで、ＭＣモードが通信セッションに対して有効ではないことを示す信号、たとえばＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージを、ソースデバイスから受信する（７０８）。シンクデバイス３６０は次いで、ソースデバイスの通常の動作に従って、ソースデバイスからメディアデータを受信することができる（８１０）。

シンクデバイス３６０がＭＣモードをサポートしない場合（８０４のはいの分岐）、シンクデバイス３６０は、ＭＣモードがサポートされることを示す機能応答、たとえばＲＴＳＰ ｇｅｔ＿ｐａｒａｍｅｔｅｒ応答メッセージを、ソースデバイスに送信する（８１２）。シンクデバイス３６０は次いで、ＭＣモードが通信セッションに対して有効であることを示す信号、たとえばＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージを、ソースデバイスから受信する（８１４）。ＭＣモードが有効にされると、シンクデバイス３６０は、ホストシステム３００から検出されたトリガ情報に基づいて、ＭＣモードのあるレベルをアクティブ化することができる（８１６）。たとえば、シンクデバイス３６０内のＭＣモードユニット３７８は、ホストシステム３００のセンサ３１２から受信されたトリガ情報を検出し、トリガ情報に基づいて、ＭＣモード、たとえばＭＣ−１、ＭＣ−２、またはＭＣ−３のレベルの１つをアクティブ化することができる。

シンクデバイス３６０は次いで、ＭＣモードのアクティブ化されたレベルを示す信号をソースデバイスに送信する（８１８）。シンクデバイス３６０は、制御メッセージ、たとえばＲＴＳＰ ｓｅｔ＿ｐａｒａｍｅｔｅｒ要求メッセージ、またはデータパケット、たとえばＭＣモード命令タイプを伴うＵＩＢＣパケットのうちの１つを使用して、ＭＣモードのアクティブ化されるレベルを送信することができる。シンクデバイス３６０は、ＭＣモードのアクティブ化されるレベルをソースデバイスに送信して、ＭＣモードのアクティブ化されたレベルと関連付けられる規則に従って、シンクデバイス３６０において受信されるＡ／Ｖデータのタイプ、たとえば、電話呼、テキストメッセージ、ならびにオーディオおよび／またはビデオコンテンツを修正する。シンクデバイス３６０は次いで、ＭＣモードのアクティブ化されたレベルに対して、ソースデバイスの修正された動作に従って、メディアデータをソースデバイスから受信する（８２０）。加えて、ＭＣモードユニット３７８は、ＭＣモードのアクティブ化されたレベルと関連付けられる規則によって許容されるタイプのユーザ対話のみを受け入れるように、たとえば、ボイスコマンドおよびタッチコマンドを受け入れ、ボイスコマンドのみを受け入れ、またはコマンドを受け入れないように、ユーザ入力インターフェース３７６の動作を修正する。

１つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装する場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶するか、またはコンピュータ可読媒体を介して送信することができる。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータデータ記憶媒体または通信媒体を含み得る。いくつかの例では、コンピュータ可読媒体は、非一時的コンピュータ可読媒体を備え得る。データ記憶媒体は、本開示で説明された技法の実装のための命令、コードおよび／またはデータ構造を取り出すために１つまたは複数のコンピュータまたは１つまたは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であり得る。

限定ではなく例として、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくは他の光ディスクストレージ、磁気ディスクストレージ、もしくは他の磁気ストレージデバイス、フラッシュメモリ、または、命令またはデータ構造の形態の所望のプログラムコードを搬送または記憶するために使用されコンピュータによってアクセスされ得る、任意の他の媒体のような、非一時的媒体を備え得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびＢｌｕ−ｒａｙディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。

コードは、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、または他の等価な集積回路もしくはディスクリート論理回路などの１つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造のいずれか、または本明細書で説明する技法の実装に好適な任意の他の構造を指し得る。加えて、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェアモジュール内で与えられてよく、または複合コーデックに組み込まれてよい。また、本技法は、１つまたは複数の回路または論理要素中で完全に実装されてよい。

本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）、またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために、様々なコンポーネント、モジュール、またはユニットが説明されたが、それらのコンポーネント、モジュール、またはユニットを、必ずしも異なるハードウェアユニットによって実現する必要はない。むしろ、上で説明したように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上で説明した１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられてよく、または相互動作するハードウェアユニットの集合によって与えられてよい。

本発明の様々な実施形態が説明されてきた。これらおよび他の実施形態は以下の特許請求の範囲内に入る。

Claims (48)

1. 少なくとも１つのシンクデバイスとの接続をソースデバイスによって確立することであって、前記ソースデバイスおよび前記シンクデバイスが、１つまたは複数のレベルを含む最小認識（ＭＣ）モードをサポートする、確立することと、
   前記ソースデバイスによって、前記ＭＣモードの前記レベルの１つを示す信号を前記シンクデバイスから受信することであって、前記ＭＣモードの前記示されたレベルが、前記シンクデバイスのホストシステムから検出されたトリガ情報に基づいて前記シンクデバイスにおいてアクティブ化される、受信することと、
   前記ソースデバイスにおいて前記ＭＣモードの前記示されたレベルをアクティブ化することと、
   前記ＭＣモードの前記アクティブ化されたレベルに対する前記ソースデバイスの修正された動作に従って、メディアデータを前記シンクデバイスに送信することとを備える、方法。
2. 前記シンクデバイスが前記ＭＣモードをサポートするかどうかを判定することと、
   前記シンクデバイスが前記ＭＣモードをサポートする場合、前記ＭＣモードが有効であることを示す信号を前記シンクデバイスに送信することとをさらに備える、請求項１に記載の方法。
3. 前記シンクデバイスが前記ＭＣモードをサポートしない場合、前記ＭＣモードが有効ではないことを示す信号を前記シンクデバイスに送信することと、
   前記ソースデバイスの通常の動作に従って、メディアデータを前記シンクデバイスに送信することとをさらに備える、請求項２に記載の方法。
4. 前記ＭＣモードの前記示されたレベルをアクティブ化することがさらに、前記ＭＣモードの前記アクティブ化されたレベルに対して設定される規則に基づいて、前記ソースデバイスの動作を修正することを備える、請求項１に記載の方法。
5. 前記ＭＣモードの前記示されるレベルをアクティブ化することがさらに、電話アプリケーション、テキストメッセージングアプリケーション、および前記ソースデバイスにおけるメディアデータのレンダリングのうちの１つまたは複数の動作を修正することを備える、請求項１に記載の方法。
6. 前記ＭＣモードの前記示されたレベルに対する前記トリガ情報が、前記ホストシステムからの前記シンクデバイスによって検出される、環境条件、ユーザの挙動、およびユーザ入力のうちの１つまたは複数を含む、請求項１に記載の方法。
7. 前記ＭＣモードの前記レベルの１つを示す前記信号を前記シンクデバイスから受信することが、前記シンクデバイスにおける前記ＭＣモードの前記アクティブ化されたレベルを示すように定義されるパラメータを伴う、リアルタイムストリーミングプロトコル（ＲＴＳＰ）制御メッセージを受信することを備える、請求項１に記載の方法。
8. 前記ＭＣモードの前記レベルの１つを示す前記信号を前記シンクデバイスから受信することが、前記シンクデバイスにおける前記ＭＣモードの前記アクティブ化されたレベルを示すように定義される入力カテゴリーに対する、ユーザ対話バックチャンネル（ＵＩＢＣ）パケットを受信することを備える、請求項１に記載の方法。
9. 前記ソースデバイスがワイヤレス通信デバイスを備え、前記シンクデバイスが自動車ホストシステム内のメディアヘッドユニットを備える、請求項１に記載の方法。
10. ソースデバイスとの接続をシンクデバイスによって確立することであって、前記ソースデバイスおよび前記シンクデバイスが、１つまたは複数のレベルを含む最小認識（ＭＣ）モードをサポートする、確立することと、
    前記シンクデバイスのホストシステムから検出されたトリガ情報に基づいて、前記シンクデバイスにおける前記ＭＣモードの前記レベルの１つをアクティブ化することと、
    前記シンクデバイスにおける前記ＭＣモードの前記アクティブ化されたレベルを示す信号を前記ソースデバイスに送信することと、
    前記ＭＣモードの前記アクティブ化されたレベルに対する前記ソースデバイスの修正された動作に従って、メディアデータを前記シンクデバイスにおいて受信することとを備える、方法。
11. 前記シンクデバイスが前記ＭＣモードをサポートするかどうかの指示に対する要求を前記ソースデバイスから受信することと、
    前記シンクデバイスが前記ＭＣモードをサポートする場合、前記シンクデバイスが前記ＭＣモードをサポートすることを示す応答を前記ソースデバイスに送信することと、
    前記ＭＣモードが有効であることを示す信号を前記ソースデバイスから受信することとをさらに備える、請求項１０に記載の方法。
12. 前記シンクデバイスが前記ＭＣモードをサポートしない場合、前記シンクデバイスが前記ＭＣモードをサポートしないことを示す応答を前記ソースデバイスに送信することと、
    前記ＭＣモードが有効ではないことを示す信号を前記ソースデバイスから受信することと、
    前記ソースデバイスの通常の動作に従って、メディアデータを前記ソースデバイスから受信することとをさらに備える、請求項１１に記載の方法。
13. 前記ＭＣモードの前記レベルの１つをアクティブ化することがさらに、前記ＭＣモードの前記アクティブ化されたレベルに対して設定される規則に基づいて、前記シンクデバイスの動作を修正することを備える、請求項１０に記載の方法。
14. 前記ＭＣモードの前記レベルの１つをアクティブ化することがさらに、前記シンクデバイスにおけるユーザ入力インターフェースの動作を修正することを備える、請求項１０に記載の方法。
15. 前記シンクデバイスの前記ホストシステム内の１つまたは複数のセンサから前記トリガ情報を検出することをさらに備え、前記ＭＣモードの前記アクティブ化されたレベルに対する前記トリガ情報が、環境条件、ユーザの挙動、およびユーザ入力の１つまたは複数を含む、請求項１０に記載の方法。
16. 前記ＭＣモードの前記アクティブ化されたレベルを示す前記信号を前記ソースデバイスに送信することが、前記シンクデバイスにおける前記ＭＣモードの前記アクティブ化されたレベルを示すように定義されるパラメータを伴う、リアルタイムストリーミングプロトコル（ＲＴＳＰ）制御メッセージを送信することを備える、請求項１０に記載の方法。
17. 前記ＭＣモードの前記アクティブ化されたレベルを示す前記信号を前記ソースデバイスに送信することが、前記シンクデバイスにおける前記ＭＣモードの前記アクティブ化されたレベルを示すように定義される入力カテゴリーに対する、ユーザ対話バックチャンネル（ＵＩＢＣ）パケットを送信することを備える、請求項１０に記載の方法。
18. 前記シンクデバイスが自動車ホストシステム内のメディアヘッドユニットを備え、前記ソースデバイスがワイヤレス通信デバイスを備える、請求項１０に記載の方法。
19. メディアデータを記憶するメモリと、
    プロセッサとを備え、前記プロセッサが、少なくとも１つのシンクデバイスとの接続を確立することであって、ソースデバイスおよび前記シンクデバイスが１つまたは複数のレベルを含む最小認識（ＭＣ）モードをサポートする、確立することと、前記ＭＣモードの前記レベルの１つを示す信号を前記シンクデバイスから受信することであって、前記ＭＣモードの前記示されるレベルが、前記シンクデバイスのホストシステムから検出されたトリガ情報に基づいて前記シンクデバイスにおいてアクティブ化される、受信することと、前記ソースデバイスにおいて前記ＭＣモードの前記示されたレベルをアクティブ化することと、前記ＭＣモードの前記アクティブ化されたレベルに対する前記ソースデバイスの修正された動作に従って、前記シンクデバイスにメディアデータを送信することとを行うように構成される、ソースデバイス。
20. 前記プロセッサが、前記シンクデバイスが前記ＭＣモードをサポートするかどうかを判定し、前記シンクデバイスが前記ＭＣモードをサポートする場合、前記プロセッサが、前記ＭＣモードが有効であることを示す信号を前記シンクデバイスに送信する、請求項１９に記載のソースデバイス。
21. 前記シンクデバイスが前記ＭＣモードをサポートしない場合、前記プロセッサが、前記ＭＣモードが有効ではないことを示す信号を前記シンクデバイスに送信し、前記ソースデバイスの通常の動作に従って、メディアデータを前記シンクデバイスに送信する、請求項２０に記載のソースデバイス。
22. 前記プロセッサが、前記ＭＣモードの前記アクティブ化されたレベルに対して設定される規則に基づいて、前記ソースデバイスの動作を修正する、請求項１９に記載のソースデバイス。
23. 前記プロセッサが、電話アプリケーション、テキストメッセージングアプリケーション、および前記ソースデバイスにおけるメディアデータのレンダリングのうちの１つまたは複数の動作を修正する、請求項１９に記載のソースデバイス。
24. 前記ＭＣモードの前記示されたレベルに対する前記トリガ情報が、前記ホストシステムからの前記シンクデバイスによって検出される、環境条件、ユーザの挙動、およびユーザ入力のうちの１つまたは複数を含む、請求項１９に記載のソースデバイス。
25. 前記プロセッサが、前記シンクデバイスにおける前記ＭＣモードの前記アクティブ化されたレベルを示すように定義されるパラメータを伴う、リアルタイムストリーミングプロトコル（ＲＴＳＰ）制御メッセージを受信する、請求項１９に記載のソースデバイス。
26. 前記プロセッサが、前記シンクデバイスにおける前記ＭＣモードの前記アクティブ化されたレベルを示すように定義される入力カテゴリーに対する、ユーザ対話バックチャンネル（ＵＩＢＣ）パケットを受信する、請求項１９に記載のソースデバイス。
27. 前記ソースデバイスがワイヤレス通信デバイスを備え、前記シンクデバイスが自動車ホストシステム内のメディアヘッドユニットを備える、請求項１９に記載のソースデバイス。
28. メディアデータを記憶するメモリと、
    プロセッサとを備え、前記プロセッサが、ソースデバイスとの接続を確立することであって、前記ソースデバイスおよびシンクデバイスが１つまたは複数のレベルを含む最小認識（ＭＣ）モードをサポートする、確立することと、前記シンクデバイスのホストシステムから検出されたトリガ情報に基づいて、前記シンクデバイスにおける前記ＭＣモードの前記レベルの１つをアクティブ化することと、前記シンクデバイスにおける前記ＭＣモードの前記アクティブ化されたレベルを示す信号を前記ソースデバイスに送信することと、前記ＭＣモードの前記アクティブ化されたレベルに対する前記ソースデバイスの修正された動作に従って、前記シンクデバイスにおいてメディアデータを受信することとを行うように構成される、シンクデバイス。
29. 前記プロセッサが、前記シンクデバイスが前記ＭＣモードをサポートするかどうかの指示に対する要求を前記ソースデバイスから受信し、前記シンクデバイスが前記ＭＣモードをサポートする場合、前記プロセッサが、前記シンクデバイスが前記ＭＣモードをサポートすることを示す応答を前記ソースデバイスに送信し、前記ＭＣモードが有効であることを示す信号を前記ソースデバイスから受信する、請求項２８に記載のシンクデバイス。
30. 前記シンクデバイスが前記ＭＣモードをサポートしない場合、前記プロセッサが、前記シンクデバイスが前記ＭＣモードをサポートしないことを示す応答を前記ソースデバイスに送信し、前記ＭＣモードが有効ではないことを示す信号を前記ソースデバイスから受信し、前記ソースデバイスの通常の動作に従って、メディアデータを前記ソースデバイスから受信する、請求項２９に記載のシンクデバイス。
31. 前記プロセッサが、前記ＭＣモードの前記アクティブ化されたレベルに対して設定される規則に基づいて、前記シンクデバイスの動作を修正する、請求項２８に記載のシンクデバイス。
32. 前記プロセッサが、前記シンクデバイスにおけるユーザ入力インターフェースの動作を修正する、請求項２８に記載のシンクデバイス。
33. 前記プロセッサが、前記シンクデバイスの前記ホストシステム内の１つまたは複数のセンサから前記トリガ情報を検出し、前記ＭＣモードの前記アクティブ化されたレベルに対する前記トリガ情報が、環境条件、ユーザの挙動、およびユーザ入力の１つまたは複数を含む、請求項２８に記載のシンクデバイス。
34. 前記プロセッサが、前記シンクデバイスにおける前記ＭＣモードの前記アクティブ化されたレベルを示すように定義されるパラメータを伴う、リアルタイムストリーミングプロトコル（ＲＴＳＰ）制御メッセージを前記ソースデバイスに送信する、請求項２８に記載のシンクデバイス。
35. 前記プロセッサが、前記シンクデバイスにおける前記ＭＣモードの前記アクティブ化されたレベルを示すように定義される入力カテゴリーに対する、ユーザ対話バックチャンネル（ＵＩＢＣ）パケットを前記ソースデバイスに送信する、請求項２８に記載のシンクデバイス。
36. 前記シンクデバイスが自動車ホストシステム内のメディアヘッドユニットを備え、前記ソースデバイスがワイヤレス通信デバイスを備える、請求項２８に記載のシンクデバイス。
37. 少なくとも１つのシンクデバイスとの接続を確立するための手段であって、ソースデバイスおよび前記シンクデバイスが、１つまたは複数のレベルを含む最小認識（ＭＣ）モードをサポートする、手段と、
    前記ＭＣモードの前記レベルの１つを示す信号を前記シンクデバイスから受信するための手段であって、前記ＭＣモードの前記示されたレベルが、前記シンクデバイスのホストシステムから検出されたトリガ情報に基づいて前記シンクデバイスにおいてアクティブ化される、手段と、
    前記ソースデバイスにおいて前記ＭＣモードの前記示されたレベルをアクティブ化するための手段と、
    前記ＭＣモードの前記アクティブ化されたレベルに対する前記ソースデバイスの修正された動作に従って、メディアデータを前記シンクデバイスに送信するための手段とを備える、ソースデバイス。
38. 前記シンクデバイスが前記ＭＣモードをサポートするかどうかを判定するための手段と、
    前記シンクデバイスが前記ＭＣモードをサポートする場合、前記ＭＣモードが有効であることを示す信号を前記シンクデバイスに送信するための手段とをさらに備える、請求項３７に記載のソースデバイス。
39. 前記ＭＣモードの前記アクティブ化されたレベルに対して設定される規則に基づいて、前記ソースデバイスの動作を修正するための手段をさらに備える、請求項３７に記載のソースデバイス。
40. 電話アプリケーション、テキストメッセージングアプリケーション、および前記ソースデバイスにおけるメディアデータのレンダリングのうちの１つまたは複数の動作を修正するための手段をさらに備える、請求項３７に記載のソースデバイス。
41. 前記ＭＣモードの前記示されたレベルに対する前記トリガ情報が、前記ホストシステムからの前記シンクデバイスによって検出される、環境条件、ユーザの挙動、およびユーザ入力のうちの１つまたは複数を含む、請求項３７に記載のソースデバイス。
42. ソースデバイスとの接続を確立するための手段であって、前記ソースデバイスおよびシンクデバイスが、１つまたは複数のレベルを含む最小認識（ＭＣ）モードをサポートする、手段と、
    前記シンクデバイスのホストシステムから検出されたトリガ情報に基づいて、前記シンクデバイスにおける前記ＭＣモードの前記レベルの１つをアクティブ化するための手段と、
    前記シンクデバイスにおける前記ＭＣモードの前記アクティブ化されたレベルを示す信号を前記ソースデバイスに送信するための手段と、
    前記ＭＣモードの前記アクティブ化されたレベルに対する前記ソースデバイスの修正された動作に従って、メディアデータを前記シンクデバイスにおいて受信するための手段とを備える、シンクデバイス。
43. 前記シンクデバイスが前記ＭＣモードをサポートするかどうかの指示に対する要求を前記ソースデバイスから受信するための手段と、
    前記シンクデバイスが前記ＭＣモードをサポートする場合、前記シンクデバイスが前記ＭＣモードをサポートすることを示す応答を前記ソースデバイスに送信するための手段と、
    前記ＭＣモードが有効であることを示す信号を前記ソースデバイスから受信するための手段とをさらに備える、請求項４２に記載のシンクデバイス。
44. 前記ＭＣモードの前記アクティブ化されたレベルに対して設定される規則に基づいて、前記シンクデバイスの動作を修正するための手段をさらに備える、請求項４２に記載のシンクデバイス。
45. 前記シンクデバイスにおけるユーザ入力インターフェースの動作を修正するための手段をさらに備える、請求項４２に記載のシンクデバイス。
46. 前記シンクデバイスの前記ホストシステム内の１つまたは複数のセンサから前記トリガ情報を検出するための手段をさらに備え、前記ＭＣモードの前記アクティブ化されたレベルに対する前記トリガ情報が、環境条件、ユーザの挙動、およびユーザ入力の１つまたは複数を含む、請求項４２に記載のシンクデバイス。
47. ソースデバイスにおいて実行されると、プログラマブルプロセッサに、
    少なくとも１つのシンクデバイスとの接続を確立することであって、前記ソースデバイスおよび前記シンクデバイスが、１つまたは複数のレベルを含む最小認識（ＭＣ）モードをサポートする、確立することと、
    前記ＭＣモードの前記レベルの１つを示す信号を前記シンクデバイスから受信することであって、前記ＭＣモードの前記示されたレベルが、前記シンクデバイスのホストシステムから検出されたトリガ情報に基づいて前記シンクデバイスにおいてアクティブ化される、受信することと、
    前記ソースデバイスにおいて前記ＭＣモードの前記示されたレベルをアクティブ化することと、
    前記ＭＣモードの前記アクティブ化されたレベルに対する前記ソースデバイスの修正された動作に従って、メディアデータを前記シンクデバイスに送信することとを行わせる、命令を備えるコンピュータ可読媒体。
48. シンクデバイスにおいて実行されると、プログラマブルプロセッサに、
    ソースデバイスとの接続を確立することであって、前記ソースデバイスおよび前記シンクデバイスが、１つまたは複数のレベルを含む最小認識（ＭＣ）モードをサポートする、確立することと、
    前記シンクデバイスのホストシステムから検出されたトリガ情報に基づいて、前記シンクデバイスにおける前記ＭＣモードの前記レベルの１つをアクティブ化することと、
    前記シンクデバイスにおける前記ＭＣモードの前記アクティブ化されたレベルを示す信号を前記ソースデバイスへ送信することと、
    前記ＭＣモードの前記アクティブ化されたレベルに対する前記ソースデバイスの修正された動作に従って、メディアデータを前記ソースデバイスから受信することとを行わせる、命令を備えるコンピュータ可読媒体。

Images