JPWO2018051633A1 - 通信装置及び通信方法 - Google Patents

Abstract

Ｗｉ−Ｆｉ Ｐ２Ｐ仕様に則って好適に通信動作を行なう通信装置及び通信方法を提供する。ＷＦＤ Ｒ２のデバイスは、サービス・アドバータイザー機能又はサービス・シーカー機能のどちらか一方を動作させようとしたら、両方の機能を動作させるようにする。特に、デバイスがサービス・シーカーとしてのみ動作するという状況を避けるようにする。これによって、デバイスは、サービス・シーカーとして相手デバイスを発見できるだけでなく、サービス・アドバータイザーとして相手デバイスからも発見してもらうことができるようになる。

Description

本明細書で開示する技術は、Ｗｉ−Ｆｉ Ｐ２Ｐ（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）仕様に則って通信動作を行なう通信装置及び通信方法に関する。

最近、スマートフォンや電話、タブレットなどさまざまな情報端末が、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃ Ｅｎｇｉｎｅｅｒｓ）８０２．１１に代表される無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）規格に準拠した通信機能を標準で装備している。無線ＬＡＮとして、例えば、Ｗｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）、Ｗｉ−Ｆｉ Ｐ２Ｐ（以下、「Ｗｉ−Ｆｉダイレクト」又は「Ｗｉ−Ｆｉ Ｄｉｒｅｃｔ」と呼ばれることもある）、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ Ｍｉｒａｃａｓｔを用いることができる（例えば、特許文献１を参照のこと）。Ｗｉ−Ｆｉ Ｐ２Ｐを実装している情報端末は、簡単且つ手軽な操作で、印刷、情報の共有・同期化、画像表示などを行なうことができる。

特開２０１６−２８４６５号公報

本明細書で開示する技術の目的は、Ｗｉ−Ｆｉ Ｐ２Ｐ仕様に則って好適に通信動作を行なうことができる、優れた通信装置及び通信方法を提供することにある。

本明細書で開示する技術は、上記課題を参酌してなされたものであり、その第１の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）接続を用いるサービスをサポートする通信装置であって、
サービス・アドバータイザー機能又はサービス・シーカー機能のどちらか一方を動作させようとする際に、サービス・アドバータイザー機能及びサービス・シーカー機能の両方を動作させる、通信装置である。

本明細書の第２の側面によれば、第１の側面に係る通信装置は、同通信装置内で、ＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ）がサービス層からシーク・サービス・メソッドを受信したことをトリガーにしてサービス・シーカー機能を動作させ、さらにサービス・アドバータイザー機能の動作が停止しているときにはサービス・アドバータイザー機能も動作させるように構成されている。

また、本明細書で開示する技術の第３の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、
サービス・アドバータイザー機能のみを動作させているときに、対応可能なサービスを指定する要求又は問い合わせを受信したことをトリガーにして、サービス・シーカー機能の動作を開始する、通信装置である。

本明細書の第４の側面によれば、第３の側面に係る通信装置は、サービス・アドバータイザー機能のみを動作させているときに、対応可能なサービス名称にマッチするハッシュ値を含んだ要求又は対応可能なサービス名称を示す文字列を含んだ問い合わせを受信したことをトリガーにして、サービス・シーカー機能を動作させて他の通信装置へ対応可能なサービスを指定する要求又は問い合わせを送信するように構成されている。

また、本明細書で開示する技術の第５の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、使用できるチャネルに制限がない状況下において、
サービス・アドバータイザー機能のみを動作させているときに、ソーシャル・チャネル上で、対応可能なサービスを指定する要求又は問い合わせを所定の時間内に受信できなかったことをトリガーにして、サービス・シーカー機能の動作を開始して、対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信する、通信装置である。

本明細書の第６の側面によれば、第５の側面に係る通信装置は、サービス・シーカー機能を用いて送信した要求又は問い合わせに対する応答を第２の所定の時間内に受信できなかったことをトリガーにして、サービス・シーカー機能を停止するように構成されている。

また、本明細書で開示する技術の第７の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、使用できるチャネルに制限がない状況下において、
サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させているときに、ソーシャル・チャネル上で、自ら送信した対応可能なサービスを指定する要求又は問い合わせに対する応答を所定の時間内に受信できず、又は対応可能なサービスを指定する要求又は問い合わせを所定の時間内に受信できなかったことをトリガーにして、対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信する、通信装置である。

また、本明細書で開示する技術の第８の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、使用できるチャネルに制限がない状況下において、
サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させているときに、ソーシャル・チャネル上で対応可能なサービスを指定する要求又は問い合わせを自ら送信するとともに、自ら送信した要求又は問い合わせに対する応答又は対応可能なサービスを指定する要求又は問い合わせの受信待機を行なった後に、対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信する、通信装置である。

本明細書の第９の側面によれば、第８の側面に係る通信装置は、ソーシャル・チャネル以外での要求又は問い合わせの送信を行なうべきか否かをユーザーに確認した後又は所定の時間が経過した後に、対応可能なすべてのチャネル上で要求又は問い合わせを送信するように構成されている。

また、本明細書で開示する技術の第１０の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、使用できるチャネルがオペレーティング・チャネルに限定される状況下において、
サービス・アドバータイザー機能のみを動作させているときに、前記オペレーティング・チャネル上で、対応可能なサービスを指定する要求又は問い合わせを受信したことをトリガーにして、サービス・シーカー機能の動作を開始して、前記オペレーティング・チャネル上で対応可能なサービスを指定する要求又は問い合わせを送信する、通信装置である。

また、本明細書で開示する技術の第１１の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐを用いるサービスをサポートする通信装置であって、使用できるチャネルがオペレーティング・チャネルに限定される状況下において、
サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させているときに、前記オペレーティング・チャネル上で、プローブ要求フレームを送信するとともに、他のデバイスからのプローブ要求フレームの受信、又は、自デバイスが送信したプローブ要求フレームに対するプローブ応答フレームの受信を待機する、通信装置である。

また、本明細書で開示する技術の第１２の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置の通信方法であって、
サービス・シーカー機能の動作を開始するステップと、
サービス・アドバータイザー機能の動作が停止しているときに、さらにサービス・アドバータイザー機能の動作を開始するステップと、
を有する通信方法である。

また、本明細書で開示する技術の第１３の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置の通信方法であって、
サービス・アドバータイザー機能を動作させて、他の通信装置からの対応可能なサービスを指定する要求又は問い合わせを受信待機するステップと、
対応可能なサービスを指定する要求又は問い合わせを受信したことをトリガーにして、サービス・シーカー機能の動作を開始して、対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
を有する通信方法である。

また、本明細書で開示する技術の第１４の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートし、使用できるチャネルに制限がない状況下における通信装置の通信方法であって、
サービス・アドバータイザー機能を動作させて、ソーシャル・チャネル上で他のデバイスからの対応可能なサービスを指定する要求又は問い合わせを受信待機するステップと、
対応可能なサービスを指定する要求又は問い合わせを所定の時間内に受信できなかったことをトリガーにして、サービス・シーカー機能の動作を開始するステップと、
対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
を有する通信方法である。

また、本明細書で開示する技術の第１５の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートし、使用できるチャネルに制限がない状況下における通信装置の通信方法であって、
サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させるステップと、
ソーシャル・チャネル上で、自ら送信した対応可能なサービスを指定する要求又は問い合わせに対する応答を受信待機するステップと、
自ら送信した要求又は問い合わせに対する応答を所定の時間内に受信できず、又は対応可能なサービスを指定する要求又は問い合わせを所定の時間内に受信できなかったことをトリガーにして、対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
を有する通信方法である。

また、本明細書で開示する技術の第１６の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートし、使用できるチャネルに制限がない状況下における通信装置の通信方法であって、
サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させるステップと、
ソーシャル・チャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
自ら送信した要求又は問い合わせに対する応答又は対応可能なサービスを指定する要求又は問い合わせを受信待機するステップと、
対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
を有する通信方法である。

また、本明細書で開示する技術の第１７の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートし、使用できるチャネルがオペレーティング・チャネルに限定される状況下における通信装置の通信方法であって、
サービス・アドバータイザー機能を動作させて、前記オペレーティング・チャネル上で他のデバイスからの対応可能なサービスを指定する要求又は問い合わせを受信待機するステップと、
前記オペレーティング・チャネル上で、対応可能なサービスを指定する要求又は問い合わせを受信したことをトリガーにして、サービス・シーカー機能の動作を開始するステップと、
前記オペレーティング・チャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
を有する通信方法である。

また、本明細書で開示する技術の第１８の側面は、Ｗｉ−Ｆｉ Ｐ２Ｐを用いるサービスをサポートし、使用できるチャネルがオペレーティング・チャネルに限定される状況下における通信装置の通信方法であって、
サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させるステップと、
前記オペレーティング・チャネル上で、プローブ要求フレームを送信するステップと、
前記オペレーティング・チャネル上で、他のデバイスからのプローブ要求フレームの受信、又は、自デバイスが送信したプローブ要求フレームに対するプローブ応答フレームの受信を待機するステップと、
を有する通信方法である。

本明細書で開示する技術によれば、デバイス・ディスカバリー並びにサービス・ディスカバリーに際してＷｉ−Ｆｉ Ｐ２Ｐサービスで定義されるサービス・シーカー並びにサービス・アドバータイザーとして好適に通信動作を行なうことができる、優れた通信装置及び通信方法を提供することができる。

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

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

図１は、Ｐ２Ｐｓフレームワーク構成要素を示した図である。 図２は、Ｐ２Ｐｓ動作について説明するための図である。 図３は、Ｐ２Ｐｓデバイス間でＡＳＰセッションをセットアップするためのシーケンスを示した図である。 図４は、Ｐ２Ｐｓデバイスとして無線通信動作を行なう通信装置４００の機能的構成例を示した図である。 図５は、ＷＦＤ Ｒ２のデバイスがサービス・アドバータイザー機能及びサービス・シーカー機能の両方を動作させるようにセットアップするシーケンス例を示した図である。 図６は、ＷＦＤ Ｒ２のデバイスがサービス・アドバータイザー及びサービス・シーカーの両方の機能を動作させるようにセットアップするための処理手順を示したフローチャートである。 図７は、ＷＦＤ Ｒ２のデバイスが、Ｐ２Ｐインターフェース側でサービス・アドバータイザー機能のみを動作させているときに、サービス・シーカー機能も動作させるようにセットアップするシーケンス例を示した図である。 図８は、ＷＦＤ Ｒ２のデバイスが、Ｐ２Ｐインターフェース側でサービス・アドバータイザー機能のみを動作させているときに、サービス・シーカー機能も動作させるようにセットアップするための処理手順を示したフローチャートである。 図９は、使用できるチャネルに制限がない状況下でＷＦＤ Ｒ２のデバイスが、Ｐ２Ｐインターフェース側でサービス・アドバータイザー機能のみを動作させているときに、サービス・シーカー機能も動作させるようにセットアップするための処理手順を示したフローチャートである。 図１０は、使用できるチャネルに制限がない状況下でＷＦＤ Ｒ２のデバイスが、Ｐ２Ｐインターフェース側でサービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させているときの、セットアップするための処理手順を示したフローチャートである。 図１１は、使用できるチャネルに制限がない状況下でＷＦＤ Ｒ２のデバイスが、Ｐ２Ｐインターフェース側でサービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させているときの、セットアップするための処理手順（但し、ソーシャル・チャネル以外でのスキャンも必ず行なう場合）を示したフローチャートである。 図１２は、使用できるチャネルに制限がある状況下でＷＦＤ Ｒ２のデバイスが、Ｐ２Ｐインターフェース側でサービス・アドバータイザー機能のみを動作させているときに、サービス・シーカー機能も動作させるようにセットアップするための処理手順を示したフローチャートである。 図１３は、使用できるチャネルに制限がない状況下でＷＦＤ Ｒ２のデバイスが、Ｐ２Ｐインターフェース側でサービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させているときの、セットアップするための処理手順を示したフローチャートである。 図１４は、ポイント（３）の要点をまとめた図である。

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

Ｗｉ−Ｆｉ Ｐ２Ｐによれば、各デバイスがアクセスポイント（ＡＰ）の介在なしに互いに容易に接続することができる。また、ＷＦＡ（Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅ）では、Ｗｉ―Ｆｉ Ｐ２Ｐリンクを用いたさまざまなサービス（例えば、センド（Ｓｅｎｄ）、プレイ（Ｐｌａｙ）、ディスプレイ（Ｄｉｓｐｌａｙ）、プリント（Ｐｒｉｎｔ）など）をサポートするプラットフォームを導入する技術、すなわちＷｉ―Ｆｉ Ｐ２Ｐサービス（Ｐ２Ｐｓ）が仕様化されている。

図１には、Ｐ２Ｐｓフレームワーク構成要素を示している。同図中、参照番号１０１で示すＷｉ−Ｆｉ Ｐ２Ｐ層は、Ｗｉ−Ｆｉ Ｐ２Ｐ標準によって定義されるＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層に相当するが、Ｗｉ−Ｆｉ Ｐ２Ｐ標準と互換のソフトウェアとして構成することができる。

また、Ｗｉ−Ｆｉ Ｐ２Ｐ層１０１の上位には、参照番号１０２で示すＡｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ（ＡＳＰ）というプラットフォームが定義される。なお、図示を省略するが、Ｗｉ−Ｆｉ Ｐ２Ｐ層１０１の下位には、Ｗｉ−Ｆｉ ＰＨＹと互換の物理層によって、無線接続が構成されるものとする。さらにＡＳＰ層１０２の上位には、参照番号１０３で示す、サービス（Ｓｅｒｖｉｃｅ）層が定義される。

ＡＳＰ層１０２は、各サービスで共有される共通のプラットフォームであり、最上位のアプリケーション（Ａｐｐ）層１０４と下位のＷｉ−Ｆｉ Ｐ２Ｐ層１０１との間のセッション管理やサービスの命令処理、他のデバイスのＡＳＰ間の制御などを行なう。ＡＳＰ層１０２は、各サービスで必要とされる共通の機能、具体的にはデバイス・ディスカバリー（Ｄｅｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ）、サービス・ディスカバリー（Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ）、ＡＳＰセッション管理などを実現する。

サービス層１０３は、ユースケース特定のサービスを含む。ＷＦＡでは、センド、プレイ、ディスプレイ、プリントといった基本サービスが定義されている。ここで、センド・サービスは、２つのＰ２Ｐｓデバイス間でファイル伝送を行なうサービス及びアプリケーションである。また、プレイ・サービスは、２つのＰ２Ｐｓデバイス間でＤＬＮＡ（登録商標）（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ）を基盤とするコンテンツ共有又はストリーミングを行なうサービス及びアプリケーションである。また、ディスプレイ・サービスは、デバイス（ＳｏｕｒｃｅとＳｉｎｋ）間で画面共有を可能にするサービス及びアプリケーションである。より具体的には、ディスプレイ・サービスは、ＷＦＡによって策定された、１対１の無線通信によるディスプレイ伝送技術であるＭｉｒａｃａｓｔのユースケースであり、その技術仕様はＷｉ−Ｆｉ Ｄｉｓｐｌａｙ（ＷＦＤ）として規定されている。また、プリントは文書や画像などのコンテンツを有しているデバイスとプリンター間での文書や画像のプリントアウトを可能にするサービス及びアプリケーションである。

さらに、サード・パーティーから提供されるアプリケーションをサポートしＡＳＰ共通のプラットフォームを利用できるようにするために、参照番号１０５で示す、イネーブル（Ｅｎａｂｌｅ）ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を定義してもよい。

アプリケーション層１０４は、ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を提供することができ、ユーザーに対し情報を可視化して表現するとともに、ユーザーから入力された情報を下位層に伝達する機能を有している。

続いて、Ｐ２Ｐｓ動作について、図２を参照しながら説明する。同図では、Ｐ２ＰｓによりＰ２Ｐ接続される２台のデバイスＡ、Ｂが存在する。

デバイスＡとデバイスＢの互いのＰ２Ｐ層間でデバイス・ディスカバリー及びＰ２Ｐが行なわれると、互いのＡＳＰ間では、ＡＳＰセッションと呼ばれる論理的なリンクがセットアップされる。なお、ＡＳＰは、相手デバイスのＡＳＰとの間で、サービス毎に複数のＡＳＰセッションをセットアップすることができ、各ＡＳＰセッションはそのセッションを要求したＡＳＰによって割り当てられるセッション識別子で識別される。

デバイスのサービスは、他のデバイス側の対応するデバイスと、サービス標準でＡＳＰプロトコルによって定義されるサービス特定のプロトコルを用いて通信することができる。図２に示す例では、デバイスＡとデバイスＢのサービスＸ間でサービス・セッションがセットアップされ、また、デバイスＡとデバイスＢのサービスＹ間では別のサービス・セッションがセットアップされている。

デバイス内のＡＳＰとサービスとの間では、メソッド（ｍｅｔｈｏｄ）及びイベント（ｅｖｅｎｔ）というインターフェースが定義されている。メソッドは、サービスによって開始される動作を示すインターフェースである。メソッドのパラメーター（又はフィールド）には、遂行しようとする動作に対する情報を含ませることができる。また、イベントは、ＡＳＰからサービスに提供するインターフェースである。

例えば、ユーザーがデバイスＡとデバイスＢ間でサービスＸを利用しようとする場合、各デバイス上のＡＳＰは、サービスＸ専用のＡＳＰセッションをデバイス間で確立してから、サービス・セッションを確立する。さらにユーザーがサービスＹを利用しようとする場合には、サービスＹ専用のＡＳＰセッションをデバイス間で新たに確立してから、サービス・セッションを確立する。

続いて、Ｐ２Ｐｓデバイス間でＡＳＰセッションをセットアップするためのシーケンスについて、図３を参照しながら説明する。

ＷＦＡで規定されるＰ２Ｐｓでは、デバイス・ディスカバリーに際してサービス・シーカー（Ｓｅｒｖｉｃｅ Ｓｅｅｋｅｒ）とサービス・アドバータイザー（Ｓｅｒｖｉｃｅ Ａｄｖｅｒｔｉｓｅｒ）という役割が定義されている。サービス・シーカーは、サービス・アドバータイザーを発見（ｄｉｓｃｏｖｅｒ）し、所望のサービスを検出した場合にはサービス・アドバータイザーとの接続を要求することもできる。図３では、サービス・アドバータイザーとしての役割を担うデバイスＡとサービス・シーカーとしての役割を担うデバイスＢ間でＡＳＰセッションのセットアップを行なう例を示している。なお、サービス・シーカーやサービス・アドバータイザーという用語は、その役割を持つ機器全体を指すような意味合いで使われる場合が多いが、より正確にはサービス・シーカー機能（Ｓｅｒｖｉｃｅ Ｓｅｅｋｅｒ Ａｐｐｌｉｃａｔｉｏｎ）やサービス・アドバータイザー機能（Ｓｅｒｖｉｃｅ Ａｄｖｅｒｔｉｓｅｒ Ａｐｐｌｉｃａｔｉｏｎ）を動作させたＰ２Ｐｓデバイス（Ｐ２Ｐｓ機器）を指している。

ＡＳＰのセットアップ動作は、一方のＰ２Ｐｓデバイスの特定のサービスが他方のＰ２Ｐｓデバイス及びサービスを探索し、サービスを要求し、Ｗｉ−Ｆｉ Ｐ２Ｐ接続を確立し、アプリケーションを動作させる過程である。

デバイスＡ内のＡＳＰが同デバイス内のサービス層からアドバータイズ・サービス・メソッド（ＡｄｖｅｒｔｉｓｅＳｅｒｖｉｃｅ ｍｅｔｈｏｄ）を受信すると、デバイスＡは、サービス・アドバータイザーとして動作する。図３では、デバイスＡはＰ２Ｐインターフェース（Ｉ／Ｆ）側でサービス・アドバータイザーを動作させるものとする。デバイスＡは、自分のサービスをアドバータイズし、他のデバイスが当該サービスを探索することができるように待機する。また、デバイスＡのＡＳＰは、サービス層から供給されるアドバータイズ・サービス・メソッドに含まれる情報に基づいて、他のデバイスに応答することができる。

また、デバイスＢ内のサービス層は、アプリケーション（図示を省略）からサービスを使用する意図（Ｕｓｅｒ Ｓｅｒｖｉｃｅ）を示す情報を受信すると、シーク・サービス・メソッド（ＳｅｅｋＳｅｒｖｉｃｅ ｍｅｔｈｏｄ）に必要な情報を格納して、ＡＳＰに伝達することができる。そして、デバイスＢ内のＡＳＰがサービス層からシーク・サービス・メソッドを受信すると、デバイスＢは、サービス・シーカーとして動作して、上位アプリケーション又はユーザーが要求するサービスをサポートするデバイスを探索するプロセスを実施する。図３では、デバイスＢは、Ｐ２Ｐインターフェース側でサービス・シーカーを動作させるものとする。

デバイスＢのＡＳＰは、他のデバイスに、プローブ要求（Ｐｒｏｂｅ ｒｅｑｕｅｓｔ）フレームをＰ２Ｐインターフェース側から伝送する。このとき、デバイスＢのＡＳＰは、自分が探そうとしているサービスのサービス名称（ｓｅｒｖｉｃｅ ｎａｍｅ）のハッシュ値を計算して、プローブ要求フレーム内に含ませる。

デバイスＡのＡＳＰは、自分がサポートしているサービスのサービス名称のハッシュ値を計算しており、Ｐ２ＰインターフェースでデバイスＢからのプローブ要求を受信すると、ハッシュ・マッチング（Ｈａｓｈ Ｍａｔｃｈｉｎｇ）を試みる。そして、ハッシュ値が一致し、デバイスＢが探しているサービスをサポートしていることが分かったときには、デバイスＡは、デバイスＢへのプローブ応答（Ｐｒｏｂｅ ｒｅｓｐｏｎｓｅ）フレームをＰ２Ｐインターフェース側から伝送する。プローブ応答フレーム内に、サービス名称、アドバータイズメントＩＤ値などを含ませることができる。

プローブ要求フレーム及びプローブ応答フレームを交換するプロセスでは、デバイスＡとデバイスＢが互いにＰ２Ｐｓをサポートするデバイスであることと、各自がサポートするサービスを検知することができ、デバイス・ディスカバリー・プロセスということができる。

続いて、デバイスＡとデバイスＢは、Ｐ２Ｐサービス・ディスカバリー・プロセスを通じて、サービスの具体的な事項に関する情報を交換する。

例えば、サービス名称（複数のサービスに対するサポートの有無を探索する場合は、複数のサービス名称）、サービス情報要求を含んだサービス・ディスカバリー要求（Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔ）メッセージが、デバイスＢのＰ２ＰインターフェースからデバイスＡに伝送される。

これに対し、デバイスＡのＡＳＰは、サービス名称のマッチング（Ｎａｍｅ Ｍａｔｃｈｉｎｇ）を行ない、マッチングする場合にはサービス・ディスカバリー応答（Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｒｅｓｐｏｎｓｅ）メッセージがデバイスＡのＰ２ＰインターフェースからデバイスＢに伝送される。サービス・ディスカバリー応答メッセージには、サービス名称、アドバータイズメントＩＤ、サービス状態、サービス状態（Ｓｅｒｖｉｃｅ Ｓｔａｔｕｓ）などの情報を含めることができる。サービス状態は、サービス・アドバータイザーとしてのデバイスＡ側で遠隔デバイスから要求されるサービスが利用可能であるかを通知する情報である。

デバイスＢのＡＳＰは、サービス層からシーク・サービス・メソッドによって要求された動作が完了すると、その結果であるサーチ結果（ＳｅａｒｃｈＲｅｓｕｌｔ）を、サービスを通じてアプリケーション及びユーザーに通知することができる。例えば、アプリケーション（図示を省略）は、Ｐ２Ｐサービス・ディスカバリー・プロセスを通じて発見したデバイスをリストアップしたデバイス・リストをＵＩに表示する。ユーザーはこのＵＩを通じて所望するデバイスを選択することができる。ＡＳＰは、サービス層から接続要求（ＣｏｎｎｅｃｔＳｅｓｓｉｏｎ）メソッドを受信したことをトリガーにしてユーザーが選択したデバイスに対するＰ２Ｐ接続を試みるが、以降のプロセスの詳細については説明を省略する。

図４には、Ｐ２Ｐｓデバイスとして無線通信動作を行なう通信装置４００の機能的構成例を示している。

通信装置４００は、データ処理部４０１と、制御部４０２と、通信部４０３と、電源部４０４を備えている。また、通信部４０３はさらに、変復調部４１１と、空間信号処理部４１２と、チャネル推定部４１３と、無線インターフェース（ＩＦ）部４１４と、アンプ部４１５と、アンテナ４１６を備えている。１組の無線インターフェース部４１４と、アンプ部４１５と、アンテナ４１６で１つの送受信ブランチを構成し、図示のように複数（ｎ本）の送受信ブランチを備えていてもよい。なお、アンプ部４１５の機能が無線インターフェース部４１４に内包される場合もある。

通信部４０３は、Ｐ２Ｐｓで規定される複数の周波数チャネルのうちいずれかを使用して無線通信動作を行なえることを前提としている。現在通信動作を行なっているチャネルをオペレーティング・チャネル（ｏｐｅｒａｔｉｎｇ ｃｈａｎｎｅｌ）と言う。また、デバイス・ディスカバリー並びにサービス・ディスカバリーに使用するチャネルをソーシャル・チャネル（ｓｏｃｉａｌ ｃｈａｎｎｅｌ）と言う。通信装置４００は、通信部４０３で使用できるチャネルに制限がない場合（時分割でオペレーティング・チャネル以外のソーシャル・チャネルに移行できる場合）と、使用できるチャネルに制限がある場合（ソーシャル・チャネルに移行できない場合）がある。

データ処理部４０１では、通信プロトコルの上位層（図示しない）よりデータが入力される送信時において、そのデータから無線送信のためのパケットを生成し、メディア・アクセス制御のためのＭＡＣヘッダーの付加や誤り検出符号の付加などの処理を実施し、処理後のデータを変復調部４１１へ提供する。また、データ処理部４０１は、逆に変復調部４１１からのデータ入力がある受信時において、ＭＡＣヘッダーの解析、パケット誤りの検出、パケットのリオーダー処理などを実施し、処理後のデータを自身のプロトコル上位層へ提供する。Ｐ２Ｐｓフレームワークでは、Ｗｉ−Ｆｉ Ｐ２Ｐ標準によって定義されるＭＡＣ層はＷｉ−Ｆｉ Ｐ２Ｐ層（図１を参照のこと）に相当する。

制御部４０２は、通信装置４００内の各部間の情報の受け渡しを行なう。また、制御部４０２は、通信部４０３内の変復調部４１１及び空間信号処理部４１２におけるパラメーターの設定、データ処理部４０１におけるパケットのスケジューリングを行なう。また、制御部４０２は、通信部４０３内の無線インターフェース部４１４及びアンプ部４１５のパラメーターの設定及び送信電力の制御を行なう。特に本明細書で開示する技術では、制御部４０２は、デバイス・ディスカバリー並びにサービス・ディスカバリーに際してサービス・シーカー並びにサービス・アドバータイザーの動作を制御する。

変復調部４１１は、送信時には、データ処理部４０１からの入力データに対し、制御部４０２によって設定されたコーディング及び変調方式基づいて、エンコード、インターリーブ及び変調処理を行ない、データ・シンボル・ストリームを生成して、空間信号処理部４１２へ提供する。また、変復調部４１１は、受信時には、空間信号処理部４１２からの入力に対して、送信時とは反対に復調処理、デインターリーブ、デコードを行ない、データ処理部４０１若しくは制御部４０２へデータを提供する。

空間信号処理部４１２は、送信時には、必要に応じて変復調部４１１から入力されるデータに対して空間分離に供される信号処理を行ない、得られた１つ以上の送信シンボル・ストリームをそれぞれの無線インターフェース部４１３へ提供する。また、空間信号処理部４１２は、受信時には、それぞれの無線インターフェース部４１４から入力された受信シンボル・ストリームに対して信号処理を行ない、必要に応じてストリームの空間分解を行なってから変復調部４１１へ提供する。

チャネル推定部４１３は、各無線インターフェース部４１４からの入力信号のうち、プリアンブル部分及びトレーニング信号部分から伝搬路の複素チャネル利得情報を算出する。算出された複素チャネル利得情報は、制御部４０２を介して変復調部４１１での変復調処理、及び、空間信号処理部４１２での空間処理に利用される。

無線インターフェース部４１４は、送信時には、空間信号処理部４１２からの入力をアナログ信号へ変換し、フィルタリング、及び搬送波周波数へのアップコンバートを実施し、アンテナ４１６又はアンプ部４１５へ送出する。また、無線インターフェース部４１４は、受信時には、アンテナ４１６又はアンプ部４１５からの入力に対して反対にベースバンド周波数へのダウンコンバートやディジタル信号への変換処理を実施し、空間信号処理部４１２及びチャネル推定部４１３へデータを提供する。

アンプ部４１５は、送信時には、無線インターフェース部４１４から入力されたアナログ信号を所定の電力まで増幅し、アンテナ４１６へと送出する。また、アンプ部４１５は、受信時には、アンテナ４１６から入力された信号を所定の電力まで低雑音増幅して、無線インターフェース部４１４に出力する。アンプ部４１５は、送信時の機能と受信時の機能の少なくともどちらか一方が無線インターフェース部４１４に内包される場合がある。

電源部４０４は、バッテリー電源又は固定電源（商用電源など）で構成され、通信装置４００の各部に対し電力を供給する。

続いて、従来のＰ２Ｐｓデバイス・ディスカバリーの際の問題点について説明する。

ＷＦＡで規定されるＰ２Ｐｓでは、デバイス・ディスカバリー並びにサービス・ディスカバリーに際して、サービス・シーカーとサービス・アドバータイザーという役割が定義されている（前述）。サービス・シーカーは、発見した相手デバイスのリストをＵＩに表示でき、ユーザーがこのサービス・シーカーのＵＩを介して選択したデバイスに対して接続を試みる。ところが、サービス・アドバータイザーは自分が対応しているサービスに関する情報を返信するのみで、デバイス・リストの画面を生成できず、ユーザーがサービス・アドバータイザーのＵＩを介してデバイスを選択することができない。

一方がシーカーになり、他方がアドバータイザーになるデバイスの組み合わせで好適に機能するサービスであれば、上記の規定のままでも問題ない。例えば、プリント・サービスであれば、プリント・サーバーとして機能するＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）がシーカーとなり、プリンターがアドバータイザーとなる。シーカーとしてのプリント・サーバーは、プリンターの発見とユーザーが選択したプリンターへの接続を試みる。また、アドバータイザーとしてのプリンターは、自分が対応しているプリント・サービスに関する情報をプリント・サーバーに返信すればよく、ユーザーにデバイス・リストを提示したり、選択されたプリント・サーバーと接続を試みたりする必要はない。

しかしながら、デバイス間で画面共有を可能にするディスプレイ・サービスなどの場合では、画面情報を送信するＳｏｕｒｃｅ、及びＳｏｕｒｃｅから画面情報を受信して表示するＳｉｎｋのいずれからも、相手を選択できるような仕組みが必要である。例えば、スマートフォン内の画像をＴＶ受像機のような大画面に表示出力する場合には、スマートフォン側から画像の出力先のデバイスを選択できるとともに、逆にＴＶ受信機側から画像の提供元のスマートフォンを選択できることが好ましい。具体的には、ＷＦＡによって策定された、１対１の無線通信によるディスプレイ伝送技術であるＷｉ−Ｆｉ Ｄｉｓｐｌａｙ Ｒｅｌｅａｓｅ ２（以下、「ＷＦＤ Ｒ２」とする）のユースケースでは、Ｓｏｕｒｃｅ及びＳｉｎｋの各デバイスはともにシーカー及びアドバータイザーの両方に対応できる必要がある。その両対応のための手順や動作方法が定まってないと、互換性の問題を引き起こすおそれがある。

要するに、ＷＦＤ Ｒ２のデバイスは、サービス・シーカーとサービス・アドバータイザーの両方を同時に動作させる能力を持たなければならない。但し、ここで言う「デバイス」は、ＳｏｕｒｃｅとＳｉｎｋの両方を指すものとする。

サービス・シーカーとサービス・アドバータイザーはＰ２Ｐｓの技術仕様書である“Ｗｉ−Ｆｉ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｓｅｒｖｉｃｅ Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ”にて定義されている。また、この技術仕様書は無償で公開されている。但し、Ｐ２Ｐｓの技術仕様書では、ＡＳＰがシーク・サービス・メソッドを受信するとデバイスはサービス・シーカーとして動作を開始し、ＡＳＰがアドバータイズ・サービス・メソッドを受信するとデバイスはサービス・アドバータイザーとして動作を開始するということまでしか記述されていない。すなわち、デバイス・ディスカバリーに際して各デバイスがサービス・シーカー並びにサービス・アドバータイザーの両方に対応するための手順や動作方法は、本出願時点において明確には定義されていない。

一方、単純にサービス・シーカーとサービス・アドバータイザーの両方を動作させてしまうと、相手機器を発見するまでサービス・シーカーとして動作してしまうために、プローブ要求を送信し続けてしまい、消費電力の増大や無線通信媒体の負荷増大を引き起こしてしまう。この問題を回避するために、例えば単にサービス・シーカー機能を動作させる時間とサービス・アドバータイザー機能を動作させる時間を切り替えるようにすると、当該サービスに対応している他のＰ２Ｐｓ機器から発見してもらえる確率が低下したり、当該サービスに対応している他のＰ２Ｐｓ機器を発見できる確率が低下したりして、そもそも相互に発見し合うためにサービス・シーカーとサービス・アドバータイザーの両方を動作させるという目的と相入れなくなってしまう。さらに、サービス・シーカー機能を常に動作させておくと、相手デバイスを発見する度に発見相手デバイスのリストや接続確認のＵＩが表示されるため、ユーザーにとっては煩わしいものとなってしまうおそれもある。

また、Ｐ２Ｐｓ仕様においては、第２層の接続手段としてＷｉ−Ｆｉ Ｐ２Ｐのみが規定されている。このままでは、ＡＰに接続している端末がＡＰ経由でサービスを行おうとしても、デバイス・ディスカバリーやサービス・ディスカバリーを行なうことができず、実現できない。そのため、ＡＰと接続しているＢＳＳ接続を用いたデバイス・ディスカバリー並びにサービス・ディスカバリーが実現できるように機能拡張を行なうことが望まれる。

そこで、本明細書では、Ｐ２Ｐｓの技術仕様を拡張し、ＷＦＤ Ｒ２のデバイスがデバイス・ディスカバリーに際してシーカー及びアドバイザーの両方に対応するための手順や動作方法について提案する。

なお、図４に示した通信装置４００は、後述する手順や動作方法を実現するために、制御部４０２において、サービス・シーカーとサービス・アドバータイザーの両方が同時に動作可能となっており、サービス・シーカー動作の開始を制御するものとする。

まず前提として、ＷＦＤ Ｒ２のデバイスを、デフォルトではサービス・アドバータイザー機能を動作させるようにする。変形例として、従来通りにＡＳＰがアドバータイズ・サービス・メソッドを受信したら、デバイスはサービス・アドバータイザー機能の動作を開始する場合も含める。

かかる前提の上で、以下に示すＷＦＤ Ｒ２のデバイスの手順若しくは動作方法に関するポイント（１）〜（３）を説明する。

ポイント（１）
ＷＦＤ Ｒ２のデバイス内のＡＳＰがシーク・サービス・メソッド又はアドバータイズ・サービス・メソッドの少なくともどちらかを受信したら、このデバイスはサービス・シーカー機能を動作させる。また、このときサービス・アドバータイザーがオフになっていたら、サービス・アドバータイザー機能も動作させる。

要するに、ＷＦＤ Ｒ２のデバイスは、サービス・アドバータイザー機能又はサービス・シーカー機能のどちらか一方を動作させようとしたら、両方の機能を動作するようにする。特に、デバイスがサービス・シーカーとしてのみ動作するという状況を避けるようにする。これによって、デバイスは、サービス・シーカーとして相手デバイスを発見できるだけでなく、サービス・アドバータイザーとして相手デバイスからも発見してもらうことができるようになる。

図５には、ＷＦＤ Ｒ２のデバイスがサービス・アドバータイザー機能及びサービス・シーカー機能の両方を動作させるようにセットアップするシーケンス例を示している。

デバイスＢ内のＡＳＰがサービス層からシーク・サービス・メソッドを受信したことをトリガーにして、デバイスＢは、サービス・シーカーとして動作する。他のデバイスにプローブ要求フレームを送信してデバイス・ディスカバリー・プロセスを実施する点などは図３と同様なので、ここでは図示並びに説明を省略する。このとき、デバイスＢにおいて、サービス・アドバータイザーがオフになっていたら、ＡＳＰが自らに対してアドバータイズ・サービス・メソッドを発行することで、デバイスＢはサービス・アドバータイザーとしても動作する。

また、デバイスＡ内のＡＳＰがサービス層からアドバータイズ・サービス・メソッドを受信したことをトリガーにして、デバイスＢは、サービス・アドバータイザーとして動作する。他のデバイスからのプローブ要求受信待ちに入る点などは図３と同様なので、ここでは図示並びに説明を省略する。このとき、デバイスＡにおいて、サービス・シーカーがオフになっていたら、デバイスＡ内のＡＳＰが自らに対してシーク・サービス・メソッドを発行することで、デバイスＡはサービス・シーカーとしても動作する。

図６には、ＷＦＤ Ｒ２のデバイスがサービス・アドバータイザー及びサービス・シーカーの両方の機能を動作させるようにセットアップするための処理手順をフローチャートの形式で示している。

デバイス内で、ＡＳＰがサービス層からシーク・サービス・メソッドを受信すると（ステップＳ６０１のＹｅｓ）、また、このデバイスにおいてサービス・シーカーの動作がオフになっているかどうかをチェックする（ステップＳ６０２）。そして、サービス・シーカーの動作がオフになっていたら（ステップＳ６０２のＹｅｓ）、このデバイス内でＡＳＰが自らに対してシーク・サービス・メソッドを発行させて（ステップＳ６０３）、デバイスはサービス・シーカーの動作をオンにする（ステップＳ６０４）。このようにして、デバイスは、サービス・シーカーとして動作していることになる。

このとき、このデバイスにおいてサービス・アドバータイザーの動作がオフになっているかどうかをチェックする（ステップＳ６０５）。そして、サービス・アドバータイザーの動作がオフになっていたら（ステップＳ６０５のＹｅｓ）、このデバイス内でＡＳＰが自らに対してアドバータイズ・サービス・メソッドを発行して（ステップＳ６０６）、デバイスはサービス・アドバータイザーの動作をオンにする（ステップＳ６０７）。

ポイント（２）
ＷＦＤ Ｒ２のデバイスは、Ｐ２Ｐインターフェース側でサービス・アドバータイザー機能のみを動作させているときに、自分が対応しているサービス（例えばＭｉｒａｃａｓｔ Ｓｉｎｋ）にマッチするハッシュ値を含んだプローブ要求フレームを受信したら、すぐにサービス・シーカー機能も動作させるようにする。その結果、このデバイスは自分からも他のデバイスにプローブ要求フレームを送信できるようになる。

ＷＦＤ Ｒ２のデバイスは、サービス・シーカーを立ち上げないと自分から相手を探せなくて自デバイスで表示するデバイス・リストを作ることがないからである。サービス・アドバータイザー機能のみを動作させているデバイスは、上記のようにサービス・シーカー機能も動作させることで、自デバイスで表示するデバイス・リストを作り、ユーザーにそのＵＩを提示することができるようになる。

図７には、ＷＦＤ Ｒ２のデバイスＡが、Ｐ２Ｐインターフェース側でサービス・アドバータイザー機能のみを動作させているときに、サービス・シーカー機能も動作させるようにセットアップするシーケンス例を示している。

デバイスＢ内のＡＳＰがサービス層からシーク・サービス・メソッドを受信したことをトリガーにして、デバイスＢは、サービス・シーカー機能の動作を開始する。そして、デバイスＢは、自分が探そうとしているサービス名称のハッシュ値を含んだプローブ要求フレームを、他のデバイスに送信する。

デバイスＡは、ＡＳＰが同デバイス内のサービス層からアドバータイズ・サービス・メソッドを受信したことにより、サービス・アドバータイザー機能のみを動作させている。ここで、デバイスＢから受信したプローブ要求フレームに含まれているサービス名称のハッシュ値が、デバイスＡで対応しているサービスとマッチしたとする。デバイスＡがデバイスＢにプローブ応答フレームを返信し、引き続きデバイスＢとの間でサービス・ディスカバリー・プロセスを実施する点などは図３と同様なので、ここでは図示並びに説明を省略する。このとき、デバイスＡにおいて、ＡＳＰが自らに対してシーク・サービス・メソッドを発行することで、デバイスＡはサービス・シーカー機能も動作させる。

そして、デバイスＡは、自分が探そうとしているサービス名称のハッシュ値を含んだプローブ要求フレームを、他のデバイスに送信し、ハッシュ値がマッチしたデバイス（仮に、デバイスＢとする）からのプローブ応答フレームを受信し、サーチ結果に基づくデバイス・リストのＵＩをユーザーに提示することができる。

図８には、ＷＦＤ Ｒ２のデバイスが、Ｐ２Ｐインターフェース側でサービス・アドバータイザー機能のみを動作させているときに、サービス・シーカー機能も動作させるようにセットアップするための処理手順をフローチャートの形式で示している。

デバイスは、サービス・アドバータイザーとして動作中であれば（ステップＳ８０１のＹｅｓ）、（サービス・シーカーとして動作している）他のデバイスからのプローブ要求フレームを受信待機する（ステップＳ８０２）。

そして、他のデバイスからプローブ要求フレームを受信すると（ステップＳ８０２のＹｅｓ）、受信したプローブ要求フレームに含まれているサービス名称のハッシュ値が、自デバイスで対応しているサービスとマッチするか否か、ハッシュ・マッチングを行なう（ステップＳ８０３）。

ここで、ハッシュ値がマッチしなければ（ステップＳ８０４のＮｏ）、受信したプローブ要求フレームでは自デバイスでは対応できないサービスが指定されていることが分かる。この場合、ステップＳ８０１に戻り、デバイスは、このままサービス・アドバータイザーとしてのみ動作を続ける。

一方、サービス名称のハッシュ値がマッチするときには（ステップＳ８０４のＹｅｓ）、受信したプローブ要求フレームでは自デバイスで対応可能なサービスが指定されていることが分かる。この場合、このデバイス内ではＡＳＰが自らに対してシーク・サービス・メソッドを発行することで（ステップＳ８０５）、デバイスはサービス・シーカー機能も動作させる（ステップＳ８０６）。

このようにして、サービス・アドバータイザー機能のみを動作させているデバイスは、ハッシュ値がマッチするプローブ要求フレームを受信したことをトリガーにしてサービス・シーカー機能も動作させることで、自らもプローブ要求フレームを送信するようになり、それに対するプローブ応答フレームを受信することにより自デバイスで表示するデバイス・リストを作り、ユーザーにそのＵＩを提示することができるようになる。

ＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）接続側でも同様のことを行なう変形例も考えられる。すなわち、ＷＦＤ Ｒ２のデバイスは、ＢＳＳインターフェース側でサービス・アドバータイザー機能のみを動作させているときに、自分が対応しているサービス（例えばＭｉｒａｃａｓｔ Ｓｉｎｋ）に対応する文字列を含むｍＤＮＳ問い合わせ（ｍｕｌｔｉｃａｓｔ ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ） ｑｕｅｒｙ）を受信したら、すぐにサービス・シーカー機能も動作させるようにする。その結果、このデバイスは自分からもｍＤＮＳ問い合わせを送信するようになり、対応する文字列を含むｍＤＮＳ問い合わせを受信した他のデバイスからｍＤＮＳ応答を受信し、デバイス・ディスカバリー並びにサービス・ディスカバリーのサーチ結果に基づいて自デバイスに表示するデバイス・リストを作ることができるようになる。

ポイント（３）
ＷＦＤ Ｒ２のデバイスは、使用できるチャネルの制限の有無とデバイスのサービス・アドバータイザー又はサービス・シーカーの動作状態とに応じて、動作を制御するようにする。

ＩＥＥＥ８０２．１１では、割り当てられた帯域を複数のチャネルに分割して用いている。このうちの１つは、サービス・ディスカバリーに使用するソーシャル・チャネルに割り当てられ、他のチャネルは通常の通信動作に用いられる。そのうち特に、前述のように、ＢＳＳインターフェース側でＡＰと接続する際に用いているチャネル、Ｐ２Ｐクライアントとして動作していてＰ２Ｐ ＧＯ（Ｐ２Ｐ Ｇｒｏｕｐ Ｏｗｎｅｒ）と接続する際に用いているチャネル、又は自らがＰ２Ｐ ＧＯとして動作しているチャネルをオペレーティング・チャネルと呼ぶことにする。

使用できるチャネルに制限がない場合とは、具体的には、デバイスが、ＡＰ又はＰ２Ｐ ＧＯにアソシエーションしていない、Ｐ２Ｐ ＧＯになっていない、あるいはソーシャル・チャネル以外で動作しているアクセスポイントにアソシエーションしているかＰ２Ｐグループのメンバーになっていても時分割でオペレーティング・チャネル以外のソーシャル・チャネルに移行できる場合である。

一方、使用できるチャネルに制限がある場合とは、具体的には、デバイスが、ＡＰ又はＰ２Ｐ ＧＯにアソシエーションしているか、又は自分がＰ２Ｐ ＧＯとして動作しており、オペレーティング・チャネルがソーシャル・チャネルではなく、且つ時分割でソーシャル・チャネルに移行して送受信できない場合であり、この場合のフレーム送受信動作はオペレーティング・チャネルに限定される。

（３−１）使用できるチャネルに制限がない場合であって、Ｐ２Ｐインターフェース向けにサービス・アドバータイザー機能のみを動作させているＷＦＤ Ｒ２のデバイスは、ソーシャル・チャネル上で自分が対応しているサービスにマッチするハッシュ値を含んだプローブ要求フレームを受信するのを所定の時間だけ待機し、受信しなかったらサービス・シーカー機能も動作させて、対応可能なすべてのチャネル上でスキャン（すなわち、プローブ要求フレームの送信とプローブ応答フレームの受信待機、並びにプローブ要求フレームの受信待機）を行なう。

ＷＦＤ Ｒ２のデバイスは、タイムアウトするとサービス・シーカー機能も動作させて自ら積極的に他のチャネル上でも相手デバイスの探索を開始する上、サービス・アドバータイザー機能も動作させたままなので、相手デバイスからも他のチャネル上で見つけてもらうことができる。また、サービス・シーカーとして第２の所定の時間だけかけて相手デバイスを発見することができなかった場合には、このデバイスはサービス・シーカー機能を停止するようにしてもよい。

サービス・アドバータイザー機能の動作は、基本的にプローブ要求フレームの受信待機状態にあり、受信できたときにハッシュ・マッチングし、マッチした場合にプローブ応答フレームを返信する。他方、サービス・シーカー機能の動作は、自らプローブ要求フレームを送信するので、その送信電力の分だけ消費電力が多くなるとともに送信時に通信メディアを使用する。したがって、第２の所定の時間がタイムアウトしたことによりサービス・シーカー機能を停止することで、デバイスの低消費電力化と無線通信媒体の節約（トラフィックの混雑回避）になる。

図９には、使用できるチャネルに制限がない状況下でＷＦＤ Ｒ２のデバイスが、Ｐ２Ｐインターフェース側でサービス・アドバータイザー機能のみを動作させているときに、サービス・シーカー機能も動作させるようにセットアップするための処理手順をフローチャートの形式で示している。

サービス・アドバータイザー機能のみを動作させているＷＦＤ Ｒ２のデバイスは、ソーシャル・チャネル上でプローブ要求フレームの受信を待機する（ステップＳ９０１）。

所定の時間がタイムアウトするまでに（ステップＳ９０２のＮｏ）、ソーシャル・チャネル上でプローブ要求フレームを受信できたときには（ステップＳ９０１のＹｅｓ）、デバイスは、受信したプローブ要求フレームに含まれているハッシュ値が、自デバイスで対応しているサービスとマッチするか否か、ハッシュ・マッチングを行なう（ステップＳ９０３）。

ここで、ハッシュ値がマッチするときには（ステップＳ９０４のＹｅｓ）、受信したプローブ要求フレームでは自デバイスで対応可能なサービスが指定されていることが分かる。この場合、デバイスは、他のデバイスにプローブ応答フレームを返信した上で（ステップＳ９０５）、直ちにサービス・シーカー機能も動作させる（ステップＳ９０６）。

一方、所定の時間内に、ソーシャル・チャネル上で、自デバイスが対応しているサービスにマッチするハッシュ値を含んだプローブ要求フレームを受信できなかったときには（ステップＳ９０４のＮｏで且つステップＳ９０２のＹｅｓ）、このデバイス内でＡＳＰが自らに対してシーク・サービス・メソッドを発行することで、デバイスはサービス・シーカー機能も動作させる（ステップＳ９０６）。以降、デバイスは、サービス・アドバータイザーとして動作し続けながら、サービス・シーカー機能の動作も開始する。

デバイスは、サービス・シーカーとして、対応可能なすべてのチャネル上でスキャン（すなわち、プローブ要求フレームの送信とプローブ応答フレームの受信待機）を行なう（ステップＳ９０７）。デバイスは、タイムアウトするとサービス・シーカー機能も動作させて自ら積極的に他のチャネル上でも相手デバイスの探索を開始する上、サービス・アドバータイザー機能も動作させたままなので、相手デバイスからも他のチャネル上で見つけてもらうことができるようになる。

デバイスは、第２の所定の時間だけ（ステップＳ９１０のＮｏ）、すべてのチャネル上でのスキャン動作を繰り返し実施する。この間もデバイスはサービス・アドバータイザー機能も動作したままなので、相手デバイスからも他のチャネル上で見つけてもらうことができる。なお、図９に示した処理手順では、所定の時間だけ受信待機するようタイムアウト機構を中止条件に用いているが、最大のスキャン試行回数など他の中止条件を用いても、本質的には同様である。

そして、デバイスは、第２の所定の時間内に（ステップＳ９１０のＮｏ）、いずれかのチャネル上でプローブ応答フレームを受信し、所望する相手デバイスを発見することができたときには（ステップＳ９０８のＹｅｓ）、サーチ結果として、サービス層及びアプリケーションを通じて発見した相手デバイス・リストのＵＩをユーザーに提示する（ステップＳ９０９）。

また、第２の所定の時間だけかけて相手デバイスを発見することができなかった場合（ステップＳ９１０のＹｅｓ）、すなわち、タイムアウトすると、デバイスはサービス・シーカー機能を停止する（ステップＳ９１１）。

ＢＳＳ接続側で同様のことを行なう変形例も考えられる。すなわち、ＢＳＳインターフェース向けにサービス・アドバータイザー機能のみを動作させているＷＦＤ Ｒ２のデバイスは、自分が対応しているサービスにマッチするハッシュ値を含んだｍＤＮＳ問い合わせを受信するのを所定の時間だけ待機し、受信しなかったらサービス・シーカー機能を動作させるようにして、自ら積極的に探しているサービスに対応する文字列を含んだｍＤＮＳ問い合わせを送信して相手デバイスを探索する。それでも第２の所定の時間だけかけて相手デバイスを発見することができなかった場合には、このデバイスはサービス・シーカー機能を停止するようにしてもよい。タイムアウトしたことによりサービス・シーカー機能を停止することで、デバイスの低消費電力化と無線通信媒体の節約（トラフィックの混雑回避）になる。

（３−２）使用できるチャネルに制限がない場合であって、Ｐ２Ｐインターフェース向けにサービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させているＷＦＤ Ｒ２のデバイスは、ソーシャル・チャネル上でプローブ要求フレームを送信するとともに、他のデバイスからのプローブ要求フレームの受信、又は、自デバイスが送信したプローブ要求フレームに対するプローブ応答フレームの受信を所定の時間だけ待機する。そして、相手デバイスを発見することができなかったら、このデバイスは、サービス・シーカー機能及びサービス・アドバータイザー機能をともに動作させたままで、対応可能なすべてのチャネル上でスキャン（すなわち、プローブ要求フレームの送信とプローブ応答フレームの受信待機、並びにプローブ要求フレームの受信待機）を行なう。

この場合、ＷＦＤ Ｒ２のデバイスは、タイムアウトすると自ら積極的に他のチャネル上でも相手デバイスの探索を開始する上、サービス・アドバータイザー機能も動作させているので、相手デバイスからも他のチャネル上で見つけてもらうことができる。また、サービス・シーカーとして第２の所定の時間だけかけて相手デバイスを発見することができなかった場合には、このデバイスはサービス・シーカー機能を停止するようにしてもよい。

図１０には、使用できるチャネルに制限がない状況下でＷＦＤ Ｒ２のデバイスが、Ｐ２Ｐインターフェース側でサービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させているときの、セットアップするための処理手順をフローチャートの形式で示している。

サービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させているＷＦＤ Ｒ２のデバイスは、ソーシャル・チャネル上で、他のデバイスからのプローブ要求フレームの受信を待機する（ステップＳ１００１）。

所定の時間がタイムアウトするまでに（ステップＳ１０１０のＮｏ）、ソーシャル・チャネル上でプローブ要求フレームを受信できたときには（ステップＳ１０１０のＹｅｓ）、デバイスは、受信したプローブ要求フレームに含まれているハッシュ値が、自デバイスで対応しているサービスとマッチするか否か、ハッシュ・マッチングを行なう（ステップＳ１００２）。

ここで、ハッシュ値がマッチするときには（ステップＳ１００３のＹｅｓ）、受信したプローブ要求フレームでは自デバイスで対応可能なサービスが指定されていることが分かる。この場合、このデバイスは、他のデバイスにプローブ応答フレームを返信した後（ステップＳ１００４）、相手デバイスとの間で引き続きサービス・ディスカバリー・プロセスを実施する。具体的には、ソーシャル・チャネル上でプローブ要求フレームを送信して（ステップＳ１００５）、自デバイスが送信したプローブ要求フレームに対するプローブ応答フレームの受信を待機する（ステップＳ１００６）。

一方、所定時間内に、ソーシャル・チャネル上でプローブ要求フレームもプローブ応答フレームも受信できず、相手デバイスを発見することができなかったら（ステップＳ１０１０のＹｅｓ）、このデバイスは、サービス・シーカー機能及びサービス・アドバータイザー機能をともに動作させたままで、対応可能なすべてのチャネル上でスキャン（すなわち、プローブ要求フレームの送信）を行なう（ステップＳ１００７）。なお、デバイスはサービス・アドバータイザー機能も動作させたままなので、相手デバイスからも他のチャネル上で見つけてもらうことができる。

そして、デバイスは、ソーシャル・チャネル上でプローブ応答フレームを受信し（ステップＳ１００６のＹｅｓ）、又は、いずれかのチャネル上でプローブ応答フレームを受信して、所望する相手デバイスを発見することができたときには（ステップＳ１００８のＹｅｓ）、サーチ結果として、サービス層及びアプリケーションを通じてユーザーにデバイス・リストのＵＩを提示する（ステップＳ１００９）。

また、いずれのチャネル上でも相手デバイスを検出することができなかった場合には（ステップＳ１００８のＮｏ）、デバイスは、サービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させたまま、ステップＳ１００１に戻り、上記と同様の処理を繰り返し実行する。あるいは、相手デバイスを検出することができなかった場合には（ステップＳ１００８のＮｏ）、サービス層及びアプリケーションを通じてユーザーに相手デバイスを発見できなかったというサーチ結果を提示した上でユーザーに相手デバイス発見を継続するかどうかをユーザーに選択させるＵＩを提示するようにしてもよい。そした、ユーザーが継続を選択した場合にのみステップＳ１００１に戻り、継続を選択しなかった場合には相手デバイスの探索を中断するようにしてもよい。相手デバイスの探索を中断する場合には、このデバイスはサービス・シーカー機能を停止することが好適である。なお、図１０に示した処理手順では、所定の時間だけ待つようなタイムアウト機構を中止条件に用いているが、最大のスキャン試行回数など他の中止条件を用いても、本質的に同等である。

上記（３−１）及び（３−２）に共通するメリットとして、使用できるチャネルに制限がない場合のＷＦＤ Ｒ２のデバイスは、ソーシャル・チャネル以外で動作していて他のチャネルに移行できない他のデバイス（ＷＦＤ Ｒ２対応のデバイス、並びにＷＦＤ Ｒ１対応のデバイス）を発見することができるし、逆に相手デバイスから自デバイスを発見してもらうことができる。

（３−３）使用できるチャネルに制限がない場合であって、Ｐ２Ｐインターフェース向けにサービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させているＷＦＤ Ｒ２のデバイスは、ソーシャル・チャネル上でプローブ要求フレームを送信するとともに、他のデバイスからのプローブ要求フレームの受信、又は、自デバイスが送信したプローブ要求フレームに対するプローブ応答フレームの受信を所定の時間だけ待機する（上記（３−２）と同様）。そして、相手デバイスを発見することができた場合でも、このデバイスは、サービス・シーカー機能及びサービス・アドバータイザー機能をともに動作させたままで、対応可能なすべてのチャネル上でスキャンを行なう方が好ましい。別チャネルに存在するかもしれないＷＦＤ Ｒ２対応のデバイスやＷＦＤ Ｒ１対応のデバイスを発見するためである。

但し、対応可能なすべてのチャネル上でスキャンを開始する前に、ユーザーがソーシャル・チャネル以外でのスキャンを許可又は希望するか否かを選択するためのＵＩの表示を行なうようにしてもよい。

図１１には、使用できるチャネルに制限がない状況下でＷＦＤ Ｒ２のデバイスが、Ｐ２Ｐインターフェース側でサービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させているときの、セットアップするための処理手順（但し、ソーシャル・チャネル以外でのスキャンも必ず行なう場合）をフローチャートの形式で示している。

サービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させているＷＦＤ Ｒ２のデバイスは、ソーシャル・チャネル上でプローブ要求フレームを送信して（ステップＳ１１０１）、自デバイスが送信したプローブ要求フレームに対するプローブ応答フレームの受信を待機するとともに（ステップＳ１１０２）、他のデバイスからのプローブ要求フレームの受信を待機する（ステップＳ１１０３）。

所定の時間がタイムアウトするまでに（ステップＳ１１１１のＮｏ）、ソーシャル・チャネル上でプローブ要求フレームを受信できたときには（ステップＳ１１０３のＹｅｓ）、デバイスは、受信したプローブ要求フレームに含まれているハッシュ値が、自デバイスで対応しているサービスとマッチするか否か、ハッシュ・マッチングを行なう（ステップＳ１１０４）。

ここで、ハッシュ値がマッチするときには（ステップＳ１１０５のＹｅｓ）、受信したプローブ要求フレームでは自デバイスで対応可能なサービスが指定されていることが分かる。この場合、このデバイスは、他のデバイスにプローブ応答フレームを返信する（ステップＳ１１０６）。

所定の時間が経過した後に、ステップＳ１１０７の処理として、ソーシャル・チャネル上での相手デバイスのサーチ結果をユーザーに提示する。その際、ソーシャル・チャネル上でプローブ要求フレームもプローブ応答フレームも受信できず、相手デバイスを発見することができなかった場合には（ステップＳ１１１１のＹｅｓ）、ソーシャル・チャネル上で相手デバイスを発見できなかった旨のサーチ結果をユーザーに提示する。一方、ソーシャル・チャネル上でプローブ要求フレームを受信し（ステップＳ１１０３のＹｅｓ）、且つ、ハッシュ値がマッチして（ステップＳ１１０５のＹｅｓ）、受信したプローブ要求フレームに対するプローブ応答フレームを返信した場合には（ステップＳ１１０６）、発見できた１つ乃至複数のデバイスのサーチ結果をユーザーに提示する。さらにステップＳ１１０７の処理として、ユーザーがソーシャル・チャネル以外でのスキャンを許可又は希望するか否かを選択するためのＵＩを表示して、ソーシャル・チャネル以外でのスキャンを行なうべきかどうかをチェックする。

ソーシャル・チャネル以外でのスキャンを行なわない場合には（ステップＳ１１０８のＮｏ）、デバイスは、サービス・シーカー機能を停止し、サービス・アドバータイザー機能のみを動作させて、プローブ要求フレーム受信待機に戻る。あるいは、サービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させたまま、ステップＳ１１０１に戻り、上記と同様の処理を繰り返し実行するようにしてもよい。

一方、ソーシャル・チャネル以外でのスキャンを行なう場合には（ステップＳ１１０８のＹｅｓ）、このデバイスは、サービス・シーカー機能及びサービス・アドバータイザー機能をともに動作させたままで、対応可能なすべてのチャネル上でスキャン（すなわち、プローブ要求フレームの送信とプローブ要求フレームの受信待機、及びプローブ要求フレームの受信待機）を行なう（ステップＳ１１０９）。なお、デバイスはサービス・アドバータイザー機能も動作させたままなので、相手デバイスからも他のチャネル上で見つけてもらうことができる。

最終的に、デバイスがソーシャル・チャネル又はいずれかのチャネル上でプローブ応答フレームを受信して、所望する相手デバイスを発見することができたときには（ステップＳ１１０９のＹｅｓ）、サーチ結果として、サービス層及びアプリケーションを通じてユーザーにデバイス・リストのＵＩを提示する（ステップＳ１１１０）。

また、いずれのチャネル上でも相手デバイスを検出することができなかった場合には（ステップＳ１１０９のＮｏ）、デバイスは、サービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させたまま、ステップＳ１１０１に戻り、上記と同様の処理を繰り返し実行する。あるいは、このデバイスは、サービス・シーカー機能の動作を停止しサービス・アドバータイザー機能のみを動作させてプローブ要求フレーム受信待機に戻ってもよい。なお、図１１に示した処理手順では、所定の時間だけ待つようなタイムアウト機構を中止条件に用いているが、最大のスキャン試行回数など他の中止条件を用いても、本質的に同等である。

（３−４）使用できる周波数に制約がある場合、すなわちフレーム送受信動作はオペレーティング・チャネルに限定される場合であって、Ｐ２Ｐインターフェース向けにサービス・アドバータイザー機能だけを動作させているＷＦＤ Ｒ２のデバイスは、オペレーティング・チャネル上でプローブ要求フレームを受信待機する。もし自分が対応しているサービス（例えば、Ｍｉｒａｃａｓｔ Ｓｉｎｋ）にマッチするハッシュ値を含んだプローブ要求フレームを受信したら、すぐにサービス・シーカー機能も動作させる。その結果、このデバイスは、オペレーティング・チャネル上でプローブ要求フレームを送信するようになり、相手デバイスを自ら発見できるようになる。

図１２には、使用できるチャネルに制限がある状況下でＷＦＤ Ｒ２のデバイスが、Ｐ２Ｐインターフェース側でサービス・アドバータイザー機能のみを動作させているときに、サービス・シーカー機能も動作させるようにセットアップするための処理手順をフローチャートの形式で示している。

サービス・アドバータイザー機能のみを動作させているＷＦＤ Ｒ２のデバイスは、ソーシャル・チャネル上でプローブ要求フレームの受信を待機する（ステップＳ１２０１）。

ソーシャル・チャネル上でプローブ要求フレームを受信できたときには（ステップＳ１２０１のＹｅｓ）、デバイスは、受信したプローブ要求フレームに含まれているハッシュ値が自デバイスで対応しているサービスとマッチするか否か、ハッシュ・マッチングを行なう（ステップＳ１２０３）。

ハッシュ値がマッチしないときには（ステップＳ１２０４のＮｏ）、デバイスは、そのままステップＳ１２０１に戻り、サービス・アドバータイザー機能の動作のみを継続し、他のデバイスからのプローブ要求フレームを受信待機する。

一方、ハッシュ値がマッチするときには（ステップＳ１２０４のＹｅｓ）、受信したプローブ要求フレームでは自デバイスで対応可能なサービスが指定されていることが分かる。この場合、デバイスはプローブ応答フレームを返信し（ステップＳ１２０５）、さらにこのデバイス内でＡＳＰが自らに対してシーク・サービス・メソッドを発行することで、デバイスはサービス・シーカー機能も動作させる（ステップＳ１２０６）。以降、デバイスは、オペレーティング・チャネル上において、サービス・アドバータイザーとして動作し続けながら、サービス・シーカー機能の動作も開始する。

（３−５）使用できる周波数に制約がある場合、すなわちフレーム送受信動作はオペレーティング・チャネルに限定される場合であって、Ｐ２Ｐインターフェース向けにサービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させているＷＦＤ Ｒ２のデバイスは、オペレーティング・チャネル上でプローブ要求フレームを送信するとともに、他のデバイスからのプローブ要求フレームの受信、又は、自デバイスが送信したプローブ要求フレームに対するプローブ応答フレームの受信を待機する。

図１３には、使用できるチャネルに制限がない状況下でＷＦＤ Ｒ２のデバイスが、Ｐ２Ｐインターフェース側でサービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させているときの、セットアップするための処理手順をフローチャートの形式で示している。

サービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させているＷＦＤ Ｒ２のデバイスは、まず、サービス・シーカーの動作として、オペレーティング・チャネル上でプローブ要求フレームを送信する（ステップＳ１３０１）。

プローブ要求フレームに対するプローブ応答フレームを受信できたときには（ステップＳ１３０２のＹｅｓ）、サーチ結果として、サービス層及びアプリケーションを通じてユーザーにデバイス・リストのＵＩを提示する（ステップＳ１３０３）。

デバイス・リストのＵＩを提示した後（ステップＳ１３０３）、並びに、プローブ要求フレームに対するプローブ応答フレームを受信できなかったとき（ステップＳ１３０２のＮｏ）、このデバイスは、続いて、サービス・アドバータイザーの動作として、他のデバイスからのプローブ要求フレームの受信を待機する（ステップＳ１３０４）。

プローブ要求フレームを受信しないときには（ステップＳ１３０４のＮｏ）、ステップＳ１３０１に戻り、デバイスは、サービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させたまま、オペレーティング・チャネル上でのプローブ要求フレーム又はプローブ応答フレームの送受信動作を繰り返し実行する。

また、プローブ要求フレームを受信したときには（ステップＳ１３０４のＹｅｓ）、デバイスは、受信したプローブ要求フレームに含まれているハッシュ値が、自デバイスで対応しているサービスとマッチするか否か、ハッシュ・マッチングを行なう（ステップＳ１３０５）。

ハッシュ値がマッチしないときには（ステップＳ１３０６のＮｏ）、ステップＳ１３０１に戻り、デバイスは、サービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させたまま、オペレーティング・チャネル上でのプローブ要求フレーム又はプローブ応答フレームの送受信動作を繰り返し実行する。

また、ハッシュ値がマッチするときには（ステップＳ１３０６のＹｅｓ）、受信したプローブ要求フレームでは自デバイスで対応可能なサービスが指定されていることが分かる。この場合、デバイスは、サービス・アドバータイザー機能の動作を続ける。すなわち、このデバイスは、他のデバイスにプローブ応答フレームを返信する（ステップＳ１３０７）。その後、ステップＳ１３０１に戻り、デバイスは、サービス・シーカー及びサービス・アドバータイザーの両方の機能を動作させたまま、オペレーティング・チャネル上でのプローブ要求フレーム又はプローブ応答フレームの送受信動作を繰り返し実行する。

なお、ポイント（３）の要点を図１４にまとめる。

本明細書で開示する技術によれば、サービス・シーカー並びにサービス・アドバータイザー動作を行なうことにより、自機器が対応するサービス機器を発見すると同時に他の機器から発見されるように動作する場合において、サービス・シーカーとして動作する時間を限定することができる。これにより、機器は対応可能なサービスを指定する要求又は問い合わせを送信する頻度を減らして消費電力の低減及び無線通信媒体の浪費を防止しながらも、常時サービス・シーカーとして動作させた場合と比較して他のサービス対応機器を発見する確率や他のサービス対応機器から発見される確率を低下させることがないという効果を有する。さらに、サービス・シーカー機能を特定の状態において動作させることより、相手デバイスを発見する度に相手デバイスのリストや接続確認のＵＩが表示され、ユーザーにとっては煩わしいものとなってしまう可能性を排除することができる。

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

本明細書で開示する技術は、主にＰ２Ｐｓ仕様の通信装置に好適に適用することができるが、デバイス・ディスカバリーに際してシーカーとアドバータイザーの役割が定義されるさまざまな通信システムにも同様に適用して、所望する通信相手を見つけ易くすることができる。

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

なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、
サービス・アドバータイザー機能又はサービス・シーカー機能のどちらか一方を動作させようとする際に、サービス・アドバータイザー機能及びサービス・シーカー機能の両方を動作させる、通信装置。
（２）前記通信装置内で、ＡＳＰがサービス層からシーク・サービス・メソッドを受信したことをトリガーにしてサービス・シーカー機能を動作させ、さらにサービス・アドバータイザー機能の動作が停止しているときにはサービス・アドバータイザー機能も動作させる、上記（１）に記載の通信装置。
（３）Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、
サービス・アドバータイザー機能のみを動作させているときに、対応可能なサービスを指定する要求又は問い合わせを受信したことをトリガーにして、サービス・シーカー機能の動作を開始する、通信装置。
（４）サービス・アドバータイザー機能のみを動作させているときに、対応可能なサービス名称にマッチするハッシュ値を含んだ要求又は対応可能なサービス名称を示す文字列を含んだ問い合わせを受信したことをトリガーにして、サービス・シーカー機能を動作させて他の通信装置へ対応可能なサービスを指定する要求又は問い合わせを送信する、上記（３）に記載の通信装置。
（５）Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、使用できるチャネルに制限がない状況下において、
サービス・アドバータイザー機能のみを動作させているときに、ソーシャル・チャネル上で、対応可能なサービスを指定する要求又は問い合わせを所定の時間内に受信できなかったことをトリガーにして、サービス・シーカー機能の動作を開始して、対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信する、通信装置。
（６）サービス・シーカー機能を用いて送信した要求又は問い合わせに対する応答を第２の所定の時間内に受信できなかったことをトリガーにして、サービス・シーカー機能を停止する、上記（５）に記載の通信装置。
（７）Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、使用できるチャネルに制限がない状況下において、
サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させているときに、ソーシャル・チャネル上で、自ら送信した対応可能なサービスを指定する要求又は問い合わせに対する応答を所定の時間内に受信できず、又は対応可能なサービスを指定する要求又は問い合わせを所定の時間内に受信できなかったことをトリガーにして、対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信する、通信装置。
（８）Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、使用できるチャネルに制限がない状況下において、
サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させているときに、ソーシャル・チャネル上で対応可能なサービスを指定する要求又は問い合わせを自ら送信するとともに、自ら送信した要求又は問い合わせに対する応答又は対応可能なサービスを指定する要求又は問い合わせの受信待機を行なった後に、対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信する、通信装置。
（９）ソーシャル・チャネル以外での要求又は問い合わせの送信を行なうべきか否かをユーザーに確認した後又は所定の時間が経過した後に、対応可能なすべてのチャネル上で要求又は問い合わせを送信する、上記（８）に記載の通信装置。
（１０）Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、使用できるチャネルがオペレーティング・チャネルに限定される状況下において、
サービス・アドバータイザー機能のみを動作させているときに、前記オペレーティング・チャネル上で、対応可能なサービスを指定する要求又は問い合わせを受信したことをトリガーにして、サービス・シーカー機能の動作を開始して、前記オペレーティング・チャネル上で対応可能なサービスを指定する要求又は問い合わせを送信する、通信装置。
（１１）Ｗｉ−Ｆｉ Ｐ２Ｐを用いるサービスをサポートする通信装置であって、使用できるチャネルがオペレーティング・チャネルに限定される状況下において、
サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させているときに、前記オペレーティング・チャネル上で、プローブ要求フレームを送信するとともに、他のデバイスからのプローブ要求フレームの受信、又は、自デバイスが送信したプローブ要求フレームに対するプローブ応答フレームの受信を待機する、通信装置。
（１２）Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置の通信方法であって、
サービス・シーカー機能の動作を開始するステップと、
サービス・アドバータイザー機能の動作が停止しているときに、さらにサービス・アドバータイザー機能の動作を開始するステップと、
を有する通信方法。
（１３）Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置の通信方法であって、
サービス・アドバータイザー機能を動作させて、他の通信装置からの対応可能なサービスを指定する要求又は問い合わせを受信待機するステップと、
対応可能なサービスを指定する要求又は問い合わせを受信したことをトリガーにして、サービス・シーカー機能の動作を開始して、対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
を有する通信方法。
（１４）Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートし、使用できるチャネルに制限がない状況下における通信装置の通信方法であって、
サービス・アドバータイザー機能を動作させて、ソーシャル・チャネル上で他のデバイスからの対応可能なサービスを指定する要求又は問い合わせを受信待機するステップと、
対応可能なサービスを指定する要求又は問い合わせを所定の時間内に受信できなかったことをトリガーにして、サービス・シーカー機能の動作を開始するステップと、
対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
を有する通信方法。
（１５）Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートし、使用できるチャネルに制限がない状況下における通信装置の通信方法であって、
サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させるステップと、
ソーシャル・チャネル上で、自ら送信した対応可能なサービスを指定する要求又は問い合わせに対する応答を受信待機するステップと、
自ら送信した要求又は問い合わせに対する応答を所定の時間内に受信できず、又は対応可能なサービスを指定する要求又は問い合わせを所定の時間内に受信できなかったことをトリガーにして、対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
を有する通信方法。
（１６）Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートし、使用できるチャネルに制限がない状況下における通信装置の通信方法であって、
サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させるステップと、
ソーシャル・チャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
自ら送信した要求又は問い合わせに対する応答又は対応可能なサービスを指定する要求又は問い合わせを受信待機するステップと、
対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
を有する通信方法。
（１７）Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートし、使用できるチャネルがオペレーティング・チャネルに限定される状況下における通信装置の通信方法であって、
サービス・アドバータイザー機能を動作させて、前記オペレーティング・チャネル上で他のデバイスからの対応可能なサービスを指定する要求又は問い合わせを受信待機するステップと、
前記オペレーティング・チャネル上で、対応可能なサービスを指定する要求又は問い合わせを受信したことをトリガーにして、サービス・シーカー機能の動作を開始するステップと、
前記オペレーティング・チャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
を有する通信方法。
（１８）Ｗｉ−Ｆｉ Ｐ２Ｐを用いるサービスをサポートし、使用できるチャネルがオペレーティング・チャネルに限定される状況下における通信装置の通信方法であって、
サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させるステップと、
前記オペレーティング・チャネル上で、プローブ要求フレームを送信するステップと、
前記オペレーティング・チャネル上で、他のデバイスからのプローブ要求フレームの受信、又は、自デバイスが送信したプローブ要求フレームに対するプローブ応答フレームの受信を待機するステップと、
を有する通信方法。

４００…通信装置、４０１…データ処理部、４０２…制御部
４０３…通信部、４０４…電源部
４１１…変復調部、４１２…空間信号処理部
４１３…チャネル推定部、４１４…無線インターフェース部
４１５…アンプ部、４１６…アンテナ

Claims (18)

1. Ｗｉ−Ｆｉ Ｐ２Ｐ（Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）又はＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）接続を用いるサービスをサポートする通信装置であって、
   サービス・アドバータイザー機能又はサービス・シーカー機能のどちらか一方を動作させようとする際に、サービス・アドバータイザー機能及びサービス・シーカー機能の両方を動作させる、通信装置。
2. 前記通信装置内で、ＡＳＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ｐｌａｔｆｏｒｍ）がサービス層からシーク・サービス・メソッドを受信したことをトリガーにしてサービス・シーカー機能を動作させ、さらにサービス・アドバータイザー機能の動作が停止しているときにはサービス・アドバータイザー機能も動作させる、請求項１に記載の通信装置。
3. Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、
   サービス・アドバータイザー機能のみを動作させているときに、対応可能なサービスを指定する要求又は問い合わせを受信したことをトリガーにして、サービス・シーカー機能の動作を開始する、通信装置。
4. サービス・アドバータイザー機能のみを動作させているときに、対応可能なサービス名称にマッチするハッシュ値を含んだ要求又は対応可能なサービス名称を示す文字列を含んだ問い合わせを受信したことをトリガーにして、サービス・シーカー機能を動作させて他の通信装置へ対応可能なサービスを指定する要求又は問い合わせを送信する、請求項３に記載の通信装置。
5. Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、使用できるチャネルに制限がない状況下において、
   サービス・アドバータイザー機能のみを動作させているときに、ソーシャル・チャネル上で、対応可能なサービスを指定する要求又は問い合わせを所定の時間内に受信できなかったことをトリガーにして、サービス・シーカー機能の動作を開始して、対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信する、通信装置。
6. サービス・シーカー機能を用いて送信した要求又は問い合わせに対する応答を第２の所定の時間内に受信できなかったことをトリガーにして、サービス・シーカー機能を停止する、請求項５に記載の通信装置。
7. Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、使用できるチャネルに制限がない状況下において、
   サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させているときに、ソーシャル・チャネル上で、自ら送信した対応可能なサービスを指定する要求又は問い合わせに対する応答を所定の時間内に受信できず、又は対応可能なサービスを指定する要求又は問い合わせを所定の時間内に受信できなかったことをトリガーにして、対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信する、通信装置。
8. Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、使用できるチャネルに制限がない状況下において、
   サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させているときに、ソーシャル・チャネル上で対応可能なサービスを指定する要求又は問い合わせを自ら送信するとともに、自ら送信した要求又は問い合わせに対する応答又は対応可能なサービスを指定する要求又は問い合わせの受信待機を行なった後に、対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信する、通信装置。
9. ソーシャル・チャネル以外での要求又は問い合わせの送信を行なうべきか否かをユーザーに確認した後又は所定の時間が経過した後に、対応可能なすべてのチャネル上で要求又は問い合わせを送信する、請求項８に記載の通信装置。
10. Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置であって、使用できるチャネルがオペレーティング・チャネルに限定される状況下において、
    サービス・アドバータイザー機能のみを動作させているときに、前記オペレーティング・チャネル上で、対応可能なサービスを指定する要求又は問い合わせを受信したことをトリガーにして、サービス・シーカー機能の動作を開始して、前記オペレーティング・チャネル上で対応可能なサービスを指定する要求又は問い合わせを送信する、通信装置。
11. Ｗｉ−Ｆｉ Ｐ２Ｐを用いるサービスをサポートする通信装置であって、使用できるチャネルがオペレーティング・チャネルに限定される状況下において、
    サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させているときに、前記オペレーティング・チャネル上で、プローブ要求フレームを送信するとともに、他のデバイスからのプローブ要求フレームの受信、又は、自デバイスが送信したプローブ要求フレームに対するプローブ応答フレームの受信を待機する、通信装置。
12. Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置の通信方法であって、
    サービス・シーカー機能の動作を開始するステップと、
    サービス・アドバータイザー機能の動作が停止しているときに、さらにサービス・アドバータイザー機能の動作を開始するステップと、
    を有する通信方法。
13. Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートする通信装置の通信方法であって、
    サービス・アドバータイザー機能を動作させて、他の通信装置からの対応可能なサービスを指定する要求又は問い合わせを受信待機するステップと、
    対応可能なサービスを指定する要求又は問い合わせを受信したことをトリガーにして、サービス・シーカー機能の動作を開始して、対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
    を有する通信方法。
14. Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートし、使用できるチャネルに制限がない状況下における通信装置の通信方法であって、
    サービス・アドバータイザー機能を動作させて、ソーシャル・チャネル上で他のデバイスからの対応可能なサービスを指定する要求又は問い合わせを受信待機するステップと、
    対応可能なサービスを指定する要求又は問い合わせを所定の時間内に受信できなかったことをトリガーにして、サービス・シーカー機能の動作を開始するステップと、
    対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
    を有する通信方法。
15. Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートし、使用できるチャネルに制限がない状況下における通信装置の通信方法であって、
    サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させるステップと、
    ソーシャル・チャネル上で、自ら送信した対応可能なサービスを指定する要求又は問い合わせに対する応答を受信待機するステップと、
    自ら送信した要求又は問い合わせに対する応答を所定の時間内に受信できず、又は対応可能なサービスを指定する要求又は問い合わせを所定の時間内に受信できなかったことをトリガーにして、対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
    を有する通信方法。
16. Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートし、使用できるチャネルに制限がない状況下における通信装置の通信方法であって、
    サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させるステップと、
    ソーシャル・チャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
    自ら送信した要求又は問い合わせに対する応答又は対応可能なサービスを指定する要求又は問い合わせを受信待機するステップと、
    対応可能なすべてのチャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
    を有する通信方法。
17. Ｗｉ−Ｆｉ Ｐ２Ｐ又はＢＳＳ接続を用いるサービスをサポートし、使用できるチャネルがオペレーティング・チャネルに限定される状況下における通信装置の通信方法であって、
    サービス・アドバータイザー機能を動作させて、前記オペレーティング・チャネル上で他のデバイスからの対応可能なサービスを指定する要求又は問い合わせを受信待機するステップと、
    前記オペレーティング・チャネル上で、対応可能なサービスを指定する要求又は問い合わせを受信したことをトリガーにして、サービス・シーカー機能の動作を開始するステップと、
    前記オペレーティング・チャネル上で対応可能なサービスを指定する要求又は問い合わせを送信するステップと、
    を有する通信方法。
18. Ｗｉ−Ｆｉ Ｐ２Ｐを用いるサービスをサポートし、使用できるチャネルがオペレーティング・チャネルに限定される状況下における通信装置の通信方法であって、
    サービス・シーカー機能及びサービス・アドバータイザー機能の両方を動作させるステップと、
    前記オペレーティング・チャネル上で、プローブ要求フレームを送信するステップと、
    前記オペレーティング・チャネル上で、他のデバイスからのプローブ要求フレームの受信、又は、自デバイスが送信したプローブ要求フレームに対するプローブ応答フレームの受信を待機するステップと、
    を有する通信方法。

Images