JP6698553B2 - １つの要求メッセージに基づいたネットワーク・ノードへの多数のチャンクの要求 - Google Patents

Description

本発明は、１つの要求メッセージに基づいてネットワーク・ノードに多数のチャンクを要求することに関し、特に、１つの要求メッセージに基づいてネットワーク・ノードに多数のチャンクを要求する方法、１つの要求メッセージに基づいて多数のチャンクを要求するように構成された適応ストリーミング・クライアントを含むユーザ・デバイス、１つの要求メッセージに基づいて多数のチャンクをクライアントに配信するネットワーク・ノード、およびこのような方法を実現するためのコンピュータ・プログラム製品に関するものであるが、これらに限定されない。

従来技術

インターネット・ビデオおよびインターネットＴＶが増々普及するに連れて、変化するネットワーク条件の下で連続再生および最良のユーザ体験を可能にする適応型ストリーミング・ソリューションに対する要望が高まりつつある。適応型ストリーミングの概念は、ビデオ・ストリームによって要求される帯域幅を、ストリーミング・ソースとクライアントとの間にあるネットワーク経路上で利用可能な帯域幅に適応させる(adapt)という考えであり、ビデオ・ストリームのビット・レート（即ち、品質）を変化させることによって帯域幅を適応させる。

現在、多数のＨＴＴＰベース適応型ストリーミング（ＨＡＳ）プロトコルが開発されている。このようなプロトコルの例には、Ａｐｐｌｅ社のHTTP Live Streaming [http:// tools.ietf.org/html/draft-pantos-http-live-streaming-07]、Ｍｉｃｒｏｓｏｆｔ社の Smooth Streaming [http://www.iis.net/download/ SmoothStreaming]、Ａｄｏｂｅ社のHTTP Dynamic Streaming [http://www.adobe.com/products/httpdynamicstreaming]、3GPP-DASH [TS 26.247 Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP]（［ＴＳ ２６，２４７透過二端間パケット交換ストリーミング・サービス（ＰＳＳ）；ＨＴＴＰによる漸進ダウンロードおよび動的適応型ストリーミング］）等が含まれる。

独特な技術を中心とする市場を調和させる努力において、ＩＳＯは ISO/IEC 23009を作成した。これは、MPEG Dynamic Adaptive Streaming over HTTP (MPEG DASH)と呼ばれている。ＨＡＳソリューションでは、コンテンツ・ストリームは大抵の場合（時間的に、そしてときには空間的にも）「チャンク」に区分される。チャンクは、大きなファイルの一部として格納されるフラグメント(fragment)に関係することができ、またはセグメントに関係することができる（これによって、各セグメントは別個のファイルとして格納される）。チャンクは、任意の期間を有することができるが、大抵の場合期間は２秒（例えば、Ｍｉｃｒｏｓｏｆｔ社のSmooth Streaming）および１０秒（例えば、Ａｐｐｌｅ社のHTTP Live Streaming）の間であり、例えば、スケーラブル・ビデオ・コーディング（ＳＶＣ）のような適したコーディング方式を使用して、１つ以上の品質表現で利用することができる。チャンクに基づくストリーミング・コンテンツは、ストリーミング・クライアントが、現在のネットワークおよびデバイス条件（例えば、測定された帯域幅、利用可能なＣＰＵ、バッファ・サイズ）に基づいて、１つのチャンク要求から次の要求にシームレスにビデオの品質を適応させることを可能にする。

効率的にチャンクを大多数のストリーミング・クライアントに配信するために、通例コンテンツ配信ネットワーク（ＣＤＮ）が使用される。チャンクおよびそれらの異なる表現は、いわゆるマニフェスト・ファイルに記述される。マニフェスト・ファイルは、ストリームにおけるセグメントについての情報（セグメント識別子、位置、再生時間等）、およびストリーム内にある異なるセグメント間の時間関係を含むことができる。

ＭＰＥＧ ＤＡＳＨでは、マニフェスト・ファイルをメディア・プレゼンテーション記述（ＭＰＤ）とも呼び、チャンク識別子と、１つ以上のチャンク・ロケータ、例えば、チャンクを配信するように構成されたネットワーク・ノードを指し示すＵＲＬを含む。ストリーミング・セッションの開始時に、クライアントは最初に、１組の利用可能な品質表現、表現ビットレート、チャンク数、およびその位置を決定するためにマニフェスト・ファイルを要求する。その後、ＨＴＴＰ ＧＥＴ方法を使用して、チャンクを順次要求することができる。要求されるチャンクの品質表現は、クライアントのレート適応化アルゴリズムによって決定することができる。

現在、コンテンツの処理においてチャンク数は増々増加しつつある。その例には、スケーラブル・ビデオ・コーディング（ＳＶＣ）を使用してエンコードされ時間的にセグメント化されたコンテンツ、または空間的にセグメント化された超高解像度コンテンツが含まれる。ＳＶＣベースのコンテンツは、一定の品質表現をデコードするには、同じチャンク識別子を有しそれよりも低い品質表現のチャンクも全て必要とするような方法でエンコードされる。したがって、品質表現Ｘを要求すると、その結果、時間的チャンク毎にＸ個のＨＴＴＰ ＧＥＴ要求が生ずる（デフォルトのＡＶＣベースのＨＡＳでは１つだけであるのと比較した場合。品質表現は独立してデコードすることができる）。空間的にセグメント化されたコンテンツでは、この問題は更に悪化する。それは、各時間的チャンクは多数の品質表現の多数の空間チャンクで構成される場合もあるからである。

これらの発展の結果、ＨＴＴＰ適応型ストリーミング（ＨＡＳ）を使用してチャンク型コンテンツを受信するために送る必要があるＨＴＴＰ ＧＥＴ要求の数が著しく増大した。ＨＡＳを使用して多数のこのようなＨＴＴＰ ＧＥＴ要求を送ることによってコンテンツを引き出すことにより、これらの要求の各々の送出と受信との間に発生する遅延のために、有効スループットの低下を招く。殆どのＨＴＴＰ適応型ストリーミング技法が動作する仕組みでは、次のチャンク要求は、直前の要求のチャンクが実際にクライアントによって受信された後でなければ送られないことになっている。要求の送出と要求されたチャンクの送信開始との間の期間に利用可能な帯域幅は、データをクライアントに送信するためには使用されず、したがって、ある時間期間にわたって測定されると、有効（または確認された）帯域幅を奪う(cut in on)ことになる。加えて、ＨＴＴＰ ＧＥＴ要求数の著しい増加は、これらの要求を処理する必要があるサーバおよび中間キャッシュにおいて、ＣＰＵ、メモリ、および帯域幅消費に関して多大なオーバーヘッド増大を招く。これは、それ自体において処理における更なる遅延を招き、更にＨＡＳを使用するときに達成可能なビットレート、および／または一定のインフラストラクチャを想定したときのＨＡＳベースのストリーミングのスケーラビリティにも影響を及ぼす可能性がある。

ＷＯ２０１２１２３７７３（Ａ１）は、サーバ・デバイス上に格納されているエンコード・メディア・ストリーム(encoded media stream)のフラグメント（部分）を要求するためのメディア・フラグメント要求を生成する方法を開示する。この方法は、クライアント・デバイスによって実現され、既に受信されクライアント・デバイス上に格納されたメディア・ストリームのフラグメント（部分）を表す構造を格納する。この構造は、既に受信されたフラグメントに関連付けられた第１および第２タイプのアドレシング情報を含む。メディア・フラグメント要求を生成する方法は、メディア・ストリームの新たなフラグメントに対応する欠落メディア・データを得るためにメディア・フラグメント要求を形成するステップを含む。メディア・フラグメント要求は、少なくとも１つの第１タイプのアドレシング情報、および少なくとも１つの第２タイプのアドレシング情報を指定する。第１タイプのアドレシング情報は、空間または時間情報であり、第２タイプのアドレシング情報は、メディア・ストリーム内部におけるバイト位置情報である。ＷＯ２０１２１２３７７３（Ａ１）による方法は、ＭＦ ＵＲＩ １．０仕様書のコンテキストで説明される。この仕様書は、通例ではビデオであり「メディア・フラグメント」とも呼ばれるマルチメディア部分を交換するためのプロトコルについて記載する。開示された方法の目的は、ＭＦ ＵＲＩ １．０仕様書の問題を解決することであり、ＷＯ２０１２１２３７７３（Ａ１）によれば、マルチメディア・ファイルから抽出されたマルチメディア部分（即ち、サブストリーム）は独立してデコード可能である必要があることを教示する。この要件を満たすために、抽出され配信されたマルチメディア部分は、いわゆる時間予測を使用するＨ．２６４またはＭＰＥＧ−４のようなビデオ圧縮フォーマットでエンコードされ、要求された部分よりも大きくなる場合がある。要求された部分は、通例、コンテンツに対する一般的な参照と組み合わせて、時間間隔によって指定される。ＷＯ２０１２１２３７７３（Ａ１）によれば、以上の要件は、したがって、要求間でメディア引き出しにおいて接続時間間隔の重複を生ずるおそれがあり、更にあるマルチメディア（ビデオ）部分を２回引き出すことに至るおそれがある。以上で開示した方法は、要求されることになるファイルのマルチメディア部分(the to be requested multimedia portion)の内、これまでの要求に対する応答によって既に受信された部分を要求において指定することによって、この問題を解決することを目的とする。これを行うために、受信側デバイスは、応答内で提供されるバイト位置情報に基づいて、どの部分が既に受信されたか追跡する。 ＷＯ２０１１２１２３７７３（Ａ１）による方法は、ＨＴＴＰベースのメディア引き出しに対して包括的であり、具体的に要求することができる種々の品質のコンテンツの所定のチャンクの具体的な集合体を定めるマニフェスト・ファイルの使用というような、ＨＴＴＰ適応型ストリームの使用を開示することも、教示することも、示唆することもなく、本願において詳細に述べられるように、このようなコンテキストにおいて起こるおそれがある具体的な問題を仄めかすことも解決することもない。

これら先行技術の問題の１つに関し、コンテンツのあらゆるチャンクに一意の要求を送る必要性、および直前の要求に関連付けられたチャンクが受信されるまでの次の要求の待ち時間（有効帯域幅を奪う）は、ＨＴＴＰパイプライニングと呼ばれる既知の技法によって部分的に解決することができる。具体的には、パイプライニングは、レイテンシの問題を軽減または解消することを可能にすると考えられる。しかしながら、これは要求オーバーヘッドの問題には取り組まない。また、チャンク毎のパイプライニングでは、必要なオーバーヘッドを含む別個の要求が必要となることに代わりはない。適応型ストリーミングにパイプライニングを使用することによって、更に別の問題が生ずるおそれもある。パイプライニングの原理は、現在のチャンクを受信する前に、１つ以上の次のチャンクを送る要求を求める（出させる）ということである（例えば、これらの要求されることになるチャンクに先行するチャンク(chunk preceding these to be requested chunks)）。ＨＴＴＰ適応型ストリームの一部である、要求されたチャンクに対する品質選択の決定は、したがって、潜在的に古くなった情報を使用して行われる可能性がある。現在のチャンクが受信される速度によって影響を受けるパラメータ（例えば、バッファ・サイズの変化、要求元エンティティによって測定される有効スループット）は、１つ以上の後続のチャンクを要求するときに考慮されない。更に、パイプライニングは、これら後続の要求を取り消すことをサポートしない。つまり、ネットワーク条件がもはやチャンク化コンテンツ(chunked content)のある種の品質表現の引き出しをサポートしなくなっても、この品質表現を求める要求は既に作られているということがあり得る。これは、レンダリングされたチャンク化コンテンツの体験の品質にまさしく影響を及ぼすおそれがある。何故なら、要求されたチャンクは、レンダリングに「間に合う」には到達が遅すぎて、したがってレンダリングされたコンテンツにアーチファクト（画像のフリーズのような）を発生させるおそれがあるからである。

以上のことから、当技術分野には、ＨＡＳコンテンツ、そして具体的には、要求される必要がある膨大な数のチャンクで構成される複雑なコンテンツ（例えば、スケーラブルなビデオ、または空間的にセグメント化されたコンテンツ） に対する総合的な要求オーバーヘッドを軽減する方法およびシステムが求められているという結論になる。

当業者には認められようが、本発明の態様は、システム、方法、またはコンピュータ・プログラム製品として具体化することができる。したがって、本発明の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）、またはソフトウェアおよびハードウェアの態様を組み合わせた実施形態という形態をなすことができ、これらは全て本明細書では一般に「回路」、「モジュール」、「ノード」、「クライアント」、または「システム」と呼ぶこともできる。本開示において説明する機能は、コンピュータのマイクロプロセッサによって実行されるアルゴリズムとして実現することができる。更に、本発明の態様は、コンピュータ読み取り可能プログラム・コードが具体化されている、例えば、格納されている１つ以上のコンピュータ読み取り可能媒体（１つまたは複数）に具体化されたコンピュータ・プログラム製品の形態をなすこともできる。

１つ以上のコンピュータ読み取り可能媒体（１つまたは複数）の任意の組み合わせも利用することができる。コンピュータ読み取り可能媒体は、コンピュータ読み取り可能信号媒体またはコンピュータ読み取り可能記憶媒体であってもよい。コンピュータ読み取り可能記憶媒体は、例えば、電子、磁気、光、電磁、赤外線、または半導体システム、装置、あるいはデバイス、更には以上のもののあらゆる適した組み合わせであってもよいが、これらに限定されるのではない。コンピュータ読み取り可能記憶媒体の更に具体的な例（非網羅的な羅列）を挙げるとすれば、以下を含むであろう。即ち、１本以上のワイヤを有する電気接続、可搬型コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、消去可能プログラマブル・リード・オンリ・メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、可搬型コンパクト・ディスク・リード・オンリ・メモリ（ＣＤ−ＲＯＭ）、光記憶デバイス、磁気記憶デバイス、あるいは以上のもののあらゆる適した組み合わせである。本文書のコンテキストでは、コンピュータ読み取り可能記憶媒体は、命令実行システム、装置、またはデバイスによる使用のため、またはそれと関連した使用のためのプログラムを収容または格納することができる、任意の有形媒体とすればよい。

コンピュータ読み取り可能信号媒体は、例えば、ベースバンドにまたは搬送波の一部としてコンピュータ読み取り可能プログラム・コードが内部に具体化された伝搬データ信号を含むことができる。このような伝搬信号は、電磁、光、またはこれらのあらゆる適した組み合わせを含むがこれらに限定されない種々の形態の内任意の形態をなすことができる。コンピュータ読み取り可能信号媒体は、コンピュータ読み取り可能記憶媒体ではなく、命令実行システム、装置、またはデバイスによる使用、またはそれと関連した使用のためにプログラムを伝達、伝搬、または移送することができる任意のコンピュータ読み取り可能媒体とすることができる。

コンピュータ読み取り可能媒体上に具体化されたプログラム・コードは、任意の適した媒体を使用して送信することができる。任意の適した媒体には、ワイヤレス、ワイヤライン、光ファイバ、ケーブル、ＲＦ等、または以上のもののあらゆる適した組み合わせを含むが、これらに限定されるのではない。本発明の態様のために動作を実行するコンピュータ・プログラム・コードは、１つ以上のプログラミング言語の任意の組み合わせで書くことができる。プログラミング言語には、Ｊａｖａ（商標）、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のようなオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語のような従来の手続き型プログラミング言語が含まれる。プログラム・コードは、完全にユーザのコンピュータにおいて、部分的にユーザのコンピュータにおいて、単独のソフトウェア・パッケージとして、部分的にユーザのコンピュータにおいてそして部分的にリモート・コンピュータにおいて、あるいは完全にリモート・コンピュータまたはサーバにおいて実行することができる。後者のシナリオでは、リモート・コンピュータをユーザのコンピュータに任意のタイプのネットワークを通じて接続することができる。ネットワークには、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）が含まれ、または接続が外部コンピュータに対して行われてもよい（例えば、インターネット・サービス・プロバイダを使用してインターネットを通じて）。

本発明の態様について、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図および／またはブロック図を参照して以下に説明する。尚、フローチャート図および／またはブロック図の各ブロック、そしてフローチャート図および／またはブロック図におけるブロックの組み合わせをコンピュータ・プログラム命令によって実現できることが理解されよう。これらのコンピュータ・プログラム命令は、汎用コンピュータ、特殊目的コンピュータ、または他のプログラマブル・データ処理装置のプロセッサ、具体的には、マイクロプロセッサまたは中央処理ユニット（ＣＰＵ）に供給され、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイスのプロセッサによって命令が実行されて、フローチャートおよび／またはブロック図の１つまたは複数のブロックにおいて指定された機能／行為を実現する手段を形成する(create)ように、機械を生成することができる。

これらのコンピュータ・プログラム命令は、コンピュータ読み取り可能媒体に格納することもでき、コンピュータ読み取り可能媒体に格納された命令が、フローチャートおよび／またはブロック図の１つまたは複数のブロックにおいて指定された機能／行為を実現する命令を含む製品を生成するように、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイスに特定のやり方で機能するように指令することができる。

また、コンピュータ・プログラム命令は、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイス上にロードして、一連の動作ステップをコンピュータ、他のプログラマブル装置、またはデバイス上で実行させ、コンピュータまたは他のプログラマブル装置上で実行する命令が、フローチャートおよび／またはブロック図の１つまたは複数のブロックにおいて指定された機能／行為を実現するためのプロセスを設けるように、コンピュータ実装プロセスを生成することもできる。

図におけるフローチャートおよびブロック図は、本発明の種々の実施形態によるシステム、方法、およびコンピュータ・プログラム製品の可能な実施態様のアーキテクチャ、機能、および動作を例示する。これに関して、フローチャートまたはブロック図における各ブロックは、指定された論理機能（１つまたは複数）を実現するための１つ以上の実行可能命令を含む、モジュール、セグメント、またはコードの一部を表すことができる。また、ある代替実施態様では、ブロック内に記された機能が、図に記された順序以外で行われてもよいことも注記してしかるべきである。例えば、連続して示される２つのブロックが、実際には、実質的に同時に実行されてもよく、またはこれらのブロックが、関与する機能に応じて、逆の順序で実行されてもよいときもある。また、ブロック図および／またはフローチャート図の各ブロック、ならびにブロック図および／またはフローチャート図におけるブロックの組み合わせは、指定された機能または行為を実行する特殊目的ハードウェア・ベース・システム、あるいは特殊目的ハードウェアおよびコンピュータ命令の組み合わせによっても実現できることも注記しておく。

本発明の目的は、先行技術において知られている欠点の内少なくとも１つを軽減するまたは解消することである。一態様において、本発明は、１つの要求メッセージに基づいて、ストリーミング・クライアント、好ましくは、適応型ストリーミング・クライアントによって複数のチャンクを要求するコンピュータ実装方法に関するのでもよい。適応型ストリーミング・クライアントは、ＨＴＴＰまたはＨＴＴＰの異形(variant)を使用するストリーミングのコンテキストでは、一般にＨＴＴＰ適応型ストリーミング（ＨＡＳ）クライアントとして知られている。

本発明の実施形態では、要求メッセージは、好ましくは、ＨＴＴＰ１．１またはＨＴＴＰ２要求メッセージのような、ＨＴＴＰ（チャンク）要求メッセージである。ＨＴＴＰ２要求メッセージは、ＨＴＴＰ２ヘッダ・メッセージとすればよい。あるいは、要求メッセージは、しかしながら、ウェブソケット・ベースの要求メッセージであってもよい。ウェブソケット・メッセージは、１つ以上のウェブソケット・フレームとして送信される。本願全体において、（チャンク）要求メッセージを（ＨＴＴＰ）サブスクライブ・メッセージ(subscribe message)またはサブスクリプション要求メッセージ(subscription request message)とも呼ぶ。このようなメッセージの送出側は、このようなメッセージによって定められる複数のチャンク（セグメント）を供給されることに「サブスクライブ」する、または言い換えると「申し込む」(take a subscription)。

実施形態では、上記チャンクは、マニフェスト・ファイルに基づいて定められるとよい。マニフェスト・ファイルは、チャンク識別子によって定められたチャンクをクライアントに配信するように構成された少なくとも１つのノードを決定するためにチャンク識別子を含む。

実施形態では、上記方法は、少なくとも１つのプロセッサ、好ましくは、少なくとも１つのマイクロプロセッサを含んでもよく、クライアントにおいて、好ましくは、マニフェスト・ファイルに基づいて、第１複数のチャンクを要求するために、第１要求メッセージ、好ましくは、ＨＴＴＰ ＧＥＴメッセージまたはＨＴＴＰ ＨＥＡＤＥＲＳフレーム・メッセージまたはウェブソケット・ベースのメッセージの内１つを決定するコンピュータ読み取り可能プログラム・コードを実行し、第１要求メッセージは１つ以上の第１チャンク・テンプレート・パラメータを含む。要求されたチャンクは、好ましくは、セグメントである。セグメントとは、個々にファイルとして格納されたチャンクである。これは、チャンク化コンテンツ（即ち、コンテンツ項目に関連付けられたチャンクの集合体）を１つのよりも多い場所を通じて分散できるという重要な利点を有する。また、これは、ネットワークにおけるキャッシュも可能にし、コンテンツ全体を１つ以上の場所に格納することと比較して、一層効率的なコンテンツの配給を可能にする。あるいは、要求されたチャンクは、コンテンツ・ファイルの個々に引き出し可能な部分に関係するフラグメントであってもよい。更に、上記方法は、第１要求メッセージを第１ネットワーク・ノード、好ましくは、配信ノードまたはキャッシュに送るステップであって、第１ネットワーク・ノードが、１つ以上の第１チャンク・テンプレート・パラメータと、１つ以上のチャンク・テンプレート・パラメータ・フィールドを含む第１チャンク・テンプレートに基づいて、第１複数のチャンクに関連付けられた第１複数のチャンク識別子、好ましくは、第１複数のＵＲＬを決定するように構成される、ステップと、第１チャンク・テンプレートおよび１つ以上の第１チャンク・テンプレート・パラメータに基づいて決定されたチャンク識別子の内の１つに関連付けられた１つのチャンクを含む、少なくとも１つの応答メッセージ、好ましくは、ＨＴＴＰ ＯＫメッセージまたはＨＴＴＰ ＤＡＴＡフレーム・メッセージのようなＨＴＴＰ応答メッセージ、あるいはウェブソケット（ベースの）応答メッセージを受信するステップとを含む。第１要求メッセージがウェブソケット（ベースの）メッセージである場合、少なくとも１つの応答メッセージも、ウェブソケット（ベースの）応答メッセージであることが好ましい。第１要求メッセージがＨＴＴＰ１．１メッセージである場合、応答メッセージもＨＴＴＰ１．１メッセージであることが好ましい。

第１要求メッセージがＨＴＴＰ２メッセージ、好ましくは、ＨＴＴＰ ＨＥＡＤＥＲＳフレーム・メッセージである場合、応答メッセージもＨＴＴＰ２メッセージ（通例、ＨＴＴＰ ＤＡＴＡフレーム・メッセージ）であることが好ましい。本発明による実施形態における全ての要求−応答メッセージに対する好ましい動作モードも同じである。

実施形態では、第１チャンク・テンプレートは、ＵＲＬチャンク・テンプレート、即ち、ＵＲＬのシンタックスを決定する慣例に従うテンプレートでもよい。ＵＲＬチャンク・テンプレートは、ＵＲＬテンプレートとしても知られている。これら２つの用語は、本願全体にわたって相互交換可能に使用される。

本発明は、クライアントが、好ましくは複数の（空間的、時間的、および／または品質関連）チャンクを含む所定の集合体を提供することを（配信ノードに）要求するために、１つの要求メッセージ、好ましくは、ＨＴＴＰまたはウェブソケット・ベースの（チャンク）要求メッセージを送ることを可能にする。このようにして、多数のストリーミング・クライアントに対処し、各々が多くの異なる品質表現および／または小さなチャンク・サイズを有するかもしれないチャンク化コンテンツを要求するときに存在するおそれがある、要求メッセージの大きなオーバーヘッドに伴う問題を解消する、または少なくとも大幅に低減することができる。オーバーヘッドの低減を可能にする１つの要求メッセージを、サブスクライブ・メッセージ（サブスクリプション）と呼ぶこともできる。本願全体にわたって、このサブスクライブ・メッセージはＨＴＴＰサブスクライブ・メッセージ（例えば、ＨＴＴＰ１．１およびＨＴＴＰ２実施態様に対して。今後の次世代ＨＴＴＰ実施態様を除外しない。）、あるいはウェブソケット・サブスクリプションまたはウェブソケット・サブスクライブ・メッセージとも呼ぶ。ウェブソケット・サブスクライブ・メッセージは、ウェブソケットを使用して送信される（送られる）サブスクライブ・メッセージである。

本発明は、（適応型）ストリーミング・クライアントに利用可能な（有効）帯域幅を増大させる。これによって、ストリーミング・クライアントが、本発明を使用せずに可能であるよりも高いレベルでストリーミングの品質を維持することが可能になると考えられ、および／またはストリーミング・クライアントが、帯域幅を考慮して低い方の品質ビデオ・ストリーミングに切り替える回数を減らすことができる。本発明は、特に、ＭＰＥＧ−ＤＡＳＨのような適応型ストリーミング技術に基づいてテレビジョン・サービスを提供するために使用することができる（テレビジョン）運営業者によって管理されるネットワークのような、安定したネットワーク環境において使用されるのに適している。「安定」という用語は、好ましくは、クライアント（デバイス）において確認または測定される帯域幅の変動に言及する。ネットワーク（例えば、ストリーミング）環境が安定である程、これらのパラメータに存在する変動は少なくなる。

（ＨＴＴＰまたはウェブソケット）サブスクライブ・メッセージによる要求オーバーヘッドの低減は、（ＨＴＴＰまたはウェブソケット）サブスクライブ・メッセージにおいてチャンク・テンプレート・パラメータをネットワークに送ることによって達成することができる。チャンク・テンプレート・パラメータは、チャンク・テンプレートに基づいて１組のチャンク識別子および／またはＵＲＬを生成するために、ネットワーク・ノードによって使用することができる。ＵＲＬは、一般に、チャンク識別子およびチャンク・ロケータを含む。チャンク・テンプレートは、チャンク・テンプレート・パラメータに基づいて指定することができるチャンク・パラメータ・フィールド（例えば、置き換えられる）を含むことができる。このように、大きな１組のＨＴＴＰ要求メッセージ、好ましくは、ＨＴＴＰセグメント要求メッセージを、１つのチャンク・テンプレートおよびいくつかのチャンク・テンプレート・パラメータに基づいて効率的に生成することができる。

実施形態では、第１（ＨＴＴＰまたはウェブソケット）要求メッセージ（即ち、サブスクライブ・メッセージ）が第１チャンク・テンプレートを含んでもよい。このように、複数のＨＴＴＰ要求メッセージおよび／またはチャンク識別子を生成するために必要とされる情報が効率的に、１つのメッセージにおいてネットワーク・ノードに送られる。

実施形態では、上記ネットワーク・ノードは、第１チャンク・テンプレートおよび１つ以上の第１チャンク・テンプレート・パラメータに基づいて第１複数のチャンクの少なくとも一部に関連付けられた１組の（ＨＴＴＰまたはウェブソケット）（単独）チャンク要求メッセージを生成またはエミュレートし、（ＨＴＴＰまたはウェブソケット）（単独）チャンク要求メッセージの内少なくとも１つに対して、チャンクを含む（ＨＴＴＰまたはウェブソケット）応答メッセージをクライアントに送るように構成されてもよい。実施形態では、所定の１組の（ＨＴＴＰまたはウェブソケット）応答メッセージが、所定の１組の（ＨＴＴＰまたはウェブソケット）チャンク要求メッセージに応答して、クライアントに送られてもよい。したがって、１組の（ＨＴＴＰまたはウェブソケット）チャンク要求は、ネットワークにおいて生成され、例えば、配信ノードまたはキャッシュにおける（ＨＴＴＰおよび／またはウェブソケット対応）サーバに、要求されたチャンク（の少なくとも一部）を含む１組の（ＨＴＴＰまたはウェブソケット）応答メッセージを生成するために供給されてもよい。

実施形態では、１組の（ＨＴＴＰまたはウェブソケット）応答メッセージは、所定のシーケンスでクライアントに送られてもよい。順序属性のような、チャンク・テンプレート・パラメータに関連付けられた情報（例えば、パラメータ）は、応答メッセージが所定の順序でクライアントに送られるように、（ＨＴＴＰまたはウェブソケット）チャンク要求メッセージを所定の順序で（所定のシーケンス）（ＨＴＴＰおよび／またはウェブソケット対応）サーバに供給することを、ネットワーク・ノードに命令することができる。

実施形態では、チャンク・テンプレート・パラメータが順序、範囲、および／または時間属性と関連付けられてもよい。時間属性は、当該チャンク・テンプレート・パラメータに対して異なる値を有する次のチャンクを送る前に配信ノードが待つ必要がある時間間隔を指定することができる。

実施形態では、第１（ＨＴＴＰまたはウェブソケット）要求メッセージ（即ち、サブスクライブ・メッセージ）を決定するステップが、マニフェスト・ファイルにおける１つ以上のチャンク識別子の少なくとも一部に基づいてチャンク・テンプレートおよび／またはチャンク・テンプレート・パラメータを決定するステップを含んでもよい。マニフェスト・ファイルは、通常、チャンク要求メッセージをネットワークに送るためにテンプレートおよび／または１組のチャンク識別子（通例、１組のＵＲＬまたは部分的なＵＲＬの形式で）を含む。この情報テンプレートおよび／またはチャンク識別子は、ストリーミング・クライアント、具体的には、ストリーミング・クライアントにおけるサブスクリプション生成モジュールによって、ＵＲＬテンプレートを生成するために使用されてもよい。ＵＲＬテンプレートは、ＵＲＬシンタックスに従い、サブスクライブ・メッセージの要求ＵＲＬの一部であってもよい。

実施形態では、チャンク・テンプレート・パラメータは、１つ以上のチャンク番号またはチャンク番号の範囲、１つ以上のチャンク・プレゼンテーション時間またはプレゼンテーション時間期間、１つ以上のチャンク品質表現またはチャンク品質表現範囲、１つ以上のチャンク・ビットレートまたはチャンク・ビットレート範囲、１つ以上のチャンク・サイズまたはチャンク・サイズの範囲の内少なくとも１つと関連付けられてもよい。したがって、チャンク・テンプレート・パラメータは、ある種および／または品質のチャンクに関連付けられたチャンク識別子を生成するために使用されてもよい。チャンク・テンプレート・パラメータ属性は、１つのチャンク・パラメータに対して一連の値または値の範囲を定めるために使用されるのでもよい。更に、チャンク・テンプレート・パラメータは、順序属性と関連付けられてもよく、順序属性は、ネットワーク・ノード、具体的には、ネットワーク・ノードにおけるサブスクリプション変換モジュールに、チャンク・テンプレートに基づいて所定のシーケンスでチャンク・テンプレート・パラメータを処理することを命令する。

実施形態では、第１（ＨＴＴＰまたはウェブソケット）要求メッセージ（即ち、サブスクライブ・メッセージ）の要求ＵＲＬが、チャンク・テンプレートと、第１配信ノードに関連付けられたリソース・ロケーション・パスとを含んでもよい。したがって、チャンク・テンプレートは、（ＨＴＴＰまたはウェブソケット）サブスクライブ・メッセージの要求ＵＲＬの一部であってもよい。

実施形態では、１つ以上の第１チャンク・テンプレート・パラメータの少なくとも一部が（ＨＴＴＰまたはウェブソケット）要求メッセージに追加されてもよい。他の実施形態では、１つ以上のチャンク・テンプレート・パラメータが、第１（ＨＴＴＰまたはウェブソケット）要求メッセージのヘッダに挿入されてもよく、要求ＵＲＬに挿入されてもよく、および／または要求にクエリ・ストリングとしてアペンドされてよい。したがって、これらのパラメータをネットワークに効率的に送るには、異なる方法が利用可能である。

実施形態では、第１（ＨＴＴＰまたはウェブソケット）要求メッセージを決定するステップは、更に、セッション識別子を第１（ＨＴＴＰまたはウェブソケット）要求メッセージに挿入するステップを含み、セッション識別子は、クライアントおよび／またはネットワーク・ノードが第１（ＨＴＴＰまたはウェブソケット）要求メッセージを１つ以上の他の（ＨＴＴＰまたはウェブソケット）要求メッセージおよび／または（ＨＴＴＰまたはウェブソケット）応答メッセージにリンクすることを可能にする。実施形態では、セッション識別子がトークンとして要求ＵＲＬに追加されてもよい。他の実施形態では、セッション識別子がクッキー値として第１（ＨＴＴＰまたはウェブソケット）要求メッセージのヘッダに追加されてもよい。したがって、セッション識別子は、ネットワーク・ノード、例えば、キャッシュが、１つのセッション／サブスクリプションに属する要求および応答メッセージ（例えば、１つのサブスクリプション要求メッセージに関連付けられた）を追跡することを可能にする。

本発明の実施形態では、要求メッセージがＨＴＴＰ２メッセージ（例えば、１つ以上のＨＥＡＤＥＲＳフレーム）である場合、セッション識別子はストリーム識別子であってもよい。

本発明の更に他の実施形態では、要求メッセージがウェブソケット・サブスクライブ・メッセージである場合、セッション識別子がサブスクリプションＩＤであってもよい。ウェブソケット・メッセージのコンテンツのフォーマットは自由であるので、セッション識別子の他の形式も可能である。

実施形態では、上記方法は、更に、第２（ＨＴＴＰまたはウェブソケット）要求メッセージ、好ましくは、ＨＴＴＰ ＧＥＴメッセージを決定するステップを含み、第２（ＨＴＴＰまたはウェブソケット）要求メッセージは、第２チャンク・テンプレートおよび１つ以上の第２チャンク・テンプレート・パラメータに基づいて第１ネットワーク・ノードによって決定された第２複数のチャンク識別子に基づいて、第１複数のチャンク識別子の少なくとも一部を更新することを第１ネットワーク・ノードに命令するように構成される。実施形態では、第２（ＨＴＴＰまたはウェブソケット）要求メッセージ（即ち、サブスクライブ・メッセージ）が、第２（ＨＴＴＰまたはウェブソケット）要求メッセージに基づいて第１（ＨＴＴＰまたはウェブソケット）要求メッセージを更新することを第１ネットワーク・ノードに命令する更新パラメータを含んでもよい。ＨＴＴＰ２の実施態様では、第２ＨＴＴＰ要求メッセージ（例えば、「更新」有り）がＨＴＴＰ２取り消しメッセージ（例えば、ＲＴＳ＿ＳＴＲＥＡＭフレーム）に先行されてもよい。

したがって、（ＨＴＴＰまたはウェブソケット）要求メッセージは、単に（ＨＴＴＰまたはウェブソケット）サブスクライブ更新メッセージを送ることによって更新することができる。更新された要求が受信された場合、直前の要求メッセージ（即ち、サブスクライブ・メッセージ）が置き換えられ、未だ送られることが予定されているあらゆるチャンクを自動的に欠落させる（即ち、最初のサブスクライブ・メッセージによって識別されたが未だ送信されていないチャンクの送信を取り消す）。これは、例えば、ＳＶＣベースのＨＡＳには有用である。何故なら、これは、クライアントが１つの要求で全ての品質レイヤを要求することを許すが、時間的チャンク(temporal chunk)の再生を開始しなければならない前に次の品質レイヤを受信する十分な時間が残されていないことに気付いた場合、その要求を更新することも許す。

パイプライニングのような（このような更新メカニズムを備えない）先行技術の方式とは対照的に、ＨＴＴＰ更新メッセージの使用により、利用可能な（即ち、有効）帯域幅の変化によるバッファ欠乏の危険性を大幅に低減することができる。ストリーミング・クライアントは、配信ノードが未だ以前の（ＨＴＴＰまたはウェブソケット）サブスクライブ・メッセージの応答メッセージをクライアントに送るプロセスにあるときに、もっと低い品質のチャンクに切り替えることを決定してもよい（例えば、利用可能な帯域幅の変化のため）。ＨＴＴＰ更新メッセージは、直前のサブスクライブ・メッセージに基づいて生成されたチャンク要求メッセージを取り消しまたは更新し、これらを所望の（もっと低い品質の）タイプの１つ以上のＨＴＴＰ要求メッセージと置き換えることもできる。

実施形態では、ネットワーク・ノードに（ＨＴＴＰまたはウェブソケット）要求メッセージ（即ち、サブスクライブ・メッセージ）を更新することを命令する更新パラメータが、前述のように、別の（ＨＴＴＰまたはウェブソケット）要求メッセージに、好ましくは、トークンまたはクッキーとして挿入される。あるいは、更新パラメータは（ＨＴＴＰまたはウェブソケット）要求メッセージにクエリ・ストリングとして挿入されてもよい。

本発明による実施形態では、第１ネットワーク・ノードが、第１ネットワーク・ノードによってクライアントに配信できない１つ以上のチャンクに関連付けられた少なくとも１つの（ＨＴＴＰまたはウェブソケット、即ち、ウェブソケット・ベースの）応答メッセージ、好ましくは、ＨＴＴＰリダイレクト・メッセージを生成するように構成され、（ＨＴＴＰまたはウェブソケット）応答メッセージが、第１ネットワーク・ノードによって配信できない１つ以上のチャンクを配信することができる第２ネットワーク・ノードに関連付けられたリソース・ロケーション・パスを含む。実施形態では、（ＨＴＴＰまたはウェブソケット）応答メッセージが、更に、第２ネットワーク・ノードに関連付けられたリダイレクトＵＲＬを含み、好ましくは、リダイレクトＵＲＬがチャンク・テンプレートと、第１ネットワーク・ノードによって配信できない１つ以上のチャンクを定める１つ以上の第２チャンク・テンプレート・パラメータとを含む。

したがって、要求されたチャンクの一部が第１配信ノードによって配信できない場合、これらのチャンクを代わりに配信することができる更に別の配信ノードを指し示すＵＲＬを含む１つ以上のリダイレクト・メッセージを生成することができる。

更に他の態様では、本発明は、１つの（ＨＴＴＰまたはウェブソケット）要求メッセージに基づいて複数のチャンクを少なくとも１つのクライアント、好ましくは、適応型ストリーミング・クライアントに配信するように構成されたネットワーク・ノードに関するのでもよい。上記ネットワーク・ノードは、コンピュータ読み取り可能プログラム・コードが具体化された少なくとも１つのコンピュータ読み取り可能記憶媒体と、コンピュータ読み取り可能記憶媒体に結合された少なくとも１つのプロセッサ、好ましくは、少なくとも１つのマイクロプロセッサとを含む。コンピュータ読み取り可能プログラム・コードの実行に応答して、少なくとも１つのプロセッサが、第１複数のチャンクのクライアントへの配信を要求する第１（ＨＴＴＰまたはウェブソケット）要求メッセージ、好ましくは、ＨＴＴＰ ＧＥＴメッセージを受信する動作であって、第１（ＨＴＴＰまたはウェブソケット）要求メッセージが１つ以上の第１チャンク・テンプレート・パラメータを含む、動作と、１つ以上の第１チャンク・テンプレート・パラメータと、１つ以上のチャンク・テンプレート・パラメータ・フィールドを含む第１チャンク・テンプレート、好ましくは、ＵＲＬチャンク・テンプレートとに基づいて、第１複数のチャンクに関連付けられた第１複数のチャンク識別子、好ましくは、第１複数のＵＲＬを決定する動作と、少なくとも１つの（ＨＴＴＰまたはウェブソケット）応答メッセージをクライアントに送る動作であって、応答メッセージが、第１チャンク・テンプレートおよび１つ以上の第1チャンク・テンプレート・パラメータに基づいて決定されたチャンク識別子の内１つに関連付けられたチャンクを含む、動作とを含む実行可能動作を実行するように構成される。

実施形態では、第１（ＨＴＴＰまたはウェブソケット）要求メッセージが第１チャンク・テンプレートを含んでもよい。

実施形態では、上記実行可能動作が、更に、第２（ＨＴＴＰまたはウェブソケット）要求メッセージ、好ましくは、ＨＴＴＰ ＧＥＴメッセージを受信する動作を含み、第２（ＨＴＴＰまたはウェブソケット）要求メッセージが、第２チャンク・テンプレートおよび１つ以上の第２チャンク・テンプレート・パラメータに基づいて第１ネットワーク・ノードによって決定された第２複数のチャンク識別子に基づいて、第１複数のチャンク識別子の少なくとも一部を更新することをネットワーク・ノードに命令するように構成され、好ましくは、第２（ＨＴＴＰまたはウェブソケット）要求メッセージが、第２（ＨＴＴＰまたはウェブソケット）要求メッセージに基づいて第１（ＨＴＴＰまたはウェブソケット）要求メッセージを更新するように、第１ネットワーク・ノードをトリガする更新パラメータを含む。

実施形態では、上記実行可能動作が、更に、第１（ＨＴＴＰまたはウェブソケット）要求メッセージに応答して、第１ネットワーク・ノードによってクライアントに配信できない１つ以上のチャンクに関連付けられた（ＨＴＴＰまたはウェブソケット）応答メッセージ、好ましくは、ＨＴＴＰリダイレクト・メッセージを生成する動作を含み、（ＨＴＴＰまたはウェブソケット）応答メッセージが、第１ネットワーク・ノードによって配信できない１つ以上のチャンクを配信することができる第２ネットワーク・ノードに関連付けられたリソース・ロケーション・パスを含む。

他の実施形態では、上記実行可能動作が、更に、第１（ＨＴＴＰまたはウェブソケット）要求メッセージに応答して、第１ネットワーク・ノードによってクライアントに配信できない１つ以上のチャンクに関連付けられた第２（ＨＴＴＰまたはウェブソケット）要求メッセージを生成する動作を含み、第２（ＨＴＴＰまたはウェブソケット）要求メッセージが、第１ネットワーク・ノードによって配信できない１つ以上のチャンクを配信することができる第２ネットワーク・ノードに関連付けられたリソース・ロケーション・パスを含む。実施形態では、第２（ＨＴＴＰまたはウェブソケット）要求メッセージが、要求ＵＲＬ、チャンク・テンプレート、および第１ネットワーク・ノードによって配信できない１つ以上のチャンクを定める１つ以上の第２チャンク・テンプレート・パラメータを含んでもよい。

更に他の態様では、ユーザ・デバイスは、１つの（ＨＴＴＰまたはウェブソケット）要求メッセージに基づいて複数のチャンクを要求するように構成されたクライアント、好ましくは、適応型ストリーミング・クライアントを含んでもよい。チャンクは、チャンク識別子を含み当該チャンク識別子によって定められたチャンクをクライアントに配信する少なくとも１つの配信ノードを決定するためのマニフェスト・ファイルに基づいて定められる。ユーザ・デバイスは、プログラムの少なくとも一部が具体化され、詳細ソフトウェア・プログラムを有するコンピュータ読み取り可能記憶媒体と、コンピュータ読み取り可能プログラム・コードが具体化されたコンピュータ読み取り可能記憶媒体と、コンピュータ読み取り可能記憶媒体に結合されたプロセッサ、好ましくは、マイクロプロセッサとを含む。コンピュータ読み取り可能プログラム・コードの実行に応答して、第１複数のチャンク、好ましくは、セグメントを要求するための第１（ＨＴＴＰまたはウェブソケット）要求メッセージ、好ましくは、ＨＴＴＰ ＧＥＴメッセージを決定する動作であって、第１（ＨＴＴＰまたはウェブソケット）要求メッセージが１つ以上の第１チャンク・テンプレート・パラメータを含む、動作と、第１（ＨＴＴＰまたはウェブソケット）要求メッセージを第１ネットワーク・ノード、好ましくは、配信ノードまたはキャッシュに送る動作であって、第１ネットワーク・ノードが、１つ以上の第１チャンク・テンプレート・パラメータと、１つ以上のチャンク・テンプレート・パラメータ・フィールドを含む第１チャンク・テンプレート、好ましくは、ＵＲＬチャンク・テンプレートとに基づいて、第１複数のチャンクに関連付けられた第１複数のチャンク識別子、好ましくは、第１複数のＵＲＬを決定するように構成される、動作と、第１チャンク・テンプレートおよび１つ以上の第１チャンク・テンプレート・パラメータに基づいて決定されたチャンク識別子の内の１つに関連付けられたチャンクを含む、少なくとも１つの（ＨＴＴＰまたはウェブソケット）応答メッセージを受信する動作と、または、第１ネットワーク・ノードによってクライアントに配信できない１つ以上のチャンクに関連付けられた少なくとも１つのＨＴＴＰリダイレクト・メッセージを受信する動作であって、ＨＴＴＰリダイレクト・メッセージが、第１ネットワーク・ノードによって配信できない１つ以上のチャンクを配信することができる第２ネットワーク・ノードに関連付けられたリソース・ロケーション・パスを含み、好ましくは、ＨＴＴＰリダイレクト・メッセージが、更に、第２ネットワーク・ノードに関連付けられたリダイレクトＵＲＬを含み、好ましくは、リダイレクトＵＲＬが、チャンク・テンプレートと、第１ネットワーク・ノードによって配信できない１つ以上のチャンクを定める１つ以上の第２チャンク・テンプレート・パラメータとを含む、動作とを含む実行可能動作を実行するように、プロセッサが構成される。

更に別の態様では、本発明は、ユーザ・デバイス、好ましくは、前述のようなユーザ・デバイスによる使用のためにマニフェスト・ファイルの少なくとも一部を格納する非一時的コンピュータ読み取り可能記憶媒体に関するのでもよい。ユーザ・デバイスは、１つの（ＨＴＴＰまたはウェブソケット）要求メッセージに基づいて複数のチャンク、好ましくは、セグメントを要求するように構成されたクライアント、好ましくは、適応型ストリーミング・クライアントを含むことができ、チャンクはマニフェスト・ファイルに基づいて定められる。マニフェスト・ファイルは、チャンク識別子によって定められたチャンクをクライアントに配信する少なくとも１つの配信ノードを決定するチャンク識別子と、少なくとも１つの配信ノードが、１つ以上の第１チャンク・テンプレート・パラメータおよび第１チャンク・テンプレートに基づいて第１複数のチャンクに関連付けられた第１複数のチャンク識別子、好ましくは、第１複数のＵＲＬを決定し、少なくとも１つの（ＨＴＴＰまたはウェブソケット）応答メッセージをクライアントに送るように構成されていることを示すサブスクリプション・サポート・パラメータ、好ましくは、フラグとを含み、応答メッセージが、第１チャンク・テンプレートおよび１つ以上の第１チャンク・テンプレート・パラメータに基づいて決定されたチャンク識別子の内１つに関連付けられたチャンクを含む。

実施形態では、上記マニフェスト・ファイルが、更に、１つの（ＨＴＴＰまたはウェブソケット）要求メッセージの要求ＵＲＬのチャンク・テンプレートにおける１つ以上のチャンク・テンプレート・パラメータ・フィールドの少なくとも一部を、１つ以上のチャンク・テンプレート・パラメータの少なくとも一部と置き換えることをクライアントに命令するサブスクリプション・フォーマット・パラメータを含むことができる。

更に他の態様において、本発明は、１つの（ＨＴＴＰまたはウェブソケット）要求メッセージに基づいて、クライアント、好ましくは、適応型ストリーミング・クライアントによって複数のチャンクを要求するシステムに関するのでもよく、システムが、前述した実施形態の内任意のものを参照して説明したように、１つ以上のユーザ・デバイスと、少なくともネットワーク・ノードとを含む。

また、本発明は、コンピュータのメモリにおいて実行されると、前述のような方法ステップを実行するように構成されたソフトウェア・コード部分を含むプログラム製品にも関するのでもよい。更に、本発明について添付図面を参照しながら例示する。添付図面は、本発明による実施形態を模式的に示す。尚、本発明はこれらの具体的な実施形態には決して限定されないことは理解されよう。

図１は、本発明の実施形態にしたがって、チャンク化コンテンツをストリーミング・クライアントに供給するシステムを示す。 図２Ａは、本発明の実施形態にしたがって、１つのチャンク要求メッセージに基づいて、複数のチャンクをストリーミング・クライアントに配信する方法を示す。 図２Ｂは、本発明の実施形態にしたがって、１つのチャンク要求メッセージに基づいて、複数のチャンクをストリーミング・クライアントに配信する方法を示す。 図３Ａは、本発明の種々の実施形態にしたがってサブスクリプション要求メッセージを処理するように構成されたストリーミング・クライアントおよび関連する配信ノードの概要(schematics)を示す。 図３Ｂは、本発明の種々の実施形態にしたがってサブスクリプション要求メッセージを処理するように構成されたストリーミング・クライアントおよび関連する配信ノードの概要(schematics)を示す。 図４は、チャンク化コンテンツのストリーミングの間に生ずるオーバーヘッドを表す種々のグラフを示す。 図５は、本発明の他の実施形態にしたがって多数のチャンクを適応型ストリーミング・クライアントに配信する方法を模式的に示す。 図６は、本発明の更に別の実施形態にしたがって、多数のチャンクを適応型ストリーミング・クライアントに配信する方法を模式的に示す。 図７は、本発明の種々の実施形態にしたがって、サブスクリプション要求メッセージを処理するように構成された配信ノード（またはキャッシュ）の概要を示す。 図８は、本発明の更に他の実施形態にしたがって、１つのチャンク要求メッセージに基づいて多数のチャンクを適応型ストリーミング・クライアントに配信する方法を示す。 図９は、本発明の他の実施形態にしたがって、１つのチャンク要求メッセージに基づいて多数のチャンクを適応型ストリーミング・クライアントに配信する方法を示す。 図１０は、本発明の更に他の実施形態にしたがって、１つのチャンク要求メッセージに基づいて多数のチャンクを適応型ストリーミング・クライアントに配信する方法を示す。 図１１は、本発明の実施形態によるマニフェスト・ファイルおよび関連するＨＴＴＰサブスクライブ・メッセージを示す。 図１２は、本発明の他の実施形態によるマニフェスト・ファイルおよび関連するＨＴＴＰサブスクライブ・メッセージを示す。 図１３は、本開示におけるシステムおよび方法において使用することができるデータ処理システム例を示すブロック図である。 図１４は、本発明の更に他の実施形態にしたがって、１つのチャンク要求メッセージに基づいて多数のチャンクを適応型ストリーミング・クライアントに配信する方法を示す。 図１５は、本発明の更に他の実施形態にしたがって２つのチャンク要求メッセージに基づいて多数のチャンクを適応型ストリーミング・クライアントに配信する方法を示す。

図１は、本発明の実施形態にしたがって、チャンク要求メッセージに基づいて多数のチャンクを適応型ストリーミング・クライアントに配信するコンテンツ配信システムの少なくとも一部を示す。具体的には、図１は、コンテンツ配信システムの概要を示す。コンテンツ配信システムは、少なくとも１つのコンテンツ・サーバ１１６と、１つ以上の配信ノード１１２_１，２とを含む。これらは、１つ以上のネットワーク（例えば、コア・ネットワーク１０２およびアクセス・ネットワーク１０４）を通じてクライアント１０８_１，２に接続することができる。

配信ノードは、ＨＴＴＰ適応型ストリーミング（ＨＡＳ）プロトコルのような、適応型ストリーミング・プロトコルに基づいて、セグメント化されたコンテンツをクライアントに配信することができる。適応型ストリーミング・プロトコルの例には、Ａｐｐｌｅ社のHTTP Live Streaming [http://tools.ietf.org/html/draft-pantos-http-live-streaming-07]、Ｍｉｃｒｏｓｏｆｔ社の Smooth Streaming [http://www.iis.net/download/ SmoothStreaming]、Ａｄｏｂｅ社のHTTP Dynamic Streaming [http://www.adobe.com/products/httpdynamicstreaming]、3GPP-DASH [TS 26.247 Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP]、およびMPEG Dynamic Adaptive Streaming over HTTP [MPEG DASH ISO/IEC 23001-6] （［ＴＳ ２６，２４７透過二端間パケット交換ストリーミング・サービス（ＰＳＳ）；ＨＴＴＰによる漸進ダウンロードおよび動的適応型ストリーミング］）が含まれる。ＨＴＴＰは、チャンク化（セグメント化）ストリームをＨＡＳ対応クライアント（別名、ＨＡＳクライアント）に配信するための効率的でファイアウォール・フレンドリで、そしてスケーラブルな方式を可能にする。配信ノードは、チャンクに関連付けられたパケットを、ユニキャスト接続を介してクライアントに送信することができる。代わりにおよび／または加えて、ブロードキャスト（例えば、ＤＶＢ接続）、マルチキャスト、オーバーレイ・マルチキャスティング(overlay multicasting)、マルチメディア・ブロードキャスト、マルチキャスト接続を介してパケットをクライアントに送信することもできる。

ＨＡＳ対応クライアントは、ユーザ・デバイス内に実装することができ、一般に、電子タブレットのような（移動体）コンテンツ再生デバイス、スマート・フォン、ノートブック、メディア・プレーヤ、ホーム・ゲートウェイ、ＡＲめがね、またはＤＡＳＨ対応ＨｂｂＴＶディスプレイ・デバイスのようなＤＡＳＨ対応デバイスに関係することができる。あるいは、ユーザ・デバイスは、格納されているコンテンツにアクセスすることができるコンテンツ再生デバイスによる今後の消費のためにコンテンツを処理し一時的に格納するように構成されたセットトップ・ボックスまたはコンテンツ記憶デバイスであってもよい。

「クライアント」という用語が本願にわたって本発明を説明する目的で使用されるときはいつでも、以上のデバイスの内の１つ、あるいは、場合によって、そのようなハードウェアとして、またはハードウェアおよびソフトウェアの組み合わせとして以上のデバイスの内の１つに実装されるモジュールを等しく指すことができる。

コンテンツ・サーバ１１６は、クライアントによってアクセスまたは購入することができるビデオ・タイトルに関連付けられたマニフェスト・ファイルをホストすることができる。あるいは、ビデオ・タイトルがコンテンツ・プロバイダのウェブサイト等を通じて購入されるときに、ビデオ・タイトルに関連付けられたマニフェスト・ファイルを生成するようにコンテンツ・サーバを構成することもできる。配信ノード１１２_１，２は、マニフェスト・ファイルにおいて識別されるチャンクをホストすることができる。

図１のシステムでは、クライアントが、例えばウェブサイトを通じて、マニフェスト・ファイルをコンテンツ・サーバに要求することができる。クライアントが受信するマニフェスト・ファイルは、特定の配信ノード、例えば、第１配信ノード１１０_１に格納されているチャンクを指し示すチャンク識別子および位置情報（例えば、１つ以上のＵＲＬの形態）を含むことができる。マニフェスト・ファイルに基づいて、クライアントは、ＨＴＴＰ要求メッセージ、例えば、ＨＴＴＰ ＧＥＴメッセージに基づいてチャンクを要求し始めることができる。このメッセージは、１つ以上のルーティング・プロキシおよび／またはキャッシュ１０６を通じて、チャンク要求において識別されたチャンクをホストする配信ノードに送られてもよい。

先に説明したように、多数のクライアントへのＨＡＳコンテンツの配信のためにシステムによって処理される必要があるＨＴＴＰ ＧＥＴ要求の総数は、相当なものになる可能性がある。このように多くの要求の送出および処理は、ネットワークの有効スループットの低下を招くおそれがある。この低下は、このような要求の送出と受信との間に生ずる遅延の原因となるおそれがある。加えて、これは、これらの要求を処理する必要があるサーバおよび中間キャッシュにおいて、ＣＰＵ、メモリ、および帯域幅消費に関して、大きなオーバーヘッドが生ずる原因となる。

この問題を解消するまたは少なくとも大幅に軽減するために、クライアントはサブスクリプション生成モジュール（省略して、サブスクリプション・ジェネレータ）を含むことができる。これは、マニフェスト・ファイル内にある情報を使用して、１つ以上の所定の（ＨＴＴＰまたはウェブソケット・ベースの）要求メッセージを生成するように構成することができる。これら１つ以上の要求メッセージは、ネットワーク・ノード、例えば、配信ノード、キャッシュ、または他のネットワーク・エレメントにおけるサブスクリプション変換モジュール（省略して、サブスクリプション・トランスレータ）に、一連の単独チャンク要求メッセージを、例えば、ＨＴＴＰ ＧＥＴメッセージの形式で生成することを命令するように構成され、各チャンク要求メッセージは、クライアントがチャンク化コンテンツを再生するために必要とするチャンクに関連付けられる。これらの特殊要求メッセージ（例えば、一度に１つよりも多いチャンクを要求することができる）は、以後（好ましくは、ＨＴＴＰ）サブスクライブ・メッセージまたはサブスクリプション要求メッセージと称することもあり、ネットワーク・ノードにおいて、所定の一連のチャンク要求メッセージ（例えば、従来のＨＴＴＰ ＧＥＴメッセージ）を生成またはエミュレートすることができる。チャンク要求メッセージ毎に、配信ノードは対応するＨＴＴＰチャンク応答メッセージを生成することができ、この応答メッセージは、その本体の一部としてチャンクを含む。

以下で更に詳しく説明するが、ＨＴＴＰサブスクライブ・メッセージは、例えば、図１に示すようなコンテンツ配信システムによって送出および処理されるチャンク要求メッセージの量を大幅に減少させる。ＨＴＴＰサブスクライブ・メッセージの種々の有利なフォーマットおよび使用については、以下で更に詳しく説明する。

図２Ａは、本発明の実施形態にしたがって、１つのＨＴＴＰ要求メッセージに基づいて、複数のチャンクを要求しストリーミング・クライアントに配信する方法を示す。具体的には、図２は、１つのＨＴＴＰ ＧＥＴメッセージに基づいて、多数のチャンク（この場合、ＳＶＣチャンク）をストリーミング・クライアントに配信する方法を示す。（ＨＡＳ）ストリーミング・クライアントは、多数のチャンク（例えば、この特定例では、３つの品質レイヤに関連付けられたＳＶＣチャンク）の配信を要求するためのＨＴＴＰ ＧＥＴメッセージを生成するように構成されたサブスクリプション生成モジュールを含むことができる。

ユーザは、ストリーミング・クライアントを含むユーザ・デバイスをネットワーク、例えば、インターネットに接続し、ビデオ・タイトル・リンクを含むコンテンツ・プロバイダのウェブサイトをブラウズし、１つを選択することができる。リンク、例えば、ＵＲＬの選択時に、マニフェスト・ファイル（ＭＦ）をクライアントに送ることができる（ステップ２００）。ここで、マニフェスト・ファイルという用語は、一般に、ビデオ・タイトルまたはその一部を構成する(build)チャンクを識別するチャンク識別子（記述子）を含む特殊なデータ構造を指すことができる。チャンク識別子は、（１組の）ネットワーク・ノード（１つまたは複数）、例えば、メディア・サーバ（１つまたは複数）にアクセスするために使用することができる。メディア・サーバは、チャンク（例えば、セグメント）をクライアントに配信するように、またはどこでチャンクを引き出すことができるかという情報をクライアントに提供するように構成することができる。

サブスクリプション・ジェネレータは、マニフェスト・ファイルに基づいて所定のＨＴＴＰ要求メッセージを生成することができる（ステップ２０２）。図２Ｂは、チャンクを引き出すための１つ以上のチャンク識別子を含むマニフェスト・ファイル２３０の例を示す。チャンク識別子は、チャンク・テンプレート・パラメータ（例えば、この特定例では、＄Ｎｕｍｂｅｒ＄２３８および＄Ｂａｎｄｗｉｄｔｈ＄２４０）に関連付けられた１つ以上のチャンク・テンプレート・パラメータ・フィールド２３８、２４０を含むテンプレート２３６（図２Ｂでは、ＳｅｇｍｅｎｔＴｅｍｐｌａｔｅと呼ぶ）の形式で具体化することができる。更に、マニフェスト・ファイルは、１つ以上のドメイン名にそれぞれ関連付けられた１つ以上のベースＵＲＬ（ＢａｓｅＵＲＬ）２３２、２３４も含むことができる。ベースＵＲＬ（１つまたは複数）、チャンク・テンプレート、およびチャンク・テンプレート・パラメータを組み合わせることにより、どこでチャンクを引き出すことができるか判断するために、一連の具体的なＵＲＬを決定することができる。例えば、パラメータＮｕｍｂｅｒおよびＢａｎｄｗｉｄｔｈを設定することにより、次の一連のＵＲＬを生成することができる。
movie/movie_c234_1000kbps.mp4
movie/movie_c235_1000kbps.mp4
movie/movie_c236_1000kbps.mp4
movie/movie_c237_1000kbps.mp4
movie/movie_c238_1000kbps.mp4

他のチャンク・テンプレート・パラメータには、＄ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ＄（即ち、例えば、ＳＶＣアプリケーションにおけるチャンクの品質表現の識別子）、および＄Ｔｉｍｅ＄、即ち、チャンク化コンテンツのメディア・プレゼンテーション・タイムラインについての情報に基づいて決定することができるチャンクの開始時刻を含むことができる。

これらのＵＲＬは、チャンクを配信ノードに要求するためのＨＴＴＰ ＧＥＴメッセージを生成するために使用することができる。本発明による実施形態では、クライアントは、所定の一連のチャンクを配信ノードに要求するためのＨＴＴＰメッセージ（即ち、サブスクライブ・メッセージ）を生成するために、ベースＵＲＬ、チャンク・テンプレート、およびチャンク・テンプレート・パラメータを使用することができる。

好ましくは、ＨＴＴＰメッセージは、ＨＴＴＰ／１．１のような既知のＨＴＴＰ規格によってコンパイルするフォーマットを有する。例えば、ビデオの最初の２つのチャンクの３つの品質バージョンを要求するために、ＨＡＳクライアントにおけるサブスクリプション・ジェネレータは、マニフェスト・ファイルにおける情報に基づいて、ＨＴＴＰ要求メッセージを生成することができ、メッセージは、１つ以上のチャンク・テンプレート・パラメータおよびチャンク・テンプレートを含む要求ＵＲＬを含む。

以下で更に詳しく説明するが、チャンク・テンプレート・パラメータは、本発明の態様にしたがってＨＴＴＰＧＥＴメッセージ（即ち、サブスクライブ・メッセージ）を組み立てるために、チャンク・テンプレートにおいて一定のフィールドを指定するために使用することができる。実施形態では、ＨＴＴＰ ＧＥＴメッセージは次のフォーマットを有することができる。
HTTP GET/movie/movie_s{Number}_q{Bandwidth}.mp4 HTTP/1.1
Host: www.moviewebsite.com
Number: 2;234,235;2s
Bandwidth: 1;800,1000,1500;0s

この例では、ＨＴＴＰメッセージの要求ＵＲＬは、ドメイン名（この場合、http://www.moviewebsite.com/）を含むことができ、このドメイン名はマニフェスト・ファイルにおけるＢａｓｅＵＲＬから導き出すことができる。更に、要求ＵＲＬは、１つ以上のチャンク・テンプレート・パラメータ・フィールド（この場合、チャンク（シーケンス）番号フィールドおよび帯域幅パラメータ・フィールド）を含むチャンク・テンプレート（ＵＲＬチャンク・テンプレート）/movie/movie_s{Number}_q{Bandwidth}を含むことができ、これらのフィールドはマニフェスト・ファイルにおけるＳｅｇｍｅｎｔＴｅｍｐｌａｔｅエレメントから導き出すことができる。ここで、チャンク・テンプレート・パラメータ・フィールドは、ＵＲＬテンプレートの使用を示すために「中括弧」（｛．．．｝）によって識別することができる。各チャンク・テンプレート・パラメータ・フィールドは、この例ではＨＴＴＰヘッダにおいて定めることができる、ＮｕｍｂｅｒまたはＢａｎｄｗｉｄｔｈのような、チャンク・テンプレート・パラメータに基づいて指定することができる。

チャンク・テンプレート・パラメータは、セミコロンによって区切られた１つ以上のパラメータ属性を含むことができ、パラメータ属性は、サブスクリプション・トランスレータによって、クライアントによって要求された正しい一連のＵＲＬを生成するために使用される。

以上の例では、チャンク・テンプレート・パラメータは、順序、範囲、および／または時間属性と関連付けられてもよい。例えば、Ｎｕｍｂｅｒチャンク・テンプレート・パラメータは、Ｂａｎｄｗｉｄｔｈチャンク・テンプレート・パラメータの順序属性「１」よりも高い順序属性「２」と関連付け、サブスクリプション・ジェネレータが、Ｎｕｍｂｅｒチャンク・テンプレート・パラメータよりも前にＢａｎｄｗｉｄｔｈチャンク・テンプレート・パラメータを処理できるようにしてもよい。

したがって、配信ノードにおけるサブスクリプション・トランスレータがＨＴＴＰサブスクライブ・メッセージを解析しているとき、ヘッダのサブスクリプション・フィールドにおけるチャンク・テンプレート・パラメータの順序属性を解釈し、第１チャンク（第１チャンク識別子に関連付けられている）の３つのビットレート個別値(variant)が送られ、これに続いて第２チャンク（第２チャンク識別子に関連付けられている）の３つのビットレート個別値が送られる等と判定することができる。Ｎｕｍｂｅｒチャンク・テンプレート・パラメータがＢａｎｄｗｉｄｔｈチャンク・テンプレート・パラメータよりも低い順序の属性を有する場合、配信ノードは最初に第１ビットレートの全ての（例えば、３つ）チャンク（異なるチャンク識別子に関連付けられている）をクライアントに送り、次いで第２ビットレートの全てのチャンク（異なるチャンク識別子に関連付けられている）（以下続く）を送ることになる。

範囲属性は、関連するチャンク・テンプレート・パラメータが取ることができる値を指定することができ、これらの値は、その終点（例えば、「０〜１０」によって、リスト（例えば、「１、２、３」）、またはこれらの組み合わせ（例えば、「１、２、５〜１０」）によって決定することができる。時間属性（即ち、時間パラメータ）は、配信ノードが、そのチャンク・テンプレート・パラメータに対して異なる値を有する次のチャンクを送る前に待つ必要がある時間間隔を指定することができる。

クライアントがＨＴＴＰサブスクライブ・メッセージ（ＨＴＴＰ規格によってコンパイルする）を生成した後、クライアントは、配信ノードとの接続、例えば、ＴＣＰ／ＩＰ接続を確立することができる（ステップ２０４）。この接続は、ＩＰアドレスと、例えば、適したＤＮＳ方式を使用して要求ＵＲＬに基づいて決定されたポートとに基づいて確立することができる。ＴＣＰ／ＩＰ接続は、１つの接続（そのＩＰアドレスおよびポートによって識別される）を介して多数のＨＴＴＰ要求−応答メッセージの交換を可能にする永続的接続であることが可能である。ＨＴＴＰサブスクライブ・メッセージは、この接続を介して、要求ＵＲＬにおいて識別された配信ノードに送ることができる。

したがって、以上の例では、クライアントは、本発明にしたがって、第１チャンク識別子に関連付けられた異なるビットレートのチャンクを所定の順序でクライアントに配信し、そして後続のチャンク識別子に関連付けられた異なるビットレートのチャンクを配信する前に所定期間（この場合２秒）待つように、配信ノードに命令するために、ＨＴＴＰサブスクライブ・メッセージ、好ましくは、ＨＴＴＰ規格によってコンパイルする所定のＨＴＴＰ ＧＥＴメッセージを、配信ノードに送ることができる（ステップ２０６）。

尚、チャンク・テンプレート・パラメータ、ならびに関連する順序、範囲、および／または時間属性は単なる実施形態例であること、そして品質および／またはプレゼンテーション時間属性に関連付けられた他のチャンク・テンプレート・パラメータを有する実施形態も、１つ以上の配信ノードから所定の順序のチャンクを要求するために使用できることを申し添えておく。

ＨＴＴＰサブスクライブ・メッセージを生成するとき、クライアントは、このメッセージの配信ノードへの送信が、所定数のＨＴＴＰチャンク要求メッセージの所定のシーケンスでの配信ノードへの送信と同等であることを知る。したがって、ＨＴＴＰサブスクライブ・メッセージの送信後に、クライアントは、接続を開いたままにして、ＨＴＴＰサブスクライブ・メッセージに応答してサブスクリプション・トランスレータによって生成またはエミュレートされている要求の数に対応する数のＨＴＴＰ応答メッセージを受信するのを待機する（ステップ２０８）。実施形態では、クライアントは、ＨＴＴＰ応答メッセージがクライアントによって受信される（時間）順序に基づいて、それが受信した応答を（生成またはエミュレートされた）ＨＴＴＰチャンク要求メッセージ（ＨＴＴＰサブスクライブ・メッセージに関連付けられた）の１つにリンクする。例えば、実施形態では、クライアントは、サブスクライブ変換器によって生成された一連のＨＴＴＰチャンク要求メッセージにおける第１ＨＴＴＰチャンク要求メッセージを、サブスクリプション要求メッセージに応答してクライアントによって受信された第１応答メッセージと関連付けることができる。

したがって、先に説明したように、配信ノードにおけるサブスクリプション・トランスレータは、ＨＴＴＰサブスクライブ・メッセージを一連の、この場合６つのＨＴＴＰチャンク要求メッセージ（即ち、６つの「従来の」ＨＴＴＰ ＧＥＴメッセージ）に変換するために、チャンク要求テンプレート・パラメータを使用することができる（ステップ２１０）。
HTTP GET movie/movie_c234_q800.mp4;
HTTP GET movie/movie_c234_q1000.mp4;
HTTP GET movie/movie_c234_q1500.mp4;
HTTP GET movie/movie_c235_q800.mp4;
HTTP GET movie/movie_c235_q1000.mp4;
HTTP GET movie/movie_c235_q1500.mp4.

実施態様に応じて、サブスクリプション・トランスレータは、一連のＨＴＴＰ ＧＥＴメッセージをエミュレートするために使用される一連のＨＴＴＰ ＧＥＴメッセージ（上で列挙したような）または一連のＵＲＬを生成するために、チャンク・テンプレートおよびチャンク・テンプレート・パラメータを使用することもできる。Ｂａｎｄｗｉｄｔｈチャンク・テンプレート・パラメータの方がＮｕｍｂｅｒチャンク・テンプレート・パラメータよりも高い優先度が与えられたので、配信ノードは、各々１つのチャンクの異なるビットレート個別値を含む３つの応答を送ることができる（ステップ２１２，２１４，２１６）。次いで、Ｂａｎｄｗｉｄｔｈチャンク・テンプレート・パラメータに関連付けられた時間パラメータ（時間属性）に基づいて、配信ノードは、次の３つの応答を送る前に（ステップ２２０，２２２，２２４）、所定時間だけ（この場合、２秒）待つことができる（ステップ２１８）。

以上の方式は、時間的および空間的にセグメント化されたコンテンツ（「タイル」と称されることもある）を含む、異なるタイプのチャンク化コンテンツにも適用することができる。例えば、実施形態では、フレームが空間的に２×２タイルに分割された（座標（１，１），（１，２），（２，１），（２，２）に関連付けられる）セグメント化ビデオに対するＨＴＴＰサブスクライブ・メッセージは、次のフォーマットを有することができる。
HTTP GET movie/movie_c{Number}_q{Bandwidht}_x{XID}_y{YID}.mp4 HTTP/1.1
Host: www.deliverynode.com
Number: 4;234;2s
Bandwidth: 3;1000,1500;0s
XID: 2;1-2;0s
YID: 1;1-2;0s

ＮｕｍｂｅｒおよびＢａｎｄｗｉｄｔｈチャンク・テンプレート・パラメータの他に、ＨＴＴＰメッセージは、更に、要求されたタイル化ストリームのタイル座標を決定する２つのチャンク・テンプレート・パラメータＸＩＤおよびＹＩＤも含むことができる。

サブスクリプション・メッセージは、配信ノードにおける記述変換器によって解釈することができ、第１チャンク識別子（Ｎｕｍｂｅｒ）に対して、タイル（１，１），（１，２），（２，１），（２，２）を第１および第２ビットレート・バージョン（Ｂａｎｄｗｉｄｔｈ）で要求する必要があると判断する。したがって、このＨＴＴＰサブスクライブ・メッセージは、一連の８つのチャンク要求メッセージに変換（またはエミュレート）することができる。ＹＩＤチャンク・テンプレート・パラメータが最も高い優先度（優先度１）を有するので、最初に、第１ビットレート・バージョンのタイル（１，１）および（１，２）に関連付けられたチャンク要求メッセージが生成される。続いて、第１ビットレート・バージョンにおけるタイル（２，１）および（２，２）に関連付けられたチャンク要求メッセージが決定されるように、ＸＩＤが増加される（優先度２）。最後に、Ｂａｎｄｗｉｄｔｈパラメータが増加され（優先度３）、第２ビットレート・バージョンの４つのタイル全てが、第１ビットレート・バージョンに関して先に説明したのと同じ順序で生成される。
HTTP GET movie/movie c234_q1000_x1_y1.mp4
HTTP GET movie/movie c234_q 1000_x1 _y2.mp4
HTTP GET movie/movie c234_q 1000_x2_y1.mp4
HTTP GET movie/movie c234_q 1000_x2_y2.mp4
HTTP GET movie/movie c234_q1500_x1_y1.mp4
HTTP GET movie/movie c234_q 1500_x1_y2.mp4
HTTP GET movie/movie c234_q 1500_x2_y1.mp4
HTTP GET movie/movie c234_q 1500_x2_y2.mp4

このように、本発明によるサブスクリプション要求メッセージは、任意のタイプのセグメント化（チャンク）コンテンツに対してマニフェスト・ファイルに基づいて容易に決定することができ、一連の（空間的、時間的、および／または品質）チャンクの配信を配信ノードに要求するために、１つのＨＴＴＰ要求を使用すればよい。

尚、図２Ａおよび図２Ｂを参照して説明したＨＴＴＰサブスクライブ・メッセージは、単なる一例に過ぎず、以下では図１１および図１２を参照して他のメッセージ・フォーマットについて更に詳細に論ずることを申し添えておく。

図３Ａおよび図３Ｂは、本開示において説明するようなＨＴＴＰサブスクライブ・メッセージを処理するように構成されたストリーミング・クライアントおよび関連する配信ノードの概要を示す。図３Ａは、本発明の実施形態によるユーザ・デバイスを示す。ユーザ・デバイス３００は、クライアント３０２、好ましくは（ＨＴＴＰ適応型ストリーミング（ＨＡＳ）クライアントを含むことができる。クライアント３０２は、１つ以上のネットワーク・ノード、例えば、配信ノードまたはキャッシュのような（メディア）サーバと通信し、適応型ストリーミング・プロトコルに基づいてチャンク化コンテンツをストリーミングするように構成される。ユーザ・デバイスは、一般に、コンテンツ処理デバイス、例えば、電子タブレット、スマート・フォン、ノートブック、メディア・プレーヤ等のような（移動体）コンテンツ再生デバイスに関係付けることができる。ある実施形態では、ユーザ・デバイスが、コンテンツ再生デバイスによる今後の消費のためにコンテンツを処理し一時的に格納するように構成されたセットトップ・ボックスまたはコンテンツ記憶デバイスであってもよい。

図３Ａに示すように、マニフェスト・ファイル内にある情報をマニフェスト・キャッシュ３１０に格納し、特定のチャンクを配信ノードに要求しそして前述のようにＨＴＴＰサブスクライブ・メッセージを要求するための（従来の）ＨＴＴＰチャンク要求メッセージのような、ＨＴＴＰ要求メッセージを生成するために、クライアントによって解析することもできる。これらのメッセージは、クライアントによってＨＴＴＰインターフェースを介して配信ノードに送ることができる。ＨＴＴＰサブスクライブ・メッセージを形成するために、クライアントはサブスクリプション生成モジュール３１２を含むことができる。サブスクリプション生成モジュール３１２は、ＨＴＴＰサブスクライブ・メッセージを生成するために、マニフェスト・ファイルからの情報、例えば、チャンク・テンプレートおよびチャンク・テンプレート・パラメータを使用する。

更に、クライアントは、ＨＴＴＰサブスクライブ・メッセージに関連付けられた所定の一連のＨＴＴＰ応答メッセージ３０６を受信し、これらのチャンクをバッファ３１４に一時的に格納するように構成することができる。チャンクは、（チャンク）転送プロトコル（通例、これはＨＴＴＰであるが、ＲＴＳＰ／ＲＴＰ、ＦＴＰ、および他のプロトコルも使用することができる）を使用して引き出すことができる。ビデオ再生機能３１６（メディア・エンジンと呼ぶこともできる）は、情報、例えば、マニフェスト・ファイルにおけるセグメント・タイムライン情報に基づいて、バッファに格納されているチャンクを再生することができる。

チャンク引き出し機能は、再生が開始する前に所定数のチャンクがバッファにロードされるように、チャンクを引き出すように構成することができる。更に、再生の間、クライアントは、十分なチャンクがチャンク・バッファに格納されるように、マニフェスト・ファイルに基づいて、連続的にチャンクを引き出す。クライアントは、ユーザ・デバイスの（グラフィカル）ユーザ・インターフェース（図示せず）に接続されたユーザ・ナビゲーション機能３３０からチャンク引き出し命令を受け入れて処理することができる。このように、ユーザは、マニフェスト・ファイルによって定められる通りに、チャンク全体をナビゲートすることができる。

図３Ｂは、本発明の種々の実施形態にしたがってＨＴＴＰサブスクライブ・メッセージを処理する(handle)ように構成された配信ノードのようなネットワーク・ノードの概要を示す。配信ノード３２０は、ＨＴＴＰ要求および応答３２４，３２６，３２８を処理するための標準的なＨＴＴＰサーバ３２２を含むことができる。ＨＴＴＰサーバは、ＨＴＴＰサブスクライブ・メッセージ３３０を選別する(filter out)ように構成することができ、これらのメッセージはサブスクリプション変換モジュール３３２に転送される。変換コンポーネントは、図２を参照して詳しく説明したようなチャンク・テンプレートおよびチャンク・テンプレート・パラメータを使用して、ＨＴＴＰサブスクライブ・メッセージを所定の一例のＨＴＴＰチャンク要求３３４に変換(transform)する。

本発明の実施形態では、ＨＴＴＰ要求タイマ・モジュール３３８が、送出する必要がある要求の順序を追跡することができ、ある実施形態では、チャンク要求に回答（応答）しなければならない時間も追跡することができる。このために、ＨＴＴＰメッセージは、要求メッセージにおけるタイミング情報（例えば、タイム・スタンプ）と、ＨＴＴＰメッセージにおいてチャンク・テンプレート・パラメータに関連付けられた１つ以上の時間パラメータ(例えば、時間属性）とを含むことができる。実施形態では、ＨＴＴＰ要求タイマ・モジュール３３８は、時刻に基づいて（例えば、クロック信号によって供給される）、定時(timed)ＨＴＴＰチャンク要求をＨＴＴＰサーバに受け渡すように構成することができる。ＨＴＴＰチャンク要求に応答して、ＨＴＴＰサーバは、要求されたチャンクを含むＨＴＴＰ応答メッセージ３２４を生成することができ、このＨＴＴＰ応答メッセージ３２４を、１つ以上の時間属性（時間パラメータ）にしたがって、コンテンツ・データベース３３０に（一時的に）格納することができる。

更に注記すべきは、図３Ａおよび図３Ｂにおいて示された例は、ウェブソケット・ベースの要求−応答メカニズムにも等しく適用できるということである。次いで、ＨＴＴＰメッセージはウェブソケット・メッセージ（例えば、ウェブソケット・フォーマットに基づくメッセージ）と交換される。これらのメッセージのシンタックスの例については、本願において説明した。次いで、クライアントおよびサーバ双方は、チャンクを要求するおよび／または引き出すために使用される、ウェブソケット接続を設定する（例えば、アップグレードする）ように構成される。

図４は、従来のＨＴＴＰチャンク要求メッセージを使用したチャンク化コンテンツのストリーミングの間に生ずるオーバーヘッドを表す種々のグラフを示す。実生活の状況では、オーバーヘッドは計算するのが難しい。これは、使用される物理レイヤ（例えば、イーサネット）に左右されるからである。（ＯＳＩモデルの）物理レイヤに関連付けられたプロトコルが、色々な形で(different ways)オーバーヘッドを付加し、ＴＣＰストリームをフラグメント化する可能性がある（例えば、イーサネットは１８バイトのオーバーヘッドを付加し、ＴＣＰストリームを１５００バイトのデータ・パケットに分割する）。したがって、計算では、ＩＰ、ＴＣＰ、およびＨＴＴＰのオーバーヘッドしか考慮されなかった。

ＩＰおよびＴＣＰヘッダのオーバーヘッドは、各々、最少でも２０バイトである。ＨＴＴＰのオーバーヘッドは、実際のヘッダ・フィールドおよびＵＲＬの長さによって左右される。一例として、タイル化ストリーミング(tiled streaming)の例に対して以下の最小ＨＴＴＰ要求を使用する。
GET movie/movie_c001_q 1_x1_y1.mp4
Host: www.deliverynode.com
この要求のサイズは約６０バイトである。サブスクリプション要求はこれに似ている。
GETmovie/movie_c{Number}_q{RepresentationlD}_x{XID}_y{YID}.mp4
Host: www.deliverynode.com
Number: 4;001-010;2s
RepresentationID: 3;1-3;0s
XID: 2;1-4;0s
YID: 1;1-4;0s

この要求は、１３４バイトである。図４における２つのグラフは、ＳＶＣベースのタイル化ストリーミングのシナリオにおいて、従前からのＨＴＴＰ ＧＥＴ手法を使用する要求のサイズ（バイト単位）を、要求されたチャンクの数（Ｘ軸）および要求された品質レイヤ（曲線）の数の関数として示す。最初のグラフは、２×２タイルで構成されたビデオについての結果を示し、２番目のグラフは、４×４タイル化ビデオに対する結果を示す。

明らかに、要求の数、したがって要求されるバイトは、３つの変数全てと共に線形に増加する。例えば、２×２タイル化ビデオのために２０チャンクの３つの品質レイヤを要求すると、２３ＭＢが必要となり、一方４×４ビデオのために同じことを要求すると、既に９３ＭＢが必要となる。これらの数値を、要求する必要があるチャンクの総数およびネットワークにおけるクライアントの数と乗算すると、要求の数に関連して膨大な量のオーバーヘッドが生ずることになる。

対照的に、サブスクリプションの総バイト数は、この場合、要求される品質レイヤ、タイル、またはセグメントの数には関係なく、１７４（即ち、０．１６ＭＢ）となる。尚、この計算のために最小値が使用されたので、実生活状況におけるオーバーヘッドは遙かに多くなることを注記しておく。

図５は、本発明の他の実施形態にしたがって、１つのチャンク要求メッセージに基づいて多数のチャンクを適応型ストリーミング・クライアントに配信する方法を模式的に示す。具体的には、図５は、第１ＨＴＴＰサブスクライブ・メッセージの生成および配信ノードへの送信、ならびに配信ノードによるＨＴＴＰサブスクライブ・メッセージの処理の間におけるサブスクライブ要求のその後の更新を模式的に示す。このプロセスは、図２Ａのステップ２００〜２１４を参照して説明したのと同様に開始することができる。具体的には、ＨＡＳクライアントは、２つのチャンクの２つの異なる品質レイヤでの引き出しのために、ＨＴＴＰサブスクライブ・メッセージを配信ノードに送ることができる（ステップ５０２）。ＨＴＴＰサブスクライブ・メッセージは、配信ノードにおけるサブスクリプション・トランスレータによって一連の４つのＨＴＴＰチャンク要求メッセージに変換することができる（ステップ５０４）。その後、配信ノードは第１チャンクの２つの（ＳＶＣ）品質レイヤをクライアントに送ることができる（ステップ５０６および５０８）。

一方、第１チャンクの２つのＳＶＣ異形(SVC variant)を受信した後、クライアントはもはや第２品質レイヤには関心がない（例えば、利用可能な帯域幅がそれをサポートするには十分でないことに気がついたため）と判断することもあり得る。したがって、クライアントは、チャンク２および３のベース・レイヤのみを引き出すために、新たな第２ＨＴＴＰサブスクライブ・メッセージを永続的接続を介して送ることができる（ステップ５５０)。

配信ノードは、第２ＨＴＴＰサブスクライブ・メッセージが以前のＨＴＴＰサブスクライブ・メッセージと同じセッションに属することを確認することができ、そして第２ＨＴＴＰサブスクライブ・メッセージが、新たな要求よりはむしろ、第１ＨＴＴＰサブスクライブ・メッセージの更新に関係すると判断する。

配信ノードは、要求が更新であるか否か、様々な異なる方法で判定することができる。例えば、実施形態では、各ＨＴＴＰサブスクライブ・メッセージを一意の識別子によって識別することができ、第２ＨＴＴＰサブスクライブ・メッセージを同じ識別子を使用して送ることによって、第２ＨＴＴＰサブスクライブ・メッセージを更新メッセージとして解釈するように、配信ノードをトリガすることができる。他の実施形態では、「更新」と命名されたパラメータを要求ＵＲＬのクエリ−ストリングに追加することもできる。値が所定の値、例えば、「１」に設定された場合、要求はＨＴＴＰサブスクライブ更新メッセージになる。「更新」パラメータが「０」であると、またはクエリ−ストリングが存在しない場合、ＨＴＴＰサブスクライブ・メッセージは更新ではない。他の実施形態では、「更新」パラメータをＨＴＴＰメッセージのヘッダに挿入することもできる。

ＨＴＴＰメッセージがＨＴＴＰサブスクライブ更新メッセージである場合、配信ノードは、そのセッションのもっと前にある第１ＨＴＴＰサブスクライブ・メッセージに関連付けられた要求を削除することができる（ステップ５１２）。セッションの識別は、多数の方法で実施することもでき、トークンまたはクッキーに基づく方式が含まれる（このようなセッション識別方式の例について、以下で図８および図９を参照して更に詳しく説明する）。新たなＨＴＴＰサブスクライブ・メッセージは、配信ノードにおけるサブスクリプション・トランスレータによって、２つの新たなＨＴＴＰチャンク要求メッセージに変換することができる（ステップ５１４）。配信ノードにおけるＨＴＴＰサーバは、要求されたチャンクを含む２つのＨＴＴＰ応答メッセージをクライアントに送ることによって、これらのメッセージに応答することができる（ステップ５１６および５１８）。その結果、元の第１ＨＴＴＰサブスクライブ要求メッセージの一部として要求されたチャンク'movie_c2_q2'は、決してクライアントには送られず、したがって元の要求のこの部分は事実上取り消される。

更に他の実施形態では、ＨＴＴＰサブスクライブ・メッセージの代わりに、クライアントは以上で述べた同じメカニズムを使用して、要求を完全に取り消すことを決定することもできる。例えば、一実施形態では、クライアントは空のＨＴＴＰサブスクライブ・メッセージを永続的接続を介して配信ノードに送ることができ、配信ノードにおけるサブスクリプション・トランスレータは、このような空のＨＴＴＰサブスクライブ・メッセージを、それよりも前のＨＴＴＰサブスクライブ・メッセージの完全な取り消しとして解釈することができる。更に他の実施形態では、図５のプロセスにおいて、クライアントが、（第２）ＨＴＴＰチャンク要求メッセージを配信ノードに、それよりも前の第１ＨＴＴＰサブスクライブ・メッセージの後に送ることを決定することもできる。その場合、第１ＨＴＴＰサブスクライブ・メッセージに関連付けられたＨＴＴＰ要求は、１つのＨＴＴＰチャンク要求と置き換えることができる。

図６は、本発明の更に他の実施形態にしたがって、１つのチャンク要求メッセージに基づいて多数のチャンクを適応型ストリーミング・クライアントに配信する方法を示す。具体的には、図６は、１つのＨＴＴＰ ＧＥＴメッセージに基づいて、多数のチャンク（ＳＶＣチャンクのような）をストリーミング・クライアントに配信する方法を示す。この特定的な場合では、本発明によるサブスクリプション要求方式をサポートするＨＴＴＰプロキシ・キャッシュを、クライアントと配信ノードとの間の経路内に配置することができる。

このプロセスは、図２Ａおよび図２Ｂを参照して詳細に説明したのと同様にクライアントにおけるサブスクリプション・ジェネレータによって、マニフェスト・ファイルにおける情報に基づいて生成された第１ＨＴＴＰサブスクライブ・メッセージを使用して、多数のチャンク、例えば、チャンク識別子によって識別されたチャンクの２つの品質レイヤの配信を、クライアントが要求する（ステップ６０２）ことから開始することができる。
HTTP GET movie/movie_c{Number}_q{Bandwidth}.mp4
Host: www.deliverynode.com
Number: 2;1,2;2s
Bandwidth: 1;1,2;0s

クライアントとキャッシュとの間に第１（永続的）接続を確立することができ、この接続を介してＨＴＴＰサブスクライブ・メッセージをキャッシュに送ることができる。キャッシュのＨＴＴＰサーバは、メッセージを変換するため、そしてキャッシュが要求されたチャンクの内１つ以上を配信することができるか否かチェックするために、ＨＴＴＰサブスクライブ・メッセージをサブスクリプション・トランスレータに転送することができる。このために、要求されたチャンクがキャッシュのコンテンツ・データベースに格納されているか否かチェックすることができる。この特定例では、キャッシュは第１品質レイヤの２つのチャンクを格納してあると考えられ、したがって、キャッシュにおけるサブスクリプション・トランスレータは、キャッシュによる第１品質レイヤの第１および第２チャンクのストリーミング・クライアントへの配信のために、ＨＴＴＰサブスクライブ・メッセージを少なくとも２つの（ローカル）ＨＴＴＰチャンク要求メッセージに変換することができる。
HTTP GET movie/movie_c1_q1.mp4
HTTP GET movie/movie_c2_q1.mp4

要求されたチャンクの内残りについては、即ち、キャッシュに格納されていない第２品質レイヤのチャンクについては、キャッシュにおけるサブスクリプション・ジェネレータが、チャンクの残りをクライアントに配信することを配信ノード（元の（第１）ＨＴＴＰサブスクライブ・メッセージの宛先）に要求するために、更に別の第２ＨＴＴＰ要求メッセージを生成することができる（ステップ６０４）。
HTTP GET movie/movie_c[Number]_q[Bandwidth].mp4
Host: www.deliverynode.com
Number: 2; 1,2;0s
Bandwidth: 1;2;0s

したがって、この実施形態では、キャッシュは、第１ＨＴＴＰサブスクライブ・メッセージを（ローカル）ＨＴＴＰチャンク要求メッセージに変換し、更にキャッシュ内に存在しない１つ以上のチャンクのために第２ＨＴＴＰサブスクライブ・メッセージを生成するように構成される。この場合、キャッシュは配信ノードとの第２（永続的）接続を設定し、第２ＨＴＴＰサブスクライブ・メッセージを配信ノードに送ることができる。

キャッシュにおけるＨＴＴＰクライアントによって配信ノードに送られた後、第２ＨＴＴＰサブスクライブ・メッセージは、サブスクリプション・トランスレータ（配信ノード内にある）によって、第２品質レイヤの第１および第２チャンクのクライアントへの配信のために、２つの（ローカル）チャンク要求メッセージに変換することができる（ステップ６０６）。第２ＨＴＴＰサブスクライブ・メッセージに応答して、配信ノードは、要求されたチャンクを含む２つのＨＴＴＰ応答メッセージをキャッシュに返送することができ、キャッシュは、第１および第２ＨＴＴＰサブスクライブ・メッセージに関連付けられたＨＴＴＰ応答をクライアントに送ることができる。

クライアントによって要求される通りに応答のタイミングおよび順序に従うために、キャッシュにおけるＨＴＴＰ要求タイマ・モジュールは、それが配信ノードに送るＨＴＴＰサブスクライブ・メッセージ（１つまたは複数）およびそれがクライアントに送るＨＴＴＰチャンク要求のタイミングを管理することができる。ＨＴＴＰメッセージのタイミングは、要求された通りの順序で応答をクライアントに送る時刻が来るまでの、生成されたＨＴＴＰ応答の内部格納(local storage)を含むことができる。

図６による本発明の実施形態例では、キャッシュが第１ＨＴＴＰサブスクライブ・メッセージを処理し終えると直ちに、キャッシュは品質レイヤ１のチャンク１を含むＨＴＴＰ応答を既に送り始めることができる。更に、キャッシュは、それが配信ノードから受信したいずれのチャンクも、配信ノードからの後続のチャンクを待つ必要なく、転送することができる。言い換えると、図６の例では、キャッシュから発信するＨＴＴＰ応答、および配信ノードから発信するＨＴＴＰ応答を交互にinterleaved way)クライアントに送ることができる。

図７は、本発明の種々の実施形態にしたがってＨＴＴＰサブスクライブ・メッセージを処理するように構成されたキャッシュ７００の概要を示す。当業者は、図７のコンテキストにおいて言及されるチャンク（のタイプ）がセグメントであることが分かるであろう。何故なら、これらは、チャンクが１つのファイル内に多数格納される（例えば、収容される）フラグメントとは異なり、個々にファイルとして格納することができるからである。つまり、フラグメントは、一般に、キャッシュのような記憶装置(facilities)内に「単独で」格納することができず、これは配給の効率に影響を及ぼすおそれがある。実施形態では、図７におけるＨＴＴＰキャッシュ・サーバは、図６を参照して詳しく説明したように、ＨＴＴＰサブスクライブ・メッセージを処理するように構成することができる。図３Ｂにおける配信ノードと同様、キャッシュ７００は、ＨＴＴＰ要求および応答７０４、７０６、７０８を処理するために、標準的なＨＴＴＰサーバ７０２を含めばよい。ＨＴＴＰサーバは、ＨＴＴＰサブスクライブ・メッセージ７０８を選別するように構成することができ、次いで、メッセージ７０８はサブスクリプション変換モジュール７１０に転送される。

サブスクリプション・トランスレータは、ＨＴＴＰサブスクライブ・メッセージによってどのチャンクが要求されたか判定し、これらのチャンク（の少なくとも一部）がキャッシュのコンテンツ・データベース７１３に格納されているか否かチェックすることができる。チャンクの一部がキャッシュに格納されている場合、サブスクリプション・トランスレータは、最初の第１ＨＴＴＰサブスクライブ・メッセージを、コンテンツ・データベースに格納されているチャンクに関連付けられた所定の一連のＨＴＴＰチャンク要求７１２のに変換することができる。これらのＨＴＴＰ要求を生成するために、サブスクリプション・トランスレータは、図２を参照して詳しく説明したような、チャンク・テンプレートおよびチャンク・テンプレート・パラメータを使用することができる。

このように生成されたＨＴＴＰ要求は、ＨＴＴＰ要求タイマ・モジュール７１４に送ることができ、ＨＴＴＰ要求タイマ・モジュール７１４は、送出する必要がある要求の順序を追跡することができ、そしてある実施形態では、チャンク要求に回答しなければならない時刻も追跡することができる。実施形態では、ＨＴＴＰ要求タイマ・モジュール７１４は、時刻（例えば、クロック信号によって供給される）に基づいて、定時ＨＴＴＰチャンク要求７１６をＨＴＴＰサーバに受け渡すように構成することができる。ＨＴＴＰチャンク要求に応答して、ＨＴＴＰサーバは、要求されたチャンクを含むＨＴＴＰ応答メッセージ７０４を生成することができ、このＨＴＴＰ応答メッセージ７０４をコンテンツ・データベース７１３に格納することができる。

キャッシュのコンテンツ・データベースに格納されなかったチャンクに関して、サブスクリプション・トランスレータ７１０は、最初の第１ＨＴＴＰサブスクライブ・メッセージを第２（上流）ＨＴＴＰサブスクライブ・メッセージ７２４に変更して、第２ＨＴＴＰサブスクライブ・メッセージ７２４を、最初の第１ＨＴＴＰサブスクライブ・メッセージにおいて識別された配信ノードに送ることができる。変更されたＨＴＴＰサブスクライブ・メッセージは、こうして、キャッシュ内に存在しないチャンク（セグメント）だけを要求する。あるいは、サブスクリプション・トランスレータは、１つ以上の（上流）ＨＴＴＰチャンク要求（即ち、従来のＨＴＴＰ要求メッセージ）に基づいて、コンテンツ・データベースに格納されなかったチャンクを要求することを決定し、これらの要求メッセージ７２２を配信ノードに送るために、これらのＨＴＴＰ要求をクライアントに送ることもできる。

最初の第１ＨＴＴＰサブスクライブ・メッセージ内にあったチャンクが全くキャッシュ内に格納されていない場合、ＨＴＴＰサブスクリプション・トランスレータは、ＨＴＴＰチャンク要求をキャッシュ内にあるＨＴＴＰクライアント７１８に転送することができ、ＨＴＴＰクライアント７１８はＨＴＴＰサブスクライブ・メッセージを配信ノードに送る。ＨＴＴＰクライアントは、更に、ＨＴＴＰ応答７２４を逆に配信ノードおよび／または他のネットワーク・ノードから受信するように構成することができる。チャンクを含むＨＴＴＰ応答は選別され、チャンクのコンテンツ７２６は、メタデータ、例えば、チャンク識別子および／またはＵＲＬと共にコンテンツ・データベースに格納されるので、ＨＴＴＰサーバ７０２によってコンテンツを引き出すことができる。実施形態では、ＨＴＴＰクライアントは、クライアントによるＨＴＴＰ応答の受信に関連付けられた応答タイミング情報（例えば、タイムスタンプ情報）をＨＴＴＰ要求タイマ・モジュール７１４に送るように構成することもできる。更に別の実施形態では、ＨＴＴＰ要求タイマ・モジュールは、どの時点で応答がＨＴＴＰサーバからクライアントに送られるとよいか判定するために、応答タイミング情報を使用するように構成することができる。このように、キャッシュ・サーバは、キャッシュに格納されていたチャンク、および配信ノードから発信したチャンクを正しい順序でクライアントに送ることができる。

図８は、本発明の更に別の実施形態にしたがって、１つのチャンク要求メッセージに基づいて多数のチャンクを適応型ストリーミング・クライアントに配信する方法を示す。ＨＴＴＰサブスクライブ・メッセージの変更および取り消しをサポートするために、ＨＴＴＰサーバはクライアントおよびリンク・サブスクリプション要求（ＨＴＴＰ要求メッセージを一緒に識別する（例えば、連係を行う）ことができなければならない。ある場合には、これはＴＣＰ接続に基づいて行うことができる。しかしながら、非透過的プロキシが仲介するというような他の場合には、これは可能でない。更に、ＨＴＴＰクライアントおよび／またはサーバにそれらの接続を開いたままにするように強制することはできない。したがって、接続が閉じられるとき、クライアントおよび／またはサーバが１つの特定のストリーミング・セッションに関連付けられた要求および応答をリンクすることができなければならない。この問題は様々な方法で解決することができる。図８の実施形態では、要求および応答を識別するためにトークンを使用する。

図８は、図５を参照して説明したのと同様のフローを示し、クライアントは、早期に送られたＨＴＴＰサブスクライブ・メッセージを更新するために、ＨＴＴＰサブスクライブ更新メッセージを送るように構成される。この実施形態では、しかしながら、クライアントはＨＴＴＰメッセージのＵＲＬにおいてトークンをクエリ・パラメータとして含む。例えば、図８に示すように、クライアントは、チャンク化コンテンツに関連付けられたＭＰＤをネットワーク・ノード（例えば、配信ノード）に要求することができ、ＨＴＴＰ ＧＥＴメッセージの要求ＵＲＬがクエリ・パラメータ"token=abc"を含み、ここで"abc"はクライアント・セッションの一意の識別子である（ステップ８０２）。

続いて、クライアントはＭＰＤファイル８３０を応答メッセージにおいて受信する（ステップ８０４）。ＭＰＤファイルは、追加のトークン・パラメータ"useMPDURLQuery=true"を含み、これは、クライアントに、クライアント・セッション・トークンを、後続のＨＴＴＰチャンク要求の要求ＵＲＬに追加することを命令する。このために、ＭＰＤにおけるチャンク・テンプレート８３４は、追加のチャンク・テンプレート・パラメータ・フィールド$QueryPart$を含むことができる。これは、トークンをクエリ・ストリングとして要求ＵＲＬに追加することを、クライアントに命令する。加えて、このトークン・パラメータは、クライアント・セッション・トークンをクエリ・ストリングとしてＨＴＴＰサブスクライブ・メッセージの要求ＵＲＬに追加することを、クライアントに命令することができる。

クライアントがＨＴＴＰサブスクライブ・メッセージを生成するとき、配信ノードにそれを送る前に、ＭＰＤファイルにおける$QueryPart$パラメータによって指示されるように、元のＭＰＤ ＵＲＬの"token=abc"の部分を要求ＵＲＬに追加する（ステップ８０６）。配信ノードは、ＨＴＴＰサブスクライブ・メッセージを多数のＨＴＴＰ単独チャンク要求メッセージに変換し、一意にクライアント・セッションを識別するために、これらのメッセージをトークン値"abc"にリンクすることができる。したがって、２つの応答を受信した（ステップ８１０および８１２）後に、クライアントが配信ノードに、 "update=1" および"token=abc" クエリがその要求ＵＲＬにアペンドされたＨＴＴＰサブスクライブ・メッセージを送信する場合（ステップ８１４）、配信ノードはこのＨＴＴＰサブスクライブ更新メッセージ（およびそれに関連するＨＴＴＰチャンク要求）を、同じトークンを有する以前のＨＴＴＰサブスクライブ・メッセージ（および関連するＨＴＴＰチャンク要求メッセージ）にリンクし、直前のＨＴＴＰサブスクライブ・メッセージを更新との置き換えのために選択する（ステップ８１６）ことができる。更新は、配信ノードによって未だ処理されていなかった直前のＨＴＴＰサブスクライブ・メッセージのＨＴＴＰチャンク要求の削除を含むことができる。その後、本プロセスは配信プロセスに進むことができる。配信プロセスは、ＨＴＴＰサブスクライブ・メッセージを一連のＨＴＴＰチャンク要求に変換すること、およびこれらのＨＴＴＰチャンク要求に応答してクライアントに応答を送ること（ステップ８１８〜８２２）を含む。

ネットワーク・ノードにＨＴＴＰサブスクライブ・メッセージを更新することを命令する更新パラメータは、種々の方法でＨＴＴＰ要求メッセージに挿入することができる。実施形態では、チャンク・テンプレート・パラメータを参照して先に説明したのと同様に、更新パラメータをトークンまたはクッキーとしてＨＴＴＰメッセージに挿入することができる。あるいは、更新パラメータは、クエリ・ストリングとしてＨＴＴＰ要求メッセージに挿入してもよい。

図９は、本発明の実施形態にしたがって、１つのＨＴＴＰサブスクライブ・メッセージに基づいて多数のチャンクを適応型ストリーミング・クライアントに配信する方法を示す。この特定実施形態では、クライアント・セッション・トークンを使用する（図８を参照して説明したように）代わりに、クライアント・セッション識別にクッキーを使用する。

クライアントが、配信ノードのような、ネットワーク・ノードにＭＰＤを要求するとき（ステップ９０２）、配信ノードは、ＭＰＤデータを含むＨＴＴＰ応答９２４に"Set-Cookie"ヘッダ・フィールド９２６を設定することができる。このヘッダ・フィールドは、クッキー名"Sessionld"およびクッキー値"abc"を含むことができる。この値は、クライアント・セッションの一意の識別子を表す。一旦ＨＴＴＰ応答メッセージがクライアントによって受信されたなら、配信ノードが異なるＨＴＴＰサブスクライブ・メッセージとＨＴＴＰ要求および応答とを相関付けすることができるように、クライアントは"Cookie"ヘッダ・フィールドを、受信したセッション識別子と共に、あらゆる後続のＨＴＴＰチャンク要求メッセージまたはＨＴＴＰサブスクライブ・メッセージに追加することができる。例えば、クライアントが、ＳｅｓｓｉｏｎＩＤに値ａｂｃが与えられたクッキー・ヘッダを含むＨＴＴＰサブスクライブ・メッセージを生成し、このＨＴＴＰサブスクライブ・メッセージを配信ノードに送る（ステップ９０６）ことができる。同様に、クライアントは、同じクッキー・ヘッダを含むＨＴＴＰサブスクライブ更新メッセージを生成し、それを配信ノードに送ることができ、配信ノードはこのクッキー値を使用して、このサブスクライブ更新メッセージを以前のサブスクライブ・メッセージに関係付けることができる。

図１０は、本発明の実施形態にしたがって、１つの要求メッセージに基づいて（例えば、ＨＴＴＰサブスクライブ・メッセージに基づいて）多数のチャンクを適応型ストリーミング・クライアントに配信する方法を示す。コンテンツ配信ネットワーク（ＣＤＮ）では、要求ルータまたは配信ノードがＨＴＴＰ要求メッセージをＣＤＮにおける他のノードにリダイレクトすることができる。ＨＴＴＰサブスクライブ・メッセージの場合、リダイレクト方式を単純に実施することはできない。何故なら、１つのＨＴＴＰサブスクライブ・メッセージが、各々異なるリダイレクトを要求するかもしれない多数のＨＴＴＰ要求を指す(refer to)こともあり得るからである。更に、既知のＨＴＴＰプロトコル実施では、送られる要求毎に１つのリダイレクト・メッセージが必要となる。図１０は、本発明の態様において、既知のＨＴＴＰリダイレクト原理をＨＴＴＰサブスクライブ・メッセージに基づく応答に拡張する方法を示す。

この実施形態例では、クライアントは、最初に、２つの異なるＳＶＣレイヤ、例えば、ベース・レイヤおよびエンハンスメント・レイヤを２つのチャンクに要求するために、第１ＨＴＴＰサブスクライブ・メッセージを第１配信ノードに送る（ステップ１００２）ことができる。第１配信ノードは、ＨＴＴＰサブスクライブ・メッセージを変換し（ステップ１００４）、２つのベース・レイヤ・チャンクしかクライアントに配信できないと判断する。したがって、これは、２つのエンハンスメント・レイヤ・チャンクを要求するために、クライアントを第２配信ノードにリダイレクトすることができる。ＨＴＴＰリダイレクト・メッセージは、第２配信ノードへのリソース・ロケーション・パスの少なくとも一部およびチャンク・テンプレートを含むリダイレクトＵＲＬを含むＨＴＴＰ応答メッセージの形態で実装することができる。ここで、第２配信ノードは、前記第１配信ノードによて前記クライアントに配信することができないチャンクを配信することができればよい。ＨＴＴＰリダイレクト・メッセージは、更に、前記第１ネットワーク・ノードによって配信することができない１つ以上のチャンクを定めるために１つ以上の第２チャンク・テンプレート・パラメータを含むことができる。この特定例では、第２チャンク・テンプレート・パラメータは、ＱＩＤテンプレート・パラメータがこの場合は第２（エンハンスメント）レイヤのみを指すことを除いて、元のＨＴＴＰサブスクライブ・メッセージのチャンク・テンプレート・パラメータと同じセマンティクスを有する（ステップ１００６）。ＨＴＴＰサブスクライブ・リダイレクト・メッセージに応答して、クライアントは、エンハンスメント・レイヤ・チャンクを要求するために、新たな第２ＨＴＴＰサブスクライブ・メッセージを第２配信ノードに送ることができ（ステップ１００８）、このＨＴＴＰサブスクライブ・メッセージは、リダイレクト・メッセージ内にあるリダイレクトＵＲＬおよび第２チャンク・テンプレート・パラメータに対応する要求ＵＲＬおよびチャンク・テンプレート・パラメータを含む。最後に、第１および第２配信ノードは、要求されたコンテンツを所定の順序でクライアントに配信することができる（ステップ１０１２〜１０２２）。

図１１は、本発明の実施形態によるマニフェスト・ファイルおよび関連するＨＴＴＰサブスクライブ・メッセージを示す。マニフェスト・ファイルは、サブスクリプション・サポート・パラメータを含むことができ、この例ではsupportSubscription１１０２として示される。このサブスクリプション・サポート・パラメータは、コンテンツ配信システム、例えば、ＣＤＮ（コンテンツ配信ネットワーク）または１つの配信ノードが、好ましくは本発明による更新およびリダイレクト・メッセージを含む、ＨＴＴＰサブスクライブ・メッセージをサポートするか否かを示す。サポートする場合、クライアント、具体的には、クライアントにおけるサブスクリプション・ジェネレータが、チャンク・テンプレート１１０６に基づいて、ＨＴＴＰサブスクライブ・メッセージ、ＨＴＴＰサブスクライブ更新メッセージを生成し、および／またはＨＴＴＰサブスクライブ・リダイレクト・メッセージに応答することができる。更に別の実施形態（図示せず）では、サポート・サブスクリプション更新パラメータおよびサポート・サブスクリプション・リダイレクト・パラメータのような別個のパラメータに基づいて、本発明による更新および／またはリダイレクト方式のサポートをマニフェスト・ファイルにおいて通知することもできる。このようなＨＴＴＰサブスクライブ・メッセージの様々なフォーマットを図１１に示す。

例えば、実施形態では、クライアントが、要求ＵＲＬ movie/movie_c{Number}_q1.mp4を形成するために、マニフェスト・ファイル内にあるチャンク・テンプレートおよびベースＵＲＬを使用することができ、ＵＲＬテンプレートmovie_c{Number}_q1が、一連のＨＴＴＰチャンク要求メッセージを生成またはエミュレートするために、変換モジュールによって使用される。その後、要求ＵＲＬを含むＨＴＴＰサブスクライブ・メッセージ１１０８を形成することができ、ＨＴＴＰヘッダは、チャンク・テンプレート・パラメータＮｕｍｂｅｒおよびその属性を含むことができる。これらは、サブスクリプション・トランスレータによって、特定のＨＴＴＰチャンク要求メッセージに対してチャンク番号を定めるために使用される。他の実施形態では、要求ＵＲＬを含むＨＴＴＰサブスクライブ・メッセージ１１１０を形成することもでき、１つ以上のチャンク・テンプレート・パラメータおよびそれらの属性（この例では、チャンク・テンプレート・パラメータＮｕｍｂｅｒ）をＵＲＬに、例えば、１つ以上のクエリ・パラメータの形態で追加することができる。

図１２は、本発明の他の実施形態によるマニフェスト・ファイルおよび関連するＨＴＴＰサブスクライブ・メッセージを示す。図１１において、ＨＴＴＰヘッダ・フィールドに基づくＨＴＴＰサブスクライブ・フォーマットが採用され、サーバ、具体的には、サーバにおける変換モジュールが、角括弧（または何らかの他の境界(delimiter)間にある変数）を、対応するヘッダ・フィールドにおける値と置き換える。図１２は、直接交換が採用される代替手法を示す。したがって、この実施形態においても、マニフェスト・ファイルは、ＨＴＴＰサブスクライブ・メッセージがサーバによってサポートされることをクライアントに示すために、サブスクリプション・サポート・パラメータ１２０２を含むことができる。加えて、マニフェスト・ファイルは、どのサブスクリプション方法を使用するかクライアントに命令するために、サブスクリプション・フォーマット・パラメータ１２０４も含むことができる。この場合、この方法は、ＨＴＴＰサブスクライブ・メッセージの要求ＵＲＬのＵＲＬテンプレートにおける１つ以上のチャンク・テンプレート・パラメータを、直接それらのそれぞれの属性と交換する（この場合、$Number$を直接1;1,2;2s"と交換する）ことを指示する交換である。

尚、この開示においてＨＴＴＰメッセージのＵＲＬにある種のアスキー・キャラクタ（「；」および「，」のような）を使用するとき（図１１および図１２におけるように）、それらのエンコード値を使用してもよいことを注記しておく。更に、図１〜図１２における実施形態は、チャンク・テンプレート・パラメータおよびチャンク・テンプレートの双方を含むＨＴＴＰサブスクライブ・メッセージを例示するが、本発明は、チャンク・テンプレートが、チャンク・テンプレート・パラメータとは別個に、ネットワーク・ノード（例えば、配信ノードまたはキャッシュ）に供給され、チャンク・テンプレート・パラメータはＨＴＴＰサブスクライブ・メッセージにおいてネットワーク・ノードに送られる実施形態も含むことを申し添えておく。

図１３は、図１〜図１２を参照して説明したシステムおよび方法において使用することができるデータ処理システム例を示すブロック図である。データ処理システム１３００は、システム・バス１３０６を通じてメモリ・エレメント１３０４に結合された少なくとも１つのプロセッサ１３０２を含むことができる。したがって、データ処理システムは、メモリ・エレメント１３０４内にプログラム・コードを格納することができる。更に、プロセッサ１３０２は、メモリ・エレメント１３０４からシステム・バス１３０６を通じてアクセスしたプログラム・コードを実行することができる。１つの態様では、データ処理システムは、プログラム・コードを格納するおよび／または実行するのに適したコンピュータとして実現することもできる。しかしながら、データ処理システム１３００は、プロセッサおよびメモリを含み本明細書内において説明した機能を実行することができる任意のシステムの形態で実現できることは、認められてしかるべきである。

メモリ・エレメント１３０４は、例えば、ローカル・メモリ１３０８および１つ以上の大容量記憶デバイス１３１０のような、１つ以上の物理メモリ・デバイスを含むことができる。ローカル・メモリとは、一般にプログラム・コードの実際の実行の間使用されるランダム・アクセス・メモリまたは他の非永続的メモリ・デバイスを指すことができる。大容量記憶デバイスは、ハード・ドライブまたは他の永続的データ記憶デバイスとして実装することができる。また、処理システム１３００は、１つ以上のキャッシュ・メモリ（図示せず）も含むことができる。キャッシュ・メモリは、実行中にプログラム・コードを大容量記憶デバイス１３１０から引き出さなければならない回数を削減するために、少なくとも一部のプログラム・コードの一時的格納に備える。

任意に、入力デバイス１３１２および出力デバイス１３１４として示される入力／出力（Ｉ／Ｏ）デバイスを、データ処理システムに結合することができる。入力デバイスの例には、例えば、キーボード、マウスのようなポインティング・デバイス等を含むことができるが、これらに限定されるのではない。出力デバイスの例には、例えば、モニタまたはディスプレイ、スピーカ等を含むことができるが、これらに限定されるのではない。入力デバイスおよび／または出力デバイスは、直接または仲介するＩ／Ｏコントローラを介してのいずれかでデータ処理システムに結合することができる。また、ネットワーク・アダプタ１３１６もデータ処理システムに結合することができ、他のシステム、コンピュータ・システム、リモート・ネットワーク・デバイス、および／またはリモート記憶デバイスに、仲介する私有または公共ネットワークを通じて、データ処理システムを結合することを可能にする。ネットワーク・アダプタは、前記システム、デバイス、および／またはネットワークによって送信されたデータを受信するデータ受信機と、データを前記システム、デバイス、および／またはネットワークに送信するデータ送信機とを含むことができる。モデム、ケーブル・モデム、およびイーサネット・カードは、データ処理システム３１５０と共に使用することができる異なるタイプのネットワーク・アダプタの例である。

図１３に示すように、メモリ・エレメント１３０４はアプリケーション１３１８を格納することができる。尚、データ処理システム１３００は、更に、アプリケーションの実行を容易にすることができるオペレーティング・システム（図示せず）も実行できることは認められてしかるべきである。実行可能プログラム・コードの形態で実装されたアプリケーションは、データ処理システム１３００によって、例えば、プロセッサ１３０２によって実行することができる。アプリケーションの実行に応答して、データ処理システムは、本明細書において更に詳しく説明する１つ以上の動作を実行するように構成することができる。

１つの態様では、例えば、データ処理システム１３００はクライアント・データ処理システムを表すことができる。この場合、アプリケーション１３１８はクライアント・アプリケーションを表すことができ、実行されると、データ処理システム１１００を、「クライアント」を参照して本明細書において説明した種々の機能を実行するように構成する。クライアントの例には、パーソナル・コンピュータ、携帯用コンピュータ、移動体電話機等を含むことができるが、これらに限定されるのではない。

本明細書において使用する用語は、特定の実施形態を説明することを目的とするのであり、本発明を限定することを意図するのではない。本明細書において使用する場合、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈が明らかにそうでないことを示さない限り、複数形も含むことを意図している。更に、「含む」(comprises)および／または「含んでいる」(comprising)という用語が本明細書において使用される場合、述べられる特徴、整数、ステップ、動作、エレメント、および／またはコンポーネントの存在を指定するが、１つ以上の他の特徴、整数、ステップ、動作、エレメント、コンポーネント、および／またはそのグループの存在や追加を除外するのではないことも理解されよう。

以下の特許請求の範囲における全ての手段またはステップ＋機能エレメントの対応する構造、材料、行為、および均等物は、当該機能を他の特許請求されるエレメントと組み合わせて実行する任意の構造、材料、または行為を、特定的に特許請求されたかのように、含むことを意図している。本発明の説明は、例示および説明の目的に限って提示されたのであって、網羅的であること、または開示した形態に本発明を限定することを意図するのではない。本発明の範囲および主旨から逸脱することなく、当業者には多くの変更および変種が明白であろう。以上の実施形態が選択され説明されたのは、本発明の原理および実用的実施形態を最良に説明するためであり、更に他の当業者が、本発明を理解して、想定される特定の使用に適する種々の変更を行って種々の実施形態を得ることを可能にするためである。

図１４は、本発明の実施形態にしたがって、１つのチャンク要求メッセージに基づいて多数のチャンクを適応型ストリーミング・クライアントに配信する方法を示す。この特定実施形態では、図２Ａにおけるのと同じ交換が示されるが、ＨＴＴＰバージョン１．１の代わりにＨＴＴＰバージョン２を使用する。ＨＴＴＰ２はプッシュ・ベースのデータ配信をサポートするので、１つの要求に基づく多数のセグメントの配信に非常に適している。ＨＴＴＰ２では、クライアントとサーバとの間の通信は、１つ以上のストリームにわたって送られるフレーム（ＨＴＴＰ２メッセージと呼ぶこともできる）を使用して実行される。ステップ１４０６において、クライアントがＨＥＡＤＥＲフレーム（ＨＴＴＰ（２）要求メッセージ）を、ストリーム識別子０×３を有する配信ノードに送るときに、ＩＤ０×３を有する新たなストリームが暗示的にクライアントによって作成される。ＨＥＡＤＥＲＳフレームの代わりに、ＨＥＡＤＥＲＳフレーム・メッセージという用語を使用することもできる。「ストリーム識別子」パラメータを、本発明の実施形態によるセッション識別子として使用することができる（例えば、セッション識別子として機能する）。

要求のパラメータは、図２Ａにおけるものと同様であるが、ＨＴＴＰ２のシンタックスを使用する。尚、ＨＴＴＰ２は本質的に二進フォーマットであるが、メッセージは明確化のために平文で示されることを注記しておく。ステップ１４１０において、配信ノードは再度変換ステップを実行する。続いて、これは要求されたセグメントをクライアントに送る（ステップ１４１２〜１４２４）。各セグメントは、ストリーム０×３上で送られるＤＡＴＡフレーム（例えば、ＨＴＴＰ（２）応答メッセージ）である。ＤＡＴＡフレームの代わりに、ＤＡＴＡフレーム・メッセージという用語を使用することもできる。最後に、最終ＤＡＴＡフレームが送られるとき、配信ノードはＥＮＤ＿ＳＴＲＥＡＭフラグをセットして、要求されたセグメント全てが配信されたことをクライアントに通知する。

図１５は、本発明の実施形態にしたがって２つの（チャンク）要求メッセージに基づいて多数のチャンクを適応型ストリーミング・クライアントに提供する方法を示す。この特定実施形態では、内蔵されたＨＴＴＰ２機能(facilities)を使用することによって、どのようにサブスクリプション要求（即ち、多数のチャンクの配信のための要求メッセージ）を取り消すおよび／または変更することができるかについて示す。具体的には、クライアントは、数個のチャンクが既に配信された後であっても、ステップ１５１６において、 元の要求からのストリーム識別子（即ち、ステップ１５０６のＨＥＡＤＥＲＳフレーム）に等しいストリーム識別子を有するＲＳＴ＿ＳＴＲＥＡＭフレームを送ることによって、前記要求を容易に取り消すことができる。このＲＳＴ ＳＴＲＥＡＭフレーム・メッセージ（ＨＴＴＰ取り消しメッセージ）は、ストリームを閉じて、配信ノードがそれ以上のセグメント（チャンク）を送ることを防止する。その後、クライアントは自由に新たなストリームを開き、他の（サブスクリプション）要求（例えば、ＨＴＴＰ更新メッセージ）を（第２）ＨＥＡＤＥＲＳフレームの形式で送る。

図１４および図１５は、本発明の実施形態をどのようにＨＴＴＰ２に基づいて実現できるかを実証する。ＨＴＴＰ２の更に他の代わりとして、本発明の実施形態は、ウェブソケット・プロトコルに基づくメッセージを使用して、そしてウェブソケット接続を使用して実現することができる。ウェブソケットは、クライアントとサーバとの間における全二重通信をサポートする。通信はフレームを使用して行われる。フレームは、テキスト・ベースまたは二進ペイロード・データを収容することができる。このデータのシンタックスおよびセマンティクスは、ウェブソケット・プロトコルを使用するアプリケーションによって自由に選択することができる。したがって、本発明の実施形態によれば、ＨＴＴＰ２の例に使用したシンタックスと同様のシンタックスを、ウェブソケット・ベースの（サブスクリプション）要求メッセージに合わせて改造することができる。本発明の実施形態にしたがって（サブスクリプション）要求メッセージとして構成されたウェブソケット・フレームのペイロードは、例えば、次の形態をなすことができる。
> subscription_id = 3
> method = GET
> path = movie/movie_c{number}_q{bandwidth}.mp4
> number = 2;1,2;2s
> bandwidth = 1;1-3;0s

ＨＴＴＰ２とは対照的に、ウェブソケット・メッセージはストリームと関連付けられず、したがって、要求を応答と関連付けるために"subscription_id"変数がメッセージのペイロードに付加された。このように、"subscription id"パラメータは、本発明の実施形態にしたがって、セッション識別子として使用する（セッション識別子として機能する）ことができる。同様に、サブスクリプション取り消しメッセージは、例えば、次のシンタックスによって定めることができる。
> subscription_id = 3
> method = CANCEL
同様に、ウェブソケット更新メッセージを、method=UPDATEによって定めることができ、更に新たに定められたチャンク（セグメント）の集合体を含む。

サーバ（例えば、配信ノード）側からは、セグメント・データ・メッセージ（例えば、セグメントまたはチャンクを収容し、（ウェブソケット）応答メッセージとも呼ばれる）は、以下の形式（シンタックス）をなすことができる。
> subscription_id = 3
> method = SEGMENT
> last_segment = 1
> <segment data>
"last_segment"変数は任意であり、ＨＴＴＰ２の例におけるＥＮＤ＿ＳＴＲＥＡＭビットと同じ目的を果たす。

Claims (16)

1. １つの要求メッセージに基づいて、適応型ストリーミング・クライアントによって複数のチャンクを要求する方法であって、前記複数のチャンクが、チャンク識別子を含み当該チャンク識別子によって定められたチャンクを前記クライアントに配信する少なくとも１つの配信ノードを決定するためのマニフェスト・ファイルに基づいて定められ、
   前記方法が、前記クライアントの少なくとも１つのプロセッサにより、
   前記マニフェスト・ファイルに基づいて第１複数のチャンクを要求するために、ＨＴＴＰ ＧＥＴメッセージ、ＨＴＴＰ ＨＥＡＤＥＲＳフレーム・メッセージまたはウェブソケット・ベースのメッセージの１つである第１要求メッセージを決定するステップであって、前記第１要求メッセージが、第１チャンク・テンプレートと１つ以上の第１チャンク・テンプレート・パラメータとを含む、ステップと、
   前記第１要求メッセージを第１ネットワーク・ノードに送るステップであって、前記第１ネットワーク・ノードが、前記１つ以上の第１チャンク・テンプレート・パラメータと、１つ以上のチャンク・テンプレート・パラメータ・フィールドを含む前記第１チャンク・テンプレートと、に基づいて、前記第１複数のチャンクに関連付けられた第１複数のチャンク識別子、好ましくは、第１複数のＵＲＬを決定するように構成される、ステップと、
   前記第１チャンク・テンプレートおよび前記１つ以上の第１チャンク・テンプレート・パラメータに基づいて決定された前記第１複数のチャンク識別子の内の１つに関連付けられたチャンクを含む、少なくとも１つの応答メッセージを受信するステップと、
   第２要求メッセージ、好ましくは、ＨＴＴＰ ＧＥＴメッセージを決定するステップと、
   についてのコンピュータ読み取り可能プログラム・コードを実行することを含み、
   前記第２要求メッセージが、第２チャンク・テンプレートおよび１つ以上の第２チャンク・テンプレート・パラメータに基づいて前記第１ネットワーク・ノードによって決定された第２複数のチャンク識別子に基づいて、前記第１複数のチャンク識別子の少なくとも一部を更新することを前記第１ネットワーク・ノードに命令するように構成され、
   前記第１要求メッセージがＨＴＴＰ ＨＥＡＤＥＲＳフレーム・メッセージであり、ＨＴＴＰ２取り消しメッセージを送るステップが前記第２要求メッセージを送るステップに先行し、
   前記ＨＴＴＰ２取り消しメッセージを送るステップが、前記第１要求メッセージで要求されたものの未だ前記クライアントに送られていないチャンクの送信をキャンセルする、方法。
2. 請求項１記載の方法において、前記第１ネットワーク・ノードが、
   前記第１チャンク・テンプレートおよび前記１つ以上の第１チャンク・テンプレート・パラメータに基づいて前記第１複数のチャンクの少なくとも一部に関連付けられた所定の１組のチャンク要求メッセージを生成またはエミュレートし、
   前記チャンク要求メッセージの内少なくとも１つに対して、チャンクを含む応答メッセージを前記クライアントに送り、好ましくは、前記所定の１組のチャンク要求メッセージに応答して、所定の１組の応答メッセージを前記クライアントに送る
   ように構成される、方法。
3. 請求項１または２記載の方法において、前記第１要求メッセージを決定するステップが、
   前記マニフェスト・ファイルにおける前記１つ以上のチャンク識別子の少なくとも一部に基づいて前記第１チャンク・テンプレート・パラメータを決定するステップを含み、
   好ましくは、第１チャンク・テンプレート・パラメータが、
   １つ以上のチャンク番号またはチャンク番号の範囲と、
   １つ以上のチャンク・プレゼンテーション時刻またはプレゼンテーション時間期間と、
   １つ以上のチャンク品質表現またはチャンク品質プレゼンテーション範囲と、
   １つ以上のチャンク・ビットレートまたはチャンク・ビットレート範囲と、
   １つ以上のチャンク・サイズまたはチャンク・サイズの範囲と、
   の内少なくとも１つに関連付けられる、方法。
4. 請求項１〜３のいずれか１項記載の方法において、前記第１要求メッセージについての要求ＵＲＬが、前記第１チャンク・テンプレートと、前記第１ネットワーク・ノードに関連付けられたリソース・ロケーション・パスとを含み、並びに／または前記１つ以上の第１チャンク・テンプレート・パラメータの少なくとも一部が前記要求メッセージに追加され、好ましくは、前記１つ以上の第１チャンク・テンプレート・パラメータが、前記第１要求メッセージのヘッダに挿入される、前記要求ＵＲＬに挿入される、および／若しくは前記要求にクエリ・ストリングとしてアペンドされる、方法。
5. 請求項１〜４のいずれか１項記載の方法において、
   第１要求メッセージを決定するステップが、更に、セッション識別子を前記第１要求メッセージに挿入するステップを含み、
   前記セッション識別子が、前記クライアントおよび／または前記第１ネットワーク・ノードが前記第１要求メッセージを１つ以上の他の要求メッセージおよび／または応答メッセージにリンクすることを可能にし、好ましくは、前記セッション識別子がトークンとして前記第１要求メッセージについての要求ＵＲＬに追加されるか、またはクッキー値として前記第１要求メッセージのヘッダに追加される、方法。
6. 請求項１〜５の何れか一項記載の方法において、前記第２要求メッセージが、前記第２要求メッセージに基づいて前記第１要求メッセージを更新することを前記第１ネットワーク・ノードに命令する更新パラメータを含む、方法。
7. 請求項１〜６のいずれか１項記載の方法において、
   前記第１ネットワーク・ノードが、該第１ネットワーク・ノードによって前記クライアントに配信できない１つ以上のチャンクに関連付けられた少なくとも１つの応答メッセージ、好ましくは、ＨＴＴＰリダイレクト・メッセージを生成するステップを含み、
   前記応答メッセージが、前記第１ネットワーク・ノードによって配信できない前記１つ以上のチャンクを配信することができる第２ネットワーク・ノードに関連付けられたリソース・ロケーション・パスを含み、好ましくは、前記応答メッセージが、更に、前記第２ネットワーク・ノードに関連付けられたリダイレクトＵＲＬを含み、好ましくは、前記リダイレクトＵＲＬが、第２チャンク・テンプレートと、前記第１ネットワーク・ノードによって配信できない前記１つ以上のチャンクを定める１つ以上の第２チャンク・テンプレート・パラメータとを含む、方法。
8. １つの要求メッセージに基づいて複数のチャンクを少なくとも１つのクライアントに配信するように構成されたネットワーク・ノードであって、前記クライアントが、好ましくは、適応型ストリーミング・クライアントであり、前記ネットワーク・ノードが、
   コンピュータ読み取り可能プログラム・コードが具体化された少なくとも１つのコンピュータ読み取り可能記憶媒体と、前記コンピュータ読み取り可能記憶媒体に結合された少なくとも１つのプロセッサ、好ましくは、少なくとも１つのマイクロプロセッサとを含み、前記コンピュータ読み取り可能プログラム・コードの実行に応答して、前記少なくとも１つのプロセッサが、
   第１複数のチャンクの前記クライアントへの配信を要求する第１要求メッセージ、好ましくは、ＨＴＴＰ ＧＥＴメッセージを受信する動作であって、前記第１要求メッセージが第１チャンク・テンプレートと１つ以上の第１チャンク・テンプレート・パラメータとを含む、動作と、
   前記１つ以上の第１チャンク・テンプレート・パラメータと、１つ以上のチャンク・テンプレート・パラメータ・フィールドを含む前記第１チャンク・テンプレートとに基づいて、前記第１複数のチャンクに関連付けられた第１複数のチャンク識別子、好ましくは、第１複数のＵＲＬを決定する動作と、
   少なくとも１つの応答メッセージを前記クライアントに送る動作であって、前記応答メッセージが、前記第１チャンク・テンプレートおよび前記１つ以上の第1チャンク・テンプレート・パラメータに基づいて決定された前記チャンク識別子の内１つに関連付けられたチャンクを含む、動作と、
   前記クライアントから、第２要求メッセージ、好ましくは、ＨＴＴＰ ＧＥＴメッセージを受信する動作と、
   を含む実行可能動作を実行するように構成され、
   前記第２要求メッセージが、第２チャンク・テンプレートおよび１つ以上の第２チャンク・テンプレート・パラメータに基づいて前記ネットワーク・ノードによって決定された第２複数のチャンク識別子に基づいて、前記第１複数のチャンク識別子の少なくとも一部を更新することを前記ネットワーク・ノードに命令するように構成され、
   前記第１要求メッセージがＨＴＴＰ ＨＥＡＤＥＲＳフレーム・メッセージであり、ＨＴＴＰ２取り消しメッセージを受信する動作が前記第２要求メッセージを受信する動作に先行し、
   前記受信されたＨＴＴＰ２取り消しメッセージによって、前記第１要求メッセージで要求されたものの未だ前記クライアントに未だ送信されていないチャンクの前記クライアントへの送信が取り消される、ネットワーク・ノード。
9. 請求項８記載のネットワーク・ノードにおいて、前記第１チャンク・テンプレートがＵＲＬチャンク・テンプレートである、ネットワーク・ノード。
10. 請求項８または９記載のネットワーク・ノードにおいて、前記第２要求メッセージが、前記第２要求メッセージに基づいて前記第１要求メッセージを更新するように、前記ネットワーク・ノードをトリガする更新パラメータを含む、ネットワーク・ノード。
11. 請求項８記載のネットワーク・ノードにおいて、前記実行可能動作が、更に、
    前記第１要求メッセージに応答して、前記ネットワーク・ノードによって前記クライアントに配信できない１つ以上のチャンクに関連付けられた応答メッセージ、好ましくは、ＨＴＴＰリダイレクト・メッセージを生成する動作であって、前記応答メッセージが、前記ネットワーク・ノードによって配信できない前記１つ以上のチャンクを配信することができる別のネットワーク・ノードに関連付けられたリソース・ロケーション・パスを含む、動作、または、
    前記第１要求メッセージに応答して、前記ネットワーク・ノードによって前記クライアントに配信できない１つ以上のチャンクに関連付けられた第２要求メッセージを生成する動作であって、前記第２要求メッセージが、前記ネットワーク・ノードによって配信できない前記１つ以上のチャンクを配信することができる前記別のネットワーク・ノードに関連付けられたリソース・ロケーション・パスを含み、好ましくは、前記第２要求メッセージが、要求ＵＲＬ、第２チャンク・テンプレート、および前記ネットワーク・ノードによって配信できない前記１つ以上のチャンクを定める１つ以上の第２チャンク・テンプレート・パラメータを含む、動作、
    を含む、ネットワーク・ノード。
12. １つの要求メッセージに基づいて複数のチャンクを要求するように構成された適応型ストリーミング・クライアントを含むユーザ・デバイスであって、前記チャンクが、チャンク識別子を含み当該チャンク識別子によって定められたチャンクを前記クライアントに配信する少なくとも１つの配信ノードを決定するためのマニフェスト・ファイルに基づいて定められ、前記ユーザ・デバイスが、
    プログラムの少なくとも一部が具体化され、詳細ソフトウェア・プログラムを有するコンピュータ読み取り可能記憶媒体と、
    コンピュータ読み取り可能プログラム・コードが具体化されたコンピュータ読み取り可能記憶媒体と、
    前記コンピュータ読み取り可能記憶媒体に結合されたプロセッサ、好ましくは、マイクロプロセッサと、
    を含み、前記コンピュータ読み取り可能プログラム・コードの実行に応答して、前記プロセッサが、
    前記マニフェスト・ファイルに基づいて、第１複数のチャンクを要求するための第１要求メッセージ、好ましくは、ＨＴＴＰ ＧＥＴメッセージを決定する動作であって、前記第１要求メッセージが第１チャンク・テンプレートと１つ以上の第１チャンク・テンプレート・パラメータとを含む、動作と、
    前記第１要求メッセージを第１ネットワーク・ノード、好ましくは、配信ノードまたはキャッシュに送る動作であって、前記第１ネットワーク・ノードが、前記１つ以上の第１チャンク・テンプレート・パラメータと、１つ以上のチャンク・テンプレート・パラメータ・フィールドを含む前記第１チャンク・テンプレートとに基づいて、前記第１複数のチャンクに関連付けられた第１複数のチャンク識別子、好ましくは、第１複数のＵＲＬを決定するように構成される、動作と、
    前記第１チャンク・テンプレートおよび前記１つ以上の第１チャンク・テンプレート・パラメータに基づいて決定された前記チャンク識別子の内の１つに関連付けられたチャンクを含む、少なくとも１つの応答メッセージを受信する動作と、
    第２要求メッセージを決定する動作と、
    を含む実行可能動作を実行するように構成され、
    前記第２要求メッセージが、第２チャンク・テンプレートおよび１つ以上の第２チャンク・テンプレート・パラメータに基づいて前記第１ネットワーク・ノードによって決定された第２複数のチャンク識別子に基づいて、前記第１複数のチャンク識別子の少なくとも一部を更新することを前記第１ネットワーク・ノードに命令するように構成され、
    前記第１要求メッセージがＨＴＴＰ ＨＥＡＤＥＲＳフレーム・メッセージであり、ＨＴＴＰ２取り消しメッセージを送る動作が前記第２要求メッセージを送る動作に先行し、
    前記ＨＴＴＰ２取り消しメッセージを送る動作が、前記第１要求メッセージで要求されたものの未だ前記クライアントに送られていないチャンクの送信をキャンセルする、ユーザ・デバイス。
13. コンピュータのメモリにおいて実行されると、請求項１〜７のいずれか１項記載の方法ステップを実行するように構成されたソフトウェア・コード部分を含むコンピュータ・プログラムを格納する、コンピュータ読み取り可能記録媒体。
14. 請求項１〜７の何れか１項記載の方法において、前記第１複数のチャンクが、ファイルとして独立して格納可能なセグメントである、方法。
15. 請求項１２記載のユーザ・デバイスにおいて、前記第１複数のチャンクが、ファイルとして独立して格納可能なセグメントである、ユーザ・デバイス。
16. 請求項１記載の方法において、前記第１要求メッセージが、ストリーム識別子を有するＨＴＴＰ ＨＥＡＤＥＲＳフレーム・メッセージであり、前記第１要求メッセージを送るステップに続いて、前記クライアントが、前記ストリーム識別子を有するＲＳＴ ＳＴＲＥＡＭフレーム・メッセージを前記第１ネットワーク・ノードに送り、前記ＲＳＴ ＳＴＲＥＡＭフレーム・メッセージが、前記第１要求メッセージで要求されたものの未だ前記クライアントに送られていないチャンクの送信をキャンセルする、方法。

Images