(57)【要約】  ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコル（ＨＴＴＰ）（ＤＡＳＨ）を実行するネットワークにおける、クライアントによるデリファレンスの方法は、更新されたメディアプレゼンテーション記述（ＭＰＤ）を取り出すようにクライアントに指示するメッセージとクライアントが更新されたＭＰＤを取り出すための場所を示す指示子とを含んだストリーミングコンテンツの第１区間を受信するステップと、更新されたＭＰＤを取り出すステップと、更新されたＭＰＤ中のリンクをデリファレンスするステップとを有し、ここで、リンクは、更新されたＭＰＤに記述されたストリーミングコンテンツの第２区間でストリーミングされるべきコンテンツの場所を示し、クライアントは、最小バッファ時間の２倍の長さである、ストリーミングコンテンツの第１区間の終了よりも前の時点で、デリファレンスを実行する。
2016522621.tif 000002
【特許請求の範囲】
【請求項１】
ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコル（ＨＴＴＰ）（ＤＡＳＨ）を実行するシステムにおけるコンテンツストリーミングの方法であって、
システム要素により、更新されたメディアプレゼンテーション記述（ＭＰＤ）の存在を通知するメッセージを含んだストリーミングコンテンツの第１区間を準備するステップと、
ストリーミングコンテンツの前記第１区間をクライアントに転送するステップと、
ストリーミングコンテンツの前記第１区間を介して前記メッセージが転送された後に、前記更新されたＭＰＤを前記クライアントに転送するステップと
を有する方法。
【請求項２】
前記第１区間が、複数のセグメントを含み、
ストリーミングコンテンツの前記第１区間で転送される最後のセグメントに前記メッセージを含ませるステップをさらに有する、請求項１に記載の方法。
【請求項３】
前記更新されたＭＰＤを入手可能な場所を示す指示子を前記メッセージに含ませるステップをさらに有する、請求項１に記載の方法。
【請求項４】
前記更新されたＭＰＤが、前記クライアントが現在利用可能なＭＰＤには記述されていないストリーミングコンテンツの第２区間中のコンテンツの記述を含む、請求項１に記載の方法。
【請求項５】
前記更新されたＭＰＤが、ストリーミングコンテンツの前記第１区間の転送の終了の実質的直後に、ストリーミングコンテンツの前記第２区間が始まることを示す、請求項４に記載の方法。
【請求項６】
前記更新されたＭＰＤが、リモートエンティティを参照するリンクを含み、
前記リモートエンティティは、前記クライアントへのコンテンツストリームに動的に挿入されるべきストリーミングコンテンツの前記第２区間の記述を含む、請求項４に記載の方法。
【請求項７】
前記リンクが、拡張可能なマークアップ言語（ＸＭＬ）リンク付け言語（ＸＬｉｎｋ）リンクである、請求項６に記載の方法。
【請求項８】
前記ＸＬｉｎｋリンクが、ストリーミングコンテンツの前記第１区間の終了よりも前の時点でデリファレンスされる、請求項７に記載の方法。
【請求項９】
ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコル（ＨＴＴＰ）（ＤＡＳＨ）を実行するシステムにおける、クライアントによるデリファレンスの方法であって、
更新されたメディアプレゼンテーション記述（ＭＰＤ）を取り出すようにクライアントに指示するメッセージと前記クライアントが前記更新されたＭＰＤを取り出すための場所を示す指示子とを含んだストリーミングコンテンツの第１区間を受信するステップと、
前記更新されたＭＰＤを取り出すステップと、
前記更新されたＭＰＤ中のリンクをデリファレンスするステップと
を有し、
前記リンクは、前記クライアントへのコンテンツストリームに動的に挿入されるべきストリーミングコンテンツの第２区間の記述を含んだリモートエンティティを参照し、
前記クライアントは、ストリーミングコンテンツの前記第１区間の終了よりも前の時点で、前記デリファレンスするステップを実行する、方法。
【請求項１０】
前記リンクが、拡張可能なマークアップ言語（ＸＭＬ）リンク付け言語（ＸＬｉｎｋ）リンクである、請求項９に記載の方法。
【請求項１１】
前記更新されたＭＰＤよりも前に、初期ＭＰＤを受信するステップをさらに有し、
前記更新されたＭＰＤに記述されたストリーミングコンテンツの前記第２区間は、前記初期ＭＰＤには記述されていない、請求項９に記載の方法。
【請求項１２】
前記更新されたＭＰＤが、ストリーミングコンテンツの前記第１区間の終了の実質的直後に、ストリーミングコンテンツの前記第２区間が始まることを示す、請求項９に記載の方法。
【請求項１３】
アダプティブストリーミングコンテンツへのリンクの動的なジャストインタイムデリファレンスを実行する方法であって、
動的なマルチ区間デリファレンス手続きと静的なジャストインタイムデリファレンス手続きとの組合せに従うステップを有し、
コンテンツを記述するメディアプレゼンテーション記述（ＭＰＤ）は、リモート区間要素を含み、
前記ＭＰＤの更新が、ＭＰＤ妥当性期限満了イベントによってトリガされ、
前記動的なジャストインタイムデリファレンスへの準拠が、@Profiles属性によって通知される、方法。
【請求項１４】
Period@xlink:actuate="onRequest"であり、かつデリファレンスがPeriodStartよりも最大で2×MPD@minBufferTime（MBT）秒前に実行される場合、第１結果区間は、妥当な区間であり、
リモート要素エンティティが２つ以上の区間要素を含む場合、前記区間要素は、リモート要素である、請求項１３に記載の方法。
【請求項１５】
前記ＭＰＤが、複数のリモート区間を含み、
前記複数のリモート区間のうちのいくつかは、デフォルトのコンテンツを有し、
前記複数のリモート区間のうちのいくつかは、複数の区間要素に分解され、
Period@xlink:actuate="onRequest"である場合、挿入されたコンテンツのダウンロードに与えられる時間が不十分なことに起因するエラーを回避するために、ＭＰＤの更新及びＸＬｉｎｋのリゾルブが、PeriodStartよりも前に完了する、請求項１３に記載の方法。
【請求項１６】
Pmが、主コンテンツを伝送する区間であり、
Piが、Pmの直後に挿入されるコンテンツを伝送するリモート区間であり、
Tが、区間Pmの有効期間 = PeriodStart(Pi) - PeriodStart(Pm)であり、
MBTが、MPD@minBufferTimeであり、
Piのデリファレンスが、時間T - 2×MBTで実行される、請求項１５に記載の方法。
【請求項１７】
時間T - 1×MBTまでに応答が無かった場合、デリファレンスが失敗に終わる、請求項１６に記載の方法。
【請求項１８】
@schemeIdUri="urn:mpeg:dash:event:2012"を有するAdaptationSet.InbandEventStream要素を使用して、インバンドＭＰＤ妥当性期限満了イベントの存在が通知される、請求項１３に記載の方法。
【請求項１９】
セグメントSR1(i)が、N個のリプレゼンテーションを含んだアダプテーションセット内のリプレゼンテーションR1のi番目のセグメントであるとき、
セグメントSR0(i)が「emsg」ボックスを含む場合、「emsg」ボックスは、セグメントSRN(i)でも伝送され、
選択されたリプレゼンテーションに関わらず、アダプテーションセットに基づくメディアが再生されるときには、すべての「emsg」ボックスが読み取られ、
１つのセグメント中には、最大でも１つの「emsg」ボックスしか存在しない
よう、「emsg」ボックスが調整される、請求項１３に記載の方法。
【請求項２０】
マルチ区間ＭＰＤ内の同一のアセットの部分を識別するために、AssetIdentifier記述子が使用され、
異なるアセットに対しては、一意に定まる識別子（ＩＤ）が使用される、請求項１３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、Alexander Giladiによって２０１３年７月１５日付けで出願された「Just-in-Time Dereferencing of Remote Elements in Dynamic Adaptive Streaming over Hypertext Transfer Protocol」と題した米国仮特許出願第６１／８４６，４１２号に対する優先権を主張するものである。引用により、上記米国出願の全内容が本明細書に組み込まれる。
【背景技術】
【０００２】
ビデオコンテンツ、オーディオコンテンツ、又はその他のコンテンツは、インターネットを介してコンテンツサーバから１つ又は複数のクライアントにストリーミングされ得る。いくつかのケースでは、ストリーミングされるコンテンツは、ストリーミングされるよりもいくらか前の時点でサーバに格納され得る。別のケース、例えば、ライブスポーツイベントのストリーミングでは、サーバは、記録デバイスからコンテンツを受信するのとほぼ同時に、当該コンテンツをストリーミングし得る。クライアントが、コンテンツをメモリロケーションに保存し、コンテンツの全体を受信し終えた後に、当該コンテンツを再生し得るといった、コンテンツを単純にダウンロードする場合とは異なり、コンテンツを受信するクライアントは、サーバからコンテンツを受信するのとほぼ同時に、当該コンテンツを再生し得る。
【発明の概要】
【課題を解決するための手段】
【０００３】
一態様において、本開示は、ダイナミックアダプティブストリーミング・オーバー・ハイパーテキストトランスファープロトコル（Hypertext Transfer Protocol，ＨＴＴＰ）（Dynamic Adaptive Streaming over Hypertext Transfer Protocol，ＤＡＳＨ）を実行するネットワークにおけるデータストリーミングの方法を含む。この方法は、ネットワーク要素により、更新されたメディアプレゼンテーション記述（Media Presentation Description，ＭＰＤ）を取り出すようにクライアントに指示するメッセージを含んだストリーミングコンテンツの第１区間を準備するステップと、ストリーミングコンテンツの第１区間をクライアントに転送するステップとを有する。
【０００４】
別の態様において、本開示は、ＤＡＳＨを実行するネットワークにおける、クライアントによるデリファレンスの方法を含む。この方法は、更新されたＭＰＤを取り出すようにクライアントに指示するメッセージとクライアントが更新されたＭＰＤを取り出すための場所を示す指示子とを含んだストリーミングコンテンツの第１区間を受信するステップと、更新されたＭＰＤを取り出すステップと、更新されたＭＰＤ中のリンクをデリファレンスするステップとを有し、ここで、リンクは、更新されたＭＰＤに記述されたストリーミングコンテンツの第２区間でストリーミングされるべきコンテンツの場所を示し、クライアントは、最小バッファ時間の２倍の長さである、ストリーミングコンテンツの第１区間の終了よりも前の時点で、デリファレンスを実行する。
【０００５】
別の態様において、本開示は、アダプティブストリーミングコンテンツへのリンクの動的なジャストインタイムデリファレンスを実行する方法を含む。この方法は、動的なマルチ区間デリファレンス手続きと静的なジャストインタイムデリファレンス手続きとの組合せに従うステップを有し、ここで、コンテンツを記述するＭＰＤは、リモート区間要素を含み、ＭＰＤの更新は、ＭＰＤ妥当性期限満了（Validity Expiration）イベントによってトリガされ、動的なジャストインタイムデリファレンスに準拠することは、値http://dashif.org/guidelines/adin/dynamic#jitを有した@profiles属性によって通知される。
【０００６】
これらの又はその他の特徴は、添付の図面及び特許請求の範囲を参照する以下の発明の詳細な説明からより明確に理解されよう。
【０００７】
この開示のより完全な理解のために、添付の図面及び発明の詳細な説明に関連して、以下の簡単な説明への参照がなされる。図中、同様の符号は、同様の要素を示す。
【図面の簡単な説明】
【０００８】
【図１】本開示の一実施形態によるアダプティブストリーミングビデオコンテンツ配信システムの概略図である。
【図２】本開示の一実施形態によるネットワーク要素の概略図である。
【図３】本開示の一実施形態によるアダプティブストリーミングビデオコンテンツ配信システムにおける更新されたマニフェスト文書の配信の概略図である。
【図４】本開示の一実施形態によるアダプティブストリーミングデリファレンスシステムの概略図である。
【図５】本開示の一実施形態によるアダプティブストリーミングシステムにおけるデータストリーミングのための方法を示すフロー図である。
【発明を実施するための形態】
【０００９】
最初に、以下では、１つ又は複数の実施形態の例示的な実装形態が提供されるが、開示されるシステム及び／又は方法は、それが既知であるか否か又は現存するか否かによらない、任意の数の技術を用いて実装されてよい、ということを理解されたい。本開示は、示された又は記載された設計例及び実装例を含む、以下に示される例示的な実装形態、図面、及び技術に限定することを意図せず、添付の特許請求の範囲内及びその均等物の全範囲内で修正がなされてよい。
【００１０】
アダプティブストリーミングは、インターネット帯域幅に対して増大する要望を満たすためのメカニズムとして提案された。アダプティブストリーミングにおいて、インターネットを介してストリーミングされるデータには、複数の異なるバージョンが存在し、これらは、リプレゼンテーションと称され得る。各バージョンは、異なるサイズに圧縮されて、異なるレートで転送され得る。所与の時間に所与のクライアントにストリーミングされるバージョンは、その時間のネットワークコンディション、クライアントの能力、及び／又はその他の要素に基づいて、クライアントによって適応的に選択され得る。ビデオコンテンツは、複数の時間区間でストリーミングされ得、このとき、例えば、第１区間は、主コンテンツの第１部分を含み、第２区間は、広告を含み、かつ第３区間は、主コンテンツの第２部分を含む。クライアントがビデオコンテンツのストリーミングを要求するとき、コンテンツサーバは、クライアントに、クライアントが区間の各々に対するコンテンツを取り出し得る場所を示す複数のＵＲＬ（Uniform Resource Locator）を含んだマニフェスト文書を送信し得る。
【００１１】
開示されるものは、クライアントが現在利用可能なマニフェストには記述されていない新たな区間の記述を含んだ更新されたマニフェストを取り出すようにクライアントに指示するメッセージを、ビデオコンテンツサーバが、ストリーミングされるビデオコンテンツのセグメントに挿入し得るメカニズムである。更新されたマニフェストは、新たな区間がメッセージの転送の後に始まることを示してよい。また、更新されたマニフェストは、新たな区間で再生される、広告などのコンテンツの場所への参照を含んでもよい。いくつかのケースでは、新たな区間は、動的な区間であってよい。換言すれば、新たな区間の開始時間は、クライアントが現在利用可能なマニフェストが準備された時点では不明であってよい。新たな区間の開始時間が分かったとき、そのような時間は、更新されたマニフェストに含められてよい。また、開示される実施形態は、新たな区間中のコンテンツへのリンクがデリファレンスされるべき時間を指定してもよい。
【００１２】
図１は、アダプティブストリーミングビデオコンテンツ配信システム１００の一実施形態の概略図である。複数の異なる技術及びプロトコルがビデオストリーミングのために使用可能であり、複数のタイプのアダプティブビデオフォーマットが存在し得る。以下の説明では、ＤＡＳＨ（Dynamic Adaptive Streaming over Hypertext Transfer Protocol（ＨＴＴＰ））として知られるコンテンツ配信プラットホームに焦点を合わせるが、同様の考察が他のビデオコンテンツ配信プラットホームになされ得ることを理解されたい。システム１００は、１つ又は複数のＤＡＳＨメディアプレゼンテーションを保持し得るサーバ１１０又は同様の構成要素を含み得る。メディアプレゼンテーションは、映画、テレビ番組、又は録画されたスポーツイベントなどの１つのビデオコンテンツの複数のバージョンを含み得る。クライアント１２０は、サーバ１１０から転送されるビデオコンテンツを受信し得る。
【００１３】
サーバ１１０上の異なるバージョンのビデオコンテンツは、各バージョンのコンテンツが異なる転送レートでクライアント１２０に転送され得るように構成されてよい複数のデータセグメント１４０を含み得る。ＤＡＳＨを用いるビデオストリームは、サーバ１１０からクライアント１２０への、メディアプレゼンテーション記述（Media Presentation Description，ＭＰＤ）１３０と称されるマニフェストの転送から開始されてよい。ＭＰＤ１３０は、ＵＲＬのリストと、セグメント１４０へのビデオストリームの分解についての記述とを含んでよく、各セグメントは、ビデオストリーム中の特定の時間フレーム及び特定の符号化に対応する。したがって、ビデオは、時間の側面と、レートの側面とで表現され得る。クライアント１２０は、時間ウィンドウに対応するセグメント１４０をダウンロードする際に達するスループットを測定し得、次いで、次の時間ウィンドウに対して、適切な転送レート及び関連する符号化を選択し得る。したがって、クライアント１２０は、クライアント１２０とサーバ１１０との間の経路上のチャネル品質の変化に対応し得る。
【００１４】
ＭＰＤ１３０は、１つ又は複数の区間についての情報を含み得る。各区間は、１つ又は複数のアダプテーションセット１５０を含み得る。各アダプテーションセット１５０は、１つ又は複数のリプレゼンテーション１６０を含み得る。各リプレゼンテーション１６０は、１つ又は複数のセグメント１４０を含み得る。区間は、タイミングデータを含んでよく、メディアコンテンツの符号化バージョンの一貫したセット（例えば、変更できない利用可能なビットレート、言語、字幕、サブタイトル等のセット）が利用可能であるコンテンツ区間を表し得る。アダプテーションセット１５０は、１つ又は複数のメディアコンテンツコンポーネントの相互交換可能な符号化バージョンのセットを表し得る。例えば、第１アダプテーションセット１５０が、主ビデオコンポーネントを含んでよく、第２アダプテーションセット１５１が、主オーディオコンポーネントを含んでよく、かつ（図示されていない）第３アダプテーションセットが、字幕を含んでよい。また、アダプテーションセット１５０は、組み合わされたビデオ及びオーディオなど、複合化コンテンツを含んでもよい。リプレゼンテーション１６０は、ＩＳＯ−ＢＭＦＦ（International Organization for Standardization（ＩＳＯ）Based Media File Format）バージョン又はＭＰＥＧ−２ ＴＳ（Moving Picture Experts Group（ＭＰＥＧ）Version Two Transport System）バージョンなど、１つ又は複数のメディアコンテンツコンポーネントの配信可能な符号化バージョンを記述してよい。リプレゼンテーション１６０は、例えば、任意のコーデック、暗号、及び／又はメディアコンテンツを表現するためのその他のデータを記述してよい。
【００１５】
クライアント１２０は、ネットワークコンディション、デバイス能力、ユーザ選択、及び／又はその他の要素に基づいて、リプレゼンテーション１６０とリプレゼンテーション１６１とを動的に切り替えてよい。そのような動的な切替えは、アダプティブストリーミングと称され得る。各セグメント１４０は、メディアコンテンツデータを含んでよく、ＵＲＬに関連付けられてよく、かつ、例えば、ＨＴＴＰ ＧＥＴリクエストにより、クライアント１２０によって取り出されてよい。各セグメント１４０は、予め定められたバイトサイズ（例えば、１０００バイト）及び／又はメディアコンテンツの再生時間の間隔（例えば、２又は５秒）を含んでよい。セグメント１４０は、ＭＰＤ１３０を介して知らされるＵＲＬを使用してダウンロード可能なデータの個々の最小のアドレス可能ユニットを含んでよい。区間、アダプテーションセット１５０、リプレゼンテーション１６０、及び／又はセグメント１４０は、属性及び要素の観点から記述されてよく、クライアント１２０によるメディアコンテンツのプレゼンテーションの修正のために、修正が加えられてもよい。
【００１６】
図２は、開示されるシステム、方法、及びスキームの１つ又は複数の実施形態を実装するために適し得るネットワーク要素（Network Element，ＮＥ）２００の一実施形態の概略図である。例えば、ＮＥ２００は、図１のサーバ１１０又はクライアント１２０として動作してよい。ＮＥ２００は、１つのノードに実装されてよく、又はＮＥ２００の機能が複数のノードに実装されてもよい。用語「ＮＥ」は、ＮＥ２００が一例に過ぎない広い範囲のデバイスを包含し得る、ということが当業者には認識されよう。ＮＥ２００は、説明を明確にすることを目的として、かつ本開示の用途に限定することを意図せずに、特定のＮＥ実施形態又はＮＥ実施形態のクラスに含められる。本開示に記載された少なくともいくつかの特徴及び方法は、ＮＥ２００などのネットワーク装置又は構成要素として実装されてよい。例えば、本開示の特徴／方法は、ハードウェア、ファームウェア、及び／又はハードウェア上で実行されるように導入されたソフトウェアを用いて実装されてよい。
【００１７】
図２に示されるように、ＮＥ２００は、送信器、受信器、又はそれらの組合せであり得るトランシーバ（Ｔｘ／Ｒｘ）２１０を含んでよい。Ｔｘ／Ｒｘ２１０は、ダウンストリームエンティティにデータを送信するために、及び／又はダウンストリームエンティティからデータを受信するために、複数のダウンストリームポート２２０に接続されてよい。また、Ｔｘ／Ｒｘ２１０は、アップストリームエンティティにデータを送信するため、及び／又はアップストリームエンティティからデータを受信するための複数のアップストリームポート２５０に接続されてもよい。プロセッサ２３０は、データを処理するため、及び／又はどのノードにデータを送信するかを決定するために、Ｔｘ／Ｒｘ２１０に接続されてよい。プロセッサ２３０は、ＭＰＤに関して本開示に記載された機能を実行するためのＭＰＤモジュール２３４を含んでよい。プロセッサ２３０は、１つ又は複数のマルチコアプロセッサ及び／又はメモリデバイス２３２を含んでよい。メモリデバイス２３２は、データストア、バッファ等として機能し得る。プロセッサ２３０は、汎用プロセッサとして実装されてよく、又は、１つ又は複数のＡＳＩＣ（Application Specific Integrated Circuit）及び／又はＤＳＰ（Digital Signal Processor）の一部分であってもよい。ダウンストリームポート２２０及び／又はアップストリームポート２５０は、電気的な及び／又は光学的な送信及び／又は受信コンポーネントを含んでよい。
【００１８】
ＮＥ２００に実行可能な命令をプログラム及び／又はロードすることにより、プロセッサ２３０、ＭＰＤモジュール２３４、Ｔｘ／Ｒｘ２１０、メモリ２３２、ダウンストリームポート２２０、及び／又はアップストリームポート２５０のうちの少なくとも１つが変更され、ＮＥ２００は、本開示によって教示される新規な機能性を有する特定の機械又は装置へと部分的に変わる、ということが理解されよう。コンピュータに実行可能なソフトウェアをロードすることによって実装可能な機能性が、既知の設計規則によってハードウェア実装と可換であることは、電気技術及びソフトウェア技術の分野の基本である。典型的に、ソフトウェアとして実装するかハードウェアとして実装するかの判断は、ソフトウェア領域からハードウェア領域に変換する際に生じる何らかの問題点ではなく、設計の安定性及び生み出されるユニットの数を考慮して決まる。一般に、ハードウェア実装の再設計（リスピン）は、ソフトウェア設計の再設計よりも高価であるので、頻繁な変更の原因となる設計は、ソフトウェアとして実装されることが望ましいと言えよう。一般に、ハードウェア実装で動作する大部分の製品は、ソフトウェア実装よりも安価となり得るので、大量に製造されることが分かっている設計は、ハードウェア、例えば、ＡＳＩＣなどで実行されることが望ましいと言えよう。多くの場合、設計は、ソフトウェア形態で開発され、テストされ、その後、既知の設計規則によって、ソフトウェア命令を有線接続化した特定用途向け集積回路中の均等なハードウェア実装へと変換される。新たなＡＳＩＣによってコントロールされる機械が特定の機械又は装置であるのと同じく、実行可能な命令がプログラム及び／又はロードされた同様のコンピュータは、特定の機械又は装置と見なされてよい。
【００１９】
本開示の任意の処理は、コンピュータシステム中のプロセッサ（例えば、コンピュータシステム内部の汎用中央処理ユニット（Central Processing Unit，ＣＰＵ））にコンピュータプログラムを実行させることによって実施されてよい、ということを理解されたい。この場合、コンピュータプログラム製品は、任意のタイプの非一時的なコンピュータ読み取り可能な媒体を用いて、コンピュータ又はモバイルデバイスに提供できる。コンピュータプログラム製品は、コンピュータ又はネットワークデバイス中の非一時的なコンピュータ読み取り可能な媒体に格納されてよい。非一時的なコンピュータ読み取り可能な媒体は、任意のタイプの有形記憶媒体を含み得る。非一時的なコンピュータ読み取り可能な媒体の例としては、（フロッピー（登録商標）ディスク、磁気テープ、ハードディスクドライブなどの）磁気記憶媒体、（磁気光学ディスクなどの）光磁気記憶媒体、ＣＤ−ＲＯＭ（Compact Disc Read-Only Memory）、ＣＤ−Ｒ（Compact Disc Recordable）、ＣＤ−Ｒ／Ｗ（Compact Disc Rewritable）、ＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu−ray（登録商標）Disc）、及び（マスクＲＯＭ、プログラマブルＲＯＭ（ＰＲＯＭ）、イレーサブルＰＲＯＭ、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory）などの）半導体メモリがある。また、コンピュータプログラム製品は、任意のタイプの一時的なコンピュータ読み取り可能な媒体を用いて、コンピュータ又はネットワークデバイスに提供されてもよい。一時的なコンピュータ読み取り可能な媒体の例としては、電気信号、光信号、及び電磁波がある。一時的なコンピュータ読み取り可能な媒体は、有線通信回線（例えば、電線又は光ファイバ）又は無線通信回線を介してコンピュータにプログラムを提供できる。
【００２０】
先に記載の通り、ビデオコンテンツは、後のストリーミングのために、サーバに格納されてよい。主コンテンツ中に広告が挿入される場合、広告が再生されるべき時間は、コンテンツに対するＭＰＤが準備される時点で知られていてよい。そのような場合、ＭＰＤは、主コンテンツの各部分及び各広告の開始時間又は長さを含み得る。例えば、ＭＰＤは、既知の開始時間又は既知の長さを有した第１主コンテンツ区間、それに続く、既知の開始時間又は既知の長さを有した区間、それに続く、既知の開始時間又は既知の長さを有した第２主コンテンツ区間を記述してよい。ＭＰＤは、各区間で再生されるべきコンテンツの場所を指定するＵＲＬ、又はそのようなＵＲＬを発見し得る場所へのリンクを含んでよい。
【００２１】
別のケースでは、コンテンツは、ストリーミングに先立ってサーバに格納されず、その代わりに、コンテンツが記録されるのとほぼ同時にストリーミングされる。そのようなライブストリーミングは、例えば、ライブスポーツイベントのストリーミングに利用され得る。そのような場合、広告が再生される時間は、イベントの開始よりも前には分からず、その代わりに、審判がタイム（time-out）を宣言したときなど、イベントの状況に応じて生じ得る。そのようなイベントよりも前に、広告が現れる区間の開始時間を記述するためにＭＰＤを生成することは不可能であろう。
【００２２】
本開示の実施形態は、ストリーミングの開始よりも前には区間の開始時間が分からない場合の、ストリーミングコンテンツへの区間挿入のためのメカニズムを提供する。図３は、広告又はその他の二次コンテンツが、ストリーミングが開始されたときには不明な時間で、コンテンツの主ストリームに挿入され得るシステム３００を示す。第１主コンテンツ区間３１０は、図１のサーバ１１０などのサーバによって、準備され、転送されてよい。一実施形態において、第１区間３１０は、複数のセグメント３１２を含んでよいが、複数のセグメント３１２は、そのうちの１つを除いて、ビデオ及び／又はオーディオコンテンツなどのストリーミングコンテンツを含んでよい。区間３１０で転送される最後のセグメント３１２ｆは、ビデオ又はオーディオコンテンツでなはく、サーバによって挿入されるメッセージを含んでよい。最後のセグメント３１２ｆ中のメッセージは、図１のクライアント１２０と実質的に同一であってよいクライアント３２０に、更新されたＭＰＤ３３０を取り出すように指示する。メッセージは、更新されたＭＰＤ３３０をどこで発見し得るかをクライアント３２０に通知するＵＲＬ又はその他の指示子を含んでよい。
【００２３】
更新されたＭＰＤ３３０は、クライアント３２０が現在利用可能なＭＰＤには記述されていない、新たに挿入された区間３４０中のコンテンツの記述３３２を含んでよい。記述３３２は、主コンテンツの第１区間３４０の転送の終了のほぼ直後に、挿入された区間３４０が始まることを示してよい。また、更新されたＭＰＤ３３０は、挿入された区間３４０で再生されるコンテンツを発見し得る場所を指定するリンク３３４を含んでもよい。いくつかのケースでは、挿入された区間３４０で再生されるコンテンツは、広告であり得る。
【００２４】
第１主コンテンツ区間３１０の最後のセグメント３１２ｆ中のメッセージは、挿入された区間３４０が終了したときに第２主コンテンツ区間３５０が始まることを、クライアント３２０に通知してよい。第１主コンテンツ区間３１０中の最後のセグメント３１２ｆと同様の、第２主コンテンツ区間３５０中の最後のセグメント３５２ｆは、第２主コンテンツ区間３５０の終了の後に挿入される別の区間に対する別の更新されたＭＰＤを取り出すように、クライアント３２０に指示するメッセージを含んでよい。このようにして、広告又はその他の二次コンテンツは、ストリーミングの開始前にはそれらが生じる時間が分からない場合でも、ストリーム中の適切な時間で、コンテンツストリームに挿入され得る。
【００２５】
いくつかのケースでは、異なる広告が、異なるクライアントをターゲットとし得る。そのような場合、ＭＰＤは、所与の時間で再生される１つの広告の対する固定されたＵＲＬを含まなくてよい。一実施形態において、挿入された区間３４０中のコンテンツへの、更新されたＭＰＤ３３０中のリンク３３４は、異なるクライアントに対し、異なる時間で、異なるＵＲＬにデリファレンスされてよい。ＵＲＬは、異なるクライアントに対する異なる広告／コンテンツを含んだリモートエンティティを指し示してよい。いくつかの実施形態では、更新されたＭＰＤ３３０中のリンク３３４は、ストリーム可能なコンテンツの記述を含んだリモートエンティティを指し示してよい。例えば、そのようなリンクは、本開示中では、ＸＬｉｎｋと称され得る、拡張可能なマークアップ言語（Extensible Markup Language，ＸＭＬ）リンク付け言語リンクであってよい。例えば、クライアント３２０は、コンテンツストリームに挿入されるべきコンテンツの記述を指し示し得る、更新されたＭＰＤ３３０を受信してよい。クライアント３２０は、リンクをデリファレンス（間接参照）及び／又はリゾルブ（解決）して、挿入されるコンテンツの記述を取得し、更新されたＭＰＤ３３０に記述を含めてよい。次いで、クライアント３２０は、解決された記述を利用して、必要に応じて、挿入されたコンテンツを取得する。
【００２６】
ＸＬｉｎｋは、OnLoadパラメータ又はOnRequestパラメータのいずれかに従って、デリファレンス又はリゾルブされてよい。OnLoadデリファレンスでは、クライアントは、ＸＬｉｎｋを含んだＭＰＤがロードされた時点で、ＸＬｉｎｋをリゾルブする。動的デリファレンスとしても知られる、OnRequestデリファレンスでは、クライアントは、該クライアントがＸＬｉｎｋを含んだＭＰＤの該当部分を読み取った時点で、ＸＬｉｎｋをリゾルブする。図３では、OnRequestデリファレンスが使用されてよい。クライアント３２０が更新されたＭＰＤ３３０を取り出すとき、ＸＬｉｎｋ３３４のOnRequestデリファレンスがいつ発生するかは不明であってよい。ＸＬｉｎｋのデリファレンスが早すぎる場合、挿入される区間３４０で再生されるべきコンテンツは、まだダウンロード不可能であり得る。ＸＬｉｎｋのデリファレンスが遅すぎる場合、挿入される区間３４０で再生されるべきコンテンツは、適時に取り出され得ない。
【００２７】
一実施形態において、タイミングは、主コンテンツの区間に動的に挿入される区間中のコンテンツを参照するＸＬｉｎｋのOnRequestデリファレンスのために指定される。より具体的には、主コンテンツを伝送する区間として、Pmが定義され得る、Pmの直後に挿入されるコンテンツが伝送される区間として、Piが定義され得る。区間Pmの有効期間（例えば、PeriodStart(Pi) - PeriodStart(Pm)）として、Tが定義され得る。ストリーミングシステム３００に対する最小バッファ時間として、MBTが定義され得る。一実施形態において、更新されたＭＰＤ３３０を取り出すようにクライアント３２０に指示するメッセージを含んだセグメント３１２ｆは、時間T - 2×MBTで転送される。換言すれば、ＸＬｉｎｋ３３４は、第１主コンテンツ３１０の終了よりも前の、最小バッファ時間の２倍の長さの時間で、デリファレンスされ得る。
【００２８】
ＸＬｉｎｋを有したリモート要素のオンデマンドデリファレンスは、対象とする広告の挿入のために使用されてよく、ユーザに提示すべき広告コンテンツへのリアルタイムでの決定が要求され得る。ＤＡＳＨ及びリモート区間要素を使用する広告挿入の実施形態において、デリファレンスシステムは、図４に示されるように機能し得る。図４において、ＤＡＳＨアクセスクライアント４１０は、対応するＤＡＳＨ ＭＰＤ中でクライアント４１０に提供されるＨＴＴＰ ＵＲＬを使用して、リモート要素をデリファレンスし得る。このコンテキストにおいて、要素は、区間要素と見なされ得るが、属性@xlink:href及び@xlink:actuateを有した任意のＭＰＤ要素は、開示される技術に従ってデリファレンスされ得る。
【００２９】
図４に示されるように、区間リゾルバ４２０、例えば、ＨＴＴＰサーバは、ＤＡＳＨクライアント４１０からＨＴＴＰ ＧＥＴリクエスト４３０を受信したとき、広告決定サーバ４４０にコンタクトしてよい。区間リゾルバ４２０は、当分野で広く知られた１つ又は複数の適切な通信プロトコル、例えば、ＶＡＳＴ（Video Ad Serving Template）及び／又はＳＣＴＥ（Society of Cable Telecommunications Engineers）規格１３０を使用して、広告決定サーバ４４０に広告決定のためのリクエスト４５０を送信してよい。広告決定サーバ４４０は、広告決定結果４６０を区間リゾルバ４２０に返してよい。広告決定サーバ４４０は、当分野で広く知られた１つ又は複数の適切な通信プロトコル、例えば、ＶＡＳＴ、ＳＣＴＥ１３０、及び／又はＶＭＡＰ（Video Multiple Ad Playlist）を使用して、広告決定結果４６０を区間リゾルバ４２０に返してよい。区間リゾルバ４２０は、広告決定結果４６０を１つ又は複数の区間要素４７０へと変換してよい。次いで、区間リゾルバ４２０は、ＤＡＳＨクライアント４１０からの元のＨＴＴＰ ＧＥＴリクエスト４３０に応答して、区間要素４７０をＤＡＳＨクライアント４１０に送信し得る。
【００３０】
ＤＡＳＨ規格は、デリファレンスの発生時には指定され得ない。ある値、例えば、@xlink:actuateの値OnLoadは、即時のデリファレンスを要求し得、一方、値OnRequestは、デリファレンスの一定期間の保留を許可し得る。この開示においてデリファレンスを説明するときには、OnRequest値が想定される。
【００３１】
ＸＬｉｎｋに対する指定は、アプリケーションが、トラバーサルを目的としてトリガされたロード後イベントにおいて、開始リソースから終了リソースにトラバーサルすることを示す。そのようなイベントの例としては、ユーザが、開始リソースの表示物をクリックするとき、又はソフトウェアモジュールが、リダイレクトに先立つカウントダウンを完了させたときであり得る。指定は、ガイダンス又はコンプライアンス規則を提供せずともよく、したがって、早ければＭＰＤがパース（解釈）されるときに、要素をデリファレンスすることを許容し得る。この問題点は、動的なＭＰＤ及び／又はジャストインタイムなＭＰＤ更新の使用を介して克服され得る。新たなＭＰＤをダウンロードし、ＭＰＤをパースし、ＭＰＤに含まれたリモート要素をデリファレンスするために十分な時間をＤＡＳＨクライアントが有し得るので、ＭＰＤは、早期にトリガされてよい。
【００３２】
動的なＭＰＤ及び／又はジャストインタイムなＭＰＤ更新の使用は、上手く定義されたタイミングモデルを提供し得る。しかしながら、そのような技術は、トラフィックのオーバヘッドを増大させ得る頻繁なＭＰＤ更新を、エンティティに要求し得る。さらに、ＤＡＳＨイベントが使用される場合、広告挿入の機能性を考慮して、メディアのセグメンテーションを実行する必要が生じ得る。ＭＰＤパッチイベントが使用されない場合、ＭＰＤのフェッチに起因する追加的な遅延を招き得る。ＭＰＤパッチイベントが使用される場合、ＭＰＤのフェッチに関連する遅延は発生し得ないが、ＭＰＤを生成するエンティティとメディアをセグメント化するエンティティとの間の厳格な同期が生じ得る。
【００３３】
ＤＡＳＨに対するＸＬｉｎｋタイミングモデルを定義することは、上記の問題点に対処し得る。そのような定義は、元のＤＡＳＨ指定を実施する任意のＤＡＳＨクライアントが、タイミングモデルを意識せずとも正しく動作できることを必要とし得る。また、そのような解決策は、ＸＬｉｎｋとの互換性が保たれていることを必要とし得る。
【００３４】
要素がデリファレンスされ得る最も早い時間として、要素可用性開始時間（Element Availability Start Time，ＥＡＳＴ）が定義され得、かつＭＰＤがパースされる時間として、ＭＰＤパース時間（ＭＰＤ Parse Time，ＭＰＴ）が定義され得る。一実施形態において、一般的なＤＡＳＨクライアントは、ＥＡＳＴよりも前に要求がなされた任意の時間にリモート要素を返すことによって、ＥＡＳＴ後の要素をデリファレンスし得る。しかしながら、この手順は、無自覚なクライアントからのリクエストの無限ループを引き起こし得る。代替的な実施形態において、ＨＴＴＰステータスコード、例えば、３ｘｘ、４ｘｘ、及び／又は５ｘｘ、が、ＥＡＳＴよりも前になされたリクエストの任意のデリファレンスへの応答として返されてよい。無自覚なクライアントは、エラー時にＭＰＤをリロードし得、一例として、５ｘｘエラーコード、例えば、ゲートウェイタイムアウト発生時、無自覚なクライアントは、一旦諦めて、後にリトライし得る。そのような例において、無自覚なクライアントは、エラーを、ＭＰＤを無効にするエラーと解釈し得、したがって、新たなＭＰＤのフェッチ及び再パースが要求され得る。一実施形態において、ＥＡＳＴよりも前のデリファレンスに対する繰返しのエラーに起因したＭＰＤをリロードする試みの頻繁な発生による無限ループを回避するために、ＨＴＴＰサーバは、応答を遅延させてよい。
【００３５】
ＥＡＳＴを明示的に通知することも可能である。ＥＡＳＴの明示的な通知は、追加的なオプション属性、例えば、@xlink:availabilityTime、を必要とし得、これは、属性@xlink:hrefを有したすべてのＤＡＳＨ ＭＰＤ要素に追加され得る。@xlink:availabilityTimeの意味は、@xlink:hrefで指定されたＵＲＬが@xlink:availabilityTimeで指定される時間よりも前にリゾルブされ得ないことを示す。@xlink:availabilityTimeは、PeriodStart時間に関連してよい。無自覚なクライアントは、早期のデリファレンスを試み得、そのとき、早期のデリファレンスを回避するために、サーバ側のメソッドが使用されてよい。
【００３６】
ＸＬｉｎｋ １．１は、otherとして知られる、@xlink:actuateのための別の値を許容する。other値は、末尾リソースにトラバースするアプリケーションの挙動がＸＬｉｎｋ仕様によって拘束されないことを示し得る。そのような場合、アプリケーションは、リンク中の１つ又は複数の別のマークアップ表示を見つけ出して、適切な挙動を決定し得る。無自覚なクライアントは、値otherを無視し得、一方、それに気付くクライアントは、ＤＡＳＨ仕様で指定された規則に従い得る。ＤＡＳＨ規格は、otherの使用を許容せず、より古いＭＰＤバリデータは、other値を使用する場合に、ＭＰＤが妥当でないことを発見する結果となり得る。一実施形態において、otherの使用を許容するために、ＸＬｉｎｋのＤＡＳＨプロファイルが修正されてよい。otherの@xlink:actuate値が@xlink: availabilityTimeと共に使用されるシステムでは、それに気付くクライアントは、ＥＡＳＴ後に要素をデリファレンスし得、一方、無自覚なクライアントは、要求された挙動を認識し得ないので、要素を無視し得る。
【００３７】
別の実施形態において、ＤＡＳＨクライアント認識のための要件は、プロファイル、例えば、プロファイルＵＲＩ（Uniform Resource Identifier）、としてＭＰＤで表現されてよい。クライアント認識要件が表現されたプロファイルに準拠するＤＡＳＨクライアントは、開示されたタイミングモデルに従い得る。
【００３８】
図５は、アダプティブストリーミングシステムにおけるデータストリーミングの方法５００の一実施形態を示すフロー図である。ブロック５１０において、ネットワーク要素は、更新されたＭＰＤを取り出すようにクライアントに指示するメッセージを含んだストリーミングコンテンツの第１区間を準備する。ブロック５２０において、ネットワーク要素は、ストリーミングコンテンツの第１区間をクライアントに転送する。ブロック５３０において、ネットワーク要素又はネットワーク要素に関連した構成要素は、更新されたＭＰＤを要求するＨＴＴＰ ＧＥＴメッセージ又は同様のメッセージをクライアントから受信する。ブロック５４０において、ネットワーク要素又はネットワーク要素に関連した構成要素は、更新されたＭＰＤをクライアントに転送する。ブロック５５０において、ネットワーク要素は、ストリーミングコンテンツの第２区間で再生すべき（例えば、コンテンツストリームに挿入された）広告などのコンテンツを含むリモートエンティティを指定するＸＬｉｎｋを含んだＨＴＴＰ ＧＥＴメッセージ又は同様のメッセージをクライアントから受信する。ブロック５６０において、第２区間で再生すべきコンテンツが広告である場合、ネットワーク要素は、広告サーバから広告決定結果を取得する。ブロック５７０において、ネットワーク要素は、第２区間のコンテンツをクライアントに転送する。
【００３９】
以下の参照文献は、引用によって、それらの全内容が本開示に組み込まれる。ISO/IEC 23009-1:2012 Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats、ISO/IEC 23009-1:2012/Cor 1:2013、XML Linking Language (XLink) Version 1.1、W3C Recommendation 06 May 2010、Alex Giladi (ed.), Ad Insertion in DASH: Architectures and Guidelines, July 10, 2013、Giles Godart-Brown, Jeff Goldberg, Rolando Medina, Keith Millar, Advert Insertion using MPEG DASH, v1.0, May 15, 2013、及びAd Insertion in DASH, Architectures and Guidelines, May 9, 2014。
【００４０】
説明したように、静的なジャストインタイムデリファレンスに対する相互運用性ポイントは、マルチ区間ＤＡＳＨコンテンツと、Period@xlink:href及びPeriod@xlink:actuateを含んだＭＰＤとを前提とする。ＸＬｉｎｋの追加を伴う、スタティックマルチ区間インターオペラビリティポイント（Interoperability Point，ＩＯＰ）の拡張セットであってもよい。スタティックジャストインタイムＩＯＰへの準拠は、値http://dashif.org/guidelines/adin/static#jitを有した@profiles属性によって通知され得る。
【００４１】
コンテンツ作成に関して、マルチ区間ＭＰＤ内の同一のアセットの部分を識別するために、AssetIdentifier記述子が使用されてよく、よって、記述子は、主コンテンツに対して使用され得る。より良好な追跡及び通知を可能にするために、一意に定まる識別子（ＩＤ）が異なるアセットに対して使用されてもよい。故に、挿入されたコンテンツ中のAssetIdentifier記述子を同様に使用することが推奨される。@schemeIdUriの値は、"urn:org:dashif:asset-id:2014"であってよい。@value属性記述子の値は、コンテンツに対するMovieLabs ContentID URNであってよい。アセットのすべての部分に対して同一であってもよい。好適なスキームは、ＥＩＤＲ（Entertainment Identifier Registry）であってよい。区間がマルチ区間アセットの最後の区間である場合、発行者は、いわゆる、一回限り自己完結（one-off self-contained）区間（例えば、広告）を追加してよく、かつAssetIdentifier@id属性の値は、ＵＵＩＤ（Universally Unique Identifier）であってよい。後者の処置がなされない場合、繰り返される広告に対するランダムアクセスロジックは、広告のすべての繰り返しの出現を、以前の（複数の）出現の続きと見なし得る。このようにして、広告の第２の出現は、５０パーセントから始まるプレイアウトバーを有し得る。AssetIdentifier記述子は、すべてのマルチ区間アセットに対して使用され得る。区間がシングル区間の意味を有する（すなわち、アセットが１つの区間に完全に含まれ、かつその連続性が今後予期されない）場合、発行者は、これらのアセットにアセット識別子を使用しなくてよい。非リモートなAdaptationSet要素を含まない区間、及びゼロ長の区間は、AssetIdentifier記述子を含まずともよい。
【００４２】
連続する区間に関して、広告コンテンツは、ＤＡＳＨ−ＡＶＣ（Advanced Video Coding）／２６４準拠コンテンツであってよい。同一のAssetIdentifierを有する異なるアセット中のコンテンツは、コンテンツ特性（例えば、コーデック、解像度、フレームレート、ビットレート）を保存するように調整されてよい。同一の初期化セグメントを有し、かつＤＲＭ（Digital Rights Management）情報の最大共有性を有することが望まれ得る。挿入されたコンテンツは、シームレスな区間遷移を許容するように調整されてよく、例えば、コーデック、解像度、フレームレート等の変更が阻止される。さらに、挿入されたコンテンツの最低ビットレートが主コンテンツの最低ビットレートよりも高くなることはなくてよい。
【００４３】
要求されるコンテンツに関して、主コンテンツがＩＳＯ−ＢＭＦＦ OnDemandプロファイルに準拠する場合、コンテンツは１つのファイルとして格納されると見なされ得る。このコンテンツがマルチ区間として与えられている場合、区間毎のファイルを作成せずともよい。このアセットに対するすべての区間は、同一のBaseURL値と、PeriodStartに等しいメディア時間にそれぞれ対応する、異なるSegmentBase@presentationTimeOffset値とを有し得る。ファイルは、（複数の）「sidx」ボックスを含み得、かつクライアントは、インデックス情報を読み取って、SegmentBase@presentationTimeOffsetの値を考慮したセグメントオフセットを計算し得る。
【００４４】
ＭＰＤは、複数のリモート区間を含んでよく、そのうちのいくつかは、デフォルトのコンテンツを有してよく、かつそのうちのいくつかは、複数の区間要素に分解されてよい。デリファレンスの後、ＭＰＤは、ゼロ長の区間及び／又はリモート区間を含み得る。Period@xlink:actuate="onRequest"である場合、挿入されたコンテンツのダウンロードに与えられる時間が不十分なことに起因する副作用が生じることがないよう、ＭＰＤの更新及びＸＬｉｎｋのリゾルブは、十分に早く行われ得る。主コンテンツを伝送する区間を、Pmとし、かつPmの直後に挿入されるコンテンツを伝送するリモート区間を、Piとする。区間Pmの有効期間（すなわち、PeriodStart(Pi) - PeriodStart(Pm)）を、Tとする。また、MPD@minBufferTimeを、MBTとする。Piのデリファレンスは、時間T - 2×MBTで実行されなければならない。T - 1×MBTまでに応答が無い場合、クライアントは、デリファレンスの失敗と見なしてよい。
【００４５】
動的なマルチ区間デリファレンスに対する相互運用性ポイントは、先に説明した静的なマルチ区間の拡張であり、コンテンツは、ＤＡＳＨ ＭＰＤ妥当性期限満了イベントに依存し、アップストリーム機器（例えば、パッケージャ）が入来キューを検出すると、ＭＰＤ更新をトリガするという差異を伴う。スタティックジャストインタイムＩＰＯへの準拠は、値http://dashif.org/guidelines/adin/dynamic#multiperiodを有した@profiles属性によって通知され得る。
【００４６】
静的なデリファレンスの場合のコンテンツ作成について先に説明したガイドラインは、動的なマルチ区間デリファレンスにも適用されてよい。ＤＡＳＨ ＭＰＤ妥当性期限満了は、メディアセグメントのうちのいくつかで発生することが予期され得る。
【００４７】
インバンドＭＰＤ妥当性期限満了イベントの存在は、値@schemeIdUri=" urn:mpeg:dash:event:2012"を有したAdaptationSet.InbandEventStream要素を用いて通知され得る。インバンドＭＰＤ妥当性期限満了イベントは、ビデオ中に存在し得る。これらのイベントが使用される場合、ビデオアダプテーションセットがそれらを伝送し得る。
【００４８】
「emsg」ボックスは、セグメントSR1(i)が、N個のリプレゼンテーションを含んだアダプテーションセット内のリプレゼンテーションRのi番目のセグメントであるとすると、SR0(i)が「emsg」ボックスを含む場合、同一の「emsg」ボックスがセグメントSR2(i)…SRN(i)で伝送されるよう、調整され得る。これは、選択されたリプレゼンテーションに関わらず、アダプテーションセットに基づくメディアが再生される場合に、すべての「emsg」ボックスが読み取られ得ることを意味する。最大で１つの「emsg」ボックスがセグメントに提示され得る。いくつかの「emsg」ボックスがセグメントに提示され得る場合、「emsg」は、最初に現れ得る。
【００４９】
タイミングの挙動に関して、主コンテンツを伝送する区間を、Pmとし、かつその直後に挿入されたコンテンツを伝送する区間を、Piとする。区間Pmの有効期間（すなわち、PeriodStart(Pi) - PeriodStart(Pm)）を、Tとする。また、MPD@minBufferTimeを、MBTとする。区間Piに追加される、ＭＰＤ更新をトリガするＭＰＤ妥当性期限満了イベントを伝送する「emsg」は、イベント区間時間（Event Period Time，ＥＰＴ）≦T - 2×MBTのセグメントで伝送されなければならない。
【００５０】
動的なジャストインタイムデリファレンスのための相互運用性ポイントは、ダイナミックマルチ区間ＩＯＰとスタティックジャストインタイムＩＯＰとの組合せであり得る。ＭＰＤは、リモート区間要素を含んでよく（例えば、Period@xlink:href及びPeriod@xlink:actuateが提示されてよく）、ＭＰＤの更新は、ＭＰＤ妥当性期限満了イベントによってトリガされてよい。ダイナミックジャストインタイムＩＯＰへの準拠は、値"http://dashif.org/guidelines/adin/dynamic#jit"を有した@profiles属性によって通知されてよい。
【００５１】
静的なデリファレンスの場合及び動的なマルチ区間デリファレンスの場合のコンテンツ作成のための上記のガイドラインは、動的なジャストインタイムデリファレンスにも適用され得る。（ａ）ＭＰＤの更新の要求及び受信と、（ｂ）来たるリモート区間のデリファレンスとを行うために十分な時間がクライアントに与えられるよう、配慮が必要となり得る。
【００５２】
Period@xlink:actuate="onRequest"である場合、続いてのデリファレンス、すなわち、PeriodStartよりも最大で2×MBT秒前に実行される場合の、第１結果の区間は、（例えば、デリファレンスの余剰回を必要としない）妥当な区間となり得る。リモート要素入力が２以上の区間要素を含む場合、それらは、リモート要素となってよい。
【００５３】
少なくとも１つの実施形態が開示されたが、当技術分野における通常の知識を有する者によってなされる、（複数の）実施形態及び／又は（複数の）実施形態の特徴の変形例、組合せ例、及び／又は修正例は、本開示の範囲内にある。また、（複数の）実施形態の特徴の組合せ、一体化、及び／又は省略の結果として生じる代替形態は、本開示の範囲内にある。数値的な範囲又は限界が明確に指定される場合、そのように明示された範囲又は限界は、明確に指定された範囲又は限界内にある類似した振れ幅の反復範囲又は限界を含む（例えば、「約１から約１０」は、２、３、４、…を含み、「０．１０を超える」は、０．１１、０．１２、０．１３、…を含む）ということを理解されたい。例えば、下限Ｒｌと上限Ｒｕと有する数値範囲が開示され、範囲内にある任意の数が具体的に開示される。詳細には、範囲内の以下の数が具体的に開示される。すなわち、Ｒ＝Ｒｌ＋ｋ＊（Ｒｕ−Ｒｌ）であり、ここで、ｋは、１パーセントの増分で１パーセントから１００パーセントまでの範囲にある変数であり、例えば、ｋは、１パーセント、２パーセント、３パーセント、４パーセント、７パーセント、…、７０パーセント、７１パーセント、７２パーセント、…、９７パーセント、９６パーセント、９７パーセント、９８パーセント、９９パーセント、又は１００パーセントである。さらにまた、上記で定義されたような２つの数Ｒによって定義される数値範囲が具体的に開示される。語「約（about）」の使用は、特に指定しない限り、その後に続く数の１０％前後を意味する。特許請求の範囲の任意の要素に関連した、語「選択的に（optionally）」の使用は、当該要素が必要とされること、又は当該要素が必要とされないことを意味し、それら両方の代替例は、特許請求の範囲内にある。「備える、含む、有する（comprise，include，having）」などのより広い意味を有する語の使用は、「からなる、から本質的になる、から実質的になる（consisting of，consisting essentially of，comprised substantially of）」などのより狭い意味を有する語を包含するものと理解されたい。したがって、保護範囲は、以上の詳細な記載によって限定されるのではなく、添付された特許請求の範囲によって定義され、その範囲には、特許請求の範囲の対象物のすべての均等物が含まれる。本開示における参照文献の説明は、それが従来技術であることを認めるものではなく、特に、この出願の優先日よりも後の公開日を有する任意の参照文献も含む。本開示で引用したすべての特許、特許出願、及び刊行物の開示内容は、引用によって、それらが提供する例、手順、又はその他の補足的な詳細の範囲が本明細書に組み込まれる。
【００５４】
いくつかの実施形態が本開示において提供されたが、開示されたシステム及び方法は、本開示の精神又は範囲から逸脱することなく、他の多くの特定の形態で実施されてよい、ということを理解されたい。本例は、限定ではなく、例示と見なされるべきものであり、その意図は、本開示で与えられた細部に限定することではない。例えば、さまざまな要素又は構成要素は、別のシステムに組み合わせられるか又は一体化されてよく、又は、ある特徴は、省略されるか又は実装されなくてよい。
【００５５】
さらに、さまざまな実施形態において個別に又は分離したものとして説明され、示された技術、システム、及び方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技術、又は方法に組み合わせられるか又は一体化されてよい。互いが接続される、直接的に接続される、又は通信するものとして示されたか又は説明された他の項目は、それが電気的、機械的、又はその他の態様であるか否かに関わらず、何らかのインタフェース、デバイス、又は中間構成要素を介して、間接的に接続されるか又は通信してよい。その他の変更例、代用例、及び置換例は、当業者によって認識可能であり、本開示の精神及び範囲から逸脱することなく実施され得る。
【符号の説明】
【００５６】
１００  アダプティブストリーミングビデオコンテンツ配信システム
１１０  サーバ
１２０  クライアント
１３０  メディアプレゼンテーション記述（ＭＰＤ）
１４０，１４１  セグメント
１５０，１５１  アダプテーションセット
１６０，１６１  リプレゼンテーション
２００  ネットワーク要素（ＮＥ）
２１０  トランシーバ（Ｔｘ／Ｒｘ）
２２０  ダウンストリームポート
２３０  プロセッサ
２３２  メモリ
２３４  ＭＰＤモジュール
２５０  アップストリームポート
３００  ストリーミングシステム
３１０  第１主コンテンツ区間
３１２ａ，３１２ｂ，３１２ｃ，３１２ｄ，３１２ｅ  コンテンツ
３１２ｆ  メッセージ
３２０  クライアント
３３０  更新されたＭＰＤ
３３２  挿入された区間の記述
３３４  挿入されたコンテンツへのＸＬｉｎｋ
３４０  挿入された区間
３５０  第２主コンテンツ区間
３５２ａ，３５２ｂ，３５２ｃ，３５２ｄ，３５２ｅ  コンテンツ
３５２ｆ  メッセージ
４１０  ＤＡＳＨアクセスクライアント
４２０  区間リゾルバ
４３０  ＨＴＴＰ ＧＥＴリクエスト
４４０  広告決定サーバ
４５０  広告決定リクエスト
４６０  広告決定
４７０  （複数の）区間要素
【図１】
2016522621.tif 000003
【図２】
2016522621.tif 000004
【図３】
2016522621.tif 000005
【図４】
2016522621.tif 000006
【図５】
2016522621.tif 000007
【国際調査報告】
2016522621.tif 000008
2016522621.tif 000009