JP6310513B2 - ネットワーク開始コンテンツ・ストリーミング制御 - Google Patents

Description

本発明は、コンテンツのストリーミング制御に関し、特に、セグメント化されたコンテンツのネットワーク開始ストリーミング制御を可能にする方法、セグメント化されたコンテンツの受信を制御するためにコンテンツ処理デバイスにおいて使用するためのクライアント、セグメント化されたコンテンツのストリーミングのネットワーク開始制御を可能にするための制御チャネル・サーバ機能およびデータ構造、ならびにこのような方法を使用するコンピュータ・プログラム製品に関するが、これらに限定されない。

従来技術

現在、いわゆるコンテンツ・セグメント化を利用するビデオ・ストリーミング技術が拡大しつつある。コンテンツ・セグメント化では、コンテンツ・データ、例えば、ビデオ・データが論理的または仮想的に様々なセグメント・ファイルまたはストリームに分割され、こうしてセグメント化されたコンテンツを生成する。セグメント・ファイルは、コンテンツ・データを構成するファイルに関係することができ、例えば、ＨＴＴＰまたはＦＴＰというような、ファイル検索プロトコルによって抽出することができる。同様に、セグメント・ストリームは、コンテンツ・データを構成するストリームに関係することができ、ストリーミング・プロトコル、例えば、ＲＴＳＰ／ＲＴＰまたはＨＡＳによって抽出することができる。セグメント・ファイルまたはストリーム（以後、省略してセグメントと称することもある）は、別々にクライアントに配信することができるが、クライアントにおいて再度組み合わせられると、これらは継ぎ目のないビデオ・ストリームを供給する。

コンテンツ・セグメント化プロセスの間、いわゆるマニフェスト・ファイル(manifest file)が生成される。マニフェスト・ファイルは、セグメントを識別し、異なるセグメントとそのセグメントを抽出することができる位置（１つまたは複数）との間の関係を記述する。セグメント化されたコンテンツは、様々な表現で供給することができ、例えば、同じコンテンツであるが、例えば、解像度、オーディオ・チャネルの数、および／またはビットレートが異なる代替バージョンで供給することができる。全ての表現は、異なる表現のセグメントを継ぎ目なく相互交換できるように、時間的に整列される。異なる表現にしたセグメント化されたコンテンツのストリーミングは、適応ストリーミングと呼ばれ、ＨＴＴＰ適応ストリーミング（ＨＡＳ）のような適応ストリーミング・プロトコルおよび関連プロトコルを使用することができる。

ＨＡＳは、ＨＴＴＰプロトコルによって、クライアントによって独立して要求されたセグメント単位でビデオをウェブ・サーバから送信することによって、（生の）ビデオ配信を可能にする。Apple社のＨＴＴＰライブ・ストリーミング（http://tools.ietf.org/html/draft-pantos-http-live-streaming-07）、Microsoft Smooth Streaming（http://www.iis.net/download/SmoothStreaming）、Adobe社のHTTP動的ストリーミング（http://www.adobe.com/products/ httpdynamicstreaming）、3GPP-DASH TS 26.247透過型端末間パケット交換ストリーミング・サービス（ＰＳＳ）、ＨＴＴＰ上プログレッシブ・ダウンロードおよび動的適応ストリーミングおよびＨＴＴＰ上ＭＰＥＧ動的適応ストリーミング（MPEG DASH ISO/IEC 23001−6）というような、種々の商用および標準化されたＨＡＳプロトコルが存在する。

セグメント化されたコンテンツは、変化する帯域幅要件に動的に適応するために、例えば、高品質ビデオ・ストリームから低品質ビデオ・ストリームに切り替えることによって、使用することができる。更に、セグメント化されたコンテンツは、人気がある（ビデオ）セグメントと人気がない（ビデオ）セグメントとの間で区別することにも対処することができる。例えば、ビデオの開始に通例関連付けられるコンテンツ（トレーラーのような）の方が、終了時にあるコンテンツよりも頻繁に見られる（したがって一層ポピュラである）であろう。同様に、いくつかの使用事例でも、高品質のコンテンツ（例えば、更に解像度が高いＨＡＳセグメント）の方が高価であり、または受信デバイスからより多くを求められ、またはより多くの帯域幅が必要になるために、これよりも低ビットレートの低品質ビデオ・コンテンツ（例えば、最低解像度のＨＡＳセグメント）の方が頻繁にダウンロードされることもあり得る。以上で述べたセグメント化されたコンテンツの固有性は、コンテンツを消費者に配信するように構成されるコンテンツ配信ネットワーク（ＣＤＮ）によって有利に使用することができる。ＣＤＮは、例えば、人気があり、より頻繁に要求されるコンテンツ・セグメントを当該ＣＤＮにおける多数の配信ノードに格納することができ、帯域幅の問題を低減することができ、効率的な配信が保証される。ＣＤＮの制御機能（ＣＤＮＣＦ）は、ＣＤＮ内部の位置を集中的に管理することができる。これらの位置のことを以後配信ノードと呼び、ここから、コンテンツ項目（ビデオまたはムービーのような）に関連付けられたコンテンツ・セグメントを抽出する（得る）ことができる。

ＲＴＰ／ＲＴＳＰまたはＲＴＭＰのような多数の異なるストリーミング・プロトコルは、（セグメント化）コンテンツをクライアントにストリーミングすることを実現するために使用することができるが、ＨＴＴＰまたはＨＴＴＰベース・ストリーミング・プロトコルがＣＤＮ内部では最も広く使用される。これらのストリーミング・プロトコルは、標準的なＨＴＴＰ、即ち、ステートレスのクライアント−サーバ・プロトコルを使用して、コンテンツ・セグメントを要求してサーバから受信するが、新たな機能性(functionality)を必要とせず、セグメントを透過的にキャッシュすることができる。更に、殆どの他のストリーミング・ソリューションとは異なり、ＨＴＴＰトラフィック自体は、通常ファイアウォールやネットワーク・アドレス変換器（ＮＡＴ）によって自動的に阻止されない。

更に、ＨＴＴＰベース・ストリーミングは、セッションに基づくのではない。これが意味するのは、ＨＴＴＰサーバは、それがサービスを提供する(serve)種々のクライアントのためにセッションを維持する必要がないということである。このように、ＨＴＴＰサーバ・アーキテクチャは簡素に保つことができる。しかしながら、このセッションレスの特性(session−less nature)が、ＨＴＴＰがクライアント開始プロトコル(client−initiated protocol)であるという事実と組み合わせられると、ＨＴＴＰサーバ、例えば、ＣＤＮにおける配信サーバはクライアントとの通信を開始することができないことを意味する。

クライアントがＣＤＮに格納されたセグメントにアクセスする（ダウンロードする／抽出する）ことを可能にするために、クライアントにいわゆるマニフェスト・ファイルが供給される。マニフェスト・ファイルは、セグメントのリストを含み、各セグメントが、セグメント識別子（例えば、セグメント・ファイル名）およびセグメント位置（セグメント・ロケータ）、例えば、ＵＲＬによって識別される。セグメント位置は、当該セグメントにアクセスする（抽出する）ことができるネットワーク・ノードを指し示す。個々のＣＤＮおよび／または実施態様に依存して、既定のマニフェスト・ファイルが、ＣＤＮの１つ以上の（配信）ノードに、関連するセグメントと共に格納されてもよく、あるいはマニフェスト・ファイルが、ユーザの要求時に、ＣＤＮによって動的に生成されてもよい。

このように、消費者（クライアント・デバイス）が特定のセグメント・コンテンツ項目（ビデオのような）を要求すると、ＣＤＮは、要求に応じて、顧客（デバイス）に対する要求されたコンテンツ・ファイルの配信を可能にするのに適した（配信）ノード上に格納されたマニフェスト・ファイルを識別することができる。あるいは、ＣＤＮは、１つ以上の配信ノードを識別する新たなマニフェスト・ファイルを生成することもできる。これらの配信ノードを併せると、要求されたコンテンツ・セグメントを顧客に配信するのに適したものになる。その後、ＣＤＮは、消費者の要求元クライアント（デバイス）に応答して
、生成したマニフェスト・ファイルを送ることができる。

コンテンツ・セグメントのストリーミングの間、ＣＤＮにおけるネットワーク構成および負荷分散が変化する可能性がある。例えば、ＣＤＮにおけるあるノードの障害または過剰負荷のために、ＣＤＮにおける１つ以上の配信ノードが、もはや、マニフェスト・ファイルにおいて識別されたコンテンツ・ファイルを配信できなくなるという状況に陥る場合もある。また、他の状況では、例えば、法外な過剰負荷の状況では、特定のコンテンツ・セグメントの特定の消費者（コンテンツ受信デバイス）に配信するタスクを、ストリーミング・プロセスの間、１つの配信ノードから当該ＣＤＮの他の配信ノードに、または他のＣＤＮにおける配信ノードにさえも移転することによって、過剰負荷状況を防止することが必要になる場合もある。また、特定の消費者のクライアント・デバイスがその位置を変化させたときに、その時点で一層近くなった他の配信ノードに、元のノードからストリーミングを引き受けさせる方が有利であるかもしれないと想像することもできる。配信ネットワークにおいて、クライアントへのセグメントの配信における変更を必要とするまたは保証する他のイベント（即ち、ネットワークにおいて負荷均衡化メカニズムを作動させる）には、計画停電、サーバ移動(Server Migration)、ＣＤＮ移動等がある。

既知の方法では、クライアントに対するセグメント配信の変更は、様々な方法で実現することができる。場合によっては、ＣＤＮが、例えば、ＨＴＴＰリディレクト方式を使用して、セグメント要求を所望の配信ノードにリディレクトすることもできる。このような方式は、しかしながら、クライアントが今後要求するあらゆるセグメントに対して別個のリディレクト応答メッセージ（単にリディレクトと称する）を要求し作動させることがあり、または要求されたセグメント毎に多数のリディレクト応答メッセージさえも要求し作動させることもあり、これによってネットワークにおけるシグナリング負荷の著しい増加を招くことになる。これは、特に、大量の消費者が同じ配信ノードに依存し、同時に同じコンテンツを要求し抽出している場合に該当する。追加のシグナリング負荷がＣＤＮの一部または全部に押し寄せる可能性があるだけでなく、リディレクトがクライアント側において容認できないサービスの中断を引き起こす可能性もある。何故なら、個々のコンテンツ・セグメントの配信は、リディレクトの結果として突然遅延するからである。したがって、リディレクト方式は、ネットワーク構成の変化（例えば、配信ノードの障害の結果）のために、サービス中断を効果的に防止できない場合もある。例えば、コンテンツがクライアント・デバイスにおいて殆どバッファされない状況、多数のリディレクトが発生する状況、または以前の配信ノードと比較して、新たな目標配信ノードがクライアント・デバイスまでかなり長い距離のところに位置する状況においては、サービスの中断は一層顕著になる可能性がある。

あるいは、ＣＤＮが、新たなネットワーク構成に基づいて、クライアントに対して、新たに更新されたマニフェスト・ファイルを生成することもできる。しかしながら、それ自体の本質のために、ＨＴＴＰプロトコルは、サーバ側（例えば、ＣＤＮ）がこのように新たに更新されたマニフェスト・ファイルのクライアントへの送信を直接または率先して開始することを許可せず、またこのような新たに更新されたマニフェスト・ファイルのクライアント要求を開始することも許可しない。クライアントが更新マニフェスト・ファイルを受信するか否かは、このような更新を要求するクライアントの先導(initiative)に完全に依存する（しかしながら、クライアントはネットワーク構成の（保留中の）変化を知ることができない）。同様に、例えば、セグメント化されたコンテンツ・ストリームが、クライアントに以前に供給されたマニフェスト・ファイルにおけるよりも、ＣＤＮによって高い表現(higher representation)で利用可能にされた場合、クライアントはこれを知る方法がなく、このような高品質ストリームから利益を得ることができない。クライアントが、例えば、周期的にマニフェスト・ファイルの更新を要求するように構成されるとしても、このような更新方式は、効果的に（素早く）臨機応変に(an on ad−hoc basis)ネットワーク構成の変化に反応し、このような変化によるサービス中断を回避することができない。このような更新頻度が、突然必要とされる構成変更と正確に一致したとしても、単なる偶然に過ぎないであろう。更に、非常に高い更新頻度を実現すると（ＨＴＴＰベースの要求−応答シグナリング・メカニズムを利用する）、構成変更（例えば、クライアントへのセグメント化されたコンテンツの配信における変化）が必要とされないまたは推奨されない期間であっても、クライアントおよびネットワーク側におけるネットワークおよびプロセッサ負荷に多大なオーバーヘッド・シグナリング負荷を生ずるという欠点がある。

したがって、クライアントへのコンテンツのストリーミング制御を改良することができる方法およびシステムが、当技術分野では求められている。

本発明の目的は、先行技術において周知である欠点の少なくとも１つを低減または解消することである。

第１の態様において、本発明は、配信ノードから、少なくとも１つのクライアント、好ましくは、ＭＰＥＧ ＤＡＳＨ互換適応ストリーミング・クライアントのような、ＨＴＴＰ適応ストリーミング（ＨＡＳ）クライアントへのセグメント化されたコンテンツのストリーミングのネットワーク開始制御を可能にする方法に関する。この方法は、第１マニフェスト・ファイルを受信するステップであって、好ましくは、前記マニフェスト・ファイルが、１つ以上のセグメントを識別するための１つ以上のセグメント識別子と、前記セグメント識別子に関連付けられた１つ以上のセグメントを前記少なくとも１つのクライアントに送信するように構成された１つ以上のコンテンツ配信ノードを位置特定するための位置情報とを含む、ステップと、クライアントにチャネル設定情報を提供するステップと、および／または前記提供されたチャネル設定情報に基づいて、前記少なくとも１つのクライアントとネットワーク、好ましくは、前記１つ以上の配信ノードの内少なくとも１つに関連付けられた制御チャネル・サーバ機能との間に少なくとも１つのストリーミング制御チャネルを確立するステップとを含む。一実施形態では、これらのステップがクライアントによって実行されてもよい。他の実施形態では、前記少なくとも１つのクライアントが、少なくとも１つのマニフェスト・ファイル更新メッセージを前記ストリーミング制御チャネルを通じて受信するように構成されてもよい。あるいは、制御チャネルが、マニフェスト・ファイル更新の入手可能性を示す更新メッセージ以外に、セグメント・コンテンツのストリーミングに関連するサーバまたはネットワーク側イベントのメッセージを伝達するために、ネットワーク（例えば、制御チャネル・サーバ機能）によって使用されてもよい。このようなイベントは、マニフェスト・ファイル更新を通じて伝達できない情報（例えば、パラメータ）、マニフェスト・ファイル更新とは別にクライアントにこれらを伝達する方が適している（例えば、もっと速く）と考えられる情報に関係するのでもよい。このような実施形態では、クライアントが、代わりに、これら他のイベント・メッセージを受信するおよび／または処理するように構成されてもよい。他の実施形態では、前記少なくとも１つのクライアントが、マニフェスト・ファイルに基づいて、前記セグメント化ファイルの少なくとも一部にアクセスするように構成されてもよい。別の実施形態では、クライアントによるマニフェスト・ファイルの受信が、好ましくは、提供されたチャネル設定情報に基づいて、ネットワークとのストリーミング制御チャネルを設定するようにクライアントを作動させるのでもよい。ストリーミング制御チャネルは、ネットワーク、例えば、ＣＤＮが、率先してクライアントにマニフェスト・ファイル更新メッセージを供給し、マニフェスト・ファイル更新の入手可能性を示すことを可能にする。マニフェスト・ファイル更新メッセージは、クライアントが最初に（ＨＴＴＰ）要求をネットワークに送信することを必要とせずに、率先して制御チャネルを通じてクライアントに送信することができる。このように、クライアント上で実行されるストリーミング・プロセスは、ネットワーク構成の変化および／またはネットワークの問題、例えば、突出した過剰負荷状況またはネットワーク障害に素早く反応することができ、これによって、ネットワークは今や先験的にクライアントに知らせることが可能になる。制御チャネルを実現することによって、先行技術型のセグメント化ストリーミング・ソリューションの基礎となる既知の（ＨＴＴＰ）要求−応答メカニズムの限界および欠点を軽減するおよび／または克服することができる。先行技術の一部については、背景の章において詳しく論じられる。

一実施形態では、この方法は、前記ストリーミング制御チャネルを監視して、少なくとも１つのマニフェスト・ファイル更新メッセージを求めるステップを含むのでもよい。この実施形態では、このような更新メッセージに対するクライアントによる素早い応答が保証されるように、クライアントが連続的にチャネルを監視して、ネットワークからの更新メッセージを求めるのでもよい。この監視プロセスは、例えば、ストリーミング・プロセスの間に背景プロセスとして実行されてもよい。

一実施形態では、この方法は、マニフェスト・ファイル更新メッセージを検出するステップと、任意に、前記マニフェスト・ファイル更新メッセージに応答して、第２マニフェスト・ファイルの少なくとも一部を抽出するステップとの内少なくとも１つを含むのでもよい。他の実施形態では、この方法は、更に、前記第２マニフェスト・ファイルに基づいてセグメント・ストリームまたはファイルを要求するステップを含んでもよい。したがって、クライアントによってネットワークから受信されるマニフェスト・ファイル更新メッセージが、更新されたマニフェスト・ファイルが要求されていることおよび／または入手可能であること、ならびにこの更新されたマニフェスト・ファイルに基づいてストリーミング・プロセスを継続すべきことまたは継続してもよいことを、クライアントに知らせることができる。ここで、マニフェスト・ファイルにおける更新は、ネットワーク構成における変化および／またはネットワーク障害またはネットワーク過剰負荷というようなネットワークの問題のために、要求されるのでもよい。このように、ネットワークは、ネットワークにおけるある種のイベントに応答して、ストリーミング・プロセスの制御を効率的にそして率先して開始することができる。先行技術のＨＴＴＰベースのセグメント化ストリーミングのソリューションは、定義上クライアントからの最初の先導を必要とするＨＴＴＰ要求および応答メカニズムに基づくのであり、このようなストリーミング・プロセスの主体的ネットワーク開始制御は、絶対に不可能である。

一実施形態では、前記チャネル設定情報の少なくとも一部が、前記第１マニフェスト・ファイルにおいて前記クライアントに提供されてもよく、あるいは、別のメッセージにおいてクライアントに提供されてもよい。別の実施形態では、前記チャネル設定情報を提供する前記ステップが、前記チャネル設定情報によってクライアントを予め構成するステップを含む。一実施形態では、前記チャネル設定情報が、前記制御チャネル・サーバ機能を前記ネットワークにおいて位置特定するためのサーバ位置情報、好ましくは、少なくとも１つのＵＲＬを含んでもよい。したがって、マニフェスト・ファイルは、制御チャネルを設定するために必要とされる情報の少なくとも一部を含むのでもよい。

一実施形態では、前記マニフェスト・ファイル更新メッセージの前記少なくとも一部が、第２マニフェスト・ファイルの少なくとも一部を含むのでもよい。この実施形態では、ストリーミング制御チャネルが、マニフェスト・ファイルにおける更新の一部を送信するために使用されてもよい。他の実施形態では、前記マニフェスト・ファイル更新メッセージが、前記第２マニフェスト・ファイルの少なくとも一部を突き止めそして要求するためのマニフェスト・ファイル位置情報、好ましくは、少なくとも１つのＵＲＬを含むのでもよい。このように、ネットワークは、簡単で効率的な方法で、更新されたマニフェスト・ファイル（またはその一部）をどこから抽出することができるかについてクライアントに通知することができる。

一実施形態では、前記ストリーミング制御チャネルが、ＷｅｂＳｏｃｋｅｔプロトコルに基づいて確立されてもよい。一実施形態では、コンテンツ配信ネットワーク（ＣＤＮ）エンティティ、好ましくは、制御チャネル・サーバ機能、およびクライアントが、クライアントと前記ＣＤＮエンティティとの間にストリーミング制御チャネルを設定するためにＷｅｂＳｏｃｋｅｔプロトコルおよびチャネル設定情報を使用するように構成されたＨＴＴＰ ＷｅｂＳｏｃｋｅｔ ＡＰＩを含むのでもよい。ＷｅｂＳｏｃｋｅｔ接続は、通例、標準的なＨＴＴＰポート８０および４４３を使用するので、データは容易にファイアウォールおよびＮＡＴを横断することができるが、他のポートが使用されてもよい。更に、このプロトコルは、メッセージ・オーバーヘッドが少ないので、スケーラブルなソリューションを提供する。更に、ＷｅｂＳｏｃｋｅｔはＨＴＴＰに基づくので、ファイアウォールの横断に伴う問題を解消するまたは少なくとも実質的に低減することができる。更に、これは他のプロトコルのトンネリングの可能性も提供する。

一実施形態では、前記セグメント化されたコンテンツの前記少なくとも一部が、ストリーミング・プロトコル、好ましくはＨＴＴＰベース・ストリーミング・プロトコルまたはその派生物に基づいて、前記少なくとも１つのクライアントに配信される。他の実施形態では、ストリーミング制御チャネルが、ＳＩＰプロトコル、ＸＭＰＰプロトコル、および／またはその組み合わせを使用して確立されてもよい。

他の態様において、本発明は、配信ノードから少なくとも１つのクライアントへのセグメント化されたコンテンツのストリーミングのネットワーク開始制御を可能にする方法に関する。前記方法は、１つ以上のセグメント識別子と、前記１つ以上の識別子に関連付けられた１つ以上のセグメントを前記少なくとも１つのクライアントに送信するように構成された１つ以上コンテンツ配信ノードを位置特定するための位置情報とを含む第１マニフェスト・ファイルを、少なくとも１つのクライアントに配信するステップと、前記１つ以上のコンテンツ配信ノードに関連付けられた制御チャネル・サーバ機能と前記少なくとも１つのクライアントとの間に、ストリーミング制御チャネルを設定する要求を受信するステップと、および／または前記少なくとも１つのストリーミング制御チャネルを確立するステップの内少なくとも１つを含むのでもよい。一実施形態では、前記制御チャネル・サーバ機能が、前記少なくとも１つのマニフェスト・ファイル更新メッセージを前記クライアントに送信するように構成されるのでもよい。他の実施形態では、前記クライアントが、マニフェスト・ファイルに基づいて前記セグメント化さえたコンテンツの少なくとも一部にアクセスするように構成されてもよい。他の実施形態では、マニフェスト・ファイルが、１つ以上のセグメント識別子、および／または前記１つ以上のセグメント識別子に関連付けられた１つ以上のセグメントを前記少なくとも１つのクライアントに送信するように構成された１つ以上のコンテンツ配信ノードを位置特定するための位置情報を含むことができる。

他の実施形態では、前記１つ以上の配信ノードの少なくとも第１部分が、前記セグメントの少なくとも第１部分を前記クライアントに配信するように構成された第１コンテンツ配信ネットワークに関連付けられた第１配信ノードとして構成されてもよく、および／または前記配信ノードの少なくとも第２部分が、前記セグメントの少なくとも第２部分を前記クライアントに配信するように構成された第２コンテンツ配信ネットワーク（ＣＤＮ２）に関連付けられた第２配信ノードとして構成されてもよい。この実施形態では、セグメントの少なくとも一部が、第２の別のＣＤＮによって、クライアントに配信される。

一実施形態では、前記方法が、１つ以上のネットワーク・パラメータ、好ましくは、前記１つ以上の配信ノードに関連付けられた過剰負荷、法外な過剰負荷、障害、またはネットワーク構成変更に関連付けられた１つ以上のネットワーク・パラメータの内少なくとも１つを監視するステップと、前記ネットワーク・パラメータに関連付けられた１つ以上の所定の条件が満たされる場合、マニフェスト・ファイル更新メッセージを生成するステップと、任意に、前記マニフェスト・ファイル更新メッセージを前記少なくとも１つのクライアントに送信するステップを含むことができる。

一実施形態では、前記方法が、前記第１配信ノードおよび／または第２配信ノードの内１つ以上に関連付けられた過剰負荷、法外な過剰負荷、障害、またはネットワーク構成変更を判定するステップと、前記判定された過剰負荷、法外な過剰負荷、障害、またはネットワーク構成変更に関連付けられた前記１つ以上の第１配信ノードおよび／または第２配信ノードから、少なくとも１つのセグメントを抽出するかまたは抽出することを予想する１つ以上のクライアントを識別するステップと、前記識別されたクライアントの少なくとも一部に関連付けられた１つ以上のストリーミング制御チャネルを決定するステップと、任意に、マニフェスト・ファイル更新メッセージを前記識別されたクライアントの少なくとも一部に、前記１つ以上のストリーミング制御チャネルを通じて送信するステップとを含むのでもよい。

一実施形態では、前記過剰負荷、法外な過剰負荷、障害、またはネットワーク構成変更の内前記少なくとも一部が、第２ＣＤＮに所属する前記第２配信ノードの少なくとも１つと関連付けられるのでもよい。他の実施形態では、前記方法が、前記第２ＣＤＮが、過剰負荷通知、障害通知、またはネットワーク構成変更通知を前記第１ＣＤＮに送信するステップを含むのでもよく、前記過剰負荷または障害通知が、前記過剰負荷または障害に関連付けられた１つ以上の第２配信ノード識別子を含む。

一実施形態では、前記方法が、クライアント配信情報を第１ＣＤＮデータベースに格納するステップを含み、前記クライアント配信情報が、ストリーミング制御チャネル識別子、クライアント識別子、好ましくは前記クライアントに関連付けられたＩＰアドレス、前記マニフェスト・ファイルにおいて参照された１つ以上のセグメントをホストする配信ノードに関連付けられた配信ノード識別子、コンテンツ配信ネットワーク識別子、および／またはマニフェスト・ファイル識別子の内少なくとも１つを含むのでもよい。

更に他の態様では、本発明は、少なくとも第１および第２コンテンツ配信ネットワーク（ＣＤＮ１、ＣＤＮ２）に関連付けられたセグメント化されたコンテンツの１つ以上のクライアントへのストリーミングのネットワーク開始制御を可能する方法に関することもできる。前記第１ＣＤＮは、第１制御チャネル・サーバ機能に関連付けられ、前記第２ＣＤＮは、第２制御チャネル・サーバ機能に関連付けられる。前記方法は、セグメント化されたコンテンツに関連付けられた第１マニフェスト・ファイルを生成するステップであって、前記第１マニフェスト・ファイルが、１つ以上のセグメントと、前記第１ＣＤＮに関連付けられた１つ以上のコンテンツ配信ノードを位置特定するための位置情報とを含む、ステップと、および／または前記第２制御チャネル・サーバ機能に、前記セグメント化されたコンテンツに関連付けられた第２マニフェスト・ファイルを要求するステップであって、前記第２マニフェスト・ファイルが、１つ以上のセグメント、および／または前記第２ＣＤＮと関連付けられた１つ以上のコンテンツ配信ノードを位置特定するための位置情報を含むのでもよい、ステップと、前記第１および第２マニフェスト・ファイル、ならびに、任意に、チャネル設定情報に基づいて、更に他のマニフェスト・ファイルを生成するステップと、前記チャネル設定情報に基づいて、前記少なくとも１つのクライアントと前記第１制御チャネル・サーバ機能との間に少なくとも第１ストリーミング制御チャネルを確立するステップであって、前記第１制御チャネル・サーバ機能が、マニフェスト・ファイル更新メッセージを生成し、前記メッセージを前記ストリーミング制御チャネルを通じて前記クライアントに送信するように構成されてもよい、ステップを含むことができる。

更に他の態様では、本発明は、コンテンツ処理デバイスにおける使用のためのクライアントに関することもできる。前記クライアントは、セグメント化されたコンテンツを配信する要求を前記サーバに送信し、１つ以上のセグメント識別子と、前記セグメント識別子に関連付けられた１つ以上のセグメントを前記少なくとも１つのクライアントに送信するように構成された１つ以上のコンテンツ配信ノードを位置特定するための位置情報とを含むマニフェスト・ファイルを受信し、第１チャネル設定情報を供給され、および／または前記提供された第１チャネル設定情報に基づいて、前記少なくとも１つのクライアントと前記第１ＣＤＮに関連付けられた前記制御チャネル・サーバ機能との間に第１ストリーミング制御チャネルを確立するように構成されるのでもよい。一実施形態では、前記少なくとも１つのクライアントが、前記第１制御チャネル・サーバ機能から少なくとも１つのマニフェスト・ファイル更新メッセージを受信するように構成される。

一態様において、本発明は、少なくとも１つの配信ノードに関連付けられ、前記配信ノードから１つ以上のクライアントへのセグメント化されたコンテンツのストリーミングのネットワーク開始制御を可能にするための制御チャネル・サーバ機能に関することもできる。前記制御チャネル・サーバ機能は、セグメント化されたコンテンツを前記１つ以上のクライアントに配信する少なくとも１つの要求を受信するステップと、１つ以上のセグメント識別子と、前記１つ以上のセグメント識別子に関連付けられた１つ以上のセグメントを前記クライアントに送信するように構成された１つ以上のコンテンツ配信ノードを位置特定するための位置情報と、任意に、チャネル設定情報とを含む少なくとも１つのマニフェスト・ファイルを生成するステップと、前記少なくとも１つのマニフェスト・ファイルを前記クライアントに送信するステップと、前記チャネル設定情報に基づいて、前記少なくとも１つのクライアントと前記制御チャネル・サーバ機能との間における少なくとも１つのストリーミング制御チャネルの設定に関与するステップの内少なくとも１つのために構成されてもよい。一実施形態では、前記制御チャネル・サーバ機能が、更に、マニフェスト・ファイル更新メッセージを生成し、前記メッセージを前記第１ストリーミング制御チャネルを通じて前記クライアントに送信するように構成することができる
一実施形態では、前記少なくとも１つのマニフェスト・ファイルを生成する動作が、１つ以上の第１セグメント識別子と、第１コンテンツ配信ネットワーク（ＣＤＮ１）において１つ以上のコンテンツ配信ノードを位置特定するための第１位置情報とを提供し、第２コンテンツ配信ネットワークに、１つ以上の第２セグメント識別子と、前記第２コンテンツ配信ネットワーク（ＣＤＮ２）において１つ以上のコンテンツ配信ノードを位置特定するための第２位置情報とを要求し、前記１つ以上の第１および第２セグメント識別子の少なくとも一部と第１および第２位置情報とにそれぞれ基づいて、前記マニフェスト・ファイルを生成する動作を含むことができる。

他の実施形態では、前記制御チャネル・サーバ機能が、更に、過剰負荷通知を前記第２コンテンツ配信ネットワークから受信し、前記過剰負荷通知に応答して、マニフェスト・ファイル更新メッセージを前記第１ストリーミング制御チャネルを通じて前記クライアントに送るように構成することができる。

更に他の態様では、本発明は、前述のようにクライアントにおける使用のための、データ構造、好ましくは、マニフェスト・ファイルに関することもできる。前記データ構造は、１つ以上のセグメント識別子と、前記１つ以上のセグメント識別子に関連付けられた１つ以上のセグメントを前記クライアントに送信するように構成された１つ以上のコンテンツ配信ノードを位置特定するための位置情報とを含むのでもよい。更に、前記データ構造は、前記チャネル設定情報の少なくとも一部を含む。一実施形態では、前記チャネル設定情報が、前記クライアントとストリーミング制御チャネルを設定するプロセスを開始するように構成された制御チャネル・サーバ機能を含むネットワーク・ノードに関連付けられた位置情報、好ましくは１つ以上のＵＲＬを含むことができる。

また、本発明は、ソフトウェア・コード部分を含むコンピュータ・プログラム製品にも関し、コンピュータのメモリにおいて実行されると、以上で説明した方法ステップのいずれかに従って、方法ステップを実行する。

添付図面を参照して、本発明について更に例示する。添付図面は、本発明による実施形態を模式的に示す。尚、本発明は、これらの具体的な実施形態には全く限定されないことは言うまでもない。

図１は、クライアントとサーバとの間における従来のＨＡＳセッションの全体像を示す。 図２は、本発明の一実施形態によるクライアントとサーバとの間におけるプロトコル・フローを示す。 図３は、本発明の一実施形態によるクライアント側プロセス・フローを示す。 図４は、本発明の一実施形態によるサーバ側プロセス・フローを示す。 図５Ａは、本発明の種々の実施形態によるクライアントとサーバとの間におけるプロトコル・フローを示す。 図５Ｂは、本発明の種々の実施形態によるクライアントとサーバとの間におけるプロトコル・フローを示す。 図５Ｃは、本発明の種々の実施形態によるクライアントとサーバとの間におけるプロトコル・フローを示す。 図６は、本発明の一実施形態によるコンテンツ・ストリーミング・システムを示す。 図７は、本発明の一実施形態によるコンテンツ・ストリーミング・システムにおける使用のためのメッセージ・フローを示す。 図８は、本発明の一実施形態による配信連続ノード（ＤＣＮ）機能に関連付けられたプロセス・フローを示す。 図９は、本発明の他の実施形態によるコンテンツ・ストリーミング・システムにおける使用のためのメッセージ・フローを示す。 図１０は、本発明の更に他の実施形態によるコンテンツ・ストリーミング・システムにおける使用のためのメッセージ・フローを示す。 図１１は、本発明の別の実施形態によるコンテンツ・ストリーミング・システムにおける使用のためのメッセージ・フローを示す。 図１２は、本発明の一実施形態によるコンテンツ・ストリーミング・システムを示す。 図１３は、本発明の更に他の実施形態によるコンテンツ・ストリーミング・システムにおける使用のためのメッセージ・フローを示す。 図１４は、本発明の一実施形態によるマニフェスト・ファイルを示す。

図１は、端末におけるクライアント１３０とメディア・サーバ１３２との間における従来のＨＡＳプロトコル・フローの全体像を示す。クライアント１３０およびサーバ１３２は、応答および要求プロトコル・メッセージ１３４，１３６を含むＨＡＳストリーミング・プロトコルのような、ストリーミング・プロトコルによって通信するように構成される。ここでは、端末は、一般に、コンテンツ処理デバイス、例えば、電子タブレット、スマート・フォン、ノートブック、メディア・プレーヤ等というような、（移動体）コンテンツ・プレイ・アウト・デバイスに関係することができる。実施形態では、端末が、コンテンツ・プレイ・アウト・プレーヤによる今後の消費のためにコンテンツを処理し一時的に格納するように構成されたセット・トップ・ボックスまたはコンテンツ記憶デバイスであってもよい場合もある。同様に、メディア・サーバは、コンテンツ提供者またはコンテンツ配信ネットワーク（ＣＤＮ）の一部であってもよく、またはこれに関連付けられてもよい。

このプロトコル・フローは、ユーザがウェブサイト上であるビデオに対するリンクを選択することによって開始することができ（ステップ１０２）、ＵＬＲがマニフェスト・ファイルを指し示すことができる（例えば、リディレクトによって）。マニフェスト・ファイルは、セグメント識別子、例えば、セグメント・ファイル名を含む空間データ構造に関係することができ、セグメント化ビデオ・ファイルおよび１つ以上のネットワーク・ノードを位置特定するための関連する位置情報、例えば、ＵＲＬを構築する。ネットワーク・ノードは、セグメントをクライアント（配信ノード）に配信するように、または代わりにネットワーク・ノードに配信するように構成される。ネットワーク・ノードは、識別されたセグメントを配信することができると考えられる１つ以上のネットワーク・ノードを決定することができる。更に他の実施形態では、位置情報は、ネットワーク・ノード上の位置も指し示すことができる。例えば、ＵＲＬ関連セグメントは、１つの配信ノードにおいて定められた異なるフォルダを指し示すことができる。

好ましくはマニフェスト・ファイル内に含まれる、セグメントに対する参照は、セグメント識別子、および／または当該セグメントを位置特定するためにセグメント識別子に関連付けられた位置情報を含むことができる。

更に、マニフェスト・ファイルは、セグメント間の時間的および／または空間的関係を記述する情報も含むことができる。このようなファイルは、特定のファイル名拡張子、例えば、.mf、.xml、および.n3u8を使用して格納および識別することができる。次いで、クライアントはＨＴＴＰ ＧＥＴ要求を送り、サーバからマニフェスト・ファイルを得ることができる（ステップ１０４）。応答して、サーバはマニフェスト・ファイルをクライアントに送ることによって応答することができる（ステップ１０６）。その後、クライアントはマニフェスト・ファイルを解析して、要求されたビデオに関連付けられたセグメントの位置を得る（ステップ１０８）。

クライアントは、ビデオの第１セグメントを、マニフェスト・ファイルに記載された位置に要求し、サーバは、要求されたセグメントをクライアントに送ることによって、この要求に応答する（ステップ１１０，１１２）。マニフェスト・ファイルに基づいて、様々なセグメントを抽出することができる（ステップ１１４，１１６）。次いで、ある時間量の後、クライアントは、マニフェスト・ファイルを更新する時間であると判断することができ（例えば、既定のタイマが満了したこと、またはクライアントがライブ・ストリームにおいてマニフェスト・ファイルの終端にほぼ達したことに基づいて）、最初のマニフェストを取得した同じ位置に要求を送ることができる（ステップ１１８）。その後、更新されたマニフェスト・ファイルがクライアントに送られ（ステップ１２０）、更新されたマニフェスト・ファイルの解析を開始することによって、再度クライアントによって処理することができる。

先に既に論じたように、このような従来のＨＡＳコンテンツ・ストリーミング・システムは、クライアントとサーバとの間におけるストリーミング・プロセスのサーバに基づく制御を許可しない。これは、予測が難しくストリーミング構成の直接適応化が要求される場当たり的状況における制御も許可しない。

図２は、本発明の一実施形態によるクライアントとサーバとの間におけるプロトコル・フローを示す。具体的には、図２は、コンテンツをメディア・サーバ２３２からクライアント２３０にストリーミングするためのＨＴＴＰ適応ストリーミング（ＨＡＳ）プロトコルのような、ストリーミング・プロトコルに関連付けられたプロトコル・フローを示す。

クライアントは、ビデオ・プレイ・アウト機能２４６によるプレイ・アウトのためにストリームを処理するストリーミング・クライアント機能２４８と、制御チャネル・クライアント機能２４４（ＣＣＣＦ）とを含むことができる。同様に、メディア・サーバは、ストリーミング・クライアント機能２４８にメディアをストリーミングするストリーミング・サーバ機能２４２を含むことができる。メディア・サーバは、更に、サーバ２３２内にまたはこれに関連付けられた制御チャネル・サーバ機能（ＣＣＳＦ）、例えば、ＨＡＳ制御チャネル・サーバ機能２３４を含むことができる。ＨＡＳ制御チャネル・サーバ機能２３４は、ＣＣＳＦとＣＣＣＦ２４４との間におけるストリーミング制御チャネル２３６の確立を開始するように構成される。ストリーミング制御チャネルは、クライアントとサーバとの間においてストリーミング制御情報、特に、セグメント化されたコンテンツ２３８のクライアントへのストリーミングの間、サーバから発信してクライアントへのストリーミング制御情報を交換するために使用することができる。

ここでは、本プロセスは図１と同様に開始することができる。即ち、ユーザが、ウェブサイト上においてビデオに対するリンクをクリックし（ステップ２００）、ＵＲＬがマニフェスト・ファイルを指し示す（例えば、リディレクトによって）。クライアントは、サーバからマニフェスト・ファイルを得るためにＨＴＴＰ ＧＥＴ要求を送ることができ、サーバは、マニフェスト・ファイル（この場合、ＸＭＬファイル）をクライアントに送ることによって、それに応答する（ステップ２０２，２０４）。その後、クライアントはマニフェスト・ファイルを解析して、要求されたコンテンツ・ストリームを構成するセグメントの位置を得る（ステップ２０６）。この特定的な事例では、しかしながら、サーバにおけるＣＣＳＦが、チャネル設定情報をマニフェスト・ファイルに挿入するように構成され、これによって、クライアントにおけるＣＣＣＦおよびサーバにおけるＣＣＳＦがストリーミング制御チャネルを設定することができる。

マニフェスト・ファイルに埋め込まれたチャネル設定情報に基づいて、クライアントにおけるＣＣＣＦは、例えば、サーバ−クライアント・ストリーミング制御チャネルを設定するために、チャネル設定要求をサーバにおけるＣＣＳＦに送る（ステップ２０８）。一実施形態では、ＣＣＣＦおよびＣＣＳＦは、ＷｅｂＳｏｃｋｅｔプロトコルおよびチャネル設定情報を使用してクライアントとサーバとの間にストリーミング制御チャネルを設定するように構成されたＨＴＴＰ ＷｅｂＳｏｃｋｅｔＡＰＩを含むことができる。ＷｅｂＳｏｃｋｅｔ接続は、通例、データが容易にファイアウォールおよびＮＡＴを移る(transfer)ように、標準的なＨＴＴＰポート８０および４４３を使用するが、他のポートを使用してもよい。

ＷｅｂＳｏｃｋｅｔプロトコルの使用には、スケーラビリティに対する少ないメッセージ・オーバーヘッド、プロトコル収束およびファイアウォール横断のためのＨＴＴＰの使用、ならびに他のプロトコルのトンネリングの可能性というような、ＣＤＮおよびＨＡＳのコンテキスト内において様々な利点がある。他の実施形態では、セッション開始プロトコル（ＳＩＰ）（http://tools.ietf.org/html/rfc3261）が使用され、この場合、クライアントはＳＩＰユーザ・エージェントを構成することができ、サーバはＳＩＰアプリケーション・サーバとなる。

更に他の実施形態では、拡張可能メッセージングおよびプレゼンス・プロトコル（ＸＭＰＰ）（http://www.ietf.org/rfc/ rfc3920.txt）が使用され、この場合、クライアントはＸＭＰＰクライアントを構成することができ、サーバはＸＭＰＰサーバを構成する。ＳＩＰおよびＸＭＰＰプロトコル・メッセージは双方共、draft-ibc-rtcweb-sip-websocket-00 および draft-moffitt-xmpp-over-websocket-00にしたがって、ＷｅｂＳｏｃｋｅｔをくぐり抜けることができる。異なるプロトコルについての実施形態の更に詳細な説明は、図５Ａから図５Ｃに設けられる。

ストリーミング制御チャネルの設定の間、チャネル・パラメータをＣＣＣＦとＣＣＳＦとの間で交換することができる（ステップ２１０）。更に、クライアントから発信するメッセージを処理する(handle)ために、ＣＣＳＦは専用チャネル処理プロセス（スレッド）を作成することができる（ステップ２１２）。一旦ストリーミング制御チャネルが確立されたなら（２１４）、クライアントは、マニフェスト・ファイルにおいて特定されたストリーミング・セグメントの処理を開始することができる。ストリーミング・プロセスは、ＨＡＳタイプのストリーミング・プロトコルに基づくことができ、ＨＴＴＰ ＧＥＴ要求から開始することができる。ＨＴＴＰ ＧＥＴ要求は、第１セグメントsegment_low-1.aviに関連付けられたＵＲＬを含む（ステップ２１６）。一旦第１セグメントとの配信がＨＴＴＰ ２００ ＯＫ応答によって確認されたなら（ステップ２１８）、クライアントは後続のセグメント segment_high−2.aviを要求することができる（ステップ２２０，２２２）。

次いで、メディア・サーバにおけるＣＣＳＦは、クライアントがそのマニフェスト・ファイルを更新することが必要であると判断することができる。例えば、ＣＣＳＦが可能なサーバの過剰負荷または障害を検出するかもしれない。したがって、ストリーミング制御チャネルを通じて、任意に新たなマニフェスト・ファイルを指し示すＵＲＬを含むマニフェスト更新信号を送ることができる（ステップ２２４）。マニフェスト・ファイル更新信号を受信すると、ＣＣＣＦは新たなマニフェスト・ファイルを要求することができる。新たなマニフェスト・ファイルの受信時に、クライアントは新たなマニフェスト（図示せず）に基づいてストリーミングを継続することもできる。

一実施形態では、マニフェスト・ファイルにおいてチャネル設定情報を転送する代わりに、チャネル設定情報が端末に予めインストールされてもよく、または別の通信チャネルを通じて他の（ネットワーク）ソースから抽出されてもよい。その場合、クライアントがマニフェスト・ファイルを受信すると、図２のステップ２０８から２１４を参照して説明したように、ストリーミング制御チャネルを確立するために、チャネル設定情報を抽出するストリーミング制御チャネル・クライアント機能を作動させる。

他の実施形態では、メディア・サーバがセグメントを多数のクライアントにストリーミングするように構成されてもよく、図２を参照して説明したように、ネットワーク開始、例えば、サーバ開始制御を可能にするために、各クライアントにはそれ自体のストリーミング制御チャネルが関連付けられる。このように、サーバは、ネットワーク・パラメータ、例えば、ネットワーク・トラフィックまたはサーバの処理負荷に基づいて、セグメント化されたコンテンツの多数のクライアントに対するストリーミングを制御することができる。例えば、一特定実施形態では、異なるクライアントが異なる登録、例えば、特別登録および通常登録に関連付けられてもよい。メディア・サーバに関連付けられた負荷均衡化機能２４０が負荷増大を検出すると、ＣＣＳＦにマニフェスト・ファイル更新を開始するように通知することによって、先験的にその負荷を低減することができ、通常クライアント（の少なくとも一部）には、新たなマニフェスト・ファイルが供給され、これらのクライアントに、低レートおよび／または低（より低い）品質に関連付けられたセグメントを要求させる。

マニフェスト・ファイル更新は、種々の方法で実現することができる。一実施形態では、更新されるマニフェスト・ファイルの全体または少なくとも一部が、ストリーミング制御チャネルを通じてクライアントに送られてもよい。別の実施形態では、ＣＣＳＦがマニフェスト更新トリガをクライアントに、具体的には、ＣＣＣＦに送るのでもよく、ＣＣＣＦは、マニフェスト・ファイル更新トリガにおいて識別されるように、更新されたまたは新たなマニフェスト・ファイルを（デフォルト）位置、例えば、元のメディア・サーバ、または新たな位置、例えば、別のメディア・サーバに要求することによって応答する（例えば、ＵＲＬを使用する）。

図３は、本発明の一実施形態によるクライアント側プロセス・フローを示す。具体的には、図３は、セグメントの抽出およびプレイバックのため、ならびに、例えば、図２に示したようなストリーミング制御チャネルを通じてストリーミングのサーバ開始制御を行うためにクライアント上で実行されるプロセスに関連付けられたプロセスを示す。このプロセスは、クライアントが特定のセグメント化されたコンテンツ項目に関連付けられたマニフェスト・ファイルを要求することから開始することができる（ステップ３００）。マニフェスト・ファイルは、セグメント位置だけでなく、ストリーミング制御チャネルを設定するためにクライアントによって使用されるチャネル設定情報（ＷｅｂＳｏｃｋｅｔ ＵＲＬ、および例えば、ＷｅｂＳｏｃｋｅｔサブプロトコル、ＷｅｂＳｏｃｋｅｔバージョン等を示す可能な何らかのプロトコル）も含むことができる。マニフェスト・ファイルをサーバから受信すると、クライアントはこのマニフェスト・ファイルを解析し（ステップ３０１および３０２）、クライアントにおいて少なくとも２つの別のプロセス／スレッド、即ち、セグメントの抽出およびセグメントのプレイバックを処理するためにクライアントにおいてメディア・ストリーミング・クライアント機能によって実行される第１プロセスと、ストリーミング制御チャネルを操作するためにクライアントにおいてＣＣＣＦによって実行される第２プロセスとを開始することができる。クライアントは、マニフェスト・ファイルに記載されたセグメント位置を使用して、セグメントを周期的に抽出し、ビデオの終了が検出されるまで（ステップ３０４）これらを生成する（ステップ３０３）。更に、クライアントは、マニフェスト・ファイルに埋め込まれたチャネル設定情報を使用して、マニフェスト・ファイルに記載されたＵＲＬに基づいてサーバにチャネル設定要求を送り（ステップ３０５）、クライアント、具体的には、クライアントにおけるＣＣＣＦとサーバ、具体的には、サーバに関連付けられたＣＣＳＦとの間にストリーミング制御チャネルを確立する（ステップ３０６）ことができる。次いで、セグメントのストリーミングおよびプレイ・アウトの間、ＣＣＣＦは、サーバからの着信メッセージを求めて、ストリーミング制御チャネルを聴取する（ステップ３０７）。また、ストリーミング制御チャネルは、クライアントからサーバへのデータ送信にも使用することができる。

サーバからの着信メッセージの場合、ＣＣＣＦはマニフェスト更新信号（マニフェスト更新トリガ）が受信されたか否かチェックすることができる（ステップ３０８）。このようなマニフェスト更新信号が受信されていた場合、ＣＣＣＦは更新マニフェスト（元のマニフェストを受信した位置から、またはマニフェスト更新トリガ・メッセージに指定されるＵＲＬから）を要求することができる（ステップ３０９）。更新マニフェスト・ファイルを受信した後、クライアントはそれを解析し（ステップ３０２参照）、セグメント識別子のリストおよび関連する位置情報を更新する。

図４は、本発明の一実施形態によるサーバ側プロセス・フローを示す。具体的には、図４は、セグメントをクライアントにストリーミングするため、そしてストリーミング制御チャネルを使用してストリーミングのネットワーク開始制御を行うためにメディア・サーバ上で実行されるプロセスのプロセス・フローを示す。このプロセスは、例えば、図２を参照して説明したように、メディア・サーバ上にホストされた種々の機能、即ち、ストリーミング・サーバ機能、制御チャネル・サーバ機能、および、任意に、負荷均衡化機能によって実行することができる。これらの機能は、サーバ負荷を監視し、クライアントからのセグメント要求に応答し、ストリーミング制御チャネルをクライアントと共に設定し維持するために１つ以上のプロセスを実行するように構成することができる。

例えば、第１プロセスがメディア・サーバにおけるＣＣＳＦによって実行され、クライアントによってサーバに送られるチャネル設定を求める要求の受信を監視することができる（ステップ４０２）。このような要求が受信された場合、ＣＣＳＦはストリーミング制御チャネルを設定し、チャネル処理プロセスを開始することができ、たとえば、クライアントから発信した情報またはクライアントに送られる情報が適正に処理される。第２プロセスがメディア・ストリーミング・サーバ機能によって実行され、クライアントからのマニフェスト・ファイルおよび／またはセグメントを求める要求の受信を処理することができる（ステップ４００）。このような要求が受信された場合、サーバは要求された情報（セグメントおよび／またはマニフェスト・ファイル）を要求元のクライアントに送ることができる（ステップ４０１）。第３プロセスは、ネットワーク負荷情報および／またはサーバ負荷情報を監視する負荷均衡化機能に関係することができる。負荷が一定の（最大）閾値に達したまたは近づいた場合、マニフェスト・ファイル更新のために１つ以上のクライアントを選択するように、ＣＣＳＦに通知することができる（ステップ４０５）。応答して、ＣＣＳＦはマニフェスト更新トリガを、選択されたクライアントに送ることができる（ステップ４０６）。

例えば、一実施形態では、サーバに関連付けられた負荷均衡機能は、サーバの処理負荷を低減するために、マニフェスト・ファイル更新を開始するように、ＣＣＳＦに通知することができる。更新されたマニフェスト・ファイルは、クライアントに、品質が低い方のセグメントに基づいてストリーミングを継続することを命令する。他の実施形態では、ＣＣＳＦは、サーバの過剰負荷またはサーバ障害を検出し、応答して、１つ以上のクライアントに他のネットワーク・サーバからセグメントを抽出することを命令するために、マニフェスト・ファイル更新を開始することができる。

マニフェスト更新プロセスは、様々な方法で実現することができる。一実施形態では、更新されたマニフェスト・ファイルは、ＣＣＳＦによって、ストリーミング制御チャネルを通じてクライアントにおけるＣＣＣＦに送られるのでもよい。他の実施形態では、ＣＣＳＦがマニフェスト・ファイル更新トリガをクライアントにおけるＣＣＣＦに送るのでもよく、応答して、クライアントは更新されたまたは新しいマニフェスト・ファイルをメディア・サーバに要求する。別の実施形態では、マニフェスト・ファイル更新トリガが、別のメディア・サーバの位置情報、例えば、ＵＲＬを含んでもよく、クライアントが、この位置情報に基づいて、更新されたまたは新しいマニフェスト・ファイルをこの別のメディア・サーバに要求することができる（ステップ４０６）。

図５Ａから図５Ｃは、ネットワーク開始ストリーミング制御を可能にするストリーミング制御チャネルを確立するための種々の非限定的なプロトコル・フローを示す。具体的には、図５Ａは、図２と同様のメッセージ・フローを示し、ここでは、ＨＴＴＰ ＷｅｂＳｏｃｋｅｔプロトコルが、ストリーミング制御チャネルを設定するために使用される。このプロセスは、ユーザが、ウェブサイト上でビデオに対するリンクを選択することから開始することができ（ステップ５００ａ）、ＵＲＬがマニフェスト・ファイルを指し示すことができる（例えば、リディレクトによって）。応答して、クライアントは、マニフェスト・ファイルをサーバから得るために、ＨＴＴＰ ＧＥＴ要求を送ることができ（ステップ５０１ａ）、マニフェスト・ファイルはサーバによってクライアントに（この場合、ＸＭＬファイルの形態で）送られる（ステップ５０２ａ）。

クライアントは、マニフェスト・ファイルを解析して、ビデオを構築するセグメントの少なくとも一部の位置を得て（ステップ５０３ａ）、マニフェスト・ファイルに埋め込まれた情報を使用して、ＷｅｂＳｏｃｋｅｔ設定要求 (HTTP GET WS ws://...)をサーバに送ることができる（ステップ５０４ａ）。強制ＷｅｂＳｏｃｋｅｔハンドシェーク（WS draft draft−ietf−hybi−thewebsocketprotocol−17に詳細に説明されるように）を実行した後、サーバは、ＨＴＴＰ １０１ ＳＷＩＴＣＨＩＮＧ ＰＲＯＴＯＣＯＬＳメッセージを使用して、クライアントからのＷｅｂＳｏｃｋｅｔ要求を受け入れることができる（ステップ５０５ａ）。次いで、着信メッセージを処理してＷｅｂＳｏｃｋｅｔを作成するために、サーバは専用プロセス／スレッドを作成し（ステップ５０６ａ）、これによってＷｅｂＳｏｃｋｅｔストリーミング制御チャネルを確立する。このＷｅｂＳｏｃｋｅｔストリーミング制御チャネルは、サーバ開始ストリーミング制御を行うために使用することができる（ステップ５０７ａ）。

ＷｅｂＳｏｃｋｅｔプロトコルは、ベスト・エフォート・インターネット接続における全二重双方向通信に対応する(allow for)。サーバおよびクライアント双方がいずれの時点でも、ストリーミング制御チャネル上で同時にでもデータを送ることができる。ＨＴＴＰヘッダのオーバーヘッドがないデータのみが送られることによって、帯域幅を劇的に広げる。更に、ＷｅｂＳｏｃｋｅｔはＨＴＴＰベース・プロトコルであるので、通常、ファイアウォールまたはネットワーク・アドレス変換器（ＮＡＴ）によって自動的に阻止されない。

図５Ｂは、図２と同様に、ＳＩＰプロトコルを使用してストリーミング制御チャネルを設定するためのメッセージ・フローを示す。このプロセスは、ユーザが、ウェブサイト上であるビデオに対するリンクを選択することから開始することができる（ステップ５００ｂ）。応答して、クライアントは、ＨＴＴＰ ＧＥＴ要求を送って、マニフェスト・ファイルをサーバから得ることができ（ステップ５０１ｂ）、ＵＲＬがマニフェスト・ファイルを指し示すことができる（例えば、リディレクトによって）。マニフェスト・ファイルは、サーバによって（この場合、ＸＭＬファイルの形態で）クライアントに送られる（ステップ５０２ｂ）。

クライアントは、マニフェスト・ファイルを解析して、ビデオを構成するセグメントの位置を得て（ステップ５０３ｂ）、マニフェスト・ファイルに埋め込まれた情報を使用して、ＳＩＰ ＩＮＶＩＴＥメッセージをＳＩＰアプリケーション・サーバに送ることができる（ステップ５０４ｂ）。この情報は、セッション記述プロトコル・メッセージ[http://www.ietf.org/rfc/rfc4566.txt]としてフォーマットすることができる。サーバは、ＩＮＶＩＴＥメッセージを受け入れ、ＳＩＰ ２００ ＯＫメッセージで応答する（ステップ５０５ｂ）。次いで、着信メッセージを処理してＳＩＰセッションを作成するために、サーバは専用プロセス／スレッドを作成し（ステップ５０６ｂ）、これによってＳＩＰベース・ストリーミング制御チャネルを確立する。このＳＩＰベース・ストリーミング制御チャネルは、サーバ開始ストリーミング制御を行うために使用することができる（ステップ５０７ｂ）。

図５Ｃは、図２と同様に、ＸＭＰＰプロトコルを使用してストリーミング制御チャネルを設定するためのメッセージ・フローを示す。このプロセスは、ユーザが、ウェブサイト上であるビデオに対するリンクを選択することから開始することができ（ステップ５００ｃ）、ＵＲＬがマニフェスト・ファイルを指し示すことができる（例えば、リディレクトによって）。応答して、クライアントは、ＨＴＴＰ ＧＥＴ要求を送って、マニフェスト・ファイルをサーバから得ることができる（ステップ５０１ｃ）。マニフェスト・ファイルは、サーバによって（この場合、ＸＭＬファイルの形態で）クライアントに送られる（ステップ５０２ｃ）。

クライアントは、マニフェスト・ファイルを解析して、ビデオを構成するセグメントの位置を得て（ステップ５０３ｃ）、ＸＭＰＰサーバのJabber Identifier（ＪＩＤ）のようなマニフェスト・ファイルに埋め込まれた情報を使用して、ＸＭＰＰセッション要求メッセージを、１つ以上のXML Stanzasの形態でＸＭＬストリーム上でＸＭＰＰサーバに送ることができる（ステップ５０５ｃ）。ＸＭＰＰサーバは、このセッション要求メッセージを受け入れて、セッション作成結果メッセージで応答する（ステップ５０６ｃ）。次いで、 着信メッセージを処理してＸＭＰＰセッションを作成するために、サーバは専用プロセス／スレッドを作成し（ステップ５０７ｃ）、これによってＸＭＰＰベース・ストリーミング制御チャネルを確立する。ＸＭＰＰベース・ストリーミング制御チャネルは、サーバ開始ストリーミング制御を行うために使用することができる（ステップ５０８ｃ）。

図６は、本発明の一実施形態にしたがって、セグメント化されたコンテンツをクライアントに配信するコンテンツ・ストリーミング・システム６００を示す。具体的には、図６はＣＤＮを含むコンテンツ配信システムのアーキテクチャ全体像を示す。ＣＤＮは、ＣＤＮにおける１つ以上の配信ノードと１つ以上のクライアントとの間においてネットワーク開始制御ストリーミング・プロセスを設けるように構成される。ネットワーク開始制御は、図２から図５を参照して説明したストリーミング制御チャネル機能性に基づいて実現することができる。

この実施形態では、クライアント配信システムは、少なくとも１つのコンテンツ配信ネットワーク（ＣＤＮ）６０２、トランスポート・ネットワーク６００を介して１つ以上のクライアント６０３に結合されたコンテンツ・ソース（ＣＳ）６０１を含むことができる。コンテンツ・ソースは、コンテンツ提供システム（ＣＰＳ）、コンテンツ準備システム、または他のＣＤＮに関係することができる。ＣＰＳは、コンテンツ、例えば、オーディオ項目またはビデオ・タイトルを顧客に提供するように構成することができ、顧客は、クライアントを使用して、コンテンツを購入し受信することができる。

クライアントには、端末、即ち、コンテンツ処理デバイス、例えば、電子タブレット、スマート・フォン、ノートブック、メディア・プレーヤ等というような、（移動体）コンテンツ・プレイ・アウト・デバイス上で実行するソフトウェア・プログラムを実装することができる。実施形態では、端末がコンテンツ・プレイ・アウト・プレーヤによる今後の消費のためにコンテンツを処理し一時的に格納するように構成されたセット・トップ・ボックスまたはコンテンツ記憶デバイスであってもよい場合もある。

ＣＤＮは、配信ノード（ＤＮ１，ＤＮ２）６１１，６１２、および少なくとも１つの中央ＣＤＮノード（ＣＣＮ）６１０を含むことができる。各配信ノードは、コントローラ６３０、６３１、ならびにコンテンツを格納およびバッファリングするキャッシュ６３２、６３３を含む、またはこれらと関連付けることができる。各ＣＣＮは、外部ソース、例えば、コンテンツ提供者または他のＣＤＮからのコンテンツの収集を制御する収集機能（またはコンテンツ起点ノード、ＣＯＦ(content origin function)６２０、コンテンツがＣＤＮ内部のどこに格納されているかについての情報を維持するコンテンツ位置データベース６２２、およびコンテンツの１つ以上のコピーの配信ノードに対する配給を制御し、更にクライアントをしかるべき配信ノードにリディレクトする（要求ルーティングとしても知られるプロセス）ＣＤＮ制御機能（ＣＤＮＣＦ）６２１を含むことができ、あるいはこれらと関連付けることができる。配給は、ＣＤＮ全域にわたって、クライアントに対するコンテンツ配信に十分な帯域幅が保証されるように制御することができる。一実施形態では、ＣＤＮは、 ETSI TS 182 019に記載されるように、ＣＤＮに関係することができる。

顧客は、要求をウェブ・ポータル（ＷＰ）６６１に送ることによって、セグメント化されたコンテンツ、例えば、ビデオ・タイトルをＣＰＳ６６０から購入することができる。ウェブ・ポータル６６１は、購入可能なビデオ・タイトルを識別するタイトル参照を供給するように構成される。この要求に応答して、クライアントは、タイトル参照の少なくとも一部をＷＰから受信し、そして選択されたコンテンツを配信することができるＣＤＮのＣＤＮＣＦの位置情報、例えば、ＵＲＬを受信することができる。

ＣＤＮＣＦは、選択されたコンテンツをクライアントに配信するように構成される１つ以上の配信ノードに関連付けられたクライアント位置情報を送ることができる。セグメントは、ＣＤＮにおける１つの配信ノード上にホストされても、あるいは代わりにＣＤＮにおける複数の異なる配信ノードにホストされてもよい。例えば、人気が高いセグメントは、ＣＤＮにおける多数の配信ノード上にホストされ、適時の配信を保証できるようにするとよい。通例、ＣＤＮＣＦは、選択されたコンテンツをクライアントに配信するのに最も適した配信ノードをＣＤＮにおいて選択することができる。１つ以上の配信ノードを選択する判断基準は、配信ノードの処理負荷、および／またはクライアントに関連付けられたコンテキスト情報、例えば、クライアントの位置（ＩＰアドレス）および／またはクライアントの登録（例えば、図２を参照して先に説明したような特別登録および通常登録）に基づくことができる。したがって、このように、ＣＤＮＣＦは動的にマニフェスト・ファイルを生成することができ、マニフェスト・ファイルは、セグメントをクライアントに効率的に配信するために最適化される。

クライアントは、例えば、従来のＤＮＳシステムを使用して、ＣＤＮにおける配信ノードに連絡することができる。更に、コンテンツをメディア・ストリーミング機能６５２に配信するためには種々のストリーミング・プロトコルを使用することができる。メディア・ストリーミング機能６５２は、ビデオ・プレイ・アウト機能６５１によるプレイ・アウトのためにストリームを処理する。このようなプロトコルは、ＨＴＴＰおよびＲＴＰ／ＲＴＣＰ型ストリーミング・プロトコルを含むことができる。好ましい実施形態では、ＨＴＴＰ適応ストリーミング（ＨＡＳ）のような適応ストリーミング・プロトコル、およびApple社のＨＴＴＰライブ・ストリーミング、Microsoft Smooth Streaming、Adobe社のＨＴＴＰ動的ストリーミング、３ＧＰＰ−ＤＡＳＨ、およびＨＴＴＰ上ＭＰＥＧ動的適応ストリーミングというような関連プロトコルを使用することができる。

ＣＤＮは、セグメント化されたコンテンツを収集し配給するように構成される。既知のセグメント化ストリーミング・システムは、ＨＴＴＰ適応ストリーミング（ＨＡＳ）のような、時間セグメント化に基づくことができる。この場合、コンテンツは、多数のセグメント（断片または部分）に編成することができ、セグメントは、ＭＰＥＧまたはＡＶＩのような既知のトランスポート・コンテナ・フォーマットにしたがってフォーマットすることができる。

セグメント間の関係は、マニフェスト・ファイル内に記述することができ、マニフェスト・ファイルは、特定のファイル名拡張子、例えば、.mf、.xml、および.m3u8を使用して格納および識別することができる。マニフェスト・ファイルは、更に、１つ以上の配信ノード上における異なるセグメントの位置および名前（セグメント識別子）を記述することもできる。セグメント、特に、人気のあるセグメントは、ＣＤＮにおける１つよりも多い配信ノードから配信されてもよい。更に、ある状況では、セグメントは、他のＣＤＮドメインにおける配信ノードから抽出されなければならないこともある。この状況については、図１２および図１３を参照して更に詳しく説明する。ＣＤＮＣＦは、セグメントを抽出することができる位置を管理することができる。このために、ＣＤＮＣＦはコンテンツ位置データベース６２２を使用することができる。一実施形態では、コンテンツ位置データベースは、 ETSI TS 182 019に記載されるように、アセット位置検出機能（ＡＬＦ）に関係することができる。

更に、ＣＤＮは配信連続ノード（ＤＣＮ）６１３も含むことができる。配信連続ノード６１３は、クライアントに関連付けられたストリーミング制御チャネルを設定し管理し、更にクライアントと、これらのクライアントが接続される配信ノード（１つまたは複数）を含むデータベースを維持するように構成される。ＤＣＮは、配信連続管理機能（ＤＣＭＦ）６４０を含むことができる。この機能は、ＣＤＮＣＦの要求−ルーティング（ＲＲ）機能から発する通知を監視するプロセスを実行することができる。ＤＣＮは、更に、クライアントからのチャネル設定要求を監視し、クライアントにおける制御チャネル・クライアント（ＣＣＣＦ）機能６５０と共にストリーミング制御チャネルを設定するために、ＤＣＮにおいて制御チャネル・サーバ機能（ＣＣＳＦ）６４１を含むことができる。

更に、ＤＣＮ内におけるまたはＤＣＮに関連付けられた配信連続（ＤＣ）データベース６４２は、クライアント情報（例えば、そのＩＰアドレス）およびマニフェスト・ファイル情報（即ち、セグメント識別子（例えば、ファイル名）およびこれらのセグメントをホストする配信ノードの少なくとも一部）を格納することができる。配信連続管理機能（ＤＣＭＦ）は、ＣＤＮＣＦまたはＣＤＮにおける別のネットワーク監視機能から発するネットワーク通知、例えば、（過剰）負荷通知または障害通知を監視し、このようなネットワーク通知の受信に応答してマニフェスト・ファイル更新プロセスを開始することができる。ＤＣＮにおけるプロセスおよび機能についての詳細については、図８を参照して説明する。

図６では、ＤＣＮにおける機能、即ち、ＤＣＭＦおよびＣＣＳＦが別のノード（ＤＣＮ）上に実装されるが、別の実施形態では、これらの機能がＣＤＮＣＦおよび収集機能を含むＣＣＮ６１０上において完全にまたは部分的に実装されてもよい。

図７は、本発明の一実施形態によるコンテンツ・ストリーミング・システムにおける使用のためのメッセージ・フローを示す。具体的には、図７は、ＣＤＮにおける１つ以上の配信ノードと１つ以上のクライアントとの間におけるストリーミング・プロセスのネットワーク開始制御を行うように構成されたＣＤＮ型コンテンツ・ストリーミング・システムにおける使用のためのメッセージ・フローを示す。この実施形態では、ＣＤＮは、少なくとも第１および第２配信ノード（ＤＮ１、ＤＮ２）、ならびに図６を参照して説明したようなＣＤＮＣＦ、ＤＣＭＦ、およびＣＣＳＦを含むＣＣＮを含むことができる。

図７におけるプロセスは、ユーザが、ウェブサイト上においてあるビデオに対するリンクを選択することから開始することができ（ステップ７００）、ＵＲＬがマニフェスト・ファイルを指し示すことができる（例えば、リディレクトによって）。選択するとき、クライアントは、ＨＴＴＰ ＧＥＴ要求をＣＤＮＣＦに送ってマニフェスト・ファイルを得ることができる（ステップ７０１）。ＣＤＮＣＦは、マニフェスト・ファイルをクライアントに送ることによって、この要求に応答することができる（ステップ７０２）。この場合、負荷均衡化機能からの情報に基づいて、ＣＤＮＣＦは、第１配信ノードＤＮ１上に格納されたセグメントに対する参照（例えば、セグメント識別子および／または関連する位置情報）を収容するマニフェスト・ファイルを選択および／または生成することができる。更に、ＣＤＮＣＦは、特定のクライアント（例えば、そのＩＰアドレスによって定められる）に、特定の（１組の）配信ノード（１つまたは複数）（この例では、配信ノードＤＮ１）に対する参照を収容するマニフェスト・ファイルを送ったという事実を記す。このために、ＣＤＮＣＦは、ビデオ・タイトルの少なくとも一部に関連付けられたクライアント情報（例えば、クライアントのＩＰアドレス）およびマニフェスト・ファイル情報（例えば、マニフェスト・ファイル識別子、マニフェストＩＤ）と、配信連続（ＤＣ）データベースにおいてマニフェスト・ファイルによって参照されるセグメントをホストする特定の（１組の）配信ノード（１つまたは複数）の位置情報とを今後の使用のために格納することができる（ステップ７０３）。

ここでは、マニフェスト・ファイル情報は、番号によって識別することができ、配信ノードは、ＣＤＮ内部で知られる配信ノードによって識別することができる。クライアントは、マニフェスト・ファイルを解析して、ビデオを構成するセグメントの位置（例えば、ＵＲＬ）を得ることができる（ステップ７０４）。更に、クライアントにおけるＣＣＣＦは、マニフェスト・ファイルにおけるチャネル設定情報を使用して、ＣＣＣＦとＣＤＮにおけるＣＣＳＦとの間においてストリーミング制御チャネルを設定ことができる（ステップ７０５ａ）（ＣＣＣＦとＣＣＳＦとの間にストリーミング制御チャネルを設定するプロセスは、図２および図３を参照して説明したので、ここでは繰り返さない）。

ストリーミング制御チャネルを確立する間、ＣＣＳＦは、ＤＣデータベースに格納された情報を使用して、チャネル設定要求を、特定のクライアントおよび１つ以上の関連する配信ノードに相関付けることができる（ステップ７０５ｂ）。具体的には、ＣＣＳＦがＤＣデータベースに問い合わせて、ストリーミング制御チャネルが設定されるクライアントを求め（クライアントは、例えば、そのＩＰアドレスによって識別することができる）、一意のストリーミング・チャネル識別子、即ち、チャネルＩＤ（例えば、ポート番号、またはＷｅｂＳｏｃｋｅｔが使用される場合は、ＷｅｂＳｏｃｋｅｔＩＤ）を、当該クライアントに所属するデータベース・エントリに割り当てることができる。このように、ＣＣＳＦは、特定のクライアント−チャネルの組み合わせと特定の（１組の）配信ノード（１つまたは複数）および／またはマニフェスト・ファイルに関係付けることができる。

一旦ストリーミング制御チャネルが設定されたなら、クライアントは、第１セグメント（この場合、segment_low-1）を第１配信ノードＤＮ１（マニフェスト・ファイルにおいて参照される）に要求することによって、ストリーミング・プロセスを開始することができる（ステップ７０６）。配信ノードＤＮ１は、要求されたセグメントをクライアントにストリーミングすることによって応答することができる（ステップ７０７）。

ストリーミング・プロセスの間、ある時点において、ＣＤＮＣＦ（ＣＤＮにおける配信ノードの負荷を監視する負荷均衡機能を含むまたはそれと関連付けられる）は、第１配信ノードＤＮ１上の負荷が（最大）閾値に近づくことを注意することができる（ステップ７０８）。ＣＤＮＣＦは、ＣＤデータベースに格納された情報をチェックすることによって、どのクライアントが第１配信ノードＤＮ１を使用しているのかチェックするように、ＤＣＭＦに通知することができる（ステップ７０９）。次いで、ＤＣＭＦは、第１配信ノードＤ１の処理負荷が低減されるように、一部（または全部）のクライアントを第１配信ノードＤＮ１から他の第２配信ノードＤＮ２にリディレクトすることを決定することができる。このために、ＤＣＭＦは、ＤＣデータベースにおける情報を使用して、ＣＣＳＦにＤＣＭＦによって選択されたクライアントのストリーミング制御チャネルを通じてマニフェスト更新トリガを送るように命令することができる（ステップ７１０）。

マニフェスト更新トリガを受信すると、クライアントにおけるＣＣＣＦは、マニフェスト要求をＣＤＮＣＦに送ることによって、新たなまたは更新されたマニフェスト・ファイルを要求するように作動される（ステップ７１１）（ステップ７０１を参照して説明したのと同様に）。ＣＤＮＣＦは、マニフェスト要求を受け、クライアントのために新たなまたは更新されたマニフェスト・ファイルを選択または生成し、このマニフェスト・ファイルをクライアントに送ることができる。

一実施形態では、新たなまたは更新されたマニフェスト・ファイルを生成するとき、ＣＤＮＣＦは新たな配信ノードを選択するために、負荷均衡化機能からの情報を使用することができる（ステップ７０２も参照のこと）。更に、新たなまたは更新されたマニフェスト・ファイルは、第２配信ノードＤＮ２上に格納されたセグメントに対するリンクを収容することもできる。

一実施形態では、マニフェスト更新トリガは、新たなまたは更新されたマニフェスト・ファイルを含む別のノードを識別する位置情報、例えば、ＵＲＬを含むことができる。他の実施形態では、新たなまたは更新されたマニフェスト・ファイルを抽出するようにクライアントに通知するためにマニフェスト更新トリガを送る代わりに、新たなまたは更新されたマニフェスト・ファイルを直接ストリーミング制御チャネルを通じてクライアントに送信することもできる。更新マニフェスト・ファイルがクライアントに返送された後、クライアントは新たなまたは更新されたマニフェスト・ファイルを使用して、第２配信ノード（図示せず）からセグメントのストリームを再開する。

クライアントは新たなまたは更新されたマニフェスト・ファイルを受信したので、ＣＤＮＣＦは、７０３を参照して説明したようにこのステップを実行することによって、ＤＣデータベースにおいてそのクライアントに関連付けられたマニフェスト・ファイル情報を更新することができる。このように、今後のある時点において、過剰負荷の問題が発生した場合、ＣＤＮＣＦはクライアントを再度他の配信ノードにリディレクトすることができるとよい。

図８は、本発明の一実施形態による配信連続ノード（ＤＣＮ）に関連付けられたプロセス・フローを示す。具体的には、図８は、図６を参照して説明したような配信連続ノード（ＤＣＮ）上にホストすることができる１つ以上の機能の全体像を示す。ＤＣＮは、クライアントに関連付けられたストリーミング制御チャネルを設定および管理し、クライアントとこれらが接続される配信ノード（１つまたは複数）とを列挙する表を維持するように構成することができる。他の実施形態では、ＤＣＮに関連付けられた機能の全部または少なくとも一部がＣＣＮ上にホストされるのでもよい（図７、図９、図１１、および図１３参照）。

ＤＣＮは、配信連続管理機能（ＤＣＭＦ）を含むことができる。この機能は、ＣＤＮＣＦの要求−ルーティング（ＲＲ）機能から発する通知を監視するプロセスを実行することができる（ステップ８００）。ＣＤＮＣＦがマニフェスト・ファイルをクライアントに送るときはいつでも、またはクライアントを特定の配信ノードにリディレクトするときはいつでも、ＣＤＮＣＦは、どの配信ノードからクライアントがセグメントを抽出することを予想されるかＤＣＮに通知することができる（即ち、クライアントに送られたマニフェスト・ファイルにおいて参照される配信ノード、またはクライアントがリディレクトされる配信ノード）。この通知を受信すると、ＤＣＮは、特定のクライアント（例えば、そのＩＰアドレスによって識別される）を、そのクライアントに送られたマニフェスト・ファイルにおいて参照される配信ノードの少なくとも一部に割り当てるエントリを配信連続（ＤＣ）データベースに追加することができる（ステップ８０１）。

更に、制御チャネル・サーバ機能（ＣＣＳＦ）は、クライアントにおけるＣＣＣＦからのチャネル設定要求を監視することができる（ステップ８０２）。要求を受信した場合、適したプロトコル、例えば、ＷｅｂＳｏｃｋｅｔ、ＳＩＰ、またはＸＭＰＰに基づいて、ストリーミング制御チャネルを設定するプロセスを開始する。

ストリーミング制御チャネルの確立の間、ＣＣＳＦはＤＣデータベースに問い合わせ、ストリーミング制御チャネルが設定されるクライアント（クライアントは、例えば、そのＩＰアドレスによって識別することができる）を求め、一意のストリーム・チャネル識別子（例えば、ポート番号、またはＷｅｂＳｏｃｋｅｔが使用される場合、ＷｅｂＳｏｃｋｅｔ ＩＤ）を、そのクライアントに所属するデータベース・エントリに割り当てることができる（ステップ８０３）。ＤＣＭＦは、次いで、ネットワーク通知、例えば、ＣＤＮＣＦ、ＣＤＮＣＦに関連付けられた負荷均衡化機能、または別のネットワーク監視機能からのネットワーク過剰負荷通知または障害通知を監視する監視プロセスを実行することができる（ステップ８０４）。一実施形態では、過剰負荷または障害通知は、ＣＤＮＣＦがリディレクトを望むクライアントの数に関する情報を含むこともできる。

一旦ＤＣＭＦがこのような通知（それ自体における配信ノードまたは他のＣＤＮ（図示せず）における配信ノードに関する）をＤＣＮＣＦから受信したなら、ＤＣデータベースに問い合わせて、過剰負荷または障害通知に関連付けられた配信ノードからセグメントを抽出することが予想されるクライアントをチェックすることができる（ステップ８０５）。ＤＣＭＦは、次いで、リディレクトすべき１つ以上のクライアントを選択することができる（ステップ８０６）（この選択は、ステップ８０４を参照して先に説明したように、リディレクトされるべきクライアントの数に基づくことができる）。その後、ＤＣＭＦは、そのデータベースに問い合わせて、選択されたクライアントに関連付けられたストリーミング・チャネル（例えば、ストリーミング・チャネル識別子を使用する）を識別し、これらのチャネルの各々を通じてマニフェスト・トリガを送ることができる。

ＤＭＣＦは、更に、クライアントから発信するメッセージを監視するように構成することもできる。一実施形態では、ＤＭＣＦが新たなまたは更新されたマニフェスト・ファイルを、ストリーミング制御チャネルを通じて、クライアントに送るのでもよい。

図９は、本発明の他の実施形態によるコンテンツ・ストリーミング・システムにおける使用のためのメッセージ・フローを示す。具体的には、図９は、図７と同様のコンテンツ配信システムとの使用のためのメッセージ・フローを示す。この実施形態では、しかしながら、マニフェスト・ファイルは、ＣＤＮＣＦによってクライアントに配信されるのではなく、配信ノード自体によって配信される。このために、配信ノード、例えば、第１配信ノードＤＮ１は、その配信ノード上のセグメントに対する参照だけを含むマニフェスト・ファイルを含むことができる。

図９におけるプロセスは、ユーザが、ウェブサイト上であるビデオに対するリンクを選択することから開始することができ（ステップ９００）、ＵＲＬがＣＤＮＣＦの要求ルーティング（ＲＲ）機能を指し示す（例えば、コンテンツ・プロバイダからのリディレクトによって）。クライアントがＨＴＴＰ ＧＥＴ要求をＣＤＮＣＦに送った後（ステップ９０１）、ＣＤＮＣＦのＲＲ機能が、例えば、負荷均衡化機能から得られた情報に基づいて、要求されたマニフェスト・ファイルおよび関連するセグメント化されたコンテンツをクライアントに配信するのに適した配信ノードを選択することができる。ＣＤＮＣＦは、次いで、クライアントに、選択された配信ノード（この特定的な例では、第１配信ノードＤＮ１）上のマニフェスト・ファイルへのＵＲＬを収容するＨＴＴＰ ＲＥＤＩＲＥＣＴメッセージを送ることができる（ステップ９０２）。

ＨＴＴＰ ＧＥＴ要求をリディレクトするとき、ＣＤＮＣＦはクライアント情報（例えば、クライアントのＩＰアドレス）およびマニフェスト・ファイル情報（例えば、ビデオ・ファイルの少なくとも一部に関連付けられたマニフェスト・ファイル識別子、またはマニフェストＩＤ、およびマニフェスト・ファイルによって参照されるセグメントをホストする特定の（１組の）配信ノード（１つまたは複数））を、今後の使用のために配信連続（ＤＣ）データベースに格納することができる（ステップ９０３）。ここでは、マニフェスト・ファイル識別子は、数値によって識別することができ、配信ノードは、ＣＤＮ内部において知られている配信ノード識別子によって識別することができる。

ＣＤＮＣＦからＨＴＴＰ ＲＥＤＩＲＥＣＴメッセージを受信すると、クライアントは新たなＨＴＴＰ ＧＥＴ要求メッセージを、第１配信ノードに関連付けられたＲＥＤＩＲＥＣＴメッセージにおけるＵＲＬに送ることができる（ステップ９０４）。配信ノードＤＮ１は、続いて、要求されたマニフェスト・ファイルをクライアントに送ることによって、応答する（ステップ９０５）。

マニフェスト・ファイルを受信した後、クライアントはこのマニフェスト・ファイルを解析して、ビデオを構成するセグメントの位置を得ることができる（ステップ９０６）。クライアントにおけるＣＣＣＦは、マニフェスト・ファイルにおけるチャネル設定情報を使用して、ＣＣＳＦとクライアントとの間にストリーミング制御チャネルを設定することができる（ステップ９０７ａ）（チャネルを設定するプロセスは、図２および図３において説明したので、ここでは繰り返さない）。

ストリーミング制御チャネルの確立の間、ＣＣＳＦは、ＤＣデータベースに格納された情報を使用することによって、チャネル設定要求を特定のクライアントおよび関連する配信ノードと相関付けることができる（ステップ９０７ｂ）。具体的には、ＣＣＳＦはＤＣデータベースに問い合わせて、ストリーミング制御チャネルが設定されるクライアント（このクライアントは、例えば、そのＩＰアドレスによって識別することができる）を求め、一意のストリーミング・チャネル識別子（例えば、ポート番号、またはＷｅｂＳｏｃｋｅｔが使用される場合、ＷｅｂＳｏｃｋｅｔ ＩＤ）を、クライアントに所属するデータベース・エントリに割り当てることができる。このように、ＣＤＮにおける機能は、どのクライアント／チャネルの組み合わせが、どの（１組の）配信ノード（１つまたは複数）を使用しているのかチェックすることができる（例えば、この場合、ＣＤＮＣＦは、特定のクライアントが第１配信ノードＤＮ１を使用しており、特定のマニフェスト・ファイルを受信したことをチェックすることができる）。

一旦ストリーミング制御チャネルが設定されたなら（例えば、図２および図３において説明したように）、クライアントは、第１配信ノードＤＮ１から得られるセグメントを要求し、受信し、プレイ・アウトし始めることができる（ステップ９０８）。ストリーミング・プロセスの間、ある時点において、ＣＤＮＣＦ（ＣＤＮにおける配信ノードの負荷を監視するために負荷均衡化機能を含む、またはこれに関連付けられる）は、第１配信ノードＤＮ１上の負荷が所定の（最大）閾値レベルに達することを通知することができる（ステップ９０９）。ＣＤＮＣＦは、次に、ＤＣＭＦを作動させて、ＤＣデータベースに格納された情報をチェックすることによって、どのクライアントが第１配信ノードＤＮ１に関連付けられているか判定することができる（ステップ９１０）。この情報に基づいて、ＤＣＭＦは、一部（または全部）のクライアントを第１配信ノードＤＮ１から離れるようにリディレクトすることを決定することができる。

このために、ＣＣＳＦを作動させて、これらのクライアントの制御チャネルを通じてマニフェスト更新トリガを送ることができる（ステップ９１１）。クライアントがそれらの更新マニフェストを第１配信ＤＮ１（デフォルトとして）を受信しないことを確実にするために、マニフェスト更新トリガは、新たなまたは更新されたマニフェスト・ファイルに関連付けられたＵＲＬを含むことができる（例えば、第２配信ノードＤＮ２を指し示す）。マニフェスト更新トリガの受信は、クライアントに、新たなマニフェスト・ファイルを要求しなければならないことを伝える。次いで、マニフェスト・ファイル要求を、マニフェスト更新トリガにおいて参照された第２配信ノードＤＮ２に関連付けられたＵＲＬに送ることができる（ステップ９１２）。第２配信ノードＤＮ２は、要求されたマニフェスト・ファイルをクライアントに送ることによって応答することができる。

このマニフェスト・ファイルを受信すると、クライアントは、後続のセグメントを、第１配信ノードＤＮ１の代わりに、第２配信ノードＤＮ２に要求することによって、ストリーミング・プロセスを継続することができる（ステップ９１３）。クライアントは新たなまたは更新されたマニフェスト・ファイルを受信したので、ＣＤＮＣＦは、９０３を参照して説明したステップを実行することによって、ＤＣデータベースにおいて、そのクライアントに関連付けられたマニフェスト・ファイル情報を更新することができる。このように、今後のある時点において過剰負荷の問題が発生した場合、ＣＤＮＣＦはクライアントを再度他の配信ノードにリディレクトすることができると考えられる。

したがって、図９に示す実施形態では、クライアントとＣＣＳＦとの間にストリーミング制御チャネルを設定するためのチャネル設定情報を含むマニフェスト・ファイルが、セグメントが格納された配信ノードに格納される。この実施態様では、ＣＤＮＣＦの負荷および複雑さの一部が複数の配信ノードに肩代わりされるという利点がある。図７では、ＣＤＮＣＦは、マニフェスト・ファイルが更新される毎に負荷がＣＤＮＣＦに追加されるように、マニフェスト・ファイルをホストし、および／または生成する。ある種の実施態様では、例えば、生コンテンツの場合、クライアント開始マニフェスト更新は、非常に頻繁に、例えば、３０秒毎に１回起こる場合もあり、これによってＣＤＮＣＦにかかる負荷が増大する。したがって、クライアント開始マニフェスト要求に応答するタスクを、配信ノードに委託することによって、ＣＤＮＣＦの相当な負荷低減を実現することができる。

図１０は、本発明の更に他の実施形態によるコンテンツ・ストリーミング・システムにおける使用のためのメッセージ・フローを示す。具体的には、図１０は、図７と同様のメッセージ・フローを示すが、ＤＣＮ機能性をＣＤＮＣＦに追加させる代わりに、ＣＤＮが別のノードに配置される。

図１０におけるプロセスは、ユーザが、ウェブサイト上であるビデオに対するリンクを選択し（ステップ１０００）、およびＣＤＮＣＦからマニフェスト・ファイルを得るためにクライアントによって送られるＨＴＴＰ ＧＥＴ要求の送信（ステップ１００１）から開始することができ、ＵＲＬがＣＤＮＣＦ上にホストされたマニフェスト・ファイルを指し示すことができる（例えば、リディレクトによって）。ＣＤＮＣＦは、マニフェスト・ファイルをクライアントに送ることによって、この要求に応答することができる。この例では、負荷均衡化機能から得られた情報に基づいて、ＣＤＮＣＦは、第１配信ノードＤＮ１上に格納されたセグメントに対する参照を収容するマニフェスト・ファイルを選択することができる（ステップ１００２）。

ＣＤＮＣＦは、ＤＣＮに、具体的には、ＤＣＮにおけるＤＣＭＦに、特定のクライアント（例えば、そのＩＰアドレスによって識別される）に、特定の（１組の）配信ノード（１つまたは複数）に対する参照を含む新たなまたは更新されたマニフェスト・ファイルが供給されたことを示す通知を送ることができる（ステップ１００３）。ＤＣＭＦは、クライアント情報（例えば、クライアントのＩＰアドレス）およびマニフェスト・ファイル情報（例えば、ビデオ・ファイルの少なくとも一部に関連付けられたマニフェスト・ファイル識別子、またはマニフェストＩＤ、およびマニフェスト・ファイルによって参照されたセグメントをホストする特定の（１組の）配信ノード（１つまたは複数）の位置情報）を、今後の使用のためにＤＣデータベースに格納することができる（ステップ１００４）。ここでは、マニフェスト・ファイル識別子は数値によって識別することができ、配信ノードは、ＣＤＮ内部において知られている配信ノード識別子によって識別することができる。

クライアントは、マニフェスト・ファイルを解析して、ビデオを構成するセグメントの位置（例えば、ＵＲＬ）を得ることができる（ステップ１００５）。更に、クライアントは、マニフェスト・ファイルにおけるチャネル設定情報を使用して、ＣＤＮへのチャネルを設定することができる（ステップ１００６ａ）。（チャネルを設定するプロセスは、図２および図３において説明したので、ここでは繰り返さない）。

ストリーミング制御チャネルの確立の間、ＣＣＳＦは、ＤＣデータベースに格納された情報を使用することによって、チャネル設定要求を特定のクライアントおよび関連する配信ノードと相関付けることができる（ステップ１００６ｂ）。具体的には、ＣＣＳＦはＤＣデータベースに問い合わせて、ストリーミング制御チャネルが設定されるクライアント（このクライアントは、例えば、そのＩＰアドレスによって識別することができる）を求め、一意のストリーミング・チャネル識別子（例えば、ポート番号、またはＷｅｂＳｏｃｋｅｔが使用される場合、ＷｅｂＳｏｃｋｅｔ ＩＤ）を、クライアントに所属するデータベース・エントリに割り当てることができる。このように、ＣＤＮにおける機能、例えば、ＣＤＮＣＦ、ＤＣＭＦ、およびＣＣＳＦは、特定のクライアント−チャネルの組み合わせを特定の（１組の）配信ノード（１つまたは複数）に関係付けることができる。

一旦ストリーミング制御チャネルが設定されたなら、ストリーミング・クライアント機能は、第１配信ノードＤＮ１から得られるセグメントを要求し、受信し、プレイ・アウトし始めることができる（ステップ１００７）。ストリーミング・プロセスの間、ＤＣＭＦは、ネットワーク通知、例えば、ＣＤＮＣＦ、ＣＤＮＣＦに関連付けられた負荷均衡化機能、あるいはネットワーク監視機能からのネットワーク過剰負荷または障害通知を監視するための監視プロセスを実行することができる。例えば、ある時点において、全ての配信ノードの負荷を監視するための負荷均衡化機能を含むまたはこれに関連付けられたＣＤＮＣＦが、ＤＮ１にかかる負荷が所定の（最大）閾値に達することを通知することもできる（ステップ１００８）。

次いで、ＣＤＮＣＦは過剰負荷通知をＤＣＭＦに送り、第１配信ノードＤＮ１にかかる負荷が所定の（最大）閾値に近づきつつあることを示すことができる。一実施形態では、過剰負荷通知が、リディレクトすべきクライアントの数に関する情報を含んでもよい（ステップ１００９）。ＤＣＭＦは、ＤＣデータベースにおいてマニフェスト・ファイル情報をチェックすることによって、第１配信ノードＤＮ１を使用しているクライアントを判定することができる（ステップ１０１０）。

ＤＣＭＦは、次に、リディレクトすべきクライアントを選択し、ＣＣＳＦを作動させて、これらのクライアントのストリーミング制御チャネルを通じて、マニフェスト更新トリガを送ることができる（ステップ１０１１）。マニフェスト更新トリガの受信は、ステップ１００１を参照して説明したのと同様の方法で、クライアントに、マニフェスト要求をＣＤＮＣＦに送ることによって新たなマニフェストを要求するように伝えることができる（ステップ１０１２）。

ＣＤＮＣＦは、マニフェスト要求を受信し、クライアントに適した新たなマニフェスト・ファイルを生成または選択することができる（ステップ１０１３）（例えば、負荷均衡化機能を調べることによって）。この場合、選択されたマニフェスト・ファイルは、例えば、第２配信ノードＤＮ２上に格納されたセグメントに対するリンクを収容することができる。次いで、選択されたマニフェスト・ファイルをクライアントに送ることができる。この新たなマニフェスト・ファイルを受信すると、クライアントは、第１配信ノードＤＮ１の代わりに第２配信ノードＤＮ２に後続のセグメントを要求することによって、ストリーミング・プロセスを継続することができる。

クライアントは、異なる配信ノード（即ち、第１配信ノードＤＮ１の代わりに第２配信ノードＤＮ２）上にホストされたセグメントを参照する新たなまたは更新されたマニフェスト・ファイルを受信したので、ＣＤＮＣＦは、クライアントに関連するＤＣデータベースにおいて１つまたは複数のエントリを更新することができる。そうするために、ＣＤＮＣＦは、ＣＤＮにおけるＤＣＭＦに、クライアントには新たなまたは更新されたマニフェスト・ファイルが供給されたという通知を送ることができる（ステップ１００３を参照して説明したのと同様に）。この通知を受信した後、ＤＣＭＦはクライアント情報およびマ
ニフェスト・ファイル情報をＤＣデータベースに格納することができる（ステップ１００４を参照して説明したのと同様に）。このように、ＣＤＮＣＦは、第２配信ノードＤＮ２に関連付けられた別の可能な負荷問題を扱うことができる。

したがって、図１０に示す実施形態では、ストリーミング制御機能を確立し管理する機能が、別のネットワーク・ノード、即ち、ＤＣＮ上に実装されるので、ＣＣＮにおけるＣＤＮＣＦに必要とされる変化は非常に限定され、既存のＣＤＮＣＦの実施態様を再利用することができ、これによって、ストリーミング制御チャネル機能性をＣＤＮに追加するときに必要となるコストを抑える。更に、クライアントの数、および関連するアクティブなストリーミング制御チャネルの数が増大した場合、ＣＤＮＣＦ全体ではなく、ＤＣＮの容量だけをアップグレードすれば済む。このように、この実施形態は、ＣＤＮに関連付けられた多数のストリーミング制御チャネルを管理するために、スケーラブルなソリューションを提供する。

図１１は、本発明の別の実施形態によるコンテンツ・ストリーミング・システムにおける使用のためのメッセージ・フローを示す。具体的には、図１１は、図７と同様のメッセージ・フローを示す。しかしながら、各マニフェスト・ファイルが１つの配信ノードに対する参照だけを含む代わりに、マニフェスト・ファイルは多数の配信ノードに対する参照を収容することができる。この実施形態では、ＣＤＮＣＦは、マニフェスト・ファイルを作成しホストするように構成することができる。

このプロセスは、ユーザが、ウェブサイト上であるビデオに対するリンクを選択すること（ステップ１１００）、およびＣＤＮＣＦからマニフェスト・ファイルを得るためにクライアントによって送られるＨＴＴＰ ＧＥＴ要求の送信（ステップ１１０１）から開始することができ、ＵＲＬがＣＤＮＣＦ上にホストされたマニフェスト・ファイルを指し示す（例えば、リディレクトによって）。クライアントからマニフェスト要求を受信すると、ＣＤＮＣＦは新たなマニフェスト・ファイルを作成するか、または異なる配信ノード上にあるセグメントに対する参照を含む既存のマニフェスト・ファイルを選択することができる（ステップ１１０２）。例えば、一実施形態では、マニフェスト・ファイルは、第１配信ノードＤＮ１上にホストされた低品質セグメントに対する参照、および第２配信ノードＤＮ２上にホストされた高品質セグメントに対する参照を含むことができる。ＣＤＮＣＦは、ＣＤＮにおける配信ノードに関連付けられた負荷情報（負荷均衡化機能によって生成される）を使用し、更には任意にクライアントの位置情報（例えば、ＩＰアドレス）を使用して、クライアントに要求されたセグメント（の一部）を配信するのに最も適した配信ノードを選択することができる。この場合、マニフェスト・ファイルは、少なくとも第１配信ノードＤＮ１および第２配信ノードＤＮ２に対する参照を含むことができる。

ＣＤＮＣＦは、マニフェスト・ファイルをクライアントに送り（ステップ１１０３）、クライアント情報（例えば、そのＩＰアドレス）ならびにマニフェスト・ファイル情報（例えば、クライアントのＩＰアドレス）およびマニフェスト・ファイル情報（例えば、ビデオ・タイトルの少なくとも一部に関連付けられた、マニフェスト・ファイル識別子、またはマニフェストＩＤ、ならびにマニフェスト・ファイルによって参照されるセグメントをホストする特定の（１組の）配信ノード（１つまたは複数）、この場合、第１および第２配信ノードＤ１およびＤ２の位置情報）をＤＣデータベースに格納することができる（ステップ１１０４）。ここでは、マニフェスト・ファイル識別子は、数値によって識別することができ、配信ノードは、ＣＤＮ内部で知られている配信ノード識別子によって識別することができる。

クライアントは、マニフェスト・ファイルを解析して、ビデオを構成するセグメントの位置を得て（ステップ１１０５）、マニフェスト・ファイルにおけるチャネル設定情報を使用して、クライアントとＣＣＳＦとの間にストリーミング制御チャネルを設定することができる（ステップ１１０６ａ）。（このチャネルを設定するプロセスは図２および図３において説明したので、ここでは繰り返さない。）
ストリーミング制御チャネルの確立の間、ＣＣＳＦは、ＤＣデータベースに格納された情報を使用することによって、チャネル設定要求を特定のクライアントおよび関連する（１組の）配信ノード（１つまたは複数）と相関付けることができる（ステップ１１０６ｂ）。具体的には、ＣＣＳＦがＤＣデータベースに問い合わせて、ストリーミング制御チャネルが設定されるクライアントを求め（クライアントは、例えば、そのＩＰアドレスで識別することができる）、一意のストリーミング・チャネル識別子（例えば、ポート番号、またはＷｅｂＳｏｃｋｅｔが使用される場合は、ＷｅｂＳｏｃｋｅｔ ＩＤ）を、クライアントに所属するデータベース・エントリに割り当てることができる。このように、ＣＤＮにおける機能は、特定のクライアント−チャネルの組み合わせを特定の（１組の）配信ノード（１つまたは複数）に関係付けることができる。

一旦ストリーミング制御チャネルが設定されたなら、クライアントは第１および第２配信ノードから発信するセグメントを要求し、受信し、プレイ・アウトすることによって、ストリーミング・プロセスを開始することができる（ステップ１１０７）。ストリーミング・プロセスの間、ある時点において、ＣＤＮ内部の配信ノードの負荷を監視するための負荷均衡化機能を含むまたはこれに関連付けられたＣＤＮＣＦが、第１配信ノードＤＮ１にかかる負荷が所定の（最大）閾値に達するまたは接近することを通知することができる（ステップ１１０８）。すると、ＣＤＮＣＦは、ＤＣＭＦを作動させて、ＤＣデータベースにおけるマニフェスト・ファイル情報をチェックすることによって、第１配信ノードＤＮ１と関連付けられたクライアントはどれかチェックすることができる。次いで、ＤＣＭＦは、どのクライアントがマニフェスト更新を必要とするか判定し、ＣＣＳＦを作動させて、マニフェスト更新トリガをこれらのクライアントの制御チャネルを通じて送ることができる（ステップ１１１０）。

マニフェスト更新トリガは、マニフェスト要求をＣＤＮＣＦに送ることによって（ステップ１１０１）、クライアントが新たなまたは更新されたマニフェスト・ファイルを必要とすることを、クライアントに知らせることができる（ステップ１１１１）。ＣＤＮＣＦは、マニフェスト要求を受信し、このクライアントに適した新たなマニフェスト・ファイルを作成または選択する（ステップ１１０２参照）（ステップ１０１２）。この場合、新たなまたは更新されたマニフェスト・ファイルは、例えば、第１配信ノードＤＮ１に関連付けられたＵＲＬを、同じセグメントをホストする他の配信ノードＤＮ（例えば、第３配信ノードＤＮ３）に関連付けられたＵＲＬと交換することができる。配信ノードＤＮ２に関連付けられたＵＲＬは交換されない。何故なら、第１配信ノードＤＮ１だけが過剰負荷になる危険があったからである。ＣＤＮＣＦは、新たなまたは更新されたマニフェスト・ファイルをクライアントに送ることができ（ステップ１１１３）、クライアントはその（内部）セグメント・リストを更新し、新たなまたは更新されたマニフェスト・ファイルに列挙されたセグメントを要求することによって、ストリーミング・プロセスを継続することができる。

クライアントは新たなまたは更新されたマニフェスト・ファイルを受信したので、ＣＤＮＣＦは、１１０４を参照して説明したステップを実行することによって、そのクライアントに関連付けられたマニフェスト・ファイル情報をＤＣデータベースにおいて更新する。このように、今後のある時点において、過剰負荷の問題が発生した場合、ＣＤＮＣＦはこのクライアントを再度他の配信ノードにリディレクトすることができると考えられる。

したがって、図１１に示す実施形態は、１つのマニフェストによって参照されたセグメントを多数の配信ノードに渡って分散できるという利点があり、各配信ノードは全てのセグメントの内部分集合のみをホストする。これの利点の１つは、ＣＤＮが異なるタイプのセグメント間で区別することが可能になることである。セグメント化されたコンテンツでは、あるセグメントが他のセグメントよりも人気がある（一層頻繁に要求される）ことがある。例えば、時間的セグメント化ビデオ・タイトルでは、早い方のセグメントは、遅い方のセグメントよりも頻繁に要求されるのが通例である。他の例では、ビデオ・タイトルが、異なるビデオ品質に関係するセグメントを有し、ある品質が他のよりも人気があるという場合もある。このような場合、ＣＤＮは、人気が高い方のセグメントを、人気が低い方のセグメントよりも多くの配信ノードにおいてホストし、スケーラビリティ強化および効率向上に備えることができる。

図１２は、本発明の他の実施形態によるコンテンツ・ストリーミング・システムを示す。具体的には、図１２は、図６を参照して説明したような、ＣＤＮベースのコンテンツ配信システムを示す。しかしながら、この実施形態では、本システムは少なくとも２つの相互接続されたＣＤＮを含む。具体的には、このコンテンツ・ストリーミング・システムは、ＣＤＮ相互接続インターフェース１２６４を介して少なくとも１つの第２ＣＤＮ １２０４（下流ＣＤＮとも称される）に相互接続された第１ＣＤＮ １２０２（上流ＣＤＮとも称される）を含み、各ＣＤＮは、当該ＣＤＮ内における１つ以上の配信ノードと１つ以上のクライアントとの間において、ストリーミング・プロセスのネットワーク開始制御を行うように構成される。ネットワーク開始制御は、図２から図５を参照して説明したようなストリーミング制御チャネル機能性に基づいて実現することができる。

更に、コンテンツ配信システムは、クライアント１２０３をホストする１つ以上の端末１２０４にトランスポート・ネットワーク６００を通じて接続されたコンテンツ・ソース１２０１を含む。コンテンツ・ソースは、コンテンツ・プロバイダ・システムＣＰＳ、コンテンツ準備システム、または他のＣＤＮに関係することができる。ＣＰＳは、コンテンツ、例えば、ビデオ・タイトルを顧客に提供するように構成することができ、顧客は、ビデオ・プレイ・アウト機能１２５１によるプレイ・アウトのためにストリームを処理するメディア・ストリーミング機能１２５２を含むクライアントを使用して、コンテンツを購入し受信することができる。

図６と同様、ＣＤＮは、配信ノード１２１１，１２１２，１２１５、および少なくとも１つのＣＣＮ１２１０，１２２３を含むことができる。各配信ノードは、コントローラ１２３０，１２３１，１２３４，およびコンテンツを格納およびバッファリングするキャッシュ１２３２，１２３３，１２３５を含むことができ、またはこれらと関連付けられるのでもよい。各ＣＣＮは、外部ソース、例えば、コンテンツ・プロバイダまたは他のＣＤＮからのコンテンツの収集を制御する収集ノード（またはコンテンツ発信機能、ＣＯＦ）１２２０，１２２３，コンテンツがＣＤＮ内のどこに格納されたかについての情報を維持するコンテンツ位置データベース１２２２，１２２５、ならびに配信ノードへのコンテンツの１つ以上のコピーの配給を制御し、更にクライアントをしかるべき配信ノードにリディレクトする（要求ルーティングとしても知られるプロセス）ＣＤＮ制御機能（ＣＤＮＣＦ）１２２１，１２２４を備えることができ、またはこれらと関連付けられるのでもよい。顧客は、要求をウェブ・ポータル（ＷＰ）１２６１に送ることによって、コンテンツ、例えば、ビデオ・タイトルをＣＰＳ１２６０から購入することができ、ウェブ・ポータル１２６１は、図６を参照して説明したのと同様に、購入可能なコンテンツ項目を識別するタイトル参照を供給するように構成される。

ＣＤＮＣＦは、コンテンツ位置データベース１２２２，１２２５を使用して、セグメントを抽出することができる位置を管理することができる。更に、ＣＤＮは、配信連続ノード（ＤＣＮ）１２１３，１２１６も含むことができる。配信連続ノード１２１３，１２１６は、クライアントに関連付けられたストリーミング制御チャネルを設定および管理し、クライアント情報およびこれらのクライアントが接続された配信ノード（１つまたは複数）のマニフェスト・ファイル情報を含むデータベースを維持するように構成される。ＤＣＮは、単体ＤＣＮとして構成される、またはＣＤＮＣＦに統合されるのでもよい。

ＤＣＮは、ＣＤＮＣＦの要求ルーティング（ＲＲ）機能から発信する通知を監視する配信連続管理機能（ＤＣＭＦ）１２４０、１２４３と、クライアントからのチャネル設定要求を監視し、クライアントにおける制御チャネル機能１２５０と共にストリーミング制御チャネルを設定する制御チャネル・サーバ機能（ＣＣＳＦ）１２４１、１２４４と、クライアント情報（例えば、クライアントのＩＰアドレス）およびマニフェスト・ファイル情報（即ち、セグメント識別子（例えば、ファイル名）およびこれらのセグメントをホストする配信ノードの少なくとも一部に関連付けられた位置情報（例えば、ＵＲＬ））を格納するためにＤＣＮ内にあるまたはこれに関連付けられた配信連続（ＤＣ）データベース１２４２，１２４５を含むことができる。

ＤＣＭＦは、ネットワーク通知、例えば、ＣＤＮＣＦの要求ルーティング（ＲＲ）機能、ＣＤＮにおける別の過剰負荷機能、またはネットワーク監視機能から発信する過剰負荷または障害通知を監視し、このような通知の受信に応答してマニフェスト・ファイル更新プロセスを開始することができる。マニフェスト・ファイル更新プロセスの詳細については、以下で図１３を参照して更に詳しく説明する。

図１２のコンテンツ配信システムでは、上流ＣＤＮが、クライアントへのセグメント配信の一部を、下流ＣＤＮに外部委託することができる。例えば、一実施形態では、低品質セグメントが、第１ＣＤＮ Ａ（例えば、移動体デバイスに対するコンテンツ配信のために構成される）によって突き止められて配信されてもよく、高品質セグメントが、第２ＣＤＮ Ｂによって突き止められて配信されてもよい（ＨＤＴＶ技術をサポートする家庭用メディア・デバイス）への高品質セグメントの配信のために構成される）。

セグメント配信の一部を下流ＣＤＮに外部委託するとき、上流ＣＤＮ（または、具体的には、上流ＣＤＮのＣＤＮＣＦ）が、第１ＣＤＮ Ａにおける１つ以上の配信ノードに対する参照と、第２ＣＤＮ Ｂにおける１つ以上の配信ノードに対する参照とを含むマニフェスト・ファイルを生成するプロセスを開始することができる。このようなマニフェスト・ファイルは、ＣＤＮ間マニフェスト・ファイルと称することもできる。ＣＤＮ間マニフェスト・ファイルは、更に、クライアントと上流ＣＤＮ Ａとの間にストリーミング制御チャネルを設定するためのチャネル設定情報も含むことができる。

ＣＤＮ間マニフェスト・ファイルを生成するプロセスの間、相互接続インターフェース１２６４を介してＣＤＮ間で情報を交換することができる。具体的には、ＣＤＮ間マニフェスト・ファイルの生成の間、上流ＣＤＮは、下流ＣＤＮに外部委託された１つ以上のセグメントに関する位置情報を、下流ＣＤＮに要求することができる。応答して、下流ＣＤＮは、クライアントに関するコンテキスト情報に基づいて、要求されたセグメントをホストする配信ノードを選択することができる。例えば、下流ＣＤＮは、クライアントの位置に地理的に最も近い配信ノードを選択することもできる。この情報は、続いて、ＣＤＮ間マニフェスト・ファイルの生成のために、上流ＣＤＮのＣＤＮＣＦに送られる。したがって、図１３におけるコンテンツ配信システムは、「個人専用とされた」ＣＤＮ間マニフェスト・ファイルを動的に生成するように構成される。

一旦ＣＤＮ間マニフェスト・ファイルが生成されクライアントに転送されると、このクライアントにおける制御チャネル機能は、ＣＤＮ間マニフェスト・ファイル内にあるチャネル設定情報を使用して、上流ＣＤＮのＤＣＮにおけるＣＣＳＦと共にストリーミング制御チャネルを設定し、セグメントの要求およびプレイ・アウトを開始することができる。

ストリーミング・プロセスの間、ＤＣＭＦは、ネットワーク通知、例えば、（過剰）負荷通知または障害通知をＣＤＮＣＦから受信し、クライアントを１つ以上の他の配信ノードにリディレクトすべきであると判断することができる。このネットワーク通知は、上流ＣＤＮまたは下流ＣＤＮにおけるネットワーク問題状況に関係することができる。後者の場合、下流ＣＤＮのＣＤＮＣＦは、ネットワーク通知を、相互接続インターフェース１２６４を介して、上流ＣＤＮのＣＤＮＣＦに送ることができる。

図１３は、本発明の更に別の実施形態によるコンテンツ・ストリーミング・システムにおける使用のためのメッセージ・フローを示す。具体的には、図１３は、図１２に示したコンテンツ配信ネットワークにおける使用のためのメッセージ・フローを示し、マニフェスト・ファイルは、異なるＣＤＮに関連付けられた異なる配信ノード上にホストされたセグメントに対する参照を含むことができる。

このプロセスは、ユーザが、ウェブサイト上であるビデオに対するリンクを選択することから開始することができ（ステップ１３００）、ＵＲＬが第１ＣＮＤ Ａと関連付けられた第１ＣＤＮＣＦ上にホストされたマニフェスト・ファイルを指し示す（例えば、リディレクトによって）。このＣＤＮは、上流ＣＤＮと称することもある。選択のとき、クライアントは、ＣＤＮ ＡのＣＤＮＣＦからマニフェスト・ファイルを得るために、ＨＴＴＰ ＧＥＴ要求を送ることができる（ステップ１３０１）。

クライアントからマニフェスト要求を受信した後、第１ＣＤＮＣＦは、新たなマニフェスト・ファイルを作成するまたは既存のマニフェスト・ファイルを更新するプロセスを開始することができ、マニフェスト・ファイルは、異なるＣＤＮに関連付けられた異なる配信ノード上にあるセグメントに対する参照を含むことができる（ステップ１３０２）。例えば、一実施形態では、低品質セグメントが第１ＣＤＮ Ａによって突き止められて配信されてもよい（例えば、移動体デバイスに対するコンテンツ配信のために構成される）。このＣＤＮを上流ＣＤＮと称することもある。更に、高品質セグメントは、第２ＣＤＮ Ｂによって突き止められて配信されてもよい（例えば、ＨＤＴＶ技術をサポートする家庭用メディア・デバイスに対する高品質セグメントの配信のために構成される）。このＣＤＮを下流ＣＤＮと称することもある。少なくとも第１ＣＤＮ Ａに関連付けられた第１配信ノードＤＮ１と、ＣＤＮ Ｂに関連付けられた第２配信ノードＤＮ２に対する参照を含むマニフェスト・ファイルを、ＣＤＮ間マニフェスト・ファイルと称することもある。ＣＤＮ間マニフェスト・ファイルは、更に、クライアントと上流ＣＤＮ Ａに関連付けられたＣＤＮＣＦとの間にストリーミング制御チャネルを設定するためのチャネル設定情報も含むことができる。

一実施形態では、ＣＤＮ間マニフェスト・ファイルは、上流ＣＤＮ Ａの第１ＣＤＮＣＦが、ＣＤＮ Ｂによってクライアントに配信されるべき所定数のセグメントの位置に対する参照を提供するように、下流ＣＤＮ Ｂの第２ＣＤＮＣＦに要求するプロセスに基づいて、生成することができる。

第１ＣＤＮＣＦは、次に、ＣＤＮ間マニフェスト・ファイルをクライアントに送ることができ（ステップ１３０３）、第１ＣＤＮＣＦはクライアント情報（例えば、そのＩＰアドレス）およびマニフェスト・ファイル情報を、第１ＣＤＮＣＦに関連付けられたＤＣデータベースに格納することができる（ステップ１３０４）。マニフェスト・ファイル情報は、ビデオ・タイトルの少なくと一部に関連付けられたマニフェスト・ファイル識別子、またはマニフェストＩＤと、第１ＣＤＮ Ａと第２ＣＤＮ Ｂに関連付けられた（特定の１組の）配信ノード（１つまたは複数）とに関連付けられた、マニフェスト・ファイルによって参照されるセグメントとをホストする特定の（１組の）配信ノード（１つまたは複数）の位置情報とを含む。ここでは、セグメントはファイル名によって識別することができ、配信ノードは配信ノード識別子によって識別することができる。ここでは、マニフェスト・ファイル識別子は、数値によって識別することができ、配信ノードはＣＤＮ内部で知られている配信ノード識別子によって識別することができる。

したがって、ＣＤＮ間マニフェスト・ファイルの生成の間、第１および第２ＣＤＮＣＦ間で通信が行われるので、第２ＣＤＮＣＦはＣＤＮマニフェスト・ファイルにおける全てのセグメントを知らなくても、第２ＣＤＮＣＦは、その配信ノード（１つまたは複数）上に配置された所定数のセグメントが（近い）今後クライアントによって要求される可能性があることを知る。したがって、第２ＣＤＮＣＦは、下流ＣＤＮ（この場合、第２配信ノードＤＮ２）における配信ノードを、第２ＣＤＮ Ｂに関連付けられたＤＣデータベースにおける上流ＣＤＮ（この場合、第１ＣＤＮＣＦ）に対する参照と共に格納することができるので、これらの配信ノードの１つに伴うあらゆるネットワーク問題、例えば、負荷または障害問題を第１ＣＤＮＣＦに通知することができる（ステップ１３０５）。

クライアントは、ＣＤＮ間マニフェスト・ファイルを解析して、ビデオを構成するセグメントの位置を得て（ステップ１３０６）、マニフェスト・ファイル内にあるチャネル設定情報を使用して第１ＣＤＮＣＦとクライアントとの間にストリーミング制御チャネルを設定することができる（ステップ１３０７）（チャネルを設定するプロセスは、図２および図３において説明したので、ここでは繰り返さない）。

ストリーミング制御チャネルの確立の間、第１ＣＤＮ １に関連付けられたＣＣＳＦは、第１ＤＣデータベースに格納された情報を使用することによって、チャネル設定要求を特定のクライアントおよび関連する（１組の）配信ノード（１つまたは複数）と相関付けることができる（ステップ１３０９）。具体的には、ＣＣＳＦがＤＣデータベースに問い合わせて、ストリーミング制御チャネルが設定されるクライアントを求め（クライアントは、そのＩＰアドレスによって識別することができる）、一意のストリーム・チャネル識別子（例えば、ポート番号、またはＷｅｂＳｏｃｋｅｔを使用する場合は、ＷｅｂＳｏｃｋｅｔ ＩＤ）を、クライアントに所属するデータベース・エントリに割り当てることができる。このように、第１ＣＤＮ１における機能は、特定のクライアント−チャネルの組み合わせを特定の（１組の）配信ノード（１つまたは複数）に関係付けることができる。ストリーミング制御チャネルの確立の後、クライアントは、第１（上流）ＣＤＮ Ａに関連付けられた第１配信ノードＤＮ１および第２（下流）ＣＤＮ Ｂに関連付けられた第２配信ノードＤＮ２双方から得られるセグメントを要求し、受信し、プレイ・アウトすることによって、ストリーミング・プロセスを開始することができる（ステップ１３０８）。

ストリーミング・プロセスの間、ある時点において、それ自体の配信ノードを監視している第２ＣＤＮＣＦが、ネットワーク問題、例えば、第２配信ノードＤＮ２におけるネットワーク障害を通知する場合や、第２配信ノードＤＮ２にかかる負荷が所定の（最大）閾値に達するまたは接近することを通知する場合もあり得る（ステップ１３０９）。すると、ＤＣデータベースにおけるＣＤＮ間情報に基づいて、第２ＣＤＮＣＦが、ネットワーク通知、例えば、（過剰）負荷通知または障害通知を第１ＣＤＮＣＦに送ることによって、このネットワーク問題を第１ＣＤＮＣＦに通知することができる。過剰負荷通知は、第２ＣＤＮにおける配信ノードに対する参照の少なくとも一部、具体的には、ＣＤＮ間マニフェスト・ファイルに列挙された配信ノードに対する参照を更新する必要があることを、第１ＣＤＮＣＦに知らせることができる（ステップ１３１０）。

したがって、第２ＣＤＮＣＦからネットワーク通知を受信すると、第１ＣＤＮＣＦは、ＤＣＭＦを作動させて、第１ＣＤＮＣに関連付けられたＤＣデータベースに格納されたマニフェスト・ファイル情報に基づいて、第２配信ノードＤＮ２に対する参照を収容したＣＤＮ間マニフェスト・ファイルがどのクライアントに送られたのかチェックする（ステップ１３１１）。次いで、ＤＣＭＦは、どのクライアントがリディレクトし、そしてＣＣＳＦを作動させて、リディレクトされる必要があるクライアントの制御チャネルを通じて、マニフェスト更新トリガを送るか決定することができる（ステップ１３１２）。マニフェスト更新トリガを受信すると、クライアントは、マニフェスト・ファイル要求を第１ＣＤＮＣＦに送ることによって（ステップ１３０１と同様）、新たなマニフェスト・ファイルを要求する（ステップ１３１３）。

第１ＣＤＮＣＦは、マニフェスト要求を受信し、ステップ１３０２を参照して先に説明したのと同様に、第２ＣＤＮＣＦと共同してクライアントに適した、新たなまたは更新されたマニフェスト・ファイルを生成する（ステップ１３１４）。例えば、一実施形態では、第２ＣＤＮＣＦが、第２ＣＤＮ（この場合、第２配信ノード）における（殆ど）過剰負荷がかけられた配信ノードに参照するＵＲＬを、他の配信ノード、例えば、同じセグメントをホストする第４配信ノードＤＮ４に対するＵＲＬと交換し、これらの参照を第１ＣＤＮＣＦに送ることができる。第１ＣＤＮ Ａにおいて配信ノードＤＮ１を参照するＵＲＬは交換されない。何故なら、その配信ノードに対しては、過剰負荷シグナリングが第１ＣＤＮＣＦによって受信されないからである。第１ＣＤＮＣＦは、更新されたＣＤＮ間マニフェスト・ファイルをクライアントに送ることができる（ステップ１３１５）。クライアントは、更新されたマニフェスト・ファイルに基づいて、その内部セグメント・リストを更新し、新たなマニフェストにおいて列挙されたＵＲＬに、後続のセグメントを要求することによって、ストリーミングを継続することができる。

クライアントは新たなまたは更新されたマニフェスト・ファイルを受信したので、第１ＣＤＮＣＦは、１３０４を参照して説明したステップを実行することによって、このクライアントに関連付けられたマニフェスト・ファイル情報をＤＣデータベースにおいて更新することができる。更に、第２ＣＤＮＣＦは、下流ＣＤＮ（この場合第１ＣＤＮＣＦ）に対する参照と共に上流ＣＤＮ（この場合、第４配信ノードＤＮ４）における配信ノードを含むＣＤＮ内情報を、第２ＣＤＮ Ｂに関連付けられたＤＣデータベースにおいて、ステップ１３０５を参照して説明したのと同様に、更新することができる。このように、今後のある時点において、ＣＤＮ Ｂにおいて過剰負荷問題が発生した場合、第２ＣＤＮＣＦがクライアントを再度他の配信ノードにリディレクトすることができると考えられる。

したがって、図１３に示す実施形態は、区分化コンテンツを多数のＣＤＮにわたって配給することを可能にするという利点があり、各ＣＤＮは全てのセグメントの内部分集合のみをホストする。この実施形態は、図１１を参照して論じたのと同じ種類の利点を提供するが、この場合、異なる配信ノードを多数のＣＤＮにわたって分散させることができる。これの更に別の利点は、上流ＣＤＮが一部の作業負荷を他の下流ＣＤＮに外部委託することを可能にすることである。更に、この実施形態は特殊化ＣＤＮの使用も可能にする。例えば、一実施形態では、第１ＣＤＮが移動体デバイスに対する配信に合わせて構成され最適化され、主に低い方の品質のセグメントをホストするのでもよく、一方第２ＣＤＮは、ＨＤプレイ・アウト・デバイスに対する配信に合わせて構成され最適化されて、主に高い方の品質のセグメントをホストするのでもよい。

尚、以上で説明したＣＤＮの実施形態では、更新マニフェスト・トリガをクライアントに送り、クライアントが更新されたまたは新たなマニフェスト・ファイルを要求することによって応答する代わりに、新たなまたは更新されたマニフェスト・ファイル（の一部）を直接クライアントに、このクライアントへのストリーミング制御チャネルを通じて送ることができることを申し述べておく。

図１４は、本発明の一実施形態によるマニフェスト・ファイルを示す。具体的には、図１４は、特定の１組のセグメントを配信するように構成された配信ノードに対する参照、例えば、ＵＲＬを含むマニフェスト・ファイルの一実施形態を示す。この特定例では、マニフェスト・ファイルは、ある配信ノードに格納された同じコンテンツに関係する、２つの異なる組のセグメント、例えば、低および高ビットレート・セグメントに対する参照を含むのでもよい。更に、このマニフェスト・ファイルは、チャネル設定情報を含むこともできる。一実施形態では、チャネル設定情報は、ストリーミング制御機能（または、ＣＤＮの場合、制御チャネル・サーバ機能）を含むネットワーク・ノートに対する参照を示すチャネル目標パラメータ１４００を含むことができる。更に、他の実施形態では、チャネル設定情報が、チャネル・パラメータ１４０２、即ち、ストリーミング制御機能／制御チャネル・サーバ機能によって使用されるパラメータを含むこともできる。例えば、ＷｅｂＳｏｃｋｅｔの場合、パラメータはＷｅｂＳｏｃｋｅｔサブプロトコル、ＷｅｂＳｏｃｋｅｔバージョン等の使用に言及するのでもよい。

尚、いずれの１つの実施形態に関係して説明されたいずれの特徴も、単独で用いること、または説明された他の特徴と組み合わせて用いることもでき、更に他のいずれかの実施形態の１つ以上の特徴と組み合わせ用いることもでき、あるいは、他のいずれの実施形態のいずれの組み合わせと組み合わせて用いることもできることは、理解されてしかるべきである。本発明の一実施形態は、コンピュータ・システムと共に用いるプログラム生産物として実現することができる。このプログラム生産物のプログラム（１つまたは複数）は、実施形態の機能を定義し（本明細書において説明した方法を含む）、種々のコンピュータ読み取り可能記憶媒体上に収容することができる。例示的なコンピュータ読み取り可能記憶媒体には、（ｉ）情報が永続的に格納される不揮発性記憶媒体（例えば、ＣＤ−ＲＯＭドライブによって読み取り可能なＣＤ−ＲＯＭのようなコンピュータ内部にあるリード・オンリー・メモリ・デバイス、フラッシュ・メモリ、ＲＯＭチップ、またはあらゆるタイプのソリッド・ステート不揮発性半導体メモリ）、ならびに（ｉｉ）変更可能な情報が格納される書き込み可能記憶媒体（例えば、ディスケット・ドライブ内部にあるフロッピー（登録商標）・ディスク、またはハード・ディスク・ドライブ、またはあらゆるタイプのソリッド・ステート・ランダム・アクセス半導体メモリ）が含まれるが、これらに限定されるのではない。本発明は、以上で説明した実施形態に限定されるのではなく、実施形態は、添付する請求項の範囲内で変更することもできる。

Claims (12)

1. ＨＴＴＰベース・ストリーミング・プロトコルまたはその派生物に基づいて、少なくとも１つの配信ノードから送信されたセグメント化されたコンテンツの受信を制御するためのコンテンツ処理デバイスにおける使用のためのクライアントであって、前記配信ノードが制御チャネル・サーバ機能に関連付けられ、前記クライアントが、
   前記セグメント化されたコンテンツの配信の要求を、前記少なくとも１つの配信ノードに送信し、
   １つ以上のセグメント識別子と、前記セグメント識別子に関連付けられた１つ以上のセグメントを少なくとも１つの前記クライアントに送信するように構成される１つ以上のコンテンツ配信ノードを位置特定するための位置情報とを含むマニフェスト・ファイルを受信し、
   チャネル設定情報を供給され、
   前記チャネル設定情報に基づいて、前記少なくとも１つのクライアントと前記制御チャネル・サーバ機能との間にストリーミング制御チャネルを確立するように構成され、
   前記少なくとも１つのクライアントが更に、前記制御チャネル・サーバ機能から少なくとも１つのマニフェスト・ファイル更新メッセージを受信するように構成される、クライアント。
2. 前記チャネル設定情報が、前記マニフェスト・ファイル内で、または別個のメッセージとして供給される、請求項１記載のクライアント。
3. 前記チャネル設定情報が、前記制御チャネル・サーバ機能をネットワークにおいて位置特定するためのサーバ位置情報を含む、請求項１または２記載のクライアント。
4. 前記サーバ位置情報が少なくとも１つのＵＲＬを含む、請求項３記載のクライアント。
5. 前記ストリーミング制御チャネルを前記少なくとも１つのマニフェスト・ファイル更新メッセージについて監視するように更に構成される、請求項１から４のいずれか一項記載のクライアント。
6. 前記マニフェスト・ファイル更新メッセージを検出し、該マニフェスト・ファイル更新メッセージの検出に応答して第２マニフェスト・ファイルの少なくとも一部を取り出すように更に構成される、請求項５記載のクライアント。
7. 前記確立が、ＷｅｂＳｏｃｋｅｔプロトコルに基づく、請求項１から６のいずれか一項記載のクライアント。
8. 前記マニフェスト・ファイル更新メッセージが第２マニフェスト・ファイルの少なくとも一部を含み、または、前記マニフェスト・ファイル更新メッセージが前記第２マニフェスト・ファイルの少なくとも一部を位置決定および要求するためのマニフェスト・ファイル位置情報を含む、請求項１から７のいずれか一項記載のクライアント。
9. 記録されたデータを有するコンピュータ可読記憶媒体であって、
   前記データが、セグメント化されたコンテンツのストリーミングのネットワーク開始制御を可能にするためのデータ構造を含み、
   前記ストリーミングがＨＴＴＰベース・ストリーミング・プロトコルまたはその派生物に基づき、
   前記データ構造が、１つ以上のセグメント識別子と、前記１つ以上のセグメント識別子に関連付けられた１つ以上のセグメントをクライアントに送信するように構成される１つ以上のコンテンツ配信ノードを位置特定するための位置情報とを含み、
   前記データ構造が、更に、前記クライアントと制御チャネル・サーバ機能の間のストリーミング制御チャネルを確立するためのチャネル設定情報を含む、コンピュータ可読記憶媒体。
10. 前記チャネル設定情報が、前記クライアントとストリーミング制御チャネルを設定するプロセスを開始するように構成される制御チャネル・サーバ機能を含むネットワーク・ノードに関連付けられた位置情報を含む、請求項９記載のコンピュータ可読記憶媒体。
11. 前記位置情報が１つ以上のＵＲＬを含む、請求項１０記載のコンピュータ可読記憶媒体。
12. 前記データ構造がマニフェスト・ファイルである、請求項９から１１のいずれか一項に記載のコンピュータ可読記憶媒体。

Images