(57)【要約】【課題】Ｐ２Ｐ方式でのデータファイル配信が可能とされたシステムにおいて、データファイル配信を期限通りに確実に行うことができるようにする。【解決手段】データファイル配信システムＳは、データファイル配信元であるサーバ装置１と、複数のクライアント（シーダ用クライアント２１Ａ〜２１Ｃ、クライアント２２Ａ〜２２Ｃ）とを含む。これらサーバ装置１と複数のクライアントとは相互にインターネット回線でネットワーク接続され、Ｐ２Ｐ方式でデータファイルの配信が行われる。サーバ装置１は、各クライアントに対するデータファイルの配信状況を管理し、配信が遅延すると予想されるクライアントが特定されたとき、直接そのクライアントへ未配信のデータファイルを配信する。【選択図】図１
2008304980.tif 000002
【特許請求の範囲】
【請求項１】
データファイル配信元であるサーバ装置と複数のクライアントとを含み、前記サーバ装置及び複数のクライアントが相互にネットワーク接続され、ピアツーピア方式でデータファイル配信を行うことが可能とされたデータファイル配信システムであって、
前記サーバ装置は、各クライアントに対するデータファイルの配信状況に関する情報を取得し、前記配信状況に基づいて各クライアントへの配信完了時を予測する配信管理手段を備えることを特徴とするデータファイル配信システム。
【請求項２】
前記配信管理手段は、前記複数のクライアントのうち任意のクライアントを、サーバ機能を果たすシーダとして扱い、該シーダから他のクライアントにデータファイルの配信を行わせることを特徴とする請求項１に記載のデータファイル配信システム。
【請求項３】
前記サーバ装置が、
前記データファイルを保有し、前記複数のクライアントのうちの所定の条件で決定されるクライアントに対して前記データファイルを配信可能な第１のサーバと、
前記データファイルを保有し、特定のクライアントに対して前記データファイルをファイル単位で直接配信可能な第２のサーバと、を備え、
前記配信管理手段は、データファイルの配信が所定の時刻よりも遅れると予測されるクライアントを特定したときに、前記第２のサーバから前記特定されたクライアントに対して前記データファイルを直接配信させることを特徴とする請求項１又は２に記載のデータファイル配信システム。
【請求項４】
前記サーバ装置が、
前記データファイルを保有し、前記複数のクライアントのうちの所定の条件で決定されるクライアントに対して前記データファイルを配信可能な第１のサーバと、
前記データファイルを保有し、特定のクライアントに対して一つの前記データファイルを、細分化された小ファイル単位で直接配信可能な第３のサーバと、を備え、
前記配信管理手段は、データファイルの配信が所定の時刻よりも遅れると予測されるクライアントを特定したときに、前記第３のサーバから前記特定されたクライアントに対して前記データファイルを直接配信させることを特徴とする請求項１又は２に記載のデータファイル配信システム。
【請求項５】
前記特定されたクライアントに対する配信が、一つの前記データファイルを構成する全ての小ファイルのうち、一部の小ファイルについて完了している場合において、
前記第３のサーバから前記特定されたクライアントに対して、配信が完了していない残りの小ファイルが配信されることを特徴とする請求項４に記載のデータファイル配信システム。
【請求項６】
前記サーバ装置が、
前記データファイルを保有し、前記複数のクライアントのうちの所定の条件で決定されるクライアントに対して前記データファイルを配信可能な第１のサーバと、
前記データファイルを保有し、特定のクライアントに対して前記データファイルをファイル単位で直接配信可能な第２のサーバと、
前記データファイルを保有し、特定のクライアントに対して一つの前記データファイルを、細分化された小ファイル単位で直接配信可能な第３のサーバと、を備え、
前記配信管理手段は、データファイルの配信が所定の時刻よりも遅れると予測されるクライアントを特定したときに、当該クライアントに対するデータファイルの配信完了度を確認し、
前記配信完了度が、所定の閾値を下回る第１の値であるとき、前記配信管理手段は、前記第２のサーバから前記特定されたクライアントに対して前記データファイルをファイル単位で直接配信させ、
前記配信完了度が、所定の閾値を上回る第２の値であるとき、前記配信管理手段は、前記第３のサーバから前記特定されたクライアントに対して前記データファイルを小ファイル単位で直接配信させることを特徴とする請求項１又は２に記載のデータファイル配信システム。
【請求項７】
配信されるデータファイルが、第１データファイルと、該第１ファイルに続いて配信される第２データファイルとを含む場合において、
前記第１データファイルの配信完了度が、前記第１の値であるとき、前記配信管理手段は、前記第２のサーバから前記特定されたクライアントに対して前記第１及び第２データファイルをファイル単位で直接配信させ、
前記第１データファイルの配信完了度が、前記第２の値であるとき、前記配信管理手段は、前記第３のサーバから前記特定されたクライアントに対して前記第１データファイルを小ファイル単位で直接配信させた後に、前記第２のサーバから前記第２データファイルをファイル単位で直接配信させることを特徴とする請求項６に記載のデータファイル配信システム。
【請求項８】
前記配信管理手段は、前記ネットワークから前記サーバ装置を離脱させ、前記離脱後に前記ネットワークへ復帰させる機能を備え、
前記配信管理手段は、クライアント間におけるデータ配信環境の形成状況に応じて、前記サーバ装置の前記ネットワークからの離脱若しくは前記ネットワークへの復帰を制御することを特徴とする請求項１〜７のいずれかに記載のデータファイル配信システム。
【請求項９】
前記配信管理手段は、前記複数のクライアントのうち任意のクライアントを、サーバ機能を果たすシーダとして扱い、該シーダから他のクライアントにデータファイルの配信を行わせるものであって、
前記シーダの数が所定数よりも多い状態となったときに前記サーバ装置を前記ネットワークから離脱させ、その後、前記シーダの数が所定数よりも少ない状態となったときに前記サーバ装置を前記ネットワークへ復帰させることを特徴とする請求項８に記載のデータファイル配信システム。
【請求項１０】
前記サーバ装置が、前記データファイルを保有する単一のサーバからなり、該単一のサーバが、前記複数のクライアントのうちの所定の条件で決定されるクライアントに対して前記データファイルを配信する第１機能部と、
特定のクライアントに対して前記データファイルをファイル単位で直接配信する第２機能部及び／又は特定のクライアントに対して一つの前記データファイルを、細分化された小ファイル単位で直接配信する第３機能部と、を備え、
前記配信管理手段は、前記離脱時に、前記第１機能部を前記ネットワークから切り離す一方で、前記第２機能部及び／又は第３機能部が前記ネットワークに接続された状態を維持することを特徴とする請求項８に記載のデータファイル配信システム。
【請求項１１】
各クライアントに対するデータファイルの配信実績情報が格納される履歴情報データベースをさらに備えることを特徴とする請求項１〜１０のいずれかに記載のデータファイル配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば画像、映像、音声コンテンツのような各種のデータファイルを、ネットワークを通して配信するためのデータファイル配信システムに関する。
【背景技術】
【０００２】
複数のコンピュータ装置をネットワーク接続するネットワークシステムの形態として、クライアントサーバ（Ｃ／Ｓ）システムと、ピアツーピア（Peer to Peer＝Ｐ２Ｐ）システムとが知られている。Ｃ／Ｓシステムは、サーバとクライアントとの主従関係が固定化されたシステムであり、例えばサーバがデータファイル配信するサービスを行い、クライアントがこれを利用するシステムである。
【０００３】
これに対し、Ｐ２Ｐシステムは、ネットワークに接続されたピア（例えばパーソナルコンピュータ等）の各々が、あるときは他のピアに対して所定のサービスを提供してサーバのように動作し、あるときは他のピアが提供するサービスを利用してクライアントのように動作するシステムであり、各ピアが対等なシステムである。かかるシステムによれば、パーソナルコンピュータ間でデータファイルや演算能力等の情報資源の共有化を図ることができる利点がある。このようなＰ２Ｐシステムに関して、従来様々な技術が提案されており、例えば特許文献１には、サーバからデータファイルを細分化して配信し、ピア間で細分化ファイルの転送を行えるようにしたシステムが提案されている。
【特許文献１】特開２００４−２１３５０８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、Ｐ２Ｐシステムにてデータファイルを一つのピア（ファイルサーバ）を発信元として各ピアに配信させようとする場合、一部のピアに対してファイル配信の遅延が生じることがあった。これは、Ｐ２Ｐシステムを用いた配信では、ピアの負荷や配信環境等に応じて成り行き任せでシステムを動作させる方が配信の効率が良く、配信制御を行うことが難しいことに起因する。従って、ある期限までに各ピアへのデータファイルの配信を完了させねばならない要請があるような場合に、Ｐ２Ｐシステムは信頼性が低いという問題があった。
【０００５】
本発明は上記問題に鑑みてなされたものであって、Ｐ２Ｐ方式でのデータファイル配信が可能とされたシステムにおいて、データファイル配信を期限通りに確実に行うことができるようにすることを目的とする。
【課題を解決するための手段】
【０００６】
上記目的を達成する本発明の一の局面に係るデータファイル配信システムは、データファイル配信元であるサーバ装置と複数のクライアントとを含み、前記サーバ装置及び複数のクライアントが相互にネットワーク接続され、ピアツーピア方式でデータファイル配信を行うことが可能とされたデータファイル配信システムであって、前記サーバ装置は、各クライアントに対するデータファイルの配信状況に関する情報を取得し、前記配信状況に基づいて各クライアントへの配信完了時を予測する配信管理手段を備えることを特徴とする（請求項１）。
【０００７】
この構成によれば、配信管理手段により各クライアントに対するデータファイルの配信状況を管理し、各クライアントへの配信完了時を予測することができる。従って、データファイル配信の進捗管理が可能となり、配信が遅延しているクライアントを把握し、該クライアントに対して措置を講ずることが可能となる。
【０００８】
上記構成において、前記配信管理手段は、前記複数のクライアントのうち任意のクライアントを、サーバ機能を果たすシーダとして扱い、該シーダから他のクライアントにデータファイルの配信を行わせることが望ましい（請求項２）。
【０００９】
この構成によれば、クライアントを階層化してデータファイルの配信を行わせることができる。従って、サーバ装置のボトルネックの問題を解消して、効率良くデータファイル配信を行い得るシステムを構築することができる。
【００１０】
上記いずれかの構成において、前記サーバ装置が、前記データファイルを保有し、前記複数のクライアントのうちの所定の条件で決定されるクライアントに対して前記データファイルを配信可能な第１のサーバと、前記データファイルを保有し、特定のクライアントに対して前記データファイルをファイル単位で直接配信可能な第２のサーバと、を備え、前記配信管理手段は、データファイルの配信が所定の時刻よりも遅れると予測されるクライアントを特定したときに、前記第２のサーバから前記特定されたクライアントに対して前記データファイルを直接配信させる構成とすることができる（請求項３）。
【００１１】
この構成によれば、データファイルの配信が所定の時刻よりも遅れると予測されるクライアントが特定されたとき、第２のサーバからその遅延クライアントに対してデータファイルがファイル単位で直接配信される。このため、クライアント間におけるＰ２Ｐ方式によるデータファイル配信で、一部のクライアントに配信遅延が生じたとしても、その遅延を第２のサーバからの直接配信で補填することができる。従って、データファイルを期限内に確実に配信し終えることができる。
【００１２】
上記いずれかの構成において、前記サーバ装置が、前記データファイルを保有し、前記複数のクライアントのうちの所定の条件で決定されるクライアントに対して前記データファイルを配信可能な第１のサーバと、前記データファイルを保有し、特定のクライアントに対して一つの前記データファイルを、細分化された小ファイル単位で直接配信可能な第３のサーバと、を備え、前記配信管理手段は、データファイルの配信が所定の時刻よりも遅れると予測されるクライアントを特定したときに、前記第３のサーバから前記特定されたクライアントに対して前記データファイルを直接配信させる構成とすることができる（請求項４）。
【００１３】
この構成によれば、データファイルの配信が所定の時刻よりも遅れると予測されるクライアントが特定されたとき、第３のサーバからその遅延クライアントに対してデータファイルが小ファイル単位で直接配信される。このため、クライアント間におけるＰ２Ｐ方式によるデータファイル配信で、一部のクライアントに配信遅延が生じたとしても、その遅延を第３のサーバからの直接配信で補填することができる。従って、データファイルを期限内に確実に配信し終えることができる。
【００１４】
この場合、前記特定されたクライアントに対する配信が、一つの前記データファイルを構成する全ての小ファイルのうち、一部の小ファイルについて完了している場合において、前記第３のサーバから前記特定されたクライアントに対して、配信が完了していない残りの小ファイルが配信されることが望ましい（請求項５）。
【００１５】
この構成によれば、特定されたクライアントに対して、既に送信済みの一部データファイルを廃棄することなく、送信未了の残りのデータファイルだけが配信されるので、重複配信の無駄を避けることができる。
【００１６】
上記構成において、前記サーバ装置が、前記データファイルを保有し、前記複数のクライアントのうちの所定の条件で決定されるクライアントに対して前記データファイルを配信可能な第１のサーバと、前記データファイルを保有し、特定のクライアントに対して前記データファイルをファイル単位で直接配信可能な第２のサーバと、前記データファイルを保有し、特定のクライアントに対して一つの前記データファイルを、細分化された小ファイル単位で直接配信可能な第３のサーバと、を備え、前記配信管理手段は、データファイルの配信が所定の時刻よりも遅れると予測されるクライアントを特定したときに、当該クライアントに対するデータファイルの配信完了度を確認し、前記配信完了度が、所定の閾値を下回る第１の値であるとき、前記配信管理手段は、前記第２のサーバから前記特定されたクライアントに対して前記データファイルをファイル単位で直接配信させ、前記配信完了度が、所定の閾値を上回る第２の値であるとき、前記配信管理手段は、前記第３のサーバから前記特定されたクライアントに対して前記データファイルを小ファイル単位で直接配信させる構成とすることができる（請求項６）。
【００１７】
一般に、ファイル配信速度は、ファイル単位で配信する方が、小ファイル単位に区分して一つのファイルを配信するよりも早い。上記構成によれば、データファイルの配信が所定の時刻よりも遅れると予測されるクライアントが特定されたとき、そのクライアントへの配信完了度に応じて第２のサーバ又は第３のサーバが選択された上で、データファイルが配信遅延クライアントに対して直接配信される。従って、ファイルの配信効率を一層高めることができる。
【００１８】
ここで、配信されるデータファイルが、第１データファイルと、該第１ファイルに続いて配信される第２データファイルとを含む場合において、前記第１データファイルの配信完了度が、前記第１の値であるとき、前記配信管理手段は、前記第２のサーバから前記特定されたクライアントに対して前記第１及び第２データファイルをファイル単位で直接配信させ、前記第１データファイルの配信完了度が、前記第２の値であるとき、前記配信管理手段は、前記第３のサーバから前記特定されたクライアントに対して前記第１データファイルを小ファイル単位で直接配信させた後に、前記第２のサーバから前記第２データファイルをファイル単位で直接配信させることが望ましい（請求項７）。
【００１９】
この構成によれば、第１、第２データファイルが続けて配信される場合において、配信遅延クライアントに対して第１データファイルが配信途中であるとき、その配信完了度に応じて第２のサーバ又は第３のサーバからの配信が選択される。一方、続く第２データファイルの配信では、ファイル配信速度が早い第２のサーバからの配信が選択される。従って、ファイルの配信効率がより一層高められる。
【００２０】
上記いずれかの構成において、前記配信管理手段は、前記ネットワークから前記サーバ装置を離脱させ、前記離脱後に前記ネットワークへ復帰させる機能を備え、前記配信管理手段は、クライアント間におけるデータ配信環境の形成状況に応じて、前記サーバ装置の前記ネットワークからの離脱若しくは前記ネットワークへの復帰を制御することが望ましい（請求項８）。
【００２１】
この構成によれば、ネットワークからサーバ装置を離脱させることで、サーバ装置の負荷を軽減することができるので、当該サーバ装置に他の負荷を担わせることが可能となり、サーバ装置の利用性を高めることができる。
【００２２】
この場合に、前記配信管理手段は、前記複数のクライアントのうち任意のクライアントを、サーバ機能を果たすシーダとして扱い、該シーダから他のクライアントにデータファイルの配信を行わせるものであって、前記シーダの数が所定数よりも多い状態となったときに前記サーバ装置を前記ネットワークから離脱させ、その後、前記シーダの数が所定数よりも少ない状態となったときに前記サーバ装置を前記ネットワークへ復帰させることが望ましい（請求項９）。
【００２３】
この構成によれば、他のクライアントにデータファイル配信を行わせるのに十分なシーダの数が確保された段階でサーバ装置をネットワークから離脱させる一方で、過剰負荷や電源ＯＦＦなどの影響で実働シーダの数が減少したような場合に、サーバ装置をネットワークへ復帰させでデータファイル配信動作の一部を担わせるという、極めて実用的な運用を行わせることができる。
【００２４】
また、前記サーバ装置が、前記データファイルを保有する単一のサーバからなり、該単一のサーバが、前記複数のクライアントのうちの所定の条件で決定されるクライアントに対して前記データファイルを配信する第１機能部と、特定のクライアントに対して前記データファイルをファイル単位で直接配信する第２機能部及び／又は特定のクライアントに対して一つの前記データファイルを、細分化された小ファイル単位で直接配信する第３機能部と、を備え、前記配信管理手段は、前記離脱時に、前記第１機能部を前記ネットワークから切り離す一方で、前記第２機能部及び／又は第３機能部が前記ネットワークに接続された状態を維持することが望ましい（請求項１０）。
【００２５】
この構成によれば、単一のサーバで、データファイルを特定のクライアントに対して配信する第１機能、配信が遅延している特定のクライアントに対して救済配信する第２機能部及び／又は第３機能が実現される。この際、第１機能がネットワークから適時に切り離されるので、救済配信を行う際のサーバの負荷を軽減することができる。
【００２６】
上記いずれかの構成において、各クライアントに対するデータファイルの配信実績情報が格納される履歴情報データベースをさらに備えることが望ましい（請求項１１）。
【００２７】
この構成によれば、各クライアントに対するデータファイルの配信実績情報が記録されるので、かかる情報を参照することで、各クライアントへの配信完了時を適確に予測することができるようになる。
【発明の効果】
【００２８】
本発明のデータファイル配信システムによれば、データファイル配信の進捗管理が可能となり、配信が遅延しているクライアントを把握できるようになる。従って、配信遅延クライアントに対して、例えば救済用のサーバからデータファイルを直接配信する等の措置を講ずることができる。これにより、Ｐ２Ｐ方式でのデータファイル配信が可能とされたシステムにおいて、データファイル配信を期限通りに確実に行わせることができる。
【発明を実施するための最良の形態】
【００２９】
以下、図面に基づいて本発明の実施形態につき詳細に説明する。図１は、本発明の実施形態に係るデータファイル配信システムＳのハード構成を模式的に示す図である。このデータファイル配信システムＳは、データファイル配信元であるサーバ装置１と、複数のクライアント（シーダ用クライアント２１Ａ〜２１Ｃ、クライアント２２Ａ〜２２Ｃ）とを含む。これらサーバ装置１と複数のクライアントとは相互にインターネット回線でネットワーク接続され、Ｐ２Ｐ方式でデータファイル配信を行うことが可能とされている。
【００３０】
ここで、ネットワーク配信されるデータファイルは、例えばＭＰＥＧ（moving picture experts group）方式で圧縮されたカラー動画映像ファイル、ＭＰ３（MPEG audio layer 3）方式で圧縮された音声ファイル、ＪＰＥＧ（joint photographic experts group）方式で圧縮されたカラー静止画像ファイルのような、各種のコンテンツファイルである。サーバ装置１は、例えばこのようなコンテンツファイルをユーザに向けて配信することを業とするコンテンツプロバイダに保有されるサーバ装置である。クライアントは、例えば前記ユーザに保有されるパーソナルコンピュータ等の端末装置である。
【００３１】
サーバ装置１は、第１サーバ（配信元サーバ１１）、第２サーバ（ＦＴＰレスキューサーバ１２）及び第３サーバ（Ｐ２Ｐレスキューサーバ１３）を備えている。またクライアントは、実質的にサーバの機能を果たすように利用されるシーダ用クライアント２１Ａ〜２１Ｃと、クライアント２２Ａ〜２２Ｃとからなる。なお、シーダ用クライアント２１Ａ〜２１Ｃは固定的なものではなく、後述するサーバ装置１の配信管理部１１２によってクライアント群の中から適宜選択されるものである。この選択は、例えばシーダ用クライアントの数を予め定めておき、データファイルの配信が完了したクライアントから順にシーダと扱うという運用とすることができる。このように各クライアントは、Ｐ２Ｐ通信におけるピアとしてそれぞれ機能する対等な端末装置であるが、配信効率を高めるため、フレキシブルに階層化されるようになっている。
【００３２】
配信元サーバ１１は、前記データファイルを保有し、クライアント（結果的にはシーダ用クライアント２１Ａ〜２１Ｃ）に対してデータファイルを配信するサーバである。ＦＴＰ（file transfer protocol）レスキューサーバ１２は、配信元サーバ１１が持つデータファイルを共有し、ファイル配信が遅延している特定のクライアントに対して、前記データファイルをファイル単位で直接配信するサーバである。Ｐ２Ｐレスキューサーバ１３は、同様に配信元サーバ１１が持つデータファイルを共有し、ファイル配信が遅延している特定のクライアントに対して、一つの前記データファイルを、細分化された小ファイル（サブピース）単位で直接配信するサーバである。
【００３３】
このように構成されたデータファイル配信システムＳの大略的な動作は次の通りである。先ず、任意の条件で、クライアントに向けて配信元サーバ１１からデータファイルが配信され、配信が完了したクライアントがシーダ用クライアント２１Ａ〜２１Ｃと扱われる。このシーダ用クライアント２１Ａ〜２１Ｃから各々、クライアント２２Ａ〜２２Ｃに対してデータファイルがＰ２Ｐ方式で配信される。さらに、クライアント２２Ａ〜２２Ｃ同士でもデータファイルがＰ２Ｐ方式で配信される。これにより、配信元サーバ１１のボトルネックの問題を解消して、効率良くデータファイル配信を行うことが可能となる。
【００３４】
しかし、Ｐ２Ｐ方式でデータファイルをクライアント２２Ａ〜２２Ｃ間で配信する場合、一部のクライアントに対してファイル配信が予定通りに進行しないことがある。この場合、クライアント２２Ａ〜２２Ｃ間のＰ２Ｐ通信に委ねていると、ある期限までに全クライアント（データファイルのダウンロード申請があったクライアント）へのデータファイルの配信を完了させる必要があるとき、その期限までにデータファイルの配信が完了できないことが生じ得る。
【００３５】
そこで、本実施形態のデータファイル配信システムＳでは、各クライアントに対するデータファイルの配信状況に関する情報を取得し、前記配信状況に基づいて各クライアントへの配信完了時を予測する配信管理手段（図２に示す配信管理部１１２）を備えている。そして、配信遅延が予測されるクライアントに対して、ＦＴＰレスキューサーバ１２及び／又はＰ２Ｐレスキューサーバ１３からデータファイルが直接的に救済配信されるように構成されている。以下、上記配信管理手段、並びに救済配信の機能について詳細に説明する。
【００３６】
図２は、データファイル配信システムＳの機能的な構成、特に配信元サーバ１１の機能的な構成を示すブロック図である。配信元サーバ１１は、コンテンツデータベース（ＤＢ）１１１と、配信管理部１１２とを備える。
【００３７】
コンテンツデータベース１１１は、上述の映像ファイル、音声ファイル、画像ファイルなどのデータファイルが格納されるデータベースである。コンテンツデータベース１１１に格納されているデータファイルは、クライアントからのダウンロード申請に応じて適宜配信される。
【００３８】
配信管理部１１２は、コンテンツデータベース１１１のデータファイルが遅滞なく各クライアントへ配信されるようにするために設置されている。配信管理部１１２は、ＣＰＵ（Central Processing Unit）、制御プログラムを記憶するＲＯＭ（Read Only Memory）、ＣＰＵの作業領域として使用されるＲＡＭ（Random Access Memory）等から構成され、ＣＰＵが制御プログラムを実行することにより、配信制御部３１、管理情報通信部３２、配信管理テーブル３３、配信履歴記憶部３４、配信予測部３５、レスキューサーバ制御部３６及びネットワーク接続制御部３７を具備するように機能する。
【００３９】
配信制御部３１は、データファイルの配信に当たり、後述する配信管理テーブル３３に設定されたセンターマスター情報を参照し、該センターマスター情報と配信すべきクライアント数とに応じてシーダ用クライアントの数を決定する。そして、配信リクエストのあったクライアントに向けて、コンテンツデータベース１１１に格納されているデータファイルを、インターネットＩＮを介して配信させる処理を行う。
【００４０】
ここで、データファイルの転送方式について説明しておく。図３は、映像ファイルや音声ファイルの転送に一般的に採用されているサブピース転送方式を模式的に示す図である。Ｐ２Ｐ方式で映像ファイルや音声ファイルを転送する場合に汎用されているビットトレント（Bit Torrent）方式も、かかる転送方式が採用されている。図３に示すように、サブピース転送方式では一つのデータファイルは、多数のサブピースファイルに細分化され、このサブピース単位でファイル転送が行われる。
【００４１】
図４は、配信元サーバ１１からクライアント（図２に示すシーダ用クライアント２１Ａ、２１Ｂ又はクライアント２２Ａ〜２２Ｃ）、シーダ用クライアント２１Ａ、２１Ｂとクライアント２２Ａ〜２２Ｃとの間、及びクライアント２２Ａ〜２２Ｃにおけるファイル転送の方式を模式的に示す図である。図４に示すように、この配信元サーバ１１等では、Ｐ２Ｐ方式でファイルを配信するために、上記のサブピース転送方式が採用されている。すなわち、配信すべきファイル１、ファイル２及びファイル３が存在するとき、ファイル１から順に、サブピース単位でファイル転送が行われる。
【００４２】
図５は、ＦＴＰレスキューサーバ１２から配信遅延クライアントへデータファイルを救済配信する場合の転送方式を模式的に示す図である。ＦＴＰレスキューサーバ１２は、ファイル１、ファイル２又はファイル３の単位で、配信遅延クライアントへファイル転送を行う。図５では、ファイル２がファイル単位で救済配信されている例を示している。この転送方式では、ファイル単位で転送が行なわれるので、データの転送効率が良いという利点がある。一方、ファイル単位での転送しか行えないので、例えばファイル２についてＰ２Ｐ方式で一部の転送が既に行われている場合でも、その一部転送済みのファイル２を廃棄し、新たにファイル２全体を転送し直す必要がある。
【００４３】
図６は、Ｐ２Ｐレスキューサーバ１３から配信遅延クライアントへデータファイルを救済配信する場合の転送方式を模式的に示す図である。Ｐ２Ｐレスキューサーバ１３は、一つのファイルのサブピースの単位で、配信遅延クライアントへファイル転送を行う。図６では、ファイル１に一部がサブピース単位で救済配信されている例を示している。この転送方式では、サブピース単位で転送が行なわれるので、例えばファイル１についてＰ２Ｐ方式で一部の転送が既に行われている場合には、その一部転送済みのファイル１を廃棄することなく、ファイル１のうち未転送のサブピースだけをＰ２Ｐ方式で配信できる利点がある。
【００４４】
図２に戻って、管理情報通信部３２は、各クライアントとデータ通信を行い、各クライアントからデータファイルの配信状況に関する情報を含む各種のクライアント情報を取得する。例えば管理情報通信部３２は、クライアントがサーバ装置１に接続されると、そのクライアントのアドレス、配信を希望するファイル名などの情報を取得して配信管理テーブル３３にクライアント毎の管理テーブルを作成すると共に、データファイルの配信進捗状況に関するデータを取得して前記管理テーブルに順次書き込む処理を行う。
【００４５】
配信管理テーブル３３は、データファイルの配信に当たり設定されるセンターマスター情報や、管理情報通信部３２と各クライアントとのデータ通信で取得されるクライアント情報を管理する機能部である。図７は、配信管理テーブル３３において管理されるテーブルの一例を示す表形式の図である。
【００４６】
図７（ａ）は、センターマスター情報のテーブルの一例である。ここでは、シーダチェックタイミング、配信開始日時、配信チェック日時、配信締切日時、最低限シーダ割合及びレスキューモード切り換え％が管理項目として挙げられている例を示している。
【００４７】
シーダチェックタイミングは、シーダ用クライアントが正常に動作しているか否かをチェックするインターバルの設定である。このシーダチェックは、シーダ用クライアントがネットワーク上に所要数存在しているか否かを確認するために行われる。ファイル転送を早く、効率良く行うには、配信を行うクライアントの総数に対して一定数以上のシーダが常時動作していることが望ましい。しかし、シーダ適格を持っているクライアント（ファイル転送が完了しているクライアント）が電源ＯＦＦとされてしまったり、過剰負荷で実質的にシーダの役割を果たさなかったりすることが起こり得る。そこで、シーダ数を常時把握するために、シーダチェックが行われるものである。管理情報通信部３２は、ここで設定されたシーダチェックタイミングでシーダ用クライアントと通信を行い、シーダチェックを行なう。
【００４８】
配信開始日時は、配信が行われる一つのデータファイル（群）の配信が実際に開始される日時の設定である。配信制御部３１は、この設定日時から、ファイル転送を開始する。また、配信締切日時は、一つのデータファイル（群）の配信を完了せねばならない日時の設定である。配信チェック日時は、各クライアントに対するデータファイルの配信状況を確認する日時の設定である。管理情報通信部３２は、この配信チェック日時に、各クライアントからデータファイル配信の進捗データを取得する。
【００４９】
最低限シーダ割合は、配信を行うクライアントの総数に対して、効率的なデータファイル配信を行うのに必要なシーダ数の設定である。ここではパーセンテージを例示しているが、例えばクライアント総数が５０台以下ならシーダ数は１台、５０〜１００台ならシーダ数は２台、というような設定をしても良い。本実施形態では、この最低限シーダ割合を上回ると、配信元サーバ１１がネットワークから離脱され、最低限シーダ割合を下回ると配信元サーバ１１がネットワークに復帰されてデータファイルの配信を再開する。
【００５０】
レスキューモード切り換え％は、配信遅延クライアントに対して救済配信を行う際、ＦＴＰレスキューサーバ１２又はＰ２Ｐレスキューサーバ１３のいずれを採用するかを判定するための閾値についての設定である。例えばレスキューモード切り換え％＝５０％に設定されている場合、一つのデータファイルについて、配信完了度が５０％以上であると、Ｐ２Ｐレスキューサーバ１３から救済配信が行われ、配信完了度が５０％未満であると、ＦＴＰレスキューサーバ１２からの配信が行われる。
【００５１】
図７（ｂ）は、クライアント情報の管理テーブルの一例である。ここでは、ニックネーム（クライアント毎に付与される一意の管理番号）、配信（ＤＬ）モードの別、ステイタスの他、配信ファイル毎に配信完了率が管理されている例を示している。また、配信開始日時と配信終了日時も記録されている。これらデータは、配信履歴の記録の際に活用される。
【００５２】
配信履歴記憶部３４（履歴情報データベース）には、各クライアントに対するデータファイルの配信履歴情報が格納される。図８は、配信履歴情報が格納されたテーブルの一例を示す表形式の図である。ここでは、前回、及び前々回の配信実績について、クライアント毎に、受信容量、平均受信速度、受信速度順位、送信容量、平均送信速度及び送信速度順位が記録されている例を示している。
【００５３】
配信予測部３５は、各クライアントから取得した配信状況に関するデータに基づいて、各クライアントへの配信完了時を予測する処理を行う。この際、配信予測部３５は、配信履歴記憶部３４に格納されている配信履歴情報を参照する。かかる配信履歴情報を参照することで、各クライアントへの配信完了時を適確に予測することができる。
【００５４】
具体的には配信予測部３５は、上記配信開始日時から配信チェック日時（図７（ａ）参照）までの配信完了度から、クライアント毎に平均転送容量を求め、この平均転送容量から配信完了時を予測する。実際の処理では、前記平均転送容量と配信チェック日時から配信締切日時までの期間とに基づき、通常のＰ２Ｐ通信で配信が可能な容量（配信可能容量）を求める。そして、この配信可能容量と、配信チェック日時の時点で未だ配信が完了していないデータ容量（残転送容量）とを比較し、配信締切日時までに配信が完了できるか否かを判定する。
【００５５】
レスキューサーバ制御部３６は、配信予測部３５により、データファイルの配信が配信締切日時までに完了できないと予測されるクライアント（配信遅延クライアント）が特定されたとき、ＦＴＰレスキューサーバ１２及び／又はＰ２Ｐレスキューサーバ１３を制御し、その配信遅延クライアントに対して未配信のデータファイルを直接配信（救済配信）させる。
【００５６】
レスキューサーバ制御部３６は、状況に応じて、ＦＴＰレスキューサーバ１２を用いて救済配信を行うＦＴＰレスキューモード、Ｐ２Ｐレスキューサーバ１３を用いて救済配信を行うＰ２Ｐレスキューモード、並びに、ＦＴＰレスキューサーバ１２及びＰ２Ｐレスキューサーバ１３の双方を用いて救済配信を行う複合レスキューモードのいずれかをモード選択する。なお、複合レスキューモードを適用する際には、レスキューサーバ制御部３６は、配信管理テーブル３３のレスキューモード切り換え％を参照して両者の切替を行う。
【００５７】
ネットワーク接続制御部３７は、クライアント間におけるデータ配信環境の形成状況に応じて、配信元サーバ１１のネットワークに対する離脱、及び離脱後のネットワークへの復帰を制御する。具体的にはネットワーク接続制御部３７は、配信管理テーブル３３の最低限シーダ割合を参照し、この最低限シーダ割合を上回ると、配信元サーバ１１をネットワークから離脱させ、最低限シーダ割合を下回ると配信元サーバ１１をネットワークに復帰させる。
【００５８】
このような制御を行うことで、十分なシーダの数が確保された段階で配信元サーバ１１がネットワークから離脱されるので、データファイルの配信に不具合を与えない一方で、配信元サーバ１１の負荷を軽減でき、配信元サーバ１１を他の用途に用い易くなる。一方、実働シーダの数が減少したような場合に、配信元サーバ１１がネットワークへ復帰されるので、データファイルの配信が滞らないようにすることができる。
【００５９】
また、サーバ装置１として単一のサーバ装置が用いられ、これを配信元サーバ１１として機能する部分（第１機能部）、ＦＴＰレスキューサーバ１２として機能する部分（第２機能部）、及び、Ｐ２Ｐレスキューサーバ１３として機能する部分（第３機能部）に区分して運用する場合、第１機能部をネットワークから切り離す一方で、第２機能部及び／又は第３機能部が前記ネットワークに接続された状態を維持することで、当該単一のサーバ装置の負荷を軽減でき、レスキューサーバとしての機能を高速で実行させることが可能となる。
【００６０】
続いて、以上説明したデータファイル配信システムＳの動作を、フローチャートに従って説明する。図９は、本実施形態に係るデータファイル配信システムＳ（配信管理部１１２）によるデータファイル配信処理の全体的な概略動作を示すフローチャートである。配信管理部１１２は、クライアントからのダウンロード申請等に応じてデータファイルの配信するとき、先ずその配信のために必要な各種の設定を行う（ステップＳ１）。しかる後、クライアントに対してデータファイルを配信する制御を行う（ステップＳ２）。
【００６１】
図１０は、図９に示したステップＳ１の配信設定処理の詳細を示すフローチャートである。先ず、コンテンツデータベース１１１に、リクエストに応じて配信されるデータファイルの登録が受け付けられる（ステップＳ１１）。既に当該データファイルがコンテンツデータベース１１１に格納されている場合は、配信選択が受け付けられる。
【００６２】
次に、配信管理テーブル３３に、センターマスター情報として各項目の設定が受け付けられる（ステップＳ１２）。ここでの設定項目は、上述した通り、例えばシーダチェックタイミング、配信開始日時、配信チェック日時、配信締切日時、最低限シーダ割合及びレスキューモード切り換え％等である（図７（ａ）参照）。
【００６３】
続いて、配信制御部３１に、データファイルを配信すべきクライアント総数の入力が受け付けられる（ステップＳ１３）。このクライアント総数と、前記センターマスター情報とを参照して、配信制御部３１は今回の配信に最低限必要なシーダ用クライアントの数を決定する（ステップＳ１４）。
【００６４】
図１１は、図９に示したステップＳ２の配信制御処理の概略を示すフローチャートである。上述の配信設定が完了し、設定された配信開始日時が到来すると、配信制御部３１は、配信リクエストのあったクライアントに向けて、コンテンツデータベース１１１に格納されているデータファイルを、ネットワーク（インターネットＩＮ）を介して配信させる処理を開始する（ステップＳ２１）。
【００６５】
その後、配信チェック日時が到来すると、管理情報通信部３２により逐次取得されているクライアント情報（図７（ｂ）参照）に基づく配信遅延クライアントの特定、及び救済配信を骨子とする救済処理が実行される（ステップＳ２２）。これと並行して、ネットワーク接続制御部３７により、配信元サーバ１１のネットワークに対する離脱、及び復帰を制御するサーバ離脱復帰処理が実行される（ステップＳ２３）。
【００６６】
図１２は、図１１に示したステップＳ２３のサーバ離脱復帰処理の詳細を示すフローチャートである。ネットワーク接続制御部３７は、配信管理テーブル３３の最低限シーダ割合を参照し、シーダ数が所定数に到達しているか否かを判定する（ステップＳ３１）。なお、シーダのカウントは、管理情報通信部３２が取得するクライアント情報において配信完了率が１００％であるクライアントの数に依る。
【００６７】
シーダ数が所定数に到達していない場合（ステップＳ３１でＮＯ）、ネットワーク接続制御部３７は、配信元サーバ１１がネットワークに接続された状態を維持する。一方、シーダ数が所定数に到達すると場合（ステップＳ３１でＹＥＳ）、ネットワーク接続制御部３７は、配信元サーバ１１をネットワークから離脱させ、配信元サーバ１１からのデータファイルの配信を停止させる（ステップＳ３２）。
【００６８】
その後、ネットワーク接続制御部３７は、センターマスター情報の一つとして設定されているシーダチェックタイミングの到来を待ち（ステップＳ３３）、そのシーダチェックタイミングが到来すると（ステップＳ３３でＹＥＳ）、シーダ数が所定数を維持しているか否かを判定する（ステップＳ３４）。
【００６９】
所定数のシーダがネットワーク上に存在している場合（ステップＳ３４でＹＥＳ）、ステップＳ３３に戻って処理が繰り返される。これに対し、所定数のシーダがネットワーク上に存在していない状態となった場合（ステップＳ３４でＮＯ）、ネットワーク接続制御部３７は、配信元サーバ１１をネットワークに復帰させ、配信元サーバ１１からのデータファイルの配信を再開させる（ステップＳ３５）。その後、ステップＳ３１に戻って処理が繰り返される。
【００７０】
次に、図１１に示したステップＳ２２の救済処理の詳細を説明する。本実施形態では、下記の３つのモードによる救済配信が可能とされている。
［１］ＦＴＰレスキューモード：ＦＴＰレスキューサーバ１２を利用
［２］Ｐ２Ｐレスキューモード：Ｐ２Ｐレスキューサーバ１３を利用
［３］複合レスキューモード：ＦＴＰレスキューサーバ１２及びＰ２Ｐレスキューサーバ１３の双方を利用
以下、これら３つのモードの各々の詳細を順次説明する。
【００７１】
図１３は、ＦＴＰレスキューモードによる救済処理の詳細を示すフローチャートである。配信予測部３５は、センターマスター情報の一つとして設定されている配信チェック日時の到来を待つ（ステップＳ４１）。その配信チェック日時が到来すると（ステップＳ４１でＹＥＳ）、配信予測部３５は、配信管理テーブル３３のクライアント情報を参照してクライアント毎に配信進捗度を確認し、配信チェック日時〜配信締切日時までの期間の配信可能容量が、残転送容量を上回っているか否かを確認する（ステップＳ４２）。
【００７２】
特定のクライアントについて配信可能容量＜残転送容量であった場合（ステップＳ４２でＮＯ）、そのクライアントには配信締切日時までにデータファイルの配信が完了できない可能性が高いので、救済配信が必要となる。この場合、当該配信遅延クライアントに対するＤＬモードが通常の“Ｐ２Ｐモード”から“ＦＴＰレスキューモード”に変更され（ステップＳ４３）、レスキューサーバ制御部３６によりＦＴＰレスキューサーバ１２が制御され、配信遅延クライアントに対して未配信のデータファイルがＦＴＰレスキューサーバ１２から直接配信される（ステップＳ４４）。
【００７３】
図１４は、ＦＴＰレスキューモードによる救済配信の態様を模式的に示す図である。配信すべきデータファイルとして、ファイル１、ファイル２又はファイル３が存在するものとし、配信チェック日時において特定のクライアントについてファイル１の転送しか完了していないと想定する。そして、ファイル２及びファイル３の転送が、通常のＰ２Ｐ配信ルートではこれまでの伝送実績からして配信締切日時に間に合わないと判定される場合、このファイル２及びファイル３が、ＦＴＰレスキューサーバ１２から配信遅延クライアントへファイル単位で救済配信されるものである。
【００７４】
なお、ステップＳ４２で配信可能容量＜残転送容量と判定された場合に、システム管理者の端末機や、そのクライアントに、配信が遅延している旨の報知を、電子メール等で行わせるようにしても良い。
【００７５】
特定のクライアントについて配信可能容量＞残転送容量であった場合（ステップＳ４２でＹＥＳ）、そのクライアントには特に救済配信は実行されない。その後、クライアントに対するデータファイルの配信が１００％完了したか否かが、クライアント情報に基づき確認される（ステップＳ４５）。配信が１００％完了したならば（ステップＳ４５でＹＥＳ）、システム管理者の端末機及びクライアントに、配信の完了を報知する電子メールが配信管理部１１２から発信される（ステップＳ４６）。しかる後、ネットワーク接続制御部３７によるサーバ離脱復帰処理機能が停止され（ステップＳ４７）、配信処理が完了する。
【００７６】
図１５は、Ｐ２Ｐレスキューモードによる救済処理の詳細を示すフローチャートである。配信予測部３５は、先に図１３のフローチャートで説明したステップＳ４１、ステップＳ４２と同様に、配信チェック日時を待ち（ステップＳ５１）、その時点で配信可能容量＞残転送容量の関係を満たすか否かを確認する（ステップＳ５２）。
【００７７】
特定のクライアントについて配信可能容量＜残転送容量であった場合（ステップＳ５２でＮＯ）、救済配信が必要となるため、その配信遅延クライアントに対するＤＬモードが通常の“Ｐ２Ｐモード”から“Ｐ２Ｐレスキューモード”に変更される（ステップＳ５３）。そして、レスキューサーバ制御部３６によりＰ２Ｐレスキューサーバ１３が制御され、配信遅延クライアントに対して未配信のデータファイルがＰ２Ｐレスキューサーバ１３から直接配信される（ステップＳ５４）。
【００７８】
図１６は、Ｐ２Ｐレスキューモードによる救済配信の態様を模式的に示す図である。配信すべきデータファイルとして、ファイル１、ファイル２又はファイル３が存在するものとし、配信チェック日時において特定のクライアントについてファイル１の途中までの転送しか完了していないと想定する。このままでは配信締切日時に間に合わないと判定される場合、その配信遅延クライアントに対して、区切りの良いサブピースまで通常のＰ２Ｐ通信での配信が行われた後、ファイル１の残りのサブピースがＰ２Ｐレスキューサーバ１３から帯域を独占する形態で直接配信される。以後、ファイル２及びファイル３が、順次サブピース単位でＰ２Ｐレスキューサーバ１３から配信されるものである。
【００７９】
特定のクライアントについて配信可能容量＞残転送容量であった場合（ステップＳ５２でＹＥＳ）、そのクライアントには特に救済配信は実行されない。その後、データファイルの配信が１００％完了したか否かが確認され（ステップＳ５５）、配信が１００％完了したならば（ステップＳ５５でＹＥＳ）、システム管理者の端末機及びクライアントに、配信の完了を報知する電子メールが配信管理部１１２から発信される（ステップＳ５６）。しかる後、ネットワーク接続制御部３７によるサーバ離脱復帰処理機能が停止され（ステップＳ５７）、配信処理が完了する。
【００８０】
図１７は、複合レスキューモードによる救済処理の詳細を示すフローチャートである。配信予測部３５は、先に図１３のフローチャートで説明したステップＳ４１、ステップＳ４２と同様に、配信チェック日時を待ち（ステップＳ６１）、その時点で配信可能容量＞残転送容量の関係を満たすか否かを確認する（ステップＳ６２）。
【００８１】
特定のクライアントについて配信可能容量＜残転送容量であった場合（ステップＳ６２でＮＯ）、救済配信が必要となるのであるが、ここでレスキューモードを選定するために、レスキューサーバ制御部３６は、現在転送中のファイルの配信完了度が所定の閾値（レスキューモード切り換え％）を超過しているか否かを、クライアント情報に基づき確認する（ステップＳ６３）。この閾値は、上述の通り、例えば５０％である。
【００８２】
配信完了度が所定の閾値を下回っている場合（ステップＳ６３でＮＯ）、配信完了度が低く、現在転送中のファイルを破棄して新たに配信速度が速いＦＴＰ方式で救済配信した方が時間的に有利である。このため、かかるケースでは、レスキューサーバ制御部３６は、その配信遅延クライアントに対するＤＬモードを通常の“Ｐ２Ｐモード”から“ＦＴＰレスキューモード”に変更し（ステップＳ６４）、ＦＴＰレスキューサーバ１２を制御して、配信遅延クライアントに対して現在転送中のファイルに相当するデータファイルを直接配信させる（ステップＳ６８）。この場合、通常の“Ｐ２Ｐモード”で途中まで配信されたファイルは破棄されることになる。
【００８３】
一方、配信完了度が所定の閾値を超過している場合（ステップＳ６３でＹＥＳ）、現在転送中のファイルを破棄して新たにそのファイルを救済配信するのは時間的に無駄が多いと言える。従って、この場合レスキューサーバ制御部３６は、その配信遅延クライアントに対するＤＬモードを通常の“Ｐ２Ｐモード”から“Ｐ２Ｐレスキューモード”に変更し（ステップＳ６５）、Ｐ２Ｐレスキューサーバ１３を制御して、配信遅延クライアントに対して現在転送中のファイルのうち未配信のサブピースデータファイルを直接配信させる（ステップＳ６６）。
【００８４】
その後、転送中のファイルにつき配信が完了したか否かが確認される（ステップＳ６７）。配信が完了したら（ステップＳ６７でＹＥＳ）、レスキューサーバ制御部３６は、救済モードを“ＦＴＰレスキューモード”に変更する（ステップＳ６４）。これは、残りのファイルについては、転送効率のよい“ＦＴＰレスキューモード”を選択した方が時間的に有利だからである。そして、残りのファイルが、ＦＴＰレスキューサーバ１２から直接配信される（ステップＳ６８）。なお、残りのファイルが存在しない場合は、これらステップＳ６７〜Ｓ６８はスキップされる。
【００８５】
図１８は、複合レスキューモードによる救済配信の態様を模式的に示す図である。配信すべきデータファイルとして、ファイル１、ファイル２又はファイル３が存在するものとし、配信チェック日時において特定のクライアントについてファイル１の途中までの転送しか完了していないと想定する。ファイル１の配信完了度が閾値（例えば５０％）を超過している場合、図示しているように、区切りの良いサブピースまで通常のＰ２Ｐ通信での配信が行われた後、ファイル１の残りのサブピースがＰ２Ｐレスキューサーバ１３から帯域を独占する形態で直接配信される。その後、ファイル２及びファイル３については、配信効率の良いＦＴＰレスキューサーバ１２により救済配信が行われる。ファイル１の配信完了度が閾値を下回っているときは、ファイル１、ファイル２又はファイル３の全てが、ＦＴＰレスキューサーバ１２により救済配信される。
【００８６】
特定のクライアントについて配信可能容量＞残転送容量であった場合（ステップＳ６２でＹＥＳ）、そのクライアントには特に救済配信は実行されない。その後、データファイルの配信が１００％完了したか否かが確認され（ステップＳ６９）、配信が１００％完了したならば（ステップＳ６９でＹＥＳ）、システム管理者の端末機及びクライアントに、配信の完了を報知する電子メールが配信管理部１１２から発信される（ステップＳ７０）。しかる後、ネットワーク接続制御部３７によるサーバ離脱復帰処理機能が停止され（ステップＳ７１）、配信処理が完了する。
【００８７】
以上、本発明を表現するために、上述において図面を参照しながら実施形態を通して本発明を適切且つ十分に説明したが、当業者であれば上述の実施形態を変更及び／又は改良することは容易に為し得ることであると認識すべきである。従って、当業者が実施する変更形態又は改良形態が、請求の範囲に記載された請求項の権利範囲を離脱するレベルのものでない限り、当該変更形態又は当該改良形態は、当該請求項の権利範囲に包括されると解釈される。
【図面の簡単な説明】
【００８８】
【図１】本発明の実施形態に係るデータファイル配信システムＳのハード構成を模式的に示す図である。
【図２】データファイル配信システムＳの機能的な構成を示すブロック図である。
【図３】サブピース転送方式を模式的に示す図である。
【図４】配信元サーバ等からクライアントへのファイル転送の方式を模式的に示す図である。
【図５】ＦＴＰレスキューサーバから配信遅延クライアントへデータファイルを救済配信する場合の転送方式を模式的に示す図である。
【図６】Ｐ２Ｐレスキューサーバから配信遅延クライアントへデータファイルを救済配信する場合の転送方式を模式的に示す図である。
【図７】配信管理テーブルにおいて管理されるテーブルの一例を示す表形式の図である。
【図８】配信履歴情報が格納されたテーブルの一例を示す表形式の図である。
【図９】データファイル配信システムＳによるデータファイル配信処理の全体的な概略動作を示すフローチャートである。
【図１０】図９に示したステップＳ１の配信設定処理の詳細を示すフローチャートである。
【図１１】図９に示したステップＳ２の配信制御処理の概略を示すフローチャートである。
【図１２】図１１に示したステップＳ２３のサーバ離脱復帰処理の詳細を示すフローチャートである。
【図１３】ＦＴＰレスキューモードによる救済処理の詳細を示すフローチャートである。
【図１４】ＦＴＰレスキューモードによる救済配信の態様を模式的に示す図である。
【図１５】Ｐ２Ｐレスキューモードによる救済処理の詳細を示すフローチャートである。
【図１６】Ｐ２Ｐレスキューモードによる救済配信の態様を模式的に示す図である。
【図１７】複合レスキューモードによる救済処理の詳細を示すフローチャートである。
【図１８】複合レスキューモードによる救済配信の態様を模式的に示す図である。
【符号の説明】
【００８９】
１  サーバ装置
１１  配信元サーバ（第１のサーバ）
１２  ＦＴＰレスキューサーバ（第２のサーバ）
１３  Ｐ２Ｐレスキューサーバ（第３のサーバ）
２１Ａ〜２１Ｃ  シーダ用クライアント
２２Ａ〜２２Ｃ  クライアント
３１  配信制御部
３２  管理情報通信部
３３  配信管理テーブル
３４  配信履歴記憶部
３５  配信予測部
３６  レスキューサーバ制御部
３７  ネットワーク接続制御部
１１１  コンテンツデータベース
１１２  配信管理部
Ｓ  データファイル配信システム
【図１】
2008304980.tif 000003
【図２】
2008304980.tif 000004
【図３】
2008304980.tif 000005
【図４】
2008304980.tif 000006
【図５】
2008304980.tif 000007
【図６】
2008304980.tif 000008
【図７】
2008304980.tif 000009
【図８】
2008304980.tif 000010
【図９】
2008304980.tif 000011
【図１０】
2008304980.tif 000012
【図１１】
2008304980.tif 000013
【図１２】
2008304980.tif 000014
【図１３】
2008304980.tif 000015
【図１４】
2008304980.tif 000016
【図１５】
2008304980.tif 000017
【図１６】
2008304980.tif 000018
【図１７】
2008304980.tif 000019
【図１８】
2008304980.tif 000020