以下、本発明の最良の実施形態を図面に� ��づいて説明する。なお、以下に説明する実� ��の形態は、コンテンツ配信システムに対し� ��本発明を適用した場合の実施形態である。

 [1.コンテンツ配信システムの構成等]
 始めに、図1を参照して、コンテンツ配信シ ステムの一例としてのコンテンツ配信システ ムの概要構成等について説明する。

 図1は、本実施形態に係るコンテンツ配信 システムにおける各ノード装置の接続態様の 一例を示す図である。

 図1の下部枠101内に示すように、IX(Internet� �eXchange)3、ISP(Internet Service Provider)4a,4b、DSL(Di gital Subscriber Line)回線事業者(の装置)5a,5b、FT TH(Fiber To The Home)回線事業者(の装置)6、及び 通信回線(例えば、電話回線や光ケーブル等)7 等によって、インターネット等のネットワー ク(現実世界の通信ネットワーク)8が構築され ている。なお、図1の例におけるネットワー� �(通信ネットワーク)8には、データ(パケット) を転送するためのルータが、適宜挿入されて いるが図示を省略している。

 コンテンツ配信システムSは、このような ネットワーク8を介して相互に接続された複� �のノード装置(以下、単に、「ノード」とい� ��)n1,n2・・・n21を備えて構成されることにな� ��、ピアツーピア方式のネットワークシステ� ��となっている(なお、実際には、これ以上の ノードが存在することになる)。また、各ノ� �ドn1~n21には、固有の製造番号及びIP(Internet P rotocol)アドレスが割り当てられている。なお� ��製造番号及びIPアドレスは、複数のノード� �で重複しないものである。

 これらのノードn1~n21は、例えば、CATV(Cable  Television or Community Antenna Television)など、� �用サービスの専用のセットトップボックス(S TB)などであり、全国の、或いは海外の複数の 放送局2a、2b、2cから様々な放送チャンネルで 放送された番組の映像及び音声を含む番組デ ータ(番組内に組み込まれるCM情報等を含む場 合もある)を有する番組情報(以下、「コンテ� ��ツデータ」という)を記録(保存)することが� ��能になっている。なお、放送局2a、2b、2cか� ��コンテンツデータを放送する放送媒体とし� ��は、衛星電波、地上波、インターネット、C ATVケーブル等の専用回線等を適用することが できる。

 登録サーバ2dは、ノードnnのコンテンツ配 信システムSへの参加登録を管理する。また� �ログサーバ2eは、各ノードnnの当該システムS の利用状況をログ管理し、更に、決済サーバ 2fは、利用状況に応じて、各ノードnnに対し� �コンテンツデータの2次的利用に対する課金� ��理を行なう。そして、ライブラリサーバ2g� �、各ノードnnにて記録されたコンテンツデー タを収集管理する。

 そして、このコンテンツ配信システムSに おいては、特定のアルゴリズム、例えば、DHT (Distributed Hash Table)を利用したアルゴリズム� ��よって、図1の上部枠100内に示すような、オ ーバーレイネットワーク9が構築されること� �なる。つまり、このオーバーレイネットワ� �ク9は、既存のネットワーク8を用いて形成さ れた仮想的なリンクを構成するネットワーク (論理的なネットワーク)を意味する。

 本実施形態においては、DHTを利用したア� ��ゴリズムによって構築されたオーバーレイ� ��ットワーク9を前提としており、このオーバ ーレイネットワーク9(図1の上部枠100内)に配� �されたノードn1~n15を、オーバーレイネット� �ーク9に参加しているノードnnという。言い� �えれば、オーバーレイネットワーク9は、ノ� ��ドnnの参加により形成されている。

 このようなオーバーレイネットワーク9へ の参加は、登録サーバ2dへユーザ情報を送信� ��コンテンツ配信システムSへの登録が適式に 行なわれたノードn16~n21が(この時点では未だ� ��ーバーレイネットワーク9へは参加していな い)、参加している任意のノードnnに対して参 加要求を示す参加メッセージを送信すること によって行われる。そして、ユーザ情報を受 けた登録サーバ2dにてノードの登録が行なわ� ��ると、新たに登録しようとするノードn16が� ��既に参加している任意のノードnnにアクセ� �して、参加メッセージを送信して参加して� �る任意のノードnnからDHT(後に詳述する)をコ� ��ーさせてもらう。

 上述したように、各ノードnnは固有の識� �情報としてのノードIDを有しており、当該ノ ードIDは、例えば、IPアドレスあるいは製造� �号を共通のハッシュ関数(例えば、SHA-1等)に� ��りハッシュ化した値(例えば、bit長が160bit)� �あり、一つのID空間に偏りなく分散して配置 されることになる。

 このように共通のハッシュ関数により求� ��られた(ハッシュ化された)ノードIDは、当該 IPアドレスあるいは製造番号が異なれば、同� ��値になる確率が極めて低いものである。な� ��、ハッシュ関数については公知であるので� ��しい説明を省略する。

 また、各ノードnnは、夫々、DHTを保持し� �いる。このDHTは、オーバーレイネットワー� �9上における各種メッセージの転送先を規定� ��ており、具体的には、ノードID空間内で適� �に離れたノードnnのノードIDとそのIPアドレ� �及びポート番号等の組が複数登録されたル� �ティングテーブル(転送先テーブル)が含まれ ている。

 図2は、ノードn1が保持するDHTのルーティ� ��グテーブルの一例を示す図であり、図3は、 DHTのノードID空間の一例を示す概念図である� ��

 なお、図2及び図3の例においては、説明� �便宜上、ノードIDのbit長を2bit×3桁=6bitとし、 各桁を4進数(0~3の整数)で表している(実際に� �、もっと長いbit長を用い、各桁も例えば4bit� ��区切って0~fの16進数で表現する)。

 図2の例において、DHTのルーティングテー ブルは、レベル1~レベル3のテーブルからなり (複数のレベルに区分されており)、各レベル� ��テーブルエントリーには、エリア毎に、ノ� ��ドIDとこれに対応するノードnnのIPアドレス� ��びポート番号が対応付けられて登録されて� ��る。各レベルのテーブルにおける各エリア� ��、DHTのノードID空間を分割することにより� �られるエリアである。例えば、図3に示すよ� ��に、レベル1では、DHTのノードID空間全体が4 分割され、“000”~“033”のノードIDが存在す るエリアを0XXのエリア、“100”~“133”のノ� �ドIDが存在するエリアを1XXのエリア、“200” ~“233” のノードIDが存在するエリアを2XXの� ��リア、“300”~“333”のノードIDが存在する� ��リアを3XXのエリアとする。また、レベル2で は、レベル1のエリア(つまり、0XX~3XXのエリア )が更に4分割、例えば1XXのエリアが4分割され 、“100”~“103”のノードIDが存在するエリア を10Xのエリア、“110”~“113” のノードIDが� ��在するエリアを11Xのエリア、“120”~“123” のノードIDが存在するエリアを12Xのエリア、� ��130”~“133” のノードIDが存在するエリア� �13Xのエリアとする。

 そして、例えば、ノードn1のノードIDが“ 122”とすると、図2に示すように、かかるノ� �ドn1のレベル1における1XXのエリア(自己(つま り、自ノード)が存在するエリア)のテーブル� ��は、自己のノードID及びIPアドレス(IPアドレ スは自分のものであるので、当該ルーティン グテーブルに登録しなくても良い)等が登録� �れ、自己が存在しないエリア(つまり、0XXの� ��リア、2XXのエリア、及び3XXのエリア)には、 夫々、他の任意のノードnnのノードID及びIPア ドレス等が登録されている。

 また、かかるノードn1のレベル2における1 2Xのエリア(自己が存在するエリア)のテーブ� �には、図2に示すように、自己のノードID及� �IPアドレス(IPアドレスは自分のものであるの で、当該ルーティングテーブルに登録しなく ても良い)等が登録され、自己が存在しない� �リア(つまり、10Xのエリア、11Xのエリア、及� ��13Xのエリア)等には、夫々、他の任意のノー ドnnのノードID及びIPアドレス等が登録されて いる。

 更に、かかるノードn1のレベル3には、図2 に示すように、ノードIDが“120”~“122”のノ ードID及びIPアドレス(IPアドレスは自分のも� �であるので、当該ルーティングテーブルに� �録しなくても良い)等が登録されている。

 なお、図2及び図3の例では、ノードIDのbit 長を3桁×2bitとしたので、レベル1~3の3レベル� ��のテーブルで網羅できるが、ノードIDのbit� �が増せば、その分のテーブルが必要となる(� ��えば、ノードIDのbit長を16桁×4bitとした場合 、16レベル分のテーブルが必要となる)。

 このように、本実施形態におけるDHTのル� ��ティングテーブルでは、レベルが上がるほ� ��、エリアが狭まっていくようになっている� ��

 このようなDHTは、例えば、未参加のノー� ��がオーバーレイネットワーク9に参加する際 に与えられることになる。

 本実施形態は、各放送局2a~2cから放送さ� �る全番組を、各ノードnnに記録担当として割 り当て、各ノードnnは記録担当分として割り� ��てられた番組を、複数のノードnn間で共用� �能に保存(記録)するよう構成する。なお、本 実施形態では、各ノードnnにて自己の記録担� ��時間を決定する場合と、各ノードnnのシス� �ムSへの参加登録時に、登録サーバ2dから、� �録担当番組が割り当てられ、装置内部に記� �担当番組表として記憶する場合の2通りの例� ��ついて説明する。表1は、後者の例、すなわ ち登録サーバ2dから、あるノードnnに割り当� �られた記録担当番組表の一例である。各ノ� �ドnnは、該記録担当番組表(表1参照)に従い、 録画(記録)開始時刻がきたら、該当する録画c hを受信して録画(保存)するよう構成する。

 後者の例の場合、登録サーバ2dは、各ノー� �装置nnから受信した地域情報に従って記録担 当番組を割り当てることが好ましい。例えば 、地域情報が名古屋を示す場合、名古屋地域 で受信可能な放送局の放送チャンネルを録画 chとして割り当てる。

 また、これらのコンテンツデータには、� ��々、番組に固有のコンテンツID(識別情報の� ��例)が生成され、コンテンツデータと対応付 けて各ノードnn内に保存される。コンテンツI Dは、例えば、「番組が放送された日時」と� �放送チャンネル」(つまり、録画開始時刻と� ��画ch)に従って生成される。

 例えば、2006年8月4日18時00分00秒に、放送チ� ��ンネル1で放送された番組に対しては、
    2006080418000001
 という数字列を上記ノードIDを得るときと� �通のハッシュ関数によりハッシュ化して当� �番組に一意に対応するコンテンツIDを生成す るようになっている(つまり、コンテンツIDは 、ノードIDと同一のID空間に配置される)。

 このように共通のハッシュ関数により求� ��られた(ハッシュ化された)コンテンツIDは、 放送チャンネル、放送時間帯が異なれば、同 じ値になる確率が極めて低いものである。従 って、同一のタイトルの番組(例えば、毎週� �送される番組)であっても、放送日時又は放� ��チャンネルが異なれば、コンテンツIDは異� �ることになる。なお、上記数字列がノードID と同一の桁数であるような場合には、上記数 字列をそのままコンテンツIDとして利用する� ��とも可能である。

 また、このように分散保存されているコ� ��テンツデータの所在を示すインデックス情� ��(当該コンテンツデータを保存している各コ ンテンツ保持ノードのノード情報(IPアドレス 及びポート番号等)を含むインデックスリス� �)は、上記コンテンツIDの管理元となるノー� �nn(以下、「ルートノード」という)により管� ��されるようになっている。例えば、番組Xの コンテンツデータのインデックス情報は、そ のコンテンツ(コンテンツID)のルートノード� �あるノードn13により管理され、番組Yのコン� ��ンツデータのインデックス情報は、そのコ� ��テンツ(コンテンツID)のルートノードである ノードn14により管理される。つまり、コンテ ンツ毎にルートノードが分けられるので負荷 分散が図らており、しかも、同一のコンテン ツデータ(コンテンツIDが同一)が、夫々、複� �のコンテンツ保持ノードに保存されている� �合であっても、かかるコンテンツデータの� �ンデックス情報は、1つのルートノードで管� ��することができる。また、このようなルー� ��ノードは、例えば、コンテンツIDと最も近� �(例えば、上位桁がより多く一致する)ノード IDを有するノードnnであるように定められる� �

 そして、コンテンツデータを保存したノ� ��ドnn(コンテンツ保持ノード)は、当該コンテ ンツデータを保存したことをそのルートノー ドに知らせるために、そのコンテンツデータ のコンテンツID及び自己のノード情報(コンテ ンツデータを保存した当該コンテンツ保持ノ ードを示すIPアドレス及びポート番号等のノ� ��ド情報)を含む登録メッセージとしてのパブ リッシュメッセージ(コンテンツデータを保� �したので、その情報をオーバーレイネット� �ーク9に参加しているノードnnに対して、保� �元ノード情報の登録の要求を示し、ルート� �ードを通じて公開するためのメッセージ)を� ��当該コンテンツIDに基づいて、そのルート� �ードに向けて送出する。これにより、パブ� �ッシュメッセージは、コンテンツIDをキーと するDHTルーティングによってルートノードに 到着することになる。

 図4(A)は、コンテンツ保持ノードから送出 されたパブリッシュメッセージの流れの一例 を、DHTのノードID空間にて示した概念図であ� ��。

 図4(A)の例において、例えば、コンテンツ 保持ノードであるノードn1は、自己のDHTのレ� ��ル1のテーブルを参照して、パブリッシュメ ッセージに含まれるコンテンツIDと最も近い( 例えば、上位桁がより多く一致する)ノードID を有する例えばノードn8のIPアドレス及びポ� �ト番号を取得し、そのIPアドレス及びポート 番号宛てに、上記パブリッシュメッセージを 送信する。

 これに対して、ノードn8は、当該パブリ� �シュメッセージを受信し、自己のDHTのレベ� �2のテーブルを参照して、当該パブリッシュ� ��ッセージに含まれるコンテンツIDと最も近� �(例えば、上位桁がより多く一致する)ノード IDを有する例えばノードn11のIPアドレス及び� �ート番号を取得し、そのIPアドレス及びポー ト番号宛てに、上記パブリッシュメッセージ を転送する。

 これに対して、ノードn11は、当該パブリ� ��シュメッセージを受信し、自己のDHTのレベ� ��3のテーブルを参照して、当該パブリッシュ メッセージに含まれるコンテンツIDと最も近� ��(例えば、上位桁がより多く一致する)ノー� �IDを有する例えばノードn13のIPアドレス及び� ��ート番号を取得し、そのIPアドレス及びポ� �ト番号宛てに、上記パブリッシュメッセー� �を転送する。

 これに対して、ノードn13は、パブリッシ� ��メッセージを受信し、自己のDHTのレベル4の テーブルを参照して、当該パブリッシュメッ セージに含まれるコンテンツIDと最も近い(例 えば、上位桁がより多く一致する)ノードIDが 自分である、つまり、自分がそのコンテンツ IDのルートノードであることを認識し、自己� ��インデックス情報中に、当該パブリッシュ� ��ッセージに含まれるノード情報を登録する� ��とになる。

 なお、パブリッシュメッセージに含まれ� ��ノード情報は、コンテンツ保持ノードから� ��ートノードに至るまでの転送経路における� ��ードnn(図4(A)の例では、ノードn8及びノードn 11)においても登録(キャッシュ)される。

 さて、あるノードnnのユーザが、過去に� �送された番組を視聴したい場合、その番組� �コンテンツデータの取得を望むノードnn(以� �、「ユーザノード」という)は、当該ユーザ� ��より指定された当該番組の「番組が放送さ� ��た日時」と「放送チャンネル」(つまり、録 画開始時刻と録画ch)を、上記共通のハッシュ 関数によりハッシュ化してコンテンツIDを生� ��し、当該コンテンツID及び自己(当該ユーザ� ��ード)のノード情報を含むコンテンツ所在問 合せ(検索)メッセージを、自己のDHTのルーテ� ��ングテーブルにしたがって他のノードnnに� �して送出する。これにより、当該コンテン� �所在問合せメッセージは、上述したパブリ� �シュメッセージと同様に、コンテンツIDをキ ーとするDHTルーティングによって、いくつか のノードnn(以下、「中継ノード」という)を� �由(転送)されて、そのコンテンツIDのルート� ��ードに辿り着く。そして、当該ルートノー� ��は、インデックス情報にノード情報が登録� ��れている何れかのコンテンツ保持ノードに� ��して、当該ユーザノードのノード情報を含� ��コンテンツ送信要求メッセージを送信する� ��これにより、ユーザノードは、当該コンテ� ��ツ保持ノードから、上記コンテンツ所在問� ��せ(検索)メッセージに係るコンテンツデー� �を取得(ダウンロード)することになる。

 図4(B)は、ユーザノードから送出されたコ ンテンツ所在問合せメッセージの流れの一例 を、DHTのノードID空間にて示した概念図であ� ��。

 図4(B)の例において、例えば、ユーザノー ドであるノードn3は、自己のテーブルを参照� ��て、コンテンツ所在問合せメッセージに含� ��れるコンテンツIDと最も近い(例えば、上位� ��がより多く一致する)ノードIDを有する例え� ��ノードn10のIPアドレス及びポート番号を取� �し、そのIPアドレス及びポート番号宛てに、 上記コンテンツ所在問合せメッセージを送信 する。

 これに対して、ノードn10は、当該コンテ� ��ツ所在問合せメッセージを受信し、自己の� ��ーブルを参照して、当該コンテンツ所在問� ��せメッセージに含まれるコンテンツIDと最� �近い(例えば、上位桁がより多く一致する)ノ ードIDを有する例えばノードn13のIPアドレス� �びポート番号を取得し、そのIPアドレス及び ポート番号宛てに、上記コンテンツ所在問合 せメッセージを転送する。

 これに対して、ノードn13は、コンテンツ� ��在問合せメッセージを受信し、自己のテー� ��ルを参照して、当該コンテンツ所在問合せ� ��ッセージに含まれるコンテンツIDと最も近� �(例えば、上位桁がより多く一致する)ノード IDが自分である、つまり、自分がそのコンテ� ��ツIDのルートノードであることを認識し、� �己のインデックス情報に登録されているコ� �テンツ保持ノードであるノードn1のノード情 報(IPアドレス及びポート番号)を、ユーザノ� �ドであるノードn3に送信する。

 これにより、ユーザノードであるノードn 3は、コンテンツ保持ノードであるノードn1に 対して、上記コンテンツ所在問合せメッセー ジに係るコンテンツデータを要求し取得(ダ� �ンロード)する。取得したコンテンツデータ� ��、ノードn1に固有の暗号鍵によって暗号化� �れているため、当該コンテンツデータを復� �化すべく、ノードn1の公開鍵を登録サーバ2d� ��ら取得して、当該公開鍵を用いてコンテン� ��データを復号化し、視聴することとなる。� ��体的には、ノードn3は、登録サーバ2dに対し てノードn1のノード情報を送信して公開鍵を� ��求し、これを受けた登録サーバ2dは、送信� �れたノードn1のノード情報に対応するノード n1の公開鍵をノードn3に送信する。

 なお、図4(B)に示すように、ユーザノード がコンテンツ保持ノードに対して送信要求を 行なってコンテンツデータを取得する構成(Pu sh)に限らず、例えば、ルートノードが、コン テンツ保持ノードであるノードn1に対して、� ��ーザノードのノード情報とコンテンツIDを� �むコンテンツ送信要求メッセージを送信し� �これに対して、コンテンツ保持ノードであ� �ノードn1は、コンテンツ送信要求メッセージ を受信し、自己が保存しているコンテンツデ ータから、当該コンテンツ送信要求メッセー ジに含まれるコンテンツIDに対応するコンテ� ��ツデータを取得し、当該コンテンツ送信要� ��メッセージに含まれるユーザノードである� ��ードn3のノード情報(IPアドレス及びポート� �号)に基づいて当該コンテンツデータを、ノ� ��ドn3に送信する構成(Pull)としてもよい。ま� �、上記ユーザノードは、コンテンツ所在問� �せメッセージがルートノードに辿り着くま� �の間に、当該ルートノードと同じノード情� �をキャッシュしているキャッシュノードか� �当該ノード情報を取得(受信)することもでき る。

 その後、ユーザノードは、ログサーバ2e� �接続して当該取得したコンテンツデータの� �聴ログを記録し、後に、決済サーバ2fにおい て、取得したコンテンツデータの2次的利用� �対する課金処理が行なわれることになる。

 次に、図5を参照して、ノードnnの構成及� ��機能について説明する。

 図5は、ノードnnの概要構成例を示す図で� ��る。

 ノードnnは、図5に示すように、演算機能� ��有するCPU,作業用RAM,各種データ及びプログ� �ムを記憶するROM等から構成されたコンピュ� �タとしての制御部11と、各種データ(例えば� �コンテンツデータ、ノード情報、DHT、登録� �ーバ2d、ログサーバ2e、決済サーバ2f及びラ� �ブラリサーバ2gのIPアドレス等)、当該ノード nn固有の秘密鍵(暗号化鍵の一例)、自己が記� �すべき番組を示す記録担当情報(表1参照)及� �プログラム等を記憶保存(格納)するためのHDD 等から構成された番組情報保存手段及び暗号 化鍵記憶手段としての記憶部12と、受信され� ��コンテンツデータを一時蓄積するバッファ� ��モリ13と、コンテンツデータに含まれるエ� �コードされたビデオデータ(映像情報)及びオ ーディオデータ(音声情報)等をデコード(デー タ伸張や復号化等)するための復号化手段と� �てのデコーダ部14と、当該デコードされたビ デオデータ等に対して所定の描画処理を施し ビデオ信号として出力する映像処理部15と、� ��該映像処理部15から出力されたビデオ信号� �基づき映像表示するCRT,液晶ディスプレイ等� ��表示部16と、上記デコードされたオーディ� �データをアナログオーディオ信号にD(Digital)/ A(Analog)変換した後これをアンプにより増幅し て出力する音声処理部17と、当該音声処理部1 7から出力されたオーディオ信号を音波とし� �出力するスピーカ18と、受信されたコンテン ツデータを暗号化するための暗号化手段とし てのエンコーダ部19と、ネットワーク8を通じ て他のノードnnや各サーバ2d~2gとの間の通信� �御を行なうための通信部19aと、放送局2aから 放送された番組のコンテンツデータを受信す るためのチューナ等の受信部19bと、ユーザか らの指示を受け付け当該指示に応じた指示信 号を制御部11に対して与える入力部(例えば、 キーボード、マウス、或いは、操作パネル等 )19cと、を備えて構成され、制御部11、記憶部 12、バッファメモリ13、デコーダ部14、エンコ ーダ部19、通信部19a、及び受信部19bは、バス1 9dを介して相互に接続されている。なお、ノ� ��ドnnとしては、パーソナルコンピュータ、ST B(Set Top Box)、或いは、TV受信機等を適用可能 である。

 このような構成において、制御部11は、CP Uが記憶部12等に記憶されたプログラム(本発� �の処理プログラムを含む)を読み出して実行� ��ることにより、全体を統括制御すると共に� ��上述したユーザノード、中継ノード、ルー� ��ノード、キャッシュノード、及びコンテン� ��保持ノード等の何れかのノードとしての処� ��を行なうようになっており、本発明の番組� ��報受信手段、番組情報保存手段、公開メッ� ��ージ送出手段、番組情報送信手段、暗号化� ��記憶手段、暗号化手段、参加登録手段、記� ��担当情報取得手段、復号化鍵送信手段、検� ��メッセージ送出手段、ノード情報取得手段� ��番組情報要求手段、番組情報取得手段、復� ��化鍵要求情報送信手段、復号化鍵取得手段� ��び復号化手段として機能し、後述する各種� ��理を行なうようになっている。

 また、本実施形態では、コンテンツデー� ��が暗号化されて記憶保存されるため、例え� ��、記憶部12に備える暗号化鍵記憶手段とし� �のセキュアな不揮発性メモリに、各ノードnn に固有の秘密鍵が、例えば当該ノードnnの製� ��時又は出荷時に記憶保存されるようになっ� ��おり、かかる秘密鍵は書き換え、消去、及� ��外部からの取り出しが不可能に保護されて� ��る。

 なお、上記処理プログラムは、例えば、� ��ットワーク8上の所定のサーバからダウンロ ードされるようにしてもよいし、例えば、CD- ROM等の記録媒体に記録されて当該記録媒体の ドライブを介して読み込まれるようにしても よい。

 次に、図6~図9を参照して、登録サーバ2d� �ログサーバ2e、決済サーバ2f及びライブラリ� ��ーバ2gの構成及び機能について説明する。� �お、本実施形態は、登録サーバ2d及び決済サ ーバ2fが、本発明のサーバ装置として機能す� ��場合の例である。

 先ず、図6を参照して、登録サーバ2dの構� ��及び機能について説明する。

 図6は、登録サーバ2dの概要構成例を示す� ��である。

 登録サーバ2dは、一般のサーバコンピュ� �タを適用可能であり、図6に示すように、CPU, 作業用RAM,各種データ及びプログラムを記憶� �るROM等から構成された制御部21と、各種デー タ(例えば、ログサーバ2e、決済サーバ2f及び� ��イブラリサーバ2gのIPアドレス等)及びプロ� �ラム等を記憶(格納)するHDD等から構成された 記憶部22と、ネットワーク8を通じてノードnn� ��の間の通信制御を行なうための通信部23と� �を備えて構成され、これらの各構成要素は� �ス24を介して相互に接続されている。

 このような構成において、制御部21は、CP Uが記憶部22等に記憶されたプログラムを読み 出して実行することにより、全体を統括制御 すると共に、本発明のサーバ装置の記録担当 情報決定手段及び記録担当情報送信手段、使 用者情報管理手段、復号化鍵記憶手段及び復 号化鍵送信手段等として機能し、後述する各 種処理を行なうようになっている。

 登録サーバ2dは、記憶部22にユーザ情報デー タベース22aを構築し、当該ユーザ情報データ ベース22aには、ユーザ情報として、各ノード nnのノードIDに対応付けて、
 〈1〉当該各ノードnnのユーザの個人情報(例 えば、ユーザID、住所、氏名、電子メールア� ��レス)、
 〈2〉各ノードnnが設置されるエリアの郵便� ��号や電話番号等の地域情報、
 〈3〉課金情報、決済方法を示す情報、クレ ジットカード番号等の決済情報、
 〈4〉各ノードnnに固有の秘密鍵によって暗� ��化(スクランブル)されたコンテンツデータ� �復号化するための公開鍵(復号化鍵の一例)、
 〈5〉各ノードnnへの公開鍵送信実績、
 が登録(記憶)されている(表2参照)。

 各ノードnnのノードIDは、例えば、当該ノー ドnnの製造時又は出荷時に製造番号に基づい� ��生成され登録されたり、ユーザの個人情報� ��地域情報、決済情報、公開鍵は、当該ユー� ��によるノードnnの購入時に該ノードID等に対 応付けて登録される。或いは、これら各ノー ドIDや個人情報等は、当該ノードnn購入後の� �ンテンツ配信システムSへの利用手続完了時( オーバーレイネットワーク9への参加時)に登� ��されることとなる。そして、登録サーバ2d� �ら決済サーバ2fに決済情報が送られ、決済サ ーバ2fにて各ノードnnの使用者に対して課金� �理が行なわれる他、当該ユーザ情報データ� �ース22aは、他の各サーバ2e~2gからもアクセス 可能に構成され、必要に応じてユーザ情報デ ータベース22aのユーザの個人情報や決済情報 が利用できるようになっている。

 なお、サーバ処理プログラムは、例えば� ��ネットワーク8上の所定のサーバからダウン ロードされるようにしてもよいし、例えば、 CD-ROM等の記録媒体に記録されて当該記録媒体 のドライブを介して読み込まれるようにして もよい。

 次に、図7を参照して、ログサーバ2eの構� ��及び機能について説明する。

 図7は、ログサーバ2eの概要構成例を示す� ��である。

 ログサーバ2eは、一般のサーバコンピュ� �タを適用可能であり、図7に示すように、CPU, 作業用RAM,各種データ及びプログラムを記憶� �るROM等から構成された制御部31と、各種デー タ(例えば、登録サーバ2d、ログサーバ2e及び� ��イブラリサーバ2gのIPアドレス等)及びプロ� �ラム等を記憶(格納)するHDD等から構成された 記憶部32と、ネットワーク8を通じてノードnn� ��各サーバとの間の通信制御を行なうための� ��信部33と、を備えて構成され、これらの各� �成要素はバス34を介して相互に接続されてい る。

 記憶部32では、各放送局2a~2cから放送された 各番組の放送後に、システムSを利用して、� �が、どの番組を、何回視聴(ダウンロード)し たか等のシステム利用実績を管理する。具体 的には、
 (i)各ノードnnのユーザ(使用者)毎の利用実績 を、各ノードnnに固有のノードIDに対応付け� �管理(記憶)し(表3参照)、
 (ii)各番組(コンテンツ)毎の利用実績を、各� ��組に固有のコンテンツIDに対応付けて管理(� ��憶)する(表4参照)。

 そして、定期的に、決済サーバ2fに(i)各ノ� �ドnnのシステム利用実績を送信し、決済サー バ2fが当該システム利用実績に応じて各ノー� ��nnに対して課金処理を行なうこととなる。� �た、登録サーバ2dからの要求に応じて、(ii)� �番組の利用実績を送信する。これを受けた� �録サーバ2dでは、各番組の利用実績を参考に (つまり、各番組の視聴率を考慮して)、新た� ��ノードnnが記録(録画)すべき記録担当番組の 割り当て、及び、各ノードnnが記録(録画)す� �き記録担当番組の再割り当てを行なう。

 次に、図8を参照して、決済サーバ2fの構� ��及び機能について説明する。

 図8は、決済サーバ2fの概要構成例を示す� ��である。

 決済サーバ2fは、一般のサーバコンピュ� �タを適用可能であり、図8に示すように、CPU, 作業用RAM,各種データ及びプログラムを記憶� �るROM等から構成された制御部41と、各種デー タ(例えば、登録サーバ2d、ログサーバ2e及び� ��イブラリサーバ2gのIPアドレス等)及びプロ� �ラム等を記憶(格納)するHDD等から構成された 記憶部42と、ネットワーク8を通じてノードnn� ��各サーバとの間の通信制御を行なうための� ��信部43と、を備えて構成され、これらの各� �成要素はバス44を介して相互に接続されてい る。

 このような構成において、制御部41は、CP Uが記憶部42等に記憶されたプログラムを読み 出して実行することにより、全体を統括制御 すると共に、本発明のサーバ装置の課金処理 手段等として機能し、ログサーバ2eから受信� ��た各ノードnnのユーザ(使用者)毎の利用実績 に応じて、各ノードnnのユーザに対して利用� ��金を課する課金処理を行なう。実際に課金� ��理を行なう際には、登録サーバ2dのユーザ� �報データベース22aにアクセスし、ユーザの� �人情報及び決済情報を利用して行なう。

 次に、図9を参照して、ライブラリサーバ 2gの構成及び機能について説明する。

 図9は、ライブラリサーバ2gの概要構成例� ��示す図である。

 ライブラリサーバ2gは、一般のサーバコ� �ピュータを適用可能であり、図9に示すよう� ��、CPU,作業用RAM,各種データ及びプログラム� �記憶するROM等から構成された制御部51と、各 種データ(例えば、登録サーバ2d、ログサーバ 2e及び決済サーバ2fのIPアドレス等)及びプロ� �ラム等を記憶(格納)するHDD等から構成された 記憶部52と、ネットワーク8を通じてノードnn� ��各サーバとの間の通信制御を行なうための� ��信部53と、を備えて構成され、これらの各� �成要素はバス54を介して相互に接続されてい る。

 このような構成において、制御部51は、CP Uが記憶部52等に記憶されたプログラムを読み 出して実行することにより、全体を統括制御 し、各放送局2a~2cから過去に放送された番組� ��記憶部52に記憶させる。

 具体的には、各ノードnnにて記録担当番� �を録画しようとしたところ、ノード内の番� �記憶領域の記憶容量をオーバーしてしまい� �新たな番組を録画するために、既に録画済� �番組(例えば、比較的古い番組)を削除しなけ ればならない場合に、当該各ノードnnから削� ��される番組(コンテンツデータ)を受信(アッ� ��ロード)して、記憶部52に記憶(管理)する。

 このようにコンテンツ配信システムSを構 成することにより、各放送局2a~2cから過去に� ��送された全ての番組を、記録担当である各� ��ードnn、或いはライブラリサーバ52gの何れ� �に必ず記録保存させることができるため、� �送された全ての番組について、各ノードnnの 配信要求に対応することができる。

 [2.コンテンツ配信システムの動作]
 次に、コンテンツ配信システムSの動作につ いて説明する。

 [2-1.ノードnnの処理]
 図10は、ノードnnの制御部11における処理を� ��すフローチャートである。ノードnnの電源� �オンとされることにより、本発明の処理プ� �グラムが制御部11の制御に基づいて実行され る。

 先ず、電源がオフとされたか否かを判定� ��(ステップS1)、オフとされていない場合(ス� �ップS1:No)には、ステップS2以下の処理へ移行 する。

 そして、制御部11は、ユーザが入力部19c� �を操作することにより、コンテンツ配信シ� �テムSへの参加登録が指示されたか否かを判� ��し(ステップS2)、コンテンツ配信システムS� �の参加登録が指示された場合(ステップS2:Yes) には、「登録処理」を行なう(ステップS3)。

 一方、コンテンツ配信システムSへの参加 登録が指示されていない場合(ステップS2:No)� �は、ステップS4へ移行して、記憶部12に記憶� ��れた記録担当番組表(表1)を参照して記録担� ��となっている番組の録画開始時刻が到来し� ��か否かを判定し(ステップS4)、記録担当とな っている番組の録画開始時刻が到来した場合 (ステップS4:Yes)には、「録画処理」を行なう( ステップS5)。

 一方、記録担当となっている番組の録画� ��始時刻が到来していない場合(ステップS4:No) には、ステップS6へ移行して、コンテンツ視� ��ログをログサーバ2eに送信すべき時刻(ログ� ��告時刻)が到来したか否かを判定する(ステ� �プS6)。

 そして、ログ報告時刻が到来した場合(ス テップS6:Yes)には、「ログ送信処理」を行な� �(ステップS7)、ログ報告時刻が到来していな� ��場合(ステップS6:No)には、ステップS8へ移行� ��る。

 次いで、制御部11は、ユーザが入力部19c� �を操作することにより、過去に放送局2a~2cか ら放送された番組について、再生指示がされ たか否かを判定し(ステップS8)、再生指示が� �れた場合(ステップS8:Yes)には、該番組をコン テンツ配信システムS内で検索すべく、「再� �処理」を行なう(ステップS9)。

 一方、再生指示がされていない場合(ステ ップS8:No)には、ステップS1へ戻り、電源がオ� ��とされる(ステップS1:Yes)まで、上記ステッ� �S1~S9の処理が繰り返し行なわれる。

 ■ステップS3における登録処理
 次に、上記ステップS3における「登録処理� �について説明する。なお、当該「登録処理� �は、各ノードnnにて記録担当番組を決定し、 記録担当番組表として記憶する場合における 登録処理と、各ノードnnのシステムSへの参加 登録時に、登録サーバ2dから、記録担当番組� ��割り当てられ、装置内部に記録担当番組表( 表1参照)として記憶する場合について説明す� ��。

 初めに、図11のフローチャートを用いて� �各ノードnnにて記録担当番組を決定する場合 における登録処理について説明する。

 先ず、制御部11は、ノードnnの使用者(ユ� �ザ)の個人情報、地域情報、決済情報等のユ� ��ザ情報を取得する(ステップS21)、具体的に� �、上記ユーザ情報の入力をユーザに促して� �ユーザが入力部19cを操作することにより取� �する。

 そして、ユーザ情報が取得されたか否か� ��判定し(ステップS22)、ユーザ情報が取得で� �れば(ステップS22:Yes)、登録サーバ2dに接続(� �クセス)する(ステップS23)。ユーザ情報が取� �できなれば(ステップS22:No)、ステップS21に移 行して、ユーザ情報が取得できるまで、ユー ザ情報の入力を促す等のユーザ情報取得処理 を繰り返し行なう。

 次いで、登録サーバ2dに接続できたか否� �を判定し(ステップS24)、登録サーバ2dに接続� ��きた場合(ステップS24:Yes)には、制御部11は� �加登録手段として機能し、ステップS21にて� �得したユーザ情報を登録サーバ2dに送信する (ステップS25)。一方、登録サーバ2dに接続で� �なれば(ステップS24:No)、ステップS23に移行し て、登録サーバ2dに接続できるまで、登録サ� ��バ2dへの接続を試みる。

 そして、ユーザ情報を登録サーバ2dに送� �できたか否かを判定し(ステップS26)、ユーザ 情報を送信できた場合(ステップS26:Yes)には、 記録担当番組を決定し、記憶部12に自己の記� ��担当番組表として記憶する(ステップS27)。� �録担当番組の決定方法としては、例えば、� �ードnn固有の製造番号を、自己が受信可能な 放送チャンネルのチャンネル数で割った余り を算出して得た数のチャンネルNoを録画チャ� ��ネルとして決定する。そして、製造番号を� ��時間帯総数で割った余りを算出て得た数に� ��当する時間を録画時間として決定する。時� ��帯総数とは、例えば、1日24時間を午前0時か ら30分ごとのコンテンツデータとして録画す� ��場合には、48個の時間帯(録画タイミング)が 発生する。そして、自己の製造番号を48で割� ��た余りが3であれば、3番目の時間帯、つま� �、午前1時から午前1時半までの30分間が録画� ��間となる。この他に、ノード製造時に製造� ��期や製造場所毎に記録担当番組を複数のノ� ��ドnnに振り分けて割り当てて記憶させてお� �ことにより、全ての放送チャンネルの番組� �複数のノードnnにて網羅するよう構成するこ ともできる。また、各放送チャンネルを受信 可能な地域ごとに複数の記録担当情報を予め 記憶部12に記憶させておき、当該複数の記録� ��当情報の中から、ステップS21にて取得した� ��ーザ情報に含まれる地域情報に基づいて、� ��ードnn自身がノードnnの地域情報に対応する 地域の記録担当情報を抽出し、自己の記憶担 当番組表として記憶しなおすよう構成するこ ともできる。

 一方、ユーザ情報を送信できなかった場� ��(ステップS26:No)には、送信できるまでステ� �プS25の送信処理を繰り返し行なう。

 そして、ステップS28にて、記録担当情報� ��決定、記憶できたか否かを判定し(ステップ S28)、記録担当情報を決定、記憶できた場合(� ��テップS28:Yes)、「登録処理」を終了し、記� �担当情報を決定、記憶できなかった場合(ス� ��ップS28:No)には、取得できるまで監視し記録 担当決定・記憶処理を繰り返す。

 続いて、図12のフローチャートを用いて� �登録サーバ2dから、記録担当番組が割り当て られる場合における登録処理について説明す る。なお、ステップS31~S36の処理は、夫々上� �したステップS21~S26の処理と同様であるため� ��ここでの説明は省略する。

 ステップS37では、制御部11が記録担当情� �取得手段として機能し、登録サーバ2dから記 録担当情報を取得する(ステップS37)。具体的� ��は登録サーバ2dにおける処理において詳述� �るが、登録サーバ2dでは、ステップS35にて送 信したユーザ情報に含まれる地域情報に基づ いて、ノードnnの地域情報に対応する地域の� ��録担当情報が決定され、ノードnnに送信さ� �る。

 そして、ステップS38にて、記録担当情報� ��取得できたか否かを判定し(ステップS38)、� �録担当情報を取得できた場合(ステップS38:Yes )、「登録処理」を終了し、記録担当情報を� �得できなかった場合(ステップS38:No)には、取 得できるまで登録サーバ2dからの記録情報の� ��信を待つ。

 ■ステップS5における録画処理
 次に、上記ステップS5における「録画処理� �について図13のフローチャートを用いて説明 する。

 先ず、制御部11は、番組を記録するため� �記憶部12の記憶領域が、容量不足であるか否 かを判定する(ステップS41)、具体的には、所� ��閾値以上記憶領域が残されているか否かを� ��定する。所定閾値は例えば、次の記録時間� ��(例えば30分)の容量とする。

 判定の結果、記憶領域の容量不足である� ��合(ステップS41:Yes)には、「削除処理」を行� ��い(ステップS42)、再び、容量不足であるか� �かを判定する(ステップS43)。「削除処理」に ついてはこの後詳述する。そして、「削除処 理」を行なってもなお容量不足である場合(� �テップS43:Yes)には、処理を終了する。ある番 組に対して予め複数のノードnnが記録担当と� ��て割り当てられる場合には、1台のノードnn� ��容量不足によって録画できないとしても、� ��の記録担当ノードnnが当該番組を記録する� �とで十分カバーできる。

 一方、記憶領域の容量が不足していない� ��合(ステップS41:No、S43:No)には、制御部11は番 組情報受信手段及び番組情報保存手段として 機能し、録画すべき録画チャンネルの放送を 受信してコンテンツデータ(番組)の受信し、� ��画を開始する(ステップS44)。

 そして、録画が適式に行なわれたか否か� ��判定し(ステップS45)、録画開始が適式に行� �われた場合(ステップS45:Yes)には、制御部11は 、暗号化手段として機能し、受信された該コ ンテンツデータを記憶部12に記憶した自己の� ��有の秘密鍵(暗号化鍵の一例)でエンコーダ� �19により暗号化させながら(つまり、秘密鍵� �用いて受信されたコンテンツデータを暗号� �する)、記憶部12に記録するように制御する(� ��テップS46)。

 そして、当該録画処理が終了すると、制� ��部11は、「番組が放送された日時」と「放� �チャンネル」(つまり、録画開始時刻と録画c h)に従って固有のコンテンツIDを生成し、暗� �化されたコンテンツデータと対応付けて記� �部12に記憶する(ステップS47)。

 次いで、制御部11は、公開メッセージ送� �手段として機能し、上記コンテンツID及び自 己のノード情報を含むパブリッシュメッセー ジを、そのルートノードに向けて送出し(ス� �ップS48)、当該処理を終了する。そして、送� ��されたパブリッシュメッセージは、図4(A)を 用いて説明したように、幾つかの中継ノード を経由され、上記コンテンツIDのルートノー� ��に辿り着く。そのルートノードは、当該パ� ��リッシュメッセージを受信すると、これに� ��まれるノード情報を記憶、つまり、インデ� ��クス情報中に登録することになる。こうし� ��、上記パブリッシュメッセージを送出した� ��ードnnは、コンテンツ保持ノードとなる。

 次に、上記ステップS5における「削除処� �」について図14のフローチャートを用いて説 明する。

 先ず、制御部11は、記憶部12に記憶されて いるコンテンツデータの中から、削除コンテ ンツデータを決定する(ステップS51)。削除コ� ��テンツデータの選択方法としては、例えば� ��記憶部12に記憶されているコンテンツデー� �のうち、放送日時(録画日時)が最も古いもの 、或いは、各コンテンツデータに寿命時間を 設けておき、当該寿命時間が既に経過してい るもの(寿命時間は、例えば各放送局2a~2cから 番組が放送される際に、当該番組に寿命時間 情報を付加しておく等の構成とする)、或い� �、最もコンテンツ配信要求の少ないもの、� �いは、視聴率の最も少ないもの(視聴率は、� ��番組の利用実績(表4参照)を管理しているロ� ��サーバ2eに問い合わせる等の構成とする)な� ��とすればよい。また、上記S43にて不足とさ� ��た容量分の削除コンテンツデータを選択す� ��ことが好ましい。

 そして、ライブラリサーバ2gに接続(アク� ��ス)する(ステップS52)。次いで、ライブラリ� ��ーバ2gに接続できたか否かを判定し(ステッ� ��S53)、ライブラリサーバ2gに接続できた場合( ステップS53:Yes)には、ステップS51にて決定し� ��削除コンテンツデータがライブラリサーバ2 g内に記憶されているか否かをライブラリサ� �バ2gに問い合わせる(ステップS54)。削除コン� ��ンツデータがライブラリサーバ2g内に記憶� �れていない場合には、当該ライブラリサー� �2gから、削除コンテンツデータの送信(アッ� �ロード)指示がされることとなる。一方、ラ� ��ブラリサーバ2gに接続できなれば(ステップS 55:No)、ステップS52に移行して、ライブラリサ ーバ2gに接続できるまで、ライブラリサーバ2 gへの接続を試みる。

 そして、ライブラリサーバ2gから、削除� �ンテンツデータのアップロード指示(送信指� ��)がされたか否かを判定し(ステップS55)、削� ��コンテンツデータのアップロード指示がさ� ��ていない場合(ステップS55:No)には、ステッ� �S57へ移行し、削除コンテンツデータのアッ� �ロード指示がされた場合(ステップS55:Yes)に� �、削除コンテンツデータをライブラリサー� �2gにアップロード(送信)する(ステップS56)。� �お、本実施形態では、ライブラリサーバ2gに 削除コンテンツデータを送信する際には、自 己の公開鍵にて該コンテンツを復号化した後 にライブラリサーバ2gに送信するよう構成す� ��。

 続いて、ステップS57にて、削除コンテン� ��データを記憶部12から削除する(ステップS57) 。そして、削除メッセージ(コンテンツデー� �を削除したので、ルートノード等に対して� �ード情報の登録削除の要求をするためのメ� �セージ)を、当該削除コンテンツデータのコ� ��テンツIDに基づいて、そのルートノードに� �けて送出する。これにより、削除メッセー� �は、公開したときのパブリッシュメッセー� �と同様に、コンテンツIDをキーとするDHTルー ティングによってルートノードに到着するこ とになる。そしてルートノードと、該削除メ ッセージの転送経路における各ノードnnでは� ��自己のインデックス情報にキャッシュされ� ��削除メッセージ送信元のノードnn(つまり、� ��除コンテンツデータを保存していたノードn n)のノード情報が削除されることとなる。以� ��で図14の「削除処理」を終了する。

 ■ステップS7におけるログ送信処理
 次に、上記ステップS7における「ログ送信� �理」について図15のフローチャートを用いて 説明する。

 先ず、制御部11は、ログサーバ2eに接続(� �クセス)する(ステップS61)。次いで、ログサ� �バ2eに接続できたか否かを判定し(ステップS6 2)、ログサーバ2eに接続できなれば(ステップS 62:No)、ステップS61に移行して、ログサーバ2e� ��接続できるまで、ログサーバ2eへの接続を� �みる。

 一方、ログサーバ2eに接続できた場合(ス� ��ップS62:Yes)には、コンテンツ視聴ログをロ� �サーバ2eへ送信し(ステップS63)、送信できた� ��否かを判定し(ステップS64)、ログサーバ2eに コンテンツ視聴ログを送信できれば(ステッ� �S64:Yes)、処理を終了し、送信できなれば(ス� �ップS64:No)、ステップS63に移行して、送信で� ��るまで、ログサーバ2eへの送信を試みる。

 ■ステップS9における再生処理
 次に、上記ステップS9における「再生処理� �について図16のフローチャートを用いて説明 する。当該処理は、ユーザが入力部19c等を操 作して再生指示の対象とする番組の放送日時 と放送チャンネルが入力されることにより、 過去に放送局2a~2cから放送された番組につい� ��、再生指示がされたことにより開始する処� ��である。

 先ず、制御部11は、入力指示された番組� �放送日時と放送チャンネルに基づいてコン� �ンツIDを生成し(ステップS70)、コンテンツ検� ��処理を実行する。具体的には、制御部11は� �検索メッセージ送出手段として機能し、当� �生成したコンテンツID及び自己(当該ユーザ� �ード)のノード情報を含むコンテンツ所在問� ��せ(検索)メッセージを、そのルートノード� �向けて送出し、返答を待つ(ステップS71)。

 例えば、1つの番組が1つのコンテンツデ� �タとして1つのノードnnに記録されている場� �には、入力指示された番組の放送日時と放� �チャンネルに基づいて1つのコンテンツIDが� �成され、当該コンテンツIDに基づくDHTルーテ ィングに基づく1つのコンテンツ所在問合せ� �ッセージが送出されることとなるが、1つの� ��組(2時間番組)が、初めの1時間が1つのコン� �ンツデータとして1つのノードnnにて記録さ� �、後の1時間が1つのコンテンツデータとして 別のノードnnにて記録されている場合には、� ��めの1時間のコンテンツデータに対しては、 放送日時(初めの1時間の録画開始時刻)と放送 チャンネルに基づいてコンテンツIDが生成さ� ��、後の1時間のコンテンツデータに対しては 、放送日時(後の1時間の録画開始時刻)と放送 チャンネルに基づいてコンテンツIDが生成さ� ��て、2つのコンテンツ所在問合せメッセージ が送出されることとなる。このように、再生 指示をした番組が1つであっても、複数のコ� �テンツデータを検索し取得する必要がある� �ともある。

 そして、送出されたコンテンツ所在問合� ��(検索)メッセージは、図4(B)を用いて説明し� ��ように、幾つかの中継ノードを経由され、� ��記コンテンツIDのルートノードに辿り着く� �

 そして、そのルートノードが、当該コン� ��ンツ所在問合せ(検索)メッセージを受信す� �と、当該コンテンツIDに対応するコンテンツ データを保存しているコンテンツ保持ノード nnのノード情報がインデックス情報中に登録� ��れているか否かを判断し、登録されている� ��合には、登録されているコンテンツ保持ノ� ��ドnn(複数登録されている場合には、そのう� ��の何れか1つ又は複数のコンテンツ保持ノー ド)のノード情報を返答メッセージとしてユ� �ザノードに対して送信する。

 一方、当該ルートノードは、当該コンテ� ��ツIDに対応するコンテンツデータを保存し� �いるコンテンツ保持ノードnnのノード情報が インデックス情報中に登録されていない場合 には、登録されていないことを示す返答メッ セージを、当該ユーザノードに送信する。

 これに対して、ユーザノードが上記返答� ��ッセージを受信すると、その制御部11は、� �該返答メッセージを参照して、コンテンツ� �ータを発見できたか否かを判定する(ステッ� ��S72)。つまり、ステップS71にて送出した全て のコンテンツ所在問合せメッセージに対して 、返答メッセージを受信できたか、受信でき た場合には、再生指示をした番組にかかるコ ンテンツデータを保持するコンテンツ保持ノ ードnnのノード情報をルートノードから取得� ��きたか否か(ノード情報取得手段)を判定す� �。判定の結果、全てのコンテンツデータを� �見できた場合には(ステップS72:Yes)、制御部11 は、復号化鍵要求情報送信手段及び復号化鍵 取得手段として機能し、ルートノードから教 えてもらった各コンテンツ保持ノードnnのノ� ��ド情報に含まれるノードIDを含む復号化鍵� �求情報を登録サーバ2dに送信して、該登録サ ーバ2dから、各コンテンツ保持ノードnnの公� �鍵を取得する(ステップS73)。1つのルートノ� �ドから、複数のコンテンツ保持ノードのノ� �ド情報を教えてもらったときは、全てのコ� �テンツ保持ノードの公開鍵を取得し、全て� �コンテンツ保持ノードに対してコンテンツ� �ータの配信を要求してもよく、或いは、何� �か1つのコンテンツ保持ノードに対してコン� ��ンツデータの配信を要求してもよい。なお� ��この際配信要求対象とされるコンテンツの� ��ンテンツIDも共に登録サーバ2dに送信する。 登録サーバ2dにて、公開鍵送信実績(表2参照)� ��記録するためである。

 そして、公開鍵を取得できたか否かを判� ��し(ステップS74)、公開鍵を取得できなれば(� ��テップS74:No)、ステップS71に移行して、再び コンテンツ所在問合せ(検索)メッセージを送� ��する。ところで、ある番組は、視聴による� ��録や重複した記録担当割り当てにより複数� ��ノードnnに記録されその旨が公開されるの� �、複数のノードnnが当該番組の所在を知る(� �ャッシュされる)ことなる。従って、例えば� ��じコンテンツ所在問合せ(検索)メッセージ� �受けた場合には、同じコンテンツ保持ノー� �のノード情報を返さないよう構成すれば、� �ンテンツ所在問合せ(検索)メッセージの再送 信に対しては、S74で公開鍵を取得できなかっ たコンテンツ保持ノードとは別のコンテンツ 保持ノードのノード情報を得ることができる 。

 なお、過去に公開鍵を取得したことがあ� ��場合には、ステップS74の処理を行なわなく� ��もよい。例えば、表2のユーザ情報にかかる 公開鍵送信実績と表3の利用実績を比較して� �明すると、ノードID「002」のノードnnは、表2 の公開鍵送信実績によれば、コンテンツID「1 12」のコンテンツを復号化するために、公開� ��を登録サーバ2dに1回送信してもらっている� ��そして、表3の利用実績によれば、該ノード ID「002」のノードは、コンテンツID「112」の� �ンテンツを4回利用していることがわかる。� ��れは例えば、ノードID「002」のノードがコ� �テンツID「112」のコンテンツを検索し、取得 した経験があるが、その都度コンテンツデー タ自体は記憶部12から消去しているが、該コ� ��テンツデータの保存元のノードnn(コンテン� ��保持ノード)の公開鍵だけは記憶しておいた ため、コンテンツデータのみを何度も(表3の� ��では4回)取得しているのである。

 一方、公開鍵を取得できた場合(ステップ S74:Yes)には、制御部11は番組情報要求手段と� �て機能し、各コンテンツ保持ノードnnにコン テンツデータの配信を要求する(ステップS75)� ��そして、コンテンツデータを受信したか否� ��を判定し(ステップS76)、コンテンツデータ� �受信できなれば(ステップS76:No)、ステップS75 に移行して、コンテンツデータを受信するま でコンテンツデータの配信を要求する。

 ステップS72において、コンテンツデータ� ��発見できなかった場合(ステップS72:No)、す� �わち、ステップS71にて送出した各コンテン� �所在問合せメッセージのうち、コンテンツ� �持ノードnnのノード情報を1つも得られなか� �たコンテンツ所在問合せメッセージがある� �合には、当該コンテンツ所在問合せメッセ� �ジにかかるコンテンツデータの配信を、ラ� �ブラリサーバ2gに要求する(ステップS77)。例� ��ば、ステップS71にて2つのコンテンツデータ に係る2つのコンテンツ所在問合せメッセー� �を送出した場合、一方のコンテンツデータ� �かかるコンテンツ保持ノードnnのノード情報 はルートノードから得られたが、他方のコン テンツデータにかかるコンテンツ保持ノード nnのノード情報はルートノードから得られな� ��った場合には、当該他方のコンテンツデー� ��についてのみ、ライブラリサーバ2gに要求� �る。ライブラリサーバ2gの負荷軽減のために も、コンテンツ保持ノードnnのノード情報が� ��られたものは、コンテンツ保持ノードnnに� �して配信要求を行ない、できる限り他のノ� �ドnnから取得するよう構成することが好まし い。

 そして、ライブラリサーバ2gからコンテ� �ツデータを受信したか否かを判定し(ステッ� ��S78)、コンテンツデータを受信できなれば(� �テップS78:No)、ステップS77に移行して、コン� ��ンツデータを受信するまでライブラリサー� ��2gにコンテンツデータの配信を要求する。

 続いて、制御部11は番組情報取得手段と� �て機能して、ステップS76、S78にてコンテン� �データを受信(取得)すると(ステップS76:Yes、S 78:Yes)、当該受信(取得)したコンテンツデータ を記憶部12に記憶して、コンテンツ視聴ログ� ��記録する(ステップS79)。コンテンツ視聴ロ� �は、定期的にログサーバ2eに送信するもので (上記ステップS6,7参照)、コンテンツデータの 受信の都度、コンテンツ視聴回数、視聴日時 等をコンテンツIDに対応付けて記録する。

 そして、コンテンツデータを再生して(ステ ップS80)、処理を終了する。なお、コンテン� �保持ノードnnから受信(取得)(S76)したコンテ� �ツデータについては、暗号化された状態で� �得されているため、制御部11は復号化手段と して機能し、ステップS73で登録サーバ2dから� ��得したコンテンツ保持ノードの公開鍵を用� ��てデコーダ部14にて復号化しながら再生処� �を行なう。なお、ユーザによる再生指示の� �象とする番組の開始位置が、1つのコンテン� ��データの途中に位置する場合、再生指示さ� ��た番組の放送日時をコンテンツ録画開始時� ��に正規化した日時(たとえばこの例で言うと 、2006年8月3日の18時5分から放送された番組を 視聴したい場合には2006年8月3日の18時0分)と� �送チャンネルに基づいて1つのコンテンツID� �生成され、当該コンテンツIDに基づくDHTルー ティングに基づく1つのコンテンツ所在問合� �メッセージがルートノードに向けて送出さ� �る。そして、最終的に、上記番組を含む当� �コンテンツデータがコンテンツ保持ノードnn から受信(取得)されることになるが、この場� ��、当該再生指示された番組の開始位置まで� ��キップする処理が行われた上で当該番組が� ��生(つまり、取得されたコンテンツデータの 途中から再生)されることになる。
 また、同様にユーザによる再生指示の対象� ��する番組の終了位置が、1つのコンテンツデ ータの途中に位置する場合、上記番組を含む 当該コンテンツデータがコンテンツ保持ノー ドnnから受信(取得)されることになるが、こ� �場合、当該再生指示された番組の終了位置� �でを再生(つまり、取得されたコンテンツデ� ��タの途中まで再生)することになる。

 なお、再生したコンテンツデータは、再� ��後、記憶部12に記憶された自己の秘密鍵を� �いて暗号化し、記憶部12に保存するよう構成 することにより、ノードnnは再生したコンテ� ��ツデータのコンテンツ保持ノードとして機� ��する。つまり、コンテンツIDと自己のノー� �情報を含むパブリッシュメッセージをルー� �ノードに向けて送出し、公開する。これに� �り、人気の高い番組のコンテンツデータほ� �、多くのユーザにより録画されるため、多� �のノードnnに保存されるので、サーバ装置の ような特定の装置に負荷をかけることなく、 人気の高い番組ほどアクセス(取得)しやすく� ��り、録画し損ねた番組の番組であっても確� ��に取得することができる。

 [2-2.登録サーバ2dの処理]
 図17は、登録サーバ2dの制御部21における処� ��を示すフローチャートである。なお、ここ� ��は、登録サーバ2dが、各ノードnnに対して記 録担当番組を割り当てる場合について説明す る。図17に示す処理は登録サーバ2dの電源が� �ンとされることにより、本発明のサーバ処� �プログラムが制御部21の制御に基づいて実行 される。

 先ず、電源がオフとされたか否かを判定� ��(ステップS81)、オフとされていない場合(ス� ��ップS81:No)には、ステップS82以下の処理へ移 行する。

 そして、制御部21は、コンテンツ配信シ� �テムSに未参加の新たなノードnnから登録要� �を受けたか否かを判定し(ステップS82)、登録 要求を受けていない場合(ステップS82:No)には� ��ステップS86へ移行し、登録要求を受けた場� ��(ステップS82:Yes)には、当該ノードnnからユ� �ザ情報を受信して、ユーザ情報データベー� �22aに登録する(ステップS83)。

 続いて、制御部21は、記録担当情報決定� �段及び記録担当情報送信手段として機能し� �該ノードnnが記録担当となるべき番組を決定 し、記録担当情報としてノードnnに送信する( ステップS84)。このとき、受信したユーザ情� �に含まれる地域情報に基づいて、記録担当� �報を決定するよう構成することが好ましい� �すなわち、地域情報が名古屋を示す場合、� �古屋地域で受信可能な放送局の放送チャン� �ルを録画chとして割り当て、地域情報が東京 を示す場合、東京地域で受信可能な放送局の 放送チャンネルを録画chとして割り当てる。� ��ての放送局から放送される全ての番組が、� ��ンテンツ配信システムSに参加する何れかの ノードnnにて必ず記録されるよう、記録担当� ��割り振ることが好ましい。なお、記録担当� ��組を、各ノードnnにて決定する構成である� �合には、当該ステップS84の処理は行なわな� �。

 次に、ステップS83で受信したユーザ情報� ��含まれる決済情報を決済サーバ2fに送信す� �(ステップS85)。なお、決済情報を決済サーバ 2fに送信後は、ユーザ情報データベース22aか� ��決済情報を削除してもよい。この後、決済� ��ーバ2fでは、決済情報に基づいてノードnnの ユーザに対して所定額の利用料金を課する課 金処理を行なうこととなる。そして、例えば ユーザの銀行口座から当該利用料金が引き落 とされ、こうして徴収された利用料金は、予 め定められた基準にしたがって番組制作者や 放送局側の著作者等に対して支払われること になる。なお、ここで行なわれる課金処理は 、コンテンツ配信システムSへの登録時に行� �われる課金処理であって、コンテンツの利� �実績に基づいて各ユーザに対して行なわれ� �課金処理は、後に詳述するログサーバ2eから 送信される利用実績に基づいて、後に行なわ れることとなる。

 続いて、ノードnnから、公開鍵の要求が� �れたか否かを判定する(ステップS86)。判定の 結果、公開鍵の要求がされていない場合(ス� �ップS86:No)には、ステップS81に移行し、公開� ��の要求がされた場合(ステップS86:Yes)には、� ��求元のノードnnが正式にコンテンツ配信シ� �テムSに登録された登録済みのノードnnであ� �か否かを判定する(ステップS87)。具体的には 、要求元のノードnnのノードIDを受信して、� �該ノードIDがユーザ情報データベース22aに登 録されているか否かに基づいて判定する。こ のとき、ノードIDだけでなく、該ノードIDと� �応付けられたユーザ情報の任意の情報(例え� ��、電話番号等)を要求元のノードnnにて入力� ��送信するよう促し、当該送信された情報と� ��ーザ情報データベース22aに登録されている� ��報とを照合して登録済みか否かを判定する� ��う構成してもよい。

 そして、登録済みのノードnnである場合(� ��テップS87:Yes)には、制御部21は復号化鍵送信 手段として機能し、要求されているコンテン ツ保持ノードのノードIDに対応付けられた公� ��鍵をユーザ情報データベース22aから取得し� ��、要求元のノードnnに送信し、要求元のノ� �ドnnのユーザ情報に、当該公開鍵を送信した 旨を、該要求元のノードnnのノードIDに対応� �けて記録し(ステップS88)、ステップS81に移行 する。このとき、要求元のノードnnが取得(再 生)を所望しているコンテンツのコンテンツID に対応付けて公開鍵送信実績を記録する。表 2を参照して具体的に説明すると、例えば、� �ードID「103」のノードnnが、コンテンツID「12 1」のコンテンツの取得(再生)を所望して、該 コンテンツID「121」のコンテンツデータを保� ��するコンテンツ保持ノードであるノードID� �120」の公開鍵を要求した場合には、登録サ� �バ2dは、ユーザ情報データベース22aからノー ドID「120」の公開鍵(120)を取得してノードID「 103」のノードnnに送信し、ノードID「103」に� �応付けられた公開鍵送信実績のコンテンツID 「101」の回数を1加算して更新することとな� �。

 一方、登録済みのノードnnでない場合(ス� ��ップS87:No)には、正規登録者でないため公開 鍵を送信できない旨のエラーメッセージを送 信し(ステップS89)、ステップS81に移行する。

 そして、電源がオフとされる(ステップS81 :Yes)まで、上記ステップS81~S89の処理が繰り返 し行なわれる。

 また、上述した処理は電源がオンとされ� ��いる間、繰り返し行なわれる処理であるが� ��この他に、登録サーバ2dでは、定期的にロ� �サーバ2eから各番組の利用実績(表4参照)を受 信して、(つまり、各番組の視聴率を考慮し� �)、新たなノードnnが記録(録画)すべき記録担 当番組の割り当て、及び、各ノードnnが記録( 録画)すべき記録担当番組の再割り当てを行� �うよう構成する。記録担当番組の再割り当� �を行なう場合、登録サーバ2dは、各ノードnn� ��対して新しい記録担当情報を送信し、古い( これまでの)記録担当情報と書き換えるよう� �示し、これを受けたノードnnは、古い(これ� �での)記録担当情報に変えて新たな記録担当� ��報を記憶部12に記憶するよう構成する。

 [2-3.ログサーバ2eの処理]
 図18は、ログサーバ2eの制御部31における処� ��を示すフローチャートである。図18に示す� �理はログサーバ2eの電源がオンとされること により、本発明のサーバ処理プログラムが制 御部31の制御に基づいて実行される。

 先ず、電源がオフとされたか否かを判定� ��(ステップS91)、オフとされていない場合(ス� ��ップS91:No)には、ステップS92以下の処理へ移 行する。

 そして、制御部31は、ノードnnから接続要 求を受けたか否かを判定し(ステップS92)、接� ��要求を受けていない場合(ステップS92:No)に� �、ステップS96へ移行し、接続要求を受けた� �合(ステップS92:Yes)には、該ノードnnからコン テンツ視聴ログを受信して、システム利用実 績を記録する(表3、表4参照)。そして、該ノ� �ドnnの利用実績(表3参照)を決済サーバ2fに送� ��(報告)する(ステップS96)。この後、決済サー バ2fでは、利用実績に基づいてノードnnのユ� �ザに対して所定額の利用料金を課する課金� �理を行なうこととなる。そして、コンテン� �配信システムSへの登録時と同様に、例えば� ��ーザの銀行口座から当該利用料金が引き落� ��され、予め定められた基準にしたがって番� ��制作者や放送局側の著作者等に対して支払� ��れることになる。

 続いて、制御部31は、登録サーバ2dから接 続要求を受けたか否かを判定し(ステップS96)� ��接続要求を受けていない場合(ステップS96:No )には、ステップS91へ移行し、接続要求を受� �た場合(ステップS96:Yes)には、コンテンツの� �用実績(表4参照)を登録サーバ2dに送信して(� �テップS97)、ステップS91へ移行する。

 そして、電源がオフとされる(ステップS91 :Yes)まで、上記ステップS91~S97の処理が繰り返 し行なわれる。

 [2-4.ライブラリサーバ2gの処理]
 図19は、ライブラリサーバ2gの制御部51にお� ��る処理を示すフローチャートである。図19� �示す処理はライブラリサーバ2gの電源がオン とされることにより、本発明のサーバ処理プ ログラムが制御部51の制御に基づいて実行さ� ��る。

 先ず、電源がオフとされたか否かを判定� ��(ステップS101)、オフとされていない場合(ス テップS101:No)には、ステップS102以下の処理へ 移行する。

 そして、制御部51は、ノードnnからコンテ ンツIDを受信してコンテンツデータ有無の問� ��せがされたか否かを判定する(ステップS102)� ��この問い合わせは、上述したノードnnにお� �る削除処理(ステップS5、S54)の処理に呼応す� ��処理である。

 判定の結果、コンテンツデータ有無の問� ��せがされていない場合(ステップS102:No)には� ��ステップS108に移行し、コンテンツデータ有 無の問合せがされた場合(ステップS102:Yes)に� �、問い合わされたコンテンツデータを記憶� �ているか否かを判定する(ステップS103)。記� �している場合には、該コンテンツIDにかかる コンテンツのアップロード(送信)は不要であ� ��旨を返信し(ステップS104)、ステップS108に移 行する。一方、問い合わされたコンテンツデ ータを記憶していない場合(ステップS103:No)に は、該コンテンツIDにかかるコンテンツのア� ��プロード(送信)を指示する(ステップS105)。

 そして、コンテンツのアップロードが確� ��に行なわれたか否かを判定し(ステップS106)� ��コンテンツのアップロード(送信)が確実に� �なわれなかった場合(ステップS106:No)には、� �テップS105に移行して、コンテンツのアップ� ��ード(送信)が完了するまで監視し指示をし� �ける。コンテンツのアップロードが確実に� �なわれると(ステップS106:Yes)、アップロード� ��れたコンテンツデータを記憶部52にコンテ� �ツIDに対応付けて保存する(ステップS107)。な お、本実施形態ではライブラリサーバ2gに保� ��されるコンテンツは、暗号化されていない� ��ンテンツデータであるものとする。従って� ��ライブラリサーバ2gは、各ノードnnから、当 該ノードnnの公開鍵(つまりコンテンツ保持ノ ードの公開鍵)にて復号化されたコンテンツ� �ータを受信することとなる。この他、例え� �、各ノードnnから暗号化されたコンテンツデ ータを受信し、該ノードnnの公開鍵を、登録� ��ーバ2dから取得して復号化した後に記憶部52 に保存するよう構成することもできる。

 続いて、ノードnnからコンテンツデータ� �配信要求があったか否かを判定し(ステップS 108)、配信要求がされていない場合(ステップS 108:No)には、ステップS101に移行し、配信要求� ��された場合(ステップS108:Yes)には、要求元の ノードnnが正式にコンテンツ配信システムSに 登録された登録済みのノードnnであるか否か� ��判定する(ステップS109)。具体的には、要求� ��のノードnnのノードIDを登録サーバ2dに送信� ��て、当該ノードIDがのユーザ情報データベ� �ス22aに登録されているか否かを登録サーバ2d に問い合わせて判定する。

 そして、登録済みのノードnnである場合(� ��テップS109:Yes)には、要求されているコンテ� ��ツデータを、該要求元のノードnnに配信し� �(ステップS110)、ステップS101の処理に移行す� ��。一方、登録済みのノードnnでない場合(ス� ��ップS109:No)には、正規登録者でないため公� �鍵を送信できない旨のエラーメッセージを� �信し(ステップS111)、ステップS101に移行する� ��

 そして、電源がオフとされる(ステップS10 1:Yes)まで、上記ステップS101~S111の処理が繰り 返し行なわれる。

 以上説明したように、本実施形態によれ� ��、各放送局2a~2cから放送される番組を受信� �る複数のノードnnが、記録担当分として夫々 割り当てられた番組に固有のコンテンツIDに� ��応付けて他のノードnn間で共用可能に保存� �るように構成したので、各ノードnnの使用者 (ユーザ)は、過去に放送された番組を、特定� ��サーバ等に負担をかけることなく、該番組� ��記録保存しているノードnnから取得して視� �することができる。

 また、各ノードnnは番組を記録保存する� �、該番組固有のコンテンツIDをキーとする公 開メッセージをルートノードに向けて送出し て公開し、かつ、他のノードnnから記録保存� ��た番組の要求を受けると、要求された番組� ��該他のノードnnへ送信するよう構成したの� �、ある番組を所望するノード(ユーザノード) は、所望の番組のコンテンツIDを生成し、当� ��コンテンツIDをキーとしてコンテンツ所在� �合せ(検索)メッセージを他のノードnnに向け� ��送出するだけで、所望の番組のコンテンツ� ��ータの所在(これを保存するコンテンツ保持 ノードのノード情報)をルートノードを通じ� �知ることができる。

 更に、各ノードnnでは、コンテンツデー� �を暗号化して保存し、コンテンツデータを� �求されると、要求元のノードnnに暗号化した コンテンツデータを送信するようにしたので 、セキュリティ性を向上させることができる 。また、暗号化されたコンテンツデータを復 号する公開鍵(復号化鍵の一例)は、登録サー� ��2dが保存管理するよう構成したので、暗号� �されたコンテンツデータを取得した際には� �登録サーバ2dから暗号化されたコンテンツデ ータが保存されていたノードnn(コンテンツ保 持ノード)の公開鍵を取得することにより、� �号化されたコンテンツデータを復号化して� �聴することができる。しかも、暗号化され� �コンテンツデータを復号する公開鍵は、各� �ードnnに固有の鍵であり、全てのノードnnの� ��開鍵を知っている登録サーバ2dのみが保存� �理するものであるので、あるノードnnにおい て暗号化され保存されたコンテンツデータを 復号する公開鍵を他のノードnnが生成するこ� ��ができず、登録サーバ2dにノードnnを指定し て公開鍵を取得しない限り、該ノードnnにて� ��号化されたデータを復号することが出来な� ��。したがって、安全性をより一層確保する� ��とができる。

 また、登録サーバ2dが、各ノードnnが記録 すべき番組を示す記録担当情報を決定し、各 ノードnnに指示するため、各放送局2a~2cから� �送される番組を各ノードnnに対して、偏り無 く記録担当として割り振ることができる。

 更に、登録サーバ2dは、各ノードnnの地域 情報に基づいて各ノードnnが記録すべき番組� ��示す記録担当情報を決定するため、当該各� ��ードnnの設置される地域を考慮して記録担� �として割り振ることができる。

 さらに、ログサーバ2eからコンテンツ毎� �利用実績を取得するよう構成することによ� �、視聴率の高い番組に対しては、より多く� �ノードnnが記録担当となるよう記録担当情報 の再割り振りを行なうよう構成することもで きる。

 また、上記実施形態においては、番組が2 時間等である場合であっても、番組を時間単 位で区切り(例えば、30分や1時間づつなど)複� ��のコンテンツデータとして記録保存、公開� ��検索の対象とするよう構成したが、番組単� ��で区切るよう構成することもできる。例え� ��、番組固有の番組のタイトルや番組固有の� ��ード(例えば、Gコード)等を、ノードIDを生� �したときと同じハッシュ関数によりハッシ� �化して、コンテンツIDを生成すればよい。

 この場合、記録担当情報(記録担当番組表 (表1参照))も、各番組毎に区切られるよう構� �すればよい。なお、24時間など、1つのノー� �nnにて記録保存できないような長い番組があ る場合には、番組単位ではなく、上記実施形 態で説明したように1つの番組を複数の録画� �間に区切り、1つの番組を複数のノードnnに� �複数のコンテンツデータとして記録保存し� �記録担当となった各ノードnnは、「番組が放 送された日時」と「放送チャンネル」(つま� �、録画開始時刻と録画ch)に従ってコンテン� �IDを生成して該コンテンツIDに従って公開す� ��。そして、各ノードnnがコンテンツの検索� �する際には、各ノードnnにて所望の番組のタ イトルやGコードを入力すると、制御部11が、 例えば、システム運営者によって登録サーバ 2d等から配布され記憶部12に記憶されたカタ� �グリスト(番組のタイトルや番組固有のコー� ��(例えば、Gコード)等と、「番組が放送され� ��日時」と「放送チャンネル」と、を対応付� ��て記憶)や、システム運営者によってweb上に 公開された上記カタログリストを参照して、 入力された番組のタイトルやGコードに対応� �る「番組が放送された日時」と「放送チャ� �ネル」に基づいて複数のコンテンツIDを生成 し、複数のコンテンツ所在問合せメッセージ を送出するよう構成する。これにより、長い 番組であっても、複数のノードnnで分担して� ��実に記録することができ、また、コンテン� ��を検索しようとするユーザにとっては、番� ��のタイトルやGコード等の入力だけで、所望 の1つの番組を構成する全てのコンテンツデ� �タを一度に検索することができる。

 また、上記実施形態では、ライブラリサ� ��バ2gには、暗号化されていないコンテンツ� �ータを保存するよう構成したが、各ノードnn から暗号化されたコンテンツデータを受信し 、暗号化されたコンテンツデータを保存する よう構成してもよい。この場合、ライブラリ サーバ2gから暗号化されたコンテンツデータ� ��取得したノードnnは、ライブラリサーバ2gに 、当該暗号化されたコンテンツデータを元々 保存していたノードnn(つまり、削除コンテン ツデータとして削除するためにライブラリサ ーバ2gにアップロード(送信)してきたノードnn )のノードIDを問い合わせて、当該ノードIDを� ��録サーバ2dに送信して該ノードIDに係るノー ドnnの公開鍵を取得し、復号化するよう構成� ��ればよい。

 また、上記実施形態では、コンテンツデ� ��タを秘密鍵にて暗号化し、公開鍵を用いて� ��号化する非対称鍵暗号方式を利用したが、� ��号化されたコンテンツデータの復号する際� ��処理負荷を低減すべく、コンテンツデータ� ��対称暗号鍵方式にて暗号化し、この鍵の受� ��渡しをする際に非対称鍵暗号方式を利用し� ��もよい。

 更に、新しい放送チャンネルが開設され� ��場合には、登録サーバ2dが各ノードnnに新し い放送チャンネルの情報を送信するよう構成 する。これにより、各ノードnnは新しい放送� ��ャンネル数を用いて、記録担当番組を再度� ��定しなおして、新しい放送チャンネルの開� ��にも対応することができる。

 また、各ノードnnにて放送チャンネル受� �の電波強度を測定し、この強度が一定レベ� �(所定閾値)に達しているか否かを判定して、 この強度が一定レベルに達していない場合に は、ノードnnは記録担当番組を変更(更新)す� �よう構成してもよい(受信強度判定手段、記� ��担当番組更新手段)。具体的には、ノードnn� ��身で記録担当番組を決定する場合には、電� ��強度が一定レベルに達していない放送チャ� ��ネルを除いて記録担当番組を決定しなおし� ��また、登録サーバ2dから記録担当情報が送� �される場合には、電波強度が一定レベルに� �していない放送チャンネルは記録すること� �できない旨を登録サーバ2dに返答し、登録サ ーバ2dにて再度選びなおされた記録担当情報� ��取得するよう構成する。これにより、常に� ��画品質が一定以上に保たれたコンテンツデ� ��タを記録保存しておくことができる。

 更に、上記実施形態では、決済サーバ2f� �、ログサーバ2eから各ノードnnの利用実績(表 3)の報告を受け(S96)、該利用実績に基づいて� �金処理を行なうよう構成したが、登録サー� �2dにて記録される各ノードnnに公開鍵を送信� ��た回数(公開鍵送信実績(表2))を利用して課� �処理を行なったり(課金処理手段)、ログサー バ2eから報告された利用実績に基づいて課金� ��理を行なう際に、登録サーバ2dの公開鍵送� �実績と照合することにより、誤った決済処� �が行なわれないよう担保するよう構成して� �よい。

 また、上記実施形態では、複数のサーバ� ��本発明のサーバ装置として機能させたが、� ��グサーバ2eにて行なわれるログの収集、管� �処理、決済サーバ2fにて行なわれる決済処理 、ライブラリサーバ2gにて行なわれる過去に� ��送されたコンテンツデータ(ノードnnにて削� ��されたコンテンツデータ)の記録保存処理を 、全て登録サーバ2dにて行なうことし、当該� ��録サーバ2dを本発明のサーバ装置として機� �させてもよい。

 なお、上記説明したコンテンツ配信シス� ��ムSは、ビデオオンデマンドサービスのシス テムに対しても適用可能である。

 また、上記実施形態においては、DHTを利� ��したアルゴリズムによって構築されたオー� ��ーレイネットワーク9を前提として説明した が、本発明はこれに限定されるものではない 。