JP2017062799A - セグメント化されたコンテンツについての制御されたストリーミング - Google Patents

Abstract

【課題】セグメント化されたコンテンツのクライアント制御によるストリーミングを可能にする方法およびシステムを提供する。【解決手段】マニフェスト・ファイルから選択される少なくとも１つのセグメント識別子に基づいて少なくとも１つのセグメントの配信を要求するステップと、要求されたセグメントに基づいて、マニフェスト・ファイルから、予想される将来のセグメント要求に関連付けられる、少なくとも１つの別のセグメント識別子を選択するステップと、第１のセグメント・ロケ−タに関連付けられるネットワーク情報を取得するために、選択した別のセグメント識別子に関連付けられる第１のセグメント・ロケ−タを事前解決するステップからなる。【選択図】図３

Description

本発明は、セグメント化されたコンテンツについての制御されたストリーミングに関するものである。より詳細には、排他的ではないが、セグメント化されたコンテンツについての制御されたストリーミングを可能にする方法、セグメント化されたコンテンツについてストリーミングを制御するクライアント、クライアントで使用するためのネットワーク・ノードおよびデータ構造、並びにこのような方法を用いたコンピュータ・プログラム製品に関するものである。

従来技術

現在のところ、拡大しているビデオ・ストリーミング技術は、いわゆるセグメント化(segmentation)を用いる。例えば、ＨＴＴＰ適用可能ストリーミング（ＨＡＳ）、スケーラブル・ビデオ符号化（ＳＶＣ）、および空間的にセグメント化したビデオ（例えば、タイル化したビデオ）は、それぞれ、時間、品質、および空間に基づいてセグメント化を用いる。セグメント化処理の間、異なるセグメンント・ファイルおよび／またはストリームの間の関係、並びにセグメントを抽出できる位置について記述する所謂マニフェスト・ファイルが生成されることになる。セグメント・ファイルはセグメント・データを含むファイルに関連し、当該セグメント・データはファイル抽出プロトコル、例えばＨＴＴＰまたはＦＴＰにより抽出することができる。同様に、セグメント・ストリームはセグメント・データを含むストリームに関連し、当該セグメント・データは、ストリーミング・プロトコル、例えばＲＴＳＰ／ＲＴＰまたはＨＡＳにより抽出することができるセグメント・データにより抽出することができる。以降において、セグメント・ファイルまたはストリームについてセグメントと称することがある。更に、ビデオ、より包括的にはセグメント化方式でレンダリングされるコンテンツをセグメント化されたコンテンツ(segmented content)と称することがある。

セグメント化されたコンテンツは、例えば、高品質から低品質へとビデオ・ストリームを切り替えることにより、帯域幅要件の変更に対して動的に調整するのに使用することができる。更に、セグメント化されたコンテンツはまた、ポピュラーなビデオ・セグメントとあまりポピュラーではないビデオ・セグメントの間を区別するのを可能にする。例えば、通例、ビデオの開始に関連付けられるコンテンツは、終了したコンテンツよりもより頻繁に（よりポピュラーに）視聴される（ダウンロード／アクセス／抽出される）ことになる。同様に、低ビットレートでより低い品質のビデオ・コンテンツ（例えば、最低解像度のＨＡＳセグメントまたはＳＶＣ基礎レイヤ）は、高品質コンテンツ（例えば、より高い解像度のＨＡＳセグメントまたはＳＶＣ強化レイヤ）よりもより頻繁に視聴される（ダウンローにアクセス／抽出される）ことになる。

したがって、コンテンツをセグメント化するときは、特定のセグメントが他のコンテンツよりも消費者によって（非常に）より頻繁に要求されることになる。この特性は、コンテンツを消費者に配信するように構成されるコンテンツ配信ネットワーク（ＣＤＮ）により使用されると有利なものとなる。ＣＤＮは、例えば、ＣＤＮ内の複数のノードにおいてよりポピュラーなコンテンツに関連付けられるセグメントを格納することができる。その結果、（とても離れたサーバから多くのポピュラーなセグメントを取得することによりネットワーク帯域が輻輳することがあるというような）帯域幅の課題を低減させることができ、配信の効率性が保証される。ＣＤＮコンテンツ位置マネージャは、セグメントを抽出するＣＤＮ内の位置を中央で管理することができる。

クライアントによる、ＣＤＮ内に格納されるセグメントへのアクセスを可能とするために、クライアントには、セグメント識別子と、ネットワーク内の位置をポイントするセグメント・ロケータと、についてのリストを識別する所謂マニフェスト・ファイルが提供され、クライアントがセグメントを抽出するのを可能にする。通例、プレイ・アウトが開始される前に、クライアント（デバイス）に関連付けられるセグメント・バッファが所定の数のセグメントにより負荷を掛けられるように、クライアントはセグメントを抽出するように構成される。更にまた、プレイ・アウトの間、クライアントは、マニフェスト・ファイルに基づいてセグメントを継続的に抽出し、その結果、十分なセグメントがバッファ内に維持される。このように、セグメントの抽出に関連するレイテンシは、セグメントのシームレスなプレイ・アウトと干渉することはない。

しかしながら、幾らかの場合では、クライアントは、コンテンツのプレイ・アウト（例えば、早送り(fast-forwarding)、パン(panning)、ズーム、および／またはタイル化）をユーザに相互作用させることもある。更に、ユーザは、別のレートまたはビデオ品質に切り替えるように、クライアントに指示することもある。上記の全ての場合において、セグメントのプレイ・アウトはバッファ内で利用可能なことを必要とはしなくてもよく、その結果、クライアントは、オンザフライ(on the fly)で（ＣＤＮまたは別のネットワークから）そのセグメントの抽出を開始することになる。しかしながら、この処理は相当量の時間を要する場合がある。何故ならば、セグメントが、ＤＮＳルック・アップおよびＨＴＴＰリダイレクトを伴うことがある解決処理を用いて位置特定および抽出されることになるからである。更には、幾らかの場合では、コンテンツ・アイテム（例えば、ビデオ／動画）に関連付けられる（コンテンツ）セグメントは、２つ以上の異なるＣＤＮに所属する（ＣＤＮ／他のネットワークの）ノードに格納する場合がある。その場合は、どの中央の位置マネージャも、異なるＣＤＮドメイン内のセグメントを位置特定するのに利用可能ではない。それ故、第１のＣＤＮに関連付けられるマニフェスト・ファイルは、別のＣＤＮにおいてルーティング機能を参照することのみができる。何故ならば、第１のＣＤＮは、第２のＣＤＮにあるセグメントの位置に関する知識を有しないからである。別の（第２の）ＣＤＮからのあるセグメントが要求される都度、その他の（第２の）ＣＤＮへのルーティング要求は必要とされる。また、１つ以上の更なるルーティング要求（および応答）が別の（第２の）ＣＤＮで生成されることがある。このような要求は、要求ルーティングの遅延を生じさせることになり、その結果、クライアントが要求されたセグメントを受信するのにより多くの時間、最大数秒も掛かることになる。

したがって、上記のことから、ユーザの如何なる相互作用なしで、ＤＮＳ要求に関連する遅延、リダイレクトおよび／またはＣＤＮ間（ＣＤＮ−Ｉ）の要求ルーティングは、（ビデオ）ストリームの品質についてユーザの知覚にほとんど影響しないということになる。何故ならば、クライアントは通例、バッファされた少しのセグメントを有し、あるスラックを許容するからである。しかしながら、（セグメント化された）コンテンツとの相互作用が認められる場合は、バッファ内で利用可能ではないセグメントについてのプレイ・アウトは、相当量の時間を要する。何故ならば、セグメントは、解決処理を用いて位置特定される必要があるからである。この処理は、複雑に相互接続されたＣＤＮの場合、最大で秒数も掛かることになり、その結果、セグメント化された（ビデオ）コンテンツのシームレスなプレイ・アウトはもはや可能ではなく、ユーザ経験(user experience)は深刻に格下げされる。

したがって、当該技術分野では、セグメント化されたコンテンツについてクライアントへの効率的なストリーミングの必要性が存在する。具体的には、ユーザがセグメント化されたコンテンツと相互作用する場合であっても、セグメント化されたコンテンツのシームレスなプレイ・アウトを提供する方法およびシステムの必要性が存在する。

本発明の目的は、当該技術分野において公知とされる欠点の内の少なくとも１つを削減または排除して、本発明の第１の態様における方法を提供することである。

当該方法は、１つ以上の配信ノードを位置特定するマニフェスト・ファイルに基づいて、セグメント化されたコンテンツのストリーミング、好ましくはクライアントにより制御される(client-controlled)ストリーミングを可能にする。当該方法は次のステップの内少なくとも１つを含むことができる。即ち、マニフェスト・ファイルに基づいて、少なくとも１つのセグメントの配信を要求するステップ、当該セグメントの要求に関連付けられるセグメント識別子に基づいて、マニフェスト・ファイルから少なくとも１つの別のセグメント識別子を選択するステップであって、当該別のセグメント識別子が、予想された将来のセグメント要求に関連付けられるステップ、および、第１のセグメント・ロケ−タに関連付けられたネットワーク情報を取得するために、上記選択した別のセグメント識別子に関連付けられる第１セグメント・ロケ−タの少なくとも一部を事前解決するステップである。一実施形態では、マニフェスト・ファイルは、１つ以上のセグメント識別子および／または１つ以上の関連するセグメント・ロケータを含む。他の実施形態では、配信ノードは、当該セグメント識別子によって識別される１つ以上のセグメントをクライアントに配信するように構成できる。更なる他の実施形態では、セグメント・ロケ−タは、ネットワーク・ノードをポイントする所定のＵＲＬの一部とすることができる。

したがって、本方法は、クライアントが、マニフェスト・ファイルにリストされ、将来要求されることになると予想されるセグメントを選択することを可能にし、また、クライアントによって要求される１つ以上のセグメントの内の１つに基づいて、これら選択されるセグメントに関連付けられる１つ以上のセグメント・ロケータを少なくとも部分的に事前解決することを可能にする。このようにして、要求ルーティング、ＤＮＳ要求および／またはリダイレクトに関連する遅延は、除去されるかまたは少なくとも実質的に削減される。その結果、ユーザ相互作用の間においてシームレスなまたは少なくとも実質的にシームレスなセグメントのプレイ・アウトを実現することができる。

一実施形態では、ネットワーク情報は、第１セグメント・ロケ−タの少なくとも一部に関連付けられるネットワーク・アドレスの少なくとも一部に関する情報や、選択した別のセグメント識別子に関連付けられる第１のセグメント・ロケ−タが、上記予想された将来のセグメント要求に関連付けられるセグメントの配信のための配信ノードをポイントするか、若しくは、上記予想された将来のセグメント要求のリダイレクトのためにネットワーク・ノードをポイントするかについての情報、および／または、上記選択された別のセグメント・ロケータに関連付けられる第２のセグメント・ロケ−タの少なくとも一部を含むことができる。他の実施形態では、本方法は、第１セグメント・ロケ−タがリダイレクトのためにネットワーク・ノードをポイントする場合に、当該第１セグメント・ロケ−タを、上記選択された別のセグメント識別子に関連付けられる第２のセグメント・ロケ−タに事前解決するステップを含むことができる。更なる他の実施形態では、上記ネットワーク情報に基づいて上記マニフェスト・ファイルを修正するステップを含む。したがって、抽出したネットワーク情報に基づいて、マニフェスト・キャッシュに格納されるマニフェスト・ファイルを更新することができる。このようにして、特に、クライアントに関連付けられる事前解決機能は、継続的におよび動的に、事前解決セグメント・ロケータの全部および／または一部を用いてマニフェスト・ファイルを更新することができる。

一実施形態において、本方法は、上記第２セグメント・ロケ−タの少なくとも一部に基づいて、上記マニフェスト・ファイルを修正するステップであって、好ましくは、第１セグメント・ロケ−タの少なくとも一部を第２セグメント・ロケ−タの少なくとも一部で置き換えるステップを含むことができる。事前解決ステップについての結果は、元のセグメント・ロケータを部分的な事前解決された別のセグメント・ロケータにリプレイおよび／または修正するのに使用することができる。その結果、部分的に事前解決されるセグメント・ロケータに関連付けられるセグメントが要求されると、セグメント・ロケータを解決することに関連する遅延が実質的に削減される。

更なる実施形態では、本方法は、第２セグメント・ロケータが、予想された将来のセグメント要求に関連付けされるセグメントの配信のために、配信ノードのネットワーク・アドレスに関連付けられる場合に、上記第２セグメント・ロケータに基づいて、マニフェスト・ファイルを修正するステップを含む。事前解決ステップの結果は、元のセグメント・ロケータを完全に事前解決したセグメント・ロケータにリプレイおよび／または修正するのに使用することができる。その結果、セグメントが要求されても、セグメント要求の解決は必要ない。

更なる他の実施形態では、本方法は次のステップの内の少なくとも１つを含むことができる。即ち、ネットワーク情報についての要求を、第１セグメント・ロケータに関連付けられるネットワーク・ノードに送信するステップ、応答メッセージを受信するステップ、上記選択した別のセグメント識別子に関連付けられる第１セグメント・ロケータが、上記予想された将来のセグメント要求に関連付けられるセグメントの配信のために配信ノードをポイントするか、または上記予想された将来のセグメント要求のリダイレクトのためにネットワーク・ノードをポイントするかについて、応答メッセージに基づいて決定するステップである。

更なる他の実施形態では、ネットワーク情報についての要求が、ＨＴＴＰ、ＲＴＳＰおよび／若しくはＤＮＳのプロトコル・メッセージ、好ましくは、ＨＴＴＰＨＥＡＤメッセージ若しくはＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージを含むことができ、並びに／または、上記応答メッセージがＨＴＴＰ若しくはＲＴＳＰの応答メッセージである。

一実施形態では、上記事前解決ステップは、少なくとも１つのセグメントの少なくとも一部の配信の間、バックグラウンド処理として実施することができる。

一実施形態では、本方法は、ユーザ・プロファイル、ユーザ・ナビゲーション履歴、セグメント化されたコンテンツとのユーザ相互作用、並びに／またはユーザの地理的位置の少なくとも一部に基づいて、上記少なくとも１つの別のセグメント識別子を選択するステップを含むことができる。したがって、予想される将来のセグメント要求に関連付けられるセグメントの選択は、ユーザ関連情報に基づくものとすることができる。

一実施形態では、マニフェスト・ファイルは、将来のセグメント要求のために１つ以上の別のセグメント識別子をマークする１つ以上のマーカを含み、好ましくは、当該マーカはランキング値を含む。このようにして、事前解決のためのセグメントの選択は、マニフェスト・ファイルの情報に基づくことができる。この情報は、ＣＤＮによってまたはコンテンツ・プロバイダによって、マニフェスト・ファイルに挿入することができる。

一変更態様では、事前解決するステップは、次の内の少なくとも１つを含むことができる。即ち、ネットワーク情報についての要求、好ましくは、ＨＴＴＰＨＥＡＤメッセージまたはＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージを第１のコンテンツ配信ネットワーク（ＣＤＮ１）に送信するステップであって、上記要求が少なくとも選択される別のセグメント識別子を含むステップ、第１コンテンツ配信ネットワーク（ＣＤＮ１）が、選択される別のセグメント識別子によって識別されるセグメントについての将来の配信をネゴシエートするために、上記選択された別のセグメント識別子を含むＣＤＮ間要求メッセージ、好ましくはＤＥＬＩＶＥＲＹＲＥＱＵＥＳＴメッセージを、第２のコンテンツ配信ネットワーク（ＣＤＮ２）に送信するステップ、および／または、第１コンテンツ配信ネットワーク（ＣＤＮ１）が、位置情報、好ましくは第２コンテンツ配信ネットワーク（ＣＤＮ２）内の１つ以上の配信ノードに関連付けられるネットワーク・アドレスまたはセグメント・ロケータを含むＣＤＮ内応答メッセージ、好ましくは、ＤＥＬＩＶＥＲＹＲＥＳＰＯＮＳＥメッセージを受信するステップであって、１つ以上の配信ノードが、上記選択された別のセグメント識別子によって識別されるセグメントをクライアントに配信するように構成されるステップである。したがって、事前解決処理の間、第１のＣＤＮ内のネットワーク・ノードは、セグメント識別子の事前解決に関連付けられるネットワーク情報についての要求を識別し、当該要求を第２のＣＤＮ内のネットワーク・ノードに転送することができる。これにより、事前解決処理の効率性を改良することができる。

一実施形態では、ＣＤＮ間(inter-CDN)要求メッセージはフラグを含むことができ、第２コンテンツ配信ネットワーク（ＣＤＮ２）により、ＣＤＮ間要求メッセージがセグメント・ロケータの事前解決に関連付けられるのを判断することを可能にする。

他の実施形態では、ＣＤＮ間要求メッセージが、ＨＴＴＰ ＨＥＡＤメッセージ若しくはＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージに基づいて実装され、これにより、第２コンテンツ配信ネットワーク（ＣＤＮ２）により、ＣＤＮ間メッセージがセグメント・ロケータについての事前解決に関連付けられるのを判断することを可能にする。

更なる他の実施形態では、マニフェスト・ファイルは、第１のコンテンツ配信ネットワーク（ＣＤＮ１）内の１つ以上の配信ノードに関連付けられる第１の位置情報、好ましくはネットワーク・アドレス、および第２のコンテンツ配信ネットワーク（ＣＤＮ２）内の１つ以上の配信ノードに関連付けられる第２の位置情報、好ましくはネットワーク・アドレスを含むことができる。

更なる実施形態では、上記セグメント化されたコンテンツは、時間的にセグメント化されたコンテンツであり、上記クライアントは、時間的距離を規定する時間近接度パラメータを用いる。その結果、クライアントによって現在処理されている時間的セグメントから時間近接度距離内に配置される時間的セグメントを識別する１つ以上のセグメント識別子を、１つ以上の関連するセグメント・ロケータを事前解決するために、マークする、および／または選択することができ、或いは、
上記セグメント化されたコンテンツは、空間的にセグメント化されたコンテンツであり、上記クライアントは、空間的距離を規定する空間的近接度パラメータを用いる。その結果、クライアントによって現在処理されている空間的セグメントから空間近接度距離内に配置される空間的セグメントを識別する１つ以上のセグメント識別子を、１つ以上の関連するセグメント・ロケータを事前解決するために、マークする、および／または選択することができ、或いは、
上記セグメント化されたコンテンツは、品質的にセグメント化されたコンテンツであり、上記クライアントは品質的距離を規定する品質的近接度パラメータを用いる。その結果、クライアントによって現在処理されている品質的セグメントから品質的近接度距離内に配置される品質的セグメントを識別する１つ以上のセグメント識別子を、１つ以上の関連するセグメント・ロケータを事前解決するために、マークする、および／または選択することができる。

更なる態様では、本発明は、ネットワーク内の１つ以上の配信ノードにホストされたセグメント化されたコンテンツについてのクライアント制御ストリーミングのためのクライアントに関するものである。当該クライアントは、マニフェスト・ファイルの少なくとも一部を格納するためのマニフェスト・キャッシュであって、当該マニフェスト・ファイルが、１つ以上のセグメント識別子と、１つ以上のセグメント識別子によって識別される１つ以上のセグメントをクライアントに配信するにように構成される１つ以上の配信ノードを位置特定するための１つ以上の関連のセグメント・ロケ−タ、好ましくは１つ以上のＵＲＬを含むマニフェスト・キャッシュ、マニフェスト・ファイル内の少なくとも１つのセグメント識別子に基づいて少なくとも１つのセグメントの配信を要求するセグメント抽出機能、少なくとも１つのセグメント識別子に基づいて少なくとも１つの予想される将来のセグメント要求に関連付けられる少なくとも１つの別のセグメント識別子を選択するように構成されるセグメント・セレクタ、そして、第１セグメント・ロケータに関連付けられるネットワーク情報を取得するために少なくとも１つの別のセグメント識別子に関連付けられる第１セグメント・ロケータの少なくとも一部を事前解決する事前解決機能を含む。

他の態様では、本発明は、先に説明したクライアントと共に使用するためのネットワーク・ノードに関するものである。ネットワーク・ノードは、第１のコンテンツ配信ネットワーク（ＣＤＮ１）に関連付けられる。また、ネットワーク・ノードは、セグメント・ロケータに関連付けられるネットワーク情報についての要求をクライアントから受信し、好ましくは、上記要求が、ＨＴＴＰＨＥＡＤメッセージまたはＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージを含み、セグメント・ロケータが、セグメントを識別するセグメント識別子に関連付けられ、ＣＤＮ間要求メッセージ、好ましくは、セグメントの将来の配信をネゴシエートするために、上記セグメント・ロケータおよび／またはセグメント識別子の少なくとも一部を含むＤＥＬＩＶＥＲＹＲＥＱＵＥＳＴメッセージを、第２のコンテンツ配信ネットワーク（ＣＤＮ２）に送信するように構成される。ＣＤＮ間要求メッセージはフラグを含み、ＣＤＮ間要求メッセージは、ＨＴＴＰＨＥＡＤメッセージ若しくはＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージに基づくものであり、フラグ、ＨＴＴＰＨＥＡＤメッセージ、またはＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージにより、ＣＤＮ間メッセージがクライアントによって要求されたセグメント・ロケータについての事前解決に関連付けられることを、第２コンテンツ配信ネットワーク（ＣＤＮ２）が判断するのを可能にする。

更なる別の態様では、本発明は、先に説明したようなクライアントで使用するためのデータ構造、好ましくはマニフェスト・ファイルである。データ構造は、１つ以上のセグメント識別子、および当該１つ以上のセグメント識別子によって識別される１つ以上のセグメントをクライアントに配信するように構成される１つ以上の配信ノードを位置特定するための１つ以上の関連のセグメント・ロケ−タ、好ましくはＵＲＬを含む。当該データ構造は更に、上記セグメント識別子の内の１つ以上に関連付けられる１つ以上のマーカを含む。１つ以上のマーカは、クライアントの事前解決機能が、将来のセグメント要求について別のセグメント識別子を選択するのを可能にする。好ましくは、１つ以上のマーカは、ランキング値、好ましくは有名度スコアに関連付けられる。

本発明はまた、コンピュータのメモリにおいて実施したときに、先に説明した方法ステップの少なくとも１つを実行するように構成されるソフトウェア・コード部を含むコンピュータ・プログラム製品に関するものである。

本発明について添付の図面を参照して更に説明する。図面は本発明の実施形態を概略的に示している。本発明は、これら特定の実施形態に如何なる方法でも制限されないことが理解されるであろう。

図１Ａは、クライアントで使用するための適用ストリーミング・クライアントおよびマニフェスト・ファイルを示す。 図１Ｂは、クライアントで使用するための適用ストリーミング・クライアントおよびマニフェスト・ファイルを示す。 図２は、従来型のＡＳクライアントについてのセグメント抽出およびプレイ・アウト処理のフロー図を示す。 図３は、本発明の一実施形態によるクライアントについて示す。 図４Ａは、本発明の一実施形態により、ＣＤＮベース・コンテンツ配信システム、およびＣＤＮベース・コンテンツ配信システムにおける位置を解決するための事前解決処理に関連するフロー図である。 図４Ｂは、本発明の一実施形態により、ＣＤＮベース・コンテンツ配信システム、およびＣＤＮベース・コンテンツ配信システムにおける位置を解決するための事前解決処理に関連するフロー図である。 図５は、本発明の一実施形態による事前解決セグメントの抽出について示す。 図６は、本発明の一実施形態により、クライアントによって実施されるセグメント事前解決および抽出処理に関連するフロー図である。 図７は、本発明の一実施形態により、クライアントのマニフェスト・キャッシュに格納されるマニフェスト・ファイルの少なくとも一部を事前解決する例について示す。 図８は、マニフェスト・ファイルの要求およびプレイ・アウトについて、マニフェスト・ファイルにおける未解決セグメントＵＲＬが事前解決される処理のフロー図について示す。 図９は、本発明の実施形態により、クライアントにおける事前解決機能により実行される処理についての詳細なフロー図である。 図１０は、本発明の一実施形態により、事前解決のための適切なセグメントの選択について示す。 図１１は、本発明の他の実施形態により、事前解決のための適切なセグメントの選択について示す。 図１２は、本発明の更なる他の実施形態により、事前解決のための適切なセグメントの選択について示す。 図１３は、本発明の一実施形態により事前解決のためにマークされるセグメントを含むマニフェスト・ファイルの少なくとも一部について示す。

図１Ａおよび図１Ｂは、それぞれ、従来型の適応ストリーミング（ＡＳ; adaptive streaming）クライアント、およびこのようなＡＳクライアントで使用するマニフェスト・ファイルについて示す。

クライアント１０２は、端末（図示せず）にホストすることができ、ネットワーク内の１つ以上のメディア・サーバと通信して、例えば、アップル社のＨＴＴＰＬｉｖｅ Ｓｔｒｅａｍｉｎｇ［http://tools.ietf.org/html/draft-pantos-http-live-streaming-07］、マイクロソフト社のＳｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ［http://www.iis.net/download/SmoothStreaming］、アドビ社のＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ［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 DASH ISO/IEC 23001-6]のような適応ストリーミング・プロトコルに基づいて、コンテンツのストリーミングを可能にするように構成される。

端末は、全般的に、コンテンツ処理デバイス、例えば、電子タブレット、スマートフォン、ノートブック、メディア・プレーヤ等のような（モバイル）コンテンツ・プレイ・アウト・デバイスに関する。実施形態の中には、端末は、コンテンツ・プレイ・アウト・デバイスによる将来の消費のためのコンテンツを処理し、一時的に格納するように構成されるセットトップ・ボックスまたはコンテンツ・ストレージ・デバイスとしてもよい。

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

図１Ｂは、コンテンツ・アイテムを構築するセグメント、および１つ以上のネットワーク・ノードへの参照を含む位置情報を識別するための識別子を含むマニフェスト・ファイルについての概略図である。１つ以上のネットワーク・ノードは、識別されるセグメントをクライアントに配信するように構成され、またはセグメントを抽出できるクライアントに情報を提供するように構成される。したがって、このような参照は、以降ではセグメント・ロケータと称するが、識別されるセグメントを配信するように構成されるネットワーク・ノードをポイントするか、または、その代替として、識別されるセグメントを配信可能である１つ以上のネットワーク・ノードを決定することができるネットワーク・ノードをポイントすることができる。更に他の実施形態では、セグメント・ロケータはまた、ネットワーク・ノードの位置をポイントすることもできる。例えば、異なるセグメント・ロケータは、１つの配信ノードにおいて定められる異なるフォルダをポイントすることができる。

図１Ｂは、マニフェスト・ファイルで識別されるセグメントをクライアントに配信するように構成される配信ノードの位置特定をするために、クライアントにより使用されるマニフェスト・ファイルの概略図である。そのために、マニフェスト・ファイルは、セグメントを識別するために、少なくとも１つのセグメント識別子、例えばセグメント・ファイル名、セグメント識別子に関連付けられる少なくとも１つのセグメント識別子の形態の位置情報を含むことができる。セグメント・ロケータは、１つ以上のネットワーク・ノード（またはネットワーク・ノード上の１つ以上のフォルダ）をポイントするように規定することができる。当該ネットワーク・ノードは、識別されたセグメントをホストし、セグメントをクライアントまで配信するように構成されるか、または識別されたセグメントをクライアントに配信可能な１つ以上の別のネットワーク・ノードを決定するように構成される。

実施形態の中には、セグメント識別子およびセグメント・ロケータは、ＵＲＬのような所定のデータ構造の一部とすることができるものもある。例えば、central.cdnA.com/segment1-1.aviというＵＲＬは、セグメント・ロケータ central.cdnA.com、即ちＣＤＮＡのネットワークへのポインタ（または参照）、およびセグメント識別子、即ちセグメント・ファイル名segment1-1.aviを含む。ここで、セグメント・ロケータcentral.cdnA.comに関連付けられるネットワーク・ノードは、セグメントをクライアントに配信するように構成することができ、または、セグメントsegment1-1.aviを配信可能な１つ以上のネットワーク・ノードをポイントする１つ以上の別のセグメント・ロケータを配信するように構成することができる。以下の例示では、ＵＲＬを用いて説明するが、本発明はそれに限定されない。他の実施形態では、セグメント識別子およびセグメント・ロケータは、ネットワークにおいてセグメントを識別および位置特定するために、如何なる適切なフィーマットとしてもよい。実施形態の中には、セグメント識別子およびセグメント・ロケータは、セグメント識別子またはセグメント・ロケータのどちらかが、ネットワーク内でセグメントを識別および位置特定するのに使用できるという意味において一致させることができる。

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

図１Ａに示したように、マニフェスト・ファイルは、マニフェスト・キャッシュ１０４に格納され、パースされて、セグメント・リスト、即ち論理データ構造に構造化されることができる。当該セグメント・リストは、セグメントを抽出するための情報、例えば、セグメント識別子（例えばセグメント・ファイル名）およびセグメント・ロケータ（例えばＵＲＬ（１または複数）のうち所定の部分）を抽出する情報、これらセグメントが抽出される位置を決定する情報、およびセグメントのプレイ・アウト、即ちセグメント間の関係（例えば、時間的関係、品質的関係、および／または空間的関係）を制御するためのプレイ・アウト制御情報を含む。

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

セグメント抽出機能は、セグメントを抽出して、プレイ・アウトが開始されないうちに、セグメント・バッファが所定の数のセグメントによって負荷を掛けられるように構成することができる。更に、プレイ・アウトの間、セグメント抽出機能は、マニフェスト・ファイルに基づいて継続的にセグメントを抽出する。その結果、充分なセグメントをセグメント・バッファに格納することができる。このように、セグメント抽出に関連したレイテンシは、セグメントのシームレスなプレイ・アウトを干渉することがない。セグメント抽出機能は、ユーザ・ナビゲーション機能１１２からのセグメント抽出命令を受け入れて処理することができる。ここで、ユーザ・ナビゲーション機能からのセグメント抽出命令は、時間的ナビゲーション（例えば早送り）、または空間的ナビゲーション（例えばパニング・ズーム・タイトル化）に関するものとすることができる。

図１Ａに示すような従来型のＡＳクライアントに関する１つの課題は、ユーザ・ナビゲーション機能がセグメント・バッファにおいて利用可能ではないセグメントのプレイ・アウトを要求する場合に、セグメント抽出機能が、要求されたセグメントをオンザフライで抽出するのを開始することになってしまうという事実に関する。この処理は、しかしながら、相当量の時間を要する。何故ならば、セグメントは、解決処理を用いて位置特定される必要があるからであり、ここでは、マニフェスト・ファイルの（未解決の）セグメント・ロケータが、セグメントをホストするネットワークに関連付けられるネットワーク・アドレスに解決される。この解決処理は、ＤＮＳルック・アップ、ＨＴＴＰリダイレクト、および／またはＣＤＮ間（ＣＤＮ―Ｉ）要求ルーティングを伴うことがある。この処理は、複雑なまたは相互接続されたＣＤＮの場合に、最大で数秒も掛かることがある。セグメントをダウンロードする処理はまた、著しく時間が掛かることもある。しかしながら、プレイ・アウト処理は、セグメント全体がダウンロードされないうちに既に開始することになるので、ユーザが知覚する経験の品質は、コンテンツを通じてナビゲートするときは、主にセグメント解決処理によって決定されることになる。

図２は、図１Ａに示した従来型のクライアントについてのセグメント抽出およびプレイ・アウト処理について、より詳細に示している。ｔ＝０において処理は開始し、クライアントはバッファ・セグメント、この場合は第１のセグメント「segment1-1.avi」のプレイ・アウトを開始することができる（ステップ２００）。バッファ・セグメントは、図１Ａおよび図１Ｂを参照して説明したマニフェスト・ファイルに基づくセグメント抽出機能により、ＣＤＮから既に抽出されている。第１セグメントのプレイ・アウトが一旦終了すると、後続のｔ＝１でのセグメント（segment1-2.avi）、およびｔ＝２でのセグメント（segment1-3.avi）が処理されて、プレイ・アウトされることになる。

次いで、ｔ＝２において、segment1-3.aviのセグメント・ファイル名を有するセグメントのプレイ・アウトの間、ユーザは、クライアントのユーザ・ナビゲーション機能を用いて、（例えば、ボタンを低ビットレートのプレイ・アウト・モードに入れよう選択することによって）コンテンツと相互作用することができる。相互作用の結果として、端末のセグメント・バッファにおいて利用可能ではない新規のセグメント、即ち低ビットレートのセグメントsegment2-4.aviが要求される（ステップ２０２）。

クライアントは、セグメントがバッファにおいて利用可能ではないと決定するときに、セグメント抽出機能をトリガして、マニフェスト・ファイルの低ビットレート・セグメントsegment2-4.aviの位置情報、例えばセグメント・ロケータを抽出し、ＣＤＮＡの要求ルーティング機能に関連付けられるセグメント・ロケータcentral.cdnA.comを含むＤＮＳ要求メッセージをＤＮＳシステムに送信することによって、セグメント・ロケータcentral.cdnA.comを解決する。ＤＮＳシステムは、解決済みのＩＰアドレスを含むＤＮＳ応答メッセージをクライアントに戻すことができる（ステップ２０４，２０６）。応答では、クライアントは、セグメントsegment2-4.aviついてのＨＴＴＰゲット要求をＣＤＮＡの要求ルーティング・ノードのＤＮＳ解決済みＩＰアドレス123.45.67.89に送信することができる（ステップ２０８）。要求に応答して、ＣＤＮＡ、上流(upstream)ＣＤＮは、ＣＤＮ Ｂ、下流(downstream)ＣＤＮと要求されたセグメントの配信について協議することができる（ステップ２１０，２１２）。

ここで、ＣＤＮ ＡとＣＤＮＢの間の通信は、ｄｒａｆｔ−ｉｅｔｆ−ｃｄｎｉ−ｐｒｏｂｌｅｍ−ｓｔａｔｅｍｅｎｔ−０１に説明されるように、ＣＤＮＩ要求ルーティング（ＲＲ）インタフェースに基づいてもよい。このインタフェースは、相互接続されるＣＤＮ内の要求ルーティング・ノードが通信するのを可能にし、ユーザ要求が上流ＣＤＮ（この場合ＣＤＮＢ）から下流ＣＤＮの代理物(surrogate)まで（リ）ダイレクトされるのを確実にすることができる。ＣＤＮＩ ＲＲインタフェースは、下流ＣＤＮが、情報（例えば、リソース、フットプリント、負荷）を上流ＣＤＮに提供するのを可能にし、コンテンツ要求を処理するときに、上流ＣＤＮの要求ルーティング・システムによる下流ＣＤＮの選択を容易にする。

ＣＤＮ間による協議の後に、ＣＤＮ Ａの要求ルーティング・ノードは、この特定のユーザについてのセグメントの配信がＣＤＮ Ｂによって最良に届けられることを判断することができる。ＣＤＮ Ａの要求ルーティング機能は、それ故、ＣＤＮＢの要求ルーティング・ノードの位置情報（central.cdnB.com/segment2-4.avi）を収容するＨＴＴＰリダイレクト応答をクライアントに送信し戻すことができる（ステップ２１４）。ＨＴＴＰリダイレクトを受信すると、クライアントは、別のＤＮＳクエリを実行し、新規のＨＴＴＰゲットを解決済みのＩＰアドレス98.65.45.201に送信する（ステップ２１６−２２０）。

その後に、ＣＤＮ Ｂの要求ノード、特にＣＤＮＢのＣＤＮ制御機能（ＣＤＮＣＦ）は、特定のセグメントをクライアントに配信するのに最適な配信ノード（ＤＮ）を決定し（ステップ２２２，２２４）、セグメント・ロケータ（この場合は、node3.cdnB.com）を収容するＨＴＴＰリダイレクトをクライアントに送信し戻す。クライアントは、その後、別のＤＮＳクエリを実行して、配信ノードのＩＰアドレス24.67.13.57を抽出することができる。次いで、クライアントは、ＵＲＬ24.67.13.57/segment2-4.aviを含むＨＴＴＰ ＧＥＴを、配信ノードのこのような解決済みのＩＰアドレスに送る（ステップ２２８−２３２）。これに応答して、配信ノードは、要求されたセグメント（segment2-4.avi）をクライアントに送信する（ステップ２３４）。次いで、ｔ＝９において、クライアント、segment2-4.aviを受信し、プレイ・アウトを開始することができる。

したがって、図２からも分かるように、ユーザ相互作用なしで、リダイレクトおよび要求ルーティングの遅延は、ユーザ知覚への影響をほとんど有さない。何故ならば、クライアントは、通例、プレイ・アウトを開始しないうちに幾らかのセグメントをバッファするからである。しかしながら、クライアントとのユーザ相互作用が許容される場合、そのクライアントは、どのセグメントをユーザが選択することになるかについての知識を何ら有しない。図２に示すように、時間的（早送り）、空間的（パニング／ズーミング）、またはマルチ・レート方式での別のレートへのスイッチは、アドホックの抽出を必要とし、相当量の遅延が生じることになる。例えば、図２では、ｔ＝２におけるユーザ相互作用と、ｔ＝９におけるそのユーザ・アクションに関連するセグメントの受信との間で全てのプロトコル変換（ＤＮＳ、ＨＴＴＰリダイレクト、およびＣＤＮ間シグナリング）を実行するために、最大で数秒ものレイテンシがあり得る。このようなレイテンシは、セグメントのシームセスなプレイ・アウトを中断することになり、これによりユーザ経験を損なう。

図３は、本発明の一実施形態によるクライアントを示す。特に、図３は、事前解決機能３１４を含むＡＳクライアントを示す。事前解決機能３１４は、プレイ・アウトのためにクライアントによって近い将来に選択されることが予想されるセグメントのセグメント・ロケータ、例えば少なくともＵＲＬの一部を事前解決するように構成される。

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

プレイ・アウトのセグメントに基づいて、また、ユーザ・ナビゲーション機能により提供されるナビゲーション情報に基づいて、セグメント・セレクタは、どのセグメント（１または複数）が、近い将来にクライアントによって選択されることに概ねなるかについて予測することができる。ユーザ・ナビゲーション情報は、つまり、コンテキスト情報、即ち、ユーザに特化した情報（例えばユーザ・プロファイル、ユーザ・ナビゲーション履歴、ユーザの（地理的）位置など）を供給する。コンテキスト情報は、将来のセグメント・プレイ・アウトを予測するセグメント・セレクタによって使用される。

事前解決機能はまた、プレイされるセグメント・コンテンツに関連付けられる包括的なナビゲーション情報、例えば、特定のコンテンツ・アイテムに関連付けられる頻繁に要求されるセグメントに関する情報を使用することもできる。この包括的なナビゲーション情報は、将来のセグメントのプレイ・アウトを予測するために、ユーザ・ナビゲーション情報と共に用いることができる。一実施形態では、コンテンツ・プロバイダまたはＣＤＮの制御機能は、マニフェスト・ファイル内の包括的なコンテンツ・ナビゲーション情報（例えばポピュラーなものとしてマークされたセグメント）を、それがクライアントに配信されたときに、挿入することができる。当該実施形態について、図１３を参照して更に詳細に説明する。他の実施形態では、事前解決機能は、コンテンツ・プロバイダ、ＣＤＮまたはサード・パーティから別の通信チャネルを通じて包括的なナビゲーション情報を受信することができる。

予測したセグメント（１または複数）がセグメント・キャッシュにない場合は、事前解決機能は事前解決処理を開始することができ、予測したセグメントのセグメント・ロケータが、予測したセグメントを実際に抽出することなく、完全にまたは少なくとも部分的に事前解決される。ここで、事前解決という用語とは、予測したセグメントのセグメント位置に関連付けられるネットワーク情報を取得する処理に関するものである。ネットワーク情報は、ＩＰアドレス、別のセグメント・ロケータ（一部）、および／またはセグメント・ロケータがネットワーク・ノードをポイントするかについての情報を含むことができる。ネットワーク・ノードは、セグメントをクライアント（即ち配信ノード）に配信する、またはネットワーク情報についての要求をリダイレクトするように構成される。予測したセグメントの事前解決セグメント・ロケータについての当該処理は、セグメントのプレイ・アウトと共に並行して（またはバックグラウンド処理として）実施することができ、また、ＤＮＳルック・アップ、リダイレクト、および／または実際にセグメント抽出することのないＣＤＮ間要求ルーティングのような技術を用いることができる。

セグメント・ロケータと関連付けられるネットワーク情報は、クライアントのマニフェスト・ファイルを修正するのに用いることができる。例えば、一実施形態では、予測したセグメントのセグメント・ロケータを事前解決する処理の結果、完全に事前解決したセグメント・ロケータ、即ちクライアントにセグメントを配信するように構成された配信ノードのネットワーク・アドレスをポイントするセグメント・ロケータとなる場合は、事前解決機能は、事前解決済みのネットワーク・アドレスを受信し、当該ネットワーク・アドレスを用いて、マニフェスト・キャッシュ３０４内に格納されたセグメント・リストのエントリを修正およびリライトすることができる。代替として、事前解決機能は、解決済みのネットワーク・アドレスをセグメント・リストに追加することができる。更に、予測したセグメントのセグメント・ロケータについての事前解決処理の結果、部分的に事前解決セグメント・ロケータ、即ち第２のセグメント・ロケータ（これは、完全に事前解決したセグメント・ロケータへとそれを解決させるために、１つ以上の別の事前解決ステップを必要とする）となる場合は、事前解決機能は、当該部分的に事前解決済みのセグメント・ロケータを使用して、マニフェスト・キャッシュ３０４内に格納されたセグメント・リストのエントリを更新、例えば修正およびリライトすることができる。

このようにして、完全にまたは部分的に事前解決済みのセグメントがユーザ・ナビゲーション機能を通じてユーザによって選択されたときに、クライアントは、図２を参照して説明する解決ステップの全部または少なくとも一部をスキップすることができる。これにより、予測したセグメントについての抽出時間を相当量削減することができる。特に、セグメント・ロケータが完全に事前解決される場合は、クライアントは、マニフェスト・ファイルに格納された事前解決済みのネットワーク・アドレスに基づいて、最小の要求ルーティング遅延でセグメントを抽出することができる。当該アドレスは、事前解決機能によってより早く決定されている。

図４Ａは、本発明の一実施形態によるコンテンツ・ストリーミング・システムを示す。特に、図４Ａは、ＣＤＮ相互接続インタフェース４６４を介して少なくとも第２のＣＤＮ４０４（下流ＣＤＮとも称される）に相互接続する第１のＣＤＮ４０２（上流ＣＤＮとも称される）を備えるＣＤＮベース・コンテンツ配信システムを示す。

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

ＣＤＮは、配信ノード４１０，４１３，４１４、および少なくとも１つの中央のＤＮノード４１６，４１８を備えることができる。各配信ノードは、コントローラ４２０，４２２，４２４、並びにコンテンツを格納およびバッファするためのキャッシュ４４０，４４２，４４４を備え、または関連付けることができる。各中央ＣＤＮノードは、外部ソース、例えばコンテンツ・プロバイダまたは別のＣＤＮからのコンテンツの摂取(ingestion)を制御するための摂取ノード(ingestion node)（またはコンテンツ起始機能、ＣＯＦ; content origin function）４２５，４２７、コンテンツがＣＤＮ内に格納される場所についての情報を保持するためのコンテンツ位置データベース４３４，４３６、および、コンテンツの１つ以上のコピーを配信ノードに配給するのを制御し且つ適切な配信ノードに対してクライアントをリダイレクトする（要求ルーティングとしてまた知られる処理）ためのＣＤＮ制御機能４２６，４２８を備え、または関連付けることができる。一実施形態では、ＣＤＮＣＦをホストするノードは、要求ルーティングＲＲと称することもある。顧客は、要求をウェブポータル（ＷＰ）４３２に送信することにより、コンテンツ、例えばビデオ・タイトルをＣＰＳ４３０から購入することができる。ＷＰ４３２は、購入可能なコンテンツ・アイテムを識別するタイトルの参照を提供するように構成される。ＣＤＮＣＦは、セグメントがコンテンツ位置データベース４３４，４３６を用いて抽出される位置を管理することができる。

図４Ａのコンテンツ配信システムでは、上流ＣＤＮは、クライアントへのセグメントの配信の一部を下流ＣＤＮにアウトソースすることができる。例えば、一実施形態では、低品質セグメントは、（例えば、モバイル・デバイスにコンテンツを配信するように構成される）第１のＣＤＮＡによって位置決定および配信することができ、また、高品質セグメントは、（例えば、ＨＤＴＶ技術をサポートするホーム・メディア・デバイスに高品質セグメントを配信するように構成される）第２のＣＤＮＢによって位置決定および配信することができる。

図４Ｂは、本発明の一実施形態による事前解決処理に関連するフロー図を示す。図４Ｂは、特に、ＨＴＴＰＨＥＡＤメッセージが使用されるＨＴＴＰベース事前解決処理についてのフロー図を示す。

ｔ＝２において、クライアントによるセグメントのバッファリングおよびプレイ・アウトの間、ユーザは、クライアントのユーザ・ナビゲーション機能を用いて（例えば、ボタンを押下してパニング動作を実行させることによって）コンテンツと相互作用することができる。相互作用の間、セグメント・セレクタは、マニフェスト・ファイル内の特定のセグメント、segment2-4.aviが、近い将来プレイ・アウトによって要求することができるということ、およびこのような要求に関連付けられるセグメントが現在のところ端末のセグメント・バッファでは利用可能でない見込みが高いということを判断（予測）することができる。このようなセグメント要求は、予測した将来のセグメント要求と称することもある。

この予測したセグメントがセグメント・バッファでは利用可能でないと判断されるときは、クライアントは、セグメント・ロケータに関連付けられたネットワーク情報をネットワークから要求することによって、予測したセグメントの（未解決の）セグメント・ロケータを、部分的にまたは完全に事前解決するよう決定することができる（ステップ４５２）。

このネットワーク情報に基づいて、事前解決機能は、例えばセグメント・ロケータ（この場合は、要求ルーティング・ノードcentral.cdnA.comをポイントするＵＲＬの一部）を修正して別のセグメント・ロケータとすることができる。このような別のセグメント・ロケータは、部分的に事前解決したセグメント・ロケータ、または完全に事前解決したセグメント・ロケータに関するものであり、セグメント・ロケータは、このセグメントをクライアントに配信するように構成される少なくとも１つの配信ノードに関連付けられるネットワーク・アドレス、例えばＩＰアドレスを含む。事前解決セグメント・ロケータについてのこの処理について、以下により詳細に説明する。

事前解決処理は、ネットワーク・ノード、例えば、ＣＤＮ Ａの要求ルーティング機能を含むネットワーク・ノードに関連付けられるＵＲＬの一部(central.cdnA.com)を含むＤＮＳ要求メッセージをネットワーク内の解決機能、例えばＤＮＳシステムに送信することによって開始することができる。そして、ネットワーク・ノード、この場合はＣＤＮＡに関連付けられる要求ルーティング機能を含むネットワーク・ノードのＩＰアドレスを含む応答メッセージを受信することができる（ステップ４５４，４５６）。更に、クライアントは、このネットワーク・ノードが、予測したセグメントを配信することができるかどうかについて検査することができる。そのために、クライアントは、segment2-4.aviについてのＨＴＴＰ ＨＥＡＤ要求をＤＮＳ解決ＩＰアドレス123.45.67.89に送信することができる（ステップ４５８）。このネットワーク・ノードが、要求されたセグメントを配信することができる場合は、ＨＴＴＰ２００ ＯＫメッセージにより当該要求に応答することができる。要求したセグメントを送信することができない場合は、別のセグメント・ロケータを含むＨＴＴＰＲＥＤＩＲＥＴメッセージにより応答することができる。別のセグメント・ロケータは更に事前解決される必要があり、その結果、要求されたセグメントをクライアントに配信するように構成されるネットワーク・ノードのネットワーク・アドレスを取得することができる。既に先に説明したように、このような別のセグメント・ロケータについて、以降では部分的に事前解決したセグメント・ロケータと称することもある。

したがって、ＨＴＴＰ ＨＥＡＤ要求メッセージを受信するときは、ＣＤＮ Ａの要求ルーティング機能は、ＣＤＮＩ要求ルーティング（ＲＲ）インタフェースを介して、要求されたセグメントの配信についてＣＤＮＢと協議することができる（ステップ４６０，４６２）。

一実施形態では、クライアントをＣＤＮ Ｂにリダイレクトしないうちに、ＣＤＮ ＡのＲＲノードは、ＣＤＮＢが特定のセグメントをクライアントに配信することができ、且つその意思があることの確認を要求することができる。その場合、ＣＤＮＡは、ＣＤＮ間メッセージ、例えばＤＥＬＩＶＥＲＹ ＲＥＱＵＥＳＴメッセージをＣＤＮ ＢのＲＲノードに送信することができる。ここでは、要求は、要求したセグメントおよび位置情報、例えばクライアントのＩＰアドレスを識別するパラメータを含むことができる。このＤＥＬＩＶＥＲＹＲＥＱＵＥＳＴは、ＨＴＴＰ ＧＥＴメッセージにより実施することができる。

他の実施形態では、ＣＤＮ間メッセージ、例えばＨＴＴＰ ＧＥＴ ＤＥＬＩＶＥＲＹ ＲＥＱＵＥＳＴメッセージは、ＣＤＮＡのＲＲノードによりＣＤＮ ＢのＲＲノードに送信され、特定のＣＤＮ間メッセージが、クライアントによる実際のコンテンツ要求（例えばＨＴＴＰＧＥＴメッセージ）に関連しないものの、クライアントにより（例えばＨＴＴＰ ＨＥＡＤメッセージに基づいて）実行される事前解決ステップに関連することを示すフラグを含むことができる。当該フラグは、ＣＤＮ ＢのＲＲノードに要求の性質(nature)を通知するように使用され、ＣＤＮ ＢのＲＲノードは（チャージ、統計等の目的で）適切な後続のアクションの選択が可能になる。

他の実施形態では、ＣＤＮ間メッセージ、例えばＤＥＬＩＶＥＲＹ ＲＥＱＵＥＳＴがコンテンツ要求の代わりに事前解決ステップに関連する場合は、ＣＤＮ間メッセージは、ＨＴＴＰ ＧＥＴメッセージの代わりにＨＴＴＰ ＨＥＡＤメッセージにより実装することができ、その結果、ＣＤＮＢのＲＲノードは、要求の性質により、（チャージ、統計等の目的で）適切な後続のアクションが選択になる。この実施形態では、ＨＴＴＰＨＥＡＤメッセージに応答して、ＨＴＴＰ ＯＫ応答メッセージは、要求されたセグメントおよび位置情報、例えば、クライアントのＩＰアドレスをそのヘッダーに含めることができる（ＨＴＴＰＨＥＡＤへの応答メッセージはボディ部を有しないためである）。

ＣＤＮ Ｂとの協議の後、ＣＤＮＡの要求ルーティング・ノードは、この特定のユーザへのこの特定のセグメントの配信がＣＤＮＢにより最適にサービス提供されることを決定することができる。それ故、部分的に解決したセグメント・ロケータ、例えば、ＣＤＮＢの要求ルーティング・ノードをポイントするＵＲＬの一部（central.cdnB.com）を含むＨＴＴＰ ３０２ ＲＥＤＩＲＥＣＴ応答を、クライアントに送り戻す（ステップ４６４）。ＨＴＴＰＨＥＡＤメッセージに応答して送信されるメッセージは、ボディ部を有しないので、ＨＴＴＰ３０２ ＲＥＤＩＲＥＣＴメッセージもまたボディ部を有しない。しかしながら、このことは課題にはならない。何故ならば、リダイレクト情報は、部分的に解決したセグメント・ロケータを含むが、そのヘッダーには収容されず、その結果、メッセージのボディ部は必要されることはないからである。

部分的に解決したセグメント・ロケータを含むＨＴＴＰ ＲＥＤＩＲＥＣＴメッセージを受信すると、クライアントは、要求内のセグメント・ロケータが完全に事前解決されてネットワーク・アドレスにはなっていないと判断する。事前解決機能は、次いで、事前解決処理を停止するよう決定し、元のセグメント・ロケータcentral.cdnA.comを、部分的に解決したセグメント・ロケータcentral.cdnB.comに置き換えることにより、マニフェスト・キャッシュ内のマニフェスト・ファイルの一部をリライトすることができる（図４Ｂには図示せず）。

代替として、ＨＴＴＰ ＲＥＤＩＲＥＣＴを受信すると、ＡＳクライアントは、別のＤＮＳクエリを実行することによって事前解決処理を継続し（ステップ４６６，４６８）、そして、新規のＨＴＴＰＨＥＡＤを、ＣＤＮ Ｂの要求ルーティング・ノードの解決済みのＩＰアドレス98.65.45.210を送信する（ステップ４７０）ように決定することができる。

その後に、ＣＤＮ Ｂの要求ノード、特にＣＤＮＢのＣＤＮ制御機能（ＣＤＮＣＦ）は、配信ノード（ＤＮ）を決定することができる。ＤＮは、特定のセグメントをクライアントに配信し（ステップ４７２，４７４）、そして、選択した配信ノードの位置、この場合はセグメント・ロケータnode3.cdnB.comを収容するＨＴＴＰリダイレクトをクライアントに送信し戻す（ステップ４７６）のに最適なものとなる。ＨＴＴＰＲＥＤＩＲＥＣＴメッセージを受信すると、クライアントは、事前解決処理を停止して、元のセグメント・ロケータcentral.cdnA.comを、部分的に事前解決済みのセグメント・ロケータnode3.cdnB.comで置き換える（その結果、修正したＵＲＬであるnode3.cdnB.com/segment2-4.aviとする）ことによりマニフェスト・キャッシュ内のマニフェスト・ファイルの一部をリライトするか、または、事前解決処理を継続するかについて、再度決定することができる。

クライアントは、別のＤＮＳクエリを実行することにより事前解決処理を継続することができ（ステップ４７８，４８０）、その結果、ＵＲＬを解決して、セグメントをクライアントに配信するように構成される配信ノードのネットワーク・アドレス（この場合、24.67.13.57）とすることができる。また、この時に、事前解決機能は、事前解決処理を停止し、結果、即ちセグメント・ロケータ24.67.13.57をマニフェスト・キャッシュに格納するように決定することができる（図示せず）。

事前解決機能による事前解決処理が継続される場合は、当該事前解決機能は、事前解決済みのセグメント・ロケータに関連付けられたネットワーク・ノードが予測したセグメントを配信可能かについて、再度検査することができる。そのために、ＡＳクライアントは、ＨＴＴＰＨＥＡＤを配信ノードのネットワーク・アドレスに送信することができる（ステップ４８２）。ここでは、応答により、事前解決処理が早期のセグメント・ロケータ（即ち、開始時に、または事前解決処理の中間段階において使用されるもの）を完全に解決したことを事前解決機能に確認するＨＴＴＰ２００ ＯＫメッセージを送信する。このようにして、セグメントがＵＲＬ24.67.13.57/segment2-4.aviに基づいて抽出できるかについて決定することができる（ステップ４８４）。

次いで、ｔ＝９において、事前解決処理は、元のセグメント・ロケータcentral.cdnA.comを完全に事前解決済みのセグメント・ロケータ24.67.13.57で置き換えることによって（その結果、完全に解決済みのＵＲＬ24.67.13.57/segment2-4.aviとなる）、マニフェスト・キャッシュ内のマニフェスト・ファイルの一部をリライトすることができる（ステップ４８６）。フラグ即ちセグメント・ロケータに関連付けられるインジケータは、セグメント・ロケータが、完全に事前解決済みかまたは部分的に事前解決済みかについて示すことができる。先に説明した処理は、他のセグメントについて繰り返すことができ、ユーザ・ナビゲーション情報により、どの後続のセグメントが部分的にまたは完全に解決したかについて決定する。

したがって、上記から導き出すことができるように、部分的にまたは完全に事前解決する事前解決機能では、セグメント・ロケータに関連付けられるネットワーク情報に基づいてＡＳクライアントのマニフェスト・キャッシュ内にあるマニフェスト・ファイルにおいて、セグメント・ロケータを予め規定している。このようなネットワーク情報を取得するために、事前解決機能は、ＲＦＣ２６１６に規定されるＤＮＳ要求またはＨＴＴＰＨＥＡＤ要求のような、予め規定されたプロトコル・メッセージを使用することができる。ＨＥＡＤ要求は、ネットワーク・ノードが応答のメッセージ・ヘッダを戻すのみであるという点を除き、ＨＴＴＴＧＥＴ要求と同一である。ＨＥＡＤ要求をマニフェスト・ファイル内に見いだされるＵＲＬに送信することによって、ＡＳクライアントは、ＵＲＬが実際のセグメントをホストするか否かを、応答メッセージに基づいて検査することができる。ＨＴＴＰＨＥＡＤ要求がＨＴＴＰ ＯＫ応答を戻す場合は、ＡＳクライアントは、ＵＲＬが最終宛先であり、更なる要求ルーティング遅延を予想する必要がないことを分かる。サーバの応答がＨＴＴＰＲＥＤＩＲＥＣＴメッセージである場合は、ＡＳクライアントは、その時点で事前解決処理を停止し、未解決のセグメントＵＲＬを部分的に解決済みのセグメントＵＲＬで置き換えることができる。代替として、クライアントは、別のＨＴＴＰＨＥＡＤ要求をリダイレクト・メッセージ内にリストされたＵＲＬに送信することによって、事前解決処理を継続するように決定することができる。この処理は、最終的に完全に事前解決済みのＵＲＬが受信されるまで繰り返すことができる。次いで、マニフェスト・キャッシュに格納したＵＲＬは、事前解決処理により取得したＵＲＬで置き換えることができる。

図４Ｂに示した処理ではＨＴＴＰプロトコルに関して説明したが、これに限定されない。例えば、マニフェスト・ファイルが１つ以上のＲＴＳＰセグメント・ロケータ、例えばＲＴＳＰＵＲＬを含む場合は、クライアントは、ＲＴＳＰ ＤＥＳＣＲＩＢＥ要求を用いてセグメント・ロケータについて事前解決を実行することができる。更に、ＲＴＳＰでは、応答時に３ｘｘ応答を用いることによって、リダイレクトをＨＴＴＰと同様のやり方で処理することができる。したがって、クライアントがＲＴＳＰＤＥＳＣＲＩＢＥに応答して３ｘｘ応答を受信したときに、クライアントは、別のＲＴＳＰＤＥＳＣＲＩＢＥ要求を３ｘｘ応答のＵＲＬに送信する必要があることが分かる。

図５は、本発明の一実施形態により、事前解決済みのセグメント・ロケータに基づいたセグメントの抽出に示す。この特定の例では、処理は、図２を参照して説明した処理、即ち、バッファされたセグメントのプレイ・アウトと同一のやり方で開始することができる。ここでは、セグメント・バッファは、セグメント抽出機能により別のセグメントで継続的に満たされる。セグメント抽出機能は、セグメント・プレイ・アウト処理と並行に実施することができる。一方、図４に示した事前解決処理は、バックグラウンド処理としてクライアントにおいて実施することができる。その結果、セグメント・ロケータcentral.cdnA.comを含む、マニフェスト・ファイルのセグメント・ロケータは、図３を参照して説明したユーザ・ナビゲーション情報に基づき事前解決される。

したがって、図５に示すように、ｔ＝０において、クライアントは、セグメント（この場合、segment1-1.avi）のプレイ・アウトを開始することができる。簡単のため、セグメント抽出機能については図示しない（ステップ５００）。最初のセグメントのプレイ・アウトが一旦終了すると、ｔ＝１（segment1-2.avi）およびｔ＝２（segment1-3.avi）において後続のセグメントを処理およびプレイ・アウトすることができる。次いで、ｔ＝２では、クライアントがsegment1-3.aviをプレイ・アウトするときに、ユーザは、（例えば、ボタンを押下して、パニング動作を実行することによって）コンテンツと相互作用することができる。当該相互作用の結果は、新規のセグメントsegment2-4.aviが要求されるというものである。

このセグメントに関連付けられるセグメント・ロケータは、バックグランド処理で起動する事前解決機能によって既に完全に事前解決しているので、クライアントは、ＨＴＴＰＧＥＴを配信ノードのアドレスに送信する。ここでは、ＨＴＴＰ ＧＥＴメッセージはセグメント識別子segment2-4.aviを含む（ステップ５３２）。ＣＤＮ Ｂの配信ノードは、ＨＴＴＰ２００ ＯＫ応答メッセージの要求セグメントsegment2-4.aviをクライアントに送信することによって応答することができる（ステップ５３４）。次いで、ｔ＝４において、クライアントは、segment2-4.aviの受信およびプレイを開始する（ステップ５３６）。

図５からも理解できるように、クライアントの事前解決機能は、クライアントとのユーザ相互作用を受けて、セグメント抽出処理により導出される遅延を著しく削減させる。セグメントが部分的に事前解決のみされている場合は、事前解決処理の未終了の部分については、セグメントが抽出できる前に、終了される必要がある。それにもかかわらず、その場合はまた（特に、大多数のセグメントが事前解決される必要がある場合は）、要求ルーティング遅延の削減において相当量の改良を達成することができる。このようにして、ユーザによる経験の知覚品質は、コンテンツを通じてナビゲートするときに、相当量を改良することができる。更に、事前解決機能は、クライアント・ソフトウェアの更新を要求のみする既存のネットワーク技術と共に使用することができる。

図６は、本発明の実施形態により、クライアントによって実施される事前解決処理およびセグメント抽出処理に関するフロー図である。ウェブサイトをブラウズしている間の或る時に、ユーザはウェブ・ビデオへのリンクを選択する。選択を受けて、ユーザのクライアントは、ＨＴＴＰＧＥＴ要求をリンク内に収容されたＵＲＬに送信する。この場合は、リンクは、ＣＤＮ Ａの要求ルーティング・ノード上のmanifest.mfと名付けられるマニフェスト・ファイルをポイントする（ステップ６００）。マニフェスト・ファイルについてのクライアントによる要求を受け取ると、要求ルーティング・ノードは、クライアントにマニフェスト・ファイルを配信するのにどの配信ノードが最も適しているかについて決定することができる。次いで、ＨＴＴＰＲＥＤＩＲＥＣＴメッセージを、選択された配信ノードのＵＲＬを収容するクライアントに送信することができる（ステップ６０１）。クライアントが、一旦、ＨＴＴＰＲＥＤＩＲＥＣＴメッセージを受信すると、クライアントは、ＲＥＤＩＲＥＣＴメッセージに収容されるＵＲＬ（この場合は、node1.cdnA.com/manifest.mf）に新規のＨＴＴＰ ＧＥＴを送信することができる（ステップ６０２）。ＣＤＮ Ａの配信ノードは、要求されたマニフェスト・ファイルをクライアントに送信することによって応答することができる（ステップ６０３）。

マニフェスト・ファイルを受信すると、クライアントは、当該マニフェスト・ファイルをパースして、記述されたコンテンツの構造についての概念(idea)をゲットすることができる（ステップ６０４）。マニフェスト・ファイルをパースした後、クライアント処理を（少なくとも）２つの別個の処理（スレッド）に分割する。第１の処理は、図５を参照して説明したセグメントの要求およびプレイ・アウト（第１処理６０７）についてのものであり、第２の（バックグラウンド）処理は、図３から図４を参照して説明した、セグメント・セレクタにより選択されたセグメントに関連付けられるセグメント・ロケータの事前解決（第２処理６０６）についてのものである。

これらのメッセージのフローは、一旦セグメント・ロケータが事前解決されると、更なるリダイレクトは何れも必要とされないことを明確に示している。何故ならば、クライアントは、マニフェスト・キャッシュ内の事前解決済みのネットワーク・アドレスに基づいて、セグメントをホストするサーバと即座にコンタクトできるからである。また、異なるセグメントが異なるノード上で位置される場合であっても、また、異なるＣＤＮにおける場合であっても、セグメントの効率的な抽出を実現できることを示している。

図７は、本発明の一実施形態により、マニフェスト・ファイルの少なくとも一部のセグメント・ロケータを事前解決する例を示す。特に、図７は、如何にしてクライアントが事前解決処理を用いて、セグメント・ロケータ、例えば、端末のマニフェスト・キャッシュに格納されたＵＲＬの所定の一部を置き換えることができるかについての例を示す。ここでは、事前解決されることになるセグメント・ロケータは、（図３を参照して説明した）ユーザ・ナビゲーション情報およびコンテンツ・ナビゲーション情報に基づいて、セグメント・セレクタによって選択される。

第１のマニフェスト・ファイル７００は、図６を参照して説明したように、ＣＤＮからクライアントが受信することができる。この場合、マニフェスト・ファイルは、所謂多数の空間的セグメント・ファイルに関連し、空間的にセグメント化されたコンテンツをクライアントにストリーミングするのに使用することができる。

空間的にセグメント化されたコンテンツ、即ちタイル化されたコンテンツは、所謂タイル化されたビデオ・システムにおいて使用され、ビデオ・コンテンツ・ファイルについての複数の解像度のレイヤを生成することができる。タイル化されたビデオ・システムの例は、Mavlankarらによる、「An interactive region-of-interest video streaming system for online lecturing viewing」ICIP2010会報，4437-4440ページに記載されている。

空間的にセグメント化されたコンテンツは、ビデオ・ファイルのビデオ・フレームを所謂タイルに空間的に分割することによって生成することができ、各タイルは、そこから該タイルが生成される元のビデオ・フレームの空間領域に関連付けられるコンテンツを含む。ビデオ・フレームのシーケンスに基づいて、１つの空間領域に関連付けられるタイルのシーケンスは、別個のストリーム、例えばＭＰＥＧストリームとして生成およびフォーマットすることができる。このようなストリームは、空間的なセグメント・ストリーム、即ち、空間セグメントと称することができる。

したがって、空間的ストリームは、各々独立してコード化され、配給（即ちストリーム）される。端末のビデオ・クライアントは、特定の空間領域、即ち関心領域（ＲＯＩ; Region of Interest）を要求することができ、サーバは、引き続いてＲＯＩ要求を１つ以上の空間セグメントにマップして、空間セグメントについて選択したグループをクライアントに送信する。端末は、空間セグメントのストリームを１つのシームレスなビデオに結合するように構成される。セグメント化したコンテンツについては、図１０から図１２を参照してより詳細に説明する。

図７のマニフェスト・ファイルは、空間的にセグメント化されたコンテンツがコンテンツ・ソース・ファイルMovie_4に基づいて生成されたこと、また、セグメント識別子（ファイル名）によって規定される４つの別個の空間セグメントのストリーム、Movie-4-1.seg，Movie-4-2.seg，Movie-4-3.seg，Movie-4-4.segがＣＤＮ Ａのドメイン内に格納されていることを示す。ここでは、ＵＲＬの所定の一部central.cdn_A.com（７０１ａ−７０１ｄ）は、ＣＤＮ Ａ内の包括的なＲｅｑｕｅｓｔＲｏｕｔｉｎｇノードをポイントする。したがって、これらのセグメント・ロケータは、セグメントを抽出できるノードのネットワーク・アドレスを備えていないという意味では未解決である。このマニフェスト・ファイルがストリーミング処理においてクライアントによって使用されるときは、図４を参照して詳細に説明したように、事前解決処理を用いることができる。

その処理の間、４つのセグメントに関連付けられるＵＲＬ７０１ａ−７０１ｄにおける未解決のセグメント・ロケータの少なくとも一部central.cdn_A.comは、ネットワーク・アドレスで置き換えることができる。このようにして、４つの未解決のＵＲＬ７０３ａ−７０３ｄは、これらセグメントが抽出することができる配信ノードのネットワーク・アドレスをそれぞれ含むように形成することができる。解決済みのＵＲＬは、例えば１つ以上の配信ノードをポイントすることができ、その内の幾らかは、例えば別のＣＤＮＢに位置することができる。図７に見ることができるように、セグメントは、ネットワーク・アドレス24.67.13.57により識別される１つの配信ノードから全て抽出することができる。

図８は、マニフェスト・ファイルの要求およびプレイ・アウトのための処理についてのフロー図を示し、未解決のセグメント・ロケータが少なくとも部分的に事前解決される。この処理は、クライアントが所望のコンテンツに関連付けられるマニフェスト・ファイルを要求することにより開始する（ステップ８００）。当該要求に応じて、クライアントは、サーバからマニフェスト・ファイルを受信し（ステップ８０１）、マニフェスト・ファイル内にリストされる最初のセグメントを要求することによってビデオのプレイ・アウトを開始する（ステップ８０２）。

プレイ・アウトの間、ユーザ相互作用は、セグメント・セレクタによって分析されて、どのセグメントおよび関連のセグメント・ロケータをユーザが好ましくは近い将来において要求するかについて予測する（ステップ８０３）。これら予測したセグメント・ロケータは、次いで、（部分的な）事前予測のために、セグメント・セレクタによってマークされる。事前解決機能は、次いで、事前解決のためにマークされたセグメント・ロケータを部分的にまたは完全に事前解決することができる（ステップ８０４）。最後のセグメント・ロケータが処理されると（ステップ８０５）、本処理は停止する。そうでない場合は、事前解決についての新規のラウンドを開始する。

図９は、本発明の実施形態による、事前解決処理についての詳細なフロー図を示す。特に、図９は事前解決処理のフロー図を示し、マニフェスト・ファイル内のセグメント・ロケータは、これらセグメント・ロケータに関連付けられるネットワーク情報に基づいて事前解決される。

最初のステップ９００では、事前解決機能は、部分的にまたは完全に事前解決される必要があるセグメント・ロケータ、例えばＵＲＬについてのリストを受信することができる。セグメント・ロケータに関連付けられる各セグメントは、特定のセグメント識別子、例えばセグメント・ファイル名により識別される。このリストは、図８を参照して説明した処理のステップ８０３の間、生成することができる。

事前解決機能は、最初のセグメント・ロケータ、例えばネットワーク・ノードをポイントするＵＲＬの所定の一部を、解決するのに必要とされるセグメント・ロケータのリストからフェッチすることができ（ステップ９０１）、そして、セグメント・ロケータに関連するネットワーク情報の取得を開始する（ステップ９０２）。ネットワーク情報は、図４Ｂを参照して説明したように、ネットワーク情報についての１つ以上の要求メッセージを用いて取得することができる。これらのメッセージは、１つ以上のＤＮＳメッセージ（例えばＤＮＳクエリ）、セグメントの配信若しくは要求のリダイレクトのためのネットワーク・ノードをセグメント・ロケータがポイントするかを判断する１つ以上の要求メッセージ（例えば、ＨＴＴＰＨＥＡＤまたはＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージ）、および／またはセグメント・ロケータがセグメントの配信のためのネットワーク・ノード、若しくは要求のリダイレクトのためのネットワーク・ノードをポイントするかを示す１つ以上の応答メッセージ（例えば、ＨＴＴＰ２００ ＯＫメッセージ若しくは３ｘｘＲＴＳＰエラー・メッセージ）を含むことができる。

これらメッセージに基づいて、事前解決機能は、ネットワーク情報を用いてセグメント・ロケータを更新することができる（ステップ９０３）。ネットワーク情報に基づいて、更新されたセグメント・ロケータが、セグメント・ロケータに関連付けられるセグメントを配信するために配信ノードをポイントすることが確立される（ステップ９０４）（何故ならば、例えばＨＴＴＰ２００ ＯＫメッセージが受信されたからである。）場合は、事前解決機能は、更新されたセグメント・ロケータが完全に事前解決済みのセグメント・ロケータであることを判断することができる（ステップ９０５）。事前解決機能は更に、マニフェスト・リスト内の当初のセグメント・ロケータを、完全に事前解決済みのセグメント・ロケータで置き換えることによって、セグメント・リストを更新することができる（ステップ９０６）。オプションとして、フラグ、即ち、インジケータを用いて、このように修正したセグメント・ロケータが完全に事前解決済みのセグメント・ロケータに関連することをクライアントにシグナリングすることができる。

ネットワーク情報に基づいて、更新されたセグメント・ロケータは、配信ノードをポイントするのではなく、リダイレクトのためにノードをポイントすることが確立される（何故ならば、例えばＨＴＴＰＲＥＤＩＲＥＣＴが受信されたからである）場合は、事前解決機能は、事前解決処理を停止すべきか否かについて判断することができる（ステップ９０７）。事前解決手段が事前解決処理の係属を決定する場合（ステップ９０８）は、ネットワーク情報を取得する処理が開始される（ステップ９０２）。事前解決処理の停止を決定する場合は、事前解決機能は、更新されたセグメント・ロケータが部分的に解決済みのセグメント・ロケータであると判断することができる（ステップ９０９）。事前解決機能は更に、マニフェスト・ファイル内の当初のセグメント・ロケータを部分的に事前解決済みのセグメント・ロケータで置き換えることによって、セグメント・リストを更新することができる（ステップ９１０）。オプションとして、フラグ、即ちインジケータを用いて、このように修正したセグメント・ロケータが完全に事前解決済みのセグメント・ロケータに関連することをクライアントに示すことができる。

セグメント・リストを更新した後、事前解決機能は、セグメント・ロケータが更に事前解決される必要があるかどうかを判断することができる（ステップ９１１）。この場合は、事前解決機能は、次のセグメント・ロケータに基づいて事前解決処理を開始することができる（ステップ９１２）。

この事前解決処理は、ネットワークからセグメントを抽出する間、バックグラウンドで実施することができる。このようにして、セグメント・リストは、完全におよび／または部分的に事前解決したセグメント・ロケータで継続的におよび動的に更新される。ここでは、事前解決されることになるセグメント・ロケータは、例えばユーザ・プロファイル、ユーザ・ナビゲーション履歴および／若しくはユーザの地理的位置のようなユーザ関連情報のような事前解決済みの情報、または、例えば、事前解決機能が事前解決のためにマークされたセグメント・ロケータを選択することができるために、マニフェスト・ファイル内で識別される特定のセグメント・ロケータをマークするためのセグメント・マーカのようなマニフェスト・ファイル内の情報に基づいて、セグメント・セレクタによって選択される。

図１０は、本発明の一実施形態による事前解決のための適切なセグメント・ロケータの選択について示す。特に、図１０は、時間的にセグメント化されたビデオ、例えばＨＡＳベースのビデオ・ストリームに関連付けられるマニフェスト・ファイル内のどのセグメント・ロケータが、事前解決に適しているかについてセグメント・セレクタが判断するための簡潔なアルゴリズムを示す。この場合、現在視聴されているセグメント１０００の時間的に近くにあるセグメント１００１は事前解決するのに適している。現在視聴されているセグメントから、時間において更に遠く離れて位置する時間的なセグメント（１００２）は、事前解決に（未だ）適していない。一実施形態では、クライアントは、時間的距離を規定する時間的な近接度パラメータを用いることができる。時間的近接度パラメータは、マニフェスト・ファイル内に識別されるどのセグメントが、クライアントによって現在プレイ・アウトされているセグメントに近い時間的近接度にあるかについて決定するために用いることができる。その時間的距離内にある、マニフェスト・ファイルにおいて識別されるセグメントは、事前解決のためにマークすることができる。

図１１は、本発明の他の実施形態により、事前解決のための適切なセグメント・ロケータの選択について示す。特に、図１１は、質的にセグメント化されたビデオに関連付けられるマニフェスト・ファイル内のどのセグメント・ロケータが、事前解決に適しているかについてセグメント・セレクタが判断するための簡潔なアルゴリズムを示す。この場合、品質が現在視聴されている品質（１１００）に（品質の尺度において）近くにある品質レイヤ１１０１に関連付けられるセグメント・ロケータが、事前解決するのに適している。現在視聴されている品質から遠く離れる品質を有する品質レイヤ１１０２に関連付けられるセグメント・ロケータは、事前解決に適していない。一実施形態では、クライアントは、品質的距離を規定する品質的近接度パラメータを用いることができる。品質的近接度パラメータは、マニフェスト・ファイル内に識別されるどのセグメントが、クライアントによって現在プレイ・アウトされているセグメントに近い品質的近接度にあるかについて決定するために用いることができる。その品質的距離内にある、マニフェスト・ファイルにおいて識別されるセグメントは、事前解決のためにマークすることができる。

図１２は、本発明の更なる他の実施形態による、事前解決のための適切なセグメント・ロケータの選択について示す。特に、図１２は、空間的にセグメント化されたビデオに関連付けられるマニフェスト・ファイル内のどのセグメント・ロケータが、事前解決に適しているかについてセグメント・セレクタが判断するための簡潔なアルゴリズムを示す。アルゴリズムは、空間的セグメントのマトリクスを決定する。各空間的セグメントは、空間的セグメントのマトリクスによりカバーされる総合的なエリア内の（点線で形成される）特定の領域のコンテンツに関連付けられる。ユーザは、１つの特定の空間的セグメント１２０１を選択して視聴することができる。したがって、ユーザが（例えば、パニング動作を通じて）端末上に表示されるコンテンツとの相互作用を開始するときは、視聴されているセグメントと直接境界を有する(bordering)１つ以上のセグメントが、プレイ・アウトのためにユーザによって選択されることになるという大きな機会がある。この状況では、事前解決に適した空間的なセグメント・ロケータは、視聴されるセグメントの周りで直接位置特定される。したがって、ユーザ・ナビゲーション情報が特定のエリアｘ，ｙと関連付けられる空間的セグメントがプレイ・アウトされることを示す場合は、セグメント・セレクタは、別のセグメント・ロケータのセット、例えば、位置（ｘ−１，ｙ）（ｘ−１，ｙ−１）（ｘ−１，ｙ＋１）（ｘ，ｙ＋１）（ｘ，ｙ−１）（Ｓｘ＋１，ｙ）（ｘ＋１，ｙ―１）（ｘ＋１，ｙ＋１）でのエリアに関連付けられる空間的セグメント・ロケータを、事前解決に適したセグメント・ロケータとして選択することができる。ユーザ・ナビゲーション情報に基づいて、セグメント・セレクタは、他の空間的セグメントが事前解決に（未だ）適していないと判断することができる。一実施形態では、クライアントは、空間的距離を規定する空間的近接度パラメータを用いることができる。現在視聴されている空間的セグメント（１または複数）からの空間的近接距離内に位置するエリアに関連付けられる空間的セグメントは、事前解決のためにマークされる。

図１３は、本発明の一実施形態により、事前解決のためにマークされる（ＵＲＬの一部としての）未解決のセグメント・ロケータ１３０２を含むマニフェスト・ファイルの少なくとも一部を示す。この特定の実施形態では、コンテンツ・プロバイダまたはＣＤＮプロバイダは、特定のセグメント・ロケータについてのマーカ１３０１ａ，１３０２ｂをマニフェスト・ファイル１３００に挿入することができる。これらのマーカは、セグメントのナビゲーション統計に基づいて挿入することができ、その結果、ポピュラーなセグメント、例えば、頻繁に要求されるセグメントは、マニフェスト・ファイル内のマーカに基づいてクライアントによって識別されることができる。このようなマーカは、セグメント・ロケータを事前解決に適したものとして識別する。一実施形態では、マーカは、ランキング値、例えば有名度スコアに関連付けることができ、その結果、未解決のセグメント・ロケータはランキングに従ってランク付けされることができる。これらのマーカは、つまり、将来のセグメント要求についての１つ以上の別のセグメント識別子を選択するために、セグメント・セレクタのためにランキング方式を提供する。このように、高い有名度スコアに関連付けられる未解決のセグメント・ロケータは、低い有名度スコアに関連付けられるものよりも早期に事前解決することができる。一実施形態では、コンテンツ・プロバイダまたはＣＤＮは、これらマーカをマニフェスト・ファイルに挿入することができる。他の実施形態では、コンテンツ・プロバイダまたはＣＤＮは、新規にマークされたマニフェスト・ファイルを生成することができる。

如何なる一実施形態に関連して説明した如何なる特徴もが単独で、または説明した他の特徴と組み合わせて使用することができ、また、如何なる他の実施形態の１つ以上の特徴と組み合わせて、または如何なる他の実施形態の如何なる組み合わせにおいて使用することもできることが理解されるべきである。

本発明の一実施形態では、コンピュータ・システムと共に使用するためのプログラム製品として実施することができる。このプログラム製品のプログラム（１または複数）は、（本明細書で説明した方法を含む）実施形態の機能を規定し、多様なコンピュータ可読ストレージ媒体上に収容することができる。例示のコンピュータ可読ストレージ媒体は、以下を含むが、これに限定されるものではない。即ち、（ｉ）情報が永続的に格納される、（例えば、ＣＤ−ＲＯＭドライブにより読み取り可能なＣＤ−ＲＯＭディスクのようなコンピュータ内のリード・オンリ・メモリ・デバイス、フラッシュ・メモリ、ＲＯＭチップ、または如何なる種別のソリッド・ステート非一時的半導体メモリのような）非書き込み可能なストレージ媒体、および（ｉｉ）代替可能な情報が格納される、（例えば、ディスケット・ドライブ内のフロッピー・ディスク、ハード・ディスク・ドライブ、または如何なる種別のソリッド・ステート・ランダム・アクセス半導体メモリのような）書き込み可能なストレージ媒体である。本発明は、先に説明した実施形態に限定されることはなく、添付の特許請求の範囲内で変更を加えることができる。

Claims (16)

1. セグメント化されたコンテンツのストリーミングをマニフェスト・ファイルに基づいて可能にするための方法であって、前記マニフェスト・ファイルが、１つ以上のセグメント識別子と、該セグメント識別子によって識別される１つ以上のセグメントをクライアントに配信するように構成される１つ以上の配信ノードを位置特定するための１つ以上の関連のセグメント・ロケ−タとを含み、当該方法が、
   前記マニフェスト・ファイル内のセグメント識別子に少なくとも基づいて、少なくとも１つのセグメントの配信を要求するステップと、
   前記少なくとも１つのセグメント識別子に基づいて、前記マニフェスト・ファイルから少なくとも１つの別のセグメント識別子を選択するステップであって、前記別のセグメント識別子が少なくとも１つの予想される将来のセグメント要求に関連付けられる、ステップと、
   第１セグメント・ロケ−タに関連付けられるネットワーク情報を取得するために、前記選択された別のセグメント識別子に関連付けられる前記第１セグメント・ロケ−タの少なくとも一部を事前解決するステップと、
   を含み、前記事前解決するステップが、
   ネットワーク情報についての要求を、前記第１セグメント・ロケータに関連付けられるネットワーク・ノードに送信するステップであって、該要求がＨＴＴＰＨＥＡＤまたはＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージである、ステップと、
   応答メッセージを受信するステップと、
   前記選択された別のセグメント識別子に関連付けられる前記第１セグメント・ロケータが、前記予想された将来のセグメント要求に関連付けられるセグメントの配信のために配信ノードをポイントするか、または前記予想された将来のセグメント要求のリダイレクトのためにネットワーク・ノードをポイントするかについて、前記応答メッセージに基づいて決定するステップと、
   を含む、方法。
2. 請求項１記載の方法において、前記ネットワーク情報が、前記第１セグメント・ロケ−タの少なくとも一部に関連付けられるネットワーク・アドレスの少なくとも一部に関する情報、前記選択された別のセグメント識別子に関連付けられる第１セグメント・ロケ−タが、前記予想された将来のセグメント要求に関連付けられるセグメントの配信のための配信ノードをポイントする、若しくは前記予想された将来のセグメント要求のリダイレクトのためにネットワーク・ノードをポイントするかについての情報、および／または、前記選択された別のセグメント識別子に関連付けられる第２セグメント・ロケ−タの少なくとも一部を含む、方法。
3. 請求項１または２記載の方法であって、更に、
   前記第１セグメント・ロケ−タがリダイレクトのためにネットワーク・ノードをポイントする場合に、前記第１セグメント・ロケ−タの少なくとも一部を、前記選択された別のセグメント識別子に関連付けられる第２セグメント・ロケ−タの少なくとも一部に事前解決するステップを含む、方法。
4. 請求項１から３のいずれか一項記載の方法であって、
   前記ネットワーク情報に基づいて前記マニフェスト・ファイルを修正するステップを含む、方法。
5. 請求項２または３記載の方法であって、
   前記第２セグメント・ロケ−タの前記少なくとも一部に基づいて前記マニフェスト・ファイルを修正するステップを含む、方法。
6. 請求項５記載の方法において、前記修正するステップが、前記第１セグメント・ロケ−タの少なくとも一部を、前記第２セグメント・ロケ−タの前記少なくとも一部で置き換えるステップを含む、方法。
7. 請求項１から６のいずれか一項記載の方法において、前記事前解決ステップが、前記少なくとも１つのセグメントの少なくとも一部の配信の間、バックグラウンド処理として実施される、方法。
8. 請求項１から７のいずれか一項記載の方法であって、
   ユーザ・プロファイル、ユーザ・ナビゲーション履歴、前記セグメント化されたコンテンツとのユーザ相互作用、並びに／または、前記クライアントおよび／若しくはユーザの地理的位置の内、少なくとも一部に基づいて、前記少なくとも１つの別のセグメント識別子を選択するステップを含む、方法。
9. 請求項１から８のいずれか一項記載の方法において、
   前記セグメント化されたコンテンツが時間的にセグメント化されたコンテンツであり、前記クライアントが、時間的距離を規定する時間的近接度パラメータを使用して、１つ以上の関連するセグメント・ロケータを事前解決するために、前記クライアントによって現在処理されている時間的セグメントから前記時間的距離内に配置される前記時間的セグメントを識別する１つ以上のセグメント識別子をマークおよび／または選択し、
   或いは、
   前記セグメント化されたコンテンツが空間的にセグメント化されたコンテンツであり、前記クライアントが、空間的距離を規定する空間的近接度パラメータを使用して、１つ以上の関連するセグメント・ロケータを事前解決するために、前記クライアントによって現在処理されている空間的セグメントから前記空間的距離内に配置される前記空間的セグメントを識別する１つ以上のセグメント識別子をマークおよび／または、選択し、
   或いは、
   前記セグメント化されたコンテンツが品質的にセグメント化されたコンテンツであり、前記クライアントが、品質的距離を規定する品質的近接度パラメータを使用して、１つ以上の関連するセグメント・ロケータを事前解決するために、前記クライアントによって現在処理されている品質的セグメントから前記品質的距離内に配置される前記品質的セグメントを識別する１つ以上のセグメント識別子をマークおよび／または選択する、
   方法。
10. 請求項１から９のいずれか一項記載の方法において、
    ネットワーク情報についての前記要求が第１コンテンツ配信ネットワーク（ＣＤＮ１）に送信され、前記要求が前記選択された別のセグメント識別子を少なくとも含み、
    前記第１コンテンツ配信ネットワーク（ＣＤＮ１）が、前記選択された別のセグメント識別子によって識別される前記セグメントの将来の配信をネゴシエートするために、前記選択された別のセグメント識別子を含むＣＤＮ間要求メッセージを、第２コンテンツ配信ネットワーク（ＣＤＮ２）に送信し、
    前記第１コンテンツ配信ネットワーク（ＣＤＮ１）が、前記第２コンテンツ配信ネットワーク（ＣＤＮ２）内の１つ以上の配信ノードに関連付けられるネットワーク・アドレスまたはセグメント・ロケータを含むＣＤＮ間応答メッセージを受信し
    前記ＣＤＮ間要求メッセージがインジケータを含み、前記第２コンテンツ配信ネットワーク（ＣＤＮ２）により、前記ＣＤＮ間要求メッセージがセグメント・ロケータについての事前解決に関連付けられるのを判断することを可能にし、または、前記ＣＤＮ間要求メッセージが、ＨＴＴＰＨＥＡＤメッセージ若しくはＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージに基づいて実装され、これにより、前記第２コンテンツ配信ネットワーク（ＣＤＮ２）により、前記ＣＤＮ間要求メッセージがセグメント・ロケータについての事前解決に関連付けられるのを判断することを可能にする、方法。
11. ネットワーク内の１つ以上の配信ノードにホストされたセグメント化されたコンテンツについてのクライアント制御によるストリーミングのためのクライアントであって、
    マニフェスト・ファイルの少なくとも一部を格納するためのマニフェスト・キャッシュであって、前記マニフェスト・ファイルが、１つ以上のセグメント識別子と、該セグメント識別子によって識別される１つ以上のセグメントを当該クライアントに配信するように構成される１つ以上の配信ノードを位置特定するための１つ以上の関連のセグメント・ロケ−タとを含む、マニフェスト・キャッシュと、
    前記マニフェスト・ファイル内の少なくとも１つのセグメント識別子に基づいて、少なくとも１つのセグメントの配信を要求するセグメント抽出機能と、
    前記少なくとも１つのセグメント識別子に基づいて、少なくとも１つの予想される将来のセグメント要求に関連付けられる少なくとも１つの別のセグメント識別子を、前記セグメント抽出機能から選択するように構成されるセグメント・セレクタと、
    第１セグメント・ロケータに関連付けられるネットワーク情報を取得するために、前記少なくとも１つの別のセグメント識別子に関連付けられる前記第１セグメント・ロケータの少なくとも一部を事前解決する事前解決機能と、
    を備え、前記事前解決することが、
    ネットワーク情報についての要求を、前記第１セグメント・ロケータに関連付けられるネットワーク・ノードに送信することと、
    応答メッセージを受信することと、
    前記選択された別のセグメント識別子に関連付けられる前記第１セグメント・ロケータが、前記予想された将来のセグメント要求に関連付けられるセグメントの配信のために配信ノードをポイントするか、または前記予想された将来のセグメント要求のリダイレクトのためにネットワーク・ノードをポイントするかについて、前記応答メッセージに基づいて決定することと、
    を含む、クライアント。
12. 請求項１１記載のクライアントにおいて、前記要求がＨＴＴＰ ＨｅａｄまたはＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージである、クライアント。
13. 請求項１１または１２記載のクライアントにおいて、前記事前解決することが、更に、
    前記第１セグメント・ロケ−タがリダイレクトのためにネットワーク・ノードをポイントする場合に、前記第１セグメント・ロケ−タの少なくとも一部を、前記選択された別のセグメント識別子に関連付けられる第２セグメント・ロケ−タの少なくとも一部に事前解決することを含む、クライアント。
14. 請求項１１から１３のいずれか一項記載のクライアントにおいて、前記事前解決機能が更に、前記ネットワーク情報に基づいて前記マニフェスト・ファイルを修正するように構成される、クライアント。
15. 請求項１１から１４のいずれか一項記載のクライアントにおいて、前記少なくとも１つの別のセグメント識別子を選択することが、ユーザ・プロファイル、ユーザ・ナビゲーション履歴、セグメント化されたコンテンツとのユーザ相互作用、並びに／または、クライアントおよび／若しくはユーザの地理的位置の内、少なくとも一部に基づく、クライアント。
16. コンピュータのメモリにおいて実施したときに、請求項１〜１０のいずれか一項に記載の方法のステップを実行するように構成されるソフトウェア・コード部を含むコンピュータ・プログラム。

Images