(57)【特許請求の範囲】
【請求項１】
各タイムスロットにおいてＭ個のビデオを送信できるサーバからコンテンツを通信する方法であって、Ｍは２以上であり：
コンテンツの要求を受信する段階；
該コンテンツを配信するスケジュールを直ちに生成する段階；
前記スケジュールが、Ｍ個より多いビデオを伝送すべき何れかの前記タイムスロットを有するか否かを決定する段階；
前記スケジュールに、Ｍ個より多いビデオを伝送すべきタイムスロットが存在する場合、Ｍ個より多いビデオを伝送する必要がない第１のタイムスロットに前記コンテンツの一部の配信を遅延させるよう、前記スケジュールを修正する段階；
修正された前記スケジュールが前記要求の遅延パラメータを満たすか否かを決定する段階；及び
修正された前記スケジュールが前記遅延パラメータを満たす場合、修正された前記スケジュールに従って、前記コンテンツを送信する段階；
を有する方法。
【請求項２】
前記コンテンツの第１の部分が、他の要求によって伝送されたかを決定する段階であって、前記コンテンツの第１の部分が伝送されている場合、前記スケジュールは、前記コンテンツの残りの部分を有し、前記コンテンツの残りの部分は、前記第１のタイムスロットで伝送されるコンテンツの部分を含む、段階；
を更に有する請求項１記載の方法。
【請求項３】
前記要求は、クライアント装置から受信され、前記遅延パラメータは該クライアント装置のユーザにより設定された遅延限度を有する、
請求項２記載の方法。
【請求項４】
前記スケジュールは複数のタイムスロットを有し、該複数のタイムスロットは、前記コンテンツの一部の配信が配信のためにスケジューリングされる第２のタイムスロットを有し、前記コンテンツは複数のビデオのブロックを有し、前記一部は該複数のビデオのブロックの中の第１のブロックを有し、前記第１のタイムスロットは、前記第２のタイムスロットの後続に発生し、かつ前記修正された前記スケジュールが前記要求の遅延パラメータを満たすか否かを決定する段階は、
前記第２のタイムスロットから前記第１のタイムスロットまでの遅延により生じる送信の遅延が、前記遅延パラメータと関連付けられた遅延限度を超えているか否かを決定する段階；を有する、
請求項１記載の方法。
【請求項５】
コンテンツを配信する方法であって：
ビデオの要求を受信する段階；
該ビデオの初期部分を第１の遅延を以て、該ビデオの後続の部分を第２の遅延を以て、該ビデオを配信するスケジュールを生成する段階；
を有し、
該スケジュールを生成する段階は、
前記要求の受信から前記ビデオの初期部分の配信までの時間を最小化するよう、前記第１の遅延を選択する段階；及び
前記要求と関連付けられた遅延パラメータを満たし、前記後続の部分の配信の遅延を最大化させるよう、前記第２の遅延を選択する段階、
を有する、
方法。
【請求項６】
コンテンツを受信する方法であって：
コンテンツ・プロバイダーからのコンテンツを要求する段階；
該コンテンツ・プロバイダーへ配信遅延限度を提供する段階；
前記コンテンツの初期部分の配信を開始する第１の時間と前記コンテンツの後続の部分の配信を開始する第２の時間とを有するスケジュールに従い、前記コンテンツを受信する段階；
を有し、
前記第１の時間は、前記要求の受信から前記コンテンツの初期部分の配信の開始までの遅延を最小化し、前記第２の時間は、前記配信遅延限度を満たすとともに前記コンテンツの後続の部分の配信の開始の遅延を増大させる、
方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般にネットワーク通信に関し、より詳細にはネットワークを介したビデオ情報のようなコンテンツの通信に関する。
【背景技術】
【０００２】
サーバの帯域幅は、ビデオオンデマンド（ＶＯＤ）システムのようなユーザ要求に応答してコンテンツを通信する大規模システムにおいて主要な隘路として知られている。チャネルをクライアント毎に専用にすることは、サーバの帯域幅を瞬く間に使い切ってしまい、拡張性に欠ける。サーバの帯域幅を保つために、多くのユーザはマルチキャストを用いてチャネルを共有しうる。
【０００３】
マルチキャストには２種類がある。つまり、周期的なブロードキャストと非周期的なマルチキャストである。周期的なブロードキャスト環境では、サーバは、サービス要求を待たない。サーバはコンテンツを循環的にブロードキャストする。ビデオ・コンテンツの場合、循環的ブロードキャストは、真のＶＯＤを保証しない。循環的ブロードキャストは、特定の限度の範囲内で任意のクライアントが最悪のサービス待ち時間を経験するよう保つ。実際に、帯域幅の要件は、システムの加入者数とは独立である。しかしながら、周期的ブロードキャストの利点は、人気のあるビデオのような頻繁に要求されるコンテンツに限られる。
【０００４】
あまり人気のない、頻繁に要求されないコンテンツの場合には、非周期的なマルチキャストを用いることができる。非周期的なマルチキャストの環境では、ユーザは、サーバにコンテンツを要求し、サーバは当該コンテンツをあるスケジューリング・ポリシーに従い提供する。パッチングと称される技術は、新たに入来する要求が、現行のマルチキャストに加わることを可能にし、同一のデータ・ストリームを活用する。非周期的マルチキャストの手法は、真のＶＯＤサービスを提供しうる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、これらの手法は、パッチング技術を採用する手法も含め、真のＶＯＤサービスを提供するが、一方で大きなデータ・バーストの影響受けうる。
【課題を解決するための手段】
【０００６】
本発明のある態様は、既存のコンテンツ配信システムが、望ましくないデータ・バーストの影響を生じるというような問題のある特徴を有するという認識を含む。本発明の別の態様は、コンテンツを通信する方法を含む。当該方法は：コンテンツの要求を受信する段階；該コンテンツを配信するスケジュールを生成する段階；該スケジュールが前記要求の遅延パラメータを満たすか否かを決定する段階；該遅延パラメータを満たすという決定に応答して、前記コンテンツの一部の配信を遅延させるよう、前記スケジュールを修正する段階；を有する。前記スケジュールを修正する段階は：前記コンテンツを配信するために帯域幅が利用可能な、前記スケジュールの第１の時間間隔を検出する段階；及び前記コンテンツの一部の配信を遅延させ前記時間間隔中に生じるようにするために、前記スケジュールを調整する段階；を更に有してよい。要求は、クライアント装置から受信され、前記遅延パラメータは該クライアント装置のユーザにより設定された遅延限度を有してよい。前記スケジュールは複数の時間間隔を有し、該複数の時間間隔は前記コンテンツの一部の配信が配信のためにスケジューリングされる第１の時間間隔を有し、前記コンテンツは複数の情報ブロックを有し、前記一部は該複数の情報ブロックの中の第１のブロックを有し；前記スケジュールを修正する段階は：前記第１の時間間隔中に前記コンテンツの一部を配信するために、追加の帯域幅が必要であると決定する段階；前記第１の時間間隔の後の、追加の帯域幅が利用可能な第２の時間間隔中に生じるよう、前記第１のブロックの送信を遅延させる段階；及び前記第１の時間間隔から前記第２の時間間隔までの遅延により生じる送信の遅延が、前記遅延パラメータと関連付けられた遅延限度を超えているか否かを決定する段階；を有してよい。
【０００７】
本発明の別の態様は、コンテンツを配信する方法を含む。当該方法は：コンテンツの要求を受信する段階；該コンテンツの初期部分を第１の遅延を以て、該コンテンツの後続の部分を第２の遅延を以て、該コンテンツを配信するスケジュールを生成する段階；を有し、該スケジュールを生成する段階は、前記要求の受信から前記コンテンツの初期部分の配信までの時間を最小化するよう、前記第１の遅延を選択する段階及び前記要求と関連付けられた遅延パラメータを満たし、前記後続の部分の配信の遅延を増大させるよう、前記第２の遅延を選択する段階、を有してよい。
【０００８】
本発明の別の態様は、コンテンツを受信する方法を含む。当該方法は：コンテンツ・プロバイダーからコンテンツを受信する段階；該コンテンツ・プロバイダーへ配信遅延限度を提供する段階；前記コンテンツの初期部分の配信を開始する第１の時間と前記コンテンツの後続の部分の配信を開始する第２の時間とを有するスケジュールに従い、前記コンテンツを受信する段階；を有し、前記第１の時間は、前記要求の受信から前記コンテンツの初期部分の配信の開始までの遅延を最小化し、前記第２の時間は、前記配信遅延時間を満たすとともに前記コンテンツの後続の部分の配信の開始の遅延を増大させてよい。  本発明の別の態様は、コンテンツを配信するシステムを含む。当該システムは：コンテンツの要求装置から要求を受信し、該要求装置から遅延パラメータを受信するインターフェース；該インターフェースと結合され、前記要求に応答してスケジュールに従い前記要求装置へ前記コンテンツを配信するスケジューラ；を有し、該スケジューラは、前記コンテンツの一部の配信を遅延させるよう、前記要求装置の遅延パラメータに応じて前記スケジュールを修正し、前記遅延パラメータが満たされると決定してよい。
【０００９】
本発明の別の態様は、コンテンツを配信する方法を含む。当該方法は：コンテンツの要求を受信する段階；該要求に応答して前記コンテンツを配信するスケジュールを生成する段階；及び前記コンテンツを送信する遅延時間を示すメッセージを送信する段階；を有してよい。当該方法は、前記スケジュールが前記要求の遅延パラメータを満たすか否かを決定する段階を更に有し、前記スケジュールが前記遅延パラメータを満たさない場合、前記メッセージは前記要求が拒否されたことを示す。
【００１０】
本発明は、以下の詳細な記載を添付の図面と関連して読むことにより明らかである。
【図面の簡単な説明】
【００１１】
【図１】本発明の原理を組み込んだ、１又は複数のユーザからの要求に応答してコンテンツを通信するシステムを、ブロック図の形式で示す。
【図２】本発明の原理に従うコンテンツ通信のスケジューリングに関する図１のシステムの態様を、フローチャートの形式で示す。
【図３】図２のフローチャートに従うコンテンツ通信のスケジューリングのための、図１のシステムの動作の態様を説明するタイミング図を示す。
【図４】図２、３のコンテンツ通信のスケジューリングのための、図１のシステムの動作を更に説明するタイミング図を示す。
【図５】本発明の原理に従うコンテンツ通信のスケジューリングに関する図１のシステムの態様を、フローチャートの形式で示す。
【発明を実施するための形態】
【００１２】
図及び関連する説明の理解を実現するために、種々の図面を通じて、同一又は同様の特徴には同一の参照符号を用いる。理解されるべき点は、図面は、本発明の態様、特に本発明の例である実施例を説明することを目的としていることである。本発明の原理を組み込んだシステムの他の構成及び実施例も可能である。
【００１３】
説明を簡単にするために、以下では、ビデオオンデマンド・システム又はＶＯＤにおける、本発明の原理の例である実施例を説明する。しかしながら、本発明は、コンテンツ源とユーザとの間でコンテンツを通信する種々のシステムに広く適用可能である。本願明細書に記載される本発明の原理は、ビデオ及び／又はオーディオを含むがこれらに限定されないあらゆる種類のコンテンツを配信し及び／又は受信するシステムに適用可能である。
【００１４】
また、コンテンツは、種々の通信媒体及び素子を含む種々の種類の通信ネットワークを介して通信されてよい。例えば、本発明の原理は、コンテンツを電話機（例えば固定電話機又は携帯電話機のような無線電話機）、セットトップボックス、テレビ、コンピューター等を含む装置に提供する有線及び無線通信ネットワーク（例えばＣＡＴＶ、携帯電話ネットワーク、衛星システム等）に適用可能である。また、本発明のある態様は、コンテンツ格納機能、及び／又は個人向けビデオ・レコーダー（ＰＶＲ）のような機能を有するシステムに関する。例えば、ＰＶＲのような格納機能の能力は、以下に説明するように、再生に必要になるまで受信したデータをバッファリングすることにより、早くからいるクライアントにメディア・データを配信しているマルチキャスト・ストリームに後から来たクライアントが参加することを可能にする。
【００１５】
本願明細書に記載する本発明の原理を組み込んだシステムの他システムの例である実施例は、ＶＯＤサービス・モード、及びマルチキャスト伝送をスケジューリングする関連方法を含む。記載するＶＯＤシステムは、システムのユーザ、顧客、又はクライアントに、コンテンツを識別するリスト、例えばビデオの名称のリスト、及び個々の最も早い再生時間を提供してよい。再生が可能な時間に関する情報を提供することは、例えば提供されたリスト内のコンテンツ・アイテムの１つを要求することにより又は許容遅延を特定する情報を動作の設定モード中のような別個の通信でサーバに提供することにより、コンテンツを要求する各エンティティ、例えば顧客、クライアント、又はユーザが、要求者の選択する又は認容可能な又は許容遅延を特定する遅延パラメータ又は遅延限度を設定することを可能にする。顧客から要求を受信することにより、システムは、要求を受け付けるか否かを、利用可能なネットワークの帯域幅及びユーザの許容遅延によって決定する。
【００１６】
例えば、図１は、ＶＯＤサーバ１１０を有する例であるＶＯＤシステムのブロック図を示す。ＶＯＤサーバ１１０は、図１で概して１３０、より詳細には１３１、１３２、１３３、１３４で識別される種々のクライアント・システムにネットワーク１２０を介してサービスを提供する。図１に示すクライアント・システムは、マルチメディア装置、パーソナル・コンピューター、セットトップボックス、テレビ等のような種々の可能な装置を表す。ユーザ１４０は、コンテンツをサーバ１１０から、クライアント・システムの１つ、例えばクライアント１３２を介して要求する。
【００１７】
本発明のある態様によると、サーバ１１０は、利用可能なコンテンツ及び最も早い再生時間のリスト１５０をユーザ１４０へクライアント１３２を介して提供する。ユーザ１４０は、要求１６０をクライアント装置１３２を介して提出し、リストされたコンテンツ・アイテムの１つを要求する。
【００１８】
本発明の別の態様によると、ユーザ１４０は、コンテンツを受信するためにユーザが選択する又は許容可能な遅延であると思う遅延値を識別又は特定する遅延パラメータ又は遅延限度を指定する。つまり、ユーザは、ユーザが認容可能な遅延限度又は最大遅延を指定してよい。許容遅延のこのような指定は、コンテンツの要求の一部として又は許容遅延パラメータが定められる動作の設定モード中に提供されてよい。
【００１９】
或いは、サーバ１１０は、許容遅延、例えば既定値を提案し、ユーザ１４０はクライアント装置１３２のユーザ・インターフェース（例えば表示された設定メニュー）を介して当該値を承諾するか、拒否するか、修正してよい。
【００２０】
図１に示すシステムは、例えばサーバ１１０内に、クライアント装置１３０のような要求装置からのコンテンツ要求を受信するインターフェース、及び例えばサーバ１１０内に、インターフェースと結合された、スケジュールに従いコンテンツを配信する要求に応じるスケジューラ、を有する。図１のサーバ１１０内のスケジューラにより構築された、コンテンツをクライアントへ提供又は送信するための送信スケジュールは、ＶＯＤ要求の到着に従い準備される。システムにより受理された各要求は、スケジュールされたコンテンツのストリームに対応する。スケジュールの目的は、最も早い時間に各要求にコンテンツへアクセスさせ（例えば要求したビデオの閲覧）、当該コンテンツを連続的に再生させることである。
【００２１】
本発明のある態様によると、ビデオのようなコンテンツは、コンテンツ・データ又は情報の複数のブロック又は部分に分割される。コンテンツのストリームは、特定のコンテンツ・アイテムの全ての部分又はブロックを提供する。ストリーム毎に、送信スケジュールは、コンテンツ、例えばビデオの最初の又は初期部分又はブロックを、帯域幅が利用可能となった後、直ちに送信し、コンテンツの連続したブロック又は後続の部分をできる限り遅くに、しかし最初のブロックからの時間オフセットよりも遅れずに送信し、コンテンツがユーザに対して連続的に又は少なくとも許容できない中断を有さずに再生されるようにする。例えば、ビデオ・コンテンツの場合、送信スケジュールは、ビデオが円滑に再生し続けるように、ビデオ・コンテンツの送信のために提供される。
【００２２】
本発明の別の態様によると、スケジューラは、例えば以下に説明するようにスケジュールを再構成することにより、スケジュールを修正又は採用してよい。例えば、スケジュールは、コンテンツの一部の配信を遅延させるために、ユーザが指定した許容遅延のような遅延パラメータ又は遅延限度に応じて修正されてよい。遅延は、ストリーム内のブロックの送信をできる限り遅くに遅延させ、利用されているコンテンツの送信されたブロックが複数の要求に供する可能性を増大させる。つまり、ビデオに対する第１の要求に続いて、同一のビデオに対する第２の要求が受信された場合に、第１の要求に応じたブロックの送信は、第２の又は他の続いて生じる要求に供するために用いられてもよい。上述のような配信を遅らせるためのスケジューラによるスケジュールの修正は、遅延が遅延パラメータを満たすと決定された後に生じる。コンテンツを円滑に再生するためには更なる考慮が必要である。
【００２３】
詳細には、例であるＶＯＤシステムは、２つの主要な構成要素、つまりＶＯＤサーバ１１０及びクライアント１３０を有する。ＶＯＤサーバ１１０は、ビデオの名称と最も早いアクセス時間とを有する、ビデオの再生リストを発行する。最も早いアクセス時間は動的に更新される。クライアントがビデオに興味があるときはいつでも、クライアントは、ビデオの名称及びユーザの許容遅延のような情報が含まれる要求を作成する。要求を受信した後に、ＶＯＤサーバは、当該要求を受け付けるか否かを、利用可能な帯域幅及びユーザの許容遅延によって決定する。要求が受け付けられる場合、再生遅延は、確認応答情報に含まれてよい。要求が拒否される場合、最小可能再生遅延が、確認応答情報に含まれてよい。クライアントは、最小可能再生遅延に基づき、必要に応じて別の適当な要求を作成できる。
【００２４】
図２に、送信のスケジューリングの例である実施例を、フローチャートの形式で示す。図２に示す実施例は、ソフトウェア（例えば、コンピューター、又はマイクロプロセッサー、コントローラー、又は信号処理集積回路により実行される）、及び／又はハードウェアで実施されてよい。図２では、スケジューリングは段階２００で開始する。段階２００の次に段階２１０がある。段階２１０で、１又は複数のクライアントがコンテンツの要求を生成するか又はサーバが当該コンテンツの要求を傾聴又は受信する。以下に詳細に説明するように、要求が到着すると、システムは、先ず当該要求のためのストリームをスケジュールし、次に必要に応じて複数の要求に関連するストリームを結合してよい。
【００２５】
図２の態様を説明する目的で、特定の用語が以下のように用いられる。用語「ブロック」は、コンテンツ・アイテムの部分又はサブセットを表すために用いられる。ビデオのようなコンテンツでは、ビデオは、例えば各ブロックが等しい大きさを有する、Ｎ個の部分又はブロックに論理的に分割される。ブロックの大きさは、スケジュールの精度を決定する。
【００２６】
「ストリーム」は、ビデオのようなコンテンツ・アイテムを表す送信された一連のブロックを表す。ビデオの要求のようなコンテンツの要求が到着すると、システムは要求に対してストリームをスケジューリングする。スケジュールされたストリームは、いつ及びどのブロックが送信されるかを表す。各要求はスケジュールされたストリームに対応する。
【００２７】
ビデオの「送信期間」は、（最初のビデオの要求に対する）最初のストリームの送信が開始したときに開始する。送信期間は、ビデオの全ての存在するストリームが終了する前に、如何なる要求も到着しない場合に、終了する。新たな送信期間は、最後の送信期間が終了した後にビデオの要求が到着した場合に開始する。
【００２８】
「基準ストリーム」は、送信期間内の最初のストリームである。送信期間には正確に１つの基準ストリームがある。
【００２９】
「タイムスロット」は、ビデオ・ブロックの継続期間のタイム・スパン、つまりコンテンツのブロックが伝達される時間間隔である。同一のタイムスロット内のビデオ・ブロックは、同一の時間に送信される。各タイムスロットは、タイムスロットの「容量」として表される、特定の数のビデオ・ブロックを有する。特定のスケジュールを実施するために、タイムスロットがその容量より多くのブロックを有しなければならない場合、タイムスロットは、「過負荷タイムスロット」として表される。つまりタイムスロットは如何なる利用可能な帯域幅も有さない。タイムスロットが余分な容量を有する場合、つまり特定のスケジュールがタイムスロットにその容量より少ないブロックを有することを要求し、従ってタイムスロットが余分な又は利用可能な帯域幅を有する場合、タイムスロットは「不足負荷タイムスロット」として表される。
【００３０】
図３は、上述の用語の特徴を説明する、２つの送信期間のタイミング図を示す。図３のコンテンツでは、ブロックの総数は２０である。送信期間１には、２つのストリームＳ０、Ｓ１がある。送信期間２には、３つのストリームＳ２、Ｓ３、及びＳ４がある。Ｓ０は、送信期間１の基準ストリームである。Ｓ２は、送信期間２の基準ストリームである。基準ストリームのみが、全てのＮ個のブロックを望ましくは連続して送信する。基準ストリームの最初のブロックは基準時間ゼロを有し、他の全てのブロックは最初のブロックからの再生時間オフセットと等しい基準時間を有する。所与の時間に１つのブロックを送信しているように図示したが、本発明の原理は、複数のブロックが所与のタイムスロットで同時に送信される場合にも適用できる。
【００３１】
上述の用語に加え、本願明細書の記載は、以下の記号を用いる。
Ｎは、ビデオの総ブロック数を表す。
Ｂは、サーバの帯域幅の限度を表す。
ｂは、ビデオの再生レートを表す。
ｄｉは、ｉ番目の要求のサービス遅延を表す。（送信遅延は無視される。つまりビデオがＴｉで送信された場合、当該ビデオはＴｉで表示でき、従ってサービス遅延は関連するサーバの帯域幅の限度である。）
Ｄｉは、ｉ番目のユーザが許容できる最大サービス遅延を表す。aiは、送信期間内のｉ番目の要求の到着時間を表す（ｉ＝０、１、２、．．．）。
ｔｉｊは、送信期間内のｉ番目のストリームの中のｊ番目のブロックの送信の開始時間を表す。ａｉ及びｔｉｊの精度は、ブロックの期間である。ａ０＝０、ｔ００＝０、つまり第１のストリームの最初のブロックは、基準時間ゼロを有する。
Ｔｉは、ｉ番目のストリームの送信時間を表す。Ｔｉ＝ａｉ＋ｄｉ
図４は、本発明の態様による、スケジューリングを提供する例である実施例の動作例を示す。図４では、小さい○は要求を表す。実線の上の数字は、ビデオ・ブロックの指数を表す。全部で２０個のブロックがビデオに含まれる。サーバの帯域幅は、ビデオ・レートの３倍である。Ｒｉは、ｉ番目の要求を表す。Ｓｉは、ｉ番目のストリームを表す。
【００３２】
送信期間内の最初の要求に対し、スケジューラは、Ｎ個の全てのブロックを従来のＶＯＤシステムでのように連続して送信するために、最初の要求Ｒ０の到着時間であるＴ０で開始する基準ストリームを生成する。ｋ番目の要求が到着すると、システムは、ｋ番目の要求のために、Ｓｋにより表されるストリームをスケジューリングする。スケジュール手順の詳細を、図２及び図４に関連して以下に説明する。要求、例えばｋ番目の要求を受信した後、図２の段階２１０として、初期の又は初めのスケジュールが図２の段階２２０として示されるように作成される。システムは、［ａｋ−１，ａｋ］で送信されているブロックを送信するようスケジューリングする。
【００３３】
他のブロックは、要求しているクライアントに利用可能である。何故なら、当該他のブロックは、先行する要求に応答して存在しているストリームにより送信されるからである。全てのブロックは、最初のブロックからの当該ブロックの時間オフセットで送信されるようスケジューリングされる。サーバは、ｋ番目のストリームＳｋのブロックの送信時間を示す初期スケジュールＵｋを作成する。Ｕｋは次式で表される。
Ｕｋ＝｛ｕｋ１，ｕｋ２，．．．，ｕｋｙ｝
ここでｕｋｉは、ｋ番目のストリームの中のｉ番目のブロックの予定送信時間である。ｋ番目のストリームの中のｉ番目のブロックは、必ずしも要求されたビデオ又はコンテンツのｉ番目のブロックではない。
【００３４】
図２の段階２３０で、初期スケジュールの生成に続き、帯域幅が利用可能なタイムスロット又は時間間隔を検出するために帯域幅の検出が実行される。時点ａｋから、帯域幅が帯域幅の限度を上回っているタイムスロットのセットは、Ｈとして表される。ここでＨ＝｛ｈ１，ｈ２，．．．，ｈｍ｝である。各ｈｉは、２つの属性を有する。つまりｈｉ＝｛ｈｉ１，ｈｉ２｝である。ここでｈｉ１は、タイムスロットの開始時間を表し、ｈｉ２は、当該タイムスロット内のｉ番目のストリームのブロック数を表す。ｈｉ１は、過負荷タイムスロットとして参照され、ｈｉ２は、過剰ブロックとして参照される。ｈｉ（ｉ＝１，２，．．．，ｍ）は、ｈｉ１の昇順に順序付けられる。
【００３５】
時点ａｋから、帯域幅が帯域幅の限度を下回っているタイムスロットのセットは、Ｌとして表される。ここでＬ＝｛ｌ１，ｌ２，．．．，ｌｗ｝である。各ｌｉは、２つの属性を有する。つまりｌｉ＝｛ｌｉ１，ｌｉ２｝である。ここでｌｉ１はタイムスロットの開始時間を表し、ｌｉ２は占有されている帯域幅と帯域幅の限度との間の差分を表す。ｌｉ（ｉ＝１，２，．．．，ｗ）は、ｌｉ１の昇順に順序付けられる。
【００３６】
本発明のある態様によると、図２の段階２４０で、帯域幅検出の結果が評価される。例えば、段階２４０は、Ｈを評価する段階を有してよい。Ｈがヌルである（つまり、図２の段階２４０で否定的又は「Ｎｏ」という結果を得た）場合、利用可能な帯域幅は、初期スケジュールを修正しなくとも、ストリームの送信に適している。その場合、図２の動作は、段階２５０に進む。
【００３７】
段階２５０で、初期スケジュールが確認され、当該スケジュールに従い直ちに送信が行われる。段階２４０でＨがヌルでない場合、スケジュールの修正は、本発明の態様による再構成を含み、図２の段階２７０で行われてよい。
【００３８】
再構成の前に、段階２６０で、再構成を行う必要のある遅延が、要求元の能力の範囲内か否か、つまりユーザの指定した遅延パラメータ又は遅延の限度を満たしているか又はそれらに従っているか否かについて、評価が行われる。
【００３９】
評価が否定的な結果であった場合、段階２８０で要求が拒否される。遅延が許容可能な場合、スケジュールの修正又は再構成は、段階２７０で、以下に説明されるように実行される。
【００４０】
段階２５０の間、スケジュールされたストリームｋは、時間Ｔｋで送信される。ここで、Ｔｋ＝ａｋである。これは、ｋ番目の要求のサービス遅延がゼロであることを意味する。ブロックの送信時間は、Ｖｋ＝Ｕｋ＝｛ｕｋ１，ｕｋ２，．．．，ｕｋｙ｝である。例えば、図４で、要求２が到着したとき、利用可能な帯域幅はストリームを送信するのに十分である。従って、ストリーム２は、［ａ１，ａ２］で遅延なく送信されているブロックを送信する。また、ストリーム２の最初のブロックは、時間Ｔ２で送信される。ここでＴ２＝ａ２である。
【００４１】
図２の段階２４０での評価が、帯域幅は初期スケジュールに対応するために適当でないと示す場合、初期スケジュールの修正は、段階２７０で行われる。本発明のある態様によると、スケジュールの修正又は再構成は、帯域幅のバーストを平坦化し、元のスケジュールに近いものに保つ。再構成の後、Ｔｋ＞ａｋである。必要な遅延ｄｉが待ち時間許容値Ｄｉの範囲内である場合、要求は受理され、ビデオ・ブロックは再構成された結果であるスケジュールに従い送信される。その他の場合、段階２８０で、要求は拒否され、最も早い可能な開始時間が要求元へ返送される。
【００４２】
段階２７０のようなスケジュール調整又は再構成の例である実施例を以下に説明し、図５に詳細に示す。スケジュールの修正又は再構成のある特徴は、最小初期遅延を生成することであってよい。別の特徴は、現在の要求のために送信されるコンテンツが、後の要求によっても共有される程度を最大化することであってよい。一つには、記載された実施例により提供される共有の増大は、ブロックをできる限り遅くに送信すること、一方でユーザにより示された遅延許容値に従い当該送信を行うことに起因する。
【００４３】
スケジュールの修正の第１の段階は、不足負荷タイムスロットの集合Ｇの決定である。ＧがＬから生成され、Ｇ＝｛ｇ１，ｇ２，．．．，ｇｎ｝、
【数１】
0005479107.tif 000002
及び２はＬ内の要素数であるとすると、Ｇは次式のように生成されうる。
ｇ１＝ｌ１１
ｇｉ（ｉ＝２，３，．．．，ｎ）は次式に従い生成される。
【００４４】
【数２】
0005479107.tif 000003
次に、Ｇのｍ個の要素は、集合Ｑのために選択される。ここで
【数３】
0005479107.tif 000004
である。ｍはＨの要素数である。
【００４５】
【数４】
0005479107.tif 000005
次に、Ｑｉは次式（１）が成立するように、Ｑから選択される。
【００４６】
【数５】
0005479107.tif 000006
ここでｈｉ２はｑｉｊで送信されるようスケジューリングされる。
【００４７】
次に、ｋ番目のストリームのためにスケジュールされた全てのブロックは、シーケンスの昇順で再順序づけされる。ブロックの送信時間は、Ｖｋ＝｛ｖｋ１，ｖｋ２，．．．，ｖｋｙ｝である。従って、再生時間の遅延は次式に等しい。
【００４８】
【数６】
0005479107.tif 000007
必要な遅延がユーザの待ち時間の許容範囲内である場合、つまり遅延パラメータ又は遅延限度が満たされている場合、システムはビデオ・ブロックをスケジュールされた通りに送信する。必要な遅延が待ち時間の許容範囲を超えている場合、つまり遅延パラメータ又は遅延限度が満たされていない場合、要求は拒否され、最も早い可能な開始時間が要求元へ返送される。
【００４９】
例えば、図４で、要求３が到着すると、利用可能な帯域幅はストリームの送信に十分ではない。また、最も早い開始時間はＴ３である。従って、ストリーム３は、［ａ２，ａ３］で遅延なく送信されているブロックを送信する。また、ストリーム３の最初のブロックは、時間Ｔ３で送信される。ここでＴ３＝ａ３である。
【００５０】
本発明の別の態様は、適切な不足負荷タイムスロットの選択、つまり帯域幅が利用可能な適切な時間間隔の決定を含む。図５を参照し、以下に適正な不足負荷タイムスロットを選択し、スケジュールを修正又は調整して再構成を提供する例である実施例を説明する。図５の段階２１０から２５０は、図２の同様に示された段階に対応する。上述のように、初期スケジュールの調整中に考慮すべき事項には、以下の条件の一方又は両方を満たすことが含まれてよい。
条件１：最小の初期遅延を提供する。
条件２：例えばブロックをできる限り遅くに送信することにより、特定の要求に対するコンテンツの送信を、後の要求と最大限に共有する。
つまり、条件１によると、スケジュールは、最小の初期遅延を提供する、コンテンツの初期部分の配信を開始する第１の時間を含む。更に、条件２によると、スケジュールは、第２のブロックのようなコンテンツの後続の部分の配信を開始する第２の時間を含む。これは、遅延パラメータ又は遅延限度を満たしながら、後続の部分の配信の遅延をできる限り遅くになるよう増大させる。
【００５１】
両条件を満たすシステムを提供する例である実施例は、先ず条件１を考慮し、次に第１の条件が満たされると第２の条件を考慮する。最小の初期遅延を提供するという第１の条件を満たすことを、スケジュール修正の第１のパスと表す。第１のパスの間、２つの処理が行われる。つまり、不足負荷タイムスロットの選択とブロックのシフトである。
【００５２】
最小の初期遅延、つまり遅延許容範囲内であることを達成するために、図５の段階５６０のように、最も早い利用可能な不足負荷タイムスロットが、過負荷ブロックを含むよう選択される。つまり、スケジュールされているストリームの過負荷ブロックの総数がｍである場合、Ｌから最初のｍ個の不足負荷タイムスロットを選択すべきである。次に、過負荷ブロックは、それぞれｍ個の選択した不足負荷タイムスロットへシフトされる。つまりコンテンツの一部が遅延される。
【００５３】
シフト又は遅延は以下ように行われる。（タイムスロットｈｉ１の）過負荷ブロックｈｉ２を不足負荷タイムスロットｌｊ１へ移動する必要がある場合、２つの場合を考慮する。場合１、つまりｌｊ１＜ｈｉ１の場合、ｌｊ１の直ぐ隣のタイムスロットにあるブロックはｌｊ１へ移動され、代わりに（ｌｊ１，ｈｉ１）間の全てのブロックは自身の直前のタイムスロットへ移動され、（タイムスロットｈｉ１の）ブロックｈｉ２はｈｉ１の直前のタイムスロットへ移動される。場合２、つまりｌｊ１＞ｈｉ１の場合、ｌｊ１の直前のタイムスロットにあるブロックはｌｊ１へ移動され、代わりに（ｈｉ１，ｌｊ１）間の全てのブロックは自身の直ぐ隣のタイムスロットへ移動され、（タイムスロットｈｉ１にある）ブロックｈｉ２はｈｉ１の直ぐ隣のタイムスロットへ移動される。
【００５４】
次に、最小の初期遅延ｄを決定する。初期スケジュールの後のブロックの送信時間をＵ＝｛ｕ１，ｕ２，．．．，ｕｙ｝と表し、第１のパスの再スケジュールの後のブロックの送信時間をＶ＝｛ｖ１，ｖ２，．．．，ｖｙ｝と表す。すると、最小遅延ｄは次のように決定される。
【００５５】
【数７】
0005479107.tif 000008
次に、段階５６１で、最大遅延を調べ、最大遅延が許容範囲内であるかどうか、つまりスケジュールが遅延パラメータ又は遅延限度を満たすかを決定する。否定的な結果であった場合、段階５８０で要求が拒否される。最小遅延が許容できる場合（つまり許容範囲内であるか、遅延パラメータ又は遅延限度を満たす場合）、データ共有を最大化する第２の条件を考慮するために、スケジュールの第２のパスが行われる。つまり、遅延パラメータを満たすと決定されると、第２のパスが行われ、スケジュールを修正し、コンテンツの少なくとも一部の配信を遅延させる。第１のパスの後、スケジュールの最小初期遅延Ｄｍｉｎが決定され、段階５６２で、初期にスケジュールされたストリームはＤｍｉｎの範囲内で遅延される。次に、段階５６３で帯域幅の検出が行われ、全ての過負荷ブロックと全ての不足負荷タイムスロットが見付けられる。段階５６４で、最後の過負荷ブロックから最初の過負荷ブロックまで、シフトが行われ、過負荷ブロックを、該過負荷ブロックの現在の位置より前に位置し且つ該現在の位置への最短距離を有する不足負荷タイムスロットへそれぞれ移動する。このシフト又は遅延又は再配置を、以下に詳細に説明する。
【００５６】
初期スケジュールをＤｍｉｎの範囲内で遅延した後、過負荷ブロック毎に、過負荷タイムスロットの前に位置する少なくとも１つの不足負荷タイムスロットを見付け、過負荷ブロックを「保つ」ことが常に可能である。これは以下のように行われる。
【００５７】
先ず、初期スケジュールをＤｍｉｎの範囲内で遅延することにより、ストリームが最大初期遅延を有しスケジューリングされる。つまり、ｋ番目のストリームに対し、［ａｋ−１，ａｋ］で送信された全てのブロックは、最初のブロックからの該ブロックの時間オフセットにＤｍｉｎを加算して送信されるようスケジューリングされる。ブロックの送信時間は、Ｕｋ＝｛ｕ１＋Ｄｍｉｎ，ｕ２＋Ｄｍｉｎ，．．．，ｕｙ＋Ｄｍｉｎ｝と表される。
【００５８】
次に帯域幅の検出が行われる。スケジュールを遅延した後、タイムスロットの帯域幅が変更される。従って、全ての過負荷ブロックと全ての不足負荷タイムスロットを見付けるために、帯域幅の検出を再び行う必要がある。
【００５９】
次に、スケジュールされたブロックが再構成される。再構成は、第１のパスのスケジュールと同様である。再構成も２つの処理を有する。つまり、不足負荷タイムスロットの選択とブロックのシフトである。過負荷ブロックを含めるためにどの不足負荷タイムスロットが選択されるかを決定するために、「後ろ」から「前」へ向かって選択が行われる。つまり、先ずどの不足負荷タイムスロットが（時間軸上での）最後の過負荷ブロックを含むかを決定し、次にどの不足負荷タイムスロットが（時間軸上での）最後から２番目の過負荷ブロックを含むかを決定し、以下同様である。（タイムスロットｈｉ１にある）過負荷ブロックｈｉ２に対し、ｈｉ２を含む不足負荷タイムスロットｌｊ１は次のように決定される。
【００６０】
【数８】
0005479107.tif 000009
Ｌｉｐｒｉｏｒは、ｈｉ１の前にある（ｈｉ１より小さい）全ての不足負荷タイムスロットの部分集合である。つまり、不足負荷タイムスロットｌｊ１は、ｈｉ１の前にある全ての不足負荷タイムスロットの中で、ｈｉ１への最短距離を有する。
【００６１】
第２のパスのスケジュールのブロック・シフトは、第１のパスのスケジュールのブロック・シフトと同じである。しかしながら、選択した不足負荷タイムスロットは過負荷タイムスロットの前にあり、従って第２のパスのブロック・シフトは場合１だけしか有さないので、場合１のみが存在する。
【００６２】
本発明の別の態様は、図５の段階５９０として、ストリームを結合した後に１又は複数の要求が１つのストリームに対応するような、コンテンツ・ストリームの結合を有する。ストリームの結合は次のように行われる。現在の要求時間が前のストリームの送信開始時間より前である場合、現在のストリームは前のストリームと結合される。結合の結果、２つの要求に対してサービスを提供する１つのストリームを生じる。例えば、要求５が到着すると、要求５のために十分な資源がないので、ストリーム５の最も早い送信開始時間はＴ５にスケジューリングされる。要求５は待ち時間モード（ｌａｔｅｎｃｙ  ｍｏｄｅ）でサービスを提供される。待機時間中、要求５は、マルチキャスト・データを受信し、バッファに格納する。次に、要求５の開始時間より前の、つまりｔ５＞ａ６である（ブロック持続時間の精度が用いられる場合には、ｔ５＝ａ６である）要求６が到着する。従って、要求５は要求６と結合されてよい。結合した後、新たなストリームＳ５はスケジュールされ、要求５と要求６の両方に対応する。図４から、期間［ａ５，ａ６］中に到着した全ての要求は、１つのストリームに結合されることが分かる。
【００６３】
段階５６５で、ストリームは、スケジュールに従ってクライアントへ送信される。ストリームをクライアントへマルチキャストする幾つかの方法がある。ある方法は、コンテンツのユーザ要求毎に独自にストリームをマルチキャストする方法である。別の方法は、全てのユーザ要求に対し１回ストリームをマルチキャストする方法である。前者の方法の利点は、ユーザが興味のあるマルチキャスト・ストリームを申し込むだけでよく、関係のないストリームがユーザに届かないことである。後者の方法は、クライアント側で余分なデータをフィルターする必要がある。
【００６４】
本発明の上述の態様は、図４と関連して記載する例である実施例の以下の説明を読むことにより一層理解されるだろう。上述のように、例である実施例は、ビデオ・プログラムに対する複数の要求を処理するＶＯＤサーバを有する。サーバは、１つより多いビデオ・プログラムを格納できるが、記載される実施例は特に同一のビデオ・プログラムに対する要求に関連する。ビデオ・プログラムは、説明のためにＮ個のブロックに分割される。通信チャネルは、１つのタイムスロットで最大Ｍ個のブロックを送信できる。そして、各ブロックは１つのタイムスロットで送信されうる。図４では、Ｎ＝２０、Ｍ＝３である。クライアント装置が要求を提出すると、クライアント装置は、通信チャネル内の全てのビデオ・ブロックを集め、ビデオ・ブロックを適正な順序に並べ始める。要求されたビデオ・プログラムの全てのブロックを受信すると、クライアント装置は、要求したビデオ・プログラムの再生を開始しうる。
【００６５】
図４の例では、ストリームＳ０〜Ｓ５は、要求Ｒ０〜Ｒ６に応答して示される。Ｓ２は、ブロック０−４及び８−１２を、タイムスロット１３−１７及び２１−２５からそれぞれ送信し始める。Ｓ３は、ブロック０、１、５、６、１３及び１４を、タイムスロット１６、１７、２０、２１、２８、２９でそれぞれ送信し始める。Ｓ４は、ブロック０−４、７及び１５−１７を、タイムスロット１８−２２、２５及び３４−３６からそれぞれ送信し始める。Ｓ５は、ブロック０−６、８、９、１８及び１９を、タイムスロット２３−２９、３１、３２、４２及び４３からそれぞれ送信し始める。また、要求Ｒ５が到着したとき、図４に示したスケジュールの結果は、Ｓ５のブロック０がタイムスロット２３で送信を開始することを示す。しかし、要求Ｒ６はタイムスロット２３より前に到着するので、Ｓ５とＳ６は１つのストリームとして結合される。
【００６６】
クライアント装置０が時間ａ０又はタイムスロット０でビデオ・プログラムを要求すると（図４の要求Ｒ０）、サーバは、基準ストリームＳ０に対する初期スケジュールＵ０を作成する。ここで（０，１，２，．．．，１９）であり、ビデオのブロックｉがタイムスロットｉで送信されるようスケジュールされたことを示すビデオ・プログラムの如何なるブロックも通信チャネルで送信されていないので、２０個のブロックの全てが送信されなければならない。如何なる過負荷タイムスロットも存在しないので、初期スケジュールＵ０は、再構成されることなく最終スケジュールＶ０になる。サーバは各タイムスロットで３個のブロックを送信できるが、本実施例では、サーバは各タイムスロットで１つのビデオ・ブロックを送信する。ブロックはブロック０から開始するシーケンスで送信されるが、これは、各クライアント装置が全てのブロックを再生のために適正なシーケンスに再組立てできるので、必要ない。
【００６７】
サーバは要求０に応答してタイムスロット毎に１つのブロックを送信するので、各タイムスロット内の２つのブロックの帯域幅は、他の要求のために利用できる。
【００６８】
クライアント装置１は、時間ａ１又はタイムスロット８で要求（図４のＲ１）を提出し、通信チャネルでビデオ・ブロックを受信し始める。ブロック８−１９は通信チャネルで既に利用可能なので、サーバはブロック０−７だけを送信する。該ブロック０−７は、時間間隔［ａ０，ａ１］で送信される。サーバは、ストリーム１、つまりＳ１に対し、ブロック０−７のための初期スケジュールＵ１を（８，９，１０，．．．，１５）として作成する。如何なる過負荷タイムスロットも存在しないので、初期スケジュールＵ１は、再構成されることなく最終スケジュールＶ１になる。
【００６９】
時間ａ２又はタイムスロット１３で、クライアント装置２は、要求（図４のＲ２）を提出する。この時点で、通信チャネルは、ブロック５−７及び１３−１９を送信している。サーバは、ブロック１−４及び８−１２を送信するだけでよい。これらのブロックは時間間隔［ａ１，ａ２］で送信される。サーバは、ストリーム２（Ｓ１）に対しブロック１−４及び８−１２を送信するために初期スケジュールＵ２、つまり（１３，１４，１５，１６，１７，２１，２２，２３，２４，２５）を作成する。初期スケジュールでは、最初のブロックを送信する時間は、要求を受信した時間である。Ｓ２内の全てのブロックは、連続するタイムスロットで送信されるようスケジュールされてよい。しかしながら、送信チャネルの帯域幅管理の柔軟性を向上させるために、連続するブロックだけが連続するタイムスロットで送信されるよう初期スケジューリングされることが望ましい。２つの連続するブロック間でブロック番号が不連続である場合、例えばブロックｉとブロックｉ＋ｊで、ブロックｉが対応する初期スケジュール内でタイムスロットｋで送信されるようスケジュールされた場合、サーバは、ブロックｉ＋ｊがタイムスロットｋ＋ｊで送信されるようスケジューリングする。例えば、Ｕ２で、ブロック０−４は、タイムスロット１３−１７で送信されるようスケジューリングされるが、ブロック８−１２はタイムスロット２１−２５にスケジューリングされる。如何なる過負荷タイムスロットも存在しないので、初期スケジュールＵ２は、再構成されることなく最終スケジュールＶ２になる。
【００７０】
ここまでで、上述の説明は、各タイムスロットの帯域幅を超過しない、つまりタイムスロットが不足負荷タイムスロットである例に関するものであった。以下では、要求を受信したときに帯域幅が不十分な状況、つまり過負荷タイムスロットの状態を記載する。
【００７１】
この場合のスケジュールは次の通りである。
ストリーム０：Ｕ０＝Ｖ０＝（０，１，２，．．．，１９）、それぞれブロック０−１９に対応する。
ストリーム１：Ｕ１＝Ｖ１＝（８，９，．．．，１５）、それぞれブロック０−７に対応する。
ストリーム２：Ｕ２＝Ｖ２＝（１３，１４，１５，１６，１７，２１，２２，２３，２４，２５）、それぞれブロック０−４及び８−１２に対応する。
【００７２】
ａ３又はタイムスロット１５で、受信機３は、要求（図４のＲ３）を提出する。サーバは、間隔［ａ２，ａ３］で送信されるブロックを調べる。これらのブロックはストリーム３、つまりＳ３に含まれるべきである。これらのブロックは、ブロック０、１、５、６、１３及び１４であり、サーバはこれらのブロックを送信するために初期スケジュールＵ３、つまり（１５，１６，２０，２１，２８，２９）を作成する。しかしながら、Ｖ０−Ｖ２及びＵ３を調べた後、サーバは、タイムスロット１５が過負荷であるが、タイムスロット１７及びその先のタイムスロットが不足負荷であることを発見する。サーバは、Ｈリストを作成する。Ｈリストの各要素は、開始タイムスロット及び対応するオーバーフロー・ブロックの番号を示す。本例では、Ｈ＝｛（１５，０）｝である。
【００７３】
サーバは、Ｌリストも作成し、Ｒ３を受信したときより遅い時間のタイムスロットである不足負荷タイムスロットを把握する。Ｌリスト内の要素数ｗは、Ｈリスト内の要素数と少なくとも同じでなければならない。望ましくは、ｗはＶリスト内の最新のタイムスロット数とビデオ・プログラム内のブロック数との和である。この場合、ｗは２５＋２０＝４５である。しかしながら、簡単のため、本例では、ｗは、全帯域幅が利用可能な場合のｗに選択される。また、Ｌは本例は次の通りである。｛（１７，１），（１８，２），（１９，２），（２０，２），（２１，１），（２２，２），（２３，２），（２４，２），（２５，２）｝
{(１７,１),(１８,２),(１９,２),(２０,２),(２１,１),(２２,２),(２３,２),(２４,２),(２５,２)}
従って、ｗ＝９であり、Ｇ内の要素数ｎは１＋２＋２＋２＋１＋２＋２＋２＋２又は１６である。
【００７４】
Ｇを計算するとき、ｇ１＝１７であることに留意する。Ｇの他の要素は、既に説明した次式から計算される。
【００７５】
【数９】
0005479107.tif 000010
従って、ｇ２＝ｇ３＝１８、ｇ４＝ｇ５＝１９、ｇ６＝ｇ７＝２０、ｇ８＝２１、ｇ９＝ｇ１０＝２２、ｇ１１＝ｇ１２＝２３、ｇ１３＝ｇ１４＝２４及びｇ１５＝ｇ１６＝２５である。
【００７６】
Ｑを生成するときの添え字ｍは、Ｈリスト内の項目数を表す。本例では、ｍ＝１である。また、Ｑ内の要素数ｘは１６であり、Ｑは１６個のリスト、つまりＱ１−Ｑ１６を有する。各リストは１つの項目のみを有し、ｔｉ１＝ｇｉである。
【００７７】
次に、以下の式（１）は、Ｈリスト内の各要素の開始タイムスロットに時間的に最も近いｑｉ１を選択するために用いられる。つまり、
【数１０】
0005479107.tif 000011
本例では、ｑ１１＝１７が選択される。これは、ブロック０がタイムスロット１７で送信されることを意味する。ブロックを順序付けした後、Ｖ３＝（１６，１７，２０，２１，２８，２９）であり、ブロック０はタイムスロット１６で送信され、ブロック１はタイムスロット１７で送信される。ブロック５，６，１３，１４は元のスケジュールのままである。つまり、これらのブロックは、タイムスロット２０，２１，２８，２９でそれぞれ送信される。
【００７８】
この時点で、サーバは１つのタイムスロットの遅延時間を知っている。要求が最大で１タイムスロットの遅延時間を要求する場合、該要求は許可され、許可メッセージは遅延時間を有する。要求が１タイムスロットより少ない遅延時間を要求する場合、該要求は拒否され、メッセージは遅延時間を有する。従って、ユーザは更に長い待機時間を有する別の要求を提出しうる。
【００７９】
本願明細書に記載された原理の種々の変更及び／又は拡張が考えられる。例えば、ＶＯＤのようなアプリケーションのために、上述のシステムが適応され、更に多数のユーザに対応するために拡張可能である。上述のようなスケジュールの修正は、「適度」の定義がユーザにより指定されうる適度な待ち時間のサービスを複数のユーザへ提供することにより、複数の要求及びユーザの追加によるデータ・バーストの影響を低減又は平坦化するために用いられうる。
【００８０】
本発明は、個人向けビデオ・レコーダー（ＰＶＲ）を使用可能な顧客を有するＶＯＤシステムを含む種々のシステムに適用可能である。例えば、ＰＶＲが利用可能な場合、後から来たクライアントが、早くからいる複数のクライアントにメディア・データを配信しているマルチキャスト・ストリームに参加し、再生に必要になるまで受信したデータをバッファリングする。これにより、サーバの必要な帯域幅を低減できる。
【００８１】
本願明細書に記載したシステムは、顧客に、特定のコンテンツへの最も早いアクセス時間のような有用な情報を提供する。例えば、システムは、ビデオ名及び該ビデオ名の個々の最も早いアクセス時間のリストを提供してよい。最も早いアクセス時間は、ユーザがコンテンツに対する合理的な要求を作成するのに役立つ。
【００８２】
これにより、ユーザからの無意味な要求を回避し、システムの効率を向上しうる。上述のシステムは、要求の到着、現在利用可能な帯域幅及びユーザの許容可能な遅延に従い構成されたマルチキャスト送信スケジュールに従って動作する。システムは、サーバの帯域幅とサーバの待ち時間との間でトレードオフを行う。システムは、ストリームを動的に結合し、クライアントがデータを最適に共有することを可能にする。
【図１】
0005479107.tif 000012
【図２】
0005479107.tif 000013
【図３】
0005479107.tif 000014
【図４】
0005479107.tif 000015
【図５】
0005479107.tif 000016