(57)【要約】  デバイスは、動的適応ストリーミングオーバーハイパーテキスト転送プロトコルメッセージタイプを示すフレームヘッダをシグナリングし、かつＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ符号化パラメータとしてメッセージタイプに対応する１つ以上の与えられた引数をシグナリングするように構成されてもよい。
2019536312.tif 000002
【特許請求の範囲】
【請求項１】
メディアプレゼンテーションと関連付けられた情報をシグナリングするための方法であって、前記方法は、
動的適応ストリーミングオーバーハイパーテキスト転送プロトコルメッセージタイプを示すフレームヘッダをシグナリングすることと、ＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ符号化パラメータとして前記メッセージタイプに対応する１つ以上の与えられた引数をシグナリングすることと、を含む、方法。
【請求項２】
前記フレームヘッダは、メディアプレゼンテーション記述応答メッセージタイプを示し、与えられた引数は、メディアプレゼンテーション記述パラメータを示す、請求項１に記載の方法。
【請求項３】
前記メディアプレゼンテーション記述パラメータは、符号化された文字列を含む、請求項２に記載の方法。
【請求項４】
前記フレームヘッダは、セグメント要求応答メッセージタイプを示し、与えられた引数は、ステータスパラメータを示す、請求項１に記載の方法。
【請求項５】
与えられた引数は、セグメントパラメータを含み、セグメントパラメータは、符号化された文字列を含む、請求項４に記載の方法。
【請求項６】
メディアプレゼンテーションと関連付けられた情報をシグナリングするデバイスであって、前記デバイスは、請求項１から５に含まれるステップのいずれか及びすべての組み合わせを実行するように構成された１つ以上のプロセッサを備える、デバイス。
【請求項７】
メディアプレゼンテーションと関連付けられた情報を解析するデバイスであって、前記デバイスは、請求項１から５に含まれるステップのいずれか及びすべての組み合わせに従って生成された信号を解析するように構成された１つ以上のプロセッサを備える、デバイス。
【請求項８】
前記デバイスは、メディア配信エンジンを含む、請求項６又は７に記載のデバイス。
【請求項９】
前記デバイスは、演算デバイスを含む、請求項６又は７に記載のデバイス。
【請求項１０】
前記デバイスは、デスクトップ若しくはラップトップコンピュータ、モバイルデバイス、スマートフォン、携帯電話、携帯情報端末（personal data assistant、ＰＤＡ）、テレビ、タブレット型デバイス、又はパーソナルゲーミングデバイスからなる群から選択される、請求項９に記載のデバイス。
【請求項１１】
請求項８のデバイスと、
請求項９のデバイスと、を備える、システム。
【請求項１２】
メディアプレゼンテーションと関連付けられた情報をシグナリングする装置であって、前記装置は、請求項１から５に含まれるステップのいずれか及びすべての組み合わせを実行する手段を備える、装置。
【請求項１３】
実行すると、デバイスの１つ以上のプロセッサに、請求項１から５に含まれるステップのいずれか及びすべての組み合わせを実行させる命令を中に記憶している、非一時的コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、デジタルメディア配信の分野に関する。
【背景技術】
【０００２】
デジタルメディア再生機能は、いわゆる「スマート」テレビを含むデジタルテレビ、セットトップボックス、ラップトップ又はデスクトップコンピュータ、タブレット型コンピュータ、デジタル記録デバイス、デジタルメディアプレイヤ、ビデオゲーミングデバイス、いわゆる「スマート」フォンを含む携帯電話、専用ビデオストリーミングデバイスなどを含む、広範囲のデバイス中に組み込まれ得る。デジタルメディアコンテンツ（例えば、動画像及び音声プログラム）は、例えば、無線テレビプロバイダ、衛星テレビプロバイダ、ケーブルテレビプロバイダ、いわゆるストリーミングサービスプロバイダを含むオンラインメディアサービスプロバイダなどの複数のソースから発信され得る。デジタルメディアコンテンツは、インターネットプロトコル（Internet Protocol、ＩＰ）ネットワークなどの双方向ネットワーク及びデジタル放送ネットワークなどの単方向ネットワークを含むパケット交換ネットワークで送達されてもよい。
【０００３】
デジタルメディアコンテンツは、ソースから受信部デバイス（例えば、デジタルテレビ又はスマートフォン）にコンテンツ送達プロトコルモデルに従って伝送されてもよい。コンテンツ送達プロトコルモードは、１つ以上の伝送規格に基づくことができる。伝送規格の例としては、デジタルビデオブロードキャスティング（Digital Video Broadcasting、ＤＶＢ）規格、統合デジタル放送サービス規格（Integrated Services Digital Broadcasting、ＩＳＤＢ）規格、及び例えば、現在作成中のＡＴＳＣ  ３．０の一連の規格を含む、高度テレビジョン・システムズ委員会（Advanced Television Systems Committee、ＡＴＳＣ）によって作成された規格が挙げられる。ソースから受信部デバイスにデジタルメディアコンテンツを伝送する現在の技術は、理想的でない場合がある。
【発明の概要】
【０００４】
本開示の一実施例によれば、メディアプレゼンテーションと関連付けられた情報をシグナリングする方法は、動的適応ストリーミングオーバーハイパーテキスト転送プロトコルメッセージタイプを示すフレームヘッダをシグナリングすることと、ＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ符号化パラメータとしてメッセージタイプに対応する１つ以上の与えられた引数をシグナリングすることと、を含む。
【図面の簡単な説明】
【０００５】
【図１】図１は、本開示の１つ以上の技術による、コンテンツ送達プロトコルモデルの例を示す概念図である。
【図２】図２は、本開示の１つ以上の技術を実施できるシステムの例を示すブロック図である。
【図３】図３は、本開示の１つ以上の技術を実施できる演算デバイスの例を示すブロック図である。
【図４】図４は、本開示の１つ以上の技術を実施できるメディア配信エンジンの例を示すブロック図である。
【図５】図５は、本開示の１つ以上の技術による、通信フローの例を示す概念図である。
【図６Ａ】図６Ａは、メディアプレゼンテーションドキュメント要求メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【図６Ｂ】図６Ｂは、メディアプレゼンテーションドキュメント要求メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【図７Ａ】図７Ａは、メディアプレゼンテーションドキュメント要求応答メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【図７Ｂ】図７Ｂは、メディアプレゼンテーションドキュメント要求応答メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【図８Ａ】図８Ａは、セグメント要求メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【図８Ｂ】図８Ｂは、セグメント要求メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【図９Ａ】図９Ａは、セグメント要求応答メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【図９Ｂ】図９Ｂは、セグメント要求応答メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【図９Ｃ】図９Ｃは、セグメント要求応答メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【図９Ｄ】図９Ｄは、セグメント要求応答メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【図１０Ａ】図１０Ａは、キャンセル要求メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【図１０Ｂ】図１０Ｂは、キャンセル要求メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【図１１Ａ】図１１Ａは、リソース変更通知メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【図１１Ｂ】図１１Ｂは、リソース変更通知メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。
【発明を実施するための形態】
【０００６】
一般に、本開示は、デジタルメディアコンテンツの配信と関連付けられた通信を可能にする技術について記載する。デジタルメディアコンテンツは、音声ビジュアルサービスの一部として含まれてもよく、又はいくつかの実施例では、専用の音声サービスとして含まれてもよいという点に留意すべきである。いくつかの実施例では、特定の伝送規格及び特定のデジタルメディアフォーマットに関する本開示の技術が記載されているが、本明細書に記載された技術は、一般に、様々な伝送規格及びデジタルメディアフォーマットに適用可能であり得るという点に留意すべきである。例えば、本明細書に記載された技術は、一般に、ＤＶＢ規格、ＩＳＤＢ規格、ＡＴＳＣ規格、Ｄｉｇｉｔａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ（ＤＴＭＢ）規格、Ｄｉｇｉｔａｌ  Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ（ＤＭＢ）規格、Ｈｙｂｒｉｄ  Ｂｒｏａｄｃａｓｔ  ａｎｄ  Ｂｒｏａｄｂａｎｄ  Ｔｅｌｅｖｉｓｉｏｎ（ＨｂｂＴＶ）規格、ワールド・ワイド・ウェブ・コンソーシアム（World Wide Web Consortium、Ｗ３Ｃ）規格、ユニバーサルプラグアンドプレイ（Universal Plug and Play、ＵＰｎＰ）規格、及びムービング・ピクチャー・エキスパート・グループ（Moving Pictures Expert Group、ＭＰＥＧ）規格のうちのいずれかに適用可能であり得る。更に、本明細書への文書の参照による組み込みは、説明を目的としており、本明細書で使用される用語に関して限定する及び／又は曖昧さを生み出すように構築されるべきではないという点に留意すべきである。例えば、ある組み込まれた参照が別の組み込まれた参照とは異なる用語の定義をもたらす場合、及び／又はその用語が本明細書で使用される場合、その用語は、各それぞれの定義を広く含むやり方で、及び／又は代替物における特定の定義の各々を含むやり方で解釈されるべきである。
【０００７】
本開示の別の実施例によれば、メディアプレゼンテーションと関連付けられた情報をシグナリングするデバイスは、動的適応ストリーミングオーバーハイパーテキスト転送プロトコルメッセージタイプを示すフレームヘッダをシグナリングし、かつＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ符号化パラメータとしてメッセージタイプに対応する１つ以上の与えられた引数をシグナリングするように構成された１つ以上のプロセッサを備える。
【０００８】
本開示の別の実施例によれば、メディアプレゼンテーションと関連付けられた情報をシグナリングする装置は、動的適応ストリーミングオーバーハイパーテキスト転送プロトコルメッセージタイプを示すフレームヘッダをシグナリングする手段と、ＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ符号化パラメータとしてメッセージタイプに対応する１つ以上の与えられた引数をシグナリングする手段と、を含む。
【０００９】
本開示の別の実施例によれば、非一時的コンピュータ可読記憶媒体は、実行すると、デバイスの１つ以上のプロセッサに、動的適応ストリーミングオーバーハイパーテキスト転送プロトコルメッセージタイプを示すフレームヘッダをシグナリングさせ、かつＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ符号化パラメータとしてメッセージタイプに対応する１つ以上の与えられた引数をシグナリングさせる命令を中に記憶している。
【００１０】
１つ以上の実施例の詳細は、添付の図面及び以下の明細書に記述されている。他の特徴、目的、及び利点は、明細書及び図面から、並びに特許請求の範囲から明白であろう。
【００１１】
演算デバイス及び／又は伝送システムは、１つ以上の抽象化層を含むモデルに基づいてもよく、各抽象化層のデータは、特定の構造、例えば、パケット構造、変調方式などに従って表される。定義された抽象化層を含むモデルの一例は、いわゆる開放型システム間相互接続（Open Systems Interconnection、ＯＳＩ）モデルである。ＯＳＩモデルは、アプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、データリンク層、及び物理層を含む、７層スタックモデルを定義する。スタックモデル内の層の記述に関して上位（upper）及び下位（lower）という用語を使用することは、最上層であるアプリケーション層及び最下層である物理層に基づいてもよいという点に留意すべきである。更に、場合によっては、用語「層１」又は「Ｌ１」を使用して、物理層を指すことができ、用語「層２」又は「Ｌ２」を使用して、リンク層を指すことができ、用語「層３」又は「Ｌ３」又は「ＩＰ層」を使用して、ネットワーク層を指すことができる。
【００１２】
物理層は、一般に、電気信号がデジタルデータを形成する層を指すことができる。例えば、物理層は、変調された無線周波数（radio frequency、ＲＦ）シンボルがデジタルデータのフレームをどのように形成するかを定義する層を指すことができる。リンク層とも呼ばれることもあるデータリンク層は、送信側での物理層処理前及び受信側での物理層受信後に使用される抽象化を指すことができる。本発明で使用する場合、リンク層は、送信側でのネットワーク層から物理層へのデータのトランスポートに使用される、及び受信側での物理層からネットワーク層へのデータのトランスポートに使用される抽象化を指すことができ、送信側及び受信側は、論理的役割であり、単一デバイスは、あるインスタンスの送信側及び別のインスタンスの受信側の両方として動作できるという点に留意すべきである。リンク層は、特定のパケットタイプ（例えば、インターネットプロトコルバージョン４（ＩＰｖ４）パケットなど）にカプセル化された様々なタイプのデータ（例えば、動画像ファイル、音声ファイル、又はアプリケーションファイル）を物理層による処理のための単一汎用フォーマットに抽象化することができる。ネットワーク層は、一般に、論理アドレッシングが発生する層を指すことができる。すなわち、ネットワーク層は、一般に、アドレッシング情報（例えば、ＩＰアドレス）を提供することができ、これにより、データパケットをネットワーク内の特定のノード（例えば、演算デバイス）に送達することができる。本発明で使用する場合、ネットワーク層という用語は、リンク層の上の層及び／又はリンク層処理のために受信され得るような構造のデータを有する層を指すことができる。トランスポート層は、いわゆるプロセス間通信サービスを可能にする層を指すことができる。セッション層、プレゼンテーション層、及びアプリケーション層の各々は、ユーザアプリケーションによって使用するためにデータをどのように送達するかを定義することができる。現在作成中の伝送規格を含む伝送規格は、各層毎にサポートされたプロトコルを規定するコンテンツ送達プロトコルモデルを含むことができ、１つ以上の特定の層実装を更に定義することができる。
【００１３】
図１は、本明細書に記載された技術による、コンテンツ送達プロトコルモデルの例を示す。本明細書に記載された技術は、コンテンツ送達プロトコルモデル１００に基づいて動作するように構成されたシステムに実装することができる。
コンテンツ送達プロトコルモデル１００は、デジタルメディアコンテンツの配信を可能にすることができる。したがって、コンテンツ送達プロトコルモデル１００は、ユーザがメディアサービスプロバイダ（例えば、いわゆるストリーミングサービス）からのデジタルメディアコンテンツにアクセスできるようにするシステムに実装することができる。メディアサービス又はメディアプレゼンテーションという用語を使用して、ユーザに集合的に提示されるメディアコンポーネント（例えば、動画像コンポーネント、音声コンポーネント、及びサブタイトルコンポーネント）の集合を指すことができ、コンポーネントは、複数のメディアタイプであることができ、サービスは、連続的又は断続的のいずれかであることができ、サービスは、リアルタイムサービス（例えば、ライブイベントに対応するマルチメディアプレゼンテーション）又は非リアルタイムサービス（例えば、ビデオオンデマンドサービス）であることができる。
【００１４】
図１に示したように、コンテンツ送達プロトコルモデル１００は、物理層及びデータリンク層を含む。前述したように、物理層は、一般に、電気信号がデジタルデータを形成する層を指すことができ、データリンク層は、物理層による処理のための汎用フォーマットを含むことができる。図１に示された実施例では、いくつかの例において、物理層は、定義されたプリアンブルを含む物理層フレーム構造と、ＲＦチャネル又はＲＦチャネルの一部内に１つの論理構造を含むデータペイロード構造と、を含むことができる。図１に示された実施例では、データリンク層は、様々な特定のパケットタイプを物理層による処理のための単一汎用フォーマットに抽象化するために使用されるデータ構造であってもよく、前述したように、ネットワーク層は、一般に、論理アドレッシングが発生する層を指すことができる。図１を参照すると、コンテンツ送達プロトコルモデル１００は、ＩＰアドレッシングスキーム、例えば、ネットワーク層としてＩＰｖ４及び／又はＩＰｖ６を利用することができる。前述したように、トランスポート層は、一般に、いわゆるプロセス間通信サービスを可能にする層を指すことができる。図１に示したように、コンテンツ送達プロトコルモデル１００は、トランスポート層としてトランスポートコントロールプロトコル（Transport Control Protocol、ＴＣＰ）を利用することができる。
【００１５】
前述したように、コンテンツ送達プロトコルモデル１００は、デジタルメディアコンテンツの配信を可能にすることができる。図１の実施例では、アプリケーションは、ユーザがデジタルメディアコンテンツをレンダリングすることを可能にするアプリケーションを含むことができる。例えば、コンテンツ送達プロトコルモデルは、モバイルデバイスなどで動作する動画像プレイヤアプリケーションを含むことができる。図１に示された実施例では、メディアコーデックは、デジタルメディアコンテンツフォーマット（例えば、ＭＰＥＧフォーマットなど）をアプリケーションによってレンダリングすることを可能にする、基礎コーデック（すなわち、マルチメディアエンコーダ／デコーダ実装）を含むことができる。図１に示された実施例では、コンテンツ送達プロトコルモデル１００は、動的適応ストリーミングオーバーＨＴＴＰ（Dynamic adaptive streaming over ＨＴＴＰ、ＤＡＳＨ）を利用して、論理クライアントが論理サーバからデジタルメディアコンテンツを受信できるようにする。ＤＡＳＨは、ＭＰＥＧ  ＤＡＳＨ  ＩＳＯ／ＩＥＣ：ＩＳＯ／ＩＥＣ  ２３００９〜１：２０１４，「Ｉｎｆｏｒｍａｔｉｏｎ  ｔｅｃｈｎｏｌｏｇｙ＿Ｄｙｎａｍｉｃ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ（ＤＡＳＨ）−Ｐａｒｔ１：Ｍｅｄｉａ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｓｃｒｉｐｔｉｏｎ  ａｎｄ  ｓｅｇｍｅｎｔ  ｆｏｒｍａｔｓ」，Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｏｒｇａｎｉｚａｔｉｏｎ  ｆｏｒ  Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ，２ｎｄ  Ｅｄｉｔｉｏｎ，５／１５／２０１４（以下では、「ＩＳＯ／ＩＥＣ  ２３００９〜１：２０１４」）のＤＡＳＨ−ＩＦプロファイルに記載されており、これは、本明細書に参考として組み込まれる。図１に示したように、ＤＡＳＨメディアプレゼンテーションは、データセグメント、動画像セグメント、及び音声セグメントを含むことができる。いくつかの実施例では、ＤＡＳＨメディアプレゼンテーションは、サービスプロバイダによって定義された所与の期間の線形サービス又は線形サービスの一部（例えば、単一のＴＶ番組、又はある期間にわたる連続した線形ＴＶ番組の組）に対応することができる。ＤＡＳＨに従って、メディアプレゼンテーションドキュメント（ＭＰＤ）は、ＤＡＳＨメディアプレゼンテーションのプロファイルの形式化した記述を含むメタデータフラグメントである。フラグメントは、拡張可能マークアップ言語（eXtensible Markup Language、ＸＭＬ）符号化メタデータフラグメントのセットを含むことができる。ＭＰＤのコンテンツは、セグメントのためのリソース識別子及びメディアプレゼンテーション内の識別されたリソースのためのコンテキストを提供する。ＭＰＤフラグメントのデータ構造及びセマンティックスは、ＩＳＯ／ＩＥＣ  ２３００９〜１：２０１４に関して記載されている。更に、ＩＳＯ／ＩＥＣ  ２３００９〜１のドラフト版が現在提案されているという点に留意すべきである。したがって、図１に示された実施例では、ＭＰＤは、ＩＳＯ／ＩＥＣ  ２３００９〜１：２０１４に記載のようなＭＰＤ、現在提案されているＭＰＤ、及び／又はこれらの組み合わせを含むことができる。
【００１６】
ＩＳＯ／ＩＥＣ  ２３００９〜１：２０１４において、ＭＰＤに記載されているメディアプレゼンテーションは、１つ以上のピリオド（Period）のシーケンスを含むことができ、各ピリオドは、１つ以上のアダプテーションセット（Adaptation Set）を含むことができる。アダプテーションセットが複数のメディアコンテンツコンポーネントを含む場合、各メディアコンテンツコンポーネントを個別に記述してもよいという点に留意すべきである。各アダプテーションセットは、１つ以上のリプレゼンテーション（Representation）を含むことができる。ＩＳＯ／ＩＥＣ  ２３００９〜１：２０１４において、各リプレゼンテーションは、次のように提供される。（１）単一セグメントとして、サブセグメントがアダプテーションセットのリプレゼンテーションにわたって整列される、及び（２）セグメントのシーケンスとして、各セグメントは、テンプレートで生成されたユニバーサルリソースロケータ（Universal Resource Locator、ＵＲＬ）によってアドレス指定可能である。各メディアコンテンツコンポーネントのプロパティは、アダプテーションセット要素、及び／又は例えば、コンテンツコンポーネント（ContentComponent）要素を含むアダプションセット（AdaptionSet）内の要素によって記述されてもよい。
【００１７】
図１に示したように、ＤＡＳＨは、ＨＴＴＰ及びＷｅｂＳｏｃｋｅｔプロトコルの上で動作してもよい。すなわち、ＤＡＳＨメディアプレゼンテーションは、Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ（ＩＥＴＦ）Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔ（ＲＦＣ）７５４０のＨｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  ２（ＨＴＴＰ／２）（２０１５年５月）に記載されているＨＴＴＰ／２、及びＩｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ、ＲＦＣ  ６４５５のＩＥＴＦ：「Ｔｈｅ  ＷｅｂＳｏｃｋｅｔ  Ｐｒｏｔｏｃｏｌ」（２０１１年１２月）、及びｔｈｅ  ＷｅｂＳｏｃｋｅｔ  ＡＰＩ（ワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ）勧告候補、２０１２年９月２０日）に記載されているＷｅｂＳｏｃｋｅｔプロトコルを含む、全二重ＨＴＴＰ対応プロトコルを介して搬送されてもよく、これらは、各々がそれぞれ本明細書に参照として組み込まれる。
【００１８】
ＷｅｂＳｏｃｋｅｔプロトコルは、双方向ソケットの確立を通じて、論理クライアントと論理サーバ（リモートホストと呼ばれることもある）との間で相互通信を可能にする。場合によっては、双方向ソケットの側方又はエンドポイントは、ターミナルと呼ばれることもあるという点に留意すべきである。ＷｅｂＳｏｃｋｅｔプロトコルに基づく双方向ソケットは、ユニバーサルトランスフォーメーションフォーマット−８（Universal Transformation Format-8、ＵＴＦ−８）で符号化された文字データを、ＴＣＰを介して論理クライアントと論理サーバとの間で交換することができる双方向ソケットを含む。２３００９−６：ＤＡＳＨ  ｗｉｔｈ  Ｓｅｒｖｅｒ  Ｐｕｓｈ  ａｎｄ  ＷｅｂＳｏｃｋｅｔｓ（ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１１／Ｗ１６２３２、２０１６年６月）の国際規格案（以下では、「Ｗ１６２３２」）（これは、本明細書に参考として組み込まれる）は、ＷｅｂＳｏｃｋｅｔプロトコルに基づく双方向ソケットを使用して、ＭＰＥＧ−ＤＡＳＨメディアプレゼンテーションの送達を駆動するためのシグナリング及びメッセージフォーマットを定義する。
【００１９】
Ｗ１６２３２において、サーバからクライアントへのセグメントの伝送（Ｗ１６２３２においてプッシュ（push）と呼ばれる）は、プッシュストラテジに基づき、これは、セグメントをサーバからクライアントへ伝送することができる方法を定義する。Ｗ１６２３２において、プッシュディレクティブ（push directive）は、クライアントからサーバへ送信される要求修飾子であり、これにより、クライアントは、要求を処理するためのサーバのプッシュストラテジに関するその期待を表現することができる。更に、Ｗ１６２３２において、プッシュ肯定応答（Ｐｕｓｈ  Ａｃｋとも呼ばれる）は、サーバからクライアントへ送信される応答修飾子であり、これにより、サーバは、要求を処理する際に使用されるプッシュストラテジを述べることができる。Ｗ１６２３２において、プッシュディレクティブ及びプッシュ肯定応答は、ＤＡＳＨサブプロトコルフレームヘッダ及び１つ以上の与えられた引数を含むメッセージを送信することによって通信され得る。Ｗ１６２３２において提供されるようなＤＡＳＨサブプロトコルフレームヘッダのセマンティックスは、表１で提供される。
【表１】
2019536312.tif 000003
【００２０】
Ｗ１６２３２では、ＳＴＲＥＡＭ＿ＩＤ、ＭＳＧ＿ＣＯＤＥ、Ｅ、Ｆ、ＥＸＴ＿ＬＥＮＧＴＨ、及びＥｘｔｅｎｓｉｏｎの各々について以下の定義が提供されている。
ＳＴＲＥＡＭ＿ＩＤ：現在のストリームの識別子であり、同一のＷｅｂＳｏｃｋｅｔ接続を介する複数の要求／応答の多重化を可能にする。特定の要求への応答は、その要求と同一のＳＴＲＥＡＭ＿ＩＤを使用するものとする。新しいＳＴＲＥＡＭ＿ＩＤの出現は、新しいストリームが開始されたことを示す。キャンセル要求、ストリームの終了、又はエラーの受信により、搬送されたＳＴＲＥＡＭ＿ＩＤによって識別されるストリームを閉じるものとする。
【００２１】
ＭＳＧ＿ＣＯＤＥ：このフレームで表されるＭＰＥＧ−ＤＡＳＨメッセージを示す。利用可能なメッセージコードは、表２で定義される。
【表２】
2019536312.tif 000004
【００２２】
Ｅ：このフィールドは、エラーフラグである。このフィールドが設定されていると、受信部は、エラーとしてメッセージを解釈できる。エラーに関する付加情報は、拡張ヘッダにおいて利用可能であってもよい。
Ｆ：予約
ＥＸＴ＿ＬＥＮＧＴＨ：パディングを含む、アプリケーションデータに先行する４バイト長の拡張データを提供する。
Ｅｘｔｅｎｓｉｏｎ：拡張ヘッダは、ＩＥＴＦ  ＲＦＣ７１５８［Ｔｈｅ  ＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）  Ｄａｔａ  ｌｎｔｅｒｃｈａｎｇｅ  Ｆｏｒｍａｔ、２０１３年３月、これは、本明細書に参考として組み込まれる］に準拠する、要求／応答に適用される付加情報フィールドのＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）符号化でなければならない。４バイトの境界にそろえるために、０バイトのパディングを拡張ヘッダ後に追加することができる。コンテンツは、ＵＴＦ−８フォーマットで符号化されているとする。拡張ヘッダのＪＳＯＮ符号化は、ゼロ以上の名前／値の対を含む、単一ルートレベルＪＳＯＮオブジェクトからなるものとする。
【００２３】
表２に示したように、各メッセージタイプは、表３〜表８に示されている与えられた引数を含む。表３〜表８の各々において、型（Type）は、データ型を示し、ＵＲＩは、ＲＦＣ３９８６で定義されたユニフォームリソース識別子（Uniform Resource Identifier、ＵＲＩ）を含む文字列であり、Ｓｔｒｉｎｇは、ＵＴＦ−８文字の文字列、整数であり、Ｂｏｏｌｅａｎは、ｔｒｕｅ又はｆａｌｓｅの値である。表３〜表８の各々において、基数は、メッセージのインスタンスにおけるパラメータの必要なインスタンス数を示し、０は、パラメータ値のシグナリングが任意選択であることを示す。
【表３】
2019536312.tif 000005
【表４】
2019536312.tif 000006
【表５】
2019536312.tif 000007
【表６】
2019536312.tif 000008
【表７】
2019536312.tif 000009
【表８】
2019536312.tif 000010
【００２４】
表３及び表４を参照すると、Ｗ１６２３２は、ＰｕｓｈＤｉｒｅｃｔｉｖｅパラメータに次のフォーマットを提供する。
【００２５】
ＡＢＮＦ［ＩＥＴＦ  ＲＦＣ  ５２３４、Ａｕｇｍｅｎｔｅｄ  ＢＮＦ［Ｂａｃｋｕｓ−Ｎａｕｒ  Ｆｏｒｍ］  ｆｏｒ  Ｓｙｎｔａｘ  Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ：ＡＢＮＦ、２００８年１月］形式におけるＰｕｓｈＤｉｒｅｃｔｉｖｅのフォーマットは、次のとおりである：
ＰＵＳＨ＿ＤＩＲＥＣＴＩＶＥ＝ＰＵＳＨ＿ＴＹＰＥ［ＯＷＳ  ＯＷＳ  ＱＶＡＬＵＥ］
ＰＵＳＨ＿ＴＹＰＥ＝＜［以下］で定義されたＰｕｓｈＴｙｐｅ＞
ＱＶＡＬＵＥ＝＜ＲＦＣ７２３１に記載のｑｖａｌｕｅ＞
「ＯＷＳ」は、ＲＦＣ７２３０［ＩＥＴＦ  ＲＦＣ７２３０、Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ／１．１）：Ｍｅｓｓａｇｅ  Ｓｙｎｔａｘ  ａｎｄ  Ｒｏｕｔｉｎｇ、２０１４年６月］、セクション３．２．３に定義されており、任意選択の空白を表す。
【００２６】
複数のプッシュディレクティブが要求に適用される際、クライアントは、ＲＦＣ７２３１のコンテンツネゴシエーションにて使用するために記載されるように、品質値（「ｑｖａｌｕｅ」）を適用することができる。クライアントは、より低い品質値である代替のディレクティブよりも優先したいディレクティブにより高い品質値を適用することができる。これらの値は、サーバへのヒントであり、サーバが最も高い品質値を有するストラテジーを必ず選択するという意味ではないことに留意されたい。
【００２７】
表５及び表６を参照すると、Ｗ１６２３２は、ＰｕｓｈＡｃｋに次のフォーマットを提供する。
ＡＢＮＦ形式におけるＰｕｓｈＡｃｋのフォーマットは、次のとおりである：
ＰＵＳＨ＿ＡＣＫ＝ＰＵＳＨ＿ＴＹＰＥ
式中、ＰＵＳＨ＿ＴＹＰＥは、［以下］で定義される。
Ｗ１６２３２は、ＰｕｓｈＴｙｐｅに次のフォーマットを提供する：
ＡＢＮＦ形式におけるＰｕｓｈＴｙｐｅのフォーマットは、次のとおりである：
ＰＵＳＨ＿ＴＹＰＥ＝ＰＵＳＨ＿ＴＹＰＥ＿ＮＡＭ［ＯＷＳ”；”ＯＷＳ  ＰＵＳＨ＿ＰＡＲＡＭＳ］ＰＵＳＨ＿ＴＹＰＥ＿ＮＡＭＥ＝ＤＱＵＯＴＥ＜ＵＲＮ＞ＤＱＵＯＴＥ
ＰＵＳＨ＿ＰＡＲＡＭＳ＝ＰＵＳＨ＿ＰＡＲＡＭ＊（ＯＷＳ”；”ＯＷＳ  ＰＵＳＨ＿ＰＡＲＡＭ）
ＰＵＳＨ  ＰＡＲＡＭ＝１＊ＶＣＨＡＲ
式中、
−「＜ＵＲＮ＞」構文は、ＲＦＣ  ２１４１［ＩＥＴＦ  ＲＦＣ  ２１４１、Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｎａｍｅｓ（ＵＲＮ）  Ｓｙｎｔａｘ、１９９７年５月］に定義されている。
【００２８】
Ｗ１６２３２においてプッシュディレクティブ及びプッシュ肯定応答をシグナリングするために定義されたメッセージは、理想的でない場合がある。
【００２９】
図２は、本開示中に記載された１つ以上の技術を実施できるシステムの例を示すブロック図である。システム２００は、本明細書に記載された技術に従って、データを通信するように構成されてもよい。図２に示された実施例では、システム２００は、１つ以上の演算デバイス２０２Ａ〜２０２Ｎ、１つ以上のコンテンツプロバイダサイト２０４Ａ〜２０４Ｎ、データベース２０６、１つ以上のメディア配信エンジン２０８Ａ〜２０８Ｎ、及びワイドエリアネットワーク２１０を含む。システム２００は、ソフトウェアモジュールを含むことができる。ソフトウェアモジュールは、メモリ内に記憶され、プロセッサによって実行することができる。システム２００は、１つ以上のプロセッサ並びに複数の内部メモリデバイス及び／又は外部メモリデバイスを含むことができる。メモリデバイスの例としては、ファイルサーバ、ファイル転送プロトコル（file transfer protocol、ＦＴＰ）サーバ、ネットワークアタッチトストレージ（network attached storage、ＮＡＳ）デバイス、ローカルディスクドライブ、又はデータを記憶できる任意の他のタイプのデバイス若しくは記憶媒体が挙げられる。記憶媒体は、Ｂｌｕ−ｒａｙ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、磁気ディスク、フラッシュメモリ、又は任意の他の好適なデジタル記憶媒体を含むことができる。本明細書に記載された技術がソフトウェア内に部分的に実装されている場合、デバイスは、好適な非一時的コンピュータ可読媒体内にソフトウェアの命令を記憶し、かつ１つ以上のプロセッサを使用して、ハードウェア内で命令を実行することができる。
【００３０】
システム２００は、例えば、映画、ライブスポーツイベントなどのデジタルメディアコンテンツ、並びにデータ及びアプリケーション及びそれらに関連するメディアプレゼンテーションが複数の演算デバイスに配信され及びそれらによってアクセスされることが可能となるように構成され得るシステムの一例を表す。図２に示された実施例では、演算デバイス２０２Ａ〜２０２Ｎは、有線通信及び／又は無線通信のために装備された任意のデバイスを含むことができ、テレビ、セットトップボックス、デジタルビデオレコーダ、デスクトップ、ラップトップ、又はタブレット型コンピュータ、ゲーミングコンソール、例えば、「スマート」フォン、携帯電話、及びパーソナルゲーミングデバイスを含むモバイルデバイスを含むことができる。システム２００は、別個のサイトを有するものとして図示されるが、このような図示は、説明を目的としており、システム２００を特定の物理アーキテクチャに限定しないという点に留意すべきである。システム２００及びそれに含まれるサイトの機能は、ハードウェア実装、ファームウェア実装、及び／又はソフトウェア実装の任意の組み合わせを使用して実現することができる。
【００３１】
図３は、本開示の１つ以上の技術を実施できる演算デバイスの例を示すブロック図であり、演算デバイス３００は、通信ネットワークからデータを受信し、ユーザがマルチメディアコンテンツにアクセスすることを可能にするように構成され得る演算デバイスの一例である。演算デバイス３００は、中央処理装置（単数又は複数）３０２、システムメモリ３０４、システムインターフェース３１２、音声デコーダ３１４、音声出力システム３１６、動画像デコーダ３１８、表示システム３２０、Ｉ／Ｏデバイス（単数又は複数）３２２、及びネットワークインターフェース３２４を含む。中央処理装置（単数又は複数）３０２、システムメモリ３０４、システムインターフェース３１２、音声デコーダ３１４、音声出力システム３１６、動画像デコーダ３１８、表示システム３２０、Ｉ／Ｏデバイス（単数又は複数）３２２、及びネットワークインターフェース３２４の各々は、コンポーネント間通信のために（物理的、通信的、及び／又は動作的に）相互接続してもよく、１つ以上のマイクロプロセッサ、デジタル信号プロセッサ（digital signal processors、ＤＳＰ）、特定用途向け集積回路（application specific integrated circuits、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（field programmable gate arrays、ＦＰＧＡ）、ディスクリートロジック、ソフトウェア、ハードウェア、ファームウェア、又はこれらの組み合わせなどの様々な好適な回路のいずれかとして実装することができる。演算デバイス３００は、別個の機能ブロックを有するものとして図示されるが、このような図示は、説明を目的としており、演算デバイス３００を特定のハードウェアアーキテクチャに限定しないという点に留意すべきである。演算デバイス３００の機能は、ハードウェア実装、ファームウェア実装、及び／又はソフトウェア実装の任意の組み合わせを使用して実現することができる。
【００３２】
ＣＰＵ（単数又は複数）３０２は、演算デバイス３００において実行するための機能及び／又はプロセス命令を実施するように構成されてもよい。ＣＰＵ（単数又は複数）３０２は、シングルコア及び／又はマルチコアの中央処理装置を含むことができる。ＣＰＵ（単数又は複数）３０２は、本明細書に記載された技術のうちの１つ以上を実施するための命令、コード、及び／又はデータ構造を検索及び処理することが可能であり得る。命令は、システムメモリ３０４などのコンピュータ可読媒体に記憶され得る。システムメモリ３０４は、非一時的又は有形のコンピュータ可読記憶媒体として記載することができる。いくつかの実施例では、システムメモリ３０４は、一時的及び／又は長期記憶部を提供することができる。いくつかの実施例では、システムメモリ３０４又はその一部は、不揮発性メモリとして記載されてもよく、別の実施例では、システムメモリ３０４の一部は、揮発性メモリとして記載されてもよい。システムメモリ３０４は、動作中に演算デバイス３００によって使用され得る情報を記憶するように構成されてもよい。システムメモリ３０４は、ＣＰＵ（単数又は複数）３０２によって実行するためのプログラム命令を記憶するために使用することができ、演算デバイス３００上で実行しているプログラムによって、プログラム実行中に情報を一時的に記憶するために使用されてもよい。更に、システムメモリ３０４は、多数のデジタルメディアコンテンツファイルを記憶するように構成されてもよい。
【００３３】
図３に示したように、システムメモリ３０４は、オペレーティングシステム３０６、アプリケーション３０８、及びブラウザアプリケーション３１０を含む。アプリケーション３０８は、演算デバイス３００内で実施されるか又はそれによって実行されるアプリケーションを含むことができ、演算デバイス３００のコンポーネント内に実装されるか若しくは含まれ、それによって動作可能であり、それによって実行され、及び／又は動作的／通信的に結合され得る。アプリケーション３０８は、演算デバイス３００のＣＰＵ（単数又は複数）３０２に特定の機能を実行させることができる命令を含むことができる。アプリケーション３０８は、ｆｏｒループ、ｗｈｉｌｅループ、ｉｆステートメント、ｄｏループなどのコンピュータプログラミングステートメントで表現されたアルゴリズムを含むことができる。アプリケーション３０８は、特定のプログラミング言語を使用して開発され得る。プログラミング言語の例としては、Ｊａｖａ（登録商標）、Ｊｉｎｉ（登録商標）、Ｃ，Ｃ＋＋、Ｏｂｊｅｃｔｉｖｅ  Ｃ、ｓｗｉｆｔ、Ｐｅｒｌ（登録商標）、Ｐｙｔｈｏｎ（登録商標）、ＰｈＰ、ＵＮＩＸ（登録商標）  Ｓｈｅｌｌ、Ｖｉｓｕａｌ  Ｂａｓｉｃ、及びＶｉｓｕａｌ  Ｂａｓｉｃ  Ｓｃｒｉｐｔが挙げられる。ブラウザアプリケーション３１０は、演算デバイス３００がリソース識別子を使用してデータを検索すること、及び／又は検索したデータをレンダリングさせることを可能にする論理構造を含む。ブラウザアプリケーション３１０は、１つ以上のウェブブラウザを含むことができる。ブラウザアプリケーション３１０は、例えば、マークアップ言語ドキュメント（例えば、ＨＴＭＬ５、ＸＭＬなど）及びスクリプト言語ドキュメント（例えば、ＪａｖａＳｃｒｉｐｔ（登録商標）など）などのウェブサイトコンテンツに一般に対応するドキュメントを処理するように構成されてもよい。アプリケーション３０８及びブラウザアプリケーション３１０は、オペレーティングシステム３０６と関連して実行することができる。すなわち、オペレーティングシステム３０６は、演算デバイス３００のＣＰＵ（単数又は複数）３０２及び他のハードウェアコンポーネントとのアプリケーションのインタラクションを容易にするように構成されてもよい。いくつかの実施例では、オペレーティングシステム３０６は、セットトップボックス、デジタルビデオレコーダ、テレビなどにインストールされるように設計されたオペレーティングシステムであってよい。更に、いくつかの実施例では、オペレーティングシステム３０６は、専用の演算デバイス及び／又はモバイル演算デバイス上にインストールされるように設計されたオペレーティングシステムであってよい。本明細書に記載された技術は、ソフトウェアアーキテクチャのいずれか及びすべての組み合わせを使用して動作するように構成されたデバイスによって利用され得るという点に留意すべきである。
【００３４】
システムインターフェース３１２は、演算デバイス３００のコンポーネント間で通信できるように構成されてもよい。一例では、システムインターフェース３１２は、あるピアデバイスから別のピアデバイス又は記憶媒体にデータを転送することを可能にする構造を含む。例えば、システムインターフェース３１２は、アクセラレーテッドグラフィックスポート（Accelerated Graphics Port、ＡＧＰ）ベースプロトコル、例えば、Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｓｐｅｃｉａｌ  Ｉｎｔｅｒｅｓｔ  Ｇｒｏｕｐによって管理されたＰＣＩ  Ｅｘｐｒｅｓｓ（登録商標）（ＰＣＩｅ）バス仕様などのペリフェラルコンポーネントインターコネクト（Peripheral Component Interconnect、ＰＣＩ）バスベースプロトコル、又はピアデバイスと相互接続するのに使用することができる任意の他の形態の構造（例えば、独自のバスプロトコル）に対応するチップセットを含むことができる。
【００３５】
前述したように、演算デバイス３００は、演算デバイス３００は、通信ネットワークからデータを受信し、そこからデジタルメディアコンテンツを抽出するように構成されている。抽出されたデジタルメディアコンテンツは、様々なパケットタイプでカプセル化されてもよい。ネットワークインターフェース３２４は、演算デバイス３００がローカルエリアネットワーク及び／又はワイドエリアネットワークを介してデータを送信及び受信できるように構成されてもよい。ネットワークインターフェース３２４は、Ｅｔｈｅｒｎｅｔ（登録商標）カードなどのネットワークインターフェースカード、光トランシーバ、無線周波数トランシーバ、又は情報を送信及び受信するように構成された任意の他のタイプのデバイスを含むことができる。ネットワークインターフェース３２４は、ネットワークで利用される物理層及びメディアアクセス制御（Media Access Control、ＭＡＣ）層に従って、物理的シグナリング、アドレッシング、及びチャネルアクセス制御を実行するように構成されてもよい。演算デバイス３００は、本明細書に記載された技術のいずれかに従って生成された信号を解析するように構成されてもよい。
【００３６】
音声デコーダ３１４は、音声パケットを受信及び処理するように構成されてもよい。例えば、音声デコーダ３１４は、音声コーデックの態様を実施するように構成されたハードウェア及びソフトウェアの組み合わせを含むことができる。すなわち、音声デコーダ３１４は、音声パケットを受信して、レンダリングのために音声出力システム３１６に音声データを提供するように構成されてもよい。音声データは、Ｄｏｌｂｙ及びＤｉｇｉｔａｌ  Ｔｈｅａｔｅｒ  Ｓｙｓｔｅｍｓによって開発されたものなどのマルチチャネルフォーマットを使用して、符号化されてもよい。音声データは、音声圧縮フォーマットを使用して符号化されてもよい。音声圧縮フォーマットの例としては、Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＭＰＥＧ）フォーマット、先進的音響符号化（Advanced Audio Coding、ＡＡＣ）フォーマット、ＤＴＳ−ＨＤフォーマット、及びドルビーデジタル（ＡＣ−３）フォーマットが挙げられる。音声出力システム３１６は、音声データをレンダリングするように構成されてもよい。例えば、音声出力システム３１６は、音声プロセッサ、デジタル／アナログ変換装置、増幅器、及びスピーカシステムを含むことができる。スピーカシステムは、ヘッドホン、統合ステレオスピーカシステム、マルチスピーカシステム、又はサラウンドサウンドシステムなどの様々なスピーカシステムのいずれかを含むことができる。
【００３７】
動画像デコーダ３１８は、動画像パケットを受信及び処理するように構成されてもよい。例えば、動画像デコーダ３１８は、動画像コーデックの態様を実施するように使用されたハードウェア及びソフトウェアの組み合わせを含むことができる。一例では、動画像デコーダ３１８は、ＩＴＵ−Ｔ  Ｈ．２６２又はＩＳＯ／ＩＥＣ  ＭＰＥＧ−２  Ｖｉｓｕａｌ、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｖｉｓｕａｌ、ＩＴＵ−Ｔ  Ｈ．２６４（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ａｄｖａｎｃｅｄ  ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＡＶＣ）としても知られている）、及びＨｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＨＥＶＣ）などの任意の数の動画像圧縮規格に従って符号化された動画像データを復号化するように構成されてもよい。表示システム３２０は、表示のために動画像データを検索及び処理するように構成されてもよい。例えば、表示システム３２０は、動画像デコーダ３１８から画素データを受信し、ビジュアルプレゼンテーションのためにデータを出力することができる。更に、表示システム３２０は、動画像データと関連するグラフィックス（例えば、グラフィカルユーザインターフェース）を出力するように構成されてもよい。表示システム３２０は、液晶ディスプレイ（liquid crystal display、LCD）、プラズマディスプレイ、有機発光ダイオード（organic light emitting diode、OLED）ディスプレイ、又は動画像データをユーザに提示することができる別のタイプのディスプレイデバイスなどの様々な表示デバイスのうちの１つを含むことができる。表示デバイスは、標準精細度コンテンツ、高精細度コンテンツ、又は超高精度コンテンツを表示するように構成されてもよい。
【００３８】
Ｉ／Ｏデバイス（単数又は複数）３２２は、演算デバイス３００の動作中に入力を受信し、出力を提供するように構成されてもよい。すなわち、Ｉ／Ｏデバイス（単数又は複数）３２２は、レンダリングされるマルチメディアコンテンツをユーザが選択できるようにする。入力は、例えば、押しボタン式リモートコントロール、タッチ感知スクリーンを含むデバイス、モーションベースの入力デバイス、音声ベースの入力デバイス、又はユーザ入力を受信するように構成された任意の他のタイプのデバイスなどの入力デバイスから生成され得る。Ｉ／Ｏデバイス（単数又は複数）３２２は、例えば、ユニバーサルシリアルバスプロトコル（Universal Serial Bus、ＵＳＢ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）などの規格化された通信プロトコル、又は例えば、独自の赤外線通信プロトコルなどの独自の通信プロトコルを使用して、演算デバイス３００に動作的に結合され得る。
【００３９】
図２を再度参照すると、ワイドエリアネットワーク２１０は、デジタルメディアコンテンツを配信できるように構成されたネットワークの一例である。ワイドエリアネットワーク２１０は、パケットベースのネットワークを含み、１つ以上の電気通信プロトコルの組み合わせに従って動作することができる。電気通信プロトコルは、専用の態様を含むことができ、及び／又は規格化された電気通信プロトコルを含むことができる。
規格化された電気通信プロトコルの例としては、汎欧州デジタル移動電話方式（Global System Mobile Communications、ＧＳＭ）規格、符号分割多元接続（code division multiple access、ＣＤＭＡ）規格、３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ（３ＧＰＰ）規格、欧州電気通信標準化機構（European Telecommunications Standards Institute、ＥＴＳＩ）規格、欧州規格（ＥＮ）、ＩＰ規格、ワイヤレスアプリケーションプロトコル（Wireless Application Protocol、ＷＡＰ）規格、及び例えば、ＩＥＥＥ  ８０２規格のうちの１つ以上（例えば、Ｗｉ−Ｆｉ）などのＩｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｅｎｇｉｎｅｅｒｓ（ＩＥＥＥ）規格が挙げられる。ワイドエリアネットワーク２１０は、無線通信メディア及び／又は有線通信メディアの任意の組み合わせを含むことができる。ワイドエリアネットワーク２１０は、同軸ケーブル、光ファイバケーブル、ツイストペアケーブル、イーサネット（登録商標）ケーブル、無線送信部及び受信部、ルータ、スイッチ、中継器、基地局、又は様々なデバイス及びサイト間の通信を容易にするために有用であり得る任意の他の機器を含むことができる。一例では、ワイドエリアネットワーク２１０は、一般に、インターネット及びそのサブネットワークに対応してもよい。
【００４０】
更に、ワイドエリアネットワーク２１０上は、ラジオ及びテレビサービスネットワークを含むことができ、公衆無線伝送ネットワーク、公衆若しくは加入に基づく衛星伝送ネットワーク、及び公衆若しくは加入に基づくケーブルネットワーク、並びに／又はオーバーザトップ（over the top）若しくはインターネットサービスプロバイダを含むことができる。ワイドエリアネットワーク２１０は、ラジオ及びテレビサービスネットワークと関連付けられた１つ以上の電気通信プロトコルの組み合わせに従って動作することができる。電気通信プロトコルは、専用の態様を含むことができ、及び／又は規格化された電気通信プロトコルを含むことができる。規格化された電気通信プロトコルの例としては、ＤＶＢ規格、ＡＴＳＣ規格、ＩＳＤＢ規格、ＤＴＭＢ規格、ＤＭＢ規格、ケーブルによるデータサービスインターフェース標準（Data Over Cable Service Interface Specification、ＤＯＣＳＩＳ）規格、ＨｂｂＴＶ規格、Ｗ３Ｃ規格、及びＵＰｎＰ規格が挙げられる。
【００４１】
図２を再度参照すると、コンテンツプロバイダサイト２０４Ａ〜２０４Ｎは、マルチメディアコンテンツを発信することができるサイトの例を表す。例えば、コンテンツプロバイダサイトは、マルチメディアファイル及び／又はストリームをメディア配信エンジン及び／又はデータベースに提供するように構成された１つ以上のスタジオコンテンツサーバを有するスタジオを含むことができる。データベース３０６は、例えばマルチメディアコンテンツ及びそれに関連するデータ、例えば、記述データ及び実行可能な対話型アプリケーションを含むデータを記憶するように構成された記憶デバイスを含むことができる。マルチメディアコンテンツと関連付けられたデータは、例えば、ハイパーテキストマークアップランゲージ（Hypertext Markup Language、ＨＴＭＬ）、ダイナミックＨＴＭＬ、ＸＭＬ、及びＪＳＯＮなどの定義されたデータフォーマットに従ってフォーマットすることができ、ＵＲＬ及びＵＲＩを含むことができる。
【００４２】
メディア配信エンジン２０８Ａ〜２０８Ｎは、ワイドエリアネットワーク２１０を介してデジタルメディアコンテンツを配信するように構成されてもよい。例えば、メディア配信エンジン２０８Ａ〜２０８Ｎは、１つ以上の放送局、ケーブルテレビプロバイダサイト、衛星テレビプロバイダサイト、インターネットベースのテレビプロバイダサイト、及び／又はいわゆるストリーミングメディアサービスサイトに含まれ得る。メディア配信エンジン２０８Ａ〜２０８Ｎは、例えば、マルチメディアコンテンツ、対話型アプリケーション及びメッセージを含むデータを受信し、ワイドエリアネットワーク２１０を通じて、演算デバイス２０２Ａ〜２０２Ｎにデータを配信するように構成されてもよい。
【００４３】
図４は、本開示の１つ以上の技術を実施できるメディア配信エンジンの例を示すブロック図である。メディア配信エンジン４００は、データを受信し、通信ネットワーク、例えば、ワイドエリアネットワーク２１０を介して配信するためのデータを表す信号を出力するように構成されてもよい。例えば、メディア配信エンジン４００は、デジタルメディアコンテンツを受信し、１つ以上のデータストリームを出力するように構成されてもよい。データストリームは、一般に、１つ以上のデータパケットのセットにカプセル化されたデータを指すことができる。図４に示したように、メディア配信エンジン４００は、中央処理装置（単数又は複数）４０２、システムメモリ４０４、システムインターフェース４１２、メディアプレゼンテーション記述生成部４１４、セグメント生成部４１６、トランスポート／ネットワークパケット生成部４１８、及びネットワークインターフェース４２０を含む。中央処理装置（単数又は複数）４０２、システムメモリ４０４、システムインターフェース４１２、メディアプレゼンテーション生成部４１４、セグメント生成部４１６、トランスポート／ネットワークパケット生成部４１８、及びネットワークインターフェース４２０の各々は、コンポーネント間通信のために（物理的、通信的、及び／又は動作的に）相互接続してもよく、１つ以上のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリートロジック、ソフトウェア、ハードウェア、ファームウェア、又はこれらの組み合わせなどの様々な好適な回路のいずれかとして実装することができる。メディア配信エンジン４００は、別個の機能ブロックを有するものとして図示されるが、このような図示は、説明を目的としており、メディア配信エンジン４００を特定のハードウェアアーキテクチャに限定しないという点に留意すべきである。メディア配信エンジン４００の機能は、ハードウェア実装、ファームウェア実装、及び／又はソフトウェア実装の任意の組み合わせを使用して実現することができる。
【００４４】
中央処理装置（単数又は複数）４０２、システムメモリ４０４、システムインターフェース４１２、及びネットワークインターフェース４２０の各々は、上述の中央処理装置（単数又は複数）３０２、システムメモリ３０４、システムインターフェース３１２、及びネットワークインターフェース３２４と同様であってもよい。ＣＰＵ（単数又は複数）４０２は、メディア配信エンジン４００において実行するための機能及び／又はプロセス命令を実施するように構成されてもよい。システムインターフェース４１２は、メディア配信エンジン４００のコンポーネント間で通信できるように構成されてもよい。ネットワークインターフェース４２０は、メディア配信エンジン４００がローカルエリアネットワーク及び／又はワイドエリアネットワークを介してデータを送信及び受信できるように構成されてもよい。システムメモリ４０４は、動作中にメディア配信エンジン４００によって使用され得る情報を記憶するように構成されてもよい。システムメモリ４０４は、コンポーネントカプセル化部４０２、トランスポート／ネットワークパケット生成部４０４、リンク層パケット生成部４０６、及びフレームビルダ、及び波形生成部４０８の各々内に含まれる個々のメモリ要素を含んでもよいという点に留意すべきである。例えば、システムメモリ４０４は、メディア配信エンジン４００のコンポーネントによる処理のためのデータを記憶するように構成された１つ以上のバッファ（例えば、先入れ先出し（First-in First-out、ＦＩＦＯ）バッファ）を含むことができる。
【００４５】
図４に示したように、システムメモリは、オペレーティングシステム４０６、メディアコンテンツ４０８、及びサーバアプリケーション４１０を含む。オペレーティングシステム４０６は、メディア配信エンジン４００のＣＰＵ（単数又は複数）４０２及び他のハードウェアコンポーネントとのアプリケーションのインタラクションを容易にするように構成されてもよい。メディアコンテンツ４０８は、メディアプレゼンテーション（例えば、動画像コンポーネント、音声コンポーネント、サブタイトルコンポーネントなど）を形成するデータを含むことができる。メディアプレゼンテーション生成部４１４は、１つ以上のコンポーネントを受信し、ＤＡＳＨに基づいてメディアプレゼンテーションを生成するように構成されてもよい。更に、メディアプレゼンテーション生成部４１４は、メディアプレゼンテーション記述フラグメントを生成するように構成されてもよい。セグメント生成部４１６は、メディアコンポーネントを受信し、メディアプレゼンテーションに含めるための１つ以上のセグメントを生成するように構成されてもよい。トランスポート／ネットワークパケット生成部４１８は、トランスポートパッケージを受信し、トランスポートパッケージを対応するトランスポート層パケット（例えば、ＵＤＰ、トランスポートコントロールプロトコル（ＴＣＰ）など）及びネットワーク層パケット（例えば、Ｉｐｖ４、Ｉｐｖ６、圧縮ＩＰパケットなど）にカプセル化するように構成されてもよい。
【００４６】
図４を再度参照すると、システムメモリ４０４は、サーバアプリケーション４１０を含む。前述したように、ＷｅｂＳｏｃｋｅｔプロトコルは、双方向ソケットの確立を通じて、論理クライアントと論理サーバとの間で相互通信を可能にする。サーバアプリケーション４１０は、メディア配信エンジン４００のＣＰＵ（単数又は複数）４０２にＷｅｂＳｏｃｋｅｔプロトコルと関連付けられた特定の機能を実行させることができる命令を含むことができる。図５は、本開示の１つ以上の技術による、通信フローの例を示す概念図である。図５は、全二重ＷｅｂＳｏｃｋｅｔセッションを介してＭＰＥＧ−ＤＡＳＨメディアプレゼンテーションを搬送するためのメッセージフローの例を示す。前述したように、Ｗ１６２３２においてプッシュディレクティブ及びプッシュ肯定応答をシグナリングするために定義されたメッセージは、理想的でない場合がある。演算デバイス３００及びメディア配信エンジン４００は、本明細書に記載された技術に従ってメッセージを交換するように構成されてもよい。
【００４７】
図５に示された実施例では、５０２において、ブラウザアプリケーション３１０は、ＭＰＤ要求をサーバアプリケーション４１０に送信する。いくつかの実施例では、ブラウザアプリケーション３１０は、クライアント、又はＨＴＴＰクライアント、又はＤＡＳＨクライアントと呼ばれることもある。表３を参照すると、Ｗ１６２３２は、表３の与えられた引数に対して規範的なＪＳＯＮスキーマを定義できない。図６Ａ〜図６Ｂは、メディアプレゼンテーションドキュメント要求メッセージのそれぞれの例示的なＪＳＯＮスキーマを示すコンピュータプログラミングリストである。一例では、ブラウザアプリケーション３１０は、図６Ａ〜図６Ｂに示された例示的なスキーマに基づいて、ＭＰＤ要求をサーバアプリケーション４１０に送信するように構成されてもよい。
【００４８】
図５を再度参照すると、５０４において、サーバアプリケーション４１０は、ＭＰＤ要求応答をブラウザアプリケーション３１０に送信する。表５を参照すると、Ｗ１６２３２は、表５の与えられた引数に対して規範的なＪＳＯＮスキーマを定義できない。更に、表５では、パラメータｓｔａｔｕｓは、Ｗ１６２３２における「Ｎｕｍｂｅｒ」型を含む。ＪＳＯＮデータ型「Ｎｕｍｂｅｒ」は、整数と浮動小数点数に対応する。ＨＴＴＰステータスコードに関して、浮動小数点数は必要としない。したがって、いくつかの実施例では、サーバアプリケーション４１０は、ＪＳＯＮデータ型「Ｉｎｔｅｇｅｒ」を使用するパラメータｓｔａｔｕｓを含む応答メッセージを送信するように構成されてもよい。この場合、ＪＳＯＮデータ型は、「Ｉｎｔｅｇｅｒ」又は「ｉｎｔｅｇｅｒ」と呼ばれていてもよいという点に留意すべきである。表５を再度参照すると、Ｗ１６２３２は、型が「ＭＰＤ」のパラメータとして「ｍｐｄ」を提供する。これは、どのＪＳＯＮデータ型が使用されるかを定義していないため、ＪＳＯＮ符号化されたパラメータとしてどのようにＭＰＤが符号化されるか完全には指定していない。一例では、パラメータ「ｍｐｄ」について、サーバアプリケーション４１０は、次の例示的な要件のうちの１つに基づく符号化と共に「ｓｔｒｉｎｇ」のＪＳＯＮデータ型を使用することができる。
サーバによって返されたメディアプレゼンテーション記述（ＭＰＤ）データは、発生した全てのラインフィード（０×０Ａ）が削除され、発生したすべてのダブルクォート（０×２２）がシングルクォート（０×２７）と置換され後に、ＪＳＯＮ文字列に含まれるとする。
又は
サーバによって返されたメディアプレゼンテーション記述（ＭＰＤ）データは、発生したすべてのラインフィード（０×０Ａ）が削除又はエスケープ符号化された後に、ＪＳＯＮ文字列に含まれるとする。
又は
サーバによって返されたメディアプレゼンテーション記述（ＭＰＤ）データは、エスケープ符号化後に、ＪＳＯＮ文字列に含まれるとする。
【００４９】
したがって、一例では、サーバアプリケーション４１０は、ＭＰＤ要求応答をブラウザアプリケーション３１０に送信することができ、ＭＰＤ要求応答のフォーマットは、表９で提供されるように定義される。
【表９】
2019536312.tif 000011
【００５０】
更に、図７Ａ〜図７Ｂは、メディアプレゼンテーションドキュメント要求応答メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。一例では、サーバアプリケーション４１０は、図７Ａ〜図７Ｂに示された例示的なスキーマに基づいて、ＭＰＤ要求応答をブラウザアプリケーション３１０に送信するように構成されてもよい。
【００５１】
図５を再度参照すると、５０６において、ブラウザアプリケーション３１０は、セグメント要求をサーバアプリケーション４１０に送信する。表４を参照すると、Ｗ１６２３２は、表４の与えられた引数に対して規範的なＪＳＯＮスキーマを定義できない。図８Ａ〜図８Ｂは、セグメント要求メッセージのそれぞれの例示的なＪＳＯＮスキーマを示すコンピュータプログラミングリストである。一例では、ブラウザアプリケーション３１０は、図８Ａ〜８Ｂに示された例示的なスキーマに基づいて、セグメント要求をサーバアプリケーション４１０に送信するように構成されてもよい。
【００５２】
図５を再度参照すると、５０８において、サーバアプリケーション４１０は、セグメント要求応答をブラウザアプリケーション３１０に送信する。表６を参照すると、Ｗ１６２３２は、型「Ｓｅｇｍｅｎｔ」のパラメータとして「ｓｅｇｍｅｎｔ」を含む。これは、どのＪＳＯＮデータ型が使用されるかを定義していないため、ＪＳＯＮ符号化されたパラメータとしてどのようにセグメントが符号化されるか完全には指定していない。一例では、サーバアプリケーション４１０は、セグメント要求応答を送信するように構成されてもよく、パラメータ「Ｓｅｇｍｅｎｔ」は、与えられた引数ではない。一例では、サーバアプリケーション４１０は、「ｐｕｓｈ＿ａｃｋ」、「ｈｅａｄｅｒｓ」、「ｓｔａｔｕｓ」を含むＪＳＯＮ符号化されたパラメータの後に、ＪＳＯＮ符号化なしでバイナリデータとしてＳｅｇｍｅｎｔデータを直接送信するように構成されてもよい。図９Ａ〜図９Ｂは、セグメント要求応答メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。図９Ａ〜図９Ｂに示したように、例示的なスキーマは、パラメータ「Ｓｅｇｍｅｎｔ」を含まない。図９Ａ〜図９Ｂに示された実施例の各々において、ｓｔａｔｕｓは、ｉｎｔｅｇｅｒデータ型を有することができるという点に留意すべきである。一例では、サーバアプリケーション４１０は、図９Ａ〜図９Ｂに示された例示的なスキーマに基づいて、セグメント要求応答をブラウザアプリケーション３１０に送信するように構成されてもよい。
【００５３】
別の例では、サーバアプリケーション４１０は、ＪＳＯＮとして「ｓｅｇｍｅｎｔ」パラメータを送信するように構成されてもよく、セグメントパラメータは、表１０で提供される記述に基づいてもよく、それで、表６の対応するエントリを置き換えてもよい。
【表１０】
2019536312.tif 000012
【００５４】
図９Ｃ〜図９Ｄは、セグメント要求応答メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。図９Ｃ〜図９Ｄに示したように、例示的なスキーマは、パラメータ「Ｓｅｇｍｅｎｔ」を含む。図９Ｃ〜図９Ｄに示された実施例の各々において、ｓｔａｔｕｓは、ｉｎｔｅｇｅｒデータ型を有することができるという点に留意すべきである。一例では、サーバアプリケーション４１０は、図９Ｃ〜図９Ｄに示された例示的なスキーマに基づいて、セグメント要求応答をブラウザアプリケーション３１０に送信するように構成されてもよい。一例では、図９Ｃ〜図９Ｄ中のスキーマは、表１０と共に使用することができる。図５を再度参照すると、ブラウザアプリケーション３１０がキャンセル要求をサーバアプリケーション４１０に送信すること（５１０）によって、又はサーバアプリケーション４１０がリソース変更通知をブラウザアプリケーションに送信すること（５１２）によって、セッションを終了することができる。表８を参照すると、Ｗ１６２３２は、表８の与えられた引数に対して規範的なＪＳＯＮスキーマを定義できない。図１０Ａ〜図１０Ｂは、キャンセル要求メッセージのそれぞれの例示的なＪＳＯＮスキーマを示すコンピュータプログラミングリストである。一例では、ブラウザアプリケーション３１０は、図１０Ａ〜図１０Ｂに示された例示的なスキーマに基づいて、キャンセル要求メッセージをサーバアプリケーション４１０に送信するように構成されてもよい。
【００５５】
表７を参照すると、Ｗ１６２３２は、表７の与えられた引数に対して規範的なＪＳＯＮスキーマを定義できない。図１１Ａ〜図１１Ｂは、リソース変更通知メッセージのそれぞれの例示的なスキーマを示すコンピュータプログラミングリストである。一例では、サーバアプリケーション４１０は、図１１Ａ〜図１１Ｂに示された例示的なスキーマに基づいて、キャンセル要求メッセージをブラウザアプリケーション３１０に送信するように構成されてもよい。表７に示したように、ｈｅａｄｅｒパラメータを含めることは、任意選択であってもよい。一例では、ｈｅａｄｅｒｓパラメータがｅｎｄ＿ｏｆ＿ｓｔｒｅａｍメッセージのインスタンスに含まれない場合、ＥＸＴ＿ＬＥＮＧＴＨは、ＤＡＳＨサブプロトコルフレームにおいて０と設定されるものとし（又はいくつかの実施例では、設定すべきであり）、ＥＸＴ＿ＬＥＮＧＴＨフィールドの後に空のＪＳＯＮパラメータ符号化は存在しないものとする。ｈｅａｄｅｒｓパラメータが存在しない場合、４バイト境界への追加の必要なパディングを伴う空のＪＳＯＮ文字列データを含むことは、帯域幅の無駄であり、不必要な処理を要求するという点に留意すべきである。このようにして、演算デバイス３００及びメディア配信エンジン４００は、本明細書に記載された技術に従ってメッセージを交換するように構成されてもよい。
【００５６】
前述したように、Ｗ１６２３２において、ＡＢＮＦ形式におけるＰｕｓｈＴｙｐｅのフォーマットは、次のとおりである：
ＰＵＳＨ＿ＴＹＰＥ＝ＰＵＳＨ＿ＴＹＰＥ＿ＮＡＭＥ［ＯＷＳ”；”ＯＷＳ  ＰＵＳＨ＿ＰＡＲＡＭＳ］ＰＵＳＨ＿ＴＹＰＥ＿ＮＡＭＥ＝ＤＱＵＯＴＥ＜ＵＲＮ＞ＤＱＵＯＴＥ
ＰＵＳＨ＿ＰＡＲＡＭＳ＝ＰＵＳＨ＿ＰＡＲＡＭ＊（ＯＷＳ”；”ＯＷＳ  ＰＵＳＨ＿ＰＡＲＡＭ）
ＰＵＳＨ＿ＰＡＲＡＭ＝１＊ＶＣＨＡＲ
【００５７】
場合によっては、ＰＵＳＨ＿ＰＡＲＡＭは、ＪＳＯＮ予約文字と競合する場合がある。例えば、ＶＣＨＡＲは、文字ＤＱＵＯＴＥ（”）を含む。ＪＳＯＮは、予約文字としてＤＱＵＯＴＥを使用する。場合によっては、ＰｕｓｈＤｉｒｅｃｔｉｖｅは、ＪＳＯＮプロパティとしてシグナリングされるが、複雑な解析が必要となる場合がある。一例では、ＪＳＯＮ符号化を阻害しないように、ＰＵＳＨ＿ＰＡＲＡＭの文法は、いくつかの簡単な変更で定義できる。一例では、ブラウザアプリケーション４１０及びサーバアプリケーション５１０は、ＰＵＳＨ＿ＰＡＲＡＭがＤＱＵＯＴＥを含む場合、ＤＱＵＯＴＥが先行する「＼」（すなわち、％ｘ５Ｃ）でエスケープされているものとするように構成されてもよい。
【００５８】
前述のダブルクォートを扱う別の例では、次の変更をＷ１６２３２に加えることができる：
セクション「３．２  Ｃｏｎｖｅｎｔｉｏｎ」に以下を追加する：ＰＰＣＨＡＲ＝％ｘ２１／％ｘ２３−７Ｅ
発生したＶＣＨＡＲをＰＰＣＨＡＲで置換する（セクション６．１．２  ＰｕｓｈＴｙｐｅ、６．１．５  ＵＲＬＬｉｓｔ、６．１．６  ＵＲＬＴｅｍｐｌａｔｅ、及び６．１．７  ＦａｓｔＳｔａｒｔＰａｒａｍｓ）。
６．１．５（ＵＲＬ  Ｔｅｍｐｌａｔｅ）では、２つのＤＱＵＯＴＥを’（シングルクォート、すなわち、％ｘ２７）に変更する。また、表２（Ｖａｌｉｄ  ａｔｔｒｉｂｕｔｅｓ  ｆｏｒ  ＦａｓｔＳｔａｒｔＰａｒａｍｓ）では、発生したＤＱＵＯＴＥを‘（シングルクォート、すなわち、％ｘ２７）に、及び’’を’（シングルクォート、すなわち、％ｘ２７）に変更する。
上述の変更は、ダブルクォート文字の代わりにシングルクォートを使用する。このため、ＰＰＣＨＡＲは、ＤＱＵＯＴＥ文字（％ｘ２２）を除外するように定義されている。
【００５９】
Ｗ１６２３２において、下記のサブプロトコル識別子は、ＷｅｂＳｏｃｋｅｔサブプロトコルに使用されるという点に留意すべきである。
サブプロトコル識別子：「ｍｐｅｇ−ｄａｓｈ」
【００６０】
いくつかの実施例では、ブラウザ４１０及びサーバアプリケーション５１０は、サブプロトコル識別子にバージョン及び／又は年を含むことによって将来の拡張性を提供するように構成されてもよい。一例では、タグベースのサブプロトコル識別子は、次のように定義されてもよい。
サブプロトコル識別子：「ｔａｇ：ｍｐｅｇ．ｃｈｉａｒｉｇｌｉｏｎｅ．ｏｒｇ−ｄａｓｈ，２０１６：２３００９−６」
一例では、ＵＲＮベースのサブプロトコル識別子は、次のように定義されてもよい。
サブプロトコル識別子：「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：２０１６」
又は
サブプロトコル識別子：「ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：２０１６：２３００９−６」
一例では、サブプロトコル識別子及びサブプロトコル一般名は、次のように定義されてもよい。
サブプロトコル識別子：「２０１６．ｆｄｈ．ｄａｓｈ．ｍｐｅｇ．ｃｈｉａｒｉｇｌｉｏｎｅ．ｏｒｇ」
サブプロトコル一般名：「ＭＰＥＧ−ＤＡＳＨ−ＦＤＨ−２３００９−６」
【００６１】
このようにして、演算デバイス３００及びメディア配信エンジン４００は、本明細書に記載された技術に従ってメッセージを交換するように構成されてもよい。
【００６２】
１つ以上の例では、記載された機能は、ハードウェア、ソフトウェア、ファームウェア、又はこれらの任意の組み合わせで実装することができる。ソフトウェアで実装される場合に、この機能は、コンピュータ可読媒体上の１つ以上の命令又はコードとして記憶するか又は伝送され、ハードウェアベースの処理部によって実行することができる。コンピュータ可読媒体は、例えば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む、データ記憶媒体又は通信媒体などの有形の媒体に対応する、コンピュータ可読記憶媒体を含むことができる。このようにして、コンピュータ可読媒体は、一般に、（１）非一時的な有形のコンピュータ可読記憶媒体、又は（２）信号又は搬送波などの通信媒体に対応することができる。データ記憶媒体は、本開示中に記載された技術の導入のための命令、コード、及び／又はデータ構造を検索するために、１つ以上のコンピュータ又は１つ以上のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含むことができる。
【００６３】
一例として、非限定的に、このようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、又は他の光学ディスク記憶装置、磁気ディスク記憶装置、他の磁気記憶装置、フラッシュメモリ、又は任意の他の媒体、すなわち命令又はデータ構造の形式で所望のプログラムコードを記憶するために使用可能であり、かつコンピュータによりアクセス可能な任意の他の媒体を含むことができる。また、任意の接続は、コンピュータ可読媒体と適切に呼ばれる。例えば、命令がウェブサイト、サーバ、又は他のリモートソースから、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者線（digital subscriber line、ＤＳＬ）、あるいは赤外線、無線及びマイクロ波などの無線技術を使用して伝送される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、あるいは赤外線、無線及びマイクロ波などの無線技術は、媒体の定義に含まれる。しかし、コンピュータ可読媒体及びデータ記憶媒体は、接続、搬送波、信号、又は他の一過性媒体を含まないが、代わりに非一時的な有形記憶媒体を対象としていることを理解すべきである。本発明で使用する場合、ディスク（disk）及びディスク（disc）は、コンパクトディスク（Compact Disc、ＣＤ）、レーザーディスク（laser disc）、光学ディスク（optical disc）、デジタル多用途ディスク（Digital Versatile Disc、ＤＶＤ）、フロッピーディスク（floppy disk）及びブルーレイ（登録商標）ディスク（Blu-ray（登録商標）disc）を含み、ディスク（disk）は通常データを磁気的に再生し、ディスク（disc）はレーザを用いてデータを光学的に再生する。上記の組み合わせもまた、コンピュータ可読媒体の範囲内に含まれなければならない。
【００６４】
命令は、１つ以上のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又は他の同等の集積又はディスクリートロジック回路などの１つ以上のプロセッサによって実行することができる。したがって、本発明で使用する場合、用語「プロセッサ」は、本明細書に記載された技術の実施に好適な前述の構造又は任意の他の構造のいずれかを指すことができる。加えて、いくつかの態様において、本明細書に記載の機能は、符号化及び復号化するように構成された、又は複合コーデックに組み込まれた専用のハードウェアモジュール及び／又はソフトウェアモジュール内に設けられ得る。また、この技術は、１つ以上の回路又は論理素子中に完全に実装することができる。
【００６５】
本開示の技術は、無線ハンドセット、集積回路（integrated circuit、ＩＣ）、又はＩＣのセット（例えば、チップセット）を含む多種多様なデバイス又は装置に実装することができる。様々なコンポーネント、モジュール、又はユニットは、開示された技術を実行するように構成されたデバイスの機能的な態様を強調するために本開示中に記載されているが、異なるハードウェアユニットによる実現は必ずしも必要ではない。むしろ、前述したように、様々なユニットは、コーデックハードウェアユニットと組み合わせてもよく、又は好適なソフトウェア及び／又はファームウェアと共に、前述の１つ以上のプロセッサを含む、相互動作ハードウェアユニットの集合によって提供することができる。
【００６６】
更に、上述の各実装形態において使用された基地局デバイス及び端末デバイス（動画像デコーダ及び動画像エンコーダ）の各機能ブロックや各種の機能は、一般的には集積回路又は複数の集積回路である回路によって実装又は実行することができる。本明細書に記載の機能を実行するように設計された回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け若しくは汎用アプリケーション集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）若しくは他のプログラマブルロジックデバイス、ディスクリートゲート若しくはトランジスタロジック、若しくは個々のハードウェアコンポーネント、又はそれらの組み合わせを備えていてもよい。汎用プロセッサは、マイクロプロセッサでもよく、あるいは、プロセッサは、従来のプロセッサ、コントローラ、マイクロコントローラ、又はステートマシンもよい。上述した汎用プロセッサ又は各回路は、デジタル回路で構成されても、又はアナログ回路で構成されてもよい。更に、半導体技術の進歩により現時点での集積回路に置き換わる集積回路化技術が現れれば、この技術による集積回路もまた使用可能となる。
【００６７】
様々な実施例について説明した。これら及び他の実施例は、以下の特許請求の範囲内である。
【００６８】
本出願は、２０１６年１０月１３日に出願された米国仮特許出願第６２／４０８，００８号の関連出願であり、この仮出願に基づく優先権を主張し、参照により本明細書にその内容全体が組み込まれる。
【図１】
2019536312.tif 000013
【図２】
2019536312.tif 000014
【図３】
2019536312.tif 000015
【図４】
2019536312.tif 000016
【図５】
2019536312.tif 000017
【図６Ａ】
2019536312.tif 000018
【図６Ｂ】
2019536312.tif 000019
【図７Ａ】
2019536312.tif 000020
【図７Ｂ】
2019536312.tif 000021
【図８Ａ】
2019536312.tif 000022
【図８Ｂ】
2019536312.tif 000023
【図９Ａ】
2019536312.tif 000024
【図９Ｂ】
2019536312.tif 000025
【図９Ｃ】
2019536312.tif 000026
【図９Ｄ】
2019536312.tif 000027
【図１０Ａ】
2019536312.tif 000028
【図１０Ｂ】
2019536312.tif 000029
【図１１Ａ】
2019536312.tif 000030
【図１１Ｂ】
2019536312.tif 000031
【国際調査報告】
2019536312.tif 000032
2019536312.tif 000033
2019536312.tif 000034