(57)【要約】【課題】デバイスの認証済みの位置情報を取得することができるとともに、認証済みの位置情報を用いた様々なサービスを提供する。【解決手段】複数のデバイスからなるネットワークシステムが提供される。複数のデバイスの各々は、他のデバイスとデータ通信を行うための通信部と、自デバイスのＩＰアドレスを決定するための公開鍵を含む電子証明書を格納する記憶部と、他のデバイスから受信した電子証明書に含まれる公開鍵に基づいて、他のデバイスのＩＰアドレスを決定する決定部とを含む。電子証明書は、対応するデバイスに関連付けられた位置情報を含む。【選択図】図４
2020178279.tif 000002
【特許請求の範囲】
【請求項１】
複数のデバイスからなるネットワークシステムであって、
前記複数のデバイスの各々は、
他のデバイスとデータ通信を行うための通信部と、
自デバイスのＩＰアドレスを決定するための公開鍵を含む電子証明書を格納する記憶部と、
他のデバイスから受信した電子証明書に含まれる公開鍵に基づいて、前記他のデバイスのＩＰアドレスを決定する決定部とを備え、
前記電子証明書は、対応するデバイスに関連付けられた位置情報を含む、ネットワークシステム。
【請求項２】
前記位置情報は、ゾーンを階層的に分割することで生成されるいずれかのゾーンを示す、請求項１に記載のネットワークシステム。
【請求項３】
前記位置情報は、対象とするゾーンの階層構造を反映したコードからなる、請求項２に記載のネットワークシステム。
【請求項４】
前記複数のデバイスのうちいずれかのデバイスは、自デバイスに関連付けられた位置情報が示すゾーンより上位の階層のゾーンに関連付けられた他のデバイスに対して、自デバイスに設定されるべき位置情報を要求する、請求項２または３に記載のネットワークシステム。
【請求項５】
前記複数のデバイスのうちいずれかのデバイスからの要求に応答して、要求元に格納すべき電子証明書に署名する認証局をさらに備える、請求項１〜４のいずれか１項に記載のネットワークシステム。
【請求項６】
前記複数のデバイスのうちいずれかのデバイスは、他のデバイスとの間で電子証明書を交換してセッションを確立した後に、自デバイスにて生成または収集した情報を当該他のデバイスへ送信する、請求項１〜５のいずれか１項に記載のネットワークシステム。
【請求項７】
前記複数のデバイスのうち第１のデバイスは、
前記第１のデバイスに関連付けられたリソースを管理するように構成されており、
前記複数のデバイスのうち第２のデバイスからの要求に応答して、管理しているリソースの少なくとも一部を割り当てるように構成されており、
前記リソースの割り当てに係る情報は、前記第１のデバイスおよび前記第２のデバイス間で共有される、請求項１〜６のいずれか１項に記載のネットワークシステム。
【請求項８】
前記複数のデバイスのうちいずれかのデバイスは、他のデバイスからの現在位置の要求に応答して、当該現在位置に関連付けられたデバイスを特定するための特定情報を応答する、請求項１〜７のいずれか１項に記載のネットワークシステム。
【請求項９】
前記複数のデバイスのうちいずれかのデバイスは、商品やサービスに対する対価となる価値を管理する機能を備える、請求項１〜８のいずれか１項に記載のネットワークシステム。
【請求項１０】
ネットワークシステムを構成するデバイスであって、
他のデバイスとデータ通信を行うための通信部と、
自デバイスのＩＰアドレスを決定するための公開鍵を含む電子証明書を格納する記憶部と、
他のデバイスから受信した電子証明書に含まれる公開鍵に基づいて、前記他のデバイスのＩＰアドレスを決定する決定部とを備え、
前記電子証明書は、対応するデバイスに関連付けられた位置情報を含む、デバイス。
【請求項１１】
第１および第２のデバイスを含むネットワークシステムにおける処理方法であって、
前記第１のデバイスが、前記第１のデバイスのＩＰアドレスを決定するための第１の公開鍵を含む第１の電子証明書を第２のデバイスへ送信するステップと、
前記第２のデバイスが、前記第１のデバイスから受信した前記第１の電子証明書に含まれる前記第１の公開鍵に基づいて、前記第１のデバイスのＩＰアドレスを決定するステップと、
前記第２のデバイスが、前記第２のデバイスのＩＰアドレスを決定するための第２の公開鍵を含む第２の電子証明書を第１のデバイスへ送信するステップと、
前記第１のデバイスが、前記第２のデバイスから受信した前記第２の電子証明書に含まれる前記第２の公開鍵に基づいて、前記第２のデバイスのＩＰアドレスを決定するステップとを備え、
前記電子証明書は、対応するデバイスに関連付けられた位置情報を含む、処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、認証済みＩＰアドレスを有するデバイスからなるネットワークシステム、そのデバイスならびにネットワークシステムにおける処理方法に関する。
【背景技術】
【０００２】
近年の情報通信技術（Information and Communication Technology：ＩＣＴ）の進歩は目覚ましく、インターネットなどのネットワークに接続されるデバイスは、従来のパーソナルコンピュータやスマートフォンといった情報処理装置に限らず、様々なモノ（things）に広がっている。このような技術トレンドは、「ＩｏＴ（Internet of Things；モノのインターネット）」と称され、様々な技術およびサービスが提案および実用化されつつある。将来的には、地球上の数十億人と数百億または数兆のデバイスとが同時につながる世界が想定されている。このようなネットワーク化された世界を実現するためには、よりシンプル、より安全、より自由につながることができるソリューションを提供する必要がある。
【０００３】
このようなデバイスがどの位置にあるのかという情報は、各種サービスを提供する上で重要である。例えば、特表２０１２−５０４２８５号公報（特許文献１）は、インターネットに接続されたコンピュータ、モバイル装置、ウェブサイト訪問者またはその他の実際の地理的位置を識別する技術としてのジオロケーションを開示する。特に、特許文献１は、一般家庭顧客に割り当てられるＩＰ（Internet Protocol）アドレスが変わることに伴う位置情報の更新を支援する技術を開示する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特表２０１２−５０４２８５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上記特許文献１に開示されるように、デバイスに任意のＩＰアドレスを割り当てるというフレームワークに依存して、デバイスの位置情報を正しく決定することは難しかった。
【０００６】
本開示は、認証済みＩＰアドレスを用いるフレームワークを採用することで、このような課題を解決するとともに、位置情報を用いた様々なサービスを提供できる解決策を提供する。
【課題を解決するための手段】
【０００７】
本開示のある形態によれば、複数のデバイスからなるネットワークシステムが提供される。複数のデバイスの各々は、他のデバイスとデータ通信を行うための通信部と、自デバイスのＩＰアドレスを決定するための公開鍵を含む電子証明書を格納する記憶部と、他のデバイスから受信した電子証明書に含まれる公開鍵に基づいて、他のデバイスのＩＰアドレスを決定する決定部とを含む。電子証明書は、対応するデバイスに関連付けられた位置情報を含む。
【０００８】
位置情報は、ゾーンを階層的に分割することで生成されるいずれかのゾーンを示すものであってもよい。
【０００９】
位置情報は、対象とするゾーンの階層構造を反映したコードからなっていてもよい。
複数のデバイスのうちいずれかのデバイスは、自デバイスに関連付けられた位置情報が示すゾーンより上位の階層のゾーンに関連付けられた他のデバイスに対して、自デバイスに設定されるべき位置情報を要求するようにしてもよい。
【００１０】
ネットワークシステムは、複数のデバイスのうちいずれかのデバイスからの要求に応答して、要求元に格納すべき電子証明書に署名する認証局をさらに含んでいてもよい。
【００１１】
複数のデバイスのうちいずれかのデバイスは、他のデバイスとの間で電子証明書を交換してセッションを確立した後に、自デバイスにて生成または収集した情報を当該他のデバイスへ送信するようにしてもよい。
【００１２】
複数のデバイスのうち第１のデバイスは、第１のデバイスに関連付けられたリソースを管理するように構成されていてもよく、複数のデバイスのうち第２のデバイスからの要求に応答して、管理しているリソースの少なくとも一部を割り当てるように構成されていてもよい。リソースの割り当てに係る情報は、第１のデバイスおよび第２のデバイス間で共有されてもよい。
【００１３】
複数のデバイスのうちいずれかのデバイスは、他のデバイスからの現在位置の要求に応答して、当該現在位置に関連付けられたデバイスを特定するための特定情報を応答するようにしてもよい。
【００１４】
複数のデバイスのうちいずれかのデバイスは、商品やサービスに対する対価となる価値を管理する機能を含んでいてもよい。
【００１５】
本開示の別の形態に従えば、ネットワークシステムを構成するデバイスが提供される。デバイスは、他のデバイスとデータ通信を行うための通信部と、自デバイスのＩＰアドレスを決定するための公開鍵を含む電子証明書を格納する記憶部と、他のデバイスから受信した電子証明書に含まれる公開鍵に基づいて、他のデバイスのＩＰアドレスを決定する決定部とを含む。電子証明書は、対応するデバイスに関連付けられた位置情報を含む。
【００１６】
本開示のさらに別の形態に従えば、第１および第２のデバイスを含むネットワークシステムにおける処理方法が提供される。処理方法は、第１のデバイスが、第１のデバイスのＩＰアドレスを決定するための第１の公開鍵を含む第１の電子証明書を第２のデバイスへ送信するステップと、第２のデバイスが、第１のデバイスから受信した第１の電子証明書に含まれる第１の公開鍵に基づいて、第１のデバイスのＩＰアドレスを決定するステップと、第２のデバイスが、第２のデバイスのＩＰアドレスを決定するための第２の公開鍵を含む第２の電子証明書を第１のデバイスへ送信するステップと、第１のデバイスが、第２のデバイスから受信した第２の電子証明書に含まれる第２の公開鍵に基づいて、第２のデバイスのＩＰアドレスを決定するステップとを含む。電子証明書は、対応するデバイスに関連付けられた位置情報を含む。
【発明の効果】
【００１７】
本開示によれば、デバイスの認証済みの位置情報を取得することができるとともに、認証済みの位置情報を用いた様々なサービスを提供できる。
【図面の簡単な説明】
【００１８】
【図１】本実施の形態に従うネットワークシステムの全体構成の一例を示す模式図である。
【図２】本実施の形態に従うネットワークシステムに含まれるデバイスのハードウェア構成例を示す模式図である。
【図３】本実施の形態に従うネットワークシステムにおけるＩＰアドレスの認証処理例を説明するための図である。
【図４】本実施の形態に従うネットワークシステムにおいて用いられる電子証明書の一例を示す図である。
【図５】本実施の形態に従うネットワークシステムにおいて用いられるゾーンＩＤを説明するための模式図である。
【図６】本実施の形態に従うネットワークシステムにおいて用いられるゾーンＩＤのコード体系を説明するための模式図である。
【図７】本実施の形態に従うネットワークシステムにおけるゾーンＩＤの設定に係る処理を説明するための模式図である。
【図８】本実施の形態に従うネットワークシステムが提供する位置情報を利用したアプリケーションの一例を示す模式図である。
【図９】図８に示すアプリケーションを実現するための処理手順を示すシーケンス図である。
【図１０】本実施の形態に従うネットワークシステムが提供する位置情報を利用したアプリケーションの別の一例を示す模式図である。
【図１１】図１０に示すアプリケーションを実現するためのシステム構成例を示す模式図である。
【図１２】図１０に示すアプリケーションにおけるリソース管理を説明するための模式図である。
【図１３】図１０に示すアプリケーションにおいて用いられるチケット情報の一例を示す図である。
【図１４】図１０に示すアプリケーションを実現するための処理手順を示すシーケンス図である。
【図１５】本実施の形態に従うネットワークシステムが提供する位置情報を利用したアプリケーションのさらに別の一例を示す模式図である。
【図１６】図１５に示すアプリケーションを利用した経路選択を示す模式図である。
【図１７】図１５に示すアプリケーションを実現するための処理手順を示すシーケンス図である。
【発明を実施するための形態】
【００１９】
本開示に係る実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰り返さない。
【００２０】
＜Ａ．ネットワークシステム１の全体構成＞
まず、本実施の形態に従うネットワークシステム１の全体構成について説明する。ネットワークシステム１は、１または複数のデバイスの位置情報を管理および提供する機能を有している。
【００２１】
図１は、本実施の形態に従うネットワークシステム１の全体構成の一例を示す模式図である。図１を参照して、ネットワークシステム１は、複数のデバイス１０を含み、各デバイス１０は物理的な位置あるいは範囲に関連付けられている。各デバイス１０に関連付けられている位置あるいは範囲は、各デバイス１０が現実に存在している位置あるいは範囲であってよいし、各デバイス１０が管理あるいはサービスを提供する位置あるいは範囲であってよい。
【００２２】
図１に示す例においては、３つのゾーンＡ，Ｂ，Ｃに関連付けて、デバイス１０Ａ１，１０Ｂ１，１０Ｃ１が存在している。ゾーンＡには、さらにデバイス１０Ａ２，１０Ａ３，１０Ａ４が存在しており、ゾーンＢには、さらにデバイス１０Ｂ２，１０Ｂ３，１０Ｂ４，１０Ｂ５が存在しており、ゾーンＣには、さらにデバイス１０Ｃ２，１０Ｃ３，１０Ｃ４が存在している。なお、各デバイスを単に「デバイス１０」と総称することもある。
【００２３】
本実施の形態に従うネットワークシステム１においては、各デバイス１０に関連付けられた位置情報が決定および提供可能になっている。
【００２４】
各デバイス１０は、認証済みＩＰアドレスを有している。本明細書において、「認証済みＩＰアドレス」は、通信先あるいは第三者に対して、各デバイス１０が保持しているＩＰアドレスの正当性が保証されている状態を意味する。より具体的には、「認証済みＩＰアドレス」は、不可逆な暗号学的ハッシュ関数によって生成されるとともに、認証局２によって直接的または間接的に認証されたＩＰアドレスであることを意味する（詳細については後述する）。このような「認証済みＩＰアドレス」を用いることで、各デバイス１０がデータ通信に利用するＩＰアドレスが偽装されていないことを保証できる。
【００２５】
その結果、ネットワークシステム１に含まれる任意のデバイス１０は、各デバイス１０が有しているＩＰアドレスに基づいて一意に特定されることになる。すなわち、各デバイスは、各デバイスが有しているＩＰアドレス自体が識別情報となるので、各デバイス１０の識別情報（すなわち、ＩＰアドレス）に基づいて、位置情報および関連する情報の決定および提供が可能となる。
【００２６】
ＩＰアドレスは、インターネットに接続されたデバイス１０間のデータ通信にも用いることができるグローバルＩＰアドレスが想定されるが、特定のネットワーク内だけで利用されるプライベートＩＰアドレスであってもよい。ＩＰアドレスは、バージョンによって、アドレスを構成するビット数が異なっている。現在制定されているＩＰｖ４（Internet Protocol Version 4）においては、３２ビットのアドレス区間が規定されており、現在制定されているＩＰｖ６（Internet Protocol Version 6）においては、１２８ビットのアドレス区間が規定されている。本実施の形態においては、ＩＰｖ６に従うＩＰアドレスを主として説明する。但し、より多くのビット数で規定されるネットワークアドレス、あるいは、より少ないビット数で規定されるネットワークアドレスにも本開示は適用可能である。
【００２７】
本明細書において「デバイス」は、各々が有しているＩＰアドレスを用いて他のデバイスとデータ通信を行う機能を有している任意の装置を包含する。デバイス１０は、通信装置単体として構成されることもあるし、何らかのモノの一部として、あるいは、何らかのモノに組み込まれて構成されることもある。
【００２８】
より具体的には、デバイス１０は、例えば、パーソナルコンピュータ、スマートフォン、タブレット、ユーザの身体（例えば、腕や頭など）に装着されるウェアラブルデバイス（例えば、スマートウォッチやＡＲグラスなど）のいずれであってもよい。また、デバイス１０は、スマート家電、コネクティッド自動車、工場などに設置された制御機器あるいはその一部であってもよい。
【００２９】
ネットワークシステム１は、１または複数の認証局２をさらに含んでいてもよい。認証局２の各々は、１または複数のサーバで構成されるコンピュータであってもよい。１または複数の認証局２を用いて、各デバイス１０が有しているＩＰアドレスを認証するようにしてもよい。但し、認証局２が提供する機能の全部または一部をいずれかのデバイス１０が担当するようにしてもよい。
【００３０】
本実施の形態に従うネットワークシステム１においては、デバイス１０同士およびデバイス１０と認証局２との間は、任意の有線通信または無線通信を介してデータ通信可能に接続される。デバイス１０同士の通信およびデバイス１０と認証局２との通信には、一種のピアトゥピア（peer-to-peer）接続が用いられる。この通信には、ＴＣＰ（Transmission Control Protocol）およびＵＤＰ（User Datagram Protocol）を含む、任意のプロトコルを採用できる。
【００３１】
ネットワークに接続されたデバイス１０および認証局２の各々は、ネットワークの「ノード」とみなすことができ、以下の説明においては、デバイス１０および認証局２の各々を「ノード」と称することもある。
【００３２】
＜Ｂ．デバイス１０のハードウェア構成例＞
次に、本実施の形態に従うネットワークシステム１に含まれるデバイス１０のハードウェア構成例について説明する。
【００３３】
図２は、本実施の形態に従うネットワークシステム１に含まれるデバイス１０のハードウェア構成例を示す模式図である。図２を参照して、デバイス１０は、主たるコンポーネントとして、処理回路（processing circuitry）である制御部１１０とを含む。
【００３４】
制御部１１０は、本実施の形態に従う機能の提供および処理の実行を実現するための演算主体である。制御部１１０は、図２に示すようなプロセッサおよびメモリを用いて、メモリに格納されたコンピュータ可読命令（computer-readable instructions）をプロセッサが実行するように構成されてもよい。あるいは、コンピュータ可読命令に相当する回路が組み込まれたＡＳＩＣ（Application Specific Integrated Circuit）などのハードワイヤード回路を用いて制御部１１０を実現してもよい。さらにあるいは、ＦＰＧＡ（field-programmable gate array）上にコンピュータ可読命令に相当する回路を実現することで制御部１１０を実現してもよい。また、プロセッサおよびメモリ、ＡＳＩＣ、ＦＰＧＡなどを適宜組み合わせて制御部１１０を実現してもよい。
【００３５】
図２に示すようなプロセッサおよびメモリを用いた構成において、制御部１１０は、プロセッサ１０２と、主メモリ１０４と、ストレージ１０６と、ＲＯＭ（Read Only Memory）１０８とを含む。
【００３６】
プロセッサ１０２は、コンピュータ可読命令を順次読出して実行する演算回路である。プロセッサ１０２は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）などで構成される。複数のプロセッサ１０２を用いて制御部１１０を実現してもよいし（マルチプロセッサの構成）、複数のコアを有するプロセッサを用いて制御部１１０を実現してもよい（マルチコアの構成）。
【００３７】
主メモリ１０４は、ＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）などの揮発性記憶装置である。プロセッサ１０２は、ストレージ１０６またはＲＯＭ１０８に格納された各種プログラムのうち、指定されたプログラムを主メモリ１０４上に展開し、主メモリ１０４と協働することで、本実施の形態に従う各種処理を実現する。
【００３８】
ストレージ１０６は、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリなどの不揮発性記憶装置である。ストレージ１０６には、プロセッサ１０２で実行される各種プログラムや後述するような各種データが格納されている。
【００３９】
ＲＯＭ１０８は、プロセッサ１０２で実行される各種プログラムや後述するような各種データを固定的に格納する。
【００４０】
デバイス１０は、デバイス１０をネットワークに接続するためのネットワークインターフェイス１２０をさらに含む。ネットワークインターフェイス１２０は、ネットワークを介して他のデバイス１０とデータ通信を行うための通信部に相当する。
【００４１】
ネットワークインターフェイス１２０は、例えば、イーサネット（登録商標）ポート、ＵＳＢ（Universal Serial Bus）ポート、ＩＥＥＥ１３９４などのシリアルポート、レガシーなパラレルポートといった有線接続端子を含む。あるいは、ネットワークインターフェイス１２０は、デバイス、ルータ、移動体基地局などと無線通信するための処理回路およびアンテナなどを含んでもよい。ネットワークインターフェイス１２０が対応する無線通信は、例えば、Ｗｉ−Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）、ＬＰＷＡ（Low Power Wide Area）、ＧＳＭ（登録商標）、Ｗ−ＣＤＭＡ、ＣＤＭＡ２００、ＬＴＥ（Long Term Evolution）、第５世代移動通信システム（５Ｇ）のいずれであってもよい。
【００４２】
デバイス１０は、オプショナルなコンポーネントとして、内部インターフェイス１３０と、入力部１４０と、出力部１５０とを含んでいてもよい。
【００４３】
内部インターフェイス１３０は、デバイス１０が、何らかのモノの一部として、あるいは、何らかのモノに組み込まれて構成されるときに、対象のモノとの間でデータ通信を行う。内部インターフェイス１３０は、例えば、ＵＳＢ（Universal Serial Bus）ポート、ＩＥＥＥ１３９４などのシリアルポート、レガシーなパラレルポートといった有線接続端子を含む。あるいは、内部インターフェイス１３０は、アナログ／デジタル変換回路などの電気信号を取り込むような回路を含んでいてもよい。
【００４４】
入力部１４０は、デバイス１０を操作するユーザの入力操作を受け付けるためのコンポーネントである。入力部１４０は、例えば、キーボード、マウス、表示デバイス上に配置されたタッチパネル、デバイス１０の筐体に配置された操作ボタンなどであってもよい。
【００４５】
出力部１５０は、プロセッサ１０２での処理結果などを外部へ提示するためのコンポーネントである。出力部１５０は、例えば、ＬＣＤ（Liquid Crystal Display）や有機ＥＬ（Electro-Luminescence)ディスプレイなどであってもよい。また、出力部１５０は、ユーザの頭部に装着されるヘッドマウントディスプレイであってもよいし、画像をスクリーン上に投影するプロジェクターであってもよい。あるいは、出力部１５０は、デバイス１０の筐体に配置されたインジケータなどであってもよい。
【００４６】
入力部１４０および出力部１５０は、オプショナルなコンポーネントであるため、例えば、ＵＳＢなどの任意のインターフェイスを介してデバイス１０の外部から接続されるようにしてもよい。
【００４７】
デバイス１０は、各種プログラム（コンピュータ可読命令）および／または各種データが格納された非一過性（non-transitory）のメディアから各種プログラムおよび／または各種データを読み出すためのコンポーネントをさらに有していてもよい。メディアは、例えば、ＤＶＤ（Digital Versatile Disc）などの光学メディア、ＵＳＢメモリなどの半導体メディアなどであってもよい。
【００４８】
なお、メディアを介して各種プログラムおよび／または各種データをデバイス１０にインストールするのではなく、ネットワーク上の配信サーバから必要なプログラムおよびデータをデバイス１０にインストールするようにしてもよい。この場合には、ネットワークインターフェイス１２０を介して、必要なプログラムおよびデータが取得される。
【００４９】
本実施の形態に従う機能の提供および処理の実行を実現するのは制御部１１０であり、本願の技術的範囲は、少なくとも、制御部１１０を実現するためのハードウェアおよび／またはソフトウェアを包含する。ハードウェアは、上述したように、プロセッサおよびメモリからなる構成だけではなく、ＡＳＩＣなどを用いたハードワイヤード回路やＦＰＧＡを用いた構成を含み得る。すなわち、制御部１１０は、汎用コンピュータにプログラムをインストールすることで実現され得るし、専用のチップとして実現することもできる。
【００５０】
また、プロセッサで実行されるソフトウェアは、メディアを介して流通するものだけではなく、配信サーバを介して適宜ダウンロードされるものも含み得る。
【００５１】
なお、本実施の形態に従う機能の提供および処理の実行を実現するための構成は、図２に示す制御部１１０に限られず、実現される時代に応じた任意の技術を用いて実装できる。
【００５２】
＜Ｃ．認証済みＩＰアドレス＞
次に、本実施の形態に従うネットワークシステム１における認証済みＩＰアドレスの実現方法の一例について説明する。
【００５３】
本実施の形態に従うネットワークシステム１においては、一例として、公開鍵暗号基盤（ＰＫＩ：public key infrastructure）を用いて、各デバイス１０のＩＰアドレスを認証する。
【００５４】
図３は、本実施の形態に従うネットワークシステム１におけるＩＰアドレスの認証処理例を説明するための図である。図３を参照して、デバイス１０は、秘密鍵１６０および公開鍵１６２からなる鍵ペアを有している。予め定められたハッシュ関数１６４に公開鍵１６２を入力することでハッシュ値１６６を算出し、その算出されたハッシュ値１６６の全部または一部がデバイス１０のＩＰアドレス１６８として用いられる。
【００５５】
デバイス１０間で予め定められたハッシュ関数１６４を共有しておくことで、他のデバイス１０から取得した公開鍵１６２に基づいて、当該公開鍵１６２の送信元であるデバイス１０のＩＰアドレス１６８を一意に決定できる。公開鍵１６２は、電子証明書１７０とともに、あるいは、電子証明書１７０に組み込まれて送信されるようになっており、電子証明書１７０に基づいて公開鍵１６２（すなわち、決定されるＩＰアドレス１６８の正当性）を確保できる。すなわち、各デバイス１０は、デバイス１０間で予め定められたハッシュ関数１６４を共有しておくことで、他のデバイス１０から受信した電子証明書１７０に含まれる公開鍵１６２に基づいて、当該他のデバイスのＩＰアドレスを決定するロジックを有している。
【００５６】
このように、本実施の形態に従うネットワークシステム１においては、ＩＰアドレス１６８自体を認証することができ、このような認証済みＩＰアドレス１６８をデバイス自体が保持することで、各デバイスに静的または動的に割り当てられたＩＰアドレスを用いることなく、自立的なネットワークを構築できる。
【００５７】
鍵ペアである秘密鍵１６０および公開鍵１６２は、デバイス１０自身が作成してもよいし、外部から提供されて予めデバイス１０に格納されていてもよい。外部から提供される場合には、デバイス１０は秘密鍵１６０のみを取得し、公開鍵１６２については自身で生成するようにしてもよい。
【００５８】
鍵ペアである公開鍵１６２の生成方法の一例としては、乱数発生器が発生する所定長さのビット列（例えば、５１２ビット）を秘密鍵１６０として用いるとともに、公知の暗号アルゴリズム（例えば、楕円曲線暗号アルゴリズム）に従って秘密鍵１６０から所定長さのビット列（例えば、２５６ビット）からなる公開鍵１６２を生成してもよい。なお、デバイス１０自身が鍵ペアを生成する場合には、乱数発生器は、ＯＳが提供する機能を利用して実現してもよいし、ＡＳＩＣなどのハードワイヤード回路を用いて実現してもよい。
【００５９】
ハッシュ関数１６４は、公知の不可逆な暗号学的ハッシュ関数（例えば、ＢＬＡＫＥ）を用いることができる。ハッシュ関数１６４は、所定長さのビット列（例えば、２５６ビット）からなるハッシュ値１６６を算出する。
【００６０】
ハッシュ関数１６４には、公開鍵１６２だけではなく、任意のキーワードを入力するようにしてもよい。任意のキーワードとして、所定の組織に関連付けられたメッセージを用いてもよい。所定の組織に関連付けられたメッセージとして、当該所定の組織が有している商標の名称を含むメッセージを用いてもよい。例えば、所定の組織が保有する登録された商標の名称（例えば、「ｃｏｎｎｅｃｔＦｒｅｅ」）をハッシュ関数１６４に入力するキーワードとして用いるようにしてもよい。このような実装方式を採用することで、所定の組織以外の第三者が、当該所定の組織の許諾なしに本実施の形態に従うネットワークシステム１および関連する方法やプログラムなどを実施することを防止できる。
【００６１】
ハッシュ関数１６４により算出されるハッシュ値１６６の全部または一部がＩＰアドレス１６８として用いられる。例えば、２５６ビット（１６進数表現で６４桁）のハッシュ値１６６が算出される場合には、６４桁のハッシュ値１６６のうち任意の３２桁（例えば、前半３２桁）をＩＰｖ６に対応するＩＰアドレス１６８（１２８ビット）として決定してもよい。あるいは、６４桁のハッシュ値１６６のうち前半８桁をＩＰｖ４に対応するＩＰアドレス１６８（３２ビット）として決定してもよい。
【００６２】
あるいは、ＩＰｖ６に対応するＩＰアドレス１６８（１２８ビット）を考慮して、ハッシュ関数１６４から１２８ビットのハッシュ値１６６を算出するようにしてもよい。この場合には、算出されるハッシュ値１６６の全部をＩＰｖ６に対応するＩＰアドレス１６８（１２８ビット）として決定できる。
【００６３】
なお、決定されるＩＰアドレスには、予め定められた特定用の固有値（固有文字列）を含めるようにしてもよい。
【００６４】
一例として、１６進数表現のＩＰアドレス１６８の先頭２桁（先頭から１桁目および２桁目）を予め定められた固有文字列（例えば、「ＦＣ」）に固定してもよい。別の一例として、１６進数表現のＩＰアドレス１６８の先頭から３桁目および４桁目にデバイス１０の種類を示す値（種類特定情報）を埋め込んでもよい。
【００６５】
通常、ハッシュ関数１６４は一方向性関数であるので、ＩＰアドレス１６８から公開鍵１６２を逆算することはできない。そのため、決定されるＩＰアドレス１６８が所定条件（この場合には、先頭４桁の全部または一部が予め定められた値になること）を満たすまで、乱数発生器を用いて、秘密鍵１６０および公開鍵１６２を繰り返し生成してもよい。
【００６６】
このように、ＩＰアドレス１６８に予め定められた特定用の固有値（例えば、先頭２桁が「ＦＣ」）を含めることで、第三者は、デバイス１０のＩＰアドレス１６８がデバイス１０自身によって決定されたものであるか否かを判断できる。また、ＩＰアドレス１６８にデバイス１０の種類を示す値を含めることで、第三者は、決定されたＩＰアドレス１６８から当該デバイス１０の種類を特定できる。
【００６７】
図４は、本実施の形態に従うネットワークシステム１において用いられる電子証明書１７０の一例を示す図である。各デバイス１０は、図４に示すような電子証明書１７０を保持しており、必要に応じて他のデバイス１０へ送信する。電子証明書１７０は、典型的には、デバイス１０のストレージ１０６またはＲＯＭ１０８（図２参照）に格納される。すなわち、デバイス１０のストレージ１０６またはＲＯＭ１０８は、電子証明書１７０を格納する記憶部に相当する。
【００６８】
図４に示すような電子証明書１７０は、認証局２により予め作成されて各デバイス１０に提供されてもよいし、各デバイス１０が自身で作成してもよい（但し、認証局署名は、デバイス１０自身の署名となる）。認証局２が電子証明書１７０を発行する場合には、デバイス１０は、自デバイス１０が有している公開鍵１６２とともに、認証局２に対して電子証明書の発行要求（以下、「証明書署名要求」とも称す。）を送信する。認証局２は、デバイス１０から受信した証明書署名要求に応答して、公開鍵１６２を登録するとともに、所定のアルゴリズムに従って生成された認証局署名１７８を含む電子証明書１７０を発行する。すなわち、認証局２は、いずれかのデバイスからの証明書署名要求に応答して、要求元に格納すべき電子証明書１７０に署名する。
【００６９】
図４には、一例として、Ｘ．５０９ｖ３証明書フォーマットに従う電子証明書１７０を示す。より具体的には、図４を参照して、各デバイス１０が保持する電子証明書１７０は、バージョン情報１７１と、シリアル番号１７２と、署名アルゴリズム１７３と、発行者識別名１７４と、有効期間１７５と、主体者識別名１７６と、公開鍵１６２と、認証局署名１７８と、拡張情報１８０とを含む。
【００７０】
バージョン情報１７１は、証明書フォーマットのバージョン情報を示す。シリアル番号１７２は、電子証明書１７０の発行主体（認証局２またはデバイス１０）における通し番号を示す。署名アルゴリズム１７３は、電子証明書１７０に含まれる認証局署名１７８の生成に用いられたアルゴリズムを示す。発行者識別名１７４は、電子証明書１７０の発行主体（認証局２またはデバイス１０）を特定するための情報を示す。有効期間１７５は、電子証明書１７０の有効期間を示す。主体者識別名１７６は、電子証明書１７０の発行対象者（通常は、電子証明書１７０を保持しているデバイス１０）を特定するための情報を示す。公開鍵１６２は、電子証明書１７０を保持しているデバイス１０が有している公開鍵１６２であり、自デバイスのＩＰアドレスを決定するために用いられる。
【００７１】
認証局署名１７８は、認証局２により生成された署名（ハッシュ値）である。
拡張情報１８０は、任意の情報を含ませることができる。本実施の形態に従うネットワークシステム１においては、各デバイス１０に関連付けられた位置情報を示すゾーンＩＤ１８２（詳細については後述する）を含む。ゾーンＩＤ１８２は、電子証明書１７０が格納されるデバイス（すなわち、ゾーンＩＤ１８２に対応するデバイス）に関連付けられた位置情報を含む。電子証明書１７０に含まれるゾーンＩＤ１８２を参照することで、各デバイス１０が存在している位置あるいは範囲などを容易に特定できる。
【００７２】
＜Ｄ．ゾーンＩＤ＞
次に、本実施の形態に従うネットワークシステム１において利用されるゾーンＩＤの詳細について説明する。
【００７３】
（ｄ１：ゾーンＩＤの決定および体系）
図５は、本実施の形態に従うネットワークシステム１において用いられるゾーンＩＤを説明するための模式図である。図５を参照して、本実施の形態においては、要求に応じて階層的に範囲を分割する。図５には、四分木空間分割を用いた例を示すが、これに限らず任意の分割手法を用いることができる。
【００７４】
より具体的には、ゾーンＩＤを設定可能なゾーンがＡ〜Ｄの４つに分割されている。すなわち、図５において最上位のゾーンＩＤは、「Ａ」，「Ｂ」，「Ｃ」，「Ｄ」となる。
【００７５】
分割された各ゾーンをさらに４分割することができる。図５に示す例においては、ゾーンＩＤが「Ａ」のゾーンがさらに４つに分割されている。各分割されたゾーンのゾーンＩＤは、「ＡＡ」，「ＡＢ」，「ＡＣ」，「ＡＤ」である。
【００７６】
ゾーンＩＤが「ＡＡ」のゾーンはさらに４つに分割されている。各分割されたゾーンのゾーンＩＤは、「ＡＡＡ」，「ＡＡＢ」，「ＡＡＣ」，「ＡＡＤ」である。ゾーンＩＤが「ＡＢ」および「ＡＣ」のゾーンについても同様に、それぞれ４分割されている。すなわち、ゾーンＩＤが「ＡＢ」のゾーンを４分割して得られたゾーンのゾーンＩＤは、「ＡＢＡ」，「ＡＢＢ」，「ＡＢＣ」，「ＡＢＤ」であり、ゾーンＩＤが「ＡＣ」のゾーンを４分割して得られたゾーンのゾーンＩＤは、「ＡＣＡ」，「ＡＣＢ」，「ＡＣＣ」，「ＡＣＤ」である。
【００７７】
ゾーンＩＤが「Ｄ」のゾーンについても同様に４つに分割されており、分割された一部のゾーンはさらに４分割されている。
【００７８】
このように、対象のゾーンの全部または一部を４分割する操作を、必要な粒度まで繰り返すことで、位置情報を決定できる。すなわち、決定される位置情報は、ゾーンを階層的に分割することで生成されるいずれかのゾーンを示すことになる。
【００７９】
図６は、本実施の形態に従うネットワークシステム１において用いられるゾーンＩＤのコード体系を説明するための模式図である。図６に示すコード体系の一例は、図５に示すゾーン分割に対応するものとなっている。
【００８０】
図６を参照して、第１階層には、ゾーンＩＤとして「Ａ」，「Ｂ」，「Ｃ」，「Ｄ」の４つが割り当てられる。第２階層には、対応する第１階層のゾーンＩＤの全体にさらに識別のための文字が付加されたゾーンＩＤが用いられる。例えば、ゾーンＩＤが「Ａ」を分割して得られる４つのゾーンには、「Ａ」の後に識別のための文字としてそれぞれ「Ａ」，「Ｂ」，「Ｃ」，「Ｄ」が付加された、「ＡＡ」，「ＡＢ」，「ＡＣ」，「ＡＤ」が用いられる。
【００８１】
同様に、第３階層には、対応する第２階層のゾーンＩＤの全体にさらに識別のための文字が付加されたゾーンＩＤが用いられる。例えば、ゾーンＩＤが「ＡＡ」を分割して得られる４つのゾーンには、「ＡＡ」の後に識別のための文字としてそれぞれ「Ａ」，「Ｂ」，「Ｃ」，「Ｄ」が付加された、「ＡＡＡ」，「ＡＡＢ」，「ＡＡＣ」，「ＡＡＤ」が用いられる。
【００８２】
以下、より深い階層になった場合でも同様の規則に従ってゾーンＩＤが決定される。このように、位置情報であるゾーンＩＤは、対象とするゾーンの階層構造を反映したコードから構成される。本実施の形態に従うネットワークシステム１においては、上位の階層のゾーンＩＤをすべて含むゾーンＩＤが用いられるので、任意のゾーンＩＤについて、その上位に存在するゾーンＩＤを一意に特定できる。例えば、ゾーンＩＤとして「ＡＡＡ」が付加されたゾーンは、ゾーンＩＤとして「ＡＡ」が付加されたゾーンの部分領域であると判断でき、さらにゾーンＩＤとして「Ａ」が付加されたゾーンの部分領域であるとも判断できる。
【００８３】
図５および図６においては、説明の便宜上、階層が深くなる毎に英文字１文字が追加される例を示すが、これに限らず、予め定められた規則に従って、任意の長さの識別情報（文字や数字など）が順次追加されるように構成すればよい。
【００８４】
図５および図６においては、説明の便宜上、４つに分割された状態を最上位の階層（第１階層）としたが、最上位の階層については任意の数のゾーンとしてもよい。さらに、第２階層以下についても、分割数を４に限定する必要はなく、任意の数に順次分割することができる。
【００８５】
図５においては、説明の便宜上、方形状のゾーンを順次分割する例を示すが、これは論理的な表現に過ぎず、適用されるアプリケーションに応じて、任意の単位を各階層のゾーンに設定できる。すなわち、図５に示す「ゾーン」は、必ずしも物理的な範囲に限定されるのではなく、人為的に取り決められた規則に従って規定されるゾーンの区分を含み得る。例えば、「ゾーン」の階層を人為的に取り決められた住所表記（例えば、「都道府県」，「市町村」，「町」，「番地」，「部屋番号」など）に対応付けてもよい。さらに、図５に示す「ゾーン」の分割数および分割階層は何ら制限されることはない。例えば、ファースト店の住所に対応するゾーンＩＤをさらに分割して、座席毎にゾーンＩＤを割り当ててもよい。
【００８６】
通信可能な各デバイス１０からゾーンＩＤを取得して地図上のマッピングすることで、各デバイス１０が存在している位置を具現化することもできる。
【００８７】
（ｄ２：ゾーンＩＤの設定および更新）
次に、各デバイス１０へのゾーンＩＤの設定および更新に係る処理例について説明する。各デバイス１０に対して、予め定められたゾーンＩＤを設定し、当該設定されたゾーンＩＤを含む電子証明書１７０を認証局２から発行するようにしてもよい。あるいは、ネットワークシステム１にデバイス１０を接続した後に、ネットワーク上の接続関係に基づいて、接続したデバイス１０に対してゾーンＩＤを設定するようにしてもよい。以下、ネットワーク上の接続関係に基づくゾーンＩＤの設定および電子証明書１７０の発行などの処理例について説明する。
【００８８】
図７は、本実施の形態に従うネットワークシステム１におけるゾーンＩＤの設定に係る処理を説明するための模式図である。図７には、デバイス１０Ａ２（図１参照）がゾーンＡに関連付けられたデバイス１０Ａ１のネットワークに接続された場合の処理例を示す。
【００８９】
図７（Ａ）には、デバイス１０Ａ２が同一ネットワークに接続されているデバイス１０Ａ１にゾーンＩＤの割り当てを依頼する例を示す。図７（Ａ）に示す例では、デバイス１０Ａ２がデバイス１０Ａ１に対してゾーンＩＤを要求する（（１）ゾーンＩＤ要求）。デバイス１０Ａ１は、ゾーンＩＤ要求に応答して、自デバイスに割り当てられているゾーンＩＤにさらに識別情報を付加してゾーンＩＤを決定し、デバイス１０Ａ２に応答する（（２）ゾーンＩＤ）。そして、デバイス１０Ａ２は、デバイス１０Ａ１から割り当てられたゾーンＩＤおよび自デバイスの公開鍵１６２を含む証明書署名要求を認証局２へ送信する（（３）証明書署名要求）。認証局２は、証明書署名要求に応答して、デバイス１０Ａ２に対する電子証明書１７０を生成し、デバイス１０Ａ２へ送信する（（４）電子証明書）。デバイス１０Ａ２は、認証局２からの電子証明書１７０を格納し、他のデバイスとのデータ通信に利用する。
【００９０】
このように、下位の階層のデバイス１０は、自デバイスに関連付けられたゾーンＩＤ（位置情報）が示すゾーンより上位の階層のゾーンに関連付けられた他のデバイスに対して、自デバイスに設定されるべき位置情報を要求する。
【００９１】
図７（Ｂ）には、デバイス１０Ａ２からの要求が同一ネットワークに接続されているデバイス１０Ａ２に電子証明書１７０の発行を依頼する例を示す。図７（Ｂ）に示す例では、デバイス１０Ａ２がデバイス１０Ａ１に対して電子証明書１７０の発行を要求する（（１）証明書発行要求）。この電子証明書１７０の発行要求には、デバイス１０Ａ２の公開鍵１６２が含まれる。デバイス１０Ａ１は、電子証明書１７０の発行要求に応答して、自デバイスに割り当てられているゾーンＩＤにさらに識別情報を付加して、デバイス１０Ａ２のゾーンＩＤを決定する（（２）ゾーンＩＤ決定）。そして、デバイス１０Ａ２は、デバイス１０Ａ１に対して決定したゾーンＩＤおよびデバイス１０Ａ２の公開鍵１６２を含む証明書署名要求を認証局２へ送信する（（３）証明書署名要求）。認証局２は、証明書署名要求に応答して、デバイス１０Ａ２に対する電子証明書１７０を生成してデバイス１０Ａ１へ送信し、デバイス１０Ａ１を中継してデバイス１０Ａ２へ届けられる（（４）電子証明書）。デバイス１０Ａ２は、認証局２からの電子証明書１７０を格納し、他のデバイスとのデータ通信に利用する。
【００９２】
図７に示すゾーンＩＤの設定に係る処理は一例でありどのような設定方法を採用してもよい。なお、デバイス１０が別のネットワークに接続した場合には、図７に示すゾーンＩＤの設定に係る処理を再実行するようにしてもよい。このような再実行によりゾーンＩＤを更新できる。
【００９３】
以下、本実施の形態に従う位置情報を利用したいくつかのアプリケーションの例について説明する。以下に説明するアプリケーションにおいては、各デバイスが貨幣あるいは商品やサービスに対する対価となる価値（通常通貨および仮想通貨を含む）を管理する機能を実装してもよい。例えば、各デバイスに予算を与えることで、人が介在しない決済処理などを実現できる。
【００９４】
＜Ｅ．第１のアプリケーション例＞
第１のアプリケーション例として、建物内に配置されている火災報知器などに利用した構成について説明する。
【００９５】
図８は、本実施の形態に従うネットワークシステム１が提供する位置情報を利用したアプリケーションの一例を示す模式図である。図８を参照して、ビルディングの各階に火災報知器であるデバイス１０ＤＴ１〜１０ＤＴ６が配置されているとする。ビルディングの火災検知などを含む各種情報を集約するホストであるデバイス１０ＨＳＴも配置されており、デバイス１０ＨＳＴは、デバイス１０ＤＴ１〜１０ＤＴ６の各々とデータ通信可能になっている。さらに、デバイス１０ＨＳＴは、消防機関に配置されたホストあるいは消防機関ヘの通知を集約するホストであるデバイス１０ＭＳＴとデータ通信可能になっている。
【００９６】
図８に示す例では、１つのビルディングがゾーンＩＤの管理単位となっており、ゾーンＩＤとして「ＡＫＰＲＭＭ」が割り当てられているとする。さらに、ビルディングの各階にそれぞれゾーンＩＤが割り当てられている（「ＡＫＰＲＭＭ１」〜「ＡＫＰＲＭＭ６」）。
【００９７】
例えば、５階には位置された火災報知器（デバイス１０ＤＴ５）が火災を検知すると、その火災検知の情報をホスト（デバイス１０ＨＳＴ）に通知する。デバイス１０ＤＴ５とデバイス１０ＨＳＴとの間では、ゾーンＩＤを含む電子証明書１７０がやり取りされることでデータ通信を行うためのセッションが確立される。やり取りされる電子証明書１７０には、デバイス１０ＤＴ５のゾーンＩＤも含まれている。なお、デバイス１０ＤＴ５は、自デバイスのゾーンＩＤである「ＡＫＰＲＭＭ５」から上位階層となるデバイス１０が有しているゾーンＩＤを特定する。この例では、デバイス１０ＤＴ５のゾーンＩＤである「ＡＫＰＲＭＭ５」のうち最後の１文字を取り除いた「ＡＫＰＲＭＭ」が通知先であると特定できる。
【００９８】
デバイス１０ＨＳＴは、デバイス１０ＤＴ５から火災検知の情報を受信すると、デバイス１０ＤＴ５から予め取得している電子証明書１７０を参照してデバイス１０ＤＴ５のゾーンＩＤを特定し、火災検知の情報を特定したゾーンＩＤとともにデバイス１０ＭＳＴへ通知する。デバイス１０ＭＳＴは、デバイス１０ＨＳＴからの通知情報に基づいて、火災が検知された火災報知器（デバイス１０ＤＴ２）の位置を特定できる。そして、特定された位置に応じて、必要な処置を実行する。
【００９９】
このように、本実施の形態に従うネットワークシステム１を応用することで、ビルディングのいずれの階において火災などの異常が発生したのかを即座に取得できる。
【０１００】
図９は、図８に示すアプリケーションを実現するための処理手順を示すシーケンス図である。図９を参照して、デバイス間では、先にセッションを確立する処理が実行される。ホストであるデバイス１０ＨＳＴは、自デバイスの電子証明書１７０を消防機関のデバイス１０ＭＳＴへ送信し（シーケンスＳＱ１０）、デバイス１０ＭＳＴも自デバイスの電子証明書１７０をデバイス１０ＨＳＴへ送信する（シーケンスＳＱ１１）。デバイス１０ＨＳＴおよびデバイス１０ＭＳＴは、電子証明書１７０を交換することで、セッションを確立する（シーケンスＳＱ１２）。
【０１０１】
また、火災報知器であるデバイス１０ＤＴ５は、自デバイスの電子証明書１７０をデバイス１０ＨＳＴへ送信し（シーケンスＳＱ１３）、デバイス１０ＨＳＴも自デバイスの電子証明書１７０をデバイス１０ＤＴ５へ送信する（シーケンスＳＱ１４）。デバイス１０ＤＴ５およびデバイス１０ＨＳＴは、電子証明書１７０を交換することで、セッションを確立する（シーケンスＳＱ１５）。説明の便宜上、図９には、デバイス１０ＤＴ５とデバイス１０ＨＳＴとの間でセッションを確立する処理のみを示すが、他のデバイス１０ＤＴ１〜１０ＤＴ４および１０ＤＴ６についても、デバイス１０ＨＳＴとの間で同様にセッションを確立する。
【０１０２】
その後、デバイス１０ＤＴ５が火災を検知すると（シーケンスＳＱ１６）、デバイス１０ＤＴ５は火災検知の情報をデバイス１０ＨＳＴへ送信する（シーケンスＳＱ１７）。デバイス１０ＨＳＴは、デバイス１０ＤＴ５から火災検知の情報を受信すると、デバイス１０ＤＴ５から受信している電子証明書１７０を参照して、デバイス１０ＤＴ５のゾーンＩＤを決定する（シーケンスＳＱ１８）。そして、デバイス１０ＤＴ５は、デバイス１０ＤＴ５からの火災検知の情報と、決定したデバイス１０ＤＴ５のゾーンＩＤとをデバイス１０ＭＳＴへ送信する（シーケンスＳＱ１９）。
【０１０３】
このように、ネットワークシステム１を構成するデバイス１０ＤＴ５は、デバイス１０ＨＳＴとの間で電子証明書１７０を交換してセッションを確立した後に、自デバイスにて生成または収集した情報をデバイス１０ＨＳＴへ送信する。セッションの確立に用いられた電子証明書１７０の内容に基づいて、デバイス１０ＤＴ５を確実に特定できる。
【０１０４】
以上のような処理手順によって、火災報知器で検知された情報は、その検知された火災報知器の位置とともに消防機関などに送信されるので、消火活動に必要な位置情報を消防機関へ提供できる。
【０１０５】
なお、図８および図９においては、典型例として、火災報知器による通知の例を示したが、これに限らず任意の監視および検知に係るデバイス（例えば、赤外線センサやカメラなどによる侵入検知装置など）に適用可能である。
【０１０６】
さらに、火災報知器やスプリンクラーなどのデバイスにおいて、火災が発生した場合に必要となる水の料金を支払うことのできる預かり金を予め保持あるいは管理するようにしていてもよい。このような予算および決済機能を実装することで、火災報知器やスプリンクラーなどのデバイスは、火災を検知すると、管理者などの人が介在しない状態で、消防機関などへの情報の提供とともに、費用の管理までを自律的に実行することができる。
【０１０７】
＜Ｆ．第２のアプリケーション例＞
第２のアプリケーション例として、ホテルの部屋の予約および利用といったサービス利用の権利を管理する構成について説明する。
【０１０８】
図１０は、本実施の形態に従うネットワークシステム１が提供する位置情報を利用したアプリケーションの別の一例を示す模式図である。図１０に示すアプリケーションにおいては、ユーザが保持するモバイル端末であるデバイス１０ＴＲＭを電子的な鍵（利用証）として用いることができる。宿泊施設４０の各部屋の前には、施錠装置であるデバイス１０ＫＥＹが配置されている。ユーザが自身のモバイル端末であるデバイス１０ＴＲＭを操作して、予約サイトなどで利用予約をすると、後述するようなチケット情報がモバイル端末および対象の施錠装置に提供される。モバイル端末と対象の施錠装置との間では、同一のチケット情報が共有されており、ユーザが予約した部屋に近付くと、ユーザのモバイル端末と対象の施錠装置との間で通信を行うことで、部屋が解錠される。なお、モバイル端末と施錠装置との間の通信は、自動的に開始されるようにしてもよいし、ユーザが明示的に操作を行った上で開始されるようにしてもよい。
【０１０９】
図１１は、図１０に示すアプリケーションを実現するためのシステム構成例を示す模式図である。図１１を参照して、ホテルの各部屋に関連付けられた１または複数の施錠装置であるデバイス１０ＫＥＹ１，１０ＫＥＹ２，１０ＫＥＹ３，・・・が配置されている。デバイス１０ＫＥＹ１，１０ＫＥＹ２，１０ＫＥＹ３，・・・は、ホテルの予約などを管理するサーバであるデバイス１０ＳＲＶとデータ通信可能になっている。
【０１１０】
サーバであるデバイス１０ＳＲＶは、モバイル端末であるデバイス１０ＴＲＭともデータ通信可能になっている。
【０１１１】
サーバであるデバイス１０ＳＲＶは、施錠装置であるデバイス１０ＫＥＹ１，１０ＫＥＹ２，１０ＫＥＹ３，・・・が管理する各部屋に対する予約を管理する。各施錠装置が管理する部屋を「リソース」と考えると、デバイス１０ＳＲＶは、要求されたサービスに応じて、提供するリソースを管理するとみなすこともできる。後述するようなリソース管理に従って決定されたサービスを提供するための情報がチケット情報５０として、モバイル端末であるデバイス１０ＴＲＭおよびリソースを提供するデバイス１０ＫＥＹに送信される。
【０１１２】
図１２は、図１０に示すアプリケーションにおけるリソース管理を説明するための模式図である。図１２を参照して、サーバであるデバイス１０ＳＲＶは、デバイス１０ＫＥＹ１，１０ＫＥＹ２，１０ＫＥＹ３，・・・に関連付けられる部屋毎に時間をリソースとして管理する。ホテルの各部屋は、ある時刻においては１つの利用予約（すなわち、サービス）のみを受け付けるので、時間軸に対して、重複しないようにサービスを割り当てる。
【０１１３】
本実施の形態に従うネットワークシステム１においては、各デバイス１０が認証済みＩＰアドレスを有しているので、リソース管理においても、サービスを要求したデバイス１０の認証済みＩＰアドレスを用いることができる。
【０１１４】
図１２に示すように要求されたサービス（予約）に対してリソースを確保できると、サービスを要求したデバイス１０および確保されたリソースを提供するデバイス１０に対して、チケット情報５０が送信される。
【０１１５】
図１３は、図１０に示すアプリケーションにおいて用いられるチケット情報５０の一例を示す図である。図１３を参照して、チケット情報５０は、リソース割り当て期間５１と、リソースのＩＰアドレス５２と、リソースのゾーンＩＤ５３と、サービス提供先のＩＰアドレス５４とを含む。
【０１１６】
リソース割り当て期間５１は、部屋を利用可能な時間を示す。リソースのＩＰアドレス５２は、予約先の部屋に関連付けられた施錠装置であるデバイス１０ＫＥＹのＩＰアドレスを示す。リソースのゾーンＩＤ５３は、予約先の部屋に関連付けられた施錠装置であるデバイス１０ＫＥＹが有するゾーンＩＤを示す。サービス提供先のＩＰアドレス５４は、部屋を予約したデバイス１０ＴＲＭを示す。
【０１１７】
このようなチケット情報５０がデバイス１０ＴＲＭおよび対象のデバイス１０ＫＥＹの間で共有される。以上のように、施錠装置であるデバイス１０ＫＥＹ１，１０ＫＥＹ２，１０ＫＥＹ３，・・・は、各デバイスに関連付けられたリソースを管理するように構成されている。そして、デバイス１０ＴＲＭからの要求に応答して、デバイス１０ＫＥＹ１，１０ＫＥＹ２，１０ＫＥＹ３，・・・が管理しているリソースの少なくとも一部が割り当てられる。さらに、リソースの割り当てに係る情報は、リソースを提供したデバイス１０ＫＥＹおよびリソースを要求したデバイス１０ＴＲＭの間で共有される。
【０１１８】
図１４は、図１０に示すアプリケーションを実現するための処理手順を示すシーケンス図である。図１４を参照して、デバイス間では、先にセッションを確立する処理が実行される。サーバであるデバイス１０ＳＲＶは、自デバイスの電子証明書１７０を施錠装置であるデバイス１０ＫＥＹへ送信し（シーケンスＳＱ２０）、デバイス１０ＫＥＹも自デバイスの電子証明書１７０をデバイス１０ＳＲＶへ送信する（シーケンスＳＱ２１）。デバイス１０ＳＲＶおよびデバイス１０ＫＥＹは、電子証明書１７０を交換することで、セッションを確立する（シーケンスＳＱ２２）。説明の便宜上、図１４には、デバイス１０ＳＲＶと１つのデバイス１０ＫＥＹとの間でセッションを確立する処理のみを示すが、１または複数のデバイス１０ＫＥＹ１，１０ＫＥＹ２，１０ＫＥＹ３，・・・の各々との間についても、デバイス１０ＳＲＶとの間で同様にセッションを確立する。
【０１１９】
また、モバイル端末であるデバイス１０ＴＲＭは、自デバイスの電子証明書１７０をデバイス１０ＳＲＶへ送信し（シーケンスＳＱ２３）、デバイス１０ＳＲＶも自デバイスの電子証明書１７０をデバイス１０ＫＥＹへ送信する（シーケンスＳＱ２４）。デバイス１０ＤＴ５およびデバイス１０ＨＳＴは、電子証明書１７０を交換することで、セッションを確立する（シーケンスＳＱ２５）。
【０１２０】
その後、デバイス１０ＴＲＭに対するユーザ操作（シーケンスＳＱ２６）を受けて、デバイス１０ＴＲＭは、デバイス１０ＳＲＶへ予約要求を送信する（シーケンスＳＱ２７）。デバイス１０ＳＲＶは、デバイス１０ＴＲＭからの予約要求を受けて、要求されたサービスを提供可能なリソースを確保する（シーケンスＳＱ２８）。そして、デバイス１０ＴＲＭは、確保したリソースに応じたチケット情報５０を生成する（シーケンスＳＱ２９）。デバイス１０ＳＲＶは、予約要求を送信したデバイス１０ＴＲＭおよび確保したリソースを提供するデバイス１０ＫＥＹに対して、生成したチケット情報５０を送信する（シーケンスＳＱ３０およびＳＱ３１）。
【０１２１】
ユーザが予約した部屋に近付くと、デバイス１０ＴＲＭは、自デバイスの電子証明書１７０をデバイス１０ＫＥＹへ送信し（シーケンスＳＱ３２）、デバイス１０ＫＥＹも自デバイスの電子証明書１７０をデバイス１０ＴＲＭへ送信する（シーケンスＳＱ３３）。デバイス１０ＴＲＭおよびデバイス１０ＫＥＹは、電子証明書１７０を交換することで、セッションを確立する（シーケンスＳＱ３４）。そして、デバイス１０ＴＲＭとデバイス１０ＫＥＹとの間でチケット情報５０を互いに照会する処理が実行される（シーケンスＳＱ３５）。チケット情報５０の照会処理が成功裏に終了すると、デバイス１０ＫＥＹは、管理している部屋を解錠する（シーケンスＳＱ３６）。
【０１２２】
以上のような処理手順によって、ユーザによるホテルの部屋の予約およびモバイル端末自体を部屋の鍵として利用できる仕組みを提供できる。
【０１２３】
上述のアプリケーションの説明においては、典型例として、モバイル端末をホテルといった宿泊施設の各部屋の鍵として使用する構成について例示したが、これに限らず、任意の利用証として用いることができる。例えば、モバイル端末そのものを、アミューズメント施設などの各種施設や、コンサートなどの各種イベントの入場券として使用できる。さらに、モバイル端末そのものを、鉄道や航空機のチケットとして使用することもできる。
【０１２４】
さらに、デバイスとしての、宿泊施設の各部屋の鍵やチケット等の認証端末（例えば、ゲートや発券機など）は、それら自体に予算を与えることができる。予算は、預かり金や決済業者等と連携して保持するようにしてよい。あるいは、モバイル端末自体に予算を与えることもできる。こうして、認証端末とモバイル端末との間でシームレスな金銭のやり取りが可能となり、管理者などの人が介在しないシステムを構築できる。
【０１２５】
＜Ｇ．第３のアプリケーション例＞
第３のアプリケーション例として、交通リソースを管理する構成について説明する。
【０１２６】
本明細書において「交通リソース」とは、自動車、鉄道、航空機、船舶などの移動体で利用される物理的あるいは人的なリソースを意味する。基本的には、「交通リソース」は有限であり、要求に応じて適宜調停されて利用される。以下では、このような交通リソースを管理するデバイス１０で構成されるシステムを想定する。
【０１２７】
図１５は、本実施の形態に従うネットワークシステム１が提供する位置情報を利用したアプリケーションのさらに別の一例を示す模式図である。図１５には、交通リソースとして車両が通行する道路を想定するシステムを示す。より具体的には、４つの道路を想定し、各道路６１，６２，６３，６４の交差する区間毎に交通リソースを定義するとともに、各交通リソースを管理するデバイス１０を配置する。各デバイス１０には、管理する交通リソースを示すゾーンＩＤが設定されているとする。
【０１２８】
道路６１に関連付けられたデバイス１０（ゾーン：アヴェニュー００１）は、交通リソースを管理するためのリソーステーブル７１を有している。同様に、道路６２に関連付けられたデバイス１０（ゾーン：アヴェニュー００２）は、交通リソースを管理するためのリソーステーブル７２を有している。同様に、道路６３に関連付けられたデバイス１０（ゾーン：ストリート００１）は、交通リソースを管理するためのリソーステーブル７３を有している。同様に、道路６４に関連付けられたデバイス１０（ゾーン：ストリート００２）は、交通リソースを管理するためのリソーステーブル７４を有している。
【０１２９】
リソーステーブル７１〜７４には、関連付けられた交通リソースに存在する車両が登録されている。各車両は、ＩＰアドレスを有しており、各交通リソースに関連付けられたデバイス１０との間でデータ通信可能になっている。リソーステーブル７１〜７４を管理する各デバイス１０は、関連付けられた交通リソースを車両が利用する（あるいは、利用する予定になる）と、対応するリソーステーブルに当該車両のＩＰアドレスなどを登録する。また、リソーステーブル７１〜７４を管理する各デバイス１０は、関連付けられた交通リソースを車両が利用し終わると、対応するリソーステーブルから当該車両のＩＰアドレスを削除する。さらに、各車両の走行方向などの付加情報を併せて登録してもよい。
【０１３０】
このような交通リソースの管理を行うことで、交通集中などによる渋滞などを回避でき、各車両に対して最適な経路選択などを提供できる。
【０１３１】
図１６は、図１５に示すアプリケーションを利用した経路選択を示す模式図である。図１６を参照して、例えば、車両（ＩＰアドレスｘｘ）に対して、道路６１および道路６３の交通リソースを予め割り当てておくことで、スムーズに通行することができる。
【０１３２】
より具体的には、道路６１に関連付けられたリソーステーブル７１および道路６３に関連付けられたリソーステーブル７３に対して、それぞれ交通リソースの利用を予定する車両のＩＰアドレスを登録しておくことで、車両が通行する一種の「権利」を確保できる。
【０１３３】
このように、交通リソースの各々に関連付けたゾーンＩＤを用意するとともに、各ゾーンＩＤが割り当てられたデバイス１０が対応する交通リソースを管理するとともに、各交通リソースを利用するサービスについても管理するように構成することで、交通リソースの最適な利用を実現できる。
【０１３４】
移動体である車両は、ゾーンＩＤのコード体系を利用して、利用可能な交通リソースを管理するデバイス１０を特定できる。
【０１３５】
図１７は、図１５に示すアプリケーションを実現するための処理手順を示すシーケンス図である。図１７には、車両に搭載されるデバイス１０Ｍおよび道路６１，６２，６３，６４を管理するリソースマネジャであるデバイス１０ＲＭ１，１０ＲＭ２，１０ＲＭ３，１０ＲＭ４に加えて、デバイス１０ＲＭ１，１０ＲＭ２，１０ＲＭ３，１０ＲＭ４の上位階層に存在するゾーン管理サーバであるデバイス１０ＳＲＶを含むネットワークシステムの例を示す。
【０１３６】
図１７を参照して、車両に搭載されるデバイス１０Ｍは、任意の方法で現在位置を取得する（シーケンスＳＱ４０）。典型的には、ＧＰＳや移動体基地局からの情報に基づいて、現在位置が取得される。
【０１３７】
そして、デバイス１０Ｍは、自デバイスの電子証明書１７０をゾーン管理サーバであるデバイス１０ＳＲＶへ送信し（シーケンスＳＱ４１）、デバイス１０ＳＲＶも自デバイスの電子証明書１７０をデバイス１０Ｍへ送信する（シーケンスＳＱ４２）。デバイス１０Ｍおよびデバイス１０ＳＲＶは、電子証明書１７０を交換することで、セッションを確立する（シーケンスＳＱ４３）。
【０１３８】
セッション確立後、デバイス１０Ｍは、シーケンスＳＱ４０において取得した現在位置を含む接続先ノード問合せをデバイス１０ＳＲＶへ送信する（シーケンスＳＱ４４）。デバイス１０ＳＲＶは、接続先ノード問合せに含まれる現在位置に基づいて、接続先ノードをデバイス１０Ｍへ応答する（シーケンスＳＱ４５）。接続先ノードは、デバイス１０Ｍが利用することになる交通リソースを管理するデバイス１０を特定するための情報である。なお、接続先ノードとしては、複数のデバイス１０を含めるようにしてもよい。この例では、接続先ノードとして、リソースマネジャであるデバイス１０ＲＭ１が通知されたとする。
【０１３９】
このように、デバイス１０ＳＲＶは、デバイス１０Ｍからの現在位置の要求に応答して、当該現在位置に関連付けられたデバイス１０ＲＭ１，１０ＲＭ２，１０ＲＭ３，１０ＲＭ４を特定するための接続先ノード（特定情報）を応答する。
【０１４０】
続いて、デバイス１０Ｍは、自デバイスの電子証明書１７０をリソースマネジャであるデバイス１０ＲＭ１へ送信し（シーケンスＳＱ４６）、デバイス１０ＲＭ１も自デバイスの電子証明書１７０をデバイス１０Ｍへ送信する（シーケンスＳＱ４７）。デバイス１０Ｍおよびデバイス１０ＲＭ１は、電子証明書１７０を交換することで、セッションを確立する（シーケンスＳＱ４８）。
【０１４１】
セッション確立後、デバイス１０Ｍは、デバイス１０ＲＭ１へリソース要求を送信する（シーケンスＳＱ４９）。デバイス１０ＲＭ１は、デバイス１０Ｍからのリソース要求を受けて、要求に従ってリソースを確保する（シーケンスＳＱ５０）。そして、デバイス１０ＲＭ１は、リソースを確保できたことを示すリソース要求応答をデバイス１０Ｍへ送信する（シーケンスＳＱ５１）。さらに、デバイス１０ＲＭ１は、デバイス１０ＲＭ１が管理する交通リソースに引き続く交通リソースを特定し、特定された交通リソースを管理するデバイスマネジャを示す接続先ノードをデバイス１０Ｍへ応答する（シーケンスＳＱ５２）。この例では、接続先ノードとして、リソースマネジャであるデバイス１０ＲＭ２が通知されたとする。
【０１４２】
続いて、デバイス１０Ｍは、自デバイスの電子証明書１７０をリソースマネジャであるデバイス１０ＲＭ２へ送信し（シーケンスＳＱ５３）、デバイス１０ＲＭ２も自デバイスの電子証明書１７０をデバイス１０Ｍへ送信する（シーケンスＳＱ５４）。デバイス１０Ｍおよびデバイス１０ＲＭ２は、電子証明書１７０を交換することで、セッションを確立する（シーケンスＳＱ５５）。
【０１４３】
セッション確立後、デバイス１０Ｍは、デバイス１０ＲＭ２へリソース要求を送信する（シーケンスＳＱ５６）。デバイス１０ＲＭ２は、デバイス１０Ｍからのリソース要求を受けて、要求に従ってリソースを確保する（シーケンスＳＱ５７）。そして、デバイス１０ＲＭ２は、リソースを確保できたことを示すリソース要求応答をデバイス１０Ｍへ送信する（シーケンスＳＱ５８）。さらに、デバイス１０ＲＭ２は、デバイス１０ＲＭ２が管理する交通リソースに引き続く交通リソースを特定し、特定された交通リソースを管理するデバイスマネジャを示す接続先ノードをデバイス１０Ｍへ応答する（シーケンスＳＱ５９）。以下、シーケンスＳＱ４６〜ＳＱ５２およびシーケンスＳＱ５３〜ＳＱ５９と類似下処理が繰り返される。
【０１４４】
このような処理手順によって、図１６に示すような交通リソースの割り当てが完了する。これにより、交通リソースの効率的な利用を実現できる。
【０１４５】
以上のように、デバイス１０ＲＭ１，１０ＲＭ２，１０ＲＭ３，１０ＲＭ４は、各デバイスに関連付けられた交通リソースを管理するように構成されている。そして、デバイス１０Ｍからの要求に応答して、デバイス１０ＲＭ１，１０ＲＭ２，１０ＲＭ３，１０ＲＭ４が管理している交通リソースの少なくとも一部が割り当てられる。
【０１４６】
上述のアプリケーションの説明においては、交通リソースの典型例として道路を採用した場合について例示したが、これに限らず、任意の交通リソースに対して適用可能である。例えば、鉄道、航空機、船舶などの各便の各座席を交通リソースとして取り扱うこともできる。
【０１４７】
上述の交通リソースに対しても予算を割り当てることができる。この場合、目的地に最短時間で到達することを保証されたい場合には、道路利用者が交通リソースに対して課金をするような仕組みを提案することができる。一方で、効率的な経路であるにもかかわらず、混雑していない道路においては交通リソースが予算の中からユーザ等に利用の対価を支払うこともできる。
【０１４８】
＜Ｈ．その他の形態＞
上述のアプリケーションの例においては、デバイス１０との間でデータをやり取りする処理を例示したが、これに限らず、デバイス１０との間で命令（コマンド）をやり取りするようにしてもよい。このような命令をやり取りすることで、デバイス１０の役割などを動的に変化させることができる。
【０１４９】
このような役割を動的に変化させることで、例えば、あるデバイス１０の処理を別のデバイス１０に委任あるいは代理するようなことも可能となる。例えば、図１５に示すような交通リソースの管理を担当するデバイス１０に何らかの不具合が発生した場合、あるいは、交通リソースの管理に係る処理が増大したような場合には、処理を担当していたデバイス１０を別のデバイス１０に変更する、あるいは、処理を担当していたデバイス１０に加えて別のデバイス１０を追加するといった役割の変更を行ってもよい。このようなネットワークシステム全体としてデバイス１０を最適に利用するための任意の手法を採用できる。
【０１５０】
＜Ｉ．利点＞
本実施の形態に従うネットワークシステム１によれば、デバイスの認証済みの位置情報を取得することができるとともに、認証済みの位置情報を用いた様々なサービスを提供できる。
【０１５１】
今回開示された実施の形態はすべての点で例示であって制限的なものでないと考えられるべきである。本発明の範囲は上記した説明ではなくて請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【０１５２】
１  ネットワークシステム、２  認証局、１０，１０Ａ１〜１０Ａ４，１０Ｂ１〜１０Ｂ５，１０Ｃ１〜１０Ｃ４，１０ＤＴ１〜１０ＤＴ６，１０ＨＳＴ，１０ＫＥＹ，１０ＫＥＹ１〜１０ＫＥＹ３，１０Ｍ，１０ＭＳＴ，１０ＲＭ１〜１０ＲＭ４，１０ＳＲＶ，１０ＴＲＭ  デバイス、４０  宿泊施設、５０  チケット情報、５１  リソース割り当て期間、５２，５４，１６８  ＩＰアドレス、５３，１８２  ゾーンＩＤ、６１，６２，６３，６４  道路、７１，７２，７３，７４  リソーステーブル、１０２  プロセッサ、１０４  主メモリ、１０６  ストレージ、１０８  ＲＯＭ、１１０  制御部、１２０  ネットワークインターフェイス、１３０  内部インターフェイス、１４０  入力部、１５０  出力部、１６０  秘密鍵、１６２  公開鍵、１６４  ハッシュ関数、１６６  ハッシュ値、１７０  電子証明書、１７１  バージョン情報、１７２  シリアル番号、１７３  署名アルゴリズム、１７４  発行者識別名、１７５  有効期間、１７６  主体者識別名、１７８  認証局署名、１８０  拡張情報。
【図１】
2020178279.tif 000003
【図２】
2020178279.tif 000004
【図３】
2020178279.tif 000005
【図４】
2020178279.tif 000006
【図５】
2020178279.tif 000007
【図６】
2020178279.tif 000008
【図７】
2020178279.tif 000009
【図８】
2020178279.tif 000010
【図９】
2020178279.tif 000011
【図１０】
2020178279.tif 000012
【図１１】
2020178279.tif 000013
【図１２】
2020178279.tif 000014
【図１３】
2020178279.tif 000015
【図１４】
2020178279.tif 000016
【図１５】
2020178279.tif 000017
【図１６】
2020178279.tif 000018
【図１７】
2020178279.tif 000019