(57)【要約】【課題】インターネットを経由して動画や音声などの大容量コンテンツが配信されるビデオオンデマンドのシステムにおいて、システムが複数のサーバーを備える場合であっても、一つのサーバーにアクセスが集中するようなアクセス集中に弱い。【解決手段】インターネットＮに接続する複数のサーバーＳ内において、ビデオの作品単位である一つのレーベルを複数に分解した分解要素Ｅを記憶する。そして、インターネットに接続するユーザーの個人パソコンからの要求信号に応じて、前記分解要素Ｅを相互の配置的な前後を設定した信号とともにインターネットＮへ送信する。これにより、ある特定のレーベルへアクセスが集中しても、各サーバーＳが記憶するその特定のレーベルを分解した分解要素Ｅを送信し、よって、アクセス集中による負荷はいわば各サーバーＳが分散して受け持つので、ある特定のサーバーにアクセスが集中することにはならない。【選択図】図1
2005309640.tif 000002
【特許請求の範囲】
【請求項１】
広域ネットワークの大容量コンテンツ配信システムであって、このシステムを構成して広域ネットワークに接続する複数のサーバーと、各サーバー内において、大容量コンテンツを複数に分解した分解要素を記憶する記憶手段と、広域ネットワークに接続するユーザーからの要求信号に応じて、前記分解要素を相互の配置的な前後を設定した信号とともに広域ネットワークへ送信する送信手段と、を有してなることを特徴とする広域ネットワーク大容量コンテンツ配信システム。
【請求項２】
一つの前記サーバーが記憶する前記分解要素は、前記一つの配置的な順序を有する大容量コンテンツに対し、異なる配置に属する複数があり、前記配信は、前記複数の分解要素ごとに複数の配信タイミングによりおこなうことを特徴とする請求項１記載の広域ネットワーク大容量コンテンツ配信システム。
【請求項３】
前記複数のサーバーは、前記システムを構成することを同意して登録された一般家庭のパソコンであることを特徴とする請求項２、又は３に記載の広域ネットワーク大容量コンテンツ配信システム。
【請求項４】
広域ネットワークの大容量コンテンツ配信方法であって、このシステムを構成して広域ネットワークに接続する複数のサーバー内の記憶手段に対して、大容量コンテンツを複数に分解した分解要素を記憶させる記憶ステップと、広域ネットワークに接続するユーザーからの要求信号に応じて、前記分解要素を相互の配置的な前後を設定した信号とともに広域ネットワークへ送信する送信ステップと、を有してなることを特徴とする広域ネットワーク大容量コンテンツ配信方法。
【請求項５】
一つの前記サーバーが記憶する前記分解要素は、前記一つの大容量コンテンツに対し、異なる配置に属する複数があり、前記配信は、前記複数の分解要素ごとに複数の配信タイミングによりおこなうことを特徴とする請求項４記載の広域ネットワーク大容量コンテンツ配信方法。
【請求項６】
前記複数のサーバーは、前記システムを構成することを同意して登録された一般家庭のパソコンであることを特徴とする請求項４、又は５に記載の広域ネットワーク大容量コンテンツ配信方法。
【請求項７】
インターネットを経由して動画や音声などのビデオの作品が配信されるビデオオンデマンドのシステムであって、このシステムを構成してインターネットに接続する複数のサーバーと、各サーバー内において、ビデオの作品単位である一つのレーベルを複数に分解した分解要素を記憶する記憶手段と、インターネットに接続するユーザーの個人パソコンからの要求信号に応じて、前記分解要素を相互の配置的な前後を設定した信号とともにインターネットへ送信する送信手段と、を有してなることを特徴とする広域ネットワーク大容量コンテンツ配信システム。
【請求項８】
一つの前記サーバーが記憶する前記分解要素は、前記一つのレーベルに対し、異なる配置に属する複数があり、前記配信は、前記複数の分解要素ごとに複数の配信タイミングによりおこなうことを特徴とする請求項７に記載の広域ネットワーク大容量コンテンツ配信システム。
【請求項９】
前記複数のサーバーは、前記システムを構成することを同意して登録された一般家庭のパソコンであることを特徴とする請求項７、又は８に記載の広域ネットワーク大容量コンテンツ配信システム。
【請求項１０】
インターネットを経由して動画や音声などのビデオの作品が配信されるビデオオンデマンドの配信方法であって、このシステムを構成してインターネットに接続する複数のサーバー内の記憶手段に対して、ビデオの作品単位である一つのレーベルを複数に分解した分解要素を記憶させる記憶ステップと、インターネットに接続するユーザーの個人パソコンからの要求信号に応じて、前記分解要素を相互の配置的な前後を設定した信号とともにインターネットへ送信する送信ステップと、を有してなることを特徴とする広域ネットワーク大容量コンテンツ配信方法。
【請求項１１】
一つの前記サーバーが記憶する前記分解要素は、前記一つのレーベルに対し、異なる配置に属する複数があり、前記配信は、前記複数の分解要素ごとに複数の配信タイミングによりおこなうことを特徴とする請求項１０に記載の広域ネットワーク大容量コンテンツ配信方法。
【請求項１２】
前記複数のサーバーは、前記システムを構成することを同意して登録された一般家庭のパソコンであることを特徴とする請求項１０、又は１１に記載の広域ネットワーク大容量コンテンツ配信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、広域ネットワークの大容量コンテンツ配信システム、特に、インターネットを経由して動画や音声などの大容量コンテンツが配信されるビデオオンデマンドのシステムに関する。
【背景技術】
【０００２】
広域ネットワークの大容量コンテンツ配信システムとして、代表的なものに、インターネット接続によるビデオオンデマンドのシステムがある。このシステムでは、動画や音声からなるビデオの配信は、非常に大量の情報を、大量のアクセスに対し、一定の時間、常に安定した状態で供給し続けなければならない。
【０００３】
図８に、一般的なインターネット配信の流れを経路１〜８に示す。
すなわち、図中左のサーバーからスタートし、サーバーのハードディスクから始まってサーバーのメモリーまでの経路１、メモリーからＬＡＮカードまでの経路２、ＬＡＮカードからインターネット上のサーバー側の収容局までの経路３、収容局からプロバイダまでの経路４、プロバイダからユーザー側の収容局までの経路５、収容局からユーザーの個人パソコン（ＰＣと表示する）のＬＡＮカードまでの回路６、ＬＡＮカードからメモリーまでの経路７、メモリーからパソコンの表示機までの経路８を通って初めて、ユーザーのパソコンの表示機にたどり着く。
【０００４】
これらの経路はそれぞれデータ転送速度が違う。それぞれの速度を通信速度でよく使われるｂｐｓという単位で説明すると、
経路１：ハードディスクのアクセス速度によってデータ転送速度が決定する。現在の技術では約７００Mｂｐｓが目安となる。
【０００５】
経路２＆７：メモリーのアクセス速度によってデータ転送速度が決定する。速度的には最高の速度を持つ。現在の技術では約３２Ｇｂｐｓが目安となる。ハードディスクの約４６倍である。
経路３：いわゆる回線速度である。HPを運営しているサーバーの場合は高速な回線を使用している場合が多いと考えられるため、光ファイバーの１００Ｍｂｐｓを基準に考える。この速度を使用しても、経路２＆７の転送速度の１／３２０にすぎない。
経路４＆５：基幹（バックボーン）と呼ばれる経路である。通信速度は地域、プロバイダによって異なる。３００Ｍ〜１０Ｇと相当なばらつきがある。１Ｇ〜１０Ｇという高速回線は都市間（東京←→大阪、日本←→海外など）に使用され、３００Ｍ〜６００Ｍ程度が地域間（東京都２３区内など）に使用される。これは都市間のデータ転送は全ての地域から流れてきたデータの総和になるため、より大きな回線が必要なためである。現在の速度では、本格的なブロードバンドに使用できないため、基幹回線速度の拡充が急ピッチで行われている。経路６：プロバイダと契約する際にＡＤＳＬ１２Ｍ、２４Ｍ等のコースをよく見かけるが、この速度はこの６番の経路を示す。俗にラスト１マイルと呼ばれる。ＡＤＳＬ１０Ｍ〜２０Ｍ辺りが最近の一般的な速度域と考えると、経路３の１／１０〜１／５くらいになる。
【０００６】
経路７：上記経路２＆７で説明した。
経路８：表示機として様々な周辺機器があるが、おおむね１Ｇｂｐｓ程度を考えておけば妥当といえる。ただし、ビデオオンデマンドの場合は一時間で１〜２Ｇバイトのデータを取得すればよいので、仮に少ないほうの１Ｇバイトを想定するとして、１Ｇバイトを８Ｇビット、及び１時間（３６００秒）で割って、２．２Ｍｂｐｓ程度で良いと思われる。このことから、
経路１ ： ７００Ｍｂｐｓ
経路２ ：  ３２０００Ｍｂｐｓ
経路３ ： １００Ｍｂｐｓ
経路４＆５： ３００Ｍｂｐｓ
経路６ ： １０Ｍｂｐｓ
経路７ ： ３２０００Ｍｂｐｓ
経路８ ： １０００Ｍｂｐｓ
となり、実際には経路６のところの速度を超えることはできないので、経路６の１０Ｍｂｐｓの速度が最高速度になり、通信速度の目安となる。
【０００７】
ビデオオンデマンドに実際に必要な速度は２Ｍ程度であり、これなら何の問題もなく契約した速度が出そうであるが、これはあくまでも１サーバー対１ユーザーを考えた場合である。複数のユーザーがデータを取得すると、一部の経路には集中がおきる。仮に、同時にユーザー２０人が同じサーバーからデータを取得したとすると、１ユーザー当たり
経路１    ：      ３５Ｍｂｐｓ＝    ７００／２０Ｍｂｐｓ
経路２    ：  １６００Ｍｂｐｓ＝３２０００／２０Ｍｂｐｓ
経路３    ：        ５Ｍｂｐｓ＝    １００／２０Ｍｂｐｓ
経路４＆５：      １５Ｍｂｐｓ＝    ３００／２０Ｍｂｐｓ
経路６    ：      １０Ｍｂｐｓ
経路７    ：３２０００Ｍｂｐｓ
経路８    ：  １０００Ｍｂｐｓ
となり、経路３の５Ｍｂｐｓが最高速度となり、実際の速度の１／２しか得られないという現象が起きる。これがいわゆる「混んでいる」という状態である。最低限２Ｍｂｐｓを確保するとすれば、４０人程度が限界となる。
【０００８】
では、このように、１００Ｍの回線をもつサーバーは約４０人のユーザーしか使えないサーバーなのだろうか？そうであれば、商用のサーバーとしてはコスト的に成り立たない。
ところが、実際にはインターネットは「完全に「同時」アクセス」というのはあり得ない。なぜならば通常のＨＰ（ホームページ）はページ当たり１Ｍビットを切るデータ量のところがほとんどで、０．０１秒でデータ転送は終了してしまう。０．０１秒の間に４０人がアクセスする可能性はほとんどない。しかも、０．０１秒でデータ転送は終了するので、１時間当たりに転送可能な接続数は３６００秒＊１００の数となる。１時間当たり３６万接続を相手にできる計算になる。
【０００９】
ＨＰが１０ページで構成されているとすれば、ページ当たり１Ｍビットとして、１時間に３万６千人まで対処可能ということになる。ＨＰが２０ページならば１万８千人、４０ページなら９千人。とページが増えると対応人数に限りが出てくる。もっとも、通常は全ての人が全てのページを見るとは限らないので、概ね１万人程度はさばけるものと思われる。これが従来のサーバー処理が十分になされていた事情である。
【００１０】
ところが、ビデオオンデマンドの場合は最初から最後までをほとんどの人が、全てのページを見るのと同じなので、従来の考え方が通用しない。１０ページ＝１０Ｍ→３万６千人、２０ページ＝２０Ｍ→１万８千人と考えた場合、ビデオオンデマンドは１時間に最低８０００Ｍが必要といわれているので、８０００Ｍ→４５人
1万8千人*２０Ｍ/８０００Ｍ＝４５
となり、１台のサーバーで４５人が限度となる。
【００１１】
４５人しか見ることができないのでは、商用的な運営のためには少なすぎると思われる。そこで次に、レンタルビデオショップの貸し出し例をもとに、商用として成り立つ配信データ量を算出する。
ビデオショップの一日の売上は小さな店舗で１５万円、大型店舗で６０万円といわれている。単価を３８０円とすると
１５００００／３８０＝４００人〜６０００００／３８０≒１６００人
となり、延べ人数４００人〜１６００人がビデオ１本を借りる事が可能である必要がある。これをサーバー台数に換算すると４００／４５≒９台〜１６００／４５≒３６台が必要になる。ビデオショップに置かれているビデオの本数は、一般的に棚ひとつで約１千本ある。店舗の規模にもよるが、大型店舗の場合、棚の数を５０個前後とすると約５万本となる。一本当たりの平均視聴時間数を１．５時間とすると、ビデオを借りるユーザーの個人パソコンの表示機の経路８の要求速度が上記したようにおおむね一時間当たり１Ｇバイト程度であることを考えれば、必要なハードディスクの容量は、
１Ｇバイト＊１．５＊５００００＝７５０００Ｇ
の容量が必要になる。
【００１２】
また、一台のパソコンに接続可能なハードディスクの数は４台である、現在の市販ハードディスクは一台当たり２５０Ｇ程度であるから
２５０＊４＝１０００Ｇ
となり、
１０００Ｇ／１，５Ｇ＝６６６
よって、一台のパソコンに約６００本程度の保管が限界となる。ハードディスクは年々増加傾向にあるが、仮に１０倍のデータ量を保管できると見込んでも６千本／台となる。
【００１３】
よって５万本を処理する場合は、最低でも８台〜９台が必要となる。ビデオショップの売上から求めた台数は４５台なので、それぞれに１７００Ｇ（約１１１１本）ずつを配置すれば問題ないように思える。
しかしながら、これでは借り出される任意のレーベル（ビデオの作品単位である）が、人気があり、借り出しが任意のサーバーに偏ってしまった場合に、そのレーベルは４５人しかサービスできない。また４５人にサービスを行っている場合は上記サーバーに存在する他のレーベルもサービスできない。これでは営業上の問題が発生してしまう。人気レーベルの予測等によって、同じレーベルを複数用意し複数のサーバーへ分散することも考えられるが、必ず予測が当たるとはいえず、また分散作業も大変で、更に余分の容量も確保しなければならない。
【００１４】
そこで１サーバーあたり４５人という問題を解決するために、図９に示すように、回線サーバーにはレーベルを置かずに、この回線サーバーと高速なイントラネットで接続されているビデオレーベルサーバーからレーベルを取得してインターネット回線に流す方法がある。これであれば、全ての回線サーバーから送信が可能である。この図は、いわば図８のサーバー部分の処理を置き換えたものである。
【００１５】
この図９の構成は、ＶＯＤ（ビデオオンデマンド）配信元で、それぞれの回線サーバーに１０Ｇｂｐｓの高速のイントラネットを使い、必要なレーベルをレーベルサーバーから読み取りつつ、複数の回線サーバーに配信する。各々の回線サーバーはインターネットにビデオデータを流す構成である。しかしこの方法でも、１台のレーベルサーバーに１６００人（店舗が一日に扱う延べ人数）がアクセスした場合、最初に計算した経路速度を考えると、レーベルサーバーのハードディスクからメモリーまでの経路１、メモリーからＬＡＮカードまでの経路２については、通常のサーバーと同じに、それぞれ７００Ｍｂｐｓ、３２０００Ｍｂｐｓとなるので、
経路１（ハードディスク）：    ０．４４Ｍｂｐｓ＝    ７００／１６００Ｍｂｐｓ
経路２（メモリー）      ：        ２０Ｍｂｐｓ＝３２０００／１６００Ｍｂｐｓ
となる。実際に１Ｇバイトを１時間で流す場合、２．２Ｍｂｐｓが必要となるため、０．４４Ｍｂｐｓでは無理がある。実際に２．２Ｍを守るためには３００人程度のアクセスが限界となる。レーベルサーバーを増やしていくことで緩和していくが、根本的な解決にはならない。また常にハードディスクにアクセスしているシステムであるのでハードディスクトラブルがおのずと高くなる。トラブルが発生して、いずれかのレーベルサーバーがダウンした場合、そこに入っているレーベルの全てが使用できなくなり、ユーザーは借りてきたビデオを見ることができない。
【００１６】
なお、先行技術には、複数のサーバーの負荷率を考慮して負荷を分散する技術が、以下の特許文献１に記載される。
【特許文献１】特開2001-094959
【発明の開示】
【発明が解決しようとする課題】
【００１７】
以上のように、インターネットを経由して動画や音声などの大容量コンテンツが配信されるビデオオンデマンドのシステムにおいて、複数のレーベルサーバーを備える場合であっても、各レーベルサーバーのハードディスクからメモリーまでの経路１の転送速度が足りなくなる為、人気のあるレーベル（ビデオの作品単位である）が納められたレーベルサーバーへのアクセス集中に弱い。
【００１８】
このような課題は、ビデオオンデマンドのシステムに限らず、他の大容量コンテンツ配信システムについては同様に存在することになる。
【課題を解決するための手段】
【００１９】
以上の課題を解決するために、第一発明は、広域ネットワークの大容量コンテンツ配信システムであって、このシステムを構成して広域ネットワークに接続する複数のサーバーと、各サーバー内において、大容量コンテンツを複数に分解した分解要素を記憶する記憶手段と、広域ネットワークに接続するユーザーからの要求信号に応じて、前記分解要素を相互の配置的な前後を設定した信号とともに広域ネットワークへ送信する送信手段と、を有してなることを特徴とする広域ネットワーク大容量コンテンツ配信システムである。
第二発明は、さらに、一つの前記サーバーが記憶する前記分解要素は、前記一つの大容量コンテンツに対し、異なる配置に属する複数があり、前記配信は、前記複数の分解要素ごとに複数の配信タイミングによりおこなうことを特徴とする広域ネットワーク大容量コンテンツ配信システムである。
第三発明は、さらに、前記複数のサーバーは、前記システムを構成することを同意して登録された一般家庭のパソコンであることを特徴とする広域ネットワーク大容量コンテンツ配信システム。
第四発明は、広域ネットワークの大容量コンテンツ配信方法であって、このシステムを構成して広域ネットワークに接続する複数のサーバー内の記憶手段に対して、大容量コンテンツを複数に分解した分解要素を記憶させる記憶ステップと、広域ネットワークに接続するユーザーからの要求信号に応じて、前記分解要素を相互の配置的な前後を設定した信号とともに広域ネットワークへ送信する送信ステップと、を有してなることを特徴とする広域ネットワーク大容量コンテンツ配信方法である。
第五発明は、さらに、一つの前記サーバーが記憶する前記分解要素は、前記一つの大容量コンテンツに対し、異なる配置に属する複数があり、前記配信は、前記複数の分解要素ごとに複数の配信タイミングによりおこなうことを特徴とする広域ネットワーク大容量コンテンツ配信方法である。
第六発明は、さらに、前記複数のサーバーは、前記システムを構成することを同意して登録された一般家庭のパソコンであることを特徴とする広域ネットワーク大容量コンテンツ配信方法である。
第七発明は、インターネットを経由して動画や音声などのビデオの作品が配信されるビデオオンデマンドのシステムであって、このシステムを構成してインターネットに接続する複数のサーバーと、各サーバー内において、ビデオの作品単位である一つのレーベルを複数に分解した分解要素を記憶する記憶手段と、インターネットに接続するユーザーの個人パソコンからの要求信号に応じて、前記分解要素を相互の配置的な前後を設定した信号とともにインターネットへ送信する送信手段と、を有してなることを特徴とする広域ネットワーク大容量コンテンツ配信システムである。
第八発明は、さらに、一つの前記サーバーが記憶する前記分解要素は、前記一つのレーベルに対し、異なる配置に属する複数があり、前記配信は、前記複数の分解要素ごとに複数の配信タイミングによりおこなうことを特徴とする請求項７に記載の広域ネットワーク大容量コンテンツ配信システム。
第九発明は、さらに、前記複数のサーバーは、前記システムを構成することを同意して登録された一般家庭のパソコンであることを特徴とする広域ネットワーク大容量コンテンツ配信システムである。
第十発明は、インターネットを経由して動画や音声などのビデオの作品が配信されるビデオオンデマンドの配信方法であって、このシステムを構成してインターネットに接続する複数のサーバー内の記憶手段に対して、ビデオの作品単位である一つのレーベルを複数に分解した分解要素を記憶させる記憶ステップと、インターネットに接続するユーザーの個人パソコンからの要求信号に応じて、前記分解要素を相互の配置的な前後を設定した信号とともにインターネットへ送信する送信ステップと、を有してなることを特徴とする広域ネットワーク大容量コンテンツ配信方法である。
第十一発明は、さらに、一つの前記サーバーが記憶する前記分解要素は、前記一つのレーベルに対し、異なる配置に属する複数があり、前記配信は、前記複数の分解要素ごとに複数の配信タイミングによりおこなうことを特徴とする広域ネットワーク大容量コンテンツ配信方法である。
第十二発明は、さらに、前記複数のサーバーは、前記システムを構成することを同意して登録された一般家庭のパソコンであることを特徴とする広域ネットワーク大容量コンテンツ配信方法である。
【発明の効果】
【００２０】
第一、第二、第三、第四、第五、及び第六発明によれば、システムを構成する複数の各サーバー内において、配置的な順序を有する大容量コンテンツを複数に分解した分解要素を記憶し、ユーザーからの要求信号に応じて、この分解要素を相互の配置的な前後を設定した信号とともに広域ネットワークへ送信することにより、仮に、ある特定の大容量コンテンツへアクセスが集中しても、各サーバーが記憶するその特定の大容量コンテンツを分解した分解要素を送信し、よって、アクセス集中による負荷はいわば各サーバーが分散して受け持つので、ある特定のサーバーにアクセスが集中することにはならない。
【００２１】
第二、第三、第五、及び第六発明によれば、さらに、各サーバーが記憶する分解要素は、一つの配置的な順序を有する大容量コンテンツに対し、異なる配置に属する複数があり、配信は、これらの分解要素ごとに複数の配信タイミングによりおこなうことによって、一つの配信タイミングから次の配信タイミングまでに、時間的な余裕ができ、他のアクセスによる要求に対して時間的な余裕をもって対応できる。
【００２２】
第三、及び第六発明によれば、さらに、複数のサーバーは、一般家庭のパソコンとすることで、一般家庭のパソコンの余剰能力を活用でき、ハードウエア資源の有効活用を図れる。
第七、第八、第九、第十、第十一、及び第十二発明によれば、システムを構成する複数の各サーバー内において、ビデオの作品単位である一つのレーベルを複数に分解した分解要素を記憶し、ユーザーからの要求信号に応じて、この分解要素を相互の配置的な前後を設定した信号とともにインターネットへ送信することにより、仮に、ある特定のレーベルへアクセスが集中しても、各サーバーが記憶するその特定のレーベルを分解した分解要素を送信し、よって、アクセス集中による負荷はいわば各サーバーが分散して受け持つので、ある特定のサーバーにアクセスが集中することにはならない。  
第八、第九、第十一、及び第十二発明によれば、さらに、各サーバーが記憶する分解要素は、一つのレーベルに対し、異なる配置に属する複数があり、配信は、これらの分解要素ごとに複数の配信タイミングによりおこなうことによって、一つの配信タイミングから次の配信タイミングまでに、時間的な余裕ができ、他のアクセスによる要求に対して時間的な余裕をもって対応できる。
【００２３】
第九、及び第十二発明によれば、複数のサーバーは、一般家庭のパソコンとすることで、一般家庭のパソコンの余剰能力を活用でき、ハードウエア資源の有効活用を図れる。
【発明を実施するための最良の形態】
【００２４】
この発明の第１実施形態を、図１に示す。
この実施形態は、インターネットを経由して動画や音声などの大容量コンテンツが配信されるビデオオンデマンドのシステムに関する。このシステムは、ビデオ配信業務をおこなう店舗に設置され、インターネットＮにそれぞれが接続する複数のサーバーＳによって構成される。
【００２５】
図１（Ａ）に示すように、各サーバー（図中Ｓ１〜Ｓ３６で示す）内においては、ビデオの作品単位である一つのレーベルを複数に分解した分解要素Ｅが記憶手段としてのハードディスクＨに記憶される。一つのサーバーＳが記憶する分解要素Ｅは、一つのレーベルに対し、一つでも良いし、異なる配置に属する複数が記憶されるとしてもよい。図においては一つとする。
【００２６】
また、それぞれ一つのサーバーＳ内においては、このような分解要素Ｅが、その店舗の扱う全てのビデオのレーベルに関して記憶される。
各サーバーＳ内の図示しない制御回路が兼ねる送信手段は、インターネットに接続するユーザーの個人パソコンからの要求信号に応じて、分解要素Ｅを送信する。このとき、同様にして他のサーバーＳから送信される分解要素Ｅとの相互の配置的な前後関係は、前後関係を設定した信号によって特定される。この信号は各サーバーＳ内の制御回路が兼ねる送信手段から、分解要素Ｅとともに同時に送信される。
【００２７】
このように構成することで、仮に、ある特定の大容量コンテンツへアクセスが集中しても、各サーバーＳが記憶するその特定の大容量コンテンツを分解した分解要素Ｅを送信する。よって、アクセス集中による負荷はいわば各サーバーＳが分散して受け持ち、図１（Ｂ）に示すように各サーバーＳは常に稼動する。なお、図１（Ｂ）の各ブロック内のグラフは、縦軸が各サーバーＳの稼動の程度を示し、横軸がアクセスの程度を示す。このように、ある特定のサーバーにアクセスが集中することにはならない。
これに対し図２（Ａ）に示す比較例では、従来のように各サーバー（図中Ｓ１〜Ｓ３６で示す）は、ビデオの作品単位である各レーベルＬは、分解されることなく、一つにまとまったまま記憶手段としてのハードディスクＨに記憶される。よって、アクセス集中による負荷は、集中が起きた人気のあるレーベルＬを有するあるサーバーＳ３に集中することとなる（図２（Ｂ））。
【００２８】
（具体例）
この発明の具体例としての第２実施形態を図３、図４、及び図５に示す。
前記第１実施形態と同様にサーバ−Ｓは３６台が備えられるが、一つのサーバーＳが記憶する分解要素Ｅが、一つのレーベルに対し、一つではなく、異なる配置に属する複数がある。配信は、複数の分解要素Ｅごとに複数の配信タイミングにより繰り返して行われる。
【００２９】
また、図３に示すように、各７台のサーバーＳからなるグループ毎に、複数の分解要素Ｅがまとまって同時に配信される。各グループには、後述するように１台の補完データ用サーバーが備えられるので、まとまって配信される分解要素Ｅは他の６台から配信される６つである。６つの分解要素Ｅが、時間軸ｔに沿って合計５回配信されることで、３６台のサーバーがほぼ一巡して配信を終える。この配信が複数巡して、一つのレーベルの配信が完了する。この複数巡の回数は、一つのサーバーＳが一つのレーベルに対して記憶する、異なる配置に属する分解要素Ｅの個数に一致する。
【００３０】
この実施形態において、９０分のビデオのレーベルを配信する時の時間系列で見た処理は図４のようになり、サーバー毎に見た処理は図５のようになる。
ひとつのレーベルが９０分であり、よって１．５Ｇの大きさを持つと仮定して、例えば３６に時間単位で分解して、分解した一つの分解要素を複数台のサーバーが記憶する。すなわち各サーバーは、１．５Ｇｂｙｔｅｓ／３６≒４２Ｍｂｙｔｅｓ（２分３０秒）の一部を受け持つことになる。この受け持ち分は４２Mｂｙｔｅｓを例えば６分割することによって求める。すなわち、この６分割によって４２Mｂｙｔｅｓはそれぞれ７Mｂｙｔｅｓ（２５秒）ずつに分解される。よって、図４に示すように、ひとつのレーベルをユーザーに提供する場合に０分〜２．５分をサーバー１、２、３、４、５、６、７（７は補完データ）が同時配信、２．５分〜５分をサーバー８、９、１０、１１、１２、１３、１４（１４は補完データ）が同時配信、５分〜７．５分→サーバー１５、１６、１７、１８、１９、２０、２１（２１は補完データ）が同時配信、・・・・、８７．５分〜９０分をサーバー３０、３１、３２、３３、３４、３５、３６が同時配信という具合に分散する。２．５分毎にサーバー群を切り替えて同時配信することになる。
【００３１】
（具体例による効果）
これによって、過度のアクセス集中に対する解決が得られる。すなわち、時間ごとにサーバーが切り替わるため、アクセス集中はしない。また、ひとつのサーバーから見ると合計で４２Ｍｂｙｔｅｓのデータを提供しているだけであるから、前述の一般的なＨＰのページ数にして４２０ページを１．５時間当たりに接続することと同じになるので、１時間当たりを約２８０ページとすると１６００人が接続できることになり、３６台のサーバを設置した場合の計算どおりの結果が得られる。
【００３２】
また、レーベルの適切な分散が得られる。すなわち、レーベルそのものが分散されているため、どのようなレーベルがアクセスされても均等にサーバーを使用することができ完全に適切な分散ができる。
また、レーベルサーバーと回線サーバーが必要なためにコストがかさむということがない。すなわち、背景技術に比べ、レーベルデータはいわば回線サーバーに配置するため、レーベルサーバーを配置する必要はなくなる。また、前出の７万５千Ｇｂｙｔｅｓを３６等分すればよいので、７万５千／３６≒２１００Ｇｂｙｔｅｓとなり、それぞれの回線サーバーに２１００Gｂｙｔｅｓのハードディスクを接続すれば良いことになる。
【００３３】
また、過度のアクセス集中が起きた場合、サーバートラブルが偏ることも避けられる。すなわち、サーバーは均等に使用されるのでトラブルが偏ることは無く、結果的にトラブルの頻度が是正される。
（具体的な計算で示す効果）
ここで、この実施形態の処理方法を行ったことにより１つのレーベルに何人のアクセスが可能なのか計算してみる。９０分のレーベルを見るにあたって、１時間の再生に１Ｇｂｙｔｅｓのデータを必要とするとして、
１Ｇｂｙｔｅｓ＝８０００Ｍｂｉｔｓ
１時間＝３６００ｓｅｃ
よって、１秒あたりに要求される転送量は
８０００Ｍ／３．６Ｋ＝８Ｍ／３．６≒２．２Ｍ［ｂｉｔｓ／ｓｅｃ］
前出の３６台のサーバーを使用した場合、１サーバーが配信する量は２５秒分（７Ｍｂｙｔｅｓ）であるから、２５秒分の転送量を算出すると、
２５秒間の転送データ量は、２．２Ｍ＊２５≒５６Ｍ［ｂｉｔｓ／ｓｅｃ］
１００Ｍｂｐｓ（ｂｉｔｓ／ｓｅｃ）の通信速度を持つパソコンの場合、２５秒間の再生に必要なデータを取得する時間は
５６／１００＝０．５６秒となる）
一ユーザーあたり、２分３０秒毎にサーバー紹介を要求してくるため、２分３０秒＝１５０秒を０．５６秒で割ったものになる。１５０／０．５６＝２７０人となる。
【００３４】
ここの例では説明がわかりやすいように、一回のサーバー紹介数を補完データを含めて７サーバー（実データは６サーバー）としたが、補完データを含めて１３サーバー（実データは１２サーバー）とした場合は担当時間が６／１２＝１／２（１２．５秒）になり、同時アクセス可能人数はサーバー担当時間の逆数に比例するので、倍の５４０人に提供できる。最大の構成を考えた場合は一回の紹介を３６サーバー全て使用するとすれば、実データを受け持つサーバーは３５サーバーであるから担当時間は６／３５である。この逆数は３５／６≒５．８倍。５．８＊２７０≒１５７５人となる。また、同時アクセス可能人数はサーバー紹介時間間隔（例では2分３０秒）の逆数に比例するので、サーバーの紹介時間間隔を短くすることによっても同等の結果が得られる。
以上をまとめれば、大容量データを一定時間単位でサーバーに分散し、時間毎にサーバーを切り替えて使用し、複数台のサーバーを１台のサーバーに見立てて運用することができるため、高度な性能が提供できる、ということになる。
【００３５】
（各個のサーバーのトラブルを防ぐ補完データ）
各個のサーバーのトラブル時の影響として、一台のサーバーのトラブルが全てのレーベルの使用不能につながる可能性がある。このトラブルを防ぐために、所定台数のサーバー毎に補完データを扱う補完データ用サーバーを設ける。すなわちここでは、６台のサーバー毎に７台目の補完データ用サーバーを設ける。補完の方法は、いわば排他的論理和の手法を用いる。
【００３６】
すなわち、まず、４２Ｍｂｙｔｅｓのデータを例えば６分割する。４２Ｍｂｙｔｅｓ／６＝７Ｍｂｙｔｅｓ（２５秒）となる。それぞれ０〜２５秒の部分をサーバー１、２５秒〜５０秒の部分をサーバー２、５０秒〜７５秒の部分をサーバー３、・・・、１２５秒〜１５０秒の部分をサーバー６にそれぞれ記憶する。その上で、それぞれのデータを２進数として扱う。１バイトは８ビットからなるので、それぞれ５６Ｍビットとなる。各時間ごとの５６Ｍビットのデータの最初のビットの１の数を数える。数えた数が奇数であれば１、偶数であれば０とする。全てのビットで同じ処理を行うと、新たに５６Mビットのデータを得ることができる。これが補完データである。これを７台目のサーバー７に記憶させる。
【００３７】
各時間単位のサーバーの処理状態を説明すると、
０〜  ２５秒  ：サーバー１：０１１０１０００１０１０１１１１０．．．
２５〜  ５０秒  ：サーバー２：０１１０１０１０１１１１０１０００．．．
５０〜  ７５秒  ：サーバー３：０１１０１０１０１０００１０１１１．．．
７５〜１００秒  ：サーバー４：１１０１０１０１０００１０１１１０．．．
１００〜１２５秒：サーバー５：０１０１０１０１０００１０１１１０．．．
１２５〜１５０秒：サーバー６：１０１０００１０１１１０１１０１０．．．
補完データ      ：サーバー７：０１００１０１０００１１１１０１１．．．
ユーザーは７台のサーバーから一気に０〜２分３０秒のデータと補完データを同時に受信する。
【００３８】
ここで７台のうち、サーバー５に故障が起きていたとすると、サーバー１、２、３、４、６、７（補完データ）が取得できることになる。ここで、サーバー１、２、３、４、６の各ビットの１の数を数える。
０〜  ２５秒  ：サーバー１：０１１０１０００１０１０１１１１０．．．
２５〜  ５０秒  ：サーバー２：０１１０１０１０１１１１０１０００．．．
５０〜  ７５秒  ：サーバー３：０１１０１０１０１０００１０１１１．．．
７５〜１００秒  ：サーバー４：１１０１０１０１０００１０１１１０．．．
１２５〜１５０秒：サーバー６：１０１０００１０１１１０１１０１０．．．
数えた結果      ：          ：０００１１１１１００１０１０１０１
補完データ      ：サーバー７：０１００１０１０００１１１１０１１．．．
数えた結果を各ビット毎に補完データと比較する。最初のビットはお互いに０である。つまり１の数は足りているわけなので、欠損したサーバー５の最初のビットは０と考えられる。次のビットは数えた結果が０、補完データが１であるので、１が足りないということになる。よって、２番目は１であるということになる。このように、比較結果が異なるビットは１、同じビットは０と表現したデータ列を導出データとすると、導出データと欠損したサーバー５のデータを復元できたことがわかる。
【００３９】
数えた結果      ：          ：０００１１１１１００１０１０１０１
補完データ      ：サーバー７：０１００１０１０００１１１１０１１．．．
導出データ      ：          ：０１０１０１０１０００１０１１１０ 
１００〜１２５秒：サーバー５：０１０１０１０１０００１０１１１０．．．
この方法によって、いずれかのサーバーがダウンした場合もダウンしたサーバーの提供するデータを復元できるため、サーバートラブル時の影響が大きいという問題を解決することができる。
【００４０】
ここで以上の補完データによる解決策の流れをまとめて見ると、ユーザーが受信する１回のデータは、サーバー１からサーバー６の各２５秒毎のデータと、サーバー７の２分３０秒の補完データとなる。３６台のサーバーで各処理を３６回繰り返し送信することにより９０分のビデオデータがユーザーに送信されることとなる。
【００４１】
（サーバーとして一般家庭のパソコンを使用） 
以上の実施形態は、一つの店舗に複数のサーバー（専用のパソコン）を備えてシステムを構成する場合を説明したが、これらのサーバーとして一般家庭のパソコンを利用することもできる。すなわち、インターネットフランチャイズ方式として、一般家庭のパソコンの余剰能力を提供していただくことによってシステムを構成する。  図６に示すように、広域ネットワークの大容量コンテンツ配信システムを構成することを同意して登録された一般家庭のパソコンには、フランチャイズ本部から提供される特定のソフトウェアをダウンロードして起動することによって、以上の実施形態で説明した機能をそのまま活用でき、パソコンも通信回線も既に存在しているものを使用できるので、設備投資も必要ない。
【００４２】
図示するように、一般家庭のパソコンを登録者パソコンとしてシステムへ登録し、この登録は登録専用のホームページにある登録用のソフトウェアをダウンロードし、実行することによって行われる。その後、フランチャイズ登録サーバーが登録者のパソコンの査定を行い、充分な性能を持っていると判断すると正式にシステムの一部として認識し登録者パソコンはデータの送信部を担当するサーバーとして機能を開始する。
【００４３】
次にＶＯＤ（ビデオオンデマンド）のユーザーが実際にビデオのレーベルのデータを受信する時のしくみを図７で説明する。ＶＯＤユーザーは受信を希望するビデオのレーベルを示すタイトルを本部のサーバーに送信し、要求をおこなう。本部サーバーはそのビデオタイトルを所有する登録者パソコンを選択して紹介する。ユーザーパソコンは紹介された登録者パソコンから実際のビデオデータを取得する。レーベルの送信手順は前記実施形態で説明した方法でおこなう。
【００４４】
（サーバーとして一般家庭のパソコンを使用する場合の問題点）
次に一般的な家庭のパソコンを送信システムの一部として使用する場合の問題点がいくつかある。
第１に送信速度の脆弱さである。一般的に普及している、ＡＤＳＬは送信（上り）速度と受信（下り）速度が違う。これが、Ａ（アシンクロナス：非対称）のいわれである。なるべく受信速度を高めるために送信速度が１Ｍｂｐｓ程度に抑えられている。ユーザーとして使う場合は問題はない。ユーザーはほとんどが受信だからである。一方、提供者（サーバー）としては致命的である。このままでは、一般的なＶＯＤファイルの仕様である１Ｇｂｙｔｅｓのデータを１時間で送るための速度である２．２Ｍｂｐｓの送信帯域を必要とするビデオサーバーとしては使えない。
【００４５】
第２に提供時間の安定性である。一般家庭のパソコンを使用する際に、「必ずパソコンの電源が入っている」ことを期待することはできない。また、サービス中に電源を切られる可能性もある。ビデオサーバーとして使用する場合は一旦接続した後は１〜２時間もの間サービスを継続的に行わなければならない。不定期に電源を切られる可能性のあるパソコンを使用するのは困難であると思われる。
【００４６】
第３にパソコンの安定性である。一般家庭のパソコンの場合は、サーバーとしてシステムが利用している間もパソコン提供者が他のアプリケーションを使用している可能性を考えなければいけない。これは、状況によってパソコンの提供できる性能が変化することを示す。アプリケーションの使用状態によっては過度の利用によってスワップが発生し過渡的に著しい速度の低下を招いたり、最悪の場合はパソコンのフリーズ（暴走）も想定しなければならない。
【００４７】
（サーバーとして一般家庭のパソコンを使用する場合の問題点の解決策）
第１の問題点である送信速度の脆弱さの解決策について説明する。これまでは便宜上、２５秒分として計算したが、この２５秒という値は００３４で示したように変更することができる。ＡＤＳＬは上りが１Ｍｂｐｓであるが、半分の５００Ｋｂｐｓとした場合は１ＧＢ、１時間のファイルの約０．２３秒分のデータに相当する。前出の例では一度に６台のサーバーから同時配信するとしたので、一度に転送できる量はこの６倍＝０．２３*６＝1．３５秒。一度に転送する量は最低が１秒分を上回っていれば良いので、これで問題は解決できる。実際には一度に繋ぐサーバーの数を増やすことで更に速度は向上する。
【００４８】
第２の問題点である提供時間の安定性の解決策について説明する。上記の計算に使用したように、一つのサーバーに要求される送信速度を５００ｂｐｓとしたことから、逆にサーバー側がユーザーに保証する接続時間は最低０．５秒間で良いことになる。これであれば提供時間が不定期であっても充分に使用に耐える。
【００４９】
第３の問題点であるパソコンの安定性の解決策について説明する。補完データを含む７つのサーバーのうち一台に問題が出た場合も回復が可能であることは前述した。この論理によっていずれかのパソコンが不安定になってもユーザーは問題なく受信が可能である。またパソコン提供者は提供していることを意識せずにパソコンの使用が可能なので、気軽に提供が可能である。
【００５０】
（サーバーとして一般家庭のパソコンを使用する場合の具体例）
次に、一般家庭のパソコンを使用する場合の最低限のシステム構成と、自己復旧機能について説明する。一般家庭のパソコンは常に電源が入っているとは限らないので、最低限のサービスを行う為のシステム構成を考える。なお、この計算は以下の前提が基本になっている。
【００５１】
・一台のパソコンに接続できるハードディスクの限界数：4
・一台のハードディスクの上限                      ：1000Gbytes
・ビデオレーベル１本あたりの使用量                ：1.5GB
・ビデオレーベルの保有数                          ：５万本
・ユーザーへの一回あたりの接続数                  ：７接続（６データ、１補完）
・一台のパソコンが持つ送信速度                    ：100Mbps
・ビデオレーベルの１秒あたりに必要な送信量        ：1GB／3600≒278Kbytes
ここから、最低限必要なパソコンの数を求める。
【００５２】
・一台当たり使用可能なハードディスク容量    ：4＊1000GB＝4000GBbytes
・全てのビデオレーベルを保有するための必要量：1.5GB＊50000＝75000GBbytes
・補完データの量                            ：75000／6＝12500GBbytes
・総必要量                                  ：75000＋12500＝87500GBbytes
・送信に必要な最低限のパソコンの数          ：87500／4000≒22台
・各種管理サーバー                          ：１台
上記の構成（22＋1＝２３台）で同時にサービス可能な人数は、１秒あたりに必要な送信量とそれに伴う、補完データの量を加えたもので合計の送信速度を割ったものになる。
【００５３】
・ビデオレーベルの１秒あたりに必要な送信量      ：1Gbytes／3600≒278Kbytes
・ビデオレーベルの１秒あたりに必要な補完データ量：278／6≒46.3Kbytes
・１秒間に必要な総送信量（ｂｙｔｅｓ）          ：278＋46.3＝324.3Kbytes
・１秒間に必要な総送信量（ｂｉｔｓ）            ：324.3＊8≒2.6Mbits
・送信速度の合計量                              ：100＊22＝2200Mbps
・同時利用可能者数                              ：2200／2.6≒864人
となる。
【００５４】
この構成で、例えば一台が動作中に異常となった場合に、
・サーバー分散（１ユーザー対多サーバー構成）、
・補完データによるデータ修復の機能
を使用して、自己修復が可能である。いずれかの１台のパソコンに異常が生じた場合、全ての送信サーバーを管理している管理サーバーに異常の発生したパソコンがそれぞれのビデオレーベルのどの配置部分を持っているのかを記録しておくことで、前述の修復方法を利用して全てのデータを復活させることが可能となる。復活されるまでの間もユーザーには滞りなくサービスができる。ただし、この場合、余分に一台分を復旧用として設置しておくほうが安全である。すなわち、最低限の台数は２４台ということになる。
【００５５】
配信速度もサーバー分散（１ユーザー対多サーバー構成）によって高速に行われる。システムに登録されたパソコンへの配信速度を試算する。登録した家庭用パソコンにはユーザーが受信を希望するまでは何のデータも存在しないとする。そこで、受信要求が発生した場合に全ての登録パソコンになるべく分散するようにデータを送出する。２２台のそれぞれのパソコンから同時送信が可能なので、２２００Ｍｂｐｓの速度となる。よって、１．５ＧＢ（１．５時間）のビデオデータを全ての登録パソコンに送出する時間は１．５Ｇ＊８／２．２Ｍ≒５．４５秒である。実際には、他のユーザーへの使用時間なども考慮する必要があるが、誤差は１０％程度と思われる。一度、配信したデータは必要が無い限り消されないので、同じレーベルを他のユーザーから要求された場合は再利用が可能である。
【００５６】
以上のサーバー分散（１ユーザー対多サーバー構成）と補完データによるデータ修復の２点が核となる技術である。
【００５７】
（サーバーとして一般家庭のパソコンを使用する場合の利点）
この方式によって、次の利点がある。すなわち高い拡張性と柔軟性である。ユーザーが増えて更に大規模なサービスが要求される場合でも、登録者を募ることによって柔軟に対応ができる。
【００５８】
また、メンテナンスコストの低減もある。すなわち、最も稼動時間が長い送信部を登録制とするためにハードウェアメンテナンスは登録者に一任できるため、メンテナンスコストを最低限まで低減できる。
【００５９】
（登録者への報酬）
また、登録者への報酬がある。すなわち登録者にはパソコンの使用頻度に応じた率で何らかの利用対価を支払うのが妥当であり、この対価によって登録意欲が刺激される。利用対価については以下のもが考えられる。
【００６０】
まず、金銭による対価：利用頻度比例方式で、登録者に使用料を支払う方式である。月額の使用料を決めるわけではなく、その月の売上から必要経費を差し引いた残額のうち一定率の使用料を登録者で分配する。分配の基準は本システムが使用した登録者パソコンのサービス利用頻度に応じて行われる。利用頻度は登録者パソコンの性能と安定性で決まるので、フェアな分配が可能である。登録者にとって実質的な対価が支払われるので魅力は高いと思われる。
【００６１】
次に、金銭による対価：宝くじ方式で、前述と同じく登録者に使用料を支払う方式であるが、利用頻度に応じて宝くじを配布する。すなわち、利用頻度が高い場合はたくさんの宝くじを所持できるわけである。月末に宝くじ抽選を行い、その金額をそれぞれの当選者に支払う。この場合に、宝くじの抽選をイベント化できるため宣伝効果を演出することもできる。さらに、登録者が増えても当選金額が減らない。実際には登録者が増えるとあたりにくくなるわけであるが、実際の当選金額が大きく変わらないため損した感覚になりにくいといえる。なお、この宝くじは電算化されたものとする。
【００６２】
また、ビデオ無料貸し出し券で、本システムが使用した登録者パソコンのサービス利用頻度に応じて、登録者にＶＯＤ経由の無料貸し出し券を提供する方式である。この場合は実質的なコストが掛からない一方、登録者の登録意欲を刺激するレベルが低い。こういった方式の場合、貸し出し券の譲渡が可能になっている事が必要であると思われる。
【００６３】
登録者はあくまでも「パソコンの電源を入れているだけ」で上記のような権利を受けられるので、充分に登録者を集めることは可能と考えられる。また、ホームページに毎日利用頻度のランキングを発表するなどの演出によってマニア心をくすぐることもできる。利用頻度はパソコンの安定性や性能の指針であることを明確にして行うことで、パソコン性能のランキングと読み替えることが出来るため、虚栄心を充分に満たせる。
【００６４】
（他の実施形態）
以上の実施形態では、動画や音声などのビデオの作品が配信されるビデオオンデマンドのシステムに関し、ビデオの作品単位である一つのレーベルを複数に分解した分解要素を配信する例を説明したが、この発明はこれに限らず、他の実施形態では、他の大容量コンテンツ配信システムについても、実施できる。例えば、最近のコンシューマゲーム等の様に大量の画像データを扱うものをインターネット配信する場合の画像データ部の代理提供をおこなう配信システム、車載ＧＰＳの地図情報の代理提供をおこなう配信システム、過度なアクセスによってアクセス速度の落ちたホームページのデータを代理応答することによってアクセス速度の向上をおこなう配信システム、などである。また、本システムから一般家庭のパソコンの登録部分をのぞいたものをＬＡＮ上に構築することでホテルなどのＶＯＤシステムとしても有効に機能する
【図面の簡単な説明】
【００６５】
【図１】この発明の第１実施形態を示すもので（Ａ）はシステムを構成する各サーバーのハードディスクの説明を模式的に示すブロック図、（Ｂ）は各サーバーの稼動の様子をグラフで示すブロック図である。
【図２】図１に対する比較例としての従来例を示すもので（Ａ）はシステムを構成する各サーバーのハードディスクの説明を模式的に示すブロック図、（Ｂ）は各サーバーの稼動の様子をグラフで示すブロック図である。
【図３】この発明の第２実施形態を示すものであり、第１実施形態の図１（Ａ）に対応する図である。
【図４】図３のシステムの時間系列で見た処理を示す図である。
【図５】図３のシステムのサーバー毎に見た処理を示す図である。
【図６】この発明の実施形態を示すもので、サーバーとして一般家庭のパソコンを登録して使用する場合の登録の説明図である。
【図７】この発明の実施形態を示すもので、サーバーとして一般家庭のパソコンを使用する場合、実際にビデオのレーベルのデータを受信する時のしくみを説明する説明図である。
【図８】背景技術を説明する従来の図である。
【図９】背景技術を説明する他の従来の図である。
【符号の説明】
【００６６】
Ｓ・・・サーバー、  Ｎ・・・インターネット、  Ｅ・・・時間分解要素、  Ｌ・・・レーベル（ビデオの作品単位）
【図４】
2005309640.tif 000003
【図５】
2005309640.tif 000004
【図６】
2005309640.tif 000005
【図７】
2005309640.tif 000006
【図８】
2005309640.tif 000007
【図９】
2005309640.tif 000008
【図１】
2005309640.tif 000009
【図２】
2005309640.tif 000010
【図３】
2005309640.tif 000011