特許 6064249 動的適応ストリーミングオーバーハイパーテキスト転送プロトコルクライアント挙動フレームワークおよびセッション管理の実装

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

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

(11)【特許番号】6064249

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

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

(54)【発明の名称】動的適応ストリーミングオーバーハイパーテキスト転送プロトコルクライアント挙動フレームワークおよびセッション管理の実装

(51)【国際特許分類】

   H04N 21/235 20110101AFI20170116BHJP

   H04N 21/435 20110101ALI20170116BHJP

【ＦＩ】

   H04N21/235

   H04N21/435

【請求項の数】17

【全頁数】21

(21)【出願番号】特願2015-521719(P2015-521719)

(86)(22)【出願日】2013年7月9日

(65)【公表番号】特表2015-530002(P2015-530002A)

(43)【公表日】2015年10月8日

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

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

(87)【国際公開日】20140206

【審査請求日】2015年1月27日

(31)【優先権主張番号】61/669,437

(32)【優先日】2012年7月9日

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

(73)【特許権者】

【識別番号】504161984

【氏名又は名称】ホアウェイ・テクノロジーズ・カンパニー・リミテッド

(74)【代理人】

【識別番号】100146835

【弁理士】

【氏名又は名称】佐伯 義文

(74)【代理人】

【識別番号】100140534

【弁理士】

【氏名又は名称】木内 敬二

(72)【発明者】

【氏名】アレクサンダー・ギラディ

【審査官】 後藤 嘉宏

(56)【参考文献】

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

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

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

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

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

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

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

【請求項1】

動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)についての要求を受信するように構成された受信機と、
前記受信機に結合された、前記MPDを作成するように構成されたプロセッサであって、
前記MPDが、クライアントの挙動を指定するための機構を含み、
前記機構が、特徴をサポートする前記クライアントの能力についてのコンテンツをダウンロードする前記クライアントの能力を調整する、プロセッサと、
前記プロセッサに結合された、前記MPDを送信するように構成された送信機と
を含み、
前記機構が、記述子型記述子のための識別子(ID)属性と、必須プロパティ記述子と、補助プロパティ記述子とのうちの少なくとも1つを含み、
前記ID属性が、前記記述子の識別子を指定し、同一のID属性をもつ記述子が同義であり、
前記必須プロパティ記述子が、含有要素を処理するためにメディアプレゼンテーション著者によって必須であると見なされる前記含有要素に関する情報を指定し、
前記補助プロパティ記述子は、前記クライアントが処理を最適化するのに使用され得る含有要素に関する補足情報を指定する、装置。

【請求項2】

前記機構がセッションを識別する、請求項1に記載の装置。

【請求項3】

前記機構が、セッションID属性と、セッションIDユニフォームリソースロケータ(URL)属性と、セッション持続時間属性とを含むセッション記述子を含み、前記セッションID属性が、セッション識別子を指定し、前記セッションID URL属性が、前記セッションID属性によって記述されるフォーマットでセッションIDを戻すことになるURLを指定し、前記セッション持続時間属性が、前記セッション識別子が受信される時間と新しいセッション識別子を再び要求する必要がある時間との間の時間ウィンドウを指定する、請求項2に記載の装置。

【請求項4】

前記セッション記述子が、セッション解放URL属性とセッション解放パラメータ名属性をさらに含み、前記セッション解放URL属性は、前記クライアントが前記セッションから離れていることをサーバに通知するためのURLを指定し、前記セッション解放パラメータ名属性が、前記セッション識別子を搬送するクエリパラメータの名前を指定する、請求項3に記載の装置。

【請求項5】

前記機構がイベントを識別し、前記イベントが、前記クライアントにまたはアプリケーションに時間関連補助情報をシグナリングするための方法である、請求項1に記載の装置。

【請求項6】

前記機構が、方式IDユニフォームリソース識別子(URI)属性と、ID属性と、行動属性とをもつイベント記述子を含み、前記方式ID URI属性が、方式を識別するためのURIを指定し、前記ID属性が、前記記述子の識別子を指定し、前記行動属性が、記述されたイベントのサポートが必要とされるか否かを指定する、請求項5に記載の装置。

【請求項7】

前記機構が、方式に関連し、前記クライアントによって定義される名前をもつ総称記述子を含む、請求項1に記載の装置。

【請求項8】

前記総称記述子が、グループID属性と、前記総称記述子の挙動を指定する挙動とを含む、請求項7に記載の装置。

【請求項9】

前記機構が、ユニフォームリソースロケータ(URL)認証を与える、請求項1に記載の装置。

【請求項10】

前記機構が、キーURL属性と、キー属性と、持続時間属性とを含むURL認証記述子を含み、前記キーURL属性が、キー導出のためのURLを指定し、前記キー属性が、URL認証キーを指定し、前記持続時間属性が、前記URL認証キー有効の持続時間を指定する、請求項9に記載の装置。

【請求項11】

URL認証記述子が、アルゴリズム属性とパラメータ名属性とをさらに含み、前記アルゴリズム属性が、署名アルゴリズムのユニフォームリソースネーム(URN)を指定し、前記パラメータ名属性が、URL署名を搬送するクエリパラメータの名前を指定する、請求項8に記載の装置。

【請求項12】

動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)を受信するように構成された受信機であって、
前記MPDが、記述子型記述子のための識別子(ID)属性と、必須プロパティ記述子と、補助プロパティ記述子とのうちの少なくとも1つを含み、
前記ID属性が、前記記述子の識別子を指定し、
同一のID属性をもつ記述子が同義であり、
前記必須プロパティ記述子が、含有要素を処理するためにメディアプレゼンテーション著者によって必須であると見なされる前記含有要素に関する情報を指定し、
前記補助プロパティ記述子は、クライアントが処理を最適化するのに使用され得る含有要素に関する補足情報を指定する、受信機と、
前記受信機に結合された、前記MPDを処理するように構成されたプロセッサと
を含む装置。

【請求項13】

ID属性と、必須プロパティ記述子と、補助プロパティ記述子とのうちの少なくとも1つが、セッションを識別するために使用される、請求項12に記載の装置。

【請求項14】

ID属性と、必須プロパティ記述子と、補助プロパティ記述子とのうちの少なくとも1つが、イベントを識別するために使用される、請求項12に記載の装置。

【請求項15】

ID属性と、必須プロパティ記述子と、補助プロパティ記述子とのうちの少なくとも1つが、ユニフォームリソースロケータ(URL)認証を与えるために使用される、請求項12に記載の装置。

【請求項16】

動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)についての要求を受信するステップと、
前記MPDを送信するステップであって、
前記MPDが、クライアントの挙動を指定するための機構を含み、
前記機構が、特徴をサポートする前記クライアントの能力についてのコンテンツをダウンロードする前記クライアントの能力を調整する、送信するステップと
を含み、
前記機構が、記述子型記述子のための識別子(ID)属性と、必須プロパティ記述子と、補助プロパティ記述子とのうちの少なくとも1つを含み、前記ID属性が、前記記述子の識別子を指定し、同一のID属性をもつ記述子が同義であり、前記必須プロパティ記述子が、含有要素を処理するためにメディアプレゼンテーション著者によって必須であると見なされる前記含有要素に関する情報を指定し、前記補助プロパティ記述子は、前記クライアントが処理を最適化するのに使用され得る含有要素に関する補足情報を指定する、方法。

【請求項17】

動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)を受信するステップであって、
前記MPDが、記述子型記述子のための識別子(ID)属性と、必須プロパティ記述子と、補助プロパティ記述子とのうちの少なくとも1つを含み、
前記ID属性が、前記記述子の識別子を指定し、
同一のID属性をもつ記述子が同義であり、
前記必須プロパティ記述子が、含有要素を処理するためにメディアプレゼンテーション著者によって必須であると見なされる前記含有要素に関する情報を指定し、
前記補助プロパティ記述子は、クライアントが処理を最適化するのに使用され得る含有要素に関する補足情報を指定する、受信するステップと、
前記MPDを処理するステップと
を含む方法。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、その全体が組み込まれる「DASH Client Behavior Framework and Implementation of Session Management」と題する、Alexander Giladiにより2012年7月9日に出願された米国仮出願第61/669,437号の優先権を主張する。

【0002】

連邦政府による資金提供を受けた研究開発の記載
適用不可。

【0003】

マイクロフィッシュの補遺の参照
適用不可。

【背景技術】

【0004】

多くのテレビジョンおよび動画の閲覧者は、現在、ビデオおよび他のメディアコンテンツへのオンデマンドアクセスを望んでいる。第1の例として、テレビジョン視聴者は、その人がテレビ番組のテレビジョンでの通常の放送時間中に見逃した番組を見ることを望み得る。閲覧者は、ノートブックコンピュータ、タブレットコンピュータ、デスクトップコンピュータ、携帯電話、または他のデバイス上でウェブブラウザまたは他のアプリケーションを通してインターネットを介して要求に応じて番組をダウンロードし、次いで、ブラウザまたは他のアプリケーション中でその番組を閲覧し得る。第2の例として、閲覧者は、要求に応じて動画をダウンロードし得る。第3の例として、閲覧者は、他の閲覧者とのテレビ会議に参加し得る。

【0005】

動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH:Dynamic Adaptive Streaming over Hypertext Transfer Protocol)は、そのようなメディアコンテンツを与えるために開発された規格であり、その全体が組み込まれる、国際標準化機構(ISO)/国際電気標準会議(IEC)23009-1、First Edition、2012(「23009-1」)に部分的に記載されている。さらに、ISO/IEC 23009-1、Technical Corrigendum 1、2013は、その全体が組み込まれる。DASHには、コンテンツを与えるハイパーテキスト転送プロトコル(HTTP)サーバと、コンテンツをダウンロードし、閲覧者またはユーザに関連付けられるDASHクライアントとの2つの主要なデバイスがある。DASHは、HTTPプロトコルを使用してコンテンツを要求することができるクライアントに制御を負わせる。クライアントは、ネットワーク状態、デバイス能力、およびユーザ選定など、様々なファクタに基づいて複数の形態のコンテンツまたはデータの中から選定し得るので、DASHは動的であり、適応性がある。たとえば、HTTPサーバは、様々なダウンロードビットレートをクライアントに通知し得、クライアントは、それらのビットレートのうちの1つを選定し得、クライアントは、選定されたビットレートでデータのセグメントをダウンロードし始め得る。何らかの理由のために、ネットワーク状態が劣化する場合、クライアントは、より低いビットレートに変更し、新しいビットレートでデータのセグメントをダウンロードし始め得る。したがって、DASHの適応性は、クライアントが利用可能な帯域幅よりも少ない帯域幅を消費することを保証する。

【0006】

クライアントが閲覧することを望むテレビ番組、動画、ビデオ会議、または他のメディアコンテンツは、メインコンテンツと呼ばれ得る。メインコンテンツのプロバイダは、メインコンテンツを与えることに対する収入を獲得することを望み得る。収入を獲得する1つの方法は、メインコンテンツに広告を含めることである。広告は、広告または広告コンテンツと呼ばれ得る。したがって、HTTPサーバは、広告サーバから広告をダウンロードするようにクライアントに指示し得る。クライアントが広告コンテンツをダウンロードし、表示するまで、クライアントは、メインコンテンツまたはメインコンテンツの部分をダウンロードまたは表示することができなくなり得る。さらに、広告コンテンツを閲覧する間にスキップすることができないように、コンテンツが閲覧されるブラウザまたは他のアプリケーションにいくつかの制限が課され得る。クライアントが広告をダウンロードし、閲覧すると、広告コンテンツのプロバイダは、メインコンテンツのプロバイダに代金を支払い得る。

【発明の概要】

【課題を解決するための手段】

【0007】

一実施形態では、本開示は、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)についての要求を受信するように構成された受信機と、受信機に結合された、MPDを作成するように構成されたプロセッサであって、MPDが、クライアントの挙動を指定するための機構を含み、機構が、特徴をサポートするクライアントの能力についてのコンテンツをダウンロードするクライアントの能力を調整する、プロセッサと、プロセッサに結合された、MPDを送信するように構成された送信機とを含む装置を含む。

【0008】

別の実施形態では、本開示は、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)を受信するように構成された受信機であって、MPDが、記述子型記述子のためのID属性と、必須プロパティ記述子と、補助プロパティ記述子とのうちの少なくとも1つを含み、ID属性が、記述子の識別子を指定し、同一のID属性をもつ記述子が同義であり、必須プロパティ記述子が、含有要素を処理するためにメディアプレゼンテーション著者によって必須であると見なされる含有要素に関する情報を指定し、補助プロパティ記述子は、クライアントが処理を最適化するのに使用され得る含有要素に関する補足情報を指定する、受信機と、受信機に結合された、MPDを処理するように構成されたプロセッサとを含む装置を含む。

【0009】

また別の実施形態では、本開示は、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)についての要求を受信するステップと、MPDを送信するステップであって、MPDが、クライアントの挙動を指定するための機構を含み、機構が、特徴をサポートするクライアントの能力についてのコンテンツをダウンロードするクライアントの能力を調整する、送信するステップとを含む方法を含む。

【0010】

また別の実施形態では、本開示は、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)を受信するステップであって、MPDが、記述子型記述子のためのID属性と、必須プロパティ記述子と、補助プロパティ記述子とのうちの少なくとも1つを含み、ID属性が、記述子の識別子を指定し、同一のID属性をもつ記述子が同義であり、必須プロパティ記述子が、含有要素を処理するためにメディアプレゼンテーション著者によって必須であると見なされる含有要素に関する情報を指定し、補助プロパティ記述子は、クライアントが処理を最適化するのに使用され得る含有要素に関する補足情報を指定する、受信するステップと、MPDを処理するステップとを含む方法を含む。

【0011】

これらおよび他の特徴は、添付の図面および特許請求の範囲とともに行われる以下の発明を実施するための形態からより明確に理解されよう。

【0012】

本開示のより完全な理解のために、ここで、添付の図面および発明を実施するための形態と併せて行われる以下の簡単な説明を参照されたい。同様の参照番号は同様の部分を表す。

【図面の簡単な説明】

【0013】

【図1】本開示の一実施形態による、DASHシステムの概略図である。

【図2】本開示の一実施形態による、ネットワークデバイスの概略図である。

【図3】本開示の一実施形態による、DASHシステムのプロトコル図である。

【図4】本開示の一実施形態による、メディアプレゼンテーション記述(MPD:media presentation description)の概略図である。

【図5】本開示の一実施形態による、方法を示すフローチャートである。

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

【0014】

以下に1つまたは複数の実施形態の例示的な実装形態を与えるが、開示するシステムおよび/または方法は、現在知られているか、存在するかにかかわらず、任意の数の技法を使用して実装され得ることを最初に理解されたい。本開示は、本明細書で示し説明する例示的な設計および実装形態を含む、以下に示す例示的な実装形態、図、および技法にいかなる場合も限定されるべきではなく、全範囲の均等物とともに添付の特許請求の範囲内で修正され得る。

【0015】

DASHの設計に関する少なくとも2つの問題がある。第1に、DASHは、HTTPサーバとクライアントとの間のインターフェースを定義するが、クライアントの挙動を直接定義しない。相互運用可能なクライアントを実装するために、DASHは、いくつかのクライアント挙動を指定する必要があり得る。その指定される挙動のいくつかは、広告挿入に関係し得、いくつかは、HTTPサーバまたはコンテンツのプロバイダによって課される、コンテンツをダウンロードおよび閲覧することに対する制限に関係し得る。第2に、HTTPは、ステートレスプロトコルであり、これは、それがデータについての各要求を、任意の前の要求に関係しない独立トランザクションとして扱うことを意味する。したがって、HTTPは、セッションの概念を有しておらず、これは、本開示では、同一ユーザによるメディアプレゼンテーションの連続または非連続ダウンロード、提示、または閲覧を指し得る。たとえば、セッションは、タブレットコンピュータなどの第1のクライアントに関連するユーザが、タブレットコンピュータ上でメディアプレゼンテーションの一部を閲覧することと、タブレットコンピュータ上で閲覧を停止することと、ノートブックコンピュータなどの第2のクライアント上で閲覧を再開することとを含み得る。HTTPのステートレス性とセッションの概念の欠如との結果として、HTTPサーバは、どのクライアントがどのコンテンツをダウンロードしたかを直接知ることができない。むしろ、HTTPサーバは、どのコンテンツが要求され、ダウンロードされたかのみを知る。さらに、クライアントが複数のHTTPサーバからダウンロードしている場合、クライアントは、それがどのHTTPサーバからダウンロードしているのかのみを知る。しかしながら、ある場合にはステートフル性が望ましいことがあり得る。たとえば、クライアントに関する情報を取得し、クライアントに的を絞った広告を与えるために、HTTPサーバまたは広告サーバは、どのクライアントがセッションに関与するのかを知ることを望み得る。さらに、HTTPサーバは、コンテンツについての要求をそのコンテンツのレーティングと相関させることを望み得る。広告およびレーティングは、コンテンツ収益化可能性を拡大し得る。

【0016】

改善されたDASH実装形態のためのシステムおよび方法を本明細書で開示する。開示する技法は、クライアント記述子を通してクライアントの挙動を指定し、セッションを識別するための機構を提供し得る。したがって、開示する技法は、上記の問題の各々に対処し得る。開示する技法はまた、他の規格に適用され、他の規格開発団体(SDO:standards developing organization)によって実装され得る。言い換えれば、開示する技法は、23009-1に、さらには他のDASH規格に限定されない。さらに、開示する技法は、ビデオオンデマンドまたはビデオ会議に限定されず、メディアコンテンツの他の形態にも適用され得る。

【0017】

図1は、本開示の一実施形態による、DASHシステム100の概略図である。システム100は、複数の(たとえば、n個の)HTTPサーバ110と、広告サーバ140と、DASHクライアント150と、ネットワーク180とを含み得る。HTTPサーバ110と、広告サーバ140と、クライアント150とは、ネットワーク180とHTTPキャッシュ(図示せず)などの他のネットワーク構成要素とを介して互いに通信可能に結合され得る。

【0018】

HTTPサーバ110は、HTTPを介してデータを送信および受信するように構成された任意のハードウェアコンピュータサーバであり得る。HTTPサーバ110は、HTTPを介して、DASH規格に従ってデータを送信および受信するように構成されたサーバDASHモジュール(DM)120を含み得る。HTTPサーバは、コンテンツ配信ネットワーク(CDN)130を形成し得、CDN130は、コンテンツを配信するために複数のバックボーンを介して複数のデータセンターで展開されるサーバの分散型システムを指し得る。CDN130は、任意の数のHTTPサーバ110を含み得、したがって、nは任意の数であり得る。典型的には、CDNは、数千個のサーバを含み得る。

【0019】

広告サーバ140は、HTTPを介してデータを送信および受信するように構成された任意のハードウェアコンピュータサーバであり得る。特に、広告サーバ140は、広告についての要求を受信し、他のネットワーク構成要素に要求された広告を送り得る。システム100にわたって任意の数の広告サーバ140があり得る。複数の広告サーバ140がある場合、広告サーバ140は、互いに関連付けられることも関連付けられないこともある。

【0020】

クライアント150は、HTTPを介してデータを送信および受信するように構成された任意のハードウェアデバイスであり得る。たとえば、クライアント150は、ノートブックコンピュータ、タブレットコンピュータ、デスクトップコンピュータ、携帯電話、または別のデバイスであり得る。クライアント150は、クライアントDM155と、アプリケーション170と、グラフィカルユーザインターフェース(GUI)175とを含み得る。

【0021】

クライアントDM155は、HTTPを介して、DASH規格に従ってデータを送信および受信するように構成され得る。クライアントDM155は、DASHアクセスエンジン(DAE:DASH access engine)160と、メディア出力(ME:media output)165とを含み得る。DAE160は、HTTPサーバ110から生データを受信し、そのデータを閲覧のためのフォーマットに構成するための主要構成要素であり得る。たとえば、DAE160は、タイミングデータとともにMoving Picture Experts Group(MPEG)コンテナフォーマットにデータをフォーマットし、次いで、ME165にフォーマットされたデータを出力し得る。ME165は、初期化、再生、およびコンテンツに関連する他の機能を担当し得、アプリケーション170にそのコンテンツを出力し得る。

【0022】

アプリケーション170は、ウェブブラウザまたはコンテンツをダウンロードおよび提示するように構成されたインターフェースをもつ他のアプリケーションであり得る。クライアント150に関連するユーザがアプリケーション170の様々な機能を閲覧し得るように、アプリケーション170はGUI175に結合され得る。ユーザがコンテンツを探索することができるように、アプリケーション170は探索機能を含み得る。たとえば、アプリケーション170がメディアプレーヤである場合、ユーザが動画を探索するために単語の列を入力し得るように、アプリケーション170は探索バーを含み得る。アプリケーション170は、探索ヒットのリストを提示し得、ユーザは、ヒットの中から所望の動画を選択し得る。選択時に、アプリケーション170は、動画をダウンロードするためのクライアントDM155に命令を送り得る。DM155は、動画をダウンロードし、アプリケーション170に出力するための動画を処理し得る。アプリケーション170は、ユーザが閲覧するための動画をGUI175が表示するための命令をGUI175に与え得る。アプリケーション170は、さらに、動画の時間進行を示すプログレスバーをGUI175が表示するための命令をGUI175に与え得る。

【0023】

GUI175は、ユーザがアプリケーションを動作させ得るように、アプリケーション170の機能を表示するように構成された任意のGUIであり得る。上記で説明したように、GUI175は、ダウンロードすべきコンテンツをユーザが選択し得るように、アプリケーション170の様々な機能を表示し得る。GUI175は、次いで、ユーザが閲覧するためのコンテンツを表示し得る。

【0024】

ネットワーク180は、HTTPサーバ110と、広告サーバ140と、クライアント150との間の通信を提供するように構成された任意のネットワークであり得る。たとえば、ネットワーク180は、インターネット、携帯電話網、または別のネットワークであり得る。ネットワーク180により、ワイヤードまたはワイヤレスチャネルに沿った通信が可能になり得る。

【0025】

図2は、本開示の一実施形態による、ネットワークデバイス200の概略図である。デバイス200は、データを受信するための複数の入口ポート210および/または受信機ユニット(Rx)220と、信号を処理するための論理ユニットまたはプロセッサ230と、他の構成要素にデータを送信するための複数の出口ポート240および/または送信機ユニット(Tx)250と、メモリ260とを含み得る。デバイス200は、開示する特徴、方法、およびデバイスのいずれかを実装するのに好適であり得る。たとえば、デバイス200は、HTTPサーバ110、広告サーバ140、およびクライアント150を実装するのに好適であり得る。

【0026】

中央処理ユニット(CPU)と呼ばれ得る論理ユニット230は、入口ポート210、受信機ユニット220、出口ポート240、送信機ユニット250、およびメモリ260と通信していることがあり得る。論理ユニット230は、1つまたは複数のCPUチップ、コア(たとえば、マルチコアプロセッサなど)、フィールドプログラマブルゲートアレイ(FPGA)、特定用途向け集積回路(ASIC)、および/またはデジタル信号プロセッサ(DSP)として実装され得、ならびに/あるいは1つまたは複数のASICの一部であり得る。

【0027】

メモリ260は、1つまたは複数のディスク、テープドライブ、光ディスクドライブ、またはソリッドステートドライブからなり得、データの不揮発性記憶装置のために、およびオーバーフローデータストレージデバイスとして使用され得、プログラムが実行のために選択されたときにそのようなプログラムを記憶するために使用され得、プログラム実行中に読み取られる命令およびデータを記憶するために使用され得る。メモリ260は、揮発性および/または不揮発性であり得、読取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、3値連想メモリ(TCAM:ternary content-addressable memory)、スタティックランダムアクセスメモリ(SRAM:static random-access memory)、別の好適なタイプのメモリ、またはそれらの任意の組合せであり得る。メモリ260は、サーバDM120またはクライアントDM155を実装するのに好適であり得るDM270を含み得る。メモリ260は、DM270を含むものとして示されているが、論理ユニット230または論理ユニット230とメモリ260との任意の組合せがDM270を代替的に含み得る。

【0028】

図3は、本開示の一実施形態による、DASHシステム100のプロトコル図300である。クライアント150は、メインコンテンツをダウンロードすることを望み得る。その場合、ステップ310において、クライアント150は、HTTPサーバ₁110₁にMPDについての要求を送るか、あるいは送信またはアップロードし得、MPDは、HTTPサーバ110の任意の組合せからメインコンテンツのセグメントをダウンロードまたは受信するための命令を含み得る。メインコンテンツのセグメントをダウンロードするための命令に加えて、MPDは、広告サーバ140から広告コンテンツのセグメントをダウンロードする必要があり、そのための命令を含み得る。MPDについて以下でより十分に説明する。ステップ320において、HTTPサーバ₁110₁は、クライアント150にMPDを送り得る。クライアント150は、DAE160を介してMPDを受信し得、DAE160は、メインコンテンツおよび広告コンテンツのセグメントについてのHTTPサーバ110からの要求を構成し発行するために、MPDを処理し得る。

【0029】

ステップ330において、MPDによって命令されたように、クライアント150は、DAE160を介してHTTPサーバ₁110₁に、メインコンテンツの第1のセグメントについての第1のセグメント要求を送り得る。ステップ340において、HTTPサーバ₁110₁は、サーバDM120を介してクライアント150に、メインコンテンツの第1のセグメントを送り得る。DAE160は、第1のセグメントを受信、処理、およびフォーマットし、次いで、ME165にフォーマットされたデータを出力し得、ME165は、様々な機能を実行し、アプリケーション170にデータを出力し得る。バッファリング期間の後に、アプリケーション170は、GUI175を介して閲覧するためのデータを提示し得る。

【0030】

ステップ350において、MPDによって命令されたように、クライアント150は、DAE160を介して広告サーバ140に、広告コンテンツ要求を送り得る。ステップ360において、広告サーバ140は、クライアント150に広告コンテンツを送り得る。MPDは、クライアント150がメインコンテンツの追加のセグメントをダウンロードするのを進める前に、クライアント150が広告コンテンツをダウンロードし提示することを必要とし得る。

【0031】

その後、MPDによって命令されたように、ステップ370において、クライアント150が、DAE160を介してHTTPサーバ₂110₂にメインコンテンツの最後のセグメントについての最後のセグメント要求を送り得るまで、クライアント150は、メインコンテンツならびに広告コンテンツの追加のセグメントについての要求を送り、それを受信し得る。最後に、ステップ380において、HTTPサーバ₂110₂は、サーバDM120を介してクライアント150に、メインコンテンツの最後のセグメントを送り得る。各セグメントを受信した後に、DAE160は、そのセグメントを処理およびフォーマットし、次いで、ME165にフォーマットされたデータを出力し得る。ME165は、様々な機能を実行し、アプリケーション170にデータを出力し得る。バッファリング期間の後に、アプリケーション170は、GUI175を介して閲覧するためのデータを提示し得る。

【0032】

メインコンテンツと広告コンテンツとは、MPDによって命令された任意の順序でダウンロードされ得る。クライアント150は、同時に閲覧のためのコンテンツを表示しながら、コンテンツをダウンロードし得る。同時ダウンロードおよび表示が、プロセスがストリーミングと呼ばれる理由であり得る。MPDを要求し受信するプロセスは反復し得る。たとえば、クライアント150は、様々な理由で更新されたMPDを要求するか、または要求するように命令され得る。

【0033】

図4は、本開示の一実施形態による、MPD400の概略図である。MPD400は、期間410要素と、適応セット420要素と、表現430要素と、セグメント440要素と、サブ表現450要素と、サブセグメント460要素とを含み得る。それらの要素は、大文字の第1の文字またはキャメルケースならびにボールド体によって区別され得るが、ボールド体は本明細書では除去される。たとえば、セグメント440は、セグメントに関連付けられるMPD400の要素であり得、それの後者は、以下でより十分に説明するようにデータのユニットであり得る。同様に、期間410は、データの期間に関連付けられ得る。23009-1では、MPD400は、「ストリーミングサービスを与えるためのメディア表現のための形式化された記述(formalized description for a [m]edia [p]resentation for the purpose of providing a streaming service)」と呼ばれ得る。メディア表現は、次に、「メディアコンテンツの表現...を確立するデータの集まり(collection of data that establishes a...presentation of media content)」と呼ばれ得る。特に、MPD400は、データのセグメントをダウンロードするためのHTTPユニフォームリソースロケータ(URL)またはネットワークアドレスを告知するためのフォーマットを定義し得る。セグメントは、URLに関連するデータのユニットと呼ばれ得る。言い換えれば、セグメントは、概して、単一のURLを使用して単一のHTTP要求で取り出され得るデータの最大ユニットであり得る。MPD400は、拡張マークアップ言語(XML)文書であり得る。

【0034】

要するに、MPD400は、データのセグメントをダウンロードするための1つまたは複数のHTTPサーバ110を指す複数のURL、または複数のURLを構成するためにクライアント150によって使用されるメタデータを含み得る。たとえば、図3を参照すると、クライアント150は、ステップ320において、MPD中で複数のURLを受信し得る。第1のURLは、第1のセグメントに関連付けられ、HTTPサーバ₁110₁を指し得、したがって、クライアント150は、HTTPサーバ₁110₁に第1のセグメントを要求し、受信する。第2のURLは、広告コンテンツに関連付けられ、広告サーバ140を指し得、したがって、クライアント150は、広告サーバ140に広告コンテンツを要求し、受信する。プロセスは、クライアント150が最後のURLに関連するHTTPサーバ110にコンテンツを要求し、受信するまで継続し得る。

【0035】

再び図4を参照すると、MPD400が階層データモデルであることがわかる。23009-1では、期間410は、典型的には、「メディアコンテンツの符号化バージョンの一貫したセットが利用可能であるメディアコンテンツ期間(a media content period during which a consistent set of encoded versions of the media content is available)」を表し得る。言い換えれば、「利用可能なビットレート、言語、キャプション、サブタイトルなどのセットが期間中に変化しない(set of available bitrates, languages, captions, subtitles, etc. does not change during a [p]eriod)」。表現430は、「1つまたは複数のメディアコンテンツコンポーネントの配信可能な符号化バージョン(a deliverable encoded version of one or several media content components)」について記述し得る。クライアント150は、「ネットワーク状態または他のファクタに適応するために...表現間で切り替わり得る(may switch from Representation to Representation…in order to adapt to network conditions or other factors)」。したがって、DASHの適応性は、適応セット420と呼ばれ得る、相互に交換可能な表現430のセットの間にある。クライアント150は、それが特定の表現430をサポートすることができるかどうかを判断し得る。サポートすることができない場合、クライアント150は、それがサポートすることができる異なる表現430を選択し得る。クライアント150は、次いで、クライアント150がダウンロードするのを中止するまで、またはクライアント150が別の表現430を選択するまで、選択された表現内の各セグメントをダウンロードし始め得る。

【0036】

期間410要素と、適応セット420要素と、表現430要素と、セグメント440要素と、サブ表現450要素と、サブセグメント460要素とはデータを記述する。各要素は、要素に関するさらなる定義を与えるという点で要素の同様のプロパティである1つまたは複数の属性を含み得る。要素および属性は、その全体が組み込まれる、Extensible Markup Language(XML)1.0、Fifth Edition、2008において定義されている。属性は、先行する@シンボルによって区別され得る。たとえば、期間410は、期間410に関連する期間がプレゼンテーションタイムライン上でいつ開始するのかを指定し得る@start属性を含み得る。セグメント440要素と、サブ表現450要素と、サブセグメント460要素とは、23009-1において説明されており、本明細書においてさらなる説明を必要としない。

【0037】

上記で説明したように、DASHは、クライアント150の挙動を直接指定しない。ただし、DASHは、特定の特徴のクライアント150のサポートについてのデータをダウンロードするクライアント150の能力を調整し得る。たとえば、表現430がContentProtection記述子を含む場合、クライアント150が、ContentProtection記述子において定義されている方式のうちの少なくとも1つをサポートしない限り、DASHは、クライアント150が表現430に関連するセグメントをダウンロードするのを許可しないことがあり得る。記述子は、コンテンツとコンテンツを識別する一意の方式識別子とを有するデータ構造を指し得る。記述子は、要素のタイプであり得る。DASHは、3つのタイプの記述子を記述する。第1に、表現430中の必須の、または必要な記述子は、表現430に関連するセグメントをダウンロードするために、クライアント150が記述子をサポートすることを必要とし得る。第2に、表現430中の記述子のグループは、表現430に関連するセグメントをダウンロードするために、クライアント150がグループ内の記述子のうちの1つだけをサポートすることを必要とし得る。第3に、表現430中の情報、または随意の記述子は、クライアント150が何かをサポートすることを必要とし得ず、代わりに、表現430に関連するコンテンツに関する情報を単に与え得る。たとえば、クライアント150が、レーティングを表示し、たとえば、ペアレンタルコントロールを通して、表現430に関連するセグメントをダウンロードまたは表示すべきか否かを独力で判断し得るように、レーティング情報記述子は、クライアント150にレーティングを与え得る。

【0038】

したがって、開示する技法は、クライアントの挙動を指定するための汎用フレームワークを含み得る。開示する技法は、汎用フレームワークを使用した新しいセッション記述子と、イベント記述子と、総称記述子と、URL認証記述子とをさらに含み得る。汎用フレームワークおよび新しい記述子は、期間410レベル、適応セット420レベル、表現430レベル、またはサブ表現450レベルにあり得る。汎用フレームワークは、クライアント150の挙動を指定し得、必要な、グループの、および随意のコンテキストに対してクライアント150の挙動を指定し得る。

【0039】

第1の実施形態では、汎用フレームワークは、Table 1(表1)に示す属性をもつ抽象的なDescriptorType記述子から継承される新しいClientDescriptor記述子を含み得る。

【0040】

【表1】

【0041】

Table 1(表1)において、@schemeIdUri属性と@value属性とは、23009-1で与えられる属性と同様であり得る。さらに、汎用フレームワークは、Table 2(表2)に示す属性をもつDescriptorType記述子から継承されるClientDescriptorGroup記述子を含み得る。

【0042】

【表2】

【0043】

第2の実施形態では、汎用フレームワークは、新しいClientDescriptor記述子を含まないことがあり得るが、代わりに、Table 3(表3)に示すDescriptorType記述子のための@id属性を含み得る。

【0044】

【表3】

【0045】

Table 3(表3)では、@id属性は、Table 1(表1)中の@groupId属性と同様であり得、@schemeIdUri属性と@value属性とは、23009-1中に与えられる属性と同様であり得る。さらに、汎用フレームワークは、EssentialProperty記述子とSupplementalProperty記述子とを含み得る。EssentialProperty記述子は、含有要素を処理するためにメディアプレゼンテーション著者によって必須であると見なされる含有要素に関する情報を指定し得る。それぞれ別個の@id値の少なくとも1つのEssentialProperty記述子が処理されることが予想され得る。したがって、EssentialProperty記述子は、Table 1(表1)中の@behaviour属性の必要な値に対応し得る。SupplementalProperty記述子は、DASHクライアントが処理を最適化するのに使用され得る含有要素に関する補足情報を指定し得る。したがって、SupplementalProperty記述子は、Table 1(表1)中の@behaviour属性の随意の値に対応し得る。

【0046】

セッション記述子は、セッションを識別し得る。セッションを識別することによって、HTTPサーバ110は、どのデータがダウンロードされたのか、いつそのデータがダウンロードされたのか、どのクライアントがそのデータをダウンロードしたのかを判断することが可能であり得る。そうする際に、上記で説明したように、HTTPサーバ110または広告サーバ140は、クライアントに的を絞った広告を与え得、HTTPサーバは、コンテンツについての要求をそのコンテンツのレーティングと相関させ得る。さらに、セッションを識別することは、認証および資格付与(たとえば、クライアント150に関連するユーザが、コンテンツを閲覧するために正しいサブスクリプションレベルを購入、レンタル、または取得したかどうか)を行い、これについて以下でより十分に説明する。セッション記述子は、セッションIDをセグメントURLに静的にまたは動的に埋め込むことを行い得る。第1の例として、HTTPサーバ110は、セッションIDをMPD400に挿入し得、クライアント150は、そのセッションIDをセグメントURLに埋め込み得る。セッションIDは同じままであるので、セッションID埋め込みは、静的であると言われ得る。第2の例として、HTTPサーバ110は、セッションID URLをMPD400に挿入し得、クライアント150は、そのURLに関連するHTTPサーバ110にセッションIDを要求し得る。クライアント150が、そのURLに関連するHTTPサーバ110にセッションIDを要求するたびにセッションIDが異なり得るので、セッションIDの埋め込みは、動的であると言われ得る。動的埋め込みは、クライアント150が複数回同じMPD400を使用するときに特に好適であり得る。得られたセッションIDは、$SessionID$置換変数になり得、テンプレート中で使用され得る。

【0047】

第1の実施形態では、セッション記述子は、ClientDescriptor記述子から継承され、したがって、DescriptorType記述子から継承される新しいSessionDescriptor記述子を含み得る。SessionDescriptor記述子は、Table 4(表4)に示す属性を含み得る。

【0048】

【表4】

【0049】

第2の実施形態では、セッション記述子は、セッションを識別するための別の方法を含み得る。セッション記述子は、新しい、継承されたかまたは継承されていない要素、記述子、またはセッションを識別するのに好適な他のデータ構造を含み得る。セッション記述子は、セッションをさらに識別するための属性を含み得る。

【0050】

イベント記述子は、イベントを識別し得る。イベントは、クライアント150にまたはアプリケーション170に時間関連補助情報をシグナリングするための方法と呼ばれ得る。たとえば、イベントは、メインコンテンツが表示している間にクライアント150上に表示する広告であり得る。その点において、広告コンテンツは、メインコンテンツの補助であり得る。イベントストリームは、同じコンテキストをもつイベントシーケンスと呼ばれ得る。たとえば、別個の広告のシーケンスは、メインコンテンツが表示している間にクライアント150上に表示され得る。イベントの主要な目的は、広告挿入を行うことであり得る。したがって、イベント記述子に記述されているイベント、たとえば広告が満たされるまで、イベント記述子は、メインコンテンツをダウンロードまたは表示するのを防ぎ得る。イベント記述子の詳細は、任意の著者、たとえば、HTTPサーバ110または広告サーバ140によって定義され得る。

【0051】

第1の実施形態では、イベント記述子は、ClientDescriptor記述子から継承され、したがって、DescriptorType記述子から継承される新しいEventDescriptor記述子を含み得る。EventDescriptor記述子は、イベント、たとえばメッセージング方式を記述し得る。EventDescriptor記述子は、Table 1(表1)に示す属性を含み得る。@behaviour属性は、記述されたメッセージング方式のサポートが必要であるか否かを示すために使用され得、@value属性は空であり得る。たとえば、方式は、urn:mpeg:dash:client:mpd-updateであり得る。クライアント150がその方式をサポートする場合、クライアント150は、MPD400更新メッセージを受信すると、または第1のMPD400の満了など後の時間に、第2の、更新されたMPD400を要求およびダウンロードする必要があり得る。

【0052】

第2の実施形態では、イベント記述子は、イベントを識別するための別の方法を含み得る。イベント記述子は、新しい、継承されたかまたは継承されていない要素、記述子、またはイベントを識別するのに好適な他のデータ構造を含み得る。イベント記述子は、イベントをさらに識別するための属性を含み得る。

【0053】

総称記述子は、その名前が方式に関連付けられる記述子であり得る。総称記述子は、クライアント150またはクライアント150に関連するユーザによって定義され得る。代替的に、総称記述子は、HTTPサーバ110など、別のネットワーク180の構成要素によって定義され得る。

【0054】

第1の実施形態では、総称記述子は、ClientDescriptor記述子から継承され、したがって、DescriptorType記述子から継承される新しい総称記述子を含み得る。総称記述子は、Table 1(表1)に示す属性を含み得る。総称記述子の挙動は、@groupId属性と@behaviour属性とによって定義され得る。さらに、総称記述子は、クライアント150がそれのタイプを定義することを可能にする追加の属性を含み得る。

【0055】

第2の実施形態では、総称記述子は、クライアント150がそれのタイプを定義するための別の方法を含み得る。総称記述子は、新しい、継承されたかまたは継承されていない要素、記述子、またはクライアント150がそれのタイプを定義するのに好適な他のデータ構造を含み得る。たとえば、総称記述子は、EssentialProperty記述子とSupplementalProperty記述子とを使用して実装され得る。総称記述子は、クライアント150がそれのタイプをさらに定義するための属性を含み得る。

【0056】

URL認証記述子は、URL認証を与え得る。URL認証は、DASHコンテキストで少なくとも5つの利点を与えることができる技法である。第1に、HTTPサーバ110は、URLに関連するデータをアップロードする前に要求を検証し得る。第2に、URLは、指定された時間期間の間、有効にされ得る。第3に、URLは、指定された地理的領域にアクセスを制限し得る。第4に、HTTPサーバ110は、クライアント150に関連するURL署名を認識し、クライアント150が広告コンテンツをダウンロードしている場合、メインコンテンツへのアクセスを制限し得る。第5に、HTTPサーバ110は、クライアント150に関連するURL署名を認識し、クライアント150がセッションをいつ完了したかを判断し、そのセッションについてロギングおよび課金することを可能にし得る。

【0057】

URL認証は、以下の5つのステップを含み得る。第1に、クライアント150は、認証キーとURLとをダウンロードし得る。URLは、たとえば、「www.cdn1.example.com/movie/256K/seg00001.ts」であり得る。第2に、認証キーを使用して、クライアント150は、URLのための署名、たとえば、鍵付きハッシュメッセージ認証コード(HMAC:keyed-hash message authentication code)SHA-1署名を計算し得る。第3に、クライアント150は、著名付きURLを作成するためにURLに署名を付加し得る。著名付きURLは、たとえば、「http://cdn1.example.com/seg00001.ts?seg=198d6c52a8755d77da7239ea0c753a7f7870d0e0」であり得る。第4に、クライアント150は、HTTPサーバ110に、著名付きURLを使用して関連付けられたデータについての要求を送り得る。第5に、HTTPサーバ110が著名付きURLを有効にする場合、HTTPサーバ110は、著名付きURLに関連するデータをアップロードし得、HTTPサーバ110が著名付きURLを無効にする場合、HTTPサーバ110は、要求を破棄するか、またはエラーメッセージをアップロードし得る。認証キーは、指定された時間の後に満了し得る。URL認証がセッション管理のために使用される場合、たとえば、指定された数のデバイスへのコンテンツの共有を制限するために、クライアント150に好都合な時間にセッションを終了することが望ましいことがあり得る。

【0058】

第1の実施形態では、URLは、ClientDescriptor記述子から継承され、したがって、DescriptorType記述子から継承される新しいUrlAuthentication記述子を含み得る。UrlAuthentication記述子は、Table 5(表5)に示す属性を含み得る。

【0059】

【表5】

【0060】

MPD400中の例示的なUrlAuthentication記述子は次の通りであり得る。
<UrlAuthentication
algorithm="urn:mpeg:dash:sea:hmac-sha1"
key="33FD3F35CD966"
parameterName="sig" />。

【0061】

第2の実施形態では、URL認証記述子は、URL認証を行うための別の方法を含み得る。URL認証記述子は、新しい、継承されたかまたは継承されていない要素、記述子、またはURL認証を行うのに好適な他のデータ構造を含み得る。たとえば、URL認証記述子は、EssentialProperty記述子とSupplementalProperty記述子とを使用して実装され得る。URL認証記述子は、URL認証をさらに行うための属性を含み得る。

【0062】

図5は、本開示の一実施形態による、方法500を示すフローチャートである。方法500は、たとえば、クライアント150において実装され得る。ステップ510において、DASH MPDについての要求が受信され得る。たとえば、HTTPサーバ110は、クライアント150から要求を受信し得る。DASH MPDは、MPD400であり得る。ステップ520において、MPDが作成され得る。たとえば、HTTPサーバ110は、MPD400を作成し得る。MPD400は、クライアント150の挙動を指定するための機構を含み得る。機構は、特徴をサポートするクライアント150の能力についてのコンテンツをダウンロードするクライアント150の能力を調整し得る。ステップ530において、MPDが送信され得る。たとえば、HTTPサーバ110は、クライアント150にMPD400を送信し得る。

【0063】

少なくとも1つの実施形態が開示され、当業者によって行われる実施形態および/または実施形態の特徴への変形、組合せ、および/または変更が本開示の範囲内に入る。実施形態の特徴を組み合わせること、統合すること、および/または省略することから生じる代替実施形態も本開示の範囲内に入る。数値範囲または限定が明確に述べられている場合、そのような明示的な範囲または限定が、明確に述べられた範囲または限定内に入る同様の大きさの反復範囲または限定を含むことを理解されたい(たとえば、約1〜約10は2、3、4などを含み、0.10よりも大きいは0.11、0.12、0.13などを含む)。たとえば、下限がR_lおよび上限がR_uの数値範囲が開示されるときはいつでも、その範囲内に入る任意の数が明確に開示される。特に、範囲内の以下の数が明確に開示される。R=R_l+k*(R_u-R_l)、ここで、kは、1パーセントずつ増分する、1パーセントから100パーセントの範囲にある変数であり、すなわち、kは、1パーセント、2パーセント、3パーセント、4パーセント、5パーセント、...、50パーセント、51パーセント、52パーセント、...、95パーセント、96パーセント、97パーセント、98パーセント、99パーセント、または100パーセントである。さらに、上記で定義されている2つのR数によって定義される任意の数値範囲も明確に開示される。「約」という用語の使用は、別段に明記されていない限り、後続の数の+/-10%を意味する。請求項の任意の要素に関する「随意に」という用語の使用は、要素が必要であること、または代替的に、要素が必要でないことを意味し、両方の代替が請求項の範囲内に入る。備える、含む、および有するなどの上位語の使用は、からなる、本質的にからなる、実質的にからなるなどの下位語のサポートを行うことを理解されたい。したがって、保護の範囲は、上記に述べた説明によって限定されず、以下の特許請求の範囲によって定義され、その範囲は、特許請求の範囲の主題のすべての均等物を含む。あらゆる請求項をさらなる開示として明細書に組み込み、特許請求の範囲は本開示の実施形態である。本開示における参照、特に、公開日が本出願の優先日の後である参照に関する議論は、それが従来技術であるとの承認ではない。本開示で引用されるすべての特許、特許出願、および刊
行物の開示は、それらが例示的な詳細、手続きの詳細、または本開示を補う他の詳細を与える範囲で、参照により本明細書に組み込まれる。

【0064】

本開示でいくつかの実施形態を与えたが、開示するシステムおよび方法が、本開示の趣旨または範囲から逸脱することなく、多くの他の特定の形態で実施され得ることが理解され得る。提示する例は、限定的なものではなく例示的なものと見なすべきであり、その意図は、本明細書で与える詳細に限定されるものではない。たとえば、様々な要素または構成要素が別のシステムと組み合わされるかまたは統合され得、あるいはいくつかの特徴が省略されるか、または実装されないことがあり得る。

【0065】

さらに、個別または別個のものとして様々な実施形態で説明されたか、またはそのように示された技法、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく他のシステム、モジュール、技法、または方法と組み合わされるか、または一体化され得る。相互に結合されるものとしてか、または相互に直接結合されるものとしてか、または相互に通信するものとして示されているか、またはそのように説明された他の部材は、間接的に結合されるか、あるいは何らかのインターフェース、デバイス、または電気的でか、機械的でか、もしくは他の方法でかにかかわらず、中間構成要素を通して通信し得る。変更、代替、および改変の他の例が、当業者によって確認可能であり、本明細書で開示した趣旨および範囲から逸脱することなくなされ得る。

【符号の説明】

【0066】

100 DASHシステム
110 HTTPサーバ
110₁ HTTPサーバ₁
110₂ HTTPサーバ₂
110_n HTTPサーバ_n
120 サーバDASHモジュール(DM)
120₁ サーバDM
120₂ サーバDM
120_n サーバDM
130 コンテンツ配信ネットワーク(CDN)
140 広告サーバ
150 DASHクライアント
155 クライアントDM
160 DASHアクセスエンジン(DAE:DASH access engine)
165 メディア出力(ME:media output)
170 アプリケーション
175 グラフィカルユーザインターフェース(GUI)
180 ネットワーク
200 ネットワークデバイス
210 入口ポート
220 受信機ユニット(Rx)
230 論理ユニットまたはプロセッサ
240 出口ポート
250 送信機ユニット(Tx)
260 メモリ
270 DM
300 プロトコル図
400 MPD
410 期間
420 適応セット
430 表現
440 セグメント
450 サブ表現
460 サブセグメント

【図1】

【図2】

【図3】

【図4】

【図5】