JP6371836B2 - マルチメディアコンテンツのコンテンツ部分をクライアント端末によって取り出す方法 - Google Patents

Description

本発明は一般に、例えばそれだけには限らないが、ＨＴＴＰ（ハイパーテキスト転送プロトコル）を通した適応ストリーミング技術の領域に関し、具体的には、キャッシュがクライアント端末とリモートサーバーの間の送信経路に沿って配置された、マルチメディアコンテンツのコンテンツ部分をクライアント端末によって取り出す方法に関する。

このセクションは、以下に説明および／または特許請求される本発明の様々な態様に関連させられ得る、技術の様々な態様を読者に導入することを意図されている。この考察は、本発明の様々な態様のより良い理解を容易にするように、背景情報を読者にもたらすために役立つと考えられる。従ってこれらの記述はこの観点から読まれるものであり、従来技術の承認としてではないことが理解されるべきである。

ＨＴＴＰを通した適応ストリーミング（マルチビットレートスイッチングとも呼ばれる）は、急速にマルチメディアコンテンツ配信のための主要な技術になりつつある。すでに使用されているＨＴＴＰ適応ストリーミングプロトコルの中で最も有名なものは、ＡｐｐｌｅからのＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）、ＭｉｃｒｏｓｏｆｔからのＳｉｌｖｅｒｌｉｇｈｔ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ（ＳＳＳ）、ＡｄｏｂｅからのＡｄｏｂｅ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ（ＡＤＳ）、およびＳＡ４グループ内の３ＧＰＰによって開発されたＤｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）である。

クライアント端末が、適応ストリーミングにおいて視聴覚コンテンツ（またはＡ／Ｖコンテンツ）を再生することを望むときは、それはどのようにこのＡ／Ｖコンテンツが取得され得るかを記述したファイルをまず入手しなければならない。これは一般にＵＲＬ（統一資源位置指定子）から記述ファイル、いわゆるマニフェストを入手することによってＨＴＴＰプロトコルを通してなされるが、他の手段（例えばブロードキャスト、電子メール、ＳＭＳなど）によっても達成され得る。マニフェストは基本的に、このようなＡ／Ｖコンテンツの利用可能な表示（インスタンスまたはバージョンとも呼ばれる）を、（ビットレート、解像度、および他の特性の観点から）リストし、品質レベル（ビットレート）ごとに１つの表示となる。各表示は、個別のＵＲＬによってアクセス可能な、等しい持続時間の一続きのチャンク(chunk:データの塊)からなり、クライアントによる選択のために添付された記述要素の組を有する。マニフェストは前もって生成され、例えばリモートサーバーによってクライアント端末に届けられる。

実際、Ａ／Ｖコンテンツに対応するデータのストリームは、様々な品質を有してＨＴＴＰサーバー上において利用可能である。最高の品質は高いビットレートに関連付けられ、最低の品質は低いビットレートに関連付けられる。これは、非常に変化するネットワーク条件を受け得る、多くの異なる端末への配信を可能にする。

各表示のデータストリームの全体は、等しい持続時間のチャンクに分割され、これらはクライアント端末が、２つのチャンクの間で一方の品質から他方に、円滑に切り換え得るようになされる。結果として再生中にビデオ品質は変化し得るが、まれにしか中断（フリーズとも呼ばれる）を受けない。

クライアント側においてチャンクは、送信経路の利用可能な帯域幅の測定値に基づいて選択される。具体的には、クライアント端末は通常、ビットレート符号化、および従って測定された帯域幅に従った品質に対応するチャンクの表示を要求する。

クライアント端末とリモートサーバーの間の送信経路に沿ってキャッシュがあるということはしばしば生じることであり、そのときは、別のクライアントが同じ表示を有する同じチャンクを前に要求した場合、またはコンテンツ配信ネットワーク（ＣＤＮ）がすでにキャッシュ内にチャンクを供給している場合は、所与のチャンクの１つの表示は、すでにキャッシュに記憶されている場合がある。従って所与のチャンクに対するＨＴＴＰ要求に対する応答は、チャンクがリモートサーバーから来る場合よりも高速であり、重複した送信が避けられることができ、ネットワークリソースを効果的に節約する。

それでもＨＴＴＰ適応ストリーミングは、キャッシュにとって都合がよくない（または少なくとも例えばＨ２６４−ＳＶＣなどのいわゆる階層化ベーススイッチングよりは、キャッシュにとって都合がよくない）ように思われる。実際、第１のクライアント端末が所与のチャンクの表示ｒを要求し、キャッシュおよび送信経路の一部を第１のクライアント端末と共有する第２のクライアント端末が、所与のチャンクの表示ｒ’（より高いまたはより低い品質での）を要求した場合は、キャッシュはヒットされず、輻輳を引き起こすリスクを有して、キャッシュとサーバーの間のネットワーク区間における、より高い負荷に繋がる。キャッシングの恩恵は完全に消滅し、現在はキャッシュはこの状況を改善することができない。

本発明は、ネットワーク輻輳の防止に焦点を当て、具体的には、クライアント端末と１つまたはいくつかのリモートサーバーの間の送信経路に沿って配置される可能性があるキャッシュを動作させることを試みる。

本発明は、キャッシュがクライアント端末とサーバーの間の送信経路に沿って配置された、マルチメディアコンテンツのコンテンツ部分を上記クライアント端末によって取り出す方法に関し、上記コンテンツ部分のいくつかの表示が利用可能であり、
この方法は、以下の構成、
Ａ／ 上記コンテンツ部分の上記利用可能な表示の中から選択された、許容できる表示の組に属する、上記コンテンツ部分の第１の表示に対する要求を送るステップ、
Ｂ／ 上記第１の表示がキャッシュされていない場合は、上記第１の表示がキャッシュされていないことを示す、上記キャッシュからの応答メッセージを受信するステップ、
を含むという点で注目すべきであり、上記の構成において、応答メッセージを受信すると、１つの要求された代替表示が上記キャッシュから上記クライアント端末によって受信されるまで、または上記組のすべての許容できる表示が要求されるまで、ステップＡ／およびステップＢ／は、上記第１の表示とは異なる、上記コンテンツ部分の代替表示を用いて連続して繰り返される。

従って本発明によれば、キャッシングによって、クライアント端末（すなわちＨＴＴＰ適応ストリーミングクライアント端末）と、対応する配信元サーバーとの間のエンドツーエンドトラフィックを低減することが可能になり、これはキャッシュヒットの数を増加させることを目指す。この目的のためにクライアント端末は、送信経路に沿ったキャッシュにすでに記憶された表示を優先してフェッチすることを試みるように構成され得る。それによりクライアント端末と配信元のサーバーの間のより少ないトラフィックに至り、そして結果として、より少ない輻輳に繋がる。従って本発明は、サーバーからチャンクをダウンロードする必要性を制限するので、エンドユーザにより良いユーザエクスペリエンスをもたらすことができる。

本発明に従う好ましい実施形態によれば、上記代替表示は、上記第１の表示のものより低い対応するビットレートを有する。変形としてまたは補足として、上記代替表示のビットレートは、上記第１の表示のものより高くすることができる。

さらに上記好ましい実施形態によれば上記方法は、上記クライアント端末と上記リモートサーバーの間の上記送信経路に沿った帯域幅を推定するさらなるステップを含む。

加えて上記組の各許容できる表示は、最大限でも上記推定された帯域幅に等しい対応するビットレートを有することが好ましい。

上記好ましい表示のビットレートは、上記推定された帯域幅をわずかに下回ることが有利である。

本発明のさらなる態様では、上記決定された許容できる表示の組において、上記表示は選好の順序で、例えば高い方のビットレートから低い方のビットレートに減少順にリストされ得ることが有利である。

上記好ましい実施形態によれば上記要求は、少なくとも１つの指令を備え、それにより上記キャッシュは、キャッシュされている場合は上記要求された表示を返し、または上記第１の表示がキャッシュされていない場合は上記応答メッセージを返すことが有利である。

具体的には、用いられる送信プロトコルがＨＴＴＰである場合は、上記要求はＨＴＴＰ要求であり、上記ＨＴＴＰ要求のキャッシュ制御ヘッダは、指令「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」を備えることができる。同じ意味を上記キャッシュに運ぶために、代替として他の指令が用いられ得ることは明らかである。

本発明に従う変形としてまたは補足として、上記キャッシュが、応答メッセージを送る前に、上記リストの代替表示がキャッシュされているかどうかをチェックできるように、上記要求は、上記第１の表示がキャッシュされていない場合に上記クライアント端末によって要求され得る、上記決定された組の代替表示を、選好の順序でもたらすように構成された１つの追加の指令を、さらに備えることができる。

加えて、用いられる送信プロトコルがＨＴＴＰである場合は、上記追加の指令は、上記ＨＴＴＰ要求の上記キャッシュ制御ヘッダ内に含まれ得る。

さらに本発明はまた、マルチメディアコンテンツのコンテンツ部分を取り出すように構成された端末に関し、キャッシュは上記端末とサーバーの間の送信経路に沿って配置され、上記コンテンツ部分のいくつかの表示が利用可能である。

本発明によれば、上記端末は、
− 決定された許容できる表示の組に属する、上記コンテンツ部分の第１の表示に対する要求を送り、
− 上記第１の表示がキャッシュされていない場合は、上記第１の表示がキャッシュされていないことを示す、上記キャッシュからの応答メッセージを受信する
ように構成されたモジュールを備え、従って、上記キャッシュから応答メッセージを受信すると、上記モジュールは、１つの要求された代替表示が上記キャッシュから上記クライアント端末によって受信されるまで、または上記組のすべての許容できる表示が要求されるまで、上記第１の表示とは異なる、上記コンテンツ部分の代替表示に対する少なくとも１つの新しい要求を送る。

さらに、上記端末は、上記コンテンツ部分の上記利用可能な表示の中で、上記端末が要求し得る許容できる表示の組を決定するように構成された選択モジュールを追加として備えることができる。

加えて上記要求は、少なくとも１つの指令を備え、それにより上記キャッシュは、キャッシュされている場合は上記要求された表示を返し、または上記第１の表示がキャッシュされていない場合は上記応答メッセージを返すことが有利である。

開示される実施形態の範囲に相応するいくつかの態様が、以下に記述される。これらの態様は単に、本発明がとり得るいくつかの形の簡潔な概要を読者にもたらすために示され、これらの態様は本発明の範囲を限定することを目的とするものではないことが理解されるべきである。実際、本発明は以下に記述されない場合がある多様な態様を包含し得る。

本発明は、添付の図を参照して、全く限定するものではない以下の実施形態および実施例によって、より良く理解され示されるであろう。

本発明が実現され得る、クライアントサーバーネットワークアーキテクチャの概略図である。 本発明の好ましい実施形態によるクライアント端末の例のブロック図である。 所与のチャンクの要求された表示がキャッシュにキャッシュされている場合の、図２のクライアント端末と、送信経路に沿って配置されたキャッシュとの間で交換される、ＨＴＴＰ要求および応答を示す図である。 所与のチャンクの要求された表示がキャッシュにキャッシュされていない場合の、図２のクライアント端末と、送信経路に沿って配置されたキャッシュとの間で交換される、ＨＴＴＰ要求および応答を示す図である。 図２のクライアント端末によって実現される、所与のチャンクの表示を取り出す方法を示すフローチャートである。

図１および図２において、表示されるブロックは単に機能エンティティであり、これらは必ずしも物理的に別々のエンティティに対応しない。すなわちそれらはソフトウェア、ハードウェアの形で開発されることができ、あるいは１または複数のプロセッサーを備えた１つまたはいくつかの集積回路において実現され得る。

可能な限り、同じまたは同様な部分を指すために、図の全体にわたって同じ参照番号が用いられる。

本発明の図および説明は、本発明の明瞭な理解のために関連のある要素を示すように簡略化されており、分かりやすくするために通常のディジタルマルチメディアコンテンツ配信方法およびシステムにおいて見られる多くの他の要素を取り除いていることが理解されるべきである。しかしこのような要素は当技術分野ではよく知られているので、本明細書ではこのような要素の詳しい考察は示されない。本明細書における開示は、当業者に知られているすべてのこのような変形および変更に向けられる。

好ましい実施形態によれば、本発明はＨＴＴＰ適応ストリーミングプロトコルに関連して示される。当然ながら本発明は、このような特定の環境に限定されず、もちろん他の適応ストリーミングプロトコルも考慮され、実現され得る。

図１に示されるように、本発明が実現され得るクライアントサーバーネットワークアーキテクチャは、クライアント端末Ｃ、ゲートウェイＧＷ、および１または複数のＨＴＴＰサーバーＳ（図１には１つだけ表示される）を備える。

第１のネットワークＮ１（ホームネットワークまたは企業ネットワークなど）を通してゲートウェイＧＷに接続されたクライアント端末Ｃは、第２のネットワークＮ２（インターネットネットワークなど）を通して、リモートサーバーＳに記憶されたマルチメディアコンテンツを要求することを望み得る。第１のネットワークＮ１は、ゲートウェイＧＷのおかげで第２のネットワークＮ２に接続される。

ＨＴＴＰサーバーＳは、クライアント要求の後、１または複数のＴＣＰ／ＩＰ接続を通したＨＴＴＰ適応ストリーミングプロトコルを用いて、クライアント端末Ｃにチャンクをストリーミングする。

図２に示されるような好ましい実施形態によれば、クライアント端末Ｃは少なくとも以下を備える：
− 第１のネットワークＮ１に対する接続のインターフェース１（有線および／または無線、例えばＷｉ−Ｆｉ、イーサネットなど）
− ＨＴＴＰサーバーＳと通信するためのプロトコルスタックを含んだ通信モジュール２。具体的には通信モジュール２は、当技術分野でよく知られているＴＣＰ／ＩＰスタックを備える。もちろんこれは、クライアント端末ＣがＨＴＴＰサーバーＳと通信することを可能にする、任意のタイプのネットワークおよび／または通信手段とすることができる。
− ＨＴＴＰサーバーＳからＨＴＴＰストリーミングマルチメディアコンテンツを受信する、適応ストリーミングモジュール３。これはその対応するビットレートが、本明細書で後に述べられる制約条件により良く適合する、チャンクの表示を連続的に選択する。
− マルチメディアコンテンツを復号し、レンダリングするように適合されたビデオプレーヤ４
− クライアント端末Ｃの不揮発性メモリに記憶されたアプリケーションおよびプログラムを実行するための、１または複数のプロセッサー５
− ＨＴＴＰサーバーＳから受信したチャンクを、ビデオプレーヤ４へのそれらの送信の前にバッファするための、揮発性メモリなどの記憶手段６
− 一般的なクライアント端末機能を行うための、当業者にはよく知られた様々なモジュールおよびすべての手段を接続するための内部バスＢ１

例としてクライアント端末Ｃは、ポータブルメディアデバイス、携帯電話、タブレットまたはラップトップである。当然ながらクライアント端末Ｃは、完全なビデオプレーヤではなく、エンドユーザに対してメディアコンテンツを逆多重化および復号するためのものなどのいくつかの部分要素のみを備え得る。この場合はクライアント端末Ｃは、セットトップボックスなどの、ＨＴＴＰ適応ストリーミング（ＨＡＳ）対応のビデオデコーダである。

図１に示される好ましい実施形態によれば、ゲートウェイＧＷは、クライアント端末ＣとサーバーＳの間の送信経路に沿って配置された、キャッシュＲを備える。変形ではキャッシュＲは、第１のネットワークＮ１のプロキシ内に、または送信経路に沿った任意の他の場所に配置され得る。

以下では、クライアント端末ＣはリモートサーバーＳに対して、ＨＴＴＰ適応ストリーミング（ＨＡＳ）マルチメディアコンテンツを要求し、ＨＡＳマルチメディアコンテンツは、一続きのチャンクからなるいくつかの表示において利用可能であることが仮定される。各表示の品質は、メディア符号化品質、メディア符号化タイプ（例えば２Ｄに対して３Ｄ）、メディア符号化配色方式などに関連すると理解されるべきである。

この目的のために、図２に示されるようにクライアント端末Ｃは、以下をさらに備える。
− 送信経路の帯域幅を推定するように構成された帯域幅推定器７
− クライアント端末Ｃが要求し得る、許容できる表示の組を決定するように構成された選択モジュール８。許容できる表示は、関連付けられたマニフェスト内にリストされたような、マルチメディアコンテンツの所与のチャンクｌ_nの利用可能な表示の中から選択される。具体的にはモジュール８による、所与のチャンクｌ_nの許容できる表示の組の決定は、例えば以下のような１つまたはいくつかの性能基準に基づくことができる。
・ 推定器７によって推定された帯域幅
・ クライアント端末Ｃの能力
・ 前に要求されたチャンクｌ_n-1の表示
・ クライアント端末Ｃのエンドユーザによって必要とされるエクスペリエンスの品質

明らかなように選択モジュール８は、変形では適応ストリーミングモジュール３内に統合され得る。

「許容できる」表示の意味は、実現形態に依存することが理解され得る。実際、これは前に要求されたチャンクｌ_n-1の表示と比べて、所与のチャンクｌ_nの引き上げられたまたは引き下げられた品質の表示を意味し得る。

所与のチャンクｌ_nの要求された表示が、前に要求されたチャンクｌ_n-1の表示のものより著しく低い（すなわちエンドユーザによって目に見える）対応する品質を有する場合は、選択モジュール８は、利用可能な帯域幅によって制約される場合を除いて、可能性があるキャッシュされたチャンクの動作において、品質をさらに引き下げるように試みないように構成され得る。

本発明に従う例示の、非限定的な例では、所与のチャンクｌ_nの許容できる表示（マニフェストにリストされた利用可能な表示から選択される）は、最大限でも推定された帯域幅に等しい対応するビットレート（所与の品質に関連した）を有する。加えて、組の許容できる表示のビットレートはまた、それより低い品質はクライアント端末Ｃのエンドユーザによって許容できない、規定された閾値に少なくとも等しくすることができる。

明らかなように変形としてまたは補足として、決定された許容できる表示の組は、キャッシュＲにすでに記憶された表示をフェッチすることを試みるために、推定された帯域幅より高いビットレートを有する１または複数の表示を備えることができる。

さらに適応ストリーミングモジュール３は、許容できる表示の組から、ＨＡＳマルチメディアコンテンツの所与のチャンクｌ_nの第１の表示ｒ（好ましい表示とも呼ばれる）を要求するように構成される。例えばチャンクｌ_nの第１の表示ｒは、推定された帯域幅よりわずかに低い、関連付けられたビットレートを有する表示に対応し得る。

この目的のために通信モジュール２は、ＨＴＴＰ要求を送り、そこでは例えばそのヘッダのキャッシュ制御拡張部は、指令「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」を備える。以下は、このようなＨＴＴＰ要求の例である。

従って図３Ａおよび３Ｂに示されるように、指令「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」を構文解析することによって、キャッシュＲは、キャッシュされている場合は第１の表示ｒ（図３Ａ参照）、または応答としてエラーメッセージＭ_err（図３Ｂ参照）を返すことになる。

好ましい実施形態では、クライアント端末Ｃによって、キャッシュＲからエラーメッセージＭ_errを受信すると（すなわち第１の表示ｒはキャッシュされていない）、適応ストリーミングモジュール３は、決定された表示の組からの代替表示ｒ’を要求する。代替表示ｒ’は、第１の表示ｒのものよりわずかに低いビットレートを有することが好ましい。

次いで第１の表示ｒを得るために用いられたものと同様な新しい要求が、通信モジュール２によって送られ、キャッシュＲによってインターセプトされ、それはそれがこの代替表示ｒ’を含んでいるかどうかをチェックする。

同様に代替表示ｒ’がキャッシュされていないときは、クライアント端末ＣにエラーメッセージＭ_errが送られる。代替表示ｒ’がキャッシュされている場合は、キャッシュＲはクライアント端末Ｃに代替表示ｒ’を返す。

好ましい実施形態によれば、所与のチャンクｌ_nの第１の表示ｒがキャッシュされていない場合は、クライアント端末ＣはキャッシュＲから、要求された表示をキャッシュＲがもたらすまで、または組のすべての許容できる表示が要求されてしまう場合まで、品質が低下する順序で、代替表示ｒ’のそれぞれを連続してダウンロードするように試みる。

いずれの許容できる表示もキャッシュされていないときは、クライアント端末Ｃは再びリモートサーバーＳから、所与のチャンクｌ_nの表示、例えば推定された帯域幅をわずかに下回るビットレートを有する第１の表示ｒを要求する。この目的のためにクライアント端末ＣによってサーバーＳに、ヘッダのキャッシュ制御拡張部内に指令「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」を有しない、新しいＨＴＴＰ要求が送られる。

図４に示されるように好ましい実施形態によれば、クライアント端末Ｃは、所与のチャンクｌ_nを取り出すための以下の機構Ｍ１を実現するように構成され、機構Ｍ１は以下のステップを含む。

− クライアント端末ＣとリモートサーバーＳの間の送信経路に沿った、利用可能な帯域幅を推定する（ステップＳ０）
− 所与のチャンクｌ_nの利用可能な表示から選択された、許容できる表示の組を決定する（ステップＳ１）
− 推定された帯域幅より厳密に低いビットレートを好ましくは有する、チャンクｌ_nの第１の表示ｒに対するＨＴＴＰ要求を送る（ステップＳ２）
− キャッシュＲから以下を受信する（ステップＳ３）
・ キャッシュされている場合は、第１の表示ｒ（図３Ａ参照）、または
・ 第１の表示ｒがキャッシュされていない場合は、エラーメッセージＭ_err（図３Ｂ参照）
− キャッシュＲからエラーメッセージＭ_errを受信すると、決定された許容できる表示の組に属する、チャンクｌ_nの代替表示ｒ’に対するＨＴＴＰ要求を送る（ステップＳ４）。代替表示ｒ’は、前に要求された表示ｒとは異なる。

エラーメッセージＭ_errを受信すると、ステップＳ４は、キャッシュＲから１つの代替表示ｒ’がクライアント端末Ｃに返されるまで、または成功することなく組のすべての許容できる表示が要求されるまで、繰り返される。

さらに、好ましい実施形態の変形では、許容できる表示の組を決定する（ステップＳ１）代わりに、クライアント端末Ｃは、選好の順序で（例えばそれだけには限らないが、高い方から低い方のビットレートに）、対応するマニフェストにリストされた任意の利用可能な表示を連続して要求して（推定された帯域幅より高い関連付けられたビットレートを有するものさえも）、キャッシュＲにすでに記憶された表示をフェッチすることを試みることができる。

好ましい実施形態の他の変形では、クライアント端末Ｃによって送られるＨＴＴＰ要求ヘッダのキャッシュ制御拡張部は、「altlist」と名付けられた追加の指令をさらに備えることができる。この追加の指令「altlist」は、クライアント端末Ｃが、第１の表示ｒがキャッシュされていない場合にキャッシュＲによって返され得る代替表示ｒ’を、選好のまたは優先度の順序でリストすることを可能にする。以下は、このようなＨＴＴＰ要求の例である。

「altlist」指令の代替表示ｒ’は、決定された組の許容できる表示に対応し得る。明らかなように、追加の表示（例えば、推定された帯域幅より高いビットレートを有する）が加えられ得る。

「altlist」指令は、キャッシュＲがそれをサポートするように構成されたときにのみ正しく働くことが留意されるべきである（このようなキャッシュは「スマート」キャッシュと呼ばれる）。この後者の場合は「altlist」指令は、キャッシュ制御ヘッダの「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」指令よりも高い優先度を有する。「altlist」指令を解釈できないキャッシュは、「レガシー」キャッシュと名付けられる。

従ってキャッシュＲがスマートキャッシュであると考えることにより、所与のチャンクｌ_nの第１の表示ｒに対するこのようなＨＴＴＰ要求（指令「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」および指令「altlist」の両方を含む）を受信すると、スマートキャッシュＲは第１の表示ｒがキャッシュされているかどうかをチェックする。キャッシュされている場合はスマートキャッシュＲは、第１の表示ｒをクライアント端末Ｃに返す。キャッシュされていない場合はそれは、「altlist」指令を参照して、１つの代替表示ｒ’がキャッシュされているかどうかを選好の順序によって連続してチェックする。

このような「altlist」指令の代替表示ｒ’がキャッシュされているときは、スマートキャッシュＲは、代替表示ｒ’をクライアント端末Ｃに返す。

「altlist指令」のいずれの代替表示ｒ’もキャッシュされていない場合は、スマートキャッシュＲは、以下をともに示す、エラーメッセージＭ_err（例えば「ＨＴＴＰ／１．１ ５０４ altlist＿ｓｕｐｐｏｒｔｅｄ」）を返すように構成される。
− 第１の表示ｒはキャッシュされていない。
− キャッシュＲは「altlist」指令をサポートし、従ってこのようなエラーメッセージＭ_errの受信から、「altlist」指令のいずれの代替表示ｒ’もキャッシュされていないことが導き出され得る。

さらなるステップではクライアント端末Ｃは、サーバーＳから直接、所与のチャンクｌ_nの第１の表示ｒを取り出すために、新しい要求をリモートサーバーＳに送る。この目的のために、この新しい要求のヘッダには、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」指令または「altlist」指令のいずれも用いられない。

さらに、キャッシュＲがレガシーキャッシュである（それは「altlist」指令をサポートしない）と考えることにより、所与のチャンクｌ_nの第１の表示ｒに対するＨＴＴＰ要求（「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」指令および「altlist」指令を含む）を受信すると、レガシーキャッシュＲは、第１の表示ｒがキャッシュされているかどうかをチェックする。

キャッシュされている場合はレガシーキャッシュＲは、第１の表示ｒをクライアント端末Ｃに返す。キャッシュされていない場合はレガシーキャッシュＲは、「altlist」指令を参照することができず、エラーメッセージＭ_err（例えば「ＨＴＴＰ／１．１ ５０４ Ｇａｔｅｗａｙ＿ｔｉｍｅｏｕｔ」）を返す。

このようなエラーメッセージＭ_errを受信すると、クライアント端末Ｃは、一方ではレガシーキャッシュＲが第１の表示ｒを有しないこと、他方ではレガシーキャッシュＲは「altlist」指令をサポートしないことを理解する。言い換えればそれは、レガシーキャッシュＲの存在を検出するために、クライアント端末によって用いられ得る。

次いでさらなるステップでは、クライアント端末Ｃは次いで、図４に関連して前述されたように機構Ｍ１に進み、または変形では、所与のチャンクｌ_nの第１の表示ｒを取り出すために、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」指令および「altlist」指令を有しない新しい要求を、リモートサーバーＳに送ることができる。

本発明の他の変形では、クライアント端末Ｃによって送られるＨＴＴＰ要求ヘッダのキャッシュ制御拡張部は、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」指令なしに、「altlist」指令のみを備えることができる。以下は、このようなＨＴＴＰ要求の例である。

スマートキャッシュＲを考えることにより、所与のチャンクｌ_nの第１の表示ｒに対するこのようなＨＴＴＰ要求を受信すると、スマートキャッシュＲは第１の表示ｒがキャッシュされているかどうかをチェックする。

キャッシュされている場合はスマートキャッシュＲは、第１の表示ｒをクライアント端末Ｃに返す。キャッシュされていない場合はそれは、「altlist」指令を参照して、１つの代替表示ｒ’がキャッシュされているかどうかを選好の順序で連続してチェックする。

このような「altlist」指令の代替表示ｒ’がキャッシュされているときは、スマートキャッシュＲは、代替表示ｒ’をクライアント端末Ｃに返す。

「altlist指令」のいずれの代替表示ｒ’もキャッシュされていない場合は、スマートキャッシュＲは、クライアント端末Ｃによって送られたＨＴＴＰ要求を、サーバーＳに向かって解放する。

解放されたＨＴＴＰ要求は、次いで前のスマートキャッシュＲとリモートサーバーＳの間の送信経路に沿った、次のキャッシュによってインターセプトされる可能性があり、従って次のキャッシュがスマートキャッシュである場合は、それは前のスマートキャッシュＲのように機能する。そうでない（次のキャッシュがレガシーキャッシュである）場合は、それはエラーメッセージＭ_errを返すことができ、またはＨＴＴＰ要求をサーバーＳに向かって解放することができる。

さらに、本発明（および具体的には機構Ｍ１）は、専用のクライアントプロキシデバイス（例えばホームゲートウェイ）内に実現され得ることが理解され得る。従ってエンドユーザによって動作されるクライアント端末は、変わらないままとする（すなわちそれは、キャッシングを処理することなく、従来の方法でＨＴＴＰ要求を提出する）ことができ、プロキシデバイスは、機構Ｍ１を実現し、従って前に示されたようにキャッシュ指令を動作させることができる。

明細書、請求項、および図面において開示された参照は、独立にまたは任意の適切な組み合わせにおいてもたらされ得る。特徴は、適切な場合は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現され得る。

請求項において現れる参照番号は例示のためのみであり、請求項の範囲に対して限定的な影響を有するものではない。

本発明はその好ましい実施形態において述べられたが、本発明は当業者の能力内で、発明の能力を用いることなく、数多くの変更形態および実施形態が可能であることが明らかである。従って本発明の範囲は、以下の「特許請求の範囲」によって定義される。

本明細書の請求項において、指定された機能を行うための手段として表されるいずれの要素（例えば適応ストリーミングモジュール３、帯域幅推定器７、選択モジュール８など）も、その機能を行う任意の方法を包含することが意図され、これは例えば、ａ）その機能を行う回路要素（例えば１もしくは複数のプロセッサー）の組み合わせ、またはｂ）任意の形の、従って機能を行うようにそのソフトウェアを実行するための適切な回路と組み合わされたファームウェア、マイクロコードなどを含む、ソフトウェアを含む。このような請求項によって定義される本原理は、様々な列挙された手段によってもたらされる機能が、請求項が要求するやり方で組み合わされ一緒にもたらされるという事実にある。従ってそれらの機能をもたらすことができる任意の手段は、本明細書において示されるものと等価であると見なされる。
［付記１］
マルチメディアコンテンツのコンテンツ部分をクライアント端末（Ｃ）によって取り出す方法であって、キャッシュ（Ｒ）が前記クライアント端末（Ｃ）とサーバー（Ｓ）の間の送信経路に沿って配置され、前記コンテンツ部分のいくつかの表示が利用可能であり、該方法は、
前記コンテンツ部分（ｌ _ｎ ）の前記利用可能な表示の中から選択された、許容できる表示の組に属する、前記コンテンツ部分（ｌ _ｎ ）の第１の表示に対する要求を送る（Ｓ２）、ステップＡ／と、
前記第１の表示がキャッシュされていない場合は、前記第１の表示がキャッシュされていないことを示す、前記キャッシュ（Ｒ）からの応答メッセージ（Ｍ _ｅｒｒ ）を受信する（Ｓ３）、ステップＢ／と、
を含み、応答メッセージ（Ｍ _ｅｒｒ ）を受信すると、１つの要求された代替表示が前記キャッシュ（Ｒ）から前記クライアント端末（Ｃ）によって受信されるまで、または前記組のすべての許容できる表示が要求されるまで、ステップＡ／およびステップＢ／は、前記第１の表示とは異なる、前記コンテンツ部分（ｌ _ｎ ）の代替表示を用いて連続して繰り返される（Ｓ４）、前記方法。
［付記２］
前記代替表示は、前記第１の表示のものより低い対応するビットレートを有する、付記１に記載の方法。
［付記３］
前記クライアント端末（Ｃ）と前記リモートサーバー（Ｓ）の間の前記送信経路に沿った帯域幅を推定する（Ｓ０）、付記１または２に記載の方法。
［付記４］
前記組の各許容できる表示は、最大限でも前記推定された帯域幅に等しい対応するビットレートを有する、付記３に記載の方法。
［付記５］
前記要求は、少なくとも１つの指令を備え、それにより前記キャッシュ（Ｒ）は、キャッシュされている場合は前記要求された表示を返し、または前記第１の表示がキャッシュされていない場合は前記応答メッセージ（Ｍ _ｅｒｒ ）を返す、付記１から４のいずれかに記載の方法。
［付記６］
前記キャッシュ（Ｒ）が、応答メッセージ（Ｍ _ｅｒｒ ）を送る前に、前記リストの代替表示がキャッシュされているかどうかをチェックできるように、前記要求は、前記第１の表示がキャッシュされていない場合に前記クライアント端末（Ｃ）によって要求され得る、前記決定された組の代替表示を、選好の順序でもたらすように構成された１つの追加の指令を、さらに備える、付記５に記載の方法。
［付記７］
用いられる送信プロトコルがＨＴＴＰである場合は、前記要求はＨＴＴＰ要求であり、前記ＨＴＴＰ要求のキャッシュ制御ヘッダは、指令「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」を備える、付記５または６に記載の方法。
［付記８］
前記追加の指令は、前記ＨＴＴＰ要求の前記キャッシュ制御ヘッダ内に含まれる、付記６または７に記載の方法。
［付記９］
マルチメディアコンテンツのコンテンツ部分（ｌ _ｎ ）を取り出すように構成された端末であって、キャッシュ（Ｒ）は前記端末とサーバー（Ｓ）の間の送信経路に沿って配置され、前記コンテンツ部分（ｌ _ｎ ）のいくつかの表示が利用可能であり、該端末は、
− 決定された許容できる表示の組に属する、前記コンテンツ部分（ｌ _ｎ ）の第１の表示に対する要求を送り、
− 前記第１の表示がキャッシュされていない場合は、前記第１の表示がキャッシュされていないことを示す、前記キャッシュ（Ｒ）からの応答メッセージ（Ｍ _ｅｒｒ ）を受信する
ように構成されたモジュール（３）を備え、それによって、前記キャッシュ（Ｒ）から応答メッセージ（Ｍ _ｅｒｒ ）を受信すると、前記モジュール（３）は、１つの要求された代替表示が前記キャッシュ（Ｒ）から前記クライアント端末（Ｃ）によって受信されるまで、または前記組のすべての許容できる表示が要求されるまで、前記第１の表示とは異なる、前記コンテンツ部分（ｌ _ｎ ）の代替表示に対する少なくとも１つの新しい要求を送る、前記端末。
［付記１０］
前記コンテンツ部分（ｌ _ｎ ）の前記利用可能な表示の中で、前記端末（Ｃ）が要求し得る許容できる表示の前記組を決定するように構成された選択モジュール（Ｃ８）をさらに備えた、付記９に記載の端末。
［付記１１］
前記要求は、少なくとも１つの指令を備え、それにより前記キャッシュ（Ｒ）は、キャッシュされている場合は前記要求された表示を返し、または前記第１の表示がキャッシュされていない場合は前記応答メッセージ（Ｍ _ｅｒｒ ）を返す、付記９または１０に記載の端末。

Claims (11)

1. マルチメディアコンテンツのコンテンツ部分をクライアント端末によって取り出す方法であって、キャッシュが前記クライアント端末とサーバーの間の送信経路に沿って配置されるよう構成され、前記コンテンツ部分のいくつかのリプレゼンテーションが利用可能であり、該方法は、
   前記コンテンツ部分の前記利用可能なリプレゼンテーションの中から選択された、許容できるリプレゼンテーションの組に属する、前記コンテンツ部分の第１のリプレゼンテーションに対する要求を送ることと、
   前記第１のリプレゼンテーションがキャッシュされていない場合は、前記第１のリプレゼンテーションがキャッシュされていないことを示す、前記キャッシュからの応答メッセージを受信することと、
   を含み、応答メッセージを受信すると、１つの要求された代替リプレゼンテーションが前記キャッシュから前記クライアント端末によって受信されるまで、または前記組のすべての許容できるリプレゼンテーションが要求されるまで、前記送ることおよび前記受信することは、前記第１のリプレゼンテーションとは異なる、前記コンテンツ部分の代替リプレゼンテーションを用いて連続して繰り返される、前記方法。
2. 前記代替リプレゼンテーションは、前記第１のリプレゼンテーションのものより低い対応するビットレートを有する、請求項１に記載の方法。
3. 前記クライアント端末と前記サーバーの間の前記送信経路に沿った帯域幅を推定することをさらに含む、請求項１または２に記載の方法。
4. 前記組の各許容できるリプレゼンテーションは、最大で前記推定された帯域幅に等しい、対応するビットレートを有する、請求項３に記載の方法。
5. 前記要求は、少なくとも１つの指令を備え、それにより前記キャッシュは、キャッシュされている場合は前記要求されたリプレゼンテーションを返し、または前記第１のリプレゼンテーションがキャッシュされていない場合は前記応答メッセージを返す、請求項１から４のいずれかに記載の方法。
6. 前記キャッシュが、応答メッセージを送る前に、前記コンテンツ部分の代替リプレゼンテーションがキャッシュされているかどうかをチェックできるように、前記要求は、前記第１のリプレゼンテーションがキャッシュされていない場合に前記クライアント端末によって要求され得る、前記選択された組に属する代替リプレゼンテーションを、プリファレンスの順序で与えるように構成された１つの追加の指令を、さらに備える、請求項５に記載の方法。
7. 用いられる送信プロトコルがＨＴＴＰである場合は、前記要求はＨＴＴＰ要求であり、前記ＨＴＴＰ要求のキャッシュ制御ヘッダは、指令「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」を備える、請求項５または６に記載の方法。
8. 前記追加の指令は、前記ＨＴＴＰ要求の前記キャッシュ制御ヘッダ内に含まれる、請求項６を引用する請求項７に記載の方法。
9. マルチメディアコンテンツのコンテンツ部分を取り出すように構成された端末であって、キャッシュは前記端末とサーバーの間の送信経路に沿って配置されるよう構成され、前記コンテンツ部分のいくつかのリプレゼンテーションが利用可能であり、該端末は、
   決定された許容できるリプレゼンテーションの組に属する、前記コンテンツ部分の第１のリプレゼンテーションに対する要求を送り、
   前記第１のリプレゼンテーションがキャッシュされていない場合は、前記第１のリプレゼンテーションがキャッシュされていないことを示す、前記キャッシュからの応答メッセージを受信する
   ように構成されたモジュールを備え、それによって、前記キャッシュから応答メッセージを受信すると、前記モジュールは、１つの要求された代替リプレゼンテーションが前記キャッシュから前記端末によって受信されるまで、または前記組のすべての許容できるリプレゼンテーションが要求されるまで、前記第１のリプレゼンテーションとは異なる、前記コンテンツ部分の代替リプレゼンテーションに対する少なくとも１つの新しい要求を送る、前記端末。
10. 前記コンテンツ部分の前記利用可能なリプレゼンテーションの中で、前記端末が要求し得る許容できるリプレゼンテーションの前記組を決定するように構成された選択モジュールをさらに備えた、請求項９に記載の端末。
11. 前記要求は、少なくとも１つの指令を備え、それにより前記キャッシュは、キャッシュされている場合は前記要求されたリプレゼンテーションを返し、または前記第１のリプレゼンテーションがキャッシュされていない場合は前記応答メッセージを返す、請求項９または１０に記載の端末。