JP6250821B2 - 目標メディアコンテンツの配信 - Google Patents

Description

［関連出願］
本願は、米国仮特許出願番号第６１／８９８,４２５号、２０１３年１０月３１日出願、代理人管理番号Ｐ６１９９３Ｚ、米国仮特許出願番号第６１／８７９,０１４号、２０１３年９月１７日出願、代理人管理番号Ｐ６１０２６Ｚ、及び米国非仮特許出願番号第１４／４８７,３４９号、２０１４年９月１６日出願、代理人管理番号P６６３０２の利益を請求し、これらの出願を参照することによりここに組み込む。

ストリーミング及び会話サービスを含むマルチメディアサービスの成長は、新しいモバイル広帯域技術及び標準への進化の主要因の１つである。デジタルビデオコンテンツは、モバイル装置で益々消費されている。日常生活の中でモバイル装置で幅広く使用される多くのビデオアプリケーションが存在する。例えば、オンラインビデオストリーミングは、ＹｏｕＴｕｂｅ（登録商標）及びＨｕｌｕのような有名なサービスを含む。ビデオ記録及びビデオ会議は、Ｓｋｙｐｅ及びＧｏｏｇｌｅ Ｈａｎｇｏｕｔのようなサービスを含む。２０１１年に、ＹｏｕＴｕｂｅ（登録商標）の閲覧は世界中で１兆回を超えた。閲覧の１０パーセントは、携帯電話機又はタブレットによりアクセスされた。より多くのスマートフォン、タブレット、及び他のモバイルコンピューティング装置が購入されるにつれ、ビデオ記録及びビデオ会議のためのそれらの使用は、劇的に増加するだろう。このようなメディア圧縮及び無線ネットワーク基盤における発展に伴うマルチメディアサービスへの高い消費者要求により、将来の携帯電話機及びモバイル広帯域システムのマルチキャストサービス能力を拡張し、高いＱｏＥ（quality of experience）を消費者に供給し、それにより任意の場所から任意の時間に任意の装置及び技術によるビデオコンテンツ及びサービスへのユビキタスアクセスを保証することに関心が持たれる。

本開示の特徴及び利点は、例として本開示の特徴を共に図示する添付の図面と関連する以下の詳細な説明から明らかである。
一例による、ＭＰＤ（media presentation description、メディア表現記述）メタデータファイル構成のブロック図を示す。 一例による、ＨＴＴＰ（hypertext transfer protocol）ストリーミングのブロック図を示す。 一例による、ＨＴＴＰベース（hypertext transfer protocol−based）ビデオストリーミングのためのエネルギ特性認識型無線アクセスネットワーク（radio access network：ＲＡＮ）アーキテクチャのブロック図を示す。 一例による、ＢＭＳＣ（broadcast multicast service center）の図を示す。 一例による、ＭＢＭＳ（multimedia broadcast and multicast services）ＵＳＤ（user service description）の図を示す。 一例による、複数のユーザのためのメディアコンテンツストリームへの広告の挿入を示す図である。 一例による、ＭＢＭＳ（multimedia broadcast and multicast services）ＵＳＤ（user service description）に含まれる記述の図を示す。 目標メディアコンテンツを受信するＭＢＭＳ（multimedia broadcast multicast service）を含むユーザ機器（user equipment：ＵＥ）の回路の機能を示す。 一例による目標メディアコンテンツを受信する方法のフローチャートを示す。 メディアコンテンツストリーミングをサポートするユーザ機器（ＵＥ）の回路の機能を示す。 一例による、無線装置（例えば、ＵＥ）の図を示す。

以下では、図示の例示的な実施形態を参照し、本願明細書ではそれらを説明するために固有の言語が用いられる。しかしながら、それにより本発明の範囲の如何なる限定も意図されないことが理解されるだろう。

本発明が開示され説明される前に、本発明は本願明細書に開示される特定の構造、処理ステップ又は材料に限定されず、関連分野の当業者により認識されるように、それらの等価物にまで拡張されることが理解されるべきである。本願明細書で用いられる用語は、特定の例を説明することのみを目的としており、限定を目的としていないことが理解されるべきである。異なる図中の同じ参照符号は、同じ要素を表す。フローチャート及び処理中に提供される数値は、ステップ及び動作を説明する際に明確性のために提供されるものであり、必ずしも特定の順序又は配列を示さない。

＜例示的な実施形態＞
以下に、技術的実施形態の最初の概略が提供され、次に特定の技術的実施形態が詳細に説明される。この最初の概要は、読者が技術をより迅速に理解するのを助けることを目的としており、技術の主要な特徴又は基本的特徴を特定することを意図せず、あるいは請求される主題の範囲を限定することを意図しない。

ブロードキャスト環境において、ユーザ機器（user equipment：ＵＥ）のＭＢＭＳ（multimedia broadcast multicast service）クライアントで、目標メディアコンテンツを受信し、ＵＥにおける消費のためにメディアコンテンツストリームの中の目標メディアコンテンツを再生する技術が記載される。ＭＢＭＳクライアントは、目標メディアコンテンツ（例えば、目標メディアコンテンツのファイル又はセッション）を記述するＭＰＤ（media presentation description）情報を含むサーバ（例えば、広告サーバ）からＵＳＤ（user service description）を受信できる。目標メディアコンテンツは広告を含むことができる。例えば、ＵＳＤは、目標メディアコンテンツの種々のファイル及びセッションのグループ識別情報（identification：ＩＤ）要素を含むことができる。グループＩＤ要素は、目標メディアコンテンツの種々のファイル及びセッションの記述子であり得る。例えば、グループＩＤ要素は、目標メディアコンテンツアイテムを、自動車、映画、電子機器、等に関連すると識別することができる。さらに、ＭＢＭＳクライアントは、ライブビデオ又はテレビジョン（ＴＶ）ブロードキャスト（例えば、ニュース放送、サッカーの試合）のようなストリーミングメディアコンテンツのＭＰＤ情報を含むＵＳＤを受信できる。ストリーミングメディアコンテンツは、ＢＭＳＣ（broadcast multicast service center）から受信できる。ＭＢＭＳクライアントは、ブロードキャストチャネルを傾聴し、目標メディアコンテンツアイテムに関連するグループＩＤ要素及びＵＥに関連するユーザプロファイルに基づき特定の目標メディアコンテンツアイテム（例えば、広告）をキャッシュすることを決定できる。ユーザプロファイルは、閲覧習慣の説明及び／又はＵＥのユーザの人口統計学的情報を含むことができる。言い換えると、ユーザプロファイルは、ＵＥのユーザに興味を持たせる目標メディアコンテンツの種類を特定できる。

ＭＢＭＳクライアントは、ユーザプロファイルの中で定められた関心に合うグループＩＤ要素を有する目標メディアコンテンツアイテムをキャッシュできる。ＭＢＭＳクライアントは、マージされたＭＰＤを生成するために、キャッシュした目標メディアコンテンツアイテムのＭＰＤ情報を、ストリーミングメディアコンテンツに関連するＭＰＤ情報に挿入できる。マージされたＭＰＤは、ストリーミングメディアコンテンツ及び目標メディアコンテンツの両方のためにフェッチされるべきセグメントを記述できる。ストリーミングメディアコンテンツ及び目標メディアコンテンツは、マージされたＭＰＤに従ってＵＤにおいて受信できる。ＵＥのＤＡＳＨ（dynamic adaptive streaming over HTTP）クライアントは、ストリーミングメディアコンテンツ及び目標メディアコンテンツを用いて再生を実行できる。一例では、目標メディアコンテンツアイテムは、ストリーミングメディアコンテンツが供給されている間に、所定のプレースフォルダ（placeholder）において再生できる。一例では、ストリーミングメディアコンテンツは、空の３０秒スロットを周期的に含むことができる。このスロットの中で、目標メディアコンテンツアイテムが、ＵＥのＤＡＳＨクライアントにより再生される。

ＨＴＴＰ ＨＡＳ（Hypertext transfer protocol adaptive streaming）は、インターネットビデオのマルチメディア配信の形式で使用され得る。ＨＴＴＰに基づく配信は、ＨＴＴＰと、ＴＣＰ（transmission control protocol）／ＩＰ（internet protocol）ＨＴＴＰの基礎にあるプロトコルの両方の広範な採用により、信頼性及び簡易な展開を提供できる。ＨＴＴＰに基づく配信は、ネットワークアドレス変換（network address translation：ＮＡＴ）及びファイアウォール横断問題を回避することにより、容易且つ楽なストリーミングサービスを可能にできる。ＨＴＴＰに基づく配信又はストリーミングは、標準的なＨＴＴＰサービスを使用する能力及び専用ストリーミングサーバの代わりにキャッシュを提供することもできる。ＨＴＴＰに基づく配信は、サーバ側の最小限の又は削減された状態情報により、拡張性を提供できる。

インターネットマルチメディアコンテンツを配信するためにＨＡＳを用いるとき、モバイル装置で動作するビデオクライアントは、マルチメディアサーバのような専用リソースからデータを読み出すためにＨＴＴＰ ＧＥＴ又は部分的（partial）ＧＥＴコマンドを用いてビデオサーバから適切なビデオ表現レベルを選択し及び要求することにより、レート適応において主要な役割を実行するよう構成され得る。ビデオクライアントは、オーディオ又はビデオのようなストリーミングマルチメディアコンテンツを再生し始める前に、先ず、あるレベルまでバッファを構築する。この段階は、起動段階と呼ばれる。この後、クライアントは、バッファに格納したマルチメディアコンテンツの再生を始める。クライアント装置におけるマルチメディア再生の品質及び解像度は、利用可能リンク帯域幅に依存する。ビデオクライアントは、通常、ＨＴＴＰレベルのビデオストリーミングスループットのような上位レイヤのスループット推定、又はＴＣＰ（transmission control protocol）のスループットにのみ基づき、利用可能リンク帯域幅を推定する。

高移動性環境におけるマルチメディアストリーミングは、ネットワーク状態の変動（つまり、ネットワークの変動性）がマルチメディアコンテンツに関連する通信データレートを低下させるとき、困難になり得る。過負荷ネットワークが通信データレートを低下させるとき、エンドユーザのＱｏＥ（quality of experience）も低下し得る。例えば、モバイル装置で受信されたマルチメディアコンテンツは、低い解像度又は品質であり得る、及び／又はマルチメディアコンテンツは、過負荷ネットワークを介して提供されているとき、周期的に壊れ又は停止し得る。

限られたリソースのモバイルネットワークにおけるプログレッシブダウンロードに基づくストリーミング技術の使用は、非効率な帯域幅利用及び粗悪なエンドユーザＱｏＥにより、望ましくない。以下に詳述するように、ＤＡＳＨ（dynamic adaptive streaming over HTTP）のようなＨＴＴＰ（hyper−text transfer protocol）に基づくストリーミングサービスは、プログレッシブダウンロードに基づくストリーミングの弱点を解決するために使用できる。

ユーザ機器（ＵＥ）のようなクライアントにストリーミングされるマルチメディアコンテンツは、複数のマルチメディアコンテンツセグメントを有し得る。マルチメディアコンテンツセグメントは、それぞれ、マルチメディアコンテンツの異なる品質レベルを表す異なる符号化バージョンを含み得る。異なる符号化バージョンは、クライアントに、変化するネットワーク状態にシームレスに適応することを可能にできる。例えば、ネットワーク状態が良好なとき（つまり、ネットワーク状態が所定閾より高い）、クライアントは、高いビデオ品質のマルチメディアコンテンツセグメントを要求できる。例えば、ネットワーク状態が粗悪なとき（つまり、ネットワーク状態が所定閾より低い）、クライアントは、低いビデオ品質のマルチメディアコンテンツセグメントを要求できる。その結果、クライアントは、ネットワーク状態が粗悪なときも、（低品質ではあるが）依然としてマルチメディアコンテンツセグメントを受信でき、適応型メディアストリームが中断される可能性を低減できる。

ＤＡＳＨでは、クライアントは、最高ビットレートを有するマルチメディアコンテンツセグメントを選択でき、マルチメディアコンテンツセグメントは、メディア再生において再バッファリングイベントを生じることなく、クライアントにおいてメディア再生に間に合うようにダウンロードできる。言い換えると、クライアントは、クライアントにおいてメディア再生を再開する前に、メディアコンテンツの一部をクライアントにキャッシュ又は予めロードするために、適応メディアストリームが周期的に中断されるような高いマルチメディアコンテンツセグメントを選択する必要がない。一例では、悪いネットワーク状態は、メディアコンテンツストリームの品質を劣化させ得る。悪いネットワーク状態は、カバレッジ無し（coverage nulls）、突然の帯域幅変化、パケットロス、実質的な遅延変動、等を含み得る。

適応型ストリーミング技術は、利用可能なスループットを計算し及び該利用可能なスループットに基づき適切なストリーミングビットレートを決定するとき、現在のネットワーク状態を考慮できるが、クライアントにおける円滑なメディア再生は、突然のネットワーク変動及び／又は悪いネットワーク状態の間、保証できない。

したがって、クライアントにおける適応型メディアストリームの望ましいＱｏＥを維持するために、クライアントの計画された経路及び計画された経路に沿った現在のネットワーク状態は、クライアントにおいてマルチメディアコンテンツセグメントを戦略的にキャッシュするために用いることができる。それにより、クライアントにおいて、より円滑なメディア再生及び拡張されたＱｏＥをもたらす。クライアントは、計画された経路（つまり、クライアントが始めようとする地理的経路）を選択できる。クライアントは、計画された経路を移動している間に、メディアコンテンツ（例えば、映画）をストリーミングできる。一例では、クライアントは、移動中の車の中にあるモバイル装置、又は自動車のコンピューティング装置を含み得る。クライアントは、チャネル情報データベース（channel information database：ＣＩＤ）から、計画された経路の現在のネットワーク状態を受信できる。現在のネットワーク状態は、所定閾より低い対応するネットワーク状態を有する計画された経路に沿った特定の位置（例えば、トンネル、橋、遠隔地）を有し得る。クライアントは、メディアコンテンツサーバからメディアコンテンツの追加メディアコンテンツセグメント（例えば、映画の追加セグメント）を要求し、次に、該追加メディアコンテンツセグメントをキャッシュに格納できる。クライアントが所定閾より低いネットワーク状態を有する計画された経路に沿った位置に到達すると、クライアントは、キャッシュに格納されているメディアコンテンツを再生できる。その結果、計画された経路に沿った現在のネットワーク状態が所定閾より下に低下するときでも、実質的にクライアントにおいて連続的なメディア再生が提供できる。

＜無線マルチメディア標準＞
モバイルコンピューティング装置へ、それから、又はそれらの間でマルチメディアを通信可能にするために開発された多数のマルチメディア標準が存在している。例えば、ビデオをストリーミングするのに、３ＧＰＰ（the third generation partnership project）は、オンデマンド又はライブコンテンツのユニキャストストリーミングのためのＲＴＳＰ（real−time streaming protocol）に基づくパケット交換ストリーミングサービス（packet−switched streaming services：ＰＳＳ）を定めるＴＳ（technical specification）２６．２３４（例えば、リリース１１．０．０）を開発した。さらに、プログレッシブダウンロード及びＤＡＳＨ（dynamic adaptive streaming over HTTP）を含むＨＴＴＰ（hyper−text transfer protocol）に基づくストリーミングサービスは、３ＧＰＰ ＴＳ２６．２４７（例えばリリース１１．０．０）で定められている。３ＧＰＰに基づくＭＢＭＳ（multimedia broadcast and multicast services）仕様ＴＳ２６．３４６（例えばリリース１１．０．０）は、マルチキャスト／ブロードキャストコンテンツ配信のためのストリーミング及びダウンロード技術の仕様を定める。このように、ユーザ機器（ＵＥ）のようなＤＡＳＨ／ＰＳＳ／ＭＢＭＳに基づくモバイルコンピューティング装置は、ＵＥ装置においてストリーミングされたビデオを復号化しレンダリングする。３ＧＰＰ ＴＳ２６．２４４（例えばリリース１１．０．０）の３ＧＰファイルフォーマットのサポートは、ファイルダウンロード及びＨＴＴＰに基づくストリーミングの使用例をサポートするために、これらの仕様の全部において必須である。

ビデオ会議のような従来のビデオ通信のための標準の一例は、３ＧＰＰ ＴＳ２６．１１４（例えば１１．０．０）の中で提供される。標準は、ネットワークに基づくＩＭＳ（ＩＰ（internet protocol） multimedia subsystems）を介した高度なマルチメディア会話サービス及びコンテンツの配信を可能にするＭＴＳＩ（multimedia telephony services over IMS）を定める。ＩＭＳは、３ＧＰＰ ＴＳ２６．１４０（例えばＲｅｌ．１１．０．０）で標準化されている。ＭＴＳＩに基づく送信機であるＵＥ端末は、ビデオをキャプチャし記録し、次に、該ビデオを３ＧＰＰネットワークを介してＭＴＳＩに基づく受信機であるＵＥ端末へ転送する。受信機であるＵＥ端末は、次に該ビデオを復号化しレンダリングできる。３ＧＰＰ ＴＳ２６．１４０は、３ＧＰファイルフォーマットのサポートが提供されるマルチメディア共有サービス（multimedia sharings ervices：ＭＭＳ）を用いてビデオ共有もできる。

上述の標準は、マルチメディア装置へ、それから、及び／又はそれらの間でマルチメディアを通信するために使用できる無線マルチメディア標準の一例として提供される。

このような例は、限定を意図しない。ビデオのストリーミング、会話ビデオ、又はビデオ共有を提供するために、追加の標準が使用され得る。

＜ストリーミングメディア標準＞
ＨＴＴＰストリーミング、より詳細にはＤＡＳＨ標準の更なる詳細な説明が、本発明の実施形態の環境で、本願明細書で提供される。このような詳細な説明は、限定を意図しない。以降の段落で更に説明するように、本発明の実施形態は、モバイル装置に又はモバイル装置と通信するサーバに、所望のエネルギ特性を有するマルチメディアを選択し及び／又は通信させることにより、モバイル装置へ、それから及び／又はそれらの間でマルチメディアを効率的に通信するために使用できる。マルチメディアは、標準又は非標準化通信方式を用いて通信できる。

ＨＴＴＰ（Hypertext transfer protocol）ストリーミングは、インターネットビデオのマルチメディア配信の形式で使用できる。ＨＴＴＰストリーミングでは、マルチメディアファイルは、１又は複数のセグメントに分割され、ＨＴＴＰプロトコルを用いてクライアントへ配信され得る。ＨＴＴＰに基づく配信は、ＨＴＴＰ、及びＴＣＰ（transmission control protocol）／ＩＰ（internet protocol）を含むＨＴＴＰの基礎にあるプロトコルの両方の広範な適応により、信頼性を提供し及び簡単に展開できる。ＨＴＴＰに基づく配信は、ネットワークアドレス変換（network address translation：ＮＡＴ）及びファイアウォール横断問題を回避することにより、簡単なストリーミングサービスを可能にできる。ＨＴＴＰに基づく配信又はストリーミングは、標準的なＨＴＴＰサービスを使用する能力及び専用ストリーミングサーバの代わりにキャッシュを提供することもできる。ＨＴＴＰに基づく配信は、サーバ側の最小限の又は削減された状態情報により、拡張性を提供できる。ＨＴＴＰストリーミング技術の例は、Microsoft IIS Smooth Streaming、Apple HTTP Live Streaming、及びAdobe HTTP Dynamic Streamingを含み得る。

ＤＡＳＨは、標準化されたＨＴＴＰストリーミングプロトコルである。図１に示すように、ＤＡＳＨは、サーバに格納されたメディアコンテンツ表現の構造及び異なるバージョン並びにセグメントフォーマットに関する情報を提供するＭＰＤ（media presentation description）メタデータファイル１０２のために異なるフォーマットを指定できる。ＭＰＤメタデータファイルは、他の表現との切り替え及び同期した提示のためにセグメントのメディア提示タイムラインへのマッピングを保証するよう、メディアプレイヤの初期化及びメディアコンテンツに関する情報を含む（例えば、メディアプレイヤは、コンテナフォーマット及びメディアタイミング情報を決定するために初期化セグメントを見ることができる）。ＤＡＳＨ技術は、ＭＰＥＧ（Moving Picture Experts Group）、ＯＩＰＦ（Open IPTV Forum）、及びＨｂｂＴＶ（Hybrid Broadcast Broadband TV）のような他の組織によっても標準化されている。

ＤＡＳＨクライアントは、一連のＨＴＴＰ要求−応答トランザクションを通じて、セグメントをダウンロードすることにより、マルチメディアコンテンツを受信できる。ＤＡＳＨは、モバイル装置に利用可能な帯域幅が変化するとき、メディアコンテンツの異なるビットレート表現の間で動的に切り替える能力を提供できる。したがって、ＤＡＳＨは、変動するネットワーク及び無線リンク状態、ユーザの好み、及びディスプレイ解像度、利用されるＣＰＵ（central processing unit）の種類、利用可能なメモリリソース、等のような装置能力に素早く適応できる。ＤＡＳＨの動的適応は、他のストリーミングプロトコルより短い起動遅延及び少ない再バッファリングイベントで、ユーザにより良いＱｏＥ（quality of experience）を適用できる。

ＤＡＳＨでは、図２に示すように、ＭＰＤ（media presentation description）メタデータ１０２は、ウェブ／メディアサーバ２１２に格納されたメディアコンテンツ表現の構造及び異なるバージョンに関する情報を提供できる。図１に示す例では、ＭＰＤメタデータは、本例では６０秒のような所定長を有する期間に時間的に分割される。各々の期間は、複数の適応セット１０４を有することができる。各々の適応セットは、多数の符号化されたプレースフォルダを有する１又は複数のメディアコンポーネントに関する情報を提供できる。例えば、本例における適応セット０は、異なるビットレート、モノ、ステレオ、サラウンドサウンド、等のような様々な異なる符号化されたオーディオプレースフォルダを有し得る。期間ＩＤ（Period ID）に渡るマルチメディア表現について異なる品質のオーディオを提供することに加えて、適応セット（Adaptation Set）は、異なる言語のオーディオも含むことができる。適応セットの中で提供される異なるプレースフォルダは、表現（Representation）１０６として参照される。

図１で、適応セット１は、５メガビット毎秒（Ｍｂｐｓ）、２Ｍｂｐｓ、５００キロビット毎秒（ｋｂｐｓ）又はトリックモードのような異なるビットレートでビデオを提供するとして示される。トリックモードは、マルチメディアストリーミングファイルの中の位置の探求、早送り、巻き戻し、又は他の変更のために用いることができる。さらに、ビデオは、２つの２次元（２Ｄ）及び３次元（３Ｄ）ビデオのような異なるフォーマットで利用可能になる。各々の表現１０６はセグメント情報（Segment info）１０８を含むことができる。セグメント情報は、初期化情報１１０及び実際のメディアセグメント１１２を含むことができる。本例では、ＭＰＥＧ４（ＭＰ４）ファイルは、サーバからモバイル装置へストリーミングされる。本例ではＭＰ４が用いられるが、前述のように様々な種類の異なるコーデックが使用できる。

適応セットの中のマルチメディアは、更に小さなセグメントに更に分割できる。図１の例では、適応セット１の６０秒ビデオセグメントは、各々１５秒の４個のサブセグメント１１２に更に分割される。これらの例は、限定を意図しない。適応セット及び各々のメディアセグメント若しくはサブセグメントの実際の長さは、メディアの種類、システム要件、起こり得る干渉の種類、等に依存する。実際のメディアセグメント又はサブセグメントは、１秒から数分の長さより短い長さを有することができる。

図２に示すように、ＭＰＤメタデータ情報は、モバイル装置のようなクライアント２２０へ通信され得る。モバイル装置は、ストリーミングメディアを受信し及び表示するよう構成される無線装置であり得る。一実施形態では、モバイル装置は、ストリーミングメディアを受信し及び次にそれを別の装置若しくはディスプレイ装置にレンダリングのために通信するような、この機能の一部のみを実行できる。モバイル装置は、クライアント２２０を実行するよう構成されることができる。クライアントは、ＨＴＴＰ ＧＥＴ２４０メッセージ又は一連の部分的（partial）ＧＥＴメッセージを用いて、セグメントを要求できる。クライアントは、無線リンク、装置状態又はユーザの好みの変化に反応するために、一連のセグメントのオンタイム要求及び円滑なプレイアウトを管理する又は場合によってはビットレート若しくは他の属性を調整するように、ストリーミングセッションを制御できる。

図２は、ＤＡＳＨに基づくストリーミングの枠組みを示す。ウェブ／メディアサーバ２１２の中のメディアエンコーダ２１４は、記憶又はストリーミングのためのフォーマットで、オーディオ／ビデオ入力２１０からの入力メディアを符号化できる。メディアセグメンタ２１６は、入力メディアをセグメントのシリーズに分割するために使用できる２３２。該シリーズはウェブサーバ２１８に供給できる。クライアント２２０は、ウェブサーバ（例えば、ＨＴＴＰサーバ）へ送信されるＨＴＴＰ ＧＥＴメッセージ２３４を用いて、セグメントの中で新しいデータを要求できる。

例えば、クライアント２２０のウェブブラウザ２２２は、ＨＴＴＰ ＧＥＴメッセージ２４０を用いてマルチメディアコンテンツを要求できる。ウェブサーバ２１８は、マルチメディアコンテンツのＭＰＤ２４２をクライアントに提供できる。ＭＰＤは、関連メタデータ情報として示すように、各々のセグメントのインデックス及びセグメントの対応する位置を伝達するために使用できる２５２。ウェブブラウザは、２３６に示すようにＭＰＤ２４２に関連して、セグメント毎にサーバからメディアを引き出すことができる。例えば、ウェブブラウザは、ＨＴＴＰ ＧＥＴ ＵＲＬ（frag １ req）を用いて第１のセグメントを要求できる２４４。ＵＲＬ（uniform resource locator又はuniversal resource locator）は、どのセグメントをクライアントが要求するかをウェブサーバに教えるために使用できる２５４。ウェブサーバは、第１のフラグメント（つまり、セグメント１ ２４６）を提供できる。後続のセグメントに関しては、ウェブブラウザは、ＨＴＴＰ ＧＥＴ ＵＲＬ（frag i req）を用いてセグメントｉを要求できる２４８。ここで、ｉはセグメントの整数インデックスである。その結果、ウェブサーバは、セグメントｉを提供できる２５０。セグメントは、メディアデコーダ／プレイヤ２２４により、クライアントに提示できる。

図３は、マルチメディアコンテンツを提供するＨＴＴＰサーバ３１０と、ＵＥ３３６のようなモバイル装置で動作する３ＧＰＰクライアント３３８との間のマルチメディアコンテンツ３１２の流れを示す。ＨＴＴＰサーバは、無線広域ネットワーク（wireless wide area network：ＷＷＡＮ）のコアネットワーク３２４と通信する公衆又は私設ネットワーク３２２（又はインターネット）と接続できる。一実施形態では、ＷＷＡＮは、３ＧＰＰに基づくネットワーク又はＩＥＥＥ８０２．１６に基づくネットワーク（つまり、８０２．１６−２００９）であり得る。コアネットワークは、無線アクセスネットワーク（radio access network：ＲＡＮ）３３２を介してＥＰＳ（evolved packet system）のような無線ネットワーク３３０にアクセスできる。ＲＡＮ３３２は、ノード（例えば、ｅＮＢ（evolved Node B）３３４）によりＵＥ３３６で動作するクライアントにマルチメディアコンテンツを提供できる。

一例では、ＨＴＴＰサーバ３１０は、チャネル情報データベース３５０に結合できる。チャネル情報データベース３５０は、複数の地理的位置の現在のネットワーク状態を有することができる。複数の地理的位置は、特定の道路、通り、近所、地理的領域、橋、トンネル、等を有することができる。現在のネットワーク状態は、複数の地理的位置の現在のネットワーク状態のリアルタイム監視に基づくことができる。したがって、チャネル情報データベース３５０は、現在のネットワーク状態の変動に起因して動的に更新され得る。代替で、現在のネットワーク状態は、複数の地理的位置の過去のネットワーク状態情報に基づき推定され得る。更に別の例では、現在のネットワーク状態は、クラウドソーシングされた（crowd sourced）ネットワーク状態情報を用いて決定され得る。

＜ｅＭＢＭＳ（Enhanced Multimedia Broadcast Multicast Services）＞
ＬＴＥネットワークの現行の商用化は、ｅＭＢＭＳ（Enhanced Multimedia Broadcast Multicast Services）の展開への興味を益々増大している。ＭＢＭＳ（Multimedia Broadcast Multicast Services）のＬＴＥバージョンがｅＭＢＭＳである。ＭＢＭＳは、ブロードキャスト及びマルチキャストサービスの効率的な配信を提供するために設計された１対多地点インタフェース仕様である。ＭＢＭＳは、モバイルテレビジョン（ＴＶ）及びラジオ放送、並びにファイル配信及び緊急警報にも適用できる。ｅＭＢＭＳの最初の展開は２０１４年に期待されているので、コアＭＢＭＳユーザサービス機能の性能及び使い勝手を向上することは重要である。３ＧＰＰ ＴＳ２６．３４６ リリース６−１２で仕様化されるＭＢＭＳは、３ＧＰＰにより発布されたセルラ標準のうちの１つに従って動作するセルラネットワークで利用される１対多地点システムである。ＭＢＭＳは、ブロードキャスト及びマルチキャスト技術に基づき、人気のあるメディアコンテンツを複数の受信機に効率的に配信するために設計されている。サービスレイヤにおいて、ＭＢＭＳは、トランスポートレイヤのＵＤＰ（user datagram protocol）に基づき、並びにストリーミングのためのＲＴＰ（real−time transmission protocol）及びファイル配信のためのＦＬＵＴＥ（File Delivery over Unidirectional Transport）を用いて、マルチメディアコンテンツのストリーミング及びファイルの信頼できるダウンロードの両方のための配信プロトコルを定める。

ＭＢＭＳアクセスクライアントは、ＭＢＳＣ（broadcast multicast service center）として知られるサーバから、ＵＳＤ（user service discovery）シグナリングにより、メディアデータ及びメタデータを受信できる。ＭＢＭＳは、３ＧＰＰリリース８以降に対応する３ＧＰＰに基づくＬＴＥ（Long Term Evolution）標準の中でｅＭＢＭＳ（evolved MBMS）モードとして採用されている。ＭＢＭＳダウンロード配信技術は、比較的大きな受信機集団にＭＢＭＳを介して任意の数のオブジェクトを配信するために設計されている。ＭＢＭＳダウンロードは、ＦＥＣ及びファイル修復のような信頼性を向上する幾つかの技術を定める。ダウンロード配信技術は、ＤＡＳＨセグメント及びＭＰＤ（Media Presentation Descriptions）の配信を可能にする。

ＭＢＭＳダウンロード配信は、ＨＴＴＰに基づくユニキャストダウンロード配信をオフロードするための魅力的なサービスの選択肢である。利点は、新しい非リアルタイムサービス種類のサポート、ＭＢＭＳストリーミングサービスを補完するコンテンツの提供、及び装置の記憶容量の増大の利用を可能にすることを含む。ＤＡＳＨセグメントフォーマットは、主にＨＴＴＰによるユニキャストトランスポートを意図しているが、配信環境がユニキャスト又はマルチキャストであることが分からない。ＭＢＭＳユーザサービス仕様ＴＳ２６．３４６は、ＤＡＳＨフォーマットのコンテンツがＦＬＵＴＥプロトコルによりＭＢＭＳダウンロード配信を用いて送信される可能性を示す。ＦＬＵＴＥは、ＲＦＣ３９２６で定められ、ＭＢＭＳを介してセグメントを配信させ、クライアントがＨＴＴＰ／ＴＣＰを介して配信されているそれらのセグメントを観察できるようにする。ＨＴＴＰ−ＵＲＬは、ＦＬＵＴＥの中で各々の配信されたオブジェクトに割り当てられる。ＨＴＴＰ−ＵＲＬは、ＭＰＤの中のセグメントＵＲＬにマッピングする。つまり、ＦＬＵＴＥを介して配信されたオブジェクトのＦＤＴ（File Delivery Table）の中のコンテンツ位置要素は、ＭＰＤの中のセグメントＵＲＬに一致する。ＵＥは、ＭＰＤに含まれるＨＴＴＰ ＵＲＬとＦＬＵＴＥパケットに含まれるＵＲＬ情報との比較に基づき、受信したＤＡＳＨ表現を識別できる。

図４は、ＭＢＭＳに基づくＢＭＳＣ（broadcast multicast service center）サブ機能アーキテクチャ、及びＵＥとＭＢＳＣとの間の関連するインタフェースを示す。ＢＭＳＣ又はＢＭ−ＳＣは、コンテンツプロバイダ／マルチキャストブロードキャストソースと通信し及び／又はそれを制御できる。ＢＭ−ＳＣは、ＭＢＭＳ配信機能を提供できる。ＭＢＭＳは、３ＧＰＰ ＴＳ２６．３４６の中で更に定められる。

図５は、ＭＢＭＳ（multimedia broadcast and multicast services）ＵＳＤ（user service description）の図を示す。ＢＭ−ＳＣは、サービスバンドルとして編成されたＵＳＤ（user service descriptions）の１又は複数のインスタンス化により、利用可能なＭＢＭＳサービスをアナウンスする。ＭＢＭＳユーザサービスは、ダウンロード配信方法を用いて又は双方向アナウンス機能を用いて配信されるメタデータ（オブジェクト／ファイル）により記述される。ＭＢＭＳユーザサービス発見又はアナウンスは、適切な方法でメタデータのフラグメントを複数の受信機に配信することを含む。メタデータ自体は、サービスの詳細事項を記述する。メタデータ管理情報は、メタデータフラグメントオブジェクトの識別、バージョニング、更新及び時間的有効性を可能にする（ＸＭＬフォーマットの）メタデータエンベロープオブジェクトで構成される。

図５に示すように、受信機に提供されるＵＳＤに含まれるメタデータは、単一のＭＢＭＳユーザサービス若しくはＭＢＭＳユーザサービスのバンドルの詳細事項を記述するメタデータフラグメントオブジェクト、ＭＢＭＳユーザサービスセッションの詳細事項を記述するメタデータフラグメントオブジェクト、関連する配信方法の詳細事項を記述するメタデータフラグメントオブジェクト、サービス保護の詳細事項を記述するメタデータフラグメントオブジェクト、ＦＥＣ修復データストリームの詳細事項を記述するメタデータフラグメントオブジェクト、（ＤＡＳＨコンテンツの）ＭＰＤ（Media Presentation Description）を提供するメタデータフラグメントオブジェクト、（ＤＡＳＨコンテンツの）初期化セグメントを提供するメタデータフラグメントオブジェクト、スケジュール情報記述を提供するメタデータフラグメントオブジェクト、ユーザサービスの中の所与のユーザサービスの個々のセッション又は個々のファイルコンテンツのレベルでサービスバンドルの名ＡｋのＭＢＭＳユーザサービスのためのデータのフィルタリングを提供するメタデータフラグメントオブジェクト、を含むことができる。

ビデオ配信サービス（例えば、ストリーミング、ダウンロード、ブロードキャスト、ＴＶ、等）の成長は、個人向け広告によりユーザをより良く狙うよう、並びにユーザが広告主の広告を閲覧する可能性及びユーザの需要／興味との関連性を増大するよう（つまり、スキップされる又は見られない代わりに）、広告主を駆動してきた。ｅ−ＭＢＭＳに基づくようなブロードキャストネットワークでは、広告挿入の観点から、広告は、通常、ブロードキャストの前に挿入され、広告はまるで主ビデオコンテンツのようにブロードキャストにより配信される。これは、全てのユーザが同じ広告を受信し及び個人化のための余地が残されていないので、投資の良好な見返りを得るために広告の目標を定める機会を殆ど与えない。したがって、本願明細書で詳細に記載されるように、ｅ−ＭＢＭＳを介した広告の配信は、ユーザのために個人化することができる。

ある構成では、個人向け広告は、メディアコンテンツストリームに生で（live）挿入され得る。例えば、人口集中都市の２つの有名なサッカーチームが、週末に互いにダービーマッチを行おうとしている。試合はファンの間で多大な関心を生じることが予想されるので、オペレータはＭＢＭＳを介して自身の加入者にサービスを提供することを計画する。試合コンテンツは、ＤＡＳＨフォーマットを用いてＦＬＵＴＥに基づくダウンロード配信技術に基づきブロードキャストされる。オペレータは、各々のサッカークラブのファンストアからの商品を販売促進するために、クラブファンに向けた広告の別個のセットを配信する、つまり試合の中断等の間に再生する計画である。各々のストリームについてサーバで予め挿入された異なる広告を有する主コンテンツの複数のイベントストリームをブロードキャストすることは、帯域幅の観点から高コストなので、オペレータは、広告の別個のセットと一緒に単一の主イベントストリームをブロードキャストし、広告挿入はクライアントにより実行させることにする。言い換えると、クライアントは、特定のセットに属する広告を、ストリームメディアコンテンツ、つまり単一の主イベントストリームの中の所定のプレースフォルダに挿入できる。

別の構成では、個人向け広告は、キャッシュからメディアコンテンツストリームに挿入され得る。オペレータは、モバイル装置の中のメモリ／記憶能力により現在利用可能である、ＵＥの中のコンテンツキャッシュ能力により使用可能な広告配信サービスを自身のＭＢＭＳの可能な加入者に提供できる。広告コンテンツは、ＤＡＳＨファイルフォーマットに基づくことができる。サービスに加入しているユーザのＭＢＭＳクライアント装置は、例えば理想的にはオフトラフィック又は非輻輳時間の間にスケジューリングされる、広告ブロードキャストセッションに参加し、ユーザの好み／興味に関連する広告をキャッシュできる。後の生ブロードキャストイベントの間に、ユーザは、主コンテンツストリームの中の広告の代わりに、これらの予めキャッシュされた広告のうちの１つを見ることができる。広告の個人化を可能にする上に、これは、生ストリームの中で広告ブロードキャストの間にクライアントにより粗悪なネットワーク状態が経験されるとき、特に望ましい。

したがって、個人向け広告挿入は、ＭＢＭＳ及びｅＭＢＭＳでサポートされ得る。主ブロードキャストコンテンツ（つまり、ストリーミングメディアコンテンツ）及び目標メディアコンテンツファイル（例えば、広告）は、クライアントに別個にブロードキャストされ、目標メディアコンテンツファイルの挿入は、クライアントにおいて可能にされ得る。生イベントに関して、クライアントへの個人向け広告の配信は、主ブロードキャストコンテンツへの適時の挿入のためにスケジューリングされ得る。予めキャッシュされた広告の挿入は、これらの広告が認可され特定の基準を満たす場合、例えば広告がオペレータのネットワークから前にフェッチされた場合、主ブロードキャストストリームの中の広告を置き換えることができる。さらに、ＵＥは、ユーザの好みに従う分類情報に基づき、ブロードキャストされた広告を選択的にキャッシュできる。

一例では、ＵＥのＭＢＭＳクライアントは、目標メディアコンテンツについて、ブロードキャストチャネルを傾聴できる。目標メディアコンテンツは、ＢＭＳＣ（broadcast multicast service center）からブロードキャストされ得る。各々の目標メディアコンテンツアイテムは、グループ識別情報（ＩＤ）要素及び／又は記述子と関連付けられ得る。グループＩＤ要素及び／又は記述子は、目標メディアコンテンツアイテムに関連するカテゴリを識別できる。例えば、第１のグループＩＤ要素は、第１のメディアコンテンツアイテムが自動車に関連することを識別し、第２のグループＩＤ要素は、第２の目標メディアコンテンツアイテムがスポーツに関連することを識別できる。グループＩＤ要素の他の例は、ソーシャルグループ、職業、民族グループ、等を含むことができる。グループＩＤ要素でタグ付けされた目標メディアコンテンツアイテムは、メディアコンテンツファイルであり得る。或いは代替で、目標メディアコンテンツアイテムは、メディアコンテンツセッションであり得る。ここで、メディアコンテンツセッションは複数のメディアコンテンツファイルである。

一例では、ＭＢＭＳクライアントは、ＵＳＤ（user service description）に従ってブロードキャストされる各々の目標メディアコンテンツアイテムのグループＩＤ要素を決定できる。ＭＢＭＳクライアントは、目標メディアコンテンツアイテムを送信する前に、ＢＭＳＣからＵＳＤを受信できる。ここで、ＵＳＤは、ブロードキャストされるべき目標メディアコンテンツアイテムを記述する。ＵＳＤは、目標メディアコンテンツアイテムを記述するグループＩＤ要素を含むグループフィルタ又はグループ情報を含むことができる。グループフィルタ又はグループ情報は、ＵＳＤの中のフィルタ記述メタデータフラグメントの一部であり得る。言い換えると、ＵＳＤは、電子サービスガイドに似ている。ＵＳＤは、ブロードキャストチャネル、各々のブロードキャストチャネルの配信されるべき目標メディアコンテンツアイテム、各々の目標メディアコンテンツアイテムが配信されるべき時間、目標メディアコンテンツアイテムの各々の特性（つまり、記述子又はグループＩＤ要素）、等を記述できる。グループＩＤ要素は、特定の目標メディアコンテンツアイテムが、自動車、ビデオゲーム、音楽プレイヤ、等のうちの１つに関連することを示すことができる。

別の例では、ＵＳＤは、ＵＳＤの特定の要素の中の上述のような分類／カテゴリを伝達できる。例えば、スケジュール記述要素は、ブロードキャストされるファイル（つまり、目標メディアコンテンツアイテム）に関する詳細事項を含むfileSchedule要素を含むことができる。さらに、広告の分類及びカテゴリ情報に関する記述子は、ファイル毎にブロードキャストされる広告ファイルのコンテキストの間で区別するために、要素の中に含まれ得る。つまり、各々のブロードキャストされる広告ファイルは、広告が属するカテゴリ／分類に関する記述子と関連付けられ得る。

さらに、ＭＢＭＳクライアントは、ユーザが興味を持つ目標メディアコンテンツの種類に関する分類及びカテゴリ情報についてのデータベースを維持することができる。言い換えると、ＭＢＭＳクライアントは、ユーザの閲覧習慣及び人口統計学的情報を示すＵＥの各々のユーザのユーザプロファイルを維持できる。非限定的な例として、ユーザプロファイルは、ユーザがスポーツ、自動車、及び政治に関連する広告を好むことを示すことができる。さらに、人口統計学的情報は、ユーザに関連する性別、年齢、地理的位置、等を識別できる。

ＢＭＳＣが目標メディアコンテンツファイルをブロードキャストするとき、ＭＢＭＳクライアントは、ＵＥのユーザが関心のある目標メディアコンテンツファイルを選択的にキャッシュできる。ＭＢＭＳクライアントは、ユーザプロファイルの中のユーザの興味に合う（ＵＳＤの中で示されたような）記述子を有する、ブロードキャストされたファイルを探すことができる。同様に、ＭＢＭＳクライアントは、ユーザプロファイルに含まれるグループＩＤ要素と一致するグループＩＤ要素を有する目標メディアコンテンツファイルを選択できる。言い換えると、ＭＢＭＳクライアントは、ユーザプロファイルに合うよう、知られているグループフィルタ値を有するコンテンツを選択的に受信できる。一例では、ＭＢＭＳクライアントは、ユーザプロファイルに対応するグループＩＤ要素を有する目標メディアコンテンツセッション（つまり、複数のメディアコンテンツファイル）を選択できる。ＭＢＭＳクライアントは、選択したメディアコンテンツファイルをキャッシュに格納できる。後に、ＭＢＭＳクライアントは、ＵＥにおける消費のために、メディアコンテンツストリーム（例えば、フットボールゲーム、ニュースブロードキャスト）の間、メディアコンテンツファイルを再生できる。

一例では、所与のセッションについての分類及びカテゴリ情報に関するユーザプロファイル記述子（つまり、記述子又はグループＩＤ要素）は、該セッションの中でブロードキャストされたコンテンツファイルのコンテキストの間で開始時間及び終了時間により示されるタイムスロット毎に区別するために、開始時間及び終了時間のセットと一緒に、ＵＳＤの中のsessionSchedule要素に含まれ得る。つまり、所与の時間間隔でブロードキャストされたコンテンツファイルは、目標ユーザが属するカテゴリ／分類に関するユーザプロファイル記述子と関連付けられ得る。別の例では、目標メディアコンテンツの表現形式は、目標メディアコンテンツを記述するキーワードのセットの決定に基づくことができる。これらの決定されたコンテキスト情報キーワードは、ＭＢＭＳクライアントにより保持されるデータベースにローカルに格納され、広告コンテンツを表すキーワードと照合される。コンテンツ記述キーワードがコンテキスト情報キーワードと一致する目標メディアコンテンツ（例えば、広告）は、挿入されユーザに提示されるべき目標メディアコンテンツとして識別される。

目標メディアコンテンツファイルはブロードキャストされるので、ＭＢＭＳクライアントは、全部のブロードキャストされたメディアコンテンツファイルを受信できる。しかしながら、ＭＢＭＳクライアントは、目標メディアコンテンツファイルのヘッダをパースし、ＵＥのユーザが目標メディアコンテンツファイルのこのカテゴリに興味がないことを決定できる。したがって、ＭＢＭＳクライアントは、ユーザプロファイルに対応しない目標メディアコンテンツファイルを無視できる。非限定的な例として、ＵＥのＭＢＭＳクライアントは、ＵＥに関連するユーザプロファイルがユーザは６５歳男性であると示すとき、広告が子供用玩具のためのものであると示すグループＩＤ要素を有する広告を無視することを選択できる。

一例では、広告コンテンツのセットは、別個のセッションで、ＭＢＭＳクライアントへブロードキャストされ得る。広告コンテンツは、オフトラフィック又は非輻輳時間の間のような、主コンテンツのブロードキャストの前にブロードキャストされ得る。広告コンテンツは、広告コンテンツを記述するリモート要素並びに広告に関する分類及びカテゴリ情報（例えば、スポーツ、音楽、自動車、家電、コンピュータ、食品、等）を含むメタデータと一緒に、ＭＢＭＳクライアントへ送信され得る。分類及びカテゴリ情報は、特定のＵＲＩ（uniform resource indicator）及び広告のコンテキストに等しい値と共に、各々の広告に付加されるグループＩＤ要素又は記述子を有し得る。一例では、比較的多数のユーザは、ブロードキャストによる広告の配信を正当化するために、広告の各々の分類／カテゴリを受信し及びキャッシュすることを望み得る。

後に、ＭＢＭＳクライアントは、ストリーミングメディアコンテンツ（例えば、フットボールゲームの主コンテンツブロードキャスト）を受信できる。ストリーミングメディアコンテンツは、ライブビデオ又はテレビジョン（ＴＶ）ブロードキャストを含み得る。ストリーミングメディアコンテンツは、ユーザの集合へ向けてブロードキャストされ得る。ストリーミングメディアコンテンツは、目標メディアコンテンツファイル（例えば、広告）の所定のプレースフォルダを含むことができる。例えば、ＭＢＭＳクライアントは、ＵＳＤの基づき受信されているストリーミングメディアコンテンツを知ることができる。ＭＢＭＳクライアントは、ＵＳＤをＭＢＳＣから予め受信できる。ＵＳＤは、ブロードキャストセッション及び全てのブロードキャストチャネルのブロードキャストコンテンツを記述できる。言い換えると、ＵＳＤは、ストリーミングメディアコンテンツ、及び目標メディアコンテンツファイル（例えば、広告）を記述できる。ストリーミングメディアコンテンツはＤＡＳＨフォーマットコンテンツであり得るので、ＤＡＳＨフォーマットコンテンツのＭＰＤは、ＵＳＤに含まれ得る。ＭＰＤは、ＸＭＬ（extensible markup language）ファイルであり得る。

ストリーミングメディアコンテンツと目標メディアコンテンツの両方をＵＥにおいて再生するために、ユーザプロファイルに関係のあるストリーミングメディアコンテンツと目標メディアコンテンツ（例えば、ＵＥのキャッシュに格納された目標メディアコンテンツ）の両方に関連するセグメントを識別するＭＰＤが生成され得る。ストリーミングメディアコンテンツのＭＰＤでは、期間又はプレースフォルダは、ＸＬＩＮＫを介してリモート要素を指すことができる。ここで、リモート要素は、目標メディアコンテンツファイル（例えば、広告コンテンツ）に関する情報を含む。リモート要素は、完全にＭＰＤに含まれる要素ではなく、ＸＬＩＮＫの簡単なプロファイルを用いてＨＴＴＰ−ＵＲＬによりＭＰＤの中で参照される。言い換えると、目標メディアコンテンツファイルをストリーミングメディアコンテンツに挿入するために、ＸＬＩＮＫは、ＭＰＤの中で外部ＤＡＳＨセグメント又はＤＡＳＨシーンを参照するために使用され得る。

ストリーミングメディアコンテンツの第１のＭＰＤの中で、ユーザプロファイルに関連する目標メディアコンテンツの第２のＭＰＤ（つまり、第２のＸＭＬファイル）は、ＸＬＩＮＫを用いて参照され得る。第２のＭＰＤからのリモート要素は、第１のＭＰＤに挿入され、それにより、更に大きなＭＰＤを生じる。言い換えると、２つのＸＭＬファイルは、マージされ、より大きなＭＰＤを生成する。広告は通常、異なるサーバから通信されるので、ここでの使用例は、広告挿入を目的とする。広告は、ストリーミングメディアコンテンツとは別個に管理される。広告をストリーミングメディアコンテンツ（例えば、現行のＤＡＳＨストリーム）に挿入する目的で、ＸＬＩＮＫは、広告の外部ＤＡＳＨセグメントを参照するために使用され得る。外部ＤＡＳＨセグメントに関連する第２のＭＰＤ（つまり、目的メディアコンテンツのＭＰＤ）は、より大きなＭＰＤ又はマージされたＭＰＤを生成するために、挿入され、ストリーミングメディアコンテンツの第１のＭＰＤとマージされ得る。マージされたＭＰＤは、ストリーミングメディアコンテンツ及び目的メディアコンテンツファイル（例えば、ユーザプロファイルに関連する広告）の両方のための全体のコンテンツ記述を提供できる。したがって、ＵＥは、マージされたＭＰＤを用いて、ストリーミングメディアコンテンツ及び目標メディアコンテンツの両方を再生できる。

一例では、ＵＥのＤＡＳＨクライアントは、ストリーミングメディアコンテンツのＭＰＤを、ＵＥのＭＢＭＳクライアントから受信できる。ＤＡＳＨクライアントは、ストリーミングメディアコンテンツのＭＰＤに従って、（主コンテンツブロードキャストに関連する）メディアコンテンツセグメントをフェッチし再生できる。ＤＡＳＨクライアントがＭＰＤの中でリモート要素（例えば、プレースフォルダ）を指すＸＬＩＮＫ属性を見付けると、ＤＡＳＨクライアントは、ＵＥのＭＢＭＳクライアントからリモート要素を要求できる。ＭＢＭＳクライアントは、キャッシュされたリモート要素のうちの１つ（つまり、広告コンテンツを記述するリモート要素）を選択でき、ＤＡＳＨクライアントに該リモート要素を提供する。例えば、ＭＢＭＳクライアントは、ユーザプロファイルに対応するリモート要素のうちの１つを選択できる。ＤＡＳＨクライアントは、ＭＢＭＳクライアントからリモート要素を受信し、次にリモート要素をストリーミングメディアコンテンツのＭＰＤに再構築できる。言い換えると、ＭＰＤは、リモート要素のＭＰＤ（つまり、ストリーミングメディアコンテンツと一緒に再生されるべき目標メディアコンテンツを記述するＭＰＤ）を含むよう再構成され得る。例えば、リモート要素に関連するＭＰＤは、元のＭＰＤとマージされ得る。ＤＡＳＨクライアントは、再構成されたＭＰＤに従って、リモート要素により記述されるセグメント（つまり、個人向け広告に対応するセグメント）をフェッチし始めることができる。ＤＡＳＨクライアントは、ＭＢＭＳクライアントのキャッシュからセグメントをフェッチし、ＵＥで表示するためにセグメントを提供できる。再構成されたＭＰＤに基づき、ＤＡＳＨクライアントは、ストリーミングメディアコンテンツ及び目標メディアコンテンツの両方を再生できる。

異なるユーザプロファイルは異なるうえに関連付けられ得るので、各々のＭＰＤは、どの広告がユーザプロファイルに対応するかに依存して、異なる方法で構成され得る。例えば、第１のＵＥの中の第１のＭＢＭＳクライアントは、ブロードキャストされているアクション映画のＤＡＳＨセグメントを記述するＭＰＤを受信できる。第２のＵＥの中の第２のＭＢＭＳクライアントは、同じＭＰＤを受信できる。言い換えると、両方のＵＥは、アクション映画のブロードキャストを受信できる。しかしながら、第１のＵＥに関連するユーザプロファイルは、ユーザが自動車の広告を好むことを示し得る。したがって、第１のＭＢＭＳクライアントは、ＭＰＤを再構成して、再構成されたＭＰＤの中で参照されるリモート要素が自動車の広告に関連するようにできる。他方で、第２のＵＥに関連するユーザプロファイルは、ユーザが子供用玩具を好むことを示し得る。したがって、第２のＭＢＭＳクライアントは、ＭＰＤを再構成して、再構成されたＭＰＤの中で参照されるリモート要素が玩具の広告に関連するようにできる。ユーザプロファイルに基づき、同じアクション映画（つまり、主コンテンツストリーム）を観ているユーザは、異なる目標メディアコンテンツファイル、例えば自動車の広告又は玩具の広告を受信できる。各々のＵＥは、ブロードキャストリモート要素の中の（例えば、ユーザが興味を持っている広告に関連する）異なるリモート要素を探し、該リモート要素をＵＥ自身のＭＰＤの構築に挿入できる。

ある構成では、ライブブロードキャストイベント設定を考慮し、主コンテンツストリーム及び広告ストリームは、ＵＥのＭＢＭＳクライアントに同時にブロードキャストされ得る。

言い換えると、この構成では、ＭＢＭＳクライアントは、主コンテンツストリームがブロードキャストされる前に、オフトラフィック又は非輻輳期間の間に広告を受信しなくても良い。広告ストリームはＵＥで直ちに消費されないので、広告ストリームは、主コンテンツストリームに比べて相対的に低いレートに関連付けられ得る。ＵＥのＭＢＭＳクライアントは、主コンテンツに適時挿入するために、広告をキャッシュできる。広告は、主ストリームと並列に送信され得る。また、ＭＢＭＳクライアントは両者を受信することが期待される。ＢＭ−ＳＣは、主コンテンツ送信及び広告配信をスケジューリングし、広告が主コンテンツに挿入されるために適時に到着するようにできる。ＢＭ−ＳＣはＭＰＤ更新を制御し、広告を指すＸＬＩＮＫに基づくリモート要素が現れ得るので、ＢＭ−ＳＣは、ＸＬＩＮＫに基づくリモート要素でＭＰＤを更新する前に、確実に広告を受信できる。

一例では、リモート要素は、このＵＲＬへのＨＴＴＰ ＧＥＴ要求を発行した結果として、ＤＡＳＨクライアントがＨＴＴＰ応答の本体の中で文字通り１又は複数の要素を受信するとき、解明され得る。リモート要素から得られた属性及び要素は、@xlink:hrefを含むＭＰＤの要素に追加され、ＭＰＤの中に既に存在する要素にマージされ得る。同じ属性がＭＰＤ及びリモート要素の両方の中に存在する場合、属性値は同じであり得る。それらが同一でない場合、ＭＰＤの属性の値は、リモートＤＡＳＨ要素の中の属性の値に優先し得る。

ある構成では、オペレータは、予め広告をブロードキャストでき、各々のＭＢＭＳクライアントは、後の、例えばＤＡＳＨを用いたライブブロードキャストイベントの間の、閲覧のために関心のある広告をフェッチしキャッシュできる。各々のブロードキャストされた広告コンテンツは、ここでも（ＤＡＳＨコンテンツに挿入するために）リモート要素を、及び広告コンテンツに関する分類及びカテゴリ情報を含む記述子メタデータを伴う。したがって、ＭＢＭＳクライアントは、各々の広告コンテンツを選択的に受信しキャッシュできる。

図６は、複数のユーザのためのメディアコンテンツストリームへの広告の挿入を示す図６００である。ＢＭＳＣ（broadcast multicast service center）６０２は、メディアコンテンツストリームのための複数の期間をブロードキャストできる。例えば、主コンテンツストリームは、ＤＡＳＨコンテンツの５個の期間、つまり期間（Period）１〜５に分けられ得る。主コンテンツストリームの中の期間は、ＭＰＤ（media presentation description）の中で記述され得る。ユーザ機器（ＵＥ）のＭＢＭＳ（multimedia broadcast and multicast services）クライアントは、ＭＰＤに従ってＢＭＳＣ６０２からメディアコンテンツストリームを受信できる。

ＭＢＭＳクライアントは、メディアコンテンツストリームの前に又はそれと同時に、ＭＢＳＣ６０２からブロードキャストされる広告についてブロードキャストチャネルを傾聴できる。例えば、広告は、５個の別個の広告、つまりａｄ１〜ａｄ５を有し得る。各々の広告は、リモート要素及び記述子を伴うことができる。ＭＢＭＳクライアントは、ＵＥのユーザに関連するユーザプロファイルに基づき、ＭＢＭＳクライアントにおいてどの広告を受信しキャッシュすべきかを決定できる。したがって、ＭＢＭＳクライアントは、ユーザプロファイルに対応する記述子を有する広告をキャッシュでき、ユーザプロファイルに対応しない記述子を有する広告を無視できる。ユーザプロファイルに依存して、異なるＭＢＭＳクライアントは、異なる種類の広告をキャッシュすることを決定できる。

ＵＥのＤＡＳＨクライアントは、ブロードキャストされた主コンテンツを、及びＭＰＤに従って広告を、再生できる。一例として、ＭＰＤは、期間２と期間３との間に、ＸＬＩＮＫによるリモート要素を含むことができる。リモート要素は、メディアコンテンツストリームの間の期間２と期間３との間に挿入されるべき広告を参照できる。ＤＡＳＨクライアントは、ＭＢＭＳクライアントからリモート要素を要求できる。これに応答して、ＭＢＭＳクライアントは、ユーザプロファイルに対応するリモート要素をＤＡＳＨクライアントに提供できる。ＤＡＳＨクライアントは、次に、リモート要素に関連する広告コンテンツを読み出し、該広告コンテンツをメディアコンテンツストリームと一緒に再生できる。非限定的な例として、第１のＤＡＳＨクライアントは、期間１、期間２、ａｄ４、期間４及び期間５を再生できる。第２のＤＡＳＨクライアントは、期間１、期間２、ａｄ３、期間４及び期間５を再生できる。ユーザプロファイルに依存して、異なるＤＡＳＨクライアントは、異なる種類の広告を再生できる。

図７は、ＭＢＭＳ（multimedia broadcast and multicast services）ＵＳＤ（user service description）に含まれ得る例示的な記述子７００である。記述子は、ユーザプロファイル記述子としても参照され得る。記述子は、ＢＭＳＣからブロードキャストされる目標メディアコンテンツファイルに関連付けられ得る。記述子は、目標メディアコンテンツファイルの分類又はカテゴリを記述できる。例えば、記述子は、特定の目標メディアコンテンツファイルが自動車の広告又は携帯電話の広告に関連することを示すことができる。記述子は、ＵＳＤのsessionSchdule要素又はfileSchedule要素に挿入されるＸＭＬ構造であり得る。記述子は、アクセス制御、識別情報、関心、コンテキスト、端末プロファイル、好み及び情報のような複数のフィールドを有し得る。

別の例は、図８のフローチャートに示すように、目標メディアコンテンツを受信するよう動作するＭＢＭＳ（multimedia broadcast multicast service）クライアントを含むユーザ機器（ＵＥ）の回路の機能８００を提供する。機能は方法として実施され得る。あるいは、機能は機械において命令として実行され得る。ここで、命令は、少なくとも１つのコンピュータ可読媒体若しくは非一時的機械可読記憶媒体に含まれる。ブロック８１０のように、回路は、第１のメタデータをサーバからＭＢＭＳを介して受信するよう構成され得る。第１のメタデータは、目標メディアコンテンツに対応する１又は複数のファイル又はセッションのグループ情報と、該ファイル又はセッションに関連するＭＰＤ（media presentation description）情報を含む。ここで、グループ情報の中の各々のファイル及びセッションは、グループ情報に含まれるグループ識別情報（ＩＤ）に関連付けられる。ブロック８２０のように、回路は、ＭＢＭＳを介して、ストリーミングメディアコンテンツのＭＰＤ情報を含むＵＳＤの中の第２のメタデータを受信するよう構成され得る。ブロック８３０で、回路は、ＵＥのユーザに関連するユーザプロファイルを識別するよう構成され得る。ここで、ユーザプロファイルは、ユーザに関連するグループＩＤ要素を含む。ブロック８４０のように、回路は、ユーザプロファイルに含まれるグループＩＤ要素を有するファイル又はセッションに対応する目標メディアコンテンツを選択するよう構成され得る。ブロック８５０のように、回路は、ユーザプロファイルに含まれるグループＩＤ要素を有する選択された目標メディアコンテンツの目標ＭＰＤ情報を、ストリーミングメディアコンテンツのＭＰＤ情報に挿入して、マージされたＭＰＤを生成するよう構成され得る。ブロック８６０のように、回路は、マージされたＭＰＤに従って、ＭＢＭＳクライアントを介して、選択された目標メディアコンテンツを受信するよう構成され得る。ブロック８７０のように、回路は、マージされたＭＰＤに従って、ＭＢＭＳクライアントを介して、ストリーミングメディアコンテンツを受信するよう構成され得る。ブロック８８０のように、回路は、選択された目標メディアコンテンツ及びストリーミングメディアコンテンツを用いて、ＵＥにおいて再生を実行するよう構成され得る。

一例では、目標メディアコンテンツは広告を含む。別の例では、ユーザプロファイルの中のユーザに関連するグループＩＤ要素は、ユーザの閲覧習慣、又はユーザを記述する人口統計学的情報の内の１つに関連する。更に別の例では、回路は、ＭＢＭＳクライアントを介して受信された選択された目標メディアコンテンツをＵＥにあるキャッシュに格納し、該ＵＥにあるキャッシュに格納された選択された目標メディアコンテンツを用いて、ＵＥにおいて再生を実行するよう更に構成され得る。

ある構成では、回路は、選択された目標メディア及びストリーミングメディアコンテンツをＢＭＳＣ（broadcast multicast service center）から受信するよう更に構成され得る。別の構成では、回路は、ＭＢＭＳを介して広告サーバから第１のメタデータを受信するよう更に構成され得る。一例では、サーバから受信される第１のメタデータは、目標メディアコンテンツを記述するＭＢＭＳ ＵＳＤ（user service description）及び目標メディアコンテンツファイルに関連するグループＩＤ要素に含まれる。別の例では、ＵＥは、アンテナ、タッチ感応ディスプレイスクリーン、スピーカ、マイクロフォン、グラフィックプロセッサ、アプリケーションプロセッサ、内部メモリ、又は不揮発性メモリポートを有する。

別の例は、図９のフローチャートに示すように、目標メディアコンテンツを受信する方法９００を提供する。方法は機械において命令として実行できる。ここで、命令は、少なくとも１つのコンピュータ可読媒体若しくは非一時的機械可読記憶媒体に含まれる。ブロック９１０のように、方法は、第１のメタデータをサーバからユーザ機器（ＵＥ）の中のＭＢＭＳ（multimedia broadcast multicast service）クライアントを介して受信する工程を含み得る。第１のメタデータは、目標メディアコンテンツに対応する１又は複数のファイル又はセッションのグループ情報と、該ファイル又はセッションに関連するＭＰＤ（media presentation description）情報を含む。ここで、グループ情報の中の各々のファイル及びセッションは、グループ情報に含まれるグループ識別情報（ＩＤ）に関連付けられる。ブロック９２０のように、方法は、ＵＥのユーザに関連するユーザプロファイルを識別する工程を含み得る。ここで、ユーザプロファイルは、ユーザに関連するグループＩＤ要素を含む。ブロック９３０のように、方法は、ユーザプロファイルに含まれるグループＩＤ要素を有するファイル又はセッションに対応する目標メディアコンテンツを選択する工程を含み得る。ブロック９４０のように、方法は、選択された目標メディアコンテンツをＵＥの中のＭＢＭＳクライアントを介して受信する工程を含み得る。さらに、ブロック９５０のように、方法は、選択された目標メディアコンテンツをＵＥにあるキャッシュに格納する工程を含み得る。

ある構成では、方法は、ＭＢＭＳを介して、ストリーミングメディアコンテンツのＭＰＤ情報を含むＵＳＤ（user service description）の中の第２のメタデータを受信する工程と、ユーザプロファイルに含まれるグループＩＤ要素を有する選択された目標メディアコンテンツの目標ＭＰＤ情報を、ストリーミングメディアコンテンツのＭＰＤ情報に挿入して、マージされたＭＰＤを生成する工程と、マージされたＭＰＤに従ってＭＢＭＳクライアントを介してストリーミングメディアコンテンツを受信する工程と、ＵＥにあるキャッシュに格納された選択された目標メディアコンテンツ及びストリーミングメディアコンテンツを用いて、ＵＥにおいて再生を実行する工程と、を含み得る。

一例では、目標メディアコンテンツは広告を含む。別の例では、ユーザプロファイルの中のユーザに関連するグループＩＤ要素は、ユーザの閲覧習慣、又はユーザを記述する人口統計学的情報の内の１つに関連する。更に別の構成では、方法は、選択された目標メディア及びストリーミングメディアコンテンツをＢＭＳＣ（broadcast multicast service center）から受信する工程を含み得る。

ある構成では、目標メディアコンテンツに対応するファイル又はセッションは、ＤＡＳＨ（dynamic adaptive streaming over hypertext transfer protocol）フォーマットファイル又はセッションを含む。別の構成では、方法は、ＭＢＭＳを介して広告サーバから第１のメタデータを受信する工程を含み得る。更に別の例では、サーバから受信される第１のメタデータは、目標メディアコンテンツを記述するＭＢＭＳ ＵＳＤ（user service description）及び目標メディアコンテンツファイルに関連するグループＩＤ要素に含まれる。

図１０のフローチャートに示すように、別の例は、メディアコンテンツストリーミングをサポートするよう動作するユーザ機器（ＵＥ）の回路の機能１０００を提供する。機能は方法として実施され得る。あるいは、機能は機械において命令として実行され得る。ここで、命令は、少なくとも１つのコンピュータ可読媒体若しくは非一時的機械可読記憶媒体に含まれる。ブロック１０１０のように、回路は、第１のＵＳＤ（user service description）フラグメントをＵＥのＭＢＭＳ（multimedia broadcast multicast service）クライアントを介して受信するよう構成され得る。第１のＵＳＤフラグメントは、広告に対応する１又は複数のファイル又はセッションのグループ情報と、該ファイル又はセッションに関連するＭＰＤ（media presentation description）情報と、を含む。ここで、グループ情報の中の各々のファイル及びセッションは、グループ情報に含まれるグループ識別情報（ＩＤ）に関連付けられる。ブロック１０２０のように、回路は、ＵＥのＭＢＭＳクライアントを介して、ＢＭＳＣ（broadcast multicast service center）から、ストリーミングメディアコンテンツのＭＰＤ情報を含む第２のＵＳＤフラグメントを受信するよう構成され得る。ブロック１０３０で、回路は、ＵＥのユーザに関連するユーザプロファイルを識別するよう構成され得る。ここで、ユーザプロファイルは、ユーザに関連するグループＩＤ要素を含む。ブロック１０４０のように、回路は、ユーザプロファイルに含まれるグループＩＤ要素を有するファイル又はセッションに対応する広告を選択するよう構成され得る。ブロック１０５０のように、回路は、ユーザプロファイルに含まれるグループＩＤ要素を有する選択された広告の目標ＭＰＤ情報を、ストリーミングメディアコンテンツのＭＰＤ情報に挿入して、マージされたＭＰＤを生成するよう構成され得る。ブロック１０６０のように、回路は、マージされたＭＰＤに従って、ＵＥのＭＢＭＳクライアントを介して、ス選択された広告を受信するよう構成され得る。ブロック１０７０のように、回路は、マージされたＭＰＤに従って、ＭＢＭＳクライアントを介して、ＢＭＳＣから、ストリーミングメディアコンテンツを受信するよう構成され得る。さらに、ブロック１０８０のように、回路は、選択された広告及びストリーミングメディアコンテンツを用いて、ＵＥにおいて再生を実行するよう構成され得る。ここで、広告は、ストリーミングメディアコンテンツの間に再生される。

ある構成では、広告に対応するファイル又はセッションは、ＤＡＳＨ（dynamic adaptive streaming over hypertext transfer protocol）フォーマットファイル又はセッションを含む。別の例では、回路は、ＭＢＭＳクライアントを介して受信された選択された広告をＵＥにあるキャッシュに格納し、該ＵＥにあるキャッシュに格納された選択された広告を用いて、ＵＥにおいて再生を実行するよう更に構成され得る。更に別の例では、再生は、ＵＥのＤＡＳＨ（dynamic adaptive streaming over hypertext transfer protocol）クライアントにおいて生じる。

図１１は、ユーザ機器（ＵＥ）、移動局（ＭＳ）、モバイル無線装置、モバイル通信装置、タブレット、ハンドセット、又は他の種類の無線装置のような無線装置の例示的説明を提供する。無線装置は、ノード又は基地局（ＢＳ）、ｅＮＢ（evolved Node B）、ベースバンドユニット（baseband unit：ＢＢＵ）、ＲＲＨ（remote radio head）、ＲＲＥ（remote radio equipment）、中継局（ＲＳ）、無線機器（radio equipment：ＲＥ）、ＲＲＵ（remote radio unit）、ＣＰＭ（central processing module）若しくは他の種類の無線広域ネットワーク（wireless wide area network：ＷＷＡＮ）アクセスポイントのような送信局と通信するよう構成される１又は複数のアンテナを有し得る。無線装置は、３ＧＰＰ ＬＴＥ、ＷｉＭＡＸ、ＨＳＰＡ（High Speed Packet Access）、Ｂｌｕｅｔｏｏｔｈ（登録商標）及びＷｉＦｉを含む少なくとも１つの無線通信規格を用いて通信するよう構成され得る。無線装置は、無線通信規格毎に別個のアンテナを又は複数の無線通信規格のための共有アンテナを用いて通信できる。無線装置は、ＷＬＡＮ（wireless local area network）、ＷＰＡＮ（wireless personal area network）、及び／又はＷＷＡＮ内で通信できる。

図１１は、無線装置からの音声入力及び出力のために用いられ得るマイクロフォン及び１又は複数のスピーカの説明も提供する。ディスプレイスクリーンは、ＬＣＤ（liquid crystal display）スクリーン、又はＯＬＥＤ（organic light emitting diode）ディスプレイのような他の種類のディスプレイスクリーンであり得る。ディスプレイスクリーンは、タッチスクリーンのように構成され得る。タッチスクリーンは、容量性、抵抗性、又は別の種類のタッチスクリーン技術を用いることができる。アプリケーションプロセッサ及びグラフィックプロセッサは、処理及び表示能力を提供するために内部メモリに結合され得る。不揮発性メモリポートも、ユーザに入力／出力オプションを提供するために用いられ得る。不揮発性メモリポートは、無線装置のメモリ容量を拡張するために用いられ得る。キーボードは、追加ユーザ入力を提供するために、無線装置に統合され又は無線装置に無線接続され得る。仮想キーボードは、タッチスクリーンを用いて提供され得る。

種々の技術又はその特定の態様若しくは部分は、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ（compact disc−read−only memory）、ハードドライブ、非一時的コンピュータ可読記憶媒体、又は任意の他の機械可読記憶媒体のような有形媒体に具現化されるプログラムコード（つまり、命令）の形式をとることができ、プログラムコードがコンピュータのような機械に読み込まれ実行されると、該機械は、種々の技術を実施するための装置になる。回路は、ハードウェア、プログラムコード、実行可能コード、コンピュータ命令、及び／又はソフトウェアを有し得る。非一時的コンピュータ可読記憶媒体は、信号を含まないコンピュータ可読記憶媒体であり得る。プログラム可能なコンピュータでプログラムコードが実行される場合、コンピューティング装置は、プロセッサ、該プロセッサにより読み取り可能な記憶媒体（揮発性及び不揮発性メモリ、及び／又は記憶素子を含む）、少なくとも１つの入力装置、及び少なくとも１つの出力装置を含み得る。揮発性及び不揮発性メモリ及び／又は記憶素子は、ＲＡＭ（random−access memory）、ＥＰＲＯＭ（erasable programmable read only memory）、フラッシュドライブ、光ドライブ、磁気ハードドライブ、固体ドライブ、又は電子データを格納する他の媒体である得る。ノード及び無線装置は、通信機モジュール（つまり、通信機）、カウンタモジュール（つまり、カウンタ）、処理モジュール（つまり、プロセッサ）、及び／又はクロックモジュール（つまり、クロック）若しくはタイマモジュール（つまり、タイマ）を有し得る。ここに記載した種々の技術を実施し又は利用し得る１又は複数のプログラムは、ＡＰＩ（application programming interface）、再利用可能制御、等を用いることができる。このようなプログラムは、コンピュータシステムと通信するために、高度な手続き又はオブジェクト指向プログラミング言語で実装され得る。しかしながら、プログラムは、望ましい場合には、アセンブラ又は機械語で実装され得る。いずれの場合にも、言語は、コンパイルされた又はインタープリットされた言語であり得、ハードウェア実装と結合され得る。

理解されるべきことに、本願明細書に記載の機能ユニットの多くは、それらの実装独立性を特に強調するために、モジュールとしてラベル付けされた。例えば、モジュールは、カスタムＶＬＳＩ（very−large−scale integration）回路又はゲートアレイ、ロジックチップ、トランジスタ若しくは他の個別部品のようなオフザシェルフ（off−the−shelf）半導体を有するハードウェア回路として実装され得る。モジュールは、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイス、等のようなプログラマブルハードウェア素子内に実装され得る。

モジュールは、種々の種類のプロセッサにより実行されるソフトウェアで実装され得る。例えば、実行可能コードの識別されるモジュールは、例えばオブジェクト、プロシジャ又は関数として編成され得るコンピュータ命令の１又は複数の物理又は論理ブロックを有し得る。しかしながら、識別されるモジュールの実行ファイルは、物理的に一緒に配置される必要はなく、論理的に一緒にされるとモジュールを有しモジュールの提示される目的を達成する異なる場所に格納される別個の命令を有し得る。

実際に、実行可能コードのモジュールは、単一命令又は多くの命令であり、幾つかの異なるコードセグメントに渡り、異なるプログラムの間で、及び幾つかのメモリ装置に渡り分散され得る。同様に、運用データは、ここにモジュール内で識別され示され、任意の適切な形式で実装され、任意の適切な種類のデータ構造で編成され得る。運用データは、単一データセットとして集められ、異なる記憶装置に渡ることを含む異なる場所に渡り分散され、少なくとも部分的にシステム又はネットワーク上の電子信号として単に存在し得る。モジュールは、所望の機能を実行するよう動作するエージェントを含み、受動的又は能動的であり得る。

本願明細書を通じて「一例」又は「例示的」という言及は、その例と関連して記載された特定の特徴、構造、機能又は特性が本発明の少なくとも１つの実施形態に含まれることを意味する。したがって、本願明細書を通じて種々の場所にある「一例では」という表現又は「例示的な」という語の出現は、必ずしも全て同じ実施形態を参照していない。

ここで用いられるように、複数の用語、構造的要素、組成要素、及び／又は材料は、便宜のために共通のリストに現れ得る。しかしながら、これらのリストは、該リストの各構成要素が別個の及びユニークな構成要素として個々に識別されるものと考えられるべきである。したがって、このようなリストのいかなる個々の構成要素も、断りのない限り、事実上、共通グループ内での出現に基づき同じリストの任意の他の構成要素の等価物として考えられるべきである。さらに、本発明の種々の実施形態及び例は、その種々の成分の代替物とともにここで言及され得る。理解されるべきことに、このような実施形態、例、及び代替は、事実上互いの等価物として考えられるべきではないが、本発明の別個の及び自主的表現として考えられるべきである。

更に、記載の特徴、構造又は特性は、１又は複数の実施形態において、任意の適切な方法で結合され得る。以下の記載では、本発明の実施形態の完全な理解を提供するために、レイアウトの例、距離、ネットワーク例、等のような多くの特定の詳細事項が提供される。しかしながら、当業者は、本発明が特定の詳細事項のうちの１又は複数がなくても又は他の方法、コンポーネント、レイアウト、等で実施できることを理解するだろう。他の例では、良く知られた構造、材料又は動作は、本発明の態様を不明瞭にしないために詳細に示されず又は記載されない。

前述の例は１又は複数の特定の用途における本発明の原理の説明であるが、当業者には、発明力を行使しないで及び本発明の原理及び概念から逸脱することなく、実装の形式、使用方法及び詳細事項において多くの変更を行うことができることが明らかである。したがって、以下に記載の請求の範囲を除いて、本発明は限定されるものではない。

Claims (26)

1. 目標メディアコンテンツを受信するよう動作するＭＢＭＳ（multimedia broadcast multicast service）クライアントを有するユーザ機器（ＵＥ）であって、前記ＵＥは回路を有し、前記回路は、
   ＭＢＭＳによりサーバから第１のメタデータを受信し、前記第１のメタデータは、目標メディアコンテンツに対応する１又は複数のファイル又はセッションのグループ情報と、前記ファイル又はセッションに関連するＭＰＤ（media presentation description）情報と、を有し、前記グループ情報の中の各々のファイル又はセッションは、前記グループ情報に含まれるグループ識別（ＩＤ）要素と関連し、
   ＭＢＭＳにより、ストリーミングメディアコンテンツのＭＰＤ情報を含むＵＳＤ（user service description）の中の第２のメタデータを受信し、
   前記ＵＥのユーザに関連するユーザプロファイルを識別し、前記ユーザプロファイルは前記ユーザに関連するグループＩＤ要素を有し、
   前記ユーザプロファイルに含まれる前記グループＩＤ要素に関連付けられるファイル又はセッションに対応する目標メディアコンテンツを選択し、
   前記ユーザプロファイルに含まれる前記グループＩＤ要素を有する前記選択された目標メディアコンテンツの目標ＭＰＤ情報を、前記ストリーミングメディアコンテンツのＭＰＤ情報に挿入して、マージされたＭＰＤを生成し、
   前記ＭＢＭＳクライアントにより、前記マージされたＭＰＤに従って、前記選択された目標メディアコンテンツを受信し、
   前記ＭＢＭＳクライアントにより、前記マージされたＭＰＤに従って、前記ストリーミングメディアコンテンツを受信し、
   前記選択された目標メディアコンテンツ及び前記ストリーミングメディアコンテンツを用いて、前記ＵＥにおいて再生を実行する、
   よう構成される、ＵＥ。
2. 前記目標メディアコンテンツは、広告を含む、請求項１に記載の回路。
3. 前記ユーザプロファイルの中のユーザに関連するグループＩＤ要素は、前記ユーザの閲覧習慣、又は前記ユーザを記述する人口統計学的情報、のうちの１つに関連する、請求項１に記載の回路。
4. 前記ＵＥにあるキャッシュに、前記ＭＢＭＳクライアントにより受信された前記選択された目標メディアコンテンツを格納し、
   前記ＵＥにある前記キャッシュに格納された前記選択された目標メディアコンテンツを用いて、前記ＵＥにおいて再生を実行する、
   よう更に構成される請求項１に記載の回路。
5. ＢＭＳＣ（broadcast multicast service center）から、前記選択された目標メディアコンテンツ及び前記ストリーミングメディアコンテンツを受信するよう更に構成される請求項１に記載の回路。
6. ＭＢＭＳにより広告サーバから、前記第１のメタデータを受信するよう更に構成される請求項１に記載の回路。
7. 前記サーバから受信される前記第１のメタデータは、ＭＢＭＳ ＵＳＤ（user service description）に含まれ、前記ＭＢＭＳ ＵＳＤは前記目標メディアコンテンツ及び前記目標メディアコンテンツに関連する前記グループＩＤ要素を記述する、請求項１に記載の回路。
8. 前記ＵＥは、アンテナ、タッチ感応ディスプレイスクリーン、スピーカ、マイクロフォン、グラフィックプロセッサ、アプリケーションプロセッサ、内部メモリ、又は不揮発性メモリポートを有する、請求項１に記載の回路。
9. 目標メディアコンテンツを受信する方法であって、前記方法は、
   ユーザ機器（ＵＥ）の中のＭＢＭＳ（multimedia broadcast multicast service）クライアントによりサーバから第１のメタデータを受信するステップであって、前記第１のメタデータは、目標メディアコンテンツに対応する１又は複数のファイル又はセッションのグループ情報と、前記ファイル又はセッションに関連するＭＰＤ（media presentation description）情報と、を有し、前記グループ情報の中の各々のファイル又はセッションは、前記グループ情報に含まれるグループ識別（ＩＤ）要素に関連付けられる、ステップと、
   前記ＵＥのユーザに関連するユーザプロファイルを識別するステップであって、前記ユーザプロファイルは、前記ユーザに関連するグループＩＤ要素を有する、ステップと、
   前記ユーザプロファイルに含まれるグループＩＤ要素に関連付けられるファイル又はセッションに対応する目標メディアコンテンツを選択するステップと、
   前記ＵＥの中の前記ＭＢＭＳクライアントにより、前記選択された目標メディアコンテンツを受信するステップと、
   前記ＵＥにあるキャッシュに、前記選択された目標メディアコンテンツを格納するステップと、
   を有する方法。
10. ＭＢＭＳにより、ストリーミングメディアコンテンツのＭＰＤ情報を含むＵＳＤ（user service description）の中の第２のメタデータを受信するステップと、
    前記ユーザプロファイルに含まれるグループＩＤ要素を有する前記選択された目標メディアコンテンツの目標ＭＰＤ情報を、前記ストリーミングメディアコンテンツのＭＰＤ情報に挿入して、マージされたＭＰＤを生成するステップと、
    前記マージされたＭＰＤに従って前記ＭＢＭＳクライアントにより前記ストリーミングメディアコンテンツを受信するステップと、
    前記ＵＥにある前記キャッシュに格納された前記選択された目標メディアコンテンツ及び前記ストリーミングメディアコンテンツを用いて、前記ＵＥにおいて再生を実行するステップと、
    を更に有する請求項９に記載の方法。
11. 前記目標メディアコンテンツは、広告を含む、請求項９に記載の方法。
12. 前記ユーザプロファイルの中の前記ユーザに関連する前記グループＩＤ要素は、前記ユーザの閲覧習慣、又は前記ユーザを記述する人口統計学的情報、のうちの１つに関連する、請求項９に記載の方法。
13. ＢＭＳＣ（broadcast multicast service center）から、前記選択された目標メディアコンテンツ及び前記ストリーミングメディアコンテンツを受信するステップ、を更に有する請求項１０に記載の方法。
14. 前記目標メディアコンテンツに対応する前記ファイル又はセッションは、ＤＡＳＨ（dynamic adaptive streaming over hypertext transfer protocol）フォーマットファイル又はセッションを含む、請求項９に記載の方法。
15. ＭＢＭＳにより広告サーバから、前記第１のメタデータを受信するステップ、を更に有する請求項９に記載の方法。
16. 前記サーバから受信される前記第１のメタデータは、ＭＢＭＳ ＵＳＤ（user service description）に含まれ、前記ＭＢＭＳ ＵＳＤは前記目標メディアコンテンツ及び前記目標メディアコンテンツに関連する前記グループＩＤ要素を記述する、請求項９に記載の方法。
17. プロセッサに請求項９の方法を実行させるコンピュータプログラム。
18. メディアコンテンツストリーミングをサポートするよう動作するユーザ機器（ＵＥ）であって、前記ＵＥは回路を有し、前記回路は、
    前記ＵＥのＭＢＭＳ（multimedia broadcast multicast service）クライアントにより第１のＵＳＤ（user service description）フラグメントを受信し、前記第１のＵＳＤフラグメントは、広告に対応する１又は複数のファイル又はセッションのグループ情報と、前記ファイル又はセッションに関連するＭＰＤ（media presentation description）情報と、を有し、前記グループ情報の中の各々のファイル又はセッションは、前記グループ情報に含まれるグループ識別（ＩＤ）要素と関連付けられ、
    前記ＵＥの前記ＭＢＭＳクライアントにより、ＢＭＳＣ（broadcast multicast service center）から、ストリーミングメディアコンテンツのＭＰＤ情報を含む第２のＵＳＤフラグメントを受信し、
    前記ＵＥのユーザに関連するユーザプロファイルを識別し、前記ユーザプロファイルは、前記ユーザに関連するグループＩＤ要素を有し、
    前記ユーザプロファイルに含まれるグループＩＤ要素に関連付けられるファイル又はセッションに対応する広告を選択し、
    前記ユーザプロファイルに含まれる前記グループＩＤ要素を有する前記選択された広告の目標ＭＰＤ情報を、前記ストリーミングメディアコンテンツの前記ＭＰＤ情報に挿入して、マージされたＭＰＤを生成し、
    前記ＵＥの前記ＭＢＭＳクライアントにより、前記マージされたＭＰＤに従って、前記選択された広告を受信し、
    前記ＭＢＭＳクライアントにより、前記ＢＭＳＣから、前記マージされたＭＰＤに従って、前記ストリーミングメディアコンテンツを受信し、
    前記選択された広告及び前記ストリーミングメディアコンテンツを用いて、前記ＵＥにおいて再生を実行し、前記広告は、前記ストリーミングメディアコンテンツの間に再生される、
    よう構成される、ＵＥ。
19. 前記広告に対応する前記ファイル又はセッションは、ＤＡＳＨ（dynamic adaptive streaming over hypertext transfer protocol）フォーマットファイル又はセッションを含む、請求項１８に記載の回路。
20. 前記ＵＥにあるキャッシュに、前記ＭＢＭＳクライアントにより受信された前記選択された広告を格納し、
    前記ＵＥにある前記キャッシュに格納された前記選択された広告を用いて、前記ＵＥにおいて再生を実行する、
    よう更に構成される、請求項１８に記載の回路。
21. 前記再生は、前記ＵＥのＤＡＳＨ（dynamic adaptive streaming over hypertext transfer protocol）クライアントにおいて生じる、請求項１８に記載の回路。
22. 目標メディアコンテンツを受信するよう動作するＭＢＭＳ（multimedia broadcast multicast service）クライアントを有するユーザ機器（ＵＥ）であって、前記ＵＥは回路を有し、前記回路は、
    ＭＢＭＳによりサーバから第１のメタデータを受信し、前記第１のメタデータは、目標メディアコンテンツに対応する１又は複数のファイル又はセッションのグループ情報と、前記ファイル又はセッションに関連するＭＰＤ（media presentation description）情報と、を有し、前記グループ情報の中の各々のファイル又はセッションは、前記グループ情報に含まれるグループ識別（ＩＤ）要素と関連し、
    ＭＢＭＳにより、ストリーミングメディアコンテンツのＭＰＤ情報を含むＵＳＤ（user service description）の中の第２のメタデータを受信し、
    前記ＵＥのユーザに関連するユーザプロファイルを識別し、前記ユーザプロファイルは前記ユーザに関連するグループＩＤ要素を有し、
    前記ユーザプロファイルに含まれるグループＩＤ要素に関連付けられるファイル又はセッションに対応する目標メディアコンテンツを選択し、
    前記ユーザプロファイルに含まれる前記グループＩＤ要素を有する前記選択された目標メディアコンテンツの目標ＭＰＤ情報を、前記ストリーミングメディアコンテンツのＭＰＤ情報に挿入して、マージされたＭＰＤを生成する、
    よう構成される、ＵＥ。
23. 前記ＭＢＭＳクライアントにより前記マージされたＭＰＤに従って、前記選択された目標メディアコンテンツを受信するよう更に構成される請求項２２に記載の回路。
24. 前記ＭＢＭＳクライアントにより前記マージされたＭＰＤに従って、前記ストリーミングメディアコンテンツを受信するよう更に構成される請求項２３に記載の回路。
25. 前記選択された目標メディアコンテンツ及び前記ストリーミングメディアコンテンツを用いて、前記ＵＥにおいて再生を実行するよう更に構成される請求項２４に記載の回路。
26. 請求項１７のコンピュータプログラムを記憶したコンピュータ可読記憶媒体。

Images