JP2017510873A - セグメントに分割されたマルチメディアコンテンツを受信するように構成されたクライアント端末によるネットワーク情報取得方法 - Google Patents

Abstract

本発明は、セグメントに分割され少なくとも１つのリモートサーバにより提供されるマルチメディアコンテンツを受信するように構成されたクライアント端末（ＣＴ）に関する。各セグメントは一以上の表現で入手可能であり、前記クライアント端末は、前記サーバ（ＳＥ）と前記クライアント端末（ＣＴ）との間のパスに沿った、階層を成すキャッシュ（ＤＡＮＥ）を含むネットワーク情報を受信するように構成された通信モジュール（２）を含む。図２

Description

本発明は概してＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などによる適応的ストリーミング技術の領域に関し、特に、セグメントに分割されたマルチメディアコンテンツを受信するように構成されたクライアント端末による、ネットワーク情報の取得方法に関する。

このセクションは、以下に説明して特許請求する本発明の様々な態様に関連する様々な態様の技術を読者に紹介することを意図するものである。この説明は、本発明の様々な態様の理解を容易にする背景情報を読者に提供する役に立つはずである。従って、言うまでもなく、これらの記載は上記を考慮して読むべきであり、先行技術として認める（ａｄｍｉｓｓｉｏｎｓ ｏｆ ｐｒｉｏｒ ａｒｔ）ものではない。

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

クライアント端末は、適応的ストリーミングでオーディオビジュアルコンテンツ（またはＡ／Ｖコンテンツ）を再生したいとき、このＡ／Ｖコンテンツをどうやって取得するかを記述するファイルを、まず取得しなければならない。これは概して、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）から記述ファイルいわゆるマニフェストを取得することにより、ＨＴＴＰプロトコルを通して行われるが、その他の手段（例えば、ブロードキャスト、電子メール、ＳＭＳなど）により実現することも可能である。マニフェストは、基本的には、（ビットレート、解像度、その他の特性に関する）Ａ／Ｖコンテンツなどの利用可能表現（ａｖａｉｌａｂｌｅ ｒｅｐｒｅｓｅｎｔａｔｉｏｎｓ）を列挙したものである。前記マニフェストは事前に生成され、例えばリモートサーバによりクライアント端末に配信される。

実際、画質が異なるＡ／Ｖコンテンツに対応するデータのストリームがＨＴＴＰサーバから入手可能である。高ビットレートには最高画質が伴い、低ビットレートには最低画質が伴う。これにより、ネットワーク状態が大きく変化する、異なる多くの端末への配信が可能となる。

全データストリームはセグメントに分割され、このセグメントは、クライアント端末が２つのセグメント間で一画質レベルから他の画質レベルにスムースに切り替わるようになっている。結果として、ビデオ画質は再生中に変化し得るが、中断（フリーズとも呼ばれる）することはほとんどない。

プロトコルに応じて、マニフェストはさまざまなフォーマットを提供し得る。Ａｐｐｌｅ ＨＬＳプロトコルの場合、それはＭ３Ｕ８プレイリスト（「マスタープレイリスト」と呼ばれる）である。このプレイリストの各要素は他のプレイリストであり、表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）ごとに１つのプレイリストがある。他のプロトコル（例えば、ＤＡＳＨ）によると、マニフェストは、すべての表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎｓ）を順次記述する一以上のＸＭＬファイルよりなる。どんな場合であっても、マニフェストの生成は、テキストファイルの生成や確定的文法に基づくテキストの作成（ｗｒｉｔｉｎｇ）と同じくらい単純である。

周知なことであるが、利用可能な帯域幅に基づき、クライアント端末は、ある時点で最適な表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を選択し、画質（例えば、ビデオ画質）とネットワーク変化に対するロバスト性（ｒｏｂｕｓｔｎｅｓｓ）との間のトレードオフを最適化する。利用可能な帯域幅は、受信セグメントごとに動的に決定される。実際、あるセグメントを求めるＨＴＴＰリクエストの送信と、それに対応するＨＴＴＰレスポンスの受信との間として定義されるラウンドトリップ時間（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）（以下、本願ではＨＴＴＰ ＲＴＴと呼ぶ）が一般的に測定され、伝送経路に沿って利用できる帯域幅を推定するのに用いられる。

クライアント端末とリモートサーバ間の伝送経路上にキャッシュがあれば、これは良くあることであるが、他のクライアントが同じ表現の同じセグメントを以前要求したことがある場合や、コンテンツ配信ネットワーク（Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ（ＣＤＮ））がそのセグメントをそのキャッシュにすでに提供している場合には、セグメントが前記キャッシュにすでに格納されていることがある。

このように、前記セグメントを求めるＨＴＴＰリクエストに対する応答は、セグメントがリモートサーバから来る場合よりも速い。クライアント端末とキャッシュ間のＨＴＴＰリクエストのＨＴＴＰ ＲＴＴは、クライアント端末とリモートサーバ間のものよりずっと短いことがある。伝送経路が短いからである。
また、伝送経路上にキャッシュがある（かつ、要求されたセグメントがそのキャッシュに格納されている）場合、ピークレートはより良く、特にキャッシュとリモートサーバとの間の前記伝送経路上に輻輳がある場合にそうである。

クライアント端末は、リモートサーバにより送信された応答と中間キャッシュにより送信された応答とを通常は区別しないので、帯域幅変化を、間違って、エンドツーエンドのネットワーク条件の変化として解釈するが、実際には、「クライアント端末からサーバへの」経路から、「クライアント端末からキャッシュへの」経路への切り替えを見ている。
その結果、クライアント端末により行われる帯域幅推定は、過大評価され、期待したようには、エンドツーエンドの伝送経路特性を正しく反映しない。

かかる過大評価は概してエンドユーザにとって貧しい経験となる。実際、推定された帯域幅が期待よりも大きいとき、適応的ストリーミングクライアント端末は通常、画質がより高い表現（例えば、ビットレートがより高いもの）からのセグメントを要求する。この要求されたセグメントは、（キャッシュは、一定のビットレートで同じマルチメディアコンテンツを再生するクライアント端末により満たされていると仮定して）表現が変化するので、キャッシュにある確率は低い。要求された前記セグメントに関連するダウンロード時間は、期待よりもずっと長くなってしまい、要求されたセグメントの到着が遅すぎることになる。クライアント端末は、低画質表現に戻る。これはキャッシュ中に見つかりやすいものである。

結果として、クライアント端末は、キャッシュミスにより常にインターラプトされて、高画質と低画質のセグメント間を行ったり来たりして、キャッシングの利益を危険にさらすこととなる。

さらに、ＨＡＳクライアント端末は、キャッシュの内容を知らないので、加速能力やネットワーク負荷の低減の利益を失う。さらに、セグメントの各ダウンロードにおける個々のクエリーが可能であっても、現在のＨＡＳクライアント端末は、セグメントシーケンスがキャッシュ中にあることを考慮するレート適応ストラテジをｅｌａｂｏｒａｔｅできない。

本発明は、エンドユーザ体験の質を改善するために上記の欠点の少なくとも一部を改善することを試みるものである。

本発明は、セグメントに分割され少なくとも１つのリモートサーバにより提供されるマルチメディアコンテンツを受信するように構成されたクライアント端末による、ネットワーク情報を取得する方法に関する。各セグメントは一以上の表現で入手可能であり、これは、前記ネットワーク情報がサーバとクライアント端末との間のパスに沿って階層を成すキャッシュを含む点で特筆すべきである。

一実施形態では、前記ネットワーク情報は、前記階層の少なくとも幾つかのキャッシュについて、前記キャッシュにより記憶されたセグメントの表現のリストを更に含み得る。

一実施形態では、クライアントは、階層に属する目標キャッシュに要求を送信し、前記目標キャッシュにより記憶されたセグメントの表現のリストを受信する。この表現のリストは、完全なリストであるか、または前に記憶されていたセグメントと現在記憶されているセグメントとの差分のリストである。

一実施形態では、クライアント端末は、前記目標キャッシュにより記憶されたセグメントの表現のリストに従って、前記キャッシュにより記憶されたセグメントの表現のリストを更新する。

さらに別の実施形態では、前記ネットワーク情報は、前記クライアント端末によりサーバから受信されるマニフェストにより提供され、前記マニフェストは、前記サーバにおいて入手可能な、前記マルチメディアコンテンツの表現をリストしていてもよい。

また、前記マニフェストは、前記サーバと前記クライアント端末との間のパスに沿ったキャッシュの順序付きリストを含み得る。

さらに、前記マニフェストは、前記順序付きリストの各キャッシュについて、前記キャッシュにより記憶された前記セグメントの表現を特定し得る。前記リストは、ローカルでキャッシュされた表現のマニフェストへの追加により、サーバとクライアント端末との間のパスに沿って出会った各キャッシュによりインクリメント方式で構成され得る。

その他、前記マニフェストは、サーバとクライアント端末との間のパスに沿って出会ったキャッシュにより、その識別子を追加して順序付きリストを構成することにより、修正され得る。

一実施形態では、前記マニフェストは、前記サーバと前記クライアント端末との間のパスに沿って出会う、前記順序付きリストの各キャッシュの識別子を含む。

さらにまた、前記キャッシュは、接続情報を追加することにより、前記マニフェストを更に修正することができる。

一実施形態では、マニフェストは、前記キャッシュの少なくとも１つの接続情報を含む。

さらに別の態様では、前記クライアント端末は、各キャッシュにより記憶された前記セグメントの表現を決定するために、データの配信に用いられるデータパスとは異なる補助通信パスを用いて、前記順序付きリストの少なくとも幾つかのキャッシュにクエリーできる。

他の一態様では、ネットワーク情報は、サーバからクライアント端末により受信されるメッセージに負荷され得る。
このメッセージは、それを受信するキャッシュが前記メッセージに自分の存在をレポートできる拡張ヘッダを含む。
特に、出会った各キャッシュを特定する順序付きリストは、前記拡張ヘッダに構成できる。
また、接続情報は、前記順序付きリストの各キャッシュに関連付け得る。

一実施形態では、前記方法は、キャッシュの階層に属する少なくとも１つのキャッシュからのセグメントのダウンロードを含む。

一実施形態では、ネットワーク情報は、セグメントの受信に使われるインターフェースと同様の、又はセグメントの受信に使われるインターフェースとは異なるネットワークインターフェースにより受信される。
異なる実施形態によると、ネットワークインターフェースは、ネットワーク情報（Ｗｉｆｉ、ＡＤＳＬ、Ｃａｂｌｅ、Ｍｏｂｉｌｅ及び／又はＢｒｏａｄｃａｓｔ（例えば、ＤＶＢ、ＡＴＳＣ））を受信するように適応される。

異なる実施形態によると、セグメントを受信するように適応されたネットワークインターフェースは、Ｗｉｆｉ、ＡＤＳＬ、Ｃａｂｌｅ、Ｍｏｂｉｌｅ及び／又はＢｒｏａｄｃａｓｔ（例えば、ＤＶＢ、ＡＴＳＣ）インターフェースである。

一実施形態では、クライアント端末は、セグメントを受信するのに使われるプロトコル（例えば、ｈｔｔｐ、Ｆｌｕｔｅ）と同様のプロトコルを、又は異なるプロトコル（セグメント：ｈｔｔｐ、ｆｌｕｔｅ；ネットワーク情報：ＴＲ６９ Ｂｒｏａｄｂａｎｄ Ｆｏｒｕｍまたはブロードキャストプロトコル、ｘｍｐｐ ＩＥＴＦ、ＤＤＳ ＯＭＧ（Ｏｂｊｅｃｔ Ｍａｎａｇｅｍｅｎｔ Ｇｒｏｕｐ））を、ネットワーク情報を受信するために用いる。

一実施形態では、ネットワーク情報はランダムアクセスメモリ（ＲＡＭ）に記憶される。

一実施形態では、セグメントは、ローカルメモリ（例えば、ハードディスクまたはフラッシュメモリ）に記憶され、及び／又はデコーダにより復号され、及び／又はディスプレイに表示される。

本発明はまた、セグメントに分割され少なくとも１つのリモートサーバにより提供されるマルチメディアコンテンツを受信するように構成されたクライアント端末であって、各セグメントは一以上の表現で入手可能である。本発明によると、前記クライアント端末は、サーバとクライアント端末との間のパスに沿って階層を成すキャッシュを含むネットワーク情報を受信するように構成された通信モジュールを含む。

また、前記ネットワーク情報は、前記階層の少なくとも幾つかのキャッシュについて、前記キャッシュにより記憶されたセグメントの表現のリストを更に含み得る。

さらに、前記通信モジュール端末は、各キャッシュにより記憶された前記セグメントの表現を決定するために、データの配信に用いられるデータパスとは異なる補助通信パスを用いて、前記階層の少なくとも幾つかのキャッシュにクエリーするように更に構成され得る。

本発明は、少なくとも１つのリモートサーバにより提供されるマルチメディアコンテンツのセグメントをクライアント端末に配信するように構成されたキャッシュによる、ネットワーク情報を送信する方法にも関する。各セグメントは一以上の表現で入手可能である。
本発明によると、前記ネットワーク情報は、サーバとクライアント端末との間のパスに沿って階層を成すキャッシュを含む。

一実施形態では、キャッシュは、階層を受信し、それがクライアント端末への最寄りのキャッシュと考えられるように更新する。この最寄りのキャッシュは、（例えば、クライアント端末上のセグメントを更新するネットワークリソースを節約し、及び／又はセグメントへの最も素早いアクセスのため）アクセススピードの点で最も好ましく、ネットワークリソースを節約する。そして、キャッシュは、更新した階層を下向きにクライアントに転送する；こうして階層はインクリメント方式で構成される。

一実施形態では、キャッシュは、受信した階層に関連して受信した表現のリストに、前記キャッシュに関連するローカルでキャッシュされた表現のリストを追加し、キャッシュは、次いで、更新した表現のリストを下向きにクライアントに転送する；こうして表現のリストがインクリメント方式で構成される。

本発明は、少なくとも１つのリモートサーバにより提供されるマルチメディアコンテンツのセグメントをクライアント端末に配信するように構成されたキャッシュによる、ネットワーク情報を送信する方法にも関する。各セグメントは一以上の表現で入手可能である。発明によると、前記ネットワーク情報は、サーバとクライアント端末との間のパスに沿って階層を成すキャッシュを含む。

前記キャッシュは、
−受信した階層に関する受信した表現のリストに、前記キャッシュに関連するローカルでキャッシュされた表現のリストを追加し、
−前記クライアント端末に、更新した表現のリストを転送し、
前記ネットワーク情報は、前記クライアント端末によりサーバから受信されるマニフェストにより提供され、前記マニフェストは、前記サーバにおいて入手可能な、前記マルチメディアコンテンツの表現をリストしている。

一実施形態では、前記マニフェストは、前記サーバと前記クライアント端末との間のパスに沿ったキャッシュの順序付きリストを含む。

一実施形態では、さらに、前記マニフェストは、前記順序付きリストの各キャッシュについて、前記キャッシュにより記憶された前記セグメントの表現を特定する。

一実施形態では、前記キャッシュは、自分の識別子を追加して前記順序付きリストを構成することにより、前記順序付きリストを修正する。

一実施形態では、前記キャッシュは、接続情報を追加することにより、前記マニフェストを更に修正する、
本発明は、ネットワーク情報を送信するように適応されたキャッシュに関し、前記キャッシュは少なくとも１つのリモートサーバにより提供されるマルチメディアコンテンツのセグメントをクライアント端末に配信するように構成され、各セグメントは一以上の表現で入手可能である。本発明によると、前記ネットワーク情報はサーバと前記クライアント端末との間のパスに、階層を成すキャッシュを含む。

一実施形態では、キャッシュは、住宅用ゲートウェイ、パブリックゲートウェイ、企業ゲートウェイ、ホットスポット、電話、車両、インターネットサービスプロバイダ（ＩＳＰ）ネットワーク要素、及び企業プロキシを含むセットに含まれるネットワーク要素（ネットワークキャッシュとも呼ぶ）である。

本発明は、通信ネットワークからダウンロード可能であり、及び／又はコンピュータにより読み取り可能な媒体上に記録され、及び／又はプロセッサにより実行可能であり、上記の方法のステップを実装するプログラムコード命令を含むコンピュータプログラム製品に更に関する。

また、本発明は、非一時的コンピュータ読み取り可能媒体であって、それに記録されたコンピュータプログラム製品を含み、プロセッサにより実行可能であり、上記の方法のステップを実装するプログラムコード命令を含むものにも関する。

開示した実施形態と同じ範囲の態様を以下に記載する。言うまでもなく、これらの態様は、読者に本発明が取り得る形態の簡単な概要を提供するためだけに記載するものであり、本発明の範囲を限定するものではない。実際、本発明は、以下に記載していない様々な態様を包含し得る。

開示した実施形態と同じ範囲の態様を以下に記載する。言うまでもなく、これらの態様は、読者に本発明が取り得る形態の簡単な概要を提供するためだけに記載するものであり、本発明の範囲を限定するものではない。実際、本発明は、以下に記載していない様々な態様を包含し得る。

本発明は、添付した図面を参照して以下の実施形態及び実施例により、よりよく理解でき、説明されるであろう。
本発明の好ましい実施形態が実装され得るクライアントサーバネットワークアーキテクチャを示す模式図である。 本発明の好ましい実施形態によるクライアント端末の一例を示すブロック図である。 図２のクライアント端末により実装されるマルチメディアコンテンツの入来セグメントシーケンスをダウンロードする方法を示すフローチャートである。 図１と図２において、表示したブロックは純粋に機能的なものであり、必ずしも物理的なものとして分離していることを示すものではない。すなわち、これらのブロックは、ソフトウェア、ハードウェアとして開発してもよいし、一以上のプロセッサを含む一または複数の集積回路に実装してもよい。

可能な限り、同じ又は同様のパーツを参照するため複数の図面を通して同じ参照数字を用いる。

言うまでもなく、本発明の図面と説明は簡略化され、本発明をよく理解するのに必要な要素を説明しており、明確性のため、一般的なデジタルマルチメディアコンテンツ配信方法やシステムにあるその他の多くの要素は省略している。しかし、本技術分野ではかかる要素は周知であるから、かかる要素の詳細な説明はここではしていない。本開示は、当業者に知られたかかるバリエーションや修正もすべて含むものである。

好ましい実施形態では、本発明はＨＴＴＰ適応的ストリーミングプロトコル（またはＨＡＳ）に関して図示する。当然、本発明は斯様な具体的な環境には制約されず、他の適応的ストリーミングプロトコルをもちろん考え実装することもできる。

図１に示したように、一または複数のネットワークＮ（図には１つのみを示した）は、本発明が実装され得るものであり、一または複数のクライアント端末ＣＴ、一以上のＨＴＴＰサーバＳＥ、複数のスマートキャッシュＤＡＮＥ、及び一以上のレガシーキャッシュＲＮＥを含む。ＤＡＳＨによると、かかるサーバＳＥはメディアオリジン（Ｍｅｄｉａ Ｏｒｉｇｉｎ）とも呼ばれる。これらは、例えばメディアプレゼンテーション記述（ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ、ＭＰＤ）、すなわちいわゆるマニフェストを生成する。これはコンテンツ配信の配信源である。マルチメディアコンテンツは幾つかの外部エンティティから入来し、メディアオリジンでＨＡＳフォーマットに変換されてもよい。

スマートキャッシュＤＡＮＥはネットワークＮにおけるキャッシング要素であり、このキャッシング要素はＨＡＳコンテンツが配信されることを分かるように構成されている。ＭＰＥＧ−ＤＡＳＨ用語を用いて、スマートキャッシュはＤＡＳＨ Ａｗａｒｅ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ（ＤＡＮＥ）であると考えられる。

レガシーキャッシュＲＮＥは、ネットワークＮにおける、それを通して伝送されるデータのタイプを知らない、または少なくともＨＡＳを理解しない、キャッシング要素である。ＭＰＥＧ−ＤＡＳＨ用語では、レガシーキャッシュはＲｅｇｕｌａｒ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ（ＲＮＥ）であると考えられる。

クライアント端末ＣＴはＨＴＴＰサーバＳＥの１つからマルチメディアコンテンツを取得したい。前記マルチメディアコンテンツは複数のセグメント（チャンク（ｃｈｕｎｋｓ）とも呼ばれる）に分割される。マルチメディアコンテンツはサーバＳＥにおいて異なる表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎｓ）で入手できるものと仮定する。ＨＴＴＰサーバＳＥは、クライアントの要求に応えて、ＨＴＴＰ適応的ストリーミングプロトコルを用いて、一以上のＴＣＰ／ＩＰ接続を介してクライアント端末ＣＴにセグメントをストリーミングできる。

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

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

本発明によると、各クライアント端末ＣＴは、リモートサーバＳＥに格納されたマルチメディアコンテンツのセグメントの入来シーケンスをダウンロードする方法Ｍを実装するように構成されている。前記シーケンスは、そのフィーチャが後程開示する画質基準に最も良くマッチするように選択される。

方法Ｍを実装するため、クライアント端末ＣＴは好ましくはネットワークアーキテクチャＮを知っている必要がある。

この目的のため、マニフェストは、ＨＴＴＰレスポンスにより、サーバＳＥからクライアント端末ＣＴに、後者によるマルチメディアコンテンツの要求時に配信され、サーバＳＥにおいて前記マルチメディアコンテンツの利用可能な表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎｓ）のリストを含むが、サーバＳＥとクライアント端末ＣＴとの間にあるスマートキャッシュＤＡＮＥの順序付きリストをさらに含み得る。この場合、サーバＳＥは、ネットワークアーキテクチャ（例えば、マネージドネットワークなどの場合）を知っており、かかる順序付きリストを予め構成することができる。サーバＳＥは要求クライアント端末ＣＴに応じた順序付きリストを提供してもよい。

順序付きリストにおいて、出会う各スマートキャッシュＤＡＮＥの識別は次により行える：
− ユニークな識別子；
− 前記スマートキャッシュに到達できる（後で説明する）、サービスアクセスポイント（Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ）などの接続情報。

このスマートキャッシュＤＡＮＥの順序付きリストは、任意的に、付加的接続情報で完了するが、クライアント端末ＣＴにより受信されるので、マニフェストの拡張として提供される。

順序付きリストにおいて、スマートキャッシュＤＡＮＥは、好ましくはクライアント端末ＣＴとの近さを考慮して、リストされる。順序付きリストの最初の要素はクライアント端末ＣＴに最も近いスマートキャッシュに対応する。

変形例では、サーバＳＥは、ネットワークアーキテクチャを知らないとき、かかる順序付きリストを予め構成することはできないかも知れない。その場合、各スマートキャッシュＤＡＮＥは、（専用調査モジュールにより）サーバＳＥのＨＴＴＰレスポンスのコンテンツタイプヘッダを調査（ｉｎｓｐｅｃｔ）し、それがマニフェストを含むことを識別し、次いで、例えば対応するサービスアクセスポイントで、自分の識別子を順序付きリストに追加することにより前記マニフェストを更新する。

順序付きリストを確立する両方法は共存でき、サーバＳＥにより知られていないスマートキャッシュＤＡＮＥは、サーバＳＥのＨＴＴＰレスポンスを受信する時、自分を、既存の順序付きリストに追加できる。明らかに、その場合、スマートキャッシュは好ましくは、何らかの情報を追加する前に、順序付きリストに自分が載っているかチェックする。

以下は、スマートキャッシュＤＡＮＥの順序付きリストの、限定ではないＭＰＥＧ−ＤＡＳＨマニフェストの一例である。

順序付きリストのスマートキャッシュ階層情報に加え、マニフェストはさらに、対応するスマートキャッシュ識別子に関連する付加リストに、マルチメディアコンテンツ（またはその一部）の各セグメントの格納された表示を加えることにより、順序付きリストの各スマートキャッシュＤＡＮＥに格納されたマルチメディアコンテンツのセグメントの表現を示し得る。前記付加リストは、（例えば、マネージドネットワークの場合）サーバＳＥにより、又は出会う各スマートキャッシュＤＡＮＥにより構成され得る。

他の変形例では、ネットワークアーキテクチャ及び特にスマートキャッシュ階層を決めるため、サーバＳＥはクライアント端末ＣＴにＨＴＴＰレスポンスを送る。これは、各スマートキャッシュＤＡＮＥが前記応答を受信して、自分の存在をクライアント端末ＣＴと、前記キャッシュＤＡＮＥとクライアント端末ＣＴ間にある次のキャッシュにレポートできるようにする拡張ヘッダを含む。ＨＴＴＰ拡張ヘッダは次のように定義できる：

ヘッダ拡張により、サーバＳＥ及び／又はスマートキャッシュＤＡＮＥに、自分の存在をダウンストリームのスマートキャッシュＤＡＮＥ及び／又はクライアント端末ＳＥに示す手段を提供し得る。かかる手段はどの応答にも（特に、マニフェストを含むもの）添付され得る。
サーバＳＥは、ＨＴＴＰレスポンスに添付されたシンタックス「Ｘ−ＳｍａｒｔＣａｃｈｅ： ｒｅｑｕｉｒｅｄ」を用いて、ダウンストリームのスマートキャッシュＤＡＮＥに、専用修正モジュールにより、自分の識別子と、任意的にその接続情報を添付させることができる。このヘッダを受信すると、各スマートキャッシュＤＡＮＥは、順序付きリストに自分の識別子と接続情報とをプリペンド（ｐｒｅｐｅｎｄ）する。有利にも、ＨＴＴＰレスポンスを受信した最初のスマートキャッシュは、「ｒｅｑｕｉｒｅｄ」トークンを破棄する。

この変形例の利点は、前記ＨＴＴＰ拡張ヘッダは、（さらに別のコンテンツデータ転送などの）他の応答メッセージに添付することができる。それは、マニフェストを含むＨＴＴＰレスポンスの傍受時に使えるが、後者の修正はできない。

例示的だが限定的でない例として、スマートキャッシュ階層は、ＨＴＴＰレスポンスを用いて次のように示すことができる：

好ましい実施形態の別の態様では、クエリーしているスマートキャッシュＤＡＮＥのシグナリングメッセージは、データ配信に使われる主チャネルとは別の補助通信チャネル（又はパス）により交換できる。この補助チャネルはデータ主チャネルとは独立して動作する。かかるシグナリングメカニズムはアウトオブバンド・シグナリングと名付けられている。

アウトオブバンド・シグナリングの２つの区別できるメカニズムは、第１のメカニズムの場合、具体的なスマートキャッシュＤＡＮＥをターゲットにする別のプロトコルを実装して開発でき、第２のメカニズムの場合、ＨＴＴＰの要求を自然な上向きルーティングからの利益をシグナリングする第２のＴＣＰ接続を有するＨＴＴＰプロトコルを実装して開発できる（サーバＳＥに向けてクライアント端末ＣＴにより送信されたシグナリング要求は、当然ながら、出会ったスマートキャッシュＤＡＮＥと適当な時に反応できるレガシーキャッシュＲＮＥを通る）。いかなる場合にも、これらのメカニズムはレガシーキャッシュＲＮＥには影響しない。

特定プロトコルを用いる第１のメカニズムによると、シグナリングオーバーレイはスマートキャッシュ階層とその識別子とを用いるところにある。シグナリングオーバーレイ（ｓｉｇｎａｌｉｎｇ ｏｖｅｒｌａｙ）が得られると、異なるネットワーク機器は互いに通信できる。スマートキャッシュインターフェースを用いてキャッシュ管理動作を交換できる。前記スマートキャッシュインターフェースは、ＨＴＴＰレスポンスヘッダに含まれる又はマニフェストの一部として提供されるスマートキャッシュ・サービスアクセスポイントによりアクセスできる。それにより、ＤＡＳＨ／ＨＡＳクライアントは、スマートキャッシュインターフェースの動作を起動できる。各動作は、動作識別子とそのパラメータとを含むメッセージを構成し、それをスマートキャッシュインターフェースに送信することにより、起動できる。

例示的ではあるが限定的ではない例では、シグナリングメッセージは、ＪＳＯＮストリングス（ＪＳＯＮ ｓｔｒｉｎｇｓ）として構成でき、これは多くのサーバサイドスクリプティング言語で容易に解析される。シグナリングメッセージの受信時、スマートキャッシュＤＡＮＥは要求された動作を実行できる。

特に、クライアント端末ＣＴとスマートキャッシュＤＡＮＥとの間のシグナリングメッセージは複数の好適なプロトコルにより送信できる。

第１の例示的例では、ＷｅｂＳｏｃｋｅｔを用い、これによりクライアント端末ＣＴとスマートキャッシュＤＡＮＥとの間の双方向ポイントツーポイント通信が可能である。第２の例示的例では、ＸＭＰＰを用いて、（例えば、スマートキャッシュの全てのクライアント端末へのキャッシュ更新通知に関する）情報のポイントツーマルチポイント（ｐｏｉｎｔ ｔｏ ｍｕｌｔｉ−ｐｏｉｎｔ）送信が可能である。当然に、他のプロトコルを使ってもよい。

第１のメカニズムにより、クライアント端末ＣＴは、前記スマートキャッシュＤＡＮＥに格納されたセグメントとその表現をディスカバーするため、スマートキャッシュＤＡＮＥとメッセージを交換できる。次のメッセージを使える：

このシグナリングメッセージを受信すると、スマートキャッシュＤＡＮＥは、キャッシュされたセグメントの識別子を含む更新されたリストを回答できる。このメッセージは、個別の各スマートキャッシュのコンテンツの正確な概要を得るため、クライアント端末により、そのアップストリームのどのスマートキャッシュＤＡＮＥにも送信できる。

また、スマートキャッシュＤＡＮＥは、登録されたクライアント端末であって例えばモニターしたいセグメントを事前に指定していたものへのコールバック（ｃａｌｌｂａｃｋ）を用いて、クライアントに、そのキャッシュ内容の変化に関して通知できる。かかるコールバックメカニズムは、ＨＴＭＬ５ウェブソケット、サーバーサイドイベントを用いて、今日では容易に実装されるが、他の技術を利用して同様の結果を実現することもできる。

第２のメカニズムに従って、クライアント端末ＣＴは、ＨＴＴＰを、キャッシュのチェーン（スマートキャッシュＤＡＮＥとレガシーキャッシュＲＮＥ）にクエリーしてキャッシュされたコンテンツをディスカバーするシグナリング手段として用いることもできる。これらのシグナリングＨＴＴＰメッセージは、同じサーバアドレスに向けた二次的ＴＣＰセッションで送信され、主データ配信セッションと同じパスをたどる。シグナリングＨＴＴＰリクエストは、特に、データ転送をトリガーすることを回避するように構成される。

この目的の為、ＨＴＴＰ ＨＥＡＤメソッドまたは最小バイトレンジＧＥＴ（例えば、データの単一バイトを要求するもの）を用いることができる。入来セグメントの異なる表現を求める複数のＨＥＡＤ（又は１バイトレンジＧＥＴ）リクエストを送信し、提案の拡張を用いることにより、クライアント端末ＣＴは、キャッシュされた表現の位置のマップを構成することができる。

特に、キャッシュの内容をクエリーするため、クライアント端末ＣＴは、最も近いキャッシュの内容を要求する「ｏｎｌｙ−ｉｆ−ｃａｃｈｅｄ」命令を伴う「Ｃａｃｈｅ−ｃｏｎｔｒｏｌ」ＨＴＴＰヘッダを用いることができる。しかし、第１のメカニズムと比較して、ＨＴＴＰベースのメカニズムでは黙示的に、サーバＳＥに向かうパスの最初のキャッシュのみへのクエリーができる。

最初のキャッシュのみにクエリーするという欠点を緩和する拡張として、シグナリング要求の「ｏｎｌｙ−ｉｆ−ｃａｃｈｅｄ」命令は、考慮すべきキャッシュの深さの表示を更に含んでも良い。例えば、次の通りである：

この深さ値がスマートキャッシュＤＡＮＥに解釈され、セグメントの要求された表現はスマートキャッシュＤＡＮＥにキャッシュされていない場合、前記スマートキャッシュは、深さ値が許容すれば、そのシグナリング要求を上に転送する。スマートキャッシュＤＡＮＥが、要求された表現を格納していないときは常に、シグナリング要求を転送する前に、深さ値がデクリメントされ、ＨＴＴＰヘッダが適宜修正される。スマートキャッシュＤＡＮＥが、深さ値が１であるシグナリング要求を受信すると、前記シグナリング要求は、キャッシュミスの場合でも、それ以上転送されない。

改良において、要求された表現を格納しているスマートキャッシュＤＡＮＥは、その応答に、到達した深さを示す補足命令を含んでいてもよい。例えば、

そして、スマートキャッシュＤＡＮＥから受信した値で、クライアント端末ＣＴは、クライアント端末ＣＴのシグナリング要求の初期の深さ値から、返された値を減算することにより、考慮されたスマートキャッシュＤＡＮＥまでの（キャッシュに関する）距離を知ることができる。

あるいは、クライアント端末ＣＴは、シグナリング要求中でクエリーの深さを特定することにより、それをあるキャッシュに制限してもよい。シグナリング要求が、特定された前記スマートキャッシュＤＡＮＥに到達し、前記スマートキャッシュＤＡＮＥが、要求されたセグメントの表現を格納していない場合、特定された前記スマートキャッシュＤＡＮＥは、要求をサーバＳＥに転送せずに、否定的な回答をする。この目的のため、目標スマートキャッシュ識別子を指定する拡張が、ＨＴＴＰシグナリング要求のキャッシュ制御（ｃａｃｈｅ−ｃｏｎｔｒｏｌ）「ｏｎｌｙ−ｉｆ−ｃａｃｈｅｄ」命令に追加される。例えば：

シグナリング要求で用いられるスマートキャッシュ識別子は、スマートキャッシュＤＡＮＥの既知のＳＡＰであっても、前記スマートキャッシュＤＡＮＥのユニークな識別子であってもよい。

ＨＡＳクライアント端末ＣＴが、サーバＳＥへのパス上に配置されたスマートキャッシュＤＡＮＥを知っていて、各スマートキャッシュＤＡＮＥに保持されたキャッシュされた表現のリストを知っている場合、クライアント端末ＣＴは方法Ｍを実装できる。

（ｋ個のセグメントの１つのシーケンスを確定する）ｋ個の入来セグメントについて、クライアント端末ＣＴとサーバＳＥとの間のスマートキャッシュＤＡＮＥの内容について分かっていれば、方法Ｍは、ダウンロードされるシーケンスの前記セグメントのｋ個の表現を決定できる。方法Ｍは、ｍ個のセグメント（１≦ｍ≦ｋ）をダウンロードした後、またはキャッシュ更新メッセージの受信時に定期的に実行されることが好ましい。かかる更新により、ｍ＋１個からｍ＋ｍ個までのセグメントのさらなるダウンロードが、（ｍ＋ｋまでの予測を用いて）最適化できる。

好ましい実施形態によると、図３に示したように、クライアント端末ＣＴにおいて、サーバＳＥに格納され、異なる表現で利用可能なマルチメディアコンテンツのｋ個のセグメントの入来シーケンスをダウンロードする方法は、次のステップを含む：
− クライアント端末ＣＴとサーバＳＥとの間に配置された、（上記の通り）特定されたキャッシュＤＡＮＥに格納された、又は格納されていない前記セグメントの利用可能な表現の一部または全部の組み合わせについて、次を計算するステップ（ステップＳ１）：
§ ｋ個の表現の前記組み合わせの各々の画質の効用関数Ｕ（ｋ）の値；及び
§ 前記組み合わせの各々をダウンロードする予測時間Ｔ（ｋ）；
計算するステップＳ１は、図２に示したように、クライアント端末ＣＴの計算器７により実行される。変形例では、計算器７はプロセッサモジュール５に組み込まれても、その一部であってもよい。
− 決定された効用関数値のうち、ダウンロード時間が（例えば、セグメントのシーケンスのプレイアウト時間に対応する）時間閾値より短い、最も高い効用関数値を選択するステップ（ステップＳ２）。選択するステップＳ２はクライアント端末ＣＴの選択モジュール８により実行される；
− クライアント端末ＣＴにおいて、選択された組み合わせに関連する表現の少なくとも初期シーケンスをダウンロードするステップ（ステップＳ３）；選択された組み合わせに関する情報を受信するとき、選択された表現のダウンロードは、通信モジュール２により及び／又は適応的ストリーミングモジュール３により、管理される。
当然に、ステップＳ１乃至Ｓ３の少なくとも幾つかはクライアント端末ＣＴではなく、外部ネットワーク機器（例えば、サーバ、ゲートウェイ、プロキシなど）で実行されても良い。
特に、ある組み合わせの場合、効用関数Ｕ（ｋ）は次のものに依存する：
− 前記組み合わせの表現の

（外１）

の全体的画質；
− 前記組み合わせの表現の変動性σ；
− 前記組み合わせの表現のキャッシュミスのコストＭ（ｋ）。
全体的画質（ｏｖｅｒａｌｌ ｑｕａｌｉｔｙ）は、クライアント端末のエンドユーザにより知覚されるので、前記組み合わせにおける表現の画質に比例する。高画質を提供するには高いビットレートを使うので、

（外２）

と記される表現のビットレートの和又はその平均を、この全体的画質の推定として用いることができる。

変動性は、例えば、前記組み合わせ中の表現値の分散により表すことができる。
キャッシュミスのコストは、帯域幅コストであり、ネットワークリソースに影響し、データを配信するサーバリソースにおけるコストでもある。両者は、サーバからダウンロードされるセグメントのビットレートに比例し、それゆえ、このコストは、キャッシュミスのあるセグメントの表現のビットレートの和により表すことができる。

限定的ではなく例示的な例では、ある組み合わせの効用関数Ｕ（ｋ）は、次の式により求められる：

ここで、
−

（外３）

は、前記組み合わせの表現の平均ビットレートであり、ｋはシーケンスのセグメント数であり；
− σは前記組み合わせの表現の分散であり（それゆえシーケンスの不安定性を示す）；
− αは分散の加重パラメータであり；
− Ｍ（ｋ）は前記組み合わせの表現のキャッシュミスの平均コストであり；
− βはキャッシュミスの平均コストの加重パラメータである。

特に、ある組み合わせの表現の平均ビットレートは、次の式により決定できる：

Ｒｉは、前記組み合わせに属するセグメントｉのある表現のビットレートである。
また、前記組み合わせの表現の分散σは次の式で得られる：

分散σは、表現間の変化数と、平均的表現からの変化の大きさとに応じて大きくなる。
さらに、前記組み合わせの表現のキャッシュミスの平均コストＭ（ｋ）は、例えば、

と書ける。
ここで、セグメントｉの表現がサーバＳＥから読み出された場合には、Ｓｉ＝１であり、そうでなければ（その表現は、特定されたスマートキャッシュＤＡＮＥの１つにキャッシュされていれば）、Ｓｉ＝０である。

シーケンスの効用関数Ｕ（ｋ）を最大化することにより、ビットレートが高く、分散が小さく、キャッシュミスが少ない方が優先される。加重パラメータα及び／又はβを調整して、分散及び／又はキャッシュミスの許容度を確定することができる。明らかに、分散及び／又はキャッシュミスは、α及び／又はβの値をゼロにすることにより、無くすことができる。

効用関数Ｕ（ｋ）は、次の基準を満たす組み合わせを決定するために、考えられる組み合わせの各候補に対して計算される：
− 高い平均ビットレート（及び黙示的に高い画質）
− 変動性が小さい安定したビットレート、これは一定のビデオ画質を意味する
− サーバＳＥ及びネットワークＮへの負荷をできるだけ低減するため、最大数のセグメントがキャッシュから読み出される。
また、組み合わせの推定ダウンロード時間Ｔ（ｋ）は、次の式

により計算してもよい。
ここで、
− ＢＷｓｅｒｖｅｒは、サーバから前記組み合わせの表現をダウンロードしている時に観測されたダウンリンク帯域幅であり；
− ＢＷｃｉは、前記組み合わせのセグメントｉの表現を、その表現を保持している最寄りのスマートキャッシュＤＡＮＥからダウンロードしている時に観測されたダウンリンク帯域幅である。Ｃｉは、組み合わせの各表現に対して、前記表現を保持している最寄りのキャッシュのインデックスを取ることにより確立されるベクトルＣの要素に対応する。

分母では、Ｓｉは０または１なので、Ｓｉまたは（１−Ｓｉ）の一方のみがゼロではない。そのため、分母は、サーバＳＥからのリンクの帯域幅ＢＷｓｅｒｖｅｒか、又は考えられているスマートキャッシュＤＡＮＥからの帯域幅ＢＷｃｉである。セグメントの選択された各表現のビットレートの数を帯域幅ＢＷｓｅｒｖｅｒで割ることにより、各表現をダウンロードするのに必要な時間が得られる。

この、組み合わせのダウンロード時間Ｔ（ｋ）は、好ましくは、シーケンスのプレイアウト時間よりも短くなければならず、そうでないと、バッファが空になってプレイバックが中断されことがある。そのため

となる。

好ましい実施形態では、クライアント端末ＣＴは、ｋ個のセグメントの表現の各組み合わせに対して、効用関数Ｕ（ｋ）とダウンロード時間Ｔ（ｋ）を計算する（ステップＳ１）。ｒを（サーバＳＥから）入手できる表現の数とすると、Ｕ（ｋ）とＴ（ｋ）はそれぞれｒ^ｋ回計算される。

このように、ステップＳ２を行うことにより、クライアント端末ＣＴは、バッファが空になるのを回避するｋ個の表現の最良のシーケンスを選択できる。

下のテーブルは、１から８までの範囲の８個のセグメントのシーケンスに対する、スマートキャッシュＤＡＮＥのグループの内容の限定的ではない例を示している（１はダウンロードされたシーケンスの最初のセグメントである）。セルの値は、考えているセグメント／表現を保持するスマートキャッシュＤＡＮＥのインデックスに対応する。

一定表現２５００ｋｂｐｓでのｋ個のセグメントのシーケンスに対応する次のビットレートベクトルＲ＝｛Ｒ１＝２５００ｋｂｐｓ，Ｒ２＝２５００ｋｂｐｓ，Ｒ３＝２５００ｋｂｐｓ，Ｒ４＝２５００ｋｂｐｓ，Ｒ５＝２５００ｋｂｐｓ，Ｒ６＝２５００ｋｂｐｓ，Ｒ７＝２５００ｋｂｐｓ，Ｒ８＝２５００ｋｂｐｓ｝を考えることにより、各セグメントに対して、表現２５００ｋｂｐｓを保持する最寄りのスマートキャッシュＤＡＮＥのインデックスを取ることにより、Ｃベクトルが構成される。上記のテーブルに与えられたスマートキャッシュの例では、Ｃ＝｛１，１，２，１，０，０，０，１｝であり、０は表現２５００ｋｂｐｓが、特定されたスマートキャッシュＤＡＮＥにキャッシュされていないことを意味する。

好ましい実施形態の変形例では、ｋ個のセグメントの利用可能な表現の各組み合わせに対して効用関数Ｕ（ｋ）とダウンロード時間Ｔ（ｋ）を計算する替わりに、クライアント端末ＣＴは、好ましくは、各表現のキャッシュされたセグメントの数を、評価モジュール９により（ｋ個の入来セグメントの、クライアント端末ＣＴとサーバＳＥとの間のスマートキャッシュＤＡＮＥの内容に関する情報から）計算する（ステップＳ２０）。これは、ステップＳ２１において、最も頻繁にキャッシュされる表現（目標表現とも呼ぶ）を選択するためである。

上記のｋ＝８のテーブル例に基づき、選択される表現はビットレートが２５００ｋｂｐｓである表現であり、これは５つのセグメントがキャッシュされている。対応する目標組み合わせのビットレートベクトルＲは、目標表現のビットレートと等しい一様な値を有するＲ＝｛Ｒ１＝２５００ｋｂｐｓ，Ｒ２＝２５００ｋｂｐｓ，Ｒ３＝２５００ｋｂｐｓ，Ｒ４＝２５００ｋｂｐｓ，Ｒ５＝２５００ｋｂｐｓ，Ｒ６＝２５００ｋｂｐｓ，Ｒ７＝２５００ｋｂｐｓ，Ｒ８＝２５００ｋｂｐｓ｝。

さらにステップＳ２２において、クライアント端末ＣＴは、その計算器７により、目標組み合わせのダウンロード時間Ｔ（ｋ）を計算する。

さらにステップＳ２３において、クライアント端末ＣＴは、計算されたダウンロード時間Ｔ（ｋ）（初期Ｔ（ｋ）とも呼ぶ）をプレイアウト時間（ｐｌａｙｏｕｔ ｔｉｍｅ）と比較する。

初期Ｔ（ｋ）がプレイアウト時間と少なくとも等しい場合（

（外４）

）、クライアント端末ＣＴは、代替的な、セグメントのキャッシュされた表現を決定し（ステップＳ２４）、それに対しては、（例えば、上記のテーブルの例におけるセグメント５、６及び７のような）目標表現はスマートキャッシュに格納されない。

この目的のため、クライアント端末ＣＴは、ステップＳ２５において、代替的表現の代替的順序付きリストを構成する。これでは、より良い画質のキャッシュされた代替的表現が昇順にリストされ、より低い画質のキャッシュされた代替的表現が降順に続く。
ステップＳ２６において、クライアント端末ＣＴは：
− 代替的順序付きリストの最初の表現を選択し；
− 選択された代替的表現が、対応するセグメントの目標表現と置き換えられたこと以外は目標組み合わせと同様の新しい組み合わせを決定し（上記テーブルの例では、新しい組み合わせのベクトルＲは｛２５００ｋｂｐｓ，２５００ｋｂｐｓ，２５００ｋｂｐｓ，２５００ｋｂｐｓ，２５００ｋｂｐｓ，４５００ｋｂｐｓ，２５００ｋｂｐｓ，２５００ｋｂｐｓ｝である）、
− 前記新しい表現の組み合わせのダウンロード時間を計算する。

新しい組み合わせのＴ（ｋ）が目標組み合わせのＴ（ｋ）に対して増加する場合、選択された代替的表現はステップＳ２７でリジェクトされ、新しい組み合わせは拒絶される。ステップＳ２６は、代替的順序付きリストの次の表現に対して繰り替えされ、目標組み合わせが前記次の表現で修正され、新しい組み合わせがさらに確立される。

新しい組み合わせのＴ（ｋ）がプレイアウト時間より短い場合、クライアント端末ＣＴは前記新しい組み合わせのダウンロードを開始する（ステップＳ３）。

新しい組み合わせのＴ（ｋ）が目標組み合わせのＴ（ｋ）に対して減少するが、少なくともプレイアウト時間と等しい場合、代替リストの選択された代替的表現は保持され（ステップ２８）、目標組み合わせの替わりに新しい組み合わせを考慮することにより、ステップＳ２６が反復される。

上記のテーブル例では、これは、中間解が見つかるまで、Ｒ６＝４５００ｋｂｐｓ、Ｒ５＝６５００ｋｂｐｓ、Ｒ７＝６５００ｋｂｐｓ及びＲ５＝１２００ｋｂｐｓ、Ｒ７＝１２００ｋｂｐｓとして順次テストされる。

代替的順序付きリストのすべての表現が試され、最後の新しい組み合わせに対して計算されたＴ（ｋ）がプレイアウト時間より短くなければ、クライアント端末ＣＴは、ステップＳ２９において、目標表現より画質が低い表現を含む、降順に並べられた追加の代替的リストを作る（ｅｓｔａｂｌｉｓｈ）。ステップ２６、２７及び２８は前記追加の順序付きリストに適用される。

このアルゴリズムの終わりに、Ｔ（ｋ）が制約を満たす、又はＴ（ｋ）の値はこれ以上短くならない。

初期Ｔ（ｋ）がプレイアウト時間より短いとき、クライアント端末ＣＴは、より高いレートで、キャッシュされた表現を使うことにより、効用関数Ｕ（ｋ）を大きくするよう試みる（ステップＳ２４１）。最初のステップＳ４において、クライアント端末ＣＴは、昇順で、初期の目標表現より大きい表現の順序付きリストを構成する。

そして、このリストの各表現に対して、クライアント端末ＣＴは：
− 考えている表現の対応セグメントがキャッシュ中にあるように、最高のｉを選択し（ステップＳ４１）；
− 考えている表現で、前のＲｉを変更することにより得られる表現の組み合わせのＵ（ｋ）とＴ（ｋ）を計算する（ステップＳ４２）。

ついで、Ｔ（ｋ）が制約をまだ満たし、Ｕ（ｋ）の新しい値が前の値より大きいとき、クライアント端末ＣＴは新しい組み合わせを保持し、次の（より低い）ｉでステップＳ４１を繰り返す。Ｔ（ｋ）がもはや制約を満たさないか、またはＵ（ｋ）が減少するとき、クライアント端末ＣＴは、前の組み合わせを回復するため、Ｒｉの新しい値をリジェクトする。

全てのインデックスｉが考慮されたら、次に高い表現をテストする。

明らかに、好ましい実施形態から逸脱せずに、他の発見的問題解決法を用いて、Ｕ（ｋ）を改善しつつ、Ｔ（ｋ）に対する制約を満たすこともできる。

当然に、ステップＳ２０乃至Ｓ２９の少なくとも幾つかはクライアント端末ＣＴではなく、外部ネットワーク機器（例えば、サーバ、ゲートウェイ、プロキシなど）で実行されても良い。

所望の組み合わせ、セグメントシーケンスが決定されると、クライアント端末ＣＴは、ｍ個のセグメント（１≦ｍ≦ｋ）に達するまで、またはスマートキャッシュから更新メッセージを受け取るまで、または受信レートが変化するまで、遅延無しにそのシーケンスから次のセグメントをダウンロードする。前出のイベントのどれにおいても、クライアント端末ＣＴは方法Ｍを繰り返す。

ネットワーク情報は、サーバ（ＳＥ）とクライアント端末（ＣＴ）との間のパスにある階層的キャッシュ（ＤＡＮＥ）を含み、任意的に、ネットワーク情報は、さらに、前記階層の少なくとも幾つかのキャッシュに対して、前記キャッシュ（ＤＡＮＥ）により記憶されたセグメントの表現のリストを含む。

留意点として、発明の別の変形例では、ネットワーク情報は、セグメントの受信に用いられるインターフェースと同様の、またはセグメントの受信に用いられるインターフェースとは異なるネットワークインターフェースを通じて受信される。

実施形態によると、クライアント端末のネットワークインターフェースは、Ｗｉｆｉ、ＡＤＳＬ、Ｃａｂｌｅ、Ｍｏｂｉｌｅ及び／又はＢｒｏａｄｃａｓｔ（例えば、ＤＶＢ、ＡＴＳＣ）インターフェースからネットワーク情報を受信するように適応されている。

異なる実施形態によると、クライアント端末のネットワークインターフェースは、Ｗｉｆｉ、ＡＤＳＬ、Ｃａｂｌｅ、Ｍｏｂｉｌｅ及び／又はＢｒｏａｄｃａｓｔ（例えば、ＤＶＢ、ＡＴＳＣ）インターフェースからネットワーク情報を受信するように適応されている。

異なる実施形態によると、クライアント端末は、セグメントを受信するのに使われるプロトコルと同様のプロトコルを、ネットワーク情報を受信するために用いる。異なる実施形態では、クライアント端末はネットワーク情報を受信するため異なるプロトコルを用いている：
− セグメント送受信はｈｔｔｐまたはフルートプロトコルを用いることができる；
− ネットワーク情報の送受信には、ＴＲ６９ Ｂｒｏａｄｂａｎｄ Ｆｏｒｕｍプロトコルまたは放送プロトコル（例えば、ｘｍｐｐ ＩＥＴＦ、ＤＤＳ ＯＭＧ（Ｏｂｊｅｃｔ Ｍａｎａｇｅｍｅｎｔ Ｇｒｏｕｐ））を使える。

異なる実施形態によると、ネットワーク情報はランダムアクセスメモリ（ＲＡＭ）に記憶される。

異なる実施形態によると、セグメントは、ローカルメモリ（例えば、ハードディスクまたはフラッシュメモリ）に記憶され、及び／又はデコーダにより復号され、及び／又はディスプレイに表示される。

異なる実施形態によると、クライアント端末は次を含むセットに属する：
− 携帯型メディアデバイス；
− 携帯電話；
− ゲームデバイス：
− セットトップボックス；
− テレビセット；
− タブレット；
− ラップトップ；及び
− 集積回路。

図のフローチャートとブロック図は、本発明の様々な実施形態によるシステム、方法及びコンピュータプログラム製品の可能性のある実装の構成、動作及び機能を示す。これに関連して、フローチャートやブロック図の各ブロックは、モジュール、セグメント、コードの一部分を表す。これは指定された論理的機能を実装する一又は複数の実行可能命令を含む。留意すべき点として、代替的な実施形態では、ブロックに示した機能は図面に示した順序でない順序で行ってもよい。例えば、順次的に示された２つのブロックは、その機能に応じて、実際には、実質的に同時に実行してもよく、逆の順序で実行してもよいし、ブロックは別の順序で実行されてもよい。また、留意点として、ブロック図及び／又はフローチャートの各ブロック、及びブロック図及び／又はフローチャートのブロックの組合せは、指定された機能や動作を実行する特定目的ハードウェアベースシステムにより、又は特定目的ハードウェアとコンピュータ命令との組合せにより実施できる。明示的には説明していないが、本実施形態は任意の組み合わせやサブコンビネーションで利用できる。

本技術分野の当業者には言うまでもないが、本原理の諸態様はシステム、方法、またはコンピュータ読み取り可能媒体として実施され得る。したがって、本原理の諸態様は、完全にハードウェアによる実施形態、完全にソフトウェアによる実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなど）、またはソフトウェアとハードウェアの態様を組み合わせた実施形態の形式を取り得る。これらはすべてここでは概して「回路」、「モジュール」または「システム」と呼ぶ。さらにまた、本原理の諸態様はコンピュータ読み取り可能記憶媒体の形式を取り得る。一以上のコンピュータ読み取り可能記憶媒体の任意の組み合わせを利用できる。

コンピュータ読み取り可能記憶媒体は、一以上のコンピュータ読み取り可能媒体に化体され、その上に化体され、コンピュータにより実行可能なコンピュータ読み取り可能プログラムコードを有するコンピュータ読み取り可能プログラム製品の形式を取ることができる。本願のコンピュータ読み取り可能記憶媒体は、情報をその中に記憶する本来的機能、及びそれから情報の読み出しをする本来的機能を与えられた、非一時的記憶媒体である。コンピュータ読み取り可能記憶媒体は、例えば、電子的、磁気的、光学的、電磁気的、赤外線、又は半導体のシステム、装置、又はデバイス、又はそれらの任意の好適な組み合わせであってもよいが、これらに限定されない。言うまでもなく、次のリストは、本原理を適用できるコンピュータ読み取り可能記憶媒体のよりぐらい的な例を提供するものであるが、当業者には明らかなように、単なる例示であり網羅的なものではない：ポータブルコンピュータディスケット；ハードディスク；ランダムアクセスメモリ（ＲＡＭ）；リードオンリーメモリ（ＲＯＭ）；消去可能プログラマブルリードオンリーメモリ（ＥＰＲＯＭまたはフラッシュメモリ）；ポータブルコンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭ）；光学的記憶デバイス；磁気記憶デバイス；又はそれらの任意の好適な組み合わせ。

Claims (20)

1. セグメントに分割され少なくとも１つのリモートサーバにより提供されるマルチメディアコンテンツを受信するように構成されたクライアント端末による、ネットワーク情報を取得する方法であって、各セグメントは一以上の表現で入手可能であり、
   前記ネットワーク情報はサーバと前記クライアント端末との間のパスに沿って、階層を成すキャッシュを含み、
   前記ネットワーク情報は、前記階層の少なくとも幾つかのキャッシュについて、前記キャッシュにより記憶されたセグメントの表現のリストを更に含み、
   前記ネットワーク情報は、前記クライアント端末によりサーバから受信されるマニフェストにより提供され、前記マニフェストは、前記サーバにおいて入手可能な、前記マルチメディアコンテンツの表現をリストしている、
   方法。
2. 前記マニフェストは、前記サーバと前記クライアント端末との間のパスに沿ったキャッシュの順序付きリストを含む、請求項１に記載の方法。
3. 前記マニフェストは、前記順序付きリストの各キャッシュについて、前記キャッシュにより記憶された前記セグメントの表現を特定する、請求項２に記載の方法。
4. 前記マニフェストは、前記サーバと前記クライアント端末との間のパスに沿って出会う、前記順序付きリストの各キャッシュの識別子を含む、請求項２または３に記載の方法。
5. 前記マニフェストは、前記キャッシュの少なくとも１つの接続情報を含む、請求項４に記載の方法。
6. 前記クライアント端末は、各キャッシュにより記憶された前記セグメントの表現を決定するために、データの配信に用いられるデータパスとは異なる補助通信パスを用いて、前記順序付きリストの少なくとも幾つかのキャッシュにクエリーする、
   請求項２ないし５いずれか一項に記載の方法。
7. セグメントに分割され少なくとも１つのリモートサーバにより提供されるマルチメディアコンテンツを受信するように構成されたクライアント端末であって、各セグメントは一以上の表現で入手可能であり、
   前記クライアント端末は、前記サーバと前記クライアント端末との間のパスに沿った、階層を成すキャッシュを含むネットワーク情報を受信するように構成された通信モジュールを含み、
   前記ネットワーク情報は、前記階層の少なくとも幾つかのキャッシュについて、前記キャッシュにより記憶されたセグメントの表現のリストを更に含み、
   前記ネットワーク情報は、前記クライアント端末によりサーバから受信されるマニフェストにより提供され、前記マニフェストは、前記サーバにおいて入手可能な、前記マルチメディアコンテンツの表現をリストしている、
   クライアント端末。
8. 前記マニフェストは、前記サーバと前記クライアント端末との間のパスに沿ったキャッシュの順序付きリストを含む、請求項７に記載のクライアント端末。
9. 前記マニフェストは、順序付きリストの各キャッシュについて、前記キャッシュにより記憶された前記セグメントの表現を特定する、請求項７または８に記載のクライアント端末。
10. 前記マニフェストは、前記サーバと前記クライアント端末との間のパスに沿って出会う、前記順序付きリストの各キャッシュの識別子を含む、請求項８または９に記載のクライアント端末。
11. 前記マニフェストは、前記キャッシュの少なくとも１つの接続情報を含む、
    請求項１０に記載のクライアント端末。
12. 前記クライアント端末は、各キャッシュにより記憶された前記セグメントの表現を決定するために、データの配信に用いられるデータパスとは異なる補助通信パスを用いて、前記順序付きリストの少なくとも幾つかのキャッシュにクエリーする、請求項８ないし１１いずれか一項に記載のクライアント端末。
13. 少なくとも１つのリモートサーバにより提供されるマルチメディアコンテンツのセグメントをクライアント端末に配信するように構成されたキャッシュによる、ネットワーク情報を送信する方法であって、各セグメントは一以上の表現で入手可能であり、
    前記ネットワーク情報はサーバと前記クライアント端末との間のパスに、階層を成すキャッシュを含み、
    前記キャッシュは、
    受信した階層に関する受信した表現のリストに、前記キャッシュに関連するローカルでキャッシュされた表現のリストを追加し、
    前記クライアント端末に、更新した表現のリストを転送し、
    前記ネットワーク情報は、前記クライアント端末によりサーバから受信されるマニフェストにより提供され、前記マニフェストは、前記サーバにおいて入手可能な、前記マルチメディアコンテンツの表現をリストしている、
    方法。
14. 前記マニフェストは、前記サーバと前記クライアント端末との間のパスに沿ったキャッシュの順序付きリストを含む、請求項１３に記載の方法。
15. 前記マニフェストは、前記順序付きリストの各キャッシュについて、前記キャッシュにより記憶された前記セグメントの表現を特定する、請求項１４に記載の方法。
16. 前記キャッシュは、自分の識別子を追加して前記順序付きリストを構成することにより、前記順序付きリストを修正する、請求項１４または１５に記載の方法。
17. 前記キャッシュは、接続情報を追加することにより、前記マニフェストを更に修正する、
    請求項１６に記載の方法。
18. ネットワーク情報を送信するように適応されたキャッシュであって、前記キャッシュは少なくとも１つのリモートサーバにより提供されるマルチメディアコンテンツのセグメントをクライアント端末に配信するように構成され、各セグメントは一以上の表現で入手可能であり、
    前記ネットワーク情報はサーバと前記クライアント端末との間のパスに、階層を成すキャッシュを含み、
    前記キャッシュは、
    受信した階層に関する受信した表現のリストに、前記キャッシュに関連するローカルでキャッシュされた表現のリストを追加し、
    前記クライアント端末に、更新した表現のリストを転送するように構成され、
    前記ネットワーク情報は、前記クライアント端末によりサーバから受信されるマニフェストにより提供され、前記マニフェストは、前記サーバにおいて入手可能な、前記マルチメディアコンテンツの表現をリストしている、
    キャッシュ。
19. 通信ネットワークからダウンロード可能であり、及び／又はコンピュータにより読み取り可能な媒体に記録され、及び／又はプロセッサにより実行可能なコンピュータプログラム製品であって、請求項１乃至６及び１３乃至１７いずれか少なくとも一項の方法のステップを実装するプログラムコード命令を含む、コンピュータプログラム製品。
20. コンピュータプログラム製品が記録され、プロセッサにより実行され得る非一時的コンピュータ読み取り可能媒体であって、請求項１乃至６及び１３乃至１７いずれか少なくとも一項の方法のステップを実装するプログラムコード命令を含む、非一時的コンピュータ読み取り可能媒体。
    

Images