JP2013536611A - Ｈｔｔｐライブストリーミングと両立できるようにストリーミングメディアプログラムおよび目標とされた広告を供給する方法および装置 - Google Patents

Abstract

広告にユーザデバイスに伝送されたメディアプログラムを付す方法、装置、製品およびメモリ構造を説明する。メディアプログラムおよび広告の異なるバージョンを生成およびセグメント化して、メディアプレーヤに個別に伝送すると、ユーザ人口統計および他の要素に従ってユーザへの提示に向けて異なる広告を選択することができる。

Description

関連出願に対する相互参照

本出願は、Ｗｉｌｌｉａｍ Ｚ．Ｈｏｌｔ、Ｘｉｎａｎ Ｗｕ、Ｅｄｅｎ Ｌｉ、Ｂａｐｔｉｓｔｅ ＣｏｕｄｕｒｉｅｒおよびＡｌｅｘａｎｄｅｒ Ｖ．Ｇｕｔａｒｉｎにより２０１０年６月２８日に出願された米国特許仮出願第Ｎｏ．６１／３５９，３１９号の利益を主張する、Ｗｉｌｌｉａｍ Ｚ．Ｈｏｌｔ、Ｘｉｎａｎ Ｗｕ、Ｅｄｅｎ Ｌｉ、Ｂａｐｔｉｓｔｅ ＣｏｕｄｕｒｉｅｒおよびＡｌｅｘａｎｄｅｒ Ｖ．Ｇｕｔａｒｉｎにより２０１０年１１月１９日に出願された、「ＨＴＴＰライブストリーミングと両立できるようにストリーミングメディアプログラムおよび目標とされた広告を供給する方法および装置」(METHOD AND APPARATUS FOR PROVIDING STREAMING MEDIA PROGRAMS AND TARGETED ADVERTISEMENTS COMPATIBLY WITH HTTP LIVE STREAMING)という名称の米国特許出願第１２／９５０，５６３号の利益を主張するものであり、これらの出願のいずれも、参照により本明細書に組み入れられる。

本出願は、以下の同時係属特許出願にも関するものであり、これらの特許のいずれも、参照により本明細書に組み入れられる。

Ｒｏｂｅｒｔ Ｍ．Ｗｏｎｇ、Ｃｈａｒｌｅｓ Ｂ．ＲｅｅｖｅｓおよびＥｕｇｅｎｅ Ｃｈａｎ−Ｈｕａｉ Ｗｅｉにより、本出願と同一日付にて出願された「メディアプログラムの直観的ナビゲーションのための方法および装置」(METHOD AND APPARATUS FOR INTUITIVE NAVIGATION OF A MEDIA PROGRAM)という名称の、出願第６１／３５９，３０９号、および
Ｒｏｂｅｒｔ Ｍ．ＷｏｎｇおよびＥｄｅｎ Ｌｉにより、本出願と同一日付にて出願された「プラットフォーム全体にわたって休止された再生を同期化する方法および装置」(METHOD AND APPARATUS FOR SYNCHRONIZING PAUSED PLAYBACK ACROSS PLATFORMS)という名称の出願第６１／３５９，２５８号

本発明は、ユーザライブストリーミングプロトコルに即してストリーミングメディアを供給するシステムおよび方法に関し、特に、ターゲット式広告（ｄｉｒｅｃｔｅｄ ａｄｖｅｒｔｉｓｉｎｇ）を上記のストリーミングメディア内に含むシステムおよび方法に関する。

メディアプログラムの提供および再生は、過去１０年でかなり変わった。以前は、メディアプログラム（音声、映像または両方とも含む場合がある）は、アナログ放送（従来の衛星またはケーブル）により、または、映画館へのフィルムの配給により提供されていた。

これらの従来の提供および再生手段は、デジタル技術の到来後も相変わらず使用されている。しかしながら、デジタル技術は、メディアプログラムの提供および再生に大きな影響を与えてきた。

第１に、デジタル技術により、デジタルビデオテープレコーダ（ＤＶＲ）の使用が可能となった。ＤＶＲは、標準的なアナログビデオカセットレコーダ（ＶＣＲ）と機能が似ているが、ライブ休止、別のプログラムを再生中に１つのプログラムを録画することができること、およびＤＶＲ機能性と電子プログラムガイドとの一体化（メディアプログラム録画をかなり前もって予定することができるように）を含め、いくつかの更なる便利な機能がある。

第２に、デジタル技術により、インターネットを介したメディアプログラムの提供および再生が許可となり、信号処理が向上し、高速インターネットアクセス（例えばＤＳＬ、ファイバおよび／または衛星）を使用する世帯がますます増えている。これらの提供および再生の方法は、従来の手段と競合するようになった。インターネットを介したメディアプログラムの提供は、簡単なダウンロード、プログレッシブダウンロードまたはストリーミングにより行われる場合がある。

プログレッシブダウンロード（Progressive Downloading）
プログレッシブダウンロードについては、メディアプログラムを有するメディアファイルは、ダイヤルアップ、ＤＳＬ、ＡＤＳＬ、ケーブル、Ｔｌまたは他の高速接続でインターネットを介してダウンロードされる。当該のダウンロードは、一般的にインターネットを介してウェブサーバにより実行される。

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

プログレッシブダウンロードの短所の１つは、データを伝送するエンティティ（ウェブサーバ）は、単にできるだけ速くクライアントにデータをプッシュ配信するだけであるという点である。映像を「ストリーミングしている」ように見えるかもしれないが、この理由としては、多くのメディアプレーヤのプログレッシブダウンロード能力により、適当な量のデータがダウンロードされるとすぐには再生が可能であるからである。しかしながら、ユーザは、ファイル全体がウェブサーバにより配信されるまでファイルの終わりまで早送りすることができない。プログレッシブダウンロードに関する別の短所は、ウェブサーバは、ビデオファイルのデータ転送速度を考慮に入れないという点である。それゆえに、ネットワーク帯域幅がビデオファイルにより必要とされるデータ転送速度を下回る場合、ユーザは、しばらく待たなければならず、その後に、再生が始まることがある。再生速度がデータ伝達速度を上回る場合、再生が、更なるデータがダウンロード中にしばらく休止される場合があり、視聴経験が中断される。しかしながら、映像再生品質は、潜在的により高いデータ転送速度のために再生が行われたときに良くなる場合がある。例えば、１００ｋｂｐｓの動画ファイルを５６ｋｂｐｓのモデム上に配信することができる場合、映像は１００ｋｂｐｓの速度にて提示されることになる、しかし、更なる映像データがダウンロード中に再生が休止される期間がある場合がある。映像データは、一般的に、全体が一時ファイルとしダウンロードおよび記憶される。

Ｗｅｂサーバは、ＴＣＰ（伝送制御プロトコル）に加えてＨＴＴＰ（ハイパーテキスト転送プロトコル）を一般的に使用して、ネットワークでファイルを転送する。ネットワーク上でのデータパケットの転送を制御するＴＣＰは、速度でなくデータ配信の保証のために最適化される。したがって、ブラウザがデータがなくなっていると感知した場合、再送要求が発行されてデータが再送される。配信エラーが多いネットワークにおいては、再送要求は、大量の帯域幅を消費する恐れがある。ＴＣＰが適当なデータの効率的な配信または帯域幅制御（むしろ全てのデータの配信の保証）に向けて設計されていないことから、全ての用途において映像データの配信に好ましいというわけではない。

ストリーミング
ストリーミングでは、メディアプレーヤに連続的にメディアコンテンツを配信し、メディア再生が、同時に行われる。エンドユーザは、コンテンツプロバイダにより配信されると直ちにメディアを再生することができる。従来のストリーミング技法は、１組のエンドユーザにデータのストリームを配信する単一のプロバイダから発するものである。多くの視聴者に単一のストリームを配信するために高帯域および中央演算装置（ＣＰＵ）電力が必要であり、プロバイダの所要の帯域幅は、エンドユーザの数が増加するにつれて増加する。

プログレッシブダウンロードとは異なり、ストリーミングメディアは、オンデマンドでまたはライブで配信することができる。プログレッシブダウンロードでファイル全体をダウンロードするか、または、開始時に再生を開始するのに十分なファイル全体の量をダウンロードすることが必要である場合、ストリーミングにより、ファイル内の任意の地点にて即時の再生が可能である。エンドユーザは、再生を開始するためにメディアファイルにざっと目を通すか、または、メディアファイルにおいて任意の点に再生を変更するかもしれない。したがって、エンドユーザは、ファイルが漸進的にダウンロードされるのを待つ必要はない。一般的に、ストリーミングメディアは、高帯域容量を有する２、３の専用サーバから配信される。

ストリーミングメディアサーバは、動画ファイルの要求を受理し、かつ、それらのファイルのフォーマット、帯域幅および構造に関する情報とともに、動画ファイルを再生するために必要な速度にて、映像を再生するために必要なデータ量のみを配達する専用デバイスである。ストリーミングメディアサーバは、伝送帯域幅およびメディアプレーヤ容量に対応する場合がある。ウェブサーバとは異なり、ストリーミングメディアサーバは、映像が再生されるとき、変化するネットワーク状態に適応するために制御メッセージおよびデータメッセージを使用してユーザコンピュータと通信する。これらの制御メッセージは、早送り、早戻し、休止、ファイルの特定部分への移動などのトリックプレイ機能のコマンドを含む可能性がある。ストリーミングメディアサーバは必要に応じてのみおよび必要される速度にて映像データを伝送することから、供されるストリームの数の正確な制御を維持することができる。プログレッシブダウンロードの場合とは異なり、視覚者は、データ転送速度が劣るメディア伝送媒体でデータ転送速度が速い映像を見ることができない。しかしながら、ストリーミングメディアサーバは、（１）ユーザが動画ファイルにランダムアクセスすることができ、（２）誰がどんな動画プログラムを見ているか、および、どれくらい見ているかのモニタリングを可能にし、（３）視聴経験をサポートするために必要とされるデータ量のみが伝送されることからより効率的に伝送帯域幅を使用し、（４）視覚者のコンピュータ内に動画ファイルを記憶しない（ファイルは、最終的にメディアプレーヤにより廃棄され、この結果、コンテンツのより多くの制御が可能である）。

ストリーミングメディアサーバは、ＨＴＴＰおよびＴＣＰを使用してビデオストリームを配信する場合があるが、通常、ＲＳＴＰ（リアルタイムストリーミングプロトコル）およびＵＤＰ（ユーザデータグラムプロトコル）を使用する。これらのプロトコルでは、制御メッセージを許可してオーバーヘッドを低減することにより帯域幅を節約する。ＴＣＰとは異なり、データが伝送中になくなったとき、ＵＤＰは、再送された要求を伝送しない。その代わりに、サーバは、データを送り続ける。ストリーミングメディアサーバは、ライブウェブキャストを配信することもでき、かつ、マルチキャストすることもでき、これにより、２つ以上のクライアントが、単一のストリームに同調することができ、この結果、帯域幅が節約される。

一般的に、プログレッシブダウンロードされたメディアは、再生よりも速い速度にてユーザコンピュータに伝送される。メディアプログラムプレーヤは、このデータをバッファリングし、かつ、通常「プログレスバー(progress bar)」の一部としてインディケータを提示することによりメディアプログラムのどれだけがバッファリングされたか示す場合がある。ユーザが、制御を選択してプログレスバーに沿って異なる場所に移動させることにより既にバッファリングされたプログラム内の任意の地点に行くことを可能にする制御が行われることが多い。これにより、ユーザは、ランダムにメディアプログラムの任意のバッファリングされた部分にアクセスすることができる。

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

モバイルデバイス
携帯電話、ｉＰｈｏｎｅ、個人用携帯情報端末（ＰＤＡ）、ラップトップコンピュータなどのモバイルメディアプログラム再生デバイスにメディアプログラムを伝送したいという願望がある。デバイス当該のモバイルデバイスへのメディアプログラムの伝送には更なる問題点があり、この理由は、通信チャネルの帯域幅が一般的に低減され、かつ、デバイス自体の処理電力が一般的に普通のコンピュータまたは専用デバイスの処理電力を下回るからである。

当該のデバイスにメディアプログラム（ライブメディアプログラムを含む）を伝送する各種伝送プロトコルが既に開発されている。ライブメディアプログラムの伝送は、当該のストリームの長さは限りがないので更に一層困難だがやりがいのあるものとなる可能性がある。１つの当該の伝送プロトコルは、ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ＨＴＭＬ／ｄｒａｆｔ−ｐａｎｔｏｓ−ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｍｉｎｇで、かつ、米国特許仮出願第６１／３５９，３１９号で説明するように、ＩＥＴＦ（インターネット技術タスクフォース）トラストのＨＴＴＰライブストリーミングプロトコルであり、この出願は、参照により本明細書に組み入れられる。

広告の組み込み
メディアプログラムの配信は、様々なモデルに基づいて達成することができる。１つのモデルにおいては、ユーザはメディアプログラムの視聴の代金を支払う（例えば、ペイパービューサービスを使用して）。開始直後に放送テレビにより広く採用された別のモデルにおいては、スポンサは、プログラム提示中にまたはプログラムの提示の近くで広告を提示する権利と引き換えにメディアプログラムの提示の代金を支払う。

広告モデルは、視覚者が自分にとって興味深い広告が提示された場合に最も良好に機能する。これまでは、広告主は、当該の人口統計により見られそうだというメディアプログラム中に広告が確実に放映されるようにすることにより自社製品に興味がある視聴者に広告の狙いを定めようとするしかできなかった。しかしながら、デジタル技術の出現およびインターネットを介したメディアプログラムの配信により、広告を特定のユーザにより具体的に方向づけることができる。例えば、登録ユーザは、男性２５〜３０才、未婚とわかる場合がある。他の情報（例えば、視聴者がどんなメディアプログラムをこれまで見てきたかまたはどんな広告にこれまで前向きな反応があったか）とともに、これらの人口統計を用いてユーザにどんな広告を見せたらよいか判断することができる。

スループット
ＨＴＴＰ、ＴＣＰ、ＲＴＳＰ、ＵＤＰを介してかまたはライブストリーミングを介してかを問わず、メディアプログラムを送受信するために使用される通信チャネルのスループットは、非常に可変であり、かつ、予測し難い。したがって、メディアサーバは、通常は各メディアプログラムのいくつかの異なるバージョンを記憶し、各々の異なるバージョンは、異なる通信チャネルスループットに向けて最適化されており、適切なバージョンが、通信チャネルスループットに基づいて送受信に向けて選択される。

しかしながら、ストリーミングされたメディアプログラムのビット伝送速度は、時間的に一定でなくて経時的に大きく変わる。通信チャネルスループットも、経時的に変わる場合がある。これらの時間的変動により、通信チャネルの帯域幅は、メディアプログラムの各部には十分かまたは必要以上であるが、他の部分には不十分である状況が生じる。当該の変動により、メディアプログラムプレーヤは、適当な再生を確保するために、メディアプログラムのバージョン間で切り替わる。当該の切り替えは、通常は広告に関する配慮を問わず行われ、したがって、結果として、再生中断または途切れが発生することがある。したがって、当該の問題を軽減または排除するシステム、装置および方法に対する要望がある。本発明は、この要望を満たすものである。

先述した要件に対応するために、広告が中に含まれたメディアプログラムをストリーミングする方法、装置、製品およびメモリ構造体を開示する。一実施形態においては、メディアプログラムプロバイダが、各々が他と異なる提示スループットに向けて生成される複数のメディアプログラムバージョンを生成し、メディアプログラムバージョンの各々複数のメディアプログラムセグメントにセグメント化し、各々がメディアプログラムバージョンの１つのみに関連し、かつ、関連のメディアプログラムバージョンのデータ転送速度での転送に向けて生成される、複数の広告バージョンを生成し、広告バージョンの各々を複数の広告セグメントにセグメント化する。メディアプログラムプロバイダは、その後、メディアプログラム識別子を有するメディアプログラム要求をメディアプログラムプレーヤから受信して、各々が複数のメディアプログラムバージョンの１つに関連する複数のアドレスを備える、第１のメッセージから生成されたマスタプレイリストをメディアプログラムプレーヤに伝送し、セグメントプレイリストをメディアプログラムプレーヤに伝送する。一実施形態においては、セグメントプレイリストは、メディアプログラムバージョンの１つに関連し、かつ、メディアプログラムバージョンの１つに関連した複数のメディアプログラムセグメントの各１つに関連したアドレスと、メディアプログラムバージョンの１つに関連した広告バージョンに関連した複数の広告セグメントの各１つに関連したアドレスとを有する時間的に順序づけられたリストを備える。

同様の参照番号が全体にわたって対応する部分を表す図面をここで参照すると、

図１は、例示的なメディアプログラムシステムを示す図である。 本発明を実行するために使用することができる例示的なユーザデバイスを示す図である。 図３は、ユーザへの提示に向けてメディアプログラムおよび広告に配信するために使用することができるコンテンツ配信サブシステムおよび最重要の作業を示す図である。 図４は、メディアプログラムおよび広告の異なるバージョンのセグメント化を示す図である。 図５は、変動するスループットによる通信チャネルおよびユーザデバイスの対象となるメディアプログラムの提示および広告セグメントを示す図である。 図６は、ユーザザデバイスが通信提示スループット変化に対応しかつそのうえ異なるユーザを対象とした異なる広告の挿入に許可しながらどのようにしてメディアプログラムセグメントを受信することができるかを示す図である。 図７は、利用可能な提示スループットの変化に対応しながらユーザデバイスがどのようにしてメディアプログラムセグメントおよび目標とされた広告を受信することができるかを示す図である。 図８Ａは、メディアプログラムおよび広告をストリーミングするために使用することができる例示的方法の諸ステップを示す図を示す。 図８Ｂは、マスタプレイリストを生成するために使用することができる例示的な諸ステップを示す図である。 図９は、例示的なマスタプレイリストを示す図である。 図１０は、セグメントプレイリストの一実施形態を示す図である。

以下の説明においては、本明細書の一部を成し、かつ、例示として示される添付図面、本発明のいくつかの実施形態を参照する。他の実施形態を利用される場合があり、構造上の変更が本発明の範囲から逸脱することなく行われる場合があることが理解される。

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

メディアプログラムシステム１００は、コンピュータなどの第１のユーザデバイス１０２Ａまたは携帯電話などの第２のユーザデバイス１０２Ｂ（以下あるいはユーザデバイス１２０という）にメディアプログラムを伝送する。この伝送は、メディアプログラムプロバイダ１１０から直接的なものとすることができるか、または、メディアプログラムプロバイダ１１０は、ポータルとして動作することができ、メディアプログラム自体でなく（その代わりにメディアプログラムソース１２０により供給される）、メディアプログラムソース１２０Ａおよび１２０Ｂから入手可能であるメディアプログラムに対するインターフェースとなる。

第１の場合においては、メディアプログラムプロバイダ１１０は、メディアプログラムソース１２０（ｗｗｗ．ｆｏｘ．ｃｏｍまたはｗｗｗ．ｎｂｃ．ｃｏｍなど）からのメディアプログラムを使用許諾し、当該のプログラムのメタデータは、通常、同様にメディアプログラムソース１２０からメディアプログラムプロバイダ１１０にも供給される。当該のメタデータは、使用に向けてメディアプログラムプロバイダのデータベース１１４により検索することができる。補助メタデータが必要とされる場合、以下で更に説明するように、メディアプログラムプロバイダ１１０およびメディアプログラムソース１２０から独立しているメタデータソース１３０から取得することができる。

第２の場合においては、メディアプログラムは、メディアプログラムソース１２０のサーバから直にユーザデバイス１０２にストリーミングされる。メディアプログラムがメディアプログラムソース１２０から直にストリーミングされるとき、メディアプログラムソース１２０により供給されたメタデータは不十分であることが当てはまることが多い。このような場合、補助メタデータは、独立したメタデータソース１３０（ｗｗｗ．ｔｖ．ｃｏｍまたはｗｗｗ．ｉｍｄｂ．ｃｏｍなど）または他の第三者ソースから取得することができる。この状況においては、メディアプログラムプロバイダ１１０の役割は、ユーザ１３２に利用可能なメディアプログラムのリストを供給するポータル、かつ、当該のプログラムを見つけるために、かつ、視聴するために調べるインターフェースの役割である。

メディアプログラムおよびメタデータは、インターネットなどの通信ネットワーク１０４を介して、または、補助（および／または専用）通信リンク１３４を介して取得することができる。当該の情報は、インターネットのクローリングにより（例えば、秩序立った自動的な方法でワールドワイドウェブを閲覧するプログラムまたは自動スクリプトを使用して）取得することができる。

ユーザデバイス１０２を使用して、リモートユーザ１３２は、メディアプログラム（ビデオオンデマンドおよび／または映像配信サービスを含む）を取得するために、かつ、プロバイダメディアプログラムデータベース１１４を調べて当該のメディアプログラムを見つけるために通信ネットワーク１０４を使用してメディアプログラムプロバイダ１１０と通信することができる。

メディアプログラムシステム１００は、メディアプログラムプロバイダ１１０またはメディアプログラムソース１２０により供給されたメディアプログラムに関連してリプレイされる広告を供給する１つまたは複数の広告プロバイダ１４０を備えることができる。図示する実施形態においては、広告プロバイダ１４０は、関連のかつ通信上結合された広告プロバイダデータベース１４４に通信上結合された広告プロバイダサーバ１４２を含む。

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

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

図２は、ユーザデバイス１０２、サーバ１１２、１２２、および１４２およびデータベース１１４、１２４、および１４４を含め、本発明の要素を実行するために使用することができる例示的なコンピュータシステム２０２を示す。システム２０２は、汎用ハードウェアプロセッサ２０４Ａおよび／または専用ハードウェアプロセッサ２０４Ｂ（以下あるいは集合的にプロセッサ２０４という）およびランダムアクセスメモリ（ＲＡＭ）などメモリ２０６を備える。コンピュータ２０２は、キーボード２１４などの入出力（Ｉ／Ｏ）デバイス、マウス、タッチパッドまたはトラックボールなどのポインティングデバイス２１６およびプリンタ２２８を含め、他のデバイスに結合することができる。

一実施形態においては、システム２０２は、オペレーティングシステム（ＯＳ）２０８に制御されたコンピュータプログラム２１０により定義された命令を実行する汎用プロセッサ２０４Ａにより動作する。コンピュータプログラム２１０および／またはオペレーティングシステム２０８は、メモリ２０６内に記憶することができ、かつ、入力およびコマンドを受理するために、かつ、コンピュータプログラム２１０およびオペレーティングシステム２０８により定義された当該の入力およびコマンドおよび命令に基づいて、出力および結果を供給するためにユーザ１３２および／または他のデバイスとインターフェースすることができる。

出力／結果は、ディスプレイ２２２上で提示するか、または、提示または更なる処理またはアクションに向けて別のデバイスに供給することができる。通常は、ディスプレイ２２２は、ユーザ１３２に画像を集合的に提示するために状態を変更する複数の絵素（画素）を備える。例えば、ディスプレイ２２２は、入力およびコマンドへのコンピュータプログラム２１０の命令の適用からプロセッサ２０４および／またはオペレーティングシステム２０８により生成されたデータまたは情報に応答してディスプレイ上で画像の一部を形成するために不透明または半透明の状態に変わる液晶を各々が有する複数の別々にアドレス指定可能な画素を有する液晶ディスプレイ（ＬＣＤ）を備えることができる。同様に、プラズマディスプレイは、異なる色蛍光体を各々が有する３つの別々のサブピクセルセルを有する画素を含む。色は、共に混ざり合って画素に示す色を作成する。セルを流れる電流のパルスは、入力およびコマンドに応答してコンピュータプログラムおよび／またはオペレーティングシステム２０８の命令の適用からプロセッサにより生成されるデータに従って変えられ、画素により供給される光の強度が変わる。また、同様に、光線管（ＣＲＴ）が表示する陰極は、各画素が通常はアパーチャグリルからの点または線により表されるサブピクセルを有する複数の画素を含む。各点または線は、電子銃から電子により当たられるときに光を発する蛍光体被覆を含む。コンピュータプログラムおよび／またはオペレーティングシステム２０８の命令の適用からプロセッサにより生成されたデータに応答して、および、入力およびコマンドに応答して、電子銃により出射された電子は、点または線にてステアリングされ、この結果、関連の画素の状態が、この点または線の蛍光体被覆に光を発せさせることにより変わる。

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

コンピュータプログラム１１０命令に従ってシステム２０２により行われる作業の一部または全部は、専用プロセッサ２０４Ｂ内で実行することができる。この実施形態においては、コンピュータプログラム２１０命令の一部または全部は、専用プロセッサ２０４Ｂ内の読取り専用メモリ（ＲＯＭ）、プログラマブル読取り専用メモリ（ＰＲＯＭ）またはフラッシュメモリ内にまたはメモリ２０６内に記憶されたファームウェア命令を介して実行することができる。専用プロセッサ２０４Ｂは、本発明を実行する作業の一部または全部を実行するために回路設計を介して配線で接続することができる。更に、専用プロセッサ２０４Ｂは、機能のサブセットを実行する専用回路およびコンピュータプログラム命令に応答するなどのより一般的な機能を実行する他の回路を含むハイブリッドプロセッサとすることができる。一実施形態においては、専用プロセッサは、特定用途向け集積回路（ＡＳＩＣ）である。

システム２０２は、ＣＯＢＯＬ、Ｃ＋＋、ＦＯＲＴＲＡＮなどのプログラミング言語または他の言語で書かれたアプリケーションプログラム２１０をプロセッサ２０４可読コードに変換することを可能にするコンパイラ２１２を実行することもできる。完了後、アプリケーションまたはコンピュータプログラム２１０は、入出力デバイスから受理され、かつ、関係およびコンパイラ２１２を使用して生成された論理回路を使用してシステム２０２のメモリ２０６内に記憶されたデータにアクセスおよび操作する。

システム２０２は、随意的にモデム、衛星リンク、イサーネットカード、無線リンク、または他のコンピュータから入力を受理して他のコンピュータに出力を供給する他のデバイスなどの外部通信デバイスも備える。

一実施形態においては、オペレーティングシステム２０８、コンピュータプログラム２１０およびコンパイラ２１２を実行する命令は、Ｚｉｐドライブ、フロッピー（登録商標）ディスクドライブ２２４、ハードドライブ、ＣＤ−ＲＯＭドライブ、テープドライブ、ＤＶＤなど１つまたはそれ以上の固定式または着脱式データ記憶デバイスを含むことができるコンピュータ可読媒体、例えば、データ記憶デバイス２２０において明白に実施される。更に、オペレーティングシステム２０８およびコンピュータプログラム２１０は、コンピュータプログラム命令で構成され、コンピュータプログラム命令は、システム２０２によりアクセスされ、読み込まれて実行されたとき、システム２０２に、本発明を実行および／または使用するために、または、命令のプログラムをメモリに取り込むために必要なステップを実行させ、その結果、コンピュータに本明細書で説明する方法のステップを実行する特別にプログラムされたコンピュータとして動作させる専用データ構造が作成される。コンピュータプログラム２１０および／または操作命令は、メモリ２０６および／またはデータ通信デバイス２３０においても明白に実施することができ、この結果、本発明に従ってコンピュータプログラム製品または製品が作製される。この点を踏まえて、本明細書で使用する「製品」、「プログラム記憶装置」および「コンピュータプログラム製品」という用語は、任意のコンピュータ可読デバイスまたは媒体からアクセス可能なコンピュータプログラムを包含することが意図されている。

言うまでもなく、当業者は、上記の構成部品または任意の数の異なる構成部品、周辺機器、および他のデバイスの任意の組み合わせをシステム２０２と共に用いることができることを認識するであろう。

「ユーザデバイス」という用語に本明細書で言及するが、ユーザコンピュータ、ｉＰｈｏｎｅ、ｉＰｏｄ、ｉＰａｄ、携帯電話、セル方式の携帯無線電話、ポータブルＭＰ３またはビデオプレーヤ、ビデオゲームコンソール、ノートパソコン、ポケットコンピュータ、パームデバイスなどの個人用携帯情報端末（ＰＤＡ）、または、適当な処理、通信および入出力能力を有する任意の他のデバイスを含むことができる。

図３は、コンテンツ配信サブシステム（ＣＤＳ）３００およびユーザ１３２への提示に向けてメディアプログラムおよび広告を配信するために使用することができる最重要の作業の一実施形態を示す図である。図示する実施形態においては、コンテンツ配信サブシステム３００は、ユーザデバイス１０２、メディアプログラムプロバイダ１１０および広告プロバイダ１４０を含む。

メディアプログラムプロバイダ１１０は、ユーザデバイス１０２を介してユーザ１３２にメディアプログラムおよび広告を供給するためにユーザデバイス１０２および広告プロバイダと通信する。広告プロバイダ１４０はメディアプログラムプロバイダ１１０と別個の構造上のエンティティをと示されているが、広告プロバイダ１４０は、メディアプログラムプロバイダ１１０と一体化することができる（即ち、メディアプログラムプロバイダ１１０は、広告を供給することもできる）。メディアサーバ１１４も、メディアプログラムプロバイダ１１０の一部または別個のエンティティとすることができる。ＣＤＳ３００は、ｗｗｗ．ｈｕｌｕ．ｃｏｍ、ｗｗｗ．ｉｍｄｂ．ｃｏｍ、ｗｗｗ．ａｏｌ．ｃｏｍまたはｗｗｗ．ｍｓｎ．ｃｏｍを挙げることができる複数の配信網全体にわたってメディアプログラムおよび広告を供給する手段となる。

メディアプログラムに関係するメタデータおよび広告コンテンツ並びにストリーミング情報は、メディアプログラムおよび広告がＣＤＳ３００内でどこにあるかを記述するデータと同様にコンテンツ配信システム３００のデータベース３１６内に記憶されている。

図示する実施形態においては、ユーザデバイス１０２は、インターフェースモジュール３０２およびメディアプログラムプレーヤ３０４を含む。インターフェースモジュール３０２は、ユーザ１３２に情報およびメディアプログラムを提示し、かつ、コマンドを含めユーザ入力を受理するためにユーザデバイス１０２のプロセッサにより実行される命令を含む。ユーザインターフェースモジュール３０２がメディアプログラムプレーヤ３０４とは別個に実行されると図示されているが、ユーザインターフェースモジュール３０２は、メディアプログラムプレーヤ３０４と一体化することができる。

ポータブルユーザデバイスによるメディアプログラムの伝送および提示において使用する単純かつ効果的なデータ転送プロトコルが、既に開発されている。これらのプロトコルでは、ユーザデバイスにメディアプログラムの小さいセグメントを伝送し、これらのプロトコルにより、ユーザデバイスは、より大きな伝送帯域幅およびメディアプログラムプレーヤ処理電力（以下提示スループットという）を必要とするセグメントを受信するのか、または、提示スループットを必要とするより低い解像度のセグメントを受信するのか選択することができる。

図４は、メディアプログラム伝送プロトコルの態様を示す図である。メディアプログラムプロバイダ１１０または別のエンティティは、各々が異なる提示スループットに適当な、メディアプログラムの複数の異なるバージョンを生成する。図示する実施形態においては、３つのバージョン、高提示スループットバージョン４０２、中提示スループットバージョン４０４および低提示スループットバージョン４０６が作成される。更にまた、メディアプログラムの各バージョン４０２〜４０４は、複数のセグメントに分離される。例えば、図４では、メディアプログラムの第１のバージョン４０２は、Ｎセグメント４０２−１〜４０２−Ｎに分離され、メディアプログラムの第２のバージョン４０４も、Ｎセグメント４０４−１〜４０４−Ｎに分離され、メディアプログラムの第３のバージョン４０６は、Ｎセグメント４０６−１〜４０６Ｎに分離される。

図示する実施形態においては、任意の特定のバージョンのセグメントの全ては、等しい時間的長さである（例えば、時間的セグメント４０２−１は、時間的セグメント４０２−２と同じ時間的長さである）が、これは当てはまらなくてもよい。また、図示する実施形態においては、メディアプログラムの各バージョンは、同数のセグメントを含む（例えば、バージョン４０２、４０４および４０６は、全てＮ個のセグメントを含む）が、これが当てはまらなくてもよい。更に、各々の対応する時間的セグメントのバージョンの全ては、通常、同じ時間的長さとなる（換言すると、セグメント４０２−１は、通常は、４０４−１と同じ時間的長さとなる）が、これが当てはまらなくてもよい。その代わりに、異なるバージョンの時間的セグメントは、広告が挿入されることになっている時間にてセグメントが時間的に整合される限り異なる時間的長さとすることができる。例えば、第１のバージョン４０２がＮ個の時間的に等しいセグメントを有し、第２のバージョン４０４が２Ｎ個の時間的に等しいセグメントを有する場合、セグメント４０２−１の長さは、第２のバージョンセグメントの２倍となる。

メディアプログラムの３つのバージョンだけが図示されているが、異なるメディアプログラムの数は、わずか２個、または、必要されるだけとすることができる。通常は、バージョンの数は、異なるバージョンの記憶、生成および管理と伝送帯域幅およびメディアプログラムプレーヤ処理要件の保護間の歩み寄りである。

図５は、提示スループットおよび／またはメディアプログラムデータ転送速度の変化に対応しながらメディアプログラムプレーヤ３０４がどのようにしてメディアプログラムセグメントを受信することができるかの簡素化されたバージョンを示す図である。図５に示すように、メディアプログラムのデータまたはビット伝送速度は、破線で示すように時間と共に変わる可能性がある。同時に、実線で示すように、提示スループット（例えば、メディアプログラムが受信される通信チャネルのスループットおよび／またはユーザデバイス１０２の処理スループットを含むことができる）は、時間と共に変わる恐れがある。

図示する実施例においては、メディアプログラムプレーヤ３０４は、提示スループットが最小値閾値を上回ったとき、メディアプログラム４０２−１〜４０２−７の第１の（高提示スループット）バージョンのセグメントを受信する。しかしながら、提示スループットが時間ｔ_１にてメディアプログラムデータ転送速度を下回ったとき、メディアプログラムプレーヤは、時機を逃さずにメディアプログラムの高解像度バージョンを受信および処理することができることができない恐れがあり、したがって、中間解像度（４０４−８〜４０４−１０）のメディアプログラムセグメントを要求および受信する。提示スループットが時間ｔ_２にてメディアプログラムデータ転送速度を上回ったとき、メディアプログラムプレーヤは、時機を逃さずにメディアプログラムの高解像度バージョンを受信および処理することができ、したがって、中間の解像度（４０４−１１など）のメディアプログラムセグメントを要求および受信する。

通常は、ユーザデバイス１０２は、先入れ先出し（ＦＩＦＯ）バッファを含み、メディアプログラムデータ転送速度が提示スループットを下回ったとき、ユーザデバイス１０２は、後の提示に向けてデータをバッファリングすることができる。このバッファは、ユーザデバイス１０２が異なるセグメントバージョンに切り替わる必要性を改善する、つまり、遅らせることができる。しかしながら、メディアプログラムデータ転送速度が十分に長い期間にわたって提示スループットを上回った場合、ユーザデバイス１０２は、先述したように、メディアプログラムの低い方のビット伝送速度バージョンに切り替わる必要がある。通常は、メディアプログラムプレーヤ３０４は、ユーザに提示する前のセグメントを記憶する任意のバッファの豊かさ、処理負荷および通信チャネル帯域幅を含む様々な要因に基づいてストリーミングされたメディアプログラムの異なるバージョンがいつ所望されるか判断する。

また、ライブストリーミングプロトコルで一度に要求および伝送を必要とされるメディアプログラムのセグメントは相対的に短いことから、メディアプログラムデータ転送速度はセグメント間で殆ど変わらないと考えられることは注目に値することである。当該の場合、メディアプログラムプレーヤは、提示スループットに主として基づいて異なるセグメントバージョンを要求することになる。

上記プロトコルは、メディアプログラムが広告を含まない限り、または、メディアプログラムが全ての視聴者に向けて同じ広告を含む限りよく機能する。当該の場合、広告は、メディアストリーム内に配置しさえすればよく、メディアプレーヤは、広告が同じ情報（メディアプログラムの一部のみ、広告の一部のみまたはその両方を有するセグメントを含むことができる）を表す限りセグメントバージョン間で切り替わることができることになる。しかしながら、ユーザにユーザの好みまたは他の要素に基づいて選択される広告（以下、個人用にカスタマイズされた、または、ターゲット式広告（ｄｉｒｅｃｔｅｄ ａｄｖｅｒｔｉｓｅｍｅｎｔ）という）提示されたとき、前出のモデルは、良好には機能しない。それは、ユーザがメディアプログラムを要求したときであれば、メディアプログラムは、検索される必要があり、広告は妥当な時間にて組み継がれる必要があり、その後になってユーザデバイスがメディアプログラムを受信することができるからである。更に、このプロセスであれば、全てのメディアプログラムバージョンについて実行される必要がある。

図６は、メディアプログラムプレーヤ３０４が通信提示スループットおよびメディアプログラムビット伝送速度の変化に対応しかつそのうえ異なるユーザを対象とした異なる広告の挿入に許可しながらどのようにしてメディアプログラムセグメントを受信することができるかを示す図である。前と同様に、メディアプログラムの異なるバージョンが生成される。前と同様に、メディアプログラム６０２〜６０６の異なるバージョンは、通常は時間的にバージョン間で同じ長さであるセグメント６０２−１〜６０６−Ｎに分離される。しかし、この場合、メディアプログラム６００は、広告を除外する。その代わりに、広告の異なるバージョンが生成され（第１の広告６５０の３つのバージョン６５２〜６５６など）、これらの異なるバージョンも、セグメント６５２−１〜６５６−Ｍに分離される。メディアプログラムセグメント６０２−１〜６０６−Ｍと同様に、広告セグメント６５２−１〜６５６−Ｍは、同じ時間的長さである必要がなく、バージョン間で等しい長さである場合もあれば、等しい長さではない場合もある。

図７は、利用可能な提示スループットおよびメディアプログラムビット伝送速度の変化に対応しながらメディアプログラムプレーヤ３０４がどのようにしてメディアプログラムセグメントおよび目標とされた広告を受信することができるかを示す図である。提示スループットが仮に高品質再生の最小値閾値を上回ったままである場合、メディアプログラムプレーヤ３０４は、単に、図７の頂部に示すように、共にメディアプログラムの高解像度バージョンを備えるセグメントを要求する。これであれば、メディアプログラム（ＰＳ１Ｖ１−ＰＳ６Ｖ１）の第１の６つのセグメント６０２−１〜６０２−６、次に、広告（ＡＳ１Ｖ１−ＡＳ２Ｖ１）の２つのセグメント６５２−１〜６５２−２、その後、メディアプログラム（ＰＳ７Ｖ１−ＰＳ１０Ｖ１）の次のセグメント６０２−７〜６０２−１０を含む。しかしながら、提示スループット最小値がメディアプログラム（時間ｔ_１にて、例えば）を再生するために必要な場合、本発明は、その代わりに、再生が続くように広告の異なるバージョンを検索する。例えば、図７に示すように、時間ｔ_１の後、メディアプログラムプレーヤ３０４は、セグメントＡＳ１Ｖ１、ＰＳ７Ｖ２およびＰＳ８Ｖ２を要求し、セグメントＡＳ１Ｖ１、ＰＳ７Ｖ２およびＰＳ８Ｖ２は、通信チャネル上で適当に伝送してメディアプログラムプレーヤ３０４により提示することができるより低いサイズおよび解像度の広告およびメディアプログラムセグメントである。提示スループットがメディアプログラムを再生するために必要な最小値を上回ったとき、メディアプログラムプレーヤ３０４により要求される次のセグメントは、メディアプログラムＰＳ９Ｖ１、ＰＳ１０Ｖ１）のより高い帯域幅のバージョンである。

図示する実施形態では、データセグメイトのバッファリングおよび提示スループットの可能な予測を考慮に入れていない。したがって、大きい方のＡＳ１Ｖ１の代わりに広告セグメントＡＳ１Ｖ２を検索することが望ましかったであろうが、メディアプログラムプレーヤ３０２は、単に、次の配信されたセグメントが、現在利用可能な提示スループットおよびメディアプログラムデータ転送速度に適当であることを要求する。一実施形態においては、メディアプログラムプレーヤ３０４は、提示スループット変化を予測して、これらの予測変化に基づいてメディアプログラムおよび広告の異なるバージョンを要求することができる。別の実施形態においては、メディアプログラムプレーヤ３０４は、スループットが変更したために、提示および現在バッファ済みであるが提示されていないセグメントが適当に提示することができない場合にメディアプログラムプレーヤがその代わりに処理要件が低減された代替セグメントを要求してそのセグメントを提示する時間を有するように、受信されたセグメントを提示されるときにかなり先んじてバッファリングする。メディアプログラムプレーヤがメディアプログラムデータ転送速度を予測することができる（例えば、メディアプログラムデータ転送速度に関する情報を使用して、または、他の要素から予想されるデータ転送速度を推論することにより）実施形態も可能である。

図８Ａは、メディアプログラムおよび広告をストリーミングするために使用することができる例示的方法の諸ステップを示す図を示す。ブロック８０２においては、各１つが異なる提示スループットに向けて生成される複数のメディアプログラムバージョン６０２〜６０６をメディアプログラムに向けて生成する。例えば、各々、異なるビット伝送速度または平均的なビット伝送速度にていくつかのメディアプログラムバージョン６０２〜６０６を生成することができる。ブロック８０４においては、これらのメディアプログラムバージョン６０２〜６０６の各々を一部がメディアプログラムプレーヤ３０４に伝送される複数のメディアプログラムバージョンセグメント（例えば、６０２−１〜６０６Ｎ）に分離する。図示する実施形態においては、メディアプログラムバージョンセグメント６０２−１〜６０２−Ｎは、メディアプログラムバージョン６０２に向けて生成され、メディアプログラムバージョンセグメント６０４−１〜６０４−Ｎは、メディアプログラムバージョン６０４に向けて生成され、メディアプログラムバージョンセグメント６０６〜１−６０６−Ｎは、メディアプログラムバージョン６０６に向けて生成される。これらの作業は、ＣＭＳ ３１０の制御下にあるコンテンツセグメンタ３２０により実行することができる。

ブロック８０６〜８０８においては、類似の作業を行って、複数の広告バージョン６５２〜６５６および広告バージョンセグメント６５２−１〜６５６−Ｍを生成する。

図３に戻って、ここで、更に詳細にメディアプログラムおよび広告の伝送および受信を論じる。先述したように、複数のメディアプログラムバージョンが、メディアプログラムプロバイダ（または、別のエンティティ）により生成され、各々バージョンは、複数のバージョンの他のバージョンと異なる提示スループットに向けて生成される。

ユーザインターフェースモジュール３０２を使用して、ユーザは、視聴に向けてメディアプログラムを選択し、ユーザデバイス１０２は、メディアプログラムの要求をメディアプログラムプロバイダ１１０に伝送する。図示する実施形態においては、要求はユーザ識別子（ユーザＩＤ）および要求のメディアプログラムの識別子を備えて、供給サービス３０６に伝送されるメタデータ（特に、メディアプログラムのためのマスタプレイリストのアドレス）の要求である。一実施形態においては、メタデータ要求で伝送される要求されたメディアプログラムの識別子は、ユーザインターフェースモジュール３０２を介してユーザに提示されるプログラムガイドから取得される。プログラムガイドは、メディアプログラムのサムネイル図を含むことができ、ユーザは、当該のメディアプログラムに関連したサムネイルをクリックすることによりメディアプログラムを選択することができる。

図８Ａを再度参照すると、ブロック８１０に示すように、メディアプログラムのメディアプログラム要求を受信する。供給サービス３０６は、メそしディアプログラムを受信および視聴するために必要とされるマスタプレイリストを付してＩＤ要求に最終的に応答する。

図８Ｂは、マスタプレイリストを生成するために使用することができる例示的な諸ステップを示す図である。図８Ｂを図３に関連して論じる。

ブロック８１６に示すように、メディアプログラムに関連したマスタプレイリストのアドレスの要求をユーザデバイスから受信する。一実施形態においては、要求は、当該のメディアプログラムを識別するデータ、並びに、ユーザ１３２を識別するデータ、ユーザコンピュータ１０２および／またはメディアプログラムプレーヤ３０４を含む。この情報は、メディアプログラムに関連して再生に向けて選択される広告がユーザ１３２、ユーザコンピュータ１０２またはメディアプログラム３０４データに基づいて選択される実施形態において使用することができる。供給サービス３０６は、要求を受信し、保証格納域３１２および他のデータベース３１６、および、コンテンツ管理サービス３１０を介して広告サービス３１６から取得された情報を用いて、供給サービス３０６は、選択されたメディアプログラムについて、メディアプログラム識別子（ＰＩＤ）、および、メディアプログラムとともに再生されるべき任意の広告の類似の識別子を含むことができる妥当なメタデータを判断する。

メディアプログラムプロバイダ１１０はユーザＩＤまたは少なくとも多少ユーザを識別する他の情報を受信したかもしれないことから、メディアプログラムプロバイダ１１０は、要求されたメディアプログラムと共にのどの広告を含めるべきか判断するために広告サービス３１８を呼び出すことができる。これらの識別子は、ともに含むことができる。これは、Ｗｉｎｇ Ｃｈｉｔ Ｍａｋにより２０１０年５月２６日に出願された「迅速かつ拡大縮小可能なターゲット式広告（ｄｉｒｅｃｔｅｄ ａｄｖｅｒｔｉｓｉｎｇ）サービスの方法および装置」(METHOD AND APPARATUS FOR RAPID AND SCALEABLE DIRECTED ADVERTISING SERVICE)という名称の同時係属特許出願第１２／７８７，６７９号明細書で説明されるように達成することができ、この出願は、参照により本明細書に組み入れられる。あるいは、このプロセスは、以下で説明するように、メディアプログラムプレーヤがメディアプログラムのどのバージョンから始めるべきか選択した後に始めることができる。

ブロック８２０に示すように、マスタプレイリストを生成する。一実施形態においては、これは、コンテンツセレクタ３０８により実行される。例示的なマスタプレイリストを図９に示すとともに以下で更に論じる。ブロック８２２においては、マスタプレイリスト９００を供給する。一実施形態においては、先述したように、マスタプレイリスト９００は、選択された広告の各々の識別子を含むことができるアドレスにて供給される。

例えば、マスタプレイリストアドレスは、以下とすることができる：
ｈｔｔｐｓ：／／ｐｌａｙ．ｈｕｌｕ．ｃｏｍ／ｐｌａｙ／５０００００１１／ｍｐｌｓｔ／ｂ＝［ａｄｌｉｓｔ］ａ＝［ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｔｏｋｅｎ］
「５０００００１１」はメディアプログラムＩＤ（ＰＩＤ）を表し、「ａｄｌｉｓｔ」は再生中にプログラムに挿入されるように選択された広告について広告セグメント識別子９０４のリストである。ブロック８２２および図３に示すように、マスタプレイリスト９００アドレスをユーザデバイス１０２に伝送する。

次に、ユーザデバイス１０２は、マスタプレイリストアドレス９００を受信して、ブロック８２４において受信されたマスタプレイリストアドレスにマスタプレイリスト要求を伝送する。先述したように、アドレスは、メディアプログラムのＰＩＤ並びにメディアプログラムの再生中に提示されるべき広告を識別する広告ＩＤのリストを含むことができる。

ブロック８２６に示すように、マスタプレイリストをメディアプログラムプロバイダ１１０においてマスタプレイリストアドレスにて受信する。各々が、メディアプログラムバージョンの要求された１つに関連した広告バージョン６５２〜６５６に関して広告バージョンセグメント識別子６５２−１〜６５６−Ｍを有する複数のメディアプログラムバージョンアドレスは生成される。マスタプレイリストは、複数のメディアプログラムバージョンアドレスから作成される。

図９は、例示的なマスタプレイリスト９００を示す図である。この実施形態においては、マスタプレイリスト９００は、「．ｍ３ｕ８」で終了しおよび／または「ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ａｐｐｌｅ．ｍｐｅｇｕｒｌ」のコンテンツ形式を有するファイル名を有し、かつ、単一のＬＦ文字またはキャリッジリターンにより終了される個々の線を備えるテキストファイルである。コメント文字「＃」で始まる線は、コメントまたはタグであり、タグは、文字ＥＸＴで始まる。「＃」で始まる全ての他の線は、コメントであり無視される。第１の線は、拡張されたｍ３ｕファイルとしてファイルを識別するＭ３Ｕタグを備える。次に、マスタプレイリストは、ＵＲＩまたはＵＲＬが以下の線で提示されるメディアプログラムバージョンを記述するタグを有する。例えば、８０２Ａは、以下のものを識別するタグを提示する。

ＰＲＯＧＲＡＭ−ＩＤ：マスタプレイリストが複数のメディアプログラムを指す場合、ＰＲＯＧＲＡＭ−ＩＤパラメータは、複数のメディアプログラムのうちのどれが関与するか識別する。図示する実施形態においては、マスタプレイリストは、同じメディアプログラムのいくつかのバージョンを指すのでＰＲＯＧＲＡＭ−ＩＤは、１である。複数のメディアプログラムがマスタプレイリストに含まれている場合、第２のメディアプログラムは、例えば、２というＰＲＯＧＲＡＭ−ＩＤを有する。このＰＲＯＧＲＡＭ−ＩＤは、マスタプレイリスト内だけでなく大域的にメディアプログラムの識別子を指すＰＩＤと混同すべきではない。

ＢＡＮＤＷＩＤＴＨ：は、以下の線で記載されるＵＲＩにて利用可能であるストリームの平均的なビット伝送速度を識別するものである。メディアプログラムプレーヤは、セグメントのダウンロード速度を観察することにより実際の帯域幅を判断することができる。

ＵＲＩは、タグの後にあり、ＰＩＤ（図示する実施例では５０００００１１）、ファイル名（図示する実施例では「．ｍ３ｕ８」拡張子を有するビット伝送速度）、広告セグメント識別子９０４（６５２−１〜６５６−Ｍ、６５４−１〜６５４−Ｍまたは６５６−１〜６５６Ｍに類似）および認証目的に使用されているトークンを含む。

尚、図９に示すマスタプレイリストは、メディアプログラムの８つの異なるバージョンについてタグおよびＵＲＩを含み、ストリームは、それぞれ、１５００ｋｂｐｓ、３２００ｋｂｐｓ、２５００ｋｂｐｓ、１０００ｋｂｐｓ、４００ ２００ｋｂｐｓ、１２８ｋｂｐｓおよび６４ｋｂｐｓを表す９０２Ａ、９０２Ｂ、９０２Ｃ、９０２Ｄ、９０２Ｅ、９０２Ｆ、９０２Ｇおよび９０２Ｈにより識別する。各メディアプログラムバージョンアドレスに関連した広告ＩＤの各々は、他のメディアプログラムバージョンアドレスに関連した広告ＩＤと異なる場合がある。

図８Ａに示すブロック８１２に示すように、マスタプレイリスト９００アドレスをユーザデバイス１０２に伝送する。

先述した実施形態においては、ユーザＩＤは、マスタプレイリストのアドレスの要求と共に供給され、かつ、ユーザ１３２にとって最も興味深い広告を選択するために使用されたものである。これらの広告の識別子は、ユーザデバイス１０２に伝送されるマスタプレイリストアドレスで、かつ、その後、マスタプレイリスト自体のメディアプログラムバージョンのアドレスでも返される。この特徴部により、選択された広告のアイデンティティは、マスタプレイリストの生成と、要求されたメディアプログラムバージョン間で、かつ、メディアプログラムプロバイダ１１０により広告状態を維持することなく異なるプログラムバージョン間でも持続することができる。対応される多数のユーザデバイス１０２を考慮すると、この特徴部により大幅に大いに管理が簡素化する。

他の実施形態においては、メディアプログラム内に含めるべき広告のリストは、マスタプレイリストアドレスが伝送された後、および、マスタプレイリストが受信される前に生成することができる。この実施形態においては、マスタプレイリストアドレスは、広告ＩＤのリストを含まないが、マスタプレイリスト自体はこのリストを含む場合がある。

他の実施形態においては、ユーザＩＤは、伝送されず、メディアプログラムと共に再生するべき広告を識別するのに用いられる。あるいは、ユーザのアイデンティティは、クッキー、ユーザのＩＰアドレスを使用してなど他の情報を使用して十分に確認される（その結果、ユーザの地理的場所を判断するために使用することができる情報が得られ、かつ、結果的に、広告を選択するために使用することができるユーザに関する情報が得られる）。

図３を参照すると、予想される提示スループットおよびメディアプログラムデータ転送速度（利用可能な場合）を考慮して、メディアプログラムプレーヤ１０２は、メディアプログラムバージョンのうちどれが受信および提示に最も適当か判断し、メディアプログラムバージョンの１つを識別するメディアプログラムバージョン要求を伝送することにより、そのメディアプログラムバージョンを要求する。一実施形態においては、これは、マスタプレイリストに示す妥当なアドレスにて特定のメディアプログラムバージョンを要求することにより達成される。初めに選ばれるメディアプログラムバージョンは、視聴者好みにより判断することもできる（例えば、ユーザは、通常であれば供給されるより高い解像度バージョンを要求することができる）。一実施形態においては、メディアプログラムバージョン要求は、メディアプログラムプレーヤ１０２が選択したメディアプログラムバージョンに関連したＵＲＬまたはＵＲＩを備えるかまたはこのＵＲＬまたはＵＲＩにアドレス指定される。例えば、メディアプログラムプレーヤ１０２が図９に示す例示的なマスタプレイリストにおいてメディアプログラムの１５００ｋｂｐｓのバージョンを選択した場合、メディアプログラムプレーヤは、８０２ＡのＵＲＩ、即ち、
ｈｔｔｐｓ：／／ｐｌａｙ．ｈｕｌｕ．ｃｏｍ／ｐｌａｙ／５０００００１１／１５００．ｍ３ｕ８？ｂ＝ＩＵＥｆＡＡＫ７．．．５８０
をメディアプログラムプロバイダ１１０に伝送する。メディアプログラムプロバイダ１１０はメッセージを受信して、選択されたメディアプログラムバージョンに関連したセグメントプレイリストを生成する（または、予め生成されたセグメントプレイリストを検索する）。これは、メディアプログラムバージョン要求内のメディアプログラムバージョンの複数のメディアプログラムセグメントの各々に関連したアドレスを生成し、かつ、メディアプログラム中に提示されるように選ばれる広告の複数の広告セグメントの各々に関連したアドレスを生成することにより達成される。セグメントプレイリストは、これらのアドレスおよび妥当なタグを付して生成される。一実施形態においては、セグメントプレイリストは、時間的に順序づけられる（セグメントは、リスト上に提示される順番で要求および再生される）、しかしながら、他の実施形態が可能であり、セグメントプレイリストは任意の順番であり、再生順序は、黙示的であるか（送信器および受信器にはわかっている）、または、ユーザデバイス１０２に伝送されたデータ内に明記されている。

図１０は、セグメントプレイリスト１０００の一実施形態を示す図である。図示する実施形態においては、セグメントプレイリストは、要求されたメディアプログラムバージョン１００６Ａ〜１００６Ｃのメディアプログラムセグメント、および、選択されたメディアプログラムバージョン（どの広告がユーザへの提示に向けてメディアプログラムプロバイダ１１０により選択されたか）に関連した広告バージョンの広告セグメント１００４Ａ〜１００４Ｃの各々に関連したアドレスまたはユニフォームリソースアイデンティファイア（ＵＲＩ）のリストを備える。一実施形態においては、アドレスまたはＵＲＩは、時間的に順序づけられる。この時間的順序づけは、リスト（時間的順番での各エントリ）固有である場合があるか、または、セグメントの時間的関係が判断することができるようにインデックスが供給される場合がある。

セグメントプレイリスト１０００は、上記アドレスおよびプレロール（メディアプログラムの再生が始まる前に）広告１００２のタグおよび２つの不連続性タグ１００８、１０１０を含むこともできる。不連続性タグ１００８、１０１０は、メディアファイルの後に来るメディアファイルとその前にあるメディアファイル間で符号化上の不連続性を示す。変更する恐れがある１組の特性としては、ファイル形式、トラックの数および形式、符号化パラメータ、符号化シーケンスおよび／またはタイムスタンプシーケンスがある。図１０に示す実施例においては、不連続性は、メディアプログラムセグメントから広告セグメントへの（例えば、不連続性１００８）、または、広告セグメントからメディアプログラムセグメントへの（不連続性１０１０、例えば）の変化を表す。

図３に戻ると、メディアプログラムプロバイダ１１０は、ユーザデバイス１０２にセグメントプレイリストを伝送する。ユーザデバイス１０２は、セグメントプレイリストを受信して、メディアサーバ１１４にセグメント要求を伝送し、メディアサーバ１１４は、ストレージ３１２からメディアプログラムを検索して、ユーザデバイスに要求されたメディアセグメントおよび広告を伝送する。ユーザデバイス１０２は、各メディアプログラムおよび広告セグメントを受信して、妥当な順序でユーザに再生する。

前述の実施形態においては、セグメントプレイリスト１０００は＜マスタプレイリスト９００とは別個に、かつ、マスタプレイリスト９００に従って伝送されたものであるが、これが当てはまらなくてもよい。その代わりに、メディアプログラムプレーヤは、単一のメッセージでマスタプレイリスト９００およびセグメントプレイリスト１０００を共に送る場合がある。この場合、一旦メディアプログラムプレーヤ３０４が当該のメディアプログラムバージョンを選択した場合、メディアプログラムプレーヤは、その後、既に受信されたセグメントプレイリスト９００を使用してメディアプログラムまたは妥当なメディアプログラム用広告セグメントおよび広告バージョンを単に要求することができる。

提示スループットがメディアプログラムおよび関連の広告の再生を通して十分なままである場合、メディアプログラムプレーヤ３０４は、単に、現在選択されているバージョンについてメディアプログラムセグメントおよび広告のセクションを受信し続ける。しかしながら、提示スループットが現在選択されているメディアプログラムバージョンに不十分である（例えば、図７に示す時間ｔ_１にて）場合、メディアプログラムプレーヤ３０４は、その代わりに、必要とする提示スループットが小さい方のメディアプログラムセグメントおよび告セグメントのＵＲＩを提示するセグメントプレイリストかららメディアプログラムおよび広告セグメントを選択する。

妥当なセグメントプレイリスト１０００がメディアプログラムプレーヤ３０４に既に供給されている場合、メディアプログラムプレーヤ３０４は、妥当なメディアプログラムおよび広告バージョンについてセグメントプレイリスト１０００内に記載された妥当なＵＲＩを使用して妥当なセグメントを要求しさえすればよい。

しかしながら、妥当なセグメントプレイリスト１０００が第２のメディアプログラムバージョンに供給されていなかった場合、現在のまたは予測された提示スループットに妥当であるメディアプログラムおよび広告のバージョンに向けてセグメントプレイリスト９００を要求する要求が、メディアプログラムプロバイダ１１０に伝送される。例えば、図１０に示す例示的なマスタプレイリストにおいては、メディアプログラムプレーヤ３０４は、メディアプログラムの１０００ｋｂｐｓのバージョンおよび今後のセグメントに向けた広告を選択することができる。これは、１０００ｋｂｐｓのストリームに関連したＵＲＩに第２のメディアプログラムバージョン要求を伝送することにより達成することができる。図９に示す実施例においては、これは９０２Ｄに関連したＵＲＩ、つまり、以下である。

ｈｔｔｐｓ：／／ｐｌａｙ．ｈｕｌｕ．ｃｏｍ／ｐｌａｙ／５０００００１１／１０００．ｍ３ｕ８．．．．
メディアプログラムプロバイダ１１０は、その後、メディアプログラムプレーヤに第２のセグメントプレイリストを伝送する。第１のセグメントプレイリストと同様に、第２のセグメントプレイリストは、第２の選択されたメディアバージョンに関連したメディアプログラムセグメントの各１つに関連したアドレス、および、メディアプログラムバージョンの第２のメディアプログラムバージョンに関連した広告バージョンに関連した複数の広告セグメントの各１つに関連したアドレスとを有する時間的に順序づけられたリストである。換言すれば、ビット伝送速度が遅い方のメディアプログラムセグメントおよび広告セグメントに関するセグメントリスト１０００は、メディアプログラムプロバイダ１１０からメディアプログラムプレーヤ３０４に伝送されてそこで再生される。

当業者は、本発明の範囲から逸脱することなく多くの改変をこの構成に行うことができることを認識するであろう。例えば、当業者は、上記の構成部品または任意の数の異なる構成部品、周辺機器、および他のデバイスの任意の組み合わせを本発明とともに使用することができることを認識するであろう。

結び
これにより、好適な本発明の実施形態の説明を終了する。本発明の好適な実施形態の上記説明は、例示および説明を目的として提示したものである。網羅的であること、または、開示した正確な形態に本発明を制限することを目的とするものではない。上記の教示に照らして多くの改変および変形が可能である。本発明の範囲はこの詳細な説明により限定されず本明細書に添付の特許請求項の範囲により限定されることを意図している。上記明細書、実施例、および、データは、本発明の構成の製造および使用に説明を完全に行うものである。本発明の精神および範囲から逸脱することなく多くの本発明の種々の実施形態を成すことができることから、本発明は、以下に添付する特許請求項の範囲に属する。

Claims (18)

1. メディアプログラムと、これと共に提示するための広告とをストリーミングする方法であって、
   各々が他と異なる提示スループットのために生成される複数のメディアプログラムバージョンを生成することと、
   各メディアプログラムバージョンについて複数のメディアプログラムバージョンセグメントを生成するために複数のメディアプログラムバージョンセグメントに前記複数のメディアプログラムバージョンの各々をセグメント化することと、
   各々が前記複数のメディアプログラムバージョンの１つのみに関連し、かつ、前記関連のメディアプログラムバージョンの前記提示スループットのために生成される、前記広告の複数の広告バージョンを生成することと、
   各広告バージョンについて複数の広告バージョンセグメントを生成するために複数の広告バージョンセグメントに前記複数の広告バージョンの各々をセグメント化することと、
   前記メディアプログラムのメディアプログラム要求を受信することと、
   各々が前記複数のメディアプログラムバージョンの１つのみに関連する複数のメディアプログラムバージョンアドレスを備えるマスタプレイリストを前記メディアプログラムプレーヤに伝送することと、
   前記複数のメディアプログラムバージョンの要求された１つに関連し、かつ、
   前記複数のメディアプログラムバージョンの前記要求された１つに関連した前記複数のメディアプログラムバージョンセグメントの各１つに関連したメディアプログラムバージョンセグメントアドレスと、前記複数のメディアプログラムバージョンの前記要求された１つに関連した前記広告バージョンに関連した前記複数の広告セグメントの各１つに関連した広告バージョンセグメントアドレスと
   を有する時間的に順序づけられたリストを備える、セグメントプレイリストを前記メディアプログラムプレーヤに伝送することと、
   の各ステップを備える方法。
2. 前記メディアプログラム要求を受信する前記ステップ
   は、
   前記メディアプログラムに関連した前記マスタプレイリストのアドレスの要求を受信するステップを備え、
   前記マスタプレイリストを伝送する前記ステップは、
   前記メディアプログラムと共に再生するべき１組の広告から前記広告を選択すること、
   のステップを備え、前記選択された広告は、少なくともある程度ユーザ識別子に従って選択され、
   前記マスタプレイリストを伝送する前記ステップは、更に
   前記マスタプレイリストを生成して、前記選択された広告の識別子を含むマスタプレイリストアドレスにて前記マスタプレイリストを供給することと、
   前記メディアプログラム要求に応答して前記メディアプログラムプレーヤに前記マスタプレイリストアドレスを伝送することと、
   前記マスタプレイリストアドレスにてマスタプレイリスト要求を受信することと、
   前記マスタプレイリスト要求に応答して前記マスタプレイリストを伝送することと
   の各ステップを備える請求項１に記載の方法。
3. 前記選択された広告の前記複数の広告バージョンセグメントの各々は、広告バージョンセグメント識別子に関連し、
   前記マスタプレイリストを生成する前記ステップは、
   前記選択された広告の前記識別子を有する前記マスタプレイリストアドレスにて前記マスタプレイリスト要求を受信することと、
   各々は前記複数のメディアプログラムバージョンの１つのみに関連し、かつ、前記複数のメディアプログラムバージョンの前記要求の１つに関連した前記選択された広告の前記広告バージョンについて前記広告バージョンセグメント識別子を備える前記複数のメディアプログラムバージョンアドレスを生成することとのステップを備える請求項２に記載の方法。
4. 前記広告の前記識別子は、複数の広告識別子文字を備え、前記複数の広告バージョンセグメント識別子の各々は、前記複数の広告識別子文字を備える請求項３に記載の方法。
5. 前記メディアプログラムプレーヤに前記セグメントプレイリストを伝送する前記ステップは、
   前記複数のメディアプログラムバージョンの前記要求の１つの前記メディアプログラムバージョンアドレスにてセグメントプレイリスト要求を受信することと、
   前記受信されたセグメントプレイリスト要求に応答して前記セグメントプレイリストを伝送することとの各ステップを備える請求項３に記載の方法。
6. 前記複数のメディアプログラムバージョンの第２の要求された１つの前メディアプログラムバージョンアドレスにて第２のセグメントプレイリスト要求を受信するステップを更に備え、前記第２のセグメントプレイリスト要求は、前記複数のメディアプログラムバージョンの前記第２の要求の１つに関連した前記複数のメディアプログラムバージョンアドレスの前記１つにアドレス指定され、前記複数のメディアプログラムバージョンアドレスの前記１つは、前記選択された広告の前記識別子を含み、
   前記方法は、更に
   前記複数のメディアプログラムバージョンの前記第２の要求の１つに関連した前記複数のメディアプログラムセグメントの各１つに関連したアドレスと、
   前記複数のメディアプログラムバージョンの前記要求の１つに関連した前記選択された広告の前記広告バージョンに関連した前記複数の広告セグメントの各１つに関連したアドレスとを有する時間的に順序づけられたリストを備えるセグメントプレイリストを前記メディアプログラムプレーヤに伝送するステップを備える請求項３に記載の方法。
7. メディアプログラムと、これと共に提示するための広告とをストリーミングする装置であって、
   各々が他と異なる提示スループットのために生成される複数のメディアプログラムバージョンを生成する手段と、
   各メディアプログラムバージョンについて複数のメディアプログラムバージョンセグメントを生成するために複数のメディアプログラムバージョンセグメントに前記複数のメディアプログラムバージョンの各々をセグメント化する手段と、
   各々が前記複数のメディアプログラムバージョンの１つのみに関連し、かつ、前記関連のメディアプログラムバージョンの前記提示スループットのために生成される、前記広告の複数の広告バージョンを生成する手段と、
   各広告バージョンについて複数の広告バージョンセグメントを生成するために複数の広告バージョンセグメントに前記複数の広告バージョンの各々をセグメント化する手段と、
   前記複数のメディアプログラムのメディアプログラム要求を受信する手段と、
   各々が前記複数のメディアプログラムバージョンの１つのみに関連する複数のメディアプログラムバージョンアドレスを備えるマスタプレイリストを前記メディアプログラムプレーヤに伝送する手段と、
   前記複数のメディアプログラムバージョンの要求の１つに関連し、かつ
   前記複数のメディアプログラムバージョンの前記要求された１つに関連した前記複数のメディアプログラムバージョンセグメントの各１つに関連したメディアプログラムバージョンセグメントアドレスと、前記メディアプログラムバージョンの前記要求された１つに関連した前記広告バージョンに関連した前記複数の広告セグメントの各１つに関連した広告バージョンセグメントアドレスとを有する時間的に順序づけられたリストを備える、セグメントプレイリストを前記メディアプログラムプレーヤに伝送する手段と
   を備える装置。
8. 前記メディアプログラム要求を受信する前記手段は、
   前記メディアプログラムに関連した前記マスタプレイリストのアドレスの要求を受信する手段を備え、
   前記マスタプレイリストを伝送する前記手段は、
   前記メディアプログラムと共に再生するべき１組の広告から前記広告を選択する手段を備え、前記選択された広告は、少なくともある程度ユーザ識別子に従って選択され、
   前記マスタプレイリストを伝送する前記手段は、更に
   前記マスタプレイリストを生成して、前記選択された広告の識別子を含むマスタプレイリストアドレスにて前記マスタプレイリストを供給する手段と、
   前記メディアプログラム要求に応答して前記メディアプログラムプレーヤに前記マスタプレイリストアドレスを伝送する手段と、
   前記マスタプレイリストアドレスにてマスタプレイリスト要求を受信する手段と、
   前記マスタプレイリスト要求に応答して前記マスタプレイリストを伝送する手段とを備える請求項７に記載の装置。
9. 前記選択された広告の前記複数の広告バージョンセグメントの各々は、広告バージョンセグメント識別子に関連し、
   前記マスタプレイリストを生成する前記手段は、
   前記選択された広告の前記識別子を有する前記マスタプレイリストアドレスにて前記マスタプレイリスト要求を受信する手段と、
   各々が前記複数のメディアプログラムバージョンの１つのみに関連し、かつ、前記複数のメディアプログラムバージョンの前記要求の１つに関連した前記選択された広告の前記広告バージョンについて前記広告バージョンセグメント識別子を備える前記複数のメディアプログラムバージョンアドレスを生成する手段とを備える請求項８に記載の装置。
10. 前記広告の前記識別子は、複数の広告識別子文字を備え、前記複数の広告バージョンセグメント識別子の各々は、前記複数の広告識別子文字を備える請求項９に記載の装置。
11. 前記セグメントプレイリストを前記メディアプログラムプレーヤに伝送する前記手段は、
    前記複数のメディアプログラムバージョンの前記要求の１つの前記メディアプログラムバージョンアドレスにてセグメントプレイリスト要求を受信する手段と、
    前記受信されたセグメントプレイリスト要求に応答して前記セグメントプレイリストを伝送する手段とを備える請求項９に記載の装置。
12. 前記複数のメディアプログラムバージョンの第２の要求された１つの前メディアプログラムバージョンアドレスにて第２のセグメントプレイリスト要求を受信する手段を更に備え、
    前記第２のセグメントプレイリスト要求は、前記複数のメディアプログラムバージョンの前記第２の要求の１つに関連した前記複数のメディアプログラムバージョンアドレスの前記１つにアドレス指定され、前記複数のメディアプログラムバージョンアドレスの前記１つは、前記選択された広告の前記識別子を含み、
    前記装置は、更に
    前記複数のメディアプログラムバージョンの前記第２の要求の１つに関連した前記複数のメディアプログラムセグメントの各１つに関連したアドレスと、
    前記複数のメディアプログラムバージョンの前記要求の１つに関連した前記選択された広告の前記広告バージョンに関連した前記複数の広告セグメントの各１つに関連したアドレスとを有する時間的に順序づけられたリストを備える、セグメントプレイリストを前記メディアプログラムプレーヤに伝送する手段を備える請求項９に記載の装置。
13. メディアプログラムと、これと共に提示するための広告とをストリーミングする装置であって、
    各々が他と異なる提示スループットのために生成される複数のメディアプログラムバージョンを生成し、各メディアプログラムバージョンについて複数のメディアプログラムバージョンセグメントを生成するために複数のメディアプログラムバージョンセグメントに前記複数のメディアプログラムバージョンの各々をセグメント化し、各々が前記複数のメディアプログラムバージョンの１つのみに関連し、かつ、前記関連のメディアプログラムバージョンの前記提示スループットについて生成される、前記広告の複数の広告バージョンを生成し、かつ、各広告バージョンについて複数の広告バージョンセグメントを生成するために複数の広告バージョンセグメントに前記複数の広告バージョンの各々をセグメント化するコンテンツ生成器と、
    前記メディアプログラムのメディアプログラム要求を受信し、各々が前記複数のメディアプログラムバージョンの１つのみに関連する複数のメディアプログラムバージョンアドレスを備えるマスタプレイリストを前記メディアプログラムプレーヤに伝送し、かつ
    前記複数のメディアプログラムバージョンの要求の１つに関連し、かつ
    前記複数のメディアプログラムバージョンの前記要求された１つに関連した前記複数のメディアプログラムバージョンセグメントの各１つに関連したメディアプログラムバージョンセグメントアドレスと、前記複数のメディアプログラムバージョンの前記要求された１つに関連した前記広告バージョンに関連した前記複数の広告セグメントの各１つに関連した広告バージョンセグメントアドレスとを有する時間的に順序づけられたリストを備える、セグメントプレイリストを前記メディアプログラムプレーヤに伝送するコンテンツセレクタと
    を備える装置。
14. コンテンツセレクタは、
    前記メディアプログラムに関連した前記マスタプレイリストのアドレスの要求を受信する手段と、
    前記マスタプレイリストを生成して、前記選択された広告の識別子を含むマスタプレイリストアドレスにて前記マスタプレイリストを供給する手段と、
    前記メディアプログラム要求に応答して前記メディアプログラムプレーヤに前記マスタプレイリストアドレスを伝送する手段と、
    前記マスタプレイリストアドレスにてマスタプレイリスト要求を受信する手段と、
    前記マスタプレイリスト要求に応答して前記マスタプレイリストを伝送する手段とを備え、前記装置は、前記メディアプログラムと共に再生するべき１組の広告から前記広告を選択する広告サービスを更に備え、前記選択された広告は、少なくともある程度ユーザ識別子に従って選択される請求項１３に記載の装置。
15. 前記選択された広告の前記複数の広告バージョンセグメントの各々は、広告バージョンセグメント識別子に関連し、
    前記マスタプレイリストを生成する前記手段は、
    前記選択された広告の前記識別子を有する前記マスタプレイリストアドレスにて前記マスタプレイリスト要求を受信する手段と、
    各々が前記複数のメディアプログラムバージョンの１つのみに関連し、かつ、前記複数のメディアプログラムバージョンの前記要求の１つに関連した前記選択された広告の前記広告バージョンについて前記広告バージョンセグメント識別子を備える前記複数のメディアプログラムバージョンアドレスを生成する手段とを備える請求項１４に記載の装置。
16. 前記広告の前記識別子は、複数の広告識別子文字を備え、前記複数の広告バージョンセグメント識別子の各々は、前記複数の広告識別子文字を備える請求項１５に記載の装置。
17. コンテンツセレクタは、
    前記複数のメディアプログラムバージョンの前記要求の１つの前記メディアプログラムバージョンアドレスにてセグメントプレイリスト要求を受信する手段と、
    前記受信されたセグメントプレイリスト要求に応答して前記セグメントプレイリストを伝送する手段とを更に備える請求項１５に記載の装置。
18. 前記コンテンツセレクタは、
    更に、前記複数のメディアプログラムバージョンの第２の要求された１つの前メディアプログラムバージョンアドレスにて第２のセグメントプレイリスト要求を受信し、前記第２のセグメントプレイリスト要求は、前記複数のメディアプログラムバージョンの前記第２の要求の１つに関連した前記複数のメディアプログラムバージョンアドレスの前記１つにアドレス指定され、前記複数のメディアプログラムバージョンアドレスの前記１つは、前記選択された広告の前記識別子を含み、
    前記複数のメディアプログラムバージョンの前記第２の要求の１つに関連した前記メディアプログラムセグメントの各１つに関連したアドレスと、
    前記複数のメディアプログラムバージョンの前記要求の１つに関連した前記選択された広告の前記広告バージョンに関連した前記複数の広告セグメントの各１つに関連したアドレスとを有する時間的に順序づけられたリストを備える、セグメントプレイリストを前記メディアプログラムプレーヤに伝送する手段を備える請求項１５に記載の装置。

Images