JP2016521485A - 少なくとも１つのサーバによって送信されたマニフェストを適応化するための装置および方法 - Google Patents

Abstract

少なくとも１つのサーバから受信された、クライアント端末が要求したマルチメディア・コンテンツに関連付けられたマニフェストを適応化する装置であって、マニフェストは上記マルチメディア・コンテンツのリプリゼンテーションのリストを含み、−上記マニフェストをインターセプトするように構成されたモジュール（１３）と、−上記クライアント端末と上記サーバとの間の経路の少なくとも一部分の達成可能なデータ・レートを推定するように構成された推定器（１４）と、−上記インターセプトされたマニフェストのリプリゼンテーションのリストの中から、上記推定された達成可能なデータ・レートに等しいか、またはそれよりも低い関連付けられたビット・レートを有するリプリゼンテーションを選択するように構成されたモジュール（１５）と、−適応化されたマニフェストを上記クライアント端末に配信するように構成されたモジュール（１６）と、を含み、上記選択されたリプリゼンテーションが推奨される上記装置である。【選択図】図３

Description

本発明は、概して、適応的ストリーミングの分野、例えば、これに限定するわけではないが、ＨＴＴＰ（ハイパーテキスト転送プロトコル）を介する適応的ストリーミングの分野に関し、具体的には、１つまたは以上のサーバによって送信され、クライアント端末が要求したマルチメディア・コンテンツに関連付けられたマニフェストを適応化するための装置および方法に関する。

この欄は技術の様々な態様を読者に紹介することを意図しており、その態様は以下の明細書および／または特許請求の範囲に記載する本発明の様々な態様に関連するであろう。この説明は、本発明の様々な態様についてより良く理解することを容易にする背景情報を読者に提供することに役立つと信じるものである。したがって、この説明は、この観点で解釈されるべきであり、従来技術を容認したものとして解釈されるべきではないことが理解されるであろう。

クライアント端末は、適応的ストリーミングでのオーディオビジュアル・コンテンツ（すなわち、Ａ／Ｖコンテンツ）を再生したい場合、先ず、どのようにすればＡ／Ｖコンテンツを取得できるかを記述したファイルを得る必要がある。これは、ＨＴＴＰプロトコルを介して、ＵＲＬ（（統一資源位置指定子）から記述ファイル、いわゆるマニフェストを取得することによって行われる。マニフェストは、基本的に、Ａ／Ｖコンテンツについての（ビット・レート、解像度、およびその他の特性に関しての）利用可能なリプリゼンテーション（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を列記している。マニフェストは、予め生成されて、クライアント端末に例えば遠隔サーバによって配信される。

実際、データのストリームは、ＨＴＴＰサーバ上でさまざまな品質で利用可能である。最も高い品質は高ビット・レートを有し、最も低い品質は低ビット・レートを有する。これによって、激しく変動するネットワーク状況を被り易い多くの様々な端末への配信が可能になる。

データ・ストリーム全体は複数のチャンクに分割され、クライアント端末が２つのチャンクの間である品質レベルから別の品質レベルへと円滑に切り替えられるようにそのチャンクが作成されている。その結果、ビデオは品質が再生中に変化するかもしれないが、めったにフリーズすることはない。

データ・ストリームはマニフェストによってクライアント端末に通知され、このマニフェストによって、とりわけ複数のリプリゼンテーションを含むリストが与えられ、品質レベル（ビット・レート）毎に１つのリプリゼンテーションが含まれている。各々のリプリゼンテーションは、持続期間が等しいチャンクのシリーズである一連のチャンクから構成されており、クライアントが選択するために付加された記述的要素のセットを有している。各々のチャンクは別個のＵＲＬによってアクセス可能である。

マニフェストは、プロトコルに従って異なるフォーマットを有することができる。Ａｐｐｌｅ ＨＬＳ（ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ）プロトコルでは、マニフェストは、「マスタ・プレイリスト」と呼ばれるＭ３Ｕ８プレイリストである。このプレイリストの各々の要素は、別の１つのプレイリストである（リプリゼンテーション毎に１つ）。その他のプロトコル（例えば、ＤＡＳＨ）に従えば、マニフェスト（ＤＡＳＨに従えば、いわゆるＭｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ、つまりＭＰＤ）は、１つ以上のＸＭＬファイルから作成されており、ＸＭＬファイルは全てのリプリゼンテーションを１つずつ記述したものである。いずれにせよ、マニフェストを作成することは、テキスト・ファイルを作成して決定論的な文法に従ってテキストを書くことと同様に簡単である。

リストになったリプリゼンテーションの順序は、開始時以外重要ではないが、最初のリプリゼンテーションはクライアント端末によって提案された、または、好ましいとされたリプリゼンテーションとして規則によって解釈されることが知られている。

しかしながら、この推奨は、静的なコンテンツの特徴（解像度、オーディオ・チャンネル数など）のみに基づいている。したがって、クライアント端末が開始時に最適なビット・レートを要求する可能性は実に低い。クライアント端末は、その後にそれ自体によって最適なビット・レートに近づける必要があり、これは、ストリーミング動画を見始めるエンドユーザの最初の印象が悪いかもしれないことを意味する。

本発明は、少なくとも上述の欠点を改良することによって解消しようとするものであり、特に、クライアント端末が開始時に最適なリプリゼンテーションを要求する可能性を高めることによって少なくとも上述の欠点を解消し、ストリーミング・セッションのまさに最初からより良いユーザ体験をもたらすものである。

本発明は、少なくとも１つのサーバから受信した、クライアント端末が要求したマルチメディア・コンテンツに関連付けられたマニフェストを適応化する装置であって、そのマニフェストは上記マルチメディア・コンテンツのリプリゼンテーションのリストを含み、
上記装置が、特徴として、
上記マニフェストをインターセプトするように構成されたモジュールと、
上記クライアント端末と上記サーバとの間の経路の少なくとも一部分の達成可能なデータ・レートを（例えば、別のネットワーク設備から受信されたデータに基づいて）推定するように構成された推定器と、
上記インターセプトされたマニフェストのリプリゼンテーションのリストの中から、上記推定された達成可能なデータ・レートに等しいかまたは、それよりも低い関連付けられたビット・レートを有するリプリゼンテーションを選択するように構成されたモジュールと、
適応化されたマニフェストを上記クライアント端末に配信するように構成されたモジュールと、
を含み、上記選択されたリプリゼンテーションが推奨される、上記装置に関する。

本発明によれば、マニフェストの推奨されたリプリゼンテーションがクライアント端末によって選択された場合、最初にダウンロードされるチャンクは、この推奨されたリプリゼンテーションから選ばれる。この推奨されたリプリゼンテーションのビット・レートが、推定された達成可能なデータ・レートに近い場合、クライアントが最適なビット・レートでスタートすることが見込まれる。これは、マニフェストがこのような検討を考慮しないで作成された場合にはめったに起きないことである。これにより、ストリーミング・セッションのまさに開始時点からより良いユーザ体験を得られる。その結果、エンドユーザにとって第一印象が大幅に改善されることは明らかである。

本発明は、換言すれば、クライアント端末の、各々のクライアント端末に定義上特有であるネットワーキング接続性パラメータ（アクセス・ネットワークのタイプ、現行のデータ・レートなど）を考慮に入れる。

本発明に係るある特定の一実施形態において、選択モジュールは、推定された達成可能なデータ・レートに等しいか、またはそれよりも低い関連付けられたビット・レートを有する最初のリプリゼンテーションを選択するようにさらに構成されてもよい。

本発明の別の一様態において、上記装置は、
― 少なくとも、上記クライアント端末を含む第１のネットワークとの第１のインタフェースと、
― 少なくとも、上記サーバを含む第２のネットワークとの第２のインタフェースと、
をさらに備える。

上記装置は、プロキシ装置であることが好ましく、例えば、インターネット・ゲートウェイ、ＷｉＦｉホットスポット、フェムトセル、または、利用可能なスループットをモニタでき、例えば、ＨＴＴＰ適応ストリーミング・マニフェストをインターセプトして修正できる任意の装置のようなプロキシ装置であることが好ましい。

上記選択されたリプリゼンテーションの推奨は、上記適応化されたマニフェストにおいて上記選択されたリプリゼンテーションに注釈を付けることによって行われることが有利である。

本発明に係る一変形例において、上記選択されたリプリゼンテーションの推奨は、上記適応化されたマニフェストにおいて上記選択されたリプリゼンテーションを上記リストされたリプリゼンテーションの最初の位置に配置することによって行われてもよい。

本発明の一例によれば、上記マニフェストはＨＴＴＰ適応的ストリーミング・プロトコルによってサポートされる。

更に、本発明は、少なくとも１つのサーバから受信した、クライアント端末が要求したマルチメディア・コンテンツに関連付けられたマニフェストを適応化する方法であって、そのマニフェストは上記マルチメディア・コンテンツのリプリゼンテーションのリストを含む、上記方法にも関する。

本発明によれば、上記方法は、
上記マニフェストをインターセプトすることと、
上記クライアント端末と上記サーバとの間の経路の少なくとも一部分の達成可能なデータ・レートを（例えば、別のネットワーク設備から受信されたデータに基づいて）推定することと、
上記インターセプトされたマニフェストのリプリゼンテーションのリストの中から、上記推定された達成可能なデータ・レートに等しいか、またはそれよりも低い関連付けられたビット・レートを有するリプリゼンテーションを選択することと、
適応化されたマニフェストを上記クライアント端末に配信することと、
を含み、上記選択されたリプリゼンテーションが推奨される。

ここに開示される実施形態と適用範囲が同等である特定の態様を以下に説明する。この態様は、本発明が取り得る特定の形態の簡潔な要約を読者に単に提供するものであり、本発明の適用範囲を限定することを意図するものではないことを理解されたい。実際、本発明は以下に説明しないような様々な態様を包含し得る。

本発明を実施し得るクライアント―サーバ・ネットワーク構成の概略的な図である。 本発明の好ましい実施形態に係るクライアント端末の一例についてのブロック図である。 好ましい実施形態に係るマニフェストを適応化できるゲートウェイの一例についてのブロック図である。 好ましい実施形態に従って、サーバによって送信された、クライアント端末が要求したマルチメディア・コンテンツに関連付けられたマニフェストを適応化する方法を示すフローチャートである。

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

図１から図３において表されたブロックは純粋に機能的な要素であり、必ずしも物理的に別個の要素に対応するものではない。すなわち、その要素はソフトウェアまたはハードウェアの形態で展開され、あるいは１つ以上の複数の集積回路内で実装され得る。

全図面を通じて可能な限り同じ参照番号を用いて同じまたは類似の部分を表す。

本発明の図面および説明は、本発明を明確に理解するために簡略化して関連要素を例示しており、その一方で、明確性の目的で、通常のデジタル・マルチメディア・コンテンツ配信方法およびシステムにおいて見られる他の多数の要素を省略している。しかしながら、そのような要素はこの技術分野において周知であるので、ここではそのような要素を詳細には説明していない。ここでの開示事項は、当業者に理解されるような変形形態および修正形態の全てを対象とするものである。

好ましい実施形態に従って、本発明をＨＴＴＰ適応的ストリーミング・プロトコルに関して説明する。もちろん、本発明はこのような特定の環境に限定されることはなく、他の適応的ストリーミング・プロトコルを、当然、考慮して実施できる。

図１に示されているように、クライアント―サーバ・ネットワーク構成は、本発明に係るマニフェストを適応化する装置を組み込むことができ、クライアント端末Ｃ、ゲートウェイＧＷ、および１つ以上のＨＴＴＰサーバＳを含む。

クライアント端末Ｃは、第１ネットワークＮ１（ホーム・ネットワークとして）を介してゲートウェイＧＷに接続されており、第２ネットワークＮ２（インターネット・ネットワークとして）を介して１つ以上のＨＴＴＰサーバＳに接続したい。第１ネットワークＮ１はゲートウェイＧＷによって第２ネットワークＮ２に接続される。

ＨＴＴＰサーバＳは、クライアント要求に応じて、ＨＴＴＰ適応的ストリーミング・プロトコルを用いて１つ以上のＴＣＰ／ＩＰ接続を通じてチャンクをクライアント端末Ｃにストリーミングする。この変形例として、ただ１つのＨＴＴＰサーバＳが、チャンクをクライアント端末Ｃにストリーミングできることは当然である。

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

この好ましい実施形態において、クライアント端末Ｃは、ポータブル・メディア機器、携帯電話機、タブレット、またはラップトップパソコンである。もちろん、クライアント端末Ｃは、ビデオ・プレーヤを有さずビデオ・プレーヤを接続するインタフェースを有していてもよい。この場合、クライアント端末Ｃは、例えばセットトップ・ボックスのようなビデオ・デコーダである。

更に、図３に示されているように、この好ましい実施形態のゲートウェイＧＷは、デジタル加入者線（ＤＳＬ）ゲートウェイであり、ＤＳＬ技術によって、ホーム・ネットワークＮ１にインターネット・ブロードバンド・アクセスをもたらす。もちろん、このゲートウェイは、例えばケーブル、ファイバ、または無線のような任意のタイプのブロードバンド・ゲートウェイであってもよい。

この好ましい実施形態において、ゲートウェイＧＷは、少なくとも、以下の要素を含む。
−ホーム・ネットワークＮ１とのＬＡＮ（ローカル・エリア・ネットワーク）（有線および／または無線、例えばＷｉＦｉ、イーサネットなど）接続用インタフェース７
−インターネット・ネットワークＮ２とのブロードバンド（有線および／または無線）接続用インタフェース８
−上記接続用インタフェースを介して通信を行うためのプロトコル・スタックを有する通信モジュール９：特に、この通信モジュールは、ＩＰスタックと表記されるインターネット・プロトコルスタックを有する。
−第１メモリ１０および第２メモリ１１：第１メモリ１０は、マニフェスト（例えば、プレイリストまたはＸＭＬファイル）から抽出された情報を記憶するように構成されている。第２メモリ１１は、インタフェース７および８から受信したパケット／チャンクとインタフェース７および８へ送るパケット／チャンクとをバッファリングするように構成されている。
−一般的な住居用ゲートウェイ機能の実行のために、様々なモジュールと、処理手段と、ルーティングおよびブリッジング手段と、当業者に周知の全ての手段とを接続するための内部バスＢ２

前述の如く、適応的ストリーミングにおいてマルチメディア・コンテンツ（例えば、動画）を再生するためには、クライアント端末Ｃは、先ず、必要なマルチメディア・コンテンツについての、ビット・レートおよび解像度に関する利用可能なリプリゼンテーションを含むリストのマニフェストを取得する必要がある。このマニフェストは、予め生成されて、ＨＴＴＰサーバＳに記憶されている。

本発明によれば、ゲートウェイＧＷは、１つ以上のＨＴＴＰサーバＳがマルチメディア・コンテンツのクライアント要求に応じて送信したマニフェストを適応化できる。

この目的のために、ゲートウェイＧＷは更に以下の要素を含む。
−ゲートウェイＧＷで受信したストリームを解析するように構成されたインターセプション・モジュール１３：インターセプション・モジュール１３は、クライアント端末ＣがＨＴＴＰサーバＳ宛のサービス要求を送出する度に、そのサービス要求を識別して、ＨＴＴＰサーバＳからクライアント端末Ｃに応答として返信されるマニフェストをインターセプトすることによってサービス情報を収集する。インターセプション・モジュール１３は、マニフェストをインターセプトして解析する。マニフェストを解析することによって、特に、例えばサーバによって通知されるビット・レートおよび関連付けられたセグメントのＵＲＬのような情報を抽出できる。インターセプション・モジュール１３は、マニフェストをインターセプトするために、利用可能なストリーミング技術および関連付けられたプロトコルを認識している。インターセプション・モジュール１３は、各々のプロトコルについて、マニフェストを伝送するパケットのタイプを知っている。特に、インターセプション・モジュール１３は、例えば、アップルＨＴＴＰライブ・ストリーミング、マイクロソフト・スムーズ・ストリーミング）、およびアドビ・オープン・ソース・メディア・フレームワークの技術を認識している。もちろん、インターセプション・モジュール１３は、他のストリーミング技術を認識するように構成可能である。
−クライアント端末ＣとＨＴＴＰサーバＳとの間の経路（例えば、アクセス・リンクまたはホームＷｉＦｉアクセス・ポイントとしてボトルネックとなり得るネットワーク・セグメント）の達成可能なデータ・レートを推定するように構成された推定モジュール１４：例えば、クライアント端末ＣがＷｉＦｉを介して接続されている場合には、達成可能なデータ・レートは、物理的伝送パラメータを推定することによって取得でき、例えば、生のデータ・レートを半減して達成可能なＴＣＰスループットを取得することによって取得できる。その代替例として、クライアント端末ＣがどのようなＷｉＦｉ変調で動作されるかを特定してそのＷｉＦｉ変調からゲートウェイＧＷとクライアント端末Ｃとの間で利用可能な帯域幅を特定することもできる。別の一変形例では、ＡＤＳＬプロトコルについて、アクセス・リンクの特徴に従って、使用されるサブキャリヤの数を求める。使用されていないサブキャリヤを取り除く。アクセス・リンクのデータ・レートの算定は、効率的なサブキャリヤから近似的に得ることができる。ＡＤＳＬ同期化ビット・レートを用いて、アクセス・リンク上で達成可能なスループットを推測できる。更に別の一実施形態において、達成可能なデータ・レートの推定は、別のネットワーク設備ＥＰ（例えば、ブロードバンド・アクセス・サーバ、最初のインターネット・サービス・プロバイダのルータなど）によって提供されるデータに基づいて行われる。更にまた別の一実施形態において、達成可能なデータ・レートの推定は、ＯｐｅｎＦｌｏｗコントローラによって［ＯｐｅｎＦｌｏｗシグナリングの形態で］提供される。上記別のネットワーク設備によって提供されるデータが既にその経路の達成可能なデータ・レートに対応している場合、推定モジュール１４は、演算をさらに行うことなく、そのデータを、そのようなものとして、配信してもよい。
−インターセプトされたマニフェストの複数のリプリゼンテーションを含むリストの中から、推定された達成可能なデータ・レートに等しいか、またはそれよりも低い関連付けられたビット・レートを有するそのリストの最初のリプリゼンテーションを選択するように構成された選択モジュール１５：換言すれば、インターセプトされたマニフェストの選択されたリプリゼンテーションは、関連付けられたビット・レートが、推定された達成可能なデータ・レートに最も近く、かつ、それよりも低い（または、それに等しい）リプリゼンテーションである。
−インターセプトされたマニフェストを必要ならば修正して、修正したマニフェスト（適応化されたマニフェストとも称する。）をクライアント端末Ｃに配信するように構成された適応化モジュール１６：特に、適応化されたマニフェストにおいて、選択モジュール１５によって選択されたリプリゼンテーションが推奨される（例えば、強調される）。これとは別に、マニフェストに含まれているその他の全ての情報は変更されないことが好ましい。特に、任意のフィルタリング、広告の挿入、または他の任意のマニフェスト修正技術との互換性を持たせるために、元のマニフェストに記述された全てのリプリゼンテーションは、適応化されたマニフェストに記述されていることが好ましい。

本発明によれば、選択されたリプリゼンテーションを推奨するための様々な手法を実施でき、この手法は、使用されるストリーミング技術（Ａｐｐｌｅ ＨＬＳ、Ｍｉｃｒｏｓｏｆｔ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ、ＤＡＳＨなど）に応じて決まることがある。

第１の手法は、選択されたリプリゼンテーションを推奨するために、選択されたリプリゼンテーションに注釈を付けることを含む。この注釈付けは、例えば、選択されたリプリゼンテーションに特定のタグを付加することである。この第１の手法は、ＤＡＳＨプロトコルの場合に特に有効であることがあり、その理由は、マニフェストが、そのような付加的な注釈付けが可能なＸＭＬファイルであるからである。この場合、リストされた全リプリゼンテーションの順序は変更されなくてもよく、選択し推奨されたリプリゼンテーションのみにタグが付けられる。

適応化されたマニフェストにおいて、選択されたリプリゼンテーションを推奨する別の手法では、リストに含まれるリプリゼンテーションの順序を変更するか、あるいは、少なくともその一部の順序を変更して、その選択されて推奨されたリプリゼンテーションをリストの先頭に配置してもよい。実際、本出願人は、ストリーミング・コンテンツの現行の再生機器が、通常、マニフェスト内にリストされた最初のリプリゼンテーションを選択することを観察して、もし選択されたリプリゼンテーションが最初の位置に配置されているならば、再生機器はそれを最初に選択するという結論に至った。

更に、図４に示されたフローチャートには、本発明の好ましい実施形態に従って、サーバＳによって送信され、クライアント端末Ｃが要求したマルチメディア・コンテンツに関連付けられたマニフェストを適応化する方法のステップが説明されている。

特に、事前ステップＥ０では、ゲートウェイＧＷは、サーバＳによって送信され、クライアント端末Ｃが要求しているマルチメディア・コンテンツに関連付けられたマニフェストをインターセプトする。

次のステップＥ１では、ゲートウェイＧＷは、クライアント端末ＣとサーバＳとの間の経路の少なくとも一部分の達成可能なデータ・レートを推定する。

更に次のステップＥ２では、ゲートウェイＧＷは、上記インターセプトされたマニフェストのリストされたリプリゼンテーションの中から、推定された達成可能なデータ・レートに等しいか、またはそれよりも低い関連付けられたビット・レートを有する最初のリプリゼンテーションを選択する。この選択されたリプリゼンテーションは、推奨リプリゼンテーションとも称する。

更に次のステップＥ３では、ゲートウェイＧＷは、適応化されたマニフェストをクライアント端末Ｃに配信する。このマニフェストでは、選択されたリプリゼンテーションが、上述した手法に従って推奨されている。

本発明によって、推奨リプリゼンテーションは、クライアント端末Ｃに転送される前に、適応化されたマニフェストにおいて推奨されている。その結果、クライアント端末Ｃが、開始時に最適なビット・レートに関連付けられたリプリゼンテーションを要求することが見込まれる。最初にダウンロードされるチャンクは、この推奨リプリゼンテーションから選ばれる。この推奨リプリゼンテーションのビット・レートが、推定された達成可能なデータ・レートに近い場合、クライアントが最適なビット・レートで開始することが見込まれる。このストリーミング・セッションの開始時点でのエンドユーザの第一印象は、現行の技術に比べて向上する。

もちろん、適応化されたマニフェストは、サーバＳによって提案された他の全てのリプリゼンテーションが含まれているので、端末クライアントＣは、その後、新たな最適なビット・レートにそれ自体で収束できる。

本発明は、上述したように、中継装置（プロキシ装置とも称する。）において、例えば、インターネット・ゲートウェイ、ＷｉＦｉホットスポット、フェムトセル、あるいは、利用可能なスループットをモニタでき、かつ、ＨＴＴＰストリーミング・マニフェストをインターセプトして修正できる任意の装置において実施できる。

当然、一変形例において、本発明は、マニフェストを変更するように構成された、装置またはクラウドに配置されたプロキシにより実施されてもよい。そのプロキシは物理的なネットワーク・リンクを制御する機器とは別で、その機器からスループット情報を入手できるプロキシにおいて本発明が実施されてもよい。これによって、より複雑なネットワーク構成を管理することができ、例えばいくつかのネットワーク・セグメントがボトルネックであり得る場合でも管理することができる。このプロキシは、種々のネットワーク・ノードから情報を入手して利用可能な最も低い帯域幅を特定でき、これが適切なリプリゼンテーションを選択する目標になる。例えばホーム・ネットワーク内では、ＡＤＳＬアクセス・リンクおよびホームＷｉＦｉアクセス・ポイントの両方が経路内に存在することがあり、共に変動し得る帯域幅の制限を受ける。

なお、本発明による複数のプロキシ装置をクライアント―サーバ構成の様々な位置に配置してもよく、例えば、ＤＳＬＡＭ内に１台のプロキシ装置を配置し、もう１台のプロキシ装置をゲートウェイ内に配置してもよい。実際、マニフェストは、加入者相互間のトラフィックを調整するために、ＤＳＬＡＭ内に配置された上記第１のプロキシ装置によって適応化されてもよい。次に、ホーム・ネットワークの帯域幅をより良く管理するために上記第２のプロキシ装置（この例ではゲートウェイ）によって、適応化されたマニフェストの別の適応化が実施されてもよい。

本発明の別の実施形態において、マニフェストは、その場その場で（例えば、ライブ・トランスコーディングにおいて）生成して同じ効果を得てもよい。そのような場合には、マニフェスト作成段階を修正して上述の方法を実施するか、あるいは、上述の発明をマニフェスト生成段階の後に適用する。

本明細書における詳細な説明、特許請求の範囲の請求項、および、図面において開示された内容は、互いに独立して、あるいは、任意に適切に組み合わせて、実施してもよい。開示された特徴は、適切であれば、ハードウェア、ソフトウェア、あるいは、両者の組み合わせにおいて実施してもよい。

特許請求の範囲の請求項内に示されている参照番号などは、単なる例示に過ぎず、請求項の範囲を限定する効果は有していない。

本発明は、この好ましい実施形態について説明したが、当業者の知識の範囲内で独創的な能力を行使せずに多数の修正と実施形態が可能である。したがって、本発明の範囲は、後述の特許請求の範囲の請求項の範囲によって定められる。

本願の特許請求の範囲の請求項において、規定された機能を実施する手段として表現された任意の構成要素は、例えば、ａ)上記機能を実施する回路素子の組み合わせ、または、ｂ)任意の形態のソフトウェアであって、ファームウェア、マイクロコードなどを含み、そのソフトウェアを実行して上記機能を実施する適切な回路と組み合わせられるソフトウェアを含む、上記機能を実施する任意の手法を包含することを意図している。特許請求の範囲の請求項によって規定される本原理は、特許請求の範囲の請求項に記載された種々の手段によって提供される機能が、特許請求の範囲の請求項に記載された態様で、組み合わせられて結合されるという事実に存する。それでそれらの機能を提供できる任意の手段がここに示された手段に相当すると考えられる。

Claims (10)

1. 少なくとも１つのサーバ（Ｓ）から受信し、クライアント端末（Ｃ）が要求したマルチメディア・コンテンツに関連付けられたマニフェストを適応化する装置であって、該マニフェストは該マルチメディア・コンテンツのリプリゼンテーションのリストを含み、
   −前記マニフェストをインターセプトするように構成されたモジュール（１３）と、
   −前記クライアント端末（Ｃ）と前記サーバ（Ｓ）との間の経路の少なくとも一部分の達成可能なデータ・レートを推定するように構成された推定器と、
   −前記インターセプトされたマニフェストのリプリゼンテーションのリストの少なくとも一部の中から、前記推定された達成可能なデータ・レートに等しいか、またはそれよりも低い関連付けられたビット・レートを有するリプリゼンテーションを選択するように構成されたモジュール（１５）と、
   −適応化されたマニフェストを前記クライアント端末（Ｃ）に配信するモジュール（１６）と、
   を備え、前記選択されたリプリゼンテーションが推奨されることを特徴とする、前記装置。
2. 前記クライアント端末（Ｃ）を含む少なくとも第１のネットワーク（Ｎ１）との第１のインタフェース（７）と、
   前記サーバ（Ｓ）を含む少なくとも第２のネットワーク（Ｎ２）との第２のインタフェース（８）と、
   を更に備える、請求項１に記載の装置。
3. 当該装置がプロキシ装置（ＧＷ）である、請求項１または２に記載の装置。
4. 前記選択されたリプリゼンテーションの推奨が、前記適応化されたマニフェストにおいて前記選択されたリプリゼンテーションに注釈を付けることによって行われる、請求項１〜３のうちいずれか一項に記載の装置。
5. 前記選択されたリプリゼンテーションの推奨が、前記適応化されたマニフェストにおいて前記選択されたリプリゼンテーションを前記リプリゼンテーションのリストの最初の位置に配置することによって行われる、請求項１〜３のうちいずれか一項に記載の装置。
6. 前記マニフェストが、ＨＴＴＰ適応的ストリーミング・プロトコルによってサポートされている、請求項１〜５のうちいずれか一項に記載の装置。
7. 少なくとも１つのサーバ（Ｓ）から受信し、クライアント端末（Ｃ）が要求したマルチメディア・コンテンツに関連付けられたマニフェストを適応化する方法であって、該マニフェストは該マルチメディア・コンテンツのリプリゼンテーションのリストを含み、
   −前記マニフェストをインターセプトすることと、
   −前記クライアント端末（Ｃ）と前記サーバ（Ｓ）との間の経路の少なくとも一部分の達成可能なデータ・レートを推定することと、
   −前記インターセプトされたマニフェストのリプリゼンテーションのリストの中から、前記推定された達成可能なデータ・レートに等しいか、またはそれよりも低い関連付けられたビット・レートを有するリプリゼンテーションを選択することと、
   −適応化されたマニフェストを前記クライアント端末（Ｃ）に配信することと、
   を含み、前記選択されたリプリゼンテーションが推奨されることを特徴とする、前記方法。
8. 前記選択されたリプリゼンテーションの推奨が、前記適応化されたマニフェストにおいて前記選択されたリプリゼンテーションに注釈を付けることによって行われる、請求項７に記載の方法。
9. 前記選択されたリプリゼンテーションの推奨が、前記適応化されたマニフェストにおいて前記選択されたリプリゼンテーションを前記リプリゼンテーションのリストの最初の位置に配置することによって行われる、請求項７または８に記載の方法。
10. 前記サーバ（Ｓ）が少なくとも１つのＨＴＴＰ適応的ストリーミング・プロトコルに準拠している、請求項７〜９のうちいずれか一項に記載の方法。

Images