WO2016121412A1

WO2016121412A1 - 情報処理装置

Info

Publication number: WO2016121412A1
Application number: PCT/JP2016/050079
Authority: WO
Inventors: 英輝石見; 山浦　智也; 鈴木　英之; 武敏山根
Original assignee: ソニー株式会社
Priority date: 2015-01-30
Filing date: 2016-01-05
Publication date: 2016-08-04
Also published as: EP3253066A1; US20180004383A1; EP3253066B1; EP3253066A4; US11068148B2

Abstract

　操作者の身体の障がい又は機能の低下に対応した閲覧を保証するアクセシビリティー・モードで動作可能な情報処理装置を提供する。　ソース機器は各シンク機器を接続時にアクセシビリティー・モードかどうかを確認し、アクセシビリティー・モードのシンク機器に対して、本来の画像・音声データの伝送の際に、障がいをサポートするメタデータ（例えば、音声、映像、テキスト、バイブレーション情報など）を加えるかどうかを判断する。ソース機器は、各々のシンク機器のアクセシビリティー・モードがオン又はオフかによって、メタデータの伝送方法を変更する。

Description

情報処理装置

　本明細書で開示する技術は、操作者の身体の障がい又は機能の低下に対応した閲覧を保証するアクセシビリティー・モードで動作可能な情報処理装置、並びに、アクセシビリティー・モードで相手端末とデータを送受信する情報処理装置に関する。

　障がい者や高齢者など、視力や聴力などが制限され、あるいは目と手の協調や手指が器用でない操作者による操作性を考慮した情報処理装置について検討がなされている。例えば、スマートフォンやタブレット端末などの情報機器で、健常者向けと障がい者向けのユーザー・インターフェースを選択できる機種が存在している（例えば、特許文献１を参照のこと）。

　しかしながら、スマートフォンやタブレット端末、ノートブックＰＣといった情報機器からの映像を伝送するさまざまな通信方式では、健常者向けの表示や操作のみの伝送方法が規定され、障がい者のアクセシビリティーが考慮されていないのが現状である。最近では、無線ネットワーク通信やＰ２Ｐ（Ｐｅｅｒ　ｔｏ　Ｐｅｅｒ）ダイレクト通信において、複数の端末がグループ化して無線映像伝送を行なうユースケースが増えてきているが（例えば、特許文献２を参照のこと）、障がい者向けの操作に対応したプロトコルが存在しないのが現状である。

　一方、送信機器と受信機器とのやりとりに関し、伝送可能な通信方式を決めたとしても、複数端末がグループ化し、共通のサービスを実現する場合に、マルチシンク・トポロジー又はマルチソース・トポロジー環境において、新たな課題が発生する。

　例えば、マルチシンク・トポロジー環境での接続形態を考える場合、コンテンツ・データを持つ送信装置はすべてのシンク機器との接続を行ない、最適なデータを受信装置に伝送することが望ましい。しかし、健常者と障がい者が混在する環境において、どのようにして、ソース機器とシンク機器が接続制御し、混在環境での整合性を確保するかという新たな課題がある。

　さらに、マルチソース・トポロジー環境での接続形態を考える場合、シンク機器が１台のプラットフォームであるため、各ソース機器からの受信データは同一フォーマットであることが望ましいが、伝送前に設定値を確認する必要がある。シンク機器にとって効果的な管理方法を提供する必要がある。

　また、ユーザー・インターフェースは健常者向けと障がい者向けでは全く異なっているが、Ｐ２Ｐ（Ｐｅｅｒ　ｔｏ　Ｐｅｅｒ）で接続する端末が健常者向けのモード（以下、「通常モード」とする）と障がい者向けのモード（以下、「アクセシビリティー・モード」とする）が接続する場合、本出願時点では十分な考慮がなされていない。

　また、従来の無線映像伝送規格（例えば、Ｍｉｒａｃａｓｔ）での通信において、コンテンツ・メディア用伝送回線を使用してアクセシビリティー・モード用データを伝送しようとすると、制御方法が独自になり、端末間の互換性がない。例えば、視覚障がい者のサポートにおいて、視覚サポートを行ないながら無線映像伝送を行なうケースを考える。送信機器又は受信機器は、コンテンツ・メディアが映像の場合、例えば、音声又は触覚による情報提供方法へ変換する必要がある。さらに、コンテンツ・メディアに音声がある場合には、操作用音声データが必要な場合もある。しかし、本出願時点では独自実装による実現方法となってしまい、上記アクセシビリティーの種別を考慮した伝送を行なうことができない。送信機器と受信機器でやりとり可能な伝送制御が必要となる。

　加えて、障がいの種別が同じであっても、操作者が持つ障がいの度合いなどに応じて、障がいをサポートする対応方法が異なる。例えば、視覚障がい者が、例えば「視力なしで操作可能」、「色弱、色盲で操作可能」、「弱視かつ難聴で操作可能」というように、視覚サポートにも対応方法がさまざまである。

特開２０１２－２２６７５４号公報米国特許出願公開２０１３０１３９２１０号明細書

　本明細書で開示する技術の目的は、通常モードとアクセシビリティー・モードの端末が混在するトポロジー環境において、アクセシビリティー・モードで好適に動作することができる、優れた情報処理装置を提供することにある。

　本明細書で開示する技術のさらなる目的は、アクセシビリティー・モードで相手端末と好適にデータを送受信することができる、優れた情報処理装置を提供することにある。

　本明細書で開示する技術は、上記課題を参酌してなされたものであり、その第１の側面は、
　複数のシンク機器との間でソース機器として無線通信する無線通信部と、
　前記シンク機器との接続並びに前記シンク機器へのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記複数のシンク機器はそれぞれ、通常モードと、操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、前記複数のシンク機器のアクセシビリティー・モードの種別を管理する、
情報処理装置である。

　本明細書で開示する技術の第２の側面によれば、第１の側面に係る情報処理装置の前記制御部は、前記複数のシンク機器のアクセシビリティー・モードの調停を行なってから、コンテンツ・データの伝送を開始させように構成されている。

　本明細書で開示する技術の第３の側面によれば、第２の側面に係る情報処理装置の前記制御部は、アクセシビリティー・モードへ変更するシンク機器に対し、操作者へ変更が問題ないかを確認するポップアップを表示させるように構成されている。

　本明細書で開示する技術の第４の側面によれば、第１の側面に係る情報処理装置の前記制御部は、アクセシビリティー・モードのシンク機器と接続することを把握し、これから接続するアクセシビリティー・モード種別の論理和をとった結果に基づいて、必要なアクセシビリティー・モード用メタデータを送信させるように構成されている。

　本明細書で開示する技術の第５の側面によれば、第４の側面に係る情報処理装置の前記制御部は、アクセシビリティー・モード用メタデータをマルチキャスト・パケット又はユニキャスト・パケットのうちいずれかで送信させるように構成されている。

　本明細書で開示する技術の第６の側面によれば、第１の側面に係る情報処理装置の前記制御部は、前記複数のシンク機器を同じアクセシビリティー・モード種別毎にグループ化して、グループ毎に対応したアクセシビリティー・モード用メタデータを送信させるように構成されている。

　本明細書で開示する技術の第７の側面によれば、第６の側面に係る情報処理装置の前記制御部は、アクセシビリティー・モード用メタデータをマルチキャスト・パケット又はユニキャスト・パケットのうちいずれかで送信させるように構成されている。

　また、本明細書で開示する技術の第８の側面は、
　ソース機器との間でシンク機器として無線通信する無線通信部と、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記制御部は、前記ソース機器から受信した複数のアクセシビリティー・モード用メタデータのうち再生可能なメタデータのみを抽出して再生処理する、
情報処理装置である。

　また、本明細書で開示する技術の第９の側面は、
　他のソース機器とともに同じシンク機器に対してソース機器として無線通信する無線通信部と、
　前記シンク機器との接続並びに前記シンク機器へのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記シンク機器は通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、アクセシビリティー・モードで接続することを前記シンク機器に通知させる、
情報処理装置である。

　また、本明細書で開示する技術の第１０の側面は、
　複数のソース機器との間でシンク機器として無線通信する無線通信部と、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御部と、
　アクセシビリティー向けの操作と通常向けの操作のいずれかを選択するユーザー・インターフェース部と、
を具備する情報処理装置である。

　また、本明細書で開示する技術の第１１の側面は、
　複数のソース機器との間でシンク機器として無線通信する無線通信部と、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記複数のソース機器はそれぞれ、通常モードと、操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、前記複数のソース機器へＵＩＢＣデータを送信させる、
情報処理装置である。

　本明細書で開示する技術の第１２の側面によれば、第１１の側面に係る情報処理装置の前記制御部は、ソース機器毎のモードに合うようにＵＩＢＣデータを変換した後に送信させるように構成されている。

　本明細書で開示する技術の第１３の側面によれば、第１１の側面に係る情報処理装置の前記制御部は、ソース機器のモードに拘わらずＵＩＢＣデータを送信させるように構成されている。

　本明細書で開示する技術の第１４の側面によれば、第１１の側面に係る情報処理装置の前記制御部は、すべての機器が切り替え可能な共通のモードに切り替えた後にＵＩＢＣデータを送信させるように構成されている。

　また、本明細書で開示する技術の第１５の側面は、
　他のソース機器とともに同じシンク機器に対してソース機器として無線通信する無線通信部と、
　前記シンク機器との接続並びに前記シンク機器へのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記シンク機器は通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、操作者が接続中にシンク機器のモードを変更した場合、通常モードとアクセシビリティー・モードを途中で変更するモード・エックスチェンジ用メッセージ信号を伝送途中で送信させる、
情報処理装置である。

　また、本明細書で開示する技術の第１６の側面は、
　複数のソース機器との間でシンク機器として無線通信する無線通信部と、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記複数のソース機器はそれぞれ、通常モードと、操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、前記複数のソース機器のアクセシビリティー・モードを一致するよう、各ソース機器へ要求させる、
情報処理装置である。

　また、本明細書で開示する技術の第１７の側面は、
　通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能なシンク機器と、ソース機器として無線通信する無線通信部と、
　コンテンツ・データを前記シンク機器に前記無線通信部を介して送信するコンテンツ送信部と、
　アクセシビリティー・モードで動作する前記シンク機器に、前記シンク機器の操作者において操作可能なメタデータを、前記無線通信部を介して送信するメタデータ送信部と、
を具備する情報処理装置である。

　本明細書で開示する技術の第１８の側面によれば、第１７の側面に係る情報処理装置の前記メタデータ送信部は、メタデータ送信用のチャネルを用いてメタデータの送信を行なうように構成されている。

　また、本明細書で開示する技術の第１９の側面は、
　通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能なシンク機器と、ソース機器として無線通信する無線通信部と、
　コンテンツ・データを前記シンク機器に前記無線通信部を介して送信するコンテンツ送信部と、
　前記シンク機器の動作モードを、前記無線通信部を介して確認するモード確認部と、
　アクセシビリティー・モードで動作する前記シンク機器に、前記シンク機器の操作者において操作可能なメタデータを、前記無線通信部を介して送信するメタデータ送信部と、
を具備する情報処理装置である。

　本明細書で開示する技術の第２０の側面によれば、第１９の側面に係る情報処理装置の前記モード確認部は、ＭｉｒａｃａｓｔプロトコルにおけるＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ、Ｄｅｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙ、又は、Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙのうちいずれか１つ以上の処理を用いて前記シンク機器が対応しているアクセシビリティー・モード種別を確認するように構成されている。

　本明細書で開示する技術の第２１の側面によれば、第１９又は第２０のいずれかの側面に係る情報処理装置は、前記シンク機器がサポートするアクセシビリティー・モード種別に応じてメタデータを変換するメタデータ変換部をさらに備えている。

　本明細書で開示する技術の第２２の側面によれば、第１９乃至第２１のいずれかの側面に係る情報処理装置は、前記シンク機器がアクセシビリティー・モードの場合に、メタデータを生成する必要があることを前記情報処理装置の操作者に通知する通知部をさらに備えている。

　本明細書で開示する技術の第２３の側面によれば、第２２の側面に係る情報処理装置の前記通知部は、前記シンク機器へ送信するメタデータのメディア種別を表示し、メタデータを変換してもよいかどうかを操作者に確認を促すように構成されている。

　本明細書で開示する技術の第２４の側面によれば、第１９乃至第２３のいずれかの側面に係る情報処理装置は、前記シンク機器とアクセシビリティー・モードの種別が異なる場合に前記シンク機器とモードを一致させるモード制御部をさらに備えている。

　本明細書で開示する技術の第２５の側面によれば、第１９乃至第２４のいずれかの側面に係る情報処理装置は、操作者が前記シンク機器と接続中にモードを変更した場合、通常モードとアクセシビリティー・モードを途中で変更するモード・エックスチェンジ用メッセージ信号を前記コンテンツ送信部によるコンテンツの伝送途中で送信させるメッセージ送信部をさらに備えている。

　本明細書で開示する技術によれば、通常モードとアクセシビリティー・モードの端末が混在するトポロジー環境において、アクセシビリティー・モードで好適に動作することができる、優れた情報処理装置を提供することができる。

　また、本明細書で開示する技術によれば、アクセシビリティー・モードで相手端末と好適にデータを送受信することができる、優れた情報処理装置を提供することができる。

　なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。

　本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

図１は、本明細書で開示する技術の第１の実施形態に係る通信システム１００の構成例を模式的に示した図である。図２は、ソース機器として動作する情報処理装置２００の機能的構成例を模式的に示した図である。図３は、シンク機器として動作する情報処理装置３００の機能的構成例を模式的に示した図である。図４は、第１の実施形態におけるソース機器４１０とシンク機器４２０間の接続シーケンス例を示した図である。図５Ａは、ソース機器とシンク機器がともにアクセシビリティー・モードでやりとりする接続形態を例示した図である。図５Ｂは、通常モードのソース機器とアクセシビリティー・モードのシンク機器がやりとりする接続形態を例示した図である。図６は、図５Ａに示したトポロジー環境におけるソース機器と各シンク機器間の接続シーケンス例を示した図である。図７は、第１の実施形態におけるソース機器４１０とシンク機器４２０間の接続シーケンス例（Ｍｉｒａｃａｓｔでの処理を用いた例）を示した図である。図８は、障がいの種別と対応要求、及び各々の対応例を示した図である。図９は、アクセシビリティー対応要求のビット・アサインを示した図である。図１０Ａは、ソース機器とシンク機器間でＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ通信処理を行なうシーケンス例（ソース機器からアクセシビリティー機能要求する通信例）を示した図である。図１０Ｂは、ソース機器とシンク機器間でＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ通信処理を行なうシーケンス例（ソース機器から接続Ｅｎａｂｌｅ要求する通信例）を示した図である。図１１Ａは、ソース機器とシンク機器間でＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ通信処理を行なうシーケンス例（シンク機器からアクセシビリティー機能要求する通信例）を示した図である。図１１Ｂは、ソース機器とシンク機器間でＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ通信処理を行なうシーケンス例（シンク機器から接続Ｅｎａｂｌｅ要求する通信例）を示した図である。図１２は、各アクセシビリティー・モード種別におけるシンク機器の動作例を示した図である。図１３Ａは、ソース機器が複数のシンク機器用アクセシビリティー・モード種別の中から共通するアクセシビリティー・モードを選択するための処理手順を示したフローチャートである。図１３Ｂは、ソース機器が複数のシンク機器用アクセシビリティー・モード種別の中から共通するアクセシビリティー・モードを選択するための処理手順を示したフローチャートである。図１４Ａは、アクセシビリティー・モード及び通常モードのソース機器がともに１台のアクセシビリティー・モードのシンク機器とやりとりする接続形態を例示した図である。図１４Ｂは、通常モード及びアクセシビリティー・モードのソース機器がともに１台の通常モードのシンク機器とやりとりする接続形態を例示した図である。図１５Ａは、ソース機器４１０とシンク機器４２０間のＷｅｂＳｏｃｋｅｔを用いた画像データ及び音声データの通信処理例を示した図である。図１５Ｂは、ソース機器４１０とシンク機器４２０間でやりとりされるＷｅｂＳｏｃｋｅｔのフレーム・フォーマット例を示した図である。図１５Ｃは、ソース機器４１０とシンク機器４２０間でやりとりされるＷｅｂＳｏｃｋｅｔのフレーム・フォーマット例を示した図である。図１６は、本明細書で開示する技術の第２の実施形態に係る通信システム１１００の構成例を模式的に示した図である。図１７は、アクセシビリティー操作とデフォルト操作を指定するボタンを含んだ大画面ディスプレイを例示した図である。図１８は、Ｐ２Ｐダイレクト接続からマルチシンク・トポロジー環境を構築するまでの基本シーケンス例を示した図である。図１９は、本明細書で開示する技術の１つの実施形態に係る通信システムの構成例を模式的に示した図である。図２０は、アクセシビリティー・モードのソース機器とアクセシビリティー・モードのシンク機器の間でやりとりする接続形態を示した図である。図２１は、通常モードのソース機器とアクセシビリティー・モードのシンク機器の間でやりとりする接続形態を示した図である。図２２は、アクセシビリティー・モードのソース機器と通常モードのシンク機器の間でやりとりする接続形態を示した図である。図２３は、ソース機器がアクセシビリティー・モード用メタデータ回線のＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎを開始し、ソース機器がシンク機器と映像伝送を開始するまでの動作手順を示したフローチャートである。図２４は、ソース機器がアクセシビリティー・モード用メタデータ回線のＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎを開始し、ソース機器がシンク機器と映像伝送を開始するまでの動作手順を示したフローチャートである。図２５は、Ｄｅｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙ又はＳｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙの制御方法の一例を示した図である。図２６は、ＷＦＤ　ＩＥのフォーマット例を示した図である。図２７は、ＷＦＤ　Ｓｕｂｅｌｅｍｅｎｔの一般フォーマット例を示した図である。図２８は、ＷＦＤ　Ｓｕｂｅｌｅｍｅｎｔ　ＩＤ　Ｄｅｆｉｎｉｔｉｏｎ例を示した図である。図２９は、Ｎｅｗ　Ｄｅｖｉｃｅ　Ｓｕｂｅｌｅｍｅｎｔ例を示した図である。図３０は、Ｎｅｗ　Ｄｅｖｉｃｅ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｆｉｅｌｄ例を示した図である。図３１は、ＡＳＰメッセージのペイロード例を示した図である。

　以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。

［第１の実施形態］
［通信システム構成］
　図１には、本明細書で開示する技術の第１の実施形態に係る通信システム１００の構成例を模式的に示している。図示の通信システム１００は、Ｐ２Ｐダイレクト通信を用いたマルチシンク・トポロジー環境の無線接続を行なうことを想定している。具体的には、通信システム１００は、３台の情報処理装置２００、３００、４００を含み、ソース機器としての１台の情報処理装置２００から送信されるデータ（例えば、画像データや音声データ）を、他の２台の情報処理装置３００、４００がシンク機器として受信するようになっている。１台のソース機器に対して複数台のシンク機器が存在することから、図１に示す通信システム１００は、マルチシンク・トポロジー環境ということができる。

　通信システム１００を構成する各情報処理装置２００、３００、４００は、無線通信機能を備える通信機器である。例えば、情報処理装置２００、３００、４００は、無線通信機能を備える表示装置（例えば、パーソナル・コンピューター）や携帯型の情報処理装置（スマートフォンやタブレット端末など）である。また、情報処理装置２００、３００、４００は、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ　ｏｆ　Ｅｌｅｃｔｒｉｃａｌ　ａｎｄ　Ｅｌｅｃｔｒｏｎｉｃｓ　Ｅｎｇｉｎｅｅｒｓ）８０２．１１、ＩＥＥＥ８０２．１５、ＩＥＥＥ８０２．１６、３ＧＰＰ（３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）仕様（例えば、Ｗ－ＣＤＭＡ（Ｗｉｄｅｂａｎｄ　Ｃｏｄｅ　Ｄｉｖｉｓｉｏｎ　Ｍｕｌｔｉｐｌｅ　Ａｃｃｅｓｓ）、ＧＳＭ（登録商標）（Ｇｌｏｂａｌ　Ｓｙｓｔｅｍ　ｆｏｒ　Ｍｏｂｉｌｅ　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ　Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ　ｆｏｒ　Ｍｉｃｒｏｗａｖｅ　Ａｃｃｅｓｓ）、ＷｉＭＡＸ２、ＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）、ＬＴＥ－Ａ（Ａｄｖａｎｃｅｄ）に準拠した無線通信装置である。そして、情報処理装置２００、３００、４００はともに、これらのうちいずれかの無線通信機能を利用して、各種情報のやりとりを行なうことができる。

　ここで、シンク機器である情報処理装置３００又は４００は、ソース機器である情報処理装置２００から送信されるデータを受信するという点で、同一の機能的構成を備えた機器である。また、情報処理装置２００と情報処理装置４００とのやりとりは、基本的には情報処理装置２００と情報処理装置３００とのやりとりと同等である。したがって、以下では、情報処理装置２００と情報処理装置３００との接続方法についてのみ第１の実施形態として説明し、情報処理装置２００と情報処理装置４００との接続方法については説明を省略する。なお、情報処理装置２００と情報処理装置３００間で無線ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）を用いた無線通信を行なう場合を例にとって説明する。

　この無線ＬＡＮとして、例えば、Ｗｉ－Ｆｉ（Ｗｉｒｅｌｅｓｓ　Ｆｉｄｅｌｉｔｙ）　Ｄｉｒｅｃｔ、ＴＤＬＳ（Ｔｕｎｎｅｌｅｄ　Ｄｉｒｅｃｔ　Ｌｉｎｋ　Ｓｅｔｕｐ）、アドホック・ネットワーク、メッシュ・ネットワークを用いることができる。また、通信システム１００に用いられる近距離無線ＡＶ（Ａｕｄｉｏ　Ｖｉｓｕａｌ）伝送通信として、例えば、Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔ（技術仕様書名：Ｗｉ－Ｆｉ　Ｄｉｓｐｌａｙ）を用いることができる。なお、Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔは、Ｗｉ－Ｆｉ　ＤｉｒｅｃｔやＴＤＬＳの技術を利用して、一方の端末で再生される音声や表示画像を他の端末に送信し、他の端末でも同様にその音声、画像データを出力させるミラーリング技術である。

　また、Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔでは、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）上でＵＩＢＣ（Ｕｓｅｒ　Ｉｎｐｕｔ　Ｂａｃｋ　Ｃｈａｎｎｅｌ）を実現している。ＵＩＢＣは、一方の端末から他方の端末へマウスやキーボードなどの入力機器の操作情報を送信する技術である。なお、Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔの代わりに、他のリモート・デスクトップ・ソフトウェア（例えば、ＶＮＣ（Ｖｉｒｔｕａｌ　Ｎｅｔｗｏｒｋ　Ｃｏｍｐｕｔｉｎｇ））を適用するようにしてもよい。

　ここで、Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔでは、画像（映像）を、例えば、Ｈ．２６４を用いて圧縮・展開することが定められている。また、例えば、Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔでは、Ｈ．２６４を送信側で調整することができる。なお、Ｈ．２６４に限らず、例えば、Ｈ．２６５（例えば、ＨＥＶＣ（ｈｉｇｈ　ｅｆｆｉｃｉｅｎｃｙ　ｖｉｄｅｏ　ｃｏｄｉｎｇ）、ＳＨＶＣ（ｓｃａｌａｂｌｅ　ｖｉｄｅｏ　ｃｏｄｉｎｇ　ｅｘｔｅｎｓｉｏｎｓ　ｏｆ　ｈｉｇｈ　ｅｆｆｉｃｉｅｎｃｙ　ｖｉｄｅｏ　ｃｏｄｉｎｇ））、ＭＰＥＧ（Ｍｏｖｉｎｇ　Ｐｉｃｔｕｒｅ　Ｅｘｐｅｒｔｓ　Ｇｒｏｕｐ）４、ＪＰＥＧ（Ｊｏｉｎｔ　１Ｐｈｏｔｏｇｒａｐｈｉｃ　Ｅｘｐｅｒｔｓ　Ｇｒｏｕｐ）２０００にも対応することができる。また、例えば、１ライン以上を束ねて圧縮したり、２ライン以上を２×２以上のマクロブロックに分割して圧縮・展開を行なったりするラインベース・コーデック（例えば、Ｗａｖｅｌｅｔ、ＤＣＴ（Ｄｉｓｃｒｅｔｅ　Ｃｏｓｉｎｅ　Ｔｒａｎｓｆｏｒｍ））にも対応することができる。また、例えば、特定の符号量領域（Ｐｉｃｔｕｒｅ又は複数ラインの束又はマクロブロックなど）の前符号量領域との差分を求めることでＤＣＴやＷａｖｅｌｅｔなどの圧縮を行なわずに伝送レートを減らすコーデックにも対応することができる。また、情報処理装置２００と情報処理装置３００間で、非圧縮で画像（映像）を送信・受信するようにしてもよい。

　第１の実施形態に係る通信システム１００では、情報処理装置２００から情報処理装置３００への送信対象とするデータとして、例えば撮像動作により生成された画像データ及び音声データや、ハード・ディスクなどの記憶装置に保存されているコンテンツ（例えば、画像データ及び音声データからなるコンテンツ）などを想定している。データの送信元である情報処理装置２００として、カメラを搭載した電子機器（例えば、パーソナル・コンピューター、ゲーム機、スマートフォン、タブレット端末）を用いるようにしてもよい。また、データの送信先である情報処理装置３００として、表示部を備える他の電子機器（例えば、撮像装置、ゲーム機、スマートフォン、タブレット端末）を用いるようにしてもよい。また、情報処理装置２００がテザリング機能を備える場合には、無線又は有線ネットワークを介してＩＳＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｒｖｉｃｅｓ　Ｐｒｏｖｉｄｅｒ）に保存されたコンテンツを情報処理装置３００への送信対象とするようにしてもよい。

　例えば、情報処理装置２００の撮像動作により生成された画像データが情報処理装置３００に送信され、情報処理装置３００側では受信した画像データに基づく画像が表示部に表示される。

　また、図１では、無線通信を利用して情報処理装置２００がＰ２Ｐダイレクト接続により直接通信することができる範囲すなわち情報伝達範囲を参照番号１０１で示している。この情報伝達範囲１０１は、情報処理装置３００を基準とした場合における情報伝達範囲（サービス範囲）である。

　情報処理装置２００と情報処理装置３００間の動作について詳細に説明する前に、マルチシンク・トポロジーの構築方法について述べておく。

　図１８には、Ｐ２Ｐダイレクト接続からマルチシンク・トポロジー環境を構築するまでの基本シーケンス例を示している。同図では、ソース機器である情報処理装置２００がシンク機器である情報処理装置３００とＰ２Ｐダイレクト通信で接続している環境において、情報処理装置４００がグループ参入してくる動作例を示している。

　情報処理装置２００は、ＧＯ（Ｇｒｏｕｐ　Ｏｗｎｅｒ）として、情報処理装置３００のＰ２Ｐクライアント間と既に接続済である。このため、情報処理装置２００から情報処理装置４００にＩｎｖｉｔａｔｉｏｎ　Ｒｅｑｕｅｓｔ処理を行なう。あるいは、情報処理装置４００から情報処理装置２００にＰｒｏｖｉｓｉｏｎ　Ｄｉｓｃｏｖｅｒｙ処理を行なうようにしてもよい。Ｉｎｖｉｔａｔｉｏｎ　Ｒｅｑｕｅｓｔ処理を例に動作シーケンスを説明すると、情報処理装置４００から情報処理装置２００にＩｎｖｉｔａｔｉｏｎ　Ｒｅｓｐｏｎｓｅ処理を返信する。

　上記処理によって、情報処理装置２００は、情報処理装置４００を新たなＰ２Ｐクライアントとして接続する。そして、お互いにサービス・ディスカバリーを行なうことで、情報処理装置２００をソース機器とし、情報処理装置３００及び情報処理装置４００をシンク機器として、マルチシンク・トポロジーを構築する。

　マルチシンク・トポロジーが構築された後、情報処理装置２００から情報処理装置３００又は情報処理装置４００に送信されて表示されるコンテンツは、同じコンテンツ（画像）でもよく、異なるコンテンツ（画像）でもよい。例えば、情報処理装置３００には、情報処理装置２００に表示された画像をそのまま送信し、情報処理装置４００には、情報処理装置２００の記憶部に保存されているコンテンツを送信することもできる。

［ソース機器の構成］
　図２には、第１の実施形態に係る通信システム１００においてソース機器として動作する情報処理装置２００の機能的構成例を模式的に示している。

　情報処理装置２００は、アンテナ２１０と、無線通信部２２０と、制御信号受信部２３０と、制御部２４０と、画像・音声信号生成部２５０と、画像・音声圧縮部２６０と、ストリーム送信部２７０を備えている。以下、各部について説明する。

　無線通信部２２０は、制御部２４０の制御に基づいて、無線通信を利用して、他の情報処理装置（例えば、情報処理装置３００などのシンク機器）との間で各情報（例えば、画像データ、音声データ、及び制御データ）の送受信を、アンテナ２１０を介して行なう。例えば、他の情報処理装置への画像データの送信処理が行なわれる場合、画像・音声信号生成部２５０により生成された画像データが画像・音声圧縮部２６０により圧縮され、この圧縮された画像データ（画像ストリーム）が無線通信部２２０を経由してアンテナ２１０から送信される。

　また、無線通信部２２０は、複数の周波数チャネルを利用して、他の情報処理装置（例えば、情報処理装置３００）との間で各情報の送受信を行なうことが可能であるものとする。第１の実施形態では、無線通信部２２０が、２．４ＧＨｚ、５ＧＨｚ、６０ＧＨｚの３種類の周波数チャネルを同時又は選択した周波数のみを送受信可能な機能を備える例について説明する。このように、ソース機器が複数の周波数チャネルを送受信可能な機能を備える場合には、シンク機器（例えば、情報処理装置３００）は、各ソース機器にどの周波数チャネルを使用させるかを制御することができる。

　制御信号受信部２３０は、無線通信部２２０により受信された各情報のうちから、他の情報処理装置（例えば、情報処理装置３００）から送信された制御信号（例えば、情報処理装置３００とのやりとりの情報）を取得する。そして、制御信号受信部２３０は、その取得された制御信号を制御部２４０に出力する。

　制御部２４０は、情報処理装置２００から送信される各情報に関する制御を行なう。例えば、制御部２４０は、制御信号受信部２３０により受信された制御信号に基づいて、画像・音声信号生成部２５０及び画像・音声圧縮部２６０に対する制御を行なう。具体的には、制御部２４０は、送信対象となる画像データの解像度や音声のチャネル数を変更させるための制御や、送信対象となる画像データの画像領域を変更させるための制御を行なう。すなわち、制御部２４０は、制御信号受信部２３０により受信された制御信号に基づいて、送信対象となるストリームの伝送制御を行なう。このストリームの伝送制御は、例えば、データ伝送速度制御、スケーラビリティ伝送レート制御である

　また、制御部２４０は、無線通信を利用してシンク機器（例えば、情報処理装置３００）との間でデータの送受信が行なわれている際における電波伝搬状況（リンク電波伝搬状況）を測定する機能を備え、その測定結果（電波伝搬測定情報）を無線通信部２２０からシンク機器に送信するようにしてもよい。

　ここで言う電波伝搬測定情報は、例えば、シンク機器との回線品質が、画像データ及び音声データの送受信を行なうことができる品質であるか否かを判断する際に用いられる情報である。また、電波伝搬測定情報は、例えば、ストリームの伝送制御を行なう際に用いられる。

　また、ここで言うデータ伝送速度は、主に、通信路を占有する率を意味し、通信速度や通信容量の意味を含むものとする。また、解像度は、例えば、画像データの画枠（縦・横のピクセル数）、画像データのビットレート（圧縮率）などの要素から構成される画質の指標と定義する。また、画質の指標としては、ストリームのスループットを用いることができる。また、音声のチャネル数は、モノラル（１．０ｃｈ）、ステレオ（２．０ｃｈ）、５．１ｃｈ、６．１ｃｈ、９．１ｃｈ、ハイレゾリューション・オーディオ（Ｈｉｇｈ－Ｒｅｓｏｌｕｔｉｏｎ　Ａｕｄｉｏ）などの音声の記録再生方法の意味を含むものとする。また、音声のチャネル数は、音声データのビットレート（圧縮率）やチャネル数などの要素から構成される音質の指標と定義する。また、音質の指標としては、ストリームのスループットを用いることができる。

　また、制御部２４０は、データ伝送速度制御では安定化することができない状態を改善させるための制御を行なう。例えば、制御部２４０は、シンク機器（例えば、情報処理装置３００）との情報のやりとりにより、シンク機器のシステム性能情報を把握する。ここで言うシステム性能情報は、例えば、シンク機器のシステムに関する性能情報である。例えば、システム性能情報は、使用可能な周波数チャネル、解像度、伝送制御プロトコル（ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ））である。また、システム性能情報は、例えば、暗号化方法の対応、ＳＤ（Ｓｔａｎｄａｒｄ　Ｄｅｆｉｎｉｔｉｏｎ）／ＨＤ（Ｈｉｇｈ　Ｄｅｆｉｎｉｔｉｏｎ）／４Ｋ対応、低消費電力モードの対応のそれぞれを示す情報である。例えば、制御部２４０は、シンク機器が低消費電力モードに対応しているか否かに応じて、通信システム１００のシステム全体の安定度をさらに向上させるストリームの伝送制御方法を選ぶことができる。

　また、制御部２４０は、シンク機器との情報のやりとりの中に、情報処理装置２００がモバイル機器であるかどうかの情報を入れるものとする。例えば、情報処理装置２００に関するＣａｐａｂｉｌｉｔｙ情報に、情報処理装置２００がモバイル機器であるかどうかの情報を含めることができる。情報処理装置３００などのシンク機器側では、情報処理装置２００がモバイル機器であることを把握すると、他に接続した情報処理装置との関連に基づいて、情報処理装置２００を動作させる必要がないと判断することができる。このように、情報処理装置２００を動作させる必要がないとシンク機器で判断された場合には、情報処理装置２００は、シンク機器から送信停止コマンドを受信する。そして、制御部２４０は、その送信停止コマンドを把握すると、画像・音声信号生成部２５０と、画像・音声圧縮部２６０と、ストリーム送信部２７０とのそれぞれの機能の電源を一定時間ダウンさせることができる。また、制御部２４０は、無線通信部２２０についても間欠受信（シンク機器からコマンドを受信できる程度に定期的に起き上がり、他は電源をダウンさせるモード）に移行することができる。

　画像・音声信号生成部２５０は、制御部２４０の制御に基づいて、出力対象となるデータ（画像データ、音声データ）を生成し、生成されたデータを画像・音声圧縮部２６０に出力する。例えば、画像・音声信号生成部２５０は、撮像部及び音声取得部（いずれも図示しない）を備えている。この撮像部（例えば、レンズ、撮像素子、信号処理回路）は、被写体を撮像して画像（画像データ）を生成する。また、音声取得部（例えば、マイク）は、撮像部による画像データの生成時における周囲の音声を取得する。画像・音声信号生成部２５０で生成されたデータは、他の情報処理装置（例えば、情報処理装置３００などのシンク機器）への送信対象となる。

　画像・音声圧縮部２６０は、制御部２４０の制御に基づいて、画像・音声信号生成部２５０により生成されたデータ（画像データ及び音声データ）を圧縮（エンコード）する。そして、画像・音声圧縮部２６０は、その圧縮されたデータ（画像データおよび音声データ）をストリーム送信部２７０に出力する。なお、画像・音声圧縮部２６０は、ソフトウェアによるエンコードの実行により実現するようにしてもよく、ハードウエアによるエンコードの実行により実現するようにしてもよい。また、画像・音声圧縮部２６０は、コーデックとして機能することを想定しているが、非圧縮の画像又は音声を扱えるものとする。さらに、画像・音声圧縮部２６０は、スケーラブル・コーデックとしても機能するものとする。ここで言うスケーラブル・コーデックは、例えば、受信側の情報処理装置（シンク機器）の解像度やネットワーク環境などに応じて、自在に適応することができるコーデックを意味する。

　ストリーム送信部２７０は、制御部２４０の制御に基づいて、画像・音声圧縮部２６０により圧縮されたデータ（画像データ及び音声データ）を、ストリームとして無線通信部２２０を経由してアンテナ２１０から送信する送信処理を行なう。

　なお、情報処理装置２００は、上述した各部以外にも、表示部、音声出力部、操作受付部などを備えることができるが、これらについては、簡素化のため、図２での図示を省略する。

　情報処理装置２００の表示部（図示しない）は、例えば、画像・音声信号生成部２５０により生成された画像を表示する。表示部として、各種の表示パネルを用いることができる。例えば、有機ＥＬ（Ｅｌｅｃｔｒｏ　Ｌｕｍｉｎｅｓｃｅｎｃｅ）、クリスタルＬＥＤ（Ｌｉｇｈｔ　Ｅｍｉｔｔｉｎｇ　Ｄｉｏｄｅ）ディスプレイ、ＬＣＤ（Ｌｉｑｕｉｄ　Ｃｒｙｓｔａｌ　Ｄｉｓｐｌａｙ）を用いることができる。

　また、情報処理装置２００の音声出力部（図示しない）は、例えばスピーカーであり、画像・音声信号生成部２５０により生成された音声を出力する。なお、画像については、送信機器及び受信機器の双方から出力することもできるが、音声については何れか一方のみから出力することが好ましい。

　また、情報処理装置２００の操作受付部（図示しない）は、例えば、キーボード、マウス、ゲームパッド、タッチパネル、カメラ、マイクで構成され、操作者により行なわれた操作入力を受け付ける。なお、操作受付部と上記の表示部については、操作者がその指を表示面に接触又は近接することにより操作入力を行なうことが可能なタッチパネルを用いて一体で構成することができる。

　また、本明細書では情報処理装置２００が送信対象となる画像データ及び音声データを生成する例について説明するが、情報処理装置２００は、送信対象となる画像データ及び音声データを外部装置から取得するようにしてもよい。例えば、情報処理装置２００は、マイクロフォン付きのＷｅｂカメラから、送信対象となる画像データ及び音声データを取得するようにしてもよい。

　また、情報処理装置２００は、図示しない記憶装置（例えば、ハードディスク）に保存されているコンテンツ（例えば、画像データ及び音声データからなるコンテンツ）を送信対象とするようにしてもよい。記憶装置は、情報処理装置２００の内蔵又は外部接続のいずれであってもよい。この場合に、その記憶装置に保存されているコンテンツが圧縮済みのコンテンツである場合も想定される。その圧縮済みのコンテンツが、通信システム１００で採用されている規格で定義されたエンコード方式で圧縮されている場合には、その圧縮済みのコンテンツを復号（デコード）せずにそのまま送信するようにしてもよい。

［シンク機器の構成］
　図３には、第１の実施形態に係る通信システム１００においてシンク機器として動作する情報処理装置３００の機能的構成例を模式的に示している。他の情報処理装置４００も同様の機能的構成を備えるものと理解されたい。

　情報処理装置３００は、アンテナ３１０と、無線通信部３２０と、ストリーム受信部３３０と、画像・音声展開部３４０と、画像・音声出力部３５０と、ユーザー情報取得部３６０と、制御部３７０と、制御信号送信部３８０と、管理情報保持部３９０を備えている。画像・音声出力部３５０は、表示部３５１及び音声出力部３５２を備えている。以下、各部について説明する。

　無線通信部３２０は、制御部３７０の制御に基づいて、無線通信を利用して、他の情報処理装置（例えば、情報処理装置２００などのソース機器）との間で各情報（例えば、画像データ及び音声データ）の送受信を、アンテナ３１０を介して行なう。例えば、他の情報処理装置からの画像データの受信処理が行なわれる場合、アンテナ３１０により受信された画像データが、無線通信部３２０、ストリーム受信部３３０を経由して画像・音声展開部３４０により展開（復号）される。そして、その展開された画像データが画像・音声出力部３５０に供給され、その展開された画像データに応じた画像が画像・音声出力部３５０から出力される。すなわち、その展開された画像データに応じた画像が表示部３５１に表示される。また、展開された音声データに応じた音声が音声出力部３５２から音声出力される。

　また、無線通信部３２０は、複数の周波数チャネルを利用して、他の情報処理装置（例えば、情報処理装置２００）との間で各情報の送受信を行なうことが可能であるものとする。第１の実施形態では、無線通信部３２０が、２．４ＧＨｚ、５ＧＨｚ、６０ＧＨｚの３種類の周波数チャネルを同時又は選択した周波数のみを送受信可能な機能を備える例について説明する。すなわち、無線通信部３２０は、第１の周波数帯を用いる通信と、第１の周波数帯よりも高速なデータ伝送速度の第２の周波数帯を用いる通信とを行なうことが可能であるとする。また、制御部３７０は、各ソース機器との無線通信に、複数の周波数チャネルのうちのどの周波数チャネルを使用させるかを制御する。

　なお、図１に示した通信システム１００において、情報処理装置２００及び情報処理装置３００間（若しくは、ソース機器とシンク機器間）のリンクと、情報処理装置４００及び情報処理装置３００間（若しくは、シンク機器同士）のリンクとは同一の周波数チャネルとするようにしてもよく、異なる周波数チャネルとするようにしてもよい。

　また、第１の実施形態では、無線通信部３２０が、２．４ＧＨｚ、５ＧＨｚ、６０ＧＨｚの３種類の周波数チャネルを送受信可能な機能を備える例について説明するが、使用する周波数チャネルはこれらに限定されない。例えば、無線通信部３２０が、他の周波数チャネルや、１種類又は２種類の周波数チャネルを送受信可能な機能しか備えていなくてもよい。さらに４種類以上の周波数チャネルを送受信可能な機能を備えるようにしてもよい。

　ストリーム受信部３３０は、制御部３７０の制御に基づいて、無線通信部３２０により受信された各情報のうちから、各ソース機器とのやりとりの情報及びストリーム（例えば、画像ストリーム、音声ストリーム）を受信する。そして、ストリーム受信部３３０は、受信したやりとりの情報を制御部３７０に出力し、受信したストリームを画像・音声展開部３４０及び制御部３７０に出力する。

　ここで言う、各ソース機器とのやりとりの情報は、ソース機器（例えば、情報処理装置２００）から送信される情報であり、例えば、情報処理装置３００のシステム性能情報の取得要求を含む。このシステム性能情報は、例えば、使用可能な周波数チャネル、解像度、ＴＣＰ、ＵＤＰや、暗号化方法の対応、ＳＤ／ＨＤ／４Ｋ対応、低消費電力モードの対応のそれぞれを示す情報である。

　また、ストリーム受信部３３０は、無線通信を利用してソース機器との間でデータの送受信が行なわれている際における電波伝搬状況（リンク電波伝搬状況）を測定する機能を備える。そして、ストリーム受信部３３０は、その測定結果（電波伝搬測定情報）を制御部３７０に出力する。

　画像・音声展開部３４０は、制御部３７０の制御に基づいて、他の情報処理装置（例えば、情報処理装置２００）から送信されたストリーム（画像データ及び音声データ）を展開（デコード）する。そして、画像・音声展開部３４０は、その展開されたデータ（画像データ及び音声データ）を画像・音声出力部３５０に出力する。なお、画像・音声展開部３４０は、ソフトウェアによるデコードの実行により実現するようにしてもよく、ハードウエアによるデコードの実行により実現するようにしてもよい。また、画像・音声展開部３４０は、コーデックとして機能することを想定しているが、非圧縮の画像又は音声を扱えるものとする。また、画像・音声展開部３４０は、スケーラブル・コーデックとしても機能するものとする。

　画像・音声出力部３５０内の表示部３５１は、画像・音声展開部３４０により展開された画像データに基づく各画像を表示する。なお、表示部３５１として、例えば、有機ＥＬパネル、クリスタルＬＥＤディスプレイ、ＬＣＤパネルなどの表示パネルを用いることができる。また、表示部３５１として、操作者がその指を表示面に接触又は近接することにより操作入力が可能なタッチパネルを用いるようにしてもよい。

　また、音声出力部３５２は、例えばスピーカーで構成され、画像・音声展開部３４０により展開された音声データに基づく各種音声（表示部３５１に表示された画像に関する音声など）を出力する。音声の出力方法としては、例えば、中央チャネル（メイン画像）に割り当てられたソース機器の音声のみをスピーカーから再生して周辺チャネル（サブ画像）に割り当てられたソース機器の音声を再生しない方法を用いることができる。また、他の音声の出力方法として、例えば、中央チャネルに割り当てられたソース機器の音声の音量をメインにして、周辺チャネルに割り当てられたソース機器の音声の音量を下げて再生する方法を用いることができる。勿論、これら以外の音声の出力方法を用いるようにしてもよい。

　ユーザー情報取得部３６０は、当該情報処理装置３００の操作者に関する情報（ユーザー情報）を取得し、その取得されたユーザー情報を制御部３７０に出力する。例えば、ユーザー情報取得部３６０は、操作者が表示方法を直接設定することができる操作受付部（キーボード、マウス、リモコン、ゲームパッド、タッチパネル）からの入力を受け付けることにより、ユーザー情報を取得することができる。なお、操作受付部は、例えば、表示部３５１に表示される画像における任意の領域を指定するための操作部材である。また、例えば、ユーザー情報取得部３６０は、カメラ、マイク、各種センサー（例えば、ジャイロセンサー、人体を感知するセンサー）などのように操作者の意図を把握することができるデバイスからの入力を受け付けることによりユーザー情報を取得することができる。

　例えば、ユーザー情報取得部３６０は、無線通信を利用して他の情報処理装置（例えば、情報処理装置２００）から受信したストリームに基づく情報が画像・音声出力部３５０から出力されている際における操作者によるユーザー動作により生じるユーザー情報を取得する。このユーザー情報は、例えば、表示部３５１に表示されている画像に関するユーザー動作により生じるユーザー情報である。例えば、ユーザー情報は、表示部３５１に表示されている画像に関するユーザー操作に基づいて生成される情報である。

　また、ユーザー情報取得部３６０は、表示部に付属する撮像部（図示しない）により生成された画像データを取得してユーザー情報を生成することができる。また、ユーザー情報取得部３６０は、例えば外部装置（例えば、各センサーやウェアラブル・デバイス）により取得される情報（例えば、位置情報、識別情報）を取得してユーザー情報を生成するようにしてもよい。

　制御部３７０は、ストリーム受信部３３０により取得された各情報を管理情報保持部３９０に保持させ、管理情報保持部３９０に保持されている管理情報に基づいてソース機器を管理する。また、制御部３７０は、マルチソース・トポロジー環境においては、複数のソース機器から送信されるストリームをシステム全体で安定度が向上するようにストリームの伝送制御を行なう。

　例えば、制御部３７０は、ユーザー情報取得部３６０により取得されたユーザー情報と、管理情報保持部３９０に保持されている管理情報とに基づいてストリームの伝送制御を行なう。具体的には、制御部３７０は、管理情報保持部３９０に保持されている管理情報に基づいて、ストリームの伝送制御を行なうための制御信号をソース機器毎に生成する。そして、制御部３７０は、その生成された制御信号を制御信号送信部３８０に出力する。例えば、制御部３７０は、ユーザー情報及び管理情報に基づいて、表示部３５１に表示される画像の解像度を変更し、この解像度と同等の送信レートを各ソース機器に要求するための制御信号を生成する。また、例えば、制御部３７０は、ユーザー情報及び管理情報に基づいて、表示部３５１における画像の表示領域を決定するための制御信号を生成する。また、例えば、制御部３７０は、ユーザー情報及び管理情報に基づいて、表示部３５１における画像のサイズを決定するための制御信号を生成する。

　また、制御部３７０は、ユーザー情報及び管理情報に基づいて、使用する周波数チャネルと解像度を設定するための制御を行なう。例えば、制御部３７０は、無線通信部３２０が備える複数の周波数チャネルについて、使用する周波数チャネルをソース機器毎に設定する。また、制御部３７０は、周波数チャネル毎に、消費電力モードが異なる場合には、それぞれのモードを把握し、モバイル機器の消費電力をケアした周波数チャネルを設定することができるようにする。すなわち、制御部３７０は、第１の周波数帯に関する第１の消費電力モードと、第１の周波数帯よりも高速なデータ伝送速度の第２の周波数帯に関する第２の消費電力モードを別々に設定することができる。

　制御信号送信部３８０は、制御部３７０から出力された制御信号を無線通信部３２０並びにアンテナ３１０を介して、他の情報処理装置に送信する送信処理を行なう。

［Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔ仕様コマンドを用いたやりとりの通信例］
　図４には、第１の実施形態におけるソース機器４１０とシンク機器４２０間の接続シーケンス例を示している。同図は、ＲＴＳＰ（Ｒｅａｌ　Ｔｉｍｅ　Ｓｔｒｅａｍｉｎｇ　Ｐｒｏｔｏｃｏｌ）プロトコルを用いたやりとり（ＷＦＤ　ｃａｐａｂｉｌｉｔｙ　ｎｅｇｏｔｉａｔｉｏｎ）の通信処理例である。但し、ソース機器４１０とシンク機器４２０はそれぞれ、図１に示した通信システム１００における情報処理装置２００と情報処理装置３００に相当するものとする。

　最初に、図４中の点線の矩形４３０内に示すように、ソース機器４１０からシンク機器４２０に送信される「ＲＴＳＰ　Ｍ３　Ｒｅｑｕｅｓｔ」（ＲＴＳＰ　ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ　Ｒｅｑｕｅｓｔ）メッセージと、これに応答してシンク機器４２０からソース機器４１０に送信される「ＲＴＳＰ　Ｍ３　Ｒｅｓｐｏｎｓｅ」（ＲＴＳＰ　ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ　Ｒｅｓｐｏｎｓｅ）メッセージを用いることができる。

　一方、ソース機器４１０からシンク機器４２０に適宜送信するようにしてもよい。例えば、上記の「ＲＴＳＰ　Ｍ３　Ｒｅｑｕｅｓｔ」メッセージと、「ＲＴＳＰ　Ｍ３　Ｒｅｓｐｏｎｓｅ」メッセージのやりとりを省略して、ソース機器４１０からシンク機器４２０に送信されるメッセージに管理情報を含めて、ソース機器４１０からシンク機器４２０に管理情報を送信し、シンク機器４２０が情報を選択して管理情報保持部３９０に保持するようにしてもよい。また、コンテンツ・プロテクション設定を行なう場合、「ＲＴＳＰ　Ｍ３　Ｒｅｓｐｏｎｓｅ」メッセージの後にリンク・プロテクション・セットアップを行ない、その後、Ｍ４以上のメッセージに関する秘話性を確保したまま、通信を行なうようにしてもよい。

　ＲＴＳＰ　Ｍ３　Ｒｅｓｐｏｎｓｅとして受信するシンク機器４２０の情報は、以下のとおりである。

・Ａｕｄｉｏ　ｆｏｒｍａｔ（ｓ）　ｓｕｐｐｏｒｔｅｄ　ｂｙ　ｔｈｅ　ＷＦＤ　Ｓｉｎｋ．
・ｖｉｄｅｏ　ｆｏｒｍａｔ（ｓ）　ｓｕｐｐｏｒｔ　ｂｙ　ｔｈｅ　ＷＦＤ　Ｓｉｎｋ．
・３Ｄ　ｆｏｒｍａｔｓ　ｓｕｐｐｏｒｔｅｄ　ｂｙ　ｔｈｅ　ＷＦＤ　Ｓｉｎｋ．
・Ｔｈｅ　ＨＤＣＰ　ｓｙｓｔｅｍ　２．０／２．１／２．２　ｓｕｐｐｏｒｔ／ｃｏｎｔｒｏｌ　ｐｏｒｔ．
・Ａｖａｉｌａｂｌｅ　ＥＤＩＤ　ｉｎｆｏｒｍａｔｉｏｎ　ｏｆ　ｄｉｓｐｌａｙ　ａｔｔａｃｈｅｄ　ｔｏ　ｔｈｅ　ＷＦＤ　Ｓｉｎｋ．
・Ｃｏｕｐｌｅｄ　ＷＦＤ　Ｓｉｎｋ　ｉｎｆｏｒｍａｔｉｏｎ．
・ＲＴＰ　ｐｏｒｔ（ｓ）　ｔｈｅ　ＷＦＤ　Ｓｉｎｋ（ｓ）　ｌｉｓｔｅｎ　ｏｎ．
・Ｓｕｐｐｏｒｔｓ　Ｉ２Ｃ　ｃｏｍｍａｎｄｓ　ａｎｄ　ｐｏｒｔ　ｎｕｍｂｅｒ．
・ＵＩＢＣ　ｃａｐａｂｉｌｉｔｙ　ｓｕｐｐｏｒｔｅｄ．
・ＷＦＤ　Ｓｏｕｒｃｅ　ｕｓｅｓ　ｔｈｉｓ　ｐａｒａｍｅｔｅｒ　ｔｏ　ｏｂｔａｉｎ　ｔｈｅ　ｃｏｎｎｅｃｔｏｒ　ｔｙｐｅ　ｃｕｒｒｅｎｔｌｙ　ａｃｔｉｖｅ　ｏｎ　ｔｈｅ　ＷＦＤ　Ｓｉｎｋ．
・Ｉｎｄｉｃａｔｅ　ｔｈｅ　ｓｕｐｐｏｒｔ　ｆｏｒ　ｓｔａｎｄｂｙ　ａｎｄ　ｒｅｓｕｍｅ　ｃｏｎｔｒｏｌ　ｕｓｉｎｇ　ＲＴＳＰ．

　図４に示したソース機器４１０とシンク機器４２０との接続シーケンスは、第１の実施形態に係る通信システム１００における情報処理装置２００と情報処理装置３００との接続シーケンス、並びに、情報処理装置２００と情報処理装置４００との接続シーケンスに当てはまる。

［アクセシビリティー・モードが混在するマルチシンク・トポロジー環境］
　続いて、図１に示したようなマルチシンク・トポロジー環境で、障がい者向け端末モードであるアクセシビリティー・モードが混在する環境について考察する。

　ここで言うアクセシビリティー・モードとは、身体に障がいのある方や高齢のため身体の機能が低下している方々に対しての閲覧保障性（ウェブ・アクセシビリティー）へ対応したモードである。視覚障がいをサポートする「視覚障がいサポート」、聴覚障がいをサポートする「聴覚障がいサポート」、認知又は身体障がいをサポートする「身体機能（操作困難）サポート」など、サポートすべき障がい毎に、アクセシビリティー・モードの種別（情報処理装置において対応する動作）が異なる。各アクセシビリティー・モード種別における情報処理装置の動作を以下に例示する。

（１）視覚障がいサポート
・画面内容を音声読み上げすることで、視覚サポートを行なう。具体的には、アプリケーション名を音声読み上げする機能、タップを変更し、アイコンを選択するときには１回タップし、アイコンを実行するためには、ダブルタップするといった端末が存在する。さらに、バイブレーションによりアイコンが選ばれたことを通知する方法や、点字用ディスプレイを接続することも可能となる。
・画面の文字を大きくすること、ズーム機能による画面を拡大・縮小、画面の色反転などが可能である。

（２）聴覚障がいサポート
・映画、ビデオ鑑賞時は、字幕表示に変更する。
・音声の音量を調整する。
・着信をＬＥＤフラッシュで通知する。

（３）身体機能サポート
・ピンチなどうまくできないジェスチャーを、認知又は身体障がいのある操作者が操作可能な独自に作った別のジェスチャーに置き換えられる。
・ピンチなどのジェスチャーができないときに、音声操作ができるようにする。

　図８には、障がいの種別毎の情報処理装置に対する対応要求と、実際に情報処理装置が対応する動作例をまとめている。

　図８を補足すると、対応動作「音声、触覚での情報提示、操作」の具体例として、ＴＴＳ（ｔｅｘｔ　ｔｏ　ｓｐｅｅｃｈ）、報知音、凸点、点字、ディスプレイ、音声操作などを挙げることができる。また、対応動作「見え難い色の組み合わせを用いない、色で判別する情報に文字を併記」の具体例として、赤・緑の組み合わせ禁止や、カラーキーに文字を併記することなどを挙げることができる。また、対応動作「視力０．２８６～０．１の人が操作可」の具体例として、文字、画面の拡大、コントラストの変更などを挙げることができる。また、対応動作「音声情報の視覚化」の具体例として、Ｓｐｅｅｃｈ　ｔｏ　Ｔｅｘｔ、報知光、振動、ジェスチャー、手話などを挙げることができる。また、対応動作「発話に頼らないモードを提供」の具体例として、キーボード対応などを挙げることができる。また、対応動作「認知、記憶、言語、理解能力を問わないモードを提供」の具体例として、Ｐｌａｉｎ　ｔｅｘｔ、ＴＴＳ、記号やイラストを併記することなどを挙げることができる。また、対応動作「細かい操作や同時に行なう操作を要求しないモードを提供」の具体例として、キーボードショートカット対応などを挙げることができる。また、対応動作「身体を伸ばしたり、力を入れることが不自由な人でも操作できるモードを提供」の具体例として、タッチパネル、外部キーボード、音声操作などを挙げることができる。また、対応動作「身体に直接触れなくても操作可」の具体例として、大きなキーボード、音声操作などを挙げることができる。

　同じ障がいの種別であっても、障がいの度合いによって、情報処理装置に対する対応要求は異なってくる。また、障がいの種別が相違していても、障がいの度合いによっては、情報処理装置への対応要求や情報処理装置の対応動作が同一又は類似する場合もある。但し、図８は例示に過ぎず、障がいの種別に対する他の対応要求も考え得ることを理解されたい。以下では、障がいの種別に応じたアクセシビリティー・モードを「アクセシビリティー・モード種別」とする。

［想定される接続形態］
　複数のシンク機器が、健常者向けモード（通常モード）と障がい者向けモード（アクセシビリティー・モード）とが混在するマルチシンク・トポロジー環境において、ソース機器の動作概要について説明する。

　図５Ａには、ソース機器とシンク機器がともにアクセシビリティー・モードでやりとりする接続形態を例示している。例えば図１に示した通信システム１００で、情報処理装置２００と情報処理装置３００がアクセシビリティー・モードで、情報処理装置４００が通常モードで、それぞれ動作している場合である。

　また、図５Ｂには、通常モードのソース機器とアクセシビリティー・モードのシンク機器がやりとりする接続形態を例示している。例えば図１に示した通信システム１００で、情報処理装置２００が通常モードで動作し、情報処理装置３００又は４００のうち少なくとも一方がアクセシビリティー・モードで動作している場合である。

　マルチシンク・トポロジー環境では、図５Ａや図５Ｂに例示したように、通常モードとアクセシビリティー・モードのシンク機器が混在することが想定される。ソース機器は、各シンク機器を接続時に、アクセシビリティー・モードかどうかを確認する。そして、アクセシビリティー・モードのシンク機器に対しては、本来の画像・音声データの伝送の際に、障がいをサポートするための（若しくは、伝送する画像の閲覧を保証するための）メタデータ（図８に示す対応動作例を実現するのに必要なデータ、例えば、音声、映像、テキスト、音声情報を視覚化した情報、サイズ情報など）を加えるかどうかを判断する。ソース機器は、各々のシンク機器のアクセシビリティー・モードがオン又はオフかによって、メタデータの伝送方法を変更する。伝送方法には、Ｍｕｌｔｉｐｌｅ　Ｕｎｉｃａｓｔ、Ｍｕｌｔｉｃａｓｔの両方を利用することができる。

　例えば、ソース機器は、接続したすべてのシンク機器へ、サポートが必要なすべてのメタデータを送信する。これに対し、各シンク機器は、自分のアクセシビリティー・モード種別に適合するメタデータを利用するか否かをそれぞれ判断すればよい。

　図５Ａ並びに図５Ｂに示したような、通常モードとアクセシビリティー・モードが混在するマルチシンク・トポロジー環境では、以下の（１）～（５）に示す５通りのアプローチが考えられる。

（１）マルチシンク・トポロジー環境において、ソース機器は、画像転送を開始する前に、各シンク機器のモードを統一するための調停を行なう。具体的には、ソース機器は、複数のシンク機器のモードを一致するよう、各シンク機器へ要求（シンク機器のモード統一のための調停）をし、各端末のモードを一致させてから画像転送を開始する。

（２）ソース機器は、（１）のような複数のシンク機器とのモードを統一するための調停を行なわず、自端末の動作モードで送信処理を行なう。各シンク機器は、ソース機器から受信したデータに基づいて、自端末が取り扱い可能なデータに変換させて、再生する。

（３）マルチシンク・トポロジー環境において、ソース機器は、アクセシビリティー・モードのシンク機器と接続することを把握し、これから接続するアクセシビリティー・モード種別の論理和をとった結果に基づいて、サポートが必要なすべてのメタデータを送信する。シンク機器は、受信した複数のメタデータの中から、自端末にて再生可能なメタデータのみを抽出して再生する。

（４）マルチシンク・トポロジー環境において、ソース機器は、複数のシンク機器のうち、アクセシビリティー・モードの有無を把握し、アクセシビリティー・モード端末が存在する場合には、アクセシビリティー・モード種別として選択可能なすべてのメタデータをＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ処理から情報収集する。シンク機器は、受信した複数のメタデータの中から、自端末にて再生可能なメタデータのみを抽出して再生する。

（５）マルチシンク・トポロジー環境において、ソース機器は、複数のシンク機器が選択されたアクセシビリティー・モード種別をＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ処理から情報収集する。情報収集の結果、同じ障がいの種別毎にグループ分けを行ない、グループ毎に対応したメタデータを送信する。

　図６には、図５Ａに示したトポロジー環境で、上記のアプローチ（１）でソース機器と各シンク機器間の接続シーケンス例を示している。

　ソース機器２００がアクセシビリティー・モードの場合、シンク機器３００がアクセシビリティー・モード種別まで一致するどうか、また、シンク機器４００を通常モードからアクセシビリティー・モードへ変換するためのアプローチが必要となる。

　まず、図５Ａに示したトポロジー環境で、ソース機器２００とシンク機器３００のアクセシビリティー・モードが一致していることを前提としてソース機器２００とシンク機器３００の接続シーケンスの処理について説明する。

　ソース機器２００のアクセシビリティー・モードを操作し映像又は音声を選択すると、通常のコンテンツ・データ（図６記載のコンテンツ・データ）の伝送の他に、アクセシビリティー・モード用メタデータ（図６記載のメタデータ）として、上記視覚サポート、聴覚サポート、身体機能（操作困難）サポートのうち、どれか１つ以上の情報を別途送信する。但し、アクセシビリティー・モード用メタデータとコンテンツ・データの送信手順は、図６に示した通信手順に限定されない。アクセシビリティー・モード用メタデータは、コンテンツ・データを（障がいをサポートするために）補間する情報であり、コンテンツ・データと同時に送信される以外に、どちらか片方が送信されることもある。

　これに対し、シンク機器３００は、ソース機器２００からコンテンツ・データを受信すると同時に、アクセシビリティー・モード用メタデータを受信し、シンク機器３００内部の制御によって、適宜、最適なコンテンツの表示を行なう。

　一方、シンク機器３００側でアクセシビリティー・モードを操作してソース機器２００の映像又は音声をリモート選択すると、上記コンテンツ・データとメタデータとは別に、シンク機器３００からソース機器２００へ、シンク機器３００の操作情報がアクセシビリティー・モード用操作情報（図６記載の操作用メタデータ）として送信される。ソース機器２００は、シンク機器３００から、シンク機器３００の操作情報をシンク機器３００のアクセシビリティー・モード用操作情報として受信すると、受信した操作情報の通りに動作を行なう。アクセシビリティー・モード用操作情報に基づくソース機器２００の操作は、従来のＵＩＢＣと同等の機能であるが、閲覧保障性を考慮することで、ＵＩＢＣのデータ種別が、音声や映像やテキスト情報、又は音声情報を視覚化した情報も含まれるものとする。

　ここで、ソース機器２００又はシンク機器３００の操作者が接続中に変更した場合のために、通常モードとアクセシビリティー・モードを途中で変更するモード・エックスチェンジ用メッセージ信号を用意してもよい。例えば、送受信間で本メッセージがやりとりされると、現在送受信中の無線映像伝送を切断させることなく、通常モードとアクセシビリティー・モード、又は、アクセシビリティー・モードの種別を変更することが可能となる（図１１（後述）にコマンドのやりとりの一例を示す）。

　なお、ソース機器は、アクセシビリティー・モードの種別を変更する前に、操作しているシンク機器に対し、操作者へ変更が問題ないかを確認するポップアップを表示させるようにてもよい。

　続いて、図５Ａに示したトポロジー環境で、ソース機器２００とシンク機器３００のアクセシビリティー・モードが一致していないことを前提として、ソース機器２００とシンク機器３００の接続シーケンスの処理について説明する。

　ソース機器２００からシンク機器３００へ伝送する映像や音声を、ソース機器２００側にて操作する場合、ソース機器２００は、ソース機器２００とシンク機器３００のアクセシビリティー・モード種別が一致するよう、操作によって作成された映像、音声、テキストとリンクしたアクセシビリティー・モード用メタデータをシンク機器３００に送信する。このとき、ソース機器２００は、上記アクセシビリティー・モード用メタデータを、シンク機器３００が操作可能なコンテンツ・メディアに変換してから送信処理を行なう。例えば、聴覚サポートのアクセシビリティーの場合、ソース機器２００は、映画、ビデオ鑑賞コンテンツについては、字幕データをテキストとして送信したり、音声の音量を調整したりする。また、ソース機器２００は、シンク機器３００側で着信をＬＥＤフラッシュが実現できるよう、制御データをシンク機器３００へ伝送する処理を行なう。

　また、上記のアプローチ（２）では、シンク機器４００は、ソース機器２００からアクセシビリティー・モード用コンテンツ・データ、又は、アクセシビリティー・モード用メタデータを受信すると、適宜、コンテンツに最適な変換を施してから表示を行なう。

　ソース機器２００は、シンク機器４００から、（ソース機器２００が受信可能な操作情報に変換された）ソース機器２００のリモート操作情報を受信し、受信した操作用メタデータを、そのままアクセシビリティー・モードの操作用データとして処理する。従来のＵＩＢＣと同等の機能であるが、閲覧保障性を考慮することで、ＵＩＢＣのデータ種別に、音声や映像やテキスト情報、又は音声情報を視覚化した情報も含まれてもよいものとする。

　なお、アプローチ（２）を実現するための動作は上記に限定されないものとする。例えば、アクセシビリティー・モードに合ったデータ変換はソース機器２００又はシンク機器４００側のどちらでもよい。加えて、例えば、ソース機器２００側で通常モードに変換できるようにしてもよい。特に、操作用データは、通常モードとアクセシビリティー・モードではタップの扱いが異なるため、モードが異なる機器間の伝送では変換操作が必須となる。例えば、身体機能（操作困難）サポートにおいて、ソース機器２００の操作者が独自のユーザー操作を登録した場合、シンク機器３００、４００では操作内容の解釈できないため、ソース機器２００でシンク機器３００のアクセシビリティー・モードとシンク機器４００の通常モードの操作を理解できるように、ソース機器２００にて把握するのが適している。

　続いて、上記のアプローチ（３）において、ソース機器４１０が、具体的にはＭｉｒａｃａｓｔでの処理を用いて、シンク機器４２０とのＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎを行なう方法について、図７を参照しながら説明する。このＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎを行なう方法によって、聴覚、視覚、身体機能（操作困難）のうちどのアクセシビリティー・モードが選択されているかをソース機器４１０側で判断できるかを確認することが可能となる。

　図７中の点線の矩形４３０内に示すように、シンク機器４２０は、ソース機器４１０からのＲＴＳＰＧＥＴ＿ＰＡＲＡＭＥＴＥＲＲｅｑｕｅｓｔに従って、シンク機器４２０側に設定しているアクセシビリティー能力を、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ　Ｒｅｓｐｏｎｓｅで返信している。図７では、このＧＥＴ＿ＰＡＲＡＭＥＴＥＲ　Ｒｅｓｐｏｎｓｅの返信内容の一例を示している。

　なお、ソース機器４１０がシンク機器４２０とアクセシビリティー能力をやりとりするメッセージにおいて、Ｍｉｒａｃａｓｔ規格上で実現する場合のメッセージの一例として、以下を使用するものとする。

［アクセシビリティー・モードの設定例］
　図１０及び図１１には、第１の実施形態に係る通信システム１００において、ソース機器とシンク機器間でＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ通信処理を行なうシーケンス例を示している。図１０及び図１１では、Ｃａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎにおいて、アクセシビリティー・モード用メタデータを設定するための通信例（アクセシビリティー・モード用メタデータの設定例）を示している。このアクセシビリティー・モード用メタデータ設定方法については、Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔの規格に適応した場合の一例である。

　アクセシビリティー・モード用メタデータを設定する場合、Ｍ３メッセージ（ＲＴＳＰ　ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ）により、ソース機器４１０及びシンク機器４２０間でＷｆｄ－ａｃｃｅｓｓｉｂｉｌｉｔｙ－ｃａｐａｂｉｌｉｔｙのやりとりを行なう。このやりとりは、シンク機器４２０がアクセシビリティー・モード用メタデータ機能を内蔵しているか否かを、ソース機器４１０が確認することが目的である。

　この目的を上記のアプローチ（３）で実現する場合、図６に示した通信シーケンス中のＳ６０１とＳ６０２のＣａｐａｂｉｌｉｔｙＮｅｇｏｔｉａｔｉｏｎのＲＴＳＰ　Ｍ３の各メッセージにおいて、図９のアクセシビリティー対応要求のビット・アサインが同時に立ち上がっているモードを、ソース機器２００はすべてのシンク機器３００、４００が設定可能な統一のアクセシビリティー・モードと判断する。

　例えば、ビット０が”１”（アクセシビリティー・モード　Ｏｎ）の前提で、Ｓ６０１のメッセージで一方のシンク機器３００から示されるＷｆｄ－ａｃｃｅｓｓｉｂｉｌｉｔｙ－ｃａｐａｂｉｌｉｔｙ　Ｒｅｓｐｏｎｓｅ情報［１４：５］が０００００００１０１となり、Ｓ６０２のメッセージで他方のシンク機器４００から示されるＷｆｄ－ａｃｃｅｓｓｉｂｉｌｉｔｙ－ｃａｐａｂｉｌｉｔｙ　Ｒｅｓｐｏｎｓｅ情報［１４：５］が０００００００１００となった場合、すべての操作内容をビットＯＲすると、１ビット目（図９に示すビット・アサインでは「視力なしで操作可能」に対応）と３ビット目（図９に示すビット・アサインでは「弱視且つ軟調で操作可能」に対応）が“１”になっている。例えば、図８に示した障がいの種別の対応要求に対する対応例に従うとすると、ソース機器２００は、以下の２つのうちいずれをアクセシビリティー・モード用メタデータとして生成可能かを判断する。

・報知音声、点字ディスプレイ用データ、操作用音声
・文字サイズ、画面拡大レベル、コントラスト変更に関する情報

　そして、ソース機器２００は、上記２つのアクセシビリティー・モード用メタデータのうちどちらかを生成可能と判断することができた場合、Ｗｆｄ－ａｃｃｅｓｓｉｂｉｌｉｔｙ－ｓｅｔｔｉｎｇとして、該当するアクセシビリティー・モードを設定するようにする。

　図１０Ａに示す、ソース機器４１０とシンク機器４２０間でのＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ通信方法では、ソース機器４１０は、シンク機器４２０のＣａｐａｂｉｌｉｔｙ情報をシンク機器４２０から受信すると、Ｍ４メッセージで、シンク機器４２０にアクセシビリティー・モード用メタデータ回線設定要求を行なう。なお、Ｍ４メッセージでアクセシビリティー・モード用メタデータ回線設定要求を送信せずに、画像伝送を開始した後に、Ｍ１４メッセージで接続要求を行なうようにしてもよい。また、Ｍ１４メッセージ送信時には、ソース機器４１０からの要求だけでなく、図１１Ａに示すように、シンク機器４２０からソース機器４１０へアクセシビリティー・モード用メタデータ回線設定要求を行なうようにしてもよい。

　また、Ｍ４でｗｆｄ－ａｃｃｅｓｓｉｂｉｌｉｔｙ－ｓｅｔｔｉｎｇ、ｗｆｄ－ａｃｃｅｓｓｉｂｉｌｉｔｙ－ｓｅｔｔｉｎｇのやりとりを行なうことができた場合、アクセシビリティー・モード用メタデータがＥｎａｂｌｅになるが、Ｍ１４メッセージのやりとりを行なった場合では、Ｍ１５メッセージを受信するまで、アクセシビリティー・モード用メタデータがＥｎａｂｌｅにならない。このため、図１０Ｂや図１１Ｂに示すように、ソース機器４１０又はシンク機器４２０は、アクセシビリティー・モード用メタデータ回線設定要求に対する返答を受信した後、Ｍ１５メッセージのやりとりを行なう。これにより、アクセシビリティー・モード用メタデータ回線がＥｎａｂｌｅとなる。

　図１１に示す動作シーケンス例では、ソース機器４１０とシンク機器４２０との間で映像伝送を開始した後に、アクセシビリティー・モード用メタデータ回線をシンク機器４２０から要求している。なお、図１１Ａについては、図１０Ａに示した通り、映像伝送開始前のＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ時に設定することもできるものとする。

　以上により、ソース機器とシンク機器がアクセシビリティー・モードに対応しているかどうかを、接続時のＣａｐａｂｉｌｉｔｙＮｅｇｏｃｉａｔｉｏｎで確認することができる。さらに、本実施例ではＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎによって、アクセシビリティー・モード種別を判断していたが、その他でもよい。例えば、Ｄｅｉｖｃｅ　Ｄｅｓｃｏｖｅｒｙ又はＳｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙを用いてもよい。Ｄｅｉｖｃｅ　Ｄｅｓｃｏｖｅｒｙ又はＳｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙの制御方法の一例としては、Ｐ２Ｐ　ＩＥ（Ｉｎｆｏｒｍａｔｉｏｎ　Ｅｌｅｍｅｎｔ）、ＷＦＤ　ＩＥ（Ｉｎｆｏｒｍａｔｉｏｎ　Ｅｌｅｍｅｎｔ）、ＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｅｒｖｉｃｅ　Ｐｌａｔｆｏｒｍ）、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ　Ｐｌｕｇ　ａｎｄ　Ｐｌａｙ）標準でのプロトコルなどを用いてもよい。

　さらに、ソース機器からシンク機器へ、アクセシビリティー・モード用メタデータ（図８の対応動作例を実現するのに必要なデータ、例えば、音声、映像、テキスト、バイブレーション）を送信するチャネルを新設することもできる。また、アクセシビリティー・モード用メタデータに意味を持たせて、又はシンク機器が設定モードに応じて、シンク機器からソース機器へ伝送するＵＩＢＣをＥｎａｂｌｅになっていない接続設定でも再生するか情報を判断し、選択することができる。

　図１２には、アクセシビリティー・モード用メタデータ回線をＥｎａｂｌｅにすることで、各アクセシビリティー・モード種別におけるシンク機器の動作例をまとめている。

　同図において、「アクセシビリティー」（視覚サポート、聴覚サポート、操作困難サポート、認知サポート）の欄は、ソース機器とシンク機器間で設定されたモード種別を示し、「メディア・データ」の欄は、コンテンツ・データのメディアを示し、Ｍｉｒａｃａｓｔ規格ではＲＴＰによって送信されるデータに相当する。

　「アクセシビリティー・データ」は、アクセシビリティー用メタデータ回線を用いて伝送されるメディア（アクセシビリティー・モード用メタデータ）を示す。アクセシビリティー用メタデータ回線のプロトコルとしては、例えば、ＲＴＳＰ又はＴＣＰを用いて伝送される。

　「アクセシビリティー・モード時対応」又は「通常モード時対応」の各欄は、シンク機器でアクセシビリティー・モードが選択された場合と通常モードが選択された場合それぞれの表示形態の違いの一例を示している。

　例えば、アクセシビリティー・モード種別が「視覚障がい」且つ「視力なしで操作可能」（図８を参照のこと）の場合、音声、触覚での操作が可能となるため、図１２においては音声操作を可能にするため、メディア・データとして音声を伝送するとともに、アクセシビリティー・モード用メタデータとして操作用音声をソース機器からシンク機器へ伝送する。

　メディア・データ用音声、アクセシビリティー・モード用メタデータとしての操作用音声を受信したシンク機器は、アクセシビリティー・モード時（例えば、図１７（後述）に示すシンク機器の画面でアクセシビリティー操作ボタンがオンの場合）の対応として、メディア音声をミュート又は音量を落とし、操作用音声をメインに再生する処理を行なう。一方、通常モード時（例えば、図１７に示すシンク機器の画面でデフォルト操作ボタンがオンの場合）の対応としては、メディア音声を優先して流し、操作用音声は再生しない処理を行なう。

　図１３Ａ及び図１３Ｂには、ソース機器が複数のシンク機器用アクセシビリティー・モード種別の中から共通するアクセシビリティー・モードを選択するための処理手順をフローチャートの形式で示している。

　まず、ソース機器２００の制御部２４０は、接続したい（情報伝達範囲１０１内に存在する）各シンク機器との間でＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎを開始する（ステップＳ９０２）。

　続いて、制御部２４０は、各シンク機器との間で接続可能なアクセシビリティー・モードを確認した後、アクセシビリティー・モードでの動作を要求するか否かを判断する（ステップＳ９０３）。アクセシビリティー・モードでの動作を要求しないシンク機器に対しては（ステップＳ９０３のＮｏ）、ソース機器２００は、通常モードで通信を開始する。

　また、ソース機器２００の制御部２４０は、シンク機器にアクセシビリティー・モードでの動作を要求するときには（ステップＳ９０３のＹｅｓ）、そのシンク機器をメタデータ管理リストに登録し保持する（ステップＳ９０４）。

　接続したいすべてのシンク機器への確認が終了していないときには（ステップＳ９０５のＮｏ）、ステップＳ９０２に戻って上記と同様の処理を繰り返す。また、接続したいすべてのシンク機器への確認を終了すると（ステップＳ９０５のＹｅｓ）、制御部２４０は、次ステップＳ９０６の処理に進む。

　ソース機器２００は、同じアクセシビリティー・モード種別を持つシンク機器毎にグループ分けすることが可能かどうかをチェックする（ステップＳ９０６）。

　アクセシビリティー・モード種別毎にシンク機器をグループ分けしない場合には（ステップＳ９０６のＮｏ）、接続したいすべてのシンク機器にすべてのアクセシビリティー・モード用メタデータを送信して（ステップＳ９０７）、本処理を終了する。

　一方、シンク機器をアクセシビリティー・モード種別毎にグループ分けして管理を行なう場合には（ステップＳ９０６のＹｅｓ）、ソース機器２００は、アクセシビリティー・モードの種別を確認する（ステップＳ９０８）。アクセシビリティー・モードの種別を考慮する必要がない、又は種別情報が含まれていない場合には（ステップＳ９０９のＮｏ）、アクセシビリティー・モードの中で最も優先度が高いモードを選択する。図１３Ｂでは、視覚サポート、聴覚障がい、操作困難の順で優先度が高いというケースを示している。

　ソース機器２００は、各ステップＳ９１０、Ｓ９１１、Ｓ９１２で、グループのアクセシビリティー・モードが視覚サポートか、聴覚サポートか、身体（操作困難）サポートかを、シンク機器から受信したＣａｐａｂｉｌｉｔｙ情報から判断する。

　グループのアクセシビリティー・モードが視覚サポートの場合（ステップＳ９１０のＹｅｓ）、ソース機器２００は、アクセシビリティー・モード用メタデータとして、コンテンツ・メディア伝送に同期した音声の提供（例えば、アプリケーションの内容を読み上げる処理）や、操作者がタップしたときに選択されたアイコンの名称を音声にて提供する処理に変更して（ステップＳ９１３）、当該グループに振り分けられた各シンク機器へ伝送する（ステップＳ９１６）。なお、音声提供方法として、アクセシビリティー・モード用コンテンツ・メディアの音声の一部として提供する方法や、アクセシビリティー・モード用メタデータとして音声を挿入する方法を挙げることができるが、これらに限定されない。

　また、グループのアクセシビリティー・モードが聴覚サポートの場合（ステップＳ９１１のＹｅｓ）、ソース機器２００は、アクセシビリティー・モード用メタデータとして、コンテンツ・メディア伝送に同期した字幕の提供や、操作者がセットした音声通知をＬＥＤフラッシュに変換して（ステップＳ９１４）、当該グループに振り分けられた各シンク機器へ伝送する（ステップＳ９１６）。なお、字幕やＬＥＤフラッシュの提供方法として、コンテンツ・メディアの一部として提供する方法や、アクセシビリティー・モード用メタデータとして提供する方法が挙げられるが、これらに限定されない。また、コンテンツ・メディア、アクセシビリティー・モード用メタデータを無線伝送する際のパケット種別は、マルチキャスト・パケット又はユニキャスト・パケットのどちらでも良い。

　また、グループのアクセシビリティー・モードが身体（操作困難）サポートの場合（ステップＳ９１２のＹｅｓ）、ソース機器２００は、独自に作成したジェスチャー操作のデータを、シンク機器が理解できるポインティングへ変換した後（ステップＳ９１５）、当該グループに振り分けられた各シンク機器へ送信する処理を行なう（ステップＳ９１６）。なお、送信するコンテンツ・メディア、アクセシビリティー・モード用メタデータを無線伝送する際のパケット種別は、マルチキャスト・パケット又はユニキャスト・パケットのどちらでも良い。

　ステップＳ９１７は本動作フローを終了する処理である。

　なお、送信又は受信端末において、端末のモード又はアクセシビリティーの種別が異なる場合、送信又は受信で操作用手段を変換するようにし、モードを一致させてもよい。

　このように、ソース機器２００の無線通信部２２０は、Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔ仕様に従ってシンク機器との間でリアルタイム画像伝送を行なう。また、制御部２４０は、ソース機器から送信された画像情報に基づく画像を表示部（図２では図示しない）に表示させ、その画像に関するアクセシビリティー・モード用メタデータをシンク機器との間でやりとりするための複数の通信方式（ＵＩＢＣ、ＷｅｂＳｏｃｋｅｔ）に使用されるポートでの制御を行なう。この場合に、例えば、制御部２４０は、シンク機器との間で生成されたＴＣＰセッション上でポートを設定する場合に、ポートを使用する複数の通信方式を指定する情報（例えば、図１５（後述）を参照のこと）をシンク機器に送信する。

　制御部２４０は、複数の通信方式に使用されるポートとして複数の通信方式毎に複数のポートを設定することができる。この場合には、制御部２４０は、シンク機器からの要求に応じて複数のポートを設定することができる。

　また、制御部２４０は、複数の通信方式に使用されるポートとして複数の通信方式について１つのポートを設定することができる。

　また、例えば、情報処理装置２００の制御部２４０は、シンク機器側の表示部に画像を表示させるための画像情報をシンク機器に送信する。また、制御部２４０は、その画像に関する制御情報をシンク機器との間でやりとりするための複数の通信方式に使用されるポートを設定する制御を行なうことができる。

［第２の実施形態］
［通信システム構成］
　図１６には、本明細書で開示する技術の第２の実施形態に係る通信システム１１００の構成例を模式的に示している。図１６では、Ｐ２Ｐダイレクト通信により無線通信を行なうことができる通信システムの一例を示している。

　通信システム１１００は、複数の情報処理装置１２００、１３００、１４００で構成される。また、通信システム１１００は、情報処理装置１２００又は情報処理装置１４００のうちの少なくとも１つから送信されるデータ（例えば、画像データや音声データ）を情報処理装置１３００が受信するように構成されている。また、各情報処理装置１２００、１３００、１４００は、無線通信機能を備える送受信機器である。

　以下では、情報処理装置１２００と情報処理装置１３００間、又は、情報処理装置１４００と情報処理装置１３００間で無線ＬＡＮを用いた無線通信を行なう場合を例にとって、通信システム１１００の動作について説明する。

　図示の通信システム１１００は、Ｐ２Ｐダイレクト通信を用いたマルチソース・トポロジー環境の無線接続を行なうことを想定している。例えば、情報処理装置１２００、１４００をソース機器とし、情報処理装置１３００をシンク機器とする。具体的には、情報処理装置１２００の撮像動作により生成された画像データが情報処理装置１３００に送信され、その画像データに基づく画像１１１が情報処理装置１３００の表示部１３５１に表示される。また、情報処理装置１４００の記憶部（例えば、ハードディスク）に保存されているコンテンツが情報処理装置１３００に送信され、そのコンテンツに基づく画像１１２が情報処理装置１３００の表示部１３５１に表示される。情報処理装置１３００は、操作者などを撮像する撮像部１３６１を備えていてもよい。

　また、図１６では、Ｐ２Ｐダイレクト接続により無線通信を利用して情報処理装置１３００が直接通信することができる範囲を、情報伝達範囲１１０１として示している。この情報伝達範囲１１０１は、情報処理装置１３００を基準とした場合における情報伝達範囲（サービス範囲）である。

　このようなマルチソース・トポロジー環境において、通常モードの端末とアクセシビリティー・モードの端末が混在することが想定される。図１４Ａには、アクセシビリティー・モード及び通常モードのソース機器がともに１台のアクセシビリティー・モードのシンク機器とやりとりする接続形態を例示している。また、図１４Ｂには、通常モード及びアクセシビリティー・モードのソース機器がともに１台の通常モードのシンク機器とやりとりする接続形態を例示している。

　マルチソース・トポロジー環境は、第１の実施形態として説明したマルチシンク・トポロジー環境とは相違がある。マルチソース・トポロジー環境でも、第１の実施形態と同様に、以下のアプローチ（１１）、（１２）が可能である。

（１１）マルチソースにおいて、シンク機器は、複数のソース機器のモードを一致するよう、各ソース機器へ応答し、各端末のモードを一致するよう、ソース機器に促してから画像転送を開始する。

（１２）シンク機器は、上記（１１）のような複数のソース機器とのモードを統一するための調停を行なわず、ソース機器から受信したデータに基づいて、自端末が取り扱い可能なデータに変換させて、再生する。

　一方、第１の実施形態との違いは、マルチソース・トポロジー環境では、シンク機器から複数のソース機器に対し、ＵＩＢＣデータを送信する点である。ソース機器とシンク機器間でやりとりされるＵＩＢＣのパケット・フォーマットとして、以下の（２１）～（２３）を挙げることができる。

（２１）ソース機器毎のモードに合うよう、ＵＩＢＣデータを変換した後に送信する方法

（２２）シンク機器では、ソース機器のモードに拘わらず、ＵＩＢＣデータを送信し、各ソース機器が自端末で理解可能なデータに変換して内部処理する方法

（２３）ソース機器、シンク機器を含めすべての機器が切替可能な共通なモードに切り替えた後に送受信する方法

　加えて、マルチソース・トポロジー環境でのユースケースとして、大画面ディスプレイ表示をソース機器の所有者でシェアするケースが考えられる。このユースケースでは、大画面ディスプレイを健常者が操作するケースと障がい者が操作するケースが時分割又は同時に発生する可能性がありえる。そこで、アクセシビリティー・モードのソース機器が接続した場合、シンク機器の表示画面から、アクセシビリティー・モード用操作を行ないたいのか、デフォルトの表示機器が持つ操作を行ないたいのか、切替又は同時利用ができるものとする。なお、シンク機器は、アクセシビリティー・モードの種別を変更する前に、操作しているシンク機器に対し、操作者へ変更が問題ないかを確認するポップアップを表示させるようにてもよい。

　図１７には、アクセシビリティー操作とデフォルト操作を指定するボタンを含んだ大画面ディスプレイ１７００を例示している。この大画面ディスプレイ１７００は、マルチソース・トポロジー環境において、シンク機器として動作するが、例えばタッチパネル式の画面にアクセシビリティー操作ボタン１７１１とデフォルト操作ボタン１７１２を備えている。操作者は、アクセシビリティー操作ボタン１７１１とデフォルト操作ボタン１７１２のうちいずれかを選択することで、アクセシビリティー・モード用操作を行ないたいのか、デフォルトの表示機器が持つ操作を行ないたいのかを指示することができる。

　さらに、アクセシビリティー操作とデフォルト操作の切り替え又は同時利用によって、操作者が接続中にシンク機器のモードを変更した場合、通常モードとアクセシビリティー・モードを途中で変更するモード・エックスチェンジ用メッセージ信号（前述）を伝送途中で送信又は受信することで、操作者が変更した環境でも、初期動作に戻ることなく、効率良い動作を行なえるものとする。

　また、シンク機器は、ソース機器からの要求に基づいて、シンク機器の表示位置に関する情報を伝送するため、接続途中、ＵＩＢＣの制御チャネルを、要求があったソース機器に切り替えることもできる。また、ソース機器は、シンク機器からの操作により、ソース機器の表示位置情報を伝送するため、接続途中、ＵＩＢＣの制御チャネルを、要求があったシンク機器に切り替えることもできる。

［ＷｅｂＳｏｃｋｅｔを用いたアクセシビリティー・モード用メタデータ伝送の送信例］
　アクセシビリティー・モード用メタデータ回線として、ＷｅｂＳｏｃｋｅｔの制御回線を用いて、画像データや音声データ、テキスト・データを送受信することも可能である。そこで、以下では、ＷｅｂＳｏｃｋｅｔの制御回線を用いて画像データや音声データを送受信する例について説明する。

　図１５には、第１の実施形態におけるソース機器４１０とシンク機器４２０間のＷｅｂＳｏｃｋｅｔを用いた画像データ及び音声データの通信処理例を示している。図１５Ａには、ソース機器４１０とシンク機器４２０間における通信処理例を示している。また、図１５Ｂ及び図１５Ｃには、ソース機器４１０とシンク機器４２０間でやりとりされるＷｅｂＳｏｃｋｅｔのフレーム・フォーマット例を示している。

　また、図１５Ａに示す通信処理例では、Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔのソース機器４１０が、ＷｅｂＳｏｃｋｅｔのクライアントとして機能し、シンク機器４２０が、ＷｅｂＳｏｃｋｅｔのサーバーとして機能する。なお、１台のソース機器と１台のシンク機器が接続するＰ２Ｐ伝送を想定しているため、サーバー及びクライントはどちらでも良いが、複数接続する環境においては、複数端末と接続するＧＯ（グループ・オーナー）がＷｅｂＳｏｃｋｅｔのサーバー機能として動作することが望ましい。

　例えば、ソース機器４１０は、参照番号４４１で示すように、Ｈｏｓｔ、Ｓｅｃ－ＷｅｂＳｏｃｋｅｔ－Ｋｅｙ、Ｓｅｃ－ＷｅｂＳｏｃｋｅｔ－Ｖｅｒｓｉｏｎをシンク機器４２０に送信する。なお、Ｈｏｓｔは、ＷｅｂＳｏｃｋｅｔの接続先を指定するものである。また、Ｓｅｃ－ＷｅｂＳｏｃｋｅｔ－Ｋｅｙは、ハンドシェイク応答を得るためのものである。また、Ｓｅｃ－ＷｅｂＳｏｃｋｅｔ－Ｖｅｒｓｉｏｎは、ＷｅｂＳｏｃｋｅｔのバージョンを指定するためのものである。

　また、シンク機器４２０は、ソース機器４１０から受信したＳｅｃ－ＷｅｂＳｏｃｋｅｔ－Ｋｅｙの値に基づいて、Ｓｅｃ－ＷｅｂＳｏｃｋｅｔ－Ａｃｃｅｐｔの値を作成する。そして、シンク機器４２０は、参照番号４４２で示すように、作成したＳｅｃ－ＷｅｂＳｏｃｋｅｔ－Ａｃｃｅｐｔをソース機器４１０に送信する。ここで、Ｓｅｃ－ＷｅｂＳｏｃｋｅｔ－Ａｃｃｅｐｔは、クライアントとのコネクションを維持するためのものである。

　また、ソース機器４１０は、図１５Ｂに示すフレーム・フォーマットをシンク機器に送信する。このフレーム・フォーマットでは、送信対象となるデータを、ＷｅｂＳｏｃｋｅｔ　Ｔｙｐｅ　ＩＤで指定することができる。図１５Ｃには、このＷｅｂＳｏｃｋｅｔ　Ｔｙｐｅ　ＩＤの一例を示している。

　また、図１５Ａ中の参照番号４４３で示すように、ソース機器４１０とシンク機器４２０間で、ＷｅｂＳｏｃｋｅｔのバイナリー・データとして画像データや音声データをやりとりする。

　例えば、ＦＩＮが０ｘ０のときは、ペイロードが続くため、シンク機器４２０は直前のデータと連結する。また、ＦＩＮが０ｘ１のときは、ペイロードが終了したフラグであるため、シンク機器４２０はペイロードの処理を行なう。

　また、例えば、ＲＳＶは、拡張ビットである。

　また、例えば、ｏｐｃｏｄｅが０ｘ０のときは、ペイロードが続くため、シンク機器４２０は直前のデータと連結する。また、ｏｐｃｏｄｅが０ｘ１のときは、ペイロードがテキストであり、ｏｐｃｏｄｅが０ｘ２のときは、ペイロードがバイナリーであることを意味する。

　また、例えば、ＭＡＳＫは、メッセージがエンコードされているかを示すビットである。なお、ソース機器４１０からシンク機器４２０へのメッセージは、常にエンコードされている。

　このように、ｏｐｃｏｄｅのバイナリーを用いると、ソース機器４１０とシンク機器４２０間で、ＷｅｂＳｏｃｋｅｔのバイナリー・データとして画像データや音声データのやりとりが可能となる。すなわち、ＷｅｂＳｏｃｋｅｔ規格フォーマットを用いて、画像データ及び音声データを伝送することができる。このため、事前認証を画像データや音声データで行なうことができる。また、それ以外の各種のユースケースに対応することができる。

　また、ソース機器とシンク機器間での画像データ及び音声データのやりとりを、Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔ規格の画像伝送を行ないつつ、ＷｅｂＳｏｃｋｅｔを利用しても行なうことができる。また、操作用メタデータのやりとりにＷｅｂＳｏｃｋｅｔを利用してもよい。

　このように、シンク機器としての情報処理装置３００の制御部３７０は、ＷｅｂＳｏｃｋｅｔを利用してソース機器から送信された画像情報及び音声情報を取得することができる。また、制御部３７０は、その画像情報に基づく画像を表示部３５１に表示させ、その音声情報に基づく音声を音声出力部３５２から出力させることができる。

　このように、第２の実施形態では、ソース機器のアクセシビリティー・モード用操作は、シンク機器で受け付けることができる。すなわち、ソース機器からの画像、音声、テキスト、操作用補助情報をシンク機器側の表示部又はスピーカーに表示する環境において、安定して動作させることができ、リアルタイム性がある接続制御の操作を行なうことができる。

　また、ソース機器における各画像の表示位置をリアルタイムでシンク機器に通知することで、ソース機器からアクセシビリティー・モード用メタデータによって、表示位置を制御することができる。また、ＵＩＢＣ及びＷｅｂＳｏｃｋｅｔを利用してアクセシビリティー・モード用メタデータの表示位置に関する情報のやりとりを同時に行なうことができる。

［第３の実施形態］
［通信システム構成］
　図１９には、本明細書で開示する技術の１つの実施形態に係る通信システムの構成例を模式的に示している。同図に示す通信システム１９００は、それぞれ無線通信機能を備える２台の情報処理装置２００、３００で構成され、これらの装置同士がＰ２Ｐダイレクト通信により無線接続を行なうことを想定している。具体的には、情報処理装置２００から送信されるデータ（例えば、画像データや音声データ）を情報処理装置３００が受信する。

　通信システム１９００を構成する情報処理装置２００、３００は、例えば、無線通信機能を備える表示装置（例えば、パーソナルコンピュータ）や携帯型の情報処理装置（例えば、スマートフォン、タブレット端末）である。また、情報処理装置２００、３００は、例えば、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１５、ＩＥＥＥ８０２．１６、３ＧＰＰ仕様（例えば、Ｗ－ＣＤＭＡ、ＧＳＭ（登録商標）、ＷｉＭＡＸ、ＷｉＭＡＸ２、ＬＴＥ、ＬＴＥ－Ａに準拠した無線通信装置である。そして、情報処理装置２００、３００は、無線通信機能を利用して各種情報のやりとりを行なうことができる。

　情報処理装置２００及び情報処理装置３００間で、例えば、Ｗｉ－Ｆｉ　Ｄｉｒｅｃｔ、ＴＤＬＳ、アドホック・ネットワーク、メッシュ・ネットワークなどの無線ＬＡＮを用いた無線通信を行なうことができる。

　また、通信システム１００に用いられる近距離無線ＡＶ伝送通信として、例えば、Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔ（前述）を用いることができる。Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔでは、ＴＣＰ／ＩＰ上でＵＩＢＣ（前述）を実現している。なお、Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔの代わりに、他のリモート・デスクトップ・ソフトウェア（例えば、ＶＮＣ）を適用するようにしてもよい。

　本実施形態に係る通信システム１００では、一方の情報処理装置２００をソース機器とし、他方の情報処理装置３００をシンク機器とする。例えば、情報処理装置２００の撮像動作により生成された画像データが情報処理装置３００に送信され、その画像データに基づく画像が情報処理装置３００で表示される。以下では、情報処理装置２００が撮像動作により生成された画像データ及び音声データを送信対象とする例や、情報処理装置２００がハード・ディスクなどの記憶装置に保存されているコンテンツ（例えば、画像データ及び音声データからなるコンテンツ）を送信対象とする例を示す。

　なお、情報処理装置２００として、カメラを搭載した電子機器（例えば、パソコン、ゲーム機、スマートフォン、タブレット端末）を用いるようにしてもよい。また、情報処理装置３００として、表示部を備える他の電子機器（例えば、撮像装置、ゲーム機、スマートフォン、タブレット端末）を用いるようにしてもよい。また、情報処理装置２００がテザリング機能を備える場合には、無線又は有線ネットワークを介してＩＳＰに保存されたコンテンツを送信対象とするようにしてもよい。

　また、図１９に示す通信システム１９００では、Ｐ２Ｐダイレクト接続により、無線通信を利用して情報処理装置３００が直接通信することができる範囲を情報伝達範囲１０１として示す。この情報伝達範囲１０１は、情報処理装置３００を基準とした場合における情報伝達範囲（サービス範囲）である。

　本実施形態に係る通信システム１９００において、ソース機器として動作する情報処理装置２００の機能的構成例は図２と同様であり、また、シンク機器として動作する情報処理装置３００の機能的構成は図３と同様である。ここでは、各情報処理装置２００、３００の機能的構成についての詳細な説明を省略する。また、本実施形態におけるソース機器４１０とシンク機器４２０間のＷｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔ仕様コマンドを用いた接続シーケンスも、図４と同様なので、ここでは詳細な説明を省略する。

［想定される接続形態］
　ソース機器としての情報処理装置２００とシンク機器としての情報処理装置３００がＰ２Ｐダイレクト通信により無線接続を行なう通信システム１００において、想定される接続形態を図２０～図２２に示す。

　図２０には、アクセシビリティー・モードのソース機器とアクセシビリティー・モードのシンク機器の間でやりとりする接続形態を示している。また、図２１には、通常モードのソース機器とアクセシビリティー・モードのシンク機器の間でやりとりする接続形態を示している。また、図２２には、アクセシビリティー・モードのソース機器と通常モードのシンク機器の間でやりとりする接続形態を示している。

　図２０に示す接続形態において、ソース機器とシンク機器のアクセシビリティー・モードの種別が一致していることを前提として、ソース機器とシンク機器間における通信処理について説明する。

　ソース機器がシンク機器へ伝送する映像や音声をソース機器が操作する場合、通常のコンテンツ・データの伝送の他に、アクセシビリティー・モード用メタデータとして、上記視覚サポート、聴覚サポート、身体機能（操作困難）サポートから現在設定されている情報を別途送信する。

　これに対し、シンク機器は、ソース機器からコンテンツ・データを受信すると同時に、アクセシビリティー・モード用メタデータを受信し、シンク機器内部の制御によって、適宜、最適な表示を行なう。

　一方、ソース機器から伝送する映像や音声をシンク機器が操作する場合、シンク機器は、上記閲覧保障性に対応した操作情報をそのままソース機器へ送信する。従来のＵＩＢＣと同等の機能であるが、閲覧保障性を考慮することで、ＵＩＢＣのデータ種別が、音声や映像やテキスト情報も含まれるもの（操作用メタデータ）とする。

　これに対し、ソース機器は、上記コンテンツ・データとアクセシビリティー・モード用メタデータをシンク機器へ送信するのとは別に、シンク機器から、シンク機器の操作情報をシンク機器のアクセシビリティー・モード用操作情報として受信し、受信した操作情報通りの動作を行なう。

　なお、操作者が接続中に変更した場合、通常モードとアクセシビリティー・モードを途中で変更するモード・エックスチェンジ用メッセージ信号を持ってもよい。例えば、ソース機器とシンク機器間でモード・エックスチェンジ用メッセージがやりとりされると、現在送受信中の無線映像伝送を切断させることなく、通常モードとアクセシビリティー・モード、又は、アクセシビリティー・モードの種別を変更することが可能となる。

　続いて、図２１又は図２２に示すように、ソース機器とシンク機器でモードが一致していないことを前提として、ソース機器とシンク機器間における通信処理について説明する。

　図２１に示す接続形態において、ソース機器がシンク機器へ伝送する映像や音声をソース機器が操作する場合、ソース機器は、操作によって作成された映像、音声、テキストを基に、シンク機器が操作可能なコンテンツ・メディアに変換してから送信を行なう。例えば、聴覚サポートのアクセシビリティー・モードの場合、ソース機器は、映画、ビデオ鑑賞コンテンツについては、字幕データをテキストとして送信し、音声の音量を調整したり、シンク機器側でも着信をＬＥＤフラッシュが実現できるよう、制御データをシンク機器へ伝送する処理を行なう。

　これに対し、シンク機器は、ソース機器からアクセシビリティー・モード用コンテンツ・データを受信し、適宜、最適な表示を行なう。

　これに対し、ソース機器は、上記コンテンツ・データをシンク機器へ送信するのとは別に、シンク機器から、シンク機器の操作情報をシンク機器のアクセシビリティー・モード用操作情報として受信すると、受信した操作情報を通常モードの操作用データとして変換して処理を行なう。

　なお、本実施形態に係る通信システム１００で可能な通信動作は上記に限らないものとする。例えば、上記説明では、ソース機器側でアクセシビリティー・モードに合ったデータとして送受信しているが、それに限らず、例えば、シンク機器側で通常モードに変換できるようにしてもよい。特に、操作用データはタップの扱いが異なるため、モードがソース機器とシンク機器間の異なる伝送ではタップの変換操作が必須となる。とりわけ、身体機能（操作困難）サポートにおいて、シンク機器の操作者がユーザー独自の操作を登録した場合、ソース機器では解釈できないため、シンク機器で通常モードでも理解できるように、タップやジェスチャー操作に切り替えて、伝送するのが適している。

　図２２には、アクセシビリティー・モードのソース機器と通常モードのシンク機器の間でやりとりする接続形態を示しているが、図２１に示した接続形態の場合と同様に変換処理が必要となる。

　図２２に示す接続形態において、ソース機器がシンク機器へ伝送する映像や音声をソース機器が操作する場合、ソース機器は、通常のコンテンツ・データの伝送を行なう。これに対し、シンク機器は、ソース機器からコンテンツ・データを受信すると、適宜、最適な表示を行なう。

　一方、ソース機器から伝送する映像や音声をシンク機器が操作する場合、シンク機器は、操作情報をそのままソース機器へ送信する。これに対し、ソース機器は、上記コンテンツ・データとアクセシビリティー・モード用メタデータをシンク機器へ送信するのとは別に、シンク機器から、シンク機器の操作情報を閲覧保障性に対応した操作情報に変換し、変換後の操作情報に従って動作を行なう。

　あるいは、ソース機器から伝送する映像や音声をシンク機器が操作する場合、シンク機器は、操作情報を閲覧保障性に対応した操作情報に変換した後に、ソース機器へ送信する。閲覧保障性に対応した操作情報は、従来のＵＩＢＣと同等の機能であるが、閲覧保障性を考慮することで、ＵＩＢＣのデータ種別が、音声や映像やテキスト情報も含まれるもの（操作用メタデータ）とする。これに対し、ソース機器は、上記コンテンツ・データとアクセシビリティー・モード用メタデータをシンク機器へ送信するのとは別に、シンク機器から、シンク機器の操作情報をシンク機器のアクセシビリティー・モード用操作情報として受信し、受信した操作情報通りの動作を行なう。

　図２１又は図２２に示した接続形態において、ソース機器は、通信相手であるシンク機器がアクセシビリティー・モードの場合、ポップアップ表示などを通じて、アクセシビリティー・モード用メタデータを生成する必要があることを当該ソース機器の操作者に通知するようにしてもよい。また、そのポップアップ表示などで、シンク機器に送信するアクセシビリティー・モード用メタデータのメディア種別を表示して、メタデータの変換を行なってよいかどうかを操作者に確認するようにしてもよい。

　また、シンク機器は、通信相手であるソース機器がアクセシビリティー・モードの場合、ポップアップ表示などを通じて、アクセシビリティー・モード用メタデータを再生する必要があることを当該シンク機器の操作者に通知するようにしてもよい。

　また、図２１や図２２に示すように、ソース機器とシンク機器のうちいずれか一方のみがアクセシビリティー・モードの場合には、ソース機器側から送信されるアクセシビリティー・モード用メタデータのメディア種別に対応するメディア再生機能がオフになっていることも想定される。このような場合、シンク機器において、ソース機器から送られてくるアクセシビリティー・モード用メタデータのメディア種別を表示して、メディア再生をオンにしてもよいかどうかを操作者に確認するようにしてもよい。

　図２０～図２２に示した接続形態において、ソース機器４１０は、シンク機器４２０がアクセシビリティー・モードに対応しているかどうかを確認するやりとりを行なっている。具体的にＭｉｒａｃａｓｔでの処理を用いて、シンク機器４２０がアクセシビリティー・モードに対応しているかどうかを確認する方法について、図７（前述）を参照しながら説明する。この方法によって、聴覚、視覚、身体機能（操作困難）のうちどのアクセシビリティー・モードが選択されているかをソース機器４１０側で判断できるかを確認することが可能となる。

　図７中の点線の矩形４３０内に示すように、シンク機器４２０は、ソース機器４１０からのＲＴＳＰＧＥＴ＿ＰＡＲＡＭＥＴＥＲＲｅｑｕｅｓｔに従って、シンク機器４２０側に設定しているアクセシビリティー能力を、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ　Ｒｅｓｐｏｎｓｅで返信している。図９では、このＧＥＴ＿ＰＡＲＡＭＥＴＥＲ　Ｒｅｓｐｏｎｓｅの返信内容の一例を示している。

　ソース機器４１０は、受信したアクセシビリティー能力（Ｃａｐａｂｉｌｉｔｙ情報）を基に、ソース機器４１０からシンク機器４２０に送信するためのメタデータを選択し、送信する。

　ソース機器４１０がシンク機器４２０とアクセシビリティー能力をやりとりするメッセージにおいて、Ｍｉｒａｃａｓｔ規格上で実現する場合のメッセージの一例として、上記の表１に挙げたものを使用するものとする。

　加えて、図２０から図２２に示す接続形態において、ソース機器とシンク機器間でモード又はアクセシビリティー・モードの種別が異なる場合、アクセシビリティー・モードの種別を変換し、機器間で操作方法を理解できるようにする。ソース機器とシンク機器のモード又はアクセシビリティー・モードの種別が異なる場合、機器間で操作方法を理解できるように、ソース機器又はシンク機器のいずれかでアクセシビリティー・モードの種別を変換するようにし、モードを一致させてもよい。

　図７に示した通信シーケンス中のＣａｐａｂｉｌｉｔｙ　ＮｅｇｏｔｉａｔｉｏｎのＲＴＳＰ　Ｍ３の各メッセージにおいて、図９のアクセシビリティー対応要求のビット・アサインが同時に立ち上がっているモードを、ソース機器４１０はシンク機器４２０が設定可能なアクセシビリティー・モードと判断する。具体的には、ビット０は、シンク機器４２０がアクセシビリティー・モードに対応している機器かどうかを示す。ビット［１４：１］はビット０が”１”（アクセシビリティー・モード　Ｏｎ）のときに各ビットが有効になり、ビット［４：１］はアクセシビリティー・モードの種別を示す。本ビット領域は、ビット［１４：５］の対応方法に含まれない操作が必要な場合、種別を示すことで、想定される操作用データを全て生成するなどの対応を可能させることができるが、すべての判断をビット［１４：５］で行ない、ビット［４：１］を省略してもよい。

　例えば、ビット０が”１”（アクセシビリティー・モード　Ｏｎ）の前提で、Ｓ６０１のメッセージでシンク機器４２０から示されるＷｆｄ－ａｃｃｅｓｓｉｂｉｌｉｔｙ－ｃａｐａｂｉｌｉｔｙ　Ｒｅｓｐｏｎｓｅ情報［１４：５］が０００００００１０１となった場合、１ビット目（図９に示すビット・アサインでは「視力なしで操作可能」に対応）と３ビット目（図９に示すビット・アサインでは「弱視且つ難聴で操作可能」に対応）が“１”になっている。アクセシビリティー・モード用メタデータとして、図８に対応動作例を示している。ソース機器４１０は、例えば、以下のような情報をアクセシビリティー・モード用メタデータとして生成可能かどうかを判断する。

　そして、ソース機器４１０は、上記２つのアクセシビリティー・モード用メタデータとのうちどちらかを生成可能と判断することができた場合、Ｗｆｄ－ａｃｃｅｓｓｉｂｉｌｉｔｙ－ｓｅｔｔｉｎｇとして、該当するアクセシビリティー・モードを設定するようにする。

　本実施形態に係る通信システム１９００では、図１０及び図１１（前述）に示した通信シーケンス例に従って、ソース機器４１０とシンク機器４２０間がアクセシビリティー・モードに対応しているかどうかを、接続時のＣａｐａｂｉｌｉｔｙＮｅｇｏｃｉａｔｉｏｎで確認して、アクセシビリティー・モードの設定のための通信処理を行なうことができる。また、アクセシビリティー・モード用メタデータ回線をＥｎａｂｌｅにすることで、各アクセシビリティー・モード種別におけるシンク機器の動作例は、図１２を参照しながら既に説明した通りである。

　図２３及び図２４には、ソース機器がアクセシビリティー・モード用メタデータ回線のＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎを開始し、ソース機器２００がシンク機器３００と映像伝送を開始するまでの動作手順をフローチャートの形式で示している。

　まず、ソース機器２００の制御部２４０は、シンク機器３００との間でＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎを開始する（ステップＳ８０２）。

　次いで、制御部２４０は、シンク機器３００との間で接続可能なアクセシビリティー・モードを確認した後、シンク機器３００にアクセシビリティー・モードでの動作を要求するか否かを判断する（ステップＳ８０３）。シンク機器３００にアクセシビリティー・モードでの動作を要求しない場合には（ステップＳ８０３のＮｏ）、ソース機器２００は、通常モードでシンク機器３００との通信を開始する（ステップＳ８０４）。

　一方、シンク機器３００にアクセシビリティー・モードでの動作を要求する場合には（ステップＳ８０３のＹｅｓ）、ソース機器２００は、シンク機器３００で対応可能なアクセシビリティー・モードの種別をさらに確認する（ステップＳ８０５）。アクセシビリティー・モードの種別を確認する必要がない、又は種別情報が含まれていない場合には（ステップＳ８０６のＮｏ）、アクセシビリティー・モードの中で最も優先度が高いモードが選択される。同図では、視覚サポート、聴覚障がい、操作困難の順で優先度が高いというケースを示しており、視覚サポートのモードが選択される。

　また、デフォルトのアクセシビリティー・モードを持ち、アクセシビリティー・モードの種別を確認する場合には（ステップＳ８０６のＹｅｓ）、ソース機器２００は、アクセシビリティー・モードの中で最も優先度が高いモードかどうかの確認を行なう。最も優先度が高いモードでない場合、その他のモードかどうかの確認をさらに行なう。同図では、視覚サポート、聴覚障がい、操作困難の順で優先度が高いというケースを示している。ソース機器２００は、シンク機器３００から受信したＣａｐａｂｉｌｉｔｙ情報に基づいてアクセシビリティー・モードが視覚サポートか、聴覚サポートか、身体（操作困難）サポートかを順に判断する（ステップＳ８０７、Ｓ８０９、Ｓ８１１）。

　アクセシビリティー・モードが視覚サポートの場合（ステップＳ８０７のＹｅｓ）、ソース機器２００は、アクセシビリティー・モード用メタデータとして、コンテンツ・メディア伝送に同期した音声の提供（例えば、アプリ内容の読み上げる処理）や、操作者がタップしたときに選択した選択されたアイコン名称を音声にて提供する処理をシンク機器へ伝送する（ステップＳ８０８）。なお、音声提供方法は、アクセシビリティー・モード用コンテンツ・メディアの音声の一部として提供することも、アクセシビリティー・モード用メタデータとして音声を挿入してもどちらでも良いものとする。

　また、アクセシビリティー・モードが聴覚サポートの場合（ステップＳ８０９のＹｅｓ）、ソース機器２００は、アクセシビリティー・モード用メタデータとして、コンテンツ・メディア伝送に同期した字幕の提供や、操作者がセットした音声通知をＬＥＤフラッシュに変換してシンク機器へ伝送する（ステップＳ８１０）。映画、ビデオ、Ｐｏｄｃａｓｔを視聴するときは、字幕表示に変更する。なお、字幕やＬＥＤフラッシュの提供方法は、アクセシビリティー・モード用コンテンツ・メディアのメタデータの一部として提供することも、アクセシビリティー・モード用メタデータとして提供してもどちらでも良いものとする。

　また、アクセシビリティー・モードが身体（操作困難）サポートの場合（ステップＳ８１１のＹｅｓ）、ソース機器２００は、独自に作ったジェスチャー操作のデータを、シンク機器３００が理解できるポインティングへ変換した後、シンク機器３００へ送信する処理を行なう（ステップＳ８１２）。

　ステップＳ８１３は本動作フローを終了するステップである。なお、図２３及び図２４に示したフローチャートでは、視覚障がい、聴覚障がい、身体（操作困難）についてのアクセシビリティー・モード用メタデータに変換していたが、それだけに限らない。例えば、図８に示した対応動作をアクセシビリティー・モード用メタデータとして変更するようにしてもよい。

　なお、ソース機器２００とシンク機器３００間において、端末のモード又はアクセシビリティー・モードの種別が異なる場合には、ソース機器２００又はシンク機器３００でアクセシビリティー・モードの種別を変換するようにし、モードを一致させてもよい。

　上記のステップＳ８０８、Ｓ８１０、Ｓ８１２などにおいて、ソース機器２００は、通信相手であるシンク機器３００がアクセシビリティー・モードの場合、ポップアップ表示などを通じて、アクセシビリティー・モード用メタデータを生成する必要があることを当該ソース機器２００の操作者に通知するようにしてもよい。また、そのポップアップ表示などで、シンク機器に送信するアクセシビリティー・モード用メタデータのメディア種別を表示して、メタデータの変換を行なってよいかどうかを操作者に確認するようにしてもよい。

　また、シンク機器３００は、通信相手であるソース機器２００がアクセシビリティー・モードの場合、ポップアップ表示などを通じて、アクセシビリティー・モード用メタデータを再生する必要があることを当該シンク機器３００の操作者に通知するようにしてもよい。

　また、ソース機器２００とシンク機器３００のうちいずれか一方のみがアクセシビリティー・モードの場合には、ソース機器２００側から送信されるアクセシビリティー・モード用メタデータのメディア種別に対応するメディア再生機能がオフになっていることも想定される。このような場合、シンク機器３００において、ソース機器３００から送られてくるアクセシビリティー・モード用メタデータのメディア種別を表示して、メディア再生をオンにしてもよいかどうかを操作者に確認するようにしてもよい。

　このように、情報処理装置（ソース機器）２００の無線通信部２２０は、Ｗｉ－Ｆｉ　ＣＥＲＴＩＦＩＥＤ　Ｍｉｒａｃａｓｔ仕様に従ってシンク機器３００との間でリアルタイム画像伝送を行なう。また、制御部２４０は、ソース機器２００から送信された画像情報に基づく画像を表示部（図２では省略）に表示させ、その画像に関するアクセシビリティー・モード用メタデータをシンク機器３００との間でやりとりするための複数の通信方式（ＵＩＢＣ、ＷｅｂＳｏｃｋｅｔ）に使用されるポートでの制御を行なう。この場合に、例えば、制御部２４０は、シンク機器３００との間で生成されたＴＣＰセッション上でポートを設定する場合に、ポートを使用する複数の通信方式を指定する情報（例えば、図１５（後述）で説明する各情報）をシンク機器に送信する。

　また、制御部２４０は、複数の通信方式に使用されるポートとして複数の通信方式毎に複数のポートを設定することができる。この場合には、制御部２４０は、ソース機器からの要求に応じて複数のポートを設定することができる。

　また、例えば、情報処理装置２００の制御部２４０は、シンク機器３００側の表示部に画像を表示させるための画像情報をシンク機器３００に送信する。また、制御部２４０は、その画像に関する制御情報をシンク機器３００との間でやりとりするための複数の通信方式に使用されるポートを設定する制御を行なうことができる。

　また、シンク機器３００は、ソース機器２００からの要求に基づいて、シンク機器３００の表示位置に関する情報を伝送するため、接続途中、ＵＩＢＣの制御チャネルを、要求があったソース機器２００に切り替えることもできる。また、ソース機器２００は、シンク機器３００からの操作により、ソース機器２００の表示位置情報を伝送するため、接続途中、ＵＩＢＣの制御チャネルを、要求があったシンク機器３００に切り替えることもできる。

　なお、本実施形態に係る通信システム１９００では、アクセシビリティー・モード用メタデータ回線として、ＷｅｂＳｏｃｋｅｔの制御回線を用いて、画像データや音声データ、テキスト・データを送受信することも可能である。例えば、図１５Ａに示した通信シーケンス（前述）に従って、ソース機器４１０とシンク機器４２０間のＷｅｂＳｏｃｋｅｔを用いた画像データ及び音声データの通信処理を実施することが可能である。この通信シーケンスでは、図１５Ｂ及び図１５Ｃに示したＷｅｂＳｏｃｋｅｔのフレーム・フォーマット（前述）を用いて、ソース機器４１０とシンク機器４２０間でやりとりされる。

　ｏｐｃｏｄｅのバイナリーを用いると、ソース機器４１０とシンク機器４２０間で、ＷｅｂＳｏｃｋｅｔのバイナリー・データとして画像データや音声データのやりとりが可能となる。すなわち、ＷｅｂＳｏｃｋｅｔ規格フォーマットを用いて、画像データ及び音声データを伝送することができる。このため、事前認証を画像データや音声データで行なうことができる。また、それ以外の各種のユースケースに対応することができる（同上）。

　このように、本実施形態では、ソース機器のアクセシビリティー・モード用操作は、シンク機器で受け付けることができる。すなわち、ソース機器からの画像、音声、テキスト、操作用補助情報をシンク機器側の表示部又はスピーカーに表示する環境において、安定して動作させることができ、リアルタイム性がある接続制御の操作を行なうことができる。

　上記の説明では、ソース機器とシンク機器間でＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎによって、アクセシビリティー・モード種別を判断していたが、その他でもよい。例えば、Ｄｅｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙ又はＳｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙを用いてもよい。Ｄｅｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙ又はＳｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙの制御方法として、以下の（Ｃ１）～（Ｃ４）のいずれか１つ以上のやりとりを行なう。

（Ｃ１）Ｐ２Ｐ　ＩＥ（ＩｎｆｏｒｍａｔｉｏｎＥｌｅｍｅｎｔ）
（Ｃ２）ＷＦＤ　ＩＥ（Ｉｎｆｏｒｍａｔｉｏｎ　Ｅｌｅｍｅｎｔ）
（Ｃ３）ＡＳＰ（ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｉｃｅＰｌａｔｆｏｒｍ）
（Ｃ４）ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ　Ｐｌｕｇ　ａｎｄ　Ｐｌａｙ）標準でのプロトコル

　Ｄｅｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙ又はＳｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙの制御方法の一例について、図２５を参照しながら説明しておく。

　情報処理装置７１０（ソース機器）は、Ｐｒｏｂｅ　Ｒｅｑｕｅｓｔを送信して、Ｐ２Ｐ接続可能な情報処理装置７２０（シンク機器）をサーチする。例えば、情報処理装置７２０（シンク機器）がＰ２Ｐ接続可能な装置である場合には、Ｐｒｏｂｅ　Ｒｅｓｐｏｎｓｅを受信することにより、Ｐ２Ｐ接続で使用する周波数チャネルを検出することが可能となる。ここでは、情報処理装置７２０（シンク機器）がＰ２Ｐ接続可能な機器であることを想定し、Ｐｒｏｂｅ　Ｒｅｓｐｏｎｓｅを受信できたことを前提にして説明する。

　上述した処理によって、図２５において、情報処理装置７１０（ソース機器）は、情報処理装置７２０（シンク機器）とＰ２Ｐ接続するための周波数チャネルを把握し、Ｐ２Ｐ接続のコネクションを確立する。そして、Ｐ２Ｐ接続のコネクションを確立した後、情報処理装置７１０（ソース機器）は、情報処理装置７２０（シンク機器）とＴＣＰコネクション又はＲＴＳＰコネクションのリンクをさらに確立した後に、上述した（Ｃ１）乃至（Ｃ４）の何れか１つ以上のやりとりを行なう。

　ここでは、Ｐｒｏｂｅ　ＲｅｑｕｅｓｔやＰｒｏｂｅ　Ｒｅｓｐｏｎｓｅのペイロード部分にＷＦＤ　ＩＥをカプセル化させ、やりとりする方法について説明する。

　図２６～図３０には、上述した（Ｃ２）のＷＦＤＩＥを用いたフォーマット例を示している。このうち図２６乃至図２８は、既にＭｉｒａｃａｓｔ　Ｒｅｌｅａｓｅ１で割り当てられているフォーマットである。但し、図２８に示すＳｕｂｅｌｅｍｅｎｔＩＤ（１１）に、新規のビットを割り当てる。具体的には、このＳｕｂｅｌｅｍｅｎｔＩＤ（１１）に対応する新規Ｆｉｅｌｄについては、図２９、図３０に示す。

　図２８において、Ｎｅｗ　Ｄｅｖｉｃｅ　Ｉｎｆｏｒｍａｔｉｏｎフィールドの［５：０］は、情報処理装置７２０（シンク機器）がＰ２Ｐ接続において、最適な周波数チャネルを判断するための情報である。

　上述した（Ｃ１）乃至（Ｃ３）のいずれか１つを用いたシーケンスの過程で、情報処理装置７１０（ソース機器）は、各情報を把握することにより、情報処理装置７２０（シンク機器）とのＰ２Ｐ接続において、最適な周波数チャネルを判断することができる。例えば、アクセスポイント７０１（図示しない）及び情報処理装置７２０（シンク機器）間のアソシエイトされた周波数情報（図３０に示す［２３：１４］のフィールド）を用いることができる。また、例えば、情報処理装置７２０（シンク機器）の無線回線のコンカレント情報（図３０に示す［５：２］のフィールド）を用いることができる。このコンカレント情報は、例えば、同じ周波数チャネルの時分割接続、違う周波数チャネルの時分割接続、同じ周波数チャネルの同時接続、違う周波数チャネルの同時接続等の接続形態が可能か否かを示す情報である（図３０に示す［５：２］のフィールド）。また、例えば、無線機能としての端末能力（図２１に示す［１３：８］のフィールド）を用いることができる。

　また、アクセスポイント７０１が外部にあり、情報処理装置７１０（ソース機器）は、アクセスポイント７０１経由で情報処理装置７２０（シンク機器）と通信を行なう可能性もある。その場合、アクセスポイント７０１と情報処理装置７２０（シンク機器）間がＥｔｈｅｒｎｅｔ（登録商標）ケーブルやＵＳＢケーブル・コネクタのように有線接続又はコネクタ接続されている場合もある。こういったトポロジにも対応するため、情報処理装置７２０（シンク機器）が、アクセスポイント７０１との接続が有線であること（図３０に示す［１：０］）と、Ｐ２Ｐ接続用無線を備えるか否かを情報処理装置７１０（ソース機器）に通知する。これにより、情報処理装置７１０（ソース機器）は、最適な周波数チャネルを判断することができる。例えば、情報処理装置７２０（シンク機器）が、有線回線にのみ対応する場合には、Ｐ２Ｐ接続へ移行せずにそのままアクセスポイント７０１と接続する。一方、情報処理装置７２０（シンク機器）が、無線回線にも対応する場合には、サポートする周波数チャネルの１つを選択して接続することが可能である。

　以上が、Ｐｒｏｂｅ　ＲｅｑｕｅｓｔやＰｒｏｂｅ　Ｒｅｓｐｏｎｓｅのペイロード部分にＷＦＤ　ＩＥをカプセル化させた例であるが、本明細書で開示する技術はこれに限定されない。

　例えば、Ｗｉ－Ｆｉ　Ｄｉｒｅｃｔ　ＳｅｒｖｉｃｅｓのＤｉｓｐｌａｙＳｅｒｖｉｃｅを使う場合には、ＡＳＰ準拠のメッセージを介してデバイス間でＳｅｒｖｉｃｅ　Ｃａｐａｂｉｌｉｔｙ情報を交換することができる。具体的には、ＷＦＤ　ＩＥに含まれる情報を、４ビット毎に区切って１６進数にしたものをｔｅｘｔ　ｓｔｒｉｎｇとしたものを送受信する。さらに、ＷＦＤ　ＩＥに含まれる情報は現時点の仕様に限らない。例えば、図３１に示すＳｅｒｖｉｃｅＣａｐａｂｉｌｉｔｙ情報をＡＳＰメッセージ中のペイロードに含むようにしてもよい。

　なお、アソシエイトされた周波数情報、デバイスのコンカレント情報のネゴシエーションは、Ｄｅｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙ又はＳｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙの処理の一貫として行なうようにしてもよい。また、アソシエイトされた周波数情報、デバイスのコンカレント情報のネゴシエーションは、伝送途中に周波数チャネル変更が必要な際に再ネゴシエーションしてもよい。さらに、ネゴシエーションの開始時に、上述した（Ｃ１）乃至（Ｃ４）のいずれのやりとりが可能かを、情報処理装置７１０（ソース機器）及び情報処理装置７２０（シンク機器）間でネゴシエーションし、どの方法で情報のやりとりを行なうかを選択するようにしてもよい。

　また、上述した各処理では、情報処理装置７１０（ソース機器）は、Ｐｒｏｂｅ　Ｒｅｓｐｏｎｓｅを受信した後、Ｐ２Ｐ接続リンクのＴＣＰコネクション又はＲＴＳＰコネクションをさらに確立した後に上述した（Ｃ１）～（Ｃ４）を行なう例を示した。但し、Ｐ２Ｐ接続リンクを確立する前に、アクセスポイント７０１を経由して、情報処理装置７１０（ソース機器）及び情報処理装置７２０（シンク機器）が接続されたＴＣＰコネクション又はＲＴＳＰコネクションを用いて、ＷＦＤ　ＩＥを含むＰｒｏｂｅ　ＲｅｑｕｅｓｔとＰｒｏｂｅ　Ｒｅｓｐｏｎｓｅのやりとりを行なうようにしてもよい。また、この例では、情報処理装置７１０（ソース機器）が主導して行なう例を示したが、情報処理装置７２０（シンク機器）が主導して行なうようにしてもよい。

　また、上述した各処理にかかわらず、上述したＰｒｏｂｅ　ＲｅｑｕｅｓｔにＰ２Ｐ接続するための周波数が記載されており、情報処理装置７２０（シンク機器）からのＰｒｏｂｅ　Ｒｅｓｐｏｎｓｅを返信する周波数チャネルはＰｒｏｂｅ　Ｒｅｑｕｅｓｔが使用した周波数チャネルでなくてもよい。また、受信はＰ２Ｐ接続経由で行なうようにしてもよい。

　以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

　本明細書で開示する技術によれば、マルチシンク・トポロジー環境において、ソース機器は、複数のシンク機器のモードを管理し、ケースによっては一致させる要求を行なうことで、アクセシビリティー・モード用メタデータの伝送を効果的に行なうことができる。

　また、モード変更時に、事前に操作者へモード変更確認を行なうことで、操作変更を操作者が理解でき、モード変更に伴う操作違いを極力操作者が把握できるようにすることができる。

　また、本明細書で開示する技術によれば、マルチシンク・トポロジー環境において、ソース機器は、複数のシンク機器のモードの調停を行なうことで、各端末が自端末のモードとの管理、やりとりを最低限に済ませることができる。

　また、本明細書で開示する技術によれば、マルチキャスト・パケット又はユニキャスト・パケットを用いた、帯域制御を行なうことができる。

　また、本明細書で開示する技術によれば、マルチシンク・トポロジー環境において、ソース機器は、シンク機器のデータ変換を最小限に抑えることができる。

　また、本明細書で開示する技術によれば、シンク機器を操作する操作者が障がい者であっても、シンク機器からソース機器を操作できるモード選択ＵＩを設けて、リモート操作をすることができる。

　また、本明細書で開示する技術によれば、マルチソース・トポロジー環境において、操作方法が異なるソース機器との接続を行なう際に、シンク機器からの共通操作から、ソース機器毎の変換処理を行ない、リモート操作を行なうことができる。

　また、本明細書で開示する技術によれば、接続中のソース機器又はシンク機器の操作者が変更した場合でも、初期動作に戻ることなく、効率良い動作を行なうことができる。マルチソース・トポロジー環境において、シンク機器は、複数のソース機器のモードを一致させるよう、Ｃａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ管理を行なうことができる。

　また、本明細書で開示する技術は、それぞれソース機器並びにシンク機器として動作する情報処理装置同士がＰ２Ｐダイレクト通信により無線接続を行ない、画像伝送を行なうさまざまなタイプの通信システムに適用することができる。

　このような通信システムにおいて、ソース機器がシンク機器の現在の動作モードを把握することにより、画像伝送を行なうコンテンツ・メディアに影響されることなく、適切なアクセシビリティー・モード用操作メタデータを選択し送信することが可能となる。

　また、ソース機器とシンク機器が接続前のやりとりで把握することで、伝送が必要ないメディアをオフにすることで、帯域を効率的に使用することができる。

　また、相手端末の操作者に通知する手段を設けることで、操作者が次端末の設定を変更することができる。

　また、操作者が変更した環境でも、初期動作に戻ることなく、効率良い動作を行なうことができる。

　要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。

　なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）複数のシンク機器との間でソース機器として無線通信する無線通信部と、
　前記シンク機器との接続並びに前記シンク機器へのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記複数のシンク機器はそれぞれ、通常モードと、操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、前記複数のシンク機器のアクセシビリティー・モードの種別を管理する、
情報処理装置。
（２）前記制御部は、前記複数のシンク機器のアクセシビリティー・モードの調停を行なってから、コンテンツ・データの伝送を開始させる、
上記（１）に記載の情報処理装置。
　上記（１）又は（２）に記載の情報処理装置は、マルチシンク・トポロジー環境において、複数のシンク機器のモードを管理し、ケースによっては一致させる要求を行なうことで、アクセシビリティー・モード用メタデータの伝送を効果的に行なうことができる。
（３）前記制御部は、アクセシビリティー・モードへ変更するシンク機器に対し、操作者へ変更が問題ないかを確認するポップアップを表示させる、
上記（２）に記載の情報処理装置。
　上記（３）に記載の情報処理装置によれば、モード変更時、事前に操作者へモード変更確認を行なうことで、操作変更を操作者が理解でき、モード変更に伴う操作違いを極力ユーザーが把握できることができる。
（４）前記制御部は、アクセシビリティー・モードのシンク機器と接続することを把握し、これから接続するアクセシビリティー・モード種別の論理和をとった結果に基づいて、必要なアクセシビリティー・モード用メタデータを送信させる、
上記（１）に記載の情報処理装置。
　上記（４）に記載の情報処理装置によれば、マルチシンク・トポロジー環境において、複数のシンク機器のモードの調停を行ない、各端末が自端末のモードとの管理、やりとりを最低限に済ませることができる。
（５）前記制御部は、アクセシビリティー・モード用メタデータをマルチキャスト・パケット又はユニキャスト・パケットのうちいずれかで送信させる、
上記（４）に記載の情報処理装置。
（６）前記制御部は、前記複数のシンク機器を同じアクセシビリティー・モード種別毎にグループ化して、グループ毎に対応したアクセシビリティー・モード用メタデータを送信させる、
上記（１）に記載の情報処理装置。
　上記（６）に記載の情報処理装置によれば、シンク機器のデータ変換を最小限に抑えることができる。
（７）前記制御部は、アクセシビリティー・モード用メタデータをマルチキャスト・パケット又はユニキャスト・パケットのうちいずれかで送信させる、
上記（６）に記載の情報処理装置。
（８）ソース機器との間でシンク機器として無線通信する無線通信部と、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記制御部は、前記ソース機器から受信した複数のアクセシビリティー・モード用メタデータのうち再生可能なメタデータのみを抽出して再生処理する、
情報処理装置。
（９）他のソース機器とともに同じシンク機器に対してソース機器として無線通信する無線通信部と、
　前記シンク機器との接続並びに前記シンク機器へのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記シンク機器は通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、アクセシビリティー・モードで接続することを前記シンク機器に通知させる、
情報処理装置。
　上記（９）に記載の情報処理装置によれば、シンク機器を操作する操作者が障がい者であっても、シンク機器からソース機器を操作できるＵＩを設けることができる。
（１０）複数のソース機器との間でシンク機器として無線通信する無線通信部と、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御部と、
　アクセシビリティー向けの操作と通常向けの操作のいずれかを選択するユーザー・インターフェース部と、
を具備する情報処理装置。
　上記（１０）に記載の情報処理装置によれば、シンク機器を操作する操作者が障がい者であっても、シンク機器からソース機器を操作できるＵＩを設けることができる。
（１１）複数のソース機器との間でシンク機器として無線通信する無線通信部と、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記複数のソース機器はそれぞれ、通常モードと、操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、前記複数のソース機器へＵＩＢＣデータを送信させる、
情報処理装置。
（１２）前記制御部は、ソース機器毎のモードに合うようにＵＩＢＣデータを変換した後に送信させる、
上記（１１）に記載の情報処理装置。
（１３）前記制御部は、ソース機器のモードに拘わらずＵＩＢＣデータを送信させる、
上記（１１）に記載の情報処理装置。
（１４）前記制御部は、すべての機器が切り替え可能な共通のモードに切り替えた後にＵＩＢＣデータを送信させる、
上記（１１）に記載の情報処理装置。
　上記（１１）乃至（１４）に記載の情報処理装置によれば、操作方法が異なるソース機器との接続においても、シンク機器からの共通操作から、ソース機器ごとの変換処理を行い、リモート操作を行なうことができる。
（１５）他のソース機器とともに同じシンク機器に対してソース機器として無線通信する無線通信部と、
　前記シンク機器との接続並びに前記シンク機器へのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記シンク機器は通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、操作者が接続中にシンク機器のモードを変更した場合、通常モードとアクセシビリティー・モードを途中で変更するモード・エックスチェンジ用メッセージ信号を伝送途中で送信させる、
情報処理装置。
　上記（１５）に記載の情報処理装置によれば、操作者が変更した環境でも、初期動作に戻ることなく、効率良い動作を行なうことができる。
（１６）複数のソース機器との間でシンク機器として無線通信する無線通信部と、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記複数のソース機器はそれぞれ、通常モードと、操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、前記複数のソース機器のアクセシビリティー・モードを一致するよう、各ソース機器へ要求させる、
情報処理装置。
　上記（１６）に記載の情報処理装置によれば、マルチソースにおいて、シンク機器は、複数のソース機器のモードを一致させるよう、Ｃａｐａｂｉｌｉｔｙ　　Ｎｅｇｏｔｉａｔｉｏｎ管理を行なうことができる。
（１７）複数のソース機器との間でシンク機器として無線通信する無線通信部と、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記複数のソース機器はそれぞれ、通常モードと、操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、アクセシビリティー・モードのソース機器と接続することを把握し、これから接続するアクセシビリティー・モード種別の論理和をとった結果に基づいてソース機器に送信させる、
情報処理装置。
　上記（１７）に記載の情報処理装置によれば、マルチソースにおいて、シンク機器は、複数のソース機器のモードを一致させるよう、Ｃａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ管理を行なうことができる。
（１８）複数のシンク機器との間でソース機器として無線通信する無線通信ステップと、
　前記シンク機器との接続並びに前記シンク機器へのコンテンツ・データの伝送を制御する制御ステップと、
を有し、
　前記複数のシンク機器はそれぞれ、通常モードと、操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御ステップでは、前記複数のシンク機器のアクセシビリティー・モードの種別を管理する、
無線通信方法。
（１９）複数のソース機器との間でシンク機器として無線通信する無線通信ステップと、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御ステップと、
を有し、
　前記複数のソース機器はそれぞれ、通常モードと、操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御ステップでは、前記複数のソース機器へＵＩＢＣデータを送信させる、
無線通信方法。
（２０）他のソース機器とともに同じシンク機器に対してソース機器として無線通信する無線通信ステップと、
　前記シンク機器との接続並びに前記シンク機器へのコンテンツ・データの伝送を制御する制御ステップと、
を有し、
　前記シンク機器は通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御ステップでは、操作者が接続中にシンク機器のモードを変更した場合、通常モードとアクセシビリティー・モードを途中で変更するモード・エックスチェンジ用メッセージ信号を伝送途中で送信させる、
無線通信方法。
（２１）通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能なシンク機器と、ソース機器として無線通信する無線通信部と、
　コンテンツ・データを前記シンク機器に前記無線通信部を介して送信するコンテンツ送信部と、
　アクセシビリティー・モードで動作する前記シンク機器に、前記シンク機器の操作者において操作可能なメタデータを、前記無線通信部を介して送信するメタデータ送信部と、
を具備する情報処理装置。
（２２）前記メタデータ送信部は、メタデータ送信用のチャネルを用いてメタデータの送信を行なう、
上記（２１）に記載の情報処理装置。
（２３）通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能なシンク機器と、ソース機器として無線通信する無線通信部と、
　コンテンツ・データを前記シンク機器に前記無線通信部を介して送信するコンテンツ送信部と、
　前記シンク機器の動作モードを、前記無線通信部を介して確認するモード確認部と、
　アクセシビリティー・モードで動作する前記シンク機器に、前記シンク機器の操作者において操作可能なメタデータを、前記無線通信部を介して送信するメタデータ送信部と、
を具備する情報処理装置。
（２４）前記モード確認部は、ＭｉｒａｃａｓｔプロトコルにおけるＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ、Ｄｅｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙ、又は、Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙのうちいずれか１つ以上の処理を用いて前記シンク機器が対応しているアクセシビリティー・モード種別を確認する、
上記（２３）に記載の情報処理装置。
（２５）前記シンク機器がサポートするアクセシビリティー・モード種別に応じてメタデータを変換するメタデータ変換部をさらに備える、
上記（２３）または（２４）のいずれかに記載の情報処理装置。
（２６）前記シンク機器がアクセシビリティー・モードの場合に、メタデータを生成する必要があることを前記情報処理装置の操作者に通知する通知部をさらに備える、
上記（２３）乃至（２５）のいずれかに記載の情報処理装置。
（２７）前記通知部は、前記シンク機器へ送信するメタデータのメディア種別を表示し、メタデータを変換してもよいかどうかを操作者に確認を促す、
上記（２６）に記載の情報処理装置。
（２８）前記シンク機器とアクセシビリティー・モードの種別が異なる場合に前記シンク機器とモードを一致させるモード制御部をさらに備える、
上記（２３）乃至（２７）のいずれかに記載の情報処理信装置。
（２９）操作者が前記シンク機器と接続中にモードを変更した場合、通常モードとアクセシビリティー・モードを途中で変更するモード・エックスチェンジ用メッセージ信号を前記コンテンツ送信部によるコンテンツの伝送途中で送信させるメッセージ送信部をさらに備える、
上記（２３）乃至（２８）のいずれかに記載の情報処理装置。
（３０）通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能なソース機器と、シンク機器として無線通信する無線通信部と、
　前記ソース機器から伝送されるコンテンツ・データを、前記無線通信部を介して受信するコンテンツ受信部と、
　前記無線通信部を介して、前記ソース機器との間で動作モードを確認するモード確認部と、
　アクセシビリティー・モードで動作する操作者において操作可能なメタデータを、前記無線通信部を介して前記ソース機器から受信するメタデータ受信部と、
を具備する情報処理装置。
（３１）前記情報処理装置自身がサポートするアクセシビリティー・モード種別に応じてメタデータを変換するメタデータ変換部をさらに備える、
上記（３０）に記載の情報処理装置。
（３２）前記ソース機器がアクセシビリティー・モードの場合に、メタデータを再生する必要があることを前記情報処理装置の操作者に通知する通知部をさらに備える、
上記（３０）又は（３１）のいずれかに記載の情報処理装置。
（３３）前記ソース機器とアクセシビリティー・モードの種別が異なる場合に前記ソース機器とモードを一致させるモード制御部をさらに備える、
上記（３０）乃至（３２）のいずれかに記載の情報処理装置。
（３４）前記ソース機器から受信するメタデータのメディア種別を表示し、現在オフしているメディア再生をオンにしてよいか否かを操作者に確認する再生確認部をさらに備える、
上記（３０）乃至（３３）のいずれかに記載の情報処理装置。
（３５）操作者が前記ソース機器と接続中にモードを変更した場合、通常モードとアクセシビリティー・モードを途中で変更するモード・エックスチェンジ用メッセージ信号を前記ソース機器からのコンテンツの伝送途中で受信するメッセージ受信部をさらに備える、
上記（３０）乃至（３５）のいずれかに記載の情報処理装置。
（３６）通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能なシンク機器と、ソース機器として無線接続する無線接続ステップと、
　前記シンク機器にコンテンツ・データを送信するコンテンツ送信ステップと、
　アクセシビリティー・モードで動作する前記シンク機器に、前記シンク機器の操作者において操作可能なメタデータを送信するメタデータ送信ステップと、
を有する無線通信方法。
（３７）通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能なシンク機器と、ソース機器として無線接続する無線接続ステップと、
　前記シンク機器にコンテンツ・データを送信するコンテンツ送信ステップと、
　前記シンク機器の動作モードを確認するモード確認ステップと、
　アクセシビリティー・モードで動作する前記シンク機器に、前記シンク機器の操作者において操作可能なメタデータを送信するメタデータ送信ステップと、
を有する無線通信方法。
（３８）通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能なソース機器と、シンク機器として無線接続する無線接続ステップと、
　前記ソース機器から伝送されるコンテンツ・データを受信するコンテンツ受信ステップと、
　前記ソース機器との間で動作モードを確認するモード確認ステップと、
　アクセシビリティー・モードで動作する操作者において操作可能なメタデータを前記ソース機器から受信するメタデータ受信ステップと、
を有する無線通信方法。

　１００…通信システム、１０１…情報伝達範囲
　２００…情報処理装置、２１０…アンテナ
　２２０…無線通信部、２３０…制御信号受信部
　２４０…制御部、２５０…画像・音声信号生成部
　２６０…画像・音声圧縮部、２７０…ストリーム送信部
　３００…情報処理装置、３１０…アンテナ
　３２０…無線通信部、３３０…ストリーム受信部
　３４０…画像・音声展開部、３５０…画像・音声出力部
　３５１…表示部、３５２…音声出力部
　３６０…ユーザー情報取得部、３７０…制御部
　３８０…制御信号送信部、３９０…管理情報保持部
　１１００…通信システム
　１２００、１３００、１４００…情報処理装置
　１３５１…表示部、１３６１…撮像部

Claims

　複数のシンク機器との間でソース機器として無線通信する無線通信部と、
　前記シンク機器との接続並びに前記シンク機器へのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記複数のシンク機器はそれぞれ、通常モードと、操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、前記複数のシンク機器のアクセシビリティー・モードの種別を管理する、
情報処理装置。
　前記制御部は、前記複数のシンク機器のアクセシビリティー・モードの調停を行なってから、コンテンツ・データの伝送を開始させる、
請求項１に記載の情報処理装置。
　前記制御部は、アクセシビリティー・モードへ変更するシンク機器に対し、操作者へ変更が問題ないかを確認するポップアップを表示させる、
請求項２に記載の情報処理装置。
　前記制御部は、アクセシビリティー・モードのシンク機器と接続することを把握し、これから接続するアクセシビリティー・モード種別の論理和をとった結果に基づいて、必要なアクセシビリティー・モード用メタデータを送信させる、
請求項１に記載の情報処理装置。
　前記制御部は、アクセシビリティー・モード用メタデータをマルチキャスト・パケット又はユニキャスト・パケットのうちいずれかで送信させる、
請求項４に記載の情報処理装置。
　前記制御部は、前記複数のシンク機器を同じアクセシビリティー・モード種別毎にグループ化して、グループ毎に対応したアクセシビリティー・モード用メタデータを送信させる、
請求項１に記載の情報処理装置。
　前記制御部は、アクセシビリティー・モード用メタデータをマルチキャスト・パケット又はユニキャスト・パケットのうちいずれかで送信させる、
請求項６に記載の情報処理装置。
　ソース機器との間でシンク機器として無線通信する無線通信部と、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記制御部は、前記ソース機器から受信した複数のアクセシビリティー・モード用メタデータのうち再生可能なメタデータのみを抽出して再生処理する、
情報処理装置。
　他のソース機器とともに同じシンク機器に対してソース機器として無線通信する無線通信部と、
　前記シンク機器との接続並びに前記シンク機器へのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記シンク機器は通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、アクセシビリティー・モードで接続することを前記シンク機器に通知させる、
情報処理装置。
　複数のソース機器との間でシンク機器として無線通信する無線通信部と、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御部と、
　アクセシビリティー向けの操作と通常向けの操作のいずれかを選択するユーザー・インターフェース部と、
を具備する情報処理装置。
　複数のソース機器との間でシンク機器として無線通信する無線通信部と、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記複数のソース機器はそれぞれ、通常モードと、操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、前記複数のソース機器へＵＩＢＣデータを送信させる、
情報処理装置。
　前記制御部は、ソース機器毎のモードに合うようにＵＩＢＣデータを変換した後に送信させる、
請求項１１に記載の情報処理装置。
　前記制御部は、ソース機器のモードに拘わらずＵＩＢＣデータを送信させる、
請求項１１に記載の情報処理装置。
　前記制御部は、すべての機器が切り替え可能な共通のモードに切り替えた後にＵＩＢＣデータを送信させる、
請求項１１に記載の情報処理装置。
　他のソース機器とともに同じシンク機器に対してソース機器として無線通信する無線通信部と、
　前記シンク機器との接続並びに前記シンク機器へのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記シンク機器は通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、操作者が接続中にシンク機器のモードを変更した場合、通常モードとアクセシビリティー・モードを途中で変更するモード・エックスチェンジ用メッセージ信号を伝送途中で送信させる、
情報処理装置。
　複数のソース機器との間でシンク機器として無線通信する無線通信部と、
　前記ソース機器との接続並びに前記ソース機器からのコンテンツ・データの伝送を制御する制御部と、
を具備し、
　前記複数のソース機器はそれぞれ、通常モードと、操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能であり、
　前記制御部は、前記複数のソース機器のアクセシビリティー・モードを一致するよう、各ソース機器へ要求させる、
情報処理装置。
　通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能なシンク機器と、ソース機器として無線通信する無線通信部と、
　コンテンツ・データを前記シンク機器に前記無線通信部を介して送信するコンテンツ送信部と、
　アクセシビリティー・モードで動作する前記シンク機器に、前記シンク機器の操作者において操作可能なメタデータを、前記無線通信部を介して送信するメタデータ送信部と、
を具備する情報処理装置。
　前記メタデータ送信部は、メタデータ送信用のチャネルを用いてメタデータの送信を行なう、
請求項１７に記載の情報処理装置。
　通常モードと操作者の身体の障がい又は機能の低下に対応した閲覧を保証する１以上の種別のアクセシビリティー・モードのいずれかで動作可能なシンク機器と、ソース機器として無線通信する無線通信部と、
　コンテンツ・データを前記シンク機器に前記無線通信部を介して送信するコンテンツ送信部と、
　前記シンク機器の動作モードを、前記無線通信部を介して確認するモード確認部と、
　アクセシビリティー・モードで動作する前記シンク機器に、前記シンク機器の操作者において操作可能なメタデータを、前記無線通信部を介して送信するメタデータ送信部と、
を具備する情報処理装置。
　前記モード確認部は、ＭｉｒａｃａｓｔプロトコルにおけるＣａｐａｂｉｌｉｔｙ　Ｎｅｇｏｔｉａｔｉｏｎ、Ｄｅｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙ、又は、Ｓｅｒｖｉｃｅ　Ｄｉｓｃｏｖｅｒｙのうちいずれか１つ以上の処理を用いて前記シンク機器が対応しているアクセシビリティー・モード種別を確認する、
請求項１９に記載の情報処理装置。
　前記シンク機器がサポートするアクセシビリティー・モード種別に応じてメタデータを変換するメタデータ変換部をさらに備える、
請求項１９又は２０のいずれかに記載の情報処理装置。
　前記シンク機器がアクセシビリティー・モードの場合に、メタデータを生成する必要があることを前記情報処理装置の操作者に通知する通知部をさらに備える、
請求項１９乃至２１のいずれかに記載の情報処理装置。
　前記通知部は、前記シンク機器へ送信するメタデータのメディア種別を表示し、メタデータを変換してもよいかどうかを操作者に確認を促す、
請求項２２に記載の情報処理装置。
　前記シンク機器とアクセシビリティー・モードの種別が異なる場合に前記シンク機器とモードを一致させるモード制御部をさらに備える、
請求項１９乃至２３のいずれかに記載の情報処理装置。
　操作者が前記シンク機器と接続中にモードを変更した場合、通常モードとアクセシビリティー・モードを途中で変更するモード・エックスチェンジ用メッセージ信号を前記コンテンツ送信部によるコンテンツの伝送途中で送信させるメッセージ送信部をさらに備える、
請求項１９乃至２４のいずれかに記載の情報処理装置。