JP2008059351A - ノード装置、処理プログラム、情報配信システム及びサーバ処理プログラム - Google Patents

Abstract

【課題】サーバ装置のような特定の装置に多大な負荷をかけることなく、過去に放送された番組を簡易な操作によって視聴することが可能なノード装置等を提供する。
【解決手段】ネットワークを介して互いに通信可能な複数のノード装置と、番組情報を放送する少なくとも一以上の放送局と、を備えた情報配信システムに含まれる前記ノード装置であって、各前記放送局から放送された番組情報を受信する番組情報受信手段と、前記受信した番組情報のうち、記録担当分として割り当てられた番組情報を、当該番組情報に固有の識別情報と対応付けて、前記複数のノード装置間で共用可能に保存する番組情報保存手段と、を有する。
【選択図】図４

Description

本発明は、ネットワークを介して互いに通信可能な複数のノード装置を備え、放送局から放送された番組情報が何れかのノード装置によって受信される情報配信システム等の技術分野に関する。

近年、デジタル放送、ハードディスクレコーダー、Ｇコード（番組を予約録画するための要素（録画日，録画チャンネル，録画開始時刻，録画終了時刻）を符号化したもの）予約、自動ＣＭ（Commercial Message）カットなど、利用者個人で、テレビ放送、ラジオ放送及びＣＡＴＶ（Cable Television or Community Antenna Television）等を録画するコンテンツのクオリティが高くなっている。また、キーワード録画などによって、極力撮り逃しを防ぐ機能も知られている。

特許文献１には、放送されている番組の映像及び音声を含む番組データを記録する複数の録画装置と、放送される番組毎に少なくとも番組の放送開始時刻及び番組の放送終了時刻を表す番組情報を記録する番組データベース装置と、番組データベース装置に接続されたサーバ装置とを備えた番組録画システムが開示されている。この番組録画システムでは、ある録画装置において番組データの記録の開始が放送開示時刻に間に合わない場合、必要な番組の放送開始時刻から放送終了時刻までの番組データがサーバ装置によって各録画装置に記録された番組データの中から検索され、検索された番組データが番組データの記録に失敗した録画装置によって取得され記録されるようになっている。これにより、１つの録画装置において所定の番組データの記録が放送開始時刻よりも後に記録された番組データの中から必要な番組データが検索されて、録画装置間で番組データの受け渡しをすることができる。

また、特許文献２には、放送番組発生メディアから放送配信された放送番組情報を全て収集（記録）する放送番組再配信ホストサイトと、インターネットを介して放送番組再配信ホストサイトから放送番組情報をダウンロードするクライアント情報処理装置と、を備えたテレビ又はラジオの放送番組情報のインターネット配信システムが開示されている。
特開２００４−３２０４５５号公報 特開２００３−１０１４９８号公報

しかしながら、上述した番組録画システムやインターネット配信システムでは、録画装置間の番組データの受け渡しをサーバ装置（又は放送番組再配信ホストサイト）が取り持つようになっているため、当該番組録画システムの利用者の数が増大すると、サーバ装置に多大の負荷がかかるという問題がある。

本発明は、以上の問題等に鑑みてなされたものであり、上記サーバ装置のような特定の装置に多大な負荷をかけることなく、過去に放送された番組を簡易な操作によって視聴することが可能なノード装置、処理プログラム、情報配信システム及びサーバ処理プログラムを提供することを課題とする。

上記課題を解決するために、請求項１に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置と、番組情報を放送する少なくとも一以上の放送局と、を備えた情報配信システムに含まれる前記ノード装置であって、各前記放送局から放送された番組情報を受信する番組情報受信手段と、前記受信した番組情報のうち、記録担当分として割り当てられた番組情報を、当該番組情報に固有の識別情報と対応付けて、前記複数のノード装置間で共用可能に保存する番組情報保存手段と、を有することを特徴とするノード装置である。

この発明によれば、各放送局から放送される番組を受信する複数のノード装置が、記録担当分として夫々割り当てられた番組を、該番組に固有のコンテンツＩＤに対応付けて複数のノード装置間で共用可能に保存するように構成したので、特定のサーバ等に負担をかけることなく、各ノード装置の使用者（ユーザ）は、過去に放送された番組を、記録保存しているノードｎｎから取得して視聴することができる。

上記課題を解決するために、請求項２に記載の発明は、請求項1に記載のノード装置であって、前記複数のノード装置間で共用可能とすべく、前記保存された番組情報に固有の前記識別情報を含む公開メッセージを、当該番組情報の所在を管理するノード装置へ向けて送出する公開メッセージ送出手段と、他の前記ノード装置から保存した前記番組情報の要求を受けると、要求された番組情報を要求元の前記他のノード装置へ送信する番組情報送信手段と、を有することを特徴とするノード装置である。

この発明によれば、各ノード装置は番組を記録保存すると、該番組固有の識別情報をキーとする公開メッセージを番組情報の所在を管理するノード装置に向けて送出して公開し、かつ、他のノード装置から記録保存した番組の要求を受けると、要求された番組を該他のノード装置へ送信するよう構成したので、ある番組を所望するノード装置は、所望の番組の識別情報を生成し、当該識別情報をキーとして検索メッセージを番組情報の所在を管理するノード装置に向けて送出するだけで、所望の番組を保存したノード装置の所在を、該番組情報の所在を管理するノード装置を通じて容易に知ることができる。

上記課題を解決するために、請求項３に記載の発明は、請求項２に記載のノード装置であって、当該ノード装置に固有の暗号化鍵を記憶する暗号化鍵記憶手段と、前記受信した番組情報のうち、記録担当分として割り当てられた番組情報を、前記記憶された暗号化鍵を用いて暗号化する暗号化手段と、を有し、前記番組情報保存手段は、暗号化した前記番組情報を前記識別情報と対応付けて保存し、前記番組情報送信手段は、前記暗号化された番組情報を要求元の前記他のノード装置へ送信することを特徴とするノード装置である。

この発明によれば、各ノード装置では、番組情報を暗号化して保存し、該番組情報を要求された場合には、暗号化された番組情報を送信するようにしたので、セキュリティ性を向上させることができる。

上記課題を解決するために、請求項４に記載の発明は、請求項１乃至３のいずれか一項に記載のノード装置であって、前記情報配信システムに参加する際に、当該情報配信システムに含まれるサーバ装置に対して、参加登録を行なう参加登録手段と、前記サーバ装置から、自己が記録すべき記録担当分の番組情報に係る情報を示す記録担当情報を取得する記録担当情報取得手段と、を有し、前記番組情報保存手段は、前記受信した番組情報のうち、前記記録担当情報に基づいて記録担当分として割り当てられた番組情報を保存することを特徴とするノード装置である。

この発明によれば、サーバ装置が各放送局から放送される番組を各ノード装置に対して偏りなく記録担当として割り振ることができる。

上記課題を解決するために、請求項５に記載の発明は、請求項４に記載のノード装置であって、前記参加登録手段は、前記サーバ装置に対して、当該ノード装置が設置される地域を示す地域情報を送信して参加登録を行ない、前記記録担当情報取得手段は、前記サーバ装置から、前記地域情報に基づいて決定された前記記録担当情報を取得することを特徴とするノード装置である。

この発明によれば、記録担当情報が地域情報に基づいて決定されるため、各放送局から放送される番組を各ノード装置に対して、当該各ノード装置の設置される地域を考慮して記録担当として割り振ることができる。

上記課題を解決するために、請求項６に記載の発明は、請求項４又は５に記載のノード装置であって、前記参加登録手段は、前記暗号化鍵によって暗号化された情報を復号化するための復号化鍵を、前記サーバ装置に送信する復号化鍵送信手段を有することを特徴とするノード装置である。

この発明によれば、暗号化された番組情報を復号する復号化鍵は、サーバ装置が保存管理するよう構成したので、暗号化された番組情報を取得した際には、サーバ装置から暗号化された番組情報が保存されていたノード装置の復号化鍵を取得することにより、暗号化された番組情報を復号化して視聴することができる。

上記課題を解決するために、請求項７に記載の発明は、請求項６に記載のノード装置であって、過去に何れかの前記放送局から放送された前記番組情報の取得を望む場合には、当該番組情報に固有の前記識別情報を含む検索メッセージを、当該番組情報の所在を管理するノード装置へ向けて送出する検索メッセージ送出手段と、前記番組情報の所在を管理するノード装置から、当該番組情報を記録しているノード装置を示すノード情報を取得するノード情報取得手段と、前記ノード情報に基づいて、前記番組情報を記録しているノード装置に対して当該番組情報の送信を要求する番組情報要求手段と、前記番組情報を記録しているノード装置から、前記番組情報要求手段にて要求した番組情報であって、暗号化された前記番組情報を取得する番組情報取得手段と、前記暗号化された番組情報を復号化するための前記復号化鍵を要求すべく復号化鍵要求情報を前記サーバ装置に送信する復号化鍵要求情報送信手段と、前記復号化鍵を前記サーバ装置から取得する復号化鍵取得手段と、前記取得した復号化鍵を用いて、前記暗号化された番組情報を復号化する復号化手段と、を有することを特徴とするノード装置である。

この発明によれば、ある番組を所望するノード装置は、所望の番組の識別情報を生成し、当該識別情報をキーとして検索メッセージを番組情報の所在を管理するノード装置に向けて送出することにより、所望の番組を保存したノード装置の所在を、該番組情報の所在を管理するノード装置を通じて容易に知ることができ、該番組情報を記録しているノード装置から暗号化された番組情報を取得できる。そして、サーバ装置から該番組情報を復号化するための復号化鍵を取得して、これを用いて暗号化された番組情報を復号化し、所望の番組を視聴することができる。

上記課題を解決するために、請求項８に記載の発明は、請求項１乃至７のいずれか一項に記載のノード装置であって、記録担当分として割り当てられた番組情報の受信強度を測定し、該受信強度が所定閾値に達しているか否かを判定する受信強度判定手段と、判定の結果、受信強度が所定閾値に達していない場合には、該番組情報を放送している前記放送局を除く他の前記放送局から放送される番組情報を新たな記録担当の番組情報として更新する記録担当番組更新手段と、を有することを特徴とするノード装置。

これによれば、常に録画品質が一定以上に保たれた番組情報を記録保存しておくことができる。

上記課題を解決するために、請求項９に記載の発明は、コンピュータを、請求項１乃至８の何れか一項に記載のノード装置として機能させることを特徴とする処理プログラムである。

上記課題を解決するために、請求項１０に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置と、番組情報を放送する少なくとも一以上の放送局と、前記複数のノード装置の参加登録を管理するサーバ装置と、を備えた情報配信システムであって、各前記ノード装置は、各前記放送局から放送された番組情報を受信する番組情報受信手段と、前記サーバ装置に対して、参加登録を行なう参加登録手段と、前記サーバ装置から、自己が記録すべき記録担当分の番組情報に係る情報を取得する記録担当情報を取得する記録担当情報取得手段と、前記受信した番組情報のうち、前記記録担当情報に基づいて、記録担当分として割り当てられた番組情報を、当該番組情報に固有の識別情報と対応付けて、前記複数のノード装置間で共用可能に保存する番組情報保存手段と、を有し、前記サーバ装置は、前記ノード装置から参加登録を受けると、当該ノード装置が記録担当となるべき番組情報に係る情報を示す前記記録担当情報を決定する記録担当情報決定手段と、前記決定された記録担当情報を前記ノード装置に送信する記録担当情報送信手段と、を有することを特徴とする情報配信システムである。

この発明によれば、各放送局から放送される番組を受信する複数のノード装置が、サーバ装置から記録担当分として夫々割り当てられた番組を、該番組に固有の識別情報に対応付けて複数のノード装置間で共用可能に保存するように構成したので、特定のサーバ等に負担をかけることなく、各ノード装置の使用者（ユーザ）は、過去に放送された番組を、記録保存しているノード装置から取得して視聴することができる。

上記課題を解決するために、請求項１１に記載の発明は、請求項１０に記載の情報配信システムであって、前記ノード装置の前記参加登録手段は、前記サーバ装置に対して、当該ノード装置が設置される地域を示す地域情報を送信して参加登録を行ない、前記サーバ装置の前記記録担当情報決定手段は、前記ノード装置から前記地域情報を受信して参加登録を受けると、前記記録担当情報を前記地域情報に基づいて決定することを特徴とする情報配信システムである。

上記課題を解決するために、請求項１２に記載の発明は、請求項１０又は１１に記載の情報配信システムであって、各前記ノード装置は、当該ノード装置に固有の暗号化鍵を記憶する暗号化鍵記憶手段と、前記受信した番組情報のうち、記録担当分として割り当てられた番組情報を、前記記憶された暗号化鍵を用いて暗号化する暗号化手段と、を有し、かつ、前記番組情報保存手段は、暗号化した前記番組情報を前記識別情報と対応付けて保存し、かつ、前記複数のノード装置間で共用可能とすべく、前記保存された番組情報に固有の前記識別情報を含む公開メッセージを、当該番組情報の所在を管理するノード装置へ向けて送出する公開メッセージ送出手段と、他の前記ノード装置から保存した前記番組情報の要求を受けると、前記要求された番組情報であって、暗号化された番組情報を要求元の前記他のノード装置へ送信する番組情報送信手段と、を有し、更に、前記参加登録手段は、前記暗号化鍵によって暗号化された情報を復号化するための復号化鍵を、前記サーバ装置に送信する復号化鍵送信手段を有し、前記サーバ装置は、前記ノード装置から、当該ノード装置を示すノード情報と前記復号化鍵を受信すると、当該ノード情報と当該復号化鍵を対応付けて記憶する復号化鍵記憶手段と、何れかの前記ノード装置から、前記番組情報を復号化するための前記復号化鍵を要求する復号化鍵要求情報を受信すると、受信した前記復号化鍵要求情報に含まれる前記ノード情報と対応付けて前記復号化鍵記憶手段に記憶された復号化鍵を、当該復号化鍵の要求元のノード装置に送信する復号化鍵送信手段と、を有し、前記番組情報の取得を望むノード装置は、当該番組情報に固有の前記識別情報を含む検索メッセージを、当該番組情報の所在を管理するノード装置へ向けて送出する検索メッセージ送出手段と、前記番組情報の所在を管理するノード装置から、当該番組情報を記録しているノード装置を示すノード情報を取得するノード情報取得手段と、前記取得したノード情報に基づいて、前記番組情報を記録しているノード装置に対して当該番組情報の送信を要求する番組情報要求手段と、前記番組情報を記録しているノード装置から、前記番組情報要求手段にて要求した番組情報であって、暗号化された前記番組情報を取得する番組情報取得手段と、前記暗号化された番組情報を復号化するための前記復号化鍵を要求すべく、前記番組情報を記録しているノード装置を示す前記ノード情報を含む前記復号化鍵要求情報を前記サーバ装置に送信する復号化鍵要求情報送信手段と、前記復号化鍵を前記サーバ装置から取得する復号化鍵取得手段と、前記取得した復号化鍵を用いて、前記暗号化された番組情報を復号化する復号化手段と、を有することを特徴とする情報配信システムである。

上記課題を解決するために、請求項１３に記載の発明は、請求項１０乃至１２のいずれか一項に記載の情報配信システムにおいて、前記サーバ装置は、前記各ノード装置の使用者毎の使用者情報を記憶、管理する使用者情報管理手段と、前記復号化鍵要求情報を送信したノード装置の使用者に対して課金処理を行なう課金処理手段と、を有することを特徴とする情報配信システムである。

上記課題を解決するために、請求項１４に記載の発明は、請求項１０乃至１３のいずれか一項に記載の情報配信システムにおいて、全ての前記放送局から放送された全ての前記番組情報が、前記複数のノード装置で分担され、何れかの前記ノード装置にて保存されることを特徴とする情報配信システムである。

上記課題を解決するために、請求項１５に記載の発明は、１又は複数のコンピュータを、請求項１０乃至１４の何れか一項に記載のサーバ装置として機能させることを特徴とするサーバ処理プログラムである。

本発明によれば、各放送局から放送される番組を受信する複数のノード装置が、記録担当分として夫々割り当てられた番組を、該番組に固有のコンテンツＩＤに対応付けて複数のノード装置間で共用可能に保存するように構成したので、特定のサーバ等に負担をかけることなく、各ノード装置の使用者（ユーザ）は、過去に放送された番組を、記録保存しているノードｎｎから取得して視聴することができる。

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

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

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

図１の下部枠１０１内に示すように、ＩＸ（Internet eＸchange）３、ＩＳＰ（Internet Service Provider）４ａ,４ｂ、ＤＳＬ（Digital Subscriber Line）回線事業者（の装置）５ａ,５ｂ、ＦＴＴＨ（Fiber To The Home）回線事業者（の装置）６、及び通信回線（例えば、電話回線や光ケーブル等）７等によって、インターネット等のネットワーク（現実世界の通信ネットワーク）８が構築されている。なお、図１の例におけるネットワーク（通信ネットワーク）８には、データ（パケット）を転送するためのルータが、適宜挿入されているが図示を省略している。

コンテンツ配信システムＳは、このようなネットワーク８を介して相互に接続された複数のノード装置（以下、単に、「ノード」という）ｎ１，ｎ２・・・ｎ２１を備えて構成されることになり、ピアツーピア方式のネットワークシステムとなっている（なお、実際には、これ以上のノードが存在することになる）。また、各ノードｎ１〜ｎ２１には、固有の製造番号及びＩＰ（Internet Protocol）アドレスが割り当てられている。なお、製造番号及びＩＰアドレスは、複数のノード間で重複しないものである。

これらのノードｎ１〜ｎ２１は、例えば、ＣＡＴＶ（Cable Television or Community Antenna Television）など、専用サービスの専用のセットトップボックス（ＳＴＢ）などであり、全国の、或いは海外の複数の放送局２ａ、２ｂ、２ｃから様々な放送チャンネルで放送された番組の映像及び音声を含む番組データ（番組内に組み込まれるＣＭ情報等を含む場合もある）を有する番組情報（以下、「コンテンツデータ」という）を記録（保存）することが可能になっている。なお、放送局２ａ、２ｂ、２ｃからコンテンツデータを放送する放送媒体としては、衛星電波、地上波、インターネット、ＣＡＴＶケーブル等の専用回線等を適用することができる。

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

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

本実施形態においては、ＤＨＴを利用したアルゴリズムによって構築されたオーバーレイネットワーク９を前提としており、このオーバーレイネットワーク９（図１の上部枠１００内）に配置されたノードｎ１〜ｎ１５を、オーバーレイネットワーク９に参加しているノードｎｎという。言い換えれば、オーバーレイネットワーク９は、ノードｎｎの参加により形成されている。

このようなオーバーレイネットワーク９への参加は、登録サーバ２ｄへユーザ情報を送信しコンテンツ配信システムＳへの登録が適式に行なわれたノードｎ１６〜ｎ２１が（この時点では未だオーバーレイネットワーク９へは参加していない）、参加している任意のノードｎｎに対して参加要求を示す参加メッセージを送信することによって行われる。そして、ユーザ情報を受けた登録サーバ２ｄにてノードの登録が行なわれると、新たに登録しようとするノードｎ１６が、既に参加している任意のノードｎｎにアクセスして、参加メッセージを送信して参加している任意のノードｎｎからＤＨＴ（後に詳述する）をコピーさせてもらう。

上述したように、各ノードｎｎは固有の識別情報としてのノードＩＤを有しており、当該ノードＩＤは、例えば、ＩＰアドレスあるいは製造番号を共通のハッシュ関数（例えば、ＳＨＡ−１等）によりハッシュ化した値（例えば、ｂｉｔ長が１６０ｂｉｔ）であり、一つのＩＤ空間に偏りなく分散して配置されることになる。

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

また、各ノードｎｎは、夫々、ＤＨＴを保持している。このＤＨＴは、オーバーレイネットワーク９上における各種メッセージの転送先を規定しており、具体的には、ノードＩＤ空間内で適度に離れたノードｎｎのノードＩＤとそのＩＰアドレス及びポート番号等の組が複数登録されたルーティングテーブル（転送先テーブル）が含まれている。

図２は、ノードｎ１が保持するＤＨＴのルーティングテーブルの一例を示す図であり、図３は、ＤＨＴのノードＩＤ空間の一例を示す概念図である。

なお、図２及び図３の例においては、説明の便宜上、ノードＩＤのｂｉｔ長を２ｂｉｔ×３桁＝６ｂｉｔとし、各桁を４進数（０〜３の整数）で表している（実際には、もっと長いｂｉｔ長を用い、各桁も例えば４ｂｉｔに区切って０〜ｆの１６進数で表現する）。

図２の例において、ＤＨＴのルーティングテーブルは、レベル１〜レベル３のテーブルからなり（複数のレベルに区分されており）、各レベルのテーブルエントリーには、エリア毎に、ノードＩＤとこれに対応するノードｎｎのＩＰアドレス及びポート番号が対応付けられて登録されている。各レベルのテーブルにおける各エリアは、ＤＨＴのノードＩＤ空間を分割することにより得られるエリアである。例えば、図３に示すように、レベル１では、ＤＨＴのノードＩＤ空間全体が４分割され、“０００”〜“０３３”のノードＩＤが存在するエリアを０ＸＸのエリア、“１００”〜“１３３”のノードＩＤが存在するエリアを１ＸＸのエリア、“２００”〜“２３３” のノードＩＤが存在するエリアを２ＸＸのエリア、“３００”〜“３３３”のノードＩＤが存在するエリアを３ＸＸのエリアとする。また、レベル２では、レベル１のエリア（つまり、０ＸＸ〜３ＸＸのエリア）が更に４分割、例えば１ＸＸのエリアが４分割され、“１００”〜“１０３”のノードＩＤが存在するエリアを１０Ｘのエリア、“１１０”〜“１１３” のノードＩＤが存在するエリアを１１Ｘのエリア、“１２０”〜“１２３”のノードＩＤが存在するエリアを１２Ｘのエリア、“１３０”〜“１３３” のノードＩＤが存在するエリアを１３Ｘのエリアとする。

そして、例えば、ノードｎ１のノードＩＤが“１２２”とすると、図２に示すように、かかるノードｎ１のレベル１における１ＸＸのエリア（自己（つまり、自ノード）が存在するエリア）のテーブルには、自己のノードＩＤ及びＩＰアドレス（ＩＰアドレスは自分のものであるので、当該ルーティングテーブルに登録しなくても良い）等が登録され、自己が存在しないエリア（つまり、０ＸＸのエリア、２ＸＸのエリア、及び３ＸＸのエリア）には、夫々、他の任意のノードｎｎのノードＩＤ及びＩＰアドレス等が登録されている。

また、かかるノードｎ１のレベル２における１２Ｘのエリア（自己が存在するエリア）のテーブルには、図２に示すように、自己のノードＩＤ及びＩＰアドレス（ＩＰアドレスは自分のものであるので、当該ルーティングテーブルに登録しなくても良い）等が登録され、自己が存在しないエリア（つまり、１０Ｘのエリア、１１Ｘのエリア、及び１３Ｘのエリア）等には、夫々、他の任意のノードｎｎのノードＩＤ及びＩＰアドレス等が登録されている。

更に、かかるノードｎ１のレベル３には、図２に示すように、ノードＩＤが“１２０”〜“１２２”のノードＩＤ及びＩＰアドレス（ＩＰアドレスは自分のものであるので、当該ルーティングテーブルに登録しなくても良い）等が登録されている。

なお、図２及び図３の例では、ノードＩＤのｂｉｔ長を３桁×２ｂｉｔとしたので、レベル１〜３の３レベル分のテーブルで網羅できるが、ノードＩＤのｂｉｔ長が増せば、その分のテーブルが必要となる（例えば、ノードＩＤのｂｉｔ長を１６桁×４ｂｉｔとした場合、１６レベル分のテーブルが必要となる）。

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

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

本実施形態は、各放送局２ａ〜２ｃから放送される全番組を、各ノードｎｎに記録担当として割り当て、各ノードｎｎは記録担当分として割り当てられた番組を、複数のノードｎｎ間で共用可能に保存（記録）するよう構成する。なお、本実施形態では、各ノードｎｎにて自己の記録担当時間を決定する場合と、各ノードｎｎのシステムＳへの参加登録時に、登録サーバ２ｄから、記録担当番組が割り当てられ、装置内部に記録担当番組表として記憶する場合の２通りの例について説明する。表１は、後者の例、すなわち登録サーバ２ｄから、あるノードｎｎに割り当てられた記録担当番組表の一例である。各ノードｎｎは、該記録担当番組表（表１参照）に従い、録画（記録）開始時刻がきたら、該当する録画ｃｈを受信して録画（保存）するよう構成する。

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

また、これらのコンテンツデータには、夫々、番組に固有のコンテンツＩＤ（識別情報の一例）が生成され、コンテンツデータと対応付けて各ノードｎｎ内に保存される。コンテンツＩＤは、例えば、「番組が放送された日時」と「放送チャンネル」（つまり、録画開始時刻と録画ｃｈ）に従って生成される。

例えば、２００６年８月４日１８時００分００秒に、放送チャンネル１で放送された番組に対しては、
２００６０８０４１８０００００１
という数字列を上記ノードＩＤを得るときと共通のハッシュ関数によりハッシュ化して当該番組に一意に対応するコンテンツＩＤを生成するようになっている（つまり、コンテンツＩＤは、ノードＩＤと同一のＩＤ空間に配置される）。

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

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

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

図４（Ａ）は、コンテンツ保持ノードから送出されたパブリッシュメッセージの流れの一例を、ＤＨＴのノードＩＤ空間にて示した概念図である。

図４（Ａ）の例において、例えば、コンテンツ保持ノードであるノードｎ１は、自己のＤＨＴのレベル１のテーブルを参照して、パブリッシュメッセージに含まれるコンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する例えばノードｎ８のＩＰアドレス及びポート番号を取得し、そのＩＰアドレス及びポート番号宛てに、上記パブリッシュメッセージを送信する。

これに対して、ノードｎ８は、当該パブリッシュメッセージを受信し、自己のＤＨＴのレベル２のテーブルを参照して、当該パブリッシュメッセージに含まれるコンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する例えばノードｎ１１のＩＰアドレス及びポート番号を取得し、そのＩＰアドレス及びポート番号宛てに、上記パブリッシュメッセージを転送する。

これに対して、ノードｎ１１は、当該パブリッシュメッセージを受信し、自己のＤＨＴのレベル３のテーブルを参照して、当該パブリッシュメッセージに含まれるコンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する例えばノードｎ１３のＩＰアドレス及びポート番号を取得し、そのＩＰアドレス及びポート番号宛てに、上記パブリッシュメッセージを転送する。

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

なお、パブリッシュメッセージに含まれるノード情報は、コンテンツ保持ノードからルートノードに至るまでの転送経路におけるノードｎｎ（図４（Ａ）の例では、ノードｎ８及びノードｎ１１）においても登録（キャッシュ）される。

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

図４（Ｂ）は、ユーザノードから送出されたコンテンツ所在問合せメッセージの流れの一例を、ＤＨＴのノードＩＤ空間にて示した概念図である。

図４（Ｂ）の例において、例えば、ユーザノードであるノードｎ３は、自己のテーブルを参照して、コンテンツ所在問合せメッセージに含まれるコンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有する例えばノードｎ１０のＩＰアドレス及びポート番号を取得し、そのＩＰアドレス及びポート番号宛てに、上記コンテンツ所在問合せメッセージを送信する。

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

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

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

なお、図４（Ｂ）に示すように、ユーザノードがコンテンツ保持ノードに対して送信要求を行なってコンテンツデータを取得する構成（Ｐｕｓｈ）に限らず、例えば、ルートノードが、コンテンツ保持ノードであるノードｎ１に対して、ユーザノードのノード情報とコンテンツＩＤを含むコンテンツ送信要求メッセージを送信し、これに対して、コンテンツ保持ノードであるノードｎ１は、コンテンツ送信要求メッセージを受信し、自己が保存しているコンテンツデータから、当該コンテンツ送信要求メッセージに含まれるコンテンツＩＤに対応するコンテンツデータを取得し、当該コンテンツ送信要求メッセージに含まれるユーザノードであるノードｎ３のノード情報（ＩＰアドレス及びポート番号）に基づいて当該コンテンツデータを、ノードｎ３に送信する構成（Ｐｕｌｌ）としてもよい。また、上記ユーザノードは、コンテンツ所在問合せメッセージがルートノードに辿り着くまでの間に、当該ルートノードと同じノード情報をキャッシュしているキャッシュノードから当該ノード情報を取得（受信）することもできる。

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

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

図５は、ノードｎｎの概要構成例を示す図である。

ノードｎｎは、図５に示すように、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データ及びプログラムを記憶するＲＯＭ等から構成されたコンピュータとしての制御部１１と、各種データ（例えば、コンテンツデータ、ノード情報、ＤＨＴ、登録サーバ２ｄ、ログサーバ２ｅ、決済サーバ２ｆ及びライブラリサーバ２ｇのＩＰアドレス等）、当該ノードｎｎ固有の秘密鍵（暗号化鍵の一例）、自己が記録すべき番組を示す記録担当情報（表１参照）及びプログラム等を記憶保存（格納）するためのＨＤＤ等から構成された番組情報保存手段及び暗号化鍵記憶手段としての記憶部１２と、受信されたコンテンツデータを一時蓄積するバッファメモリ１３と、コンテンツデータに含まれるエンコードされたビデオデータ（映像情報）及びオーディオデータ（音声情報）等をデコード（データ伸張や復号化等）するための復号化手段としてのデコーダ部１４と、当該デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する映像処理部１５と、当該映像処理部１５から出力されたビデオ信号に基づき映像表示するＣＲＴ，液晶ディスプレイ等の表示部１６と、上記デコードされたオーディオデータをアナログオーディオ信号にＤ（Digital）／Ａ（Analog）変換した後これをアンプにより増幅して出力する音声処理部１７と、当該音声処理部１７から出力されたオーディオ信号を音波として出力するスピーカ１８と、受信されたコンテンツデータを暗号化するための暗号化手段としてのエンコーダ部１９と、ネットワーク８を通じて他のノードｎｎや各サーバ２ｄ〜２ｇとの間の通信制御を行なうための通信部１９ａと、放送局２ａから放送された番組のコンテンツデータを受信するためのチューナ等の受信部１９ｂと、ユーザからの指示を受け付け当該指示に応じた指示信号を制御部１１に対して与える入力部（例えば、キーボード、マウス、或いは、操作パネル等）１９ｃと、を備えて構成され、制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４、エンコーダ部１９、通信部１９ａ、及び受信部１９ｂは、バス１９ｄを介して相互に接続されている。なお、ノードｎｎとしては、パーソナルコンピュータ、ＳＴＢ（Set Top Box）、或いは、ＴＶ受信機等を適用可能である。

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

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

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

次に、図６〜図９を参照して、登録サーバ２ｄ、ログサーバ２ｅ、決済サーバ２ｆ及びライブラリサーバ２ｇの構成及び機能について説明する。なお、本実施形態は、登録サーバ２ｄ及び決済サーバ２ｆが、本発明のサーバ装置として機能する場合の例である。

先ず、図６を参照して、登録サーバ２ｄの構成及び機能について説明する。

図６は、登録サーバ２ｄの概要構成例を示す図である。

登録サーバ２ｄは、一般のサーバコンピュータを適用可能であり、図６に示すように、ＣＰＵ，作業用ＲＡＭ，各種データ及びプログラムを記憶するＲＯＭ等から構成された制御部２１と、各種データ（例えば、ログサーバ２ｅ、決済サーバ２ｆ及びライブラリサーバ２ｇのＩＰアドレス等）及びプログラム等を記憶（格納）するＨＤＤ等から構成された記憶部２２と、ネットワーク８を通じてノードｎｎとの間の通信制御を行なうための通信部２３と、を備えて構成され、これらの各構成要素はバス２４を介して相互に接続されている。

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

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

各ノードｎｎのノードＩＤは、例えば、当該ノードｎｎの製造時又は出荷時に製造番号に基づいて生成され登録されたり、ユーザの個人情報、地域情報、決済情報、公開鍵は、当該ユーザによるノードｎｎの購入時に該ノードＩＤ等に対応付けて登録される。或いは、これら各ノードＩＤや個人情報等は、当該ノードｎｎ購入後のコンテンツ配信システムＳへの利用手続完了時（オーバーレイネットワーク９への参加時）に登録されることとなる。そして、登録サーバ２ｄから決済サーバ２ｆに決済情報が送られ、決済サーバ２ｆにて各ノードｎｎの使用者に対して課金処理が行なわれる他、当該ユーザ情報データベース２２ａは、他の各サーバ２ｅ〜２ｇからもアクセス可能に構成され、必要に応じてユーザ情報データベース２２ａのユーザの個人情報や決済情報が利用できるようになっている。

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

次に、図７を参照して、ログサーバ２ｅの構成及び機能について説明する。

図７は、ログサーバ２ｅの概要構成例を示す図である。

ログサーバ２ｅは、一般のサーバコンピュータを適用可能であり、図７に示すように、ＣＰＵ，作業用ＲＡＭ，各種データ及びプログラムを記憶するＲＯＭ等から構成された制御部３１と、各種データ（例えば、登録サーバ２ｄ、ログサーバ２ｅ及びライブラリサーバ２ｇのＩＰアドレス等）及びプログラム等を記憶（格納）するＨＤＤ等から構成された記憶部３２と、ネットワーク８を通じてノードｎｎや各サーバとの間の通信制御を行なうための通信部３３と、を備えて構成され、これらの各構成要素はバス３４を介して相互に接続されている。

記憶部３２では、各放送局２ａ〜２ｃから放送された各番組の放送後に、システムＳを利用して、誰が、どの番組を、何回視聴（ダウンロード）したか等のシステム利用実績を管理する。具体的には、
（ｉ）各ノードｎｎのユーザ（使用者）毎の利用実績を、各ノードｎｎに固有のノードＩＤに対応付けて管理（記憶）し（表３参照）、
（ｉｉ）各番組（コンテンツ）毎の利用実績を、各番組に固有のコンテンツＩＤに対応付けて管理（記憶）する（表４参照）。

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

次に、図８を参照して、決済サーバ２ｆの構成及び機能について説明する。

図８は、決済サーバ２ｆの概要構成例を示す図である。

決済サーバ２ｆは、一般のサーバコンピュータを適用可能であり、図８に示すように、ＣＰＵ，作業用ＲＡＭ，各種データ及びプログラムを記憶するＲＯＭ等から構成された制御部４１と、各種データ（例えば、登録サーバ２ｄ、ログサーバ２ｅ及びライブラリサーバ２ｇのＩＰアドレス等）及びプログラム等を記憶（格納）するＨＤＤ等から構成された記憶部４２と、ネットワーク８を通じてノードｎｎや各サーバとの間の通信制御を行なうための通信部４３と、を備えて構成され、これらの各構成要素はバス４４を介して相互に接続されている。

このような構成において、制御部４１は、ＣＰＵが記憶部４２等に記憶されたプログラムを読み出して実行することにより、全体を統括制御すると共に、本発明のサーバ装置の課金処理手段等として機能し、ログサーバ２ｅから受信した各ノードｎｎのユーザ（使用者）毎の利用実績に応じて、各ノードｎｎのユーザに対して利用料金を課する課金処理を行なう。実際に課金処理を行なう際には、登録サーバ２ｄのユーザ情報データベース２２ａにアクセスし、ユーザの個人情報及び決済情報を利用して行なう。

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

図９は、ライブラリサーバ２ｇの概要構成例を示す図である。

ライブラリサーバ２ｇは、一般のサーバコンピュータを適用可能であり、図９に示すように、ＣＰＵ，作業用ＲＡＭ，各種データ及びプログラムを記憶するＲＯＭ等から構成された制御部５１と、各種データ（例えば、登録サーバ２ｄ、ログサーバ２ｅ及び決済サーバ２ｆのＩＰアドレス等）及びプログラム等を記憶（格納）するＨＤＤ等から構成された記憶部５２と、ネットワーク８を通じてノードｎｎや各サーバとの間の通信制御を行なうための通信部５３と、を備えて構成され、これらの各構成要素はバス５４を介して相互に接続されている。

このような構成において、制御部５１は、ＣＰＵが記憶部５２等に記憶されたプログラムを読み出して実行することにより、全体を統括制御し、各放送局２ａ〜２ｃから過去に放送された番組を記憶部５２に記憶させる。

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

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

［２．コンテンツ配信システムの動作］
次に、コンテンツ配信システムＳの動作について説明する。

［２−１.ノードｎｎの処理］
図１０は、ノードｎｎの制御部１１における処理を示すフローチャートである。ノードｎｎの電源がオンとされることにより、本発明の処理プログラムが制御部１１の制御に基づいて実行される。

先ず、電源がオフとされたか否かを判定し（ステップＳ１）、オフとされていない場合（ステップＳ１：Ｎｏ）には、ステップＳ２以下の処理へ移行する。

そして、制御部１１は、ユーザが入力部１９ｃ等を操作することにより、コンテンツ配信システムＳへの参加登録が指示されたか否かを判定し（ステップＳ２）、コンテンツ配信システムＳへの参加登録が指示された場合（ステップＳ２：Ｙｅｓ）には、「登録処理」を行なう（ステップＳ３）。

一方、コンテンツ配信システムＳへの参加登録が指示されていない場合（ステップＳ２：Ｎｏ）には、ステップＳ４へ移行して、記憶部１２に記憶された記録担当番組表（表１）を参照して記録担当となっている番組の録画開始時刻が到来したか否かを判定し（ステップＳ４）、記録担当となっている番組の録画開始時刻が到来した場合（ステップＳ４：Ｙｅｓ）には、「録画処理」を行なう（ステップＳ５）。

一方、記録担当となっている番組の録画開始時刻が到来していない場合（ステップＳ４：Ｎｏ）には、ステップＳ６へ移行して、コンテンツ視聴ログをログサーバ２ｅに送信すべき時刻（ログ報告時刻）が到来したか否かを判定する（ステップＳ６）。

そして、ログ報告時刻が到来した場合（ステップＳ６：Ｙｅｓ）には、「ログ送信処理」を行ない（ステップＳ７）、ログ報告時刻が到来していない場合（ステップＳ６：Ｎｏ）には、ステップＳ８へ移行する。

次いで、制御部１１は、ユーザが入力部１９ｃ等を操作することにより、過去に放送局２ａ〜２ｃから放送された番組について、再生指示がされたか否かを判定し（ステップＳ８）、再生指示がされた場合（ステップＳ８：Ｙｅｓ）には、該番組をコンテンツ配信システムＳ内で検索すべく、「再生処理」を行なう（ステップＳ９）。

一方、再生指示がされていない場合（ステップＳ８：Ｎｏ）には、ステップＳ１へ戻り、電源がオフとされる（ステップＳ１：Ｙｅｓ）まで、上記ステップＳ１〜Ｓ９の処理が繰り返し行なわれる。

■ステップＳ３における登録処理
次に、上記ステップＳ３における「登録処理」について説明する。なお、当該「登録処理」は、各ノードｎｎにて記録担当番組を決定し、記録担当番組表として記憶する場合における登録処理と、各ノードｎｎのシステムＳへの参加登録時に、登録サーバ２ｄから、記録担当番組が割り当てられ、装置内部に記録担当番組表（表１参照）として記憶する場合について説明する。

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

先ず、制御部１１は、ノードｎｎの使用者（ユーザ）の個人情報、地域情報、決済情報等のユーザ情報を取得する（ステップＳ２１）、具体的には、上記ユーザ情報の入力をユーザに促して、ユーザが入力部１９ｃを操作することにより取得する。

そして、ユーザ情報が取得されたか否かを判定し（ステップＳ２２）、ユーザ情報が取得できれば（ステップＳ２２：Ｙｅｓ）、登録サーバ２ｄに接続（アクセス）する（ステップＳ２３）。ユーザ情報が取得できなれば（ステップＳ２２：Ｎｏ）、ステップＳ２１に移行して、ユーザ情報が取得できるまで、ユーザ情報の入力を促す等のユーザ情報取得処理を繰り返し行なう。

次いで、登録サーバ２ｄに接続できたか否かを判定し（ステップＳ２４）、登録サーバ２ｄに接続できた場合（ステップＳ２４：Ｙｅｓ）には、制御部１１は参加登録手段として機能し、ステップＳ２１にて取得したユーザ情報を登録サーバ２ｄに送信する（ステップＳ２５）。一方、登録サーバ２ｄに接続できなれば（ステップＳ２４：Ｎｏ）、ステップＳ２３に移行して、登録サーバ２ｄに接続できるまで、登録サーバ２ｄへの接続を試みる。

そして、ユーザ情報を登録サーバ２ｄに送信できたか否かを判定し（ステップＳ２６）、ユーザ情報を送信できた場合（ステップＳ２６：Ｙｅｓ）には、記録担当番組を決定し、記憶部１２に自己の記録担当番組表として記憶する（ステップＳ２７）。記録担当番組の決定方法としては、例えば、ノードｎｎ固有の製造番号を、自己が受信可能な放送チャンネルのチャンネル数で割った余りを算出して得た数のチャンネルＮｏを録画チャンネルとして決定する。そして、製造番号を、時間帯総数で割った余りを算出て得た数に相当する時間を録画時間として決定する。時間帯総数とは、例えば、１日２４時間を午前０時から３０分ごとのコンテンツデータとして録画する場合には、４８個の時間帯（録画タイミング）が発生する。そして、自己の製造番号を４８で割った余りが３であれば、３番目の時間帯、つまり、午前１時から午前１時半までの３０分間が録画時間となる。この他に、ノード製造時に製造時期や製造場所毎に記録担当番組を複数のノードｎｎに振り分けて割り当てて記憶させておくことにより、全ての放送チャンネルの番組を複数のノードｎｎにて網羅するよう構成することもできる。また、各放送チャンネルを受信可能な地域ごとに複数の記録担当情報を予め記憶部１２に記憶させておき、当該複数の記録担当情報の中から、ステップＳ２１にて取得したユーザ情報に含まれる地域情報に基づいて、ノードｎｎ自身がノードｎｎの地域情報に対応する地域の記録担当情報を抽出し、自己の記憶担当番組表として記憶しなおすよう構成することもできる。

一方、ユーザ情報を送信できなかった場合（ステップＳ２６：Ｎｏ）には、送信できるまでステップＳ２５の送信処理を繰り返し行なう。

そして、ステップＳ２８にて、記録担当情報を決定、記憶できたか否かを判定し（ステップＳ２８）、記録担当情報を決定、記憶できた場合（ステップＳ２８：Ｙｅｓ）、「登録処理」を終了し、記録担当情報を決定、記憶できなかった場合（ステップＳ２８：Ｎｏ）には、取得できるまで監視し記録担当決定・記憶処理を繰り返す。

続いて、図１２のフローチャートを用いて、登録サーバ２ｄから、記録担当番組が割り当てられる場合における登録処理について説明する。なお、ステップＳ３１〜Ｓ３６の処理は、夫々上述したステップＳ２１〜Ｓ２６の処理と同様であるため、ここでの説明は省略する。

ステップＳ３７では、制御部１１が記録担当情報取得手段として機能し、登録サーバ２ｄから記録担当情報を取得する（ステップＳ３７）。具体的には登録サーバ２ｄにおける処理において詳述するが、登録サーバ２ｄでは、ステップＳ３５にて送信したユーザ情報に含まれる地域情報に基づいて、ノードｎｎの地域情報に対応する地域の記録担当情報が決定され、ノードｎｎに送信される。

そして、ステップＳ３８にて、記録担当情報を取得できたか否かを判定し（ステップＳ３８）、記録担当情報を取得できた場合（ステップＳ３８：Ｙｅｓ）、「登録処理」を終了し、記録担当情報を取得できなかった場合（ステップＳ３８：Ｎｏ）には、取得できるまで登録サーバ２ｄからの記録情報の送信を待つ。

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

先ず、制御部１１は、番組を記録するための記憶部１２の記憶領域が、容量不足であるか否かを判定する（ステップＳ４１）、具体的には、所定閾値以上記憶領域が残されているか否かを判定する。所定閾値は例えば、次の記録時間分（例えば３０分）の容量とする。

判定の結果、記憶領域の容量不足である場合（ステップＳ４１：Ｙｅｓ）には、「削除処理」を行ない（ステップＳ４２）、再び、容量不足であるか否かを判定する（ステップＳ４３）。「削除処理」についてはこの後詳述する。そして、「削除処理」を行なってもなお容量不足である場合（ステップＳ４３：Ｙｅｓ）には、処理を終了する。ある番組に対して予め複数のノードｎｎが記録担当として割り当てられる場合には、１台のノードｎｎが容量不足によって録画できないとしても、他の記録担当ノードｎｎが当該番組を記録することで十分カバーできる。

一方、記憶領域の容量が不足していない場合（ステップＳ４１：Ｎｏ、Ｓ４３：Ｎｏ）には、制御部１１は番組情報受信手段及び番組情報保存手段として機能し、録画すべき録画チャンネルの放送を受信してコンテンツデータ（番組）の受信し、録画を開始する（ステップＳ４４）。

そして、録画が適式に行なわれたか否かを判定し（ステップＳ４５）、録画開始が適式に行なわれた場合（ステップＳ４５：Ｙｅｓ）には、制御部１１は、暗号化手段として機能し、受信された該コンテンツデータを記憶部１２に記憶した自己の固有の秘密鍵（暗号化鍵の一例）でエンコーダ部１９により暗号化させながら（つまり、秘密鍵を用いて受信されたコンテンツデータを暗号化する）、記憶部１２に記録するように制御する（ステップＳ４６）。

そして、当該録画処理が終了すると、制御部１１は、「番組が放送された日時」と「放送チャンネル」（つまり、録画開始時刻と録画ｃｈ）に従って固有のコンテンツＩＤを生成し、暗号化されたコンテンツデータと対応付けて記憶部１２に記憶する（ステップＳ４７）。

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

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

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

そして、ライブラリサーバ２ｇに接続（アクセス）する（ステップＳ５２）。次いで、ライブラリサーバ２ｇに接続できたか否かを判定し（ステップＳ５３）、ライブラリサーバ２ｇに接続できた場合（ステップＳ５３：Ｙｅｓ）には、ステップＳ５１にて決定した削除コンテンツデータがライブラリサーバ２ｇ内に記憶されているか否かをライブラリサーバ２ｇに問い合わせる（ステップＳ５４）。削除コンテンツデータがライブラリサーバ２ｇ内に記憶されていない場合には、当該ライブラリサーバ２ｇから、削除コンテンツデータの送信（アップロード）指示がされることとなる。一方、ライブラリサーバ２ｇに接続できなれば（ステップＳ５５：Ｎｏ）、ステップＳ５２に移行して、ライブラリサーバ２ｇに接続できるまで、ライブラリサーバ２ｇへの接続を試みる。

そして、ライブラリサーバ２ｇから、削除コンテンツデータのアップロード指示（送信指示）がされたか否かを判定し（ステップＳ５５）、削除コンテンツデータのアップロード指示がされていない場合（ステップＳ５５：Ｎｏ）には、ステップＳ５７へ移行し、削除コンテンツデータのアップロード指示がされた場合（ステップＳ５５：Ｙｅｓ）には、削除コンテンツデータをライブラリサーバ２ｇにアップロード（送信）する（ステップＳ５６）。なお、本実施形態では、ライブラリサーバ２ｇに削除コンテンツデータを送信する際には、自己の公開鍵にて該コンテンツを復号化した後にライブラリサーバ２ｇに送信するよう構成する。

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

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

先ず、制御部１１は、ログサーバ２ｅに接続（アクセス）する（ステップＳ６１）。次いで、ログサーバ２ｅに接続できたか否かを判定し（ステップＳ６２）、ログサーバ２ｅに接続できなれば（ステップＳ６２：Ｎｏ）、ステップＳ６１に移行して、ログサーバ２ｅに接続できるまで、ログサーバ２ｅへの接続を試みる。

一方、ログサーバ２ｅに接続できた場合（ステップＳ６２：Ｙｅｓ）には、コンテンツ視聴ログをログサーバ２ｅへ送信し（ステップＳ６３）、送信できたか否かを判定し（ステップＳ６４）、ログサーバ２ｅにコンテンツ視聴ログを送信できれば（ステップＳ６４：Ｙｅｓ）、処理を終了し、送信できなれば（ステップＳ６４：Ｎｏ）、ステップＳ６３に移行して、送信できるまで、ログサーバ２ｅへの送信を試みる。

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

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

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

そして、送出されたコンテンツ所在問合せ（検索）メッセージは、図４（Ｂ）を用いて説明したように、幾つかの中継ノードを経由され、上記コンテンツＩＤのルートノードに辿り着く。

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

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

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

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

なお、過去に公開鍵を取得したことがある場合には、ステップＳ７４の処理を行なわなくてもよい。例えば、表２のユーザ情報にかかる公開鍵送信実績と表３の利用実績を比較して説明すると、ノードＩＤ「００２」のノードｎｎは、表２の公開鍵送信実績によれば、コンテンツＩＤ「１１２」のコンテンツを復号化するために、公開鍵を登録サーバ２ｄに１回送信してもらっている。そして、表３の利用実績によれば、該ノードＩＤ「００２」のノードは、コンテンツＩＤ「１１２」のコンテンツを４回利用していることがわかる。これは例えば、ノードＩＤ「００２」のノードがコンテンツＩＤ「１１２」のコンテンツを検索し、取得した経験があるが、その都度コンテンツデータ自体は記憶部１２から消去しているが、該コンテンツデータの保存元のノードｎｎ（コンテンツ保持ノード）の公開鍵だけは記憶しておいたため、コンテンツデータのみを何度も（表３の例では４回）取得しているのである。

一方、公開鍵を取得できた場合（ステップＳ７４：Ｙｅｓ）には、制御部１１は番組情報要求手段として機能し、各コンテンツ保持ノードｎｎにコンテンツデータの配信を要求する（ステップＳ７５）。そして、コンテンツデータを受信したか否かを判定し（ステップＳ７６）、コンテンツデータを受信できなれば（ステップＳ７６：Ｎｏ）、ステップＳ７５に移行して、コンテンツデータを受信するまでコンテンツデータの配信を要求する。

ステップＳ７２において、コンテンツデータを発見できなかった場合（ステップＳ７２：Ｎｏ）、すなわち、ステップＳ７１にて送出した各コンテンツ所在問合せメッセージのうち、コンテンツ保持ノードｎｎのノード情報を１つも得られなかったコンテンツ所在問合せメッセージがある場合には、当該コンテンツ所在問合せメッセージにかかるコンテンツデータの配信を、ライブラリサーバ２ｇに要求する（ステップＳ７７）。例えば、ステップＳ７１にて２つのコンテンツデータに係る２つのコンテンツ所在問合せメッセージを送出した場合、一方のコンテンツデータにかかるコンテンツ保持ノードｎｎのノード情報はルートノードから得られたが、他方のコンテンツデータにかかるコンテンツ保持ノードｎｎのノード情報はルートノードから得られなかった場合には、当該他方のコンテンツデータについてのみ、ライブラリサーバ２ｇに要求する。ライブラリサーバ２ｇの負荷軽減のためにも、コンテンツ保持ノードｎｎのノード情報が得られたものは、コンテンツ保持ノードｎｎに対して配信要求を行ない、できる限り他のノードｎｎから取得するよう構成することが好ましい。

そして、ライブラリサーバ２ｇからコンテンツデータを受信したか否かを判定し（ステップＳ７８）、コンテンツデータを受信できなれば（ステップＳ７８：Ｎｏ）、ステップＳ７７に移行して、コンテンツデータを受信するまでライブラリサーバ２ｇにコンテンツデータの配信を要求する。

続いて、制御部１１は番組情報取得手段として機能して、ステップＳ７６、Ｓ７８にてコンテンツデータを受信（取得）すると（ステップＳ７６：Ｙｅｓ、Ｓ７８：Ｙｅｓ）、当該受信（取得）したコンテンツデータを記憶部１２に記憶して、コンテンツ視聴ログを記録する（ステップＳ７９）。コンテンツ視聴ログは、定期的にログサーバ２ｅに送信するもので（上記ステップＳ６，７参照）、コンテンツデータの受信の都度、コンテンツ視聴回数、視聴日時等をコンテンツＩＤに対応付けて記録する。

そして、コンテンツデータを再生して（ステップＳ８０）、処理を終了する。なお、コンテンツ保持ノードｎｎから受信（取得）（Ｓ７６）したコンテンツデータについては、暗号化された状態で取得されているため、制御部１１は復号化手段として機能し、ステップＳ７３で登録サーバ２ｄから取得したコンテンツ保持ノードの公開鍵を用いてデコーダ部１４にて復号化しながら再生処理を行なう。

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

［２−２.登録サーバ２ｄの処理］
図１７は、登録サーバ２ｄの制御部２１における処理を示すフローチャートである。なお、ここでは、登録サーバ２ｄが、各ノードｎｎに対して記録担当番組を割り当てる場合について説明する。図１７に示す処理は登録サーバ２ｄの電源がオンとされることにより、本発明のサーバ処理プログラムが制御部２１の制御に基づいて実行される。

先ず、電源がオフとされたか否かを判定し（ステップＳ８１）、オフとされていない場合（ステップＳ８１：Ｎｏ）には、ステップＳ８２以下の処理へ移行する。

そして、制御部２１は、コンテンツ配信システムＳに未参加の新たなノードｎｎから登録要求を受けたか否かを判定し（ステップＳ８２）、登録要求を受けていない場合（ステップＳ８２：Ｎｏ）には、ステップＳ８６へ移行し、登録要求を受けた場合（ステップＳ８２：Ｙｅｓ）には、当該ノードｎｎからユーザ情報を受信して、ユーザ情報データベース２２ａに登録する（ステップＳ８３）。

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

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

続いて、ノードｎｎから、公開鍵の要求がされたか否かを判定する（ステップＳ８６）。判定の結果、公開鍵の要求がされていない場合（ステップＳ８６：Ｎｏ）には、ステップＳ８１に移行し、公開鍵の要求がされた場合（ステップＳ８６：Ｙｅｓ）には、要求元のノードｎｎが正式にコンテンツ配信システムＳに登録された登録済みのノードｎｎであるか否かを判定する（ステップＳ８７）。具体的には、要求元のノードｎｎのノードＩＤを受信して、当該ノードＩＤがユーザ情報データベース２２ａに登録されているか否かに基づいて判定する。このとき、ノードＩＤだけでなく、該ノードＩＤと対応付けられたユーザ情報の任意の情報（例えば、電話番号等）を要求元のノードｎｎにて入力、送信するよう促し、当該送信された情報とユーザ情報データベース２２ａに登録されている情報とを照合して登録済みか否かを判定するよう構成してもよい。

そして、登録済みのノードｎｎである場合（ステップＳ８７：Ｙｅｓ）には、制御部２１は復号化鍵送信手段として機能し、要求されているコンテンツ保持ノードのノードＩＤに対応付けられた公開鍵をユーザ情報データベース２２ａから取得して、要求元のノードｎｎに送信し、要求元のノードｎｎのユーザ情報に、当該公開鍵を送信した旨を、該要求元のノードｎｎのノードＩＤに対応付けて記録し（ステップＳ８８）、ステップＳ８１に移行する。このとき、要求元のノードｎｎが取得（再生）を所望しているコンテンツのコンテンツＩＤに対応付けて公開鍵送信実績を記録する。表２を参照して具体的に説明すると、例えば、ノードＩＤ「１０３」のノードｎｎが、コンテンツＩＤ「１２１」のコンテンツの取得（再生）を所望して、該コンテンツＩＤ「１２１」のコンテンツデータを保存するコンテンツ保持ノードであるノードＩＤ「１２０」の公開鍵を要求した場合には、登録サーバ２ｄは、ユーザ情報データベース２２ａからノードＩＤ「１２０」の公開鍵（120）を取得してノードＩＤ「１０３」のノードｎｎに送信し、ノードＩＤ「１０３」に対応付けられた公開鍵送信実績のコンテンツＩＤ「１０１」の回数を１加算して更新することとなる。

一方、登録済みのノードｎｎでない場合（ステップＳ８７：Ｎｏ）には、正規登録者でないため公開鍵を送信できない旨のエラーメッセージを送信し（ステップＳ８９）、ステップＳ８１に移行する。

そして、電源がオフとされる（ステップＳ８１：Ｙｅｓ）まで、上記ステップＳ８１〜Ｓ８９の処理が繰り返し行なわれる。

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

［２−３.ログサーバ２ｅの処理］
図１８は、ログサーバ２ｅの制御部３１における処理を示すフローチャートである。図１８に示す処理はログサーバ２ｅの電源がオンとされることにより、本発明のサーバ処理プログラムが制御部３１の制御に基づいて実行される。

先ず、電源がオフとされたか否かを判定し（ステップＳ９１）、オフとされていない場合（ステップＳ９１：Ｎｏ）には、ステップＳ９２以下の処理へ移行する。

そして、制御部３１は、ノードｎｎから接続要求を受けたか否かを判定し（ステップＳ９２）、接続要求を受けていない場合（ステップＳ９２：Ｎｏ）には、ステップＳ９６へ移行し、接続要求を受けた場合（ステップＳ９２：Ｙｅｓ）には、該ノードｎｎからコンテンツ視聴ログを受信して、システム利用実績を記録する（表３、表４参照）。そして、該ノードｎｎの利用実績（表３参照）を決済サーバ２ｆに送信（報告）する（ステップＳ９６）。この後、決済サーバ２ｆでは、利用実績に基づいてノードｎｎのユーザに対して所定額の利用料金を課する課金処理を行なうこととなる。そして、コンテンツ配信システムＳへの登録時と同様に、例えばユーザの銀行口座から当該利用料金が引き落とされ、予め定められた基準にしたがって番組制作者や放送局側の著作者等に対して支払われることになる。

続いて、制御部３１は、登録サーバ２ｄから接続要求を受けたか否かを判定し（ステップＳ９６）、接続要求を受けていない場合（ステップＳ９６：Ｎｏ）には、ステップＳ９１へ移行し、接続要求を受けた場合（ステップＳ９６：Ｙｅｓ）には、コンテンツの利用実績（表４参照）を登録サーバ２ｄに送信して（ステップＳ９７）、ステップＳ９１へ移行する。

そして、電源がオフとされる（ステップＳ９１：Ｙｅｓ）まで、上記ステップＳ９１〜Ｓ９７の処理が繰り返し行なわれる。

［２−４.ライブラリサーバ２ｇの処理］
図１９は、ライブラリサーバ２ｇの制御部５１における処理を示すフローチャートである。図１９に示す処理はライブラリサーバ２ｇの電源がオンとされることにより、本発明のサーバ処理プログラムが制御部５１の制御に基づいて実行される。

先ず、電源がオフとされたか否かを判定し（ステップＳ１０１）、オフとされていない場合（ステップＳ１０１：Ｎｏ）には、ステップＳ１０２以下の処理へ移行する。

そして、制御部５１は、ノードｎｎからコンテンツＩＤを受信してコンテンツデータ有無の問合せがされたか否かを判定する（ステップＳ１０２）。この問い合わせは、上述したノードｎｎにおける削除処理（ステップＳ５、Ｓ５４）の処理に呼応する処理である。

判定の結果、コンテンツデータ有無の問合せがされていない場合（ステップＳ１０２：Ｎｏ）には、ステップＳ１０８に移行し、コンテンツデータ有無の問合せがされた場合（ステップＳ１０２：Ｙｅｓ）には、問い合わされたコンテンツデータを記憶しているか否かを判定する（ステップＳ１０３）。記憶している場合には、該コンテンツＩＤにかかるコンテンツのアップロード（送信）は不要である旨を返信し（ステップＳ１０４）、ステップＳ１０８に移行する。一方、問い合わされたコンテンツデータを記憶していない場合（ステップＳ１０３：Ｎｏ）には、該コンテンツＩＤにかかるコンテンツのアップロード（送信）を指示する（ステップＳ１０５）。

そして、コンテンツのアップロードが確実に行なわれたか否かを判定し（ステップＳ１０６）、コンテンツのアップロード（送信）が確実に行なわれなかった場合（ステップＳ１０６：Ｎｏ）には、ステップＳ１０５に移行して、コンテンツのアップロード（送信）が完了するまで監視し指示をし続ける。コンテンツのアップロードが確実に行なわれると（ステップＳ１０６：Ｙｅｓ）、アップロードされたコンテンツデータを記憶部５２にコンテンツＩＤに対応付けて保存する（ステップＳ１０７）。なお、本実施形態ではライブラリサーバ２ｇに保存されるコンテンツは、暗号化されていないコンテンツデータであるものとする。従って、ライブラリサーバ２ｇは、各ノードｎｎから、当該ノードｎｎの公開鍵（つまりコンテンツ保持ノードの公開鍵）にて復号化されたコンテンツデータを受信することとなる。この他、例えば、各ノードｎｎから暗号化されたコンテンツデータを受信し、該ノードｎｎの公開鍵を、登録サーバ２ｄから取得して復号化した後に記憶部５２に保存するよう構成することもできる。

続いて、ノードｎｎからコンテンツデータの配信要求があったか否かを判定し（ステップＳ１０８）、配信要求がされていない場合（ステップＳ１０８：Ｎｏ）には、ステップＳ１０１に移行し、配信要求がされた場合（ステップＳ１０８：Ｙｅｓ）には、要求元のノードｎｎが正式にコンテンツ配信システムＳに登録された登録済みのノードｎｎであるか否かを判定する（ステップＳ１０９）。具体的には、要求元のノードｎｎのノードＩＤを登録サーバ２ｄに送信して、当該ノードＩＤがのユーザ情報データベース２２ａに登録されているか否かを登録サーバ２ｄに問い合わせて判定する。

そして、登録済みのノードｎｎである場合（ステップＳ１０９：Ｙｅｓ）には、要求されているコンテンツデータを、該要求元のノードｎｎに配信して（ステップＳ１１０）、ステップＳ１０１の処理に移行する。一方、登録済みのノードｎｎでない場合（ステップＳ１０９：Ｎｏ）には、正規登録者でないため公開鍵を送信できない旨のエラーメッセージを送信し（ステップＳ１１１）、ステップＳ１０１に移行する。

そして、電源がオフとされる（ステップＳ１０１：Ｙｅｓ）まで、上記ステップＳ１０１〜Ｓ１１１の処理が繰り返し行なわれる。

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

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

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

また、登録サーバ２ｄが、各ノードｎｎが記録すべき番組を示す記録担当情報を決定し、各ノードｎｎに指示するため、各放送局２ａ〜２ｃから放送される番組を各ノードｎｎに対して、偏り無く記録担当として割り振ることができる。

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

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

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

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

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

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

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

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

更に、上記実施形態では、決済サーバ２ｆは、ログサーバ２ｅから各ノードｎｎの利用実績（表３）の報告を受け（Ｓ９６）、該利用実績に基づいて課金処理を行なうよう構成したが、登録サーバ２ｄにて記録される各ノードｎｎに公開鍵を送信した回数（公開鍵送信実績（表２））を利用して課金処理を行なったり（課金処理手段）、ログサーバ２ｅから報告された利用実績に基づいて課金処理を行なう際に、登録サーバ２ｄの公開鍵送信実績と照合することにより、誤った決済処理が行なわれないよう担保するよう構成してもよい。

また、上記実施形態では、複数のサーバを本発明のサーバ装置として機能させたが、ログサーバ２ｅにて行なわれるログの収集、管理処理、決済サーバ２ｆにて行なわれる決済処理、ライブラリサーバ２ｇにて行なわれる過去に放送されたコンテンツデータ（ノードｎｎにて削除されたコンテンツデータ）の記録保存処理を、全て登録サーバ２ｄにて行なうことし、当該登録サーバ２ｄを本発明のサーバ装置として機能させてもよい。

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

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

本実施形態に係るコンテンツ配信システムにおける各ノード装置の接続態様の一例を示す図である。 ノードｎ１が保持するＤＨＴのルーティングテーブルの一例を示す図である。 ＤＨＴのノードＩＤ空間の一例を示す概念図である。 （Ａ）コンテンツ保持ノードから送出されたパブリッシュメッセージの流れの一例を、ＤＨＴのノードＩＤ空間にて示した概念図である。（Ｂ）ユーザノードから送出されたコンテンツ所在問合せメッセージとコンテンツデータ取得の流れの一例を、ＤＨＴのノードＩＤ空間にて示した概念図である。 ノードｎｎの概要構成例を示す図である。 登録サーバ２ｄの概要構成例を示す図である。 ログサーバ２ｅの概要構成例を示す図である。 決済サーバ２ｆの概要構成例を示す図である。 ライブラリサーバ２ｇの概要構成例を示す図である。 本実施形態に係るノードｎｎの制御部１１における処理を示すフローチャートである。 ノードｎｎにおける「登録処理」を示すフローチャートである。 ノードｎｎにおける「登録処理」を示すフローチャートである。 ノードｎｎにおける「録画処理」を示すフローチャートである。 ノードｎｎにおける「削除処理」を示すフローチャートである。 ノードｎｎにおける「ログ送信処理」を示すフローチャートである。 ノードｎｎにおける「再生処理」を示すフローチャートである。 本実施形態に係る登録サーバ２ｄの制御部２１における処理を示すフローチャートである。 本実施形態に係るログサーバ２ｅの制御部３１における処理を示すフローチャートである。 本実施形態に係るライブラリサーバ２ｇの制御部５１における処理を示すフローチャートである。

符号の説明

ｎｎ ノード
２ａ、２ｂ、２ｃ 放送局
２ｄ 登録サーバ
２ｅ ログサーバ
２ｆ 決済サーバ
２ｇ ライブラリサーバ
８ ネットワーク
９ オーバーレイネットワーク
１１ 制御部
１２ 記憶部
１３ バッファメモリ
１４ デコーダ部
１５ 映像処理部
１６ 表示部
１７ 音声処理部
１８ スピーカ
１９ エンコーダ部
１９ａ 通信部
１９ｂ 受信部
１９ｃ 入力部
１９ｄ バス
２１ 制御部
２２ 記憶部
２２ａ ユーザ情報データベース
２３ 通信部
２４ バス
３１、４１、５１ 制御部
３２、４２、５２ 記憶部
３３、４３、５３ 通信部
３４、４４、５４ バス
Ｓ コンテンツ配信システム

Claims (15)

1. ネットワークを介して互いに通信可能な複数のノード装置と、番組情報を放送する少なくとも一以上の放送局と、を備えた情報配信システムに含まれる前記ノード装置であって、
   各前記放送局から放送された番組情報を受信する番組情報受信手段と、
   前記受信した番組情報のうち、記録担当分として割り当てられた番組情報を、当該番組情報に固有の識別情報と対応付けて、前記複数のノード装置間で共用可能に保存する番組情報保存手段と、
   を有することを特徴とするノード装置。
2. 請求項1に記載のノード装置であって、
   前記複数のノード装置間で共用可能とすべく、前記保存された番組情報に固有の前記識別情報を含む公開メッセージを、当該番組情報の所在を管理するノード装置へ向けて送出する公開メッセージ送出手段と、
   他の前記ノード装置から保存した前記番組情報の要求を受けると、要求された番組情報を要求元の前記他のノード装置へ送信する番組情報送信手段と、
   を有することを特徴とするノード装置。
3. 請求項２に記載のノード装置であって、
   当該ノード装置に固有の暗号化鍵を記憶する暗号化鍵記憶手段と、
   前記受信した番組情報のうち、記録担当分として割り当てられた番組情報を、前記記憶された暗号化鍵を用いて暗号化する暗号化手段と、を有し、
   前記番組情報保存手段は、暗号化した前記番組情報を前記識別情報と対応付けて保存し、
   前記番組情報送信手段は、前記暗号化された番組情報を要求元の前記他のノード装置へ送信することを特徴とするノード装置。
4. 請求項１乃至３のいずれか一項に記載のノード装置であって、
   前記情報配信システムに参加する際に、当該情報配信システムに含まれるサーバ装置に対して、参加登録を行なう参加登録手段と、
   前記サーバ装置から、自己が記録すべき記録担当分の番組情報に係る情報を示す記録担当情報を取得する記録担当情報取得手段と、を有し、
   前記番組情報保存手段は、前記受信した番組情報のうち、前記記録担当情報に基づいて記録担当分として割り当てられた番組情報を保存することを特徴とするノード装置。
5. 請求項４に記載のノード装置であって、
   前記参加登録手段は、前記サーバ装置に対して、当該ノード装置が設置される地域を示す地域情報を送信して参加登録を行ない、
   前記記録担当情報取得手段は、前記サーバ装置から、前記地域情報に基づいて決定された前記記録担当情報を取得することを特徴とするノード装置。
6. 請求項４又は５に記載のノード装置であって、
   前記参加登録手段は、前記暗号化鍵によって暗号化された情報を復号化するための復号化鍵を、前記サーバ装置に送信する復号化鍵送信手段を有することを特徴とするノード装置。
7. 請求項６に記載のノード装置であって、
   過去に何れかの前記放送局から放送された前記番組情報の取得を望む場合には、当該番組情報に固有の前記識別情報を含む検索メッセージを、当該番組情報の所在を管理するノード装置へ向けて送出する検索メッセージ送出手段と、
   前記番組情報の所在を管理するノード装置から、当該番組情報を記録しているノード装置を示すノード情報を取得するノード情報取得手段と、
   前記ノード情報に基づいて、前記番組情報を記録しているノード装置に対して当該番組情報の送信を要求する番組情報要求手段と、
   前記番組情報を記録しているノード装置から、前記番組情報要求手段にて要求した番組情報であって、暗号化された前記番組情報を取得する番組情報取得手段と、
   前記暗号化された番組情報を復号化するための前記復号化鍵を要求すべく復号化鍵要求情報を前記サーバ装置に送信する復号化鍵要求情報送信手段と、
   前記復号化鍵を前記サーバ装置から取得する復号化鍵取得手段と、
   前記取得した復号化鍵を用いて、前記暗号化された番組情報を復号化する復号化手段と、
   を有することを特徴とするノード装置。
8. 請求項１乃至７のいずれか一項に記載のノード装置であって、
   記録担当分として割り当てられた番組情報の受信強度を測定し、該受信強度が所定閾値に達しているか否かを判定する受信強度判定手段と、
   判定の結果、受信強度が所定閾値に達していない場合には、該番組情報を放送している前記放送局を除く他の前記放送局から放送される番組情報を新たな記録担当の番組情報として更新する記録担当番組更新手段と、
   を有することを特徴とするノード装置。
9. コンピュータを、請求項１乃至８の何れか一項に記載のノード装置として機能させることを特徴とする処理プログラム。
10. ネットワークを介して互いに通信可能な複数のノード装置と、番組情報を放送する少なくとも一以上の放送局と、前記複数のノード装置の参加登録を管理するサーバ装置と、を備えた情報配信システムであって、
    各前記ノード装置は、
    各前記放送局から放送された番組情報を受信する番組情報受信手段と、
    前記サーバ装置に対して、参加登録を行なう参加登録手段と、
    前記サーバ装置から、自己が記録すべき記録担当分の番組情報に係る情報を取得する記録担当情報を取得する記録担当情報取得手段と、
    前記受信した番組情報のうち、前記記録担当情報に基づいて、記録担当分として割り当てられた番組情報を、当該番組情報に固有の識別情報と対応付けて、前記複数のノード装置間で共用可能に保存する番組情報保存手段と、を有し、
    前記サーバ装置は、
    前記ノード装置から参加登録を受けると、当該ノード装置が記録担当となるべき番組情報に係る情報を示す前記記録担当情報を決定する記録担当情報決定手段と、
    前記決定された記録担当情報を前記ノード装置に送信する記録担当情報送信手段と、
    を有することを特徴とする情報配信システム。
11. 請求項１０に記載の情報配信システムであって、
    前記ノード装置の前記参加登録手段は、前記サーバ装置に対して、当該ノード装置が設置される地域を示す地域情報を送信して参加登録を行ない、
    前記サーバ装置の前記記録担当情報決定手段は、前記ノード装置から前記地域情報を受信して参加登録を受けると、前記記録担当情報を前記地域情報に基づいて決定することを特徴とする情報配信システム。
12. 請求項１０又は１１に記載の情報配信システムであって、
    各前記ノード装置は、
    当該ノード装置に固有の暗号化鍵を記憶する暗号化鍵記憶手段と、
    前記受信した番組情報のうち、記録担当分として割り当てられた番組情報を、前記記憶された暗号化鍵を用いて暗号化する暗号化手段と、を有し、かつ、
    前記番組情報保存手段は、暗号化した前記番組情報を前記識別情報と対応付けて保存し、かつ、
    前記複数のノード装置間で共用可能とすべく、前記保存された番組情報に固有の前記識別情報を含む公開メッセージを、当該番組情報の所在を管理するノード装置へ向けて送出する公開メッセージ送出手段と、
    他の前記ノード装置から保存した前記番組情報の要求を受けると、前記要求された番組情報であって、暗号化された番組情報を要求元の前記他のノード装置へ送信する番組情報送信手段と、を有し、更に、
    前記参加登録手段は、前記暗号化鍵によって暗号化された情報を復号化するための復号化鍵を、前記サーバ装置に送信する復号化鍵送信手段を有し、
    前記サーバ装置は、
    前記ノード装置から、当該ノード装置を示すノード情報と前記復号化鍵を受信すると、当該ノード情報と当該復号化鍵を対応付けて記憶する復号化鍵記憶手段と、
    何れかの前記ノード装置から、前記番組情報を復号化するための前記復号化鍵を要求する復号化鍵要求情報を受信すると、受信した前記復号化鍵要求情報に含まれる前記ノード情報と対応付けて前記復号化鍵記憶手段に記憶された復号化鍵を、当該復号化鍵の要求元のノード装置に送信する復号化鍵送信手段と、を有し、
    前記番組情報の取得を望むノード装置は、
    当該番組情報に固有の前記識別情報を含む検索メッセージを、当該番組情報の所在を管理するノード装置へ向けて送出する検索メッセージ送出手段と、
    前記番組情報の所在を管理するノード装置から、当該番組情報を記録しているノード装置を示すノード情報を取得するノード情報取得手段と、
    前記取得したノード情報に基づいて、前記番組情報を記録しているノード装置に対して当該番組情報の送信を要求する番組情報要求手段と、
    前記番組情報を記録しているノード装置から、前記番組情報要求手段にて要求した番組情報であって、暗号化された前記番組情報を取得する番組情報取得手段と、
    前記暗号化された番組情報を復号化するための前記復号化鍵を要求すべく、前記番組情報を記録しているノード装置を示す前記ノード情報を含む前記復号化鍵要求情報を前記サーバ装置に送信する復号化鍵要求情報送信手段と、
    前記復号化鍵を前記サーバ装置から取得する復号化鍵取得手段と、
    前記取得した復号化鍵を用いて、前記暗号化された番組情報を復号化する復号化手段と、
    を有することを特徴とする情報配信システム。
13. 請求項１０乃至１２のいずれか一項に記載の情報配信システムにおいて、
    前記サーバ装置は、
    前記各ノード装置の使用者毎の使用者情報を記憶、管理する使用者情報管理手段と、
    前記復号化鍵要求情報を送信したノード装置の使用者に対して課金処理を行なう課金処理手段と、
    を有することを特徴とする情報配信システム。
14. 請求項１０乃至１３のいずれか一項に記載の情報配信システムにおいて、
    全ての前記放送局から放送された全ての前記番組情報が、前記複数のノード装置で分担され、何れかの前記ノード装置にて保存されることを特徴とする情報配信システム。
15. １又は複数のコンピュータを、請求項１０乃至１４の何れか一項に記載のサーバ装置として機能させることを特徴とするサーバ処理プログラム。

Images