情報処理装置及び情報処理方法並びに情報処理用プログラム
【課題】全体としての消費電力を低下させることが可能な配信システムを提供する。
【解決手段】インデックス情報により示されるコンテンツホルダからコンテンツをダウンロードするに当たり、現在配信中のコンテンツについての配信開始時刻、終了予測時刻、追加の配信可能数及び現配信数をコンテンツホルダから取得し（ステップＳ１４乃至Ｓ１６）、その中から、終了予測時刻が最も遅いコンテンツホルダＣＨを選択して（ステップＳ１７）、コンテンツの配信を受ける（ステップＳ１８）。
【解決手段】インデックス情報により示されるコンテンツホルダからコンテンツをダウンロードするに当たり、現在配信中のコンテンツについての配信開始時刻、終了予測時刻、追加の配信可能数及び現配信数をコンテンツホルダから取得し（ステップＳ１４乃至Ｓ１６）、その中から、終了予測時刻が最も遅いコンテンツホルダＣＨを選択して（ステップＳ１７）、コンテンツの配信を受ける（ステップＳ１８）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置及び情報処理方法並びに情報処理用プログラムの技術分野に属し、より詳細には、ネットワークを介して配信されるべき映画等のコンテンツ（配信情報）を、当該配信用に蓄積する蓄積装置及び当該蓄積装置からの当該配信情報の配信等を行う情報処理装置及び当該情報処理装置における情報処理方法並びに当該情報処理用プログラムの技術分野に属する。
【背景技術】
【０００２】
近年、インターネット等のネットワーク技術は著しく進歩しつつあり、その中で、例えば下記特許文献１に開示されている如きコンテンツ配信システムに関する研究が行われている。
【０００３】
ここで、当該コンテンツ配信システムにおいて、例えば映画等のコンテンツは、その製作者又は管理者（当該製作者又は管理者を、以下単に管理者等と称する）により当該コンテンツ配信システム内のいずれかのコンテンツノードに対してネットワークを介して最初に配信され、当該各コンテンツノードにおいて蓄積／記憶される。なお、上記管理者等によりコンテンツ配信システム内に最初にコンテンツが配信されることを、以下、「コンテンツの投入」と称する。
【０００４】
そして、当該投入されたコンテンツをコンテンツ配信システム内において配信する場合には、当該コンテンツに相当する動画情報等を蓄積／記憶している上記コンテンツノードから、当該コンテンツの視聴を希望する者により操作されるリクエストノードに対して当該動画情報等が配信（伝送）される。
【０００５】
なお、当該「コンテンツノード」の定義付けについては、例えば下記特許文献１の明細書段落番号［００７１］を参照することができ、また当該「リクエストノード」の定義付けについては、例えば下記特許文献１の明細書段落番号［００６４］及び［００６５］を参照することができる。
【０００６】
また、上記コンテンツ配信システムにおいては、一旦投入されたコンテンツは、初期投入の後、最初に投入先となったコンテンツノードだけではなく、例えば分散ハッシュテーブル（いわゆるＤＨＴ（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）変換した後これを増幅器等により増幅して出力する。そして、スピーカ１８は、当該音声処理部１７から出力されたオーディオ信号を音波として出力する。
【００７０】
他方、通信部２０は、ネットワーク８を通じて他のノード装置１との間の情報の通信制御を行なうために用いられる。
【００７１】
更に、入力部２１は、夫々の使用者からの指示を受け付け当該指示に応じた指示信号を制御部１１に出力する。
【００７２】
更にまた、制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４、及び通信部２０はバス２２を介して相互にデータの授受が可能に接続されている。
【００７３】
そして、制御部１１におけるＣＰＵが記憶部１２等に記録された各種プログラムを実行することにより、当該制御部１１が、リクエスタＲＱ、キャッシュノードＣＮ、ルートノードＲＮ、コンテンツホルダＣＨ又はそれら以外の一般のノードＮとしての全体動作を統括制御する。
【００７４】
なお、上記ノードＮが本発明に係る情報処理装置としてのリクエスタＲＱである場合は、制御部１１が本発明に係る検索手段及び配信情報取得手段として機能し、通信部２０が本発明に係る所在情報取得手段、第１送信手段、第２送信手段及び受信手段として機能する。
【００７５】
次に、コンテンツホルダＣＨ及びリクエスタＲＱに分けて、実施形態に係る各ノードＮの動作について説明する。なお、実施形態に係るルートノードＲＮ及びキャッシュノードＣＮとしてのノードＮの動作は、基本的に従来のもの同様であるので、細部の説明は省略する。
【００７６】
（Ａ）コンテンツホルダにおける動作
先ず、実施形態に係るコンテンツホルダＣＨにおける動作について、図４（ａ）を用いて説明する。なお、図４（ａ）は、実施形態に係るコンテンツホルダＣＨにおける動作を示すフローチャートである。
【００７７】
また、実施形態に係るコンテンツホルダＣＨにおける動作のうち、新たなコンテンツの登録動作は従来と同様であるのでその説明を省略する。図４（ａ）に示す動作は、いずれかのリクエスタＲＱから上記インデックス要求メッセージを受信した以降の実施形態に係るコンテンツホルダＣＨの動作のみを示すものである。
【００７８】
先ず、実施形態に係るコンテンツホルダＣＨの動作は、いずれかのメッセージを受信したときに開始される。
【００７９】
次に、当該コンテンツホルダＣＨ内の制御部１１は、図４（ａ）に示すように、その受信したメッセージが上記インデックス要求メッセージであるか、或いはダウンロード要求メッセージであるか、を確認する（ステップＳ１）。
【００８０】
そして、受信したメッセージがインデックス要求メッセージである場合は（ステップＳ１；インデックス要求メッセージ）、当該制御部１１は、従来の上記インデックス情報ＥＸの他に、その時点での上記配信開始時刻情報、終了予測時刻情報、配信可能数情報及び現配信数情報を含む上記追加インデックス情報を生成する。
【００８１】
その後、当該制御部１１は、当該生成された追加インデックス情報を上記インデックス要求メッセージを送信して来たリクエスタＲＱに送信し（ステップＳ２）、実施形態に係るコンテンツホルダＣＨとしての動作を終了する。
【００８２】
一方、ステップＳ１の判定において、受信したメッセージがダウンロード要求メッセージである場合は（ステップＳ１；ダウンロード要求メッセージ）、当該制御部１１は、当該ダウンロード要求メッセージにより示されるコンテンツを、当該ダウンロード要求メッセージを送信して来たリクエスタＲＱにネットワークを介して送信し（ステップＳ３）、実施形態に係るコンテンツホルダＣＨとしての動作を終了する。
【００８３】
（Ｂ）リクエスタにおける動作
次に、実施形態に係るリクエスタＲＱにおける動作について、図４（ｂ）を用いて説明する。なお、図４（ｂ）は実施形態に係るリクエスタＲＱにおける動作を示すフローチャートである。
【００８４】
実施形態に係るリクエスタＲＱの動作は、使用者による所望のコンテンツの配信を要求する旨の操作が当該リクエスタＲＱ内の入力部２１において実行されることにより開始される。
【００８５】
そして、リクエスタＲＱ内の制御部１１は、図４（ｂ）に示すように、当該配信要求されたコンテンツを示すコンテンツＩＤを算出し、配信元問い合わせメッセージＱrを生成する（ステップＳ１１）。
【００８６】
次に、当該制御部１１は、実施形態に係る配信システム内のネットワークにおけるスパニングツリー上でルートノードＲＮに向けて当該生成された配信元問い合わせメッセージＱrを送信し（ステップＳ１２）、その送信結果として所望するインデックス情報ＥＸを、一又は複数リスト形式にて取得する（ステップＳ１３）。
【００８７】
次に、当該制御部１１は、インデックス情報ＥＸを受信した場合、当該受信したインデックス情報ＥＸに夫々対応するコンテンツホルダＣＨに対して、各々、上記インデックス要求メッセージを送信する（ステップＳ１４）。
【００８８】
その後、当該制御部１１は、当該インデックス要求メッセージに対する上記追加インデックス情報の返信を待機する。この間、予め設定された待機時間Ｔを経過しても追加インデックス情報が返信されてこないコンテンツホルダＣＨについては、例えばその電源がオフとされている等の原因によりコンテンツの配信が不可能となっているとして、当該制御部１１は、上記ステップＳ１３において受信したリストの中から削除する（ステップＳ１５）。
【００８９】
次に、インデックス要求メッセージを送信した各コンテンツホルダＣＨから夫々追加インデックス情報が返信されて来たら、当該制御部１１は、当該返信されて来た各追加インデックス情報に含まれている上記配信開始時刻情報、終了予測時刻情報、配信可能数情報及び現配信数情報の内容を確認する。
【００９０】
そして、配信可能数情報が零であるコンテンツホルダＣＨについて、当該制御部１１は、更なるコンテンツの追加配信が不可能であるとして、上記ステップＳ１３において受信したリストの中から削除する（ステップＳ１６）。
【００９１】
そして、当該制御部１１は、当該リストに残っているコンテンツホルダＣＨの中から、終了予測時刻情報により示されるコンテンツ配信の終了予測時刻が最も遅いコンテンツホルダＣＨに接続して（ステップＳ１７）、所望するコンテンツの配信を受ける（ステップＳ１８）。以上の動作により、実施形態に係るリクエスタＲＱとしての処理を完了する。
【００９２】
以上夫々説明したように、実施形態に係るノードＮとしてのコンテンツホルダＣＨ及びリクエスタＲＱの動作によれば、いずれかのコンテンツの配信を最も遅い時刻まで行っていると予想されるコンテンツホルダＣＨから新たなコンテンツの配信を受けるので、現在配信中のコンテンツホルダＣＨから同時並行的に更に新たな配信を受けることができる可能性が高くなることで、新たなコンテンツホルダＣＨにおいて配信処理が開始されることに起因する消費電力の増大等を抑制することができる。特に、リクエスタＲＱにおいて配信を所望するコンテンツ以外の他のコンテンツをも対象として追加インデックス情報が送信されて来るので、全てのコンテンツを対象として、現在配信中且つ終了予測時刻が最も遅いコンテンツホルダＣＨを検索することができる。
【００９３】
従って、配信システム全体としての消費電力を低下させることが可能となる。
【００９４】
また、追加インデックス情報として各コンテンツホルダＣＨから送信されて来る終了予測時刻情報に基づき、配信の終了予測時刻が最も遅いコンテンツを配信しているコンテンツホルダＣＨを検索してダウンロード要求メッセージを送信するので、各コンテンツホルダＣＨにおける配信状態を正確に把握してダウンロード要求メッセージを送信することができる。
【００９５】
更に、予め設定されている待機時間Ｔの間に受信した追加インデックス情報内から検索を実行するので、無駄な待ち時間を要することなく迅速に必要なコンテンツホルダＣＨを検索してコンテンツを取得することができる。
【００９６】
更にまた、追加配信が可能なコンテンツホルダＣＨから検索を実行するので、例えば、更なる配信が不可能なコンテンツホルダＣＨに対してダウンロード要求メッセージを送信する等の無駄な処理を行うことなく迅速に必要なコンテンツホルダＣＨを検索してコンテンツを取得することができる。
【００９７】
なお、上述した実施形態において、終了予測時刻が最も遅いコンテンツホルダＣＨが複数存在するときには、配信可能数情報により示される配信可能数が最も多いコンテンツホルダＣＨから、次に配信が所望されている他の配信情報を配信させるように構成すればよい。
【００９８】
この構成によれば、新たなコンテンツホルダＣＨにおいて配信処理が開始されることに起因する消費電力の増大等を更に抑制することができる。
【００９９】
また、上述した実施形態では、配信状態情報として配信開始時刻情報、終了予測時刻情報、配信可能数情報及び現配信数情報が含まれている追加インデックス情報について説明したが、これ以外に、例えば、コンテンツホルダＣＨにおける記憶部１２の累積稼働時間を示す情報、コンテンツホルダＣＨからリクエスタＲＱまでの間のネットワークにおけるホップ数又は回線の周波数帯域（回線速度）を示す情報、コンテンツホルダＣＨにおける電源スイッチのオン／オフの頻度を示す情報等を、追加インデックス情報に含ませても良い。
【０１００】
そしてリクエスタＲＱの制御部１１では、これらの累積稼働時間情報等を含めて、他のコンテンツを含めた配信を最も遅くまで行っており、且つ最も高速且つ安定的にコンテンツの配信を受け得るコンテンツホルダＣＨを選択して上記ダウンロード要求メッセージを送信する構成とすることができる。
【０１０１】
なお、上記の「高速且つ安定的」か否かの判断に当たっては、例えば、累積稼働時間がより少なく、ホップ数がより少なく、回線の周波数帯域がより広く、或いは電源スイッチのオン／オフの頻度がより少ないコンテンツホルダＣＨを選択することで、高速且つ安定的なコンテンツの配信を受けることができる。
【０１０２】
この構成によれば、より確実に消費電力の増大等を抑制することができる。
【０１０３】
なお、上述した図４（ａ）及び（ｂ）に夫々示すフローチャートに対応するプログラムを、フレキシブルディスク又はハードディスク等の情報記録媒体に記録しておき、又はインターネット等を介して取得して記録しておき、これらを汎用のコンピュータで読み出して実行することにより、当該コンピュータを実施形態に係る制御部１１として機能させることも可能である。
【産業上の利用可能性】
【０１０４】
以上夫々説明したように、本発明はネットワークを介したコンテンツの配信の分野に利用することが可能であり、特にダウンロード形式によるコンテンツの配信の分野に適用すれば特に顕著な効果が得られる。
【図面の簡単な説明】
【０１０５】
【図１】各実施形態に係る配信システムの概要を示す模式図（Ｉ）であり、（ａ）は当該配信システムにおけるＩＤ空間を示す模式図であり、（ｂ）はインデックス情報を例示する図である。
【図２】各実施形態に係る配信システムの概要を示す模式図（II）であり、（ａ）は当該配信システムにおけるメッセージの伝送状態を示す模式図であり、（ｂ）はスパニングツリーとして表した当該メッセージの伝送状態を示す図である。
【図３】実施形態に係るノードの概要構成をコンテンツホルダ等について共通的に示すブロック図である。
【図４】実施形態に係るコンテンツホルダ及びリクエスタにおける動作を示すフローチャートであり（ａ）は当該コンテンツホルダにおける動作を示すフローチャートであり、（ｂ）は当該リクエスタにおける動作を示すフローチャートである。
【符号の説明】
【０１０６】
１１ 制御部
１２ 記憶部
１３ バッファメモリ
１４ デコーダ部
１５ 映像処理部
１６ 表示部
１７ 音声処理部
１８ スピーカ
２０ 通信部
２１ 入力部
２２ バス
Ｒc、Ｒn リング
ＥＸ インデックス情報
ＣＨ コンテンツホルダ
ＲＱ、ＲＱ１、ＲＱ２、ＲＱ３ リクエスタ
ＲＮ ルートノード
ＣＮ キャッシュノード
Ｑp 登録メッセージ
Ｑr 配信元問い合わせメッセージ
Ｎ ノード
ＲＴ 返信情報
【技術分野】
【０００１】
本発明は、情報処理装置及び情報処理方法並びに情報処理用プログラムの技術分野に属し、より詳細には、ネットワークを介して配信されるべき映画等のコンテンツ（配信情報）を、当該配信用に蓄積する蓄積装置及び当該蓄積装置からの当該配信情報の配信等を行う情報処理装置及び当該情報処理装置における情報処理方法並びに当該情報処理用プログラムの技術分野に属する。
【背景技術】
【０００２】
近年、インターネット等のネットワーク技術は著しく進歩しつつあり、その中で、例えば下記特許文献１に開示されている如きコンテンツ配信システムに関する研究が行われている。
【０００３】
ここで、当該コンテンツ配信システムにおいて、例えば映画等のコンテンツは、その製作者又は管理者（当該製作者又は管理者を、以下単に管理者等と称する）により当該コンテンツ配信システム内のいずれかのコンテンツノードに対してネットワークを介して最初に配信され、当該各コンテンツノードにおいて蓄積／記憶される。なお、上記管理者等によりコンテンツ配信システム内に最初にコンテンツが配信されることを、以下、「コンテンツの投入」と称する。
【０００４】
そして、当該投入されたコンテンツをコンテンツ配信システム内において配信する場合には、当該コンテンツに相当する動画情報等を蓄積／記憶している上記コンテンツノードから、当該コンテンツの視聴を希望する者により操作されるリクエストノードに対して当該動画情報等が配信（伝送）される。
【０００５】
なお、当該「コンテンツノード」の定義付けについては、例えば下記特許文献１の明細書段落番号［００７１］を参照することができ、また当該「リクエストノード」の定義付けについては、例えば下記特許文献１の明細書段落番号［００６４］及び［００６５］を参照することができる。
【０００６】
また、上記コンテンツ配信システムにおいては、一旦投入されたコンテンツは、初期投入の後、最初に投入先となったコンテンツノードだけではなく、例えば分散ハッシュテーブル（いわゆるＤＨＴ（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）変換した後これを増幅器等により増幅して出力する。そして、スピーカ１８は、当該音声処理部１７から出力されたオーディオ信号を音波として出力する。
【００７０】
他方、通信部２０は、ネットワーク８を通じて他のノード装置１との間の情報の通信制御を行なうために用いられる。
【００７１】
更に、入力部２１は、夫々の使用者からの指示を受け付け当該指示に応じた指示信号を制御部１１に出力する。
【００７２】
更にまた、制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４、及び通信部２０はバス２２を介して相互にデータの授受が可能に接続されている。
【００７３】
そして、制御部１１におけるＣＰＵが記憶部１２等に記録された各種プログラムを実行することにより、当該制御部１１が、リクエスタＲＱ、キャッシュノードＣＮ、ルートノードＲＮ、コンテンツホルダＣＨ又はそれら以外の一般のノードＮとしての全体動作を統括制御する。
【００７４】
なお、上記ノードＮが本発明に係る情報処理装置としてのリクエスタＲＱである場合は、制御部１１が本発明に係る検索手段及び配信情報取得手段として機能し、通信部２０が本発明に係る所在情報取得手段、第１送信手段、第２送信手段及び受信手段として機能する。
【００７５】
次に、コンテンツホルダＣＨ及びリクエスタＲＱに分けて、実施形態に係る各ノードＮの動作について説明する。なお、実施形態に係るルートノードＲＮ及びキャッシュノードＣＮとしてのノードＮの動作は、基本的に従来のもの同様であるので、細部の説明は省略する。
【００７６】
（Ａ）コンテンツホルダにおける動作
先ず、実施形態に係るコンテンツホルダＣＨにおける動作について、図４（ａ）を用いて説明する。なお、図４（ａ）は、実施形態に係るコンテンツホルダＣＨにおける動作を示すフローチャートである。
【００７７】
また、実施形態に係るコンテンツホルダＣＨにおける動作のうち、新たなコンテンツの登録動作は従来と同様であるのでその説明を省略する。図４（ａ）に示す動作は、いずれかのリクエスタＲＱから上記インデックス要求メッセージを受信した以降の実施形態に係るコンテンツホルダＣＨの動作のみを示すものである。
【００７８】
先ず、実施形態に係るコンテンツホルダＣＨの動作は、いずれかのメッセージを受信したときに開始される。
【００７９】
次に、当該コンテンツホルダＣＨ内の制御部１１は、図４（ａ）に示すように、その受信したメッセージが上記インデックス要求メッセージであるか、或いはダウンロード要求メッセージであるか、を確認する（ステップＳ１）。
【００８０】
そして、受信したメッセージがインデックス要求メッセージである場合は（ステップＳ１；インデックス要求メッセージ）、当該制御部１１は、従来の上記インデックス情報ＥＸの他に、その時点での上記配信開始時刻情報、終了予測時刻情報、配信可能数情報及び現配信数情報を含む上記追加インデックス情報を生成する。
【００８１】
その後、当該制御部１１は、当該生成された追加インデックス情報を上記インデックス要求メッセージを送信して来たリクエスタＲＱに送信し（ステップＳ２）、実施形態に係るコンテンツホルダＣＨとしての動作を終了する。
【００８２】
一方、ステップＳ１の判定において、受信したメッセージがダウンロード要求メッセージである場合は（ステップＳ１；ダウンロード要求メッセージ）、当該制御部１１は、当該ダウンロード要求メッセージにより示されるコンテンツを、当該ダウンロード要求メッセージを送信して来たリクエスタＲＱにネットワークを介して送信し（ステップＳ３）、実施形態に係るコンテンツホルダＣＨとしての動作を終了する。
【００８３】
（Ｂ）リクエスタにおける動作
次に、実施形態に係るリクエスタＲＱにおける動作について、図４（ｂ）を用いて説明する。なお、図４（ｂ）は実施形態に係るリクエスタＲＱにおける動作を示すフローチャートである。
【００８４】
実施形態に係るリクエスタＲＱの動作は、使用者による所望のコンテンツの配信を要求する旨の操作が当該リクエスタＲＱ内の入力部２１において実行されることにより開始される。
【００８５】
そして、リクエスタＲＱ内の制御部１１は、図４（ｂ）に示すように、当該配信要求されたコンテンツを示すコンテンツＩＤを算出し、配信元問い合わせメッセージＱrを生成する（ステップＳ１１）。
【００８６】
次に、当該制御部１１は、実施形態に係る配信システム内のネットワークにおけるスパニングツリー上でルートノードＲＮに向けて当該生成された配信元問い合わせメッセージＱrを送信し（ステップＳ１２）、その送信結果として所望するインデックス情報ＥＸを、一又は複数リスト形式にて取得する（ステップＳ１３）。
【００８７】
次に、当該制御部１１は、インデックス情報ＥＸを受信した場合、当該受信したインデックス情報ＥＸに夫々対応するコンテンツホルダＣＨに対して、各々、上記インデックス要求メッセージを送信する（ステップＳ１４）。
【００８８】
その後、当該制御部１１は、当該インデックス要求メッセージに対する上記追加インデックス情報の返信を待機する。この間、予め設定された待機時間Ｔを経過しても追加インデックス情報が返信されてこないコンテンツホルダＣＨについては、例えばその電源がオフとされている等の原因によりコンテンツの配信が不可能となっているとして、当該制御部１１は、上記ステップＳ１３において受信したリストの中から削除する（ステップＳ１５）。
【００８９】
次に、インデックス要求メッセージを送信した各コンテンツホルダＣＨから夫々追加インデックス情報が返信されて来たら、当該制御部１１は、当該返信されて来た各追加インデックス情報に含まれている上記配信開始時刻情報、終了予測時刻情報、配信可能数情報及び現配信数情報の内容を確認する。
【００９０】
そして、配信可能数情報が零であるコンテンツホルダＣＨについて、当該制御部１１は、更なるコンテンツの追加配信が不可能であるとして、上記ステップＳ１３において受信したリストの中から削除する（ステップＳ１６）。
【００９１】
そして、当該制御部１１は、当該リストに残っているコンテンツホルダＣＨの中から、終了予測時刻情報により示されるコンテンツ配信の終了予測時刻が最も遅いコンテンツホルダＣＨに接続して（ステップＳ１７）、所望するコンテンツの配信を受ける（ステップＳ１８）。以上の動作により、実施形態に係るリクエスタＲＱとしての処理を完了する。
【００９２】
以上夫々説明したように、実施形態に係るノードＮとしてのコンテンツホルダＣＨ及びリクエスタＲＱの動作によれば、いずれかのコンテンツの配信を最も遅い時刻まで行っていると予想されるコンテンツホルダＣＨから新たなコンテンツの配信を受けるので、現在配信中のコンテンツホルダＣＨから同時並行的に更に新たな配信を受けることができる可能性が高くなることで、新たなコンテンツホルダＣＨにおいて配信処理が開始されることに起因する消費電力の増大等を抑制することができる。特に、リクエスタＲＱにおいて配信を所望するコンテンツ以外の他のコンテンツをも対象として追加インデックス情報が送信されて来るので、全てのコンテンツを対象として、現在配信中且つ終了予測時刻が最も遅いコンテンツホルダＣＨを検索することができる。
【００９３】
従って、配信システム全体としての消費電力を低下させることが可能となる。
【００９４】
また、追加インデックス情報として各コンテンツホルダＣＨから送信されて来る終了予測時刻情報に基づき、配信の終了予測時刻が最も遅いコンテンツを配信しているコンテンツホルダＣＨを検索してダウンロード要求メッセージを送信するので、各コンテンツホルダＣＨにおける配信状態を正確に把握してダウンロード要求メッセージを送信することができる。
【００９５】
更に、予め設定されている待機時間Ｔの間に受信した追加インデックス情報内から検索を実行するので、無駄な待ち時間を要することなく迅速に必要なコンテンツホルダＣＨを検索してコンテンツを取得することができる。
【００９６】
更にまた、追加配信が可能なコンテンツホルダＣＨから検索を実行するので、例えば、更なる配信が不可能なコンテンツホルダＣＨに対してダウンロード要求メッセージを送信する等の無駄な処理を行うことなく迅速に必要なコンテンツホルダＣＨを検索してコンテンツを取得することができる。
【００９７】
なお、上述した実施形態において、終了予測時刻が最も遅いコンテンツホルダＣＨが複数存在するときには、配信可能数情報により示される配信可能数が最も多いコンテンツホルダＣＨから、次に配信が所望されている他の配信情報を配信させるように構成すればよい。
【００９８】
この構成によれば、新たなコンテンツホルダＣＨにおいて配信処理が開始されることに起因する消費電力の増大等を更に抑制することができる。
【００９９】
また、上述した実施形態では、配信状態情報として配信開始時刻情報、終了予測時刻情報、配信可能数情報及び現配信数情報が含まれている追加インデックス情報について説明したが、これ以外に、例えば、コンテンツホルダＣＨにおける記憶部１２の累積稼働時間を示す情報、コンテンツホルダＣＨからリクエスタＲＱまでの間のネットワークにおけるホップ数又は回線の周波数帯域（回線速度）を示す情報、コンテンツホルダＣＨにおける電源スイッチのオン／オフの頻度を示す情報等を、追加インデックス情報に含ませても良い。
【０１００】
そしてリクエスタＲＱの制御部１１では、これらの累積稼働時間情報等を含めて、他のコンテンツを含めた配信を最も遅くまで行っており、且つ最も高速且つ安定的にコンテンツの配信を受け得るコンテンツホルダＣＨを選択して上記ダウンロード要求メッセージを送信する構成とすることができる。
【０１０１】
なお、上記の「高速且つ安定的」か否かの判断に当たっては、例えば、累積稼働時間がより少なく、ホップ数がより少なく、回線の周波数帯域がより広く、或いは電源スイッチのオン／オフの頻度がより少ないコンテンツホルダＣＨを選択することで、高速且つ安定的なコンテンツの配信を受けることができる。
【０１０２】
この構成によれば、より確実に消費電力の増大等を抑制することができる。
【０１０３】
なお、上述した図４（ａ）及び（ｂ）に夫々示すフローチャートに対応するプログラムを、フレキシブルディスク又はハードディスク等の情報記録媒体に記録しておき、又はインターネット等を介して取得して記録しておき、これらを汎用のコンピュータで読み出して実行することにより、当該コンピュータを実施形態に係る制御部１１として機能させることも可能である。
【産業上の利用可能性】
【０１０４】
以上夫々説明したように、本発明はネットワークを介したコンテンツの配信の分野に利用することが可能であり、特にダウンロード形式によるコンテンツの配信の分野に適用すれば特に顕著な効果が得られる。
【図面の簡単な説明】
【０１０５】
【図１】各実施形態に係る配信システムの概要を示す模式図（Ｉ）であり、（ａ）は当該配信システムにおけるＩＤ空間を示す模式図であり、（ｂ）はインデックス情報を例示する図である。
【図２】各実施形態に係る配信システムの概要を示す模式図（II）であり、（ａ）は当該配信システムにおけるメッセージの伝送状態を示す模式図であり、（ｂ）はスパニングツリーとして表した当該メッセージの伝送状態を示す図である。
【図３】実施形態に係るノードの概要構成をコンテンツホルダ等について共通的に示すブロック図である。
【図４】実施形態に係るコンテンツホルダ及びリクエスタにおける動作を示すフローチャートであり（ａ）は当該コンテンツホルダにおける動作を示すフローチャートであり、（ｂ）は当該リクエスタにおける動作を示すフローチャートである。
【符号の説明】
【０１０６】
１１ 制御部
１２ 記憶部
１３ バッファメモリ
１４ デコーダ部
１５ 映像処理部
１６ 表示部
１７ 音声処理部
１８ スピーカ
２０ 通信部
２１ 入力部
２２ バス
Ｒc、Ｒn リング
ＥＸ インデックス情報
ＣＨ コンテンツホルダ
ＲＱ、ＲＱ１、ＲＱ２、ＲＱ３ リクエスタ
ＲＮ ルートノード
ＣＮ キャッシュノード
Ｑp 登録メッセージ
Ｑr 配信元問い合わせメッセージ
Ｎ ノード
ＲＴ 返信情報
【特許請求の範囲】
【請求項１】
ネットワークを介して複数の情報処理装置が接続されてなるネットワークシステムに含まれる当該情報処理装置において、
配信用の配信情報を蓄積している前記情報処理装置である蓄積装置の所在を示す所在情報を取得する所在情報取得手段と、
前記取得した所在情報に対応する各前記蓄積装置に対して、前記配信状態を問い合わせるための問い合わせ情報を送信する第１送信手段と、
各前記蓄積装置における前記配信状態を示す配信状態情報であって前記送信された問い合わせ情報に対応して各前記蓄積装置から送信されて来る配信状態情報を受信する受信手段と、
前記受信した配信状態情報に基づき、各前記蓄積装置内に蓄積されている前記配信情報の配信を最も遅い時刻まで行うと予測される前記蓄積装置を検索する検索手段と、
前記検索された蓄積装置に対して、前記配信情報の配信を要求する配信要求情報を送信する第２送信手段と、
前記送信された配信要求情報を受信した前記蓄積装置から当該配信要求情報に対応して送信されて来る前記配信情報を取得する配信情報取得手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
請求項１に記載の情報処理装置において、
前記配信状態情報には、当該配信状態情報が対応する前記蓄積装置に蓄積されている各前記配信情報についての配信完了予定時刻を示す予定時刻情報が含まれており、
前記検索手段は、複数の前記蓄積装置の中から、前記配信完了予定時刻が最も遅い前記予定時刻情報を送信して来た前記蓄積装置を検索することを特徴とする情報処理装置。
【請求項３】
請求項１又は２に記載の情報処理装置において、
前記検索手段は、予め設定された待機時間の間に前記受信手段が受信した前記配信状態情報に対して検索を実行することを特徴とする情報処理装置。
【請求項４】
請求項１から３のいずれか一項に記載の情報処理装置において、
前記配信状態情報には、当該配信状態情報が対応する前記蓄積装置において、追加して配信が可能な前記配信情報の数を示す配信可能数情報が含まれており、
前記検索手段は、前記追加配信が可能な配信情報の数が零より大きい配信可能数を示す前記配信可能数情報を送信して来た前記蓄積装置に対して検索を実行することを特徴とする情報処理装置。
【請求項５】
ネットワークを介して複数の情報処理装置が接続されてなるネットワークシステムに含まれる当該情報処理装置において実行される情報記録方法において、
配信用の配信情報を蓄積している前記情報処理装置である蓄積装置の所在を示す所在情報を取得する所在情報取得工程と、
前記取得した所在情報に対応する各前記蓄積装置に対して、前記配信状態を問い合わせるための問い合わせ情報を送信する第１送信工程と、
各前記蓄積装置における前記配信状態を示す配信状態情報であって前記送信された問い合わせ情報に対応して各前記蓄積装置から送信されて来る配信状態情報を受信する受信工程と、
前記受信した配信状態情報に基づき、各前記蓄積装置内に蓄積されている前記配信情報の配信を最も遅い時刻まで行うと予測される前記蓄積装置を検索する検索工程と、
前記検索された蓄積装置に対して、前記配信情報の配信を要求する配信要求情報を送信する第２送信工程と、
前記送信された配信要求情報を受信した前記蓄積装置から当該配信要求情報に対応して送信されて来る前記配信情報を取得する配信情報取得工程と、
を含むことを特徴とする情報処理方法。
【請求項６】
コンピュータを、請求項１から４のいずれか一項に記載の情報処理装置として機能させることを特徴とする情報処理用プログラム。
【請求項１】
ネットワークを介して複数の情報処理装置が接続されてなるネットワークシステムに含まれる当該情報処理装置において、
配信用の配信情報を蓄積している前記情報処理装置である蓄積装置の所在を示す所在情報を取得する所在情報取得手段と、
前記取得した所在情報に対応する各前記蓄積装置に対して、前記配信状態を問い合わせるための問い合わせ情報を送信する第１送信手段と、
各前記蓄積装置における前記配信状態を示す配信状態情報であって前記送信された問い合わせ情報に対応して各前記蓄積装置から送信されて来る配信状態情報を受信する受信手段と、
前記受信した配信状態情報に基づき、各前記蓄積装置内に蓄積されている前記配信情報の配信を最も遅い時刻まで行うと予測される前記蓄積装置を検索する検索手段と、
前記検索された蓄積装置に対して、前記配信情報の配信を要求する配信要求情報を送信する第２送信手段と、
前記送信された配信要求情報を受信した前記蓄積装置から当該配信要求情報に対応して送信されて来る前記配信情報を取得する配信情報取得手段と、
を備えることを特徴とする情報処理装置。
【請求項２】
請求項１に記載の情報処理装置において、
前記配信状態情報には、当該配信状態情報が対応する前記蓄積装置に蓄積されている各前記配信情報についての配信完了予定時刻を示す予定時刻情報が含まれており、
前記検索手段は、複数の前記蓄積装置の中から、前記配信完了予定時刻が最も遅い前記予定時刻情報を送信して来た前記蓄積装置を検索することを特徴とする情報処理装置。
【請求項３】
請求項１又は２に記載の情報処理装置において、
前記検索手段は、予め設定された待機時間の間に前記受信手段が受信した前記配信状態情報に対して検索を実行することを特徴とする情報処理装置。
【請求項４】
請求項１から３のいずれか一項に記載の情報処理装置において、
前記配信状態情報には、当該配信状態情報が対応する前記蓄積装置において、追加して配信が可能な前記配信情報の数を示す配信可能数情報が含まれており、
前記検索手段は、前記追加配信が可能な配信情報の数が零より大きい配信可能数を示す前記配信可能数情報を送信して来た前記蓄積装置に対して検索を実行することを特徴とする情報処理装置。
【請求項５】
ネットワークを介して複数の情報処理装置が接続されてなるネットワークシステムに含まれる当該情報処理装置において実行される情報記録方法において、
配信用の配信情報を蓄積している前記情報処理装置である蓄積装置の所在を示す所在情報を取得する所在情報取得工程と、
前記取得した所在情報に対応する各前記蓄積装置に対して、前記配信状態を問い合わせるための問い合わせ情報を送信する第１送信工程と、
各前記蓄積装置における前記配信状態を示す配信状態情報であって前記送信された問い合わせ情報に対応して各前記蓄積装置から送信されて来る配信状態情報を受信する受信工程と、
前記受信した配信状態情報に基づき、各前記蓄積装置内に蓄積されている前記配信情報の配信を最も遅い時刻まで行うと予測される前記蓄積装置を検索する検索工程と、
前記検索された蓄積装置に対して、前記配信情報の配信を要求する配信要求情報を送信する第２送信工程と、
前記送信された配信要求情報を受信した前記蓄積装置から当該配信要求情報に対応して送信されて来る前記配信情報を取得する配信情報取得工程と、
を含むことを特徴とする情報処理方法。
【請求項６】
コンピュータを、請求項１から４のいずれか一項に記載の情報処理装置として機能させることを特徴とする情報処理用プログラム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２００９−９３４６０（Ｐ２００９−９３４６０Ａ）
【公開日】平成２１年４月３０日（２００９．４．３０）
【国際特許分類】
【出願番号】特願２００７−２６４２１４（Ｐ２００７−２６４２１４）
【出願日】平成１９年１０月１０日（２００７．１０．１０）
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【Ｆターム（参考）】
【公開日】平成２１年４月３０日（２００９．４．３０）
【国際特許分類】
【出願日】平成１９年１０月１０日（２００７．１０．１０）
【出願人】（０００００５２６７）ブラザー工業株式会社 (13,856)
【Ｆターム（参考）】
[ Back to top ]