JP6406681B2 - プレアソシエーションサービスディスカバリのためのシステムおよび方法 - Google Patents

Description

本出願は、2015年8月21日に提出された米国仮特許出願第14／832，607号、標題「System and Method for Securing Pre−Association Service Discovery」に対する優先権を主張し、ひいては2014年8月25日に提出された米国仮特許出願第62／041，470号、標題「Method and System for Securing Pre−association Service Discovery」の優先権を主張するものであり、その両方の特許出願はその全体が再現されているかのように参照により本明細書に援用される。

本開示は、概して、デジタル通信、より具体的には、プレアソシエーションサービスディスカバリを確保するためのシステムおよび方法に関する。

IEEE 802．11系の技術方式および付帯技術は、通称Wi−Fiとも呼ばれ、デバイスが特定の目的のために接続する、サービス中心の接続モデルに発展している。意図的な接続は、特定のサービスをサポートするネットワークおよび／またはピアデバイスを探すアプリケーションによってトリガされる。これらのサービスの例には、ファイル共有、印刷、メディアストリーミング等が含まれる。

Wi−Fi接続は、一般的に、認証、アソシエーション、またある場合にはインターネットプロトコル（IP）アドレスの割り当てが成功裏に完了した後に確立され、その後、サービスデータをデバイス間で交換することができる。認証、アソシエーションおよびIPアドレス割り当て手順によるシグナリングオーバーヘッドおよび遅延が多い場合があり、このことは接続されたデバイスが要求されたサービスを提供することができる場合にのみ正当な理由となり得る。不要な遅延を回避するために、デバイスは、プレアソシエーションサービスディスカバリを行って、デバイスが最初に認証およびアソシエーション手順を実行することなく提供する、デバイスおよびサービスを識別することができる。プレアソシエーションサービスディスカバリを確保するための機構が望まれている。

例示的な実施形態は、プレアソシエーションサービスディスカバリを確保するためのシステムおよび方法を提供する。

例示的な実施形態によれば、サービスを発見する際に局を動作させるための方法が提供される。方法は、局によってサービスの第1の識別子を生成するステップと、局によって、第1のパラメータに基づいて、サービスの第2の識別子を生成するステップと、局によって第3の識別子の生成を指示する要求を送信するステップと、を含み、要求は、サービスの第1の識別子と、第1のパラメータとを含む。方法は、局によって第3の識別子を含む第1の応答を受信するステップと、局によって、第2の識別子と第3の識別子が等しくない場合に、第1の応答が有効でないと判定するステップと、局によって、第2の識別子と第3の識別子が等しい場合に、第1の応答が有効であると判定するステップと、を含む。

別の例示的な実施形態によれば、サービスを発見するように適合された局が提供される。局は、処理ユニットと、処理ユニットに動作可能に結合された送信機と、処理ユニットに動作可能に結合された受信機とを含む。処理ユニットは、サービスの第1の識別子を生成し、サービスの第2の識別子を生成し、第2の識別子は第1のパラメータに基づいて生成され、第2の識別子と第3の識別子が等しくない場合に、第1の応答が有効でないと判定し、第2の識別子と第3の識別子が等しい場合に、第1の応答が有効であると判定する。送信機は、第3の識別子の生成を支持する要求を送信し、要求は、サービスの第1の識別子と、第1のパラメータとを含む。受信機は、第3の識別子を含む第1の応答を受信する。

別の例示的な実施形態によれば、サービスを広告する際に局を動作させる方法が提供される。方法は、局によって、第1の識別子および第1のパラメータを含む要求を受信するステップと、局によって、サービスの第2の識別子を生成するステップと、局によって、第1の識別子と第2の識別子が等しいと判定された場合に、局によって、第1のパラメータに基づいて、サービスの第3の識別子を生成するステップと、局によって、サービスの第3の識別子を含む第1の応答を送信するステップと、を含む。

別の例示的な実施形態によれば、サービスを広告するように適合された局が提供される。局は、受信機と、受信機に動作可能に結合された処理ユニットと、処理ユニットに動作可能に結合された送信機とを含む。受信機は、第1の識別子および第1のパラメータを含む要求を受信する。処理ユニットは、サービスの第2の識別子を生成し、第1の識別子と第2の識別子が等しい場合に、第1のパラメータに基づいて、サービスの第3の識別子を生成する。送信機は、サービスの第3の識別子を含む第1の応答を送信する。

以上の実施形態の実行は、サービス名を暗号化することによって、プレアソシエーションサービスディスカバリを保護し、サブスクライバのプライバシー保護に役立つ。

また、異なる切り捨てられたハッシュ出力に一致しているハッシュ、およびノンスを使用することによって、セキュリティはさらに強化される。

本開示およびその利点をより完全に理解するために、添付図面と合わせて以下の説明をここで参照する。

本明細書に記載された例示的な実施形態による例示的な通信システムを示す。 ピア局（またはデバイス）でサービスディスカバリ中に交換されるメッセージを強調している、例示的なメッセージ交換図を示す。 サービスディスカバリを行っている2つのNANデバイス間のインタラクションを強調している、例示的な通信システムを示す。 プレアソシエーションディスカバリのためにIEEE 802．11 TGaqに提案されている、例示的な通信システムのアーキテクチャおよびネットワーク要素を示す。 本明細書に記載された例示的な実施形態による安全なプレアソシエーションサービスディスカバリを行っているサブスクライバに発生している動作例のフローチャートを示す。 本明細書に記載された例示的な実施形態による安全なプレアソシエーションサービスディスカバリを行っているパブリッシャに発生している動作例のフローチャートを示す図である。 安全なプレアソシエーションサービスディスカバリを行っているサブスクライバに発生している動作例のフローチャートであって、パラメータは、本明細書に記載された例示的な実施形態によるハッシュ出力の一部を示す。 安全なプレアソシエーションサービスディスカバリを行っているパブリッシャに発生している動作例のフローチャートであって、パラメータは、本明細書に記載された例示的な実施形態によるハッシュ出力の一部を示す。 安全なプレアソシエーションサービスディスカバリを行っているサブスクライバに発生している動作例のフローチャートであって、パラメータは、本明細書に記載された例示的な実施形態によるノンスである。 安全なプレアソシエーションサービスディスカバリを行っているパブリッシャに発生している動作例のフローチャートであって、パラメータは、本明細書に記載された例示的な実施形態によるノンスである。 本明細書に記載された例示的な実施形態による、高速認証およびプレアソシエーションサービスディスカバリを強調している、メッセージ交換図を示す。 本明細書に記載された例示的な実施形態による、高速認証およびプレアソシエーションサービスディスカバリに参加しているサブスクライバに発生している、動作例のフローチャートを示す。 本明細書に記載された例示的な実施形態による、高速認証およびプレアソシエーションサービスディスカバリに参加しているパブリッシャにおいて発生している、動作例のフローチャートを示す。 本明細書に開示されたデバイスおよび方法を実施するために使用することができる処理システムのブロック図である。

例示的な当実施形態の動作およびその構成について、以下に詳しく説明する。しかし、明らかなように、本開示は、種々の特定の文脈で実現することができる多くの適用可能な発明概念を提供するものである。説明する特定の実施形態は、本開示の特定な構成および本明細書で開示された実施形態を動作させる方法の単なる例示であり、本開示の範囲を限定するものではない。

一実施形態は、プレアソシエーションサービスディスカバリの保護に関する。たとえば、局は、サービスの第1の識別子を生成し、第1のパラメータに基づいて、サービスの第2の識別子を生成し、第3の識別子の生成を指示する要求を送信し、要求は、サービスの第1の識別子と第1のパラメータとを含む。局はまた、第3の識別子を含む第1の応答を受信し、第2の識別子と第3の識別子が等しくない場合に第1の応答が有効でないと判定し、第2の識別子と第3の識別子が等しい場合に第1の応答が有効であると判定する。

本実施形態は、特定の状況、すなわち、サービス中心の接続およびプレアソシエーション動作をサポートして、接続を確立する前にサービスを発見する無線通信システムにおける、例示的な実施形態について記載する。本実施形態は、サービス中心の接続およびプレアソシエーションディスカバリをサポートする、IEEE 802．11aq、IEEE 802．15．8ピアアウェア通信（PAC）、Wi−Fiアライアンス（WFA）近隣アウェアネスネットワーキング（NAN）、WFA Wi−Fi Directサービス（WFDS）、WFAアプリケーションサービスプラットフォーム（ASP）2．0、第3世代パートナーシップ・プロジェクト（3GPP）デバイスツーデバイス（D2D）等、技術標準に準拠するもの等、標準に準拠する無線通信システム、および非標準的な通信システムに適用することができる。

図1は、例示的な通信システム100を示す。通信システム100は、STA1 105およびSTA2 110の2局を含み、基本サービスセット（BSS）を形成する。局は、デバイス、端末、ユーザ機器（UE）、移動局（MS）、通信ノード、ユーザ等と呼ばれることも多い。この2局は、アクセスポイント（AP）、ノードB、eノードB（eNB）、基地局（BS）または通信コントローラのような集中型ネットワーク機器の支援なしに信号を送る、802．11メディアアクセスコントロール（MAC）および物理（PHY）層を使用して、互いに直接通信する。このタイプの通信は、アドホックまたはピアツーピア（P2P）通信としても知られている。Wi−Fiダイレクトとしても知られているWi−Fi P2Pは、このようなP2P通信技術の一例であり、米国電気電子学会（IEEE）802．11エアインターフェース標準を使用しており、多くのスマートフォン、プリンタおよび家庭用電化製品においてますます普及してきている。Wi−Fiダイレクト仕様は、IEEE 802．11標準に基づいて、Wi−Fiアライアンス（WFA）によって開発された。最近、Wi−Fiアライアンスは、新たなWi−Fiダイレクトサービス（WFDS）仕様によって、Wi−Fiダイレクトをさらに強化し、Wi−Fiダイレクトのためのサービスディスカバリおよびサービスレベル相互運用性を向上させている。

BSSは複数の局を使用してもよいことが理解されるが、単純化のため2局のみ図示する。さらに、通信システムは、複数のAPを使用して、たとえばAP制御通信を行うこともできるが、図1にはAPが示されていない。

図2は、ピア局（またはデバイス）でサービスの発見中に交換されるメッセージを強調している、メッセージ交換図200を示す。WFDSでは、サービスは、汎用コード化文字集合＋8ビットのトランスフォーメーションフォーマット（UTF−8）ストリングのサービス名で表される。たとえば、プリンタサービス用のWFDS仕様に定義されているサービス名は、「org．wi−fi．wfds．print．tx」である。WFAは、WFAで定義されていないサービスのサービス名について、「逆ドメイン名表記法」を用いることをさらに推奨している。サービス名の他、サービスハッシュと呼ばれる短い識別子を使用して、サービスを表すこともできる。サービスハッシュは、たとえば、ハッシュ関数への入力としてサービス名を備えた、SHA−256ハッシュ関数のハッシュ出力の最初の6オクテットである。

メッセージ交換図200は、アドバタイザの役割で動作しているデバイスA 205）、およびシーカの役割で動作しているデバイスB 215）によって交換されたメッセージおよび行われた処理を示す。本開示の例示的な実施形態において、アドバタイザは、パブリッシャと言い換え可能な用語であり、シーカは、サブスクライバと言い換え可能な用語である。デバイスA 205およびデバイスB 215は各々、サービス層（それぞれデバイスA 205の207およびデバイスBの217）、アプリケーションサービスプラットフォーム（ASP）層（それぞれデバイスA 205の209およびデバイスBの219）、ピアツーピア（P2P）メディアアクセス制御（MAC）層（それぞれデバイスA 205の211およびデバイスBの221）のような複数の層を含む。物理（PHY）層のようなP2P MAC層の下層の詳細は、図2を単純化し易いように意図的に省略されている。デバイスA 205のサービス層207は、1つ以上のservice＿name＿advertiserを備えたデバイスA 205のASP層209からAdvertiseService（）手順を開始することができ、service＿name＿advertiserの各々は、デバイスA 205によって提供されたサービスのサービス名である（イベント230として示す）。イベント230は、WFDSサービスを追加するデバイスA 205のASP層209をもたらす（イベント232として示す）。デバイスA 205のASP層209はまた、各service＿name＿advertiser用のサービスハッシュを生成してもよい（イベント234として示す）。

デバイスB 215のサービス層217は、1つ以上のservice＿name＿seekerを備えたデバイスB 215のASP層219からSeekService（）手順を開始することができ、service＿name＿seekerの各々は、デバイスB 215によって所望されたサービスのサービス名である（イベント236として示す）。イベント236は、各service＿name＿seeker用のサービスハッシュを生成するデバイスB 215のASP層219をもたらす（イベント238として示す）。デバイスB 215のASP層219は、サービスハッシュを生成するために、たとえばハッシュ出力の最初の6オクテット等、service＿name＿seekerのハッシュ出力の一部を使用することができる。P2P MAC層221は、1つ以上のサービスハッシュを含むP2Pプローブ要求を送信してもよい（イベント240として示す）。

デバイスA 205は、（service＿name＿advertiserから生成された）そのサービスハッシュが、（service＿name＿seekerからシーカ（すなわちデバイスB 215）によって生成された）P2Pプローブ要求において受信されたサービスハッシュと一致するかどうかを判定するチェックを行ってもよい（ハッシュ照合242として示す）。一致が存在する場合、デバイスA 205は、一致したサービスハッシュのservice＿name＿advertiserを含む、P2Pプローブ応答を送信してもよい（イベント244として示す）。デバイスB 215は、デバイスA 205から受信したservice＿name＿advertiserがservice＿name＿seekerと一致するかどうかを判定するチェックを行ってもよい（名前の照合246として示す）。一致が存在する場合、デバイスB 215は、デバイスA 205に対して、service＿name＿seekerと追加のサービス情報の要求とを備えた、サービスディスカバリ（SD）要求フレームを送信してもよい（イベント248として示す）。次に、デバイスAは、サービス名の照合およびサービス情報の照合（「名前の照合、サービス情報の照合」250として示す）を行い、SD応答フレーム内に要求された追加のサービス情報を備えて応答してもよい（イベント252として示す）。

図2に示すように、プローブ応答およびSD要求／応答フレームには、平文サービス名が使用され、平文サービス名は、プレアソシエーションマネージメントフレームの性質上、WFDS仕様によるいかなる層2セキュリティまたはプライバシー保護手段によっても保護されていない。露出したサービス名は、意図しない受信者によって使用されて、ユーザがプロファイルされたり、ユーザの秘密情報が推定される可能性がある。一例として、モバイルヘルスケアデバイス上で動作しているサービスは、デバイスを使用する目的である医学的状態に関連する方法で命名されている可能性がある。したがって、サービス名は、平文で露出した場合、デバイスのユーザがその特定の医学的状態を有することを示す可能性がある。

現在、デバイスのバックグラウンドで動作して、デバイスに近隣認識をさせる低電力機構を、Wi−Fi技術にもたらすために、Wi−FiアライアンスNANマーケティングおよび技術タスクグループによって、近隣認識ネットワーキング（NAN）認証プログラムおよび仕様が開発されている。NAN技術があれば、モバイルデバイスは、近傍の人やサービスを効率的に発見することができる。NANの典型的な用途には、Wi−Fi方式のモバイルソーシャルネットワーキング、モバイルコマース、モバイル広告、無線マルチプレーヤゲーム等が含まれることが想定される。

図3は、2つのNANデバイスがサービスディスカバリを行う際の相互作用を強調している、通信システム300を示す。図3に示すように、2つのNANデバイス（NANデバイス305およびNANデバイス315）と、NANデバイスとしてこれらのNANデバイスの中にあるNANコンポーネント（アプリケーション307およびアプリケーション317、ディスカバリエンジン（DE）309およびDE319、MAC層311およびMAC層321等）との間の相互作用は、ドラフトのWi−FiアライアンスNAN仕様v0．0r18に基づいて、802．11物理層325上で、サービスディスカバリを行う。AdvertiseServiceコマンドおよびSubscribeServiceコマンドは、アプリケーション・プログラミング・インターフェース（API）を介して、NAN DEにアプリケーションによって提供される。NAN DEは、受信したAdvertiseServiceコマンドまたはSubscribeServiceコマンドを処理し、それに基づいて、NANディスカバリエンジンは、NAN MACコンポーネントに対して、パブリッシュメッセージまたはサブスクライブメッセージを生成し提供する。NAN MACコンポーネントは、NANビーコンフレームおよびサービスディスカバリフレームを処理し、取り扱う責任を有し、これによりパブリッシュメッセージまたはサブスクライブメッセージが搬送される。NANサービスディスカバフレームは、ベンダー固有のコンテンツを定義するWi−Fiアライアンスを備えたIEEE 802．11パブリックアクションフレームフォーマットを用いて、詳細なサービス情報（たとえばパブリッシュメッセージ）または詳細なサービスクエリ（たとえばサブスクライブメッセージ）を提供する。

NANでは、平文サービス名は、無線のいかなるNANプロトコルメッセージにおいても使用されない。代わりに、NANプロトコルメッセージでは、WFDSのサービスハッシュとして前述したサービス名と全く同じ切り捨てられた暗号ハッシュである、サービス識別子（ID）を用いて、サービスを識別する。しかし、NANサービスディスカバリフレーム内で搬送されたNANサービスクエリおよびサービス応答の残りのコンテンツは、MAC副層で保護されていない。この結果、クエリされているサービスのサービス情報、デバイスのグローバルMACアドレスを含むことが多いディスカバリ後の接続情報のような秘密情報が、意図しない受信者に暴露される可能性があり、受信者は、そのサービス情報を用いてユーザをプロファイルする、および／または、MACアドレスを用いてユーザを追跡する可能性がある。このことは、サービスクエリおよびサービス応答の交換に先立つ認証およびアソシエーションの欠如により、WFDSサービスディスカバリおよびIEEE 802．11aqのような他のプレアソシエーションディスカバリ機構においても事実である。

IEEE 802．11タスクグループAQ（TGaq）は現在、アクセスポイントとのアソシエーションを行う前に、Wi−Fiデバイスが、無線ローカルエリアネットワーク（WLAN）に提供されたサービスを発見することができるように、プレアソシエーションディスカバリ（PAD）技術を開発している。図4は、プレアソシエーションディスカバリのためにIEEE 802．11 TGaqに提案されている、例示的な通信システム400のアーキテクチャおよびネットワーク要素を示す。通信システム400は、局STA1 405、Wi−Fiを用いて局STA1 405のような局に使用されるアクセスポイントAP1 410、およびAP1 410と接続されたサービストランザクションプロキシ（STP）エンティティ415を含む。STP415は、ローカルエリアネットワーク420の、AP2のような、他のアクセスポイントにも接続される可能性がある。STP415は、サービスおよび関連づけられたサービス情報のリストをキャッシュする、論理エンティティである。STP415は、ネットワーク425にも接続され、たとえば、ネットワーク425でアドバタイザからサービスおよび関連づけられたサービス情報に関する情報を取得することができる。STA1 405のような局は、AP1 410のようなアクセスポイントとアソシエーション手順を行う前に、ローカルエリアネットワーク420のAP1 410のようなアクセスポイントを介して、サービスクエリメッセージをSTP415に送信し、STP415からサービス応答メッセージを受信することができる。STA1 405およびAP1 410の間では、IEEE 802．11aq MAC副層上で、generic advertisement service（GAS）要求フレームおよびGAS応答フレームを用いて、サービスクエリおよびサービス応答メッセージが移送され、これは、図3に示すように、NAN MAC副層上で、NANサービスディスカバリフレームを用いて、NANパブリッシュメッセージおよびサブスクライブメッセージが移送される方法に似ている。STP415およびAP1 410は、一般的に有線回線を用いて接続される。したがって、STP415およびAP1 410の間では、サービスクエリおよびサービス応答メッセージは、Diameter or Remote Authentication Dial In User Service（RADIUS）のような有線ベースのプロトコルを用いて移送されてもよい。

上記のように、秘密情報は、WFDSおよびNANの両方において、意図しない受信者に漏洩される可能性があり、このことはセキュリティの脆弱性につながる可能性がある。例として、ハッカーのデバイスは、（ハッカーにそのサービス名を提供する）正規のサービスアドバタイザから、WFDS P2Pプローブ応答およびSD応答フレームを受信し、WFDS P2Pプローブ応答およびSD応答フレーム内で見出したサービス名から生成されるサービスIDを、サービスシーカがWFDS P2Pプローブ要求を送るように誘い出すためにハッカーのデバイスが送信するNANパブリッシュメッセージ内で広告することによって、ハッカーは、他の場所で正規のサービスアドバタイザになりすますことが可能となる。サービスシーカからのWFDS P2Pプローブ要求に応じて、ハッカーのデバイスは、ハッカーのデバイスがサービスシーカに送信する、WFDS P2Pプローブ応答およびSD応答に、盗難サービス名およびサービス情報を含めることによってリプレイし、正規のサービスアドバタイザがサービスシーカに応答しているかのように見せる。次に、ハッカーのデバイスは、WFDS手順を用いて、正規のサービスシーカとのP2P接続をセットアップすることができる。IP層および移送層の接続が一旦確立されると、ハッカーは、正規のサービスシーカに、広告等のジャンク情報を送信し始める可能性がある。

別の例として、ハッカーのデバイスは、正規のサービスプロバイダのサービスIDを、そのサービスプロバイダが送信したNANパブリッシュメッセージから受信する。ハッカーのデバイスは、サービスシーカを装い、WFDS P2Pプローブ要求内のサービスハッシュと同じサービスIDをリプレイすることによって（同じサービス名に対するWFDS内のサービスハッシュとNANのサービスIDとは全く同一であるため）、WFDS P2Pプローブ要求をサービスプロバイダに送信する。サービスハッシュの一致を判定した後、サービスプロバイダは、サービス名を含むWFDS P2Pプローブ応答を備えて応答する。次に、ハッカーのデバイスは、WFDS SDクエリをさらに送信して、サービス情報を要求することができる。次に、ハッカーのデバイスは、WFDS手順を用いて、正規のサービスプロバイダとのWi−Fi P2P接続をセットアップすることができる。IP層および移送層の接続が一旦確立されると、ハッカーは、正規のサービスプロバイダに、広告等のジャンク情報を送信し始める可能性がある。

そのため、サービスアドバタイザは、さらなるサービスディスカバリの交換が許容される前に、サービスシーカの信頼性およびその逆を検証できることが望ましい。

ドラフトのWFA NAN仕様には、共有のシークレットキー、たとえばNANグループキーを用いることによって、デバイスのグループは、NANパブリッシュおよびサブスクライブ機能を安全に利用することができると述べられている。NANサービスIDは、NANグループキーを用いてサービス名をハッシュすることによって形成される、偽のランダムなセキュアサービスIDでサービスIDを置換することによって、さらに保護することができる。また、NANサービス情報は、たとえばNANマスターグループキーおよびAES−SIVアルゴリズムを用いて、サービス情報を暗号化することによって保護することができる。しかし、共有のグループキーの使用は、グループのメンバーシップを確立し、最初に共有のシークレットキーを配布するために、追加のステップを必要とする。また、サービス情報がサービス名のように比較的静的である場合、共有のグループキーを頻繁に変更しない限り、暗号化されたサービス情報は、依然としてリプレイ攻撃にさらされる可能性がある。

したがって、本開示の1つの態様は、プレアソシエーションサービスディスカバリのクエリおよび応答の初期交換中に、層2以上の層のメッセージを搬送するための、層2移送を提供することである。いくつかの実施形態では、層2以上の層メッセージを用いて、さらなるサービスディスカバリの交換が許可される前に、または特定のサービス情報が開示される前に、アドバタイザ／パブリッシャまたはシーカ／サブスクライバの信頼性を検証することができ、共有のシークレットキーを確立して、後続のサービスディスカバリクエリ、応答およびフォローアップメッセージの間、サービス関連情報のプライバシーを保護することができ、および／または、予め定められたフォーマットを示すか要求して、後続のサービスディスカバリおよび／またはプロビジョニングネゴシエーションメッセージにおいて、サービス情報を表すか保護することができる。

例示的な実施形態によれば、サブスクライバおよびパブリッシャは、現在送信されているメッセージ内および／または現在送信されているメッセージに応じてこれから受信されるメッセージ内に、サービス識別子が生成または選択された方法を示すパラメータを備えたサービス識別子を含む、サービスクエリおよびサービス応答メッセージを交換する。サービス識別子の動的な生成または選択は、パブリッシャおよびサブスクライバの信頼性を検証することによってサブスクライバのプライバシーが保護されることを確実にするために有用である。

図5Aは、安全なプレアソシエーションサービスディスカバリを行っているサブスクライバに発生している例示的な動作500のフロー図を示す。動作500は、サブスクライバがパブリッシャと安全なプレアソシエーションサービスディスカバリを行う際に、サブスクライバに発生している動作を示してもよい。

動作500は、サブスクライバが探しているサービスのサービス名の第1の識別子をサブスクライバが生成することから開始されてもよい（ブロック505）。サブスクライバは、パブリッシャに対して、第1の識別子およびパラメータを備えた、要求すなわちサービスクエリメッセージを送信してもよい（ブロック507）。第1の識別子のような識別子は、SHA−256のようなハッシュ関数を、サブスクライバがシークしているサービスのサービス名のようなサービス名に適用した、切り捨てられたハッシュ出力であってもよい。パラメータは、第3の識別子の生成方法を示す、第1の指標を備えていてもよく、第3の識別子は、応答すなわちサービス応答メッセージに含まれて、一致したサービスを表す。説明のための例として、第1の指標は、応答内で第3の識別子を生成するのに使用される、ハッシュ出力の第1の切り捨てられた部分を示す。説明のための別の例として、第1の指標は、サービス要求への応答内で第3の識別子を生成するのに使用される、第1の乱数（すなわち第1のノンス）を示す。パラメータの第1の指標は、サブスクライバによって使用され、サービス応答に含まれた第3の識別子である、チャレンジへのパブリッシャの応答を通して、パブリッシャの信頼性を検証するために、パブリッシャへのチャレンジが生成される。パラメータは、第1の識別子とのハッシュ照合に使用される識別子の生成方法を示すために使用される、第2の指標を備えていてもよい。説明のための例として、第2の指標は、第1の識別子とのハッシュ照合に使用されるハッシュ出力の第2の切り捨てられた部分を示す。説明のための別の例として、第2の指標は、第1の識別子とのハッシュ照合に使用される識別子を生成するのに使用される、第2の乱数（すなわち第2のノンス）を示す。パラメータの使用を含む例示的な実施形態の詳細な説明を以下に提供する。

サブスクライバは、サブスクライバが探しているサービスのサービス名の第2の識別子を生成してもよい（ブロック509）。第2の識別子は、サブスクライバによって送信された要求に含まれたパラメータの第1の指標に基づいて生成される。サブスクライバは、パブリッシャからの第3の識別子を備えた、応答すなわちサービス応答メッセージを受信してもよい（ブロック511）。第3の識別子は、パブリッシャが提供している一致したサービスのサービス名からパブリッシャによって生成され（すなわち、ハッシュ照合のために生成される識別子は、第1の識別子と一致する）、サブスクライバによって送信されたパラメータの第1の指標に基づいて生成される。サブスクライバは、第2の識別子が第3の識別子と一致するか否かを判定するチェックを行ってもよい（ブロック513）。第2の識別子が第3の識別子と一致する場合、応答は有効であり（ブロック515）、プレアソシエーションサービスディスカバリを完了してもよく、または、サブスクライバは、パブリッシャと、一致したサービスの詳細なサービス情報のさらなるディスカバリを進めてもよい。第2の識別子が第3の識別子と一致しない場合、応答は有効ではなく、パブリッシャとのプレアソシエーションサービスディスカバリは中断されてもよく、または、サブスクライバは、別のパブリッシャとプレアソシエーションサービスディスカバリを繰り返してもよい。なお、パブリッシャから受信した応答は、サブスクライバが、第2のパラメータに基づいて第4の識別子を生成し、第4の識別子を用いて、後続のサービスクエリまたはフォローアップメッセージ内の一致したサービスを表し、プライバシーに関わる可能性がある追加のサービス情報を取得するために、その信頼性を証明するように指示する、第2のパラメータをさらに含んでもよい。説明のための例として、第2のパラメータは、第4の識別子を生成するのに使用される、ハッシュ出力の第3の切り捨てられた部分を示す。説明のための別の例として、第2のパラメータは、第4の識別子を生成するのに使用される、第3の乱数（すなわち第3のノンス）を示す。次に、追加のサービス情報の受信を望んでいるサブスクライバは、受信した第2のパラメータに基づいて、サービス名の第4の識別子を生成し、第4の識別子を含む後続のサービスクエリまたはフォローアップメッセージを送信する。結果として、サブスクライバは、パブリッシャからの追加のサービス情報を含む第2の応答を受信してもよく、プレアソシエーションサービスディスカバリを完了してもよい。

図5Bは、安全なプレアソシエーションサービスディスカバリを行っているパブリッシャに発生している例示的な動作550のフロー図を示す。動作550は、パブリッシャがサブスクライバと安全なプレアソシエーションサービスディスカバリを行う際に、パブリッシャに発生している動作を示してもよい。

動作550は、パブリッシャが要求すなわちサービスクエリメッセージを受信することから開始されてもよい（ブロック555）。要求は、第1の識別子およびパラメータを含んでもよい。第1の識別子のような識別子は、SHA−256のようなハッシュ関数を、サブスクライバがシークしているサービスのサービス名のようなサービス名に適用した、切り捨てられたハッシュ出力であってもよい。パラメータは、第1の識別子とのハッシュ照合で一致したサービスが見出された場合、応答すなわちサービス応答メッセージに含まれて、一致したサービスを表すための、第3の識別子の生成方法を示す、第1の指標を備えていてもよい。説明のための例として、第1の指標は、第3の識別子を生成するのに使用される、ハッシュ出力の第1の切り捨てられた部分を示す。説明のための別の例として、第1の指標は、第3の識別子を生成するのに使用される、第1の乱数（すなわち第1のノンス）を示す。パラメータは、第1の識別子とのハッシュ照合に使用される、第2の識別子の生成方法を示す、第2の指標をさらに含んでいてもよい。説明のための例として、第2の指標は、第1の識別子とのハッシュ照合で第2の識別子として使用される、ハッシュ出力の第2の切り捨てられた部分を示す。説明のための別の例として、第2の指標は、第1の識別子とのハッシュ照合に使用される第2の識別子を生成するのに使用される、第2の乱数（すなわち第2のノンス）を示す。パラメータの使用を含む例示的な実施形態の詳細な説明を以下に提供する。

パブリッシャは、SHA−256のようなハッシュ関数を、パブリッシャによって提供されたサービスのサービス名に適用した、ハッシュ出力の切り捨てられた部分を用いて、第2の識別子を生成してもよい（ブロック556）。パブリッシャは、たとえば、上記説明のための2例のうちの一例に記載したように、受信したパラメータの第2の指標に基づいて、第2の識別子を生成してもよい。パブリッシャは、チェック（すなわちハッシュ照合）を行って、第1の識別子が第2の識別子と一致するか否かを判定してもよい（ブロック557）。第1の識別子が第2の識別子と一致している場合、パブリッシャは、受信したパラメータの第1の指標に基づいて、一致したサービスの第3の識別子を生成してもよい（ブロック559）。パブリッシャは、第3の識別子を含む、応答すなわちサービス応答メッセージを送信して、サブスクライバに対して一致したサービスを表してもよい（ブロック561）。パブリッシャは、応答に、サービスの使用状態、サービスの特定のパラメータまたは属性のような、一致したサービスのサービス情報をさらに含んでもよい。パブリッシャは、応答に第2のパラメータをさらに含んでもよく、第2のパラメータは、サブスクライバがパブリッシャに送信する後続のサービスクエリまたはフォローアップメッセージの中で、一致したサービスを表す第4の識別子をサブスクライバが生成する方法を示す。説明のための例として、第2のパラメータは、第4の識別子を生成するのに使用される、ハッシュ出力の第3の切り捨てられた部分を示す。説明のための別の例として、第2のパラメータは、第4の識別子を生成するのに使用される、第3の乱数（すなわち第3のノンス）を示す。第2のパラメータは、パブリッシャによって使用され、後続のサービスクエリまたはフォローアップメッセージに含まれた第4の識別子である、チャレンジへのサブスクライバの応答を通して、サブスクライバの信頼性を検証するために、サブスクライバへのチャレンジが生成される。サブスクライバによって送信された後続のサービスクエリまたはフォローアップメッセージ内の第4の識別子が、パブリッシャが予期した識別子と一致する場合、パブリッシャは、プライバシーに関わる可能性のある追加のサービス情報を備えて応答してもよい。後続のサービスクエリまたはフォローアップメッセージの中でサブスクライバによって送信された第4の識別子が、パブリッシャが予期した識別子と一致しない場合、パブリッシャは、サブスクライバの信頼性が確立されていないとみなし、関連サービス情報のさらなる応答または開示を中断し、プレアソシエーションサービスディスカバリを終了してもよい。第1の識別子が、ブロック557においてパブリッシャが提供する任意のサービスの第2の識別子と一致しない場合、パブリッシャは、要求を満たすことができないとみなす。次に、パブリッシャは、サブスクライバに応答しないか、または否定応答を提供し、プレアソシエーションサービスディスカバリを終了してもよい。

例示的な実施形態によれば、パラメータは、識別子として使用されるサービス名にハッシュ関数が適用される際に生成される、ハッシュ出力の一部を特定する。一般に、ハッシュ出力は長く、ハッシュ出力全体を備えた要求および／または応答を送信することは、シグナリングオーバーヘッドの面で無駄である場合がある。したがって、ハッシュ出力の十分に長い部分を用いて、シグナリングオーバーヘッドを低減してもよい。一例として、ハッシュ出力の6オクテット部分は、ハッシュ出力全体の代わりに使用される。

説明のための例として、サブスクライバは、サービス名の切り捨てられたハッシュの1つのバージョン（たとえば、HASH−1）を含むサービスクエリメッセージを送信してもよく、パブリッシャが、ハッシュの一致を見出した場合、一致したサービス名の切り捨てられたハッシュの異なるバージョン（たとえば、HASH−2）をサービス応答内に含んで応答し、その信頼性を証明することを要求する。プライバシーまたはセキュリティが懸念されるサービスの場合、サービス名そのものが、意図された者の間のみで共有されるシークレットとして使用できるような方法で作られてもよい。サブスクライバは、複数の予め定められた選択肢の中から、切り捨てられたハッシュの特定のバージョンを要求してもよい。パブリッシャによって返信されたHASH−2が、サブスクライバによって知られているHASH−2と一致しない場合、パブリッシャの信頼性は確立されず、応答は破棄されてもよい。同様に、パブリッシャは、サブスクライバが、後続のクエリまたはフォローアップメッセージにおいて、要求されたサービス名の特定の、かつ異なるバージョンの切り捨てられたハッシュを使用するように要求してもよい。サブスクライバによって返信された切り捨てられたハッシュが、パブリッシャによって予期された（または既知の）ハッシュと一致しない場合、サブスクライバの信頼性は確立されず、さらなるサービスディスカバリの交換またはサブスクライバに対する一定のサービス情報の開示は許可されない。この目的のために、同じサービス名の切り捨てられたハッシュの異なるバージョンは、統計的に無相関であるべきである。本開示の態様は、2013年12月13日に提出された同時係属中の米国特許出願第14／105，895号に記載されており、その全体が再現されているかのように本明細書に援用される。同じ譲受人に譲渡された米国特許出願第14／105，895号に記載されているように、同じサービス名の切り捨てられたハッシュの異なるバージョンを生成する簡単な方法は、ハッシュ関数からの同じハッシュ出力の異なる、好ましくは重複しない部分を切り捨てることである。SHA−256ハッシュ関数のような良好な暗号特性を有するハッシュ関数を用いた場合には、同じサービス名のハッシュ出力の異なる、重複しない部分は、完全に無相関である。

SHA−256ハッシュ関数のハッシュ出力は長さ256ビットであるため、各サービスハッシュが長さ6オクテットである場合、5つの重複しない切り捨てられたハッシュ（異なるバージョンのサービスハッシュまたはサービスIDとして使用される）を生成することができる。これらの異なるバージョンのサービスハッシュは、シグナリングの目的で順次インデックスすることができる。たとえば、SHA−256ハッシュ関数のハッシュ出力の最初の6オクテット（たとえば0オクテットから5オクテット）は、サービス名の第1のサービスハッシュを形成し、バージョン番号1として索引付けされてもよく、SHA−256ハッシュ関数のハッシュ出力の次の6オクテット（たとえば6オクテットから11オクテット）は、同じサービス名の第2のサービスハッシュを形成し、バージョン番号2等としてインデックスされてもよい。SHA−256ハッシュ関数から生成することができる異なるバージョンの数を増加させるため、別の方法は、部分的に重複した切り捨てパターンを許容することである。たとえば、SHA−256ハッシュ関数のハッシュ出力の0ビットから47ビットは、サービス名の第1のサービスハッシュを形成し、バージョン番号1としてインデックスされてもよく、またSHA−256ハッシュ関数のハッシュ出力の1ビットから48ビットは、同じサービス名の第2のサービスハッシュを形成し、バージョン番号2等としてインデックス付けされてもよい。このようにして、SHA−256ハッシュ関数のハッシュ出力から、208通りの異なるバージョンのサービスハッシュを生成することができる。しかし、いくつかのバージョンは、何らかの形で互いに相関している。

シグナリングの目的のため、サブスクライバは、検索している各サービスのサービスクエリメッセージに、1つ以上のハッシュバージョン数フィールドを含んでもよく、少なくとも1つのハッシュバージョン数フィールドは、パブリッシャの信頼性を証明するために、パブリッシャが応答内で使用するようにサブスクライバが要求するハッシュバージョンを示す。サブスクライバが検索しているサービスに対するサービスクエリメッセージ内にサブスクライバが含めたサービスハッシュのハッシュバージョンを示すために、別のハッシュバージョン数フィールドが含まれてもよい。同様に、パブリッシャは、広告または応答している各サービスのサービス応答メッセージに、1つ以上のハッシュバージョン数フィールドを含んでもよく、たとえば、あるハッシュバージョン数フィールドは、パブリッシャがサービス応答メッセージに含めたサービスハッシュのハッシュバージョンを示し、また別のハッシュバージョン数フィールドは、サブスクライバの信頼性を証明するために、後続のクエリまたはフォローアップメッセージにおいて、サブスクライバが使用するようにパブリッシャが要求するハッシュバージョンを示す。

図6Aは、プレアソシエーションサービスディスカバリを行っているサブスクライバに発生している例示的な動作600のフロー図を示し、パラメータは、サービス応答メッセージ内で一致したサービスを表すために使用される識別子を生成するのに使用される、ハッシュ出力の一部を示す。動作600は、サブスクライバが、パブリッシャと安全なプレアソシエーションサービスディスカバリを行う際に、サブスクライバに発生している動作を示してもよく、パラメータは、サービス応答メッセージ内で一致したサービスを表すために使用される識別子を生成するのに使用される、ハッシュ出力の一部を示す。パラメータは、サブスクライバによって使用され、サービス応答メッセージに含まれた識別子である、チャレンジへのパブリッシャの応答を通して、パブリッシャの信頼性を検証するために、パブリッシャへのチャレンジが生成される。

動作600は、サブスクライバが探しているサービスのサービス名の第1の識別子をサブスクライバが生成することから開始されてもよい（ブロック605）。第1の識別子のような識別子は、SHA−256のようなハッシュ関数を、サブスクライバが探しているサービスのサービス名、すなわちservice＿name＿subscriberのようなサービス名に適用することによって生成された、ハッシュ出力の切り捨てられた部分であってもよい。簡略化のために、第1の識別子は、ハッシュ出力の最初の6オクテット（すなわち0オクテットから5オクテット）のような予め定められた部分であってもよい。サブスクライバは、パブリッシャに対して、第1の識別子およびパラメータを備えた、要求すなわちサービスクエリメッセージを送信してもよい（ブロック607）。パラメータは、パブリッシャによって第3の識別子を生成するのに使用される、ハッシュ出力の第1の切り捨てられた部分を示すために使用される。サブスクライバは、パラメータに基づいて、第2の識別子を生成してもよい（ブロック609）。説明のための例として、パラメータが3に等しい場合、第2の識別子は、ハッシュ関数をservice＿name＿subscriberに適用することによって生成された、ハッシュ出力の第3の6オクテット部分（たとえば12オクテットから17オクテット）である（また第3の識別子は、ハッシュ関数をパブリッシャによるservice＿name＿publisherに適用することによって生成された、ハッシュ出力の第3の6オクテット部分（たとえば12オクテットから17オクテット）である）。

サブスクライバは、パブリッシャから、第3の識別子を備えた応答すなわちサービス応答メッセージを受信してもよい（ブロック611）。第3の識別子は、パブリッシャが提供しているサービスのサービス名（すなわち、service＿name＿publisher）から、パブリッシャによって生成され、かつ、サブスクライバによって送信されたパラメータに基づいて生成される。サブスクライバは、第2の識別子が第3の識別子と一致するか否かを判定するチェックを行ってもよい（ブロック613）。第2の識別子が第3の識別子と一致する場合、応答は有効であり（ブロック615）、プレアソシエーションサービスディスカバリを完了してもよい。第2の識別子が第3の識別子と一致しない場合、応答は有効ではなく、プレアソシエーションサービスディスカバリは中断されるか、または、サブスクライバは別のパブリッシャとプレアソシエーションサービスディスカバリを繰り返してもよい。なお、応答は、ハッシュ関数をサービス名に適用することによって生成される、ハッシュ出力の第2の切り捨てられた部分を示している、第2のパラメータをさらに含み、サービス名の第4の識別子を生成するのに使用され、また、後続のサービスクエリまたはフォローアップメッセージに第4の識別子を含み、プライバシーに関わる可能性がある追加のサービス情報を取得するために、その信頼性を証明してもよい。次に、追加のサービス情報の受信を望んでいるサブスクライバは、第2のパラメータに基づいて（すなわちハッシュ出力の第2の切り捨てられた部分を用いて）、サービス名の第4の識別子を生成し、第4の識別子を含む後続のサービスクエリまたはフォローアップメッセージを送信する。結果として、サブスクライバは、パブリッシャから追加のサービス情報を含む第2の応答を受信することができる。

図6Bは、安全なプレアソシエーションサービスディスカバリを行っているパブリッシャに発生している例示的な動作650のフロー図を示し、パラメータは、一致したサービスをサービス応答メッセージ内で表すために使用される識別子を生成するのに使用される、ハッシュ出力の一部を示す。動作650は、パブリッシャが、サブスクライバと安全なプレアソシエーションサービスディスカバリを行う際に、パブリッシャに発生している動作を示してもよく、パラメータは、一致したサービスをサービス応答メッセージ内で表すために使用される識別子を生成するのに使用される、ハッシュ出力の一部を示す。パラメータは、サブスクライバによって使用され、サービス応答メッセージに含まれた識別子である、チャレンジへのパブリッシャの応答を通して、パブリッシャの信頼性を検証するために、パブリッシャへのチャレンジが生成される。

動作650は、パブリッシャが要求すなわちサービスクエリメッセージを受信することから開始されてもよい（ブロック655）。要求は、第1の識別子およびパラメータを含んでもよい。第1の識別子のような識別子は、SHA−256のようなハッシュ関数を、サブスクライバがシークしているサービスのサービス名（service＿name＿subscriber）のようなサービス名に適用するハッシュ出力の切り捨てられた部分であってもよい。パラメータは、第1の識別子とのハッシュ照合で一致したサービスが見出された場合に、一致したサービスを表すために応答内に含まれる、第3の識別子を生成するのに使用される、ハッシュ出力の第1の切り捨てられた部分を示すために使用される。パブリッシャは、SHA−256のようなハッシュ関数を、パブリッシャが提供するサービスのサービス名に適用するハッシュ出力の最初の6オクテット（すなわち0オクテットから5オクテット）のような、（第1の識別子と）同じ予め定められた切り捨てられた部分を用いて、第2の識別子を生成してもよい（ブロック656）。パブリッシャは、第1の識別子が第2の識別子と一致するか否かを判定するチェックを行ってもよい（ブロック657）。第1の識別子が第2の識別子と一致する場合、パブリッシャは、パラメータに基づいて第3の識別子を生成してもよい（ブロック659）。説明のための例として、第3の識別子は、ハッシュ出力のN番目の6オクテット部であり、Nはパラメータの値である。パブリッシャは、サブスクライバに、第3の識別子を含む応答すなわちサービス応答メッセージを送信してもよい（ブロック661）。パブリッシャは、応答に、サービスの使用状態、サービスの特定のパラメータまたは属性のような一致したサービスのサービス情報をさらに含んでもよい。パブリッシャは、サービスクエリに応答して、第2のパラメータをさらに含んでもよく、第2のパラメータは、サブスクライバがパブリッシャに送信する後続のサービスクエリまたはフォローアップメッセージ内で一致したサービスを表すために、サブスクライバが第4の識別子を生成する方法を示す。説明のための例として、第4の識別子は、ハッシュ出力のM番目の6オクテット部であり、Mは第2のパラメータの値である。第2のパラメータは、パブリッシャによって使用され、後続のサービスク
エリまたはフォローアップメッセージに含まれた第4の識別子である、チャレンジへのサブスクライバの応答を通して、サブスクライバの信頼性を検証するために、サブスクライバへのチャレンジが生成される。後続のサービスクエリまたはフォローアップメッセージにおいてサブスクライバが送信した第4の識別子が、パブリッシャが予期した識別子と一致する場合、パブリッシャは、プライバシーに関わる可能性がある、一致したサービスの追加のサービス情報を備えて返信してもよい。後続のサービスクエリまたはフォローアップメッセージの中でサブスクライバによって送信された第4の識別子が、パブリッシャが予期した識別子と一致しない場合、パブリッシャは、サブスクライバの信頼性が確立されていないとみなし、関連サービス情報のさらなる応答または開示を中断し、プレアソシエーションサービスディスカバリを終了してもよい。第1の識別子が、パブリッシャがブロック657で提供する任意のサービスの第2の識別子と一致しない場合、パブリッシャは、要求を満たすことができないとみなす。次に、パブリッシャは、サブスクライバに応答しないか、または否定応答を提供し、プレアソシエーションサービスディスカバリを終了してもよい。

この切り捨てベースのアプローチは、比較的単純である。しかし、ハッシュ出力は静的であり、限られた数の非重複切り捨てパターンが存在するため、忍耐強いハッカーは、攻撃を開始する前に、すべての異なるバージョンを収集するまで待機することができる。

例示的な実施形態によると、パラメータは、識別子を生成するために使用されるノンスである。ノンスは、ハッシュ関数に適用される前に、サービス名に連結されてもよい。ノンスは、ハッシュ関数に適用される前に、サービス名に追加されてもよい。共同譲渡され援用された米国特許出願第14／105，895号は、異なる文字列または値を使用することによって、同じサービス名から異なるサービスハッシュを生成するための方法および装置を記載している。

説明のための例として、サブスクライバは、サービス名の切り捨てられたハッシュ（たとえばHASH−1）の1つのバージョンを含むサービスクエリメッセージを送信して、サービスおよび1つ以上のランダム番号を識別してもよく、また、ハッシュの一致を見出した場合、パブリッシャの信頼性を証明するために、サービスの識別子として、サブスクライバによってパブリッシャに提供される乱数で生成される、一致したサービス名の切り捨てられたハッシュ（たとえばHASH−3）を用いて応答することをパブリッシャに要求する。パブリッシャによって返信されたHASH−3がサブスクライバに知られているHASH−3と一致しない場合、パブリッシャの信頼性が確立されず、応答は破棄されてもよい。同様に、パブリッシャは、パブリッシャによってサブスクライバに提供された乱数から生成される、要求されたサービス名の切り捨てられたハッシュを用いて、後続のクエリまたはフォローアップメッセージ内で一致したサービスを表すことを、サブスクライバに要求してもよい。サブスクライバによって返信された切り捨てられたハッシュが、パブリッシャが予期したハッシュと一致しない場合、サブスクライバの信頼性は確立されず、サブスクライバとのさらなるサービスディスカバリの交換、またはサブスクライバへの特定のサービス情報の開示は許可されない。

上記のように、ハッカーは、正規のサブスクライバおよびパブリッシャによって送信されるサービス識別子、およびこれらの識別子を生成するのに使用されるパラメータを、盗聴によって収集することができ、その後、収集した識別子およびパラメータをリプレイして、正規のサブスクライバまたはパブリッシャのふりをする。これに対抗するため、正規のサブスクライバおよびパブリッシャは、相手に異なるノンスを提供し、そのノンスを用いて、後続のメッセージ内でサービスの異なる識別子を生成するように、相手に求めることにより、各サービスディスカバリメッセージ交換において、互いにチャレンジを続けることが完全に可能である。たとえば、サブスクライバはまず、シークされたサービスの識別子I1と、I1を生成するのに使用されたノンスN1と、パブリッシャへのチャレンジを生成するのに使用されるノンスN2とを備えた、メッセージM1を送信する。パブリッシャが一致したサービスを見出す場合、パブリッシャは、N2に基づいて生成される一致したサービスの識別子I2と、サブスクライバへのチャレンジを生成するのに使用されるノンスN3とを備えた、メッセージM2を送信する。サブスクライバは、M2で受信するI2が予期するものと一致すると判定する場合、サブスクライバは、N3に基づいて生成される一致したサービスの識別子I3と、パブリッシャへの別のチャレンジを生成するのに使用されるノンスN4とを備えた、メッセージM3を送信する。パブリッシャは、M3で受信するI3が予期するものと一致すると判定する場合、パブリッシャは、N4に基づいて生成される一致したサービスの識別子I4と、サブスクライバへのさらに別のチャレンジを生成するのに使用されるノンスN5とを備えた、メッセージM4を送信する。すべてのサービスディスカバリメッセージ交換が完了するまで、処理を継続することができる。ノンス値空間のサイズが十分に大きい場合には、サブスクライバまたはパブリッシャによって生成されたこれらのノンス値は、互いに繰り返されることはない。

例示的な本実施例では、乱数（すなわちノンス）は、生成することができる切り捨てられたハッシュの違いに、より大きなダイナミクスを提供する。SHA−256ハッシュ関数のような良好な暗号特性を有するハッシュ関数が使用される場合、2つの乱数の間のわずかな差でさえも2つの無相関ハッシュ出力を生成する。またこの場合、単一の切り捨て関数を用いるとしても、2つの切り捨てられたハッシュは高度に無相関である。各ステップで成功裏にチャレンジに解答するための多くの識別子および関連する乱数を収集し記憶することは、ハッカーにとってほぼ不可能であるため、このチャレンジと応答のアプローチは、リプレイ攻撃に対してより堅牢性が高い。そのため、および所望のセキュリティおよびプライバシーの観点から、サービス名の識別子を生成する際に乱数（すなわちノンス）を用いた手法を用いることが好ましい。しかし、局がリアルタイムでハッシュアルゴリズムを実行する必要もあり、応答局は一般的にチャレンジャー局に比べてハッシュを計算するために有する時間が短いため、特に応答局にとって、計算的に要求度が高い。

図7Aは、安全なプレアソシエーションサービスディスカバリを行っているサブスクライバに発生している、例示的な動作700のフロー図を示し、パラメータは1つ以上の乱数（ノンス）を備える。動作700は、サブスクライバがパブリッシャと安全なプレアソシエーションサービスディスカバリを行う際に、サブスクライバに発生している動作を示してもよく、パラメータは1つ以上の乱数（ノンス）を備える。

動作700は、サブスクライバが探しているサービスのサービス名の第1の識別子をサブスクライバが生成することから開始されてもよい（ブロック705）。第1の識別子は、SHA−256のようなハッシュ関数を、サブスクライバが探しているサービスのサービス名すなわちservice＿name＿subscriberに適用することによって生成された、ハッシュ出力の最初の6オクテットのような予め定められた切り捨てられた部分であってもよい。あるいは、第1の識別子は、SHA−256のようなハッシュ関数を、第1のノンスと、サブスクライバが探しているサービスのサービス名すなわちservice＿name＿subscriberとの（追加、連結等を通して）組み合わされたサービス名に適用することによって生成された、ハッシュ出力の最初の6オクテットのような予め定められた切り捨てられた部分であってもよい。後続のサービスディスカバリメッセージ交換に使用される識別子は、SHA−256のようなハッシュ関数を、ノンスおよびサービス名の（追加、連結等を通して）組み合わされたサービス名に適用することによって生成された、ハッシュ出力の最初の6オクテットのような予め定められた切り捨てられた部分であってもよい。サブスクライバは、パブリッシャに対して、第1の識別子、第1の識別子を生成するのに使用される場合に限り第1のノンスを含むパラメータ、および第2のノンスを備えた、要求すなわちサービスクエリメッセージを送信してもよい（ブロック707）。第1の識別子を生成するのに使用される場合、第1のノンスもパブリッシャに提供され、第1の識別子とのハッシュ照合に使用される識別子が生成される。第2のノンスは、シークされたサービスの第2の識別子をサブスクライバが生成するのに使用され、また、一致したサービスを応答すなわちサービス応答メッセージ内で表すために、一致したサービスがあればその第3の識別子を生成するために、パブリッシャに提供される。サブスクライバは、パラメータの第2のノンスに基づいて第2の識別子を生成してもよい（ブロック709）。説明のための例として、第2のノンスが3に等しい場合、第2の識別子は、第2のノンス「3」をservice＿name＿subscriberと組み合わせ（たとえば追加、連結等）、組み合わせたサービス名にハッシュ関数を適
用することによって生成される。簡略化のために、第2の識別子は、ハッシュ出力の最初の6オクテットのような、ハッシュ出力の第1の識別子と同じ予め定められた切り捨てられた部分を使用してもよい。

サブスクライバは、パブリッシャから、第3の識別子を備えた応答すなわちサービス応答メッセージを受信してもよい（ブロック711）。第3の識別子は、パブリッシャが提供しているサービスのサービス名（すなわちservice＿name＿publisher）から、パブリッシャによって生成され、かつ、サブスクライバによって送信されたパラメータの第2のノンスに基づいて生成される。第3の識別子は、ハッシュ出力の最初の6オクテットのような、第1の識別子が使用したものと同じハッシュ出力の予め定められた切り捨てられた部分を使用してもよい。サブスクライバは、第2の識別子が、第3の識別子と一致するか否かを判定するチェックを行ってもよい（ブロック713）。第2の識別子が第3の識別子と一致する場合、応答は有効であり（ブロック615）、プレアソシエーションサービスディスカバリを完了してもよい。第2の識別子が第3の識別子と一致しない場合、応答は有効ではなく、プレアソシエーションサービスディスカバリは中断されるか、または、サブスクライバは別のパブリッシャとプレアソシエーションサービスディスカバリを繰り返してもよい。なお、応答は、サブスクライバが、第2のパラメータに基づいて第4の識別子を生成し、また第4の識別子を用いて一致したサービスを後続のサービスクエリまたはフォローアップメッセージ内で表し、プライバシーに関わる可能性がある追加のサービス情報を取得するためにその信頼性を証明するように指示する、第2のパラメータをさらに含んでもよい。説明のための例として、第2のパラメータは、第4の識別子を生成するのに使用される第3の乱数（第3のノンス）を示している。次に、追加のサービス情報の受信を望んでいるサブスクライバは、受信した第2のパラメータに基づいて、サービス名の第4の識別子を生成し、第4の識別子を含む後続のサービスクエリまたはフォローアップメッセージを送信する。結果として、サブスクライバは、パブリッシャからの追加のサービス情報を含む第2の応答を受信してもよく、プレアソシエーションサービスディスカバリを完了してもよい。

図7Bは、安全なプレアソシエーションサービスディスカバリを行っているパブリッシャに発生している例示的な動作750のフロー図を示し、パラメータは1つ以上の乱数（ノンス）を備える。動作750は、パブリッシャがサブスクライバと安全なプレアソシエーションサービスディスカバリを行う際に、パブリッシャに発生している動作を示してもよく、パラメータは1つ以上の乱数（ノンス）を備える。

動作750は、パブリッシャが要求すなわちサービスクエリメッセージを受信することから開始されてもよい（ブロック755）。要求は、第1の識別子およびパラメータを含んでもよい。パラメータは、第1の識別子を生成するのに使用される場合に限り第1のノンスと、第2のノンスとを含んでもよい。第1の識別子は、SHA−256のようなハッシュ関数を、サブスクライバが探しているサービスのサービス名すなわちservice＿name＿subscriberに適用することによって生成された、ハッシュ出力の最初の6オクテットのような予め定められた切り捨てられた部分であってもよい。あるいは、第1の識別子は、SHA−256のようなハッシュ関数を、第1のノンスと、サブスクライバが探しているサービスのサービス名すなわちservice＿name＿subscriberとの（追加、連結等を通して）組み合わされたサービス名に適用することによって生成された、ハッシュ出力の最初の6オクテットのような予め定められた切り捨てられた部分であってもよい。後続のサービスディスカバリメッセージ交換に使用される識別子は、SHA−256のようなハッシュ関数を、ノンスとサービス名との（追加、連結等を通して）組み合わされたサービス名に適用したハッシュ出力の切り捨てられた部分であってもよい。第1のノンスは、サブスクライバが第1の識別子を生成するのに使用する場合、パブリッシャが、第1の識別子とのハッシュ照合に使用される、第2の識別子を生成するのにも使用される。第2のノンスは、一致したサービスを応答すなわちサービス応答メッセージ内で表すために、一致したサービスがあればその第3の識別子を生成するために使用される。パブリッシャは、SHA−256のようなハッシュ関数を、パブリッシャが提供するサービスのサービス名に適用するハッシュ出力の最初の6オクテット（すなわち0オクテットから5オクテット）のような、（第1の識別子が使用するものと）同じ、予め定められた切り捨てられた部分を用いて、第2の識別子を生成してもよい（ブロック756）。あるいは、第1のノンスが、サブスクライバが第1の識別子を生成するのに使用され、要求の中でパブリッシャに提供される場合、パブリッシャは、SHA−256のようなハッシュ関数を、第1のノンスと、パブリッシャが提供するサービスのサービ
ス名すなわちservice＿name＿publisherとの（追加、連結等を通して）組み合わされたサービス名に適用するハッシュ出力の、最初の6オクテット（すなわち0オクテットから5オクテット）のような、（第1の識別子と）同じ予め定められた切り捨てられた部分を用いて、第2の識別子を生成してもよい。パブリッシャは、第1の識別子が第2の識別子と一致するか否かを判定するチェックを行ってもよい（ブロック757）。第1の識別子が第2の識別子と一致している場合、パブリッシャは第2のノンスに基づいて、第3の識別子を生成してもよい（ブロック759）。説明のための例として、第3の識別子は、service＿name＿publisherと第2のノンスとを組み合わせたハッシュ出力の切り捨てられた部分である。第3の識別子は、ハッシュ出力の最初の6オクテットのような、第1の識別子および第2の識別子が使用したものと同じ、ハッシュ出力の予め定められた切り捨てられた部分を用いてもよい。パブリッシャは、サブスクライバに対して、第3の識別子を含む応答すなわちサービス応答メッセージを送信してもよい（ブロック761）。パブリッシャは、応答に、サービスの使用状態、サービスの特定のパラメータまたは属性のような一致したサービスのサービス情報をさらに含んでもよい。パブリッシャは、サービスクエリへの応答に、第3のノンスをさらに含んでもよい。第3のノンスは、サブスクライバに提供され、サブスクライバがパブリッシャに送信する後続のサービスクエリまたはフォローアップメッセージ内で、一致したサービスを表す第4の識別子が生成される。第3のノンスは、パブリッシャによって使用され、後続のサービスクエリまたはフォローアップメッセージに含まれた第4の識別子である、チャレンジへのサブスクライバの応答を通して、サブスクライバの信頼性を検証するために、サブスクライバへのチャレンジが生成される。サブスクライバによって送信された後続のサービスクエリまたはフォローアップメッセージ内の第4の識別子が、パブリッシャが予期した識別子と一致する場合、パブリッシャは、プライバシーに関わる可能性のある追加のサービス情報を備えて応答してもよい。後続のサービスクエリまたはフォローアップメッセージの中でサブスクライバによって送信された第4の識別子が、パブリッシャが予期
した識別子と一致しない場合、パブリッシャは、サブスクライバの信頼性が確立されていないとみなし、関連サービス情報のさらなる応答または開示を中断し、プレアソシエーションサービスディスカバリを終了してもよい。第1の識別子が、パブリッシャがブロック757で提供する任意のサービスの第2の識別子と一致しない場合、パブリッシャは、要求を満たすことができないとみなす。次に、パブリッシャは、サブスクライバに応答しないか、または否定応答を提供し、プレアソシエーションサービスディスカバリを終了してもよい。

例示的な実施形態によれば、サブスクライバのプライバシーは、プレアソシエーションサービスディスカバリを実行する前に、パブリッシャと（IEEE 802．11ai FILS認証のような）高速認証を行うことによって保護される。高速認証は、アソシエーションまたはアドレス割り当てを必要としないため、遅延を低減することができる。高速認証は、キーの確立をもたらし、これを用いてサービス名を保護することができる。

図8は、高速認証およびプレアソシエーションサービスディスカバリを強調している、メッセージ交換図800を示す。メッセージ交換図800は、局805、AP810、トラステッドサードパーティ815、サービストランザクションプロキシ820の間で交換されるメッセージを示す。

局805はまず、AP810から送信されたビーコンフレームの受動的な監視を通して、AP810の認証ポリシーを発見する（イベント830として示す）。あるいは、局805は、能動的なプロービングを用いて、プローブ要求を送信し、結果としてプローブ応答を受信することによって、AP810の認証ポリシーを発見してもよい。なお、プローブ要求メッセージおよびプローブ応答メッセージは、図8に示されていない。AP810の認証ポリシーが、AP810が高速認証をサポートすることを示す場合、たとえば、AP810は認証のため相互のトラステッドサードパーティ815に接続し、その後、局805が、AP810に対して、認証情報（たとえばFILS認証情報）を備えた認証フレームを送信することによって、高速認証を開始する（イベント832として示す）。AP810は、FILS認証情報をトラステッドサードパーティ815に転送する（イベント834として示す）。トラステッドサードパーティ815からの応答を受信すると（イベント836として示す）、AP810は、認証情報を備えた認証フレームを備えて局805に応答する（イベント838として示す）。イベント832〜イベント838に示すメッセージの交換の結果として、局805およびAP810は、2つ1組のマスターキー（PMK）を生成する。

局805は、探しているサービスのサービス識別子と、正しいPMKの保持証明とを含むサービスディスカバリクエリフレームを、AP810に送信する（イベント840として示す）。AP810は、キーの確認を行う（ブロック842）。キーの確認が成功した場合、AP810は、サービストランザクションプロキシ820にサービスクエリを転送する（イベント844として示す）。また、キーの確認が成功しなかった場合、AP810はサービスディスカバリクエリを破棄してもよい。サービストランザクションプロキシ820からの応答を受信すると（イベント846として示す）、AP810は、サービストランザクションプロキシ820から受信したサービス情報を備えて、STA805にサービスディスカバリ応答フレームを返信する（イベント848として示す）。AP810は、サービスディスカバリ応答フレーム内に、PMKの保持証明も含む。局805は、キーの確認を実行する（ブロック850）。キーの確認が成功した場合、局805は、サービスディスカバリ応答をさらに処理する。キーの確認が成功しなかった場合、局805は、サービスディスカバリ応答を破棄してもよい。

高速認証のためのツーウェイハンドシェイクメッセージは、GAS要求およびGAS応答フレームのようないくつかのパブリックアクションフレームを用いて、初期サービスクエリおよびサービス応答内で搬送することもできる。802．11aiと同様に、キーの確立は、認証フレーム中に行われ、キーの確認は、後続のサービスクエリおよびサービス応答フレーム中に行われる。確立された共有のシークレットキーを用いて、サービスディスカバリクエリおよびサービスディスカバリ応答メッセージのコンテンツを暗号化によって保護することができる。パブリッシャ（たとえばAP810）は、サービスディスカバリクエリフレームでキーの確認を行い成功するまで、サービスディスカバリクエリに応答しない。サブスクライバ（たとえば局805）は、サービスディスカバリ応答フレームでキーの確認を行い成功するまで、サービスディスカバリ応答を有効なものとして許容しない。

図9Aは、高速認証およびプレアソシエーションサービスディスカバリに参加しているサブスクライバに発生している、例示的な動作900のフロー図を示す。動作900は、サブスクライバが高速認証およびプレアソシエーションサービスディスカバリに参加する際に、サブスクライバに発生している動作を示してもよい。

動作900は、パブリッシャが高速認証をサポートすることをサブスクライバが発見した後、サブスクライバが、パブリッシャに認証情報を備えた第1の認証フレームを送信することから開始されてもよい（ブロック905）。認証情報は、FILS認証情報の形式であってもよい。サブスクライバは、パブリッシャから、認証情報を備えた第2の認証フレームを受信してもよい（ブロック907）。認証フレームの交換によって、PMKが生成される。サブスクライバは、サービス識別子およびPMK証明を備えたサービスディスカバリクエリを送信する（ブロック909）。サブスクライバは、サービス情報およびPMK証明を備えたサービスディスカバリ応答を受信する（ブロック911）。サブスクライバは、キーの確認を行う（ブロック913）。キーの確認が成功した場合、サブスクライバは、サービスディスカバリ応答を処理する（ブロック915）。キーの確認が失敗した場合、サブスクライバは、サービスディスカバリ応答を破棄する（ブロック917）。

図9Bは、高速認証およびプレアソシエーションサービスディスカバリに参加しているパブリッシャに発生している、例示的な動作950のフロー図を示す。動作950は、パブリッシャが高速認証およびプレアソシエーションサービスディスカバリに参加する際に、パブリッシャに発生している動作を示してもよい。

パブリッシャはサブスクライバから認証情報を備えた第1の認証フレームを受信する（ブロック955）。認証情報は、FILS認証情報の形式であってもよい。パブリッシャは、トラステッドサードパーティに認証情報を送信する（ブロック957）。パブリッシャは、トラステッドサードパーティからの応答を受信し（ブロック959）、認証情報を含む第2の認証フレームをサブスクライバに送信する（ブロック961）。認証フレームの交換によって、PMKが生成される。パブリッシャは、サブスクライバから、サービス識別子およびPMK証明を備えた、サービスディスカバリクエリを受信する（ブロック963）。パブリッシャは、キーの確認を行う（ブロック965）。キーの確認が成功した場合、パブリッシャは、STPにクエリを送信し（ブロック967）、STPからの応答を受信する（ブロック969）。パブリッシャは、サービス情報およびPMK証明を含むサービスディスカバリ応答を、サブスクライバに送信する（ブロック971）。キーの確認に失敗した場合、サブスクライバは、サービスディスカバリクエリを破棄する（ブロック973）。

図10は、本明細書に開示されたデバイスおよび方法を実施するために使用することができる、処理システム1000のブロック図である。特定のデバイスは、示されたすべてのコンポーネント、またはコンポーネントのサブセットのみを利用してもよく、統合のレベルはデバイス毎に異なる場合がある。さらに、デバイスは、複数の処理ユニット、プロセッサ、メモリ、送信機、受信機のような複数のインスタンスを含んでもよい。処理システムは、処理ユニット1005を含んでもよい。処理ユニット1005は、ヒューマンインターフェース部1015（たとえばスピーカ、マイクロフォン、マウス、タッチスクリーン、キーパッド、キーボード、プリンタ等を含む）、ディスプレイ1010等のような1つ以上の入力／出力デバイスを具備してもよい。処理ユニットは、中央処理装置（CPU）1020、メモリ1025、大容量記憶装置1030、ビデオアダプタ1035、およびバス1045に接続されたI／Oインターフェース1040を含んでもよい。

バスは、メモリバス、メモリコントローラ、周辺バス、ビデオバス等を含む、任意のタイプのいくつかのバスアーキテクチャのうちの1つ以上であってもよい。CPUは、任意のタイプの電子データプロセッサを含んでもよい。メモリは、スタティック・ランダム・アクセス・メモリ（SRAM）、ダイナミック・ランダム・アクセス・メモリ（DRAM）、同期DRAM（SDRAM）、読出し専用メモリ（ROM）、これらの組み合わせ等のような任意のタイプのシステムメモリを含んでもよい。実施形態では、メモリは、ブートアップ時に使用するためのROM、プログラム用のDRAM、およびプログラム実行中に使用するためのデータ記憶装置を含んでもよい。

大容量記憶装置は、データ、プログラム、および他の情報を格納するように構成され、かつバスを通して、データ、プログラム、および他の情報をアクセス可能にするように構成された、任意のタイプの記憶装置を備えていてもよい。大容量記憶装置は、たとえば、ソリッドステートドライブ、ハードディスクドライブ、磁気ディスクドライブ、光ディスクドライブ等のうちの1つ以上を備えていてもよい。

ビデオアダプタおよびI／Oインターフェースは、外部入出力装置を処理ユニットに結合するためのインターフェースを提供する。図示されるように、入出力デバイスの例として、ビデオアダプタに接続されたディスプレイ、I／Oインターフェースに接続されたマウス／キーボード／プリンタが挙げられる。他のデバイスを処理ユニットに接続してもよく、追加のまたはより少数のインターフェースカードを利用してもよい。たとえば、ユニバーサルシリアルバス（USB）のようなシリアルインターフェース（図示せず）を用いて、プリンタのためのインターフェースを提供してもよい。

処理ユニットは、また、1つ以上のネットワークインターフェース1050を含み、ネットワークインターフェース1050は、ノードまたは異なるネットワーク1055にアクセスするための、イーサネット（登録商標）ケーブル等の有線リンクおよび／または無線リンクを備えていてもよい。ネットワークインターフェースは、処理ユニットがネットワークを介して遠隔装置と通信することを可能にする。たとえば、ネットワークインターフェースは、1つ以上の送信機／送信アンテナ、および
1つ以上の受信機／受信アンテナを介して、無線通信を提供してもよい。実施形態では、処理ユニットは、ローカルエリアネットワークまたはワイドエリアネットワークに接続されて、データ処理、および他の処理ユニット、インターネット、リモートストレージファシリティのような遠隔装置との通信を行う。

本実施形態とその利点を詳細に説明してきたが、様々な変更、置換および修正は、添付の特許請求の範囲によって定義される本開示の精神および範囲から逸脱することなく行うことができることを理解されたい。

100 通信システム
105 STA1
110 STA2
200 メッセージ交換図
205 デバイスA
207 サービス層
209 ASP層
215 デバイスB
217 サービス層
219 ASP層
221 MAC層
300 通信システム
305 NANデバイス
307 アプリケーション
309 ディスカバリエンジン
311 MAC層
315 NANデバイス
317 アプリケーション
321 MAC層
325 物理層
400 通信システム
410 AP1
415 STP
420 ローカルエリアネットワーク
425 ネットワーク
800 メッセージ交換図
805 局
810 AP
815 トラステッドサードパーティ
820 サービストランザクションプロキシ
1000 処理システム
1005 処理ユニット
1010 ディスプレイ
1015 ヒューマンインターフェース部
1020 中央処理装置（CPU）
1025 メモリ
1030 大容量記憶装置、
1035 ビデオアダプタ
1040 I／Oインターフェース
1045 バス
1050 ネットワークインターフェース
1055 ネットワーク

Claims (22)

1. サービスを発見する際の局の動作方法であって、
   前記局によって、前記サービスの第1の識別子を生成するステップと、
   前記局によって、第1のパラメータに基づいて、前記サービスの第2の識別子を生成するステップと、
   前記局によって、第3の識別子の生成を指示する要求を送信するステップであって、前記要求は、前記サービスの前記第1の識別子および前記第1のパラメータを含む、ステップと、
   前記局によって、前記第3の識別子を含む第1の応答を受信するステップと、
   前記第2の識別子および前記第3の識別子が等しくない場合、前記局によって前記第1の応答が有効でないと判定するステップと、
   前記第2の識別子および前記第3の識別子が等しい場合、前記局によって前記第1の応答が有効であると判定するステップと
   を備え、
   前記第1の識別子は、第1の方法に基づいて生成され、前記第2の識別子は、第2の方法に基づいて生成され、前記第1のパラメータは、前記第2の方法に基づいて前記第3の識別子が生成されるように指示し、
   前記第1の方法に基づいて前記第1の識別子を生成するステップは、
   ハッシュ関数を用いて、前記サービスのサービス名をハッシュすることによって、ハッシュ出力を生成するステップと、
   前記ハッシュ出力の第1の部分を切り捨てて前記第1の識別子を生成するステップと
   を備え、前記第2の方法に基づいて前記第2の識別子を生成するステップは、
   前記ハッシュ出力の第2の部分を切り捨てて前記第2の識別子を生成するステップ
   を備える、方法。
2. 前記サービスの前記第2の識別子を生成するステップは、前記ハッシュ関数を用いて、前記サービスの前記サービス名をハッシュすることをさらに備える、請求項1に記載の方法。
3. 前記第1の応答は、前記サービスのサービス情報をさらに含む、請求項1に記載の方法。
4. 前記第1の応答は、前記サービスの第4の識別子、および第3の方法に基づいて前記第4の識別子の生成を指示する第2のパラメータに対する要求をさらに含み、前記方法は、
   前記ハッシュ出力の第3の部分を切り捨てて前記サービスの前記第4の識別子を生成することによって、前記第3の方法に基づいて前記サービスの前記第4の識別子を生成するステップと、
   前記第4の識別子を含む第2の応答を送信するステップと、
   前記サービスのサービス情報を含む第3の応答を受信するステップと
   をさらに備える、請求項1に記載の方法。
5. 前記第1のパラメータは、前記第3の識別子および前記第2の識別子を生成するのに使用される第1のノンス値を含み、前記第2の識別子を生成するステップは、
   前記第1のノンス値と、前記サービスのサービス名とを組み合わせて、第1の変更されたサービス名を生成するステップであって、前記第1のノンス値と前記サービス名とを組み合わせる前記ステップは、前記第1のノンス値を表すストリングを前記サービス名に連結するステップと、前記サービス名を表す値および前記第1のノンス値に数学的関数を適用するステップとのいずれかを備える、ステップと、
   ハッシュ関数を用いて前記第1の変更されたサービス名をハッシュすることによって、第1のハッシュ出力を生成するステップと、
   前記第1のハッシュ出力の予め定められた部分を切り捨てて前記第2の識別子を生成するステップと
   を備える、請求項1に記載の方法。
6. 前記第1のパラメータは、前記第1の識別子を生成するのに使用される第2のノンス値をさらに含み、前記第1の識別子を生成するステップは、
   前記第2のノンス値と、前記サービスの前記サービス名とを組み合わせて、第2の変更されたサービス名を生成するステップと、
   前記ハッシュ関数を用いて、前記第2の変更されたサービス名をハッシュすることによって、第2のハッシュ出力を生成するステップと、
   前記第2のハッシュ出力の前記予め定められた部分を切り捨てて前記第1の識別子を生成するステップと
   を備える、請求項5に記載の方法。
7. 前記第1の識別子を生成するステップは、
   前記ハッシュ関数を用いて、前記サービス名をハッシュすることによって、第3のハッシュ出力を生成するステップと、
   前記第3のハッシュ出力の前記予め定められた部分を切り捨てて前記第1の識別子を生成するステップと
   を備える、請求項5に記載の方法。
8. 前記第1の応答は、前記サービスのサービス情報をさらに含む、請求項5に記載の方法。
9. 前記第1の応答は、前記サービスの第4の識別子、および前記第4の識別子を生成するのに使用される第3のノンス値に対する要求をさらに含み、前記方法は、
   前記第3のノンス値に基づいて、前記サービスの前記第4の識別子を生成するステップと、
   前記第4の識別子を含む第2の応答を送信するステップと、
   前記サービスのサービス情報を含む第3の応答を受信するステップと
   をさらに備える、請求項5に記載の方法。
10. 前記サービスの前記第4の識別子を生成するステップは、
    前記第3のノンス値と、前記サービスの前記サービス名とを組み合わせて、第3の変更されたサービス名を生成するステップと、
    前記ハッシュ関数を用いて前記第3の変更されたサービス名をハッシュすることによって、第4のハッシュ出力を生成するステップと、
    前記第4のハッシュ出力の前記予め定められた部分を切り捨てて前記第4の識別子を生成するステップと
    を備える、請求項9に記載の方法。
11. サービスを発見するように適合された局であって、前記局は、
    前記サービスの第1の識別子を生成し、前記サービスの第2の識別子を生成するように構成された処理ユニットであって、前記第2の識別子は、第1のパラメータに基づいて生成され、前記第2の識別子および第3の識別子が等しくない場合には第1の応答が有効でないと判定し、前記第2の識別子および前記第3の識別子が等しい場合には前記第1の応答が有効であると判定する、処理ユニットと、
    前記処理ユニットに動作可能に結合され、前記第3の識別子の生成を指示する要求を送信するように構成された送信機であって、前記要求は、前記サービスの前記第1の識別子および前記第1のパラメータを含む、送信機と、
    前記処理ユニットに動作可能に結合され、前記第3の識別子を含む前記第1の識別子を受信するように構成された受信機と
    を備え、
    前記第1の識別子は、第1の方法に基づいて生成され、前記第2の識別子は、第2の方法に基づいて生成され、前記第1のパラメータは、前記第2の方法に基づいて前記第3の識別子が生成されるように指示し、
    前記第1の方法に基づいて前記第1の識別子を生成することは、
    ハッシュ関数を用いて、前記サービスのサービス名をハッシュすることによって、ハッシュ出力を生成することと、
    前記ハッシュ出力の第1の部分を切り捨てて前記第1の識別子を生成することと
    を備え、前記第2の方法に基づいて前記第2の識別子を生成することは、
    前記ハッシュ出力の第2の部分を切り捨てて前記第2の識別子を生成すること
    を備える、局。
12. サービスを広告する際の局の動作方法であって、前記方法は、
    前記局によって、第1の識別子および第1のパラメータを含む要求を受信するステップと、
    前記局によって、前記サービスの第2の識別子を生成するステップと、
    前記局によって前記第1の識別子および前記第2の識別子が等しいと判定された場合、
    前記局によって、前記第1のパラメータに基づいて、前記サービスの第3の識別子を生成し、
    前記局によって、前記サービスの前記第3の識別子を含む第1の応答を送信するステップと
    を備え、
    前記第1の識別子は、第1の方法に基づいて生成され、前記第2の識別子は、第2の方法に基づいて生成され、前記第1のパラメータは、前記第2の方法に基づいて前記第3の識別子が生成されるように指示し、
    前記第1の方法に基づいて前記第1の識別子を生成することは、
    ハッシュ関数を用いて、前記サービスのサービス名をハッシュすることによって、ハッシュ出力を生成することと、
    前記ハッシュ出力の第1の部分を切り捨てて前記第1の識別子を生成することと
    を備え、前記第2の方法に基づいて前記第2の識別子を生成することは、
    前記ハッシュ出力の第2の部分を切り捨てて前記第2の識別子を生成すること
    を備える、方法。
13. 前記第1の応答は、前記サービスのサービス情報をさらに含む、請求項12に記載の方法。
14. 前記第1の識別子および前記第2の識別子は、第1の方法に基づいて生成され、前記第3の識別子は、第2の方法に基づいて生成され、前記第1のパラメータは、前記第3の識別子を前記第2の方法に基づいて生成するように指示する、請求項12に記載の方法。
15. 前記第1の方法に基づいて前記第2の識別子を生成するステップは、
    ハッシュ関数を用いて前記サービスのサービス名をハッシュすることによって、ハッシュ出力を生成するステップと、
    前記ハッシュ出力の第1の部分を切り捨てて前記第2の識別子を生成するステップと
    を備え、前記第2の方法に基づいて前記第3の識別子を生成するステップは、
    前記ハッシュ出力の第2の部分を切り捨てて前記第3の識別子を生成するステップを含む、
    請求項14に記載の方法。
16. 前記第1の応答は、第4の識別子、および第3の方法に基づいて前記第4の識別子の生成を指示する第2のパラメータに対する要求をさらに含み、前記方法は、
    前記ハッシュ出力の第3の部分を切り捨てて前記サービスの第5の識別子を生成することによって、前記第3の方法に基づいて前記サービスの前記第5の識別子を生成するステップと、
    前記第4の識別子を含む第2の応答を受信するステップと、
    前記第4および前記第5の識別子が等しいという判定に応じて、前記サービスのサービス情報を含む第3の応答を送信するステップと
    をさらに備える、請求項15に記載の方法。
17. 前記第1のパラメータは、前記第3の識別子を生成するのに使用される第1のノンス値を備え、前記第3の識別子を生成するステップは、
    前記第1のノンス値を表すストリングを前記サービス名に連結するステップと、前記サービス名を表す値および前記第1のノンス値に数学的関数を適用するステップとのいずれかによって、前記第1のノンス値と前記サービスのサービス名とを組み合わせて、第1の変更されたサービス名を生成するステップと、
    ハッシュ関数を用いて前記第1の変更されたサービス名をハッシュすることによって、第1のハッシュ出力を生成するステップと、
    前記第1のハッシュ出力の予め定められた部分を切り捨てて前記第3の識別子を生成するステップと
    を備える、請求項12に記載の方法。
18. 前記第1のパラメータは、前記第2の識別子を生成するのに使用される第2のノンス値をさらに含み、前記第2の識別子を生成するステップは、
    前記第2のノンス値と前記サービスの前記サービス名とを組み合わせて、第2の変更されたサービス名を生成するステップと、
    前記ハッシュ関数を用いて前記第2の変更されたサービス名をハッシュすることによって、第2のハッシュ出力を生成するステップと、
    前記第2のハッシュ出力の前記予め定められた部分を切り捨てて前記第2の識別子を生成するステップと
    を備える、請求項17に記載の方法。
19. 前記第2の識別子を生成するステップは、
    前記ハッシュ関数を用いて前記サービス名をハッシュすることによって、第3のハッシュ出力を生成するステップと、
    前記第3のハッシュ出力の前記予め定められた部分を切り捨てて前記第2の識別子を生成するステップと
    を備える、請求項17に記載の方法。
20. 前記第1の応答は、前記サービスの第4の識別子、および前記第4の識別子を生成するのに使用される第3のノンス値に対する要求をさらに含み、前記方法は、
    前記第3のノンス値に基づいて、前記サービスの第5の識別子を生成するステップと、
    前記第4の識別子を含む第2の応答を受信するステップと、
    前記第4の識別子および前記第5の識別子が等しいという判定に応じて、前記サービスのサービス情報を含む第3の応答を送信するステップと
    をさらに備える、請求項17に記載の方法。
21. 前記サービスの前記第5の識別子を生成するステップは、
    前記第3のノンス値と前記サービスの前記サービス名とを組み合わせて、第3の変更されたサービス名を生成するステップと、
    ハッシュ関数を用いて前記第3の変更されたサービス名をハッシュすることによって、第4のハッシュ出力を生成するステップと、
    前記第4のハッシュ出力の前記予め定められた部分を切り捨てて前記第5の識別子を生成するステップと
    を備える、請求項20に記載の方法。
22. サービスを広告するように適合された局であって、前記局は、
    第1の識別子および第1のパラメータを含む要求を受信するように構成された受信機と、
    前記受信機に動作可能に結合された処理ユニットであって、前記サービスの第2の識別子を生成し、前記第1の識別子および前記第2の識別子が等しい場合、前記第1のパラメータに基づいて、前記サービスの第3の識別子を生成するように構成されている、処理ユニットと、
    前記処理ユニットに動作可能に結合された送信機であって、前記サービスの前記第3の識別子を含む第1の応答を送信するように構成されている、送信機と
    を備え、
    前記第1の識別子は、第1の方法に基づいて生成され、前記第2の識別子は、第2の方法に基づいて生成され、前記第1のパラメータは、前記第2の方法に基づいて前記第3の識別子が生成されるように指示し、
    前記第1の方法に基づいて前記第1の識別子を生成することは、
    ハッシュ関数を用いて、前記サービスのサービス名をハッシュすることによって、ハッシュ出力を生成することと、
    前記ハッシュ出力の第1の部分を切り捨てて前記第1の識別子を生成することと
    を備え、前記第2の方法に基づいて前記第2の識別子を生成することは、
    前記ハッシュ出力の第2の部分を切り捨てて前記第2の識別子を生成すること
    を備える、局。

Images