JP6538061B2 - クライアント端末にマルチメディアコンテンツのコンテンツ部分を提供する方法及び対応するキャッシュ - Google Patents

Description

本開示は一般に、例えばこれに限定されないがＨＴＴＰ（HyperText Transfer Protocol）を介した適応ストリーミング技術分野に関連し、特にクライアント端末にマルチメディアコンテンツのコンテンツ部分を提供する方法であって、クライアント端末とリモートサーバとの間の伝送経路にキャッシュが配置される、方法に関する。

この項目では、技術の様々な側面を読者に紹介することを意図し、その後説明及び／又は請求される本開示の様々な側面に関連し得る。ここでの検討は、本開示の様々な側面のより良い理解を容易にする背景情報を読者に提供する手助けとなると確信する。その結果、これらの記述はこの観点で読まれるべきであり、先行技術に対する自白と理解すべきではない。

ＨＴＴＰ（マルチビットレートスイッチングとも呼ばれる）を介した適応ストリーミング（adaptive streaming）は、マルチメディアコンテンツの配布において急速に主要な技術となってきている。既に利用されているＨＴＴＰ適応ストリーミングプロトコルの中で、最も有名なものは、アップルのＨＴＴＰライブストリーミング（ＨＬＳ：HTTP Live Streaming）、マイクロソフトのシルバーライトスムースストリーミング（ＳＳＳ：Silverlight Smooth Streaming）、アドビのアドビダイナミックストリーミング（ＡＤＳ：Adobe Dynamic Streaming）、ＳＡ４グループ内で３ＧＰＰにより開発されたＨＴＴＰを介した動的適応ストリーミング（ＤＡＳＨ：Dynamic Adaptive Streaming over HTTP）である。

適応ストリーミングにおいてクライアント端末がオーディオビジュアルコンテンツ（すなわち、Ａ／Ｖコンテンツ）の再生を希望するときは、どのようにＡ／Ｖコンテンツを入手可能かということを記述したファイルを最初に入手しなければならない。これは通常、いわゆるマニフェスト（manifest）と呼ばれる説明ファイルをＵＲＬ（Uniform Resource Locator）から入手することによりＨＴＴＰプロトコル経由で達成されるが、他の手段（例えば、同報通信（broadcast）
、電子メール、ＳＭＳ等）によっても達成できる。マニフェストは、通常、そのようなＡ／Ｖコンテンツ（ビットレート、解像度や他の特性の観点で）の入手可能なリプレゼンテーション（representation）（インスタンスやバージョンとも呼ばれる）のリストを作成し、ここで品質レベル（ビットレート）毎に一つのリプレゼンテーションである。各リプレゼンテーションは、同じ継続時間のチャンク（chunk）の連続でできていて、個別のＵＲＬによりアクセスでき、クライアントの選択に対して添付される説明要素の組を有している。このマニフェストは、事前に生成され、クライアント端末に例えばリモートサーバにより配布される。

実際に、Ａ／Ｖコンテンツに対応するデータのストリームは、異なる品質のＨＴＴＰサーバ上で入手可能である。最高品質は、高いビットレートに関連し、最低品質は、低いビットレートに関連している。このことは、ネットワークの状態が大きく変化を受ける可能性がある多くの異なる端末への配布を可能とする。

各リプレゼンテーションのデータストリーム全体は、同じ継続時間のチャンクに分割されることにより、クライアント端末が２つのチャンク間で一つの品質レベルから他の品質レベルへスムーズに移行することが可能となる。その結果、ビデオ品質は再生中に変化することがあるが、めったに中断（いわゆるフリーズ）に悩まされることが無くなる。

クライアント側において、チャンクは伝送経路の利用可能な帯域幅（bandwidth）の測定に基づいて選択される。特に、クライアント端末は通常、符号化ビットレートに対応するチャンクのリプレゼンテーションをリクエストするので、測定された帯域幅に準拠した品質である。

キャッシュが、良くあるようにクライアント端末とリモートサーバ間の伝送経路にあるとき、所定のチャンクの一つのリプレゼンテーションはこのキャッシュに既に保存されているかも知れず、それは他のクライアントが同じリプレゼンテーションの同じチャンクを以前リクエストしていた場合、又はコンテンツデリバーネットワーク（ＣＤＮ：Content Deliver Network）がキャッシュの中のチャンクを既に供給していた場合である。したがって、所定のチャンクに関するＨＴＴＰリクエストに対する応答は、チャンクがリモートサーバから来る場合よりも早く、重複した伝送を回避することが可能となり、効率的にネットワークリソースをセーブすることが可能となる。

それにもかかわらず、ＨＴＴＰ適応ストリーミングは、キャッシュしにくいように見える（すなわち、少なくとも例えばＨ２６４−ＳＶＣとしてのいわゆる層状化ベースのスイッチングと比較するとキャッシュしづらい）。実際、もし第１のクライアント端末が所定のチャンクのリプレゼンテーションｒをリクエストし、第２のクライアント端末が、第１のクライアント端末及びキャッシュと伝送経路の一部を共用し、所定のチャンク（より高い又はより低い品質で）のリプレゼンテーションｒ’をリクエストしたとすると、キャッシュはヒットせずに、輻輳の発生するリストを伴う、キャッシュとサーバ間のネットワークセグメント上でより高い負荷を発生する。キャッシュすることの利益は、したがって完全に無くなり、キャッシュはこれまでは状況を改善することは出来ない。

本開示は、ネットワークの輻輳（congestion）を防止し、特にクライアント端末と一つ以上のリモートサーバ間の伝送経路に位置するキャッシュをできる限り動作させようとすることに取り組む。

本開示はクライアント端末にマルチメディアコンテンツのコンテンツ部分を提供する方法であって、一つ以上のキャッシュがクライアント端末とリモートサーバとの間の伝送経路に配置され、複数の離プレゼンテーションが利用可能である、方法に関連し、以下を含む点において優れた方法である：
−第１のキャッシュで、クライアント端末からその中から選択可能な利用可能なリプレゼンテーションの組（set）に属するコンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するステップであって、リクエストはさらに組の他に取り得るリプレゼンテーションのリストとリクエストの範囲を特定する補助情報を含む、受信するステップと、
−第１のキャッシュで所定のリプレゼンテーションがキャッシュに保存されているか否かを検査するステップと、
−所定のリプレゼンテーションがキャッシュされていない場合、第１のキャッシュでリスト上の他に取り得るリプレゼンテーションをブラウズするステップ。

これにより、本開示のお陰で、クライアント端末（すなわち、ＨＴＴＰ適応ストリーミングクライアント端末）と対応する元のサーバ間の終端間のトラフィックの削減をキャッシュ手段により行うことが可能となり、キャッシュヒットの数が増加する。この目的を達成するために、キャッシュは、クライアント端末により送信されたリクエストのディレクティブ（directive）をサポートするように構成され、それにより所定のリプレゼンテーションがキャッシュされていないときに、このディレクティブに含まれる他に取り得るリプレゼンテーションがフェッチされる。これによりクライアント端末と元のサーバ間のより少ないトラフィックへと導かれ、結果として、より少ない輻輳になる。このように、本開示は、サーバからのチャンクのダウンロードの必要性を制限することにより、エンドユーザにより良いユーザ体験を提供することができる。

好ましい実施形態の第１の態様において、補助情報（auxiliary information）がクライアントとサーバの間に配置される残りのキャッシュの数を規定でき、所定のリプレゼンテーション及び他に取り得るリプレゼンテーションが保存されていない場合に、補助情報によりリクエストを次のキャッシュへ転送することが可能となる。

特に、残りのキャッシュの最後のキャッシュが、所定のリプレゼンテーション及び他に取り得るリプレゼンテーションを持っていないときに、エラーメッセージがクライアントに送信され得る。

好ましい実施形態の第２の態様において、補助情報は伝送経路に配置される最後のキャッシュを規定でき、それにより、所定のリプレゼンテーションと他に取り得るリプレゼンテーションがこれ以降のキャッシュに保存されていない場合は、リクエストは最後のキャッシュにより転送されない。

有利なことに、最後のキャッシュが所定のリプレゼンテーションと他に取り得るリプレゼンテーションを持たないときは、エラーメッセージは、クライアントに送信されないことができる。

さらに、他に取り得るリプレゼンテーションは望ましい順番で好ましくはブラウズされ、他に取り得るリプレゼンテーションは、例えば、望ましさが減っていく順番でリスト化される。

さらに、それぞれの他に取り得るリプレゼンテーションは、好ましくは所定のリプレゼンテーションの一つより低い対応するビットレートを有する。当然、変形例としては、少なくとも１つの他に取り得るリプレゼンテーションが所定のリプレゼンテーションの一つより高い対応するビットレートを有することもあり得る。

さらに、組の利用可能な各リプレゼンテーションは有利にはクライアント端末とリモートサーバの間の伝送経路の帯域幅と最大でも等しい対応するビットレートを有することができる。

好ましい実施形態の別の態様としては、使用される伝送プロトコルがＨＴＴＰで、リクエストは、ＨＴＴＰリクエストであり、ＨＴＴＰリクエストのキャッシュ制御拡張（Cache Control extension）は他に取り得るリプレゼンテーションのリストを含んでいる。

変形例又は補足として、リクエストは付加情報（additional information）を含むことにより、もしキャッシュされていれば、リクエストされたリプレゼンテーション又はリストに記載された他に取り得るリプレゼンテーションを返し、あるいは、所定のリプレゼンテーション及びリストに記載された他に取り得るリプレゼンテーションがキャッシュされていない場合は、応答メッセージを返す。

具体的には、使用される伝送プロトコルがＨＴＴＰの場合、付加情報は、ＨＴＴＰリクエストのキャッシュ制御拡張内に含まれる。

さらに、本開示は、またクライアント端末にマルチメディアコンテンツのコンテンツ部分を提供するように構成されたキャッシュに関し、キャッシュはクライアント端末とリモートサーバの間の伝送経路上に配置され、コンテンツ部分の複数のリプレゼンテーションが利用可能である。

本開示によるキャッシュは、以下のものを含む。
−クライアント端末からのコンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するインタフェースモジュールであって、コンテンツ部分は利用可能なリプレゼンテーションの中から選択された利用可能なリプレゼンテーションに属し、リクエストは、さらに、組の他に取り得るリプレゼンテーションのリスト及びリクエストの範囲を特定する補助情報を含む、インタフェースモジュールと、
−所定のリプレゼンテーションが保存されているか否かを検査する制御モジュールと、
−所定のリプレゼンテーションがキャッシュされていない場合に、リストに記載された他に取り得るリプレゼンテーションをブラウズするブラウジングモジュール。

好ましくは、他に取り得るリプレゼンテーションは、望ましい順にブラウズされ得る。

好ましい実施形態の第１の態様は、補助情報がクライアントとサーバ間に配置される残りのキャッシュの数を規定し、それにより所定のリプレゼンテーション及び他に取り得るリプレゼンテーションが保存されていない場合にリクエストを次のキャッシュに転送し、キャッシュにおいて、残りのキャッシュの数がゼロの場合には、リクエストは好ましくは転送されないことが可能になる。

好ましい実施形態の別の態様では、補助情報は、伝送線路に配置される最後のキャッシュを規定し、リクエストは好ましくは下記の場合に転送され得ない。
−所定のリプレゼンテーション及び他に取り得るリプレゼンテーションがキャッシュに保存されていない場合、且つ
−キャッシュが最後のキャッシュである場合。

開示された実施形態の範囲に対応するいくつかの態様が以下で説明される。これらの態様は単に本開示が取りうるいくつかの形式で概要を読者に提供するためのものであり、これらの態様は、本開示の範囲の制限を意図するものではないことを理解されたい。実際に、本開示は後述されない多くの態様を包含するものである。

本開示は、下記の実施形態や実施例による説明により、制限的な方法ではなく、添付図面を参照してより理解される。

本開示が実装され得るクライアントサーバネットワークアーキテクチャの概略図である。 本開示の好ましい実施形態によるクライアント端末の実施例のブロック図である。 本開示の好ましい実施形態によるキャッシュの実施例のブロック図である。 図３のキャッシュにより実装された所定のチャンクのリプレゼンテーションを検索する方法を説明するフロー図である。

図１から図３において、示されたブロックは、純粋に機能的なエンティティであり、物理的な個別のエンティティに対応する必要はない。すなわち、これらはソフトウェア、ハードウェアの形態で開発され、又は１つ以上のプロセッサを含む１つ以上の集積回路として実装することも可能である。

可能な限り、同じ参照番号は全ての図面において同じ又は類似の要素に使用される。

本開示の図面及び説明は本開示の明確な理解に関連する要素の説明を簡略化したものであり、典型的なデジタルマルチメディアコンテンツ配信方法やシステムにおいて見られる多くの他の要素を明確さのために除外している点を理解されたい。しかしながら、そのような要素は当該技術分野において良く知られるので、そのような要素の詳細な議論はここでは提供しない。ここでの本開示は、当業者に知られているそのような変形や改良を対象にしている。

好ましい実施態様にしたがって、本開示はＨＴＴＰ適応ストリーミングプロトコルに関して説明される。もちろん、本開示は、そのような特定の環境に制限されるものではなく、他の適応ストリーミングプロトコルも考慮され、実装され得る。

図１で説明するように、本開示が実装される得るクライアントサーバネットワークアーキテクチャは、クライアント端末Ｃ、ゲートウェイＧＷ、一つ以上のＨＴＴＰサーバＳ（図１には１つしか示していない）を含む。

クライアント端末Ｃは、第１のネットワークＮ１（例えばホームネットワーク又は企業のネットワーク）を介してゲートウェイＧＷに接続され、第２のネットワークＮ２（例えばインターネットネットワーク）を介してリモートサーバＳに保存されたマルチメディアコンテンツをリクエストし得る。第１のネットワークＮ１は、ゲートウェイＧＷのお陰で第２のネットワークＮ２に接続される。

ＨＴＴＰサーバＳは、クライアントからのリクエストに応じて、１つ以上のＴＣＰ／ＩＰ接続を介してＨＴＴＰ適応ストリーミングプロトコルを使用して、クライアント端末Ｃにチャンクをストリーミングする。

図２に記載された好ましい実施形態にしたがって、クライアント端末Ｃは、少なくとも下記を含む：
−第１のネットワークＮ１への接続インタフェース１（有線及び／又は無線、例えばＷｉ−Ｆｉ、イーサネット（登録商標）等）；
−ＨＴＴＰサーバＳと通信するプロトコルスタックを含む通信モジュール２。具体的には、通信モジュール２は、当該技術分野でよく知られるＴＣＰ／ＩＰスタックを含む。もちろん、クライアント端末ＣのＨＴＴＰサーバＳとの通信を可能にする他のいかなるタイプのネットワーク及び／又は通信手段であっても良い；
−ＨＴＴＰサーバＳからＨＴＴＰストリーミングマルチメディアコンテンツを受信する、適応ストリーミングモジュール３。これは対応するビットレートが後述される制約により適合するチャンクのリプレゼンテーションを継続的に選択する；
−マルチメディアコンテンツのデコード及びレンダリングに適合したビデオプレーヤ４；
−クライアント端末Ｃの不揮発性メモリに保存されたアプリケーションとプログラムを実行する１つ以上のプロセッサ５；
−ビデオプレーヤ４に伝送される前にＨＴＴＰサーバＳから受信したチャンクをバッファする、例えば揮発性メモリ等の記憶手段６；
−いくつかのモジュール及び一般的なクライアント端末の機能を実行する技術分野の当業者に周知の全ての手段に接続される内部バスＢ１。

一例として、クライアント端末Ｃは、ポータブルメディアデバイス、携帯電話、タブレット又はラップトップである。当然、クライアント端末Ｃは、完全なビデオプレーヤを含んでいないかも知れないが、メディアコンテンツの逆多重化や復号を行うような部分要素のいくつかのみを含み、エンドユーザに復号済みコンテンツを表示する外部手段に依存しても良い。この場合は、クライアント端末Ｃは、セットトップボックスのようなＨＴＴＰ適応ストリーミング（ＨＡＳ）対応ビデオデコーダである。

図１に記載された好ましい実施形態によると、ゲートウェイＧＷは、キャッシュＲを含み、このキャッシュＲはクライアント端末ＣとサーバＳの間の伝送経路に配置される。変形例としては、キャッシュＲは、第１のネットワークＮ１のプロキシの中又は伝送経路の他の位置に配置され得る。

以下では、クライアント端末ＣがＨＴＴＰ適応ストリーミング（ＨＡＳ）マルチメディアコンテンツをリモートサーバＳに対してリクエストし、ＨＡＳマルチメディアコンテンツは、一連のチャンクから作成されるいくつかのリプレゼンテーションとして利用可能であると仮定する。各リプレゼンテーションの品質は、メディア符号化の品質、メディア符号化のタイプ（例えば２Ｄ対３Ｄ）、メディア符号化カラースキーム等に関連してくることを理解されたい。

この目的を達成するために、図２に示したように、クライアント端末Ｃは、さらに下記を含む。
−伝送経路の帯域幅を推定する、帯域幅推定器７
−クライアント端末Ｃがリクエストし得る利用可能なリプレゼンテーションの組を判定するように構成された、選択モジュール８。利用可能なリプレゼンテーションは、マルチメディアコンテンツの所定のチャンクＩ_ｎの利用可能なリプレゼンテーションの中から選択され、利用可能なリプレゼンテーションは、関連するマニフェストにリスト化される。具体的には、モジュール８による、所定のチャンクＩ_ｎの利用可能なリプレゼンテーションの組の判定は、例えば下記のような一つ以上のパフォーマンス基準に基づく：
・推定器７による帯域幅の推定；
・クライアント端末Ｃの性能；
・以前にリクエストされたチャンクＩ_ｎ−１のリプレゼンテーション；
・クライアント端末Ｃのエンドユーザにより要求される体験品質。

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

「利用可能な（allowable）」リプレゼンテーションの意味は、実装に依存することを理解されたい。実際に、以前リクエストされたチャンクＩ_ｎ−１のリプレゼンテーションを比較することにより、所定のチャンクＩ_ｎのリプレゼンテーションの品質は、アップグレード又はダウングレードを意味し得る。

もし所定のチャンクＩ_ｎのリクエストされたリプレゼンテーションが以前にリクエストされたチャンクＩ_ｎ−１のリプレゼンテーションより対応する品質が著しく低い（例えばエンドユーザに可視で）場合は、選択モジュール８は利用可能な帯域幅による制限がある場合を除いて、動作中の潜在的なキャッシュされたチャンクの品質をさらにダウングレードしないように構成され得る。

説明の役に立ち、且つ制限的ではない本開示に準拠している実施例において、所定のチャンクＩ_ｎの利用可能なリプレゼンテーション（マニフェスト中にリスト化された利用可能なリプレゼンテーションから選ばれた）は、推定される帯域幅にほぼ等しい対応するビットレート（所定の品質に関連した）を有する。さらに、組の利用可能なリプレゼンテーションのビットレートは、その品質がクライアント端末Ｃのエンドユーザによって受け入れられない条件下で所定の閾値に少なくとも等しくとも良い。

明らかなように、変形例又は補足として、判定された利用可能なリプレゼンテーションの組は、推定帯域幅より高いビットレートの一つ以上のリプレゼンテーションを含み、それによりキャッシュＲに既に保存されているリプレゼンテーションをフェッチできる。

さらに、適応ストリーミングモジュール３は、利用可能なリプレゼンテーションの組からＨＡＳマルチメディアコンテンツの所定のチャンクＩ_ｎの好ましいリプレゼンテーション（preferred representation）ｒをリクエストするように構成される。例えば、チャンクＩ_ｎの好ましいリプレゼンテーションｒは、推定帯域幅より一寸低い関連するビットレートを有するリプレゼンテーションに対応することができる。

この目的を達成するために、通信モジュール２は、ＨＴＴＰリクエストを送信し、ここで、そのヘッダのキャッシュ制御拡張がディレクティブ「ａｌｔｌｉｓｔ」を含み、クライアント端末Ｃは、好ましいリプレゼンテーションｒがキャッシュされていない場合にキャッシュＲによって返される別のリプレゼンテーションｒ’を望ましい順番又は優先順位にしたがってリスト化する。

「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションｒ’は、判定された組の利用可能なリプレゼンテーションに好ましくは対応する。明らかなように、追加のリプレゼンテーション（例えば、推定される帯域幅より高いビットレートを持つ）が追加される。

以下で、「ａｌｔｌｉｓｔ」ディレクティブを含んでいるＨＴＴＰリクエストの実例を示す：

好ましい実施形態によるキャッシュＲは「ａｌｔｌｉｓｔ」ディレクティブをサポートし、そのコンテンツを解釈するように構成されていると理解されたい。そのようなキャッシュＲは、以下では「スマート（smart）」キャッシュと呼び、他のキャッシュはレガシーキャッシュ（別名非スマートキャッシュ）と呼ばれる。

この目的を達成するために、好ましい実施形態にしたがって、図３に示されるようにスマートキャッシュＲは、以下を含む：
−例えば揮発性メモリ及び／又は永久メモリであり、マルチメディアコンテンツのリクエストをするクライアント端末Ｃへの伝送の前に一つ以上のサーバＳから受信したマルチメディアコンテンツのチャンクを保存する、記憶モジュール９；
−クライアント端末Ｃからコンテンツ部分の好ましいリプレゼンテーションｒに関するＨＴＴＰリクエストを受信するインタフェースモジュール１０であって、好ましいリプレゼンテーションｒは、利用可能なリプレゼンテーションの組に属する、インタフェースモジュール１０。ＨＴＴＰリクエストは「ａｌｔｌｉｓｔ」ディレクティブ内で他に取り得るリプレゼンテーションｒ’を示し、他に取り得るリプレゼンテーションｒ’は、好ましいリプレゼンテーションｒがキャッシュされていない場合に、クライアント端末Ｃにより代替品として受け入れられ得る。
−スマートキャッシュＲが既にリクエストされた好ましいリプレゼンテーションｒを持っているか否かを検査するように構成された、制御モジュール１１；
−好ましいリプレゼンテーションｒがキャッシュされていない場合に、クライアント端末Ｃにより送信されたＨＴＴＰリクエストの「ａｌｔｌｉｓｔ」ディレクティブ中にリスト化された他に取り得るリプレゼンテーションを望ましい順にブラウズするように適合された、ブラウジングモジュール１２。変形例としては、制御モジュール及びブラウジングモジュールは、ただ一つのモジュールを形成する。

クライアント端末Ｃから所定のチャンクＩ_ｎの好ましいリプレゼンテーションｒに関するそのようなＨＴＴＰリクエストの受信に応じて、スマートキャッシュＲの制御モジュール１１は好ましいリプレゼンテーションｒがキャッシュされているか否かを検査する。
−キャッシュされている場合は、スマートキャッシュＲは、クライアント端末Ｃに好ましいリプレゼンテーションｒを返す。
−キャッシュされていない場合は、ブラウジングモジュール１２は、他に取り得るリプレゼンテーションｒ’がキャッシュされているか否か望ましい順番の連続検査に対して、ＨＴＴＰリクエストの「ａｌｔｌｉｓｔ」ディレクティブをブラウズする。

「ａｌｔｌｉｓｔ」ディレクティブのそのような他に取り得るリプレゼンテーションｒ’がキャッシュされているとき、スマートキャッシュＲは、クライアント端末Ｃに他に取り得るリプレゼンテーションｒ’を返す。

「ａｌｔｌｉｓｔ」の他に取り得るリプレゼンテーションｒ’が一つもキャッシュされていない場合は、スマートキャッシュＲは、クライアント端末ＣによってサーバＳに送信されたＨＴＴＰリクエストをリリース（release）するように構成される。

リリースされたＨＴＴＰリクエストは、その後、スマートキャッシュＲとリモートサーバＳの間の伝送経路にある次のキャッシュによって捉えられ、もし次のキャッシュがスマートキャッシュなら、スマートキャッシュＲとして振る舞う。そうでない場合は（次のキャッシュが「ａｌｔｌｉｓｔ」ディレクティブをサポートしていない場合）、エラーメッセージが返されるか、又はサーバＳに対するＨＴＴＰリクエストがリリースされ得る。

改良版としては、クライアント端末Ｃの通信モジュール２により送信されたＨＴＴＰリクエストが、補助ディレクティブ（補助情報を定義する）「Ｔｉｍｅ−Ｔｏ−Ｌｉｖｅ」（ＴＴＬ）をヘッダのキャッシュ制御拡張に含むことができる。「Ｔｉｍｅ−Ｔｏ−Ｌｉｖｅ」ディレクティブ（トークンとも呼ばれる）は、「ａｌｔｌｉｓｔ」ディレクティブを繰り返し利用することを可能にする。この目的を達成するために、ＴＴＬディレクティブ（ＨＴＴＰリクエストの範囲を指定する）は、クライアント端末ＣとサーバＳの間に配置された残りのキャッシュ（スマートキャッシュ又はレガシーキャッシュ）の数を定義するＴＴＬ値と関連し、それにより、好ましいリプレゼンテーション及び他に取り得るリプレゼンテーションが保存されていない場合に、次のキャッシュにリクエストを転送することが可能となる。実際に、クライアント端末からリクエストを受信する各キャッシュ（スマートキャッシュ又はレガシーキャッシュ）が処理し、リクエストのＴＴＬ値をデクリメントしながら転送する。リクエストのＴＴＬ値がゼロに等しいとき、リクエストは、最早転送されず、エラーコード（例えば４１２）と共に応答がクライアント端末Ｃに送信され得る。失敗の理由が応答に追加されることもできる。

以下で「ａｌｔｌｉｓｔ」及び「ＴＴＬ」ディレクティブを含むＨＴＴＰリクエストの実例を示す：

さらなる改良版又は補足として、クライアント端末Ｃの通信モジュール２によって送信されたＨＴＴＰリクエストは、補助ディレクティブ「ｕｎｔｉｌ ｅｌｅｍｅｎｔ」ディレクティブをヘッダのキャッシュ制御拡張に含むことができる。「ｕｎｔｉｌ ｅｌｅｍｅｎｔ」ディレクティブ（ＨＴＴＰリクエストの範囲を指定する）は、最後のキャッシュを特定する値（例えば、キャッシュのＩＰアドレス、修飾ドメイン名、又は他の種類の識別子）と関連している。

「ｕｎｔｉｌ ｅｌｅｍｅｎｔ」ディレクティブは、それ以降のキャッシュが好ましいリプレゼンテーション又は「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションを含まない場合、所定の最後のキャッシュに到達したときは誰にもＨＴＴＰリクエストを転送しない点を除いて、ＴＴＬディレクティブと同様に動作する。その場合、エラーコード（例えば４１２）を含む応答は、好ましくは生成され、クライアント端末Ｃに送信される。失敗の理由が応答に追加されることもできる。

図４に示したように、好ましい実施形態によるキャッシュＲは、クライアント端末ＣにＨＡＳマルチメディアコンテンツの所定のチャンクＩ_ｎのリクエストされたリプレゼンテーションを提供するための以下のメカニズムＭを実施するように構成される。メカニズムＭは、以下のステップを含む：
−クライアント端末Ｃから以前に定義した利用可能なリプレゼンテーションの組に属する所定のチャンクＩ_ｎ部分の好ましいリプレゼンテーションに対するＨＴＴＰリクエストを受信するステップ（ステップ Ｓ０）。ＨＴＴＰリクエストは、さらに、組の他に取り得るリプレゼンテーションをリスト化する「ａｌｔｌｉｓｔ」ディレクティブを含む。；
−好ましいリプレゼンテーションｒが記憶モジュール９に保存されているか検査するステップ（ステップ Ｓ１）；
−好ましいリプレゼンテーションｒがキャッシュされていない場合に、「ａｌｔｌｉｓｔ」ディレクティブにリスト化された他に取り得るリプレゼンテーションｒ’を望ましい順にブラウズするステップ（ステップ Ｓ２）；
−他に取り得るリプレゼンテーションのいずれもがスマートキャッシュＲの記憶モジュール９にキャッシュされていないとき、サーバＳに対するＨＴＴＰリクエストをリリースするステップ（ステップ Ｓ３）。

好ましい実施形態の変形例として、クライアント端末Ｃから送信されたＨＴＴＰリクエストのキャッシュ制御拡張は、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」という名前の追加のディレクティブ（追加情報を規定する）をさらに含む。「ａｌｔｌｉｓｔ」ディレクティブは、キャッシュ制御ヘッダの「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」ディレクティブ上の優先順位を維持する。以下で上述のディレクティブを含むＨＴＴＰリクエストの例を示す：

変形例として、所定のチャンクＩ_ｎの好ましいリプレゼンテーションｒに関するＨＴＴＰリクエスト（「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」及び「ａｌｔｌｉｓｔ」の両方を含む）の受領に応答して、スマートキャッシュＲは、好ましいリプレゼンテーションｒがキャッシュされているか否かを検査する：
−キャッシュされている場合、スマートキャッシュＲは、クライアント端末Ｃに好ましいリプレゼンテーションＲを返す；
−キャッシュされていない場合、ブラウジングモジュール１２は、一つの別のリプレゼンテーションｒ’がキャッシュされているか否か望ましい順での連続する検査のためＨＴＴＰリクエストの「ａｌｔｌｉｓｔ」ディレクティブをブラウズする。

「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションｒ’がキャッシュされている場合、スマートキャッシュＲは、クライアント端末Ｃに他に取り得るリプレゼンテーションｒ’を返す。

「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションｒ’が一つもキャッシュされていない場合は、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」ディレクティブのお陰で、スマートキャッシュＲが次にエラーメッセージ（例えば「http/1.1 504 altlistがサポートされている」）を返すように構成され、これらは以下のことを示す：
−好ましいリプレゼンテーションｒがキャッシュされていない；
−キャッシュＲが「ａｌｔｌｉｓｔ」ディレクティブをサポートしており、そのようなエラーメッセージの受領から「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションのいずれもがキャッシュされてないことが導き出せる。

さらなるステップで、クライアント端末Ｃは、サーバＳから直接所定のチャンクＩ_ｎの好ましいリプレゼンテーションｒを検索するためにリモートサーバＳに新たなリクエストを送信できる。この目的のために、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」ディレクティブ又は「ａｌｔｌｉｓｔ」ディレクティブのいずれもがこの新たなリクエストのヘッダで使用されない。明らかなように、この新たなリクエストは、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」ディレクティブを含まず、「ａｌｔｌｉｓｔ」ディレクティブのみを含むことができる。

本明細書に開示された参照、請求項及び図面は、独立して、又は適切な組合せとして提供され得る。特徴は、適切であれば、ハードウェア、ソフトウェア又はそれらの組合せとして実装することができる。

請求項における参照番号は、説明のためのものであり、請求項の範囲を制限する効果を持つものではない。

好ましい実施形態に記載された本開示は、発明能力を行使することなく、本技術分野の当業者の能力の範囲内で多くの変形例や実施形態を許容できることは明白である。したがって、開示の範囲は、添付の請求項の範囲により規定される。

添付請求項において、特定の機能を実現する手段として表現された構成要素（例えば、適応ストリーミングモジュール３、帯域幅推定器７、選択モジュール８、制御モジュール１１、ブラウジングモジュール１２等）は、これらの機能を実施するためのいかなる方法、例えば、ａ）機能を実行する回路要素の組合せ（例えば一つ以上のプロセッサ）又はｂ）ファームウェア、マイクロコード等、機能を実施するためのソフトウェアを実行するための適切な回路との組合せ等を含むいかなる形式のソフトウェアも包含することを意図する。請求項によって規定される本原理は、様々な引用される手段によって提供される機能性が請求項が請求する態様で結合され、組み合わせられるという事実に存在する。したがって、これらの機能を提供できるいかなる手段も本明細書に示されたものと均等物と見なされる。
ここでいくつかの付記を記載する。
（付記１）
マルチメディアコンテンツのコンテンツ部分をクライアント端末に提供する方法であって、一つ以上のキャッシュが前記クライアント端末とリモートサーバとの間の伝送経路に配置され、前記コンテンツ部分の複数のリプレゼンテーションが利用可能であり、前記方法が、
第１のキャッシュで、前記クライアント端末から前記コンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するステップであって、前記コンテンツ部分は、前記利用可能なリプレゼンテーションの中から選択された利用可能なリプレゼンテーションの組に属し、前記リクエストは、さらに、前記組の他に取り得るリプレゼンテーションのリスト及び前記リクエストの範囲を特定する補助情報を含む、受信するステップと、
前記所定のリプレゼンテーションが前記キャッシュに保存されているかを前記第１のキャッシュで検査するステップと、
前記所定のリプレゼンテーションがキャッシュされていない場合に、前記第１のキャッシュでリストに記載された他に取り得るリプレゼンテーションをブラウズするステップと、
を含む、方法。
（付記２）
前記補助情報が、前記クライアントと前記サーバの間に配置された残りのキャッシュの数を規定し、それにより、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが保存されていない場合に、前記リクエストを次のキャッシュに転送することを可能にする、付記１に記載の方法。
（付記３）
前記残りのキャッシュの最後のキャッシュが前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションを有していないとき、エラーメッセージが前記クライアントへ送信される、付記２に記載の方法。
（付記４）
前記補助情報が前記伝送経路に配置された最後のキャッシュを規定し、それにより、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが後ろのキャッシュに保存されていない場合に、前記最後のキャッシュによってリクエストが転送されない、付記１乃至３のいずれか１項に記載の方法。
（付記５）
前記最後のキャッシュが前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションを有しない場合に、エラーメッセージが前記クライアントに送信される、付記４に記載の方法。
（付記６）
前記他に取り得るリプレゼンテーションが望ましい順番でブラウズされる、付記１乃至５のいずれか１項に記載の方法。
（付記７）
各他に取り得るリプレゼンテーションが前記所定のリプレゼンテーションのビットレートよりも低い対応するビットレートを有する、付記１乃至６のいずれか１項に記載の方法。
（付記８）
前記組の各利用可能なリプレゼンテーションが、前記クライアント端末と前記リモートサーバの間の前記伝送経路の帯域幅に最大限で等しい対応するビットレートを有する、付記７に記載の方法。
（付記９）
伝送プロトコルとしてＨＴＴＰが使用され、前記リクエストはＨＴＴＰリクエストであり、前記ＨＴＴＰリクエストのキャッシュ制御拡張が他に取り得るリプレゼンテーションの前記リストを含む、付記１乃至８のいずれか１項に記載の方法。
（付記１０）
前記リクエストが、追加情報を含み、キャッシュされている場合は前記第１のキャッシュがリクエストされたリプレゼンテーション又はリストに記載された他に取り得るリプレゼンテーションを返し、前記所定のリプレゼンテーション及びリストに記載された他に取り得るリプレゼンテーションのいずれもがキャッシュされていない場合は応答メッセージを返す、付記１乃至９のいずれか１項に記載された方法。
（付記１１）
使用される前記伝送プロトコルがＨＴＴＰであり、前記追加情報が前記ＨＴＴＰリクエストの前記キャッシュ制御拡張内に含まれる、付記１０に記載の方法。
（付記１２）
クライアント端末とリモートサーバとの間の伝送経路に配置され、マルチメディアコンテンツのコンテンツ部分を前記クライアント端末に提供するキャッシュであって、前記コンテンツ部分の複数のリプレゼンテーションが利用可能であり、前記キャッシュが、
前記クライアント端末から前記コンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するインタフェースモジュールであって、前記コンテンツ部分は、前記利用可能なリプレゼンテーションの中から選択された利用可能なリプレゼンテーションの組に属し、前記リクエストは、さらに、前記組の他に取り得るリプレゼンテーションのリスト及び前記リクエストの範囲を特定する補助情報を含む、インタフェースモジュールと、
前記所定のリプレゼンテーションが保存されているかを検査する制御モジュールと、
前記所定のリプレゼンテーションがキャッシュされていない場合に、リストに記載された他に取り得るリプレゼンテーションをブラウズするブラウジングモジュールと、
を含む、キャッシュ。
（付記１３）
前記他に取り得るリプレゼンテーションが望ましい順番でブラウズされる、付記１２に記載されたキャッシュ。
（付記１４）
前記補助情報が、前記クライアントと前記サーバの間に配置された残りのキャッシュの数を規定し、それにより、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが保存されていない場合に前記リクエストを次のキャッシュに転送することを可能にし、前記キャッシュにおいて、残りのキャッシュの数がゼロに等しいときは前記リクエストを転送しない、付記１２又は１３に記載のキャッシュ。
（付記１５）
前記補助情報が前記伝送経路に配置された最後のキャッシュを規定し、前記リクエストは、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが前記キャッシュに保存されておらず、且つ、前記キャッシュが前記最後のキャッシュに対応している場合に、転送されない、付記１２乃至１４のいずれか１項に記載のキャッシュ。

Claims (10)

1. マルチメディアコンテンツのコンテンツ部分をクライアント端末に提供する方法であって、一つ以上のキャッシュが前記クライアント端末とリモートサーバとの間の伝送経路に配置され、前記コンテンツ部分の複数のリプレゼンテーションが利用可能であり、前記方法が、
   第１のキャッシュで、前記クライアント端末から前記コンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するステップであって、前記コンテンツ部分は、前記利用可能なリプレゼンテーションの中から選択された利用可能なリプレゼンテーションの組に属し、前記リクエストは、さらに、前記組の他に取り得るリプレゼンテーションのリスト及び前記クライアント端末と前記リモートサーバとの間で前記リクエストの範囲を特定する補助情報を含み、前記補助情報が、前記クライアント端末と前記リモートサーバの間に配置された残りのキャッシュの数を規定し、それにより、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが保存されていない場合に、前記リクエストを次のキャッシュに転送することを可能にする、受信するステップと、
   前記所定のリプレゼンテーションが前記キャッシュに保存されているかを前記第１のキャッシュで検査するステップと、
   前記所定のリプレゼンテーションがキャッシュされていない場合に、前記第１のキャッシュでリストに記載された他に取り得るリプレゼンテーションをブラウズするステップと、
   を含む、方法。
2. 前記残りのキャッシュの最後のキャッシュが前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションを有していないとき、エラーメッセージが前記クライアント端末へ送信される、請求項１に記載の方法。
3. 前記他に取り得るリプレゼンテーションが望ましい順番でブラウズされる、請求項１又は２に記載の方法。
4. 各他に取り得るリプレゼンテーションが前記所定のリプレゼンテーションのビットレートよりも低い対応するビットレートを有する、請求項１乃至３のいずれか１項に記載の方法。
5. 前記組の各利用可能なリプレゼンテーションが、前記クライアント端末と前記リモートサーバの間の前記伝送経路の帯域幅に最大限で等しい対応するビットレートを有する、請求項４に記載の方法。
6. 伝送プロトコルとしてＨＴＴＰが使用され、前記リクエストはＨＴＴＰリクエストであり、前記ＨＴＴＰリクエストのキャッシュ制御拡張が他に取り得るリプレゼンテーションの前記リストを含む、請求項１乃至５のいずれか１項に記載の方法。
7. 前記リクエストが、追加情報を含み、キャッシュされている場合は前記第１のキャッシュがリクエストされたリプレゼンテーション又はリストに記載された他に取り得るリプレゼンテーションを返し、前記所定のリプレゼンテーション及びリストに記載された他に取り得るリプレゼンテーションのいずれもがキャッシュされていない場合は応答メッセージを返す、請求項１乃至６のいずれか１項に記載された方法。
8. 使用される伝送プロトコルがＨＴＴＰであり、前記追加情報が前記ＨＴＴＰのリクエストのキャッシュ制御拡張内に含まれる、請求項７に記載の方法。
9. クライアント端末とリモートサーバとの間の伝送経路に配置され、マルチメディアコンテンツのコンテンツ部分を前記クライアント端末に提供するキャッシュであって、前記コンテンツ部分の複数のリプレゼンテーションが利用可能であり、前記キャッシュが、
   前記クライアント端末から前記コンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するインタフェースモジュールであって、前記コンテンツ部分は、前記利用可能なリプレゼンテーションの中から選択された利用可能なリプレゼンテーションの組に属し、前記リクエストは、さらに、前記組の他に取り得るリプレゼンテーションのリスト及び前記クライアント端末と前記リモートサーバとの間で前記リクエストの範囲を特定する補助情報を含み、前記補助情報が、前記クライアント端末と前記リモートサーバの間に配置された残りのキャッシュの数を規定し、それにより、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが保存されていない場合に、前記リクエストを次のキャッシュに転送することを可能にする、インタフェースモジュールと、
   前記所定のリプレゼンテーションが保存されているかを検査する制御モジュールと、
   前記所定のリプレゼンテーションがキャッシュされていない場合に、リストに記載された他に取り得るリプレゼンテーションをブラウズするブラウジングモジュールと、
   を含む、キャッシュ。
10. 前記他に取り得るリプレゼンテーションが望ましい順番でブラウズされる、請求項９に記載されたキャッシュ。

Images