JP2002032284A - データ配信システムにおけるダウンロード方法及びそのプログラムを記憶した記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 無駄なトラフィックを抑制しつつ、できるだ
け短時間にダウンロードを終了する。 【解決手段】 帯域が保証されていないデータ配信シス
テム（ネットワーク）における、ファイル転送の中断再
開が可能なダウンロード方法において、ダウンロードの
中断再開タイマー値を可変とし、データダウンロード実
行中の平均スループットをパラメータとして中断再開タ
イマー値を制御する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データ配信システ
ムにおけるダウンロード方法（配信予約方法）及びファ
イル転送を行うダウンロードプログラムを記録したクラ
イアントの記録媒体に関する。

【０００２】

【従来の技術】ダウンロードの中断再開を可能とするソ
フトウェアモジュールとして、パソコン上のｉｒｉａ
（フリーウェア）等のダウンロード支援ソフトウェアを
利用する方法がある。

【０００３】ダウンロード支援ソフトウェアは、ＦＴＰ
（ファイル転送）及びＨＴＴＰ（Ｗｅｂ）から自分のパ
ソコンにファイルのダウンロードを行い、希望のファイ
ルを確実にダウンロードすることを目的としており、フ
ァイルをダウンロードしようとしているサーバーがビジ
ー（忙しい状態）もしくは反応が無かった場合には、ダ
ウンロードが完了するまでリトライ（再試行）すること
ができる。ＨＴＴＰとＦＴＰのどちらからでも、中断さ
れた位置からダウンロードをレジューム（再開）するこ
とができる。

【０００４】さらに、複数のファイルを同時にダウンロ
ードすることもできる。また、スケジューリング機能
（以下、予約配信機能）として、指定された時刻にイン
ターネットプロバイダに自動接続してファイルをダウン
ロードしたり、逆に、接続を切断したりすることができ
る。

【０００５】但し、これらのダウンロード支援ソフトウ
ェアにおいて、ダウンロード中断時の、ダウンロード再
開方法は、図８に示すように、サーバマシンからクライ
アントマシンヘのダウンロード開始後に、ダウンロード
状況を判定し、データを全て受信完了する前にデータ受
信の失敗によりタウンロード中断が生じた場合、ウェイ
トタイマー値Ｔｓの時間（定数）待って、ダウンロード
を再開していた。このウェイトタイマー値Ｔｓは、固定
の設定値であった。

【０００６】

【発明が解決しようとする課題】この場合、ダウンロー
ド中断が連続して生じた場合は、ウェイトタイマー値Ｔ
ｓという定数を基に再送を行っていた。

【０００７】しかし、この再送を行う時点で、（ａ）サ
ーバマシンとクライアントマシン間の通信路に、一時的
な何らかのトラブルが生じている、（ｂ）一時的にサー
バのダウンロードプロセスが高負荷により停止している
等の事象が発生している可能性があり、その場合は、い
くらリトライしても、ダウンロードは再開されず、
（ｃ）ダウンロードセッションの確立による、無駄なト
ラフィックの発生が生じていた。もし、クライアントと
サーバの間にダウンロードのセッションを確立するため
に有料の回線を利用する場合には、無駄な回線使用コス
トが生じていた。

【０００８】本発明の目的は、無駄なトラフィックを抑
制しつつ、できるだけ短時間にダウンロードを終了する
ことが可能な技術を提供することにある。

【０００９】本発明の前記ならびにその他の目的と新規
な特徴は、本明細書の記述及び添付図面によって明らか
にする。

【００１０】

【課題を解決するための手段】本願において開示される
発明の概要を簡単に説明すれば、下記のとおりである。

【００１１】（１）帯域が保証されていないデータ配信
システム（ネットワーク）における、ファイル転送の中
断再開が可能なダウンロード方法において、ダウンロー
ドの中断再開タイマー値を可変とし、データダウンロー
ド実行中の平均スループットをパラメータとして中断再
開タイマー値を制御する。

【００１２】（２）帯域が保証されていないデータ配信
システム（ネットワーク）における、ファイル転送の中
断再開が可能なダウンロード方法において、ダウンロー
ドが中断した際、ダウンロードするサーバマシンとの過
去Ｘ（Ｘは固定値、設定により可変）秒のスループット
Ｓが事前に設定した閾値Ｓｍｉｎ以上（Ｓ≧Ｓｍｉｎ）
であった場合は、一時的な回線または一時的なサーバ障
害の疑いと判定し、（Ｆ−１）回（Ｆは固定値、設定に
より可変）は、ウェイトタイマー値Ｔｓ（短時間）で再
開を試み、Ｆ回以上連続して再開に失敗した場合は、何
らかの一時的障害が発生したと判定し、ウェイトタイマ
ー値ＴｓをＴｌ（≧Ｔｓ，Ｔｌの“ｌ”はＬの小文字）
に設定変更して再開を試み、Ｓ≦Ｓｍｉｎの場合は、恒
久的に回線状況が悪いと判断し、ウェイトタイマー値Ｔ
ｓで再開を試みる。

【００１３】ここで、Ｔｌ、Ｔｓは、ともに回線の実効
帯域が理想値の場合、ダウンロードが中断せずに完了し
たと仮定した場合の予想ファイル転送時間（Ｔｄｏｗ
ｎ）に対しては、非常に短い値とする。

【００１４】（３）帯域が保証されていないデータ配信
システム（ネットワーク）における、ファイル転送の中
断再開が可能なダウンロード方法の処理手順を、コンピ
ュータに実行させるためのプログラムを記憶したコンピ
ュータが読み出し可能な記憶媒体であって、ダウンロー
ドが中断した際、ダウンロードするサーバマシンとの過
去Ｘ（Ｘは固定値、設定により可変）秒のスループット
Ｓが事前に設定した閾値Ｓｍｉｎ以上（Ｓ≧Ｓｍｉｎ）
であった場合は、一時的な回線または一時的なサーバ障
害の疑いと判定する手順と、（Ｆ−１）回（Ｆは固定
値、設定により可変）は、ウェイトタイマー値Ｔｓ（短
時間）で再開を試みる手順と、Ｆ回以上連続して再開に
失敗した場合は、何らかの一時的障害が発生したと判定
する手順と、ウェイトタイマー値ＴｓをＴｌ（≧Ｔｓ）
に設定変更して再開を試みる手順と、Ｓ≦Ｓｍｉｎの場
合は、恒久的に回線状況が悪いと判断する手順と、ウェ
イトタイマー値Ｔｓで再開を試みる手順を、コンピュー
タに実行させるためのプログラムを記憶したコンピュー
タが読み出し可能な記憶媒体である。

【００１５】前記本発明の手段によれば、中断再開が可
能なファイルのダウンロードを行う場合に、ダウンロー
ドの中断再開タイマー値を可変とし、データダウンロー
ドが成功している時の平均スループット（ｎｏｔ＝直前
のスループット）を保持し、中断発生時には、そのスル
ープットをパラメータとして、スループット高で予め設
定した回数連続して中断が発生したら、中断再開タイマ
ー値を長くし、スループット低なら何度連続して中断が
発生しても、中断再開タイマー値を維持することによ
り、クライアントとサーバの間のトラフィックを軽減で
きるので、できるだけ早くダウンロードを完了させるこ
とができる。また、クライアントとサーバ間で有料の回
線を利用する場合は、無駄な回線使用コストを軽減でき
る。

【００１６】以下に、本発明について、本発明による実
施形態（実施例）とともに図面を参照して詳細に説明す
る。

【００１７】

【発明の実施の形態】本発明による一実施形態は、ダウ
ンロードの中断再開タイマー値の制御方法において、生
じる中断再開タイマーの制御方法として、ダウンロード
が中断した際、ダウンロードするサーバマシンとの過去
Ｘ（Ｘは固定値、設定により可変）秒のスループットＳ
が事前に設定した閾値Ｓｍｉｎ以上（Ｓ≧Ｓｍｉｎ）で
あった場合は、一時的な回線または一時的なサーバ障害
の疑いと判定し、（Ｆ−１）回（Ｆは固定値、設定によ
り可変）は、ウェイトタイマー値Ｔｓ（短時間）で再開
を試みる。Ｆ回以上連続して再開に失敗した場合は、何
らかの一時的障害が発生したと判定し、ウェイトタイマ
ー値ＴｓをＴｌ（≧Ｔｓ）に設定変更して再開を試み
る。

【００１８】また、Ｓ≦Ｓｍｉｎの場合は、恒久的に回
線状況が悪いと判断し、ウェイトタイマー値Ｔｓ（短時
間）で再開を試みる。

【００１９】ここで、Ｔｌ、Ｔｓは、ともに回線の実効
帯域が理想値の場合、ダウンロードが中断せずに完了し
たと仮定した場合の予想ファイル転送時間（Ｔｄｏｗ
ｎ）に対しては、非常に短い値とする。すなわち、Ｔｄ
ｏｗｎ≫Ｔｌ＞Ｔｓである。具体的には、ダウンロード
対象のファイルサイズが、８ＭＢ（＝６４０００ｋｂｉ
ｔ）で、回線帯域が６４ｋｂｉｔ／ｓｅｃの場合は、Ｔ
ｄｏｗｎ＝６４０００／６４＝１０００ｓｅｃとなり、
この場合の、Ｔｌ、Ｔｓはそれぞれ６０ｓｅｃ、１０ｓ
ｅｃ程度を想定している。勿論、これらの値は、状況に
応じて、適切な値に設定することが望ましいし、もしく
は、ファイルのダウンロードを実行する毎に回線速度と
ファイルサイズファイルから適切なＴｌ、Ｔｓを計算し
て、設定する方法でもよい。

【００２０】前記のダウンロード中断再開におけるウェ
イトタイマー値Ｔｓの制御方法が、無駄なトラフィック
を抑制しつつ、できるだけ速くダウンロードを完了させ
る根拠としては、以下の（ａ）及び（ｂ）が挙げられ
る。

【００２１】（ａ）ダウンロード実行時のスループット
が高くて、ダウンロードが中断した場合は、サーバまで
の回線状況が一時的に悪化して、ダウンロードが中断し
たと推定される。通常は、数回（以下、Ｆ回とする）の
リトライでダウンロード再開に成功することが普通であ
り、もし、Ｆ回のリトライでダウンロード再開に成功し
なかった場合も、再開後、高いスループットでのダウン
ロードが期待されるので、Ｆ＋１回以降のリトライは、
ウェイトタイマー値Ｔｓを長めに設定しても、トータル
の転送時間は、短く完了する。

【００２２】（ｂ）ダウンロード実行時のスループット
が低くて、ダウンロードが中断した場合は、サーバまで
の回線状況が一時的ではなく、恒久的に悪く、ダウンロ
ードが中断しやすい状態と考えられる。よってダウンロ
ードの中断が回線状況が悪いことが原因で頻繁に生じる
ことが予想されるため、再開までのウェイトタイマー値
を大きくすることは、意味がなく、逆に、頻繁にアクセ
スして、少しずつのデータ量でもよいから、ダウンロー
ドを実行したほうが効率的である。

【００２３】本発明を実現するダウンロード方法及びそ
のプログラムを記憶した記憶媒体の中には、ファイル転
送実行部とファイル転送制御部の２つを設ける。

【００２４】ファイル転送実行部は、サーバから実際に
データを受信、格納するモジュールである。ダウンロー
ドアルゴリズムは、中断再開に対応しているプロトコル
である必要があり、現時点では、ＨＴＴＰのファイル受
信プロトコルが望ましい。勿論、将来的にＦＴＰ等のＴ
ＣＰ／ＩＰ汎用ファイル転送プロトコルが中断再開に対
応すれば、そのプロトコルであってもよいし、ＴＣＰ／
ＩＰを使っていれば、独自のプロトコルでもよい。

【００２５】前記ファイル転送実行部は、既存のファイ
ル転送モジュールであり、特に新規性はないが、ダウン
ロード状況として、 i）データを全て受信完了したか？ ii)データを受信失敗してダウンロードを中断したか？ iii)データを受信実行中で、かつ残りのデータがあるか
？ を外部のモジュールから判定できるようにしておく必要
がある。

【００２６】この実現手法の一例としては、プロセスの
終了時に、その終了の理由を示すステータスコードファ
イルを生成し、外部からそれを参照する方法があるが、
他にどんな方法でもダウンロード状況が判定できればそ
れでよい。

【００２７】以下に、プロセスの終了時にステータスコ
ードファイルを生成する方法の代表例を以下に説明す
る。ステータスコードファイルの内容は、 （ａ）データを受信失敗してダウンロードを中断した場
合：エラー終了 （ｂ）データを全て受信完了した場合：正常終了 （ｃ）データを受信実行中で、かつ残りのデータがない
場合：ファイル未作成 とする。

【００２８】また、ダウンロードのスループットを計算
するため、ダウンロードしたファイルサイズを保持し、
外部からそれを参照する機能も必要である。この実現手
法の一例として、ファイルをダウンロードする毎に、ダ
ウンロードしたファイルサイズを別のファイル（以下、
ダウンロード済みファイルサイズファイル）に記憶して
おく方法があるが、ファイルではなく、メモリ空間でも
よいし、他にどんな方法でもファイルサイズを保持でき
ればよい。

【００２９】前記ファイル転送制御部は、前記ファイル
転送実行部に対して、ダウンロードの開始、再開及び再
開までのウェイトタイマー値Ｔｓを制御するモジュール
である。

【００３０】図１は、本実施形態の一実施例のファイル
転送制御部の動作を示すフローチャートである。図１に
おいて、各定数、変数の説明は、以下のとおりである。

【００３１】初期設定を行う定数としては、 Ｔｓ：間隔の短いタイマー値（ｓｅｃ） Ｔｌ：間隔の長いタイマー値（Ｔｌ＞Ｔｓ）（ｓｅｃ） Ｓｍｉｎ：回線状況良好と判定するスループットの最小
値 Ｆｍｉｎ：高スループット状態でのデータ受信連続許容
失敗回数 Ｘｔｉｍｅｒ：スループットを観測する間隔 また、変数としては、 Ｓ：データ受信時の過去Ｘ秒のスループット（ｋｂｉｔ
／ｓｅｃ） Ｆ：高スループット状態でのデータ受信連続失敗回数 Ｔｉｍｅ：ダウンロード開始からの経過時間（ｓｅｃが
最小単位、端数は切り捨て）を用いる。

【００３２】本実施例のファイル転送制御部は、図１に
示すように、ステップ（ｓｔｅｐ）０をスタート（ＳＴ
ＡＲＴ）とする。ステップ０では、演算制御の初期値と
してＳ＝０、Ｆ＝０をセットし、ステップ１に進む。

【００３３】ステップ１において、ファイル転送制御部
は、ファイル転送実行部に対してダウンロード開始指示
を出し、Ｔｉｍｅ＝０にセットし、ステップ２に進む。

【００３４】ステップ２では、ダウンロードの状況を判
定する。ダウンロード状況の判定は、ファイル転送実行
部からステータスコードファイルを読み出すことにより
行う。

【００３５】ステータスコードファイルが生成されてい
ない場合は、データを受信成功し、かつ、残りのデータ
があると判定しステップ７に進む。

【００３６】ステータスコードファイルの内容がエラー
終了の場合、ステップ３に進む。

【００３７】ステータスコードファイルの内容が正常終
了の場合は、処理を終了する。

【００３８】ステップ７では、データの受信が成功して
いるため変数Ｆを０にセットしステップ１３に進む。

【００３９】ステップ１１では、ダウンロード時間（Ｔ
ｉｍｅ）が、設定値Ｘを既に経過しているか否かを判定
する。具体的には、Ｔｉｍｅ≧Ｘを判定し、真なら、ス
テップ１２に進む。偽なら、ステップ１３に進む。

【００４０】ステップ１２では、ダウンロード時間（Ｔ
ｉｍｅ）が、スループットの測定タイミングであるかを
判定する。すなわち、Ｔｉｍｅが、Ｘｔｉｍｅｒの整数
倍か否かを判定する。具体的には、（Ｔｉｍｅ）ｍｏｄ
（Ｘｔｉｍｅｒ）＝０を判定し、真なら、ステップ８に
進む。偽なら、ステップ１３に進む。

【００４１】ステップ８では、過去Ｘ秒の平均スループ
ットを計算してＳとして保持し、ステップ２へ進む。平
均スループットは、（ダウンロード済みファイルサイズ
ファイルの過去Ｘ秒の増加分）／Ｘの計算式から求め
る。ステップ１３へ進む。

【００４２】ステップ１３では、ファイル転送制御部の
処理の負荷を軽減するため、処理を１秒に一回に制限す
るために、１秒のウェイトを置き、ステップ２へ遷移す
る。

【００４３】ステップ３では、データ受信時の過去Ｘ秒
のスループットが回線状況良好と判定するスループット
の最小値よりも大きいか否かを判定する。具体的には、
Ｓ＞Ｓｍｉｎを判定し、真なら、一時的な回線またはサ
ーバ障害の疑いありと判定し、ステップ４に進む。偽な
ら、回線状況が良好でないと判定し、ステップ９に進
む。

【００４４】ステップ４では、ここに遷移するのは高ス
ループット状態でのデータ受信連続失敗が一回増加した
場合であるから、Ｆを１インクリメントする。すなわ
ち、Ｆ＝Ｆ＋１の演算を行う。

【００４５】ステップ５では、高スループット状態での
データ受信連続失敗が、高スループット状態でのデータ
受信連続許容失敗回数以上に達したかを判定する。具体
的には、Ｆ≧Ｆｍｉｎを判定し、真なら、一時的な回線
またはサーバ障害発生と判定し、ステップ６に進む。偽
なら、ステップ９に進む。

【００４６】ステップ６では、Ｔｌのウェイトタイマー
値のウェイトを置く。そしてステップ１０に進む。

【００４７】ステップ９では、Ｔｓのウェイトタイマー
値のウェイトを置く。そしてステップ１０に進む。

【００４８】ステップ１０において、ファイル転送制御
部は、ファイル転送実行部に対してダウンロード再開指
示を出し、Ｔｉｍｅ＝０にセットし、ステップ２に進
む。

【００４９】図２は、本実施形態のファイル転送実行部
の動作を示すフローチャートである。

【００５０】本実施形態のファイル転送実行部は、図２
に示すように、ステップＡは処理のスタート（ＳＴＡＲ
Ｔ）である。これは、ファイル転送制御部から、ダウン
ロード開始指示を受信することにより、スタートする。
この時、ステータスコードファイルは消去し、ステップ
Ｂに進む。

【００５１】ステップＢで、ファイルのダウンロードを
試みる。ステップＣに進む。

【００５２】ステップＣで、ダウンロードエラーが発生
したか否かを判定する。ダウンロードエラーが発生して
いたら、ステップＨに進む。エラーが発生しておらず、
ダウンロードが正常に行えた場合は、ステップＤに進
む。

【００５３】ステップＤで、受信したデータをファイル
に格納し、再開指示の場合は、従来ダウンロードしたフ
ァイルの後ろにデータをアペンドする。ステップＥに進
む。

【００５４】ステップＥで、受信したファイルのデータ
長をダウンロード済みファイルサイズファイルに格納
し、ステップＦに進む。

【００５５】ステップＦでは、ダウンロードが完了した
か否かを判定する。ダウンロードが完了していたらステ
ップＧに進む。ダウンロードが未完了の場合は、ステッ
プＢに進む。

【００５６】ステップＧでは、ステータスコードファイ
ルに正常終了を示す情報を書き込み、処理を終了する。

【００５７】ステップＨでは、ステータスコードファイ
ルにエラー終了を示す情報を書き込み、処理を終了す
る。

【００５８】次に、ファイル転送制御部、ファイル転送
実行部、ポータルの各ノード間のシーケンスチャートの
例を図３、図４、図５に示す。ポータルは、ダウンロー
ドするコンテンツが格納されているサーバである。

【００５９】図３は、中断が一度も発生せずに正常終了
した場合のシーケンスであり、図４は、中断が１回発生
したが、次の再開で復旧して、正常終了の場合のシーケ
ンスである。図５は、途中で中断し、そのまま時間切れ
の場合のシーケンスチャートである。

【００６０】（実施例１）本実施形態の実施例１は、ダ
ウンロードクライアントソフトウェアがサーバからデー
タを受信し、ダウンロードエラーが発生しなかった場合
の処理の流れの実施例である。

【００６１】本実施例１においての各種条件は、 ・コンテンツのファイルサイズ＝８０００ＫＢ＝６４０
００ｂｉｔ ・回線帯域が６４ｋｂｉｔ／ｓｅｃ ・Ｔｌ＝６０ｓｅｃ ・Ｔｓ＝１０ｓｅｃ ・Ｓｍｉｎ＝４０（ｋｂｉｔ／ｓｅｃ） ・Ｆｍｉｎ＝２（回） ・Ｘ＝３０ｓｅｃ ・Ｘｔｉｍｅｒ＝５ｓｅｃ ・ダウンロード実行部のダウンロードプロトコル：ＨＴ
ＴＰプロトコルによるダウンロード である。以下、前記図１及び図２のフローチャートにつ
いてファイル転送実行部及びファイル転送制御部の処理
の流れを時系列的に説明する。

【００６２】（ファイル転送実行部の動作）図２に示す
ように、ファイル転送制御部からのダウンロード開始指
示を受けると処理を開始し、ステップＢに進みＨＴＴＰ
プロトコルによるダウンロードを実行する。ステップＣ
に進む。

【００６３】ステップＣでは、ダウンロードエラー発生
の判定を行う。ここでは、エラーが発生しなかったの
で、ステップＤに進む。

【００６４】ステップＤで、受信したデータをファイル
に格納し、ステップＥで、受信したデータ長をダウンロ
ード済ファイルサイズファイルに格納し、ステップＦに
進む。ステップＦではダウンロードが完了したか否かを
判定するが、ここでは、まだダウンロードが完了してい
ないので、ステップＢに戻る。

【００６５】ここで、ステップＢ→ステップＣ→ステッ
プＤ→ステップＥ→ステップＦ→ステップＢを繰り返
す。

【００６６】ここで、繰り返し処理の間、その時点で、
ダウンロード済みファイルの容量（＝ダウンロード済み
ファイルサイズファイルの内容）は、単調に増えてい
く。すなわち、 Ｔｉｍｅ＝０ｓｅｃの時は、０ｋｂｉｔ Ｔｉｍｅ＝１ｓｅｃの時は、６４ｋｂｉｔ Ｔｉｍｅ＝５ｓｅｃの時は、３２０ｋｂｉｔ Ｔｉｍｅ＝１０ｓｅｃの時は、６４０ｋｂｉｔ Ｔｉｍｅ＝３０ｓｅｃの時は、１９２０ｋｂｉｔ Ｔｉｍｅ＝３５ｓｅｃの時は、２２４０ｋｂｉｔ Ｔｉｍｅ＝１００ｓｅｃの時は、６４００ｋｂｉｔ Ｔｉｍｅ＝９６５ｓｅｃの時に、６１７６０ｋｂｉｔ Ｔｉｍｅ＝９９５ｓｅｃの時に、６３６８０ｋｂｉｔで
ある。Ｔｉｍｅ＝１０００ｓｅｃの時に、６４０００ｋ
ｂｉｔとなり、ステップＦのダウンロード完了判定で、
ダウンロード完了と判定し、ステップＧに進み、ステー
タスコードファイルをクリエイトして正常終了を示す情
報を書込み、ファイル転送実行部の処理を終了する。

【００６７】（ファイル転送制御部の動作）図１におい
て、ステップ０でＳ＝０、Ｆ＝０と設定する。ステップ
１に進む。

【００６８】ステップ１において、ファイル転送制御部
は、ファイル転送実行部に対してダウンロード開始指示
を出し、Ｔｉｍｅを０ｓｅｃに設定し、ステップ２に進
む。

【００６９】ステップ２では、ダウンロードの状況を判
定する。ダウンロード状況の判定は、ファイル転送実行
部からステータスコードファイルを読み出すことにより
行う。この時点ではダウンロードが終了していないの
で、ステータスコードファイルが生成されていないの
で、データを受信成功し、かつ、残りのデータがあると
判定し、ステップ７に進む。

【００７０】ステップ７では、データの受信が成功して
いるため変数Ｆを０にセットしステップ１１に進む。

【００７１】ステップ１１では、Ｔｉｍｅ≧Ｘを判定す
る。ここでは、Ｔｉｍｅ＝０、Ｘ＝３０であるため、偽
と判定されステップ１３へ遷移する。ステップ１３で１
秒のウェイトを置き、ステップ２へ遷移する。

【００７２】以下、Ｔｉｍｅ＝３０まで、ステップ２→
ステップ７→ステップ１１→ステップ１３の処理を繰り
返す。Ｔｉｍｅ＝３０における、ステップ１１の処理で
Ｔｉｍｅ＝３０、Ｘ＝３０であるため、真と判定されス
テップ１２へ遷移する。

【００７３】ステップ１２では、ダウンロード時間（Ｔ
ｉｍｅ）が、スループットの測定タイミングであるかを
判定する。すなわち、Ｔｉｍｅが、Ｘｔｉｍｅｒの整数
倍か否かを判定する。具体的には、（Ｔｉｍｅ）ｍｏｄ
（Ｘｔｉｍｅｒ）＝０を判定する。ここでは、１０ｍｏ
ｄ５＝０なので、真と判定し、ステップ８に進む。

【００７４】ステップ８では、過去Ｘ秒の平均スループ
ットを計算してＳとして保持する。平均スループット
は、（ダウンロード済みファイルサイズファイルの過去
Ｘ秒の増加分）／Ｘの計算式から求めるが、ここでは、
ファイル転送実行部のダウンロード済みファイルサイズ
ファイルの過去Ｘ秒の増加分は１９２０ｋｂｉｔ−０ｋ
ｂｉｔ＝１９２０ｋｂｉｔなので、１９２０ｋｂｉｔ／
３０ｓｅｃ＝６４（ｋｂｉｔ／ｓｅｃ）となる。ステッ
プ１３に進む。ステップ１３では、１秒のウェイトを置
き、ステップ２へ遷移する。

【００７５】ステップ２では、ダウンロードの状況を判
定する。ダウンロード状況の判定は、ファイル転送実行
部からステータスコードファイルを読み出すことにより
行う。この時点ではダウンロードが終了していないの
で、ステータスコードファイルが生成されていないの
で、データを受信成功し、かつ残りのデータがあると判
定しステップ７に進む。

【００７６】ステップ７では、データの受信が成功して
いるため変数Ｆを０にセットしステップ１１に進む。ス
テップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、
Ｔｉｍｅ＝３１、Ｘ＝３０であるため、真と判定されス
テップ１２へ遷移する。

【００７７】ステップ１２では、ダウンロード時間（Ｔ
ｉｍｅ）が、スループットの測定タイミングであるかを
判定する。ここでは、３１ｍｏｄ５＝１なので、偽と判
定し、ステップ１３に進む。

【００７８】以下、Ｔｉｍｅ＝３５までステップ２→ス
テップ７→ステップ１１→ステップ１２→ステップ１３
の処理を繰り返す。

【００７９】Ｔｉｍｅ＝３５におけるステップ１２の処
理で３５ｍｏｄ５＝０なので、真と判定し、ステップ８
に進む。ステップ８では、過去Ｘ秒の平均スループット
を計算してＳとして保持する。平均スループットは、
（ダウンロード済みファイルサイズファイルの過去Ｘ秒
の増加分）／Ｘの計算式から求めるが、ここでは、ファ
イル転送実行部のダウンロード済みファイルサイズファ
イルの過去Ｘ秒の増加分は２２４０ｋｂｉｔ−３２０ｋ
ｂｉｔ＝１９２０ｋｂｉｔなので、１９２０ｋｂｉｔ／
３０ｓｅｃ＝６４（ｋｂｉｔ／ｓｅｃ）となる。ステッ
プ１３に進む。

【００８０】ステップ１３では、ファイル転送制御部の
処理の負荷を軽減するため、処理を１秒に一回に制限す
るために、１秒のウェイトを置き、ステップ２へ遷移す
る。

【００８１】以下、同様にステップ２〜ステップ１３処
理を行い、Ｔｉｍｅ＝９９５となったとする。

【００８２】ステップ２では、ダウンロードの状況を判
定する。ダウンロード状況の判定は、ファイル転送実行
部からステータスコードファイルを読み出すことにより
行う。この時点ではダウンロードが終了していないの
で、ステータスコードファイルが生成されていないの
で、データを受信成功し、かつ残りのデータがあると判
定しステップ７に進む。

【００８３】ステップ７では、データの受信が成功して
いるため変数Ｆを０にセットしステップ１１に進む。ス
テップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、
Ｔｉｍｅ＝９９５、Ｘ＝３０であるため、真と判定され
ステップ１２へ遷移する。

【００８４】ステップ１２では、ダウンロード時間（Ｔ
ｉｍｅ）が、スループットの測定タイミングであるかを
判定する。ここでは、９９５ｍｏｄ５＝０なので真と判
定し、ステップ８に進む。ステップ８では、過去Ｘ秒の
平均スループットを計算してＳとして保持する。平均ス
ループットは、（ダウンロード済みファイルサイズファ
イルの過去Ｘ秒の増加分）／Ｘの計算式から求めるが、
ここでは、ファイル転送実行部のダウンロード済みファ
イルサイズファイルの過去Ｘ秒の増加分は６３６８０ｋ
ｂｉｔ−６１７６０ｋｂｉｔ＝１９２０ｋｂｉｔなの
で、１９２０ｋｂｉｔ／３０ｓｅｃ＝６４（ｋｂｉｔ／
ｓｅｃ）となる。ステップ１３に進む。

【００８５】ステップ１３では、ファイル転送制御部の
処理の負荷を軽減するため、処理を１秒に一回に制限す
るために、１秒のウェイトを置き、ステップ２へ遷移す
る。

【００８６】ステップ２では、ダウンロードの状況を判
定する。ダウンロード状況の判定は、ファイル転送実行
部からステータスコードファイルを読み出すことにより
行う。この時点ではダウンロードが終了していないの
で、ステータスコードファイルが生成されていないの
で、データを受信成功し、かつ残りのデータがあると判
定しステップ７に進む。

【００８７】ステップ７では、データの受信が成功して
いるため変数Ｆを０にセットしステップ１１に進む。ス
テップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、
Ｔｉｍｅ＝９９６、Ｘ＝３０であるため、真と判定され
ステップ１２へ遷移する。

【００８８】ステップ１２では、ダウンロード時間（Ｔ
ｉｍｅ）が、スループットの測定タイミングであるかを
判定する。ここでは、９９６ｍｏｄ５＝１なので、偽と
判定し、ステップ１３に進む。ステップ１３で１秒のウ
ェイトを置き、ステップ２へ遷移する。

【００８９】以下、Ｔｉｍｅ＝９９９までステップ２→
ステップ７→ステップ１１→ステップ１２→ステップ１
３の処理を繰り返す。

【００９０】Ｔｉｍｅ＝９９９におけるステップ１３の
処理後、Ｔｉｍｅ＝１０００になった時点でステップ２
に進む。

【００９１】ステップ２では、ダウンロードの状況を判
定する。ダウンロード状況の判定は、ファイル転送実行
部からステータスコードファイルを読み出すことにより
行う。この時点で、ダウンロードが終了しているので、
ステータスコードファイルが正常終了なためデータを全
て受信完了と判定し、ファイル転送処理部の処理を終了
する。

【００９２】（実施例２）本実施形態の実施例２は、ダ
ウンロードクライアントソフトウェアがサーバからデー
タを受信し、ダウンロードエラーが発生した場合の処理
の流れの例である。本実施例２は、平均スループットが
６４ｋｂｉｔ／ｓｅｃの場合である。本実施例２におい
ての各種条件は、 ・コンテンツのファイルサイズ＝８０００ＫＢ＝６４０
００ｂｉｔ ・回線帯域が６４ｋｂｉｔ／ｓｅｃ ・Ｔｌ＝６０ｓｅｃ ・Ｔｓ＝１０ｓｅｃ ・Ｓｍｉｎ＝４０（ｋｂｉｔ／ｓｅｃ） ・Ｆｍｉｎ＝２（回） ・Ｘ＝３０ｓｅｃ ・Ｘｔｉｍｅｒ＝５ｓｅｃ ・ダウンロード実行部のダウンロードプロトコル：ＨＴ
ＴＰプロトコルによるダウンロード ・Ｔｉｍｅ＝３５の時点でダウンロードが２回連続して
失敗し、その後、再開に成功した場合である。

【００９３】以下、図１及び図２のフローチャートにつ
いてファイル転送実行部及びファイル転送制御部の処理
の流れを時系列的に説明する。

【００９４】（ファイル転送実行部の動作）図２に示す
ように、ファイル転送制御部からのダウンロード開始指
示を受けると処理を開始し、ステップＢに進みＨＴＴＰ
プロトコルによるダウンロードを実行する。ステップＣ
に進む。

【００９５】ステップＣでは、ダウンロードエラー発生
の判定を行う。ここでは、エラーが発生しなかったの
で、ステップＤに進む。

【００９６】ステップＤで、受信したデータをファイル
に格納し、ステップＥで、受信したデータ長をダウンロ
ード済ファイルサイズファイルに格納し、ステップＦに
進む。ステップＦではダウンロードが完了したか否かを
判定するが、ここでは、まだダウンロードが完了してい
ないので、ステップＢに戻る。

【００９７】ここで、ステップＢ→ステップＣ→ステッ
プＤ→ステップＥ→ステップＦ→ステップＢをＴｉｍｅ
＝３５まで繰り返す。

【００９８】前記繰り返し処理の間、その時点で、ダウ
ンロード済みファイルの容量（＝ダウンロード済みファ
イルサイズファイルの内容）は、単調に増えていく。す
なわち、 Ｔｉｍｅ＝０ｓｅｃの時は、０ｋｂｉｔ Ｔｉｍｅ＝１ｓｅｃの時は、６４ｋｂｉｔ Ｔｉｍｅ＝５ｓｅｃの時は、３２０ｋｂｉｔ Ｔｉｍｅ＝１０ｓｅｃの時は、６４０ｋｂｉｔ Ｔｉｍｅ＝３０ｓｅｃの時は、１９２０ｋｂｉｔ Ｔｉｍｅ＝３５ｓｅｃの時は、２２４０ｋｂｉｔ である。

【００９９】Ｔｉｍｅ＝３５のステップＣの時点でダウ
ンロードエラーが発生したので、ステップＨに遷移し、
ステータスコードファイルにエラー終了を示す情報を書
込み、一旦処理を終了する。

【０１００】ファイル転送制御部からのダウンロード再
開指示を受けると処理を開始し、ステップＢにすすみＨ
ＴＴＰプロトコルによるダウンロードを実行する。ステ
ップＣに進む。

【０１０１】ステップＣでは、もう一度エラーが発生し
たので、ステップＨに遷移し、ステータスコードファイ
ルにエラー終了を示す情報を書込み、一旦処理を終了す
る。

【０１０２】ファイル転送制御部からのダウンロード再
開指示を受けると処理を開始し、ステップＢにすすみＨ
ＴＴＰプロトコルによるダウンロードを実行する。ステ
ップＣに進む。

【０１０３】ステップＣでは、ダウンロードエラー発生
の判定を行う。ここでは、エラーが発生しなかったの
で、ステップＤに進む。

【０１０４】ステップＤで、受信したデータを前回中断
したファイルの後ろに追記する形で格納し、ステップＥ
で、今回の再開処理で受信したデータ長をダウンロード
済ファイルサイズファイルに格納し、ステップＦに進
む。ステップＦではダウンロードが完了したか否かを判
定するが、ここでは、まだダウンロードが完了していな
いので、ステップＢに戻る。

【０１０５】ここで、ステップＢ→ステップＣ→ステッ
プＤ→ステップＥ→ステップＦ→ステップＢをＴｉｍｅ
＝９６５まで繰り返す。

【０１０６】 Ｔｉｍｅ＝０ｓｅｃの時は、０ｋｂｉｔ Ｔｉｍｅ＝３０ｓｅｃの時は、１９２０ｋｂｉｔ Ｔｉｍｅ＝９３０ｓｅｃの時に、５９５２０ｋｂｉｔ Ｔｉｍｅ＝９６０ｓｅｃの時に、６１４４０ｋｂｉｔ となり、ステップＦのダウンロード完了判定で、ダウン
ロード完了と判定し、ステップＧに進み、ステータスコ
ードファイルをクリエイトして正常終了を示す情報を書
込み、ファイル転送実行部の処理を終了する。

【０１０７】（ファイル転送制御部の動作）図１に示す
ように、ステップ０でＳ＝０、Ｆ＝０と設定する。ステ
ップ１に進む。ステップ１において、ファイル転送制御
部は、ファイル転送実行部に対してダウンロード開始指
示を出し、Ｔｉｍｅを０ｓｅｃに設定し、ステップ２に
進む。

【０１０８】ステップ２では、ダウンロードの状況を判
定する。ダウンロード状況の判定は、ファイル転送実行
部からステータスコードファイルを読み出すことにより
行う。この時点ではダウンロードが終了していないの
で、ステータスコードファイルが生成されていないの
で、データを受信成功し、かつ残りのデータがあると判
定しステップ７に進む。

【０１０９】ステップ７では、データの受信が成功して
いるため変数Ｆを０にセットしステップ１１に進む。ス
テップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、
Ｔｉｍｅ＝０、Ｘ＝３０であるため、偽と判定されステ
ップ１３へ遷移する。ステップ１３で１秒のウェイトを
置き、ステップ２へ遷移する。

【０１１０】以下、Ｔｉｍｅ＝３０まで、ステップ２→
ステップ７→ステップ１１→ステップ１３の処理を繰り
返す。Ｔｉｍｅ＝３０におけるステップ１１の処理でＴ
ｉｍｅ＝３０、Ｘ＝３０であるため、真と判定されステ
ップ１２へ遷移する。

【０１１１】ステップ１２では、ダウンロード時間（Ｔ
ｉｍｅ）が、スループットの測定タイミングであるかを
判定する。すなわち、Ｔｉｍｅが、Ｘｔｉｍｅｒの整数
倍か否かを判定する。具体的には、（Ｔｉｍｅ）ｍｏｄ
（Ｘｔｉｍｅｒ）＝０を判定する。ここでは、１０ｍｏ
ｄ５＝０なので、真と判定し、ステップ８に進む。

【０１１２】ステップ８では、過去Ｘ秒の平均スループ
ットを計算してＳとして保持する。平均スループット
は、（ダウンロード済みファイルサイズファイルの過去
Ｘ秒の増加分）／Ｘの計算式から求めるが、ここでは、
ファイル転送実行部のダウンロード済みファイルサイズ
の過去Ｘ秒の増加分は、１９２０ｋｂｉｔ−０ｋｂｉｔ
＝１９２０ｋｂｉｔなので、１９２０ｋｂｉｔ／３０ｓ
ｅｃ＝６４（ｋｂｉｔ／ｓｅｃ）となる。これをＳとし
て保持する。ステップ１３に進む。ステップ１３では、
１秒のウェイトを置き、ステップ２へ遷移する。

【０１１３】ステップ２では、ダウンロードの状況を判
定する。ダウンロードの状況の判定は、ファイル転送実
行部からステータスコードファイルを読み出すことによ
り行う。この時点ではダウンロードが終了していないの
で、ステータスコードファイルが生成されていないの
で、データを受信成功し、かつ残りのデータがあると判
定し、ステップ７に進む。

【０１１４】ステップ７では、データの受信が成功して
いるため、変数Ｆを０にセットしステップ１１に進む。

【０１１５】ステップ１１では、Ｔｉｍｅ≧Ｘを判定す
る。ここでは、Ｔｉｍｅ＝３１、Ｘ＝３０であるため、
真と判定されステップ１２へ遷移する。ステップ１２で
は、ダウンロード時間（Ｔｉｍｅ）が、スループットの
測定タイミングであるかを判定する。ここでは、３１ｍ
ｏｄ５＝１なので、偽と判定し、ステップ１３に進む。

【０１１６】以下、Ｔｉｍｅ＝３５までステップ２→ス
テップ７→ステップ１１→ステップ１２→ステップ１３
の処理を繰り返す。

【０１１７】Ｔｉｍｅ＝３５におけるステップ２では、
ダウンロードの状況を判定する。ダウンロード状況の判
定は、ファイル転送実行部からステータスコードファイ
ルを読み出すことにより行う。この時点で、ダウンロー
ドが終了しているので、ステータスコードファイルがエ
ラー終了であるためデータを受信失敗と判定し、ステッ
プ３へ遷移する。

【０１１８】ステップ３では、データ受信時の過去Ｘ秒
のスループットが回線状況良好と判定するスループット
の最小値よりも大きいか否かを判定する。具体的には、
Ｓ＞Ｓｍｉｎを判定する。ここでは、６４（ｋｂｉｔ／
ｓｅｃ）＞４０（ｋｂｉｔ／ｓｅｃ）が真なので、一時
的な回線またはサーバ障害の疑いありと判定し、ステッ
プ４に進む。ステップ４では、ここに遷移するのは高ス
ループット状態でのデータ受信連続失敗が一回増加した
場合であるから、Ｆを１インクリメントする。すなわ
ち、Ｆ＝０＋１＝１となり、Ｆに１をセットし、ステッ
プ５に遷移する。

【０１１９】ステップ５では、高スループット状態での
データ受信連続失敗が、高スループット状態でのデータ
受信連続許容失敗回数以上に達したかを判定する。具体
的には、Ｆ≧Ｆｍｉｎを判定する。ここでは、１≧２が
偽なので、ステップ９に進む。

【０１２０】ステップ９では、Ｔｓ＝１０秒のウェイト
タイマー値のウェイトを置く。そしてステップ１０に進
む。ステップ１０において、ファイル転送制御部は、フ
ァイル転送実行部に対してダウンロード再開支持を出
し、Ｔｉｍｅ＝０にセットし、ステップ２に進む。

【０１２１】Ｔｉｍｅ＝０におけるステップ２では、ダ
ウンロードの状況を判定できる。ダウンロード状況の判
定は、ファイル転送実行部からのステータスコードファ
イルを読み出すことにより行う。この時点で、ダウンロ
ードが終了しているので、ステータスコードファイルが
エラー終了なためデータを受信失敗と判定し、ステップ
３へ遷移する。

【０１２２】ステップ３では、データ受信時の過去Ｘ秒
のスループットが回線状況良好と判定するスループット
の最小値よりも大きい否かを判定する。具体的には、Ｓ
＞Ｓｍｉｎを判定する。ここでは、６４（ｋｂｉｔ／ｓ
ｅｃ）＞４０（ｋｂｉｔ／ｓｅｃ）が真なので、一時的
な回線またはサーバ障害の疑いありと判定し、ステップ
４に進む。

【０１２３】ステップ４では、ここに遷移するのは、高
スループット状態でのデータ受信連続失敗が一回増加し
た場合であるから、Ｆを１インクリメントする。すなわ
ち、Ｆ＝１＋１＝２となり、Ｆに２をセットし、ステッ
プ５に遷移する。

【０１２４】ステップ５では、高スループット状態での
データ受信連続失敗が、高スループット状態でのデータ
受信連続失敗許容失敗回数以上に達したかを判定する。
具体的には、Ｆ≧Ｆｍｉｎを判定する。ここでは、２≧
２が真なので、一時的な回線またはサーバ障害発生と判
定し、ステップ６に進む。

【０１２５】ステップ６では、Ｔｌ＝６０秒のウェイト
タイマー値のウェイトを置く。そしてステップ１０に進
む。ステップ１０において、ファイル転送制御部は、フ
ァイル転送実行部に対してダウンロード再開指示を出
し、Ｔｉｍｅ＝０にセットし、ステップ２に進む。

【０１２６】ステップ２では、ダウンロードの状況を判
定する。ダウンロード状況の判定は、ファイル転送実行
部からステータスコードファイルを読み出すことにより
行う。この時点ではダウンロードが終了していないの
で、ステータスコードファイルが生成されていないの
で、データを受信成功し、かつ、残りのデータがあると
判定しステップ７に進む。

【０１２７】ステップ７では、データの受信が成功して
いるため変数Ｆを０にセットしステップ１１に進む。ス
テップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、
Ｔｉｍｅ＝０、Ｘ＝３０であるため、偽と判定されステ
ップ１３へ遷移する。ステップ１３で１秒のウェイトを
置き、ステップ２へ遷移する。

【０１２８】以下、Ｔｉｍｅ＝３０まで、ステップ２→
ステップ７→ステップ１１→ステップ１３の処理を繰り
返す。Ｔｉｍｅ＝３０における、ステップ１１の処理で
Ｔｉｍｅ＝３０、Ｘ＝３０であるため、真と判定されス
テップ１２へ遷移する。

【０１２９】ステップ１２では、ダウンロード時間（Ｔ
ｉｍｅ）が、スループットの測定タイミングであるかを
判定する。すなわち、Ｔｉｍｅが、Ｘｔｉｍｅｒの整数
倍か否かを判定する。具体的には、（Ｔｉｍｅ）ｍｏｄ
（Ｘｔｉｍｅｒ）＝０を判定する。ここでは、１０ｍｏ
ｄ５＝０なので、真と判定し、ステップ８に進む。

【０１３０】ステップ８では、過去Ｘ秒の平均スループ
ットを計算してＳとして保持する。平均スループット
は、（ダウンロード済みファイルサイズファイルの過去
Ｘ秒の増加分）／Ｘの計算式から求めるが、ここでは、
ファイル転送実行部のダウンロード済みファイルサイズ
ファイルの過去Ｘ秒の増加分は、１９２０ｋｂｉｔ−０
ｋｂｉｔ＝１９２０ｋｂｉｔなので、１９２０ｋｂｉｔ
／３０ｓｅｃ＝６４（ｋｂｉｔ／ｓｅｃ）となる。ステ
ップ１３に進む。ステップ１３では、１秒のウェイトを
置き、ステップ２へ遷移する。

【０１３１】ステップ２では、ダウンロードの状況を判
定する。ダウンロード状況の判定は、ファイル転送実行
部からステータスコードファイルを読み出すことにより
行う。この時点ではダウンロードが終了していないの
で、ステータスコードファイルが生成されていないの
で、データを受信成功し、かつ、残りのデータがあると
判定しステップ７に進む。

【０１３２】ステップ７では、データの受信が成功して
いるため変数Ｆを０にセットしステップ１１に進む。ス
テップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、
Ｔｉｍｅ＝３１、Ｘ＝３０であるため、真と判定されス
テップ１２へ遷移する。

【０１３３】ステップ１２では、ダウンロード時間（Ｔ
ｉｍｅ）が、スループットの測定タイミングであるかを
判定する。ここでは、３１ｍｏｄ５＝１なので、偽と判
定し、ステップ１３に進む。

【０１３４】以下、Ｔｉｍｅ＝３５までステップ２→ス
テップ７→ステップ１１→ステップ１２→ステップ１３
の処理を繰り返す。Ｔｉｍｅ＝３５におけるステップ１
２の処理で３５ｍｏｄ５＝０なので、真と判定し、ステ
ップ８に進む。ステップ８では、過去Ｘ秒の平均スルー
プットを計算してＳとして保持する。

【０１３５】平均スループットは、（ダウンロード済み
ファイルサイズファイルの過去Ｘ秒の増加分）／Ｘの計
算式から求めるが、ここでは、ファイル転送実行部のダ
ウンロード済みファイルサイズファイルの過去Ｘ秒の増
加分は２２４０ｋｂｉｔ−３２０ｋｂｉｔ＝１９２０ｋ
ｂｉｔなので、１９２０ｋｂｉｔ／３０ｓｅｃ＝６４
（ｋｂｉｔ／ｓｅｃ）となる。ステップ１３に進む。

【０１３６】ステップ１３では、ファイル転送制御部の
処理の負荷を軽減するため、処理を１秒に一回に制限す
るために、１秒のウェイトを置き、ステップ２へ遷移す
る。

【０１３７】以下、同様にステップ２〜ステップ１３処
理を行い、Ｔｉｍｅ＝９５５となったとする。

【０１３８】ステップ２では、ダウンロードの状況を判
定する。ダウンロード状況の判定は、ファイル転送実行
部からステータスコードファイルを読み出すことにより
行う。この時点ではダウンロードが終了していないの
で、ステータスコードファイルが生成されていないの
で、データを受信成功し、かつ残りのデータがあると判
定しステップ７に進む。

【０１３９】ステップ７では、データの受信が成功して
いるため変数Ｆを０にセットしステップ１１に進む。ス
テップ１１では、Ｔｉｍｅ≧Ｘを判定する。ここでは、
Ｔｉｍｅ＝９６０、Ｘ＝３０であるため、真と判定され
ステップ１２へ遷移する。ステップ１２では、ダウンロ
ード時間（Ｔｉｍｅ）が、スループットの測定タイミン
グであるかを判定する。ここでは、９６０ｍｏｄ５＝０
なので真と判定し、ステップ８に進む。

【０１４０】ステップ８では、過去Ｘ秒の平均スループ
ットを計算してＳとして保持する。平均スループット
は、（ダウンロード済みファイルサイズファイルの過去
Ｘ秒の増加分）／Ｘの計算式から求めるが、ここでは、
ファイル転送実行部のダウンロード済みファイルサイズ
ファイルの過去Ｘ秒の増加分は６１４４０ｋｂｉｔ−５
９５２０ｋｂｉｔ＝１９２０ｋｂｉｔなので、１９２０
ｋｂｉｔ／３０ｓｅｃ＝６４（ｋｂｉｔ／ｓｅｃ）とな
る。ステップ１３に進む。ステップ１３では、ファイル
転送制御部の処理の負荷を軽減するため、処理を１秒に
一回に制限するために、１秒のウェイトを置き、ステッ
プ２へ遷移する。

【０１４１】ステップ２では、ダウンロードの状況を判
定する。ダウンロード状況の判定は、ファイル転送実行
部からステータスコードファイルを読み出すことにより
行う。この時点ではダウンロードが終了していないの
で、ステータスコードファイルが生成されていないの
で、データを受信成功し、かつ、残りのデータがあると
判定しステップ７に進む。ステップ７では、データの受
信が成功しているため変数Ｆを０にセットしステップ１
１に進む。

【０１４２】ステップ１１では、Ｔｉｍｅ≧Ｘを判定す
る。ここでは、Ｔｉｍｅ＝９６１、Ｘ＝３０であるた
め、真と判定されステップ１２へ遷移する。ステップ１
２では、ダウンロード時間（Ｔｉｍｅ）が、スループッ
トの測定タイミングであるかを判定する。ここでは、９
６１ｍｏｄ５＝１なので、偽と判定し、ステップ１３に
進む。ステップ１３で１秒のウェイトを置き、ステップ
２へ遷移する。

【０１４３】以下、Ｔｉｍｅ＝９６４までステップ２→
ステップ７→ステップ１１→ステップ１２→ステップ１
３の処理を繰り返す。Ｔｉｍｅ＝９６４におけるステッ
プ１３の処理後、Ｔｉｍｅ＝９６５になった時点でステ
ップ２に進む。

【０１４４】ステップ２では、ダウンロードの状況を判
定する。ダウンロード状況の判定は、ファイル転送実行
部からステータスコードファイルを読み出すことにより
行う。この時点で、ダウンロードが終了しているので、
ステータスコードファイルが正常終了なためデータを全
て受信完了と判定し、ファイル転送処理部の処理を終了
する。

【０１４５】（実施例３）以下、前記本発明の帯域が保
証されていないデータ配信システム（ネットワーク）に
おける、ファイル転送の中断再開が可能なダウンロード
方法の処理手順のを、コンピュータが実行するためのプ
ログラムを記憶した記憶媒体を、音楽配信サービスシス
テムヘ適用した場合の実施例３を記述する。

【０１４６】（実施例３において使用する通信ノード）
本実施例３においては、以下の５つを通信ノードとす
る。 ・ユーザ登録端末（以下ユーザ登録端末） ・予約端末（以下予約端末） ・お客様のＰＣ（以下ＰＣ） ・ホームゲートウェイ（以下ＨＧＷ） ・音楽配信ポータルサイト（以下ポータル） である。各通信ノード間は、ＴＣＰ／ＩＰのネットワー
クで接続されている。

【０１４７】ユーザ登録端末及び予約端末は、ポータル
にインターネット経由で接続できることだけが、必要要
件である。

【０１４８】ＰＣはＬＡＮ（ＴＣＰ／ＩＰ）でＨＧＷに
接続され、一台のＨＧＷに一台のＰＣではなく複数のＰ
Ｃが接続することもあり得る。但し、本実施例３では、
一台のＰＣが接続されているものとして説明する。

【０１４９】ＨＧＷは、インターネットを介してポータ
ルに接続し、複数のＨＧＷが存在する。本実施例３で
は、そのうちの１つのＨＧＷに着目して説明する。

【０１５０】ポータルはインターネット上に１つのみと
する。ポータルは音楽コンテンツダウンロードサービス
を提供している。

【０１５１】（本音楽配信サービスシステムのポイン
ト）本音楽配信サービスシステムは、お客様がポータル
から音楽コンテンツを取得することを目的としている。

【０１５２】本音楽配信サービスシステムは、単にお客
様のＰＣ上のダウンロードソフトで、音楽コンテンツが
存在するポータルからコンテンツをダウンロードするの
ではなく、ポータルにコンテンツの配信を予約すると決
まった時間にポータルからＨＧＷにコンテンツを配信し
てくれて、予約したお客様だけがＨＧＷに蓄積されたコ
ンテンツを取り出せるという特徴を持つ。但し、ポータ
ルからＨＧＷへのデータ配信は、ＨＧＷがポータルから
データをダウンロードすることにより実現している。

【０１５３】以下、お客様がコンテンツを予約してから
データを取り出すまでのシーケンスをＨＧＷが１つで、
ユーザがひとりの場合を例に説明する。次に、予約した
お客様だけがＨＧＷに蓄積されたコンテンツを取り出せ
るためのユーザＩＤ認証方法を複数のユーザが存在する
事象で説明する。

【０１５４】本実施例３においても、ダウンロードの中
断再開タイマー値を可変とし、データダウンロード実行
中の平均スループットをパラメータとして中断再開タイ
マー値を制御して、無駄なトラフィックを抑制しつつ、
できるだけ速くダウンロードを完了させる処理を適用し
ているが、詳細は後述する。

【０１５５】（音楽の予約配信サービスにおける時系列
的な処理）以下、音楽の予約配信サービスにおける時系
列的な処理の説明を行う。以下の項番において、１．
３．１．と１．３．２（１．３．２．１．１．３．２．
２）については、準備処理であり、これらの処理は時系
列的にシーケンシャルでなくてもよい。また、これらの
処理は、後述する予約処理の前に終わっていればよい。
但し、１．３．２．１と１．３．２．２の順番はこの順
番に行うことが必須である。

【０１５６】１．３．３〜１．３．６は予約処理であ
り、予約端末からポータルに対する操作及びデータ送信
である。これらはシーケンシャルに行う必要がある。

【０１５７】１．３．７は配送処理であり、予約処理が
終わっていることが前提である。ポータルからＨＧＷヘ
コンテンツを配送する仕組みを説明している。

【０１５８】１．３．８は、コンテンツ取り出し処理で
あり、配送処理が終了していることが前提である。ＨＧ
ＷからＰＣへのデータの取り出しについて説明してい
る。

【０１５９】これらを図示すると、図６のようになる。

【０１６０】（１．３．１音楽コンテンツの登録）音楽
コンテンツの登録は、ポータルサイト管理者が手動で行
う。管理者は、音楽コンテンツをポータルのダウンロー
ド用コンテンツ領域に置く。また、音楽コンテンツのリ
スト（以下、ポータルの曲目リスト）のページを用意す
る。・ポータルの曲目リストには、曲名、（アーティス
ト）、（レコード会社）、ファイルサイズ、（料金）を
登録する。（ ）内の情報は省略可能である。

【０１６１】（１．３．２ユーザ登録）１．３．２．１
ポータルサイトヘのユーザ登録はポータルルサイトで、
音楽配信サービスのユーザ登録を行う。ユーザ登録はロ
グインの前に予め行う必要があり、ユーザ登録端末から
ユーザが行う。必須で登録する項目は、以下の通りであ
る。 ・ユーザＩＤ ・パスワード ・ＨＧＷ−ＩＤ（ＨＧＷへのダウンロード先を決定する
のに利用） ・接続環境（ダイヤルアップアナログ５６ｋ、ダイヤル
アップアナログ２８ｋ、ダイヤルアップＩＳＤＮ６４
ｋ、常時ＩＰ６４ｋ、ＬＡＮ１０Ｍ） ・利用サービス（ＩＮＳ（登録商標）テレホーダイ、テ
レホーダイ１８００、テレホーダイ３６００） なお、接続環境は、データ配信時のスループットを推定
するために使用する。接続環境（ＩＳＤＮ、アナログ５
６ｋ、２８ｋ…）については、ユーザが設定した値を初
期値とするが、後に実行される１．３．７で実際に実行
された配信処理での平均的な通信速度（配信速度）を記
録しておき、それに応じて設定値を動的に変化させる方
法も考えられる。

【０１６２】以下の項目は、オプションとし、登録が望
ましいが、無くても運用可能である。 ・氏名 ・電話番号 ・連絡先メールアドレス ・ダウンロード完了通知用メールアドレス（連絡先用メ
ールアドレスと同じか違うか選択する。違うときは入力
してもらう。） 但し、ユーザＩＤは、ユーザを特定するＩＤであり、そ
の重複は許さない。従って、各項目は、ユーザＩＤに対
してバインドされる。

【０１６３】登録方法の一例としては、前記登録項目の
ＷＥＢの画面をポータルからユーザが登録端末に表示
し、ユーザは入力した情報を、ＨＴＴＰのＰＯＳＴコマ
ンド等でユーザ登録端末からユーザに伝え、それを受け
取ったポータルはプロファイル保存ファイルに書き込む
という処理があげられる。但し、最終的に、ユーザが入
力した必須項目をポータル上のプロファイル保存ファイ
ルに書き込むことが目的であり、それができれば手段は
問わない。

【０１６４】（１．３．２．２ＨＧＷへのユーザ登録）
ＨＷＧへのユーザ登録は、１．３．２．１のポータルへ
のユーザ登録処理で発行されたユーザＩＤとパスワード
をＨＷＧ内部のユーザ登録ファイルに保持することを目
的とする処理である。

【０１６５】ユーザ登録ファイルは、ユーザＩＤとパス
ワードを対にして保存される。登録方法は、前記目的を
満たせれば問わないので、具体例は示さない。

【０１６６】（１．３．３予約処理／ログイン）ログイ
ンは、予約端末から行う。予約端末とはユーザ登録端末
と同一でも良いし、別でも良い。ログイン処理では、ユ
ーザが、予約端末から登録してあるユーザＩＤとパスワ
ードをポータルに伝え、ポータルではプロファイル保存
ファイルからユーザＩＤに対応するパスワードをチェッ
クした上で予約サービスのユーザＩＤを特定し、正しけ
れば音楽コンテンツ選択画面を予約端末に表示すること
が目的である。

【０１６７】ログイン処理の一例としては、予約端末の
ＷＥＢブラウザでユーザＩＤとパスワードのダイヤログ
ボックスをポータルから予約端末に表示し、ユーザは入
力した情報をＨＴＴＰのＰＯＳＴコマンド等で予約端末
からポータルに伝え、それを受け取ったポータルは、プ
ロファイル保存ファイルからユーザＩＤに対応するパス
ワードをチェックし正しい場合に、ＷＥＢブラウザ上に
音楽コンテンツ選択画面を表示するという処理が挙げら
れるが、前記目的を実現できれば、手段は問わない。

【０１６８】（１．３．４音楽コンテンツの選択）音楽
コンテンツの選択処理は、ユーザが獲得したい音楽コン
テンツの曲目をポータルに指定する処理である。音楽コ
ンテンツの曲目を予約端末からポータルに伝え、ポータ
ルがそれを保持し、アーカイブ処理に遷移することが目
的である。

【０１６９】音楽コンテンツの選択処理の一例として
は、予約端末のＷＥＢブラウザに対して音楽コンテンツ
の曲目リストをポータルから予約端末に表示し、ユーザ
はダウンロードする曲を一曲または複数選択し、ＨＴＴ
ＰのＰＯＳＴコマンド等で予約端末からポータルに伝
え、それを受け取ったポータルは、ユーザが指定した曲
を得て、アーカイブ処理に遷移するという処理が挙げら
れるが、前記処理を実現できれば、手段は問わない。

【０１７０】（１．３．５アーカイブ処理）ポータル
が、１．３．４で指定されたひとつまたは複数の音楽コ
ンテンツを、ひとまとめにしてアーカイブしてそのＵＲ
Ｌとファイルの実体を保持し、配信ポリシーの指定画面
に遷移することがアーカイブ処理の目的である。アーカ
イブ手段として、ＵＮＩＸ（登録商標）でよく使われる
ｔａｒやＷｉｎｄｏｗｓ（登録商標）でよく使われるＺ
ＩＰ等の形式があるが、アーカイブできればアルゴリズ
ムは問わない。

【０１７１】以下、アーカイブ処理された音楽コンテン
ツをアーカイブと呼ぶ。アーカイブ処理を行う理由は、
一回の配送で指定された全部の音楽コンテンツを効率的
に配信することが期待されるためである。

【０１７２】（１．３．６配信ポリシーの指定）配信ポ
リシーの指定は、ユーザがポータルに配信ポリシーを指
定し、その上で予約が完了したことをユーザに伝えるこ
とが目的である。配信ポリシーの指定手段として、表１
の「時刻指定」の項目の項番１〜６、すなわち、「いま
すぐ」、「指定した時間から」、「指定した時間まで
に」、「一番安い時間」、「ＨＧＷの未使用時」からユ
ーザが１つ選んでポータルに伝え、ポータルが配信ポリ
シーを保持することが必要である。

【０１７３】

【表１】 配信ポリシーの指定処理の一例としては、予約端末のＷ
ＥＢブラウザに対して表１の配信ポリシー表をポータル
から予約端末に表示し、ユーザは配信ポリシーを１つ選
択し、ＨＴＴＰのＰＯＳＴコマンド等で予約端末からポ
ータルに伝え、それを受け取ったポータルは、ユーザが
指定した配信ポリシーを決定し、ポータルは予約端末の
ＷＥＢブラウザに対して、予約を受け付けたことを表示
するという処理が挙げられるが、上記目的を実現できれ
ば、手段は問わない。

【０１７４】以下、決定された配信ポリシーに従って、
１．３．６．１〜１．３．６．４の処理のいずれかを実
行する。これらの処理のポイントは、配信開始時刻を設
定することである。その後、１．３．７の処理に遷移す
る。１．３．６．１今すぐ、配信開始時刻を指定無しと
設定する。配信終了期限は指定無しとする。１．３．
６．２指定した時間から、配信開始時刻を設定された時
刻に設定する。配信終了期限は指定無しとする。

【０１７５】

【表２】 表２は、時刻の指定方法に応じてコンテンツに価格変化
を付ける一例である。この例では、今すぐ、指定した時
間からの場合は通常のコンテンツ価格に対して１０％の
割り増し料金をとり、一番安い時間を指定した場合は、
１５％割引する。

【０１７６】本価格変化の手法を時刻の指定方法と併用
することにより、ユーザヘの配信時刻は平滑化サーバ及
びネットワークの負荷分散が行え、サーバ及びネットワ
ークコストが安くできるので、安価な設備でサーバ設備
を構築できる。

【０１７７】なお、これは現実の物流システムに例える
ならば、宅配便において到着時間を指定して、荷物の配
送を依頼する時間指定配送サービスなどと同じである。

【０１７８】通常、コンテンツをダウンロードする際は
ユーザが配信開始時刻を指定する。本手法においては、
ユーザが指定した範囲内でサーバが配信時刻を指定す
る。

【０１７９】これにより、ユーザの指定範囲によりサー
バ側の配信開始時刻を設定する際の自由度は変動する。
例えば、ユーザが「３日以内に」といった大まかな時間
を指定しただけならばサーバ側自由度は大きくなるが、
「３日の１２時から１３時の間に」といった詳細な指定
をするとサーバの自由度は小さくなる。サーバ側の自由
度が大きいと、そのオーダによる負荷を自由に分散でき
る。サーバ側の負荷分散の観点からは、ユーザのオーダ
はなるべくサーバ側自由度の大きなものの方が望まし
い。

【０１８０】この点に着目し、ユーザの配信オーダを、
サーバの配信時刻指定の自由度という点からとらえ、自
由度の大きなオーダに対してはコンテンツの料金や通信
料金を安くし、自由度の小さなオーダに対しては、それ
ら料金を安くして提供する。

【０１８１】宅配便の例においては、配送が集中する
「翌朝９時までに配送」という指定をすると、利用者は
その分の高い料金を支払う必要があり、通常の配送であ
る「翌日中で時間指定は特にしない」という指定の際に
は、高い料金は必要なく通常の料金で配送が可能である
のと、同様である。

【０１８２】１．３．６．３指定した時間までに（終了
時指定配信）、アーカイブのサイズと、接続環境の平均
通信速度から、配信開始時刻を決定する。

【０１８３】（１）アーカイブの配信に必要な時間を計
算する。 通信時間＝（アーカイブのサイズ）／（接続環境の平均
通信速度） （２）指定された終了時間にちょうど配信が終了する時
刻を計算する。 配信開始最終時刻＝配信終了期限−通信時間 （３）配信開始最終時刻から１時間前の時刻を配信開始
時刻とする。配信終了期限は、ユーザが選択した配信終
了期限を設定する。

【０１８４】１．３．６．４一番安い時間（最低コスト
配信）は、多量のアーカイブの配送が同時刻に集中する
のをさけるために、配信開始時刻については一定の時間
帯内でランダムに指定する。 ・テレホーダイ利用：テレホーダイ時間内で指定する。
２３時から１時の間で配信開始時刻をランダムに指定。
配信終了期限は、１時に指定。 ・ＩＳＤＮ及びアナログのダイヤルアップ：２４時間以
内で最も通信料の安い時間帯（最も通信料の安い時間帯
の計算方法は、ユーザの利用している通信会社の通信料
金テーブルを元に算出する）を考慮し、配信開始時刻を
ランダムに設定する。配信終了期限は指定無しとする。 ・ＩＰ常時接続：２３時から１時を除いた時刻の中から
配信開始時刻をランダムに指定する。配信終了期限は指
定しない。

【０１８５】以上の１．３．６．１〜１．３．６．４の
いずれかで、配信開始時刻が決定される。 （１．３．７配信）１．３．７．１ポータル（ダウンロ
ードサーバ側）の処理は、ダウンロードすべきコンテン
ツを指定したメッセージとして「受取人情報、ＵＲＬ、
時刻指定プル情報」をメッセージ要素として設定したフ
ァイル転送要求メッセージをＨＧＷへ送信する。各メッ
セージ要素には、以下の情報を格納する。

【０１８６】（メッセージ要素名） ・受取人情報：１．３．３で特定された本サービスのユ
ーザＩＤ（図７ではＡＡＡＡ等）を設定。 ・ＵＲＬ：１．３．５で指定された、アーカイブファイ
ルのＵＲＬを設定。 ・時刻指定プル情報：１．３．６．１〜１．３．６．４
のいずれかで特定された、配信開始時刻及び配信終了期
限。

【０１８７】なお、ポータルからＨＧＷへのファイル転
送要求メッセージの伝達手段は、ポータルからＨＧＷヘ
ファイルを送信する方法ではなく、特願平１０−４９７
７１のテレポーリング技術により、ＨＧＷがポータルか
ら周期的にファイル転送要求メッセージをポーリング受
信する方法でもよい。

【０１８８】（１．３．７．２ＨＧＷ（クライアント）
側の処理） 「ファイル転送要求」メッセージを受け取った場合、
「時刻指定プル情報」メッセージ要素で、配信開始時刻
が指定なしの場合は、即時に指定されたＵＲＬからのプ
ルを実行する（プルの定義は後述する）。

【０１８９】メッセージが時間指定ダウンロード
（「時刻指定プル情報」メッセージ要素に配信開始時刻
が含まれる）の場合は、ＨＧＷテーブルに登録する。登
録する内容は、受信したファイル転送要求メッセージ内
の「受取人情報」、「ＵＲＬ」、「時刻指定プル情報」
及び「ダウンロード終了ステータス」である。ダウンロ
ード終了ステータスは初期値として１（ダウンロード待
ち状態を示す）をセットする。

【０１９０】ＨＧＷでは、現在時刻が、時刻指定プル
情報の配信開始時刻以前になったＨＧＷテーブルのレコ
ードについて、指定されたＵＲＬからのプルを開始す
る。プルを開始する時点で、ダウンロード終了ステータ
スを２（ダウンロード中を示す）にセットする。

【０１９１】ここで述べるプル（コンテンツセッショ
ン）は、ＨＴＴＰあるいはＦＴＰなどの一般的に用いら
れるプロトコルによりファイルを受信する処理である。

【０１９２】ここでは、レジューム機能を持つプロトコ
ルとして、ＨＴＴＰダウンロードプロトコルによりＨＧ
Ｗがファイルを受信したとする。ただし、ダウンロード
時刻をすぎても完了しない場合には、プルを中止する。

【０１９３】本実施例３では、プル処理において、ＨＧ
Ｗ（ダウンロードクライアント）がポータル（サーバ）
からアーカイブ（データ）を受信し、ダウンロードエラ
ーが発生しなかったとする。この場合、処理フローは、
前記実施例１と同様である。

【０１９４】（１．３．８コンテンツ取り出し処理）ユ
ーザがＨＧＷに配送されたコンテンツをＰＣに対して取
り出すことが目的である。また、予約したユーザ以外が
コンテンツを取り出せないことも必須である。

【０１９５】以下、処理の一例を示す。ユーザは、ＰＣ
からユーザＩＤとパスワードをＨＧＷに対して送信し、
ＨＧＷはユーザ登録ファイルをもとに、ユーザＩＤとパ
スワードを照合する。受け取ったユーザＩＤとパスワー
ドがユーザ登録ファイルに含まれている場合は、そのユ
ーザＩＤを持つユーザに対して配信されているコンテン
ツを、取り出し端末に渡す。この後、ユーザは、ＰＣ上
で、取り出し端末にあるコンテンツを自由に再生した
り、編集することができる。

【０１９６】予約したお客様だけがＨＧＷに蓄積された
コンテンツを取り出せるためのユーザＩＤ認証方法につ
いて説明する。

【０１９７】本サービスでは、ポータルとＨＧＷの双方
で利用ユーザを特定できるユーザＩＤを利用ユーザ毎に
付与する。ユーザＩＤは後述のユーザ登録時にポータル
にて登録するとともに、ＨＧＷ側にも同一のユーザＩＤ
を登録しておく必要がある。

【０１９８】ユーザＩＤは、家庭内で複数の人が利用す
ることを想定し、ＨＧＷに複数の設定が可能である。ポ
ータルにおいては、ユーザＩＤ毎に配送すべきＨＧＷの
ＩＤをユーザ登録時に登録し、通常は注文したユーザの
ユーザＩＤに対して、登録されているＨＧＷのＩＤに対
してＴＰＰを利用した配送が行われる。また、ＨＧＷに
配送する時は、ＨＧＷに登録されているユーザＩＤ毎に
コンテンツを区分して登録し、特定のユーザＩＤのユー
ザのみがＨＧＷに配送されたコンテンツを取り出せるよ
うにする（図７の例）。

【０１９９】図７に示されるＨＧＷへのユーザ登録から
取り出しまでの方法について説明する。ここでは、例と
して、ＨＧＷ（ＨＧＷ−ＩＤが１００であるＨＧＷ、以
下ＨＧＷ１）にはユーザが２名登録され、ＨＧＷ（ＨＧ
Ｗ−ＩＤが２００であるＨＧＷ、以下ＨＧＷ２）にはユ
ーザが１名登録されることを想定する。また、ＨＧＷか
らコンテンツを取り出すにはＰＣなどＨＧＷに接続され
ているコンテンツ取り出し端末が必要である。

【０２００】１）ＨＧＷへのユーザ登録処理 ＨＧＷには、そのＨＧＷを利用するユーザが登録されて
いる必要がある。ＨＧＷへのユーザ登録は、ユーザのユ
ーザＩＤとパスワードを登録する処理である。ＨＧＷで
は、ユーザから入力されたユーザＩＤとパスワードをＨ
ＧＷ内部のユーザ登録ファイルに保持する。ここで、ユ
ーザＩＤの重複は許さない。また、ユーザ登録ファイル
は、ユーザＩＤとパスワードを対にして保存される。

【０２０１】この例においては、ＨＧＷ１においては、
ユーザＩＤとしてＡＡＡＡを持つユーザ（以下ユーザＡ
ＡＡＡ）、ユーザＩＤとしてＢＢＢＢを持つユーザ（ユ
ーザＢＢＢＢ）の２名が登録する。

【０２０２】ユーザＡＡＡＡは、ユーザＩＤ（ＡＡＡ
Ａ）、パスワード ユーザＢＢＢＢは、ユーザＩＤ（ＢＢＢＢ）、パスワー
ド をＨＧＷに登録する。ここで、各ユーザの登録するパス
ワードは任意の文字列を指定し登録出来る。

【０２０３】ＨＧＷ２においては、ユーザＩＤとしてＣ
ＣＣＣを持つユーザ（ユーザＣＣＣＣ）１名が登録す
る。ユーザＣＣＣＣは、ユーザＩＤ（ＣＣＣＣ）、パス
ワードをＨＧＷに登録する。

【０２０４】２）予約配信処理 次に、ユーザが注文端末から予約したコンテンツを、ポ
ータルからＨＧＷへ配信する処理がある。

【０２０５】ユーザの予約の処理については、詳細は後
述する。ＨＧＷへの配信処理は、例においては、ユーザ
ＡＡＡＡは、コンテンツＡの配信を予約し、同じくユー
ザＢＢＢＢはコンテンツＢ、ユーザＣＣＣＣはコンテン
ツＣの配信を予約することを想定する。コンテンツは、
予約したユーザがユーザ登録をしてあるＨＧＷへ配送さ
れる。つまり、ユーザＡＡＡＡ、ユーザＢＢＢＢはとも
にＨＧＷ１にユーザ登録されているので、コンテンツＡ
及びコンテンツＢはＨＧＷ１に配送される。コンテンツ
Ｃは、ユーザＣＣＣＣがユーザ登録されているＨＧＷ２
へ配送される。ＨＧＷへ配送されたコンテンツは、ＨＧ
Ｗに登録された各ユーザＩＤに対応して確保されている
メモリエリアに蓄積される。

【０２０６】３）ＨＧＷからのコンテンツ取り出し処理 ＨＧＷには複数のユーザが登録される場合があるため、
複数ユーザが予約した複数のコンテンツが１つのＨＧＷ
に同時に蓄積されている。その中から、各ユーザに対し
て、自分の予約したコンテンツのみを取り出させる必要
がある。つまり、ＨＧＷからコンテンツを取り出す際に
は、ＨＧＷに登録された各ユーザに自分の予約したコン
テンツのみの取り出しを許可し、他ユーザの予約したコ
ンテンツの取り出しは許可しないことになる。

【０２０７】ＨＧＷは、ユーザがコンテンツ取り出し端
末から入力したユーザＩＤとパスワードを受け取る。Ｈ
ＧＷは、受け取ったユーザＩＤとパスワードを、ユーザ
登録ファイルに登録されているユーザＩＤとパスワード
とを照合する。受け取ったユーザＩＤとパスワードがユ
ーザ登録ファイルに含まれている場合は、そのユーザＩ
Ｄを持つユーザに対して配信されているコンテンツを、
取り出し端末に渡す。前記の例においては、ＨＧＷ２に
は、ユーザはＣＣＣＣのみ１名登録されているので、Ｈ
ＧＷ２に配信され蓄積されているコンテンツＣはユーザ
ＣＣＣＣのみが取り出せばよい。

【０２０８】ＨＧＷ１では、ユーザはＡＡＡＡとＢＢＢ
Ｂの２名が登録されている。ＨＧＷ１に接続された取り
出し端末から、ユーザＩＤとしてＡＡＡＡとパスワード
を受け取ったときは、ユーザＡＡＡＡに対して配信され
ているコンテンツＡを取り出し端末に渡す。同様に、ユ
ーザＩＤとしてＢＢＢＢとパスワードを受け取ったとき
は、ユーザＢＢＢＢに対して配信されているコンテンツ
Ｂを取り出し端末に渡す。

【０２０９】以上、本発明者によってなされた発明を、
前記実施形態（実施例）に基づき具体的に説明したが、
本発明は、前記実施形態（実施例）に限定されるもので
はなく、その要旨を逸脱しない範囲において種々変更可
能であることは勿論である。

【０２１０】

【発明の効果】本願において開示される発明のうち代表
的なものによって得られる効果を簡単に説明すれば、以
下のとおりである。

【０２１１】本発明によれば、クライアントとサーバの
間のトラフィックを軽減できる。

【０２１２】また、クライアントとサーバ間で有料の回
線を利用する場合は、無駄な回線使用コストを軽減でき
る。

【図面の簡単な説明】

【図１】本発明による一実施形態（実施例）のファイル
転送制御部の動作を示すフローチャートである。

【図２】本実施形態のファイル転送実行部の動作を示す
フローチャートである。

【図３】本実施形態の中断が一度も発生せずに正常終了
した場合のシーケンスチャートである。

【図４】本実施形態の中断が１回発生したが、次の再開
で復旧して、正常終了の場合のシーケンスチャートであ
る。

【図５】本実施形態の途中で中断し、そのまま時間切れ
の場合のシーケンスチャートである。

【図６】本実施形態のＨＧＷからＰＣへのデータの取り
出しについて説明するための図である。

【図７】本実施形態のユーザとＨＧＷの関係を示す図で
ある。

【図８】従来のダウンロードレジュームのアルゴリズム
を示すフローチャートである。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 稲垣 博人 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 (72)発明者 斉藤 隆一 東京都千代田区大手町二丁目３番１号 日 本電信電話株式会社内 Ｆターム(参考） 5B082 HA05 5B085 AA08 5K030 GA12 HA08 HB19 HC14 LD18 MB01 MB09 5K035 AA01 CC01 CC08 DD01 EE22 LL06

Claims (3)

【特許請求の範囲】
1. 【請求項１】 帯域が保証されていないデータ配信シス
   テム（ネットワーク）における、ファイル転送の中断再
   開が可能なダウンロード方法において、ダウンロードの
   中断再開タイマー値を可変とし、データダウンロード実
   行中の平均スループットをパラメータとして中断再開タ
   イマー値を制御することを特徴とするダウンロード方
   法。
2. 【請求項２】 帯域が保証されていないデータ配信シス
   テム（ネットワーク）における、ファイル転送の中断再
   開が可能なダウンロード方法において、ダウンロードが
   中断した際、ダウンロードするサーバマシンとの過去Ｘ
   （Ｘは固定値、設定により可変）秒のスループット（以
   下、Ｓと称する）が事前に設定した閾値（以下、Ｓｍｉ
   ｎと称する）以上（Ｓ≧Ｓｍｉｎ）であった場合は、一
   時的な回線または一時的なサーバ障害の疑いと判定し、
   （Ｆ−１）回（Ｆは固定値、設定により可変）は、短時
   間（ウェイトタイマー値Ｔｓ）で再開を試み、Ｆ回以上
   連続して再開に失敗した場合は、何らかの一時的障害が
   発生したと判定し、ウェイトタイマー値ＴｓをＴｌ（≧
   Ｔｓ）に設定変更して再開を試み、Ｓ≦Ｓｍｉｎの場合
   は、恒久的に回線状況が悪いと判断し、短時間（ウェイ
   トタイマー値Ｔｓ）で再開を試みることを特徴とするダ
   ウンロード方法。
3. 【請求項３】 帯域が保証されていないデータ配信シス
   テム（ネットワーク）における、ファイル転送の中断再
   開が可能なダウンロード方法の処理手順を、コンピュー
   タに実行させるためのプログラムを記憶したコンピュー
   タが読み出し可能な記憶媒体であって、ダウンロードが
   中断した際、ダウンロードするサーバマシンとの過去Ｘ
   （Ｘは固定値、設定により可変）秒のスループット（以
   下、Ｓと称する）が事前に設定した閾値（以下、Ｓｍｉ
   ｎと称する）以上（Ｓ≧Ｓｍｉｎ）であった場合は、一
   時的な回線または一時的なサーバ障害の疑いと判定する
   手順と、（Ｆ−１）回（Ｆは固定値、設定により可変）
   は、短時間（ウェイトタイマー値Ｔｓ）で再開を試みる
   手順と、Ｆ回以上連続して再開に失敗した場合は、何ら
   かの一時的障害が発生したと判定する手順と、ウェイト
   タイマー値をＴｌ（≧Ｔｓ）に設定変更して再開を試み
   る手順と、Ｓ≦Ｓｍｉｎの場合は、恒久的に回線状況が
   悪いと判断する手順と、短時間（ウェイトタイマー値＝
   Ｔｓ）で再開を試みる手順を、コンピュータに実行させ
   るためのプログラムを記憶したコンピュータが読み出し
   可能な記憶媒体。