(57)【要約】【課題】ハンドオーバーを利用して高速にデータ伝送する通信装置を提供すること。【解決手段】低速な第１の通信方式に対応する第１通信部と、前記第１の通信方式よりも高速な第２の通信方式に対応する第２通信部と、を有する通信装置であって、前記第１通信部は、前記第１の通信方式の通信パケットが、前記第２の通信方式の接続認証に用いる認証情報を含む第１部分と、当該第１部分以外の第２部分とに分割されたうちの前記第１部分を受信し、前記第２通信部は、前記第１部分に含まれる認証情報により接続認証が成功した場合に、前記第２部分を受信し、前記受信した第２の部分を解析して、所定の処理を実行する実行部と、を備える、通信装置が提供される。【選択図】図２
2010213334.tif 000002
【特許請求の範囲】
【請求項１】
低速な第１の通信方式に対応する第１通信部と、前記第１の通信方式よりも高速な第２の通信方式に対応する第２通信部と、を有する通信装置であって、
前記第１通信部は、前記第１の通信方式の通信パケットが、前記第２の通信方式の接続認証に用いる認証情報を含む第１部分と、当該第１部分以外の第２部分とに分割されたうちの前記第１部分を受信し、
前記第２通信部は、前記第１部分に含まれる認証情報により接続認証が成功した場合に、前記第２部分を受信し、
前記受信した第２の部分を解析して、所定の処理を実行する実行部と、
を備える、
通信装置。
【請求項２】
前記実行部は、前記第２の部分からパラメータを抽出し、前記パラメータに基づいてアプリケーションを起動する処理を実行する、
請求項１に記載の通信装置。
【請求項３】
前記第１部分には、第１部分が分割されたものか否かを示す分割情報、及び前記第２の通信方式を識別するための方式識別情報が付加され、
前記分割情報および方式識別情報に基づいて、前記第２部分の受信に対応するか否かを判別する判別部をさらに備え、
前記判別部により前記第２部分の受信に対応すると判別された場合、前記第２通信部により第２の部分を受信する、
請求項１に記載の通信装置。
【請求項４】
前記第１部分には、第１部分が分割されたものか否かを示す分割情報、及び前記第２の通信方式を識別するための方式識別情報が付加され、
前記分割情報および方式識別情報に基づいて、前記第２部分の受信に対応するか否かを判別する判別部をさらに備え、
前記判別部により前記第２部分の受信に対応しないと判別された場合、前記第１通信部により前記第１部分と前記第２部分とを含む第１の通信方式の通信パケットを受信する、
請求項１又は３に記載の通信装置。
【請求項５】
低速な第１の通信方式に対応する第１通信部と、前記第１の通信方式よりも高速な第２の通信方式に対応する第２通信部と、を有する通信装置による通信方法であって、
前記第１通信部により、前記第１の通信方式の通信パケットが、前記第２の通信方式の接続認証に用いる認証情報を含む第１部分と、当該第１部分以外の第２部分とに分割されたうちの前記第１部分を受信する第１受信ステップと、
前記第２通信部により、前記第１部分に含まれる認証情報により接続認証が成功した場合に、前記第２部分を受信する第２受信ステップと、
前記受信した第２の部分を解析して、所定の処理を実行する実行ステップと、
を含む、
通信方法。
【請求項６】
低速な第１の通信方式に対応する第１通信部と、前記第１の通信方式よりも高速な第２の通信方式に対応する第２通信部と、を有し、
前記第１通信部は、前記第１の通信方式の通信パケットが、前記第２の通信方式の接続認証に用いる認証情報を含む第１部分と、当該第１部分以外の第２部分とに分割されたうちの前記第１部分を受信し、
前記第２通信部は、前記第１部分に含まれる認証情報により接続認証が成功した場合に、前記第２部分を受信し、
前記受信した第２の部分を解析して、所定の処理を実行する実行部と、
を備える、第１の通信装置と；
少なくとも前記第１の通信方式に対応する第２の通信装置と；
を含む、
通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信方法、及び通信システムに関する。
【背景技術】
【０００２】
近年、ハンドオーバーと呼ばれる技術が利用されるようになってきている。この技術は、互いに異なる通信方式に対応した２つの通信手段を自動的に切り替えて通信する技術である。例えば、第１の通信方式として赤外線通信や非接触近接通信（以下、ＮＦＣ）に対応し、第２の通信方式として無線ＬＡＮ（以下、ＷＬＡＮ）やＢｌｕｅｔｏｏｔｈ（登録商標）（以下、ＢＴ）に対応するような電子機器に適用される。こうした電子機器では、例えば、第１の通信方式を用いて第２の通信方式の認証情報を伝送し、その認証情報を用いて第２の通信方式の認証設定が自動的に行われる。そのため、ユーザは、認証処理や設定処理について意識することなく、自動的に第２の通信方式に係る通信機能を利用できるようになる。
【０００３】
最近では、多くの規格化団体により、近接無線通信（ＰＡＮ：Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）方式を用いたハンドオーバー技術や簡単認証方式と呼ばれる技術が提案されている。ＷＬＡＮに関しては、ＷｉＦｉ  Ｐｒｏｔｅｃｔｅｄ  Ｓｅｔｕｐ（ＷＰＳ）規格の中で、こうした方式が提案されている。さらに、ＢＴに関しては、Ｃｏｒｅ仕様バージョン２．１のＳｅｃｕｒｅ  Ｓｉｍｐｌｅ  Ｐａｉｒｉｎｇ（ＳＳＰ）の中で、こうした方式が提案されている。より具体的には、ＮＦＣ通信経由で認証情報を交換することにより、ユーザが認証情報を直接機器に入力することなく簡単に認証可能な方式が規格化されている。
【０００４】
また、より広範囲にユーザの利便性を追及していくと、第２の通信方式に対する認証処理だけでなく、第１の通信方式によるアプリケーションの起動等までもが視野に入ってくる。これに関し、例えば、下記の特許文献１には、携帯電話の赤外線通信機能をトリガーにして電話会議システムを起動する技術が開示されている。また、他の例として、下記の特許文献２には、第１の通信方式により、第２の通信の通信方式、及び暗号化方式の情報を交換し、適合する方式が発見された場合にデータ転送手段を第２の通信方式に切り換える技術が開示されている。この技術は、データの機密性を確保するための技術としてハンドオーバー技術を応用した例である。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−２９５５７４号公報
【特許文献２】特開２００７−１６６５３８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、電話会議システムを実現するための赤外線通信内容には、通信相手のインターネットアドレスや認証情報だけでなく、テレビ電話を開始するためのアプリケーションに関する情報が含まれる。そのため、通信帯域幅が比較的狭い赤外線通信を利用して多くのデータを伝送することになり、データ伝送に時間が掛かってしまう。
【０００７】
ところで、インターネットが普及し、ＬＡＮに接続されたネットワーク対応機器が増えるに連れ、必要なサービスを提供している機器を効率良く探し出す方法が課題として挙げられるようになってきている。このような課題に対し、Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ（ＵＰｎＰ）は、ユーザによる複雑な操作や設定作業を伴わずに、ネットワークに接続するだけで、ユーザが所望する機能が実現されることを目指している。
【０００８】
ＵＰｎＰの仕様で規定されたＳｉｍｐｌｅ  Ｓｅｒｖｉｃｅ  Ｄｉｓｃｏｖｅｒｙ  Ｐｒｏｔｏｃｏｌ（ＳＳＤＰ）においては、ＨＴＴＰフォーマットに従い、所望の拡張性を維持しながら検索対象の条件を記述する方式が定義されている。この定義に従って記述されたパケットがネットワーク内にブロードキャスト配信されることで、ユーザは、利用可能な機器や所望のサービスを容易に検出することができるようになっている。
【０００９】
ここで、ＷＬＡＮ機器がハンドオーバーによってＩＰネットワークに接続されるケースについて考えてみる。このケースでは、ハンドオーバーによる認証が完了した後で、所望のサービスを実装した機器が検索される。そして、所望のサービスを実装した機器との間で、起動するアプリケーションの指定等の一連の作業が実行される。この一連の作業は、ＵＰｎＰで規定された技術を利用することにより実現される。
【００１０】
そこで、ＵＰｎＰによる処理を実行するために必要な情報をＨＴＴＰ形式で記述し、ＮＦＣ通信パケットに付加して伝送することによって、ユーザは、非常に簡単な動作にて認証処理からアプリケーションの起動処理までの一連の処理を完了させることができる。
【００１１】
ところが、利便性が高まる一方で、第２の通信方式を利用して起動されるアプリケーションの情報が第１の通信パケットに含まれる結果、第１の通信パケットのサイズが大きくなり、通信時間が長期化してしまうという問題が生じる。
【００１２】
通常、第１の通信方式による変調方式や通信プロトコルは、シンプルな構造を有する場合が多い。そのため、第２の通信方式と比較して非常に低速であり、また、通信可能な範囲が制限されていることが多い。その結果、通信時間の長期化は、本来求められるべきユーザの利便性を却って損ねる結果になりかねない。
【００１３】
例えば、赤外線通信によってサイズの大きなデータを通信する場合、通信中、通信可能な角度と距離を所定範囲に維持しなければならず、ユーザにとって大きな負担となる。ＮＦＣ通信の場合は通信範囲が非常に短距離であるため、ユーザは、通信対象物同士を接触した状態に維持しなければならず、大きな負担を強いることになる。交通機関の改札やコンビニエンスストアの電子決済等にＮＦＣ通信が用いられているのは、多くの場合、ＮＦＣ通信で伝送されるデータ量が非常に少ないからである。そのため、要求される接触時間が比較的短く、ＮＦＣデバイスを読み取り機器に翳している時間が問題になる場面が発生し難いのである。
【００１４】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、互いに通信速度の異なる複数の通信手段をデータの種類の応じて選択的に利用することにより、通信時間を短縮することが可能な、新規かつ改良された通信装置、及び通信方法を提供することにある。
【課題を解決するための手段】
【００１５】
上記課題を解決するために、本発明のある観点によれば、低速な第１の通信方式に対応する第１通信部と、前記第１の通信方式よりも高速な第２の通信方式に対応する第２通信部と、を有する通信装置であって、前記第１通信部は、前記第１の通信方式の通信パケットが、前記第２の通信方式の接続認証に用いる認証情報を含む第１部分と、当該第１部分以外の第２部分とに分割されたうちの前記第１部分を受信し、前記第２通信部は、前記第１部分に含まれる認証情報により接続認証が成功した場合に、前記第２部分を受信し、前記受信した第２の部分を解析して、所定の処理を実行する実行部と、を備える、通信装置が提供される。
【００１６】
また、前記実行部は、前記第２の部分からパラメータを抽出し、前記パラメータに基づいてアプリケーションを起動する処理を実行するように構成されていてもよい。
【００１７】
また、前記第１部分には、第１部分が分割されたものか否かを示す分割情報、及び前記第２の通信方式を識別するための方式識別情報が付加されていてもよく、上記の通信装置は、前記分割情報および方式識別情報に基づいて、前記第２部分の受信に対応するか否かを判別する判別部をさらに備え、前記判別部により前記第２部分の受信に対応すると判別された場合、前記第２通信部により第２の部分を受信するように構成されていてもよい。
【００１８】
また、前記第１部分には、第１部分が分割されたものか否かを示す分割情報、及び前記第２の通信方式を識別するための方式識別情報が付加されていてもよく、上記の通信装置は、前記分割情報および方式識別情報に基づいて、前記第２部分の受信に対応するか否かを判別する判別部をさらに備え、前記判別部により前記第２部分の受信に対応しないと判別された場合、前記第１通信部により前記第１部分と前記第２部分とを含む第１の通信方式の通信パケットを受信するように構成されていてもよい。
【００１９】
また、上記課題を解決するために、本発明の別の観点によれば、低速な第１の通信方式に対応する第１通信部と、前記第１の通信方式よりも高速な第２の通信方式に対応する第２通信部と、を有する通信装置による通信方法であって、前記第１通信部により、前記第１の通信方式の通信パケットが、前記第２の通信方式の接続認証に用いる認証情報を含む第１部分と、当該第１部分以外の第２部分とに分割されたうちの前記第１部分を受信する第１受信ステップと、前記第２通信部により、前記第１部分に含まれる認証情報により接続認証が成功した場合に、前記第２部分を受信する第２受信ステップと、前記受信した第２の部分を解析して、所定の処理を実行する実行ステップと、を含む、通信方法が提供される。
【００２０】
また、上記課題を解決するために、本発明の別の観点によれば、低速な第１の通信方式に対応する第１通信部と、前記第１の通信方式よりも高速な第２の通信方式に対応する第２通信部と、を有し、前記第１通信部は、前記第１の通信方式の通信パケットが、前記第２の通信方式の接続認証に用いる認証情報を含む第１部分と、当該第１部分以外の第２部分とに分割されたうちの前記第１部分を受信し、前記第２通信部は、前記第１部分に含まれる認証情報により接続認証が成功した場合に、前記第２部分を受信し、前記受信した第２の部分を解析して、所定の処理を実行する実行部と、を備える、第１の通信装置と；少なくとも前記第１の通信方式に対応する第２の通信装置と；を含む、通信システムが提供される。
【発明の効果】
【００２１】
以上説明したように本発明によれば、互いに通信速度の異なる複数の通信手段をデータの種類に応じて選択的に利用することにより、通信時間を短縮することが可能になる。
【図面の簡単な説明】
【００２２】
【図１】本発明の一実施形態に係る通信システムの構成例を示す説明図である。
【図２】同実施形態に係る通信装置の機能構成を示す説明図である。
【図３】同実施形態に係る通信パケットの構成例を示す説明図である。
【図４】同実施形態に係る通信パケットの構成例を示す説明図である。
【図５】同実施形態に係る通信パケットの構成例を示す説明図である。
【図６】同実施形態に係る通信パケットの分割方法の一例を示す説明図である。
【図７】同実施形態に係る通信パケットの分割方法の一例を示す説明図である。
【図８】同実施形態に係る通信パケットの分割方法の一例を示す説明図である。
【図９】同実施形態に係るハンドオーバーシーケンスを示す説明図である。
【図１０】同実施形態に係る通信方法の流れを示す説明図である。
【図１１】同実施形態に係る通信方法の流れを示す説明図である。
【図１２】同実施形態に係る通信方法の流れを示す説明図である。
【図１３】同実施形態に係る通信方法の流れを示す説明図である。
【図１４】同実施形態に係る通信装置のハードウェア構成例を示す説明図である。
【図１５】同実施形態に係る通信装置のハードウェア構成例を示す説明図である。
【図１６】ＢＴデバイスにおける認証処理方法の流れを示す説明図である。
【図１７】ＢＴデバイスにおける認証処理方法の流れを示す説明図である。
【図１８】ＢＴデバイスにおける認証処理方法の流れを示す説明図である。
【図１９】ＢＴデバイスにおける認証処理方法の流れを示す説明図である。
【図２０】ＢＴデバイスにおける認証処理方法の流れを示す説明図である。
【発明を実施するための形態】
【００２３】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００２４】
＜第１実施形態＞
まず、本発明の一実施形態について説明する。以下では、まず、本実施形態に係るアプリケーションの全体的な流れについて説明する。この中で、第１の通信方式から第２の通信方式への通信方式の切り替わりがトリガーとなり、通信相手と同期しつつ、アプリケーションが起動される技術が説明される。
【００２５】
次いで、本実施形態に係る通信装置１００、２００の機能構成が説明される。次いで、第２の通信方式による接続認証処理の流れが説明される。この中で、ＮＦＣ  Ｆｏｒｕｍで定義されたＮＦＣ通信パケットの構造が説明される。さらに、認証情報の格納方法、及び認証後に起動されるアプリケーションの起動方法が説明される。
【００２６】
本実施形態は、認証処理からアプリケーションの起動処理までに要する情報のうち、ＮＦＣ通信方式で伝送すべき情報を適切な単位で切り分け、ＮＦＣ通信方式で伝送すべき情報と他の通信方式で伝送すべき情報とを区別して、利用される通信方式を選択的に切り替える技術に特徴がある。特に、ＮＦＣ通信方式で伝送される情報を最小限にし、全体として通信効率を高めている。以下、こうした特徴を実現することが可能なパケット構成、パケットの分割方法、及び、通信相手とのネゴシエーション（通信方式の調停）を含む送受信処理の流れについて、詳細に説明する。
【００２７】
［通信システム１０のシステム構成例］
まず、図１を参照しながら、本実施形態に係る通信システム１０のシステム構成の一例について説明する。図１は、本実施形態に係る通信システム１０のシステム構成例を示す説明図である。
【００２８】
図１に示すように、通信システム１０は、２つの通信装置１００、２００により構成されている。これらの通信装置１００、２００は、２種類の通信方式で通信できるように構成されている。通信装置１００、２００は、相互に連携して動作し、一連のサービスを提供するためのアプリケーションを起動することが可能な通信システム１０を形成する。
【００２９】
その１つの通信方式（第１通信方式）は、近接通信方式（以下、ＮＦＣ方式）である。ＮＦＣ方式は、１０ｃｍ程度の非常に短い距離間で通信するための通信方式であり、所謂、非接触通信と呼ばれる通信方式である。この通信方式は、例えば、非接触ＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）カードのような電磁誘導を利用した無線通信で実現される。一方、他の通信方式（第２通信方式）は、第１通信方式よりも長い距離間で通信可能な通信方式である。尚、第１通信方式として、赤外線通信方式が利用されてもよい。
【００３０】
また、第２通信方式は、第１通信方式に比べて帯域幅が広く、比較的高速な通信が可能な通信方式である。また、第２通信方式としては、例えば、ＢＴ通信方式やＷＬＡＮ通信方式（ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃ  Ｅｎｇｉｎｅｅｒｓ）８０２．１１ｘ）等が利用される。
【００３１】
通常、第１通信方式では、第２通信方式用の設定情報やアプリケーションの起動に必要な情報が通信されることが多い。一方、第２通信方式では、通信装置１００、及び通信装置２００のそれぞれで実行されるアプリケーションを連携して動作させたり、一連のサービス（アプリケーション提供サービス）に必要な情報が通信されることが多い。
【００３２】
一般に、第１通信方式を用いると、その通信範囲の物理的制限から、通信相手の特定が容易であり、その分、通信接続を確立させるための設定作業が容易になる。一方、第２通信方式の場合、通信可能範囲に複数のデバイスが存在する場合に、どのデバイスと通信を行うかをユーザが指定する必要がある。このように、第１通信方式の場合、ユーザは、自分自身が操作するデバイスを通信相手となるデバイスに近接させた際に、通信相手が１台に制限されることが多い。そのため、通信相手を指定する情報等をユーザが手入力しなくて済むのである。
【００３３】
但し、第１通信方式は、比較的データ転送レートが低く、大容量のデータ転送に不向きであることが多い。また、通信中はデバイス同士を近接させておかなければならないという制約もある。そのため、ユーザによりデバイス同士が近接され続けることが困難であったり、デバイス同士の所定の位置関係を維持し続けることが困難な場合も考えられる。さらに、３台以上のデバイス同士を所定の通信範囲に内包させ、そのデバイス間で通信させることも困難な場合が多い。
【００３４】
上記のような問題点を踏まえ、通信システム１０においては、通信装置１００、２００の連携によるアプリケーションの実行処理を第２通信方式により行い、第１通信方式は、第２通信方式の設定情報やアプリケーション起動情報の授受のみに利用されることを想定する。つまり、通信装置１００、２００は、まず、第１通信方式により、互いに第２通信方式の設定情報を交換し、その設定情報に基づいて第２通信方式の接続を確立した上で、第２通信方式を利用してアプリケーションの連係動作を行うのである。
【００３５】
このとき、通信装置１００、２００は、第１通信方式を利用して、第２通信方式の設定情報だけでなく、互いの起動アプリケーション情報も交換することができる。その場合、通信装置１００、２００は、通信相手のアプリケーション情報に基づいて、使用するアプリケーションを選択することが可能になる。このようなアプリケーション情報の交換により、通信装置１００、２００は、ユーザの作業負担を増大させることなく、通信設定やアプリケーション設定を適切に行うことが可能になり、機器間の通信を伴うアプリケーションの実行に際して、ユーザの利便性を向上させることができる。
【００３６】
尚、通信システム１０を構成する通信装置１００、２００の形態は、第１通信方式と第２通信方式とで通信を行うことができる装置であれば、どのような形態の通信装置であってもよい。例えば、テレビジョン信号受像機、ビデオレコーダ、メディアプレーヤ、オーディオアンプ、オーディオコンポ、プリンタ、ファクシミリ、車載用オーディオシステム、又はカーナビゲーションシステム等であってもよい。
【００３７】
もちろん、本実施形態は、これに限定されるものではない。例えば、携帯電話機とオーディオコンポとによって通信システム１０が構成されていてもよい。このように、各通信装置が互いに異なる機能を有するものでもよい。さらに、通信システム１０を構成する通信装置の数は任意であり、３台以上であってもよい。尚、以下の説明においては、説明の便宜上、通信システム１０が通信装置１００、及び通信装置２００により構成されるケースが想定されている。
【００３８】
［通信装置１００、２００の機能構成］
次に、図２を参照しながら、本実施形態に係る通信装置１００、２００の機能構成について説明する。図２は、本実施形態に係る通信装置１００、２００の機能構成を示す説明図である。
【００３９】
図２に示すように、通信装置１００、２００は、主に、アンテナ１０２、１０６と、近接通信部１０４と、近距離通信部１０８と、制御部１１０と、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１１２と、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１１４と、フラッシュメモリ１１６と、入力部１１８と、表示部１２０により構成される。
【００４０】
尚、アンテナ１０２、近接通信部１０４は、図１４に示すハードウェア資源のうち、ＩＣカード、又はリーダ／ライタを構成する要素の一部又は全部により実現される。アンテナ１０６、近距離通信部１０８は、図１５に示すハードウェア資源のうち、例えば、通信部９２６により実現される。また、制御部１１０の機能は、例えば、制御回路７１２、コントローラ７２２、又はＣＰＵ９０２により実現される。
【００４１】
（近接通信部１０４）
近接通信部１０４は、アンテナ１０２に接続されており、第１通信方式（ＮＦＣ方式）に従ってデータを送受信することができる。近接通信部１０４は、例えば、１３．５６ＭＨｚ帯の周波数を利用し、１０ｃｍ程度の非常に短い距離間において最大４２４Ｋビット／秒の通信レートで通信することができる。尚、近接通信部１０４の通信距離、通信速度、及び周波数帯域は、上記の例に限定されず、任意に設定され得る。
【００４２】
（近距離通信部１０８）
近距離通信部１０８は、近接通信部１０４よりも長い距離間で通信することが可能な通信手段である。また、近距離通信部１０８は、アンテナ１０６に接続されており、近接通信部１０４よりも広い帯域幅を利用し、高速にデータを送受信することができる。尚、第２通信方式に利用される通信プロトコル毎に複数の近距離通信部１０８が設けられていてもよい。つまり、複数種類の第２通信方式に対応していてもよい。
【００４３】
例えば、近距離通信部１０８は、第２通信方式としてＢＴに対応し、２．４ＧＨｚ帯の通信帯域を利用して最大３Ｍビット／秒の通信速度で通信することができる。尚、通信帯域、及び通信速度は、ＢＴ規格のＣｏｒｅ２．０＋ＥＤＲで規定されたもの以外にも、これ以降のバージョンや他の規格が適用されてもよく、実施の態様に応じて適宜変更可能である。他の例として、近距離通信部１０８は、第２通信方式としてＷＬＡＮに対応していてもよい。この場合、近距離通信部１０８は、例えば、ＷＬＡＮの８０２．１１ｎにおいて最大約１００Ｍビット／秒にて通信することができる。
【００４４】
（制御部１１０）
制御部１１０は、通信装置１００、２００の各構成要素を制御する手段である。制御部１１０は、主に、境界決定機能と、メッセージ分割機能と、パケット再構成機能と、パケット特性判別機能と、を有する。制御部１１０は、これらの機能を利用して、後段において詳述するメッセージの分割処理や分割パケットの伝送制御等を行う。
【００４５】
境界決定機能は、後述するハンドオーバーメッセージの分割処理に際し、切り分ける境界部分を決定する機能である。メッセージ分割機能は、境界決定機能により決定された境界部分でハンドオーバーメッセージを分割する機能である。パケット再構成機能は、分割されたハンドオーバーメッセージの前半部分を含む第１通信方式の通信パケットを構成する機能である。
【００４６】
パケット再構成機能は、分割されたハンドオーバーメッセージの最後尾に、そのメッセージが分割されたものか否かを示すフラグと、第２通信方式に関する情報とを付加する機能を含む。パケット特性判別機能は、第１通信方式の通信パケットが分割されたパケットであるか否かを判別したり、その通信パケットの送信元が第２通信方式のプロトコルに対応するか否かを判別する機能である。
【００４７】
（その他）
ＲＡＭ１１２は、例えば、制御部１１０による演算処理の際に、スタック領域、又はヒープ領域として利用される。ＲＯＭ１１４には、例えば、制御部１１０の機能を実現するためのプログラムの実行バイナリコードが格納されている。但し、制御部１１０の機能を実現するためのプログラムのバイナリコードは、フラッシュメモリ１１６に格納されていてもよい。
【００４８】
［ＯＯＢ方式による認証方法］
ここで、ＢＴの標準化団体であるＢＴ  ＳＩＧによるＢＴ標準仕様（コアバージョン２．１）で規定されたＳｅｃｕｒｅ  Ｓｉｍｐｌｅ  Ｐａｉｒｉｎｇ（ＳＳＰ）認証方式の中のＯＯＢ方式に係る認証方法について簡単に説明する。
【００４９】
［ＯＯＢ方式による認証方法］
次に、ＯＯＢ方式に係る認証方法について説明する。ＯＯＢ方式はＳＳＰ認証方式の一例である。この処理の中で、通信装置１００、２００は、ユーザにより近接された状態で近接通信部１０４によりＮＦＣ通信を実行し、その後、近距離通信部１０８によりＢＴによる認証処理を実行する。ＳＳＰ認証処理の詳細については補遺１を参照のこと。
【００５０】
まず、通信装置１００、２００が十分に近接され、ＮＦＣ通信による通信可能範囲まで近づくと、近接通信部１０４を介して設定情報（ＢＤアドレス、証明書等）が交換される（ステップ１）。次いで、設定情報に含まれるＢＤアドレスに基づいて相互に公開鍵（ＰＫａ，ＰＫｂ）が交換される（ステップ２）。このとき、制御部１１０により、取得した公開鍵（ＰＫｂ，ＰＫａ）、及び自装置の秘密鍵（ＳＫａ，ＳＫｂ）に基づいて共有鍵（ＤＨＫｅｙ）が生成される（ステップ３）。
【００５１】
次いで、通信装置１００、２００は、それぞれ、受信した設定情報に含まれる乱数（ｒａ，ｒｂ）、及び証明書（Ｃａ，Ｃｂ）等を利用して第１の認証処理（図１８の認証処理に相当）を実行する（ステップ４）。但し、図１８に示す第１の認証処理の場合、証明書の発行に公開鍵を利用しているため、ＮＦＣ通信の開始以前に公開鍵が交換されていることが前提となるが、本実施形態は、このような方式にも適用可能である。
【００５２】
第１の認証処理が成功裏に完了すると、通信装置１００、２００の制御部１１０により、それぞれ、乱数（Ｎａ，Ｎｂ）が生成され、近距離通信部１０８を介して交換される。また、制御部１１０により、共有鍵（ＤＨＫｅｙ）、取得した乱数（Ｎａ，Ｎｂ，ｒａ，ｒｂ）、及びＢＤアドレス等が利用され、所定の認証関数（ｆ３）に基づいて認証値（Ｅａ，Ｅｂ）が算出される。
【００５３】
そして、これらの認証値（Ｅａ，Ｅｂ）が互いに交換され、通信装置１００、２００において、それぞれ第２の認証処理（図２０の認証処理に相当）が実行される（ステップ５）。次いで、通信装置１００、２００の制御部１１０により、それぞれ、リンクキー（ＬＫ）が算出される（ステップ６）（図１６（Ｂ）を参照）。
【００５４】
［ＷＰＳ方式による認証方法］
ここで、ＷｉＦｉ  Ａｌｌｉａｎｃｅが規定しているＷｉＦｉ  Ｐｒｏｔｅｃｔｅｄ  Ｓｅｔｕｐ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＷＰＳ）ｖｅｒｓｉｏｎ１．０ｈで規定されている認証方法について簡単に説明する。この仕様の中にも、いくつかの認証方式が規定されているが、その中でも、ＮＦＣ通信デバイスを用いるＯＯＢ方式について簡単に説明する。ＷＰＳによる認証処理の詳細については、補遺２を参照のこと。
【００５５】
まず、ＮＦＣ伝送されるパケットは２種類ある。１つは、「ＯＯＢ  Ｄｅｖｉｃｅ  Ｐａｓｓｗｏｒｄ」であり、もう１つは「Ｃｒｅｄｅｎｔｉａｌ」である。「ＯＯＢ  Ｄｅｖｉｃｅ  Ｐａｓｓｗｏｒｄ」には、ＷＰＳ仕様の中で規定された３２バイトの公開鍵に対応するＤｅｖｉｃｅ  Ｐａｓｓｗｏｒｄ、及び証明書用の２０バイトのハッシュ値等が含まれる。
【００５６】
このパケットは、ネットワークへの加入希望デバイス（Ｅｎｒｏｌｌｅｒ）と登録局（Ｒｅｇｉｓｔｒａｒ）との間で交換される。このとき、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換方式を用いて暗号化されたネットワーク経路を介して、設定情報が２．４ＧＨｚ帯で安全に交換される。その後、Ｅｎｒｏｌｌｅｒがネットワークに追加される。
【００５７】
一方、「Ｃｒｅｄｅｎｔｉａｌ」には、ネットワーク設定に必要なＳＳＩＤ、伝送路の暗号キーを表すＮｅｔｗｏｒｋ  Ｋｅｙ等の情報が暗号化されずに格納されている。ＷＰＳ方式に対応していないアクセスポイント（ＡＰ）に加入を希望するデバイス（Ｅｎｒｏｌｌｅｒ）がある場合について考える。この場合、ＥｎｒｏｌｌｅｒがＮＦＣ通信に対応し、ＮＦＣ通信可能なカードタイプのトークンにＡＰの設定情報が記されているならば、Ｅｎｒｏｌｌｅｒは、このトークンからネットワーク設定情報を読み込むことによってネットワークへ接続できるようになる。
【００５８】
［ＮＦＣ通信パケットの構成例］
次に、図３を参照しながら、ＮＦＣ通信に利用される通信パケットの構成例について説明する。図３は、ＮＦＣ通信に利用される通信パケットの構成例を示す説明図である。
【００５９】
ＮＦＣ通信は、ＮＦＣ  Ｆｏｒｕｍで規定されたＮＦＣ  Ｄａｔａ  Ｅｘｃｈａｎｇｅ  Ｆｏｒｍａｔ（以下、ＮＤＥＦ）に則って行なわれる。ＮＦＣ通信におけるパケットは、図３に示すようなＮＤＥＦ  Ｒｅｃｏｒｄと呼ばれる単位で構成される。ＮＤＥＦ  Ｒｅｃｏｒｄは、大きく分けてＲｅｃｏｒｄ  Ｔｙｐｅ部分Ｄ５、Ｒｅｃｏｒｄ  ＩＤ部分Ｄ６、Ｐａｙｌｏａｄ部分Ｄ７により構成される。
【００６０】
また、ＮＤＥＦ  Ｒｅｃｏｒｄの先頭部分Ｄ１には、そのＲｅｃｏｒｄがメッセージの最初のレコードであるか否かを示す識別子ＭＢと、そのＲｅｃｏｒｄがメッセージの最後のレコードであるか否かを示す識別子ＭＥが含まれる。さらに、この先頭部分Ｄ１には、Ｐａｙｌｏａｄ部分Ｄ７のデータ長が１バイト長であるか、４バイト長であるかを示す識別子ＳＲ（Ａ１）が含まれる。
【００６１】
さらに、この先頭部分Ｄ１には、Ｒｅｃｏｒｄ  ＩＤ部分Ｄ６の有無を示す識別子ＩＬ（Ａ２）、及びＲｅｃｏｒｄ  Ｔｙｐｅ部分Ｄ５のフォーマットを指定する識別子ＴＮＦ（Ａ３）が含まれる。また、ＮＤＥＦ  Ｒｅｃｏｒｄのヘッダ部分Ｄ２、Ｄ３、Ｄ４には、それぞれ、Ｒｅｃｏｒｄ  Ｔｙｐｅ部分Ｄ５、Ｒｅｃｏｒｄ  ＩＤ部分Ｄ６、Ｐａｙｌｏａｄ部分Ｄ７のデータ長が格納される。
【００６２】
Ｒｅｃｏｒｄ  Ｔｙｐｅ部分Ｄ５は、Ｐａｙｌｏａｄ部分Ｄ７に格納されるデータの識別子として利用される。そのため、Ｒｅｃｏｒｄ  Ｔｙｐｅ部分Ｄ５は、Ｐａｙｌｏａｄ部分Ｄ７に格納されたデータのフォーマットが特定される際に参照される。例えば、Ｒｅｃｏｒｄ  Ｔｙｐｅ部分Ｄ５により、Ｐａｙｌｏａｄ部分Ｄ７の構造、及び意味が決定される（Ａ４）。
【００６３】
また、Ｒｅｃｏｒｄ  ＩＤ部分Ｄ６は、Ｐａｙｌｏａｄを同定するためのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）が格納される（Ａ５）。尚、Ｒｅｃｏｒｄ  Ｔｙｐｅの定義は、ＮＦＣＦｏｒｕｍが規定する場合と、ユーザが独自に定義する場合とがある。
【００６４】
さらに、図４を参照する。図４は、ＮＤＥＦメッセージの構成例を示す説明図である。ＮＤＥＦメッセージは、図３に示すＮＤＥＦ  Ｒｅｃｏｒｄが集まって構成される。尚、ＮＤＥＦ  Ｒｅｃｏｒｄの先頭部分Ｄ１に含まれる識別子ＭＢ＝１のレコードから、識別子ＭＥ＝１のレコードまでが１つのＮＤＥＦメッセージを構成する。
【００６５】
［ハンドオーバーメッセージの構成例］
次に、図５を参照しながら、本実施形態に係るハンドオーバーメッセージの具体的な構成について説明する。図５は、本実施形態に係るハンドオーバーメッセージの具体的な構成を示す説明図である。尚、第２の通信方式に対応した通信デバイスが複数存在する場合も想定されるが、ここでは、２つの第２の通信方式（ＢＴとＷＬＡＮ）に対応する通信デバイス（近距離通信部１０８）が存在する場合について考える。
【００６６】
ヘッダ部分を構成する第１のＮＤＥＦ  Ｒｅｃｏｒｄ（ＮＤＥＦ（１））には、ＮＤＥＦメッセージがハンドオーバー用であることを示すハンドオーバー用ＲｅｃｏｒｄＴｙｐｅが格納される。より具体的は、ハンドオーバー要求用のメッセージであることを示す“Ｈｑ（ＨａｎｄｏｖｅｒＲｅｑｕｅｓｔ）”、又は要求への返答メッセージであることを示す”Ｈｓ（ＨａｎｄｏｖｅｒＳｅｌｅｃｔ）”がＲｅｃｏｒｄ  Ｔｙｐｅ内に記入されている。また、このＮＤＥＦ（１）以降に続くハンドオーバーメッセージ内のＮＤＥＦ通信パケットの数がＰｌａｙｌｏａｄ内に格納される。
【００６７】
ＮＤＥＦ（１）に続くＮＤＥＦ通信パケットであるａｌｔｅｒｎａｔｉｖｅ  Ｃａｒｒｉｅｒレコード（Ａｌｔｅｒｎａｔｉｖｅ  Ｃａｒｒｉｅｒ  Ｒｅｃｏｒｄ；ＡＣＲ）は、ＮＤＥＦ（１）で示された数だけ存在している。このＡＣＲのペイロード中には、自装置の通信デバイス種別や起動状態（電源ＯＮ／ＯＦＦ）等の情報と、詳細な設定情報の参照先が格納されている。
【００６８】
また、ＮＤＥＦ（２）には、このパケットがＢＴデバイス（以下、ＢＤ）の接続情報であることを示す”ｂｌｕｅｔｏｏｔｈ．ｏｒｇ．ｓｐ”がＴｙｐｅ  Ｒｅｃｏｒｄ中に記述される。さらに、ＮＤＥＦ（２）には、詳細情報（ＮＤＥＦ（４）、及びＮＤＥＦ（５））への２つの参照ポインタがＰａｙｌｏａｄ中に格納される。
【００６９】
同様に、ＮＤＥＦ（３）のＲｅｃｏｒｄ  Ｔｙｐｅには、このパケットがＷＬＡＮデバイスの接続情報であることを示す”ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｗｆａ．ｗｓｃ”が記述される。また、ＮＤＥＦ（３）には、詳細情報（ＮＤＥＦ（６）、及びＮＤＥＦ（７））への２つの参照ポインタがＰａｙｌｏａｄ中に格納されている。
【００７０】
次に、各通信方式に関するパラメータが格納されているＮＤＥＦ通信パケットのペイロードについて、より詳細に説明する。
【００７１】
まず、ＮＤＥＦ（４）、及びＮＤＥＦ（６）には、それぞれ第２の通信方式の各規格（ＢＴ、ＷＬＡＮ）が定めた認証処理に最低限必要な情報が記入されている。具体的には、ＮＤＥＦ（４）には、ＢＴのＯＯＢ認証で使われるＢＤアドレス、ハッシュ値（１６バイト）、及び乱数列（１６バイト）が格納されている。一方、ＮＤＥＦ（６）には、ＷＰＳ認証に使われる”ＷＰＳ  Ｃｒｅｄｅｎｔｉａｌ”情報であるＳＳＩＤ、暗号方式、認証方式、ネットワークキー、及びＭＡＣアドレス等の情報が格納されている。
【００７２】
ＮＤＥＦ（５）には、ＢＴ認証後にアプリケーションを起動するのに必要な情報（例えば、起動するアプリケーション名、使用するプロファイル名、起動前にユーザーへ表示するメッセージ等）、ネットワーク構成情報（例えば、ピコネットのＭａｓｔｅｒ／Ｓｌａｖｅ指定等）、アプリケーションが起動した後に必要になるオプション情報、及びユーザ情報であるプロファイル情報が格納されている。
【００７３】
同様に、ＮＤＥＦ（６）には、ＷＰＳ仕様には記されていないがＷＬＡＮ認証後にアプリケーションを起動するのに必要な情報（例えば、起動するアプリケーション名、使用するプロトコルであるＤＬＮＡ等、起動前にユーザへ表示するメッセージ等）が格納されている。さらに、ＮＤＥＦ（６）には、ネットワーク構成情報（例えば、インフラモードなのか、或いは、アドホックモードなのかを示す情報、決定していれば自装置のＩＰアドレス等）、アプリケーションが起動した後に必要になるオプション情報（例えば、ＵＰｎＰ接続による相手先検索方法が記されたＨＴＭＬテキストデータ）、及びユーザ情報であるプロファイル情報が格納されている。
【００７４】
［ハンドオーバーメッセージの分割方法］
このように、ＮＤＥＦメッセージには種々の情報が格納される。上記のように、ＮＤＥＦ（５）、及びＮＤＥＦ（６）の構成要素には、そのＮＤＥＦ通信パケットの前半部分に、認証を行う前に必要になる部分が集約している。さらに、そのＮＤＥＦ通信パケットの後半部分に、認証後に交換し合えば良い情報が集約している。そこで、本実施形態においては、制御部１１０により、この前半部分と後半部分との間の境界線が管理される。
【００７５】
まず、制御部１１０は、上記の境界線に基づいてＮＤＥＦメッセージを２分割する。そして、制御部１１０は、その境界線までの前半部分が含まれるハンドオーバーメッセージを新たなＮＤＥＦ通信パケットとして再構成する。さらに、制御部１１０は、新たに再構成されたＮＤＥＦ通信パケットのメッセージの最後尾に第２通信方式に関する情報を含める。例えば、制御部１１０は、第２通信方式に関する情報として、分割された残りの部分が後続パケットとして伝送されるか否かを示すフラグ、第２通信方式のプロトコル種別を示す情報、及び各プロトコルに必要なパラメータを付加する。
【００７６】
第２通信方式のプロトコル種別としては、例えば、ＢＴの場合、Ｏｂｊｅｃｔ  Ｐｕｓｈ  Ｐｒｏｆｉｌｅ（ＯＰＰ）やＳｅｒｉａｌ  Ｐｏｒｔ  Ｐｒｏｆｉｌｅ（ＳＰＰ）、Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｆｉｌｅ（ＦＴＰ）、Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｏｗｏｒｋｉｎｇ  Ｐｒｏｆｉｌｅ、ＬＡＮ  Ａｃｃｅｓｓ  Ｐｒｏｆｉｌｅ（ＬＡＰ）等の各種プロファイルが含まれる。一方、ＷＬＡＮの場合、第２通信方式のプロトコル種別としては、ソケット通信やＦＴＰのプロトコル等が含まれる。また、各プロトコルに必要なパラメータとしては、例えば、ソケット通信の場合、ＩＰアドレスやポート番号等が含まれる。一方、各プロトコルに必要なパラメータとしては、例えば、ＦＴＰの場合、ＩＰアドレス、ＦＴＰユーザー名、及びＦＴＰパスワードが含まれる。
【００７７】
（具体例：前半部分と後半部分との間の分類）
図６、図７には、制御部１１０により分割されたＮＤＦＥメッセージの前半部分（図６）と、後半部分（図７）とに関する具体的な例が示されている。
【００７８】
まず、図６を参照する。図６に示すように、ＮＦＣ通信（第１通信方式）で伝送される前半部分の情報としては、例えば、ＢＴのＯＯＢ認証情報やＷＰＳのＣｒｅｄｅｎｔｉａｌ認証情報がある。ＢＴのＯＯＢ認証情報には、ＢＤアドレス、ハッシュ値、乱数列等の情報が含まれる。一方、ＷＰＳのＣｒｅｄｅｎｔｉａｌ認証情報には、ネットワークのＳＳＩＤ、暗号化方式、認証タイプ、ネットワークキー、マックアドレス等の情報が含まれる。これらの情報は、第２通信方式による認証処理等に利用される情報であり、第２通信方式による通信経路の確立に必要な情報である。
【００７９】
次に、図７を参照する。図７に示すように、ＮＦＣ通信（第１通信方式）で伝送されなくてもよい後半部分の情報としては、例えば、ＢＴ又はＷＬＡＮのアプリケーション情報、ＨＴＴＰメッセージ、ユーザ情報等が含まれる。ＢＴ又はＷＬＡＮのアプリケーションの情報としては、アプリケーションの名前、プロファイル情報、メッセージ等の情報が含まれる。ＨＴＴＰメッセージとしては、機器検索方式等に関するプロファイル情報が含まれる。ユーザ情報としては、ユーザのプロファイル情報が含まれる。これらの情報は、第２通信方式による通信経路の確立に必ずしも必要な情報ではない。また、これらの情報は、対応するアプリケーションやプロトコルの種類が増大するに連れて、そのデータサイズが大きくなるため、第１通信方式で通信するのには適さない性質のものである。
【００８０】
（伝送方法について）
次に、図８を参照しながら、本実施形態に係るハンドオーバーメッセージの伝送方法について説明する。図８は、本実施形態に係るハンドオーバーメッセージの伝送方法を示す説明図である。
【００８１】
上記のように、ハンドオーバーメッセージは、制御部１１０により、ＮＦＣ通信で伝送すべき前半部分と、それ以外の後半部分とに分割される。さらに、前半部分と後半部分とを繋ぐ部分に、分割された後半部分のメッセージが存在するか否かを示すフラグと、後半部分を伝送するのに利用される第２通信方式のプロトコル、及び伝送パラメータが格納される。そして、この繋ぎ部分は、制御部１１０により、前半部分の最後尾に付加される。そして、制御部１１０により、繋ぎ部分を含む前半部分が新たなＮＦＣ通信パケットとして再構成され、後半部分が第２通信方式の通信パケットとして再構成される。
【００８２】
上記の前半部分に相当するＮＦＣ通信パケットは、近接通信部１０４により相手装置に伝送される。そして、相手装置によりＮＦＣ通信パケットに含まれる認証情報が抽出され、その認証情報を用いて認証処理が実行されて第２通信方式による伝送経路が確立される。その後、後半部分に相当する第２通信方式の通信パケットは、近距離通信部１０８により相手装置に伝送され、所望のアプリケーションによるサービスの提供が開始される。
【００８３】
（分割パケットの送信手順について）
上記の伝送方法の流れについて、図９を参照しながら、より詳細に説明する。図９は、本実施形態に係る分割パケットの送信手順を示す説明図である。但し、以下の説明では、通信装置１００が接続要求側であり、通信装置２００が接続受入側であるとする。
【００８４】
まず、ハンドオーバーメッセージが前半部分と後半部分とに分割され、前半部分に相当するＮＦＣ通信パケットが送受信される（Ｓｔｅｐ．１）。このとき、ユーザは、通信装置１００、２００を１０ｃｍ程度の通信可能範囲内に近接させ、ＮＦＣ通信が完了するまで、その状態を維持する必要がある。
【００８５】
しかしながら、本実施形態の再構成されたＮＦＣ通信パケットには、主に第２通信方式の識別情報等しか含まれていないため、非常に短時間でＮＦＣ通信が完了する。その結果、ユーザが通信装置１００、２００を近接させた状態で維持すべき時間が短縮され、ユーザの負担が軽減される。尚、ＮＦＣ通信が完了した後で、ユーザは、通信装置１００、２００をＮＦＣ通信の通信可能範囲の外に離してもよい。
【００８６】
次いで、通信装置１００、２００は、ＮＦＣ通信パケットに含まれる認証情報を利用して、第２通信方式による通信経路を確立するための認証処理を実施する（Ｓｔｅｐ．２）。この認証処理は、より通信可能範囲の広い第２通信方式を介したパケット通信により実行されるため、通信装置１００、２００が互いに近接している必要がない。認証処理が成功裏に完了すると、分割パケットの後半部分に相当する第２通信方式の通信パケットが送受信される（Ｓｔｅｐ．３）。
【００８７】
このとき、Ｓｔｅｐ．１で伝送されたＮＦＣ通信パケットの最後尾に付加された第２通信方式に関する情報に基づいて通信が開始される。例えば、第２通信方式のプロトコル、及びパラメータが参照される。通信装置１００、２００は、互いに受信した後半部分の通信パケットからアプリケーションの起動に利用されるパラメータ情報等を抽出し、そのパラメータ情報を利用してアプリケーションを起動する（Ｓｔｅｐ．４）。
【００８８】
以上、ハンドオーバーメッセージの分割方法、及び分割パケットの伝送方法について説明した。上記のように、ＮＦＣ通信で伝送されるデータサイズが小さくなるように分割して送信することで、ＮＦＣ通信に要する時間が短縮され、ユーザが通信装置１００、２００を互いに近接させたまま維持する時間を短くすることができる。
【００８９】
また、データを伝送する際に、第１通信方式よりも高速な伝送が可能な第２通信方式を利用する割り合いを増加させることで、通信処理に要する時間が短縮される。その結果、アプリケーションの起動までに要する時間が全体として短縮される。
【００９０】
（ハンドオーバー処理の詳細な流れについて）
次に、図１０〜図１３を参照しながら、本実施形態に係るハンドオーバー処理の詳細な流れについて説明する。図１０〜図１３は、本実施形態に係るハンドオーバー処理の詳細な流れを示す説明図である。これらの説明図は、上記のハンドオーバー処理工程の流れを詳細に示すものであり、特に、相手装置が対応する通信プロトコルに応じてパケット分割の可否を判断したり、通信処理の調停に係る処理工程を含むものである。
【００９１】
（ハンドオーバーの要求側の処理）
まず、図１０、図１１を参照する。図１０、図１１は、ハンドオーバーの要求側（通信装置１００）に関する処理の流れを示す説明図である。特に、図１０は、ＮＦＣ通信に係る処理の流れを示している。図１１は、第２通信方式（２ｎｄキャリア通信）に係る処理の流れを示している。
【００９２】
ハンドオーバー処理が開始されると、通信装置１００は、ハンドオーバーメッセージを分割する（Ｓ１０２）。このとき、通信装置１００は、上記の分割方法に基づいてＮＦＣ通信で伝送すべき前半部分と、それ以外の後半部分とに分割する。次いで、通信装置１００は、ハンドオーバーメッセージを相手装置（通信装置２００）に送信する（Ｓ１０４）。このとき、通信装置１００は、近接通信部１０４により、分割されたハンドオーバーメッセージの前半部分に相当するＮＦＣ通信パケットを通信装置２００に対して送信する。ここで送信されたＮＦＣ通信パケットは、後述する図１２のステップＳ２０２において処理される。
【００９３】
次いで、通信装置１００は、対向する通信装置２００から、ハンドオーバーメッセージ（ＮＦＣ通信パケット）を受信する。そして、通信装置１００は、受信したハンドオーバーメッセージが分割パケットか否かを示すフラグ（以下、分割フラグ）と、第２通信方式の使用可否を示す情報（以下、方式対応情報）とを抽出する（Ｓ１０６）。ここで受信したＮＦＣ通信パケットは、後述する図１２のステップＳ２１０において通信装置２００により送信されたものである。
【００９４】
次いで、通信装置１００は、ステップＳ１０４で自装置が送信したＮＦＣ通信パケットが、元のハンドオーバーメッセージを分割したものか否か、及び、通信装置２００が自装置の第２通信方式による通信プロトコル（例えば、ＢＴの場合にはＯＰＰ又はＳＰＰプロファイル、ＷＬＡＮの場合にはＩＰソケット又はＦＴＰ等）に対応しているか否かが判断される（Ｓ１０８）。このとき、通信装置１００は、受信したＮＦＣ通信パケットから抽出される方式対応情報に基づいて通信装置２００が対応する第２通信方式のプロトコルを認知することができる。
【００９５】
通信装置２００が、ハンドオーバーメッセージの後半部分に相当する通信パケットを送信するための第２通信方式による通信プロトコルに対応していなければ、通信装置２００は、この通信パケットを受信することができない。そのため、通信装置１００が送信したＮＦＣ通信パケットが分割されたものか否か、及び、通信装置２００が後半部分に相当する通信パケットを送信するための通信プロトコルに対応するか否かが判断される。
【００９６】
もし、通信装置１００が送信したＮＦＣ通信パケットが分割されたものであり、通信装置２００が後半部分に相当する通信パケットの受信に非対応の場合、ステップＳ１１０の処理に進行する。一方、通信装置１００が分割されたＮＦＣ通信パケットを送信していないか、或いは、通信装置２００が後半部分に相当する通信パケットの受信に対応している場合、第２通信方式による認証処理（図１１）に進行する。
【００９７】
ステップＳ１１０の処理に進行すると、通信装置１００は、ハンドオーバーメッセージを分割せず（Ｓ１１０）、ＮＦＣ通信にてハンドオーバーメッセージに含まれる全ての設定情報を送信する（Ｓ１０４）。この場合、ＮＦＣ通信の通信時間が短縮されない。
【００９８】
次いで、図１１を参照する。第２通信方式による認証処理に進行した場合、通信装置１００は、当該認証処理に必要な情報を交換した後、通信装置２００との間で第２通信方式により認証処理を実行する。そして、認証処理が成功裏に完了すると、通信装置１００は、ステップＳ１１２の処理に進行する。
【００９９】
次いで、通信装置１００は、ステップＳ１０４（図１０）で送信したＮＦＣ通信パケットが分割したものであるか否かを判断する（Ｓ１１２）。分割したＮＦＣ通信パケットを送信した場合、通信装置１００は、ステップＳ１１４の処理に進行する。一方、分割せずにＮＦＣ通信パケットを送信した場合、通信装置１００は、ステップＳ１１６の処理に進行する。
【０１００】
ステップＳ１１４において、通信装置１００は、既に認証処理を経て確立した第２通信方式の通信経路を介して残りのハンドオーバーメッセージを送信する（Ｓ１１４）。ここで送信された残りのハンドオーバーメッセージは、後述する図１３のステップＳ２１８にて処理される。
【０１０１】
次いで、通信装置１００は、ステップＳ１０６（図１０）で受信したＮＦＣ通信パケットが分割されたものであるか否かを判断する（Ｓ１１６）。受信したＮＦＣ通信パケットが分割されたものである場合、通信装置１００は、ステップＳ１１８の処理に進行する。一方、受信したＮＦＣ通信パケットが分割されていないものである場合、通信装置１００は、ステップＳ１２０の処理に進行する。
【０１０２】
ステップＳ１１８において、通信装置１００は、第２通信方式により、対向する通信装置２００から残りのハンドオーバーメッセージを受信する（Ｓ１１８）。このハンドオーバーメッセージは、後述する図１３のステップＳ２２２において送信されたものである。次いで、通信装置１００は、最後に受信したハンドオーバーメッセージを解析し（Ｓ１２０）、適切なアプリケーションを起動する。
【０１０３】
（ハンドオーバーの受入側の処理）
次に、図１２を参照する。図１２、図１３は、ハンドオーバーの受入側（通信装置２００）に関する処理の流れを示す説明図である。特に、図１２は、ＮＦＣ通信に係る処理の流れを示している。図１３は、第２通信方式（２ｎｄキャリア通信）に係る処理の流れを示している。
【０１０４】
まず、通信装置２００は、対向する通信装置１００からハンドオーバーメッセージ（ＮＦＣ通信パケット）を受信する。このとき、通信装置２００は、図１０のステップＳ１０４において通信装置１００が送信したＮＦＣ通信パケットを受信する。
【０１０５】
そして、通信装置２００は、受信したＮＦＣ通信パケットから、そのＮＦＣ通信パケットが分割されたものか否かを示す分割フラグと、通信装置１００が自装置の第２通信方式による通信プロトコルに対応しているか否かを示す方式対応情報を抽出する（Ｓ２０２）。通信プロトコルとしては、例えば、ＢＴの場合にはＯＰＰ、又はＳＰＰプロファイル、ＷＬＡＮの場合にはＩＰソケット、又はＦＴＰ等がある。
【０１０６】
次いで、通信装置２００は、抽出した方式対応情報に基づいて第２通信方式でハンドオーバーメッセージを送信可能か否かを判断する（Ｓ２０４）。第２通信方式による送信が可能な場合、通信装置２００は、ステップＳ２０８の処理に進行する。一方、第２通信方式による送信が不可の場合、通信装置２００は、ステップＳ２０６の処理に進行する。
【０１０７】
ステップＳ２０６の処理に進行した場合、自装置が対応する第２通信方式の通信プロトコルに通信装置１００が対応していないのであるから、通信装置２００は、ハンドオーバーメッセージの分割をしない（Ｓ２０６）。そして、メッセージの全てをＮＦＣ通信にて送信する（Ｓ２１０）。
【０１０８】
一方、ステップＳ２０８の処理に進行した場合、通信装置２００は、ハンドオーバーメッセージを分割し（Ｓ２０８）、前半部分に相当するＮＦＣ通信パケットのみをＮＦＣ通信にて送信する（Ｓ２１０）。ステップＳ２１０で送信されたハンドオーバーメッセージは、図１０のステップＳ１０６において処理される。
【０１０９】
次いで、通信装置２００は、対向する通信装置１００がＮＦＣ通信パケットを分割して送信してきたか否か、及び、自装置が第２通信方式で受信可能か否かを判断する（Ｓ２１２）。
【０１１０】
通信装置１００により分割されたＮＦＣ通信パケット（前半部分）が送信された場合、後半部分を受信する第２通信方式の通信プロトコルが自装置に実装されていなければ、通信装置１００により再度ＮＦＣ通信パケットが送信される。そのため、通信装置２００は、受信したＮＦＣ通信パケットが分割されたものであり、その後半部分の受信プロトコルに自装置が対応していない場合、ステップＳ２１４の処理に進行する。
【０１１１】
ステップＳ２１４において、通信装置２００は、対向する通信装置１００から再送されるＮＦＣ通信パケットを待ち（Ｓ２１４）、再びステップＳ２０２の処理に進行する。一方、受信したＮＦＣ通信パケットが分割パケットでないか、或いは、自装置が後半部分の受信プロトコルに対応する場合、通信装置２００は、第２通信方式の認証処理（図１３）に進行する。
【０１１２】
次いで、図１３を参照する。第２通信方式の認証処理に進行した場合、通信装置２００は、当該認証処理に必要な情報を交換した後、通信装置１００との間で第２通信方式を利用して認証処理を実行する。そして、認証処理が成功裏に完了すると、通信装置２００は、ステップＳ２１６の処理に進行する。
【０１１３】
次いで、通信装置２００は、ステップＳ２０２（図１２）で受信したＮＦＣ通信パケットが分割したものであるか否かを判断する（Ｓ２１６）。分割されたＮＦＣ通信パケットを受信した場合、通信装置２００は、ステップＳ２１８の処理に進行する。一方、分割されていないＮＦＣ通信パケットを受信した場合、通信装置２００は、ステップＳ２２０の処理に進行する。
【０１１４】
ステップＳ２１８において、通信装置２００は、既に認証処理を経て確立した第２通信方式の通信経路を介して残りのハンドオーバーメッセージを受信する（Ｓ２１８）。ここで受信される残りのハンドオーバーメッセージは、図１１のステップＳ１１４にて送信されたものである。
【０１１５】
次いで、通信装置２００は、ステップＳ２１０（図１２）で送信したＮＦＣ通信パケットが分割されたものであるか否かを判断する（Ｓ２２０）。送信したＮＦＣ通信パケットが分割されたものである場合、通信装置２００は、ステップＳ２２２の処理に進行する。一方、送信したＮＦＣ通信パケットが分割されていないものである場合、通信装置２００は、ステップＳ２２４の処理に進行する。
【０１１６】
ステップＳ２２２において、通信装置２００は、第２通信方式により、対向する通信装置１００に対して残りのハンドオーバーメッセージを送信する（Ｓ２２２）。このハンドオーバーメッセージは、図１１のステップＳ１１８において処理される。次いで、通信装置２００は、最後に受信したハンドオーバーメッセージを解析し（Ｓ２２４）、適切なアプリケーションを起動する。
【０１１７】
以上、本実施形態に係る通信装置１００、２００の機能構成、ハンドオーバーメッセージの構成、ハンドオーバーメッセージの分割方法、及び分割されたハンドオーバーメッセージの交換手順について説明した。
【０１１８】
上記のように、本実施形態では、第１通信方式にて伝送されるパケットを２分割した上で、その前半部分を第１通信方式にて伝送し、前半部分に含まれる認証情報に基づいて第２通信方式による認証を行う。さらに、認証処理が成功裏に完了した後で、後半部分のパケット情報が伝送される。
【０１１９】
かかる構成により、第１通信方式における通信データ量が低減され、第１通信方式による通信時間が短くなる。その結果、第１通信方式が有する通信可能な距離や角度等の制限に起因する所定の通信状態をユーザが長く維持しておく必要がなくなる。そのため、第１通信方式による通信の間にユーザに掛かる負荷が軽減され、より利便性が向上する。
【０１２０】
また、分割された通信パケットの後半部分を伝送するための伝送プロトコルに関する情報を通信パケットの前半部分に付加することにより、双方の機器がサポートしている最適な伝送プロトコルを利用して後半部分のパケットを伝送することができるようになる。また、双方の機器が共通で使用できるプロトコルがない場合に、通信パケットに含まれる全ての情報を第１通信方式にて伝送することが可能となる。このように、接続相手先と自装置のプロトコルの実装状況を対比し、より適切な方式を選択できるようになる。その結果、より汎用性が増大する。
【０１２１】
［非接触通信装置の装置構成例］
ここで、図１４を参照しながら、上記の装置が有する機能の一部又は全部を実現することが可能な非接触型の通信装置の装置構成例について簡単に説明する。図１４は、非接触通信装置の装置構成例を示す説明図である。尚、上記の装置が有する機能は、この非接触通信装置が有する構成要素の一部のみを利用して実現してもよい。
【０１２２】
図１４に示すように、この通信装置は、主に、ＩＣカード部分と、リーダ／ライタ部分と、コントローラ７２２とにより構成される。
【０１２３】
（ＩＣカード部分）
ＩＣカード部分は、例えば、アンテナ７０２と、フロントエンド回路７０４と、変調器７０６と、コマンド再生器７０８と、クロック再生器７１０と、制御回路７１２と、暗号化回路７１４と、メモリ７１６と、有線インターフェース回路７１８とで構成される。
【０１２４】
アンテナ７０２は、ループ・アンテナにより構成され、リーダ／ライタが有するループ・アンテナと磁気的に結合してコマンドや電力を受け取る。フロントエンド回路７０４は、リーダ／ライタから送出された搬送波を整流して直流電源を再生する。
【０１２５】
また、フロントエンド回路７０４は、取得した１３．５６ＭＨｚの搬送波を分周してコマンド再生器７０８、及びクロック再生器７１０に入力する。コマンド再生器７０８は、入力された搬送波からコマンドを再生して制御回路７１２に入力する。クロック再生器７１０は、入力された搬送波からロジック回路を駆動するためのクロックを再生して制御回路７１２に入力する。また、フロントエンド回路７０４は、再生した電源を制御回路７１２（ＣＰＵ）に供給する。
【０１２６】
全ての回路に電源が供給されると、制御回路７１２は、再生されたコマンドに応じて各回路を駆動する。尚、制御回路７１２から出力されたデータは、暗号化回路７１４により暗号化されてメモリ７１６に格納される。尚、メモリ７１６は、例えば、磁気的、光学的、又は光磁気的に情報を記録する記憶装置であってもよいし、ＲＯＭやＲＡＭ等に利用される半導体記憶装置であってもよい。
【０１２７】
一方、メモリ７１６内に格納された暗号化データを送信する場合、フロントエンド回路７０４は、変調器７０６により変調された暗号化データに基づいてアンテナ７０２の給電点にある負荷インピーダンスを変化させ、その変化によりアンテナ７０２によって誘起される磁界を変化させる。この磁界変化により、磁気的に結合したリーダ／ライタのアンテナを流れる電流変化が誘起されて暗号化データが伝送される。
【０１２８】
また、制御回路７１２は、有線インターフェース回路７１８を介してコントローラ７２２により制御されてもよい。また、ＩＣカード部分は、インターフェースＩ／Ｆ（非図示）を介して、後述のリーダ／ライタ部分との間で情報を送受信し、相互に又は一方から他方を制御することが可能であってもよい。
【０１２９】
（リーダ／ライタ部分）
リーダ／ライタ部分は、例えば、アンテナ７０２と、フィルタ７３２と、受信アンプ７３４と、周波数変換器７３６と、識別器７３８と、ロジック回路７４０と、制御回路７１２と、メモリ７１６と、有線インターフェース回路７４２と、変調器７４６と、局部発振器７５０と、送信アンプ７４８とにより構成される。
【０１３０】
リーダ／ライタ部分は、非接触ＩＣカード等との磁気的な結合を利用してコマンドや電力を供給する。このリーダ／ライタ部分は、制御部７１２（ＣＰＵ）の制御により、非接触ＩＣカード等に電力を供給して活性化させてから、所定の伝送プロトコルに従って通信を開始する。このとき、リーダ／ライタ部分は、通信接続の確立、アンチコリジョン処理、及び認証処理等を行う。
【０１３１】
リーダ／ライタ部分は、局部発振器７５０を利用して搬送波を生成する。情報を送信する場合、まず、制御回路７１２は、メモリ７１６からデータを読み出してロジック回路７４０に伝送する。そして、変調器７４６は、ロジック回路７４０から出力された信号に基づいて局部発振器７５０により生成された搬送波を変調する。さらに、送信アンプ７４８は、変調器７４６から出力された変調波を増幅し、アンテナ７０２を介して送信する。
【０１３２】
一方、情報を受信する場合、まず、アンテナ７０２を介して受信された変調波は、フィルタ７３２を通した上で受信アンプ７３４に入力される。そして、受信アンプ７３４により増幅された信号は、周波数変換器７３６により周波数変換されてロジック回路７４０に入力される。さらに、ロジック回路７４０から出力された信号は、制御回路７１２によりメモリ７１６に記録される。或いは、当該信号は、有線インターフェース回路７４２を介して外部のコントローラ７２２に伝送される。
【０１３３】
以上、非接触通信装置の装置構成例について説明した。当該非接触通信装置は、例えば、携帯電話、携帯情報端末、各種の通信機器、パーソナルコンピュータ等の情報処理装置、或いは、ゲーム機や情報家電等であってもよい。また、上記の非接触通信装置が有する機能又は構成要素の一部又は全部を内蔵した各種の機器についても、上記実施形態の技術的範囲に含まれる。
【０１３４】
［ハードウェア構成（情報処理装置）］
上記装置が有する各構成要素の機能は、例えば、図１５に示すハードウェア構成を有する情報処理装置により、上記の機能を実現するためのコンピュータプログラムを用いて実現することが可能である。図１５は、上記装置の各構成要素が有する機能を実現することが可能な情報処理装置のハードウェア構成を示す説明図である。
【０１３５】
図１５に示すように、前記の情報処理装置は、主に、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）９０２と、ＲＯＭ９０４と、ＲＡＭ９０６と、ホストバス９０８と、ブリッジ９１０と、外部バス９１２と、インターフェース９１４と、入力部９１６と、出力部９１８と、記憶部９２０と、ドライブ９２２と、接続ポート９２４と、通信部９２６とにより構成される。
【０１３６】
ＣＰＵ９０２は、例えば、演算処理装置又は制御装置として機能し、ＲＯＭ９０４、ＲＡＭ９０６、記憶部９２０、又はリムーバブル記録媒体９２８に記録された各種プログラムに基づいて各構成要素の動作全般又はその一部を制御する。
【０１３７】
ＲＯＭ９０４は、例えば、ＣＰＵ９０２に読み込まれるプログラムや演算に用いるデータ等を格納する。ＲＡＭ９０６は、例えば、ＣＰＵ９０２に読み込まれるプログラムや、そのプログラムを実行する際に適宜変化する各種パラメータ等を一時的又は永続的に格納する。これらの構成要素は、例えば、高速なデータ伝送が可能なホストバス９０８によって相互に接続されている。また、ホストバス９０８は、例えば、ブリッジ９１０を介して比較的データ伝送速度が低速な外部バス９１２に接続されている。
【０１３８】
入力部９１６は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチ、及びレバー等の操作手段である。また、入力部９１６は、赤外線やその他の電波を利用して制御信号を送信することが可能なリモートコントロール手段（所謂、リモコン）であってもよい。なお、入力部９１６は、上記の操作手段を用いて入力された情報を入力信号としてＣＰＵ９０２に伝送するための入力制御回路等により構成されている。
【０１３９】
出力部９１８は、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ）、ＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）、ＰＤＰ（Ｐｌａｓｍａ  ＤｉｓｐｌａｙＰａｎｅｌ）、又はＥＬＤ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ  Ｄｉｓｐｌａｙ）等のディスプレイ装置、スピーカ、ヘッドホン等のオーディオ出力装置、プリンタ、携帯電話、又はファクシミリ等、取得した情報を利用者に対して視覚的又は聴覚的に通知することが可能な装置である。
【０１４０】
記憶部９２０は、各種のデータを格納するための装置であり、例えば、ハードディスクドライブ（ＨＤＤ；Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）等の磁気記憶デバイス、半導体記憶デバイス、光記憶デバイス、又は光磁気記憶デバイス等により構成される。
【０１４１】
ドライブ９２２は、例えば、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリ等のリムーバブル記録媒体９２８に記録された情報を読み出し、又はリムーバブル記録媒体９２８に情報を書き込む装置である。リムーバブル記録媒体９２８は、例えば、ＤＶＤメディア、Ｂｌｕ−ｒａｙメディア、ＨＤ−ＤＶＤメディア、コンパクトフラッシュ（登録商標）（ＣＦ；ＣｏｍｐａｃｔＦｌａｓｈ）、メモリースティック、又はＳＤメモリカード（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ  ｍｅｍｏｒｙ  ｃａｒｄ）等である。もちろん、リムーバブル記録媒体９２８は、例えば、非接触型ＩＣチップを搭載したＩＣカード、又は電子機器等であってもよい。
【０１４２】
接続ポート９２４は、例えば、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）ポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ（Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ）、ＲＳ−２３２Ｃポート、又は光オーディオ端子等のような外部接続機器９３０を接続するためのポートである。外部接続機器９３０は、例えば、プリンタ、携帯音楽プレーヤ、デジタルカメラ、デジタルビデオカメラ、又はＩＣレコーダ等である。
【０１４３】
通信部９２６は、ネットワーク９３２に接続するための通信デバイスであり、例えば、有線又は無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、又はＷＵＳＢ（Ｗｉｒｅｌｅｓｓ  ＵＳＢ）用の通信カード、光通信用のルータ、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）用のルータ、又は各種通信用のモデム等である。
【０１４４】
また、通信部９２６に接続されるネットワーク９３２は、有線又は無線により接続されたネットワークにより構成され、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、可視光通信、放送、人体通信、又は衛星通信等である。尚、通信部９２６の機能に上記の非接触通信装置が備える非接触通信機能を含めてもよい。
【０１４５】
［補遺１：＜ＳＳＰ方式について＞］
上記の実施形態に係る技術は、以下で説明するＳＳＰ方式に対し、好適に適用することが可能である。
【０１４６】
［１：ＳＳＰ方式の提案モデル］
ＳＳＰ方式には、４つのモデルが提案されている。これらの４つのモデルは、それぞれ、数字比較モデル、ＪＷ（Ｊｕｓｔ  Ｗｏｒｋ）モデル、ＯＯＢモデル、パスキー入力モデルと呼ばれる。以下、これらの提案モデルについて簡単に説明する。
【０１４７】
（１−１：数字比較モデル）
数字比較モデルは、次のようなシナリオを想定している。（１）互いに通信するデバイスの両方が６桁の数字を表示できるものとする。（２）これらの両方のデバイスには、”Ｙｅｓ”又は”Ｎｏ”のユーザ入力が可能であるとする。このシナリオには、例えば、セルラーフォンやパーソナルコンピュータが適用される。
【０１４８】
（ペアリングの確立手順について）
まず、ユーザは、両方のデバイスが備えるディスプレイ上に表示された６桁の数字（”００００００”から”９９９９９９”まで）を視認する。それから、ユーザは、両方のデバイスに表示された数字が同じであるか否かを尋ねられる。そこで、ユーザは、両方のデバイスに”ＹＥＳ”又は”ＮＯ”を入力する。もし、”ＹＥＳ”が両方のデバイスに入力されたならば、ペアリングが成立する。
【０１４９】
（数字比較モデルの目的）
この数字比較モデルには２つの目的がある。１つ目の目的は、個々のデバイスに固有の名前を持っていない場合に、正しいデバイスがそれぞれ接続されたという承認をユーザに対して与えるということである。２つ目の目的は、中間者攻撃（ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ  ａｔｔａｃｋ）に対する防衛手段を提供することである。
【０１５０】
尚、Ｃｏｒｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ  ２．０＋ＥＤＲ以前の規格で利用されるＰＩＮ入力モデルと、この数字比較モデルとの間には、暗号化技術に係る観点から重大な相違があるという点に注意が必要である。この数字比較モデルで利用される６桁の数字は、人工的なセキュリティアルゴリズムに基づくものであり、現行のセキュリティモデルのようなユーザの手で入力されるものではない。当然の事ながら、表示された数字が知らされることにより、両方のデバイス間で交換される暗号データが復号される危険性が高まるため、これを避けるように構成されているのである。
【０１５１】
（１−２：ＪＷモデル）
ＪＷモデルでは、次のようなシナリオが想定されている。このシナリオでは、少なくとも１つのデバイスが、６桁の数字が表示できるディスプレイを備えていないか、或いは、６桁の数字を入力するためのキーボードを備えていないということが想定されている。このシナリオには、例えば、携帯電話や単体のハンドセットが適用される。現状、大部分のハンドセットはディスプレイを持っていないからである。
【０１５２】
ＪＷモデルは、数字比較方式を利用する。しかし、ユーザには、数字が表示されることはない。また、アプリケーションは、ユーザに対して単に接続の承認を尋ねるだけである。ＪＷモデルは、受動的な盗聴に対して上記の数字比較モデルと同等の耐性を備えた防御手段を提供する。但し、中間者攻撃に対する防御手段を提供するものではない。
【０１５３】
一般的なハンドセット等による４桁の数字（固定ＰＩＮ）を利用したセキュリティモデルと比較するとき、ＪＷモデルのセキュリティレベルは比較的高いと考えられる。その理由は、受動的な盗聴に対する高い耐性が実現されているためである。
【０１５４】
（１−３：ＯＯＢモデル）
ＯＯＢ（Ｏｕｔ  Ｏｆ  Ｂａｎｄ）モデルは、次のようなシナリオを想定している。まず、ＯＯＢの技術は、ペアリングの工程で暗号数字を交換する際又は送信する際に、両方のデバイスを発見するために用いられる。但し、このＯＯＢチャネルは、セキュリティに関する効果を期待して、デバイスの発見とは異なる目的でも提供されるべきである。例えば、ＯＯＢチャネルは、ＢＴの通信チャネルにおけるセキュリティを高めるために提供されるべきである。ＯＯＢチャネルは、中間者攻撃、及びプライバシーの侵害に対する防御手段を提供する。
【０１５５】
尚、ユーザの操作はＯＯＢの機構に依存して異なるかもしれない。例えば、ＯＯＢとして近接場通信（Ｎｅａｒ  Ｆｉｅｌｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ；ＮＦＣ）を適用する場合、ユーザは、はじめに２つのデバイスを互いにタッチさせる。それから、ユーザは、他のデバイスとペアリングを構成したいか否かを尋ねられる。そこで、ユーザは、”ＹＥＳ”又は”ＮＯ”を入力する。”Ｙｅｓ”が入力されると、ペアリングが形成される。
【０１５６】
上記の操作は、デバイス間で情報を交換するためのシングルタッチの操作である。この交換される情報には、ＢＤの発見に利用されるＢＤアドレスのようなデバイス情報と、暗号化に利用されるセキュリティ情報とが含まれる。デバイスの一方は、受信したＢＤアドレスを他のデバイスとの間の接続を確立するために利用することができる。一方、交換されたセキュリティ情報は、認証処理において利用される。尚、ＯＯＢの機構が有する特徴に依存して、１方向、又は双方向の認証処理が実現される。
【０１５７】
ＯＯＢ方式は、次のような場合にのみ選択される。例えば、ＯＯＢによる情報交換によりペアリングが既に有効化されていた場合や、一方又は両方のデバイスが入出力機能の有無（ＩＯ  Ｃａｐａｂｉｌｉｔｙ；Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｃａｐａｂｉｌｉｔｙ）を応答する際にＯＯＢ方式に対応可能であることを通知した場合である。
【０１５８】
ＯＯＢ方式では、ユーザに対して単に接続の承認を尋ねるための情報が利用される。尚、ＯＯＢモデルには、暗号化に必要な情報、及びＢＤアドレスを交換可能な機構であれば、任意のＯＯＢ機構を適用することができる。また、このＯＯＢモデルでは、ユーザがＢＴ通信を利用して既に接続を有効にした手段をサポートせず、接続に際して認証処理のためにＯＯＢチャネルが利用される。
【０１５９】
（１−４：パスキー入力モデル）
パスキー入力モデルは、次のようなシナリオを想定している。（１）一方のデバイスは、入力機能を備えており、かつ、６桁の数字を表示する機能を備えていない。（２）そして、他方のデバイスは、出力機能を備えている。このシナリオは、例えば、パーソナルコンピュータとキーボードの組み合わせに適用される。
【０１６０】
まず、ユーザに対し、一方のデバイスが備えるディスプレイ上に６桁の数字（”００００００”から”９９９９９９”まで）が表示される。それから、ユーザは、他方のデバイスにより表示された数字を入力するように求められる。表示された数字が他方のデバイスに正しく入力された場合にペアリングが形成される。
【０１６１】
［２：セキュリティ確立手段］
ＳＳＰ方式のセキュリティ確立手段は、次のような５つのフェーズにより構成される。
フェーズ１：公開鍵の交換
フェーズ２：認証ステージ１
フェーズ３：認証ステージ２
フェーズ４：リンクキーの算出
フェーズ５：ＬＭＰ認証、及び暗号化
【０１６２】
フェーズ１、３、４、５は、上記の全てのモデルで同じである。但し、フェーズ２（認証ステージ１）に関しては、適用するモデルに依存して若干異なる。尚、以下の説明において、下表１で定義される表現（［Ｔｅｒｍ］）が用いられる。
【０１６３】
（２−１：フェーズ１＜公開鍵の交換＞（図１６（Ａ）を参照））
まず、各デバイスがＥＣＤＨ（Ｅｌｌｉｐｔｉｃ  Ｃｕｒｖｅ  Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）方式に基づいて自身の公開鍵／秘密鍵のペア（ＰＫ，ＳＫ）を生成する（ステップ１）。この鍵ペアは、デバイスの組毎に１度だけ生成される。この鍵ペアは、ペアリング処理の開始前に算出されていてもよい。また、任意の時点で、その鍵ペアはデバイスにより放棄され、新たな鍵ペアが生成されることがある。
【０１６４】
ペアリングは、初期化デバイス（Ｉｎｉｔｉａｔｉｎｇ  Ｄｅｖｉｃｅ  Ａ）により、受信側のデバイス（以下、応答デバイス（Ｎｏｎ−ｉｎｉｔｉａｔｉｎｇ  Ｄｅｖｉｃｅ  Ｂ））に公開鍵が送信されることで開始される（ステップ１ａ）。応答デバイスは、初期化デバイスによる公開鍵の送信に応じて、自身の公開鍵を初期化デバイスに送信する（ステップ１ｂ）。双方の公開鍵（ＰＫａ，ＰＫｂ）は、たとえ、デバイスを認証するものであろうとも、秘密のものと見なされない。尚、ステップ１ａ、１ｂは、上記の全てのモデルで共通である。
【０１６５】
（２−２：フェーズ２＜認証ステージ１＞（図１７〜図２０を参照））
認証ステージ１は、上記の３つのモデル（数字比較モデル、ＯＯＢモデル、パスキー入力モデル）の間で処理が異なる。いずれのモデルを選択するかは、両方のデバイスの入出力機能の有無に基づいて決定される。尚、図１７〜図２０の中で、文頭に記載された数字はステップを表す。
【０１６６】
（２−２−１：認証ステージ１（数字比較モデル／図１７））
数字比較モデルは、効果的な中間者攻撃に対して一定の耐性を有する防御手段を提供する。１度の中間者攻撃に対し、０．０００００１程度の確率でしか攻撃が成功しないであろう。もし、ペアリングされている時点で中間者攻撃がないならば、共有されているリンクキーは、計算上、ペアリングされている間の受動的な盗聴に対しても安全である。
【０１６７】
以下、暗号化の観点から、数字比較モデルにおける認証ステージ１（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｓｔａｇｅ  １）のシーケンスダイアグラムについて説明する。
【０１６８】
公開鍵が交換された後で、各デバイスは、一時的な１２８ビットの疑似乱数（Ｎａ，Ｎｂ）を生成する（ステップ２ａ，２ｂ）。この疑似乱数値は、反復攻撃を避けるために利用される。また、この疑似乱数値は、ペアリングが形成される毎に新規に生成されなければならない。さらに、この疑似乱数値は、物理的な乱数発生源、又は物理的な発生源による乱数値をシードとする良い疑似乱数発生器から直接生成されるべきである。
【０１６９】
次いで、対向するデバイスは、双方の公開鍵に対応した証明書（Ｃａ，Ｃｂ）を算出する。この証明書は、一時的な疑似乱数を用いて生成されているため、それ自体が一時値である（ステップ３ｃ）。この証明書は、その証明書の算出に利用されるパラメータの入力に対して１方向性を有する関数（ｆ１）によって算出される。次いで、この証明書は、初期化デバイスに送信される（ステップ４）。尚、この証明書は、一時期間を経過した後で攻撃者によりパラメータが変更されるのを避けるために利用される。
【０１７０】
次いで、初期化デバイス、及び応答デバイスは、上記の一時値（疑似乱数値（Ｎａ，Ｎｂ））を交換する（ステップ５、６）。次いで、初期化デバイスは、その証明書が正しいか否かを確認する（ステップ６ａ）。ステップ６ａにおける確認の失敗は、攻撃者の存在、又は他の送信エラーが存在することを示すものである。もし、失敗したならば、このモデルにおけるペアリングの形成処理は破棄される。尚、これらのステップは、新たな鍵ペアが生成された際に、又は、新たな鍵ペアが生成されていなくても繰り返し実行されることがある。しかし、そうしたステップが繰り返されるならば、新たな一時値が生成されねばならない。
【０１７１】
さて、証明書のチェックが成功した場合、双方のデバイスは、６桁の数字（認証値（Ｖａ，Ｖｂ））をそれぞれ算出する。この認証値は、ユーザに提示されるために、各デバイスが備えるディスプレイ上に表示される（ステップ７ａ、７ｂ、８）。ユーザには、これらの６桁の認証値が一致しているか否か、或いは、一致しているものがあるか否かの確認が期待される。もし、一致しているものがないならば、その認証ステップは破棄される。さらに、その認証ステップが繰り返されるならば、新たな一時値が生成されねばならない。
【０１７２】
尚、狡猾な中間者によりサービス否認以外の任意の影響が及ばないように、認証プロセスにおいて自身のデバイスに関する鍵の情報が認証の際に利用される。単純な中間者攻撃であれば、０．９９９９９９の確率で異なる２組の６桁の表示値に帰着するであろう。より洗練された攻撃であれば、技術者に対し、表示値を一致させるように試みるかもしれないが、上記の認証処理シーケンスにより防ぐことができる。
【０１７３】
（２−２−２：認証ステージ１＜ＯＯＢモデル＞（図１８））
ＯＯＢモデルは、ＬＭＰ入出力機能の可否に関する情報を交換するシーケンスの中で、認証に利用されるセキュリティ情報が少なくとも一方のデバイスによって受信され、その中にＯＯＢ認証データ存在パラメータ（ＯＯＢ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｄａｔａ  Ｐｒｅｓｅｎｔ  ｐａｒａｍｅｔｅｒ）が含まれる場合に選択される。
【０１７４】
両方のデバイスがＯＯＢチャネルを介してデータを送信及び／又は受信できるならば、相互認証は、ＯＯＢ公開鍵（ＰＫａ，ＰＫｂ）に基づく証明書（Ｃａ，Ｃｂ）が認証ステージの中で交換されることにより実現されることになる。
【０１７５】
１．ＯＯＢ通信が１方向でのみ可能である場合（例えば、受動的なＮＦＣタグ等で構成されるデバイスを適用する場合、又は一方のデバイスが読み込み専用のものである場合）、ＯＯＢ通信における受信デバイスの認証は、ＯＯＢ通信を介して送信された乱数ｒを知っているデバイスにより実現される。このケースにおいて、乱数ｒは、秘密でなければならない。また、乱数ｒが毎回新たに生成されるか、或いは、乱数ｒを送信するデバイスへのアクセスが制限されていなければならない。もし、乱数ｒがデバイスに送られなかったならば、ステップ４ａ、４ｂの中でＯＯＢ情報（Ａ，Ｂ，ｒａ，ｒｂ，Ｃａ，Ｃｂ）を受信したデバイスにより、ｒが０であると設定される。
【０１７６】
もし、ＯＯＢ通信が堅牢なものであるならば（例えば、中間者攻撃を防御可能であるならば）、ＯＯＢモデルは、中間者攻撃による影響を受けにくいものであると言える。また、ＯＯＢモデルの中で、認証に利用されるパラメータ（Ｃａ、Ｃｂ、ｒａ、ｒｂ）のサイズは、ユーザが読み易いか、或いは、手入力し易いかということに配慮して制限されることがない。こうした理由により、ＯＯＢモデルは、数字比較モデル、又はパスキー入力モデルよりも、よりセキュアにすることができる。しかしながら、両方のデバイスが相互に対応するＯＯＢインターフェースを有することが必要となる。
【０１７７】
デバイスＡ、Ｂの役割：ＯＯＢモデルにおいて、デバイスＡとデバイスＢには、その役割に関して対称性がある。まず、デバイスＡがいつもペアリングを開始することは要求されない。例えば、一方のデバイスがＮＦＣタグを備え、ＯＯＢ情報の送信のみができる場合、ＯＯＢ通信の中で自動的に非対称性が解決される。
【０１７８】
しかしながら、ステップ１２（図１６（Ｂ））でリンクキー（ＬＫ）が計算される際、双方のデバイス群は、同じオーダー（秩序）のパラメータを入力しなければならない。但し、各デバイスにより異なる鍵が算出される。このオーダーとは、例えば、「デバイスＡ´のパラメータがピコネットマスターのパラメータであり、デバイスＢ´のパラメータがピコネットスレーブのパラメータである」といったものである。
【０１７９】
ステップの順序：公開鍵の交換は、認証処理のステップ（ステップ５）よりも以前に実行されなければならない。ダイアグラムの中で、デバイス間におけるＢＴバンド内での公開鍵の交換（ステップ１）は、ＯＯＢ通信（ステップ４）の以前に実行される。しかし、ＯＯＢインターフェースによりペアリングを開始しようとすると、公開鍵の交換はＯＯＢ通信の後になってしまう（ステップ１がステップ４とステップ５との間になろう）。
【０１８０】
ｒａ，ｒｂの値：ＯＯＢ通信が実行される以前には対向するデバイスのＯＯＢインターフェースの方向性が確認できないため、デバイスによりｒａ、ｒｂの値がいつも生成される。そして、可能ならば、ＯＯＢインターフェースを通じて対向するデバイスに乱数ｒが送信される。各デバイスは、自身のｒの値、及び対向するデバイスのｒの値をローカルで設定するために、次のようなルールを適用する。
【０１８１】
１．最初、デバイスのｒが乱数に設定され、対向するデバイスのｒが０に設定される（ステップ２）。
２．デバイスがＯＯＢで情報を受信したならば、対向するデバイスにより送信されたｒ値を設定する（ステップ５）。
３．デバイスがＯＯＢ認証データを受信したと示さなければ、自身のｒ値を０に設定する（ステップ５）。
【０１８２】
これらのルールにより、認証ステージ２でＯＯＢ通信が行われた際に、入力されたｒａ、ｒｂに関し、両方のデバイスＡ、Ｂが同じ値を持つことが確認される。
【０１８３】
（２−２−２−１：ＯＯＢ機構の一例であるＮＦＣ）
ＮＦＣ（Ｎｅａｒ  Ｆｉｅｌｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ；近接場通信）デバイスは、異なるデータレート（１０６ｋｂｐｓ、２１２ｋｂｐｓ、４２４ｋｂｐｓ）にそれぞれ対応するモードや、異なるオペレーション（有効／無効）に対応するモードをサポートしている。
【０１８４】
さらに、いくつかのＮＦＣデバイスは、初期化（初期化／リーダモード）の機能を有しており、接続（タグ／ターゲットモード）を許可する機能を有している。一方、他のデバイスは、接続を受け付ける能力のみを有している。例えば、ＯＯＢーＩＯ  ＮＦＣデバイスは、他のＮＦＣデバイスに対し、データを送信したり、データを受信したりする機能を有すると共に、ＢＴ通信するための機能を有している。
【０１８５】
ＯＯＢ機構に適用される場合、ＮＦＣデバイスに対して、デバイスＡ、Ｂが次の組み合わせとなるような３つのシナリオが想定されている。
（１）デバイスＡ：ＯＯＢ−ＩＯ  ＮＦＣデバイス、かつ、デバイスＢ：ＯＯＢ−Ｏ  ＮＦＣデバイスである場合、（２）デバイスＡ：ＯＯＢ−Ｏ  ＮＦＣデバイス、かつ、デバイスＢ：ＯＯＢ−ＩＯ  ＮＦＣデバイスである場合、（３）デバイスＡ：ＯＯＢ−ＩＯ  ＮＦＣデバイス、かつ、デバイスＢ：ＯＯＢ−ＩＯ  ＮＦＣデバイスである場合である（但し、ＯＯＢ−Ｏ：アウトプットのみ、ＯＯＢ−ＩＯ：インプット／アウトプット対応）。つまり、ＯＯＢ−Ｏ／ＯＯＢ−Ｏ（ｔａｇ／ｔａｇ）のケースが存在せず、一方のデバイスがリーダと成り得ることが求められる。
【０１８６】
（２−２−３：認証ステージ１＜パスキー入力モデル＞（図１９を参照））
パスキー入力モデルに関し、認証ステージ１におけるシーケンスダイアグラムについて説明する。
【０１８７】
ユーザにより両方のデバイスに個々のパスキーが入力される代わりに、パスキー（ｒａ，ｒｂ）が生成され、一方のデバイスに表示される。そして、ユーザは、表示されたパスキーを他方のデバイスに入力する（ステップ２）。この短い共有値（ｒａ，ｒｂ）により、デバイス間の相互認証が実現される。ステップ３〜８は、ｋビットのパスキーに対し、ｋ回繰り返される。例えば、６桁の数字に対するパスキー（９９９９９９＝０ｘＦ４２３Ｆ）は、ｋ＝２０である。
【０１８８】
ステップ３〜８において、各デバイスは、長い一時値（１２８ビット）を用いて、パスキーの各ビットを送る。さらに、一時値のハッシュ、パスキーのビット、及び他方のデバイスの公開鍵を送信する。
【０１８９】
次いで、各デバイスは、互いの証明書を確認すべく、パスキーが相互に開示されるまで返信する。与えられたパスキーのビットについて証明書を折り返す最初のデバイスは、そのプロセスの中でパスキーのビットを効果的に返信する。しかし、他のデバイスは、与えられたパスキーのビットと同じ値を示すビットの証明書を返信するか、或いは、パスキーのビットが更に返信されなかった場合に、この認証ステップが破棄される。
【０１９０】
この”漸次的な開示”は、中間者攻撃によりパスキーの情報が推測されないように１ビット以上の漏洩を避けるためのものである。パスキーの部分的な知識のみを有する中間者攻撃者は、この認証ステップが失敗する以前の不確かなパスキーの受信ビットしか推定できないことになる。ゆえに、０．０００００１の確率で成功する単純なＢｌｕｔｅ−ｆｏｒｃｅ攻撃者のような中間者攻撃者に対して、最大で２ビットの分の推測困難性を加えることができる。また、長い一時値には、認証ステップが失敗した後でさえも、ｂｒｕｔｅ−ｆｏｒｃｅ攻撃を困難にさせるための証明書のハッシュが含まれる。
【０１９１】
標準的な中間者攻撃はＥＣＤＨを交換する両サイドで攻撃者の公開鍵を置き換えることから、中間者攻撃を避けるために、オリジナルのＥＣＤＨ鍵の交換に際してパスキー入力モデルのセキュリティを厳しくするために公開Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ値が含まれる。このステージの最後において、認証ステージ２で利用されるＮａにＮａ２０が設定され、ＮｂにＮｂ２０が設定される。
【０１９２】
（２−３：フェーズ３＜認証ステージ２＞（図２０を参照））
認証ステージ２では両方のデバイスが認証情報の交換を成功裏に完了したことが確かめられる。このステージは、上記の３つのモデルにおいて共通である。
【０１９３】
まず、各デバイスは、新たに認証値（Ｅａ，Ｅｂ）を算出する。この認証値は、既に交換されたパラメータに基づいて算出される。また、この認証値は共有される（ステップ９）。次いで、初期化デバイスにより、対向する応答デバイスに認証値が送信される。次いで、送信された認証値は、応答デバイスにより確認される（ステップ１０）。もし、この確認が失敗であれば、初期化デバイスがペアリングを認証しなかったことが示される。その場合、この認証ステップが破棄される。
【０１９４】
次いで、応答デバイスは、自身が算出した認証値を初期化デバイスに送信する。この認証値は、初期化デバイスにより確認される（ステップ１１）。この確認が失敗であれば、応答デバイスがペアリングを認証しなかったことが示される。その場合、この認証ステップが破棄される。
【０１９５】
（２−４：フェーズ４：リンクキーの算出（図１６（Ｂ）を参照））
両方のサイドでペアリングが認証されると、共有鍵（ＤＨＫｅｙ）等によりリンクキー（ＬＫ）が算出され、このリンクキーを用いて公にデータが交換されるようになる（ステップ１２）。このとき利用される一時値は、リンクキーの新しさを示す。たとえ、長文のＥＣＤＨ値が両サイドで利用される場合であっても、このリンクキーは、ペアリングを管理するために利用される。
【０１９６】
リンクキーを算出する際に、両方のデバイスはパラメータを入力する。これらのパラメータは、両方のデバイスが同じリンクキーを算出したことを確かめるために、同じオーダー（順序）で入力される。また、パラメータには、「デバイスＡ´のパラメータはピコネットマスターのものであり、デバイスＢ´のパラメータはピコネットスレーブのものである」といったことを示す情報も含まれる。
【０１９７】
（２−５：フェーズ５：ＬＭＰ認証、及び暗号化）
シンプルペアリングの最終フェーズは、暗号鍵を生成することである。これは、従来のペアリングの最終ステップと同じように実行される。
【０１９８】
［３：暗号化に用いる関数群］
（３−１：楕円曲線の定義）
ＳＳＰ方式は、「ＦＩＰＳ（Ｆｅｄｅｒａｌ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  Ｓｔａｎｄａｒｄｓ  Ｐｕｂｌｉｃａｔｉｏｎ）  Ｐ−１９２  ｃｕｒｖｅ」の楕円曲線を暗号化に利用している。この楕円曲線Ｅは、下記の式（１）に示すようにパラメータｐ、ａ、ｂを引数として値が決定されるものである。
【０１９９】
【数１】
2010213334.tif 000003
【０２００】
但し、パラメータｂの値に対して一意に曲線が決定される。「ＮＩＳＴ（Ｎａｔｉｏｎａｌ  Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｓｔａｎｄａｒｄｓ  ａｎｄ  Ｔｅｃｈｎｏｌｏｇｙ）  Ｐ−１９２」において、パラメータａは下記の式（２）により定義されている。
【０２０１】
【数２】
2010213334.tif 000004
【０２０２】
一方、パラメータｂは定義されおり、その生成の方法はＳＨＡ−１（シード値ｓに対し、ｂ２ｓ＝−２７（ｍｏｄ  ｐ）を利用する。）を用いて確かめられる。また、次のようなパラメータが与えられる。
【０２０３】
主なパラメータは、第１の係数（絶対値）ｐ、オーダーｒ、基準となるｘ座標Ｇｘ、基準となるｙ座標Ｇｙである。また、整数ｐ、ｒは、１０進法の形式で与えられる。そして、ビット列、フィールド要素はｈｅｘ（１６進数）の形式で与えられる。これらのパラメータは、例えば、次のような数値（＃１〜＃５）で与えられる。
【０２０４】
（＃１）  ｐ＝６２７７１０１７３５３８６６８０７６３８３５７８９４２３２０７６６６４１６０８３９０８７００３９０３２４９６１２７９
（＃２）  ｒ＝６２７７１０１７３５３８６６８０７６３８３５７８９４２３１７６０５９０１３７６７１９４７７３１８２８４２２８４０８１
（＃３）  ｂ＝６４２１０５１９  ｅ５９ｃ８０ｅ７  ０ｆａ７ｅ９ａｂ  ７２２４３０４９  ｆｅｂ８ｄｅｅｃ  ｃ１４６ｂ９ｂ１
（＃４）  Ｇｘ＝１８８ｄａ８０ｅ  ｂ０３０９０ｆ６  ７ｃｂｆ２０ｅｂ  ４３ａ１８８００  ｆ４ｆｆ０ａｆｄ  ８２ｆｆ１０１２
（＃５）  Ｇｙ＝０７１９２ｂ９５  ｆｆｃ８ｄａ７８  ６３１０１１ｅｄ  ６ｂ２４ｃｄｄ５  ７３ｆ９７７ａ１  １ｅ７９４８１１
【０２０５】
関数Ｐ１９２（）は次のように定義されている。整数ｕ（０＜ｕ＜ｒ）、曲線Ｅ上の点Ｖが与えられると、点Ｖのｕ倍であるｕＶをｘ座標値とする値Ｐ１９２（ｕ，Ｖ）が算出される。秘密鍵は、１〜ｒ／２の間になる。ここで、ｒは、楕円曲線上のアーベル群のオーダーである（例えば、１〜２１９２／２）。
【０２０６】
（３−２：暗号化関数の定義）
楕円曲線Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵の算出に加え、数字比較モデル、ＯＯＢモデル、パスキー入力モデルの各プロトコルには、４つの暗号化関数が必要とされる。これらの関数は、後述する関数ｆ１，ｇ，ｆ２，ｆ３である。
【０２０７】
ｆ１は、１２８ビットの証明書の値Ｃａ、Ｃｂを生成するために利用される。ｇは、認証値を算出するために利用される。ｆ２は、リンクキー、及び、ＤＨＫｅｙや一時乱数値を用いて導出される他の鍵を算出するために利用される。ｆ３は、認証ステージ２における認証値Ｅａ、Ｅｂを算出するために利用される。これらの関数の基本的な構成はＳＨＡー２５６に基づいている。
【０２０８】
（３−２−１：ＳＳＰ方式における証明書生成関数ｆ１）
証明書は、関数ｆ１により算出される。ＳＳＰ方式の証明書用関数の定義は、ＳＨＡ−２５６に基づくＭＡＣ関数（ＨＭＡＣ）を用いている。このＨＭＡＣは１２８ビット鍵の場合に、ＨＭＡＣ−ＳＨＡ−２５６Ｘと表記されるものである。ＳＳＰ方式の関数ｆ１には、次のような形式のパラメータ（Ｕ，Ｖ，Ｘ，Ｚ）が入力される。
【０２０９】
Ｕは１９２ビット値である。Ｖは１９２ビット値である。Ｘは１２８ビット値である。Ｚは８ビット値である。
【０２１０】
Ｚは、数字比較モデル、及びＯＯＢモデルの各プロトコルにおいて０である（即ち、８ビットの０）。パスキー入力モデルのプロトコルの中で、Ｚの最も重要なビットは１に設定され、そして、少なくとも重要なビットはパスキーの１ビット目に生成される。例えば、パスキーが”１”である場合、Ｚ＝０ｘ８１に設定され、パスキーが”０”である場合、Ｚ＝０ｘ８０に設定される。
【０２１１】
ＳＳＰ方式の関数ｆ１の出力は、下記の式（３）のようになる。
【０２１２】
【数３】
2010213334.tif 000005
【０２１３】
関数ｆ１の入力は、下表２に示すようにプロトコルに依存して異なる。
【０２１４】
ここで、ＰＫａｘは、デバイスＡの公開鍵ＰＫａに対するｘ座標値を示す。同様に、ＰＫｂｘは、デバイスＢの公開鍵ＰＫｂに対するｘ座標値を示す。Ｎａｉは、ｉ番目の繰り返し処理における一時値を示す。繰り返し処理の各工程において、Ｎａｉの値は、あたらな１２８ビット数となる。同様に、ｒａｉは、８ビットに拡張されたパスキーの１ビット値（例えば、０ｘ８０、又は０ｘ８１）である。
【０２１５】
（３−２−２：ＳＳＰ方式における数値認証関数ｇ）
ＳＳＰ方式の関数ｇは、次のように定義される。ＳＳＰ方式の関数ｇの入力（Ｕ，Ｖ，Ｘ，Ｙ）の形式は次の通りである。
【０２１６】
Ｕは１９２ビット値である。Ｖは１９２ビット値である。Ｘは１２８ビット値である。Ｙは１２８ビット値である。
【０２１７】
ＳＳＰ方式の関数ｇの出力は、下記の式（４）のようになる。
【０２１８】
【数４】
2010213334.tif 000006
【０２１９】
数値認証値は、３２ビット整数ｇ（ＰＫａｘ，ＰＫｂｘ，Ｎａ，Ｎｂ）の中で、６つの少なくとも重要なビットが取り出される。ここで、ＰＫａｘはデバイスＡの公開鍵ＰＫａに対するｘ座標値を示し、ＰＫｂｘはデバイスＢの公開鍵ＰＫｂに対するｘ座標値を示す。
【０２２０】
ＳＨＡ−２５６の出力は、ＳＨＡ−２５６の出力に対応する少なくとも重要な３２ビットを取り出すことによって３２ビットに切りつめられる。この値は、１０進数形式の数値に変換される。数字比較モデルで利用されるチェックサムは、少なくとも重要な６桁である。比較結果（Ｃｏｍｐａｒｅ  Ｖａｌｕｅ）は、下記の式（５）のようになる。
【０２２１】
【数５】
2010213334.tif 000007
【０２２２】
例えば、出力が０ｘ  ０１  ２ｅ  ｂ７  ２ａであった場合、１０進数形式の数値は１９８３８７６２になる。そして、数字比較のためのチェックサムとして、８３８７６２が取り出される。
【０２２３】
（３−２−３：ＳＳＰ方式における鍵導出関数ｆ２）
ＳＳＰ方式の鍵導出関数には、ＳＨＡ−２５６に基づくＭＡＣ関数（ＨＭＡＣ）が用いられる。このＨＭＡＣは、１９２ビット鍵Ｗに対してＨＭＡＣ−ＳＨＡ−２５６Ｗと表現される。ＳＳＰ方式の関数ｆ２に対する入力（Ｗ，Ｎ１，Ｎ２，ＫｅｙＩＤ，Ａ１，Ａ２）の形式は次のようになる。
【０２２４】
Ｗは１９２ビット値である。Ｎ１は１２８ビット値である。Ｎ２は１２８ビット値である。ＫｅｙＩＤは３２ビット値である。Ａ１は４８ビット値である。Ａ２は４８ビット値である。
【０２２５】
文字列”ｂｔｌｋ”は拡張ＡＳＣＩＩコードにより、次のようにＫｅｙＩＤに対してマッピングされている。
【０２２６】
ＫｅｙＩＤ［０］＝０１１０  １０１１  （ｌｓｂ）
ＫｅｙＩＤ［１］＝０１１０  １１００
ＫｅｙＩＤ［２］＝０１１１  ０１００
ＫｅｙＩＤ［３］＝０１１０  ００１０
ＫｅｙＩＤ＝０ｘ６２７４６ｃ６ｂ
【０２２７】
ＳＳＰ方式の関数ｆ２の出力は、下記の式（６）のようになる。
【０２２８】
【数６】
2010213334.tif 000008
【０２２９】
関数ｆ２の出力としては、ＨＭＡＣ−ＳＨＡ−２５６の出力の中で、１２８の最も重要な（最左の）ビットが取り出される。また、リンクキーは、下記の式（７）により算出される。
【０２３０】
【数７】
2010213334.tif 000009
【０２３１】
（３−２−４：ＳＳＰ方式におけるチェックサム関数ｆ３）
ＳＳＰ方式のチェックサム関数ｆ３の定義には、ＳＨＡ−２５６に基づくＭＡＣ関数（ＨＭＡＣ）が用いられる。このＨＭＡＣは、１９２ビット鍵Ｗに対してＨＭＡＣ−ＳＨＡ−２５６Ｗと表現される。ＳＳＰ方式の関数ｆ３の入力（Ｗ，Ｎ１，Ｎ２，Ｒ，ＩＯｃａｐ，Ａ１，Ａ２）の形式は次の通りである。
【０２３２】
Ｗは１９２ビット値である。Ｎ１は１２８ビット値である。Ｎ２は１２８ビット値である。Ｒは１２８ビット値である。ＩＯｃａｐは１６ビット値である。Ａ１は４８ビット値である。Ａ２は４８ビット値である。
【０２３３】
ＩＯｃａｐは、ＬＭＰ  ＯＯＢ認証データとして最も重要なオクテット（８桁）、及びＬＭＰ入出力機能の可否を示す最小の重要度のオクテットで構成されるオクテットの組である。ＳＳＰ方式の関数ｆ３の出力は、下記の式（８）の通りである。
【０２３４】
【数８】
2010213334.tif 000010
【０２３５】
関数ｆ３の出力には、ＨＭＡＣ−ＳＨＡ−２５６の出力の中で１２８の最も重要な（最左の）ビットが取り出される。認証値は、関数ｆ３により算出される。関数ｆ３の入力は、下表３のように、プロトコル毎に異なる。
【０２３６】
ＤＨＫｅｙは、デバイスＡによりＰ１９２（ＳＫａ，ＰＫｂ）として、そして、デバイスＢによりＰ１９２（ＳＫｂ，ＰＫａ）として、算出された共有された秘密のＤｉｆｆｅ−Ｈｅｌｌｍａｎ鍵である。ＡデータはデバイスＡの機能を示すデータであり、ＢデータはデバイスＢの機能を示すデータである。パスキー入力モデルにおいて、データｒａ、ｒｂは６桁のパスキーの値であり、１２８ビットの整数値により表現される。例えば、ｒａの６桁の値が１３１３１３であったならば、Ｒ＝０ｘ００  ００  ００  ００  ００  ００  ００  ００  ００  ００  ００  ００  ００  ０２  ００  ｆ１となる。入力ＡはデバイスＡのＢＤアドレスである。入力ＢはデバイスＢのＢＤアドレスである。
【０２３７】
【表１】
2010213334.tif 000011
【０２３８】
【表２】
2010213334.tif 000012
【０２３９】
【表３】
2010213334.tif 000013
【０２４０】
［補遺２：＜ＷＰＳ１．０ｈについて＞］
上記の実施形態に係る技術は、以下で説明するＷＰＳ１．０ｈ方式に対し、好適に適用することが可能である。以下、ＷＰＳ１．０ｈ方式に係る認証方法について詳細に説明する。尚、ここで用いられる用語の意味、及び表現については、後段で示す表５〜表１０を参照されたい。
【０２４１】
［ＷＰＳ（Ｗｉ−Ｆｉ  Ｐｒｏｔｅｃｔｅｄ  Ｓｅｔｕｐ）について］
ＷＰＳは、Ｗｉ−Ｆｉ  Ａｌｌｉａｎｃｅにより独立に構築された１つの規格である。また、ＷＰＳは、Ｗｉ−Ｆｉ  ＣＥＲＴＩＦＩＥＤ（ＷＦＣ）の８０２．１１デバイスをサポートするようにデザインされている。このデバイスの形態としては、コンシューマ向けの電化プロダクトや電話機等が含まれる。これらのＷＦＣデバイスは、コンピュータ（ＰＣ）やアクセスポイント（ＡＰ）と同等の通信機能を有している。この通信機能は、家庭や小規模オフィス等に設置された８０２．１１デバイスにて利用されているようなものである。
【０２４２】
これらのデバイスには、８０２．１１ｂ、８０２．１１ａ、８０２．１１ｇを用いて通信するマルチバンドデバイスと同様の拡張機能を有しているものもある。こうした拡張機能は、ＷＦＣプログラムのオプションとして提供される。このオプションは、８０２．１１ｎ規格のプレ標準プロダクトに関するものである。このプレ標準プロダクトは、２００８年に予定している最終的な８０２．１１ｎの標準プロダクトに認定される予定にものである。尚、Ｗｉ−Ｆｉ  Ａｌｌｉａｎｃｅは、ＷＰＳに準拠した最初のプロダクトを２００７年の１月に承認している。
【０２４３】
ＷＰＳは、コンシューマに対し、Ｗｉ−Ｆｉネットワークの有効化する際に行うセキュリティ設定に関して、購入したＷＦＣデバイスがより簡単に設定されるものであることを確信させるためのものである。また、ＷＰＳにより、既に構築されたネットワークに対して新たなＷＰＳデバイスを追加する際にも、従来より遥かに容易に追加設定ができるようになるのである。
【０２４４】
尚、ＷＰＳは、オプション的な認証事項である。つまり、全てのプロダクトにその認証が与えられるわけではない。特に、ＳＯＨＯ市場における利用を想定しており、エンタープライズ環境における使用を目的にしたものではない。こうしたエンタープライズ環境では、分散して設置されたネットワークサーバ群がネットワークアクセスの制御用に設けられていたり、暗号化技術により厳重に情報が管理されていたりする。そこで、コンシューマは、購入するデバイスにＷＰＳ−ＷＦＣプロダクトの認定マークが存在するか否かを確認すればよい。このＷＰＳ認定マークは、プロダクト、パッケージ、ユーザドキュメントに表示されている。
【０２４５】
ＷＰＳは、典型的な家庭用ネットワークに適用される。その中で、デバイスは、アクセスポイント（ＡＰ）、又はルータを介して通信する。こうした通信環境では、”アドホック”ネットワークがサポートされていないことが多い。この”アドホック”ネットワークとは、各デバイスがＡＰから独立して直接的に他のデバイスと通信するネットワークである。
【０２４６】
典型的な通信環境では、ネットワーク上で、ネットワークネーム（ＳＳＩＤ）、及びＷＰＡ２セキュリティキーがＡＰ、及びＷＰＳクライアントデバイスに設定される。ＷＰＳの標準化されたアプローチによると、典型的なＷｉ−Ｆｉユーザにより簡単にＷｉ−Ｆｉネットワークが設定可能になり、セキュリティが有効化されたネットワークが構築できるようになる。このとき、Ｗｉ−Ｆｉユーザは、セキュリティやネットワークに関する基盤の技術、及び、その設定に含まれるプロセスについて理解していなくともよい。即ち、ユーザは、ＳＳＩＤがネットワークの名前を参照することや、ＷＰＡ２がセキュリティ機構を参照することを知る必要すらないのである。
【０２４７】
ＷＰＳはＷＰＡ２の個人向け技術を利用する。この技術は、レガシーデバイスとの互換性がある。ＷＰＡ／ＷＰＡ２  Ｐｅｒｓｏｎａｌに関してＷＦＣが認定を与えるのである。ＷＰＡとＷＰＡ２はＷｉ−Ｆｉ技術に関するセキュリティに関して最新のものである。ユーザは、レガシーデバイス（即ち、ＷＰＡ／ＷＰＡ２  Ｐｅｒｓｏｎａｌに関するＷＦＣでないデバイス）を利用することが、ＷＬＡＮが弱点を有する状態にあるということを認識しておかなければならない。２００３年９月以後に認定された全てのＷＦＣプロダクトは、ＷＰＡ又はＷＰＡ２のいずれかをサポートしている。つまり、２００６年３月以降に認定されるプロダクトには、ＷＰＡ２のサポートが要求されるのである。
【０２４８】
ＷＰＳで認定されたプロダクトでは、ユーザに２つの簡単な設定方法を提供している。個人識別数字（ＰＩＮ）による設定方法、及びプッシュボタン認証設定（ＰＢＣ）方法である。もちろん、ＷＰＳは、他の方法に対する拡張性も考慮してデザインされている。近接場通信（ＮＦＣ）カードやＵＳＢフラッシュデバイスを利用した認証方法についても、２００７年の後半にテストプログラムに追加されることが予定されている。
【０２４９】
尚、ユーザは、レガシーデバイスが含まれるＷｉーＦｉネットワークにＷＰＳーＷＦＣデバイスを加えるかもしれない。このネットワークは、デバイスの設計者により提供されるマニュアルの手順に従ってユーザが以前に構築したものである。
【０２５０】
ＷＰＳーＷＦＣプロダクトは、ＡＰにおいてＰＩＮによる認証設定、又はＰＢＣ設定の両方が可能なようにテストされてから認定される。クライアントデバイスでは、少なくとも、ＰＩＮによる認証設定がテストされてから認定される。
【０２５１】
レジスタラ（Ｒｅｇｉｓｔｒａｒ）は、新しいクライアントをネットワークに登録するのに必要な証明書を発行する。このレジスタラは、ＡＰ又はクライアント等の様々なデバイスに設定できる。ユーザが様々な環境や場所にデバイスを加えることができるように、仕様書では、１つのネットワーク内に多重のレジスタラが含まれることをサポートしている。但し、レジスタラの機能は、ＡＰの管轄内に限定される。
【０２５２】
ＰＩＮ設定に関し、ＰＩＮは、ネットワークに接続しようとする個々のデバイスに対して与えられる。通常、ユーザがＰＩＮを認識できるように、デバイス上に固定ラベルやステッカーが設けられている。また、動的なＰＩＮが生成される場合、そのＰＩＮは、例えば、デバイスに設置されたＴＶスクリーンやモニターのようなディスプレイに表示される。ＰＩＮは、他者による事故や悪意の企てによりネットワークに意図しないデバイスが加えられないように、ユーザがネットワークに加えようと考えるデバイスであるか否かを確かめるために利用される。
【０２５３】
まず、ユーザはＰＩＮをレジスタラに入力する。例えば、ＰＩＮは、ＡＰのＧＵＩを介して入力されるか、或いは、ネットワーク上の他のデバイスに設けられたオンスクリーンインターフェースを介して管理ページにアクセスすることにより入力される。
【０２５４】
ＰＢＣ設定に関し、ユーザは、デバイスをネットワークに接続し、ＡＰとクライアントデバイスのボタンを押下することによりデータの暗号化を有効にする。このとき、ユーザは、ＡＰとクライアントのボタンを押下する間に、意図しないデバイスがとても簡単にネットワークに接続することが可能な期間があることを意識しておく必要がある。
【０２５５】
（設定ステップの比較）
表４は、ＰＩＮによる認証設定とＰＢＣによる認証設定との間の操作ステップの比較を示した図表である。また、参考までに、ＷＰＳ以前の方法によるＷＬＡＮ上の設定、及びセキュリティの有効化に要求されるステップも併せて掲載している。これによると、ＷＰＳ以前の方法は多数のステップを有する。
【０２５６】
ＷＰＳ以前の方法において、ユーザは、デバイスを電源に接続し、有線ネットワークに接続した上でＡＰを有効化する（ステップ１）。次いで、ユーザは、有線ネットワークに接続されたコンピュータからウェブブラウザを立ち上げ、管理ページにログインしてＡＰにアクセスする（ステップ２）。次いで、ユーザは、ネットワークネーム（ＳＳＩＤ）を選択し、それをＡＰに入力する（ステップ３）。
【０２５７】
次いで、ユーザは、セキュリティ設定ページに導かれれる。そこで、ユーザは、利用するセキュリティタイプを選択し、セキュリティ設定を有効にする（ステップ４）。セキュリティ設定が有効化された後で、ユーザは、ＡＰがセキュリティキーを生成するために利用されるパスフレーズの入力を促される。そこで、ユーザは、パスフレーズをＡＰに設定し、セキュリティキーを設定する。（ステップ５）。ユーザは、コントロールパネルを用いてネットワークに登録されるクライアントデバイスを設定する。このとき、ユーザは、デバイスの無線インターフェースを有効化し、ＷＬＡＮ接続を有効化する（ステップ６）。
【０２５８】
次いで、クライアントデバイスは、ユーザに対し、周囲に発見される全てのＷＬＡＮのネットワークネーム（ＳＳＩＤ）を提示する。そこで、ユーザは、（ステップ３で選択した）適切なネットワークネームを選択し、ネットワークに接続する（ステップ７）。次いで、ユーザは、ステップ５で設定したパスフレーズを入力するように促される。そこで、ユーザは、クライアントデバイスにパスフレーズを入力する（ステップ８）。その後、クライアント、及びＡＰは、セキュリティ証明書を交換し、新たなデバイスがセキュアにＷＬＡＮに接続される。
【０２５９】
多くの場合、ＷＰＳを適用することにより、上記のステップ２〜５の手順が省略される。加えて、ユーザに要求されるいくつかの作業（例えば、パスフレーズの設定等）が簡単化される。
【０２６０】
ＷＰＳにおいて、ユーザは、単にＡＰとクライアントデバイスを有効化する。そして、ＡＰの生成手段により提供されたＰＩＮを入力するか（ＰＩＮによる認証設定の場合）、或いは、セキュリティの設定を開始するために、ＡＰとクライアントデバイスのボタンを押下する（ＰＢＣによる認証設定の場合）。このとき、ユーザには、パスフレーズの設定が要求されない。つまり、セキュリティコードが自動的に有効化されて通信されるのである。
【０２６１】
ＳＳＩＤとＷＰＡ２セキュリティキーが適切に設定されるのを保証するのに加え、ＷＰＳは、空間に伝播する情報セキュリティを確保するための技術を提供する。つまり、ＷＰＳは、ネットワークにアクセスするために不正なＰＩＮを入力するユーザを排除する。また、ＷＰＳには、認証に用いる証明書を一時的な証明書にすることで、その時点で転送されたものでないときに設定プロセスをキャンセルするタイムアウト機能も提供する。
【０２６２】
また、ＷＰＳでは、ユーザが生成したパスフレーズを消去することにより、セキュリティを向上させる。ＷＰＳ以前、ユーザは、ＡＰ上でパスフレーズを生成し、入力することを要求されていた。彼らは、任意の新たなデバイスをネットワークに追加する際に、ネットワークをセキュアにするためのパスフレーズを再利用していた。さらに、そのパスフレーズの多くは、短く、子供やペットの名前のような覚えやすく、外部の人に容易に推測されるような分かり易いパスフレーズであった。
【０２６３】
（ＷＰＳのオプション）
ＷＰＳのオプションとして、ＮＦＣやＵＳＢを利用した認証方法がある。これらの方法は、ＰＢＣによる認証方法やＰＩＮによる方法のようにユーザの手入力を要求せずにデバイスをネットワークに参加させるものである。
【０２６４】
ＷＰＳのＮＦＣによる設定方法を適用すると、新たなデバイスをＡＰ又はレジスタラ機能を有する他のデバイスにタッチすることで簡単にセキュアなネットワークが有効化される。ＷＰＳのＵＳＢによる設定方法では、証明書をＵＳＢフラッシュドライブ（ＵＦＤ）を介して転送する。これらの方法は、意図しないデバイスがネットワークに加入することに対して強固な防御効果を与える。
【０２６５】
しかしながら、ＵＳＢによる方法やＮＦＣによる方法は、２００７年の第１四半期後半でＷＦＳに対するＷＦＣプログラムに予定されている。他の方法についても、後日、認定プログラムに加えられるかもしれない。ＷＰＳは、こうした方法についても、他の技術に対する拡張性を考慮してデザインされている。
【０２６６】
（ＷＰＳの機能について）
詳細な設定手段とＷＰＳデバイスのセキュリティとは、従来のホームセキュリティに関する馴染み深い比喩”ｌｏｃｋ  ａｎｄ  ｋｅｙ”に対比される。ＷＰＳの仕様は、新たなデバイスが探索プロトコルに基づいて構築されたＷｉ−Ｆｉネットワークに加入される際に、シンプルで矛盾しない手順を提供している。また、このプロトコルは、ベンダー間で整合している。
【０２６７】
この手順では、ネットワークに登録されるデバイスの証明書を自動的に発行するためにレジスタラが利用される。ＷＰＳーＷＦＣデバイスのＡＰにはレジスタラ機能が搭載されている。さらに、レジスタラは、ＷＬＡＮ上の任意のデバイスに駐在することができる。ＡＰ上に駐在するレジスタラは、内部のレジスタラとして参照される。ネットワーク上の他のデバイスに駐在するレジスタラは、外部のレジスタラとして参照される。ＷＰＳネットワークでは、１つのＷＬＡＮ上における多重のレジスタラがサポートされている。
【０２６８】
ユーザがＷＬＡＮ上に新たなデバイスを追加設定するプロセスは、鍵を錠に挿入する工程と対比される次のようなアクションによって開始される。このプロセスでは、設定ウィザードが起動され、ＰＩＮが入力されるか、又はＰＢＣボタンが押下される。この時点で、アクセスが検出される。
【０２６９】
ＷＰＳデバイスは、レジスタラとの間で情報の交換を開始する。次いで、レジスタラは、ネットワーク証明書を発行する。ネットワーク証明書は、クライアントがＷＬＡＮに加入するのを認証するためのネットワークネーム、及びセキュリティキーを含むものである。錠と鍵の比喩において、このネットワーク証明書の交換は、アクセスが受け入れられるように錠の中でキーを回す動作に似ている。その後、新たなデバイスは、ネットワークを介し、侵入者による非認証アクセスに対してセキュアにデータを通信することができる。
【０２７０】
新たにＷＰＳ−ＷＦＣデバイスは、有効なＡＰの範囲内に入ったときに存在が検出される。その後、ＷＰＳ−ＷＦＣデバイスは、レジスタラに通信し、ユーザに証明書の発行を認証する行為を促す。
【０２７１】
ＷＰＳネットワークでは、各デバイスを認証する際にデータが暗号化される。つまり、情報とネットワーク証明書は、拡張認証プロトコル（ＥＡＰ）を利用して空間内でセキュアに交換される。認証プロトコルにはＷＰＡ２が使われる。デバイスにより相互に認証が実行され、クライアントがネットワーク上で許容された場合に接続が行われる。レジスタラは、セキュリティを有効にするためにネットワークネーム（ＳＳＩＤ）、及びＷＰＡ２の”Ｐｒｅ−Ｓｈａｒｅｄ  Ｋｅｙ（ＰＳＫ）”を通知する。ランダムなＰＳＫの使用は、予測可能なパスフレーズの使用を避けることでセキュリティが向上する。
【０２７２】
ＷＰＳ以前の設定方法では、ユーザに対し、ＡＰがＰＳＫをサポートするように手動で設定すること、及び、ＳＳＩＤとＰＳＫを手動で入力することが要求されていた。ＳＳＩＤやＰＳＫの入力は、ＡＰとクライアントの両方で行われる。このアプローチは、ユーザによるエラーの原因の大部分を占めていた。ユーザエラーとしては、ミスタイピング、及びＰＳＫとＳＳＩＤの混同である。ところが、ＷＰＳを用いた場合、証明書の交換プロセスは、初期の設定処理が完了した後において、ユーザによる僅かな介在を要求するのみである。例えば、ＰＩＮの入力、又はＰＢＣボタンの押下だけである。このとき、ネットワークネームとＰＳＫは自動的に発行されているのである。
【０２７３】
次に、証明書の交換、及びデバイスの追加に関するダイアグラムを示す。つまり、ＷＰＳデバイスにより、どのようにしてネットワークが設定されるかについて説明する。
【０２７４】
（証明書の交換について）
ＷＰＳでは、レジスタラデバイスがネットワーク上の他のデバイスに対して識別情報を発行するように促し、さらに、証明書を発行する。このとき、各種の情報は、Ｗｉ−Ｆｉネットワークを介して交換される。１つのシナリオとして、レジスタラがＡＰに設定される。証明書の交換は、クライアント、及びＡＰに設けられたボタンを押下することで行われてもよい（ＰＢＣ方式）。また、クライアントデバイスを用いたＰＩＮの入力により行われてもよい（ＰＩＮ方式）。例えば、ＰＩＮ入力は、ＰＩＮ方式用のＧＵＩにユーザがＰＩＮを入力する形式で行われる。
【０２７５】
（デバイスの追加について）
新たなクライアントが既に存在するネットワークに加えられるものとする。このとき、ＰＩＮ又はプッシュボタンにより設定されてもよい。例えば、既に存在するネットワークに新たなＡＰデバイスが加えられる場合にも、ＰＩＮ又はプッシュボタンによる設定が可能である。ＰＩＮ方式、及びＰＣＢ方式のいずれの方法が利用されるかは、どちらの設定方法がクライアントデバイスによりサポートされるかに依存して選択される。
【０２７６】
（ＷＰＳにおける設定オプション）
ＰＢＣ方式やＰＩＮ方式の設定オプションは、ＷＰＳーＷＦＣプロダクトに対して適用される。つまり、ＮＦＣやＵＳＢによる設定方法は、オプションであり、Ｗｉ−Ｆｉ  Ａｌｌｉａｎｃｅによりテスト及び認定されているものではない。しかしながら、製造者は、オプション的にこれらを提供することができる。ＮＦＣやＵＳＢによる設定方法は、２００７年のＷＰＳに対するＷＦＡの認定テストプログラムに含まれることが予定されている。
【０２７７】
（ＮＦＣ設定の場合）
ＮＦＣ設定は、タッチベースの相互作用を利用する。ＮＦＣ設定では、ＡＰ又は他のレジスタラデバイスとクライアントとの間でＮＦＣを利用してネットワーク証明書の交換を有効にする。証明書の交換は、ＮＦＣが有効なクライアントデバイスをＡＰ（又は他のＮＦＣが有効なレジスタラデバイス）上のＮＦＣターゲットマークにタッチした時点で開始されるか、或いは、クライアントをその近接領域内に持っていくことで開始される。その距離は、およそ１０ｃｍである。
【０２７８】
レジスタラは、クライアント識別用の証明書をＮＦＣを介して読み出す。ＮＦＣデバイスは、デバイスに埋め込まれている。そして、新たなデバイスをネットワークに接続するために、ネットワークＳＳＩＤとＰＳＫセキュリティコードをクライアントに返信する。
【０２７９】
（ＵＳＢ設定の場合）
ＵＳＢ設定において、ＵＳＢフラッシュドライブをレジスタラデバイス（この場合、ＡＰ）に接続することによって証明書が交換される。この証明書は、フラッシュドライブ上にコピーされる。一方、そのフラッシュドライブは、新たなデバイスに挿入されて証明書の交換が完了する。
【０２８０】
（ＷＰＳのまとめ）
ＷＰＳにより、ユーザに設定アプローチの統一的な枠組みが提供される。この枠組みには、ＰＩＮ入力やプッシュボタンのシーケンスが含まれる。このシーケンスは、新たなＷＦＣデバイスの設定をより容易にし、家庭又は小規模オフィスの環境においてＷＦＣネットワークのセキュリティを簡単に有効にすることができる。
【０２８１】
ＷＰＳは、ＷＦＣデバイスに対するユーザのアウトオブボックス操作を改善するようにデザインされており、ベンダーの技術サポートに対する依存性を低減し、小売店によるプロダクト回収の数を低減すると共に、ユーザの技術に対する満足度を増大させるものである。特に、ＷＰＳは、ユーザにＰＳＫやＳＳＩＤのようなコンセプトを理解させるような要求を排除し、誤入力が避けられないＰＳＫの手入力プロセスを排除することで、ネットワーク設定をより容易にする。
【０２８２】
ＷＰＳは、８０２．１１ａ，ｂ，ｇのＷＦＣデバイスがサポートする２．４ＧＨｚや５ＧＨｚ周波数帯の両方をサポートできるように拡張可能にデザインされている。認定自体はオプション的な位置付けであるが、家庭又は小規模オフィスに存在するマルチバンド、マルチモードをサポートするデバイスに適用されるであろう。また、このオプションは、２００７年の８０２．１１ｎのプレスタンダードプロダクトに対するＷＦＣプログラムへの適用が予定されている。また、２００８年に予定されている最終的な８０２．１１ｎ標準で認定されるプロダクトに対しても同様である。
【０２８３】
【表４】
2010213334.tif 000014
【０２８４】
【表５】
2010213334.tif 000015
【０２８５】
【表６】
2010213334.tif 000016
【０２８６】
【表７】
2010213334.tif 000017
【０２８７】
【表８】
2010213334.tif 000018
【０２８８】
【表９】
2010213334.tif 000019
【０２８９】
【表１０】
2010213334.tif 000020
【０２９０】
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【符号の説明】
【０２９１】
１００、２００    通信装置
１０２、１０６    アンテナ
１０４    近接通信部
１０８    近距離通信部
１１０    制御部
１１２    ＲＡＭ
１１４    ＲＯＭ
１１６    フラッシュメモリ
１１８    入力部
１２０    表示部
【図１】
2010213334.tif 000021
【図２】
2010213334.tif 000022
【図３】
2010213334.tif 000023
【図４】
2010213334.tif 000024
【図５】
2010213334.tif 000025
【図６】
2010213334.tif 000026
【図７】
2010213334.tif 000027
【図８】
2010213334.tif 000028
【図９】
2010213334.tif 000029
【図１０】
2010213334.tif 000030
【図１１】
2010213334.tif 000031
【図１２】
2010213334.tif 000032
【図１３】
2010213334.tif 000033
【図１４】
2010213334.tif 000034
【図１５】
2010213334.tif 000035
【図１６】
2010213334.tif 000036
【図１７】
2010213334.tif 000037
【図１８】
2010213334.tif 000038
【図１９】
2010213334.tif 000039
【図２０】
2010213334.tif 000040