JP2010516125A - コンテンツ通信のためのシステム及び方法 - Google Patents

Abstract

マルチキャストＶＯＤシステムのようなシステムは、コンテンツのユーザ要求に応答して及びユーザが指定した許容可能なコンテンツ配信の待ち時間に適合するスケジュールに従いコンテンツを通信する、例えばコンテンツを配信するか又はコンテンツを受信する。スケジュールは、ユーザの要求に応答してコンテンツの配信の開始を最小化するよう修正されてよい。スケジュールは、コンテンツの後続の部分の配信をできる限り遅くまで遅延し、後続の要求がコンテンツ・ストリームを共有するとともに、ユーザにより指定された許容可能な待ち時間パラメータを超過しないよう修正されてもよい。

Description

本発明は一般にネットワーク通信に関し、より詳細にはネットワークを介したビデオ情報のようなコンテンツの通信に関する。

サーバの帯域幅は、ビデオオンデマンド（ＶＯＤ）システムのようなユーザ要求に応答してコンテンツを通信する大規模システムにおいて主要な隘路として知られている。チャネルをクライアント毎に専用にすることは、サーバの帯域幅を瞬く間に使い切ってしまい、拡張性に欠ける。サーバの帯域幅を保つために、多くのユーザはマルチキャストを用いてチャネルを共有しうる。

マルチキャストには２種類がある。つまり、周期的なブロードキャストと非周期的なマルチキャストである。周期的なブロードキャスト環境では、サーバは、サービス要求を待たない。サーバはコンテンツを循環的にブロードキャストする。ビデオ・コンテンツの場合、循環的ブロードキャストは、真のＶＯＤを保証しない。循環的ブロードキャストは、特定の限度の範囲内で任意のクライアントが最悪のサービス待ち時間を経験するよう保つ。実際に、帯域幅の要件は、システムの加入者数とは独立である。しかしながら、周期的ブロードキャストの利点は、人気のあるビデオのような頻繁に要求されるコンテンツに限られる。

あまり人気のない、頻繁に要求されないコンテンツの場合には、非周期的なマルチキャストを用いることができる。非周期的なマルチキャストの環境では、ユーザは、サーバにコンテンツを要求し、サーバは当該コンテンツをあるスケジューリング・ポリシーに従い提供する。パッチングと称される技術は、新たに入来する要求が、現行のマルチキャストに加わることを可能にし、同一のデータ・ストリームを活用する。非周期的マルチキャストの手法は、真のＶＯＤサービスを提供しうる。

しかしながら、これらの手法は、パッチング技術を採用する手法も含め、真のＶＯＤサービスを提供するが、一方で大きなデータ・バーストの影響受けうる。

本発明のある態様は、既存のコンテンツ配信システムが、望ましくないデータ・バーストの影響を生じるというような問題のある特徴を有するという認識を含む。本発明の別の態様は、コンテンツを通信する方法を含む。当該方法は：コンテンツの要求を受信する段階；該コンテンツを配信するスケジュールを生成する段階；該スケジュールが前記要求の遅延パラメータを満たすか否かを決定する段階；該遅延パラメータを満たすという決定に応答して、前記コンテンツの一部の配信を遅延させるよう、前記スケジュールを修正する段階；を有する。前記スケジュールを修正する段階は：前記コンテンツを配信するために帯域幅が利用可能な、前記スケジュールの第１の時間間隔を検出する段階；及び前記コンテンツの一部の配信を遅延させ前記時間間隔中に生じるようにするために、前記スケジュールを調整する段階；を更に有してよい。要求は、クライアント装置から受信され、前記遅延パラメータは該クライアント装置のユーザにより設定された遅延限度を有してよい。前記スケジュールは複数の時間間隔を有し、該複数の時間間隔は前記コンテンツの一部の配信が配信のためにスケジューリングされる第１の時間間隔を有し、前記コンテンツは複数の情報ブロックを有し、前記一部は該複数の情報ブロックの中の第１のブロックを有し；前記スケジュールを修正する段階は：前記第１の時間間隔中に前記コンテンツの一部を配信するために、追加の帯域幅が必要であると決定する段階；前記第１の時間間隔の後の、追加の帯域幅が利用可能な第２の時間間隔中に生じるよう、前記第１のブロックの送信を遅延させる段階；及び前記第１の時間間隔から前記第２の時間間隔までの遅延により生じる送信の遅延が、前記遅延パラメータと関連付けられた遅延限度を超えているか否かを決定する段階；を有してよい。

本発明の別の態様は、コンテンツを配信する方法を含む。当該方法は：コンテンツの要求を受信する段階；該コンテンツの初期部分を第１の遅延を以て、該コンテンツの後続の部分を第２の遅延を以て、該コンテンツを配信するスケジュールを生成する段階；を有し、該スケジュールを生成する段階は、前記要求の受信から前記コンテンツの初期部分の配信までの時間を最小化するよう、前記第１の遅延を選択する段階及び前記要求と関連付けられた遅延パラメータを満たし、前記後続の部分の配信の遅延を増大させるよう、前記第２の遅延を選択する段階、を有してよい。

本発明の別の態様は、コンテンツを受信する方法を含む。当該方法は：コンテンツ・プロバイダーからコンテンツを受信する段階；該コンテンツ・プロバイダーへ配信遅延限度を提供する段階；前記コンテンツの初期部分の配信を開始する第１の時間と前記コンテンツの後続の部分の配信を開始する第２の時間とを有するスケジュールに従い、前記コンテンツを受信する段階；を有し、前記第１の時間は、前記要求の受信から前記コンテンツの初期部分の配信の開始までの遅延を最小化し、前記第２の時間は、前記配信遅延時間を満たすとともに前記コンテンツの後続の部分の配信の開始の遅延を増大させてよい。 本発明の別の態様は、コンテンツを配信するシステムを含む。当該システムは：コンテンツの要求装置から要求を受信し、該要求装置から遅延パラメータを受信するインターフェース；該インターフェースと結合され、前記要求に応答してスケジュールに従い前記要求装置へ前記コンテンツを配信するスケジューラ；を有し、該スケジューラは、前記コンテンツの一部の配信を遅延させるよう、前記要求装置の遅延パラメータに応じて前記スケジュールを修正し、前記遅延パラメータが満たされると決定してよい。

本発明の別の態様は、コンテンツを配信する方法を含む。当該方法は：コンテンツの要求を受信する段階；該要求に応答して前記コンテンツを配信するスケジュールを生成する段階；及び前記コンテンツを送信する遅延時間を示すメッセージを送信する段階；を有してよい。当該方法は、前記スケジュールが前記要求の遅延パラメータを満たすか否かを決定する段階を更に有し、前記スケジュールが前記遅延パラメータを満たさない場合、前記メッセージは前記要求が拒否されたことを示す。

本発明は、以下の詳細な記載を添付の図面と関連して読むことにより明らかである。

本発明の原理を組み込んだ、１又は複数のユーザからの要求に応答してコンテンツを通信するシステムを、ブロック図の形式で示す。 本発明の原理に従うコンテンツ通信のスケジューリングに関する図１のシステムの態様を、フローチャートの形式で示す。 図２のフローチャートに従うコンテンツ通信のスケジューリングのための、図１のシステムの動作の態様を説明するタイミング図を示す。 図２、３のコンテンツ通信のスケジューリングのための、図１のシステムの動作を更に説明するタイミング図を示す。 本発明の原理に従うコンテンツ通信のスケジューリングに関する図１のシステムの態様を、フローチャートの形式で示す。

図及び関連する説明の理解を実現するために、種々の図面を通じて、同一又は同様の特徴には同一の参照符号を用いる。理解されるべき点は、図面は、本発明の態様、特に本発明の例である実施例を説明することを目的としていることである。本発明の原理を組み込んだシステムの他の構成及び実施例も可能である。

説明を簡単にするために、以下では、ビデオオンデマンド・システム又はＶＯＤにおける、本発明の原理の例である実施例を説明する。しかしながら、本発明は、コンテンツ源とユーザとの間でコンテンツを通信する種々のシステムに広く適用可能である。本願明細書に記載される本発明の原理は、ビデオ及び／又はオーディオを含むがこれらに限定されないあらゆる種類のコンテンツを配信し及び／又は受信するシステムに適用可能である。

また、コンテンツは、種々の通信媒体及び素子を含む種々の種類の通信ネットワークを介して通信されてよい。例えば、本発明の原理は、コンテンツを電話機（例えば固定電話機又は携帯電話機のような無線電話機）、セットトップボックス、テレビ、コンピューター等を含む装置に提供する有線及び無線通信ネットワーク（例えばＣＡＴＶ、携帯電話ネットワーク、衛星システム等）に適用可能である。また、本発明のある態様は、コンテンツ格納機能、及び／又は個人向けビデオ・レコーダー（ＰＶＲ）のような機能を有するシステムに関する。例えば、ＰＶＲのような格納機能の能力は、以下に説明するように、再生に必要になるまで受信したデータをバッファリングすることにより、早くからいるクライアントにメディア・データを配信しているマルチキャスト・ストリームに後から来たクライアントが参加することを可能にする。

本願明細書に記載する本発明の原理を組み込んだシステムの他システムの例である実施例は、ＶＯＤサービス・モード、及びマルチキャスト伝送をスケジューリングする関連方法を含む。記載するＶＯＤシステムは、システムのユーザ、顧客、又はクライアントに、コンテンツを識別するリスト、例えばビデオの名称のリスト、及び個々の最も早い再生時間を提供してよい。再生が可能な時間に関する情報を提供することは、例えば提供されたリスト内のコンテンツ・アイテムの１つを要求することにより又は許容遅延を特定する情報を動作の設定モード中のような別個の通信でサーバに提供することにより、コンテンツを要求する各エンティティ、例えば顧客、クライアント、又はユーザが、要求者の選択する又は認容可能な又は許容遅延を特定する遅延パラメータ又は遅延限度を設定することを可能にする。顧客から要求を受信することにより、システムは、要求を受け付けるか否かを、利用可能なネットワークの帯域幅及びユーザの許容遅延によって決定する。

例えば、図１は、ＶＯＤサーバ１１０を有する例であるＶＯＤシステムのブロック図を示す。ＶＯＤサーバ１１０は、図１で概して１３０、より詳細には１３１、１３２、１３３、１３４で識別される種々のクライアント・システムにネットワーク１２０を介してサービスを提供する。図１に示すクライアント・システムは、マルチメディア装置、パーソナル・コンピューター、セットトップボックス、テレビ等のような種々の可能な装置を表す。ユーザ１４０は、コンテンツをサーバ１１０から、クライアント・システムの１つ、例えばクライアント１３２を介して要求する。

本発明のある態様によると、サーバ１１０は、利用可能なコンテンツ及び最も早い再生時間のリスト１５０をユーザ１４０へクライアント１３２を介して提供する。ユーザ１４０は、要求１６０をクライアント装置１３２を介して提出し、リストされたコンテンツ・アイテムの１つを要求する。

本発明の別の態様によると、ユーザ１４０は、コンテンツを受信するためにユーザが選択する又は許容可能な遅延であると思う遅延値を識別又は特定する遅延パラメータ又は遅延限度を指定する。つまり、ユーザは、ユーザが認容可能な遅延限度又は最大遅延を指定してよい。許容遅延のこのような指定は、コンテンツの要求の一部として又は許容遅延パラメータが定められる動作の設定モード中に提供されてよい。

或いは、サーバ１１０は、許容遅延、例えば既定値を提案し、ユーザ１４０はクライアント装置１３２のユーザ・インターフェース（例えば表示された設定メニュー）を介して当該値を承諾するか、拒否するか、修正してよい。

図１に示すシステムは、例えばサーバ１１０内に、クライアント装置１３０のような要求装置からのコンテンツ要求を受信するインターフェース、及び例えばサーバ１１０内に、インターフェースと結合された、スケジュールに従いコンテンツを配信する要求に応じるスケジューラ、を有する。図１のサーバ１１０内のスケジューラにより構築された、コンテンツをクライアントへ提供又は送信するための送信スケジュールは、ＶＯＤ要求の到着に従い準備される。システムにより受理された各要求は、スケジュールされたコンテンツのストリームに対応する。スケジュールの目的は、最も早い時間に各要求にコンテンツへアクセスさせ（例えば要求したビデオの閲覧）、当該コンテンツを連続的に再生させることである。

本発明のある態様によると、ビデオのようなコンテンツは、コンテンツ・データ又は情報の複数のブロック又は部分に分割される。コンテンツのストリームは、特定のコンテンツ・アイテムの全ての部分又はブロックを提供する。ストリーム毎に、送信スケジュールは、コンテンツ、例えばビデオの最初の又は初期部分又はブロックを、帯域幅が利用可能となった後、直ちに送信し、コンテンツの連続したブロック又は後続の部分をできる限り遅くに、しかし最初のブロックからの時間オフセットよりも遅れずに送信し、コンテンツがユーザに対して連続的に又は少なくとも許容できない中断を有さずに再生されるようにする。例えば、ビデオ・コンテンツの場合、送信スケジュールは、ビデオが円滑に再生し続けるように、ビデオ・コンテンツの送信のために提供される。

本発明の別の態様によると、スケジューラは、例えば以下に説明するようにスケジュールを再構成することにより、スケジュールを修正又は採用してよい。例えば、スケジュールは、コンテンツの一部の配信を遅延させるために、ユーザが指定した許容遅延のような遅延パラメータ又は遅延限度に応じて修正されてよい。遅延は、ストリーム内のブロックの送信をできる限り遅くに遅延させ、利用されているコンテンツの送信されたブロックが複数の要求に供する可能性を増大させる。つまり、ビデオに対する第１の要求に続いて、同一のビデオに対する第２の要求が受信された場合に、第１の要求に応じたブロックの送信は、第２の又は他の続いて生じる要求に供するために用いられてもよい。上述のような配信を遅らせるためのスケジューラによるスケジュールの修正は、遅延が遅延パラメータを満たすと決定された後に生じる。コンテンツを円滑に再生するためには更なる考慮が必要である。

詳細には、例であるＶＯＤシステムは、２つの主要な構成要素、つまりＶＯＤサーバ１１０及びクライアント１３０を有する。ＶＯＤサーバ１１０は、ビデオの名称と最も早いアクセス時間とを有する、ビデオの再生リストを発行する。最も早いアクセス時間は動的に更新される。クライアントがビデオに興味があるときはいつでも、クライアントは、ビデオの名称及びユーザの許容遅延のような情報が含まれる要求を作成する。要求を受信した後に、ＶＯＤサーバは、当該要求を受け付けるか否かを、利用可能な帯域幅及びユーザの許容遅延によって決定する。要求が受け付けられる場合、再生遅延は、確認応答情報に含まれてよい。要求が拒否される場合、最小可能再生遅延が、確認応答情報に含まれてよい。クライアントは、最小可能再生遅延に基づき、必要に応じて別の適当な要求を作成できる。

図２に、送信のスケジューリングの例である実施例を、フローチャートの形式で示す。図２に示す実施例は、ソフトウェア（例えば、コンピューター、又はマイクロプロセッサー、コントローラー、又は信号処理集積回路により実行される）、及び／又はハードウェアで実施されてよい。図２では、スケジューリングは段階２００で開始する。段階２００の次に段階２１０がある。段階２１０で、１又は複数のクライアントがコンテンツの要求を生成するか又はサーバが当該コンテンツの要求を傾聴又は受信する。以下に詳細に説明するように、要求が到着すると、システムは、先ず当該要求のためのストリームをスケジュールし、次に必要に応じて複数の要求に関連するストリームを結合してよい。

図２の態様を説明する目的で、特定の用語が以下のように用いられる。用語「ブロック」は、コンテンツ・アイテムの部分又はサブセットを表すために用いられる。ビデオのようなコンテンツでは、ビデオは、例えば各ブロックが等しい大きさを有する、Ｎ個の部分又はブロックに論理的に分割される。ブロックの大きさは、スケジュールの精度を決定する。

「ストリーム」は、ビデオのようなコンテンツ・アイテムを表す送信された一連のブロックを表す。ビデオの要求のようなコンテンツの要求が到着すると、システムは要求に対してストリームをスケジューリングする。スケジュールされたストリームは、いつ及びどのブロックが送信されるかを表す。各要求はスケジュールされたストリームに対応する。

ビデオの「送信期間」は、（最初のビデオの要求に対する）最初のストリームの送信が開始したときに開始する。送信期間は、ビデオの全ての存在するストリームが終了する前に、如何なる要求も到着しない場合に、終了する。新たな送信期間は、最後の送信期間が終了した後にビデオの要求が到着した場合に開始する。

「基準ストリーム」は、送信期間内の最初のストリームである。送信期間には正確に１つの基準ストリームがある。

「タイムスロット」は、ビデオ・ブロックの継続期間のタイム・スパン、つまりコンテンツのブロックが伝達される時間間隔である。同一のタイムスロット内のビデオ・ブロックは、同一の時間に送信される。各タイムスロットは、タイムスロットの「容量」として表される、特定の数のビデオ・ブロックを有する。特定のスケジュールを実施するために、タイムスロットがその容量より多くのブロックを有しなければならない場合、タイムスロットは、「過負荷タイムスロット」として表される。つまりタイムスロットは如何なる利用可能な帯域幅も有さない。タイムスロットが余分な容量を有する場合、つまり特定のスケジュールがタイムスロットにその容量より少ないブロックを有することを要求し、従ってタイムスロットが余分な又は利用可能な帯域幅を有する場合、タイムスロットは「不足負荷タイムスロット」として表される。

図３は、上述の用語の特徴を説明する、２つの送信期間のタイミング図を示す。図３のコンテンツでは、ブロックの総数は２０である。送信期間１には、２つのストリームＳ０、Ｓ１がある。送信期間２には、３つのストリームＳ２、Ｓ３、及びＳ４がある。Ｓ０は、送信期間１の基準ストリームである。Ｓ２は、送信期間２の基準ストリームである。基準ストリームのみが、全てのＮ個のブロックを望ましくは連続して送信する。基準ストリームの最初のブロックは基準時間ゼロを有し、他の全てのブロックは最初のブロックからの再生時間オフセットと等しい基準時間を有する。所与の時間に１つのブロックを送信しているように図示したが、本発明の原理は、複数のブロックが所与のタイムスロットで同時に送信される場合にも適用できる。

上述の用語に加え、本願明細書の記載は、以下の記号を用いる。
Ｎは、ビデオの総ブロック数を表す。
Ｂは、サーバの帯域幅の限度を表す。
ｂは、ビデオの再生レートを表す。
ｄ_ｉは、ｉ番目の要求のサービス遅延を表す。（送信遅延は無視される。つまりビデオがＴ_ｉで送信された場合、当該ビデオはＴ_ｉで表示でき、従ってサービス遅延は関連するサーバの帯域幅の限度である。）
Ｄ_ｉは、ｉ番目のユーザが許容できる最大サービス遅延を表す。a_iは、送信期間内のｉ番目の要求の到着時間を表す（ｉ＝０、１、２、．．．）。
ｔ_ｉｊは、送信期間内のｉ番目のストリームの中のｊ番目のブロックの送信の開始時間を表す。ａ_ｉ及びｔ_ｉｊの精度は、ブロックの期間である。ａ_０＝０、ｔ_００＝０、つまり第１のストリームの最初のブロックは、基準時間ゼロを有する。
Ｔ_ｉは、ｉ番目のストリームの送信時間を表す。Ｔ_ｉ＝ａ_ｉ＋ｄ_ｉ
図４は、本発明の態様による、スケジューリングを提供する例である実施例の動作例を示す。図４では、小さい○は要求を表す。実線の上の数字は、ビデオ・ブロックの指数を表す。全部で２０個のブロックがビデオに含まれる。サーバの帯域幅は、ビデオ・レートの３倍である。Ｒ_ｉは、ｉ番目の要求を表す。Ｓ_ｉは、ｉ番目のストリームを表す。

送信期間内の最初の要求に対し、スケジューラは、Ｎ個の全てのブロックを従来のＶＯＤシステムでのように連続して送信するために、最初の要求Ｒ_０の到着時間であるＴ_０で開始する基準ストリームを生成する。ｋ番目の要求が到着すると、システムは、ｋ番目の要求のために、Ｓｋにより表されるストリームをスケジューリングする。スケジュール手順の詳細を、図２及び図４に関連して以下に説明する。要求、例えばｋ番目の要求を受信した後、図２の段階２１０として、初期の又は初めのスケジュールが図２の段階２２０として示されるように作成される。システムは、［ａ_ｋ−１，ａ_ｋ］で送信されているブロックを送信するようスケジューリングする。

他のブロックは、要求しているクライアントに利用可能である。何故なら、当該他のブロックは、先行する要求に応答して存在しているストリームにより送信されるからである。全てのブロックは、最初のブロックからの当該ブロックの時間オフセットで送信されるようスケジューリングされる。サーバは、ｋ番目のストリームＳ_ｋのブロックの送信時間を示す初期スケジュールＵ_ｋを作成する。Ｕ_ｋは次式で表される。
Ｕ_ｋ＝｛ｕ_ｋ１，ｕ_ｋ２，．．．，ｕ_ｋｙ｝
ここでｕ_ｋｉは、ｋ番目のストリームの中のｉ番目のブロックの予定送信時間である。ｋ番目のストリームの中のｉ番目のブロックは、必ずしも要求されたビデオ又はコンテンツのｉ番目のブロックではない。

図２の段階２３０で、初期スケジュールの生成に続き、帯域幅が利用可能なタイムスロット又は時間間隔を検出するために帯域幅の検出が実行される。時点ａ_ｋから、帯域幅が帯域幅の限度を上回っているタイムスロットのセットは、Ｈとして表される。ここでＨ＝｛ｈ_１，ｈ_２，．．．，ｈ_ｍ｝である。各ｈ_ｉは、２つの属性を有する。つまりｈ_ｉ＝｛ｈ_ｉ１，ｈ_ｉ２｝である。ここでｈ_ｉ１は、タイムスロットの開始時間を表し、ｈ_ｉ２は、当該タイムスロット内のｉ番目のストリームのブロック数を表す。ｈ_ｉ１は、過負荷タイムスロットとして参照され、ｈ_ｉ２は、過剰ブロックとして参照される。ｈ_ｉ（ｉ＝１，２，．．．，ｍ）は、ｈ_ｉ１の昇順に順序付けられる。

時点ａ_ｋから、帯域幅が帯域幅の限度を下回っているタイムスロットのセットは、Ｌとして表される。ここでＬ＝｛ｌ_１，ｌ_２，．．．，ｌ_ｗ｝である。各ｌ_ｉは、２つの属性を有する。つまりｌ_ｉ＝｛ｌ_ｉ１，ｌ_ｉ２｝である。ここでｌ_ｉ１はタイムスロットの開始時間を表し、ｌ_ｉ２は占有されている帯域幅と帯域幅の限度との間の差分を表す。ｌ_ｉ（ｉ＝１，２，．．．，ｗ）は、ｌ_ｉ１の昇順に順序付けられる。

本発明のある態様によると、図２の段階２４０で、帯域幅検出の結果が評価される。例えば、段階２４０は、Ｈを評価する段階を有してよい。Ｈがヌルである（つまり、図２の段階２４０で否定的又は「Ｎｏ」という結果を得た）場合、利用可能な帯域幅は、初期スケジュールを修正しなくとも、ストリームの送信に適している。その場合、図２の動作は、段階２５０に進む。

段階２５０で、初期スケジュールが確認され、当該スケジュールに従い直ちに送信が行われる。段階２４０でＨがヌルでない場合、スケジュールの修正は、本発明の態様による再構成を含み、図２の段階２７０で行われてよい。

再構成の前に、段階２６０で、再構成を行う必要のある遅延が、要求元の能力の範囲内か否か、つまりユーザの指定した遅延パラメータ又は遅延の限度を満たしているか又はそれらに従っているか否かについて、評価が行われる。

評価が否定的な結果であった場合、段階２８０で要求が拒否される。遅延が許容可能な場合、スケジュールの修正又は再構成は、段階２７０で、以下に説明されるように実行される。

段階２５０の間、スケジュールされたストリームｋは、時間Ｔ_ｋで送信される。ここで、Ｔ_ｋ＝ａ_ｋである。これは、ｋ番目の要求のサービス遅延がゼロであることを意味する。ブロックの送信時間は、Ｖ_ｋ＝Ｕ_ｋ＝｛ｕ_ｋ１，ｕ_ｋ２，．．．，ｕ_ｋｙ｝である。例えば、図４で、要求２が到着したとき、利用可能な帯域幅はストリームを送信するのに十分である。従って、ストリーム２は、［ａ_１，ａ_２］で遅延なく送信されているブロックを送信する。また、ストリーム２の最初のブロックは、時間Ｔ_２で送信される。ここでＴ_２＝ａ_２である。

図２の段階２４０での評価が、帯域幅は初期スケジュールに対応するために適当でないと示す場合、初期スケジュールの修正は、段階２７０で行われる。本発明のある態様によると、スケジュールの修正又は再構成は、帯域幅のバーストを平坦化し、元のスケジュールに近いものに保つ。再構成の後、Ｔ_ｋ＞ａ_ｋである。必要な遅延ｄ_ｉが待ち時間許容値Ｄ_ｉの範囲内である場合、要求は受理され、ビデオ・ブロックは再構成された結果であるスケジュールに従い送信される。その他の場合、段階２８０で、要求は拒否され、最も早い可能な開始時間が要求元へ返送される。

段階２７０のようなスケジュール調整又は再構成の例である実施例を以下に説明し、図５に詳細に示す。スケジュールの修正又は再構成のある特徴は、最小初期遅延を生成することであってよい。別の特徴は、現在の要求のために送信されるコンテンツが、後の要求によっても共有される程度を最大化することであってよい。一つには、記載された実施例により提供される共有の増大は、ブロックをできる限り遅くに送信すること、一方でユーザにより示された遅延許容値に従い当該送信を行うことに起因する。

スケジュールの修正の第１の段階は、不足負荷タイムスロットの集合Ｇの決定である。ＧがＬから生成され、Ｇ＝｛ｇ_１，ｇ_２，．．．，ｇ_ｎ｝、

及び２はＬ内の要素数であるとすると、Ｇは次式のように生成されうる。
ｇ_１＝ｌ_１１
ｇ_ｉ（ｉ＝２，３，．．．，ｎ）は次式に従い生成される。

次に、Ｇのｍ個の要素は、集合Ｑのために選択される。ここで

である。ｍはＨの要素数である。

次に、Ｑ_ｉは次式（１）が成立するように、Ｑから選択される。

ここでｈ_ｉ２はｑ_ｉｊで送信されるようスケジューリングされる。

次に、ｋ番目のストリームのためにスケジュールされた全てのブロックは、シーケンスの昇順で再順序づけされる。ブロックの送信時間は、Ｖ_ｋ＝｛ｖ_ｋ１，ｖ_ｋ２，．．．，ｖ_ｋｙ｝である。従って、再生時間の遅延は次式に等しい。

必要な遅延がユーザの待ち時間の許容範囲内である場合、つまり遅延パラメータ又は遅延限度が満たされている場合、システムはビデオ・ブロックをスケジュールされた通りに送信する。必要な遅延が待ち時間の許容範囲を超えている場合、つまり遅延パラメータ又は遅延限度が満たされていない場合、要求は拒否され、最も早い可能な開始時間が要求元へ返送される。

例えば、図４で、要求３が到着すると、利用可能な帯域幅はストリームの送信に十分ではない。また、最も早い開始時間はＴ_３である。従って、ストリーム３は、［ａ_２，ａ_３］で遅延なく送信されているブロックを送信する。また、ストリーム３の最初のブロックは、時間Ｔ_３で送信される。ここでＴ_３＝ａ_３である。

本発明の別の態様は、適切な不足負荷タイムスロットの選択、つまり帯域幅が利用可能な適切な時間間隔の決定を含む。図５を参照し、以下に適正な不足負荷タイムスロットを選択し、スケジュールを修正又は調整して再構成を提供する例である実施例を説明する。図５の段階２１０から２５０は、図２の同様に示された段階に対応する。上述のように、初期スケジュールの調整中に考慮すべき事項には、以下の条件の一方又は両方を満たすことが含まれてよい。
条件１：最小の初期遅延を提供する。
条件２：例えばブロックをできる限り遅くに送信することにより、特定の要求に対するコンテンツの送信を、後の要求と最大限に共有する。
つまり、条件１によると、スケジュールは、最小の初期遅延を提供する、コンテンツの初期部分の配信を開始する第１の時間を含む。更に、条件２によると、スケジュールは、第２のブロックのようなコンテンツの後続の部分の配信を開始する第２の時間を含む。これは、遅延パラメータ又は遅延限度を満たしながら、後続の部分の配信の遅延をできる限り遅くになるよう増大させる。

両条件を満たすシステムを提供する例である実施例は、先ず条件１を考慮し、次に第１の条件が満たされると第２の条件を考慮する。最小の初期遅延を提供するという第１の条件を満たすことを、スケジュール修正の第１のパスと表す。第１のパスの間、２つの処理が行われる。つまり、不足負荷タイムスロットの選択とブロックのシフトである。

最小の初期遅延、つまり遅延許容範囲内であることを達成するために、図５の段階５６０のように、最も早い利用可能な不足負荷タイムスロットが、過負荷ブロックを含むよう選択される。つまり、スケジュールされているストリームの過負荷ブロックの総数がｍである場合、Ｌから最初のｍ個の不足負荷タイムスロットを選択すべきである。次に、過負荷ブロックは、それぞれｍ個の選択した不足負荷タイムスロットへシフトされる。つまりコンテンツの一部が遅延される。

シフト又は遅延は以下ように行われる。（タイムスロットｈ_ｉ１の）過負荷ブロックｈ_ｉ２を不足負荷タイムスロットｌ_ｊ１へ移動する必要がある場合、２つの場合を考慮する。場合１、つまりｌ_ｊ１＜ｈ_ｉ１の場合、ｌ_ｊ１の直ぐ隣のタイムスロットにあるブロックはｌｊ１へ移動され、代わりに（ｌ_ｊ１，ｈ_ｉ１）間の全てのブロックは自身の直前のタイムスロットへ移動され、（タイムスロットｈ_ｉ１の）ブロックｈ_ｉ２はｈ_ｉ１の直前のタイムスロットへ移動される。場合２、つまりｌ_ｊ１＞ｈ_ｉ１の場合、ｌ_ｊ１の直前のタイムスロットにあるブロックはｌｊ１へ移動され、代わりに（ｈ_ｉ１，ｌ_ｊ１）間の全てのブロックは自身の直ぐ隣のタイムスロットへ移動され、（タイムスロットｈ_ｉ１にある）ブロックｈ_ｉ２はｈ_ｉ１の直ぐ隣のタイムスロットへ移動される。

次に、最小の初期遅延ｄを決定する。初期スケジュールの後のブロックの送信時間をＵ＝｛ｕ_１，ｕ_２，．．．，ｕ_ｙ｝と表し、第１のパスの再スケジュールの後のブロックの送信時間をＶ＝｛ｖ_１，ｖ_２，．．．，ｖ_ｙ｝と表す。すると、最小遅延ｄは次のように決定される。

次に、段階５６１で、最大遅延を調べ、最大遅延が許容範囲内であるかどうか、つまりスケジュールが遅延パラメータ又は遅延限度を満たすかを決定する。否定的な結果であった場合、段階５８０で要求が拒否される。最小遅延が許容できる場合（つまり許容範囲内であるか、遅延パラメータ又は遅延限度を満たす場合）、データ共有を最大化する第２の条件を考慮するために、スケジュールの第２のパスが行われる。つまり、遅延パラメータを満たすと決定されると、第２のパスが行われ、スケジュールを修正し、コンテンツの少なくとも一部の配信を遅延させる。第１のパスの後、スケジュールの最小初期遅延Ｄ_ｍｉｎが決定され、段階５６２で、初期にスケジュールされたストリームはＤ_ｍｉｎの範囲内で遅延される。次に、段階５６３で帯域幅の検出が行われ、全ての過負荷ブロックと全ての不足負荷タイムスロットが見付けられる。段階５６４で、最後の過負荷ブロックから最初の過負荷ブロックまで、シフトが行われ、過負荷ブロックを、該過負荷ブロックの現在の位置より前に位置し且つ該現在の位置への最短距離を有する不足負荷タイムスロットへそれぞれ移動する。このシフト又は遅延又は再配置を、以下に詳細に説明する。

初期スケジュールをＤ_ｍｉｎの範囲内で遅延した後、過負荷ブロック毎に、過負荷タイムスロットの前に位置する少なくとも１つの不足負荷タイムスロットを見付け、過負荷ブロックを「保つ」ことが常に可能である。これは以下のように行われる。

先ず、初期スケジュールをＤ_ｍｉｎの範囲内で遅延することにより、ストリームが最大初期遅延を有しスケジューリングされる。つまり、ｋ番目のストリームに対し、［ａ_ｋ−１，ａ_ｋ］で送信された全てのブロックは、最初のブロックからの該ブロックの時間オフセットにＤ_ｍｉｎを加算して送信されるようスケジューリングされる。ブロックの送信時間は、Ｕ_ｋ＝｛ｕ_１＋Ｄ_ｍｉｎ，ｕ_２＋Ｄ_ｍｉｎ，．．．，ｕ_ｙ＋Ｄ_ｍｉｎ｝と表される。

次に帯域幅の検出が行われる。スケジュールを遅延した後、タイムスロットの帯域幅が変更される。従って、全ての過負荷ブロックと全ての不足負荷タイムスロットを見付けるために、帯域幅の検出を再び行う必要がある。

次に、スケジュールされたブロックが再構成される。再構成は、第１のパスのスケジュールと同様である。再構成も２つの処理を有する。つまり、不足負荷タイムスロットの選択とブロックのシフトである。過負荷ブロックを含めるためにどの不足負荷タイムスロットが選択されるかを決定するために、「後ろ」から「前」へ向かって選択が行われる。つまり、先ずどの不足負荷タイムスロットが（時間軸上での）最後の過負荷ブロックを含むかを決定し、次にどの不足負荷タイムスロットが（時間軸上での）最後から２番目の過負荷ブロックを含むかを決定し、以下同様である。（タイムスロットｈ_ｉ１にある）過負荷ブロックｈ_ｉ２に対し、ｈ_ｉ２を含む不足負荷タイムスロットｌ_ｊ１は次のように決定される。

Ｌ_{ｉｐｒｉｏｒ}は、ｈ_ｉ１の前にある（ｈｉ１より小さい）全ての不足負荷タイムスロットの部分集合である。つまり、不足負荷タイムスロットｌ_ｊ１は、ｈ_ｉ１の前にある全ての不足負荷タイムスロットの中で、ｈ_ｉ１への最短距離を有する。

第２のパスのスケジュールのブロック・シフトは、第１のパスのスケジュールのブロック・シフトと同じである。しかしながら、選択した不足負荷タイムスロットは過負荷タイムスロットの前にあり、従って第２のパスのブロック・シフトは場合１だけしか有さないので、場合１のみが存在する。

本発明の別の態様は、図５の段階５９０として、ストリームを結合した後に１又は複数の要求が１つのストリームに対応するような、コンテンツ・ストリームの結合を有する。ストリームの結合は次のように行われる。現在の要求時間が前のストリームの送信開始時間より前である場合、現在のストリームは前のストリームと結合される。結合の結果、２つの要求に対してサービスを提供する１つのストリームを生じる。例えば、要求５が到着すると、要求５のために十分な資源がないので、ストリーム５の最も早い送信開始時間はＴ_５にスケジューリングされる。要求５は待ち時間モード（ｌａｔｅｎｃｙ ｍｏｄｅ）でサービスを提供される。待機時間中、要求５は、マルチキャスト・データを受信し、バッファに格納する。次に、要求５の開始時間より前の、つまりｔ_５＞ａ_６である（ブロック持続時間の精度が用いられる場合には、ｔ_５＝ａ_６である）要求６が到着する。従って、要求５は要求６と結合されてよい。結合した後、新たなストリームＳ５はスケジュールされ、要求５と要求６の両方に対応する。図４から、期間［ａ_５，ａ_６］中に到着した全ての要求は、１つのストリームに結合されることが分かる。

段階５６５で、ストリームは、スケジュールに従ってクライアントへ送信される。ストリームをクライアントへマルチキャストする幾つかの方法がある。ある方法は、コンテンツのユーザ要求毎に独自にストリームをマルチキャストする方法である。別の方法は、全てのユーザ要求に対し１回ストリームをマルチキャストする方法である。前者の方法の利点は、ユーザが興味のあるマルチキャスト・ストリームを申し込むだけでよく、関係のないストリームがユーザに届かないことである。後者の方法は、クライアント側で余分なデータをフィルターする必要がある。

本発明の上述の態様は、図４と関連して記載する例である実施例の以下の説明を読むことにより一層理解されるだろう。上述のように、例である実施例は、ビデオ・プログラムに対する複数の要求を処理するＶＯＤサーバを有する。サーバは、１つより多いビデオ・プログラムを格納できるが、記載される実施例は特に同一のビデオ・プログラムに対する要求に関連する。ビデオ・プログラムは、説明のためにＮ個のブロックに分割される。通信チャネルは、１つのタイムスロットで最大Ｍ個のブロックを送信できる。そして、各ブロックは１つのタイムスロットで送信されうる。図４では、Ｎ＝２０、Ｍ＝３である。クライアント装置が要求を提出すると、クライアント装置は、通信チャネル内の全てのビデオ・ブロックを集め、ビデオ・ブロックを適正な順序に並べ始める。要求されたビデオ・プログラムの全てのブロックを受信すると、クライアント装置は、要求したビデオ・プログラムの再生を開始しうる。

図４の例では、ストリームＳ０〜Ｓ５は、要求Ｒ０〜Ｒ６に応答して示される。Ｓ２は、ブロック０−４及び８−１２を、タイムスロット１３−１７及び２１−２５からそれぞれ送信し始める。Ｓ３は、ブロック０、１、５、６、１３及び１４を、タイムスロット１６、１７、２０、２１、２８、２９でそれぞれ送信し始める。Ｓ４は、ブロック０−４、７及び１５−１７を、タイムスロット１８−２２、２５及び３４−３６からそれぞれ送信し始める。Ｓ５は、ブロック０−６、８、９、１８及び１９を、タイムスロット２３−２９、３１、３２、４２及び４３からそれぞれ送信し始める。また、要求Ｒ５が到着したとき、図４に示したスケジュールの結果は、Ｓ５のブロック０がタイムスロット２３で送信を開始することを示す。しかし、要求Ｒ６はタイムスロット２３より前に到着するので、Ｓ５とＳ６は１つのストリームとして結合される。

クライアント装置０が時間ａ０又はタイムスロット０でビデオ・プログラムを要求すると（図４の要求Ｒ０）、サーバは、基準ストリームＳ０に対する初期スケジュールＵ０を作成する。ここで（０，１，２，．．．，１９）であり、ビデオのブロックｉがタイムスロットｉで送信されるようスケジュールされたことを示すビデオ・プログラムの如何なるブロックも通信チャネルで送信されていないので、２０個のブロックの全てが送信されなければならない。如何なる過負荷タイムスロットも存在しないので、初期スケジュールＵ０は、再構成されることなく最終スケジュールＶ０になる。サーバは各タイムスロットで３個のブロックを送信できるが、本実施例では、サーバは各タイムスロットで１つのビデオ・ブロックを送信する。ブロックはブロック０から開始するシーケンスで送信されるが、これは、各クライアント装置が全てのブロックを再生のために適正なシーケンスに再組立てできるので、必要ない。

サーバは要求０に応答してタイムスロット毎に１つのブロックを送信するので、各タイムスロット内の２つのブロックの帯域幅は、他の要求のために利用できる。

クライアント装置１は、時間ａ１又はタイムスロット８で要求（図４のＲ１）を提出し、通信チャネルでビデオ・ブロックを受信し始める。ブロック８−１９は通信チャネルで既に利用可能なので、サーバはブロック０−７だけを送信する。該ブロック０−７は、時間間隔［ａ０，ａ１］で送信される。サーバは、ストリーム１、つまりＳ１に対し、ブロック０−７のための初期スケジュールＵ１を（８，９，１０，．．．，１５）として作成する。如何なる過負荷タイムスロットも存在しないので、初期スケジュールＵ１は、再構成されることなく最終スケジュールＶ１になる。

時間ａ２又はタイムスロット１３で、クライアント装置２は、要求（図４のＲ２）を提出する。この時点で、通信チャネルは、ブロック５−７及び１３−１９を送信している。サーバは、ブロック１−４及び８−１２を送信するだけでよい。これらのブロックは時間間隔［ａ１，ａ２］で送信される。サーバは、ストリーム２（Ｓ１）に対しブロック１−４及び８−１２を送信するために初期スケジュールＵ２、つまり（１３，１４，１５，１６，１７，２１，２２，２３，２４，２５）を作成する。初期スケジュールでは、最初のブロックを送信する時間は、要求を受信した時間である。Ｓ２内の全てのブロックは、連続するタイムスロットで送信されるようスケジュールされてよい。しかしながら、送信チャネルの帯域幅管理の柔軟性を向上させるために、連続するブロックだけが連続するタイムスロットで送信されるよう初期スケジューリングされることが望ましい。２つの連続するブロック間でブロック番号が不連続である場合、例えばブロックｉとブロックｉ＋ｊで、ブロックｉが対応する初期スケジュール内でタイムスロットｋで送信されるようスケジュールされた場合、サーバは、ブロックｉ＋ｊがタイムスロットｋ＋ｊで送信されるようスケジューリングする。例えば、Ｕ２で、ブロック０−４は、タイムスロット１３−１７で送信されるようスケジューリングされるが、ブロック８−１２はタイムスロット２１−２５にスケジューリングされる。如何なる過負荷タイムスロットも存在しないので、初期スケジュールＵ２は、再構成されることなく最終スケジュールＶ２になる。

ここまでで、上述の説明は、各タイムスロットの帯域幅を超過しない、つまりタイムスロットが不足負荷タイムスロットである例に関するものであった。以下では、要求を受信したときに帯域幅が不十分な状況、つまり過負荷タイムスロットの状態を記載する。

この場合のスケジュールは次の通りである。
ストリーム０：Ｕ０＝Ｖ０＝（０，１，２，．．．，１９）、それぞれブロック０−１９に対応する。
ストリーム１：Ｕ１＝Ｖ１＝（８，９，．．．，１５）、それぞれブロック０−７に対応する。
ストリーム２：Ｕ２＝Ｖ２＝（１３，１４，１５，１６，１７，２１，２２，２３，２４，２５）、それぞれブロック０−４及び８−１２に対応する。

ａ３又はタイムスロット１５で、受信機３は、要求（図４のＲ３）を提出する。サーバは、間隔［ａ２，ａ３］で送信されるブロックを調べる。これらのブロックはストリーム３、つまりＳ３に含まれるべきである。これらのブロックは、ブロック０、１、５、６、１３及び１４であり、サーバはこれらのブロックを送信するために初期スケジュールＵ３、つまり（１５，１６，２０，２１，２８，２９）を作成する。しかしながら、Ｖ０−Ｖ２及びＵ３を調べた後、サーバは、タイムスロット１５が過負荷であるが、タイムスロット１７及びその先のタイムスロットが不足負荷であることを発見する。サーバは、Ｈリストを作成する。Ｈリストの各要素は、開始タイムスロット及び対応するオーバーフロー・ブロックの番号を示す。本例では、Ｈ＝｛（１５，０）｝である。

サーバは、Ｌリストも作成し、Ｒ３を受信したときより遅い時間のタイムスロットである不足負荷タイムスロットを把握する。Ｌリスト内の要素数ｗは、Ｈリスト内の要素数と少なくとも同じでなければならない。望ましくは、ｗはＶリスト内の最新のタイムスロット数とビデオ・プログラム内のブロック数との和である。この場合、ｗは２５＋２０＝４５である。しかしながら、簡単のため、本例では、ｗは、全帯域幅が利用可能な場合のｗに選択される。また、Ｌは本例は次の通りである。｛（１７，１），（１８，２），（１９，２），（２０，２），（２１，１），（２２，２），（２３，２），（２４，２），（２５，２）｝
{(１７,１),(１８,２),(１９,２),(２０,２),(２１,１),(２２,２),(２３,２),(２４,２),(２５,２)}
従って、ｗ＝９であり、Ｇ内の要素数ｎは１＋２＋２＋２＋１＋２＋２＋２＋２又は１６である。

Ｇを計算するとき、ｇ_１＝１７であることに留意する。Ｇの他の要素は、既に説明した次式から計算される。

従って、ｇ_２＝ｇ_３＝１８、ｇ_４＝ｇ_５＝１９、ｇ_６＝ｇ_７＝２０、ｇ_８＝２１、ｇ_９＝ｇ_１０＝２２、ｇ_１１＝ｇ_１２＝２３、ｇ_１３＝ｇ_１４＝２４及びｇ_１５＝ｇ_１６＝２５である。

Ｑを生成するときの添え字ｍは、Ｈリスト内の項目数を表す。本例では、ｍ＝１である。また、Ｑ内の要素数ｘは１６であり、Ｑは１６個のリスト、つまりＱ１−Ｑ１６を有する。各リストは１つの項目のみを有し、ｔｉ１＝ｇｉである。

次に、以下の式（１）は、Ｈリスト内の各要素の開始タイムスロットに時間的に最も近いｑ_ｉ１を選択するために用いられる。つまり、

本例では、ｑ１１＝１７が選択される。これは、ブロック０がタイムスロット１７で送信されることを意味する。ブロックを順序付けした後、Ｖ３＝（１６，１７，２０，２１，２８，２９）であり、ブロック０はタイムスロット１６で送信され、ブロック１はタイムスロット１７で送信される。ブロック５，６，１３，１４は元のスケジュールのままである。つまり、これらのブロックは、タイムスロット２０，２１，２８，２９でそれぞれ送信される。

この時点で、サーバは１つのタイムスロットの遅延時間を知っている。要求が最大で１タイムスロットの遅延時間を要求する場合、該要求は許可され、許可メッセージは遅延時間を有する。要求が１タイムスロットより少ない遅延時間を要求する場合、該要求は拒否され、メッセージは遅延時間を有する。従って、ユーザは更に長い待機時間を有する別の要求を提出しうる。

本願明細書に記載された原理の種々の変更及び／又は拡張が考えられる。例えば、ＶＯＤのようなアプリケーションのために、上述のシステムが適応され、更に多数のユーザに対応するために拡張可能である。上述のようなスケジュールの修正は、「適度」の定義がユーザにより指定されうる適度な待ち時間のサービスを複数のユーザへ提供することにより、複数の要求及びユーザの追加によるデータ・バーストの影響を低減又は平坦化するために用いられうる。

本発明は、個人向けビデオ・レコーダー（ＰＶＲ）を使用可能な顧客を有するＶＯＤシステムを含む種々のシステムに適用可能である。例えば、ＰＶＲが利用可能な場合、後から来たクライアントが、早くからいる複数のクライアントにメディア・データを配信しているマルチキャスト・ストリームに参加し、再生に必要になるまで受信したデータをバッファリングする。これにより、サーバの必要な帯域幅を低減できる。

本願明細書に記載したシステムは、顧客に、特定のコンテンツへの最も早いアクセス時間のような有用な情報を提供する。例えば、システムは、ビデオ名及び該ビデオ名の個々の最も早いアクセス時間のリストを提供してよい。最も早いアクセス時間は、ユーザがコンテンツに対する合理的な要求を作成するのに役立つ。

これにより、ユーザからの無意味な要求を回避し、システムの効率を向上しうる。上述のシステムは、要求の到着、現在利用可能な帯域幅及びユーザの許容可能な遅延に従い構成されたマルチキャスト送信スケジュールに従って動作する。システムは、サーバの帯域幅とサーバの待ち時間との間でトレードオフを行う。システムは、ストリームを動的に結合し、クライアントがデータを最適に共有することを可能にする。

Claims (9)

1. コンテンツを通信する方法であって：
   コンテンツの要求を受信する段階；
   該コンテンツを配信するスケジュールを生成する段階；
   該スケジュールが前記要求の遅延パラメータを満たすか否かを決定する段階；
   該遅延パラメータを満たすという決定に応答して、前記コンテンツの一部の配信を遅延させるよう、前記スケジュールを修正する段階；
   を有する方法。
2. 前記スケジュールを修正する段階は：
   前記コンテンツを配信するために、帯域幅が利用可能な、前記スケジュールの第１の時間間隔を検出する段階；及び
   前記コンテンツの一部の配信を遅延させ前記時間間隔中に生じるようにするために、前記スケジュールを調整する段階；
   を有する請求項１記載の方法。
3. 前記要求は、クライアント装置から受信され、前記遅延パラメータは該クライアント装置のユーザにより設定された遅延限度を有する、
   請求項２記載の方法。
4. 前記スケジュールは複数の時間間隔を有し、該複数の時間間隔は前記コンテンツの一部の配信が配信のためにスケジューリングされる第１の時間間隔を有し、前記コンテンツは複数の情報ブロックを有し、前記一部は該複数の情報ブロックの中の第１のブロックを有し；
   前記スケジュールを修正する段階は：
   前記第１の時間間隔中に前記コンテンツの一部を配信するために、追加の帯域幅が必要であると決定する段階；
   前記第１の時間間隔の後の、追加の帯域幅が利用可能な第２の時間間隔中に生じるよう、前記第１のブロックの送信を遅延させる段階；及び
   前記第１の時間間隔から前記第２の時間間隔までの遅延により生じる送信の遅延が、前記遅延パラメータと関連付けられた遅延限度を超えているか否かを決定する段階；を有する、
   請求項１記載の方法。
5. コンテンツを配信する方法であって：
   コンテンツの要求を受信する段階；
   該コンテンツの初期部分を第１の遅延を以て、該コンテンツの後続の部分を第２の遅延を以て、該コンテンツを配信するスケジュールを生成する段階；
   を有し、
   該スケジュールを生成する段階は、
   前記要求の受信から前記コンテンツの初期部分の配信までの時間を最小化するよう、前記第１の遅延を選択する段階；及び
   前記要求と関連付けられた遅延パラメータを満たし、前記後続の部分の配信の遅延を増大させるよう、前記第２の遅延を選択する段階、
   を有する、
   方法。
6. コンテンツを受信する方法であって：
   コンテンツ・プロバイダーからコンテンツを受信する段階；
   該コンテンツ・プロバイダーへ配信遅延限度を提供する段階；
   前記コンテンツの初期部分の配信を開始する第１の時間と前記コンテンツの後続の部分の配信を開始する第２の時間とを有するスケジュールに従い、前記コンテンツを受信する段階；
   を有し、
   前記第１の時間は、前記要求の受信から前記コンテンツの初期部分の配信の開始までの遅延を最小化し、前記第２の時間は、前記配信遅延時間を満たすとともに前記コンテンツの後続の部分の配信の開始の遅延を増大させる、
   方法。
7. コンテンツを配信するシステムであって：
   コンテンツの要求装置から要求を受信し、該要求装置から遅延パラメータを受信するインターフェース；
   該インターフェースと結合され、前記要求に応答してスケジュールに従い前記要求装置へ前記コンテンツを配信するスケジューラ；
   を有し、
   該スケジューラは、前記コンテンツの一部の配信を遅延させるよう、前記要求装置の遅延パラメータに応じて前記スケジュールを修正し、前記遅延パラメータが満たされると決定する、
   システム。
8. コンテンツを配信する方法であって：
   コンテンツの要求を受信する段階；
   該要求に応答して前記コンテンツを配信するスケジュールを生成する段階；及び
   前記コンテンツを送信する遅延時間を示すメッセージを送信する段階；
   を有する方法。
9. 前記スケジュールが前記要求の遅延パラメータを満たすか否かを決定する段階を更に有し、
   前記スケジュールが前記遅延パラメータを満たさない場合、前記メッセージは前記要求が拒否されたことを示す、
   請求項８記載の方法。

Images