JP2006072715A - コンテンツ配信システムおよびコンテンツ配信方法 - Google Patents

Abstract

【課題】コンテンツ配信システムのサービス範囲を拡大する場合に、ＩＴリソースの増設をより小さく抑える。
【解決手段】クライアント８各々は、ストレージ８５と、ストレージ８５の一部または全部をリソースプールとしてローカルサーバ６に登録する登録手段と、コンテンツの配信要求をローカルサーバ６に送信する要求手段と、を有する。ローカルサーバ６は、リソースプール管理テーブルとコンテンツ管理テーブルとを記憶する記憶手段と、クライアント８各々からコンテンツの配信要求を受け付ける要求受付手段と、コンテンツを格納しているリソースプールを特定する特定手段と、特定したリソースプールを有するクライアント８にコンテンツの配信指示を送信する配信指示手段と、を有する。
【選択図】 図１４

Description

本発明は、コンテンツ配信技術に関する。

近年、ビデオ・オン・デマンド（ＶＯＤ）や通信カラオケなどに代表されるコンテンツ配信ネットワーク（ＣＤＮ）に関する技術開発が行われ、様々なコンテンツ配信システムが存在する。特にコンテンツ配信におけるサーバ負荷やトラフィックの分散に関する技術開発は数多く実施されている。例えば、特許文献１には、複数のキャッシュサーバ各々に配置されたビデオデータの断片を、クライアントからのアクセス状況に応じて配置を変更し、キャッシュサーバの負荷の分散化と平準化を図る分散ビデオサーバシステムが記載されている。

特開平９−１６３３５３号公報

ところで、コンテンツ配信サービスのサービス範囲を拡大する場合、システムを構成するＩＴリソース設備を増築しなければなない。例えば、サービスの利用者（エンドユーザ）が増加するに従って、地理的・物理的に広範囲にわたって、コンテンツ配信システムのＩＴリソース設備を増築する必要がある。なお、特許文献１では、既存のコンテンツ配信システムにおけるＩＴリソースの有効活用を目的としているが、サービス範囲を拡大する場合に増設するＩＴリソースについては考慮されていない。

本発明は上記事情に鑑みてなされたものであり、本発明の目的は、コンテンツ配信システムに要求されるＩＴリソースの増設をより小さく抑えることにある。

上記課題を解決するために、本発明では、エンドユーザが使用するクライアントのストレージを、コンテンツ配信システムのコンテンツ格納領域（リソースプール）として利用する。

例えば、コンテンツ配信システムであって、コンテンツの配信を指示する配信サーバと、少なくとも１つのクライアントとを有する。そして、クライアント各々は、データを記憶するためのクライアントストレージと、クライアントストレージの一部または全部を、コンテンツを格納するためのリソースプールとして、配信サーバに登録する登録手段と、コンテンツの配信要求を受け付けて、コンテンツの配信要求を配信サーバに送信する要求手段と、を有する。配信サーバは、クライアント各々が登録したリソースプールを管理するためのリソースプール管理テーブルと、コンテンツと当該コンテンツを格納しているリソースプールとを対応付けたコンテンツ管理テーブルと、を記憶する配信サーバ記憶手段と、 クライアント各々から、コンテンツの配信要求を受け付ける要求受付手段と、コンテンツ管理テーブルを読み出して、要求受付手段が受け付けたコンテンツを格納しているリソースプールを特定する特定手段と、特定手段が特定したリソースプールを有するクライアントに、コンテンツの配信指示を送信する配信指示手段と、を有する。

本発明では、エンドユーザが使用するクライアントのストレージを、コンテンツ配信システムのコンテンツ格納領域（リソースプール）として利用することで、ＩＴリソースの増設をより小さく抑えることができる。

以下、本発明の実施の形態について説明する。

図１は、本発明の一実施形態が適用されたコンテンツ配信システムの全体構成図である。図示するように、本実施形態のコンテンツ配信システムは、管理センタ１と、少なくとも１つのローカルドメイン５とを有する。そして、管理センタ１は、管理サーバ２と、ストレージ装置３とを有する。管理サーバ２は、ストレージ装置３に格納されているコンテンツを、各ローカルサーバ６を介してクライアント８に配信する装置である。ストレージ装置３は、管理サーバ２の外部記憶装置であって、コンテンツなどのリポジトリ（倉庫）としての役割を果たす。なお、管理サーバ２は、インターネット４などのドメイン間ネットワーク４により、各ローカルドメイン５のローカルサーバ６またはクライアント８と、接続されている。

なお、コンテンツは、音楽、映像、画像、プログラム、データベース、または、これらを組み合わせた情報（データ）である。具体的なコンテンツの例としては、映画のビデオデータや、カラオケ用の音楽データなどがあげられる。

ローカルドメイン５各々は、ローカルサーバ６と、少なくとも１つのクライアント８と、を有する。ローカルサーバ６は、当該ローカルサーバ６が所属するローカルドメイン５内の各クライアント８を管理し、また、各クライアント８にコンテンツを配信する。クライアント８は、当該クライアント８のストレージ、または、他のクライアント８のストレージに格納されたコンテンツを再生し、出力装置に出力する。なお、ローカルドメイン５内のローカルサーバ６およびクライアント８各々は、ドメイン内ネットワーク７によりそれぞれ接続されている。また、ローカルドメイン５内のローカルサーバ６およびクライアント８各々は、ドメイン内ネットワーク７およびドメイン間ネットワーク４を介して、管理サーバ２および他のローカルドメイン５内の各装置６、８と接続されている。

ローカルドメイン５は、ネットワーク上のコンピュータを管理する所定の単位（領域、エリア）である。例えば、国毎、または、道府県毎にローカルドメイン５を設定することが考えられる。また、インターネットマンション（Internet-ready apartment）を、１つのローカルドメイン５とすることも考えられる。インターネットマンションは、各部屋にインターネットに接続するための設備が備え付けられているマンンションである。インターネットマンションでは、一般的に、マンション内でインターネットと接続したＬＡＮ（ドメイン内ネットワーク７）を構築し、各部屋にコンピュータを接続するためのモジュラジャックを配置している。

次に、管理センタ１の管理サーバ２およびストレージ装置３の詳細について説明する。

図２は、管理サーバ２およびストレージ装置３の概略構成図である。

管理サーバ２は、図示するように、コンテンツ管理部２１と、顧客情報管理部２２と、ローカルサーバ管理部２３と、ネットワークインタフェース部２４と、ユーザインタフェース部２５と、を有する。コンテンツ管理部２１は、ストレージ装置３に格納されたコンテンツ管理テーブル３１およびオリジナルコンテンツ３４を管理する。顧客情報管理部２２は、ストレージ装置３に格納された顧客管理テーブル３２を管理する。ローカルサーバ管理部２３は、ストレージ装置３に格納されたローカルサーバ管理テーブル３３を管理する。ネットワークインタフェース部２４は、ドメイン間ネットワーク４および各ドメイン内ネットワーク７を介して、ローカルサーバ６など外部システムとデータの送受信を行う。ユーザインタフェース部２５は、システム管理者の指示（操作、入力）を受け付け、また、各種のデータを出力装置に出力する。

ストレージ装置３には、管理サーバ２がコンテンツを配信するために必要な情報が記憶されている。ストレージ装置３は、図示するように、コンテンツ管理テーブル３１と、顧客管理テーブル３２と、ローカルサーバ管理テーブル３３と、少なくとも１つのコンテンツ３４と、を有する。ストレージ装置３に格納されたコンテンツ３４は、本コンテンツ配信システムにおいて、オリジナルなコンテンツである。コンテンツ３４は、各クライアント８からの要求に応じて配信され、各クライアント８のストレージに記憶される。なお、コンテンツ管理テーブル３１、顧客管理テーブル３２、および、ローカルサーバ管理テーブル３３については、後述する。

次にローカルサーバ６の詳細について説明する。

図３はローカルサーバ６の概略構成図である。ローカルサーバ６は、図示するように、配信処理部６１と、リソース管理部６２と、ネットワークインタフェース部６３と、記憶部６４と、を有する。配信処理部６１は、クライアント８からのコンテンツ配信要求を受け付けて、要求されたコンテンツをクライアント８に配信する。リソース管理部６２は、記憶部６４に記憶された各テーブル６４１、６４２を管理する。ネットワークインタフェース部６３は、ドメイン内ネットワーク７を介して、同一ローカルドメイン内のクライアント８とデータの送受信を行う。また、ネットワークインタフェース部６３は、ドメイン内ネットワーク７およびドメイン間ネットワーク４を介して、管理サーバ２または他のローカルドメイン５の各装置６、８とデータの送受信を行う。記憶部６４は、後述するリソースプール管理テーブル６４１と、ドメイン内コンテンツ管理テーブル６４２とを有する。

次にクライアント８の詳細について説明する。

図４は、クライアント８の概略構成図である。クライアント８は、図示するように、要求処理部８１と、ストレージ管理部８２と、ネットワークインタフェース部８３と、ユーザインタフェース８４と、ストレージ８５と、を有する。要求処理部８１は、ユーザインタフェース部８４を介して入力されたコンテンツ配信要求を受け付けて、ローカルサーバ６にコンテンツを要求する。ストレージ管理部８２は、ストレージ８５に記憶された各テーブル８５１、８５２およびコンテンツ８５３を管理する。ネットワークインタフェース部８３は、ドメイン内ネットワーク７を介して、同一ローカルドメイン５内のローカルサーバ６や他のクライアント８と、データの送受信を行う。また、ネットワークインタフェース部８３は、ドメイン内ネットワーク７およびドメイン間ネットワーク４を介して、管理サーバ２や他のローカルドメイン５の各装置６、８と、データの送受信を行う。ユーザインタフェース部８４は、当該クライアントを使用するユーザの指示（操作、入力）を受け付け、また、各種のデータを出力装置に出力する。

ストレージ８５は、各種のデータを記憶する記憶装置である。本実施形態においては、クライアント８各々は、当該クライアント８が有するストレージ８５の一部または全部を、コンテンツを格納するためのリソースプール（コンテンツ格納領域）としてローカルサーバ６に登録（提供）する。ストレージ８５の一部または全部をリソースプールとして登録することにより、クライアント８各々は、コンテンツ配信を要求し、配信されたコンテンツを再生することができる。

ストレージ８５は、リソースプールとして登録した領域に、ストレージ管理テーブル８５１と、クライアントコンテンツ管理テーブル８５２と、コンテンツ８５３とを有する。クライアント８のストレージ８５に格納されたコンテンツ８５３は、管理センタ１のストレージ装置３に記憶されたオリジナルのコンテンツ３４のコピーである。なお、ストレージ管理テーブル８５１、および、クライアントコンテンツ管理テーブル８５２については、後述する。なお、ストレージ８５は、リソースプール以外の領域には、自クライアント８固有の各種データ（不図示）が格納されている。

以上説明した、管理サーバ２、ローカルサーバ６、および、クライアント８は、いずれも例えば図５に示すようなＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、キーボードやマウスなどの入力装置９０４と、ディスプレイやプリンタなどの出力装置９０５と、ネットワーク接続するための通信制御装置９０６と、これらの各装置を接続するバス９０７と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、管理サーバ２、ローカルサーバ６、および、クライアント８の各機能は、管理サーバ２用のプログラムの場合は管理サーバ２のＣＰＵ９０１が、ローカルサーバ６用のプログラムの場合はローカルサーバ６のＣＰＵ９０１が、そして、クライアント８用のプログラムの場合はクライアント８のＣＰＵ９０１が、それぞれ実行することにより実現される。

なお、管理センタ１のストレージ装置３は、管理サーバ２の外部記憶装置９０３またはメモリ９０２として用いられる。また、ローカルサーバ６の記憶部６４には、ローカルサーバ６のメモリ９０２または外部記憶装置９０３が用いられる。また、クライアント８のストレージ８５には、クライアント８のメモリ９０２または外部記憶装置９０３が用いられる。

次に、管理サーバ１のストレージ装置３に記憶された各テーブルについて説明する。

図６は、コンテンツ管理テーブル３１の一例を示した図である。コンテンツ管理テーブル３１は、コンテンツ毎に、コンテンツＩＤ６１と、コンテンツ名６２と、データサイズ６３と、コピー上限６４と、コピー回数６５と、を有する。コンテンツＩＤ６１は、各コンテンツを識別するための識別情報である。コンテンツ名６２は、コンテンツの名称である。データサイズ６３は、コンテンツのデータの大きさである。コピー上限６４は、コンテンツをローカルドメイン５のクライアント８にコピー可能な（すなわち、配信可能な）最大回数である。コピー回数６５は、コンテンツをローカルドメイン５のクライアント８にコピー（配信）した回数である。例えば、コンテンツＩＤ６１が「Ｃ−００１」６１ａのコンテンツは、コンテンツ名６２が「ＣｏｎｔｅｎｔＡ」、データサイズ６３が「５００Ｍバイト」、コピー上限６４が「３」、コピー回数６５が「３」である。

図７は、顧客管理テーブル３２の一例を示した図である。顧客管理テーブル３２は、顧客毎に、ユーザＩＤ７１と、ユーザ名７２と、所属ドメイン名７３と、を有する。ユーザＩＤ７１は、各ユーザを識別するための識別情報である。ユーザ名７２は、ユーザの名称である。所属ドメイン名７３は、ユーザ（すなわち、当該ユーサが使用しているクライアント８）が所属しているローカルドメイン５の名称または識別情報である。例えば、ユーザＩＤ７１が「Ｕ−００１」７１ａのユーザは、ユーザ名７２が「ＵｓｅｒＡ」で、所属ドメイン名７３が「ローカルドメイン１」である。

図８は、ローカルサーバ管理テーブル３３の一例を示した図である。ローカルサーバ管理テーブル３３は、ローカルサーバ６毎に、サーバＩＤ８１と、所属ドメイン名８２と、所有コンテンツＩＤ８３と、を有する。サーバＩＤ８１は、ローカルサーバ６を識別するための識別情報である。所属ドメイン名８２は、各ローカルサーバ２が所属するローカル
ドメインの名称または識別情報である。所有コンテンツＩＤ８３には、対応するローカルドメイン内に存在する各コンテンツのコンテンツＩＤがそれぞれ設定される。すなわち、所有コンテンツＩＤ８３には、当該ローカルドメインに所属するクライアント８各々のリソースプールに格納（コピー）されたコンテンツのコンテンツＩＤが設定される。
図示する例では、サーバＩＤ８１が「Ｓ−００１」８１ａのローカルサーバ６は、所属ドメイン名８２が「ローカルドメイン１」で、ローカルドメイン１内に存在するコンテンツＩＤ８３は「Ｃ−００１」と「Ｃ−００３」であることを示している。

次に、ローカルサーバ６の記憶部６４に記憶された各テーブルについて説明する。

図９は、リソースプール管理テーブル６４１の一例を示した図である。リソースプール管理テーブル６４１は、ローカルドメイン内に存在するクライアント８各々が登録したリソースプールを管理するためのテーブルである。リソースプール管理テーブル６４１は、リソースプール毎に、リソースプールＩＤ９１と、ユーザＩＤ９２と、登録ストレージ容量９３と、未使用容量９４と、アドレス９５と、を有する。リソースプールＩＤ９１は、リソースプールとして登録したクライアント８の各ストレージ８５を識別するための識別情報である。ユーザＩＤ９２は、ユーザを識別する識別情報である。ユーザＩＤ９２には、当該リソースプール（ストレージ８５）を有するクライアント８を使用するユーザのユーザＩＤが設定される。登録ストレージ容量９３は、リソースプールとして登録したストレージの容量である。未使用容量９４は、登録ストレージ容量９３の中で、未使用状態のストレージの容量である。

アドレス９５は、リソースプールの位置情報である。すなわち、アドレス９５には、ネットワーク上のクライアント８のアドレス（例えば、ＩＰアドレス、ＤＮＳ名）と、当該クライアント８におけるリソースプールの場所とを含む。ローカルサーバ６は、当該アドレス９５を用いることによりリソースプールに透過的にアクセスすることができる。このようなアドレス９５は、例えば、ＩＰ−ＳＡＮのｉＳＣＳＩ技術を用いることにより実現することができる。なお、アドレス９５は、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバが動的に設定することとしてもよい。また、ローカルサーバ６が、クライアント８毎にあらかじめ定められたアドレス９５を設定することとしてもよい。

図示する例では、リソースプールＩＤ９１が「Ｐ−００１」９１ａのリソースプールは、ユーザＩＤ９２が「Ｕ−００１」で、登録ストレージ容量９３が「３０Ｇバイト」で、未使用ストレージ容量９４が「２０Ｇバイト」である。

図１０は、ドメイン内コンテンツ管理テーブル６４２の一例を示した図である。ドメイン内コンテンツ管理テーブル６４２は、ローカルドメイン内に存在する各コンテンツが、どのリソースプールに格納されているかを示すテーブルである。ドメイン内コンテンツ管理テーブル６４２は、コンテンツＩＤ１０１と、当該コンテンツＩＤ１０１のコンテンツが格納されているリソースプールＩＤ１０２と、を有する。図示する例では、コンテンツＩＤ１０１が「Ｃ−００１」１０１ａのコンテンツは、リソースプールＩＤ１０２が「Ｐ−００１」のリソースプールに格納されていることを示している。

次に、クライアント８のストレージ８５に記憶された各テーブルについて説明する。

図１１は、ストレージ管理テーブル８５１の一例を示す図である。ストレージ管理テーブル８５１は、ストレージ８５に関する情報が記憶されたテーブルである。ストレージ管理テーブル８５１は、全容量１１１と、登録ストレージ容量１１２と、リソースプールＩＤ１１３と、ユーザＩＤ１１４と、を有する。全容量１１１は、ストレージ８５の全記憶容量である。登録ストレージ容量１１２は、全容量１１１の中からリソースプールとして登録した記憶容量である。リソースプールＩＤ１１３は、当該クライアント８のリソースプールの識別情報である。ユーザＩＤ１１４は、当該クライアント８を使用するユーザの識別情報である。図示する例では、ストレージ８５の全容量１１１は「１２０Ｇバイト」で、登録ストレージ容量１１２は「３０Ｇバイト」で、リソースプールＩＤ１１３は「Ｐ−００１」で、ユーザＩＤ１１４は「Ｕ−００１」である。

図１２は、クライアントコンテンツ管理テーブル８５２の一例を示す図である。クライアントコンテンツ管理テーブル８５２は、各クライアント８のリソースプールに格納されたコンテンツを管理するテーブルである。クライアントコンテンツ管理テーブル８５２は、コンテンツ毎に、コンテンツＩＤ１２１と、コンテンツ名１２２と、データサイズ１２３とを有する。コンテンツＩＤ１２１と、コンテンツ名１２２と、データサイズ１２３は、図６に示すコンテンツ管理テーブル３１のコンテンツＩＤ６１と、コンテンツ名６２と、データサイズ６３と同様である。図示する例では、リソースプールには、コンテンツＩＤ１２１が「Ｃ−００１」１２１ａ、コンテンツ名１２２が「ＣｏｎｔｅｎｔＡ」、データサイズ１２３が「５００Ｍバイト」のコンテンツが格納されていることを示している。

次に、ストレージ８５の一部または全部を、リソースプールとしてローカルサーバ６に登録する処理を説明する。クライアント８各々は、自クライアント８のストレージ８５の一部または全部を、リソースプールとして同一のローカルドメイン５内のローカルサーバ６に登録することにより、コンテンツ配信システムが提供するコンテンツの配信を受けることができる。すなわち、ローカルサーバ６は、当該ローカルサーバ６が所属するローカルドメイン５のクライアント８各々からリソースプールの登録を受け付け、各リソースプールを一元管理する。そして、ローカルサーバ６は、受け付けた各リソースプールに、管理センタ１のストレージ装置３（または、他のローカルドメイン５のリソースプール）に格納されたコンテンツを、コピー（または、移動）する。すなわち、ローカルサーバ６に登録された各リソースプールは、当該ローカルドメイン５の各クライアント８にコンテンツを配信するための共通のコンテンツ格納領域である。

図１３は、ローカルサーバ６にリソースプールを登録するリソースプール登録処理の処理フローである。まず、クライアント８のストレージ管理部８２は、ユーザインタフェース部８４を介して入力されたリソースプール登録指示を受け付ける（Ｓ１３１）。ユーザは、入力装置９０４を用いて、当該ユーザのクライアント８のストレージ８５の一部または全部の容量を、リソースプールとして登録するための指示を入力する。

そして、ストレージ管理部８２は、受け付けた登録指示に基づいて、指示された容量の領域を、ストレージ８５の記憶領域の中からリソースプール用の領域として分割する（すなわち、パーティショニングする）（Ｓ１３２）。そして、ストレージ管理部８２は、リソースプールとして分割された領域を所定のフォーマットで初期化する。これにより、ローカルサーバ６は、リソースプールとして分割された領域（以下、「パーティション」）を認識することができる。

そして、ストレージ管理部８２は、初期化したパーティションの登録メッセージを、ドメイン内ネットワーク７を介して、ローカルサーバ６に送信する（Ｓ１３３）。なお、登録メッセージには、ユーザインタフェース部８４を介して入力された登録ストレージ容量と、当該クライアントを使用するユーザのあらかじめ定められたユーザＩＤと、を含む。

そして、ローカルサーバ６のリソース管理部６２は、クライアント８から登録メッセージを受信し、登録メッセージの内容をリソースプール管理テーブル６４１（図９参照）に登録する（Ｓ１３４）。すなわち、リソース管理部６２は、一意（未使用）のリソースプールＩＤを特定する。また、リソース管理部６２は、ＤＨＣＰサーバにより動的に設定されたリソースプールのアドレス、または、クライアント８毎にあらかじめ定められたリソースプールのアドレスを特定する。そして、リソース管理部６２は、特定したリソースプールＩＤ９１と、登録メッセージに含まれたユーザＩＤ９２および登録ストレージ容量９３と、特定したアドレス９５とを設定したレコードをリソースプール管理テーブル６４１に追加する。なお、この時点においては、未使用容量９４には登録メッセージに含まれる登録ストレージ容量９３と同じ容量が設定される。

そして、リソース管理部６２は、ドメイン内ネットワーク７を介して、クライアント８に、リソースプール管理テーブル６４１に設定したリソースプールＩＤ９１を送信する（Ｓ１３５）。クライアント８のストレージ管理部８２は、ストレージ８５にストレージ管理テーブル８５１を作成（または、更新）する（Ｓ１３６）。すなわち、ストレージ管理部８２は、全容量１１１にはあらかじめ定められた容量を、登録ストレージ容量１１２にはＳ１３１において受け付けた容量を、リソースプールＩＤ１１３にはＳ１３５において通知されたリソースプールＩＤ、ユーザＩＤ１１４にはあらかじめ定められたユーザＩＤを設定する。

そして、ローカルサーバ６のリソース管理部６２は、ドメイン内ネットワーク７およびドメイン間ネットワーク４を介して、管理サーバ２に登録メッセージを送信する（Ｓ１３７）。なお、登録メッセージには、リソースプール管理テーブル６４１に設定されたユーザＩＤ９２と、当該ローカルサーバ６が所属するローカルドメイン名とが含まれる。また、リソース管理部６２は、当該ローカルサーバ６の所属するローカルドメイン名を記憶部６４にあらかじめ記憶しているものとする。

管理サーバ２の顧客情報管理部２２は、ローカルサーバ６から登録メッセージを受け付けて、顧客管理テーブル３２（図７参照）を更新する（Ｓ１３８）。すなわち、顧客情報管理部２２は、登録メッセージに含まれるユーザＩＤに対応するユーザ名を、ストレージ装置３に記憶された図示しないユーザＩＤ対応テーブルから特定する。そして、顧客情報管理部２２は、登録メッセージに含まれるユーザＩＤ７１および所属ドメイン名７３と、特定したユーザ名７２を設定したレコードを、顧客管理テーブル３２に追加する。

以上説明したリソーススプール登録処理により、リソースプールを登録したクライアント８は、コンテンツ配信サービスの提供を受けることができる。

次に、コンテンツの配信処理について説明する。

図１４は、要求されたコンテンツが同一のローカルドメイン５内に存在している場合のコンテンツ配信処理を模式的に示した図である。図示する例では、所定のローカルドメイン５に所属するクライアントＡ８ａが、同一ローカルドメイン内に所属するクライアントＢ８ｂに格納されたコンテンツを要求する場合を例に、以下説明する。なお、図示するローカルドメイン５は、ローカルサーバ６と、コンテンツを要求する要求元クライアントＡ８ａと、コンテンツを配信する配信元クライアントＢ８ｂと、を有するものとする。

まず、クライアントＡ８ａは、入力装置９０４から入力されたコンテンツの要求を受け付け（Ｓ１）、コンテンツ要求メッセージをローカルサーバ６に送信する（Ｓ２）。そして、ローカルサーバ２は、コンテンツ要求メッセージを受信し、当該メッセージで要求されたコンテンツの格納場所を、ドメイン内コンテンツ管理テーブル６４２（図１０参照）を参照して検索する（Ｓ３）。なお、図示する例では、要求されたコンテンツはクライアントＢ８ｂのストレージ８５ｂ（リソースプール）に格納されているものとする。そして、ローカルサーバ６は、クライアントＡ８ａに、要求したコンテンツを配信する配信元クライアント（クライアントＢ８ｂ）を通知する（Ｓ４）。また、ローカルサーバ６は、クライアントＢ８ｂに対して、要求されたコンテンツを要求元クライアント（クライアントＡ８ａ）に配信するよう指示する（Ｓ５）。

そして、クライアントＢ８ｂは、要求されたコンテンツをストレージ８５ｂ（リソースプール）から読み出し、クライアントＡ８ａに配信する（Ｓ６、Ｓ７）。クライアントＡ８ａは、クライアントＢ８ｂからコンテンツを受信するとともに、当該コンテンツを再生して出力装置９０５に出力する（Ｓ８）。すなわち、クライアントＡ８ａは、受信したコンテンツをストレージ８５ａに格納することなくストリーミングにより再生する。

以上説明したコンテンツ配信処理により、クライアントＡ８ａは、クライアントＢ８ｂから要求したコンテンツを受信し、再生する。これにより、クライアントＡ８ａを使用するユーザは、出力装置９０５に出力されたコンテンツを視聴することができる。この場合、クライアントＢ８ｂとクライアントＡ８ａは、同じローカルドメイン５内に所属しているため、クライアントＡ８ａは、受信したコンテンツをストレージ８５ａに格納しない。このように、同一ローカルドメイン５内のいずれかのクライアント８のストレージ８５（リソースプール）に格納されたコンテンツは、同一ローカルドメイン内のクライアント８にドメイン内ネットワーク７を介して配信される。なお、ドメイン内ネットワーク７は、ドメイン間ネットワーク４に比べ、ネットワークトラフィックが少なく、また、コンテンツ配信のためのネットワーク帯域が大きい。そのため、配信側のクライアント８は映像や音楽などの大量データのコンテンツを、ドメイン内ネットワーク７を介して一定の通信速度で配信することができる。また、受信側のクライアント８は、受信したコンテンツをストリーミングにより再生することができる。

図１５は、要求されたコンテンツが同一のローカルドメイン５内に存在しない場合であって、かつ、当該コンテンツのコピー回数が上限に達していない場合のコンテンツ配信処理を模式的に示した図である。図示する例では、所定のローカルドメインに所属するクライアントＡ８ａが、同一ローカルドメイン５内に存在しないコンテンツを要求する場合を例に、以下説明する。

まず、クライアントＡ８ａは、入力装置９０４から入力されたコンテンツの要求を受け付け（Ｓ１）、コンテンツ要求メッセージをローカルサーバ６に送信する（Ｓ２）。そして、ローカルサーバ６は、コンテンツ要求メッセージをクライアントＡ８ａから受信し、当該要求メッセージで要求されたコンテンツの格納場所を、ドメイン内コンテンツ管理テーブル６４２（図１０参照）を参照して検索する（Ｓ３）。図示する例では、要求されたコンテンツは、ローカルドメイン内の各クライアント８のいずれのストレージ８５（リソースプール）にも格納されていないものとする。したがって、ローカルサーバ６は、管理サーバ２にコンテンツを要求する（Ｓ４）。

管理サーバ２は、ストレージ装置３に格納されたコンテンツ管理テーブル３１（図６参照）を参照し、要求されたコンテンツのコピー回数が上限に達しているか否かを判別する（Ｓ５）。図示する例では、要求されたコンテンツのコピー回数は、上限に達していないものとする。したがって、管理サーバ２は、要求されたコンテンツをストレージ装置３からコピーすることをローカルサーバ６に通知する（Ｓ６）。

ローカルサーバ６は、コピーするコンテンツの格納先のリソースプールを、リソースプール管理テーブル６４１（図９参照）の未使用容量９４を参照して特定する（Ｓ７）。図示する例では、ローカルサーバ６は、クライアントＡ８ａのストレージ８５ａをリソースプールとして特定するものとする。そして、管理サーバ２は、ストレージ装置３からコンテンツを読み出し、ローカルサーバ６が特定したリソースプールにコピー（配信）する（Ｓ８）。クライアントＡ８ａは、管理サーバ２からコンテンツを受信し、当該コンテンツをストレージ８５ａに格納するとともに、当該コンテンツを再生して出力装置９０５に出力する（Ｓ９）。すなわち、クライアントＡ８ａは、受信したコンテンツのストリーミングを行う。

図１６は、要求されたコンテンツが同一のローカルドメイン５内に存在しない場合であって、かつ、当該コンテンツのコピー回数が上限に達している場合のコンテンツ配信処理を模式的に示した図である。すなわち、コンテンツを要求した要求元クライアントＡ８ａが、所属するローカルドメインＡとは異なるローカルドメインＣの移動元クライアントＣ８ｃから、コンテンツを移動する場合を例に、以下説明する。なお、図示するＳ１からＳ４までの処理は、図１５で前述したＳ１からＳ４までの処理と同様であるため、ここでは説明を省略する。

ローカルドメインＡのローカルサーバＡ６ａからコンテンツの要求を受け付けた管理サーバ２は、ストレージ装置３に格納されたコンテンツ管理テーブルを参照し、要求されたコンテンツのコピー回数が上限に達しているか否かを判別する（Ｓ５）。図示する例では、要求されたコンテンツのコピー回数は、上限に達しているものとする。したがって、管理サーバ２は、ストレージ装置３から要求されたコンテンツをさらにコピーすることができない。そのため、管理サーバ２は、ローカルサーバ管理テーブル３３（図８参照）を参照し、要求されたコンテンツを所有するローカルサーバ６（移動元ローカルサーバ）を特定し、特定した移動元ローカルサーバの情報を、ローカルサーバＡ６ａに通知する（Ｓ６）。図示する例では、移動元ローカルサーバは、ローカルドメインＣのローカルサーバＣ６ｃであるものとする。

ローカルドメインＡのローカルサーバＡ６ａは、コンテンツの移動先のリソースプールを、リソースプール管理テーブル６６４（図９参照）の未使用容量９４を参照して特定する（Ｓ７）。図示する例では、ローカルサーバ６ａは、クライアントＡ８ａのストレージ８５ａのリソースプールを特定するものとする。また、ローカルサーバ６ａは、管理センタ２から通知された移動元ローカルサーバであるローカルサーバＣ６ｃに、コンテンツの移動を要求するコンテンツ移動メッセージを送信する（Ｓ７、Ｓ８）。

ローカルドメインＣのローカルサーバＣ６ｃは、コンテンツ移動要求メッセージを受信し、当該要求メッセージで要求されたコンテンツの格納場所を、ドメイン内コンテンツ管理テーブル６４２（図１０参照）を参照して検索する（Ｓ９）。そして、ローカルサーバＣ６ｃは、コンテンツを格納しているクライアントＣ８ｃに対して、クライアントＡ８ａのリソースプールに、コンテンツを移動するよう指示する（Ｓ１０）。クライアントＣ８ｃは、クライアントＡ８ａのリソースプールに、コンテンツを移動（配信）する（Ｓ１１、Ｓ１２）。なお、コンテンツの移動の場合、クライアントＣ８ｃは、コンテンツの配信後に、ストレージ８５ｃからコンテンツを削除する。クライアントＡ８ａは、受信したコンテンツを、ストレージ８５ａのリソースプールに格納するとともに、再生して出力装置９０５に出力する（Ｓ１３）。すなわち、クライアントＡ８ａは、受信したコンテンツのストリーミングを行う。

以上、図１４から図１６で示したコンテンツ配信処理について、図１７から図２０の処理フローを用いて、詳細に説明する。

図１７は、クライアント８が指示を受け付けてから、ローカルサーバ６がローカルドメイン５内に要求されたコンテンツが存在するか否かを判別するまでの処理フローである。

まず、クライアント８の要求処理部８１は、ユーザインタフェース部８４を介して、コンテンツ一覧の要求を受け付ける（Ｓ７０１）。すなわち、当該クライアント８を使用するユーザは、入力装置９０４を用いて、コンテンツ一覧の要求指示を入力する。コンテンツ一覧は、管理センタ１のストレージ装置３に記憶されている全てのコンテンツ３４のコンテンツＩＤおよびコンテンツ名の一覧である。そして、要求処理部８１は、ドメイン内ネットワーク７を介して、ローカルサーバ６にコンテンツ一覧を要求する（Ｓ７０２）。

ローカルサーバ６の配信処理部６１は、クライアント８からコンテンツ一覧の要求を受信すると、ドメイン内ネットワーク７およびドメイン間ネットワーク４を介して、管理サーバ２にコンテンツ一覧を要求する（Ｓ７０３）。管理サーバ２のコンテンツ管理部２１は、コンテンツ一覧の要求を受信すると、ストレージ装置３に記憶されたコンテンツ管理テーブル３１（図６参照）を読み出す。そして、コンテンツ管理部２１は、コンテンツ管理テーブル３１の全レコード各々のコンテンツＩＤ６１およびコンテンツ名６２を表示したコンテンツ一覧を作成し、ローカルサーバ６に送信する。

ローカルサーバ６の配信処理部６１は、管理サーバ２からコンテンツ一覧を受信すると、ドメイン内ネットワーク７を介して要求元のクライアント６にコンテンツ一覧を転送する（Ｓ７０４）。

クライアント８の要求処理部８１は、コンテンツ一覧を受信すると、ユーザインタフェース部８４を用いて受信したコンテンツ一覧を出力装置９０５に出力する（Ｓ７０５）。そして、要求処理部８１は、ユーザインタフェース部８４を介して入力されたコンテンツの配信指示を受け付ける（Ｓ７０６）。すなわち、ユーザは、クライアント８の出力装置９０５に出力されたコンテンツ一覧の中から、配信を要求するコンテンツを、入力装置９０４を用いて指示する。そして、要求処理部８１は、指示されたコンテンツの配信要求メッセージを、ドメイン内ネットワーク７を介してローカルサーバ６に送信する（Ｓ７０７）。なお、配信要求メッセージには、指定されたコンテンツのコンテンツＩＤと、クライアント８を使用するユーザのユーザＩＤと、が含まれている。

そして、ローカルサーバ６の配信処理部６１は、クライアント８から配信要求メッセージを受け付け、記憶部６４に記憶されたドメイン内コンテンツ管理テーブル６４２を読み出す（Ｓ７０８）。そして、配信処理部６１は、配信要求メッセージに含まれるコンテンツＩＤが、ドメイン内コンテンツ管理テーブル６４２に存在するか否かを判別する（Ｓ７０９）。すなわち、配信処理部６１は、要求されたコンテンツが当該ローカルドメイン内５のリソースプールに存在するか否かを判別する。要求されたコンテンツＩＤがドメイン内コンテンツ管理テーブル６４２に存在する場合（Ｓ７０９：ＹＥＳ）、配信処理部６１は、図１８で説明するＳ８００の処理に進む。一方、要求されたコンテンツＩＤがドメイン内コンテンツ管理テーブル６４２に存在しない場合（Ｓ７０９：ＮＯ）、配信処理部６１は、図１９で説明するＳ９００の処理に進む。

図１８は、要求されたコンテンツＩＤがドメイン内コンテンツ管理テーブル６４２に存在する場合（図１７のＳ７０９：ＹＥＳ）の処理フローである。

ローカルサーバ６の配信処理部６１は、ドメイン内コンテンツ管理テーブル６４２を参照して、図１７のＳ７０７において要求されたコンテンツＩＤに対応するリソースプールＩＤを特定する（Ｓ８０１）。そして、配信処理部６１は、リソースプール管理テーブル６４１（図９参照）を読み出し、特定したリソースプールＩＤのアドレス９５を特定する（Ｓ８０２）。そして、配信処理部６１は、要求元クライアント８に、特定したアドレス９５を含む配信元情報を、ドメイン間ネットワーク７を介して送信する（Ｓ８０３）。また、配信処理部６１は、特定したアドレス９５を宛先として、要求したコンテンツを格納しているリソースプールを有するクライアント（以下、「配信元クライアント」）に、コンテンツ配信指示を、ドメイン間ネットワーク７を介して送信する（Ｓ８０４）。なお、コンテンツ配信指示には、要求されたコンテンツＩＤと、要求元のクライアント８のアドレスが含まれている。配信処理部６１は、図１７のＳ７０７において送信された配信要求メッセージに含まれるユーザＩＤに対応するアドレス９５を、リソースプール管理テーブル６４１から特定し、要求元のクライアント８の宛先としてコンテンツ配信指示に含めることとしてもよい。

配信元クライアント８の要求処理部８１は、ストレージ８５のリソースプールに記憶された複数のコンテンツの中から、コンテンツ配信指示に含まれた、要求されたコンテンツＩＤを有するコンテンツを読み出す。そして、要求処理部８１は、読み出したコンテンツを、クライアントにおいて、出力装置に再生出力が可能なデータ形式で、ネットワークインタフェース部８３を介して、要求元クライアントに配信する（Ｓ８０５）。

すなわち、要求処理部８１は、コンテンツ配信指示に指定された要求元クライアント８のアドレスを宛先として、ドメイン内ネットワーク７を介して要求されたコンテンツを配信する。

要求元クライアント８の要求処理部８１は、配信元クライアント８からコンテンツを受信するとともに、当該コンテンツを再生し出力装置９０５に出力する（Ｓ８０６）。すなわち、要求元クライアント８の要求処理部８１は、受信したコンテンツをストレージ８５に格納することなくストリーミングによる再生を行う。

図１９は、要求されたコンテンツＩＤがドメイン内コンテンツ管理テーブル６４２に存在しない場合（図１７のＳ７０９：ＮＯ）の処理フローである。

ローカルサーバ６の配信処理部６１は、ドメイン内ネットワーク７およびドメイン間ネットワーク４を介して、管理サーバ２にコンテンツ配信要求を送信する（Ｓ９０１）。なお、コンテンツ配信要求には、図１７のＳ７０７において送信されたコンテンツＩＤが含まれている。

そして、管理サーバ２のコンテンツ管理部２１は、コンテンツ配信要求を受け付けて、当該コンテンツ配信要求に含まれるコンテンツＩＤのコピー回数が上限に達しているか否かを判別する（Ｓ９０２）。すなわち、コンテンツ管理部２１は、コンテンツ管理テーブル３１を読み出し、当該コンテンツＩＤのコピー上限６４とコピー回数６５とを特定する。そして、コンテンツ管理部２１は、当該コピー上限６４の数値とコピー回数６５の数値が同じ場合、コピー回数が上限に達していると判別する。図６に示すコンテンツ管理テーブル３１の場合、コンテンツＩＤが「Ｃ-００１」６１ａのコピー上限６４とコピー回数６４は、ともに「３」である。したがって、コンテンツＩＤが「Ｃ-００１」６１ａのコンテンツの場合、コンテンツ管理部２１は、コピー回数が上限に達していると判別する。 コピー回数が上限に達している場合（Ｓ９０２：ＹＥＳ）の処理については、図２０において後述する。

一方、コンテンツ管理部２１は、当該コピー上限の数値６４が、コピー回数６５の数値より小さい場合、コピー回数が上限に達していないと判別する。図６に示すコンテンツ管理テーブルの場合、コンテンツＩＤが「Ｃ-００２」６１ｂのコピー上限は「２」で、コピー回数は「０」である。したがって、コンテンツＩＤが「Ｃ-００２」６１ｂのコンテンツの場合、コンテンツ管理部２１は、コピー回数が上限に達していないと判別する。

コピー回数が上限に達していない場合（Ｓ９０２：ＮＯ）、コンテンツ管理部２１は、コンテンツ管理テーブル３１に記憶された当該コンテンツＩＤのデータサイズ６３を、ローカルサーバ６に送信する（Ｓ９０３）。ローカルサーバ６の配信処理部６１は、コンテンツのデータサイズを受信し、受信したデータサイズに基づいて、コンテンツを格納するリソースプールＩＤを特定する（Ｓ９０４）。すなわち、配信処理部６１は、リソースプール管理テーブル６４１を参照して、未使用容量９４が受信したデータサイズより大きいリソースプールＩＤ９１を特定する。なお、受信したデータサイズより大きい未使用容量９４のリソースプールが複数存在する場合、配信処理部６１は、リソースプールＩＤが最も小さいリソースプールＩＤを特定するなど、所定の規則によりリソースプールを特定する。そして、配信処理部６１は、特定したリソースプールＩＤ９１のアドレス９５を含む配信元情報を、ドメイン内ネットワーク７を介して要求元クライアント８に送信する（Ｓ９０５）。また、配信処理部６１は、特定したリソースプールＩＤ９１のアドレス９５を、ドメイン内ネットワーク７およびドメイン間ネットワーク４を介して管理サーバ２に送信する（Ｓ９０６）。

管理サーバ２のコンテンツ管理部２１は、要求されたコンテンツをストレージ装置３から読み出し、読み出したコンテンツを送信されたアドレスのリソースプールに配信（コピー）する（Ｓ９０７）。なお、コンテンツ管理部２１は、コンテンツ管理テーブル３１に記憶された当該コンテンツのコンテンツＩＤ６１と、コンテンツ名６２と、データサイズ６３と、をコンテンツとともに前記アドレスのリソースプールに送信する。そして、コンテンツ管理部２１は、コンテンツ管理テーブル３１を更新する（Ｓ９０８）。すなわち、コンテンツ管理部２１は、配信したコンテンツＩＤ６１のコピー回数６５に「１」を加算する。また、ローカルサーバ管理部２３は、ローカルサーバ管理テーブル３３を更新する（Ｓ９０８）。すなわち、ローカルサーバ管理部２３は、要求元のローカルサーバ６のサーバＩＤ８１に対応する所有コンテンツＩＤ８３に、配信したコンテンツＩＤを追加する。

ローカルサーバ６の配信処理部６１は、Ｓ９０４において特定したリソースプールＩＤのクライアント８（以下、「配信元クライアント」）に、管理サーバ２から配信されたコンテンツの配信を指示する（Ｓ９０９）。なお、コンテンツ配信指示には、要求されたコンテンツＩＤと、要求元のクライアント８のアドレスとが含まれている。

また、ローカルサーバ６のリソース管理部６２は、リソースプール管理テーブル６４１およびドメイン内コンテンツ管理テーブル６４２を更新する（Ｓ９０９）。すなわち、リソース管理部６２は、リソースプール管理テーブル６４１において、Ｓ９０４で特定したリソースプールＩＤ９１の未使用容量９４から、要求したコンテンツのデータサイズを減算する。また、リソース管理部６２は、ドメイン内コンテンツ管理テーブル６４２に要求したコンテンツＩＤ１０１および特定したリソースプールＩＤ１０２を設定したレコードを追加する。

配信元クライアント８の要求処理部８１は、管理サーバ２から配信されたコンテンツをストレージ８５のリソースプールに記憶する。そして、配信元クライアント８の要求処理部８１は、Ｓ９０９のコンテンツ配信指示に基づいて、配信されたコンテンツを要求元クライアント８に配信する（Ｓ９１０）。また、配信元クライアント８のストレージ管理部８２は、クライアントコンテンツ管理テーブル８５２を更新する。すなわち、ストレージ管理部８２は、Ｓ９０７においてコンテンツとともに配信されたコンテンツＩＤ、コンテンツ名およびデータサイズを設定したレコードを、クライアントコンテンツ管理テーブル８５２に追加する。

要求元クライアント８の要求処理部８１は、ドメイン内ネットワーク７を介して、配信元クライアント８からコンテンツを受信するとともに、当該コンテンツを再生し出力装置９０５に出力する（Ｓ９１１）。すなわち、要求元クライアントは、受信したコンテンツをストレージに格納することなくストリーミングによる再生を行う。

なお、図示する例では、配信元クライアント８と要求元クライアント８とは異なるクライアント８である。しかしながら、Ｓ９０４で特定したリソースプールが、要求元クライアントのリソースプールで、配信元クライアント８と要求元クライアント８とが同じクライアントであってもよい。この場合、要求元クライアント（配信元クライアント）は、Ｓ９１０で、管理サーバ２から配信されたコンテンツを格納するともに再生する。

図２０は、コピー回数が上限に達している場合（図１９のＳ９０２：ＹＥＳ）の処理フローである。図示する処理フローでは、コピー回数が上限に達しているため、他のローカルドメインのクライアント８から要求したコンテンツテンツを移動する。

管理サーバ２のローカルサーバ管理部２３は、ローカルサーバ管理テーブル３３を読み出し、要求されたコンテンツＩＤを有するローカルサーバ６のサーバＩＤ８１を特定する（Ｓ２０１）。すなわち、ローカルサーバ管理部２３は、ローカルサーバ管理テーブル３３の所属コンテンツＩＤ８３を参照し、要求されたコンテンツＩＤを有するサーバＩＤ８１を特定する。そして、ローカルサーバ管理部２３は、特定したサーバＩＤ８１と、コンテンツ管理テーブル３１に記憶された当該コンテンツのデータサイズと、を要求元のローカルサーバ６に送信する（Ｓ２０２）。また、ローカルサーバ管理部２３は、ローカルサーバ管理テーブル３３を更新する。すなわち、ローカルサーバ管理部２３は、特定したサーバＩＤ８１の所有コンテンツＩＤ８３から要求されたコンテンツＩＤを削除する。そして、ローカルサーバ管理部２３は、要求元のローカルサーバ６のサーバＩＤ８１の所有コンテンツＩＤ８３に要求されたコンテンツＩＤを追加する。

要求元ローカルサーバ６の配信処理部６１は、管理サーバ２から要求したコンテンツを有するローカルサーバ６（以下、「移動元ローカルサーバ」）のサーバＩＤと、コンテンツのデータサイズを受信する。そして、配信処理部６１は、受信したデータサイズに基づいて、コンテンツを格納するリソースプールＩＤを特定する（Ｓ２０３）。すなわち、配信処理部６１は、リソースプール管理テーブル６４１を参照して、未使用容量９４が受信したデータサイズより大きいリソースプールＩＤ９１を特定する。

そして、配信処理部６１は、特定したリソースプールＩＤ９１のアドレス９５を含む配信元情報を、ドメイン内ネットワーク７を介して、要求元クライアント８に送信する（Ｓ２０４）。また、配信処理部６１は、特定したリソースプールＩＤのアドレス９５と、コンテンツＩＤとを、ドメイン内ネットワーク７およびドメイン間ネットワーク４を介して移動元ローカルサーバ６に送信する（Ｓ２０５）。

移動元ローカルサーバ６の配信処理部６１は、ドメイン内コンテンツ管理テーブル６４２を参照して、送信されたコンテンツＩＤに対応するリソースプールＩＤを特定する。また、配信処理部６１は、リソースプール管理テーブル６４２を読み出し、特定したリソースプールＩＤのアドレス９５を特定する（Ｓ２０６）。そして、配信処理部６１は、特定したアドレスを有するクライアント８（以下、「移動元クライアント」）に、コンテンツ配信指示を、ドメイン内ネットワーク７を介して送信する（Ｓ２０７）。なお、コンテンツ配信指示には、要求されたコンテンツＩＤと、Ｓ２０３において特定したリソースプールＩＤのアドレスとが含まれている。また、配信処理部６１は、ドメイン内コンテンツ管理テーブル６４２を更新する。すなわち、配信処理部６１は、ドメイン内コンテンツ管理テーブル６４２から、送信されたコンテンツＩＤおよび特定したリソースプールＩＤのレコードを削除する。

移動元クライアント８の要求処理部８１は、コンテンツ配信指示を受信し、当該指示に含まれるコンテンツをストレージ８５のリソースプールから読み出し、ネットワークインタフェース部８３を介して、Ｓ２０３において特定されたリソースプールＩＤのアドレスに位置するクライアントのストレージに移動（送信）する（Ｓ２０８）。

すなわち、要求処理部８１は、コンテンツを送信した後、リソースプールから当該コンテンツを削除する。なお、要求処理部８１は、クライアントコンテンツ管理テーブル８５２に記憶された当該コンテンツのコンテンツＩＤ１２１と、コンテンツ名１２２と、データサイズ１２３と、をコンテンツとともに送信する。そして、要求処理部８１は、コンテンツＩＤ１２１等を送信後、クライアントコンテンツ管理テーブル８５２から送信したコンテンツＩＤ等のレコードを削除する。

要求元ローカルサーバ６の配信処理部６１は、Ｓ２０３において特定したリソースプールＩＤのクライアント８（以下、「配信元クライアント」）に、移動元クライアント８から送信されたコンテンツの配信を指示する（Ｓ２０９）。なお、コンテンツ配信指示には、要求されたコンテンツＩＤと、要求元のクライアント８のアドレスとが含まれている。

また、要求元ローカルサーバ６のリソース管理部６２は、リソースプール管理テーブル６４１およびドメイン内コンテンツ管理テーブル６４２を更新する。すなわち、リソース管理部６２は、リソースプール管理テーブル６４１におけるＳ９０３で特定したリソースプールＩＤ９１の未使用容量９４から、要求したコンテンツのデータサイズを減算する。また、リソース管理部６２は、ドメイン内コンテンツ管理テーブル６４２に要求したコンテンツＩＤ１０１および特定したリソースプールＩＤ１０２を設定したレコードを追加する。

配信元クライアント８の要求処理部８１は、移動元クライアント８から配信されたコンテンツをストレージ８５のリソースプールに記憶する。そして、要求処理部８１は、Ｓ２０９のコンテンツ配信指示に基づいて、配信されたコンテンツを要求元クライアント８に配信する（Ｓ２１０）。また、ストレージ管理部８２は、クライアントコンテンツ管理テーブル８５２を更新する。すなわち、ストレージ管理部８２は、Ｓ２０８においてコンテンツとともに配信されたコンテンツＩＤ、コンテンツ名およびデータサイズを設定したレコードを、クライアントコンテンツ管理テーブル８５２に追加する。

要求元クライアント８の要求処理部８１は、ドメイン内ネットワーク７を介して、配信元クライアント８からコンテンツを受信するとともに、当該コンテンツを再生し出力装置９０５に出力する（Ｓ９１１）。すなわち、要求元クライアントは、受信したコンテンツをストレージ８５に格納することなくストリーミングによる再生を行う。

なお、図示する例では、配信元クライアント８と要求元クライアント８とは異なるクライアント８である。しかしながら、Ｓ２０３で特定したリソースプールが、要求元クライアント８のリソースプールで、配信元クライアント８と要求元クライアント８とが同じクライアントであってもよい。この場合、要求元クライアント（配信元クライアント）は、Ｓ２１０で、移動元クライアント８から配信されたコンテンツを格納するともに再生する。

以上で本実施形態について説明した。

上記の実施形態では、エンドユーザが使用するクライアント８のストレージ８５を、コンテンツ配信システムのコンテンツ格納領域（リソースプール）として管理および利用することにより、ＩＴリソースの増設をより小さく抑えることができる。すなわち、一般的なコンテンツ配信システムにおいては、サービスの対象範囲を拡大する場合、ローカルドメイン５を次々に設置し、ローカルドメイン５毎にコンテンツを格納するためのストレージ装置を新たに用意する必要があった。しかしながら、本実施形態では、ローカルドメイン５のローカルサーバ６は、コンテンツを格納するためのストレージ装置を有することなく、ローカルドメイン５内の各クライアント８にコンテンツを配信することができる。従って、一般的なコンテンツ配信システムに比べて、より少ないＩＴリソース（ローカルサーバ６）の増設だけで、ローカルドメイン５を構築することができる。

また、本実施形態では、同一ローカルドメイン５内のいずれかのクライアント８のストレージ８５（リソースプール）に格納されたコンテンツは、同一ローカルドメイン内の他のクライアント８にドメイン内ネットワーク７介して配信される。そして、他のクライアントは、配信されたコンテンツをストレージ８５に記憶することなくストリーミングにより再生する。すなわち、ローカルドメイン５内では、同一のコンテンツを重複して各クライアント８のストレージ８５に格納しないため、ストレージ８５（リソースプール）の有効活用を図ることができる。

なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記の実施形態では、管理サーバ２または移動元クライアント８は、コピーまたは移動するコンテンツを、ローカルサーバ６を経由せず、直接配信元のクライアント８にコピーまたは移動している。しかしながら、管理サーバ２または移動元クライアント８は、管理サーバ６を経由して、配信元のクライアント８にコンテンツをコピーまたは移動することとしてもよい。

本発明の一実施形態が適用されたシステムの全体構成図。 管理サーバおよびストレージ装置の概略構成図。 ローカルサーバの概略構成図。 クライアントの概略構成図。 各装置のハードウェア構成例を示す図。 コンテンツ管理テーブルの一例を示す図。 顧客管理テーブルの一例を示す図。 ローカルサーバ管理テーブルの一例を示す図。 リソースプール管理テーブルの一例を示す図。 ドメイン内コンテンツ管理テーブルの一例を示す図。 ストレージ管理テーブルの一例を示す図。 クライアントコンテンツ管理テーブルの一例を示す図。 リソースプール登録処理の処理フロー図。 ローカルドメイン内にコンテンツが存在する場合のコンテンツ配信処理を模式的に示す図。 コンテンツをコピーする場合のコンテンツ配信処理を模式的に示す図。 コンテンツを移動する場合のコンテンツ配信処理を模式的に示す図。 コンテンツ配信処理の処理フロー図。 コンテンツ配信処理の処理フロー図。 コンテンツ配信処理の処理フロー図。 コンテンツ配信処理の処理フロー図。

符号の説明

１：管理センタ、２：管理サーバ、２１：コンテンツ管理部、２２：顧客情報管理部、２３：ローカルサーバ管理部、２４：ネットワークインタフェース部、２５：ユーザインタフェース部、３：ストレージ装置、３１：コンテンツ管理テーブル、３２：顧客管理テーブル、３３：ローカルサーバ管理テーブル、３４：オリジナルコンテンツ、４：ドメイン間ネットワーク、５：ローカルドメイン、６：ローカルサーバ、６１：配信処理部、６２：リソース管理部、６３：ネットワークインタフェース部、６４：記憶部、７：ドメイン内ネットワーク、８：クライアント、８１：要求処理部、８２：ストレージ管理部、８３：ネットワークインタフェース部、８４：ユーサインタフェース部、８５：ストレージ

Claims (6)

1. コンテンツ配信システムであって、
   コンテンツの配信を指示する配信サーバと、少なくとも１つのクライアントとを有し、
   前記クライアント各々は、
   データを記憶するためのクライアントストレージと、
   前記クライアントストレージの一部または全部を、コンテンツを格納するためのリソースプールとして、前記配信サーバに登録する登録手段と、
   コンテンツの配信要求を受け付けて、前記コンテンツの配信要求を前記配信サーバに送信する要求手段と、を有し、
   前記配信サーバは、
   前記クライアント各々が登録したリソースプールを管理するためのリソースプール管理テーブルと、コンテンツと当該コンテンツを格納しているリソースプールとを対応付けたコンテンツ管理テーブルと、を記憶する配信サーバ記憶手段と、
   前記クライアント各々から、前記コンテンツの配信要求を受け付ける要求受付手段と、
   前記コンテンツ管理テーブルを読み出して、前記要求受付手段が受け付けたコンテンツを格納しているリソースプールを特定する特定手段と、
   前記特定手段が特定したリソースプールを有するクライアントに、前記コンテンツの配信指示を送信する配信指示手段と、を有すること
   を特徴とするコンテンツ配信システム。
2. 請求項１記載のコンテンツ管理システムであって、
   複数の所定の領域毎に、前記配信サーバおよび前記少なくとも１つのクライアントを有すること
   を特徴とするコンテンツ配信システム。
3. 請求項２記載のコンテンツ管理システムであって、
   前記複数の所定の領域の、前記配信サーバおよび前記少なくとも１つのクライアントを管理する管理サーバを、さらに有し、
   前記管理サーバは、コンテンツを格納するサーバストレージを有し、
   前記配信サーバの特定手段は、前記コンテンツ管理テーブルに前記要求受付手段が受け付けたコンテンツを格納しているリソースプールが記憶されていない場合、前記管理サーバに前記要求受付手段が受け付けたコンテンツの配信を要求すること
   を特徴とするコンテンツ配信システム。
4. 請求項３記載のコンテンツ配信システムであって、
   前記管理サーバは、
   コンテンツ毎に、当該コンテンツを各リソースプールに配信可能な上限回数と、当該コンテンツを各リソースプールに既に配信した配信回数と、を含む配信管理テーブルと、配信サーバ毎に、当該配信サーバの識別情報と当該配信サーバが所属する所定の領域の各リソースプールに格納されたコンテンツのリストとを有するサーバ管理テーブルと、を記憶した管理サーバ記憶手段と、
   前記配信サーバからコンテンツの配信要求を受け付けて、前記配信管理テーブルを読み出し、前記配信要求を受け付けたコンテンツの前記上限回数と、前記配信回数とを比較する判別手段と、をさらに有し、
   前記判別手段は、前記上限回数が前記配信回数より少ない場合、前記サーバストレージから前記配信要求を受け付けたコンテンツを配信し、前記上限回数が前記配信回数と同じ場合、前記サーバ管理テーブルを読み出して前記配信要求を受け付けたコンテンツを有する配信サーバの識別情報を、前記配信要求を送信した配信サーバに送信すること
   を特徴とするコンテンツ配信システム。
5. 請求項３記載のコンテンツ配信システムであって、
   前記配信サーバの前記リソースプール管理テーブルは、リソースプール各々の未使用容量を、さらに有し、
   前記配信サーバの特定手段は、前記コンテンツ管理テーブルに前記要求受付手段が受け付けたコンテンツを格納しているリソースプールが記憶されていない場合、前記リソースプール管理テーブルの各未使用容量に基づいて、前記要求受け付け手段が受け付けたコンテンツを格納するリソースプールを特定すること
   を特徴とするコンテンツ配信システム。
6. コンテンツの配信を指示する配信サーバと、少なくとも１つのクライアントとを有するコンテンツ配信システムにおけるコンテンツ配信方法であって、
   前記クライアント各々は、データを記憶するためのクライアントストレージと、クライアント処理部とを有し、
   前記クライアント処理部は、
   前記クライアントストレージの一部または全部を、コンテンツを格納するためのリソースプールとして、前記配信サーバに登録する登録ステップと、
   コンテンツの配信要求を受け付けて、前記コンテンツの配信要求を前記配信サーバに送信する配信要求ステップと、を行い、
   前記配信サーバは、前記クライアント各々が登録したリソースプールを管理するためのリソースプール管理テーブルと、コンテンツと当該コンテンツを格納しているリソースプールとを対応付けたコンテンツ管理テーブルと、を記憶する配信サーバ記憶手段と、サーバ処理部と、を有し、
   前記サーバ処理部は、
   前記クライアント各々から、前記コンテンツの配信要求を受け付ける要求受付ステップと、
   前記コンテンツ管理テーブルを読み出して、前記要求受付ステップにおいて受け付けたコンテンツを格納しているリソースプールを特定する特定ステップと、
   前記特定ステップにおいて特定したリソースプールを有するクライアントに、前記コンテンツの配信指示を送信する配信指示ステップと、を行うこと
   を特徴とするコンテンツ配信方法。

Images