JP6166780B2 - 無線通信チャンネル及び対応するテレコミュニケーションシステムを確立するように構成される通信デバイスからのインタラクションを実行するための方法 - Google Patents

Description

本発明は、インタラクションを実行するための方法に関し、特に、第１の無線通信チャンネルを確立するように構成される第１の通信デバイスと上記第１の無線通信チャンネル上で動作するように構成される１つもしくはそれ以上の第２のデバイスとの間の「信頼できる」インタラクションを実行するための方法に関する。

上記無線通信チャンネルは、発見動作の実行が上記第１の無線通信チャンネルの動作半径内の上記無線通信チャンネル上で目に見えるかもしくは発見可能なデバイスを探索することを可能とさせるように適切である。

上記方法は、上記第１の通信デバイスが上記無線通信チャンネル上のそのデバイス属性が目に見えるように公開し、上記１つもしくはそれ以上の第２のデバイスにより公開される上記無線通信チャンネル属性を介して目に見えるように検出することを予測し、上記第１の通信デバイスは、可視デバイスの格納される属性を備えるデータベースにアクセスする。

通信デバイスは、近接して知られたときに無線通信チャンネルを確立するように構成され、そのような近接もしくは近接距離はそのような無線チャンネルの動作半径、特に近隣デバイスを探すのに有用である動作半径により定義される。例えば、そのようなデバイスは、例えば携帯電話などの通信端末装置の複雑なデバイスやデータをそれらをインタロゲートするデバイスに供給するための単一の無線通信チャンネルが備えられた、よりシンプルなデバイスを含んでもよい。ここで特に、私たちは、そのようなローカル通信チャンネル上のデバイス属性の公開を介して及び通信チャンネル上で公開されるデバイスの属性を読み出す能力を介して近接して位置されるそのような無線通信チャンネルデバイス上で検出できる通信デバイスに言及する。換言すれば、以下では、デバイスが少なくとも発見可能能力、すなわち探索できるもしくは探索できるように可視化できる能力を有するデバイス発見動作を管理できる通信デバイスが参照される。従って、好ましくは、これは、ブルートゥースプロトコル上で動作しブルートゥースプロトコルを使用してチャンネルを利用する周辺機器もしくは送受信機が備えられるデバイスに言及する。しかしながら、以下で説明されることは、例えばＩＥＥＥ８０２．１１標準に従って動作するワイファイ（Ｗｉ−Ｆｉ）（ワイヤレスフィディリティ）などの発見動作を実行する他の無線通信プロトコルにもまた適用可能である。

しばしば、そのようなタイプの無線チャンネルを使用するそのようなデバイスは、信頼できない「信頼されない」タイプのデバイスである。その理由は、上述されたトランザクションでは、それらの同一性（アイデンティ）は確実に知られていないからである。「トラステッドされる」、信頼できる、もしくは「信頼されない」の用語は、悪意のあるユーザの導入に対するセキュリティーメカニズム（機構）及び例えばデータ窃盗もしくはスパムなどのサイバー攻撃に対するセキュリティーメカニズム（機構）が導入されるデバイスがどうかで定義するように使用される。

従って、「信頼されない」タイプのデバイス間での完全なダイレクト接続を行うことは不利であるかもしれない。その理由はまさに、これによりデバイスが上述した情報攻撃のリスクにさらされるであろうからである。

次に、もし検出されたデバイスの正確な識別に加えて、そのようなデバイスにより実行されるサービスもしくはアプリケーションが、これがそれがインタラクトするデバイスが実際には近隣に存在する、すなわち例えばブルートゥース周辺機器の動作範囲の半径内に位置されることのある程度の確実性をともなうことを必要とするのであれば、そのようなセキュリティ問題は増幅される。

特許文献１は、複数のデバイス識別子を複数のDevice_Namesに関連付けるデータベースのローカル記憶装置を予測する、ブルートゥースプロトコル下で動作するローカルデバイスを識別するための方法を開示する。次に、近接するデバイスからデバイス識別子を受信するローカルデバイスは、データベースにおいてDevice_Nameを探索するであろう。

これがここではマスターデバイスとスレーブデバイスと呼ばれるローカルデバイス間の十分な接続を確立することの必要性を克服し、近接するデバイスのリストを取得したローカルマスターデバイスがそれらのそれぞれに対してネーム発見手順を実行すべきことを回避する。

米国特許出願公開第２００５／０，２２０，２２１号明細書

しかしながら、そのような方法は多くの不利益を有し、その中の１つに、複数のデバイス識別子を複数の「フレンドリーな」デバイスのネームに関連付けるそのようなデータベースをデバイス上に格納することの必要要件がある。またさらに、そのような方法は、悪意のあるユーザが（例えば、ＭＩＴＨ、すなわち介入者手順を用いるなどの）非合法な方法で識別処理の間、傍受される可能性があるかもしくはいくつかのケースでは公開情報から得られる可能性があるそのような識別子及びDevice_Namesを使用するデバイスと接続することを回避しない。

また、この方法では、近接するデバイスの誤った識別がなされ、誤った情報が所定の検出されたデバイスの発見を実行しているデバイスに近接した実際の位置上で取得される。

本発明は、発見容量を有する無線通信チャンネルを備えるデバイスが、デバイスの情報もしくはサービスに続けてアクセスする前に、認定された方法で、近接検出の条件を確立する正確でありかつ安全な方法でそのような通信チャンネルを動作できるデバイスとインタラクトすることを可能とさせる方法を提供することを目的とする。

本発明によれば、そのような目的は、特に添付の特許請求の範囲に記載される特徴を有する方法及び対応するテレコミュニケーションシステムにより実現される。

本発明が、例示のためだけに提供され必ずしも限定されない添付の図面を参照して説明されるであろう。

本発明に係る方法を実行するシステムの概念図である。 本発明に係る方法の起動要求を例示するフロー図である。 本発明に係る方法の起動段階に関するフロー図である。 本発明に係る方法を動作するデバイスの公開される属性の検出の起動を表す。 本発明に係る方法のクライアント側認証要求である。 本発明に係る方法のサーバ側認証段階に関するフロー図である。 本発明に係る方法のクライアント側認証段階に関するフロー図である。 本発明に係る方法のクライアント側登録要求に関するフロー図である。 本発明に係る方法のサーバ側登録段階に関するフロー図である。 本発明に係る方法のクライアント側登録段階に関するフロー図である。 本発明に係る方法のサーバ側復号化段階に関するフロー図である。 本発明に係る方法のクライアント側復号化段階に関するフロー図である。

簡単に、その方法は、無線通信チャンネルを備える第１のデバイスが発見動作を実行しそのような無線通信チャンネル上で発見可能となることを予測する。そのような動作の間に検出されたデバイスの属性は、その固有のシステム識別コードと一緒に、クライアントとして動作する第１のデバイスから、認証される方法で近接する検出サービスを実行し、そのようなデータベースを使用するサービスに登録されるデバイスに対する属性のリストを備えるデータベースに関連するコンピュータサーバに送信される。また、サーバコンピュータは、例えば、そのようなデータベースにおいて、検出されたデバイスのそのような属性の検出を記録する。

そのデータベースにおいて、第１のデバイスもしくは検出されたデバイスがサービスに登録されるかどうか、すなわちそれらが加入者がどうかを検証することに加えて、もしそれらが加入者であれば、検出されたデバイスのシステム識別子が取得される。またさらに、第２のデバイスの検出に加えて、当該第２のデバイスが第１のデバイスにより登録されたかどうか、所定の時間期間において第２のデバイスにより第１のデバイスの検出がまた行われたことが登録されたかどうかを検証する。

次に、第２のデバイスのシステム識別子及びサーバで実行されるそれらの検査の結果は、そのようなクライアントデバイスが第２のデバイスにアクセスするモードを決定するために使用する第１のクライアントデバイスに送信される。

任意のケースでは、そのようなアクセスは、第１のクライアントデバイスとサーバとの間の通信チャンネルにより発生し、可能であればそのようなアクセスは、アクセスのモードに従って、第２の検出されたデバイスとサーバとの間の通信チャンネルをまた利用することを含んでもよい。

有利に、この方法では、発見動作の結果として、第１のデバイスは、特に登録もしくは加入、検出されたデバイスが登録されることを指示する復号化メッセージ、及びサービスにおいてそれを区別するそのシステム識別子を要求するサービスを実行する「信頼できる」タイプのサーバから取得されてもよい。本質的に、これが本発明の第１の発明の態様を構成し、それが検出されたデバイスの近接の指示及びそのようなシステム識別子を用いて検出されたデバイスの情報もしくはサービスへのアクセスモードの定義を可能とさせる。

また、本発明に係る方法及びシステムのさらなる発明の態様によれば、互恵的な発見が起こったこと示す、すなわちサービスに登録される２つのデバイス間で双一義語の検出が起こったことを示す復号化メッセージが送信される。それ故に、近接の識別は第１のアクセスモードに従って動作できる、より高レベルの確実性に関連し、第１のアクセスモードは攻撃のリスクにより晒されるかもしくは含まれるデバイス間の近接の高い程度の認証が必要とされるトランザクションを予測する。またさらに、第１のデバイスは、第２のデバイスの第１の登録されるデバイスだけによる双一義語を検出しまた登録されたことを示すメッセージを受信し、それ故に、近接の識別は第２のアクセスモードに従って動作できる、より低レベルの確実性に関連する。ここで、第２のアクセスモードはほとんどリスクのないトランザクションもしくは含まれるデバイス間の近接の高い程度の認証が必要とされないトランザクションを予測する。また、固有の検出は、登録されるがそれ自身の検出をサーバに送信する能力が欠如しそれ故に（例えば、サーバと第２のデバイスとの間のチャンネルを予測しないインタラクションである）対応するタイプのインタラクションを必要とする第２のデバイスの検出を指示することができる。第１のデバイスもしくはより一般的には第２の検出されたデバイスが登録されそうでないとき、第１のデバイスは、サーバ上で実行される認証される近接検出サービスの目的のために、第２の検出されたデバイスに近接して存在しないことが考慮されることに従ってメッセージを受信する。

従って、図１は本発明に係る方法を実行するテレコミュニケーションシステムを示す。ここで、ユーザ１１は第１の通信デバイス２１を備え、第２のユーザ１２は第２のデバイス２２を備える。第１のデバイス２１及び第２のデバイス２２は、無線通信チャンネル３０を形成し、発見動作が実行されてデバイスが見えるようになってもよいしもしくは発見可能となってもよいプロトコルをサポートするのに適切な送受信手段を備える。換言すれば、そのような無線通信チャンネル３０上で、第１のデバイス２１は、近接して位置される、すなわち無線通信チャンネル３０を実現する送受信手段の機能範囲において位置されるアナログ無線通信チャンネル３０を備えるデバイスを検出することができ、そのデバイスの属性を公開することができる。限定されない例として、そのようなローカル通信チャンネル３０は、ブルートゥースプロトコルに従って動作する通信チャンネルとすることができ、それ故に各デバイス２１または２２は、対応する周辺機器、すなわちブルートゥースプロトコルに従って動作する送受信機を備える。説明される実施形態における各デバイス２１または２２はさらに、データを遠隔コンピュータ５０に交換するためのそれぞれの第２の通信チャンネル４１または４２を確立できる周辺機器もしくは送受信機を備える。以下に詳細説明するように、一般的には、本発明に係る方法の実施のために、まさに第１のデバイスでさえも第２の通信チャンネル４１を確立するための周辺機器を備えることができる。

本実施形態では、一般的には、通信デバイス２１及び２２は、ダイレクト接続のためのチャンネルを確立するための、より好ましくは、ブルートゥース接続を確立するための送受信手段を備える計算（コンピューティング）能力及びメモリを有するコンピュータである。好ましくは、それは例えば携帯電話、スマートフォン、コンピュータタブレットもしくはポータブルコンピュータなどのモバイルデバイス（携帯機器）とすることができる。たとえその方法がまた「信頼できる」タイプのエンティティにも適用可能でも、そのようなデバイスは、「信頼されない」タイプのエンティティである。

例において、第２の通信チャンネル４１もしくは４２は同一のタイプのチャンネルであり、例示的なデバイス２１及び２２は例えばＵＭＴＳ通信を介して動作する２つの携帯電話端末装置である。また、一般的に、それらがそれぞれの通信デバイスが遠隔コンピュータサーバ５０に到達できる任意のタイプの接続を実現するという条件で、第２のチャンネル４１及び４２はお互いに異なってもよい。例えば、それは２Ｇ、３Ｇ、４Ｇ、もしくはＡＤＳＬ接続とすることができる。従って、一般的に、遠隔コンピュータサーバ５０は、例えばインターネットプロトコルなどのテレコミュニケーションネットワークのみならずＨＴＴＰプロトコルを介して接続されるが、サーバとクライアントデバイスとの間でデータ交換を確立するのに適切な他のタイプのネットワークを介してもまた接続される。

遠隔コンピュータサーバ５０は、そのようなコンピュータ５０で表示されるが、一般的にはサーバ５０がアクセスできるもう１つのコンピュータ上に存在するデータベース６０にアクセスし、特に遠隔プロセッサ５０がクライアントとして動作するデバイス２１に対する供給者として動作するためのウェブサービスである特にサービス８０のコンテキストにおけるデータベース６０における情報リカバリィ動作並びにデータの書き込み及び編集を実行するのに適している。そのようなサービス８０は、本発明に係る方法を詳細に説明するときに以下に詳細に説明されるであろうが、サービス８０は本質的には、クライアントデバイスとその近傍で検出される任意のデバイスとの間の近接を認証される方法で検証するように、データベース６０とのコンサルティングを介して、近接して発見されるデバイスの属性の復号化を供給する。

一般的に、コンピュータサーバ５０は、コンピューティング能力を有する１つもしくはそれ以上のプロセッサとメモリとを含み、「信頼できる」エンティティとして動作するように構成される。当業者には自明であろうが、データベース６０は（相関的な、階層的な、ネットワークもしくはオブジェクトの）特定の論理モデルに従ってかつ特別のソフトウェアアプリケーションによりデータ自身の管理（検索もしくはクエリー、挿入、消去及び更新）を可能とさせるような方法で接続される一連のアーカイブを備えるデータ構造の例示である。また、当業者には自明であろうが、サーバ５０によりアクセス可能なそのようなデータベース６０はサーバとして動作し及び／もしくはサーバ５０上でその方法を実行しデータベース６０自身にアクセスするサービスの部分８０ｂを実行するコンピュータ内に必ずしも含まれない。

本発明に係る方法は４つの主な段階を含む。
−サービス８０の起動段階、
−サービス８０上でのクライアントデバイス２１の認証段階、
−サービス８０におけるクライアントデバイス２１の登録段階、
−検出されたデバイス２２の属性の復号化の段階。

上述したように、その方法の主要な目的は、任意の検出されたデバイス及びサーバにより検出される（例えば非一義的な、双方向一義的なもしくは非近接的ななどの）近接検出のモードの識別子をクライアントデバイスにリターンする復号化段階である。さらに、起動、認証及び登録段階は、方法を完了する段階及び復号化メッセージの形成に属することの結果である。

一般的に、以下の説明では、特に例えばスマートフォンやポータブルコンピュータなどのクライアントデバイスを用いて、複数のユーザプロファイルが定義されそれ故にクライアントデバイス２１はそれを利用するユーザによって異なる認証情報を送信できることが可能となるが、私たちはユーザ１１の認証情報Ｃ及びデバイス２１の認証情報Ｃが同一であると仮定するであろう。

本発明に係る方法の上述した段階は、上述したように、好ましくは他のシステムが適切な「メッセージ」によりインターフェースにおいて説明される動作を可能とさせるサービスとの相互作用することを可能とさせるソフトウェアインターフェースを供給するのに適切である、同一のネットワーク上の異なるコンピュータ間の相互動作性をサポートするように設計されるサービスもしくはソフトウェアシステムを介して実行される。好ましくは、そのサービスは、例えば、例えばＪＳＯＮ（ジャバスクリプトオブジェクトノーテーション）などのフォーマットでのメッセージをＨＴＴＰプロトコルを用いて交換するウェブサービスである。代わりに、例として、ＸＭＬメッセージを使用することが可能である。

システムソフトウェアとしてのサービスは、コンピュータサーバ５０上で動作するアプリケーション８０ａにより指示されるサーバ側により実行される部分と、クライアント側上で実行される、すなわちそのようなクライアントデバイス２１における例において導入されかつ動作するアプリケーション８０ｂにより指示されるクライアントデバイス２１の側から実行される部分とを含む。これがその最も一般的な形式での方法を実行するのに必ずしも必要ではないのだが、検出されたデバイス２２はそのようなクライアント側のアプリケーション８０ｂを備えることが可能である。

一般的に、用語「サービス」は、上述定義されるサービスに言及されるが、典型的には、アプリケーションソフトウェアはクライアントデバイス２１上及びサーバ５０上に導入され、ＡＰＩ（アプリケーションプログラミングインターフェース）が導入されるであろう。

従って、コンピュータサーバ５０は、サービスを「サービスリクエスタ」として動作するクライアントデバイスに供給する「サービスプロバイダ」として構成される。より詳細に以下に例示して説明されるように、サーバ５０上に導入されるサービス８０ａの部分は、データベース６０を管理する。

サービス８０は、クライアントデバイス２１による発見動作の実行により決定される近接検出サービスの認証として定義される。その認証は、近接検出を取得するために、少なくともデバイス２１がサービスを用いて登録され、すなわちサーバ５０上で登録されるデバイスのリストにおいて存在することが必要であるという事実に由来する。

本発明に係る方法は、サービス８０において登録される各クライアント２１もしくは検出されたデバイス２２に対して、その属性ＡＭまたはＡＳ及びデータベースのみならず、デバイスがそのようなデータベース６０内に格納されることに関連して以下に説明されるであろう一義的検出もしくは双方向一義的検出のすべてにおいてそれを特に識別するシステム識別子ＩＤＭまたはＩＤＳのリストを予測する。以下に説明するように、未登録デバイスは非近接モードを決定する。

一義的検出は、第１のデバイスによる第２のデバイスの検出だけがデータベースにおいて記録されることを示す。双方向一義的検出は、第１のデバイスによる第２のデバイスの検出がデータベースに記録されるのみならず所定の時間期間内の第２のデバイスによる第１のデバイスの検出もデータベースに記録されることを意味する。

図２は、本発明に係る方法の起動のための要求を例示するフロー図である。

第１のデバイス２１は、上述したように、クライアントデバイスとして定義される。その理由は、それがサービス８０により定義されるコンピュータサーバ５０に対する容量で動作するからである。一般的にはソフトウェアモジュール８０ｂを必ずしも実行しないデバイス２２は、それが第１のチャンネル３０上の発見動作においてクライアントデバイス２１により検出されたという点において、ここでは発見されるデバイスとして定義される。

次に、ステップ２１では、ユーザ１１は、彼のクライアントデバイス２１を介して、クライアント側アプリケーション８０ｂ上で動作するクライアント側からサービス８０の起動を要求する

次に、ステップ２２０では、クライアント側サービス８０ｂは、ユーザ１１の認証を検証する。

ステップ２３０では、もしユーザ１１が認証されなければ、図５で図示されるように、認証情報Ｃがクライアントデバイス２１内にエントリーされる、クライアント側上の認証要求段階へと移行される。

ステップ２４０では、もしユーザ１１もしくはクライアントデバイス２１がすでに認証されれば、クライアント側サービス８０ｂはクライアントデバイス２１上で開始される。

ステップ２５０では、クライアント側の公開の起動段階へと移行される。

ステップ２６０では、平行して、サービスクライアント側８０ｂによるクライアントデバイス２１上で公開される属性２６０の検出の起動段階へと移行される。

図３は、クライアントデバイス２１の、ここで説明される例示的な実施形態ではブルートゥースプロトコルを実行する、サービス８０ｂ（クライアント側）が起動して無線通信周辺機器３０を（発見可能な）公開可視性に設定するクライアントデバイス２１による公開の起動段階に関連するそのようなステップ２５０に関連するフロー図である。

ステップ２５１では、ローカル通信ブルートゥース周辺機器３０は、ブルートゥースプロトコル標準に従って、クライアントデバイス２１の属性ＡＭを送信する。クライアントデバイス２１のそのような属性ＡＭは、以下のうちの１つもしくはそれ以上を含む。
−（例えばデバイスネーム、デバイスアドレスなどの）周辺機器の属性、
−（例えばサービスネーム、ＵＵＩＤなどの）サービスの属性、
−（例えばセッションＩＤなどの）セッションの属性、
−（例えばピアＩＤ、ピアネームなどの）ピア属性、
−例えばブルートゥースなどのチャンネル３０を介して、（クライアントデバイス２１に対して）ペアが構成されないもしくは接続されないもう１つのデバイスの、例えばブルートゥースなどのチャンネル３０上で動作するもう１つの周辺機器へ送信可能な任意の属性。

たとえ無線通信チャンネル３０がＷｉ−Ｆｉタイプのものであったとしても上で列挙された、対応する属性を見つけることは可能である。例えば、デバイスネーム識別子の代わりにＳＳＩＤ（サービス設定識別子）が使用され、デバイスアドレス識別子の代わりにＢＳＳＩＤ（基本サービス設定識別子）が使用される。

図４は、クライアント側サービス８０ｂによりクライアントデバイス２１上に公開される検出属性の起動を示す概略図である。

次に、ステップ２６１では、クライアント側サービス８０ｂは、近接する公開可視性を有する周辺機器、すなわち無線通信チャンネル３０の動作範囲内の周辺機器を有する１つもしくはそれ以上のデバイス２２の探索を開始する。特に、標準ブルートゥースサービス（デバイス発見）によるより好ましい実施形態によれば、クライアント側サービス８０ｂは、（発見可能な）公開可視性に設定されるアクティブブルートゥース周辺機器に近接するすべてのデバイスの探索を開始し、デバイス２２だけが存在する例では、検出される各デバイスに対して、以下の１つもしくはそれ以上を含んでもよい検出されたデバイスに関連する可能性がある属性のリストを受信する。
−（例えばデバイスネーム、デバイスアドレスなどの）周辺機器の属性、
−（例えばサービスネーム、ＵＵＩＤなどの）サービスの属性、
−（例えばセッションＩＤなどの）セッションの属性、
−（例えばピアＩＤ、ピアネームなどの）ピア属性、
−例えばブルートゥースなどのチャンネル３０を介して、（クライアントデバイス２１に対して）ペアが構成されないかもしくは接続されないもう１つのデバイスの、例えばブルートゥースなどのチャンネル３０上で動作するもう１つの周辺機器へ送信可能な任意の属性。

また、このケースでは、たとえ無線通信チャンネル３０がＷｉ−Ｆｉタイプのものであったとしても上で列挙された、対応する属性を見つけることが可能となる。

ステップ２６１では、そのような探索動作は、クライアント側サービス８０ｂがクライアントデバイス２１のユーザ１１により傍受されるまで周期的に反復される。

次に、ステップ２６２では、クライアント側サービス８０ｂはステップ２６１での探索がデバイス２２を発見したかどうかを検証する。

ステップ２６３では、ステップ２６１での探索によりリターンされる各結果に対して、クライアント側サービスは、少なくとも以下の情報を含む復号化要求メッセージＭ２６３をコンピュータサーバ５０に送信する。
−より詳細に後述説明される、ステップ２３８での認証段階においてもしくはステップ５５０での登録段階において受信されるシステム識別子ＩＤＭ、
−このケースではステップ２６２で検出されたデバイス２２である検出される１つもしくはそれ以上のデバイスに関連する検出される属性リストＡＳ。

システム識別子は、登録段階の間に、サーバ側上のサービス８０ａによりユーザもしくはデバイスに対して割り当てられる（ユーザにより選択されない）コードシステムを意味する。サーバ５０からの及びサーバ５０へのすべての通信はこの識別子を用いて実行される。

復号化要求メッセージＭ２６３は、例えばクライアントデバイス２１のＧＰＳ位置などの供給される他の可能性があるデータを含んでもよい。

次に、ステップ６００では、サーバ側復号化段階へと移行される。

図５は、クライアント側サービス８０ｂが最初にクライアントデバイス２１からの（もしくはユーザ１１からの）認証要求を管理するクライアント側認証要求２３０を例示する。

ステップ２３１では、クライアント側サービス８０ｂは、ユーザ１１からの入力を介してもしくはデバイス２１内のメモリの適切な領域からそれを自動的に引っ張ってくることにより、ステップ２５１に関連して上で詳細列挙された、クライアントデバイス２１に対する１つもしくはそれ以上の属性ＡＭを識別する。

ステップ２３２では、クライアント側サービス８０ｂは、少なくとも以下の情報を含むメッセージＭ２３２をコンピュータサーバ５０に送信する。
−ユーザ１１の認証情報Ｃ及びクライアントデバイス２１の認証情報Ｃ、
−ステップ２３１で識別される属性ＡＭ。

ステップ２３３では、サーバ側認証段階へと移行される。

図６は、サーバ側サービス８０ａが認証処理を管理するサーバ側からの認証のそのような段階に関するフロー図である。

次に、ステップ２３４では、そのようなサーバ側サービス８０ａは、ステップ２３２でクライアントデバイス２１から送信される、認証情報Ｃ及び属性ＡＭを含むメッセージＭ２３２を受信する。

ステップ２３５では、サーバ側サービス８０ａは、ステップ２３４で受信されるメッセージＭ２３２により指示されるユーザ１１もしくはクライアントデバイス２１がサービス８０によりサーバ側上で登録されたかどうか、すなわち認証情報Ｃ及び属性ＡＭがデータベース６０内に対応する登録を有するかどうかを検証する。

もしそうでなければ、ステップ２３６では、サーバ側サービス８０ａは、認証が要求されるユーザがサービス８０において登録されていないことを示すメッセージＭ２３６をクライアントデバイス１１に送信する。

ポジティブなケースでは、ステップ２３７では、サーバ側サービス８０ａは、サービス８０と一緒に使用するためのデータベース６０に登録される認証情報Ｃに対して、ステップ２３４で受信されるメッセージＭ２３２において示されるユーザ１１もしくはクライアントデバイス２１の認証情報Ｃが正確であるかどうかを検証する。

もしそうであれば、ステップ２３８では、サーバ側サービス８０ａは、以下に示すように、供給される認証情報Ｃが正確であることを示すメッセージＭ２３８及び登録のときにユーザ１１もしくはクライアントデバイス２１に対して割り当てられたシステム識別子ＩＤＭを示すメッセージＭ２３８をクライアントデバイス２１に送信する。

もしそうでなければ、ステップ２３９では、サーバ側サービス８０ａは、供給される認証情報Ｃが正確でないことを示すメッセージＭ２３９をクライアントデバイス２１に送信する。

次に、ステップ３００では、クライアント側認証段階へと移行される。

図７は、サーバ側サービス８０ａが認証処理を管理するそのようなサーバ側認証段階に関するフロー図である。

次に、ステップ３１０では、クライアント側サービス８０ｂは、ステップ２３６、ステップ２３８、もしくはステップ２３９でコンピュータサーバ５０により送信されるメッセージ、すなわち認証が要求されるユーザがデータベース６０内に登録されなかったことを示すメッセージＭ２３６、認証情報Ｃが正確でありかつユーザ１１に対して割り当てられるシステム識別子ＩＤＭであることを示すメッセージＭ２３８、もしくは供給される認証情報Ｃが正確でないことを示すメッセージＭ２３９を受信する。

ステップ３２０では、クライアント側サービス８０ｂは、受信されるメッセージがステップ２３６のメッセージＭ２３６であるかどうかを調べる。

もしそうでなければ、ステップ４００では、クライアント側サービス８０ｂは、クライアント側からの登録を実行する。すなわち、認証手順が成功しなかった及びユーザ１１もしくはクライアントデバイス２１が登録されないことを格納する、クライアントデバイス２１において利用可能な記憶媒体内への登録を実行する。クライアント側サービス８０ｂは、クライアントデバイス２１を介してユーザ１１に対する登録要求を提案する、クライアント側４００上の登録要求段階へと移動する。また、登録に対するそのような要求は選択的であってもよい。

従って、ステップ３３０において、ステップ３２０でのポジティブな結果の場合では、クライアント側サービス８０ｂは、受信されたメッセージがステップ２３８のメッセージＭ２３８かもしくはステップ２３９のメッセージＭ２３９かどうかを調べる。

ステップ３４０では、クライアント側サービス８０ｂは、認証処理、ユーザ認証、及びクライアントデバイス２１上のクライアント側からのサービス８０におけるサービスサーバ側８０ｂにより割り当てられるシステム識別子ＩＤＭを記録する。

ステップ３５０では、クライアント側サービス８０ｂは、認証手順が成功せずにユーザが認証されなかったことをクライアントデバイス２１上のクライアント側から登録する。

図８は、クライアント側サーバ８０ｂが登録要求を管理するクライアント側４００上の登録要求段階を図示する。

ステップ４１０では、クライアント側サービス８０ｂは、手動的にもしくは自動的にクライアントデバイス２１に対する１つもしくはそれ以上の属性ＡＭを識別する。

ステップ４２０では、クライアント側サービス８０ｂは、少なくとも以下の情報を含むメッセージＭ２３９かどうかを４２０をコンピュータサーバ５０に送信する。
−ユーザの認証情報Ｃ、
−ステップ４１０で識別されるクライアントデバイス２１に関する属性ＡＭ。

次に、サーバ側登録段階５００へと移行される。

例として、クライアント側登録要求段階４００において、２人の一般的なユーザＡ及びユーザＢを仮定する。ここで、ユーザＡは以下の属性を用いて登録する。
・デバイスネーム：MyName_A、
・デバイスアドレス：F0:DC:B2:BA:E8:5D。

また、ユーザＢは以下の属性を用いて登録する。
・デバイスネーム：MyName_B、
・ピアＩＤ：MyPeer_B。

図９は、サーバ側サービス８０ａがサービスに対する登録の処理を管理するサーバ側登録ステップ５００を図示する。

ステップ５１０では、サーバ側サービス８０ａは、ステップ４２０でクライアントデバイス２１により送信される認証情報Ｃ及び属性ＡＭを含むメッセージＭ４２０を受信する。

ステップ５２０では、サーバ側サービス８０ａは、ステップ５１０のメッセージで示されるユーザがサービスにおいて登録されたかどうかを調べる。

もしそうであれば、ステップ５４０では、サーバ側サービス８０ａは、登録が要求されるユーザがすでにサービスにおいて登録されたことを示すメッセージＭ５４０をクライアントデバイス２１に送信する。

もしそうでなければ、ステップ５３０では、サーバ側サービス８０ａは、データベース６０内に、ステップ５１０のメッセージＭ４２０において示されるすべての属性ＡＭに関連するシステム識別子ＩＤＭによりユーザを登録する。

ステップ５５０では、サーバ側サービス８０ａは、登録が要求されるユーザがデータベース６０内にサービスにより登録されたことを示しステップ５３０においてユーザに対して割り当てられたシステム識別子ＩＤＭを示すメッセージをクライアントデバイス２１に送信する。

ステップ５６０では、クライアント側サービス８０ｂが登録処理を管理する、図１０でより詳細に示されたクライアント側登録へと移行される。

ステップ５７０では、クライアント側サービス８０ｂは、ステップ５４０もしくは５５０でサーバ５０により送信されるメッセージＭ５５０もしくはＭ５４０を受信する。

ステップ５７５では、クライアント側サービス８０ｂは、メッセージがステップ５４０もしくはステップ５５０で発行されるタイプのものかどうかを調べる。

もしポジティブであれば（もし受信されるメッセージがＭ５５０のタイプのものであれば）、ステップ５８０において、クライアント側サービス８０ｂは、クライアント側からクライアントデバイス２１上に対して、登録処理が成功しユーザが登録されたこととユーザのシステム識別子ＩＤＭとを登録する。

もしネガティブであれば（もし受信されるメッセージがＭ５４０のタイプのものであれば）、ステップ５９０において、クライアント側サービス８０ｂは、クライアント側からクライアントデバイス２１上に対して、登録処理が成功せずにユーザが登録されなかったことを登録する。

図１１は、サーバ側サービス８０ａが復号化処理を管理するサーバ側復号化段階６００を図示する。

ステップ６１０では、サーバ側サービス８０ａは、ステップ２６３でクライアントデバイス２１により送信される復号化要求メッセージＭ２６３を受信する。

ステップ６２０では、サーバ側サービス８０ａは、システム識別子ＩＤＭによりメッセージＭ２６３において示されるクライアントデバイスがデータベース６０においてサービス８０により登録されたかどうかを検証する。

上述したように、クライアントデバイス２１の属性ＡＭ及び識別子ＩＤＭと、探索キーとして発見されたデバイス２２の属性ＡＳとを用いてそのようなデータベース６０に対してクエリーを実行することにより、サービスにおけるデバイスの登録に関する情報を取得できる。また、メッセージＭ２６３により実行されるサービス８０において登録されかつ認証されたクライアントデバイス側で復号化することの要求は、より詳細に後述説明されるタイムスタンプ情報と一緒に、データベース６０内に格納されるかもしくはデータベース６０内でカウントされる。

従って、ステップ６２０においてネガティブな結果の場合には、ステップ６３０において、サーバ側サービス８０ａは、クライアントデバイス２１がサービス８０において登録されていないことを示すメッセージＭ６３０をクライアントデバイス２１に送信する。

ステップ６２０において、ポジティブな結果の場合には、ステップ６４０において、サーバ側サービス８０ａは、ステップ６１０におけるメッセージＭ２６３で示された発見されたデバイス２２の属性ＡＳがデータベース６０においてサービスにより登録されるユーザもしくはデバイスに対応するかどうかを検証する。

もしそうでなければ、ステップ６５０において、サーバ側サービス８０ａは、ステップ６１０においてメッセージＭ２６３で示された、検出されたデバイス２２の属性ＡＳがサービス８０により登録されたユーザに対応しないことを示すメッセージＭ６５０をクライアントデバイス２１に送信する。

もしそうであれば、ステップ６６０において、サーバ側サービス８０ａは、クライアントデバイス２１が双方向一義的に１つもしくはそれ以上のデバイス２２を検出したことを記録し、そのような検出に対する情報を記録する。すなわち、
−サーバ５０の日付、
−サーバ５０の時間、
−ステップ６１０のメッセージＭ２６３で供給される任意の他の情報。

従って、検出に関する情報はデータベース６０内に記録される。すなわち、例えばそのような復号化要求Ｍ２６３では関連したクライアントデバイスやそれらのシステム識別子を介して検出されたデバイスなどの情報並びに特にサーバ時間及び日付などのサーバにおける受信に対する時間情報などの情報はデータベース６０内に記録される。

例として、登録されるユーザのリスト内に記録は、以下のように構造化されてもよい。
- user_id: 001、
- username: MyUsername、
- password: MyPassword、
- name: MyName、
- facebook_id: 547969090、
- device_name: MyDevice、
- device_address: F0:DC:B2:BA:E8:5D、
- peer_ID: MyPeer_ID、
- peer_name: MyPeerName、
- UUID: MyUUID。

user_idは、システム識別子ＩＤＭもしくはＩＤＳに対応する。

Nameはユーザの名前を表す。補助的情報の例を以下に示す。すなわち、Nameは、以下に示すように、受動的モードもしくは能動的モードが確立される例えばユーザ／デバイスに対してのみに供給されてもよい。

facebook_idは、ユーザのフェースブック識別子である。この識別子は、補助的サービスの例である。すなわち、ユーザのフェースブックページへのリンクが受動的モードもしくは能動的モードが確立される例えばユーザ／デバイスに対してのみに供給されてもよい。

device_name及びdevice_addressはデバイスのpeer_IDの実際の属性を表し、peer_nameはピアの属性を表す一方で、UUIDはサービスの属性である。

ユーザによる付加的な属性が存在してもよい。

例として、登録されるユーザの表における記録は、以下のように構造化されてもよい。
- master_user_id: 001、
- slave_user_id: 002、
- last_contact: 18-04-2011 12:28:43、
- last_checkin: 18-04-2011 12:28:43、
- posizione_GPS: (Not mandatory)。

master_user_idはクライアントデバイス２１のシステム識別子ＩＤＭに対応し、slave_user_idは検出されたデバイス２２のシステム識別子ＩＤＳに対応し、last_contactは最後の一義的検出の（サーバでの）日付及び時間を示す一方で、last_checkinは最後の双方向一義的検出の（サーバでの）日付及び時間を示す。双方向一義的検出が発生しなかった場合には、last_checkinフィールドは空白となるであろう。

ここで示されるケースでは、last_checkinフィールドの値は、双方向一義的検出が存在したことを示し、それ故に確実にこのタイプのもう１つのシステム記録が存在することを示す（master_user_idとslave_user_idとが入れ替えられた）。すなわち、
- master_user_id: 002、
- slave_user_id: 001、
- last_contact: 18-04-2011 12:28:15、
- last_checkin: 18-04-2011 12:28:43、
- posizione_GPS: (Not mandatory)。

ステップ６７０では、サーバ側サービス８０ａは、クライアントデバイス２１に相関する検出及び検出されたデバイス２２がすでにデータベース６０内に存在するかどうかを検証するが、その役割は入れ替えられる。すなわち、検出されたデバイス２２がクライアントデバイスの役割によりデータベース６０において以前に調査され、クライアントデバイス２１は検出されたデバイスの役割により調査された。さらに、サーバ側サービス８０ａは、（例えば１分間隔内などの）時間期間にわたって２つの異なる測定が行われたかどうかを検証する。

ステップ６７５では、サーバ側サービス８０ａは、属性ＡＳに基づき、ステップ６６０で記録される一義的検出のデータがデータベース６０からリカバリーされた、出されたデバイス２２のシステム識別子ＩＤＳを示すメッセージＭ６７５をクライアントデバイス２１に送信する。

ステップ６８０では、もしステップ６７０で示された条件が発生したのであれば、サーバ側サービス８０ａは、データベース６０において、クライアントデバイス２１が検出されたデバイス２２及びそのような双方向一義的検出に関する情報を双方向一義的に検出したことを登録する。上述したように、すなわち、
−サーバ５０の日付、
−サーバ５０の時間、
−ステップ６１０のメッセージＭ２６３で供給される任意の他の情報。

ステップ６８５では、サーバ側サービス８０ａは、ステップ６８０で記録された、検出されたデバイス２２のシステム識別子ＩＤＳ及び双方向一義的検出の日付を示すメッセージＭ６８５をクライアントデバイス２１に送信する。

ステップ６９０では、図１２に詳細に図示される、クライアント側復号化段階へと移行する。そのような段階では、クライアント側サービス８０ｂは、復号化処理を管理し、クライアント側サービス８０ｂがステップ６３０，ステップ６５０，ステップ６７５，もしくはステップ６８５においてサーバ５０により送信されたメッセージを受信するステップ７００を含む。すなわち、当該メッセージとは、クライアントデバイスがサービス８０を用いて登録されないことを示すメッセージＭ６３０、復号化要求メッセージＭ２６３において特定される属性がサービス８０により登録されたユーザに対応していないことを示すメッセージＭ６５０、ステップ６６０で記録された、検出されたデバイス２２の識別子及び一義的検出のデータを示すメッセージＭ６７５、またはステップ６８０で記録された検出されたデバイス２２の識別子ＩＤＳ及び双方向一義的検出のデータを示すメッセージＭ６８５である。

特に、第１のステップ７１０では、クライアント側サービス８０ｂは、メッセージが双方向一義的検出を示すメッセージＭ６８５であるかどうかを調べる。

もしそうであれば、クライアント側サービス８０ｂは、クライアントデバイス２１と検出されたデバイス２２との間の認証された近接が存在することを決定し、能動的モードに関するステップ８００へと移動する。すなわち、それはステップ６８５のメッセージＭ６８５で示される検出されたデバイスのシステム識別子ＩＤＳ並びに検出されたデバイス２２に対する復号化手順のポジティブな結果及びそのような能動的モード８００の利便性をクライアントデバイス２１上に記録する。

逆に言えば、もしメッセージがステップ６８５で示されるタイプのものでなければ、ステップ７２０では、クライアント側サービス８０ｂは、メッセージが一義的検出を示すメッセージＭ６７５であるかどうかを調べる。

もしそうであれば、クライアント側サービス８０ｂは、クライアントデバイス２１と検出されたデバイス２２との間の認証された近接に対してより低い近接レベルを決定し、受動的モード９００に対応するステップに移動し、ここで、それはクライアントデバイス２１上のクライアント側から、メッセージＭ６７５で示される検出されたデバイス２２のシステム識別子ＩＤＳと、検出されたデバイス２２に対する受動的モード９００の復号化手順のポジティブな結果及び利便性とを登録する。

もしそうでなければ、すなわち、メッセージＭ６３０及びＭ６５０が受信されて、クライアント側サービス８０ｂは、クライアントデバイス２１と検出されたデバイス２２との間の近接レベルを決定し、非能動的モードに対応するステップへと移動し、ここで、クライアント側サービス８０ｂは、復号化手順が成功しなかったことと非能動的モード１０００が検出されたデバイス２２に対して利用可能であることとをクライアントデバイス２１上に登録する。すなわち、サービス８０を介して、デバイス間の相互作用が発生することは不可能となる。

従って、そのサーバ側８０ａ及びクライアント側８０ｂの部分において、サービスにより実行される動作の終わりでは、例示されるプロトコルを採用することにより、方法は、ユーザ１１とユーザ１２との間もしくはクライアント２１と検出されたデバイス２２との間での検出されたデバイス２２に関するサービスもしくは情報への以下の３つのアクセスモードは、クライアントデバイス２１において信号が送信されることを予測する。すなわち、
−能動的モード８００：サービス８０ｂは、近接関係において、クライアントデバイス２１及び検出されたデバイス２２がサービス８０により認証されたとして定義されることを示す。クライアントデバイスは、検出されたデバイス２２のシステム識別子ＩＤＳを認識する。従って、そのような能動的モード８００では、例えばウェブを介してサーバに接続するチャンネルを介するより好ましい実施形態によれば、クライアントデバイス２１は、サーバ５０に向かって動作する通信チャンネル４１を介してそのようなデバイス２２に関連する情報もしくはサービスにアクセスすることができる。次に、検出されたデバイス２２は、クライアントデバイス２１のシステム識別子ＩＤＭを認識し、それ故にそれを特にウェブを介してサーバ５０に接続させるそれ自身のチャンネル４２を介してアクセスすることができる。特に、情報にアクセスするために、例えば、検出されたデバイスは公共に利益のある情報を配信する情報キオスクであり、通信チャンネル４１はサーバ５０を介して利用可能であろう情報にアクセスするのに十分である。補助的サービスが使用されるケースでは、それは（例えばチャットなどの）情報をデバイス２２に配信する必要があり、そのケースでは、チャンネル４２がまた必要である。
−受動的モード９００：それらは実際には近接して存在しないかもしれないが、サービス８０ｂはクライアントデバイス２１及び検出されたデバイス２２がサービス８０により定義される接近した関係にあることを示す。クライアントデバイス２１は、検出されたデバイスのシステム識別子ＩＤＳを認識し、それ故に例えばサーバ５０に向けた第２のチャンネル４１を用いてそれに接続されたさらなる情報及びサービスへのアクセスを介してそれと相互作用するかもしれない。
−非能動的モード１０００：サービス、特にクライアント側８０ｂからのサービスは、クラインアントデバイス２１及び検出されたデバイス２２が近接していないことを示す。

安全性の観点から、受動的モード９００では、デバイス２１及び２２は近接している可能性があるが、例えばデバイス２２がある方法で盗まれたデータベース６０において登録されたデバイスの属性をこっそりと公開していることを排除することは不可能である。しかしながら、もし検出されたデバイス２２がまたサービス８０を用いて登録もしくは認証により取得されたシステム識別子のみを有する必要があるサーバ５０に対して復号化要求を送信したならば、これは排除される。単一の一義的検出に基づき、２つのエンティティ間の近接を認証する（１つのエンティティだけが他のエンティティに近接することを要求している）（例えば位置情報サービスなどの）他のサービスとは異なり、本発明に係る方法だけが双方向一義的検出を用いて２つのエンティティ間の近接を認証する。このアプローチにより、他のエンティティに対する単一のエンティティによる近接の可能性がある誤った宣言が廃棄されることを可能とさせるかもしくは少なくとも近接が認証されることを不可能とさせる。

一義的検出とは「潜在的な近接」と考えられ、それ故に認証されない。

従って、上述された３つのモード８００，９００，１０００のそれぞれは、２つのデバイス間の近接の認証の異なるレベルと関連付けられ、それ故に異なるサービスと関連付けられる。

結論として、本発明に係る方法は、３つのモード８００，９００，１０００の１つに対応する検出されたデバイス２２の情報及びサービスへのアクセスのモードに対応するように構成される、検出されたデバイスのシステム識別子及びその近接の認証レベルから構成される情報を結果として提供する。次に、アプリケーションは、そのような情報内のこれらの要素に基づいて柔軟な方法で構造化される。

受動的モード９００は、相互作用している両方のデバイスにより認証される近接を有する必要がないコンテキストにおいて使用される。

例えば、電子公共トランスポートポールでは、データベース６０に格納され信頼できるサーバ５０によりアクセスされる属性を有する無線デバイス（ブルートゥース／Ｗｉ−Ｆｉ）は、各ポール内に組み込まれる。そのような登録は、サービス登録段階と同等である。一旦デバイスが起動されると、例えばブルートゥースなどの無線周辺機器は、すなわち例のブルートゥースにおいて使用される無線プロトコルの標準に従って、無線チャンネル上にその属性を公開する。電子ポールに近接して存在するサービスにより登録されたユーザは、車両の到着及び出発時間、交通情報、現在のニュース、並びに広告及び申し出のすべてがそのデバイス／ポールと関連付けられて以前に格納されたサーバ５０から受信できる。この解決法は、ポール内に組み込まれたデバイスに対して、コンピュータ、大容量記憶装置もしくはアプリケーション８０ｂを必要としない。

さらなる例によれば、ブルートゥースのような、すなわち無線チャンネル上にその属性を公開できるデバイスを用いて、上述したように、例えば記念建造物もしくは博物館などで情報キオスクが構成される。サービスに登録されたユーザは、サーバ５０から文化的なニュース、観光客ニュース、地方のニュース、及び他の情報を受信する。

能動的モード８００は、例えば両方のデバイスにより認証された近接を指示することが必要であるコンテキストなどにおいて使用される
−顧客保持／ポイントカード：ビジネスは、無線周辺機器及びサーバ８０上で登録されたサービス８０ｂを有するデバイスを備え、そのビジネスに訪れるかもしくは購入するすべての登録されたユーザにクーポン及び割引を提供する。
−仮想的なビジネスカード：登録されかつ近接する２人のユーザは、仮想的なビジネスカードを交換することができる。
−ファイルの共有：登録されかつ近接する２人のユーザは、ファイルを交換できる。
−即時のメッセージング：登録されかつ近接する２人のユーザは、メッセージを交換できる。
−携帯での支払い：登録されかつ近接する２人のユーザは、金銭を交換できる。このケースでは、仮想的な財布機構をプロファイルに関連付けることが必要である。そのサービスは、内部の仮想的な通貨を管理できるかもしくは他のプラットフォーム上でトランザクションを簡単に引き受けることができる。例えば、例えばペイパルなどのペイパルＸ（データベース６０において登録されたアカウント番号）を有する仮想的な財布番号を有するユーザＡやペイパルアカウント番号Ｙ（データベース６０において登録されたアカウント番号）を有するユーザＢなどである。そのシステムは、ペイパルがペイパルアカウントＸからペイパルアカウントＹへのトランザクションを引く受けることを求める。
−ゲーム：登録されかつ近接する２人のユーザは、同一のビデオゲームを有する複数のプレイヤーのセッションを創造できる。

必然的に、非能動的モード８００は、それが簡単に含まれる２つのデバイスの少なくとも１つがプロトコルの主要なサービスにより登録されないことを示すという点において、特定のサービスと関連付けされない。

従って、提案された解決法は有利に、信頼できる中央サーバ及び無線チャンネル３０が備えられる信頼されないデバイスが登録できるサービスにより、上記サービスのモダリティに従ってデバイス間の認証された近接の指示を取得することを可能とし、含まれたデバイス間の無線チャンネル上の完全なダイレクト接続を確立させることなしにそれ故に情報攻撃のリスクを回避することなしに近接した信頼されないデバイスの情報及びサービスにアクセスすることの対応するモードを含む相互作用を開始することを可能とさせる。

また、本発明に係る方法及びシステムは特に、所定の検出されたデバイスを発見するデバイスに近接する有効位置に対する可能性がある最も正当な情報を取得することを必要とするサービス及びアプリケーションに対する接続に適している。

例えば、ユーザもしくはデバイスの位置を確立するためにＧＰＳ情報を使用する、知られたＬＢＳ（位置情報サービス）タイプのサービスに対して、本発明に係る方法は、以下の利点を提供する。
−近接が認証される：その理由は、能動的モードのケースでは、検出が双方向一義的である一方で、ＬＢＳサービスでは、サーバはクライアントにより供給されるデータが実在しそれ故にクライアント位置を認証することを検証することができないからである。
−特に屋内のＧＰＳ信号受信は弱く、検出された位置が不正確である可能性があるという点において、位置決め（ポジショニング）はより正確でない。一方、本発明に係る方法及びシステムによれば、（数メートルのオーダで）精度は常に高く、屋内でも精度は高い。
−さらに少ないエネルギー消費量。その理由は、例えば、例えばブルートゥース４．０プロトコルなどを使用する無線周辺機器は、ＧＰＳよりもエネルギー消費量は少ないからである。
−近接認証の高レベル及びユーザの自動的な識別から得るアプリケーションの柔軟性は、幅広い実用的なアプリケーションを実現可能とする。

必然的に、本発明の原理に対する先入観なしに、構造及び実施形態の詳細は、本発明の範囲を離れることなしに、純粋に例として説明され図示された構造及び実施形態の詳細に対して広く変更されてもよい。

好ましくは、双方向一義的検出を検証するために使用され、受信された復号化するための要求の記録はデータベースにおいて実行されるが、またアプリケーションまたはサーバ側サービスによりアクセス可能な他の論理構造、記憶装置、もしくは処理により実行される。

最後に、留意すべきことは、本発明に係る方法の主要な目的は、そのような検出されたデバイス２２のシステム識別子ＩＤＳ及びメッセージＭ６８５及びＭ６７５のみならず、実質的にサービス８０のエラーもしくは非有用性の条件を示すメッセージＭ６３０及びＭ６５０からも取得可能な近接のレベルに基づいて、検出されたデバイス２２からの情報及びサービスにアクセスするためのモードのクライアントデバイス２１へのシグナリング（信号送信）を提供することである、ということである。

そのようなシグナリングは、シグナリングされたモダリティと関連付けられた任意の補助的サービスの利便性を示すサービスクライアント８０ｂから透過的に管理される。また、そのシグナリングは、クライアントデバイス２１上での可視化、そのようなクライアントデバイス２１上の変数もしくはフラッグの初期化、または復号化メッセージの内容に基づき、クライアントデバイス２１から得られたシグナリングされたモダリティ情報を利用可能とすることの類似的な手段を介してシグナリングを予測する

検出されたデバイス２２の情報及びサービスへのアクセスのモードのそのようなシグナリングは、アプリケーションがサーバにより供給されたサービスにより認証されたとして定義された近接関係のレベルを認識し、結果的に安全なもしくは信頼されてもよいアクセスオプションを選択することを可能とする。しかしながら、その方法自身は、必ずしもアクセスオプションを制限しない。また、アプリケーションは、利用可能なアクセスモードのシグナリングに基づき、例えば、受動的モード９００のシグナリングの存在においてでさえもサーバ５０と検出されたデバイス２２との間のチャンネル４２を使用することを決定するなどの異なる方法でアクセスを動作してもよい。

Claims (20)

1. 第１の無線通信チャンネル（３０）を確立するように構成される第１の通信デバイス（２１）と、上記第１の無線通信チャンネル（３０）上で動作するように構成される１つもしくはそれ以上の第２のデバイス（２２）との間の特に「信頼できる」インタラクションであるインタラクションを実行するための方法であって、当該方法は、
   上記第１の通信デバイス（２１）は、上記第１の無線通信チャンネル（３０）上にそのデバイス属性（ＡＭ）を公開する（２５０）ことで上記第１の通信デバイス（２１）を可視化でき、次いで、上記第１の通信デバイス（２１）は上記１つもしくはそれ以上の第２の通信デバイス（２２）により公開された属性（ＡＳ）を、上記第１の無線通信チャンネル（３０）を介して検出することで上記第２の通信デバイス（２２）を可視化できることを含み、
   上記第１の無線通信チャンネル（３０）は、上記第１の無線通信チャンネル（３０）の動作の半径内の上記第１の無線通信チャンネル（３０）上で、可視化可能もしくは発見可能な第２の通信デバイス（２２）を探索する発見動作を実行させるのに適したタイプのものであり、
   上記第１の通信デバイス（２１）は上記１つもしくはそれ以上の第２の通信デバイス（２２）の格納された属性（ＡＭ，ＡＳ）を備えたデータベース（６０）にアクセスする方法において、
   上記第１の通信デバイス（２１）は、クライアントとサーバの遠隔通信関係において、上記データベース（６０）が関連付けされた遠隔コンピュータサーバ（５０）と通信するための第２の通信チャンネル（４１）を確立するように構成され、
   上記第１の通信デバイス（２１）は、上記１つもしくはそれ以上の第２の通信デバイス（２２）の発見動作（２６０）の後に、上記第２の通信チャンネル（４１）を介して、上記第１の通信デバイス（２１）に対して上記データベース（６０）において割り当てられた少なくとも１つのシステム識別子（ＩＤＭ）と、上記第１の無線通信チャンネル（３０）上で検出された上記１つもしくはそれ以上の第２の通信デバイス（２２）の属性（ＡＳ）とを備える対応する復号化要求（Ｍ２６３）を上記遠隔に位置された遠隔コンピュータサーバ（５０）に送信し、
   上記遠隔コンピュータサーバ（５０）は、上記復号化要求（Ｍ２６３）に対して、可能なときには上記データベース（６０）から１つもしくはそれ以上の検出された第２の通信デバイス（２２）のそれぞれのシステム識別子（ＩＤＳ）を取得することの少なくとも１つのステップを含む復号化動作（６００）を実行し、
   上記遠隔コンピュータサーバ（５０）は、上記第２の通信チャンネル（４１）を介して、もし可能なときには、上記システム識別子（ＩＤＳ）を備える上記復号化動作（６００）の結果を含む復号化メッセージ（Ｍ６３０，Ｍ６５０，Ｍ６７５，Ｍ６８５）を上記第１の通信デバイス（２１）に送信し、
   上記遠隔コンピュータサーバ（５０）から受信された上記復号化メッセージ（Ｍ６３０，Ｍ６５０，Ｍ６７５，Ｍ６８５）において示される結果に基づき、上記第１の通信デバイス（２１）において、上記遠隔コンピュータサーバ（５０）から受信された上記システム識別子（ＩＤＳ）が記録され、当該システム識別子（ＩＤＳ）が、検出される可能性がある上記１つもしくはそれ以上の第２の通信デバイス（２２）の情報もしくはサービスに対するアクセスのための、第１のアクセスモード、第２のアクセスモード及び第３のアクセスモード（８００，９００，１０００）のうちの決定された１つのアクセスモードの利用可能性の信号が、上記１つもしくはそれ以上の第２の通信デバイス（２２）に送信されることを特徴とする方法。
2. 上記復号化動作（６００）は、上記遠隔コンピュータサーバ（５０）上で復号化するための上記要求（Ｍ２６３）を記録すること（６６０）を含むことを特徴とする請求項１記載の方法。
3. 上記遠隔コンピュータサーバ（５０）上で上記復号化要求（Ｍ２６３）を記録すること（６６０）の上記動作は、上記データベース（６０）において、上記対応するシステム識別子（ＩＤＭ，ＩＤＳ）及び特に上記遠隔コンピュータサーバ（５０）の日付及び時間である上記遠隔コンピュータサーバ（５０）での受信の時間情報である、そのような復号化要求（Ｍ２６３）に対する情報を記録することを含むことを特徴とする請求項２記載の方法。
4. 上記復号化動作（６００）はさらに、所定の時間間隔内で、上記検出された第２の通信デバイス（２２）による上記第１の通信デバイス（２１）の検出により開始される復号化要求がまた上記遠隔コンピュータサーバ（５０）に到達したかどうかを検証すること（６８５）を含むことを特徴とする請求項２または３記載の方法。
5. 上記復号化メッセージ（Ｍ６８５）が、上記検出された第２の通信デバイス（２２）による上記第１の通信デバイス（２１）の検出から開始される復号化要求が上記遠隔コンピュータサーバ（５０）に到達したことを示すときは、上記第１の通信デバイス（２１）は、検出される可能性がある上記１つもしくはそれ以上の第２の通信デバイス（２２）の情報もしくはサービスにアクセスするための第１のアクセスモード（８００）の信号を送信することを特徴とする請求項４記載の方法。
6. 上記復号化メッセージ（Ｍ６７５）が、上記検出された第２の通信デバイス（２２）による上記第１の通信デバイス（２１）の検出から開始される復号化要求が上記遠隔コンピュータサーバ（５０）に到達しなかったことを示すときは、上記第１の通信デバイス（２１）は、検出される可能性がある上記１つもしくはそれ以上の第２の通信デバイス（２２）の情報もしくはサービスにアクセスするための第２のアクセスモード（９００）の信号を送信することを特徴とする請求項４記載の方法。
7. 上記復号化動作（６００）は最初に、上記復号化要求（Ｍ２６３）の上記遠隔コンピュータサーバ（５０）での上記記録動作（６６０）の前に、上記第１の通信デバイス（２１）もしくは上記１つもしくはそれ以上の検出された第２の通信デバイス（２２）が上記データベース（６０）において登録されたかどうかを検証し、上記データベース（６０）において登録されていないときには、上記第１の通信デバイス（２１）と上記１つもしくはそれ以上の第２の通信デバイス（２２）が近接していないことを示す第３のアクセスモード（１０００）の信号である復号化メッセージ（Ｍ６３０，Ｍ６５０）を上記第１の通信デバイス（２１）に送信することを含むことを特徴とする請求項２〜６のうちのいずれか１つに記載の方法。
8. 上記第１のアクセスモード（８００）の信号が送信されるときに、上記第１の通信デバイス（２１）は、上記第２の通信チャンネル（４１）による上記システム識別子（ＩＤＳ）アクセスにより動作することが可能となることを特徴とする請求項１〜７のうちのいずれか１つに記載の方法。
9. 上記第１の通信デバイス（２１）はまた、上記第２の通信チャンネル（４１）、上記遠隔コンピュータサーバ（５０）及び上記遠隔コンピュータサーバ（５０）と上記検出された第２の通信デバイス（２２）との間の通信チャンネル（４２）を介して上記検出された第２の通信デバイス（２２）に対する上記システム識別子（ＩＤＳ）アクセスにより動作できることが可能となることを特徴とする請求項８記載の方法。
10. 上記第２のアクセスモード（９００）の信号が送信されるときに、上記第１の通信デバイス（２１）は、上記システム識別子（ＩＤＳ）により動作できることが可能となり、接続を介するアクセスは、上記検出された第２の通信デバイス（２２）のさらなる情報及び／又はサービスへのアクセスに対する上記第２の通信チャンネル（４１）を含むことを特徴とする請求項６〜９のうちのいずれか１つに記載の方法。
11. 上記第３のアクセスモード（１０００）の信号が送信されるときに、上記１つもしくはそれ以上の検出された第２の通信デバイス（２２）が近接して検出されたと考慮されないことを特徴とする請求項１〜１０のうちのいずれか１つに記載の方法。
12. 上記第１の通信デバイス（２１）は、遠隔でありかつ少なくとも上記第１の通信デバイス（２１）上に配置される上記遠隔コンピュータサーバ（５０）上にそれぞれ常駐するソフトウェアモジュール（８０，８０ａ，８０ｂ）により上記データベース（６０）を管理し、
    上記ソフトウェアモジュール（８０，８０ａ，８０ｂ）は、上記クライアントとサーバの遠隔通信関係において配置された少なくとも上記第１の通信デバイス（２１）及び上記遠隔コンピュータサーバ（５０）を設けられるように構成されることを特徴とする請求項１〜１１のうちのいずれか１つに記載の方法。
13. 上記ソフトウェアモジュール（８０，８０ａ，８０ｂ）はそれぞれ、遠隔に配置された上記遠隔コンピュータサーバ（５０）上でありかつ少なくとも上記第１の通信デバイス（２１）上に常駐し、上記第１の通信デバイス（２１）と上記遠隔コンピュータサーバ（５０）とを相互動作するように、特にウェブサービスであるサービスを定義するクライアントとサーバの遠隔通信関係において遠隔に配置された少なくとも上記第１の通信デバイス（２１）及び上記遠隔コンピュータサーバ（５０）を置くように作用することを特徴とする請求項１２記載の方法。
14. 特にウェブサービスである上記サービスは、上記第１の通信デバイス（２１）上に導入されたソフトウェアモジュール（８０ｂ）及び上記遠隔コンピュータサーバ（５０）上に導入されたＡＰＩ（アプリケーションプログラミングインターフェース）のいずれかのソフトウェアアプリケーションを含むことを特徴とする請求項１３記載の方法。
15. 上記第１の通信デバイス（２１）のもしくは上記検出された第２の通信デバイス（２２）の上記システム識別子（ＩＤＭ，ＩＤＳ）は、上記ソフトウェアモジュール（８０，８０ａ，８０ｂ）により割り当てられてかつ上記第１の通信デバイス（２１）のもしくは上記検出された第２の通信デバイス（２２）の登録段階において割り当てられた、上記データベース（６０）の特定のコードであることを特徴とする請求項１２記載の方法。
16. 上記第１の無線通信チャンネル（３０）は、ブルートゥースプロトコルに従って動作することを特徴とする請求項１〜１５のうちのいずれか１つに記載の方法。
17. 上記第１の無線通信チャンネル（３０）は、Ｗｉ−Ｆｉ（ワイヤレスフィディリティ）プロトコルに従って動作することを特徴とする請求項１〜１５のうちのいずれか１つに記載の方法。
18. 第１の無線通信チャンネル（３０）を確立するように構成される第１の通信デバイス（２１）と、上記第１の無線通信チャンネル（３０）上で動作するように構成される１つもしくはそれ以上の第２の通信デバイス（２２）との間の特に「信頼できる」タイプのインタラクションを動作するためのテレコミュニケーションシステムであって、
    上記第１の無線通信チャンネル（３０）は、発見動作の実行が、上記第１の無線通信チャンネル（３０）の動作の半径内の上記第１の無線通信チャンネル（３０）上で、可視化可能もしくは発見可能な第２の通信デバイス（２２）を探索することを可能とさせるのに適したタイプのものであり、
    上記テレコミュニケーションシステムは、遠隔コンピュータサーバ（５０）を備え、
    能動的な上記第１の通信デバイス（２１）はさらに、上記遠隔コンピュータサーバ（５０）により第２の通信チャンネル（４１）を確立するようにさらに構成され、
    上記テレコミュニケーションシステムは、請求項１〜１６のうちのいずれか１つに記載の方法の動作を実行することを特徴とするテレコミュニケーションシステム。
19. 発見動作の実行が、請求項１８記載のテレコミュニケーションシステムにおいて動作するように構成される上記第１の無線通信チャンネル（３０）の動作半径内の上記第１の無線通信チャンネル（３０）上で、可視化可能もしくは発見可能な第２の通信デバイス（２２）を探索することを可能とさせるのに適したタイプの第１の無線通信チャンネル（３０）を確立するように構成される第１の通信デバイス（２１）。
20. 請求項１８記載のテレコミュニケーションシステムにおいて動作するように構成され、データベース（６０）と関連付けられる遠隔コンピュータサーバ（５０）。

Images