6067562 適応ビットレート切換えのための方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6067562

(24)【登録日】2017年1月6日

(45)【発行日】2017年1月25日

(54)【発明の名称】適応ビットレート切換えのための方法および装置

(51)【国際特許分類】

   H04N 21/462 20110101AFI20170116BHJP

   H04N 21/442 20110101ALI20170116BHJP

   H04N 21/2662 20110101ALI20170116BHJP

【ＦＩ】

   H04N21/462

   H04N21/442

   H04N21/2662

【請求項の数】27

【全頁数】33

(21)【出願番号】特願2013-528251(P2013-528251)

(86)(22)【出願日】2011年9月6日

(65)【公表番号】特表2013-543296(P2013-543296A)

(43)【公表日】2013年11月28日

(86)【国際出願番号】US2011050554

(87)【国際公開番号】WO2012033766

(87)【国際公開日】20120315

【審査請求日】2014年9月5日

(31)【優先権主張番号】12/877,925

(32)【優先日】2010年9月8日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】512333560

【氏名又は名称】フル・エルエルシー

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100109830

【弁理士】

【氏名又は名称】福原 淑弘

(74)【代理人】

【識別番号】100088683

【弁理士】

【氏名又は名称】中村 誠

(74)【代理人】

【識別番号】100103034

【弁理士】

【氏名又は名称】野河 信久

(74)【代理人】

【識別番号】100095441

【弁理士】

【氏名又は名称】白根 俊郎

(74)【代理人】

【識別番号】100075672

【弁理士】

【氏名又は名称】峰 隆司

(74)【代理人】

【識別番号】100140176

【弁理士】

【氏名又は名称】砂川 克

(72)【発明者】

【氏名】グタリン、アレクサンダー・ブイ．

(72)【発明者】

【氏名】クーデュリエ、バプティスト

【審査官】 古川 哲也

(56)【参考文献】

【文献】 特開２００７−０３６６６６（ＪＰ，Ａ）

【文献】 米国特許第０６５２９５５２（ＵＳ，Ｂ１）

【文献】 米国特許出願公開第２０１０／０１４６１４５（ＵＳ，Ａ１）

【文献】 国際公開第２０１０／０７８２８１（ＷＯ，Ａ２）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／００ − ２１／８５８

Ｈ０４Ｎ １９／００ − １９／９８

(57)【特許請求の範囲】

【請求項1】

第１のバージョンのメディアプログラムを有する第１のビットストリームおよび第２のバージョンのメディアプログラムを有する第２のビットストリームから適応的に選択するようにメディアプレーヤを構成する方法であって、
前記第１のビットストリームは、前記第２のビットストリームと異なるビットレートを有し、前記方法は、
前記第１のビットストリームのビットレートの時間変動性を記述するデータを受信することと、
前記第１のビットストリームを通信チャネル上で受信することと、
前記通信チャネルのスループットを決定することと、
前記通信チャネルのスループットと、受信された前記第１のビットストリームのビットレートの時間変動性を記述するデータと、の比較結果を生成することと、
前記比較結果に基づいて、現在バッファリングされているデータの量が、メディアプログラムの一部について受信されると期待されるデータの不足量を超えるかを決定することと、
前記比較結果に基づいて、現在バッファリングされているデータの量が、メディアプログラムの一部について受信されると期待されるデータの不足量を超えないとき、さらなる受信のために前記第２のビットストリームを選択することと
を備える、方法。

【請求項2】

前記第１のビットストリームのビットレートの時間変動性を記述するデータは、前記第１のビットストリームのビットレートを時間の関数として記述する、請求項１に記載の方法。

【請求項3】

前記第１のビットストリームのビットレートの時間変動性を記述するデータは、前記メディアプログラムの継続期間未満の期間にわたる前記第１のビットストリームの平均ビットレートを備える、請求項１に記載の方法。

【請求項4】

前記メディアプログラムは複数の期間を備え、
前記第１のビットストリームのビットレートの時間変動性を記述するデータは、前記複数の期間の各々に対する前記第１のビットストリームの平均ビットレートを備える、請求項３に記載の方法。

【請求項5】

前記第１のビットストリームのビットレートの時間変動性を記述するデータは、複数の級数係数を備える、請求項１に記載の方法。

【請求項6】

前記方法は、前記第２のビットストリームのビットレートの時間変動性を記述するデータを受信することをさらに備え、
前記通信チャネルのスループットと前記受信されたデータとの生成された比較結果は、前記第１のビットストリームのビットレートの時間変動性および前記第２のビットストリームのビットレートの時間変動性と比較される、請求項１に記載の方法。

【請求項7】

前記メディアプレーヤは前記バッファを備え、
前記第２のビットストリームは、前記バッファの容量と、前記バッファに前記現在バッファリングされているデータの量と、に少なくとも部分的に従ってさらに選択される、請求項１に記載の方法。

【請求項8】

前記第１のビットストリームのビットレートの時間変動性を記述するデータおよび前記第２のビットストリームのビットレートの時間変動性を記述するデータは、前記通信チャネル上で前記第１のビットストリームを受信する前に受信される、請求項１に記載の方法。

【請求項9】

前記第２のビットストリームのビットレートの時間変動性を記述するデータは、前記通信チャネル上で前記第１のビットストリームを受信した後に受信される、請求項１に記載の方法。

【請求項10】

第１のバージョンのメディアプログラムを有する第１のビットストリームおよび第２のバージョンのメディアプログラムを有する第２のビットストリームから適応的に選択する装置であって、
前記第１のビットストリームは、前記第２のビットストリームと異なるビットレートを有し、
１つまたは複数のコンピュータプロセッサと、
命令を備える非一時的なコンピュータ読取可能な記憶媒体とを備え、前記命令は、実行された場合、
前記第１のビットストリームのビットレートの時間変動性を記述するデータを受信することと、
前記第１のビットストリームを通信チャネル上で受信することと、
前記通信チャネルのスループットを決定することと、
前記通信チャネルのスループットと、受信された前記第１のビットストリームのビットレートの時間変動性を記述するデータと、の比較結果を生成することと、
前記比較結果に基づいて、現在バッファリングされているデータの量が、メディアプログラムの一部について受信されると期待されるデータの不足量を超えるかを決定することと、
前記比較結果に基づいて、現在バッファリングされているデータの量が、メディアプログラムの一部について受信されると期待されるデータの不足量を超えないとき、さらなる受信のために前記第２のビットストリームを選択することと
のために構成されるように前記１つまたは複数のコンピュータを制御する、装置。

【請求項11】

前記第１のビットストリームのビットレートの時間変動性を記述するデータは、前記第１のビットストリームのビットレートを時間の関数として記述する、請求項１０に記載の装置。

【請求項12】

前記第１のビットストリームのビットレートの時間変動性を記述するデータは、前記メディアプログラムの継続期間未満の期間にわたる第１のビットストリームの平均ビットレートを備える、請求項１０に記載の装置。

【請求項13】

前記メディアプログラムは複数の期間を備え、
前記第１のビットストリームのビットレートの時間変動性を記述するデータは、前記複数の期間の各々に対する前記第１のビットストリームの平均ビットレートを備える、請求項１２に記載の装置。

【請求項14】

前記第１のビットストリームのビットレートの時間変動性を記述するデータは、複数の級数係数を備える、請求項１０に記載の装置。

【請求項15】

前記装置は、前記第２のビットストリームのビットレートの時間変動性を記述するデータを受信することをさらに備え、
前記通信チャネルのスループットと前記受信されたデータとの生成された比較結果は、前記第１のビットストリームのビットレートの時間変動性および前記第２のビットストリームのビットレートの時間変動性と比較される、請求項１０に記載の装置。

【請求項16】

メディアプレーヤは前記バッファを備え、
前記第２のビットストリームは、前記バッファの容量と、前記バッファに前記現在バッファリングされているデータの量と、に少なくとも部分的に従ってさらに選択される、請求項１０に記載の装置。

【請求項17】

前記第１のビットストリームのビットレートの時間変動性を記述するデータおよび前記第２のビットストリームのビットレートの時間変動性を記述するデータは、前記通信チャネル上で前記第１のビットストリームを受信する前に受信される、請求項１０に記載の装置。

【請求項18】

前記第２のビットストリームのビットレートの時間変動性を記述するデータは、前記通信チャネル上で前記第１のビットストリームを受信した後に受信される、請求項１０に記載の装置。

【請求項19】

第１のバージョンのメディアプログラムを有する第１のビットストリームおよび第２のバージョンのメディアプログラムを有する第２のビットストリームから適応的に選択するようにメディアプレーヤを構成する方法であって、
前記第１のビットストリームは、前記第２のビットストリームと異なるビットレートを有し、
前記第１のビットストリームのビットレートの時間変動性を記述するデータを生成することと、
前記メディアプログラムに対する第１の要求をユーザデバイスから受信することと、
前記第１のビットストリームのビットレートの時間変動性を記述するデータを送信することと、
前記第１のビットストリームを通信チャネル上で送信することと、
前記第２のビットストリームに対する第２の要求を前記ユーザデバイスから受信することと、ここで、前記第２の要求は、前記第１のビットストリームの前記ビットレートの時間変動性を記述する前記データと、前記通信チャネルの前記スループットと、の比較結果に少なくとも部分的に基づく、
前記比較結果に基づいて、現在バッファリングされているデータの量が、メディアプログラムの一部について受信されると期待されるデータの不足量を超えるかを決定することと、
前記比較結果に基づいて、現在バッファリングされているデータの量が、メディアプログラムの一部について受信されると期待されるデータの不足量を超えないとき、さらなる受信のために前記第２のビットストリームを選択することと、
前記第２のビットストリームを前記通信チャネル上で送信することと、
を備える、方法。

【請求項20】

前記第１のビットストリームのビットレートの時間変動性を記述するデータは、前記第１のビットストリームのビットレートを時間の関数として記述する、請求項１９に記載の方法。

【請求項21】

前記第１のビットストリームのビットレートの時間変動性を記述するデータは、前記メディアプログラムの継続期間未満の期間にわたる前記第１のビットストリームの平均ビットレートを備える、請求項１９に記載の方法。

【請求項22】

前記メディアプログラムは複数の期間を備え、
前記第１のビットストリームのビットレートの時間変動性を記述するデータは、前記複数の期間の各々に対する前記第１のビットストリームの平均ビットレートを備える、請求項２１に記載の方法。

【請求項23】

前記第１のビットストリームのビットレートの時間変動性を記述するデータは、複数の級数係数を備える、請求項１９に記載の方法。

【請求項24】

前記方法は、
前記第２のビットストリームのビットレートの時間変動性を記述する第２のデータを生成することと、
前記第２のビットストリームのビットレートの時間変動性を記述するデータを送信することと、
をさらに備え、
前記通信チャネルのスループットと前記受信されたデータとの比較結果は、前記第１のビットストリームのビットレートの時間変動性および前記第２のビットストリームのビットレートの時間変動性と比較される、請求項１９に記載の方法。

【請求項25】

前記メディアプレーヤはバッファを備え、
前記第２のビットストリームは、前記バッファの容量と、前記バッファに前記現在バッファリングされているデータの量と、に少なくとも部分的に従ってさらに選択される、請求項１９に記載の方法。

【請求項26】

前記第１のビットストリームのビットレートの時間変動性を記述するデータおよび前記第２のビットストリームのビットレートの時間変動性を記述するデータは、前記通信チャネル上で前記第１のビットストリームを送信する前に送信される、請求項１９に記載の方法。

【請求項27】

前記第２のビットストリームのビットレートの時間変動性を記述するデータは、前記通信チャネル上で前記第１のビットストリームを送信した後に送信される、請求項１９に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ストリーミングされる複数のメディアプログラムを提供するための複数のシステムおよび複数の方法に関し、詳細には、複数の通信チャネル状態に対して適切なビットレートを有するメディア・プログラム・ビットストリームを選択するためにメディア・プログラム・プレーヤを適合させるための方法および装置に関する。

【背景技術】

【0002】

メディアプログラムの配布および再生は、この１０年の間にかなり変化した。これまでは、メディアプログラムは（オーディオ、ビデオまたは両方を含むことがある）、アナログ放送（従来の衛星またはケーブル）により、またはフィルムを映画館に配布することにより配布された。

【0003】

これらの従来の配布および再生の手段は、デジタル技術の出現後、依然として採用されたままである。しかしながら、デジタル技術は、メディアプログラムの配布および再生に顕著な影響を与えた。

【0004】

第１に、デジタル技術は、デジタル・ビデオ・レコーダ（ＤＶＲ）の使用を可能にした。ＤＶＲは、標準的なアナログ・ビデオ・カセット・レコーダ（ＶＣＲ）と機能が類似しているが、ライブポーズ（ｌｉｖｅ ｐａｕｓｅ）、他の番組を再生しながら１つの番組を記録する能力、およびＤＶＲ機能に電子プログラムガイドを組み込むことを含むいくつかの追加の有用な機能を提供する（この結果、メディアプログラムの記録を、はるか前に予定することができた）。

【0005】

第２に、デジタル技術はまた、インターネットを介したメディアプログラムの配布および再生を可能にし、信号処理が改善され、高速インターネットアクセス（例えばＤＳＬ、ファイバおよび／または衛星）をますます多くの家庭が有した。これらの方法による配布および再生は従来の手段と比べて見劣りしなくなった。インターネットを介したメディアプログラムの配布は、単純なダウンロード、プログレッシブダウンロードまたはストリーミングにより行われてもよい。

【0006】

プログレッシブダウンロード（Progressive Downloading）
プログレッシブダウンロードでは、メディアプログラムを有するメディアファイルが、ダイヤルアップ、ＤＳＬ、ＡＤＳＬ、ケーブル、Ｔ１、または他の高速接続を使用してインターネットを介してダウンロードされる。このようなダウンロードは、典型的にはインターネットを介してウェブサーバから行われる。

【0007】

単純なダウンロードは、メディアファイルの複数のバイトを任意の好都合な順序でダウンロードするが、プログレッシブダウンロードは、ファイルの最初から複数のバイトをダウンロードし、最終バイトまで順次に、連続してファイルをダウンロードし続ける。プログレッシブダウンロード中の任意の特定の時間に、ファイルの複数の部分が再生のために即座に利用できないことがある。いくつかの状況では、ファイル全体がまずダウンロードされなければならず、この後、メディアプレーヤが再生を開始することができる。プログレッシブダウンロードの他の複数の状況では、複数のメディアプレーヤが、ファイルの最初の十分な量がダウンロードされると再生を開始することができるが、メディアプレーヤは、いくつかの形態の再生をサポートするために、十分な情報をダウンロードしなければならず、この後再生を行うことができる。プログレッシブダウンロードされた複数のメディアファイルの再生は、しばしば遅い複数のインターネット接続により遅延し、また、しばしば途切れ途切れになり、および／またはほんの数秒後に停止する可能性が高い。プログレッシブダウンロードされたメディアプログラムが完全にダウンロードされると、後で使用するためにエンドユーザのコンピュータに格納されてもよい。

【0008】

プログレッシブダウンロードの複数の不利な点の１つが、クライアントが、単にデータを自分の方にできるだけ速くプルすることである。適切な量のデータがダウンロードされたとたんに、多くのメディアプレーヤのプログレッシブダウンロード性能が再生を可能にするので、プログレッシブダウンロードは、ビデオを「ストリーミングしている」ように見えることがある。しかしながら、典型的には、ファイル全体がウェブサーバにより配送されるまで、ユーザはファイルの最後まで早送りすることができない。プログレッシブダウンロードの他の不利な点が、ウェブサーバはビデオファイルのデータ転送速度を考慮しないことである。したがって、ネットワークの帯域幅がビデオファイルに必要なデータ転送速度より低い場合、ユーザは、ある期間待たなければならず、この後、再生を開始することができる。再生速度がデータの転送速度を超えた場合、追加データがダウンロードされる間、ある期間、再生が中断することがあり、視聴体験を妨げる。しかしながら、潜在的により高いデータ転送速度により再生が行われたとき、ビデオ再生品質はより高くなることがある。例えば、１００ｋｂｐｓのビデオファイルを５６ｋｂｐｓのモデムにより配送することができる場合、ビデオは、１００ｋｂｐｓの速度で提示されるが、追加のビデオデータがダウンロードされる間、再生が中断する期間が存在することがある。ビデオデータは、典型的には、この全体が一時ファイルとしてダウンロードされ、格納される。

【0009】

ウェブサーバは、典型的には、ＴＣＰ（ｔｒａｎｓｆｅｒ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）の上位層でＨＴＴＰ（ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ）を使用して、複数のファイルをネットワーク上で転送する。ネットワーク上で複数のデータパケットの転送を制御するＴＣＰは、速度ではなく、データの配送保証のために最適化される。したがって、ブラウザが、データが欠けていることを検知した場合、再送要求が発行され、データは再送される。配送エラーが多い複数のネットワークでは、複数の再送要求が、大量の帯域幅を消費することがある。ＴＣＰは、適切なデータの効率的な配送または帯域幅制御のために設計されていないので（しかし、むしろすべてのデータの配送が保証される）、すべての用途でビデオデータを配送するのに好ましいわけではない。

【0010】

ストリーミング
ストリーミングはメディアコンテンツをメディアプレーヤに連続的に配送し、メディア再生が同時に行われる。エンドユーザは、コンテンツプロバイダにより配送されると、即座にメディアを再生することができる。従来の複数のストリーミング技術は、データのストリームを配送する単一のプロバイダから１組の複数のエンドユーザへと開始される。単一のストリームを多数の視聴者に配送するには、複数の高い帯域幅および中央処理装置（ＣＰＵ）のパワーが必要とされ、プロバイダが必要とする帯域幅は、エンドユーザの数が増すにつれて、増大する。

【0011】

プログレッシブダウンロードと異なり、ストリーミングメディアはオンデマンドで、またはライブで配送することができる。この点で、プログレッシブダウンロードはファイル全体をダウンロードする、または最初に再生を開始するのに十分な量をファイル全体からダウンロードする必要があり、ストリーミングにより、ファイル内部の任意の地点で即座に再生が可能になる。複数のエンドユーザは、メディアファイルの至る所にスキップして、再生を開始する、またはメディアファイル内の任意の地点に再生を変更してもよい。したがって、エンドユーザは、ファイルがプログレッシブダウンロードされるのを待つ必要がない。典型的には、ストリーミングメディアは、高い複数の帯域幅性能を有する少数の専用サーバから配送される。

【0012】

ストリーミング・メディア・サーバは、複数のビデオファイル要求を受け入れ、かつフォーマット、帯域幅およびこれらのファイルの構造に関する情報を使って、ビデオを再生するのに必要な量のデータだけを、ビデオを再生するのに必要な速度で配送する特化した機器である。複数のストリーミング・メディア・サーバはまた、送信帯域幅、およびメディアプレーヤの複数の性能を考慮してもよい。ウェブサーバと異なり、ストリーミング・メディア・サーバは、複数の制御メッセージおよび複数のデータメッセージを使用してユーザコンピュータと通信して、ビデオが再生されるときに、変化する複数のネットワーク条件に適応する。これらの制御メッセージは、早送り、早戻し、一時停止またはファイルの特定部分へのシークなどの複数の特殊再生機能のための複数のコマンドを含むことができる。ストリーミング・メディア・サーバは、ビデオデータを必要とされたときだけ、必要とされる速度で送信するので、提供されるいくつかのストリームに対して正確な制御を維持することができる。プログレッシブダウンロードの場合と異なり、視聴する人は、より低いデータ転送速度の伝送媒体上で高いデータ転送速度の複数のビデオを見ることができない。しかしながら、複数のストリーミング・メディア・サーバは、（１）複数のユーザにビデオファイルへのランダムアクセスを提供し、（２）だれがどの複数のビデオプログラムを見ているか、およびこれらのビデオプログラムがどれだけ長く視聴されているかをモニタすることができるようになる、（３）視聴体験をサポートするために必要な量のデータだけが送信されるので、送信帯域幅をより効率的に使用する、および（４）ビデオファイルを視聴する人のコンピュータに恒久的に格納しない（ファイルは、最終的にメディアプレーヤにより廃棄され、したがって、コンテンツに対してより多くの制御が可能になる）。

【0013】

複数のストリーミング・メディア・サーバは、ＨＴＴＰ、ＴＣＰまたはＲＴＳＰ（ｒｅａｌ ｔｉｍｅ ｓｔｒｅａｍｉｎｇ ｐｒｏｔｏｃｏｌ）を使用して、複数のビデオストリームを配送してもよいが、一般に、ＲＴＭＰ（ｒｅａｌ ｔｉｍｅ ｍｅｓｓａｇｉｎｇ ｐｒｏｔｏｃｏｌ）およびＵＤＰ（ｕｓｅｒ ｄａｔａｇｒａｍ ｐｒｏｔｏｃｏｌ）を使用する。これらのプロトコルは複数の制御メッセージを可能にし、オーバヘッドを低減することにより帯域幅を節約する。ＴＣＰと異なり、伝送中にデータが捨てられたとき、ＵＤＰは複数の再送要求を送信しない。代わりに、サーバはデータを送信し続ける。複数のストリーミング・メディア・サーバはまた、複数のライブウェブキャストを配送することができ、マルチキャストすることができ、これにより、１人以上のクライアントが単一のストリームに同調することができるようになり、したがって、帯域幅を節約する。

【0014】

典型的には、プログレッシブダウンロードされたメディアは、再生より速い速度でユーザコンピュータに送信される。メディア・プログラム・プレーヤ３０４はこのデータをバッファに入れ、通常、「プログレスバー」の一部として、インジケータを提供することにより、メディアプログラムがどれだけバッファに入れられたかを示してもよい。ユーザが、制御手段を選択し、かつプログレスバーに沿って異なる位置に制御手段を移動させることにより、すでにバッファに入れられたプログラム内の任意の地点にアクセスすることができるようになる制御手段が提供される場合が多い。これにより、ユーザは、メディアプログラムのバッファに入れられた任意の部分にランダムにアクセスすることができるようになる。

【0015】

複数のストリーミング・メディア・プレーヤは、メディアプログラム内の任意の地点にランダムにアクセスできるようにするために、バッファリングに依存しない。代わりに、これは、メディアプレーヤからストリーミング・メディア・サーバに送信される複数の制御メッセージを使用することにより実現される。

【0016】

複数の携帯デバイス
複数のメディアプログラムを複数の携帯メディアプログラム再生デバイス、例えば複数の携帯電話、複数のＩＰＨＯＮＥ、複数のＰＤＡ、複数のラップトップコンピュータなどに送信したい願望がある。通信チャネルの帯域幅は、典型的には狭くなり、かつデバイス自体の処理パワーが、典型的には通常のコンピュータまたは専用デバイスの処理パワーよりも小さいので、複数のメディアプログラムを複数の携帯デバイスに送信することは難題をさらに負わせる。

【0017】

複数のライブ・メディア・プログラムを含む複数のメディアプログラムをこのような複数のデバイスに送信するために、複数の伝送プロトコルが開発された。このような複数のストリームの長さには制限がないので、複数のライブ・メディア・プログラムの送信は、さらに難題となる可能性がある。１つのこのような伝送プロトコルが、ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｐａｎｔｏｓ−ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｍｉｎｇ−０４で入手可能であり、これに付属の付録で提供される、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）トラスト（Ｔｒｕｓｔ）のＨＴＴＰライブ・ストリーミング・プロトコルである。

【0018】

スループット
ＨＴＴＰ、ＴＣＰ、ＲＴＳＰ、ＲＴＭＰ、ＵＤＰまたはライブストリーミングを介したにせよ、複数のメディアプログラムを送受信するために使用される複数の通信のチャネルのスループットは、非常に変わりやすく、予測困難である。したがって、複数のメディアサーバは、典型的には、異なる複数の通信のチャネルのスループットにそれぞれ最適化されたいくつかの異なるバージョンの各メディアプログラムを格納し、送受信のために、該当するバージョンが複数の通信のチャネルスループットに基づき選択される。

【0019】

しかしながら、大部分の複数のストリーミングされるメディアプログラムのビットレートは時間的に一定であるが、可変ビットレート符号化が採用される場合にはこれが当てはまらない。可変ビットレート符号化を使って、メディアプログラムは、プログラム材料と共に変化し、したがって、同様に時間と共に変化するビットレートを使用して符号化される。ビットレートのこれらの時間変動は、複数の通信のチャネルの帯域幅が、メディアプログラムの複数の部分に対して十分である、または必要とされるよりも大きいが、他の複数の部分に対して不十分である複数の状況を生み出す。現在のスループット、およびメディア・プログラム・ストリームの平均ビットレートに関して複数の判定が行われるので、このような複数の変動は２つの問題を引き起こす。すなわち：（１）ビットレートのピーク中にバッファが空になり、途切れ途切れの再生となる、および（２）メディア・プログラム・プレーヤは、谷間の間に、より高いビットレートまで切り換えることができず、この結果、より高い品質のストリームを視聴することができるユーザに、より低い品質のビデオが表示されることになる。

【発明の概要】

【0020】

時間で変動する複数のビットレート要件に従って複数のメディア・プログラム・ビット・ストリームを選択することができるようになる方法および装置が求められている。本発明はこの必要を満たす。

【0021】

上述の複数の要件に対処するための、第１のバージョンのメディアプログラムを有する第１のビットストリームおよび第２のバージョンのメディアプログラムを有する第２のビットストリームから適応的に選択するようにメディアプレーヤを構成するための方法、装置および製造物およびメモリ構造。一実施形態では、本方法は、第１のビットストリームのビットレートの時間変動性を記述するデータを受信することと、第１のビットストリームを通信チャネル上で受信することと、通信チャネルのスループットを判定することと、通信チャネルのスループットと、第１のビットストリームのビットレートの時間変動性を記述する、受信されたデータとの比較結果を生成することと、生成された比較結果に少なくとも部分的に従って、さらに受信するための第２のビットストリームを選択することと、の各ステップを備える。他の複数の実施形態では、本発明は、前述の複数のステップを実行するための装置により立証される。

【0022】

次に、全体を通して同様の複数の参照番号が、対応する複数の部分を表す複数の図面を参照する。

【図面の簡単な説明】

【0023】

【図1】図１は、例示的メディア・プログラム・システムを示す図である。

【図2】図２は、本発明を実現するために使用することができる例示的コンピュータシステムを示す。

【図3】図３は、コンテンツ配送サブシステム、およびユーザに提示するために複数のメディアプログラムおよび複数の広告を配送するために使用することができるトップレベルの複数の動作を示す図である。

【図4】図４は、ライブ・ストリーミング・プロトコルに従って複数のメディアプログラムを送信するために提供されるコンテンツ配送システム４００を示す図である。

【図5】図５は、マスタプレイリストの例示的一実施形態を示す図である。

【図6】図６は、例示的セグメントプレイリストの図である。

【図7】図７は、メディアプログラム伝送プロトコルの一様態を示す図である。

【図8A】図８Ａは、メディア・プログラム・プレーヤ３０４が、異なる複数のビットレートの複数のメディアプログラムをどのようにして受信することができるかを示す図である。

【図8B】図８Ｂは、メディア・プログラム・プレーヤ３０４が、異なる複数のビットレートの複数のメディアプログラムをどのようにして受信することができるかを示す図である。

【図9A】図９Ａは、メディアプログラムを運ぶ複数のビットストリームの時間変動性を記述するデータの供給および使用を示す図である。

【図9B】図９Ｂは、メディアプログラムを運ぶ複数のビットストリームの時間変動性を記述するデータの供給および使用を示す図である。

【図10】図１０は、例示的メディア・プログラム・バージョンのビットレートを時間の関数として示す図である。

【図11】図１１は、複数の通信のチャネルのスループットとビットストリームの時間変動性との間の比較結果をどのようにして生成することができるかの一実施形態を示す図である。

【図12】図１２は、複数の通信のチャネルのスループットとビットストリームの時間変動性との間の比較結果をどのようにして生成することができるかの一実施形態を示す図である。

【発明を実施するための形態】

【0024】

以下の説明では、本発明のいくつかの実施形態の一部を形成し、かつ例示によって示される複数の添付図面が参照される。本発明の範囲を逸脱することなく、他の複数の実施形態を利用してもよく、複数の構造的変更を行ってもよいことが理解される。

【0025】

図１は、例示的メディア・プログラム・システム１００を示す図である。図示される実施形態では、システム１００は、インターネットなどの通信ネットワーク１０４に通信可能に結合され、かつ１つまたは複数のソース・メディア・プログラム・データベース１２４Ａ、１２４Ｂに通信可能に結合された１つまたは複数のソース・ビデオ・サーバ１２２Ａ、１２２Ｂをそれぞれ有する１つまたは複数のメディア・プログラム・ソース１２０Ａ、１２０Ｂを備えてもよい。メディア・プログラム・システム１００は、通信ネットワーク１０４に通信可能に結合され、かつ１つまたは複数のプロバイダ・ビデオ・サーバ１１２および１つまたは複数のプロバイダデータベース１１４を有するメディア・プログラム・プロバイダ１１０をさらに備える。一実施形態では、メディア・プログラム・プロバイダ１１０は、ビデオ・オンデマンドおよび／またはストリーミング・メディア・プログラム・プロバイダである。

【0026】

メディア・プログラム・システム１００は、複数のメディアプログラムをコンピュータなどの第１のユーザデバイス１０２Ａ、または携帯電話などの第２のユーザデバイス１０２Ｂに送信する（以下、代わりにユーザデバイス（複数）１２０と呼ぶ）。この送信は、メディア・プログラム・プロバイダ１１０から直接であってもよい、またはメディア・プログラム・プロバイダ１１０はポータルとして動作して、メディアプログラム自体（代わりに、メディア・プログラム・ソース（複数）１２０により提供される）ではなく、複数のメディア・プログラム・ソース１２０Ａおよび１２０Ｂから利用可能である複数のメディアプログラムへのインタフェースを提供してもよい。

【0027】

第１の事例では、メディア・プログラム・プロバイダ１１０は、複数のメディア・プログラム・ソース１２０（例えばｗｗｗ．ｆｏｘ．ｃｏｍまたはｗｗｗ．ｎｂｃ．ｃｏｍ）から複数のメディアプログラムのライセンス供与を受け、このような複数のプログラムに対するメタデータも、典型的には、同様にメディア・プログラム・ソース１２０からメディア・プログラム・プロバイダ１１０に提供される。このようなメタデータは、使用するためにメディア・プログラム・プロバイダのデータベース１１４により取り出すことができる。補足のメタデータが必要な場合、以下でさらに説明されるように、補足のメタデータは、メディア・プログラム・プロバイダ１１０およびメディア・プログラム・ソース１２０とは無関係のメタデータソース１３０から得ることができる。

【0028】

第２の事例では、複数のメディアプログラムは、直接メディア・プログラム・ソース１２０の複数のサーバからユーザデバイス１０２にストリーミングされる。メディアプログラムがメディア・プログラム・ソース１２０から直接ストリーミングされるとき、メディア・プログラム・ソース１２０により提供されるメタデータは不十分である場合がしばしばある。複数のこのような場合、補足のメタデータが無関係のメタデータソース１３０（例えばｗｗｗ．ｔｖ．ｃｏｍまたはｗｗｗ．ｉｍｄｂ．ｃｏｍ）または他のサードパーティの複数のソースから得られることがある。この状況では、メディア・プログラム・プロバイダ１１０の役割は、利用可能な複数のメディアプログラムのリスト、およびこのような複数のプログラムを見つけ出すために検索し、かつこのような複数のプログラムを視聴するインタフェースをユーザ１３２に提供するポータルの役割である。

【0029】

複数のメディアプログラムおよびメタデータは、インターネットなどの通信ネットワーク１０４を介して、または複数の補助（および／または専用）通信リンク１３４を通して得られてもよい。このような情報は、ウェブクローリングにより（例えば、ワールド・ワイド・ウェブを順序だった、自動化された方法でブラウズするプログラムまたは自動化スクリプトを使用して）得られてもよい。

【0030】

複数のユーザデバイス１０２を使用して、複数の遠隔ユーザ１３２が、通信ネットワーク１０４を使用してメディア・プログラム・プロバイダ１１０と通信して、複数のメディアプログラム（ビデオ・オンデマンドおよび／またはストリーミング・ビデオ・サービスを含む）を得て、プロバイダのメディア・プログラム・データベース１１４を検索して、関心のある複数のメディアプログラムを見つけ出すことができる。

【0031】

メディア・プログラム・システム１００はまた、メディア・プログラム・プロバイダ１１０または複数のメディア・プログラム・ソース１２０により提供される複数のメディアプログラムと一緒に再生される複数の広告を供給する１つまたは複数の広告プロバイダ１４０を備えてもよい。図示される実施形態では、広告プロバイダ１４０は、関連づけられ、かつ通信可能に結合された広告プロバイダデータベース１４４に通信可能に結合された広告プロバイダサーバ１４２を含む。

【0032】

複数の広告は、インターネット１０４、専用リンク１４６を介して、または広告を有するメモリ記憶デバイスの物理的交換により、広告プロバイダ１４０からメディア・プログラム・プロバイダ１１０に供給されてもよい。このような複数の広告は、メディア・プログラム・プロバイダ１１０により提供および格納され、該当する時間に、メディアプログラムと一緒にユーザデバイス（複数）１０２にストリーミングまたはダウンロードすることができる。

【0033】

一実施形態では、複数の広告は、メディア・プログラム・プロバイダ１１０からストリーミングまたはダウンロードされたビデオと一体化される。別の実施形態では、複数の広告は、メディアプログラムと一体化されるのではなく、代わりに、メディアプログラムとは別個に複数のユーザデバイス１０２に送信され、各広告がいつ提示されるべきかを示す複数のインデックスを使用して、該当する時間に再生される。例えば、複数の広告は、インデックスをつけることができる、および複数のユーザデバイス１０２にストリーミングまたはダウンロードすることができ（メディア・プログラム・プロバイダ１１０または広告プロバイダ１４０から）、このような複数の広告は、メディアプログラム内の対応する複数のインデックスにより示される複数の時間に、ユーザ１３２に対して再生することができる。

【0034】

図２は、複数のユーザデバイス１０２、複数のサーバ１１２、１２２および１４２、ならびにデータベース１１４、１２４および１４４を含む、本発明の複数の要素を実現するために使用することができる例示的コンピュータシステム２０２を示す。コンピュータ２０２は、汎用ハードウェアプロセッサ２０４Ａおよび／または専用ハードウェアプロセッサ２０４Ｂ（以下、代わりに集合的にプロセッサ２０４と呼ぶ）、ならびにランダムアクセス・メモリ（ＲＡＭ）などのメモリ２０６を備える。コンピュータ２０２は、キーボード２１４、マウスデバイス２１６およびプリンタ２２８などの複数の入出力（Ｉ／Ｏ）デバイスを含む他の複数のデバイスに結合されてもよい。

【0035】

一実施形態では、コンピュータ２０２は、オペレーティングシステム２０８の制御下でコンピュータプログラム２１０により規定される複数の命令を汎用プロセッサ２０４Ａが実行することにより動作する。コンピュータプログラム２１０および／またはオペレーティングシステム２０８は、メモリ２０６に格納されてもよく、ユーザ１３２および／または他の複数のデバイスとインタフェースで接続して、入力および複数のコマンドを受け入れて、このような入力および複数のコマンド、ならびにコンピュータプログラム２１０およびオペレーティングシステム２０８により規定される複数の命令に基づき、出力および複数の結果を提供してもよい。

【0036】

出力／複数の結果は、ディスプレイ２２２上に示されても、提示する、またはさらに処理もしくは動作させるために、他のデバイスに提供されてもよい。典型的には、ディスプレイ２２２は、状態を変えて、ユーザ１３２に画像を集合的に提示する複数の画像要素（複数の画素）を備える。例えば、ディスプレイ２２２は、不透明な状態または半透明な状態に変化して、入力および複数のコマンドに対してコンピュータプログラム２１０および／またはオペレーティングシステム２０８の複数の命令を適用することにより、プロセッサ２０４により生成されたデータまたは情報に応答して、ディスプレイ上で画像の一部を形成する液晶をそれぞれ備える別個にアドレス可能な複数の画素を有する液晶ディスプレイ（ＬＣＤ）を備えてもよい。同様に、複数のプラズマディスプレイが、異なる色の蛍光体をそれぞれ備える３つの別個のサブピクセルからなるセルを有する画素を含む。複数の色が一緒に混ざり合って、画素内に提示される色を生成する。複数のセルを通って流れる複数の電流パルスが、入力および複数のコマンドに応答してコンピュータプログラムおよび／またはオペレーティングシステム２０８の複数の命令を適用することにより、プロセッサにより生成されたデータに従って変更され、画素により提供される光の強さが変化する。また、同様に、複数の陰極線管（ＣＲＴ）ディスプレイが複数の画素を含み、それぞれ、各画素が、典型的にはアパーチャグリルからの複数のドットまたは複数のラインで表現される複数のサブピクセルを有する。各ドットまたはラインは、電子銃からの複数の電子が衝突したときに光を放つ蛍光体コーティングを含む。コンピュータプログラムおよび／またはオペレーティングシステム２０８の複数の命令を適用することにより、プロセッサにより生成されたデータに応答して、ならびに入力および／または複数のコマンドに応答して、電子銃により放出された複数の電子は、複数のドットまたは複数のラインに導かれ、したがって、このドットまたはラインの蛍光体コーティングに光を放たせることにより関連する画素の状態を変更する。

【0037】

画像はグラフィカル・ユーザ・インタフェース（ＧＵＩ）・モジュール２１８Ａにより提供されてもよい。ＧＵＩモジュール２１８Ａは別個のモジュールとして描かれているが、複数のＧＵＩ機能を実行する複数の命令が、オペレーティングシステム２０８、コンピュータプログラム２１０内に常駐もしくは分散する、または専用のメモリおよび複数のプロセッサで実現することができる。

【0038】

コンピュータプログラム１１０の複数の命令に従ってコンピュータ２０２により実行される複数の動作の一部またはすべてが、専用プロセッサ２０４Ｂで実現されてもよい。さらに、コンピュータプログラム２１０の複数の命令の一部またはすべては、読出し専用メモリ（ＲＯＭ）、プログラム可能読出し専用メモリ（ＰＲＯＭ）、もしくは専用プロセッサ２０４Ｂ内部またはメモリ２０６内のフラッシュメモリに格納された複数のファームウェア命令により実現されてもよい。専用プロセッサ２０４Ｂはまた、複数の動作の一部またはすべてを実行して本発明を実現する回路設計により、ハードウェアに組み込まれてもよい。さらに、専用プロセッサ２０４Ｂは、複数の機能のサブセットを実行するための専用回路、および複数のコンピュータプログラム命令に応答するなどのより一般的な複数の機能を実行するための他の複数の回路を含むハイブリッドプロセッサでもよい。一実施形態では、専用プロセッサは、特定用途向け集積回路（ＡＳＩＣ）である。

【0039】

コンピュータ２０２はまた、ＣＯＢＯＬ、Ｃ＋＋、ＦＯＲＴＲＡＮまたは他の言語などのプログラミング言語で書かれたアプリケーションプログラム２１０をプロセッサ２０４の可読コードに翻訳することができるようにするコンパイラ２１２を実装してもよい。コンパイル後、アプリケーションまたはコンピュータプログラム２１０は、コンパイラ２１２を使用して生成された複数の関係およびロジックを使用して、複数のＩ／Ｏデバイスから受け入れられ、コンピュータ２０２のメモリ２０６に格納されたデータにアクセスし、操作する。

【0040】

コンピュータ２０２はまた、モデム、衛星リンク、イーサネット（登録商標）カードまたは他の複数のコンピュータから入力を受け入れ他の複数のコンピュータに出力を提供する他のデバイスなどの外部通信デバイスを任意選択で備える。

【0041】

一実施形態では、オペレーティングシステム２０８、コンピュータプログラム２１０およびコンパイラ２１２を実現する複数の命令は、コンピュータ可読媒体、例えば１つまたは複数の固定のまたは取外し可能なデータ記憶デバイス、例えばジップドライブ、フロッピー（登録商標）・ディスク・ドライブ２２４、ハードドライブ、ＣＤ−ＲＯＭドライブ、テープドライブ、ＤＶＤなどを含むことができるデータ記憶デバイス２２０内に有形に具体化される。さらに、オペレーティングシステム２０８およびコンピュータプログラム２１０は、コンピュータ２０２によりアクセスされ、読み出され、実行されたとき、コンピュータ２０２に本発明を実現および／もしくは使用するのに必要な、または複数の命令からなるプログラムをメモリの中にロードするのに必要な複数のステップを実行させる複数のコンピュータプログラム命令を備え、したがって、コンピュータに本明細書で説明される複数の方法ステップを実行する専用にプログラムされたコンピュータとして動作させる専用データ構造を生成する。コンピュータプログラム２１０および／または動作させる複数の命令はまた、メモリ２０６および／または複数のデータ通信デバイス２３０内に有形に具体化されてもよく、それにより、本発明によるコンピュータプログラム製品または製造物を作成する。このため、用語「製造物」、「プログラム記憶デバイス」および「コンピュータプログラム製品」は、本明細書で使用されるとき、任意のコンピュータ可読デバイスまたは媒体からアクセス可能なコンピュータプログラムを包含するものとする。

【0042】

当然のことながら、上記の複数の構成要素の任意の組合せ、または任意の数の異なる複数の構成要素、複数の周辺装置および他の複数のデバイスが、コンピュータ２０２と共に使用されてもよいことを当業者であれば理解されよう。

【0043】

本明細書では用語「ユーザコンピュータ」と呼ばれるが、ユーザコンピュータ１０２は、複数の携帯デバイス、例えば複数の携帯電話、複数の携帯型ＭＰ３プレーヤ、複数のビデオゲーム機、複数のノートブックコンピュータ、複数のポケットコンピュータ、複数の携帯情報端末（複数のＰＤＡ）または適切な処理、通信および入出力の機能を備えた任意の他のデバイスを含んでもよいことが理解される。

【0044】

図３は、コンテンツ配送サブシステム（ＣＤＳ）３００の一実施形態、およびＨＴＴＰ、ＴＣＰ、ＲＳＴＰまたは類似の複数のプロトコルに従ってユーザ１３２に提示するための複数のメディアプログラムおよび複数の広告を配送するために使用することができるトップレベルの複数の動作を示す図である。これらの複数のプロトコルを使用して、メディアプログラム配送中に、メディア・プログラム・プレーヤ１１０からの要求に従って、またはメディアサーバ１１４の主導権で、メディア・プログラム・プレーヤ１１０に送信されるデータのスループットを変更することができる。例えば、ＲＴＳＰは、メディアサーバが、メディアサーバの能力に適合する特定の速度でメディア・プログラム・プレーヤにデータを配送し、この速度でメディアを提供することを望むことを要求する速度要求ヘッダフィールドを定義する。

【0045】

図示される実施形態では、コンテンツ配送サブシステム３００は、ユーザデバイス１０２、メディア・プログラム・プロバイダ１１０および広告プロバイダ１４０を含む。メディア・プログラム・プロバイダ１１０は、フィードサービス３０６、コンテンツセレクタ３０８およびコンテンツ管理サービス３１０を備える。ユーザ１３２が、ユーザデバイス１０２を使用してメディアプログラムを選択したとき、選択されたメディアプログラムのメディアプログラム識別子（ＰＩＤ）を要求するメッセージが、ユーザデバイス１０２からメディア・プログラム・プロバイダ１１０に送信される。フィードサービス３０６は要求を受信し、コンテンツ管理サービス３１０を介して安全な記憶装置３１２から得られた情報を使用して、フィードサービス３０６は、選択されたメディアプログラムに対するＰＩＤを決定し、ＰＩＤをユーザデバイス１０２に送信する。ユーザデバイスは、このＰＩＤおよびユーザＩＤをメディア・プログラム・プロバイダ１１０のコンテンツセレクタ３０８に送信する。コンテンツセレクタ３０８は、情報をコンテンツ管理サービス３１０に転送し、コンテンツ管理サービス３１０は、広告サービス３１８を使用して、安全な記憶装置３１２に格納された情報を使用して、ユーザおよび選択されたメディアプログラムに適合した複数の広告を選択する。これは、２０１０年５月２６日に出願された、Ｗｉｎｇ Ｃｈｉｔ Ｍａｋによる「迅速でスケーラブルな管理された広告サービスのための方法および装置（METHOD AND APPARATUS FOR RAPID AND SCALEABLE DIRECTED ADVERTISING SERVICE）」と題する同時係属中の特許出願第１２／７８７，６７９号明細書に説明されるように実現されてもよく、この出願は参照により本明細書に組み入れられる。コンテンツ管理サービス３１０は、この情報をコンテンツセレクタ３１８に転送し、コンテンツセレクタ３１８は、選択されたメディアプログラムをユーザデバイス１０２がメディアサーバ１１４から得ることができる情報だけでなく、広告プロバイダ１４０からの複数の広告も送信する。図示される実施形態では、この情報は、メディアサーバ１１４から所望のメディアプログラムを得ることができるアドレス（例えばＵＲＬ）を含む。ユーザデバイス１０２は、指定されたアドレスにあるメディアサーバ１１４にメディアプログラム要求を送信する。メディアサーバ１１４は、メディアプログラムを安全な記憶装置から取り出し、メディアプログラムをユーザデバイス１０２に送信する。ユーザデバイス１０２は、送信されたメディアプログラムを受信し、メディアプログラムをバッファ３０５に一時的に格納してもよい。バッファ３０５は、ハードウェアおよび／またはソフトウェアのバッファリングを含んでもよく、メディア・プログラム・プレーヤ３０５内、またはユーザデバイス１０２内の他のどこかに存在してもよい。

【0046】

ユーザデバイス１０２はまた、広告プロバイダ１２０からの複数の広告を要求し、複数の広告を同様に受信してもよい。典型的には、メディアサーバ１１４は、異なるスループットまたは帯域幅の複数の通信チャネルにそれぞれ適した、複数のバージョンのメディアプログラムを有する。ユーザデバイス１０２または他の場所から受信された情報を使用して、メディアプレーヤ１１４は、ユーザデバイス１０２に送信するメディアプログラムの最も該当するバージョンを決定する。この決定は、例えば、メディアプログラムをユーザデバイス１０２に送信するために使用される通信チャネルの帯域幅または利用可能なビットレート、ユーザデバイスのスループット、ならびにユーザデバイス１０２で実現されるバッファ３０５のサイズおよび速度に基づくことができる。

【0047】

次いで、ユーザデバイス１０２は、メディアプログラムを受信する。典型的には、メディア・プログラム・データは、ユーザデバイス内のハードウェアまたはソフトウェアのバッファ３０５に格納され、先入れ先出し（ＦＩＦＯ）法で取り出される。配送されるメディアプログラムのバージョンの平均ビットレートが、複数の通信のチャネルの帯域幅性能よりも低いので、メディアプログラムが再生されている間に、バッファ３０５は一杯になる。バッファリングされたデータは、通信チャネルの帯域幅またはメディアプログラムのビットレートが変化したときでさえ利用可能であり、したがって、バッファリングされたデータは、途切れ途切れの再生を低減するために使用することができる。

【0048】

メディアプログラムが、必要とされるビットレートで配送されていないとユーザデバイス１０２が判断した場合（メディアプログラムを再生するためにデータが消費される速度が、データが受信される速度を、バッファ３０５が途切れ途切れの再生を適切に防止することができない程度まで超える）、ユーザデバイス１０２は、異なるバージョンのメディアプログラム（例えば、より低いビットレートでの送信に適したバージョン）を要求するメッセージをメディアサーバ１１４に送信してもよい。逆に、メディアプログラムが必要とされるビットレートよりも高く配送されているとユーザデバイス１０２が判断した場合、ユーザデバイス１０２は、より高いビットレートでの送信に適したバージョンのメディアプログラムを要求するメッセージをメディアサーバに送信してもよい。これにより、より高い解像度のバージョンのメディアプログラムがユーザ１３２に提供されることがある。

【0049】

広告プロバイダ１４０およびメディアサーバ１１４は、メディア・プログラム・プロバイダ１１０とは別個のアーキテクチャエンティティとして図示されているが、広告プロバイダ１４０は、メディア・プログラム・プロバイダ１１０と一体化されてもよい（すなわち、メディア・プログラム・プロバイダはまた、複数の広告を提供してもよい）。ＣＤＳ３００は、ｗｗｗ．ｈｕｌｕ．ｃｏｍ、ｗｗｗ．ｉｍｄｂ．ｃｏｍ、ｗｗｗ．ａｏｌ．ｃｏｍまたはｗｗｗ．ｍｓｎ．ｃｏｍを含んでもよい複数の配送ネットワークを介して複数のメディアプログラムおよび複数の広告を提供する手段を提供する。

【0050】

メディアプログラムおよび広告コンテンツに関するメタデータだけでなく、ストリーミング情報も、複数のメディアプログラムおよび複数の広告をＣＤＳ３００内部のどこで見つけ出すことができるかを記述するデータのように、データベース３１２内のコンテンツ配送システム３００内に格納されてもよい。

【0051】

ユーザデバイス１０２は、インタフェースモジュール３０２およびメディア・プログラム・プレーヤ３０４を含んでもよい。インタフェースモジュール３０２は、情報および複数のメディアプログラムをユーザ１３２に提示するため、および複数のコマンドを含むユーザ入力を受け入れるために使用される、ユーザデバイス１０２により実行される複数の命令を含む。複数の例示的ユーザデバイス１０２が、デスクトップコンピュータ、ラップトップコンピュータまたは携帯デバイス、例えばＩＰＯＤ、ＩＰＨＯＮＥ、ＩＰＡＤ、携帯型電話機もしくはＰＡＬＭデバイスである。

【0052】

別の実施形態では、前述のことは、ユーザデバイス１０２が、ＰＩＤを受信し、ＰＩＤをコンテンツセレクタに送信する必要なしに実現され、代わりに、単にメディアプログラムの要求をユーザデバイスから受け入れ、ユーザデバイス１０２に送信され、かつメディアサーバ１１４からメディアプログラムを得るために使用されるＵＲＬおよびメタデータを生成する。

【0053】

図４は、ライブ・ストリーミング・プロトコルに従って複数のメディアプログラムを送信するために提供されるコンテンツ配送システム４００を示す図である。このプロトコルは、複数の携帯デバイスおよび複数の無線デバイスに対して特に有用である。基本的に、このプロトコルは、ユーザデバイス１０２がメディアプログラムを要求したときに、小さな複数のセグメントの「プレイリスト」またはメディアプログラムの「複数のチャンク（chunks）」を提供されることを除いて、図３に示すプロトコルに類似している。ユーザデバイス１０２は、プレイリストを使用して、メディアプログラムの各チャンクを順序正しく送信することを要求し、各チャンクが受信されたとき、各チャンクは処理され、ユーザ１３２に提示されるメディアプログラムに組み立てられる。

【0054】

図４に示すように、ユーザデバイス１０２は、メディアプログラムのＰＩＤの要求をフィードサービス３０６に送信する。要求は、典型的にはユーザＩＤ、またはこのプロキシだけでなく、メディアプログラムに対する何らかの識別も備える。フィードサービス３０６は要求を受信し、安全な記憶装置３１２およびコンテンツメタデータ／ストリーミング情報データベースから得られた情報を使用して、要求されたメディアプログラムのＰＩＤをＣＭＳ３１０から得る。次いで、ＰＩＤはユーザデバイス１０２に送信される。次いで、ユーザデバイスは、コンテンツセレクタ３０８にＰＩＤと共にメディアプログラム要求を送信する。

【0055】

次いで、ＰＩＤを有するメディアプログラム要求が、コンテンツセレクタ３０８に送信され、コンテンツセレクタ３０８は、この情報をコンテンツ管理サービス３１０に転送する。コンテンツ管理システム３１８は、広告サービス３１８を使用して、安全な記憶装置３１２に格納された情報を使用して、ユーザおよび選択されたメディアプログラムに適合した複数の広告を選択する。この場合も、これは、上述の同時係属中の特許出願第１２／７８７，６７９号明細書で説明されるように達成されてもよい。コンテンツ管理サービス３１０は、この情報をコンテンツセレクタ３１８に転送する。次いで、コンテンツセレクタ３０８は、マスタプレイリストを生成してもよい。

【0056】

図５は、マスタプレイリスト５００の例示的一実施形態を示す図である。マスタプレイリストは、異なる複数のビットレートで表現されたメディアプログラムに対するセグメントプレイリストにそれぞれ関連づけられる複数のリンク５０２Ａ〜５０２Ｈを含む。例えば、リンク５０２Ａは、１．５Ｍｂｐｓのビットレートバージョンのメディアプログラムに対するセグメントプレイリストに関連づけられる。リンク５０２Ｂは、３．２ＭＢＰＳのバージョンのメディアプログラムに対するセグメントリストに関連づけられ、一方、リンク５０２Ｈは、６４ｋｂｐｓのバージョンのメディアプログラムに関連づけられる。

【0057】

次いで、マスタプレイリストはユーザデバイス１０２に送信される。ユーザデバイス１０２は、受信および再生に最も適合するバージョンのメディアプログラムを選択する。この選択は、例えば、メディアサーバ１１４とユーザデバイス１０２の間の複数の通信のチャネルの帯域幅もしくはスループット、および／またはユーザデバイス１０２内の任意のバッファ（複数）３０５のサイズおよびスピードに基づくことができる。ユーザデバイス１０２は、選択されたバージョンのメディアプログラムのメディア・プログラム・バージョン要求をコンテンツセレクタ３０８に送信する。コンテンツセレクタ３０８は、メディア・プログラム・バージョン要求を受信し、セグメントプレイリストを生成し、セグメントプレイリストをユーザデバイス１０２に送信する。ユーザデバイス１０２は、セグメントプレイリストを受信し、メディアサーバ１１４または広告プロバイダ１４０から示された順序でプレイリスト内の複数のセグメントを要求する。

【0058】

図６は、セグメントレイリストの例示的一実施形態を示す図である。セグメントプレイリスト６００は、メディアプログラムの各セグメントへの複数のリンク６０２Ａ〜６０２Ｎを含む。例えば、リンク６０２Ａは、メディアプログラムのセグメント０へのリンクであり、メディアプログラムを取り出すために必要なトークンを含む。リンク６０２は、メディアプログラムの次のセグメント（セグメント１）へのリンクであり、同じくトークンを含む。

【0059】

図７は、ライブ・ストリーミング・プロトコルで使用される複数のセグメントを示す図である。メディア・プログラム・プロバイダ１１０または他のエンティティは、異なる提示スループットにそれぞれ適した複数の異なるバージョンのメディアプログラムを生成する。図示された実施形態では、３つのバージョンが、すなわち、高（high presentation）提示スループットバージョン７０２、中提示（medium presentation）スループットバージョン７０４および低提示（low presentation）スループットバージョン７０６が生成される。さらに、メディアプログラムの各バージョンは、複数のセグメントに分離される。例えば、第１のバージョンのメディアプログラムは、Ｎ個のセグメント７０２−１〜７０２−Ｎに分離され、第２のバージョンのメディアプログラムは、同じくＮ個のセグメント７０４−１〜７０４−Ｎに分離され、第３のバージョンのメディアプログラムは、Ｎ個のセグメント７０６−１〜７０６−Ｎに分離される。図示された実施形態では、複数のセグメントのすべてが同じ時間長であるが（すなわち、それぞれ同一時間期間からなる）、これに該当する必要はない。しかしながら、各特定の時間セグメントの複数のバージョンのすべてが、どれも同一時間長でなければならない。換言すれば、セグメント７０２−１は、７０２−２よりも時間的に長くても、短くてもよいが、７０４−１と同一時間長でなければならない。３つのバージョンのメディアプログラムだけが図示されているが、異なる複数のメディアプログラムの数は、２つのように少ない、または必要とされるだけ多くすることができる。典型的には、複数のバージョンの数は、異なる複数のバージョンの記憶領域、生成および管理、ならびに送信帯域幅の節約、ならびにメディア・プログラム・プレーヤの複数の処理要件の間のトレードオフである。

【0060】

図８Ａおよび図８Ｂは、メディア・プログラム・プレーヤ３０４が、異なる複数のビットレートの複数のメディアプログラムをどのようにして受信することができるかを示す図である。図８Ａは、ＲＳＴＰまたはＵＤＰなどの従来のストリーミングプロトコルに最も適した一実施形態を示し、一方、図８Ｂに示される実施形態は、ライブ・ストリーミング・プロトコルに最も適している。

【0061】

まず、図８Ａを参照すると、メディアプログラムが、高解像度（および高ビットレート）バージョンだけでなく低解像度（および低ビットレート）バージョンの形で提供される状況が示されている。ユーザデバイス１０２またはメディア・プログラム・プロバイダ１１０は、ユーザデバイス１０２により提供される情報を使用して、複数の通信のチャネルのスループットが、第１のアドレス（図示された実施形態では、“ｈｔｔｐ：ｗｗｗ．ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍ／ｈｉｇｈｒｅｓ．ｆｌｖ）で利用可能な高解像度バージョンの受信および処理を可能にするのに十分であると判定する。この後、ユーザデバイスは、指定されたＵＲＬを介して高解像度バージョンのメディアプログラムを受信する。しかしながら、図８Ａに示されるように、高解像度バージョンのメディアプログラムのビットレートは、時間と共に変化し、時間ｔ_１で、しきい値を超える。しきい値は、通信チャネルの帯域幅、ユーザデバイス１０２の処理能力、ならびにメディア・プログラム・データが到着したきにメディア・プログラム・データを格納するために使用されるバッファ３０５のサイズ、一杯になることおよび／または格納時間および取出時間の関数である。ユーザデバイス１０２が他のデータを処理しており、入力されるデータを遅れずに適切に処理することができないため、または複数の通信のチャネルの帯域幅が変化したために、同じ問題に遭遇する可能性がある。いずれの場合にも、ユーザデバイス１０２はこの問題を検知し（例えば、バッファ３０５内のデータ量、および／またはバッファリングされたデータが補充されることなく使用されている速度をモニタすることによる）、必要なときには、より低い解像度（およびより低いビットレートのバージョン）のメディアプログラム（図示される実施形態では、ｈｔｔｐ：ｗｗｗ．ｍｅｄｉａｓｅｒｖｅｒ．ｃｏｍ／ｍｅｄｒｅｓ．ｆｌｖで利用可能）を要求する。メディア・プログラム・プロバイダ１１０は、このメディアプログラムを提供し、ユーザデバイス１０２は、これをユーザのために再生する。時間ｔ_２で、メディアプログラムのビットレートは、このとき、メディアプログラムのビットレートがしきい値未満であるようなものである。この時点で、ユーザデバイス１０２は、より高いビットレートのバージョンのメディアプログラムを要求してもよい、または中解像度バージョンを受信し、提示し続けてもよい。

【0062】

図８Ｂは、メディアプログラムが、ライブ・ストリーミング・プロトコルによる提示スループットの複数の変化を考慮しながら、複数のメディア・プログラム・セグメントをどのようにして受信することができるかを示す。図示される例では、メディア・プログラム・プレーヤ３０４は、提示スループットが最小しきい値より大きいときに、第１の（高提示スループット）バージョンのメディアプログラム７０２−１〜７０２−７からなる複数のセグメントを受信する。しかしながら、提示スループットが時間ｔ_１でしきい値以下に低下するとき、メディア・プログラム・プレーヤ３０４は、中解像度の複数のメディア・プログラム・セグメントを（７０４−８〜７０４−１０を、同じく図４に示す）受信する。典型的には、メディア・プログラム・プレーヤ３０４は、複数のセグメントをユーザに提示する前に複数のセグメントを格納している任意のバッファ３０５が一杯になること、処理負荷および複数の通信のチャネル帯域幅を含むさまざまな要因に基づき、異なるバージョンのストリーミングされるメディアプログラムがいつ必要であるかを判定する。

【0063】

上述のように、複数のデジタル・メディア・プログラムの配送および提示が困難になる可能性があるのは、（１）メディアプログラムをユーザデバイス１０２に配送するために使用される通信チャネルが、（ａ）典型的には帯域幅が制限されており、（ｂ）時間の経過と共に、および複数の移動体用途ではユーザの位置に対してかなり変化する可能性がある、（２）ユーザデバイス１０２により受信されたメディアプログラムの処理および提示には、（ａ）時間と共に変化することがあるかなりのスループットおよび処理速度、ならびに（ｂ）ユーザデバイス１０２内で使用される、かなりの記憶容量および記憶／取出速度の任意のバッファリングを必要とするためである。

【0064】

図９Ａおよび図９Ｂは、メディアプログラムを運ぶ複数のビットストリームの時間変動性を記述するデータの供給および使用により、前述の複数の問題を改善する過程を示す図である。

【0065】

ブロック９０２では、複数のメディア・プログラム・バージョンのビットストリームが生成され、各メディア・プログラム・バージョンのビットストリームは、この他の複数のメディア・プログラム・バージョンのビットストリームと異なるビットレートを有する。一実施形態では、より低いビットレートを有する複数のメディア・プログラム・バージョンのビットストリームは、より高いビットレートを有する複数のメディア・プログラム・バージョンのビットストリームより低い解像度または低いフレームレートを有する。これらの複数のビットの複数のストリームの各々は、図８Ａに示すように、連続的であり、単一アドレスから利用できてもよい、または図８Ｂに示すように、異なるアドレスからそれぞれ利用可能な複数のセグメントを備えてもよい。

【0066】

ブロック９０４では、複数のメディア・プログラム・ビットストリーム・バージョンの時間的分散を記述するデータが生成される。一実施形態では、データは、単純な統計的分散として表される（すなわち、ビットレートの複数の時間サンプルの分散）。

【0067】

図１０は、例示的メディア・プログラム・バージョンのビットレートを時間の関数として示す図である。メディア・プログラム・ビットストリーム・バージョンのビットレートの時間的分散を記述するデータは、単に複数の時間ｔ_１、ｔ_２、…、ｔ_ｎでサンプリングされたメディアプログラムのビットレートの統計的分散という尺度、すなわち

【数1】

【0068】

でもよい。あるいは、メディア・プログラム・ビットストリーム・バージョンのビットレートの時間的分散を記述するデータは、ビットレートを時間の関数として記述してもよい。これは、単に、選択された複数の時間でのビットレート、またはメディアプログラムの継続期間よりも短い時間期間（例えば、図１０のΔｔ）にわたるビットストリームの平均ビットレートを備えてもよい。このような複数の平均ビットレートは、複数の可変期間に対して同様に記述することができる（例えば、Δｔは一定である必要はない）。例えば、データは、メディアプログラムの最初の１０秒間の平均ビットレート、およびメディアプログラムの次の１分間の平均ビットレートを備えてもよい。これにより、ビットレートがより大幅に変化するメディアプログラムの複数の部分で、より多くのデータが提供されるようになる。

【0069】

ビットレートの時間的分散はまた、ビットレートを時間の関数として近似する複数の級数の係数に関して記述することができる。換言すれば、時間の関数としてのビットレートがＢＲ（ｔ）である場合、ビットレートを記述するテーラー級数（Taylor series）を得ることができ、ビットレートの時間的分散を記述するデータは、得られたテーラー級数の複数のパラメータを備えることができる。これらの複数のパラメータをユーザデバイス１０２により処理して、ビットレートを時間の関数ＢＲ（ｔ）として再現することができる。同様に、ＢＲ（ｔ）は時間にわたる関数を表すので、メディア・プログラム・ビットストリームのビットレートを記述するデータは、ＢＲ（ｔ）のフーリエ級数またはフーリエ変換（以下、ＢＲ（ω）と呼ぶ）として表現することができ、ビットレートの時間的分散は、フーリエ変換ＢＲ（ω）の複数のパラメータを含むことができる。テーラー級数の例と同様に、フーリエ級数またはフーリエ変換の複数のパラメータは、ＢＲ（ｔ）を再現するために、ユーザデバイス１０２で（例えば逆フーリエ変換により）処理することができる。

【0070】

図９Ａに戻ると、ブロック９０６に示すように、ユーザデバイス１０２は、メディアプログラムの要求を送信する。これは、図３および図４を参照して上述されたように実現することができる。メディアプログラム要求は、要求されたメディアプログラムだけでなく、要求されたメディアプログラムのバージョンも示してよい。換言すれば、ユーザデバイス１０２は、ユーザの複数の好み、または複数の通信のチャネルのスループットおよびユーザデバイス１０２の処理能力の評価に応じて、高解像度バージョンのメディアプログラムまたはより低解像度バージョンのメディアプログラムを要求してもよい。または、メディアプログラム要求は、単に、要求されたメディアプログラムを含んでもよく、メディア・プログラム・プロバイダ１１０は、要求されたメディアプログラムのビットレート、メディア・プログラム・プレーヤに関する情報またはユーザデバイス１０２および／または通信チャネルの評価に基づき、送信すべき、適切なバージョンのメディアプログラムを判定してもよい。

【0071】

ブロック９１０〜９１６では、メディア・プログラム・プロバイダ１１０は、選択された（または要求された）バージョンのメディアプログラムの時間変動性を記述するデータだけでなく、選択された（または要求された）バージョンのビットストリームを送信し、ユーザデバイス１０２はこれらを受信する。メディア・プログラム・バージョンのビットレートの時間変動性を記述するデータは、別個のメッセージで、またはビットストリーム自体と共に、例えばヘッダで送信されてもよい。さらに、データは、選択されたまたは要求されたメディア・プログラム・バージョンの時間変動性だけを記述してもよい、または複数のメディア・プログラム・バージョンのビットレートの時間変動性を記述してもよく、それによって、必要に応じて、以下にさらに説明されるように、他の複数のメディアプログラムを選択するために使用することができる情報をユーザデバイス１０２に提供する。メディアプログラムのビットレートの時間変動性を記述するデータはまた、メディア・プログラム・ビットストリームが送信される前に、または送信がすでに始まった後に、送信することができる。さらに、メディアプログラムのビットレートの時間変動性を記述するデータは、別個の複数のメッセージで１回に１ビット送信することができる。例えば、メディアプログラムが小さな複数のセグメントでユーザデバイス１０２に送信される複数の実施形態では、各セグメントは、現在のセグメントに続くセグメント（複数）に対するメディアプログラムのビットレートの時間変動性に関する情報を含んでもよい。これにより、ユーザデバイス１０２は、どのバージョンのメディア・プログラム・ビットストリームを要求すべきかを判定することが可能になる。

【0072】

ブロック９１８では、メディア・プログラム・プレーヤは、メディア・プログラム・ビットストリームを送信するために使用される複数の通信のチャネルのスループットを判定する。これは、メディア・プログラム・ビットストリームがユーザデバイス１０２により受信される速度を推定することにより、すなわち、受信されるビットストリームをバッファ３０５に入れるために使用される任意のメモリが一杯になる速度により、リアルタイムで実現されてもよい。あるいは、これは、メディア・プログラム・ビットストリームの受信以前に、例えば、過去に受信された複数のメディアプログラムについて、同一メディア・プログラム・プロバイダ１１０との複数の通信のスループットを判定することにより、実現されてもよい。スループットはまた、時刻に基づき推定することができる。

【0073】

図９Ｂを参照すると、ブロック９２０は、複数の通信のチャネルのスループットとメディアプログラムのビットストリームの時間変動性との比較結果の生成を示す。

【0074】

図１１は、複数の通信のチャネルのスループットとビットストリームの時間変動性との比較結果をどのようにして生成することができるかの一実施形態を示す図である。図示される実施形態では、ユーザデバイス１０２は、時間ｔ_１まで、より高解像度のメディア・プログラム・ビットストリーム１１０４を受信し、リプレイした。ユーザデバイス１０２はまた、取り出されたメディア・プログラム・ビットストリームを一時的に格納するために使用されるＦＩＦＯバッファ３０５を含み、以前に受信されたビットストリームデータがバッファ３０５から読み出されると同時に、新しく受信されたビットストリームデータがバッファ３０５に入れられる。このバッファ３０５は、時間ｔ_２までメディア・プログラム・ビットストリームを受信し、格納した。したがって、メディア・プログラム・ビットストリーム・データがさらに受信されないとしても、ユーザデバイス１０２は、時間ｔ_２までメディアプログラムを再生することができる。

【0075】

上述のように、ユーザデバイスは、複数の通信のリンクのスループットを判定した。このスループットは、例えば、ユーザデバイスにより受信されたデータの総量、およびこのデータをダウンロードするのにどれだけ時間がかかったかを使用して判定することができる。図１１を参照すると、これは、単純に、時間ｔ_０からｔ_１（現在の再生位置）までの間に受信されたデータのすべてを加算し、バッファ３０５に格納されたデータの総量（時間ｔ_１からｔ_２までの間のデータ）を加算し、このデータを受信するのにかかった時間（ｔ_１−ｔ_０）で除算することにより判定することができる。換言すれば、ユーザデバイス１０２は、推定値

【数2】

【0076】

を計算することができる。結果は、ｔ_１からｔ_０までの間に受信されたメディアプログラムに対して測定された平均ビットレートである。これが、図１１に項目１１０２として示されている。

【0077】

ユーザデバイス１０２は、メディア・プログラム・ビットストリームのビットレートの時間変動性を記述するデータを受信したので、ユーザデバイスは、すでに受信されバッファに入れられたデータ、および平均スループットが現在のペースで継続した場合に受信されると期待することができるデータを考慮して、メディア・プログラム・ビットストリームの残りが再生を中断することなく受信することができるかどうかを、間に合うように予想して判定することができる。図示される例では、複数の通信のチャネルのスループットが著しく変化せず、かつ現在バッファに入れられたデータの量

【数3】

【0078】

が、時間ｔ_３から時間ｔ_４までに期待される不足量または

【数4】

【0079】

を超える限り、これが可能である。換言すれば、ユーザデバイスは、スループットが実際に一定のままであり、かつ

【数5】

【0080】

のままである限り、より低いビットレートを有するメディア・プログラム・バージョンを選択する必要がない。しかしながら、

【数6】

【0081】

である場合、ユーザデバイスは、より低いビットレートを有するメディア・プログラム・バージョン（例えば、メディア・プログラム・ビットストリーム１１０６または１１０８）を選択しなければならない。ユーザデバイスは、現在バッファに入れられているデータ量

【数7】

【0082】

が、より低いビットレートのメディア・プログラム・ビットストリーム１１０６の時間ｔ’_３から時間ｔ’_４までに期待される不足分を超えるか

【数8】

【0083】

を超えるかどうかを判定することにより、これを行うことができる。これが該当する場合、メディア・プログラム・プレーヤは、より低い解像度のメディア・プログラム・プレーヤ・ビットストリーム１１０６を選択してもよい。

【0084】

重要なことには、この判定は、前もって行うことができ、この結果、混乱を伴うビットストリームの複数の変化は最小にすることができ、メディア・プログラム・ビットストリームのビットレートのかなりの変動性を考慮することができる。例えば、図１２は、異なる複数のメディア・プログラム・バージョンについて、他の可能な複数のビットストリームのビットレートを示す図である。この場合、

【数9】

【0085】

であること、およびより低いビットレートのバージョンのメディアプログラムに切り換える必要がないことは明らかである。しかしながら、予想性能（look ahead capability）がなければ、ユーザデバイス１０２は、時間ｔ_３で、またはこの近傍で、より低いビットレートのビットストリーム（例えばビットストリーム１２０６）に、誤って切り換える場合がある。

【0086】

より低いビットレートのメディア・プログラム・ビットストリームから（例えば１１０６からより高いビットレートのメディア・プログラム・ビットストリーム（例えば１１０４））に切り換えるために、同じ技術を使用することができる。この場合、通信チャネルのスループットは、必要とされるよりもはるかに大きいので、メディア・プログラム・バッファ３０５はすぐに一杯になることがある。ユーザデバイス１０２は、バッファ３０５がすぐに一杯になることを検出し、通信チャネルの平均スループットを計算し、他の複数の高解像度ビットストリームに対するビットレートに注目して、より高解像度バージョンのメディアプログラムをダウンロードし、処理し、混乱なく提示することができると判断することができる。次いで、ユーザデバイス１０２は、より高いビットレートを有するメディア・プログラム・ビットストリームのバージョンを要求するように判断してもよい。

【0087】

バッファ３０５において、前述の判断で、容量が考慮されてもよいことは注目に値する。例えば、バッファ３０５の容量が小さい場合、ｔ_１からｔ_２までの間の時間間隔はより小さくなり、

【数10】

【0088】

はそれに比例して小さくなる。より少ないデータがバッファに入れられるので、ユーザデバイスは、より低いビットレートのビットストリームにより早く、かつより多くの場合に切り換える必要がある可能性が高い。しかしながら、

【数11】

【0089】

の値はまた、複数の通信のチャネルのスループット、およびバッファに入れられたデータが再生中にどれだけ速く使い切られるかにより制限されるので、バッファ３０５の容量を単に増加させることでは、異なる複数のビットストリームを選択する必要は改善されない。

【0090】

一実施形態では、ユーザデバイス１０２は、複数の通信のチャネルが、高ビットレートのバージョンのメディアプログラムをさらに受信するのをサポートしないと判定すると、ユーザデバイスは、より低いビットレートのバージョンのメディアプログラムを受信し再生するように即座に切り換える。別の実施形態では、ユーザデバイス１０２は、バッファ３０５に格納されたより高いビットレートのバージョンのメディアプログラムを再生し続けるが、この地点からずっと、より低いビットレートのバージョンのメディアプログラムを受信し、再生する。例えば、時間ｔ_１で、複数の通信のチャネルのスループットが、メディアプログラムの最後まで、より高いビットレートのバージョンのメディアプログラム１１０４の再生をサポートするのに十分ではないとユーザデバイス１０２が判定した場合、ユーザデバイス１０２は、時間ｔ_１からｔ_２までバッファ３０５からデータを読み続けてもよく、一方、時間ｔ_２以降、より低いビットレートのバージョンのメディアプログラム１１０６を使用して、バッファ３０５にデータを再び補充する。ユーザデバイス１０２はまた、バッファに入れられたメディア・プログラム・データを再生し、バッファに入れられたデータが使い尽くされると、単により低いビットレートのバージョンを受信するように切り換えてもよい。

【0091】

前述の複数の計算は、メディアプログラムの再生中に何回も行われてよい。例えば、スループットの推定は、ビットストリームデータが受信されたすぐ後に行われ、この後、該当するビットストリームが選択されてもよい。また、一時停止、巻き戻しまたは早送りなどの複数の特殊再生操作は、バッファ３０５が一杯になることに影響を及ぼす可能性が高いので、このような複数の操作の後に計算が繰り返されてもよい。または、前述の複数の計算は、単に、メディアプログラムの再生の間中、周期的に行われてもよい。

【0092】

図９Ｂに戻ると、ブロック９２２では、ブロック９２０で生成された比較結果に少なくとも部分的に従って、さらに受信するための第２のビットストリームが選択される。ブロック９２４および９２６に示すように、第２のビットストリームの要求がメディア・プログラム・プロバイダ１１０に送信され、メディア・プログラム・プロバイダ１１０でこの要求が受信される。次いで、ブロック９２８および９３０に示すように、第２のメディア・プログラム・ビットストリームは、メディア・プログラム・プロバイダ１１０により送信され、ユーザデバイスにより受信される。

【0093】

結論
ここでは、本発明の好ましい複数の実施形態の説明の結論が下される。本発明の好ましい実施形態の以上の説明は、例示および説明のために提示された。本発明の好ましい実施形態の以上の説明は、網羅的なものでも、開示した厳密な形態に本発明を限定するものでもない。以上の教示に照らして、多くの修正および変形が可能である。本発明の範囲は、この詳細な説明によって限定されるものではなく、むしろ本明細書に添付の特許請求の範囲によって限定されるものである。上記の説明、例およびデータは、本発明の製造、および組成物の用途の完全な説明を提供する。本発明の多くの実施形態は、本発明の精神および範囲を逸脱することなく作成することができるので、本発明は、以下に添付される特許請求の範囲にある。
以下に、本願出願時の特許請求の範囲に記載された発明を付記する。
[１]第１のバージョンのメディアプログラムを有する第１のビットストリームおよび第２のバージョンの前記メディアプログラムを有する第２のビットストリームから適応的に選択するようにメディアプレーヤを構成する方法であって、前記第１のビットストリームは、前記第２のビットストリームと異なるビットレートを有する方法であって、
前記第１のビットストリームの前記ビットレートの時間変動性を記述するデータを受信することと、
前記第１のビットストリームを通信チャネル上で受信することと、
前記通信チャネルのスループットを判定することと、
前記通信チャネルの前記スループットと前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記受信されたデータとの比較結果を生成することと、
前記生成された比較結果に少なくとも部分的に従って、さらに受信するための前記第２のビットストリームを選択することと、
の各ステップを備える方法。
[２]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記第１のビットストリームの前記ビットレートを時間の関数として記述する、前記[１]に記載の方法。
[３]前記第１のビットストリームの前記時間変動性ビットレートを記述する前記データは、前記メディアプログラムの継続期間未満の期間にわたる前記第１のビットストリームの平均ビットレートを備える、前記[１]に記載の方法。
[４]前記メディアプログラムは複数の時間期間を備え、前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記複数の時間期間の各々に対する前記第１のビットストリームの平均ビットレートを備える、前記[３]に記載の方法。
[５]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、複数の級数係数を備える、前記[１]に記載の方法。
[６]前記方法は、前記第２のビットストリームの前記ビットレートの前記時間変動性を記述するデータを受信するステップをさらに備え、
前記複数の通信のチャネルの前記スループットと前記受信されたデータとの前記生成された比較結果は、前記第１のビットストリームの前記ビットレートの前記時間変動性および前記第２のビットストリームの前記時間変動性ビットレートと比較される、前記[１]に記載の方法。
[７]前記メディアプレーヤはバッファを備え、前記第２のビットストリームは、前記バッファの容量、および前記バッファが一杯であることに少なくとも部分的に従ってさらに選択される、前記[１]に記載の方法。
[８]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データおよび前記第２のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記通信チャネル上で前記第１のビットストリームを受信する前に受信される、前記[１]に記載の方法。
[９]前記第２のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記通信チャネル上で前記第１のビットストリームを受信した後に受信される、前記[１]に記載の方法。
[１０]第１のバージョンのメディアプログラムを有する第１のビットストリームおよび第２のバージョンの前記メディアプログラムを有する第２のビットストリームから適応的に選択する装置であって、前記第１のビットストリームは、前記第２のビットストリームと異なるビットレートを有する装置であって、
前記第１のビットストリームの前記ビットレートの時間変動性を記述するデータを受信するための手段と、
前記第１のビットストリームを通信チャネル上で受信するための手段と、
前記通信チャネルのスループットを判定するための手段と、
前記通信チャネルの前記スループットと前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記受信されたデータとの比較結果を生成するための手段と、
前記生成された比較結果に少なくとも部分的に従って、さらに受信するための前記第２のビットストリームを選択するための手段と、
を備える装置。
[１１]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記第１のビットストリームの前記ビットレートを時間の関数として記述する、前記[１０]に記載の装置。
[１２]前記第１のビットストリームの前記時間変動性ビットレートを記述する前記データは、前記メディアプログラムの継続期間未満の期間にわたる第１のビットストリームの平均ビットレートを備える、
前記[１０]に記載の装置。
[１３]前記メディアプログラムは複数の時間期間を備え、前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記複数の時間期間の各々に対する前記第１のビットストリームの平均ビットレートを備える、前記[１２]に記載の装置。
[１４]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、複数の級数係数を備える、前記[１０]に記載の装置。
[１５]前記装置は、前記第２のビットストリームの前記ビットレートの前記時間変動性を記述するデータを受信するための手段をさらに備え、
前記複数の通信のチャネルの前記スループットと前記受信されたデータとの前記生成された比較結果は、前記第１のビットストリームの前記ビットレートの前記時間変動性および前記第２のビットストリームの前記時間変動性ビットレートと比較される、前記[１０]に記載の装置。
[１６]前記メディアプレーヤはバッファを備え、前記第２のビットストリームは、前記バッファの容量、および前記バッファが一杯であることに少なくとも部分的に従ってさらに選択される、前記[１０]に記載の装置。
[１７]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データおよび前記第２のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記通信チャネル上で前記第１のビットストリームを受信する前に受信される、前記[１０]に記載の装置。
[１８]前記第２のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記通信チャネル上で前記第１のビットストリームを受信した後に受信される、前記[１０]に記載の装置。
[１９]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述するデータを受信するための前記手段は、プロセッサ、および前記第１のビットストリームの前記ビットレートの前記時間変動性を記述するデータを受信するための複数の命令を格納するメモリを備え、
前記第１のビットストリームを前記通信チャネル上で受信するための前記手段は、前記プロセッサおよび前記メモリを備え、前記メモリは、前記第１のビットストリームを通信チャネル上で受信するための複数の命令をさらに格納し、
前記通信チャネルの前記スループットを判定するための前記手段は、前記プロセッサおよび前記メモリを備え、前記メモリは、前記通信チャネル上のスループットを判定するための複数の命令をさらに備え、
前記通信チャネルの前記スループットと前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データとの前記比較結果を生成するための前記手段は、前記プロセッサおよび前記メモリを備え、前記メモリは、前記通信チャネルの前記スループットと前記第１のビットストリームの前記時間変動性ビットレートを記述する前記受信されたデータとの比較結果を生成するための複数の命令をさらに備え、
前記生成された比較結果に少なくとも部分的に従って、さらに受信するための前記第２のビットストリームを選択するための前記手段は、前記プロセッサおよび前記メモリを備え、前記メモリは、前記生成された比較結果に少なくとも部分的に従って、さらに受信するための前記第２のビットストリームを選択するための複数の命令をさらに備える、前記[１０]に記載の装置。
[２０]第１のバージョンのメディアプログラムを有する第１のビットストリームおよび第２のバージョンの前記メディアプログラムを有する第２のビットストリームから適応的に選択するようにメディアプレーヤを構成する方法であって、前記第１のビットストリームは、前記第２のビットストリームと異なるビットレートを有する方法であって、
前記第１のビットストリームの前記ビットレートの前記時間変動性を記述するデータを生成することと、
前記メディアプログラムの要求をユーザデバイスから受信することと、
前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データを送信することと、
前記第１のビットストリームを通信チャネル上に送信することと、
前記第２のビットストリームの要求を前記ユーザデバイスから受信することであって、前記要求は、前記ビットレートの前記時間変動性を記述する前記受信されたデータと前記複数の通信のチャネルのスループットとの比較結果に少なくとも部分的に基づくことと、
前記第２のビットストリームを前記複数の通信のチャネル上で送信することと、
の各ステップを備える方法。
[２１]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記第１のビットストリームの前記ビットレートを時間の関数として記述する、前記[２０]に記載の方法。
[２２]前記第１のビットストリームの前記時間変動性ビットレートを記述する前記データは、前記メディアプログラムの継続期間未満の期間にわたる前記第１のビットストリームの平均ビットレートを備える、前記[２０]に記載の方法。
[２３]前記メディアプログラムは複数の期間を備え、前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記複数の期間の各々に対する前記第１のビットストリームの平均ビットレートを備える、前記[２２]に記載の方法。
[２４]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、複数の級数係数を備える、前記[２０]に記載の方法。
[２５]前記方法は、
前記第２のビットストリームの前記ビットレートの前記時間変動性を記述する第２のデータを生成することと、
前記第２のビットストリームの前記ビットレートの前記時間変動性を記述するデータを送信することと、
の各ステップをさらに備え、前記複数の通信のチャネルの前記スループットと前記受信されたデータとの前記生成された比較結果は、前記第１のビットストリームの前記ビットレートの前記時間変動性および前記第２のビットストリームの前記時間変動性ビットレートと比較される、前記[２０]に記載の方法。
[２６]前記メディアプレーヤはバッファを備え、前記第２のビットストリームは、前記バッファの容量、および前記バッファが一杯であることに少なくとも部分的に従ってさらに選択される、前記[２０]に記載の方法。
[２７]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データおよび前記第２のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記通信チャネル上で前記第１のビットストリームを受信する前に受信される、前記[２０]に記載の方法。
[２８]前記第２のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記通信チャネル上で前記第１のビットストリームを受信した後に受信される、前記[２０]に記載の方法。
[２９]第１のバージョンのメディアプログラムを有する第１のビットストリームおよび第２のバージョンの前記メディアプログラムを有する第２のビットストリームから適応的に選択するようにメディアプレーヤを構成する装置であって、前記第１のビットストリームは、前記第２のビットストリームと異なるビットレートを有する装置であって、
前記第１のビットストリームの前記ビットレートの前記時間変動性を記述するデータを生成するための手段と、
前記メディアプログラムの要求をユーザデバイスから受信するための手段と、
前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データを送信するための手段と、
前記第１のビットストリームを通信チャネル上に送信するための手段と、
前記第２のビットストリームの要求を前記ユーザデバイスから受信するための手段であって、前記要求は、前記ビット・レート・データの前記時間変動性を記述する前記受信されたデータと前記複数の通信のチャネルのスループットとの比較結果に少なくとも部分的に基づく手段と、
前記第２のビットストリームを前記複数の通信のチャネル上で送信する手段と、
を備える装置。
[３０]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記第１のビットストリームの前記ビットレートを時間の関数として記述する、前記[２９]に記載の装置。
[３１]前記第１のビットストリームの前記時間変動性ビットレートを記述する前記データは、前記メディアプログラムの継続期間未満の期間にわたる前記第１のビットストリームの平均ビットレートを備える、前記[２９]に記載の装置。
[３２]前記メディアプログラムは複数の時間期間を備え、前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記複数の時間期間の各々に対する前記第１のビットストリームの平均ビットレートを備える、前記[３１]に記載の装置。
[３３]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、複数の級数係数を備える、前記[２９]に記載の装置。
[３４]前記装置は、
前記第２のビットストリームの前記ビットレートの前記時間変動性を記述する第２のデータを生成するための手段と、
前記第２のビットストリームの前記ビットレートの前記時間変動性を記述するデータを送信するための手段と、
をさらに備え、前記複数の通信のチャネルの前記スループットと前記受信されたデータとの前記生成された比較結果は、前記第１のビットストリームの前記ビットレートの前記時間変動性および前記第２のビットストリームの前記時間変動性ビットレートと比較される、前記[２９]に記載の装置。
[３５]前記メディアプレーヤはバッファを備え、前記第２のビットストリームは、前記バッファの容量、および前記バッファが一杯であることに少なくとも部分的に従ってさらに選択される、前記[２９]に記載の装置。
[３６]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データおよび前記第２のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記通信チャネル上で前記第１のビットストリームを受信する前に受信される、前記[２９]に記載の装置。
[３７]前記第２のビットストリームの前記ビットレートの前記時間変動性を記述する前記データは、前記通信チャネル上で前記第１のビットストリームを受信した後に受信される、前記[２９]に記載の装置。
[３８]前記第１のビットストリームの前記ビットレートの前記時間変動性を記述するデータを生成するための前記手段は、プロセッサ、および前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データを生成するための複数の命令を格納するメモリを備え、
前記メディアプログラムの前記要求を前記ユーザデバイスから受信するための前記手段、および前記第２のビットストリームの要求を前記ユーザデバイスから受信するための手段は、前記プロセッサを備え、前記メモリは、前記メディアプログラムの前記要求を前記ユーザデバイスから受信するための、および前記第２のビットストリームの要求を前記ユーザデバイスから受信するための複数の命令をさらに格納し、
前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データを送信するための前記手段、前記第１のビットストリームを通信チャネル上に送信するための前記手段、および前記第２のビットストリームを前記複数の通信のチャネル上に送信するための手段は、前記プロセッサ、ならびに前記第１のビットストリームの前記ビットレートの前記時間変動性を記述する前記データを送信するため、および前記第１のビットストリームを前記通信チャネル上に送信するため、および前記第２のビットストリームを複数の通信のチャネル上に送信するための複数の命令をさらに格納するメモリを備える、前記[２９]に記載の装置。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9A】

【図9B】

【図10】

【図11】

【図12】