JP6897566B2 - 装置及び方法 - Google Patents

Description

本開示は、装置及び方法に関する。

無線ＬＡＮ（Local Area Network）機器同士の暗号化設定を容易にする技術として、Ｗｉ−Ｆｉ（登録商標）（Wireless Fidelity）アライアンスによりＷＰＳ（Wi-Fi Protected Setup（登録商標））が策定されている。ＷＰＳ対応機器同士は、無線ＬＡＮのセキュリティを担保するための複雑な設定を、簡単に行うことが可能である。なお、ＷＰＳに関する規格は下記非特許文献１に規定されている。ＷＰＳは、ＷＳＣ（Wi-Fi Simple Configuration）又はＷＳＣ ｅｘｃｈａｎｇｅとも称される場合がある。

ＷＰＳを利用するための手順には、プッシュボタン式とＰＩＮ（Personal Identification Number）コード式とがある。プッシュボタン式においては、ネットワークへの接続を行うエンローリ（Enrolle）、及びエンローリのネットワークへの登録を行うレジストラ（Registrar）に設けられたボタンがそれぞれ押下されることで、セキュリティの設定が行われる。ＰＩＮコード式においては、レジストラにエンローリのＰＩＮコードが登録されることで、セキュリティの設定が行われる。

Wi-Fi Alliance，"Wi-Fi Simple Configuration Technical Specification"， Version 2.0.5， 2014．

しかし、いずれの手順においても、エンローリのセキュリティ設定が完了するまでに相応の手間がかかっていた。ただし、手順を単に簡略化するだけでは、セキュリティレベルの低下をも引き起こしかねない。

そこで、ＷＰＳの手順を簡略化しつつセキュリティレベルを維持することが可能な仕組みが提供されることが望ましい。

本開示によれば、他の装置とのＰ２Ｐ通信の接続が確立しており、アクセスポイントとのインフラストラクチャ通信の接続が確立している又は確立履歴があり、且つ前記他の装置と前記アクセスポイントとのインフラストラクチャ通信の接続が確立していないことを条件として、前記他の装置とのインフラストラクチャ通信の接続を確立することを指示するメッセージを前記アクセスポイントへ通知する処理部、を備える装置が提供される。

また、本開示によれば、自身とのインフラストラクチャ通信の接続が確立している又は確立履歴があり、第２の端末装置とのＰ２Ｐ通信の接続が確立している第１の端末装置から、前記第２の端末装置とのインフラストラクチャ通信の接続を開始することを指示するメッセージが通知されたことをトリガとして、前記第２の端末装置とのインフラストラクチャ通信の接続を確立するための処理を開始する処理部、を備える装置が提供される。

また、本開示によれば、アクセスポイントとのインフラストラクチャ通信の接続が確立しており、且つ他の端末と前記アクセスポイントとのインフラストラクチャ通信の接続が確立していることを条件として、前記他の装置とのＰ２Ｐ通信の接続のための設定情報を、前記アクセスポイントを経由するインフラストラクチャ通信により前記他の装置へ通知する処理部、を備える装置が提供される。

また、本開示によれば、他の装置とのＰ２Ｐ通信の接続が確立しており、アクセスポイントとのインフラストラクチャ通信の接続が確立している又は確立履歴があり、且つ前記他の装置と前記アクセスポイントとのインフラストラクチャ通信の接続が確立していないことを条件として、前記他の装置とのインフラストラクチャ通信の接続を確立することを指示するメッセージを前記アクセスポイントへプロセッサにより通知すること、を含む方法が提供される。

以上説明したように本開示によれば、ＷＰＳの手順を簡略化しつつセキュリティレベルを維持することが可能な仕組みが提供される。なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。

本開示の一実施形態に係るシステムの構成例を説明するための説明図である。 ＷＰＳにおけるＰＢＣベースの接続手順の流れの一例を示すシーケンス図である。 Ｍｉｒａｃａｓｔにおけるコマンドのやり取りの流れの一例を示すシーケンス図である。 本開示の一実施形態に係るＡＰの論理的な構成の一例を示すブロック図である。 本開示の一実施形態に係るソース機器の論理的な構成の一例を示すブロック図である。 本開示の一実施形態に係るシンク機器の論理的な構成の一例を示すブロック図である。 第１の実施形態の状況設定を説明するための説明図である。 本実施形態に係るレジストラにおいて実行される接続切り替え処理の流れの一例を示すフローチャートである。 本実施形態に係るレジストラにおいて実行される接続切り替え処理の流れの一例を示すフローチャートである。 本実施形態に係るシステムにおいて実行される接続切り替え処理の流れの一例を示すシーケンス図である。 図１０に示した処理の流れを詳細に示すシーケンス図である。 本実施形態に係るシステムにおいて実行される接続切り替え処理の流れの一例を示すシーケンス図である。 図１２に示すシーケンスにおけるトポロジの変化を説明するための説明図である。 本実施形態に係るシステムにおいて実行される接続切り替え処理の流れの一例を示すシーケンス図である。 第２の実施形態の状況設定を説明するための説明図である。 インフラストラクチャ通信からＰ２Ｐ通信への切り替え処理の流れの一例を示すシーケンス図である。 インフラストラクチャ通信からＰ２Ｐ通信への切り替え処理の流れの一例を示すシーケンス図である。 本実施形態に係るソース機器において実行される接続切り替え処理の流れの一例を示すフローチャートである。 スマートフォンの概略的な構成の一例を示すブロック図である。 カーナビゲーション装置の概略的な構成の一例を示すブロック図である。 無線アクセスポイントの概略的な構成の一例を示すブロック図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
１．はじめに
１．１．システムの構成例
１．２．ＷＰＳ
１．３．Ｍｉｒａｃａｓｔ
２．各装置の構成例
２．１．ＡＰの構成例
２．２．ＳＴＡの構成例
３．第１の実施形態
３．１．状況設定
３．２．技術的課題
３．３．技術的特徴
３．４．処理の流れ
４．第２の実施形態
４．１．状況設定
４．２．技術的課題
４．３．技術的特徴
４．４．処理の流れ
５．応用例
６．まとめ

＜＜１．はじめに＞＞
＜１．１．システムの構成例＞
図１は、本開示の一実施形態に係るシステム１の構成例を説明するための説明図である。図１に示すように、システム１は、情報処理装置１００、２００及び３００を含む。情報処理装置１００、２００及び３００は、任意の無線通信規格に準拠した通信が可能な無線通信装置である。具体的な無線通信規格としては、例えば、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１、ＩＥＥＥ８０２．１５、ＩＥＥＥ８０２．１６、３ＧＰＰ（3rd Generation Partnership Project）規格（例えば、Ｗ−ＣＤＭＡ（Wideband Code Division Multiple Access）、ＧＳＭ（登録商標）（Global System for Mobile Communications）、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）、ＷｉＭＡＸ２、Ｗｉ−Ｆｉ、ＬＴＥ（Long Term Evolution）、及びＬＴＥ−Ａ（Advanced））等が挙げられる。

一例として、情報処理装置１００、２００及び３００は、無線ＬＡＮを用いた通信が可能であるものとする。例えば、情報処理装置１００は、無線ＬＡＮサービスを提供するＡＰ（Access Point）である。情報処理装置２００及び３００は、ＡＰ１００との接続を確立して、無線ＬＡＮサービスを享受するＳＴＡ（Station）である。ＳＴＡ２００及び３００は、ＡＰ１００とのインフラストラクチャ通信により、ＡＰ１００を経由して通信することが可能である。

また、ＳＴＡ２００及び３００は、Ｐ２Ｐ通信により、直接的に通信することが可能である。そのために、例えばＷｉ−Ｆｉ Ｄｉｒｅｃｔ（登録商標）、ＴＤＬＳ（Tunneled Direct Link Setup）、アドホックネットワーク、又はメッシュネットワーク等が用いられ得る。

＜１．２．ＷＰＳ＞
システム１では、ＷＰＳによりエンローリがネットワークに接続し得る。例えば、ＳＴＡ２００がレジストラ（第１の端末装置）であり、ＳＴＡ３００がエンローリ（第２の端末装置）であってもよい。

以下、図２を参照して、プッシュボタン式の手順について詳しく説明する。

図２は、ＷＰＳにおけるＰＢＣベースの接続手順の流れの一例を示すシーケンス図である。本シーケンスには、レジストラ、エンローリ、及びＡＰが関与する。本シーケンスは、外部レジストラ（External Registrar）が起点として接続が開始される例である。

図２に示すように、まず、ＡＰは、ビーコンを報知（broadcast）する（ステップＳ１０）。このビーコンには、ＳＲ（Selected Registrar）＝Ｆａｌｓｅが記載されたＷＳＣ ＩＥ（Information Element）が含まれる。レジストラは、モニタ期間中にボタンが押下されると、ＰＢＣモードに移行し、レジストラとしての機能が有効化される（ステップＳ１１）。次いで、レジストラは、ＳｅｔＳｅｌｅｃｔｅｄＲｅｇｉｓｔｒａｒ（ＳＲ＝ＴＲＵＥ、ＰＢＣ）をＡＰへ通知する（ステップＳ１２）。なお、本メッセージには、エンローリのＭＡＣアドレス（未知である場合はワイルドカードＭＡＣアドレス）が設定されている。ＡＰは、ＳＲ＝ＴＲＵＥが設定されたＳｅｔＳｅｌｅｃｔｅｄＲｅｇｉｓｔｒａｒを受信すると、ＳＲ＝ＴＲＵＥ、レジストラ設定方法（Registrar Configuration Methods）＝ＰＢＣ、及びＳｅｔＳｅｌｅｃｔｅｄＲｅｇｉｓｔｒａｒにセットされていたＭＡＣアドレスが記載されたＷＳＣ ＩＥを含むビーコンを報知する（ステップＳ１３）。

一方で、エンローリは、ボタンが押下されてＰＢＣモードに移行すると、ＰＢＣモードが有効化されたＡＰをスキャンする（ステップＳ１４）。具体的には、エンローリは、ＳＲ＝ＴＲＵＥがセットされたビーコン（又はプローブレスポンス）を探索する。

その後、エンローリは、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＲｅｑｕｅｓｔをＡＰへ通知する（ステップＳ１５）。次いで、ＡＰは、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅをエンローリへ通知する（ステップＳ１６）。次に、エンローリは、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｑｕｅｓｔ（ＷＳＣ ＩＥ）をＡＰへ通知する（ステップＳ１７）。次いで、ＡＰは、Ａｓｓｏｃｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅ（ＷＳＣ ＩＥ）をエンローリへ通知する（ステップＳ１８）。

次に、エンローリは、ＥＡＰＯＬ−ＳｔａｒｔをＡＰへ通知する（ステップＳ１９）。次いで、ＡＰは、ＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙをエンローリへ通知する（ステップＳ２０）。次に、エンローリは、ＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＩｄｅｎｔｉｔｙをＡＰへ通知する（ステップＳ２１）。次いで、ＡＰは、ＥＡＰ−Ｒｅｑｕｅｓｔ（Ｓｔａｒｔ）をエンローリへ通知する（ステップＳ２２）。

エンローリは、Ｍ１メッセージ（ＥＡＰ−Ｒｅｓｐｏｎｓｅ（Ｍ１））を通知する（ステップＳ２３）。本Ｍ１メッセージは、外部レジストラに対し、ＵＰｎＰ（Universal Plug and Play）イベントを承認したことを通知するためのものである。ＡＰは、ＵＰｎＰ Ｅｖｅｎｔ（Ｍ１）をレジストラへ通知する（ステップＳ２４）。次いで、レジストラは、ＰｕｔＷＬＡＮＲｅｓｐｏｎｓｅ（Ｍ２）をＡＰへ通知する（ステップＳ２５）。ＡＰは、ＥＡＰ−Ｒｅｑｕｅｓｔ（Ｍ２）をエンローリへ通知する（ステップＳ２６）。

次に、エンローリは、ＥＡＰ−Ｒｅｓｐｏｎｓｅ（Ｍ３）をＡＰへ通知する（ステップＳ２７）。ＡＰは、ＵＰｎＰ Ｅｖｅｎｔ（Ｍ３）をレジストラへ通知する（ステップＳ２８）。次いで、レジストラは、ＰｕｔＷＬＡＮＲｅｓｐｏｎｓｅ（Ｍ４）をＡＰへ通知する（ステップＳ２９）。ＡＰは、ＥＡＰ−Ｒｅｑｕｅｓｔ（Ｍ４）をエンローリへ通知する（ステップＳ３０）。

次に、エンローリは、ＥＡＰ−Ｒｅｓｐｏｎｓｅ（Ｍ５）をＡＰへ通知する（ステップＳ３１）。ＡＰは、ＵＰｎＰ Ｅｖｅｎｔ（Ｍ５）をレジストラへ通知する（ステップＳ３２）。次いで、レジストラは、ＰｕｔＷＬＡＮＲｅｓｐｏｎｓｅ（Ｍ６）をＡＰへ通知する（ステップＳ３３）。ＡＰは、ＥＡＰ−Ｒｅｑｕｅｓｔ（Ｍ６）をエンローリへ通知する（ステップＳ３４）。

次に、エンローリは、ＥＡＰ−Ｒｅｓｐｏｎｓｅ（Ｍ７）をＡＰへ通知する（ステップＳ３５）。ＡＰは、ＵＰｎＰ Ｅｖｅｎｔ（Ｍ７）をレジストラへ通知する（ステップＳ３６）。次いで、レジストラは、ＰｕｔＷＬＡＮＲｅｓｐｏｎｓｅ（Ｍ８，ｃｒｅｄｅｎｔｉａｌｓ）をＡＰへ通知する（ステップＳ３７）。ＡＰは、ＥＡＰ−Ｒｅｑｕｅｓｔ（Ｍ８，ｃｒｅｄｅｎｔｉａｌｓ）をエンローリへ通知する（ステップＳ３８）。

次に、エンローリは、ＥＡＰ−Ｒｅｓｐｏｎｓｅ（Ｄｏｎｅ）をＡＰへ通知する（ステップＳ３９）。ＡＰは、ＵＰｎＰ Ｅｖｅｎｔ（Ｄｏｎｅ）をレジストラへ通知する（ステップＳ４０）。また、ＡＰは、ＥＡＰ−Ｆａｉｌをエンローリへ通知し（ステップＳ４１）、Ｄｅａｕｔｈｅｎｔｉｃａｔｉｏｎをエンローリへ通知する（ステップＳ４２）。

最後に、レジストラは、ＳｅｔＳｅｌｅｃｔｅｄＲｅｇｉｓｔｒａｒ（ＳＲ＝Ｆａｌｓｅ）をＡＰへ通知して、ＡＰのＳｅｔＳｅｌｅｃｔｅｄＲｅｇｉｓｔｒａｒ属性をＦａｌｓｅにし、処理を終了する（ステップＳ４３）。

なお、本シーケンスは、上記非特許文献１の図６に開示されている。詳しい説明、及び本シーケンス以外の例は、上記非特許文献１を参照されたい。

＜１．３．Ｍｉｒａｃａｓｔ＞
システム１では、例えば、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔ（登録商標）（以下、単にＭｉｒａｃａｓｔとも称する）が用いられ得る。Ｍｉｒａｃａｓｔは、技術仕様書名をＷｉ−Ｆｉ Ｄｉｓｐｌａｙという、近距離無線ＡＶ（Audio Visual）伝送通信方式である。Ｍｉｒａｃａｓｔは、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ又はＴＤＬＳを利用して、一方の端末で再生される音声及び表示画像等のコンテンツを他の端末に送信し、他の端末でも同様にそのコンテンツを出力させるミラーリング技術である。

Ｍｉｒａｃａｓｔでは、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）上でＵＩＢＣ（User Input Back Channel）が実現される。ＵＩＢＣは、一方の端末から他方の端末へ、マウス又はキーボード等の入力機器の操作情報を送信する技術である。なお、Ｍｉｒａｃａｓｔの代わりに、他のリモートデスクトップソフトウェア（例えば、ＶＮＣ（Virtual Network Computing））が用いられてもよい。

Ｍｉｒａｃａｓｔでは、画像（又は映像）を、例えば、Ｈ．２６４を用いて圧縮及び展開することが定められている。ただし、Ｍｉｒａｃａｓｔでは、送信側でＨ．２６４に関する調整を行うことが可能である。なお、Ｍｉｒａｃａｓｔは、Ｈ．２６４に限らず、例えばＨ．２６５（例えば、ＨＥＶＣ（high efficiency video coding）、ＳＨＶＣ（scalable video coding extensions of high efficiency video coding））、ＭＰＥＧ（Moving Picture Experts Group）４又はＪＰＥＧ（Joint Photographic Experts Group）２０００にも対応可能である。また、Ｍｉｒａｃａｓｔは、例えば１ライン以上を束ねた圧縮に対応可能である。また、Ｍｉｒａｃａｓｔは、２ライン以上を２×２以上のマクロブロックに分割して圧縮・展開を行うラインベースコーデック（例えば、Ｗａｖｅｌｅｔ、ＤＣＴ（Discrete Cosine Transform））に対応可能である。また、Ｍｉｒａｃａｓｔは、例えば特定の符号量領域（Ｐｉｃｔｕｒｅまたは複数ラインの束またはマクロブロック等）の前符号量領域との差分を求めることで、ＤＣＴ又はＷａｖｅｌｅｔ等の圧縮を行わずに伝送レートを減らすコーデックにも対応可能である。また、Ｍｉｒａｃａｓｔは、非圧縮での画像（又は映像）の送信及び受信にも対応可能である。

Ｍｉｒａｃａｓｔでは、コンテンツを送信する側の端末はソース機器とも称され、受信する側の端末はシンク機器とも称される。ソース機器は、撮像動作により生成された画像データ及び音声データを送信対象としてもよいし、記憶部（例えば、ハードディスク）に保存されているコンテンツを送信対象としてもよい。さらに、ソース機器は、テザリング機能を有する場合、無線又は有線ネットワークを経由してＩＳＰ（Internet Services Provider）に保存されたコンテンツを送信対象としてもよい。ソース機器は、カメラ、ＰＣ（Personal Computer）、ゲーム機、スマートフォン又はタブレット端末等の、カメラを搭載した電子機器として実現され得る。一方で、シンク機器は、カメラ、ＰＣ（Personal Computer）、ゲーム機、スマートフォン又はタブレット端末等の、出力装置（例えば、ディスプレイ又はスピーカ等）を搭載した電子機器として実現され得る。

ＳＴＡ２００及びＳＴＡ３００のうち、任意の一方がソース機器として機能し、他方がシンク機器として機能する。以下では、一例としてＳＴＡ２００がソース機器であり、ＳＴＡ３００がシンク機器であるものとする。

以下、図３を参照して、Ｍｉｒａｃａｓｔにおけるコマンドを用いたやり取りの一例を説明する。

図３は、Ｍｉｒａｃａｓｔにおけるコマンドのやり取りの流れの一例を示すシーケンス図である。本シーケンスには、ソース機器及びシンク機器が関与する。本シーケンスは、ＲＴＳＰ（Real Time Streaming Protocol）を用いたＷＦＤ（Wi-Fi Display）ケイパビリティネゴシエーションの流れの一例を示している。

図３に示すように、ソース機器とシンク機器とは、レイヤ３の接続に成功しており、ソース機器及びシンク機器は、この時点のＩＰアドレスを共に有している（ステップＳ５０）。

次いで、ソース機器は、Ｍ１−ＲＴＳＰ ＯＰＴＩＯＮＳ Ｒｅｑｕｅｓｔをシンク機器へ通知する（ステップＳ５１）。シンク機器は、Ｍ１−ＲＴＳＰ ＯＰＴＩＯＮＳ Ｒｅｓｐｏｎｓｅをソース機器へ通知する（ステップＳ５２）。

次に、シンク機器は、Ｍ２−ＲＴＳＰ ＯＰＴＩＯＮＳ Ｒｅｑｕｅｓｔをソース機器へ通知する（ステップＳ５３）。ソース機器は、Ｍ２−ＲＴＳＰ ＯＰＴＩＯＮＳ Ｒｅｓｐｏｎｓｅをシンク機器へ通知する（ステップＳ５４）。

次いで、ソース機器は、Ｍ３−ＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ Ｒｅｑｕｅｓｔをシンク機器へ通知する（ステップＳ５５）。シンク機器は、Ｍ３ Ｒｅｓｐｏｎｓｅ−−ＯＫをソース機器へ通知する（ステップＳ５６）。

次に、ソース機器は、Ｍ４ ＲＴＳＰ ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ Ｒｅｑｕｅｓｔをシンク機器へ通知する（ステップＳ５７）。シンク機器は、Ｍ４ Ｒｅｓｐｏｎｓｅ−−ＯＫをソース機器へ通知する（ステップＳ５８）。

これにより、ソース機器とシンク機器との情報の交換は完了する（ステップＳ５９）。

例えば、情報のやり取りには、Ｍ３メッセージ（Ｍ３−ＲＴＳＰ ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ Ｒｅｑｕｅｓｔ及びＭ３ Ｒｅｓｐｏｎｓｅ）が用いられてもよい。これに代えて、Ｍ３メッセージが省略され、ソース機器からシンク機器へ送信されるメッセージに交換対象の情報が含まれてもよい。例えば、ソース機器及びシンク機器は、コンテンツプロテクション設定を行う場合、Ｍ３ Ｒｅｓｐｏｎｓｅ後にリンクプロテクションセットアップを行う。その後、ソース機器及びシンク機器は、Ｍ４以上のメッセージの交換のみを行うことで、一度設定されたリンクの秘話性を確保したまま、通信を行うことも可能である。

ＲＴＳＰ Ｍ３ Ｒｅｓｐｏｎｓｅには、以下のシンク機器の情報が含まれ得る。
・Audio format(s) supported by the WFD Sink.
・video format(s) support by the WFD Sink.
・3D formats supported by the WFD Sink.
・The HDCP system 2.0/2.1/2.2 support/control port.
・Available EDID information of display attached to the WFD Sink.
・Coupled WFD Sink information.
・RTP port(s) the WFD Sink(s) listen on.
・Supports I2C commands and port number.
・UIBC capability supported.
・WFD Source uses this parameter to obtain the connector type currently active on the WFD Sink.
・Indicate the support for standby and resume control using RTSP.

なお、本シーケンスは、「Wi-Fi Display Technical Specification v1.0.0」の図４−４に開示されている。詳しい説明、及び本シーケンス以外の例は、上記非特許文献１を参照されたい。

＜＜２．各装置の構成例＞＞
＜２．１．ＡＰの構成例＞
図４は、本開示の一実施形態に係るＡＰ１００の論理的な構成の一例を示すブロック図である。図４に示すように、ＡＰ１００は、アンテナ部１１０、無線通信部１２０、ネットワーク通信部１３０、記憶部１４０及び処理部１５０を含む。

（アンテナ部１１０）
アンテナ部１１０は、無線通信部１２０により出力された信号を電波として空間に放射する。また、アンテナ部１１０は、空間の電波を信号に変換し、当該信号を無線通信部１２０へ出力する。

（無線通信部１２０）
無線通信部１２０は、信号を送受信する。例えば、無線通信部１２０は、ＳＴＡ２００又は３００への信号を受信し、ＳＴＡ２００又は３００からの信号を受信する。

（ネットワーク通信部１３０）
ネットワーク通信部１３０は、情報を送受信する。例えば、ネットワーク通信部１３０は、他のノードへの情報を送信し、他のノードからの情報を受信する。例えば、上記他のノードは、ルータを含む。

（記憶部１４０）
記憶部１４０は、ＡＰ１００の動作のためのプログラム及びデータを記憶する。

（処理部１５０）
処理部１５０は、ＡＰ１００の様々な機能を提供する。処理部１５０は、通信制御部１５１及び接続制御部１５３を含む。なお、処理部１５０は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部１５０は、これらの構成要素の動作以外の動作も行い得る。

通信制御部１５１は、ＳＴＡ２００又はＳＴＡ３００との通信を制御する機能を有する。接続制御部１５３は、ＳＴＡ２００又はＳＴＡ３００がネットワークに接続するための、例えばＷＰＳのための処理を制御する機能を有する。

＜２．２．ＳＴＡの構成例＞
（１）ＳＴＡ２００の構成例
例えば、ＳＴＡ２００は、ソース機器である。図５は、本開示の一実施形態に係るソース機器２００の論理的な構成の一例を示すブロック図である。図５に示すように、ソース機器は、アンテナ部２１０、無線通信部２２０、制御信号送受信部２３０、処理部２４０、画像・音声信号生成部２５０、画像・音声圧縮部２６０、ストリーム送信部２７０、操作受付部２８０及び出力部２９０を含む。

（アンテナ部２１０）
アンテナ部２１０は、無線通信部２２０により出力された信号を電波として空間に放射する。また、アンテナ部２１０は、空間の電波を信号に変換し、当該信号を無線通信部２２０へ出力する。

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

また、無線通信部２２０は、複数の周波数チャネルを利用可能であってもよい。例えば、無線通信部２２０は、２．４ＧＨｚ、５ＧＨｚ、及び６０ＧＨｚの３種類の周波数チャネルを、同時に又は選択的に利用可能であってもよい。もちろん、利用可能な周波数チャネル及びその数は、これらに限定されない。ソース機器２００が、複数の周波数チャネルを送受信可能である場合、シンク機器３００は、各ソース機器にどの周波数チャネルを使用させるかを制御することができる。

（制御信号送受信部２３０）
制御信号送受信部２３０は、他の情報処理装置（例えば、ＡＰ１００又はシンク機器３００）との間で制御信号を送受信する機能を有する。例えば、制御信号送受信部２３０は、無線通信部２２０により受信された情報から制御信号を取得して、処理部２４０へ出力する。また、制御信号送受信部２３０は、処理部２４０から出力された制御信号を無線通信部２２０へ出力する。

（処理部２４０）
処理部２４０は、ソース機器２００の様々な機能を提供する。処理部２４０は、コンテンツ制御部２４１及び接続制御部２４３を含む。なお、処理部２４０は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部２４０は、これらの構成要素の動作以外の動作も行い得る。

・コンテンツ制御部２４１
コンテンツ制御部２４１は、ソース機器２００からシンク機器３００へのコンテンツのストリーミングに関する各種処理を行う機能を有する。例えば、コンテンツ制御部２４１は、制御信号送受信部２３０により受信された制御信号に基づいて、画像・音声信号生成部２５０及び画像・音声圧縮部２６０に対する制御を行う。例えば、コンテンツ制御部２４１は、送信対象となる画像データの解像度、送信対象とする画像領域、音声のチャネル数等を制御する。他にも、コンテンツ制御部２４１は、ソース機器２００とシンク機器３００との間の電波伝搬状況（例えば、リンク電波伝搬状況）、伝送速度又はコンテンツの品質等に応じてストリームの伝送制御を行ってもよい。

また、コンテンツ制御部２４１は、データレート制御では安定化することが困難な状態を改善させるための制御を行ってもよい。例えば、コンテンツ制御部２４１は、ソース機器２００又はシンク機器３００のケイパビリティ情報に基づいて、ストリームの伝送制御を行ってもよい。ケイパビリティ情報は、例えばモバイル機器であるか否か、使用可能な周波数チャネル、解像度、ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）に関する情報、暗号化方法の対応、ＳＤ（Standard Definition）対応／ＨＤ（High Definition）対応／４Ｋ対応、及び低消費電力モードの対応の各々の有無を示す情報を含み得る。

これらの制御のための、電波伝搬状況を示す情報及びケイパビリティ情報等の情報は、制御信号に含まれてシンク機器３００との間で送受信されてもよい。

・接続制御部２４３
接続制御部２４３は、ＡＰ１００又はシンク機器３００との接続のための、例えばＷＰＳのための処理を制御する機能を有する。接続制御部２４３の具体的な動作は、後に詳しく説明する。

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

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

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

（操作受付部２８０）
操作受付部２８０は、ユーザにより行われた操作入力を受け付ける機能を有する。操作受付部２８０は、例えば、キーボード、マウス、ゲームパッド、タッチパネル、カメラ又はマイクであってもよい。操作受付部２８０は、表示装置と一体的に形成されるタッチパネルであってもよい。操作受付部２８０は、各種センサ又はウェアラブルデバイス等の外部装置から操作情報を受け付けてもよい。

（出力部２９０）
出力部２９０は、画像・音声信号生成部２５０により生成されたデータを出力する機能を有する。出力部２９０は、例えば表示装置及び音声出力装置を含み得る。表示装置は、例えば有機ＥＬ（Electro Luminescence）、クリスタルＬＥＤ（Light Emitting Diode）ディスプレイ（Crystal LED Display）、又はＬＣＤ（Liquid Crystal Display）により実現され得る。音声出力装置は、例えばスピーカにより実現され得る。なお、画像については、ソース機器２００及びシンク機器３００の双方から出力されることが望ましい。一方で、音声については、ソース機器２００又はシンク機器３００のいずれか一方から出力されることが望ましい。

（補足）
なお、ソース機器２００は、送信対象となる画像データ及び音声データを外部装置から取得してもよい。例えば、ソース機器２００は、マイクロフォン付きのＷｅｂカメラから、送信対象となる画像データ及び音声データを取得してもよい。ソース機器２００は、ソース機器２００の内部又は外部の記憶装置（例えば、ハードディスク）に保存されているコンテンツ（例えば、画像データ及び音声データからなるコンテンツ）を送信対象としてもよい。この場合に、当該記憶装置に保存されているコンテンツが圧縮済のコンテンツである場合も想定される。当該コンテンツがシステム１で採用されている規格で定義されたエンコード方式で圧縮されている場合には、ソース機器２００は、その圧縮済のコンテンツを復号（デコード）せずにそのまま送信してもよい。

（２）ＳＴＡ３００の構成例
例えば、ＳＴＡ３００は、シンク機器である。図６は、本開示の一実施形態に係るシンク機器３００の論理的な構成の一例を示すブロック図である。図６に示すように、シンク機器３００は、アンテナ部３１０、無線通信部３２０、ストリーム受信部３３０、画像・音声展開部３４０、画像・音声出力部３５０、操作受付部３６０、処理部３７０、及び制御信号送受信部３８０を含む。

（アンテナ部３１０）
アンテナ部３１０は、無線通信部３２０により出力された信号を電波として空間に放射する。また、アンテナ部３１０は、空間の電波を信号に変換し、当該信号を無線通信部３２０へ出力する。

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

また、無線通信部３２０は、複数の周波数チャネルを利用可能であってもよい。例えば、無線通信部３２０は、２．４ＧＨｚ、５ＧＨｚ、及び６０ＧＨｚの３種類の周波数チャネルを、同時に又は選択的に利用可能であってもよい。もちろん、利用可能な周波数チャネル及びその数は、これらに限定されない。処理部３７０は、各ソース機器２００との無線通信に、複数の周波数チャネルのうちのどの周波数チャネルを使用させるかを制御する。なお、ソース機器２００及びシンク機器３００の間のリンクと、ＡＰ１００及びシンク機器３００の間のリンクとには、同一の周波数チャネルが用いられてもよいし、異なる周波数チャネルが用いられてもよい。

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

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

（画像・音声出力部３５０）
画像・音声出力部３５０は、画像・音声展開部３４０により展開されたデータを出力する機能を有する。画像・音声出力部３５０は、表示部３５１及び音声出力部３５２を含む。表示部３５１は、例えば有機ＥＬ、クリスタルＬＥＤディスプレイ、又はＬＣＤにより実現され得る。音声出力部３５２は、例えばスピーカにより実現され得る。

（操作受付部３６０）
操作受付部３６０は、ユーザにより行われた操作入力を受け付ける機能を有する。操作受付部３６０は、例えば、キーボード、マウス、ゲームパッド、タッチパネル、カメラ又はマイクであってもよい。操作受付部３６０は、表示部３５１と一体的に形成されるタッチパネルであってもよい。操作受付部３６０は、各種センサ又はウェアラブルデバイス等の外部装置から操作情報を受け付けてもよい。

（処理部３７０）
処理部３７０は、シンク機器３００の様々な機能を提供する。処理部３７０は、コンテンツ制御部３７１及び接続制御部３７３を含む。なお、処理部３７０は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部３７０は、これらの構成要素の動作以外の動作も行い得る。

・コンテンツ制御部３７１
コンテンツ制御部３７１は、制御信号送受信部３８０により送受信された制御信号に基づいて、ストリームの伝送制御を行う。例えば、コンテンツ制御部３７１は、上述したソース機器２００（例えば、コンテンツ制御部２４１）がストリームの伝送制御を行うために用いる制御信号をソース機器２００毎に生成し、制御信号送受信部３８０を経てソース機器２００へ送信させる。また、コンテンツ制御部３７１は、コンテンツの伝送に使用する周波数チャネルをソース機器２００毎に設定してもよい。

・接続制御部３７３
接続制御部３７３は、ＡＰ１００又はソース機器２００との接続のための、例えばＷＰＳのための処理を制御する機能を有する。接続制御部３７３の具体的な動作は、後に詳しく説明する。

（制御信号送受信部３８０）
制御信号送受信部３８０は、他の情報処理装置（例えば、ＡＰ１００又はソース機器２００）との間で制御信号を送受信する機能を有する。例えば、制御信号送受信部３８０は、無線通信部３２０により受信された情報から制御信号を取得して、処理部３７０へ出力する。また、制御信号送受信部３８０は、処理部３７０から出力された制御信号を無線通信部３２０へ出力する。

＜＜３．第１の実施形態＞＞
＜３．１．状況設定＞
第１の実施形態では、ＳＴＡ２００とＳＴＡ３００との接続が、Ｐ２Ｐ通信からインフラストラクチャ通信へ切り替えられる状況における技術が開示される。以下、図７を参照して、本実施形態の状況設定を説明する。

図７は、本実施形態の状況設定を説明するための説明図である。図７に示すように、まず、ＳＴＡ２００及びＳＴＡ３００は、Ｐ２Ｐ通信の接続を確立する（符号１０）。その後、ＳＴＡ２００及びＡＰ１００はインフラストラクチャ通信の接続を確立し（符号１１）、続いてシンク機器３００がＡＰ１００とのインフラストラクチャ通信の接続を試みる（符号１２）。ＡＰ１００とシンク機器３００とのインフラストラクチャ通信の接続が確立すると、ＳＴＡ２００とＳＴＡ３００との通信は、直接的なＰ２Ｐ通信からＡＰ１００を経由したインフラストラクチャ通信へ切り替えられ得る。

＜３．２．技術的課題＞
ＳＴＡ２００がレジストラであり、ＳＴＡ３００がエンローリであるものとする。通常、機器同士は、互いに信頼関係が構築されたことを前提として、接続を確立する。即ち、ＳＴＡ２００とＳＴＡ３００とのＰ２Ｐ通信、並びにＳＴＡ２００とＡＰ１００との間のインフラストラクチャ通信及びＳＴＡ３００とＡＰ１００とのインフラストラクチャ通信の各々の接続を確立するために、信頼関係が都度構築されている。しかしながら、信頼関係の構築のためには相応の処理時間がかかっていた。

そこで、本実施形態では、符号１１に示した状況下で、エンローリ３００とＡＰ１００との信頼関係の構築ステップを、セキュリティレベルを維持しつつ簡略化する技術を提供する。詳しくは、本実施形態では、レジストラ２００とエンローリ３００との信頼関係、及びレジストラ２００とＡＰ１００との信頼関係が構築済みであることを利用することで、セキュリティレベルを維持しつつ簡略化することを可能にする。

＜３．３．技術的特徴＞
（１）ＰＢＣモード開始メッセージ
レジストラ２００（例えば、接続制御部２４３）は、エンローリ３００とのＰ２Ｐ通信の接続が確立しており、ＡＰ１００とのインフラストラクチャ通信の接続が確立している又は確立履歴があり、且つエンローリ３００とＡＰ１００とのインフラストラクチャ通信の接続が確立していないことを条件として、エンローリ３００とのインフラストラクチャ通信の接続を確立することを指示するメッセージをＡＰ１００へ通知する。例えば、レジストラ２００は、符号１１に示した状況下で、エンローリ３００とのインフラストラクチャ通信の接続を確立することを指示するメッセージをＡＰ１００へ通知する。また、符号１１に示した状況に関し、レジストラ２００とＡＰ１００とのインフラストラクチャ通信の接続が確立していることに代えて、レジストラ２００にＡＰ１００とのインフラストラクチャ通信の接続を確立した履歴があることが代用されてもよい。いずれの場合も、レジストラ２００は、一旦接続を確立することで後述するインフラストラクチャ通信用設定情報を保持可能であるためである。ここで、エンローリ３００とのインフラストラクチャ通信の接続を確立することを指示する本メッセージは、自身が外部レジストラ（External Registrar）として機能して接続処理を開始することを指示するメッセージであってもよい。例えばＵＰｎＰにおいては、本メッセージは、自身が外部レジストラとしてアクティブになり、ＰＢＣモードでの接続処理を開始することを指示する、ＳｅｔＳｅｌｅｃｔｅｄＲｅｇｉｓｔｒａｒ（ＳＲ＝ＴＲＵＥ、ＰＢＣ）であってもよい。もちろん、本メッセージは、ＳｅｔＳｅｌｅｃｔｅｄＲｅｇｉｓｔｒａｒ（ＳＲ＝ＴＲＵＥ、ＰＢＣ）以外の任意のメッセージとして実現されてもよい。また、本メッセージのプロトコルは、ＵＰｎＰに限定されず、例えばＢｏｎｊｏｕｒ又はＡｖａｈｉ等の任意のプロトコルであってもよい。本メッセージを、以下ではＰＢＣモード開始メッセージとも称する。

ＰＢＣモード開始メッセージは、従来のＷＳＣ規格ではボタンが押されたことをトリガとして通知されていた。これに対し、本実施形態では、符号１１に示した状況下で自動的にＰＢＣモード開始メッセージが通知される。符号１１に示した状況下でＰＢＣモード開始メッセージが通知され、その後の一連の接続処理が自動的に開始されることで、ユーザによるボタン押下等の手間を削減することが可能となる。また、ＡＰ１００又はエンローリ３００の視点では、従来のＷＳＣ規格からの変更なしにレジストラ２００を外部レジストラとする接続処理が実行されるので、従来のＷＳＣ規格に記載されているセキュリティレベルが確保される。

なお、Ｐ２Ｐ通信は、例えばＷｉ−Ｆｉ Ｄｉｒｅｃｔ又はＮＡＮ（neighborhood area network）に準拠した通信であってもよい。また、インフラストラクチャ通信は、Ｗｉ−Ｆｉに準拠した通信であってもよい。もちろん、これらは一例であって、他の任意の通信規格に準拠した通信であってもよい。なお、以下では、Ｐ２Ｐ通信にＷｉ−Ｆｉ Ｄｉｒｅｃｔが用いられるものとする。ＳＴＡ２００及びＳＴＡ３００のうち、任意の一方がグループオーナーとして機能し、他方がクライアントとして機能する。

（２）接続許可要求メッセージ
レジストラ２００（例えば、接続制御部２４３）は、エンローリ３００からの接続要求を優先的に許可することを要求するメッセージをＡＰ１００へ通知してもよい。本メッセージは、例えばＬ４メッセージを用いて通知され得る。本メッセージを、以下では接続許可要求メッセージとも称する。接続要求を優先的に許可することには、例えばプローブリクエストを優先的に受信してプローブレスポンスを返信することが含まれる。

接続許可要求メッセージには、エンローリ３００を識別するための情報（例えば、ＭＡＣアドレス）が含まれる。本情報により、ＡＰ１００は、エンローリ３００を識別して接続要求を優先的に許可することが可能となる。具体的には、ＡＰ１００（接続制御部１５３）は、レジストラ２００から通知されたエンローリ３００を識別するための情報により、通知されたひとつ以上のプローブリクエストのうちエンローリ３００から通知されたプローブリクエストを識別する。この識別は、例えばＭＡＣアドレスのフィルタリングにより実現され得る。このような識別により、ＡＰ１００は、レジストラ２００から指示されたエンローリ３００のみに接続許可を与えることが可能となり、セキュリティが担保される。なお、接続許可要求メッセージは、省略可能である。なぜならば、接続許可要求メッセージは、ＡＰ１００がエンローリ３００からプローブリクエストを受信することを事前に把握し、接続処理をより早く、より安全に（例えば、第３者が入らないように）行うためのダブルチェックを目的としているためである。

なお、図２を参照して上記説明したように、既存のＳｅｔＳｅｌｅｃｔｅｄＲｅｇｉｓｔｒａｒにはエンローリのＭＡＣアドレスが設定され得る。本実施形態においても、これが踏襲されてもよい。即ち、接続許可要求メッセージは、ＰＢＣモード開始メッセージに含まれてもよい。

（３）ビーコン
ＡＰ１００（例えば、接続制御部１５３）は、自身とのインフラストラクチャ通信及びエンローリ３００とのＰ２Ｐ通信の接続が確立しているレジストラ２００から、ＰＢＣモード開始メッセージが通知されたことをトリガとして、エンローリ３００とのインフラストラクチャ通信の接続を確立するための処理を開始する。

具体的には、ＡＰ１００（例えば、接続制御部１５３）は、インフラストラクチャ通信の接続を開始するよう指示するメッセージを、エンローリ３００へ通知する。例えば、第１の例として、ＡＰ１００は、ＰＢＣ（Push Button Configuration）モードで動作していることを示す情報を含むビーコン（又はプローブレスポンス）を報知してもよい。また、第２の例として、ＡＰ１００は、Ｐ２Ｐ通信からインフラストラクチャ通信へ切り替えることを指示する情報を含むビーコン（又はプローブレスポンス）を報知してもよい。また、これらのビーコンには、接続許可要求メッセージに記載された、エンローリ３００のＭＡＣアドレスが含まれてもよい。このようなビーコンを、以下ではインフラストラクチャ通信接続開始指示ビーコンとも称する。エンローリ３００は、インフラストラクチャ通信接続開始指示ビーコンにより、ＰＢＣモードの開始を知得し、それをトリガとしてＡＰ１００との接続を開始することが可能となる。そのため、ユーザによるＰＢＣ用のボタン押下等の手間を削減することが可能となる。

以下、インフラストラクチャ通信接続開始指示ビーコンのＷＳＣ ＩＥに格納される情報を具体的に説明する。下記の表１は、上記非特許文献１の表３に記載されている、ビーコンフレームのＷＳＣ ＩＥの属性の一覧である。

まず、インフラストラクチャ通信接続開始指示ビーコンには、「Selected Registrar」にＴＲＵＥが記載される。これにより、レジストラがエンローリをネットワークに追加するためにアクティベートされたことが通知される。また、インフラストラクチャ通信接続開始指示ビーコンには、「AuthorizedMACs」に、エンローリ３００のＭＡＣアドレスが記載される。また、第１の例では、インフラストラクチャ通信接続開始指示ビーコンには、「Registrar Configuration Methods」に、ＰＢＣモードであることを示す情報が記載される。この場合、インフラストラクチャ通信接続開始指示ビーコンは、図２を参照して上記説明したシーケンスにおける、ステップＳ１３で報知されるビーコンと同様である。他方、第２の例では、インフラストラクチャ通信接続開始指示ビーコンには、「Registrar Configuration Methods」に、Ｐ２Ｐ通信からインフラストラクチャ通信へ切り替えるための、レジストラ設定方法を示す情報が記載される。即ち、第２の例では、既存の規格にはない新たな情報が定義されることとなる。

（４）接続開始要求メッセージ
レジストラ２００（例えば、接続制御部２４３）は、ＡＰ１００とのインフラストラクチャ通信の接続を確立することを指示するメッセージをエンローリ３００へＰ２Ｐ通信により通知する。本メッセージは、例えばＬ４メッセージを用いて通知され得る。本メッセージを、以下では接続開始要求メッセージとも称する。レジストラ２００は、接続開始要求メッセージを用いることで、エンローリ３００が接続するタイミングを制御することが可能となる。

エンローリ３００（例えば、接続制御部３７３）は、接続開始要求メッセージを受信したことをトリガとして、インフラストラクチャ通信の接続に関する情報を表示し得る。具体的には、エンローリ３００は、ＡＰ１００経由でレジストラ２００と接続することを示す情報を表示する。このとき、エンローリ３００は、本表示に対するユーザ操作に応じて、インフラストラクチャ通信の接続を確立するか否かを判断してもよい。例えば、エンローリ３００は、ＡＰ１００経由でレジストラ２００と接続するか否かの選択肢をポップアップ表示して、ユーザ指示を受け付ける。これにより、ユーザの望まない接続切り替えを防止することが可能となる。

（５）インフラストラクチャ通信用設定情報
レジストラ２００（例えば、接続制御部２４３）は、ＡＰ１００との接続のための設定情報をエンローリ３００へＰ２Ｐ通信により通知してもよい。この情報を、以下ではインフラストラクチャ通信用設定情報とも称する。インフラストラクチャ通信用設定情報は、例えばＡＰ１００のＳＳＩＤ（Service Set Identifier）、ＢＳＳＩＤ（Basic Service Set Identifier）、ＭＡＣ（Media Access Control）アドレス、ポート情報、又はデバイス名（DevName）の少なくともいずれかを含み得る。エンローリ３００は、インフラストラクチャ通信用設定情報を参照することで、ＡＰ１００への接続処理を簡略化することが可能となる。

レジストラ２００（例えば、接続制御部２４３）は、インフラストラクチャ通信用設定情報をエンローリ３００へ通知することの許可を要求するメッセージをＡＰ１００へ通知してもよい。そして、ＡＰ１００（例えば、接続制御部１５３）は、自身とのインフラストラクチャ通信の接続のためのインフラストラクチャ通信用設定情報をエンローリ３００へ通知することを許可するか否かを示すメッセージをレジストラ２００へ通知する。レジストラ２００は、ＡＰ１００からの許可を受けた場合にのみ、インフラストラクチャ通信用設定情報をエンローリ３００へ通知する。このような仕組みにより、簡略化された接続処理においても、ＡＰ１００の接続ポリシを適切に反映させることが可能となる。また、ＡＰ１００（例えば、接続制御部１５３）は、自身とレジストラ２００とのインフラストラクチャ通信及びレジストラ２００とエンローリ３００とのＰ２Ｐ通信の同時接続を許可するか否かを示すメッセージをレジストラ２００へ通知してもよい。そして、レジストラ２００は、許可された場合はＰ２Ｐ通信の接続を切断せず、許可されなかった場合はＰ２Ｐ通信の接続を切断した上で、ＡＰ１００とエンローリ３００との接続のための処理を行う。このような仕組みにより、簡略化された接続処理においても、ＡＰ１００の接続ポリシを適切に反映させることが可能となる。

レジストラ２００は、Ｐ２Ｐ通信の接続を確立後、エンローリ３００との間でＴＣＰ接続又はＲＴＳＰ接続のリンクを確立して、インフラストラクチャ通信用設定情報を通知する。インフラストラクチャ通信用設定情報を通知するためのパケットフォーマットは、下記に一例を挙げるように多様に考えられる。
・Ｐ２Ｐ ＩＥ（Information Element）
・ＷＦＤ ＩＥ
・ＡＳＰ（Application Service Platform）用ＩＥ（例えば、ＡＳＰ２．０のフォーマットコマンドを用いて新規フォーマットが作成されてもよい）
・ＵＰｎＰ標準のプロトコルに規定されたパケット

例えば、これらのフォーマットのいずれか１つを用いたやり取りの過程で、エンローリ３００は、ＡＰ１００とレジストラ２００との間のアソシエイトされた周波数情報、及びレジストラ２００の無線回線のコンカレント情報を取得し得る。これにより、エンローリ３００は、使用すべき最適な周波数チャネルを判断することが可能となる。また、エンローリ３００は、インフラストラクチャ通信とＰ２Ｐ通信とを並行するのか、又は切り替え時にＰ２Ｐ通信を切断するのかを判断することが可能となる。なお、コンカレント情報とは、同一の周波数チャネルの時分割接続、異なる周波数チャネルの時分割接続、同一の周波数チャネルの同時接続、異なる周波数チャネルの同時接続、といった接続形態が可能か否かを示す情報である。

アソシエイトされた周波数情報及びコンカレント情報のやり取りは、Ｄｅｉｖｃｅ Ｄｉｓｃｏｖｅｒｙ又はＳｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙの処理の一貫として行われてもよいし、インフラストラクチャ通信用設定情報の通知の後に行われてもよい。アソシエイトされた周波数情報及びコンカレント情報のやり取り自体が行われなくてもよい。さらに、アソシエイトされた周波数情報及びコンカレント情報のやり取りの開始時に、レジストラ２００及びエンローリ３００は、どの情報のやりとりが可能か及びやり取りの手段を交渉してもよい。

なお、変形例として、レジストラ２００は、Ｐ２Ｐ通信の接続を確立する前に、ＡＰ１００を経由してエンローリ３００へインフラストラクチャ通信用設定情報を通知してもよい。また、インフラストラクチャ通信用設定情報の通知は、エンローリ３００により主導されてもよい。さらに、ＵＰｎＰによるコマンドのやり取りに関しては、フォーマットに基づき行われるものとする。加えて、上記処理に関わらず、例えば、エンローリ３００からＡＰ１００へのプローブリクエストに、Ｐ２Ｐ接続中の周波数が記載され、Ｐ２Ｐ通信とインフラストラクチャ通信とが同一周波数チャネルで行われてもよいものとする。レジストラ２００またはエンローリ３００が時分割コンカレント機能しか持たない場合、このような方法は有効である。

＜３．４．処理の流れ＞
以下、図８〜図１４を参照して、本実施形態に係る処理の流れを説明する。まず、レジストラ２００及びエンローリ３００の各々の単体での処理の流れを説明し、続いてシステム１全体における処理の流れを説明する。

（１）レジストラの処理
図８は、本実施形態に係るレジストラ２００において実行される接続切り替え処理の流れの一例を示すフローチャートである。

図８に示すように、まず、レジストラ２００は、エンローリ３００とのＰ２Ｐ通信の接続を確立する（ステップＳ１０２）。次いで、レジストラ２００は、レジストラ２００及びエンローリ３００がコンカレント機能に対応しているか否かを判断する（ステップＳ１０４）。いずれか一方が対応していないと判断された場合（ステップＳ１０４／ＮＯ）のみ、レジストラ２００は、エンローリ３００とのＰ２Ｐ通信の接続を切断する（ステップＳ１０６）。その後、レジストラ２００は、ＡＰ１００とのインフラストラクチャ通信の接続を確立する（ステップＳ１０８）。次いで、レジストラ２００は、エンローリ３００へＰ２Ｐ通信でインフラストラクチャ通信用設定情報を通知可能であるか否か（即ち、ＡＰ１００からの許可を受けたか否か）を判断する（ステップＳ１１０）。通知可能である場合（ステップＳ１１０／ＹＥＳ）にのみ、レジストラ２００は、エンローリ３００へＰ２Ｐ通信でインフラストラクチャ通信用設定情報を通知する（ステップＳ１１２）。

なお、ステップＳ１０６において、ＡＰ１００とのインフラストラクチャ通信用設定情報をレジストラ２００が既に保存している場合（例えば過去にＡＰ１００との接続履歴があり接続情報が残っている場合等）、レジストラ２００は、Ｐ２Ｐ接続の切断前にインフラストラクチャ通信用設定情報を通知してもよいものとする。通常、ステップＳ１０４においてコンカレント機能に対応していない場合、ステップＳ１１０もＮＯになり、ステップＳ１１２におけるインフラストラクチャ通信用設定情報の通知は行われない。これに対し、ステップＳ１０６の時点で通知しておくことで、エンローリ３００は、ステップＳ１１２が実行された場合と同様にインフラストラクチャ通信用設定を使う事が可能となる。

（２）エンローリの処理
図９は、本実施形態に係るレジストラ２００において実行される接続切り替え処理の流れの一例を示すフローチャートである。

図９に示すように、エンローリ３００は、インフラストラクチャ通信接続開始指示ビーコンを受信することで、ＰＢＣモードの開始を知得する（ステップＳ２０２）。次いで、エンローリ３００は、インフラストラクチャ通信用設定情報の通知を受けたか否かを判定する（ステップＳ２０４）。通知を受けた場合（ステップＳ２０４／ＹＥＳ）、エンローリ３００は、インフラストラクチャ通信用設定情報を用いてＡＰ１００とのインフラストラクチャ通信の接続を確立する（ステップＳ２０６）。通知を受けていない場合（ステップＳ２０４／ＮＯ）、エンローリ３００は、インフラストラクチャ通信用設定情報を用いずに、ＡＰ１００とのインフラストラクチャ通信の接続を確立する（ステップＳ２０８）。なお、ステップＳ２０４がＹＥＳの場合、エンローリ３００は、ステップＳ２０２を省略し、ＡＰ１００からビーコンを受信する前にプローブリクエストを送信してもよい。

（３）システム全体の処理（第１の例）
図１０は、本実施形態に係るシステム１において実行される接続切り替え処理の流れの一例を示すシーケンス図である。本シーケンスには、ＡＰ１００、レジストラ２００及びエンローリ３００が関与する。本シーケンスは、インフラストラクチャ通信用設定情報の通知が許可され、インフラストラクチャ通信及びＰ２Ｐ通信の同時接続が許可された場合の例である。

図１０に示すように、まず、レジストラ２００とエンローリ３００とはＰ２Ｐ通信の接続を確立する（ステップＳ３００）。次いで、レジストラ２００はＡＰ１００との間でインフラストラクチャ通信の接続を確立する（ステップＳ３１０）。次に、レジストラ２００は、ＰＢＣモード開始メッセージ及び接続許可要求メッセージをＡＰ１００へ通知する（ステップＳ３２０）。次いで、ＡＰ１００は、インフラストラクチャ通信接続開始指示ビーコンを報知する（ステップＳ３３０）。また、ＡＰ１００は、インフラストラクチャ通信用設定情報の通知を許可すること、及び同時接続を許可することを示すメッセージをレジストラ２００へ通知する（ステップＳ３４０）。次に、レジストラ２００は、接続開始要求メッセージ、及びインフラストラクチャ通信用設定情報をエンローリ３００へ通知する（ステップＳ３５０）。そして、エンローリ３００は、インフラストラクチャ通信用設定情報を用いて、ＡＰ１００との間でインフラストラクチャ通信の接続を確立する（ステップＳ３６０）。

以下では、図１１を参照して、図１０を参照して上記説明した処理の流れを、さらに詳細に説明する。図１１は、図１０に示した処理の流れを詳細に示すシーケンス図である。なお、ＡＰ１００からのビーコンは、ブロードキャスト信号であるため、レジストラ２００、エンローリ３００ともに受信している。以下の説明では、説明の簡略化のため、本実施例の特徴を説明する上で関係がない処理については説明を省略している。

まず、ステップＳ３１０における詳細な処理について説明する。レジストラ２００は、既にＡＰ１００からのビーコンを受信している状況（図１１では省略）で、プローブリクエストをＡＰ１００へ送信し（ステップＳ３１１）、ＡＰ１００からプローブレスポンスを受信する（ステップＳ３１２）。次いで、レジストラ２００は、プロビジョンディスカバリリクエストをＡＰ１００へ送信し（ステップＳ３１３）、ＡＰ１００からプロビジョンディスカバリレスポンスを受信する（ステップＳ３１４）。そして、レジストラ２００はＡＰ１００との間でＷＳＣ手続、４ウェイハンドシェイク手続、及びＩＰ割り当て手続を行う。

次いで、ステップＳ３２０における処理について説明する。レジストラ２００は、ＳｅｔＳｅｌｅｃｔｅｄＲｅｇｉｓｔｒａｒ（ＳＲ＝ＴＲＵＥ、ＰＢＣ）をＡＰ１００へ通知する（ステップＳ３２１）。本メッセージは、ＰＢＣモード開始メッセージに相当する。次いで、レジストラ２００は、接続許可要求メッセージをＡＰ１００へ通知する（ステップＳ３２２）。

次に、ステップＳ３３０における処理について説明する。ＡＰ１００は、初期状態ではＳＲ（Selected Registrar）＝Ｆａｌｓｅとなっており、ＳＲ＝Ｆａｌｓｅがセットされたビーコンを報知する。しかし、ＡＰ１００は、ＰＢＣモード開始メッセージが通知されたことをトリガとして、状態がＳＲ＝ＴＲＵＥに変更される。そして、ＡＰ１００は、ＳＲ＝ＴＲＵＥが記載され「Registrar Configuration Methods」にＰＢＣモードであることを示す情報が記載されたビーコンを報知する（ステップＳ３３０）。

次いで、ステップＳ３６０における処理について説明する。ここでは、図２を参照して上記説明した、ステップＳ１５以降と同様の処理が行われる。詳しくは、エンローリ３００は、「Registrar Configuration Methods」をＰＢＣモードとし、ＡＰ１００経由で（例えば、パケットのトンネル処理を利用して）レジストラ２００とのやり取りを開始する。具体的には、ＷＳＣで規定されているようなＭ１メッセージ送信からＷＳＣ処理を開始する。Ｍ１メッセージは、外部レジストラ（External Registrar）であるレジストラ２００に対し、ＵＰｎＰイベントを承認した事を通知するためのものである。レジストラ２００及びエンローリ３００は、ＵＰｎＰを用いてＭ１からＭ８までのメッセージのやり取りを行う。エンローリ３００は、Ｍ８メッセージの受信により、レジストラ２００が有するクレデンシャルを把握する。最後に、レジストラ２００は、ＡＰ１００の状態をＳＲ（Selected Registrar）＝Ｆａｌｓｅに変更するために、ＳｅｔＳｅｌｅｃｔｅｄＲｅｇｉｓｔｒａｒ（ＳＲ＝ＦＡＬＳＥ）を通知する。なお、上述したＷＳＣ処理は、装置ごとに行われる。また、上記ＷＳＣ処理のために、ＡＰ１００がトンネル処理に対応していることが望ましい。

（４）システム全体の処理（第２の例）
図１２は、本実施形態に係るシステム１において実行される接続切り替え処理の流れの一例を示すシーケンス図である。本シーケンスには、ＡＰ１００、レジストラ２００及びエンローリ３００が関与する。本シーケンスは、レジストラ２００又はエンローリ３００がコンカレント機能に対応していない場合の例である。図１３は、図１２に示すシーケンスにおけるトポロジの変化を説明するための説明図である。図１３に示すように、本シーケンスでは、レジストラ２００及びエンローリ３００がＰ２Ｐ通信の接続を確立する（符号２０）。次いで、レジストラ２００はＰ２Ｐ通信の接続を切断してＡＰ１００とのインフラストラクチャ通信の接続を確立し、エンローリ３００はＡＰ１００とのインフラストラクチャ通信の接続を試みる（符号２２）。

図１２に示すように、まず、レジストラ２００とエンローリ３００とはＰ２Ｐ通信の接続を確立する（ステップＳ４０２）。次いで、レジストラ２００は、接続開始要求メッセージをエンローリ３００へ通知する（ステップＳ４０４）。次に、レジストラ２００は、エンローリ３００とのＰ２Ｐ通信の接続を切断する（ステップＳ４０６）。次いで、レジストラ２００はＡＰ１００との間でインフラストラクチャ通信の接続を確立する（ステップＳ４０８）。次に、レジストラ２００は、ＰＢＣモード開始メッセージ及び接続許可要求メッセージをＡＰ１００へ通知する（ステップＳ４１０）。次いで、ＡＰ１００は、インフラストラクチャ通信接続開始指示ビーコンを報知する（ステップＳ４１２）。そして、エンローリ３００は、インフラストラクチャ通信用設定情報を用いずに、ＡＰ１００との間でインフラストラクチャ通信の接続を確立する（ステップＳ４１４）。

（５）システム全体の処理（第３の例）
図１４は、本実施形態に係るシステム１において実行される接続切り替え処理の流れの一例を示すシーケンス図である。本シーケンスには、ＡＰ１００、レジストラ２００及びエンローリ３００が関与する。本シーケンスは、インフラストラクチャ通信用設定情報の通知が禁止され、インフラストラクチャ通信及びＰ２Ｐ通信の同時接続が禁止された場合の例である。

図１４に示すように、まず、レジストラ２００とエンローリ３００とはＰ２Ｐ通信の接続を確立する（ステップＳ５０２）。次いで、レジストラ２００はＡＰ１００との間でインフラストラクチャ通信の接続を確立する（ステップＳ５０４）。次に、レジストラ２００は、ＰＢＣモード開始メッセージ及び接続許可要求メッセージをＡＰ１００へ通知する（ステップＳ５０６）。次いで、ＡＰ１００は、インフラストラクチャ通信接続開始指示ビーコンを報知する（ステップＳ５０８）。また、ＡＰ１００は、インフラストラクチャ通信用設定情報の通知を禁止すること、及び同時接続を禁止することを示すメッセージをレジストラ２００へ通知する（ステップＳ５１０）。これらの禁止を受けて、レジストラ２００は、接続開始要求メッセージをエンローリ３００へ通知し（ステップＳ５１２）、エンローリ３００とのＰ２Ｐ通信の接続を切断する（ステップＳ５１４）。そして、エンローリ３００は、インフラストラクチャ通信用設定情報を用いずに、ＡＰ１００との間でインフラストラクチャ通信の接続を確立する（ステップＳ５１６）。

＜＜４．第２の実施形態＞＞
＜４．１．状況設定＞
第２の実施形態では、ＳＴＡ２００とＳＴＡ３００との接続が、インフラストラクチャ通信からＰ２Ｐ通信へ切り替えられる状況における技術が開示される。以下、図１５を参照して、本実施形態の状況設定を説明する。

図１５は、本実施形態の状況設定を説明するための説明図である。図１５に示すように、まず、ＳＴＡ２００及びＳＴＡ３００は、ＡＰ１００を経由したインフラストラクチャ通信の接続を確立する（符号３０）。その後、ＡＰ１００が機能停止した又はアプリケーション（例えば、Ｍｉｒａｃａｓｔ）の要求遅延を満たさなくなった場合に（符号３１）、ＳＴＡ２００及びＳＴＡ３００はＰ２Ｐ通信の接続を試みる（符号３２）。

＜４．２．技術的課題＞
ＴＤＬＳ環境において、図１５を参照して上記説明したようにＡＰ１００が機能停止等した場合、Ｐ２Ｐ通信への切り替えの際にＴＤＬＳの再セットアップが行われていた。この再セットアップの処理が発生するために、Ｐ２Ｐ通信への切り替えに時間がかかっていた。

そこで、本実施形態では、図１５に示した状況下で、ＴＤＬＳの再セットアップの手順を簡略化する技術を提供する。

＜４．３．技術的特徴＞
（１）Ｐ２Ｐ通信用設定情報
グループオーナー（例えば、ＳＴＡ３００の接続制御部３７３）は、ＡＰ１００とのインフラストラクチャ通信の接続が確立しており、且つクライアント（例えば、ＳＴＡ２００）とＡＰ１００とのインフラストラクチャ通信の接続が確立していること（即ち、符号３０に示す環境の実現）を条件として、クライアントとのＰ２Ｐ通信の接続のための設定情報を、ＡＰ１００を経由するインフラストラクチャ通信によりクライアントへ通知する。インフラストラクチャ通信時とＰ２Ｐ通信時とでは、少なくとも機器のＳＳＩＤは変わる。そのため、ＳＳＩＤ等を含む設定情報を予め共有しておくことで、インフラストラクチャ通信からＰ２Ｐ通信への切り替えの際の処理時間を短縮することが可能となる。

この設定情報を、以下ではＰ２Ｐ通信用設定情報とも称する。なお、インフラストラクチャ通信時とＰ２Ｐ通信時とでは、使用するクレデンシャルも変わり得る。クレデンシャルについては、後に詳しく説明する。

インフラストラクチャ通信の接続時、ＳＴＡ２００及びＳＴＡ３００は、どちらがグループオーナー（Autonomous Group Owner）として機能するかを交渉する。グループオーナーが選択されると、グループオーナーは、Ｐ２Ｐ通信時に用いるＳＳＩＤ等を含むＰ２Ｐ通信用設定情報をクライアントとの間で共有する。Ｐ２Ｐ通信用設定情報は、グループオーナーのＳＳＩＤ、ＢＳＳＩＤ、ＭＡＣアドレス、ポート情報、デバイス名、又はグループＩＤの少なくともいずれかを含む。なお、Ｐ２Ｐ通信用設定情報として、クライアント側のＳＳＩＤ等が共有されてもよい。なお、情報交換は、インフラストラクチャ通信の暗号化されたチャネル上で行われる。

ここで、Ｐ２Ｐ通信用設定情報の交換は、ＳＴＡ２００及びＳＴＡ３００の双方がＷｉ−Ｆｉ Ｄｉｒｅｃｔに対応していることが確認されてから、行われてもよい。また、Ｐ２Ｐ通信用設定情報の交換は、ＡＰ１００による許可を得てから、行われてもよい。

また、インフラストラクチャ通信からＰ２Ｐ通信への切り替えは、ユーザ指示により行われてもよい。例えば、ＳＴＡ２００又はＳＴＡ３００は、切り替えを行うか否かの選択肢をポップアップ表示して、ユーザ指示を受け付けてもよい。これにより、ユーザの望まない接続切り替えを防止することが可能となる。なお、ユーザ指示の受付は、Ｐ２Ｐ通信用設定情報の交換の際に行われてもよい。

以下では、ＳＴＡ２００がソース機器であると共にクライアントであり、ＳＴＡ３００がシンク機器であると共にグループオーナーであるものとして説明する。

（２）クレデンシャル
Ｐ２Ｐ通信の接続を確立する際のクレデンシャルについて考察する。Ｐ２Ｐ通信におけるクレデンシャルは、グループ鍵であるＧＴＫ（Group Transient Key）、及び事前共有鍵であるＰＳＫ（Pre-Shared Key）を含み得る。例えば、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔにおいては、クライアントは、グループオーナーに一度接続すると、当該グループオーナーとの接続のためのクレデンシャルをその後も保持して、再度の接続の際に再利用する。そのため、クライアントがクレデンシャルを保持している場合、保持していない場合と比較して、再度の接続の際のＷＰＳのための処理時間が短縮される。以下では、クライアントがクレデンシャルを保持している場合としていない場合とに分けて、再接続に関して説明する。

・クライアントがクレデンシャルを保持している場合
クライアントは、Ｐ２Ｐ通信用設定情報によりＳＳＩＤ、グループＩＤ及びＭＡＣアドレスを把握した後、Persistentグループを実行する（Invokeする）だけでよい。以下、図１６を参照して、クライアントがクレデンシャルを保持している場合の、インフラストラクチャ通信からＰ２Ｐ通信への切り替え処理について説明する。

図１６は、インフラストラクチャ通信からＰ２Ｐ通信への切り替え処理の流れの一例を示すシーケンス図である。本シーケンスには、ＡＰ１００、ソース機器２００及びシンク機器３００が関与する。

まず、ＡＰ１００とソース機器２００の間で、及びＡＰ１００とシンク機器３００との間で、それぞれＷＦＤケイパビリティネゴシエーションが行われる（ステップＳ６０２）。ＷＦＤケイパビリティネゴシエーションの内容は、図３を参照して上記説明した通りである。その後、ソース機器２００からＡＰ１００を経由してシンク機器３００へ、映像が伝送される（ステップＳ６０４）。

その後、ＡＰ１００とソース機器２００との間、及びＡＰ１００とシンク機器３００との間の接続が切断されると（ステップＳ６０６）、ソース機器２００はＰ２Ｐインビテーションリクエストをシンク機器３００へ送信する（ステップＳ６０８）。次いで、シンク機器３００はＰ２Ｐインビテーションレスポンスをソース機器２００へ送信する（ステップＳ６１０）。そして、ソース機器２００及びシンク機器３００は、４ウェイハンドシェイクを行い（ステップＳ６１２）、ＷＦＤケイパビリティネゴシエーションを行って（ステップＳ６１４）、映像伝送を再開する（ステップＳ６１６）。

・クライアントがクレデンシャルを保持していない場合
クライアントがクレデンシャルを保持していない場合、図１６に示した処理に加えて、ＷＰＳのための処理が行われる。以下、図１７を参照して、クライアントがクレデンシャルを保持していない場合の、インフラストラクチャ通信からＰ２Ｐ通信への切り替え処理について説明する。

図１７は、インフラストラクチャ通信からＰ２Ｐ通信への切り替え処理の流れの一例を示すシーケンス図である。本シーケンスには、ＡＰ１００、ソース機器２００及びシンク機器３００が関与する。

本シーケンスは、図１６に示したシーケンスのステップＳ６１２に代えて、ステップＳ６１３が含まれる点で、図１６に示したシーケンスと相違する。ステップＳ６１３では、ソース機器２００及びシンク機器３００は、４ウェイハンドシェイクに加えて、アソシエーション及びＩＰアドレスの割当てを行う。

図１６及び図１７を参照すると、クライアントがクレデンシャルを保持していない場合、保持している場合と比較して、アソシエーション及びＩＰアドレスの割当てが追加的に行われており、その分処理時間がかかることが分かる。そこで、本実施形態では、クレデンシャルを事前に通知しておくことで、クライアントがクレデンシャルを保持していない（即ち、過去に一度も接続していない）場合であっても、図１６に示したシーケンスでの切り替えを可能にし、処理時間を短縮する仕組みを提供する。

例えば、クライアントは、アソシエーション時又は４ウェイハンドシェイク時に、ＧＴＫをグループオーナーから取得する。また、クライアントは、インフラストラクチャ通信の接続時にＳＴＡ２００とＳＴＡ３００との間で使われていた鍵を、ＰＳＫとして任意のアルゴリズムにより取得する。ここで、これらの情報交換は、インフラストラクチャ通信の暗号化されたチャネル上で行われる。具体的には、インフラストラクチャ通信路上で、Ｗｉ−Ｆｉ ＤｉｒｅｃｔのＷＳＣ処理が行われ得る。なお、クレデンシャルも、Ｐ２Ｐ通信用設定情報のひとつとして捉えられてもよい。

（３）ポリシ
次に、ＳＴＡ２００とＳＴＡ３００とが、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ接続を効率的に行うためのポリシについて考察する。

クレデンシャルに関して上記説明したように、グループオーナーとクライアントとの間でＰＳＫが共有された状態を想定する。その場合、インフラストラクチャ通信からＰ２Ｐ通信に切り替えられる際に、ＰａｓｓＰｈｒａｓｅのみを変更し、ＷＰＳのための処理を省略する方法が採用されてもよい。それに代えて、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔが立ち上がる前又は後に何らかのルールでＰＳＫを再生成して事前にやり取りする、又は何らかの形でＰＳＫをリフレッシュして、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ回線で使用する方法が採用されてもよい。このようなポリシの採用により、ＷＰＳ処理のための処理遅延を削減することができる。

（４）ＩＰアドレス
次に、ＩＰアドレスの変更方法について説明する。インフラストラクチャ通信においては、ＡＰ１００がＤＨＣＰサーバとして機能する、又はＡＰ１００よりもネットワーク側にＤＨＣＰサーバが配置される。一方で、Ｐ２Ｐ通信においては、グループオーナーがＤＨＣＰサーバとして機能する。

そのため、インフラストラクチャ通信からＰ２Ｐ通信に切り替わる際に、グループオーナーがＤＨＣＰサーバを起動し、ＩＰアドレスの割当てを行う。また、ＭｉｒａｃａｓｔにおいてＨＤＣＰが使用されていた場合、ＩＰアドレスの割当て変更に伴い、ＨＤＣＰを繋ぎ直すための処理が要される。これらの処理時間は、短縮されることが望ましい。

そこで、インフラストラクチャ通信時とＰ２Ｐ通信時とで、ＤＨＣＰサーバが共通化される。また、インフラストラクチャ通信時のＩＰアドレスとＰ２Ｐ通信時のＩＰアドレスを同一のサブネットで動作するものとする。また、インフラストラクチャ通信時には、ＡＰ１００がＤＨＣＰサーバとして機能するものとし、ＡＰ１００とグループオーナーのＩＰアドレスも入れ替えられる。このような仕組みにより、元々ＤＨＣＰ認証ができているソース機器２００とシンク機器３００との回線において、ソース機器とシンク機器のＩＰアドレスが変更しなければ、継続して利用可能となる。さらに、ソース機器２００からシンク機器３００への映像又は音声の伝送において、ＩＰアドレス割り当ての時間を削減することが可能となる。なお、ソース機器のＤＨＣＰポリシはシンク機器のＤＨＣＰポリシと同等のものにすることが好ましい。

（５）補足
上記では、ソース機器２００がクライアントであり、シンク機器３００がグループオーナーであるものとして説明したが、本技術はかかる例に限定されない。例えば、ソース機器２００がグループオーナーであり、シンク機器３００がクライアントであってもよい。その場合、ソース機器２００が持つＤＨＣＰサーバの代理サーバが、インフラストラクチャ通信にて管理されていたＤＨＣＰサーバになる。また、インフラストラクチャ通信からＰ２Ｐ通信へ切り替えられる際には、ＤＨＣＰサーバが設定したＩＰアドレス情報が、ＡＰ１００からグループオーナーであるソース機器２００に転送されてもよい。そして、グループオーナーのＤＨＣＰサーバが、インフラストラクチャ通信時のＩＰアドレスを継続して使用してもよい。

また、ソース機器２００とシンク機器３００との間で、Ｍｉｒａｃａｓｔのようなアプリケーションが動作していてもよい。そのようなアプリケーションにとっては、宛先がＡＰ１００からシンク機器３００へ変更される方が、送信元が変更される場合と比較して、変更処理が簡易になると考えられる。そこで、ソース機器２００のＩＰアドレスを変更せず、シンク機器３００がグループオーナーとして機能し、ＡＰ１００で使用していたＩＰアドレスをシンク機器３００が引き継ぐことが望ましい。そのため、Ｐ２Ｐ通信への切り替え時に、ＳＴＡ２００又はＳＴＡ３００のいずれがグループオーナーとなるべきかを、アプリケーションが選択してもよい。

また、ソース機器２００からシンク機器３００へのコンテンツの伝送には、インフラストラクチャ通信及びＰ２Ｐ通信の両方が用いられてもよい。この２つの伝送路で送信されるコンテンツは同一であってもよいし、異なっていてもよい。一般的に、周波数チャネルが同一であれば、Ｐ２Ｐ通信よりも、インフラストラクチャ通信の方が、サービス距離が長くなる。しかし、インフラストラクチャ通信では、アップリンク（即ち、ソース機器２００からＡＰ１００への通信）とダウンリンク（即ち、ＡＰ１００からシンク機器３００への通信）とに同一周波数チャネルが用いられる場合に伝送帯域が狭くなる。そこで、例えばインフラストラクチャ通信で確実なデータ伝送が要されるコンテンツが送信され、Ｐ２Ｐ通信でその他のコンテンツが送信されてもよい。例えば、インフラストラクチャ通信で映像が伝送され、Ｐ２Ｐ通信で音声が伝送されてもよい。このような、インフラストラクチャ通信及びＰ２Ｐ通信の両方を用いたコンテンツ伝送により、安定したコンテンツ伝送が実現される。

＜４．４．処理の流れ＞
図１８は、本実施形態に係るソース機器２００において実行される接続切り替え処理の流れの一例を示すフローチャートである。

まず、ソース機器２００は、シンク機器３００とのＡＰ１００を経由したインフラストラクチャ通信の接続を確立する（ステップＳ７０２）。次いで、ソース機器２００は、Ｐ２Ｐ通信用設定情報をシンク機器３００との間で交換する。

ソース機器２００は、ＡＰ１００との接続が強制切断されるまで（ステップＳ７０６／ＮＯ）待機し、強制切断された場合（ステップＳ７０６／ＹＥＳ）、シンク機器３００との間でＰ２Ｐ通信の接続がすでに確立されているか否かを判定する（ステップＳ７０８）。

Ｐ２Ｐ通信の接続がすでに確立されていると判定された場合（ステップＳ７０８／ＹＥＳ）、ソース機器２００は、シンク機器３００との間の通信（例えば、コンテンツの伝送）を、すでに確立されているＰ２Ｐ回線を用いて継続する（ステップＳ７１０）。一方で、Ｐ２Ｐ通信の接続が確立されていないと判定された場合（ステップＳ７０８／ＮＯ）、ソース機器２００は、Ｐ２Ｐ通信用設定情報を用いて、シンク機器３００との間でＰ２Ｐ通信の接続を確立する（ステップＳ７１２）。

なお、上記ではソース機器２００における処理の流れを説明したが、シンク機器３００においても同様の処理が行われ得る。

＜＜５．応用例＞＞
本開示に係る技術は、様々な製品へ応用可能である。例えば、ＳＴＡ２００及びＳＴＡ３００は、スマートフォン、タブレットＰＣ（Personal Computer）、ノートＰＣ、携帯型ゲーム端末若しくはデジタルカメラなどのモバイル端末、複眼カメラ（３６０度を同時または合成処理により撮像可能なカメラも含む）、テレビジョン受像機、プリンタ、デジタルスキャナ若しくはネットワークストレージなどの固定端末、又はカーナビゲーション装置などの車載端末として実現されてもよい。また、ＳＴＡ２００及びＳＴＡ３００は、スマートメータ、自動販売機、遠隔監視装置又はＰＯＳ（Point Of Sale）端末などの、Ｍ２Ｍ（Machine To Machine）通信を行う端末（ＭＴＣ（Machine Type Communication）端末ともいう）として実現されてもよい。さらに、ＳＴＡ２００及びＳＴＡ３００は、これら端末に搭載される無線通信モジュール（例えば、１つのダイで構成される集積回路モジュール）であってもよい。

一方、例えば、ＡＰ１００は、ルータ機能を有し又はルータ機能を有しない無線ＬＡＮアクセスポイント（無線基地局ともいう）として実現されてもよい。また、ＡＰ１００は、モバイル無線ＬＡＮルータとして実現されてもよい。さらに、ＡＰ１００は、これら装置に搭載される無線通信モジュール（例えば、１つのダイで構成される集積回路モジュール）であってもよい。

＜５．１．第１の応用例＞
図１９は、本開示に係る技術が適用され得るスマートフォン９００の概略的な構成の一例を示すブロック図である。スマートフォン９００は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１３、アンテナスイッチ９１４、アンテナ９１５、バス９１７、バッテリー９１８及び補助コントローラ９１９を備える。

プロセッサ９０１は、例えばＣＰＵ（Central Processing Unit）又はＳｏＣ（System on Chip）であってよく、スマートフォン９００のアプリケーションレイヤ及びその他のレイヤの機能を制御する。メモリ９０２は、ＲＡＭ（Random Access Memory）及びＲＯＭ（Read Only Memory）を含み、プロセッサ９０１により実行されるプログラム及びデータを記憶する。ストレージ９０３は、半導体メモリ又はハードディスクなどの記憶媒体を含み得る。外部接続インタフェース９０４は、メモリーカード又はＵＳＢ（Universal Serial Bus）デバイスなどの外付けデバイスをスマートフォン９００へ接続するためのインタフェースである。

カメラ９０６は、例えば、ＣＣＤ（Charge Coupled Device）又はＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像素子を有し、撮像画像を生成する。センサ９０７は、例えば、測位センサ、ジャイロセンサ、地磁気センサ及び加速度センサなどのセンサ群を含み得る。マイクロフォン９０８は、スマートフォン９００へ入力される音声を音声信号へ変換する。入力デバイス９０９は、例えば、表示デバイス９１０の画面上へのタッチを検出するタッチセンサ、キーパッド、キーボード、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９１０は、液晶ディスプレイ（ＬＣＤ）又は有機発光ダイオード（ＯＬＥＤ）ディスプレイなどの画面を有し、スマートフォン９００の出力画像を表示する。スピーカ９１１は、スマートフォン９００から出力される音声信号を音声に変換する。

無線通信インタフェース９１３は、ＩＥＥＥ８０２．１１ａ、１１ｂ、１１ｇ、１１ｎ、１１ａｃ及び１１ａｄなどの無線ＬＡＮ標準のうちの１つ以上をサポートし、無線通信を実行する。無線通信インタフェース９１３は、インフラストラクチャーモードにおいては、他の装置と無線ＬＡＮアクセスポイントを介して通信し得る。また、無線通信インタフェース９１３は、アドホックモード又はＷｉ−Ｆｉ Ｄｉｒｅｃｔ（登録商標）等のダイレクト通信モードにおいては、他の装置と直接的に通信し得る。なお、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔでは、アドホックモードとは異なり２つの端末の一方がアクセスポイントとして動作するが、通信はそれら端末間で直接的に行われる。無線通信インタフェース９１３は、典型的には、ベースバンドプロセッサ、ＲＦ（Radio Frequency）回路及びパワーアンプなどを含み得る。無線通信インタフェース９１３は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を集積したワンチップのモジュールであってもよい。無線通信インタフェース９１３は、無線ＬＡＮ方式に加えて、近距離無線通信方式、近接無線通信方式又はセルラ通信方式などの他の種類の無線通信方式をサポートしてもよい。アンテナスイッチ９１４は、無線通信インタフェース９１３に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９１５の接続先を切り替える。アンテナ９１５は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９１３による無線信号の送信及び受信のために使用される。

なお、図１９の例に限定されず、スマートフォン９００は、複数のアンテナ（例えば、無線ＬＡＮ用のアンテナ及び近接無線通信方式用のアンテナ、など）を備えてもよい。その場合に、アンテナスイッチ９１４は、スマートフォン９００の構成から省略されてもよい。

バス９１７は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１３及び補助コントローラ９１９を互いに接続する。バッテリー９１８は、図中に破線で部分的に示した給電ラインを介して、図１９に示したスマートフォン９００の各ブロックへ電力を供給する。補助コントローラ９１９は、例えば、スリープモードにおいて、スマートフォン９００の必要最低限の機能を動作させる。

図１９に示したスマートフォン９００において、図５を用いて説明したＳＴＡ２００に含まれるひとつ以上の構成要素（例えば、無線通信部２２０、制御信号送受信部２３０、処理部２４０、画像・音声信号生成部２５０、画像・音声圧縮部２６０、又はストリーム送信部２７０の少なくともいずれか）は、無線通信インタフェース９１３において実装されてもよい。また、図１９に示したスマートフォン９００において、図６を用いて説明したＳＴＡ３００に含まれるひとつ以上の構成要素（例えば、無線通信部３２０、ストリーム受信部３３０、画像・音声展開部３４０、処理部３７０、又は制御信号送受信部３８０の少なくともいずれか）は、無線通信インタフェース９１３において実装されてもよい。また、これら構成要素の少なくとも一部は、プロセッサ９０１又は補助コントローラ９１９において実装されてもよい。一例として、スマートフォン９００は、無線通信インタフェース９１３、プロセッサ９０１、及び／又は補助コントローラ９１９を含むモジュールを搭載し、当該モジュールにおいて上記ひとつ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記ひとつ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記ひとつ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記ひとつ以上の構成要素として機能させるためのプログラムがスマートフォン９００にインストールされ、無線通信インタフェース９１３、プロセッサ９０１、及び／又は補助コントローラ９１９が当該プログラムを実行してもよい。以上のように、上記ひとつ以上の構成要素を備える装置としてスマートフォン９００又は上記モジュールが提供されてもよく、プロセッサを上記ひとつ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。

また、図１９に示したスマートフォン９００において、図５を参照して説明したアンテナ部２１０又は図６を参照して説明したアンテナ部３１０は、アンテナ９１５において実装されてもよい。また、図５を参照して説明した出力部２９０又は図６を参照して説明した画像・音声出力部３５０は、表示デバイス９１０又はスピーカ９１１において実装されてもよい。また、図５を参照して説明した操作受付部２８０又は図６を参照して説明した操作受付部３６０は、入力デバイス９０９において実装されてもよい。

なお、スマートフォン９００は、プロセッサ９０１がアプリケーションレベルでアクセスポイント機能を実行することにより、無線アクセスポイント（ソフトウェアＡＰ）として動作してもよい。また、無線通信インタフェース９１３が無線アクセスポイント機能を有していてもよい。

＜５．２．第２の応用例＞
図２０は、本開示に係る技術が適用され得るカーナビゲーション装置９２０の概略的な構成の一例を示すブロック図である。カーナビゲーション装置９２０は、プロセッサ９２１、メモリ９２２、ＧＰＳ（Global Positioning System）モジュール９２４、センサ９２５、データインタフェース９２６、コンテンツプレーヤ９２７、記憶媒体インタフェース９２８、入力デバイス９２９、表示デバイス９３０、スピーカ９３１、無線通信インタフェース９３３、アンテナスイッチ９３４、アンテナ９３５及びバッテリー９３８を備える。

プロセッサ９２１は、例えばＣＰＵ又はＳｏＣであってよく、カーナビゲーション装置９２０のナビゲーション機能及びその他の機能を制御する。メモリ９２２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９２１により実行されるプログラム及びデータを記憶する。

ＧＰＳモジュール９２４は、ＧＰＳ衛星から受信されるＧＰＳ信号を用いて、カーナビゲーション装置９２０の位置（例えば、緯度、経度及び高度）を測定する。センサ９２５は、例えば、ジャイロセンサ、地磁気センサ及び気圧センサなどのセンサ群を含み得る。データインタフェース９２６は、例えば、図示しない端子を介して車載ネットワーク９４１に接続され、車速データなどの車両側で生成されるデータを取得する。

コンテンツプレーヤ９２７は、記憶媒体インタフェース９２８に挿入される記憶媒体（例えば、ＣＤ又はＤＶＤ）に記憶されているコンテンツを再生する。入力デバイス９２９は、例えば、表示デバイス９３０の画面上へのタッチを検出するタッチセンサ、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９３０は、ＬＣＤ又はＯＬＥＤディスプレイなどの画面を有し、ナビゲーション機能又は再生されるコンテンツの画像を表示する。スピーカ９３１は、ナビゲーション機能又は再生されるコンテンツの音声を出力する。

無線通信インタフェース９３３は、ＩＥＥＥ８０２．１１ａ、１１ｂ、１１ｇ、１１ｎ、１１ａｃ及び１１ａｄなどの無線ＬＡＮ標準のうちの１つ以上をサポートし、無線通信を実行する。無線通信インタフェース９３３は、インフラストラクチャーモードにおいては、他の装置と無線ＬＡＮアクセスポイントを介して通信し得る。また、無線通信インタフェース９３３は、アドホックモード又はＷｉ−Ｆｉ Ｄｉｒｅｃｔ等のダイレクト通信モードにおいては、他の装置と直接的に通信し得る。無線通信インタフェース９３３は、典型的には、ベースバンドプロセッサ、ＲＦ回路及びパワーアンプなどを含み得る。無線通信インタフェース９３３は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を集積したワンチップのモジュールであってもよい。無線通信インタフェース９３３は、無線ＬＡＮ方式に加えて、近距離無線通信方式、近接無線通信方式又はセルラ通信方式などの他の種類の無線通信方式をサポートしてもよい。アンテナスイッチ９３４は、無線通信インタフェース９３３に含まれる複数の回路の間でアンテナ９３５の接続先を切り替える。アンテナ９３５は、単一の又は複数のアンテナ素子を有し、無線通信インタフェース９３３による無線信号の送信及び受信のために使用される。

なお、図２０の例に限定されず、カーナビゲーション装置９２０は、複数のアンテナを備えてもよい。その場合に、アンテナスイッチ９３４は、カーナビゲーション装置９２０の構成から省略されてもよい。

バッテリー９３８は、図中に破線で部分的に示した給電ラインを介して、図２０に示したカーナビゲーション装置９２０の各ブロックへ電力を供給する。また、バッテリー９３８は、車両側から給電される電力を蓄積する。

図２０に示したカーナビゲーション装置９２０において、図５を用いて説明したＳＴＡ２００に含まれるひとつ以上の構成要素（例えば、無線通信部２２０、制御信号送受信部２３０、処理部２４０、画像・音声信号生成部２５０、画像・音声圧縮部２６０、又はストリーム送信部２７０の少なくともいずれか）は、無線通信インタフェース９３３において実装されてもよい。また、図２０に示したカーナビゲーション装置９２０において、図６を用いて説明したＳＴＡ３００に含まれるひとつ以上の構成要素（例えば、無線通信部３２０、ストリーム受信部３３０、画像・音声展開部３４０、処理部３７０、又は制御信号送受信部３８０の少なくともいずれか）は、無線通信インタフェース９３３において実装されてもよい。また、これら機能の少なくとも一部は、プロセッサ９２１において実装されてもよい。一例として、カーナビゲーション装置９２０は、無線通信インタフェース９３３、及び／又はプロセッサ９２１を含むモジュールを搭載し、当該モジュールにおいて上記ひとつ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記ひとつ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記ひとつ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記ひとつ以上の構成要素として機能させるためのプログラムがカーナビゲーション装置９２０にインストールされ、無線通信インタフェース９３３、及び／又はプロセッサ９２１が当該プログラムを実行してもよい。以上のように、上記ひとつ以上の構成要素を備える装置としてカーナビゲーション装置９２０又は上記モジュールが提供されてもよく、プロセッサを上記ひとつ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。

また、図２０に示したカーナビゲーション装置９２０において、図５を参照して説明したアンテナ部２１０又は図６を参照して説明したアンテナ部３１０は、アンテナ９３５において実装されてもよい。また、図５を参照して説明した出力部２９０又は図６を参照して説明した画像・音声出力部３５０は、表示デバイス９３０又はスピーカ９３１において実装されてもよい。また、図５を参照して説明した操作受付部２８０又は図６を参照して説明した操作受付部３６０は、入力デバイス９２９において実装されてもよい。

また、無線通信インタフェース９３３は、上述したＡＰ１００として動作し、車両に乗るユーザが有する端末に無線接続を提供してもよい。

また、本開示に係る技術は、上述したカーナビゲーション装置９２０の１つ以上のブロックと、車載ネットワーク９４１と、車両側モジュール９４２とを含む車載システム（又は車両）９４０として実現されてもよい。車両側モジュール９４２は、車速、エンジン回転数又は故障情報などの車両側データを生成し、生成したデータを車載ネットワーク９４１へ出力する。

＜５．３．第３の応用例＞
図２１は、本開示に係る技術が適用され得る無線アクセスポイント９５０の概略的な構成の一例を示すブロック図である。無線アクセスポイント９５０は、コントローラ９５１、メモリ９５２、入力デバイス９５４、表示デバイス９５５、ネットワークインタフェース９５７、無線通信インタフェース９６３、アンテナスイッチ９６４及びアンテナ９６５を備える。

コントローラ９５１は、例えばＣＰＵ又はＤＳＰ（Digital Signal Processor）であってよく、無線アクセスポイント９５０のＩＰ（Internet Protocol）レイヤ及びより上位のレイヤの様々な機能（例えば、アクセス制限、ルーティング、暗号化、ファイアウォール及びログ管理など）を動作させる。メモリ９５２は、ＲＡＭ及びＲＯＭを含み、コントローラ９５１により実行されるプログラム、及び様々な制御データ（例えば、端末リスト、ルーティングテーブル、暗号鍵、セキュリティ設定及びログなど）を記憶する。

入力デバイス９５４は、例えば、ボタン又はスイッチなどを含み、ユーザからの操作を受け付ける。表示デバイス９５５は、ＬＥＤランプなどを含み、無線アクセスポイント９５０の動作ステータスを表示する。

ネットワークインタフェース９５７は、無線アクセスポイント９５０が有線通信ネットワーク９５８に接続するための有線通信インタフェースである。ネットワークインタフェース９５７は、複数の接続端子を有してもよい。有線通信ネットワーク９５８は、イーサネット（登録商標）などのＬＡＮであってもよく、又はＷＡＮ（Wide Area Network）であってもよい。

無線通信インタフェース９６３は、ＩＥＥＥ８０２．１１ａ、１１ｂ、１１ｇ、１１ｎ、１１ａｃ及び１１ａｄなどの無線ＬＡＮ標準のうちの１つ以上をサポートし、近傍の端末へアクセスポイントとして無線接続を提供する。無線通信インタフェース９６３は、典型的には、ベースバンドプロセッサ、ＲＦ回路及びパワーアンプなどを含み得る。無線通信インタフェース９６３は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を集積したワンチップのモジュールであってもよい。アンテナスイッチ９６４は、無線通信インタフェース９６３に含まれる複数の回路の間でアンテナ９６５の接続先を切り替える。アンテナ９６５は、単一の又は複数のアンテナ素子を有し、無線通信インタフェース９６３による無線信号の送信及び受信のために使用される。

図２１に示した無線アクセスポイント９５０において、図４を用いて説明した処理部１５０に含まれるひとつ以上の構成要素（例えば、無線通信部１２０、通信制御部１５１又は接続制御部１５３の少なくともいずれか）は、無線通信インタフェース９６３において実装されてもよい。また、これら機能の少なくとも一部は、コントローラ９５１において実装されてもよい。一例として、無線アクセスポイント９５０は、無線通信インタフェース９６３、及び／又はコントローラ９５１を含むモジュールを搭載し、当該モジュールにおいて上記ひとつ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記ひとつ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記ひとつ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記ひとつ以上の構成要素として機能させるためのプログラムが無線アクセスポイント９５０にインストールされ、無線通信インタフェース９６３、及び／又はコントローラ９５１が当該プログラムを実行してもよい。以上のように、上記ひとつ以上の構成要素を備える装置として無線アクセスポイント９５０又は上記モジュールが提供されてもよく、プロセッサを上記ひとつ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。

また、図２１に示した無線アクセスポイント９５０において、図４を参照して説明したアンテナ部１１０は、アンテナ９６５において実装されてもよい。また、図４を参照して説明したネットワーク通信部１３０は、ネットワークインタフェース９５７において実装されてもよい。また、図４を参照して説明した記憶部１４０は、メモリ９５２において実装されてもよい。

＜＜６．まとめ＞＞
以上、図１〜図２１を参照して、本開示の一実施形態について詳細に説明した。

第１の実施形態において説明したように、レジストラは、エンローリとのＰ２Ｐ通信及びＡＰとのインフラストラクチャ通信の接続が確立しており、且つエンローリとＡＰとのインフラストラクチャ通信の接続が確立していないことを条件として、エンローリとのインフラストラクチャ通信の接続を確立することを指示するメッセージをＡＰへ通知する。これにより、従来のＷＳＣ規格ではボタンが押されたことをトリガとして通知されていたＰＢＣモード開始メッセージが自動的に通知されることとなるので、ユーザによるボタン押下等の手間を削減することが可能となる。また、ＡＰ又はエンローリの視点では、従来のＷＳＣ規格からの変更なしに外部レジストラを用いた接続処理が実行されるので、従来のＷＳＣ規格に記載されているセキュリティレベルが確保される。

第２の実施形態において上記説明したように、グループオーナーは、ＡＰとのインフラストラクチャ通信の接続が確立しており、且つクライアントとＡＰとのインフラストラクチャ通信の接続が確立していることを条件として、クライアントとのＰ２Ｐ通信の接続のための設定情報を、ＡＰを経由するインフラストラクチャ通信によりクライアントへ通知する。これにより、ＡＰが機能停止した又はアプリケーションの要求遅延を満たさなくなった等の事情でインフラストラクチャ通信からＰ２Ｐ通信へ切り替えられる際の処理時間が短縮される。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

また、本明細書においてフローチャート及びシーケンス図を用いて説明した処理は、必ずしも図示された順序で実行されなくてもよい。いくつかの処理ステップは、並列的に実行されてもよい。また、追加的な処理ステップが採用されてもよく、一部の処理ステップが省略されてもよい。

また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

なお、以下のような構成も本開示の技術的範囲に属する。
（１）
他の装置とのＰ２Ｐ通信の接続が確立しており、アクセスポイントとのインフラストラクチャ通信の接続が確立している又は確立履歴があり、且つ前記他の装置と前記アクセスポイントとのインフラストラクチャ通信の接続が確立していないことを条件として、前記他の装置とのインフラストラクチャ通信の接続を確立することを指示するメッセージを前記アクセスポイントへ通知する処理部、
を備える装置。
（２）
前記処理部は、前記アクセスポイントとの接続のための設定情報を前記他の装置へＰ２Ｐ通信により通知する、前記（１）に記載の装置。
（３）
前記設定情報は、前記アクセスポイントのＳＳＩＤ（Service Set Identifier）、ＢＳＳＩＤ（Basic Service Set Identifier）、ＭＡＣ（Media Access Control）アドレス、ポート情報、又はデバイス名（DevName）の少なくともいずれかを含む、前記（２）に記載の装置。
（４）
前記処理部は、前記設定情報を前記他の装置へ通知することの許可を要求するメッセージを前記アクセスポイントへ通知する、前記（２）又は（３）に記載の装置。
（５）
前記処理部は、前記アクセスポイントとのインフラストラクチャ通信の接続を確立することを指示するメッセージを前記他の装置へＰ２Ｐ通信により通知する、前記（１）〜（４）のいずれか一項に記載の装置。
（６）
前記他の装置において、前記アクセスポイントとのインフラストラクチャ通信の接続を確立することを指示するメッセージを受信したことをトリガとして、インフラストラクチャ通信の接続に関する情報が表示される、前記（５）に記載の装置。
（７）
前記処理部は、前記他の装置を識別するための情報を前記アクセスポイントへ通知する、前記（１）〜（６）のいずれか一項に記載の装置。
（８）
前記他の装置を識別するための情報は、前記他の装置のＭＡＣアドレスである、前記（７）に記載の装置。
（９）
前記Ｐ２Ｐ通信は、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ（登録商標）又はＮＡＮ（neighborhood area network）に準拠した通信である、前記（１）〜（８）のいずれか一項に記載の装置。
（１０）
前記インフラストラクチャ通信は、Ｗｉ−Ｆｉ（登録商標）に準拠した通信である、前記（１）〜（９）のいずれか一項に記載の装置。
（１１）
自身とのインフラストラクチャ通信の接続が確立している又は確立履歴があり、第２の端末装置とのＰ２Ｐ通信の接続が確立している第１の端末装置から、前記第２の端末装置とのインフラストラクチャ通信の接続を開始することを指示するメッセージが通知されたことをトリガとして、前記第２の端末装置とのインフラストラクチャ通信の接続を確立するための処理を開始する処理部、
を備える装置。
（１２）
前記処理部は、前記第１の端末装置とのインフラストラクチャ通信の接続を開始するよう指示するメッセージを、前記第２の端末装置へ通知する、前記（１１）に記載の装置。
（１３）
前記処理部は、ＰＢＣ（Push Button Configuration）モードで動作していることを示す情報を含むビーコンを報知する、前記（１２）に記載の装置。
（１４）
前記処理部は、Ｐ２Ｐ通信からインフラストラクチャ通信へ切り替えることを指示する情報を含むビーコンを報知する、前記（１２）に記載の装置。
（１５）
前記処理部は、前記第１の端末装置から通知された前記第２の端末装置を識別するための情報により、通知されたひとつ以上のプローブリクエストのうち前記第２の端末装置から通知されたプローブリクエストを識別する、前記（１１）〜（１４）のいずれか一項に記載の装置。
（１６）
前記処理部は、自身とのインフラストラクチャ通信の接続のための設定情報を前記第２の端末装置へ通知することを許可するか否かを示すメッセージを前記第１の端末装置へ通知する、前記（１１）〜（１５）のいずれか一項に記載の装置。
（１７）
前記処理部は、自身と前記第１の端末装置とのインフラストラクチャ通信及び前記第１の端末装置と前記第２の端末装置とのＰ２Ｐ通信の同時接続を許可するか否かを示すメッセージを前記第１の端末装置へ通知する、前記（１１）〜（１６）のいずれか一項に記載の装置。
（１８）
アクセスポイントとのインフラストラクチャ通信の接続が確立しており、且つ他の端末と前記アクセスポイントとのインフラストラクチャ通信の接続が確立していることを条件として、前記他の装置とのＰ２Ｐ通信の接続のための設定情報を、前記アクセスポイントを経由するインフラストラクチャ通信により前記他の装置へ通知する処理部、
を備える装置。
（１９）
前記設定情報は、前記装置のＳＳＩＤ（Service Set Identifier）、ＢＳＳＩＤ（Basic Service Set Identifier）、ＭＡＣ（Media Access Control）アドレス、ポート情報、デバイス名（DevName）、又はグループＩＤの少なくともいずれかを含む、前記（１８）に記載の装置。
（２０）
他の装置とのＰ２Ｐ通信の接続が確立しており、アクセスポイントとのインフラストラクチャ通信の接続が確立している又は確立履歴があり、且つ前記他の装置と前記アクセスポイントとのインフラストラクチャ通信の接続が確立していないことを条件として、前記他の装置とのインフラストラクチャ通信の接続を確立することを指示するメッセージを前記アクセスポイントへプロセッサにより通知すること、
を含む方法。
（２１）
自身とのインフラストラクチャ通信の接続が確立している又は確立履歴があり、第２の端末装置とのＰ２Ｐ通信の接続が確立している第１の端末装置から、前記第２の端末装置とのインフラストラクチャ通信の接続を開始することを指示するメッセージが通知されたことをトリガとして、前記第２の端末装置とのインフラストラクチャ通信の接続を確立するための処理をプロセッサにより開始すること、
を含む方法。
（２２）
アクセスポイントとのインフラストラクチャ通信の接続が確立しており、且つ他の端末と前記アクセスポイントとのインフラストラクチャ通信の接続が確立していることを条件として、前記他の装置とのＰ２Ｐ通信の接続のための設定情報を、前記アクセスポイントを経由するインフラストラクチャ通信により前記他の装置へプロセッサにより通知すること、
を含む方法。

１ システム
１００ ＡＰ
１１０ アンテナ部
１２０ 無線通信部
１３０ ネットワーク通信部
１４０ 記憶部
１５０ 処理部
１５１ 通信制御部
１５３ 接続制御部
２００ ＳＴＡ、レジストラ、ソース機器
２１０ アンテナ部
２２０ 無線通信部
２３０ 制御信号送受信部
２４０ 処理部
２４１ コンテンツ制御部
２４３ 接続制御部
２５０ 画像・音声信号生成部
２６０ 画像・音声圧縮部
２７０ ストリーム送信部
２８０ 操作受付部
２９０ 出力部
３００ ＳＴＡ、エンローリ、シンク機器
３１０ アンテナ部
３２０ 無線通信部
３３０ ストリーム受信部
３４０ 画像・音声展開部
３５０ 画像・音声出力部
３５１ 表示部
３５２ 音声出力部
３６０ 操作受付部
３７０ 処理部
３７１ コンテンツ制御部
３７３ 接続制御部
３８０ 制御信号送受信部

Claims (17)

1. 自身と他の装置とのＰ２Ｐ通信の接続が確立しており、自身とアクセスポイントとのインフラストラクチャ通信の接続が確立している又は確立履歴があり、且つ前記他の装置と前記アクセスポイントとのインフラストラクチャ通信の接続が確立していないことを条件として、前記他の装置と前記アクセスポイントとのインフラストラクチャ通信の接続を確立することを指示する接続許可要求メッセージを前記アクセスポイントへインフラストラクチャ通信により通知し、前記他の装置と前記アクセスポイントとのインフラストラクチャ通信の接続を確立することを指示する接続開始要求メッセージを前記他の装置へＰ２Ｐ通信により通知し、自身と前記他の装置とのＰ２Ｐ通信を前記アクセスポイントを経由したインフラストラクチャ通信へ切り替える処理部、
   を備える装置。
2. 前記処理部は、前記他の装置と前記アクセスポイントとのインフラストラクチャ通信の接続のためのインフラストラクチャ通信用設定情報を前記他の装置へＰ２Ｐ通信により通知する、請求項１に記載の装置。
3. 前記インフラストラクチャ通信用設定情報は、前記アクセスポイントのＳＳＩＤ（Service Set Identifier）、ＢＳＳＩＤ（Basic Service Set Identifier）、ＭＡＣ（Media Access Control）アドレス、ポート情報、又はデバイス名（DevName）の少なくともいずれかを含む、請求項２に記載の装置。
4. 前記処理部は、前記インフラストラクチャ通信用設定情報を前記他の装置へ通知することの許可を要求するメッセージを前記アクセスポイントへ通知する、請求項２に記載の装置。
5. 前記他の装置において、前記他の装置と前記アクセスポイントとのインフラストラクチャ通信の接続を確立することを指示する前記接続開始要求メッセージを受信したことをトリガとして、インフラストラクチャ通信の接続に関する情報が表示される、請求項１に記載の装置。
6. 前記処理部は、前記他の装置を識別するための情報を前記アクセスポイントへ通知する、請求項１に記載の装置。
7. 前記他の装置を識別するための情報は、前記他の装置のＭＡＣアドレスである、請求項６に記載の装置。
8. 前記Ｐ２Ｐ通信は、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ（登録商標）又はＮＡＮ（neighborhood area network）に準拠した通信である、請求項１に記載の装置。
9. 前記インフラストラクチャ通信は、Ｗｉ−Ｆｉ（登録商標）に準拠した通信である、請求項１に記載の装置。
10. アクセスポイントである自身とのインフラストラクチャ通信の接続が確立している又は確立履歴があり、第２の端末装置とのＰ２Ｐ通信の接続が確立している第１の端末装置から、自身と前記第２の端末装置とのインフラストラクチャ通信の接続を確立することを指示する接続許可要求メッセージが通知されたことをトリガとして、前記第１の端末装置と前記第２の端末装置とのＰ２Ｐ通信を自身を経由したインフラストラクチャ通信に切り替えることを指示する情報を含むビーコンを前記第２の端末装置に報知し、自身と前記第２の端末装置とのインフラストラクチャ通信の接続を確立するための処理を開始し、前記第１の端末装置と前記第２の端末装置とのＰ２Ｐ通信を自身を経由したインフラストラクチャ通信へ切り替える処理部、
    を備える装置。
11. 前記ビーコンは、ＰＢＣ（Push Button Configuration）モードで動作していることを示す情報を含む、請求項１０に記載の装置。
12. 前記処理部は、前記第１の端末装置から通知された前記第２の端末装置を識別するための情報により、通知されたひとつ以上のプローブリクエストのうち前記第２の端末装置から通知されたプローブリクエストを識別する、請求項１０に記載の装置。
13. 前記処理部は、自身とのインフラストラクチャ通信の接続のための設定情報を前記第２の端末装置へ通知することを許可するか否かを示すメッセージを前記第１の端末装置へ通知する、請求項１０に記載の装置。
14. 前記処理部は、自身と前記第１の端末装置とのインフラストラクチャ通信及び前記第１の端末装置と前記第２の端末装置とのＰ２Ｐ通信の同時接続を許可するか否かを示すメッセージを前記第１の端末装置へ通知する、請求項１０に記載の装置。
15. 自身とアクセスポイントとのインフラストラクチャ通信の接続が確立しており、且つ他の装置と前記アクセスポイントとのインフラストラクチャ通信の接続が確立していることを条件として、自身と前記他の装置との前記アクセスポイントを経由したインフラストラクチャ通信から自身と前記他の装置とのＰ２Ｐ通信への切り替えを行わせるユーザ指示を受け付け、自身と前記他の装置とのＰ２Ｐ通信の接続のための設定情報を、前記アクセスポイントを経由するインフラストラクチャ通信により前記他の装置へ通知し、自身と前記他の装置との前記アクセスポイントを経由したインフラストラクチャ通信をＰ２Ｐ通信へ切り替える処理部、
    を備える装置。
16. 前記設定情報は、前記装置のＳＳＩＤ（Service Set Identifier）、ＢＳＳＩＤ（Basic Service Set Identifier）、ＭＡＣ（Media Access Control）アドレス、ポート情報、デバイス名（DevName）、又はグループＩＤの少なくともいずれかを含む、請求項１５に記載の装置。
17. 装置が、自身と他の装置とのＰ２Ｐ通信の接続が確立しており、自身とアクセスポイントとのインフラストラクチャ通信の接続が確立している又は確立履歴があり、且つ前記他の装置と前記アクセスポイントとのインフラストラクチャ通信の接続が確立していないことを条件として、前記他の装置と前記アクセスポイントとのインフラストラクチャ通信の接続を確立することを指示する接続許可要求メッセージを前記アクセスポイントへインフラストラクチャ通信により通知し、前記他の装置と前記アクセスポイントとのインフラストラクチャ通信の接続を確立することを指示する接続開始要求メッセージを前記他の装置へＰ２Ｐ通信により通知し、自身と前記他の装置とのＰ２Ｐ通信を前記アクセスポイントを経由したインフラストラクチャ通信へ切り替えることを、プロセッサにより実行する方法。

Images