JP3666796B2 - Download method in data distribution system and storage medium storing program thereof - Google Patents

Download method in data distribution system and storage medium storing program thereof Download PDF

Info

Publication number
JP3666796B2
JP3666796B2 JP2000214562A JP2000214562A JP3666796B2 JP 3666796 B2 JP3666796 B2 JP 3666796B2 JP 2000214562 A JP2000214562 A JP 2000214562A JP 2000214562 A JP2000214562 A JP 2000214562A JP 3666796 B2 JP3666796 B2 JP 3666796B2
Authority
JP
Japan
Prior art keywords
download
time
user
file
determined
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2000214562A
Other languages
Japanese (ja)
Other versions
JP2002032284A (en
Inventor
清志 中濱
信行 大森
博人 稲垣
隆一 斉藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2000214562A priority Critical patent/JP3666796B2/en
Publication of JP2002032284A publication Critical patent/JP2002032284A/en
Application granted granted Critical
Publication of JP3666796B2 publication Critical patent/JP3666796B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)

Description

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

Figure 0003666796
配信ポリシーの指定処理の一例としては、予約端末のＷＥＢブラウザに対して表１の配信ポリシー表をポータルから予約端末に表示し、ユーザは配信ポリシーを１つ選択し、ＨＴＴＰのＰＯＳＴコマンド等で予約端末からポータルに伝え、それを受け取ったポータルは、ユーザが指定した配信ポリシーを決定し、ポータルは予約端末のＷＥＢブラウザに対して、予約を受け付けたことを表示するという処理が挙げられるが、上記目的を実現できれば、手段は問わない。
【０１７４】
以下、決定された配信ポリシーに従って、１．３．６．１〜１．３．６．４の処理のいずれかを実行する。これらの処理のポイントは、配信開始時刻を設定することである。その後、１．３．７の処理に遷移する。１．３．６．１今すぐ、配信開始時刻を指定無しと設定する。配信終了期限は指定無しとする。１．３．６．２指定した時間から、配信開始時刻を設定された時刻に設定する。配信終了期限は指定無しとする。
【０１７５】
【表２】
Figure 0003666796
表２は、時刻の指定方法に応じてコンテンツに価格変化を付ける一例である。この例では、今すぐ、指定した時間からの場合は通常のコンテンツ価格に対して１０％の割り増し料金をとり、一番安い時間を指定した場合は、１５％割引する。
【０１７６】
本価格変化の手法を時刻の指定方法と併用することにより、ユーザヘの配信時刻は平滑化サーバ及びネットワークの負荷分散が行え、サーバ及びネットワークコストが安くできるので、安価な設備でサーバ設備を構築できる。
【０１７７】
なお、これは現実の物流システムに例えるならば、宅配便において到着時間を指定して、荷物の配送を依頼する時間指定配送サービスなどと同じである。
【０１７８】
通常、コンテンツをダウンロードする際はユーザが配信開始時刻を指定する。本手法においては、ユーザが指定した範囲内でサーバが配信時刻を指定する。
【０１７９】
これにより、ユーザの指定範囲によりサーバ側の配信開始時刻を設定する際の自由度は変動する。例えば、ユーザが「３日以内に」といった大まかな時間を指定しただけならばサーバ側自由度は大きくなるが、「３日の１２時から１３時の間に」といった詳細な指定をするとサーバの自由度は小さくなる。サーバ側の自由度が大きいと、そのオーダによる負荷を自由に分散できる。サーバ側の負荷分散の観点からは、ユーザのオーダはなるべくサーバ側自由度の大きなものの方が望ましい。
【０１８０】
この点に着目し、ユーザの配信オーダを、サーバの配信時刻指定の自由度という点からとらえ、自由度の大きなオーダに対してはコンテンツの料金や通信料金を安くし、自由度の小さなオーダに対しては、それら料金を安くして提供する。
【０１８１】
宅配便の例においては、配送が集中する「翌朝９時までに配送」という指定をすると、利用者はその分の高い料金を支払う必要があり、通常の配送である「翌日中で時間指定は特にしない」という指定の際には、高い料金は必要なく通常の料金で配送が可能であるのと、同様である。
【０１８２】
１．３．６．３指定した時間までに（終了時指定配信）、アーカイブのサイズと、接続環境の平均通信速度から、配信開始時刻を決定する。
【０１８３】
（１）アーカイブの配信に必要な時間を計算する。
通信時間＝（アーカイブのサイズ）／（接続環境の平均通信速度）
（２）指定された終了時間にちょうど配信が終了する時刻を計算する。
配信開始最終時刻＝配信終了期限−通信時間
（３）配信開始最終時刻から１時間前の時刻を配信開始時刻とする。配信終了期限は、ユーザが選択した配信終了期限を設定する。
【０１８４】
１．３．６．４一番安い時間（最低コスト配信）は、多量のアーカイブの配送が同時刻に集中するのをさけるために、配信開始時刻については一定の時間帯内でランダムに指定する。
・テレホーダイ利用：テレホーダイ時間内で指定する。２３時から１時の間で配信開始時刻をランダムに指定。配信終了期限は、１時に指定。
・ＩＳＤＮ及びアナログのダイヤルアップ：２４時間以内で最も通信料の安い時間帯（最も通信料の安い時間帯の計算方法は、ユーザの利用している通信会社の通信料金テーブルを元に算出する）を考慮し、配信開始時刻をランダムに設定する。配信終了期限は指定無しとする。
・ＩＰ常時接続：２３時から１時を除いた時刻の中から配信開始時刻をランダムに指定する。配信終了期限は指定しない。
【０１８５】
以上の１．３．６．１〜１．３．６．４のいずれかで、配信開始時刻が決定される。
（１．３．７配信）
１．３．７．１ポータル（ダウンロードサーバ側）の処理は、ダウンロードすべきコンテンツを指定したメッセージとして「受取人情報、ＵＲＬ、時刻指定プル情報」をメッセージ要素として設定したファイル転送要求メッセージをＨＧＷへ送信する。各メッセージ要素には、以下の情報を格納する。
【０１８６】
（メッセージ要素名）
・受取人情報：１．３．３で特定された本サービスのユーザＩＤ（図７ではＡＡＡＡ等）を設定。
・ＵＲＬ：１．３．５で指定された、アーカイブファイルのＵＲＬを設定。
・時刻指定プル情報：１．３．６．１〜１．３．６．４のいずれかで特定された、配信開始時刻及び配信終了期限。
【０１８７】
なお、ポータルからＨＧＷへのファイル転送要求メッセージの伝達手段は、ポータルからＨＧＷヘファイルを送信する方法ではなく、特願平１０−４９７７１のテレポーリング技術により、ＨＧＷがポータルから周期的にファイル転送要求メッセージをポーリング受信する方法でもよい。
【０１８８】
（１．３．７．２ＨＧＷ（クライアント）側の処理）
▲１▼「ファイル転送要求」メッセージを受け取った場合、「時刻指定プル情報」メッセージ要素で、配信開始時刻が指定なしの場合は、即時に指定されたＵＲＬからのプルを実行する（プルの定義は後述する）。
【０１８９】
▲２▼メッセージが時間指定ダウンロード（「時刻指定プル情報」メッセージ要素に配信開始時刻が含まれる）の場合は、ＨＧＷテーブルに登録する。登録する内容は、受信したファイル転送要求メッセージ内の「受取人情報」、「ＵＲＬ」、「時刻指定プル情報」及び「ダウンロード終了ステータス」である。ダウンロード終了ステータスは初期値として１（ダウンロード待ち状態を示す）をセットする。
【０１９０】
▲３▼ＨＧＷでは、現在時刻が、時刻指定プル情報の配信開始時刻以前になったＨＧＷテーブルのレコードについて、指定されたＵＲＬからのプルを開始する。プルを開始する時点で、ダウンロード終了ステータスを２（ダウンロード中を示す）にセットする。
【０１９１】
ここで述べるプル（コンテンツセッション）は、ＨＴＴＰあるいはＦＴＰなどの一般的に用いられるプロトコルによりファイルを受信する処理である。
【０１９２】
ここでは、レジューム機能を持つプロトコルとして、ＨＴＴＰダウンロードプロトコルによりＨＧＷがファイルを受信したとする。ただし、ダウンロード時刻をすぎても完了しない場合には、プルを中止する。
【０１９３】
本実施例３では、プル処理において、ＨＧＷ（ダウンロードクライアント）がポータル（サーバ）からアーカイブ（データ）を受信し、ダウンロードエラーが発生しなかったとする。この場合、処理フローは、前記実施例１と同様である。
【０１９４】
（１．３．８コンテンツ取り出し処理）
ユーザがＨＧＷに配送されたコンテンツをＰＣに対して取り出すことが目的である。また、予約したユーザ以外がコンテンツを取り出せないことも必須である。
【０１９５】
以下、処理の一例を示す。
ユーザは、ＰＣからユーザＩＤとパスワードをＨＧＷに対して送信し、ＨＧＷはユーザ登録ファイルをもとに、ユーザＩＤとパスワードを照合する。受け取ったユーザＩＤとパスワードがユーザ登録ファイルに含まれている場合は、そのユーザＩＤを持つユーザに対して配信されているコンテンツを、取り出し端末に渡す。この後、ユーザは、ＰＣ上で、取り出し端末にあるコンテンツを自由に再生したり、編集することができる。
【０１９６】
予約したお客様だけがＨＧＷに蓄積されたコンテンツを取り出せるためのユーザＩＤ認証方法について説明する。
【０１９７】
本サービスでは、ポータルとＨＧＷの双方で利用ユーザを特定できるユーザＩＤを利用ユーザ毎に付与する。ユーザＩＤは後述のユーザ登録時にポータルにて登録するとともに、ＨＧＷ側にも同一のユーザＩＤを登録しておく必要がある。
【０１９８】
ユーザＩＤは、家庭内で複数の人が利用することを想定し、ＨＧＷに複数の設定が可能である。ポータルにおいては、ユーザＩＤ毎に配送すべきＨＧＷのＩＤをユーザ登録時に登録し、通常は注文したユーザのユーザＩＤに対して、登録されているＨＧＷのＩＤに対してＴＰＰを利用した配送が行われる。また、ＨＧＷに配送する時は、ＨＧＷに登録されているユーザＩＤ毎にコンテンツを区分して登録し、特定のユーザＩＤのユーザのみがＨＧＷに配送されたコンテンツを取り出せるようにする（図７の例）。
【０１９９】
図７に示されるＨＧＷへのユーザ登録から取り出しまでの方法について説明する。ここでは、例として、ＨＧＷ（ＨＧＷ−ＩＤが１００であるＨＧＷ、以下ＨＧＷ１）にはユーザが２名登録され、ＨＧＷ（ＨＧＷ−ＩＤが２００であるＨＧＷ、以下ＨＧＷ２）にはユーザが１名登録されることを想定する。また、ＨＧＷからコンテンツを取り出すにはＰＣなどＨＧＷに接続されているコンテンツ取り出し端末が必要である。
【０２００】
１）ＨＧＷへのユーザ登録処理
ＨＧＷには、そのＨＧＷを利用するユーザが登録されている必要がある。ＨＧＷへのユーザ登録は、ユーザのユーザＩＤとパスワードを登録する処理である。ＨＧＷでは、ユーザから入力されたユーザＩＤとパスワードをＨＧＷ内部のユーザ登録ファイルに保持する。ここで、ユーザＩＤの重複は許さない。また、ユーザ登録ファイルは、ユーザＩＤとパスワードを対にして保存される。
【０２０１】
この例においては、ＨＧＷ１においては、ユーザＩＤとしてＡＡＡＡを持つユーザ（以下ユーザＡＡＡＡ）、ユーザＩＤとしてＢＢＢＢを持つユーザ（ユーザＢＢＢＢ）の２名が登録する。
【０２０２】
ユーザＡＡＡＡは、ユーザＩＤ（ＡＡＡＡ）、パスワード
ユーザＢＢＢＢは、ユーザＩＤ（ＢＢＢＢ）、パスワード
をＨＧＷに登録する。ここで、各ユーザの登録するパスワードは任意の文字列を指定し登録出来る。
【０２０３】
ＨＧＷ２においては、ユーザＩＤとしてＣＣＣＣを持つユーザ（ユーザＣＣＣＣ）１名が登録する。ユーザＣＣＣＣは、ユーザＩＤ（ＣＣＣＣ）、パスワードをＨＧＷに登録する。
【０２０４】
２）予約配信処理
次に、ユーザが注文端末から予約したコンテンツを、ポータルからＨＧＷへ配信する処理がある。
【０２０５】
ユーザの予約の処理については、詳細は後述する。ＨＧＷへの配信処理は、例においては、ユーザＡＡＡＡは、コンテンツＡの配信を予約し、同じくユーザＢＢＢＢはコンテンツＢ、ユーザＣＣＣＣはコンテンツＣの配信を予約することを想定する。コンテンツは、予約したユーザがユーザ登録をしてあるＨＧＷへ配送される。つまり、ユーザＡＡＡＡ、ユーザＢＢＢＢはともにＨＧＷ１にユーザ登録されているので、コンテンツＡ及びコンテンツＢはＨＧＷ１に配送される。コンテンツＣは、ユーザＣＣＣＣがユーザ登録されているＨＧＷ２へ配送される。ＨＧＷへ配送されたコンテンツは、ＨＧＷに登録された各ユーザＩＤに対応して確保されているメモリエリアに蓄積される。
【０２０６】
３）ＨＧＷからのコンテンツ取り出し処理
ＨＧＷには複数のユーザが登録される場合があるため、複数ユーザが予約した複数のコンテンツが１つのＨＧＷに同時に蓄積されている。その中から、各ユーザに対して、自分の予約したコンテンツのみを取り出させる必要がある。つまり、ＨＧＷからコンテンツを取り出す際には、ＨＧＷに登録された各ユーザに自分の予約したコンテンツのみの取り出しを許可し、他ユーザの予約したコンテンツの取り出しは許可しないことになる。
【０２０７】
ＨＧＷは、ユーザがコンテンツ取り出し端末から入力したユーザＩＤとパスワードを受け取る。ＨＧＷは、受け取ったユーザＩＤとパスワードを、ユーザ登録ファイルに登録されているユーザＩＤとパスワードとを照合する。受け取ったユーザＩＤとパスワードがユーザ登録ファイルに含まれている場合は、そのユーザＩＤを持つユーザに対して配信されているコンテンツを、取り出し端末に渡す。前記の例においては、ＨＧＷ２には、ユーザはＣＣＣＣのみ１名登録されているので、ＨＧＷ２に配信され蓄積されているコンテンツＣはユーザＣＣＣＣのみが取り出せばよい。
【０２０８】
ＨＧＷ１では、ユーザはＡＡＡＡとＢＢＢＢの２名が登録されている。ＨＧＷ１に接続された取り出し端末から、ユーザＩＤとしてＡＡＡＡとパスワードを受け取ったときは、ユーザＡＡＡＡに対して配信されているコンテンツＡを取り出し端末に渡す。同様に、ユーザＩＤとしてＢＢＢＢとパスワードを受け取ったときは、ユーザＢＢＢＢに対して配信されているコンテンツＢを取り出し端末に渡す。
【０２０９】
以上、本発明者によってなされた発明を、前記実施形態（実施例）に基づき具体的に説明したが、本発明は、前記実施形態（実施例）に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【０２１０】
【発明の効果】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば、以下のとおりである。
【０２１１】
本発明によれば、クライアントとサーバの間のトラフィックを軽減できる。
【０２１２】
また、クライアントとサーバ間で有料の回線を利用する場合は、無駄な回線使用コストを軽減できる。
【図面の簡単な説明】
【図１】本発明による一実施形態（実施例）のファイル転送制御部の動作を示すフローチャートである。
【図２】本実施形態のファイル転送実行部の動作を示すフローチャートである。
【図３】本実施形態の中断が一度も発生せずに正常終了した場合のシーケンスチャートである。
【図４】本実施形態の中断が１回発生したが、次の再開で復旧して、正常終了の場合のシーケンスチャートである。
【図５】本実施形態の途中で中断し、そのまま時間切れの場合のシーケンスチャートである。
【図６】本実施形態のＨＧＷからＰＣへのデータの取り出しについて説明するための図である。
【図７】本実施形態のユーザとＨＧＷの関係を示す図である。
【図８】従来のダウンロードレジュームのアルゴリズムを示すフローチャートである。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a download method (distribution reservation method) in a data distribution system and a client recording medium in which a download program for performing file transfer is recorded.
[0002]
[Prior art]
There is a method of using download support software such as iria (freeware) on a personal computer as a software module capable of interrupting and resuming download.
[0003]
The download support software is intended to download a file from FTP (file transfer) and HTTP (Web) to his / her personal computer and to download the desired file without fail. The server that is trying to download the file is busy ( If there is no response, you can retry until the download is complete. The download can be resumed (resumed) from the interrupted position from either HTTP or FTP.
[0004]
You can also download multiple files at the same time. Further, as a scheduling function (hereinafter referred to as “reservation delivery function”), it is possible to automatically connect to an Internet provider at a specified time to download a file, or conversely, to disconnect the connection.
[0005]
However, in these download support softwares, the download resumption method when the download is interrupted is as follows. As shown in FIG. When the town load is interrupted due to a failure in data reception, the download is resumed after waiting for the time (constant) of the wait timer value Ts. This wait timer value Ts was a fixed set value.
[0006]
[Problems to be solved by the invention]
In this case, when download interruptions occur continuously, retransmission is performed based on a constant called a wait timer value Ts.
[0007]
However, at the time of this retransmission, (a) some temporary trouble has occurred in the communication path between the server machine and the client machine, (b) the server download process is temporarily stopped due to high load. In such a case, the download is not resumed no matter how many retries are performed, and (c) the generation of useless traffic due to the establishment of the download session has occurred. If a pay line is used to establish a download session between the client and the server, useless line use costs are incurred.
[0008]
An object of the present invention is to provide a technique capable of ending download in as short a time as possible while suppressing unnecessary traffic.
[0009]
The above and other objects and novel features of the present invention will become apparent from the description of this specification and the accompanying drawings.
[0010]
[Means for Solving the Problems]
The outline of the invention disclosed in the present application will be briefly described as follows.
[0012]
( 1 ) When a download is interrupted in a download method that allows file transfer to be interrupted and resumed in a data distribution system (network) where bandwidth is not guaranteed, The client machine A threshold (hereinafter referred to as Smin) set in advance by the past X (X is a fixed value, variable depending on settings) seconds throughput (hereinafter referred to as S) with the server machine to be downloaded. Over (S > Smin ) Place If , ( F-1) times (F is a fixed value, variable depending on the setting), try to restart in a short time (wait timer value Ts), and if the restart fails continuously more than F times The Set the wait timer value Ts to Tl ( > Change the setting to Ts) and try to restart, if S ≦ Smin Short Attempt to resume at time (wait timer value Ts).
[0013]
Here, when the effective bandwidth of the line is an ideal value, Tl and Ts are very short values with respect to the expected file transfer time (Tdown) on the assumption that the download is completed without interruption. .
[0014]
( 2 ) A computer-readable storage medium storing a program for causing a computer to execute processing procedures of a download method capable of interrupting and resuming file transfer in a data distribution system (network) whose bandwidth is not guaranteed. When the download is interrupted, a threshold (hereinafter referred to as Smin) set in advance by the past X (X is a fixed value, variable by setting) seconds throughput (hereinafter referred to as S) with the server machine to be downloaded. Over (S > Smin ) Place If , ( F-1) times (F is a fixed value, variable depending on the setting) is a procedure for attempting to restart in a short time (wait timer value Ts), and if the restart fails continuously more than F times, the wait timer value is set to Tl. ( > Ts) to change the setting and try to restart, and if S ≦ Smin Short This is a computer-readable storage medium that stores a program for causing a computer to execute a procedure for trying to restart at a time (wait timer value = Ts).
[0015]
According to the means of the present invention, when downloading a file that can be interrupted and resumed, the download interruption / resumption timer value is made variable, and the average throughput when data download is successful (not = throughput immediately before) When interruption occurs, if the interruption occurs continuously for a preset number of times with the throughput as a parameter, the interruption resumption timer value is lengthened. However, since the traffic between the client and the server can be reduced by maintaining the interruption / resumption timer value, the download can be completed as soon as possible. Further, when a pay line is used between the client and the server, useless line use costs can be reduced.
[0016]
Hereinafter, the present invention will be described in detail with reference to the drawings together with embodiments (examples) according to the present invention.
[0017]
DETAILED DESCRIPTION OF THE INVENTION
According to an embodiment of the present invention, in the control method of the interrupt / resume timer value of download, when the download is interrupted, the past X (X is a fixed value, depending on the setting) when the download is interrupted. Variable) Threshold Smin set by the throughput S in seconds Over (S > Smin ) Place If this is the case, it is determined that there is a temporary line or temporary server failure, and (F-1) times (F is a fixed value, variable depending on the setting) is attempted with a wait timer value Ts (short time). If the restart fails continuously for F times or more, it is determined that some temporary failure has occurred, and the wait timer value Ts is set to Tl ( > Change the setting to Ts) and try to restart.
[0018]
When S ≦ Smin, it is determined that the line condition is permanently bad, and resumption is attempted with the wait timer value Ts (short time).
[0019]
Here, when the effective bandwidth of the line is an ideal value, Tl and Ts are very short values with respect to the expected file transfer time (Tdown) on the assumption that the download is completed without interruption. . That is, Tdown >>Tl> Ts. Specifically, when the file size to be downloaded is 8 MB (= 64000 kbit) and the line bandwidth is 64 kbit / sec, Tdown = 64000/64 = 1000 sec. In this case, Tl and Ts are 60 sec and 10 sec, respectively. Assume the degree. Of course, it is desirable to set these values to appropriate values according to the situation, or calculate appropriate Tl and Ts from the line speed and file size file each time a file is downloaded, A method of setting may be used.
[0020]
The following (a) and (b) are grounds for the above-described control method of the wait timer value Ts in resuming the download interruption to complete the download as quickly as possible while suppressing unnecessary traffic.
[0021]
(A) When the download is interrupted due to high throughput during download execution, it is presumed that the line condition to the server has temporarily deteriorated and the download has been interrupted. Normally, it is normal to succeed in resuming downloads after several retries (hereinafter referred to as F times). Even if resuming of downloads is not successful after F retries, high throughput is achieved after resuming. Therefore, even if the wait timer value Ts is set to be longer, the total transfer time is completed in a short time after retrying F + 1 times.
[0022]
(B) If the download is interrupted due to low throughput during download execution, the line status to the server is not temporary, it is permanently bad, and the download is likely to be interrupted. Therefore, it is expected that download interruptions will frequently occur due to poor line conditions, so it is not meaningful to increase the wait timer value until resumption, conversely, frequent access and little by little It is more efficient to execute the download.
[0023]
The download method for realizing the present invention and the storage medium storing the program are provided with a file transfer execution unit and a file transfer control unit.
[0024]
The file transfer execution unit is a module that actually receives and stores data from the server. The download algorithm needs to be a protocol that supports interruption and resumption, and at the present time, an HTTP file reception protocol is desirable. Of course, if the TCP / IP general-purpose file transfer protocol such as FTP corresponds to interruption / resumption in the future, that protocol may be used, or an original protocol may be used if TCP / IP is used.
[0025]
The file transfer execution unit is an existing file transfer module and is not particularly novel.
i) Have you received all the data?
ii) Was the download interrupted due to data reception failure?
iii) Is data being received and is there remaining data?
Must be determined from an external module.
[0026]
As an example of this realization method, there is a method of generating a status code file indicating the reason for the termination at the end of the process and referring to it from the outside.
[0027]
A typical example of a method for generating a status code file at the end of the process will be described below. The contents of the status code file are
(A) When data reception fails and download is interrupted: Error end
(B) When all data has been received: Normal end
(C) When data is being received and there is no remaining data: file not created
And
[0028]
In addition, in order to calculate the download throughput, a function for holding the downloaded file size and referring to it from the outside is also required. As an example of this realization method, every time a file is downloaded, there is a method of storing the downloaded file size in a separate file (hereinafter referred to as a downloaded file size file). Any other method is acceptable as long as the file size can be maintained.
[0029]
The file transfer control unit is a module that controls the wait timer value Ts until the start, restart, and restart of download for the file transfer execution unit.
[0030]
FIG. 1 is a flowchart showing the operation of the file transfer control unit of an example of the present embodiment. In FIG. 1, the explanation of each constant and variable is as follows.
[0031]
As constants for initial setting,
Ts: Timer value with short interval (sec)
Tl: timer value with long interval (Tl> Ts) (sec)
Smin: Minimum throughput value determined to be good
Fmin: Number of continuous data reception failure failures in a high throughput state
Xtimer: Interval to observe throughput
As a variable,
S: Throughput of the past X seconds when receiving data (kbit / sec)
F: Number of consecutive data reception failures in high throughput state
Time: Elapsed time from the start of download (sec is the minimum unit, rounded down) is used.
[0032]
As shown in FIG. 1, the file transfer control unit of the present embodiment sets step 0 as a start. In step 0, S = 0 and F = 0 are set as the initial values of the calculation control, and the process proceeds to step 1.
[0033]
In step 1, the file transfer control unit issues a download start instruction to the file transfer execution unit, sets Time = 0, and proceeds to step 2.
[0034]
In step 2, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit.
[0035]
If the status code file has not been generated, it is determined that data has been successfully received and that there is remaining data, and the process proceeds to step 7.
[0036]
If the content of the status code file ends in error, the process proceeds to step 3.
[0037]
If the content of the status code file ends normally, the process ends.
[0038]
In step 7, since the data has been successfully received, variable F is set to 0. 11 Proceed to
[0039]
In step 11, it is determined whether or not the download time (Time) has already passed the set value X. Specifically, Time ≧ X is determined. If true, the process proceeds to step 12. If false, go to step 13.
[0040]
In step 12, it is determined whether the download time (Time) is the measurement timing of the throughput. That is, it is determined whether Time is an integer multiple of Xtimer. Specifically, (Time) mod (Xtimer) = 0 is determined, and if true, the process proceeds to Step 8. If false, go to step 13.
[0041]
In step 8, the average throughput of the past X seconds is calculated and held as S, and the process proceeds to step 2. The average throughput is obtained from the calculation formula of (an increase in the past X seconds of the downloaded file size file) / X. Proceed to step 13.
[0042]
In Step 13, in order to reduce the processing load of the file transfer control unit, a 1-second wait is placed in order to limit the processing to once per second, and the process proceeds to Step 2.
[0043]
In step 3, it is determined whether or not the throughput of the past X seconds at the time of data reception is larger than the minimum value of the throughput for determining that the line condition is good. Specifically, S> Smin is determined. If true, it is determined that there is a temporary line or server failure, and the process proceeds to step 4. If false, it is determined that the line status is not good, and the process proceeds to step 9.
[0044]
In Step 4, since the transition to this is a case where the continuous data reception failure in the high throughput state has increased once, F is incremented by one. That is, F = F + 1 is calculated.
[0045]
In step 5, it is determined whether the continuous data reception failure in the high throughput state has reached the number of continuous data reception allowable failures in the high throughput state. Specifically, F ≧ Fmin is determined. If true, it is determined that a temporary line or server failure has occurred, and the process proceeds to step 6. If false, go to Step 9.
[0046]
In step 6, the weight of the Tl wait timer value is set. Then, the process proceeds to Step 10.
[0047]
In step 9, the weight of the Ts wait timer value is set. Then, the process proceeds to Step 10.
[0048]
In step 10, the file transfer control unit issues a download restart instruction to the file transfer execution unit, sets Time = 0, and proceeds to step 2.
[0049]
FIG. 2 is a flowchart showing the operation of the file transfer execution unit of this embodiment.
[0050]
In the file transfer execution unit of this embodiment, as shown in FIG. 2, step A is a start of processing (START). This starts when a download start instruction is received from the file transfer control unit. At this time, the status code file is erased and the process proceeds to Step B.
[0051]
Step B attempts to download the file. Proceed to step C.
[0052]
In step C, it is determined whether a download error has occurred. If a download error has occurred, go to Step H. If no error has occurred and the download was successful, the process proceeds to step D.
[0053]
In step D, the received data is stored in a file, and in the case of a restart instruction, the data is appended after the conventionally downloaded file. Proceed to step E.
[0054]
In step E, the data length of the received file is stored in the downloaded file size file, and the process proceeds to step F.
[0055]
In step F, it is determined whether the download is completed. If the download is complete, go to Step G. If the download is not complete, go to Step B.
[0056]
In step G, information indicating normal end is written in the status code file, and the process ends.
[0057]
In step H, information indicating an error end is written in the status code file, and the process ends.
[0058]
Next, examples of sequence charts between the file transfer control unit, the file transfer execution unit, and the portal nodes are shown in FIGS. The portal is a server that stores content to be downloaded.
[0059]
FIG. 3 is a sequence in the case of normal termination without any interruption, and FIG. 4 is a sequence in the case of normal termination after recovery is resumed at the next restart after one interruption. FIG. 5 is a sequence chart in the case of interruption in the middle and time-out as it is.
[0060]
(Example 1)
Example 1 of this embodiment is an example of the flow of processing when the download client software receives data from the server and no download error has occurred.
[0061]
Various conditions in Example 1 are as follows:
-Content file size = 8000KB = 64000 bits
・ Line bandwidth is 64 kbit / sec
・ Tl = 60sec
・ Ts = 10sec
・ Smin = 40 (kbit / sec)
・ Fmin = 2 (times)
・ X = 30sec
・ Xtimer = 5sec
-Download protocol of download execution part: Download by HTTP protocol
It is. Hereinafter, the processing flow of the file transfer execution unit and the file transfer control unit will be described in time series in the flowcharts of FIGS.
[0062]
(Operation of the file transfer execution unit)
As shown in FIG. 2, when a download start instruction is received from the file transfer control unit, the process is started, and the process proceeds to step B to execute download using the HTTP protocol. Proceed to step C.
[0063]
In step C, it is determined whether a download error has occurred. Here, since no error has occurred, the process proceeds to Step D.
[0064]
In step D, the received data is stored in a file. In step E, the received data length is stored in a downloaded file size file, and the process proceeds to step F. In step F, it is determined whether or not the download has been completed. Here, since the download has not been completed, the process returns to step B.
[0065]
Here, Step B → Step C → Step D → Step E → Step F → Step B is repeated.
[0066]
Here, during the repetitive processing, the capacity of the downloaded file (= contents of the downloaded file size file) increases monotonically at that time. That is,
When Time = 0 sec, 0 kbit
When Time = 1 sec, 64 kbit
When Time = 5 sec, 320 kbit
640kbit when Time = 10sec
When Time = 30 sec, 1920 kbit
When Time = 35 sec, 2240 kbit
When Time = 100 sec, 6400 kbit
61760kbit when Time = 965sec
When Time = 995 sec, it is 63680 kbit. When Time = 1000 sec, it becomes 64000 kbits. In the download completion determination in Step F, it is determined that the download is completed. The process proceeds to Step G, where the status code file is created and information indicating normal termination is written. finish.
[0067]
(Operation of the file transfer control unit)
In FIG. 1, in step 0, S = 0 and F = 0 are set. Go to step 1.
[0068]
In step 1, the file transfer control unit issues a download start instruction to the file transfer execution unit, sets Time to 0 sec, and proceeds to step 2.
[0069]
In step 2, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit. Since the download has not been completed at this time, the status code file has not been generated. Therefore, it is determined that the data has been successfully received and there is remaining data, and the process proceeds to step 7.
[0070]
In step 7, since data reception is successful, the variable F is set to 0 and the process proceeds to step 11.
[0071]
In step 11, Time ≧ X is determined. Here, since Time = 0 and X = 30, it is determined to be false, and the process proceeds to step 13. In step 13, a 1-second wait is set, and the process proceeds to step 2.
[0072]
Thereafter, the processing of Step 2 → Step 7 → Step 11 → Step 13 is repeated until Time = 30. Since Time = 30 and X = 30 in the process of Step 11 when Time = 30, it is determined to be true, and the process proceeds to Step 12.
[0073]
In step 12, it is determined whether the download time (Time) is the measurement timing of the throughput. That is, it is determined whether Time is an integer multiple of Xtimer. Specifically, (Time) mod (Xtimer) = 0 is determined. here, 30 Since mod5 = 0, it is determined to be true, and the process proceeds to Step 8.
[0074]
In step 8, the average throughput of the past X seconds is calculated and held as S. The average throughput is calculated from the formula of (the increase in the past X seconds of the downloaded file size file) / X. Here, the increase in the past X seconds of the downloaded file size file of the file transfer execution unit is 1920 kbit− Since 0 kbit = 1920 kbit, 1920 kbit / 30 sec = 64 (kbit / sec). Proceed to step 13. In step 13, a 1-second wait is set, and the process proceeds to step 2.
[0075]
In step 2, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit. Since the download is not completed at this point, the status code file has not been generated, so it is determined that the data has been successfully received and there is remaining data, and the process proceeds to step 7.
[0076]
In step 7, since data reception is successful, the variable F is set to 0 and the process proceeds to step 11. In step 11, Time ≧ X is determined. Here, since Time = 31 and X = 30, it is determined to be true and the process proceeds to step 12.
[0077]
In step 12, it is determined whether the download time (Time) is the measurement timing of the throughput. Here, since 31 mod 5 = 1, it is determined to be false, and the process proceeds to step 13.
[0078]
Thereafter, the processing of Step 2 → Step 7 → Step 11 → Step 12 → Step 13 is repeated until Time = 35.
[0079]
Since 35 mod 5 = 0 in the process of step 12 at Time = 35, it is determined to be true, and the process proceeds to step 8. In step 8, the average throughput of the past X seconds is calculated and held as S. The average throughput is calculated from the formula of (the increase in the past X seconds of the downloaded file size file) / X. Here, the increase in the past X seconds of the downloaded file size file of the file transfer execution unit is 2240 kbit− Since 320 kbit = 1920 kbit, 1920 kbit / 30 sec = 64 (kbit / sec). Proceed to step 13.
[0080]
In Step 13, in order to reduce the processing load of the file transfer control unit, a 1-second wait is placed in order to limit the processing to once per second, and the process proceeds to Step 2.
[0081]
Hereinafter, it is assumed that Steps 2 to 13 are similarly performed and Time = 995.
[0082]
In step 2, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit. Since the download is not completed at this point, the status code file has not been generated, so it is determined that the data has been successfully received and there is remaining data, and the process proceeds to step 7.
[0083]
In step 7, since data reception is successful, the variable F is set to 0 and the process proceeds to step 11. In step 11, Time ≧ X is determined. Here, since Time = 995 and X = 30, it is determined to be true, and the process proceeds to step 12.
[0084]
In step 12, it is determined whether the download time (Time) is the measurement timing of the throughput. Here, since it is 995mod5 = 0, it determines with it being true and progresses to step 8. FIG. In step 8, the average throughput of the past X seconds is calculated and held as S. The average throughput is calculated from the formula of (the increase in the past X seconds of the downloaded file size file) / X. Here, the increase in the past X seconds of the downloaded file size file of the file transfer execution unit is 63680 kbit− Since 61760 kbit = 1920 kbit, 1920 kbit / 30 sec = 64 (kbit / sec). Proceed to step 13.
[0085]
In Step 13, in order to reduce the processing load of the file transfer control unit, a 1-second wait is placed in order to limit the processing to once per second, and the process proceeds to Step 2.
[0086]
In step 2, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit. Since the download is not completed at this point, the status code file has not been generated, so it is determined that the data has been successfully received and there is remaining data, and the process proceeds to step 7.
[0087]
In step 7, since data reception is successful, the variable F is set to 0 and the process proceeds to step 11. In step 11, Time ≧ X is determined. Here, since Time = 996 and X = 30, it is determined to be true and the process proceeds to step 12.
[0088]
In step 12, it is determined whether the download time (Time) is the measurement timing of the throughput. Here, since 996 mod 5 = 1, it is determined to be false, and the process proceeds to step 13. In step 13, a 1-second wait is set, and the process proceeds to step 2.
[0089]
Thereafter, the processing of Step 2 → Step 7 → Step 11 → Step 12 → Step 13 is repeated until Time = 999.
[0090]
After the processing of Step 13 at Time = 999, the process proceeds to Step 2 when Time = 1000.
[0091]
In step 2, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit. At this point in time, since the download has been completed, the status code file has been completed normally, so it is determined that all data has been received, and the processing of the file transfer processing unit is completed.
[0092]
(Example 2)
Example 2 of this embodiment is an example of the flow of processing when download client software receives data from a server and a download error occurs. In the second embodiment, the average throughput is 64 kbit / sec.
Various conditions in Example 2 are as follows:
-Content file size = 8000KB = 64000 bits
・ Line bandwidth is 64 kbit / sec
・ Tl = 60sec
・ Ts = 10sec
・ Smin = 40 (kbit / sec)
・ Fmin = 2 (times)
・ X = 30sec
・ Xtimer = 5sec
-Download protocol of download execution part: Download by HTTP protocol
-When Time = 35, the download fails twice in succession and then resumes successfully.
[0093]
Hereinafter, the flow of processing of the file transfer execution unit and the file transfer control unit will be described in time series with respect to the flowcharts of FIGS. 1 and 2.
[0094]
(Operation of the file transfer execution unit)
As shown in FIG. 2, when a download start instruction is received from the file transfer control unit, the process is started, and the process proceeds to step B to execute download using the HTTP protocol. Proceed to step C.
[0095]
In step C, it is determined whether a download error has occurred. Here, since no error has occurred, the process proceeds to Step D.
[0096]
In step D, the received data is stored in a file. In step E, the received data length is stored in a downloaded file size file, and the process proceeds to step F. In step F, it is determined whether or not the download has been completed. Here, since the download has not been completed, the process returns to step B.
[0097]
Here, Step B → Step C → Step D → Step E → Step F → Step B is repeated until Time = 35.
[0098]
During the repetitive processing, the capacity of the downloaded file (= content of the downloaded file size file) increases monotonically at that time. That is,
When Time = 0 sec, 0 kbit
When Time = 1 sec, 64 kbit
When Time = 5 sec, 320 kbit
640kbit when Time = 10sec
When Time = 30 sec, 1920 kbit
When Time = 35 sec, 2240 kbit
It is.
[0099]
Since a download error has occurred at the time point of Step C where Time = 35, the process proceeds to Step H, where information indicating the end of the error is written in the status code file, and the process is temporarily terminated.
[0100]
When a download resumption instruction is received from the file transfer control unit, the process is started, and the process proceeds to Step B where the download using the HTTP protocol is executed. Proceed to step C.
[0101]
In step C, since an error has occurred again, the process transitions to step H, information indicating the end of error is written in the status code file, and the process is temporarily terminated.
[0102]
When a download resumption instruction is received from the file transfer control unit, the process is started, and the process proceeds to Step B where the download using the HTTP protocol is executed. Proceed to step C.
[0103]
In step C, it is determined whether a download error has occurred. Here, since no error has occurred, the process proceeds to Step D.
[0104]
In step D, the received data is stored in the form of appending after the previously interrupted file. In step E, the data length received in the current restart process is stored in the downloaded file size file, and the process proceeds to step F. In step F, it is determined whether or not the download has been completed. Here, since the download has not been completed, the process returns to step B.
[0105]
Here, Step B → Step C → Step D → Step E → Step F → Step B is repeated until Time = 965.
[0106]
When Time = 0 sec, 0 kbit
When Time = 30 sec, 1920 kbit
When Time = 930 sec, 59520 kbit
61440 kbit when Time = 960 sec
In the download completion determination in step F, it is determined that the download is completed, the process proceeds to step G, the status code file is created, information indicating normal termination is written, and the process of the file transfer execution unit is terminated.
[0107]
(Operation of the file transfer control unit)
As shown in FIG. 1, in step 0, S = 0 and F = 0 are set. Go to step 1. In step 1, the file transfer control unit issues a download start instruction to the file transfer execution unit, sets Time to 0 sec, and proceeds to step 2.
[0108]
In step 2, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit. Since the download is not completed at this point, the status code file has not been generated, so it is determined that the data has been successfully received and there is remaining data, and the process proceeds to step 7.
[0109]
In step 7, since data reception is successful, the variable F is set to 0 and the process proceeds to step 11. In step 11, Time ≧ X is determined. Here, since Time = 0 and X = 30, it is determined to be false, and the process proceeds to step 13. In step 13, a 1-second wait is set, and the process proceeds to step 2.
[0110]
Thereafter, the processing of Step 2 → Step 7 → Step 11 → Step 13 is repeated until Time = 30. Since Time = 30 and X = 30 in the process of Step 11 when Time = 30, it is determined to be true, and the process proceeds to Step 12.
[0111]
In step 12, it is determined whether the download time (Time) is the measurement timing of the throughput. That is, it is determined whether Time is an integer multiple of Xtimer. Specifically, (Time) mod (Xtimer) = 0 is determined. here, 30 Since mod5 = 0, it is determined to be true, and the process proceeds to Step 8.
[0112]
In step 8, the average throughput of the past X seconds is calculated and held as S. The average throughput is calculated from the formula of (the increase in the past X seconds of the downloaded file size file) / X. Here, the increase in the past X seconds of the downloaded file size of the file transfer execution unit is 1920 kbit− Since 0 kbit = 1920 kbit, 1920 kbit / 30 sec = 64 (kbit / sec). This is held as S. Proceed to step 13. In step 13, a 1-second wait is set, and the process proceeds to step 2.
[0113]
In step 2, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit. Since the download has not been completed at this time, the status code file has not been generated. Therefore, it is determined that the data has been successfully received and there is remaining data, and the process proceeds to step 7.
[0114]
In step 7, since the data has been successfully received, the variable F is set to 0 and the process proceeds to step 11.
[0115]
In step 11, Time ≧ X is determined. Here, since Time = 31 and X = 30, it is determined to be true and the process proceeds to step 12. In step 12, it is determined whether the download time (Time) is the measurement timing of the throughput. Here, since 31 mod 5 = 1, it is determined to be false, and the process proceeds to step 13.
[0116]
Thereafter, the processing of Step 2 → Step 7 → Step 11 → Step 12 → Step 13 is repeated until Time = 35.
[0117]
In step 2 at Time = 35, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit. At this point, since the download has been completed, the status code file has ended in error, so it is determined that data reception has failed, and the process proceeds to step 3.
[0118]
In step 3, it is determined whether or not the throughput of the past X seconds at the time of data reception is larger than the minimum value of the throughput for determining that the line condition is good. Specifically, S> Smin is determined. Here, since 64 (kbit / sec)> 40 (kbit / sec) is true, it is determined that there is a temporary line or server failure, and the process proceeds to step 4. In Step 4, since the transition to this is a case where the continuous data reception failure in the high throughput state has increased once, F is incremented by one. That is, F = 0 + 1 = 1, 1 is set in F, and the process proceeds to step 5.
[0119]
In step 5, it is determined whether the continuous data reception failure in the high throughput state has reached the number of continuous data reception allowable failures in the high throughput state. Specifically, F ≧ Fmin is determined. Here, since 1 ≧ 2 is false, the process proceeds to step 9.
[0120]
In step 9, a wait timer value of Ts = 10 seconds is set. Then, the process proceeds to Step 10. In step 10, the file transfer control unit gives support for resuming download to the file transfer execution unit, sets Time = 0, and proceeds to step 2.
[0121]
In step 2 at Time = 0, the download status can be determined. The download status is determined by reading the status code file from the file transfer execution unit. At this point, since the download has been completed, the status code file has ended in error, so it is determined that data reception has failed, and the process proceeds to step 3.
[0122]
In step 3, it is determined whether or not the throughput of the past X seconds at the time of data reception is larger than the minimum value of the throughput for determining that the line condition is good. Specifically, S> Smin is determined. Here, since 64 (kbit / sec)> 40 (kbit / sec) is true, it is determined that there is a temporary line or server failure, and the process proceeds to step 4.
[0123]
In Step 4, since the transition to this is a case where the continuous data reception failure in the high-throughput state has increased once, F is incremented by 1. That is, F = 1 + 1 = 2, 2 is set in F, and the process proceeds to step 5.
[0124]
In step 5, it is determined whether or not the continuous data reception failure in the high throughput state has reached the number of allowable failures of continuous data reception in the high throughput state. Specifically, F ≧ Fmin is determined. Here, since 2 ≧ 2 is true, it is determined that a temporary line or server failure has occurred, and the process proceeds to step 6.
[0125]
In step 6, a wait timer value of Tl = 60 seconds is set. Then, the process proceeds to Step 10. In step 10, the file transfer control unit issues a download restart instruction to the file transfer execution unit, sets Time = 0, and proceeds to step 2.
[0126]
In step 2, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit. Since the download has not been completed at this time, the status code file has not been generated. Therefore, it is determined that the data has been successfully received and the remaining data is present, and the process proceeds to step 7.
[0127]
In step 7, since data reception is successful, the variable F is set to 0 and the process proceeds to step 11. In step 11, Time ≧ X is determined. Here, since Time = 0 and X = 30, it is determined to be false, and the process proceeds to step 13. In step 13, a 1-second wait is set, and the process proceeds to step 2.
[0128]
Thereafter, the processing of Step 2 → Step 7 → Step 11 → Step 13 is repeated until Time = 30. Since Time = 30 and X = 30 in the process of Step 11 when Time = 30, it is determined to be true, and the process proceeds to Step 12.
[0129]
In step 12, it is determined whether the download time (Time) is the measurement timing of the throughput. That is, it is determined whether Time is an integer multiple of Xtimer. Specifically, (Time) mod (Xtimer) = 0 is determined. Here, since 10 mod 5 = 0, it is determined to be true, and the process proceeds to Step 8.
[0130]
In step 8, the average throughput of the past X seconds is calculated and held as S. The average throughput is calculated from the formula of (the increase in the past X seconds of the downloaded file size file) / X. Here, the increase in the past X seconds of the downloaded file size file of the file transfer execution unit is 1920 kbit. Since −0 kbit = 1920 kbit, 1920 kbit / 30 sec = 64 (kbit / sec). Proceed to step 13. In step 13, a 1-second wait is set, and the process proceeds to step 2.
[0131]
In step 2, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit. Since the download has not been completed at this time, the status code file has not been generated. Therefore, it is determined that the data has been successfully received and the remaining data is present, and the process proceeds to step 7.
[0132]
In step 7, since data reception is successful, the variable F is set to 0 and the process proceeds to step 11. In step 11, Time ≧ X is determined. Here, since Time = 31 and X = 30, it is determined to be true and the process proceeds to step 12.
[0133]
In step 12, it is determined whether the download time (Time) is the measurement timing of the throughput. Here, since 31 mod 5 = 1, it is determined to be false, and the process proceeds to step 13.
[0134]
Thereafter, the processing of Step 2 → Step 7 → Step 11 → Step 12 → Step 13 is repeated until Time = 35. Since 35 mod 5 = 0 in the process of step 12 at Time = 35, it is determined to be true, and the process proceeds to step 8. In step 8, the average throughput of the past X seconds is calculated and held as S.
[0135]
The average throughput is calculated from the formula of (the increase in the past X seconds of the downloaded file size file) / X. Here, the increase in the past X seconds of the downloaded file size file of the file transfer execution unit is 2240 kbit− Since 320 kbit = 1920 kbit, 1920 kbit / 30 sec = 64 (kbit / sec). Proceed to step 13.
[0136]
In Step 13, in order to reduce the processing load of the file transfer control unit, a 1-second wait is placed in order to limit the processing to once per second, and the process proceeds to Step 2.
[0137]
Hereinafter, it is assumed that Steps 2 to 13 are similarly performed and Time = 955.
[0138]
In step 2, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit. Since the download is not completed at this point, the status code file has not been generated, so it is determined that the data has been successfully received and there is remaining data, and the process proceeds to step 7.
[0139]
In step 7, since data reception is successful, the variable F is set to 0 and the process proceeds to step 11. In step 11, Time ≧ X is determined. Here, since Time = 960 and X = 30, it is determined to be true and the process proceeds to step 12. In step 12, it is determined whether the download time (Time) is the measurement timing of the throughput. Here, since 960 mod 5 = 0, it is determined to be true, and the process proceeds to step 8.
[0140]
In step 8, the average throughput of the past X seconds is calculated and held as S. The average throughput is calculated from the formula of (the increase in the past X seconds of the downloaded file size file) / X. Here, the increase in the past X seconds of the downloaded file size file of the file transfer execution unit is 61440 kbit− Since 59520 kbit = 1920 kbit, 1920 kbit / 30 sec = 64 (kbit / sec). Proceed to step 13. In Step 13, in order to reduce the processing load of the file transfer control unit, a 1-second wait is placed in order to limit the processing to once per second, and the process proceeds to Step 2.
[0141]
In step 2, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit. Since the download has not been completed at this time, the status code file has not been generated. Therefore, it is determined that the data has been successfully received and the remaining data is present, and the process proceeds to step 7. In step 7, since data reception is successful, the variable F is set to 0 and the process proceeds to step 11.
[0142]
In step 11, Time ≧ X is determined. Here, since Time = 961 and X = 30, it is determined to be true, and the process proceeds to step 12. In step 12, it is determined whether the download time (Time) is the measurement timing of the throughput. Here, since 961 mod 5 = 1, it is determined to be false, and the process proceeds to step 13. In step 13, a 1-second wait is set, and the process proceeds to step 2.
[0143]
Thereafter, the processing of Step 2 → Step 7 → Step 11 → Step 12 → Step 13 is repeated until Time = 964. After the processing of Step 13 at Time = 964, the process proceeds to Step 2 when Time = 965.
[0144]
In step 2, the download status is determined. The download status is determined by reading the status code file from the file transfer execution unit. At this point in time, since the download has been completed, the status code file has been completed normally, so it is determined that all data has been received, and the processing of the file transfer processing unit is completed.
[0145]
(Example 3)
Hereinafter, in the data distribution system (network) in which the bandwidth of the present invention is not guaranteed, a storage medium storing a program for executing a processing procedure of a download method capable of interrupting and resuming file transfer, A third embodiment when applied to a music distribution service system will be described.
[0146]
(Communication node used in Example 3)
In the third embodiment, the following five are used as communication nodes.
・ User registration terminal (hereinafter referred to as user registration terminal)
・ Reservation terminal (hereinafter reservation terminal)
・ Customer's PC (PC)
・ Home gateway (HGW)
・ Music distribution portal site (hereinafter referred to as portal)
It is. Each communication node is connected by a TCP / IP network.
[0147]
The only requirement is that the user registration terminal and the reservation terminal can be connected to the portal via the Internet.
[0148]
The PC is connected to the HGW via a LAN (TCP / IP), and a plurality of PCs may be connected to one HGW instead of one PC. However, in the third embodiment, a description will be given assuming that one PC is connected.
[0149]
The HGW is connected to the portal via the Internet, and there are a plurality of HGWs. The third embodiment will be described by paying attention to one of the HGWs.
[0150]
There is only one portal on the Internet. The portal provides a music content download service.
[0151]
(Point of this music distribution service system)
The purpose of this music distribution service system is for customers to acquire music content from the portal.
[0152]
This music distribution service system is not simply a download software on the customer's PC, but downloads the content from the portal where the music content exists, rather than downloading the content from the portal to the HGW at a fixed time to reserve the content distribution to the portal. Only customers who have made a reservation and made a reservation can retrieve the content stored in the HGW. However, data distribution from the portal to the HGW is realized by the HGW downloading data from the portal.
[0153]
Hereinafter, the sequence from the time when the customer reserves the content to the time when the data is retrieved will be described by taking as an example the case where there is one HGW and one user. Next, a user ID authentication method for allowing only a reserved customer to take out content stored in the HGW will be described in the event that there are a plurality of users.
[0154]
Also in the third embodiment, the download interruption / resumption timer value is made variable, and the interruption / resumption timer value is controlled using the average throughput during the data download as a parameter, thereby reducing unnecessary traffic and completing the download as quickly as possible. Although the process is applied, details will be described later.
[0155]
(Time-series processing in the music reservation distribution service)
Hereinafter, a time-series process in the music reservation distribution service will be described.
In the following item numbers, 1.3.1. And 1.3.2 (1.3.2.1.1.3.2.2) are preparation processes, and these processes may not be sequential in time series. Moreover, these processes should just be completed before the reservation process mentioned later. However, it is essential that the order of 1.3.2.1 and 1.3.2.2 be performed in this order.
[0156]
1.3.3 to 1.3.6 are reservation processes, which are operations and data transmission from the reservation terminal to the portal. These must be done sequentially.
[0157]
1.3.7 is a delivery process, and it is assumed that the reservation process has been completed. A mechanism for delivering content from the portal to the HGW is described.
[0158]
1.3.8 is a content retrieval process, and it is assumed that the delivery process has been completed. Describes how to extract data from the HGW to the PC.
[0159]
These are shown in FIG.
[0160]
(1.3.1 Registration of music content)
Registration of music content is performed manually by the portal site administrator. The administrator places the music content in the download content area of the portal. In addition, a page of a music content list (hereinafter referred to as a portal music list) is prepared.
-Register the song name, (artist), (record company), file size, and (fee) in the song list on the portal. Information in parentheses can be omitted.
[0161]
(1.3.2 User registration)
1.3.2.1 User registration at the portal site is a portal site, and user registration of the music distribution service is performed. User registration needs to be performed in advance before login, and is performed by the user from the user registration terminal. The required items to be registered are as follows.
・ User ID
·password
・ HGW-ID (used to determine the download destination to HGW)
Connection environment (Dial-up analog 56k, dial-up analog 28k, dial-up ISDN 64k, always IP64k, LAN10M)
・ Use service (INS Telehodai, Telehodai 1800, Telehodai 3600)
The connection environment is used for estimating the throughput during data distribution. For the connection environment (ISDN, analog 56k, 28k, etc.), the value set by the user is the initial value, but the average communication speed in the distribution process actually executed in 1.3.7 executed later. It is also conceivable to record (delivery speed) and dynamically change the setting value accordingly.
[0162]
The following items are optional and should be registered, but can be used without them.
・ Name
·phone number
・ Contact email address
-Download completion notification e-mail address (Select whether it is the same as or different from the contact e-mail address.
However, the user ID is an ID for identifying the user, and duplication is not allowed. Therefore, each item is bound to the user ID.
[0163]
As an example of a registration method, the user displays a WEB screen of the registration item on the registration terminal from the portal, and the user transmits the input information to the user from the user registration terminal using an HTTP POST command or the like, and receives it. The portal can be written to a profile storage file. However, the purpose is to write the essential items input by the user in the profile saving file on the portal, and any means can be used as long as it is possible.
[0164]
(User registration to 1.3.2.2 HGW)
The user registration to the HWG is a process intended to hold the user ID and password issued in the user registration process to the portal of 1.3.2.1 in the user registration file inside the HWG.
[0165]
The user registration file is stored with a user ID and password as a pair. The registration method is not limited as long as it satisfies the above purpose, and no specific example is shown.
[0166]
(1.3.3 Reservation processing / login)
Log in from the reservation terminal. The reservation terminal may be the same as the user registration terminal or may be different. In the login process, the user communicates the user ID and password registered from the reservation terminal to the portal, and the portal checks the password corresponding to the user ID from the profile save file and specifies the user ID of the reservation service. For example, the purpose is to display a music content selection screen on a reservation terminal.
[0167]
As an example of the login process, a user ID and password dialog box is displayed on the reservation terminal from the portal using the WEB browser of the reservation terminal, and the user transmits the input information from the reservation terminal to the portal using an HTTP POST command or the like. If the portal receives the password, the password corresponding to the user ID is checked from the profile saving file and if it is correct, the music content selection screen is displayed on the WEB browser. Absent.
[0168]
(1.3.4 Selection of music content)
The music content selection process is a process of designating a music piece of music content that the user wants to acquire to the portal. The purpose is to transmit the music contents of the music from the reservation terminal to the portal, and the portal holds the music, and transitions to archive processing.
[0169]
As an example of music content selection processing, a music content list is displayed on the reservation terminal from the portal to the WEB browser of the reservation terminal, and the user selects one or a plurality of songs to be downloaded, an HTTP POST command, etc. The portal receives the information from the reservation terminal and obtains the music specified by the user and transitions to the archiving process. Any means can be used as long as the process can be realized.
[0170]
(1.3.5 Archive processing)
The purpose of archiving is that the portal archives one or more music contents specified in 1.3.4 together, stores the URL and file entity, and transitions to the distribution policy specification screen. It is. As an archiving means, there are formats such as tar often used in UNIX and ZIP frequently used in Windows, but the algorithm is not limited as long as it can be archived.
[0171]
Hereinafter, the archived music content is called an archive. The reason for performing the archiving process is that it is expected to efficiently distribute all the music contents designated by one delivery.
[0172]
(1.3.6 Specifying the distribution policy)
The purpose of specifying the distribution policy is to inform the user that the user has specified the distribution policy in the portal and that the reservation has been completed. As the delivery policy specification means, items 1 to 6 of “Time specification” in Table 1, ie, “Now”, “From specified time”, “By specified time”, “Lowest time” ”,“ When the HGW is not used ”, the user must select one and transmit it to the portal, and the portal must maintain the distribution policy.
[0173]
[Table 1]
Figure 0003666796
As an example of the distribution policy designation process, the distribution policy table of Table 1 is displayed on the reservation terminal from the portal for the WEB browser of the reservation terminal, and the user selects one distribution policy and makes a reservation with an HTTP POST command or the like. The portal communicates from the terminal to the portal, and the portal receives the information, determines the distribution policy specified by the user, and the portal displays processing for accepting the reservation to the WEB browser of the reservation terminal. Any means can be used as long as the object can be realized.
[0174]
Thereafter, one of the processes of 1.3.6.1 to 1.3.6.4 is executed according to the determined distribution policy. The point of these processes is to set the distribution start time. Thereafter, the process proceeds to 1.3.7. 1.3.6.1 Immediately set the delivery start time to not specified. The delivery end date is not specified. 1.3.6.2 Set the distribution start time to the set time from the specified time. The delivery end date is not specified.
[0175]
[Table 2]
Figure 0003666796
Table 2 is an example in which a price change is added to the content according to the time designation method. In this example, immediately from the designated time, a 10% surcharge is charged with respect to the normal content price, and when the cheapest time is designated, a 15% discount is applied.
[0176]
By using this price change method together with the time specification method, the distribution time to the user can be smoothed and the load on the network can be distributed, and the server and network costs can be reduced, so the server equipment can be constructed with inexpensive equipment. .
[0177]
If this is compared to an actual physical distribution system, it is the same as a time-designated delivery service for requesting delivery of a package by designating an arrival time in a courier.
[0178]
Normally, when downloading content, the user designates the distribution start time. In this method, the server designates the delivery time within the range designated by the user.
[0179]
Thereby, the freedom degree at the time of setting the delivery start time on the server side varies depending on the range specified by the user. For example, if the user only designates a rough time such as “within 3 days”, the degree of freedom on the server side increases, but if a detailed designation such as “between 12:00 and 13:00 on the 3rd” is given, the degree of freedom of the server is increased. Becomes smaller. If the degree of freedom on the server side is large, the load due to the order can be freely distributed. From the viewpoint of load distribution on the server side, it is desirable that the user order has as much freedom as possible on the server side.
[0180]
Focusing on this point, the user's distribution order is considered from the viewpoint of the degree of freedom for specifying the distribution time of the server. For orders with a large degree of freedom, the content fee and communication fee are reduced, and the order with a small degree of freedom is reduced. On the other hand, these fees are offered at a low price.
[0181]
In the case of courier service, if you specify “delivery before 9 am the next morning” when delivery is concentrated, the user needs to pay a high fee for that, and it is normal delivery “ In the case of designation of “no particular”, a high charge is not necessary and delivery is possible at a normal charge.
[0182]
1.3.6.3 The distribution start time is determined from the archive size and the average communication speed of the connection environment by the specified time (end-time specified distribution).
[0183]
(1) Calculate the time required for archive distribution.
Communication time = (Archive size) / (Average communication speed in the connection environment)
(2) Calculate the time at which the distribution ends exactly at the specified end time.
Delivery start final time = Delivery end deadline-Communication time
(3) A time one hour before the final distribution start time is set as the distribution start time. The distribution end time limit sets the distribution end time limit selected by the user.
[0184]
1.3.6.4 For the cheapest time (lowest cost delivery), the delivery start time is specified at random within a certain time period to avoid the delivery of a large amount of archives at the same time. .
・ Tele-hodai use: Specify within tele-hodai time. The distribution start time is randomly specified between 23:00 and 1pm. The delivery end time is specified at 1 o'clock.
-ISDN and analog dial-up: Time zone with the lowest communication charge within 24 hours (The calculation method for the time zone with the lowest communication charge is calculated based on the communication charge table of the communication company used by the user) The distribution start time is set at random. The delivery end date is not specified.
-Always-on IP: Randomly specify the distribution start time from the time except 13:00 from 13:00. No delivery end date is specified.
[0185]
The distribution start time is determined by any one of the above 1.3.6.1 to 1.3.6.4.
(1.3.7 distribution)
1.3.7.1 Portal (on the download server side) processes a file transfer request message in which “recipient information, URL, time specification pull information” is set as a message element as a message designating content to be downloaded. Send to. The following information is stored in each message element.
[0186]
(Message element name)
Recipient information: The user ID (AAAA etc. in FIG. 7) of this service specified in 1.3.3 is set.
URL: Set the URL of the archive file specified in 1.3.5.
-Time designation pull information: the distribution start time and the distribution end time limit specified in any of 1.3.6.1 to 1.3.6.4.
[0187]
Note that the file transfer request message transmission means from the portal to the HGW is not a method of transmitting a file from the portal to the HGW, but the HGW periodically sends a file transfer request from the portal by the telepoling technology of Japanese Patent Application No. 10-49771. A method of polling and receiving a message may also be used.
[0188]
(1.3.7.2 HGW (client) side processing)
(1) When the “file transfer request” message is received, if the delivery start time is not specified in the “time specified pull information” message element, the pull from the specified URL is immediately executed (pull definition) Will be described later).
[0189]
(2) If the message is a time-designated download (the “time-designated pull information” message element includes the delivery start time), it is registered in the HGW table. The contents to be registered are “recipient information”, “URL”, “time specified pull information”, and “download end status” in the received file transfer request message. The download end status is set to 1 (indicating a download waiting state) as an initial value.
[0190]
(3) The HGW starts pulling from the specified URL with respect to the record of the HGW table whose current time is before the distribution start time of the time specified pull information. At the start of pulling, the download end status is set to 2 (indicating that download is in progress).
[0191]
The pull (content session) described here is a process of receiving a file by a commonly used protocol such as HTTP or FTP.
[0192]
Here, it is assumed that the HGW receives a file by the HTTP download protocol as a protocol having a resume function. However, if it is not completed after the download time, pulling is stopped.
[0193]
In the third embodiment, it is assumed that in the pull process, the HGW (download client) receives the archive (data) from the portal (server) and no download error occurs. In this case, the processing flow is the same as in the first embodiment.
[0194]
(1.3.8 Content retrieval processing)
The purpose is that the user takes out the content delivered to the HGW to the PC. In addition, it is essential that contents other than the reserved user cannot be taken out.
[0195]
Hereinafter, an example of processing will be described.
The user transmits a user ID and password from the PC to the HGW, and the HGW verifies the user ID and password based on the user registration file. When the received user ID and password are included in the user registration file, the content distributed to the user having the user ID is transferred to the take-out terminal. Thereafter, the user can freely play back or edit the content in the takeout terminal on the PC.
[0196]
A user ID authentication method for allowing only a reserved customer to retrieve contents stored in the HGW will be described.
[0197]
In this service, a user ID that can identify a user in both the portal and the HGW is assigned to each user. The user ID must be registered at the portal at the time of user registration, which will be described later, and the same user ID must be registered on the HGW side.
[0198]
Assuming that a plurality of people use a user ID in the home, a plurality of settings can be set in the HGW. In the portal, the ID of the HGW to be delivered for each user ID is registered at the time of user registration, and usually the delivery using the TPP is performed for the registered user ID of the HGW for the user ID of the ordered user. Is called. Further, when delivering to the HGW, the contents are classified and registered for each user ID registered in the HGW, so that only the user with the specific user ID can take out the contents delivered to the HGW (FIG. 7). Example).
[0199]
A method from user registration to extraction from the HGW shown in FIG. 7 will be described. Here, as an example, two users are registered in the HGW (HGW whose HGW-ID is 100, hereinafter HGW1), and one user is registered in the HGW (HGW whose HGW-ID is 200, hereinafter HGW2). Assuming that Further, in order to take out content from the HGW, a content take-out terminal connected to the HGW such as a PC is required.
[0200]
1) User registration process to HGW
The HGW needs to register a user who uses the HGW. User registration in the HGW is a process of registering the user ID and password of the user. In the HGW, the user ID and password input by the user are held in a user registration file inside the HGW. Here, duplicate user IDs are not allowed. The user registration file is stored with a pair of user ID and password.
[0201]
In this example, in the HGW 1, two users, a user having AAAA as a user ID (hereinafter referred to as user AAAA) and a user having BBBB as a user ID (user BBBB) are registered.
[0202]
User AAAA has a user ID (AAAAA) and password
User BBBB has user ID (BBBB) and password
Is registered with the HGW. Here, the password registered by each user can be registered by specifying an arbitrary character string.
[0203]
In HGW2, one user (user CCCC) having CCCC as a user ID is registered. The user CCCC registers a user ID (CCCC) and a password with the HGW.
[0204]
2) Reservation delivery processing
Next, there is a process of distributing the content reserved by the user from the order terminal to the HGW from the portal.
[0205]
Details of the user reservation process will be described later. In the example of the distribution process to the HGW, it is assumed that the user AAAA reserves the distribution of the content A, the user BBBB also reserves the distribution of the content B, and the user CCCC reserves the distribution of the content C. The content is delivered to the HGW where the reserved user has registered as a user. That is, since both the user AAAA and the user BBBB are registered as users in the HGW 1, the contents A and the contents B are delivered to the HGW 1. The content C is delivered to the HGW 2 where the user CCCC is registered as a user. The content delivered to the HGW is stored in a memory area reserved corresponding to each user ID registered in the HGW.
[0206]
3) Content retrieval processing from HGW
Since a plurality of users may be registered in the HGW, a plurality of contents reserved by a plurality of users are simultaneously stored in one HGW. From these, it is necessary for each user to retrieve only the content reserved by him / her. That is, when content is extracted from the HGW, each user registered in the HGW is allowed to extract only the content reserved by himself / herself, and is not permitted to extract the content reserved by other users.
[0207]
The HGW receives the user ID and password input by the user from the content retrieval terminal. The HGW checks the received user ID and password against the user ID and password registered in the user registration file. When the received user ID and password are included in the user registration file, the content distributed to the user having the user ID is transferred to the take-out terminal. In the above example, since only one CCCC user is registered in the HGW 2, only the user CCCC needs to take out the content C distributed and stored in the HGW 2.
[0208]
In HGW1, two users, AAAA and BBBB, are registered. When AAAA and a password are received as the user ID from the takeout terminal connected to the HGW 1, the content A distributed to the user AAAA is taken out and passed to the takeout terminal. Similarly, when BBBB and a password are received as the user ID, the content B distributed to the user BBBB is taken out and passed to the terminal.
[0209]
Although the invention made by the present inventor has been specifically described based on the embodiment (example), the invention is not limited to the embodiment (example), and departs from the gist thereof. Of course, various changes can be made without departing from the scope.
[0210]
【The invention's effect】
The effects obtained by the representative ones of the inventions disclosed in the present application will be briefly described as follows.
[0211]
According to the present invention, traffic between a client and a server can be reduced.
[0212]
Further, when a pay line is used between the client and the server, useless line use costs can be reduced.
[Brief description of the drawings]
FIG. 1 is a flowchart showing the operation of a file transfer control unit according to an embodiment (example) of the present invention.
FIG. 2 is a flowchart showing an operation of a file transfer execution unit of the present embodiment.
FIG. 3 is a sequence chart in the case of normal termination without occurrence of interruption of the present embodiment.
FIG. 4 is a sequence chart in the case where the interruption of the present embodiment occurs once, but is restored by the next restart and is normally terminated.
FIG. 5 is a sequence chart in the case of interruption in the middle of the present embodiment and time-out as it is.
FIG. 6 is a diagram for explaining extraction of data from the HGW to the PC according to the present embodiment.
FIG. 7 is a diagram illustrating a relationship between a user and an HGW according to the present embodiment.
FIG. 8 is a flowchart illustrating a conventional download resume algorithm.

Claims (2)

帯域が保証されていないデータ配信システム（ネットワーク）における、ファイル転送の中断再開が可能なダウンロード方法において、ダウンロードが中断した際、クライアントマシンが、ダウンロードするサーバマシンとの過去Ｘ（Ｘは固定値、設定により可変）秒のスループット（以下、Ｓと称する）が事前に設定した閾値（以下、Ｓｍｉｎと称する）を超える（Ｓ＞Ｓｍｉｎ）場合は、（Ｆ−１）回（Ｆは固定値、設定により可変）は、短時間（ウェイトタイマー値Ｔｓ）で再開を試み、Ｆ回以上連続して再開に失敗した場合は、ウェイトタイマー値ＴｓをＴｌ（＞Ｔｓ）に設定変更して再開を試み、Ｓ≦Ｓｍｉｎの場合は、短時間（ウェイトタイマー値Ｔｓ）で再開を試みることを特徴とするダウンロード方法。In a data distribution system bandwidth is not guaranteed (network), the download method capable suspend resume file transfer, when the download is interrupted, the client machine, past X (X is a fixed value to the server machine to be downloaded, setting the variable) s throughput (hereinafter, threshold value referred to as S) was set in advance (hereinafter, exceeds referred Smin) (S> Smin) field if the, (F-1) times (F is a fixed value, setting the variable) by, attempts to restart in a short time (the wait timer value Ts), if it fails to restart or more consecutive F times, the restart setting change window Eitotaima value Ts to Tl (> Ts) attempts, in the case of S ≦ Smin, download method, characterized in that attempting to restart in a short time (the wait timer value Ts). 帯域が保証されていないデータ配信システム（ネットワーク）における、ファイル転送の中断再開が可能なダウンロード方法の処理手順を、コンピュータに実行させるためのプログラムを記憶したコンピュータが読み出し可能な記憶媒体であって、ダウンロードが中断した際、ダウンロードするサーバマシンとの過去Ｘ（Ｘは固定値、設定により可変）秒のスループット（以下、Ｓと称する）が事前に設定した閾値（以下、Ｓｍｉｎと称する）を超える（Ｓ＞Ｓｍｉｎ）場合は、（Ｆ−１）回（Ｆは固定値、設定により可変）は、短時間（ウェイトタイマー値Ｔｓ）で再開を試みる手順と、Ｆ回以上連続して再開に失敗した場合は、ウェイトタイマー値をＴｌ（＞Ｔｓ）に設定変更して再開を試みる手順と、Ｓ≦Ｓｍｉｎの場合は、短時間（ウェイトタイマー値＝Ｔｓ）で再開を試みる手順を、コンピュータに実行させるためのプログラムを記憶したコンピュータが読み出し可能な記憶媒体。A computer-readable storage medium storing a program for causing a computer to execute a processing procedure of a download method capable of interrupting and resuming file transfer in a data distribution system (network) whose bandwidth is not guaranteed, When the download is interrupted, the past X (X is a fixed value, variable depending on the setting) seconds throughput (hereinafter referred to as S) with the server machine to be downloaded exceeds a preset threshold (hereinafter referred to as Smin) ( S> Smin) field if the, (F-1) times (F is a fixed value, variable) by setting, the procedure attempts to restart in a short time (the wait timer value Ts), fail to resume continuous or F times If you, the procedure attempts to restart setting change window Eitotaima value Tl (> Ts), in the case of S ≦ Smin, short time (Weight timer value = Ts) in a procedure to attempt to restart the computer readable storage medium storing a program to be executed by a computer.
JP2000214562A 2000-07-14 2000-07-14 Download method in data distribution system and storage medium storing program thereof Expired - Fee Related JP3666796B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2000214562A JP3666796B2 (en) 2000-07-14 2000-07-14 Download method in data distribution system and storage medium storing program thereof

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2000214562A JP3666796B2 (en) 2000-07-14 2000-07-14 Download method in data distribution system and storage medium storing program thereof

Publications (2)

Publication Number Publication Date
JP2002032284A JP2002032284A (en) 2002-01-31
JP3666796B2 true JP3666796B2 (en) 2005-06-29

Family

ID=18710116

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000214562A Expired - Fee Related JP3666796B2 (en) 2000-07-14 2000-07-14 Download method in data distribution system and storage medium storing program thereof

Country Status (1)

Country Link
JP (1) JP3666796B2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210385512A1 (en) * 2015-06-01 2021-12-09 Comcast Cable Communications, Llc Transmission of applications with content

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2856489B1 (en) * 2003-06-23 2005-08-26 Bouygues Telecom Sa METHOD FOR DOWNLOADING FILES ON MOBILE EQUIPMENT
US7853609B2 (en) * 2004-03-12 2010-12-14 Microsoft Corporation Update distribution system architecture and method for distributing software
US8266260B2 (en) 2007-12-11 2012-09-11 Sharp Laboratories Of America, Inc. Method and system for updating the software of multiple network nodes
CN102790917B (en) * 2011-05-19 2016-02-17 上海贝尔股份有限公司 Interactive multi-screen business tine transmission method and equipment
JP2022158591A (en) * 2021-04-02 2022-10-17 株式会社デンソー Map information output device, automatic driving control system, map information output system, and map information output method
JP7399929B2 (en) * 2021-11-26 2023-12-18 株式会社日立製作所 Information processing system, information processing method, and program

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210385512A1 (en) * 2015-06-01 2021-12-09 Comcast Cable Communications, Llc Transmission of applications with content
US11595705B2 (en) * 2015-06-01 2023-02-28 Comcast Cable Communications, Llc Transmission of applications with content

Also Published As

Publication number Publication date
JP2002032284A (en) 2002-01-31

Similar Documents

Publication Publication Date Title
JP3139408B2 (en) Homepage update notification device
US7945673B2 (en) Reduced wireless internet connect time
US6742023B1 (en) Use-sensitive distribution of data files between users
US20050125456A1 (en) File migration method based on access history
JP2005513617A (en) System and method for downloading data using a proxy
WO1998040831A1 (en) System and method for selection and retrieval of diverse types opf video data on a computer network
JPH11272711A (en) Information providing system
JP2002540491A (en) Web server content replication
US20040117461A1 (en) Download system and downloading device
JP3666796B2 (en) Download method in data distribution system and storage medium storing program thereof
KR20010095113A (en) Information processing device, server connection method, program storage medium, and network system
JP2006209571A (en) Image forming apparatus, and system for distributing printer driver
JP2927259B2 (en) Download device
US20050086357A1 (en) Method and system for distributing images to client systems
JP3528681B2 (en) Information processing terminal
JP2005063153A (en) Information distribution system, terminal device, server device, method for distributing information, and program for terminal device
JP2003067194A (en) Terminal device
JP2003208367A (en) Service use device
JP3933452B2 (en) Support method and support server for supporting acquisition of information
JP3915115B2 (en) Computer and computer program
EP1345377B1 (en) Method for scheduling of file transfers for wireless networks
KR100391952B1 (en) Using server-side application direct file execution method on AIP system
JP2003051846A (en) Band control method, network service system, contents server device, band management device and contents management device
JP2003087433A (en) Internet connection method and system, and computer program
JP2006344115A (en) Server, and information processing method and program therefor

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20050208

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050302

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20050329

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20050401

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090415

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090415

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100415

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100415

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110415

Year of fee payment: 6

LAPS Cancellation because of no payment of annual fees