JP7437722B2 - データ送信方法、通信処理方法、装置、および通信処理プログラム - Google Patents

Description

本開示は、認証済みＩＰアドレスを有するデバイス間のデータ通信技術に関する。

近年の情報通信技術（Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ：ＩＣＴ）の進歩は目覚ましく、インターネットなどのネットワークに接続されるデバイスは、従来のパーソナルコンピュータやスマートフォンといった情報処理装置に限らず、様々なモノ（ｔｈｉｎｇｓ）に広がっている。このような技術トレンドは、「ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ；モノのインターネット）」と称され、様々な技術およびサービスが提案および実用化されつつある。将来的には、地球上の数十億人と数百億または数兆のデバイスとが同時につながる世界が想定されている。このようなネットワーク化された世界を実現するためには、よりシンプル、より安全、より自由につながることができるソリューションを提供する必要がある。

通常、ネットワーク上では、各デバイスに静的または動的に割り当てられたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを用いて、デバイス間のデータ通信が実現される。

デバイス間のデータ通信を実現するためには、送信元のデバイスから送出されたデータを宛先のデバイスまで転送しなければならない。このようなデータ転送の処理は、「ルーティング」などと称される。このようなルーティングを実現するために、ネットワーク上には多数のルータが配置される。

特開平０５－０２２２９３号公報（特許文献１）に開示されるように、ルータは、経路情報を記憶する経路情報テーブルを有しており、受信フレーム中のインターネットワーキング用アドレスと、経路情報テーブルの内容に従って、経路を定めて受信フレームの中継を行う（特開平０５－０２２２９３号公報の段落［０００５］および［０００６］など参照）。

特開平０５－０２２２９３号公報

上記特許文献１によれば、多数のデバイスが存在するネットワークを想定すると、ルータも多数必要となり、また、各ルータの責務も大きくなる。そのため、多数のデバイスが存在するネットワークにおいては、各デバイスが自立してデータ通信を実現できる構成が好ましい。本開示は、このような構成を実現するための解決策を提供する。

本開示のある形態によれば、複数のデバイスが接続されたネットワークにおけるデータ送信方法が提供される。データ送信方法は、複数のデバイスの各々が、各デバイスが有している公開鍵からハッシュ関数に従って算出されるハッシュ値に基づいて、各デバイスのＩＰアドレスを決定するステップと、複数のデバイスの各々が、各デバイスの接続関係を反映したステート情報を保持するとともに、ステート情報の内容を示す通知メッセージを他のデバイスへ送信するステップと、複数のデバイスの各々が、他のデバイスから受信した通知メッセージに基づいて各デバイスが保持するステート情報を更新するステップと、各デバイスが保持するステート情報に基づいて論理的に規定されるデバイスの集合の間で、当該集合に含まれるデバイスの間で保持される、データ送信の宛先となるデバイスの探索に用いられるルーティングテーブルを決定するステップとを含む。

通知メッセージは、各デバイスが決定したＩＰアドレスに基づいて算出される、各デバイスを特定するための識別情報を含んでいてもよい。

データ送信方法は、複数のデバイスの各々が、各デバイスが有している公開鍵および当該公開鍵に関連付けられた電子証明書を他のデバイスに送信するステップと、公開鍵および電子証明書を受信したデバイスにおいて、ハッシュ関数に従って公開鍵から算出されるハッシュ値に基づいて、公開鍵および電子証明書の送信元のデバイスのＩＰアドレスを決定するステップとをさらに含むようにしてもよい。

決定されるＩＰアドレスは、予め定められた特定用の固有値を含んでいてもよい。
決定されるＩＰアドレスは、当該ＩＰアドレスを決定したデバイスの種類に応じた値を含んでいてもよい。

本開示の別の形態によれば、ネットワークに接続されたデバイスでの通信処理方法が提供される。通信処理方法は、公開鍵からハッシュ関数に従って算出されるハッシュ値に基づいて、自デバイスのＩＰアドレスを決定するステップと、他のデバイスとの接続関係を反映したステート情報を保持するとともに、ステート情報の内容を示す通知メッセージを他のデバイスへ送信するステップと、他のデバイスから受信した通知メッセージに基づいてステート情報を更新するステップと、各デバイスが保持するステート情報に基づいて論理的に規定されるデバイスの集合の間で、データ送信の宛先となるデバイスの探索に用いられるルーティングテーブルを保持するステップとを含む。

通知メッセージは、決定した自デバイスのＩＰアドレスに基づいて算出される、自デバイスを特定するための識別情報を含んでいてもよい。

通信処理方法は、ステート情報に基づいて、集合において自デバイスがルートノードとして動作すると判断されると、ルーティングテーブルを決定するステップをさらに含んでいてもよい。

ルーティングテーブルを保持するステップは、他のデバイスからルーティングテーブルを受信するステップを含んでいてもよい。

ステート情報および通知メッセージは、ルートノードとされているデバイスを特定するための識別情報を含んでいてもよい。更新するステップは、受信した通知メッセージに含まれるルートノードとされているデバイスと、ステート情報に含まれるルートノードとされるデバイスとが一致しない場合には、予め定められた規則に従って、一方のデバイスをルートノードと決定するステップを含んでいてもよい。

通信処理方法は、認証局から公開鍵に関連付けられた電子証明書を取得するステップと、公開鍵および電子証明書を他のデバイスに送信するステップとをさらに含んでいてもよい。

通信処理方法は、他のデバイスから公開鍵および公開鍵に関連付けられた電子証明書を受信すると、電子証明書の正当性を判断するステップと、電子証明書が正当であると判断されると、ハッシュ関数に従って公開鍵から算出されるハッシュ値に基づいて、他のデバイスのＩＰアドレスを決定するステップとをさらに含んでいてもよい。

決定されるＩＰアドレスは、予め定められた特定用の固有値を含んでいてもよい。
決定されるＩＰアドレスは、当該ＩＰアドレスを決定したデバイスの種類に応じた値を含んでいてもよい。

本開示の別の形態によれば、ネットワークに接続されたデバイスでの通信処理方法が提供される。通信処理方法は、他のデバイスが有している公開鍵および当該公開鍵に関連付けられた電子証明書を受信するステップと、電子証明書の正当性を判断するステップと、電子証明書が正当であると判断されると、公開鍵からハッシュ関数に従って算出されるハッシュ値に基づいて決定されるＩＰアドレスを、他のデバイスの認証済みＩＰアドレスとして決定するステップと、他のデバイスからの要求に応答して、他のデバイスの認証済みＩＰアドレスに応じたサービスを提供するステップとを含む。

公開鍵は、当該公開鍵からハッシュ関数に従って算出されるハッシュ値に基づいて決定されるＩＰアドレスが、予め定められたフォーマットに合致するように決定されてもよい。

本開示のさらに別の形態に従う装置は、ネットワークに接続するためのネットワークインターフェイスと、ネットワークインターフェイスに接続された制御部とを含む。制御部は、公開鍵からハッシュ関数に従って算出されるハッシュ値に基づいて、自デバイスのＩＰアドレスを決定する処理と、他のデバイスとの接続関係を反映したステート情報を保持するとともに、ステート情報の内容を示す通知メッセージを他のデバイスへ送信する処理と、他のデバイスから受信した通知メッセージに基づいてステート情報を更新する処理と、各デバイスが保持するステート情報に基づいて論理的に規定されるデバイスの集合の間で、データ送信の宛先となるデバイスの探索に用いられるルーティングテーブルを保持する処理とを実行する。

本開示のさらに別の形態によれば、ネットワークに接続するためのネットワークインターフェイスを有するコンピュータのための通信処理プログラムが提供される。通信処理プログラムは、通信処理プログラムはコンピュータによって実行されると、コンピュータに上記の通信処理方法を実行させる。

本開示によれば、多数のデバイスが存在するネットワークにおいて、各デバイスが自立してデータ通信を実現できる構成を提供できる。

本実施の形態に従うネットワークシステムの全体構成の一例を示す模式図である。 本実施の形態に従うデバイスのハードウェア構成例を示す模式図である。 本実施の形態に従うデバイスのプログラムおよびデータの構成例を示す模式図である。 本実施の形態に従うネットワークシステムにおけるＩＰアドレスの認証手順を説明するための図である。 本実施の形態に従うネットワークシステムで利用されるＩＰアドレスに埋め込まれる種類特定情報の一例を示す図である。 本実施の形態に従うネットワークシステムにおいてデバイスが認証済みＩＰアドレスを提供する処理手順を示すフローチャートである。 本実施の形態に従うネットワークシステムにおけるＩＰアドレスの通知に係る処理を説明するための図である。 本実施の形態に従うネットワークシステムにおけるＩＰアドレスの通知に係る処理を説明するための図である。 本実施の形態に従うネットワークシステムにおけるＩＰアドレスの通知に係る処理手順を示すシーケンスチャートである。 本実施の形態に従うネットワークシステムを利用したサービス提供のアプリケーション例を説明するための図である。 本実施の形態に従うネットワークシステムを利用したサービス提供の別のアプリケーション例を説明するための図である。 本実施の形態に従うネットワークシステムにおけるルーティングの一例を説明するための図である。 本実施の形態に従うネットワークシステムにおけるルーティングの実現方法を説明するための図である。 本実施の形態に従うネットワークシステムにおけるルーティングの実現方法を説明するための別の図である。 本実施の形態に従うネットワークシステムにおけるルーティングの実現に係る処理手順を示すシーケンスチャートである。 本実施の形態に従うネットワークシステムにおいて用いられるステート情報およびステート通知メッセージのデータ構造の一例を示す図である。 本実施の形態に従うネットワークシステムにおけるステート通知メッセージによるステート情報の更新例を示す図である。 本実施の形態に従うネットワークシステムにおけるルーティングテーブルの決定に係る処理手順を示すフローチャートである。 本実施の形態に従うネットワークシステムにおける各デバイスのパケット送受信に係る処理手順を示すフローチャートである。

本開示に係る実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰り返さない。

＜Ａ．ネットワークシステム１の全体構成＞
まず、本実施の形態に従うネットワークシステム１の全体構成について説明する。

図１は、本実施の形態に従うネットワークシステム１の全体構成の一例を示す模式図である。図１を参照して、インターネットやイントラネットなどの任意のネットワーク２には、複数のデバイス１００－１，１００－２，１００－３，１００－４，１００－５，・・・（以下、「デバイス１００」と総称することもある。）が接続されているとする。一部のデバイス１００は、アクセスポイント４との間に確立された無線通信を介して、ネットワーク２に接続されてもよい。あるいは、別の一部のデバイス１００は、移動体基地局６との間に確立された無線通信を介して、ネットワーク２に接続されてもよい。

このように、ネットワーク２は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、無線アクセスネットワーク（ＲＡＮ）、およびインターネットのうちのいずれかを含んでいてもよい。

ネットワークに接続されたデバイス１００の各々は、ネットワークの「ノード」とみなすことができ、以下の説明においては、デバイス１００を「ノード」と称することもある。

本実施の形態に従うネットワークシステム１において、デバイス１００の間では、後述するような手順に従って、データ通信を実現する。なお、デバイス１００間の物理的な接続方法はどのようなものであってもよい。

デバイス１００は、各々が有しているＩＰアドレスを用いて他のデバイスとデータ通信を行う機能を有している任意の装置を包含する。デバイス１００は、通信装置単体として構成されることもあるし、何らかのモノの一部として、あるいは、何らかのモノに組み込まれて構成されることもある。

より具体的には、デバイス１００は、例えば、パーソナルコンピュータ、スマートフォン、タブレット、ユーザの身体（例えば、腕や頭など）に装着されるウェアラブルデバイス（例えば、スマートウォッチやＡＲグラスなど）のいずれであってもよい。また、デバイス１００は、スマート家電、コネクティッド自動車、工場などに設置された制御機器あるいはその一部であってもよい。

本実施の形態に従うネットワークシステム１は、１または複数の認証局２００をさらに含む。認証局２００の各々は、１または複数のサーバで構成されるコンピュータである。１または複数の認証局２００を用いて、後述するような手順によって、各デバイス１００が有しているＩＰアドレスは認証される。その結果、各デバイス１００は、認証済みＩＰアドレスを有することになる。

本明細書において、「認証済みＩＰアドレス」は、通信先あるいは第三者に対して、各デバイス１００が保持しているＩＰアドレスの正当性が保証されている状態を意味する。より具体的には、「認証済みＩＰアドレス」は、不可逆な暗号学的ハッシュ関数によって生成されるとともに、認証局によって直接的または間接的に認証されたＩＰアドレスであることを意味する（詳細については後述する）。このような「認証済みＩＰアドレス」を用いることで、各デバイス１００がデータ通信に利用するＩＰアドレスが偽装されていないことを保証できる。

その結果、ネットワークシステム１に含まれる任意のデバイス１００は、各デバイス１００が有しているＩＰアドレスに基づいて一意に特定されることになる。すなわち、各デバイスは、各デバイスが有しているＩＰアドレスに基づいて、データ送信の宛先や送出先となるデバイスを決定できる。

ＩＰアドレスは、インターネットに接続されたデバイス１００間のデータ通信にも用いることができるグローバルＩＰアドレスが想定されるが、特定のネットワーク内だけで利用されるプライベートＩＰアドレスであってもよい。

ＩＰアドレスは、バージョンによって、アドレスを構成するビット数が異なっている。現在制定されているＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ４）においては、３２ビットのアドレス区間が規定されており、現在制定されているＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ６）においては、１２８ビットのアドレス区間が規定されている。本実施の形態においては、ＩＰｖ６に従うＩＰアドレスを主として説明する。但し、より多くのビット数で規定されるネットワークアドレス、あるいは、より少ないビット数で規定されるネットワークアドレスにも本開示は適用可能である。

＜Ｂ．デバイス１００の構成例＞
次に、本実施の形態に従うネットワークシステム１に用いられるデバイス１００のハードウェアおよびソフトウェアの構成例について説明する。

図２は、本実施の形態に従うデバイス１００のハードウェア構成例を示す模式図である。図２を参照して、デバイス１００は、主たるコンポーネントとして、処理回路（ｐｒｏｃｅｓｓｉｎｇ ｃｉｒｃｕｉｔｒｙ）である制御部１１０とを含む。

制御部１１０は、本実施の形態に従う機能の提供および処理の実行を実現するための演算主体である。制御部１１０は、図２に示すようなプロセッサおよびメモリを用いて、メモリに格納されたコンピュータ可読命令（ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｉｎｓｔｒｕｃｔｉｏｎｓ）（図３に示すようなＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）および通信処理プログラム）をプロセッサが実行するように構成されてもよい。あるいは、コンピュータ可読命令に相当する回路が組み込まれたＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などのハードワイヤード回路を用いて制御部１１０を実現してもよい。さらにあるいは、ＦＰＧＡ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）上にコンピュータ可読命令に相当する回路を実現することで制御部１１０を実現してもよい。また、プロセッサおよびメモリ、ＡＳＩＣ、ＦＰＧＡなどを適宜組み合わせて制御部１１０を実現してもよい。

図２に示すようなプロセッサおよびメモリを用いた構成において、制御部１１０は、プロセッサ１０２と、主メモリ１０４と、ストレージ１０６と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０８とを含む。

プロセッサ１０２は、コンピュータ可読命令を順次読出して実行する演算回路である。プロセッサ１０２は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＭＰＵ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などで構成される。複数のプロセッサ１０２を用いて制御部１１０を実現してもよいし（マルチプロセッサの構成）、複数のコアを有するプロセッサを用いて制御部１１０を実現してもよい（マルチコアの構成）。

主メモリ１０４は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）やＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などの揮発性記憶装置である。プロセッサ１０２は、ストレージ１０６またはＲＯＭ１０８に格納された各種プログラムのうち、指定されたプログラムを主メモリ１０４上に展開し、主メモリ１０４と協働することで、本実施の形態に従う各種処理を実現する。

ストレージ１０６は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリなどの不揮発性記憶装置である。ストレージ１０６には、プロセッサ１０２で実行される各種プログラムや後述するような各種データが格納されている。

ＲＯＭ１０８は、プロセッサ１０２で実行される各種プログラムや後述するような各種データを固定的に格納する。

図２に示すようなプロセッサ１０２がメモリに格納されたコンピュータ可読命令を実行する構成において、メモリは、ストレージ１０６およびＲＯＭ１０８に相当する。

ここで、デバイス１００のメモリに格納されるプログラムおよびデータの一例について説明する。

図３は、本実施の形態に従うデバイス１００のプログラムおよびデータの構成例を示す模式図である。図３を参照して、デバイス１００のメモリ（ストレージ１０６および／またはＲＯＭ１０８）には、例えば、コンピュータ可読命令を含むプログラムとして、ＯＳ１６０と、通信処理プログラム１７０と、各種アプリケーション３００とが格納される。

ＯＳ１６０は、デバイス１００で実行される処理を実現するための基本的な機能を提供するプログラムである。通信処理プログラム１７０は、主として、本実施の形態に従う機能の提供および処理の実行を実現するためのプログラムである。なお、通信処理プログラム１７０は、ＯＳ１６０が提供するライブラリなどを利用して、本実施の形態に従う機能の提供および処理の実行を実現することもある。

各種アプリケーション３００は、デバイス１００が提供する各種機能を実現するためのプログラムであり、ユーザが任意にインストールすることができる。典型的には、各種アプリケーション３００は、通信処理プログラム１７０に提供されるデータ通信機能を利用した各種処理を提供する。

また、デバイス１００のメモリ（ストレージ１０６および／またはＲＯＭ１０８）には、例えば、本実施の形態に従う機能の提供および処理の実行の実現に必要なデータとして、秘密鍵１７２と、公開鍵１７４と、電子証明書１７６とが格納される。秘密鍵１７２および公開鍵１７４は、任意の暗号化／復号アルゴリズムに従って生成される、いわゆる鍵ペアである。秘密鍵１７２は、他のデバイスとの暗号化通信に用いられる。公開鍵１７４は、後述するような手順に従って各デバイス１００のＩＰアドレスの決定に用いられる。電子証明書１７６は、認証局２００によって公開鍵１７４に対して発行されるものであり、デバイス１００のＩＰアドレスの正当性を担保するためのものである。通常、電子証明書１７６は、認証局２００の秘密鍵を用いて、各デバイス１００の公開鍵１７４から算出されたハッシュ値（電子署名）などを含む。電子証明書１７６を受信したデバイス１００は、認証局２００の公開鍵を用いて、電子証明書１７６および電子証明書１７６に関連付けられた公開鍵１７４の正当性を確認する。

鍵ペア（秘密鍵１７２および公開鍵１７４）の生成、電子証明書１７６の取得、およびこれらのデータの利用手順などについては後述する。

なお、ストレージ１０６およびＲＯＭ１０８の両方を設ける必要はなく、実装形態に応じて、いずれか一方のみを設けるようにしてもよい。また、ストレージ１０６およびＲＯＭ１０８の両方を設ける場合には、例えば、鍵ペア（秘密鍵１７２および公開鍵１７４）についてはＲＯＭ１０８に格納して、秘匿性を高めるようにしてもよい。

再度図２を参照して、デバイス１００は、デバイス１００をネットワークに接続するためのネットワークインターフェイス１２０をさらに含む。ネットワークインターフェイス１２０は、ネットワークを介して他のデバイスとデータ通信を行う。

ネットワークインターフェイス１２０は、例えば、イーサネット（登録商標）ポート、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポート、ＩＥＥＥ１３９４などのシリアルポート、レガシーなパラレルポートといった有線接続端子を含む。あるいは、ネットワークインターフェイス１２０は、デバイス、ルータ、移動体基地局などと無線通信するための処理回路およびアンテナなどを含んでもよい。ネットワークインターフェイス１２０が対応する無線通信は、例えば、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）、ＬＰＷＡ（Ｌｏｗ Ｐｏｗｅｒ Ｗｉｄｅ Ａｒｅａ）、ＧＳＭ（登録商標）、Ｗ－ＣＤＭＡ、ＣＤＭＡ２００、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、第５世代移動通信システム（５Ｇ）のいずれであってもよい。

デバイス１００は、オプショナルなコンポーネントとして、表示部１３０と、入力部１４０と、メディアインターフェイス１５０とを含んでいてもよい。

表示部１３０は、プロセッサ１０２での処理結果などを外部へ提示するためのコンポーネントである。表示部１３０は、例えば、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）や有機ＥＬ（Ｅｌｅｃｔｒｏ－Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどであってもよい。また、表示部１３０は、ユーザの頭部に装着されるヘッドマウントディスプレイであってもよいし、画像をスクリーン上に投影するプロジェクターであってもよい。

入力部１４０は、デバイス１００を操作するユーザの入力操作を受け付けるためのコンポーネントである。入力部１４０は、例えば、キーボード、マウス、表示部１３０上に配置されたタッチパネル、デバイス１００の筐体に配置された操作ボタンなどであってもよい。

メディアインターフェイス１５０は、各種プログラム（コンピュータ可読命令）および／または各種データが格納された非一過性（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ）のメディア１５２から各種プログラムおよび／または各種データを読み出す。

メディア１５２は、例えば、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）などの光学メディア、ＵＳＢメモリなどの半導体メディアなどであってもよい。メディアインターフェイス１５０は、メディア１５２の種類に応じた構成が採用される。メディアインターフェイス１５０により読み出された各種プログラムおよび／または各種データは、ストレージ１０６などに格納されてもよい。

なお、メディア１５２を介して各種プログラムおよび／または各種データをデバイス１００にインストールするのではなく、ネットワーク上の配信サーバから必要なプログラムおよびデータをデバイス１００にインストールするようにしてもよい。この場合には、ネットワークインターフェイス１２０を介して、必要なプログラムおよびデータが取得される。

上述したように、表示部１３０、入力部１４０、メディアインターフェイス１５０は、オプショナルなコンポーネントであるため、例えば、ＵＳＢなどの任意のインターフェイスを介してデバイス１００の外部から接続されるようにしてもよい。

本実施の形態に従う機能の提供および処理の実行を実現するのは制御部１１０であり、本願の技術的範囲は、少なくとも、制御部１１０を実現するためのハードウェアおよび／またはソフトウェアを包含する。ハードウェアは、上述したように、プロセッサおよびメモリからなる構成だけではなく、ＡＳＩＣなどを用いたハードワイヤード回路やＦＰＧＡを用いた構成を含み得る。すなわち、制御部１１０は、汎用コンピュータにプログラムをインストールすることで実現され得るし、専用のチップとして実現することもできる。

また、プロセッサで実行されるソフトウェアは、メディア１５２を介して流通するものだけではなく、配信サーバを介して適宜ダウンロードされるものも含み得る。

なお、本実施の形態に従う機能の提供および処理の実行を実現するための構成は、図２に示す制御部１１０に限られず、実現される時代に応じた任意の技術を用いて実装できる。

＜Ｃ．認証済みＩＰアドレス＞
次に、各デバイス１００に対して認証済みＩＰアドレスを提供するための処理などについて説明する。

（ｃ１：ＩＰアドレスの決定処理）
本実施の形態に従うネットワークシステム１においては、典型的には、認証済みＩＰアドレスを用いて、各デバイス１００のＩＰアドレスを認証する。一例として、公開鍵暗号基盤（ＰＫＩ：ｐｕｂｌｉｃ ｋｅｙ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を用いて、各デバイス１００のＩＰアドレスを認証してもよい。

図４は、本実施の形態に従うネットワークシステム１におけるＩＰアドレスの認証手順を説明するための図である。なお、図４中の「Ｓ１」～「Ｓ４」などの符号は、図６に示すステップ番号に対応している。

図４を参照して、デバイス１００は、秘密鍵１７２および公開鍵１７４からなる鍵ペアを有している。予め定められたハッシュ関数１８０に公開鍵１７４を入力することでハッシュ値１７８を算出し、その算出されたハッシュ値１７８の全部または一部を用いて、デバイス１００のＩＰアドレス１９０として用いる。

このようなＩＰアドレス１９０の決定処理に伴い、デバイス１００は、公開鍵１７４を認証局２００へ送信し、認証局２００が公開鍵１７４に対して発行する電子証明書１７６を紐付ける。デバイス１００は、自デバイスの公開鍵１７４および電子証明書１７６を他のデバイスへ送信する。他のデバイスは、デバイス１００が公開する公開鍵１７４および電子証明書１７６に基づいて、デバイス１００のＩＰアドレス１９０の正当性を確認する。ＩＰアドレス１９０の正当性が確認されると、正当性が確認されたＩＰアドレス１９０を用いてデータ通信を開始する。自デバイスおよび他のデバイスは、互いに直接通信を行うことができるが、直接通信の処理に加えて、認証局２００における問い合わせの処理を含むようにしてもよい。

このように、本実施の形態に従うネットワークシステム１においては、ＩＰアドレス１９０自体を認証することができ、このような認証済みＩＰアドレス１９０をデバイス自体が保持することで、各デバイスに静的または動的に割り当てられたＩＰアドレスを用いることなく、自立的なネットワークを構築できる。

以下、本実施の形態に従うネットワークシステム１における認証済みＩＰアドレスを提供するための処理の詳細について説明する。

鍵ペアである秘密鍵１７２および公開鍵１７４は、デバイス１００自身が作成してもよいし、外部から提供されて予めデバイス１００に格納されていてもよい。外部から提供される場合には、デバイス１００は秘密鍵１７２のみを取得し、公開鍵１７４については自身で生成するようにしてもよい。

鍵ペアである公開鍵１７４の生成方法の一例としては、乱数発生器が発生する所定長さのビット列（例えば、５１２ビット）を秘密鍵１７２として用いるとともに、公知の暗号アルゴリズム（例えば、楕円曲線暗号アルゴリズム）に従って秘密鍵１７２から所定長さのビット列（例えば、２５６ビット）からなる公開鍵１７４を生成してもよい。なお、デバイス１００自身が鍵ペアを生成する場合には、乱数発生器は、ＯＳ１６０が提供する機能を利用して実現してもよいし、ＡＳＩＣなどのハードワイヤード回路を用いて実現してもよい。

ハッシュ関数１８０は、公知の不可逆な暗号学的ハッシュ関数（例えば、ＢＬＡＫＥ）を用いることができる。ハッシュ関数１８０は、所定長さのビット列（例えば、２５６ビット）からなるハッシュ値１７８を算出する。

ハッシュ関数１８０には、公開鍵１７４だけではなく、任意のキーワードを入力するようにしてもよい。任意のキーワードとして、所定の組織に関連付けられたメッセージを用いてもよい。所定の組織に関連付けられたメッセージとして、当該所定の組織が有している商標の名称を含むメッセージを用いてもよい。例えば、所定の組織が保有する登録された商標の名称（例えば、「ｃｏｎｎｅｃｔＦｒｅｅ」）をハッシュ関数１８０に入力するキーワードとして用いるようにしてもよい。このような実装方式を採用することで、所定の組織以外の第三者が、当該所定の組織の許諾なしに本実施の形態に従うネットワークシステム１および関連する方法やプログラムなどを実施することを防止できる。

ハッシュ関数１８０により算出されるハッシュ値１７８の全部または一部がＩＰアドレス１９０として用いられる。例えば、２５６ビット（１６進数表現で６４桁）のハッシュ値１７８が算出される場合には、６４桁のハッシュ値１７８のうち任意の３２桁（例えば、前半３２桁）をＩＰｖ６に対応するＩＰアドレス１９０（１２８ビット）として決定してもよい。あるいは、６４桁のハッシュ値１７８のうち前半８桁をＩＰｖ４に対応するＩＰアドレス１９０（３２ビット）として決定してもよい。

あるいは、ＩＰｖ６に対応するＩＰアドレス１９０（１２８ビット）を考慮して、ハッシュ関数１８０から１２８ビットのハッシュ値１７８を算出するようにしてもよい。この場合には、算出されるハッシュ値１７８の全部をＩＰｖ６に対応するＩＰアドレス１９０（１２８ビット）として決定できる。

本実施の形態によれば、デバイス１００の公開鍵１７４に基づいてデバイス１００に固有のＩＰアドレス１９０を決定できる。このように、デバイス１００によって決定されたＩＰアドレス１９０を用いてデバイス１００をインターネットなどのネットワークに接続させることができる。また、デバイス１００は、インターネットサービスプロバイダ（ＩＳＰ）などのグローバルＩＰアドレスを管理するサービス事業者（サーバ）が存在しなくても、自身が決定したＩＰアドレス１９０を用いてデータ通信を行うことができる。また、デバイス１００は、アクセスポイントなどに実装されるＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバなどのプライベートＩＰアドレスを管理するサーバが存在しなくても、自身が決定したＩＰアドレス１９０を用いてインターネットなどのグルーバルネットワークに接続してデータ通信を行うことができる。したがって、インターネットなどのネットワークへの接続についてのユーザ体験およびユーザの利便性を向上できる。

（ｃ２：固有文字列）
デバイス１００が決定するＩＰアドレス１９０は、本実施の形態に従う処理手順に従って決定されたものであることを特定できるようにしてもよい。このような特定を行うために、例えば、ＩＰアドレス１９０に予め定められた特定用の固有値（固有文字列）を含めるようにしてもよい。すなわち、決定されるＩＰアドレスは、予め定められた特定用の固有値（固有文字列）を含んでいてもよい。

一例として、１６進数表現のＩＰアドレス１９０の先頭２桁（先頭から１桁目および２桁目）を予め定められた固有文字列（例えば、「ＦＣ」）に固定してもよい。通常、ハッシュ関数１８０は一方向性関数であるので、ＩＰアドレス１９０から公開鍵１７４を逆算することはできない。そのため、決定されるＩＰアドレス１９０が所定条件（この場合には、先頭２桁が予め定められた固有値になること）を満たすまで、乱数発生器を用いて、秘密鍵１７２および公開鍵１７４を繰り返し生成してもよい。すなわち、公開鍵１７４は、公開鍵１７４からハッシュ関数に従って算出されるハッシュ値に基づいて決定されるＩＰアドレス１９０が、予め定められたフォーマットに合致するように決定されてもよい。

このように、ＩＰアドレス１９０に予め定められた特定用の固有値（例えば、先頭２桁が「ＦＣ」）を含めることで、第三者は、デバイス１００のＩＰアドレス１９０がデバイス１００自身によって決定されたものであるか否かを判断できる。

（ｃ３：種類特定情報）
デバイス１００が決定するＩＰアドレス１９０には、デバイス１００の種類を特定できる情報を含めてもよい。このような特定を行うために、例えば、ＩＰアドレス１９０にデバイス１００の種類に応じた値を含めるようにしてもよい。すなわち、決定されるＩＰアドレス１９０は、そのＩＰアドレス１９０を決定したデバイス１００の種類に応じた値を含んでいてもよい。

一例として、１６進数表現のＩＰアドレス１９０の先頭から３桁目および４桁目にデバイス１００の種類に応じた値（種類特定情報）を埋め込んでもよい。

図５は、本実施の形態に従うネットワークシステム１で利用されるＩＰアドレスに埋め込まれる種類特定情報の一例を示す図である。図５に示される種類特定情報は、各デバイス１００の制御部１１０のＲＯＭ１０８（図２参照）などに予め格納されていてもよい。一例として、図５に示すようなデバイスの種類に応じた値を用いることができる。

図５に示すように、例えば、デバイス１００の種類がパーソナルコンピュータである場合には、ＩＰアドレス１９０の先頭から３桁目および４桁目には、パーソナルコンピュータを示す値「００」が設定される。

上述したように、通常、ハッシュ関数１８０は一方向性関数であるので、ＩＰアドレス１９０から公開鍵１７４を逆算することはできない。そのため、決定されるＩＰアドレス１９０が所定条件（この場合には、先頭から３桁目および４桁目がデバイス１００の種類を示す値になること）を満たすまで、乱数発生器を用いて、秘密鍵１７２および公開鍵１７４を繰り返し生成してもよい。すなわち、公開鍵１７４は、公開鍵１７４からハッシュ関数に従って算出されるハッシュ値に基づいて決定されるＩＰアドレス１９０が、予め定められたフォーマットに合致するように決定されてもよい。

このように、ＩＰアドレス１９０にデバイス１００の種類を示す値を含めることで、第三者は、デバイス１００が決定したＩＰアドレス１９０から当該デバイス１００の種類を特定できる。

（ｃ４：公開鍵１７４の登録および電子証明書１７６の取得）
次に、公開鍵１７４の登録および電子証明書１７６の取得について説明する。

デバイス１００は、公開鍵１７４の正当性を証明するための電子証明書１７６を認証局２００から取得する。電子証明書１７６を取得する手順としては、デバイス１００から公開鍵１７４を認証局２００へ送信して登録するとともに、登録された公開鍵１７４に関連付けられた電子証明書１７６を認証局２００から取得する。

より具体的には、デバイス１００（制御部１１０）は、ネットワークを介して、公開鍵１７４および電子証明書の発行要求（以下、「証明書署名要求」とも称す。）を認証局２００へ送信する。認証局２００は、デバイス１００から受信した証明書署名要求に応答して、公開鍵１７４を登録するとともに、登録した公開鍵１７４に関連付けられた電子証明書１７６を発行する。そして、認証局２００は、ネットワークを介して、電子証明書１７６をデバイス１００へ送信する。

典型的には、電子証明書１７６は、電子証明書１７６の所有者情報（この例では、デバイス１００）、電子証明書１７６の発行者情報（この例では、認証局２００）、発行者のデジタル署名、および電子証明書１７６の有効期限などを含む。

認証局２００は、所定の組織によって運営されていてもよいし、所定の組織によって運営されているルート認証局に関連付けられた中間認証局であってもよい。また、公開鍵１７４の登録および公開鍵１７４に関連付けられた電子証明書１７６の発行にあたっては、所定の組織に対して所定の手数料および／または維持料が必要であってもよい。

本実施の形態によれば、公開鍵１７４の登録および公開鍵１７４の取得を通じて、公開鍵１７４が認証局２００によって直接的に認証されることで、公開鍵１７４に基づいて決定されるＩＰアドレス１９０も認証局２００によって間接的に認証される。このような認証局２００の認証によって、デバイス１００は、認証済みＩＰアドレス１９０を用いて、ネットワークを介してデータ通信を実現できる。

なお、公開鍵１７４に関連付けられた電子証明書１７６には、秘匿性を向上させるために、デバイス１００の属性に関連する情報（以下、「属性情報」とも称する。）を含んでもよい。デバイス１００の属性情報は、例えば、デバイス１００のＯＳ１６０や通信処理プログラム１７０のバージョン情報、デバイス１００を構成するハードウェア（例えば、プロセッサやストレージなど）のシリアル番号などを用いることができる。この場合、デバイス１００は、公開鍵１７４および証明書署名要求を送信する際に、デバイス１００の属性情報を認証局２００へ送信してもよい。なお、電子証明書１７６に含ませるデバイス１００の属性情報は、公知の不可逆な暗号学的ハッシュ関数などによって暗号化されてもよい。

このように、デバイス１００の属性情報を電子証明書１７６に含ませることで、デバイス１００自身からの証明書署名要求に応答して、電子証明書１７６が発行されたことを認証できる。すなわち、デバイス１００以外のデバイスがデバイス１００になりすまして、デバイス１００の公開鍵１７４および電子証明書１７６を用いることをより確実に防止できる。

（ｃ５：処理手順）
次に、各デバイス１００における認証済みＩＰアドレスを提供するための処理手順について説明する。

図６は、本実施の形態に従うネットワークシステム１においてデバイス１００が認証済みＩＰアドレスを提供する処理手順を示すフローチャートである。図６に示される処理手順は、各デバイス１００においてそれぞれ実行され、図６に示す各ステップは、各デバイス１００の制御部１１０によって実行される。

図６を参照して、デバイス１００は、任意のアルゴリズムに従って生成される鍵ペア（秘密鍵１７２および公開鍵１７４）を取得する（ステップＳ１）。この鍵ペアは、デバイス１００自身が生成してもよいし、デバイス１００が外部から取得してもよい。あるいは、デバイス１００は秘密鍵１７２のみを外部から取得して、公開鍵１７４を内部で生成してもよい。

続いて、デバイス１００は、予め定められたハッシュ関数１８０に公開鍵１７４を入力することでハッシュ値１７８を算出し、その算出されたハッシュ値１７８の全部または一部からデバイス１００のＩＰアドレス１９０を決定する（ステップＳ２）。すなわち、デバイス１００は、ハッシュ関数１８０に従って公開鍵１７４から算出されるハッシュ値１７８に基づいて、自デバイスのＩＰアドレスを決定する。

なお、ＩＰアドレス１９０に固有文字列（例えば、ＩＰアドレス１９０の先頭から１桁目および２桁目）および／または種類特定情報（例えば、ＩＰアドレス１９０の先頭から３桁目および４桁目）が含まれるように、適切な鍵ペア（秘密鍵１７２および公開鍵１７４）が生成されてもよい。

また、デバイス１００は、公開鍵１７４および電子証明書の発行要求（証明書署名要求）を認証局２００へ送信する（ステップＳ３）。認証局２００は、デバイス１００から受信した証明書署名要求に応答して、公開鍵１７４を登録するとともに、登録した公開鍵１７４に関連付けられた電子証明書１７６を発行する。そして、認証局２００は、ネットワークを介して電子証明書１７６をデバイス１００へ送信する。すると、デバイス１００は、認証局２００からの電子証明書１７６を受信して格納する（ステップＳ４）。

このように、デバイス１００は、認証局から公開鍵１７４に関連付けられた電子証明書１７６を取得する。

なお、ステップＳ２の処理と、ステップＳ３およびＳ４の処理との実行順序は問わない。

＜Ｄ．データ通信処理＞
次に、認証済みＩＰアドレスを用いたデバイス１００間のデータ通信処理について説明する。

（ｄ１：ＩＰアドレスの通知）
まず、本実施の形態に従うネットワークシステム１におけるデバイス１００間のＩＰアドレスの通知に係る処理について説明する。

図７および図８は、本実施の形態に従うネットワークシステム１におけるＩＰアドレスの通知に係る処理を説明するための図である。図７および図８には、３つのデバイス１００－１，１００－２，１００－３の間でＩＰアドレスを交換する例を示す。なお、２つのデバイス１００の間でも同様の処理が可能であるし、より多くのデバイス１００の間でも同様の処理が可能である。

図７および図８に示す状態において、デバイス１００－１，１００－２，１００－３の各々は、上述したような手順に従って、デバイス１００－１，１００－２，１００－３は、ＩＰアドレス１９０－１，１９０－２，１９０－３をそれぞれ決定しており、また、認証局２００への公開鍵１７４－１，１７４－２，１７４－３の登録および認証局２００からの電子証明書１７６－１，１７６－２，１７６－３の取得もそれぞれ済んでいるものとする。

図７および図８に示すように、各デバイス１００は、定期的またはイベント毎に、各デバイスが有している公開鍵１７４および公開鍵１７４に関連付けられた電子証明書１７６を送信（ブロードキャスト）する。すなわち、各デバイス１００は、公開鍵１７４および電子証明書１７６を他のデバイスに送信する。なお、公開鍵１７４が電子証明書１７６に含まれる場合には、電子証明書１７６のみを送信するようにしてもよい。

図７には、一例として、デバイス１００－１が公開鍵１７４－１および公開鍵１７４－１に関連付けられた電子証明書１７６－１を送信（ブロードキャスト）する例を示す。図７に示す例では、デバイス１００－２および１００－３がデバイス１００－１により送信された公開鍵１７４－１および電子証明書１７６－１を受信できたとする。すると、デバイス１００－２および１００－３は、電子証明書１７６－１が正当であるか否かを判断した上で、正当であると判断されると、関連付けられた公開鍵１７４－１に基づいてデバイス１００－１のＩＰアドレス１９０－１を決定し、コネクションテーブル１９４－２および１９４－３にそれぞれ登録する。

ここで、コネクションテーブルは、データ通信を行うために各デバイス１００の情報を含むものであり、各デバイス１００は、コネクションテーブルを参照して、宛先のデバイス１００のＩＰアドレスなどを特定するとともに、必要なセッションを確立する。

より具体的には、デバイス１００－２は、まず、デバイス１００－１からブロードキャストされた電子証明書１７６－１が正当であるか否かを判断する。この正当性を判断する処理においては、電子証明書１７６－１の完全性が検証される。

完全性が検証する処理の一例として、まず、デバイス１００－２は、電子証明書１７６－１の所有者情報、電子証明書１７６－１の発行者情報、発行者のデジタル署名の存在を確認する。そして、デバイス１００－２は、電子証明書１７６－１が有効期限内であるか否かを判断する。さらに、デバイス１００－２は、電子証明書１７６－１の発行元が信頼できるものであるか否かを判断する。特に、電子証明書１７６－１が中間認証局により発行されている場合には、デバイス１００－２は、電子証明書１７６－１を発行した中間認証局に関連付けられたルート認証局を特定するとともに、当該特定されたルート認証局が信頼できるものであるか否かを判断する。例えば、特定されたルート認証局がデバイス１００－１に格納されている１または複数のルート認証局のいずれかと一致する場合には、電子証明書１７６－１の発行元が信頼できると判断する。

以上のような判断処理にパスすると、デバイス１００－２は、デバイス１００－１からブロードキャストされた電子証明書１７６－１が正当であると決定する。すると、デバイス１００－２は、予め定められたハッシュ関数１８０に、デバイス１００－１からブロードキャストされた公開鍵１７４－１を入力することでハッシュ値１７８－１を算出し、その算出されたハッシュ値１７８－１の全部または一部を用いて、デバイス１００－１のＩＰアドレス１９０－１を決定する。ここで、デバイス１００－１および１００－２は、共通のハッシュ関数１８０を有しているものとする。また、デバイス１００－１および１００－２の間において、ハッシュ値１７８－１からＩＰアドレス１９０－１を決定する処理も共通であるとする。

以上のような処理によって、デバイス１００－２は、デバイス１００－１のＩＰアドレス１９０－１を決定できる。そして、デバイス１００－２は、決定したデバイス１００－１のＩＰアドレス１９０－１のエントリをコネクションテーブル１９４－２に追加する。なお、ＩＰアドレス１９０－１に関連付けて公開鍵１７４－１を登録してもよい。

また、デバイス１００－３においてもデバイス１００－２と同様の処理が実行され、デバイス１００－３のコネクションテーブル１９４－３には、決定したデバイス１００－１のＩＰアドレス１９０－１のエントリをコネクションテーブル１９４－２に追加する。なお、ＩＰアドレス１９０－１に関連付けて公開鍵１７４－１を登録してもよい。

図７に示すような処理によって、デバイス１００－２およびデバイス１００－３は、デバイス１００－１のＩＰアドレス１９０－１を取得できる。

図８には、一例として、デバイス１００－２が公開鍵１７４－２および公開鍵１７４－２に関連付けられた電子証明書１７６－２を送信（ブロードキャスト）する例を示す。図８に示す例では、デバイス１００－１および１００－３がデバイス１００－２により送信された公開鍵１７４－２および電子証明書１７６－２を受信できたとする。すると、デバイス１００－１および１００－３は、電子証明書１７６－２が正当であるか否かを判断した上で、正当であると判断されると、関連付けられた公開鍵１７４－２に基づいてデバイス１００－２のＩＰアドレス１９０－２を決定し、コネクションテーブル１９４－１および１９４－３にそれぞれ登録する。

デバイス１００－１および１００－３において実行される一連の処理は、図７を参照して説明した処理と同様であるので、詳細な説明は繰り返さない。図８に示すような処理によって、デバイス１００－１およびデバイス１００－３は、デバイス１００－２のＩＰアドレス１９０－２を取得できる。

さらに、デバイス１００－３が公開鍵１７４－３および公開鍵１７４－３に関連付けられた電子証明書１７６－３を送信（ブロードキャスト）してもよい。デバイス１００－１および１００－２がデバイス１００－３により送信された公開鍵１７４－３および電子証明書１７６－３を受信できたとする。すると、デバイス１００－１および１００－２は、電子証明書１７６－３が正当であるか否かを判断した上で、正当であると判断されると、関連付けられた公開鍵１７４－３に基づいてデバイス１００－３のＩＰアドレス１９０－３を決定し、コネクションテーブル１９４－１および１９４－２にそれぞれ登録する。このような処理によって、デバイス１００－１およびデバイス１００－２は、デバイス１００－３のＩＰアドレス１９０－３を取得できる。

図９は、本実施の形態に従うネットワークシステム１におけるＩＰアドレスの通知に係る処理手順を示すシーケンスチャートである。図９には、図７および図８に対応させて、３つのデバイス１００－１，１００－２，１００－３における処理手順を示す。

デバイス１００－１は、公開鍵１７４－１および公開鍵１７４－１に関連付けられた電子証明書１７６－１を送信（ブロードキャスト）する（シーケンスＳＱ１０）。

デバイス１００－２は、デバイス１００－１により送信された公開鍵１７４－１および電子証明書１７６－１を受信すると、電子証明書１７６－１の正当性を判断する（シーケンスＳＱ１１）。電子証明書１７６－１が正当であると判断されると、デバイス１００－２は、公開鍵１７４－１に基づいてデバイス１００－１のＩＰアドレス１９０－１を決定し（シーケンスＳＱ１２）、決定したデバイス１００－１のＩＰアドレス１９０－１をコネクションテーブル１９４－２に登録する（シーケンスＳＱ１３）。

同様に、デバイス１００－３は、デバイス１００－１により送信された公開鍵１７４－１および電子証明書１７６－１を受信すると、電子証明書１７６－１の正当性を判断する（シーケンスＳＱ１４）。電子証明書１７６－１が正当であると判断されると、デバイス１００－３は、公開鍵１７４－１に基づいてデバイス１００－１のＩＰアドレス１９０－１を決定し（シーケンスＳＱ１５）、決定したデバイス１００－１のＩＰアドレス１９０－１をコネクションテーブル１９４－３に登録する（シーケンスＳＱ１６）。

また、デバイス１００－２は、公開鍵１７４－２および公開鍵１７４－２に関連付けられた電子証明書１７６－２を送信（ブロードキャスト）する（シーケンスＳＱ２０）。

デバイス１００－１は、デバイス１００－２により送信された公開鍵１７４－２および電子証明書１７６－２を受信すると、電子証明書１７６－２の正当性を判断する（シーケンスＳＱ２１）。電子証明書１７６－２が正当であると判断されると、デバイス１００－１は、公開鍵１７４－２に基づいてデバイス１００－２のＩＰアドレス１９０－２を決定し（シーケンスＳＱ２２）、決定したデバイス１００－２のＩＰアドレス１９０－２をコネクションテーブル１９４－１に登録する（シーケンスＳＱ２３）。

同様に、デバイス１００－３は、デバイス１００－２により送信された公開鍵１７４－２および電子証明書１７６－２を受信すると、電子証明書１７６－２の正当性を判断する（シーケンスＳＱ２４）。電子証明書１７６－２が正当であると判断されると、デバイス１００－３は、公開鍵１７４－２に基づいてデバイス１００－２のＩＰアドレス１９０－２を決定し（シーケンスＳＱ２５）、決定したデバイス１００－２のＩＰアドレス１９０－２をコネクションテーブル１９４－３に登録する（シーケンスＳＱ２６）。

また、デバイス１００－３は、公開鍵１７４－３および公開鍵１７４－３に関連付けられた電子証明書１７６－３を送信（ブロードキャスト）する（シーケンスＳＱ３０）。

デバイス１００－１は、デバイス１００－３により送信された公開鍵１７４－３および電子証明書１７６－３を受信すると、電子証明書１７６－３の正当性を判断する（シーケンスＳＱ３１）。電子証明書１７６－３が正当であると判断されると、デバイス１００－１は、公開鍵１７４－３に基づいてデバイス１００－３のＩＰアドレス１９０－３を決定し（シーケンスＳＱ３２）、決定したデバイス１００－３のＩＰアドレス１９０－３をコネクションテーブル１９４－１に登録する（シーケンスＳＱ３３）。

同様に、デバイス１００－２は、デバイス１００－３により送信された公開鍵１７４－３および電子証明書１７６－３を受信すると、電子証明書１７６－３の正当性を判断する（シーケンスＳＱ３４）。電子証明書１７６－３が正当であると判断されると、デバイス１００－２は、公開鍵１７４－３に基づいてデバイス１００－３のＩＰアドレス１９０－３を決定し（シーケンスＳＱ３５）、決定したデバイス１００－３のＩＰアドレス１９０－３をコネクションテーブル１９４－２に登録する（シーケンスＳＱ３６）。

なお、シーケンスＳＱ１０～ＳＱ１６の処理と、シーケンスＳＱ２０～ＳＱ２６の処理と、シーケンスＳＱ３０～ＳＱ３６の処理とは、任意の順序あるいは並列的に実行され得る。

このように、各デバイス１００は、他のデバイスから公開鍵１７４および公開鍵１７４に関連付けられた電子証明書１７６を受信すると、電子証明書１７６の正当性を判断する（シーケンスＳＱ１１，ＳＱ１４，ＳＱ２１，ＳＱ２４，ＳＱ３１，ＳＱ３４）。そして、各デバイス１００は、電子証明書１７６が正当であると判断されると、ハッシュ関数に従って公開鍵１７４から算出されるハッシュ値に基づいて、他のデバイスのＩＰアドレスを決定する（シーケンスＳＱ１２，ＳＱ１５，ＳＱ２２，ＳＱ２５，ＳＱ３２，ＳＱ３５）。

上述したように、本実施の形態に従うネットワークシステム１においては、他のデバイス１００から送信された電子証明書１７６が正当であると判断されることを条件に、電子証明書１７６に関連付けられた公開鍵１７４に基づいて、当該他のデバイス１００のＩＰアドレス１９０を決定する。公開鍵１７４に関連付けられた電子証明書１７６が正当であるとの判断を条件に、公開鍵１７４に基づいてＩＰアドレス１９０を決定するので、公開鍵１７４の正当性およびＩＰアドレス１９０の正当性を保証できる。したがって、デバイス１００の間で確実なデータ通信を実現できる。

また、本実施の形態に従うネットワークシステム１においては、各デバイス１００がブロードキャストする公開鍵１７４に基づいて、各デバイス１００のＩＰアドレスを知ることができるので、ＩＰアドレスを管理するサーバが存在しなくても、デバイス１００同士が直接接続し得る。特に、バーチャルプライベートネットワーク（ＶＰＮ）サーバなどが存在しなくても、デバイス１００同士で秘匿性の確保された通信を実現できるため、ＶＰＮサーバを維持するためのコストや消費電力を削減できる。

（ｄ２：応用例）
本実施の形態に従うネットワークシステム１においては、デバイス１００の間でＩＰアドレスを互いに認証することができるので、ＩＰアドレスのみに基づいて、通信先を特定することができる。このような認証済みＩＰアドレスを用いることで、各種のサービスを提供できる。以下、認証済みＩＰアドレスを用いて提供されるサービスの一例について説明する。

図１０は、本実施の形態に従うネットワークシステム１を利用したサービス提供のアプリケーション例を説明するための図である。図１０に示すアプリケーション例においては、Ｗｅｂベースのアプリケーションサーバおよび当該アプリケーションサーバにアクセスするモバイル端末をそれぞれデバイス１００と想定する。アプリケーションサーバは、サクセス元のモバイル端末の認証済みＩＰアドレスに応じて固有のＷｅｂページを提供する。

図１０（ａ）には、アプリケーションサーバが保持するネットワーク管理テーブル２１０の一例を示す。ネットワーク管理テーブル２１０には、過去にアクセスしたことのある、あるいは、アクセスの予定のあるモバイル端末の認証済みＩＰアドレス２１２に関連付けて、初期画面を示す初期画面情報２１４と、好みを示すプリファレンス情報２１６とが規定されている。ネットワーク管理テーブル２１０の内容は、ユーザが手動で更新し、あるいは、ユーザの操作に応じてアプリケーションサーバによって更新してもよい。

アプリケーションサーバは、モバイル端末からのアクセスを受けると、当該モバイル端末に付与されている認証済みＩＰアドレスをキーにして、ネットワーク管理テーブル２１０を参照し、対応する初期画面情報２１４およびプリファレンス情報２１６を決定する。そして、アプリケーションサーバは、決定した初期画面情報２１４およびプリファレンス情報２１６に基づいて、アクセス元のモバイル端末へ提供するＷｅｂページの内容を決定する。

図１０（ｂ）には、一例として、アプリケーションサーバがオンラインバンキングのサービスを提供する場合のＷｅｂ画面例を示す。例えば、認証済みＩＰアドレス１が付与されているモバイル端末のディスプレイに提示されるＷｅｂ画面例２２０Ａには、「振込手続」、「口座残高確認」、「振替手続」といった基本的な口座管理のボタンが配置されている。一方、認証済みＩＰアドレス２が付与されているモバイル端末のディスプレイに提示されるＷｅｂ画面例２２０Ｂには、為替レートの時間的変化を示すチャートとともに、「外貨購入」、「外貨売却」といった外貨に関するボタンが配置されている。

このような初期画面は、例えば、ネットワーク管理テーブル２１０の初期画面情報２１４などを参照することで決定することができる。さらに、ネットワーク管理テーブル２１０のプリファレンス情報２１６などを参照することで、初期画面だけではなく、モバイル端末（すなわち、モバイル端末を操作するユーザ）毎に好みに応じたサービスを提供することができる。

以上のように、Ｗｅｂベースのアプリケーションサーバは、モバイル端末からの要求に応答して、当該モバイル端末の認証済みＩＰアドレスに応じたサービスを提供する。これによって、モバイル端末の認証済みＩＰアドレスに基づいて、アプリケーションサーバへアクセスしたときに提供される初期画面および各種サービス内容をカスタムすることができる。

図１１は、本実施の形態に従うネットワークシステム１を利用したサービス提供の別のアプリケーション例を説明するための図である。図１１に示すアプリケーション例においては、ホテルなどの利用管理サーバおよび当該利用管理サーバにアクセスするモバイル端末をそれぞれデバイス１００と想定する。図１１に示すアプリケーション例においては、モバイル端末を電子的な鍵（利用証）として用いることができる。

図１１（ａ）には、サーバが保持する利用管理テーブル２３０の一例を示す。利用管理テーブル２３０には、予約サイトなどを通じて予約された内容（部屋番号２３４および利用可能時間２３６）が当該予約操作に用いられたモバイル端末に付与されているネットワークアドレス２３２に関連付けて格納されている。

ユーザが自身のモバイル端末を操作して、予約サイトで宿泊予約をすると、サーバは、その宿泊予約に用いられたモバイル端末に付与されているネットワークアドレスとともに、予約内容を利用管理テーブル２３０に追加する。

図１１（ｂ）に示すように、宿泊施設２４０の各部屋の前には、無線通信ユニット２４２が配置されている。宿泊予定のユーザが宿泊予約に用いたモバイル端末をもって、予約した部屋に近付くと、無線通信ユニット２４２はモバイル端末と無線通信を行う。なお、モバイル端末と無線通信ユニット２４２との間の無線通信は、自動的に開始されるようにしてもよいし、ユーザが明示的に操作を行った上で開始されるようにしてもよい。

ユーザが保持するモバイル端末に付与されているネットワークアドレスが、利用管理テーブル２３０のネットワークアドレス２３２のいずれかのエントリと一致すると、対応する部屋番号２３４および利用可能時間２３６に基づいて、サーバは、予約対象の部屋を解錠する。このように、サーバは、モバイル端末からの要求に応答して、当該モバイル端末の認証済みＩＰアドレスに応じたサービスを提供する。

図１１には、典型例として、モバイル端末をホテルといった宿泊施設の各部屋の鍵として使用する構成について例示したが、これに限らず、任意の利用証として用いることができる。例えば、モバイル端末そのものを、アミューズメント施設などの各種施設や、コンサートなどの各種イベントの入場券として使用できる。さらに、モバイル端末そのものを、鉄道や航空機のチケットとして使用することもできる。

本実施の形態に従うネットワークシステム１においては、デバイス１００のＩＰアドレスそのものが認証されているので、既存技術のように、チケットを表示させるためのアプリケーションなどは必要なく、デバイス１００そのものを利用証として利用できる。

このように、本実施の形態に従うネットワークシステム１においては、モバイル端末の認証済みＩＰアドレスを取得できるので、認証処理を実現するためのアプリケーションなどを必要とすることなく、モバイル端末の各々に固有のサービスを提供できる。また、モバイル端末とサーバといった、デバイス間でデータ通信を行うことが、認証済みＩＰアドレスの取得を意味するので、モバイル端末に固有のサービスを提供するのに要する時間などもごく短いものとなり、アプリケーションを利用して認証処理を行う構成に比較して、サービス提供に要する待ち時間などを短縮できる。

（ｄ３：ルーティング）
次に、デバイス１００間のデータ通信に係る処理について説明する。本実施の形態に従うネットワークシステム１においては、各デバイス１００がルーティング機能およびデータ転送機能を有しており、このような機能によって、自立的にデータ通信を行うことができるネットワークを実現できる。

本実施の形態に従うネットワークシステム１が採用するルーティングについて説明する。以下の説明では、典型例として、データは「パケット」の形で送信されるものとする。

図１２は、本実施の形態に従うネットワークシステム１におけるルーティングの一例を説明するための図である。図１２には、一例として、７つのデバイス１００－１～１００－７を含むネットワークにおけるルーティングを説明する。

図１２に示すように、上述したようなＩＰアドレスの通知処理によって、ＩＰアドレスを交換したデバイス１００同士は、コネクション１０を確立できるようになる。コネクション１０を確立できるデバイス１００同士は、一種のピアトゥピア（ｐｅｅｒ－ｔｏ－ｐｅｅｒ）でデータをやり取りする。なお、デバイス１００間のコネクション１０には、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）およびＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を含む、任意のプロトコルを採用できる。

例えば、デバイス１００－１からデバイス１００－７を宛先とする送信パケットが送信される例を考えると、デバイス１００－１でのルーティングにより、デバイス１００－１からデバイス１００－５へ送信パケットが送信され（ルートＲＴ１）、続いてデバイス１００－５でのルーティングにより、デバイス１００－５からデバイス１００－６へ送信パケットが送信され（ルートＲＴ２）、最終的にデバイス１００－６でのルーティングにより、デバイス１００－６からデバイス１００－７へ送信パケットが送信される（ルートＲＴ３）。

本実施の形態に従うネットワークシステム１に含まれるデバイス１００の各々は、図１２に示すようなルーティングを実現するために、以下に示すような機能を有している。

図１３は、本実施の形態に従うネットワークシステム１におけるルーティングの実現方法を説明するための図である。図１３を参照して、本実施の形態に従うネットワークシステム１においては、ネットワークシステム１に含まれる複数のデバイス１００を論理的に１または複数のノードグループ３０（ノードグループ３０－１，３０－２，３０－３，・・・）に分割し、各ノードグループ３０がルーティングテーブル３２（ルーティングテーブル３２－１，３２－２，３２－３，・・・）を共有する。

ノードグループ３０は、論理的に規定されるデバイス１００の集合を意味し、後述するように、各デバイス１００が保持するステート情報４０の内容に基づいて決定される。

ルーティングテーブル３２は、データ送信の宛先（送信パケットの宛先）となるデバイス１００の探索に用いられるテーブルであり、典型的には、分散ハッシュテーブル（Ｄｉｓｔｒｉｂｕｔｅｄ Ｈａｓｈ Ｔａｂｌｅ：ＤＨＴ）を用いて実現できる。ルーティングテーブル３２は、対応するノードグループ３０に含まれるデバイス１００（ノード）を特定するための識別情報およびその位置などを含む。

ノードグループ３０の各々は、ルートノード３４（ルートノード３４－１，３４－２，３４－３，・・・）となるデバイス１００を含む。ルートノード３４には、１または複数のノード３６となるデバイス１００が階層的に論理接続される。

図１４は、本実施の形態に従うネットワークシステム１におけるルーティングの実現方法を説明するための別の図である。

図１４を参照して、ネットワークシステム１に含まれる各デバイス１００は、各デバイス１００の接続関係（論理的および物理的な接続関係）を反映したステート情報４０（ステート情報４０－１，４０－２，４０－３，・・・）を保持している。ステート情報４０は、各デバイス１００と他のデバイスとの接続関係を反映する。

また、各デバイス１００は、保持しているステート情報４０の内容を示すステート通知メッセージ４２を周期的に（例えば、数分毎）周囲に存在する他のデバイス１００へ送信する。各デバイス１００は、他のデバイス１００からのステート通知メッセージ４２に基づいて、自デバイスのステート情報４０を必要に応じて更新する。

図１４には、デバイス１００－１がステート通知メッセージ４２を送信する例を示すが、ネットワークシステム１に含まれる各デバイス１００がそれぞれステート通知メッセージ４２を送信する。各デバイス１００が他のデバイス１００からのステート通知メッセージ４２に基づいてステート情報４０を更新することで、図１３に示すようなツリー構造が論理的に規定される。

なお、いずれのデバイス１００をルートノード３４とするのかについて予め決定する必要はない。各デバイス１００のステート情報４０には、当該デバイスがルートノード３４として動作する場合を示す値が初期設定される。その後に受信される他のデバイスからのステート通知メッセージ４２に基づいて、ステート情報４０が更新されることによって、ルートノード３４として動作すべきデバイス１００と、通常のノード３６として動作すべきデバイス１００とが自律的に決定されることになる。

図１５は、本実施の形態に従うネットワークシステム１におけるルーティングの実現に係る処理手順を示すシーケンスチャートである。図１５には、図１４に示すデバイス１００－１，１００－２，１００－５，１００－４に着目したやり取りを示す。

図１５を参照して、ネットワークシステム１に接続されると、まず、デバイス１００－１，１００－３，１００－５，１００－４の各々は、各自のステート情報４０を初期設定する（シーケンスＳＱ１００）。

そして、デバイス１００－１は、自デバイスのステート情報４０の内容を示すステート通知メッセージ４２を周辺のデバイス１００へ送信する（シーケンスＳＱ１０２）。デバイス１００－１からのステート通知メッセージ４２を受信した各デバイスは、受信したステート通知メッセージ４２に基づいて、自デバイスのステート情報４０に対する更新処理を実行する（シーケンスＳＱ１０４）。

同様に、デバイス１００－２は、自デバイスのステート情報４０の内容を示すステート通知メッセージ４２を周辺のデバイス１００へ送信する（シーケンスＳＱ１０６）。デバイス１００－２からのステート通知メッセージ４２を受信した各デバイスは、受信したステート通知メッセージ４２に基づいて、自デバイスのステート情報４０に対する更新処理を実行する（シーケンスＳＱ１０８）。

同様に、デバイス１００－５は、自デバイスのステート情報４０の内容を示すステート通知メッセージ４２を周辺のデバイス１００へ送信する（シーケンスＳＱ１１０）。デバイス１００－５からのステート通知メッセージ４２を受信した各デバイスは、受信したステート通知メッセージ４２に基づいて、自デバイスのステート情報４０に対する更新処理を実行する（シーケンスＳＱ１１２）。

同様に、デバイス１００－４は、自デバイスのステート情報４０の内容を示すステート通知メッセージ４２を周辺のデバイス１００へ送信する（シーケンスＳＱ１１４）。デバイス１００－４からのステート通知メッセージ４２を受信した各デバイスは、受信したステート通知メッセージ４２に基づいて、自デバイスのステート情報４０に対する更新処理を実行する（シーケンスＳＱ１１６）。

このように、複数のデバイス１００の各々は、各デバイス１００の接続関係を反映したステート情報４０を保持する（シーケンスＳＱ１００）とともに、ステート情報４０の内容を示すステート通知メッセージ４２を他のデバイスへ送信する（シーケンスＳＱ１０２，ＳＱ１０６，ＳＱ１１０，ＳＱ１１４）。また、複数のデバイス１００の各々は、他のデバイスから受信したステート通知メッセージ４２に基づいて各デバイス１００が保持するステート情報４０を更新する（シーケンスＳＱ１０４，ＳＱ１０８，ＳＱ１１２，ＳＱ１１６）。これらの処理は、周期的に実行されてもよい。

なお、シーケンスＳＱ１０２およびＳＱ１０４と、シーケンスＳＱ１０６およびＳＱ１０８と、シーケンスＳＱ１１０およびＳＱ１１２と、シーケンスＳＱ１１４およびＳＱ１１６とは、互いに独立したタイミングで実行され得る。そのため、どのような実行順序であってもよいし、それぞれを並列に実行するようにしてもよい。

各デバイス１００によるステート通知メッセージ４２の送信の結果、ルートノード３４として動作するデバイス１００が決定されると、ルートノード３４として動作するデバイス１００（図１５に示す例では、デバイス１００－１）は、ルーティングテーブル３２を決定する（シーケンスＳＱ１２０）。このように、各デバイス１００が保持するステート情報４０に基づいて論理的に規定されるノードグループ３０（デバイス１００の集合）の間で、当該ノードグループ３０に含まれるデバイス１００の間で保持されるルーティングテーブル３２を決定する処理が実行される。なお、ルーティングテーブル３２は、データ送信の宛先となるデバイスの探索に用いられる。

そして、ルートノード３４として動作するデバイス１００は、決定したルーティングテーブル３２を他の自デバイスの子孫ノードとして動作する他のデバイス１００に送信する（シーケンスＳＱ１２２）。

そして、シーケンスＳＱ１０２～ＳＱ１２０の処理が繰り返される。
説明の便宜上、図１５には、各デバイス１００がステート情報４０を初期設定する例を示すが、実際には、ネットワークシステム１に任意のデバイス１００が新たに加入、ないし、ネットワークシステム１から任意のデバイス１００が離脱するような場合が想定される。このような場合に、ルートノード３４として動作するデバイス１００の変更、あるいは、ルーティングテーブル３２の内容更新などの処理が実行されることになる。

次に、ステート情報４０およびステート通知メッセージ４２の詳細について説明する。本実施の形態に従うネットワークシステム１においては、隣接するデバイス１００間でやり取りされるステート通知メッセージ４２に基づいて、各デバイス１００が自身のステート情報４０を順次更新することで、図１３に示すようなデバイス１００が階層的に接続されたノードグループ３０を論理的に構築する。

図１６は、本実施の形態に従うネットワークシステム１において用いられるステート情報４０およびステート通知メッセージ４２のデータ構造の一例を示す図である。図１６の（ａ）には、ステート情報４０のデータ構造の一例を示し、図１６の（ｂ）には、ステート通知メッセージ４２のデータ構造の一例を示す。

図１６の（ａ）を参照して、ステート情報４０は、設定項目として、ＰａｒｅｎｔＩＤ４０１と、Ｃｈｉｌｄｒｅｎ４０２と、ＲｏｏｔＩＤ４０３と、ｈｅｉｇｈｔ４０４と、２進数表現（Ｂｉｎａｒｙ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）４０５とを含む。

ＰａｒｅｎｔＩＤ４０１には、各デバイス１００の親ノードであるデバイスを特定するための識別情報（典型的には、後述するＫｅｙＩＤ）が格納される。

Ｃｈｉｌｄｒｅｎ４０２には、各デバイス１００の子ノードであるデバイスを特定するための識別情報（典型的には、後述するＫｅｙＩＤ）が格納される。なお、子ノードであるデバイスは、１つだけとは限らないので、Ｃｈｉｌｄｒｅｎ４０２には、１または複数のデバイスがリスト形式で格納される。

ＲｏｏｔＩＤ４０３には、各デバイスが属するノードグループ３０のルートノード３４として動作するデバイス１００を特定するための識別情報（典型的には、後述するＫｅｙＩＤ）が格納される。

ｈｅｉｇｈｔ４０４には、各デバイスが属するノードグループ３０における各デバイスのｈｅｉｇｈｔが格納される。ｈｅｉｇｈｔは、各デバイスが属するノードグループ３０におけるルートノード３４からリーフノードまでのエッジ数の最大値を意味する。すなわち、ｈｅｉｇｈｔの大きさに基づいて、ノードグループ３０におけるルートノード３４からリーフノードまでの深さを決定できる。

２進数表現４０５には、各デバイスが属するノードグループ３０において、探索対象のデバイス（ノード）を特定するための識別情報が格納される。

また、ステート情報４０は、さらなる設定項目として、ｔｉｍｅ ｓｔａｍｐを含んでいてもよい。ｔｉｍｅ ｓｔａｍｐは、例えば、各デバイス１００の更新時刻を示す情報であってもよいし、ステート通知メッセージ４２の時刻を示す情報であってもよい。

各デバイス１００は、自デバイスを特定するためのＫｅｙＩＤと称される識別情報を有している。ＫｅｙＩＤは、ネットワークシステム１においてデバイス１００を一意に特定できる識別情報が用いられる。典型的には、ＫｅｙＩＤは、各デバイス１００が有しているＩＰアドレス、あるいは、ＩＰアドレスからハッシュ関数に基づいて算出されるハッシュ値が用いられてもよい。

図１６の（ｂ）を参照して、ステート通知メッセージ４２は、ステート情報４０の内容を示す。より具体的には、ステート通知メッセージ４２は、ＰａｒｅｎｔＩＤ４２１と、ＲｏｏｔＩＤ４２２と、ｈｅｉｇｈｔ４２３と、ＫｅｙＩＤ４２４とを含む。

ＰａｒｅｎｔＩＤ４２１には、ステート情報４０のＰａｒｅｎｔＩＤ４０１と同じ値が格納される。ＲｏｏｔＩＤ４２２には、ステート情報４０のＲｏｏｔＩＤ４０３と同じ値が格納される。ｈｅｉｇｈｔ４２３には、ステート情報４０のｈｅｉｇｈｔ４０４と同じ値が格納される。ＫｅｙＩＤ４２４には、自デバイスの識別情報であるＫｅｙＩＤが格納される。

このように、ステート情報４０およびステート通知メッセージ４２は、各デバイス１００を特定するための識別情報としてＫｅｙＩＤ（自デバイスの識別情報）を含む。このとき、ＫｅｙＩＤ（自デバイスの識別情報）は、各デバイス１００が決定したＩＰアドレスに基づいて算出される値を採用してもよい。

また、ステート情報４０およびステート通知メッセージ４２は、各デバイス１００のルートノード３４とされているデバイス１００を特定するための識別情報（ＫｅｙＩＤ）を含む。

図１６には、ステート情報４０およびステート通知メッセージ４２がいずれもが初期設定された状態を示す。すなわち、ＰａｒｅｎｔＩＤ４０１には「ｎｕｌｌ」が設定され、ＲｏｏｔＩＤ４０３には、自デバイスのＫｅｙＩＤの値（図１６の例では、ＫｅｙＩＤ１）が設定され、ｈｅｉｇｈｔ４０４には「０」が設定される。

図１６の（ａ）に示されるように初期設定されたステート情報４０は、他のデバイスからのステート情報４０に基づいて適宜更新される。以下、ステート情報４０の更新例について説明する。

図１７は、本実施の形態に従うネットワークシステム１におけるステート通知メッセージ４２によるステート情報４０の更新例を示す図である。図１７には、一例として、図１２に示すネットワークシステム１において、デバイス１００－１，１００－５，１００－６がこの順序でツリー構造を形成する場合におけるステート情報４０の内容が更新される例を示す。

デバイス１００－１，１００－５，１００－６のステート情報４０は、初期設定された後、他のデバイスからのステート通知メッセージ４２に基づいて、順次更新される。この結果、いずれのステート情報４０においても、ＲｏｏｔＩＤ４０３にはデバイス１００－１を示す「ＫｅｙＩＤ１」が格納され、ｈｅｉｇｈｔ４０４にはノードグループにおけるルートノード３４からリーフノードまでのエッジ数の最大値である「２」が格納される。

ステート情報４０の各々におけるＰａｒｅｎｔＩＤ４０１およびＣｈｉｌｄｒｅｎ４０２には、ノード間の接続関係に対応するＫｅｙＩＤが格納される。

２進数表現４０５には、一例として、リーフノードからの距離に応じたビット数の識別情報が格納される。図１７には、一例として、３種類の例（「０」，「０１」「００１」）を示す。２進数表現４０５の値を構成するビット数が多いほどリーフノードから遠いことを意味するようにしてもよい。すなわち、２進数表現４０５として「０」を有するデバイス１００は、対応するリーフノードにより近く、２進数表現４０５として「００１」を有するデバイス１００は、対応するリーフノードからより遠いことを意味する。

図１７に示すような各デバイスのステート情報４０に基づいて、ノードグループのツリー構造が特定され、ルートノード３４として動作するデバイス１００は、特定したツリー構造に基づいて、ルーティングテーブル３２を決定し、同一のノードグループに属する各デバイスに提供する。このような手順によって、ノードグループおよび当該ノードグループのルートノード３４の決定、および、ルートノード３４におけるルーティングテーブル３２の決定を実現できる。

なお、各デバイス１００からのステート通知メッセージ４２の送信タイミングは、各デバイス１００において任意に決定されるので、すべてのデバイスにおいてステート情報４０の更新が完了しているとは限らない。そのため、各デバイス１００は、ステート情報４０を更新するにあたっては、数世代に亘るバージョン管理を行うことが好ましい。すなわち、ステート情報４０の更新前後の内容を両方保持することが好ましい。この場合、ルートノード３４として動作するデバイス１００は、各デバイス１００が保持するステート情報４０のうち、適切なバージョンのステート情報４０に基づいて、ルーティングテーブル３２を決定する。

図１８は、本実施の形態に従うネットワークシステム１におけるルーティングテーブルの決定に係る処理手順を示すフローチャートである。図１８に示すルーティングテーブルの決定に係る処理は、ノードグループ３０の決定およびステート情報４０の更新などの処理を含む。図１８に示す各ステップは、デバイス１００の制御部１１０（図２参照）によって実行される（典型的には、プロセッサおよびメモリが協働することにより実現される）。

図１８を参照して、いずれかのネットワークに接続されると、デバイス１００は、自デバイスのステート情報４０を初期設定する（ステップＳ１００）。

続いて、デバイス１００は、ステート通知メッセージ４２の送信条件が成立したか否かを判断する（ステップＳ１０２）。例えば、前回のステート通知メッセージ４２からの経過時間が予め定められた時間に到達したか否かが判断される。

ステート通知メッセージ４２の送信条件が成立すると（ステップＳ１０２においてＹＥＳ）、デバイス１００は、現在のステート情報４０に基づいてステート通知メッセージ４２を生成し、ステート通知メッセージ４２を他のデバイスへ送信する（ステップＳ１０４）。なお、ステート通知メッセージ４２の送信条件が成立していなければ（ステップＳ１０２においてＮＯ）、ステップＳ１０４の処理はスキップされる。

このように、デバイス１００は、他のデバイスとの接続関係を反映したステート情報４０を保持するとともに、ステート情報４０の内容を示すステート通知メッセージ４２を他のデバイスへ送信する処理を実行する（ステップＳ１００～Ｓ１０４）。

続いて、デバイス１００は、他のデバイスからステート通知メッセージ４２を受信したか否かを判断する（ステップＳ１０６）。他のデバイスからステート通知メッセージ４２を受信していれば（ステップＳ１０６においてＹＥＳ）、デバイス１００は、受信したステート通知メッセージ４２に基づいて、ステート情報４０の更新が必要であるか否かを判断する（ステップＳ１０８）。ステート情報４０の更新が必要であると判断されると（ステップＳ１０８においてＹＥＳ）、デバイス１００は、自デバイスのステート情報４０を更新する（ステップＳ１１０）。ステート情報４０の更新が必要ではないと判断されると（ステップＳ１０８においてＮＯ）、ステップＳ１１０の処理はスキップされる。

このように、デバイス１００は、他のデバイス１００から受信したステート通知メッセージ４２に基づいてステート情報４０を更新する処理を実行する（ステップＳ１０６～Ｓ１１０）。

一方、他のデバイスからステート通知メッセージ４２を受信していなければ（ステップＳ１０６においてＮＯ）、ステップＳ１０８およびＳ１１０の処理はスキップされる。

ここで、ステップＳ１０８およびＳ１１０における処理の詳細について説明する。
図１３に示すようなノードグループ３０は、任意のデバイスをルートノード３４として決定することで、各ツリー構造に含まれるデバイスを決定できる。このようなルートノード３４として動作するデバイス１００は、各デバイス１００のＫｅｙＩＤの値に基づいて決定してもよい。すなわち、ステート情報４０を更新する処理においては、受信したステート通知メッセージ４２に含まれるルートノードとされているデバイス（ＲｏｏｔＩＤ４２２に格納されるＫｅｙＩＤにより特定されるデバイス１００）と、ステート情報４０に含まれるルートノードとされるデバイス（ＲｏｏｔＩＤ４０３に格納されるＫｅｙＩＤにより特定されるデバイス１００）とが一致しない場合には、予め定められた規則に従って、一方のデバイス１００をルートノードと決定する処理が実行される。

本実施の形態においては、予め定められた規則の一例として、ＫｅｙＩＤの大小関係を利用する。例えば、ある範囲のデバイスの間でＫｅｙＩＤが最も小さいデバイスを当該範囲のルートノード３４として決定してもよい。この場合、各デバイス１００は、親ノードに相当する他のデバイスから受信したステート通知メッセージ４２に含まれるＲｏｏｔＩＤ４２２（図１６の（ｂ）参照）を参照して、ステート情報４０の更新要否を判断する。

具体的には、以下の（１）および（２）の条件が成立すると、ステート情報４０の内容が更新される。

（１）ステート情報４０のＲｏｏｔＩＤ４０３の値＞親ノードから受信したステート通知メッセージ４２のＲｏｏｔＩＤ４２２の値
かつ
（２）ステート情報４０のｈｅｉｇｈｔ４０４の値＜親ノードから受信したステート通知メッセージ４２のｈｅｉｇｈｔ４２３の値
ここで、（１）の条件は、親ノードが認識しているルートノード３４のＫｅｙＩＤが、当該デバイスが認識しているルートノード３４のＫｅｙＩＤより小さいことを意味し、（２）の条件は、当該デバイスが認識しているツリー構造より深いツリー構造に親ノードが属していることを意味する。

そして、（１）および（２）の条件が成立すると、該当デバイスは、親ノードにネストされるようにステート情報４０の内容が更新される。より具体的には、以下に示すように、ステート情報４０のＰａｒｅｎｔＩＤ４０１、ＲｏｏｔＩＤ４０３、ｈｅｉｇｈｔ４０４は、親ノードからの受信したステート通知メッセージ４２に含まれる値に更新される。

・ステート情報４０のＰａｒｅｎｔＩＤ４０１←親ノードから受信したステート通知メッセージ４２のＫｅｙＩＤ４２４の値
・ステート情報４０のＲｏｏｔＩＤ４０３←親ノードから受信したステート通知メッセージ４２のＲｏｏｔＩＤ４２２の値
・ステート情報４０のｈｅｉｇｈｔ４０４←親ノードから受信したステート通知メッセージ４２のｈｅｉｇｈｔ４２３の値＋１（ｈｅｉｇｈｔ４２３の値をインクリメント）
なお、ルートノード３４を決定する規則は、どのようなものであってもよく、ある範囲のデバイスの間でＫｅｙＩＤが最も大きいデバイスを当該範囲のルートノード３４として決定してもよいし、ＫｅｙＩＤが任意に設定された値に最も近いデバイスをルートノード３４として決定してもよい。この場合には、上述の（１）の条件を適宜変更すればよい。

続いて、デバイス１００は、他のデバイスから十分な数のステート通知メッセージ４２を受信したか否かを判断する（ステップＳ１１２）。他のデバイスから十分な数のステート通知メッセージ４２を十分に受信していれば（ステップＳ１１２においてＹＥＳ）、以下のように、デバイス１００は、各デバイス１００が保持するステート情報４０に基づいてノードグループ３０（論理的に規定されるデバイス１００の集合）の間で、データ送信の宛先となるデバイスの探索に用いられるルーティングテーブル３２を保持する処理を実行する（Ｓ１１６，Ｓ１１８，Ｓ１２２，Ｓ１２４）。

より具体的には、デバイス１００は、ステート情報４０に基づいて、自デバイスがルートノード３４として動作するか否かを判断する（ステップＳ１１４）。

自デバイスがルートノード３４として動作する場合（ステップＳ１１４においてＹＥＳ）には、デバイス１００は、自デバイスのステート情報４０および他デバイスのステート情報４０に基づいて、ルーティングテーブル３２を決定し（ステップＳ１１６）、決定したルーティングテーブル３２を他のデバイスへ送信する（ステップＳ１１８）。

このように、デバイス１００は、ステート情報４０に基づいて、ノードグループ３０において自デバイス１００がルートノードとして動作すると判断されると、ルーティングテーブル３２を決定する処理を実行する。

一方、自デバイスがルートノード３４としては動作しない場合（ステップＳ１１４においてＮＯ）には、デバイス１００は、自デバイスのステート情報４０をルートノードとして設定されているデバイスへ送信し（ステップＳ１２０）、ルートノードとして動作するデバイスからルーティングテーブル３２を受信したか否かを判断する（ステップＳ１２２）。ルートノードとして動作するデバイスからルーティングテーブル３２を受信すれば（ステップＳ１２２においてＹＥＳ）、デバイス１００は、受信したルーティングテーブル３２を格納する（ステップＳ１２４）。このように、デバイス１００は、他のデバイス１００からルーティングテーブル３２を受信することで、ルーティングテーブル３２を保持する。

なお、ルートノードとして動作するデバイスからルーティングテーブル３２を受信していなければ（ステップＳ１２２においてＮＯ）、ステップＳ１２４の処理はスキップされる。また、他のデバイスから十分な数のステート通知メッセージ４２を十分に受信していなければ（ステップＳ１１２においてＮＯ）、ステップＳ１０２以下の処理が繰り返される。

そして、図１８に示すステップＳ１０２～Ｓ１２４の処理は、繰り返し実行される。
図１９は、本実施の形態に従うネットワークシステム１における各デバイス１００のパケット送受信に係る処理手順を示すフローチャートである。図１９の（ａ）には、自デバイスにおいて送信すべきパケットが発生した場合の処理を示し、図１９の（ｂ）には、他のデバイスからパケットを受信した場合の処理を示す。図１９の（ａ）および図１９の（ｂ）に示す各ステップは、デバイス１００の制御部１１０（図２参照）によって実行される（典型的には、プロセッサおよびメモリが協働することにより実現される）。

図１９の（ａ）を参照して、デバイス１００は、各種アプリケーション３００などによって、他のデバイスを宛先とする送信パケットが与えられたか否かを判断する（ステップＳ２００）。他のデバイスを宛先とする送信パケットが与えられていなければ（ステップＳ２００においてＮＯ）、ステップＳ２００の処理が繰り返される。

一方、他のデバイスを宛先とする送信パケットが与えられると（ステップＳ２００においてＹＥＳ）、デバイス１００は、ルーティングテーブル３２を参照して、宛先のデバイスまでの経路に応じた他のデバイスへ送信パケットを送信する（ステップＳ２０２）。このとき、デバイス１００は、宛先のデバイスが自デバイスの子孫ノードに含まれていれば、当該子孫ノードまでの経路に応じた子ノードに送信パケットを送信する。一方、宛先のデバイスが自デバイスの子孫ノードに含まれていなければ、送信パケットを自デバイスの親ノードに送信する。以上により、送信パケットの送信処理は終了する。

図１９の（ｂ）を参照して、他のデバイスから送信パケットを受信したか否かを判断する（ステップＳ２５０）。他のデバイスから送信パケットを受信していなければ（ステップＳ２５０においてＮＯ）、ステップＳ２５０の処理が繰り返される。

一方、他のデバイスから送信パケットを受信していれば（ステップＳ２５０においてＹＥＳ）、デバイス１００は、受信した送信パケットが自デバイス宛てであるか否かを判断する（ステップＳ２５２）。受信した送信パケットが自デバイス宛てであれば（ステップＳ２５２においてＹＥＳ）、デバイス１００は、当該送信デバイスを受信して、対応するアプリケーション３００へ出力する（ステップＳ２５４）。これで、パケットを受信したときの処理は終了する。

これに対して、受信した送信パケットが自デバイス宛てでなければ（ステップＳ２５２においてＮＯ）、デバイス１００は、ルーティングテーブル３２を参照して、宛先のデバイスまでの経路に応じた他のデバイスへ送信パケットを送信する（ステップＳ２５６）。このルーティングテーブル３２を参照して送信先を決定する処理は、ステップＳ２０２と同様である。これで、パケットを受信したときの処理は終了する。

上述したように、本実施の形態に従うネットワークシステム１においては、ノードグループ（論理的に規定されるデバイス１００の集合）毎にルーティングテーブル３２が決定および共有される。このようにノードグループ毎に共有されるルーティングテーブル３２を採用することで、ネットワークシステム１に含まれる任意のデバイスへデータを送信するにあたって、その伝送経路をより短い時間で決定することができる。

本実施の形態に従うネットワークシステム１においては、ネットワークシステム１に含まれるデバイス１００の各々は、保持しているステート情報４０の内容を示すステート通知メッセージ４２を他のデバイス１００に送信する。そして、デバイス１００の各々は、他のデバイス１００からステート通知メッセージ４２を受信すると、その受信したステート通知メッセージ４２の内容に基づいて、自デバイスが保持しているステート情報４０の内容を適宜更新する。このようなステート通知メッセージ４２およびステート情報４０の更新処理を周期的または定期的に実行することで、ネットワークシステム１におけるデバイス１００の加入・離脱あるいは接続トポロジーの変化などが生じた場合であっても、適切なルーティングテーブル３２を維持できる。

＜Ｅ．利点＞
本実施の形態に従うネットワークシステム１によれば、多数のデバイスが存在するネットワークにおいて、各デバイスが自立してデータ通信を実現できる解決策を提供できる。

今回開示された実施の形態はすべての点で例示であって制限的なものでないと考えられるべきである。本発明の範囲は上記した説明ではなくて請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１ ネットワークシステム、２ ネットワーク、４ アクセスポイント、６ 移動体基地局、１０ コネクション、３０ ノードグループ、３２ ルーティングテーブル、３４ ルートノード、３６ ノード、４０ ステート情報、４２ ステート通知メッセージ、１００ デバイス、１０２ プロセッサ、１０４ 主メモリ、１０６ ストレージ、１０８ ＲＯＭ、１１０ 制御部、１２０ ネットワークインターフェイス、１３０ 表示部、１４０ 入力部、１５０ メディアインターフェイス、１５２ メディア、１６０ ＯＳ、１７０ 通信処理プログラム、１７２ 秘密鍵、１７４ 公開鍵、１７６ 電子証明書、１７８ ハッシュ値、１８０ ハッシュ関数、１９０ ＩＰアドレス、１９４ コネクションテーブル、２００ 認証局、２１０ ネットワーク管理テーブル、２１４ 初期画面情報、２１６ プリファレンス情報、２２０Ａ，２２０Ｂ 画面例、２３０ 利用管理テーブル、２３２ ネットワークアドレス、２３４ 部屋番号、２３６ 利用可能時間、２４０ 宿泊施設、２４２ 無線通信ユニット、３００ アプリケーション、４０５ ２進数表現、ＲＴ１，ＲＴ２，ＲＴ３ ルート。

Claims (18)

1. 複数のデバイスが接続されたネットワークにおけるデータ送信方法であって、
   前記複数のデバイスの各々が、各デバイスが有している公開鍵からハッシュ関数に従って算出されるハッシュ値の全部または一部のみを用いて、各デバイスのネットワークアドレス全体を決定するステップと、
   前記複数のデバイスの各々が、各デバイスの接続関係を反映したステート情報を保持するとともに、前記ステート情報の内容を示す通知メッセージを他のデバイスへ送信するステップと、
   前記複数のデバイスの各々が、他のデバイスから受信した前記通知メッセージに基づいて各デバイスが保持するステート情報を更新するステップと、
   各デバイスが保持する前記ステート情報に基づいて論理的に規定されるデバイスの集合の間で、当該集合に含まれるデバイスの間で保持される、データ送信の宛先となるデバイスの探索に用いられるルーティングテーブルを決定するステップとを備える、データ送信方法。
2. 前記通知メッセージは、各デバイスが決定したネットワークアドレスに基づいて算出される、各デバイスを特定するための識別情報を含む、請求項１に記載のデータ送信方法。
3. 前記複数のデバイスの各々が、各デバイスが有している公開鍵および当該公開鍵に関連付けられた電子証明書を他のデバイスに送信するステップと、
   前記公開鍵および前記電子証明書を受信したデバイスにおいて、ハッシュ関数に従って前記公開鍵から算出されるハッシュ値の全部または一部のみを用いて、前記公開鍵および前記電子証明書の送信元のデバイスのネットワークアドレスを決定するステップとをさらに備える、請求項１または２に記載のデータ送信方法。
4. 前記決定されるネットワークアドレスは、予め定められた特定用の固有値を含む、請求項１～３のいずれか１項に記載のデータ送信方法。
5. 前記決定されるネットワークアドレスは、当該ネットワークアドレスを決定したデバイスの種類に応じた値を含む、請求項１～４のいずれか１項に記載のデータ送信方法。
6. ネットワークに接続されたデバイスでの通信処理方法であって、
   公開鍵からハッシュ関数に従って算出されるハッシュ値の全部または一部のみを用いて、自デバイスのネットワークアドレス全体を決定するステップと、
   他のデバイスとの接続関係を反映したステート情報を保持するとともに、前記ステート情報の内容を示す通知メッセージを他のデバイスへ送信するステップと、
   他のデバイスから受信した前記通知メッセージに基づいて前記ステート情報を更新するステップと、
   各デバイスが保持する前記ステート情報に基づいて論理的に規定されるデバイスの集合の間で、データ送信の宛先となるデバイスの探索に用いられるルーティングテーブルを保持するステップとを備える、通信処理方法。
7. 前記通知メッセージは、前記決定した自デバイスのネットワークアドレスに基づいて算出される、自デバイスを特定するための識別情報を含む、請求項６に記載の通信処理方法。
8. 前記ステート情報に基づいて、前記集合において自デバイスがルートノードとして動作すると判断されると、前記ルーティングテーブルを決定するステップをさらに備える、請求項６または７に記載の通信処理方法。
9. 前記ルーティングテーブルを保持するステップは、他のデバイスから前記ルーティングテーブルを受信するステップを含む、請求項６～８のいずれか１項に記載の通信処理方法。
10. 前記ステート情報および前記通知メッセージは、ルートノードとされているデバイスを特定するための識別情報を含み、
    前記更新するステップは、前記受信した通知メッセージに含まれるルートノードとされているデバイスと、前記ステート情報に含まれるルートノードとされるデバイスとが一致しない場合には、予め定められた規則に従って、一方のデバイスをルートノードと決定するステップを含む、請求項６～９のいずれか１項に記載の通信処理方法。
11. 認証局から前記公開鍵に関連付けられた電子証明書を取得するステップと、
    前記公開鍵および前記電子証明書を他のデバイスに送信するステップとをさらに備える、請求項６～１０のいずれか１項に記載の通信処理方法。
12. 他のデバイスから前記公開鍵および前記公開鍵に関連付けられた電子証明書を受信すると、前記電子証明書の正当性を判断するステップと、
    前記電子証明書が正当であると判断されると、ハッシュ関数に従って前記公開鍵から算出されるハッシュ値の全部または一部のみを用いて、前記他のデバイスのネットワークアドレスを決定するステップとをさらに備える、請求項６～１１のいずれか１項に記載の通信処理方法。
13. 前記決定されるネットワークアドレスは、予め定められた特定用の固有値を含む、請求項６～１２のいずれか１項に記載の通信処理方法。
14. 前記決定されるネットワークアドレスは、当該ネットワークアドレスを決定したデバイスの種類に応じた値を含む、請求項６～１３のいずれか１項に記載の通信処理方法。
15. ネットワークに接続されたデバイスでの通信処理方法であって、
    他のデバイスが有している公開鍵および当該公開鍵に関連付けられた電子証明書を受信するステップと、
    前記電子証明書の正当性を判断するステップと、
    前記電子証明書が正当であると判断されると、前記公開鍵からハッシュ関数に従って算出されるハッシュ値の全部または一部のみを用いて全体が決定されるネットワークアドレスを、前記他のデバイスの認証済みネットワークアドレスとして決定するステップと、
    前記他のデバイスからの要求に応答して、前記他のデバイスの前記認証済みネットワークアドレスに応じたサービスを提供するステップとを備える、通信処理方法。
16. 前記公開鍵は、当該公開鍵から前記ハッシュ関数に従って算出されるハッシュ値の全部または一部のみを用いて決定されるネットワークアドレスが、予め定められたフォーマットに合致するように決定される、請求項１５に記載の通信処理方法。
17. ネットワークに接続するためのネットワークインターフェイスと、
    前記ネットワークインターフェイスに接続された制御部とを備え、
    前記制御部は、
    公開鍵からハッシュ関数に従って算出されるハッシュ値の全部または一部のみを用いて、自デバイスのネットワークアドレス全体を決定する処理と、
    他のデバイスとの接続関係を反映したステート情報を保持するとともに、前記ステート情報の内容を示す通知メッセージを他のデバイスへ送信する処理と、
    他のデバイスから受信した前記通知メッセージに基づいて前記ステート情報を更新する処理と、
    各デバイスが保持する前記ステート情報に基づいて論理的に規定されるデバイスの集合の間で、データ送信の宛先となるデバイスの探索に用いられるルーティングテーブルを保持する処理とを実行する、装置。
18. ネットワークに接続するためのネットワークインターフェイスを有するコンピュータのための通信処理プログラムであって、前記通信処理プログラムは前記コンピュータによって実行されると、前記コンピュータに請求項６～１６のいずれか１項に記載の通信処理方法を実行させる、通信処理プログラム。

Images