JP4998196B2 - コンテンツ取得装置、プログラム、コンテンツ取得方法、およびコンテンツ取得システム - Google Patents

Description

本発明は、コンテンツ取得装置、プログラム、コンテンツ取得方法、およびコンテンツ取得システムに関する。

近年、ＲＳＳ（Ｒｉｃｈ Ｓｉｔｅ Ｓｕｍｍａｒｙ）フィードによりコンテンツファイルをダウンロードする方式が広く普及している。具体的には、ＲＳＳフィードに含まれる〈ｅｎｃｌｏｓｕｒｅ）要素に対象となるコンテンツファイルのＵＲＬがＨＴＴＰ等で記載されており、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）や携帯電話などの情報処理装置が上記ＵＲＬに基づいてコンテンツファイルをダウンロードすることができる。このようなＲＳＳフィードを利用したコンテンツファイルのダウンロードについては、例えば特許文献１に記載されている。

特開２００７−１６６３６３号公報

ここで、コンテンツファイルがダウンロードされてからコンテンツが再生されるため、ＨＤ（Ｈｉｇｈ Ｄｉｆｉｎｉｔｉｏｎ）ビデオファイル等の非常に大きなコンテンツファイルの場合、ネットワークの状況により、再生が開始されるまでに時間がかかる場合が多い。例えば、Ｐ２Ｐファイル共有型のプロトコルによりコンテンツファイルの取得効率を上げることもできるが、この場合もコンテンツファイル全体が一括して取得されてからでないと再生が開始されない。

これに対し、コンテンツファイルを複数のファイルセグメント（分割データ）に分割し、各ファイルセグメントのＵＲＬをＲＳＳフィードに記載しておけば、情報処理装置が複数のＵＲＬから並列的にファイルセグメントを取得できるため取得速度の迅速化を図り得る。

しかし、ファイルセグメントの数が多くなると、ＲＳＳフィードの〈ｅｎｃｌｏｓｕｒｅ）要素の記載が冗長となり、ＲＳＳフィードを提供するＲＳＳディレクトリサーバやＲＳＳマルチキャストサーバなどの処理負荷が増大してしまう。また、ＲＳＳフィードを受信する情報処理装置（ＲＳＳフィードリーダ）のリソースを圧迫してしまうという問題も生じる。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、簡略化された例えばＲＳＳフィードなどの第１のコンテンツ情報の記載に基づいて分割データを取得することが可能な、新規かつ改良されたコンテンツ取得装置、プログラム、コンテンツ取得方法、およびコンテンツ取得システムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、第１のコンテンツデータを分割して得られた所定数の分割データのうちのいずれかを１または２以上のコンテンツ記憶装置が記憶しており、前記所定数の値を示す分割数情報と、前記第１のコンテンツデータに応じたデータ情報と、を含む第１のコンテンツ情報を受信する受信部と、前記分割数情報と前記データ情報とに基づき、前記分割データの各々を示す分割データ指定情報を前記分割データごとに生成する生成部と、前記分割データ指定情報に従って前記１または２以上のコンテンツ記憶装置から前記分割データを取得する取得部と、を備えるコンテンツ取得装置が提供される。

かかる構成においては、生成部が、第１のコンテンツ情報に基づいて各分割データを示す分割データ指定情報を複数生成することができる。そして、取得部が分割データ指定情報に従って１または２以上のコンテンツ記憶装置から分割データを取得する。したがって、当該コンテンツ取得装置によれば、第１のコンテンツ情報に、各分割データを示す分割データ指定情報が含まれていなくても、分割データを取得することができる。その結果、第１のコンテンツ情報の情報量を抑制し、第１のコンテンツ情報が煩雑化することを防止できる。

前記分割データ指定情報に基づいて特定される所在情報記憶装置には前記分割データの所在を示す所在情報が記憶されており、前記取得部は、前記分割データ指定情報に基づいて特定した所在情報記憶装置から前記分割データの所在情報を取得し、該所在情報の示すコンテンツ記憶装置から前記分割データを取得してもよい。

ここで、分割データを記憶しているコンテンツ記憶装置は追加、または減少して変化する場合がある。このため、分割データ指定情報に分割データの所在情報が記載される場合、分割データ指定情報の示す所在から分割データを取得できない、または分割データ指定情報の示す所在が好適な分割データの取得元でないことなどが想定される。そこで、上記のように分割データ指定情報を、分割データの所在情報を記憶する所在情報記憶装置を特定可能なように構成することにより、取得部がより適切に分割データを取得することができる。

また、当該コンテンツ取得装置は、前記取得部により取得された分割データが記録される記憶部と、前記分割データの前記記憶部における所在を示す所在情報を、前記分割データ指定情報に基づいて特定される所在情報記憶装置に送信する送信部とをさらに備えてもよい。

かかる構成においては、送信部から分割データの記憶部における所在情報を受信した所在情報記憶装置が、該所在情報を分割データの所在情報として新たに追加することができる。その結果、他のコンテンツ取得装置が、同一の分割データであってもより多種の所在から分散的に取得することが可能となる。

前記取得部は、前記分割データ指定情報に基づいて特定した所在情報記憶装置から前記分割データの所在情報を複数取得した場合、複数の所在情報のうちから１の所在情報を選択し、選択した所在情報の示すコンテンツ記憶装置から前記分割データを取得してもよい。かかる構成においては、取得部は、例えばネットワークの混雑状況等に応じ、取得し易いコンテンツ記憶装置から選択的に分割データを取得することにより、分割データの取得効率の向上を図ることができる。

前記所在情報記憶装置には、前記所在情報記憶装置の固有識別情報のハッシュ値に応じたハッシュ値の管理範囲が割当てられており、前記分割データの所在情報の各々は、前記分割データを示す分割データ指定情報のハッシュ値を管理範囲に含む所在情報記憶装置に分散記憶されていてもよい。かかる構成においては、分割データの所在情報が複数の所在情報記憶装置に分散して記憶されるため、ある所在情報記憶装置に分割データの所在情報の問い合わせが集中してしまう場合を抑制できる。

前記生成部は、既知の順序付けられた要素群に含まれる要素のうちで、前記分割数情報の示す値に応じた範囲内に順序付けられている要素の各々を前記データ情報に付加することにより所定数の前記分割データ指定情報を生成してもよい。かかる構成によれば、生成部は第１のコンテンツ情報から容易に分割データ指定情報を生成することができる。

受信部は、前記第１のコンテンツ情報と形式が異なり、第２のコンテンツデータを示す第２のコンテンツ情報をさらに受信し、前記取得部は、前記第２のコンテンツ情報に従って特定のコンテンツ記憶装置から前記第２のコンテンツデータを取得してもよい。かかる構成においては、取得部は、分割データだけでなく、分割されていない第２のコンテンツデータも特定のコンテンツ記憶装置から取得することができる。

前記第１のコンテンツ指定情報はＲＳＳフィードに含まれてもよい。

また、上記課題を解決するために、本発明の別の観点によれば、コンピュータを、第１のコンテンツデータを分割して得られた所定数の分割データのうちのいずれかを１または２以上のコンテンツ記憶装置が記憶しており、前記所定数の値を示す分割数情報と、前記第１のコンテンツデータに応じたデータ情報と、を含む第１のコンテンツ指定情報を受信する受信部と、前記分割数情報と前記データ情報とに基づき、前記分割データの各々を示す分割データ指定情報を前記分割データごとに生成する生成部と、前記分割データ指定情報に従って前記１または２以上のコンテンツ記憶装置から前記分割データを取得する取得部と、を備えるコンテンツ取得装置として機能させるためのプログラムが提供される。

かかるプログラムは、例えばＣＰＵ、ＲＯＭまたはＲＡＭなどを含むコンピュータのハードウェア資源に、上記のような受信部、生成部および取得部の機能を実行させることができる。すなわち、当該プログラムを用いるコンピュータを、上述のコンテンツ取得装置として機能させることが可能である。

また、上記課題を解決するために、本発明の別の観点によれば、コンテンツ取得装置において実行されるコンテンツ取得方法であって、第１のコンテンツデータを分割して得られた所定数の分割データのうちのいずれかを１または２以上のコンテンツ記憶装置が記憶しており、前記所定数の値を示す分割数情報と、前記第１のコンテンツデータに応じたデータ情報と、を含む第１のコンテンツ指定情報を受信するステップと、前記分割数情報と前記データ情報とに基づき、前記分割データの各々を示す分割データ指定情報を前記分割データごとに生成するステップと、前記分割データ指定情報に従って前記１または２以上のコンテンツ記憶装置から前記所定数の分割データを取得するステップと、を含むコンテンツ取得方法が提供される。

また、上記課題を解決するために、本発明の別の観点によれば、１または２以上のコンテンツ記憶装置と、コンテンツ取得装置とを含むコンテンツ取得システムが提供される。前記コンテンツ記憶装置は、第１のコンテンツデータを分割して所定数の分割データを得る分割部と、前記分割データの各々を記憶する分割データ記憶部と、前記所定数の値を示す分割数情報と、前記第１のコンテンツデータに応じたデータ情報と、を含む第１のコンテンツ指定情報を送信する通信部とを備えてもよい。前記コンテンツ取得装置は、前記第１のコンテンツ指定情報を受信する受信部と、前記分割数情報と前記データ情報とに基づき、前記分割データの各々を示す分割データ指定情報を前記分割データごとに生成する生成部と、前記分割データ指定情報に従って前記１または２以上のコンテンツ記憶装置から前記分割データを取得する取得部と、を備えてもよい。

以上説明したように本発明にかかるコンテンツ取得装置、プログラム、コンテンツ取得方法、およびコンテンツ取得システムによれば、簡略化された例えばＲＳＳフィードなどの第１のコンテンツ情報の記載に基づいて分割データを取得することができる。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

また、以下の順序にしたがって当該「発明を実施するための最良の形態」を説明する。
〔１〕本実施形態にかかるコンテンツ取得システムの概要
〔２〕本実施形態の目的
〔２−１〕本実施形態に関連するコンテンツ取得システム
〔２−２〕本実施形態の目的
〔３〕コンテンツ取得システムの詳細な説明
〔３−１〕ノードのハードウェア構成
〔３−２〕ノードの機能
〔３−３〕コンテンツ取得システムの動作
〔４〕まとめ

〔１〕本実施形態にかかるコンテンツ取得システムの概要
まず、図１を参照して、本実施形態にかかるコンテンツ取得システム１の概要を説明する。

図１は、本実施形態にかかるコンテンツ取得システム１の構成を示した説明図である。図１に示したように、当該コンテンツ取得システム１は、ノード２０Ａ、２０Ｂ、２０Ｃ、２０Ｄ、および２０Ｘなどの複数のノードと、ノードアドレス解決サーバ１４とを含む。なお、本明細書においては、ノード２０Ａ、２０Ｂ、２０Ｃ、２０Ｄ、および２０Ｘなどの各ノードを区別する必要が無い場合、単にノード２０と称する。他の符号についても同様である。

各ノード２０は、コンテンツの実データであるコンテンツデータ（ファイル）、またはコンテンツデータをチャンク化（分割）して得られるファイルセグメント（分割データ）を記憶している。また、各ノード２０は、所定のファイルセグメントが記憶されている所在を示す所在情報としてのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を記憶している。すなわち、各ノード２０は、コンテンツ記憶装置としての機能、および所在情報記憶装置としての機能を有する。

さらに、各ノード２０は、あるコンテンツを示す情報が〈ｅｎｃｌｏｓｕｒｅ）要素に記載されたＲＳＳフィードを受信し、通信網１２を介し、他のノード２０に記憶されている該コンテンツのファイルセグメントを取得するコンテンツ取得装置としての機能も有する。

概略的に説明すると、各ノード２０は、〈ｅｎｃｌｏｓｕｒｅ）要素に記載された情報に基づき、あるコンテンツの各ファイルセグメントのＵＲＬを記憶している１または２以上のノード２０を、ノードアドレス解決サーバ１４と協働して特定する。ここで、ノードアドレス解決サーバ１４は、各ノード２０を識別する固有識別情報としてのノードＩＤと、各ノード２０にネットワーク上で割り当てられてネットワークアドレスとを対応付けて記憶している。そして、ノードアドレス解決サーバ１４は、あるノードＩＤを有するノード２０のネットワークアドレスの解決を依頼されると、該ノードＩＤと対応付けて記憶しているネットワークアドレスを送信する。

各ノード２０は、あるコンテンツの各ファイルセグメントのＵＲＬを記憶している１または２以上のノード２０を特定すると、各ノード２０から各ファイルセグメントのＵＲＬを取得する。そして、各ノード２０は、各ファイルセグメントのＵＲＬに基づいてファイルセグメントを取得することができる。

なお、図１においては、ノード２０の一例としてノートＰＣを示しているが、ノード２０はノートＰＣに限定されず、例えば、ＰＣ、家庭用映像処理装置（ＤＶＤレコーダ、ビデオデッキなど）、携帯電話、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）、携帯用音楽再生装置、携帯用映像処理装置、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、家庭用ゲーム機器、携帯用ゲーム機器、家電機器などの情報処理装置であってもよい。

また、コンテンツとは、音楽、講演およびラジオ番組などの音楽データや、映画、テレビジョン番組、ビデオプログラム、写真、文書、絵画および図表などの映像データや、ゲームおよびソフトフェアなどの任意のデータを含む概念である。

〔２〕本実施形態の目的
続いて、本実施形態の理解を容易にするために、本実施形態に関連するコンテンツ取得システム２と対比させ、本実施形態にかかるコンテンツ取得システム１の目的を説明する。

〔２−１〕本実施形態に関連するコンテンツ取得システム
図２〜図４は、本実施形態に関連するコンテンツ取得システム２におけるコンテンツ取得の流れを示した説明図である。

あるノード２２Ａは、取得対象のファイルである「ｔａｒｇｅｔＦｉｌｅ（対象ファイル名）」を保持するとき、このノード２２Ａの記憶部２３ＡにｔａｒｇｅｔＦｉｌｅがあることを他のノード２２に告知するためのＲＳＳフィードを生成する。通常、ＲＳＳフィードの＜ｅｎｃｌｏｓｕｒｅ＞要素のｕｒｌ属性にはこのファイルの実体を取得するためのＵＲＬ「ｔａｒｇｅｔＦｉｌｅ＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ａ」が記述される。

そして、別のノード２２が、上記で生成されたＲＳＳフィードを取得し、ＲＳＳフィードに記載されている「ｔａｒｇｅｔＦｉｌｅ＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ａ」によりファイル取得プロトコルを利用して対象ファイル「ｔａｒｇｅｔＦｉｌｅ」を取得する。

ここで、＜ｅｎｃｌｏｓｕｒｅ＞要素のｕｒｌ属性の［ファイル名］の項をもとにＤＨＴ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｈａｓｈ Ｔａｂｌｅ）を構成し、［ファイル名］から［ファイル本体のＵＲＬ］の名前解決テーブルのエントリをＤＨＴを利用して引けるものとする。ＤＨＴの詳細については図９を参照して説明する。

この場合、ｔａｒｇｅｔＦｉｌｅをダウンロードしようとするノード２２は、ファイル名のハッシュ値に対応するノードに分散されたＤＨＴハッシュテーブルを利用してファイルのＵＲＬを解決し、本体のファイルを取得する。すなわち、ノード２２は、「対象ファイル名」のハッシュ値と「本体のファイルＵＲＬ」との対応関係が記述された名前解決テーブルを引いてファイルのＵＲＬを取得する。

例えば、図２に示したように、ノード２２Ａ、２２Ｂ、２２Ｃ、２２Ｄおよび２２Ｘに、点線で示したように分散して名前解決テーブル２４Ａ、２４Ｂ、２４Ｃ、２４Ｄおよび２４Ｘが記憶されている場合を考える。この場合、対象のファイル名「ｔａｒｇｅｔＦｉｌｅ」のハッシュ値（ｈａｓｈ（ｔａｒｇｅｔＦｉｌｅ））により決定されるノード（この場合はノード２２Ｂである）に、対象のファイル名から本体のファイルＵＲＬ（ｔａｒｇｅｔＦｉｌｅ＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ａ）を引く名前解決テーブル２４Ｂが管理される。なお、図４〜図６においては、図面の明瞭性の観点から各名前解決テーブルを結ぶ点線は省略する。

このｔａｒｇｅｔＦｉｌｅを取得しようとするノード２２Ｘは、このｔａｒｇｅｔＦｉｌｅについてのメタデータを記述したＲＳＳフィード（＜ｅｎｃｌｏｓｕｒｅ＞要素のｕｒｌ属性に”ｔａｒｇｅｔＦｉｌｅ”が記載されている）を取得する。そして、ノード２２Ｘは、ＤＨＴを利用してノード２２Ｂ上の名前解決テーブル２４Ｂを引き、ｔａｒｇｅｔＦｉｌｅのＵＲＬである「ｔａｒｇｅｔＦｉｌｅ＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ａ」を得て、ｔａｒｇｅｔＦｉｌｅの内容を取得する。さらに、ノード２２Ｘは、取得したｔａｒｇｅｔＦｉｌｅを記憶部２３Ｘに記録する。

その後、ノード２２Ｘは、ノード２２Ｂで管理されている名前解決テーブルエントリである［ｔａｒｇｅｔＦｉｌｅ］−＞［ｔａｒｇｅｔＦｉｌｅ＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ａ］ペアの［ｔａｒｇｅｔＦｉｌｅ＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ａ］の項の後に、記憶部２３ＸにおけるｔａｒｇｅｔＦｉｌｅのＵＲＬ「ＴａｒｇｅｔＦｉｌｅ＿ＲｅａｌＵＲＬＮｏｄｅＸ」を追加する。

その結果、ノード２２ＢへのｔａｒｇｅｔＦｉｌｅについての名前解決依頼に対して返信されるＵＲＬは「ｔａｒｇｅｔＦｉｌｅ＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ａ」と「ｔａｒｇｅｔＦｉｌｅ＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ｘ」の２つとなる。

このため、図４に示したように、複数のノード２２が異なるノードから同一のファイルを取得することが可能となる。例えば、ノード２２Ｃおよびノード２２ＤがｔａｒｇｅｔＦｉｌｅの取得を所望する場合、ノード２２Ｃおよびノード２２Ｄは、ノード２２Ｂの名前解決テーブル２４Ｂを引く。

そして、ノード２２Ｃが「ｔａｒｇｅｔＦｉｌｅ＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ｘ」を得て、ノード２２Ｄが「ｔａｒｇｅｔＦｉｌｅ＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ａ」を得たとする。この場合、ノード２２Ｃがノード２２Ｘから、ノード２２Ｄがノード２２Ａからというように、それぞれのノードが並行して同時にｔａｒｇｅｔＦｉｌｅを取得することが可能となる。

同様にして、別のノード２２がファイルを取得した場合には、名前解決テーブルのエントリに、取得したノード２２上のファイルのＵＲＬが逐次追加されていくものとする。かかる構成によれば、ファイルの複製がノード２２に分散するにつれ、複数のノード２２が同時に同一のファイルの複製を別々のノード２２から取得することができるようになる。

一方、図４に示したように、あるファイルの名前解決の依頼がノード２２Ｂに集中すると、ノード２２Ｂの負荷が増加し、個々の名前解決の依頼に対する処理パフォーマンスが劣化し、さらには全体の処理速度を律速してしまう。

〔２−２〕本実施形態の目的
そこで、この問題を緩和することを目的の一つとし、ファイルをチャンク化して複数のファイルセグメントとして複数のノード２０に記憶させる概念に至った。例えば、それぞれのファイルセグメントに［ファイル名＋ｎ］（ｎはファイルセグメントＩＤ：１，２，．．．．Ｎ）というファイル名をつけて、あるノード２０では、「ファイル名＋ｎ」−＞［（ファイルセグメントの複製）ＵＲＬ， ＵＲＬ， ．．．．］のセットを名前解決テーブルエントリとして管理する。これにより、１つのファイル名をファイル名−１， ファイル名−２， ファイル名−３， ．．．，のように複数のキーに分けてハッシュ空間上に分散させて、ファイル名をキーとするＤＨＴ検索処理を分散させることができる。

図５および図６は、本実施形態にかかるコンテンツ取得システム１におけるコンテンツ取得の流れを示した説明図である。図５に示したように、「ｔａｒｇｅｔＦｉｌｅ」が「ｔａｒｇｅｔＦｉｌｅ−１」および「ｔａｒｇｅｔＦｉｌｅ−２」にチャンク化されており、「ｔａｒｇｅｔＦｉｌｅ−１」のファイルの実体はノード２０Ａの記憶部２７Ａに記録され、「ｔａｒｇｅｔＦｉｌｅ−２」のファイルの実体はノード２０Ｘの記憶部２７Ｘに記録されているものとする。

また、「ｔａｒｇｅｔＦｉｌｅ−１」についての名前解決テーブルのエントリがノード２０Ｂで管理され、「ｔａｒｇｅｔＦｉｌｅ−２」についての名前解決テーブルのエントリがノード２０Ａで管理される。「ｔａｒｇｅｔＦｉｌｅ−１」のエントリには、「ｔａｒｇｅｔＦｉｌｅ−１」の実体のＵＲＬである「ｔａｒｇｅｔＦｉｌｅ−１＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ａ」が格納される。また、「ｔａｒｇｅｔＦｉｌｅ−２」のエントリには、「ｔａｒｇｅｔＦｉｌｅ−２」の実体のＵＲＬである「ｔａｒｇｅｔＦｉｌｅ−２＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ｘ」が格納される。

ここで、「ｔａｒｇｅｔＦｉｌｅ−１」を取得しようとするノード２０Ｃは、「ｔａｒｇｅｔＦｉｌｅ−１」の実体のＵＲＬを解決する名前解決テーブルエントリがノード２０Ｂにあるため、ノード２０Ｂに対して名前解決依頼を行なう。同様に、「ｔａｒｇｅｔＦｉｌｅ−２」を取得しようとするノード２０Ｄは、「ｔａｒｇｅｔＦｉｌｅ−２」の実体のＵＲＬを解決する名前解決テーブルエントリがノード２０Ａにあるため、ノード２０Ａに対して名前解決依頼を行なう。

その結果、ノード２０Ｃは「ｔａｒｇｅｔＦｉｌｅ−１」のＵＲＬである「ｔａｒｇｅｔＦｉｌｅ−１＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ａ」を得て、ノード２０Ａから「ｔａｒｇｅｔＦｉｌｅ−１」を取得する。同様に、ノード２０Ｄは、「ｔａｒｇｅｔＦｉｌｅ−２」のＵＲＬである「ｔａｒｇｅｔＦｉｌｅ−２１＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ｘ」を得て、ノード２０Ｘから「ｔａｒｇｅｔＦｉｌｅ−２」を取得する。

さらに、図６に示したように、「ｔａｒｇｅｔＦｉｌｅ−１」を取得したノード２０Ｃは、記憶部２７Ｃにおける「ｔａｒｇｅｔＦｉｌｅ−１」のＵＲＬを示す「ｔａｒｇｅｔＦｉｌｅ−１＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ｃ」をノード２０Ｂに送信する。そして、ノード２０Ｂは、「ｔａｒｇｅｔＦｉｌｅ−１」のＵＲＬとして「ｔａｒｇｅｔＦｉｌｅ−１＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ｃ」を追加する。

同様に、「ｔａｒｇｅｔＦｉｌｅ−２」を取得したノード２０Ｄは、記憶部２７Ｄにおける「ｔａｒｇｅｔＦｉｌｅ−２」のＵＲＬを示す「ｔａｒｇｅｔＦｉｌｅ−２＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ｄ」をノード２０Ａに送信する。そして、ノード２０Ａは、「ｔａｒｇｅｔＦｉｌｅ−２」のＵＲＬとして「ｔａｒｇｅｔＦｉｌｅ−２＿ＲｅａｌＵＲＬＯｎＮｏｄｅ−Ｄ」を追加する。

ここで、上記のように１のコンテンツのファイルセグメントを複数のノード２０に分散記憶させるシステムを実現するために、ＲＳＳフィードの＜ｅｎｃｌｏｓｕｒｅ＞要素に各ファイルセグメント名を記載する方法が考えられる。

しかし、ファイルセグメントの数が多くなると、ＲＳＳフィードの〈ｅｎｃｌｏｓｕｒｅ）要素の記載が冗長となり、ＲＳＳフィードを提供するＲＳＳディレクトリサーバやＲＳＳマルチキャストサーバなどの処理負荷が増大してしまう。また、ＲＳＳフィードを受信するノード２０のリソースを圧迫してしまうという問題も生じる。

そこで、上記事情に鑑みて本実施形態にかかるコンテンツ取得システム１を創作するに至った。本実施形態にかかるコンテンツ取得システム１によれば、ＲＳＳフィードの〈ｅｎｃｌｏｓｕｒｅ）要素の記載を簡素化しつつ、ファイルセグメントの取得を可能とすることができる。

〔３〕コンテンツ取得システムの詳細な説明
以下、当該コンテンツ取得システム１について、ノード２０のハードウェア構成、ノード２０の機能、およびコンテンツ取得システムの動作の順に従って詳細に説明する。

〔３−１〕ノードのハードウェア構成
図７は、本実施形態にかかるノード２０のハードウェア構成を示した説明図である。図７に示したように、ノード２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３と、ホストバス２０４と、ブリッジ２０５と、外部バス２０６と、インタフェース２０７と、入力装置２０８と、出力装置２１０と、ストレージ装置（ＨＤＤ）２１１と、ドライブ２１２と、通信装置２１５とを備える。

ＣＰＵ２０１は、演算処理装置および制御装置として機能し、各種プログラムに従ってノード２０内の動作全般を制御する。また、ＣＰＵ２０１は、マイクロプロセッサであってもよい。ＲＯＭ２０２は、ＣＰＵ２０１が使用するプログラムや演算パラメータ等を記憶する。ＲＡＭ２０３は、ＣＰＵ２０１の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を一次記憶する。これらはＣＰＵバスなどから構成されるホストバス２０４により相互に接続されている。

ホストバス２０４は、ブリッジ２０５を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バスなどの外部バス２０６に接続されている。なお、必ずしもホストバス２０４、ブリッジ２０５および外部バス２０６を分離構成する必要はなく、一のバスにこれらの機能を実装してもよい。

入力装置２０８は、例えば、マウス、キーボード、タッチパネル、ボタン、マイク、スイッチおよびレバーなどユーザが情報を入力するための入力手段と、ユーザによる入力に基づいて入力信号を生成し、ＣＰＵ２０１に出力する入力制御回路などから構成されている。ノード２０のユーザは、該入力装置２０８を操作することにより、ノード２０に対して各種のデータを入力したり処理動作を指示したりすることができる。

出力装置２１０は、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）ディスプレイ装置、液晶ディスプレイ（ＬＣＤ）装置、ＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｓｐｌａｙ）装置およびランプなどの表示装置と、スピーカおよびヘッドホンなどの音声出力装置で構成される。出力装置２１０は、例えば、再生されたコンテンツを出力する。具体的には、表示装置は再生された映像データ等の各種情報をテキストまたはイメージで表示する。一方、音声出力装置は、再生された音声データ等を音声に変換して出力する。

ストレージ装置２１１は、本実施形態にかかるノード２０の記憶部の一例として構成されたデータ格納用の装置である。ストレージ装置２１１は、記憶媒体、記憶媒体にデータを記録する記録装置、記憶媒体からデータを読み出す読出し装置および記憶媒体に記録されたデータを削除する削除装置などを含んでもよい。ストレージ装置２１１は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）で構成される。このストレージ装置２１１は、ハードディスクを駆動し、ＣＰＵ２０１が実行するプログラムや各種データを格納する。また、このストレージ装置２１１には、後述の、名前解決テーブル、ファイルセグメントなどが記録される。

ドライブ２１２は、記憶媒体用リーダライタであり、ノード２０に内蔵、あるいは外付けされる。ドライブ２１２は、装着されている磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等のリムーバブル記憶媒体２４に記録されている情報を読み出して、ＲＡＭ２０３に出力する。

通信装置２１５は、例えば、通信網１２に接続するための通信デバイス等で構成された通信インタフェースである。また、通信装置２１５は、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）対応通信装置であっても、ワイヤレスＵＳＢ対応通信装置であっても、有線による通信を行うワイヤー通信装置であってもよい。この通信装置２１５は、ノードアドレス解決サーバ１４や他のノード２０との間で、通信網１２を介して、ＲＳＳフィード、ＵＲＬ、ファイルセグメントなどの各種データを送受信する。

〔３−２〕ノードの機能
続いて、図８〜図１１を参照して本実施形態にかかるノード２０の機能を説明する。

図８は、本実施形態にかかるノード２０の構成を示した機能ブロック図である。図８に示したように、当該ノード２０は、通信部２１６と、名前解決処理部２２０と、コンテンツ利用部２３０と、ファイルサーバ処理部２４０と、レンダリング処理部２６０と、を備える。

通信部２１６は、他のノード２０Ｘやノードアドレス解決サーバ１４などとのインターフェースであって、各種データを送受信する。例えば、通信部２１６は、ＲＳＳディレクトリサーバ１５からＲＳＳフィードを受信する受信部としての機能や、自装置に記憶されているファイルセグメントのＵＲＬを送信する送信部としての機能を有する。ここで、ＲＳＳディレクトリサーバ１５は任意のＲＳＳフィードを記憶していてもよい。なお、本明細書においては、例えばノード２０がノード２０Ａに該当する場合、ノード２０Ａと異なる他のノード２０Ｂ、２０Ｃなどを、単にノード２０Ｘと総称する場合がある。

名前解決処理部２２０は、ＵＲＬ抽出部２２２と、名前解決テーブル記憶部２２４と、テーブル管理部２２６と、を備える。

テーブル管理部２２６は、名前解決テーブル記憶部２２４が記憶する名前解決テーブルを管理する。名前解決テーブルは、あるファイル（ファイルセグメントを含む）のファイル名のハッシュ値と、該ファイルのＵＲＬとが対応付けられたエントリ（名前解決テーブルエントリ）を含むテーブルである。

具体的には、各ノード２０はハッシュ値の管理範囲が割当てられており、各ノード２０は、ファイル名のハッシュ値が該管理範囲に含まれるファイルのファイル名のハッシュ値と、該ファイルのＵＲＬとが対応付けられた名前解決テーブルエントリを受信する。そして、テーブル管理部２２６は、他のノード２０から受信した名前解決テーブルエントリを名前解決テーブル記憶部２２４に記録する。ここで、図９を参照して各ノード２０に割当てられるハッシュ値の管理範囲について説明する。

図９は、各ノード２０に割当てられるハッシュ値の管理範囲の一例について示した説明図である。図９においては、ハッシュ値が１０であるノードＩＤをノード２０Ａが有し、ハッシュ値が９０であるノードＩＤをノード２０Ｂが有し、ハッシュ値が１５０であるノードＩＤをノード２０Ｃが有する場合を示している。また、ノード２０Ａおよびノード２０ＣがＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）ネットワークに参加しており、ノード２０Ｂは未参加であるものとする。また、ノード２０Ａおよびノード２０Ｃがリング（ノードＩＤのハッシュ値を連続して並べた仮想的な輪）上にあるものとする。

この場合、ノード２０Ａは、ノードＩＤのハッシュ値が１０であり、ノード２０ＣのノードＩＤのハッシュ値が１５０であるため、ハッシュ値１５１〜１０までをハッシュ値の管理範囲として割当てられる。また、ノード２０Ｃは、ノードＩＤのハッシュ値が１５０であり、ノード２０ＡのノードＩＤのハッシュ値が１０であるため、ハッシュ値１１〜１５０までをハッシュ値の管理範囲として割当てられる。

ここで、ノード２０Ｂが当該ネットワークに参加しようとする場合、ノード２０Ｂは自装置のハッシュ値９０の両隣のハッシュ値を有するノード２０Ａおよびノード２０Ｃを探索する。より多数のノード２０がネットワークに参加している場合、ノード２０Ｂは任意のアルゴリズムにより両隣のノードを探索することができる。例えば、ノード２０Ｂは最初に任意のノードと通信し、該ノードが両隣のノードでなかった場合、該ノードから自装置の両隣のノードを得てもよい。

ノード２０Ｂは、両隣のハッシュ値を有するノード２０Ａおよびノード２０Ｃを得ると、ノード２０ＡのノードＩＤのハッシュ値が１０であり、ノード２０ＣのノードＩＤのハッシュ値が１５０であるため、自装置のハッシュ値の管理範囲を１１〜９０とする。そして、ノード２０Ｂのネットワークへの参加により、ノード２０Ｃのハッシュ値の管理範囲は９１〜１５０になる。

ここで、ネットワークに参加している各ノード２０は、上述したように、ファイル名のハッシュ値が管理範囲に含まれるファイルのファイル名のハッシュ値と、該ファイルのＵＲＬを対応付けて記憶している。例えば、ノード２０Ｂがネットワークに参加する前は、ノード２０Ｃは、ハッシュ値が１１〜１５０の範囲内のファイル名を有するファイルのＵＲＬを記憶していた。したがって、ノード２０Ｂのテーブル管理部２２６は、ノード２０Ｃが記憶していたうちの、ハッシュ値が１１〜９０の範囲内のファイル名を有するファイルのＵＲＬと、該ファイルのファイル名のハッシュ値のペアである名前解決テーブルエントリをノード２０Ｃから受信し、記憶する。

一方、ノード２０Ｂがネットワークから離脱する場合には、ハッシュ値が隣接するノード２０Ｃを探索し、自装置の名前解決テーブル記憶部２２４が記憶していた名前解決テーブルエントリをノード２０Ｃに送信する。そして、ノード３０Ｃのテーブル管理部２２６は、ノード２０Ｂから受信した名前解決テーブルエントリを自装置が管理する名前解決テーブルに追加する。

なお、ノードＩＤは、各ノードがネットワークに参加する際に例えば時間に基づいて決定して保持するランダムな識別情報であってもよい。

以上、各ノード２０に割当てられるハッシュ値の管理範囲や、ネットワークに参加する際、またはネットワークから離脱する際の処理方法について説明したが、上記説明は一例に過ぎず、他の任意の処理方法を代用することが可能である。

ＵＲＬ抽出部２２２は、他のノード２０Ｘから名前解決要求があった場合、該名前解決要求に応じて適切なＵＲＬを返信する。ここで、ＵＲＬ抽出部２２２は、名前解決要求として例えばファイルセグメント名のハッシュ値を受信し、該ハッシュ値と対応付けて名前解決テーブル記憶部２２４に記憶されているＵＲＬを返信してもよい。このような名前解決処理部２２０を備えるノードは、所在情報記憶部としての機能を有する。また、名前解決テーブル記憶部２２４に記憶されている名前解決テーブルの一例を図１０に示す。

図１０は、名前解決テーブル記憶部２２４に記憶されている名前解決テーブルの一例を示した説明図である。図１０に示したように、名前解決テーブルには、ファイル名のハッシュ値と、ファイルの所在を示すＵＲＬとが対応付けられた名前解決テーブルエントリが複数含まれる。

コンテンツ利用部２３０は、ＲＳＳ取得部２３２、生成部２３４、ファイル取得部２３６、および再生指示部２３８を備え、ＲＳＳフィードリーダや、ＲＳＳフィードリーダにより呼び出されるアプリケーションに相当する。

ＲＳＳ取得部２３２は、例えばＲＳＳディレクトリサーバ１５に記憶されているＲＳＳフィードのうちから、選択的にＲＳＳフィードを取得する。または、ＲＳＳ取得部２３２は、ＲＳＳフィードをマルチキャストするＲＳＳマルチキャストサーバ（図示せず。）からＲＳＳフィードを取得することもできる。ここで、ＲＳＳ取得部２３２により取得されたＲＳＳフィード（第１のコンテンツ情報）に含まれる〈ｅｎｃｌｏｓｕｒｅ）要素には、あるコンテンツに応じたデータ情報として該コンテンツのファイル名や、該コンテンツの分割数が記載されている。

生成部２３４は、ＲＳＳ取得部２３２により取得されたＲＳＳフィードに含まれる〈ｅｎｃｌｏｓｕｒｅ）要素の記載から、上記コンテンツをチャンク化して得られた各ファイルセグメントを示す分割データ指定情報としてのファイルセグメント名を生成する。図１１を参照して、生成部２３４の機能を具体的に説明する。

図１１は、生成部２３４が〈ｅｎｃｌｏｓｕｒｅ）要素の記載からファイルセグメント名を生成する様子を示した説明図である。図１１に示した「ｄｒｓ：／／ｔａｒｇｅｔＦｉｌｅ−Ｎ」という〈ｅｎｃｌｏｓｕｒｅ）要素の記載のうち、「ｄｒｓ」は、当該〈ｅｎｃｌｏｓｕｒｅ）要素にファイルの所在でなく特別な情報が記載されていることを示す。

また、「ｔａｒｇｅｔＦｉｌｅ」がコンテンツファイルのファイル名であり、「Ｎ」が該コンテンツを分割して得られたファイルセグメント数である。

生成部２３４は、かかるファイル名に１〜Ｎまでの番号を付加して各ファイルセグメント名を生成する。具体的には、図１１に示したように、生成部２３４は「ｔａｒｇｅｔＦｉｌｅ−１」、「ｔａｒｇｅｔＦｉｌｅ−２」、「ｔａｒｇｅｔＦｉｌｅ−３」、「ｔａｒｇｅｔＦｉｌｅ−４」、・・・、「ｔａｒｇｅｔＦｉｌｅ−Ｎ」を生成する。

ファイル取得部２３６は、生成部２３４により生成されたファイルセグメント名の各々に基づいて各ファイルセグメントを取得する取得部として機能する。例えば、ファイル取得部２３６は、まず各ファイルセグメント名のハッシュ値を計算する。そして、ファイル取得部２３６は、計算したファイルセグメント名のハッシュ値を管理範囲に含むノードＩＤを有するノードのネットワークアドレスを、ノードアドレス解決サーバ１４に問い合わせて取得する。

その後、ファイル取得部２３６は、ノードアドレス解決サーバ１４から取得したネットワークアドレスを有するノードに、ファイルセグメント名を名前解決依頼として送信することにより、該ノードのＵＲＬ抽出部２２２からファイルセグメントのＵＲＬを取得する。
そして、ファイル取得部２３６は、取得したファイルセグメントのＵＲＬの示す所在から、ファイルセグメントの実体を取得する。

なお、ファイル取得部２３６は、１のファイルセグメントに関し、複数のファイルセグメントのＵＲＬを取得する場合がある。この場合、ファイル取得部２３６は、複数のファイルセグメントのＵＲＬから１のＵＲＬを選択し、選択したＵＲＬの示す所在からファイルセグメントの実体を取得してもよい。かかる構成においては、ファイル取得部２３６は、例えばネットワークの混雑状況等に応じ、取得し易いノードから選択的にファイルセグメントの実体を取得することにより、ファイルセグメントの取得効率の向上を図ることができる。

また、あるファイルセグメントのＵＲＬを名前解決テーブル記憶部２２４に複数記憶しているノードは、他のノードからの名前解決要求時に、複数のファイルセグメントのＵＲＬのうちから、１のファイルセグメントのＵＲＬを選択して他のノードに送信してもよい。

また、上記では、生成部２３４がコンテンツのファイル名に１〜Ｎまでの番号を付加して各ファイルセグメント名を生成する例を説明したが、本発明はかかる例に限定されない。例えば、生成部２３４は、あらかじめ順序付けられている要素群のうちで、ファイルセグメント数に応じた範囲内に順序付けられている要素の各々をコンテンツのファイル名に付加してもよい。具体的には、生成部２３４は、Ａ、Ｂ、Ｃ・・と順序付けられているアルファベット群から、ファイルセグメント数が８であった場合、８つ目に順序付けられている「Ｈ」までの各アルファベットをコンテンツ名に付加してファイルセグメント名を得てもよい。

また、ファイルセグメント数は必ずしも数字で表現される必要は無く、あらかじめ順序付けられている要素群におけるいずれかの要素で表現されてもよい。

再生指示部２３８は、ファイル取得部２３６により取得されたファイルセグメントの再生をレンダリング処理部２６０に指示する。すなわち、レンダリング処理部２６０は、再生指示部２３８からの指示に応じてコンテンツを映像や音声の出力装置に再生させる再生部として機能を有する。

ファイルサーバ処理部２４０は、記録部２４２、ファイル記憶部２４４、ＵＲＬ通知部２４６、チャンク処理部２４８、ＲＳＳ生成部２５０、およびファイル転送部２５２を備える。

記録部２４２は、ファイル記憶部２４４に、ファイル取得部２３６により取得されたコンテンツのファイルセグメントを記録する。ファイル記憶部２４４は、コンテンツのファイルセグメントや、チャンク化されていないコンテンツデータなどを記憶する分割データ記憶部として機能する。かかるファイル記憶部２４４を備えるノードは、コンテンツ記憶装置として機能する。なお、図８においては、名前解決テーブル記憶部２２４およびファイル記憶部２４４を異なる構成として示しているが、名前解決テーブル記憶部２２４およびファイル記憶部２４４は実際には物理的に同一の記憶媒体であってもよい。

また、名前解決テーブル記憶部２２４およびファイル記憶部２４４は、例えば、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）などの不揮発性メモリや、ハードディスクおよび円盤型磁性体ディスクなどの磁気ディスクや、ＣＤ−Ｒ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅｃｏｒｄａｂｌｅ）／ＲＷ（ＲｅＷｒｉｔａｂｌｅ）、ＤＶＤ−Ｒ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ Ｒｅｃｏｒｄａｂｌｅ）／ＲＷ／＋Ｒ／＋ＲＷ／ＲＡＭ（Ｒａｍｄａｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびＢＤ（Ｂｌｕ−Ｒａｙ Ｄｉｓｃ（登録商標））―Ｒ／ＢＤ−ＲＥなどの光ディスクや、ＭＯ（Ｍａｇｎｅｔｏ Ｏｐｔｉｃａｌ）ディスクなどの記憶媒体であってもよい。

ＵＲＬ通知部２４６は、記録部２４２により新たにファイル記憶部２４４に記録されたファイルセグメントの、ファイル記憶部２４４における所在を示すＵＲＬを、該ファイルセグメントの名前のハッシュ値を管理範囲に含むノードに送信する送信部として機能する。ＵＲＬ通知部２４６からあるファイルセグメントのＵＲＬを受信したノードのテーブル管理部２２６は、名前解決テーブル記憶部２２４に、該ファイルセグメントのＵＲＬとしてＵＲＬ通知部２４６から受信した該ファイルセグメントのＵＲＬを追加できる。その結果、後に該ファイルセグメントの取得を所望する複数のノードが、異なるノードから分散的に該ファイルセグメントを取得することが可能となる。

また、ＵＲＬ通知部２４６は、後述のチャンク処理部２４８によりコンテンツをチャンク化して得られた各ファイルセグメントのファイル記憶部２４４における所在を示すＵＲＬを、各々対応するノードに送信する。ＵＲＬ通知部２４６からあるファイルセグメントのＵＲＬを受信したノードのテーブル管理部２２６は、名前解決テーブル記憶部２２４に、該ファイルセグメントのＵＲＬとしてＵＲＬ通知部２４６から受信した該ファイルセグメントのＵＲＬを記録できる。

チャンク処理部２４８は、任意のコンテンツデータをチャンク化（分割）し、複数のファイルセグメント（分割データ）を得る分割部として機能する。チャンク処理部２４８によりチャンク化して得られた各ファイルセグメントは、記録部２４２によりファイル記憶部２４４に記録されてもよい。この場合、ＵＲＬ通知部２４６が、各ファイルセグメントのファイル記憶部２４４における所在を示すＵＲＬを、ファイルセグメント名のハッシュ値と併せて各々対応するノードに送信してもよい。

ＲＳＳ生成部２５０は、チャンク処理部２４８によりあるコンテンツのコンテンツデータがチャンク化されると、該コンテンツのＲＳＳフィードを生成する。具体的には、ＲＳＳ生成部２５０は、該コンテンツのコンテンツ名と、チャンク処理部２４８のチャンク処理により生成されたファイルセグメントの数と、が記載された〈ｅｎｃｌｏｓｕｒｅ〉要素を含むＲＳＳフィードを生成する。ＲＳＳ生成部２５０により生成されたＲＳＳフィードは、ＲＳＳディレクトリサーバ１５を介して他のノードに送信される。

ファイル転送部２５２は、他のノードのファイル取得部２３６から、ファイル記憶部２４４に記憶されているファイルセグメントの取得要求があった場合、該ファイルセグメントを他のノードに転送する。

なお、上記では、コンテンツデータがチャンク化された場合のＲＳＳフィードの〈ｅｎｃｌｏｓｕｒｅ〉要素に記載される内容について説明してきた。しかし、コンテンツデータがチャンク化されていない場合は、ＲＳＳフィード（第２のコンテンツ情報）の〈ｅｎｃｌｏｓｕｒｅ〉要素はコンテンツ名を記載されていればよい。この場合、ファイル取得部２３６は、〈ｅｎｃｌｏｓｕｒｅ〉要素に記載されているコンテンツ名のハッシュ値に基づいて該コンテンツの名前解決を依頼するノードを特定し、該ノードから取得したＵＲＬの示す所在から該コンテンツの実体を取得する。

〔３−３〕コンテンツ取得システムの動作
以上、図８〜図１１を参照して本実施形態にかかるノード２０の機能を説明した。続いて、図１２〜図１６を参照し、本実施形態にかかるコンテンツ取得システムの動作を説明する。

図１２は、コンテンツのチャンク化からＲＳＳフィードの公開までの流れを示したシーケンス図である。まず、ノード２０Ａのファイルサーバ処理部２４０のチャンク処理部２４８は、コンテンツのファイルをチャンク化し、各ファイルセグメントにファイル名を命名し、各ファイルセグメントにファイル記憶部２４４におけるＵＲＬを割当てる（Ｓ２０２）。ファイルセグメント数が「Ｎ」である場合、チャンク処理部２４８は、各ファイルセグメントに「ｔａｒｇｅｔＦｉｌｅ−（１ｏｒ２ｏｒ３・・・ｏｒＮ）」のようにファイルセグメント名を命名する。すなわち、図１２においては、太字で示したＮは、（１、２、３・・・、Ｎ）を示す。なお、ファイルセグメント名の命名の際には、ファイルセグメントの再生順序にしたがってコンテンツ名に付加する数字を決定してもよい。

続いて、ファイルサーバ処理部２４０のＵＲＬ通知部２４６は、「ｔａｒｇｅｔＦｉｌｅ−１」のハッシュ値を管理範囲に含むノードに、「ｔａｒｇｅｔＦｉｌｅ−１」のハッシュ値、および「ｔａｒｇｅｔＦｉｌｅ−１」のＵＲＬのペアを通知する（Ｓ２０４）。その際、ＵＲＬ通知部２４６は、ノードアドレス解決サーバ１４から「ｔａｒｇｅｔＦｉｌｅ−１」のハッシュ値を管理範囲に含むノードのネットワークアドレスを取得する（Ｓ２０６）。続いて、「ｔａｒｇｅｔＦｉｌｅ−１」のハッシュ値を管理範囲に含むノードの名前解決処理部２２０は、名前解決テーブルエントリとして「ｔａｒｇｅｔＦｉｌｅ−１」のハッシュ値、および「ｔａｒｇｅｔＦｉｌｅ−１」のＵＲＬのペアを名前解決テーブル記憶部２２４に記憶させる（Ｓ２０８）。

ノード２０Ａのファイルサーバ処理部２４０のＵＲＬ通知部２４６は、「ｔａｒｇｅｔＦｉｌｅ−２」〜「ｔａｒｇｅｔＦｉｌｅ−Ｎ」までのファイルセグメントについても同様の処理を行う。例えば、ＵＲＬ通知部２４６は、「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のハッシュ値を管理範囲に含むノードに、「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のハッシュ値、および「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のＵＲＬのペアを通知する（Ｓ２１０）。その際、ＵＲＬ通知部２４６は、ノードアドレス解決サーバ１４から「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のハッシュ値を管理範囲に含むノードのネットワークアドレスを取得する（Ｓ２１２）。続いて、「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のハッシュ値を管理範囲に含むノードは、名前解決テーブルエントリとして「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のハッシュ値、および「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のＵＲＬのペアを名前解決テーブル記憶部２２４に記憶させる（Ｓ２１４）。

その後、ノード２０Ａのファイルサーバ処理部２４０のＲＳＳ生成部２５０は、〈ｅｎｃｌｏｓｕｒｅ）要素に「ｄｒｓ：／／ｔａｒｇｅｔＦｉｌｅ−Ｎ」が記載されたＲＳＳフィードを生成する（Ｓ２１６）。そして、ノード２０Ａのファイルサーバ処理部２４０のＲＳＳ生成部２５０は、生成したＲＳＳフィードをＲＳＳディレクトリサーバ１５を介して公開する（Ｓ２１８）。

図１３〜図１６は、ＲＳＳの取得からコンテンツの再生までの流れを示したフローチャートである。まず、図１３に示したように、ノード２０Ｚのコンテンツ利用部２３０のＲＳＳ取得部２３２は、ＲＳＳディレクトリサーバ１５において公開されているＲＳＳフィードに記述されているメタデータを検索し、取得対象のコンテンツに対応するＲＳＳフィードを特定して取得する（Ｓ３０２）。続いて、ノード２０Ｚのコンテンツ利用部２３０の生成部２３４およびファイル取得部２３６は、ＲＳＳフィードの＜ｅｎｃｌｏｓｕｒｅ＞要素のｕｒｌ属性に記載されている「ＤＲＳ：／／ｔａｒｇｅｔＦｉｌｅ−［Ｎ］”をもとに、チャンク化された取得対象のコンテンツであるファイルセグメント群のＵＲＬを得る。

例えば、ノード２０Ｚのコンテンツ利用部２３０の生成部２３４は、ファイルセグメント名として「ｔａｒｇｅｔＦｉｌｅ−１」〜「ｔａｒｇｅｔＦｉｌｅ−Ｎ」を生成する。そして、ノード２０Ｚのコンテンツ利用部２３０のファイル取得部２３６が、「ｔａｒｇｅｔＦｉｌｅ−１」のハッシュ値を管理範囲に含むノードの名前解決処理部２２０に「ｔａｒｇｅｔＦｉｌｅ−１」のＵＲＬを問い合わせる（Ｓ３０４）。その際、ファイル取得部２３６は、ノードアドレス解決サーバ１４から「ｔａｒｇｅｔＦｉｌｅ−１」のハッシュ値を管理範囲に含むノードのネットワークアドレスを取得する（Ｓ３０６）。そして、「ｔａｒｇｅｔＦｉｌｅ−１」のハッシュ値を管理範囲に含むノードの名前解決処理部２２０が「ｔａｒｇｅｔＦｉｌｅ−１」のＵＲＬをノード２０Ｚに送信する（Ｓ３０８）。

ノード２０Ｚのコンテンツ利用部２３０のファイル取得部２３６は、「ｔａｒｇｅｔＦｉｌｅ−２」〜「ｔａｒｇｅｔＦｉｌｅ−Ｎ」についても同様の処理を行う。例えば、ファイル取得部２３６は、「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のハッシュ値を管理範囲に含むノードの名前解決処理部２２０に「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のＵＲＬを問い合わせる（Ｓ３１０）。その際、ファイル取得部２３６は、ノードアドレス解決サーバ１４から「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のハッシュ値を管理範囲に含むノードのネットワークアドレスを取得する（Ｓ３１２）。そして、「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のハッシュ値を管理範囲に含むノードの名前解決処理部２２０が「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のＵＲＬをノード２０Ｚに送信する（Ｓ３１４）。なお、Ｓ３０４〜Ｓ３１０までの処理は、ファイルセグメントごとに並列処理が可能である。

そして、図１４に示したように、ノード２０Ｚのコンテンツ利用部２３０のファイル取得部２３６は、ファイルセグメントごとに、取得したＵＲＬのうちのいずれかを選択し、ＵＲＬの示す所在に該当するノードのファイルサーバ処理部２４０にファイルセグメント送信を要求する。例えば、ファイル取得部２３６が「ｔａｒｇｅｔＦｉｌｅ−１」の送信をノード２０Ｘのファイルサーバ処理部２４０に要求すると（Ｓ３５０）、ノード２０Ｘのファイルサーバ処理部２４０が「ｔａｒｇｅｔＦｉｌｅ−１」をノード２０Ｚに送信する（Ｓ３５２）。

ノード２０Ｚのコンテンツ利用部２３０のファイル取得部２３６は、「ｔａｒｇｅｔＦｉｌｅ−２」〜「ｔａｒｇｅｔＦｉｌｅ−Ｎ」についても同様の処理を行う。例えば、ファイル取得部２３６は、「ｔａｒｇｅｔＦｉｌｅ−Ｎ」の送信をノード２０Ｙのファイルサーバ処理部２４０に要求すると（Ｓ３５４）、ノード２０Ｙのファイルサーバ処理部２４０が「ｔａｒｇｅｔＦｉｌｅ−Ｎ」をノード２０Ｚに送信する（Ｓ３５６）。なお、Ｓ３５０〜Ｓ３５６までの処理は、ファイルセグメントごとに並列処理が可能である。

続いて、図１５に示したように、ノード２０Ｚのファイル取得部２３６により取得された「ｔａｒｇｅｔＦｉｌｅ−１」がファイル記憶部２４４に記録されると（Ｓ４０２）、ノード２０Ｚのファイルサーバ処理部２４０のＵＲＬ通知部２４６は、「ｔａｒｇｅｔＦｉｌｅ−１」のハッシュ値と、「ｔａｒｇｅｔＦｉｌｅ−１」のファイル記憶部２４４における所在を示すＵＲＬのペアを、「ｔａｒｇｅｔＦｉｌｅ−１」のハッシュ値を管理範囲に含むノードに通知する（Ｓ４０４）。その際、ＵＲＬ通知部２４６は、ノードアドレス解決サーバ１４から「ｔａｒｇｅｔＦｉｌｅ−１」のハッシュ値を管理範囲に含むノードのネットワークアドレスを取得する（Ｓ４０６）。「ｔａｒｇｅｔＦｉｌｅ−１」のハッシュ値を管理範囲に含むノードは、名前解決テーブルエントリとして「ｔａｒｇｅｔＦｉｌｅ−１」のハッシュ値と、「ｔａｒｇｅｔＦｉｌｅ−１」のファイル記憶部２４４における所在を示すＵＲＬのペアを追加する（Ｓ４０８）。

そして、ノード２０Ｚのファイルサーバ処理部２４０は、「ｔａｒｇｅｔＦｉｌｅ−２」〜「ｔａｒｇｅｔＦｉｌｅ−Ｎ」についても同様の処理を行う。例えば、ノード２０Ｚのファイル取得部２３６により取得された「ｔａｒｇｅｔＦｉｌｅ−Ｎ」がファイル記憶部２４４に記録されると（Ｓ４１０）、ＵＲＬ通知部２４６は、「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のハッシュ値と、「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のファイル記憶部２４４における所在を示すＵＲＬのペアを、「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のハッシュ値を管理範囲に含むノードに通知する（Ｓ４１２）。その際、ＵＲＬ通知部２４６は、ノードアドレス解決サーバ１４から「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のハッシュ値を管理範囲に含むノードのネットワークアドレスを取得する（Ｓ４１４）。「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のハッシュ値を管理範囲に含むノードは、名前解決テーブルエントリとして「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のハッシュ値と、「ｔａｒｇｅｔＦｉｌｅ−Ｎ」のファイル記憶部２４４における所在を示すＵＲＬのペアを追加する（Ｓ４１６）。なお、Ｓ４０２〜Ｓ４１６までの処理は、ファイルセグメントごとに並列処理が可能である。

一方、図１５に示した処理と並行し、ノード２０Ｚのレンダリング処理部２６０は取得が完了したファイルセグメントから、各ファイルセグメントの順序を考慮してコンテンツの逐次再生処理を実行する。具体的には、図１６に示したように、ノード２０Ｚのファイル取得部２３６に取得された「ｔａｒｇｅｔＦｉｌｅ−１」がファイル記憶部２４４に記録されると（Ｓ４５２）、ノード２０Ｚのファイルサーバ処理部２４０はレンダリング処理部２６０に「ｔａｒｇｅｔＦｉｌｅ−１」の再生を要求する（Ｓ４５４）。レンダリング処理部２６０は、ファイルサーバ処理部２４０からの要求に応じて「ｔａｒｇｅｔＦｉｌｅ−１」の再生を開始する（Ｓ４５６）。

そして、ノード２０Ｚは、「ｔａｒｇｅｔＦｉｌｅ−２」〜「ｔａｒｇｅｔＦｉｌｅ−Ｎ」についても同様の処理を行う。例えば、ファイル取得部２３６に取得された「ｔａｒｇｅｔＦｉｌｅ−Ｎ」がファイル記憶部２４４に記録されると（Ｓ４５８）、ファイルサーバ処理部２４０はレンダリング処理部２６０に「ｔａｒｇｅｔＦｉｌｅ−Ｎ」の再生を要求する（Ｓ４６０）。レンダリング処理部２６０は、ファイルサーバ処理部２４０からの要求に応じて「ｔａｒｇｅｔＦｉｌｅ−Ｎ」の再生を開始する（Ｓ４６２）。

〔４〕まとめ
以上説明したように、本実施形態にかかるノード２０は、生成部２３４が、ＲＳＳフィードの＜ｅｎｃｌｏｓｕｒｅ＞要素の記載に基づいて各ファイルセグメント名を生成することができる。そして、ファイル取得部２３６が各ファイルセグメント名に従って他のノードから各ファイルセグメントを取得する。したがって、当該ノード２０によれば、ＲＳＳフィードの＜ｅｎｃｌｏｓｕｒｅ＞要素に、各ファイルセグメント名が記載されていなくても各ファイルセグメントを取得することができる。その結果、ＲＳＳフィードの情報量を抑制し、ＲＳＳフィードが煩雑化することを防止できる。

なお、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。

例えば、本明細書のコンテンツ取得システム１の処理における各ステップは、必ずしもシーケンス図として記載された順序に沿って時系列に処理する必要はない。例えば、コンテンツ取得システム１の処理における各ステップは、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）を含んでもよい。

また、ノード２０に内蔵されるＣＰＵ２０１、ＲＯＭ２０２およびＲＡＭ２０３などのハードウェアを、上述したノード２０の各構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、該コンピュータプログラムを記憶させた記憶媒体も提供される。また、図８の機能ブロック図で示したそれぞれの機能ブロックをハードウェアで構成することで、一連の処理をハードウェアで実現することもできる。

本実施形態にかかるコンテンツ取得システムの構成を示した説明図である。 本実施形態に関連するコンテンツ取得システムにおけるコンテンツ取得の流れを示した説明図である。 本実施形態に関連するコンテンツ取得システムにおけるコンテンツ取得の流れを示した説明図である。 本実施形態に関連するコンテンツ取得システムにおけるコンテンツ取得の流れを示した説明図である。 本実施形態にかかるコンテンツ取得システムにおけるコンテンツ取得の流れを示した説明図である。 本実施形態にかかるコンテンツ取得システムにおけるコンテンツ取得の流れを示した説明図である。 本実施形態にかかるノードのハードウェア構成を示した説明図である。 本実施形態にかかるノードの構成を示した機能ブロック図である。 各ノードに割当てられるハッシュ値の管理範囲の一例について示した説明図である。 名前解決テーブル記憶部に記憶されている名前解決テーブルの一例を示した説明図である。 生成部が〈ｅｎｃｌｏｓｕｒｅ）要素の記載からファイルセグメント名を生成する様子を示した説明図である。 コンテンツのチャンク化からＲＳＳフィードの公開までの流れを示したシーケンス図である。 ＲＳＳの取得からコンテンツの再生までの流れを示したフローチャートである。 ＲＳＳの取得からコンテンツの再生までの流れを示したフローチャートである。 ＲＳＳの取得からコンテンツの再生までの流れを示したフローチャートである。 ＲＳＳの取得からコンテンツの再生までの流れを示したフローチャートである。

符号の説明

１４ ノードアドレス解決サーバ
２１６ 通信部
２２０ 名前解決処理部
２２２ ＵＲＬ抽出部
２２４ 名前解決テーブル記憶部
２２６ テーブル管理部
２３０ コンテンツ利用部
２３２ ＲＳＳ取得部
２３４ 生成部
２３６ ファイル取得部
２４０ ファイルサーバ処理部
２４２ 記録部
２４４ ファイル記憶部
２４６ ＵＲＬ通知部
２４８ チャンク処理部
２５０ ＲＳＳ生成部
２５２ ファイル転送部

Claims (10)

1. 第１のコンテンツデータを分割して得られた所定数の分割データのうちのいずれかを１または２以上のコンテンツ記憶装置が記憶しており、前記所定数の値を示す分割数情報と、前記第１のコンテンツデータに応じたデータ情報と、を含む第１のコンテンツ情報を受信する受信部と；
   前記分割数情報と前記データ情報とに基づき、前記分割データの各々を示す分割データ指定情報を前記分割データごとに生成する生成部と；
   前記分割データ指定情報に従って前記１または２以上のコンテンツ記憶装置から前記分割データを取得する取得部と；
   を備え、
   前記分割データ指定情報に基づいて特定される所在情報記憶装置には前記分割データの所在を示す所在情報が記憶されており、
   前記取得部は、前記分割データ指定情報に基づいて特定した所在情報記憶装置から前記分割データの所在情報を取得し、該所在情報の示すコンテンツ記憶装置から前記分割データを取得することを特徴とする、コンテンツ取得装置。
2. 前記取得部により取得された分割データが記録される記憶部と；
   前記分割データの前記記憶部における所在を示す所在情報を、前記分割データ指定情報に基づいて特定される所在情報記憶装置に送信する送信部と；
   をさらに備えることを特徴とする、請求項１に記載のコンテンツ取得装置。
3. 前記取得部は、前記分割データ指定情報に基づいて特定した所在情報記憶装置から前記分割データの所在情報を複数取得した場合、複数の所在情報のうちから１の所在情報を選択し、選択した所在情報の示すコンテンツ記憶装置から前記分割データを取得することを特徴とする、請求項１に記載のコンテンツ取得装置。
4. 前記所在情報記憶装置には、前記所在情報記憶装置の固有識別情報のハッシュ値に応じたハッシュ値の管理範囲が割当てられており、
   前記分割データの所在情報の各々は、前記分割データを示す分割データ指定情報のハッシュ値を管理範囲に含む所在情報記憶装置に分散記憶されていることを特徴とする、請求項１に記載のコンテンツ取得装置。
5. 前記生成部は、既知の順序付けられた要素群に含まれる要素のうちで、前記分割数情報の示す値に応じた範囲内に順序付けられている要素の各々を前記データ情報に付加することにより所定数の前記分割データ指定情報を生成することを特徴とする、請求項１に記載のコンテンツ取得装置。
6. 受信部は、前記第１のコンテンツ情報と形式が異なり、第２のコンテンツデータを示す第２のコンテンツ情報をさらに受信し、
   前記取得部は、前記第２のコンテンツ情報に従って特定のコンテンツ記憶装置から前記第２のコンテンツデータを取得することを特徴とする、請求項１に記載のコンテンツ取得装置。
7. 前記第１のコンテンツ指定情報はＲＳＳフィードに含まれることを特徴とする、請求項１に記載のコンテンツ取得装置。
8. コンピュータを、
   第１のコンテンツデータを分割して得られた所定数の分割データのうちのいずれかを１または２以上のコンテンツ記憶装置が記憶しており、前記所定数の値を示す分割数情報と、前記第１のコンテンツデータに応じたデータ情報と、を含む第１のコンテンツ指定情報を受信する受信部と；
   前記分割数情報と前記データ情報とに基づき、前記分割データの各々を示す分割データ指定情報を前記分割データごとに生成する生成部と；
   前記分割データ指定情報に従って前記１または２以上のコンテンツ記憶装置から前記分割データを取得する取得部と；
   を備え、
   前記分割データ指定情報に基づいて特定される所在情報記憶装置には前記分割データの所在を示す所在情報が記憶されており、
   前記取得部は、前記分割データ指定情報に基づいて特定した所在情報記憶装置から前記分割データの所在情報を取得し、該所在情報の示すコンテンツ記憶装置から前記分割データを取得するコンテンツ取得装置として機能させるためのプログラム。
9. コンテンツ取得装置において実行されるコンテンツ取得方法であって：
   第１のコンテンツデータを分割して得られた所定数の分割データのうちのいずれかを１または２以上のコンテンツ記憶装置が記憶しており、前記所定数の値を示す分割数情報と、前記第１のコンテンツデータに応じたデータ情報と、を含む第１のコンテンツ指定情報を受信するステップと；
   前記分割数情報と前記データ情報とに基づき、前記分割データの各々を示す分割データ指定情報を前記分割データごとに生成するステップと；
   前記分割データ指定情報に従って前記１または２以上のコンテンツ記憶装置から前記所定数の分割データを取得するステップと；
   を含み、
   前記分割データ指定情報に基づいて特定される所在情報記憶装置には前記分割データの所在を示す所在情報が記憶されており、
   前記取得するステップでは、前記分割データ指定情報に基づいて特定した所在情報記憶装置から前記分割データの所在情報を取得し、該所在情報の示すコンテンツ記憶装置から前記分割データを取得することを特徴とする、コンテンツ取得方法。
10. １または２以上のコンテンツ記憶装置と、コンテンツ取得装置とを含むコンテンツ取得システムであって：
    前記コンテンツ記憶装置は、
    第１のコンテンツデータを分割して所定数の分割データを得る分割部と；
    前記分割データの各々を記憶する分割データ記憶部と；
    前記所定数の値を示す分割数情報と、前記第１のコンテンツデータに応じたデータ情報と、を含む第１のコンテンツ指定情報を送信する通信部と；
    を備え、
    前記コンテンツ取得装置は、
    前記第１のコンテンツ指定情報を受信する受信部と；
    前記分割数情報と前記データ情報とに基づき、前記分割データの各々を示す分割データ指定情報を前記分割データごとに生成する生成部と；
    前記分割データ指定情報に従って前記１または２以上のコンテンツ記憶装置から前記分割データを取得する取得部と；
    を備え、
    前記分割データ指定情報に基づいて特定される所在情報記憶装置には前記分割データの所在を示す所在情報が記憶されており、
    前記取得部は、前記分割データ指定情報に基づいて特定した所在情報記憶装置から前記分割データの所在情報を取得し、該所在情報の示すコンテンツ記憶装置から前記分割データを取得することを特徴とする、コンテンツ取得システム。
    

Images