添付の図面を参照して本発明の実施の形態を説明する。以下に説明する実施の形態は本発明の構成の例であり、本発明は、以下の実施の形態に制限されるものではない。また、図面における丸付き数字の番号は、手順の順番を表す。
(実施形態1)
図1は、本実施形態に係るネットワークデータ分散共有システムの構成概略図である。図1に示すネットワークデータ分散共有システム91は、ネットワーク監視用ノード71及びネットワーク監視用ノード71に予め登録されている複数のクライアントノード81、82a、82b、82c、83がネットワークで互いに接続されているシステムである。
クライアントノードのうち少なくとも1つのクライアントノードは、ファイルデータを所有しているデータ配信元クライアントノード81であり、クライアントノードのうち少なくとも1つのクライアントノードは、ファイルデータが分割されかつ暗号化されているデータピースを格納しているデータピースクライアントノード82であり、クライアントノードのうち少なくとも1つのクライアントノードは、データ配信元クライアントノード81に対し、ファイルデータの要求を行うデータ要求クライアントノード83である。
図2は、ネットワークデータ分散共有システム91の一例を示す構成図である。ネットワーク監視用ノード71は、ネットワーク監視用サーバ72と、ファイルエントリデータベース73と、クライアントノードエントリデータベース74と、ネットワーク監視サーバデータベース75と、を備える。ネットワーク監視用サーバ72は、クライアントノード認証手段32と、通信接続情報通知手段33と、自由配信許可フラグ判別手段34と、を備えることが好ましい。
データ配信元クライアントノード81は、メタデータ記憶手段11と、メタデータ送信手段13と、クライアントノード認証情報問合せ手段14と、暗号鍵送信手段15と、を備える。データ配信元クライアントノード81は、さらに、暗号鍵発生手段21と、データピース生成手段22と、を備えることが好ましい。
データ要求クライアントノード83は、データピース収集手段16と、暗号化ファイルデータ復元手段17を備える。データ要求クライアントノード83は、データ配信元問合せ手段18と、データ要求手段12と、暗号化判別手段19と、非暗号化ファイルデータ復元手段20と、を備えることが好ましい。暗号化ファイルデータ復元手段17は、暗号鍵取得手段を備えることが好ましい。
図2に示すネットワーク監視用ノード71のネットワーク監視用サーバ72は、ネットワークを管理する。ネットワーク監視用サーバ72は、ファイルエントリデータベース73と、P2Pネットワークに参加しているクライアントノード情報を管理するクライアントノードエントリデータベース74及び、ネットワーク監視用サーバ72自身の、位置情報、識別情報等から成る、認証情報を登録および管理するためのネットワーク監視サーバデータベース75とから構成される一群のデータベース群に接続される。ファイルエントリデータベース73、クライアントノードエントリデータベース74、ネットワーク監視サーバデータベース75は、物理的に分離されて表現されているが、これらは、物理的に分離することも、物理的には1つのサーバに統合することも、あるいは、ネットワーク上に分散して配備することも可能である。また、ネットワーク監視用サーバの信頼性を向上させるためには、2つ以上配備することもが可能である。
ネットワーク監視用サーバ72は、自己の位置情報を取得するための位置情報受信手段76を備える。位置情報受信手段76は、例えば、衛星測位システムまたは無線測位システム、或いは、これらの組み合わせである。衛星測位システムは、衛星を用いて位置を測定するシステムであり、例えば、GNSS(Global Navigation Satellite System)である。無線測位システムは、無線信号を用いて位置を測定するシステムであり、無線信号は、例えば、無線基地局から発信する無線信号、RFID(Radio Frequency Identification)タグの発信する無線信号である。
図2に示すネットワーク監視用ノード71のファイルエントリデータベース73は、ファイルデータの識別情報、データ配信元クライアントノード81のデータ配信元クライアントノード識別情報、データピース識別情報、データピースクライアントノード82a、82b、82cのデータピースクライアントノード識別情報をファイル配信メタデータとして格納する。ファイルエントリデータベース73は、ネットワーク内部を、P2Pメカニズムを用いて、流通するファイルデータのファイル配信メタデータを管理するためのファイルデータを管理する。
図3は、ファイルエントリデータベースの格納するファイル配信メタデータの一例である。ここでは、ファイルデータが3つに分割されたときのメタデータの構成例を示すが、分割数は任意に設定が可能である。また、分割された1つのデータに対応するデータ情報を「データピース」と呼称し、この「データピース」を保持するクライアントノードである、データピースクライアントノード82a、82b、82cは、ネットワーク上に、複数個存在する。データピースクライアントノード82a、82b、82cは、クライアントノード識別情報にて識別可能である。また、1つのデータピースに対するデータピースクライアントノードIDは複数個の場合も可能である。
各データピースクライアントノードへのトラヒック負荷分散の観点からは、データピースノードは、データピースのファイル名(ハッシュ値)、データピースクライアントノードID1、データピースクライアントノードID2、データピースクライアントノードID3のような構成のデータ分散状態を示す履歴情報を保持することが好ましい。この例では、すでにデータピースクライアントノードの管理するデータピースが、3つの他のクライアントノードにダウンロードされている場合の履歴であるが、この例に限定されるものではない。データ分散の履歴情報は、データピースクライアントノードがデータ要求クライアントノードからの要求に応じてデータピースを送信し、確かにデータ要求クライアントノードがデータピースを受け取ったことを確認した際に、データ要求クライアントノードのIDをデータピースクライアントノードIDとして利用可能とするために、データピースクライアントノードが保持することが好ましい。
図3に示すファイル配信メタデータにおいては、後述するように、一般的には、各データピースは暗号化されており、この暗号解読用の暗号鍵は、データ配信元クライアントノード81が所有することを基本とする。すなわち、ネットワーク監視用サーバ72からは、ファイルデータの要求を行うデータ要求クライアントノード83に、暗号鍵は、直接には送信しないことを基本とする。しかしながら、データ配信元クライアントノード81の故障の場合に備え、ファイル配信メタデータに記述されるデータピース毎に、暗号鍵を、ファイルエントリデータベース73内に、事前に格納する構成をとることも可能である。ファイル配信メタデータは、ファイルエントリデータベース73内に、複数個、格納され、適切に、通信事業者により、管理し運営されることが好ましい。
また、図3に示すファイル配信メタデータにおいて、ファイル名、および各データピース名は、ハッシュ値で格納しておくことが、好ましい。しかしながら、ファイルデータ検索の観点からは、「ファイル名」のみは、ハッシュ値を持たない形態での運用することが好ましい。データ要求クライアントノードへのデータピースの自由取得を許可するか否かを示す自由配信許可フラグが設定されている場合には、データ要求クライアントノード83の認証が成立した場合は、基本的には、無条件に、データ要求クライアントノード83にファイルデータが配信される。
図2に示すネットワーク監視用ノード71のクライアントノードエントリデータベース74は、登録されている各クライアントノード81、82a、82b、82c、83の情報を格納する。クライアントノードエントリデータベース74の格納する情報は、例えば、クライアントノードID、クライアントノード認証用パスワード、クライアントノードの位置情報、クライアントノードIPアドレス、接続可能フラグ、クライアントノード情報更新日時がある。クライアントノードエントリデータベース74は、クライアントノード認証用パスワードやクライアントノードのGPS情報などのクライアントノードを認証することの可能な情報をクライアントノード認証情報として格納している。
図2に示すネットワーク監視用ノード71のネットワーク監視サーバデータベース75は、ネットワーク監視用ノード71自身のIDとパスワードを格納する。
図2に示すネットワーク監視用ノード71のクライアントノード認証手段32は、データ配信元問合せ手段18からの問い合わせを受けると、データ要求クライアントノード83のクライアントノード認証情報がクライアントノードエントリデータベース74に格納されているか否かを判定する。例えば、データ配信元問合せ手段18からの問い合わせに添付されているクライアントノード認証情報とデータ要求クライアントノード83のデータ要求クライアントノード識別情報をネットワーク監視用サーバ72に送信し、これらの情報がクライアントノードエントリデータベース74に格納されているか否かを問い合わせる。そして、ネットワーク監視用サーバ72からクライアントノードエントリデータベース74に格納されている旨の通知を受けることで、クライアントノード認証手段32はデータ要求クライアントノード83のクライアントノード認証情報がクライアントノードエントリデータベース74に格納されていると判定する。一方、ネットワーク監視用サーバ72からクライアントノードエントリデータベース74に格納されていない旨の通知を受けることで、クライアントノード認証手段32はデータ要求クライアントノード83のクライアントノード認証情報がクライアントノードエントリデータベース74に格納されていないと判定する。これらの判定により、クライアントノード認証手段32の認証を終了する。
図2に示すネットワーク監視用ノード71の通信接続情報通知手段33は、クライアントノード認証手段32が認証を行うと、ファイルエントリデータベース73を参照し、問い合わせのあったファイルデータを所有するデータ配信元クライアントノード81の通信接続情報を、データ要求クライアントノード83に通知する。データ配信元クライアントノード81の通信接続情報は、例えば、データ配信元クライアントノード81のデータ配信元クライアントノード識別情報又はIPアドレスである。
ファイルエントリデータベース73の格納するファイル配信メタデータに、データ要求クライアントノード83へのデータピースの自由取得を許可するか否かを示す自由配信許可フラグがさらに含まれている場合、図2に示すネットワーク監視用ノード71は自由配信許可フラグ判別手段34をさらに備えることが好ましい。自由配信許可フラグ判別手段34は、データ配信元問合せ手段18からの問い合わせを受けると、ファイルエントリデータベース73を参照し、自由配信許可フラグを判別する。例えば、自由配信許可フラグが有効のときにデータ要求クライアントノード83へのデータピースの自由取得が許可されていると判別し、自由配信許可フラグが無効のときにデータ要求クライアントノード83へのデータピースの自由取得が許可されていないと判別する。判別は、有効が不許可、無効が許可であってもよい。
ネットワーク監視用ノード71が自由配信許可フラグ判別手段34をさらに備える場合、ネットワーク監視用ノード72の通信接続情報通知手段33は、自由配信許可フラグ判別手段34がデータピースの自由取得を許可するファイルデータであることを判別すると、ファイルエントリデータベース73を参照し、問い合わせられたファイルデータのファイル配信メタデータを、データ要求クライアントノード83にさらに通知することが好ましい。さらに、ファイルエントリデータベース73にデータピースが格納されている場合には、自由配信許可フラグ判別手段34がデータピースの自由取得を許可するファイルデータであることを判別すると、通信接続情報通知手段33は、データピースをデータ要求クライアントノード83へ送信することが好ましい。データ要求クライアントノード83がファイル配信メタデータ或いはファイル配信メタデータ及びデータピースを容易に取得することができるので、お試し版のファイルデータやサンプルファイルなどのデータ要求クライアントノード83に自由に見てほしいコンテンツをデータ要求クライアントノード83に容易に提供することができる。さらに、データピースの自由取得を許可するデータピースを暗号化しなければ、データ要求クライアントノード83は暗号鍵を使用しないでファイルデータの活用が可能である。
なお、図1及び図2では、ネットワーク監視用ノード71が1つの例を示したが、ネットワーク監視用ノード71は複数であることが好ましい。この場合、ネットワーク監視用ノード71のそれぞれは、データ配信元クライアントノード81とネットワークで接続される。そして、データ配信元クライアントノード81は、複数のネットワーク監視用ノード71のうちのいずれかを選択して通信接続を行うネットワーク監視用ノード選択手段(不図示)をさらに備えることが好ましい。データ配信元クライアントノード81と複数のネットワーク監視用ノード71のそれぞれとがネットワークで接続され、ネットワーク監視用ノード71のうちの任意の1つを選択することができることで、ネットワーク監視用ノード71が接続不能となった場合でも、その影響をまったく受けないシステムとすることができる。これにより、個々のサーバの冗長化を行う必要がなくなるので、システム構築におけるコスト削減を図ることができる。
さらに、複数のネットワーク監視用ノード71のうち少なくとも1つは、ファイルエントリデータベース73がさらに暗号鍵を格納する暗号鍵蓄積サーバ(不図示)であることが好ましい。この場合、データ配信元クライアントノード81の暗号鍵送信手段15は、は、データ要求クライアントノード83への暗号鍵の提供に際して、暗号鍵蓄積サーバ(不図示)から前記暗号鍵を取得することができる。これにより、データ配信元クライアントノード81のうちの暗号鍵に関する機能が一時停止状態になった場合でも、データ配信元クライアントノード81は滞りなくコンテンツの提供を継続することができる。
図2に示すデータ配信元クライアントノード81のメタデータ記憶手段11は、ファイルデータ固有のファイルデータ識別情報、データピース固有のデータピース識別情報、データピースクライアントノード82固有のデータピースクライアントノード識別情報、及び、データピースをファイルデータに復元する暗号鍵をファイル配信メタデータとして格納する。データ配信元クライアントノード81が管理するファイル配信メタデータに関しては、ファイルエントリデータベース73に登録されているファイル配信メタデータと一部、データの構成が異なり、データ受信許可ノードID部を追加することが好ましい。データ受信許可ノードID部は、データ配信元クライアントノード81の公開するファイルデータを受信することを許可するクライアントノードを特定する。データ受信許可ノードID部を設けることで、データ受信許可ノードID部に含まれるクライアントノードIDを持つクライアントノードのみが、データ配信元クライアントノード81の公開するファイルデータを受信することが可能となる。
図4は、メタデータ記憶手段に記憶されるファイル配信メタデータの構成例である。図4では、一例として、ファイルデータが3つに分割されたときを示すが、分割数は任意に設定することが可能である。ファイルデータが、データピース1からデータピース3までの、3つのデータピースに分割されたときの、クライアントノードが管理するファイル配信メタデータの構成を示しており、この分割数は、任意に、設定が可能である。また、各々のデータピースに対する、データピースクライアントノードIDは、ネットワーク上でのデータ取得の信頼性を向上させるため、1つのデータピースに対して、複数個、存在してもよい。データ受信許可ノードID部に含まれるクライアントノードIDを持つクライアントノードのみが、データ配信元クライアントノード81の公開するファイルデータを受信することが可能となる。ここで、データ受信許可ノードIDは複数個、存在してもよい。データ受信許可ノードIDが、2個存在する場合(データ受信許可ノードID1、ID2)を示しているが、2個に限定されるものではない。通常は、データ配信元クライアントノード81は事前にファイルデータの受信を許可するクライアントノードのクライアントノードIDをリストアップし、ファイル配信メタデータのデータ受信許可クライアントノードIDに記述するフィールド部に、クライアントノードIDを追加することができる。このデータ受信許可クライアントノードIDフィールド部に含まれるクライアントノードIDを持つクライアントノードのみが、データ配信元クライアントノード81の公開するファイルデータを受信することが可能となる。
データ配信元となるデータ配信元クライアントノード81が、公開したいファイルデータを、いくつに分割し、データピースクライアントノード82a、82b、82cに対して、どのように分散配信するかについては、データ配信元クライアントノード81自身が任意に決定することが可能である。データ配信元クライアントノード81は、ファイルデータの分割数を決めた後に、自身の生成した暗号鍵によってファイルデータを暗号化する。ファイルデータを分割した時は、各々の分割されたデータピース毎に、別々の暗号鍵を用いることが、セキュリティ上は好ましい。また、データピースのファイル名にはハッシュ値を用いることが好ましい。データピースのファイル名にハッシュ値を用いた場合は、ファイル配信メタデータ内の各データピースのチェックサム部は省略することも可能である。
データ配信元クライアントノード81がデータピース生成手段22を備える場合、メタデータ記憶手段11は、データピース生成手段22の用いた暗号鍵を暗号鍵として記憶する。
図2に示すデータ配信元クライアントノード81のメタデータ送信手段13は、データ要求クライアントノード83からファイルデータの要求を受けると、メタデータ記憶手段11を参照し、ファイルデータについてのファイル配信メタデータをデータ要求クライアントノード83に送信する。
図2に示すデータ配信元クライアントノード81のクライアントノード認証情報問合せ手段14は、データ要求クライアントノード83のデータ要求手段12からファイルデータの要求を受けると、データ要求クライアントノード83のクライアントノード認証情報がクライアントノードエントリデータベース74に格納されているか否かをネットワーク監視用ノード71に問い合わせる。例えば、データ要求手段12からの問い合わせに添付されているクライアントノード認証情報とデータ要求クライアントノード83固有のデータ要求クライアントノード識別情報をネットワーク監視用サーバ72に送信し、これらの情報がクライアントノードエントリデータベース74に格納されているか否かを問い合わせる。そして、ネットワーク監視用サーバ72からクライアントノードエントリデータベース74に格納されている旨の通知を受けることで、クライアントノード認証情報問合せ手段14はデータ要求クライアントノード83のクライアントノード認証情報がクライアントノードエントリデータベース74に格納されていると判定する。一方、ネットワーク監視用サーバ72からクライアントノードエントリデータベース74に格納されていない旨の通知を受けることで、クライアントノード認証情報問合せ手段14はデータ要求クライアントノード83のクライアントノード認証情報がクライアントノードエントリデータベース74に格納されていないと判定する。これらの判定により、クライアントノード認証情報問合せ手段14は、データ要求クライアントノード83の認証を終了する。
クライアントノード認証情報問合せ手段14は、データ要求クライアントノード83との間で、互いが所持する相手のID、パスワード、及び位置情報を照合することによって認証を行うことが好ましい。また、ネットワークに、すでに参加しているデータ要求クライアントノード83との間での接続に際しては、互いが所持する相手のID、パスワード、及び位置情報の照合を相互に行い、照合が成功した場合のみ接続が確立できる。具体的な接続シーケンス例については後述する。
ここで、各クライアントノード81、82a、82b、82c、83は、衛星測位システム又は無線測位システムによって自己の位置情報を取得し、当該位置情報をネットワーク監視用ノード71へ継続的に送信する位置情報通知手段をさらに備えることが好ましい。ここで、自己の位置情報を取得は、衛星測位システム及び無線測位システムによって取得してもよい。両者を組み合わせることで、測位衛星からの信号を受信できない場合や無線測位システムの配備されていない地域であっても、位置情報を取得することができる。この場合、位置情報通知手段がネットワーク監視用ノード71へ位置情報を送信すると、
ネットワーク監視用サーバ72が受信し、クライアントノードエントリデータベース74に格納する。これにより、ネットワーク監視用ノード71は、各クライアントノード81、82a、82b、82c、83の最新の位置情報を取得することができる。データ配信元クライアントノード81は、データ要求クライアントノード83との通信中において、クライアントノード認証情報問合せ手段14が、継続的にネットワーク監視用ノード71に問い合わせることが好ましい。
図2に示すデータ配信元クライアントノード81の暗号鍵送信手段15は、クライアントノード認証情報問合せ手段14が認証を行うと、メタデータ記憶手段11の記憶する暗号鍵をデータ要求クライアントノード83のデータ要求手段12へ送信する。
図2に示すデータ配信元クライアントノード81の暗号鍵発生手段21は、暗号鍵を発生させる。暗号鍵の暗号は、特に限定するものではないが、例えば、ブロック暗号、ストリーム暗号等の共通鍵暗号、RSA暗号等、ElGamal暗号、楕円曲線暗号、ナップサック暗号、ラティス暗号等の公開鍵暗号である。本実施形態では、公開鍵暗号が好ましい。
図2に示すデータ配信元クライアントノード81のデータピース生成手段22は、暗号鍵発生手段の発生させる暗号鍵を用いてファイルデータを暗号化かつ分割してデータピースを生成させる。データピース生成手段22は、公開したいファイルデータを複数のデータピースに分割し、全てのデータピースを暗号化する。または、データピース生成手段22は、公開したいファイルデータを暗号化し、複数のデータピースに分割する。これにより、データ配信元クライアントノード81は、各々のデータピースは、データ配信元クライアントノード81が認証に成功した他のクライアントノードに対して送信することができる。
データピースを受信したクライアントノードが、データピースクライアントノード82a、82b、82cである。データ配信元クライアントノード81はデータピースクライアントノード82へのデータの送信が完了した後、データ配信元クライアントノード81自身が管理するファイル配信メタデータに、図4に示すように、暗号化したデータピースのファイル名、データピースのチェックサム、データピースの暗号化に使用した暗号鍵、及びデータピースクライアントノードID等を、データ配信元ノード自身が管理するファイル配信メタデータ、およびネットワーク監視用サーバが管理するファイルエントリデータベース内に存在するファイル配信メタデータに追加する。データ配信元クライアントノードはネットワーク内の登録された、複数のクライアントノードに対して、冗長化して、データピースを分散配信することが可能となる。
データピース生成手段22は、さらに、自身のクライアントノードID、公開するファイル名、公開するファイルデータのトータルデータサイズ、公開するファイルデータのトータルデータチェックサム値を含むデータをファイル配信メタデータとして生成することが好ましい。公開するファイルデータのチェックサム値の算出にはハッシュ関数を用いることが好ましい。この際に、用いるハッシュ関数としてはMD5(Message Digest Algorithm 5)などが適用可能であるが、これに限定されるものではない。なお、自由配信許可フラグの、詳細の機能に関しては後述する。
データ配信元クライアントノード81がファイルデータの公開を中止したい場合には、先ず、データ配信元クライアントノード81は、ネットワーク監視用サーバ72に接続し、認証を受け、ネットワーク監視用サーバ72に対して、公開を中止したいファイルデータのファイル配信メタデータの削除指令を送信する。この情報を受信したネットワーク監視用サーバ72は、ファイルエントリデータベース73からファイル配信メタデータを削除する。次に、データ配信元クライアントノード81は、自身の管理するファイル配信メタデータ内の、ファイルデータの記述内容の削除を行う
以上述べた手順により、データ配信元クライアントノード81によるファイルデータの公開を中止することが実現できる。P2Pネットワーク内には、すでに複数のデータピースが分散されている可能性があるが、このデータピースを、集めて復号化するための暗号鍵は、上記の手段により、P2Pネットワーク内から完全に消去されるため、分散化されたデータピースは意味を持たないデータとなる。万が一、以前にファイルデータ全ての受信に成功したデータピースクライアントノード82が、当該ファイルデータの解読に関わる暗号鍵を、データ配信元クライアントノード81と同様に、所有し続け、当該ファイルデータのデータ配信元となった場合においては、特願平2005−353829及び特願平2005−353831「交換ノードおよび交換ノード制御方法」に開示されている方法により、悪意のあるクライアントノードの特定化あるいは、絞り込みが可能である。
図2に示すデータ要求クライアントノード83のデータ配信元問合せ手段18は、ファイルデータを所有するデータ配信元クライアントノード81の通信接続情報をネットワーク監視用ノード71に問い合わせる。ネットワーク監視用サーバ72により、認証に成功して、正常にP2Pネットワークに参加したクライアントノードは、受信を希望するファイルデータの要求時には、ネットワーク監視用サーバ72の認証を受け、ファイル配信メタデータを受信する。ネットワーク内に存在するファイルデータの情報は、各クライアントノード間で、ファイル名と、データ配信元クライアントノードIDとを組み合わせた形式で流通することを想定すれば、任意のクライアントノード(ユーザ)側で、ファイル転送要求を行うユーザが、受信を希望するファイル名を検索して、決定することができる。データ要求クライアントノード83は、データ配信元クライアントノード81のクライアント識別情報(ID)やIPアドレスなどのデータ配信元クライアントノード81の通信接続情報を取得することができる。
図2に示すデータ要求クライアントノード83のデータ要求手段12は、データ配信元問合せ手段18が取得したデータ配信元クライアントノード81の通信接続情報に、ファイルデータの配信を要求する。このとき、データ要求手段12は、データ配信元クライアントノード81との間で、互いが所持する相手のクライアントノード識別情報、パスワード、及び位置情報を照合することによって認証を行うことが好ましい。また、ネットワークに、すでに参加しているデータ配信元クライアントノード81との間での接続に際しては、互いが所持する相手のID、パスワード、及び位置情報の照合を相互に行い、照合が成功した場合のみ接続が確立できる。具体的な接続シーケンス例については後述する。
ファイルデータの取得を希望するデータ要求クライアントノード83は、データ配信元クライアントノード81から、分割かつ暗号化されたファイルデータの復号化に必要な暗号鍵を入手する際に、何らかの理由で、データ配信元クライアントノード81が、故障している場合が考えられる。この場合には、例えば、事前に、ネットワーク監視用サーバ72に接続されたファイルエントリデータベース73内に、暗号鍵を、データ配信元クライアントノード81の指示に従い、事前に格納しておき、ネットワーク監視用サーバ72から暗号鍵を入手することも可能である。
データ要求手段12は、公開鍵暗号方式を用いて暗号鍵を入手することが好ましい。また、データ配信元クライアントノード81が正常に動作している場合には、データ要求クライアントノード83は、データ配信元クライアントノード81に対して、ファイル配信メタデータを要求することが、一般的には、ネットワーク監視用サーバ72の負荷を軽減する観点から考えて、好ましい。ただし、ファイル配信メタデータ内の自由配信許可フラグが無効である場合には、データ要求クライアントノード83はファイル配信メタデータを取得するために、データ配信元クライアントノード81から直接に認証を受ける必要がある。この場合は、ネットワーク監視用サーバ72はファイル配信メタデータをデータ要求クライアントノードに送信する必要がない。データ要求クライアントノード83はデータ配信元クライアントノード81に接続し、認証に成功した後にファイル配信メタデータを受信できる。なお、認証に際しては、データ配信元クライアントノード81は、自身の管理するファイル配信メタデータのデータ受信許可ノードID部に、データ要求クライアントノード83のクライアントノードIDが登録されているかどうかを判断し、登録されている場合のみ、認証が成功したものとみなし、ファイル配信メタデータをデータ要求クライアントノード83に送信する。上述した手順を用いることにより、データ配信元クライアントノード81から、ファイルデータの受信を許可されたクライアントノードのみがファイル配信メタデータの受信が可能となる。また、この時データ要求クライアントノード83がデータ配信元クライアントノード81もしくはネットワーク監視用サーバ72から受け取るファイル配信メタデータは、ファイルエントリデータベース73の格納するファイル配信メタデータから暗号鍵を除去したデータである。
図2に示すデータ要求クライアントノード83のデータピース収集手段16は、データ配信元クライアントノード81の送信したファイル配信メタデータに基づき、データピースクライアントノード82からデータピースを取得する。ファイル配信メタデータを受信したデータ要求クライアントノード83は、ファイル配信メタデータの内容に基づいて、データピースを保持する各データピースクライアントノード82a、82b、82cへの接続を試みる。認証に成功し、データピースクライアントノード82a、82b、82cに接続したデータ要求クライアントノード83は、データピースクライアントノード82a、82b、82cから、ファイル配信メタデータに記述されたデータピースファイル名に合致するファイル名を持つデータピースを受信する。
この際、あるデータピースクライアントノード82a、82b、82cがビジー状態にあり、データの送受信が困難な場合には、データ要求クライアントノード83に対して、データピースを送信できない旨を通知し、データピースクライアントノード82a、82b、82cはデータ分散の履歴情報を参照し、データ要求クライアントノード83に対して、代替データピースクライアントノードIDを代わりに送信する。この代替データピースクライアントノードIDを受け取ったデータ要求クライアントノード83は、データピースクライアントノード82a、82b、82cとの接続を切断し、代替データピースクライアントノードIDを持つクライアントノードに接続し、代替データピースクライアントノードからデータピースを受信する。
データピースの受信が完了した後は、実際に受信したデータピースのハッシュ値とデータピースのファイル名とを比較し、一致した場合は、データピースクライアントノード82a、82b、82cから正常にデータピースを受信できたと判断する。なお、この際に、用いるハッシュ関数としては前述のとおり、MD5の適用が可能であるが、これに限定されるものではない。
図2に示すデータ要求クライアントノード83の暗号化ファイルデータ復元手段17は、データ配信元クライアントノード81の送信したファイル配信メタデータに基づいて、データ配信元クライアントノード81の送信した暗号鍵を用い、データピース収集手段の収集するデータピースをファイルデータに復元する。例えば、全てのデータピースの復号化し、復号化した各々のデータピースを結合し、結合後のファイルデータのトータルデータサイズ、トータルチェックサムを計算し、ファイル配信メタデータ内に記述されているトータルデータサイズ、及びトータルチェックサムと一致するかどうかを確認する。一致した場合、ファイルデータの受信が成功したものと判断する。また、全てのデータピースを結合し、結合したデータピースを復号化して、ファイルデータに復元する。P2Pネットワーク内を流通するファイルデータは、全てファイル配信メタデータの形式で、ネットワーク監視用サーバの管理するファイルエントリデータベースに格納されるため、予め定められた機関に属するクライアントノードに限って、または、相互に個別に取り決めのなされているクライアントノード間でのみ、ファイルデータの分散共有を行うことが可能となる。以上のようにして、クライアントノードの認証、ファイルデータの分割および分散化、ファイルデータのデータ要求クライアントへの受信が実現できる。
さらに、暗号化ファイルデータ復元手段17は、ファイルデータを復元した後に、復元したファイルデータのトータルデータサイズ、トータルチェックサムを計算し、ファイル配信メタデータ内に記述されているトータルデータサイズ、及びトータルチェックサムと一致するかどうかを確認する。一致した場合、ファイルデータの受信が成功したものと判断することが好ましい。
ファイル配信メタデータに自由配信許可フラグが含まれている場合には、データ要求クライアントノード83は、暗号化判別手段19と、非暗号化ファイルデータ復元手段20と、をさらに備えることが好ましい。
図2に示すデータ要求クライアントノード83の暗号化判別手段19は、自由配信許可フラグに基づいてデータピースが暗号化されているか否かを判別する。自由配信許可フラグは、例えば、暗号鍵を用いずにファイルデータを復元することの可能なファイルデータであることを示す。
図2に示すデータ要求クライアントノード83の非暗号化ファイルデータ復元手段20は、暗号化判別手段19がデータピースを暗号化されていないと判別すると、データピース収集手段16の収集するデータピースをファイルデータに復元する。非暗号化ファイルデータ復元手段20は、暗号化ファイルデータ復元手段17を用いてもよい。
暗号化ファイルデータ復元手段17は、暗号鍵取得手段を備えることが好ましい。暗号鍵取得手段は、データピース収集手段16がデータピースクライアントノード82からデータピースを取得した後に、ファイル配信メタデータに記述されたデータ配信元クライアントノード81のIDに対して接続を行い、暗号鍵をデータ配信元クライアントノード81から取得する。例えば、暗号鍵受信手段は、分割された、全てのデータピースが、集められた時点で、データ要求クライアントノード83はファイル配信メタデータに記述されたデータ配信元クライアントノード81のIDに対して接続を行う。ここで、データ配信元クライアントノード81との認証に成功し、データ配信元クライアントノード81に接続ができたデータ要求クライアントノード83は、データ配信元クライアントノード81に対して、データピースのファイル名を送信する。データ配信元クライアントノード81ではファイル名に関わるデータピースに対応する暗号鍵を保持しているため、この暗号鍵の情報を、暗号鍵取得手段に対して送信する。この際には、通常は、公開鍵暗号方式による暗号鍵の送信が好ましい。
ただし、ファイル配信メタデータ内の自由配信許可フラグが無効である場合には、暗号鍵取得手段は暗号鍵を取得するために、データ配信元クライアントノード81から直接に、認証を受けて、暗号鍵を受信する必要がある。すなわち、この場合には、ネットワーク監視用サーバ72は、暗号鍵を、暗号鍵取得手段には送信する必要はない。この時、暗号鍵取得手段はデータ配信元クライアントノード81に接続することを試み、認証を受けた後に、暗号鍵を受信する。例えば、データ配信元クライアントノード81は、自身の管理するファイル配信メタデータのデータ配信元クライアントノード81のID部に、データ要求クライアントノード83のIDが登録されているかどうかを判断し、登録されている場合のみ、認証が成功したと判断し、暗号鍵をデータ要求クライアントノード83に送信する。以上述べた手順を用いることにより、データ配信元クライアントノード81からファイルデータの受信を許可されたクライアントノードのみが、暗号鍵を受信することが可能となる。
また、何らかの原因によって、データ配信元クライアントノード81が故障している場合または、ビジー等の状態にある場合は、暗号鍵取得手段は、ネットワーク監視用サーバ72との接続を行い、ネットワーク監視用サーバ72から認証を受け、ネットワーク監視用サーバ72に対してデータ配信元クライアントノード81のID、ファイル名、データピースのファイル名を送信する。これらの情報を受信したネットワーク監視用サーバ72は、ファイルエントリデータベース73内からデータ配信元クライアントノード81のIDとファイル名を含むファイル配信メタデータを検索し、検索できたファイル配信メタデータの内容に基づいて、暗号鍵を暗号鍵取得手段に、公開鍵方式を用いて送信する。このような手順を適用することにより、データ配信元クライアントノード81が故障等の状況にある場合でも、分割化かつ、暗号化されたファイルデータの解読に必要な暗号鍵の受信が、データ要求クライアントノード83により可能となる。
暗号化ファイルデータ復元手段17は、データ配信元クライアントノード81又は暗号鍵の管理を委託されているネットワーク監視用サーバ72から暗号鍵を受信した後に、ファイルデータの一部として、データ要求クライアントノード83のメタデータ記憶手段11には保存はせず、主記憶(メインメモリ)に保持したまま、速やかに、データピースからファイルデータへの復元処理に用いることが好ましい。ファイルデータの復元処理が終了し、必要の無くなった暗号鍵は、速やかに、主記憶上から消去されるようにすると共に、暗号鍵は、ハードディスク等への記憶媒体へは書き込み禁止となるように構成した復元処理プログラムを活用する形態が好ましい。
また、データ要求クライアントノード83は、ファイルデータを公開する際には、毎回、または周期的に、暗号鍵を更新するようにする形態が好ましい。P2Pネットワークに登録された正規のユーザのみを対象として、ファイルデータの共有を実現することが、本実施形態の前提であるため、暗号鍵を何らかの手段で、流通させる、悪意のあるユーザが発見された場合には、当該ユーザをクライアントノードデータベースエントリーから除外することが好ましい。
なお、図1に示すネットワークデータ分散共有システム91では、クライアントノード81、82a、82b、82c、83は、あらかじめ、クライアントノードエントリデータベース74に、P2Pネットワークに参加する正規のクライアントノードとして、クライアントノード認証情報等が登録されたものに限定される。ネットワーク監視サーバデータベース75は、ネットワーク監視用サーバ72のID、パスワード及び位置情報が格納されることが好ましい。但し、位置情報に関しては、ネットワーク監視サーバデータベース75に格納せず、リアルタイムに取得した情報を各クライアントノード81、82a、82b、82c、83に送付することも可能である。
図5は、クライアントノードのシステム構成の一例を示す模式図である。クライアントノード80は、図1に示したクライアントノード81、82a、82b、82c、83すべてに備わる基本構成の一部を示す。クライアントノード80は、通信ネットワーク101に接続するための通信手段、通信ネットワーク101上のデータを送受信し、格納するためのデータ格納手段102、及びクライアントノード80自身の位置情報を取得するための位置情報受信手段76を備える制御用端末103の機能を具備するが、図1及び図2では省略した。また、制御用端末103には通信ネットワーク101内で、P2Pメカニズムを活用するための通信ソフトウェアが搭載される。
クライアントノード80のデータ格納手段102は、図2に示すメタデータ記憶手段11を含み、送受信する通信ネットワーク101内のファイルデータのほか、ネットワーク監視用サーバ(図1の符号72)の属性データや自己のクライアントノード80についての情報が格納されている。ネットワーク監視用サーバ(図1の符号72)の情報は、例えば、ネットワーク監視用サーバ(図1の符号72)のID、パスワード、位置情報、IPアドレスである。自己のクライアントノード80の情報は、例えば、クライアントノード80のID、認証用パスワ−ド、クライアントノード80の位置情報である。クライアントノード80は、ネットワークに参加する際には、制御端末内のデータ格納手段に格納されているネットワーク監視用サーバ(図1の符号72)の情報に基づき、ネットワーク監視用サーバ(図1の符号72)に接続を行い、相互に認証を行った後に、P2Pネットワークに参加できる。
図1に示す各クライアントノード81、82a、82b、82c、83は、P2Pネットワークに参加する際、ネットワーク監視用サーバ72に接続し、データ格納手段(図5の符号102)に格納されているネットワーク監視用サーバ72の属性データに基づいて、位置情報、クライアントノードのID、およびパスワード等の属性情報を活用し、ネットワーク監視用サーバ72による認証を受けることにより、初めてP2Pネットワークに参加することができる。ネットワーク監視用サーバ72は、クライアントノードエントリデータベース74に、各クライアントノード81、82a、82b、82c、83に備わる制御端末内のデータ格納手段(図5の符号102)に含まれている自己のクライアントノードの情報と同じ情報が、あらかじめ登録されている場合にのみ、正常なクライアントノードとしてP2Pネットワークへの参加を認めるメカニズムを活用することにより、セキュリティを確保することが可能となる。通信ネットワーク内にファイルデータを公開したいファイル配信元となるデータ配信元クライアントノード81は、事前に公開したいファイルデータのファイル配信メタデータを、ネットワーク監視用サーバ72の認証を経て、ファイルエントリデータベース73に登録する必要がある。
また、ファイル配信元となるデータ配信元クライアントノード81が、ファイル配信メタデータの登録に際して、特定のクライアントノードのIDを持つクライアントノードにのみファイルデータを公開する場合、自由配信許可フラグを無効にして、ファイルエントリデータベース73に登録することが好ましい。ファイルデータの入手の要求を行うデータ要求クライアントノード83と配信元となるデータ配信元クライアントノード81との間で、個別に相互認証を行う手段を設けることが好ましい。
(実施例1)
以下に、本実施形態における、各状態でのシステムの動作を説明する。図6は、実施例1に係るネットワークデータ分散共有システムの構成概略図である。図7は、実施例1に係るネットワークデータ分散共有システムのデータシーケンスである。図6及び図7を用いて、本実施形態によるP2Pネットワークにクライアントノード80が参加するときの動作を説明する。以下の説明では、ネットワーク監視用サーバ72側のクライアントノードエントリデータベース74に新規クライアントノードの情報があらかじめ登録されているものとする。先ず、第1の手順では、クライアントノード80側制御用端末は測位衛星97から随時送信される制御用端末103の地理的データである位置情報を、位置情報受信手段76を用いて受信する。
第2の手順では、制御用端末103は、データ格納手段102に格納されている自クライアントノード80のデータを取り出し、クライアントノード認証情報を生成し、ネットワーク監視用サーバ72に送信する。ここで、クライアントノード認証情報は、例えば、クライアントノード識別情報(ID)、クライアントノード認証用パスワード(PASS)、クライアントノードの位置情報(位置)である。クライアントノード認証情報を受信したネットワーク監視用サーバ72は、クライアントノードエントリデータベース74にクライアントノード認証情報と一致するクライアントノードエントリ情報があるかどうかの問い合わせを行う。この際、あらかじめクライアントノードエントリデータベース74に格納されている位置情報と、現在送信されてきたクライアントノード認証情報に含まれる位置情報の間にどれだけの誤差を認めるかどうかは、システム運用を行う通信事業者の判断するセキュリティレベルに依存する。通常は、メートルオーダーの精度で十分な運用が可能と考えられる。
第3の手順では、ネットワーク監視用サーバ72は、クライアントノードエントリデータベース74に問い合わせを行い、クライアントノードエントリデータベース74に、正常に登録されているクライアントノードであることが確認できた場合には、ネットワーク監視用サーバ72は、測位衛星97から随時送信されてくる制御用端末103の地理的データである位置情報を、位置情報受信手段76から受信する。
第4の手順では、ネットワーク監視用サーバ72はネットワーク監視サーバデータベース75に格納されている自身のIDとパスワードを取り出し、認証データを生成し、クライアントノードに送信する。ここで、ネットワーク監視用サーバ72がクライアントノードに送信する認証データの構成は、例えば、ネットワーク監視用サーバ72の識別除法(ID)、ネットワーク監視用サーバ72のパスワード(PASS)、および、ネットワーク監視用サーバ72の位置情報である。
第5の手順では、ネットワーク監視用サーバ72からクライアントノード認証情報を受け取ったクライアントノード80は、自身のデータ格納手段102に格納されているネットワーク監視用サーバ72の情報と照合し、一致した場合のみ、ネットワーク監視用サーバ72に対して、すでにP2Pネットワークに参加しているクライアントノード80の情報を要求すると共に、自身のIPアドレスを送信する。
第6の手順では、このデータ情報を受信したネットワーク監視用サーバ72は、クライアントノードエントリデータベース74内の自己のクライアントノード80のIPアドレス情報を更新し、接続可能フラグを有効にした後、すでにP2Pネットワークに参加している他のクライアントノードの情報をクライアントノード80側の制御用端末103に送信する。ネットワーク監視用サーバ72からクライアントノード80へ送信される他のクライアントノードの情報は、例えば、クライアントノード識別情報(ID)、クライアントノードの認証用パスワード(PASS)、クライアントノードの位置情報、クライアントノードのIPアドレス、接続可能フラグ、又は、ノード情報更新日時、或いはこれらの組み合わせである。
以上述べた手順により、クライアントノード80のP2Pネットワークへの参加が実現できる。なお、この後で、クライアントノード80が、ネットワーク監視用サーバ72から受信した他のクライアントノードの情報を元に、他のクライアントノードに接続する場合、互いのクライアントノード識別情報、クライアントノード認証用パスワード、位置情報等を照合することにより、クライアントノード相互間での認証が実現できる。また、クライアントノード間の接続後の通信においては、常時、クライアントノード80自身の位置情報を、通信相手のクライアントノードに対して送信し、位置情報を、相互に照合することにより、認証を行うことが好ましい。また、他のクライアントノードに接続する際は、接続可能フラグが有効になっているクライアントノードに対してのみ接続が可能である。
(実施例2)
図8は、実施例2に係るネットワークデータ分散共有システムの構成概略図である。図9は、実施例2に係るネットワークデータ分散共有システムのデータシーケンスである。図8及び図9に、一度、正常に、ネットワーク監視用サーバに認証されたクライアントノードが、接続中、もしくは前回に、接続した後に、パスワードもしくはIPアドレスを変更した場合の動作例を示す。
第1の手順では、自己のクライアントノードのパスワード又はIPアドレスの変更を行うクライアントノードを、図8では情報変更要求クライアントノード84と呼ぶこととする。また、すでにネットワーク監視用サーバ72に認証を受け、P2Pネットワークに参加しているクライアントノードを、既存クライアントノード85とする。情報変更要求クライアントノード84は、図6に示す方法で、ネットワーク監視用サーバ72に接続を行う。この際、変更する内容がパスワードである場合は、認証時に用いるパスワードは変更前のものを用いる。その後、情報変更要求クライアントノード84はネットワーク監視用サーバ72に対して、情報変更要求信号を発信し、引き続いて、変更する項目(IPアドレス、もしくは位置情報、パスワード、あるいはこれらの情報の全て)を送信する。ネットワーク監視用サーバ72は前述の信号を受信し、クライアントノードエントリデータベース74内の情報変更要求クライアントノード84の情報を更新する。この手順により、ネットワーク監視用サーバ72側の情報の更新が完了する。この際、ネットワーク監視用サーバ72は、情報変更要求クライアントノード84の情報の更新日時も更新する。
第2の手順では、すでにP2Pネットワークに参加している既存クライアントノード85が情報変更要求クライアントノード84に対して、接続を試みたとする。この場合、第1の手順での更新手順が終了する前の段階では、既存クライアントノード85がP2Pネットワーク参加時に、ネットワーク監視用サーバ72から受信した情報変更要求クライアントノード84の情報と、現在の時点で保持されている実際の情報変更要求クライアントノード84の情報に、不一致が生じる。例えば、情報変更要求クライアントノード84がIPアドレスを変更したとすると、既存クライアントノード85は接続が不可能になり、情報変更要求クライアントノード84がパスワードもしくは位置情報を変更した場合にも、既存クライアントノード85は情報変更要求クライアントノード84を正常に認証することが不可能となる。
第3の手順では、既存クライアントノード85は、ネットワーク監視用サーバ72に、情報変更要求クライアントノード84の最新情報を取得するために、問い合わせを行う。この際に、既存クライアントノード85は図6で示した方法でネットワーク監視用サーバ72に接続を行う。そして、既存のクライアントノード85は、ネットワーク監視用サーバ72に対して、情報変更要求クライアントノード84のクライアントノード識別情報(ID)、及び情報更新要求信号を送信する。
第4の手順では、ネットワーク監視用サーバ72は、情報更新要求信号を受信する。そして、ネットワーク監視用サーバ72は、クライアントノードエントリデータベース74から情報変更要求クライアントノード84のクライアントノード識別情報に該当するクライアントノードの情報を検索し、情報変更要求クライアントノード84の情報を既存クライアントノード85に送信する。ここで、ネットワーク監視用サーバ72の送信する情報は、例えば、クライアントノード識別情報(ID)、クライアントノード認証用パスワード(PASS)、クライアントノードの位置情報(位置)、クライアントノードのIPアドレス、接続可能フラグ、又は、ノード情報更新日時、或いはこれらの組み合わせである。
第5の手順では、ネットワーク監視用サーバ72から情報変更要求クライアントノード84の最新の情報を受け取った既存クライアントノード85は、再度、情報変更要求クライアントノード84に対して接続を行う。ここで、パスワードもしくはGPS情報の不一致が起こった場合には、情報変更要求クライアントノード84は不正なクライアントノードとして検出される。この際には、不正クライアントノードを、どのように処置するかは、システム管理を行う通信事業者の判断に委ねられる。既存クライアントノード85は、不正クライアントノードの情報に加えて、不正クライアントノードの検出信号をネットワーク監視用サーバ72に送信し、不正クライアントノードの検出信号を受信したネットワーク監視用サーバ72は、クライアントノードエントリデータベース74から不正クライアントノードのエントリを削除することが好ましい。
以上述べた手順により、すでにP2Pネットワークに参加している、その他の既存クライアントノードが、不正なクライアントノードに接続することを、未然に防止することが可能となる。また、クライアントノード間での接続が、できなかった場合には、情報変更要求クライアントノード84が故障しているなどの可能性が考えられる。この場合には、既存クライアントノード85はネットワーク監視用サーバ72に対して、情報変更要求クライアントノード84のクライアントノードIDに加えて、接続不可フラグ信号を送信することが好ましい。接続不可フラグ信号を受信したネットワーク監視用サーバ72は、情報変更要求クライアントノード84のクライアントノードIDに該当するクライアントノードのエントリを検索し、そのエントリの接続可能フラグを無効にすることが可能である。この場合、ネットワーク監視用サーバ72は、クライアントノード情報のクライアントノード情報更新日時も更新することも可能である。以上述べた手順により、この後で、P2Pネットワークに参加を行う、他の既存クライアントノードが、無駄に接続のための試行を行うことを、未然に防ぐことが可能となる。
情報変更要求クライアントノード84が、多数存在する場合には、ネットワーク監視用サーバ72への負荷集中が問題となる。この問題に対処する方法としては、例えば、クライアントノード間で、接続を確立した際に、互いの保持している他のクライアントノード情報を交換する方法も可能である。クライアントノード情報の交換の際には、クライアントノード更新日時が、新しい情報で、上書きされるように制御する必要がある。この手順をとることにより、後から、P2Pネットワークに参加するクライアントノードから、既存のクライアントノードが、最新の、他のクライアントノード情報を受信することも可能となり、ネットワーク監視用サーバ72へのトラヒック負荷を軽減することが可能となる。
(実施例3)
図10は、実施例3に係るネットワークデータ分散共有システムの構成概略図である。図11は、実施例3に係るネットワークデータ分散共有システムのデータシーケンスである。図10及び図11は、正常にネットワーク監視用サーバ72に認証されたクライアントノードに対して、後からP2Pネットワークに参加してきたクライアントノード86が接続する場合の例を示している。既存クライアントノード85がネットワーク監視用サーバ72に認証を受けた時点では、クライアントノード86はクライアントノードエントリデータベースに登録されていなかった場合、既存クライアントノード85にとってクライアントノード86は未知クライアントノードとなる。
第1の手順では、クライアントノード86から認証データがクライアントノード85に対して送信される。ここで、認証データは、クライアントノードがネットワーク監視用サーバ72に送信するクライアントノード認証情報と同様の情報である。このクライアントノード認証情報を受け取った既存クライアントノード85は、自身の所持している他のクライアントノード情報のリストの中にクライアントノード86の情報がないことを検出する。この場合、既存クライアントノード85は図6に示した方法でネットワーク監視用サーバ72に接続を行う。
第2の手順では、ネットワーク監視用サーバ72に対してクライアントノード86のクライアントノードID、及びクライアントノード情報要求信号を送信する。
第3の手順では、ネットワーク監視用サーバ72はクライアントノード情報要求信号を受け、クライアントノードエントリデータベース74からクライアントノード86のクライアントノードIDに該当するクライアントノードのエントリ情報を探し出し、クライアントノード情報を、既存クライアントノード85に送信する。ここで、ネットワーク監視用サーバ72から既存クライアントノード85へ送信される他のクライアントノード86の情報は、例えば、クライアントノード識別情報(ID)、クライアントノードの認証用パスワード(PASS)、クライアントノードの位置情報(位置)、クライアントノードのIPアドレス、接続可能フラグ、又は、ノード情報更新日時、或いはこれらの組み合わせである。この時、クライアントノードエントリデータベース74に登録されていないクライアントノードの場合は、データが受信できないため、あるタイミング後に、既存クライアントノード85は通信を切断する。ネットワーク監視用サーバ72からクライアントノード86の情報を受信した既存クライアントノード85は、クライアントノード86から送信されてきたクライアントノード認証情報とネットワーク監視用サーバ72から受信したクライアントノード86のデータを照合し、一致した場合のみ、既存クライアントノード85自身のクライアントノード認証情報を送信することにより、認証処理を行う。ここで、クライアントノード認証情報は、例えば、クライアントノード識別情報(ID)、クライアントノードの認証用パスワード(PASS)、又は、クライアントノードの位置情報、或いはこれらの組み合わせである。
(実施例4)
図12は、実施例4に係るネットワークデータ分散共有システムの構成概略図である。図13は、実施例4に係るネットワークデータ分散共有システムのデータシーケンスである。図12及び図13にデータ配信元クライアントノード81がP2Pネットワークに対してファイルデータを公開する場合のシーケンス例を示す。データ配信元クライアントノード81は、自身のクライアントノードID、公開する予定のファイルデータのファイル名、公開する予定のファイルデータのトータルデータサイズ、公開する予定のファイルデータのトータルデータチェックサム値を含むファイル配信メタデータを生成する。公開するファイルデータのチェックサム値の算出にはファイルデータの一意性を保障するハッシュ関数を用いることが好ましい。この際に、用いるハッシュ関数としてはMD5(Message Digest Algorithm 5)などが適用可能であるが、これに限定されるものではない。この場合、前述したように、特定のクライアントノードIDを持つクライアントノードにのみデータを公開する場合、自由配信許可フラグを無効にし、データ要求クライアントノードをデータ配信元クライアントノード81自身で認証することが好ましい。
また、データ配信元クライアントノード81は、上記のデータの公開を許可するクライアントIDを、ファイル配信メタデータのデータ内の、受信許可ノードID部に追加する。このデータ受信許可ノードID部に含まれるクライアントノードIDを持つクライアントノードのみが、データ配信元クライアントノード81の公開するファイルデータを受信することが可能となる。その後、データ配信元クライアントノード81は図6に示した方法で、ネットワーク監視用サーバ72に接続し、ファイル配信メタデータを送信する。この際、ネットワーク監視用サーバ72に送信されるファイル配信メタデータは、データ配信元クライアントノード81自身で管理するファイル配信メタデータとは、一部データ構成が異なり、図3に示すように、ファイル配信メタデータの構成からデータ受信許可クライアントノードID部が除去されたものである。このファイル配信メタデータを受信したネットワーク監視用サーバ72は、ファイルエントリデータベース73にこのファイル配信メタデータを登録する。
ネットワーク監視用サーバ72は、登録を要求されたファイル配信メタデータ内のファイルチェックサム値と同一のファイルチェックサム値を持つファイル配信メタデータが、ファイルエントリデータベース73にすでに登録されていないかどうかをチェックする。すでに登録されている場合には、データ配信元クライアントノード81による登録を拒否することも可能である。この手順を用いることにより、オリジナルのデータ配信元の一意性が保たれ、不正なデータ配信元を排除することが可能となる。
第1の手順では、データ配信元クライアントノード81は、ファイル配信メタデータをファイルエントリデータベース73に登録した後、公開するファイルデータを任意の数に分割する。この時に、分割しないことも可能である。図12に示した例では分割数を3としている。この場合、データ配信元クライアントノード81は公開するファイルデータを例えば、3つに分割することによって、データピース1、データピース2、データピース3が生成される。その後、データ配信元クライアントノード81はデータピースを暗号化するための暗号鍵を生成する。暗号鍵は1つでもよいが、各々のデータピースに対して別々の暗号鍵を用いるのがセキュリティ上は好ましい。データ配信元クライアントノードはその後、生成した暗号鍵で各々のデータピースを暗号化する。暗号化したデータピースには、暗号化したデータピース自身のハッシュ値をファイル名として与える。このときに、使用するハッシュ関数としては例えばMD5(Message Digest Algorithm 5)が使用可能であるが、このハッシュ関数に限定されるものではない。この場合、データ配信元クライアントノード81は、データピースと暗号鍵の対応関係をファイル配信メタデータに記録する。すべてのデータピースの暗号化を終えた後に、データ配信元クライアントノード81は、暗号化したデータピースの配信先となるデータピースクライアントノード82a、82b、82cを選定し、入手したデータピースクライアントノード82a、82b、82cの情報を用い、これらとの接続および認証を行った後、先ず、ファイル配信メタデータをネットワーク監視用サーバ72に送出する。
第2の手順では、データ配信元クライアントノード81は、データピースクライアントノード82a、82b、82cに対してデータピースの配信を行う。各データピースの配信を行う際は、データピースのサイズなどを、事前にデータピースクライアントノード候補となるクライアントノードに送信し、受信可能かどうかを問い合わせることが好ましい。この手順を用いることにより、データピースクライアントノードに対して、データピースの配信が完了した後に、データ配信元クライアントノードは自身の管理するファイル配信メタデータにどのデータピースをどのクライアントノードIDをもつクライアントノードに配信したかを記録する。この際、一つのデータピースに対して複数のデータピースクライアントノードが存在する場合も可能である。なお、データピースの送信が完了した後に、ファイル配信メタデータを生成しファイルエントリデータベースにこのファイル配信メタデータを登録することが、好ましい。
第3の手順では、データピースの配信を完了したデータ配信元クライアントノード81は、自身の管理しているファイル配信メタデータとファイルエントリデータベース73内のファイル配信メタデータとの整合性を取るため、図6に示す手順でネットワーク監視用サーバ72に接続し、最新のファイル配信メタデータを送信する。この情報を受信したネットワーク監視用サーバ72はファイルエントリデータベース73内に存在するファイル配信メタデータを更新する。以上述べた処理手順によって、データ配信元クライアントノード81のP2Pネットワークに対してのファイル公開が実現できる。
(実施例5)
図14は、実施例5に係るネットワークデータ分散共有システムの構成概略図である。図15は、実施例5に係るネットワークデータ分散共有システムのデータシーケンスである。図14及び図15に、データ要求クライアントノード83が、受信を希望するファイルデータを取得する際の動作例およびシーケンス例を示す。第1の手順では、データ要求クライアントノード83は、図6に示す方法で入手した、他のクライアント情報を活用して、データ配信元クライアントノード81もしくはネットワーク監視用サーバ72に対して接続する。
第2の手順では、認証が成功した場合には、データ要求クライアントノード83は、配信を希望するファイルデータのファイル配信メタデータを受信することが可能である。ファイル配信メタデータの自由配信許可フラグが無効である場合には、ネットワーク監視用サーバ72はファイル配信メタデータを送信せず、データ要求クライアントノード83に対して、データ配信元クライアントノード81からファイル配信メタデータを受信するように指示することが好ましい。この時に、データ要求クライアントノード83がデータ配信元クライアントノード81もしくはネットワーク監視用サーバ72から受信するファイル配信メタデータは暗号鍵のデータ部を除去した情報データが送信される。
図16は、データ要求クライアントノード83に送信されるファイル配信メタデータの構成例である。ファイルデータが3つに分割されたときのめたデータ構成例であり、ファイルデータは2つ以下に分割されていてもよいし、4つ以上に分割されていてもよい。また、分割されていなくてもよい。さらに、1つのファイルデータに対するデータピースクライアントノードIDは複数個持つことが可能である。このファイル配信メタデータを受信したデータ要求クライアントノード83は、ファイル配信メタデータの内容に基づいて、データピースを保持する各データピースクライアントノード82a、82b、82cへの接続を試みる。
第3の手順及び第4の手順では、データ要求クライアントノード83は、例えば、データピースごとに、トータルサイズと、自由配信許可フラグのトータルデータチェックサムとを受信する。図14に示す動作例では、データ要求クライアントノード83が受信したファイル配信メタデータは図16に示される構成を想定し、データ要求クライアントノード83はデータピースクライアントノード82aのID1、データピースクライアントノード82bのID2、データピースクライアントノード82cのID3を持つクライアントノードに対して接続し、データピースクライアントノード82a、82b、82cから、ファイル配信メタデータに記述されたデータピースファイル名に合致するファイル名を持つデータピースを受信する。データピースの受信が完了した後は、実際に受信したデータピースのハッシュ値とデータピースのファイル名を比較し、一致した場合は、データピースノードから正常にデータピースを受信できたと判断し、データピースクライアントノードに対して、受信完了を通知する。この情報を受け取ったデータピースクライアントノード82a、82b、82cは、データ分散の履歴情報にデータ要求クライアントノード83のIDを追加し、データ分散の履歴情報を更新することが好ましい。図14の例では、データ要求クライアントノード83は、データピースクライアントノード82a及びデータピースクライアントノード82bから正常にデータピースを受信した場合を想定している。
第5の手順では、データ要求クライアントノード83が、データピースクライアントノード82cに対して接続し、データピース3の送信を要求する。そして、第6の手順では、データピース3クライアントノードは、例えば、ビジー状態にあり、データ要求クライアントノード83に対して、データピースを送信できない時には、データピースクライアントノード82cは自己の管理しているデータ分散の履歴情報を参照し、データ要求クライアントノード83にデータピース代替データピースクライアントノード82c’のクライアントノード識別情報(代替データピースクライアントノードID)を送信する。
そして、第7の手順では、この情報を受信したデータ要求クライアントノード83は、データピースクライアントノード82cとの接続を切断し、代替データピースクライアントノードIDを持つクライアントノード82c’に接続し、この代替えデータピースクライアントノード82c’からデータピース3を受信する。データピース3の受信が完了した後は、データ要求クライアントノード83は、実際に受信したデータピース3のハッシュ値とデータピース3のファイル名を比較し、一致した場合は、代替データピースクライアントノードIDから正常にデータピースを受信できたと判断し、データピース3クライアントノードに対して、受信完了を送信する。このような手順で、全てのデータピースがそろった後、データ要求クライアントノード83はファイル配信メタデータに記述されたデータ配信元クライアントノードに対して接続を試みる。
第8の手順では、認証に成功し、データ配信元クライアントノードに接続したデータ要求クライアントノード83は、データ配信元クライアントノード81に対して、データピースのファイル名を送信する。第9の手順では、データ配信元クライアントノード81ではデータピースのファイル名に対応する暗号鍵を保持しているため、この暗号鍵をデータ要求クライアントノード83に対して送信する。この場合にも、公開鍵暗号方式を適用することが好ましい。
図14及び図15の例で、データ要求クライアントノード83がデータ配信元クライアントノード81に対して暗号鍵を取得するために接続を行った時点で、何らかの原因によってデータ配信元クライアントノード81が故障していた場合の動作を例に以下に、説明する。
第10の手順では、データ要求クライアントノード83は図6に示した方法でネットワーク監視用サーバ72に接続し、ネットワーク監視用サーバ72に対してデータ配信元クライアントノード81のID、ファイル名、データピースのファイル名を送信する。第11の手順では、この情報を受信したネットワーク監視用サーバ72は、ファイルエントリデータベース73内からデータ配信元クライアントノード81のIDとファイル名を含むファイル配信メタデータを検索し、発見したファイル配信メタデータの内容に基づいて、暗号鍵をデータ要求クライアントノード83に送信する。この場合には、前述した第8の手順及び第9の手順のシーケンスの代わりに、第10の手順及び第11の手順のシーケンスが置き換えられる。上記の手順を用いることにより、データ配信元クライアントノード81、もしくはネットワーク監視用サーバ72から暗号鍵を受信したデータ要求クライアントノード83は、受信後にファイルデータとしてデータ要求クライアントノード83のデータ格納手段には保存はせず、主記憶(メインメモリ)に保持したまま、即座にデータピースの復号化処理に用いる。復号化処理が終了し、必要のなくなった暗号鍵は、即座に主記憶上から消去されるようにすることが好ましいことは、前述したとおりである。全てのデータピースの復号化を完了したデータ要求クライアントノード83は、復号化した各々のデータピースを結合し、その後に、結合後のファイルデータのトータルデータサイズ、トータルチェックサムを計算し、ファイル配信メタデータ内に記述されているトータルデータサイズ、及びトータルチェックサムと一致するかどうかを確認する。一致した場合には、ファイルデータの受信が成功したものと判断できる。
(実施例6)
図17は、実施例6に係るネットワークデータ分散共有システムの構成概略図である。図18は、実施例6に係るネットワークデータ分散共有システムのデータシーケンスである。図17及び図18に、データ配信元クライアントノード81がP2Pネットワークへのファイルデータの公開を停止する場合の動作例およびシーケンス例を示す。第1の手順では、データ配信元クライアントノード81は図6に示す方法でネットワーク監視用サーバ72に接続し、認証を受けた後に、ネットワーク監視用サーバ72に対して、公開を中止したいファイルデータのファイル配信メタデータの公開停止命令を送信する。例えば、ファイルデータの公開の停止を要求する公開停止命令信号を、ファイルデータの名称及び認証情報と共に送信する。認証情報は、例えば、IPアドレス、位置情報又はパスワードあるいはこれらの組み合わせである。ネットワーク監視用サーバ72は、ファイル配信メタデータの公開停止命令信号を受信すると、クライアントノードエントリデータベース74を参照して認証を行う。認証が成功すると、ネットワーク監視用サーバ72は、ファイルエントリデータベース73から、公開停止命令のあったファイルデータのファイル配信メタデータを削除する。また、ファイル配信メタデータに自由配信許可フラグが含まれている場合には、自由配信許可フラグの設定を有効から無効に変更することでファイルデータの公開を停止してもよい。
第2の手順では、ファイルエントリデータベース73からファイルデータのファイル配信メタデータを削除したネットワーク監視用サーバ72は、データ配信元クライアントノード81に対して、ファイル配信メタデータの削除完了を通知する。この通知を受信したデータ配信元クライアントノード81は、自身の管理するファイル配信メタデータの削除を行う。以上、述べた手順により、データ配信元クライアントノード81によるファイルデータの公開を中止することが実現できる。P2Pネットワーク内にはすでに複数のデータピースが分散されている可能性があるが、このデータピースを復号化するための暗号鍵がP2Pネットワーク内から完全に消去されるため、実質的には、意味を成さないデータとなり、これらデータが、ネットワーク内に流通し、ネットワーク内の他の通信トラヒックを圧迫するような影響をもつことはない。
(実施形態2)
図19は、本実施形態に係るネットワークデータ分散共有システムの一例を示す構成図である。ネットワークデータ分散共有システム92は、実施形態1で説明したネットワーク監視用ノード71とデータ配信元クライアントノード81の機能が異なっている。ネットワーク監視用ノード71は、実施形態1で説明したネットワーク監視用ノード71に加え、さらにメタデータ送信手段31を備える。すなわち、ネットワーク監視用サーバ72と、ファイルエントリデータベース73と、クライアントノードエントリデータベース74と、ネットワーク監視サーバデータベース75と、クライアントノード認証手段32と、メタデータ送信手段31と、を備えている。また、データ配信元クライアントノード81は、実施形態1で説明したメタデータ送信手段13を用いない。すなわち、データ配信元クライアントノード81は、メタデータ記憶手段11と、クライアントノード認証情報問合せ手段14と、暗号鍵送信手段15と、暗号鍵発生手段21と、データピース生成手段22とを備えている。また、データ要求クライアントノード83は、データピース収集手段16と、暗号化ファイルデータ復元手段17と、を備える。データ要求クライアントノード83は、さらに、データ配信元問合せ手段18と、データ要求手段12と、暗号化判別手段19と、非暗号化ファイルデータ復元手段20と、を備えることが好ましい。暗号化ファイルデータ復元手段17は、暗号鍵取得手段を備えることが好ましい。
メタデータ送信手段31は、データ要求クライアントノード83のデータ要求手段12からファイルデータの要求を受けると、ファイルエントリデータベース73を参照し、要求のあったファイルデータについてのファイル配信メタデータをデータ要求クライアントノード83へ送信する。メタデータ送信手段31の送信したファイル配信メタデータは、データ要求クライアントノード83のデータピース収集手段16に入力される。データピース収集手段16の機能及び動作は、実施形態1と同様である。ファイル配信メタデータは、データ配信元クライアントノード81だけでなく、ネットワーク監視用ノード71も蓄積し、ネットワーク監視用ノード71でも管理されている。このため、暗号鍵を除いては、ネットワーク監視用ノード71からもファイル配信メタデータをデータ要求クライアントノード83に配信することができる。ネットワーク監視用ノード71がファイル配信メタデータを直接データ要求クライアントノード83へ提供することで、データ配信元クライアントノードの負荷を減らすことができる。どのコンテンツの人気がいつ高まるかは不明であるので、あらかじめクライアントノード端末の負荷を減らしておくことで、コンテンツ配信サービスの品質を維持することができる。
以上述べたように、実施形態1及び実施形態2により、P2Pによるネットワークメカニズムとファイル分散技術および暗号による相互認証技術とを、効果的に活用することにより、不正なコンテンツが流通することを防止すると共に、ファイルデータの配信元の著作権を、保護できる効果的なファイル共有の手段を提供することが可能となる。また、実施形態1及び実施形態2により、P2Pメカニズムを活用して、ネットワーク内に流出したファイルデータを、ネットワークから事実上、消去することも可能とし、かつ、ネットワーク内での情報の流通を、通信事業者による安全な管理のもとで、効率的に運用すること可能とするものである。また、ネットワーク上で、無効なトラヒック負荷をネットワーク通信事業者の判断で制御することも可能である。また、実施形態1及び実施形態2により、P2P技術によるファイルデータの交換を、安全化することが可能となり、更に、ネットワーク内でのトラヒック負荷分散を、同時に実現することができる手段を提供することができるため、ネットワークを、構築および運用する通信事業者にとっては、ネットワーク資源を経済的に使用できるための有効な手段として活用し、かつ、登録されたユーザ間では、トラヒックの流通が、効果的に実現でき、両者にとって、利益の高いファイルデータの共有手段を提供することが可能となる。
(実施形態3)
図20は、本実施形態に係るネットワークデータ分散共有システムの一例を示す構成図である。ネットワークデータ分散共有システム93は、実施形態1で説明したネットワークデータ分散共有システム91に加え、さらに、データピースクライアントノード82a、82a’、82a”、82b、82b’、82b”、82c、82c’、82c”を備える。また、ネットワーク監視用ノード71は、優先順位格納データベース77を備える。
図20に示す優先順位格納データベース77は、データピースの取得先となるデータピースクライアントノードの優先順位を優先順位メタデータとして格納する。優先順位格納データベース77は、ファイルエントリデータベース73、クライアントノードエントリデータベース74、ネットワーク監視サーバデータベース75と同様、ネットワーク監視用サーバ72に接続される。優先順位格納データベース77は、ファイルエントリデータベース73と統一した1つのデータベースとすることも可能である。
ネットワーク監視用サーバ72は、データ要求クライアントノード83のデータ配信元問合せ手段から問い合わせを受けると、優先順位格納データベース77を参照し、データ要求クライアントノード83に関連する優先順位メタデータを抽出して、データ要求クライアントノード83に送信する。
図21は、データピースクライアントノードの格納するデータピースの一例である。実施形態1で説明したように、データ配信元クライアントノード81は、1個のファイルデータをデータピース1、データピース2及びデータピース3に分割する。論理的には、ファイルデータ=データピース1+データピース2+データピース3である。ファイルデータが3つのデータピース1、データピース2及びデータピース3に分割された時に、各々のデータピースが、それそれ、3つ分に、コピーされる。たとえば、データピース1は、データピース1’およびデータピース1”にコピーされる。ファイルデータ=データピース1’+データピース2’+データピース3’とも同等であり、また、ファイルデータ=データピース1”+データピース2”+データピース3”とも同等である。これらは結合され、その後に、ファイルデータを復元するための暗号鍵を用いて元のファイルデータに復元することができる。
データピースは、それぞれ、実施形態1で説明したように、異なるデータピースクライアントノードに格納される。たとえば、データピース1、1’、1”は、それぞれ、データピースクライアントノード82a、82a’、82a”へ転送され、格納される。データピース2、2’、2”は、それぞれ、データピースクライアントノード82b、82b’、82b”へ転送され、格納される。データピース3、3’、3”は、それぞれ、データピースクライアントノード82c、82c’、82c”へ転送され、格納される。
同一のデータピース1をコピーすることによって生じたデータピース1、1’、1”は、同一の暗号鍵で暗号化してもよいし、異なる暗号鍵で暗号化してもよい。たとえば、データピース1、1’、1”が同一の暗号鍵で暗号化されていれば、同一のデータピース1をコピーすることによって生じたデータピース1’が消失した場合であっても、データ要求クライアントノード83は、データピース1と同一の暗号鍵を用いてファイルデータを復元することができる。一方で、データピース1、1’、1”が異なる暗号鍵で暗号化されていれば、データ要求クライアントノード83は、それぞれ固有の暗号鍵を用いなければファイルデータを復元することができないので、安全性を確保することができる。
データ要求クライアントノード83は、実施形態1で説明したように、データピースを収集し、ファイルデータを復元する。本実施形態では、データ要求クライアントノード83は、さらに、ネットワーク監視用ノード71からの優先順位メタデータに基づき、{データピース1、データピース1’、データピース1”}の中から任意の1つのデータピースを受信し、{データピース2、データピース2’、データピース2”}の中からも任意の1つのデータピースを受信し、{データピース3、データピース3’、データピース3”}の中からも任意の1つのデータピースを受信して、要求するファイルデータを復元する。優先順位が1位となっているデータピースがデータピース1、データピース2’及びデータピース3”であれば、データ要求クライアントノード83は、データピースクライアントノード82aに格納されているデータピース1、データピースクライアントノード82b’に格納されているデータピース2’及びデータピースクライアントノード82c”に格納されているデータピース3”を収集し、ファイルデータを復元することができる。
ここで、暗号鍵は、データ配信元クライアントノード81からデータ要求クライアントノード83へ提供されることを基本とする。しかしながら、データ配信元クライアント81の故障の場合に備え、ファイル配信メタデータに記述されるデータピース毎に、暗号鍵を、ファイルエントリデータベース73内に、事前に格納する構成をとることも同様に可能である。ファイル配信メタデータは、ファイルエントリデータベース73内に、複数個、格納され、適切に、通信事業者により、管理し運営されることが好ましい。
図22は、実施形態3に係るネットワークデータ分散共有システムの具体的な一例を示す構成図である。実施形態2で説明した実施形態2で説明したネットワークデータ分散共有システム92に、さらに、優先順位格納データベース77、応答遅延時間測定用データ送受信手段35、メタデータ登録手段36、メタデータ登録要求手段23を備える。また、メタデータ送信手段31に代えて優先順位メタデータ送信手段31’を、データピース生成手段22に代えてデータピース生成手段22’を備える。
図22に示す優先順位格納データベース77は、データ要求クライアントノード83にデータピースを取得させるデータピースクライアントノード82a、82a’、82a”、82b、82b’、82b”、82c、82c’、82c”の優先順位を優先順位メタデータとして格納する。優先順位として、どのデータピースを選択的に受信すれば、最も短い、配信遅延時間で、迅速にファイルを入手できるかを決定することが、ネットワークのリソースの有効活用とユーザの利便性の面では重要である。このため、優先順位は、配信遅延時間の短い順位であることが好ましい。
図23は、データピース1、1’、1”についての優先順位メタデータの一例である。優先順位メタデータは、データピース1、1’、1”それぞれについての最新の応答遅延時間、応答遅延時間の平均及び優先順位を含む。最新の応答遅延時間は、たとえばデータピース1であれば、データピース1を格納しているデータピースクライアントノード82aとネットワーク監視用ノード71の最新の応答遅延時間である。応答遅延時間の平均は、たとえばデータピース1であれば、データピースクライアントノード82aとネットワーク監視用ノード71の応答遅延時間の平均である。優先順位は、データピース1、1’、1”内での最新の応答遅延時間の短い順である。優先順位メタデータは、図23に示すように、データピース1、1’、1”が格納されているデータピースクライアントノード82a、82a’、82a”のID(識別情報)とともに、ファイル配信メタデータの内容も含むことが好ましい。たとえば、優先順位メタデータには、データピース1、1’、1”のチェックサム、データピース1、1’、1”の暗号鍵も含むことが好ましい。
図23において、優先順位メタデータは、ファイル配信メタデータとともに格納されていてもよい。たとえば、ファイルデータのファイル名と、ファイルデータのトータルサイズと、データピースごとのファイル名、チェックサム及び暗号鍵が、データピースが格納されているデータピースクライアントノードの識別情報、最新の応答遅延時間、応答遅延時間の平均及び優先順位とともに、ファイルエントリデータベース73または優先順位格納データベース77に格納される。なお、ファイル配信メタデータは、ファイル名、および各データピース名は、ハッシュ値で格納しておくことが好ましい。また、優先順位メタデータは、ファイルエントリデータベース73又はメタデータ記憶手段11の記憶するファイル配信メタデータに関わるデータ形式で保持されることが好ましいが、この形式に限定されるものではない。
図23において、データピース1、1’、1”のどれも、内容的には同じ情報に対応しているが、配信遅延時間の面ではもっとも有利と考えられるため、データピース1”を格納しているデータピースクライアントノード82a”の優先順位が1位となっている。データ要求クライアントノード83は、優先順位メタデータを受信することによって、データピース1を格納するデータピースクライアントノード82a、82a’、82a”のうち、優先順位が1位である、すなわち、配信遅延時間の面ではもっとも有利なデータピースクライアントノード82a”からデータピース1”を取得することができる。データピース2、2’、2”及びデータピース3、3’、3”についても、データピース1、1’、1”と同様の優先順位メタデータが作成される。
図22に示す応答遅延時間測定用データ送受信手段35は、優先順位格納データベース77に格納する優先順位メタデータの情報を取得する。たとえば優先順位を決定するための情報を取得する。情報の取得は、一定、または、任意に決定される周期で行うことが好ましく、これにより、優先順位格納データベース77に格納されている優先順位メタデータを、最新の情報に随時更新することができる。
取得した優先順位を決定するための情報は、適切な処理がなされた後に、優先順位格納データベース77に格納される。優先順位格納データベース77に既に格納されているファイルデータであれば、データピースを格納しているデータピースクライアントノード82の優先順位が更新される。優先順位格納データベース77と同様のデータベースが他のクライアントノード、例えばデータ配信元クライアントノード81に格納されている場合は、データ配信元クライアントノード81に格納されている優先順位メタデータも更新する。この場合、優先順位メタデータは、図23に開示した形式で定期的に送ることが好ましい。
優先順位が応答遅延時間で決定される場合、応答遅延時間測定用データ送受信手段35は、全てのデータピースクライアントノード82に対して、PINGなどの応答遅延測定用のデータを配信する。そして、ポーリングを行い、その応答遅延時間を測定する。配信は、たとえば、通信事業者が周期的に行う。この場合、データピースクライアントノード82は、応答遅延時間測定用データ送受信手段35からの、一定、または、任意に決定される周期での、ポーリング等の要求に応答する。
優先順位メタデータ送信手段31’は、実施形態2で説明したように、データ要求クライアントノード83のデータ要求手段12からファイルデータの要求を受けると、ファイルエントリデータベース73を参照し、要求のあったファイルデータについてのファイル配信メタデータをデータ要求クライアントノード83へ送信する。
本実施形態では、優先順位メタデータ送信手段31’は、ファイルデータの要求を受けると、さらに、ファイルデータの要求を行ったデータ要求クライアントノード83に対して、当該ファイルデータに関連する優先順位メタデータを、優先順位格納データベース77から抽出して、データ要求クライアントノード83に提供する。ここで、優先順位メタデータは、ファイル配信メタデータと共通のメタデータとして、データ要求クライアントノード83に送信してもよい。また、優先順位メタデータ送信手段31’は、優先順位メタデータから優先順位が1位となっているデータピースクライアントノード82を抽出して、抽出したデータピースクライアントノード82からデータピースを取得するためのファイル配信メタデータを、データ要求クライアントノード83に提供してもよい。
図22に示すデータ要求クライアントノード83のデータピース収集手段16は、実施形態2で説明したように、ファイル配信メタデータを、優先順位メタデータ送信手段31’から取得する。データピース収集手段16は、優先順位メタデータ送信手段31’から取得したファイル配信メタデータに基づき、データピースクライアントノード82からデータピースを取得する。
本実施形態では、データピース収集手段16は、さらに、ファイル配信メタデータおよび優先順位メタデータを、優先順位メタデータ送信手段31’から取得する。そして、データピース収集手段16は、ファイル配信メタデータおよび優先順位メタデータに基づき、データピースクライアントノード82からデータピースを取得する。ファイル配信メタデータおよび優先順位メタデータを取得することで、優先順位格納データベース77にて管理されている優先順位の高いデータピースクライアントノード82からデータピースを取得することができる。
1つのファイルデータが図21で説明したデータピース1、1’、1”、2、2’、2”、3、3’、3”、に分割されている場合、最初に分割された3つのデータピース1、データピース2、データピース3のそれぞれから、優先順位の高いデータピースを受信する。たとえば、データピース収集手段16は、{データピース1,データピース1’,データピース1”}の中から任意の1つのファイルを受信し、{データピース2,データピース2’,データピース2”}の中からも任意の1つのファイルを受信し、また、{データピース3,データピース3’,データピース3”}の中からも任意の1つのデータピースを受信する。そして、それぞれのデータピースに対応する暗号鍵を、クライアントノード認証情報問合せ手段14および暗号鍵送信手段15を介してデータ配信元クライアントノード81から取得する。これにより、データ要求クライアントノード83は、要求するファイルデータを完全に復元できる。
一方、データ配信元クライアントノード81のデータピース生成手段22’は、実施形態1で説明したように、暗号鍵発生手段21の発生させる暗号鍵を用いてファイルデータを暗号化かつ分割してデータピースを生成させ、さらに暗号化し、当該暗号化したデータピースをデータピースクライアントノード82に格納する。そして、ファイル配信メタデータをメタデータ記憶手段11に記憶させる。
本実施形態では、暗号化したデータピースをデータピースクライアントノード82に格納する際に、データピース生成手段22’は、メタデータ登録要求手段23の取得した優先順位メタデータに基づいて、格納先のデータピースクライアントノード82を決定する。さらに、データピース生成手段22’は、メタデータ登録要求手段23の取得した優先順位メタデータに基づいて、ファイルデータの分割数を決定してもよい。
データ配信元クライアントノード81のメタデータ登録要求手段23は、ネットワーク監視用ノード71に対して、新たに発生させるファイル配信メタデータの登録要求を送信し、ネットワーク監視用ノード71から優先順位メタデータを取得する。たとえば、データピース生成手段22’に新たなファイルデータが入力されると、メタデータ登録要求手段23は、ファイルデータのファイル名やデータ容量などの優先順位を決定するための情報をメタデータ登録手段36に送信する。そして、メタデータ登録手段36から優先順位メタデータを取得する。
ネットワーク監視用ノード71のメタデータ登録手段36は、メタデータ登録要求手段23からファイル配信メタデータの登録要求を受け取ると、優先順位格納データベース77を参照し、当該登録要求のあったファイルデータに応じた優先順位メタデータを抽出し、当該抽出した優先順位メタデータをデータ配信元クライアントノード81に送信する。当該登録要求のあったファイルデータに応じた優先順位メタデータは、たとえば、ファイルデータのファイルサイズに応じた分割数、および、決定した分割数と同数のデータピースクライアントノード82についての情報である。分割数が3であり、優先順位の高いデータピースクライアントノード82が図20に示すデータピースクライアントノード82a’、82b、82c”の場合、メタデータ登録手段36は、優先順位の高いデータピースクライアントノード82a’、82b、82c”の識別情報を抽出し、データピースクライアントノード82a’、82b、82c”の識別情報やIPアドレスなどが格納された優先順位メタデータを送信する。
(優先順位の更新)
図21に示す応答遅延時間測定用データ送受信手段35は、優先順位格納データベース77に格納する優先順位メタデータを更新する。図24は、優先順位が配信遅延時間である場合に、応答遅延時間測定用データ送受信手段がデータピースクライアントノード間での配信遅延時間を取得する手順を示す流れ図である。以下、更新処理の一例について説明する。
第1の手順S111では、ネットワーク監視用ノード71が、優先順位の決定のための初期設定処理を行う。ここで、初期設定処理は、たとえば、優先順位格納データベース77に格納されている情報のリセット、データピースクライアントノードの登録処理である。さらに、応答遅延時間を測定するための応答遅延時間測定用データのネットワークへの配信処理を行う。第2の手順S112では、第1の手順で配信した応答遅延時間測定用データによって測定されたデータピースクライアントノードの応答遅延時間の測定結果を収集する。
第2の手順S112において、各データピースクライアントノードからの応答を受信していれば、第3の手順S113へ移行する。第3の手順S113では、第2の手順S112で受信した応答を、データピースクライアントノードごとに平均を算出する。そして、優先順位格納データベース77の最新の応答遅延時間および応答遅延時間の平均を更新する。第2の手順S112において、データピースクライアントノードからの応答を受信していなければ、第4の手順S114へ移行する。第4の手順S114では、第2の手順S112で配信した応答遅延時間測定用データがすべてのデータピースクライアントノードに送信されたか否かを判定する。
第4の手順S114において、応答遅延時間測定用データがすべてのデータピースクライアントノードに送信されていなければ、第5の手順S115へ移行する。第5の手順S115では、まだ応答遅延時間測定用データを配信していない次のデータピースクライアントノードについて初期設定を行う。第6の手順S116では、第5の手順S115で初期設定を行ったデータピースクライアントノードについて、応答遅延時間を測定するための応答遅延時間測定用データのネットワークへの配信処理を行う。そして、第5の手順S115、第6の手順S116、第2の手順S112および第4の手順S114を、第4の手順S114において、すべてのデータピースクライアントノードに送信されていると判定されるまで繰り返す。
第7の手順S117の手順では、応答遅延時間測定用データに対する応答が、すべてのデータピースクライアントノードからあったか否かを判定する。第7の手順S117の手順において、応答遅延時間測定用データに対する応答が、すべてのデータピースクライアントノードからでない場合、第8の手順S118に移行する。第8の手順S118では、設定タイマーにて設定されている時間が経過しているか否かを判定する。設定されている時間は、たとえば、そのデータピースクライアントノードに応答遅延時間測定用データを送信してから一定の時間である。第8の手順S118の手順において、設定タイマーにて設定されている時間が経過していない場合は、第7の手順S117に移行する。一方、設定タイマーにて設定されている時間が経過している場合は、第9の手順S119に移行する。
第7の手順S117の手順において、応答遅延時間測定用データに対する応答が、すべてのデータピースクライアントノードからあった場合、第9の手順S119に移行する。第9の手順S119では、データ配信元クライアントノード81に対して、優先順位メタデータが更新された旨を通知する。そして、優先順位メタデータの更新を終了する。
上記の優先順位メタデータの更新を行うことによって、応答遅延時間測定用データ送受信手段35は、優先順位格納データベース77に格納する情報を更新することができる。更新は、データ配信元クライアントノード81からの要求に基づいて行ってもよいし、あらかじめ定められた時間ごとに行ってもよい。また、ネットワーク監視用ノード71が複数備わる場合には、優先順位格納データベース77内の情報は、複数のネットワーク監視用ノード71間において、定期的に更新処理されて、運用されることが好ましい。
(優先順位の決定)
以下に、優先順位の具体的な決定例を、データピース1について図20を用いて説明する。上述のように、応答遅延時間測定用データ送受信手段35は、データピースクライアントノード82a、82a’、82a”からの応答遅延時間を測定する。データピースクライアントノード82a、82a’、82a”からの応答遅延時間を、それぞれ、R(82a)、R(82a’)、R(82a”)を表現する。この中でもっとも短い応答遅延時間を、Min1{R(82a),R(82a’),R(82a”)}と表現する。たとえば、図23に示すデータピース1の最新の応答遅延時間であれば、Min1{R(82a”)}=2.5msとなる。同様に、2番目に短い応答遅延時間をもつクライアントノードを、Min2{R(82a),R(82a’),R(82a”)}、3番目に短い応答遅延時間をもつクライアントノードを、Min3{R(82a),R(82a’),R(82a”)}で表現する。もし、冗長化されて分散配備されたデータピースクライアントノード82がN台ある場合は、N番目(Nは正の整数)に短い応答遅延時間をもつデータピースクライアントノード(最も応答の遅いノード)を、MinN{R(82a),R(82a’),R(82a”)……R82a’’’・・・’’’’}で、表現する。このように表現された最新の応答遅延時間を用いて優先順位を決定することができる。
優先順位を決定する際には、最新の応答遅延時間と応答遅延時間の平均とを、ある重み付けによって決定することも可能である。たとえば、データピースクライアントノード82a、82a’、82a”からの平均応答遅延時間が過去のある時点で測定されたときから現在に至るまでの平均遅延時間を、A(82a)、A(82a’)、A(82a”)と表現する。このとき、優先順位の決定に当たっては、重み付け係数を、それぞれ、p、qとして、データピースの取得先の優先順位を以下の式によって、決定することも可能である。
(数1)
これらの値の具体的な決定に際しては、ネットワーク監視用ノード71がネットワークの運用を、適切に行う際に、フレキシブルに決定する決定することも可能である。たとえば、図23の例ではp=2、q=5の場合においても、データピースクライアントノード82a”の優先順位が1位となって選ばれるが、p=1、q=10の場合のように、応答遅延時間の平均値に対して、大きな重み付け係数を掛けて評価する場合には、データピースクライアントノード82aの優先順位が1位となる。その他、応答遅延時間の平均と最新の応答遅延時間に対して、対等に、重み付けの係数を掛ける方法も可能である。なお、優先順位格納データベース77の優先順位の情報を決定する方法は、この方法に限定されない。
(実施形態3における実施例1)
図25は、本実施例に係るネットワークデータ分散共有システムの構成概略図である。図26は、本実施例に係るネットワークデータ分散共有システムのデータシーケンスである。本実施例に係るネットワークデータ分散共有システムでは、データ配信元クライアントノード81が、優先順位メタデータの優先順位に従ってデータピースを送信する。
ネットワークデータ分散共有システム93では、実施形態1で説明したように、データ配信元クライアントノード81がP2Pネットワークに対してファイルデータを公開する。データ配信元クライアントノード81は、ファイル配信メタデータを生成する。ここで、ファイル配信メタデータは、たとえば、データ配信元クライアントノード81自身のクライアントノードID、公開する予定のファイルデータのファイル名、公開する予定のファイルデータのトータルデータサイズ、公開する予定のファイルデータのトータルデータチェックサム値である。公開するファイルデータのチェックサム値の算出にはファイルデータの一意性を保障するハッシュ関数を用いることが好ましい。この際に、用いるハッシュ関数としてはMD5などが適用可能であるが、これに限定されるものではない。
ここで、特定のクライアントノードIDを持つクライアントノードにのみデータを公開する場合、自由配信許可フラグを無効にし、データ要求クライアントノード83をデータ配信元クライアントノード81自身で認証することが好ましい。
第1の手順では、データ配信元クライアントノード81が、1つのファイルデータを3つのデータピース1、2、3に分割する場合に、ネットワーク監視用サーバ72に対して、最も、配信効率が良いと推定されるデータピースクライアントノードに関する問い合わせを行う。この際、ネットワーク監視用ノード71が認証を行うのに必要な情報、たとえば、データ配信元クライアントノード81のクライアントノードIDを送信する。また、データピースごとにデータピースクライアントノードを決定するため、公開予定のファイルデータのファイル名やデータサイズを送信する。
第2の手順では、ネットワーク監視用サーバ72は、データ配信元クライアントノード81からの問い合わせを受けると、優先順位格納データベース77を参照する。たとえば、優先順位格納データベース77には、データピースクライアントノードの組み合わせ{82a,82a’,82a”}、{82b,82b’,82b”}および{82c,82c’,82c”}の組み合わせが格納されている。そして、データピースクライアントノードのそれぞれの組み合わせの中で、データピースクライアントノード82a’、82b、82c”の優先順位が1位となっている場合、ネットワーク監視用サーバ72は、データピースクライアントノードの組み合わせ{82a’,82b、82c”}を抽出し、優先順位メタデータとして、データ配信元クライアントノード81に返送する。
第3の手順では、データ配信元クライアントノード81は、データ配信元クライアントノード81は、第2の手順で受信したデータピースクライアントノードの組み合わせ{82a’、82b、82c”}の識別情報などを含んだファイル配信メタデータを、ネットワーク監視サーバ72に送信する。第4の手順では、データ配信元クライアントノード81は、生成したデータピースを、それぞれ、第2の手順で取得したデータピースクライアントノード82a’、82b、82c”に送信する。第5の手順では、データ配信元クライアントノード81がすべてのデータピースがデータピースクライアントノード82a、82bおよび82c”に送信した後、ネットワーク監視サーバ72に対して、ファイルエントリデータベース73に格納されているファイル配信メタデータの更新指令を送信する。
データ配信元となるデータ配信元クライアントノード81が、公開したいファイルデータを、いくつに分割し、どのデータピースクライアントノードに対して、どのように分散配信するかについての指示は、ネットワーク運用者が、例えば、図23に示す形式のデータをデータ配信クライアントに、送付することにより行うことが好ましい。ネットワーク運用者のみが、最新のネットワークリソースの使用状況を判断できるからである。データ配信元クライアント81は、この指示に、対応して動作するための通信用ソフトウェアを具備することが好ましい。
データ配信元クライアントノード81自身が、任意に当該データピースの配信先を決定することも可能である。この場合、データ配信元クライアントノード81は、ファイルデータの分割を決めた後に、自身の生成した暗号鍵によってファイルデータを暗号化する。データ配信元クライアント81がファイルデータを分割した時は、各々の分割されたデータピース毎に、別々の暗号鍵を用い、データピースのファイル名には、ハッシュ値を用いることが、セキュリティ上、好ましい。データピースのファイル名にハッシュ値を用いた場合は、ファイル配信メタデータ内の各データピースのチェックサム部は省略することも可能である。
(実施形態4)
図27は、本実施形態に係るネットワークデータ分散共有システムの具体的な一例を示す構成図である。本実施形態に係るネットワークデータ分散共有システム94は、実施形態3において説明したネットワークデータ分散共有システム93と、前提とするシステムが実施形態1で説明したネットワークデータ分散共有システム91である点で異なる。すなわち、ネットワークデータ分散共有システム94では、実施形態1で説明したネットワークデータ分散共有システム91に、さらに、優先順位格納データベース77、応答遅延時間測定用データ送受信手段35、優先順位メタデータ送信手段31”、メタデータ登録手段36、メタデータ登録要求手段23を備える。また、メタデータ送信手段13に代えて優先順位メタデータ送信手段13”を、データピース生成手段22に代えてデータピース生成手段22’を備える。
優先順位格納データベース77、応答遅延時間測定用データ送受信手段35、データピース生成手段22’およびメタデータ登録要求手段23およびメタデータ登録手段36については、実施形態3で説明したとおりである。
データ配信元クライアントノード81の優先順位メタデータ送信手段13”は、実施形態1で説明したように、データ要求クライアントノード83のデータ要求手段12からファイルデータの要求を受けると、メタデータ記憶手段11を参照し、ファイルデータについてのファイル配信メタデータをデータ要求クライアントノード83に送信する。
本実施形態では、優先順位メタデータ送信手段13”は、データ要求クライアントノード83からファイルデータの要求を受けると、さらに、優先順位の問い合わせをネットワーク監視用ノード71に行い、ファイルデータの要求のあった当該ファイルデータに関連する優先順位メタデータを、ネットワーク監視用ノード71の優先順位メタデータ送信手段31”から取得する。そして、優先順位メタデータ送信手段13”は、ファイル配信メタデータおよび優先順位メタデータを、データ要求クライアントノード83に送信する。
ネットワーク監視用ノード71の優先順位メタデータ送信手段31”は、優先順位メタデータ送信手段13”から優先順位の問い合わせを受けると、ファイルデータの要求のあったファイルデータに関連する優先順位メタデータを、優先順位格納データベース77から抽出して、優先順位メタデータ送信手段13”に提供する。
データ要求クライアントノード83のデータピース収集手段16は、実施形態1で説明したように、ファイル配信メタデータを、優先順位メタデータ送信手段13”から取得する。そして、データピース収集手段16は、優先順位メタデータ送信手段13”から取得したファイル配信メタデータに基づき、データピースクライアントノード82からデータピースを取得する。
本実施形態では、データピース収集手段16は、さらに、ファイル配信メタデータおよび優先順位メタデータを、優先順位メタデータ送信手段13”から取得する。そして、データピース収集手段16は、ファイル配信メタデータおよび優先順位メタデータに基づき、データピースクライアントノード82からデータピースを取得する。ファイル配信メタデータおよび優先順位メタデータを取得することで、優先順位格納データベース77にて管理されている優先順位の高いデータピースクライアントノード82からデータピースを取得することができる。
(実施形態4における実施例1)
データ要求クライアントノード83がファイルデータを取得するまでの手順を図28及び図29を用いて説明する。図28は、本実施例に係るネットワークデータ分散共有システムの一例を示す構成図である。図29は、本実施例に係るネットワークデータ分散共有システムのデータシーケンスである。ネットワークデータ分散共有システム94は、データ要求クライアントノード83への優先順位メタデータの直接の提供元が、ネットワーク監視用ノード71ではなくデータ配信元クライアントノード81である点でネットワークデータ分散共有システム93と異なる。図28では、簡単のため、データピースクライアントノード82a、82a’、82a”、82b、82b’、82b”、82c、82c’、82c”のうち、各データピースにおいて優先順位が1位となっているデータピースクライアントノード82a’、82b、82c”のみを記載し、他のデータピースクライアントノード82a、82a”、82b’、82b”、82c、82c’は省略した。
第1の手順では、データ要求クライアントノード83は、実施形態1で説明したように、データ配信元クライアントノード81に対して、ファイルデータの要求を行う。この際、データ要求クライアントノード83は、自身のID情報や認証に用いられる情報を送信する。
第2の手順では、データ配信元クライアントノード81は、データ要求クライアントノード83からファイルデータの要求を受信すると、最新の最適なデータピースクライアントノードに関わる優先順位メタデータの取得要求をネットワーク監視用サーバ72に対して送信する。また、データ配信元クライアントノード81は、自身の格納するファイル配信メタデータを取得する。
第3の手順では、ネットワーク監視用サーバ72は、優先順位メタデータの最新情報を優先順位格納データベース77から取得し、優先順位格納データベース77から取得した優先順位メタデータを、データ配信元クライアントノード81に送信する。
第4の手順では、データ配信元クライアントノード81は、ファイル配信メタデータを、優先順位メタデータとともに、データ要求クライアントノード83に送信する。ここで、優先順位メタデータ及びファイル配信メタデータが1つのメタデータとなっている場合は、そのメタデータには、データピースクライアントノード82a’、82b、82c”の優先順位や、データ配信元クライアントノード81である自己のクライアントノードID、公開する予定のファイルデータのファイル名、公開する予定のファイルデータのトータルデータサイズ、公開する予定のファイルデータのトータルデータチェックサム値が含まれる。公開するファイルデータのチェックサム値の算出にはファイルデータの一意性を保障するハッシュ関数としてMD5等を用いることが好ましいが、この方法に限定されるものではない。
また、データ配信元クライアントノード81は、ネットワーク監視用サーバ72から取得した優先順位メタデータに基づいて、メタデータ記憶手段に記憶しているファイル配信メタデータのなかから優先順位の高いデータピース1、2、3の取得先となるデータピースクライアントノード82a’、82b、82c”を選択した上でファイル配信メタデータを送信してもよい。
第5の手順、第6の手順、第7の手順、第8の手順、第9の手順および第10の手順では、データ要求クライアントノード83は、優先順位メタデータ及びファイル配信メタデータを取得すると、優先順位メタデータ及びファイル配信メタデータに基づいて、データピースクライアントノード82a’、82b、82c”からデータピースを取得する。ここで、データピースクライアントノード82a’、82b、82c”は、データ配信元クライアントノード81がファイルデータを3つのデータピースに分割した時に、その時点で最適なデータピースクライアントノードと同一である。しかし、優先順位格納データベース77に格納されている優先順位メタデータを随時更新すれば、最新の応答遅延時間に基づいて、優先順位を決定できる。すなわち、優先順位メタデータによっては、他のデータピースクライアントノードの組み合わせもありうる。
第11の手順では、すべてのデータピースがデータ要求クライアントノード83に送信された後は、データ要求クライアントノード83は、データ配信元クライアントノード81に対して、データピースクライアントノード82a’、82b、82c”のID、ファイルデータの名、データピースのファイル名を送信する。
第12の手順では、データ配信元クライアントノード81は、データ要求クライアントノード83の認証、ならびに課金処理等を実施後に、データ要求クライアントノード83にファイルデータを復元するための暗号鍵の送信を行う。
以上の手順を行うことによって、データ要求クライアントノード83は、ファイルデータを復元することができる。