特許 7364272 通信方法およびネットワークシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-10-10

(45)【発行日】2023-10-18

(54)【発明の名称】通信方法およびネットワークシステム

(51)【国際特許分類】

   H04L 69/08 20220101AFI20231011BHJP

【ＦＩ】

H04L69/08

【請求項の数】 8

(21)【出願番号】P 2022078019

(22)【出願日】2022-05-11

(62)【分割の表示】P 2020570275の分割

【原出願日】2019-02-06

(65)【公開番号】P2022109301

(43)【公開日】2022-07-27

【審査請求日】2022-06-10

(73)【特許権者】

【識別番号】514318600

【氏名又は名称】コネクトフリー株式会社

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】帝都 久利寿

【審査官】宮島 郁美

(56)【参考文献】

【文献】国際公開第２００５／０９９１７０（ＷＯ，Ａ１）

【文献】特表２０１７－５３７５３８（ＪＰ，Ａ）

【文献】特開２０１５－１９１２２８（ＪＰ，Ａ）

【文献】米国特許出願公開第２００３／００１４６２３（ＵＳ，Ａ１）

【文献】特開２００１－３２０３５９（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１６／０１４９８９９（ＵＳ，Ａ１）

【文献】米国特許出願公開第２００６／０１８４７８９（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ１２／００－１３／１８，４１／００－４９／９０５７，６１／００－６５／８０，６９／００－６９／４０

(57)【特許請求の範囲】

【請求項1】

複数のデバイスが接続されたネットワークにおける通信方法であって、
第１のデバイスにおいて、認証済みＩＰアドレスを有している第２のデバイスを宛先とする第１の暗号化パケットを生成するステップと、
前記第１の暗号化パケットを前記第１のデバイスから前記第２のデバイスまでＰ２Ｐ（ｐｅｅｒ ｔｏ ｐｅｅｒ）で転送するステップと、
前記第１のデバイスにおいて、認証済みＩＰアドレスを有していない第３のデバイスを宛先とするパケットを暗号化して第２の暗号化パケットを生成するステップと、
前記第２の暗号化パケットを第１のデバイスから認証済みＩＰアドレスを有している第４のデバイスまでＰ２Ｐで転送するステップと、
前記第４のデバイスにおいて、前記第２の暗号化パケットを復号して生成したパケットを、前記第３のデバイスに送信するステップとを備える、通信方法。

【請求項2】

前記第４のデバイスにおいて、前記第３のデバイスからの応答パケットを受信して、前記第１のデバイスを宛先とする第３の暗号化パケットを生成するステップとをさらに備え、前記第３の暗号化パケットは、前記応答パケットを含み、
前記第３の暗号化パケットを前記第３のデバイスから前記第１のデバイスまでＰ２Ｐで転送するステップをさらに備える、請求項１に記載の通信方法。

【請求項3】

前記第１のデバイスから前記第４のデバイスに対してプロキシ動作を有効化するための要求を送信するステップをさらに備える、請求項１または２に記載の通信方法。

【請求項4】

前記第２の暗号化パケットは、前記第４のデバイスに対する要求を含む、請求項１～３のいずれか１項に記載の通信方法。

【請求項5】

前記第１のデバイス、前記第２のデバイス、および前記第３のデバイスの各々において、ハッシュ関数に従って公開鍵から算出されるハッシュ値に基づいて、当該公開鍵に関連付けられるデバイスの認証済みＩＰアドレスを取得するステップをさらに備える、請求項１～４のいずれか１項に記載の通信方法。

【請求項6】

前記第１のデバイス、前記第２のデバイス、および前記第３のデバイスの各々において、前記公開鍵に関連付けられる電子証明書を取得するステップをさらに備える、請求項５に記載の通信方法。

【請求項7】

複数のデバイスが接続されたネットワークシステムであって、
認証済みＩＰアドレスを有している第１のデバイス、第２のデバイスおよび第３のデバイスと、
認証済みＩＰアドレスを有していない第４のデバイスとを備え、
前記第１のデバイスは、
前記第２のデバイスを宛先とする第１の暗号化パケットを生成し、
前記第１の暗号化パケットを前記第２のデバイスまでＰ２Ｐ（ｐｅｅｒ ｔｏ ｐｅｅｒ）で転送し、
前記第４のデバイスを宛先とするパケットを暗号化して第２の暗号化パケットを生成し、
前記第２の暗号化パケットを前記第３のデバイスまでＰ２Ｐで転送し、
前記第３のデバイスは、前記第２の暗号化パケットを復号して生成したパケットを、前記第４のデバイスに送信する、ネットワークシステム。

【請求項8】

前記第３のデバイスは、
前記第４のデバイスからの応答パケットを受信して、前記第１のデバイスを宛先とする第３の暗号化パケットを生成し、
前記第３の暗号化パケットを前記第１のデバイスまでＰ２Ｐで転送する、請求項７に記載のネットワークシステム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

通常、ネットワーク上では、各デバイスに静的または動的に割り当てられたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを用いて、デバイス間のデータ通信が実現される。例えば、特開２０１８－２０７４７２号公報（特許文献１）は、ネットワークアドレス自体の認証という新たなコンセプトを用いたネットワークシステムを開示する。このネットワークシステムによれば、認証済みＩＰアドレスを用いてデバイス間でセキュアな通信などを実現できる。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１８－２０７４７２号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

上記特許文献１によれば、このような認証済みＩＰアドレスを用いてセキュアな通信を実現するというコンセプトを既存のネットワークに適用する場合を想定すると、デバイスは、認証済みＩＰアドレスを有するデバイスと通信するだけではなく、通常のＩＰアドレス（すなわち、割り当てられたＩＰアドレスは認証されたものではない）のみを有するデバイスとの間で通信する必要もある。

【0006】

本開示は、宛先のデバイスが暗号化パケットをやり取り可能ではないデバイスを含むネットワークにおける一つの解決策を提供する。

【課題を解決するための手段】

【0007】

本開示のある形態によれば、複数のデバイスが接続されたネットワークにおけるデータ送信方法が提供される。データ送信方法は、第１のデバイスにおいて、第２のデバイスを宛先とする第１の暗号化パケットを生成するステップと、第１の暗号化パケットを第１のデバイスから第２のデバイスまでＰ２Ｐ（ｐｅｅｒ ｔｏ ｐｅｅｒ）で転送するステップと、第１のデバイスにおいて、第１のデバイスのプロキシサーバとなる第３のデバイスを宛先とする第２の暗号化パケットを生成するステップとを含む。第２の暗号化パケットは、第４のデバイスを宛先とするパケットを含む。データ送信方法は、第２の暗号化パケットを第１のデバイスから第３のデバイスまでＰ２Ｐで転送するステップと、第３のデバイスにおいて、第２の暗号化パケットを復号して生成した通常パケットを、第４のデバイスに送信するステップとを含む。

【0008】

データ送信方法は、第３のデバイスにおいて、第４のデバイスからの応答パケットを受信して、第１のデバイスを宛先とする第３の暗号化パケットを生成するステップをさらに含んでいてもよい。第３の暗号化パケットは、応答パケットを含んでいてもよい。データ送信方法は、第３の暗号化パケットを第３のデバイスから第１のデバイスまでＰ２Ｐで転送するステップをさらに含んでいてもよい。

【0009】

データ送信方法は、第１のデバイスから第３のデバイスに対してプロキシ動作を有効化するための要求を送信するステップをさらに含んでいてもよい。

【0010】

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

【0011】

本開示の別の形態によれば、ネットワークに接続されたデバイスでの通信処理方法が提供される。通信処理方法は、パケットの送信要求に応答して、宛先のデバイスが暗号化パケットをやり取り可能であるか否かを判断するステップと、宛先のデバイスが暗号化パケットをやり取り可能であれば、パケットの送信要求に従って宛先のデバイスに向けた第１の暗号化パケットを生成するステップと、第１の暗号化パケットを宛先のデバイスまでＰ２Ｐで転送するステップと、宛先のデバイスが暗号化パケットをやり取り可能でなければ、パケットの送信要求に従って、宛先のデバイスに向けたパケットを含む第２の暗号化パケットを生成するステップと、第２の暗号化パケットをプロキシサーバとなるデバイスまでＰ２Ｐで転送するステップとを含む。

【0012】

通信処理方法は、プロキシサーバとなるデバイスを特定するステップと、特定したデバイスに対してプロキシ動作を有効化するための要求を送信するステップとをさらに含んでいてもよい。

【0013】

通信処理方法は、秘密鍵および公開鍵を取得するステップと、ハッシュ関数に従って公開鍵から算出されるハッシュ値に基づいて、自デバイスのＩＰアドレスを決定するステップと、ネットワークに接続される認証局から公開鍵に関連付けられた電子証明書を取得するステップと、公開鍵および電子証明書を他のデバイスに送信するステップとをさらに含むようにしてもよい。

【0014】

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

【0015】

本開示のさらに別の形態に従う装置は、ネットワークに接続するためのネットワークインターフェイスと、ネットワークインターフェイスに接続された制御部とを含む。制御部は、パケットの送信要求に応答して、宛先のデバイスが暗号化パケットをやり取り可能であるか否かを判断する処理と、宛先のデバイスが暗号化パケットをやり取り可能であれば、パケットの送信要求に従って宛先のデバイスに向けた第１の暗号化パケットを生成する処理と、第１の暗号化パケットを宛先のデバイスまでＰ２Ｐで転送する処理と、宛先のデバイスが暗号化パケットをやり取り可能であれば、パケットの送信要求に従って、宛先のデバイスに向けたパケットを含む第２の暗号化パケットを生成する処理と、第２の暗号化パケットをプロキシサーバとなるデバイスまでＰ２Ｐで転送する処理とを、実行可能に構成される。

【0016】

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

【発明の効果】

【0017】

本開示によれば、宛先のデバイスが暗号化パケットをやり取り可能ではないデバイスを含むネットワークにおいても、処理の親和性を維持しつつ、セキュアレベルも維持できる。

【図面の簡単な説明】

【0018】

【図1】本実施の形態に従うネットワークシステムの全体構成の一例を示す模式図である。

【図2】本実施の形態に従うデバイスのハードウェア構成例を示す模式図である。

【図3】本実施の形態に従うデバイスのプログラムおよびデータの構成例を示す模式図である。

【図4】本実施の形態に従うネットワークシステムにおけるＩＰアドレスの認証手順を説明するための図である。

【図5】本実施の形態に従うネットワークシステムで利用されるＩＰアドレスに埋め込まれる種類特定情報の一例を示す図である。

【図6】本実施の形態に従うネットワークシステムにおいてデバイスが認証済みＩＰアドレスを提供する処理手順を示すフローチャートである。

【図7】本実施の形態に従うネットワークシステムにおけるＩＰアドレスの通知に係る処理を説明するための図である。

【図8】本実施の形態に従うネットワークシステムにおけるＩＰアドレスの通知に係る処理を説明するための図である。

【図9】本実施の形態に従うネットワークシステムにおけるＩＰアドレスの通知に係る処理手順を示すシーケンスチャートである。

【図10】本実施の形態に従うネットワークシステムのネットワーク構成の一例を示す模式図である。

【図11】本実施の形態に従うネットワークシステムにおける認証済みＩＰアドレスを有するデバイス間のデータ通信の手順を示すシーケンス図である。

【図12】本実施の形態に従うネットワークシステムにおける認証済みＩＰアドレスを有するデバイス間のデータ通信の手順を示すシーケンス図である。

【図13】本実施の形態に従うデバイスがパケットをやり取りする処理手順を示すフローチャートである。

【図14】本実施の形態に従うプロキシサーバがパケットをやり取りする処理手順を示すフローチャートである。

【発明を実施するための形態】

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

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

【0076】

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

【0077】

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

【0078】

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

【0079】

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

【0080】

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

【0081】

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

【0082】

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

【0083】

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

【0084】

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

【0085】

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

【0086】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

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

【0093】

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

【0094】

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

【0095】

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

【0096】

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

【0097】

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

【0098】

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

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

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

【0107】

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

【0108】

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

【0109】

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

【0110】

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

【0111】

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

【0112】

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

【0113】

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

【0114】

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

【0115】

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

【0116】

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

【0117】

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

【0118】

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

【0119】

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

【0120】

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

【0121】

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

【0122】

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

【0123】

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

【0124】

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

【0125】

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

【0126】

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

【0127】

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

【0128】

＜Ｅ．データ通信処理＞
次に、本実施の形態に従うネットワークシステム１におけるデータ通信処理について説明する。

【0129】

（ｅ１：背景）
本実施の形態に従うネットワークシステム１において、デバイス１００間は、いわゆるＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ：ピア・トゥ・ピア）によりデータをやり取りする。また、各デバイス１００は、ルーティング機能およびデータ転送機能を有しており、宛先のデバイスに到達するまでＰ２Ｐでのデータ転送が繰り返される。このような機能によって、自立的にデータ通信を行うことができるネットワークを実現できる。

【0130】

Ｐ２Ｐで通信されるデータ（典型的には、パケットまたはフレーム）は、各Ｐ２Ｐに関与するデバイス１００間に設定される暗号鍵により暗号化されるので、セキュアなデータ通信を実現できる。以下の説明では、典型例として、データは「パケット」の形で送信されるものとする。

【0131】

図１０は、本実施の形態に従うネットワークシステム１のネットワーク構成の一例を示す模式図である。図１０に示すネットワークシステム１は、アクセスポイント４を含むローカルライン１０と、インターネット２０と、制限ネットワーク３０とを含む。ローカルライン１０とインターネット２０との間には、ゲートウェイとしても機能するプロキシサーバ２２が配置されている。ローカルライン１０と制限ネットワーク３０との間には、ゲートウェイとしても機能する中継サーバ３２が配置されている。

【0132】

インターネット２０には、各種ネットワークサービスを提供する１または複数のサーバ２４が存在する。制限ネットワーク３０は、例えば、特定の企業や組織に属するデバイス１００（あるいは、ユーザ）のみがアクセス可能な、インターネット２０からは完全または部分的に隔離されたネットワークである。制限ネットワーク３０には、各種ネットワークサービスを提供する１または複数のサーバ３４が存在する。ここで、各種ネットワークサービスとしては、例えば、Ｗｅｂ、メール、データベースなどを含む。なお、プロキシサーバ２２および中継サーバ３２もネットワークサービスを提供するサーバとみなすこともできる。

【0133】

一例として、図１０に示すネットワークシステム１において、デバイス１００、プロキシサーバ２２、中継サーバ３２、およびサーバ３４は、いずれも認証済みＩＰアドレスを有するデバイスに相当する。すなわち、これらのデバイスは、上述したような認証済みＩＰアドレスを用いたデータ通信が可能になっている。これに対して、インターネット２０上の１または複数のサーバ２４は、通常のＩＰアドレス（すなわち、割り当てられたＩＰアドレスは認証されたものではない）のみを有するデバイスであるとする。

【0134】

既存のネットワークを想定すると、図１０に示されるように、認証済みＩＰアドレスを用いたデータ通信に対応してないデバイスとの間でやり取りされるデータも存在し得る。そこで、本実施の形態に従うデバイス１００は、以下のような機能を実装することで、証済みＩＰアドレスを用いたデータ通信に対応するデバイスだけではなく、認証済みＩＰアドレスを有しておらず、あるいは、認証済みＩＰアドレスを用いたデータ通信に対応していないデバイスとの間でもデータをやり取りすることもできる。

【0135】

（ｅ２：認証済みＩＰアドレスを有するデバイス間のデータ通信）
まず、認証済みＩＰアドレスを有するデバイス間のデータ通信について説明する。一例として、図１０に示すネットワークシステム１において、デバイス１００とサーバ３４との間のデータ通信を説明する。

【0136】

図１１は、本実施の形態に従うネットワークシステム１における認証済みＩＰアドレスを有するデバイス間のデータ通信の手順を示すシーケンス図である。図１１には、複数のデバイスが接続されたネットワークにおけるデータ送信方法が示されている。図１１には、デバイス１００からサーバ３４に対して任意の要求が送信され、サーバ３４がその要求に従って処理を実行した結果を、デバイス１００に応答する場合を示す。なお、図１０には、図１１に示す主要な処理に対応するシーケンス番号と同じシーケンス番号を記載している。

【0137】

図１１を参照して、デバイス１００は、サーバ３４に対する要求を含む暗号化パケットを生成する（シーケンスＳＱ１００）。デバイス１００とサーバ３４との間には、予めセッションが確立されており、その確立されたセッションにおいて取り決められた暗号化方式に従って、デバイス１００からサーバ３４宛てのパケットが暗号化される。この生成される暗号化パケットは、サーバ３４を宛先とするものとなる。

【0138】

続いて、デバイス１００は、中継サーバ３２との間でセッションを確立し、Ｐ２Ｐで暗号化パケットを送信する（シーケンスＳＱ１０２）。すなわち、生成された暗号化パケットをデバイス１００からサーバ３４までＰ２Ｐで転送する処理が実行される。Ｐ２Ｐでの送信において、暗号化パケットをさらに暗号化するようにしてもよい。この場合には、デバイス１００と中継サーバ３２との間で確立されたセッションにおいて取り決められた暗号化方式に従うことになる。

【0139】

中継サーバ３２は、デバイス１００から受信した暗号化パケットをさらにサーバ３４へ転送する。すなわち、中継サーバ３２は、サーバ３４との間でセッションを確立し、Ｐ２Ｐで暗号化パケットを送信する（シーケンスＳＱ１０４）。なお、Ｐ２Ｐでの送信において、暗号化パケットをさらに暗号化するようにしてもよい。

【0140】

サーバ３４は、中継サーバ３２から受信した暗号化パケットが自デバイス宛てであることを判断し、暗号化パケットを復号する（シーケンスＳＱ１０６）。そして、サーバ３４は、暗号化パケットの復号結果に含まれる要求に従って、処理を実行する（シーケンスＳＱ１０８）。サーバ３４は、処理の実行結果を含む暗号化パケットを生成する（シーケンスＳＱ１１０）。サーバ３４は、Ｐ２Ｐで暗号化パケットを中継サーバ３２に送信する（シーケンスＳＱ１１２）。中継サーバ３２は、サーバ３４から受信した暗号化パケットをさらにデバイス１００に転送する。すなわち、中継サーバ３２は、Ｐ２Ｐで暗号化パケットをデバイス１００に送信する（シーケンスＳＱ１１４）。

【0141】

デバイス１００は、中継サーバ３２から受信した暗号化パケットが自デバイス宛てであることを判断し、暗号化パケットを復号する（シーケンスＳＱ１１６）。そして、デバイス１００は、暗号化パケットの復号結果に含まれる処理の実行結果を用いて、結果表示などの処理を実行する（シーケンスＳＱ１１８）。

【0142】

以上のとおり、認証済みＩＰアドレスを有するデバイス間においては、暗号化パケットがＰ２Ｐで順次転送されることで、データがセキュアにやり取りされることになる。

【0143】

（ｅ３：認証済みＩＰアドレスに非対応のデバイスとのデータ通信）
次に、認証済みＩＰアドレスに非対応のデバイスとのデータ通信について説明する。一例として、図１０に示すネットワークシステム１において、デバイス１００とサーバ２４との間のデータ通信を説明する。

【0144】

図１２は、本実施の形態に従うネットワークシステム１における認証済みＩＰアドレスを有するデバイス間のデータ通信の手順を示すシーケンス図である。図１２には、デバイス１００からサーバ２４に対して任意の要求が送信され、サーバ２４がその要求に従って処理を実行した結果を、デバイス１００に応答する場合を示す。このとき、プロキシサーバ２２がデバイス１００とサーバ２４との間のプロキシサーバとなる。なお、図１０には、図１２に示す主要な処理に対応するシーケンス番号と同じシーケンス番号を記載している。

【0145】

以下の説明においては、典型例として、プロキシサーバ２２のプロキシ動作のみ着目して説明するが、プロキシ動作と全く同一の処理を実装する必要はなく、プロキシ動作に係る処理と類似した処理を採用してもよい。また、プロキシ動作だけに限らず、例えば、ウィルスチェック機能やフィルタリング機能などを含めるようにしてもよい。

【0146】

図１２を参照して、デバイス１００は、任意のアプリケーションなどから予め定められた条件を満たすパケットを与えられると、プロキシサーバ２２に対して、プロキシ動作要求を送信する（シーケンスＳＱ２００）。予め定められた条件は、例えば、認証済みＩＰアドレスを用いたデータ通信に対応していないデバイスを宛先とするパケットが与えられたことなどを含む。プロキシ動作要求を受けて、プロキシサーバ２２は、デバイス１００についてのプロキシ動作を有効化する。このように、デバイス１００からプロキシサーバ２２に対してプロキシ動作を有効化するための要求を送信する処理が実行される。

【0147】

プロキシ動作要求についても、デバイス１００からプロキシサーバ２２にＰ２Ｐで送信されてもよい。さらに、Ｐ２Ｐで送信されるプロキシ動作要求を暗号化してもよい。

【0148】

プロキシサーバ２２およびデバイス１００からのプロキシ動作要求は、公知のプロコトルを用いて実装してもよい。より具体的には、ＳＯＣＫＳ（ＳＯＣＫＳ４，ＳＯＣＫＳ４ａ，ＳＯＣＫＳ５）などのプロトコルを用いることができる。

【0149】

続いて、デバイス１００は、サーバ３４に対する要求を含む暗号化パケットを生成する（シーケンスＳＱ２０２）。デバイス１００とプロキシサーバ２２との間には、予めセッションが確立されており、その確立されたセッションにおいて取り決められた暗号化方式に従って、デバイス１００からプロキシサーバ２２宛てのパケットが暗号化される。この生成される暗号化パケットは、プロキシサーバ２２を宛先とするものとなるが、サーバ３４を宛先とするパケットをも含む。

【0150】

続いて、デバイス１００は、Ｐ２Ｐで暗号化パケットをプロキシサーバ２２に送信する（シーケンスＳＱ２０４）。すなわち、生成された暗号化パケットをデバイス１００からプロキシサーバ２２までＰ２Ｐで転送する処理が実行される。Ｐ２Ｐでの送信において、暗号化パケットをさらに暗号化するようにしてもよい。この場合には、デバイス１００とプロキシサーバ２２との間で確立されたセッションにおいて取り決められた暗号化方式に従うことになる。

【0151】

プロキシサーバ２２は、デバイス１００から受信した暗号化パケットを一旦復号する（シーケンスＳＱ２０６）。これは、プロキシサーバ２２より先の経路においては、ＩＰアドレスを用いた通常の通信プロコトルが利用されることになるからである。そして、サーバ３４は、暗号化パケットの復号結果に含まれる要求に従って、デバイス１００の代理としてサーバ２４とデータ通信を行う。すなわち、プロキシサーバ２２は、暗号化パケットの復号結果に含まれる要求を含む通常パケットを生成する（シーケンスＳＱ２０８）。そして、プロキシサーバ２２は、生成した通常パケットをサーバ２４に送信する（シーケンスＳＱ２１０）。このように、プロキシサーバ２２において、暗号化パケットを復号して生成した通常パケットを、サーバ２４に送信する処理が実行される。

【0152】

なお、プロキシサーバ２２は、通常パケットを生成する際に、デバイス１００からのパケットに含まれるヘッダ情報などを適宜変更してもよい。

【0153】

そして、プロキシサーバ２２は、生成した通常パケットをサーバ２４に送信する（シーケンスＳＱ２１０）。この通常パケットの送信は、必ずしもＰ２Ｐでなくてもよく、通常のＴＣＰ／ＩＰやＵＤＰ／ＩＰなどに従って、適宜パケットを転送するようにしてもよい。

【0154】

サーバ２４は、プロキシサーバ２２から通常パケットを受信すると、当該通常パケットに含まれる要求に従って、処理を実行する（シーケンスＳＱ２１２）。そして、サーバ２４は、処理の実行結果を含む通常パケット（応答パケット）をプロキシサーバ２２に送信する（シーケンスＳＱ２１４）。

【0155】

プロキシサーバ２２は、サーバ２４からの応答パケットを受信して、受信した通常パケットを含む暗号化パケットを生成する（シーケンスＳＱ２１６）。この生成される暗号化パケットは、デバイス１００を宛先とするものとなる。そして、プロキシサーバ２２は、生成した暗号化パケットをＰ２Ｐでデバイス１００に送信する（シーケンスＳＱ２１８）。このように、暗号化パケットをプロキシサーバ２２からデバイス１００までＰ２Ｐで転送る処理が実行される。

【0156】

デバイス１００は、プロキシサーバ２２から受信した暗号化パケットが自デバイス宛てであることを判断し、暗号化パケットを復号する（シーケンスＳＱ２２０）。そして、デバイス１００は、暗号化パケットの復号結果に含まれる処理の実行結果を用いて、結果表示などの処理を実行する（シーケンスＳＱ２２２）。

【0157】

以上のとおり、認証済みＩＰアドレスを有するデバイス間においては、暗号化パケットがＰ２Ｐで順次転送されることで、データがセキュアにやり取りされることになる。一方、認証済みＩＰアドレスに非対応のデバイスとのデータのやり取りにおいては、プロキシサーバ２２が代理応答することで、任意のデバイスとの間でデータをやり取りできる。

【0158】

（ｅ４：処理手順）
次に、デバイス１００における処理手順およびプロキシサーバ２２における処理手順について説明する。

【0159】

図１３は、本実施の形態に従うデバイス１００がパケットをやり取りする処理手順を示すフローチャートである。図１３には、ネットワークに接続されたデバイス１００での通信処理方法の一例を示す。図１３に示す各ステップは、デバイス１００の制御部１１０（図２参照）によって実行される（典型的には、プロセッサおよびメモリが協働することにより実現される）。

【0160】

図１３を参照して、デバイス１００上で実行される任意のアプリケーション３００などから、他のデバイスを宛先とするパケットの送信要求が与えられたか否かを判断する（ステップＳ１００）。他のデバイスを宛先とするパケットの送信要求が与えられていなければ（ステップＳ１００においてＮＯ）、ステップＳ１５０以下の処理が実行される。

【0161】

これに対して、他のデバイスを宛先とするパケットの送信要求が与えられると（ステップＳ１００においてＹＥＳ）、デバイス１００は、宛先のデバイスが認証済みＩＰアドレスを用いたデータ通信に対応したデバイスであるか否かを判断する（ステップＳ１０２）。認証済みＩＰアドレスを用いたデータ通信に対応したデバイスであるか否かの判断は、宛先のデバイスが暗号化パケットをやり取り可能であるか否かを判断することを意味する。

【0162】

ステップＳ１０２においては、例えば、宛先デバイスのＩＰアドレスが図５に示すような値になっているか否かなどに基づいて判断してもよい。あるいは、デバイス１００が予め保持するリストに登録されてＩＰアドレスと一致する場合に限って、認証済みＩＰアドレスを用いたデータ通信に対応するものと判断し、それ以外については、対応しないと判断するようにしてもよい。

【0163】

宛先のデバイスが認証済みＩＰアドレスを用いたデータ通信に対応したデバイスであれば（ステップＳ１０２においてＹＥＳ）、デバイス１００は、宛先のデバイスとのセッションにおいて取り決められた暗号化方式に従って、指定された他のデバイスを宛先とする暗号化パケットを生成する（ステップＳ１０４）。すなわち、デバイス１００は、宛先のデバイスが暗号化パケットをやり取り可能であれば、パケットの送信要求に従って宛先のデバイスに向けた暗号化パケットを生成する。続いて、デバイス１００は、隣接するデバイスに生成した暗号化パケットをＰ２Ｐで送信する（ステップＳ１０６）。最終的に、暗号化パケットは、宛先のデバイスまでＰ２Ｐで転送される。そして、ステップＳ１５０以下の処理が実行される。

【0164】

これに対して、宛先のデバイスが認証済みＩＰアドレスを用いたデータ通信に対応したデバイスでなければ（ステップＳ１０２においてＮＯ）、デバイス１００は、デバイス１００のプロキシサーバとなるプロキシサーバ２２を特定する（ステップＳ１０８）。このプロキシサーバ２２の特定は、典型的には、ＩＰアドレスを用いて行われる。

【0165】

そして、デバイス１００は、特定したプロキシサーバ２２に対してプロキシ動作要求を送信済であるか否かを判断する（ステップＳ１１０）。特定したプロキシサーバ２２に対してプロキシ動作要求を送信済でなければ（ステップＳ１１０においてＮＯ）、デバイス１００は、特定したプロキシサーバ２２に対してプロキシ動作要求を送信する（ステップＳ１１２）。プロキシ動作要求は、プロキシ動作を有効化するための要求に相当する。特定したプロキシサーバ２２に対してプロキシ動作要求を送信済であれば（ステップＳ１１０においてＹＥＳ）、ステップＳ１１２の処理はスキップされる。

【0166】

続いて、デバイス１００は、指定された他のデバイスを宛先とする通常パケットを生成し（ステップＳ１１４）、さらに、特定したプロキシサーバ２２とのセッションにおいて取り決められた暗号化方式に従って、生成した通常パケットを含む、特定したプロキシサーバ２２を宛先とする暗号化パケットを生成する（ステップＳ１１６）。すなわち、デバイス１００は、宛先のデバイスが暗号化パケットをやり取り可能でなければ、パケットの送信要求に従って宛先のデバイスに向けたパケットを含む暗号化パケットを生成する。続いて、デバイス１００は、隣接するデバイスに生成した暗号化パケットをＰ２Ｐで送信する（ステップＳ１０６）。最終的に、暗号化パケットは、デバイス１００のプロキシサーバとなるプロキシサーバ２２までＰ２Ｐで転送される。そして、ステップＳ１５０以下の処理が実行される。

【0167】

ステップＳ１００～Ｓ１１６の処理は、パケット送信に係る処理に相当する。ステップＳ１５０以下の処理は、パケット受信に係る処理に相当する。

【0168】

ステップＳ１５０において、デバイス１００は、他のデバイスから暗号化パケットを受信したか否かを判断する（ステップＳ１５０）。他のデバイスから暗号化パケットを受信していなければ（ステップＳ１５０においてＮＯ）、ステップＳ１００以下の処理が繰り返される。

【0169】

他のデバイスから暗号化パケットを受信していれば（ステップＳ１５０においてＹＥＳ）、デバイス１００は、受信した暗号化パケットが自デバイス宛であるか否かを判断する（ステップＳ１５２）。受信した暗号化パケットが自デバイス宛であれば（ステップＳ１５２においてＹＥＳ）、デバイス１００は、受信した暗号化パケットを復号し（ステップＳ１５４）、暗号化パケットの復号結果に基づいて必要な処理を実行する（ステップＳ１５６）。そして、ステップＳ１００以下の処理が繰り返される。

【0170】

これに対して、受信した暗号化パケットが自デバイス宛でなければ（ステップＳ１５２においてＮＯ）、デバイス１００は、受信した暗号化パケットを別のデバイスにＰ２Ｐで転送する（ステップＳ１５８）。そして、ステップＳ１００以下の処理が繰り返される。

【0171】

図１４は、本実施の形態に従うプロキシサーバ２２がパケットをやり取りする処理手順を示すフローチャートである。図１４に示す各ステップは、プロキシサーバ２２の制御部によって実行される（典型的には、プロセッサおよびメモリが協働することにより実現される）。

【0172】

図１４を参照して、プロキシサーバ２２は、いずれかのデバイスからプロキシ動作要求を受信したか否かを判断する（ステップＳ２００）。いずれかのデバイスからプロキシ動作要求を受信していれば（ステップＳ２００においてＹＥＳ）、プロキシサーバ２２は、要求元のデバイスについてのプロキシ動作に係るセッションを確立する（ステップＳ２０２）。いずれかのデバイスからプロキシ動作要求を受信していなければ（ステップＳ２００においてＮＯ）、ステップＳ２０２の処理はスキップされる。

【0173】

続いて、プロキシサーバ２２は、いずれかのデバイスから自デバイス宛の暗号化パケットを受信したか否かを判断する（ステップＳ２０４）。いずれかのデバイスから自デバイス宛の暗号化パケットを受信していれば（ステップＳ２０４においてＹＥＳ）、プロキシサーバ２２は、受信した暗号化パケットを復号し（ステップＳ２０６）、暗号化パケットの復号結果に含まれる要求に従って処理を実行する（ステップＳ２０８）。いずれかのデバイスから自デバイス宛の暗号化パケットを受信していなければ（ステップＳ２０４においてＮＯ）、ステップＳ２０６およびＳ２０８の処理はスキップされる。

【0174】

続いて、プロキシサーバ２２は、いずれかのデバイスから自デバイス宛の通常パケットを受信したか否かを判断する（ステップＳ２１０）。この通常パケットは、上述のサーバ２４などからの応答を含むパケットが想定される。いずれかのデバイスから自デバイス宛の通常パケットを受信していれば（ステップＳ２１０においてＹＥＳ）、プロキシサーバ２２は、受信した通常パケットを含む暗号化パケットを生成する（ステップＳ２１２）。そして、プロキシサーバ２２は、生成した暗号化パケットをＰ２Ｐでデバイス１００に送信する（ステップＳ２１４）。いずれかのデバイスから自デバイス宛の通常パケットを受信していなければ（ステップＳ２１０においてＮＯ）、ステップＳ２１２およびＳ２１４の処理はスキップされる。そして、ステップＳ２００以下の処理が繰り返される。

【0175】

上述したように、認証済みＩＰアドレスを有していて、暗号化パケットをやり取りできるデバイスと、認証済みＩＰアドレスを有しおらず、暗号化パケットをやり取りできないデバイスとが混在するネットワークが存在し得る。本実施の形態に従うネットワークシステム１は、このようなネットワークにおいても、プロキシサーバとなるデバイスを利用することで、送信元のデバイスから見れば、認証済みＩＰアドレスを有しているデバイスとの間で暗号化パケットをやり取りするのと同様の手順で、必要なデータ通信を実現できる。

【0176】

＜Ｆ．利点＞
本実施の形態に従うネットワークシステム１によれば、宛先のデバイスが暗号化パケットをやり取り可能ではないデバイスを含むネットワークにおいても、処理の親和性を維持しつつ、セキュアレベルも維持できるＰ２Ｐによるデータ通信を実現できる。

【0177】

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

【符号の説明】

【0178】

１ ネットワークシステム、２ ネットワーク、４ アクセスポイント、６ 移動体基地局、１０ ローカルライン、２０ インターネット、２２ プロキシサーバ、２４，３４ サーバ、３０ 制限ネットワーク、３２ 中継サーバ、１００ デバイス、１０２ プロセッサ、１０４ 主メモリ、１０６ ストレージ、１０８ ＲＯＭ、１１０ 制御部、１２０ ネットワークインターフェイス、１３０ 表示部、１４０ 入力部、１５０ メディアインターフェイス、１５２ メディア、１６０ ＯＳ、１７０ 通信処理プログラム、１７２ 秘密鍵、１７４ 公開鍵、１７６ 電子証明書、１７８ ハッシュ値、１８０ ハッシュ関数、１９０ ＩＰアドレス、１９４ コネクションテーブル、２００ 認証局、３００ アプリケーション。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】