(57)【要約】      （修正有）【課題】複数のコンテンツデータを順次連続して取得する場合に、各ノード装置がコンテンツ提供サーバに負担をかけずにこれらのコンテンツデータをより効率良く取得する。【解決手段】内容の異なる複数のコンテンツデータが複数のノード装置に分散保存され管理されるコンテンツ分散保存システムにおけるノード装置は、コンテンツデータの所在を管理している管理装置に問い合わせて当該コンテンツデータを保存している他のノード装置に接続するためのネットワークアドレス情報を取得し、そのネットワークアドレス情報に基づいて、他のノード装置に接続しコンテンツデータを取得し再生する。そして、次のコンテンツデータを連続して取得する場合に、直前のコンテンツデータの再生終了の所定時間前に次のコンテンツデータの所在を管理装置に問合せ、次のコンテンツデータを保存している他のノード装置のネットワークアドレス情報を取得する。【選択図】図３
2008310621.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して互いに通信可能な複数のノード装置を備えたコンテンツ分散保存システムであり、内容の異なる複数のコンテンツデータが複数のノード装置に分散保存され、当該分散保存されているコンテンツデータの所在がコンテンツデータ毎に管理されるコンテンツ分散保存システムにおける前記ノード装置であって、
取得すべき前記コンテンツデータの所在を管理している管理装置に問い合わせることにより、当該コンテンツデータを保存している他のノード装置に接続するためのネットワークアドレス情報を取得するアドレス情報取得手段と、
前記取得したネットワークアドレス情報に基づいて、前記他のノード装置に接続し、前記コンテンツデータを取得するコンテンツデータ取得手段と、
前記取得したコンテンツデータを再生するコンテンツデータ再生手段と、
を備え、
前記複数のコンテンツデータを順次連続して取得する場合に、前記アドレス情報取得手段は、直前のコンテンツデータの再生終了の所定時間前に次の前記コンテンツデータの所在を管理している管理装置に問合せを行い、当該次のコンテンツデータを保存している他のノード装置のネットワークアドレス情報を取得することを特徴とするノード装置。
【請求項２】
請求項１に記載のノード装置において、
前記アドレス情報取得手段は、前記次のコンテンツデータのビットレートに基づいて前記所定時間を決定することを特徴とするノード装置。
【請求項３】
請求項２に記載のノード装置において、
前記アドレス情報取得手段は、前記次のコンテンツデータのビットレートが高いほど、前記所定時間を長くすることを特徴とするノード装置。
【請求項４】
請求項１に記載のノード装置において、
前記コンテンツデータ再生手段は、前記コンテンツデータの取得開始から、当該コンテンツデータの再生に必要なバッファ量が蓄積手段に蓄積されたときに当該コンテンツデータの再生を開始し、
前記アドレス情報取得手段は、前記次のコンテンツデータの再生に必要なバッファ量に基づいて前記所定時間を決定することを特徴とするノード装置。
【請求項５】
請求項１乃至４の何れか一項に記載のノード装置において、
前記アドレス情報取得手段は、前記取得すべきコンテンツデータのビットレートに応じて当該コンテンツデータを保存している他のノード装置の数を決定し、当該数分の当該他のノード装置のネットワークアドレス情報を、当該コンテンツデータの所在を管理している管理装置から取得することを特徴とするノード装置。
【請求項６】
コンピュータを、請求項１乃至５の何れか一項に記載のノード装置として機能させることを特徴とするノード処理プログラム。
【請求項７】
ネットワークを介して互いに通信可能な複数のノード装置を備えたコンテンツ分散保存システムであり、内容の異なる複数のコンテンツデータが複数のノード装置に分散保存され、当該分散保存されているコンテンツデータの所在がコンテンツデータ毎に管理されるコンテンツ分散保存システムにおいて前記ノード装置は、
取得すべき前記コンテンツデータの所在を管理している管理装置に問い合わせることにより、当該コンテンツデータを保存している他のノード装置に接続するためのネットワークアドレス情報を取得するアドレス情報取得手段と、
前記取得したネットワークアドレス情報に基づいて、前記他のノード装置に接続し、前記コンテンツデータを取得するコンテンツデータ取得手段と、
前記取得したコンテンツデータを再生するコンテンツデータ再生手段と、
を備え、
前記複数のコンテンツデータを順次連続して取得する場合に、前記アドレス情報取得手段は、直前のコンテンツデータの再生終了の所定時間前に次の前記コンテンツデータの所在を管理している管理装置に問合せを行い、当該次のコンテンツデータを保存している他のノード装置のネットワークアドレス情報を取得することを特徴とするコンテンツ分散保存システム。
【請求項８】
ネットワークを介して互いに通信可能な複数のノード装置を備えたコンテンツ分散保存システムであり、内容の異なる複数のコンテンツデータが複数のノード装置に分散保存され、当該分散保存されているコンテンツデータの所在がコンテンツデータ毎に管理されるコンテンツ分散保存システムにおけるコンテンツデータ取得方法であって、
前記ノード装置は、
取得すべき前記コンテンツデータの所在を管理している管理装置に問い合わせることにより、当該コンテンツデータを保存している他のノード装置に接続するためのネットワークアドレス情報を取得するアドレス情報取得工程と、
前記取得したネットワークアドレス情報に基づいて、前記他のノード装置に接続し、前記コンテンツデータを取得する工程と、
前記取得したコンテンツデータを再生する工程と、
を備え、
前記複数のコンテンツデータを順次連続して取得する場合に、前記アドレス情報取得工程においては、直前のコンテンツデータの再生終了の所定時間前に次の前記コンテンツデータの所在を管理している管理装置に問合せを行い、当該次のコンテンツデータを保存している他のノード装置のネットワークアドレス情報を取得することを特徴とするコンテンツデータ取得方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えたピアツーピア（Peer to Peer（P2P））型の通信システムの技術分野に関する。
【背景技術】
【０００２】
この種のピアツーピア型の通信システムにおいて、コンテンツデータを複数のノード装置に分散配置（分散保存）させておくコンテンツ分散保存システムが知られており、これにより、対故障性やアクセスの分散性が高められている。このように分散保存されたコンテンツデータの所在は、例えば特許文献１に開示されるような分散ハッシュテーブル（以下、ＤＨＴ（Distributed Hash Table）という）を利用して効率良く検索可能になっている。
【０００３】
そして、コンテンツ分散保存システムに参加しているノード装置は、所望のコンテンツデータの取得を望む場合、上記ＤＨＴを利用して当該コンテンツデータの所在を管理しているノード装置（ルートノード）に問い合わせる（クエリの送出による）ことにより、当該コンテンツデータを保存している他のノード装置に接続するためのネットワークアドレス情報を取得し、当該ネットワークアドレス情報に基づいて、上記他のノード装置に接続し当該コンテンツデータを取得することができるようになっている。
【特許文献１】特開２００６−１９７４００号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、一のノード装置が、内容の異なる複数のコンテンツデータを順次連続して取得する場合に、開始時に一度に夫々のコンテンツデータの所在を管理しているノード装置に問い合わせて夫々のコンテンツデータを保存している他のノード装置のネットワークアドレス情報を取得しておき、順に当該他のノード装置に接続してコンテンツデータを一つずつ順に取得（ダウンロード）する方法が考えられる。
【０００５】
しかしながら、この方法の場合、コンテンツ分散保存システムに参加しているノード装置は、例えば電源ＯＦＦにより脱退したり、ディスク容量の制限によりコンテンツデータを削除することがあるので、時間が経過すると、上記一のノード装置がコンテンツデータを取得できないことが想定される。上記一のノード装置が、再度、当該コンテンツデータの所在を管理しているノード装置に問い合わせる必要があり非効率的である。或いは、当該一のノード装置は、全てのコンテンツデータを保存しているコンテンツ提供サーバに接続して当該コンテンツデータを取得することも考えられるが、当該コンテンツ提供サーバの負荷が増大するという問題がある。
【０００６】
本発明は、以上の問題等に鑑みてなされたものであり、複数のコンテンツデータを順次連続して取得する場合に、各ノード装置が、コンテンツ提供サーバに負担をかけずに、これらのコンテンツデータをより効率良く取得すること等を可能にしたコンテンツ分散保存システム、コンテンツデータ取得方法、ノード装置、及びノード処理プログラムを提供することを課題とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、請求項１に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えたコンテンツ分散保存システムであり、内容の異なる複数のコンテンツデータが複数のノード装置に分散保存され、当該分散保存されているコンテンツデータの所在がコンテンツデータ毎に管理されるコンテンツ分散保存システムにおける前記ノード装置であって、取得すべき前記コンテンツデータの所在を管理している管理装置に問い合わせることにより、当該コンテンツデータを保存している他のノード装置に接続するためのネットワークアドレス情報を取得するアドレス情報取得手段と、前記取得したネットワークアドレス情報に基づいて、前記他のノード装置に接続し、前記コンテンツデータを取得するコンテンツデータ取得手段と、前記取得したコンテンツデータを再生するコンテンツデータ再生手段と、を備え、前記複数のコンテンツデータを順次連続して取得する場合に、前記アドレス情報取得手段は、直前のコンテンツデータの再生終了の所定時間前に次の前記コンテンツデータの所在を管理している管理装置に問合せを行い、当該次のコンテンツデータを保存している他のノード装置のネットワークアドレス情報を取得することを特徴とする。
【０００８】
この発明によれば、複数のコンテンツデータを順次連続して取得する場合に、直前のコンテンツデータの再生終了の所定時間前に次の前記コンテンツデータの所在を管理している管理装置に問合せを行い、当該次のコンテンツデータを保存している他のノード装置のネットワークアドレス情報を取得するように構成したので、時間の経過により上記他のノード装置が脱退するなどの状況が変わるという事態を回避でき、したがって、再度、上記他のノード装置に問い合わせる必要もなく、コンテンツ提供サーバに負担をかけずに、これらのコンテンツデータをより効率良く取得することができる。
【０００９】
請求項２に記載の発明は、請求項１に記載のノード装置において、前記アドレス情報取得手段は、前記次のコンテンツデータのビットレートに基づいて前記所定時間を決定することを特徴とする。
【００１０】
この発明によれば、最適なタイミングで次のコンテンツデータの所在を上記他のノード装置に問い合わせることができ、ひいては、直前のコンテンツデータの再生終了後速やかに次のコンテンツデータの再生を開始することができる。
【００１１】
請求項３に記載の発明は、請求項２に記載のノード装置において、前記アドレス情報取得手段は、前記次のコンテンツデータのビットレートが高いほど、前記所定時間を長くすることを特徴とする。
【００１２】
請求項４に記載の発明は、請求項１に記載のノード装置において、前記コンテンツデータ再生手段は、前記コンテンツデータの取得開始から、当該コンテンツデータの再生に必要なバッファ量が蓄積手段に蓄積されたときに当該コンテンツデータの再生を開始し、前記アドレス情報取得手段は、前記次のコンテンツデータの再生に必要なバッファ量に基づいて前記所定時間を決定することを特徴とする。
【００１３】
この発明によれば、最適なタイミングで次のコンテンツデータの所在を上記他のノード装置に問い合わせることができ、ひいては、直前のコンテンツデータの再生終了後速やかに次のコンテンツデータの再生を開始することができる。
【００１４】
請求項５に記載の発明は、請求項１乃至４の何れか一項に記載のノード装置において、前記アドレス情報取得手段は、前記取得すべきコンテンツデータのビットレートに応じて当該コンテンツデータを保存している他のノード装置の数を決定し、当該数分の当該他のノード装置のネットワークアドレス情報を、当該コンテンツデータの所在を管理している管理装置から取得することを特徴とする。
【００１５】
この発明によれば、再生に必要なバッファ量が蓄積されるのに要する時間を短縮することができる。
【００１６】
請求項６に記載のノード処理プログラムの発明は、コンピュータを、請求項１乃至５の何れか一項に記載のノード装置として機能させることを特徴とする。
【００１７】
請求項７に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えたコンテンツ分散保存システムであり、内容の異なる複数のコンテンツデータが複数のノード装置に分散保存され、当該分散保存されているコンテンツデータの所在がコンテンツデータ毎に管理されるコンテンツ分散保存システムにおいて前記ノード装置は、取得すべき前記コンテンツデータの所在を管理している管理装置に問い合わせることにより、当該コンテンツデータを保存している他のノード装置に接続するためのネットワークアドレス情報を取得するアドレス情報取得手段と、前記取得したネットワークアドレス情報に基づいて、前記他のノード装置に接続し、前記コンテンツデータを取得するコンテンツデータ取得手段と、前記取得したコンテンツデータを再生するコンテンツデータ再生手段と、を備え、前記複数のコンテンツデータを順次連続して取得する場合に、前記アドレス情報取得手段は、直前のコンテンツデータの再生終了の所定時間前に次の前記コンテンツデータの所在を管理している管理装置に問合せを行い、当該次のコンテンツデータを保存している他のノード装置のネットワークアドレス情報を取得することを特徴とする。
【００１８】
請求項８に記載の発明は、ネットワークを介して互いに通信可能な複数のノード装置を備えたコンテンツ分散保存システムであり、内容の異なる複数のコンテンツデータが複数のノード装置に分散保存され、当該分散保存されているコンテンツデータの所在がコンテンツデータ毎に管理されるコンテンツ分散保存システムにおけるコンテンツデータ取得方法であって、前記ノード装置は、取得すべき前記コンテンツデータの所在を管理している管理装置に問い合わせることにより、当該コンテンツデータを保存している他のノード装置に接続するためのネットワークアドレス情報を取得するアドレス情報取得工程と、前記取得したネットワークアドレス情報に基づいて、前記他のノード装置に接続し、前記コンテンツデータを取得する工程と、前記取得したコンテンツデータを再生する工程と、を備え、前記複数のコンテンツデータを順次連続して取得する場合に、前記アドレス情報取得工程においては、直前のコンテンツデータの再生終了の所定時間前に次の前記コンテンツデータの所在を管理している管理装置に問合せを行い、当該次のコンテンツデータを保存している他のノード装置のネットワークアドレス情報を取得することを特徴とする。
【発明の効果】
【００１９】
本発明によれば、複数のコンテンツデータを順次連続して取得する場合に、直前のコンテンツデータの再生終了の所定時間前に次の前記コンテンツデータの所在を管理している管理装置に問合せを行い、当該次のコンテンツデータを保存している他のノード装置のネットワークアドレス情報を取得するように構成したので、時間の経過により上記他のノード装置が脱退するなどの状況が変わるという事態を回避でき、したがって、再度、上記他のノード装置に問い合わせる必要もなく、コンテンツ提供サーバに負担をかけずに、これらのコンテンツデータをより効率良く取得することができる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明の最良の実施形態を図面に基づいて説明する。なお、以下に説明する実施の形態は、コンテンツ分散保存システムに本発明を適用した場合の実施形態である。
【００２１】
［１．コンテンツ分散保存システムの構成等］
始めに、図１等を参照して、本実施形態に係るコンテンツ分散保存システムの概要構成等について説明する。
【００２２】
図１は、本実施形態に係るコンテンツ分散保存システムにおける各ノード装置の接続態様の一例を示す図である。
【００２３】
図１の下部枠１０１内に示すように、ＩＸ（Internet eＸchange）３、ＩＳＰ（Internet Service Provider）４ａ,４ｂ、ＤＳＬ（Digital Subscriber Line）回線事業者（の装置）５ａ,５ｂ、ＦＴＴＨ（Fiber To The Home）回線事業者（の装置）６、及び通信回線（例えば、電話回線や光ケーブル等）７等によって、インターネット等のネットワーク（現実世界の通信ネットワーク）８が構築されている。なお、図１の例におけるネットワーク８には、データ（パケット）を転送するためのルータが、適宜挿入されているが図示を省略している。
【００２４】
このようなネットワーク８には、複数のノード装置（以下、「ノード」という）Ｎｎ（ｎ＝１，２，３・・・の何れか）がルータを介して接続されている。また、各ノードＮｎには、固有の製造番号およびＩＰ（Internet Protocol）アドレスが割り当てられている。そして、本実施形態に係るコンテンツ分散保存システムＳは、これらのノードＮｎのうち、図１の上部枠１００内に示すように、何れか複数のノードＮｎの参加により形成されるピアツーピア方式のネットワークシステムとなっている。
【００２５】
なお、図１の上部枠１００内に示すネットワーク９は、既存のネットワーク８を用いて形成された仮想的なリンクを構成するオーバーレイネットワーク９（論理的なネットワーク）である。かかるオーバーレイネットワーク９は、特定のアルゴリズム、例えば、ＤＨＴを利用したアルゴリズムにより実現される。
【００２６】
そして、コンテンツ分散保存システムＳ（言い換えれば、オーバーレイネットワーク９）に参加している各ノードＮｎには、所定桁数からなる固有の識別情報であるノードＩＤが割り当てられている。また、当該ノードＩＤは、例えば、各ノードＮｎに個別に割り当てられたＩＰアドレス或いは製造番号を共通のハッシュ関数（例えば、ＳＨＡ−１等）によりハッシュ化した値（例えば、ｂｉｔ長が１６０ｂｉｔ）であり、一つのＩＤ空間に偏りなく分散して配置されることになる。
【００２７】
なお、コンテンツ分散保存システムＳへの参加は、参加していないノードＮｎ（例えば、ノードＮ８）が、参加している任意のノードＮｎ（例えば、当該システムＳに常時参加しているコンタクトノード）に対して参加要求を示す参加メッセージを送信することによって行われる。
【００２８】
また、各ノードＮｎは、夫々、ＤＨＴを用いたルーティングテーブルを保持している。このルーティングテーブルは、コンテンツ分散保存システムＳ上における各種メッセージの転送先を規定しており、具体的には、ＩＤ空間内で適度に離れたノードＮｎのノードＩＤ、ＩＰアドレス及びポート番号を含むノード情報が複数登録されている。なお、ＩＰアドレス及びポート番号は、ネットワークアドレス情報の一例である。
【００２９】
コンテンツ分散保存システムＳに参加している１台のノードＮｎは、該システムＳに参加している全てのノードＮｎのうち、必要最低限のノードＮｎのノード情報をルーティングテーブルに登録しておき、ノード情報を知らない（記憶していない）ノードＮｎについては、各ノードＮｎ間で互いに各種メッセージを転送し合って届けてもらうようになっている。
【００３０】
このようなＤＨＴを用いたルーティングテーブルについては、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。
【００３１】
ところで、コンテンツ分散保存システムＳにおいては、内容の異なる様々なコンテンツ（例えば、映画や音楽等）データ（実際には、コンテンツデータの複製であるレプリカ）所定のファイル形式で複数のノードＮｎに分散して保存（格納）されている。
【００３２】
例えば、ノードＮ５には、タイトルがＸＸＸの映画のコンテンツデータ（ファイル）が保存されており、一方、ノードＮ３には、タイトルがＹＹＹの映画のコンテンツデータが保存されるというように、複数のノードＮｎ（以下、「コンテンツ保持ノード」という）に分散されて保存される。
【００３３】
また、これらのコンテンツデータには、夫々、コンテンツ名（タイトル）及びコンテンツＩＤ（コンテンツ毎に固有の識別情報）等の情報が付加されている。このコンテンツＩＤは、例えば、コンテンツ名＋任意の数値（或いは、当該コンテンツデータの先頭数バイトでも良い）が、上記ノードＩＤを得るときと共通のハッシュ関数によりハッシュ化されて生成される（ノードＩＤと同一のＩＤ空間に配置）。或いは、システム管理者が、コンテンツ毎に一意のＩＤ値（ノードＩＤと同一ビット長）を付与しても良い。この場合は、コンテンツ名とそのコンテンツＩＤの対応が書かれたコンテンツカタログ情報が、全ノードＮｎに配布される。
【００３４】
また、このように分散保存されているコンテンツデータの所在、つまり、当該コンテンツデータを保存したノードＮｎのノード情報と当該コンテンツデータに対応するコンテンツＩＤ等の組が含まれるインデックス情報が、当該コンテンツデータの所在を管理しているノードＮｎ（以下、「ルートノード」、又は「コンテンツデータ（コンテンツＩＤ）のルートノード」という、管理装置の一例）等により記憶（インデックスキャッシュに記憶）、管理されるようになっている。つまり、コンテンツデータを保存しているコンテンツ保持ノードのノード情報は、他のノードＮｎからの問い合わせに応じて提供可能なようにルートノードにより管理されている。
【００３５】
例えば、タイトルがＸＸＸの映画のコンテンツデータについてのインデックス情報は、そのコンテンツ（コンテンツＩＤ）のルートノードであるノードＮ４により管理され、タイトルがＹＹＹの映画のコンテンツデータについてのインデックス情報は、そのコンテンツ（コンテンツＩＤ）のルートノードであるノードＮ７により管理される。また、このようなルートノードは、例えば、コンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有するノードＮｎであるように定められる。
【００３６】
そして、あるノードＮｎのユーザが、所望するコンテンツデータを取得したい場合、当該コンテンツデータの取得を望むノードＮｎ（以下、「ユーザノード」という）は、当該ユーザにより選択されたコンテンツデータのコンテンツＩＤ及び自己のＩＰアドレス等を含むコンテンツ所在問合せ（検索）メッセージ（クエリ）を生成し、これを自己のＤＨＴを用いたルーティングテーブルにしたがって他のノードＮｎに対して送出する。つまり、ユーザノードは、コンテンツ所在問合せ（検索）メッセージを、ルートノードに向けて（ルートノード宛に）送出する（つまり、ルートノードにコンテンツデータの所在を問い合わせる）。これにより、コンテンツ所在問合せ（検索）メッセージは、コンテンツＩＤをキーとするＤＨＴルーティングによって最終的にルートノードに到着することになる。
【００３７】
なお、各ノードＮｎにおいてユーザにより選択されるべきコンテンツデータのコンテンツ名及びコンテンツＩＤ等の属性情報は、例えばコンテンツ提供サーバＳＡから全てのノードＮｎに配信されるコンテンツカタログ情報に記述されている。また、上記コンテンツ所在問合せ（検索）メッセージに含まれるコンテンツＩＤは、ユーザノードによって、コンテンツ名が上記共通のハッシュ関数によりハッシュ化されて生成されるようにしても良い。なお、ＤＨＴルーティングについては、特開２００６−１９７４００号公報等で公知であるので、詳しい説明を省略する。
【００３８】
上記コンテンツ所在問合せ（検索）メッセージを受信したルートノードは、これに含まれるコンテンツＩＤに対応するインデックス情報をインデックスキャッシュから取得して、当該インデックス情報を、該コンテンツ所在問合せメッセージの送信元であるユーザノードに対して返信する。こうしてインデックス情報を取得したユーザノードは、当該インデックス情報に含まれるあるコンテンツ保持ノードのＩＰアドレス等に基づいて当該コンテンツ保持ノードに接続して、コンテンツ送信要求メッセージを送信し、そこから当該コンテンツデータを取得することが可能になる。なお、当該インデックス情報には、例えば複数のコンテンツ保持ノードのノード情報が含まれていることもある（同一のコンテンツデータが複数のコンテンツ保持ノードに保存されている場合）。かかる場合、ユーザノードは、当該複数のコンテンツ保持ノードのうち一つのコンテンツ保持ノードを選択し、選択したコンテンツ保持ノードに接続してコンテンツデータを取得することができる。或いは、ユーザノードは、複数のコンテンツ保持ノードの夫々に接続して夫々のコンテンツ保持ノードから、ある時間毎に区切ってコンテンツデータを取得することもできる。例えば、１番目のコンテンツ保持ノードからは０以上１０分未満までのコンテンツデータを取得し、２番目のコンテンツ保持ノードからは１０分以上１０分未満までのコンテンツデータを取得する。
【００３９】
なお、ルートノードは、当該インデックス情報に含まれるＩＰアドレス等に示されたコンテンツ保持ノードに対してコンテンツ送信要求メッセージを送信し、これにより、ユーザノードは、上記コンテンツ保持ノードから当該コンテンツデータを取得することもできる。また、上記ユーザノードは、コンテンツ所在問合せメッセージがルートノードに辿り着くまでの間に、当該ルートノードと同じインデックス情報をキャッシュしているキャッシュノードから当該インデックス情報を取得することもできる。
【００４０】
また、本実施形態においては、各ユーザノードは、ルートノードから取得したインデックス情報に含まれるＩＰアドレス等に基づいてコンテンツ保持ノードに接続した後、当該コンテンツ保持ノードからストリーミングにより配信されてきたコンテンツデータを取得（受信）し、バッファリングしつつ再生出力するようになっている。このとき、バッファリングされたコンテンツデータは、ハードディスク等に記憶保存される。
【００４１】
ところで、例えば電源ＯＦＦによりノードＮｎがコンテンツ分散保存システムＳから脱退した場合、或いは、コンテンツデータを削除した場合、その分当該ノードＮｎが保存するコンテンツデータのコンテンツ保持ノードの数が減ることになるので、当該コンテンツデータをコンテンツ保持ノードから取得することが困難な場合が生じうる。当該取得困難な場合としては、例えば、コンテンツ保持ノードが多数のノードＮｎからのアクセスにより混雑しておりコンテンツデータを提供できないか、提供に時間がかかる場合等が挙げられる。このため、コンテンツ分散保存システムＳにおいて利用可能なコンテンツデータをコンテンツ提供サーバＳＡにも保存させておくようにし、各ノードＮｎは、コンテンツ保持ノードから所望のコンテンツデータを取得困難なとき、コンテンツ提供サーバＳＡに接続して当該コンテンツ提供サーバＳＡからも当該コンテンツデータを取得可能となっている。
【００４２】
なお、コンテンツ保持ノードから取得したコンテンツデータを保存したユーザノードは、当該コンテンツデータを保存したことをそのルートノードに知らせるために（言い換えれば、該システムＳに参加している他のノードＮｎに対して公開するために）、そのコンテンツデータのコンテンツＩＤ及び自己のノード情報が含まれるパブリッシュ（登録通知）メッセージを生成し、該パブリッシュメッセージを、そのルートノードに向けて（ルートノード宛に）送出する。これにより、パブリッシュメッセージは、コンテンツ所在問合せ（検索）メッセージと同じように、コンテンツＩＤをキーとするＤＨＴルーティングによってルートノードに到着することになる。そして、該ルートノードは、受信したパブリッシュメッセージに含まれるノード情報及びコンテンツＩＤの組を含むインデックス情報を登録（インデックスキャッシュ領域に記憶）することになる。こうして、上記ユーザノードは、新たに、上記コンテンツデータを保持するコンテンツ保持ノードとなる。
【００４３】
なお、上記パブリッシュメッセージに含まれるノード情報及びコンテンツＩＤの組を含むインデックス情報は、ルートノードに至るまでの転送経路におけるキャッシュノードにおいても登録（キャッシュ）される。
【００４４】
［２．ノードＮｎの構成及び機能等］
次に、図２を参照して、ノードＮｎの構成及び機能について説明する。
【００４５】
図２は、ノードＮｎの概要構成例を示す図である。
【００４６】
各ノードＮｎは、図２に示すように、演算機能を有するＣＰＵ，作業用ＲＡＭ，各種データおよびプログラムを記憶するＲＯＭ等から構成されたコンピュータとしての制御部１１と、各種データ（例えば、コンテンツデータのレプリカ、インデックス情報、ＤＨＴ等）及び各種プログラム等を記憶保存（格納）するためのＨＤ等から構成された記憶部１２と、受信されたコンテンツデータのレプリカ等を一時蓄積するバッファメモリ１３と、コンテンツデータのレプリカに含まれるエンコードされたビデオデータ（映像情報）およびオーディオデータ（音声情報）等をデコード（データ伸張や復号化等）するデコーダ部１４と、当該デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する映像処理部１５と、当該映像処理部１５から出力されたビデオ信号に基づき映像表示するＣＲＴ，液晶ディスプレイ等の表示部１６と、上記デコードされたオーディオデータをアナログオーディオ信号にＤ（Digital）／Ａ（Analog）変換した後これをアンプにより増幅して出力する音声処理部１７と、当該音声処理部１７から出力されたオーディオ信号を音波として出力するスピーカ１８と、ネットワーク８を通じて他のノードＮｎや各種サーバとの間の情報の通信制御を行うための通信部２０と、ユーザからの指示を受け付け当該指示に応じた指示信号を制御部１１に対して与える入力部（例えば、キーボード、マウス、或いは、操作パネル等）２１と、を備えて構成され、制御部１１、記憶部１２、バッファメモリ１３、デコーダ部１４、通信部２０、及び入力部２１はバス２２を介して相互に接続されている。なお、ノードＮｎとしては、パーソナルコンピュータ、ＳＴＢ（Set Top Box）、或いは、ＴＶ受信機等を適用可能である。また、記憶部１２には、コンテンツ分散保存システムＳに参加する際のアクセス先となるコンタクトノードのＩＰアドレス及びポート番号等が記憶されている。
【００４７】
このような構成において、制御部１１は、ＣＰＵが記憶部１２等に記憶されたプログラム（本発明のノード処理プログラムを含む）を読み出して実行することにより、全体を統括制御し、コンテンツ分散保存システムＳへの参加により上述したユーザノード、中継ノード、ルートノード、キャッシュノード、及びコンテンツ保持ノードの少なくとも何れか一つのノードとしての処理を行うようになっており、ユーザノードとしての処理を実行する場合には、本発明におけるアドレス情報取得手段、コンテンツデータ取得手段、及びコンテンツデータ再生手段等として機能するようになっている。なお、上記ノード処理プログラムは、例えば、ネットワーク８上の所定のサーバからダウンロードされるようにしてもよいし、例えば、ＣＤ−ＲＯＭ等の記録媒体に記録されて当該記録媒体のドライブを介して読み込まれるようにしても良い。
【００４８】
具体的には、ユーザノードの制御部１１は、上述したように、取得すべきコンテンツデータの所在を管理しているルートノードに問い合わせることにより、当該コンテンツデータを保存しているコンテンツ保持ノードに接続するためのノード情報を含むインデックス情報を取得する。そして、ユーザノードの制御部１１は、当該取得したノード情報に基づいて、コンテンツ保持ノードに接続してコンテンツデータの配信要求を行い、当該コンテンツ保持ノードからストリーム配信されてきたコンテンツデータを通信部２０を通じて受信（取得）し、当該受信したコンテンツデータをバッファメモリ１３にバッファリングしつつ、再生処理を行うようになっている。かかる再生処理によりコンテンツデータは、デコーダ部１４、映像処理部１５、表示部１６、音声処理部１７、及びスピーカ１８を通じて再生出力するようになっている。
【００４９】
なお、コンテンツデータの再生は、コンテンツデータの受信（取得）開始から、当該コンテンツデータの再生に必要なバッファ量（バッファリング量）がバッファメモリ１３に蓄積されたときに開始される。このバッファ量は、コンテンツデータの再生が途切れることがないよう十分な量に設定される。
【００５０】
ここで、ユーザノードの制御部１１は、内容の異なる複数のコンテンツデータを順次ストリーミングにより連続して取得し再生する場合、開始時に一度に夫々のコンテンツデータの所在をルートノードに問い合わせるのではなく、直前のコンテンツデータの再生終了の所定時間前に次のコンテンツデータの所在をそのルートノードに問い合わせ、当該次のコンテンツデータを保存しているコンテンツ保持ノードのノード情報を含むインデックス情報をルートノードから取得するように制御する。
【００５１】
図３は、本実施形態におけるコンテンツデータの所在の問い合わせ（コンテンツ所在問合せメッセージの送出）タイミングを示す概念図である。図３に示す例では、コンテンツデータＣ１の再生後、次に続くコンテンツデータＣ２、Ｃ３、Ｃ４は、直前のコンテンツデータＣ１、Ｃ２、Ｃ３の再生終了の直前、言い換えれば、再生開始する際にコンテンツデータの所在を問い合わせるようになっている。
【００５２】
直前のコンテンツデータの再生終了のどの程度の時間（所定時間）前に次のコンテンツデータの所在をそのルートノードに問い合わせるかについては、次のコンテンツデータの再生開始に必要なバッファ量に基づいて決定されることが望ましい。つまり、再生開始に必要なバッファ量がバッファメモリ１３に蓄積されるのに要する時間より前に、所在をルートノードに問い合わせ、コンテンツ保持ノードからそのコンテンツデータの受信を開始することで、直前のコンテンツデータの再生終了後、速やかに次のコンテンツデータの再生を開始できるのである。
【００５３】
再生開始に必要なバッファ量は、次のコンテンツデータのビットレート（単位時間当たりに処理（デコード等の再生処理）されるデータ量（ｂｐｓ））に応じて変化する。例えば、次のコンテンツデータのビットレートが高いほど、例えば１秒間により多くのデータが処理されるので、バッファ量を多くする必要がある。従って、この場合、バッファリングする時間が長くなるので、ルートノードへの問い合わせのタイミングが早めに行われるよう、上記所定時間が長く設定される。一方、次のコンテンツデータのビットレートが低いほど、バッファ量は少なくとも良く、バッファリングする時間が短くなるので、上記所定時間が短く設定される。従って、上記所定時間は、次のコンテンツデータのビットレートに基づいて決定されるとも言える。
【００５４】
図４は、ビットレートの異なる３つのコンテンツデータに関し、時間の経過とともにバッファメモリ１３に蓄積されるデータ量（破線）と、再生処理されるデータ量（実線）との関係の一例を示す図である。図４において、ビットレートの最も高いコンテンツデータＣ２については、ルートノードへの問い合わせタイミングが、直前のコンテンツデータＣ１の再生終了のＫ分前（言い換えれば、コンテンツデータＣ２の再生開始のＫ分前）になっている。また、ビットレートの最も低いコンテンツデータＣ３については、ルートノードへの問い合わせタイミングが、直前のコンテンツデータＣ２の再生終了のＬ分前（言い換えれば、コンテンツデータＣ３の再生開始のＬ分前）になっている。当該ルートノードへの問い合わせは、例えば、コンテンツデータのビットレートが２Ｍｂｐｓ以上の場合、５分前に、ビットレートが５００ｋｂｐｓ以上２Ｍｂｐｓ未満の場合、２分前に、ビットレートが５００ｋｂｐｓ未満の場合、１分前に、夫々行われるように、制御部１１により設定される。
【００５５】
更に、ユーザノードの制御部１１は、取得すべきコンテンツデータのビットレートに応じて当該コンテンツデータを保存しているコンテンツ保持ノードの数を決定し、当該数分の当該コンテンツ保持ノードのノード情報を、夫々の所在を管理しているルートノードから取得するように構成すればより望ましい。例えば、コンテンツデータのビットレートが２Ｍｂｐｓ以上の場合、コンテンツ保持ノードの数を１０とし、ビットレートが５００ｋｂｐｓ以上２Ｍｂｐｓ未満の場合、コンテンツ保持ノードの数を５とし、ビットレートが５００ｋｂｐｓ未満の場合、コンテンツ保持ノードの数を３とすると、いうように、取得すべきコンテンツデータのビットレートが高いほど、コンテンツ保持ノードの数を多く確保する。これは、コンテンツデータのビットレートが高いほど、再生に必要なバッファ量が蓄積されるのに要する時間が長くなるので、かかる時間を少しでも短縮するために、より多くのコンテンツ保持ノードから、ある時間毎に区切られたコンテンツデータを取得するという趣旨である。
【００５６】
［３．コンテンツ分散保存システムＳの動作］
次に、図５及び図６を参照して、コンテンツ分散保存システムＳの動作について説明する。
【００５７】
図５は、ノードＮｎの制御部１１におけるメイン処理を示すフローチャートである。また、図６は、図５におけるメッセージ受信処理の詳細を示すフローチャートである。
【００５８】
図５に示す処理は、任意のノードＮｎにおいて例えば電源ＯＮになった場合に開始され、コンテンツ分散保存システムＳへの参加処理が実行される（ステップＳ１）。この参加処理においては、当該ノードＮｎの制御部１１は、記憶部１２からコンタクトノードのＩＰアドレス及びポート番号を取得し、これに基づきコンタクトノードにネットワーク８を介して接続し、参加要求を示す参加メッセージ（自己のノードＩＤ及びノード情報等を含む）を送信する。これにより、当該ノードＮｎには、当該システムＳに参加している他のノードＮｎからルーティングテーブルが送信されることになり、受信したルーティングテーブルに基づき自己のルーティングテーブルを生成し、コンテンツ分散保存システムＳに参加が完了することになる。
【００５９】
こうしてコンテンツ分散保存システムＳへの参加処理が完了すると、制御部１１は、電源ＯＦＦの指示（例えば、ユーザから入力部２１を介した電源ＯＦＦ操作指示）があった場合には（ステップＳ２：ＹＥＳ）、当該処理を終了する。一方、電源ＯＦＦの指示がない場合には（ステップＳ２：ＮＯ）、制御部１１は、再生コンテンツリストを取得済であるか否かを判別し（ステップＳ３）、当該再生コンテンツリストを取得済でない場合には（ステップＳ３：ＮＯ）、ステップＳ４に進み、当該再生コンテンツリストを取得済である場合には（ステップＳ３：ＹＥＳ）、ステップＳ６に進む。
【００６０】
ここで、再生コンテンツリストには、連続して再生されるべき各コンテンツデータの再生順番、コンテンツ名及びコンテンツＩＤ等が記載されている。
【００６１】
また、再生コンテンツリストは、例えば管理者側から、コンテンツ視聴のために店舗に設置されたノードＮｎに電子メールで配信される。
【００６２】
或いは、ユーザからの入力部２１を介した指示の下、各ノードＮｎにおいて作成される。かかる場合、ユーザが、例えばコンテンツカタログ情報から所望の（視聴したい）数十個のコンテンツデータを入力部２１から選択（例えば、コンテンツ名で選択）することになる。
【００６３】
ステップＳ４では、制御部１１は、再生コンテンツリストが受信又は作成され、例えば記憶部１２における所定の記憶領域に格納されているか否かを判別し、格納されている場合には（ステップＳ４：ＹＥＳ）、ステップＳ５に進み、格納されていない場合には（ステップＳ４：ＮＯ）、ステップＳ１６に進む。
【００６４】
ステップＳ５では、制御部１１は、再生コンテンツリストを記憶部１２から取得し（ＲＡＭに読み込み）、ステップＳ６に進む。
【００６５】
ステップＳ６では、制御部１１は、これから再生すべきコンテンツデータの再生順番が１番目であるか否かを判別し、１番目である場合には（ステップＳ６：ＹＥＳ）、ステップＳ７に進み、１番目でない場合には（ステップＳ６：ＮＯ）、ステップＳ９に進む。
【００６６】
ステップＳ７では、制御部１１は、当該１番目のコンテンツデータの所在を既にルートノードに問い合わせ、インデックス情報を取得し、１又は複数のコンテンツ保持ノードへコンテンツ送信要求をしているか否かを判別する。そして、コンテンツ送信要求済である場合には（ステップＳ７：ＹＥＳ）、ステップＳ９に進む。一方、コンテンツ送信要求済でない場合には（ステップＳ７：ＮＯ）、制御部１１は、当該１番目のコンテンツデータのコンテンツＩＤ等を含むコンテンツ所在問合せメッセージ（クエリ）をルートノードに向けて送出することによりインデックス情報を取得し、続いて、取得したインデックス情報に基づき１又は複数のコンテンツ保持ノードに接続しコンテンツ送信要求メッセージを送信し（ステップＳ８）、ステップＳ９に進む。
【００６７】
ステップＳ９では、制御部１１は、コンテンツ保持ノードからストリーム配信され、通信部２０を介してバッファメモリ１３にバッファリングされているコンテンツデータが再生開始に必要なバッファ量蓄積されたか否かを判別し、蓄積された場合には（ステップＳ９：ＹＥＳ）、ステップＳ１０に進み、蓄積されていない場合には（ステップＳ９：ＮＯ）、ステップＳ１１に進む。
【００６８】
ステップＳ１０では、制御部１１は、バッファメモリ１３に蓄積されたコンテンツデータの再生処理を開始する。
【００６９】
ステップＳ１１では、制御部１１は、再生中のコンテンツデータが再生コンテンツリストの最後のコンテンツデータであるか否かを判別し、最後のコンテンツデータである場合には（ステップＳ１１：ＹＥＳ）、ステップＳ１６に進み、最後のコンテンツデータでない場合には（ステップＳ１１：ＮＯ）、ステップＳ１２に進む。
【００７０】
ステップＳ１２では、制御部１１は、再生コンテンツリストから次に再生すべきコンテンツデータの情報（例えばビットレート）を取得済であるか否かを判別し、取得済でない場合には（ステップＳ１２：ＮＯ）、ステップＳ１３に進み、取得済である場合には（ステップＳ１２：ＹＥＳ）、ステップＳ１４に進む。
【００７１】
ステップＳ１３では、制御部１１は、例えば次に再生すべきコンテンツデータのビットレートを例えばコンテンツカタログ情報から取得し、上述したように、当該ビットレートに基づいてルートノードへの問い合わせ時間（例えば、５分）及びコンテンツ保持ノードの数（例えば、１０）を決定する。なお、ビットレートは、再生コンテンツリストに記載されていても良い。
【００７２】
次いで、制御部１１は、現在再生中のコンテンツデータの再生終了の上記決定された時間前になったか否かを判別し（ステップＳ１４）、当該時間前になった場合には（ステップＳ１４：ＹＥＳ）、ステップＳ１５に進み、当該時間前になっていない場合には（ステップＳ１４：ＮＯ）、ステップＳ１６に進む。
【００７３】
ステップＳ１５では、制御部１１は、上記次に再生すべきコンテンツデータのコンテンツＩＤ等を含むコンテンツ所在問合せメッセージ（クエリ）をルートノードに向けて送出することによりインデックス情報を取得し、続いて、取得したインデックス情報に基づき１又は複数のコンテンツ保持ノードに接続しコンテンツ送信要求メッセージを送信する。ここで、ステップＳ１３で決定された数分のコンテンツ保持ノードのノード情報が取得され、当該数分のコンテンツ保持ノードに対してコンテンツ送信要求が行われることになる。
【００７４】
ステップＳ１６では、制御部１１は、コンテンツデータの受信中であるか否かを判別し、受信中である場合には（ステップＳ１６：ＹＥＳ）、ステップＳ１７に進み、受信中でない場合には（ステップＳ１６：ＮＯ）、ステップＳ２０に進む。
【００７５】
ステップＳ１７では、制御部１１は、受信され、バッファメモリ１３にバッファリングされているコンテンツデータを所定のファイル形式で記憶部１２に書き込む（保存）ように制御する。
【００７６】
次いで、制御部１１は、当該コンテンツデータの全部が書き込まれたか否かを判別し（ステップＳ１８）、書き込まれていない場合には（ステップＳ１８：ＮＯ）、ステップＳ２０に進み、書き込まれた場合には（ステップＳ１８：ＹＥＳ）、当該コンテンツデータのルートノードに向けて上述したパブリッシュメッセージを送出し（ステップＳ１９）た後、ステップＳ２０に進む。
【００７７】
ステップＳ２０では、制御部１１は、メッセージを受信したか否かを判別し、受信していない場合には（ステップＳ２０：ＮＯ）、ステップＳ２に戻り、受信した場合には（ステップＳ２０：ＹＥＳ）、メッセージ受信処理を行う（ステップＳ２１）。
【００７８】
このメッセージ受信処理においては、図６に示すように、制御部１１は、受信したメッセージがパブリッシュメッセージであるか否かを判別し（ステップＳ２１１）、パブリッシュメッセージである場合には（ステップＳ２１１：ＹＥＳ）、ステップＳ２１２に進み、パブリッシュメッセージでない場合には（ステップＳ２１１：ＮＯ）、ステップＳ２１５に進む。
【００７９】
ステップＳ２１２では、制御部１１は、受信したパブリッシュメッセージに含まれるノード情報及びコンテンツＩＤの組をインデックス情報としてインデックスキャッシュに記憶する。
【００８０】
次いで、制御部１１は、自己（自ノード）がルートノードであるか否かを判別（つまり、自己のルーティングテーブルを参照して、当該パブリッシュメッセージに含まれるコンテンツＩＤと最も近いノードＩＤが自分であるか否かを判別）し（ステップＳ２１３）、自己がルートノードでない（つまり、中継ノードである）場合には（ステップＳ２１３：ＮＯ）、ステップＳ２１４に進み、自己がルートノードである場合には（ステップＳ２１４：ＹＥＳ）、図５に示す処理に戻る。
【００８１】
ステップＳ２１４では、制御部１１は、上記パブリッシュメッセージを、自己のルーティングテーブルにしたがって他のノードＮｎ（つまり、当該コンテンツＩＤと最も近い（例えば、上位桁がより多く一致する）ノードＩＤを有するノードＮｎ）に対して転送し、図５に示す処理に戻る。
【００８２】
ステップＳ２１５では、制御部１１は、受信したメッセージがコンテンツ所在問合せメッセージ（クエリ）であるか否かを判別し、コンテンツ所在問合せメッセージである場合には（ステップＳ２１５：ＹＥＳ）、ステップＳ２１６に進み、コンテンツ所在問合せメッセージない場合には（ステップＳ２１５：ＮＯ）、ステップＳ２１７に進む。
【００８３】
ステップＳ２１６では、制御部１１は、コンテンツ所在問合せメッセージに含まれるコンテンツＩＤに対応付けられた１又は複数のノード情報を含むインデックス情報をインデックスキャッシュから取得して、当該インデックス情報を、該コンテンツ所在問合せメッセージの送信元であるユーザノードに対して返信し、図５に示す処理に戻る。
【００８４】
ステップＳ２１７では、制御部１１は、受信したメッセージがコンテンツ送信要求メッセージであるか否かを判別し、コンテンツ送信要求メッセージでない場合には（ステップＳ２１７：ＮＯ）、ステップＳ２１９に進む。一方、コンテンツ送信要求メッセージである場合には（ステップＳ２１７：ＹＥＳ）、当該コンテンツ送信要求メッセージを送信したユーザノードに対して、当該要求に係るコンテンツデータをストリーム配信し（ステップＳ２１８）、図５に示す処理に戻る。
【００８５】
なお、ステップＳ２１９におけるその他のメッセージ処理では、上記メッセージ以外のメッセージ（例えば参加メッセージ等）が受信された場合の処理が行われる。
【００８６】
以上説明したように、上記実施形態によれば、ユーザノードは、内容の異なる複数のコンテンツデータを順次ストリーミングにより連続して取得し再生する場合、直前のコンテンツデータの再生終了の所定時間前に次のコンテンツデータの所在をそのルートノードに問い合わせ、当該次のコンテンツデータを保存しているコンテンツ保持ノードのノード情報を含むインデックス情報をルートノードから取得するように構成したので、時間の経過によりコンテンツ保持ノードが脱退するなどの状況が変わるという事態を回避でき、したがって、再度、ルートノードに問い合わせる必要もなく、コンテンツ提供サーバＳＡからコンテンツデータを取得するために当該コンテンツ提供サーバＳＡの負荷が増大するということを防止しつつ、これらのコンテンツデータをより効率良く取得し、適切なタイミングで再生することができる。
【００８７】
また、上記所定時間は、次のコンテンツデータの再生開始に必要なバッファ量を考慮し、当該コンテンツデータのビットレートに基づいて決定されるように構成したので、最適なタイミングで次のコンテンツデータの所在をそのルートノードに問い合わせることができ、ひいては、直前のコンテンツデータの再生終了後速やかに次のコンテンツデータの再生を開始することができる。
【００８８】
更に、取得すべきコンテンツデータのビットレートに応じて当該コンテンツデータを保存しているコンテンツ保持ノードの数を決定し、当該数分の当該コンテンツ保持ノードのノード情報を、夫々の所在を管理しているルートノードから取得するように構成したので、再生に必要なバッファ量が蓄積されるのに要する時間を短縮することができる。
【００８９】
なお、上記実施形態におけるコンテンツ分散保存システムＳは、ＤＨＴを利用したアルゴリズムによって形成されることを前提として説明したが、本発明はこれに限定されるものではない。
【図面の簡単な説明】
【００９０】
【図１】本実施形態に係るコンテンツ分散保存システムにおける各ノード装置の接続態様の一例を示す図である。
【図２】ノードＮｎの概要構成例を示す図である。
【図３】本実施形態におけるコンテンツデータの所在の問い合わせタイミングを示す概念図である。
【図４】ビットレートの異なる３つのコンテンツデータに関し、時間の経過とともにバッファメモリ１３に蓄積されるデータ量と、再生処理されるデータ量との関係の一例を示す図である。
【図５】ノードＮｎの制御部１１におけるメイン処理を示すフローチャートである。
【図６】図５におけるメッセージ受信処理の詳細を示すフローチャートである。
【符号の説明】
【００９１】
８  ネットワーク
９  オーバーレイネットワーク
１１  制御部
１２  記憶部
１３  バッファメモリ
１４  デコーダ部
１５  映像処理部
１６  表示部
１７  音声処理部
１８  スピーカ
２０  通信部
２１  入力部
２２  バス
Ｎｎ  ノード
Ｓ  コンテンツ分散保存システム
【図１】
2008310621.tif 000003
【図２】
2008310621.tif 000004
【図３】
2008310621.tif 000005
【図４】
2008310621.tif 000006
【図５】
2008310621.tif 000007
【図６】
2008310621.tif 000008