(57)【特許請求の範囲】
【請求項１】
一定の処理能力を有する中継装置を経由して通信端末へコンテンツを配信するコンテンツ配信制御システムにおいて、
前記通信端末のスループットに基づいて当該通信端末へ配信予定のコンテンツに係る前記中継装置の予測負荷量を算出する予測負荷量算出手段と、
予め準備された前記中継装置に係るトラフィック雛型と前記中継装置の予測負荷量とに基づいて、前記中継装置にかかるであろう総負荷量が所定量を超えないように平準化された配信スケジュールを作成する配信スケジュール作成手段と、
を備えたことを特徴とするコンテンツ配信制御システム。
【請求項２】
前記予測負荷量算出手段は、前記通信端末のスループットの実績値に基づいて前記予測負荷量を算出することを特徴とする請求項１に記載のコンテンツ配信制御システム。
【請求項３】
前記通信端末へのコンテンツ配信結果に基づいて当該通信端末の実績スループットを算出するスループット算出手段を備えたことを特徴とする請求項２に記載のコンテンツ配信制御システム。
【請求項４】
前記スループット算出手段は、前記通信端末へのコンテンツ配信の都度、当該通信端末の実績スループットを更新して記録することを特徴とする請求項３に記載のコンテンツ配信制御システム。
【請求項５】
前記配信スケジュール作成手段は、前記通信端末からのコンテンツ更新確認要求時に、次回の配信に関する前記配信スケジュールを作成し、当該通信端末に対して次回のコンテンツ更新確認要求を行う時期を通知することを特徴とする請求項４に記載のコンテンツ配信制御システム。
【請求項６】
前記配信スケジュール作成手段は、前記配信スケジュールに基づき前記通信端末に対し前記通信端末の起動指示を含む信号を送信することを特徴とする請求項５に記載のコンテンツ配信制御システム。
【請求項７】
前記予測負荷量算出手段は、前記配信予定のコンテンツのサイズと前記通信端末のスループットとから、予測負荷量を算出することを特徴とする請求項１から６のいずれかの項に記載のコンテンツ配信制御システム。
【請求項８】
前記通信端末へ配信するコンテンツに関する情報が登録された登録コンテンツ情報記憶手段と、
前記通信端末で管理する登録コンテンツ情報と、前記登録コンテンツ情報記憶手段の登録コンテンツ情報とを照合し、登録コンテンツ情報の不整合を検出する登録コンテンツ情報不整合検出手段と、
前記登録コンテンツ情報不整合検出手段により登録コンテンツ情報の不整合が検出された場合、前記登録コンテンツ情報記憶手段の登録コンテンツ情報を前記通信端末へ送信する登録コンテンツ情報整合手段と、
を備えたことを特徴とする請求項１から７のいずれかの項に記載のコンテンツ配信制御システム。
【請求項９】
一定の処理能力を有する中継装置を経由して通信端末へコンテンツを配信するコンテンツ配信制御システムにおける配信スケジュール作成方法であって、
前記中継装置に係るトラフィック雛型を予め準備する過程と、
前記通信端末のスループットに基づいて当該通信端末へ配信予定のコンテンツに係る前記中継装置の予測負荷量を算出する過程と、
前記トラフィック雛型と前記中継装置の予測負荷量とに基づいて、前記中継装置にかかるであろう総負荷量が所定量を超えないように平準化して配信するようにスケジューリングする過程と、
を含むことを特徴とする配信スケジュール作成方法。
【請求項１０】
一定の処理能力を有する中継装置を経由して通信端末へコンテンツを配信するコンテンツ配信制御システムにおける配信スケジュールを作成するためのコンピュータプログラムであって、
前記通信端末のスループットに基づいて当該通信端末へ配信予定のコンテンツに係る前記中継装置の予測負荷量を算出する機能と、
予め準備された前記中継装置に係るトラフィック雛型と前記中継装置の予測負荷量とに基づいて、前記中継装置にかかるであろう総負荷量が所定量を超えないように平準化して配信するようにスケジューリングする機能と、
をコンピュータに実現させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ配信制御システム及びその配信スケジュール作成方法、コンピュータプログラムに関する。
本願は、２００４年５月１９日に出願された特願２００４−１４９１９３号に対し優先権を主張し、その内容をここに援用する。
【背景技術】
【０００２】  本発明は、コンテンツ配信制御システム及びその配信スケジュール作成方法、通信端末、並びにそのコンテンツ配信制御システムをコンピュータを利用して実現するためのコンピュータプログラムに関する。
近年、携帯電話機などの携帯無線端末においては、その処理能力の向上に伴い、番組コンテンツなど大きなサイズの動画像ファイルを高速で送受可能なものが実現されている。【０００３】  また、近年、携帯無線端末のユーザは、インターネットを利用して動画像などの番組コンテンツをオンデマンドで視聴することができるようになってきている。
また、通信回線を用いて端末に音楽データ等のデータを配信する際に、過去の時間帯別の配信予約件数の平均値や、配信サーバの時間当たりの最大の配信能力の上限値、伝送路の時間帯毎の混雑具合（伝送路の伝送速度を継続的に計測した結果から求められる）などに基づいて配信予定時刻を決定する配信システムが知られている（例えば、特開平１１−３５５３４６号公報）。これにより、情報を配信する配信サーバの負荷分散と、効率的な情報の配信を図っている。【０００４】  しかしながら、上記した従来の配信システムでは、端末自体のデータ通信速度（スループット）が全く考慮されずに配信予定時刻の決定が行われるために、予定通りに配信できず、十分な効果が得られないという問題がある。また、携帯無線端末の種類によっては、処理能力が低くスループットが遅いものがある。さらに、携帯無線端末は、電界強度やフェージングなどの無線状態によってスループットに大きな影響を受ける。したがって、携帯無線端末は、種類と無線状態とによってスループットが大きく異なる。このようにスループットが異なる端末に対して一律にデータの配信予定時刻をスケジューリングしても、単位時間当たりに配信できるデータ量が端末毎に異なるので、同じデータ量でも配信に要する時間が異なることとなり、配信スケジュールの精度が悪くなる。【０００５】  また、インターネットを利用したオンデマンドによる動画像などのコンテンツ配信サービスは、利用者にとっては便利なサービスであるが、ネットワークにとってはトラフィックが込み合っている状況下では混雑に拍車をかけることになる。一方、インターネットのトラフィックは時間帯による変動が大きく（日による変動は小さい）、特に深夜から早朝にかけては少ないため、そのネットワークリソースの有効利用が以前から課題とされていた。【０００６】  また、一般的な放送サービスのように予め番組の放送時間が決まっていれば、視聴者はその時間に放送を受信して番組を視聴したり、又は番組をビデオ録画して後で再生・視聴したりすることができる。【０００７】  本発明は、このような事情を考慮してなされたもので、その目的は、通信ネットワークのトラフィックの閑散時間帯（例えば深夜から早朝にかけての時間帯）を利用してコンテンツを配信する際に、端末ごとのスループットの差異、コンテンツのサイズなどから算出される予測負荷量を利用してトラフィックの平準化を図る配信スケジュールを作成することにより、ネットワークの利用効率の向上を図ることができるコンテンツ配信制御システム及びその配信スケジュール作成方法を提供することにある。【０００８】
また、本発明の他の目的は、本発明のコンテンツ配信制御システムをコンピュータを利用して実現するためのコンピュータプログラムを提供することにある。
【発明の開示】
【０００９】  本発明のコンテンツ配信制御システムは、一定の処理能力を有する中継装置を経由して通信端末へコンテンツを配信するコンテンツ配信制御システムにおいて、前記通信端末のスループットに基づいて当該通信端末へ配信予定のコンテンツに係る前記中継装置の予測負荷量を算出する予測負荷量算出手段と、予め準備された前記中継装置に係るトラフィック雛型と前記中継装置の予測負荷量とに基づいて、前記中継装置にかかるであろう総負荷量が所定量を超えないように平準化された配信スケジュールを作成する配信スケジュール作成手段と、を備えたことを特徴とする。
【００１０】  また、本発明のコンテンツ配信制御システムにおいて、前記予測負荷量算出手段は、前記通信端末のスループットの実績値に基づいて前記予測負荷量を算出することを特徴とする。
【００１１】  また、本発明のコンテンツ配信制御システムは、前記通信端末へのコンテンツ配信結果に基づいて当該通信端末の実績スループットを算出するスループット算出手段を備えたことを特徴とする。
【００１２】  また、本発明のコンテンツ配信制御システムにおいて、前記スループット算出手段は、前記通信端末へのコンテンツ配信の都度、当該通信端末の実績スループットを更新して記録することを特徴とする。
【００１３】  また、本発明のコンテンツ配信制御システムにおいて、前記配信スケジュール作成手段は、前記通信端末からのコンテンツ更新確認要求時に、次回の配信に関する前記配信スケジュールを作成し、当該通信端末に対して次回のコンテンツ更新確認要求を行う時期を通知することを特徴とする。
【００１４】  また、本発明のコンテンツ配信制御システムにおいて、前記配信スケジュール作成手段は、前記配信スケジュールに基づき前記通信端末に対し前記通信端末の起動指示を含む信号を送信することを特徴とする。
【００１５】  また、本発明のコンテンツ配信制御システムにおいて、前記予測負荷量算出手段は、前記配信予定のコンテンツのサイズと前記通信端末のスループットとから、予測負荷量を算出することを特徴とする。
【００１６】  また、本発明のコンテンツ配信制御システムは、前記通信端末へ配信するコンテンツに関する情報が登録された登録コンテンツ情報記憶手段と、前記通信端末で管理する登録コンテンツ情報と、前記登録コンテンツ情報記憶手段の登録コンテンツ情報とを照合し、登録コンテンツ情報の不整合を検出する登録コンテンツ情報不整合検出手段と、前記登録コンテンツ情報不整合検出手段により登録コンテンツ情報の不整合が検出された場合、前記登録コンテンツ情報記憶手段の登録コンテンツ情報を前記通信端末へ送信する登録コンテンツ情報整合手段と、を備えたことを特徴とする。
【００１７】
また、本発明の一実施形態に係る通信端末は、一定の処理能力を有する中継装置を経由してコンテンツの配信を受ける通信端末であって、前記配信されるコンテンツに関する情報が登録された登録コンテンツ情報記憶手段と、コンテンツ配信制御システムで管理する登録コンテンツ情報を受信し、前記登録コンテンツ情報記憶手段の登録内容を更新する登録コンテンツ情報整合手段と、を備えたことを特徴とする。
【００１８】
また、本発明の一実施形態に係る通信端末は、一定の処理能力を有する中継装置を経由してコンテンツの配信を受ける通信端末であって、前記配信されるコンテンツのサイズに応じた記憶手段のメモリ量を予め割り当てて確保するメモリ管理手段と、前記記憶手段に確保されたメモリ領域に、配信されたコンテンツを保存するコンテンツ保存制御手段と、を備えたことを特徴とする。
【００１９】  また、本発明の配信スケジュール作成方法は、一定の処理能力を有する中継装置を経由して通信端末へコンテンツを配信するコンテンツ配信制御システムにおける配信スケジュール作成方法であって、前記中継装置に係るトラフィック雛型を予め準備する過程と、前記通信端末のスループットに基づいて当該通信端末へ配信予定のコンテンツに係る前記中継装置の予測負荷量を算出する過程と、前記トラフィック雛型と前記中継装置の予測負荷量とに基づいて、前記中継装置にかかるであろう総負荷量が所定量を超えないように平準化して配信するようにスケジューリングする過程と、を含むことを特徴とする。
【００２０】  また、本発明のコンピュータプログラムは、一定の処理能力を有する中継装置を経由して通信端末へコンテンツを配信するコンテンツ配信制御システムにおける配信スケジュールを作成するためのコンピュータプログラムであって、前記通信端末のスループットに基づいて当該通信端末へ配信予定のコンテンツに係る前記中継装置の予測負荷量を算出する機能と、予め準備された前記中継装置に係るトラフィック雛型と前記中継装置の予測負荷量とに基づいて、前記中継装置にかかるであろう総負荷量が所定量を超えないように平準化して配信するようにスケジューリングする機能と、をコンピュータに実現させることを特徴とする。
【００２１】  また、本発明によれば、通信端末（例えば携帯無線端末）の過去のスループットと配信予定のコンテンツのサイズから次回のコンテンツ配信時に中継装置にかかる予測負荷量を算出し、中継装置にかかるであろう総負荷量が所定量を超えないように平準化して配信するようにスケジューリングすることができる。これにより、通信ネットワークのトラフィックの閑散時間帯（例えば深夜から早朝にかけての時間帯）を利用してコンテンツを配信する際に、ネットワークの利用効率の向上を図ることが可能となる。
【図面の簡単な説明】
【００２２】［図１］図１は、本発明の一実施形態に係るコンテンツ配信システムの構成を示すブロック図である。
［図２］図２は、図１に示すＰｒｏｘｙ３及びログサーバ４について説明するためのブロック図である。
［図３］図３は、図１に示すＤＥＣ５について説明するためのブロック図である。
［図４］図４は、本発明に係る配信スケジュール作成方法を説明するための第１の図である。
［図５］図５は、本発明に係る配信スケジュール作成方法を説明するための第２の図である。
［図６］図６は、図１に示すコンテンツ配信システムに係る配信処理の概略シーケンス図である。
［図７］図７は、ＤＥＣ５に記憶されるユーザ情報１０１、番組情報１０２、Ｐｒｏｘｙトラフィック情報１０３及び携帯無線端末種別情報１０４の構成例を示す図である。
［図８］図８は、本発明に係る予測リクエスト数と予測保留時間の関係を説明するための概念図である。
［図９］図９は、本発明に係る配信スケジュール作成方法を説明するための第３の図である。
［図１０］図１０は、本発明に係るコンテンツ配信システムの一実施例を説明するための第１のシーケンス図である。
［図１１］図１１は、本発明に係るコンテンツ配信システムの一実施例を説明するための第２のシーケンス図である。
［図１２］図１２は、本発明に係るコンテンツ配信システムの一実施例を説明するための第３のシーケンス図である。
［図１３］図１３は、本発明に係るコンテンツ配信システムの一実施例を説明するための第４のシーケンス図である。
［図１４］図１４は、図１に示すコンテンツ配信システムに係る配信処理の概略シーケンス図である。
【発明を実施するための最良の形態】
【００２３】  以下、図面を参照しつつ、本発明の好適な実施例について説明する。ただし、本発明は以下の各実施例に限定されるものではなく、例えばこれら実施例の構成要素同士を適宜組み合わせてもよい。【００２４】  以下、図面を参照し、本発明の一実施形態について説明する。
図１は、本発明の一実施形態に係るコンテンツ配信システムの構成を示すブロック図である。このコンテンツ配信システムでは、音声、画像（動画像又は静止画像）又はテキストなどから構成される番組を配信する。図１において、携帯無線端末１は、移動通信網２の加入端末であり、移動通信網２に接続して音声通話やインターネット経由のデータ通信（電子メール、Ｗｅｂアクセス、データダウンロード等）、ダウンロードした番組の再生等を行うことが可能である。携帯無線端末１には、本コンテンツ配信システムによる番組配信サービス専用のアプリケーション１ａが組み込まれている。【００２５】  Ｐｒｏｘｙ３は、携帯無線端末１によるＷｅｂアクセスを中継する装置である。このＷｅｂアクセスには、本配信サービスに係るアクセスと、これ以外のアクセスとが含まれる。ログサーバ４は、Ｐｒｏｘｙ３のトラフィックデータを収集する装置である。ＤＥＣ（ＤＥｌｉｖｅｒｙ  Ｃｏｎｔｒｏｌｌｅｒ；配信制御装置）５は、本配信サービスにおけるＣＰ（コンテンツプロバイダ）情報、番組情報、ユーザ情報の管理や、携帯無線端末１への配信スケジュール及び配信結果の管理などを行う装置（コンテンツ配信制御システム）である。【００２６】  配信サーバ６は、本配信サービスで提供する番組を携帯無線端末１に対して配信する。
ＣＰのＷｅｂサーバ７は、本配信サービスで提供する番組の提供元のＷｅｂサーバであり、提供番組の登録・解約を行うためのＷｅｂページを開設している。このＷｅｂサーバ７のＷｅｂページは、ＤＥＣ５のユーザ窓口のＷｅｂページからリンクしている。【００２７】  上記Ｐｒｏｘｙ３、ＤＥＣ５、配信サーバ６及びＷｅｂサーバ７は、それぞれ通信ネットワーク８に接続している。通信ネットワーク８はインターネットや専用網などから構成される。また、ログサーバ４は、Ｐｒｏｘｙ３及びＤＥＣ５に接続されている。【００２８】  図２は、Ｐｒｏｘｙ３及びログサーバ４について説明するためのブロック図である。図２において、Ｐｒｏｘｙ３は、携帯無線端末１によるＷｅｂアクセス時の通信セッションを中継処理する。また、Ｐｒｏｘｙ３は、ログ出力項目Ｌ１を含むログデータをログサーバ４へ出力する。Ｐｒｏｘｙ３は、Ｇ／Ｗルータ３１を介して移動通信網２に接続される。また、インターネットを介して配信サーバ６と接続する。【００２９】  ログサーバ４は、Ｐｒｏｘｙ３のログデータを収集し、Ｐｒｏｘｙ３を経由する全てのリクエストをロギングする。そして、そのロギングデータを集計し、集計ログ出力項目Ｌ２を含むログデータを作成する。このログデータは、ルータ３２を介して、ＤＥＣ５によりファイル転送で取得される。【００３０】  ＤＥＣ５に転送されるログデータには、例えば１日分のＰｒｏｘｙ３のログデータの集計結果が含まれる。その集計結果の内容は、例えば集計単位が１分ごとであり、その集計項目としては、全サービス分のリクエスト数および平均転送バイト数、並びに本配信サービス分のリクエスト数および平均転送バイト数などである。【００３１】  図３は、ＤＥＣ５について説明するためのブロック図である。図３において、コントロールサーバ５１は、携帯無線端末１との間で規定されたインタフェースに基づき、番組の登録、解約、配信、登録番組一覧表示を実施するための制御を行う。ポータルサーバ５２は、本配信サービス用のサイト管理を行うＷｅｂサーバであり、ＣＰのＷｅｂサーバ７へリンクしている。上記コントロールサーバ５１及びポータルサーバ５２は、携帯無線端末１からアクセス可能である。Ｓｏｒｒｙサーバ５３は、コントロールサーバ５１又はポータルサーバ５２へのアクセスが不可の場合に、携帯無線端末１からのアクセスが振り分けされ、アクセス不可能であることを示す。【００３２】  分析サーバ５４は、ログサーバ４からログデータを取得し、トラフィック分析用データとして管理する。データベース（ＤＢ）サーバ５５は、トラフィック情報、ＣＰ情報、番組情報及びユーザ情報等を蓄積する。運用サーバ５６は、本システム運用者やＣＰに対して、各運用端末からのＣＰ情報、番組情報及びユーザ情報（携帯無線端末情報等）等を登録したり、又は変更等を行う機能を実現する。【００３３】  次に、本実施形態に係る配信スケジュールの作成方法について説明する。
本コンテンツ配信システムでは、配信スケジュール用のトラフィック雛型（以下、単にトラフィック雛型と称する）を予め準備する。そして、このトラフィック雛型に基づいて配信スケジュールを作成する。【００３４】  初めに、このトラフィック雛型の作成方法を説明する。
先ず、図４に示されるように、Ｐｒｏｘｙ３におけるＷｅｂサービス全体のトラフィックＡから、Ｐｒｏｘｙ３における本配信サービス分のトラフィックＢを差し引いた残りのベーストラフィックＣを算出する。Ｗｅｂサービス全体のトラフィックＡ及び本配信サービス分のトラフィックＢは、ログサーバ４のログデータから得られたものである。【００３５】  次いで、図５に示されるように、ベーストラフィックＣに対して、今後のトラフィックの伸びをマージンαとして加えたものを「トラフィック雛型」としてＤＥＣ５に設定する。そして、ＤＥＣ５は、このトラフィック雛型に基づいて配信スケジュールを作成する。【００３６】  図５の例では、トラフィックの閑散時間帯である深夜時間帯（例えば午前２時から午前６時までの時間帯）をスケジューリング対象の時間帯としてＤＥＣ５に設定する。また、Ｐｒｏｘｙ３の処理性能限界からマージンβ分を差し引いたＰｒｏｘｙトラフィック上限をＤＥＣ５に設定する。これらの設定データはＤＢサーバ５５などで保持される。これにより、ＤＥＣ５では、深夜時間帯（例えば午前２時から午前６時までの時間帯）において、トラフィック雛型からＰｒｏｘｙトラフィック上限までのＰｒｏｘｙ３の余剰トラフィックが、本配信サービスで使用可能となる。【００３７】  なお、Ｐｒｏｘｙ３における単位時間当たりの処理負荷は、携帯無線端末１から受信した単位時間当たりのリクエスト数に比例する。これにより、Ｐｒｏｘｙ３における単位時間当たりの予測負荷量には、携帯無線端末１から受信した単位時間当たりのリクエスト数を用いることができる。
あるいは、ＤＥＣ５は、このＰｒｏｘｙ３における単位時間当たりの予測負荷量として、″リクエスト数×平均転送バイト数″により得られる配信帯域を用いても良い。
以降、予測負荷量にリクエスト数を用いるケースを説明する。
また、トラフィック雛型は、ログサーバ４のログデータを基に適宜見直しされ、更新される。【００３８】  次に、図６を参照して、ＤＥＣ５における配信スケジュール作成に係る動作を説明する。
図６は、本実施形態に係る配信処理の概略シーケンス図である。この図６において、携帯無線端末１は、ＤＥＣ５から予め指定された時刻になると、タイマ起動により自動的に専用アプリケーション１ａを起動して、コンテンツ更新確認要求を行う（ステップＳ１）。この携帯無線端末１からのアクセスを受けると、ＤＥＣ５は、コンテンツ更新確認処理と次回のタイマ起動日時算出処理を実施する（ステップＳ２）。【００３９】  ここで、ＤＥＣ５による次回のタイマ起動日時算出処理を説明する。
ＤＥＣ５は、ＤＢサーバ５５内に、図７に示されるユーザ情報１０１、番組情報１０２、Ｐｒｏｘｙトラフィック情報１０３及び携帯無線端末種別情報１０４などを記憶している。
これらの情報１０１〜１０４に基づいて、ＤＥＣ５は、ユーザ毎に、登録している番組に関する情報（番組ＩＤ、番組ファイルのサイズ（番組サイズ）、公開予定日、配信サーバ６のＵＲＬ（配信ＵＲＬ情報）など）、Ｐｒｏｘｙトラフィック情報、携帯無線端末１のレスポンスサイズ（１リクエスト当たりの取得バイト数）、過去の配信スループット（最新５回分のスループットの実績値と平均値（実績スループット情報））などを管理する。
Ｐｒｏｘｙトラフィック情報には、上記したトラフィック雛型の情報として、単位時間（例えば１分間）当たりのリクエスト数（単位時間あたりの雛型）などが含まれる。【００４０】  次回のタイマ起動日時算出処理において、ＤＥＣ５は、当該ユーザの次回配信する登録番組のファイルサイズとレスポンスサイズとから、該ファイル配信の際に当該ユーザの携帯無線端末１が配信サーバ６に送信するリクエストの総回数を求める。
例えば、レスポンスサイズが９６Ｋバイトであった場合、３Ｍバイトのファイルを取得するには、携帯無線端末１は配信サーバ６に対してリクエストを少なくとも３２回送信する必要がある。
「３Ｍバイト÷９６Ｋバイト＝３２」より、総リクエスト数＝３２回。
次いで、ＤＥＣ５は、次回配信するファイルサイズと過去の配信スループットとから、次回配信に要する時間を計算する。
例えば、３Ｍバイトのファイルを過去の配信スループット「２０５Ｋｂｐｓ（毎秒２０５Ｋビット）」で送信すると、保留時間＝３Ｍバイト÷２０５Ｋｂｐｓ＝１２０秒、となる。【００４１】  次いで、ＤＥＣ５は、携帯無線端末１が送信する単位時間（１分間）当たりのリクエスト数を求める。
例えば、総リクエスト数が３２回、保留時間が１２０秒の場合、リクエスト数／分＝３２回÷１２０秒×６０＝１６となる。ここで算出された「単位時間（１分間）当たりのリクエスト数」が、次回のスケジューリング対象時間帯にスケジューリングすべき、Ｐｒｏｘｙ３にかかる単位時間（１分間）当たりの予測リクエスト数である。そして、この予測リクエスト数が、予測保留時間だけ保留される。【００４２】  図８は、単位時間（１分間）当たりの予測リクエスト数と予測保留時間の関係を説明するための概念図である。ファイルの転送に要する総予測負荷量は、単位時間当たりの予測リクエスト数と予測保留時間の積である。図８に示されるように、同じ総リクエスト数であっても、携帯無線端末１のスループットが高く配信速度が速い場合は、携帯無線端末１のスループットが低く配信速度が遅い場合に比して、予測保留時間が短くなり、単位時間当たりの予測リクエスト数が多くなる。【００４３】  次いで、ＤＥＣ５は、その算出した単位時間当たりの予測リクエスト数と予測保留時間からなる総予測負荷量、トラフィック雛型、及び他ユーザを含むスケジューリング状況から、次回のファイル配信日時（すなわち無線携帯端末１の次回のタイマ起動日時でありかつ無線携帯端末１がＤＥＣ５に対してコンテンツ更新確認を要求する時）を決定する。
図９は、Ｐｒｏｘｙ３にかかる総予測負荷量をスケジューリングする方法を説明するための概念図である。図９（ａ）には、次回の配信時間帯におけるスケジューリング状況が示されている。ＤＥＣ５は、登録番組情報から次回の配信日を判断し、対象日のスケジューリングテーブルを取得し、スケジューリング済みのトラフィックが最も低いところをサーチする。そして、このサーチにより見つかったところへ総予測負荷量を配置する。ここで、配置後のトラフィックが一部でもトラフィック上限を超えた場合には（図９（ｂ））、再度サーチし、総予測負荷量を再配置する（図９（ｃ））。この結果、トラフィック上限を超えずに総予測負荷量を配置することができたときに、スケジューリングの予約確定とする。そして、この配置した時間帯の先頭時刻を、無線携帯端末１へ通知する次回のタイマ起動日時として決定する。この決定したスケジュールについては、当該配信日用のスケジュールテーブルに登録する。スケジュールテーブルはＤＢサーバ５５内に保存される。ＤＥＣ５は、スケジューリングの際には、ＤＢサーバ５５内のスケジュールテーブルを参照してスケジューリング対象日のスケジューリング状況を取得する。
なお、Ｐｒｏｘｙ３の処理能力に余裕のある時間帯から優先的にスケジューリングすることにより、番組を確実に配信することが可能となる。【００４４】  図６に戻り、ＤＥＣ５は、上記算出した次回のタイマ起動日時と、今回配信する配信サーバ６のＵＲＬとを携帯無線端末１へ返信する（ステップＳ３）。携帯無線端末１は、この次回のタイマ起動日時を記憶する。次いで、携帯無線端末１は、その配信ＵＲＬに基づいて配信サーバ６へアクセスし、番組配信の要求を行う（ステップＳ４）。その後、配信サーバ６は、携帯無線端末１からのリクエストに応じたレスポンスとして、該当する番組ファイルを指定されたサイズに分割して送信する（ステップＳ５）。この動作は、番組ファイルのダウンロードが完了するまで繰り返し行なわれる。携帯無線端末１は、この番組ファイルを受信して自己のメモリに保存する。携帯無線端末１は、その保存した番組ファイルを再生する機能を有する。これにより、ユーザは、ネットワークに接続しなくても好きな時に、携帯無線端末１に保存されている番組ファイルを再生することができる。【００４５】  次いで、携帯無線端末１は、今回の配信が成功し終了すると、配信結果として受信したファイルの実サイズ（受信バイト数）をＤＥＣ５へ通知する（ステップＳ６）。この配信結果の通知を受けると、ＤＥＣ５は、今回のスループットを計算する（ステップＳ７）。このスループット計算処理では、今回の配信開始時刻と配信終了時刻から配信所要時間を算出する。そして、携帯無線端末１から通知された配信結果である受信バイト数を配信所要時間で除して今回のスループットを求める。そして、今回のスループットを用いて当該ユーザ情報の実績スループット情報を更新する。ＤＥＣ５では、ユーザごとに例えば過去１０回分のスループット値と、指定された回数分（例えば最新５回分）の平均スループット値を管理する。
なお、配信が失敗した場合にも携帯無線端末１の実受信バイト数をＤＥＣ５へ通知してスループットの算出に使用するようにしてもよい。【００４６】  次に、上述した実施形態に係るコンテンツ配信システムの一実施例を説明する。
図１０〜図１３は、本発明に係るコンテンツ配信システムの一実施例を説明するためのシーケンス図である。【００４７】  初めに、図１０を参照して、番組登録に係る動作を説明する。
図１０において、携帯無線端末１は、ユーザ操作により所望のＣＰのＷｅｂサーバ（以下、ＣＰサーバ）７を介してＤＥＣ５のコントロールサーバ５１へ番組登録を要求する。これにより、コントロールサーバ５１は、登録可否チェックを行う（ステップＳ１０１）。この登録可否チェックでは、登録可能数の範囲内であるかのチェックや、携帯無線端末１のメモリ量が今回の番組ファイルのサイズを満足しているかなどのチェックを行う。また、携帯無線端末１で管理している既登録番組と、ＤＥＣ５で管理している当該携帯無線端末１の既登録番組との間で不整合が生じていないかチェックする（ステップＳ１０２）。ここで、不整合を発見した場合には、ＤＥＣ５の番組情報（番組ＩＤ等）を携帯無線端末１へ送信し、携帯無線端末１の番組情報をＤＥＣ５に合わせる。このように、携帯無線端末１とＤＥＣ５の双方で管理される登録番組ＩＤを整合させることにより、携帯無線端末１が誤番組の配信を未然に防ぐことができ、ＤＥＣ５により作成された配信スケジュールを円滑に実行することが可能となる。【００４８】  不整合を発見しなかった場合、コントロールサーバ５１は、番組情報を抽出し、次回タイマ起動日時を算出し（ステップＳ１０３）、この次回タイマ起動日時と番組名と番組サイズを携帯無線端末１へ送信して番組情報登録設定を要求する。この次回タイマ起動日時は、携帯無線端末１における次回のコンテンツ確認要求日時となる。【００４９】  次いで、ユーザ操作により登録ボタンを押下すると、ＤＥＣ５から通知された番組ＩＤや番組サイズ、次回タイマ起動日時等の番組情報をメモリに書き込む。ただし、この段階では書き込んだ情報は有効とはならずに、この後にコントロールサーバ５１からの番組情報本登録応答を受け取ると書き込んだ情報を有効とする。これにより、携帯無線端末１は、自己のメモリから当該番組ファイルを蓄積する分のメモリ量を割り当てて確保する。このように、携帯無線端末１において配信される番組のサイズに応じたメモリ量を予め確保しておくことにより、携帯無線端末１のメモリ不足による配信失敗を未然に防ぐことができ、ＤＥＣ５により作成された配信スケジュールを円滑に実行することが可能となる。【００５０】  次に、図１１を参照して、番組解約に係る動作を説明する。
図１１において、携帯無線端末１は、ユーザ操作によりコントロールサーバ５１へ番組解約を要求する。これにより、携帯無線端末１は、コントロールサーバ５１からのリダイレクトによりＣＰサーバ７の解約ページへアクセスする。次いで、コントロールサーバ５１は、携帯無線端末１からの解約可否チェック要求を受信すると、解約可否をチェックし（ステップＳ２０１）、チェック結果を携帯無線端末１へ応答する。このチェック結果により解約可の場合、コントロールサーバ５１は、携帯無線端末１へ解約設定要求を送信し、ＤＥＣ５上での解約を完了する。また、携帯無線端末１は、自己で管理している当該番組情報を消去するとともに、当該番組ファイル用に割り当てていたメモリ量を解放する。
次いで、携帯無線端末１は、コントロールサーバ５１との間で設定応答を行い、解約を完了する。【００５１】  次に、図１２を参照して、番組登録一覧表示に係る動作を説明する。
図１２において、携帯無線端末１は、ユーザ操作によりポータルサーバ５２のＷｅｂページを介してコントロールサーバ５１へ登録番組情報取得を要求する。これにより、コントロールサーバ５１は、携帯無線端末１で管理している既登録番組と、ＤＥＣ５で管理している当該携帯無線端末１の既登録番組との間で不整合が生じていないかチェックする（ステップＳ３０１）。ここで、不整合を発見した場合には、ＤＥＣ５の既登録番組管理内容をコントロールサーバ５１から携帯無線端末１へ送信し、携帯無線端末１の既登録番組管理内容をＤＥＣ５に合わせる（ステップＳ３０２）。次いで、この登録番組情報に含まれている登録番組の一覧が携帯無線端末１で画面表示される。【００５２】  次に、図１３を参照して、番組配信に係る動作を説明する。
図１３において、携帯無線端末１は、タイマ起動日時になると、タイマ起動によりコントロールサーバ５１へアクセスする。このアクセスにより、コントロールサーバ５１は、当該携帯無線端末１との間で、登録番組に不整合がないかをチェックし、不整合がなければ、新着番組の有無を検索し、次回タイマ起動日時を算出する（ステップＳ４０１）。次いで、コントロールサーバ５１は、今回の配信用のＵＲＬと次回タイマ起動日時を携帯無線端末１へ返信する。但し、新着番組が無い場合は、次回タイマ起動日時を通知するが、配信用のＵＲＬは通知しない。また、登録番組の不整合を発見した場合は、ＤＥＣ５の既登録番組管理内容を携帯無線端末１へ送信し、携帯無線端末１の既登録番組管理内容をＤＥＣ５に合わせる。この場合にも、次回タイマ起動日時は通知するが、新着番組があっても配信用のＵＲＬは通知しない。【００５３】  次いで、携帯無線端末１は、その返信されたＵＲＬを使用して配信サーバ６へアクセスし、自己のレスポンスサイズずつ番組のダウンロードを要求する。このダウンロードされた番組は、携帯無線端末１内で当該番組保存用に割り当てられているメモリに書き込まれる。このダウンロードが終了すると、携帯無線端末１は、コントロールサーバ５１へ、配信により上書きされた前回ダウンロードした番組を一度でも再生したか否かを、今回のダウンロード結果とともに通知する。これにより、コントロールサーバ５１は、配信結果を記録し、また今回のスループットを算出して当該ユーザの実績スループット情報を更新し、また前回の番組が視聴されたか否かを記録する（ステップＳ４０２）。【００５４】  上述したように本実施形態によれば、携帯無線端末の過去の配信スループットから次回の番組配信時にＰｒｏｘｙ３にかかる予測負荷量を算出する。そして、Ｐｒｏｘｙ３にかかるであろう総負荷量が所定量を超えないように平準化して配信するようにスケジューリングすることができる。これにより、通信ネットワークのトラフィックの閑散時間帯（例えば深夜から早朝にかけての時間帯）を利用して番組を配信する際に、ネットワークの利用効率の向上を図ることが可能となる。【００５５】  また、深夜時間帯にはユーザが睡眠中であり、携帯無線端末が移動していない可能性が高いので無線状態が安定している。このため、深夜から朝にかけてのユーザが活動を開始するまでの時間帯において、確実に番組を配信して端末内に蓄積することにより、ユーザ活動に合致した番組配信を実現することができる。
なお、本実施形態に係るＤＥＣ５は、専用のハードウェアにより実現されるものであってもよく、あるいは汎用のコンピュータシステムにより構成され、図３に示されるＤＥＣ５の各機能を実現するためのプログラムを実行することによりその機能を実現させるものであってもよい。【００５６】  また、そのＤＥＣ５には、周辺機器として入力装置、表示装置等（いずれも図示せず）が接続されるものとする。ここで、入力装置とはキーボード、マウス等の入力デバイスのことをいう。表示装置とはＣＲＴ（Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ）や液晶表示装置等のことをいう。
また、上記周辺機器については、ＤＥＣ５に直接接続するものであってもよく、あるいは通信回線を介して接続するようにしてもよい。【００５７】  また、図３に示すＤＥＣ５の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより配信スケジュール作成処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。【００５８】  また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。【００５９】  さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ））のように、一定時間プログラムを保持しているものも含むものとする。【００６０】  また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。【００６１】  また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。
さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。【００６２】  以上、本発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
例えば、本発明は、定期的に配信センタからユーザ端末へコンテンツを自動配信するサービスに応用することができる。【００６３】  図６に示す他にも図１４に示すように、ＤＥＣ５が、前回算出した時刻に携帯無線端末１へアクセスし起動を要求しても良い。【００６４】  ＤＥＣ５は、スケジュール作成処理により、携帯無線端末１ごとに次回のタイマ起動日時を算出し管理している。ＤＥＣ５は、算出した時刻になるとタイマ起動処理して（ステップＳ５０１）、携帯無線端末１に起動を要求する（ステップＳ５０２）。携帯無線端末１は、それをトリガにしてＤＥＣ５にコンテンツの更新確認を要求する（ステップＳ５０３）。次に、ＤＥＣ５は、コンテンツ更新確認処理の後、次回のタイマ起動日時を算出して記憶し（ステップＳ５０４）、今回配信する配信サーバ６のＵＲＬを携帯無線端末１へ送信する（ステップＳ５０５）。以降の携帯無線端末１による配信サーバ６へのアクセス処理（ステップＳ５０６〜ステップＳ５０９）は前述と同様である。
【産業上の利用可能性】
【００６５】  本発明は、通信端末（例えば携帯無線端末）の過去のスループットと配信予定のコンテンツのサイズから次回のコンテンツ配信時に中継装置にかかる予測負荷量を算出し、中継装置にかかるであろう総負荷量が所定量を超えないように平準化して配信するようにスケジューリングするものである。これにより、通信ネットワークのトラフィックの閑散時間帯（例えば深夜から早朝にかけての時間帯）を利用してコンテンツを配信する際に、ネットワークの利用効率の向上を図ることが可能となる。
【図１】
0004160093.tif 000002
【図２】
0004160093.tif 000003
【図３】
0004160093.tif 000004
【図４】
0004160093.tif 000005
【図５】
0004160093.tif 000006
【図６】
0004160093.tif 000007
【図７】
0004160093.tif 000008
【図８】
0004160093.tif 000009
【図９】
0004160093.tif 000010
【図１０】
0004160093.tif 000011
【図１１】
0004160093.tif 000012
【図１２】
0004160093.tif 000013
【図１３】
0004160093.tif 000014
【図１４】
0004160093.tif 000015