(57)【要約】【課題】  コンテンツを効率的にユーザ端末へ配信する配信サーバを提供する。【解決手段】  配信サーバ本体２ａは、ユーザ端末から監視対象の配信サーバへのアクセスのログに基づき、該配信サーバにおける配信負荷を予測する自サーバ負荷状態監視部１１と、自サーバ負荷状態監視部１１により配信サーバ２への配信負荷が高くなると予測される場合、配信サーバ２以外の配信サーバからコンテンツを配信することを決定する配信サーバ判断部１２とを備えている。【選択図】  図１
2006065516.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツの配信サーバの配信負荷を分散する配信負荷分散装置であって、
ユーザ端末から監視対象の配信サーバへのアクセスのログに基づき、該配信サーバにおける配信負荷を予測する負荷状態監視手段と、
上記負荷状態監視手段により上記配信サーバへの配信負荷が高くなると予測される場合、上記配信サーバ以外の配信サーバからコンテンツを配信することを決定する配信サーバ判断手段とを備えていることを特徴とする配信負荷分散装置。
【請求項２】
上記負荷状態監視手段は、さらに、上記監視対象の配信サーバからコンテンツを配信することを許可できるコンテンツ配信要求が上記配信サーバに送信される周期、コンテンツ配信に用いられるチャネルの数、およびコンテンツをユーザ端末に転送するための時間に基づき設定されるしきい値を用いて、該配信サーバにおける配信負荷を予測することを特徴とする請求項１に記載の配信負荷分散装置。
【請求項３】
請求項１または２に記載の配信負荷分散装置を備えていることを特徴とする配信サーバ。
【請求項４】
他の配信サーバにおけるコンテンツ配信負荷を監視する他サーバ負荷状態監視手段を備えていることを特徴とする請求項３に記載の配信サーバ。
【請求項５】
複数のユーザ端末のそれぞれに割り当てられた帯域を用いて、各ユーザ端末へコンテンツ配信を行うことを特徴とする請求項３または４に記載の配信サーバ。
【請求項６】
請求項１または２に記載の配信負荷分散装置と、該配信負荷分散装置の負荷状態監視手段により配信負荷が予測される配信サーバを少なくとも１つ含む複数の配信サーバと、該複数の配信サーバのいずれかからコンテンツが配信される複数のユーザ端末とを備えていることを特徴とするコンテンツ配信システム。
【請求項７】
請求項３ないし５のいずれか１項に記載の配信サーバを含む複数の配信サーバと、該複数の配信サーバのいずれかからコンテンツが配信される複数のユーザ端末とを備えていることを特徴とするコンテンツ配信システム。
【請求項８】
上記配信サーバによるコンテンツ配信を補助する副配信サーバを備えていることを特徴とする請求項６または７に記載のコンテンツ配信システム。
【請求項９】
上記コンテンツ配信システムにおける複数のユーザ端末からのコンテンツ配信要求を受け付ける受付装置を備えていることを特徴とする請求項６ないし８のいずれか１項に記載のコンテンツ配信システム。
【請求項１０】
コンテンツの配信サーバにおける配信負荷を分散する配信負荷分散方法であって、
監視対象の配信サーバへのアクセスのログに基づき、該配信サーバにおける配信負荷を予測する第１ステップと、
上記第１ステップにより上記配信サーバへの配信負荷が高くなると予測される場合、上記配信サーバ以外の配信サーバからコンテンツを配信することを決定する第２ステップとを備えていることを特徴とする配信負荷分散方法。
【請求項１１】
請求項１０に記載の配信負荷分散方法をコンピュータに実行させるための配信負荷分散プログラム。
【請求項１２】
請求項１１に記載の配信負荷分散プログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、配信サーバから複数のユーザ端末にコンテンツを配信する際、配信サーバにおける負荷を分散して効率的にコンテンツを配信するための配信負荷分散装置、配信サーバ、コンテンツ配信システム、配信負荷分散方法、配信負荷分散プログラム、およびコンピュータ読み取り可能な記録媒体に関する。
【背景技術】
【０００２】
近年、ネットワークを介してサーバ装置にアクセスすることで、映像や音楽等の情報が家庭で視聴できるようになっている。映像データや音楽データは、大容量のコンテンツであるので、効率よくサーバ装置から利用者端末装置に伝送される必要がある。そのためには、ユーザからのコンテンツ配信要求がサーバ装置に集中した場合にも対応し得るコンテンツ配信システムの構築が必要となる。
【０００３】
つまり、ユーザからのコンテンツ配信要求がサーバ装置に集中すると、サーバ装置に掛かる配信負荷が高くなり、サーバ装置のコンテンツ配信が不調となる場合がある。また、配信要求をしてから実際にコンテンツが配信されるまでの待ち時間が長くなり、ユーザを苛立たせてしまうこともある。
【０００４】
このように配信要求が集中した場合に発生し得る問題に対応したコンテンツ配信システムとしては、特許文献１に記載されているものを挙げることができる。特許文献１に記載されたコンテンツ配信システムでは、コンテンツの送出数または予測可能なアクセス数が対応するしきい値を超えた場合に、ビデオサーバと他ビデオサーバ間とでコンテンツの格納制御を行って、コンテンツの動的配信を行う。
【特許文献１】特開平１１−９８４４６号公報（１９９９年４月９日公開）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１では、アクセス数をどのように予測するかについて具体的な記載がない。したがって、アクセス数について誤った予測を行うと、アクセス数が多いにも関わらず他ビデオサーバからコンテンツ配信が行われなかったり、またはアクセス数がそれほど多くないのに他ビデオサーバからコンテンツ配信を行われたりするというように、コンテンツの配信を効率的に行うことができない場合がある。
【０００６】
本発明は、上記従来の問題点に鑑みなされたものであって、コンテンツを効率的にユーザ端末へ配信し得る配信負荷分散装置、配信サーバ、コンテンツ配信システム、配信負荷分散方法、配信負荷分散プログラム、およびコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の配信負荷分散装置は、上記課題を解決するために、コンテンツの配信サーバの配信負荷を分散するものであって、ユーザ端末から監視対象の配信サーバへのアクセスのログに基づき、該配信サーバにおける配信負荷を予測する負荷状態監視手段と、上記負荷状態監視手段により上記配信サーバへの配信負荷が高くなると予測される場合、上記配信サーバ以外の配信サーバからコンテンツを配信することを決定する配信サーバ判断手段とを備えていることを特徴としている。
【０００８】
また、本発明の配信負荷分散方法は、コンテンツの配信サーバにおける配信負荷を分散する方法であって、監視対象の配信サーバへのアクセスのログに基づき、該配信サーバにおける配信負荷を予測する第１ステップと、上記第１ステップにより上記配信サーバへの配信負荷が高くなると予測される場合、上記配信サーバ以外の配信サーバからコンテンツを配信することを決定する第２ステップとを備えている。
【０００９】
上記構成によれば、負荷状態監視手段または第１ステップにより監視対象の配信サーバ（自配信サーバ）における配信負荷が高くなると予測される場合、配信サーバ判断手段または第２ステップにより自配信サーバ以外の配信サーバ（他配信サーバ）からコンテンツが配信されることが決定される。したがって、自配信サーバにおける配信負荷が過負荷状態となる前に、他配信サーバからコンテンツの配信を行うことができるので、コンテンツをユーザ端末に安定して配信することが可能となる。
【００１０】
しかも、負荷状態監視手段または第１ステップにおいては、自配信サーバに対するアクセスログに基づき配信負荷を予測するので、将来の配信負荷を適切に予測することができる。
【００１１】
よって、配信サーバ判断手段または第２ステップにおいては、他配信サーバからコンテンツ配信を行うか否かを適切に決定できるので、より効率的にコンテンツをユーザ端末に配信することができる。
【００１２】
さらに、上記負荷状態監視手段は、上記監視対象の配信サーバからコンテンツを配信することを許可できるコンテンツ配信要求が上記配信サーバに送信される周期、コンテンツ配信に用いられるチャネルの数、およびコンテンツをユーザ端末に転送するための時間に基づき設定されるしきい値を用いて、該配信サーバにおける配信負荷を予測することが好ましい。
【００１３】
つまり、ある配信サーバから同時にコンテンツを配信可能な端末数は、コンテンツを配信することを許可できるコンテンツ配信要求が送信される周期と、コンテンツ配信に用いられるチャネル数と、コンテンツを端末側に転送するのに必要な時間とから算出することができる。
【００１４】
したがって、上記構成によれば、上記３つのパラメータに基づきしきい値を設定して配信サーバの負荷を予測するので、適切な配信負荷の予測が可能となる。よって、さらに効率的にコンテンツをユーザ端末に配信することができる。
【００１５】
また、本発明の配信サーバは、上記構成の配信負荷分散装置を備えているものである。上記構成によれば、配信サーバに本発明の配信負荷分散装置が備えられているので、効率的にユーザ端末にコンテンツを配信することが可能となる。
【００１６】
さらに、本発明の配信サーバは、他の配信サーバにおけるコンテンツ配信負荷を監視する他サーバ負荷状態監視手段を備えていることが好ましい。
【００１７】
上記構成によれば、他サーバ負荷状態監視手段により他の配信サーバにおけるコンテンツ配信負荷が監視される。したがって、配信サーバ判断手段により他配信サーバを用いてコンテンツを配信することを決定する際において、他配信サーバにおける配信負荷も考慮してその配信サーバでコンテンツを配信するかを決定することができる。
【００１８】
つまり、他サーバ負荷状態監視手段により他配信サーバにおいて配信負荷が高いと判断される場合には、その配信サーバからコンテンツ配信を行わず、さらに他の配信サーバを用いてコンテンツが配信されるようにすることができる。よって、より効率的にユーザ端末にコンテンツを配信することができる。
【００１９】
さらに、本発明の配信サーバは、複数のユーザ端末のそれぞれに割り当てられた帯域を用いて、各ユーザ端末へコンテンツ配信を行うことが好ましい。
【００２０】
上記構成によれば、各ユーザ端末に対してコンテンツ配信に用いられる帯域が個別に割り当てられているので、各ユーザ端末に固定された帯域でコンテンツを配信することができる。よって、より安定した通信状態でコンテンツをユーザ端末に配信することができる。
【００２１】
さらに、本発明のコンテンツ配信システムは、本発明の配信負荷分散装置と、該配信負荷分散装置の負荷状態監視手段により配信負荷が予測される配信サーバを少なくとも１つ含む複数の配信サーバと、該複数の配信サーバのいずれかからコンテンツが配信される複数のユーザ端末とを備えているものである。
【００２２】
また、本発明のコンテンツ配信システムは、本発明の配信サーバを含む複数の配信サーバと、該複数の配信サーバのいずれかからコンテンツが配信される複数のユーザ端末とを備えている構成であってもよい。
【００２３】
上記構成によれば、本発明の配信負荷分散装置または配信サーバがコンテンツ配信システムに備えられているので、複数のユーザ端末に効率的にコンテンツを配信できる。
【００２４】
さらに、本発明のコンテンツ配信システムは、上記配信サーバによるコンテンツ配信を補助する副配信サーバを備えていることが好ましい。
【００２５】
上記構成によれば、副配信サーバにより配信サーバによるコンテンツ配信が補助されるので、配信サーバにおける配信負荷が軽減され、その配信サーバからコンテンツをさらに効率的に配信することができる。
【００２６】
さらに、本発明のコンテンツ配信システムは、上記コンテンツ配信システムにおける複数のユーザ端末からのコンテンツ配信要求を受け付ける受付装置を備えていることが好ましい。
【００２７】
上記構成によれば、受付装置によりユーザ端末からのコンテンツ配信要求を集中管理することができ、複数の配信サーバに対して行われるコンテンツ配信要求を、この受付装置に行われるものとすることができる。
【００２８】
よって、特定の配信サーバにコンテンツ配信要求が集中して、その配信サーバにおける負荷が高くなってしまうことを防止し、より効率的にコンテンツをユーザ端末に配信することができる。
【００２９】
なお、コンピュータに上記配信負荷分散方法を実行させる配信負荷分散プログラムにより、コンピュータを用いて本発明の配信負荷分散方法と同様の作用効果を得ることができる。さらに、上記配信負荷分散プログラムをコンピュータ読み取り可能な記録媒体に記憶させることにより、任意のコンピュータ上で上記配信負荷分散プログラムを実行させることができる。
【発明の効果】
【００３０】
本発明によれば、自配信サーバにおける配信負荷が過負荷状態となる前に、他配信サーバからコンテンツの配信を行うことができるので、コンテンツをユーザ端末に安定して配信することが可能となる。
【００３１】
しかも、負荷状態監視手段においては、自配信サーバに対するアクセスログに基づき配信負荷を予測するので、将来の配信負荷を適切に予測することができる。よって、配信サーバ判断手段においては、他配信サーバからコンテンツ配信を行うか否かを適切に決定できるので、より効率的にコンテンツをユーザ端末に配信することができる。
【発明を実施するための最良の形態】
【００３２】
〔１．コンテンツ配信システムの基本構成〕
本発明の一実施形態に係る配信サーバを用いるコンテンツ配信システム（以下、単に本コンテンツ配信システムという）の基本的な構成について説明する。先ず、図２を用いて本コンテンツ配信システムの概要について説明する。
【００３３】
図２に示すように、本コンテンツ配信システムは、コンテンツサーバ１と、複数の配信サーバ２…と、複数のユーザ端末３…とから構成される。
【００３４】
コンテンツサーバ１は、配信の対象となるコンテンツを格納するとともに配信サーバ２…へ送信するものであり、そのコンテンツとしては、動画像データ、音楽データ、静止画像データ、またはアプリケーション実行用データ等、ネットワークを介して送信可能なものであればよい。なお、ネットワークとしては、衛星通信網、インターネット、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、ＦＴＴＨ（Fiber To The Home）、ＣＡＴＶ（Community Antenna TeleVision）、ＸＤＳＬ（Digital Subscriber Line）、ＩＳＤＮ（Integrated Services Digital Network）、公衆電話回線網等、種々の無線・有線通信回線を含むものとする。
【００３５】
配信サーバ２は、コンテンツサーバ１から送信されるコンテンツを中継して、コンテンツサーバ１−配信サーバ２間と同様のネットワーク経由でユーザ端末３…へ送信するためのものである。図２では、複数の配信サーバ２…のうち、ユーザ端末３…へのコンテンツ送信を代表的に担当する配信サーバを「メイン配信サーバ」と記載している。そして、そのメイン配信サーバが行うコンテンツ送信を補助する配信サーバについて、「補助配信サーバ」の枠組みで囲っている。
【００３６】
この「メイン配信サーバ」と「補助配信サーバ」とは、以下に説明する関係にある。つまり、本コンテンツ配信システムでは、メイン配信サーバに対するユーザ端末３…からのコンテンツ配信要求が集中し、同サーバへの負荷が上昇すると予測される場合において、他の補助配信サーバを利用してコンテンツをユーザ端末３へ送信する。そして、本コンテンツ配信システムの特徴点の１つとして、メイン配信サーバにおける負荷を予測するという点を挙げることができる。この特徴点の詳細については後述する。
【００３７】
また、複数の配信サーバ２…および複数のユーザ端末３…から、任意に１つずつ抽出された配信サーバ２およびユーザ端末３と、コンテンツサーバ１との関係について、図３を用いて説明する。
【００３８】
図３に示すように、コンテンツサーバ１は、コンテンツサーバ本体１ａと、コンテンツ蓄積部１ｂとからなる。また、配信サーバ２は、配信サーバ本体２ａと、コンテンツ蓄積部２ｂとからなる。これらの本コンテンツ配信システムを構成する各ブロックがどのように情報のやりとりを行うかについて、図４のタイムシーケンスを用いて説明する。
【００３９】
図４に示すように、先ずユーザ端末３から配信サーバ２の配信サーバ本体２ａにコンテンツの配信要求が送信される（ステップ１、以下単にステップはＳと記載する）。配信サーバ２において他のユーザ端末３からの配信要求が集中しており、コンテンツをユーザ端末３へ送信できない状況にあるならば、配信サーバ本体２ａは、コンテンツ配信を許可できない旨のメッセージをユーザ端末３に送信する（Ｓ２）。
【００４０】
このＳ１およびＳ２の処理は、配信サーバ２において負荷が低くなり、ユーザ端末３へのコンテンツ配信が許可されるまで繰り返される。そして、Ｓ１およびＳ２の処理が繰り返されている間、配信サーバ本体２ａでは、コンテンツを配信できなかったユーザに関する情報、すなわちＳ２で不許可メッセージを送信したユーザ端末３のユーザに関する情報を蓄積する（Ｓ３）。
【００４１】
その後、配信サーバ２からコンテンツ配信を了解する旨のメッセージがユーザ端末３へ送信される（Ｓ４）。この了解メッセージを受信すると、ユーザ端末３から配信サーバ本体２ａにコンテンツの取得を要求するメッセージ（コンテンツ取得要求）が送信される（Ｓ５）。
【００４２】
配信サーバ本体２ａは、ユーザ端末３からのコンテンツ取得要求を受信すると、コンテンツサーバ本体１ａに対してコンテンツ取得要求を送信する（Ｓ６）。コンテンツサーバ本体１ａは、配信サーバ本体２ａからのコンテンツ取得要求を受信すると、コンテンツ蓄積部１ｂ内から要求されたコンテンツを検索し、抽出する（Ｓ７）。そして、コンテンツサーバ本体１ａは、Ｓ７で抽出したコンテンツを配信サーバ本体２ａに送信する（Ｓ８）。
【００４３】
配信サーバ本体２ａは、コンテンツサーバ本体１ａから送信されたコンテンツを、一旦コンテンツ蓄積部２ｂに蓄積した後に、ユーザ端末３へ送信する（Ｓ９）。
【００４４】
以上のＳ１〜Ｓ９を踏むことにより、コンテンツサーバ１からユーザ端末３へ最終的にコンテンツが配信される。
【００４５】
〔２．配信サーバ本体の構成および処理フロー〕
次に、配信サーバ本体２ａの構成の詳細について説明する。図１に示すように、配信サーバ本体２ａは、ユーザコンテンツ利用受付部４と、配信用制御情報送受信部５と、ユーザ情報蓄積部６と、コンテンツ検索／取得部７と、コンテンツ情報出力部８と、コンテンツ関連情報提示部９と、コンテンツ配信部１０と、自サーバ負荷状態監視部（負荷状態監視手段）１１と、配信サーバ判断部（配信サーバ判断手段）１２と、他サーバ負荷状態監視部（他サーバ負荷状態監視手段）１３とを備えている。
【００４６】
配信サーバ本体２ａは、上記の各ブロックを備えていることにより、自身に対するユーザ端末からのアクセス負荷を監視し、その負荷に応じて、自身からコンテンツを配信するか、または他のサーバからコンテンツを配信するかを判断することが可能とされている。以下、配信サーバ本体２ａにおける処理の手順および各ブロックの機能について、図５のフローチャートを用いて説明する。
【００４７】
先ず、図５に示すように、コンテンツ利用のためのユーザアクセスが、ユーザコンテンツ利用受付部４により行われる（Ｓ１１）。さらに、Ｓ１１では、ユーザの認証処理もユーザコンテンツ利用受付部４により行われる。このＳ１１におけるユーザの認証処理は、図１に示すように、上記アクセスを行ったユーザのＩＤが、ユーザ情報蓄積部６に登録された正規のものであるかを確認することにより行われる。なお、ユーザ情報蓄積部６には、ユーザに配信されたコンテンツのインデックスを示すコンテンツＩＤ、およびユーザが過去に配信サーバにアクセスしたログを示すユーザアクセス情報が蓄積されている。
【００４８】
その後、図１に示すように、コンテンツ検索／取得部７により、ユーザが利用可能なコンテンツが、コンテンツサーバ１のコンテンツ蓄積部１ｂ（図３参照）から検索され、配信サーバ２側に取得される。なお、コンテンツ検索／取得部７により取得されたコンテンツは、配信サーバ２のコンテンツ蓄積部２ｂ（図３参照）に蓄積される。
【００４９】
さらに、コンテンツ情報出力部８は、コンテンツ検索／取得部７により取得されたコンテンツに関して、コンテンツのタイトル、再生時間、作成時間、配信元等を示すコンテンツ関連情報を抽出し、コンテンツ関連情報提示部９に出力する。このコンテンツ関連情報を受け、コンテンツ関連情報提示部９は、配信用制御情報送受信部５を介してユーザ端末にコンテンツ情報の提示を行う。このコンテンツ情報の提示処理が、図５のフローにおけるＳ１２の処理に相当する。
【００５０】
Ｓ１２の処理の後、図５に示すように、コンテンツの配信要求があったか否かが、配信用制御情報送受信部５により判断される（Ｓ１３）。このＳ１３の処理は、たとえば、ユーザ端末３の画面に表示されたコンテンツ配信ボタンを、ユーザがクリックしたか否かを配信用制御情報送受信部５にて判断することにより行われる。Ｓ１３においてコンテンツの配信要求がなかったと判断される場合、再度Ｓ１２の処理に戻りコンテンツ情報の提示が行われる。
【００５１】
また、Ｓ１３においてコンテンツの配信要求があったと判断された場合、配信用制御情報送受信部５は、コンテンツ配信要求に応じるか否かを判断する（Ｓ１４）。Ｓ１４における判断は、現在のコンテンツ利用者数が所定しきい値を超えているか否かを判断することにより行われる。この所定しきい値としては、コンテンツの安定配信が可能な配信要求数の上限値ｐ１（詳細は後述する）を用いることが可能である。
【００５２】
Ｓ１４においてコンテンツの配信要求に応じると判断された場合、配信用制御情報送受信部５は、ユーザ端末３に対してコンテンツを配信することを許可する旨の通知を送信する（Ｓ１５）。一方、Ｓ１４においてコンテンツの配信要求に応じないと判断された場合、ユーザ端末３に対してコンテンツを配信できない旨の通知が配信用制御情報送受信部５により行われる（Ｓ１６）。
【００５３】
Ｓ１５またはＳ１６の後、自サーバ負荷状態監視部１１により行われるコンテンツ配信要求状況の監視ステップに移行する（Ｓ１７）。すなわち、Ｓ１７においては、自サーバ負荷状態監視部１１により、自身が設けられている配信サーバ（以下、自配信サーバとする）に対するコンテンツ配信要求の数、およびコンテンツ配信要求を拒否したユーザ端末の数が記録される。さらに、Ｓ１７の後、Ｓ１８においてユーザに対するコンテンツの配信要求状況が、ユーザアクセス情報としてユーザ情報蓄積部６に蓄積される（Ｓ１８）。
【００５４】
そして、自サーバ負荷状態監視部１１により、自配信サーバの負荷状態が算出、すなわち現在の時刻における自配信サーバに対するコンテンツ配信要求の数が把握されるとともに、将来におけるコンテンツ配信要求が予測される（Ｓ１９）。なお、自サーバ負荷状態監視部１１による負荷状態の算出手順については後述する。
【００５５】
また、説明の便宜上、Ｓ１７〜Ｓ１９の処理は、Ｓ１５またはＳ１６の処理の後に実行されるように記載したが、必ずしもその必要はない。すなわち、Ｓ１７〜Ｓ１９の処理は、Ｓ１５およびＳ１６の処理とは無関係に常時実行されているものであっても構わない。また、Ｓ１７〜Ｓ１９の処理は、必ずしもこの順番で実行される必要もない。
【００５６】
また、図５に示すように、上記Ｓ１１〜Ｓ１９の処理と並行して、以下に説明するＳ２０〜Ｓ２２の処理が実行される。すなわち、Ｓ２０においては、他サーバ負荷状態監視部１３により、自身が設けられている配信サーバ以外のサーバ（以下、他配信サーバとする）の負荷状況が監視される。さらに、Ｓ２１においては、他配信サーバの負荷状況が他サーバ負荷状態監視部１３に蓄積され、その後Ｓ２２において、他配信サーバの負荷状態が算出される。
【００５７】
これらＳ２０〜Ｓ２２において行われる他配信サーバの負荷状況の監視手順は、自配信サーバに対する負荷状況の監視手順と同様の手順により実行されることが好ましいが、必ずしもその必要はない。たとえば、単純に他配信サーバに対するコンテンツの配信要求の有無だけを判断して他配信サーバの負荷状況を監視してもよい。さらに、Ｓ２０〜Ｓ２２にて行われる負荷状況の監視手順は、省略されてもよい。
【００５８】
Ｓ１９およびＳ２２にて自配信サーバおよび他配信サーバの負荷状態が算出された後、配信サーバ判断部１２にて、自配信サーバを用いてコンテンツを配信するか否かの判断が行われる（Ｓ２３）。Ｓ２３における判断手順の詳細については後述する。なお、Ｓ２２が省略される場合は、Ｓ１９において自配信サーバの負荷状態が算出されたら、Ｓ２３の処理を実行すればよい。
【００５９】
Ｓ２３にて自配信サーバを用いてコンテンツを配信すると判断された場合、ユーザ端末３に対して自配信サーバが配信可能である旨が、配信用制御情報送受信部５により提示される（Ｓ２４）。
【００６０】
Ｓ２４の後、配信用制御情報送受信部５は、ユーザからコンテンツの配信要求があったか否かを判断する（Ｓ２５）。このＳ２５の処理は、たとえば、ユーザ端末３の画面に表示された自配信サーバからコンテンツが配信される旨のメッセージに対して、ユーザがＯＫボタンを押す等の動作により、自配信サーバからコンテンツが配信されることにユーザが同意したか否かを判断することにより行われる。
【００６１】
そして、Ｓ２５にてユーザからコンテンツ配信要求があったと判断された場合、コンテンツ配信部１０は、ユーザ端末３に対してコンテンツを配信する（Ｓ２６）。
【００６２】
一方、Ｓ２３にて自配信サーバではなく他配信サーバを用いてコンテンツを配信すると判断された場合、他配信サーバは、自身をコンテンツ配信が可能なサーバとしてユーザ端末３に提示する（Ｓ２７）。その後、他配信サーバは、ユーザ端末３からコンテンツ配信要求があったか否かを判断し（Ｓ２８）、その要求があったと判断される場合には、他配信サーバはユーザ端末３に対してコンテンツを配信する（Ｓ２９）。
【００６３】
Ｓ２６またはＳ２９のコンテンツ配信処理が終了した後、あるいはＳ２５またはＳ２８にてコンテンツ配信要求が無かったと判断された場合には、コンテンツ利用を終了するか否かの判断が配信用制御情報送受信部５により行われる（Ｓ３０）。Ｓ３０における判断は、たとえば配信用制御情報送受信部５を用いてユーザ端末３に対して「コンテンツ利用を終了しますか？」等のメッセージを表示し、その表示に対してユーザがＯＫボタンを押す等の動作により同意したか否かを判断することにより実現される。
【００６４】
上述のＳ１１〜Ｓ３０を踏むことにより、配信サーバ２からユーザ端末３にコンテンツが配信されるまでの一連の手順が終了する。
【００６５】
〔３．負荷状態の監視、配信サーバの判断に関して〕
次に、図５のＳ１９にて実行される自サーバ負荷状態監視部１１による負荷状態算出手順、およびＳ２３にて実行される配信サーバ判断部１２による判断手順の詳細に関して説明する。
【００６６】
先ず、本発明者らは、配信サーバに対するユーザ端末からのコンテンツ配信要求数と、配信要求をしてからコンテンツの配信が開始されるまでの待ち時間（配信開始待ち時間）との関係について検討した。その結果、図６の（ａ）部分のグラフに示す関係を得ることができた。
【００６７】
図６の（ａ）部分に示すように、配信開始待ち時間は、配信要求数がある値ｐ１となるまでは、配信要求数が増加するとなだらかな傾斜を描くように増加する。その一方、配信要求数がｐ１を超えると、配信開始待ち時間は、配信要求数の増加に対応して急峻な傾斜を描いて増加すると本発明者らは考えた。
【００６８】
つまり、配信サーバに対するコンテンツの配信要求数がｐ１となるまでは、図６の（ｂ）部分に示すように、配信要求を行っているユーザ端末の数が比較的少なく、ユーザ端末（１）およびユーザ端末（ｎ）のそれぞれに対してコンテンツを配信することが可能であり、ユーザ端末（ｎ＋１）に対するコンテンツ配信だけができていない「安定配信」状態にあるといえる。
【００６９】
一方、配信サーバに対するコンテンツの配信要求がｐ１を超えている場合、図６の（ｃ）部分に示すように、コンテンツの配信要求を行っているユーザ端末が非常に多く、ユーザ端末（１）に対するコンテンツ配信のみが行われ、ユーザ端末（ｍ）・（ｍ＋１）・（ｍ＋２）に対してはコンテンツ配信をできていない「過負荷」状態にあるといえる。
【００７０】
このように得られた配信待ち時間と配信要求数との関係から、図５のＳ１９に係る負荷状態の算出ステップにて、自サーバ負荷状態監視部１１は、現在時刻における配信要求数がｐ１を超えているか、または配信要求数がｐ１を超えると予測されるかを判断する。
【００７１】
そして、現在時刻における配信要求数がｐ１を超えていない場合、またはｐ１を超えることも想定されない場合においては、図５のＳ２３にて配信サーバ判断部１２は自配信サーバを用いてコンテンツの配信をすることを決定する。また、現在時刻における配信要求数がｐ１を超えている場合、または現在時刻からある程度時間が経ったら配信要求数がｐ１を超えると予測される場合においては、配信サーバ判断部１２は、自配信サーバを用いずに他配信サーバからコンテンツを配信することを決定する。
【００７２】
なお、配信要求数がｐ１を超えるか否かに関する予測は、自サーバ負荷状態監視部１１がユーザ情報蓄積部６（図１参照）に蓄積されたコンテンツの配信要求状況を参照することにより実現可能である。つまり、ユーザ情報蓄積部６においては、ユーザが過去に配信サーバにアクセスしたログを示すユーザアクセス情報が蓄積されている。このユーザアクセス情報には、過去におけるユーザの配信要求数とその要求を拒否した数とが記録されているので、自サーバ負荷状態監視部１１が当該情報を参照し、現在の配信要求数と拒否数とを過去のものと比較することにより、配信要求数がこれから減少するのか増加するのかを判断することできる。
【００７３】
ここで、自配信サーバで配信を行うか否かを決定するためのしきい値となる上記ｐ１の値をどのように決定するかについて説明する。ｐ１の値は、基本的に、コンテンツをユーザ端末に転送するために必要な時間、コンテンツを利用するための時間、および次のコンテンツを利用できるまでの待ち時間の関係から算出される。さらに、ｐ１の値を配信サーバに対する一定時間内のアクセスの数から算出することもできる。
【００７４】
また、以下に説明するｐ１の算出手順においては、一定の時間間隔を空けないと次のコンテンツ利用ができないことを基本的な考え方とし、ｐ１を算出するためのパラメータとしてコンテンツの利用待ち時間を設定している。一方で、従来では、このような利用待ち時間まで考慮したしきい値が設定されておらず、ユーザが一定時間待てばコンテンツを配信してもらえるような状況であっても、配信サーバが過負荷状態であると判断されていた。
【００７５】
しかしながら、本実施形態によれば、利用待ち時間を考慮してｐ１を設定するので、そのような状況においても、配信サーバが過負荷状態でないと判断する。
【００７６】
自配信サーバで配信を行うか否かを決定するためのしきい値となる上記ｐ１の値の決定手順の一例について、図７を用いて説明する。図７は、１つのチャネルにおける、コンテンツの配信に関する時間と帯域幅との関係を示す図である。
【００７７】
図７に示すように、ユーザがユーザ端末３を介して配信サーバ２にアクセスしてから、実際にコンテンツが配信されるまでの時間は、アクセス時間Ｔ０、配信時間Ｔ１、蓄積時間Ｔ２、ブラウズ時間Ｔ３、および待ち時間Ｔ４に分類することができる。それぞれの時間に関する説明は以下のとおりである。
【００７８】
アクセス時間Ｔ０：ユーザがコンテンツの配信要求を行うために配信サーバ２にアクセスしてから、そのアクセスに配信サーバ２が応答するまでの時間
配信時間Ｔ１：コンテンツをユーザ端末３に転送するために必要な時間
蓄積時間Ｔ２：ユーザ端末３側に転送されたコンテンツをユーザ端末３にて蓄積するための時間
ブラウズ時間Ｔ３：転送されたコンテンツをユーザ端末３でブラウズするための時間
待ち時間Ｔ４：既に配信されたコンテンツをブラウズしてから、コンテンツ配信を許可できる次回の配信要求が行われるまでの待ち時間。
【００７９】
そして、Ｔ１＋Ｔ２＋Ｔ３＋Ｔ４＝Ｔｓｕｍとおくと、Ｔｓｕｍにて示される時間が、１つのコンテンツが１つのユーザ端末に配信される周期（１コンテンツ利用時間）であるといえる。よって、１つのチャネルにて同時にコンテンツ配信が可能なユーザの数は、Ｔｓｕｍ／Ｔ１にて示される。
【００８０】
したがって、配信サーバ２とユーザ端末３との間において用いられているチャネルの数をｋとすると、ｋ個のチャネルにて同時にコンテンツ配信が可能なユーザの数は、ｋ×Ｔｓｕｍ／Ｔ１にて示される。よって、ｐ１＝ｋ×（Ｔｓｕｍ／Ｔ１＋α）にて設定することにより、ｐ１を自配信サーバで配信を行うか否かを決定するためのしきい値として機能させることができる。なお、αは任意の整数である。
【００８１】
また、このようにして配信時間Ｔ１を用いてｐ１を算出する手順以外に、配信サーバに対するユーザ端末からの一定時間内のアクセス数を用いてｐ１を算出することも可能である。つまり、Ｔｓｕｍにて示される１コンテンツ利用時間内に、どのくらいの数のアクセスがユーザ端末からあったかを、ユーザ情報蓄積部６（図１参照）に蓄積するアクセス情報として管理しておく。なお、このように管理されるアクセス数は、同一ユーザからのアクセスの数であっても、異なるユーザからのアクセスの数であっても構わない。
【００８２】
そして、配信サーバの負荷状態が安定配信状態から過負荷状態に移行する際の配信要求数（アクセス数）を、蓄積済みのアクセス情報から把握し、その配信要求数をｐ２とする。そして、ｐ１＝ｋ×（ｐ２＋α）として、ｐ２からｐ１を算出してもよい。なお、ｋはチャネルの数であり、αは任意の整数である。
【００８３】
〔４．帯域保証伝送について〕
上記構成における配信サーバ２−ユーザ端末３間のコンテンツ配信、およびコンテンツサーバ１−配信サーバ２間のコンテンツ配信においては、データ伝送をより安定して行うため、伝送帯域を保証してデータ伝送を行うことが好ましい。この帯域保証伝送について、以下に説明する。
【００８４】
図８に示すように、コンテンツサーバ１と配信サーバ２との間において帯域ＢＷ１によるコンテンツの配信が行われ、配信サーバ２とユーザ端末３…との間で帯域ＢＷ２によるコンテンツの配信が行われているとする。
【００８５】
そして、同時アクセスの数をｘとする場合、帯域ＢＷ１をｘ個のチャネル１〜ｘに分けるとともに、各チャネルについて帯域ＢＷ１／ｘを割り当てる。帯域ＢＷ２についても同様にして、ｘ個のチャネル１〜ｘに分けるとともに、各チャネルについて帯域ＢＷ２／ｘを割り当てる。
【００８６】
さらに、各ユーザ端末３について１つのチャネルを割り当てることにより、各ユーザ端末３に割り当てられる伝送帯域を固定することができる。これにより、コンテンツを各ユーザ端末３に安定して配信することができる。
【００８７】
もちろん、コンテンツサーバ１−配信サーバ２間においても帯域ＢＷ１がｘ個のチャネル１〜ｘに割り当てられているので、コンテンツサーバ１から複数の配信サーバ２へコンテンツを配信する場合において、各配信サーバ２へ安定してコンテンツを配信することができる。
【００８８】
また、各ユーザ端末３から配信サーバ２へ各種情報（コンテンツの配信要求等）を送信するための帯域ＢＷ３、および配信サーバ２からコンテンツサーバ１へ各種情報（コンテンツの取得要求等）を送信するための帯域ＢＷ４についても、帯域ＢＷ１・ＢＷ２と同様にｘ個のチャネルに分けることにより、安定した情報通信を実現できる。
【００８９】
〔５．変形例〕
以下に、上記した構成のコンテンツ配信システム以外に、本発明を適用可能なコンテンツ配信システムの構成をいくつか説明する。
【００９０】
（５−１．コンテンツサーバを設けない構成および副配信サーバを設ける構成）
本発明を適用可能なコンテンツ配信システムでは、コンテンツサーバを設けないことも可能である。つまり、図９（ａ）に示すように、配信サーバのコンテンツ蓄積部２ｂにユーザ端末３に配信すべきコンテンツを予め蓄積しておくことにより、コンテンツサーバのコンテンツ蓄積部と同様の機能を配信サーバのコンテンツ蓄積部２ｂに担保させることもできる。
【００９１】
なお、図９（ａ）においては、説明の便宜上、配信サーバ本体２ａおよびコンテンツ蓄積部２ｂを１セットしか記載していないが、実際は複数の配信サーバがネットワーク上に接続されており、これらの図示されていない複数の配信サーバと、図示されている配信サーバ本体２ａとの間で、上記したコンテンツ配信システムと同様にコンテンツの配信が分散されている。これは、以下に説明する図９（ｂ）・図９（ｃ）・図１０（ａ）〜図１０（ｄ）・図１１（ａ）〜図１１（ｄ）・図１２（ａ）〜図１２（ｄ）の構成でも同様である。
【００９２】
さらに、図９（ｂ）に示すように、副配信サーバ１４を設けてもよい。この副配信サーバ１４は、配信サーバ本体２ａに対するコンテンツの配信要求が増加して配信サーバ本体２ａが過負荷状態となったときに、その配信サーバ本体２ａのコンテンツ配信を補助するために設けられるものである。つまり、図９（ｂ）に示すコンテンツ配信システムでは、配信サーバ本体２ａと副配信サーバ１４との間において、コンテンツ配信が分散されているといえる。
【００９３】
なお、図９（ｂ）では、配信サーバ本体２ａと副配信サーバ１４とが１対１の関係で設けられるように記載しているが、必ずしもこの構成に限定されるものではない。配信サーバ本体２ａと副配信サーバ１４とを１対多の関係で設けてもよいし、多対１の関係で設けてもよい。これは、以下に説明するコンテンツ配信システムのうち、副配信サーバ１４が設けられたもの全てについても同様である。
【００９４】
また、図９（ｃ）に示すように、コンテンツサーバ本体１ａおよびコンテンツ蓄積部１ｂを省略する代わりに、図９（ａ）の構成と同様にコンテンツ蓄積部２ｂに配信すべきコンテンツを予め蓄積する一方、副配信サーバ１４を設けてもよい。
【００９５】
（５−２．受付装置を配信サーバと独立して設ける構成）
さらに、本発明を適用可能なコンテンツ配信システムでは、図１０（ａ）に示すように、受付装置１５を配信サーバ２と独立して設けることも可能である。この受付装置１５は、配信サーバ本体２ａにおけるユーザコンテンツ利用受付部４および／または配信用制御情報送受信部５（図１参照）と同様の機能、すなわち複数端末からのユーザアクセスやコンテンツの配信要求を受け付ける機能をもつものである。
【００９６】
図１０（ａ）に示すように受付装置１５をコンテンツ配信システムに設けた場合には、配信サーバ２から、ユーザコンテンツ利用受付部４および配信用制御情報送受信部５の少なくとも一方を省略することができる。また、説明の便宜上、図１０（ａ）では、配信サーバ２と受付装置１５とが１対１の関係で設けられるように記載しているが、必ずしもこの構成に限定されるものではない。配信サーバ２と受付装置１５とを１対多の関係で設けてもよいし、多対１の関係で設けてもよい。これは、以下に説明するコンテンツ配信システムのうち、受付装置１５が設けられたもの全てについても同様である。
【００９７】
また、受付装置１５が設けられているコンテンツ配信システムにおいては、図１０（ｂ）に示すように、コンテンツサーバ本体１ａおよびコンテンツ蓄積部１ｂを省略する代わりに、図９（ａ）の構成と同様にコンテンツ蓄積部２ｂに配信すべきコンテンツを予め蓄積してもよい。
【００９８】
さらに、図１０（ｃ）に示すように、本発明を適用可能なコンテンツ配信システムでは、受付装置１５と副配信サーバ１４とを同時に備えていてもよい。もちろん、図１０（ｄ）に示すように、受付装置１５と副配信サーバ１４とを同時に備えているコンテンツ配信システムにおいて、コンテンツサーバ本体１ａおよびコンテンツ蓄積部１ｂを省略し、コンテンツ蓄積部２ｂに配信すべきコンテンツを予め蓄積しておいてもよい。
【００９９】
（５−３．監視装置を配信サーバと独立して設ける構成）
さらに、本発明を適用可能なコンテンツ配信システムでは、図１１（ａ）に示すように、監視装置（配信負荷分散装置）１６を配信サーバ２と独立して設けることも可能である。この監視装置１６は、配信サーバ本体２ａにおける自サーバ負荷状態監視部１１、配信サーバ判断部１２、および他サーバ負荷状態監視部１３（図１参照）を配信サーバ本体２ａと独立させて構成させたもの、すなわち自サーバおよび他サーバの負荷状態を監視し、いずれのサーバからコンテンツを配信すべきかを決定する機能をもつものである。
【０１００】
図１１（ａ）に示すように監視装置１６をコンテンツ配信システムに設けた場合には、配信サーバ２から、自サーバ負荷状態監視部１１、配信サーバ判断部１２、および他サーバ負荷状態監視部１３を省略することができる。また、説明の便宜上、図１１（ａ）では、配信サーバ２と監視装置１６とが１対１の関係で設けられるように記載しているが、必ずしもこの構成に限定されるものではない。配信サーバ２と監視装置１６とを１対多の関係で設けてもよいし、多対１の関係で設けてもよい。これは、以下に説明するコンテンツ配信システムのうち、監視装置１６が設けられたもの全てについても同様である。
【０１０１】
また、監視装置１６が設けられているコンテンツ配信システムにおいては、図１１（ｂ）に示すように、コンテンツサーバ本体１ａおよびコンテンツ蓄積部１ｂを省略する代わりに、図９（ａ）の構成と同様にコンテンツ蓄積部２ｂに配信すべきコンテンツを予め蓄積してもよい。
【０１０２】
さらに、図１１（ｃ）に示すように、本発明を適用可能なコンテンツ配信システムでは、監視装置１６と副配信サーバ１４とを同時に備えていてもよい。もちろん、図１０（ｄ）に示すように、監視装置１６と副配信サーバ１４とを同時に備えているコンテンツ配信システムにおいて、コンテンツサーバ本体１ａおよびコンテンツ蓄積部１ｂを省略し、コンテンツ蓄積部２ｂに配信すべきコンテンツを予め蓄積しておいてもよい。
【０１０３】
（５−４．受付装置および監視装置を配信サーバと独立して設ける構成）
さらに、本発明を適用可能なコンテンツ配信システムでは、図１２（ａ）に示すように、受付装置１５と監視装置１６とを同時に設けることも可能である。
【０１０４】
また、受付装置１５および監視装置１６が設けられているコンテンツ配信システムにおいては、図１２（ｂ）に示すように、コンテンツサーバ本体１ａおよびコンテンツ蓄積部１ｂを省略する代わりに、図９（ａ）の構成と同様にコンテンツ蓄積部２ｂに配信すべきコンテンツを予め蓄積してもよい。
【０１０５】
さらに、図１２（ｃ）に示すように、本発明を適用可能なコンテンツ配信システムでは、受付装置１５、監視装置１６、および副配信サーバ１４を同時に備えていてもよい。もちろん、図１２（ｄ）に示すように、受付装置１５、監視装置１６、および副配信サーバ１４を同時に備えているコンテンツ配信システムにおいて、コンテンツサーバ本体１ａおよびコンテンツ蓄積部１ｂを省略し、コンテンツ蓄積部２ｂに配信すべきコンテンツを予め蓄積しておいてもよい。
【０１０６】
（５−５．その他の構成例）
なお、特に図示はしていないが、上述した副配信サーバ１４、受付装置１５、または監視装置１６を独立して設ける構成と同様に、配信サーバ本体２ａの配信サーバ判断部１２を、配信サーバ判断装置として独立してネットワーク上に設けることも可能である。
【０１０７】
もちろん、副配信サーバ１４、受付装置１５、および監視装置１６のうち、ネットワーク上に独立に設ける装置を任意に設定し、その装置を配信サーバ判断装置と一緒にネットワーク上に設けてもよい。
【０１０８】
〔６．補足〕
本実施形態の配信サーバ２の処理手順は、ＣＰＵなどの演算手段が、ＲＯＭ（Read Only Memory）やＲＡＭなどの記憶手段に記憶されたプログラムを実行し、キーボードなどの入力手段、ディスプレイなどの出力手段、あるいは、インターフェース回路などの通信手段を制御することにより実現することができる。
【０１０９】
したがって、これらの手段を有するコンピュータが、上記プログラムを記録した記録媒体を読み取り、当該プログラムを実行するだけで、本実施形態の配信サーバの各種処理を実現することができる。また、上記プログラムをリムーバブルな記録媒体に記録することにより、任意のコンピュータ上で上記の各種機能および各種処理を実現することができる。
【０１１０】
この記録媒体としては、マイクロコンピュータで処理を行うために図示しないメモリ、例えばＲＯＭのようなものがプログラムメディアであっても良いし、また、図示していないが外部記憶装置としてプログラム読み取り装置が設けられ、そこに記録媒体を挿入することにより読み取り可能なプログラムメディアであっても良い。
【０１１１】
また、何れの場合でも、格納されているプログラムは、マイクロプロセッサがアクセスして実行される構成であることが好ましい。さらに、プログラムを読み出し、読み出されたプログラムは、マイクロコンピュータのプログラム記憶エリアにダウンロードされて、そのプログラムが実行される方式であることが好ましい。なお、このダウンロード用のプログラムは予め本体装置に格納されているものとする。
【０１１２】
また、上記プログラムメディアとしては、本体と分離可能に構成される記録媒体であり、磁気テープやカセットテープ等のテープ系、フレキシブルディスクやハードディスク等の磁気ディスクやＣＤ／ＭＯ／ＭＤ／ＤＶＤ等のディスクのディスク系、ＩＣカード（メモリカードを含む）等のカード系、あるいはマスクＲＯＭ、ＥＰＲＯＭ（Erasable Programmable Read Only Memory）、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）、フラッシュＲＯＭ等による半導体メモリを含めた固定的にプログラムを担持する記録媒体等がある。
【０１１３】
また、インターネットを含む通信ネットワークを接続可能なシステム構成であれば、通信ネットワークからプログラムをダウンロードするように流動的にプログラムを担持する記録媒体であることが好ましい。
【０１１４】
さらに、このように通信ネットワークからプログラムをダウンロードする場合には、そのダウンロード用のプログラムは予め本体装置に格納しておくか、あるいは別な記録媒体からインストールされるものであることが好ましい。
【０１１５】
このように、本実施形態の監視装置１６は、配信サーバ２の配信負荷を分散するものであって、ユーザ端末３から監視対象の配信サーバ２へのアクセスのログに基づき、該配信サーバ２における配信負荷を予測する自サーバ負荷状態監視部１１と、自サーバ負荷状態監視部１１により配信サーバ２への配信負荷が高くなると予測される場合、配信サーバ２以外の配信サーバからコンテンツを配信することを決定する配信サーバ判断部１２とを備えているものである。
【０１１６】
上記構成によれば、自サーバ負荷状態監視部１１により監視対象の配信サーバ２（自配信サーバ）における配信負荷が高くなると予測される場合、配信サーバ判断部１２により他配信サーバからコンテンツが配信されることが決定される。したがって、自配信サーバにおける配信負荷が過負荷状態となる前に、他配信サーバからコンテンツの配信を行うことができるので、コンテンツをユーザ端末に安定して配信することが可能となる。
【０１１７】
しかも、自サーバ負荷状態監視部１１においては、自配信サーバに対するアクセスログに基づき配信負荷を予測するので、将来の配信負荷を適切に予測することができる。よって、配信サーバ判断部１２においては、他配信サーバからコンテンツ配信を行うか否かを適切に決定できるので、より効率的にコンテンツをユーザ端末に配信することができる。
【０１１８】
さらに、自サーバ負荷状態監視部１１は、監視対象の配信サーバからコンテンツを配信することを許可できるコンテンツ配信要求が上記配信サーバに送信される周期Ｔｓｕｍ、コンテンツ配信に用いられるチャネルの数ｋ、およびコンテンツをユーザ端末に転送するための時間Ｔ１に基づき設定されるしきい値ｐ１を用いて、該配信サーバにおける配信負荷を予測することが好ましい。
【０１１９】
つまり、ある配信サーバから同時にコンテンツを配信可能な端末数は、上記Ｔｓｕｍ、ｋ、およびＴ１から算出することができる。したがって、上記構成によれば、上記３つのパラメータに基づきしきい値を設定して配信サーバの負荷を予測するので、適切な配信負荷の予測が可能となる。よって、さらに効率的にコンテンツをユーザ端末に配信することができる。
【０１２０】
また、本実施形態の配信サーバ２は、上記構成の記載の配信負荷分散装置を備えているものである。上記構成によれば、配信サーバ２に自サーバ負荷状態監視部１１および配信サーバ判断部１２が備えられているので、効率的にユーザ端末にコンテンツを配信することが可能となる。
【０１２１】
さらに、配信サーバ２は、他の配信サーバにおけるコンテンツ配信負荷を監視する他サーバ負荷状態監視部１３を備えている。
【０１２２】
上記構成によれば、他サーバ負荷状態監視部１３により他の配信サーバにおけるコンテンツ配信負荷が監視される。したがって、配信サーバ判断部１２により他配信サーバを用いてコンテンツを配信することを決定する際において、他配信サーバにおける配信負荷も考慮してその配信サーバでコンテンツを配信するかを決定することができる。
【０１２３】
つまり、他サーバ負荷状態監視部１３により他配信サーバにおいて配信負荷が高いと判断される場合には、その配信サーバからコンテンツ配信を行わず、さらに他の配信サーバを用いてコンテンツが配信されるようにすることができる。よって、より効率的にユーザ端末にコンテンツを配信することができる。
【０１２４】
さらに、配信サーバ２は、複数のユーザ端末のそれぞれに割り当てられた帯域を用いて、各ユーザ端末へコンテンツ配信を行うことが好ましい。
【０１２５】
上記構成によれば、各ユーザ端末に対してコンテンツ配信に用いられる帯域が個別に割り当てられているので、各ユーザ端末に固定された帯域でコンテンツを配信することができる。よって、より安定した通信状態でコンテンツをユーザ端末に配信することができる。
【０１２６】
さらに、本実施形態のコンテンツ配信システムは、本実施形態の配信サーバ２を含む複数の配信サーバと、該複数の配信サーバのいずれかからコンテンツが配信される複数のユーザ端末とを備えている構成である。
【０１２７】
また、本実施形態のコンテンツ配信システムは、監視装置１６と、監視装置１６の自サーバ負荷状態監視部１１により配信負荷が予測される配信サーバ２を少なくとも１つ含む複数の配信サーバ２…と、該複数の配信サーバ２…のいずれかからコンテンツが配信される複数のユーザ端末３…とを備えているものである。
【０１２８】
上記構成によれば、本実施形態の配信サーバ２または監視装置１６がコンテンツ配信システムに備えられているので、複数のユーザ端末に効率的にコンテンツを配信できる。
【０１２９】
さらに、本実施形態のコンテンツ配信システムは、配信サーバ２によるコンテンツ配信を補助する副配信サーバ１４を備えていることが好ましい。
【０１３０】
上記構成によれば、副配信サーバ１４により配信サーバ２によるコンテンツ配信が補助されるので、配信サーバにおける配信負荷が軽減され、その配信サーバからコンテンツをさらに効率的に配信することができる。
【０１３１】
さらに、本実施形態のコンテンツ配信システムは、上記コンテンツ配信システムにおける複数のユーザ端末３…からのコンテンツ配信要求を受け付ける受付装置１５を備えていることが好ましい。
【０１３２】
上記構成によれば、受付装置１５によりユーザ端末３…からのコンテンツ配信要求を集中管理することができ、複数の配信サーバ２…に対して行われるコンテンツ配信要求を、この受付装置１５に行われるものとすることができる。
【０１３３】
よって、特定の配信サーバ２にコンテンツ配信要求が集中して、その配信サーバ２における負荷が高くなってしまうことを防止し、より効率的にコンテンツをユーザ端末に配信することができる。
【０１３４】
本発明は上述した実施形態に限定されるものではなく、請求項に示した範囲で変更された実施形態についても本発明の技術的範囲に含まれる。
【産業上の利用可能性】
【０１３５】
本発明によれば、動画像データ、音楽データ、静止画像データ、またはアプリケーション実行用データ等の大容量のコンテンツを効率的にユーザ端末へ配信することができるので、本発明は情報配信サービスに適している。
【図面の簡単な説明】
【０１３６】
【図１】本発明の一実施形態に係る配信サーバの構成を示すブロック図である。
【図２】本発明の一実施形態に係るコンテンツ配信システムの構成を示すブロック図である。
【図３】図２のコンテンツ配信システムに含まれるコンテンツサーバ、配信サーバ、およびユーザ端末の構成を示す図である。
【図４】図３のコンテンツサーバ、配信サーバ、およびユーザ端末間における情報のやりとりを示すタイムシーケンスである。
【図５】図１の配信サーバにおける処理の手順を示すフローチャートである。
【図６】（ａ）部分はコンテンツ配信要求の数と配信開始待ち時間との関係を示すグラフであり、（ｂ）部分は配信サーバにおいて安定したコンテンツ配信が行われている際の帯域制御を記録したグラフであり、（ｃ）部分は配信サーバが過負荷状態にある際の帯域制御を記録したグラフである。
【図７】１つのチャネルにおける、コンテンツの配信に関する時間と帯域幅との関係を示す図である。
【図８】配信サーバとユーザ端末との間において帯域保証伝送を行う場合の状態を説明する図である。
【図９】（ａ）〜（ｃ）は、本発明の一実施形態に係るコンテンツ配信システムの変形例を示す図である。
【図１０】（ａ）〜（ｄ）は、本発明の一実施形態に係るコンテンツ配信システムのさらに他の変形例を示す図である。
【図１１】（ａ）〜（ｄ）は、本発明の一実施形態に係るコンテンツ配信システムのさらに他の変形例を示す図である。
【図１２】（ａ）〜（ｄ）は、本発明の一実施形態に係るコンテンツ配信システムのさらに他の変形例を示す図である。
【符号の説明】
【０１３７】
２  配信サーバ
３  ユーザ端末
１１  自サーバ負荷状態監視部（負荷状態監視手段）
１２  配信サーバ判断部（配信サーバ判断手段）
１３  他サーバ負荷状態監視部（他サーバ負荷状態監視手段）
１４  副配信サーバ
１５  受付装置
１６  監視装置（配信負荷分散装置）
【図１】
2006065516.tif 000003
【図２】
2006065516.tif 000004
【図３】
2006065516.tif 000005
【図４】
2006065516.tif 000006
【図５】
2006065516.tif 000007
【図６】
2006065516.tif 000008
【図７】
2006065516.tif 000009
【図８】
2006065516.tif 000010
【図９】
2006065516.tif 000011
【図１０】
2006065516.tif 000012
【図１１】
2006065516.tif 000013
【図１２】
2006065516.tif 000014