(57)【要約】【課題】  ＤＡＳＨベースの通信との関連においてデータストリーミングを強化する。【解決手段】  サーバは、クライアントとの間で共有された情報に基づいて、クライアントへプッシュすべき１つ以上のメディアデータセグメントを識別し、該データをクライアントへプッシュする意図があることを通知する。サーバがクライアントからキャンセルリクエストを受信すると、前記識別されたデータのクライアントへのプッシュをキャンセルする。【選択図】  図１ｅ
2020047303.tif 000002
【特許請求の範囲】
【請求項１】
サーバによるクライアントへのメディアデータの提供方法であって、
前記サーバにおいて、前記サーバとクライアントとの間で共有された情報に基づいて、前記クライアントへプッシュすべき１つ以上のメディアデータセグメントを識別する識別工程と、
前記サーバによって、前記クライアントに対し、前記サーバが前記共有された情報に従ったデータのプッシュの意図があることを通知する通知工程と、
前記サーバにおいて、前記クライアントからのキャンセルリクエストの受信に応答して、前記識別工程において識別されたデータの前記クライアントへのプッシュをキャンセルするキャンセル工程と、
を有することを特徴とする提供方法。
【請求項２】
前記通知工程における通知は、前記クライアントへ送信される確認応答メッセージであることを特徴とする請求項１記載の提供方法。
【請求項３】
前記通知工程における通知は、ＨＴＴＰ／２によって定義されたＰＵＳＨ＿ＰＲＯＭＩＳＥフレームであることを特徴とする請求項１記載の提供方法。
【請求項４】
前記通知工程における通知は、ウェブソケットによって定義されたメッセージであることを特徴とする請求項１記載の提供方法。
【請求項５】
前記識別工程は、前記クライアントからの所定のリクエストを受信したことに応じて実行されることを特徴とする請求項１乃至４の何れか一項に記載の提供方法。
【請求項６】
前記所定のリクエストは、ＭＰＤ（ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ）を要求するリクエストであることを特徴とする請求項５記載の提供方法。
【請求項７】
前記所定のリクエストは、所定の期間のメディアデータに対応するメディアセグメントを要求するリクエストであることを特徴とする請求項５記載の提供方法。
【請求項８】
前記識別工程によって識別された一つ以上のメディアデータセグメントは、前記通知工程において前記クライアントに通知されることを特徴とする請求項１乃至７の何れか一項に記載の提供方法。
【請求項９】
前記キャンセルリクエストは、ＨＴＴＰ／２によって定義されたＲＳＴ  ＳＴＲＥＡＭフレームであることを特徴とする請求項１乃至８の何れか一項に記載の提供方法。
【請求項１０】
前記キャンセルリクエストは、前記識別工程において識別されたデータをプッシュするために確立されたストリームの識別情報を含むことを特徴とする請求項１乃至９の何れか一項に記載の提供方法。
【請求項１１】
クライアントによるサーバからのメディアデータの受信方法であって、
前記サーバからクライアントへプッシュすべきデータを決定するための情報を、前記サーバとクライアントとの間で共有する共有工程と、
前記クライアントにおいて、前記サーバが前記共有された情報に従ったデータのプッシュの意図があることを示す通知を受信する受信工程と、
前記クライアントにおいて、前記サーバからクライアントへのデータのプッシュをキャンセルするかどうか判定する判定工程と、
前記判定工程における判定結果に従って、前記データのプッシュのキャンセルを要求するキャンセルリクエストを、前記クライアントからサーバへ送信する送信工程と、
を有することを特徴とする受信方法。
【請求項１２】
前記受信工程によって受信される通知は、確認応答メッセージであることを特徴とする請求項１１記載の受信方法。
【請求項１３】
前記受信工程によって受信される通知は、ＨＴＴＰ／２によって定義されたＰＵＳＨ＿ＰＲＯＭＩＳＥフレームであることを特徴とする請求項１１記載の受信方法。
【請求項１４】
一つ以上のメディアデータセグメントが前記受信工程によって受信される通知によって通知されることを特徴とする請求項１１記載の受信方法。
【請求項１５】
前記キャンセルリクエストは、ＨＴＴＰ／２によって定義されたＲＳＴ＿ＳＴＲＥＡＭフレームであることを特徴とする請求項１１乃至１４の何れか一項に記載の受信方法。
【請求項１６】
クライアントへのメディアデータを提供するサーバであって、
前記サーバとクライアントとの間で共有された情報に基づいて、前記クライアントへプッシュすべき１つ以上のメディアデータセグメントを識別する識別手段と、
前記クライアントに対し、前記サーバが前記共有された情報に従ったデータのプッシュの意図があることを通知する通知手段と、
前記クライアントからのキャンセルリクエストの受信に応答して、前記識別手段によって識別されたデータの前記クライアントへのプッシュをキャンセルするキャンセル手段と、
を有することを特徴とするサーバ。
【請求項１７】
前記通知手段による通知は、前記クライアントへ送信される確認応答メッセージであることを特徴とする請求項１６記載のサーバ。
【請求項１８】
前記通知手段による通知は、ＨＴＴＰ／２によって定義されたＰＵＳＨ＿ＰＲＯＭＩＳＥフレームであることを特徴とする請求項１６記載のサーバ。
【請求項１９】
サーバからメディアデータを受信するクライアントであって、
前記サーバからクライアントへプッシュすべきデータを決定するための情報を、前記サーバとクライアントとの間で共有する共有手段と、
前記サーバが前記共有された情報に従ったデータのプッシュの意図があることを示す通知を受信する受信手段と、
前記サーバからクライアントへのデータのプッシュをキャンセルするかどうか判定する判定手段と、
前記判定手段による判定結果に従って、前記データのプッシュのキャンセルを要求するキャンセルリクエストを、前記サーバへ送信する送信手段と、
を有することを特徴とするクライアント。
【請求項２０】
前記受信手段によって受信される通知は、確認応答メッセージであることを特徴とする請求項１９記載のクライアント。
【請求項２１】
前記受信手段によって受信される通知は、ＨＴＴＰ／２によって定義されたＰＵＳＨ＿ＰＲＯＭＩＳＥフレームであることを特徴とする請求項１９記載のクライアント。
【請求項２２】
コンピュータに、請求項１６乃至２１の何れか一項に記載の各手段を実行させるためのプログラム。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本出願は、英国特許出願第１３１２５４７．１号および第１３１２５６１．２号（ともに２０１３年７月１２日）、並びに第１４１０５４０．７号（２０１４年６月１２日）からの優先権を主張し、それらは参考文献としてすべて本明細書に援用される。
【技術分野】
【０００２】
本発明は、ＨＴＴＰ通信ネットワーク上のデータストリーミングに関する。
【０００３】
特に、本発明はネットワーク制約を満たすための適応型データストリーミングに関する。本発明は、ＤＡＳＨネットワークにおけるアプリケーションを有してもよい。
【０００４】
ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ（動的適応型ＨＴＴＰストリーミング）の頭文字）は、ＨＴＴＰ上のメディアコンテンツストリーミング（通常はオーディオ／ビデオコンテンツ）を可能にする通信規格である。ＤＡＳＨによれば、メディアプレゼンテーションは、「メディアプレゼンテーション記述」ファイル（以下において、ＭＰＤ）と呼ばれるＸＭＬファイルとして記載される。ＭＰＤファイルは、クライアント装置がメディアコンテンツの配信を要求し制御することを可能にする情報を、クライアント装置に提供する。
【背景技術】
【０００５】
ＨＴＴＰメディアストリーミングの一般的原理は、図３に示される。適応型ＨＴＴＰメディアストリーミングのための新たなプロトコルおよび標準のほとんどは、この原理に基づく。
【０００６】
メディアサーバ３００は、クライアント３１０に対してデータをストリーミングする。メディアサーバは、メディアプレゼンテーションを保存する。例えば、メディアプレゼンテーション３０１は、オーディオデータおよびビデオデータを含む。オーディオおよびビデオは、同じファイル内でインターリーブされてもよい。メディアプレゼンテーションが構築される方法は、図４ａを参照しながら以下に記載される。メディアプレゼンテーションは、独立してアドレス指定されてダウンロードされることができるＭＰ４セグメントなどの、小さな独立した連続する時間セグメント３０２ａ、３０２ｂおよび３０２ｃに一時的に分割される。これらの時間セグメントの各々のためのメディアコンテンツのダウンロードアドレス（ＨＴＴＰ  ＵＲＬ）は、クライアントに対してサーバによって設定される。オーディオ／ビデオメディアコンテンツの各時間セグメントは、１つのＨＴＴＰアドレスに関連づけられている。
【０００７】
メディアサーバは、また、メディアコンテンツ特性（例えば、メディアのタイプ：オーディオ、ビデオ、オーディオビデオ、テキストなど）、コード化形式（例えば、ビットレート、タイミング情報など）、時間メディアセグメントと関連するＵＲＬとのリストを含むメディアプレゼンテーションのコンテンツを記述する（図５を参照ながら以下に記載される）マニフェストファイルドキュメント３０４を保存する。または、ドキュメントは、時間メディアセグメント及び関連するＵＲＬとの明示的なリストを再構築可能にするテンプレート情報を含む。このドキュメントは、エクステンシブルマークアップランゲージ（ＸＭＬ）を用いて記載されてもよい。
【０００８】
マニフェストファイルは、クライアントに対して送信される。ステップ３０５の間にマニフェストファイルの受信をすると、クライアントには、メディアコンテンツの時間セグメントとＨＴＴＰアドレスとの間の関連づけが通知される。また、マニフェストファイルは、メディアプレゼンテーションのコンテンツに関する情報（本例にではインターリーブされたオーディオ／ビデオ）をクライアントに提供する。情報は、解像度、ビットレートなどを含んでもよい。
【０００９】
受信された情報に基づいて、クライアントのＨＴＴＰクライアントモジュール３１１は、マニフェストファイル内に記載されたメディアコンテンツの時間セグメントのダウンロードのためにＨＴＴＰ要求３０６を発行することができる。サーバのＨＴＴＰ応答３０７は、要求された時間セグメントを伝達する。ＨＴＴＰクライアントモジュール３１１は、応答から時間メディアセグメントを抽出し、メディアエンジン３１２の入力バッファ３０７に対してそれらを提供する。最終的に、メディアセグメントは、ステップ３０８および３０９のそれぞれの間に復号されて表示されることができる。
【００１０】
メディアエンジン３１２は、次の時間セグメントが適切な時期に発行されるように要求するために、ＤＡＳＨ制御エンジン３１３と情報のやりとりをする。次のセグメントは、マニフェストファイルから識別される。要求が発行される時期は、受信バッファ３０７が満杯であるか否かに依存する。ＤＡＳＨ制御エンジン３１３は、バッファが過負荷になるかまたは完全に空になるのを防ぐようにバッファを制御する。
【００１１】
メディアプレゼンテーションおよびマニフェストファイルの生成を、図４ａを参照して説明する。ステップ４００および４０１の間に、オーディオデータおよびビデオデータが取得される。次に、オーディオデータは、４０２の間に圧縮される。例えば、ＭＰ３規格を用いることができる。また、ビデオデータは、ステップ４０３の間に並行して圧縮される。ＭＰＥＧ４、ＭＰＥＧ／ＡＶＣ、ＳＶＣ、ＨＥＶＣ、またはスケーラブルＨＥＶＣなどのビデオ圧縮アルゴリズムを用いることができる。オーディオデータおよびビデオデータの圧縮が一旦実行されれば、オーディオビデオエレメンタリーストリーム４０４およびビデオエレメンタリーストリーム４０５は、利用可能になる。エレメンタリストリームは、ステップ４０６の間に、グローバルメディアプレゼンテーションにカプセル化される。例えば、ＩＳＯ  ＢＭＦＦ規格（またはＩＳＯ  ＢＭＦＦ規格をＡＶＣ、ＳＶＣ、ＨＥＶＣ、ＨＥＶＣのスケーラブル拡張などに拡張する）は、符号化されたオーディオエレメンタリーストリームおよびビデオエレメンタリーストリームのコンテンツをグローバルメディアプレゼンテーションとして記述するために使用することができる。それによって取得されたカプセル化されたメディアプレゼンテーション４０７は、ステップ４０８の間に、ＸＭＬマニフェストファイル４０９を生成するために用いられる。ビデオデータ４０１およびオーディオデータ４００のいくつかのリプレゼンテーションは、取得され、圧縮され、カプセル化され、メディアプレゼンテーション４０７内に記載することができる。
【００１２】
図４ｂに示されたＭＰＥＧ／ＤＡＳＨストリーミングプロトコルの特定のケースに関して、マニフェストファイルは、「メディアプレゼンテーション記述」（または「ＭＰＤ」ファイル）と呼ばれる。ファイルのルート要素は、プロファイルまたはスキーマのようなＤＡＳＨ情報を加えたすべてのプレゼンテーションに適用する属性を含むＭＰＤ要素である。メディアプレゼンテーションは、Ｐｅｒｉｏｄ要素によって表される時間的期間に分割される。ＭＰＤファイル４１０は、各時間的期間に関連するデータをすべて含む。この情報を受信することによって、クライアントは、各々の期間ごとのコンテンツを認識する。Ｐｅｒｉｏｄ４１１ごとに、ＡｄａｐｔａｔｉｏｎＳｅｔ（アダプテーションセット）要素が定義される。
【００１３】
可能な構成は、プレゼンテーション内に含まれるメディアタイプ当たり１つ以上のＡｄａｐｔａｔｉｏｎＳｅｔを有することである。ビデオに関連するＡｄａｐｔａｔｉｏｎＳｅｔ４１２は、サーバにおいて利用可能な符号化されたビデオの異なる可能的なリプレゼンテーションに関する情報を含む。各リプレゼンテーションは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素内に記述される。例えば、第１のリプレゼンテーションは、６４０×４８０の空間解像度で符号化され、且つ５００ｋビット／秒のビットレートで圧縮されたビデオになり得る。第２のリプレゼンテーションは、同じビデオになり得るが、２５０ｋビット／秒のビットレートで圧縮され得る。
【００１４】
クライアントが各ビデオに関するＨＴＴＰアドレスを知っている場合、各ビデオは、その後、ＨＴＴＰ要求によってダウンロードすることができる。各リプレゼンテーションのコンテンツとＨＴＴＰアドレスとの間の関連づけは、付加的なレベルの記述：時間セグメントを用いることによって行われる。各ビデオリプレゼンテーションは、時間セグメント４１３（通常は数秒）に分割される。各時間セグメントは、ＨＴＴＰアドレス（ＵＲＬまたは１バイトレンジのＵＲＬ）を介してアクセス可能なサーバに保存されたコンテンツを備える。いくつかの要素は、ＭＰＤファイル：ＳｅｇｍｅｎｔＬｉｓｔ（セグメントリスト）、ＳｅｇｍｅｎｔＢａｓｅ（セグメントベース）またはＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ（セグメントテンプレート）内に時間セグメントを記述するために用いることができる。
【００１５】
さらに、特定のセグメント：イニシャライゼーションセグメントが利用可能である。イニシャライゼーションセグメントは、（ＩＳＯ  ＢＭＦＦまたはその拡張を用いてビデオがカプセル化されているならば）カプセル化されたビデオストリームを記述するＭＰ４イニシャライゼーション情報を含む。例えば、それは、クライアントがビデオに関する復号アルゴリズムをインスタンス化するのを支援する。
【００１６】
イニシャライゼーションセグメントおよびメディアセグメントのＨＴＴＰアドレスは、ＭＰＤファイル内に示される。
【００１７】
図５に、例示的なＭＰＤファイルが示される。２つのメディアが、図示されたＭＰＤファイル内に記述される。第１のものは英語のオーディオストリームであり、第２のものはビデオストリームである。英語のオーディオストリームは、ＡｄａｐｔａｔｉｏｎＳｅｔタグ５００を用いて導入される。２つの代替的リプレゼンテーションが、このオーディオストリームのために利用可能である。
【００１８】
・第１のリプレゼンテーション５０１は、６４０００ビット／秒のビットレートでＭＰ４にカプセル化されたエレメンタリオーディオストリームである。この（ＭＰ４構文解析後の）エレメンタリストリームを取り扱うために用いられるコーデックは、値「ｍｐ４ａ．０ｘ４０」を有する属性コーデックによって規格内に定義されている。それは、セグメント階層内のＢａｓｅＵＲＬ（ベースＵＲＬ）要素：相対的なＵＲＩである＜ＢａｓｅＵＲＬ＞７６５７４１２３４８．ｍｐ４＜／ＢａｓｅＵＲＬ＞の連結によって形成されたアドレスにおける要求を介してアクセス可能である。「ｈｔｔｐ：／／ｃｄｎ１．ｅｘａｍｐｌｅ．ｃｏｍ／」によって、または「ｈｔｔｐ：／／ｃｄｎ２．ｅｘａｍｐｌｅ．ｃｏｍ／」によってＭＰＤ要素内のトップレベルにおいて定義される〈ＢａｓｅＵＲＬ〉（２つのサーバが同じコンテンツのストリーミングのために利用可能である）は、絶対ＵＲＩである。そして、クライアントは、その要求から、アドレス「ｈｔｔｐ：／／ｃｄｎ１．ｅｘａｍｐｌｅ．ｃｏｍ／７６５７４１２３４８．ｍｐ４」またはアドレス「ｈｔｔｐ：／／ｃｄｎ２．ｅｘａｍｐｌｅ．ｃｏｍ／７６５７４１２３４８．ｍｐ４」に対して、英語のオーディオストリームを要求することができる。
【００１９】
・第２のリプレゼンテーション５０２は、３２０００ビット／秒のビットレートでＭＰ４にカプセル化されたエレメンタリオーディオストリームである。第１のリプレゼンテーション５０１と同じような説明を行うことができ、クライアント装置は、したがって、以下のアドレスのいずれか１つにおける要求によって、この第２のリプレゼンテーション５０２を要求することができる。
【００２０】
「ｈｔｔｐ：／／ｃｄｎ１．ｅｘａｍｐｌｅ．ｃｏｍ／３４６３６４６３４６．ｍｐ４」または
「ｈｔｔｐ：／／ｃｄｎ２．ｅｘａｍｐｌｅ．ｃｏｍ／３４６３６４６３４６．ｍｐ４」。
【００２１】
ビデオに関連するアダプテーションセット５０３は、６つのリプレゼンテーションを含む。これらのリプレゼンテーションは、異なる空間解像度（３２０×２４０、６４０×４８０、１２８０×７２０）、および異なるビットレート（２５６０００〜２０４８０００ビット／秒）のビデオを含む。これらのリプレゼンテーションの各々に対して、それぞれのＵＲＬは、ＢａｓｅＵＲＬ要素を通じて関連づけられる。そのため、クライアントは、推定された帯域幅、スクリーン解像度などの異なる基準にしたがって同じビデオのこれらの代替リプレゼンテーションの間で選択することができる。（図５において、時間セグメントへのＲｅｐｒｅｓｅｎｔａｔｉｏｎの分解は、明瞭にするために図示されていない、ということに留意されたい。）
図５ａは、ＤＡＳＨクライアントの標準的挙動（ｓｔａｎｄａｒｄ  ｂｅｈａｖｉｏｒ）を示す。図５ｂは、図４ａに示された方法において用いられる、例示的なマニフェストファイル（記述ファイルまたはＭＰＤ）のツリー表現を示す。
【００２２】
ストリーミングセッションを開始する場合、ＤＡＳＨクライアントは、マニフェストファイルを要求することによって開始する（ステップ５５０）。サーバの応答を待ってマニフェストファイルを受信した後（ステップ５５１）、クライアントは、マニフェストファイルを解析し（ステップ５５２）、その環境に適したＡｄａｐｔａｔｉｏｎＳｅｔｓのセットＡＳｉｊを選択し（ステップ５５３）、それから、例えば、その帯域幅、復号化、およびレンダリング機能に適したＭＰＤ内のＲｅｐｒｅｓｅｎｔａｔｉｏｎを各ＡｄａｐｔａｔｉｏｎＳｅｔ  ＡＳｉｊ内で選択する（ステップ５５４）。
【００２３】
そして、ＤＡＳＨクライアントは、メディア復号器のためのイニシャライゼーション情報を始めとして、要求するセグメントのリストを予め構築することができる。このイニシャライゼーションセグメントは、それが複数のリプレゼンテーション、アダプテーションセットおよび期間に共通になり得るか、または各Ｒｅｐｒｅｓｅｎｔａｔｉｏｎに特有になり得るか、または第１のメディアセグメント内にも含まれ得るので、このＭＰＤ（ステップ５５５）内で、識別されなければならない。
【００２４】
そして、クライアントは、イニシャライゼーションセグメントを要求する（ステップ５５６）。一旦イニシャライゼーションセグメントが受信されると（ステップ５５７）、復号器が起動される（ステップ５５８）。
【００２５】
そして、クライアントはセグメント単位で第１のメディアデータを要求し（ステップ５６０）、復号化を実際に開始して表示する（ステップ５６３）前に、（ステップ５５９の条件のために）最小データ量をバッファする。ＭＰＤダウンロードと最初に表示されたフレームとの間のこれら複数の要求／応答は、ストリーミングセッションにおける起動遅延（ｓｔａｒｔｕｐ  ｄｅｌａｙ）を招く。これらの初期ステップの後、ＤＡＳＨストリーミングセッションは、標準的方法で継続する、すなわち、ＤＡＳＨクライアントは、メディアセグメントを順々に適応させてリクエストする。
【００２６】
現在のＤＡＳＨバージョンは、マニフェストファイル内部の関心領域の記述を提供しない。いくつかのアプローチが、このような記述のために、提案されてきた。
【００２７】
特に、メディアコンテンツのコンポーネントは、ＳｕｂＲｅｐｒｅｓｅｎｔａｔｉｏｎ（サブリプレゼンテーション）要素を用いて記載することができる。これらの要素は、リプレゼンテーション内に埋め込まれる１つまたはいくつかのコンポーネントのプロパティを記述する。図６に、タイルトラック（ｔｉｌｅ  ｔｒａｃｋｓ）をビデオのコンポーネントとして記述するＤＡＳＨマニフェストファイルの例が示される。簡明に且つおよび明瞭にするために、１つのＰｅｒｉｏｄ６００のみを示す。しかしながら、後続の期間要素は、同じ方式で編成されるだろう。部分６０１において、第１のアダプテーションセット要素は、スケーラブルビデオのベース層を記述するために用いられる。例えば、ビデオは、ＳＶＣまたはスケーラブルなＨＥＶＣにしたがって符号化される。部分６０２において、第２のアダプテーションセットはスケーラブルビデオの最高解像度層を記述するために用いられる。非スケーラブルビデオに対して、第２のアダプテーションセット６０２のみが、ベース層に依存することなく（すなわちｄｅｐｅｎｄｅｎｃｙｌｄ属性）、存在するだろう。この第２のアダプテーションセット６０２において、単一のリプレゼンテーション６０３、すなわち表示することができるビデオに対応するもの、が記述される。そのリプレゼンテーションは、クライアント要求のためのそれぞれのＵＲＬとともにセグメント６１０のリストとして記載される。
【００２８】
このように、リプレゼンテーションは、「Ｒ１」（ｄｅｐｅｎｄｅｎｃｙｌｄ属性）によって識別された別のリプレゼンテーション、実際には第１のアダプテーションセット６０１からのベース層リプレゼンテーション、に依存する。依存性は、エンハンスメント層のために現在のセグメントを得る前にベース層のための現在のセグメントを最初に要求することをストリーミングクライアントに強制する。このように参照されるトラックがクライアントによって自動的にロードされるので、これをタイルトラックに対する依存性を表現するためには用いることができない。メディアプレゼンテーションの間にユーザにとって興味のあるタイル（ｔｉｌｅｓ）をいつでも選択することはユーザ次第であるので、これは回避されるべきである。そのため、複合トラックとタイルトラックとの間の依存性を示すために、ＳｕｂＲｅｐｒｅｓｅｎｔａｔｉｏｎ要素が用いられる。表示可能なビデオは、サブリプレゼンテーション６０４〜６０８のリストとして記載される。各サブリプレゼンテーションは、カプセル化されたＭＰ４ファイル内のトラックを実際に表わす。このように、複合トラック６０８に対して１つのタイルを加えた（本例においては４つのタイル）サブリプレゼンテーション当たり１つのサブリプレゼンテーションがある。各サブリプレゼンテーションは、タイルトラック６１４、６１５、６１６、および６１７、または複合トラック６１８に対応するか否かを示すために、コンテンツコンポーネント要素６１４〜６１８によって記述される。ＤＡＳＨ／ＭＰＤにおいて利用可能なロール記述子型は、特定のスキームによるタイリングのために用いられる。ロール記述子は、また、フルフレームビデオ内のタイルの位置を示す。例えば、コンポーネント６１４は、ビデオの左上（先頭行および先頭列の１：１）に位置するタイルを記述する。タイルの寸法、幅および高さは、ＭＰＤによって可能になるようなサブリプレゼンテーションの属性として指定される。帯域幅情報も、また、その帯域幅にしたがって、タイルの数およびタイルの選択の決定においてＤＡＳＨクライアントを支援するためにここに設けることができる。複合トラックに関して、ダウンロードの終わりに、復号することができるビデオストリームを構築することができることが義務的であるので、タイルトラックとは異なる方法で、信号で送らなければならない。その目的のために、２つの要素が記述に加えられる。第１に、関連コンテンツコンポーネント６１８内の記述子は、それがすべてのコンポーネントの中の主要なコンポーネントであることを示す。第２に、対応するデータが要求されるべきであることをクライアントに対して示すために、サブリプレゼンテーション内に、新たな「ｒｅｑｕｉｒｅｄ（必須）」属性が加えられる。複合トラック、またはタイルトラックの１つ以上に対する要求はすべて、セグメントリスト６１０内に提供されるＵＲＬから計算される（１時間間隔当たり１つ）。例では、ＭＰＤの先頭において「ＢａｓｅＵＲＬ」と組み合わされた「ＵＲＬ＿Ｘ」は、ＨＴＴＰ  ＧＥＴ要求を実行するためにクライアントが用いることができる完全なＵＲＬを提供する。この要求により、クライアントは、複合トラックのため���データと、すべてのタイルトラックのためのすべてのデータとを得るだろう。要求の代わりに、伝送を最適化するために、クライアントは、ｉｎｄｅｘ＿ｒａｎｇｅ属性６２０からの利用可能なデータを用いて、セグメントインデックス情報（通常は、当業者により周知のＩＳＯ  ＢＭＦＦ内の「ｓｉｄｘ」情報および／または「ｓｓｉｘ」）を第１に要求することができる。このインデックス情報は、コンポーネントの各々のためのバイト単位の範囲を決定することを可能にする。そして、ＤＡＳＨクライアントは、適切なバイト単位の範囲で、（要求された複合トラックを含む）選択されたトラックと同数のＨＴＴＰ  ＧＥＴ要求を送信することができる。
【００２９】
ストリーミングセッションを開始するとき、ＤＡＳＨクライアントは、マニフェストファイルを要求する。一旦受信されれば、クライアントは、マニフェストファイルを解析し、その環境に適した１セットのＡｄａｐｔａｔｉｏｎＳｅｔを選択する。次に、クライアントは、各ＡｄａｐｔａｔｉｏｎＳｅｔ内部のＭＰＤにおいて、その帯域幅と互換性をもつＲｅｐｒｅｓｅｎｔａｔｉｏｎ、復号化およびレンダリング機能を選択する。次に、それは、メディア復号器のためのイニシャライゼーション情報を始めとして、要求されるセグメントのリストを予め構築する。イニシャライゼーション情報が復号器によって受信されると、それらはイニシャライズされ、クライアントは、第１のメディアデータを要求し、ディスプレイを実際に開始する前に最小データ量をバッファする。
【００３０】
これらの複数の要求／応答は、ストリーミングセッションの起動における遅延を招くかもしれない。サービスプロバイダにとってのリスクは、ビデオを見始めることなくサービスを離れるクライアント見ることである。クライアントによって実行される第１のメディアデータチャンクのための初期のＨＴＴＰ要求とメディアデータチャンクが実際に再生し始める時間との間の時間を、スタートアップ遅れとよぶことが一般的である。それは、ネットワークラウンドトリップ時間だけでなく、メディアセグメントのサイズにも依存する。
【００３１】
サーバプッシュは、ウェブリソースのローディング時間を減少させるために有用な機能である。このようなサーバは、図１ａ〜図１ｅを参照しながら論じる。
【００３２】
図１ｂでは、ＨＴＴＰ／２交換（ＨＴＴＰ／２  ｅｘｃｈａｎｇｅｓ）において、要求は、必要とされるリソース：（図１ａに示されるように）リソースＲ１〜Ｒ４およびサブリソースＡ〜Ｉごとに送信されなければならない、ということが図示される。しかしながら、サーバによるプッシュ機能を用いるとき、図１ｃに図示されるように、要求の数は、要素Ｒ１〜Ｒ４に制限される。要素Ａ〜Ｉは、図１ａに示される依存性に基づいてサーバによってクライアントに対して「プッシュされ」、それによって、不必要な関連する要求が生じる。
【００３３】
このように、サーバがプッシュ機能を用いる場合、図１ｂおよび図１ｃに図示されるように、そのサブリソースと共にリソースをロードするために必要なＨＴＴＰラウンドトリップ（要求＋応答）の数が減少される。これは、モバイルネットワークなどの高待ち時間のネットワークにとって、とりわけ興味深い。
【００３４】
ＨＴＴＰは、ウェブリソース、通常はウェブページ、を送信するために用いられるプロトコルである。ＨＴＴＰは、クライアントとサーバとを暗に含む。
【００３５】
・クライアントは、サーバに対して要求を送信する。
【００３６】
・サーバは、クライアントの要求に対して、ウェブリソースのリプレゼンテーションを含む応答により返答する。
【００３７】
要求および応答は、様々な部分、特にＨＴＴＰヘッダ、を含むメッセージである。ＨＴＴＰヘッダは、値と共に名称を備える。例えば「Ｈｏｓｔ：  ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ」は「Ｈｏｓｔ（ホスト）」ヘッダであり、その値は「ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ」である。それは、問い合わされたリソースのホストを示すために用いられる（例えばＨＴＴＰを記述するウィキペディアページは、ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＨＴＴＰにおいて利用可能である）。ＨＴＴＰヘッダは、クライアント要求およびサーバ応答上に出現する。
【００３８】
ＨＴＴＰ／２は、ストリームを通じて要求／応答を交換することを可能にする。ストリームは、ＨＴＴＰ要求および応答ごとにＨＴＴＰ／２接続の内部で生成される。フレームは、要求および応答のコンテンツおよびヘッダを伝達するために、ストリーム内で交換される。
【００３９】
ＨＴＴＰ／２は、以下のような、個別の意味をもつフレームの制限されたセットを定義する。
・ＨＥＡＤＥＲＳ：ＨＴＴＰヘッダの伝送のために提供される
・ＤＡＴＡ：ＨＴＴＰメッセージコンテンツの伝送のために提供される
・ＰＵＳＨ＿ＰＲＯＭＩＳＥ：プッシュされたコンテンツのアナウンスのために提供される
・ＰＲＩＯＲＩＴＹ：ストリームのプライオリティを設定するために提供される
・ＷＩＮＤＯＷ  ＵＰＤＡＴＥ：制御フローウィンドウの値を更新するために提供される・ＳＥＴＴＩＮＧＳ：設定パラメータを伝達するために提供される
・ＣＯＮＴＩＮＵＡＴＩＯＮ：ヘッダブロックフラグメントのシーケンスを継続するために提供される
・ＲＳＴ  ＳＴＲＥＡＭ：ストリームの終了またはキャンセルのために提供される
サーバによるプッシュは、サーバがクライアントに対して自発的なウェブリソースリプレゼンテーションを送信することを可能にするために、ＨＴＴＰ／２に導入された。ウェブページなどのウェブリソースは、一般的には、それ自体が他のリソースへのリンクを含んでいる、他のリソースに対するリンクを含む。完全にウェブページを表示するために、リンクされ、サブリンクされたすべてリソースは、一般的には、クライアントによって検索される必要がある。この増分ディスカバリは特に高待ち時間ネットワーク（モバイルネットワーク）上の、ウェブページの低速表示をもたらすであろう。
【００４０】
所定のウェブページに対する要求を受信するとき、サーバは、他のどのリソースが要求されたリソースの完全な処理のために必要とされるのかを知っているであろう。要求されたリソースおよびリンクされたリソースを同時に送信することによって、サーバは、ウェブページのロード時間を減少させることを可能にする。このように、プッシュ機能を用いて、サーバは、所定のリソースが要求されたときに、追加リソースリプレゼンテーションを送信してもよい。
【００４１】
図１ｅのフローチャートを参照して、プッシュ機能を実行するサーバの例示的なオペレーションモードを記述する。
【００４２】
ステップ１００の間、サーバは、初期要求を受信する。次に、サーバは、ステップ１０１の間に応答の一部としてプッシュするリソースを識別し、ステップ１０２の間にコンテンツ応答を送信し始める。並行して、サーバは、ステップ１０３の間にクライアントに対してプッシュプロミスメッセージを送信する。これらのメッセージは、例えば図１ａに示される依存性に基づいて、サーバがプッシュすることを意図している他のリソースを識別する。これらのメッセージは、どのプッシュされたリソースが送信されることになるのかをクライアントに予め知らせるために送信される。特に、これは、同時にプッシュされた、またはプッシュされようとしている、リソースに対して、クライアントが要求を送信する、というリスクを低減する。このリスクをさらに低減するために、サーバは、プッシュプロミス内に記述されるリソースを参照する応答のあらゆる部分を送信する前に、プッシュプロミスメッセージを送信するべきである。これは、また、クライアントがそれらのリソースを望まないならば、クライアントがプロミスされたリソース（ｐｒｏｍｉｓｅｄ  ｒｅｓｏｕｒｃｅｓ）のプッシュのキャンセルを要求することを可能にする。次に、サーバは、ステップ１０４の間に、応答およびすべてのプロミスされたリソースを送信する。プロセスは、ステップ１０５の間に終了する。
【００４３】
図１ｄのフローチャートは、クライアント側の処理を示す。
【００４４】
クライアントがサーバから取り出すリソースを識別すると、対応するデータが既にそのキャッシュメモリ内にあるか否かを、ステップ１０６の間にまずチェックする。リソースが既にキャッシュメモリ内にある場合（はい（Ｙｅｓ））、ステップ１０７の間に、そこから取り出される。キャッシュされたデータは、先の要求から取りだされたデータ、またはサーバによって予めプッシュされたデータのいずれかであろう。それがキャッシュメモリ内になかった場合（いいえ（Ｎｏ））、クライアントは、ステップ１０８の間に、要求を送信し、サーバの応答を待つ。サーバからのフレームを受信すると、クライアントは、フレームがプッシュプロミスに対応するか否かを、ステップ１０９の間にチェックする。データフレームがプッシュプロミスに対応するならば（はい（Ｙｅｓ））、ステップ１１０の間、クライアントは、プッシュプロミスを処理する。クライアントは、プッシュされるリソースを識別する。クライアントがリソースを受信したくなければ、クライアントは、エラーメッセージをサーバに対して送信してもよく、そうすれば、サーバは、そのリソースをプッシュしない。そうでなければ、クライアントは、対応するプッシュコンテンツを受信するまでプッシュプロミスを保存する。サーバがそれをプッシュしている間に、クライアントがプロミスされたリソースを要求しないように、プッシュプロミスが用いられる。データフレームがプッシュプロミスに対応しない場合（いいえ（Ｎｏ））、ステップ１１１の間に、フレームがプッシュデータに関連するデータフレームであるか否かがチェックされる。それがプッシュデータに関する場合（はい（Ｙｅｓ））、クライアントは、ステップ１１２の間に、プッシュされたデータを処理する。プッシュされたデータは、クライアントのキャッシュ内に保存される。フレームがプッシュデータに関するデータフレームではない場合（いいえ（Ｎｏ））、ステップ１１３の間に、サーバから受信された応答にそれが対応するか否かがチェックされる。フレームがサーバからの応答に対応する場合（はい（Ｙｅｓ））、応答は、ステップ１１４の間に処理される（例えば、アプリケーションに対して送信される）。そうでなければ（いいえ（Ｎｏ））、フレームが応答の終了を識別するか否か（はい（Ｙｅｓ））が、ステップ１１５の間にチェックされる。この場合、処理は、ステップ１１６の間に終了する。そうでなければ、処理は、ステップ１０９に戻る。
【００４５】
このように、クライアントが応答およびプロミスされたリソースを受信する、ということが思われる。そのため、取りだされたウェブページを表示するブラウザなどのアプリケーションによって応答が用いられる間に、プロミスされたリソースは、一般的には、クライアントのキャッシュ内に保存される。クライアントアプリケーションがプッシュされたリソースの１つを要求するとき、リソースは、いかなるネットワーク遅延も引き起こさずに、クライアントのキャッシュから直ちに取りだされる。
【００４６】
キャッシュ内のプッシュされたリソースの保存は、キャッシュ制御指示を用いて制御される。キャッシュ制御指示は、また、応答の制御のために用いられる。これらの指示は、特に、プロキシに対して適用可能であり、プッシュされた若しくはプッシュされない任意のリソースは、プロキシ若しくはクライアントのみによって保存されてもよい。
【００４７】
図１ａは、それらの関連性とともにサーバによって所有された１セットのリソースのグラフである。リソースのセットは、以下のように関連し合う。すなわち、Ｒ１、Ｒ２、Ｒ３、およびＲ４は、クライアントによって適切に処理されるために一緒にダウンロードされる必要のあるリソースである。さらに、サブリソースＡ〜Ｈが定義される。これらのサブリソースは、１つ、２つ、または３つのリソースに関連する。例えば、Ａは、Ｒ１に対してリンクされ、Ｃは、Ｒ１、Ｒ２、およびＲ４に対してリンクされる。
【００４８】
既に上述した図１ｂは、サーバＰＵＳＨ機能を用いないＨＴＴＰ交換を示しており、クライアントは、Ｒ１を要求し、次にＲ２、Ａ、Ｂ、Ｃ、およびＤを発見し、それらを要求する。それらを受信した後、クライアントは、Ｒ３、Ｒ４、Ｆ、およびＧを要求する。最終的に、クライアントは、ＨおよびＩのサブリソースを要求する。これは、リソースの全体のセットを検索するために４つのラウンドトリップを必要とする。
【００４９】
既に上述した図１ｃは、サーバによって直接的に接続されるサブリソースをプッシュする機能を用いたＨＴＴＰ交換を示す。Ｒ１を要求した後、サーバは、Ｒ１を送信し、Ａ、Ｂ、Ｃ、およびＤをプッシュする。クライアントは、Ｒ２を識別し、それを要求する。サーバは、Ｒ２を送信し、ＦおよびＧをプッシュする。最終的に、クライアントは、Ｒ３、Ｒ４を識別し、これらのリソースを要求する。サーバは、Ｒ３、Ｒ４を送信し、ＨおよびＩをプッシュする。これは、リソースの全体のセットを取りだすために３つのラウンドトリップを必要とする。
【００５０】
１セットのリソース、通常はウェブページおよびそのサブリソース、のローディング時間を減少させるために、ＨＴＴＰ／２は、複数の要求および応答のプライオリティを並列に交換することを可能にする。図２に図示されるように、ウェブページは、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ、画像などのような、いくつかのリソースのダウンロードを要求してもよい。初期のＨＴＴＰ交換２００の間に、クライアントは、ＨＴＭＬファイルを検索する。このＨＴＭＬファイルは、２つのＪａｖａ（登録商標）Ｓｃｒｉｐｔファイル（ＪＳ１、ＪＳ２）、２つの画像（ＩＭＧ１、ＩＭＧ２）、１つのＣＳＳファイル、および１つのＨＴＭＬファイルに対するリンクを含む。交換２０１の間に、クライアントは、各ファイルに対する要求を送信する。図２の交換２０１において与えられる順序は、ウェブページの順序に基づき、クライアントは、リンクが見つかるとすぐに、要求を送信する。そして、サーバは、ＪＳ１、ＣＳＳ、ＩＭＧ１、ＨＴＭＬ、ＩＭＧ２、およびＪＳ２に対する要求を受信し、その順序に従ってこれらの要求を処理する。そして、クライアントは、その順序で、これらのリソースを取りだす。
【００５１】
ＨＴＴＰプライオリティは、どの要求がより重要であり且つ他の要求より早く処理されるべきであるかを、クライアントに明示することを可能にする。特定のプライオリティの使用を、交換２０２に示す。Ｊａｖａ（登録商標）Ｓｃｒｉｐｔファイルは、最も高いプライオリティを割り当てられる。ＣＳＳおよびＨＴＭＬファイルは、中プライオリティを割り当てられ、画像は、低プライオリティを割り当てられる。このアプローチにより、ブロッキングファイル、または他のファイルより早く他のリソースに対する参照を含むことができるファイルを受信することができる。これを受けて、交換２０２に記述されるように、サーバは、まずＪａｖａ（登録商標）Ｓｃｒｉｐｔファイル、その後ＣＳＳおよびＨＴＭＬファイル、最後には画像を、送信することを試みることが期待される。サーバは、クライアントプライオリティに従うようには義務付けられていない。
【００５２】
プライオリティに加えて、ＨＴＴＰ／２は、同時に交換されるデータ量を制御することができる、ということを提供する。クライアントおよびサーバは、接続ベース当たりおよびストリームベース当たりのバッファリングすることができるデータ量を指定することができる。これは、ＴＣＰ輻輳制御と同様であり、利用可能なバッファサイズを指定するウィンドウサイズは、所定の値にイニシャライズされ、エミッタがデータを送信するたびに、ウィンドウサイズは減少し、エミッタは、ウィンドウサイズが０より下にならないようにデータの送信を停止しなければならない。受信器は、データを受信し、データがバッファから受信され取り出されたということを通知するメッセージを送信し、メッセージは、バッファから取り出されたデータ量を含んでおり、そして、ウィンドウサイズが所定の値から増加され、エミッタは、データを送信することを再開することができる。
【００５３】
上記を考慮すると、クライアントは実行しているアプリケーションの目的のためにコンテンツのベストのリプレゼンテーションを一般的には選択することができるので、ＤＡＳＨは、クライアントがストリーミングをリードするという前提に基づくように思われる。例えば、クライアントは、そのフォームファクタおよびスクリーン解像度に基づいて高解像度または小解像度のコンテンツを要求するべきかどうかを認識していてもよい。
【発明の概要】
【発明が解決しようとする課題】
【００５４】
サーバベースのストリーミングは、通常は、ＲＴＰを用いて実行される。ＤＡＳＨとは対照的に、ＲＴＰは、ＨＴＴＰを用いず、ウェブインフラストラクチャ、特にプロキシ、キャッシュから直接的に恩恵を受けることができない。ウェブソケットベースのメディアストリーミングは、同じ短所を持つ。ＨＴＴＰ／１．１では、サーバがクライアント要求に対して一般的には答えることしかできないので、サーバベースのストリーミングは、容易に実行することができない。ＨＴＴＰ／２では、特にプッシュ機能の導入では、ＤＡＳＨベースのサーバは、ストリーミングを通すことができる。このように、サーバは、ユーザエクスペリエンスを最適化するために、ストリーミングしているコンテンツの特性のサーバの知識を用いることができる。例えば、サーバは、広告は付加的な限定的な量の帯域幅を利用するのでアドバーティスメントをＨＤとしてプッシュすることを除けばフィルムをＳＤとして（制限された帯域幅のために）プッシュするかもしれない。別の例は、低解像度ビデオでの高速起動を実行し始め、且つ一旦帯域幅が十分に推定されれば可能な限りベストのリプレゼンテーションに切り替える、サーバのケースである。
【００５５】
サーバがストリーミングを通すことを可能にするために、１つのアプローチは、サーバに好ましくはデータ（特にＤＡＳＨデータ）をプッシュさせることである。そして、クライアントは、ビデオを表示するのに利用することができるいかなるデータも用いる。サーバは、通常は、一度にいくつかのセグメントのプッシュをアナウンスする。そして、サーバは、並行してまたは連続的にセグメントを送信する。
【００５６】
発生する問題は、クライアントとサーバはプロミスされたデータが望まれる時間に送られ、受信されるかどうか、わからないかもしれないことである：クライアントは、ビデオセグメントが、いつ、どの順序で送信されることになるのかをわからないかもしれない。
【００５７】
また、サーバによってプッシュまたはアナウンスされた、プロミスされたデータは、クライアントのニーズにミスマッチするかもしれず、それにより、サーバエンドにおいて特にリソースを無駄にすることになる。
【００５８】
このように、特に、ＤＡＳＨベースの通信との関連においてデータストリーミングを強化する必要性がある。
【課題を解決するための手段】
【００５９】
上記の課題を解決するために、本発明のメディアデータの提供方法は、例えば、以下の構成を有する。すなわち、サーバによるクライアントへのメディアデータの提供方法であって、前記サーバにおいて、前記サーバとクライアントとの間で共有された情報に基づいて、前記クライアントへプッシュすべき１つ以上のメディアデータセグメントを識別する識別工程と、前記サーバによって、前記クライアントに対し、前記サーバが前記共有された情報に従ったデータのプッシュの意図があることを通知する通知工程と、前記サーバにおいて、前記クライアントからのキャンセルリクエストの受信に応答して、前記識別工程において識別されたデータの前記クライアントへのプッシュをキャンセルするキャンセル工程と、を有する。
【００６０】
本発明の他の機能および効果は、図１〜図６に加えて、添付された以下の図面を参照しながら、非限定的な好ましい実施形態の以下の記述から明らかになる。
【図面の簡単な説明】
【００６１】
【図１ａ】サーバによってプッシュされる要素の依存性を図示する。
【図１ｂ】プッシュ機能ＨＴＴＰ／２交換の例を図示する。
【図１ｃ】プッシュ機能を用いたＨＴＴＰ交換の例を図示する。
【図１ｄ】クライアント側の処理のフローチャートを図示する。
【図１ｅ】サーバ側の処理のフローチャートを図示する。
【図２】サーバ・クライアント間のＨＴＴＰ／２交換の例を図示する。
【図３】ＨＴＴＰメディアストリーミングの概略的原理を図示する。
【図４ａ】メディアプレゼンテーションおよびマニフェストファイルの生成例を図示する。
【図４ｂ】マニフェストファイル例を図示する。
【図５】ＭＰＤファイル例を図示する。
【図５ａ】ＤＡＳＨクライアントの標準的挙動例を図示する。
【図５ｂ】マニフェストファイルのツリー表現例を図示する。
【図６】ＤＡＳＨマニフェストファイル例を図示する
【図７ａ】実施形態にかかる、順序付けされたメディアセグメントを図示する。
【図７ｂ】実施形態にかかる、順序付けされたメディアセグメントを図示する。
【図８】実施形態にかかる、サーバによって実行される例示的なステップのフローチャートである。
【図９】実施形態にかかる、クライアントによって実行される例示的なステップのフローチャートである。
【図１０】実施形態にかかる、プロキシによって実行される例示的なステップのフローチャートである。
【図１１】実施形態にかかる帯域幅測定を図示する。
【図１２】実施形態にかかるビデオ再生のイニシャライゼーションを図示する。
【図１３】実施形態にかかる装置の概略図である。
【図１４ａ】クライアント側における本発明の一般的なステップを、フローチャートを用いて図示する。
【図１４ｂ】サーバ側における本発明の一般的なステップを、フローチャートを用いて図示する。
【図１５ａ】明示的アプローチに基づいて、クライアント側において共有されるプッシュポリシーを決定するステップを、フローチャートを用いて図示する。
【図１５ｂ】明示的アプローチが用いられるときに、サーバ側においてプッシュポリシーを決定するステップを、フローチャートを用いて図示する。
【図１６】サーバによって適用されるプッシュポリシーを指定するためにＰｕｓｈＰｏｌｉｃｙノードが用いられるＭＰＤドキュメントを示す。
【図１７】共有されたプッシュポリシー「ＰｕｓｈＰｏｌｉｃｙ」にしたがってプッシュされる準備ができている、いくつかのセグメントを識別してマークするステップを、フローチャート用いて図示する。
【図１８ａ】ＨＴＴＰ「プッシュポリシー」ヘッダ内で送信されるプッシュポリシーによるサーバとクライアントとの間の通信の例を図示する。
【図１８ｂ】プッシュポリシーを変更するクライアントの要求と同じ例を図示する。
【図１９】メディアプレゼンテーション記述（ＭＰＤ）ファイルの例を図示する。
【図２０】アナウンスメッセージをマージする、実施形態によるサーバ側における処理のステップを、フローチャートを用いて図示する。
【図２１】プッシュポリシーを宣言するためにＨＴＴＰヘッダを用いる場合のサーバ側における処理のステップを、フローチャートを用いて図示する。
【図２２】プッシュポリシーを宣言して共有するためにＨＴＴＰ要求を用いる場合のクライアント側における処理のステップを、フローチャートを用いて図示する。
【図２３】ドキュメントの階層レベルにおいてサーバによって適用されるプッシュポリシーを指定するためにＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ要素が用いられるＭＰＤドキュメントを示す。
【図２４】ＸＰａｔｈベースのプッシュポリシーのために例として用いられるＭＰＤドキュメントを示す。
【図２５】プッシュポリシーを適用する前の、例えばウェブページ内のプライオリティツリー内の要素の順序付けを図示する。
【図２６】本発明の実施形態による、ＤＡＳＨ高速起動を取得するために、サーバによって、およびクライアント装置によって、それぞれ実施された例示的な方法を示す。
【図２７】ＤＡＳＨ高速起動のためのサーバによって実施される例示的な方法を記述する。
【図２８】ＤＡＳＨ高速起動のためのクライアント装置によって実施された可能な方法を記述する。
【発明を実施するための形態】
【００６２】
以下において、本発明の実施形態は、ＨＴＴＰ２．０プロトコルを実施するＤＡＳＨに基づくネットワークとの関連で記述される。ストリーミングされるデータは、例えばビデオデータである。本発明の実施形態は、ＤＡＳＨネットワークに限定されない。
【００６３】
クライアント装置に対してデータをストリーミングする通信ネットワークのサーバ装置は、送信されるデータ要素に対するクライアントからの明示的リクエストを伴わずに、クライアントに対してデータ要素を送信することができることによる、プッシュ機能を実施する。
【００６４】
サーバおよびクライアントは、プッシュプロミスを決定し、且つ対応するデータを実際に送信するように、サーバを駆動するプッシュポリシーを共有してもよい。この共有により、クライアントは、そのようなプッシュをキャンセルするために、いくつかの無用データのプッシュを予期することができる。ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、送信される前にキャンセルされてもよいので、これは、ネットワーク使用と同様に、サーバの処理も減少させることになる。
【００６５】
具体的なの実施形態において、サーバは、明確に要求されていないデータ要素の送信をアナウンスする、そのプッシュプロミスにおいて、データ要素を送信するように意図するサーバの順序に関係する順序付け情報を示すことができる。データ要素の順序は、プライオリティ値、例えばＨＴＴＰ／２によるプライオリティ値、を用いて定義されてもよい。
【００６６】
プッシュプロミスを受信すると、クライアント装置は、サーバによって意図された送信の順序を予め決定することができ、それによって、クライアントは、自身の所望の順序と一致しなかった場合に、提案された順序付けに対応できる。例えば、クライアント装置は、プライオリティ値を更新し、更新されたプライオリティ値をサーバに対して送信することができる。サーバは、したがって、クライアントのニーズと適切に一致させるために、新たなプライオリティ値に基づいて送信順序付けを変更することができる。サーバは、将来のデータ送信を考慮して、更新されたプライオリティを用いることができる。
【００６７】
実施形態によれば、クライアントは、サーバに対するデータ要素の送信の全面的な順序付けまたは部分的な順序付けを要求しても良い。
【００６８】
図７ａを参照して、全面的な順序付けを説明する。クライアントは、ステップ７００の間に、メディアプレゼンテーション記述（以降、ＭＰＤ）をサーバに対して要求する。サーバは、ステップ７０１の間に、クライアントに対して返送するＭＰＤを取得し、プッシュするべき対応するデータ要素を識別する。図７ａの例において、サーバは、「データ１．１」、「データ１．２」および「データ１．３」をプッシュするデータ要素として識別する。これらの要素は、例えばデータセグメントである。要素「データＸ．１」は、データＸのためのベース層を表現し、要素「データＸ．２」は、データＸのためのエンハンスメント層を表現し、「データＸ．３」は、データＸのための付加的なエンハンスメント層を表現する。サーバは、データ要素のための具体的な送信の順序を定義する。サーバは、来たるプッシュデータ要素のアナウンスのためにクライアントに対して送信される、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームに、それぞれのプライオリティ値を関連づける。そして、サーバは、ステップ７０２の間に、関連するプライオリティおよびＭＰＤにより、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム「Ｐ１．１」、「Ｐ１．２」および「Ｐ１．３」を送信する。次に、ＭＰＤおよびプッシュプロミスを送信した直後、ステップ７０３の間に、サーバは、クライアントに対して、定義された送信順序における「データ１．１」、「データ１．２」および「データ１．３」に続くセグメントである、「データ１．１」要素に対応するデータフレームと要素「データ２．１」、「データ２．２」および「データ２．３」にそれぞれ対応するＰＵＳＨ＿ＰＲＯＭＩＳＥメッセージ「Ｐ２．１」、「Ｐ２．２」および「Ｐ２．３」とを送信する。データフレームの受信およびステップ７０３のプッシュプロミスと並行して、クライアントは、ＭＰＤおよび「Ｐ１．１」、「Ｐ１．２」および「Ｐ１．３」ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの受信後に、エンハンスメント層「データ１．２」は付加的なエンハンスメント層「データ１．３」に比較して低いプライオリティである、と判断する。したがって、クライアントは、ステップ７０４の間に、低い「データ１．２」プライオリティに対してプライオリティ更新フレームを送信する。プライオリティ更新要求を受信すると、サーバは、ステップ７０５の間に、送信のスケジュールを変更する。その結果、「データ１．３」が送信された後、「データ１．２」の送信は先延ばしされる。さらに、サーバは、「データ１．２」に関連付けられたセグメントをリンクするためにＭＰＤを用いる。サーバは「データ２．２」を識別し、そのプライオリティを減じる。
【００６９】
図７ｂを参照して、部分的な順序付けを説明する。図７ｂのステップ７１０〜７１４は、図７ａのステップ７００〜７０４と実質的に同じである。プライオリティ更新フレームの受信の後、サーバの挙動は、先に記載されたステップ７０５と比べて異なる。ステップ７１５の間、サーバは、既に「データ１．２」の送信を開始しており、送信をさらに進める。そのセグメントに関して、プライオリティに変更はない。サーバは、それにもかかわらず、連結されたセグメント、すなわち本例における「データ２．２」）のプライオリティを更新する。プライオリティ変更が考慮さられた、という事実をアナウンスするために、サーバは「データ２．２」のためのプライオリティ更新マッサージ（ｐｒｉｏｒｉｔｙｕｐｄａｔｅ  ｍａｓｓａｇｅ）を送信してもよい。クライアントは、したがって、変更を通知されることができる。
【００７０】
本発明の実施形態は、ビデオのすべての部分を高品質に再生することができるように、サーバが予め十分に良い高品質のビデオ部分をプッシュすることができる使用事例において実施されてもよい。例えば、ビデオは、低品質として再生される部分１、高品質として再生される部分２、および低品質として再生される部分３に分割されることができる。クライアントとサーバとの間の帯域幅は、高品質ではなく低品質のリアルタイムストリーミングを可能にする。その場合、サーバは、部分２を強化し、部分１をインターリーブしてもよい。一旦部分１が再生されれば、強化された部分２は、また、利用可能であり、サーバは、同じ部分２の強化と共同して高品質として再生される部分２のベース層を送信する。このように、サーバは、すべての部分２が高品質として再生されることを確実にする。部分３は、その後に送信される。ユーザエクスペリエンスを妨害する品質のちらつき（ｑｕａｌｉｔｙ  ｆｌｉｃｋｅｒｉｎｇ）を軽減することができ、品質の切り換え（ｑｕａｌｉｔｙ  ｓｗｉｔｃｈｉｎｇ）のみが、限られた数のモーメントにおいて行われる。サーバは、ビデオコンテンツを認識して以後、異なる品質レベルにいつ切り替えるべきであるかを認識するために最善位置にある。
【００７１】
図８は、実施形態にかかる、プッシュベースのＤＡＳＨメディアストリーミングを実施するサーバによって実行されたステップのフローチャートである。ステップ８００〜８１２は、一般的な原理を記述する。ステップ８２０〜８２７は、より具体的には、クライアントからのプライオリティのフィードバックの管理に対処する。
【００７２】
ステップ８００の間、サーバは、クライアントから要求Ｒを受信する。この要求は、通常はＭＰＤファイルを参照することによって特定のメディアを識別する。次に、サーバは、ステップ８０１〜８１０を含む反復処理を実行する。その処理は、定義された順序にしたがってデータを送信することを有する。送信の順序は、クライアントのフィードバックにしたがって更新される。一旦データが送信されれば、それらはクライアントによって受信され再生される。次に、サーバは、送信するべき新たなデータを識別し、処理は、そのように継続し続ける。
【００７３】
第１の反復は、送信されるデータが識別される間のステップ８０１で始まる。反復処理の第１の実行の場合、クライアントがビデオ再生を可能な限り迅速に開始することを可能にするために、高速起動アプローチが用いられてもよい。さらに、サーバは、また、チャプターへのメディアの細区分を識別しても良い。クライアントが一般的にはチャプターを用いてナビゲートする、ということをサーバが認識する場合、サーバは、メディアの先頭に対して対応するセグメントだけでなくメディア内の第１のチャプターの開始に対応するセグメントも実際に選択してもよい。反復の第１の実行の後、サーバは、また、接続がメディアの高品質のリプレゼンテーションの送信をサポートすることができる、ということを検出しても良い。このように、サーバは、解像度または品質の切り換えをいつ行うべきであるのかを識別しても良い。
【００７４】
一旦サーバがプッシュするセグメントのリストを識別すれば、サーバは、これらのセグメントのための送信順序を定義する。送信順序は、１ステップ８０２の間に各々のプッシュされたセグメントに対する初期のプライオリティ値を算出するために用いられる。順序付けは、いくつかのパラメータに基づいてもよい。
【００７５】
第１のパラメータは、異なるセグメント間の関連性であってもよく、例えば、いくつかのセグメントは、他のセグメントを正確に復号するために利用可能でなければならない。利用可能でなければならないセグメントは、したがって、前記他のセグメントよりも高いプライオリティを割り当てられる。
【００７６】
第２のパラメータは、過去統計値から採集することができる、ビデオセグメントの人気度であってもよい。例として、ＹｏｕＴｕｂｅ（登録商標）のＵＲＬにより、ビデオ内の特定の期間をアドレス指定しても良い。これらのＵＲＬＳに関連するリンク上をクリックすると、特定の時刻にビデオ再生をスタートするために必要とされるビデオのみが取りだされる。さらに、ビデオがチャプター化されている場合、各々のチャプターの先頭は、一般的には多くの場合、チャプター開始の間のセグメントよりもユーザから取りだされる。チャプターの先頭のＳｅｇｍｅｎｔｓは、したがって、中間のチャプターセグメントインよりも高いプライオリティを割り当てられる。
【００７７】
第３のパラメータは、タイムラインであってもよく、再生されているビデオセグメントにより近いビデオセグメントのプライオリティは、後で再生されることになるビデオセグメントのプライオリティより高い。
【００７８】
第４のパラメータは、セグメントを実際に送信するために費やされる推定時間であってもよい。ビデオセグメントが大きい場合、送信するのに長い時間がかかり、そのため、できるだけ早く、すなわち高プライオリティで、送信を開始するべきである。
【００７９】
２つのセグメントが同一のプライオリティを有する場合、対応するデータフレームは、送信の間にインターリーブすることができる。関心領域がメディアコンテンツ内で識別された場合、帯域幅が高品質のリプレゼンテーションには十分に大きくはないが、低品質のリプレゼンテーションには十分に大きければ、サーバは、関心領域のためにのみエンハンスメント層を選択してもよい。
【００８０】
一旦プライオリティが算出されれば、サーバは、ステップ８０３の間に、プライオリティ値を含むＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを送信する。すべてのセグメントの識別は、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの送信を開始するためには必要でない。ＭＰＤがプッシュされるセグメントのために送信される場合（ステップ８０４）、ＭＰＤが送信される（ステップ８０５）。セグメント送信は、ステップ８０６の間に、並列的に開始する。
【００８１】
一旦ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームがクライアントによって受信されれば、サーバは、プライオリティ更新変更を受信し、その後、それに応じて、その送信スケジュールを変更してもよい（ステップ８０７〜８０８およびステップ８２０〜８２８）。セグメントを送信する一方で、サーバは、プライオリティ変更メッセージの受信を待つ。プライオリティ変更メッセージが受信された場合（ステップ８０７）、サーバは、それに応じてセグメントを再順序付けて、セグメント送信を継続する（ステップ８０８）。一旦すべてのセグメントが送信されると（ステップ８０９−１）、サーバは、メディアの端部までメディアをストリーミングし続けるために反復処理を再開する。メディアの端部に到達すると（ステップ８０９−２）、サーバは、別のメディアを自動的にストリーミングし始めるべきか否かをチェックする（ステップ８１０）。別のメディアがストリーミングされるべきである場合（はい（Ｙｅｓ））、サーバは、ストリーミングする新たなメディアを識別し（ステップ８１１）、ステップ８０１から処理を再開する。新たなデータがストリーミングされるべきでない場合、処理は停止される（ステップ８１２）。
【００８２】
クライアントからのプライオリティのフィードバックの、すなわちステップ８０８の管理は、ステップ８２０の間に、プライオリティ更新変更メッセージの受信とともに始まる。クライアントがセグメントプッシュをキャンセルした場合、以下のステップが実行されてもよく、このケースは、そのセグメントに対して最も低いプライオリティを割り当てることと実際には同等であると、理解してもよい。
【００８３】
プライオリティ更新変更メッセージを受信すると、サーバは、ステップ８２１の間に、関連セグメントを識別する。そして、サーバは、セグメント送信の再順序付けを進める（ステップ８２２および８２３）。セグメントが既に送信されていれば、処理は終了する。セグメントが送信されているならば、サーバの実装に応じて、送信を変更することを拒絶してもよいし（例えば複雑すぎるので）、または、送信される残りのデータを実際にスケジュール変更してもよい。
【００８４】
データのスケジュール変更は、以下のように実行されてもよい。サーバは、プッシュするビデオセグメント（および／またはプッシュされるビデオセグメント）のリストを保存する。このリストは、サーバによって設定されたプライオリティにしたがって順序付けられる。そして、サーバは、セグメントに新たなプライオリティ値を設定する。そして、リストが再順序付けられ、対応するビデオセグメントの送信は、それに応じて、早くなったり遅くなったりする。
【００８５】
一旦ビデオセグメントが再順序付けられれば、サーバは、他の関連するビデオセグメントに対して、このプライオリティ変更を適用することを実際に決定してもよい。クライアントがエンハンスメント層の一部であるビデオセグメントのプライオリティを引き上げれば、サーバは、このエンハンスメント層のすべてのセグメントのプライオリティを引き上げてもよい。逆に、クライアントがベースビデオセグメント層のプライオリティを引き下げる場合、このセグメントに一時的に関連するすべてのセグメントのプライオリティが引き下げられてもよい。この処理は、ステップ８２４〜８２７に記述される。ＭＰＤおよびスケジュール変更されたビデオセグメントに基づいて、サーバは、関連セグメントのリストを識別する（ステップ８２４）。関連性は、時間、空間、品質ベースなどであってもよい。ＭＰＤは、潜在的な関連性をより適切に示すために強化されてもよい。特に、（１つ以上のビデオセグメントを再生するのに必要である）イニシャライゼーションセグメントのプライオリティが引き下げられるかまたは引き上げられると、すべての関連セグメントがスケジュール変更されてもよい。これは、ベース層セグメントおよび強化セグメントの同様のケースになり得る。各々の識別された関連セグメントに対して、サーバは、関連セグメントの送信が変更されるべきであるか否かテストする（ステップ８２５）。変更されるべきである場合、サーバは、各セグメントに対して新たなプライオリティ値を算出し（ステップ８２６）、それに応じて、セグメント送信をスケジュール変更する（ステップ８２７）。新たなプライオリティ値は、ステップ８２０の間に受信された新たなプライオリティ値とステップ８２１の間に識別されたセグメントの初期のプライオリティ値との間の差分を古い値に対して加えることによって算出されてもよい。各関連セグメントがテストされると、処理は停止する（ステップ８２８）。
【００８６】
サーバは、また、ＷＩＮＤＯＷ  ＳＩＺＥフレームなどの制御フローメッセージを受信してもよい。これらのメッセージによって、サーバは、クライアントが現在何を再生しているのかを、識別することが出来るであろう。いくつかの追加的バッファスペースがクライアントの端上で利用可能な場合、いくつかのデータ、通常は最も古いデータ、がバッファから取り出された、ということが推測され得る。サーバが送信されたデータの履歴を保持すれば、サーバは、どのデータが取り出されたのかを識別することができる。このように、もしサーバが、クライアントのキャッシュの順序付けを認識しているならば、サーバは、クライアントが現在どのビデオセグメントを再生しているかを知ることができる。この順序付けは、タイムラインにしたがってキャッシュされたデータを、順序付けることを可能的にするＭＰＤに基づいてもよい。そして、サーバは、例えばクライアントの時間スキップを検出することができる。サーバは、クライアントがビデオチャプターをスキップし続けることができるように、予め次のチャプターの開始を迅速に送信することによって対応してもよい。
【００８７】
プライオリティをもつＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの送信が様々な方法で行われてもよい、ということを留意するべきである。ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、クライアントによって起動される開かれたストリーム（ｏｐｅｎｅｄ  ｓｔｒｅａｍ）に関連しなければならない。実施形態によれば、ステップ８００の間にクライアントによって行われた初期のストリームは、常に開かれたままであってもよい。他の実施形態によれば、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、サーバによって開かれたストリーム内で送信される。この場合、それが親クライアントに起動されたストリームによって送信されるように、クライアントは、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを考慮する。このように、個々のＰＵＳＨ＿ＰＲＯＭＩＳＥフレームに対応する仮想要求の正しいヘッダを算出することができる。
【００８８】
他の実施形態によれば、プライオリティメッセージは、ＰＵＳＨ＿ＰＲＯＭＩＳＥと共同で送信される。第１の可能性は、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム内部のヘッダとしてそれを送信することである。もう１つの可能性は、対応するＰＵＳＨ＿ＰＲＯＭＩＳＥフレームによって保存されたストリームＩＤを持つＰＲＩＯＲＩＴＹフレームを送信することである。第３の可能性は、このＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム、その後、（ストリームを開くために）対応するＨＥＡＤＥＲＳフレーム、および新しく開かれたストリーム上のＰＲＩＯＲＩＴＹフレームを送信することである。
【００８９】
さらにクライアントのバッファを制御するために、サーバは、クライアントによってキャッシュされたセグメントの新たなリプレゼンテーションを送信してもよい。この新たなリプレゼンテーションの一部として送信されたヘッダ内で、ＨＴＴＰキャッシュ指示は、例えばキャッシュすることができるものとしてそれをマークすることによって実際にセグメントを取り出すことをクライアントに要求するために用いられてもよい。これにより、クライアントの端上のバッファスペースを回復することが可能となる。ＨＴＴＰ／２制御フローが用いられてもよい。そして、サーバは、付加データをプッシュすることができる。
【００９０】
サーバは、各ビデオセグメントのプライオリティ値を送信してもよい。サーバは、また、特定セグメントのためのプライオリティ値を送信してもよい。サーバが、現在のＰＵＳＨ＿ＰＲＯＭＩＳＥフレームのプライオリティ値を送信しなかった場合、クライアントは、サーバから送信された最後のプライオリティ値からプライオリティ値を算出することができる。例えば、クライアントは、関連付けられたプライオリティ値がない新たなＰＵＳＨ＿ＰＲＯＭＩＳＥフレームが受信されるたびにプライオリティ値を増加させてもよい。従って、特定セグメントのプライオリティの更新をするとまたグループのすべてのセグメントのプライオリティを更新するように、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、グループ化することができる。
【００９１】
図９を参照してクライアント側の処理を説明する。
【００９２】
クライアントは、所定の時間に利用可能なコンテンツを再生可能であるべきである。しかしながら、クライアントは、潜在的なバッファ制限および処理時間に対処しなければならない。クライアントは、サーバによって提案された送信順序付けがクライアントのバッファにおいて利用可能なメモリスペースと一致し、且つクライアントによって現在再生されているコンテンツと一致するか否かを、チェックしなければならない。
【００９３】
最初のステップ９００の間に、クライアントは、サーバに接続して、ＭＰＤファイルを要求する。そして、クライアントは、ステップ９０１の間にＭＰＤファイルを取り出し、データの受信を待つ（ステップ９０２）。データが受信されると、クライアントは、データがプッシュプロミスであるか否かをチェックする（ステップ９０３）。プッシュプロミスが受信された場合、これは、新たなビデオセグメントがサーバによって送信されている、ということを意味する。クライアントは、プッシュプロミスを処理する。特に、クライアントは、ステップ９０４の間にサーバによって提案されたプライオリティ値を認証してもよい。クライアントが現在のセグメントまたは別のプロミスされたセグメントのプライオリティ値を変更したい場合（ステップ９０５）、クライアントは、新たなプライオリティ値を算出して、それをサーバに対して送信する（ステップ９０６）。
【００９４】
クライアントがビデオデータを受信すると（ステップ９０７）、クライアントは、ビデオセグメントをＭＰＤファイルにリンクし（ステップ９０８）、ビデオデータ（ステップ９０９）を保存する。ビデオデータをＭＰＤファイルにリンクすると、ビデオの復号のためにさらに用いられる場合にクライアントがビデオセグメントを取りだすことが可能になる（ステップ９１１）。例えば連続したビデオセグメントがグループ化されると、これは、また、ビデオデータの効率的な保存を提供することができる（ステップ９０９）。
【００９５】
バッファ保存制約は、さらにプライオリティを変更することができる。このように、クライアントは、プライオリティ値を変更しなければならないかどうかを再びチェックすることができ、もし必要ならばサーバと通信してもよい（ステップ９０５および９０６）。
【００９６】
一旦クライアントがビデオを再生し始める、または再生し続ける準備ができれば（ステップ９１０）、クライアントは、そのキャッシュから次のタイムスロットのビデオセグメントを取り出し（ステップ９１１）、ビデオを復号して再生する（ステップ９１２）。ステップ９１１の一部として、クライアントは、どのビデオセグメントが利用可能であるのかを認識するためにそのキャッシュを問い合わせることができる。デフォルトでは、クライアントは、利用可能なすべてのビデオセグメント、もしあれば特にすべての強化セグメント、を用いてもよい。クライアントは、サーバにコンテンツを選択させることができ、一般的には言えば、すべてのセグメントは、クライアントによって用いられるべきである。（オーディオの英語トラックおよびフランス語トラックのような）いくつかのセグメントを共同で用いることができなければ、クライアントは、まず第１に未使用のセグメントを捨てるべきである。すべてのクライアントがキャッシュ状態に対してアクセスするとは限らないかもしれない、ということに留意するべきであり、特にウェブアプリケーションは、ウェブブラウザのキャッシュに対して通常はアクセスしない。このようなケースにおいて、サーバは、ウェブアプリケーションクライアントに対してプッシュされたセグメントのリストを直接送信してもよい。例えば、この情報は、ウェブソケット接続を用いて、サーバからクライアントに交換されてもよい。
【００９７】
ビデオが再生されて復号されるとともに、対応するビデオセグメントは、バッファから取り出されるであろう。従って、クライアントは、ＷＩＮＤＯＷ  ＳＩＺＥフレームを用いて、その利用可能なバッファサイズを更新する。クライアントは、ユーザが限られた期間の間にビデオを巻き戻すことを可能にするために、最近再生されたビデオセグメントを保持してもよい。ユーザが早送り／タイムスキップを行う場合、フロー制御更新メカニズムも用いられてもよい。クライアントは、新たなコンテンツのために場所を空けるために、前から保存されたビデオコンテンツを取り出してもよく、ＷＩＮＤＯＷ  ＳＩＺＥフレームを用いて、サーバに対してこの変更をアナウンスする。サーバがＷＩＮＤＯＷ  ＳＩＺＥフレームを受信すると、サーバは、前述のように、どのビデオセグメントが取り出されたのかを算出し、その後、クライアントが実際に何を再生しているのかを識別することができるであろう。
【００９８】
以下において、ステップ９０４をさらに詳細に説明する。
【００９９】
クライアントは、すべてのプッシュプロミスビデオセグメントのリストを保持する。このリストは、プッシュプロミスフレームにおいて見つかったプライオリティ情報にしたがって順序付けられる。第１に、それは潜在的な凍結されたビデオ問題のためにチェックされる。利用可能な帯域幅の推定および順序付けられたビデオセグメントリストに基づいて、各セグメントの送信の始まりおよび終わりの時刻を推測することができる。これらの時刻に基づいて、各ビデオセグメントはビデオ再生のために用いられる時刻に利用可能であるか否か、をテストされることができる。プロミスされたビデオセグメントがその対応するビデオ再生の使用の後に配送されることが予定される場合、そのプライオリティを上げるべきである。このように、このビデオセグメントは、プッシュプロミスビデオセグメントリスト内の順序が繰り上げられる。正確なプライオリティ値を算出するために、ビデオセグメントを時間通りに配送することを可能にするとともに、現在のビデオセグメントの位置に最も近い、ビデオセグメントリスト内における位置を検索する。そして、プライオリティは、ビデオセグメントの新たな位置の前後にあるリスト内のビデオセグメントのプライオリティ間の値に設定される。
【０１００】
他のファクタも、また、ビデオセグメントのプライオリティの変更のために、クライアントによって用いられてもよい。例えば、クライアントがいくつかのチャプター切換を行うことを予定していれば、クライアントは、チャプターを開始するすべてのビデオセグメント、特に対応するイニシャライゼーションセグメント、のプライオリティを実際に拡大してもよい。
【０１０１】
実施形態によれば、クライアント側フロー制御は、ストリームごとのフロー制御を停止させて接続ごとのフロー制御のみを保持することを有する。接続ごとのウィンドウサイズは、クライアントが実際にいかなるときにも保存してもよいビデオの最大量を定義する。クライアントおよびサーバは、このウィンドウサイズを減少または拡大するためにイニシャライゼーション時や接続中にネゴシエイトしてもよい。サーバがいくつかのＨＤコンテンツをプッシュしたければ、サーバは、ウィンドウサイズを拡大することをクライアントに要求してもよい。接続帯域幅が低いならば、サーバは、ビデオの特定の部分のためのＨＤコンテンツを送り出すことを予め十分に予期する必要があるかもしれず、その場合には、バッファサイズは、より大きくされる。
【０１０２】
バッファが単一のサイズを有する場合、送信の順序は、重要な問題であるであろう。特に、バッファがデータでいっぱいになった時に、プライオリティ順序付けは、より一層重要になる。重要な制約は、ビデオがフリーズしないということである。バッファが大きく空いている限り、サーバは、効率的な早送りまたはチャプタースキップを提供するために、かなり先行したセグメントのような様々なビデオセグメントを予めプッシュしてもよい。一旦バッファがほぼ満タンになれば、プッシュするビデオセグメントは再生されるビデオセグメントになるべく近いるべきである。サーバがクライアントバッファに関係する正確な情報を有していれば、このプッシュ挙動は、サーバによって行われてもよい。また、それは、プライオリティ更新メカニズムを用いて、クライアントによって実施されてもよい。
【０１０３】
自動化されたビデオ切換の場合には、図９のフローチャートは、プッシュプロミスチェックの一部として新たなＭＰＤのプッシュを検出することによって拡張されてもよい（ステップ９０３）。ＭＰＤプッシュが検出されると、クライアントは、ステップ９０８の一部として新たなビデオのセグメントを受信し始めてもよい。そのため、クライアントは、ビデオデータに関連するＭＰＤを識別しなければならない。一旦ビデオ再生が所定のＭＰＤ（ステップ９０２）のために終了されると、新たなＭＰＤは、ビデオ再生の継続のために用いられる。クライアントは、先のＭＰＤにリンクされたビデオセグメントをすべて実際に消去することができる。
【０１０４】
図１０を参照して、ＤＡＳＨ認識プロキシの挙動を説明する。サーバからプッシュされたセグメントを受信すると、プロキシは、エンドクライアントに対してそれをプッシュするようには要求されない。しかしながらＤＡＳＨストリーミングの場合には、それは優れた方式（またはデフォルトの挙動）と考えられる。
【０１０５】
プロキシは、送信されるプッシュされたデータだけでなくプライオリティ処理に関して、サーバおよびクライアントの挙動を調整することができてもよい。プロキシは、実際、クライアントによるプライオリティを、サーバによるプライオリティから独立して取り扱ってもよい。さらに、サーバは所定のクライアントのために必要とされる以上のデータをプッシュしてもよく、プロキシは、他のクライアントからの要求を実現するために付加的なプッシュされたデータを取り込んでもよい。
【０１０６】
サーバは、いくつかの理由によりビデオセグメントをプッシュしてもよい。例えば、それがエンドクライアントのために有用であると考えられた場合、ビデオセグメントがプッシュされてもよい。ビデオセグメントは数回使用することが可能で、且つプロキシに対してそれをプッシュする価値があると考えられる場合、ビデオセグメントもプッシュされてもよい。
【０１０７】
第１のケースにおいて、プロキシは、一般的には、クライアントに対してビデオセグメントを送信する。プロキシは、クライアントまたはプロキシのネットワーク状態（例えばクライアント無線状態）を最適化するためにその送信を先延ばししてもよい。例示的なケースは、高速起動ビデオ再生および帯域幅推定のためのセグメントプッシュであり、その場合には、データはクライアントに対して可能な限り高速に送信されるべきである。サーバがプロキシに対するデータのプッシュに関心がある場合、プロキシは、ビデオセグメントがクライアントに対して有用になることを認識する手段を有する場合以外は、クライアントに対してビデオセグメントを自動的に送信しなくてもよい。クライアントに対して送信されなくてもよいビデオセグメントの識別を可能にするために、特定のプライオリティ値を用いてもよい。プライオリティ値を用いると、到達する様々なフレームの処理を最適化するためにプロキシが常にプライオリティ値をチェックすることができる。
図１０は、３つのフローチャートを含む。１つのフローチャートは、プッシュされたセグメントをフィルタリングする処理に関する（ステップ１０００〜１００８）。もう１つのフローチャートは、セグメントが別のクライアントに対して既にプロミスされている一方で、セグメントがクライアントによって要求された場合に実行される処理に関する（ステップ１０１０〜１０１５）。もう１つのフローチャートは、プライオリティ変更の管理に関する（ステップ１０２０〜１０２６）。
【０１０８】
プッシュされたセグメントをフィルタリングする処理は、プッシュされたデータイベントの受信（ステップ１０００）とともに、通常はＰＵＳＨ＿ＰＲＯＭＩＳＥフレームまたは関連するＤＡＴＡフレームを受信したときに、始まる。プロキシは、データが高プライオリティであるか否かをチェックする（ステップ１００１）。データは、それらのプライオリティ値が送信されている他のセグメントのプライオリティ値よりはるかに大きい場合、高プライオリティであると考えられる。データは、また、そのプライオリティ値が高速起動または帯域幅推定などの特別の意味を有するならば、高プライオリティであるとして考えられる。データが高プライオリティである場合、それらはクライアントに対して可能な限り迅速に送信される（ステップ１００２）。そして、プロキシは、データを保存するべきであるか否かを決定する（ステップ１００３および１００４）。プッシュされたデータストリームを開く対応するＰＵＳＨ＿ＰＲＯＭＩＳＥフレームまたは対応するＨＥＡＤＥＲＳフレームを受信すると、この判定は、一回行われてもよい。この判定は、また、プロキシのキャッシュ状態、ビデオの予見された使用、ビデオソースの人気度、または他の基準に基づいてもよい。セグメントが１つ以上のクライアントによって同時に要求される間にプッシュされれば、プロキシは、ビデオセグメントを保存する。セグメントが高速起動として識別されれば、ビデオセグメントもまた保存されてもよい。
【０１０９】
データが高プライオリティでないならば、プロキシは、それが低プライオリティであるか否かをチェックする（ステップ１００５）。低プライオリティのデータは、クライアントに対する送信がスキップされてもよいが、プロキシのようなネットワーク媒介に対して興味深いものとしてサーバによって考慮されるデータかもしれない。プロキシは、まず、クライアントに対してデータを送信するべきか否かを決定する（ステップ１００６）。プッシュされたデータストリームを開く対応するＰＵＳＨ＿ＰＲＯＭＩＳＥフレームまたは対応するＨＥＡＤＥＲＳフレームを受信すると、この判定は、一回行われてもよい。そのように決定されれば、プロキシは、クライアントに対して、対応するフレームを送信する（ステップ１００２）。そして、処理は、データを保存するべきか否かを決定した後に停止する。
【０１１０】
サーバとプロキシとの間でネゴシエイトされたプライオリティ値は、また、クライアントとプロキシとの間でネゴシエイトされたプライオリティ値とは異なってもよい。そのため、データが通常のプライオリティである（すなわち、低プライオリティでもなく、高プライオリティでもない）場合、プロキシは、セグメントのプライオリティ値がプロキシによって管理されるか否かをチェックする。図１０に図示されるように（ステップ１０２０〜１０２６）、プロキシは、データが送信されるべき時刻をスケジューリングするためにクライアント〜プロキシ間の値を用い、プロキシは、送信されるべきすべてのビデオ関連のフレームのリストを保持する。これらのフレームは、その順序にしたがって送信される前に、プライオリティ値にしたがって順序付けられる。
【０１１１】
プロキシは、プライオリティ更新フレームを受信している場合に（ステップ１０１０）、プロキシは、関連するビデオセグメントを識別する（ステップ１０１１）。そのプライオリティ値がプロキシによって管理されていなければ（ステップ１０１２）、プロキシは、サーバに対してプライオリティ更新フレームを転送する（ステップ１０１３）。さもなければ、プロキシは、この新たなプライオリティ値を保存し、それに応じて、ビデオセグメントの送信を再順序付ける（ステップ１０１４）。潜在的な競合が出現した場合、特にサーバからのビデオセグメントの配信がクライアントのニーズに対して遅れすぎると予想される場合、プロキシは、サーバに対してプライオリティ値を転送することができる。
【０１１２】
ステップ１０２０〜１０２６は、サーバによって既にプロミスされているビデオセグメント（ステップ１０２０）のクライアントから別のクライアントに対する要求を受信するプロキシのケース（ステップ１０２１）に関連する。その要求に対して与えられるプライオリティに応じて、プロキシは、クライアントの要求を満たす、プロキシ〜サーバ間の最小のプライオリティを算出する（ステップ１０２２）。この計算は、サーバ〜プロキシ間の配信時刻がプロキシ〜クライアント間の予定した配信時刻よりも早いということを保証する、プロキシ〜サーバ間のプライオリティ値を算出することによって行われる。プライオリティは、算出されたプライオリティが現在設定されているプライオリティを下回る場合に、変更され（ステップ１０２３）、その場合には、プロキシは、プライオリティ更新メッセージをサーバに対して送信することになり（ステップ１０２４）、プロキシは、プロキシがそれらのニーズに対して最良の時刻にその２つのクライアントに対してビデオセグメントを送信するように、プロキシによって管理されるようなこのビデオセグメントプライオリティをマークすることになる。この処理と同様に、プロキシは、いくつかのクライアントから同じセグメントに対する、いくつかのプライオリティ更新を受信してもよく、その場合には、プロキシは、すべてのクライアントを満たす最も低いプライオリティ値を実際に送信してもよい。
【０１１３】
図１１を参照して、プッシュされたデータイベントをクライアントが受信することによる実施形態が説明され、そのデータイベントのプライオリティ値は、サーバが帯域幅の測定のためにそれを用いたいということを示す。帯域幅の測定は、ラウンドトリップ時間を算出するための能動的または受動的な測定を通じてＴＣＰ／ＩＰパケットを用いて行われてもよい。ラウンドトリップ時間に基づいて、利用可能な帯域幅は、Ｓａｕｂｈａｓｉｋ他の文献「ＢｉｔＶａｍｐｉｒｅにおける帯域幅推定および速度制御（ＢａｎｄｗｉｄｔｈＥｓｔｉｍａｔｉｏｎ  ａｎｄ  Ｒａｔｅ  Ｃｏｎｔｒｏｌ  ｉｎ  ＢｉｔＶａｍｐｉｒｅ）」に見出されるように、算出されてもよい。この計算は、場合によっては、ＨＴＴＰ／２制御フローの影響を考慮に入れてもよい。いくつかのデータフレームが可能な帯域幅推定のために用いられる、という通知を行うことによって、ＨＴＴＰ／２制御フローなしで、利用可能な帯域幅を推定することができる。
【０１１４】
処理は、プッシュされたデータフレームがサーバから受信される間のステップ１１００にて始まる。次に、ストリームの関連付けられたプライオリティが、サーバが帯域幅を測定しているということを示すか否かがチェックされる（ステップ１１０１）。その場合、専用のバッファは最大化される（ステップ１１０２）。または、ストリームフロー制御を無効にすることもできる。受信ノードがプロキシであるならば（ステップ１１０３）、セグメントデータを転送してもよい。さもなければ、クライアントは、セグメントを保存するべきか否かを決定する（ステップ１１０４）。クライアントは、プッシュされたセグメントを保存する（ステップ１１０５）。いずれにしても、クライアントは、接続ごとのウィンドウのための肯定応答をＷＩＮＤＯＷＳ（登録商標）＿ＵＰＤＡＴＥの形式でサーバに対して送信する（ステップ１１０６）。そして、この肯定応答は、接続帯域幅を推定するためにサーバによって用いられることになる。クライアントがプロキシで有る場合、プッシュされたデータを可能な限り迅速に転送する（ステップ１１０８）。エンドクライアントから肯定応答を受信すると、プロキシは、同様にそれをサーバに返送する（ステップ１１０９および１１１０）。
【０１１５】
利用可能な帯域幅を推定するために、サーバは、データフレームの送信時刻と肯定応答メッセージの受信時刻との間の差分として算出される、送信されたデータフレームのラウンドトリップ時間を用いてもよく、２者間のペアリングは、例えばウィンドウサイズ更新に等しくなるべきデータフレームサイズに基づく。ラウンドトリップ時間は、１つ以上のビデオセグメントの様々なデータフレームから算出される。正確さを増すために、データフレームは、様々なサイズを有してもよい。異なるサイズのいくつかのＤＡＴＡフレームにビデオセグメントを分割することは、サーバによって実行できる。サーバは、ネットワーク層が、ＤＡＴＡフレームを、いくつかのＴＣＰ／ＩＰパケット（したがって小型のＤＡＴＡフレーム）に分割しない、または送信されるコンテンツをバッファリングして、いくつかのＤＡＴＡフレームをＴＣＰ／ＩＰパケットにマージしない、ということを保証することのみ必要とされる。それらの測定値に基づいて、規格技術は、どのビデオリプレゼンテーションを用いるかを実際に判断するために、サーバが用いてもよい利用可能な帯域幅を算出するために用いることができる（例は上記の文献内で見出すことができる）。
【０１１６】
図１２を参照して、初期のビデオ再生のケースを説明する。サーバは、高速起動プライオリティを用いて、データをプッシュする。データは、通常低ビットレートを有しており、クライアントは、サーバが帯域幅を推定することができ、且つ最適なリプレゼンテーションに切り替えることができるように、それらのデータを受信して肯定応答をサーバに対して送信することになる、と考えられる。クライアント側の処理はステップ１２００〜１２０７に記載される。サーバ側の処理は、ステップ１２１０〜１２１５に記載される。
【０１１７】
クライアント処理は、プッシュされたデータの受信のステップ１２００から始まる。そして、クライアントは、プライオリティが高速起動の値を有するか否かをチェックする（ステップ１２０１）。その場合、クライアントは、通常は、専用のバッファを最大化する（ステップ１２０２）。プッシュされたデータのＰＵＳＨ＿ＰＲＯＭＩＳＥを受信すると、この最大化が実行される。そして、データが保存され（ステップ１２０３）、クライアントは、ＷＩＮＤＯＷ  ＵＰＤＡＴＥフレームを用いて、肯定応答をサーバに送信する（ステップ１２０４）。そして、クライアントは、ビデオを再生し始めるために十分なデータが利用可能であるか否かをチェックする（ステップ１２０５）。そうであるならば、ビデオ再生が始まる（ステップ１２０６）。そうでなければ、データを再生し始めるために十分なデータが利用可能になるまで、クライアントは、さらなるデータを待つ（ステップ１２０７）。
【０１１８】
サーバ処理は、高速起動プライオリティでセグメントデータフレームを送信するステップ１２１１から始まる（ステップ１２１０）。そして、サーバは、利用可能な帯域幅を算出すること（ステップ１２１２）を可能にする肯定応答を受信する（ステップ１２１１）。一旦十分な測定値が取得されれば、サーバは、最適なリプレゼンテーションを選択し（ステップ１２１３）、最適なリプレゼンテーションセグメントをプッシュし始める（ステップ１２１４）。サーバは、リプレゼンテーションをいつ切り替えるのかを決定する。これには少なくとも２つの利点がある。第１に、クライアントが多少の遅延に対処する必要がある一方で、サーバは、いつ測定値が十分に正確になるのかを認識することができ、このケースであれば直ちに１つの解像度から別の解像度に切り替えることができる。第２に、サーバは、ユーザエクスペリエンスをあまり妨害しない時刻に１つの解像度から別の解像度に切り替えることを決定することができる。実際には、サーバは、ビデオコンテンツの認識を有する。特に、ＭＰＤは、解像度の切り換えを最良に予見することができる時刻の情報により強化されてもよい。
【０１１９】
本発明は、強化されたストリーミング方法に関し、サーバ側において、第１のメディアデータに関連する要求がクライアント装置から受信され、要求されていなくともクライアント装置に対して送信される第２のメディアデータが識別され、そして、前記第１のメディアデータに関連する情報が前記要求に応答して前記クライアント装置に対して送信され、クライアント装置に対してアナウンスメッセージ（単数または複数）を送信するために前記第２のメディアデータをそれぞれ識別する少なくとも１つのアナウンスメッセージが準備される。
【０１２０】
クライアント側において、第１のメディアデータに関連する要求は、サーバ装置に対して送信され、前記第１のメディアデータに関連する情報は、前記要求に応答して前記サーバ装置から受信される。
【０１２１】
強化されたストリーミング方法は、いくつかのメディアデータをプッシュするサーバの判定と、このようなデータのためのクライアントのニーズとの間のミスマッチを減少させる。以下から明らかになるように、サーバおよびクライアントは、サーバおよびクライアントが両方ともクライアントによって要求されたいずれかのメディアデータからプッシュされる同じメディアデータを決定するように、プッシュポリシーを共有する。プッシュポリシーは、プッシュするデータを決定する方法を定義しており、要求されたデータが処理された（ＧＥＴ要求の後に）後に、要求されたデータに対してリンクされたどのリソースがプッシュされるのか、および場合によってどのようにプッシュされるか（例えば、どの順序で）を判定するための規則として理解されてもよい。通常、リンクされたリソースは、１つのドキュメント、例えば、（マルチメディアデータのためのＤＡＳＨコンテキストにおける）ＭＰＤファイルなどのマニフェストファイル、またはＨＴＭＬドキュメント、を用いて決定される。
【０１２２】
結果として、共有されたプッシュポリシーに基づいて、クライアントはサーバの挙動を予期し、サーバからの無用のメディアデータの送信を、回避する、そしてより正確にはキャンセルすることができる。クライアントとサーバとの間の通信ネットワーク内の帯域幅の使用が、このようにして減少する。さらに、ＨＴＴＰ要求およびＰＵＳＨ＿ＰＲＯＭＩＳＥキャンセルの数が減少し、その結果、特に低遅延のライブビデオストリーミング用のアプリケーションの待ち時間が下がる。
【０１２３】
本発明によれば、サーバは、サーバ装置がクライアント装置に対する第２の非要求メディアデータの識別および送信を駆動するためにクライアント装置と共有されるプッシュポリシーを、用いることができる。特に、クライアント装置に対して送信される第２の非要求メディアデータサーバ装置が決定するために、クライアント装置と共有されるとともに第２のメディアデータを決定する方法を定義するプッシュポリシーを用いてもよい。それに対応して、クライアント装置によって要求されていなくともサーバ装置によって送信される第２のメディアデータをクライアント装置が決定するために、クライアントは、サーバ装置と共有されるとともに第２のメディアデータを決定する方法を定義するプッシュポリシーを用いてもよい。
【０１２４】
図１４ａは、クライアント側における本発明の一般的なステップを、フローチャートを用いて示し、その一方で、図１４ｂは、サーバ側における本発明の一般的なステップを、フローチャートを用いて示す。
【０１２５】
図１ｄおよび図１ｅを参照して説明された処理との比較において、付加的なステージ１４００および１４０２は、サーバおよびクライアントが、他方と共有されて、それにより用いられるプッシュストラテジをそれぞれ決定することを可能にする。
【０１２６】
第１の実施形態によれば、共有されたプッシュポリシーは、共有されるプッシュポリシーが何であるのかを他方に知らせるためにクライアントおよびサーバがポリシーデータを交換しない（明示的でない）ということを意味する、暗示的なプッシュポリシーである。共有されたプッシュポリシーの暗示的アプローチの実施は、サーバ装置およびクライアント装置の両方において、「第２のメディアデータを決定するアルゴリズム」として呼ばれる同じアルゴリズムを用いることを含み、アルゴリズムは、サーバ装置およびクライアント装置が、要求された第１のメディアデータから同じ第２のメディアデータを決定することを可能にする。
【０１２７】
例えば、アルゴリズムは、クライアントおよびサーバのセットアップの間に、または特定の規格に関連して、予め決定される。アルゴリズムの代表例は、マニフェストファイルの構文解析順序における要求されたリソースに追続くＮ個のリソースのプッシュする場合であり、ここで、Ｎは所定数（例えば４）である。
【０１２８】
図を参照して、ステップ１４００および１４０２は、暗示的なプッシュポリシーのケースでは、プッシュされるリソースを識別する（サーバ側におけるステップ１４０３）ためにメモリ内の所定のアルゴリズムをロードすることにある。
【０１２９】
クライアントは、例えばステップ１４０１において、期待されるＰＵＳＨ＿ＰＲＯＭＩＳＥの数を推定し、且つ不要なプッシュデータのためにキャンセルメッセージを準備するように決定されたプッシュポリシーを効率的に用いてもよい。
【０１３０】
例えば、サーバ装置が対応する用意されたアナウンスメッセージを送信しないように、第２の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求をサーバがクライアント装置から受信することになる。一方で、クライアントは、第２の非要求メディアデータの一部を識別するアナウンスメッセージを送信しないようにサーバ装置を駆動するために、第２の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求をサーバ装置に対して送信するであろう。アナウンスメッセージがサーバ装置から送信されるか、またはクライアント装置によって受信される前に、このようなキャンセルが行われることができる、ということをわかるであろう。このアプローチは、例えば、別のバージョンのメディアに切り替えることをクライアントが決定するときに、有用かもしれない。このような状況において、前バージョンのためにプッシュされたセグメントをキャンセルすることを決定することができる。
【０１３１】
アルゴリズムを用いてプッシュされるリソースの認識のために、クライアントは、サーバから対応するＰＵＳＨ＿ＰＲＯＭＩＳＥを待つ必要なく後続のリソースを取りだすために、サーバに対して第２の要求を並列に行うことができる、ということにも留意するべきであろう。ＤＡＳＨの場合には、クライアントのためのこの可能性は、第２の要求が後で受信するＰＵＳＨ＿ＰＲＯＭＩＳＥに干渉しないことを保証しながら、クライアントの待ち時間を減少させることを可能にする。
【０１３２】
これらの他の必要とされるリソースがプッシュされようとしている、ということをアルゴリズムの結果から判定すれば、クライアントは、また、必要とする他のリソースを要求してもよい。
【０１３３】
第２の実施形態によれば、共有されたプッシュポリシーは、全体の規則（すなわちアルゴリズムまたはアルゴリズムのパラメータ）を明確に定義するか、または両方の側で事前に定義されたプッシュポリシーを参照することによって、クライアントとサーバとの間の交換において定義される。これは、サーバのプッシュポリシーを記述するプッシュポリシー情報をサーバがまず決定することが必要となる。そして、プッシュポリシー情報は、プッシュポリシーをクライアントと共有するために、クライアントに対して送信される。それに対応して、クライアントは、それにより、共有されたプッシュポリシーを記述するプッシュポリシー情報をサーバ装置から受信する。
【０１３４】
明示的アプローチの１つの効果は、それらの処理特性をより適切に満たすために異なるプッシュポリシーを、各クライアントまたは各マルチメディアプレゼンテーション（例えば各ＭＰＤ）のためにサーバが用いることができるという事実に依存する。図１５ａは、明示的アプローチに基づいて、クライアント側において共有されるプッシュポリシーを決定するステップ１４００を、フローチャートを用いて示し、その一方で、図１５ｂは、明示的アプローチが用いられるときに、サーバ側においてプッシュポリシーを決定するステップ１４０２を、フローチャートを用いて示す。
【０１３５】
図１５ｂに示されるように、サーバは、ステップ１５０４において、プッシュポリシーを宣言するメッセージを生成し、その後、それを共有するために、ステップ１５０５においてクライアントに対してそれを送信する。宣言メッセージ内のプッシュポリシーを記述する情報は、プッシュポリシー情報と称される。
【０１３６】
以下に記載される図１６〜図１８は、プッシュポリシーがどのように宣言され、クライアントに対して送信されるのかについて例示的な詳細を示す。
【０１３７】
ステップ１４０２において決定されるようなプッシュポリシーを用いてプッシュされるリソースは、ステップ１５０４において生成されるプッシュポリシー宣言メッセージ内に定義されたセレクションアルゴリズム（または第２のメディアデータを決定するアルゴリズム）により、ステップ１４０３において識別される。
【０１３８】
クライアント側では、図１５ａに示されるように、クライアントは、同じ選択アルゴリズムを適用することによって、所定のリソース要求のためにプッシュされるリソースを、事前に識別することができる。これは、サーバによってプッシュされるデータをクライアントが予め決定することを可能にし、したがって、プッシュデータの効率的な管理と、必要であればＧＥＴ要求の数の削減とを保証することを可能にする。
【０１３９】
同じ選択アルゴリズムを適用するために、クライアントは、サーバによって適用されたプッシュポリシーを記述するプッシュポリシー情報を受信する。
【０１４０】
様々なプッシュポリシーの宣言方法が用いられてもよい。
【０１４１】
１つの実施形態において、プッシュポリシー宣言は、要求Ｒと、プッシュされるリソースを含むドキュメント（通常はＤＡＳＨのためのマニフェストファイル）に対応するＤＯＭツリーとを入力パラメータとして利用して、プッシュされるリソースの順序付きリストを出力するＪａｖａ（登録商標）Ｓｃｒｉｐｔプログラムのおかげで共有される。この実施形態において、プッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されるウェブページ内に埋め込まれるＪａｖａ（登録商標）Ｓｃｒｉｐｔプログラムを含む。
【０１４２】
他の実施形態において、プッシュポリシーは、マニフェストファイル内に記述される。それは、共有されたプッシュポリシーを用いて、サーバ装置からクライアント装置に対して送信される記述ファイル内の共有されたプッシュポリシーが挿入されることを記述するプッシュポリシー情報である。記述ファイルは、第１のメディアデータを含むメディアデータに関係し、プッシュされる第２の非要求メディアデータを決定するために両方の側によって用いられる記述情報を含む。
【０１４３】
ＤＡＳＨにおいて、記述ファイルは、例えばＭＰＤファイルである。以下の記述は、主として、ＤＡＳＨおよびＭＰＤファイルに基づく。しかしながら、同じアプローチは、スムーズなストリーミングまたはＨＴＴＰライブストリーミングのような他のマニフェストベースのストリーミング方法に適用できる。
【０１４４】
具体的な定の実施形態によれば、プッシュポリシー情報は、識別される第２の非要求メディアデータの量を定義する第１のプッシュ属性を記述ファイル内に含む。これは、１つの要求Ｒがクライアントから受信された後、プッシュされるセグメントの数を指定することを可能にする。
【０１４５】
これは、サーバによって適用されるプッシュポリシーを指定するためにＰｕｓｈＰｏｌｉｃｙノード１６００が用いられるＭＰＤドキュメントを示す図１６によって示される。
【０１４６】
この例において、ＰｕｓｈＰｏｌｉｃｙノード１６００は、ＧＥＴ要求が受信された後にプッシュされるセグメントの数を宣言するために、プッシュ属性（すなわち「Ｓｅｇｍｅｎｔｌｄｘ」）を含む。例えば、クライアントがそのＧＥＴ要求内のセグメント１６０１を必要とするならば、ＭＰＤドキュメントの順序を解析する際に、次の２つのセグメントのためのＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを応答として、受信することになる。この例において、第１のプッシュ属性は、記述ファイル内の要求された第１のメディアデータに対して第２の非要求メディアデータを識別する。さらに一般的には、プッシュされるＫ個のセグメントの所定数は、プッシュポリシー値を定義するために用いられる。結果的に、クライアントによって要求される各セグメントに対して、サーバは、Ｋの次のセグメントをプッシュすることになる。
【０１４７】
図１６の例１６００は、単一のプッシュ属性を示すが、複数のプッシュ属性があってもよい。各プッシュ属性は、プッシュされるセグメントを選択するために、マニフェストを表現するＤＯＭ（ドキュメントオブジェクトモデル（Ｄｏｃｕｍｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ））ツリーのノード上の制約を表現してもよい。図４ｂの先の例を参照すると、プッシュポリシーノード１６００は、メディアデータが属するＰｅｒｉｏｄ要素を参照する期間属性「Ｐｅｒｉｏｄｌｄｘ」と、メディアデータのＡｄａｐｔａｔｉｏｎＳｅｔ要素を参照するアダプテーション属性「ＡｄａｐｔａｔｉｏｎＳｅｔｌｄｘ」と、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素を参照するリプレゼンテーション属性「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｌｄｘ」、すなわちメディアデータの符号化バージョン（特定のコーデック、解像度、またはビットレート…）と、所定のリプレゼンテーション内のセグメントを参照するセグメント属性「Ｓｅｇｍｅｎｔｌｄｘ」と、を含むメディアデータ属性（ＭＰＤ要素および／または属性）を用いて、記述ファイル（ＭＰＤファイル）内に記述されるメディアデータを参照することができる。
【０１４８】
これらの既存のメディアデータ属性に基づいて、プッシュポリシー情報は、第２の非要求メディアデータを識別するために、メディアデータ属性（単数または複数）上の制約を定義する少なくとも第２のプッシュ属性を含んでもよい。
【０１４９】
例えば、Ｓｅｇｍｅｎｔｌｄｘ属性に関連する上記の第１のプッシュ属性に加えて、プッシュするセグメントを選択するための期間上の制約を指定するために、プッシュ属性は、Ｐｅｒｉｏｄｌｄｘ属性に関連付けられてもよく、別の１つは、適応上の制約を指定するためにＡｄａｐｔａｔｉｏｎＳｅｔｌｄｘ属性に関連付けられてもよく、別の１つは、リプレゼンテーション上の制約を指定するためにＲｅｐｒｅｓｅｎｔａｔｉｏｎｌｄｘ属性に関連付けられてもよい。
【０１５０】
プッシュ属性が存在しないかまたは無効のとき、関連するメディアデータ属性は、非制約として考えられねばならない。
【０１５１】
プッシュ属性の値は、以下の構文を用いてもよい。
【０１５２】
プッシュ属性＝［オペレータ］オペランド（ｐｕｓｈ  ａｔｔｒｉｂｕｔｅ＝［ｏｐｅｒａｔｏｒ］  ｏｐｅｒａｎｄ）
ここで、「オペレータ」は、オプションであり、要求されたセグメントに対して相対的にプッシュされるセグメントを定義するために、値「＋」または「−」をとり（「＋」は後を意味し「−」は先を意味する）、ここで、「オペランド」は、ワイルドカードパラメータとして０または「＜＊＞」よりも上位の整数値若しくは等しい整数値のいずれかである。
【０１５３】
図１７は、共有されたプッシュポリシー「ＰｕｓｈＰｏｌｉｃｙ」にしたがってプッシュされる準備ができている、いくつかのセグメントを識別してマークするステップを、フローチャート用いて示す。このフローチャートは、ステップ１４０３を示す。
【０１５４】
まず、サーバは、ステップ１７００において、マニフェストファイル内の要求されたセグメントを識別する。要求は、このセグメントの識別された「ｒｅｑＳｅｇｌｄｘ」を含む。
【０１５５】
マニフェストファイルＭＰＤ内の各々のノード種別に対して、指標値が、各ノードに対して属性付けられる。値は、マニフェストファイル内での出現順において各々のノードごとに増加される。
【０１５６】
次に、要求されたセグメント（すなわちＧＥＴ要求において指定されたセグメント）に対応するＰｅｒｉｏｄ、ＡｄａｐｔａｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、およびＳｅｇｍｅｎｔＵＲＬのインデックスは、要求されたセグメントに到達されるまで、全体のＭＰＤを解析することによって取りだされる。
【０１５７】
プッシュポリシー内に定義されたプッシュ属性のオペレータおよびオペランドの値は、（「＋」または「−」オペレータに関連付けられている場合に、プッシュされるセグメントの量を定義するＳｅｇｍｅｎｔｌｄｘ属性を除いて）プッシュされるセグメントがどのノード内で定義されるのかを識別するために用いられる。
【０１５８】
オペレータが指定されない場合は、オペランド値は、プッシュされるデータを検索しなければならないＮｏｄｅのインデックスを識別する。例えば、第１のプッシュ属性「Ｓｅｇｍｅｎｔｌｄｘ」がオペレータを有しない場合には、それは、プッシュされる特定セグメントの、記述ファイル内部の、識別子である。１つの代替案において、オペレータが指定されないと、オペランド値は、範囲値を識別してもよく、例えば、「Ｓｅｇｍｅｎｔｌｄｘ＝２−５」は、２、３、４および５に等しいインデックスでセグメントを返すだろう。
【０１５９】
そうでなければ（オペレータが指定されている）、オペランド値は、要求されたセグメント（ステップ１７００において取得された「ｒｅｑＳｅｇｌｄｘ」）のインデックスに対して適用するために（「ｉｄｘＯｆｆｓｅｔ」と命名される）オフセット値を表現する。そのような場合、プッシュされるセグメントは、もしオペレータが「＋」ならば［ｒｅｑＳｅｇｌｄｘ，ｒｅｑＳｅｇｌｄｘ＋ｉｄｘＯｆｆｓｅｔ］範囲、そしてもしオペレータが「−」ならば［ｒｅｇＳｅｇｌｄｘ−ｉｄｘＯｆｆｓｅｔ，ｒｅｇＳｅｇｌｄｘ］内に備えられたインデックスとともにノード内にあるはずである。オペレータの使用は、記述ファイル内部の第１のメディアデータの対応するメディアデータ属性（単数または複数）に対する第２の非要求メディアデータのメディアデータ属性（単数または複数）を定義することを可能にする。
【０１６０】
例えば、以下のプッシュポリシーを考えてみよう。
１．＜ＰｕｓｈＰｏｌｉｃｙ  Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｌｄｘ＝“−１”  Ｓｅｇｍｅｎｔｌｄｘ＝“２”／＞
２．＜ＰｕｓｈＰｏｌｉｃｙ  Ｐｅｒｉｏｄｌｄｘ＝“＋１”  Ｓｅｇｍｅｎｔｌｄｘ＝”＋２／＞
３．＜ＰｕｓｈＰｏｌｉｃｙ  Ｐｅｒｉｏｄｌｄｘ＝“＋０”  Ｓｅｇｍｅｎｔｌｄｘ＝”＋２／＞
ＰｕｓｈＰｏｌｉｃｙ＃１は、要求されたセグメントのリプレゼンテーションノードに先行するリプレゼンテーションノード内のインデックス２のセグメントをサーバがプッシュすることになる、ということを指定する。
【０１６１】
ＰｕｓｈＰｏｌｉｃｙ＃２により、サーバは、現在の期間または以降において、要求されたセグメントに続く２つのセグメントをプッシュすることになる。例えば、図２４のセグメント２４０１を要求すると、セグメント２４０５および２４０２がプッシュされることになる。
【０１６２】
ＰｕｓｈＰｏｌｉｃｙ＃３は、ＰｕｓｈＰｏｌｉｃｙ＃２に対して非常に類似し、主な差は、要求されたセグメントがＰｅｒｉｏｄの最後から２番目の時のものである。例えば、２４０１を要求する場合、現在の期間における最後セグメント２４０５のみが（２つのセグメントの代わりに）プッシュされることになる。ＰｕｓｈＰｏｌｉｃｙ＃３により、Ｐｅｒｉｏｄｌｄｘは、要求されたセグメントのＰｅｒｉｏｄノードに対してセグメント検索を制限しており、したがって、（要求されたセグメントがＰｅｒｉｏｄ内の最後から２番目のセグメントであるので）Ｐｅｒｉｏｄの最後のセグメントのみがプッシュされる。それどころか、ＰｕｓｈＰｏｌｉｃｙ＃２により、セグメントは、次の期間から取りだすことができる。
【０１６３】
代替案において、またはオプションの値として、オペランドの値は、また、あらゆるセグメントがプッシュされるべきであるということを意味する「＜＊＞」（ワイルドカードを意味する）であってもよい。オペレータ「＋」（それぞれ「−」）に関連付けられていると、それは、要求されたものに対して後続する（各々が先行する）すべてのセグメントがプッシュされるべきであるということを意味する。
【０１６４】
この代替案は、クライアントがＰｕｓｈＰｏｌｉｃｙ：＜ＰｕｓｈＰｏｌｉｃｙ  Ｐｅｒｉｏｄｌｄｘ＝“＋０”Ｓｅｇｍｅｎｔｌｄｘ＝“＋＜＊＞”＞により、例えば１つのＰｅｒｉｏｄのセグメントをすべて取りだす、単一のＨＴＴＰ要求のみを送信することを可能にする。
【０１６５】
これらの例において、要求された第１のメディアデータに対する（プッシュされる）第２のメディアデータを識別するＳｅｇｍｅｎｔｌｄｘ属性の使用は、第２のメディアデータが第１のメディアデータに隣接することを必要とする。実施形態において、Ｓｅｇｍｅｎｔｌｄｘ属性は、要求されたセグメントのインデックスに適用するために（オペランドに加えて）オフセットを含んでもよい。これは、所定量のセグメントをプッシュしなければならない基準セグメントのインデックスをシフトする。例として、Ｓｅｇｍｅｎｔｌｄｘ属性の構文は、次のとおりであっても良い。
【０１６６】
プッシュ属性：［オペレータ］オペランド［，オフセット］（ｐｕｓｈ  ａｔｔｒｉｂｕｔｅ：［ｏｐｅｒａｔｏｒ］ｏｐｅｒａｎｄ［，ｏｆｆｓｅｔ］）
ここで「オフセット」は、要求されたセグメントインデックスに適応するために０とは異なる正または負の整数である。そのような場合、サーチ範囲は、オペレータが「＋」であれば［ｒｅｑＳｅｇｌｄｘ＋ｏｆｆｓｅｔ，ｒｅｑＳｅｇｌｄｘ＋ｉｄｘＯｆｆｓｅｔ＋ｏｆｆｓｅｔ］、およびオペレータが「−」であれば［ｒｅｑＳｅｇｌｄｘ−ｉｄｘＯｆｆｓｅｔ＋ｏｆｆｓｅｔ，ｒｅｑＳｅｇｌｄｘ＋ｏｆｆｓｅｔ］である。
【０１６７】
プッシュポリシーの構文は、また、プッシュされているプレゼンテーション内に最大サイズのデータまたは時間のような（非制限的な）条件をそれぞれ含むことができる。例えば、
＜ＰｕｓｈＰｏｌｉｃｙ  Ｓｅｇｍｅｎｔｌｄｘ＝’＋＜＊＞［ｓｉｚｅ＜５０００００］’＞は、多くとも５００キロバイトのセグメントデータをプッシュするプッシュポリシーを定義する。
【０１６８】
＜ＰｕｓｈＰｏｌｉｃｙ  Ｓｅｇｍｅｎｔｌｄｘ＝’＋＜＊＞［ｔｉｍｅ＜０：０１：３０］’＞は、多くとも１分３０秒の次のセグメントデータを転送するプッシュポリシーを定義する。
【０１６９】
上記の例が、どのセグメントをプッシュしなければならないのかを判定するプッシュポリシーを宣言する方法を示している一方で、セグメントがプッシュされることになる好ましい順序を指定する必要もあるかもしれない。この情報も、クライアントとサーバとの間で共有されるべきである。
【０１７０】
例として、図７〜図１２を参照して上記したプッシュされたセグメントの送信の順序の宣言を、適用することができる。
【０１７１】
プッシュされたセグメントの送信の順序の１つの代替の実施形態において、記述ファイル内の記述情報は、メディアデータに関連付けられたプライオリティ属性を含み、各々のメディアデータごとに１つのプライオリティ属性（例えば「ｐｒｉｏｒｉｔｙｌｄｘ」）があり、第２のメディアデータの送信の順序は、関連するプライオリティ属性に基づく。記述ファイルの送信のおかげで、クライアントは、また、これらのプライオリティ属性によって得られた値に気づいており、したがって、意図された送信の順序を決定することができる。
【０１７２】
図１６の例に示されるように、マニフェストファイル内に記述される各セグメント（例えば、１つのＳｅｇｍｅｎｔＵＲＬノードによって識別される）は、セグメントのプッシュ順序を指定するｐｒｉｏｒｉｔｙｌｄｘ属性（１６０４）を含む。図１６の例において、セグメント１６０３は、セグメント１６０２の前にプッシュされる。これらのプライオリティは、サーバ側においてメディアセグメントの準備の間に算出される。異なるプライオリティ値が使用出来る：３２ビット数として、Ｐｅｒｉｏｄプライオリティのための４最上位ビット、ＡｄａｐｔａｔｉｏｎＳｅｔプライオリティ値のための次の４ＭＳＢ、リプレゼンテーションプライオリティ値のための次の８ビット、およびセグメントプライオリティのための最下位１６有効ビットをもつ（図１６のような）所定のＲｅｐｒｅｓｅｎｔａｔｉｏｎ内の相対プライオリティ値または絶対プライオリティ値のいずれかを用いることができる。絶対プライオリティ値を示す別な方法は、プライオリティ値のコンマ区切りリストを用いることであり、上記の引用されたレベルの各々の１つは、例えば、Ｐｅｒｉｏｄプライオリティ、ＡｄａｐｔａｔｉｏｎＳｅｔプライオリティ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎプライオリティ、そしてセグメントプライオリティを連続的に定義するｐｒｉｏｒｉｔｙｌｄｘ＝’１，１，２，１’である。第１の実施形態は、以下の３２のビット値（バイナリ型）により与えるだろう。
【０１７３】
ｐｒｉｏｒｉｔｙｌｄｘ＝’０００１０００１００００００１００００００００００００００００１’
ｐｒｉｏｒｉｔｙｌｄｘ値を用いる主な効果は、個別のＲｅｐｒｅｓｅｎｔａｔｉｏｎ（通常は、ビデオの代替ビューなどの関連リプレゼンテーション）からセグメント間のプライオリティ順を定義することを可能にすることである。プッシュポリシーが個別のＲｅｐｒｅｓｅｎｔａｔｉｏｎセットのセグメントの送信にあると有用である。１つの層からのセグメントが１つ以上の他の層をもつセグメントによりインターリーブされる場合、通常の使用事例は、層状ビデオ（マルチビューにおけるビューである層またはスケーラブルビデオにおけるスケーラビリティ層）のストリームのためのものである。
【０１７４】
図１７に戻り、サーバは、ＭＰＤファイル内に定義されるようなプッシュポリシーに基づいて、ステップ１７０１において、プッシュされるセグメントの数を決定する。この数は、Ｓｅｇｍｅｎｔｌｄｘ属性値から直接推測される。すなわち、オペレータが属性値内で用いられなければ、この数は１に等しく、そうでなければ（オペレータは「−」または「＋」である）、数は、オペランド値に等しく、オペランドが「＜＊＞」であれば無限である（但し他の制約によって、および既存のセグメントの数によって、限定される）、と想定される。
【０１７５】
次に、プッシュするセグメントの数がプッシュされるセグメントの各々をマークするところに達する（テスト１７０２）まで、ステップ１７０２〜１７０５から構成される反復処理は、ストリーミングサーバによって適用される。
各々の反復に対して、サーバは、ステップ１７０３において、ＰｕｓｈＰｏｌｉｃｙ制約（Ａｄａｐｔａｔｉｏｎ  Ｓｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、Ｐｅｒｉｏｄ、およびＳｅｇｍｅｎｔ制約およびオプションの条件）に関する、ＭＰＤファイル内に定義されたセグメントのリストを取りだす。
【０１７６】
セグメントのリストが空であるか、またはすべてのセグメントが既にマークされていれば（テスト１７０４）、処理は終了し、サーバはクライアントの要求に対して応答を送信し始める（上記のステップ１０２）。
【０１７７】
そうでなければ、リストの第１のセグメントは、ステップ１０３（ＰＵＳＨ＿ＰＲＯＭＩＳＥ）および１０４（プロミスされたセグメント）の間にプッシュされるのと同様に、ステップ１７０５においてマークされる。
【０１７８】
プッシュポリシーを宣言する、これらのＭＰＤに基づく例において、１つのプッシュポリシーは、ＰｕｓｈＰｏｌｉｃｙ要素を用いて定義される（図１６の１６００を参照）。
【０１７９】
記述ファイルが、複数のメディアデータ属性レベル（すなわち、以上で定義されたＰｅｒｉｏｄ、ＡｄａｐｔａｔｉｏｎＳｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ要素）を用いて、メディアデータを記述することが、ここで想起される。
【０１８０】
上記のものに対するわずかな変形として、様々な共有されたプッシュポリシーは、様々なそれぞれのレベルの記述ファイルにおいて定義されてもよい。これは、メディアストリームのコンテンツに対してプッシュ戦略を適応するために、関係するレベル（Ａｄａｐｔａｔｉｏｎ  Ｓｅｔ、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ、Ｐｅｒｉｏｄ）に依存する様々なプッシュポリシーを定義することができる、ということである。
【０１８１】
これは図２３を通じて示され、ここで、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎレベルにおいて、プッシュポリシーが、所望のレベルにて、例えば「ＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ」記述子を用いて定義される。
【０１８２】
＜ＭＰＤ＞レベルごとにプッシュポリシーを用いることは、メディアにわたって定数および同じプッシュ戦略を有することを可能にする。
【０１８３】
＜Ｐｅｒｉｏｄ＞レベルごとにプッシュポリシーを用いることは、時間に沿って変化できるプッシュ戦略を有することを可能にする。
【０１８４】
＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞レベルごとにプッシュポリシーを用いることは、メディアに適したプッシュ戦略を有することを可能にする。
【０１８５】
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞レベルごとにプッシュポリシーを用いることは、メディア特性（帯域幅…）に適することができるプッシュ戦略を有することを可能にする。
【０１８６】
図２３の例において、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎレベルにおいて指定されるプッシュポリシーは、プッシュデータとともにあまりにも多くの帯域幅を用いないようにするために、高いビットレートのビデオ（２３０１）よりも低ビットレートビデオセグメント（２３００）のために、よりさらにセグメントをプッシュするように構成される。
【０１８７】
プッシュ属性の構文に関しての上記の説明も、また、このわずかな変形に適用されてもよい、ということに留意されたい。特に、プッシュポリシーは、新たな要素（図１６のように）としてマニフェストにおいて、または（図２３のように）新たなｓｃｈｅｍｅｌｄＵｒｉにより既存の記述子を用いて、または（表現されていない）新たな記述子として、またはＭＰＤスキーマ若しくはＭＰＤスキーマの拡張ポイントに適合するいずれかの手段として、信号で送ることができる。
【０１８８】
ＭＰＤは、また、各自が一意の識別子を有する、代替的なＰＵＳＨポリシーのリストを含むこともできる（以下のリストに関するさらなる説明を参照）。
【０１８９】
他の代替の実施形態において、プッシュポリシーは、相補的なＲｅｐｒｅｓｅｎｔａｔｉｏｎのためのセグメントが系統的にプッシュされる、ということを、例えば以下の構文を用いて定義してもよい。
【０１９０】
＜ｐｕｓｈ＿ｐｏｌｉｃｙ  Ｓｅｇｍｅｎｔｓ＝’＋ｃｏｍｐｌｅｍｅｎｔａｒｙ’＞または、ＤＡＳＨ記述子を用いる場合は、ｖａｌｕｅ＝’ｃｏｍｐｌｅｍｅｎｔａｒｙ’層状ビデオの場合には、これは、要求されたビデオセグメントに対して、相補的なＲｅｐｒｅｓｅｎｔａｔｉｏｎとして宣言されるすべてのＲｅｐｒｅｓｅｎｔａｔｉｏｎから同時に各セグメントも（通常は、異なるＲｅｐｒｅｓｅｎｔａｔｉｏｎ間の依存性を信号で送るＭＰＤ内のｄｅｐｅｎｄｅｎｃｙｌｄ属性を通じて）プッシュされるだろう、ということを意味する。
【０１９１】
別のプッシュポリシーは、また、＠ａｓｓｏｃｉａｔｉｏｎｌｄ属性またはｒｏｌｅ＝’ｓｕｐｐｌｅｍｅｎｔａｒｙ’により信号で送られる、関連するＲｅｐｒｅｓｅｎｔａｔｉｏｎからのセグメントのプッシュにある。
【０１９２】
完全にサーバで駆動されるストリーミングの場合には、プッシュポリシーは、サーバ挙動が「積極的」（若しくは「楽観的」）または「保守的」でなければならないか否かの情報、すなわち、それぞれ高品質のセグメントをプッシュしようとする、または同じ品質レベル（帯域幅を維持する）でプッシュしようとするか否かの情報を提供することができるであろう。
【０１９３】
他の実施形態において、プッシュポリシーは、専用のＨＴＴＰヘッダとして見なされる「プッシュポリシー」ヘッダ内で送信される。すなわち、共有されるプッシュポリシーを記述するプッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されたＨＴＴＰフレームのヘッダ内に埋め込まれる。
【０１９４】
これらの実施形態は、上記のように、それらがもはやＭＰＤファイルの送信に依存せず、クライアントおよびサーバがＨＴＴＰ／２プロトコルを用いて交換するので、プッシュポリシーを経時的に変化させることを可能にする。
【０１９５】
図１８は、ＨＴＴＰ「プッシュポリシー」ヘッダ（ヘッダ名「プッシュポリシー」は、単なる例である）内で送信されるプッシュポリシーでの、サーバとクライアントとの間の通信の例である。
【０１９６】
プッシュポリシーヘッダは、プッシュ属性のリスト（プッシュされるデータ上の制約を各々定義する）を含む。特に、先に記述されたＰｕｓｈＰｏｌｉｃｙの構文は、ＨＴＴＰヘッダ構文に書き換えられてもよい。
【０１９７】
図１８ａにおいて、クライアント（矢印１８００）からのＭＰＤ要求に応答してサーバは、プッシュポリシーを共有するために、送信されたＭＰＤに伴うＨＴＴＰヘッダ内のプッシュポリシーを送信する（ステップ１８０１）。
【０１９８】
例えば、プッシュポリシーは、要求されたセグメントを追従するセグメントがプッシュされることになる、ということを指定する。結果として、クライアントがセグメントデータ１．１を要求する（矢印１８０２）と、サーバは、セグメントデータ２．１のためのＰＵＳＨ＿ＰＲＯＭＩＳＥと（矢印１８０３）、そしてセグメントデータ１．１（矢印１８０４）のデータを送信する。
【０１９９】
後続のセグメント要求のためにどのデータが送信されようとするのかを定義するために、任意の構文：ＭＰＤ特有のものまたはＤＯＭツリーノードトラバースに基づいたより抽象的なものを用いることができる。
【０２００】
動的に共有されたプッシュポリシーに専用の特定の実施形態において、クライアントは、特定のプッシュポリシーを要求してもよい。すなわち、例えば現在共有されたプッシュポリシーがそのニーズに適していなければ、共有されたプッシュポリシーを更新してもよいし、または改善してもよい。
【０２０１】
それは、クライアント装置がＨＴＴＰフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報をサーバ装置に対して送信する、ということを意味する。それに対応して、サーバ装置は、ＨＴＴＰフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報をクライアント装置から受信する。サーバ装置は、したがって、クライアント装置（例えば次の要求のための）によって要求された他のメディアデータから非要求メディアデータを決定する前に、共有されたプッシュポリシーをそれに応じて更新してもよい。
【０２０２】
実施形態において、クライアントからのプッシュポリシー要求は、「プッシュポリシー要求」という名の（ここでの名称は単なる例である）ＨＴＴＰヘッダまたは要求内で伝達される。
【０２０３】
図１８ｂは、クライアントが新たなプッシュポリシーを要求した場合のクライアント・サーバ間の例示的な交換を示す。
【０２０４】
交換の始まりは、図１８ａと同じである。
【０２０５】
セグメントデータ２．１を受信した後、クライアントは、例えば利用可能な帯域幅が、セグメント要求に応答してさらなるセグメントをサーバにプッシュさせるのに十分に安定しているので、現在のプッシュポリシーが修正されるべきである、ということを識別する。
【０２０６】
結果として、クライアントは、ステップ１８０５において、各々の新たな要求毎に、さらなるセグメント（１の代わりに３）をプッシュするようにサーバに依頼するプッシュポリシー要求を送信する。
【０２０７】
サーバは、ステップ１８０６において、ＯＫ２００によりこのプッシュポリシー要求に肯定的に回答する。この肯定的な回答は、同じクライアントからいずれかの新たな要求に対するプッシュポリシー要求内に記述された新たなプッシュポリシーをサーバが用いることになる、ということを意味する。
【０２０８】
サーバがそのプッシュポリシーを変更したくないならば、それはプッシュポリシー要求が拒否されている、ということをクライアントに通知するためのエラーコード回答を返す。
【０２０９】
次に、クライアントが、ステップ１８０７において、次のセグメントデータ３．１を要求すると、サーバは、ステップ１８０８において、次の３つのセグメントデータ４．１、データ５．１、およびデータ６．１に対してＰＵＳＨ＿ＰＲＯＭＩＳＥにより回答する。
【０２１０】
図２１は、プッシュポリシーの共有のためにＨＴＴＰ要求を用いる場合のサーバ側における処理のステップを、フローチャート用いて示し、その一方で、図２２は、プッシュポリシーを共有するためにＨＴＴＰ要求を用いる場合のクライアント側における処理のステップを、フローチャートを用いて示す。
【０２１１】
図１４の処理との比較において、サーバは、クライアントからのプッシュポリシー要求を取り扱い、かつまた初期のプッシュポリシーを送信してそれを更新する、新たな処理ステップ（２１００〜２１０５）を含む。
【０２１２】
サーバによって受信された要求がクライアントからのプッシュポリシー要求であるならば（テスト２１００）、サーバは、まず、クライアントによって提案されたデータプッシュの制約を抽出するために、ステップ２１０１において、プッシュポリシー要求を解析する。
【０２１３】
このステップの間、サーバは、クライアントによって要求されたプッシュポリシーに従うことを決定してもよい。そのような場合、サーバは、その内部のプッシュポリシーを更新し（ステップ２１０２）、提案されたプッシュポリシーを検証するために、ステップ２１０３において、クライアントに対してＯＫ２００の応答を送信する。
【０２１４】
そうでなければ、サーバがプッシュポリシーを廃棄すると（例えば提案されたポリシーがリソースの観点からコストのかかりすぎる、または適用することができないので）、ステップ２１０２ではサーバにおいて内部プッシュポリシーを修正しない。また、エラーコードが、ステップ２１０３において、クライアントに対して送信される。
【０２１５】
具体的な実施形態によれば、サーバは、クライアントの要求とは無関係に、そのプッシュポリシーをさらに更新してもよい。そのような場合、サーバは、ステップ１４０２の間に、プッシュポリシーを決定し、その特性（例えばクライアントおよびネットワークの特性によって実行された要求の解析による）を変更することを決定しても良いし、または、決定されたプッシュポリシーが現在のものとは異なるということを理解しても良い。このような状況において、サーバは、後者がそれにまだ気づいていなければ（テスト２１０４）、クライアントと新たなプッシュポリシーを共有しなければならず、その場合には、新たなプッシュポリシーは、ステップ２１０５において、ＨＴＴＰヘッダ内で送信される。
【０２１６】
クライアント側の対応する処理は、図２２を参照して説明される。サーバ処理に関して、新たな処理ステップ（２２００〜２２０４）は、図１４の処理との比較において、プッシュポリシーメッセージを処理し、且つプッシュポリシー要求を実行するために追加される。
【０２１７】
ステップ１４００において、現在の共有されたプッシュポリシー（すなわちサーバのプッシュポリシー）を決定した後に、クライアントは、例えば、メディアストリームのセグメントを取りだすために送信するＨＴＴＰ要求の数を低減するために、新たなプッシュポリシーを要望してもよい。したがって、新たなプッシュポリシーがクライアントによって要求されると（テスト２２００）、クライアントは、ステップ２２０１において、先に記述されたような「プッシュポリシー要求」によりＨＴＴＰ要求を送信する。
【０２１８】
この要求に対する応答は、ＯＫ２００の応答またはそうでなければエラーコードを返すことによって、サーバが要求を有効にするか否かをクライアントがチェックするステップ２２０４において処理される。
【０２１９】
サーバがＯＫ２００の応答を返せば、ステップ１４００において、決定された現在のプッシュポリシーが、要求されたポリシーと置き換えられる。そうでなければ、それはそのまま変更されない。
【０２２０】
図１４の処理に加えて、クライアントがサーバから新たなプッシュポリシーでフレームを受信すると（テスト２２０２）、プッシュポリシーは、ステップ１４００の次のオカランスで取りだされるために解析され、メモリ内に保存される（ステップ２２０３）。
【０２２１】
プッシュポリシー要求がまた他のデータ（例えばメディアデータ）も含むフレーム内にあると、他のデータが、ステップ１０９〜１１１〜１１３〜１１５を通じて処理される、ということに留意すべきである。
【０２２２】
上記のＨＴＴＰに基づいた例は、適用されるプッシュポリシーを完全に定義するためにＨＴＴＰ要求を用いるが、１つの具体的な実施形態は、クライアントとサーバ側の両方において１セットの予め定義された同じプッシュポリシーを有し、各々が一意の識別子を有することを定義することに依存してもよい。この場合、ＨＴＴＰ要求は、セットの中から用いられるプッシュポリシーの識別子を指定するためにのみ用いられる。この具体的な実施形態は、ＨＴＴＰ要求のサイズを減少させる。
【０２２３】
１つの実施形態において、プッシュポリシー要求は、サーバリソースの１つを要求するために用いられるＨＴＴＰ要求の１つの付加的なＨＥＡＤＥＲとして送信され、通常は、プッシュポリシー要求は、ＭＰＤファイルに対するＧＥＴ要求における「受理プッシュポリシー」ＨＴＴＰヘッダ内で送信される。
【０２２４】
別の実施形態において、クライアントは、クライアントによって支持される（または必要とされる）プッシュポリシーのリストを示すために１つのＨＴＴＰ要求においていくつかの「Ａｃｃｅｐｔ−Ｐｕｓｈ−Ｐｏｌｉｃｙ」を指定する。ＨＴＴＰ要求に応答して、サーバは、提案されたリスト内のプッシュポリシーの１つを選択し、そして、ＨＴＴＰ応答内のプッシュポリシーを指定してもよいし、または、どれもサッポートされなければ、新たなプッシュポリシーによって応答してもよい。
【０２２５】
さらに別の実施形態において、プッシュポリシー要求は、サーバによって認識されるあらゆるリソースの独立した専用のＨＴＴＰ要求において送信される。例えば、ＧＥＴ（またはＰＯＳＴ）要求は、ウェブページのリソースのどれにも対応しないＵＲＬ、例えばｈｔｔｐ：／／ｓｅｒｖｅｒ／ｐｕｓｈ＿ｐｏｌｉｃｙと、さらに少なくとも１つのＡｃｃｅｐｔ−Ｐｕｓｈ−Ｐｏｌｉｃｙヘッダとにより形成される。
【０２２６】
さらに別の具体的な実施形態において、代替的なプッシュポリシーのセットは、各々が一意の識別子を有する、サーバとクライアントとの間で交換されたＭＰＤファイル内で定義されてもよい。プッシュポリシーの１つは、サーバによって選択されるデフォルトプッシュポリシーとしてマークされてもよい。クライアントは、デフォルトプッシュポリシーの交換に用いられるプッシュポリシーの識別子を含む新たなプッシュポリシー要求を送信することによって、どのプッシュポリシーが用いられるべきであるのかを指定してもよい。
【０２２７】
１つの実施形態において、特定のプッシュポリシーは、高速起動のためにＭＰＤドキュメントに対する要求直後に、どのセグメントがプッシュされるのかを示すために定義される。
【０２２８】
ハイブリッドアプローチにおいて、共有されるプッシュポリシーを記述するプッシュポリシー情報は、第１のプッシュポリシー部および第２のプッシュポリシー部によって定義され、第１のプッシュポリシー部は、記述ファイル（ＭＰＤ）内に挿入され、第２のプッシュポリシー部は、サーバ装置からクライアント装置に対して送信されるＨＴＴＰフレームのヘッダ内に埋め込まれる。
【０２２９】
例えば、ＭＰＤは、プッシュポリシーＨＴＴＰ要求のおかげでサーバによってその後定義される（またはさらにオーバーロードされる）テンプレート引数によりプッシュポリシーを定義してもよい。例として、ＭＰＤファイル内に定義されたプッシュポリシーは、＜ＰｕｓｈＰｏｌｉｃｙ  Ｓｅｇｍｅｎｔｌｄｘ＝”ｐａｒａｍｅｔｅｒ７＞であってもよく、変数「パラメータ」の値は、プッシュポリシーＨＴＴＰ要求において定義されてもよい。この例において、第２のプッシュポリシー部は、第１のプッシュポリシー部内に定義された１つ以上の関連変数に対する１つ以上の値（のみ）を有する。
【０２３０】
上記のプッシュポリシー識別子ベースのアプローチを用いて、記述ファイルは、複数の候補プッシュポリシーの記述を含んでもよく、第２のプッシュポリシー部は、それにより前記複数からの候補プッシュポリシーの識別子を備えてもよく、識別された候補プッシュポリシーは、それによって第１のプッシュポリシー部を形成する。
【０２３１】
クライアントに対してプッシュポリシーを宣言するための別の実施形態において、プッシュポリシーは、プッシュデータが選択されることになるリプレゼンテーションを示すＭＰＤ内に定義された〈Ｒｏｌｅ〉記述子に依存する。通常は、プッシュポリシーは、プッシュ戦略が「代替」または「追加」のロール値をもつＲｅｐｒｅｓｅｎｔａｔｉｏｎ内のセグメントを用いることになる、ということを指定してもよい。
【０２３２】
別の実施形態において、例えばストリーミングマニフェスト、ＨＴＭＬページなどのリソースのドキュメントは、ＧＥＴ要求が受信された後にプッシュされるリソースを決定するために閲覧されるプライオリティツリーに変換される。プライオリティツリー内部のナビゲーションは、ＸＰａｔｈ要求のおかげで実行することができる。このアプローチにおいて、プッシュポリシー情報は、第２の非要求メディアデータを識別するリソースのドキュメントのツリー表現上で評価される、ＸＰａｔｈ式を含む。
【０２３３】
例えば、ストリーミングマニフェストにおいて、「ｆｏｌｌｏｗｉｎｇ［ｎａｍｅ（）＝“ＳｅｇｍｅｎｔＵＲＬ”］［２］」のＸＰａｔｈ式は、プッシュされるセグメントとして、ＧＥＴ要求内のクライアントによって要求されたセグメントに続く２つのセグメントを選択するために用いることができる。また、チャプターを切り替える使用事例に関して、「（（ｆｏｌｌｏｗｉｎｇ［ｎａｍｅ（）＝“Ｐｅｒｉｏｄ”］／／ＳｅｇｍｅｎｔＵＲＬ）［２］）」のＸＰａｔｈ式は、各チャプターの最初の２つのセグメントを予めローディングするために後続のＰｅｒｉｏｄの最初の２つのセグメントを選択することを可能にする。例えば、クライアントが図２４のＭＰＤファイル内のセグメント２４０１を要求すると、後続のＰｅｒｉｏｄのセグメント２４０２および２４０３も、プッシュされたデータとしてサーバによって送信される。
【０２３４】
さらに、高度なプッシュポリシールールのために書くＸＰａｔｈ式を単純化するために、例えばＸＳＬＴ命令を用いて、プライオリティツリーをまず再順序付けることができるかもしれない。ＸＳＬＴ命令は、プッシュポリシーを適用する前にツリーを再編成することを可能にする。ＸＰａｔｈ式は、好ましくは、クライアントに対して、例えば１つのＨＴＴＰヘッダ内で送信され、ＸＳＬＴスタイルシートは、ウェブページ内で定義される。これは、例えばドキュメント内の宣言するすべての画像、ＤＯＭツリーの同じレベルにおける連続するノードのようなすべてのＣＳＳリソース、をグループ化するために、特にＨＴＭＬドキュメントに適用する。
【０２３５】
例えば、図２５のツリー２５０１は異なるタイプの異なるリソースも持つＨＴＴＰ頁を表し、ハッシュされたノード（２５１１〜２５１４）は、画像リソースに対応し、単色のノード（２５２１−２５２４）は、スクリプトリソース（ＣＳＳまたはＪａｖａ（登録商標）ｓｃｒｉｐｔ）である。ツリー２５０２は、タイプによってリソースをグループ化するＸＳＬＴ変換結果の例である（２５３０における画像および２５４０におけるスクリプトリソース）。簡単なＸＰａｔｈ式は、したがって、一旦この所定のタイプの第１のリソースが要求されれば、所定のタイプのためのいくつかのリソースがプッシュされることになる、ということを示すために、定義することができるかもしれない。
【０２３６】
以上に記述されたすべての実施形態において、いくつかのセグメントがプッシュされることをプッシュポリシーが要求するならば、各々のクライアントに対していくつかのＰＵＳＨ＿ＰＲＯＭＩＳＥでのサーバ返信を要求する、という可能性が非常に高い。
【０２３７】
例えば、図１９のＭＰＤ１９００は、要求されたセグメントに追従する３つのセグメントがプッシュされることになるということを示すプッシュポリシーを有する（＜ＰｕｓｈＰｏｌｉｃｙ＞要素を参照）。従って、クライアントが０〜９９９に等しいバイト単位の範囲でメディア１９０１に対するＧＥＴ要求によりイニシャライゼーションセグメントを要求すれば、サーバは、ステップ１０３の間に、３つのＰＵＳＨ＿ＰＲＯＭＩＳＥメッセージに１９０２を送信することになる。
【０２３８】
１つの実施形態において、識別された第２のメディアデータの各々がアナウンスメッセージ（すなわちＰＵＳＨ＿ＰＲＯＭＩＳＥ）を要求する複数のメディアセグメントを備える場合、対応する複数のアナウンスメッセージは、クライアント装置に対して送信される単一のアナウンスメッセージにマージされてもよい。
【０２３９】
図２０に示されるように、この状況を実現するために、サーバにおける処理は、好ましくは、図１４の一般的な処理と比較して、ステップ１０３においてプッシュプロミスを送信する直前に前処理ステップ２０００を含む。前処理ステップは、アナウンスメッセージの上記のマージを実行しようと努める。
【０２４０】
プッシュプロミスが１９０２のようにバイト単位の範囲の要求を含むと、プッシュプロミスのリスト１９０２は、連続するバイト単位の範囲のアドレスを含むプッシュプロミス１９０３の減少されたセットを生成するために閲覧される。次に、プッシュプロミス１９０２の各セットは、プッシュプロミスセット内のバイト単位の範囲の連結に等しい連続したバイト単位の範囲でプッシュプロミスの減少されたセットと、または例えば１９０５の不連続のバイト単位の範囲のリストでの単一のプッシュプロミスと置き換えられる。
【０２４１】
例えば、３つのプッシュプロミス１９０２は、図１９に示される単一のプッシュプロミス１９０３と置き換えられる。
【０２４２】
プッシュプロミスをマージするこのアプローチは、クライアントがより簡単な方法で、およびより低い帯域幅および処理コストで、プッシュデータの送信をキャンセルすることを可能にする。これは、マージされていない各々のプッシュプロミスの幾つかのストリームを閉じる代わりに、クライアントが単一のプッシュプロミスのための単一のストリームを閉じるだけで良いからである。
【０２４３】
代替案において、プッシュプロミスが別々なバイト単位の範囲の間隔を有したとしても、プッシュプロミスは、すべて、バイト単位の範囲のリストと置き換えられてもよい（ここで連続するバイト単位の範囲の間隔は連鎖される）。
【０２４４】
さらに、プッシュプロミスがバイト単位の範囲の間隔ではなく、異なるＳｅｇｍｅｎｔＵＲＬ値を含む場合、プッシュプロミスも、また、以下の通り単一のプッシュプロミスメッセージを生成するために連鎖されてもよく、生成されたプッシュプロミスメッセージの方法はＭＧＥＴ（複数のＧＥＴのための）として定義される。また、パスフィールドは、１９０４に表現されるようなセグメントＵＲＬのリストである。先の実施形態と同様に、クライアントは、すべてのセグメントのプッシュをキャンセルするために生成されたプッシュプロミスに対応する単一のストリームを閉じなければならない。
【０２４５】
クライアントが各プッシュされたセグメントを解析し識別することができることを保証するために、サーバは、その後に送信されるデータ内の各々のセグメントの端部においてＥＮＤ  ＳＥＧＭＥＮＴフラグを含んでもよい、ということに留意されたい。
【０２４６】
さらに、ＨＴＴＰ／２のＳＥＴＴＩＮＧＳフレームは、プッシュプロミスのグループ化がストリーミングセッションのために許可されるか否かを示すことを可能にする、新たなＳＥＴＴＩＮＧＳ＿ＥＮＡＢＬＥ＿ＧＲＯＵＰ＿ＰＵＳＨ＿ＰＲＯＭＩＳＥパラメータを含むために拡張される。
【０２４７】
本発明の実施形態は、１回または複数回のラウンドトリップを回避することができるので、ＤＡＳＨ高速起動を有することを可能することができる。ここで、図２６〜図２８を参照して、本発明のこの態様を、説明する。
【０２４８】
ＤＡＳＨ高速起動機能は、図７〜図１２および図１４〜図２５のすべてまたは一部を参照して、上記された何れの通信アプローチとともに用いられてもよい。
【０２４９】
図２６は、ＤＡＳＨ高速起動を取得するために、本発明の教示によるサーバによって、およびクライアント装置によって、それぞれ実施される例示的な方法を示す。
【０２５０】
まさに記載された標準プロセスに関して、第１のステップは、クライアントが記述ファイル、ここではＭＰＤファイル、を要求するためにある（ステップ２６５０）。そして、クライアントは、サーバの応答を待つ（ステップ２６５１）。
【０２５１】
その間に、サーバは、以下に説明されるように、特にクライアントがより高速に開始するのを支援するイニシャライゼーションデータを識別するために（ステップ２６５３）ＭＰＤファイルを解析する（ステップ２６５２）。ステップ２６５３の例示的な実施形態は、図２７を参照して、以下に説明する。
【０２５２】
一旦イニシャライゼーションデータがサーバによって識別されれば、クライアントの要求を待たずに、イニシャライゼーションデータをプッシュするその意図を示すために、ステップ２６５４において、クライアントに対してＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを送信する。
【０２５３】
場合によっては、それは、また、クライアントが関係するリソース、すなわち、：ｓｃｈｅｍｅ、：ｈｏｓｔ、および：ｐａｔｈなどの関係する初期のメディアデータ、を識別することを可能にするヘッダ部を含む別のＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを送信することによって、初期のメディアデータ（ステップ２６５６）をプッシュすることになる、ということをさらに示す。
【０２５４】
イニシャライゼーションデータのためのＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム、および初期のメディアデータのためのＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの場合、他のヘッダ部も、また、プッシュすることを決定したデータにおいてサーバがどれほど確信しているのかを示すために、サーバによって追加され、本実施形態において、ｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータはＰＵＳＨ＿ＰＲＯＭＩＳＥフレームに関連付けられる（すなわち、ヘッダ内に含まれる）。図２７を参照して、ｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータの決定を以下に説明する。サーバは、また、プッシュするつもりのセグメントを明白に示すために特定のＤＡＳＨヘッダを挿入することができる。
【０２５５】
プッシュされるべきイニシャライゼーションデータおよび第１のメディアデータのためにクライアントが要求することのリスクを最小化するために、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、応答において、いずれかのコンテンツに先立って送信されるべきである。すなわち、ステップ２６５４およびステップ２６５６は、サーバからクライアント装置までＭＰＤファイルを送信するステップ２６５５の前に行われるべきである。
【０２５６】
したがって、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームがクライアント装置に対して送信されると、サーバは、ステップ２６５５において、クライアント装置に対してＭＰＤファイルを送信する。
【０２５７】
その間にサーバがクライアント装置からＣＡＮＣＥＬまたはＥＲＲＯＲのメッセージを受信していなければ、イニシャライゼーションデータ（ステップ２６５７）および第１のメディアデータ（ステップ２６５８）をプッシュし始める。
【０２５８】
ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームおよびサーバからクライアント装置へのデータのプッシュは、例えばドキュメント「ハイパーテキスト転送プロトコルバージョン２．０（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ  ２．０）、ｄｒａｆｔ−ｉｅｔｆ−ｈｔｔｐｂｉｓ−ｈｔｔｐ２−ｌａｔｅｓｆ、ＨＴＴＰｂｉｓ作業部会、インターネットドラフト、２０１３年６月２４日（例えばｈｔｔｐ：／／ｈｔｔｐ２．ｇｉｔｈｕｂ．ｉｏ／ｈｔｔｐ２−ｓｐｅｃ／において利用可能）内に記述されるような、例えばＨＴＴＰ２．０のフレームにおいて展開される、対応する機能にしたがって実行される。
【０２５９】
クライアント装置が受信すると、イニシャライゼーションデータは、復号器を設定する（ステップ２６５９）ためにクライアントによって用いることができ、画面停止なしで十分なデータ量が復号化およびレンダリング（例えば、表示）のために利用可能になるまで、第１のメディアデータは、バッファリングされる（ステップ２６６０）。
【０２６０】
クライアントがＭＰＤファイルを完全に受信し、完全にデータをバッファリングすると（ステップ２６６１）、それを解析して（ステップ２６６２）復号化し表示し始め（ステップ２６６３）。そうでない場合は、クライアント装置が、さらなるセグメントが送信されることを、サーバによって送信されたＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム（ステップ２６５６を参照）から認識するならば、ステップ２６６４において、サーバからの第１のメディアデータのプッシュの完了を待つ。このアイドルステップ２６６４の間、クライアント装置は、既に上で説明されたように、標準的なクライアント制御のＤＡＳＨ（ステップ２６６５）において発行される後続のセグメントのために次の要求を準備してもよい。対応するＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム（上記ステップ２６５６を参照）内のプッシュされる（またはプッシュされている）初期のメディアデータの受信情報をクライアント装置が有するので、これは可能であり、したがって、サーバによってプッシュされると意図された最後の時間セグメントを直後に続く時間セグメントのための要求を準備することができる。
【０２６１】
クライアント装置は、ＭＰＤを全て受信すると、この初期のメディアデータがバッファを満たすか否かをチェックするために、そうでなければ、ステップ２６６１の前の標準的なクライアント制御のＤＡＳＨ処理にしたがって後続のメディアデータ（例えば初期のメディアデータによって表現される時間セグメントに続く時間セグメントに対応するメディアデータ）に対する要求を送信するために、ステップ２６５６において受信された初期のメディアデータの情報を用いてもよい（プッシュされた初期のメディアデータがバッファを満たすケースを示す図２６に示されるものとは逆に）。これは、クライアントが、プッシュする大量の第１のメディアデータの上のサーバから不良な推定を訂正することを可能にする。
【０２６２】
この処理は、ストリーミングクライアントが、標準的マニフェストベースのストリーミングよりも早くメディアを表示し始めることを可能にする。実際は、ネットワーク上のＨＴＴＰラウンドトリップの数がイニシャライゼーションデータおよび／または初期のメディアデータを得るために減少されるので、起動遅延は減少する。
【０２６３】
但し、この処理は、以下の理由から、現在のＤＡＳＨ規格に準拠したままである。
【０２６４】
・ＭＰＤファイルの修正がない。その送信は軽量で高速のままである。
【０２６５】
・標準ＤＡＳＨクライアントの挙動は不変のままである（すなわち、本発明の教示から恩恵を受けない）。このようなクライアント装置は、認識されないＨＴＴＰヘッダを無視するだろう。そして、プッシュ機能を受け入れなければ、さらなる要求／応答を単純に実行しなければならないだろう。したがって、表示を開始するために多くの時間を費やすだろう。
【０２６６】
図２７は、クライアント装置からのマニフェスト（または記述ファイル）に対する要求に追従するサーバ側において実施される例示的な方法説明する。
【０２６７】
この方法は、クライアントがメディアプレゼンテーションの表示を急速に開始することができるように、予めプッシュする最も関連する初期データを識別しようと努める。
【０２６８】
ステップ２７００において、マニフェストに対する要求が受信される。そして、サーバは、クライアント装置が要求内にいくつかのプレファレンスを挿入したか否かを、ステップ２７０１において、チェックする。例えばメディアプレゼンテーションのための送信速度およびオーディオストリームのための好適な言語を表現するためになど、これは、以下の専用のＨＴＴＰヘッダなどを介して行われてもよい。
【０２６９】
ＧＥＴ  ｈｔｔｐ：／／ｍｙｓｅｒｖｅｒ．ｃｏｍ／ｐｒｅｓｅｎｔａｔｉｏｎ／ｐｒｅｓ１．ｍｐｄ  ＼ｒ＼ｎ
Ｐｒｅｆｅｒｅｄ−ＭｅｄｉａＲａｎｇｅ：  ｂｗ＝２０００：ｌａｎｇ＝ＦＲ＼ｒ＼ｎ＼ｒ＼ｎ
要求がプレファレンスを含むならば（テスト２７０１で真）、サーバは、クライアントのプレファレンスを解析し（ステップ２７０３）、そのｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータを値「高」に設定する（ステップ２７０４）。
【０２７０】
表示が要求において提供されないならば（テスト２７０１で偽）、サーバは、このクライアントのサービス利用情報（ログ）（すなわちユーザまたはクライアント装置とサーバとの間の従来の交換に基づく統計値または使用データ）またはＵｓｅｒ−Ａｇｅｎｔヘッダからの情報を既に示しているか否かを、ステップ２７０２において。チェックする。実際は、Ｕｓｅｒ−Ａｇｅｎｔヘッダは、ＲＦＣ２６１６（例えばｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２６１６．ｔｘｔを参照）内のＨＴＴＰヘッダとして定義され、例えばオペレーティングシステム、ブラウザタイプ、アプリケーション名などの情報を交換するアプリケーションのための手段を提供する。例えば、ＤＡＳＨサーバは、サービスを用いることができるようになる前にクライアントに対する認証スキームを有してもよく、変形物において、それは、サービスに対してアクセスする前にロギングするユーザであり得る。このような手段により、サーバは、メディアパラメータを、接続されたユーザまたは装置に対してリンクすることができる。
【０２７１】
前の利用情報（ログ）が、関係するクライアント装置またはユーザが利用可能であると（テスト２７０２で真）、ステップ２７０５においてログを解析することによって、サーバは、所定のクライアントまたはユーザにとっての最も頻度の高い利用方法を推定することができる。例えば、ユーザまたはクライアント装置がＨＤ（高解像度）のフランス語によるオーディオストリームおよびビデオストリームを常に選択する、ということを推定することができる。さらに、サーバは、これがオープンＴＣＰ接続における第１の要求であるか否か（サービスに対して接続され、且つ第２のメディアプレゼンテーションを要求するクライアント）を知ることができる。この場合、帯域幅推定は、さらに正確で且つさらに確実になり得るし、ＴＣＰ輻輳ウィンドウは、第１の要求に対するものよりも大きくなるであろう。これは、適したＲｅｐｒｅｓｅｎｔａｔｉｏｎの観点から、サーバによって行われる選択に影響を与えることができる。
【０２７２】
ＤＡＳＨ品質メトリックを登録することによって、サーバは、そのログ内にユーザ／クライアントが通常実行する様々なリプレゼンテーションの中の変更を持つことができる。このことから、サーバは、通常の挙動を、「積極的（ａｇｇｒｅｓｓｉｖｅ）」または変更の頻度に依存する定数（ｃｏｎｓｔａｎｔ  ｄｅｐｅｎｄｉｎｇ  ｏｎ  ｔｈｅ  ｆｒｅｑｕｅｎｃｙ  ｏｆ  ｃｈａｎｇｅｓ）の間で決定する（いかなる基準：帯域幅、解像度、フレームレート等でも、変更によって、我々は他のＲｅｐｒｅｓｅｎｔａｔｉｏｎに切り換えることを意味する。）。積極的なクライアント（ａｇｇｒｅｓｓｉｖｅ  ｃｌｉｅｎｔ）は、そのコンテキストが変化すると、異なるリプレゼンテーションに自動的に切り替えるＤＡＳＨクライアントである。例として、帯域幅またはバッファ占有期間を監視すると、積極的なクライアントは、現在のＲｅｐｒｅｓｅｎｔａｔｉｏｎと比較して、新たなＲｅｐｒｅｓｅｎｔａｔｉｏｎがクライアントのコンテキストに近い特性を有すると直ちに、異なる帯域幅でＲｅｐｒｅｓｅｎｔａｔｉｏｎを要求することになる。反対に、一定のクライアントは、安定した品質および表示速度を維持するために、頻繁なＲｅｐｒｅｓｅｎｔａｔｉｏｎの切り換えを回避しようとするだろう。ユーザ／クライアント装置挙動が適応の観点からいくぶん積極的であると、サーバは、それがストリーミングを開始するために初期のリプレゼンテーションとして何を選択ようとも、クライアントは、続く最初の数秒または数分間のストリーミングにおいて適応しようとする、ということを知る。
【０２７３】
プレファレンスがログから推定されると、サーバは、ステップ２７０６において、そのｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータを値「中」に設定する。実際は、この情報は、クライアントそれ自体によって信号で送る明示的なプレファレンスよりも関連性が低いかもしれない（テスト２７０１で真）。
【０２７４】
利用可能なログ情報がない場合（テスト２７０２で偽）、サーバは、その時、ステップ２７０７において、そのｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータを最低値「低」にする。これは、決定するべき演繹的な情報がないので、サーバが、プッシュする情報上でベストの推測を実行していることを示す。この場合のさらなる処理を、以下に説明する記載する（ステップ２７１１を参照）。
【０２７５】
このｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータ計算と並行して、サーバは、ステップ２７０８において、マニフェストを解析してもよい。マニフェストが頻繁に変更しがちではない（ライブサービスとは逆に、特にオンデマンドのサービスに対して）場合において、マニフェストの解析は、ルックアップテーブル内の様々なＲｅｐｒｅｓｅｎｔａｔｉｏｎの記述を登録することによって、今回限りで、オフラインで実行することができる。このルックアップテーブルは、また、クライアントのログをメディアプレゼンテーションのいくつかの部分に対してリンクするために、サーバによって用いられてもよい。これによって、いくつかのクライアントのプレファレンスを推定するために、より高速のログ処理（上記のステップ２７０５を参照）を行うことが出来る。
【０２７６】
マニフェストの解析（ステップ２７０８）は、ストリーミングを開始するために初期のＲｅｐｒｅｓｅｎｔａｔｉｏｎ（すなわち初期のメディアデータ）として適したＲｅｐｒｅｓｅｎｔａｔｉｏｎを（ステップ２７０９において）選択するときに、サーバに対して情報を提供する。
【０２７７】
（要求においてプレファレンスをそれぞれ取得する、または、先の交換からの使用データに基づく）両方のステップ２７０３および２７０５は、クライアント装置／ユーザからプレファレンスまたは利用をＭＰＤ属性と一致する具体的なパラメータ内に変換することにある。例えば、それは、帯域幅、ビデオの幅および高さ、使用中のコーデックの種類、字幕のための言語、またはオーディオストリームであり得る。そして、これらのパラメータのために取得された値から、サーバは、クライアントに対してプッシュするべき最も都合のよいＲｅｐｒｅｓｅｎｔａｔｉｏｎを、ステップ２７０９において識別するために、マニフェスト内の値と比較する。
【０２７８】
このステップ２７０９は、通常は、クライアント装置がＤＡＳＨのような動的および適応型ストリーミングプロトコルで継続的に実行するものである、ということに留意されたい。ここで、同じステップは、ＭＰＤ構文解析手段により、ストリーミングセッションの先頭において、サーバによって実行される。
【０２７９】
適したＲｅｐｒｅｓｅｎｔａｔｉｏｎを２７０９において推定することができない場合、テスト２７１０は偽であり、サーバは、そのｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータを（前述のステップ２７０７において）「低」値にする。
【０２８０】
ｃｏｎｆｉｄｅｎｃｅ＿ｖａｌｕｅパラメータが「低」値を有する場合（プレファレンスを決定することができなかったので、または適したＲｅｐｒｅｓｅｎｔａｔｉｏｎがプレファレンスに基づいて見つからないので）、サーバは、最も簡単なＲｅｐｒｅｓｅｎｔａｔｉｏｎを選択することをステップ２７１１において判断する。ビデオに関して、例えば、最も簡単なＲｅｐｒｅｓｅｎｔａｔｉｏｎは、最低の空間解像度によるＲｅｐｒｅｓｅｎｔａｔｉｏｎであってもよいし、最低の帯域幅用に設計されてもよい。
【０２８１】
（図２７には表現されない）可能な補完的な特徴によれば、コーデック上にアンビギュイティがない場合（すなわち、ビデオＲｅｐｒｅｓｅｎｔａｔｉｏｎは、すべてコーデック属性と同じ値を有し、すなわち、同じコーデック、例えばＨＥＶＣは、ビデオＲｅｐｒｅｓｅｎｔａｔｉｏｎをすべて符号化するために用いられている）、ｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータは、値「中」に引き上げられてもよい。
【０２８２】
ステップ２７１１の次のステップは、または適したＲｅｐｒｅｓｅｎｔａｔｉｏｎが見出された場合（テスト２７１０で真）は、イニシャライゼーションデータを識別することにある（ステップ２７１２）。実際に、ＤＡＳＨマニフェスト（または記述ファイル）において、イニシャライゼーション情報は、異なる方法で、信号で送ることができ、それは、イニシャライゼーションデータに対して直接的なＵＲＬを提供するＳｅｇｍｅｎｔＢａｓｅ、ＳｅｇｍｅｎｔＬｉｓｔまたはＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ要素のイニシャライゼーション要素内に明示的に加えることができる。
【０２８３】
この場合、このＵＲＬは、（変数：ｓｃｈｅｍｅ、：ｈｏｓｔ、：ｐａｔｈ、および最終的に：Ｒａｎｇｅを指定することによって）プッシュされることをプロミスされたリソースをクライアントが識別することを可能にするＰＵＳＨ＿ＰＲＯＭＩＳＥフレームのヘッダ部内に加えられる（図２６を参照しながら上記されたステップ２６５４を参照）。
【０２８４】
イニシャライゼーションデータが明示的に記述されない場合、これは、メディアセグメントがセルフイニシャライズされる、ということを意味する。そのような場合、サーバは、セグメントの最初（例えばｍｐ４形式のセグメントのためのセグメントインデックス情報ボックス）を解析しなければならない。この解析に基づいて、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム内にヘッダとして加えられる対応するＵＲＬを適切なバイト単位の範囲で構築することができる。
【０２８５】
一旦識別されれば、イニシャライゼーションデータのためのＰＵＳＨ＿ＰＲＯＭＩＳＥフレームは、クライアントに対して直ちに送信され（図２６におけるステップ２６５４に対応するステップ２７１３）、その直後にイニシャライゼーションデータのプッシュにより送信される（図２６におけるステップ２６５７に対応するステップ２７１７ａ）。イニシャライゼーションデータが受信されると、クライアントは、その後、そのメディア復号器をイニシャライズすることができる（ステップ２７１７ｂ）。
【０２８６】
随意に、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを処理するときにクライアント装置によってセグメント信号送信およびその後の識別を向上させるために（以下に記載のステップ２８０６を参照）、サーバは、ステップ２７１３において、プッシュされたデータの性質と、イニシャライゼーションまたはメディア若しくは両方（自分でイニシャライズするセグメントの場合）と、ＵＲＬテンプレートのパラメータまたは図５ｂのＭＰＤリプレゼンテーションツリーにおけるパスのようなセグメントの表示（例えば：Ｐ２ＡＳ２１Ｒ２１１Ｓ１、すなわち、識別子に続く要素型の連結）を示すことができる。これは、ＭＰＤを受信するようにクライアント装置に要求する、ということに留意されたい。そして、サーバは、クライアント装置によってＭＰＤ受信の後に処理されることになると考えるＰＵＳＨ＿ＰＲＯＭＩＳＥメッセージ内にのみ、この特定情報を追加することを決定することができる。ＭＰＤの受信および解析の前にＰＵＳＨ＿ＰＲＯＭＩＳＥを受け入れるかまたは受け入れないかをクライアント装置で決定することを支援するために、サーバは、ＭＰＤ内のセグメントパスの代わりに、プッシュされたセグメントの定性的情報（例えばそれがベース層またはエンハンスメント層からのセグメントであるか否かなど）を示すことができ、また、別の例によれば、サーバは、それらの値で選択されたＲｅｐｒｅｓｅｎｔａｔｉｏｎの属性をヘッダ内に配置することができる。
【０２８７】
（図２７には表現されない）可能な実施形態によれば、ステップ２７０８においてマニフェストの解析が、イニシャライゼーションデータがマニフェストのトップレベル要素内にあることを判定するときに、（すなわち、例えば依存するＲｅｐｒｅｓｅｎｔａｔｉｏｎの場合には、いかなるＲｅｐｒｅｓｅｎｔａｔｉｏｎでも、イニシャライゼーションデータは、すべてのリプレゼンテーションに共通である）、サーバは、プッシュされたデータとクライアントが選択したであろうものとの間のミスマッチのリスクがないので、「高」値に設定されたｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータセットによりイニシャライゼーションデータを指定するＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを直ちに（すなわちステップ２７０８と同時に）送信することができる。例えばＨＴＴＰヘッダとしてＰＵＳＨ＿ＰＲＯＭＩＳＥフレームとともにｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータを送信する利点は、プッシュプロミスを受け入れるかまたはキャンセルする際に、それがクライアント装置を支援することができるということである（以下に説明する図２８の記述を参照）。
【０２８８】
この機能のおかげで、クライアントは、（ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームが初期に送信されるので）その復号器を設定するのに必要なイニシャライゼーションデータを一層早く受信することになる。イニシャライゼーションデータが所定のメディアタイプごとにユニークであるときに（例えば、このＡｄａｐｔａｔｉｏｎＳｅｔ内のリプレゼンテーションの数はいくつであってもＡｄａｐｔａｔｉｏｎＳｅｔ当たり１つの単一のＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔである）、これもまた動作する。この一層高速のプッシュは、マニフェストの解析（上記のステップ２７０８）の直後に行われることになり、従ってログまたはプレファレンスを処理する（上記のステップ２７０１、２７０３、および２７０５）前に行われる。
【０２８９】
そして、先にサーバによって決定されたｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータが、値「中」以上であれば（テスト２７１４）、サーバは、クライアントのために適しているものとして考えられる第１のメディアデータをプッシュするイニシアチブをとる。
【０２９０】
これは、２つステップにおいて反復して行われ、最初にＰＵＳＨ＿ＰＲＯＭＩＳＥフレームが送信され（図２６のステップ２６５６に対応するステップ２７１５）、そして、第１のメディアデータのプッシュがステップ２７１９において開始する。これは、ステップ２７０９においてプッシュされるように選択された各第１のメディアデータセグメントに対して繰り返される。
【０２９１】
可能な実施形態によれば、連続するメディアセグメントがプッシュされることがプロミスされるときに（すなわち、複数のＰＵＳＨ＿ＰＲＯＭＩＳＥがそれぞれのメディアセグメントのために送信される）、現在のメディアセグメントに関連付けられたＰＵＳＨ＿ＰＲＯＭＩＳＥは、先のＰＵＳＨ＿ＰＲＯＭＩＳＥのチャイルドまたはフォロアとしてマークされる（ステップ２７１６）。サーバがステートレスである場合、これは、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム内に新たなＨＴＴＰヘッダとして加えることができ、また、サーバがステートフルである場合テーブル内に保持されることができる。この関連性の保持は、プッシュプロミスに対して階層的なキャンセルを実行するのに有用かもしれない（図２８を参照して以下で説明するように）。
【０２９２】
データの様々な送信が可能なスケジュールは、以下の通りである。すなわち、実際に第１のメディアデータをプッシュする前に、サーバは上記のステップ２７１７ａにおいてイニシャライゼーションデータをプッシュし始める。第１のメディアデータおよびイニシャライゼーションデータに関連するＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの送信と並行して、サーバは、また、ステップ２７１８において、ＭＰＤファイル（マニフェスト）を送信し、プッシュされたデータが完全に送信されるまで、ストリームのオープンを保持する。
【０２９３】
別の実施形態において、テスト２７１４は、いかなる信頼度であっても、第１のメディアデータをプッシュするために回避されることができる。但し、ｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータが「低」に設定されている場合、サーバは、第１の（または初期の）メディアデータを実際にプッシュする前に、クライアントからの可能性のあるＣＡＮＣＥＬを待ってもよい。
【０２９４】
第１のメディアデータをプッシュすると、サーバは、プッシュするデータの全体的な量を決定し、使用する速度を決定する（フロー制御）。
【０２９５】
第１の態様に関して、サーバは、例えばマニフェストの先頭における前述のｍｉｎＢｕｆｆｅｒＴｉｍｅ属性などのマニフェストからの情報を活用することができる。この属性を用い、ステップ２７０９または２７１１において選択されたＲｅｐｒｅｓｅｎｔａｔｉｏｎ考慮し、所定のセグメント期間属性がマニフェスト内にあるとすると、サーバは、ｍｉｎＢｕｆｆｅｒＴｉｍｅ制約を実現するためにプッシュするセグメントの数（すなわち、セグメントの量、したがってプッシュされる初期のメディアデータを形成するデータの量）を容易に決定できる。有なことに、マニフェストの解析をオフラインで実行する場合（ステップ２７０８）、第１のメディアセグメントのこの数を、サーバのメモリ内のテーブル内に記録することができる。
【０２９６】
第２の態様に関して、セグメントの期間および選択されたＲｅｐｒｅｓｅｎｔａｔｉｏｎの帯域幅を与えられると、必要なビットレートの推定は、サーバによって取得されるであろう。これは、主としてビデオセグメントのために、用いる送信速度を提供する。例えば、５秒の期間のセグメントを有する、１．６メガビット／秒に等しい帯域幅により圧縮されたビデオリプレゼンテーションに対して、各セグメントは、送信する１メガバイトのデータを表現するだろう。デフォルトでは、ＨＴＴＰｖ２．０におけるフロー制御は、６５５３５バイトにほぼ等しいストリームウィンドウサイズを提供する。したがって、我々の例において、これは、プッシュされた６５５３６バイトの各パケットに対して、クライアントは、サーバに戻す肯定応答を送信しなければならず、そのため、我々の例においては、１セグメント当たり１５回を超える！ということを意味する。開発中のＨＴＴＰ２．０下でプッシュ機能を用いる場合にネットワークラウンドトリップおよびトラフィックを減少させることを目指すので、我々は、（ネットワークトラフィックを減少させることによって）ＤＡＳＨ高速起動を可能にするためにデフォルト挙動（実際にはデフォルトの輻輳ウィンドウサイズ）を改善する必要がここにある、ということを明確に認識する。
【０２９７】
クライアント装置が、マニフェストに対する要求内に含まれたプレファレンスを送信する場合、要求の直後にＳＥＴＴＩＮＧＳフレームが送信されるべきである、ということを、また、示すことができ、このＳＥＴＴＩＮＧＳフレームは、そのバッファリング容量にしたがって、例えば初期ウィンドウサイズ（ＳＥＴＴＩＮＧＳ＿ＩＮＩＴＩＡＬ＿ＷＩＮＤＯＷ＿ＳＩＺＥ）を指定する。可能な変形物によれば、このＳＥＴＴＩＮＧＳフレームは、接続設定時間に送信することができる。別な可能性は、クライアント装置が、第１のプッシュデータを通知する場合に適切なサイズのＷＩＮＤＯＷ＿ＵＰＤＡＴＥを送信することである。
【０２９８】
図２８は、本発明の教示による、例えば図２７に記載されたような方法を実行するサーバとデータを交換する場合に、クライアント装置によって実施される可能な方法を記述する。
【０２９９】
この方法の可能なアプリケーションによれば、クライアント装置は、ビデオ・オン・デマンドサービスから恩恵を得るために、サーバに対して接続する。クライアントとサーバとの間の接続確立は、従来のものである。本例において、クライアント装置およびサーバの両方は、例えば既に前述したドキュメント「ハイパーテキスト転送プロトコルバージョン２．０（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ２．０）、ｄｒａｆｔ−ｉｅｔｆ−ｈｔｔｐｂｉｓ−ｈｔｔｐ２−ｌａｔｅｓｆ」に記述されたＨＴＴＰ／２．０プロトコルを用いてメッセージを交換することができる。
【０３００】
ある時に（例えばクライアント装置におけるユーザが所定のビデオを選択するときに）、クライアント装置は、メディアプレゼンテーション（ここではユーザが見たいビデオ）を記述するマニフェストのアドレス（例えばＵＲＬ）上のサーバから情報を得る。
【０３０１】
そして、クライアント装置は、マニフェストをダウンロードする要求を準備する（ステップ２８００）。好ましい実施形態において、クライアントは、ＨＴＴＰヘッダを通じてビデオ解像度、コーデック、それを支援する帯域幅に、いくつかのプレファレンスを追加する（ステップ２８０１）。そして、クライアント装置は、サーバに対してその要求を送信する（ステップ２８０２）。
【０３０２】
本実施形態において、クライアント装置は、そして、そのバッファリング容量に従って初期ウィンドウサイズ（ＳＥＴＴＩＮＧＳ＿ＩＮＩＴＩＡＬ＿ＷＩＮＤＯＷ＿ＳＩＺＥ）を示すために、ステップ２８０３において、ＨＴＴＰ／２．０  ＳＥＴＴＩＮＧＳフレームを送信する（上記のドキュメント「ハイパーテキスト転送プロトコルバージョン２．０（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  ｖｅｒｓｉｏｎ  ２．０）、ｄｒａｆｔ−ｉｅｔｆ−ｈｔｔｐｂｉｓ−ｈｔｔｐ２−ｌａｔｅｓｆ」のセクション３．８．５を参照）。
【０３０３】
ステップ２８０４において、クライアント装置は、様々なサーバ応答を処理し始める。すなわち、マニフェストを形成するデータを受信し、そのマニフェストを解析する（ステップ２８０５）だけでなく、サーバによって送信されるＰＵＳＨ＿ＰＲＯＭＩＳＥフレームも受信し、解析する（ステップ２８０６）。
【０３０４】
ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム（単数または複数）内の指定されたプッシュ（単数または複数）を受け入れるかキャンセルするかを決定する前に、クライアントは、サーバがプッシュするように意図するリソースのＵＲＬを構築し（ステップ２８０６）、サーバによってＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム内に含まれているｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータをチェックする（ステップ２８０７）。
【０３０５】
並行して、そしてマニュフェスト（記述ファイル）が完全に受信されると、クライアント装置は、入手したい所望のメディアセグメントのリスト（すなわちそのニーズに最良に適する各セグメントのバージョンのリスト）を構築し（ステップ２８０８）、現在のｓｅｇｍｅｎｔ＿ｉｎｄｅｘ変数を０にイニシャライズする（ステップ２８０９）。ＰＵＳＨ＿ＰＲＯＭＩＳＥの処理において第１のステップは、ｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータをチェックすることにある（ステップ２８１０ａ）。そして、例えば（事前に定義された）クライアントセッティングまたはユーザのプレファレンスに依存して、クライアントは、例えば、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームが「低」値のｃｏｎｆｉｄｅｎｃｅ＿ｌｅｖｅｌパラメータを含むＰＵＳＨ＿ＰＲＯＭＩＳＥなどの、一定レベルの信頼度下のＰＵＳＨ＿ＰＲＯＭＩＳＥを拒否することを決定することができる。
【０３０６】
クライアントが（前述のステップ２８０８においてマニフェストから導き出されたような）所望のセグメントのＵＲＬとＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム内の前述のＵＲＬとをマッチさせることができる（ステップ２８１０ｂ）ならば、それらの送信状態により送信されている保留中のセグメントのリストのためのテーブルをイニシャライズする（ステップ２８１１）。ステップ２８１０ｂにおいて、所望のメディアセグメントのリスト内のサーバによってプッシュされるように意図されたセグメントをクライアントが識別することができなければ、サーバに対して適切なＣＡＮＣＥＬ命令を送信することによってプッシュをキャンセルする（ステップ２８１２）。
ステップ２８１０ｂにおけるセグメント識別を容易にするために、クライアントは、例えば、ＭＰＤツリー表現内のパス（図５ｂを参照）として、プッシュされたセグメントのインデックス、または記述ファイル（すなわちＭＰＤファイルまたはマニフェスト）がＳｅｇｍｅｎｔＴｅｍｐｌａｔｅに依存する場合にはＵＲＬテンプレートパラメータのような、付加的なヘッダ情報を活用することができる。
【０３０７】
これは、ＰＵＳＨ＿ＰＲＯＭＩＳＥを構築する際にサーバによって挿入された階層関係を用いるので（上記図２７の記述を参照）、ここでは特定のＣＡＮＣＥＬメッセージであり（ステップ２８１２）、クライアントは、後続の１つを加えた現在のＰＵＳＨ＿ＰＲＯＭＩＳＥのキャンセルをもたらす再帰的なＣＡＮＣＥＬを送信することができる。
【０３０８】
可能な実施形態によれば、クライアント装置がプッシュプロミスを解釈することができない場合、メディアのリソースの次の時間セグメントに対応するメディアデータのすべてのプッシュを、デフォルトによって停止する。
【０３０９】
ＣＡＮＣＥＬ命令のこの新たな利用により、メディアセグメント識別の観点から、一旦それがサーバと非同期にされると、クライアントがＣＡＮＣＥＬメッセージを繰り返すことを回避する。そのような場合、クライアントは、プルモードに戻ることになる。
【０３１０】
そして、プッシュによってサーバから受信されるセグメントが所望のセグメントに対応する場合（テスト２８１０ｂで真）、クライアントは、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームの処理を継続する（テスト２８１３およびステップ２８０６上でのループ）。
ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームがすべて処理されると、クライアント装置は、受理したＰＵＳＨ＿ＰＲＯＭＩＳＥに対応するデータを受信してバッファリングすることを（ステップ２８１４）予期し、開始する。
【０３１１】
十分なメディアセグメントがクライアントの受信バッファ内に受信されると（テスト２８１５）、それらはクライアントによって処理される（２８１６）。そして、現在のｓｅｇｍｅｎｔ＿ｉｎｄｅｘ変数は、リスト内の第１のセグメントの順序付け数で更新される（ステップ２８１７）。すべてのクライアントがクライアントのバッファに対してアクセスするとは限らないかもしれない、ということに留意するべきである。例えば、特にウェブアプリケーションは、ウェブブラウザのキャッシュに対して通常はアクセスしない。このようなケースにおいて、サーバは、ウェブアプリケーションクライアントに対してプッシュされたセグメントのリストを直接送信してもよい。この情報は、例えばウェブソケット接続を用いて、サーバからクライアントまで交換されることができる。
【０３１２】
プッシュされたメディアセグメントがすべて処理されると、クライアントは、次に、標準的なプルベースのＤＡＳＨ（ステップ２８１８）に戻り、変数ｓｅｇｍｅｎｔ＿ｉｎｄｅｘ＋１によって指定された、次のセグメントに対応するデータの要求を開始する。並行して、プッシュされたセグメントデータは、選択されたビデオの復号化および表示を開始するために用いられる。
【０３１３】
図１３は、実施形態に従う装置の概略図である。装置は、サーバ、クライアント、またはプロキシであってもよい。装置は、実施形態による方法を実施するように構成された制御部１３０１のためにワークメモリとして用いられるＲＡＭメモリ１３０２を備える。例えば、制御部は、ＲＯＭメモリ１３０３からロードされたコンピュータプログラムの命令を実行するように構成されるであろう。プログラムは、また、ハードドライブ１３０６からロードしても良い。例えば、コンピュータプログラムは、図８〜図１２、図１４、図１５、図１７、図２０〜図２２、および図２６〜図２８のフローチャートおよび上記の記述に基づいて設計される。
【０３１４】
装置は、また、単一のネットワークインタフェースであってもよいネットワークインタフェース１３０４を備えるか、または、１セットのネットワークインタフェース（例えば、いくつかの無線インタフェース、またはいくつかのタイプの有線若しくは無線インタフェース）を備える。装置は、ユーザに対する情報を表示するための、およびユーザから入力を受信するための、ユーザインタフェース１３０５を備えてもよい。
【０３１５】
装置は、また、外部装置から／外部装置に、データを受信および／または送信するための入出力モジュール１３０７を備えてもよい。
【０３１６】
本発明が図面および前述の記述に詳細に図示され記述されたが、このような例証および記述は、例証または例示的であって限定的ではなく、本発明が、開示された実施形態に限定されない、ということを考慮すべきである。開示された実施形態にする他の変形物は、図面、開示物、および添付の請求項に関する研究から、特許請求された発明を実施する際に、当業者によって理解され、達成され得る。
【０３１７】
なお、本実施形態は以下のように捉えることもできる。
すなわち、サーバの観点に対応する本発明の第１の態様によれば、サーバ装置によってメディアデータをクライアント装置に対してストリーミングする方法は、
・クライアント装置から第１のメディアデータに関連する要求を受信するステップと、・要求されていなくともクライアント装置に対して送信される第２のメディアデータを識別するステップと、
・前記要求に応答して、前記クライアント装置に対して前記第１のメディアデータに関連する情報を送信し、クライアント装置に対してアナウンスメッセージ（単数または複数）を送信するために前記第２のメディアデータをそれぞれ識別する少なくとも１つのアナウンスメッセージを準備するステップと
を備え、
前記方法は、サーバ装置がクライアント装置に対する第２の非要求メディアデータの識別または送信を駆動するためにクライアント装置と共有されるプッシュポリシーを用いるステップをさらに備える。
【０３１８】
クライアントの観点に対応する本発明の第２の態様によれば、サーバ装置によってストリーミングされたメディアデータにクライアント装置によってアクセスする方法は、・第１のメディアデータに関連する要求をサーバ装置に対して送信するステップと、・前記要求に応答して、前記第１のメディアデータに関連する情報を前記サーバ装置から受信するステップと
を備え、
前記方法は、クライアント装置が、クライアント装置によって要求されることなくサーバ装置によって送信される第２のメディアデータを決定するために、またはサーバ装置によってその送信の順序を決定するために、サーバ装置と共有されるプッシュポリシーを用いるステップをさらに備える。
【０３１９】
特に、共有されるプッシュポリシーは、クライアント装置に対してサーバ装置によって送信される第２の非要求メディアデータを決定する装置のために、第２のメディアデータを決定する方法を定義してもよい。
【０３２０】
このアプローチにより、サーバのプッシュされるメディアデータに関する判定とクライアントのニーズとの間のミスマッチを減少させることができ、それにより、リソースを節約することができる。
【０３２１】
これは、クライアントが、サーバの挙動と、それによりこれからプッシュされる第２のメディアデータを予期することを可能にする共有されるプッシュポリシーを用いることによって、実現される。いくつかのクライアントの後続の要求のために用いられる共有されるプッシュポリシーにより、クライアントは、要求がサーバに対して送信される前でさえも、サーバの挙動を予期することができる。
【０３２２】
予期の結果として、クライアントは、サーバによるアナウンスに関して予期される方式で、必要でないこのような第２のメディアデータのキャンセルを準備し要求することができる。
【０３２３】
第１のメディアデータに関連する要求は、第１のメディアデータおよび／またはこの第１のメディアデータに関連する他のデータに関係してもよい。
第２のメディアデータは、例えばサーバ装置によって、前記第１のメディアデータに関連づけられてもよい。
【０３２４】
本発明の実施形態は、サーバ誘導（ｓｅｒｖｅｒ−ｇｕｉｄｅｄ）ストリーミングのための軽量のメカニズムを提供する。実施形態は、ＤＡＳＨネットワークとの関連で実施されてもよい。
【０３２５】
サーバ装置は、クライアント装置に対してコンテンツ推薦を行うことができる。また、それらはネットワーク利用を最適化することができる。
【０３２６】
本発明の実施形態は、既存のＨＴＴＰ／２機能との互換性をもつ。これらの機能は、本発明の実現実施形態のために有利に用いることができる。
ネットワークの性能は、一般的には増加する。
【０３２７】
それに対応して、本発明は、また、クライアント装置に対してメディアデータをストリーミングするためのサーバ装置に関係し、サーバ装置は、
・クライアント装置から第１のメディアデータに関連する要求を受信するように構成された受信器と、
・要求されることなくクライアント装置に対して送信される第２のメディアデータを識別するように構成された制御部と、
・前記要求に応答して、前記第１のメディアデータに関連する情報を前記クライアント装置に対して送信し、クライアント装置に対してアナウンスメッセージ（単数または複数）を送信するために前記第２のメディアデータをそれぞれ識別する少なくとも１つのアナウンスメッセージを準備するように構成された送信器と
を備え、
前記制御部は、クライアント装置に対する第２の非要求メディアデータの識別または送信を駆動するためにクライアント装置と共有されるプッシュポリシーを用いるようにさらに構成される。
【０３２８】
本発明は、また、サーバ装置によってストリーミングされたメディアデータへのアクセスのためのクライアント装置に関係し、前記装置は、
・サーバ装置に対して第１のメディアデータに関連する要求を送信するように構成された送信器と、
・前記要求に応答して、前記サーバ装置から前記第１のメディアデータに関連する情報を受信するように構成された受信器と
を備え、
クライアント装置は、クライアント装置によって要求されることなくサーバ装置によって送信される第２のメディアデータを決定するために、またはサーバ装置によってその送信の順序を決定するために、サーバ装置と共有されるプッシュポリシーを用いるように構成される。
【０３２９】
サーバおよびクライアント装置は、上記の対応する方法と同じ利点を有する。
【０３３０】
方法および装置のオプション機能は、従属請求項において定義される。それらのいくつかは、方法に関して以下に説明される。しかしながら、それらは、また、対応する装置に対して適応することができる。
【０３３１】
明示的なアプローチに関して以下に参照された、いくつかの実施形態において、サーバの観点からの方法は、
サーバ装置によってプッシュポリシーを決定するステップと、
クライアント装置とプッシュポリシーを共有するために決定されたプッシュポリシーを記述するプッシュポリシー情報を、サーバ装置からクライアント装置に対して送信するステップと
をさらに備える。
【０３３２】
それに対応して、クライアント側において、前記方法は、共有されたプッシュポリシーを記述するプッシュポリシー情報を、サーバ装置から受信するステップをさらに備えてもよい。
【０３３３】
以下のいくつかの例に記述されるように、共有されたプッシュポリシーを記述するプッシュポリシー情報は、サーバ装置からクライアント装置に対して送信される記述ファイル内に挿入され、記述ファイルは、第１のメディアデータを含むメディアデータに関係する記述情報を含み、前記方法は、共有されたプッシュポリシーを用いて、前記記述ファイルに基づいて第２の非要求メディアデータを決定するステップをさらに備える。
【０３３４】
具体的な実施形態において、記述ファイルは、複数のメディアデータ属性レベルを用いてメディアデータを記述し、様々な共有されるプッシュポリシーは、様々なそれぞれのレベルの記述ファイルにおいて定義される。
【０３３５】
他の例において、共有されるプッシュポリシーを記述するプッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されたＨＴＴＰフレームのヘッダ内に埋め込まれる。
【０３３６】
具体的な機能によれば、前記方法は、サーバ装置において、クライアント装置からＨＴＴＰフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報を受信し、それに応じて、クライアント装置によって要求された他のメディアデータから非要求メディアデータを決定する前に共有されるプッシュポリシーを更新するステップをさらに備えてもよい。それに対応して、前記方法は、クライアント装置において、ＨＴＴＰフレームのヘッダ内に埋め込まれたプッシュポリシー更新情報を、サーバ装置に対して送信するステップをさらに備えてもよい。
【０３３７】
複合型アプローチによれば、共有されるプッシュポリシーを記述するプッシュポリシー情報は、第１のプッシュポリシー部および第２のプッシュポリシー部によって定義され、第１のプッシュポリシー部は、サーバ装置からクライアント装置に対して送信される記述ファイル内に挿入され、記述ファイルは、第１のメディアデータを含むメディアデータに関係する記述情報を含み、前記方法は、共有されたプッシュポリシーを用いて、前記記述ファイルに基づいて第２の非要求メディアデータを決定するステップをさらに備え、第２のプッシュポリシー部は、サーバ装置からクライアント装置に対して送信されるＨＴＴＰフレームのヘッダ内に埋め込まれる。
【０３３８】
例えば、第２のプッシュポリシー部は、第１のプッシュポリシー部内に定義された１つ以上の関連変数に対する１つ以上の値を備えてもよい。
【０３３９】
また、記述ファイルは、複数の候補プッシュポリシーの記述を含んでもよく、第２のプッシュポリシー部は、それにより前記複数からの候補プッシュポリシーの識別子を備えてもよく、識別された候補プッシュポリシーは、それによって第１のプッシュポリシー部を形成する。
【０３４０】
他の実施形態において、プッシュポリシー情報は、サーバ装置からクライアント装置に対して送信されたウェブページ内に埋め込まれたＪａｖａ（登録商標）Ｓｃｒｉｐｔプログラムを含む。
【０３４１】
さらに他の実施形態において、前記方法は、構造化ドキュメント（上記の記述ファイルまたは以下の例に導入されるＨＴＭＬページなど）に基づいて第２の非要求メディアデータを決定するステップをさらに備え、構造化ドキュメントは、第１のメディアデータを含むメディアデータに関係する記述情報を含み、
プッシュポリシー情報は、第２の非要求メディアデータを識別する構造化ドキュメントのツリー表現上で評価される、ＸＰａｔｈ式を含む。
【０３４２】
前記プッシュポリシー情報の構文に関して、実施形態は、プッシュポリシー情報が記述ファイル内に識別された第２の非要求メディアデータの量を定義する第１のプッシュ属性を含む、ということを提供し、
前記記述ファイルは、第１のメディアデータを含むメディアデータに関係する記述情報を含み、前記方法は、共有されたプッシュポリシーを用いて、前記記述ファイルに基づいて第２の非要求メディアデータを決定するステップをさらに備える。
【０３４３】
具体的な機能によれば、第１のプッシュ属性は、記述ファイル内の要求された第１のメディアデータに相対する第２の非要求メディアデータを識別する。これは、以下に記載されるようなオペレータを用いて行われてもよい。
【０３４４】
変形において、第１のプッシュ属性は、記述ファイル内部の具体的なメディアデータの識別子である。
【０３４５】
具体的な機能によれば、記述ファイル内の記述情報は、メディアデータが属する期間を定義する期間属性と、メディアデータのメディアタイプを定義するアダプテーション属性と、メディアデータの符号化バージョン（例えば、ビットレート、フレームレート、フレーム解像度、タイミング情報、など）を定義するリプレゼンテーション属性と、定義するセグメント属性との中の少なくとも１つのメディアデータ属性にしたがってメディアデータを記述し、
前記プッシュポリシー情報は、第２の非要求メディアデータを識別するために、メディアデータ属性（単数または複数）上の制約を定義する少なくとも第２のプッシュ属性を含む。
これは、記述ファイルを通じて非常に選択的なプッシュポリシーを有することを可能にする。
【０３４６】
特に、プッシュ属性（単数または複数）は、記述ファイル内部の第１のメディアデータの対応するメディアデータ属性（単数または複数）に相対する第２の非要求メディアデータのメディアデータ属性（単数または複数）を定義してもよい。
または、プッシュ属性（単数または複数）は、第２の非要求のメディアデータが検索されなければならない記述ファイル内のノードを識別してもよい。
【０３４７】
いくつかの実施形態において、記述ファイル内の記述情報は、メディアデータに関連付けられたプライオリティ属性を含み、各々のメディアデータごとに１つのプライオリティ属性があり、第２のメディアデータの送信の順序は、関連するプライオリティ属性に基づく。これは、プッシュデータの送信の順序を定義するためである。
【０３４８】
実施形態において、共有されるプッシュポリシーは、要求された第１のメディアデータから第２のメディアデータを識別する。
【０３４９】
暗示的アプローチに関して以下に参照された実施形態において、共有のプッシュポリシーは、サーバ装置およびクライアント装置の両方において同じ第２のメディアデータを決定するアルゴリズムを用いて実施され、アルゴリズムは、サーバ装置およびクライアント装置が、要求された第１のメディアデータから同じ第２のメディアデータを決定することを可能にする。
【０３５０】
暗示的アプローチおよび明示的アプローチの双方に適応した、いくつかの実施形態において、識別された第２のメディアデータが、各々がアナウンスメッセージを要求する複数のメディアセグメントを備えるならば、前記方法は、クライアント装置に対して送信される単一のアナウンスメッセージに、対応する複数のアナウンスメッセージをマージするステップをさらに備えてもよい。これは、より少量のアナウンスメッセージが送信されるので、帯域幅の消費量を低減するためである。
【０３５１】
共有されたプッシュポリシーおよびクライアント装置によるプッシュの結果として生ずる予期を実際に活用するために、前記方法は、サーバ装置が対応する準備したアナウンスメッセージを送信しないように、第２の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求を、クライアント装置から受信するステップをさらに備えてもよい。
【０３５２】
それに対応して、クライアントにおいて、前記方法は、第２の非要求メディアデータの一部を識別するアナウンスメッセージを送信しないようにサーバ装置を駆動するために、第２の非要求メディアデータの一部の送信をキャンセルすることを要求するキャンセル要求を、サーバ装置に対して送信するステップをさらに備えてもよい。
【０３５３】
本発明の実施形態において、第２の非要求メディアデータは、サーバ装置によって準備され（および多分受信され）、少なくとも１つのアナウンスメッセージから独立してクライアント装置によって決定され、要求されることなくサーバ装置がクライアント装置に対して送信する予定である第２の非要求メディアデータを識別する。ここで「独立して（ｉｎｄｅｐｅｎｄｅｎｔｌｙ）」は、このような非要請データの今後の送信のクライアント装置に通知する専用のこのようなアナウンスメッセージ（すなわち、ＰＵＳＨ＿ＰＲＯＭＩＳＥ）を認識することなく、クライアント装置が第２の非要請データの決定を行うことができる、ということを意味する。
【０３５４】
本発明の他の実施形態において、同じ共有されたプッシュポリシーは、それぞれの第１のメディアデータに関連する複数の要求からそれぞれの非要求メディアデータを決定するために用いられる。経時的に同じプッシュポリシーと連続的な要求とを用いることによって、クライアントは、サーバによる無用データの送信をさらに一層効率的に予期しやすいポジションにあり、それにより、それらの送信および対応するアナウンスメッセージの送信を効率的にキャンセルしやすいポジションにある。
【０３５５】
サーバからクライアントに対するプッシュデータの送信の順序の通知に関して、サーバ装置によってクライアント装置に対してメディアデータをストリーミングする方法は、
・クライアント装置から第１のメディアデータに関連する要求を受信するステップと、・要求されていなくともクライアント装置に対して送信される第２のメディアデータを識別するステップと、
・前記要求に応答して、前記第１のメディアデータに関連する情報と前記第２のメディアデータをそれぞれ識別する少なくとも１つのアナウンスメッセージとを前記クライアント装置に送信するステップと
を備えてもよく、
前記方法は、
・サーバ装置によって第２のメディアデータ（これは、共有されたプッシュポリシーの一部またはすべてを形成する）の送信の順序を定義するステップと、
・送信の順序に関する情報であってクライアント装置がサーバによって定義された送信の順序を決定することを可能にする前記情報を、前記アナウンスメッセージとともに送信するステップと
をさらに備える。
【０３５６】
例えば、前記第２のメディアの送信の順序は、クライアント装置によるプライオリティ値にしたがって定義され、メディアデータは、最初に送信される最も高いプライオリティ値を有する。
【０３５７】
前記プライオリティ値は、ＨＴＴＰ／２プロトコルにしたがって定義されてもよい。実施形態によれば、少なくとも１つのプライオリティ値は、ネットワーク帯域幅推定メカニズムに関連付けられ、方法は、
・前記メカニズムに関連付けられたプライオリティ値をもつ第２のメディアデータをクライアント装置に対して送信するステップと、
・前記第２のメディアデータに応答して、クライアント装置から少なくとも１つの制御フローメッセージを受信するステップと、
・受信された前記少なくとも１つの制御フローメッセージに基づいて、利用可能な帯域幅を推定するステップと
をさらに備える。
【０３５８】
例えば、サーバ装置は、それぞれのサイズおよび個別のサイズを有する複数のデータフレームにしたがって前記第２のメディアデータを送信する。
【０３５９】
前記方法は、前記帯域幅推定に基づいて、第２のメディアデータの送信の更新された順序をサーバ装置によって定義するステップをさらに備えてもよい。
【０３６０】
実施形態によれば、クライアント装置からの前記要求は、前記第１のメディアデータを備えるメディアデータに関連する記述ファイルの受信を求める要求を備え、記述ファイルは、前記第１のメディアデータに関係する記述情報を含み、方法は、前記記述ファイルに基づいて第２の非要求メディアデータを決定するステップをさらに備える。
例えば、要求された第１のメディアデータは、ビデオセグメントである。
ストリーミングは、ＤＡＳＨ規格にしたがって実行されてもよい。
例えば、前記方法は、
・クライアント装置から順序更新要求を受信するステップと
・前記順序更新要求に基づいて、第２のメディアデータの送信の新たな順序を定義し、第２のメディアデータの送信の前記新たな順序に関する情報を更新するステップと、・送信の順序に関連する前記更新通知にしたがってクライアントに対して前記第２のメディアデータを送信するステップと
をさらに備える。
【０３６１】
前記方法は、クライアント装置に対して順序更新確認メッセージを送信するステップをさらに備えてもよい。
例えば、前記更新された順序は、前記順序更新要求の受信時刻にクライアント装置に対する送信が始まっていない、第２のメディアデータのために定義される。
例えば、前記順序更新要求は、少なくとも第２のメディアデータの一部のための順序値を備える。
【０３６２】
実施形態によれば、前記第２のメディアの送信の順序は、プライオリティ値にしたがって定義され、プライオリティ値が少なくとも第１のメディアデータの一部のために更新されると、要求されていなくともクライアント装置に対して送信される少なくとも第２のメディアデータの一部のためのおよび少なくとも前記第１のメディアデータの一部に関連するプライオリティ値は、それに応じて更新される。
例えば、前記第１のメディアおよび第２のメディアは、時間的関係、空間的関係、および品質関係の少なくとも１つにしたがって関連付けられる。
【０３６３】
実施形態によれば、
・前記第２のメディアデータは、第１のメディアデータの品質を強化するためのエンハンスメントデータを備え、
・プライオリティ値が前記エンハンスメント層のメディアデータのために更新されるとき、プライオリティ値は、前記エンハンスメント層のすべてのメディアデータのために更新される。
例えば、第１のメディアデータおよび第２のメディアデータは、ビデオ時間セグメントを備え、強化メディアデータの開始時間は、第１のメディアデータのビデオコンテンツに関連する情報に基づく。
例えば、第１のメディアデータのビデオコンテンツに関連する前記情報は、前記記述ファイル内に保存される。
例えば、前記送信の順序は、少なくとも第１のメディアデータと第２のメディアデータとの間の復号化関連性に基づく。
例えば、前記送信の順序は、少なくともメディアデータの統計的人気度に基づく。例えば、前記送信の順序は、少なくともクライアント装置の端部上のメディアデータの再生時間に基づく。
例えば、前記送信の順序は、少なくともメディアデータの推測された送信時刻に基づく。例えば、前記送信の順序は、少なくともメディアデータに対するユーザ定義の関心に基づく。
【０３６４】
前記方法は、
・制御メッセージであって、現在再生されているメディアデータをサーバ装置が識別することを可能にする前記制御メッセージをクライアント装置から受信するステップと、・第２のメディアデータの更新される送信の順序を、前記制御メッセージに基づいて、サーバによって定義するステップと、
・前記更新された送信の順序にしたがってクライアントに対して前記第２のメディアデータを送信するステップと
をさらに備えてもよい。
前記方法は、順序更新確認メッセージをクライアント装置に対して送信するステップをさらに備えてもよい。
例えば、前記制御メッセージは、クライアント装置のバッファメモリの使用に関連し、前記バッファメモリは、クライアントによって再生されるそれらのメディアデータを保存する。
例えば、サーバ装置は、送信された第１の要求メディアデータの記録を保持し、第２のメディアデータの識別は、バッファメモリおよび前記記録の前記使用に基づいて実行される。
例えば、前記送信の順序情報は、前記アナウンスメッセージ内で送信される。
例えば、前記送信の順序情報は、前記アナウンスメッセージの後の専用のメッセージ内で送信される。
【０３６５】
クライアントの観点から、サーバ装置によってストリーミングされたメディアデータをクライアント装置によってアクセスする方法は、
・第１のメディアデータに関連する要求をサーバ装置に対して送信するステップと、・前記要求に応答して、前記第１のメディアデータに関連する情報と、要求されていなくともクライアント装置に対して送信される第２のメディアそれぞれ識別する少なくとも１つのアナウンスメッセージとを、前記サーバ装置から受信するステップと
を備えてもよく、
前記方法は、前記アナウンスメッセージとともに第２のメディアデータの送信の順序に関連する情報を受信するステップをさらに備え、前記情報（すなわち共有されたプッシュポリシー）は、サーバによって定義された第２のメディアデータの送信の順序を決定することをクライアント装置が可能にする。
【０３６６】
前記方法は、サーバ装置によって定義された第２のメディアデータの送信の順序がクライアント装置の端部におけるストリーミング制約を満たすか否かをクライアント装置によって判定し、前記制約が満たされなければ、順序更新要求をサーバ装置に対して送信するステップをさらに備えてもよい。
【０３６７】
例えば、前記第２のメディアデータの送信の順序は、クライアント装置によるプライオリティ値にしたがって定義され、メディアデータは、最初に送信される最も高いプライオリティ値を有する。
【０３６８】
例えば、前記プライオリティ値は、ＨＴＴＰ／２プロトコルにしたがって定義される。
【０３６９】
実施形態によれば、少なくとも１つのプライオリティ値は、ネットワーク帯域幅推定メカニズムに関連付けられ、前記方法は、
・前記メカニズムに関連付けられたプライオリティ値をもつ第２のメディアデータをサーバ装置から受信するステップと、
・前記第２のメディアデータに応答して、少なくとも１つの制御フローメッセージを前記サーバ装置に対して送信し、それによって、送信された前記少なくとも１つの制御フローメッセージに基づいてサーバ装置が利用可能な帯域幅を推定することを可能にするステップと
をさらに備える。
例えば、クライアント装置は、それぞれのサイズおよび個別のサイズを有する複数のデータフレームにしたがって前記第２のメディアデータを受信する。
例えば、第２のメディアデータの更新される送信の順序は、前記帯域幅推定に基づいて、サーバ装置によって定義される。
例えば、クライアント装置からの前記要求は、前記第１のメディアデータを備えるメディアデータに関連する記述ファイルの受信を求める要求を備え、記述ファイルは、前記第１のメディアデータに関係する記述情報を含み、前記方法は、前記記述ファイルに基づいて第２の非要求メディアデータを決定するステップをさらに備える。
例えば、要求された第１のメディアデータは、ビデオセグメントである。
例えば、前記ストリーミングは、ＤＡＳＨ規格にしたがって実行される。
方法は、サーバ装置によって定義された第２のメディアデータの新たな送信の順序に関連する更新情報にしたがってサーバ装置から前記第２のメディアデータを受信するステップをさらに備えてもよい。
【０３７０】
前記方法は、順序更新確認メッセージをサーバ装置から受信するステップをさらに備えてもよい。
【０３７１】
実施形態によれば、前記更新された順序は、前記順序更新要求の受信時刻に送信が始まっていない、第２のメディアデータのためにサーバ装置によって定義される。
実施形態によれば、前記順序更新要求は、少なくとも第２のメディアデータの一部のための順序値を備える。
【０３７２】
実施形態によれば、前記第２のメディアの送信の順序は、プライオリティ値にしたがって定義され、プライオリティ値が少なくとも第１のメディアデータの一部のために更新されると、要求されていなくともクライアント装置に対して送信される少なくとも第２のメディアデータの一部のための且つ少なくとも前記第１のメディアデータの一部に関連付けられたプライオリティ値は、それに応じて更新される。
【０３７３】
例えば、前記第１のメディアおよび第２のメディアデータは、時間的関係、空間的関係、および品質関係の少なくとも１つにしたがって関連づけられる。
実施形態によれば、
・前記第２のメディアデータは、第１のメディアデータの品質の強化するためのエンハンスメントデータを備え、
・プライオリティ値がエンハンスメント層の第１のメディアデータの少なくとも一部のために更新されるとき、プライオリティ値は、前記エンハンスメント層のすべてのメディアデータのために更新される。
例えば、第１のメディアデータおよび第２のメディアデータは、ビデオ時間セグメントを備え、強化メディアデータの開始時間は、第１のメディアデータのビデオコンテンツに関連する情報に基づく。
実施形態によれば、第１のメディアデータのビデオコンテンツに関連する前記情報は、前記記述ファイル内に保存される。
実施形態によれば、前記送信の順序は、少なくとも第１のメディアデータと第２のメディアデータとの間の復号化関連性に基づく。
実施形態によれば、前記送信の順序は、少なくともメディアデータの統計的人気度に基づく。
実施形態によれば、前記送信の順序は、少なくともクライアント装置の端部上のメディアデータの再生時間に基づく。
実施形態によれば、前記送信の順序は、少なくともメディアデータの推測された送信時刻に基づく。
実施形態によれば、前記送信の順序は、少なくともメディアデータに対するユーザ定義の関心に基づく。
【０３７４】
前記方法は、
・制御メッセージであって、現在再生されているメディアデータをサーバ装置が識別することを可能にする前記制御メッセージをサーバ装置に送信するステップと、
・前記制御メッセージに基づいて、サーバ装置によって、定義された更新された送信の順序にしたがってサーバ装置から前記第２のメディアデータを受信するステップとを備えてもよい。
【０３７５】
前記方法は、順序更新確認メッセージをサーバ装置から受信するステップを備えてもよい。
例えば、前記制御メッセージは、クライアント装置のバッファメモリの使用に関連し、前記バッファメモリは、クライアント装置によって再生されるそれらのメディアデータを保存する。
実施形態によれば、サーバ装置は、送信された第１の要求メディアデータの記録を保持し、現在再生されているメディアの識別は、バッファメモリおよび前記記録の前記使用に基づいて実行される。
例えば、前記送信の順序情報は、前記アナウンスメッセージ内で受信される。
例えば、前記送信の順序情報は、前記アナウンスメッセージの後の専用のメッセージ内で受信される。
【０３７６】
さらに送信の順序を参照して、プロキシサーバによる、クライアント装置とサーバ装置との間のデータ交換を管理する方法は、
・送信の順序の通知に関して以上に定義されるような方法を実行するサーバから、クライアント装置に対して再送信されるメディアデータを受信するステップと
・メディアデータの送信の順序に基づいて、メディアデータのための再送信プライオリティを決定するステップと、
・決定された前記送信プライオリティに基づいて、クライアント装置に対する受信されたメディアデータの再送信を実行するステップと
を備えてもよい。
【０３７７】
前記方法は、決定された前記再送信プライオリティに基づいて、受信された前記メディアデータを保存するステップをさらに備えてもよい。
前記方法は、
・第２の態様による方法を実施するクライアント装置から順序更新要求を受信するステップと、
・前記要求が再送信されるメディアデータに関連する場合、前記順序更新要求にしたがって前記再送信プライオリティを更新するステップと、
・更新された再送信プライオリティにしたがってメディアデータの再送信を実行するステップと
をさらに備えてもよい。
【０３７８】
前記方法は、
・メディアデータのための、第１のサーバ装置に対する要求を、第１のクライアント装置から受信するステップであって、前記メディアデータは、第２のサーバ装置から第２のクライアント装置に対する再送信のためにプロキシサーバによって保存されるステップと、・第１のサーバ装置および第２のサーバ装置によって前記メディアデータにそれぞれ関連付けられたプライオリティ値を決定するステップと、
・第１のクライアント装置および第２のクライアント装置に対するそれぞれのストリーミング制約にしたがって前記プライオリティ値を更新するステップと、
・前記更新されたプライオリティ値にしたがって、前記第１のクライアント装置および第２のクライアント装置に対して前記メディアデータを再送信するステップと
をさらに備えてもよく、
前記第１のサーバ装置および第２のサーバ装置は、第１の態様による方法を実施し、前記第１のクライアント装置および第２のクライアント装置は、第２の態様による方法を実施する。
【０３７９】
前記方法は、更新されたプライオリティ値に関連する更新通知を第１のサーバ装置および第２のサーバ装置に対して送信するステップをさらに備えてもよい。
【０３８０】
本発明の別の態様によれば、サーバ装置とクライアント装置との間でデータをストリーミングする方法であって、
・サーバ装置によって第１の態様による方法を実行するステップと、
・クライアント装置によって第２の態様による方法を実行するステップと
を備える方法が提供される。
【０３８１】
本発明のさらに別の態様によれば、プログラミング可能な装置のコンピュータ手段にロードされ実行されたときに、以上に定義されるような方法を実施するための命令を備えるコンピュータプログラムおよびコンピュータプログラムプロダクトが提供される。本発明のさらに別の態様によれば、第１の態様による方法を実施するように構成されたサーバ装置が提供される。
【０３８２】
本発明のさらに別の態様によれば、第２の態様による方法を実施するように構成されたクライアント装置が提供される。
サーバからクライアント装置に対するメディアデータの適応型ストリーミングにための解決手段は、関係のあるクライアント装置の機能に対して、およびサーバとクライアント装置との間の接続を提供するネットワークの特性に対して、クライアント装置に送信されるデータのタイプおよび量を特に適応するために提案されてきた。
【０３８３】
これに関連して、ＤＡＳＨ（動的適応型ＨＴＴＰストリーミング）規格などのいくつかの解決手段は、配信されるリソース（またはコンテンツ）の複数のバージョンを保存し、且つこれらのバージョンに対してリソースおよびそれぞれのポインタ（例えばＵＲＬ）を表現する様々なバージョンの記述を含む記述ファイルを、リソースを要求するクライアント装置に対して送信することを提案する。
【０３８４】
そして、記述ファイルに基づいて、クライアント装置は、対応するポインタを用いて、このバージョンのニーズおよび要求にベストマッチするリソースのバージョンを選択することができる。
【０３８５】
この解決手段は、記述ファイルがメディアデータを含まない（但しメディアデータに対するポインタのみ含む）光である、という点で有利である。その利用のために関連するバージョンをクライアントに選択させることによって、クライアント装置に適さないメディアデータの交換を回避する。さらに、それはＨＴＴＰに基づく現在のウェブアーキテクチャに適合し、既に配備されたキャッシュメカニズムを利用することができる。
【０３８６】
その代わりに、しかしながら、メディアデータがクライアント装置において受信されて、その後、復号され表示され得る前に、この解決手段は、クライアント装置とサーバとの間のいくつかの交換（またはラウンドトリップ）を必要とし、それは開始遅延をもたらす。実施形態において、本発明は、メディアアイテムを表現するデータを保存するサーバからメディアアイテム（例えばビデオ）を表現するメディアデータを提供する方法を提供するのであって、少なくともその時間セグメントは、複数のバージョンによって表現され、方法は、サーバによって実施される以下のステップ、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をクライアント装置から受信するステップと、
・記述ファイル内でポインタが指すデータのセットの中のデータを選択するステップと、・クライアント装置に対して記述ファイルを送信するステップと、
・クライアント装置に対して選択されたデータをプッシュするステップと
を備える。
【０３８７】
適切な方式において選択されたデータをプッシュ（すなわち、クライアント装置によって請求されないが、以下にさらに説明するようにサーバによって選択されたデータの送信）することによって、１つまたは複数のラウンドトリップを回避することができ、それにより、メディアデータの復号化および表示をさらに高速に開始することができる。メディアアイテムは、例えば、ビデオ、または例えばオーディオトラックなどのオーディオアイテムであってもよい。
【０３８８】
上述のデータのセットは、時間セグメントを表現するバージョンを含むが、以下に説明されるようにイニシャライゼーションデータなどの他のデータを含んでもまたよい、ということに注目されたい。
【０３８９】
まさに述べた如く、選択されたデータは、クライアント装置の復号器のためのイニシャライゼーションデータを含んでもよい。したがって、復号器は、クライアント装置がイニシャライゼーションデータを特に、要求する必要なしに、イニシャライズでき、従ってより高速にイニシャライズできる。
【０３９０】
上述のように、選択されたデータは、また、時間セグメントを表現する前記バージョンの１つの少なくとも一部を含んでもよい。
データを選択するステップは、プッシュされるデータ（例えばビデオデータ）の量を推定するステップを含んでもよく、それは、どのデータが選択されるのかを決定するときに用いられてもよい。量は、記述ファイル内に定義されたバッファ時間に基づいて、および／または、サーバによって決定された帯域幅推定に基づいて推定されてもよい。
データを選択するステップは、要求に含まれる少なくとも１つのプレファレンスに基づいて、および／またはサーバとクライアント装置との間の従来の交換から導き出される使用データに基づいて、および／またはサーバによる記述ファイルの解析に基づいて、および／またはサーバ内に保存され、記述ファイルに関連するテーブルに基づいて、実行されてもよい。
【０３９１】
可能な実施形態によれば、選択されたデータをプッシュするステップに関連するとともに、そのステップに先立って、プッシュプロミスを送信するステップを備えてもよい。したがって、これらのデータを実際に受信する前に、プッシュされるデータがクライアント装置に通知されてもよい。
【０３９２】
プッシュプロミスを送信するステップは、記述ファイルを送信するステップの前に実行されてもよく、それは、初期のステージにおいてクライアント装置に通知することを可能にする。
プッシュプロミスは、例えば選択されたデータの識別を含む。
提案された実施形態によれば、サーバは、選択されたデータに関連する信頼水準を決定し、プッシュプロミスは、決定された信頼水準を含む。
【０３９３】
以下に述べる詳細説明において説明する可能なインプランテーションによれば、サーバは、選択されたデータを形成するデータのブロックの階層的リプレゼンテーションを保存してもよい。
このようなケースにおいて、
・データのブロックをプッシュしないための命令をクライアント装置から受信するステップと、
・前記データのブロック、および階層的リプレゼンテーションにおける前記データのブロックに連結されたデータのブロックのプッシングをキャンセルするステップと
が備えられていてもよい。
提案された方法は、選択されたデータに関連した信頼度を決定するステップを含んでもよく、そして、
・決定された信頼度が所定の閾値未満であれば、選択されたデータをプッシュするステップは、クライアント装置の復号器のイニシャライゼーションデータのみをプッシュするステップを含み、
・決定された信頼度が所定の閾値を上回れば、選択されたデータをプッシュするステップは、クライアント装置の復号器のためのイニシャライゼーションデータと、時間セグメントを表現する前記バージョンの１つの少なくとも一部をプッシュするステップを含む。
【０３９４】
本発明の実施形態は、また、メディアアイテムを表現するデータを保存するサーバからメディアアイテム（例えばビデオ）を表現するメディアデータを受信するための方法を提供するのであって、少なくともその時間セグメントは、複数のバージョンによって表現され、方法は、クライアント装置によって実施される以下のステップ、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するステップと、
・記述ファイルをサーバから受信するステップであって、前記記述ファイルはデータのセットに対するポインタを含むステップと、
・サーバから、非要請データを受信するステップであって、前記非要請データは前記データのセットに属するステップと
を有する。
【０３９５】
上述のように、非要請データは、クライアント装置の復号器のためのイニシャライゼーションデータ（その場合には前記非要請データにより復号器をイニシャライズするステップが提供されてもよい）、および／または、少なくとも時間セグメントを表現する前記バージョンの１つの一部（その場合には非要請データの少なくとも一部を復号するステップが提供されてもよい）を含んでもよい。
【０３９６】
前記要求は、プッシュされるメディアデータを決定する際にサーバを支援することができる、クライアント装置における復号化を定義する少なくとも１つのプレファレンスを含んでもよい。
【０３９７】
前記要求は、また、クライアント装置がプッシュされたデータを受け入れるというインディケータを含んでもよく、それに基づいて、サーバは、データをプッシュすることを効率的に決定することができる。
【０３９８】
上記したように、非要請データを受信するステップに関連するとともに、そのステップに先立って、プッシュプロミスを受信するステップを備えてもよい。このプッシュプロミスを受信するステップは、記述ファイルを受信するステップに先立って行われてもよい。
【０３９９】
プッシュプロミスは、非要請データおよび／または非要請データに関連付けられた信頼度の識別を含んでもよい。
クライアント装置において、以下のステップ、
・プッシュプロミス内に含まれるデータに基づいてプッシュプロミスの受理または拒否を決定するステップと、
・拒否の場合には前記非要請データをプッシュしないための命令を送信するステップとが有していてもよい。
【０４００】
以下のステップ、
・非要請データに関連付けられ且つプッシュプロミス内に含まれた信頼度に基づいて、プッシュプロミスの受理または拒否を決定するステップと、
・拒否の場合には前記非要請データをプッシュしないための命令を送信するステップとが用いられてもよい。
受信に際して前記非要請データをバッファするステップは、これらのデータを復号する前に用いられてもよい。
プッシュされたデータがイニシャライゼーションデータおよび／または初期のメディアデータに対してのみ対応するように意図されるように以下のステップ、
・記述ファイルに、およびプッシュプロミス内に含まれるデータに基づいて要求される（すなわち、プッシュされるようには計画されない）データ（例えばビデオデータ）を決定するステップと、
・決定されたデータに対する要求を、サーバに対して送信するステップと
が実施されてもよい。
【０４０１】
本発明の実施形態は、また、クライアント装置に対して、メディアアイテムを表現するデータを保存するサーバからメディアアイテム（例えばビデオ）を表現するメディアデータをストリーミングする方法を提案し、メディアアイテムの少なくとも時間セグメントは、複数のバージョンによって表現され、前記方法は、
・前記クライアント装置が、時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するステップと、
・サーバが、クライアント装置から要求を受信するステップと、
・サーバが、記述ファイル内でポインタが指すデータのセットの中のデータを選択するステップと、
・サーバが、クライアント装置に対して記述ファイルを送信するステップと、
・サーバが、クライアント装置に対して選択されたデータをプッシュするステップと、・クライアント装置が、サーバから記述ファイルを受信するステップと、
・クライアント装置が、サーバから選択されたデータを受信するステップと
を有する。
【０４０２】
本発明の実施形態は、また、サーバからメディアアイテム（例えばビデオ）を表現するメディアデータを提供するための装置を提供するのであって、サーバは、メディアアイテムを表現するデータを保存し、少なくともその時間セグメントは、複数のバージョンによって表現され、前記装置は、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をクライアント装置から受信するように構成された受信器と、
・記述ファイル内でポインタが指すデータのセットの中のデータを選択するように構成された選択モジュールと、
・クライアント装置に対して記述ファイルを送信するように構成されたモジュールと、・クライアント装置に対して選択されたデータをプッシュするように構成されたモジュールと
を有する。
本発明の実施形態は、また、メディアアイテムを表現するデータを保存するサーバからメディアアイテム（例えばビデオ）を表現するメディアデータを受信するための装置を提供するのであって、少なくともその時間セグメントは、複数のバージョンによって表現され、前記装置は、
・時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するように構成されたモジュールと、
・サーバから記述ファイルを受信するように構成されたモジュールであって、前記記述ファイルがデータのセットに対するポインタを含むモジュールと、
・サーバから非要請データを受信するように構成されたモジュールであって、前記非要請データは前記データのセットに属するモジュールと
を有する。
【０４０３】
最後に、本発明の実施形態は、メディアアイテムを表現するデータを保存するサーバからメディアアイテム（例えばビデオ）を表現するメディアデータをクライアント装置に対してストリーミングするためのサーバおよびクライアント装置を有するシステムを提供し、メディアアイテムの少なくとも時間セグメントは、複数のバージョンによって表現され、
・前記クライアント装置は、時間セグメントを表現するバージョンに対する時間セグメントおよびそれぞれのポインタを表現するバージョンの記述を含む記述ファイルを求める要求をサーバに送信するように構成されたモジュールを有し、
・前記サーバは、クライアント装置から要求を受信するように構成されたモジュールと、記述ファイル内でポインタが指すデータのセットの中のデータを選択するように構成された選択モジュールと、クライアント装置に対して記述ファイルを送信するように構成されたモジュールと、クライアント装置に対して選択されたデータをプッシュするように構成されたモジュールと、を有し、
・クライアント装置は、サーバから記述ファイルを受信するように構成されたモジュールと、サーバから選択されたデータを受信するように構成されたモジュールと、を有する、を前記システムは有する。
メディアデータを提供する方法、およびメディアデータを受信する方法のために以上に提案されたオプション機能は、また、メディアデータをストリーミングする方法に対して、および前述の各種装置およびシステムに対して適用する。
【０４０４】
特許請求の範囲の単語「備える（ｃｏｍｐｒｉｓｉｎｇ）」は、他の要素またはステップを除外せず、また、不定冠詞「ａ」または「ａｎ」は、複数のものを除外しない。単一のプロセッサまたは他のユニットは、特許請求の範囲内の列挙された、いくつかのアイテムの機能を実現してもよい。個別の機能が個別の従属請求項内に相互に列挙されるという単なる事実は、これらの機能の組み合わせを有利に用いることができない、ということを示すものではない。特許請求の範囲内の任意の参照符号も、また、本発明の範囲を制限するものとして解釈するべきでない。
【図１ａ】
2020047303.tif 000003
【図１ｂ】
2020047303.tif 000004
【図１ｃ】
2020047303.tif 000005
【図１ｄ】
2020047303.tif 000006
【図１ｅ】
2020047303.tif 000007
【図２】
2020047303.tif 000008
【図３】
2020047303.tif 000009
【図４ａ】
2020047303.tif 000010
【図４ｂ】
2020047303.tif 000011
【図５】
2020047303.tif 000012
【図５ａ】
2020047303.tif 000013
【図５ｂ】
2020047303.tif 000014
【図６】
2020047303.tif 000015
【図７ａ】
2020047303.tif 000016
【図７ｂ】
2020047303.tif 000017
【図８】
2020047303.tif 000018
【図９】
2020047303.tif 000019
【図１０】
2020047303.tif 000020
【図１１】
2020047303.tif 000021
【図１２】
2020047303.tif 000022
【図１３】
2020047303.tif 000023
【図１４ａ】
2020047303.tif 000024
【図１４ｂ】
2020047303.tif 000025
【図１５ａ】
2020047303.tif 000026
【図１５ｂ】
2020047303.tif 000027
【図１６】
2020047303.tif 000028
【図１７】
2020047303.tif 000029
【図１８ａ】
2020047303.tif 000030
【図１８ｂ】
2020047303.tif 000031
【図１９】
2020047303.tif 000032
【図２０】
2020047303.tif 000033
【図２１】
2020047303.tif 000034
【図２２】
2020047303.tif 000035
【図２３】
2020047303.tif 000036
【図２４】
2020047303.tif 000037
【図２５】
2020047303.tif 000038
【図２６】
2020047303.tif 000039
【図２７】
2020047303.tif 000040
【図２８】
2020047303.tif 000041