(57)【要約】【課題】全体としての消費電力を低下させることが可能な配信システムを提供する。【解決手段】ルートノードＲＮ又はキャッシュノードＣＮにリクエスタＲＱから参照可能に記録されたインデックス情報ＥＸＸ内に、コンテンツＩＤ及びコンテンツホルダＣＨのＩＰアドレスに加えて、当該コンテンツホルダＣＨからのコンテンツ配信の終了予測時刻を示す終了予測時刻情報１０１を含む補助情報ＨＰを追加する。リクエスタＲＱに対する返信においては、終了予測時刻が最も遅いコンテンツホルダＣＨに対応するインデックス情報ＥＸＸを返信する。【選択図】図３
2009094856.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して複数の情報処理装置が接続されてなり、配信情報が配信されるネットワークシステムにおいて、
配信用の前記配信情報を蓄積する蓄積装置の所在を示す所在情報であって、当該所在情報により前記所在が示される前記蓄積装置から配信中の前記配信情報の当該配信が完了する予定時刻である配信完了予定時刻を示す配信完了予定時刻情報を含む所在情報を記憶する記憶手段と、
前記記憶されている所在情報に基づき、前記配信情報の配信中であって且つ前記配信完了予定時刻が最も遅い前記蓄積装置から、現在進行中の当該配信情報の配信と並行して、次に配信が所望されている他の前記配信情報を配信させる配信元制御手段と、
を備えることを特徴とするネットワークシステム。
【請求項２】
請求項１に記載のネットワークシステムにおいて、
前記所在情報には、当該所在情報により前記所在が示される前記蓄積装置から追加して並行配信可能な前記配信情報の数を示す配信可能数情報が更に含まれており、
前記配信完了予定時刻が最も遅い前記蓄積装置が複数存在するとき、前記配信元制御手段は、前記配信可能数情報に基づいて、当該複数の蓄積装置の中から当該配信可能数情報により示される前記配信情報の数が最も多い前記蓄積装置から、次に配信が所望されている他の前記配信情報を配信させることを特徴とするネットワークシステム。
【請求項３】
ネットワークを介して複数の情報処理装置が接続されてなり、配信情報が配信されるネットワークシステムに含まれる前記情報処理装置において、
配信用の前記配信情報を蓄積する蓄積装置の所在を示す所在情報であって、当該所在情報に対応する前記蓄積装置から配信中の前記配信情報の当該配信が完了する予定時刻である配信完了予定時刻を示す配信完了予定時刻情報を含む所在情報を記憶する記憶手段と、
配信を要求する前記配信情報を蓄積した前記蓄積装置に対応する前記所在情報を要求する所在要求情報を受信する受信手段と、
前記受信した所在要求情報により前記配信が要求されている前記配信情報を蓄積している前記蓄積装置の所在を示す前記所在情報を、前記記憶手段内において検索する検索手段と、
前記検索された所在情報を、前記所在要求情報を送信して来た所在情報要求装置に送信するに当たり、前記配信情報の配信中であって且つ対応する前記配信完了予定時刻が最も遅い前記蓄積装置に対応する前記所在情報を当該所在情報要求装置に送信する所在情報送信手段と、
を備えることを特徴とする情報処理装置。
【請求項４】
ネットワークを介して複数の情報処理装置が接続されてなり、配信情報が配信されるネットワークシステムに含まる前記情報処理装置において、
前記配信情報を蓄積した蓄積装置の所在を示す所在情報を要求する所在要求情報を送信する送信手段と、
前記送信された所在要求情報に対応した前記所在情報であって、当該所在情報が対応する前記蓄積装置における配信中の前記配信情報の配信が完了する予定時刻である配信完了予定時刻を示す配信完了予定時刻情報を含む所在情報を受信する受信手段と、
前記受信した所在情報に対応する前記蓄積装置から、前記配信情報の配信元となる前記蓄積装置を指定する配信元制御手段と、
前記配信元制御手段により指定された前記蓄積装置から当該配信情報を取得する取得手段と、
を備え、
前記受信した所在情報に対応する前記蓄積装置のいずれかを前記配信情報の配信元に指定するに当たり、前記配信元制御手段は、他の前記配信情報の配信中であって且つ対応する前記配信完了予定時刻が最も遅い前記蓄積装置を指定することを特徴とする情報処理装置。
【請求項５】
ネットワークを介して複数の情報処理装置が接続されてなり、配信情報が配信されるネットワークシステムにおいて実行される情報処理方法において、
配信用の前記配信情報を蓄積する蓄積装置の所在を示す所在情報であって、当該所在情報により前記所在が示される前記蓄積装置から配信中の前記配信情報の当該配信が完了する予定時刻である配信完了予定時刻を示す配信完了予定時刻情報を含む所在情報を記憶手段に記憶させる記憶工程と、
前記記憶されている所在情報に基づき、前記配信情報の配信中であって且つ前記配信完了予定時刻が最も遅い前記蓄積装置から、現在進行中の当該配信情報の配信と並行して、次に配信が所望されている他の前記配信情報を配信させる配信元制御工程と、
を含むことを特徴とする情報処理方法。
【請求項６】
コンピュータを、請求項３又は４に記載の情報処理装置として機能させることを特徴とする情報処理用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークシステム、情報処理装置及び情報処理方法並びに情報処理用プログラムの技術分野に属し、より詳細には、ネットワークを介して配信されるべき映画等のコンテンツ（配信情報）を、当該配信用に蓄積する蓄積装置及び当該蓄積装置からの当該配信情報の配信等を行う情報処理装置及び当該情報処理装置における情報処理方法並びに当該情報処理用プログラムの技術分野に属する。
【背景技術】
【０００２】
近年、インターネット等のネットワーク技術は著しく進歩しつつあり、その中で、例えば下記特許文献１に開示されている如きコンテンツ配信システムに関する研究が行われている。
【０００３】
ここで、当該コンテンツ配信システムにおいて、例えば映画等のコンテンツは、その製作者又は管理者（当該製作者又は管理者を、以下単に管理者等と称する）により当該コンテンツ配信システム内のいずれかのコンテンツノードに対してネットワークを介して最初に配信され、当該各コンテンツノードにおいて蓄積／記憶される。なお、上記管理者等によりコンテンツ配信システム内に最初にコンテンツが配信されることを、以下、「コンテンツの投入」と称する。
【０００４】
そして、当該投入されたコンテンツをコンテンツ配信システム内において配信する場合には、当該コンテンツに相当する動画情報等を蓄積／記憶している上記コンテンツノードから、当該コンテンツの視聴を希望する者により操作されるリクエストノードに対して当該動画情報等が配信（伝送）される。
【０００５】
なお、当該「コンテンツノード」の定義付けについては、例えば下記特許文献１の明細書段落番号［００７１］を参照することができ、また当該「リクエストノード」の定義付けについては、例えば下記特許文献１の明細書段落番号［００６４］及び［００６５］を参照することができる。
【０００６】
また、上記コンテンツ配信システムにおいては、一旦投入されたコンテンツは、初期投入の後、最初に投入先となったコンテンツノードだけではなく、例えば分散ハッシュテーブル（いわゆるＤＨＴ（Distributed Hash Table））アルゴリズムに則って他のノード内にそのコンテンツの複製（レプリカ）が作成される。そして、当該レプリカが暫増的に作成されることで、最初に投入されたコンテンツノード以外にも、同一のコンテンツを蓄積／記憶するコンテンツノードがコンテンツ配信システム内に複数存在することとなる。これにより、配信元の分散が実現され、リクエストノードへの配信の迅速化及び安定化が図られることとなる。
【０００７】
なお、上記レプリカが作成されたノードを、以下、適宜「レプリカノード」と称する。また、上記ＤＨＴアルゴリズムについては、例えば下記特許文献１の明細書段落番号［００３９］乃至［００７２］並びに図１乃至図５の記載を参照することができる。
【０００８】
ここで、下記特許文献１に記載された上記ＤＨＴアルゴリズムに用いられるＤＨＴ内においては、各コンテンツノード又はレプリカノードについて相対的な重み付けがされていることがなかったため、配信が所望されているコンテンツを蓄積しているコンテンツノード又はレプリカノードについては、各ノードがほぼ均等の機会でもってそのコンテンツの配信の用に供されることとなっていた。
【特許文献１】特開２００６−１９７４００公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、上述した特許文献１記載のコンテンツ配信システムでは、上述した如く配信が所望されるコンテンツを蓄積しているコンテンツノード又はレプリカノードの各々がほぼ均等にそのコンテンツの配信の用に供されることとなっていたため、コンテンツ配信システム全体としてみた場合に稼働しているコンテンツノード又はレプリカノードの数が増加することとなる。
【００１０】
この結果、多数のコンテンツノードやレプリカノードが一カ所に集められている例えば配信事業者等を想定する場合、その配信事業者等に係るコンテンツ配信システム全体としての消費電力が大きくなるという問題点があった。
【００１１】
そこで、本発明は、上記の各問題点に鑑みて為されたもので、その目的は、全体としての消費電力を低下させることが可能なコンテンツ配信システム、当該コンテンツ配信システムに含まれるノード、当該ノードにおける情報処理方法及び当該ノード用のプログラムを提供することにある。
【課題を解決するための手段】
【００１２】
上記の課題を解決するために、請求項１に記載の発明は、ネットワークを介して複数の情報処理装置が接続されてなり、配信情報が配信されるネットワークシステムにおいて、配信用の前記配信情報を蓄積する蓄積装置の所在を示す所在情報であって、当該所在情報により前記所在が示される前記蓄積装置から配信中の前記配信情報の当該配信が完了する予定時刻である配信完了予定時刻を示す配信完了予定時刻情報を含む所在情報を記憶する記憶部等の記憶手段と、前記記憶されている所在情報に基づき、前記配信情報の配信中であって且つ前記配信完了予定時刻が最も遅い前記蓄積装置から、現在進行中の当該配信情報の配信と並行して、次に配信が所望されている他の前記配信情報を配信させる制御部等の配信元制御手段と、を備える。
【００１３】
よって、配信情報を現在配信中であって且つその配信完了予定時刻が最も遅い蓄積装置から他の配信情報を配信させるので、現在配信中の蓄積装置から同時並行的に更に新たな配信を行わせることで、新たな蓄積装置において配信処理が開始されることに起因する消費電力の増大等を抑制することができる。
【００１４】
上記の課題を解決するために、請求項２に記載の発明は、請求項１に記載のネットワークシステムにおいて、前記所在情報には、当該所在情報により前記所在が示される前記蓄積装置から追加して並行配信可能な前記配信情報の数を示す配信可能数情報が更に含まれており、前記配信完了予定時刻が最も遅い前記蓄積装置が複数存在するとき、前記配信元制御手段は、前記配信可能数情報に基づいて、当該複数の蓄積装置の中から当該配信可能数情報により示される前記配信情報の数が最も多い前記蓄積装置から、次に配信が所望されている他の前記配信情報を配信させるように構成される。
【００１５】
よって、配信完了予定時刻が最も遅い蓄積装置が複数存在するとき、当該複数の蓄積装置の中から配信可能数情報により示される前記配信情報の数が最も多い蓄積装置から、次に配信が所望されている他の配信情報を配信させるので、新たな蓄積装置において配信処理が開始されることに起因する消費電力の増大等を更に抑制することができる。
【００１６】
上記の課題を解決するために、請求項３に記載の発明は、ネットワークを介して複数の情報処理装置が接続されてなり、配信情報が配信されるネットワークシステムに含まれる前記情報処理装置において、配信用の前記配信情報を蓄積する蓄積装置の所在を示す所在情報であって、当該所在情報に対応する前記蓄積装置から配信中の前記配信情報の当該配信が完了する予定時刻である配信完了予定時刻を示す配信完了予定時刻情報を含む所在情報を記憶する記憶部等の記憶手段と、配信を要求する前記配信情報を蓄積した前記蓄積装置に対応する前記所在情報を要求する所在要求情報を受信する通信部等の受信手段と、前記受信した所在要求情報により前記配信が要求されている前記配信情報を蓄積している前記蓄積装置の所在を示す前記所在情報を、前記記憶手段内において検索する制御部等の検索手段と、前記検索された所在情報を、前記所在要求情報を送信して来た所在情報要求装置に送信するに当たり、前記配信情報の配信中であって且つ対応する前記配信完了予定時刻が最も遅い前記蓄積装置に対応する前記所在情報を当該所在情報要求装置に送信する通信部等の所在情報送信手段と、を備える。
【００１７】
よって、次に配信情報の配信を受けるべき蓄積装置を示す所在情報を所在情報要求装置へ送信するに当たり、配信情報の配信中であって且つ配信完了予定時刻が最も遅い蓄積装置に対応する所在情報を送信するので、現在配信中の蓄積装置から同時並行的に更に新たな配信を受けることができる可能性が高くなることで、新たな蓄積装置において配信処理が開始されることに起因する消費電力の増大等を抑制することができる。
【００１８】
上記の課題を解決するために、請求項４に記載の発明は、ネットワークを介して複数の情報処理装置が接続されてなり、配信情報が配信されるネットワークシステムに含まる前記情報処理装置において、前記配信情報を蓄積した蓄積装置の所在を示す所在情報を要求する所在要求情報を送信する通信部等の送信手段と、前記送信された所在要求情報に対応した前記所在情報であって、当該所在情報が対応する前記蓄積装置における配信中の前記配信情報の配信が完了する予定時刻である配信完了予定時刻を示す配信完了予定時刻情報を含む所在情報を受信する通信部等の受信手段と、前記受信した所在情報に対応する前記蓄積装置から、前記配信情報の配信元となる前記蓄積装置を指定する制御部等の配信元制御手段と、前記配信元制御手段により指定された前記蓄積装置から当該配信情報を取得する制御部等の取得手段と、を備え、前記受信した所在情報に対応する前記蓄積装置のいずれかを前記配信情報の配信元に指定するに当たり、前記配信元制御手段は、他の前記配信情報の配信中であって且つ対応する前記配信完了予定時刻が最も遅い前記蓄積装置を指定するように構成される。
【００１９】
よって、次に配信情報の配信を受けるべき蓄積装置を指定するに当たり、他の配信情報の配信中であって且つ対応する配信完了予定時刻が最も遅い蓄積装置を指定するので、現在配信中の蓄積装置から同時並行的に更に新たな配信を受けることができる可能性が高くなることで、新たな蓄積装置において配信処理が開始されることに起因する消費電力の増大等を抑制することができる。
【００２０】
上記の課題を解決するために、請求項５に記載の発明は、ネットワークを介して複数の情報処理装置が接続されてなり、配信情報が配信されるネットワークシステムにおいて実行される情報処理方法において、配信用の前記配信情報を蓄積する蓄積装置の所在を示す所在情報であって、当該所在情報により前記所在が示される前記蓄積装置から配信中の前記配信情報の当該配信が完了する予定時刻である配信完了予定時刻を示す配信完了予定時刻情報を含む所在情報を記憶部等の記憶手段に記憶させる記憶工程と、前記記憶されている所在情報に基づき、前記配信情報の配信中であって且つ前記配信完了予定時刻が最も遅い前記蓄積装置から、現在進行中の当該配信情報の配信と並行して、次に配信が所望されている他の前記配信情報を配信させる配信元制御工程と、を含む。
【００２１】
よって、配信情報を現在配信中であって且つその配信完了予定時刻が最も遅い蓄積装置から他の配信情報を配信させるので、現在配信中の蓄積装置から同時並行的に更に新たな配信を行わせることで、新たな蓄積装置において配信処理が開始されることに起因する消費電力の増大等を抑制することができる。
【００２２】
上記の課題を解決するために、請求項６に記載の発明は、コンピュータを、請求項３又は４に記載の情報処理装置として機能させる。
【００２３】
よって、次に配信情報を配信する蓄積装置を指定するに当たり、他の配信情報の配信中であって且つ対応する配信完了予定時刻が最も遅い蓄積装置を指定するようにコンピュータが機能するので、現在配信中の蓄積装置から同時並行的に更に新たな配信を受けることができる可能性が高くなることで、新たな蓄積装置において配信処理が開始されることに起因する消費電力の増大等を抑制することができる。
【発明の効果】
【００２４】
本発明によれば、配信情報を現在配信中であって且つその配信完了予定時刻が最も遅い蓄積装置から他の配信情報を配信させるので、現在配信中の蓄積装置から同時並行的に更に新たな配信を行わせることで、新たな蓄積装置において配信処理が開始されることに起因する消費電力の増大等を抑制することができる。
【００２５】
従って、コンテンツ配信システム全体としての消費電力を低下させることが可能となる。
【発明を実施するための最良の形態】
【００２６】
次に、本発明を実施するための最良の形態について、図面に基づいて説明する。なお、以下に説明する実施形態は、インターネット等のネットワークを用いて上記コンテンツの配信を行う配信システムに対して本発明を適用した場合の実施の形態である。更に具体的には、当該ネットワークに属する端末装置間で、当該コンテンツが相互に直接授受される（換言すれば、コンテンツを複数の端末装置間で共有する）配信システム、すなわちいわゆるＰ２Ｐ（Pear to Pear）型の配信システムに対して本発明を適用した場合の実施の形態である。なお、以下の説明においては、上記端末装置を一般的に「ノード」と称することとする。
（Ｉ）本発明の原理
初めに、本発明の実施形態について具体的に説明する前に、本発明の原理につき、実施形態に係るＰ２Ｐ型配信システム（以下、単に配信システムと称する）の概要と共に説明する。
【００２７】
（Ａ）配信システムの概要
先ず、実施形態に係る配信システムの概要につき、図１及び図２を用いて一般的に説明する。なお、図１及び図２は当該配信システムの概要を示す模式図である。
【００２８】
上記特許文献１に記載されているＤＨＴを用いた配信システムでは、上記特許文献１にも一部記載されているが、その配信システムによって配信されるコンテンツ自体にも、他のコンテンツとは異なるユニークなコンテンツＩＤを付与する。このコンテンツＩＤのビット長も上記ノードＩＤのビット長と同一とされる。そして、当該コンテンツＩＤとして一般的には、そのコンテンツのタイトルを示すタイトルデータ、コンテンツを構成するデータの属性を示す属性データ、コンテンツを構成するデータのうち先頭から数バイト分のデータ等に対してハッシュ関数を適用して得られる値を用いる。
【００２９】
ここで、対応するノードＩＤ及びコンテンツＩＤが相互に同じビット長で表現されていることも関連して、上記ノード及びコンテンツは、同一のリング状の仮想的なＩＤ空間上に点在するものとして考えることができる。すなわち、一のノードを●で表示し且つ一のコンテンツを○で表示する図１（ａ）に示すように、コンテンツが属するリングＲcとノードが属するリングＲnとを仮想的に同心円状に想定する。そして更に、各リングＲc及びＲnにおいて反時計回りに各ＩＤの値が増加すると規定すると、各ノード又は各コンテンツは、各リングＲc及びＲn上に重なることなく存在すると仮定できるのである。なお、各ＩＤを上記の例のように１２８ビット長で表現すると桁数が多くなりすぎるので、図１（ａ）においては、説明の簡略化のために、各ＩＤのビット長を３２ビットとして表現している（以下、同様）。そして、上述したように各ＩＤの値を決めるに当たってハッシュ関数を用いたことに起因して、各ノード及び各コンテンツは、上記各リングＲc及びＲn上に偏ることなく概ね分散して存在することとなる。
【００３０】
一方、上記ＤＨＴを用いた配信システムでは、「あるコンテンツＩＤが付与されているコンテンツを管理するノードは、そのコンテンツＩＤの値に一番近い値を有するノードＩＤが付与されているノード」とされている。
【００３１】
ここで、「近い」とは、その配信システムに関する各種規定等において一貫してさえいればどのような定義付けでも良い。具体的には例えば、「そのコンテンツＩＤの値を超えない値であって且つＩＤとしての値同士の差が最も小さいもの」というように定義付けられる。
【００３２】
より具体的には、例えば図１（ａ）に例示するように、ノードＩＤの値が「Ａ０３３４０５５」であるノードとノードＩＤの値が「Ａ０３３４０ＦＦ」であるノードとがリングＲn上で隣り合って存在しているとする。この場合において、コンテンツＩＤの値が「Ａ０３３４０８０」であるコンテンツは、ノードＩＤの値が「Ａ０３３４０５５」であるノードが管理することになる。なお、図１（ａ）では、○のコンテンツを管理する端末情報を、当該各○から伸びた矢印で示している。このようにすると、多数のノードで分散して様々なコンテンツを管理することができる。
【００３３】
このとき、「管理」とは、そのコンテンツＩＤが付与されているコンテンツをその中に記録しているという意味ではなく、そのコンテンツが記録されているノードの所在（例えばＩＰアドレス等）を認識しているとの意味である。実際にコンテンツが記録されているノードと管理するノードとが異なっても良いし、或いは管理するノード内にその管理対象であるコンテンツが記録されていても良い。
【００３４】
そして、上述したコンテンツ管理用のノードを「ルートノード」と称する。ルートノードは、それが管理することとされているコンテンツを示すコンテンツＩＤと、当該コンテンツＩＤにより示されるコンテンツが記録されているノードのＩＰアドレスと、の対からなるインデックス情報を記録し、これを配信システム内の他のノードから参照可能に記録する。このインデックス情報内に、そのコンテンツのタイトルやその属性（ジャンル）等が含まれる場合もある。
【００３５】
また、異なるコンテンツを夫々示すコンテンツＩＤが偶然に近い値となり、その値に近い値のノードＩＤを有するノードが他に存在しない場合には、一つのルートノードが複数のコンテンツに対応する複数のインデックス情報を記録することとなる。更に、同一のコンテンツが異なる複数のノード内に記録されている場合であって、その同一のコンテンツを記録しているノードが偶然に一つのルートノードに近い場合、当該ルートノードには、同一のコンテンツが夫々に記録されている複数のノードのインデックス情報が記録されることとなる。上述してきたルートノード内のインデックス情報ＥＸの一例を図１（ｂ）に示す。
【００３６】
更に、実際に各コンテンツ自体を記録しているノードを「コンテンツホルダ」と称する。このとき、当該コンテンツホルダ自体はノードであるから、そのノードＩＤは、図１（ａ）におけるリングＲn上に存在していることになる。
【００３７】
次に、上記ＤＨＴを用いた配信システムにおいて、上述したように全てのノードのＩＰアドレスを各ノード夫々が記録する必要性を排除するための工夫の一つであるＤＨＴ（ルーティングテーブル）自体について説明する。
【００３８】
実施形態に係るＤＨＴには、図１に例示したＩＤ空間を段階的なレベル毎にレベル数を上げつつ細分化（例えば、レベル１の場合は当該ＩＤ空間を四分割）していき、そのレベル毎（段階的に細分化した領域毎）に、任意のノードのノードＩＤとそのＩＰアドレスとを対としたルーティング情報が記述されている。そして、例えばコンテンツの配信元情報を要求するための配信元問い合わせ情報をそのインデックス情報が記録されているルートノードに転送する場合、このルーティング情報を参照しつつ当該問い合わせ情報を目的のルートノードまで転送する。すなわち、ＤＨＴにおけるレベルが上がる度に、ルーティング先のノードＩＤが到達しようとするルートノードのノードＩＤに一桁ずつ合致していき、最終的に当該到達しようとするルートノードに上記要求情報が到達することになる。
【００３９】
なお、ＤＨＴを用いた配信システムにおいては、上述した如き問い合わせ情報（クエリ）や、そのコンテンツの配信自体を要求する配信要求情報、及び後述する登録メッセージ、などを「メッセージ」と称している。そして、上述した仕組みのＤＨＴを使うと、上記メッセージを図１に例示する如き上記ＩＤ空間内で効率よく目的のノードまで転送することができる。なお、以下の説明においては、コンテンツホルダにおいて新たにコンテンツが記録された場合に、それを他のノードから発見可能にする（公開する）ために当該コンテンツホルダにおいて生成されるメッセージを登録メッセージと称し、後述するリクエスタからルートノード又は後述するキャッシュノードに対して送信するメッセージを配信元問い合わせメッセージと称する。
【００４０】
ここで、上述したようにルートノードのノードＩＤの値は、そのルートノードがコンテンツを管理しているコンテンツホルダのノードＩＤの値に最も近いのであるから、上記配信元問い合わせメッセージは、当該配信要求メッセージにより要求されているコンテンツホルダに到達する直前に、配信要求対象のコンテンツを管理するルートノードに到達することになる。そして、当該配信元問い合わせメッセージを受け取ったルートノードは、その配信元問い合わせメッセージにより要求されているコンテンツを蓄積しているコンテンツホルダのＩＰアドレス等を、当該配信元問い合わせメッセージの発信元まで返信する。すなわち、ルートノード内に記録されているインデックス情報（図１（ｂ）参照）の中から、当該配信元問い合わせメッセージにより要求されているコンテンツを示すタイトル、属性情報及びそのコンテンツホルダとしてのノードのＩＰアドレス等が配信元問い合わせメッセージの発信元であるノードまで返信される。このようなＤＨＴの活用により、効率的に所望のコンテンツの所在が例えば配信要求元において認識できるのである。なお、上述したコンテンツの配信要求元であるノードを、以下「リクエスタ」と称する。
【００４１】
次に、あるノードに新たなコンテンツが蓄積された場合における当該コンテンツの登録処理について説明する。
【００４２】
新しいコンテンツがノード、すなわちそのコンテンツのコンテンツホルダに蓄積されると、そのコンテンツホルダは、配信システム内の他のノードに対してそのコンテンツが蓄積されたことを公開することになる。
【００４３】
すなわち、あるノードに新たなコンテンツが蓄積されたとき、当該蓄積されたコンテンツに対するコンテンツホルダとなるそのノードは、蓄積されたコンテンツのタイトル等に基づき、当該コンテンツに対応するコンテンツＩＤを算出する。
【００４４】
次に、当該コンテンツホルダは、算出されたコンテンツＩＤと同じ値を有するノードＩＤを有するノードを到達先として（そのノードＩＤを有するノードが実在するかどうかに拘わらず）、登録メッセージを送信する。この登録メッセージは、そのコンテンツを示すタイトル、属性情報及びそのコンテンツホルダとしてのノードのＩＰアドレス等を含むものであり、上記ＤＨＴの記述に従って各ルーティング先を介して各レベルの到達先としてのノードに順次転送される。
【００４５】
そして、最も近い値のノードＩＤを有するノードに到達すると、そのノードはその後にその登録メッセージを転送すべきノードがＩＤ空間内に存在しないことが認識して（ＤＨＴで桁合わせをすると、次に転送すべきノードが自分自身であることを認識する）、この時点で当該登録メッセージが到達しているノードが新たなコンテンツを管理するルートノードとなることになる。これにより、当該ルートノードとなったノードは、登録メッセージ含まれているコンテンツＩＤ及びコンテンツホルダを示すＩＰアドレス並びに属性情報等を図１（ｂ）に例示するインデックス情報ＥＸとして記録する。
【００４６】
次に、実施形態に係る配信システムにおける「キャッシュノード」なる概念について、図２を用いて説明する。なお、図２及び後述の図３においては、ルートノードを二重丸で示し、コンテンツホルダを内部に×が記された○で示し、リクエスタを内部に｜が記された○で示し、後述するキャッシュノードを内部に＋が記された○で示し、他の一般のノードは●で示す。
【００４７】
上述したＤＨＴを用いたルーティングによりリクエスタＲＱ１乃至ＲＱ３からの配信元問い合わせメッセージＱrをルートノードＲＮ（又はコンテンツホルダＣＨ）に転送する場合、その転送経路（図２（ａ）及び図２（ｂ）において破線で示す）は、図２（ａ）に示すように上述した登録メッセージＱpが辿った経路（図２（ａ）及び図２（ｂ）において実線で示す）と似た経路となるので、この経路上にある各ノード（図２（ａ）において符号ＣＮで示す）においても図１（ｂ）に例示するインデックス情報ＥＸを記録しておけば、当該経路を経る配信元問い合わせメッセージＱrに対応して、その到達先であるルートノードＲＮ又はコンテンツホルダＣＨに当該配信元問い合わせメッセージＱrが到達する前に、早い段階で当該配信元問い合わせメッセージＱrに対応する回答をリクエスタＲＱ１乃至ＲＱ３まで返信することができる。
【００４８】
すなわち、配信システム内に公開されたコンテンツの配信を要求するリクエスタＲＱ１乃至ＲＱ３が、そのコンテンツが記録されているノード（すなわちコンテンツホルダＣＨ）のＩＰアドレスを要求する旨の配信元問い合わせメッセージＱrを送信する。そして、当該送信された配信元問い合わせメッセージＱrは各ノード内のＤＨＴに記述されているルーティング先を転送されルートノードＲＮに近づいていく。その後、最終的には、その経路がコンテンツホルダＣＨからの登録メッセージＱpの経路と合流して、ルートノードＲＮに到達する。
【００４９】
ここで、図２（ａ）に示したリングＲc上の経路を木構造に置き換えると図２（ｂ）に示した如きものとなるが、これを一般には「スパニングツリー」と称する。
【００５０】
図２（ａ）に示したように、各リクエスタＲＱから送信された配信元問い合わせメッセージＱrの経路とコンテンツホルダＣＨから送信された登録メッセージＱpの経路とは、それら経路上のいずれかのノードにおいていずれ交わる。そこで、公開用の登録メッセージＱpをルートノードＲＮまで到達させる経路上にあるノード夫々に当該登録メッセージＱpに含まれているインデックス情報ＥＸを、一時的に記録可能な一時記録領域に記録させつつ（すなわち、一時的にキャッシュさせつつ）当該登録メッセージＱpの転送を行う。そうすれば、リクエスタＲＱからの配信元問い合わせメッセージＱrに対する返信を、ルートノードＲＮに至る経路上の配信元問い合わせメッセージＱrが到達したノードから、配信元問い合わせメッセージＱrがルートノードＲＮに到達する前に行うことができるのである。このようにルートノードＲＮ以外のノードであってインデックス情報ＥＸを一時的に記録しているノードを、以下「キャッシュノード」ＣＮと称する。
【００５１】
（Ｂ）本発明の原理
次に、概要を上述した配信システムを前提とする本発明に原理について、図３及び図４を用いて説明する。
【００５２】
上述した配信システムにおけるインデックス情報ＥＸには、図１（ｂ）に例示したように、当該インデックス情報ＥＸの夫々が対応するコンテンツ自体を示す情報（例えば図１（ｂ）に例示するタイトルやジャンル、或いは監督名等）の他は、対応するコンテンツＩＤ及びそのコンテンツが記録されている蓄積装置としてのコンテンツホルダＣＨのＩＰアドレス等のみが含まれていた。
【００５３】
そこで、図３に示すように、本発明では、このインデックス情報ＥＸの夫々に対して、配信開始時刻情報１００と、終了予測時刻情報１０１と、配信可能数情報１０２と、を夫々に含む補助情報ＨＰを夫々追加し、本発明に係るインデックス情報ＥＸＸとする。
【００５４】
このとき、配信開始時刻情報１００は、当該インデックス情報ＥＸＸが対応するコンテンツが記録されているコンテンツホルダＣＨから当該コンテンツの配信を開始した時刻である配信開始時刻を示す情報である。また、終了予測時刻情報１０１は、当該コンテンツのコンテンツホルダＣＨからの配信が終了する予想時刻である終了予測時刻を示す情報である。更に、配信可能数情報１０２は、当該コンテンツホルダＣＨから現在配信しているコンテンツに追加して更に配信可能なコンテンツの数を示す情報である。なお、図３においては、上記新たに追加される補助情報ＨＰを特徴的に示しており、元々インデックス情報ＥＸとして含まれていた上記コンテンツ自体を示す情報の記載は省略している。
【００５５】
そして、リクエスタＲＱが、補助情報ＨＰを含むそのインデックス情報ＥＸＸを参照したときに、当該補助情報ＨＰに基づき、コンテンツを他のリクエスタＲＱに対して配信中であり且つ終了予測時刻情報１０１により示されている終了予測時刻が最も遅いコンテンツホルダＣＨから優先して接続する。これにより、当該接続したコンテンツホルダＣＨから、現在配信中のコンテンツと並行してリクエスタＲＱにおいて所望されているコンテンツの配信を受けることとする。
【００５６】
これにより、例えば図４に例示するように、同じコンテンツＣＴを配信しているコンテンツホルダＣＨ１とＣＨ２があり、夫々の終了予測時刻が図４に示す終了予測時刻ＥＴ１とＥＴ２であった場合には、コンテンツホルダＣＨ２からではなく、より終了予測時刻が遅いコンテンツホルダＣＨ１に接続して新たなコンテンツＣＴの配信を受ける。
【００５７】
このようにすることで、同じコンテンツＣＴの配信につき、現在その配信を行っているコンテンツホルダＣＨ１以外の他のコンテンツホルダＣＨが新たなに配信のための稼働を開始することがない。そして、そのコンテンツホルダＣＨ１から並行してコンテンツＣＴの配信を新たに受けることで、結果として配信システム全体として稼働中のコンテンツホルダＣＨの数を減らし（換言すれば増加させないようにし）、当該全体としての消費電力及び騒音の低減を実現する。
【００５８】
なお、上記終了予測時刻情報１０１については、対応する配信開始時刻情報１００により示される配信開始時刻及び配信対象たるコンテンツのデータ量を用いてその配信所要時間を算出して上記配信開始時刻に加算し、配信の終了予測時刻を算出する。そして、対応する開始予測時刻情報１００と対にして記憶する。
【００５９】
また、図３では、一つのルートノードＲＮに複数のコンテンツに対応するインデックス情報ＥＸＸが記録されており、更に一つのコンテンツにつき、同一のコンテンツを記録する複数のコンテンツホルダＣＨに対応するインデックス情報ＥＸＸが記録されている状態を例示している。
【００６０】
更にまた、当該インデックス情報ＥＸＸは、図３に示すルートノードＲＮだけでなく、上述したキャッシュノードＣＮにも同様のものが記録されており、これを参照することで、リクエスタＲＱからの配信元問い合わせメッセージＱrをルートノードＲＮまで到達させずとも、当該配信元問い合わせメッセージＱrに補助情報ＨＰを参照して対応する返信情報ＲＴを当該リクエスタＲＱまで返信することができる。
【００６１】
このように、本発明による補助情報ＨＰを含むインデックス情報ＥＸＸをルートノードＲＮ及びキャッシュノードＣＮが夫々記録しておくことで、他のリクエスタＲＱに対する配信の終了予測時刻が最も遅いコンテンツホルダＣＨから並列して所望のコンテンツの配信を受け、これにより配信システム全体としての消費電力及び騒音の低減が実現できるのである。
（II）第１実施形態
次に、上述した原理に則った本発明に係る第１実施形態について、具体的に図５乃至図１０を用いて説明する。
【００６２】
初めに、第１実施形態に係るノードの概要構成について図５を用いて説明する。なお、図５は第１実施形態に係るノードの概要構成を示すブロック図である。また、本第１実施形態においては、上記コンテンツホルダＣＨ、リクエスタＲＱ、ルートノードＲＮ、キャッシュノードＣＮ及びその他のノードＮは、基本的に全て同一のハードウエア構成を有するものであるので、それらを代表して一般のノードＮの構成について、図５を用いてその概要を説明する。
【００６３】
図５に示すように、第１実施形態に係る配信システムに含まれているノードＮは、制御部１１と、記憶部１２と、バッファメモリ１３と、デコーダ部１４と、映像処理部１５と、ＣＲＴ（Cathode Ray Tube）又は液晶ディスプレイ等よりなる表示部１６と、音声処理部１７と、スピーカ１８と、通信部２０と、例えば、キーボード、マウス或いは操作パネル等を含む入力部２１と、により構成されている。
【００６４】
この構成において、制御部１１は、演算機能を有するＣＰＵ、作業用ＲＡＭ（Random Access Memory）、各種データ及びプログラムを記録するＲＯＭ（Read Only Memory）等から構成されている。
【００６５】
また、記憶部１２は、上記コンテンツ自体としてのコンテンツデータ、上記インデックス情報ＥＸＸ、上記ＤＨＴ及びその他の必要なプログラム等を記録保存（格納）するためのＨＤＤ等から構成されている。なお、上記コンテンツデータは、その配信前はコンテンツホルダＣＨとしてのノードＮ内の記憶部１２内にのみ記録されている。
【００６６】
更に、バッファメモリ１３は、受信されたコンテンツデータを一時蓄積する。そして、デコーダ部１４は、コンテンツデータに含まれるエンコード（符号化）されたビデオデータ（映像情報）及びオーディオデータ（音声情報）等をデコード（データ伸張や復号化等）する。その後、映像処理部１５は、当該デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する。そして、表示部１６は、当該映像処理部１５から出力されたビデオ信号に基づき映像表示する。
【００６７】
一方、音声処理部１７は、上記デコードされたオーディオデータをアナログオーディオ信号にＤ／Ａ（Digital/Analog）変換した後これを増幅器等により増幅して出力する。そして、スピーカ１８は、当該音声処理部１７から出力されたオーディオ信号を音波として出力する。
【００６８】
他方、通信部２０は、ネットワーク８を通じて他のノード装置１との間の情報の通信制御を行なうために用いられる。
【００６９】
更に、入力部２１は、夫々の使用者からの指示を受け付け当該指示に応じた指示信号を制御部１１に出力する。
【００７０】
更にまた、制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４、及び通信部２０はバス２２を介して相互にデータの授受が可能に接続されている。
【００７１】
そして、制御部１１におけるＣＰＵが記憶部１２等に記録された各種プログラムを実行することにより、当該制御部１１が、リクエスタＲＱ、キャッシュノードＣＮ、ルートノードＲＮ、コンテンツホルダＣＨ又はそれら以外の一般のノードＮとしての全体動作を統括制御する。
【００７２】
なお、上記ノードＮが本発明に係る情報処理装置としてのルートノードＲＮ又はキャッシュノードＣＮである場合は、制御部１１が本発明に係る配信元制御手段及び検索手段として機能し、記憶部１２が本発明に係る記憶手段として機能し、通信部２０が受信手段及び所在情報送信手段として機能する。
【００７３】
また、上記ノードＮが本発明に係る情報処理装置としてのリクエスタＲＱである場合は、制御部１１が本発明に係る配信元制御手段及び取得手段として機能し、通信部２０が受信手段及び送信手段として機能する。
【００７４】
次に、コンテンツホルダＣＨ、ルートノードＲＮ及びキャッシュノードＣＮ並びにリクエスタＲＱに分けて、第１実施形態に係る各ノードＮの動作について説明する。
【００７５】
（Ａ）コンテンツホルダにおける動作
先ず、第１実施形態に係るコンテンツホルダＣＨにおける動作について、図６を用いて説明する。なお、図６は第１実施形態に係るコンテンツホルダＣＨにおける動作を示すフローチャートである。
【００７６】
図６に示すように、第１実施形態に係るコンテンツホルダＣＨにおいては、先ず、当該コンテンツホルダＣＨ内の記憶部１２に配信用の新しいコンテンツ（又はその複製（レプリカ））が記録される。そして、当該記録されたコンテンツの配信がいずれかのノードＮに対して配信開始時刻情報１００により示される時刻から開始されると、当該配信の終了予測時刻を示す上記終了予測時刻情報１０１と、現在実行されている配信に追加して更に配信可能なコンテンツの数を示す上記配信可能数情報１０２と、が、コンテンツホルダＣＨ内の制御部１１により生成される（ステップＳ１）。
【００７７】
このとき、終了予測時刻情報１０１は、当該制御部１１において、上述したように、対応する配信開始時刻及び配信対象たるコンテンツのデータ量を用いてその配信所要時間を算出し、当該配信開始時刻に加算することで算出される。また、配信可能数情報１０２により示される配信可能数は、コンテンツホルダＣＨにおける通信部２０における帯域幅や、記憶部１２における読出速度等に基づいて制御部１１により決定される。
【００７８】
そして、制御部１１は、当該終了予測時刻情報１０１及び配信可能数情報１０２等を含む補助情報ＨＰを含むインデックス情報ＥＸＸを含む登録メッセージＱp（図３参照）を、ルートノードＲＮとなるべきノードＮに向けて送信する（ステップＳ２）。
【００７９】
次に、その登録メッセージＱpを送信したら、制御部１１は、当該制御部１１内の図示しないタイマにおける計時をスタートさせ（ステップＳ３）、予め設定された時間Ｔ１が経過したか否かを監視する（ステップＳ４、Ｓ４；Ｎ）。
【００８０】
ここで、当該時間Ｔ１は、更新された補助情報ＨＰを含む後述の更新メッセージがコンテンツホルダＣＨから頻繁に配信システム内に送出されることに起因して、ネットワーク内の通信量が過大となることを防止するために設けられた間隔時間である。
【００８１】
ステップＳ４の判定において、時間Ｔ１が経過したときは（ステップＳ４；Ｙ）、ルートノードＲＮにおける当該コンテンツホルダＣＨに対応する更新情報ＨＰを更新すべきとして、制御部１１は、当該更新のためのメッセージを当該ルートノートＲＮに向けて送信する（ステップＳ５）。次に、制御部１１は、当該コンテンツホルダＣＨ内に記録されているコンテンツ（又はその複製）が記憶部１２から消去されたか否かを確認する（ステップＳ６）。そして、消去されているとき（ステップＳ６；Ｙ）、制御部１１は、コンテンツホルダＣＨにおける第１実施形態としての処理を完了し、一方、未だ消去されていないとき（ステップＳ６；Ｎ）、制御部１１は、補助情報ＨＰ更新後（ステップＳ５）の新たなタイマにおける計時を開始すべく上記ステップＳ３に戻る。
【００８２】
以上説明した制御部１１を中心としたコンテンツホルダＣＨとしての動作により、コンテンツの初期登録に伴う補助情報ＨＰの新規生成並びにその更新が実行され、それを含むインデックス情報ＥＸＸがルートノードＲＮ（及びキャッシュノードＣＮ）内に記録される。
【００８３】
（Ｂ）ルートノード及びキャッシュノードにおける動作
次に、第１実施形態に係るルートノードＲＮ及びキャッシュノードＣＮにおける動作について、図７乃至図９を用いて説明する。なお、図７は第１実施形態に係るルートノードＲＮ及びキャッシュノードＣＮにおける全体動作を示すフローチャートであり、図８及び図９は当該ルートノードＲＮ及びキャッシュノードＣＮにおける細部動作を夫々示すフローチャートである。
【００８４】
第１実施形態に係るルートノードＲＮ及びキャッシュノードＣＮの動作は、配信システム内のいずれかのノードＮから何らかのメッセージ（登録メッセージＱp又は配信元問い合わせメッセージＱrのいずれか）を受け取ることにより開始される。
【００８５】
そして、当該メッセージがコンテンツホルダＣＨからの登録メッセージＱpであるか、或いはリクエスタＲＱからの配信元問い合わせメッセージＱrであるかを、当該メッセージの内容に基づき、第１実施形態に係るルートノードＲＮ及びキャッシュノードＣＮ内の制御部１１において判断する（ステップＳ１１）。
【００８６】
そして、当該受け取ったメッセージがリクエスタＲＱからの配信元問い合わせメッセージＱrであるときは（ステップＳ１１；リクエスタから）、次に、その配信元問い合わせメッセージＱrを受け取ったノードＮ自体（すなわち、図７のフローチャートにより示される動作が実行されているノードＮ）がルートノードＲＮであるか或いはキャッシュノードＣＮであるかが制御部１１により確認される（ステップＳ１２）。
【００８７】
このステップＳ１２に係る確認において、当該ノードＮ自体がルートノードＲＮであるか否かは、当該メッセージにおける送信先を示す識別情報と当該ノードＮ自体が記憶しているＤＨＴに基づいて制御部１１により確認される。一方、当該確認において、当該ノードＮ自体がキャッシュノードＣＮであるか否かは、当該メッセージにおける送信先を示す識別情報と当該ノードＮ自体が記憶しているインデックス情報ＥＸＸに基づいて制御部１１により確認される。
【００８８】
これにより、当該ノードＮがルートノードＲＮであるときは（ステップＳ１２；ルートノード）、当該ルートノードＲＮ内の制御部１１は、当該ルートノードＲＮとして上記配信元問い合わせメッセージＱrに対する返信処理を行い（ステップＳ１３）、当該ルートノードＲＮとしての動作を終了する。なお、当該ステップＳ１３の動作の細部については、後ほど詳述する。
【００８９】
一方、ステップＳ１２の判定において、当該ノードＮがキャッシュノードＣＮであるときは（ステップＳ１２；キャッシュノード）、当該キャッシュノードＣＮ内の制御部１１は、当該キャッシュノードＣＮとして上記配信元問い合わせメッセージＱrに対する返信処理を行い（ステップＳ１４）、当該キャッシュノードＣＮとしての動作を終了する。なお、当該ステップＳ１４の動作の細部についても、後ほど詳述する。
【００９０】
他方、上記ステップＳ１１の判定において、当該受け取ったメッセージがコンテンツホルダＣＨからの登録メッセージＱpであるときは（ステップＳ１１；コンテンツホルダから）、次に、上記ステップＳ１２の判定と同様に、その登録メッセージＱpを受け取ったノードＮ自体がルートノードＲＮであるか或いはキャッシュノードＣＮであるかが、当該ノードＮ自体の制御部１１により確認される（ステップＳ１５）。
【００９１】
これにより、当該ノードＮがルートノードＲＮであるときは（ステップＳ１５；ルートノード）、当該ルートノードＲＮ内の制御部１１は、更に受け取った登録メッセージＱpがコンテンツの新規登録時にコンテンツホルダＣＨから送信された登録メッセージＱpであるか、或いは登録済みのコンテンツに対応するインデックス情報ＥＸＸを更新するための登録メッセージＱpであるかを、その内容等に基づいて確認する（ステップＳ１６）。そして、受け取った登録メッセージＱpが新規登録用の登録メッセージＱpであるときは（ステップＳ１６；登録）、当該制御部１１は、当該ルートノードＲＮとして当該登録メッセージＱpを用いた登録処理を行い（ステップＳ１７）、当該ルートノードＲＮとしての動作を終了する。なお、当該ステップＳ１７の動作の細部についても、後ほど詳述する。
【００９２】
一方、ステップＳ１６の判定において、受け取った登録メッセージＱpが更新用の登録メッセージＱpであるときは（ステップＳ１６；更新）、当該制御部１１は、当該ルートノードＲＮとして当該登録メッセージＱpを用いた更新処理を行い（ステップＳ１８）、当該ルートノードＲＮとしての動作を終了する。なお、当該ステップＳ１８の動作の細部についても、後ほど詳述する。
【００９３】
他方、ステップＳ１５の判定において、当該ノードＮがキャッシュノードＣＮであるときは（ステップＳ１５；キャッシュノード）、当該キャッシュノードＣＮ内の制御部１１は、更に上記ステップＳ１６と同様にその受け取った登録メッセージＱpが新規登録用の登録メッセージＱpであるか、或いはインデックス情報ＥＸＸ更新用の登録メッセージＱpであるかを、その内容等に基づいて確認する（ステップＳ１９）。そして、受け取った登録メッセージＱpが新規登録用の登録メッセージＱpであるときは（ステップＳ１９；登録）、当該制御部１１は、当該キャッシュノードＣＮとして当該登録メッセージＱpを用いた登録処理を行い（ステップＳ２０）、当該キャッシュノードＣＮとしての動作を終了する。なお、当該ステップＳ２０の動作の細部についても、後ほど詳述する。
【００９４】
一方、ステップＳ１９の判定において、受け取った登録メッセージＱpが更新用の登録メッセージＱpであるときは（ステップＳ１９；更新）、当該制御部１１は、当該キャッシュノードＣＮとして当該登録メッセージＱpを用いた更新処理を行い（ステップＳ２１）、当該キャッシュノードＣＮとしての動作を終了する。なお、当該ステップＳ２１の動作の細部については、後ほど詳述する。
【００９５】
次に、上記ステップＳ１４としてのキャッシュノードＣＮにおける配信元問い合わせメッセージＱrに対する返信処理の詳細について、図８（ａ）を用いて説明する。
【００９６】
ルートノードＲＮと同様のインデックス情報ＥＸＸを記録するキャッシュノードＣＮ（図３参照）において配信元問い合わせメッセージＱrを受信した場合、当該キャッシュノードＣＮ内の制御部１１は、図８（ａ）に示すように、先ず、当該配信元問い合わせメッセージＱrから、それを送信したリクエスタＲＱにおいて所望されているコンテンツを示すインデックス情報ＥＸＸを示す情報と当該インデックス情報ＥＸＸの数を抽出する（ステップＳ３０）。そして、当該制御部１１は、その配信元問い合わせメッセージＱrから抽出したインデックス情報ＥＸＸを識別する識別情報と同一の識別情報を有するインデックス情報ＥＸＸが実際にそのキャッシュノードＣＮ内に記録されているか否かを確認する（ステップＳ３１）。そして、当該所望されているコンテンツに対応するインデックス情報ＥＸＸがそのキャッシュノードＣＮ内にない場合は（ステップＳ３１；Ｎ）、当該制御部１１は、他のルートノードＲＮ又はキャッシュノードＣＮ内において必要なインデックス情報ＥＸＸを検索すべく、当該他のルートノードＲＮ又はキャッシュノードＣＮに上記配信元問い合わせメッセージＱrを転送して（ステップＳ３６）、第１実施形態に係るキャッシュノードＣＮとしての処理を終了する。
【００９７】
一方、ステップＳ３１の判定において、その配信元問い合わせメッセージＱrにおいて所望されているコンテンツに対応するインデックス情報ＥＸＸがそのキャッシュノードＣＮ内に一又は複数個発見された場合は（ステップＳ３１；Ｙ）、当該制御部１１は、次に、発見された各インデックス情報ＥＸＸに含まれている配信可能数情報１０２に記述されている配信可能数が全て零でないか否かを確認する（ステップＳ３２）。
【００９８】
ステップＳ３２の判定において、各インデックス情報ＥＸＸ内の配信可能数情報１０２に夫々記述されている配信可能数が全て零であるときは（ステップＳ３２；Ｎ）、発見されたインデックス情報ＥＸＸに対応するコンテンツホルダＣＨからの追加配信は不可能であるので、当該制御部１１は、上記ステップＳ３６の処理に移行して第１実施形態に係るキャッシュノードＣＮとしての処理を終了する。
【００９９】
一方、ステップＳ３２の判定において、記述されている配信可能数が零でないインデックス情報ＥＸＸがあるときは（ステップＳ３２；Ｙ）、コンテンツの追加配信が可能なコンテンツホルダＣＨがあることになる。そこで次に、当該制御部１１は、上記発見されたインデックス情報ＥＸＸに基づき、それに含まれている終了予測時刻情報１０１により示される終了予測時刻が現在時刻より後であるコンテンツを配信しているコンテンツホルダＣＨがあるか否かを確認する（ステップＳ３３）。このステップＳ３３の処理は、対象のコンテンツホルダＣＨが、他のリクエスタＲＱに対するコンテンツの配信を現在進行中であるか否かを確認する処理である。
【０１００】
ステップＳ３３の判定において、配信中のコンテンツに対応する上記終了予測時刻が現在時刻より後であるコンテンツホルダＣＨが一つも存在しないときは（ステップＳ３３；Ｎ）、当該制御部１１は、上記ステップＳ３６の処理に移行して第１実施形態に係るキャッシュノードＣＮとしての処理を終了する。
【０１０１】
一方、ステップＳ３３の判定において、配信中のコンテンツに対応する上記終了予測時刻が現在時刻より後であるコンテンツホルダＣＨが存在するときは（ステップＳ３３；Ｙ）、当該制御部１１は、次に当該終了予測時刻が現在時刻より後であるコンテンツホルダＣＨの数が「１」であるか否かを確認する（ステップＳ３４）。そして、当該数が「１」であるときは（ステップＳ３４；Ｙ）、当該制御部１１は、そのコンテンツホルダＣＨに対応するインデックス情報ＥＸＸを、配信元問い合わせメッセージＱrを送信してきたリクエスタＲＱに対して返信し（ステップＳ３７）、第１実施形態に係るキャッシュノードＣＮとしての処理を終了する。
【０１０２】
他方、ステップＳ３４の判定において、当該終了予測時刻が現在時刻より後であるコンテンツホルダＣＨの数が二以上であるときは（ステップＳ３４；Ｎ）、当該制御部１１は、その二以上のコンテンツホルダＣＨに対応するインデックス情報ＥＸＸの中から、上記ステップＳ３３において確認されている終了予測時刻のうち最も遅い終了予測時刻が記述されている終了予測時刻情報１０１を含むインデックス情報ＥＸＸを抽出する。そして、当該制御部１１は、当該抽出したインデックス情報ＥＸＸを、配信元問い合わせメッセージＱrを送信して来たリクエスタＲＱに対して返信し（ステップＳ３５）、第１実施形態に係るキャッシュノードＣＮとしての処理を終了する。
【０１０３】
次に、上記ステップＳ１３としてのルートノードＲＮにおける配信元問い合わせメッセージＱrに対する返信処理の詳細について、図８（ｂ）を用いて説明する。
【０１０４】
キャッシュノードＣＮと同様のインデックス情報ＥＸＸを記録するルートノードＲＮ（図３参照）において配信元問い合わせメッセージＱrを受信した場合、当該ルートノードＲＮ内の制御部１１は、図８（ｂ）に示すように、先ず、ルートノードＲＮ内に記録されている各インデックス情報ＥＸＸを対象として図８（ａ）に示すステップＳ３０と同様の処理を行う。
【０１０５】
次に、当該制御部１１は、その配信元問い合わせメッセージＱrから抽出したインデックス情報ＥＸＸをルートノードＲＮ内において一又は複数検索する（ステップＳ３８）。
【０１０６】
そして、当該制御部１１は、当該検索されたインデックス情報ＥＸＸに対して、図８（ａ）に示すステップＳ３２乃至Ｓ３５及びＳ３７と同様の処理を行い、最も遅い終了予測時刻が記述されている終了予測時刻情報１０１を含むインデックス情報ＥＸＸを、配信元問い合わせメッセージＱrを送信して来たリクエスタＲＱに対して返信する。
【０１０７】
一方、ステップＳ３２の判定において、各インデックス情報ＥＸＸ内の配信可能数情報１０２に夫々記述されている配信可能数が全て零であるとき（ステップＳ３２；Ｎ）、又は、ステップＳ３３の判定において、配信中のコンテンツに対応する上記終了予測時刻が現在時刻より後であるコンテンツホルダＣＨが一つも存在しないときは（ステップＳ３３；Ｎ）、当該制御部１１は、夫々、配信元問い合わせメッセージＱrにおいて要求されている数のインデックス情報ＥＸＸが当該所望数だけ発見できないのでしばらく待機すべき旨、その配信元問い合わせメッセージＱrを送信してきたリクエスタＲＱに返信して（ステップＳ３９）、第１実施形態に係るルートノードＲＮとしての処理を終了する。
【０１０８】
次に、上記ステップＳ１７としてのルートノードＲＮにおける登録メッセージＱpに対応する処理の詳細について、図９（ａ）を用いて説明する。
【０１０９】
図９（ａ）に示すように、ルートノードＲＮにおいて新規登録用の登録メッセージＱpを受信すると（ステップＳ５０）、当該ルートノードＲＮ内の制御部１１は、そのインデックス情報ＥＸＸをそれに含まれる補助情報ＨＰと共にその記憶部１２に記録させて（ステップＳ５１、Ｓ５２）、第１実施形態に係るルートノードＲＮとしての処理を終了する。
【０１１０】
次に、上記ステップＳ１８としてのルートノードＲＮにおける登録メッセージＱpに対応する処理の詳細について、図９（ｂ）を用いて説明する。
【０１１１】
図９（ｂ）に示すように、ルートノードＲＮにおいて補助情報ＨＰの更新用登録メッセージＱpを受信すると（ステップＳ５５）、当該ルートノードＲＮ内の制御部１１は、そのインデックス情報ＥＸＸと同じコンテンツを示す既存のインデックス情報ＥＸＸをそのルートノードＲＮ内において検索し（ステップＳ５６）、その検索したインデックス情報ＥＸＸの内容を新しいインデックス情報ＥＸＸの内容に書き換えて（ステップＳ５７）、第１実施形態に係るルートノードＲＮとしての処理を終了する。
【０１１２】
次に、上記ステップＳ２０としてのキャッシュノードＣＮにおける登録メッセージＱpに対応する処理の詳細について、図９（ｃ）を用いて説明する。
【０１１３】
図９（ｃ）に示すように、キャッシュノードＣＮにおいて新規登録用の登録メッセージＱpを受信すると（ステップＳ６０）、当該キャッシュノードＣＮ内の制御部１１は、そのインデックス情報ＥＸＸをそれに含まれる補助情報ＨＰと共にその記憶部１２に記録させ（ステップＳ６１、Ｓ６２）、更にその新規登録用の登録メッセージＱpを次のキャッシュノードＣＮに転送して（ステップＳ６３）、第１実施形態に係るキャッシュノードＣＮとしての処理を終了する。
【０１１４】
最後に、上記ステップＳ２１としてのキャッシュノードＣＮにおける登録メッセージＱpに対応する処理の詳細について、図９（ｄ）を用いて説明する。
【０１１５】
図９（ｄ）に示すように、キャッシュノードＣＮにおいて補助情報ＨＰの更新用登録メッセージＱpを受信すると（ステップＳ６５）、当該キャッシュノードＣＮ内の制御部１１は、そのインデックス情報ＥＸＸと同じコンテンツを示す既存のインデックス情報ＥＸＸをそのキャッシュノードＣＮ内において検索し（ステップＳ６６）、その検索したインデックス情報ＥＸＸの内容を新しいインデックス情報ＥＸＸの内容に書き換え（ステップＳ６７）、更にその更新用の登録メッセージＱpを次のキャッシュノードＣＮに転送して（ステップＳ６８）、第１実施形態に係るキャッシュノードＣＮとしての処理を終了する。
【０１１６】
（Ｃ）リクエスタにおける動作
最後に、第１実施形態に係るリクエスタＲＱにおける動作について、図１０を用いて説明する。なお、図１０は第１実施形態に係るリクエスタＲＱにおける動作を示すフローチャートである。
【０１１７】
第１実施形態に係るリクエスタＲＱの動作は、使用者による所望のコンテンツの配信を要求する旨の操作が、当該リクエスタＲＱ内の入力部２１において実行されることにより開始される。
【０１１８】
そして、当該リクエスタＲＱにおける制御部１１において当該配信要求されたコンテンツを示すコンテンツＩＤを算出し、配信元問い合わせメッセージＱrを生成する（ステップＳ７１）。
【０１１９】
次に、当該制御部１１は、第１実施形態に係る配信システム内のネットワークにおけるスパニングツリー上でルートノードＲＮに向けて当該生成された配信元問い合わせメッセージＱrを送信し（ステップＳ７２）、その送信結果として所望するインデックス情報ＥＸＸが取得できたか（図８（ａ）又は図８（ｂ）ステップＳ３５又はＳ３７参照）、又はしばらく待機すべき旨のメッセージが送られてきたか（図８（ｂ）ステップＳ３９参照）を確認する（ステップＳ７３）。
【０１２０】
そして、配信要求されたコンテンツを蓄積しているコンテンツホルダＣＨに対応するインデックス情報ＥＸＸが得られた場合、当該制御部１１は、そのインデックス情報ＥＸＸにより示されるコンテンツホルダＣＨに接続して（ステップＳ７４）、所望するコンテンツの配信を受ける（ステップＳ７５）。以上の動作により、第１実施形態に係るリクエスタＲＱとしての処理を完了する。
【０１２１】
以上夫々説明したように、第１実施形態に係るノードＮとしてのコンテンツホルダＣＨ、ルートノードＲＮ、キャッシュノードＣＮ及びリクエスタＲＱの動作によれば、コンテンツを現在配信中であって且つその終了予測時刻が最も遅いコンテンツホルダＣＨから他のコンテンツを配信させるので、現在配信中のコンテンツホルダＣＨから同時並行的に更に新たな配信を行わせることで、新たなコンテンツホルダＣＨにおいて配信処理が開始されることに起因する消費電力の増大等を抑制することができる。
【０１２２】
従って、配信システム全体としての消費電力を低下させることが可能となる。
【０１２３】
なお、上述した第１実施形態において、終了予測時刻が最も遅いコンテンツホルダＣＨが複数存在するときには、配信数情報１０２により示される配信可能数が最も多いコンテンツホルダＣＨから、次に配信が所望されている他の配信情報を配信させるように構成すればよい。
【０１２４】
この構成によれば、新たなコンテンツホルダＣＨにおいて配信処理が開始されることに起因する消費電力の増大等を更に抑制することができる。
（III）第２実施形態
次に、上述した原理に則った本発明に係る他の実施形態である第２実施形態について、図１１及び図１２を用いて説明する。
【０１２５】
上述した第１実施形態においては、現在実行されているコンテンツの配信における終了予測時刻が最も遅いコンテンツホルダＣＨの特定は、ルートノードＲＮ又はキャッシュノードＣＮにおいて実行した（図８（ａ）及び（ｂ）におけるステップＳ３５参照）。これに対し、以下に説明する第２実施形態においては、当該終了予測時刻が最も遅いコンテンツホルダＣＨの特定をリクエスタＲＱにおいて実行する。
【０１２６】
なお、第２実施形態に係るノードＮとしての構成は第１実施形態に係るノードＮの構成と同様であるので、細部の説明は省略する。また、第２実施形態に係るノードＮとしてのコンテンツホルダＣＨ等の動作としては、ルートノードＲＮ、キャッシュノードＣＮ及びリクエスタＲＱの動作が第１実施形態に係るものと異なるのみである。よって、当該異なる部分についてのみ図１１及び図１２を用いて説明し、その他の同一の動作については細部の説明を省略する。
【０１２７】
更に、図１１は第１実施形態に係る図８に相当するルートノードＲＮ及びキャッシュノードＣＮの細部動作を示すフローチャートである。また図１２は第１実施形態に係る図１０に相当するリクエスタＲＱの動作を示すフローチャートである。
【０１２８】
（Ａ）ルートノード及びキャッシュノードにおける動作
先ず、第２実施形態に係るルートノードＲＮ及びキャッシュノードＣＮにおける細部動作について、図１１を用いて説明する。
【０１２９】
初めに、ステップＳ１４（図７参照）としてのキャッシュノードＣＮにおける配信元問い合わせメッセージＱrに対する返信処理の詳細について、図１１（ａ）を用いて説明する。
【０１３０】
ルートノードＲＮと同様のインデックス情報ＥＸＸを記録する第２実施形態に係るキャッシュノードＣＮ（図３参照）において配信元問い合わせメッセージＱrを受信した場合、当該キャッシュノードＣＮ内の制御部１１は、図１１（ａ）に示すように、先ず、第１実施形態と同様のステップＳ３０乃至Ｓ３３及びＳ３６の動作を実行する（図８（ａ）参照）。
【０１３１】
そして、ステップＳ３３の判定において、配信中のコンテンツに対応する上記終了予測時刻が現在時刻より後であるコンテンツホルダＣＨが存在するときは（ステップＳ３３；Ｙ）、当該制御部１１は、そのコンテンツホルダＣＨに対応するインデックス情報ＥＸＸを、ステップＳ３３において存在が確認されたコンテンツホルダＣＨの数だけ、配信元問い合わせメッセージＱrを送信してきたリクエスタＲＱに対して返信し（ステップＳ４０）、第２実施形態に係るキャッシュノードＣＮとしての処理を終了する。
【０１３２】
次に、ステップＳ１３（図７参照）としてのルートノードＲＮにおける配信元問い合わせメッセージＱrに対する返信処理の詳細について、図１１（ｂ）を用いて説明する。
【０１３３】
キャッシュノードＣＮと同様のインデックス情報ＥＸＸを記録する第２実施形態に係るルートノードＲＮ（図３参照）において配信元問い合わせメッセージＱrを受信した場合、当該ルートノードＲＮ内の制御部１１は、図１１（ｂ）に示すように、先ず、第１実施形態と同様のステップＳ３０、Ｓ３８、Ｓ３２及びＳ３３並びにＳ３９の動作を実行する（図８（ｂ）参照）。
【０１３４】
そして、ステップＳ３３の判定において、配信中のコンテンツに対応する上記終了予測時刻が現在時刻より後であるコンテンツホルダＣＨが存在するときは（ステップＳ３３；Ｙ）、当該制御部１１は、上記ステップＳ４０と同様に、そのコンテンツホルダＣＨに対応するインデックス情報ＥＸＸを、ステップＳ３３において存在が確認されたコンテンツホルダＣＨの数だけ、配信元問い合わせメッセージＱrを送信してきたリクエスタＲＱに対して返信し（ステップＳ４０）、第２実施形態に係るルートノードＲＮとしての処理を終了する。
【０１３５】
（Ｂ）リクエスタにおける動作
次に、第２実施形態に係るリクエスタＲＱにおける細部動作について、図１２を用いて説明する。
【０１３６】
第２実施形態に係るリクエスタＲＮの動作として、当該リクエスタＲＮ内の制御部１１は、図１２に示すように、先ず第１実施形態と同様のステップＳ７１乃至Ｓ７３の動作を実行する（図１０参照）。
【０１３７】
そして、配信要求されたコンテンツを蓄積しているコンテンツホルダＣＨに対応するインデックス情報ＥＸＸが得られた場合（図１１（ａ）及び（ｂ）におけるステップＳ４０参照）、当該制御部１１は、その中から、終了予測時刻情報１０１により示される終了予測時刻が最も遅いコンテンツホルダＣＨの検出し、その検出したコンテンツホルダＣＨに接続して（ステップＳ８０）、所望するコンテンツの配信を受ける（ステップＳ７５）。以上の動作により、第２実施形態に係るリクエスタＲＱとしての処理を完了する。
【０１３８】
以上説明した、第２実施形態に係るノードＮとしてのコンテンツホルダＣＨ、ルートノードＲＮ、キャッシュノードＣＮ及びリクエスタＲＱの動作によっても、第１実施形態に係るードＮとしてのコンテンツホルダＣＨ、ルートノードＲＮ、キャッシュノードＣＮ及びリクエスタＲＱの動作と同様の作用効果を奏することができる。
【０１３９】
なお、上述した図６乃至図１２に夫々示すフローチャートに対応するプログラムを、フレキシブルディスク又はハードディスク等の情報記録媒体に記録しておき、又はインターネット等を介して取得して記録しておき、これらを汎用のコンピュータで読み出して実行することにより、当該コンピュータを実施形態に係る制御部１１として機能させることも可能である。
【産業上の利用可能性】
【０１４０】
以上夫々説明したように、本発明はネットワークを介したコンテンツの配信の分野に利用することが可能であり、特にダウンロード形式によるコンテンツの配信の分野に適用すれば特に顕著な効果が得られる。
【図面の簡単な説明】
【０１４１】
【図１】各実施形態に係る配信システムの概要を示す模式図（Ｉ）であり、（ａ）は当該配信システムにおけるＩＤ空間を示す模式図であり、（ｂ）はインデックス情報を例示する図である。
【図２】各実施形態に係る配信システムの概要を示す模式図（II）であり、（ａ）は当該配信システムにおけるメッセージの伝送状態を示す模式図であり、（ｂ）はスパニングツリーとして表した当該メッセージの伝送状態を示す図である。
【図３】本発明の原理を示す図（Ｉ）である。
【図４】本発明の原理を示す図（II）である。
【図５】各実施形態に係るノードの概要構成をコンテンツホルダ等について共通的に示すブロック図である。
【図６】第１実施形態に係るコンテンツホルダにおける動作を示すフローチャートである。
【図７】第１実施形態に係るルートノード及びキャッシュノードにおける全体動作を示すフローチャートである。
【図８】第１実施形態に係るルートノード及びキャッシュノードにおける細部動作を示すフローチャート（Ｉ）であり、（ａ）はキャッシュノードにおける配信元問い合わせメッセージに対応する動作を示すフローチャートであり、（ｂ）はルートノードにおける配信元問い合わせメッセージに対応する動作を示すフローチャートである。
【図９】第１実施形態に係るルートノード及びキャッシュノードにおける全体動作を示すフローチャート（II）であり、（ａ）及び（ｂ）はルートノードにおける登録メッセージに対応する動作を示すフローチャートであり、（ｃ）及び（ｄ）はキャッシュノードにおける登録メッセージに対応する動作を示すフローチャートである。
【図１０】第１実施形態に係るリクエスタにおける動作を示すフローチャートである。
【図１１】第２実施形態に係るルートノード及びキャッシュノードにおける細部動作を示すフローチャートであり、（ａ）はキャッシュノードにおける配信元問い合わせメッセージに対応する動作を示すフローチャートであり、（ｂ）はルートノードにおける配信元問い合わせメッセージに対応する動作を示すフローチャートである。
【図１２】第２実施形態に係るリクエスタにおける動作を示すフローチャートである。
【符号の説明】
【０１４２】
１１    制御部
１２    記憶部
１３    バッファメモリ
１４    デコーダ部
１５    映像処理部
１６    表示部
１７    音声処理部
１８    スピーカ
２０    通信部
２１    入力部
２２    バス
１００    配信開始時刻情報
１０１    終了予測時刻情報
１０２    配信可能数情報
Ｒc、Ｒn    リング
ＥＸ、ＥＸＸ    インデックス情報
ＣＨ、ＣＨ１、ＣＨ２    コンテンツホルダ
ＲＱ、ＲＱ１、ＲＱ２、ＲＱ３    リクエスタ
ＣＴ    コンテンツ
ＲＮ    ルートノード
ＣＮ    キャッシュノード
Ｑp    登録メッセージ
Ｑr    配信元問い合わせメッセージ
Ｎ    ノード
ＨＰ    補助情報
ＲＴ    返信情報
【図１】
2009094856.tif 000003
【図２】
2009094856.tif 000004
【図３】
2009094856.tif 000005
【図４】
2009094856.tif 000006
【図５】
2009094856.tif 000007
【図６】
2009094856.tif 000008
【図７】
2009094856.tif 000009
【図８】
2009094856.tif 000010
【図９】
2009094856.tif 000011
【図１０】
2009094856.tif 000012
【図１１】
2009094856.tif 000013
【図１２】
2009094856.tif 000014