(57)【要約】 【課題】    第１のデバイス（１１０；１２０；１３０；１４０）および第２のデバイス（１１０；１２０；１３０；１４０）を結びつける。【解決手段】    各デバイス（１１０；１２０；１３０；１４０）は、アイデンティティをブロードキャストする（３０４；５０４；６０４）。第１のデバイス（１１０；１２０；１３０；１４０）は、新しいアイデンティティを格納し、かつそれらを計数する。ユーザのインストラクションに応じ（３１６；５１６；６１６）、１つの新しいアイデンティティ（３１７）が存在する場合、第１のデバイス（１１０；１２０；１３０；１４０）は、第２のデバイス（１１０；１２０；１３０；１４０）に対する結びつきのためのリクエスト（３１８；５１８；６１８）を送り、了解（３２０；５２０；６２０）を送る。第２のデバイス（１１０；１２０；１３０；１４０）はユーザのリクエスト（３３０；５３０；６３０）に応じて、コンファメーション（３３２；５３２；６３２）を第１のデバイスに（１１０；１２０；１３０；１４０）送る。これは、検証され（３３４、５３４；６３４）そのコンファメーション（３３２；５３２；６３２）が第２のデバイス（１１０；１２０；１３０；１４０）に送信される。そして、これの了解（３３６；５３６；６３６）が送られる。本発明の方法は他のデバイスのアイデンティティを表示することができないデバイスへの適用に適している。
2010509819.tif 000002
【特許請求の範囲】
【請求項１】
第１のデバイスおよび第２のデバイスを結びつける方法であって：
前記第１のデバイスが、そのアイデンティティをブロードキャストせよとのインストラクションを、受信するステップ、
前記第１のデバイスが、そのアイデンティティをブロードキャストするステップ、
前記第２のデバイスが、前記第１のデバイスの前記アイデンティティを受信するステップ、
前記第２のデバイスが、そのアイデンティティをブロードキャストせよとのインストラクションを、受信するステップ、
前記第２のデバイスが、そのアイデンティティをブロードキャストするステップ、
前記第１のデバイスが、前記第２のデバイスの前記アイデンティティを受信するステップ、
前記第１のデバイスが、前記第２のデバイスと結びつくべきとのインストラクションを、受信するステップ、
前記第１のデバイスが、受信された新しいアイデンティティの数を計数するステップ、
受信された新しいアイデンティティの前記数が１に等しい場合、前記第１のデバイスが、前記第２のデバイスと結びつくためのリクエストを、送信するステップ、および
前記第２のデバイスが、前記第１のデバイスと結びつくインストラクションを、受信するステップ、
前記第２のデバイスが、前記第１のデバイスとの結びつきのコンファメーションを送るステップ、
を有する方法。
【請求項２】
前記コンファメーションが前記第２のデバイスによって送られたことを前記第１のデバイスが検証するステップ、
をさらに有する請求項１記載の方法。
【請求項３】
前記第１のデバイスが、前記コンファメーションの検証の成功に応じて、前記第２のデバイスに了解を送信するステップ、
をさらに有する請求項２記載の方法。
【請求項４】
前記第２のデバイスが、前記リクエストの受信に応じて、前記第１のデバイスに了解を送るステップ、
をさらに有する請求項１記載の方法。
【請求項５】
少なくとも、前記第１のデバイスは、前記第２のデバイスの前記アイデンティティを表示するための能力がない、
請求項１ないし４のいずれか１項に記載の方法。
【請求項６】
前記デバイスの前記アイデンティティを有する前記ブロードキャストは、フォーマットにおいて同一である、
請求項１ないし５のいずれか１項に記載の方法。
【請求項７】
第２のデバイスと結びつくための第１のデバイスにおける方法であって、第１のデバイスにおいて、
そのアイデンティティをブロードキャストするインストラクションを受信するステップ、
そのアイデンティティをブロードキャストするステップ、
少なくとも前記第２のデバイスのアイデンティティを受信するステップであって、前記第２のデバイスの前記アイデンティティを運ぶ受信されたメッセージの前記フォーマットは、前記第１のデバイスの前記アイデンティティを運ぶメッセージの前記フォーマットと同一であるところのステップ、
前記第２のデバイスと結びつくべきとのインストラクションを受信するステップ、
受け取った新しいアイデンティティの数を計数するステップ、
受信された新しいアイデンティティの前記数が１に等しい場合、前記第２のデバイスとの結びつきのためのリクエストを送信するステップ、および
前記結びつきの了解を受信するステップ、
を有する方法。
【請求項８】
前記コンファメーションが前記第２のデバイスによって送られたことを検証するステップをさらに有する請求項７記載の方法。
【請求項９】
成功した検証に応じて、了解を送信するステップをさらに有する請求項８記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、安全なネットワークに関する。より詳細には、かかるネットワークのデバイスを結びつけることに関する。
【背景技術】
【０００２】
コンピュータ・ネットワークを有する重要なセキュリティ問題は、人間が関係するということである。かかるネットワークを管理することは特定の能力を必要とし、これを一般ユーザは持っていない。このために、複雑なユーザーインターフェースがユーザに表示されると、しばしば最も低いセキュリティレベルを選択する。そして、場合によっては、完全にそれさえも取り除いてしまうことがある。セキュリティを許容範囲に保ちつつ、可能な限りユーザのための労力を軽減する簡単な方法の必要性が存在する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】欧州特許出願公開第１４１１６７４号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１は、単純なボタンのクリックで、中心ポイントによって、伝達される電波の範囲を制限する解決策を提示している。それから、ユーザは、中心ポイントのネットワークにそれを参加させるために、制限した範囲においてデバイスの機能を起動させる。このソリューションの不利な点は、それがいろいろな攻撃に弱いということである。例えば中間者攻撃（ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ  ａｔｔａｃｋ）として知られている。本発明は少なくとも先行技術における幾つかのセキュリティの問題に対する解決を試みる。一方、ユーザは非常に単純なユーザーインターフェースを持つデバイスで安全なコミュニティを構築することができる。
【課題を解決するための手段】
【０００５】
第１の態様において、本発明は、第１のデバイスおよび第２のデバイスを結びつける方法を実現する。第１のデバイスは、そのアイデンティティをブロードキャストするインストラクションを受信する。そして、そのアイデンティティをブロードキャストする。第２のデバイスは、第１のデバイスのアイデンティティを受信し、自身のアイデンティティをブロードキャストするインストラクションを受信し、そのアイデンティティをブロードキャストする。第１のデバイスは、第２のデバイスのアイデンティティを受信し、第２のデバイスと結びつくためにインストラクションを受信し、受信された新しいアイデンティティの数を計数する。受信された新しいアイデンティティの数が１に等しい場合、第１のデバイスは結びつきのためのリクエストを第２のデバイスに送信する。第２のデバイスは、第１のデバイスと結びつくためにインストラクションを受信し、かつ第１のデバイスとの結びつきのコンファメーションを送る。
【０００６】
好ましい実施例においては、第１のデバイスは、コンファメーションが第２のデバイスによって送られたことを検証する。第１のデバイスがコンファメーションの検証に成功した場合、第２のデバイスに了解を送ることが有利である。
【０００７】
別の好ましい実施例では、第２のデバイスは、要求の受信により、第１のデバイスに了解を送る。
【０００８】
さらにもう一つの好ましい実施例において、少なくとも、第１のデバイスは、第２のデバイスのアイデンティティを表示するための能力がない。
【０００９】
更に好ましい実施例において、デバイスのアイデンティティを含むブロードキャストは、同一フォーマットである。
【００１０】
第２の態様において、本発明は、第１のデバイスが第２のデバイスと結びつくための方法を目的とする。第１のデバイスは、自身のアイデンティティをブロードキャストするインストラクションを受信し、そのアイデンティティをブロードキャストし、少なくとも第２のデバイスのアイデンティティを受信する。第２のデバイスのアイデンティティを運ぶ受信メッセージのフォーマットは、第１のデバイスのアイデンティティを運ぶメッセージのフォーマットと同一である。第１のデバイスは、第２のデバイスと結びつくためにインストラクションを受信して、受信された新しいアイデンティティの数を計数する。受信された新しいアイデンティティの数が１に等しい場合、第１のデバイスは結びつきのためのリクエストを第２のデバイスに送信し、かつ結びつきのコンファメーションを受信する。
【００１１】
好ましい実施例において、第１のデバイスは、コンファメーションが第２のデバイスによって送られたことを検証する。第１のデバイスが検証に成功した場合、了解を送ることが有利である。
【００１２】
本発明の好ましい特徴は、一例として、添付の図面を用いて説明する。
【図面の簡単な説明】
【００１３】
【図１】本発明が用いられる典型的なコミュニティを示す図である。
【図２】本発明の概念の概要を示すフローチャートである。
【図３】本発明による方法の実施例のフローチャートである。
【図４】図３において示される方法の実施例の実行中における典型的なユーザーインターフェースを単純化して示す図である。
【図５】本発明による方法の更なる実施例のフローチャートである。
【図６】本発明による方法の更なる実施例のフローチャートである。
【図７】本発明によるスクリーン付きデバイスの好ましい実施例の状態図を示す図である。
【図８】本発明によってスクリーン無しデバイスの好ましい実施例の状態図を示す図である。
【発明を実施するための形態】
【実施例】
【００１４】
［好ましい実施例の詳細な説明］
図１は、本発明が用いられる典型的なコミュニティ１００を示す。コミュニティ１００は、完全なユーザーインターフェース（それぞれ１１５および１２５）を有する２つのデバイスすなわち、スクリーン付きデバイスＡ１１０およびスクリーン付きデバイスＢ１２０、および制限されたユーザーインターフェース（それぞれ１３５および１４５）を有する２つのデバイス、すなわちスクリーン無しデバイスＣ１３０およびスクリーン無しデバイスＤ１４０を有する。本発明の説明において、制限されたユーザーインターフェースとは、例えば限られた入力機能、例えば２、３のコマンドを識別することが可能である単一のボタンまたは音声認識を有するデバイスであって、出力機能、例えば２、３の文字を表示することができる例えば２、３の発光ダイオードまたはスクリーンであってもよい。したがって、例えば、他のデバイスのアイデンティティをユーザに表示することはできない。図４を参照すると、典型的な限られたユーザーインターフェース１３５、１４５が示されており、これらは、ユーザーコマンドを受信するための１つのボタン１３６、１４６、１つの緑色発光ダイオード１３７、１４７および１つの赤色発光ダイオード１３８、１４８を有する。完全なユーザーインターフェースにおいては、例えば、ユーザは少なくとも数字を入力でき、または、第１のリストからアイデンティティを選択でき、第２のリストからのコマンドを選択できる。加えて、容易にディスプレイによって長い数字または表示されたイメージを見ることができる。
【００１５】
図を明確にするためにスクリーン無しデバイスＣ１３０が示されているが、各デバイスは他のデバイスとの対話処理のための通信ユニット１３３を有する。通信ユニット１３３は好ましくはコミュニケーションのための無線技術を使用しているが、他の通信手段（例えば赤外線）が使われてもよい。加えて、各デバイスは、算出、検証、デバイス制御のためのメモリ（スクリーン無しデバイスＣにおいてだけ１３２として示されている）、および、プロセッサ（スクリーン無しデバイスＣ１２０においてだけ１３１として示されている）を有する。
【００１６】
図２は、本発明の一般的な内容を示すフローチャートである。図は第１のデバイス２１および第２のデバイス２２を示す。そして、それらは両方ともスクリーン付きデバイス（すなわち完全なユーザーインターフェース付きデバイス）またはスクリーン無しデバイス（限られたユーザーインターフェースのデバイス）のいずれでもよい。最初、ユーザ（図示せず）が両方のデバイス２１、２２を起動させ、それらに必要なアクション（開始）を実行するように指示する２１０、２２０。これによって、それらのデバイス２１、２２は開始状態２３、２３’に移行する。この間、情報が交換される２３０。ユーザは、一方の第１のデバイス２１において、対応する他方の（すなわち）第２のデバイス２２を選択する２４０。これによって、第１のデバイス２１は処理状態２４に移る。加えて、デバイス２１および２２の間に更なる情報交換２５０がなされる。それから、ユーザは、第２のデバイス２２において、対応する第１のデバイス２１を選択する２６０。これによって、第２のデバイス２２は処理状態２４’に移る。加えて、デバイス２１、２２は更なる情報を交換する２７０。一旦必要な情報が交換されると、両デバイス２１および２２は、それぞれ結びつき、結びついた状態２５、２５’に移る。
【００１７】
図３は、本発明による方法の実施例のフローチャートを示す。これによって、第１のスクリーン無しデバイス１３０（デバイスＣ）および第２のスクリーン無しデバイス１４０（デバイスＤ）が結びつくこととなる。ユーザ１５０がデバイスＣ１３０にアクション３０２を実行すると、方法が開始される。アクションとは、例えば音声コマンドまたはボタンを押すことなど、デバイスに対し例えば状態を変えるように指示するいかなる種類の指示であってもよい。
【００１８】
デバイスＣ１３０は、それからブロードキャスト状態に入り、自身に関する証明可能なアイデンティティ（ＩＤ）をブロードキャスト３０４することを開始する。好ましくは短くほぼ一定の間隔で、ブロードキャストは繰り返される。なお、図を明確化するため、１つの更なるブロードキャストＩＤメッセージ３０９だけが、図３に示されている。ブロードキャストＩＤは、例えば一般のＲＳＡキーでもよい。そのブロードキャストＩＤをブロードキャストすると共に、デバイスは他のデバイスのブロードキャストＩＤをリスニングする。受け取ったブロードキャストＩＤが「新しい」場合、すなわち、受信および送信デバイスが結びついていない場合、受信デバイスは「新デバイス」カウンタを増加させる。この「新デバイス」カウンタは、「新しい」ブロードキャストＩＤをトラッキングする。
【００１９】
それからユーザ１５０はデバイスＤ１４０にアクションを実行し３０６、デバイスＤ１４０はブロードキャスト状態に入り、証明可能なＩＤを提供するブロードキャスト３０８を開始する。デバイスＤからのブロードキャストＩＤ３０８の受信に応じて、デバイスＣ１３０は、「新デバイス」カウンタを１に設定する（それ以前に０であったと仮定）。そして、デバイスＤ１４０は、デバイスＣのブロードキャストＩＤ３０９の受信に従って同様にアクションを起こす。両方のデバイス１３０、１４０は、それぞれ新しいデバイスに出会ったことを伝える。本実施例においては、それぞれゆっくり緑色発光ダイオード３１２および３１４を点滅させる。
【００２０】
ユーザ１５０は、発光ダイオードをチェックし３１４、少なくとも１つのデバイスがブロードキャスト状態であることを検証することができることは有利な点である。それから、ユーザは１つのデバイスにアクション３１６を実行する。実施例では、デバイスＤ１４０となっているが、ここでは、状態は対称的であり、同様にデバイスＣ１３０を選ぶこともできる。
【００２１】
デバイスＤ１４０は、それが１つの「新しい」ブロードキャストＩＤ（「新しいデバイス」が１に等しい）だけを受信したことをチェックする３１７。そうでない場合には、デバイスＤ１４０は、好ましくは赤色発光ダイオードの点滅によって、エラーの信号を伝え、かつ方法を中断する。実施例においては、デバイスＤ１４０は、単一の「新しい」ブロードキャストＩＤを受信したため、方法を続けることができる。デバイスＤ１４０は、ブロードキャストＩＤを受信したデバイス（すなわち、デバイスＣ１３０）にリクエストを発信する。この場合、Ｃ１３０のアイデンティティをリクエストに含むか、またはデバイス了解３２０を応答するようＣ１３０に対してリクエストを発する。デバイスＤ１４０は、それから、了解がデバイスＣ１３０によって送られたことを検証する３２１。好ましくはブロードキャストＩＤメッセージ３０４に含まれる公開鍵によって暗号解読で検証する。検証の好ましい方法としては、デバイスＤがリクエスト３１８チャレンジを含ませ、かつこのチャレンジは、その秘密鍵を使用してデバイスＣによって暗号化され、了解３２０によってデバイスＤに戻される。そして、これを、対応する公開鍵で解読することによって、デバイスＤによって検証される。この後に、それぞれ、両方のデバイス１３０、１４０は、好ましくは緑色発光ダイオード３２２および３２４の速い点滅によってこれを示す。好ましくはユーザ１５０によってこれらが検証される３２６、３２８。
【００２２】
検証が成功すると、ユーザ１５０はデバイスＣにアクションを実行し３３０、このアクションは、デバイスＣ１３０に対して、デバイスＤ１４０にコンファメーションを送信させる３３２。コンファメーションを受信すると、デバイスＤ１４０は、コンファメーションがデバイスＣ１３０によって送られたことを検証する３３４。これは、ブロードキャストＩＤメッセージ３０４に含まれる公開鍵を使って暗号解読によって検証することが好ましい。前項にて説明したように、使用するチャレンジは、秘密鍵によって暗号化され対応する公開鍵を使用して解読されることが望ましい。これによって、暗号化デバイスが実際に秘密鍵を備えているということを証明することができるからである。換言すれば、デバイスＤが本当に検証するものはコンファメーションが、デバイスＣの所有する選択されたブロードキャスト・アイデンティティによって送られたことである。この場合、デバイスＤ１４０は、了解を応答する３３６。その後、デバイス１３０、１４０が、結びつく。そして緑色発光ダイオードを発光させることが好ましい３３８、３４０。
【００２３】
もし、ユーザ１５０がアクション３３０を行う前に、デバイスＣ１３０が第２のリクエストを受信した場合、デバイスは、好ましくは赤色発光ダイオードを点灯することによって、エラーの信号を送り、方法が中断される点に留意する必要がある。各デバイスは、少なくとも他のデバイスからメッセージを待つたびに開始するタイマーを備えている。タイマーが一定時間経過する場合、デバイスは上記と同様に、エラーの信号を送ることができる。このように、デバイスは方法の途中で停止してしまうことを防止する。
【００２４】
図４は、図３において示される方法の実施例の実行中の典型的なユーザーインターフェースを示す。図４は、スクリーン無しデバイスＣ１３０およびスクリーン無しデバイスＤ１４０のそれぞれのユーザーインターフェース１３５、１４５を示す。各ユーザーインターフェース１３５、１４５は、ボタン１３６、１４６、緑色発光ダイオード１３７、１４７および赤色発光ダイオード１３８、１４８を有する。
【００２５】
ステップ４１０において、ユーザは、デバイスＣ１３０にアクション３０２を実行する。ステップ４２０の時点においては、ユーザーインターフェース１３５、１４５は、何も表示しないことを示している。ステップ４３０において、ユーザは、デバイスＤ１４０にアクション３０６を実行する。ステップ４４０においては、ユーザーインターフェース１３５、１４５が緑色発光ダイオード１３７、１４７の遅い点滅（斜線によって示される）によってこれを表示する。ステップ４５０において、ユーザは再びデバイスＤ１４０にアクション３１６を実行する。そして、ステップ４６０において、表示が変更され、緑色発光ダイオード１３６、１４６が、短い間隔で点滅する（水平の斜線によって示される）。そして、ステップ４７０において、ユーザが再びデバイスＣ１３０にアクション３３０を実行し、ステップ４８０で表示が変更され、緑色発光ダイオード１３６、１４６は、連続的に点灯する（グリッドによって示される）。
【００２６】
図５は、本発明による方法の実施例のフローチャートを示す。この場合、第１のスクリーン付きデバイス１１０（デバイスＡ）および第２のスクリーン付きデバイス１２０（デバイスＢ）が結びつく。明らかなように、図５において示される実施例と図３に示される実施例と類似している部分がある。
【００２７】
本方法においては、デバイスＡ１１０に対して、まずユーザ１５０が「開始」アクション５０２を実行する。このアクションは、デバイスに対して、例えば状態を変える指示（例えば、完全なユーザーインターフェースにおいてアイコンをアクティブ化、またはボタンの押下）等いかなる種類の指示であってもよい。デバイスＡ１１０は、それからブロードキャスト状態に入り、デバイス自身に関する証明可能なアイデンティティ（ＩＤ）をブロードキャスト５０４することを開始する。図５には、図を簡約化するために、ＩＤをブロードキャストする１つのメッセージ５０９だけが図示されているが、略一定の短い間隔によってブロードキャストが繰り返されることが好ましい。ブロードキャストＩＤは、例えば一般のＲＳＡキーでもよい。自身のブロードキャストＩＤをブロードキャストすると共に、デバイスは他のデバイスのブロードキャストＩＤをリスニングする。
【００２８】
ユーザ１５０は、デバイスＢ１２０にアクション５０６を実行する。デバイスＢ１２０は、その後、ブロードキャスト状態に入り、証明可能なＩＤをブロードキャスト５０８することを開始する。デバイスＢのブロードキャストＩＤ５０８の受信に応じて、デバイスＡ１１０は、スクリーンにＩＤを表示する５１２。デバイスＢは、同様に５１０のデバイスＡのブロードキャストＩＤを表示する。例えば受信されるＩＤを単に表示する代わりに、多くのデバイスのＩＤを表示してもよい。例えば、ネットワーク１００に存在する各デバイスのＩＤを表示してもよい。
【００２９】
この例示的な実施例においては、ユーザ１５０は、デバイスＢ１２０に対して、選択されたＩＤを信頼するように指示する５１６。この場合には、デバイスＡのＩＤである。デバイスＢ１２０は、ブロードキャストＩＤを受信したデバイス（すなわちデバイスＡ１１０）にリクエスト５１８を送信する。その際、デバイスＡのアイデンティティをリクエストに含ませるか、またはデバイスＡ１１０に対し、応答５２０において了解を返すようリクエストする。デバイスＢ１２０は、了解がデバイスＡ１１０によって送られたことを検証する５２１。好ましくは先に記載したように公開鍵を用いて暗号を解読することによって検証する。
【００３０】
ユーザ１５０は、デバイスＡ１１０に対し、デバイスＢ１２０を信頼するように指示する５３０。これによって、デバイスＡ１１０からデバイスＢ１２０に対してコンファメーションが送信される５３２。了解の受信に応じて、デバイスＢ１２０は、そのコンファメーションがデバイスＡ１１０によって送られたことを検証する５３４。この場合、デバイスＢ１２０は、了解を含む応答５３６を返す。そして、好ましくは、これをスクリーンに表示し５３８、５４０、デバイス１１０、１２０は結びつき、本方法は終了する。
【００３１】
図６は、本発明による方法の実施例のフローチャートを示す。この例では、スクリーン付きデバイス１１０（デバイスＡ）および第２のスクリーン無しデバイス１３０（デバイスＣ）が結びつく。明らかなように、実施例は前述の実施例の混合である。既に説明した図において詳細に説明される事項は、いかなるものも図６において利用されてもよい。スクリーン付きデバイスまたはスクリーン無しデバイスで通信する場合でも、そのこと自体は重要ではなく、方法は不変のままである。
【００３２】
ユーザ１５０がデバイスＡ１１０に対し、「開始」のアクション６０２を行うと、本方法が開始される。その後、デバイスＡ１１０が、自身を証明可能なアイデンティティ（ＩＤ）のブロードキャストを開始する６０４。ユーザ１５０は、デバイスＣ１３０に、それからアクション６０６を実行する。デバイスＣ１３０は、証明可能なＩＤをブロードキャストする６０８。両方のデバイス１３０、１４０は、それから、それらが新しいデバイスを検知したことを伝える。デバイスＡ１１０は、デバイスＣのブロードキャストＩＤをそのディスプレイに表示し６１２、デバイスＣ１３０は、緑色発光ダイオードをゆっくりと点滅させる。
【００３３】
ユーザ１５０は、デバイスＣ１３０の発光ダイオードをチェックし６１４、ＩＤをブロードキャストしたことを確認し、アクション６１６を実行する。デバイスＣ１３０は、「新しい」ブロードキャストＩＤを１つだけ受信したことをチェックする６１７。実施例において、デバイスＣ１３０はデバイスＡ１１０にリクエストを発信する６１８。デバイスＡ１１０は、了解を含む応答を返す６２０。デバイスＣ１３０は、了解がデバイスＡ１１０によって送られたことを検証６２１する。デバイスＣ１３０は緑色発光ダイオードの速い点滅によってこれを示す。ユーザ１５０はこれを確認することが望ましい。
【００３４】
ユーザ１５０は、デバイスＡ１１０にデバイスＣ１３０を信頼するように指示する６３０。これによって、デバイスＡ１１０からデバイスＣ１３０に対してコンファメーションが送信される６３２。コンファメーションの受信に応じて、デバイスＣ１３０は、コンファメーションがデバイスＡ１１０によって送られたことを検証する６３４。この場合、デバイスＣ１３０は了解を有する応答を返す６３６。その後、デバイス１１０、１２０が結びつく。これは、スクリーンおよび発光ダイオードによって表示され６３８、６４０、方法は終了する。
【００３５】
デバイスの安全な相互確認を担保するために、本発明は、以下の好ましいメッセージ方式を提案する
【００３６】
【表１】
2010509819.tif 000003
ヘッダは、メッセージのタイプを区別する。Ｘは発信者の１０２４ビットの公開鍵による証明可能なアイデンティティを表す。Ｙは、発信宛先の１０２４ビット公開鍵の証明可能なアイデンティティを表す。すべてのメッセージは、ＲＳＡ署名によって署名される。カウンターリプレイとしてシーケンス番号を含んでもよい。
【００３７】
図７は、本発明によるスクリーン付きデバイスの好ましい実施例の状態図を示す。スラッシュの存在は、状態変化を発生させるイベントを区別するために用いる。左のアクションによって、右のものが結果として実行される。例えば「リクエスト／了解を送る」とは、デバイスがリクエストを受信すると、状態が変化し、デバイスが了解を送信することを意味する。スラッシュが無い場合は、アクションが実行されないことを意味し、結果のイベントだけが示されている。また、図７の理解を容易にするために、説明において、図５が参照される。なお、この参照は図示されていない。
【００３８】
「開始」アクション（５０２、５０６）が実行されるときはいつでも、デバイスはブロードキャストＩＤ状態７０２に移行する。この状態で、デバイスは、自身を証明可能なアイデンティティをブロードキャストする。
【００３９】
更に特定のデバイス（５１６）を信頼するためのインストラクションに応じて、デバイスは、リクエスト（５１８）をそのデバイスに送る。そして、ブロードキャストＩＤ状態から、了解待ちクライアント状態７０４に移行する。プロトコルの他方の側では、ブロードキャストＩＤ状態のデバイスは、リクエストを受信（５１８）し、了解を送信し（５２０）、サーバ状態７０６に変化する。
【００４０】
了解待ちクライアント状態７０４が、タイマー期限切れ（タイムアウト）になる前に了解を受信しない場合、エラー状態７０８へ移行する。そして、プロトコルは中断される。一方、了解を受信すると（５２０）、デバイスはクライアント状態７１０へ移行する。
【００４１】
デバイスが他のデバイス（５３０）を信頼するようインストラクションを受信すると、サーバ状態７０６のデバイスは、コンファメーションを送信し（５３２）、了解待ちサーバ状態７１２へ移行する。
【００４２】
クライアント状態において、コンファメーションの受信（５３２）に応じて、デバイスは、了解を送り（５３６）、結びついた状態７１４へ移行する。この了解（５３６）によって、了解待ちサーバ状態７１２のデバイスは、結びついた状態７１４へ移行する。その後、両方のデバイスは結びついた状態になる。しかしながら、了解待ちサーバ状態７１２のデバイスは、タイマーが期限切れになる前に、了解を受信しない場合（タイムアウト）、同様にエラー状態７０８へ移行してもよい。
【００４３】
図８は、本発明によるスクリーン無しデバイスの好ましい実施例の状態図を示す。スラッシュの存在は、状態変化を発生させるイベントを区別するために用いる。左のアクションによって、右のものが結果として実行される。例えば「リクエスト／了解を送る」とは、デバイスがリクエストを受信すると、状態が変化し、デバイスが了解を送信することを意味する。スラッシュが無い場合は、アクションが実行されないことを意味し、結果のイベントだけが示されている。また、図８の理解を容易にするために、説明において、図３が参照される。なお、この参照は図示されていない。
【００４４】
アクション（３０２、３０６）が実行されるときはいつでも、デバイスはブロードキャストＩＤ状態８０２に移行する。この状態で、デバイスは、自身を証明可能なアイデンティティをブロードキャストする。そして、新しいデバイスからどれくらいのブロードキャストＩＤを受信したか（ＢｒｏａｄｃａｓｔＩＤＲｅｃｅｉｖｅ）をトラッキングする。そして、ゆっくりその緑色発光ダイオードを点滅させる。
【００４５】
更に特定のデバイスを信頼せよとのインストラクション（３１６）に応じて、デバイスは、新しいデバイスからどれくらいのブロードキャストＩＤを受信したかをチェックする。この数が１に等しくない場合（すなわち、それは全くアイデンティティを受信していないか、または二つ以上のアイデンティティを受信した場合）、デバイスはエラー状態８０８へ移行する。そして、赤色発光ダイオードだけを点灯する。他方、その数が、予想通り１に等しい場合、デバイスはリクエスト（３１８）を更なるデバイスに送信し、ブロードキャストＩＤ状態から了解待ちクライアント状態８０４に移行する。そして、緑色発光ダイオードをゆっくりと点滅させる。プロトコルの他方の側では、ブロードキャストＩＤ状態のデバイスは、リクエストを受信（３１８）し、了解を送信し（３２０）サーバ状態８０６に移行する。そして、緑色発光ダイオードを速く点滅させる。
【００４６】
了解待ちクライアント状態８０４のデバイスは、タイマー期限切れ（タイムアウト）になる前に了解を受信しない場合、エラー状態８０８へ移行する。一方、了解を受信すると（３２０）、デバイスはクライアント状態８１０へ移行する。緑色発光ダイオードは、速く点滅する。
【００４７】
サーバ状態７０６から、デバイスが更なるリクエストを受信する場合、エラー状態８０８へ移行する。一方、予想される「アクション」が実行されると（３３０）、デバイスは了解を送信し（３３２）、了解待ちサーバ状態８１２に移行する。緑色発光ダイオードは速く点滅する。
【００４８】
クライアント状態において、コンファメーション（３３２）の受信に応じて、デバイスは、了解を送り（３３６）、かつ緑色発光ダイオードが点灯し、結びついた状態８１４へ移行する。この了解（３３６）によって、了解待ちサーバ状態８１２は、結びついた状態８１４へ移行する。しかしながら、了解待ちサーバ状態８１２のデバイスは、タイマーが期限切れになる前に、了解を受信しない場合（タイムアウト）、同様にエラー状態８０８へ移行してもよい。
【００４９】
なお、すべての可能性がこの状態図の説明において示されたわけではないことは言うまでもない。例えば、更にプロトコルの安定性を増加させるために、クライアント状態７１０、８１０から、更なるタイムアウトを追加することが可能である。これは明確に示さなかったが、これが可能であることは、当業者であれば直ちにわかるであろう。
【００５０】
ユーザーインターフェース能力の如何に関わらず、本発明が同じプロトコルを使用して、デバイスを結びつける安全な方法を提供でき、先行技術を改善することができることは言うまでもない。
【００５１】
本発明が単に一例として記載されていることが理解されよう。そして、詳細な部分の修正は本発明の範囲内において、なされてもよい。
【００５２】
明細書および請求項（必要に応じて）および図面において開示される各特長は、それぞれに独立に提供されてもよく、あるいはいかなる適当な組合せで提供されてもよい。本発明の特長は、適切な、ハードウェア、ソフトウェアまたは２つの組合せで実装され得る。接続は、無線接続で実装されてもよく、直接的なあるいは専用の接続でなくてもかまわない。
【００５３】
請求項に示されている参照符号は、例示目的のためのものであり、かつ請求項の範囲に、制限影響を及ぼさない。
【図１】
2010509819.tif 000004
【図２】
2010509819.tif 000005
【図３】
2010509819.tif 000006
【図４】
2010509819.tif 000007
【図５】
2010509819.tif 000008
【図６】
2010509819.tif 000009
【図７】
2010509819.tif 000010
【図８】
2010509819.tif 000011
【国際調査報告】
2010509819.tif 000012
2010509819.tif 000013
2010509819.tif 000014