(57)【特許請求の範囲】
【請求項１】
帯域が保証されていないデータ配信システム（ネットワーク）における、ファイル転送の中断再開が可能なダウンロード方法において、ダウンロードが中断した際、クライアントマシンが、ダウンロードするサーバマシンとの過去Ｘ（Ｘは固定値、設定により可変）秒のスループット（以下、Ｓと称する）が事前に設定した閾値（以下、Ｓｍｉｎと称する）を超える（Ｓ＞Ｓｍｉｎ）場合は、（Ｆ−１）回（Ｆは固定値、設定により可変）は、短時間（ウェイトタイマー値Ｔｓ）で再開を試み、Ｆ回以上連続して再開に失敗した場合は、ウェイトタイマー値ＴｓをＴｌ（＞Ｔｓ）に設定変更して再開を試み、Ｓ≦Ｓｍｉｎの場合は、短時間（ウェイトタイマー値Ｔｓ）で再開を試みることを特徴とするダウンロード方法。
【請求項２】
帯域が保証されていないデータ配信システム（ネットワーク）における、ファイル転送の中断再開が可能なダウンロード方法の処理手順を、コンピュータに実行させるためのプログラムを記憶したコンピュータが読み出し可能な記憶媒体であって、ダウンロードが中断した際、ダウンロードするサーバマシンとの過去Ｘ（Ｘは固定値、設定により可変）秒のスループット（以下、Ｓと称する）が事前に設定した閾値（以下、Ｓｍｉｎと称する）を超える（Ｓ＞Ｓｍｉｎ）場合は、（Ｆ−１）回（Ｆは固定値、設定により可変）は、短時間（ウェイトタイマー値Ｔｓ）で再開を試みる手順と、Ｆ回以上連続して再開に失敗した場合は、ウェイトタイマー値をＴｌ（＞Ｔｓ）に設定変更して再開を試みる手順と、Ｓ≦Ｓｍｉｎの場合は、短時間（ウェイトタイマー値＝Ｔｓ）で再開を試みる手順を、コンピュータに実行させるためのプログラムを記憶したコンピュータが読み出し可能な記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ配信システムにおけるダウンロード方法（配信予約方法）及びファイル転送を行うダウンロードプログラムを記録したクライアントの記録媒体に関する。
【０００２】
【従来の技術】
ダウンロードの中断再開を可能とするソフトウェアモジュールとして、パソコン上のｉｒｉａ（フリーウェア）等のダウンロード支援ソフトウェアを利用する方法がある。
【０００３】
ダウンロード支援ソフトウェアは、ＦＴＰ（ファイル転送）及びＨＴＴＰ（Ｗｅｂ）から自分のパソコンにファイルのダウンロードを行い、希望のファイルを確実にダウンロードすることを目的としており、ファイルをダウンロードしようとしているサーバーがビジー（忙しい状態）もしくは反応が無かった場合には、ダウンロードが完了するまでリトライ（再試行）することができる。ＨＴＴＰとＦＴＰのどちらからでも、中断された位置からダウンロードをレジューム（再開）することができる。
【０００４】
さらに、複数のファイルを同時にダウンロードすることもできる。また、スケジューリング機能（以下、予約配信機能）として、指定された時刻にインターネットプロバイダに自動接続してファイルをダウンロードしたり、逆に、接続を切断したりすることができる。
【０００５】
但し、これらのダウンロード支援ソフトウェアにおいて、ダウンロード中断時の、ダウンロード再開方法は、図８に示すように、サーバマシンからクライアントマシンヘのダウンロード開始後に、ダウンロード状況を判定し、データを全て受信完了する前にデータ受信の失敗によりタウンロード中断が生じた場合、ウェイトタイマー値Ｔｓの時間（定数）待って、ダウンロードを再開していた。このウェイトタイマー値Ｔｓは、固定の設定値であった。
【０００６】
【発明が解決しようとする課題】
この場合、ダウンロード中断が連続して生じた場合は、ウェイトタイマー値Ｔｓという定数を基に再送を行っていた。
【０００７】
しかし、この再送を行う時点で、（ａ）サーバマシンとクライアントマシン間の通信路に、一時的な何らかのトラブルが生じている、（ｂ）一時的にサーバのダウンロードプロセスが高負荷により停止している等の事象が発生している可能性があり、その場合は、いくらリトライしても、ダウンロードは再開されず、（ｃ）ダウンロードセッションの確立による、無駄なトラフィックの発生が生じていた。もし、クライアントとサーバの間にダウンロードのセッションを確立するために有料の回線を利用する場合には、無駄な回線使用コストが生じていた。
【０００８】
本発明の目的は、無駄なトラフィックを抑制しつつ、できるだけ短時間にダウンロードを終了することが可能な技術を提供することにある。
【０００９】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかにする。
【００１０】
【課題を解決するための手段】
本願において開示される発明の概要を簡単に説明すれば、下記のとおりである。
【００１２】
（１）帯域が保証されていないデータ配信システム（ネットワーク）における、ファイル転送の中断再開が可能なダウンロード方法において、ダウンロードが中断した際、クライアントマシンが、ダウンロードするサーバマシンとの過去Ｘ（Ｘは固定値、設定により可変）秒のスループット（以下、Ｓと称する）が事前に設定した閾値（以下、Ｓｍｉｎと称する）を超える（Ｓ＞Ｓｍｉｎ）場合は、（Ｆ−１）回（Ｆは固定値、設定により可変）は、短時間（ウェイトタイマー値Ｔｓ）で再開を試み、Ｆ回以上連続して再開に失敗した場合は、ウェイトタイマー値ＴｓをＴｌ（＞Ｔｓ）に設定変更して再開を試み、Ｓ≦Ｓｍｉｎの場合は、短時間（ウェイトタイマー値Ｔｓ）で再開を試みる。
【００１３】
ここで、Ｔｌ、Ｔｓは、ともに回線の実効帯域が理想値の場合、ダウンロードが中断せずに完了したと仮定した場合の予想ファイル転送時間（Ｔｄｏｗｎ）に対しては、非常に短い値とする。
【００１４】
（２）帯域が保証されていないデータ配信システム（ネットワーク）における、ファイル転送の中断再開が可能なダウンロード方法の処理手順を、コンピュータに実行させるためのプログラムを記憶したコンピュータが読み出し可能な記憶媒体であって、ダウンロードが中断した際、ダウンロードするサーバマシンとの過去Ｘ（Ｘは固定値、設定により可変）秒のスループット（以下、Ｓと称する）が事前に設定した閾値（以下、Ｓｍｉｎと称する）を超える（Ｓ＞Ｓｍｉｎ）場合は、（Ｆ−１）回（Ｆは固定値、設定により可変）は、短時間（ウェイトタイマー値Ｔｓ）で再開を試みる手順と、Ｆ回以上連続して再開に失敗した場合は、ウェイトタイマー値をＴｌ（＞Ｔｓ）に設定変更して再開を試みる手順と、Ｓ≦Ｓｍｉｎの場合は、短時間（ウェイトタイマー値＝Ｔｓ）で再開を試みる手順を、コンピュータに実行させるためのプログラムを記憶したコンピュータが読み出し可能な記憶媒体である。
【００１５】
前記本発明の手段によれば、中断再開が可能なファイルのダウンロードを行う場合に、ダウンロードの中断再開タイマー値を可変とし、データダウンロードが成功している時の平均スループット（ｎｏｔ＝直前のスループット）を保持し、中断発生時には、そのスループットをパラメータとして、スループット高で予め設定した回数連続して中断が発生したら、中断再開タイマー値を長くし、スループット低なら何度連続して中断が発生しても、中断再開タイマー値を維持することにより、クライアントとサーバの間のトラフィックを軽減できるので、できるだけ早くダウンロードを完了させることができる。また、クライアントとサーバ間で有料の回線を利用する場合は、無駄な回線使用コストを軽減できる。
【００１６】
以下に、本発明について、本発明による実施形態（実施例）とともに図面を参照して詳細に説明する。
【００１７】
【発明の実施の形態】
本発明による一実施形態は、ダウンロードの中断再開タイマー値の制御方法において、生じる中断再開タイマーの制御方法として、ダウンロードが中断した際、ダウンロードするサーバマシンとの過去Ｘ（Ｘは固定値、設定により可変）秒のスループットＳが事前に設定した閾値Ｓｍｉｎを超える（Ｓ＞Ｓｍｉｎ）場合は、一時的な回線または一時的なサーバ障害の疑いと判定し、（Ｆ−１）回（Ｆは固定値、設定により可変）は、ウェイトタイマー値Ｔｓ（短時間）で再開を試みる。Ｆ回以上連続して再開に失敗した場合は、何らかの一時的障害が発生したと判定し、ウェイトタイマー値ＴｓをＴｌ（＞Ｔｓ）に設定変更して再開を試みる。
【００１８】
また、Ｓ≦Ｓｍｉｎの場合は、恒久的に回線状況が悪いと判断し、ウェイトタイマー値Ｔｓ（短時間）で再開を試みる。
【００１９】
ここで、Ｔｌ、Ｔｓは、ともに回線の実効帯域が理想値の場合、ダウンロードが中断せずに完了したと仮定した場合の予想ファイル転送時間（Ｔｄｏｗｎ）に対しては、非常に短い値とする。すなわち、Ｔｄｏｗｎ≫Ｔｌ＞Ｔｓである。具体的には、ダウンロード対象のファイルサイズが、８ＭＢ（＝６４０００ｋｂｉｔ）で、回線帯域が６４ｋｂｉｔ／ｓｅｃの場合は、Ｔｄｏｗｎ＝６４０００／６４＝１０００ｓｅｃとなり、この場合の、Ｔｌ、Ｔｓはそれぞれ６０ｓｅｃ、１０ｓｅｃ程度を想定している。勿論、これらの値は、状況に応じて、適切な値に設定することが望ましいし、もしくは、ファイルのダウンロードを実行する毎に回線速度とファイルサイズファイルから適切なＴｌ、Ｔｓを計算して、設定する方法でもよい。
【００２０】
前記のダウンロード中断再開におけるウェイトタイマー値Ｔｓの制御方法が、無駄なトラフィックを抑制しつつ、できるだけ速くダウンロードを完了させる根拠としては、以下の（ａ）及び（ｂ）が挙げられる。
【００２１】
（ａ）ダウンロード実行時のスループットが高くて、ダウンロードが中断した場合は、サーバまでの回線状況が一時的に悪化して、ダウンロードが中断したと推定される。通常は、数回（以下、Ｆ回とする）のリトライでダウンロード再開に成功することが普通であり、もし、Ｆ回のリトライでダウンロード再開に成功しなかった場合も、再開後、高いスループットでのダウンロードが期待されるので、Ｆ＋１回以降のリトライは、ウェイトタイマー値Ｔｓを長めに設定しても、トータルの転送時間は、短く完了する。
【００２２】
（ｂ）ダウンロード実行時のスループットが低くて、ダウンロードが中断した場合は、サーバまでの回線状況が一時的ではなく、恒久的に悪く、ダウンロードが中断しやすい状態と考えられる。よってダウンロードの中断が回線状況が悪いことが原因で頻繁に生じることが予想されるため、再開までのウェイトタイマー値を大きくすることは、意味がなく、逆に、頻繁にアクセスして、少しずつのデータ量でもよいから、ダウンロードを実行したほうが効率的である。
【００２３】
本発明を実現するダウンロード方法及びそのプログラムを記憶した記憶媒体の中には、ファイル転送実行部とファイル転送制御部の２つを設ける。
【００２４】
ファイル転送実行部は、サーバから実際にデータを受信、格納するモジュールである。ダウンロードアルゴリズムは、中断再開に対応しているプロトコルである必要があり、現時点では、ＨＴＴＰのファイル受信プロトコルが望ましい。勿論、将来的にＦＴＰ等のＴＣＰ／ＩＰ汎用ファイル転送プロトコルが中断再開に対応すれば、そのプロトコルであってもよいし、ＴＣＰ／ＩＰを使っていれば、独自のプロトコルでもよい。
【００２５】
前記ファイル転送実行部は、既存のファイル転送モジュールであり、特に新規性はないが、ダウンロード状況として、
i）データを全て受信完了したか？
ii)データを受信失敗してダウンロードを中断したか？
iii)データを受信実行中で、かつ残りのデータがあるか？
を外部のモジュールから判定できるようにしておく必要がある。
【００２６】
この実現手法の一例としては、プロセスの終了時に、その終了の理由を示すステータスコードファイルを生成し、外部からそれを参照する方法があるが、他にどんな方法でもダウンロード状況が判定できればそれでよい。
【００２７】
以下に、プロセスの終了時にステータスコードファイルを生成する方法の代表例を以下に説明する。ステータスコードファイルの内容は、
（ａ）データを受信失敗してダウンロードを中断した場合：エラー終了
（ｂ）データを全て受信完了した場合：正常終了
（ｃ）データを受信実行中で、かつ残りのデータがない場合：ファイル未作成
とする。
【００２８】
また、ダウンロードのスループットを計算するため、ダウンロードしたファイルサイズを保持し、外部からそれを参照する機能も必要である。この実現手法の一例として、ファイルをダウンロードする毎に、ダウンロードしたファイルサイズを別のファイル（以下、ダウンロード済みファイルサイズファイル）に記憶しておく方法があるが、ファイルではなく、メモリ空間でもよいし、他にどんな方法でもファイルサイズを保持できればよい。
【００２９】
前記ファイル転送制御部は、前記ファイル転送実行部に対して、ダウンロードの開始、再開及び再開までのウェイトタイマー値Ｔｓを制御するモジュールである。
【００３０】
図１は、本実施形態の一実施例のファイル転送制御部の動作を示すフローチャートである。図１において、各定数、変数の説明は、以下のとおりである。
【００３１】
初期設定を行う定数としては、
Ｔｓ：間隔の短いタイマー値（ｓｅｃ）
Ｔｌ：間隔の長いタイマー値（Ｔｌ＞Ｔｓ）（ｓｅｃ）
Ｓｍｉｎ：回線状況良好と判定するスループットの最小値
Ｆｍｉｎ：高スループット状態でのデータ受信連続許容失敗回数
Ｘｔｉｍｅｒ：スループットを観測する間隔
また、変数としては、
Ｓ：データ受信時の過去Ｘ秒のスループット（ｋｂｉｔ／ｓｅｃ）
Ｆ：高スループット状態でのデータ受信連続失敗回数
Ｔｉｍｅ：ダウンロード開始からの経過時間（ｓｅｃが最小単位、端数は切り捨て）を用いる。
【００３２】
本実施例のファイル転送制御部は、図１に示すように、ステップ（ｓｔｅｐ）０をスタート（ＳＴＡＲＴ）とする。ステップ０では、演算制御の初期値としてＳ＝０、Ｆ＝０をセットし、ステップ１に進む。
【００３３】
ステップ１において、ファイル転送制御部は、ファイル転送実行部に対してダウンロード開始指示を出し、Ｔｉｍｅ＝０にセットし、ステップ２に進む。
【００３４】
ステップ２では、ダウンロードの状況を判定する。ダウンロード状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。
【００３５】
ステータスコードファイルが生成されていない場合は、データを受信成功し、かつ、残りのデータがあると判定しステップ７に進む。
【００３６】
ステータスコードファイルの内容がエラー終了の場合、ステップ３に進む。
【００３７】
ステータスコードファイルの内容が正常終了の場合は、処理を終了する。
【００３８】
ステップ７では、データの受信が成功しているため変数Ｆを０にセットしステップ１１に進む。
【００３９】
ステップ１１では、ダウンロード時間（Ｔｉｍｅ）が、設定値Ｘを既に経過しているか否かを判定する。具体的には、Ｔｉｍｅ≧Ｘを判定し、真なら、ステップ１２に進む。偽なら、ステップ１３に進む。
【００４０】
ステップ１２では、ダウンロード時間（Ｔｉｍｅ）が、スループットの測定タイミングであるかを判定する。すなわち、Ｔｉｍｅが、Ｘｔｉｍｅｒの整数倍か否かを判定する。具体的には、（Ｔｉｍｅ）ｍｏｄ（Ｘｔｉｍｅｒ）＝０を判定し、真なら、ステップ８に進む。偽なら、ステップ１３に進む。
【００４１】
ステップ８では、過去Ｘ秒の平均スループットを計算してＳとして保持し、ステップ２へ進む。平均スループットは、（ダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分）／Ｘの計算式から求める。ステップ１３へ進む。
【００４２】
ステップ１３では、ファイル転送制御部の処理の負荷を軽減するため、処理を１秒に一回に制限するために、１秒のウェイトを置き、ステップ２へ遷移する。
【００４３】
ステップ３では、データ受信時の過去Ｘ秒のスループットが回線状況良好と判定するスループットの最小値よりも大きいか否かを判定する。具体的には、Ｓ＞Ｓｍｉｎを判定し、真なら、一時的な回線またはサーバ障害の疑いありと判定し、ステップ４に進む。偽なら、回線状況が良好でないと判定し、ステップ９に進む。
【００４４】
ステップ４では、ここに遷移するのは高スループット状態でのデータ受信連続失敗が一回増加した場合であるから、Ｆを１インクリメントする。すなわち、Ｆ＝Ｆ＋１の演算を行う。
【００４５】
ステップ５では、高スループット状態でのデータ受信連続失敗が、高スループット状態でのデータ受信連続許容失敗回数以上に達したかを判定する。具体的には、Ｆ≧Ｆｍｉｎを判定し、真なら、一時的な回線またはサーバ障害発生と判定し、ステップ６に進む。偽なら、ステップ９に進む。
【００４６】
ステップ６では、Ｔｌのウェイトタイマー値のウェイトを置く。そしてステップ１０に進む。
【００４７】
ステップ９では、Ｔｓのウェイトタイマー値のウェイトを置く。そしてステップ１０に進む。
【００４８】
ステップ１０において、ファイル転送制御部は、ファイル転送実行部に対してダウンロード再開指示を出し、Ｔｉｍｅ＝０にセットし、ステップ２に進む。
【００４９】
図２は、本実施形態のファイル転送実行部の動作を示すフローチャートである。
【００５０】
本実施形態のファイル転送実行部は、図２に示すように、ステップＡは処理のスタート（ＳＴＡＲＴ）である。これは、ファイル転送制御部から、ダウンロード開始指示を受信することにより、スタートする。この時、ステータスコードファイルは消去し、ステップＢに進む。
【００５１】
ステップＢで、ファイルのダウンロードを試みる。ステップＣに進む。
【００５２】
ステップＣで、ダウンロードエラーが発生したか否かを判定する。ダウンロードエラーが発生していたら、ステップＨに進む。エラーが発生しておらず、ダウンロードが正常に行えた場合は、ステップＤに進む。
【００５３】
ステップＤで、受信したデータをファイルに格納し、再開指示の場合は、従来ダウンロードしたファイルの後ろにデータをアペンドする。ステップＥに進む。
【００５４】
ステップＥで、受信したファイルのデータ長をダウンロード済みファイルサイズファイルに格納し、ステップＦに進む。
【００５５】
ステップＦでは、ダウンロードが完了したか否かを判定する。ダウンロードが完了していたらステップＧに進む。ダウンロードが未完了の場合は、ステップＢに進む。
【００５６】
ステップＧでは、ステータスコードファイルに正常終了を示す情報を書き込み、処理を終了する。
【００５７】
ステップＨでは、ステータスコードファイルにエラー終了を示す情報を書き込み、処理を終了する。
【００５８】
次に、ファイル転送制御部、ファイル転送実行部、ポータルの各ノード間のシーケンスチャートの例を図３、図４、図５に示す。ポータルは、ダウンロードするコンテンツが格納されているサーバである。
【００５９】
図３は、中断が一度も発生せずに正常終了した場合のシーケンスであり、図４は、中断が１回発生したが、次の再開で復旧して、正常終了の場合のシーケンスである。図５は、途中で中断し、そのまま時間切れの場合のシーケンスチャートである。
【００６０】
（実施例１）
本実施形態の実施例１は、ダウンロードクライアントソフトウェアがサーバからデータを受信し、ダウンロードエラーが発生しなかった場合の処理の流れの実施例である。
【００６１】
本実施例１においての各種条件は、
・コンテンツのファイルサイズ＝８０００ＫＢ＝６４０００ｂｉｔ
・回線帯域が６４ｋｂｉｔ／ｓｅｃ
・Ｔｌ＝６０ｓｅｃ
・Ｔｓ＝１０ｓｅｃ
・Ｓｍｉｎ＝４０（ｋｂｉｔ／ｓｅｃ）
・Ｆｍｉｎ＝２（回）
・Ｘ＝３０ｓｅｃ
・Ｘｔｉｍｅｒ＝５ｓｅｃ
・ダウンロード実行部のダウンロードプロトコル：ＨＴＴＰプロトコルによるダウンロード
である。以下、前記図１及び図２のフローチャートについてファイル転送実行部及びファイル転送制御部の処理の流れを時系列的に説明する。
【００６２】
（ファイル転送実行部の動作）
図２に示すように、ファイル転送制御部からのダウンロード開始指示を受けると処理を開始し、ステップＢに進みＨＴＴＰプロトコルによるダウンロードを実行する。ステップＣに進む。
【００６３】
ステップＣでは、ダウンロードエラー発生の判定を行う。ここでは、エラーが発生しなかったので、ステップＤに進む。
【００６４】
ステップＤで、受信したデータをファイルに格納し、ステップＥで、受信したデータ長をダウンロード済ファイルサイズファイルに格納し、ステップＦに進む。ステップＦではダウンロードが完了したか否かを判定するが、ここでは、まだダウンロードが完了していないので、ステップＢに戻る。
【００６５】
ここで、ステップＢ→ステップＣ→ステップＤ→ステップＥ→ステップＦ→ステップＢを繰り返す。
【００６６】
ここで、繰り返し処理の間、その時点で、ダウンロード済みファイルの容量（＝ダウンロード済みファイルサイズファイルの内容）は、単調に増えていく。すなわち、
Ｔｉｍｅ＝０ｓｅｃの時は、０ｋｂｉｔ
Ｔｉｍｅ＝１ｓｅｃの時は、６４ｋｂｉｔ
Ｔｉｍｅ＝５ｓｅｃの時は、３２０ｋｂｉｔ
Ｔｉｍｅ＝１０ｓｅｃの時は、６４０ｋｂｉｔ
Ｔｉｍｅ＝３０ｓｅｃの時は、１９２０ｋｂｉｔ
Ｔｉｍｅ＝３５ｓｅｃの時は、２２４０ｋｂｉｔ
Ｔｉｍｅ＝１００ｓｅｃの時は、６４００ｋｂｉｔ
Ｔｉｍｅ＝９６５ｓｅｃの時に、６１７６０ｋｂｉｔ
Ｔｉｍｅ＝９９５ｓｅｃの時に、６３６８０ｋｂｉｔである。Ｔｉｍｅ＝１０００ｓｅｃの時に、６４０００ｋｂｉｔとなり、ステップＦのダウンロード完了判定で、ダウンロード完了と判定し、ステップＧに進み、ステータスコードファイルをクリエイトして正常終了を示す情報を書込み、ファイル転送実行部の処理を終了する。
【００６７】
（ファイル転送制御部の動作）
図１において、ステップ０でＳ＝０、Ｆ＝０と設定する。ステップ１に進む。
【００６８】
ステップ１において、ファイル転送制御部は、ファイル転送実行部に対してダウンロード開始指示を出し、Ｔｉｍｅを０ｓｅｃに設定し、ステップ２に進む。
【００６９】
ステップ２では、ダウンロードの状況を判定する。ダウンロード状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。この時点ではダウンロードが終了していないので、ステータスコードファイルが生成されていないので、データを受信成功し、かつ、残りのデータがあると判定し、ステップ７に進む。
【００７０】
ステップ７では、データの受信が成功しているため変数Ｆを０にセットしステップ１１に進む。
【００７１】
ステップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、Ｔｉｍｅ＝０、Ｘ＝３０であるため、偽と判定されステップ１３へ遷移する。ステップ１３で１秒のウェイトを置き、ステップ２へ遷移する。
【００７２】
以下、Ｔｉｍｅ＝３０まで、ステップ２→ステップ７→ステップ１１→ステップ１３の処理を繰り返す。Ｔｉｍｅ＝３０における、ステップ１１の処理でＴｉｍｅ＝３０、Ｘ＝３０であるため、真と判定されステップ１２へ遷移する。
【００７３】
ステップ１２では、ダウンロード時間（Ｔｉｍｅ）が、スループットの測定タイミングであるかを判定する。すなわち、Ｔｉｍｅが、Ｘｔｉｍｅｒの整数倍か否かを判定する。具体的には、（Ｔｉｍｅ）ｍｏｄ（Ｘｔｉｍｅｒ）＝０を判定する。ここでは、３０ｍｏｄ５＝０なので、真と判定し、ステップ８に進む。
【００７４】
ステップ８では、過去Ｘ秒の平均スループットを計算してＳとして保持する。平均スループットは、（ダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分）／Ｘの計算式から求めるが、ここでは、ファイル転送実行部のダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分は１９２０ｋｂｉｔ−０ｋｂｉｔ＝１９２０ｋｂｉｔなので、１９２０ｋｂｉｔ／３０ｓｅｃ＝６４（ｋｂｉｔ／ｓｅｃ）となる。ステップ１３に進む。ステップ１３では、１秒のウェイトを置き、ステップ２へ遷移する。
【００７５】
ステップ２では、ダウンロードの状況を判定する。ダウンロード状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。この時点ではダウンロードが終了していないので、ステータスコードファイルが生成されていないので、データを受信成功し、かつ残りのデータがあると判定しステップ７に進む。
【００７６】
ステップ７では、データの受信が成功しているため変数Ｆを０にセットしステップ１１に進む。ステップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、Ｔｉｍｅ＝３１、Ｘ＝３０であるため、真と判定されステップ１２へ遷移する。
【００７７】
ステップ１２では、ダウンロード時間（Ｔｉｍｅ）が、スループットの測定タイミングであるかを判定する。ここでは、３１ｍｏｄ５＝１なので、偽と判定し、ステップ１３に進む。
【００７８】
以下、Ｔｉｍｅ＝３５までステップ２→ステップ７→ステップ１１→ステップ１２→ステップ１３の処理を繰り返す。
【００７９】
Ｔｉｍｅ＝３５におけるステップ１２の処理で３５ｍｏｄ５＝０なので、真と判定し、ステップ８に進む。ステップ８では、過去Ｘ秒の平均スループットを計算してＳとして保持する。平均スループットは、（ダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分）／Ｘの計算式から求めるが、ここでは、ファイル転送実行部のダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分は２２４０ｋｂｉｔ−３２０ｋｂｉｔ＝１９２０ｋｂｉｔなので、１９２０ｋｂｉｔ／３０ｓｅｃ＝６４（ｋｂｉｔ／ｓｅｃ）となる。ステップ１３に進む。
【００８０】
ステップ１３では、ファイル転送制御部の処理の負荷を軽減するため、処理を１秒に一回に制限するために、１秒のウェイトを置き、ステップ２へ遷移する。
【００８１】
以下、同様にステップ２〜ステップ１３処理を行い、Ｔｉｍｅ＝９９５となったとする。
【００８２】
ステップ２では、ダウンロードの状況を判定する。ダウンロード状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。この時点ではダウンロードが終了していないので、ステータスコードファイルが生成されていないので、データを受信成功し、かつ残りのデータがあると判定しステップ７に進む。
【００８３】
ステップ７では、データの受信が成功しているため変数Ｆを０にセットしステップ１１に進む。ステップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、Ｔｉｍｅ＝９９５、Ｘ＝３０であるため、真と判定されステップ１２へ遷移する。
【００８４】
ステップ１２では、ダウンロード時間（Ｔｉｍｅ）が、スループットの測定タイミングであるかを判定する。ここでは、９９５ｍｏｄ５＝０なので真と判定し、ステップ８に進む。ステップ８では、過去Ｘ秒の平均スループットを計算してＳとして保持する。平均スループットは、（ダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分）／Ｘの計算式から求めるが、ここでは、ファイル転送実行部のダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分は６３６８０ｋｂｉｔ−６１７６０ｋｂｉｔ＝１９２０ｋｂｉｔなので、１９２０ｋｂｉｔ／３０ｓｅｃ＝６４（ｋｂｉｔ／ｓｅｃ）となる。ステップ１３に進む。
【００８５】
ステップ１３では、ファイル転送制御部の処理の負荷を軽減するため、処理を１秒に一回に制限するために、１秒のウェイトを置き、ステップ２へ遷移する。
【００８６】
ステップ２では、ダウンロードの状況を判定する。ダウンロード状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。この時点ではダウンロードが終了していないので、ステータスコードファイルが生成されていないので、データを受信成功し、かつ残りのデータがあると判定しステップ７に進む。
【００８７】
ステップ７では、データの受信が成功しているため変数Ｆを０にセットしステップ１１に進む。ステップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、Ｔｉｍｅ＝９９６、Ｘ＝３０であるため、真と判定されステップ１２へ遷移する。
【００８８】
ステップ１２では、ダウンロード時間（Ｔｉｍｅ）が、スループットの測定タイミングであるかを判定する。ここでは、９９６ｍｏｄ５＝１なので、偽と判定し、ステップ１３に進む。ステップ１３で１秒のウェイトを置き、ステップ２へ遷移する。
【００８９】
以下、Ｔｉｍｅ＝９９９までステップ２→ステップ７→ステップ１１→ステップ１２→ステップ１３の処理を繰り返す。
【００９０】
Ｔｉｍｅ＝９９９におけるステップ１３の処理後、Ｔｉｍｅ＝１０００になった時点でステップ２に進む。
【００９１】
ステップ２では、ダウンロードの状況を判定する。ダウンロード状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。この時点で、ダウンロードが終了しているので、ステータスコードファイルが正常終了なためデータを全て受信完了と判定し、ファイル転送処理部の処理を終了する。
【００９２】
（実施例２）
本実施形態の実施例２は、ダウンロードクライアントソフトウェアがサーバからデータを受信し、ダウンロードエラーが発生した場合の処理の流れの例である。本実施例２は、平均スループットが６４ｋｂｉｔ／ｓｅｃの場合である。
本実施例２においての各種条件は、
・コンテンツのファイルサイズ＝８０００ＫＢ＝６４０００ｂｉｔ
・回線帯域が６４ｋｂｉｔ／ｓｅｃ
・Ｔｌ＝６０ｓｅｃ
・Ｔｓ＝１０ｓｅｃ
・Ｓｍｉｎ＝４０（ｋｂｉｔ／ｓｅｃ）
・Ｆｍｉｎ＝２（回）
・Ｘ＝３０ｓｅｃ
・Ｘｔｉｍｅｒ＝５ｓｅｃ
・ダウンロード実行部のダウンロードプロトコル：ＨＴＴＰプロトコルによるダウンロード
・Ｔｉｍｅ＝３５の時点でダウンロードが２回連続して失敗し、その後、再開に成功した場合である。
【００９３】
以下、図１及び図２のフローチャートについてファイル転送実行部及びファイル転送制御部の処理の流れを時系列的に説明する。
【００９４】
（ファイル転送実行部の動作）
図２に示すように、ファイル転送制御部からのダウンロード開始指示を受けると処理を開始し、ステップＢに進みＨＴＴＰプロトコルによるダウンロードを実行する。ステップＣに進む。
【００９５】
ステップＣでは、ダウンロードエラー発生の判定を行う。ここでは、エラーが発生しなかったので、ステップＤに進む。
【００９６】
ステップＤで、受信したデータをファイルに格納し、ステップＥで、受信したデータ長をダウンロード済ファイルサイズファイルに格納し、ステップＦに進む。ステップＦではダウンロードが完了したか否かを判定するが、ここでは、まだダウンロードが完了していないので、ステップＢに戻る。
【００９７】
ここで、ステップＢ→ステップＣ→ステップＤ→ステップＥ→ステップＦ→ステップＢをＴｉｍｅ＝３５まで繰り返す。
【００９８】
前記繰り返し処理の間、その時点で、ダウンロード済みファイルの容量（＝ダウンロード済みファイルサイズファイルの内容）は、単調に増えていく。すなわち、
Ｔｉｍｅ＝０ｓｅｃの時は、０ｋｂｉｔ
Ｔｉｍｅ＝１ｓｅｃの時は、６４ｋｂｉｔ
Ｔｉｍｅ＝５ｓｅｃの時は、３２０ｋｂｉｔ
Ｔｉｍｅ＝１０ｓｅｃの時は、６４０ｋｂｉｔ
Ｔｉｍｅ＝３０ｓｅｃの時は、１９２０ｋｂｉｔ
Ｔｉｍｅ＝３５ｓｅｃの時は、２２４０ｋｂｉｔ
である。
【００９９】
Ｔｉｍｅ＝３５のステップＣの時点でダウンロードエラーが発生したので、ステップＨに遷移し、ステータスコードファイルにエラー終了を示す情報を書込み、一旦処理を終了する。
【０１００】
ファイル転送制御部からのダウンロード再開指示を受けると処理を開始し、ステップＢにすすみＨＴＴＰプロトコルによるダウンロードを実行する。ステップＣに進む。
【０１０１】
ステップＣでは、もう一度エラーが発生したので、ステップＨに遷移し、ステータスコードファイルにエラー終了を示す情報を書込み、一旦処理を終了する。
【０１０２】
ファイル転送制御部からのダウンロード再開指示を受けると処理を開始し、ステップＢにすすみＨＴＴＰプロトコルによるダウンロードを実行する。ステップＣに進む。
【０１０３】
ステップＣでは、ダウンロードエラー発生の判定を行う。ここでは、エラーが発生しなかったので、ステップＤに進む。
【０１０４】
ステップＤで、受信したデータを前回中断したファイルの後ろに追記する形で格納し、ステップＥで、今回の再開処理で受信したデータ長をダウンロード済ファイルサイズファイルに格納し、ステップＦに進む。ステップＦではダウンロードが完了したか否かを判定するが、ここでは、まだダウンロードが完了していないので、ステップＢに戻る。
【０１０５】
ここで、ステップＢ→ステップＣ→ステップＤ→ステップＥ→ステップＦ→ステップＢをＴｉｍｅ＝９６５まで繰り返す。
【０１０６】
Ｔｉｍｅ＝０ｓｅｃの時は、０ｋｂｉｔ
Ｔｉｍｅ＝３０ｓｅｃの時は、１９２０ｋｂｉｔ
Ｔｉｍｅ＝９３０ｓｅｃの時に、５９５２０ｋｂｉｔ
Ｔｉｍｅ＝９６０ｓｅｃの時に、６１４４０ｋｂｉｔ
となり、ステップＦのダウンロード完了判定で、ダウンロード完了と判定し、ステップＧに進み、ステータスコードファイルをクリエイトして正常終了を示す情報を書込み、ファイル転送実行部の処理を終了する。
【０１０７】
（ファイル転送制御部の動作）
図１に示すように、ステップ０でＳ＝０、Ｆ＝０と設定する。ステップ１に進む。ステップ１において、ファイル転送制御部は、ファイル転送実行部に対してダウンロード開始指示を出し、Ｔｉｍｅを０ｓｅｃに設定し、ステップ２に進む。
【０１０８】
ステップ２では、ダウンロードの状況を判定する。ダウンロード状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。この時点ではダウンロードが終了していないので、ステータスコードファイルが生成されていないので、データを受信成功し、かつ残りのデータがあると判定しステップ７に進む。
【０１０９】
ステップ７では、データの受信が成功しているため変数Ｆを０にセットしステップ１１に進む。ステップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、Ｔｉｍｅ＝０、Ｘ＝３０であるため、偽と判定されステップ１３へ遷移する。ステップ１３で１秒のウェイトを置き、ステップ２へ遷移する。
【０１１０】
以下、Ｔｉｍｅ＝３０まで、ステップ２→ステップ７→ステップ１１→ステップ１３の処理を繰り返す。Ｔｉｍｅ＝３０におけるステップ１１の処理でＴｉｍｅ＝３０、Ｘ＝３０であるため、真と判定されステップ１２へ遷移する。
【０１１１】
ステップ１２では、ダウンロード時間（Ｔｉｍｅ）が、スループットの測定タイミングであるかを判定する。すなわち、Ｔｉｍｅが、Ｘｔｉｍｅｒの整数倍か否かを判定する。具体的には、（Ｔｉｍｅ）ｍｏｄ（Ｘｔｉｍｅｒ）＝０を判定する。ここでは、３０ｍｏｄ５＝０なので、真と判定し、ステップ８に進む。
【０１１２】
ステップ８では、過去Ｘ秒の平均スループットを計算してＳとして保持する。平均スループットは、（ダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分）／Ｘの計算式から求めるが、ここでは、ファイル転送実行部のダウンロード済みファイルサイズの過去Ｘ秒の増加分は、１９２０ｋｂｉｔ−０ｋｂｉｔ＝１９２０ｋｂｉｔなので、１９２０ｋｂｉｔ／３０ｓｅｃ＝６４（ｋｂｉｔ／ｓｅｃ）となる。これをＳとして保持する。ステップ１３に進む。ステップ１３では、１秒のウェイトを置き、ステップ２へ遷移する。
【０１１３】
ステップ２では、ダウンロードの状況を判定する。ダウンロードの状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。この時点ではダウンロードが終了していないので、ステータスコードファイルが生成されていないので、データを受信成功し、かつ残りのデータがあると判定し、ステップ７に進む。
【０１１４】
ステップ７では、データの受信が成功しているため、変数Ｆを０にセットしステップ１１に進む。
【０１１５】
ステップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、Ｔｉｍｅ＝３１、Ｘ＝３０であるため、真と判定されステップ１２へ遷移する。ステップ１２では、ダウンロード時間（Ｔｉｍｅ）が、スループットの測定タイミングであるかを判定する。ここでは、３１ｍｏｄ５＝１なので、偽と判定し、ステップ１３に進む。
【０１１６】
以下、Ｔｉｍｅ＝３５までステップ２→ステップ７→ステップ１１→ステップ１２→ステップ１３の処理を繰り返す。
【０１１７】
Ｔｉｍｅ＝３５におけるステップ２では、ダウンロードの状況を判定する。ダウンロード状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。この時点で、ダウンロードが終了しているので、ステータスコードファイルがエラー終了であるためデータを受信失敗と判定し、ステップ３へ遷移する。
【０１１８】
ステップ３では、データ受信時の過去Ｘ秒のスループットが回線状況良好と判定するスループットの最小値よりも大きいか否かを判定する。具体的には、Ｓ＞Ｓｍｉｎを判定する。ここでは、６４（ｋｂｉｔ／ｓｅｃ）＞４０（ｋｂｉｔ／ｓｅｃ）が真なので、一時的な回線またはサーバ障害の疑いありと判定し、ステップ４に進む。ステップ４では、ここに遷移するのは高スループット状態でのデータ受信連続失敗が一回増加した場合であるから、Ｆを１インクリメントする。すなわち、Ｆ＝０＋１＝１となり、Ｆに１をセットし、ステップ５に遷移する。
【０１１９】
ステップ５では、高スループット状態でのデータ受信連続失敗が、高スループット状態でのデータ受信連続許容失敗回数以上に達したかを判定する。具体的には、Ｆ≧Ｆｍｉｎを判定する。ここでは、１≧２が偽なので、ステップ９に進む。
【０１２０】
ステップ９では、Ｔｓ＝１０秒のウェイトタイマー値のウェイトを置く。そしてステップ１０に進む。ステップ１０において、ファイル転送制御部は、ファイル転送実行部に対してダウンロード再開支持を出し、Ｔｉｍｅ＝０にセットし、ステップ２に進む。
【０１２１】
Ｔｉｍｅ＝０におけるステップ２では、ダウンロードの状況を判定できる。ダウンロード状況の判定は、ファイル転送実行部からのステータスコードファイルを読み出すことにより行う。この時点で、ダウンロードが終了しているので、ステータスコードファイルがエラー終了なためデータを受信失敗と判定し、ステップ３へ遷移する。
【０１２２】
ステップ３では、データ受信時の過去Ｘ秒のスループットが回線状況良好と判定するスループットの最小値よりも大きい否かを判定する。具体的には、Ｓ＞Ｓｍｉｎを判定する。ここでは、６４（ｋｂｉｔ／ｓｅｃ）＞４０（ｋｂｉｔ／ｓｅｃ）が真なので、一時的な回線またはサーバ障害の疑いありと判定し、ステップ４に進む。
【０１２３】
ステップ４では、ここに遷移するのは、高スループット状態でのデータ受信連続失敗が一回増加した場合であるから、Ｆを１インクリメントする。すなわち、Ｆ＝１＋１＝２となり、Ｆに２をセットし、ステップ５に遷移する。
【０１２４】
ステップ５では、高スループット状態でのデータ受信連続失敗が、高スループット状態でのデータ受信連続失敗許容失敗回数以上に達したかを判定する。具体的には、Ｆ≧Ｆｍｉｎを判定する。ここでは、２≧２が真なので、一時的な回線またはサーバ障害発生と判定し、ステップ６に進む。
【０１２５】
ステップ６では、Ｔｌ＝６０秒のウェイトタイマー値のウェイトを置く。そしてステップ１０に進む。ステップ１０において、ファイル転送制御部は、ファイル転送実行部に対してダウンロード再開指示を出し、Ｔｉｍｅ＝０にセットし、ステップ２に進む。
【０１２６】
ステップ２では、ダウンロードの状況を判定する。ダウンロード状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。この時点ではダウンロードが終了していないので、ステータスコードファイルが生成されていないので、データを受信成功し、かつ、残りのデータがあると判定しステップ７に進む。
【０１２７】
ステップ７では、データの受信が成功しているため変数Ｆを０にセットしステップ１１に進む。ステップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、Ｔｉｍｅ＝０、Ｘ＝３０であるため、偽と判定されステップ１３へ遷移する。ステップ１３で１秒のウェイトを置き、ステップ２へ遷移する。
【０１２８】
以下、Ｔｉｍｅ＝３０まで、ステップ２→ステップ７→ステップ１１→ステップ１３の処理を繰り返す。Ｔｉｍｅ＝３０における、ステップ１１の処理でＴｉｍｅ＝３０、Ｘ＝３０であるため、真と判定されステップ１２へ遷移する。
【０１２９】
ステップ１２では、ダウンロード時間（Ｔｉｍｅ）が、スループットの測定タイミングであるかを判定する。すなわち、Ｔｉｍｅが、Ｘｔｉｍｅｒの整数倍か否かを判定する。具体的には、（Ｔｉｍｅ）ｍｏｄ（Ｘｔｉｍｅｒ）＝０を判定する。ここでは、１０ｍｏｄ５＝０なので、真と判定し、ステップ８に進む。
【０１３０】
ステップ８では、過去Ｘ秒の平均スループットを計算してＳとして保持する。平均スループットは、（ダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分）／Ｘの計算式から求めるが、ここでは、ファイル転送実行部のダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分は、１９２０ｋｂｉｔ−０ｋｂｉｔ＝１９２０ｋｂｉｔなので、１９２０ｋｂｉｔ／３０ｓｅｃ＝６４（ｋｂｉｔ／ｓｅｃ）となる。ステップ１３に進む。ステップ１３では、１秒のウェイトを置き、ステップ２へ遷移する。
【０１３１】
ステップ２では、ダウンロードの状況を判定する。ダウンロード状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。この時点ではダウンロードが終了していないので、ステータスコードファイルが生成されていないので、データを受信成功し、かつ、残りのデータがあると判定しステップ７に進む。
【０１３２】
ステップ７では、データの受信が成功しているため変数Ｆを０にセットしステップ１１に進む。ステップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、Ｔｉｍｅ＝３１、Ｘ＝３０であるため、真と判定されステップ１２へ遷移する。
【０１３３】
ステップ１２では、ダウンロード時間（Ｔｉｍｅ）が、スループットの測定タイミングであるかを判定する。ここでは、３１ｍｏｄ５＝１なので、偽と判定し、ステップ１３に進む。
【０１３４】
以下、Ｔｉｍｅ＝３５までステップ２→ステップ７→ステップ１１→ステップ１２→ステップ１３の処理を繰り返す。Ｔｉｍｅ＝３５におけるステップ１２の処理で３５ｍｏｄ５＝０なので、真と判定し、ステップ８に進む。ステップ８では、過去Ｘ秒の平均スループットを計算してＳとして保持する。
【０１３５】
平均スループットは、（ダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分）／Ｘの計算式から求めるが、ここでは、ファイル転送実行部のダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分は２２４０ｋｂｉｔ−３２０ｋｂｉｔ＝１９２０ｋｂｉｔなので、１９２０ｋｂｉｔ／３０ｓｅｃ＝６４（ｋｂｉｔ／ｓｅｃ）となる。ステップ１３に進む。
【０１３６】
ステップ１３では、ファイル転送制御部の処理の負荷を軽減するため、処理を１秒に一回に制限するために、１秒のウェイトを置き、ステップ２へ遷移する。
【０１３７】
以下、同様にステップ２〜ステップ１３処理を行い、Ｔｉｍｅ＝９５５となったとする。
【０１３８】
ステップ２では、ダウンロードの状況を判定する。ダウンロード状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。この時点ではダウンロードが終了していないので、ステータスコードファイルが生成されていないので、データを受信成功し、かつ残りのデータがあると判定しステップ７に進む。
【０１３９】
ステップ７では、データの受信が成功しているため変数Ｆを０にセットしステップ１１に進む。ステップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、Ｔｉｍｅ＝９６０、Ｘ＝３０であるため、真と判定されステップ１２へ遷移する。ステップ１２では、ダウンロード時間（Ｔｉｍｅ）が、スループットの測定タイミングであるかを判定する。ここでは、９６０ｍｏｄ５＝０なので真と判定し、ステップ８に進む。
【０１４０】
ステップ８では、過去Ｘ秒の平均スループットを計算してＳとして保持する。平均スループットは、（ダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分）／Ｘの計算式から求めるが、ここでは、ファイル転送実行部のダウンロード済みファイルサイズファイルの過去Ｘ秒の増加分は６１４４０ｋｂｉｔ−５９５２０ｋｂｉｔ＝１９２０ｋｂｉｔなので、１９２０ｋｂｉｔ／３０ｓｅｃ＝６４（ｋｂｉｔ／ｓｅｃ）となる。ステップ１３に進む。ステップ１３では、ファイル転送制御部の処理の負荷を軽減するため、処理を１秒に一回に制限するために、１秒のウェイトを置き、ステップ２へ遷移する。
【０１４１】
ステップ２では、ダウンロードの状況を判定する。ダウンロード状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。この時点ではダウンロードが終了していないので、ステータスコードファイルが生成されていないので、データを受信成功し、かつ、残りのデータがあると判定しステップ７に進む。ステップ７では、データの受信が成功しているため変数Ｆを０にセットしステップ１１に進む。
【０１４２】
ステップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、Ｔｉｍｅ＝９６１、Ｘ＝３０であるため、真と判定されステップ１２へ遷移する。ステップ１２では、ダウンロード時間（Ｔｉｍｅ）が、スループットの測定タイミングであるかを判定する。ここでは、９６１ｍｏｄ５＝１なので、偽と判定し、ステップ１３に進む。ステップ１３で１秒のウェイトを置き、ステップ２へ遷移する。
【０１４３】
以下、Ｔｉｍｅ＝９６４までステップ２→ステップ７→ステップ１１→ステップ１２→ステップ１３の処理を繰り返す。Ｔｉｍｅ＝９６４におけるステップ１３の処理後、Ｔｉｍｅ＝９６５になった時点でステップ２に進む。
【０１４４】
ステップ２では、ダウンロードの状況を判定する。ダウンロード状況の判定は、ファイル転送実行部からステータスコードファイルを読み出すことにより行う。この時点で、ダウンロードが終了しているので、ステータスコードファイルが正常終了なためデータを全て受信完了と判定し、ファイル転送処理部の処理を終了する。
【０１４５】
（実施例３）
以下、前記本発明の帯域が保証されていないデータ配信システム（ネットワーク）における、ファイル転送の中断再開が可能なダウンロード方法の処理手順のを、コンピュータが実行するためのプログラムを記憶した記憶媒体を、音楽配信サービスシステムヘ適用した場合の実施例３を記述する。
【０１４６】
（実施例３において使用する通信ノード）
本実施例３においては、以下の５つを通信ノードとする。
・ユーザ登録端末（以下ユーザ登録端末）
・予約端末（以下予約端末）
・お客様のＰＣ（以下ＰＣ）
・ホームゲートウェイ（以下ＨＧＷ）
・音楽配信ポータルサイト（以下ポータル）
である。各通信ノード間は、ＴＣＰ／ＩＰのネットワークで接続されている。
【０１４７】
ユーザ登録端末及び予約端末は、ポータルにインターネット経由で接続できることだけが、必要要件である。
【０１４８】
ＰＣはＬＡＮ（ＴＣＰ／ＩＰ）でＨＧＷに接続され、一台のＨＧＷに一台のＰＣではなく複数のＰＣが接続することもあり得る。但し、本実施例３では、一台のＰＣが接続されているものとして説明する。
【０１４９】
ＨＧＷは、インターネットを介してポータルに接続し、複数のＨＧＷが存在する。本実施例３では、そのうちの１つのＨＧＷに着目して説明する。
【０１５０】
ポータルはインターネット上に１つのみとする。ポータルは音楽コンテンツダウンロードサービスを提供している。
【０１５１】
（本音楽配信サービスシステムのポイント）
本音楽配信サービスシステムは、お客様がポータルから音楽コンテンツを取得することを目的としている。
【０１５２】
本音楽配信サービスシステムは、単にお客様のＰＣ上のダウンロードソフトで、音楽コンテンツが存在するポータルからコンテンツをダウンロードするのではなく、ポータルにコンテンツの配信を予約すると決まった時間にポータルからＨＧＷにコンテンツを配信してくれて、予約したお客様だけがＨＧＷに蓄積されたコンテンツを取り出せるという特徴を持つ。但し、ポータルからＨＧＷへのデータ配信は、ＨＧＷがポータルからデータをダウンロードすることにより実現している。
【０１５３】
以下、お客様がコンテンツを予約してからデータを取り出すまでのシーケンスをＨＧＷが１つで、ユーザがひとりの場合を例に説明する。次に、予約したお客様だけがＨＧＷに蓄積されたコンテンツを取り出せるためのユーザＩＤ認証方法を複数のユーザが存在する事象で説明する。
【０１５４】
本実施例３においても、ダウンロードの中断再開タイマー値を可変とし、データダウンロード実行中の平均スループットをパラメータとして中断再開タイマー値を制御して、無駄なトラフィックを抑制しつつ、できるだけ速くダウンロードを完了させる処理を適用しているが、詳細は後述する。
【０１５５】
（音楽の予約配信サービスにおける時系列的な処理）
以下、音楽の予約配信サービスにおける時系列的な処理の説明を行う。
以下の項番において、１．３．１．と１．３．２（１．３．２．１．１．３．２．２）については、準備処理であり、これらの処理は時系列的にシーケンシャルでなくてもよい。また、これらの処理は、後述する予約処理の前に終わっていればよい。但し、１．３．２．１と１．３．２．２の順番はこの順番に行うことが必須である。
【０１５６】
１．３．３〜１．３．６は予約処理であり、予約端末からポータルに対する操作及びデータ送信である。これらはシーケンシャルに行う必要がある。
【０１５７】
１．３．７は配送処理であり、予約処理が終わっていることが前提である。ポータルからＨＧＷヘコンテンツを配送する仕組みを説明している。
【０１５８】
１．３．８は、コンテンツ取り出し処理であり、配送処理が終了していることが前提である。ＨＧＷからＰＣへのデータの取り出しについて説明している。
【０１５９】
これらを図示すると、図６のようになる。
【０１６０】
（１．３．１音楽コンテンツの登録）
音楽コンテンツの登録は、ポータルサイト管理者が手動で行う。管理者は、音楽コンテンツをポータルのダウンロード用コンテンツ領域に置く。また、音楽コンテンツのリスト（以下、ポータルの曲目リスト）のページを用意する。
・ポータルの曲目リストには、曲名、（アーティスト）、（レコード会社）、ファイルサイズ、（料金）を登録する。（  ）内の情報は省略可能である。
【０１６１】
（１．３．２ユーザ登録）
１．３．２．１ポータルサイトヘのユーザ登録はポータルルサイトで、音楽配信サービスのユーザ登録を行う。ユーザ登録はログインの前に予め行う必要があり、ユーザ登録端末からユーザが行う。必須で登録する項目は、以下の通りである。
・ユーザＩＤ
・パスワード
・ＨＧＷ−ＩＤ（ＨＧＷへのダウンロード先を決定するのに利用）
・接続環境（ダイヤルアップアナログ５６ｋ、ダイヤルアップアナログ２８ｋ、ダイヤルアップＩＳＤＮ６４ｋ、常時ＩＰ６４ｋ、ＬＡＮ１０Ｍ）
・利用サービス（ＩＮＳテレホーダイ、テレホーダイ１８００、テレホーダイ３６００）
なお、接続環境は、データ配信時のスループットを推定するために使用する。接続環境（ＩＳＤＮ、アナログ５６ｋ、２８ｋ…）については、ユーザが設定した値を初期値とするが、後に実行される１．３．７で実際に実行された配信処理での平均的な通信速度（配信速度）を記録しておき、それに応じて設定値を動的に変化させる方法も考えられる。
【０１６２】
以下の項目は、オプションとし、登録が望ましいが、無くても運用可能である。
・氏名
・電話番号
・連絡先メールアドレス
・ダウンロード完了通知用メールアドレス（連絡先用メールアドレスと同じか違うか選択する。違うときは入力してもらう。）
但し、ユーザＩＤは、ユーザを特定するＩＤであり、その重複は許さない。従って、各項目は、ユーザＩＤに対してバインドされる。
【０１６３】
登録方法の一例としては、前記登録項目のＷＥＢの画面をポータルからユーザが登録端末に表示し、ユーザは入力した情報を、ＨＴＴＰのＰＯＳＴコマンド等でユーザ登録端末からユーザに伝え、それを受け取ったポータルはプロファイル保存ファイルに書き込むという処理があげられる。但し、最終的に、ユーザが入力した必須項目をポータル上のプロファイル保存ファイルに書き込むことが目的であり、それができれば手段は問わない。
【０１６４】
（１．３．２．２ＨＧＷへのユーザ登録）
ＨＷＧへのユーザ登録は、１．３．２．１のポータルへのユーザ登録処理で発行されたユーザＩＤとパスワードをＨＷＧ内部のユーザ登録ファイルに保持することを目的とする処理である。
【０１６５】
ユーザ登録ファイルは、ユーザＩＤとパスワードを対にして保存される。登録方法は、前記目的を満たせれば問わないので、具体例は示さない。
【０１６６】
（１．３．３予約処理／ログイン）
ログインは、予約端末から行う。予約端末とはユーザ登録端末と同一でも良いし、別でも良い。ログイン処理では、ユーザが、予約端末から登録してあるユーザＩＤとパスワードをポータルに伝え、ポータルではプロファイル保存ファイルからユーザＩＤに対応するパスワードをチェックした上で予約サービスのユーザＩＤを特定し、正しければ音楽コンテンツ選択画面を予約端末に表示することが目的である。
【０１６７】
ログイン処理の一例としては、予約端末のＷＥＢブラウザでユーザＩＤとパスワードのダイヤログボックスをポータルから予約端末に表示し、ユーザは入力した情報をＨＴＴＰのＰＯＳＴコマンド等で予約端末からポータルに伝え、それを受け取ったポータルは、プロファイル保存ファイルからユーザＩＤに対応するパスワードをチェックし正しい場合に、ＷＥＢブラウザ上に音楽コンテンツ選択画面を表示するという処理が挙げられるが、前記目的を実現できれば、手段は問わない。
【０１６８】
（１．３．４音楽コンテンツの選択）
音楽コンテンツの選択処理は、ユーザが獲得したい音楽コンテンツの曲目をポータルに指定する処理である。音楽コンテンツの曲目を予約端末からポータルに伝え、ポータルがそれを保持し、アーカイブ処理に遷移することが目的である。
【０１６９】
音楽コンテンツの選択処理の一例としては、予約端末のＷＥＢブラウザに対して音楽コンテンツの曲目リストをポータルから予約端末に表示し、ユーザはダウンロードする曲を一曲または複数選択し、ＨＴＴＰのＰＯＳＴコマンド等で予約端末からポータルに伝え、それを受け取ったポータルは、ユーザが指定した曲を得て、アーカイブ処理に遷移するという処理が挙げられるが、前記処理を実現できれば、手段は問わない。
【０１７０】
（１．３．５アーカイブ処理）
ポータルが、１．３．４で指定されたひとつまたは複数の音楽コンテンツを、ひとまとめにしてアーカイブしてそのＵＲＬとファイルの実体を保持し、配信ポリシーの指定画面に遷移することがアーカイブ処理の目的である。アーカイブ手段として、ＵＮＩＸでよく使われるｔａｒやＷｉｎｄｏｗｓでよく使われるＺＩＰ等の形式があるが、アーカイブできればアルゴリズムは問わない。
【０１７１】
以下、アーカイブ処理された音楽コンテンツをアーカイブと呼ぶ。アーカイブ処理を行う理由は、一回の配送で指定された全部の音楽コンテンツを効率的に配信することが期待されるためである。
【０１７２】
（１．３．６配信ポリシーの指定）
配信ポリシーの指定は、ユーザがポータルに配信ポリシーを指定し、その上で予約が完了したことをユーザに伝えることが目的である。配信ポリシーの指定手段として、表１の「時刻指定」の項目の項番１〜６、すなわち、「いますぐ」、「指定した時間から」、「指定した時間までに」、「一番安い時間」、「ＨＧＷの未使用時」からユーザが１つ選んでポータルに伝え、ポータルが配信ポリシーを保持することが必要である。
【０１７３】
【表１】
0003666796.tif 000002
配信ポリシーの指定処理の一例としては、予約端末のＷＥＢブラウザに対して表１の配信ポリシー表をポータルから予約端末に表示し、ユーザは配信ポリシーを１つ選択し、ＨＴＴＰのＰＯＳＴコマンド等で予約端末からポータルに伝え、それを受け取ったポータルは、ユーザが指定した配信ポリシーを決定し、ポータルは予約端末のＷＥＢブラウザに対して、予約を受け付けたことを表示するという処理が挙げられるが、上記目的を実現できれば、手段は問わない。
【０１７４】
以下、決定された配信ポリシーに従って、１．３．６．１〜１．３．６．４の処理のいずれかを実行する。これらの処理のポイントは、配信開始時刻を設定することである。その後、１．３．７の処理に遷移する。１．３．６．１今すぐ、配信開始時刻を指定無しと設定する。配信終了期限は指定無しとする。１．３．６．２指定した時間から、配信開始時刻を設定された時刻に設定する。配信終了期限は指定無しとする。
【０１７５】
【表２】
0003666796.tif 000003
表２は、時刻の指定方法に応じてコンテンツに価格変化を付ける一例である。この例では、今すぐ、指定した時間からの場合は通常のコンテンツ価格に対して１０％の割り増し料金をとり、一番安い時間を指定した場合は、１５％割引する。
【０１７６】
本価格変化の手法を時刻の指定方法と併用することにより、ユーザヘの配信時刻は平滑化サーバ及びネットワークの負荷分散が行え、サーバ及びネットワークコストが安くできるので、安価な設備でサーバ設備を構築できる。
【０１７７】
なお、これは現実の物流システムに例えるならば、宅配便において到着時間を指定して、荷物の配送を依頼する時間指定配送サービスなどと同じである。
【０１７８】
通常、コンテンツをダウンロードする際はユーザが配信開始時刻を指定する。本手法においては、ユーザが指定した範囲内でサーバが配信時刻を指定する。
【０１７９】
これにより、ユーザの指定範囲によりサーバ側の配信開始時刻を設定する際の自由度は変動する。例えば、ユーザが「３日以内に」といった大まかな時間を指定しただけならばサーバ側自由度は大きくなるが、「３日の１２時から１３時の間に」といった詳細な指定をするとサーバの自由度は小さくなる。サーバ側の自由度が大きいと、そのオーダによる負荷を自由に分散できる。サーバ側の負荷分散の観点からは、ユーザのオーダはなるべくサーバ側自由度の大きなものの方が望ましい。
【０１８０】
この点に着目し、ユーザの配信オーダを、サーバの配信時刻指定の自由度という点からとらえ、自由度の大きなオーダに対してはコンテンツの料金や通信料金を安くし、自由度の小さなオーダに対しては、それら料金を安くして提供する。
【０１８１】
宅配便の例においては、配送が集中する「翌朝９時までに配送」という指定をすると、利用者はその分の高い料金を支払う必要があり、通常の配送である「翌日中で時間指定は特にしない」という指定の際には、高い料金は必要なく通常の料金で配送が可能であるのと、同様である。
【０１８２】
１．３．６．３指定した時間までに（終了時指定配信）、アーカイブのサイズと、接続環境の平均通信速度から、配信開始時刻を決定する。
【０１８３】
（１）アーカイブの配信に必要な時間を計算する。
通信時間＝（アーカイブのサイズ）／（接続環境の平均通信速度）
（２）指定された終了時間にちょうど配信が終了する時刻を計算する。
配信開始最終時刻＝配信終了期限−通信時間
（３）配信開始最終時刻から１時間前の時刻を配信開始時刻とする。配信終了期限は、ユーザが選択した配信終了期限を設定する。
【０１８４】
１．３．６．４一番安い時間（最低コスト配信）は、多量のアーカイブの配送が同時刻に集中するのをさけるために、配信開始時刻については一定の時間帯内でランダムに指定する。
・テレホーダイ利用：テレホーダイ時間内で指定する。２３時から１時の間で配信開始時刻をランダムに指定。配信終了期限は、１時に指定。
・ＩＳＤＮ及びアナログのダイヤルアップ：２４時間以内で最も通信料の安い時間帯（最も通信料の安い時間帯の計算方法は、ユーザの利用している通信会社の通信料金テーブルを元に算出する）を考慮し、配信開始時刻をランダムに設定する。配信終了期限は指定無しとする。
・ＩＰ常時接続：２３時から１時を除いた時刻の中から配信開始時刻をランダムに指定する。配信終了期限は指定しない。
【０１８５】
以上の１．３．６．１〜１．３．６．４のいずれかで、配信開始時刻が決定される。
（１．３．７配信）
１．３．７．１ポータル（ダウンロードサーバ側）の処理は、ダウンロードすべきコンテンツを指定したメッセージとして「受取人情報、ＵＲＬ、時刻指定プル情報」をメッセージ要素として設定したファイル転送要求メッセージをＨＧＷへ送信する。各メッセージ要素には、以下の情報を格納する。
【０１８６】
（メッセージ要素名）
・受取人情報：１．３．３で特定された本サービスのユーザＩＤ（図７ではＡＡＡＡ等）を設定。
・ＵＲＬ：１．３．５で指定された、アーカイブファイルのＵＲＬを設定。
・時刻指定プル情報：１．３．６．１〜１．３．６．４のいずれかで特定された、配信開始時刻及び配信終了期限。
【０１８７】
なお、ポータルからＨＧＷへのファイル転送要求メッセージの伝達手段は、ポータルからＨＧＷヘファイルを送信する方法ではなく、特願平１０−４９７７１のテレポーリング技術により、ＨＧＷがポータルから周期的にファイル転送要求メッセージをポーリング受信する方法でもよい。
【０１８８】
（１．３．７．２ＨＧＷ（クライアント）側の処理）
▲１▼「ファイル転送要求」メッセージを受け取った場合、「時刻指定プル情報」メッセージ要素で、配信開始時刻が指定なしの場合は、即時に指定されたＵＲＬからのプルを実行する（プルの定義は後述する）。
【０１８９】
▲２▼メッセージが時間指定ダウンロード（「時刻指定プル情報」メッセージ要素に配信開始時刻が含まれる）の場合は、ＨＧＷテーブルに登録する。登録する内容は、受信したファイル転送要求メッセージ内の「受取人情報」、「ＵＲＬ」、「時刻指定プル情報」及び「ダウンロード終了ステータス」である。ダウンロード終了ステータスは初期値として１（ダウンロード待ち状態を示す）をセットする。
【０１９０】
▲３▼ＨＧＷでは、現在時刻が、時刻指定プル情報の配信開始時刻以前になったＨＧＷテーブルのレコードについて、指定されたＵＲＬからのプルを開始する。プルを開始する時点で、ダウンロード終了ステータスを２（ダウンロード中を示す）にセットする。
【０１９１】
ここで述べるプル（コンテンツセッション）は、ＨＴＴＰあるいはＦＴＰなどの一般的に用いられるプロトコルによりファイルを受信する処理である。
【０１９２】
ここでは、レジューム機能を持つプロトコルとして、ＨＴＴＰダウンロードプロトコルによりＨＧＷがファイルを受信したとする。ただし、ダウンロード時刻をすぎても完了しない場合には、プルを中止する。
【０１９３】
本実施例３では、プル処理において、ＨＧＷ（ダウンロードクライアント）がポータル（サーバ）からアーカイブ（データ）を受信し、ダウンロードエラーが発生しなかったとする。この場合、処理フローは、前記実施例１と同様である。
【０１９４】
（１．３．８コンテンツ取り出し処理）
ユーザがＨＧＷに配送されたコンテンツをＰＣに対して取り出すことが目的である。また、予約したユーザ以外がコンテンツを取り出せないことも必須である。
【０１９５】
以下、処理の一例を示す。
ユーザは、ＰＣからユーザＩＤとパスワードをＨＧＷに対して送信し、ＨＧＷはユーザ登録ファイルをもとに、ユーザＩＤとパスワードを照合する。受け取ったユーザＩＤとパスワードがユーザ登録ファイルに含まれている場合は、そのユーザＩＤを持つユーザに対して配信されているコンテンツを、取り出し端末に渡す。この後、ユーザは、ＰＣ上で、取り出し端末にあるコンテンツを自由に再生したり、編集することができる。
【０１９６】
予約したお客様だけがＨＧＷに蓄積されたコンテンツを取り出せるためのユーザＩＤ認証方法について説明する。
【０１９７】
本サービスでは、ポータルとＨＧＷの双方で利用ユーザを特定できるユーザＩＤを利用ユーザ毎に付与する。ユーザＩＤは後述のユーザ登録時にポータルにて登録するとともに、ＨＧＷ側にも同一のユーザＩＤを登録しておく必要がある。
【０１９８】
ユーザＩＤは、家庭内で複数の人が利用することを想定し、ＨＧＷに複数の設定が可能である。ポータルにおいては、ユーザＩＤ毎に配送すべきＨＧＷのＩＤをユーザ登録時に登録し、通常は注文したユーザのユーザＩＤに対して、登録されているＨＧＷのＩＤに対してＴＰＰを利用した配送が行われる。また、ＨＧＷに配送する時は、ＨＧＷに登録されているユーザＩＤ毎にコンテンツを区分して登録し、特定のユーザＩＤのユーザのみがＨＧＷに配送されたコンテンツを取り出せるようにする（図７の例）。
【０１９９】
図７に示されるＨＧＷへのユーザ登録から取り出しまでの方法について説明する。ここでは、例として、ＨＧＷ（ＨＧＷ−ＩＤが１００であるＨＧＷ、以下ＨＧＷ１）にはユーザが２名登録され、ＨＧＷ（ＨＧＷ−ＩＤが２００であるＨＧＷ、以下ＨＧＷ２）にはユーザが１名登録されることを想定する。また、ＨＧＷからコンテンツを取り出すにはＰＣなどＨＧＷに接続されているコンテンツ取り出し端末が必要である。
【０２００】
１）ＨＧＷへのユーザ登録処理
ＨＧＷには、そのＨＧＷを利用するユーザが登録されている必要がある。ＨＧＷへのユーザ登録は、ユーザのユーザＩＤとパスワードを登録する処理である。ＨＧＷでは、ユーザから入力されたユーザＩＤとパスワードをＨＧＷ内部のユーザ登録ファイルに保持する。ここで、ユーザＩＤの重複は許さない。また、ユーザ登録ファイルは、ユーザＩＤとパスワードを対にして保存される。
【０２０１】
この例においては、ＨＧＷ１においては、ユーザＩＤとしてＡＡＡＡを持つユーザ（以下ユーザＡＡＡＡ）、ユーザＩＤとしてＢＢＢＢを持つユーザ（ユーザＢＢＢＢ）の２名が登録する。
【０２０２】
ユーザＡＡＡＡは、ユーザＩＤ（ＡＡＡＡ）、パスワード
ユーザＢＢＢＢは、ユーザＩＤ（ＢＢＢＢ）、パスワード
をＨＧＷに登録する。ここで、各ユーザの登録するパスワードは任意の文字列を指定し登録出来る。
【０２０３】
ＨＧＷ２においては、ユーザＩＤとしてＣＣＣＣを持つユーザ（ユーザＣＣＣＣ）１名が登録する。ユーザＣＣＣＣは、ユーザＩＤ（ＣＣＣＣ）、パスワードをＨＧＷに登録する。
【０２０４】
２）予約配信処理
次に、ユーザが注文端末から予約したコンテンツを、ポータルからＨＧＷへ配信する処理がある。
【０２０５】
ユーザの予約の処理については、詳細は後述する。ＨＧＷへの配信処理は、例においては、ユーザＡＡＡＡは、コンテンツＡの配信を予約し、同じくユーザＢＢＢＢはコンテンツＢ、ユーザＣＣＣＣはコンテンツＣの配信を予約することを想定する。コンテンツは、予約したユーザがユーザ登録をしてあるＨＧＷへ配送される。つまり、ユーザＡＡＡＡ、ユーザＢＢＢＢはともにＨＧＷ１にユーザ登録されているので、コンテンツＡ及びコンテンツＢはＨＧＷ１に配送される。コンテンツＣは、ユーザＣＣＣＣがユーザ登録されているＨＧＷ２へ配送される。ＨＧＷへ配送されたコンテンツは、ＨＧＷに登録された各ユーザＩＤに対応して確保されているメモリエリアに蓄積される。
【０２０６】
３）ＨＧＷからのコンテンツ取り出し処理
ＨＧＷには複数のユーザが登録される場合があるため、複数ユーザが予約した複数のコンテンツが１つのＨＧＷに同時に蓄積されている。その中から、各ユーザに対して、自分の予約したコンテンツのみを取り出させる必要がある。つまり、ＨＧＷからコンテンツを取り出す際には、ＨＧＷに登録された各ユーザに自分の予約したコンテンツのみの取り出しを許可し、他ユーザの予約したコンテンツの取り出しは許可しないことになる。
【０２０７】
ＨＧＷは、ユーザがコンテンツ取り出し端末から入力したユーザＩＤとパスワードを受け取る。ＨＧＷは、受け取ったユーザＩＤとパスワードを、ユーザ登録ファイルに登録されているユーザＩＤとパスワードとを照合する。受け取ったユーザＩＤとパスワードがユーザ登録ファイルに含まれている場合は、そのユーザＩＤを持つユーザに対して配信されているコンテンツを、取り出し端末に渡す。前記の例においては、ＨＧＷ２には、ユーザはＣＣＣＣのみ１名登録されているので、ＨＧＷ２に配信され蓄積されているコンテンツＣはユーザＣＣＣＣのみが取り出せばよい。
【０２０８】
ＨＧＷ１では、ユーザはＡＡＡＡとＢＢＢＢの２名が登録されている。ＨＧＷ１に接続された取り出し端末から、ユーザＩＤとしてＡＡＡＡとパスワードを受け取ったときは、ユーザＡＡＡＡに対して配信されているコンテンツＡを取り出し端末に渡す。同様に、ユーザＩＤとしてＢＢＢＢとパスワードを受け取ったときは、ユーザＢＢＢＢに対して配信されているコンテンツＢを取り出し端末に渡す。
【０２０９】
以上、本発明者によってなされた発明を、前記実施形態（実施例）に基づき具体的に説明したが、本発明は、前記実施形態（実施例）に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【０２１０】
【発明の効果】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば、以下のとおりである。
【０２１１】
本発明によれば、クライアントとサーバの間のトラフィックを軽減できる。
【０２１２】
また、クライアントとサーバ間で有料の回線を利用する場合は、無駄な回線使用コストを軽減できる。
【図面の簡単な説明】
【図１】本発明による一実施形態（実施例）のファイル転送制御部の動作を示すフローチャートである。
【図２】本実施形態のファイル転送実行部の動作を示すフローチャートである。
【図３】本実施形態の中断が一度も発生せずに正常終了した場合のシーケンスチャートである。
【図４】本実施形態の中断が１回発生したが、次の再開で復旧して、正常終了の場合のシーケンスチャートである。
【図５】本実施形態の途中で中断し、そのまま時間切れの場合のシーケンスチャートである。
【図６】本実施形態のＨＧＷからＰＣへのデータの取り出しについて説明するための図である。
【図７】本実施形態のユーザとＨＧＷの関係を示す図である。
【図８】従来のダウンロードレジュームのアルゴリズムを示すフローチャートである。
【図１】
0003666796.tif 000004
【図２】
0003666796.tif 000005
【図３】
0003666796.tif 000006
【図４】
0003666796.tif 000007
【図５】
0003666796.tif 000008
【図６】
0003666796.tif 000009
【図７】
0003666796.tif 000010
【図８】
0003666796.tif 000011