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

Abstract

【課題】コンテンツ取得装置、プログラム、コンテンツ取得方法、およびコンテンツ取得システムを提供すること。
【解決手段】コンテンツ取得装置であって、コンテンツデータを分割して得られる複数の分割データのメタデータの所在を示す第１の所在情報を含むＲＳＳフィードを受信する受信部と、前記ＲＳＳフィードに含まれる前記第１の所在情報の示す所在から前記メタデータを取得するメタデータ取得部と、前記メタデータの示す各分割データの属性、または２以上の分割データを含む分割データ群の属性に基づき、前記複数の分割データの取得計画を構築する計画構築部２３４と、前記計画構築部により構築された前記取得計画に従って前記複数の分割データの一部または全体を取得する分割データ取得部と、を備える。
【選択図】図８

Description

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

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

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

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

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

しかし、ユーザによっては、コンテンツファイルの全てのファイルセグメントではなく、一部の特定の内容のファイルセグメントのみの取得を所望したり、各ファイルセグメントの特定の順序での取得を所望したりする場合がある。従来のＲＳＳフィードからはファイルセグメント単位の意味合いを得ることができなかったため、上記ファイルセグメントの取得に関する要求を解決することができないという問題があった。

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

上記課題を解決するために、本発明のある観点によれば、コンテンツデータを分割して得られる複数の分割データのメタデータの所在を示す第１の所在情報を含むＲＳＳフィードを受信する受信部と、前記ＲＳＳフィードに含まれる前記第１の所在情報の示す所在から前記メタデータを取得するメタデータ取得部と、前記メタデータの示す各分割データの属性、または２以上の分割データを含む分割データ群の属性に基づき、前記複数の分割データの取得計画を構築する計画構築部と、前記計画構築部により構築された前記取得計画に従って前記複数の分割データの一部または全体を取得する分割データ取得部と、を備えるコンテンツ取得装置が提供される。

かかる構成においては、コンテンツデータを分割して得られる複数の分割データのメタデータがメタデータ取得部により取得される。したがって、計画構築部は、メタデータ取得部により取得されたメタデータに基づいて複数の分割データの取得計画を構築することができる。そして、分割データ取得部が該取得計画に従って分割データを取得するため、当該コンテンツ取得装置は、例えば複数の分割データの一部のみを取得したり、特定の順序で分割データを取得したりすることが可能となる。

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

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

前記受信部により受信された前記ＲＳＳフィードは前記ＲＳＳフィードのカテゴリを示すカテゴリ情報をさらに含み、前記メタデータ取得部は、特定のカテゴリ情報を含むＲＳＳフィードに含まれる前記第１の所在情報の示す所在から前記メタデータを取得してもよい。かかる構成においては、多数のＲＳＳフィードが受信部により受信された場合であっても、特定のカテゴリ情報を含むＲＳＳフィードのみを抽出して利用することができる。

前記メタデータには、前記分割データの優先度を示す情報が含まれてもよい。かかる構成においては、計画構築部は、各分割データの優先度に基づいて取得計画を構築することができる。例えば、計画構築部は、優先度の高い分割データから順に取得する、または優先度の高い分割データのみを取得するといった取得計画を構築してもよい。

前記メタデータには、前記分割データの要旨が含まれてもよい。かかる構成においては、計画構築部は、各分割データの要旨に基づいて取得計画を構築することができる。例えば、計画構築部は、要旨が特定の要旨である分割データのみを取得する取得計画を構築してもよい。

また、上記課題を解決するために、本発明の別の観点によれば、コンピュータを、コンテンツデータを分割して得られる複数の分割データのメタデータの所在を示す第１の所在情報を含むＲＳＳフィードを受信する受信部と、前記ＲＳＳフィードに含まれる前記第１の所在情報の示す所在から前記メタデータを取得するメタデータ取得部と、前記メタデータの示す各分割データの属性、または２以上の分割データを含む分割データ群の属性に基づき、前記複数の分割データの取得計画を構築する計画構築部と、前記計画構築部により構築された前記取得計画に従って前記複数の分割データの一部または全体を取得する分割データ取得部と、を備えるコンテンツ取得装置として機能させるための、プログラムが提供される。

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

また、上記課題を解決するために、本発明の別の観点によれば、コンテンツ取得装置において実行されるコンテンツ取得方法であって、コンテンツデータを分割して得られる複数の分割データのメタデータの所在を示す第１の所在情報を含むＲＳＳフィードを受信するステップと、前記ＲＳＳフィードに含まれる前記第１の所在情報の示す所在から前記メタデータを取得するステップと、前記メタデータの示す各分割データの属性、または２以上の分割データを含む分割データ群の属性に基づき、前記複数の分割データの取得計画を構築するステップと、構築した前記取得計画に従って前記複数の分割データの一部または全体を取得するステップと、を含むコンテンツ取得方法が提供される。

また、上記課題を解決するために、本発明の別の観点によれば、ＲＳＳフィードを生成するＲＳＳ生成装置と、前記ＲＳＳ生成装置により生成されたＲＳＳフィードを取得するコンテンツ取得装置と、を含むコンテンツ取得システムが提供される。前記ＲＳＳ生成装置は、コンテンツデータを分割して得られる複数の分割データのメタデータの所在を示す第１の所在情報を含むＲＳＳフィードを生成する。また、前記コンテンツ取得装置は、前記ＲＳＳ生成装置により生成されたＲＳＳフィードを受信する受信部と、前記ＲＳＳフィードに含まれる前記第１の所在情報の示す所在から前記メタデータを取得するメタデータ取得部と、前記メタデータの示す各分割データの属性、または２以上の分割データを含む分割データ群の属性に基づき、前記複数の分割データの取得計画を構築する計画構築部と、前記計画構築部により構築された前記取得計画に従って前記複数の分割データの一部または全体を取得する分割データ取得部と、を備える。

以上説明したように本発明にかかるコンテンツ取得装置、プログラム、コンテンツ取得方法、およびコンテンツ取得システムによれば、ＲＳＳフィードの記載に基づき、複数の分割データの取得計画を構築することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、ユーザによっては、あるコンテンツのファイルセグメントではなく、一部の特定の内容のファイルセグメントのみの取得を所望したり、各ファイルセグメントの特定の順序での取得を所望したりする場合がある。しかし、通常のＲＳＳフィードからはファイルセグメント単位の意味合いを得ることができなかったため、上記ファイルセグメントの取得に関する要求を解決することができないという問題があった。

そこで、上記事情に鑑みて本実施形態にかかるコンテンツ取得システム１を創作するに至った。本実施形態にかかるコンテンツ取得システム１によれば、ＲＳＳフィードの記載に基づき、複数のファイルセグメントの取得計画を構築することができる。以下、当該コンテンツ取得システム１について詳細に説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

コンテンツ利用部２３０は、ＲＳＳ取得部２３２、ファイルセグメントメタファイル取得部２３３（図８においてはＦＳＭ取得部と示す）、計画構築部２３４、ファイル取得部２３６、および再生指示部２３８を備え、ＲＳＳフィードリーダや、ＲＳＳフィードリーダにより呼び出されるアプリケーションに相当する。

ＲＳＳ取得部２３２は、例えば、ＲＳＳフィードをマルチキャストするＲＳＳマルチキャストサーバ１６からＲＳＳフィードを受信する受信部としての機能を有する。ＲＳＳ取得部２３２により受信されたＲＳＳフィードは、ＲＳＳ取得部２３２に含ませることが可能なＲＳＳフィードローカルキャッシュに蓄積される。なお、ＲＳＳフィードローカルキャッシュには、特定の内容が記載されているカテゴリ情報としての〈ｃａｔｅｇｏｒｙ〉要素を含むＲＳＳフィードのみがＲＳＳフィードローカルキャッシュに蓄積されるようにしてもよい。また、ＲＳＳ取得部２３２は、ＲＳＳディレクトリサーバ（図示せず。）に記憶されているＲＳＳフィードのうちから、選択的にＲＳＳフィードを取得してもよい。

ここで、図１１を参照してＲＳＳ取得部２３２により取得されるＲＳＳフィードの具体例を説明する。

図１１は、ＲＳＳ取得部２３２により取得されるＲＳＳフィードの具体例を示した説明図である。図１１に示したように、ＲＳＳフィードには、大きく、〈ｃｈａｎｎｅｌ〉要素と、〈ｉｔｅｍ〉要素が含まれる。また、〈ｉｔｅｍ〉要素には、後述のファイルセグメントメタファイルのＵＲＬ（図１１においてＦを付して示している。）が記載された〈ｅｎｃｌｏｓｕｒｅ〉要素が含まれる。なお、〈ｃｈａｎｎｅｌ〉要素は上記ｃａｔｅｇｏｒｙ〉要素を含んでもよい。

ファイルセグメントメタファイル取得部２３３は、ＲＳＳ取得部２３２により取得され、ＲＳＳフィードローカルキャッシュに蓄積されているＲＳＳフィードの〈ｅｎｃｌｏｓｕｒｅ〉要素の記載に基づき、ファイルセグメントメタファイルを取得する。すなわち、ファイルセグメントメタファイル取得部２３３はメタデータ取得部としての機能を有する。

ファイルセグメントメタファイル（分割データのメタデータ）は、あるコンテンツをチャンク化して得られた複数のファイルセグメントの各々、または２以上のファイルセグメントを含むファイルセグメントグループの属性情報を含む。

具体的には、ファイルセグメントメタファイルには、
（１）ファイルセグメントごとに、
・ファイルセグメントＩＤ（例えば、“ＮｏｄｅＩＤ．ｔａｒｇｅｔＦｉｌｅ．ｓｅｇｍｅｎｔｅｄＦｉｌｅＩＤ”）
・ファイルセグメント属性（複数）（セグメントレベルの取得優先度等）
・ファイルセグメント付加情報（複数）（取得／再生履歴記録のためのトークン等）
（２）ファイルセグメントグループごとに、
・ファイルセグメントグループＩＤ（例えば、“ＮｏｄｅＩＤ．ｔａｒｇｅｔＦｉｌｅ．ｓｅｇｍｅｎｔｅｄＧｒｏｕｐＩＤ”）（ノードＩＤのスコープでユニーク）
・ファイルセグメントグループ属性（複数）（セグメントグループレベルの取得優先度等）
・ファイルセグメントグループ付加情報（複数）（取得／再生履歴記録のためのトークン等）
・ファイルセグメントグループに属するファイルセグメントのファイルセグメントＩＤのリスト
などを記載することができる。

ファイルセグメントグループは、複数のファイルセグメントをまとめてクラス分けし、ファイルセグメントグループ属性は、グルーピングされたファイルセグメント全体に適用される。

また、ファイルセグメント（ファイルセグメントグループ）属性として、重要（基準はコンテンツ所有者が決める）であるか否か、コンテンツを取得する側の嗜好や必要性にマッチするか否かの判断が可能なように、カテゴリを定義できる。このようなカテゴリは、以下に示すようにｕｒｎを用いて表現される。

取得優先度を示す優先度クラスが、例えば、最大３レベル中、１番優先度が高い場合、
“ｕｒｎ：ｃａｐｔｕｒｉｎｇＰｒｉｏｒｉｔｙ［ｈｉｇｈｅｒＴｈｅＢｅｔｔｅｒ， ｍａｘ３］：３”
と取得優先度を表現することができる。

また、嗜好に合わせた取得優先制御の便宜をはかるためのファイルセグメントの内容に依存した内容カテゴリが、例えば、ジャンルとしてスポーツ／野球／メジャーリーグの階層の場合、
“ｕｒｎ：ｇｅｎｒｅ：ｓｐｏｒｔ：ｂａｓｅｂａｌｌ：ｍａｊｏｒＬｅａｇｕｅ”
とカテゴリを表現することができる。

また、ハイライトにかかる複数のファイルセグメントがグルーピングされているファイルセグメントグループ属性は、
“ｕｒｎ：ｈｉｇｈｌｉｇｈｔｓ”
と表現することができる。

さらに、ファイルセグメントメタファイルには、ファイルセグメント（ファイルセグメントグループ）付加情報を格納する要素が含まれる。例えば、ファイルセグメントメタファイルは、プロバイダー側でファイルセグメント（ファイルセグメントグループ）単位の視聴記録等を収集するためのファイルセグメント（ファイルセグメントグループ）ごとに固有の文字列であるトークンを含んでもよい。かかるトークンは改竄防止のためプロバイダーの秘密鍵等で署名されて、ｂａｓｅ６４等でテキストエンコードされてファイルセグメントメタファイルに記載される。

このようなファイルセグメントメタファイルのスキーマ例、具体例を図１２〜図１５に示す。

図１２は、ファイルセグメントメタファイルのスキーマの一例を示した説明図である。図１３は、ファイルセグメントメタファイルのスキーマの内容を模式的に示した説明図である。図１２に記載した斜体の文字列は、該文字列の上段の記載の意味を示している。例えば、６行目の〈ｘｓ：ｅｌｅｍｅｎｔ ｎａｍｅ＝″ＦｉｌｅＳｅｇｍｅｎｔ″ ｔｙｐｅ＝″ＳｅｇｍｅｎｔＴｙｐｅ″ ｍａｘＯｃｃｕｒｓ″ｕｎｂｏｕｎｄ″／〉という記載は、ファイルセグメントを１以上複数格納することを示す。

図１２に示したファイルセグメントメタファイルのスキーマによれば、図１３に示すように、ファイルセグメントメタファイル３２においてファイルセグメント３４およびファイルセグメントグループ４０が定義される。より詳細には、ファイルセグメント３４の数は１以上であり上限は無く、ファイルセグメントグループ４０の数は０以上であり上限は無いことが定義されている。

また、ファイルセグメント３４の下位にＩＤ３５、Attribute３６、およびExtension３７が定義される。同様に、ファイルセグメントグループ４０の下位にＩＤ４１、セグメントＩＤリスト４２、Attribute４３、およびExtension４４が定義される。

図１４は、ファイルセグメントメタファイルの記載例を示した説明図である。図１５は、ファイルセグメントメタファイルの内容を模式的に示した説明図である。図１４に記載した斜体の文字列は、該文字列の上段の記載の意味を示している。例えば、３行目の〈Ａｔｔｒｉｂｕｔｅ ｕｒｎ＝″ｕｒｎ：ｃａｐｔｕｒｉｎｇＰｒｉｏｒｉｔｙ〔ｈｉｇｈｅｒＴｈｅＢｅｔｔｅｒ， ｍａｘ２〕：２″／〉という記載は、ＩＤが１であるファイルセグメントが、最大２レベル中、１番優先度が高いことを示す。

図１４に示したファイルセグメントメタファイルは、図１５に示したように、ＩＤが１〜４であるファイルセグメントおよびファイルセグメントグループを定義している。さらに、例えばＩＤが３であるファイルセグメントは、優先度が低く、ジャンルが「マイナーリーグ」であることが示されている。

ここで、図８を参照してノード２０の構成の説明に戻ると、計画構築部２３４は、ファイルセグメントメタファイル取得部２３３により取得されたファイルセグメントメタファイルに基づき、ファイルセグメントの取得計画を構築する。

例えば、計画構築部２３４は、優先度が高いファイルセグメントから順に取得したり、優先度が高いファイルセグメントのみを取得したり、特定のジャンルのファイルセグメントのみを取得したりする取得計画を構築する。また、計画構築部２３４は、セグメント属性がハイライト再生用であるファイルセグメントグループを取得する取得計画を構築することもできる。なお、計画構築部２３４にどのような基準でファイルセグメントの取得計画を構築させるかは、ユーザが設定してもよい。

ファイル取得部２３６は、計画構築部２３４により構築された取得計画に従ってファイルセグメント、またはファイルセグメントグループを取得する分割データ取得部としての機能を有する。ファイル取得部２３６があるファイルセグメントを取得する手順を以下に説明する。

ファイル取得部２３６は、あるファイルセグメントを取得する際、まず該ファイルセグメント名のハッシュ値を計算する。そして、ファイル取得部２３６は、計算したファイルセグメント名のハッシュ値を管理範囲に含むノードＩＤを有するノードのネットワークアドレスを、ノードアドレス解決サーバ１４に問い合わせて取得する。

なお、本明細書においては、「ｔａｒｇｅｔＦｉｌｅ」にファイルセグメントＩＤを付したものがファイルセグメント名であるとして説明する。例えば、ファイルセグメントＩＤが１であるファイルセグメントのファイルセグメント名は、「ｔａｒｇｅｔＦｉｌｅ−１」であると考える。また、かかるファイルセグメント名は、ファイルセグメントを示す分割データ指定情報として機能する。

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

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

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

ファイル取得部２３６は、このような手順で、計画構築部２３４により構築されたファイルセグメントの取得順序に従いファイルセグメントを順次に取得する。ここで、計画構築部２３４により構築されたファイルセグメントの取得順序は、ユーザが視聴を所望するファイルセグメントの順序である場合がある。この場合、レンダリング処理部２６０が、ファイル取得部２３６によるファイルセグメントの取得と並列的に、ユーザが視聴を所望する順序でファイルセグメントを順次再生することが可能である。

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

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

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

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

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

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

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

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

ファイルセグメントメタファイル生成部２４９は、チャンク処理部２４８によりチャンク化された各ファイルセグメント、またはファイルセグメントグループの属性やトークンが記載されたファイルセグメントメタファイルを生成する。ファイルセグメントメタファイルについては、図１２〜図１５を参照して上述した通りである。

なお、各ファイルセグメント、またはファイルセグメントグループの属性は、各ファイルセグメントを自動処理することにより抽出しても、ユーザが入力してもよい。ファイルセグメントメタファイル生成部２４９により生成されたファイルセグメントメタファイルは、例えばファイル記憶部２４４に記録される。

ＲＳＳ生成部２５０は、ファイルセグメントメタファイル生成部２４９によりあるコンテンツのファイルセグメントメタファイルが生成されると、該コンテンツのＲＳＳフィードを生成する。具体的には、ＲＳＳ生成部２５０は、該コンテンツのファイルセグメントメタファイルのＵＲＬが記載された〈ｅｎｃｌｏｓｕｒｅ）要素を含むＲＳＳフィードを生成する。ＲＳＳ生成部２５０により生成されたＲＳＳフィードは、ＲＳＳマルチキャストサーバ１６を介して他のノードにマルチキャストされる。

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

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

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

図１６は、コンテンツのチャンク化からＲＳＳフィードの公開までの流れを示したシーケンス図である。まず、ノード２０Ａのファイルサーバ処理部２４０のチャンク処理部２４８は、コンテンツのファイルをチャンク化し、各ファイルセグメントにファイル名を命名し、各ファイルセグメントにファイル記憶部２４４におけるＵＲＬを割当てる（Ｓ２０２）。例えば、コンテンツのファイル名が「ｔａｒｇｅｔＦｉｌｅ」であるとすると、チャンク処理部２４８は、各ファイルセグメントを「ｔａｒｇｅｔＦｉｌｅ．ＦｉｌｅｓｅｇｍｅｎｔＩＤ」と命名する。なお、ファイルセグメントＩＤ（ＦｉｌｅｓｅｇｍｅｎｔＩＤ）は、各ノード２０において固有の識別子である。また、ファイルセグメント名に、「ＮｏｄｅＩＤ」を付してもよい。

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

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

その後、ノード２０Ａのファイルサーバ処理部２４０のファイルセグメントメタファイル生成部２４９は、名前を「ＮｏｄｅＩＤ．ｔａｒｇｅｔＦｉｌｅ．ｆｉｌｅＳｅｇｍｅｎｔＭｅｔａ」とするファイルセグメントメタファイルを生成する（Ｓ２１６）。続いて、ノード２０Ａのファイルサーバ処理部２４０のＲＳＳ生成部２５０は、例えば「ｈｔｔｐ：／／ＮｏｄｅＩＤ．ｔａｒｇｅｔＦｉｌｅ．ｆｉｌｅＳｅｇｍｅｎｔＭｅｔａ」が〈ｅｎｃｌｏｓｕｒｅ〉要素に記載されたＲＳＳフィードを生成する（Ｓ２１８）。

そして、ノード２０Ａのファイルサーバ処理部２４０のＲＳＳ生成部２５０は、生成したＲＳＳフィードをＲＳＳディレクトリサーバ、およびＲＳＳマルチキャストサーバ１６を介して公開する（Ｓ２２０、Ｓ２２２）。このようにＲＳＳディレクトリサーバ、およびＲＳＳマルチキャストサーバ１６を併用することにより、ＲＳＳフィードの配信効率を高めることができる。

図１７は、ＲＳＳマルチキャストサーバ１６によりＲＳＳフィードがマルチキャストされる流れを示したシーケンス図である。図１７に示したように、ノード２０Ａ以外のノード２０のコンテンツ利用部２３０においては、ユーザインターフェースを介したユーザによるＲＳＳフィードのフィルタリング設定が行われる（Ｓ２４２）。具体的には、特定の〈ｃａｔｅｇｏｒｙ〉要素の内容が設定される。

一方、ノード２０Ａのファイルサーバ処理部２４０は、〈ｃａｔｅｇｏｒｙ〉要素を記載したＲＳＳフィードを生成すると（Ｓ２４４）、ＲＳＳマルチキャストサーバ１６にＲＳＳフィードのマルチキャスト配信を依頼する（Ｓ２４６）。

ＲＳＳフィードのマルチキャスト配信を依頼されたＲＳＳマルチキャストサーバ１６は、依頼されたＲＳＳフィードを、ＲＳＳフィードマルチキャストサービスをサブスクライブしているノード２０のコンテンツ利用部２３０にマルチキャスト配信する（Ｓ２４８）。

ＲＳＳフィードをマルチキャスト受信したノード２０のコンテンツ利用部２３０のファイル取得部２３６は、受信したＲＳＳフィードを自装置のＲＳＳフィードローカルキャッシュに蓄積する（Ｓ２５０）。そして、ノード２０のファイル取得部２３６は、ＲＳＳフィードローカルキャッシュに蓄積されたＲＳＳフィードを定期的に古いものから削除管理する。

なお、Ｓ２５０に示したＲＳＳフィードの蓄積においては、ノード２０のファイル取得部２３６は、ＲＳＳフィードの〈ｃａｔｅｇｏｒｙ〉要素の内容に基づいて受信したＲＳＳフィードをフィルタリングする。例えば、ＲＳＳ（ＲＳＳ２．０）におけるＲＳＳフィードのカテゴリを識別する要素としては、ＲＳＳ要素に格納できるｃｈａｎｎｅｌ要素のｃａｔｅｇｏｒｙ要素があり、チャネルが属するカテゴリを指定することができる。例えば、野球中継を示すカテゴリは、
＜ｃａｔｅｇｏｒｙ＞野球中継＜／ｃａｔｅｇｏｒｙ＞
のように表現される。

また、〈ｃａｔｅｇｏｒｙ〉要素のｄｏｍａｉｎ属性を利用して、ドメインを指定してそこで定義されている分類項目を指定することもできる。
＜ｃａｔｅｇｏｒｙ ｄｏｍａｉｎ＝”ｈｔｔｐ：／／ｗｗｗ．ａ．ｃｏｍ／ｃａｔｅｇｏｒｙ”＞ｓｐｏｒｔｓ／ｂａｓｅｂａｌｌ／ｍａｊｏｒＬｅａｇｕｅ＜／ｃａｔｅｇｏｒｙ＞

このようなＲＳＳフィード内のテキスト表記のカテゴリ属性でＲＳＳフィードをフィルタリングする場合、処理系に負担をかける恐れがある。このため、バイナリ表現のフィルター属性を定義して、そのバイナリインデクスによりフィルタリングをかけることによりフィルタリングの効率化をはかる方式が例えば下記文献に記載されている。
文献：特開２００１−２１６１８４号公報

上記方式を利用する場合には、〈ｃａｔｅｇｏｒｙ〉要素のｄｏｍａｉｎ属性に、バイナリインデクスを示す、例えば、”ｈｔｔｐ：／／ｗｗｗ．ａ．ｃｏｍ／ｂｉｎａｒｙＣａｔｅｇｏｒｙＩｎｄｅｘ”のようなドメインを指定して、“８ｔｕ３ｈｆ７５ｙｔ６ｅｉ”のようなｂａｓｅ６４エンコードされたバイナリインデクスを格納する。
＜ｃａｔｅｇｏｒｙ ｄｏｍａｉｎ＝”ｈｔｔｐ：／／ｗｗｗ．ａ．ｃｏｍ／ｂｉｎａｒｙＣａｔｅｇｏｒｙＩｎｄｅｘ”＞８ｔｕ３ｈｆ７５ｙｔ６ｅｉ＜／ｃａｔｅｇｏｒｙ＞

ノード２０は、このようなＲＳＳフィードを受信した場合、ｂａｓｅ６４エンコードされたバイナリインデクスを解凍してから、フィルタリングに利用する。

図１８は、ファイルセグメントメタファイルが取得される流れを示したシーケンス図である。まず、ノード２０Ｚのコンテンツ利用部２３０が、取得対象のコンテンツのＲＳＳフィードを検索、あるいは取得する（Ｓ２６２）。具体的には、ノード２０Ｚのコンテンツ利用部２３０は、ＲＳＳマルチキャストサーバ１６からマルチキャスト配信されてＲＳＳフィードローカルキャッシュ（ＲＳＳ取得部２３２）に蓄積されたＲＳＳフィードに記述されているメタデータに基づいて取得対象のコンテンツのＲＳＳフィードを検索する。または、ノード２０Ｚのコンテンツ利用部２３０は、ＲＳＳディレクトリサーバにＲＳＳフィードを要求し、ＲＳＳディレクトリサーバは要求されたＲＳＳフィードを検索しノード２０Ｚに送信する（Ｓ２６４）。

そして、ノード２０Ｚのコンテンツ利用部２３０のファイルセグメントメタファイル取得部２３３は、取得対象のコンテンツのＲＳＳフィードに含まれる＜ｅｎｃｌｏｓｕｒｅ＞要素のｕｒｌの示すノード２０Ａのファイルサーバ処理部２４０にファイルセグメントメタファイルを要求する（Ｓ２６６）。ノード２０Ａのファイルサーバ処理部２４０は、要求されたファイルセグメントメタファイルを検索し、ノード２０Ｚに送信する（Ｓ２６８）。

続いて、ノード２０Ｚのコンテンツ利用部２３０の計画構築部２３４は、ノード２０Ａから受信したファイルセグメントメタファイルの内容を解析し、とある基準に従い、ファイルセグメントの取得計画を構築する（Ｓ２７０）。基準の例としては、ファイルセグメントの優先度の高いものから順に取得する、あるいは、ハイライトファイルセグメントグループを先に取得する等のさまざまなバリエーションがある。

図１９〜図２２は、ファイルセグメントの取得からコンテンツの再生までの流れを示したシーケンス図である。なお、図１９〜図２０は図１８に示した処理に続く処理である。そこで、図１８のＳ２７０において、ノード２０Ｚのコンテンツ利用部２３０の計画構築部２３４が、「ｔａｒｇｅｔＦｉｌｅ」のファイルセグメントである、「ｔａｒｇｅｔＦｉｌｅ−１」および「ｔａｒｇｅｔＦｉｌｅ−２」を取得する取得計画を構築したものとする。

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

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

そして、図２０に示したように、ノード２０Ｚのコンテンツ利用部２３０のファイル取得部２３６は、取得した「ｔａｒｇｅｔＦｉｌｅ−１」のＵＲＬに基づき、「ｔａｒｇｅｔＦｉｌｅ−１」の送信をノード２０Ｘのファイルサーバ処理部２４０に要求する（Ｓ３５０）。ノード２０Ｘのファイルサーバ処理部２４０は、ノード２０Ｚからの要求に応じて「ｔａｒｇｅｔＦｉｌｅ−１」をノード２０Ｚに送信する（Ｓ３５２）。

同様に、ファイル取得部２３６は、取得した「ｔａｒｇｅｔＦｉｌｅ−２」のＵＲＬに基づき、「ｔａｒｇｅｔＦｉｌｅ−２」の送信をノード２０Ｙのファイルサーバ処理部２４０に要求する（Ｓ３５４）。ノード２０Ｙのファイルサーバ処理部２４０は、ノード２０Ｚからの要求に応じて「ｔａｒｇｅｔＦｉｌｅ−２」をノード２０Ｚに送信する（Ｓ３５６）。

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

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

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

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

以上説明したように、本実施形態によれば、コンテンツをチャンク化して得られる複数のファイルセグメントの属性情報を含むファイルセグメントメタファイルがファイルセグメントメタファイル取得部２３３により取得される。したがって、計画構築部２３４は、ファイルセグメントメタファイル取得部２３３により取得されたファイルセグメントメタファイルに基づいて複数のファイルセグメントの取得計画を構築することができる。そして、ファイル取得部２３６が該取得計画に従ってファイルセグメントを取得するため、本実施形態にかかるノード２０は、例えば複数のファイルセグメントの一部のみを取得したり、特定の順序でファイルセグメントを取得したりすることが可能となる。

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

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

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

本実施形態にかかるコンテンツ取得システムの構成を示した説明図である。 本実施形態に関連するコンテンツ取得システムにおけるコンテンツ取得の流れを示した説明図である。 本実施形態に関連するコンテンツ取得システムにおけるコンテンツ取得の流れを示した説明図である。 本実施形態に関連するコンテンツ取得システムにおけるコンテンツ取得の流れを示した説明図である。 本実施形態にかかるコンテンツ取得システムにおけるコンテンツ取得の流れを示した説明図である。 本実施形態にかかるコンテンツ取得システムにおけるコンテンツ取得の流れを示した説明図である。 本実施形態にかかるノードのハードウェア構成を示した説明図である。 本実施形態にかかるノードの構成を示した機能ブロック図である。 各ノードに割当てられるハッシュ値の管理範囲の一例について示した説明図である。 名前解決テーブル記憶部に記憶されている名前解決テーブルの一例を示した説明図である。 ＲＳＳ取得部により取得されるＲＳＳフィードの具体例を示した説明図である。 ファイルセグメントメタファイルのスキーマの一例を示した説明図である。 ファイルセグメントメタファイルのスキーマの内容を模式的に示した説明図である。 ファイルセグメントメタファイルの記載例を示した説明図である。 ファイルセグメントメタファイルの内容を模式的に示した説明図である。 コンテンツのチャンク化からＲＳＳフィードの公開までの流れを示したシーケンス図である。 ＲＳＳマルチキャストサーバによりＲＳＳフィードがマルチキャストされる流れを示したシーケンス図である。 ファイルセグメントメタファイルが取得される流れを示したシーケンス図である。 ファイルセグメントの取得からコンテンツの再生までの流れを示したシーケンス図である。 ファイルセグメントの取得からコンテンツの再生までの流れを示したシーケンス図である。 ファイルセグメントの取得からコンテンツの再生までの流れを示したシーケンス図である。 ファイルセグメントの取得からコンテンツの再生までの流れを示したシーケンス図である。

符号の説明

１４ ノードアドレス解決サーバ
１６ ＲＳＳマルチキャストサーバ
２１６ 通信部
２２０ 名前解決処理部
２２２ ＵＲＬ抽出部
２２４ 名前解決テーブル記憶部
２２６ テーブル管理部
２３０ コンテンツ利用部
２３２ ＲＳＳ取得部
２３３ ファイルセグメントメタファイル取得部
２３４ 計画構築部
２３６ ファイル取得部
２４０ ファイルサーバ処理部
２４２ 記録部
２４４ ファイル記憶部
２４６ ＵＲＬ通知部
２４８ チャンク処理部
２４９ ファイルセグメントメタファイル生成部
２５０ ＲＳＳ生成部

Claims (8)

1. コンテンツデータを分割して得られる複数の分割データのメタデータの所在を示す第１の所在情報を含むＲＳＳフィードを受信する受信部と；
   前記ＲＳＳフィードに含まれる前記第１の所在情報の示す所在から前記メタデータを取得するメタデータ取得部と；
   前記メタデータの示す各分割データの属性、または２以上の分割データを含む分割データ群の属性に基づき、前記複数の分割データの取得計画を構築する計画構築部と；
   前記計画構築部により構築された前記取得計画に従って前記複数の分割データの一部または全体を取得する分割データ取得部と；
   を備えることを特徴とする、コンテンツ取得装置。
2. 前記メタデータには、前記複数の分割データの各々を示す分割データ指定情報が含まれ、
   前記分割データ指定情報に基づいて特定される所在情報記憶装置には前記分割データの所在を示す第２の所在情報が記憶されており、
   前記分割データ取得部は、前記分割データ指定情報に基づいて特定した所在情報記憶装置から前記分割データの前記第２の所在情報を取得し、該第２の所在情報の示すコンテンツ記憶装置から前記分割データを取得することを特徴とする、請求項１に記載のコンテンツ取得装置。
3. 前記受信部により受信された前記ＲＳＳフィードは前記ＲＳＳフィードのカテゴリを示すカテゴリ情報をさらに含み、
   前記メタデータ取得部は、特定のカテゴリ情報を含むＲＳＳフィードに含まれる前記第１の所在情報の示す所在から前記メタデータを取得することを特徴とする、請求項１に記載のコンテンツ取得装置。
4. 前記メタデータには、前記分割データの優先度を示す情報が含まれることを特徴とする、請求項１に記載のコンテンツ取得装置。
5. 前記メタデータには、前記分割データの要旨が含まれることを特徴とする、請求項１に記載のコンテンツ取得装置。
6. コンピュータを、
   コンテンツデータを分割して得られる複数の分割データのメタデータの所在を示す第１の所在情報を含むＲＳＳフィードを受信する受信部と；
   前記ＲＳＳフィードに含まれる前記第１の所在情報の示す所在から前記メタデータを取得するメタデータ取得部と；
   前記メタデータの示す各分割データの属性、または２以上の分割データを含む分割データ群の属性に基づき、前記複数の分割データの取得計画を構築する計画構築部と；
   前記計画構築部により構築された前記取得計画に従って前記複数の分割データの一部または全体を取得する分割データ取得部と；
   を備えるコンテンツ取得装置として機能させるための、プログラム。
7. コンテンツ取得装置において実行されるコンテンツ取得方法であって：
   コンテンツデータを分割して得られる複数の分割データのメタデータの所在を示す第１の所在情報を含むＲＳＳフィードを受信するステップと；
   前記ＲＳＳフィードに含まれる前記第１の所在情報の示す所在から前記メタデータを取得するステップと；
   前記メタデータの示す各分割データの属性、または２以上の分割データを含む分割データ群の属性に基づき、前記複数の分割データの取得計画を構築するステップと；
   構築した前記取得計画に従って前記複数の分割データの一部または全体を取得するステップと；
   を含むことを特徴とする、コンテンツ取得方法。
8. ＲＳＳフィードを生成するＲＳＳ生成装置と、前記ＲＳＳ生成装置により生成されたＲＳＳフィードを取得するコンテンツ取得装置と、を含むコンテンツ取得システムであって：
   前記ＲＳＳ生成装置は、コンテンツデータを分割して得られる複数の分割データのメタデータの所在を示す第１の所在情報を含むＲＳＳフィードを生成し、
   前記コンテンツ取得装置は、
   前記ＲＳＳ生成装置により生成されたＲＳＳフィードを受信する受信部と；
   前記ＲＳＳフィードに含まれる前記第１の所在情報の示す所在から前記メタデータを取得するメタデータ取得部と；
   前記メタデータの示す各分割データの属性、または２以上の分割データを含む分割データ群の属性に基づき、前記複数の分割データの取得計画を構築する計画構築部と；
   前記計画構築部により構築された前記取得計画に従って前記複数の分割データの一部または全体を取得する分割データ取得部と；
   を備えることを特徴とする、コンテンツ取得システム。

Images