JP6145177B2 - ３ｇｐｐｌｔｅにおける通信移動体デバイス間の近接発見、認証、およびリンク確立 - Google Patents

Description

本発明は、通信デバイスの近接発見に関する。更に特定すれば、本発明は、デバイス間におけるデバイス間通信セッションを設定することが可能になるデバイスの近接発見に関する。

従来技術

３ＧＰＰ規格における最近の開発は、ロング・ターム・エボリューション（ＬＴＥ）ネットワークおよびデバイスに関する。ＬＴＥは、４Ｇ（即ち、第４世代）移動体通信規格としても知られており、移動体電話機およびデータ端末用高速データのワイヤレス通信のための規格である。これは、ＧＳＭ（登録商標）／ＥＤＧＥ（２Ｇまたは２．５Ｇとしても知られる）およびＵＭＴＳ／ＨＳＰＡ（３Ｇとしても知られる）ネットワーク技術の後継であり、中核となるネットワーク改善と共に異なる無線インターフェースを使用して、容量を増大し速度を高める。最新のＬＴＥの拡張(extensions)は、基地局と移動体デバイスとの間に限られる従前の通信に続いて、直接的なまたは近隣の基地局をリレーとして使用する、デバイス間（Ｄ２Ｄ）通信を可能にする。ＬＴＥでは、デバイス間通信は、ＬＴＥ−直接通信としても知られる。

ＬＴＥ−直接通信の使用事例は、３ＧＰＰテクニカル・レポートＴＲ２２．８０３からも周知である。第１の事例では、アリスが会議に出席しており、彼女の友人ボブの近接度を検出することを望む。アリスは、彼女の友人ボブを求めて、直接モード発見をオンにする。ここで、アリスの電話機は、彼女のモバイル運用業者にメッセージを送り、彼女が直接モードを使用し、特にボブを発見できることを望むことを伝える。モバイル運用業者の直接モード・サーバは、アリスおよびボブを１対として記録する。次いで、ネットワークが、ボブおよびアリスが近くにいる（例えば、彼らが同じネットワーク・セル内に位置する、または他の何らかのメカニズムによって）ことを検出した場合、アリスおよびボブに知らせて、彼らに情報を送り、この情報によって、彼らは、彼らのプライバシーを暴くことなく、信頼性高く互いを識別することができる。第２の使用事例は、消防隊、警察、および救急車サービスというような、公衆安全サービスに関する。例えば、カバレッジ(coverage)がない建物に入る消防士は、同僚に話ができることを望むであろう。この例では、デバイスが互いに発見し、安全で認証された接続を設定することができる。

電話機およびマシン・タイプ通信（ＭＴＣ：machine type communication）デバイスのような、固定および／または移動体デバイスが各々の近接内にあるとき、例えば、ＬＴＥ移動体デバイスの場合ＬＴＥ−直接を使用して、または、例えば、IEEE 802.11、IEEE 802.16、IEEE 802.20、Bluetooth（登録商標）、Wi-Fi、またはWiMAXに基づく任意の他のデバイス間通信規格を使用して、デバイス間通信セッションをこれらのデバイス間に設定することができる。ここで、デバイスは、通例、互いの存在を検出し、ユーザに他方のデバイスの近接度について通知する。

一般に、ネットワークはデバイスの近接の発見を補助することができる。ここで、ネットワークは、２つのデバイスが互いの近接内にある可能性が高いと判断し、それぞれのデバイスに、互いの可能性の高い近接を通知する。ネットワークが、デバイスが範囲内にあることを判断できないこともあり得る。この場合、これらのデバイスは、例えば、他の近隣デバイスによって捕獲されるために識別子をブロードキャストすることによって、別の近接検査を実行しなければならない。

あるいは、近接の発見はデバイスによって直接行われる。この場合、デバイスは、通例、識別子をブロードキャストし、ブロードキャストされた識別子において他のデバイスを発見する。Bluetooth（登録商標）デバイスは、このような近接発見能力を有することが知られている。

いずれの解決手段（近接のネットワーク補助または直接発見）でも、それぞれのデバイスの識別子が、それぞれのデバイスによって、ブロードキャストされるかまたはそれ以外の方法で送信される。通例、識別子は固定であり、単に規則的な間隔でブロードキャストされた識別子を待機することによって、個々のデバイスを追跡することを可能にする。このようなユーザのプライバシーの侵害は、非常に望ましくない。

既知の近接発見解決手段の他の欠点は、これらが個々のデバイスの発見に使用されることである。個々のデバイスの近接発見、およびデバイスのグループの近接発見の双方を可能にする選択的発見可能性解決手段が求められている。すると、ユーザは、例えば、限られた数のデバイスのみ、例えば、会議においては同僚のデバイスのみに、またポップ・コンサートでは友人のデバイスのみに対して自証する(identify itself)ように、彼／彼女のデバイスの発見可能性を調節することができる。デバイス間通信が可能な範囲にある他のデバイスは、このグループにあるデバイスの近接について学習できないことが好ましい。

制御された無線ネットワークにおいてデバイスの近接発見を可能にし、プライバシーを尊重し、選択的発見可能性に対処し、好ましくはネットワーク負荷および必要な計算パワーに関して低プロファイルを有することが求められている。

本発明の目的は、制御された無線ネットワークにおいてデバイスの近接発見を可能にし、プライバシーを尊重し、選択的発見可能性に対処し、好ましくはネットワーク負荷および必要な計算パワーに関して低プロファイルを有する解決手段を提供することである。本発明は、デバイス間通信が可能であり、デバイス間通信セッションのために近隣デバイスを発見したいデバイスに特に有用であるが、これらに限定されるのではない。

本発明の一態様によれば、ソース・デバイスと１つ以上のターゲット・デバイスとの間における近接発見方法を提供する。この方法は、ソース・デバイスにおいて識別子を含む第１データを受信するステップを含む。更に、この方法は、ターゲット・デバイスにおいて、識別子の第１表現を含む第２データを受信するステップも含む。更に、この方法は、ソース・デバイスによって、識別子の第２表現を含む信号をブロードキャストするステップも含む。更に、この方法は、ターゲット・デバイスにおいて信号を受信するステップも含む。更に、この方法は、ターゲット・デバイスにおいて、識別子の第１表現を識別子の第２表現と比較して、近接発見成功を確定するための比較結果を得るステップも含む。

このようにして得られた比較結果は、通例、識別子の第１および第２表現における識別子(identifiers in the first and second representation of the identifiers)が一致することができるか否かを示す。そうである場合、近接発見が成功であると結論付けることができる。

識別子の代わりに、ソース・デバイスが、指定されたターゲット・デバイスまたはターゲット・デバイスのグループのみがソース・デバイスに関係することができる識別子の派生物をブロードキャストすることも有利である。これによって、ターゲット・デバイスは、誰がブロードキャストしているか学習することができ、例えば、ソース・デバイスが近い範囲内、例えば、デバイス間通信セッションの範囲にあると結論付けることができ、またはソース・デバイスが近い範囲にあることに基づいて、任意のアクション、例えば、料金ゲートにおける課金のきっかけとなることができる。一方、ソース・デバイスの識別子は、追跡可能でない。

本発明の一実施形態では、前述の方法は、更に、ターゲット・デバイスからソース・デバイスに、比較結果に応じて、承認メッセージを送信するステップも含むことができる。これは、ソース・デバイスが、ターゲット・デバイスが近い範囲にあることを学習することが可能であるという利点がある。

他の実施形態では、識別子は、ターゲット・デバイスを一意に識別する一時的ブロードキャスト識別子とすることができ、識別子は、ターゲット・デバイスによってソース・デバイスと関連付け可能とすることができる。これは、ソース・デバイスが、盗聴者にはソース・デバイスにリンクされているとは思えない識別子を送信することを可能にし、ソース・デバイスを追跡不可能にするという利点がある。ターゲット・デバイスは、識別子をソース・デバイスに関連付けることができる。

他の実施形態では、 ソース・デバイスおよび１つ以上のターゲット・デバイスが、デバイスのグループを形成することができ、識別子がデバイスのグループを識別することができる。これは、単に１つのターゲット・デバイスではなく、ターゲット・デバイスのグループの近接発見を可能にするという利点がある。

他の実施形態では、識別子、識別子の第１表現、および識別子の第２表現が同一であることができる。

他の実施形態では、 ソース・デバイスおよび１つ以上のターゲット・デバイスが、ネットワークに通信可能に結合されるように構成することができ、第１データおよび第２データをネットワークにおけるサーバから受信することができる。あるいは、第１データおよび第２データをソース・デバイスから受信することができる。これは、ネットワークが関与すること、またはネットワークなしで単体モードで動作することが可能になるという利点がある。

本発明の他の実施形態では、前述の方法は、更に、ターゲット・デバイスにおいて、識別子の第３表現を含む第３データを受信するステップを含むことができる。識別子の第１表現は、第１数学関数によって得られる識別子の派生物とすることができる。第１数学関数は、識別子の派生物を計算するために、識別子および乱数を入力として使用する。識別子の第３表現は、乱数とすることができる。比較するステップは、識別子の第２表現および識別子の第３表現を入力として使用する第１数学関数と同一である第２数学関数を使用して、識別子の派生物を計算するステップを含むことができる。比較するステップは、更に、計算した識別子の派生物を、識別子の第１表現と比較するステップも含むことができる。前述の乱数は、サーバまたはソース・デバイスにおいて生成された乱数とすることができる。代わりに、前述の乱数は、サーバまたはソース・デバイスにおいて生成されたソルトとすることもできる。代わりに、前述の乱数は、第３数学関数によってサーバまたはソース・デバイスにおいて得られた更に別の乱数の派生物とすることができ、第３数学関数が、乱数の派生物を計算するために、更に別の乱数およびソース・デバイスを識別するソース識別子を入力として使用する。

これは、交換される識別子に曖昧度を追加し、デバイスを追跡することを一層困難にするという利点がある。

他の実施形態では、第２データが、更に、チケット識別子を含むことができる。更に、前述の方法は、サーバから、ソース・デバイスにおいて、チケット識別子を含むチケット・データと、第１データと、第４データとを受信するステップを含むことができる。更に、この方法は、チケット識別子に関連付けられた第４データのコピーを得るために、ターゲット・デバイスからサーバに、チケット識別子を送信するステップも含むことができる。更に、この方法は、サーバから、ターゲット・デバイスにおいて、第４データのコピーを受信するステップも含むことができる。 承認メッセージは、ソース・デバイスにおける第４データとの検証のために、第４データのコピーを含むことができる。

チケット発行(ticketing)は、近接発見の試行を追跡することを可能にするという利点がある。追跡は、例えば、近接発見の試行を記録するため、またはそれに課金するために使用することができる。

他の実施形態では、前述の方法は、更に、サーバの運用業者によって、ソース・デバイスまたはターゲット・デバイスからの第１データ、第２データ、および／またはチケット・データに対する要求に課金するステップを含むことができる。これは、近接発見の試行に対して、恐らくは、成功した近接発見の試行のみに対して課金することが可能になるという利点がある。

他の実施形態では、前述の方法は、更に、ソース・デバイスからターゲット・デバイスにおいて、第１チャレンジ・データを受信するステップを含むことができる。更に、この方法は、 ターゲット・デバイスにおいて、第４数学関数、例えば、ハッシュ関数を第１チャレンジ・データに対して使用して、派生第１チャレンジ・データを計算するステップも含むことができる。承認メッセージは、更に、派生第１チャレンジ・データと第２チャレンジ・データとを含むことができる。更に、この方法は、ソース・デバイスにおいて、受信した派生第１チャレンジ・データとの比較のために、第４数学関数と同一である第５数学関数を第１チャレンジ・データに対して使用して、派生第１チャレンジ・データを計算するステップも含むことができる。更に、この方法は、ソース・デバイスにおいて、第６数学関数を第２チャレンジ・データに対して使用して、派生第２チャレンジ・データを計算するステップも含むことができる。更に、この方法は、派生第２チャレンジ・データをターゲット・デバイスに送信するステップも含むことができる。更に、この方法は、ターゲット・デバイスにおいて、受信した派生第２チャレンジ・データとの比較のために、第６数学関数と同一である第７数学関数を第２チャレンジ・データに対して使用して、派生第２チャレンジ・データを計算するステップも含むことができる。

これは、チャレンジ−応答認証という形態で、識別子の交換に対して安全度(level of security)を高めるという利点がある。

他の実施形態では、チケット・データが、更に、暗号鍵を含むことができる。更に、前述の方法は、サーバから、ターゲット・デバイスにおいて、サーバにおいてチケット識別子に関連付けられた暗号鍵を受信するステップを含むことができる。第４、第５、第６、および第７数学関数は、暗号鍵を使用する暗号関数を含むことができる。

これは、識別子の交換に対して安全度を高めるという利点がある。

本発明の一態様によれば、以上で説明した方法の１つ以上のステップを使用して、１つ以上のターゲット・デバイスと共に近接発見手順を実行するように構成されたソース・デバイスを提案する。

本発明の一態様によれば、以上で説明した方法の１つ以上のステップを使用して、ソース・デバイスと共に近接発見手順を実行するように構成されたターゲット・デバイスを提案する。

本発明の一態様によれば、以上で説明したようなソース・デバイスと、以上で説明したような１つ以上のターゲット・デバイスとを含むネットワークを提案する。

以降、本発明の実施形態について更に詳しく説明する。しかしながら、これらの実施形態は、本発明の保護範囲を限定するように解釈してはならないことは、認められてしかるべきである。

図面に示される実施形態例を参照しながら、本発明の態様について更に詳しく説明する。

図１は、ソース・デバイスと、ターゲット・デバイスと、任意にサーバとの間における時間シーケンス図として可視化された、本発明の実施形態例による近接発見手順である。 図２は、ソース・デバイスと、ターゲット・デバイスと、任意にサーバとの間における時間シーケンス図として可視化された、本発明の実施形態例による近接発見手順である。 図３は、ソース・デバイスと、ターゲット・デバイスと、任意にサーバとの間における時間シーケンス図として可視化された、本発明の実施形態例による近接発見手順である。 図４は、ソース・デバイスと、ターゲット・デバイスと、任意にサーバとの間における時間シーケンス図として可視化された、本発明の実施形態例による近接発見手順である。 図５は、ソース・デバイスと、ターゲット・デバイスと、任意にサーバとの間における時間シーケンス図として可視化された、本発明の実施形態例による近接発見手順である。 図６は、ソース・デバイスと、ターゲット・デバイスと、任意にサーバとの間における時間シーケンス図として可視化された、本発明の実施形態例による近接発見手順である。

以下の説明では、「デバイス」、「端末」、および「ユーザ機器（ＵＥ）」という用語は、固定または移動体エンド・ユーザ即ちＭＴＣ端末の同義語として理解されるものとする。「ピア」は、デバイス間通信において関与することができる任意の固定または移動体エンド・ユーザ・デバイスとして理解されるものとする。

デバイス間通信モードでは、デバイスは、直接的に、即ち、固定またはワイヤレス・ネットワークを使用せずに通信する。デバイス間通信リンクは、デバイス間で信号を中継するために基地局を使用することもできるが、基地局のネットワークのそれ以上のネットワーク機能は使用されない。ピアは、デバイス間通信モードに隣接するワイヤレスまたは固定ネットワークに接続することができる。

本発明は、デバイス間通信モードのために、デバイスが１つ以上の他のデバイスを範囲内において発見することを可能にする。この近接発見は、例えば、ターゲット・デバイスがソース・デバイスからの信号を待機(listen to)し始める、または、例えば、料金所における課金のような、近接発見に基づく任意の他のアクションを実行するきっかけとなることができる。近接発見の結果、ソース・デバイスとターゲット・デバイスとの間においてデバイス間通信を設定することもできる。

デバイスの識別、または識別の表現が、近接発見を可能にするために交換される。この識別子の交換は、デバイスの送信を待機または盗聴し、送信される識別子を傍受することによってデバイスが追跡可能とはならないように行われる。追跡可能でないことにより、デバイスのユーザのプライバシーを強化する。

ネットワークに対して固定またはワイヤレス接続を有する２つ以上のデバイス間においてデバイス間通信セッションを設定するためには、デバイスは、近接発見手順を開始する前に、発見可能になることまたはある種の（１組の）ピア（１つまたは複数）を発見することを望むことを、ネットワークにおけるサーバに対して示すことによって、任意に他のデバイスを起動する(trigger)ことができる。近接発見手順の前に、ネットワーク、第三者（例えば、オーバーザトップ・プロバイダまたは任意の他の第三者）、またはデバイス自体が、ピアが近隣にあることを検出するのが通例である。

近接発見手順の一部として、発見されることを望むソース・デバイスは、識別子またはこの識別子の表現を含むメッセージをブロードキャストする。この識別子は、接触されるターゲット・デバイスの識別子、またはソース・デバイスの識別子、あるいはその派生物(derivation)、更には１組のピアによって使用される共通のセキュリティ・アソシエーション(common security association)であってもよい。デバイスの追跡可能性を回避するために、デバイスはそれ自体の識別子を平文ではブロードキャストしないのが 好ましい。

識別子は、一時的なブロードキャスト識別子（Ｔ−ＢＩＤ）であってもよく、ときの経過と共に変化してもよい。Ｔ−ＢＩＤは、他の当事者によって、例えば、デバイスに新たな識別子を供給するネットワークによって、またはオーバーザトップ・サービス、即ち、Facebook、Google+、またはWhatsappのような、新たな識別子を供給するネットワーク外部の当事者によってプロビジョニングすることによって、変更することもできる。Ｔ−ＢＩＤは、ネットワークを経由する２つのデバイス間の通信セッション（即ち、デバイス間通信セッションを使用しない）、あるいは、例えば、WiFi、Bluetooth（登録商標）、NFC、またはカメラおよび画面通信のような任意の他の接続によって、例えば、デバイスに新たな一時的な識別子に交換させることによって、あるいは新たな一時的識別子を計算するためのランダム／アルゴリズムによって変更することができる。Ｔ−ＢＩＤは、例えば、時間、デバイス間接続が２つ（以上）のデバイス間で設定された回数、ネットワーク運用業者またはオーバーザトップ・サービス・プロバイダのような第三者によって供給される乱数またはソルト(salt)、および／または暗号化／ハッシュ化識別子と同時に送信される乱数を含むアルゴリズムによって変更されてもよい。

近接発見手順の一部として、ターゲット・デバイスは、必要な情報を、ブロードキャストされたメッセージから抽出する（例えば、暗号解読、再ハッシング、または単にリスト上で知られている識別子と比較することによって）。ソース・デバイスは、誰がブロードキャストしているのか、指定されたターゲット・デバイスだけが習得できるような方法で、その識別子をブロードキャストする。

任意に、ターゲット・デバイスは、他方のデバイスを捕らえた(heard)ことおよびデバイス間通信に利用可能であることの承認メッセージをソース・デバイスに送ることによって応答する。任意の承認メッセージは、初期ブロードキャストに含むことができるチャレンジ(challenge)に対する応答を含むこともできる。任意の承認メッセージは、認証目的のために共通の秘密がソース・デバイスおよびターゲット・デバイスによって知られていることを確定できるデータを含むこともできる。

近接発見に成功した後、デバイス間接続をこれらのデバイス間で設定することができる。

近接発見手順は、安全なデバイス間接続を設定するために使用することができる。２つのデバイスが互いに認証できること（例えば、中間者攻撃を防止するため）、およびネットワークは接続がどのように設定されるかについて何らかの種類の制御を有すること（例えば、近接発見に課金するため）を検証することが望ましい場合がある。したがって、近接発見は、以下のように実現することができる三方向ハンドシェーク手順を含んでもよい。

１．ソース・デバイスが乱数（チャレンジ）をターゲット・デバイスに、Ｔ−ＢＩＤと同じブロードキャストにおいて送る。

２．ターゲット・デバイスは、ハッシュ（チャレンジ || 共通の秘密）を計算する。ここで、共通の秘密は、例えば、乱数、ソルト、または共通のＴ−ＢＩＤとすることができる。ターゲット・デバイスは、別の乱数回答(random replies)を、別の乱数 || ハッシュ（チャレンジ || 共通の秘密）を含むメッセージと共に生成する。

３．ソース・デバイスは、ハッシュ（チャレンジ || 共通の秘密）を検証することができ、ハッシュ（別の乱数 || 共通の秘密）を含むメッセージで回答する。

４．ターゲット・デバイスは、ハッシュ（別の乱数 || 共通の秘密）を検証することができ、次いでソース・デバイスおよびターゲット・デバイスの双方は、双方が同じ共通の秘密を有し、互いに認証したことを知る。

本発明の以下の実施形態例では、以上で概要を説明した近接発見手順について、更に詳しく説明する。

近接発見手順では、異なる種類の識別子を使用することができ、その例には、ブロードキャスト識別子（ＢＩＤ）、一時的ブロードキャスト識別子（Ｔ−ＢＩＤ）、グループ特定ブロードキャスト識別子（Ｇ Ｔ−ＢＩＤ）、友人特定（一時的）ブロードキャスト識別子（Ｆ（Ｔ）−ＢＩＤ）、およびセキュリティ・アソシエーション（一時的）ブロードキャスト識別子（ＳＡ（Ｔ）−ＢＩＤ）が含まれる。ブロードキャスト識別子は、世界規模で一意の識別子であり、存在を告知するため、または誰かに発呼するために、共有媒体によってブロードキャストされる。デバイスは、ＢＩＤの派生物、または発呼される「友人」／他のデバイスのＢＩＤのいずれかをブロードキャストすることができる。一時的ブロードキャスト識別子は、限られた時間量、使用量、または地理的位置のためにのみ使用されるブロードキャスト識別子である。この規則に対する例外は、いわゆる「一回Ｔ−ＢＩＤ」がＴ−ＢＩＤから導かれ、代わりにブロードキャストされる場合である。グループ特定（Ｔ−）ＢＩＤは、グループに言及するブロードキャスト識別子である。これが意味するのは、グループにおける全てのデバイスがこのＢＩＤを待機するということである。友人特定（Ｔ−）ＢＩＤは、２人の友人／デバイスの間のみで共有されるブロードキャスト識別子である。セキュリティ・アソシエーション（Ｔ−ＢＩＤ）は、セキュリティ・アソシエーションに言及しているブロードキャスト識別子である。これが意味するのは、２つのデバイスがセキュリティ・アソシエーションを共有する場合、これらは同じブロードキャスト識別子を待機するということである。

通例、近接発見手順の前に近接検出が行われる。近接検出フェーズでは、デバイスは、それらが近くにあるという情報を受信する。近接発見手順では、近くにあるという情報を受信したデバイスの内１つ以上が、デバイス間通信が可能か否か判断する。近接検出を実行する方法は多数ある。例えば、ネットワークが、２つのピアが近くにあることを検出し、通知してもよい。これは、第１に、デバイスは、ネットワークによって一旦通知されてから識別子をブロードキャストすればよいため、バッテリ消耗削減およびブロードキャスト・チャネルの使用削減に繋がるので、そして第２に、ネットワークは（同じメッセージにおいて）識別子および（任意に）暗号素材を供給できるので、これは有利であると考えられる。加えてまたは代わりに、オーバーザトップ・サービス・プロバイダまたは第三者が、ピアに、これらが近くにあることを通知する。加えてまたは代わりに、ユーザが、互いの近接内にあるデバイスを始動させてもよい。これは、ネットワーク・カバレッジがなく、デバイス間接続を設定したいという状況には、有利であると考えられる。ネットワーク・カバレッジがある場合でも、この方法は、例えば、互いに知らないピアには、例えば、新たな人に会って電話番号を交換したい場合に、有利であると考えられる。

図１〜図６は、ネットワークにおけるソース・デバイス１、ターゲット・デバイス２、および任意にサーバ３の間における時間シーケンス図として、近接発見手順が可視化された、本発明の実施形態例を示す。尚、多数のターゲット・デバイス２があってもよいことは、理解されてしかるべきである。矢印はデータの流れを示す。黒点は、デバイスにおいて実行されたアクションを示す。括弧「｛｝」内にある参照番号は、データ・エレメントを示す。破線は、任意選択ステップを示す。

図１において、識別子１２を含む第１データ１１が、ソース・デバイス１において受信される（１０１）。第１データは、外部サーバから、またはソース・デバイス１自体から発するのでもよい。後者の場合、ソース・デバイス１が識別子１２を生成する。識別子１２の第１表現２１を含む第２データ２０が、ターゲット・デバイス２において受信される（１０２）。第２データ２０は、外部サーバから、またはソース・デバイス１から発するのでもよい。次に、ソース・デバイス１は、識別子１２の第２表現３１を含む信号１０３をブロードキャストし（１０３）、この信号１０３はターゲット・デバイス２において受信される（１０４）。ターゲット・デバイス２は、識別子１２の第１表現２１を、識別子１２の第２表現３１と比較する（１０５）。このようにして得られた比較結果は、識別子の第１および第２表現とした識別子が一致することができるか(can be matched)否かを示す。一致することができる場合、近接発見は成功したと結論付けることができ、任意に、承認メッセージ４０においてソース・デバイス１に報告することもできる（１０６）。

図２は、チケットの使用を検出することによって、ネットワーク運用業者による近接発券の課金を可能にするという利点がある、チケット・ベースおよびネットワーク補助の実施形態を示す。

近接発見に先立って、ソース・デバイス１は、ネットワークにおけるサーバ３、または第三者に、１つ以上のターゲット・デバイス２を発見したいことを通知する（２０１）。ネットワークまたは第三者は、例えば、これらのデバイスがネットワークまたは第三者において登録(subscription)を有し追跡されているため、あるいはこれらのデバイスがネットワークまたは第三者に通知したため、これらの前述したターゲット・デバイス２の内どれが発見可能(discoverable)であるか、または発見することができる(able to discover)か知ることができ、これらをピアとして列挙する。

サーバ３は、ソース・デバイス１に、チケット・データ１０の形態としたチケットを供給し（１０１）、チケット・データ１０の中で、ソース・デバイス１に、そのピア２の各々に到達するようにブロードキャストする（１０３）ために、識別子１２が与えられる。また、ネットワーク３は、ソース・デバイス１のピア２に、これらが待ち受けるべき識別子２１について通知する。識別子２１は、識別子１２または識別子１２の第１表現２１と同一であってもよい。

ネットワークは、任意に、チケット１０内に、セキュリティ・アソシエーション１４、例えば、暗号鍵を含むこともでき、ソース・デバイス１はこのセキュリティ・アソシエーション１４を使用して、そのピア２の内の１つに対する接続を秘密に設定することができる。同様に、ネットワーク３が既にセキュリティ・アソシエーション１４をターゲット・デバイス２に送ってあってもよいが、課金の観点からは、一旦ターゲット・デバイス２がそれを要求してから、チケット全体を送ることが望ましい場合もある。その理由は、その場合、ネットワークは発見成功を確信することができ、これは課金を可能にすることを意味するからである。あるいは、ネットワーク３が２つのピア１、２が近くにあることを検出したとき、ネットワークが鍵１４を送ってもよい。この場合、ネットワーク３は、近接検出または接続の設定に関与する。これは、鍵の新鮮さ(freshness)にとっては有利である。更に、ネットワーク３は、ピアである全てのデバイスについて鍵の登録簿を保持する必要はない。

ネットワーク３は、近接検出の時点において、識別子１２および／または識別子１２の派生物(derivation)２１を送ればよい。

この時点で、ソース・デバイス１は、そのピア２の各々について、以下の情報を含むチケット１０を有する。チケット識別子２２、任意に、任意のチャレンジ応答システムにおいて使用される共通の秘密または乱数、第１デバイス１がターゲット・デバイス２に到達するために使用することができるＴ−ＢＩＤのような識別子１２、２１、任意に、ターゲット・デバイス２が第１デバイス１に到達するためにその応答において使用することができるＴ−ＢＩＤのような別の識別子１３。別の識別子１３は、実施形態例では、第４データとも呼ばれる。

任意に、マスタ暗号鍵または１組の鍵（暗号鍵および完全性保護鍵）をチケット・データ１０に含ませてもよく、このマスタ暗号鍵から他の鍵を導くことができる。

ピア１、２の各々は、この時点で、次の情報をメモリに有する。待機しソース・デバイス１に関係付けるＴ−ＢＩＤ１２、２１（またはその表現）。任意に同じ共通の秘密または乱数。チケット識別子２２。任意に他の鍵を導くことができるマスタ暗号鍵、または１組の鍵（暗号鍵および完全性保護鍵）。

後のある時点において、ネットワークまたは第三者／オーバーザトップ・プロバイダは、ソース・デバイスおよびターゲット・デバイスが近隣にあること（更に、互いにとって未だ発見可能である、即ち、ユーザは誰も未だ彼らの設定を変更していないこと）を検出することができる。ネットワークまたは第三者は、第１デバイスに、それらが近くにあることを通知する。

ここで、チケット・ベース・システムの利点が明らかになる。つまり、これは近隣検出を行うネットワークである必要はない。これが意味するのは、一旦ネットワークが鍵１４を含むチケット１０を発行したなら、鍵１４をターゲット・デバイス２に供給し、ソース・デバイス１に請求するだけでよいということである。

第１デバイス１は、先に受信した一時的ブロードキャスト識別子またはその第２表現３１を含む信号３０をブロードキャストし（１０３）、この信号３０はターゲット・デバイス２によって受信される。

任意に、本メカニズムは、チャレンジ応答システムによって拡張されてもよい。この場合、識別子３１のブロードキャスト１０３は、チャレンジ３２（実施形態例では第１チャレンジ・データ３２とも呼ぶ）と共に行うことができ、ターゲット・デバイス２は正しい答えをチャレンジに対して供給することができる。

ターゲット・デバイス２がブロードキャストを受信した後、承認メッセージ１０６を使用して、このメッセージを得たことをターゲット・デバイス１に任意に回答する。任意に、前述のように、ターゲット・デバイス２はブロードキャスト・メッセージ１０３の受信時に、ネットワークからチケット全体（鍵を含む）を引き出す。任意に、ターゲット・デバイス２は、チャレンジ３２に対するその答えを計算し（１１４）、任意にそれを暗号化して第１デバイス１に回答する（１０６）。

チャレンジ３２に対する答え１０６は、ハッシュ（チャレンジ３２ || 共通の秘密）の形態でもよい。受信時に、ソース・デバイス１は同じ計算を行い、答えが同じであることを検証する（１１５）ことができる。回答も暗号化できることの利点は、この回答がハッシュ関数に対する暴力(brute force)またはレインボー攻撃(rainbow attack)を受けにくいことである。しかし、暗号化がなくても、本解決手段は安全であることに変わりはない。

また、ターゲット・デバイス２がその回答内にチャレンジ４３（実施形態例では第２チャレンジ・データ４３とも呼ぶ）を含むことも可能である。これは、ターゲット・デバイス２によって生成される他の乱数であってもよい。

任意に、ソース・デバイスはハッシュ（チャレンジ４３ || 共通の秘密）を計算し（１１６）、この導かれた第２チャレンジ・データ値３３を用いてターゲット・デバイス２に回答する（１１７）。一方、ターゲット・デバイス２は、ソース・デバイス１が正しくハッシュ（チャレンジ４３ || 共通の秘密）を計算したことを検証することができる。現在双方が有するセキュリティ・アソシエーションに基づいて、安全性が確保され認証された接続２０２を任意に設定することができる。

１つのチケット１０が多数回使用されてもよいが、ブロードキャストＴ−ＢＩＤの追跡を回避するために、少ない回数に使用を制限することが薦められる。これが意味するのは、Ｔ−ＢＩＤのブロードキャスト失敗の後でも（例えば、ピアに到達できなかった）、新たなチケット１０が発行されなければならない場合もあるということである。

追跡可能でなければ、同じチケットを再利用したいということは考えられる。ここで、図４および図６において紹介する解決手段、およびグループ・アドレシングのための以下で説明する解決策が、図２に加えて使用されてもよい。

図３および図４に示すネットワーク補助の実施形態では、識別子がピア１、２に予めロードされており、ソース・デバイス１およびターゲット・デバイス（１つまたは複数）２がピアであることが、前もってネットワークに通知される。

図２を参照すると、近接発見に先立って、ソース・デバイス１は、１つ以上のターゲット・デバイス２を発見したいことをネットワーク３に通知する。ネットワーク３は、これら前述したターゲット・デバイス２の内どれが発見可能であるか、または発見することができるか知っており、これらを対として列挙する。このように、ネットワークは、ソース・デバイス１およびターゲット・デバイス２が近隣にあることを検出することができ、双方に通知する。

近接発見に先立つこれらのステップは、ブロック２０３によって示される。

ある指定された間隔で（例えば、夜間、または任意の他の時間間隔）、ピア１、２には１組のＴ−ＢＩＤ１２、２１（または他の識別子１２、２１）が与えられる（１０１、１０２）。これらは、デバイス１、２の各々に対する近接発見において使用することができる。ここで、ソース・デバイス１においてネットワークからの第１データ１１内で識別子１２が受信され（１０１）、この例では識別子１２と同一であってもよい識別子２１が、ターゲット・デバイス（１つまたは複数）２においてネットワークからの第２データ内で受信される（１０２）。Ｔ−ＢＩＤ１２、２１は、この例では、ピア特定Ｔ−ＢＩＤである。また、ピア１、２には、他方のデバイスが使用するＴ−ＢＩＤ１２、２１が供給される（１０１、１０２）。任意に、ピア１、２は、一般Ｔ−ＢＩＤ１２、２１（Ｇｅｎ Ｔ−ＢＩＤ）も受信する（１０１、１０２）。これらは、デバイスのグループの発見可能性のために使用することができる。このＧｅｎ Ｔ−ＢＩＤ１２、２１は、対をなす各デバイスにも配給される。したがって、各ピア１、２は以下の表のように見える登録簿を有する（この例は、ソース・デバイス１について有効である）。

この表のブロードキャスト側では、ソース・デバイス１がターゲット・デバイス２の内いずれかの特定のものと接触したい場合、または一般Ｔ−ＢＩＤ３１を使用する任意の者（即ち、「ａ」）にとって発見可能である場合に、Ｔ−ＢＩＤ３１（即ち、「ｂ」、「ｃ」、「ｄ」および「ｅ」）が信号３０内でソース・デバイス１からブロードキャストされ（１０３）、ターゲット・デバイス２において受信される（１０４）。この表の受信側では、ピア発見の場合に、ブロードキャストがソース・デバイス１によって待ち受けられることになる。したがって、ソース・デバイス１が第１ターゲット・デバイス２に到達したい場合、「ｂ」をブロードキャストしなければならない（１０３）。あるいは、ソース・デバイス１が、一般Ｔ−ＢＩＤを有する任意の者に発見可能であることを望む場合、「ａ」をブロードキャストする（１０３）。受信側では、ソース・デバイス１が最後の２つの列を待機しなければならない。最後の列における値（「ｊ」、「ｋ」、「ｍ」、「ｎ」）のいずれかがブロードキャストされた場合、そのピア２の内の１つが近隣にあり、ソース・デバイス１に到達しようとしていると結論付ける（１０５）ことができる。真中の列における値（「ｆ」、「ｇ」、「ｈ」、「ｉ」）のいずれかがブロードキャストされた場合、ソース・デバイス１は、そのピア２の内の１つが近隣にあること、そしてこれらが存在することを知らせるために、それらの一般Ｔ−ＢＩＤをブロードキャストしたことを知る。

尚、登録簿を格納する様態は任意であることは理解されてしかるべきである。表のフォーマットは、単なる例に過ぎず、値を格納する任意の他の様式を使用することができる。識別子１２、２１は、アルファベットの文字として提示される。尚、識別子は任意の長さの任意の２進値、１０進数値、１６進数値、ワード値、ｄワード値(dword value)、ストリング値等を有することもできることは理解されてしかるべきである。

図３の実施形態は、誰が近隣にいるかについての事前知識を有することなく、単にＧｅｎ Ｔ−ＢＩＤ３１またはある数の特定Ｔ−ＢＩＤ３１をブロードキャストすることを可能にする。また、これは、ピア１、２が現在ネットワーク・カバレッジまたは制御に入っていない場合、例えば、アドホック・モードで（恐らくは一時的に）動作しているときでも、作用する。

デバイス間接続２０６の時点ではセキュリティ・アソシエーションが知られておらず、このようなセキュリティ・アソシエーション２０４が望まれる場合、ネットワーク３は、任意に、暗号鍵１４をデバイス１、２に、好ましくは、安全な回線を通じて供給することができる。すると、有利なこととして、ネットワークには発見が行われたことも通知され（２０５）、課金が可能になるという利点がある。

一般ＢＩＤ１２、２１またはピア特定Ｔ−ＢＩＤ１２、２１を変更するメカニズムを有することが望ましい場合がある。例えば、一旦Ｔ−ＢＩＤ３１がブロードキャストされたなら（１０３）（そして、デバイス間セッション２０６の設定が成功したか否かには関係なく）、悪意のあるユーザがこのＴ−ＢＩＤを保存し、今後これを探し続ける可能性がある。いずれの時点においても、同じＴ−ＢＩＤが再度ブロードキャストされた場合、悪意のユーザは、特定のデバイスが近隣にあると結論付けることができる。したがって、任意に、ソース・デバイス１がネットワーク３にそれらのＴ−ＢＩＤ１２を更新するように頼む（１０１ａ）ことも可能である。次いで、ネットワーク３は新たなＴ−ＢＩＤ１２を割り当て、ピア１、２に新たなＴ−ＢＩＤ１２、２１を通知する（１０１ｂ、１０２ａ）。

Ｔ−ＢＩＤ１２、２１がブロードキャストにおいて使用される毎に、ネットワークがＴ−ＢＩＤ１２、２１を再割り当てし、これらを全てのピア１、２に再配給する（１０１ｂ、１０２ａ）ことが可能である。

ＢＩＤおよびピア特定Ｔ−ＢＩＤに続いて、ネットワークは、任意に、特定の友人／デバイスのグループのみに対して発見可能となるために、特定Ｔ−ＢＩＤを供給することもできる。こうして、閉じたユーザ・グループに特定的なＴ−ＢＩＤ（ＣＵＧ Ｔ−ＢＩＤ）を、もっと大きなグループに対して定義することができる。このようなＣＵＧ Ｔ−ＢＩＤ識別子も、グループにおける各人に供給されることが好ましい。これは、例えば、同僚、または警官および消防隊というような公共安全サービスのような、固定的なグループには有利である。

ピア特定Ｔ−ＢＩＤは、任意に、ネットワークを伴うことなくまたはネットワークに通知することなく、デバイス間接続の間にリフレッシュされてもよい。これによって、プライバシーの度合いが高くなり（ネットワークは識別子１２、２１すら知らない）、Ｔ−ＢＩＤを生成するタスクをネットワークから軽減する。

図４の実施形態では、識別子１２は予めロードされており、固定である。しかしながら、ブロードキャストＴ−ＢＩＤ３１は、例えば、ネットワーク３がソース・デバイス１およびターゲット・デバイス２に乱数５１を供給することによって（ブロードキャストが行われる前に）、変化することができる。ソース・デバイス１は、例えば、識別子１２を暗号化またはハッシュすることによって、 乱数５１を使用して、識別子の派生物を計算し（１０３ａ）、ターゲット・デバイス２は、乱数５１を使用して識別子を解読し検証する（１０９）ことができる。

図４の実施形態は、素早く変化するグループで、グループの構成員が互いの識別子を有するが、全てが同じ乱数を得るのではない場合に特に有利である。

図４を参照する以下の第１の例では、近接発見に先立って、ピア１、２に、ｐと呼ばれるＴ−ＢＩＤ（ソース・デバイス１にはｐ−ｉ、第１ターゲット・デバイス２にはｐ_２、第２ターゲット・デバイス２にはｐ_３等）が割り当てられる（２０７）。

運用業者３は、第１、第２、第３、および第４ターゲット・デバイス２を発見したいというメッセージ１０１ｃをソース・デバイス１から受信する。運用業者３は、第１、第２、および第４ターゲット・デバイス２が近くにあることを検出する。第５および第６ターゲット・デバイスも近くにある可能性があるが、これらはソース・デバイス１のリストにはない。したがって、第５および第６デバイスは発見されない。

運用業者３は、長さがｐｉ２の乱数ｘを選び、第１ターゲット・デバイス２のために、p₂についてx₂ = x mod p₂を計算し、同じものを第３ターゲット・デバイス２にも計算する（第２および第４ターゲット・デバイスは除く。何故なら、これらはこの例では近くにないからである）。あるいは、ソース・デバイス１は運用業者３に乱数ｘを供給する。

運用業者３は、ｘをソース・デバイス１に送る（１０２ｂ）。運用業者３は、ｘ_２を第１ターゲット・デバイス２に送り（１０２）、ｘ_４を第３ターゲット・デバイス２に送る。ここで、ｘ_２およびｘ_４は、識別子１２の表現２１である。

ソース・デバイス１は、乱数ｘ３１をブロードキャストし（１０３）、範囲内にある全てのピア２（第１ターゲット・デバイス２および第３ターゲット・デバイス２を含むことが望ましい）は、x_i==x mod p_iであるか否か検証する（１０９）ことができる。ここでは、値ｘ３１は、識別子の第２表現として機能する。何故なら、これはターゲット・デバイス２において識別を検証するために使用されてもよいからである。

第１および第３ターゲット・デバイス２は、メッセージが受信されたことを応答することができ（１０６）、これらのデバイスは、恐らくは、サーバ３から受信したセキュリティ・アソシエーションを使用して、デバイス間通信セッションを設定することができる。

第５および第６ターゲット・デバイスも乱数ｘ３１を受信したであろうが、これらの情報は非常に制限されるので（これらは運用業者３からのｘ_ｉ値を受信しなかった）、誰が発呼しているか発見できず、追跡（tracking and tracing）のために使用することもできない。

ソース・デバイス１が、次のブロードキャスト１０３のためにｒ３１の修正バージョンを再利用することは可能である。これは、第１デバイス１がターゲット・デバイス２のｐ_ｉの値を知っていれば可能である。知っていれば、双方の最少公倍数（ＬＣＭ）（の倍数）を使用して、X_i == x mod p_iが引き続き成り立つ新たなｘを得ることができる。即ち、 x' = x + k LCM(p₂, p₃等)となる。ここで、使用される識別子のＬＣＭについて多すぎる情報を与えるのを防止するために、ｋに素数を採用してはならず、好ましくは、素数の倍数を採用するとよい。この解決手段の利点は、ターゲット・デバイスにとって何も変化せず、これらの回答は同じままであることである。

図４を参照する以下の第２の例では、近接発見に先立って、ピア１、２にはｐと呼ばれるＴ−ＢＩＤが割り当てられる（２０７）（ソース・デバイス１にはｐ_１、第１ターゲット・デバイス２にはｐ_２、第２ターゲット・デバイス２にはｐ_３等）。ピア１、２は、互いの識別について通知されるので、例えば、ソース・デバイス１は、第１ターゲット・デバイス２のＴ−ＢＩＤを知っており、第２ターゲット・デバイス２は、ソース・デバイス１のＴ−ＢＩＤを知っている。

運用業者３は、第１、第２、第３、および第４ターゲット・デバイス２を発見したいというメッセージ１０１ｃをソース・デバイス１から受信する。運用業者３は、第１、第２、および第４ターゲット・デバイス２が近くにあることを検出する。第５および第６ターゲット・デバイスも近くにある可能性があるが、これらはソース・デバイス１のリストにはない。したがって、第５および第６デバイスは発見されない。

運用業者３は、乱数ｒを選び、x = hash(T-BID_{source device1 || r})、ならびに再度第２および第４ターゲット・デバイス２についてx_i = x mod p_iを計算する。あるいは、ソース・デバイス１が運用業者３に乱数ｒを供給する。

運用業者３は、乱数ｒをソース・デバイス１に送る（１０２ｂ）。運用業者３は、(x₂, r)を第１ターゲット・デバイス２に送り（１０２）、(x₄, r)を第３ターゲット・デバイス２に送る。ここで、ｘ_２およびｘ_４は、識別子１２の表現２１である。

ソース・デバイス１は、ｘ３１をブロードキャストし（１０３）、範囲内にある全てのピア２（第１ターゲット・デバイス２および第３ターゲット・デバイス２を含むことが望ましい）は、x_i == x mod p_iか否か検証する（１０９）ことができる。ここでは、値ｘ３１は、識別子の第２表現として機能する。何故なら、これはターゲット・デバイス２において識別を検証するために使用されてもよいからである。

第１および第３ターゲット・デバイス２は、メッセージが受信されたことを応答し（１０６）、ターゲット・デバイス２において計算された（１０８）ハッシュ（p_i || r)を戻すことによって、その認証を証明することができる。

前述の実施形態におけると同様、ネットワーク３は暗号鍵の交換に関与して、セキュリティを更に高め、近接検出の成功に対して課金することを可能にすることができる。

また、図４の例は、１つのデバイス１、２が１つの他のデバイス１、２のみを発見したいという場合にもうまく作用する。次いで、ネットワーク３はこれらの特定のピアにのみ通知する。

以下の実施形態例では、単体近接発見手順(standalone proximity discovery procedures)について説明し、デバイス１、２自体が、発見可能性のために何をブロードキャストすべきか決定する。ネットワーク３または第三者は、デバイス１、２に、可能性が高い近接について通知することに関与する、即ち、近接検出に関与し続けることもできる。単体近接発見手順では、ソース・デバイス１およびターゲット・デバイス２における近場チップを使用する（例えば、デバイス１、２を一緒に保持することによって起動し、シェーキング・ジェスチャ(shaking gesture)を行う）、他方のデバイスの画面上でバーコードまたはタグを操作する、ユーザの識別子入力、wifiを使用する、Facebookのような第三者アプリケーションまたは任意の他の手段を使用するというようにして、過去のいずれかの時点において、連絡があった、または識別子が他の手段によって交換されたと想定する。

図５は、自動忘却オプション(auto-forget option)がある逆ハッシュ・スタック(inverse hash stack)に基づく単体近接発見手順を示す。図５の例は、特に、再会する確率が高い多くのピア１、２がある環境では有用である。ピア１、２は、それら自体で、何をブロードキャストするか（１０３）、そしてブロードキャスト信号において識別子１２の第２表現３１をどのように暗号化するまたは不明瞭にするか決定する。ブロードキャストされるＴ−ＢＩＤの表現３１は、追跡(tracking and tracing)が非常に困難になるように、ときの経過と共に変化してもよい。

デバイス間通信セッションにあるソース・デバイス１およびターゲット・デバイス２は、双方共、ランダムＴ−ＢＩＤ１２およびソルト５１を生成する（１０１）ことができる。デバイス１、２の双方は、入力として以前のハッシュおよびソルト５１を取る任意のハッシュ関数を使用して、ｎ番目のハッシュ２１を繰り返し計算する。次いで、第１ハッシュは、hash₁ = hash(T-BID,salt)として計算され、後続の全てのハッシュは、hash(previous_hash,salt)として計算される。ｎ番目のハッシュ２１を計算するには、例えば、以下のコードを使用することができる。

hash₁=hash(T-BID,salt);
i=2;while i<=n do {
hash_i=hash(hash_i-1,salt);
}
ここで、Ｔ−ＢＩＤ１２は識別子１２であり、Ｔ−ＢＩＤのｎ番目のハッシュは、識別子１２の第１表現であり、ソルトは識別子１２の第３表現５１である。

デバイス１、２は、それらのｎ番目のハッシュおよびソルトを、ステップ１０２および１０７において交換する。

この段階において、ソース・デバイス１およびターゲット・デバイス２は、ネットワーク３または他のいずれの第三者とも連絡を取る必要なく、後の段階において互いに連絡を取るための十分な情報を有する。

これらが次に近寄るとき、ブロック２０９によって示されるが、ソース・デバイス１は、Ｔ−ＢＩＤの第２表現３１として、Ｔ−ＢＩＤの第（ｎ−１）番目のハッシュ３１をブロードキャストすることができる。次いで、ターゲット・デバイス２はhash(hash_n-1, salt)=直前のハッシュを計算する（１０８）ことができる。このハッシュ関数を知っている盗聴者(eavesdropper)はソルト５１を知らず、したがって、誰が発呼されているのか発見することはできない。

任意に、近接発見手順に先立つ近接検出手順において、ネットワーク３によって、近隣にあるデバイス１、２にはそれらの近接について通知することもできる。このように、ブロードキャスト信号および関係するバッテリ消耗を絶えず監視する必要性を回避することができる。

デバイス１、２の双方は多くのハッシュを所有するので、例えば、毎日、またはこれらが近づく毎に、異なるハッシュを使用すると決定してもよい。次いで、これらがＴ−ＢＩＤの第２表現３１をハッシュとしてブロードキャストする（１０３）場合、これらは、例えば、ブロードキャスト信号３０に、どのハッシュをこれらがブロードキャストしたかを示すカウンタ値ｋを含ませることができる。値ｋは、例えば、（ｎ−ｋ）番目のハッシュ（ｎ引くｋ番目のハッシュ）が、ブロードキャスト信号３０に、識別子の第２表現３１として含まれることを示すとしてもよい。

任意に、例えば、最後のデバイス間通信セッションから経過した日数または時間数に基づいて、ｋがタイマによって与えられる。これは、満了方法(expiry method)を導入するために使用されてもよい。満了方法は、ハッシュ・スタックをやがては使い果たし、最終的に２つのデバイス１、２の「ピア状態」(peerness)を解消する。例えば、デバイス１、２が、それらの初期セキュリティ・アソシエーションが満了した後に再会した場合、これらは再度初期近接発見手順全体を実行しなければならない。

図５の実施形態例は、ターゲット・デバイス２が、ハッシュされたＴ−ＢＩＤの着信毎にハッシュを計算する（１０８）必要がある場合、計算的に負荷が大きくなるおそれがある。これは、ブロードキャストをいつ待機するか示すのをネットワーク３に頼ることによって、低減することができる。代わりに、ブロードキャストされるハッシュの番号を連結することによって（したがって、ｎ−ｋをブロードキャストに追加する）、低減されてもよい。このように、ターゲット・デバイス２は、そのピアの１つから（ｎ−ｋ）番目のハャッシュを予期するのか否かチェックし、次いで着信するブロードキャストに対して（再帰）ハッシュ（１つまたは複数）を計算する（１０８）ことを決定することができる。

図５の近接発見手順は、ネットワーク・カバレッジがないときでもうまく作用するという利点がある（ネットワークが関与する必要がない）。更に、ある時間の後ピアを忘れるメカニズムを有する。これは、課金または登録の目的に使用することができ、着信するブロードキャスト１０３全てに対して再帰ハッシュを計算する計算負荷を低減するメカニズムを可能にする。

図５の例に対する異形として、デバイス１、２自体が、識別子１２を暗号化するためにどの乱数を使用すべきか決定することが可能である。例えば、以前の近接検出手順において、識別子が交換されたことがあるとき、またはネットワークによって供給されたことがあるとき、ネットワークまたは第三者は、デバイス間通信セッションを確立することに関与する必要はない。この代替手順は、次のように作用することができる。

最初に、ソース・デバイス１が乱数５１を計算し、hash(R || T-BID)を計算する。Ｒは乱数５１であり、Ｔ−ＢＩＤは識別子１２である。Ｔ−ＢＩＤは、例えば、ピア特定Ｔ−ＢＩＤ（例えば、図２の例の表に示されるようなｂまたはｊ）であってもよく、誰が発呼元であるか、または誰が発呼先であるか指定できることを意味する。指定されている場合、Ｔ−ＢＩＤは、例えば、セキュリティ・アソシエーションＴ−ＢＩＤ（ＳＡ−Ｔ−ＢＩＤ）であってもよい。

次に、ソース・デバイス１はR || hash(R || T-BID)をブロードキャストする。このブロードキャストを受信したターゲット・デバイス（１つまたは複数）２は、それらのメモリにおけるＴ−ＢＩＤ（恐らくそれら自体も含む）について、関数hash(R || T-BID)を計算し、これらが一致するか否か判定する。一致が発見された場合、引き出すことができる結論は、どのＴ−ＢＩＤがブロードキャストされるかによって異なる。ソース・デバイス１が、それ自体の識別を表すＴ−ＢＩＤをブロードキャストする場合、ソース・デバイス１が範囲内にあることが、ターゲット・デバイス２によって結論付けられてもよい。ソース・デバイス１が、ターゲット・デバイス２の識別を表すＴ−ＢＩＤをブロードキャストした場合、発呼先であるターゲット・デバイス２だけが、それら自体の識別との一致を発見する。悪意のユーザは、ターゲット・デバイス２に発呼されていることを発見するかもしれないが、誰が発呼元かを発見することはできない。ソース・デバイス１が共通セキュリティ・アソシエーション（ソース・デバイス１および／またはターゲット・デバイス（１つまたは複数）２のＴ−ＢＩＤ、および／またはＴ−ＳＡ−ＢＩＤを含むことができる）からＴ−ＢＩＤをブロードキャストした場合、ターゲット・デバイス２は自分が発呼されていると判断することができる。

図５の異形の利点は、ソース・デバイス１自体が、どのようにしてそれ自体を知らせるか決定することができ、誰がブロードキャストしているのかネットワークが発見することを可能にしつつ、高い程度のプライバシーを提供することである。後者は、例えば、課金の理由または法的な傍受(legal interception)に対して有利である。更に他の利点は、ネットワークが関与する必要がなく、したがって本手順は、ネットワーク・カバレッジがなくてもうまく作用することである。

図６の例は、混成解決手段を示し、ネットワークまたは第三者が、ハッシュ関数において使用されるソルトを供給する。図６の例は、図４および図５の例の異形であり、特に、再会する確率が高い多くのピア１、２の場合に有利である。ピア１、２は、識別子１２のような互いについての情報を保持し、互いに識別するためまたは次のＴ−ＢＩＤを発見するために後のセッションにおいてこの情報を使用することができる。

図６の例では、デバイス間セッションにある２つのデバイス１、２が双方共ランダムＴ−ＢＩＤを生成する。これらは、選択したＴ−ＢＩＤ１２を互いに通知する（１０１）。予め定められた時点において、例えば、毎晩または予め定められた時間間隔で、ネットワーク３（または任意の他の第三者）はソルト５１をデバイス１、２に配給する（１０７）。任意にまたは代わりに、２つのデバイス１、２が近くにありチャットを望んでいることを検出した時に、ネットワーク３（または第三者）がソルトを供給する（１０７）のでもよい。ターゲット・デバイス（１つまたは複数）２は、全てのＴ−ＢＩＤ１２についてhash(T-BID, salt)を計算することによって、デバイス１、２の既知のＴ−ＢＩＤ１２、即ち、通知ステップ１０１において受信したＴ−ＢＩＤ１２の第１表現２１を得る（１０２）。ソース・デバイスは、ソース・デバイス１によって使用されるＴ−ＢＩＤ３１の第２表現３１を計算することによって、それ自体のＴ−ＢＩＤ１２に対して同じ計算２１０を実行する。Ｔ−ＢＩＤの第２表現３１は、ブロードキャストされ（１０３）、ターゲット・デバイス（１つまたは複数）２において受信される。ターゲット・デバイス（１つまたは複数）２は、計算したＴ−ＢＩＤの第１表現２１を、受信したＴ−ＢＩＤ１２の第２表現３１と比較し（１０５、１０８）、一致が発見された場合検証する（１０９）。

図６の例の利点は、受信乱数(receive random)のような素早く変化するパラメータを頼り乱数が受信される毎にハッシュを計算する例よりも、計算的に負荷が少ないことである。それでもなお、識別子１２のブロードキャスト側１にとって十分なプライバシーを提供する。

図１〜図６は、本発明の実施形態例の異なる例を示す。本発明は、ここに示される例に限定されるのではない。１つの例において示されるステップが、例えば、他の例において使用されてもよいが、それは示されない。その例は、識別子のハッシング、チケットの利用、追加のチャレンジ−応答検証、および暗号鍵１４を使用するデータの暗号化である。承認メッセージの送信１０６およびデバイス間通信セッションの確立２０６というような、示される他のステップは任意でもよい。

これらの例の中には、識別子１２の派生物２１、３１を計算するためにハッシュ関数が使用される場合がある。尚、派生物２１、３１を作成するために乱数５１を使用する任意の他の数学的関数が代わりに使用されてもよいことは、理解されてしかるべきである。乱数５１は、例えば、サーバ３においてまたはソース・デバイス１において生成された、乱数またはその派生物、サーバ３においてまたはソース・デバイス１において生成されたソルトでもよい。

識別子１２は、グループ・アドレシングに使用されてもよい。例えば、Ｔ−ＢＩＤは、あるグループのデバイス１、２が発呼されていることを示すために使用されてもよい。１つのグループに属するデバイス１、２は、そのグループを表す識別子１２を受信する。他のデバイスを発見するために、これらのデバイスは、例えば、現在の日付けおよび／または時刻、あるいは乱数５１を交換することなくデバイス１、２が共通に知ることができる任意の他の乱数５１に応じて、識別子１２の派生物を計算する。つまり、識別子の第２派生物３１は、x=hash(date || Groupldentifier)として計算することができる。ソース・デバイス１は、ｘをブロードキャストし（１０３）、グループのターゲット・デバイス（１つまたは複数）２は、ｘを受信して、同じ計算hash(date || Groupldentifier)を実行することによって、識別子の第１派生物２１を計算する。第１派生物２１が第３派生物３１と一致した場合、近接発見は成功となる。

一般に、乱数５１が時間変動パラメータである場合、乱数５１は、遅く変化するように、例えば、乱数５１が現在の日付けである場合には１日に１回変化するように、選択されるとよい。その場合、hash(date || Groupldentifier)またはhash(date || identifier)の計算は、１日に１回だけ計算されればよい。一旦その計算が行われたなら、比較１０９だけを行えば済む。図５および図６の例では、この結果、他のデバイスのハッシュが１日に１回だけ計算されればよいので、実行しなければならない計算が少なくなるという利点を得ることができる。

本発明の一実施形態は、コンピュータ・システムによる使用のためのプログラム製品として実現することもできる。プログラム製品のプログラム（１つまたは複数）は、実施形態の機能（本明細書において説明した方法を含む）を定め、種々の非一時的コンピュータ読み取り可能記憶媒体に収容することができる。例示のコンピュータ読み取り可能記憶媒体には、（ｉ）情報が永続的に格納される非書き込み可能記憶媒体（例えば、ＣＤ−ＲＯＭドライブによって読み取り可能なＣＤ−ＲＯＭディスクのようなコンピュータ内部のリード・オンリー・メモリ・デバイス、ＲＯＭチップ、または任意のタイプのソリッド・ステート不揮発性半導体メモリ）、および（ｉｉ）変化可能な情報が格納される書き込み可能記憶媒体（例えば、ディスケット・ドライブ内におけるフラッシュ・メモリ、フロッピ・ディスク、またはハード・ディスク・ドライブ、または任意のタイプのソリッド・ステート・ランダム・アクセス半導体メモリ）が含まれるが、これらに限定されるのではない。

Claims (11)

1. ソース・デバイス（１）と１つ以上のターゲット・デバイス（２）との間における近接発見のための方法であって、前記ソース・デバイス（１）と前記１つ以上のターゲット・デバイス（２）が通信可能にネットワークに接続されるように構成され、
   ソース・デバイス（１）において、前記ネットワーク内のサーバ（３）から、識別子（１２）を含む第１データ（１１）を受信するステップ（１０１）であって、前記識別子（１２）が前記ソース・デバイス（１）を一意に識別する一時的ブロードキャスト識別子であり、前記識別子（１２）が、前記ターゲット・デバイス（２）によって前記ソース・デバイス（１）と関連付け可能である、ステップと、
   前記ターゲット・デバイス（２）において、前記サーバ（３）から、前記ソース・デバイス（１）の前記識別子（１２）の第１表現（２１）を含む第２データ（２０）を受信するステップ（１０２）と、
   前記ソース・デバイス（１）によって、前記ソース・デバイス（１）の前記識別子（３１）の第２表現を含む信号（３０）をブロードキャストするステップ（１０３）と、
   前記ターゲット・デバイス（２）において前記信号（３０）を受信するステップ（１０４）と、
   前記ターゲット・デバイスにおいて、前記識別子（１２）の前記第１表現（２１）を前記識別子（１２）の前記第２表現（３１）と比較して、近接発見成功を確定するための比較結果を得るステップ（１０５）と
   を含む、方法。
2. 請求項１記載の方法であって、更に、前記ターゲット・デバイス（２）から前記ソース・デバイス（１）に、前記比較結果に応じて、承認メッセージ（４０）を送信するステップ（１０６）を含む、方法。
3. 請求項１または２記載の方法において、前記識別子（１２）、前記識別子（１２）の前記第１表現（２１）、および前記識別子（１２）の前記第２表現（３１）が同一である、方法。
4. 請求項１から３のいずれか１項記載の方法であって、更に、前記ターゲット・デバイス（２）において、前記識別子（１２）の第３表現（５１）を含む第３データ（５０）を受信するステップ（１０７）を含み、前記識別子（２１）の前記第１表現が、第１数学関数によって得られる前記識別子の派生物であり、前記第１数学関数が、前記識別子の前記派生物を計算するために前記識別子（１２）および乱数を入力として使用し、前記識別子（１２）の前記第３表現（５１）が前記乱数であり、
   前記比較するステップ（１０５）が、
   前記識別子（１２）の前記第２表現（３１）および前記識別子（１２）の前記第３表現（５１）を入力として使用する前記第１数学関数と同一である第２数学関数を使用して、前記識別子の前記派生物を計算するステップ（１０８）と、
   前記計算した識別子の前記派生物を、前記識別子（１２）の前記第１表現（２１）と比較するステップ（１０９）と
   を含み、
   前記乱数が、
   前記サーバまたは前記ソース・デバイス（１）において生成された乱数、
   前記サーバ（３）または前記ソース・デバイス（１）において生成されたソルト、
   第３数学関数によって前記サーバ（３）または前記ソース・デバイス（１）において得られた更に別の乱数の派生物であって、前記第３数学関数が、前記乱数の前記派生物を計算するために、前記更に別の乱数および前記ソース・デバイス（１）を識別するソース識別子を入力として使用する、更に別の乱数の派生物、
   の内１つである、方法。
5. 請求項１から４のいずれか１項記載の方法において、前記第２データ（２０）が、更に、チケット識別子（２２）を含み、当該方法が、更に、
   前記サーバ（３）から、前記ソース・デバイス（１）において、前記チケット識別子（２２）を含むチケット・データ（１０）と、前記第１データ（１１）と、第４データ（１３）とを受信するステップ（１１０）と、
   前記チケット識別子（２２）に関連付けられた前記第４データ（１３）のコピー（４１）を得るために、前記ターゲット・デバイス（２）から前記サーバ（３）に、前記チケット識別子（２２）を送信するステップ（１１１）と、
   前記サーバ（３）から、前記ターゲット・デバイス（２）において、前記第４データ（１３）の前記コピー（４１）を受信するステップ（１１２）と
   を含み、
   前記承認メッセージ（４０）が、前記ソース・デバイス（１）における前記第４データ（１３）との検証のために、前記第４データ（１３）の前記コピー（４１）を含む、方法。
6. 請求項１から５のいずれか１項に記載の方法であって、更に、前記サーバ（３）の運用業者によって、前記ソース・デバイス（１）または前記ターゲット・デバイス（２）からの前記第１データ（１１）、前記第２データ（２０）、および／または前記チケット・データ（１０）に対する要求に課金するステップを含む、方法。
7. 請求項５または６記載の方法であって、更に、
   前記ソース・デバイス（１）から前記ターゲット・デバイス（２）において、第１チャレンジ・データ（３２）を受信するステップ（１１３）と、
   前記ターゲット・デバイス（２）において、第４数学関数、例えば、ハッシュ関数を前記第１チャレンジ・データ（３２）に対して使用して、派生第１チャレンジ・データ（４２）を計算するステップ（１１４）であって、前記承認メッセージ（４０）が、更に、前記派生第１チャレンジ・データ（４２）と第２チャレンジ・データ（４３）とを含む、ステップ（１１４）と
   を含み、当該方法が、更に、
   前記ソース・デバイス（１）において、前記受信した派生第１チャレンジ・データ（４２）との比較のために、前記第４数学関数と同一である第５数学関数を前記第１チャレンジ・データ（３２）に対して使用して、前記派生第１チャレンジ・データ（４２）を計算するステップ（１１５）と、
   前記ソース・デバイス（１）において、第６数学関数を前記第２チャレンジ・データ（４３）に対して使用して、派生第２チャレンジ・データ（３３）を計算するステップ（１１６）と、
   前記派生第２チャレンジ・データ（３３）を前記ターゲット・デバイス（１）に送信するステップ（１１７）と、
   前記ターゲット・デバイス（２）において、前記受信した派生第２チャレンジ・データ（３３）との比較のために、前記第６数学関数と同一である第７数学関数を前記第２チャレンジ・データ（４３）に対して使用して、前記派生第２チャレンジ・データ（３３）を計算するステップ（１１８）と
   を含む、方法。
8. 請求項７記載の方法において、前記チケット・データ（１０）が、更に、暗号鍵（１４）を含み、当該方法が、更に、前記サーバ（３）から、前記ターゲット・デバイス（１）において、前記サーバ（３）において前記チケット識別子（２２）に関連付けられた前記暗号鍵（１４）を受信するステップ（１１９）を含み、前記第４、第５、第６、および第７数学関数が、前記暗号鍵（１４）を使用する暗号関数を含む、方法。
9. 請求項１から８のいずれか１項記載の方法を使用して、１つ以上のターゲット・デバイス（２）と共に近接発見手順を実行するように構成されたソース・デバイス（１）。
10. 請求項１から８のいずれか１項記載の方法を使用して、ソース・デバイス（１）と共に近接発見手順を実行するように構成されたターゲット・デバイス（２）。
11. 請求項９記載のソース・デバイス（１）と、請求項１０記載の１つ以上のターゲット・デバイス（２）とを含むネットワーク。

Images