(57)【要約】【課題】クライアント３０の回線が高速化していることを利用し、より効率よく大容量のコンテンツを配信するコンテンツ配信システム２０を提供する。【解決手段】サーバは、クライアント３０やサーバへの同時接続数、各端末の回線容量、各端末への配信済みコンテンツとそのサイズなどを記憶している。クライアント３０がサーバに対してコンテンツの配信要求をしてきた際、記憶している情報を元に回線に余裕のある端末を選択して、コンテンツのダウンロード先として指定する。【選択図】　　　図１
2004118417.tif 000002
【特許請求の範囲】
【請求項１】
所定のコンテンツに対応したファイルの配信を司るサーバと、該ファイルをネットワークを介して交換するクライアントおよび／またはサーバにより構成されるコンテンツ配信システムであって、
前記サーバは、
配信が可能となったファイルの存在を前記各クライアントに通知する通知部と、
前記各クライアントに対する前記ファイルの配信状況を管理する管理部と、
前記クライアントからの要求に従い、前記ファイルの配信状況を参照し、前記クライアントがダウンロードするファイルを保有しているサーバまたはクライアントを指定する指定部と
を備え、
前記クライアントは、
前記サーバからの前記通知を受け付ける通知受付部と、
前記受け付けた通知により特定されたファイルのダウンロードを、前記サーバに要求する要求部を備え、
前記サーバの指定部が指定した前記サーバまたはクライアントから、前記ファイルのダウンロードを要求したクライアントへの、該ファイルの転送を実現するファイル転送手段
とを備えた
コンテンツ配信システム。
【請求項２】
前記ファイル転送手段は、前記ファイルのダウンロードを要求したクライアントに設けられ、
前記要求に応答して、前記サーバの指定部が行なった指定を取得する指定受付部と、
前記指定受付部で取得した指定に従い、該指定されたサーバまたはクライアントから、前記ファイルのダウンロードを行なうダウンロード部と
からなる請求項１記載のコンテンツ配信システム。
【請求項３】
前記ファイル転送手段は、前記サーバの指定部が指定した前記サーバまたはクライアントに設けられ、
前記サーバから、ファイルのダウンロードを要求した前記クライアントへの配信命令を取得する配信受付部と、
前記配信受付部で取得した配信命令に従い、ファイルのダウンロードを要求した前記クライアントへ、前記ファイルの配信を行なう配信部と
からなる請求項１ないし請求項２のいずれか記載のコンテンツ配信システム。
【請求項４】
前記サーバは、前記指定部がクライアントを指定した場合は、指定されたクライアントに対して、ファイルのダウンロード要求があることを通知する請求項１ないし請求項２のいずれか記載のコンテンツ配信システム。
【請求項５】
前記サーバは、所定の地域ごとに設置された地域サーバと，該地域サーバを管理する本部サーバから構成され、前記ファイルの配信を司るサーバは該地域サーバである請求項１ないし請求項４のいずれか記載のコンテンツ配信システム。
【請求項６】
前記サーバの管理部は、ファイルの配信状況の一部として、各クライアントの回線容量と各クライアントが現にファイルの配信を行なっているクライアントの数を管理している請求項１ないし請求項５のいずれか記載のコンテンツ配信システム。
【請求項７】
前記サーバの管理部は、前記サーバのファイルの配信状況も管理している請求項１ないし請求項６のいずれか記載のコンテンツ配信システム。
【請求項８】
前記指定部は、回線に余裕があるサーバまたはクライアントを指定する請求項１ないし請求項７のいずれか記載のコンテンツ配信システム。
【請求項９】
所定のコンテンツに対応したファイルの配信を司るサーバであって、
配信が可能となったファイルの存在を前記各クライアントに通知する通知部と、
前記各クライアントに対する前記ファイルの配信状況を管理する管理部と、
前記クライアントからの要求に従い、前記ファイルの配信状況を参照し、前記クライアントがダウンロードするファイルを保有しているサーバまたはクライアントを指定する指定部と
を備えたサーバ。
【請求項１０】
所定のコンテンツに対応したファイルの配信を司るサーバの指定により、該ファイルをネットワークを介してダウンロードするクライアントであって、
サーバから、配信が可能となったファイルの存在を通知されたとき、これを受け付ける受付部と、
前記受け付けた通知により特定されたファイルのダウンロードを、前記サーバに要求する要求部と、
該要求に応えて、前記サーバが、前記ネットワークを介して接続された他のサーバまたはクライアントへの前記ファイルの配信状況に基づいて、当該ファイルがダウンロード可能なサーバまたはクライアントを指定したとき、該指定を取得する指定受付部と、
該取得した指定に従い、該指定されたサーバまたはクライアントにダウンロードの要求を出力するダウンロード要求部と、
前記ダウンロードの要求を出力した相手のサーバまたはクライアントとの間でダウンロードを実行するダウンロード実行部と
を備えたクライアント。
【請求項１１】
所定のコンテンツに対応したファイルの配信を司るサーバの指定により、該ファイルをネットワークを介して配信するクライアントであって、
前記サーバから、ファイルのダウンロードを要求した前記クライアントへの配信命令を取得する配信受付部と、
前記配信受付部で取得した配信命令に従い、ファイルのダウンロードを要求した前記クライアントへ、前記ファイルの配信を行なう配信部と
を備えたクライアント。
【請求項１２】
所定のコンテンツに対応したファイルの配信を司るサーバと、該ファイルをネットワークを介して交換するクライアントおよび／またはサーバにより構成されるコンテンツ配信方法であって、
前記サーバは、
配信が可能となったファイルの存在を前記各クライアントに通知し、
前記各クライアントに対する前記ファイルの配信状況を管理し、
前記クライアントからの要求に従い、前記ファイルの配信状況を参照し、前記クライアントがダウンロードするファイルを保有しているサーバまたはクライアントを指定し、
前記クライアントは、
前記サーバからの前記通知を受け付け、
前記受け付けた通知により特定されたファイルのダウンロードを、前記サーバに要求し、
前記サーバが指定した前記サーバまたはクライアントから、前記ファイルのダウンロードを要求したクライアントへの、該ファイルの転送を実現する
コンテンツ配信方法。
【請求項１３】
所定のコンテンツに対応したファイルの配信を司るサーバと、該ファイルをネットワークを介して交換するクライアントおよび／またはサーバにより構成されるコンテンツ配信システムであって、
前記クライアントは、ネットワークに接続するためのネットワーク情報を、前記サーバに通知する情報通知部を備え、
前記サーバは、前記クライアントからの前記通知を受け付ける情報通知受付部を備えた請求項１ないし請求項８のいずれか記載のコンテンツ配信システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンテンツに対応したファイルの配信を司るサーバと、該ファイルをネットワークを介して交換するクライアントおよび／またはサーバにより構成されるコンテンツ配信システムに関する。
【０００２】
【従来の技術】
従来から、サーバがクライアントにコンテンツを配信するというシステムは利用されている。該システムにおいては、ファイルが必要になると全クライアントが、ファイルを配信するサーバに接続する。サーバは接続してきたクライアントの要求に応じて、クライアントにファイルを送信する。このようなシステムでは、多数のクライアントからのファイル送信の要求に応えるために、サーバの回線容量を同時に接続する可能性のあるクライアント数を見積もって設定する設計となっている。
【０００３】
【発明が解決しようとする課題】
しかしながら、近年動画や音楽など、大きなファイルの転送の要求が高まっており、従来のサーバ・クライアントシステムでのファイル転送では、サーバ側の回線容量が不足するという問題が生じていた。動画などの大容量のコンテンツを配信したいという要求が高まっているにもかかわらず、サーバ回線の容量は経費上の制約から急激に増加することが困難だからである。
【０００４】
つまり、ＡＤＳＬやＦＴＴＨなどにより、従来は５６Ｋｂｐｓや６４Ｋｂｐｓであったクライアントの回線速度が、１Ｍｂｐｓや８Ｍｂｐｓまで高速化しているが、その高速した回線を生かしきれていないのである。例えば、サーバ回線速度が１０Ｍｂｐｓで、クライアント回線速度が１Ｍｂｐｓとする。１つのサーバに対して、１００クライアントがファイルのダウンロードに来ると、各クライアントの回線速度はわずか１００Ｋｂｐｓ（＝１０Ｍｂｐｓ／１００クライアント）となってしまう。また、多数のクライアントが同時にダウンロードに来ると、サーバの回線は麻痺してしまう。例えば、多数のクライアントからの要求が輻輳すると、各クライアントに対してパケットを送信するまでの時間がかかるようになり、タイムアウトエラーを起こしやすい。
【０００５】
本発明は、上記した問題点を解決するためになされたものであり、クライアントの回線が高速化していることを利用し、効率よく大容量のコンテンツを配信するコンテンツ配信システムを提供することを目的とする。
【０００６】
【課題を解決するための手段およびその作用・効果】
上記課題の少なくとも一部を解決する本発明のコンテンツ配信システムは、
所定のコンテンツに対応したファイルの配信を司るサーバと、該ファイルをネットワークを介して交換するクライアントおよび／またはサーバにより構成されるコンテンツ配信システムであって、
前記サーバは、
配信が可能となったファイルの存在を前記各クライアントに通知する通知部と、
前記各クライアントに対する前記ファイルの配信状況を管理する管理部と、
前記クライアントからの要求に従い、前記ファイルの配信状況を参照し、前記クライアントがダウンロードするファイルを保有しているサーバまたはクライアントを指定する指定部と
を備え、
前記クライアントは、
前記サーバからの前記通知を受け付ける通知受付部と、
前記受け付けた通知により特定されたファイルのダウンロードを、前記サーバに要求する要求部とを備え、
前記サーバの指定部が指定した前記サーバまたはクライアントから、前記ファイルのダウンロードを要求したクライアントへの、該ファイルの転送を実現するファイル転送手段
を備えることを要旨としている。
【０００７】
また、このシステムに対応した方法の発明は、
所定のコンテンツに対応したファイルの配信を司るサーバと、該ファイルをネットワークを介して交換するクライアントおよび／またはサーバにより構成されるコンテンツ配信方法であって、
前記サーバは、
配信が可能となったファイルの存在を前記各クライアントに通知し、
前記各クライアントに対する前記ファイルの配信状況を管理し、
前記クライアントからの要求に従い、前記ファイルの配信状況を参照し、前記クライアントがダウンロードするファイルを保有しているサーバまたはクライアントを指定し、
前記クライアントは、
前記サーバからの前記通知を受け付け、
前記受け付けた通知により特定されたファイルのダウンロードを、前記サーバに要求し、
前記サーバが指定した前記サーバまたはクライアントから、前記ファイルのダウンロードを要求したクライアントへの、該ファイルの転送を実現すること
を要旨としている。
【０００８】
かかるシステムおよび方法によれば、コンテンツを多数のクライアントに配信する際にも、サーバはクライアントへのコンテンツの配信状況に基づき、コンテンツをクライアントから該コンテンツ間で交換するように、クライアントに指示することができる。従って、クライアントからクライアントへファイルの配信ができるようになる。この結果、クライアント数が増加しても、ダウンロードが単一のサーバに集中しにくくなり、パフォーマンスの低下を防ぐことができる。
【０００９】
コンテンツを配信済みのクライアントから、該コンテンツをダウンロードするようにクライアントに指示すれば、クライアントからクライアントへのファイルの配信を行なうことができる。一方、コンテンツを配信済みのクライアントに、未配信のクライアントに該コンテンツを配信するように指示することでも、クライアントからクライアントへのファイルの配信を行なうことができる。
【００１０】
一方、サーバを所定の地域ごとに設置することにより、更にサーバの負荷を分散することも可能である。地域ごとに設置されたサーバは、本部のサーバが管理する構成とすれば、本部のサーバで全端末を統括的に管理することができる。
【００１１】
また、サーバで各端末の情報を一元的に管理することにより、どの回線がすいているのかを認識することができる。クライアントがファイルをダウンロードする回線として、すいている回線を指定するようにすると、速く多数のクライアントにファイルを配信することができる。
【００１２】
更に、クライアントがネットワークに接続するためのネットワーク情報をサーバに通知するようにすれば、動的に変わるネットワーク情報もサーバで管理することができ、ネットワーク情報が変化する場合もファイルの配信を行なうことができる。
【００１３】
【発明の実施の形態】
＜第一実施例＞（１）構成
以下、本発明の第一実施例について、図を参照しつつ説明する。図１にはクライアント−サーバシステムを応用したコンテンツ配信システム２０が示されている。コンテンツ配信システム２０は、本社のサーバ（以下、本社サーバ２５とよぶ）から各地に点在するコンビニエンスストアへコンテンツを一斉に配信する処理を行なうシステムである。コンテンツに対応したファイルは、まず本社サーバ２５から地方のサーバ（以下、地方サーバ３５とよぶ）へ配信命令とともに配信される。ここでは、該ファイルの配信を司る地方サーバ３５と、該ファイルをダウンロードするクライアント３０から構成される地方配信部４０の処理について詳しく説明する。
【００１４】
まず地方サーバ３５の内部構成を、図２に基づいて説明する。サーバやクライアント３０は、モデムやルータ６０を介してネットワーク５０とのデータのやり取りを制御するネットワークインターフェース（ＮＴ−Ｉ／Ｆ）７０，処理を行なうＣＰＵ８０，処理プログラムや固定的なデータを記憶するＲＯＭ９０，ワークエリアとしてのＲＡＭ１００，時間を管理するタイマ１１０，モニタ１６５への表示を司る表示回路１３０，テキストデータをデータベースとして蓄積しているハードディスク（ＨＤ）１２０，キーボード１５０やマウス１６０とのインターフェースを司る入力インターフェース（Ｉ／Ｆ）１４０等を備える。なお、ハードディスク１２０は固定式のものとして記載したが、着脱式のものでも良いし、着脱式の記憶装置（例えばＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷ，ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，フレキシブルディスクなど）を併用することも可能である。また、本実施例では地方サーバ３５の処理プログラムはＲＯＭ９０内に記憶されているものとしたが、ハードディスク１２０に記憶しておき、起動時にＲＡＭ１００上に展開して実行するものとしても良い。あるいは、上述した着脱式の記録媒体から読み込むものとしても良い。更には、ネットワーク５０を介して他のサーバから読み込んで実行するものとしても良い。同様に、ハードディスク１２０に必要なデータのすべてが記憶されている必要はなく、ネットワーク５０により接続される他のサーバに膨大なデータを分散して記憶，更新，管理する構成としても良い。なお、本社サーバ２５，クライアント３０も、内部構成は地方サーバ３５とほぼ同様である。
【００１５】
本システムでは、地方サーバ３５と共に、クライアント３０側にもファイルダウンロード用のアプリケーションプログラムがインストールされている。アプリケーションプログラムには、制御モジュール，ファイル送信モジュール，ファイル受信モジュールが含まれている。制御モジュールは、各種モジュールの処理を制御する。ファイル送信モジュールとファイル受信モジュールは、対になって働き、ファイルをクライアント３０間で送受信する。
【００１６】
図３は、本システムで地方サーバ３５からクライアント３０にファイルを配信する手順を表したフローチャートである。地方サーバ３５は、まず自身が配信を担当しているクライアント３０の情報を収集する（ステップＳ２０）。地方サーバ３５は、自身が配信を担当しているクライアント３０の情報を登録しておくために、担当データベース１８０を保有している。担当データベース１８０の一例を図４に示す。担当データベース１８０には、各クライアント３０の「クライアントＩＤ」と「ＩＰアドレス」と「回線容量」を登録する。「クライアントＩＤ」はクライアントを一意に識別するためのものである。「クライアントＩＤ」と「ＩＰアドレス」は、本社サーバ２５から配信をうけもつクライアント３０の指定を受けた時点で追加する。該ＩＰアドレスに相当するクライアント３０の回線容量は、本社サーバ２５から通知を受けて登録してもよいし、テストして登録してもよい。テストする場合には、地方サーバ３５から該クライアント３０へテストファイルを送信する。その送信結果からクライアント３０の回線容量を割り出し、担当データベース１８０へ登録する（ステップＳ２０）。
【００１７】
次に、地方サーバ３５は、この時点で配信すべきコンテンツやクライアント３０が存在するかどうかを調べる（ステップＳ２２）。この判断は、コンテンツデータベース２００を検索することにより行なうが、このコンテンツデータベース２００を用意しておくために、地方サーバ３５では以下の処理が動いている。その処理を図５により説明する。配信すべきコンテンツがある際、当システムの管理人は、本社サーバ２５から全地方サーバ３５へ、配信すべきコンテンツのファイルと配信対象クライアントデータベース１７０を、コンテンツ配信命令として送信する（ステップＳ６０）。配信対象クライアントデータベース１７０には、該コンテンツを配信する対象となるクライアント３０のＩＰアドレスが全て登録されている。
【００１８】
地方サーバ３５は、配信すべきコンテンツのファイルと配信対象クライアントデータベース１７０を受信すると、配信対象クライアントデータベース１７０と担当データベース１８０の両方に存在するクライアント３０を割り出す（ステップＳ６５）。もし、両方に存在するクライアント３０がなければ（ステップＳ７０）、その地方サーバ３５が該コンテンツを配信しなければならないクライアント３０が存在しないと判断し、そのまま処理を終える。両方に存在するクライアント３０があれば（ステップＳ７０）、該クライアント３０を配信データベース１９０に登録する（ステップＳ７５）。つまり、配信データベース１９０には、その地方サーバ３５がそのコンテンツを配信しなければならないクライアント３０を登録する。配信データベース１９０はコンテンツ毎に作成される。配信データベース１９０の一例を、図６に示す。
【００１９】
配信データベース１９０作成後、地方サーバ３５はコンテンツデータベース２００に、配信対象となったコンテンツのコンテンツ名とファイルサイズを登録する（ステップＳ８０）。そして、該レコードの「配信」フィールドの値を初期値として「ＮＯ」とする（ステップＳ８０）。「配信」フィールドは、その地方サーバ３５が該コンテンツを配信しなければならない全クライアント３０へコンテンツを配信済みならば「ＹＥＳ」、未配信ならば「ＮＯ」という値をとるからである。該フィールドは、配信対象であるすべてのクライアント３０への配信が終わった時点で「ＹＥＳ」に書きかえられる。コンテンツデータベース２００の一例を図７に示す。
【００２０】
以上の処理によりコンテンツデータベース２００が作成されているので、配信すべきコンテンツが存在するかどうかの判断は、コンテンツデータベース２００の「配信」フィールドが「ＮＯ」のレコードを検索することで可能となる。再度図３に戻って説明を続ける。該レコードが存在すれば（ステップＳ２２）、ステップ２３以下の処理に移行する。存在しなければ、検索を繰り返す（ステップＳ２２）。
【００２１】
該レコードが存在したとき、地方サーバ３５は管理データベース２１０を作成する（ステップＳ２３）。管理データベース２１０の一例は、図８に示す。第一実施例では、ステップＳ２２の検索でコンテンツデータベース２００の「配信」フィールドが「ＮＯ」となっていたコンテンツが１つであるものとし、配信対象のコンテンツが１つである場合を説明する。よって、管理データベース２１０で各クライアント３０に対して配信するコンテンツは１つになっている。管理データベース２１０の「ＩＰアドレス」は、配信対象である各クライアント３０のＩＰアドレスである。「ファイルサイズ」は、コンテンツのファイルサイズである。「配信状況」は、コンテンツの配信状況であり、初期値は未配信であるから「ＮＯ」である。既配信となれば「ＹＥＳ」となる。「開始時刻」は、クライアント３０がコンテンツのダウンロードを開始した時刻である。「終了時刻」は、クライアント３０がコンテンツのダウンロードを終了した時刻である。「回線容量」は、クライアント３０の回線容量である。「接続クライアント数」は、該クライアント３０に接続しているクライアント３０の数である。
【００２２】
「ＩＰアドレス」フィールドは配信データベース１９０を参照してうめられる。「コンテンツ名」フィールドと「ファイルサイズ」フィールドはコンテンツデータベース２００を参照してうめられる。「回線容量」フィールドは担当データベース１８０を参照してうめられる。また、「開始時刻」「終了時刻」の初期値はＮｕｌｌである。「接続クライアント数」の初期値は０である。
【００２３】
ところで、管理データベース２１０には、地方サーバ３５自身のデータも含めておく。クライアント３０と同様、地方サーバ３５もクライアント３０からのダウンロード先となるので一元的に管理しておいた方が処理が簡単になるためである。地方サーバ３５のレコードには、コンテンツデータベース２００の検索結果で未配信となったコンテンツの情報をすべて登録する。そして、配信状況を「ＹＥＳ」とする。地方サーバ３５は、該コンテンツを保有しているからである。開始時刻と終了時刻はＮｕｌｌのままにしておく。「接続クライアント数」の初期値は「０」である。
【００２４】
地方サーバ３５は、管理データベース２１０内の全クライアント３０に対して、配信開始の案内と配信対象のコンテンツのコンテンツ名を送信する（ステップＳ２４）。クライアント３０は、自身が保有しているコンテンツ名の一覧である所有データベース２１５を記憶している。配信開始の案内と配信対象のコンテンツのコンテンツ名を受信したクライアント３０は（ステップＳ１９２）、所有データベース２１５を検索する（ステップＳ１９４）。そして、所有データベース２１５に受信したコンテンツ名がない場合（ステップＳ１９５）、つまり該コンテンツを保有していないとき、該情報を送信した地方サーバ３５に対してファイルの配信要求を出す（ステップＳ１９７）。配信要求には、該クライアント３０のＩＰアドレスと配信対象のコンテンツのコンテンツ名が含まれている。
【００２５】
配信要求を受けた地方サーバ３５は（ステップＳ２５）、各クライアント３０がどこからファイルをダウンロードすればよいのかを指定する（ステップＳ３０）。あるいは地方サーバ３５自ら、配信要求をしてきたクライアント３０にファイルを配信する（ステップＳ３０）。ここでは、地方サーバ３５は管理データベース２１０の情報を元に、すいている回線を判断してダウンロード先を指定している。ステップＳ３０の処理について、図９のフローチャートにより詳しく説明する。
【００２６】
コンテンツの配信要求を受けた地方サーバ３５は、ファイルをすでに配信してある端末を管理データベース２１０から検索する（ステップＳ１００）。検索は、図８に示した管理データベース２１０の「配信状況」フィールドが「ＹＥＳ」になっているレコードを検索することで行なう。管理データベース２１０にはサーバ自身も登録されているので、常に１件以上は該当するレコードが存在する。次に、該当した端末のうち、どの端末で配信を行なうと効率が良いのかを判別する（ステップＳ１４０）。判別は該レコードの「ファイルサイズ」と「回線容量」と「接続クライアント数」を用いて行なう。
【００２７】
各レコードにおける「ファイルサイズ」と「接続クライアント数＋１」をかけて求まる数は、該端末からクライアント３０がダウンロードを行なったとすると、該端末の回線で送信中となるデータのサイズである。これを「回線容量」で割ると、全データのダウンロードにかかる時間が求まる。厳密に言えば、ファイルの配信を開始した時刻も異なるし、その他様々な要因が存在するため、正確なダウンロード時間とは言えない。しかし、比較値として用いるには概ね適正である。
【００２８】
ステップＳ１００での検索で該当した端末全てに対して、該比較値であるダウンロードにかかる時間を求める。そして、その時間が最も小さい端末をダウンロード先として決定する。そのように決定されたダウンロード先からファイルをダウンロードするのが最も速い可能性が高い。
【００２９】
ステップＳ１４０で特定した端末が地方サーバ３５の場合（ステップＳ１５０）、サーバは直ちに配信要求をしてきたクライアント３０にファイルの送信を行なう（ステップＳ１６０）。その際、管理データベース２１０における自身の「接続クライアント数」に１を足す（ステップＳ１６５）。そして、ファイル送信が完了したら（ステップＳ１６７）、自身の「接続クライアント数」から１を引く（ステップＳ１７０）。また、管理データベース２１０における該クライアント３０のコンテンツの「配信状況」を「ＹＥＳ」にし、ダウンロードの開始時刻と終了時刻を記載する（図３のステップＳ５０）。
【００３０】
一方、ステップＳ１４０で特定した端末が地方サーバ３５ではない場合（ステップＳ１５０）、地方サーバ３５はまずダウンロード先となるクライアント３０にファイルの要求通知を行なう（ステップＳ１８０）。ファイルを提供するクライアント３０に対して、ファイルのダウンロード要求があることを通知するためである。そして、管理データベース２１０の該クライアント３０に相当するレコードの「接続クライアント数」に１を足す（ステップＳ１８５）。新たに接続するクライアント３０があるためである。次に、ファイルを取得する、つまり配信要求をしてきたクライアント３０に、ファイルを提供するクライアント３０のＩＰアドレスと配信対象のコンテンツのコンテンツ名を通知する（ステップＳ１９０）。なお、その際待ち受けしているポート番号もあわせて通知する構成としてもよい。その場合の待ち受けしているポート番号は、該クライアント３０が最初にサーバにログインするときにサーバに送信したものである。
【００３１】
該通知を受けたクライアント３０の処理を図３により説明する。ファイルを取得するクライアント３０は、ファイルを提供するクライアント３０に対し、ダウンロード用接続を行なう（ステップＳ２００）。つまり、通知されたＩＰアドレスとポート番号に対して、ＴＣＰ接続を試みる。次に、ファイルを取得するクライアント３０は、ファイルを提供するクライアント３０にファイルを要求する（ステップＳ２１０）。要求をうけて、ファイルを提供するクライアント３０からファイルを取得するクライアント３０へファイルが送信されるので、該ファイルを受信する（ステップＳ２１５）。ステップＳ２１５の処理が終了したら、クライアント３０は地方サーバ３５へ、ダウンロードの結果を通知する（ステップＳ２２０）。通知する内容は、ダウンロードの成否とダウンロードの開始時刻と終了時刻である。また、ダウンロードに成功した場合は（ステップＳ２２５）、所有データベースにダウンロードに成功したコンテンツのコンテンツ名を書きこむ（ステップＳ２３０）。
【００３２】
ダウンロードの結果をクライアント３０から受けた地方サーバ３５は（ステップＳ３５）、まず、管理データベース２１０のレコードのうち、ダウンロード先となっていたクライアント３０に相当するレコードの「接続クライアント数」から１をひいておく（ステップＳ４０）。クライアント３０がダウンロードに失敗した場合は（ステップＳ４５）、成功するまでダウンロード処理を繰り返させるため、地方サーバ３５はステップＳ１００からステップＳ１９０の処理を適宜行なう。そして、ステップＳ１９０の通知を受けたクライアント３０は、再びダウンロード処理を開始する（ステップＳ２００〜ステップＳ２２０）。
【００３３】
クライアント３０がダウンロードに成功した場合は（ステップＳ４５）、管理データベース２１０の内容を書き換える（ステップＳ５０）。管理データベース２１０における該クライアント３０のコンテンツの「配信状況」を「ＹＥＳ」にし、ダウンロードの開始時刻と終了時刻を記載する（ステップＳ５０）。
【００３４】
以上説明した第一実施例によれば、指定のクライアント３０にコンテンツを配信することができるのは勿論であるが、クライアント数が増加するほどファイルのダウンロード先も増加するため、クライアント数の増加による急激なパフォーマンスの低下を防ぐことができる。コンテンツの配信の際に、高速化されたクライアント３０の回線を利用することができることも利点である。また、ファイルのダウンロード先が分散されるため、サーバ回線に負荷が集中することなく、サーバ回線の麻痺が起こりにくくなる。更に、ファイルのダウンロード先が複数となるため、ネットワーク５０の一部で問題が起きても大きな問題とはならない。つまり、クライアント３０がダウンロードに失敗した場合でも、他の端末からダウンロードするように指示することで、確実にクライアント３０にファイルをダウンロードさせることができる。たとえサーバの回線に異常が生じたときでも、クライアント３０からクライアント３０へダウンロードしている最中の配信は妨げられないという利点もある。更に、クライアント３０からコンテンツの配信要求がきたときに、すいている可能性が高い回線を有する端末をダウンロード先として指定することにより、より速くファイルを配信することができる。
【００３５】
＜第二実施例＞
第二実施例では、複数のコンテンツを配信する処理について説明する。つまり、コンテンツデータベース２００の「配信」が「ＮＯ」になっているコンテンツが複数存在するものとする。よって、各クライアント３０に対して配信するコンテンツは複数であるから、この実施例では、管理データベース２１０の一例は図１０に示したものを利用する。図１０については、「コンテンツ名」「ファイルサイズ」「配信状況」「開始時刻」「終了時刻」「接続クライアント数」が各コンテンツに対応づけて記憶されている。「接続クライアント数」は、該コンテンツをダウンロードするために、該端末に接続しているクライアント３０の数である。
【００３６】
第一実施例同様、コンテンツの配信要求を受けた地方サーバ３５は、ファイルをすでに配信してある端末を管理データベース２１０から検索する。検索は、管理データベース２１０のうち、要求されたコンテンツの「配信状況」フィールドが「ＹＥＳ」になっているレコードを検索することで行なう。管理データベース２１０にはサーバ自身も登録されているので、常に１件以上は該当するレコードが存在する。次に、該当したレコードに相当する端末のうち、どの端末で配信を行なうと効率が良いのかを判別する。判別は該端末に対して記載されている各コンテンツの「ファイルサイズ」と「回線容量」と「接続クライアント数」を用いて行なう。複数のコンテンツが同時に配信されている場合に、端末の回線使用状態を判別するためには、すべてのコンテンツの送信状態から判別しなければならないからである。
【００３７】
まず、配信対象のコンテンツ以外の各コンテンツの「ファイルサイズ」と「接続クライアント数」をかける。そして、それぞれを加える。それにより、配信対象のコンテンツ以外で現在ダウンロード中のデータのサイズが求まる。次に、配信対象のコンテンツの「ファイルサイズ」と「接続クライアント数＋１」をかける。そして、それを配信対象のコンテンツ以外で現在ダウンロード中のデータのサイズに加える。それが、該端末からクライアント３０がダウンロードを行なったとすると、該端末の回線で送信中となるデータのサイズである。これを「回線容量」で割ると、全データのダウンロードにかかる時間が求まる。厳密に言えば、ファイルの配信を開始した時刻も異なるし、その他様々な要因が存在するため、正確なダウンロード時間を必ずしも反映しないが、比較値として用いるには概ね適正である。なお、開始時間や途中経過の状態の通知を受けて、より厳密に求めるものとしてもよい。
【００３８】
配信対象のコンテンツを保有する端末全てに対して、該比較値であるダウンロードにかかる時間を求める。そして、その時間が最も小さい端末をダウンロード先として決定する。そのように決定されたダウンロード先からファイルをダウンロードするのが最も速い可能性が高い。
【００３９】
以上説明した第二実施例によれば、第一実施例と同様な作用効果を奏する上、更に、複数のコンテンツを同時に速く配信することが可能となる。この場合も、コンテンツ毎に配信しなければならないクライアント３０を区別して配信することができる。
【００４０】
以上、本発明の実施の形態について説明したが、本発明はこうした実施の形態に何ら限定されるものではなく、本発明の要旨を逸脱しない範囲内において、更に様々な形態で実施しうることは勿論である。例えば、回線を提供する、つまりファイルのダウンロード先となるクライアント３０は登録制として、登録したクライアント３０には、ダウンロード先となったことでいくらかの対価、例えば有料コンテンツをダウンロードする権利や、ネットワーク上の金銭を支払うという設定にすることも可能である。
【図面の簡単な説明】
【図１】コンテンツ配信システム２０の全体を示す説明図である。
【図２】地方サーバ３５の内部構成を示す説明図である。
【図３】コンテンツの配信処理を示すフローチャートである。
【図４】担当データベース１８０の一例を示す説明図である。
【図５】配信データベース１９０とコンテンツデータベース２００の作成処理を示すフローチャートである。
【図６】配信データベース１９０の一例を示す説明図である。
【図７】コンテンツデータベース２００の一例を示す説明図である。
【図８】配信対象のコンテンツが１件である場合の管理データベース２１０の一例を示す説明図である。
【図９】コンテンツのダウンロード先を指定するための処理、またはコンテンツの配信処理を示すフローチャートである。
【図１０】配信対象のコンテンツが複数である場合の管理データベース２１０の一例を示す説明図である。
【符号の説明】
２０…コンテンツ配信システム
２５…本社サーバ
３０…クライアント
３５…地方サーバ
４０…地方配信部
５０…ネットワーク
６０…ルータ
８０…ＣＰＵ
９０…ＲＯＭ
１００…ＲＡＭ
１１０…タイマ
１２０…ハードディスク
１３０…表示回路
１５０…キーボード
１６０…マウス
１６５…モニタ
１７０…配信対象クライアントデータベース
１８０…担当データベース
１９０…配信データベース
２００…コンテンツデータベース
２１０…管理データベース
２１５…所有データベース
【図１】
2004118417.tif 000003
【図２】
2004118417.tif 000004
【図３】
2004118417.tif 000005
【図４】
2004118417.tif 000006
【図５】
2004118417.tif 000007
【図６】
2004118417.tif 000008
【図７】
2004118417.tif 000009
【図８】
2004118417.tif 000010
【図９】
2004118417.tif 000011
【図１０】
2004118417.tif 000012