特表 2016-533062 セグメント化コンテンツのストリーミング

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】特表2016-533062(P2016-533062A)

(43)【公表日】2016年10月20日

(54)【発明の名称】セグメント化コンテンツのストリーミング

(51)【国際特許分類】

   H04N 21/262 20110101AFI20160926BHJP

   H04N 21/845 20110101ALI20160926BHJP

   G06F 13/00 20060101ALN20160926BHJP

【ＦＩ】

   H04N21/262

   H04N21/845

   G06F13/00 540B

【審査請求】有

【予備審査請求】未請求

【全頁数】38

(21)【出願番号】特願2016-522589(P2016-522589)

(86)(22)【出願日】2014年7月2日

(85)【翻訳文提出日】2016年2月29日

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

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

(87)【国際公開日】20150108

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

(32)【優先日】2013年7月3日

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

(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LT,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．イーサネット

(71)【出願人】

【識別番号】504292093

【氏名又は名称】コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ

(71)【出願人】

【識別番号】508351406

【氏名又は名称】ネダーランゼ・オルガニサティ・フォーア・トゥーゲパスト−ナトゥールヴェテンシャッペリーク・オンデルゾエク・ティーエヌオー

(74)【代理人】

【識別番号】100140109

【弁理士】

【氏名又は名称】小野 新次郎

(74)【代理人】

【識別番号】100075270

【弁理士】

【氏名又は名称】小林 泰

(74)【代理人】

【識別番号】100101373

【弁理士】

【氏名又は名称】竹内 茂雄

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100173565

【弁理士】

【氏名又は名称】末松 亮太

(72)【発明者】

【氏名】ウィッシンフ，バスティアーン

(72)【発明者】

【氏名】バンクマ，メンノ

(72)【発明者】

【氏名】ファンブランデンブルク，ライ

(72)【発明者】

【氏名】ファン・デーフェンテル，マタイス・オスカル

【テーマコード（参考）】

5B084

5C164

【Ｆターム（参考）】

5B084AA01

5B084AA12

5B084AA29

5B084AB32

5B084AB50

5B084BB19

5B084DB09

5B084DC02

5B084DC06

5B084DC13

5B084DC18

5C164MB44P

5C164SB29S

5C164SC03S

5C164SC24P

(57)【要約】

マニフェスト・ファイルに基づいて、コンテンツ配信ネットワークから適応ストリーミング・クライアントへのセグメント化コンテンツのストリーミングを可能にするための方法およびシステムについて記載する。前記マニフェスト・ファイルは１つ以上のセグメント識別子を含むことができる。この方法は、前記マニフェスト・ファイルから少なくとも１つのセグメント識別子を選択するステップであって、前記識別子が、前記クライアントによって未だ要求されていないセグメントを識別する、ステップと、前記セグメントが前記クライアントによって要求され得ることを通知するために、前もって予告情報をコンテンツ配信ネットワークに送るステップであって、前記予告情報が、前記少なくとも１つのセグメント識別子を含み、前記予告情報が、更に前記要求を受けるときに、前記セグメントの入手可能性を確保するために、前記コンテンツ配信ネットワークをトリガするように構成される、ステップと、を含む。
【選択図】図４

【特許請求の範囲】

【請求項1】

配信ノードから、適応ストリーミング・クライアントを含むデバイスに、マニフェスト・ファイルに基づいて、セグメント化コンテンツのストリーミングを可能にする方法であって、前記マニフェスト・ファイルが１つ以上のセグメント識別子を含み、前記方法が、
前記マニフェスト・ファイルから少なくとも１つのセグメント識別子を選択するステップであって、前記セグメント識別子が、前記選択が行われるときに前記クライアントによって未だ要求されていないセグメントを識別する、ステップと、
前記セグメントが前記クライアントによって要求され得ることを通知するために、前もって予告情報を配信ノードまたはコンテンツ配信ネットワークに送るステップであって、前記予告情報が前記少なくとも１つのセグメント識別子を含み、前記予告情報が、更に、前記少なくとも１つのセグメントが要求されたときに、前記セグメントの入手可能性を確保するために、前記配信ノードまたは前記コンテンツ配信ネットワークをトリガするように構成される、ステップと、
を含む、方法。

【請求項2】

請求項１記載の方法において、前記予告情報が、前記セグメント要求が前記クライアントによって要求されることが予想される期間を定める時間期間を含む、方法。

【請求項3】

請求項１または２記載の方法において、前記セグメントの入手可能性を確保するステップが、更に、
前記少なくとも１つのセグメント識別子に関連付けられた前記セグメントが、前記配信ノード上でまたは前記コンテンツ配信ネットワークにおいて収集および／または格納されているか否か検証するステップと、
前記セグメントが前記配信ノード上でまたは前記コンテンツ配信ネットワークにおいて収集および／または格納されていない場合、前記セグメントを前記配信ノード上に格納するステップと、または
前記セグメントが前記配信ノード上でおよび／または前記コンテンツ配信ネットワークにおいて収集および／または格納される場合、前記セグメントの格納を所定時間期間維持するステップであって、好ましくは、前記所定の期間が、前記セグメント要求が前記クライアントから要求されると予想される期間と少なくとも同じ長さである、ステップと、
を含む、方法。

【請求項4】

請求項１〜３のいずれか１項記載の方法であって、更に、
予告メッセージ、好ましくは、（ＨＴＴＰ）要求メッセージにおいて前記予告情報を前記コンテンツ配信ノードにまたは前記コンテンツ配信ネットワークに送るステップであって、前記予告情報の少なくとも一部が前記メッセージのヘッダおよび／または前記メッセージの本体に挿入され、好ましくは、前記メッセージがＨＴＴＰ ＨＥＡＤ、ＨＴＴＰ ＧＥＴ、またはＨＴＴＰ ＰＯＳＴメッセージの内の１つである、方法。

【請求項5】

請求項４記載の方法において、前記メッセージのヘッダが、当該メッセージが予告メッセージであることを前記配信ノードまたは前記コンテンツ配信ネットワークに知らせる予告インディケータを含む、方法。

【請求項6】

請求項１〜５のいずれか１項記載の方法において、前記送るステップが、更に、
前記予告情報を、ＨＴＴＰ要求メッセージにおいて、コンテンツ配信ネットワークの要求ルーティング・ノードに送るステップと、
その後、前記要求ルーティング・ノードからＨＴＴＰリダイレクト・メッセージを受信するステップであって、前記リダイレクト・メッセージが、前記セグメントの配信が前記クライアントによって要求され得る前記コンテンツ配信ノードにおける配信ノードに関連付けられたアドレスまたはセグメント・ロケータ（ＵＲＬ）を含む、ステップと、
前記クライアントまたは前記要求ルーティング・ノードが、前記アドレスまたはセグメント・ロケータに基づいて、前記予告情報を、ＨＴＴＰ要求メッセージにおいて、前記配信ノードに送るステップと、
任意に、前記アドレスまたはセグメント・ロケータを前記マニフェスト・ファイルに書き込むステップと、
を含む、方法。

【請求項7】

請求項１〜６のいずれか１項記載の方法であって、更に、
予告サポート・メッセージを前記配信ノードまたは前記コンテンツ配信ネットワークに送るステップであって、前記予告サポート・メッセージが、前記少なくとも１つのセグメントが要求されたときに前記セグメントの入手可能性を確保するための前記配信ノードまたは前記コンテンツ配信ネットワークによる前記トリガが、前記配信ノードまたは前記コンテンツ配信ネットワークによってサポートされるか否か検証するように構成される、ステップと、
任意に、前記配信ノードまたは前記コンテンツ配信ネットワークがクライアントの予告情報の処理をサポートする場合、前記トリガがサポートされる前記配信ノードまたは前記コンテンツ配信ネットワークから、予告サポート確認メッセージを受信するステップと、
を含む、方法。

【請求項8】

請求項１〜７のいずれか１項記載の方法において、前記少なくとも１つのセグメント識別子を選択するステップが、更に、
前記クライアントにおけるユーザ・ナビゲーション機能からのユーザ・ナビゲーション情報、および／または前記マニフェスト・ファイルにおける一般ナビゲーション情報を使用して、所定の時間期間内に要求され得る前記セグメントを予測するステップを含む、方法。

【請求項9】

請求項１〜８のいずれか１項記載の方法において、前記予告情報が、別個の通信チャネル、好ましくは、（双方向）ＷｅｂＳｏｃｋｅｔ通信チャネルを通じて、前記配信ノードまたは前記コンテンツ配信ネットワークに送られ、
更に、任意に、前記別個の通信チャネルが、前記クライアントにおいて予告機能をアクティブ化または非アクティブ化するため、および／または更新マニフェスト・ファイルを前記クライアントに送るために、前記配信ノードまたは前記コンテンツ配信ネットワークによって使用される、方法。

【請求項10】

請求項１〜９のいずれか１項記載の方法において、前記配信ノードまたは前記コンテンツ配信ネットワークが、所定期間内に格納および／または収集したセグメントを追跡し、前記配信ノードまたは前記コンテンツ配信ネットワークが、前記所定期間内に格納および／または収集されたセグメント識別子に関連付けられた予告情報を受信した場合、前記セグメントが要求されたときに、前記セグメントの入手可能性を確保するために、前記配信ノードまたは前記コンテンツ配信ネットワークが、前記予告情報によってトリガされないように構成される、方法。

【請求項11】

請求項４また５に記載の方法であって、更に、
前記配信ノード、前記コンテンツ配信ネットワーク、または前記コンテンツ配信ネットワークにおける要求ルーティング・ノードにおけるフィルタ機能が、予告情報を含むメッセージと、予告情報を含まないメッセージとを、好ましくは、前記メッセージにおける予告インディケータの存在をチェックすることによって選別するステップと、
任意に、予告情報を含むメッセージが、セグメントの入手可能性をチェックするために、前記配信ノードまたは前記コンテンツ配信ネットワークにおけるキャッシュ制御機能をトリガし、前記セグメントが前記配信ノードにおいて格納および／または収集されていない場合、前記セグメントを前記配信ノード上または前記コンテンツ配信ネットワークにおいて収集および／または格納するステップと、
または、前記セグメントが前記配信ノード上または前記コンテンツ配信ネットワークにおいて格納されている場合、前記セグメントの格納を所定の時間期間維持するステップであって、前記所定の期間が、少なくとも前記セグメント要求が前記クライアントによって要求されることが予想される期間と同じ長さである、ステップと、
を含む、方法。

【請求項12】

配信ノード、好ましくはコンテンツ配信ネットワークの配信ノード上に格納されたセグメント化コンテンツの要求のために構成された適応ストリーミング・クライアントを含むデバイスであって、
マニフェスト・ファイルの少なくとも一部を格納するキャッシュであって、前記マニフェスト・ファイルが前記配信ノードを突き止めるための１つ以上のセグメント識別子を含む、キャッシュと、
前記マニフェスト・ファイルから少なくとも１つのセグメント識別子を選択するように構成されたセグメント・セレクタであって、前記セグメント識別子が、前記選択が実行されたときに前記クライアントによって要求されていないセグメントを識別する、セグメント・セレクタと、
前記セグメントが前記クライアントによって要求され得ることを通知するために、予告情報を配信ノードまたはコンテンツ配信ネットワークに前もって送るように構成された予告機能であって、前記予告情報が、前記少なくとも１つのセグメント識別子を含み、前記予告情報が、更に、前記少なくとも１つのセグメントが要求されたときに前記セグメントの入手可能性を確保するために前記配信ノードまたは前記コンテンツ配信ネットワークをトリガするように構成される、予告機能と、
含む、デバイス。

【請求項13】

請求項１２記載のデバイスにおいて、前記クライアントが、更に、
メッセージ、好ましくは、（ＨＴＴＰ）要求メッセージを用意し、前記メッセージが予告情報と予告インディケータとを含み、更に前記メッセージを前記配信ノードまたは前記コンテンツ配信ネットワークに送るように構成され、好ましくは、前記予告情報が、前記メッセージのヘッダおよび／または前記メッセージの本体に挿入され、好ましくは、前記メッセージが、ＨＴＴＰ ＨＥＡＤ、ＨＴＴＰ ＧＥＴ、ＨＴＴＰ ＰＯＳＴメッセージの内の１つである、デバイス。

【請求項14】

請求項１２または１３記載のクライアントと共に好ましくは使用するためのネットワーク・ノードであって、
セグメントがクライアントによって要求され得ることを通知するための予告情報を受けるように構成されたキャッシュ制御機能であって、前記予告情報が前記少なくとも１つのセグメント識別子を含み、前記予告情報が、更に、前記少なくとも１つのセグメントが要求されたときに前記セグメントの入手可能性を確保するために、前記ネットワーク・ノードをトリガするように構成され、好ましくは、前記セグメントの入手可能性を可能にする動作が、更に、前記少なくとも１つのセグメント識別子に関連付けられた前記セグメントが、前記配信ノード上で収集および／または格納されているか否か検証し、前記セグメントが前記配信ノード上で収集および／または格納されていない場合、前記セグメントを前記配信ノード上で収集および／または格納し、または前記セグメントが前記配信ノード上で収集および／または格納されている場合、前記セグメントの格納を所定時間期間維持する動作を含み、好ましくは、前記所定の期間が、前記セグメント要求が前記クライアントから要求されると予想される期間と少なくとも同じ長さである、キャッシュ制御機能、および／または
予告情報を含む前記メッセージと、予告情報を含まない他のメッセージとの間で、好ましくは、前記メッセージにおける予告インディケータの存在をチェックすることによって区別するフィルタ機能であって、予告情報が前記少なくとも１つのセグメント識別子を含み、前記予告情報が、前記セグメントがクライアントによって要求されたときに配信ノードまたはコンテンツ配信ネットワークによって前記セグメントの入手可能性を確保するために、前記配信ノードまたは前記コンテンツ配信ネットワークをトリガするように構成される、フィルタ機能、
を含む、ネットワーク・ノード。

【請求項15】

データ構造、好ましくは、請求項１２および１３による適応ストリーミング・クライアントによる使用のためのマニフェスト・ファイルの少なくとも一部であって、前記データ構造が、１つ以上のセグメント識別子によって識別された１つ以上のセグメントを前記クライアントに配信するように構成された１つ以上の配信ノードを突き止めるための前記１つ以上のセグメント識別子、好ましくは、ＵＲＬを含み、
前記データ構造が、更に、前記１つ以上の配信ノードが予告情報を処理するように構成されることを前記クライアントに指示し、更に、任意に、セグメントが前記クライアントによって要求され得ることを前もって通知するために予告情報を前記１つ以上の配信ノードに送るように構成されたその予告機能を使用するように、前記クライアントに指示する、予告サポート情報を含み、および／または
前記１つ以上のセグメント識別子に関連付けられた１つ以上のマーカであって、前記クライアントにおける前記予告機能が、前記マニフェスト・ファイルから少なくとも１つのセグメント識別子を選択することを可能にする、マーカを含む、データ構造。

【請求項16】

コンピュータのメモリにおいて実行すると、請求項１〜１１のいずれか１項記載の方法ステップを実行するように構成されたソフトウェア・コード部分を含むコンピュータ・プログラム製品。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、セグメント化コンテンツのストリーミングに関し、特に、配信ノードから、適応ストリーミング・クライアントを含むデバイスへのセグメント化コンテンツのストリーミングを可能にする方法、セグメント化コンテンツのストリーミングのために適応ストリーミング・クライアントを含むデバイス、クライアントと共に使用するためのネットワーク・ノードおよびデータ構造、ならびにこのような方法を使用するコンピュータ・プログラム製品に関するが、これらが全てではない。

【従来技術】

【0002】

現在、いわゆるセグメント化を利用するビデオ・ストリーミング技法の数は、増えつつある。例えば、ＨＴＴＰ適応ストリーミング（ＨＡＳ）、スケーラブル・ビデオ・コーディング（ＳＶＣ）、および空間的セグメント化ビデオ（例えば、タイル化ビデオ(tiled video)は、それぞれ、時間、品質、および空間に基づいたセグメント化を使用する。セグメント化プロセスの間、いわゆるマニフェスト・ファイルが生成される。これは、異なるセグメント・ファイル間の関係、および／またはセグメントを引き出すことができるストリームおよび位置を記述する。セグメント・ファイルは、少なくとも１つのセグメントに関連付けられたデータを含むファイルに関係付けることができ、ファイル引き出しプロトコル、例えば、ＨＴＴＰまたはＦＴＰによって引き出すことができる。同様に、セグメント・ストリームは、少なくとも１つのセグメントに関連付けられたデータを含むストリームに関係付けることができ、ストリーミング・プロトコル、例えば、ＲＴＳＰ／ＲＴＰまたはＨＡＳによって引き出すことができる。以後、セグメント・ファイルまたはストリームをセグメントと呼ぶ。更に、ビデオ、または更に一般的には、セグメント化方式によってレンダリングされるコンテンツを、セグメント化コンテンツと呼ぶこともできる。

【0003】

マニフェスト・ファイル内におけるセグメントを送出する(playout)（再生する(playback)）ために、ＨＡＳクライアント（以下省略してクライアント）は連続的にセグメントをネットワークに、通例、いわゆるコンテンツ配信ネットワーク（ＣＤＮ）に要求する。ＣＤＮは、セグメントをクライアントに配信するように構成された配信ノードの被管理ネットワークと見なすことができる。クライアントは、マニフェスト・ファイル内において定義されたセグメントを使用して、例えば、高品質ビデオ・ストリームから低品質ビデオ・ストリームにまたはその逆に切り替えることによって、変化する帯域幅要求および／またはユーザ入力に対して、送出を動的に調節する。更に、セグメント化コンテンツは、人気のあるビデオ・セグメントと人気がないビデオ・セグメントとの間で差別するために、コンテンツ配信システム、例えば、ＣＤＮによっても使用することができる。例えば、ビデオの開始に関連付けられたコンテンツは、通例、ビデオの最後におけるコンテンツよりも頻繁に（より多く）視聴される（ダウンロードされる／アクセスされる／引き出される）。同様に、低ビットレート、低品質ビデオ・コンテンツ（例えば、解像度が最も低いＨＡＳセグメントまたはいわゆるＳＶＣベース・レイヤ）は、高品質コンテンツ（例えば、高解像度ＨＡＳセグメントまたはＳＶＣ強化レイヤ）よりも頻繁に視聴されるであろう。

【0004】

１つの離れた（離れ過ぎた）サーバからの人気のあるセグメントのクライアントへの配信は、ネットワーク帯域幅を塞ぐ(clog up)おそれがある。したがって、効率的にコンテンツを消費者に配信するように構成されたコンテンツ配信ネットワーク（ＣＤＮ）は、潜在的な帯域幅問題を減らすことができ、効率的な配信が保証されるように、人気のあるコンテンツに関連付けられたセグメント程ＣＤＮにおける多数の配信ノードに格納（キャッシュ）することができる。加えて、ＣＤＮは、人気のあるセグメント程配信ノードにおいて長い期間格納することができる。ＣＤＮコンテンツ・マネージャは、セグメントを引き出すことができるＣＤＮ内における位置、およびこれらの位置からセグメントを引き出すことができる長さを集中管理することができる。

【0005】

クライアントがＣＤＮに格納されたセグメントにアクセスすることを可能にするために、クライアントには、セグメント識別子のリストを識別するいわゆるマニフェスト・ファイル、および任意に、ネットワークにおける位置を指し示すセグメント・ロケータが供給され、これらによってクライアントがセグメントを引き出すことを可能にする。通例、送出が開始される前に、クライアント（デバイス）に関連付けられたセグメント・バッファに所定数のセグメントがロードされるように、クライアントはセグメントを引き出すように構成されている。更に、送出の間、クライアントは、十分なセグメントがバッファ内に保持されるように、マニフェスト・ファイルに基づいて、ネットワークからセグメントを引き出す。このため、セグメント引き出しプロセスに伴うレイテンシは、セグメントの継ぎ目ない送出を妨害しない。

【0006】

しかしながら、場合によっては、クライアントが要求したときに、マニフェスト・ファイル内で特定されたセグメントが（未だ）配信ノード上で入手可能になっていないこともあり得る。セグメントが入手できないことには、異なる理由が考えられる。例えば、ＣＤＮは、セグメントが実際に要求される前に、そのセグメントをその配信ノードに前もって位置付けるように構成されていない場合がある。最初にセグメントが要求されたときに、ＣＤＮは、収集プロセスをトリガすることができ、このプロセスにおいて、コンテンツ起源(origin)、例えば、メディア・ストレージまたは他のＣＤＮがセグメントをＣＤＮ（またはＣＤＮにおける１つ以上の配信ノード）に配信することができる。このようなコンテンツ収集方式は、実際にコンテンツの要求があったときのみに、配信ノードにセグメントが格納されるという利点を得ることができる。更に、ＣＤＮ内に格納されたセグメントの量を効率的に管理するためには、セグメントを所定時間入手可能にすればよい（キャッシュされる）。配信ノードでは、人気が少ないセグメント程相対的に短いキャッシュ期間だけ格納することができる。この期間の後、セグメントは除去されるので、この期間の後にこれらのセグメントが要求されたときに、要求されたセグメントが再収集されることが必要となる。他の状況では、例えば、ライブ・ストリームにおけるセグメントの人気度が突然急激に高まったために、配信ノードがセグメント要求を受けた時点に、全ての配信ノードにおいて、要求されたセグメントが入手できないというおそれがある。

【0007】

以上で述べた状況では、セグメントを要求しても、セグメントが入手できない（「キャッシュ・ミス」）場合があり、要求されたセグメントを配信ノードに供給するプロセス（例えば、動的収集プロセス）をトリガする場合がある。セグメントの収集は、クライアントによるセグメント引き出しプロセスにおける遅れ、およびクライアントに入手可能な帯域幅の減少を誘発するおそれがある。多数のセグメントのために収集プロセスを実行する必要があるとき、要求されたセグメントの配信が著しく減少するおそれがある。連続的な送出を維持しようとするために、ＨＡＳクライアントはこの遅れを帯域幅問題として認識し、低い（より低い）品質のセグメント・ストリームを消費する低帯域幅の送出に切り替えることによって、このような状況に反応することができる。これは、ユーザ体験において著しい劣化を生ずる原因となるおそれがある。最悪の場合、クライアントは継ぎ目のないセグメントの送出を維持することができない。

【0008】

ＵＳ２００９／０２９２８１９は、メディア・ストリームの通常(conventional)送出の間、クライアントが「ルックアヘッド」セグメントをメディア・サーバからプリフェッチすることができる方法について記載する。このようにして、クライアントは、著しい遅れを全く起こさずに、容易にルックアヘッド・セグメントに飛ぶことができる。実際には、このようなプリフェッチ方式は、正常な(normal)ストリーミング・プロセスの間、余分な「ルックアヘッド」セグメントを引き出すので、クライアントとメディア・サーバとの間において正規のセグメントのために入手可能な帯域幅が少なくなるという状況に至る。適応ストリーミング・システムにおいてこのような方式を使用すると、ＨＡＳクライアントは、低品質のセグメント化ストリームに切り替えることによって、帯域幅減少に反応することになる。

【発明の概要】

【発明が解決しようとする課題】

【0009】

したがって、当技術分野では、セグメント化コンテンツをクライアントにストリーミングする方法およびシステムの改良が求められている。具体的には、クライアントがマニフェスト・ファイルを受信した時点で、マニフェスト・ファイルにおける全てのセグメントがクライアントへの配信のために入手できない場合であっても、セグメント化コンテンツの継ぎ目ない送出を提供する方法およびシステムが求められている。

【課題を解決するための手段】

【0010】

本発明の目的は、先行技術において知られている欠点の内少なくとも１つを低減または解消すること、そして、本発明の第１の態様において、マニフェスト・ファイルに基づいて、配信ノードから適応ストリーミング・クライアントにセグメント化コンテンツのストリーミングを可能にするための方法を提供することである。前記マニフェスト・ファイルは、１つ以上のセグメント識別子を含む。前記方法は、前記マニフェスト・ファイルから少なくとも１つのセグメント識別子を選択するステップであって、前記セグメント識別子が、前記選択が行われるときに前記クライアントによって未だ要求されていないセグメントを関連付ける、ステップと、前記セグメントが前記クライアントによって要求され得ることを通知するために、前もって予告情報を配信ノードまたは前記配信ノードに関連付けられたコンテンツ配信ネットワークに送るステップであって、前記予告情報が、前記少なくとも１つのセグメント識別子を含み、前記予告情報が、更に、前記少なくとも１つのセグメントが要求されたときに、前記セグメントの入手可能性を確保するために、前記配信ノードまたは前記コンテンツ配信ネットワークをトリガするように構成される、ステップとを含む。この方法は、セグメントのクライアントへの配信のために１つの配信ノード（メディア・サーバ）を含む単純なクライアント−サーバ・モデル、または１つ以上のコンテンツ配信ネットワークにおいて使用することができ、コンテンツ配信ネットワークでは、多数の配信ノードがセグメントをクライアントに配信することができる。

【0011】

本発明による方法は、適応ストリーミング・クライアントが、マニフェスト・ファイルに列挙されているセグメントの１つ以上のセグメント識別子を選択することを可能にする。これらのセグメントは、前記クライアントによって（未だ）要求されていないが、前記クライアントによって要求されるかもしれない（即ち、要求されることが予想または予測される）。セグメント識別子は、クライアントがセグメントを要求したときにこれらのセグメントがクライアントに入手可能であることを配信ノードに予告するために使用することができる。したがって、予告情報は、クライアントによる前記セグメントの可能なまたは今後の要求を予期して、配信ノードまたはコンテンツ配信ネットワークに送られる。コンテンツ配信ネットワークにおいてセグメントが入手可能でない場合、ネットワークは、これらのセグメントを引き出し、配信ノード上またはコンテンツ配信ネットワーク内にこれらを格納するためのプロセスを開始することができる。このように、セグメントを要求したクライアントに、このセグメントを容易に配信することができる。セグメント・ミスによる遅れを大幅に短縮できるので、適応ストリーミング・クライアントは低品質セグメントに切り替えることはなく、これによって高品質のセグメントをクライアントに配信することを確保する。

【0012】

実施形態では、前記予告情報が、前記セグメント要求が前記クライアントによって要求されることが予想される期間を定める時間期間を含むのでもよい。このように、予告情報は、近い将来、即ち、所定の時間期間以内に要求され得るセグメントについての情報を含む。この時間期間は、ユーザ統計等に基づいて決定（予測）することができる。

【0013】

実施形態では、前記セグメントの入手可能性を確保するステップが、更に、前記少なくとも１つのセグメント識別子に関連付けられた前記セグメントが、前記配信ノード上に格納されているか否か検証するステップと、前記セグメントが前記配信ノード上に格納されていない場合、前記セグメントを前記配信ノード上に格納するステップと、または前記セグメントが前記配信ノード上に格納されている場合、前記セグメントの格納を所定時間期間維持するステップであって、好ましくは、前記所定の期間が、前記セグメント要求が前記クライアントから要求されると予想される期間と同じ長さである、ステップとを含むのでもよい。したがって、予告情報は、セグメントの入手可能性を検証するために、配信ノードまたはコンテンツ配信ネットワークをトリガすることができる。セグメントが入手可能でない場合、セグメント引き出しプロセスをトリガすることができ、セグメントを引き出し、このセグメントを配信ノード上またはコンテンツ配信ネットワーク内に格納する。このようなセグメント引き出しプロセスは、例えば、収集プロセスを含むことができる。セグメントが所定時間だけ格納され、そして、例えば、キャッシュ・アルゴリズムが一定の時間期間以内にセグメントをキャッシュから除去する場合、セグメントの入手可能性を維持するために、これらのセグメントの格納時間を延長することができる。

【0014】

実施形態では、前記方法は、更に、予告メッセージにおいて前記予告情報を前記コンテンツ配信ノード、前記コンテンツ配信ネットワーク、または前記コンテンツ配信ネットワークにおける（要求ルーティング）ノードに送るステップを含むのでもよい。実施形態では、前記予告メッセージが（ＨＴＴＰ）メッセージであってもよい。更に他の実施形態では、（ＨＴＴＰ）メッセージのヘッダが、当該メッセージが予告メッセージである（予告メッセージとして解釈されるべき）ことを前記配信ノードまたは前記コンテンツ配信ネットワークに知らせる予告インディケータを含むのでもよい。他の実施形態では、前記メッセージが、前記少なくとも１つのセグメントに関連付けられた少なくとも１つのセグメント・ロケータ（ＵＲＬ）を含むのでもよい。更に他の実施形態では、前記予告情報の少なくとも一部が、前記メッセージのヘッダに、および／または前記メッセージの本体に挿入されてもよい。更に他の実施形態では、前記メッセージがＨＴＴＰ ＨＥＡＤ、ＨＴＴＰ ＧＥＴ、またはＨＴＴＰ ＰＯＳＴメッセージの内の１つであってもよい。

【0015】

したがって、コンテンツ配信ネットワーク、更に特定すれば、ＣＤＮにおける要求ルーティング・ノード、または配信ノードが、標準的な（ＨＴＴＰ）メッセージと、予告メッセージとして役割を果たす（ＨＴＴＰ）メッセージとの間で区別するために、（ＨＴＴＰ）メッセージのヘッダが予告インディケータを含むフィールドを含んでもよい。予告インディケータは、メッセージを予告メッセージとして解釈すべきことを配信ノードまたは前記コンテンツ配信ネットワークに知らせる。このような予告インディケータの種々の実施態様について、本願において説明するが、フラグ、トークン、または（ＨＴＴＰ）メッセージのヘッダに挿入することができる予告クッキー値を含む。

【0016】

他の実施形態では、前記送るステップが、更に、前記予告情報を、ＨＴＴＰ要求メッセージにおいて、コンテンツ配信ネットワークの要求ルーティング・ノードに送るステップと、（その後）、前記要求ルーティング・ノードからＨＴＴＰリダイレクト・メッセージを受信するステップであって、前記リダイレクト・メッセージが、前記セグメントの配信が前記クライアントによって要求され得る前記コンテンツ配信ノードにおける配信ノードに関連付けられたアドレスまたはセグメント・ロケータ（ＵＲＬ）を含む、ステップと、前記クライアントまたは前記要求ルーティング・ノードが、前記アドレスまたはセグメント・ロケータに基づいて、前記予告情報を、ＨＴＴＰ要求メッセージにおいて、前記配信ノードに送るステップとを含むのでもよい。他の実施形態では、前記クライアントが、前記アドレスまたはセグメント・ロケータを前記マニフェスト・ファイルに書き込む（挿入する）のでもよい。したがって、予告ＨＴＴＰメッセージを処理するために使用される情報は、ＨＴＴＰリダイレクト・メッセージにおける情報を含み、適応ストリーミング・クライアントを含むデバイスのキャッシュに格納されているマニフェスト・ファイルの１つ以上のセグメント・ロケータを少なくとも部分的に解明するために使用することができる。このように、予告および事前解明を組み合わせると、クライアントによるセグメントの要求の間、遅れを更に一層短縮することができる。

【0017】

更に他の実施形態では、前記方法は、予告サポート・メッセージを前記配信ノードまたは前記コンテンツ配信ネットワークに送るステップであって、前記セグメントの入手可能性を確保するための前記配信ノードまたは前記コンテンツ配信ネットワークによる前記トリガが、前記配信ノードまたは前記コンテンツ配信ネットワークによってサポートされるか否か検証する、ステップを含むのでもよい。他の実施形態では、前記方法が、前記配信ノードまたは前記コンテンツ配信ネットワークがクライアントの予告情報の処理をサポートする場合、前記トリガがサポートされることを示すサポート確認メッセージを、前記配信ノードまたは前記コンテンツ配信ネットワークから受信するステップを含むのでもよい。

【0018】

実施形態では、前記少なくとも１つのセグメント識別子を選択するステップが、更に、前記クライアントにおけるユーザ・ナビゲーション機能からのユーザ・ナビゲーション情報、および／または前記マニフェスト・ファイルにおける一般ナビゲーション情報を使用して、所定の時間期間内に要求され得る前記セグメントを予測するステップを含むのでもよい。

【0019】

実施形態では、前記予告情報が、別個の通信チャネルを通じて、前記配信ノードまたは前記コンテンツ配信ネットワークに送られてもよい。更に他の実施形態では、前記別個の通信チャネルが、前記クライアントにおいて予告機能をアクティブ化または非アクティブ化するため、および／または更新マニフェスト・ファイルを前記クライアントに送るために、前記配信ノードまたは前記コンテンツ配信ネットワークによって使用されるのでもよい。更に他の実施形態では、通信チャネルが（双方向）ＷｅｂＳｏｃｋｅｔ通信チャネルであってもよい。したがって、クライアントと配信ノードまたはＣＤＮとの間に別個の双方向ＷｅｂＳｏｃｋｅｔチャネルを設定することができ、予告メッセージの効率的な処理が可能になる。更に、ネットワークが動的に予告機能をアクティブ化（非アクティブ化）および／または調節することも可能にする。

【0020】

実施形態では、前記配信ノードまたは前記コンテンツ配信ネットワークが、所定期間内に格納したセグメントを追跡してもよい。実施形態では、前記コンテンツ配信ネットワークが、前記所定期間格納されているセグメント（識別子）に関連付けられた予告情報を受信した場合、前記配信ノードまたはコンテンツ配信ネットワークは、前記予告情報によってトリガされない。つまり、これらの実施形態は、予告情報におけるセグメント識別子が、所定期間格納されたセグメントのセグメント識別子と同じであると判定された場合、確保するメカニズムはトリガされないことを含意する。確保するメカニズムは、特に、非常に大きなセグメント・データベースおよびストレージでは、リソースを消費する。所定期間が、例えば、十分に短い場合、セグメントは未だそこにあり、除去されていないと時事上仮定してもよい。

【0021】

更に他の実施形態では、前記方法は、更に、前記コンテンツ配信ノードにおけるフィルタ機能、前記コンテンツ配信ノード、または前記コンテンツ配信ノードにおける要求ルーティング・ノードが、予告情報を含むメッセージと、予告情報を含まないメッセージとを選別する(filter)ステップを含むのでもよい。実施形態では、前記選別するステップが、前記メッセージにおける予告インディケータの存在をチェックするステップを含む。

【0022】

更に他の実施形態では、前記方法が、予告情報を含むメッセージが、セグメントの入手可能性をチェックするために、前記配信ノードまたは前記コンテンツ配信ネットワークにおけるキャッシュ制御機能をトリガし、更に前記セグメントが前記配信ノードにおいて、格納されていない場合、前記セグメントを前記配信ノード上格納するステップと、または、前記セグメントが前記配信ノード上において格納されている場合、前記セグメントの格納を所定の時間期間維持するステップとを含むのでもよく、好ましくは、前記所定の期間が、少なくとも前記セグメント要求が前記クライアントによって要求されることが予想される期間と同じ長さである。

【0023】

他の態様では、本発明は、配信ノード、好ましくはコンテンツ配信ネットワークの配信ノード上に格納されたセグメント化コンテンツの要求のために構成された適応ストリーミング・クライアントを含むデバイスに関することもできる。前記クライアント・デバイスは、マニフェスト・ファイルの少なくとも一部を格納するキャッシュであって、前記マニフェスト・ファイルが前記配信ノードを突き止めるための１つ以上のセグメント識別子を含む、キャッシュ、前記マニフェスト・ファイルから少なくとも１つのセグメント識別子を選択するように構成されたセグメント・セレクタであって、前記セグメント識別子が、前記選択が実行されたときに前記クライアントによって要求されていないセグメントを識別する、セグメント・セレクタ、および／または、前記セグメントが前記クライアントによって要求され得ることを通知するために、予告情報を配信ノードまたは前記配信ノードに関連付けられたコンテンツ配信ネットワークに前もって送るように構成された予告機能であって、前記予告情報が、前記少なくとも１つのセグメント識別子を含み、前記予告情報が、更に、前記少なくとも１つのセグメントが要求されたときに前記セグメントの入手可能性を確保するために前記配信ノードまたは前記コンテンツ配信ネットワークをトリガするように構成される、予告機能の内少なくとも１つを含む。

【0024】

更に他の実施形態では、前記クライアントが、更に、メッセージ、好ましくは（ＨＴＴＰ）要求メッセージを用意するように構成されるのでもよく、前記メッセージが予告情報と予告インディケータとを含み、更に前記メッセージを前記配信ノードまたは前記コンテンツ配信ネットワークに送ることが、前記予告情報をメッセージ、好ましくは、（ＨＴＴＰ）要求メッセージにおいて、前記コンテンツ配信ノードに関連付けられたコンテンツ配信ネットワークに送ることであり、好ましくは、前記メッセージが、クライアントが要求し得る前記少なくとも１つのセグメントに関連付けられた少なくとも１つのセグメント・ロケータ（ＵＲＬ）を含み、前記予告情報が、前記メッセージのヘッダおよび／または前記メッセージの本体に挿入され、好ましくは、前記メッセージが、ＨＴＴＰ ＨＥＡＤ、ＨＴＴＰ ＧＥＴ、ＨＴＴＰ ＰＯＳＴメッセージの内の１つである。

【0025】

他の態様では、本発明は、好ましくは、以上で説明したデバイスと共に使用するためのネットワーク・ノードに関することもできる。前記ネットワーク・ノードは、セグメントがクライアントによって要求され得ることを通知するための予告情報を受けるように構成されたキャッシュ制御機能であって、前記予告情報が前記少なくとも１つのセグメント識別子を含み、前記予告情報が、更に、前記少なくとも１つのセグメントが要求されたときに前記セグメントの入手可能性を確保するために、前記ネットワーク・ノードをトリガするように構成される、キャッシュ制御機能、および／または予告情報を含む前記メッセージと、予告情報を含まない他のメッセージとの間で、好ましくは、前記メッセージにおける予告インディケータの存在をチェックすることによって区別するフィルタ機能であって、予告情報が前記少なくとも１つのセグメント識別子を含み、前記予告情報が、前記セグメントがクライアントによって要求されたときに配信ノードまたはコンテンツ配信ネットワークによって前記セグメントの入手可能性を確保するために、前記配信ノードまたは前記コンテンツ配信ネットワークをトリガするように構成される、フィルタ機能の内少なくとも１つを含むことができる。

【0026】

実施形態では、前記セグメントの入手可能性を可能にする動作が、更に、前記少なくとも１つのセグメント識別子に関連付けられた前記セグメントが、前記配信ノード上に格納されているか否か検証し、前記セグメントが前記配信ノード上に格納されていない場合、前記セグメントを前記配信ノード上に格納し、または前記セグメントが前記配信ノード上に格納されている場合、前記セグメントの格納を所定時間期間維持する動作を含むのでもよく、好ましくは、前記所定の期間が、前記セグメント要求が前記クライアントから要求されると予想される期間と少なくとも同じ長さである。

【0027】

更に他の態様では、本発明は、データ構造、好ましくは、以上で説明した適応ストリーミング・クライアントによる使用のためのマニフェスト・ファイルの少なくとも一部に関することもできる。前記データ構造は、前記１つ以上のセグメント識別子によって識別された１つ以上のセグメントを前記クライアントに配信するように構成された１つ以上の配信ノードを突き止めるための１つ以上のセグメント識別子、好ましくは、ＵＲＬを含むのでもよい。更に、前記データ構造は、前記１つ以上の配信ノードが予告情報を処理するように構成されることを前記クライアントに指示し、更に、任意に、セグメントが前記クライアントによって要求され得ることを前もって通知するために予告情報を前記１つ以上の配信ノードに送るように構成されたその予告機能を使用するように、前記クライアントに指示する、予告サポート情報、および／または前記１つ以上のセグメント識別子に関連付けられた１つ以上のマーカであって、前記クライアントにおける前記予告機能が、前記マニフェスト・ファイルから少なくとも１つのセグメント識別子を選択することを可能にする、マーカを含むことができる。

【0028】

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

【図面の簡単な説明】

【0029】

【図1】図１Ａおよび図１Ｂは、従来の適応ストリーミング・クライアント、およびこのようなクライアントにおいて使用するマニフェスト・ファイルを示す。

【図2】図２は、従来のＨＡＳクライアントに対するセグメント引き出しおよび送出プロセスの流れ図を示す。

【図3A】図３Ａは、本発明の種々の実施形態にしたがってセグメント化コンテンツをストリーミングするときの流れ図を示す。

【図3B】図３Ｂは、本発明の種々の実施形態にしたがってセグメント化コンテンツをストリーミングするときの流れ図を示す。

【図3C】図３Ｃは、本発明の種々の実施形態にしたがってセグメント化コンテンツをストリーミングするときの流れ図を示す。

【図4】図４は、本発明の一実施形態によるセグメント化コンテンツの送出におけるＨＡＳクライアントを示す。

【図5】図５は、本発明の実施形態にしたがってセグメント化コンテンツをストリーミングするネットワーク・ノードを模式的に示す。

【図6】図６は、本発明の一実施形態にしたがってセグメント化コンテンツをストリーミングするシステムを示す。

【図7】図７は、本発明の他の実施形態によるセグメント化コンテンツのストリーミング・プロセスのプロトコル・フローを示す。

【図8A】図８Ａは、本発明の種々の実施形態によるセグメント化コンテンツのストリーミング・プロセスのプロトコル・フローを示す。

【図8B】図８Ｂは、本発明の種々の実施形態によるセグメント化コンテンツのストリーミング・プロセスのプロトコル・フローを示す。

【図9】図９は、本発明の一実施形態にしたがってマニフェスト・ファイルの少なくとも一部のセグメント・ロケータを事前に解明する例を示す。

【図10A】図１０Ａは、本発明の実施形態によるプロトコル・フローおよびマニフェスト・ファイルをそれぞれ示す。

【図10B】図１０Ｂは、本発明の実施形態によるプロトコル・フローおよびマニフェスト・ファイルをそれぞれ示す。

【図11】図１１は、本発明の実施形態にしたがって別個の通信チャネルを設定するための情報を含むマニフェスト・ファイルを示す。

【図12】図１２は、本発明の実施形態にしたがって双方向ＨＡＳ制御チャネルを確立するためのプロトコル・フローを示す。

【図13】図１３は、デバイス構造またはサーバ・システム、好ましくは、ネットワーク・ノードの構造の例を示す。

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

【0030】

図１Ａおよび図１Ｂは、従来の適応ストリーミング（ＡＳ）クライアント、およびこのようなＨＡＳクライアントと共に使用するマニフェスト・ファイルをそれぞれ示す。クライアント１０２は、端末（図示せず）上にホストされるのでもよく、端末は、ネットワークにおける１つ以上のメディア・サーバと通信し、適応ストリーミング・プロトコルに基づいて、コンテンツのストリーミングを可能にするように構成される。適応ストリーミング・プロトコルには、例えば、アップル・ＨＴＴＰライブ・ストリーミング（Apple HTTP Live Streaming）[http://tools.ietf.org/html/draft-pantos-http-live-streaming-07]、マイクロソフト・スムーズ・ストリーミング（Microsoft Smooth Streaming）[http://www.iis.net/download/ SmoothStreaming]、アドービＨＴＴＰダイナミック・ストリーミング（Adobe 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]）等がある。

【0031】

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

【0032】

ユーザは、端末をネットワーク、例えば、インターネットに接続し、ビデオ・タイトル・リンクを含むコンテンツ・プロバイダのウェブサイトにブラウズし、１つのビデオ・タイトル・リンクを選択することができる。リンク、例えば、ＵＲＬの選択時に、マニフェスト・ファイルをクライアントに送ることができる。ここでは、マニフェスト・ファイルという用語は、一般に、ビデオ・タイトルまたはその一部を構築するセグメントを識別するセグメント識別子（記述子）、セグメントをクライアントに配信するかまたはクライアントにセグメントを引き出すことができる場所の情報を提供するように構成することができるネットワーク・ノード（１組のネットワーク・ノード）、例えば、メディア・サーバ（１つまたは複数）の位置情報、および、任意に、送出のためにセグメントのシーケンスを正しく判定するためにクライアントによって使用することができる、セグメント間の関係を判定するセグメント制御情報を含む特殊なデータ構造を指すことができる。ある場合には、例えば、ライブ・ストリームでは、メディアを送出するために多数のマニフェスト・ファイルが使用されることもある。異なるプロトコルが、マニフェスト・ファイルに異なる名称を使用することができる。例えば、ＤＡＳＨストリーミング・プロトコルでは、マニフェスト・ファイルをメディア・プレゼンテーション記述（ＭＤＰ）と読むこともできる。

【0033】

図１Ｂは、コンテンツ項目を構築するセグメントを識別するセグメント識別子を含むマニフェスト・ファイルの模式図を示す。任意に、マニフェスト・ファイルは、特定されたセグメントをクライアントに供給するように構成された、またはセグメントを引き出すことができる場所の情報をクライアントに提供するように構成された、１つ以上のネットワーク・ノードへの参照を含む位置情報を含むことができる。したがって、このような参照は、以後セグメント・ロケータと呼ばれることもあり、特定されたセグメントを配信するように構成されたネットワーク・ノードを指し示すことができ、または、代わりに、特定されたセグメントを配信することができるかもしれない１つ以上のネットワーク・ノードを決定することができるネットワーク・ノードを指し示すことができる。更に他の実施形態では、セグメント・ロケータがネットワーク・ノード上の位置を指し示すこともできる。例えば、異なるセグメント・ロケータが、１つの配信ノード内において定められた異なるフォルダを指し示すこともできる。

【0034】

ここでは、配信ノードという用語は、セグメントをクライアントに配信するように構成された任意のタイプのネットワーク・ノードとすることができる。コンテキストに応じて、配信ノードをエッジ・ノード、キャッシュ、サービング・ノード、またはＨＴＴＰ（ウェブ）サーバと呼ぶこともある。

【0035】

ＨＡＳクライアントは、マニフェスト・ファイルを使用して、このマニフェスト・ファイル内において特定されたセグメントをクライアントに配信するように構成された配信ノードを突き止めることができる。このために、マニフェスト・ファイルは、セグメントを識別するために、少なくとも１つのセグメント識別子、例えば、セグメント・ファイル名を含むことができる。これは、更に、セグメント識別子に関連付けられた少なくとも１つのセグメント・ロケータの形態とした位置情報も含むことができる。セグメント・ロケータは、特定されたセグメントをホストし、セグメントをクライアントに配信するように構成された、または特定されたセグメントをクライアントに配信することができるかもしれない１つ以上の他のネットワーク・ノードを決定するように構成された、１つ以上のネットワーク・ノード（またはネットワーク・ノード上における１つ以上のフォルダ）へのポインタと定めることができる。

【0036】

ある実施形態では、セグメント識別子およびセグメント・ロケータが、ＵＲＬのような所定のデータ構造の一部になることもできる。例えば、ＵＲＬ「central.cdnA.com/segment1-1.avi」、即ち、ＣＤＮ Ａのネットワーク・ノードへのポインタ（または参照）、およびセグメント識別子、即ち、セグメント・ファイル名segment1-1.aviを含む。この場合、セグメント・ロケータcentral.cdnA.comに関連付けられたネットワーク・ノードは、セグメントをクライアントに配信するように構成することができ、またはセグメントsegment1-1.avを配信することができるかもしれない１つ以上のネットワーク・ノードを指し示す１つ以上の他のセグメント・ロケータを配信するように構成することができる。

【0037】

以下の例では、ＵＲＬを使用して説明するが、本発明はそれに限定されないことを具申する。他の実施形態では、セグメント識別子およびセグメント・ロケータは、ネットワークにおいてセグメントを識別し突き止めるのに適した、任意の相応しいフォーマットを採用することができる。ある実施形態では、セグメント識別子およびセグメント・ロケータは、セグメント識別子またはセグメント・ロケータのいずれもがネットワークにおいてセグメントを識別し突き止めるために使用できるという意味で、同じものであるとも言える。

【0038】

図１Ｂの例では、マニフェスト・ファイルは、２組の異なるセグメントに関連付けられたＵＲＬを含む。即ち、第１組の低ビットレート・セグメントおよび第２組の高ビットレート・セグメントであり、各組がビデオ・タイトルを収容する。ここでは、低ビットレート・セグメントに関連付けられたＵＲＬのセグメント・ロケータ部分は、第１コンテンツ配信ネットワークＣＤＮＡのネットワーク・ノードを指し示すことができ、高ビットレート・セグメントは第２ＣＤＮＢのネットワーク・ノードを指し示すことができる。異なる１組のセグメントは、同じコンテンツの異なる表現、高品質表現および低品質表現を定めることもできる。クライアントは、マニフェスト・ファイル内におけるセグメントＵＲＬに基づいてセグメントを引き出すことができる。この方式については、以下で更に詳しく説明する。

【0039】

図１Ａに示すように、マニフェスト・ファイルは、マニフェスト・キャッシュ１０４に格納され、解析され、セグメント・リスト、即ち、論理データ構造に構造化されることが可能である。この論理データ構造は、セグメントを引き出すための情報、例えば、セグメント識別子（例えば、セグメント・ファイル名）、およびこれらのセグメントを引き出すことができる場所を判定するためのセグメント・ロケータ、例えば、ＵＲＬ（１つまたは複数）の所定部分、ならびにセグメントの送出を制御するための送出制御情報、即ち、セグメント間の関係（例えば、時間関係、品質関係、および／または空間関係）を含む。

【0040】

セグメント引き出し機能１０６は、コンテンツ配信ネットワーク（ＣＤＮ）に関連付けられたメディア・サーバまたは１つ以上の配信ノードからセグメントを引き出すために、マニフェスト・キャッシュにおける位置情報を使用することができる。（セグメント）転送プロトコル（通例、これは、ＨＴＴＰであるが、ＲＴＳＰ／ＲＴＰ、ＦＴＰ、および他のプロトコルを使用することもできる）を使用してセグメントを引き出し、一時的にセグメント・バッファ１０８に格納することができる。更に、ビデオ送出機能１１０（メディア・エンジンと呼ぶこともできる）は、マニフェスト・キャッシュにおける情報に基づいて、セグメント・バッファに格納されたセグメントを送出することができる。

【0041】

セグメント引き出し機能は、送出が開始される前に、セグメントを引き出し、セグメント・バッファに所定数のセグメントがロードされるように構成することができる。更に、送出の間、セグメント引き出し機能は、十分なセグメントがセグメント・バッファに格納されるように、マニフェスト・ファイルに基づいて継続的にセグメントを引き出す。通例、セグメント引き出し機能は、クライアントと配信ノードとの間で利用可能な帯域幅に基づいて引き出しプロセスを最適化するように構成することができる。このため、セグメント引き出しに伴うレイテンシは、セグメントの継ぎ目のない送出を妨害しない。セグメント引き出し機能は、ユーザが、マニフェスト・ファイルによって定められたように、セグメント化されたコンテンツ全体をナビゲートできるように、ユーザ・ナビゲーション機能１１２からセグメント引き出し命令を受け入れて処理することができる。ここでは、ユーザ・ナビゲーション機能からのセグメント引き出し命令は、時間的なナビゲーション（例えば、高速送り）および／または空間的なナビゲーション（例えば、パンニング−ズーミング−ティルティング）に関係することができる。

【0042】

図２は、図１Ａに示したような従来のＨＡＳクライアントのセグメント引き出しおよび送出プロセスのプロトコル図を示す。このプロセスは、クライアントがネットワーク、例えば、コンテンツ配信ネットワークＣＤＮＡにマニフェスト・ファイルを要求することから開始することができる。要求メッセージ、例えば、マニフェスト・ファイルに関連付けられたＵＲＬを含むＨＴＴＰ ＧＥＴメッセージを、ＣＤＮの要求ルーティングＲＲ(request routing)ノードに送ることができる（ステップ２００）。要求ルーティング・ノードは、次に、このメッセージをＣＤＮＡにおける配信ノードにリダイレクトすることができる（ステップ２０２〜２０４）。このノードは、マニフェスト・ファイル、およびこのマニフェスト・ファイルにおいて列挙されたセグメントをクライアントに配信するように構成される。このマニフェスト要求に応答して、ＣＤＮＡにおける配信ノードＤＮ１は、マニフェスト・ファイルをクライアントに送ることができる。その後、クライアントは、マニフェスト・ファイルを解析し（ステップ２０８）、マニフェスト・ファイルからセグメントを選択し、この選択したセグメント・ファイルに関連付けられたセグメント・ロケータ（例えば、ＵＲＬ）に基づいて、選択したセグメントを要求することができる。クライアントにおけるセグメント引き出し機能は、要求されたセグメントをクライアントに配信するために利用可能な帯域幅を評価することができる。この特定の場合では、セグメントの高品質バージョンを要求するのに十分な帯域幅が利用可能である（図１Ｂに示すマニフェスト・ファイルも参照のこと）。

【0043】

配信ノードＤ１が第１セグメント"segment1-1.avi"を求める要求を受けたとき（ステップ２１０）、要求されたセグメント・ファイルが入手できないと判定する場合もある。このような状況を「キャッシュ・ミス」（２１２）と呼ぶことができる。配信ノードＤ１が第１セグメントを求める要求を受けたとき、セグメントが入手できないことには、種々の理由があると考えられる（既に以上で論じた）。キャッシュ・ミスの判定は、要求されたセグメントを他のコンテンツ起源、例えば、他のＣＤＮまたは中央コンテンツ・ストレージから、例えば、従来のＨＴＴＰ要求を使用して収集するプロセスをトリガすることができる（ステップ２１４〜２１６）。一旦、セグメントが収集され配信ノードに配信されたなら、配信ノードは要求されたセグメントをクライアントに送ることができ（ステップ２１８）、クライアントは、マニフェスト・ファイルに基づいて他のセグメントを引き出すプロセスを続けながら、高品質セグメントの送出を開始することができる。収集プロセスは、要求されたセグメントのクライアントへの配信において遅れを生ずる原因となる。これらの遅れは、マニフェスト・ファイルにおけるセグメント・ロケータ（の一部）をネットワークにおいて解明する必要がある場合、更に増大するおそれがある。このような解明プロセスは、ＤＮＳ参照およびリダイレクトを含み、これらが遅れを生ずる原因となり、この遅れがキャッシュ・ミスによる遅れに追加される。

【0044】

クライアントにおけるセグメント引き出し機能は、第１セグメントが完全にクライアントに配信される前に比較的長い時間がかかったことを察知していたかもしれない。この情報に基づいて、クライアントは、高品質セグメントをクライアントに配信するための十分な帯域幅が（もはや）入手できないと判断し、コンテンツの低（より低い）品質バージョンの送出に切り替えることができる（ステップ２１９）。したがって、この場合、セグメント引き出し機能は、低品質の第２セグメント"segment2-2.avi"に基づいて、第２セグメントに関連付けられたセグメント・ロケータを含むセグメント要求をコンテンツ配信ノードに送ることによって、セグメント引き出しプロセスを継続することができる（ステップ２２０）。また、この場合、セグメントが入手できないので、別のキャッシュ・ミスが判定されるおそれがある（ステップ２２２）。このキャッシュ・ミスが再度収集プロセスを開始する可能性があり、要求されたセグメントがコンテンツ起源から収集される。収集の後、要求された低品質（より低い品質）のセグメントがクライアントに供給され、クライアントは、より低い品質で第２セグメントを送出し始める場合がある。

【0045】

したがって、以上から、キャッシュ・ミスおよび解明プロセスによるネットワークにおける遅れの結果、クライアントが低品質のセグメントを要求し送出することになるおそれがあり、ユーザ体験を落とすおそれがあるということになる。究極的に、多数のキャッシュ・ミスが引き続き発生すると、セグメントの再生中断を起こすおそれがある。

【0046】

図３Ａは、本発明の実施形態にしたがってセグメント化コンテンツをストリーミングするときのプロトコル・フローを示す。具体的には、図３は、ＨＡＳクライアントおよびコンテンツ配信ネットワークが、セグメントを要求するクライアントと、要求されたセグメントの実際の配信との間に起こり得る遅れを最小化するように構成される、流れ図を示す。

【0047】

このプロセスは、図２を参照して説明したのと同様に、配信ノードからのマニフェスト・ファイルの引き出しから開始することができる（ステップ３００〜３０６）。その後、ＨＡＳクライアントはマニフェスト・ファイルを解析し（ステップ３０８）、ネットワークへの送信のために第１予告メッセージを用意することができる。予告メッセージは、近い将来引き出すことになるセグメントについての予告情報を含むことができる。予告情報は、１つ以上のセグメント識別子を含むことができる。セグメント識別子には、これらのセグメントのクライアントへの配信に指定される配信ノードを関連付けることができる。例えば、図３Ａにおいて、配信ノードに送られる（ステップ３１０）予告メッセージは、配信ノードＤＮ１に格納されているセグメント・ファイルを識別する１つ以上のＵＲＬを含むことができる。他の実施形態では、予告情報は、前記セグメント要求が前記クライアントによって要求されることが予想される期間を定める時間期間を含むことができる。

【0048】

予告メッセージの受信後、配信ノードによってメッセージを解析することができる（ステップ３１２）。予告メッセージに応答して、配信ノードにおけるキャッシュ制御機能が、予告メッセージにおいて特定されたセグメントがこの配信ノードにおいて入手可能か否か判定することができる。キャッシュ制御機能は、セグメント（またはその一部）が入手できないと判定する場合もある。その場合、これらのセグメントを他のコンテンツ起源から収集するためのプロセスをトリガすることができる。例えば、ダイナミック収集プロセスをトリガすることができ、配信ノード（または要求をルーティングしたノード）がコンテンツ起源に、欠落したセグメントを要求する（ステップ３１４〜３１６）。これらのセグメントは、コンテンツ起源によって配信ノードに配信することができる。

【0049】

あるいは、キャッシュ制御機能は、セグメント（またはその一部）が入手できるが、例えば、所定の最大格納時間よりも長い期間セグメントが既にキャッシュに格納されているために、所定の期間内にキャッシュから除去されることになると判定する場合もある。この場合、キャッシュ制御機能は、これらのセグメントに対して最大格納時間を延長することができる。このように、キャッシュ制御機能は、これらのセグメントがクライアントによる要求に対して入手できるように、これらのセグメントをキャッシュから除去しない。

【0050】

一方、クライアントは、第１セグメントを配信ノードに要求するプロセスを開始することができる（ステップ３１８および３２２）。予告メッセージは、既に、マニフェスト・ファイルにおける最初の方のセグメントが実際に要求に対して入手可能となる手立てをしたので、セグメントをクライアントに容易に配信することができる。セグメント収集プロセス（ステップ３２０および３２４）は、クライアントがセグメントの配信を要求する時間中も継続することができるので（ステップ３１８および３２２）、キャッシュ・ミスによる遅れは排除されるか、少なくとも大幅に減少する。

【0051】

一旦第１予告メッセージに関連付けられたセグメントの収集プロセスが終了したなら、マニフェスト・ファイルからの他のセグメントを含む第２予告メッセージを配信ノードに送ることができるので、セグメント引き出しプロセスの間、配信ノードにおいてセグメントは入手可能になる。

【0052】

以上で説明したような予告メッセージは、種々の方法でネットワークに送ることができる。一実施形態では、予告メッセージをＨＴＴＰメッセージとして実施することもできる。実施形態では、予告メッセージは、クライアントが近い将来要求しようとしそうなセグメントのセグメント・ロケータ（ＵＲＬ）を含むＨＥＡＤメッセージとして実施することもできる。

【0053】

コンテンツ配信ネットワーク（または要求をルーティングしたノードおよび／または配信ノード）が標準的なＨＴＴＰメッセージと、配信ノードまたはコンテンツ配信ネットワーク用の予告メッセージとして役割を果たすＨＴＴＰメッセージとの間で区別するために、ＨＴＴＰメッセージのヘッダは、予告インディケータを含むフィールドを含むことができる。この予告インディケータは、配信ノードまたはコンテンツ配信ノードに、メッセージを予告メッセージとして解釈すべきことを知らせる。予告インディケータは、標準的なＨＴＴＰメッセージと（とりわけ）予告メッセージとして役割を果たすＨＴＴＰメッセージとの間で区別するために、配信ノードまたはＣＤＮに必要な予告情報の一部であってもよい。あるいは、１つ以上のタイプのＨＴＴＰメッセージ、例えば、全てのＨＥＡＤメッセージが、配信ノードまたはコンテンツ配信ネットワークによって、予告メッセージとして見なされてもよい。

【0054】

一実施形態では、このインディケータはフラグ、例えば、二進フラグでもよい。他の実施形態では、このインディケータはトークンでもよい。トークンは、セグメントおよび／またはユーザ特定にすることもできる。実施形態では、セグメント識別子（の少なくとも一部）がトークンと関連付けられてもよい。クライアントが予告メッセージを用意するとき、クライアントは、１つ以上のセグメント識別子および関連するトークンをマニフェスト・ファイルから選択することができ、セグメント識別子は、クライアントが所定の時間期間内に要求することができるセグメントと関連付けられる。その後、クライアントは、少なくとも１つのセグメント識別子と、予告インディケータとしてのトークンとを含むＨＴＴＰメッセージを、配信ネットワークまたはコンテンツ配信ネットワークに送ることができる。

【0055】

更に他の実施形態では、予告インディケータを（ＨＴＴＰ）クッキーに基づいて実現することもできる。その場合、配信ノードまたはコンテンツ配信ネットワークは、クッキー設定命令を（クッキー対応）クライアントに送ることができる。実施形態では、クッキー設定命令は、図１２を参照して後に説明する（ウェブソケットに基づく）ＨＡＳ制御チャネルのような、別個の通信チャネルを介してクライアントに送ることができる。

【0056】

クッキーは、配信ノードまたはＣＤＮによって検出し解釈することができる予告インディケータを表す予告クッキー値を含むことができる。クッキー値は、クッキーが有効であるドメインに対して特定的にすることもできる。実施形態では、ドメインは、セグメント化コンテンツ項目（マニフェスト・ファイルにおいて定められる）、セグメント化コンテンツ項目の特定表現（マニフェスト・ファイルにおいて定められる）、または１つ以上の個々のセグメントであってもよい。

【0057】

クライアントがドメインに対するＨＴＴＰメッセージを配信ノードまたはＣＤＮに送るとき、ＨＴＴＰメッセージと共に予告メッセージ・クッキーを配信ノードまたはＣＤＮに送るので、このＨＴＴＰメッセージは配信ノードまたはコンテンツ配信ネットワークによって予告メッセージとして解釈される。実施形態では、クライアントが予告クッキー値をＨＴＴＰメッセージのクッキー・ヘッダ・フィールド、例えば、ＨＴＴＰ ＨＥＡＤに挿入することもできる。このように、配信ノードまたはＣＤＮ、具体的には、ＣＤＮの要求をルーティングしたノードが、ＨＴＴＰメッセージのクッキー・ヘッダをチェックして予告クッキー値を求めることができる。メッセージが予告クッキー値を含まない場合、配信ノードまたはＣＤＮはメッセージを標準的なＨＴＴＰメッセージと解釈すればよい。

【0058】

この実施形態の利点は、ネットワークが任意の時点においてクッキー設定命令を使用して動的に予告機能をアクティブ化（非アクティブ化）および／または調節することを可能にすることである。

【0059】

実施形態では、予告メッセージは、ＨＴＴＰ ＧＥＴメッセージとして実施することもできる。ＨＴＴＰ ＧＥＴメッセージは、予告インディケータと、クライアントが要求しているセグメントのセグメント識別子および／またはロケータ（ＵＲＬ）とを含む。ＧＥＴメッセージのＨＴＴＰヘッダは、更に、クライアントが近い将来要求しようとする（しそうな）１つ以上のセグメントに関連付けられた１つ以上のセグメント識別子および／またはロケータを含む。

【0060】

更に他の実施形態では、予告メッセージをＨＴＴＰ ＧＥＴまたはＰＯＳＴメッセージとして実施することもでき、この場合、ヘッダが予告インディケータを有し、本体が、クライアントが近い将来要求しようとする（しそうな）１つ以上のセグメント・ロケータを含むことができる。１つ以上のセグメント識別子および／またはロケータは、ＸＭＬまたはＪＳＯＮフォーマットで格納することができる。更に、１つ以上のセグメント識別子および／またはロケータも、ＨＴＴＰ ＧＥＴメッセージの本体に、サブＨＴＴＰ要求のリストとして格納することができる。

【0061】

あるいは、予告メッセージをネットワークに別個の通信チャネルを通じて送ることもできる。一実施形態では、このような別個の通信チャネルは、ＷｅｂＳｏｃｋｅｔプロトコルに基づいて確立することができる。ＷｅｂＳｏｃｋｅｔプロトコルを確立するプロセスについては、以下で図１１および図１２を参照しながら更に詳しく説明する。

【0062】

図３Ｂおよび図３Ｃは、本発明の２つの実施形態による、クライアント側におけるストリーミング・プロセスの流れ図を示す。図３Ｂでは、このプロセスは、ＨＡＳクライアントがビデオ・タイトルに関連付けられたマニフェスト・ファイルを要求することから開始することができる（ステップ３００）。マニフェスト・ファイルを受信した後（ステップ３０１）、クライアントはビデオの送出を開始することができる。セグメントの送出を開始した後（ステップ３０２）、クライアントは、所定期間以内に要求しようとしている（可能性が最も高い）１つ以上のセグメント識別子（１組のセグメント）をマニフェスト・ファイルにおいて決定することができる。次いで、クライアントは１つ以上のセグメント識別子を含む予告メッセージを用意して、この予告メッセージをＣＤＮに送ることができる（ステップ３０４）。予告メッセージがＣＤＮによって受信されると、ＣＤＮはセグメントがクライアントに入手可能になる手立てを行う。ここで、「クライアントに入手可能」とは、クライアントがセグメントを求める要求を行ったときに、そのセグメントが配信ノードに配置され格納されていることを意味する。予告プロセスは、ビデオの送出が終了するまで、別の複数組のセグメントのために繰り返すことができる（ステップ３０５）。図３Ｃにおけるプロセスは図３Ｂにおけるものと同様であるが、第１予告メッセージが、ビデオ送出の前にネットワークに送られることを除く。このように、キャッシュ・ミスは、ビデオの送出全体にわたって回避される。図３Ｂにおけるプロセスは、高速の初期送出に備えるが、しかしながら、開始時に、キャッシュ・ミスによる遅れが発生するという危険性が存在する。

【0063】

図４は、本発明の一実施形態によるセグメント化コンテンツの送出におけるＨＡＳクライアントを示す。具体的には、図４は、（セグメント）予告機能４１４を含むＨＡＳクライアントを示し、マニフェスト・ファイルに列挙されたセグメント識別子を含む１つ以上の予告メッセージを生成するように構成される。一実施形態では、予告機能は、近い将来送出のためにクライアントによって選択されることが予想されるセグメントのセグメント識別子を含む１つ以上の予告メッセージを生成するように構成することができる。

【0064】

このようなセグメントを予測するために、セグメント・セレクタ４１３は、マニフェスト・ケース４０４に格納されているセグメント・リストから少なくとも１つのセグメントを選択するために、ユーザ・ナビゲーション機能４１２からのユーザ・ナビゲーション情報を使用することができる。このプロセスについては、以下で更に詳しく説明する。更に、クライアントは、セグメント引き出し機能４０６、セグメント・バッファ４０８（キャッシュ）、および図１Ａを参照して説明したものと同様のビデオ送出機能４１０（メディア・エンジン）も含むことができる。

【0065】

送出されるセグメントに基づいて、そしてユーザ・ナビゲーション機能によって提供されるユーザ・ナビゲーション情報に基づいて、セグメント・セレクタは、近い将来、即ち、所定時間期間以内にクライアントによって送出のために選択される可能性が最も高いセグメント（１つまたは複数）を予測することができる。ユーザ・ナビゲーション情報は、コンテキスト情報、即ち、ユーザに特定的である情報（例えば、ユーザ・プロファイル、ユーザ・ナビゲーション履歴、ユーザの（ジオ）ロケーション等）を提供し、今後のセグメント送出を予測するためにセグメント・セレクタによって使用される。

【0066】

また、予告機能は、送出されるセグメント化コンテンツに関連付けられた一般的なナビゲーション情報、例えば、特定のコンテンツ項目に関連付けられ、頻繁に要求されるセグメントに関する情報も使用することができる。この一般的なナビゲーション情報は、今後のセグメント送出を予測するために、ユーザ・ナビゲーション情報と共に使用することができる。一実施形態では、マニフェスト・ファイルがクライアントに配信されるときに、コンテンツ・プロバイダまたはＣＤＮにおける制御機能が、この中に一般的なナビゲーション情報を挿入することができる（例えば、人気があると印されたセグメント）。この実施形態については、図１０Ｂを参照して更に詳しく説明する。他の実施形態では、予告機能は、一般的なナビゲーション情報を他の通信チャネルを介して、コンテンツ・プロバイダ、ＣＤＮ、または第三者から受信することもできる。

【0067】

予測されたセグメント（１つまたは複数）がセグメント・バッファ内にない場合、通告機能(announcement function)は、近い将来、これらの予測されたセグメントが要求されることをＣＤＮに通告するために、予測されたセグメント（１つまたは複数）のセグメント識別子を含む１つ以上の予告メッセージをネットワークに送り始めることができる。予告メッセージに基づいて、ＣＤＮ（またはＣＤＮにおける配信ノード）は、ＣＤＮ（またはＣＤＮにおける配信ノード）が、予告メッセージにおいて特定されたセグメントの内少なくとも一部がＣＤＮにおいて入手可能でないと判断した場合、予告メッセージにおいて述べられたセグメントの収集を開始することができる。

【0068】

図５は、本発明の実施形態にしたがって、セグメント化コンテンツをストリーミングするネットワーク・ノードを模式的に示す。具体的には、図５は、セグメント・ファイルを格納するためのキャッシュ５０８（記憶媒体）と、セグメントの収集および格納ならびにセグメントのクライアントへの配信を制御するためのキャッシュ制御機能５１２とを含むネットワーク・ノード５０２を模式的に示す。ネットワーク・ノード（コンテンツ配信ネットワークの一部であってもよい）は、要求メッセージ、例えば、ＨＴＴＰ ＨＥＡＤ、ＨＴＴＰ ＧＥＴ、またはＨＴＴＰ ＰＯＳＴのようなＨＴＴＰ要求メッセージを１つ以上のクライアントまたはＣＤＮの要求ルーティング・ノードから受信するように構成することができる。キャッシュ制御機能は、予告情報におけるセグメントの入手可能性を確実にするために、予告情報を含む予告メッセージによってトリガされるように構成される。

【0069】

ある実施形態では、ネットワーク・ノードはフィルタ機能５１３を含むことができる。予告メッセージが、ＨＴＴＰ ＨＥＡＤ、ＧＥＴ、またはＰＯＳＴメッセージ（前述の通り）というようなＨＴＴＰメッセージとして実施される場合、配信ノードにおけるフィルタ機能５１３は、配信ノードがＨＴＴＰ要求メッセージ５０６間で区別することを可能にするために使用することができる。フィルタは、メッセージ（のヘッダ）における予告インディケータの存在をチェックすることによって、標準的なＨＴＴＰメッセージと特殊な予告ＨＴＴＰメッセージとの間で区別することができる。要求メッセージが標準的なＨＴＴＰ要求メッセージ（従来のセグメント要求に関連付けられたＨＴＴＰ要求）である場合、要求されたセグメントは、キャッシュ５０６から選択され、そのセグメントを要求したクライアント５１０に送られる。要求メッセージが、予告情報（予告インディケータを含む）を含む、および／または配信ノードによって予告メッセージとして解釈されるべき「特殊」（ＨＴＴＰ）要求メッセージである場合（例えば、ＣＤＮがＨＴＴＰ ＨＥＡＤメッセージのようなある種のＨＴＴＰメッセージを予告メッセージとして解釈すべき場合）、フィルタは、メッセージがキャッシュ制御機能５１２に転送され、セグメント５０７の入手可能性をチェックするためにキャッシュ制御機能５１２がトリガされることを確認し、セグメントが入手可能でない場合、このセグメントをコンテンツ起源から引き出すために、セグメント引き出しプロセス５０９（例えば、コンテンツ収集プロセス）をトリガする。予告メッセージが、他のメッセージとは全く異なる場合、または予告メッセージをネットワークに送信するために別個の通信チャネルが使用される場合、フィルタ機能を使用する必要はない。

【0070】

実施形態では、キャッシュ・コントローラが、キャッシュに格納されているセグメントを追跡し、ある種の規則にしたがってセグメントをキャッシュから除去するキャッシュ・アルゴリズムを含むこともできる。キャッシュ・コントローラは、キャッシュに格納されているセグメントに時間（例えば、タイムスタンプ）を割り当て、キャッシュ・コントローラがキャッシュにおけるセグメントの格納時間を判定できるようにすることができる。セグメントが所定の（最大）期間よりも長い期間格納されている場合、キャッシュ・コントローラはこのセグメントをキャッシュから除去することができる。ある実施形態では、一定期間内に１つのセグメントが要求された回数を、キャッシュ・コントローラが追跡することもできる。多くの回数要求されたセグメント（人気のあるセグメント）は、それよりも人気がないセグメントよりも長い期間キャッシュに格納することができる。このようにして、キャッシュ・コントローラは、古いそして人気が低いセグメントをキャッシュから除去することを確保する。

【0071】

実施形態では、セグメントの入手可能性をチェックするためにキャッシュ・コントローラがトリガされ、それが入手可能であるが、所定時間以内にキャッシュ・アルゴリズムによってストレージからそのセグメントが除去されると判断された場合、キャッシュ・コントローラは、このセグメントの入手可能性が確保されるように、このセグメントの格納時間を延長することができる。

【0072】

ある実施形態では、フィルタ機能は、他のネットワーク・ノード、例えば、別個の単体ノードにおいて、またはコンテンツ配信ネットワークの要求ルーティング・ノードにおいて実装されてもよい。

【0073】

図６は、本発明の一実施形態にしたがってセグメント化コンテンツをストリーミングするシステムを示す。具体的には、図６は、ＣＤＮ系コンテンツ配信システムを示し、このシステムは、ＣＤＮ相互接続インターフェース６６４を介して少なくとも第２ＣＤＮ６０４（下流側ＣＤＮとも呼ぶ）に相互接続された第１ＣＤＮ６０２（上流側ＣＤＮとも呼ぶ）を含む。

【0074】

コンテンツ配信システムは、更に、クライアントをホストする１つ以上の端末６０８にトランスポート・ネットワーク４０７を介して接続されたコンテンツ・ソース６０６も含むことができる。コンテンツ・ソースは、コンテンツ・プロバイダ・システムＣＰＳ、コンテンツ準備システム、または他のＣＤＮに関係することができる。ＣＰＳは、コンテンツ、例えば、ビデオ・タイトルを顧客(customer)に提供するように構成することができ、ビデオ送出について図４を参照して説明したように、顧客はＨＡＳクライアントを使用してコンテンツを購入し受信することができる。

【0075】

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

【0076】

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

【0077】

図７は、本発明の他の実施形態によるセグメント化コンテンツのストリーミング・プロセスのプロトコル・フローを示す。このプロセスは、図３Ａを参照して説明したのと同様に、マニフェスト・ファイルの配信から開始することができる。ＨＡＳクライアントによってマニフェスト・ファイルを解析することができ（ステップ７０４）、その後、ＨＡＳクライアントは、１組のセグメント識別子（ＵＲＬ）を含む予告メッセージを用意し、この予告メッセージを前記コンテンツ配信ネットワーク、具体的には、前記コンテンツ配信ネットワークにおけるコンテンツ配信ネットワークに送る（ステップ７０５）。

【0078】

この特定的な実施形態では、配信ノードは、所定の期間内にコンテンツ配信ネットワークによって収集されたセグメントを追跡することができる。したがって、他のＨＡＳクライアントから同じセグメントについての第２予告メッセージが受信されたときに、同じ期間において１つのセグメントが２回収集されないように、前述の予告メッセージを削除する(drop)（即ち、排除する）ことができる。予告メッセージを削除しない場合、このメッセージが解析され、図３Ａを参照して説明したのと同様に、収集プロセスが開始するおそれがある。このように、ある期間における最初の予告メッセージのみが、次のアクション、例えば、図３Ａを参照して説明したプロセスと同様の収集プロセスをトリガするか、あるいは、キャッシュから除去されようとしているセグメントの（最大）格納時間の延長をトリガする。更に他の実施形態では、配信ノードまたは起源サーバ(origin server)の過負荷を回避するために、予告メッセージを排除することもできる。

【0079】

図８Ａおよび図８Ｂは、本発明の種々の実施形態によるセグメント化コンテンツのストリーミング・プロセスのプロトコル・フローを示す。図８Ａのプロセスは、コンテンツ・プロバイダ（ＣＰ）がビデオ・タイトルに関連付けられたマニフェスト・ファイルをＨＡＳクライアントに供給する（ステップ８００）ことから開始することができる。この場合、マニフェスト・ファイルは、セグメント識別子と、ＣＤＮＡの要求ルータへのポインタ（例えば、ＵＲＬ）とを含むことができる。ファイルを解析した後（ステップ８０２）、クライアントは、ＨＴＴＰメッセージ、例えば、クライアントが近い将来要求しようとしそうなセグメントのセグメント・ロケータ（ＵＲＬ）を含むＨＴＴＰ ＨＥＡＤメッセージの形態で予告メッセージを用意することができる。更に、ＨＥＡＤメッセージのＨＴＴＰヘッダは、ＨＥＡＤメッセージが予告メッセージであることを示し、ＣＤＮが標準的なＨＴＴＰメッセージとＨＴＴＰメッセージとの間で区別することを可能にする予告インディケータを含むフィールドを含むことができる。ＨＴＴＰメッセージは、前記セグメントがクライアントによって要求されたときに前記配信ノードまたはコンテンツ配信ノードによる前記セグメントの入手可能性を確保するために、ＣＮＤにおけるキャッシュ制御機能（例えば、ＣＤＮにおける配信ノードのキャッシュ制御機能）をトリガするはずである(should)。

【0080】

その後、ＨＥＡＤメッセージは、ＣＤＮの要求ルーティング・ノードに送られる（ステップ８０４ａ）。ＨＥＡＤメッセージに応答して、要求ルーティング・ノードは、要求されたセグメントが格納されている配信ノードに関連付けられた位置情報を含むＨＴＴＰ ＲＥＤＩＲＥＣＴメッセージを送ることができる。

【0081】

ＲＥＤＩＲＥＣＴメッセージを受信すると、クライアントはＤＮＳ要求を実行して、位置情報を解明して配信ノードのＩＰアドレス（図示せず）を得ることができる。クライアントは、配信ノードのＩＰアドレスをマニフェスト・ファイルに挿入することによって、マニフェスト・ファイルを更新することができる（ステップ８０８）。更に、ＲＥＤＩＲＥＣＴメッセージに応答して、クライアントは、配信ノードのアドレスを使用して、ＨＴＴＰ ＨＥＡＤメッセージの形態とした予告メッセージを配信ノードに再度送ることができる（ステップ８１０）。配信ノードのフィルタ機能は、ＨＥＡＤメッセージが予告メッセージであることを解析（判定）することができるので（ステップ８１２）、コンテンツ起源からセグメントを収集するための収集プロセスを開始するために、キャッシュ制御機能をトリガすることができる（８１４、８１６）。

【0082】

したがって、この例では、予告メッセージは、所定時間内にクライアントへの配信のためにある種のセグメントが入手可能でなければならないことを配信ノードに通告するためだけでなく、マニフェスト・ファイルの一部を事前に解明するためにも使用される。予告および事前解明プロセスの組み合わせにより、セグメント化コンテンツの高速で効率的な処理が可能になる（即ち、セグメントの要求、配信、および送出）。

【0083】

図８Ｂのプロセスは、図８Ａにおけるプロセスと同様である。しかしながら、図８Ｂのプロセスでは、要求ルーティング・ノードはコンテンツ配信ネットワークにおける配信ノードＤ１にメッセージを転送する。したがって、図８Ｂのプロセスは、コンテンツ・プロバイダ（ＣＰ）がビデオ・ファイルに関連付けられたマニフェスト・ファイルをＨＡＳクライアントに供給すること（ステップ８００）から開始することができる。この場合、マニフェスト・ファイルは、セグメント識別子と、ＣＤＮの要求ルータへのポインタ（例えば、ＵＲＬ）を含むことができる。ファイルを解析した後（ステップ８０２）、クライアントはＨＴＴＰメッセージの形態とした予告情報、例えば、クライアントが近い将来要求しようとしそうなセグメントのセグメント・ロケータ（ＵＲＬ）を含むＨＴＴＰ ＨＥＡＤを用意することができる。ＨＥＡＤメッセージのＨＴＴＰヘッダは、ＨＥＡＤメッセージが予告メッセージであることを示すフィールドを含むことができる。

【0084】

その後、ＨＥＡＤメッセージは、ＣＤＮの要求ルーティング・ノードに送られる（ステップ８０４ｂ）。ＨＥＡＤメッセージに応答して、要求ルーティング・ノードは、要求されたセグメントが格納されている配信ノードに関連付けられた位置情報を含むＨＴＴＰ ＲＥＤＩＲＥＣＴメッセージを送ることができる（ステップ８０５ｂ）。ＲＥＤＩＲＥＣＴメッセージを受信すると、クライアントはＤＮＳ要求を実行して、位置情報を解明し、配信ノードのＩＰアドレス（図示せず）を得ることができる。クライアントは、配信ノードのＩＰアドレスをマニフェスト・ファイルに挿入することによって、マニフェスト・ファイルを更新することができる（ステップ８０８）。

【0085】

しかしながら、この特定的な実施形態では、クライアントは他のＨＥＡＤメッセージでリダイレクトに応答しない。代わりに、予告情報を含むＨＥＡＤメッセージに応答して、要求ルーティング・ノードは、予告情報を含むＨＥＡＤメッセージを、要求されたセグメントを含む配信ノードに送ることができる（ステップ８０６ｂ）。この配信ノードは、２００ＯＫメッセージでＨＥＡＤメッセージに応答することができる（ステップ８０７ｂ）。したがって、予告メッセージはこうして配信ノードによって受信され、この配信ノードは情報を解析し（ステップ８１２）、予告メッセージにおいて特定されたセグメントがクライアントに入手可能であるか否か検証することができる。その後、本プロセス（ステップ８１４〜８２４）は図８Ａにおいて示したプロセスと同一とすることができる。この実施形態は、予告プロセスの一部が、ネットワーク内で行われることによって、クライアント上の負荷を低減するという利点を得ることができる。

【0086】

図９は、本発明の一実施形態にしたがってマニフェスト・ファイルの少なくとも一部のセグメント・ロケータを事前に解明する例を示す。具体的には、図９は、マニフェスト・ファイル内の情報の一部を事前に解明するために、所定の時間期間内に要求されようとする確率が非常に高い１つ以上のセグメントを予告するプロセスを、クライアントがどのように使用できるかという例を示す。事前解明は、セグメント・ロケータ、例えば、端末のマニフェスト・キャッシュに格納されているＵＲＬの所定部分を、配信ノードのＩＰアドレスと置き換えることを含むことができる。第１マニフェスト・ファイル７００は、図８を参照して説明したように、コンテンツ・プロバイダからクライアントによって受信されるとよい。この場合、マニフェスト・ファイルは、多数のいわゆる時間的にセグメント化されたコンテンツを指す。

【0087】

図９におけるマニフェスト・ファイルは、ＣＤＮＡのドメイン内に格納されているセグメント識別子（ファイル名）Segment1-1.avi、Segment1-2.avi、Segment1-3.avi、およびSegment1-4.aviによって定められる４つのセグメントを含む、時間的にセグメント化されたコンテンツ・ファイルを定めることを示す。ここでは、ＵＲＬの所定の部分central.cdn_A.com（９０１ａ〜９０１ｄ）は、ＣＤＮＡ内にある一般的な要求ルーティング（ＲＲ）ノードを指し示すことができる。したがって、これらのセグメント・ロケータは、セグメントを引き出すことができるノードのネットワーク・アドレスを含まないという意味で、未解明である。このマニフェスト・ファイルがストリーミング・プロセスにおいてクライアントによって使用されるとき、予告プロセスの間に、図８を参照して説明したように、セグメント・ロケータも事前に解明することができる。

【0088】

事前解明プロセスの間、４つのセグメントに関連付けられたＵＲＬ９０１ａ〜９０１ｄにおける未解明セグメント・ロケータの少なくとも一部central.cdn_A.comを、ネットワーク・アドレスで置き換えることができる。このように、４つの解明されたＵＲＬ９０３ａ〜９０３ｄは、各々、これらのセグメントを引き出すことができる配信ノードのネットワークを含んで形成することができる。解明されたＵＲＬは、例えば、１つ以上の配信ノードを指し示すことができ、その一部は、例えば、他のＣＤＮＢにおいて突き止めることができる。図９において見られるように、これらのセグメントは全て、ネットワーク・アドレス２４．６７．１３．５７によって識別される１つの配信ノードから引き出すことができる。

【0089】

図１０Ａは、近い将来クライアントによって要求されることが予想されるセグメントの予告をサポートするか否かネットワークに要求するためのプロトコル・フローを示す。このプロセスにおいて、予告サポート情報メッセージをコンテンツ配信ノードに送ることができる（ステップ１０００）。フィルタがメッセージを解釈することができない場合（ステップ１００１）（またはこのようなフィルタがない場合）、このメッセージは削除され、否定応答（例えば、４００−悪い要求、または４０５−許されていない方法というような、ＨＴＴＰ４０×応答メッセージ）がクライアントに返送されるか、または応答は返送されない（ステップ１００２）。あるいは、予告サポート情報メッセージがフィルタによって解釈可能である場合、メッセージを解析することができ（ステップ１００３）、クライアントが予告プロセスを実行できることをクライアントが知るように、サポート確認応答メッセージ、例えば、予告サポート（ＨＴＴＰ）をクライアントに返送することもできる（ステップ１００４）。

【0090】

図１０Ｂは、本発明の実施形態によるマニフェスト・ファイルの少なくとも一部を示す。このマニフェスト・ファイルは、ＣＤＮが予告プロセスをサポートすること、および／またはクライアントがその予告機能を使用する必要があることの予告インディケータ１０１０を含むことができる。更に、マニフェスト・ファイルは、（未解明の）セグメント・ロケータ１１０２（ＵＲＬの一部として）も含むことができる。この特定的な実施形態では、コンテンツ・プロバイダまたはＣＤＮプロバイダは、マニフェスト・ファイル１１００内における特定のセグメント・ロケータに印を付けるために、マーカ１１０１ａ、１１０１ｂを挿入することができる。これらのマーカは、人気のあるセグメント、即ち、頻繁に要求されるセグメントをマニフェスト・ファイル内のマーカに基づいてクライアントによって識別できるように、セグメント・ナビゲーション統計に基づいて挿入されるとよい。このようなマーカは、マニフェスト・ファイルにおいて、１つ以上のセグメント・ロケータを、予告および（望ましければ）事前解明に適しているとして識別することができる。

【0091】

一実施形態では、マーカを格付け値、例えば、人気スコアと関連付けて、この格付けにしたがって未解明のセグメント・ロケータを格付けできるようにしてもよい。このように、これらのマーカは、セグメント・セレクタが、今後のセグメント要求のために、１つ以上の別のセグメント・ロケータを選択するための格付け方式を設けることができる。このように、高人気スコアと関連付けられた未解明のセグメント・ロケータは、それよりも人気スコアが低いものよりも早く、事前に解明することができる。一実施形態では、コンテンツ・プロバイダまたはＣＤＮはこれらのマーカをマニフェスト・ファイルに挿入することができる。他の実施形態では、コンテンツ・プロバイダまたはＣＤＮは、新たなマーク付きマニフェスト・ファイルを生成することもできる。

【0092】

以上で既に端的に論じたように、予告プロセス、そして最終的に事前解明プロセスは、クライアントおよびＣＤＮ間で別個の通信チャネルを通じて実行することもできる。

【0093】

図１１は、本発明の実施形態にしたがって、別個のＷｅｂＳｏｃｋｅｔ通信チャネルを設定するための情報を含むマニフェスト・ファイルを示す。このマニフェスト・ファイルは、ストリーミング・パスと関連付けられた通信チャネル、具体的には、（双方向）ＨＡＳ制御チャネルを設定するためのチャネル設定情報１１２４、１１２６を含むことができる。一実施形態では、チャネル設定情報は、ストリーミング制御機能を含むネットワーク・ノードへの参照を与えるチャネル・ターゲット・パラメータ１１２４を含むことができる。更に、他の実施形態では、チャネル設定情報は、チャネル・パラメータ１１０２、即ち、ストリーミング制御機能／制御チャネル・サーバ機能によって使用されるパラメータを含むことができる。例えば、ＷｅｂＳｏｃｋｅｔの場合、これらのパラメータは、ＷｅｂＳｏｃｋｅｔサブプロトコル、ＷｅｂＳｏｃｋｅｔバージョン等の使用に言及することができる。ＨＡＳ制御チャネルの設定および使用については、図１２を参照して更に詳しく説明する。

【0094】

図１２は、本発明の実施形態による双方向ＨＡＳ制御チャネルの確立を含む、コンテンツ処理デバイス１２３０とサーバ・システム１２３２との間におけるプロトコル・フローを示す。コンテンツ処理デバイスは、ＨＡＳクライアント１２４８を含み、コンテンツ送出のためにメディア・エンジン１２４６を使用することができる。同様に、サーバ・システムは、コンテンツをＨＡＳクライアントにストリーミングするためのＨＴＴＰストリーミング機能１２４２を含むことができる。

【0095】

コンテンツ処理デバイスおよびサーバ・システムは、更に、制御チャネル・クライアント機能（ＣＣＣＦ）１２４４、および制御チャネル・サーバ機能（ＣＣＳＦ）、例えば、ＨＡＳ制御チャネル・サーバ機能１２３４をそれぞれ含むことができ、ＣＣＳＦとＣＣＣＦ１２４４との間にストリーミング制御チャネル１２３６を確立するように構成される。ここでは、ストリーミング制御チャネルは、クライアントとサーバとの間でストリーミング制御情報を交換するために使用することができる。具体的には、ストリーミング制御チャネルは、セグメント化コンテンツ１２３８のクライアントへのストリーミングの間に、サーバ・システムから発したストリーミング制御情報をクライアントに送るために使用することができる。例えば、一実施形態では、ストリーミング制御チャネルは、クライアントがマニフェスト・ファイル（またはマニフェスト更新）を求める要求をサーバ・システムに送るように、更新マニフェスト・トリガをサーバ・システム（または監視システム）からＣＣＣＦに送るために使用することができる。

【0096】

他の実施形態では、制御チャネルは予告メッセージのために使用することもできる。ここでは、プロセスは、他のプロセスを参照して以上で説明したのと同様に、例えば、ユーザがライブ・ストリーミング・イベントに加入する（ステップ１２００）ことから開始することができる。クライアントは、サーバ・システムからマニフェスト・ファイルを得るために、ＨＴＴＰ ＧＥＴ要求を送ることができ、サーバ・システムは、マニフェスト・ファイルをクライアントに送ることによって、この要求に応答することができる（ステップ１２０２、１２０４）。

【0097】

サーバにおけるＣＣＳＦは、チャネル設定情報をマニフェスト・ファイルに挿入するように構成され、これによって、クライアントにおけるＣＣＣＦおよびサーバにおけるＣＣＳＦがストリーミング制御チャネルを設定することが可能になる。したがって、マニフェスト・ファイルの解析中（ステップ１２０６）に、チャネル設定情報をマニフェスト・ファイルから抽出し（例えば、図１１参照）、サーバ−クライアント・ストリーミング制御チャネルを設定するために、コンテンツ処理デバイスにおけるＣＣＣＦによって、チャネル設定要求をサーバにおけるＣＣＳＦに送る（ステップ１２０８）ために使用することができる。

【0098】

一実施形態では、ＣＣＣＦおよびＣＣＳＦは、クライアントとサーバとの間にストリーミング制御チャネルを確立するために、ＷｅｂＳｏｃｋｅｔプロトコルおよびチャネル設定情報を使用するように構成されたＨＴＴＰ ＷｅｂＳｏｃｋｅｔ ＡＰＩを含むことができる。ＷｅｂＳｏｃｋｅｔ接続は、通例、データが容易にファイアウォールおよびＮＡＴを転送(transfer)できるように、標準的なＨＴＴＰポート８０および４４３を使用するが、他のポートを使用することもできる。

【0099】

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

【0100】

更に他の実施形態では、拡張可能メッセージングおよびプレゼンス・プロトコル（ＸＭＰＰ）（http://www.ietf.org/rfc/rfc3920.txt）が使用され、この場合、クライアントはＸＭＰＰクライアントを構成することができ、サーバはＸＭＰＰサーバを構成する。ＳＩＰおよびＸＭＰＰプロトコル双方のメッセージは、draft-ibc-rtcweb-sip-websocket-00およびdraft-moffitt-xmpp-over-websocket-00にしたがって、ＷｅｂＳｏｃｋｅｔを通じてトンネリングすることができる。

【0101】

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

【0102】

実施形態では、ストリーミング制御チャネルは、ネットワークにクライアントにおける予告機能を制御させることができる。例えば、コンテンツ配信ネットワークは、ある種のパラメータまたは状況に応じて、予告機能をアクティブ化または非アクティブ化することができる。例えば、ネットワークは、ある種のセグメントが（突然）人気になった場合に、予告機能をオンに切り替えることができる。実施形態では、配信ノードまたはコンテンツ配信ネットワークが、図１０Ｂにおけるマニフェスト・ファイルと同様の情報を含む更新マニフェスト・ファイルをクライアントに送ることができ、予告インディケータが、ＣＤＮが予告プロセスをサポートすること、および／またはクライアントがその予告機能を使用する必要があることを、クライアントに指示する(instruct)。

【0103】

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

【0104】

他の実施形態では、サーバ・システムは、セグメントを多数のクライアントにストリーミングするように構成することもでき、各クライアントは、図１２を参照して説明したように、ネットワーク開始、例えば、サーバ開始制御を可能にするために、それ自体のストリーミング制御チャネルと関連付けられる。

【0105】

尚、任意の１つの実施形態に関係付けて説明した特徴はいずれも、単独で、または説明した他の特徴と組み合わせて使用でき、更に実施形態の内任意の他のものの１つ以上の特徴と組み合わせて、あるいは実施形態の任意の他のものの任意の組み合わせでも使用できることは理解されよう。

【0106】

本発明の一実施形態は、コンピュータ・システムとの使用のためのプログラム製品として実現することもできる。プログラム製品のプログラム（１つまたは複数）は、実施形態の機能（本明細書において説明した方法を含む）を定め、種々のコンピュータ読み取り可能記憶媒体上に収容する(contain)ことができる。実例的なコンピュータ読み取り可能記憶媒体は、（ｉ）情報が永続的に格納される、書き込み不可の記憶媒体（例えば、ＣＤ−ＲＯＭドライブによって読み取り可能なＣＤ−ＲＯＭのような、コンピュータ内部にあるリード・オンリ・メモリ・デバイス、フラッシュ・メモリ、ＲＯＭチップ、あるいは任意のタイプのソリッド・ステート不揮発性半導体メモリ）、（ｉｉ）変更可能な情報が格納される、書き込み可能な記憶媒体（例えば、ディスケット・ドライブ内部にあるフロッピ・ディスク、またはハード・ディスク・ドライブ、あるいは任意のタイプのソリッド・ステート・ランダム・アクセス半導体メモリ）を含むが、これらに限定されるのではない。

【0107】

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

【0108】

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

【0109】

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

【0110】

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

【0111】

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

【0112】

更に、当業者には認められようが、本発明の態様は、システム、方法、またはコンピュータ・プログラム製品として具体化することもできる。したがって、本発明の態様は、全体的にハードウェアの実施形態、全体的にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア(resident software)、マイクロ・コード等を含む）、またはソフトウェアおよびハードウェアの態様を組み合わせた実施形態という形態を取ることもでき、これらは全て、本明細書では、総合的に「回路」、「モジュール」、「ノード」、または「システム」と呼ぶことができる。更に、本発明の態様は、コンピュータ読み取り可能プログラム・コードが具体化された１つ以上のコンピュータ読み取り可能媒体に具体化されたコンピュータ・プログラム製品の形態を取ることもできる。

【0113】

本明細書において説明した機能ユニットの多くは、一層特定的にこれらの実施独立性を強調するために、モジュール、機能、またはクライアントと称した。例えば、モジュール、機能、またはクライアントは、カスタムＶＬＳＩ回路またはゲート・アレイ、論理チップのような既製の半導体、トランジスタ、あるいはその他のディスクリート部品を含むハードウェア回路として実現することができる。また、モジュール、機能、またはクライアントは、フィールド・プログラマブル・ゲート・アレイ、プログラマブル・アレイ・ロジック、プログラマブル・ロジック・デバイス等のような、プログラマブル・ハードウェア・デバイスに実現することもできる。

【0114】

また、モジュール、機能、またはクライアントは、種々のタイプのプロセッサによる実行のためにソフトウェアで実現することもできる。例えば、コンピュータ読み取り可能プログラム・コードのモジュールとして特定すると、１つ以上の物理または論理ブロックのコンピュータ命令を含むことができ、例えば、オブジェクト、手順、または関数として編成することができる。しかしながら、特定したモジュールの実行可能ファイルは、物理的に一緒に配置される必要はなく、異なる位置に格納された異種の命令が論理的に一緒に合体されると、モジュールを構成し、このモジュールのために述べた目的を達成する。

【0115】

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

【0116】

以下の特許請求の範囲における全ての手段またはステップ・プラス機能エレメントの対応する構造、材料、アクト、および均等物は、他の特許請求されたエレメントと組み合わせて機能を実行するための任意の構造、材料、またはアクトを、具体的に特許請求されたものとして含むことを意図している。本発明の説明は、例示および説明の目的に限って提示されたのであり、網羅的であることや、開示された形態に本発明を限定することを意図するのではない。多くの変更および変形が、本発明の範囲や主旨から逸脱することなく、当業者には明白であろう。

【0117】

本発明の原理および実用的用途を最良に説明するために、そして当業者の他の者が種々の実施形態について本発明を理解することができるために、想定される個々の使用に適した種々の変更と共に、実施形態を選択し説明した。

【図1】

【図2】

【図3A】

【図3B】

【図3C】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9】

【図10A】

【図10B】

【図11】

【図12】

【図13】

【国際調査報告】