特許 6009700 ピアツーピアプレアソシエーション発見動作

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6009700

(24)【登録日】2016年9月23日

(45)【発行日】2016年10月19日

(54)【発明の名称】ピアツーピアプレアソシエーション発見動作

(51)【国際特許分類】

   H04W 8/00 20090101AFI20161006BHJP

   H04W 76/02 20090101ALI20161006BHJP

   H04W 84/12 20090101ALI20161006BHJP

   H04W 84/18 20090101ALI20161006BHJP

【ＦＩ】

   H04W8/00 110

   H04W76/02

   H04W84/12

   H04W84/18

【請求項の数】40

【全頁数】32

(21)【出願番号】特願2015-561421(P2015-561421)

(86)(22)【出願日】2014年2月27日

(65)【公表番号】特表2016-514420(P2016-514420A)

(43)【公表日】2016年5月19日

(86)【国際出願番号】US2014018958

(87)【国際公開番号】WO2014137734

(87)【国際公開日】20140912

【審査請求日】2015年12月8日

(31)【優先権主張番号】13/786,799

(32)【優先日】2013年3月6日

(33)【優先権主張国】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】595020643

【氏名又は名称】クゥアルコム・インコーポレイテッド

【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100109830

【弁理士】

【氏名又は名称】福原 淑弘

(74)【代理人】

【識別番号】100158805

【弁理士】

【氏名又は名称】井関 守三

(74)【代理人】

【識別番号】100194814

【弁理士】

【氏名又は名称】奥村 元宏

(72)【発明者】

【氏名】ティング、セン−コーン

【審査官】 三浦 みちる

(56)【参考文献】

【文献】 特表２０１０−５１１３２３（ＪＰ，Ａ）

【文献】 特表２０１３−５０４２８０（ＪＰ，Ａ）

【文献】 特表２０１３−５１５３９２（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１１／０２１６７５３（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｗ ４／００−９９／００

(57)【特許請求の範囲】

【請求項1】

ピアツーピア（Ｐ２Ｐ）ネットワーク中のクライアントデバイスを動作させる方法において、
前記方法は、
デバイス発見フェーズの間、
１つ以上のピアデバイスに対してプローブ要求をブロードキャストすることによって、前記Ｐ２Ｐネットワークの１つ以上のチャネルをスキャンして、前記ピアデバイスの存在を発見することと、前記プローブ要求は、前記クライアントデバイスによって提供される多数のＰ２Ｐサービスを示している多数の第１のハッシュ値を含み、
多数の前記ピアデバイスのそれぞれから、第１のフレームを受信し、各第１のフレームは、（ｉ）対応するピアデバイスとのＰ２Ｐ接続を確立するための管理情報と、（ｉｉ）前記対応するピアデバイスによってサポートされている多数のＰ２Ｐサービスを示しているサービス情報とを含むことと、
サービス発見フェーズの間、前記サービス情報に少なくとも部分的に基づいて、選択したピアデバイスにサービス発見要求を送ることとを含み、前記サービス発見要求は、１つ以上の特定のＰ２Ｐサービスを要求することである方法。

【請求項2】

前記選択したピアデバイスが、前記サービス情報において、前記１つ以上の特定のＰ２Ｐサービスに対するサポートを示す場合のみ、前記クライアントデバイスは、前記選択したピアデバイスに前記サービス発見要求を送る請求項１記載の方法。

【請求項3】

前記第１のフレームのうちの少なくとも１つは、プローブ応答を含む請求項１記載の方法。

【請求項4】

前記プローブ応答は、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを示している多数の第２のハッシュ値を含む請求項３記載の方法。

【請求項5】

前記クライアントデバイスは、前記第１のハッシュ値を前記第２のハッシュ値と比較して、前記対応するピアデバイスが、前記クライアントデバイスによって要求されることになる前記Ｐ２Ｐサービスをサポートするか否かを決定する請求項４記載の方法。

【請求項6】

前記特定のＰ２Ｐサービスは、以下の、ユニバーサル・プラグ・アンド・プレイサービス、ボンジュール・サービス、Ｗｉ−Ｆｉディスプレイサービス、プリントサービス、ゲームサービス、ファイル共有サービスのうちの１つ以上を含む請求項１記載の方法。

【請求項7】

前記スキャンすることは、前記対応するピアデバイスからブロードキャストされるビーコンフレームを聞くことによって実行され、前記第１のフレームは、前記ビーコンフレームを含む請求項１記載の方法。

【請求項8】

前記ビーコンフレームのうちの少なくとも１つは、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを示している多数のハッシュ値を含む請求項７記載の方法。

【請求項9】

前記１つ以上のピアデバイスはＰ２Ｐグループを含み、前記第１のフレームのそれぞれの１つは、前記Ｐ２Ｐグループのグループオーナーによりブロードキャストされるビーコンフレームを含む請求項１記載の方法。

【請求項10】

前記サービス情報は、前記Ｐ２Ｐグループの１人以上のメンバーが、前記１つ以上の特定のＰ２Ｐサービスを提供するように構成されているか否かを示す請求項９記載の方法。

【請求項11】

前記サービス情報は、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスに対する１つ以上の更新を示す請求項１記載の方法。

【請求項12】

前記Ｐ２Ｐサービスに対する前記１つ以上の更新を示している前記ピアデバイスに対してのみ、サービス発見要求フレームを送信することをさらに含む請求項１１記載の方法。

【請求項13】

プログラム命令を含んでいる一時的でないコンピュータ読取可能記憶媒体において、
前記命令は、ピアツーピア（Ｐ２Ｐ）ネットワークに関係付けられているクライアントデバイスのプロセッサによって実行されるときに、前記クライアントデバイスに、
デバイス発見フェーズの間、
１つ以上のピアデバイスに対してプローブ要求をブロードキャストすることによって、前記Ｐ２Ｐネットワークの１つ以上のチャネルをスキャンさせて、前記ピアデバイスの存在を発見させ、前記プローブ要求は、前記クライアントデバイスによって提供される多数のＰ２Ｐサービスを示している多数の第１のハッシュ値を含み、
多数の前記ピアデバイスのそれぞれから、第１のフレームを受信させ、各第１のフレームは、（ｉ）対応するピアデバイスとのＰ２Ｐ接続を確立するための管理情報と、（ｉｉ）前記対応するピアデバイスによってサポートされている多数のＰ２Ｐサービスを示しているサービス情報とを含み、
サービス発見フェーズの間、前記サービス情報に少なくとも部分的に基づいて、選択したピアデバイスにサービス発見要求を送らせ、前記サービス発見要求は、１つ以上の特定のＰ２Ｐサービスを要求することである一時的でないコンピュータ読取可能記憶媒体。

【請求項14】

前記選択したピアデバイスが、前記サービス情報において、前記１つ以上の特定のＰ２Ｐサービスに対するサポートを示す場合のみ、前記クライアントデバイスは、前記選択したピアデバイスに前記サービス発見要求を送る請求項１３記載の一時的でないコンピュータ読取可能記憶媒体。

【請求項15】

前記第１のフレームは、プローブ応答を含む請求項１３記載の一時的でないコンピュータ読取可能記憶媒体。

【請求項16】

前記プローブ応答のうちの少なくとも１つは、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを示している多数の第２のハッシュ値を含む請求項１５記載の一時的でないコンピュータ読取可能記憶媒体。

【請求項17】

前記クライアントデバイスは、前記第１のハッシュ値を前記第２のハッシュ値と比較して、前記対応するピアデバイスが、前記クライアントデバイスによって要求されることになる前記Ｐ２Ｐサービスをサポートするか否かを決定する請求項１６記載の一時的でないコンピュータ読取可能記憶媒体。

【請求項18】

前記特定のＰ２Ｐサービスは、以下の、ユニバーサル・プラグ・アンド・プレイサービス、ボンジュール・サービス、Ｗｉ−Ｆｉディスプレイサービス、プリントサービス、ゲームサービス、ファイル共有サービスのうちの１つ以上を含む請求項１３記載の一時的でないコンピュータ読取可能記憶媒体。

【請求項19】

スキャンするための、前記プログラム命令の実行は、前記クライアントデバイスに、
前記対応するピアデバイスからブロードキャストされるビーコンフレームを聞かせ、前記第１のフレームは、前記ビーコンフレームを含む請求項１３記載の一時的でないコンピュータ読取可能記憶媒体。

【請求項20】

前記ビーコンフレームのうちの少なくとも１つは、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを示している多数のハッシュ値を含む請求項１９記載の一時的でないコンピュータ読取可能記憶媒体。

【請求項21】

前記１つ以上のピアデバイスはＰ２Ｐグループを含み、前記第１のフレームのそれぞれの１つは、前記Ｐ２Ｐグループのグループオーナーによりブロードキャストされるビーコンフレームを含む請求項１３記載の一時的でないコンピュータ読取可能記憶媒体。

【請求項22】

前記サービス情報は、前記Ｐ２Ｐグループの１人以上のメンバーが、前記１つ以上の特定のＰ２Ｐサービスを提供するように構成されているか否かを示す請求項２１記載の一時的でないコンピュータ読取可能記憶媒体。

【請求項23】

前記サービス情報は、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスに対する１つ以上の更新を示す請求項１３記載の一時的でないコンピュータ読取可能記憶媒体。

【請求項24】

前記プログラム命令の実行は、さらに、前記クライアントデバイスに、
前記Ｐ２Ｐサービスに対する前記１つ以上の更新を示している前記ピアデバイスに対してのみ、サービス発見要求フレームを送信させる請求項２３記載の一時的でないコンピュータ読取可能記憶媒体。

【請求項25】

ピアツーピア（Ｐ２Ｐ）ネットワークに関係付けられているクライアントデバイスにおいて、
前記クライアントデバイスは、
１つ以上のピアデバイスに対してプローブ要求をブロードキャストすることによって、前記Ｐ２Ｐネットワークの１つ以上のチャネルをスキャンして、前記ピアデバイスの存在を発見し、前記プローブ要求は、前記クライアントデバイスによって提供される多数のＰ２Ｐサービスを示している多数の第１のハッシュ値を含む手段と、
多数の前記ピアデバイスのそれぞれから、第１のフレームを受信し、各第１のフレームは、（ｉ）対応するピアデバイスとのＰ２Ｐ接続を確立するための管理情報と、（ｉｉ）前記対応するピアデバイスによってサポートされている多数のＰ２Ｐサービスを示しているサービス情報とを含む手段と、
前記サービス情報に少なくとも部分的に基づいて、選択したピアデバイスにサービス発見要求を送り、前記サービス発見要求は、１つ以上の特定のＰ２Ｐサービスを要求することである手段とを具備するクライアントデバイス。

【請求項26】

前記選択したピアデバイスが、前記サービス情報において、前記１つ以上の特定のＰ２Ｐサービスに対するサポートを示す場合のみ、前記クライアントデバイスは、前記選択したピアデバイスに前記サービス発見要求を送る請求項２５記載のクライアントデバイス。

【請求項27】

前記第１のフレームのうちの少なくとも１つは、プローブ応答を含む請求項２５記載のクライアントデバイス。

【請求項28】

前記プローブ応答は、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを示している多数の第２のハッシュ値を含む請求項２７記載のクライアントデバイス。

【請求項29】

前記クライアントデバイスは、前記第１のハッシュ値を前記第２のハッシュ値と比較して、前記対応するピアデバイスが、前記クライアントデバイスによって要求されることになる前記Ｐ２Ｐサービスをサポートするか否かを決定する請求項２８記載のクライアントデバイス。

【請求項30】

前記スキャンすることは、前記対応するピアデバイスからブロードキャストされるビーコンフレームを聞くことによって実行され、前記第１のフレームは、前記ビーコンフレームを含む請求項２５記載のクライアントデバイス。

【請求項31】

前記ビーコンフレームのうちの少なくとも１つは、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを示している多数のハッシュ値を含む請求項３０記載のクライアントデバイス。

【請求項32】

前記１つ以上のピアデバイスはＰ２Ｐグループを含み、前記第１のフレームのそれぞれの１つは、前記Ｐ２Ｐグループのグループオーナーによりブロードキャストされるビーコンフレームを含む請求項２５記載のクライアントデバイス。

【請求項33】

ピアツーピア（Ｐ２Ｐ）ネットワークに関係付けられているクライアントデバイスにおいて、
前記クライアントデバイスは、
１つ以上のピアデバイスとデータを交換するトランシーバと、
プロセッサとを具備し、
前記プロセッサは、
デバイス発見フェーズの間、
前記１つ以上のピアデバイスにプローブ要求を送信し、前記プローブ要求は、前記クライアントデバイスにより提供される多数のＰ２Ｐサービスを識別する第１のサービス情報を含み、前記第１のサービス情報は、前記クライアントデバイスによって提供される前記多数のＰ２Ｐサービスを識別する多数の第１のハッシュ値を含み、
多数の前記ピアデバイスのそれぞれから、プローブ応答を受信し、各プローブ応答は、（ｉ）対応するピアデバイスとのＰ２Ｐ接続を確立するための管理情報と、（ｉｉ）前記対応するピアデバイスによってサポートされている多数のＰ２Ｐサービスを識別する第２のサービス情報とを含み、
サービス発見フェーズの間、
前記第２のサービス情報に基づいて、選択したピアデバイスにサービス発見要求を送り、前記サービス発見要求は、１つ以上の特定のＰ２Ｐサービスを要求することであるクライアントデバイス。

【請求項34】

前記選択したピアデバイスが、前記プローブ応答において、前記１つ以上の特定のＰ２Ｐサービスに対するサポートを示す場合のみ、前記クライアントデバイスは、前記選択したピアデバイスに前記サービス発見要求を送る請求項３３記載のクライアントデバイス。

【請求項35】

前記第２のサービス情報は、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを識別する多数の第２のハッシュ値を含む請求項３３記載のクライアントデバイス。

【請求項36】

前記クライアントデバイスは、前記第１のハッシュ値を前記第２のハッシュ値と比較して、前記対応するピアデバイスが、前記クライアントデバイスによって要求されることになる前記Ｐ２Ｐサービスをサポートするか否かを決定する請求項３５記載のクライアントデバイス。

【請求項37】

前記特定のＰ２Ｐサービスは、以下の、ユニバーサル・プラグ・アンド・プレイサービス、ボンジュール・サービス、Ｗｉ−Ｆｉディスプレイサービス、プリントサービス、ゲームサービス、ファイル共有サービスのうちの１つ以上を含む請求項３３記載のクライアントデバイス。

【請求項38】

前記１つ以上のピアデバイスは、Ｐ２Ｐグループを含む請求項３３記載のクライアントデバイス。

【請求項39】

前記第２のサービス情報は、前記Ｐ２Ｐグループの１人以上のメンバーが、前記１つ以上の特定のＰ２Ｐサービスを提供するように構成されているか否かを示す請求項３８記載のクライアントデバイス。

【請求項40】

前記第２のサービス情報は、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスに対する１つ以上の更新を示す請求項３３記載のクライアントデバイス。

【発明の詳細な説明】

【技術分野】

【0001】

［０００１］
本実施形態は、一般的に、ワイヤレスピアツーピアネットワークに関連し、特に、Ｗｉ−Ｆｉ（登録商標）デバイスによって提供されるサービスのプレアソシエーション発見に関連する。

【関連技術の背景】

【0002】

［０００２］
「Ｗｉ−Ｆｉダイレクト」としても知られているＷｉ−Ｆｉアライアンスピアツーピア（Ｐ２Ｐ）仕様は、ピアデバイス間のプレアソシエーションサービス発見を可能にしている。このプロトコルは、もしあれば、何のサービスがピアＳＴＡによって提供されるかを決定するために、クライアントデバイスまたは局（ＳＴＡ）が、Ｗｉ−Ｆｉ範囲内でピアＳＴＡに問い合わせるのを可能にする。このようなサービスの例は、プリント、ゲーム、ファイル共有、および／または、インターネットゲートウェイサービスを含んでいてもよい。ピアＳＴＡによって提供されるサービスを決定することは、典型的に、通信の少なくとも２つのフェーズ、デバイス発見フェーズと、後に続くサービス発見フェーズとを要求する。

【0003】

［０００３］
デバイス発見フェーズの間、クライアントＳＴＡ（例えば、特定のＰ２Ｐサービスを要求するＳＴＡ）は、Ｗｉ−Ｆｉ通信範囲内で他のＳＴＡのアイデンティティおよび／または利用可能性を決定する。到来ビーコンフレームに対して、３つのソーシャルチャネル（例えば、２．４ＧＨｚ帯域中のチャネル１、６および１１）を「スキャンすること」によって、および／または、これらのチャネルを聞くかもしれない任意のＳＴＡにプローブ要求フレームをブロードキャストすることによって、クライアントＳＴＡは典型的にこれを行う。その後、サービス発見フェーズの間、クライアントＳＴＡは、それらが提供するサービスについて、（デバイス発見フェーズの間に発見した）利用可能なピアＳＴＡに問い合わせる。クライアントＳＴＡは、典型的に、クライアントＳＴＡが、要求されたサービスを提供するピアＳＴＡを識別するまで、サービス発見動作をサポートする各ピアＳＴＡに、一回に１つの、サービス発見要求を送信する。

【0004】

［０００４］
よって、サービス発見フェーズの間、要求されたサービスを提供するピアＳＴＡを識別する前に、クライアントＳＴＡは、（そのうちのいくつかは、何らＰ２Ｐサービスを提供しないかもしれない）いくつかのピアＳＴＡに問い合わせることが多い。これは、クライアントＳＴＡが、典型的に、サービス発見フェーズの後まで、（もしあれば）ピアＳＴＡのそれぞれが提供するサービスに気付かないからである。さらに、クライアントＳＴＡは、典型的に、各ピアＳＴＡとのサービス発見動作（およびデバイス発見動作）を周期的に反復しない限り、以前に発見したピアＳＴＡによって提供されたサービスが変化したか否かについての知識を有さない。よって、所望のサービスを提供するピアＳＴＡを発見する際に、相当な量の時間とリソースが消費されるかもしれない。

【図面の簡単な説明】

【0005】

［０００５］
本実施形態は例として図示されており、付随する図面の図によって限定されることは意図されていない。

【図1A】［０００６］ 図１Ａは、本実施形態が実現されるピアツーピア（Ｐ２Ｐ）Ｗｉ−Ｆｉシステムを図示している。

【図1B】図１Ｂは、本実施形態が実現されるピアツーピア（Ｐ２Ｐ）Ｗｉ−Ｆｉシステムを図示している。

【図2】［０００７］ 図２は、いくつかの実施形態にしたがった、ワイヤレス局（ＳＴＡ）のブロックダイヤグラムを示している。

【図3】［０００８］ 図３は、いくつかの実施形態にしたがった、プレアソシエーション発見動作を図示している例示的なフローチャートである。

【図4】［０００９］ 図４は、いくつかの実施形態にしたがった、より詳細なプレアソシエーション発見動作を図示している例示的なフローチャートである。

【図5】［００１０］ 図５は、いくつかの実施形態にしたがった、管理フレームのブロックダイヤグラムを示している。

【図6A】［００１１］ 図６Ａは、本実施形態が実現されてもよい別のＰ２Ｐ Ｗｉ−Ｆｉシステムを図示している。

【図6B】図６Ｂは、本実施形態が実現されてもよい別のＰ２Ｐ Ｗｉ−Ｆｉシステムを図示している。

【図7】［００１２］ 図７は、いくつかの実施形態にしたがった、別のプレアソシエーション発見動作を図示している例示的なフローチャートである。

【図8】［００１３］ 図８は、本実施形態が実現されてもよいＰ２Ｐ Ｗｉ−Ｆｉシステムの別の実施形態を図示している。

【図9】［００１４］ 図９は、いくつかの実施形態にしたがった、別のワイヤレスＳＴＡのブロックダイヤグラムを示している。

【図10】［００１５］ 図１０は、プレアソシエーション発見動作の別の実施形態を図示している例示的なフローチャートである。

【図11】［００１６］ 図１１は、いくつかの実施形態にしたがった、デバイスおよびサービス発見フレームのブロックダイヤグラムを示している。

【詳細な説明】

【0006】

［００１７］
簡潔にするためだけに、Ｗｉ−Ｆｉ使用可能なデバイスにより実行される、および、Ｗｉ−Ｆｉ使用可能なデバイスの間で実行される、プレアソシエーションサービス発見動作の状況において、本実施形態を以下に説明する。本実施形態は、他のさまざまなワイヤレス標準規格またはプロトコルの信号を使用して、プレアソシエーションサービス発見動作を実行するために、等しく適用可能であることが理解される。ここで使用するとき、用語ＷＬＡＮおよびＷｉ−Ｆｉは、ＩＥＥＥ８０２．１１標準規格によって管理される通信、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ハイパーＬＡＮ（ヨーロッパにおいて主に使用され、ＩＥＥＥ８０２．１１標準規格に相当するワイヤレス標準規格のセット）、ワイヤレス通信において使用される他の技術を含むことがある。さらに、用語「クライアントデバイス」は、ピアツーピア（Ｐ２Ｐ）ネットワークにおける特定のサービスを要求するワイヤレスデバイスに言及し、用語「ピアデバイス」は、Ｐ２Ｐネットワークにおけるクライアントデバイスによって発見可能であるワイヤレスデバイスに言及している。用語「デバイス」および「局」（またはＳＴＡ）は、ここで、交換可能に使用することがある。

【0007】

［００１８］
以下の記述において、本開示の完全な理解を提供するために、特定のコンポーネント、回路、およびプロセスの例のような、多数の特定の詳細を明らかにしている。ここで使用されているような用語「結合されている」は、直接的に接続されていること、あるいは、１つ以上の介入しているコンポーネントまたは回路を通して接続されていることを意味する。また、本実施形態の完全な理解を提供するために、以下の記述において、および、説明の目的で、特定の術語を明らかにしている。しかしながら、これらの特定の詳細が本実施形態を実施するために要求されないかもしれないことは、当業者にとって明らかであろう。本開示を不明確にするのを防ぐために、他の例において、よく知られている回路およびデバイスをブロックダイヤグラム形態で示している。ここで説明している、さまざまなバスを介して提供される信号のうちのいずれかは、他の信号と時間多重化されるかもしれないし、１つ以上の共通のバスを介して提供されるかもしれない。付加的に、回路エレメント間またはソフトウェアブロック間の相互接続は、バスとして、または、単一の信号ラインとして示されているかもしれない。バスのそれぞれは代替的に単一の信号ラインになるかもしれず、単一の信号ラインのそれぞれは代替的にバスになるかもしれず、単一のラインまたはバスは、コンポーネント間の通信のための無数の物理的または論理的メカニズムのうちの任意の１つ以上を表しているかもしれない。本実施形態は、ここで説明する特定の例に限定して解釈されるものではなく、むしろその範囲内に、添付された特許請求の範囲によって規定されたすべての実施形態を含むものである。

【0008】

［００１９］
図１Ａおよび図Ｂは、本実施形態が実現されるかもしれないピアツーピア（Ｐ２Ｐ）Ｗｉ−Ｆｉシステム１００を図示している。システム１００は、多数のピアＳＴＡ１０２〜１０４のＷｉ−Ｆｉ通信範囲内に位置しているクライアント局（ＳＴＡ）１０１を含むように示されている。簡潔にするために、３つのピアＳＴＡ１０２〜１０４のみが図１Ａおよび図１Ｂ中に示されているが、Ｗｉ−Ｆｉシステム１００は、任意の数のピアＳＴＡを含んでいてもよいことを理解すべきである。ＳＴＡ１０１〜１０４は、Ｗｉ−Ｆｉ媒体（またはチャネル）を通して、Ｐ２Ｐ方法において、互いに通信するように構成されている。さらに特に、アクセスポイントの支援なしに、クライアントＳＴＡ１０１は、ピアＳＴＡ１０２〜１０４のそれぞれを、識別するか、または、発見してもよく、その後、ピアＳＴＡ１０２〜１０４のうちの選択した１つとの直接的なＰ２Ｐ接続を確立する。

【0009】

［００２０］
図１Ａにおいて示されているように、Ｗｉ−Ｆｉ通信に対して使用されているソーシャルチャネル（例えば、２．４ＧＨｚ帯域におけるチャネル１、６および１１）をスキャンすることによって、クライアントＳＴＡ１０１は、デバイス発見動作を開始してもよい。例えば、クライアントＳＴＡ１０１は、ソーシャルチャネルのそれぞれ上でプローブ要求（Ｐ＿Ｒｅｑ）フレームをブロードキャストしてもよく、Ｐ＿Ｒｅｑフレームに応答して、ピアＳＴＡ１０２〜１０４によって送信されるプローブ応答（Ｐ＿Ｒｅｓｐ）フレームを聞いてもよい。Ｐ＿Ｒｅｑフレームは、クライアントＳＴＡ１０１が、ピアＳＴＡ１０２〜１０４のうちの対応する１つとの通信リンクを確立するか否かを決定するために、ピアＳＴＡ１０２〜１０４によって使用されるかもしれない管理情報を含んでいる。同様に、Ｐ＿Ｒｅｓｐフレームも、パラメータを識別して、ピアＳＴＡ１０２〜１０４のうちの対応する１つと一致させるために、クライアントＳＴＡ１０１によって使用されるかもしれない管理情報を含んでいてもよい。ＳＴＡ１０１〜１０４のそれぞれと関係付けられている管理情報は、例えば、ＭＡＣアドレスと、対応するＳＴＡによってサポートされているデータレートとを含んでいてもよい。

【0010】

［００２１］
本実施形態にしたがうと、Ｐ＿Ｒｅｑフレームは、クライアントＳＴＡ１０１によって提供される、１つ以上の対応するサービスを識別する１つ以上のサービスクエリストリングのリストも含んでいてもよい。これらのサービスクエリストリングは、サービス発見フェーズの間に、クライアントＳＴＡ１０１に対して提示されている場合、ＳＴＡ１０１がこれらのサービスをサポートできることを示すように、有効なサービス応答ストリングを有するだろう。反対に、クライアントＳＴＡ１０１が、任意の所定のサービスクエリストリングに対して無効であるか、または、空のサービス応答ストリングを有している場合、これは、対応するサービスをサポートしないことを示している。いくつかの実施形態に対して、各サービスクエリストリングは、クライアントＳＴＡ１０１によって提供される特定のサービスを識別していてもよい。さらに、各ピアＳＴＡは、対応するサービス応答ストリングを有している、サポートされているサービスクエリストリングのリストを記憶してもよいので、特定のピアＳＴＡ内に記憶されている、サポートされているサービスクエリストリングのリストは、どのサービスが特定のピアＳＴＡによってサポートされているかを示していてもよい。この方法において、クライアントＳＴＡ１０１は、サービス発見動作を始める前に、近くのピアＳＴＡ１０２〜１０４のそれぞれによりどのサービスがサポートされているかを決定してもよく、このことは、以下にさらに詳細に説明するように、クライアントＳＴＡ１０１が、選択したサブセットのピアＳＴＡとともに、サービス発見動作を開始するのを可能にする。よって、クライアントＳＴＡ１０１によって要求される１つ以上のサービスをサポートすると（デバイス発見フェーズの間に）決定されているピアＳＴＡのみとともに、サービス発見動作を開始することによって、選択したピアＳＴＡとのＰ２Ｐ接続を確立することに関係付けられている時間および／またはリソースは（例えば、従来のＰ２Ｐ発見動作と比較したとき）、減少するかもしれない。

【0011】

［００２２］
いくつかの実施形態に対して、各ピアＳＴＡは、ピアＳＴＡによってサポートされているサービスを識別するこれらのサービスクエリストリングにのみに、応答してもよい。例えば、クライアントＳＴＡ１０１が、（ｉ）プリントサービスに対応する第１のサービスクエリストリングと、（ｉｉ）ゲームサービスに対応する第２のサービスクエリストリングとを含んでいるＰ＿Ｒｅｑフレームを送ることを想定する。ピアＳＴＡ１０３が、ゲームサービスではなく、プリントサービスをサポートする場合、ピアＳＴＡ１０３は、（ゲームサービスに対応するサービス応答ストリングではなく）プリントサービスに対応するサービス応答ストリングを含んでいるＰ＿Ｒｅｓｐフレームを送ってもよい。

【0012】

［００２３］
少なくともいくつかの実施形態に対して、各サービスクエリストリングはハッシュされて、対応するハッシュ値が発生されてもよく、（例えば、圧縮されていないサービスクエリストリングのリストよりもむしろ）クライアントＳＴＡ１０１によって提供されるサービスを識別するこのようなハッシュ値のリストは、Ｐ＿Ｒｅｑフレーム内で提供されてもよい。このようなＰ＿Ｒｅｑフレームを受信する各ピアＳＴＡは、ピアＳＴＡがどのサービスをサポートするかを示しているハッシュ値のリストを含むＰ＿Ｒｅｓｐフレームを送ることにより、応答してもよい。その後、クライアントＳＴＡは、どの望まれるサービスが、ピアＳＴＡによってサポートされているかを決定するために、所望のハッシュ値のリストを、ピアＳＴＡから受信したハッシュ値のリストと比較してもよい。（圧縮されていないサービスクエリストリングのリストよりもむしろ）Ｐ＿ＲｅｑフレームおよびＰ＿Ｒｅｓｐフレームにおいてハッシュ値のリストを提供することは、デバイス発見フェーズの間にＰ２Ｐデバイス間でサービス情報を交換することを可能にする値にまで、Ｐ＿ＲｅｑフレームおよびＰ＿Ｒｅｓｐフレームのサイズを制限するかもしれない。

【0013】

［００２４］
図１Ｂにおいて示されているように、クライアントＳＴＡ１０１は、その後、どのサービスがピアＳＴＡ１０２〜１０４のそれぞれによってサポートされているかの決定に少なくとも部分的に基づいて、ピアＳＴＡ１０２〜１０４のうちの１つ以上とともに、サービス発見動作を開始する。例えば、ピアＳＴＡ１０２〜１０４のうちの１つ以上により、サポートされている１つ以上の特定のサービスを要求するために、クライアントＳＴＡ１０１は、サービス発見要求（ＳＤ＿Ｒｅｑ）フレームをピアＳＴＡ１０２〜１０４のうちの１つ以上に送ってもよい。ピアＳＴＡ１０２〜１０４のそれぞれは、もしあれば、サービス発見応答（ＳＤ＿Ｒｅｓｐ）フレームを、要求するクライアントＳＴＡ１０１に返信することによって、受信したＳＤ＿Ｒｅｑフレームに応答してもよい。クライアントＳＴＡ１０１は、その後、ＳＤ＿Ｒｅｓｐフレームのそれぞれを解析して、対応するピアＳＴＡが、クライアントＳＴＡ１０１が要求している特定のサービスを提供するか否かを確認する。例えば、要求に依存して、ＳＤ＿Ｒｅｓｐフレームは、ピアＳＴＡによって提供またはサポートされているすべてのサービスの詳細なリストを、および／または、クライアントＳＴＡ１０１によって要求される特定のサービスをピアＳＴＡが提供できるか否かに関する確認を含んでいてもよい。

【0014】

［００２５］
いくつかの実施形態に対して、ＳＤ＿Ｒｅｑフレームは、例えば、ユニバーサル・プラグ・アンド・プレイ（ＵＰｎＰ）および／またはボンジュール・サービスのような、あるＰ２Ｐサービスを要求するサービスクエリストリングを含んでいてもよい。このような実施形態に対して、ピアＳＴＡ１０２〜１０４は、これらがサービスクエリストリングをサポートしているか否かを決定してもよく、そうである場合、１つ以上のサービス応答ストリングを発生させてもよい。サービス応答ストリングは、ＳＤ＿Ｒｅｓｐフレームの一部分として（または、他の何らかの適切な応答フレームにおいて）、クライアントＳＴＡ１０１に送信されてもよい。

【0015】

［００２６］
ピアＳＴＡ１０２〜１０４のうちの１つが要求されたサービスを提供することをクライアントＳＴＡ１０１が決定または確認した場合、クライアントＳＴＡ１０１は、その後、ピアＳＴＡによって提供される管理情報を使用して、そのピアＳＴＡとのＰ２Ｐ接続を確立してもよい。クライアントＳＴＡ１０１は、ピアＳＴＡ１０２〜１０４のうちの１つより多くが、要求されたサービスを提供できることを決定した場合、クライアントＳＴＡ１０１は、もしあれば、接続を確立するために、ピアＳＴＡのうちのどれを選択するかのオプションを、ユーザに提供してもよい。

【0016】

［００２７］
図２は、図１Ａおよび図１Ｂの、ＳＴＡ１０１〜１０４のうちの１つの実施形態であるＳＴＡ２００を示している。ＳＴＡ２００は、スキャナ２１０、送信機／受信機回路２２０、プロセッサ２３０およびメモリ２４０を含んでいる。周囲の環境をスキャンするのにスキャナ２１０を使用して、近くのピアＳＴＡ（例えば、ＳＴＡ２００の範囲内のピアＳＴＡ）を検出して識別してもよい。いくつかの実施形態に対して、Ｐ＿Ｒｅｑフレームを周期的にブロードキャストすることによって、スキャナ２１０は近くのピアＳＴＡをサーチしてもよい。さらに、スキャナ２１０は、隣接するデバイスからのビーコンフレームおよび／またはＰ＿Ｒｅｓｐフレームを聞くことによって、ピアＳＴＡをサーチしてもよい。送信機／受信機（すなわち「トランシーバ」）回路２２０は、発見したピアＳＴＡに信号を送信し、発見したピアＳＴＡからの信号を受信するために使用してもよい。

【0017】

［００２８］
メモリ２４０は、ローカルキャッシュとして使用して、複数のピアＳＴＡのＭＡＣアドレス（または、他の適切な識別情報）や、このようなＳＴＡの位置座標や、ＳＴＡによってサポートされているＰ２Ｐサービスや、任意の発見したピアＳＴＡに関係する他の適切な位置またはコンフィギュレーション情報を記憶できる、ＳＴＡテーブル２４２を含んでいてもよい。いくつかの実施形態に対して、ＳＴＡテーブル２４２の各エントリは、関係付けられているＳＴＡの名前を記憶するピアデバイスフィールドと、ＳＴＡのＭＡＣアドレスを記憶するアドレスフィールドと、ＳＴＡの位置座標を記憶する座標フィールドと、（もしあれば）ＳＴＡが提供するように構成されているＰ２Ｐサービスについての情報を記憶するサービスフィールドとを含んでいる。ＳＴＡテーブル２４２は、各関係付けられているピアＳＴＡに対して、どのサービスがピアＳＴＡによってサポートされているかを識別する多数のサービスクエリストリングに対応しているハッシュ値のリストを、および／または、ピアＳＴＡによってサポートされているサービスのリストを記憶していてもよい。

【0018】

［００２９］
メモリ２４０は、ＳＴＡ２００についてのサービス情報を記憶するのに使用できるサービス情報テーブル２４４も含んでいてもよい。いくつかの実施形態に対して、ＳＴＡ２００がサポートするように構成されているサービスの詳細なリストと、ＳＴＡ２００によってサポートされている異なるサービスタイプのリストと、および／または、ＳＴＡ２００によって提供される１つ以上のサービスへの更新または変更に関する情報とを、サービス情報テーブル２４４は含んでいてもよい。サービス情報テーブル２４４は、ＳＴＡ２００によって提供される１つ以上のサービスを識別している多数のサービスクエリストリングに対応するハッシュ値のリストを記憶してもよく、および／または、実際のサービスクエリストリングも記憶してもよい。

【0019】

［００３０］
さらに、メモリ２４０は、以下のソフトウェアモジュールを記憶してもよい一時的でないコンピュータ読取可能な記憶媒体（例えば、ＥＰＲＯＭ（登録商標）、ＥＥＰＲＯＭ（登録商標）、フラッシュメモリ、ハードドライブ等のような、１つ以上の不揮発性メモリエレメント）も含んでいてもよい。
・近くのピアＳＴＡの位置およびアイデンティティとともに、このようなピアＳＴＡが、（例えば、デバイス発見動作の間に交換した管理フレームからパースされた情報を使用して）提供するかもしれない何らかのＰ２Ｐサービスについての情報を決定するＰ２Ｐデバイス発見ソフトウェアモジュール２４６。
・発見されたピアＳＴＡのそれぞれに対して、そのＳＴＡによって提供および／または要求される１つ以上のサービスが、ＳＴＡ２００によって提供および／または要求される１つ以上のサービスと一致するか否かを、決定または確認するＰ２Ｐサービス発見ソフトウェアモジュール２４８。
各ソフトウェアモジュールは、プロセッサ２３０によって実行されるとき、対応する機能をＳＴＡ２００に実行させる命令を含んでいる。よって、メモリ２４０の一時的でないコンピュータ読取可能な記憶媒体は、図３、４および７に関して説明した動作のすべてまたは一部分を実行するための命令を含んでいてもよい。

【0020】

［００３１］
スキャナ２１０とトランシーバ２２０とメモリ２４０とに結合されているプロセッサ２３０は、ＳＴＡ２００において（例えば、メモリ２４０内で）記憶されている１つ以上のソフトウェアプログラムの命令のスクリプトを実行する能力がある何らか適切なプロセッサであってもよい。例えば、プロセッサ２３０は、デバイス発見ソフトウェアモジュール２４６を、および／または、サービス発見ソフトウェアモジュール２４８を実行してもよい。デバイス発見ソフトウェアモジュール２４６は、プロセッサ２３０によって実行されて、他の近くのＳＴＡを発見するとともに、近くのＳＴＡが提供するかもしれないサービスについての情報を取得してもよい。一例として、プロセッサ２３０によって実行されるデバイス発見ソフトウェアモジュール２４６は、上述したように、１つ以上のサービスクエリストリングに対応するハッシュ値のリストを含んでいるＰ＿Ｒｅｑフレームを発生させてもよく、および／または、１つ以上のサービスクエリストリングに対応するハッシュ値のリストを含んでいるＰ＿Ｒｅｓｐフレームを発生させてもよい。別の例として、（例えば、図６Ａ、図６Ｂおよび図７を参照して以下に議論するように）プロセッサ２３０によって実行されるデバイス発見ソフトウェアモジュール２４６は、Ｐ＿Ｒｅｑフレームを発生させてもよく、および／または、グループオーナーによってブロードキャストされるビーコンフレームを聞いてもよい。Ｐ＿Ｒｅｑフレームは、ＳＴＡ２００の１つ以上の通信能力を識別する管理情報を含んでいてもよい。

【0021】

［００３２］
プロセッサ２３０によって実行されるデバイス発見モジュール２４６は、管理情報と、サービス情報（ＳＩ）データとに対する受信したＰ＿Ｒｅｓｐフレームをパースし、それに応じて、ＳＴＡテーブル２４２を更新してもよい。例えば、デバイス発見ソフトウェアモジュール２４６を実行する際に、プロセッサ２３０は、（例えば、Ｐ＿Ｒｅｓｐフレームに関係付けられているＭＡＣアドレスに基づいて）ピアＳＴＡが、ＳＴＡ２００によって以前に発見されたか否かを決定してもよい。このようなＭＡＣアドレスが、ＳＴＡテーブル２４２中に存在しない場合、新たに発見したＳＴＡに対して、プロセッサ２３０は、ＳＴＡテーブル中に新たなエントリを生成させてもよく、適切なフィールドにおいて、管理情報とＳＩデータを記録してもよい。そうでなければ、プロセッサ２３０は、以前に発見したピアＳＴＡに対して、ＳＴＡテーブル２４２中の情報を単に更新してもよい。

【0022】

［００３３］
例えば、ＳＴＡ２００が別のＳＴＡからプローブ要求を受信したとき、プロセッサ２３０によって実行されるデバイス発見ソフトウェアモジュール２４６は、Ｐ＿Ｒｅｑフレーム中に含まれている管理情報をパースして、プローブ要求において特定された通信の１つ以上のタイプをＳＴＡ２００がサポートするか否かを決定してもよい。ＳＴＡ２００が、要求するＳＴＡとの接続を確立する能力がある場合、プロセッサ２３０によって実行されるデバイス発見ソフトウェアモジュール２４６は、要求するデバイスに返信するＰ＿Ｒｅｓｐフレームを発生させてもよい。Ｐ＿Ｒｅｓｐフレームは、（例えば、サービス情報テーブル２４４から取得した）管理情報とＳＩデータの両方を含んでいてもよい。例えば、１つ以上のＰ＿Ｒｅｓｐフレームのフレームボディにおいて提供される情報エレメントにＳＩデータを追加してもよい。

【0023】

［００３４］
いくつかの実施形態に対して、デバイス発見ソフトウェアモジュール２４６は、（例えば、サービス情報テーブル２４４から取得した）ＳＩデータを、Ｐ＿Ｒｅｑフレームおよび／またはＰ＿Ｒｅｓｐフレーム中にエンコードしてもよい。デバイス発見フェーズの間、これは、すべての発見可能なＳＴＡがＳＩデータを交換するのを可能にし、および／または、すべての発見可能なＳＴＡの対応するＳＴＡテーブルを更新するのを可能にする。上述したように、これは、サービス発見動作を開始する前に、発見したピアＳＴＡのそれぞれによって、どのサービスがサポートされているかを、要求するＳＴＡが決定するのを可能にする。これは、次に、要求するＳＴＡによって要求される１つ以上のサービスをサポートするこれらのピアＳＴＡのみとともに、要求するＳＴＡが、サービス発見動作を選択的に開始するのを可能にする。いくつかの実施形態に対して、デバイス発見ソフトウェアモジュール２４６は、ＳＴＡ２００によって送信される、ビーコンフレームおよび／またはＰ＿Ｒｅｓｐフレーム中にグループサービス情報（ＧＳＩ）データをエンコードしてもよい。図６Ａ、図６Ｂおよび図７を参照して、以下に議論するように、ＧＳＩデータは、Ｐ２Ｐグループの複数のメンバーに対するＰ２Ｐサービス能力をアドバタイズしてもよく、サービス情報テーブル２４４から取得してもよい。

【0024】

［００３５］
サービス発見ソフトウェアモジュール２４８は、プロセッサ２３０によって実行されて、もしあれば、どの発見したピアＳＴＡが特定のサービスを提供するように構成されているかを決定または確認してもよい。例えば、プロセッサ２３０によって実行されるサービス発見ソフトウェアモジュール２４８は、ＳＴＡテーブル２４２のサービスフィールド中に記憶されているサービス情報に基づいて、１つ以上のそれぞれのピアＳＴＡに送信される１つ以上のＳＤ＿Ｒｅｑフレームを、選択的に発生させてもよい。さらに特に、（例えば、いかなるＰ２Ｐサービスも提供しないピアＳＴＡに対しては、ＳＤ＿Ｒｅｑフレームを発生させないように）あるサービス基準に一致するピアＳＴＡに対してだけに、ＳＤ＿Ｒｅｑフレームを発生させてもよい。スキャナ２１０および／またはトランシーバ２２０を使用して、ＳＤ＿Ｒｅｑフレームを、意図するピアＳＴＡに送信するとともに、このようなＳＴＡからの対応するＳＤ＿Ｒｅｓｐフレームを聞いてもよい。プロセッサ２３０によって実行されるサービス発見モジュール２４８は、その後、詳細なサービス情報に対する受信したＳＤ＿Ｒｅｓｐフレームをパースして、もしあれば、どのピアＳＴＡが特定のＰ２Ｐサービスを提供する能力があるかを決定または確認してもよく、その後、これに応じて、ＳＴＡテーブル２４２を更新してもよい。

【0025】

［００３６］
ＳＴＡ２００が、別のＳＴＡからサービス発見要求を受信したとき、プロセッサ２３０によって実行されるサービス発見ソフトウェアモジュール２４８は、受信したＳＤ＿Ｒｅｑフレームを解析して、サービス発見要求とともに提供される１つ以上のサービス関連問い合わせに応答するＳＤ＿Ｒｅｓｐフレームを発生させてもよい。例えば、各ＳＤ＿Ｒｅｑフレームは、ＳＴＡ２００によって提供されるサービスについての、さらに詳細な情報に対する問い合わせを含んでいてもよく、および／または、特定のＰ２Ｐサービスに対する要求を含んでいてもよい。プロセッサ２３０によって実行されるサービス発見ソフトウェアモジュール２４８は、よって、（例えば、サービス情報テーブル２４４から取得した情報に基づいて、）ＳＴＡ２００によってサポートされているサービスの詳細なリストを、および／または、ＳＴＡ２００が特定のＰ２Ｐサービスを提供する能力があるか否かに関する確認を、ＳＤ＿Ｒｅｓｐフレーム中にエンコードしてもよい。

【0026】

［００３７］
いくつかの実施形態に対して、ＳＤ＿Ｒｅｑフレームは、１つ以上のサービスクエリストリングを含んでいてもよい。このようなＳＤ＿Ｒｅｑフレームを受信する各ピアデバイスは、その中に含まれている１つ以上のサービスクエリストリングを解析して、サービスクエリストリングによって示されている要求されるサービス（または同等なサービス）を、ピアデバイスが提供するか否かを決定してもよい。ピアデバイスが、要求されるサービスを提供する場合、その後、ピアデバイスは、１つ以上の要求されるサービスの利用可能性を確認する１つ以上のサービス応答ストリングを発生させて、送信するかもしれない。逆に言えば、ピアデバイスが、要求されるサービスを提供しない場合、その後、ピアデバイスは、何らサービス応答ストリングを送信しなくてもよい。各ピアデバイスは、対応するサービス応答ストリングを有する、サポートされているサービスクエリストリングのリストを記憶しているかもしれないので、特定のピアデバイス内に記憶されている、サポートされているサービスクエリストリングのリストは、特定のピアデバイスが、サポートされているサービスのうちの１つ以上を提供するか否かを示してもよい。

【0027】

［００３８］
図３は、いくつかの実施形態にしたがった、プレアソシエーション発見動作３００を図示している、実例となるフローチャートである。上記で説明したように、本実施形態は、デバイス発見動作の間に、ＳＴＡがサービス情報を交換できるようにし、よって、サービス発見動作の間に、クライアントＳＴＡによってなされる詳細なサービス問い合わせの数を減少させる（そして、潜在的に取り除く）。図１Ａおよび図１Ｂも参照すると、動作３００において、クライアント１０１は、Ｐ２Ｐネットワークをスキャンすることによって、デバイス発見動作を開始して、ピアＳＴＡ（３１０）を発見する。例えば、ビーコンフレームを聞くことによって、および／または、プローブ要求をブロードキャストして、プローブ応答を聞くことによって、クライアントＳＴＡ１０１は、ネットワークをスキャンしてもよい。

【0028】

［００３９］
クライアントＳＴＡ１０１は、発見可能なピアＳＴＡ１０２〜１０４から、管理情報とＳＩデータとを伝えるデータフレームを受信する（３２０）。いくつかの実施形態に対して、ＳＩデータは、ピアＳＴＡ１０２〜１０４のそれぞれのＰ２Ｐサービス能力を識別する。例えば、ビーコンフレーム中や、プローブ応答フレーム中や、ならびに／あるいは、近くのピアデバイスを識別および／または位置付けるのに使用されるかもしれない情報を伝える、他の何らかのタイプのデータフレーム中に、ＳＩデータをエンコードしてもよい。

【0029】

［００４０］
その後、クライアントＳＴＡ１０１は、ＳＩデータを使用して、ピアＳＴＡ１０２〜１０４のうちの選択した１つ（またはそれ以上）とのＰ２Ｐ接続を確立してもよい（３３０）。例えば、ＳＩデータは、（ｉ）ピアＳＴＡがＰ２Ｐサービスを提供するか否かを、（ｉｉ）ＳＴＡによって提供されるＰ２Ｐサービスに対する更新および／または変更を、（ｉｉｉ）ＳＴＡによってサポートされているサービスのタイプを、（ｉｖ）ＳＴＡが提供するように構成されているサービスの詳細なリストを、および／または、（ｖ）ＳＴＡが、ＳＴＡ１０１によって要求される特定のサービスを提供するか否かを、示している情報を含んでいてもよい。よって、いくつかの実施形態に対して、クライアントＳＴＡ１０１は、ＳＩデータを使用して、後続するサービス発見動作を実行するピアＳＴＡの選択を狭めるかもしれない。他の実施形態において、クライアント１０１は、ＳＩデータを使用して、もしあれば、ピアＳＴＡ１０２〜１０４のうちのどれと接続を確立するかを、直接決定してもよい（よって、サービス発見フェーズをまったくなしで済ませる）。

【0030】

［００４１］
さらに、いくつかの実施形態に対して、（例えば、ハッシュされているか否かにかかわらず）サポートされているサービスクエリストリングのリストを、サービスクエリストリングと比較することによって、クライアント１０１は、ピアＳＴＡ１０２〜１０４のうちのいずれかが所望のサービスを提供するか否かを決定してもよい。例えば、クライアントＳＴＡ１０１は、そのサービスクエリストリングに対するハッシュ値を発生させてもよく、その後、ピアＳＴＡ１０２〜１０４によって提供されているＳＩデータ中に含まれている、ハッシュされたサポートされているサービスクエリストリングのリスト中に、一致するハッシュ値があるか否かを決定してもよい。

【0031】

［００４２］
図４は、プレアソシエーション発見動作４００のさらに詳細な実施形態を図示している、実例となるフローチャートである。図１Ａおよび図１Ｂも参照すると、動作４００において、クライアントＳＴＡ１０１は、ピアＳＴＡ１０２〜１０４にプローブ要求（Ｐ＿Ｒｅｑ）をブロードキャストする（４１０）。上述したように、Ｐ＿Ｒｅｑフレームは、どのサービスがクライアントＳＴＡ１０１によって提供されるかを示す１つ以上のサービスクエリストリングに対応するハッシュ値のリストを含んでいてもよい。ピアＳＴＡ１０２〜１０４は、クライアントＳＴＡ１０１にプローブ応答（Ｐ＿Ｒｅｓｐ）を送信することによって、プローブ要求に応答する。上述したように、Ｐ＿Ｒｅｓｐフレームは、どのサービスがピアＳＴＡ１０２〜１０４によってサポートされるかを示す１つ以上のサービスクエリストリングに対応する、ハッシュ値のリストを含んでいてもよい。

【0032】

［００４３］
特に、ピアＳＴＡ１０２〜１０４のそれぞれは、クライアントＳＴＡ１０１に送信される各Ｐ＿Ｒｅｓｐフレーム内に、管理情報とＳＩデータのセットとをエンコードしてもよい。ＳＩデータは、もしあれば、ピアＳＴＡ１０２〜１０４のそれぞれが提供するように構成されているＰ２Ｐサービスについての情報を含む。ＳＩデータの例は、（ｉ）ピアＳＴＡがＰ２Ｐサービスを提供するか否かを、（ｉｉ）ＳＴＡによって提供されるＰ２Ｐサービスに対する更新および／または変更を、および／または、（ｉｉｉ）ＳＴＡによってサポートされているサービスのタイプを、示している情報を含んでいてもよい。１つ以上のサービスクエリストリングに対応しているハッシュ値の先述のリストとして、Ｐ＿Ｒｅｓｐフレーム中に含まれているＳＩデータをエンコードしてもよい。いくつかの実施形態に対して、Ｐ＿Ｒｅｑフレームは、（例えば、図２を参照して上記で説明したように）クライアントＳＴＡ１０１の１つ以上のＰ２Ｐサービス能力を識別するＳＩデータによりエンコードしてもよい。１つ以上のサービスクエリストリングに対応するハッシュ値の先述のリストとして、Ｐ＿Ｒｅｑフレーム中に含まれているＳＩデータをエンコードしてもよい。

【0033】

［００４４］
クライアントＳＴＡ１０１は、ピアＳＴＡ１０２〜１０４によって送信されるＰ＿Ｒｅｓｐフレームを受信し、対応するピアに関するＳＩデータに対して、各Ｐ＿Ｒｅｓｐフレームをパースする（４２０）。クライアントＳＴＡ１０１は、その後、Ｐ＿Ｒｅｓｐフレームに含まれるＳＩデータを解析して、もしあれば、ピアＳＴＡ１０２〜１０４のうちのどれに追加的なサービス情報について問い合わせるかを決定してもよい（４３０）。図１Ａおよび図１Ｂ中に示されている例において、ピアＳＴＡ１０３は、クライアントＳＴＡ１０１に対する潜在的な候補サービスプロバイダであるが、ＳＴＡ１０２とＳＴＡ１０４は、そうではない。

【0034】

［００４５］
いくつかの実施形態に対して、クライアントＳＴＡ１０１はＳＩデータを解析して、もしあれば、ピアＳＴＡ１０２〜１０４のうちのどれがＰ２Ｐサービスを提供するように構成されているか決定する（４４０）。例えば、いくつかのＳＴＡは、他のピアＳＴＡとのＰ２Ｐ通信の能力はあるが、Ｐ２Ｐサービス（例えば、ＵＰｎＰ、ボンジュール、Ｗｉ−Ｆｉディスプレイ、プリント、ゲーム、および／または、ファイル共有サービス）をホスト管理または提供するように構成されていないかもしれない。よって、このようなピアＳＴＡが何らＰ２Ｐサービスを提供しないとき、後続のサービス発見動作の間に（例えば、ステップ４７０において）、特定のＰ２Ｐサービスについて、このようなピアＳＴＡに問い合わせることは議論の余地があるかもしれない。

【0035】

［００４６］
さらに、いくつかの実施形態に対して、クライアントＳＴＡ１０１は、ピアＳＴＡ１０２〜１０４のうちのいずれかが、サービス記録を更新したか否かを決定してもよい（４５０）。例えば、クライアントＳＴＡは、（例えば、図２のＳＴＡテーブル２４２中に記憶されているデータに基づいて）ピアで実行される、前の、アソシエーションおよび／またはデバイス発見動作が原因で、ピアＳＴＡによって提供される１つ以上のＰ２Ｐサービスの知識を既に有しているかもしれない。よって、これらのサービスが変化しない限り、（例えば、ステップ４７０において）特定のＰ２Ｐサービスについて、このようなピアに再度問い合わせることは議論の余地があるかもしれない。

【0036】

［００４７］
さらに、いくつかの実施形態に対して、クライアントＳＴＡ１０１は、ピアＳＴＡ１０２〜１０４のうちのいずれかが、クライアントＳＴＡ１０１によって提供されるサービスに一致するサービスのタイプを提供するか否かを決定してもよい（４６０）。例えば、プリントサービスを要求するクライアントＳＴＡは、ゲームサービスのみを提供するピアＳＴＡとの接続を確立することに関心がないかもしれない。よって、このようなピアＳＴＡが所望のタイプの何らかのサービスを提供しない場合、（例えば、ステップ４７０において）特定のＰ２Ｐサービスについて、ピアＳＴＡに問い合わせることは議論の余地があるかもしれない。

【0037】

［００４８］
さらに、いくつかの実施形態に対して、クライアントＳＴＡ１０１は、各ピアＳＴＡに対して、何らかの一致する、サポートされているサービスクエリストリング、および／または、対応するハッシュエントリがあるか否かを決定してもよい（４６５）。一致する、サポートされているサービスクエリストリングおよび／または対応するハッシュエントリがある場合、その後、４７０で処理が続く。そうでなければ、処理は４３０に戻る。

【0038】

［００４９］
したがって、ピアＳＴＡ１０２〜１０４のうちの１つ（例えば、ＳＴＡ１０３）が、Ｐ２Ｐサービスを提供する能力があることをクライアントＳＴＡ１０１が決定するまで、および／または、（例えば、ピアＳＴＡ１０２〜１０４のそれぞれから）受信したＳＩデータのすべてを解析することを終えるまで、クライアントＳＴＡ１０１は、ピアＳＴＡ１０２〜１０４のそれぞれから受信したＳＩデータを解析してもよい（４３０と４４０、および、オプション的に、４５０、４６０および／または４６５）。この方法において、クライアントＳＴＡ１０１は、後続するサービス発見動作を開始する潜在的な候補のリストを狭めるかもしれない。特に、クライアントＳＴＡ１０１は、選択したピアが、クライアントＳＴＡ１０１に対して有用なサービスまたは関連のあるサービスを提供できるだろう可能性に基づいて、サービス発見動作を実行するピアＳＴＡ１０２〜１０４のうちの１つ以上を選択してもよい。

【0039】

［００５０］
クライアントＳＴＡ１０１は、その後、選択したピアＳＴＡのそれぞれに問い合わせて、それらが特定のサービスを提供するか否かを決定または確認する（４７０）。例えば、ドキュメントをプリントすることを望んでいるクライアントＳＴＡ１０１は、ピアＳＴＡ１０３がプリントサービスを提供することを決定または確認してもよい。クライアントＳＴＡ１０１は、その後、プリントすることを意図しているドキュメントのために使用する特定のプリントサービスを要求するＳＤ＿ＲｅｑフレームをピアＳＴＡ１０３に送信してもよい。クライアント１０１によって要求される特定のプリントサービスを、ピアＳＴＡ１０３がサポートするか否かを示しているＳＤ＿ＲｅｓｐフレームをクライアントＳＴＡ１０１に送信することによって、ピアＳＴＡ１０３は応答してもよい。さらに、ＳＤ＿Ｒｅｓｐフレームは、ピアＳＴＡ１０３がサポートするように構成されているサービスのすべての詳細なリストも含んでいてもよい。

【0040】

［００５１］
要求されるサービスをピアＳＴＡ１０３がサポートすることをＳＤ＿Ｒｅｓｐフレームが示している場合、クライアントＳＴＡ１０１は、その後、（例えば、Ｐ＿Ｒｅｓｐフレーム内で）先に提供された管理情報を使用して、ピアＳＴＡ１０３とのＰ２Ｐ接続を確立してもよい。いくつかのケースにおいて、クライアントＳＴＡ１０１は、要求されるサービスを複数のピアＳＴＡが提供できることを決定してもよい。よって、いくつかの実施形態に対して、クライアント１０１は、もしあれば、接続を確立するために、一致するピアＳＴＡのうちのどれを選択するかのオプションを、ユーザに提供してもよい。

【0041】

［００５２］
図５は、いくつかの実施形態にしたがった、管理フレーム５００のブロックダイヤグラムを示している。管理フレーム５００は、プローブ応答や、プローブ要求や、ビーコンや、および／または、Ｐ２Ｐデバイス発見動作の間に、ピアＳＴＡ間で交換されるかもしれない他の何らかのタイプのデータフレーム（例えば、制御フレームまたは管理フレーム）に対応していてもよい。管理フレーム５００は、フレームボディ５１０とフレームチェックシーケンス（ＦＣＳ）５０８とが続くＭＡＣヘッダ５０１を含んでいる。ＭＡＣヘッダ５０１は、宛先ＭＡＣアドレスと発信元ＭＡＣアドレスの両方を含んでいてもよい。例えば、各ＳＴＡは、デバイスの製造者によってその中にプログラムされている一意的なＭＡＣアドレスが割り当てられている。よって、個々のデバイスを一意的に識別するのに各ＭＡＣアドレスを使用してもよい。ＦＣＳ５０８は、チェックサムまたはエラー検出のために使用する他の適切な技術であってもよい。

【0042】

［００５３］
フレームボディ５１０は、管理情報５０２と、サービス発見（ＳＤ）ビット５０３と、ＳＩデータ５２０とを含んでいる。上記で議論したように、管理情報５０２は、管理フレーム５００を発信したＳＴＡを位置付けて、管理フレーム５００を発信したＳＴＡとの接続を確立するのに使用するかもしれない何らかの情報を含んでいてもよい（例えば、このような情報は、受信機ＭＡＣアドレスおよび／またはサポートされているデータレートを含んでいてもよい）。ＳＤビット５０３は、発信するＳＴＡがサービス発見動作に参加する能力があるか否か（例えば、ＳＴＡがＳＤ＿Ｒｅｑフレームを送信および／またはＳＤ＿Ｒｅｑフレームに応答できるか否か）を示す。例えば、ＳＤビット５０３のアクティブ化は、ＳＴＡがサービス発見動作を実行できることを示してもよい。しかしながら、ＳＤビット５０３は、ＳＴＡが実際に、提供するＰ２Ｐサービスを有しているか否かを示さないことに留意すべきである。

【0043】

［００５４］
ＳＩデータ５２０は、サービス情報利用可能（ＳＩＡ）ビット５０４と、サービス更新インジケータ（ＳＵＩ）フィールド５０５と、サービスタイプフィールド５０６とを含んでいる。少なくともいくつかの実施形態に対して、対応するデバイスによって提供される異なるサービスタイプのすべてを示している、ハッシュされた情報を、またはそうでなければ、圧縮された情報を、記憶させるための、ハッシュされたサポートされているサービスクエリ（ＳＳＱ）ストリングフィールド５０７も、ＳＩデータ５２０は含んでいてもよい。ＳＩＡビット５０４は、発信するＳＴＡが、１つ以上のＰ２Ｐサービスを提供するように構成されているか否かを示す。例えば、ＳＩＡビット５０４のアクティブ化は、ＳＴＡがＰ２Ｐサービスを提供する能力があることを示していてもよい。上記で着目したように、ＳＤビット５０３は、単に、ＳＴＡがサービス発見動作を実行できるか否かを示しているに過ぎない。よって、同一の管理フレーム５００のＳＩＡビット５０４が非アクティブ化されている間、ＳＤビット５０３をアクティブ化してもよい。

【0044】

［００５５］
ＳＵＩフィールド５０５は、発信するＳＴＡのサービスが変化するたびに、インクリメントされる数値を記憶してもよい。例えば、プリントサービスを提供するＳＴＡは、より後にゲームサービスを提供し始める場合、そのＳＵＩフィールド５０５中に記憶されている値をインクリメントしてもよい。その後、発信するＳＴＡが異なる種類のゲームサービスを提供し始めた場合、ＳＵＩフィールド５０５中に記憶されている値を、再度インクリメントしてもよい。上記の実施形態において説明したように、ピアＳＴＡはＳＵＩフィールド５０５中に記憶されている値における変化を探して、ピアＳＴＡが、発信するＳＴＡとの別のサービス発見問い合わせを実行すべきか否かを決定してもよい。

【0045】

［００５６］
サービスタイプフィールド５０６は、発信するＳＴＡが提供する能力があるＰ２Ｐサービスのタイプのリストを含んでいてもよい。例えば、ＳＴＡが複数のＰ２Ｐサービスをサポートしている場合、サービスタイプフィールド５０６は、サポートされている異なるタイプのＰ２Ｐサービス（例えば、ＵＰｎＰ、ボンジュール、Ｗｉ−Ｆｉディスプレイ、プリント、ゲーム、ファイル共有等）のすべてを特定してもよい。上記の実施形態において説明したように、ＳＴＡは、所望のタイプのＰ２Ｐサービスを提供しない潜在的な候補を、フィルタアウトしてもよい。

【0046】

［００５７］
さらに、フレームボディ５１０のサイズ制限内に、異なるサービスタイプのすべてをエンコードするために、サービスタイプフィールド５０６は、ハッシュするか、または、圧縮してもよい。例示的なエンコードアルゴリズムは、サービスプロトコルタイプのアレイまたはビットマップを含んでいてもよい。
・ＳＴＡによって使用されるプロトコルタイプの数値が、８（または１６）よりも小さい場合、１オクテット（または２オクテット）ビットマップを使用して、プロトコルタイプを記述してもよい。
・プロトコルタイプが、８（または１６）よりも大きい数値を有している場合、プロトコルタイプのアレイを使用して、プロトコルタイプを記述してもよい。

【0047】

［００５８］
さらに特に、少なくとも１つの実施形態に対して、ハッシュされたＳＳＱストリングフィールド５０７は、以下のエンコードアルゴリズムのうちの１つ以上を用いてもよい。
・ＳＩデータ５２０中の、サポートされているサービスクエリストリングの数が、しきい値よりも小さい（例えば、８よりも小さい）場合、各クエリストリングに対するハッシュ値のアレイを生成させてもよい。例えば、クエリストリング中のすべてのオクテットに対してＸＯＲ動作を使用して、各クエリストリングに対するハッシュ値を生成させてもよい。
・クエリサービスが「トランザクション的」である（例えば、第１のクエリストリングが固定されて、所望のトランザクションを記述している可変ストリングが続く）場合、クエリストリングの第１の部分（すなわち、静的で、切り捨てられる部分）のみをハッシュする。例えば、２つのフィールド：ハッシュを計算するのに使用するクエリの長さと、所定の長さに切り捨てられるクエリストリングのハッシュとを有するエントリを、対応するアレイは有していてもよい。

【0048】

［００５９］
先述の圧縮アルゴリズムは、例示的な目的のためだけに提供されており、上述した実施形態のいずれかを実現するのに必要でないかもしれないことに留意されたい。

【0049】

［００６０］
管理フレーム５００のフレームボディ５１０中に（例えば、１つ以上の情報エレメントとして）ＳＩデータ５２０をエンコードすることによって、既存のＰ２Ｐ Ｗｉ−Ｆｉシステムのアーキテクチャに対してわずかな修正で、本実施形態は実現されるかもしれない。特に、サービス情報の交換を容易にするための、プローブ要求、プローブ応答、および／または、ビーコンフレームの使用は、８０２．１１標準規格から逸脱することなく、本実施形態を実現できるようにする。

【0050】

［００６１］
図６Ａおよび図６Ｂは、本実施形態が実現されるかもしれない、別のＰ２Ｐ Ｗｉ−Ｆｉシステム６００を図示している。システム６００は、ピアＳＴＡ１０２〜１０４を含むＰ２Ｐグループ６１０のＷｉ−Ｆｉ通信範囲内に位置するクライアントＳＴＡ１０１を含むように示されている。ピアＳＴＡ１０３とピアＳＴＡ１０４は、ピアＳＴＡ１０２（すなわち、「グループオーナー」）を介して、Ｐ２Ｐグループ６１０に接続されている。特に、これを通して他のピアＳＴＡ１０３とピアＳＴＡ１０４が通信するかもしれないアクセスポイントとして、グループオーナーＳＴＡ１０２は機能する。簡潔さのために、Ｐ２Ｐグループ６１０は、３つのピアＳＴＡ１０２〜１０４のみを含むように示されているが、Ｐ２Ｐグループ６１０は、任意の数のＳＴＡを含んでいてもよいことを理解すべきである。

【0051】

［００６２］
グループオーナーとして、ピアＳＴＡ１０２は、アクセスポイントが実行する機能のうちの多くを実行してもよい。例えば、図６Ａにおいて示しているように、ＳＴＡ１０２は、タイミング同期化目的のために、規則的な間隔で、グループセッション情報（ＧＳＩ）を含んでいるビーコンフレームをブロードキャストしてもよい。ビーコンフレームは、動作パラメータと、サポートされている能力と、および／または、Ｐ２Ｐグループ６１０内のメンバーシップとをアドバタイズしてもよい。さらに、Ｐ２Ｐグループ６１０のメンバーとして、ピアＳＴＡ１０３および１０４は、クライアントＳＴＡ１０１によってブロードキャストされるプローブ要求に対して、直接応答しない。むしろ、図６Ｂにおいて示しているように、グループオーナーＳＴＡ１０２が、Ｐ２Ｐグループ６１０を代表して、プローブ要求に応答する。

【0052】

［００６３］
クライアントＳＴＡ１０１は、よって、グループオーナーＳＴＡ１０２によってブロードキャストされるビーコンフレームを聞くことによって、および／または、グループオーナーＳＴＡ１０２にＰ＿Ｒｅｑフレームを送信して、Ｐ＿Ｒｅｓｐフレームを聞くことによって、デバイス発見動作を開始してもよい。Ｐ２Ｐグループ６１０に加わるために、および／または、Ｐ２Ｐグループ６１０の個々のメンバーＳＴＡ１０２〜１０４とのＰ２Ｐ接続を確立するために、ビーコンとＰ＿Ｒｅｓｐフレームの両方は、クライアントＳＴＡ１０１によって使用されるかもしれない管理情報を含んでいてもよい。言い換えると、クライアントＳＴＡ１０１は、グループオーナーＳＴＡ１０２から受信した単一の通信に基づいて、ピアＳＴＡ１０２〜１０４のすべてを発見してもよい。

【0053】

［００６４］
上述したように、Ｐ＿Ｒｅｑフレームおよび／またはビーコンフレームは、どのサービスがクライアントＳＴＡ１０１によって提供されているかを示している、１つ以上のサービスクエリストリングに対応しているハッシュ値のリストを含んでいてもよく、Ｐ＿Ｒｅｓｐフレームは、どのサービスがピアＳＴＡ１０２および１０３のうちの対応する１つによってサポートされているかを示している、１つ以上のサービスクエリストリングに対応しているハッシュ値のリストを含んでいてもよい。この方法において、サービス発見動作を開始する前に、クライアントＳＴＡ１０１は、どのサービスがピアＳＴＡ１０２〜１０４のそれぞれによってサポートされているかを決定してもよい。

【0054】

［００６５］
クライアントＳＴＡ１０１は、ビーコンおよび／またはＰ＿Ｒｅｓｐフレームを解析して、ピアＳＴＡ１０２〜１０４を位置付けして識別し、その後、ピアＳＴＡ１０２〜１０４のうちの１つ以上とともに、サービス発見動作を開始してもよい。例えば、クライアントＳＴＡ１０１は、その後、ＳＤ＿Ｒｅｑフレームを、ピアＳＴＡ１０２〜１０４のうちの１つ以上に送って、対応しているピアＳＴＡによってサポートされている特定のサービスを確認してもよい。ピアＳＴＡ１０２〜１０４のそれぞれは、もしあれば、ＳＤ＿ＲｅｓｐフレームをクライアントＳＴＡ１０１に返信することによって、受信したＳＤ＿Ｒｅｑフレームに応答する。クライアントＳＴＡ１０１は、その後、ＳＤ＿Ｒｅｓｐフレームのそれぞれを解析して、クライアントＳＴＡ１０１が要求している特定のサービスを対応するピアＳＴＡが提供できるか否かを確認してもよい。この方法において、いったんクライアントＳＴＡ１０１がＰ２Ｐグループ６１０のメンバー（例えば、ピアＳＴＡ１０２〜１０４）を発見したら、クライアントＳＴＡ１０１は、Ｐ２Ｐグループ６１０のメンバーのうちのいずれかと、Ｐ２Ｐプロトコルを使用して通信してもよい。

【0055】

［００６６］
ピアＳＴＡ１０２〜１０４のうちの１つが、要求されるサービスを提供するとクライアントＳＴＡ１０１が決定した場合、クライアントＳＴＡ１０１は、その後、Ｐ＿Ｒｅｓｐフレームおよび／またはビーコンフレームにおいて提供される管理情報を使用して、そのピアＳＴＡとのＰ２Ｐ接続を確立してもよい。代替的に、クライアントＳＴＡ１０１は、管理情報を使用して、Ｐ２Ｐグループ６１０に加わってもよい。Ｐ２Ｐグループ６１０のメンバーとして、クライアントＳＴＡ１０１は、他のメンバー（例えば、ピアＳＴＡ１０２〜１０４）のうちのいずれかによって提供されるサービスを使用してもよい。

【0056】

［００６７］
図７は、いくつかの実施形態にしたがった、別のプレアソシエーション発見動作７００を図示している例示的なフローチャートである。図６Ａおよび図６Ｂも参照すると、動作７００において、クライアントＳＴＡ１０１は、ピアＳＴＡを発見するために、Ｐ２Ｐネットワークチャネルをスキャンすることによって、デバイス発見動作を開始する（７１０）。例えば、図６Ａにおいて示されているように、ビーコンフレームを聞くことによって、および／または、図６Ｂにおいて示されているように、プローブ要求をブロードキャストしてプローブ応答を聞くことによって、クライアントＳＴＡ１０１は、ネットワークをスキャンしてもよい。

【0057】

［００６８］
その後、クライアントＳＴＡ１０１は、Ｐ２Ｐグループ６１０のグループオーナーＳＴＡ１０２から管理フレームを受信する（７２０）。特に、管理フレームは、管理情報とともに、Ｐ２Ｐグループ６１０のメンバーＳＴＡ１０２〜１０４のすべてに対するＰ２Ｐサービス能力を識別しているＧＳＩデータを含んでいてもよい。ＧＳＩデータの例は、（ｉ）グループメンバーがＰ２Ｐサービスを提供するか否かを、（ｉｉ）グループメンバーのうちの１人以上によって提供されるＰ２Ｐサービスに対する更新および／または変更を、および／または、（ｉｉｉ）各グループメンバーによってサポートされるサービスのタイプを、示している情報を含んでいてもよい。

【0058】

［００６９］
クライアントＳＴＡ１０１は、管理フレームに含まれるＧＳＩデータを解析して、もしあれば、ピアＳＴＡ１０２〜１０４のうちのどれに、追加的なサービス情報を問い合わせるかを決定してもよい（７３０）。例えば、クライアントＳＴＡ１０１は、グループメンバーＳＴＡ１０２〜１０４のそれぞれに対して、（ＧＳＩデータを使用して）図４において上記に概略した解析を実行してもよい。この方法において、クライアントＳＴＡ１０１は、サービス発見動作を開始する潜在的な候補のリストを狭めるかもしれない。特に、クライアント１０１は、選択したグループメンバーが、クライアントＳＴＡ１０１によって要求されるサービスを提供できるだろう可能性に基づいて、Ｐ２Ｐグループ６１０の１つ以上のメンバーＳＴＡ１０２〜１０４を選択してもよい。

【0059】

［００７０］
クライアントＳＴＡ１０１は、その後、Ｐ２Ｐグループ６１０に加わることを決めてもよく（７４０）、および／または、Ｐ２Ｐグループ６１０の１つ以上の選択したメンバーに直接問い合わせてもよい（７５０）。例えば、クライアントＳＴＡ１０１がＰ２Ｐグループ６０１に加わる場合、クライアントＳＴＡ１０１は、その後、グループ６１０の選択したメンバーに関する詳細なサービス情報について、グループオーナーＳＴＡ１０２に問い合わせてもよい。Ｐ２Ｐグループ６１０のメンバーが要求されるサービスを提供できることをクライアントＳＴＡ１０１が決定した場合、クライアントＳＴＡ１０１は、その後、そのメンバーと通信して、所望のサービスを実行してもよい。この方法において、ＳＴＡ間のすべての通信は、グループオーナーＳＴＡ１０２を通してルーティングされるだろう。

【0060】

［００７１］
代替的に、クライアントＳＴＡ１０１は、選択したグループメンバーのそれぞれに、直接、個々にＳＤ＿Ｒｅｑフレームを送信してもよい。選択したグループメンバーは、よって、要求される特定のサービスをグループメンバーがサポートするか否かを示しているＳＤ＿ＲｅｓｐフレームをクライアントＳＴＡ１０１に送信することによって応答する。さらに、各ＳＤ＿Ｒｅｓｐフレームは、対応するグループメンバーがサポートするように構成されているすべてのサービスの詳細なリストを含んでいてもよい。グループメンバーが要求されるサービスを提供できることをＳＤ＿Ｒｅｓｐが示している場合、クライアントＳＴＡ１０１は、グループオーナーＳＴＡ１０２から受信した管理情報を使用して、その特定のグループメンバーとの直接的なＰ２Ｐ接続を確立してもよい。

【0061】

［００７２］
図８は、本実施形態が実現されるＰ２Ｐ Ｗｉ−Ｆｉシステム８００の別の実施形態を図示している。システム８００は、ピアＳＴＡ８０２〜８０４のＷｉ−Ｆｉ通信範囲内に位置しているクライアントＳＴＡ８０１を含むように示されている。簡潔さのために、３つのピアＳＴＡ８０２〜８０４のみを図８において示しているが、Ｗｉ−Ｆｉシステム８００は、任意の数のピアＳＴＡを含んでいてもよいことを理解すべきである。ＳＴＡ８０１〜８０４は、Ｐ２Ｐ方法において、Ｗｉ−Ｆｉ媒体を通して互いに通信するように構成されている。しかしながら、図１Ａおよび図１ＢのＷｉ−Ｆｉシステム１００とは対照的に、システム８００は、別のサービス発見動作が続くデバイス発見動作を実行することなく、プレアソシエーションサービス発見動作を実行してもよい。特に、デバイス発見動作およびサービス発見操作を、単一の動作に組み合わせてもよい。例えば、管理フレーム（例えば、ビーコン、Ｐ＿Ｒｅｑおよび／またはＰ＿Ｒｅｓｐ）と、サービス発見フレーム（例えば、ＳＤ＿Ｒｅｑおよび／またはＳＤ＿Ｒｅｓｐ）とを交換することよりもむしろ、ＳＴＡ８０１〜８０４は、デバイスおよびサービス発見フレーム（例えば、ＤＳＤ＿Ｒｅｑおよび／またはＤＳＤ＿Ｒｅｓｐ）を使用して、管理情報と、サービス発見要求／応答との両方を交換してもよい。

【0062】

［００７３］
図９は、図８のＳＴＡ８０１〜８０４の１つの実施形態であるＳＴＡ９００を示している。ＳＴＡ９００は、スキャナ９１０と、送信機／受信機（すなわち「トランシーバ」）回路９２０と、プロセッサ９３０と、メモリ９４０とを含んでいる。例えば、周期的にＤＳＤ＿Ｒｅｑフレームをブロードキャストして、ＤＳＤ＿Ｒｅｓｐフレームを聞くことによって、周囲の環境をスキャンするのにスキャナ９１０を使用して、近くのピアＳＴＡを検出して識別してもよい。その後、トランシーバ回路９２０を使用して、発見したピアＳＴＡに信号を送信して、発見したピアＳＴＡから信号を受信してもよい。

【0063】

［００７４］
メモリ９４０は、複数のピアＳＴＡのＭＡＣアドレスと、このようなＳＴＡの位置座標と、ＳＴＡによってサポートされているＰ２Ｐサービスと、任意の発見したピアＳＴＡに関する他の適切な位置またはコンフィギュレーション情報とを記憶するローカルキャッシュとして使用できるＳＴＡテーブル９４２を含んでいてもよい。例えば、ＳＴＡテーブル９４２の各エントリは、関係付けられてＳＴＡのネームを記憶するピアデバイスフィールドと、ＳＴＡのＭＡＣアドレスを記憶するアドレスフィールドと、ＳＴＡの位置座標を記憶する座標フィールドと、ＳＴＡが提供するように構成されているかもしれない任意のＰ２Ｐサービスについての情報を記憶するサービスフィールドとを含んでいてもよい。メモリ９４０は、ＳＴＡ９００についてのサービス情報を記憶するのに使用できるサービス情報テーブル９４４も含んでいてもよい。例えば、サービス情報テーブル９４４は、ＳＴＡ９００がサポートするように構成されているサービスの詳細なリストを、ＳＴＡ９００によってサポートされている異なるサービスタイプのリストを、および／または、ＳＴＡ９００によって提供される１つ以上のサービスに対する更新または変更に関する情報を含んでいてもよい。

【0064】

［００７５］
さらに、メモリ９４０は、以下のソフトウェアモジュールを記憶しているかもしれない、一時的でないコンピュータ読取可能な記憶媒体も含んでいてもよい。
・近くのピアＳＴＡの位置を決定および識別して、もしあれば、どの隣接ピアＳＴＡが特定のサービスを提供する能力があるかを決定するＰ２Ｐデバイスおよびサービス発見ソフトウェアモジュール９４６。
ソフトウェアモジュールは、プロセッサ９３０によって実行されるとき、対応する機能をＳＴＡ９００に実行させる命令を含んでいる。よって、メモリ９４０の一時的でないコンピュータ読取可能な記憶媒体は、図１０に関して説明する動作のすべてまたは一部分を実行するための命令を含んでいてもよい。

【0065】

［００７６］
スキャナ９１０とトランシーバ９２０とメモリ９４０とに結合されているプロセッサ９３０は、ＳＴＡ９００中に記憶されている１つ以上のソフトウェアプログラムの命令のスクリプトを実行する能力がある、任意の適切なプロセッサであってもよい。例えば、プロセッサ９３０は、Ｐ２Ｐデバイスおよびサービス発見ソフトウェアモジュール９４６を実行して、他の近くのＳＴＡを発見して、ＳＴＡのうちのいずれかが、ＳＴＡ９００によって要求される特定のサービスを提供できるか否かを決定してもよい。特に、プロセッサ９３０によって実行されるデバイスおよびサービス発見ソフトウェアモジュール９４６は、スキャナ９１０および／またはトランシーバ９２０を介してブロードキャストされるＤＳＤ＿Ｒｅｑフレームを発生させてもよい。ＤＳＤ＿Ｒｅｑフレームは、ＳＴＡ９００の１つ以上の通信能力を識別する管理情報とともに、ＳＴＡ９００によって要求されている特定のサービスを特定するサービスクエリ（ＳＱ）データとを含んでいてもよい。スキャナ９１０は、その後、隣接ピアＳＴＡから返信されるＤＳＤ＿Ｒｅｓｐフレームを聞く。

【0066】

［００７７］
プロセッサ９３０によって実行されるデバイスおよびサービス発見モジュール９４６は、管理情報とともにサービス応答（ＳＲ）データに対して、受信したＤＳＤ＿Ｒｅｓｐフレームをパースして、それに応じて、ＳＴＡテーブル９４２を更新してもよい。いくつかの実施形態に対して、プロセッサ９３０は、単にピアＳＴＡからのＤＳＤ＿Ｒｅｓｐフレームの受信に基づいて、そのピアＳＴＡが、要求されるサービスを提供する能力があるか否かを決定してもよい。代替的に、プロセッサ９３０は、サービス発見モジュール９４６を実行する際に、ＤＳＤ＿Ｒｅｓｐフレームに含まれているＳＲデータを解析して、もしあれば、ピアＳＴＡのうちのどれが、要求されるＰ２Ｐサービスを提供できる能力があるかを決定してもよい。

【0067】

［００７８］
ＳＴＡ９００が、別のＳＴＡからＤＳＤ＿Ｒｅｑフレームを受信するとき、プロセッサ９３０によって実行されるデバイスおよびサービス発見ソフトウェアモジュール９４６は、ＤＳＤ＿Ｒｅｑフレーム中に含まれる管理情報をパースして、ＤＳＤ＿Ｒｅｑフレーム中で特定された通信の１つ以上のタイプを、ＳＴＡ９００がサポートするか否かを決定してもよい。さらに、プロセッサ９３０は、デバイスおよびサービス発見ソフトウェアモジュール９４６を実行する際に、ＤＳＤ＿ＲｅｑフレームからのＳＱデータをパースして、ＳＴＡ９００が要求されるサービスを提供できるか否かを決定してもよい。ＳＴＡ９００が、要求しているＳＴＡとの接続を確立する能力があり、要求されるサービスを提供する能力がある場合、プロセッサ９３０によって実行されるデバイスおよびサービス発見モジュール９４６は、（例えば、スキャナ９１０を介して）要求するデバイスに返信するＤＳＤ＿Ｒｅｓｐフレームを発生させてもよい。ＤＳＤ＿Ｒｅｓｐフレームは、サービス情報テーブル９４４から取得した管理情報およびＳＲデータの両方を含んでいてもよい。いくつかの実施形態に対して、ＳＴＡ９００が要求されるサービスをサポートしない場合、ＤＳＤ＿Ｒｅｓｐフレームは発生されず、および／または、送信されない。

【0068】

［００７９］
図１０は、他の実施形態にしたがった、プレアソシエーション発見動作１０００を図示している例示的なフローチャートである。上述したように、本実施形態は、ＳＴＡが、単一の動作において、管理情報とサービス発見データとを交換できるようにし、よって、プレアソシエーション発見動作の、デバイス発見フェーズとサービス発見フェーズとを組み合わせる。図８も参照すると、動作１０００において、Ｗｉ−Ｆｉ範囲内で、ＤＳＤ＿ＲｅｑフレームをピアＳＴＡにブロードキャストしてＤＳＤ＿Ｒｅｓｐフレームを聞くことによって、クライアントＳＴＡ８０１は、デバイスおよびサービス動作を開始する（１０１０）。各ＤＳＤ＿Ｒｅｑフレームは、管理情報およびＳＱデータを含んでいてもよく、特定のＰ２Ｐサービスに対する要求を含んでいる。

【0069】

［００８０］
いくつかの実施形態に対して、要求されるサービスをサポートできるピアＳＴＡ８０２〜８０４のみ（例えば、ＳＴＡ８０３）が、クライアントＳＴＡ８０１にＤＳＤ＿Ｒｅｓｐフレームを送る。各ＤＳＤ＿Ｒｅｓｐフレームは、管理情報とともに、対応するピアＳＴＡが提供するように構成されているＰ２Ｐサービスについての詳細な情報を含むＳＲデータを含んでいる。ＳＲデータの例は、（ｉ）対応するピアＳＴＡによって提供されるサービスの詳細なリストを、および／または、（ｉｉ）ピアＳＴＡが要求されるサービスを提供する能力があるか否かを、示している情報を含んでいてもよい。

【0070】

［００８１］
クライアントＳＴＡ８０１は、ピアＳＴＡ８０３によって送信されるＤＳＤ＿Ｒｅｓｐフレームを受信して、ピアＳＴＡ８０３に関する、管理情報とＳＲデータとのために、ＤＳＤ＿Ｒｅｓｐフレームをパースする（１０２０）。クライアントＳＴＡ８０１は、その後、ＤＳＤ＿Ｒｅｓｐフレームに含まれているＳＲデータを解析して、ピアＳＴＡ８０３によってサポートされている特定のサービスを決定してもよい。いくつかの実施形態に対して、（例えば、ピアＳＴＡ８０２〜８０４が特定の要求されるサービスを提供できるか否かに関わらず、ピアＳＴＡ８０２〜８０４が、クライアントＳＴＡ８０１にＤＳＤ＿Ｒｅｓｐフレームを送信するケースにおいて）クライアントＳＴＡ８０１は、ＳＲデータを解析して、もしあれば、どのピアＳＴＡが、要求されるサービスをサポートできるかを決定してもよい。

【0071】

［００８２］
最後に、クライアントＳＴＡ８０１は、ＤＳＤ＿Ｒｅｓｐフレームに含まれている管理情報を使用して、ピアＳＴＡ８０３とのＰ２Ｐ接続を確立してもよい（１０３０）。いくつかのケースにおいて、ピアＳＴＡ８０２〜８０４のうちの１つより多くが、要求されるサービスを提供する能力があるかもしれない。したがって、クライアントＳＴＡ８０１は、複数のＤＳＤ＿Ｒｅｓｐフレームを受信するかもしれず、各ＤＳＤ＿Ｒｅｓｐフレームは、要求されるサービスを提供できるそれぞれのピアＳＴＡを識別する。よって、いくつかの実施形態に対して、クライアントＳＴＡ８０１は、もしあれば、接続するために、どの一致するピアＳＴＡを選ぶかのオプションを、ユーザに提供してもよい。

【0072】

［００８３］
図１１は、いくつかの実施形態にしたがった、デバイスおよびサービス発見（ＤＳＤ）フレーム１１００のブロックダイヤグラムを示している。ＤＳＤフレーム１１００は、ＭＡＣヘッダ１１０１と、管理情報１１０２と、サービスクエリ（ＳＱ）データ１１０３と、ＦＣＳ１１０４とを含んでいる。ＭＡＣヘッダ１１０１は、宛先ＭＡＣアドレスと発信元ＭＡＣアドレスの両方を含んでいてもよい。ＦＣＳ１１０４は、チェックサムまたはエラー検出のために使用する他の適切な技術であってもよい。

【0073】

［００８４］
管理情報１１０２は、ＤＳＤフレーム１１００を発信したＳＴＡを位置付けて、ＤＳＤフレーム１１００を発信したＳＴＡとの接続を確立するのに使用するかもしれない何らかの情報を含んでいてもよい（例えば、このような情報は受信機ＭＡＣアドレスを、および／または、サポートされているデータレートを含んでいてもよい）。ＳＱデータは、発信するＳＴＡが提供するように構成されているサービスの詳細なリストを含んでいてもよい。いくつかの実施形態に対して、ＳＱデータは、ＳＴＡが特定の要求されるサービスを提供する能力があるか否かを示している確認ビットも含んでいてもよい。

【0074】

［００８５］
さらに、ＳＱデータは、ハッシュされるか、または、圧縮されて、（例えば、管理情報１１０２のためのスペースを保持しながら）Ｗｉ−Ｆｉデータフレームのサイズ制限内に、ＳＴＡによってサポートされている異なるサービスのすべてをエンコードできるようにしてもよい。例示的なエンコードアルゴリズムは、
・ＳＱデータ中のサービスの数が、小さい（例えば、８よりも小さい）場合、各サービスクエリに対するハッシュ値のアレイを生成させる。例えば、クエリストリング中のすべてのオクレットに対してＸＯＲ動作を使用して、各サービスクエリに対するハッシュ値を生成させてもよい。
・クエリサービスが「トランザクション的」である（例えば、第１のクエリストリングが固定されて、所望のトランザクションを記述している可変ストリングが続く）場合、クエリストリングの第１の部分（すなわち、静的で切り捨てられる部分）のみをハッシュする。例えば、２つのフィールド：ハッシュを計算するのに使用するクエリの長さと、所定の長さに切り捨てられるクエリストリングのハッシュとを有するエントリを、対応するアレイは有していてもよい。
ことを含んでいてもよい。

【0075】

［００８６］
本実施形態は、既存のプレアソシエーションサービス発見動作に対して、いくつかの利点を提供するかもしれない。例えば、Ｗｉ−Ｆｉ管理フレーム（例えば、プローブ要求、プローブ応答、および／または、ビーコンフレーム）内にＳＩデータを含むことによって、本実施形態は、Ｐ２Ｐプレアソシエーション動作のデバイス発見フェーズの間に、クライアントＳＴＡが特定のサービスのプロバイダに対するサーチを狭めることを可能にする。したがって、クライアントデバイスは、より早くて、より効率のよい方法で、後続のサービス発見動作を実行するかもしれない。さらに、管理情報とともにＳＱデータをブロードキャストすることによって、デバイス発見フェーズの間に、クライアントＳＴＡは、その後、複数のサービス発見動作を実行する必要なく、要求されるサービスを提供する能力がある任意のピアＳＴＡからサービス情報の完全なリストを取得できる。

【0076】

［００８７］
先述の明細書において、本実施形態を、その特定の例示的な実施形態を参照して説明してきた。しかしながら、添付された特許請求の範囲において明らかにされている開示のより広い範囲から逸脱することなく、さまざまな改変および変更を行ってもよいことは明白であろう。明細書および図面は、したがって、限定的な意味よりもむしろ、実例となる意味であると考えるべきである。例えば、図３、図４、図７および／または図１０のフローチャートにおいて図示されている方法ステップは、他の適切な順序で実行してもよく、および／または、複数のステップを単一のステップに組み合わせてもよい。
以下に、本願出願時の特許請求の範囲に記載された発明を付記する。
［１］ピアツーピア（Ｐ２Ｐ）ネットワーク中のクライアントデバイスを動作させる方法において、
前記方法は、
デバイス発見フェーズの間、
前記Ｐ２Ｐネットワークの１つ以上のチャネルをスキャンして、１つ以上のピアデバイスの存在を発見することと、
多数の前記ピアデバイスのそれぞれから、第１のフレームを受信し、各第１のフレームは、（ｉ）対応するピアデバイスとのＰ２Ｐ接続を確立するための管理情報と、（ｉｉ）前記対応するピアデバイスによってサポートされている多数のＰ２Ｐサービスを示しているサービス情報とを含むことと、
サービス発見フェーズの間、前記サービス情報に少なくとも部分的に基づいて、選択したピアデバイスにサービス発見要求を送ることとを含み、前記サービス発見要求は、１つ以上の特定のＰ２Ｐサービスを要求することである方法。
［２］前記選択したピアデバイスが、前記サービス情報において、前記１つ以上の特定のＰ２Ｐサービスに対するサポートを示す場合のみ、前記クライアントデバイスは、前記選択したピアデバイスに前記サービス発見要求を送る［１］記載の方法。
［３］前記スキャンすることは、前記ピアデバイスに対してプローブ要求をブロードキャストすることによって実行され、前記第１のフレームのうちの少なくとも１つは、プローブ応答を含む［１］記載の方法。
［４］前記プローブ要求は、前記クライアントデバイスによって提供される多数のＰ２Ｐサービスを示している多数の第１のハッシュ値を含み、前記プローブ応答は、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを示している多数の第２のハッシュ値を含む［３］記載の方法。
［５］前記クライアントデバイスは、前記第１のハッシュ値を前記第２のハッシュ値と比較して、前記対応するピアデバイスが、前記クライアントデバイスによって要求されることになる前記Ｐ２Ｐサービスをサポートするか否かを決定する［４］記載の方法。
［６］前記特定のＰ２Ｐサービスは、以下の、ユニバーサル・プラグ・アンド・プレイサービス、ボンジュール・サービス、Ｗｉ−Ｆｉディスプレイサービス、プリントサービス、ゲームサービス、ファイル共有サービスのうちの１つ以上を含む［１］記載の方法。
［７］前記スキャンすることは、前記対応するピアデバイスからブロードキャストされるビーコンフレームを聞くことによって実行され、前記第１のフレームは、前記ビーコンフレームを含む［１］記載の方法。
［８］前記ビーコンフレームのうちの少なくとも１つは、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを示している多数のハッシュ値を含む［７］記載の方法。
［９］前記１つ以上のピアデバイスはＰ２Ｐグループを含み、前記第１のフレームのそれぞれの１つは、前記Ｐ２Ｐグループのグループオーナーによりブロードキャストされるビーコンフレームを含む［１］記載の方法。
［１０］前記サービス情報は、前記Ｐ２Ｐグループの１人以上のメンバーが、前記１つ以上の特定のＰ２Ｐサービスを提供するように構成されているか否かを示す［９］記載の方法。
［１１］前記サービス情報は、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスに対する１つ以上の更新を示す［１］記載の方法。
［１２］前記Ｐ２Ｐサービスに対する前記１つ以上の更新を示している前記ピアデバイスに対してのみ、サービス発見要求フレームを送信することをさらに含む［１１］記載の方法。
［１３］プログラム命令を含んでいるコンピュータ読取可能記憶媒体において、
前記命令は、ピアツーピア（Ｐ２Ｐ）ネットワークに関係付けられているクライアントデバイスのプロセッサによって実行されるときに、前記クライアントデバイスに、
デバイス発見フェーズの間、
前記Ｐ２Ｐネットワークの１つ以上のチャネルをスキャンさせて、１つ以上のピアデバイスの存在を発見させ、
多数の前記ピアデバイスのそれぞれから、第１のフレームを受信させ、各第１のフレームは、（ｉ）対応するピアデバイスとのＰ２Ｐ接続を確立するための管理情報と、（ｉｉ）前記対応するピアデバイスによってサポートされている多数のＰ２Ｐサービスを示しているサービス情報とを含み、
サービス発見フェーズの間、前記サービス情報に少なくとも部分的に基づいて、選択したピアデバイスにサービス発見要求を送らせ、前記サービス発見要求は、１つ以上の特定のＰ２Ｐサービスを要求することであるコンピュータ読取可能記憶媒体。
［１４］前記選択したピアデバイスが、前記サービス情報において、前記１つ以上の特定のＰ２Ｐサービスに対するサポートを示す場合のみ、前記クライアントデバイスは、前記選択したピアデバイスに前記サービス発見要求を送る［１３］記載のコンピュータ読取可能記憶媒体。
［１５］スキャンするための、前記プログラム命令の実行は、前記クライアントデバイスに、
前記ピアデバイスに対してプローブ要求をブロードキャストさせ、前記第１のフレームは、プローブ応答を含む［１３］記載のコンピュータ読取可能記憶媒体。
［１６］前記プローブ要求は、前記クライアントデバイスによって提供される多数のＰ２Ｐサービスを示している多数の第１のハッシュ値を含み、前記プローブ応答のうちの少なくとも１つは、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを示している多数の第２のハッシュ値を含む［１５］記載のコンピュータ読取可能記憶媒体。
［１７］前記クライアントデバイスは、前記第１のハッシュ値を前記第２のハッシュ値と比較して、前記対応するピアデバイスが、前記クライアントデバイスによって要求されることになる前記Ｐ２Ｐサービスをサポートするか否かを決定する［１６］記載のコンピュータ読取可能記憶媒体。
［１８］前記特定のＰ２Ｐサービスは、以下の、ユニバーサル・プラグ・アンド・プレイサービス、ボンジュール・サービス、Ｗｉ−Ｆｉディスプレイサービス、プリントサービス、ゲームサービス、ファイル共有サービスのうちの１つ以上を含む［１３］記載のコンピュータ読取可能記憶媒体。
［１９］スキャンするための、前記プログラム命令の実行は、前記クライアントデバイスに、
前記対応するピアデバイスからブロードキャストされるビーコンフレームを聞かせ、前記第１のフレームは、前記ビーコンフレームを含む［１３］記載のコンピュータ読取可能記憶媒体。
［２０］前記ビーコンフレームのうちの少なくとも１つは、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを示している多数のハッシュ値を含む［１９］記載のコンピュータ読取可能記憶媒体。
［２１］前記１つ以上のピアデバイスはＰ２Ｐグループを含み、前記第１のフレームのそれぞれの１つは、前記Ｐ２Ｐグループのグループオーナーによりブロードキャストされるビーコンフレームを含む［１３］記載のコンピュータ読取可能記憶媒体。
［２２］前記サービス情報は、前記Ｐ２Ｐグループの１人以上のメンバーが、前記１つ以上の特定のＰ２Ｐサービスを提供するように構成されているか否かを示す［２１］記載のコンピュータ読取可能記憶媒体。
［２３］前記サービス情報は、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスに対する１つ以上の更新を示す［１３］記載のコンピュータ読取可能記憶媒体。
［２４］前記プログラム命令の実行は、さらに、前記クライアントデバイスに、
前記Ｐ２Ｐサービスに対する前記１つ以上の更新を示している前記ピアデバイスに対してのみ、サービス発見要求フレームを送信させる［２３］記載のコンピュータ読取可能記憶媒体。
［２５］ピアツーピア（Ｐ２Ｐ）ネットワークに関係付けられたクライアントデバイスにおいて、
前記クライアントデバイスは、
前記Ｐ２Ｐネットワークの１つ以上のチャネルをスキャンして、１つ以上のピアデバイスの存在を発見する手段と、
多数の前記ピアデバイスのそれぞれから、第１のフレームを受信し、各第１のフレームは、（ｉ）対応するピアデバイスとのＰ２Ｐ接続を確立するための管理情報と、（ｉｉ）前記対応するピアデバイスによってサポートされている多数のＰ２Ｐサービスを示しているサービス情報とを含む手段と、
前記サービス情報に少なくとも部分的に基づいて、選択したピアデバイスにサービス発見要求を送る手段とを具備し、前記サービス発見要求は、１つ以上の特定のＰ２Ｐサービスを要求することであるクライアントデバイス。
［２６］前記選択したピアデバイスが、前記サービス情報において、前記１つ以上の特定のＰ２Ｐサービスに対するサポートを示す場合のみ、前記クライアントデバイスは、前記選択したピアデバイスに前記サービス発見要求を送る［２５］記載のクライアントデバイス。
［２７］前記スキャンすることは、前記ピアデバイスに対してプローブ要求をブロードキャストすることによって実行され、前記第１のフレームのうちの少なくとも１つは、プローブ応答を含む［２５］記載のクライアントデバイス。
［２８］前記プローブ要求は、前記クライアントデバイスによって提供される多数のＰ２Ｐサービスを示している多数の第１のハッシュ値を含み、前記プローブ応答は、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを示している多数の第２のハッシュ値を含む［２７］記載のクライアントデバイス。
［２９］前記クライアントデバイスは、前記第１のハッシュ値を前記第２のハッシュ値と比較して、前記対応するピアデバイスが、前記クライアントデバイスによって要求されることになる前記Ｐ２Ｐサービスをサポートするか否かを決定する［２８］記載のクライアントデバイス。
［３０］前記スキャンすることは、前記対応するピアデバイスからブロードキャストされるビーコンフレームを聞くことによって実行され、前記第１のフレームは、前記ビーコンフレームを含む［２５］記載のクライアントデバイス。
［３１］前記ビーコンフレームのうちの少なくとも１つは、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを示している多数のハッシュ値を含む［３０］記載のクライアントデバイス。
［３２］前記１つ以上のピアデバイスはＰ２Ｐグループを含み、前記第１のフレームのそれぞれの１つは、前記Ｐ２Ｐグループのグループオーナーによりブロードキャストされるビーコンフレームを含む［２５］記載のクライアントデバイス。
［３３］ピアツーピア（Ｐ２Ｐ）ネットワークに関係付けられているクライアントデバイスにおいて、
前記クライアントデバイスは、
１つ以上のピアデバイスとデータを交換するトランシーバと、
プロセッサとを具備し、
前記プロセッサは、
デバイス発見フェーズの間、
前記１つ以上のピアデバイスにプローブ要求を送信し、前記プローブ要求は、前記クライアントデバイスにより提供される多数のＰ２Ｐサービスを識別する第１のサービス情報を含み、
多数の前記ピアデバイスのそれぞれから、プローブ応答を受信し、各プローブ応答は、（ｉ）対応するピアデバイスとのＰ２Ｐ接続を確立するための管理情報と、（ｉｉ）前記対応するピアデバイスによってサポートされている多数のＰ２Ｐサービスを識別する第２のサービス情報とを含み、
サービス発見フェーズの間、
前記第２のサービス情報に基づいて、選択したピアデバイスにサービス発見要求を送り、前記サービス発見要求は、１つ以上の特定のＰ２Ｐサービスを要求することであるクライアントデバイス。
［３４］前記選択したピアデバイスが、前記プローブ応答において、前記１つ以上の特定のＰ２Ｐサービスに対するサポートを示す場合のみ、前記クライアントデバイスは、前記選択したピアデバイスに前記サービス発見要求を送る［３３］記載のクライアントデバイス。
［３５］前記第１のサービス情報は、前記クライアントデバイスによって提供される前記多数のＰ２Ｐサービスを識別する多数の第１のハッシュ値を含み、前記第２のサービス情報は、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスを識別する多数の第２のハッシュ値を含む［３３］記載のクライアントデバイス。
［３６］前記クライアントデバイスは、前記第１のハッシュ値を前記第２のハッシュ値と比較して、前記対応するピアデバイスが、前記クライアントデバイスによって要求されることになる前記Ｐ２Ｐサービスをサポートするか否かを決定する［３５］記載のクライアントデバイス。
［３７］前記特定のＰ２Ｐサービスは、以下の、ユニバーサル・プラグ・アンド・プレイサービス、ボンジュール・サービス、Ｗｉ−Ｆｉディスプレイサービス、プリントサービス、ゲームサービス、ファイル共有サービスのうちの１つ以上を含む［３３］記載のクライアントデバイス。
［３８］前記１つ以上のピアデバイスは、Ｐ２Ｐグループを含む［３３］記載のクライアントデバイス。
［３９］前記第２のサービス情報は、前記Ｐ２Ｐグループの１人以上のメンバーが、前記１つ以上の特定のＰ２Ｐサービスを提供するように構成されているか否かを示す［３８］記載のクライアントデバイス。
［４０］前記第２のサービス情報は、前記対応するピアデバイスによってサポートされている前記Ｐ２Ｐサービスに対する１つ以上の更新を示す［３３］記載のクライアントデバイス。

【図1A】

【図1B】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図7】

【図8】

【図9】

【図10】

【図11】