特許 6542346 クライアント端末と少なくとも１つのサーバーの間の伝送経路に沿って配置されたキャッシュを動作させる方法、および対応するキャッシュ

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

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

(11)【特許番号】6542346

(24)【登録日】2019年6月21日

(45)【発行日】2019年7月10日

(54)【発明の名称】クライアント端末と少なくとも１つのサーバーの間の伝送経路に沿って配置されたキャッシュを動作させる方法、および対応するキャッシュ

(51)【国際特許分類】

   H04N 21/239 20110101AFI20190628BHJP

   H04N 21/2183 20110101ALI20190628BHJP

   H04N 21/462 20110101ALI20190628BHJP

   G06F 13/00 20060101ALI20190628BHJP

【ＦＩ】

   H04N21/239

   H04N21/2183

   H04N21/462

   G06F13/00 540B

【請求項の数】13

【全頁数】19

(21)【出願番号】特願2017-500145(P2017-500145)

(86)(22)【出願日】2015年3月12日

(65)【公表番号】特表2017-514416(P2017-514416A)

(43)【公表日】2017年6月1日

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

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

(87)【国際公開日】20150924

【審査請求日】2018年2月14日

(31)【優先権主張番号】14305393.2

(32)【優先日】2014年3月20日

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

(73)【特許権者】

【識別番号】501263810

【氏名又は名称】トムソン ライセンシング

【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(74)【代理人】

【識別番号】100108213

【弁理士】

【氏名又は名称】阿部 豊隆

(72)【発明者】

【氏名】ステファン グワッシュ

(72)【発明者】

【氏名】レミ ホウダイユ

(72)【発明者】

【氏名】シャーリーン タイービ

【審査官】 松元 伸次

(56)【参考文献】

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

【文献】 特表２００５−５３９３１５（ＪＰ，Ａ）

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

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

Ｇ０６Ｆ１３／００

Ｈ０４Ｌ５／１４−５／１８

Ｈ０４Ｎ５／９１−５／９５６

７／１０

７／１４−７／１７３

７／２０−７／５６

２１／００−２１／８５８

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

【請求項1】

クライアント端末と少なくとも１つのサーバーとの間の伝送経路に沿って配置されるように構成されたキャッシュを動作させる方法であって、前記キャッシュは、いくつかのリプレゼンテーションで利用可能なマルチメディアコンテンツのセグメントの要求をクライアント端末から受け取るように構成されており、
第１のクライアント端末から、前記マルチメディアコンテンツの所与のセグメントの好ましいリプレゼンテーションおよび少なくとも１つの代替リプレゼンテーションの第１の要求を受け取ることと、
さらなるクライアント端末のために前記サーバーから前記キャッシュによってすでに要求され、現在前記キャッシュにおいてダウンロード中である、前記第１の要求の前記好ましいリプレゼンテーションまたは代替リプレゼンテーションにマッチする、前記所与のセグメントの現行のリプレゼンテーションを決定することと、
を含むことを特徴とする、前記方法。

【請求項2】

さらなるクライアント端末のために前記キャッシュによってすでに要求されている前記所与のセグメントのマッチした現行のリプレゼンテーションに関連付けられた有用性関数の値を決定することと、
前記有用性関数の値が性能基準を満たすときは、前記キャッシュによってすでに要求された、前記マッチした現行のリプレゼンテーションを、前記第１のクライアント端末に送信することと、
をさらに含む、請求項１に記載の方法。

【請求項3】

前記第１の要求の２つの相異なるリプレゼンテーションにマッチする、少なくとも２つの現行のリプレゼンテーションが、さらなるクライアント端末のために前記キャッシュによってすでに要求されている場合は、最も高い有用性値に関連付けられた前記マッチした現行のリプレゼンテーションは、前記有用性値が前記性能基準を満たすときに送信される、請求項２に記載の方法。

【請求項4】

前記第１の要求の２つの相異なるリプレゼンテーションにマッチする、少なくとも２つの現行のリプレゼンテーションが、さらなるクライアント端末のために前記キャッシュによってすでに要求されている場合は、前記マッチした現行のリプレゼンテーションのいずれも、前記性能基準を満たす有用性値を有しないときは、前記第１の要求の前記好ましいリプレゼンテーションが、前記サーバーに対して前記キャッシュによって要求される、請求項２または３に記載の方法。

【請求項5】

前記性能基準は、前記有用性関数の前記値がゼロを超えたときに満たされる、請求項２から４のいずれか一項に記載の方法。

【請求項6】

前記有用性関数は、少なくとも、
前記有用性関数の値が定数に等しい、アグレッシブモードと、
前記有用性関数が、前記第１の要求の前記好ましいリプレゼンテーションの前記サーバーからの配信時間、および前記キャッシュによってすでに要求されたマッチした現行のリプレゼンテーションの配信時間に依存する、高速モードと、
前記有用性関数が、前記第１の要求の前記好ましいリプレゼンテーションの品質、および前記キャッシュによってすでに要求されたマッチした現行のリプレゼンテーションの品質に依存する、高品質モードと、
を含むモードのグループに属する動作モードに依存する、請求項２から５のいずれか一項に記載の方法。

【請求項7】

前記動作モードは、少なくとも１つのネットワークパラメータの関数として決定される、請求項６に記載の方法。

【請求項8】

前記動作モードは、前記第１のクライアント端末によって選択され、前記第１の要求内で示される、請求項６に記載の方法。

【請求項9】

クライアント端末と少なくとも１つのサーバーの間の伝送経路に沿って位置するように適合され、いくつかのリプレゼンテーションで利用可能なマルチメディアコンテンツのセグメントの要求をクライアント端末から受け取るように構成されたキャッシュを備えるネットワーク機器であって、前記キャッシュは、
第１のクライアント端末から、前記マルチメディアコンテンツの所与のセグメントの好ましいリプレゼンテーションおよび少なくとも１つの代替リプレゼンテーションを求める第１の要求を受け取るための、接続のインターフェースと、
さらなるクライアント端末のために、サーバーから前記キャッシュによってすでに要求され、現在前記キャッシュにおいてダウンロード中である、前記所与のセグメントの少なくとも１つの現行のリプレゼンテーションが、前記第１の要求の前記好ましいリプレゼンテーションまたは代替リプレゼンテーションにマッチするかどうかを決定するように構成された、マッチングモジュールと、
を備えることを特徴とする、前記ネットワーク機器。

【請求項10】

前記キャッシュは、前記マッチングモジュールによって識別された前記所与のセグメントのマッチした現行のリプレゼンテーションに関連付けられた有用性関数の値を決定するように適合された計算器をさらに備える、請求項９に記載のネットワーク機器。

【請求項11】

前記キャッシュは、いくつかの現行のリプレゼンテーションが、前記第１の要求の前記好ましいリプレゼンテーションおよび代替リプレゼンテーションにマッチした場合に、前記有用性関数の最も高い値を有する、前記キャッシュによってすでに要求された前記マッチした現行のリプレゼンテーションを決定するように構成された比較器をさらに備える、請求項１０に記載のネットワーク機器。

【請求項12】

前記比較器が、マッチした現行のリプレゼンテーションの前記有用性関数の前記決定された値が、性能基準を満たすか否かをチェックするようにさらに構成されている、請求項１１に記載のネットワーク機器。

【請求項13】

前記有用性関数は、少なくとも、
前記有用性関数の値が定数に等しい、アグレッシブモードと、
前記有用性関数が、前記第１の要求の前記好ましいリプレゼンテーションの前記サーバーからの配信時間、および前記キャッシュによってすでに要求されたマッチした現行のリプレゼンテーションの配信時間に依存する、高速モードと、
前記有用性関数が、前記第１の要求の前記好ましいリプレゼンテーションの品質、および前記キャッシュによってすでに要求されたマッチした現行のリプレゼンテーションの品質に依存する、高品質モードと、
を含むモードのグループに属する動作モードに依存する、請求項１１または１２に記載のネットワーク機器。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は一般に、例えば非限定的にＨＴＴＰ（ハイパーテキスト転送プロトコル）を通した適応型ストリーミング技術の分野に関し、具体的にはクライアント端末とリモートサーバーの間の伝送経路に沿って配置されたキャッシュの動作の管理に関する。

【背景技術】

【0002】

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

【0003】

適応型ＨＴＴＰストリーミング（マルチビットレートスイッチングとも呼ばれる）は、急速にマルチメディアコンテンツ配布のための主要な技術になりつつある。すでに用いられているＨＴＴＰ適応型ストリーミングプロトコルの中で最も有名なものは、ＡｐｐｌｅからのＨＴＴＰライブストリーミング（ＨＬＳ）、Ｍｉｃｒｏｓｏｆｔからのシルバーライトスムーストリーミング（ＳＳＳ）、Ａｄｏｂｅからのアドビダイナミックストリーミング（ＡＤＳ）、およびＳＡ４グループ内の３ＧＰＰによって開発された動的適応型ＨＴＴＰストリーミング（ＤＡＳＨ）である。

【0004】

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

【0005】

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

【0006】

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

【0007】

クライアント側ではセグメントは、伝送経路の利用可能な帯域幅の尺度に基づいて選択される。具体的にはクライアント端末は通常、ビットレート符号化に対応しセグメントの表示を要求し、従って測定された帯域幅に品質的に適合する。

【0008】

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

【0009】

通常のＨＴＴＰキャッシュは、コンテンツがサーバーから直接到来したかのように、いずれのクライアントに配信されるコンテンツも同じになることを確実にするように努力することにより、透過的にコンテンツに対応するように設計される。

【0010】

ＨＡＳコンテンツ（例えばＤＡＳＨコンテンツ）の配信の場合は、所与のタイムスロットのすべてのビデオ表示は、エンドユーザに対して等価である（すなわちそれらは同じオーディオおよびビデオコンテンツに対応する）が、ビデオ（および場合によってはオーディオ）品質において異なる。ＤＡＳＨシステムでは、ネットワークの技術的制約は最良の品質を維持することを不可能にし、従って様々な品質レベルのセグメント表示を用いることは正常と見なされる。ＤＡＳＨの当初の目標はクライアントが表示の選択を行うことであるが、先進のキャッシュ（スマートキャッシュとも呼ばれる）は、本出願人によって出願された欧州特許出願第１３３０５９０８．９号および第１３３０５９０９．７号に述べられているように、必要な表示がキャッシュ内で利用可能でないときは、代替表示がキャッシュから返されることを可能にすることによって、クライアントが選択の範囲を広げることを可能にする。

【0011】

それでも、複数のクライアントが、重複する表示の異なる選択により、同時に同じリソースを要求（例えば同じプログラムを視聴）して、キャッシュをヒットさせるときに問題が起きる。「同時に」とは、セグメント持続時間より短い間隔で、要求が生じることと理解されるべきである。このような状況はしばしば起こり、配信チェーン全体に対して有害となる。

【0012】

実際、知られているキャッシュ（いわゆるレガシーキャッシュ）の一般の機能は以下の通りである。所与のリソース（Ｘと呼ばれ、ＸはＵＲＬである）を求める要求（Ｒａと呼ばれる）を受け取るとすぐに、要求されたコンテンツがキャッシュされて（例えば前にダウンロードされ、さらなる再使用のために記憶されて）いない場合は、それはリモートサーバーに向かって要求を始め、応答をクライアントに、それがサーバーからそれを受け取り始めるとすぐに、転送を開始する。第２の要求（Ｒｂと呼ばれる）が到着するとすぐに − 現在の要求（Ｒａ）が終わる前に − 同じリソース（Ｘ）に対して、サーバーによる応答コンテンツの任意選択の再確証ステップの後に、同じ応答コンテンツは第２のクライアントに転送され始める。キャッシュされておらずＸとは相異なる別のリソース（Ｙと呼ばれ、ＹはＵＲＬである）を求める別の要求（Ｒｃと呼ばれる）が到着するとすぐに（例えばＤＡＳＨセグメントに対して要求が発せられた場合、Ｘ＝｛ｒｅｐ４｝およびＹ＝｛ｒｅｐ６｝、これは同じコンテンツ内の同じ時間的オフセットを指す）、キャッシュは要求を、前の要求は無関係であるのでそれらと並行して処理する。

【0013】

言い換えれば知られているキャッシュは、同じリソース（Ｘ）を求める要求（Ｒａ、Ｒｂ）を待ち行列に入れ、一方それは、無関係な要求（Ｒｃに対してＲａ、Ｒｂ）を完全に並行したやり方で処理する。これは、明らかな性能および帯域幅効率の理由から非常に望ましい。

【0014】

ＤＡＳＨセグメントを取り出すために上記の要求（Ｒａ、Ｒｂ、Ｒｃ）が発せられた場合には、好ましい表示が許容される代替のリストと一緒に示され（欧州特許出願第１３３０５９０８．９号および第１３３０５９０９．７号に説明されているように）、キャッシュ（スマートキャッシュ）動作は次の通りである。Ｘ＝｛好ましい＝ｒｅｐ４，代替＝［ｒｅｐ６，ｒｅｐ５］｝、およびＹ＝｛好ましい＝ｒｅｐ６，代替＝［ｒｅｐ５，ｒｅｐ４］｝の場合、同じコンテンツ内の同じ時間的オフセットを指していると想定される。知られているキャッシュに対して述べられた上述のシナリオを考察することにより、ならびに好ましいおよび代替表示のいずれもキャッシュされていなかったと想定することによって、キャッシュは、要求（Ｒａ、Ｒｂ）に応答してｒｅｐ４、および（Ｒｃ）に応答してｒｅｐ６に対応したであろう。

【0015】

それでもこのような動作は、２つの以下の問題を提起する：
− キャッシュは要求を、それらの間の潜在的な結びつきを作り出す代替リストを無視しているので、無関係と見なす；
− キャッシュはサーバーから両方の表示をダウンロードしており、場合によってはサーバーとキャッシュの間の経路上の混雑に繋がる。

【0016】

加えて住居用ネットワークでは、少数のデバイスがある場合でも、アクセス帯域幅の欠乏は、所与のセグメントに対する要求の重複を避けることを決定的に重要なものにする。アクセスネットワーク内のキャッシュを考えると、多数の同時のセッションは、コンテンツが可能な代替の多くに対して要求される可能性を非常に高くする。キャッシュがこれらの同時の要求を最適に処理できない場合は、ネットワークは混雑することになる。

【0017】

本発明は、上述の欠点の少なくともいくつかを克服する。

【発明の概要】

【0018】

本発明は、クライアント端末と少なくとも１つのサーバーの間の伝送経路に沿って配置されたキャッシュを動作させる方法に関し、前記キャッシュは、いくつかの表示において利用可能なマルチメディアコンテンツのセグメントを求める要求をクライアント端末から受け取るように構成され、
第１のクライアント端末から、前記マルチメディアコンテンツの所与のセグメントの好ましい表示および少なくとも１つの代替表示を求める第１の要求を受け取るステップと、
さらなるクライアント端末のために前記サーバーから前記キャッシュによってすでに要求されている、上記第１の要求の上記好ましい表示または代替表示にマッチする、前記所与のセグメントの現行の表示を決定するステップと、
を含むことが注目に値する。

【0019】

本発明に適合する実施形態では、前記方法は、
さらなるクライアント端末のために前記キャッシュによってすでに要求されている前記所与のセグメントのマッチした現行の表示に関連付けられた有用性関数の値を決定するステップと、
上記有用性関数の上記対応する決定された値が性能基準を満たすときは、上記キャッシュによってすでに要求された、前記マッチした現行の表示を、上記第１のクライアント端末に送信するステップと、
をさらに含むことができる。

【0020】

本発明により、上記キャッシュは、マッチした好ましい表示および／または代替表示を有する要求の相互依存性を認識させられ得る。これは要求をマッチさせるおよびそれらを順番に並べるための、より多くの機会を作り出し、それによりサーバーとのトラフィック量を低減する。

【0021】

加えて、少なくとも２つの現行の表示 − 上記第１の要求の２つの相異なる表示にマッチする − がさらなるクライアント端末のために前記キャッシュによってすでに要求されている場合は、最も高い有用性値に関連付けられた上記マッチした現行の表示は、前記有用性値が上記性能基準を満たすときに送信され得る。

【0022】

さらに、上記第１の要求の２つの相異なる表示にマッチする、少なくとも２つの現行の表示が、さらなるクライアント端末のために前記キャッシュによってすでに要求されている場合は、上記マッチした現行の表示のいずれも、前記性能基準を満たす有用性値を有しないときは、上記第１の要求の上記好ましい表示が、上記サーバーに対して上記キャッシュによって要求され得る。

【0023】

他の実施形態では上記性能基準は、上記有用性関数の上記値がゼロを超えたときに満たされ得る。

【0024】

他の実施形態では上記有用性関数は、少なくとも、
上記有用性関数の値が定数に等しい、アグレッシブモードと、
上記有用性関数が、前記第１の要求の上記好ましい表示の上記サーバーからの配信時間、および前記キャッシュによってすでに要求されたマッチした現行の表示の配信時間に依存する、高速モードと、
上記有用性関数が、上記第１の要求の上記好ましい表示の品質、および前記キャッシュによってすでに要求されたマッチした現行の表示の品質に依存する、高品質モードと、
を含むモードのグループに属する動作モードに依存し得る。

【0025】

加えて上記動作モードは、少なくとも１つのネットワークパラメータの関数として決定され（例えば上記キャッシュにおいて）、または上記第１のクライアント端末によって、さらなるネットワーク機器によって、上記キャッシュ所有者によって、もしくは第三者によって選択され得る。

【0026】

上記動作モードが上記第１のクライアント端末によって選択された場合は（例えば上記ユーザの好みにより）、上記選択された動作モードは、前記第１の要求内で表示され得る。

【0027】

他の特徴では、上記高速モードの上記有用性関数は、前記第１の要求の上記好ましい表示の上記サーバーからの上記配信時間と、前記キャッシュによってすでに要求されたマッチした現行の表示の上記配信時間との差によって定義され得る。

【0028】

他の特徴では、上記高品質モードの上記有用性関数は、上記好ましい表示の上記品質と、前記キャッシュによってすでに要求されたマッチした現行の表示の上記品質との差によって定義される。

【0029】

本発明はまた、クライアント端末と少なくとも１つのサーバーの間の伝送経路に沿って位置し、いくつかの表示において利用可能なマルチメディアコンテンツのセグメントを求める要求をクライアント端末から受け取るように構成されたキャッシュに関する。前記キャッシュは、
第１のクライアント端末から、前記マルチメディアコンテンツの所与のセグメントの好ましい表示および少なくとも１つの代替表示を求める第１の要求を受け取るための、接続のインターフェースと、
さらなるクライアント端末のためにサーバーから上記キャッシュによってすでに要求された、前記所与のセグメントの少なくとも１つの現行の表示が、上記第１の要求の上記好ましい表示または代替表示にマッチするかどうかを決定するように構成された、マッチングモジュールと、
を備える。

【0030】

加えて前記キャッシュは、前記マッチングモジュールによって識別された上記所与のセグメントのマッチした現行の表示に関連付けられた有用性関数の値を決定するように適合された計算器をさらに備えることができる。

【0031】

さらに前記キャッシュは、いくつかの現行の表示が、上記第１の要求の上記好ましい表示および代替表示にマッチした場合に、上記有用性関数の最も高い値を有する、前記スマートキャッシュによってすでに要求された上記マッチした現行の表示を決定するように構成された比較器をさらに備えることができる。前記比較器は、マッチした現行の表示の上記有用性関数の上記決定された値が、性能基準を満たすか否かをチェックするようにさらに構成され得る。

【0032】

さらに上記有用性関数は、少なくとも、
上記有用性関数の値が定数に等しい、アグレッシブモードと、
上記有用性関数が、前記第１の要求の上記好ましい表示のサーバー（ＳＥ）からの配信時間、および前記キャッシュ（ＤＡＮＥ）によってすでに要求されたマッチした現行の表示の配信時間に依存する、高速モードと、
上記有用性関数が、上記第１の要求の上記好ましい表示の品質、および前記キャッシュ（ＤＡＮＥ）によってすでに要求されたマッチした現行の表示の品質に依存する、高品質モードと、
を含むモードのグループに属する動作モードに依存し得る。

【0033】

加えて、前記第１の要求は、上記動作モードのインディケーションを備えることができる。

【0034】

本発明はさらに、セグメントに分割され、少なくとも１つのリモートサーバーによってもたらされるマルチメディアコンテンツを受け取るように構成されたクライアント端末に関し、各セグメントは１または複数の表示において利用可能である。前記クライアント端末は、前記クライアント端末と１つのサーバーの間の伝送経路に沿って配置されたキャッシュによって適用されることになる選択された動作モードを示す表示を求める要求を送るように構成された通信モジュールを備える。

【0035】

加えて前記クライアントは下記を含むセットに属する：
− ポータブルメディアデバイス；
− 携帯電話；
− ゲーム機；
− セットトップボックス；
− テレビセット；
− タブレット；
− ラップトップ；および
− 集積回路。

【0036】

本発明はまた、クライアント端末によって、１または複数の表示において利用可能なセグメントに分割されたマルチメディアコンテンツのセグメントの表示を求める要求を送る方法に関し、前記マルチメディアコンテンツは、少なくとも１つのリモートサーバーによってもたらされる。前記要求は、前記クライアント端末と１つのサーバーの間の伝送経路に沿って配置されたキャッシュによって適用されることになる選択された動作モードのインディケーションを備える。

【0037】

本発明はさらに、上述の方法の上記ステップを実現するためのプログラムコード命令を備えた、通信ネットワークからダウンロード可能であり、および／またはコンピュータによって読み出し可能な媒体上に記録され、および／またはプロセッサーによって実行可能なコンピュータプログラム製品に関する。

【0038】

加えて本発明はまた、前述の方法の上記ステップを実現するためのプログラムコード命令を含んだ、その上に記録されプロセッサーによって実行されることが可能なコンピュータプログラム製品を備えた、非一時的コンピュータ可読媒体に関する。

【0039】

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

【図面の簡単な説明】

【0040】

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

【図1】本発明が実現され得るクライアント−サーバーネットワークアーキテクチャの概略図である。

【図2A】本発明の好ましい実施形態によるスマートキャッシュクライアントの例のブロック図である。

【図2B】本発明の好ましい実施形態によるクライアント端末の例のブロック図である。

【図3】好ましい実施形態による、図２Ａのスマートキャッシュを動作させる方法を示すフローチャートである。

【図4】アグレッシブモードに対する図３の方法の実現の説明に役立つ例を示す図である。

【図5】高速モードに対する図３の方法の実現の説明に役立つ例を示す図である。

【図6】高品質モードに対する図３の方法の実現の説明に役立つ例を示す図である。

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

図１に示されるように、本発明が実現され得る、１つまたはいくつかのネットワークＮ（図には１つだけが表される）によってサポートされるクライアント−サーバーネットワークアーキテクチャは、１つまたはいくつかのクライアント端末ＣＴ、１または複数のＨＴＴＰサーバーＳＥ、複数のスマートキャッシュＤＡＮＥ、および１または複数のレガシーキャッシュＲＮＥを備える。ＤＡＳＨによればこのようなサーバーＳＥはまた、メディアオリジンと名付けられる。それらは例えば、メディアプレゼンテーション記述（またはＭＰＤ）、いわゆるマニフェストを生成する。これはコンテンツ配布のソースであり、マルチメディアコンテンツはいくつかの外部エンティティから到来することができ、メディアオリジンにおいてＨＡＳフォーマットに変換され得る。

【0046】

スマートキャッシュＤＡＮＥは、ＨＡＳコンテンツが配信されたことを理解するように構成された、ネットワークＮ内のキャッシング要素である。ＭＰＥＧ−ＤＡＳＨ用語を用いるとスマートキャッシュは、ＤＡＳＨアウェアネットワーク要素（ＤＡＮＥ）と見なされる。

【0047】

レガシーキャッシュＲＮＥは、それを通過するデータのタイプの知識を有しない、または少なくともＨＡＳアスペクトを理解しない、ネットワークＮ内のキャッシング要素である。ＭＰＥＧ−ＤＡＳＨ用語ではレガシーキャッシュは、Ｒｅｇｕｌａｒ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ（ＲＮＥ）と見なされる。

【0048】

クライアント端末ＣＴは、ＨＴＴＰサーバーＳＥの１つからマルチメディアコンテンツを取得することを望む。マルチメディアコンテンツは複数のセグメントに分割される。マルチメディアコンテンツは、サーバーＳＥで異なる表示において利用可能であると想定される。ＨＴＴＰサーバーＳＥは、クライアント要求の後すぐに、１または複数のＴＣＰ／ＩＰ接続を通してＨＴＴＰ適応型ストリーミングプロトコルを用いて、セグメントをクライアント端末ＣＴにストリーミングすることができる。

【0049】

好ましい実施形態ではクライアント端末ＣＴは、ポータブルメディアデバイス、携帯電話、タブレットまたはラップトップ、テレビセット、セットトップボックス、ゲーム機、または集積回路である。当然ながらクライアント端末ＣＴは、完全なビデオプレーヤでなく、メディアコンテンツを逆多重化および復号するためのものなどのいくつかの部分要素のみを備える可能性があり、復号されたコンテンツをエンドユーザに表示するために外部手段に依存し得る。この場合は、クライアント端末ＣＴは、セットトップボックスなどのＨＴＴＰ適応型ストリーミング（ＨＡＳ）対応ビデオデコーダである。

【0050】

図２Ａに示されるようにスマートキャッシュＤＡＮＥは以下を備える：
− １または複数の接続のインターフェース１（有線および／または無線）；
− 接続のインターフェース１を通じて通信するためのプロトコルスタックを備えた通信モジュール２。具体的には通信モジュールは、ＩＰスタックと表される、インターネットプロトコルスタックを備えることができる；
− １または複数のサーバーＳＥから受け取ったマルチメディアコンテンツのセグメントを、それらをこのようなマルチメディアコンテンツを要求するクライアント端末ＣＴに送信するために記憶するための、揮発性メモリおよび／または固定記憶装置などの記憶モジュール３；
− 記憶モジュール３に記憶されたアプリケーションおよびプログラムを実行するための１または複数のプロセッサー４；
− 汎用住居用ゲートウェイ機能を行うための様々なモジュール、処理手段、および当業者にはよく知られているすべての手段を接続するための内部バスＢ。

【0051】

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

【0052】

以下では、所与のクライアント端末ＣＴは、マルチメディアコンテンツの所与のセグメントを取得するために、ネットワークＮ上に第１の要求を送ると仮定する。第１の要求は、好ましい要求された表示、および１または複数の代替の要求された表示を備える。このようなタイプの要求は、例えば本出願人によって出願され、参照により本明細書に組み込まれている欧州特許出願第１３３０５９０９．７号に述べられており、要求は、代替表示をリストするための「ａｌｔｌｉｓｔ」追加ディレクティブを用いることができる。

【0053】

好ましい実施形態によればスマートキャッシュＤＡＮＥはまた、以下を備える：
− 所与のセグメントの少なくとも１つの現行の表示 − これはさらなるクライアント端末ＣＴのためにスマートキャッシュＤＡＮＥによってサーバーＳＥにおいてすでに要求されている − が、（所与のクライアント端末ＣＴによって送られた）第１の要求の好ましいまたは代替表示とマッチするかどうかを決定するように構成されたマッチングモジュール５。マッチした現行の表示は、すでにスマートキャッシュＤＡＮＥに記憶されている、または現在ダウンロード中であり得る。このためにはマッチングモジュール５は、第１の要求において要求された表示（要求ＵＲＬ、ａｌｔｌｉｓｔ拡張ヘッダ）に関連付けられたＵＲＬ（統一資源位置指定子）を用いることができる；
− マッチングモジュール５によって識別された所与のセグメントのマッチした現行の表示の有用性関数Ｕの値を決定するように適合された計算器６。本明細書の以下で述べられるように、有用性関数Ｕは、スマートキャッシュＤＡＮＥまたはクライアント端末ＣＴに関連付けられた動作モードに依存し得る；
− いくつかの現行の表示が第１の要求の表示にマッチした場合に、最も高い有用性関数Ｕの値を有する、スマートキャッシュによってすでに要求されたマッチした現行の表示を決定するように適合された比較器７。加えて比較器７はさらに、現行の表示の有用性関数Ｕの決定された値が性能基準を満たすか否かをチェックするように構成される。説明に役立つが非限定的な例では、性能基準は有用性関数の値がゼロを超えるときに（すなわちＵ＞０）満たされる。

【0054】

加えて、スマートキャッシュＤＡＮＥはまた、スマートキャッシュＤＡＮＥとサーバーＳＥの間の伝送経路に沿った帯域幅を決定するように構成された帯域幅推定器８を備えることができる。このためには帯域幅推定器８は例えば、経路上で受け取ったバイト数を数えることができる。次いで帯域幅は、受け取ったバイト数を期間で除算することによって推定される。当然ながらこのような帯域幅を推定するためには、任意の他の機構が用いられ得る。帯域幅推定器８は、計算器６内に統合され得る。

【0055】

好ましい実施形態によれば有用性関数Ｕは、スマートキャッシュＤＡＮＥまたはクライアント端末ＣＴに関連付けられた動作モードに依存する。モードは、スマートキャッシュＤＡＮＥの所有者によって、または変形形態では、１つまたはいくつかのネットワークパラメータ（スマートキャッシュと所与のサーバーの間の経路に沿った帯域幅など）の関数として決定され得る。他の変形形態ではクライアント端末は、エンドユーザの個人的好みに従って、または改善されたサービスを可能にする購読料の支払いの後に、セグメントを求めるその要求内に所望の動作モードを表示することができる（例えば要求のａｌｔｌｉｓｔヘッダに追加の情報をもたらすことによって）。

【0056】

スマートキャッシュＤＡＮＥの動作モードは、記憶モジュール３（例えばランダムアクセスメモリ（ＲＡＭ）、ローカルメモリ（例えばハードディスクまたはフラッシュメモリ））に記憶され得る。

【0057】

具体的には動作モードは、アグレッシブモード、高速モード、または高品質モードの中から選択される。明らかなようにモードの数は限定的ではなく、本発明から逸脱せずに３つとは異なり得る。

【0058】

アグレッシブモードでは、有用性関数Ｕの値は定数に等しい。この動作モードではスマートキャッシュＤＡＮＥからの所望の効果は、第１の要求の好ましいおよび代替表示を、現行の表示にマッチさせることによって、キャッシュヒット率を最大化し、サーバーからキャッシュへのトラフィックをその最低限まで低減することである。これらの表示のいずれかが現在ダウンロードされているときは、第１の要求は、マッチした現行の表示を受け取るとすぐに対応されるようにスケジュールされることになる。従って可能なときはいつでも、１つの表示のみがサーバーＳＥからダウンロードされ得るので有利である。

【0059】

高速モードでは有用性関数Ｕは、第１の要求の好ましい表示のサーバーＳＥからの配信時間、およびスマートキャッシュＤＡＮＥによってすでに要求されたマッチした現行の表示の配信時間に依存する。配信時間は、要求のバイト数を、スマートキャッシュＤＡＮＥとサーバーＳＥの間の推定された帯域幅で除算することによって容易に計算され得る。マッチした現行の表示に関連付けられた要求に対しては、配信時間は、転送されることになる残りのバイト数を、スマートキャッシュＤＡＮＥとサーバーＳＥの間の帯域幅で除算することによって計算され得る。具体的には有用性関数Ｕは、第１の要求の好ましい表示のサーバーＳＥからの配信時間と、スマートキャッシュＤＡＮＥによってすでに要求されたマッチした現行の表示の配信時間との差によって定義される。高速モードが選択されたときは、計算器６は、所与のセグメントの表示の見積もられた到着時間を計算することができる。高速モードは、マッチした現行の表示のダウンロードが、第１の要求の好ましい表示の要求およびダウンロードより長く継続することを防止する。従って長い処理要求は、追加の、より短い要求によって取り下げられることになる。それでも、マッチした現行の表示に関連付けられた大きな要求がほとんど終わるときは、スマートキャッシュＤＡＮＥは、例えば第１の要求の好ましい表示を取り出すために別の高速要求をトリガする代わりに、その完了を待つことになる。

【0060】

高品質モードでは有用性関数Ｕは、好ましい表示の品質、およびキャッシュによってすでに要求されたマッチした現行の表示の品質に依存する。より具体的には、高品質モードの有用性関数Ｕは、第１の要求の好ましい表示の品質（例えばビットレート）と、スマートキャッシュＤＡＮＥによってすでに要求された考慮される現行の表示の品質との差によって定義される。高品質モードは品質に依存し、これはクライアント端末ＣＴの第１の要求の表示にマッチする現行の表示は、この現行の表示の品質が、第１の要求の好ましい表示の品質以上であるときのみに対応されることを意味する。

【0061】

高品質モードに対しては、スマートキャッシュＤＡＮＥは、表示の相対的品質を知る必要がある。ＤＡＳＨコンテンツに対して通常は、より高いビットレートがより高い品質に対応するが、明らかなように別のシグナリング手段を用いることもできる（例えば表示に追加されたメタデータ）。次いで、表示を比較するための品質メトリックの使用が想定される。

【0062】

図３に示されるようにスマートキャッシュＤＡＮＥは、クライアント端末ＣＴに、その要求および決定された動作モードに従って配信するために、マルチメディアコンテンツの所与のセグメントの表示を選択するように構成される。このためにはスマートキャッシュＤＡＮＥは、下記を含む以下の機構Ｍを実現することができる：
− 第１のクライアント端末から、マルチメディアコンテンツの所与のセグメントの好ましいおよび代替表示を求める第１の要求を受け取るステップ（ステップＳ１）；
− 所与のセグメントの少なくとも１つの現行の表示 − これはさらなるクライアント端末ＣＴのためにスマートキャッシュＤＡＮＥによってサーバーＳＥにおいてすでに要求されている − が第１の要求の好ましいまたは代替表示にマッチするかどうかを決定するステップ（ステップＳ２）；
− 所与のセグメントの各マッチした現行の表示（現行の表示はキャッシュによってすでに要求されている）に対して、有用性関数の値を決定するステップ（ステップＳ３）。具体的には：
・アグレッシブ動作モードが選択されている場合は、有用性関数の値は定数である（例えばＵ＝１）；
・高速動作モードが選択されている場合は、有用性関数は以下によって定義される：
Ｕ＝ｄｅｌｉｖｅｒｙｔｉｍｅ（ｐｒｅｆｅｒｒｅｄ＿ｒｅｐ）−ｄｅｌｉｖｅｒｙｔｉｍｅ（ｍａｔｃｈｅｄ＿ｏｎｇｏｉｎｇ＿ｒｅｐ）
・高品質動作モードが選択されている場合は、有用性関数は以下によって定義される：
Ｕ＝ｑｕａｌｉｔｙ（ｍａｔｃｈｅｄ＿ｏｎｇｏｉｎｇ＿ｒｅｐ）＋ε−ｑｕａｌｉｔｙ（ｐｒｅｆｅｒｒｅｄ＿ｒｅｐ）
ただしεは、十分に異なる品質の間で区別するために用いられる定数である。表示品質を比較するときは、品質の差（絶対値）がεより低い場合は、表示は等価な品質と見なされる。εはゼロに等しく選択され得る。

【0063】

− 性能基準を満たす、最も高い有用性関数の値を有するマッチした現行の表示を選択するステップ（ステップＳ４）。具体的にはアグレッシブモードに対しては、いくつかのマッチした現行の表示が存在するとき、および有用性関数の値は定数であるので、選択されたマッチした現行の表示は、好みの順序（好ましい表示、第１の代替、第２の代替など）によって第１の要求された表示の１つに対応する。アグレッシブモードの他の変形形態では、選択されたマッチした現行の表示は、最も短い配信時間を有する表示に対応する；
− キャッシュによって第１のクライアント端末ＣＴに、キャッシュによってすでに要求された（および場合によっては、サーバーＳＥから現在ダウンロードしている）選択された現行の表示を送信するステップ（ステップＳ５）。マッチした現行の表示のいずれも性能基準を満たす有用性値を有しない（すなわちマッチした現行の表示が選択されなかった）ときは、従ってスマートキャッシュＤＡＮＥによってサーバーＳＥに対して、第１の要求の好ましい表示が要求される（ステップＳ６）。

【0064】

本発明から逸脱せずに、ステップＳ０からＳ６までの順序は変更され得ることが理解されるべきである。

【0065】

好ましい実施形態に適合したアグレッシブモードの第１の説明に役立つが非限定的な例では、図４に示されるタイムチャートは、クライアント端末ＣＴ１、ＣＴ２によって送られるセグメントを求める要求（Ｇｅｔ ｒｅｐ４、ａｌｔ［ｒｅｐ６，ｒｅｐ５］、Ｇｅｔ ｒｅｐ６、ａｌｔ［ｒｅｐ５，ｒｅｐ４］）、スマートキャッシュＤＡＮＥによって送られる現行の表示を求める要求（Ｇｅｔ ｒｅｐ４）、サーバーＳＥによって送られる応答（ｒｅｐ４）、およびキャッシュＤＡＮＥによってクライアント端末ＣＴ１、ＣＴ２に送られる応答（ｒｅｐ４）を表す。

【0066】

アグレッシブモードでは本発明から逸脱せずに、有用性および性能パラメータは無視され、計算またはチェックされない場合があることが留意され得る。

【0067】

具体的には、クライアント端末ＣＴ２− 前述のように第１の端末に対応すると仮定する −は、好ましい表示（ｒｅｐ６）および代替表示（ｒｅｐ５、ｒｅｐ４）を求める要求を送る。表示６（ｒｅｐ６）はまた、表示４（ｒｅｐ４）より良い品質のものであると仮定する。

【0068】

アグレッシブモードによれば、その第１の要求に応答して、クライアント端末ＣＴ２は代替表示「ｒｅｐ４」を受け取る。なぜならそれの要求がスマートキャッシュＤＡＮＥに到達したときに、代替表示は（さらなるクライアント端末ＣＴ１の前の要求に応答して）ダウンロードの過程であったまたはダウンロードされたからである。

【0069】

好ましい実施形態に適合した高速モードの第２の説明に役立つが非限定的な例では、図５に示されるタイムチャートは、クライアント端末ＣＴ１、ＣＴ２、スマートキャッシュＤＡＮＥ、およびサーバーＳＥの間で交換される要求および応答を示す。

【0070】

具体的にはクライアント端末ＣＴ２は、好ましい表示（ｒｅｐ２）および代替表示（ｒｅｐ４、ｒｅｐ３）を求める要求を送る。クライアント端末ＣＴ２の要求の代替表示にマッチする、− スマートキャッシュＤＡＮＥによってすでに要求された −１つの現行の表示（ｒｅｐ４）が存在する。

【0071】

しかしながら、クライアント端末ＣＴ２によって要求された好ましい表示（ｒｅｐ２）の予想される配信時間は、すでに要求されたマッチした現行の表示（ｒｅｐ４）の配信時間より早く、そのためスマートキャッシュＤＡＮＥは、クライアント端末ＣＴ２のために好ましい表示（ｒｅｐ２）を要求することになる。

【0072】

好ましい実施形態に適合した高品質モードの第３の説明に役立つが非限定的な例では、図６のタイムチャートはまた、クライアント端末ＣＴ１、ＣＴ２、スマートキャッシュＤＡＮＥ、およびサーバーＳＥの間で交換される要求および応答を示す。

【0073】

この例ではクライアント端末ＣＴ２は、好ましい表示（ｒｅｐ６）および代替表示（ｒｅｐ５、ｒｅｐ４）を求める要求を送る。第１の例のように表示６（ｒｅｐ６）は、表示４（ｒｅｐ４）より良い品質のものであると仮定する。クライアント端末ＣＴ２の要求の代替表示にマッチする、− スマートキャッシュＤＡＮＥによってすでに要求された −１つの現行の表示（ｒｅｐ４）が存在する。

【0074】

（クライアント端末ＣＴ１のためにスマートキャッシュＤＡＮＥによってすでに要求された）マッチした現行の表示ｒｅｐ４の品質は、好ましい表示６の１つより低いと決定されたと仮定すると、スマートキャッシュＤＡＮＥはクライアント端末ＣＴ２のために好ましい表示（ｒｅｐ６）を要求することになる。

【0075】

従って好ましい実施形態は、サーバーＳＥに向かって別の要求を発行することの有用性を決定するために、すでに進行中の動作と突き合わされることになる、好ましい表示およびその代替を全体として備えた、クライアント端末ＣＴからの要求を考察することにある。マッチが見出されたとき、スマートキャッシュＤＡＮＥは、要求が、サーバーＳＥに向かって新しい要求を発行することによって処理されることになるか、またはサーバーとのトラフィック量を低減するために現行の要求の後に順番に並べられる（例えば現行の要求の結果により対応される）ことになるかを決定するために計算を行う。

【0076】

スマートキャッシュＤＡＮＥは、プロキシ内、ゲートウェイ内、または任意の他の適切なネットワーク機器内に統合され得ることが留意されるべきである。

【0077】

図におけるフローチャートおよび／またはブロック図は、本発明の様々な実施形態によるシステム、方法、およびコンピュータプログラム製品の可能な実現の構成、動作、および機能を示す。この点に関してフローチャートまたはブロック図における各ブロックは、特定の論理機能を実現するための１または複数の実行可能命令を備えるモジュール、セグメント、またはコードの一部分を表すことができる。いくつかの代替的実現では、ブロック内に示された機能は、図に示されたものと異なる順序で生じ得ることが留意されるべきである。例えば連続して示される２つのブロックは、実際は関連する機能に応じて、実質的に同時に実行することができ、またはブロックはときには逆の順序で実行することができ、またはブロックは代替の順序で実行することができる。またブロック図および／またはフローチャート図の各ブロック、ならびにブロック図および／またはフローチャート図内のブロックの組み合わせは、特定の機能もしくは動作を行う専用ハードウェア・ベースのシステム、または専用ハードウェアとコンピュータ命令の組み合わせによって実現され得ることが留意されるであろう。明示的に述べられないが本実施形態は、任意の組み合わせまたは部分組み合わせにおいて使用され得る。

【0078】

当業者には理解されるように、本原理の特徴は、システム、方法、またはコンピュータ可読媒体として具体化され得る。従って本原理の特徴は、専らハードウェアの実施形態、専らソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または本明細書においてすべて一般に「回路」、「モジュール」、もしくは「システム」と呼ばれ得るソフトウェアおよびハードウェアの特徴を組み合わせた実施形態の形をとることができる。さらに本原理の特徴は、コンピュータ可読記憶媒体の形をとることができる。１または複数のコンピュータ可読記憶媒体の任意の組み合わせが利用され得る。

【0079】

コンピュータ可読記憶媒体は、１または複数のコンピュータ可読媒体において具体化され、コンピュータによって実行可能なコンピュータ可読プログラムコードがその上に具体化された、コンピュータ可読プログラム製品の形をとることができる。本明細書で用いられるコンピュータ可読記憶媒体とは、その中に情報を記憶するための固有の能力、ならびにそれからの情報の取り出しをもたらすための固有の能力を前提とした、非一時的記憶媒体と見なされる。コンピュータ可読記憶媒体は、例えば電子的、磁気的、光学的、電磁的、赤外線、または半導体システム、装置、またはデバイス、あるいは上記の任意の適切な組み合わせとすることができるが、それらに限定されない。以下は、本原理がそれに適用され得るコンピュータ可読記憶媒体のより具体的な例をもたらすが、当業者には容易に理解されるように単に説明に役立つおよび非網羅的な列挙であることが理解されるべきである：ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラマブル読み出し専用メモリ（ＥＰＲＯＭまたフラッシュメモリ）、ポータブルコンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、光記憶装置、磁気記憶装置、または上記の任意の適切な組み合わせである。
［付記１］
クライアント端末（ＣＴ）と少なくとも１つのサーバー（ＳＥ）との間の伝送経路に沿って配置されたキャッシュ（ＤＡＮＥ）を動作させる方法であって、前記キャッシュ（ＤＡＮＥ）は、いくつかの表示において利用可能なマルチメディアコンテンツのセグメントの要求をクライアント端末（ＣＴ）から受け取るように構成される方法において、
第１のクライアント端末（ＣＴ）から、前記マルチメディアコンテンツの所与のセグメントの好ましい表示および少なくとも１つの代替表示の第１の要求を受け取るステップ（Ｓ１）と、
さらなるクライアント端末（ＣＴ）のために前記サーバー（ＳＥ）から前記キャッシュによってすでに要求されている、前記第１の要求の前記好ましい表示または代替表示にマッチする、前記所与のセグメントの現行の表示を決定するステップ（Ｓ２）と、
を含むことを特徴とする、前記方法。
［付記２］
さらなるクライアント端末（ＣＴ）のために前記キャッシュ（ＤＡＮＥ）によってすでに要求されている前記所与のセグメントのマッチした現行の表示に関連付けられた有用性関数の値を決定するステップ（Ｓ３）と、
前記有用性関数の対応する決定された値が性能基準を満たすときは、前記キャッシュ（ＤＡＮＥ）によってすでに要求された、前記マッチした現行の表示を、前記第１のクライアント端末（ＣＴ）に送信するステップ（Ｓ５）と、
をさらに含む、付記１に記載の方法。
［付記３］
前記第１の要求の２つの相異なる表示にマッチする、少なくとも２つの現行の表示が、さらなるクライアント端末（ＣＴ）のために前記キャッシュ（ＤＡＮＥ）によってすでに要求されている場合は、最も高い有用性値に関連付けられた前記マッチした現行の表示は、前記有用性値が前記性能基準を満たすときに送信される、付記２に記載の方法。
［付記４］
前記第１の要求の２つの相異なる表示にマッチする、少なくとも２つの現行の表示が、さらなるクライアント端末（ＣＴ）のために前記キャッシュ（ＤＡＮＥ）によってすでに要求されている場合は、前記マッチした現行の表示のいずれも、前記性能基準を満たす有用性値を有しないときは、前記第１の要求の前記好ましい表示が、前記サーバー（ＳＥ）に対して前記キャッシュ（ＤＡＮＥ）によって要求される、付記２または３に記載の方法。
［付記５］
前記性能基準は、前記有用性関数の前記値がゼロを超えたときに満たされる、付記２から４のいずれか一項に記載の方法。
［付記６］
前記有用性関数は、少なくとも、
前記有用性関数の値が定数に等しい、アグレッシブモードと、
前記有用性関数が、前記第１の要求の前記好ましい表示の前記サーバー（ＳＥ）からの配信時間、および前記キャッシュ（ＤＡＮＥ）によってすでに要求されたマッチした現行の表示の配信時間に依存する、高速モードと、
前記有用性関数が、前記第１の要求の前記好ましい表示の品質、および前記キャッシュ（ＤＡＮＥ）によってすでに要求されたマッチした現行の表示の品質に依存する、高品質モードと、
を含むモードのグループに属する動作モードに依存する、付記２から５のいずれか一項に記載の方法。
［付記７］
前記動作モードは、少なくとも１つのネットワークパラメータの関数として決定される、付記６に記載の方法。
［付記８］
前記動作モードは、前記第１のクライアント端末によって選択され、前記第１の要求内で示される、付記６に記載の方法。
［付記９］
クライアント端末（ＣＴ）と少なくとも１つのサーバー（ＳＥ）の間の伝送経路に沿って位置し、いくつかの表示において利用可能なマルチメディアコンテンツのセグメントの要求をクライアント端末（ＣＴ）から受け取るように構成されたキャッシュであって、
第１のクライアント端末（ＣＴ）から、前記マルチメディアコンテンツの所与のセグメントの好ましい表示および少なくとも１つの代替表示を求める第１の要求を受け取るための、接続のインターフェース（１）と、
さらなるクライアント端末（ＣＴ）のためにサーバー（ＳＥ）から前記キャッシュ（ＤＡＮＥ）によってすでに要求された、前記所与のセグメントの少なくとも１つの現行の表示が、前記第１の要求の前記好ましい表示または代替表示にマッチするかどうかを決定するように構成された、マッチングモジュール（５）と、
を備えることを特徴とする、前記キャッシュ。
［付記１０］
前記マッチングモジュール（５）によって識別された前記所与のセグメントのマッチした現行の表示に関連付けられた有用性関数の値を決定するように適合された計算器（６）をさらに備える、付記９に記載のキャッシュ。
［付記１１］
いくつかの現行の表示が、前記第１の要求の前記好ましい表示および代替表示にマッチした場合に、前記有用性関数の最も高い値を有する、前記スマートキャッシュ（ＤＡＮＥ）によってすでに要求された前記マッチした現行の表示を決定するように構成された比較器（７）をさらに備える、付記９または１０に記載のキャッシュ。
［付記１２］
前記比較器（７）が、マッチした現行の表示の前記有用性関数の前記決定された値が、性能基準を満たすか否かをチェックするようにさらに構成される、付記１１に記載のキャッシュ。
［付記１３］
前記有用性関数は、少なくとも、
前記有用性関数の値が定数に等しい、アグレッシブモードと、
前記有用性関数が、前記第１の要求の前記好ましい表示の前記サーバー（ＳＥ）からの配信時間、および前記キャッシュ（ＤＡＮＥ）によってすでに要求されたマッチした現行の表示の配信時間に依存する、高速モードと、
前記有用性関数が、前記第１の要求の前記好ましい表示の品質、および前記キャッシュ（ＤＡＮＥ）によってすでに要求されたマッチした現行の表示の品質に依存する、高品質モードと、
を含むモードのグループに属する動作モードに依存する、付記１１または１２に記載のキャッシュ。
［付記１４］
クライアント端末（ＣＴ）によって、１つまたは複数の表示において利用可能なセグメントに分割されたマルチメディアコンテンツのセグメントの表示を求める要求を送る方法であって、前記マルチメディアコンテンツは、少なくとも１つのリモートサーバー（ＳＥ）によって提供され、
前記要求は、前記クライアント端末（ＣＴ）と１つのサーバー（ＳＥ）との間の伝送経路に沿って配置されたキャッシュ（ＤＡＮＥ）によって適用されることになる選択された動作モードのインディケーションを備えることを特徴とする、前記方法。
［付記１５］
セグメントに分割され、少なくとも１つのリモートサーバー（ＳＥ）によって提供されるマルチメディアコンテンツを受け取るように構成されたクライアント端末であって、各セグメントは１つまたは複数の表示において利用可能であり、
前記クライアント端末（ＣＴ）と１つのサーバー（ＳＥ）との間の伝送経路に沿って配置されたキャッシュ（ＤＡＮＥ）によって適用されることになる選択された動作モードを示す表示を求める要求を送るように構成された通信モジュール（２Ａ）を備えることを特徴とする、前記クライアント端末。

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】