JP2018516500A - 動的パッケージャネットワークベースのａｂｒメディア配布および配信 - Google Patents

Abstract

適応ビットレート（ＡＢＲ）メディアを配布するための方法、システム、および非一時的コンピュータ可読媒体が開示される。方法は、第１のネットワークノードにおいて第１のＡＢＲメディア要素を最初に取り込むことと、第１のネットワークノードにおいて、第２のノードにおいて最初に取り込まれた第２のＡＢＲメディア要素を受信することとを含む。方法は、第１のネットワークノードから第１の複数のネットワークノードへの第１および第２のＡＢＲメディア要素の配布を開始することをさらに含む。【選択図】図１Ａ、図１Ｂ

Description

本非仮出願は、次の先行米国仮特許出願、（ｉ）参照により全体を本願に援用する、Ｒａｊ ＮａｉｒおよびＰｒａｂｕ Ｎａｖａｌｉの名において、２０１５年４月１７日に出願した出願第６２／１４９、１５３号明細書「ＤＹＮＡＭＩＣ ＰＡＣＫＡＧＥＲ ＮＥＴＷＯＲＫ ＢＡＳＥＤ ＡＢＲ ＭＥＤＩＡ ＤＩＳＴＲＩＢＵＴＩＯＮ ＡＮＤ ＤＥＬＩＶＥＲＹ」に基づく利益を主張するものである。

本開示は概して、通信ネットワークに関する。さらに詳細に、しかも限定的ではなく、本開示は、ネットワーク環境において動的パッケージャネットワークベースの適応ビットレート（ＡＢＲ）メディア配布および配信を提供するためのシステムおよび方法を対象とする。

コンテンツプロバイダは、長年にわたり、コンテンツ配布ネットワークの帯域幅制限を考慮して、高い可用性および高いパフォーマンスでコンテンツを顧客に提供する方法に取り組んできた。コンテンツ配信ネットワーク（ＣＤＮ）は、インターネットまたはその他のパブリック／プライベート通信ネットワークに接続された複数のデータセンターに配備されたサーバの大規模な分散システムであってもよい。ＣＤＮの目標は、高い可用性および高いパフォーマンスでユーザ機器ノード（ＵＥ）にメディアコンテンツ（たとえば、ビデオ／オーディオ／など）をサーブすることである。メディアコンテンツを受信することができる例示のＵＥは、セットトップボックス、テレビジョン、マルチメディアコンピュータ、および無線端末（たとえば、スマートフォンおよびタブレットコンピュータ）である。

コンテンツプロバイダから中央ＣＤＮサーバおよび／または分散エッジレプリケーションサーバにコンテンツを配布するための帯域幅要件は、適応ストリーミングコンテンツ配信ソリューションの急増と共にすさまじい成長を遂げてきた。適応ストリーミング技術は、１つまたは複数のＣＤＮにわたるオーバーザトップ（ＯＴＴ）コンテンツサーバ上のＯＴＴアプリケーションからコンテンツ（たとえば、ブロードキャストおよびオンデマンドムービー／ＴＶなど）を、多種多様なパフォーマンスおよびプロトコルを有するＵＥにストリーミングすることを求める消費者の需要の高まりに対処するために実施されている。引き続き開発されている例示の適応ストリーミング技術は、Ａｐｐｌｅが主導するＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）プロトコル、Ｍｉｃｒｏｓｏｆｔが主導するＳｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ（ＳＳ） ｏｖｅｒ ＨＴＴＰプロトコル、Ａｄｏｂｅが主導するＤｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇプロトコル、ＭＰＥＧ Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＭＰＥＧ ＤＡＳＨ）プロトコルなどを含む。メディアが帯域幅およびリソースにおいて最低コストで幅広く配布されるようにするために、さらなる開発が必要とされる。

本特許の開示は概して、最適化ＡＢＲメディア配布および配信を容易にするためのシステム、方法、および関連する非一時的コンピュータ可読媒体を対象とする。開示されるシステムおよび方法は、ネットワークにわたりワークロードを分散させつつ、ライセンシング、サービス品質（ＱｏＳ）、ビジネス制約などのような要件が確実に満たされるようにするため、コンテンツのピアツーピア共有および適応メディア配布を制御メカニズムと組み合わせる。ＡＢＲメディアのピアツーピア共有により、コアネットワーク内の任意のパッケージャは、ＡＢＲメディアを取り込むことができ、ＡＢＲメディアおよび他のパッケージャで取り込まれたＡＢＲメディアの両方を配布できるようになる。配布は、場合によっては中間ノードを経由して、主配信元からリモート配信元にエンタイトルメント制御を伝搬する共通エンタイトルメントシステムによって制御される。動的適応メディア配布により、リソースは、システムへの要件が進化するのに応じて最適化されるようになる。適応配布は、新しいパッケージャノードをインスタンス化し、どのパッケージャが固有のメディアを提供しているかを動的に変更し、変化する顧客の要望を満たすために実行中にルーティングを適用する能力を実現する。

ネットワークの動的な特性を制御できるようにするため、サービスマニフェスト（ＳＭ）が、サービスマニフェストコントローラ（ＳＭＣ）によって、パッケージングワークロードを共有するパッケージャのネットワークに提供される。サービスマニフェストは、ルーティング、パッケージング、配信、コンテンツ保護、エンタイトルメントなどに関連する操作を指図する制約を提供して、ビデオオンデマンド（ＶｏＤ）およびチャネルが、提供された制約内でパッケージングを提供する際に最適であると決定される１つまたは複数のネットワークノードからサーブされるようにする。メディアは、メディアが消費される現地地域に近接してパッケージされてもよい。

１つの態様において、ＡＢＲメディアを配布するための方法の実施形態が開示される。方法は、特に、第１のネットワークノードにおいて第１のＡＢＲメディア要素を最初に取り込むことと、第１のネットワークノードにおいて、第２のノードにおいて最初に取り込まれた第２のＡＢＲメディア要素を受信することと、第１のネットワークノードから第１の複数のネットワークノードへの第１および第２のＡＢＲメディア要素の配布を開始することとを備える。

関連する態様において、ＡＢＲメディアを配布するための複数のネットワークノードを備えるシステムの実施形態が開示される。システムは、特に、第１のネットワークノードにおいて第１のＡＢＲメディア要素を最初に取り込み、第１のパッケージャにおいて、第２のネットワークノードにおいて最初に取り込まれた第２のＡＢＲメディア要素を受信し、ピアツーピアの方式で第１の複数のネットワークノードへの第１および第２のＡＢＲメディア要素の配布を開始するように設定される。

さらなる関連する態様において、プロセッサによって実行されるとき、ＡＢＲメディアを配布するための方法を実行するプログラム命令のシーケンスを有する非一時的コンピュータ可読媒体の実施形態が開示される。実行される方法は、特に、第１のネットワークノードにおいて第１のＡＢＲメディア要素を最初に取り込むことと、第１のネットワークノードにおいて、第２のノードにおいて最初に取り込まれた第２のＡＢＲメディア要素を受信することと、ピアツーピアの方式で第１のネットワークノードから第１の複数のネットワークノードへの第１および第２のＡＢＲメディア要素の配布を開始することとを含む。

本開示の実施形態は、同種の参照が類似する要素を指示する添付の図面において、限定的ではなく、一例として説明される。本開示における「ａｎ（ある）」または「ｏｎｅ（１つの）」実施形態への異なる参照が、必ずしも同一の実施形態を示すものではなく、そのような参照が少なくとも１つを意味し得ることに留意されたい。さらに、特定の特徴、構造、または特性が実施形態に関連して説明される場合、明示的に説明されているかどうかにかかわりなく、その他の実施形態に関連してそのような特徴、構造、または特性を達成することは当業者の知るところであることが提示される。

添付の図面は、本発明の１つまたは複数の例示的な実施形態を説明するために、明細書に組み入れられ、その一部を形成する。本開示のさまざまな利点および特徴は、付加されている特許請求の範囲に関連し添付の図面を参照して示される以下の発明を実施するための形態から理解されるであろう。

開示される実施形態が動作することができる汎用のメディアネットワークを示す図である。 開示される実施形態が動作することができるメディアネットワークのアーキテクチャを示す機能図である。 本特許開示の実施形態による、ピアツーピア関係で動作するパッケージャのネットワーク、およびそこに関連付けられているサービスマニフェストコントローラのネットワークを示す図である。 本特許開示の実施形態による、メディアをクライアントに配信するために使用されるネットワーク構造の例を示す図である。 本特許開示の実施形態によるサービスマニフェストのフォーマットの例を示す図である。 本開示の実施形態によるプッシュ配布を使用するネットワークの例を示す図である。 本開示の実施形態によるプル配布を使用するネットワークの例を示す図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 本特許開示の実施形態によるネットワークにおいてＡＢＲメディアを配布するための方法を示す流れ図である。 知られている技術によるネットワークにおいてＡＢＲメディアを配布するためのネットワークを示す図である。 知られている技術によるネットワークにおいてＡＢＲメディアを配布するためのネットワークを示す図である。 知られている技術によるＡＢＲメディアを配布するためのネットワークを示す図である。

以下の説明において、多数の具体的な詳細が、本特許開示の１つまたは複数の実施形態に関して示される。しかし、１つまたは複数の実施形態は、そのような具体的な詳細を伴うことなく実施され得ることを理解されたい。その他の例において、よく知られているハードウェア／ソフトウェアサブシステム、コンポーネント、構造、および技術は、例示の実施形態の理解を不明瞭にすることがないように、詳細には説明されていない。したがって、本開示の実施形態が、１つまたは複数のそのような具体的なコンポーネントを参照することを必要とせずに実施されてもよいことは、当業者には明らかとなろう。さらに、当業者であれば、本明細書において示される発明を実施するための形態を用い、添付の図面を参照して、過度な実験を伴うことなく１つまたは複数の実施形態を使用することができるであろうことを理解されたい。

加えて、「結合された（ｃｏｕｐｌｅｄ）」および「接続された（ｃｏｎｎｅｃｔｅｄ）」のような用語は、それらの派生語と共に、以下の説明、特許請求の範囲、またはその両方において使用されてもよい。これらの用語が、必ずしも相互の同義語として意図されているわけではないことを理解されたい。「結合された（ｃｏｕｐｌｅｄ）」は、２つ以上の要素が、相互に直接の物理的または電気的接触がある場合もない場合もあるが、相互に共同または対話することを指示するために使用されてもよい。「接続された（ｃｏｎｎｅｃｔｅｄ）」は、相互に結合されている２つ以上の要素間の、通信の確立、つまり通信関係を指示するために使用されてもよい。さらに、本明細書における１つまたは複数の例示の実施形態において、一般的に言えば、要素、コンポーネント、またはモジュールは、要素が機能を実行することができるか、またはその機能を実行するように構造的に配列されている場合に、機能を実行するように設定されてもよい。

本明細書において使用されるように、ネットワーク要素またはノードは、ハードウェアと、ネットワーク上のその他の機器（たとえば、その他のネットワーク要素、エンドステーションなど）と通信可能に相互接続し、１つまたは複数のアプリケーションまたはサービスを、仮想化または非仮想化環境のいずれかにおいて、さまざまなアクセスネットワーク、送信技術、アーキテクチャ、ストリーミングプロトコルなどの１つまたは複数を使用してメディアコンテンツをストリーミングするように適合されたネットワークインフラストラクチャにおいてコンテンツを受信／消費するように動作可能な複数の加入者および関連するユーザ機器に関して、ホスティングするように適合されたソフトウェアを含む、１つまたは複数のサービスネットワーク機器で設定されてもよい。そのようなものとして、一部のネットワーク要素は、無線ラジオネットワーク環境に配置されてもよいが、その他のネットワーク要素は、適切なコンテンツ配信ネットワーク（ＣＤＮ）インフラストラクチャを含むか、または伴う、パブリックパケット交換ネットワークインフラストラクチャに配置されてもよい。さらに、本明細書において示される１つまたは複数の実施形態と共に動作可能である適切なネットワーク要素は、地上波および／または衛星ブロードバンド配信インフラストラクチャ、たとえばデジタル加入者線（ＤＳＬ）アーキテクチャ、Ｄａｔａ Ｏｖｅｒ Ｃａｂｌｅ Ｓｅｒｖｉｃｅ Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＤＯＣＳＩＳ）準拠のケーブルモデム終端システム（ＣＭＴＳ）アーキテクチャ、適切な衛星アクセスネットワークアーキテクチャまたはブロードバンド無線アクセスネットワークアーキテクチャなどを伴うことができる。加えて、特定の実施形態における一部のネットワーク要素は、複数のアプリケーションサービス（たとえば、データおよびマルチメディアアプリケーション）のサポートを提供することに加えて、複数のネットワークベースの機能（たとえば、Ａ／Ｖメディア配信ポリシー管理、セッション制御、ＱｏＳポリシー実施、帯域幅スケジューリング管理、加入者／デバイスポリシーおよびプロファイル管理、コンテンツプロバイダ優先ポリシー管理、ストリーミングポリシー管理など）のサポートを提供する「複数のサービスネットワーク要素」を備えることができる。例示の加入者エンドステーションまたはクライアントデバイスは、複数のメディア配信またはストリーミング技術を使用してメディアコンテンツを受信するように動作可能なさまざまなコンテンツ記録、レンダリング、および／または消費デバイスを備えることができる。したがって、そのようなクライアントデバイスは、本明細書において示される１つまたは複数の実施形態と組み合わせて適切な高速ブロードバンド接続を介して提供されるコンテンツ／サービスにアクセスするかまたは消費することができる、セットトップボックス（ＳＴＢ）、ネットワークＴＶ、パーソナル／デジタルビデオレコーダ（ＰＶＲ／ＤＶＲ）、ネットワークメディアプロジェクター、ポータブルラップトップ、ネットブック、パームトップ、タブレット、スマートフォン、マルチメディア／テレビ電話、モバイル／無線ユーザ機器、ポータブルメディアプレイヤー、（Ｗｉｉ（登録商標）、Ｐｌａｙ Ｓｔａｔｉｏｎ３（登録商標）などのような）ポータブルゲームシステムまたはコンソールなどを含むことができる。

本特許開示の１つまたは複数の実施形態は、ソフトウェア、ファームウェア、および／またはハードウェアのさまざまな組み合わせを使用して実施されてもよい。したがって、図面（たとえば、流れ図）に示される技術の１つまたは複数は、１つまたは複数の電子デバイスまたはノード（たとえば、加入者クライアントデバイスまたはエンドステーション、ネットワーク要素など）上で格納され実行されるコードおよびデータを使用して実施されてもよい。そのような電子デバイスは、非一時的コンピュータ可読ストレージ媒体（たとえば、磁気ディスク、光ディスク、ランダムアクセスメモリ、読み取り専用メモリ、フラッシュメモリデバイス、位相変化メモリなど）、一時的コンピュータ可読送信媒体（たとえば、キャリア波、赤外線信号、デジタル信号のような、電気、光、音響またはその他の形態の伝搬信号）などのような、コンピュータ可読記憶媒体を使用してコードおよびデータを格納および（内部的に、および／またはネットワークを介してその他の電子デバイスと）通信することができる。加えて、そのようなネットワーク要素は、通常、１つまたは複数のストレージデバイス（たとえば、非一時的機械可読ストレージ媒体）およびストレージデータベース、ユーザ入力／出力デバイス（たとえば、キーボード、タッチスクリーン、ポインティングデバイス、および／またはディスプレイ）、ならびにシグナリングおよび／またはベアラメディア送信を遂行するためのネットワーク接続のような、１つまたは複数のその他のコンポーネントに結合された１つまたは複数のプロセッサのセットを含むことができる。プロセッサのセットとその他のコンポーネントの結合は、通常、任意の知られている（たとえば、対称／共有マルチプロセッシング）または従来知られていないアーキテクチャに配列された、１つまたは複数のバスおよびブリッジ（バスコントローラとも称される）を経由してもよい。したがって、所与の電子デバイスまたはネットワーク要素のストレージデバイスまたはコンポーネントは、本開示の１つまたは複数の技法を実施する目的のために、その要素、ノード、または電子デバイスの１つまたは複数のプロセッサで実行するためにコードおよび／またはデータを格納するように設定されてもよい。

適応ストリーミング技術は、ソースメディアコンテンツストリームを、さまざまなコーディングビットレートを有する複数のコンテンツストリームに変換する。複数ビットレートのコンテンツストリームのグループは、ＵＥにより使用されるさまざまなストリーミングプロトコル（たとえば、ＨＬＳプロトコル、Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇプロトコル、Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇプロトコル、ＭＰＥＧ ＤＡＳＨプロトコルなど）によって必要とされ得るさまざまな配布コンテナフォーマットを有する複数ビットレートのコンテンツストリームの複数のグループを提供するようにトランスコードされてもよい。したがって、複数ビットレートのコンテンツストリームの単一のグループは、配布され中央ＣＤＮサーバに格納される、および／または多数の異なるタイプのＵＥへの高可用性および高パフォーマンス配信を可能にするためにエッジレプリケーションサーバに配布されることが必要な、異なるフォーマットが行われた複数ビットレートのコンテンツストリームの多数のグループを結果としてもたらすことができる。

例示の適応ストリーミングサーバシステムは、ライブソースおよび／またはスタティックファイルソース、たとえばＨｕｌｕ（登録商標）、Ｎｅｔｆｌｉｘ（登録商標）、ＹｏｕＴｕｂｅ（登録商標）、またはＡｍａｚｏｎ（登録商標）Ｐｒｉｍｅなどのオンラインコンテンツプロバイダからメディアコンテンツを受け入れるように設定されてもよい。ライブソースからのメディアコンテンツは、任意のタイプのイベント、たとえばスポーツ／エンタテイメント／ゲームイベント、コンサート、ライブＴＶショー、ライブニュースブロードキャストなどに関して取り込まれるライブプログラムを備えることができる。一般的な操作において、例示のストリーミングサーバシステムは、永続メモリモジュールに格納されている適切なプログラムコードを実行する１つまたは複数のプロセッサの制御の下に、コンテンツの適応ストリーミングを以下のように実施するように設定されてもよい。最初に、ソースメディアコンテンツはトランスコードされるか、または適切なエンコーダを使用して異なるビットレート（たとえば、マルチレートトランスコーディング）でエンコードされる。たとえば、特定のプログラムのコンテンツは、低ビットレートから高ビットレートに及ぶ（例として、５００Ｋｂｐｓから１０Ｍｂｐｓ）、可変ビットレート（もしくは、同義語として「ビットレート」または「分解能」）を使用して５つのビデオファイルにトランスコードされてもよい。したがって、特定のコンテンツは、５つの異なる「バージョン」または「フォーマット」としてエンコードされ、各ビットレートはプロファイルまたは表現と称される。セグメンテーションサーバまたはセグメンタは、エンコードされたメディアコンテンツの各バージョンを、通常は２から１０秒の期間である、固定の期間セグメントまたはチャンクに分割し、それにより複数のチャンクストリームを生成するように動作可能である。当業者であれば、より短いセグメントが、コーディング効率を低下させることがあり、一方より大きいセグメントが、ネットワークスループットの変化および／または急速に変化するクライアントの振る舞いへの適応性に影響を及ぼし得ることを理解するであろう。チャンクのサイズにはかかわりなく、セグメントは、すべてのエンコーディングプロファイルが同じセグメントを有するように、Ｇｒｏｕｐ−ｏｆ−Ｐｉｃｔｕｒｅｓ（ＧＯＰ）でそろえられてもよい。次いで、マニフェストファイルと称される１つまたは複数の適切なメタデータファイルが作成され、これはエンコードされたコンテンツのさまざまなセグメントに対してエンコーディングレートおよびユニフォームリソースロケータ（ＵＲＬ）ポインタを記述する。したがって、メディアセグメントは、配信／配布のために適切なストリーミングプロトコルに基づいてパッケージされてもよい。従来のアーキテクチャは、異なる地域、容量、ネットワーク負荷、およびその他の制約へのメディアまたはコンテンツチャネルの適応をもたらさないことを理解されたい。

以下で分かるように、コンテンツは、マルチキャストＡＢＲ技法またはユニキャストＡＢＲ技法を使用して配信されてもよい。ユニキャスト配信において、加入受信機には、要求されたデータストリームを供給するサービングメディアサーバに至るまで配信ネットワーク経由の直接および一意の双方向パスが提供されてもよい。主要ストリーミングアクティビティは、通信セッションにおいて受信機とソースサーバとの間で１対１で管理される。ソースサーバと受信機との間のネットワークは通常、ネットワークノードにおいてインストールされた一連の中間サーバを備えることができ、これはサービスには直接関与せず、パケットストリームの転送をサポートするだけである。通常、送信をサポートするために使用されるプロトコルは、フロー制御をもたらすために１つまたは複数の上位レイヤプロトコルにより増補されたインターネットプロトコル（ＩＰ）自体の簡単な形式である。これらのプロトコルは、ソースサーバと所与の受信機との間のリンクの長さにわたり拡張する。

ユニキャストシステムは、ＡＢＲストリーミングをサポートすることができ、レート適応の一部の形式を可能にする。所与のサービスは、（表現として知られる）さまざまなビットレートの選択において、規定された位置における同期化境界ポイント（たとえば、５０フレームごと）によりエンコードされてもよい。各表現について、連続する境界ポイント間のコンテンツは、個別のファイルに変換される。これにより、クライアントは、表現の１つのセグメントを取り出す。より高い、または低いビットレートが要求される場合、次のセグメントは、その他の表現のうちの１つから取り出される。セグメントは、クライアントが境界ポイントにおいて表現の間を切り替える場合に、デコードされたピクチャ／オーディオの不連続性がないように構築される。このシステムは、ファイルを要求するため、および要求されたファイルを配信するために、ソースと受信機との間のユニキャスト双方向パスを必要とする場合がある。

マルチキャスト配信は、コンテンツストリームをいくつかの受信機で共有することにより、帯域幅をさらに効率的に使用する。中間ネットワーク要素（たとえば、ルータまたはスイッチ）は、これ以降、一部の制御および管理機能がソースサーバから代行されるように、サービス提供にさらに密接に関与する。この制御は、Ｐｒｏｔｏｃｏｌ Ｉｎｄｅｐｅｎｄｅｎｔ Ｍｕｌｔｉｃａｓｔ（ＰＩＭ）およびＩｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍｕｌｔｉｃａｓｔ Ｐｒｏｔｏｃｏｌ（ＩＧＭＰ）のような、このタイプのアプリケーション向けに考案されたより広範なプロトコルによってサポートされる。新しい受信機が所与のメディア項目を要求すると、ネットワークルータシステムは、すでにネットワークにあるそのコンテンツの既存のストリームを見つけ出し、そのコピーを、サービングケーブルヘッドエンド、またはエッジ配布ネットワークの適切な隣接ネットワークノードから、その新しい受信機へと方向付ける。要求側受信機は、既存の受信機に悪影響を及ぼすことのない制御された条件下でこの既存のストリームに加わる機能が提供されてもよい。このグループの任意の受信機はまた、その他の受信機に影響を及ぼすことなく、ストリームを抜けるか、または消費を休止することができてもよい。加えて、施設へのビデオパイプ配信サービスが、バーストでビデオを受信するよう設計されている施設の１つまたは複数のプログレッシブダウンロードＡＢＲクライアントにコンテンツを配布するように動作可能である実施態様があってもよい。

これ以降、図面、および具体的には図８Ａを参照すると、従来のパッケージングモデル８００の例が示される。ブロードキャストエンコーダ８０２は、メディアストリーム８０３をトランスコーダ／パッケージャ８０４に提供する。メディアストリーム８０３は、単一ビットレートを含むＭＰＥＧ−ＴＳフォーマットでエンコードされる。トランスコーダ／パッケージャ８０４のトランスコーダ部分は、ＭＰＥＧ−ＴＳストリームを取り込み、複数ビットレートレベルを生成する。次いで、トランスコーダ／パッケージャ８０４のパッケージャ部分は、ＤＡＳＨ、ＨＬＳ、ＳＳなどのような、適応可能なストリーミングプロトコルに基づいて、適切なコンテナにメディアをカプセル化する。結果として得られるＡＢＲメディアストリーム８０７およびクライアントマニフェスト８０５は、たとえば、ここではＨＬＳ、ＳＳ、およびＤＡＳＨとして示される、望ましいフォーマットで配信元８０６に提供される。配信元８０６は、エッジノードまたはＣＤＮ内の上位レベルコンテンツ配布ノードであってもよく、望ましいメディアを受信するためにクライアントによってアクセス可能である。この集中データセンター配備モデルは、パブリックまたはプライベートのＣＤＮを使用することができ、固定のチャネルおよびＶｏＤメディア設定で設定された限られたユーザセットを網羅する、つまりすべてのクライアントが同一のコンテンツを有するチャネルまたはメディアカタログを受信する。トランスコーダおよびパッケージャリソース８０４は、手動でプロビジョニングされ、地域、容量、ネットワーク負荷などのさまざまなニーズを満たすためのメディアまたはチャネルの適応はあり得ない。

図８Ｂは、マルチキャストマルチビットレート（ＭＢＲ）適応転送ストリーム（ＡＴＳ）データの類似したパッケージングモデル８００Ｂを示す。ＭＢＲ ＡＴＳエンコーダ８１２は、ＭＰＥＧ−ＴＳストリームを受信し、再度単一ビットレートのマルチキャストＭＢＲ ＡＴＳストリームをトランスコーダおよびパッケージャ８１４に提供する。加えて、ＭＢＲ ＡＴＳエンコーダ８１２はまた、ストリームマニフェスト８１５をトランスコーダおよびパッケージャ８１４に提供する。ストリームマニフェスト８１５は、ＭＢＲ ＡＴＳエンコーダ８１２とトランスコーダおよびパッケージャ８１４との間のＡＴＳの転送を制御し、たとえばエンコーダ境界ポイント（ＥＢＰ）を識別することなど、マルチキャストストリームの特性に関する情報を提供する。次いで、トランスコーダおよびパッケージャ８１４は、メディアセグメント８１９およびクライアントマニフェスト８１７を望ましいフォーマットで配信元８１６に提供する。

図９は、知られている技術によるＡＢＲメディアを配布するためのもう１つのネットワークを示し、示されている例ではＤＡＳＨ ＡＢＲ参照アーキテクチャのＳｏｃｉｅｔｙ ｏｆ Ｃａｂｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｅｎｇｉｎｅｅｒｓ（ＳＣＴＥ）規格１２０６に従う。ネットワーク９００において、トランスコーダ９０２は、ライブストリーミングメディアとＶｏＤ（具体的には図示されず）の両方を受信し、Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｓｕｂｃｏｍｍｉｔｔｅｅ（ＤＶＳ）によりＡＴＳセットを出力する。ＡＴＳセットは、入力メディアのマニフェスト９０４と複数ビットレートストリーム９０６の両方を含むが、これ以降エンコーダ境界ポイント（ＥＢＰ）構造を含む。ＡＴＳセットは、セグメンタ／パッケージャ９０８に直接送信されてもよいか、またはストレージＡ９１０のようなキャッシュに送信されてもよい。

セグメンタ／パッケージャ９０８は、入力ストリームをセグメント化して、ＤＡＳＨ／ＴＳに基づいて中間フォーマットでストリームをパッケージする。セグメンタ／パッケージャ９０８は、マニフェスト９１２およびメディアストリーム９１４を、直接ＣＤＮ９１６またはストレージＢ９１８に提供する。ジャストインタイムパッケージング（ＪＩＴＰ）パッケージャ９２０は、マニフェストおよびストリームをＣＤＮ９１６、ストレージＡ９１０、およびストレージＢ９１８のいずれかから受信し、固有のクライアントフォーマットへのＤＡＳＨフォーマットストリームの変換を実行する。これらのクライアントフォーマットはＣＤＮ９２２に送信され、そこでマニフェストおよびメディアストリームは共に、ＤＡＳＨ ＩＳＯＢＭＦＦクライアント９２４、ＨＬＳクライアント９２６、ＨＳＳクライアント９２８、およびＤＡＳＨ／ＴＳクライアント９３０のようなさまざまなクライアントに送信される。

メディア提供の要求が急増していることに応じて、出願人は、図１Ａに示されるようにＡＢＲメディアの配布および配信のための改良された全般的アーキテクチャを構想した。この出願のコンテキストにおいて、「配布（ｄｉｓｔｒｉｂｕｔｉｏｎ）」は概して、コアネットワーク内およびエッジサーバへのメディアのプロビジョニングを説明するために使用され、一方メディアの「配信（ｄｅｌｉｖｅｒｙ）」は、エッジサーバとクライアントとの間で行われる。この図で分かるように、ネットワーク１００Ａは、この例においては全国データセンターであるスーパーヘッドエンド１０２、および地域データセンター１０４、１０６を含む。地域データセンター、パッケージャ、ＣＮＤなどの数は、例示のためのものに過ぎず、任意の数のこれらの要素を含むことができることが理解されよう。全国データセンター１０２は、地域データセンター１０４、１０６の各々に接続され、地域データセンター１０４、１０６は、相互におよびその他の地域データセンター（具体的に図示せず）に接続されている。全国データセンター１０２は、ＣＤＮ１１０、および一部がクライアントにメディアを提供するエッジパッケージャであるパッケージャ１１２を含む。すべてのパッケージャが場合によってはエッジパッケージャであるが、すべての場合においてそのように使用されるわけではない。地域データセンター１０４は、ファイバーネットワーク内にあり、地域データセンター１０６は、Ｌｏｎｇ−Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）ネットワーク内にあり、いずれもパッケージャ１１２を含むが、エッジパッケージャと非エッジパッケージャの両方を含むことができる。クライアントに提供されるメディアは、ネットワーク１００Ａ内の複数のポイントにおいて発信することができ、地域データセンター１０４と１０６の間の境界、およびスーパーヘッドエンド１０２との境界のような、境界にわたり交換されてもよい。スーパーヘッドエンド１０２と地域データセンター１０４、１０６との間の接続により、交換されるメディアに課されるすべての制約に従うために必要なエンタイトルメントおよびビジネス協定のような、メディアおよび制御情報の交換が可能になる。図示されているデータセンターは、現地またはエッジデータセンターのレイヤにさらに拡張されるが、これらのデータセンターは、簡潔にするため、およびネットワークの配布側に集中するために示されていない。たとえばブラックアウトまたは現地広告のための、メディアの地域化は、これらのエッジデータセンターにおいて行われ得る。

開示されるネットワークは、本明細書において開示される動的適応メディア配布を実施するために使用されてもよく、配布されるメディアのパッケージングおよび発信を可能にする制御プレーンアーキテクチャを提供する。この制御プレーンアーキテクチャは、複数の領域および複数のプロバイダにわたるメディア配布、ならびにたとえば挿入およびブラックアウトのためのローカライズをサポートする。アーキテクチャは、ライブチャネル、チャネルバンドルおよびＶｏｄカタログ（ネットワークデジタルビデオレコーダ（ｎＤＶＲ）およびキャッチアップ格納メディアを含む）の両方のルーティングをサポートし、動的および適応クラウドベースのパッケージャ編成を提供するために使用されてもよい。サービスの動的ロールアップおよび配布ならびにネットワークレベル分析法は、このモデルの動的な適応特性をサポートするために提供される。

上記で言及され、後段においてさらに詳細に説明されるように、協働を容易にするためのガイドラインは、たとえばチャネル、チャネルバンドルまたはＶｏＤメディア要素のグループ（つまり、カタログまたはサブカタログ）に関連付けられ得るサービスマニフェストで搬送される。少なくとも１つの実施形態において、所与のサービスマニフェストは、たとえば所与のスタジオからのすべてのＶｏＤおよび／またはチャネルに適用される。サービスマニフェストは、メディアが取り込まれる時点においてＳＭＣによって作成され、ネットワークを経由する際に変更されてもよい。ＳＭＣは、ＳＭＣが制御するパッケージャおよびその他のＳＭＣにも結合される。ＳＭＣは、配信ドメインにわたりチャネル／カタログルーティングおよびコンテンツピアリングを提供するように協働することができ、リソース、ビジネス論理、および分析法によって提供される制約内でサービスのプロビジョニングを編成することができる。

マルチドメイン配信を容易にするために、ＳＭＣは、単一プロバイダネットワーク内または複数プロバイダネットワークにわたるドメイン間ＳＭＣとのピアツーピア交換に従事する。ＳＭＣは、境界ルータにおいてサマリーサービスマニフェストを交換することができ、ここでＳＭＣは、ビジネスルールのサマリーまたは集約を提供することができる。これらのサマリーサービスマニフェストは、ＡＢＲメディアの下流プロバイダによって行われたＳＬＡに関するエンタイトルメントおよび情報を交換するために使用されてもよい。サマリーマニフェストはまた、ＡＢＲメディアをプロバイダネットワークに戻す配信に関するＡＢＲメディア分析法を提供するために使用されてもよい。ＳＭＣはまた、チャネルバンドルおよび／またはサブカタログも交換することができる。論理トランスポート制御機能は、さまざまなタイプの転送、たとえばＬＴＥ、ＤＳＬ、またはケーブルにわたり作用する抽象化を提供し、サービスマニフェスト操作を使用してメディアの最適化を可能にする。論理トランスポート制御機能内で、コンバージェンスレイヤは、固有のトランスポートタイプの詳細を抽象化し、各ネットワークが、関連するメディアを配信する最善の方法を決定できるようにする。トランスポートの各タイプ内で、サービスマニフェストのプロバイダ制御による操作は、地域のサービスを最適化するために使用されてもよい。メディアフォーマットは、トランスポートタイプを越えるときに変換され、ネットワーク分析法は、配布のために収集されてロールアップされる。複数のドメインが現在、組織内で情報を共有することができ、開示される実施形態はこの機能を、共に取り組むさまざまなプロバイダに拡張する。サービスマニフェストは、２つの異なる企業に属するＳＭＣが同じサービスマニフェストで稼働することができるように、ビジネス論理、エンタイトルメント、サービスレベルアグリーメント（ＳＬＡ）、およびドメイン間の交換を規定する手段をもたらす。

図１Ｂは、ネットワーク１００Ｂの全体的アーキテクチャを示す機能図である。機能的には、ネットワーク１００Ｂは、メディアストリームがクライアントへの提示のために処理され準備されるメディア処理および配信プレーン１２２と、ネットワークの全体的制御およびメディアの配布が管理されるメディア制御および情報プレーン１２０という２つのプレーンで動作する。メディア処理および配信プレーン１２２の機能エンティティは、ネットワークおよびクラウド管理を含むプログラマブル動的ネットワーク自動化を管理するサービスプロバイダソフトウェア規定のネットワーク１２４、キャプチャ／プレイアウト１２６、任意のデバイスまたはアプリケーションにわたりメディアを適応させることにより拡張ビデオ体感をもたらす変換１２８、コンテンツリポジトリ１３０（つまり、ストレージ）、品質管理１３２、転送１３４、トランスコーディングおよびセグメンテーション１３６、メディア配信１３８、ならびにモバイルブロードキャスト１４０を含む。メディア制御および情報プレーン１２０は、ネットワークのエンドツーエンドの制御を提供し、リソースマネージャ１４２、コンテンツ準備１４４、コンテンツ情報１４６、チャネル生成１４８、広告バックエンド１５０、コンテンツ保護１５２、カタログマネージャ（ＶｏＤ向け）１５４、推奨エンジン１５６、およびマルチスクリーン制御１５８のような機能エンティティを含む。メディアクライアント１６０は、ＵＥの一部であるか、またはネットワークで仮想化されてもよく、メディアクライアント１６０は、デバイス上のユーザから入力を受信し、メディア処理および配信プレーン１２２とメディア制御および情報プレーン１２０の両方とインターフェイスを取る。分析法１７０、オペレーションサポートシステム（ＯＳＳ）１７２、およびビジネスサポートシステム（ＢＳＳ）１７４の機能エンティティは、両プレーン上のすべての機能と対話する。

メディアの配布および配信は、このアーキテクチャ内の３つのレベルにおいて管理される。最下位の、つまり物理、レベルは、たとえばＴＣＰまたは物理レイヤのその他のプロトコルを使用してメディアをトランスポートする、トランスポート制御１６２である。物理レイヤの上には、（たとえば、ＨＬＳまたはＤＡＳＨの）ＨＴＴＰレベルにおいて動作する、ストリームマニフェスト制御１６４がある。メディアと共に送信されるストリームマニフェストはまた、クライアントマニフェストとも称され、ユーザに提示するためにストリームがどのように処理されるべきかをクライアントデバイスに伝える。サービスマニフェスト制御１６６は、ネットワーク内のメディアのエンドツーエンドの制御を提供するようにサーブする。サービスマニフェストは、ストリームの制御に携わっており、メディアの実際の制御が分散化されるように、メディアに関連付けられているエンタイトルメント、メディアがどのように準備されるかに関する制限などのような、メディアの配布および配信の任意の局面に関連し得る情報を提供するために使用される。

メディア配布および配信のコンテキストにおいて、エンタイトルメントは、メディアとユーザとの関係、つまりメディアがどのように消費され得るかを規定するビジネスルールを示す。エンタイトルメントは、誰が、いつ、どこで、メディアにアクセスし得るかを含むことができ、加入者、コンテンツ権利、および配信エンドポイントまたはデバイスの相関を必要とする。分散ネットワークにわたりエンタイトルメントを管理するために、ネットワークにわたるコンテンツとユーザ両方に識別が標準化される必要があり、分析法がネットワーク全体を通じて伝搬される必要がある。サービスマニフェスト制御１６６は、コンテンツ、つまりチャネルおよびＶｏＤに関連付けられているエンタイトルメントに特に携わっている。

固有のチャネルは、そのチャネルが使用可能であればどこでも同じ外観であったように、チャネルは従来から、それらの関連するコンテンツとの静的な結合を有していた。開示される実施形態において、チャネルはこれ以降、コンテンツに関してさらに動的な特性を呈することができる。全国データセンターによって生成されるチャネルは、たとえば、広告の現地挿入、異なる地域のプログラムの代替、および「サイマルキャスト」、つまり固有のチャネルのプログラムの代替として、またはイベントの期間のみ使用可能であって期間限定である別個のチャネルのプロビジョニングとして、卒業式、現地スポーツイベントのような現地イベントのブロードキャストを提供する可能性、のようなさまざまな地域の変動を有することがある。そのような現地の変動の包含は、ビジネスルールおよびネットワークポリシーに従って提示を制御するその他の規制によって管理される必要がある。

これらの新しいタイプの情報は、メディアを提供するネットワークエンティティによって作成され、ネットワークにわたるニーズを満たすように変更され、メディアの配布および配信中にガイダンスを提供してコンプライアンスを強化するために使用され得る、サービスマニフェストによってネットワークにわたり搬送されてもよい。ストリームマニフェストが、ビットレート、フォーマット、および関連するリソースを制御するネットワーク要素である場合、サービスマニフェストは、エンドツーエンドの制御およびエンタイトルメントの作成に関するすべてとなる要素である。サービスマニフェストを作成し対話するＳＭＣは、ネットワークにわたり多数の場所において作成されてもよい。通常、各地域データセンターは、１つまたは複数のＳＭＣを有する。追加のＳＭＣは、ネットワークの固有の部分のビジネスルールを提供するために望ましいネットワークの任意の部分に作成されてもよい。たとえば、ダウンストリームマニフェストコントローラは、以下の事項のために作成されてもよい。
− スーパーヘッドエンドから地域ヘッドエンドへの横断
− コアネットワークからエッジネットワークへの横断
− １つのネットワーク管理ドメインから別のネットワーク管理ドメインへの横断
− 有線ネットワークと無線ネットワークの間
− ホールセールとアクセスネットワークの間

開示されるＡＢＲメディア配布モデルにおいて、パッケージャの動的ネットワークは、さまざまな組織によって制御され得る複数ドメイン横断を含むメディア／チャネルを配布するために使用される。ＡＢＲメディア／チャネルの消費の増大に伴って、メディア／チャネルの一部は現地地域に近い位置からサーブされる必要がある。パッケージャおよびＣＤＮは、中央および地域データセンターの両方で配布されてもよく、同じメディアカタログ／チャネルが中央および地域データセンターの両方からサーブされるようにすることができる。所与のチャネルについて、各地域は、サービス、フォーマット、コンテンツ保護、広告挿入、ストレージ、およびメタデータに関して異なるストリームおよび異なる要件を有することがある。これらの相違は、動的編成ならびに制約ベースのルーティング（ＣＢＲ）によるメディアカタログおよびチャネルの配信を使用して満たされてもよい。

複数の制約および／またはパケットコンテンツに基づくインテリジェントパス選択は、既存のパッケージャを動的に設定すること、パッケージャを追加または削除すること、および／またはエンドツーエンドパスの１つまたは複数の階層レベルにおいて新しいパッケージャインスタンスをインスタンス化することに加えて、（たとえば、さまざまな地域、ネットワーク容量、負荷などへのコンテンツの適応を目的として）さまざまな要因を考慮に入れる。本明細書において示されるＣＢＲは、パス選択決定が、宛先およびＱｏＳ制約に加えて、要件または制約のセット（ビジネスルール、ＳＬＡ、加入者ベースのポリシー、コンテンツプロバイダポリシーなど）に基づく上位レイヤルーティングアルゴリズムのクラスを指示する。これらの制約は、管理ポリシーによって、またＱｏＳ要件によって課せられてもよい。ポリシーによって課せられる制約は、ポリシー制約と称されてもよく、関連するルーティングは、ポリシールーティング（または、ポリシーベースのルーティング）と称されてもよい。たとえば帯域幅、遅延、または損失のような、ＱｏＳ要件によって課せられる制約は、ＱｏＳ制約と称されてもよく、関連するルーティングは、ＱｏＳルーティングと称されてもよい。本明細書におけるＣＢＲベースの実施形態は、フロー集約（マクロフローまたはトランクとしても知られる）および／または個々のマクロフロー（たとえば、単一のハイパーテキスト転送プロトコル（ＨＴＴＰ）接続）を考慮することができる。

ネットワークの少なくとも一部は、知られている規格および仕様に従う適切なＴＣＰ／ＩＰ／ＵＤＰベースのルーティングプロトコルを伴うことができる。説明としては、ネットワーク環境の一部は、中間システム−中間システム（ＩＳ−ＩＳ）ルーティングプロトコル、Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ（ＯＳＰＦ）ルーティングプロトコルなどのようなリンク状態プロトコル、および／またはドメインまたは自律システム（ＡＳ）内で情報をルーティングするために使用され得るＩｎｔｅｒｉｏｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ（ＩＧＰ）またはエンドツーエンドパスに及び得る複数ドメインにわたるネットワーク到達可能性を決定するために使用され得るＥｘｔｅｒｉｏｒ Ｇａｔｅｗａｙ Ｐｒｏｔｏｃｏｌ（ＥＧＰ）としてグループ化され得る距離−ベクトルルーティングプロトコルに基づくルータネットワークを伴うことができる。有利なことに、一部の例示の実施形態において、パッケージャネットワークのチャネル／カタログルーティングプロトコルは、ＯＳＰＦのリンク状態アドバタイズメントと類似するが、スタックの上位レイヤ（たとえば、アプリケーションレイヤ）において動作するよう適合された、アドバタイズメントを備えることができる。

少なくとも１つの実施形態において、ルーティングは、コンテンツ指向ネットワーキングとしても知られる、情報指向ネットワーキング（ＩＣＮ）アーキテクチャからのプロトコルに基づく。コンテンツ指向ネットワーキング（ＣＣＮ）は、直接にアドレス可能およびルーティング可能にすることによってコンテンツ（ＡＢＲメディア）を強調する。この実施形態において、ＣＣＮルーティングプロトコルは、制約を配布し、ＡＢＲメディアチャネルまたはメディアカタログルーティングデータベースを構築するために使用される。

図２は、パッケージャ２０２の例示のネットワーク２００およびＳＭＣ２０４の関連するネットワークを示す。この図において、２つのヘッドエンドパッケージャ２０２Ａ、２０２Ｂは、メディアをＭＢＲ ＡＴＳフォーマットで受信し、メディアをダウンストリームのパッケージャ２０２Ｃ、２０２Ｄに直接配布して、そこから複数のパスウェイを介して接続されている追加のパッケージャ２０２Ｅ、２０２Ｆ、２０２Ｇ、２０２Ｈ、２０２Ｊまで配布する。この配布されたパッケージングは、弾力性、低コスト、およびリアルタイムサービスを提供できる機能の増大をもたらす。このモデルにおいて、すべてのパッケージャは、パッケージャに関連付けられているアクション、たとえばパッケージング、トランスコーディング、レコーディング、トランスポーティング、ＪＩＴサービスなどのいずれかを実行すること、および同時に複数の異なるフォーマットを提供することができるが、顧客の需要およびネットワークのニーズに従って異なるパッケージングタスクを与えられてもよい。固有のパッケージャに割り振られているさらなるタスクは、固有のニーズの変化に応じて動的に変化する可能性がある。後段においてさらに詳細に説明されるように、一部のパッケージャは、永続的に割り振られてもよいが、その他のパッケージャは、時間制限される固有のパッケージングタスクを管理するためにインスタンス化されてもよい。

出願人は、示されているヘッドエンドパッケージャが、必ずしも全国データセンターにあるとは限らないが、ネットワーク周囲のさまざまな位置にあってもよく、開示される実施形態によりメディアが多様な位置で取り込まれて、残りのネットワークと共有されるようにすることに留意する。たとえば、ヘッドエンドパッケージャ２０２Ａ、２０２Ｂは、２つのサービスプロバイダの間の境界にあって、メディアが境界を越える両方向で共有されてもよい。パッケージャのいずれかがクライアントマニフェストおよび関連するメディアを配信元サーバ２０６に提供することができるが、すべてのパッケージャが提供する必要はないことは、さらに留意されるべきである。一部のパッケージャ、たとえば示されているパッケージャ２０２Ｃ、２０２Ｄ、２０２Ｅ、２０２Ｆは、最も効率的な方法でパッケージングの管理を補助するために中間パッケージャとしてサーブする。地域のパッケージャの数は、示されている地域よりも少ないかまたは多くてもよいことが理解されよう。配信元サーバ２０６は、固定ビットレートおよび適応ビットレートのＭＰＥＧ−ＴＳを取り込み、メディアストレージ、コンテンツ変換、およびストリーミングを提供する。配信元サーバ２０６は、処理中のストリームをＲＴＳＰおよびさまざまなＯＴＴフォーマットに変換して、複数のストリームフォーマットを格納する必要性を軽減する。

１つまたは複数のサービスマニフェストコントローラ２０４は、パッケージャ２０２と対話して、新しいメディアが取り込まれるときに関連するサービスマニフェストを作成する支援を行う。サービスマニフェストはまた、ネットワークの固有の地域のパッケージングを反映するようにさまざまな方法で変更されてもよく、ＳＭＣはこれらの変更に参加する。ＳＭＣ２０４は、ヘッドエンドパッケージャのみ、またはその地域のすべてのパッケージャに接続するように設定されてもよい。ＳＭＣは、パッケージャと共同設置されることが多いが、これは要件ではない。

次に図３を参照すると、本特許開示の実施形態による、メディアをクライアントデバイスに配信するために使用されるネットワーク要素の例が示されている。ネットワーク３００は、準備制御３２１、配信制御３２３、およびエッジ制御３２５の要素を含む。準備制御３２１は、メディアマネージャ３０２およびコンテンツコントローラ３０４を含む。メディアマネージャ３０２は、管理者としての役割を果たし、電子プログラミングデータおよび加入者情報を受信して、相互に関連のあるデバイス、ユーザ、およびコンテンツ権利に基づいてユーザアクセスを認証する。メディアマネージャ３０２はまた、コンテンツ暗号キーを含み、サービスマニフェストを管理する。コンテンツコントローラ３０４は、クライアント要求およびサービス仲介に基づいてコンテンツ配信をサポートするためにクライアントデバイスと対話するデジタル著作権管理（ＤＲＭ）ライセンスサーバである。コンテンツコントローラ３０４は、ストリームマニフェストをクライアントに提供する。配信制御３２３は、ドメインネームサーバ（ＤＮＳ）３０６、ＣＤＮ要求ルータ３０８、およびマニフェストコンテンツコントローラ３１０を含む。ＤＮＳ３０６は、人間が記憶しやすいドメインネームおよびホストネームを、対応する数字のインターネットプロトコル（ＩＰ）アドレスに変換または解決する。少なくとも１つの実施形態において、ＤＮＳ３０６を使用するのではなく、アーキテクチャはＨＴＴＰリダイレクトを使用して同様の機能を実行する。ＣＤＮ要求ルータ３０８は、ユーザ要求を受信し、ＵＥをクローズ状態の配信ノードへと導く。マニフェストコンテンツコントローラ３１０は、クライアントマニフェストを制御する。エッジ制御３２５は、ＪＩＴ Ｘ／Ｐ３１２、メディアクライアントプロキシ３１４、ユーザインターフェイス３１６、およびメディアクライアント３１８を含む。ＪＩＴ Ｘ／Ｐの「Ｘ／Ｐ」は、このノードが、固有の実施形態において必要とされる機能に応じて、ＪＩＴトランスコーダまたはＪＩＴパッケージャであってもよいことを指示するために使用される。ユーザインターフェイス３１６とメディアクライアント３１８は共に、セットトップボックスまたはモバイルデバイスのような、クライアントデバイスの一部である。メディアクライアントプロキシ３１４は、クライアント内またはネットワーク内にあってもよい。クライアントデバイスのメディアクライアント３１８およびメディアクライアントプロキシ３１４は、メディアプラットフォームでのクライアントデバイスの認証を管理し、コンテンツを取り出し、デジタル著作権管理の現地実施を提供する。少なくとも１つの実施形態において、メディアクライアント３１８およびメディアクライアントプロキシ３１４はまた、デバイス管理、エンタイトルメント実施、分析法、広告挿入、ＣＤＮ選択、および帯域幅管理を提供する。ユーザインターフェイス３１６は、加入者がメディアクライアントプロキシ３１４と対話できるようにする。ユーザインターフェイス３１６およびメディアクライアント３１８を含むであろう例示のＵＥは、たとえば、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔ Ｇｒｏｕｐ（ＭＰＥＧ）コーデック（ＭＰＥＧ、ＭＰＥＧ−２、ＭＰＥＧ−４など）、Ｈ．２６４コーデック、Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ ＣｏｄｉｎｇまたはＨＥＶＣ（Ｈ．２６５）コーデックなどを含む、ただしこれらに限定されない、知られているかまたはこれまで未知の規格または仕様に基づく１つまたは複数のコーダ−デコーダ（コーデック）機能と共に動作可能であってもよい。示されている実施形態において、メディアマネージャ３０２、コンテンツコントローラ３０４、およびＪＩＴ Ｘ／Ｐ３１２は共に、パッケージャ２００と見なされてもよく、必要に応じてＪＩＴトランスコーダまたはＪＩＴパッケージャのパフォーマンスを可能にする。

図３の矢印は、ネットワークエッジにおけるエンティティ間の例示の情報フローを指示する。この図の上部に見られるように、ユーザインターフェイス３１６は、メディアのサービス詳細を取得するためにコンテンツコントローラ３０４に転送される、チャネルまたはＶｏＤのビュー要求（ロール要求）３２０を、メディアクライアントプロキシ３１４に送信する。メディアクライアントプロキシ３１４はまた、ユーザまたはメディアクライアントに代わって情報をＪＩＴ Ｘ／Ｐ３１２に送信して、加入者要求へのリソースの割り当てを要求する。メディアクライアント３１８は、フロー要求３２８をメディアクライアントプロキシ３１４に、セグメント要求３３０をＪＩＴ Ｘ／Ｐ３１２に、マニフェスト要求３３２をマニフェストコンテンツコントローラ３１０に、ＤＮＳ要求３３４をＣＤＮ要求ルータ３０８に、およびマニフェスト要求３３６をコンテンツコントローラ３０４に送信することができる。この特定の実施形態において、メディアマネージャ３０２、コンテンツコントローラ３０４、およびＪＩＴ Ｘ／Ｐ３１２は、パッケージャ２００の機能を提供することができ、クライアントがチャネルマップまたはメディアカタログマップを要求するときにコンタクトの最初のポイントとなり得る。メディアマネージャ３０２およびコンテンツコントローラ３０４は、現在のマッピングを供給することができる。

任意のメディア項目がサーブされる位置を変更するためのネットワークの開示される能力を所与として、ネットワークは、チャネルマップおよびメディアカタログマップを動的に構築する必要がある。この操作は、チャネルまたはメディアカタログルックアップアプリケーションプログラムインターフェイス（ＡＰＩ）に基づいてクライアント側で実行される。少なくとも１つの実施形態において、クライアントは、チャネルマップまたはメディアカタログマップを受信するためにネットワーク内の任意のパッケージャにコンタクトすることができる。マップは、チャネルまたは異なる位置において提供され得るメディア要素の異なる表現を含むことができ、たとえば、チャネルのスペイン語バージョンは第１の位置からアクセス可能であってもよく、英語バージョンは第２の位置からアクセス可能である。その他の相違もまた、当然可能である。少なくとも１つの実施形態において、配信ベースのＣＢＲからの入力は、固有のクライアントのチャネルマップに到達するためにエンタイトルメントおよびビジネス論理と共に使用される。

開示される配信システムの長所の１つは、要素がクラウド内のマイクロサービスとして実施され得るので、状態情報を格納する必要がないことである。むしろ、この緩く結合されたアーキテクチャは、万一のときにインスタンス化されて、ネットワーク内の任意の位置においてリアルタイムの適応構造を提供するために使用されてもよい。開示されるマイクロサービスを必要に応じてインスタンス化することによって、メディアの配布および配信は共に最適化され得る。したがって、配信元サーバ２０６によって提供されるような、メディア発信サービスは、準備制御３２１、配信制御３２３、またはエッジ制御３２５のいずれかに常駐することができ、異なる製品にマップすることができ、仮想マシンのマイクロサービスとしてインスタンス化されてもよく、各位置でメディア発信の異なる態様を実行することができる。

本明細書において開示される相互接続およびエンドツーエンドのコンポーネントを提供することによって、アプリケーションは、サービスプロバイダの操作効率を高め、地域にわたり適応性のある動的なメディアおよびチャネル編成をもたらすために、メディアカタログまたはチャネルをサーブするためのスケーラブルでコスト効果の高い方法を提供する。開示される実施形態は、膨大数のロングテールＶＯＤメディアカタログおよびチャネルをサポートすることができる。チャネルおよびメディアカタログは、フォーマット、コンテンツ保護、リソース、サービス、および制約によってルーティングされてもよい。チャネル適応は、負荷、容量などのような、現地または地域の制限に基づいてもよい。ライブチャネルまたはバンドルは、ＪＩＴプロビジョニングを受信することができ、ＶＯＤメディアカタログは、パッケージされてサーブされるＪＩＴであってもよい。

開示される適応可能なマニフェスト制御のメディア配布および配信アーキテクチャは、新しい動的パッケージャネットワークモデルにおけるメディア準備および配信の簡略化を助けるために、制御プレーンメカニズムを提供する。このアーキテクチャは、コスト効果の高い、スケーラブルなメカニズム、適応チャネル編成および配信、適応ＶＯＤメディア／カタログ準備および配信を使用する。開示されるアーキテクチャは、メディアストリームのプロパティおよびメタデータを記述し、配信のためにメディアをパッケージする指令を与えるサービスマニフェストを規定する。このアーキテクチャは、以下のメカニズムを使用する。
− メディア準備のためのＣＢＲ、つまり、ルーティングに関する決定が、全国ヘッドエンドにおいてのみローカライズされるのではなくネットワークにわたり行われ得るように、パッケージングがサービスマニフェスト内で提供されるよう管理する制約
− チャネル編成のためのＣＢＲ、つまり、チャネルは、たとえば現地広告またはブラックアウトを提供するため、提供される制約内で現地レベルにおいて変更されてもよく、時間制限されたチャネルのインスタンス化を提供し、すべてが動的チャネル編成を使用する
− メディアおよびチャネル配信のためのＣＢＲ、つまりルーティング制約もまた提供され、最適化された配信をクライアントに提供するためにエッジノードによって必要とされるガイドラインを提示する

ＣＢＲを提供するため、サービスマニフェストは、規定されてメディアに関連付けられる。サービスマニフェストは、関連付けられているメディアのストリームプロパティおよびメタデータを記述し、また配信のためにメディアをパッケージする指令も与える。サービスマニフェストは、ライブおよびタイムシフトの両方のライブチャネルメディア、およびＶｏＤメディア、およびキャッチアップメディアを表現するために使用されてもよい。サービスマニフェストは、メディア記述ドキュメントであり、クライアントではなくパッケージャによって消費され、配布を管理するために展開された、拡張ＤＡＳＨ Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｏｃｕｍｅｎｔ（ＭＰＤ）として提供される。サービスマニフェストは、クライアントマニフェストが作成され得る情報を含むが、ダウンストリームパッケージャの指令も含み、パッケージャ関連の属性を記述するように、適応セットのＭＢＲ ＡＴＳストリーム、つまりＡＴＳストリームに関連する静的メタデータおよび捕捉情報、およびパッケージされたＡＢＲ適応セットを記述する。マニフェストまたはサービスマニフェストの選択された部分は、好ましくは保護される、つまりサービスマニフェストに暗号化バイナリデータを使用する。ストリームがユーザにどのように再生されるかを記述するクライアントマニフェストとは異なり、サービスマニフェストは、ネットワーク内のリソースの割り当てのためのガイダンスを提供する。

図４を参照すると、本開示の１つの実施形態によるサービスマニフェストの例が示されている。前述のように、サービスマニフェスト４００は、ＭＰＤであり、期間４０２、適応セット４０４、表現４０６、セグメント４０８、指令４１０、およびパッケージャ４１２を含む。期間４０２は、開始時間および継続時間と共にコンテンツの一部を記述し、複数の期間は、たとえばプログラムコンテンツからシーンまたはチャプター、もしくは広告を分離するために使用されてもよい。適応セット４０４は、メディアストリームまたはメディアストリームのセットを含む。最も単純な事例において、期間４０２は、コンテンツのすべてのオーディオおよびビデオを含む１つの適応セット４０４を有することができる。あるいは、各ストリームは、異なる適応セットに分割されてもよい。一般的な事例は、１つのビデオ適応セットと、たとえばサポートされる言語ごとに１つの、複数のオーディオ適応セットを有することである。適応セットはまた、サブタイトルまたは任意のメタデータを含むこともできる。これらの適応セットは通常、ユーザによって選択されるか、または言語および／またはアクセシビリティニーズのユーザプリファレンスを使用してＷｅｂブラウザもしくはＴＶのようなユーザエージェントによって選択される。

表現４０６は、適応セットが、さまざまな方法でエンコードされた同じコンテンツを含むことができるようにする。多くの場合、表現は、複数の画面サイズおよび帯域幅で提供されて、クライアントが、バッファに入れるのを待つかまたは不要なピクセルで帯域幅を浪費することなく再生することができる最高品質のコンテンツを要求できるようにする。表現はまた、異なるコーデックでエンコードされてもよく、異なるサポートコーデックを備えるクライアントのサポート、またはレガシークライアントをサポートしつつ新しいクライアントにさらに高品質の表現を提供することが可能になる。複数のコーデックはまた、バッテリ式のデバイスで有用であってもよく、たとえデバイスが新しいコーデックのソフトウェアサポートを有する場合であっても、ハードウェアサポートおよび少ないバッテリ使用量を有する旧式コーデックを選択してもよい。表現は通常、自動的に選択されるが、一部のプレイヤーは、ユーザが選択をオーバーライドできるようにする。ユーザは、たとえば、特定のビデオで帯域幅を浪費したくない場合、またはビデオを停止させて、高品質と引き換えにバッファに入れることをいとわない場合、各自の表現の選択を行うよう選択してもよい。

メディアセグメントは、ＤＡＳＨクライアントが再生する実際のメディアファイルである。セグメント４０８は、単一セグメント表現、セグメントのリスト（ＳｅｇｍｅｎｔＬｉｓｔ）またはテンプレート（ＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ）に対してＢａｓｅＵＲＬを使用してメディアセグメント位置を提供することができる。セグメントは、別個のファイルであるか、ライブストリーミングに共通であってもよいか、またはセグメントは、静的または「オンデマンド」メディアに共通である単一ファイル内のバイト範囲であってもよい。サービスマニフェスト４００の上記の部分は、何がクライアントマニフェストで生成されているかを説明し、したがってクライアントマニフェストの類似する要素に対応する。

サービスマニフェストの新しい要素は、指令４１０およびパッケージャ４１２を含む。指令は、ダウンストリームパッケージャによって使用される情報を搬送し、メディアカタログまたはチャネルのルーティング、適応トランスコーディングおよびパッケージング、アップロードおよびＣＤＮ配信、コンテンツ保護、エンタイトルメント、広告挿入、記録およびストレージに使用されてもよい。少なくとも１つの実施形態において、指令４１０は、以下の事項を含むことができる。
− メディア／チャネルに関連する一般的情報
− ストリームをパッケージする方法に関する一般的ガイダンス
− ストリームをパッケージする方法に関するオプションまたは必須の指図
− ストリームを転送またはルーティングする方法に関するガイダンス
− ストリームに関するオプションまたは必須の制約

加えて、指令４１０は、ＣＢＲ指令、ＣＤＮ指令、トランスコード指令、パッケージ指令、アップロード指令、コンテンツ保護指令、コンテンツストレージ指令、広告挿入指令、およびタイムシフト指令のいずれかであってもよい。リンクレベル制約は、たとえば、所与のネットワークのリンクの使用に対する制約を指定することができる。１つの例において、ユニキャスト接続の帯域幅制約は、パスを設定するリンクが特定量の使用可能な空き帯域幅を有していなければならないことを要求することができる。パス制約は、単一パスのエンドツーエンドのＱｏＳ要件を指定することができる。ツリー制約は、全マルチキャストツリーの全般的なＱｏＳ要件を指定することができる。１つの例において、マルチキャスト接続の遅延制約は、送信者からツリー内の任意の受信者までの最長のエンドツーエンド遅延が、上限を超えてはならないことを要求することができる。トランスポート制御に関連する指令は、ラストマイルに使用されるトランスポートのタイプに依存するパッケージングの差を指示することができる。

パッケージャ４１２は、アップストリームおよび／またはダウンストリームパッケージャ設定に関する情報、ならびにパッケージャに関するその他の望ましい情報を提供することができる。少なくとも１つの実施形態において、パッケージャ属性は、位置（たとえば、地域、データセンター名／など）、アドレス（たとえば、パッケージャにアクセスするためのＵＲＬ）、タイプ（つまり、パッケージャ、トランスコーダ、レコーダ、ＪＩＴなど）、能力、識別（一意のパッケージャＩＤ）、および所有者（たとえば、プロバイダ、ＣＤＮ、コンテンツプロバイダ）を含む。少なくとも１つの実施形態において、パッケージャがサービスマニフェスト４００に変更を行う場合、変更、および変更を行うパッケージャの識別は、パッケージャフィールド４１２に文書化される。指令４１０およびパッケージャ４１２は、サービスマニフェスト４００の任意のレベルに適用されてもよく、たとえば指令４１０Ａは表現４０６Ａに適用されるが、表現４０６Ｂには適用されないか、または全ＭＰＤ、たとえば指令４１０Ｄ、４１０Ｅ、およびパッケージャ４１２Ａ、４１２Ｂに適用してもよい。指令４１０およびパッケージャ４１２の新しいフィールドに加えて、サービスマニフェスト４００の個々の要素が保護されてもよい。少なくとも１つの実施形態において、サービスマニフェスト４００の一部、たとえば必須である指令４１０Ｄは、保護のために署名されている。少なくとも１つの実施形態において、署名は、サービスマニフェストの保護されているデータにＳＨＡ２５６を使用するＨＭＡＣの結果である。少なくとも１つの実施形態において、署名開始要素と署名終了要素との間に含まれるすべてのデータは、保護されているデータとみなされる。少なくとも１つの実施形態において、署名は、パッケージャが必須の指令４１０を編集することを禁じるために使用される。本明細書における教示による拡張ＭＰＤがその他のプロトコルに基づいて提供されてもよいことを理解されたい。

サービスマニフェスト４００は、ＳＭＣ２０４ＡのようなＳＭＣによって生成されてもよい。少なくとも１つの実施形態において、ヘッドエンドパッケージャ２０４Ａがメディアカタログまたはチャネルブロックをアップロードすると、ＳＭＣ２０４は、カタログデータおよびチャネルまたはメディアの取り込み設定に基づいてメディアの初期サービスマニフェストを生成する。少なくとも１つの実施形態において、ＳＭＣ２０４は、ヘッドエンドパッケージャ２０２Ａ、２０２Ｂだけではなくネットワーク内のパッケージャ２０２のすべてにサービスマニフェストを生成するために使用されてもよい。ＳＭＣ２０４はまた、メディアカタログ配信およびチャネル編成のためのＣＢＲを支援する。ＳＭＣは、集中化されるのではなく、ネットワークにわたり分散される。全国データセンター１０２および地域データセンター１０４、１０６の各々は、１つまたは複数のＳＭＣを有することができる。少なくとも１つの実施形態において、ＳＭＣ２０４は、別個のエンティティであり、少なくとも１つの実施形態において、ＳＭＣ２０４は、パッケージャと共存する、たとえばＳＭＣ１０２Ａはパッケージャ１０４Ａと共存する。

少なくとも１つの実施形態において、ＳＭＣ２０４Ａは、関連するパッケージャ、たとえばパッケージャ２０２Ａと共に、サービスマニフェスト、取り込み設定、ルーティングテーブル、およびルーティングを決定するための追加の制約、ただしこれが使用され得る唯一のルーティングプロトコルではないが、これらを使用して、メディアカタログおよびチャネル編成のＣＢＲを実行する。制約は、サービスマニフェストで搬送される指令において提供されてもよく、追加の制約は、パッケージャリソース、たとえば負荷、容量、ビジネス論理などを含むことができる。ネットワークにわたるニーズの変化に応じて、チャネルおよびメディアカタログのパッケージャへの割り当ては、時間の経過に伴って変化する可能性がある。したがって、メディアカタログおよびチャネルの動的マッピングは、加入者要求に応じて、たとえば加入者が所与のデバイスをオンにするときに、実行される。クライアントデバイスは、任意のネットワークノードに現在のチャネルまたはメディアカタログマップを要求することができる。少なくとも１つの実施形態において、クライアントデバイスは、チャネルおよびメディアカタログの現在のマッピングを要求するために、最も近いネットワークノードまで進む。パッケージャは、現在のメディアカタログおよびチャネルの位置を記述するチャネルデータベースおよびメディアカタログデータベースにアクセスし、次いでメディアカタログまたはチャネルをクライアントデバイスに提供する最適なパッケージャを決定するためにＣＢＲを適用する。この最適なパッケージャの位置は、クライアントデバイスが選択されたパッケージャにコンタクトして要求されたメディアを受信することができるように、クライアントデバイスに提供される。メディア配信では、配布に使用されるデータベースおよびルーティングテーブルとは異なり、メディア配信に使用される追加の制約を含む、チャネルデータベース、メディアカタログデータベース、およびルーティングテーブルを使用する。つまり、配布に使用されるルーティングテーブルは、ストレージおよびワークロードのような使用可能なリソースに関する情報を必要とするが、配信に使用されるルーティングテーブルは、帯域幅の可用性、コンテンツ、ＪＩＴ処理リソース、およびユーザに関する位置のような制約を考慮する。

チャネルデータベースおよびメディアカタログデータベースは、パブリッシュポイント、チャネル状態、パッケージャリソース状態、ＣＤＮ配信元などのような、それぞれのチャネルまたはカタログ配布分析法（ＣＤＡ）およびその他の要素を含む。分析法は、ＡＢＲメディアの配布および配信に影響を及ぼし得る任意の数の要因に関する情報を含むことができる。情報は、チャネルおよびメディアが現在配布される場所のような要素を含むことができるが、またチャネルおよびメディアがどのように消費されるかを記述する要素、たとえばチャネルまたはメディア要素に行われたルックアップの数、チャネル／メディアを消費するクライアントの数、たとえばセルラー、ＷｉＦｉ、有線配信を介してなどメディアがどのように消費されているか、使用されるビットレートなども含むことができる。この情報は、注意または変更を必要とするネットワークの領域をネットワークが認識したままでいるのを助けるために使用されてもよい。たとえば、チャネルが頻繁に使用されている場合、現在のパッケージャは、チャネルを提供するためにその限界に到達することもあり得る。ネットワークは、たとえば、より多くの機能を備える別のパッケージャにチャネルをシフトすること、現在のパッケージャによって搬送されている負荷を分散させるために追加のパッケージャを追加すること、またはパッケージャにさらに多くのリソースを追加することを決定することができる。

チャネルおよびメディアカタログを配布するためのルーティングは、アプリケーションレベルで実行され、チャネル／メディアカタログデータベースを使用する。ルーティングプロトコルは、その他のルーティングプロトコルに使用されるルーティングプロトコルと何らかの類似性を有するが、チャネル／メディアカタログデータベース内のルックアップは、ネットワーク内のルータがするように、単に宛先にアクセスするのではなく、リソース可用性、たとえば帯域幅、ストレージ、コンテンツおよび処理リソース、ならびに現地最適化の可用性のような要因にも注目する。少なくとも１つの実施形態において、メディアカタログおよびチャネルデータベースはまた、固有の変更の実現可能性を決定するためにも使用される。主要なマッピング変更は、変更がより頻繁に行われたとすれば可能であったソリューションよりも最適なソリューションを求めてさらに複雑な計算を実行することが可能となるように、たとえば１日１回行われることが構想される。

最適化は、本明細書においてピアリングと称される、ＳＭＣまたはパッケージャの間の情報の交換によって増大される。このピアリングは、ＣＤＡを交換することができ、これは次いでチャネルおよびメディアカタログデータベースに格納される。データベースに適用されたＣＢＲは、結果として配布のための適切なルーティングテーブルをもたらす。チャネルルーティングテーブルは、チャネルまたはチャネルグループを１つまたは複数のパッケージャにルーティングするために使用され、メディアカタログルーティングテーブルは、メディアカタログを１つまたは複数のパッケージャにルーティングするために使用される。メディアは、カタログに制約され、カタログは特定の制約内でパッケージャのグループによりサービスを受ける。パッケージャのルックアップ不成功は、要求を満たすための１つまたは複数のパッケージャの動的編成をもたらすことがある。

サービスマニフェストは、メディアおよびチャネルストリームと共に、ヘッドエンドパッケージャからダウンストリームまたはエッジパッケージャへとネットワークを行き来する。任意のパッケージャは、１つまたは複数の入力サービスマニフェストを取り込むことができ、たとえばさまざまなルートに沿ってエリア固有のコンテンツを最良に提供するために、１つまたは複数のサービスマニフェストを生成することができる。このようにして、サービスマニフェストは、サービスマニフェストがネットワークを行き来するのに応じて更新される。可能な変更の例は、以下の事項を含む。
− たとえば高品位を追加または削除するために、ビットレートを追加または低下させること
− ＤＡＳＨを追加してＳＳを低下させるような、フォーマットを追加または低下させること
− たとえば固有のビジネスルールを満たすために、ＣＤＮを追加または低下させること
− たとえばスペイン語を追加するなど、オーディオストリームを追加または低下させること

ＡＢＲメディア配布のいくつかのモデルは、プッシュモデル、プルモデル、およびプッシュとプルが共に使用されるハイブリッドモデル、およびピアツーピアモデルを含む、ＣＢＲと共に使用されてもよい。これらのモデルの各々において、ヘッドエンドパッケージャであることもそうではないこともあるパッケージャは、トランスコーダからのストリームマニフェストおよびＳＭＣからの初期サービスマニフェストに基づいてチャネルまたはメディアカタログのサービスマニフェストを生成する。サービスマニフェストはまた、プロバイダからの取り込み設定を使用して生成されてもよい。パッケージャは、ストリームマニフェストおよび初期サービスマニフェストを使用して、自身のメディア取り込み設定を生成する。パッケージャによって生成されるサービスマニフェストは、出力ストリームプロパティ、および他のパッケージャによって使用されるチャネルまたはメディアカタログに関連付けられている指令を記述する。サービスマニフェストは、自身のメディア取り込み設定を生成するためにダウンストリームパッケージャに使用され、それによりダウンストリームパッケージャは、更新されたサービスマニフェストを生成する。各パッケージャによって出力されるサービスマニフェストは、現地設定およびビジネスポリシーに基づいて使用可能なストリーム、その他のリソース、および更新された指令を反映する。

図５Ａに示されるプッシュモデルにおいて、ＭＢＲ ＡＴＳトランスコーダ５０２は、ＭＢＲ ＡＴＳストリームおよびストリームマニフェストをヘッドエンドパッケージャ５０４に送信する。サービスマニフェストは、最初に、ＳＭＣ５１２と共に、ヘッドエンドパッケージャ５０４によってパブリッシュされ、パッケージャ５０６、５０８のようなダウンストリームパッケージャによって使用される。ヘッドエンドパッケージャ５０４は、サービスマニフェストを使用して、ヘッドエンドパッケージャに関連付けられている配信元サーバ５１０にサーブする。サービスマニフェストは、追加のパッケージャ（具体的に図示せず）が使用される場合、更新されてパッケージャ５０６、５０８によって再パブリッシュされ、それぞれの配信元サーバ５１０にサーブするために使用される。チャネルルーティングテーブルは、チャネルをルーティングするために使用される。プッシュモデルにおいて、ヘッドエンドパッケージャ５０４は、ダウンストリームパッケージャ５０６、５０８の設定のような、サービスマニフェストおよびその他の情報を使用して、ネットワーク内のチャネルをどのように配布するかを決定する。その他の情報は、チャネル、ＣＤＮ、および記録設定、コンテンツ保護、サービス設定、チャネルおよび／またはパッケージャ指令設定、現地ビジネス論理などを含むことができる。ヘッドエンドパッケージャ５０４は、任意のタイプのパッケージャであってもよく、そこに関連付けられている任意の数のダウンストリームパッケージャを有することができる。パッケージャ５０６、５０８のようなエッジパッケージャはサービスマニフェストおよび現地設定を使用してクライアントマニフェストを生成し、入力ストリームマニフェストを有することができ、必要な変換機能を実行する。パッケージャ５０６、５０８はまた、固有の必須指令を使用することができ、クライアントが使用する正しいパッケージャを見出すためにチャネルまたはカタログルーティングテーブルを使用してチャネルおよびメディアカタログ配信のパッケージャルックアップを実行し、ＨＬＳ、ＳＳ、ＤＳＨのような出力を提供する。

図５Ｂに示されるプルモデルにおいて、サービスマニフェストおよびメディアストリームは、ヘッドエンドパッケージャ５２０のようなアップストリームパッケージャから、ＪＩＴパッケージャ５２２のような、エッジパッケージャからプルされるときダウンストリームへと行き来する。このモデルにおいて、エッジパッケージャ５２２、５２４は、現地条件に基づいて、およびチャネルまたはカタログルーティングテーブルを使用してサービスマニフェスト要求を開始する。プルモデルにおけるパッケージャの指令は、必須ではない。エッジパッケージャ５２２、５２４は、たとえばＶｏＤのチャネルおよびＪＩＴの事前プロビジョニングを実行するなど、チャネルおよびメディアカタログプロビジョニングのためのＪＩＴと事前適応の両方を使用して、２つのモードにおいて動作することができる。ハイブリッドモデルは、プッシュおよびプルモデルを結合することができる。ハイブリッドモデルを使用する少なくとも１つの実施形態において、主要なチャネルグループおよび好評なメディアカタログは、地域データセンターまたはその先にプッシュされてもよく、一方時折の使用を受けるだけのチャネルおよびメディアカタログは、要求された場合に限り遠距離パッケージャからプルされる。

ピアツーピアモデルにおいて、複数のヘッドエンドパッケージャは、エッジパッケージャがどこでメディア／チャネルを取得すべきか分からないように、特定のメディアカタログまたはチャネルバンドルを取り込むことができる。エッジパッケージャは、ネイバーとの望ましいメディアの拡張ルックアッププロセスを実行する。望ましいメディアを有するネイバーがない場合、要求は、メディアを含むヘッドエンドパッケージャまで階層を上に進むことができる。しかし、この拡張ルックアッププロセスに沿って、メディア／チャネルを有する隣接パッケージャは、チャネルまたはメディアカタログをエッジパッケージャまで下方に送信することができる。

各モデルにおいて、チャネルおよびメディアカタログマッピングは、加入者要求およびビジネス論理に基づいて、リアルタイムで実行される。あらゆる地域は、異なるチャネルガイドマッピングを有することができ、たとえば、一部のメディアが全国データセンターからサーブされ、その他のメディアが地域センターからサーブされる。チャネルおよびメディアカタログは、要望どおり、パッケージャの異なるセットからサーブされてもよい。本明細書において開示されるアーキテクチャおよび配布、特にパッケージャネットワークと、パッケージャネットワークによって搬送されるチャネルおよびメディアカタログの両方のオンデマンドリアルタイムインフラストラクチャおよび動的編成を所与として、チャネルからパッケージャへのマッピングは、以前見られたものよりもはるかに動的である。パッケージャノードは、追加されるかまたは削除されてもよく、ＣＢＲが最適な位置および／またはノードの識別を補助する。ＣＢＲは、パッケージャが、変化する要求を満たすように再設定される必要性を指示することができ、たとえばチャネルルーティングの追加の制約がパッケージャに課されてもよい。ルーティングテーブルのパッケージャルックアップの不成功は、チャネルおよび／またはメディアカタログ編成をトリガーすることができ、結果として新しいパッケージャの編成をもたらす。したがって、エッジパッケージャは、チャネルまたはＶｏＤをユーザにサーブするパッケージャを決定するために、ユーザ要求に応じて動的ルックアップを実行する。

次に図６Ａ〜図６Ｎを参照すると、これらの図面は、ネットワークでＡＢＲメディアを配布するための方法６００の流れ図を開示する。方法６００Ａにおいて、第１のネットワークノードは、第１のＡＢＲメディア要素を取り込む６０５。第１のネットワークノードは、第２のノードにおいて最初に取り込まれた第２のＡＢＲメディア要素をさらに受信する６１０。第１のネットワークノードは、第１の複数のネットワークノードへの第１および第２のＡＢＲメディア要素の配布を開始する６１５。その他のアクションは、必要に応じて実行されてもよく、特に明記のない限り任意の特定の順序で実行されなくてもよい。方法６００Ｂにおいて、第１のＡＢＲメディア要素は、全国データセンターで最初に取り込まれ６２０、第２のＡＢＲメディア要素は、地域データセンターで最初に取り込まれる。方法６００Ｃにおいて、第１のＡＢＲメディア要素は、第１のエンティティに所有されるドメインで最初に取り込まれ６２５、第２のＡＢＲメディア要素は、第２のエンティティに所有されるドメインで最初に取り込まれる。方法６００Ｄにおいて、ネットワークは、ＡＢＲメディア要素が取り出され得る位置を備える配信データベースを保持する６３０。

方法６００Ｅにおいて、ノードは、ＡＢＲメディアの第１の要素の要求が、クライアントデバイスから受信されたかどうかを決定する６４０。要求が受信されていない場合、ノードは、その他の操作を続行し、要求を待つ。要求が受信されている場合、ノードは、ＡＢＲメディアの第１の要素を取得する最善のパッケージャを決定し６４５、クライアントデバイスをＡＢＲメディアの第１の要素を取り出すべき最善のパッケージャに方向付ける６５０。少なくとも一部の実施形態において、方法６００Ｆは、アクション６４５の一部として実行され、ＡＢＲメディアの第１の要素の配信の制約を満たす最善のパッケージャが使用可能であるかどうかを決定する６５５。最善のパッケージャが使用可能である場合、アクション６５０が実行され、それ以外の場合、ネットワークは、制約を満たすことができる新しいパッケージャのインスタンス化を開始し６６０、クライアントをＡＢＲメディアの第１の要素を取り出すべき新しいパッケージャに方向付ける。

方法６００Ｇにおいて示される少なくとも１つの実施形態において、第１のノードは、ＡＢＲメディアの第１の要素を配布ルートに沿って第１の複数のノードにプッシュする６６５。方法６００Ｈにおいて示される少なくとも１つの実施形態において、第１の複数のネットワークノード内のノードは、ＡＢＲメディアの第１の要素の配布を、配布ルートに沿って第１のノードからオンデマンドでプルする６７０。方法６００Ｊにおいて示される少なくとも１つの実施形態において、第１のノードは、ＡＢＲメディアの第１の要素を、第１の配布ルートに沿って第１の複数のノードにプッシュし６７５、第１の複数のネットワークノード内のノードは、ＡＢＲメディアの第２の要素の配布を、第２の配布ルートに沿って第１のノードからオンデマンドでプルする６８０。

方法６００Ｋにおいて、ノードは、クライアントデバイスが権利を有するＡＢＲメディアに関連付けられているクライアントエンタイトルメント、ビジネス論理、および配信の制約に基づいて、クライアントデバイスのチャネルマップを動的に構築する６８５。方法６００Ｍにおいて、ネットワークノードは、プロバイダのさまざまな地域の１つとさまざまなプロバイダとの間の境界にわたりサマリーサービスマニフェストを交換する６９０。方法６００Ｎにおいて、システムは、第１のＡＢＲメディア要素が最初に取り込まれるとき、第１のＡＢＲメディア要素に関連付けられているサービスマニフェストを作成し、サービスマニフェストは複数の指令を備える。

図７Ａ〜図７Ｑは、ネットワークにおいてＡＢＲメディアを配布するための方法の流れ図を開示する。方法７００Ａにおいて、ネットワークは、ルーティングデータベースおよびＡＢＲメディア要素に関連付けられている制約に基づいてＡＢＲメディア要素にパッケージング機能を実行すべき複数のパッケージャのうちの最善のパッケージャを決定し７０５、最善のパッケージャへのＡＢＲメディア要素のルーティングを開始する７１０。少なくとも１つの実施形態において、方法７００Ｂは、アクション７０５の一部として実行され、パッケージャが制約を満たすルーティングデータベース内で見出され得るかどうかを決定する７１５。パッケージャが見出される場合、方法は要素７１０に移動し、それ以外の場合、方法は、要求にサービスを提供するために新しいパッケージャのインスタンス化を開始し７２０、新しいパッケージャへのＡＢＲメディア要素のルーティングを初期化する。新しいパッケージャは、安全なクラウドインフラストラクチャでインスタンス化される。新しいパッケージャがインスタンス化される場合、方法５００Ｃは、新しいパッケージャを認証する７２５ために実行される。

残りのアクションは、必要に応じて実行されてもよく、特に明記のない限り任意の特定の順序で実行されなくてもよい。方法７００Ｄは、必要に応じて実行されてもよく、帯域幅の可用性、ストレージの可用性、現在サーブされるコンテンツ、およびそれぞれのパッケージャにおける処理リソースのうちの少なくとも１つをルーティングデータベースに読み込む７３０。方法７００Ｅは、方法７００Ａのアクションに先立って実行され、サービスマニフェスト内の制約を指令として受信する７３５。方法７００Ｆにおいて示される少なくとも１つの実施形態において、システムは、満たされるべき指令を要求する７４０。方法７００Ｇにおいて示される少なくとも１つの実施形態において、システムは、ストリームへの制約、チャネルに関連する一般情報、および指令のストリームをルーティングする方法に関するガイダンスのうちの少なくとも１つを提供する７４５。方法７００Ｈにおいて示される少なくとも１つの実施形態において、システムは、メディアカタログルーティング、チャネルルーティング、適応トランスコーディング、適応パッケージング、アップロードおよびＣＤＮ配信、コンテンツ保護、エンタイトルメントおよび広告挿入、記録およびストレージのうちの少なくとも１つに関する指令の制約を提供する７５０。方法７００Ｊにおいて示される少なくとも１つの実施形態において、所与のパッケージャは、サービスマニフェストを変更し７５５、サービスマニフェストのパッケージャ要素における変更を文書化する７６０。方法７００Ｋにおいて示される少なくとも１つの実施形態において、サービスマニフェストの少なくとも一部は署名される７７０。

方法７００Ｍにおいて示される少なくとも１つの実施形態において、ネットワークは、ルーティングプロトコルを使用してリアルタイムでチャネル分析法を配布する７７５。方法７００Ｎにおいて示される少なくとも１つの実施形態において、ネットワークは、チャネル分析法の更新を受信し７８０、ＡＢＲメディア要素のルーティングを更新する７８５。方法７００Ｐにおいて示される少なくとも１つの実施形態において、ネットワークノードは、ＡＢＲメディア要素を最初に取り込み７９０、ＡＢＲメディア要素のサービスマニフェストを作成する７９５。

開示されるシステム、デバイス、および方法は、管理対象ネットサークにおいてデジタルメディアをユーザに提示する多くの革新的な方法を容易にすることができる。この１つの例は、「フォローミー」メディアと呼ばれ得るものであり、たとえば別の州または国に旅行している加入者が別の位置で各自の通常のプログラムを視聴することができる。このアプリケーションにおいて、たとえばテキサスに住む加入者はフロリダを旅行しているが、通常自宅で視聴しているメディアおよびチャネルに同じ高品質体験でアクセスしたいと考える。加入者は、新しい位置においてネットワークに識別され、そのエンタイトルメントおよびメディアプリファレンスが取り出される。加入者が訪れているのが新しい地域であるため、フロリダ地域のチャネルブロックは、テキサス地域の場合とは多少異なるラインアップを有する。加入者の付近のパッケージャは、たとえばテキサスにおいて、望ましいチャネルブロックを供給することができるパッケージャを決定するためにルックアップを実行することができ、加入者のクライアントデバイスを遠くのパッケージャに方向付ける。次いで、加入者は、通常現地広告が挿入された、慣れ親しんだショーにアクセスすることができる。多数のテキサスの人が現在フロリダを訪れており、同じチャネルブロックを要求している場合、ネットワークは、２つの地域の間のトラフィック量が過剰であると決定することができる。次いで、ネットワークは、チャネルブロックの１つのコピーを受信して、このチャネルブロックを要求するフロリダ内のすべての加入者にサーブするフロリダ地域の新しいパッケージャをインスタンス化するよう選択することができる。加入者は、新しいフロリダのパッケージャがインスタンス化されるまで、テキサスのパッケージャに引き続きアクセスすることができ、次いで、次回ＵＥが次のＡＢＲセグメントを要求すると、ＵＥは新しいパッケージャに方向付けられる。

本開示のさまざまな実施形態の上記の説明において、本明細書において使用される用語が、特定の実施形態を説明することのみを目的としており、本発明を限定することは意図されていないことを理解されたい。他に特に規定のない限り、本明細書において使用されるすべての用語（技術および科学用語を含む）は、本発明が属する技術分野の当業者によって一般に理解される意味と同じ意味を有する。さらに、一般に使用される辞書に規定されているような用語が、本明細書および関連技術のコンテキストにおけるそれらの意味と一致する意味を有するものと解釈されるべきであり、理想的または過度に形式的な意味で本明細書において明示的にそのように規定されるものと解釈されないことを理解されたい。

さらに、上記で述べたように、本明細書において開示される例示のネットワークアーキテクチャの少なくとも一部は、上記で示されるように仮想化され、設定可能な仮想リソースの共有プールを備えるクラウドコンピューティング環境において設計されてもよい。たとえば、ソフトウェアのさまざまな部分、たとえばコンテンツエンコードスキーム、ＤＲＭ、セグメント化メカニズム、メディア資産パッケージデータベースなど、ならびにビデオサービスプロバイダネットワークのプラットフォームおよびインフラストラクチャは、サービス指向アーキテクチャ、たとえばサービスとしてのソフトウェア（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）（ＳａａＳ）、サービスとしてのプラットフォーム（Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）（ＰａａＳ）、およびサービスとしてのインフラストラクチャ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）（ＩａａＳ）において本発明の例示の実施形態のさまざまな特徴を提供する複数のエンティティにより実施されてもよく、仮想化環境の１つまたは複数のレイヤは商用オフザシェルフ（ＣＯＴＳ）ハードウェア上でインスタンス化されてもよい。当業者はまた、そのようなクラウドコンピューティング環境が、プライベートクラウド、パブリッククラウド、ハイブリッドクラウド、コミュニティクラウド、分散クラウド、マルチクラウド、インタークラウド（たとえば「クラウドのクラウド」）などのうちの１つまたは複数を備えることができることを理解するであろう。

少なくとも一部の例示の実施形態は、コンピュータ実施の方法、装置（システムおよび／またはデバイス）、および／またはコンピュータプログラム製品のブロック図および／または流れ図の説明を参照して本明細書において説明される。ブロック図のブロックおよび／または流れ図の説明、およびブロック図のブロックおよび／または流れ図の説明の組み合わせが、１つまたは複数のコンピュータ回路により実行されるコンピュータプログラム命令によって実施され得ることが理解されよう。そのようなコンピュータプログラム命令は、マシンを生成するために、汎用コンピュータ回路、特定用途向けコンピュータ回路、および／またはその他のプログラマブルデータ処理回路のプロセッサ回路に提供されてもよく、コンピュータのプロセッサおよび／またはその他のプログラマブルデータ処理装置を介して実行する命令が、ブロック図および／または流れ図ブロックで指定された機能／動作を実施するために、そのような回路内のトランジスタ、メモリ位置に格納されている値、およびその他のハードウェアコンポーネントを変換および制御し、それによりブロック図および／または流れ図ブロックで指定された機能／動作を実施するための手段（機能）および／または構造を作成するようになっている。加えて、コンピュータプログラム命令はまた、特定の方式で機能するようにコンピュータまたはその他のプログラマブルデータ処理装置を指図することができる有形のコンピュータ可読メモリに格納されてもよく、コンピュータ可読媒体に格納された命令が、ブロック図および／または流れ図ブロックにおいて指定される機能／動作を実施する命令を含む製造品を生成するようになっている。添付の資料における少なくとも１つまたは複数の図面は、１つまたは複数のプロセッサ、インターフェイス、および上記の１つまたは複数の実施形態を実行または達成するように設定されたプログラム命令を備える適切なメモリを含むさまざまな構造的コンポーネントおよびネットワークノードまたは要素のブロックを示す。同様に、添付の資料における少なくとも１つまたは複数の図面は、１つまたは複数のプロセッサ、インターフェイス、および上記の１つまたは複数の実施形態を実行または達成するように設定されたプログラム命令を備える適切なメモリを含むさまざまな構造的コンポーネントおよび加入者終端局またはデバイスのブロックを示す。

上記で言及したように、有形の、非一時的コンピュータ可読媒体は、電子、磁気、光、電磁、または半導体データストレージシステム装置、またはデバイスを含むことができる。コンピュータ可読媒体のさらに具体的な例は、ポータブルコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）回路、読取り専用メモリ（ＲＯＭ）回路、消去可能プログラマブル読取り専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）回路、ポータブルコンパクトディスク読取り専用メモリ（ＣＤ−ＲＯＭ）、およびポータブルデジタルビデオディスク読取り専用メモリ（ＤＶＤ／ブルーレイ）を含む。コンピュータプログラム命令はまた、コンピュータおよび／またはその他のプログラマブルデータ処理装置にロードされるかまたはダウンロードされて、コンピュータ実施のプロセスを生成するためにコンピュータおよび／またはその他のプログラマブル装置上で一連の操作ステップが実行されるようにすることができる。したがって、本発明の実施形態は、ハードウェア、および／または集合的に「回路」、「モジュール」、もしくはその変種と称され得るプロセッサまたはコントローラ上で実行するソフトウェア（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）において具現されてもよい。

さらに、例示の処理ユニットは、例として、汎用プロセッサ、専用プロセッサ、標準的プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意のタイプの集積回路（ＩＣ）、および／または状態機械を含むことができる。理解され得るように、例示のプロセッサユニットは、特定の実施形態において分散処理を採用することができる。

さらに、少なくとも一部の追加または代替の実施態様において、ブロックで説明されている機能／動作は、流れ図に示される順序通りに生じていない場合もある。たとえば、連続して示される２つのブロックが、実際にはほぼ同時に実行されることもあるか、または場合によっては、関与する機能／動作に応じて逆の順序で実行されることもある。さらに、流れ図および／またはブロック図の所与のブロックの機能は、複数のブロックに分離されてもよい、および／または流れ図および／またはブロック図の２つ以上のブロックの機能は、少なくとも部分的に統合されてもよい。さらに、図の一部は通信の基本方向を示すために通信パス上に矢印を含むが、通信は、示されている矢印に関して反対方向に生じる場合もあることを理解されたい。最後に、その他のブロックは、例示されているブロックの間に追加または挿入されてもよい。

したがって、本開示の図面に示されている流れ図のいずれかに例示される動作、ステップ、機能、コンポーネント、ブロックの順序またはシーケンスは、修正、変更、置換、カスタマイズ、あるいは特定の流れ図内で再配置されてもよく、特定の動作、ステップ、機能、コンポーネント、もしくはブロックの削除または省略を含むことを明確に理解されたい。さらに、特定の流れ図に例示されている動作、ステップ、機能、コンポーネント、またはブロックは、本特許開示の教示を実施する目的で１つまたは複数のプロセスに関して追加の変種、変更、および設定を遂行するために、別の流れ図に例示されている動作、ステップ、機能、コンポーネント、またはブロックと相互混合されるかまたは相互配列もしくは再配列されてもよい。

さまざまな実施形態が示され、詳細に説明されてきたが、特許請求の範囲は、任意の特定の実施形態または実施例に限定されることはない。上記の発明を実施するための形態のいずれも、任意の特定のコンポーネント、要素、ステップ、動作、または機能が、特許請求の範囲に含まれなければならないように必須であることを暗示するものと解釈されるべきではない。単数形の要素の参照は、明示的にそのように言及されている場合を除き「唯一の（ｏｎｅ ａｎｄ ｏｎｌｙ ｏｎｅ）」を意味することを意図されておらず、「１つまたは複数の（ｏｎｅ ｏｒ ｍｏｒｅ）」を意味する。当業者に知られている上記で説明される実施形態の要素のすべての構造的および機能的等価物は、参照により本明細書に明示的に組み入れられ、本発明の特許請求の範囲によって包含されることが意図される。したがって、本明細書において説明される例示的な実施形態が、以下に添付される特許請求の範囲の精神および範囲内のさまざまな修正および変更を伴って実施されてもよいことを、当業者は理解するであろう。

Claims (15)

1. ネットワークにおいて適応ビットレートＡＢＲメディアを配布するための方法（６００）であって、
   第１のネットワークノードにおいて第１のＡＢＲメディア要素を最初に取り込むこと（６０５）と、
   前記第１のネットワークノードにおいて、第２のノードにおいて最初に取り込まれた第２のＡＢＲメディア要素を受信すること（６１０）と、
   前記第１のネットワークノードから第１の複数のネットワークノードへの前記第１および第２のＡＢＲメディア要素の配布を開始すること（６１５）とを備える方法。
2. 第１のエンティティに所有されるドメインで前記第１のＡＢＲメディア要素を最初に取り込むこと（６２５）と、第２のエンティティに所有されるドメインで前記第２のＡＢＲメディア要素を最初に取り込むことをさらに備える請求項１に記載の方法（６００）。
3. ＡＢＲメディア要素が取り出され得る位置を備える配信データベースを保持すること（６３０）をさらに備える請求項１または２に記載の方法（６００）。
4. 前記第１のＡＢＲメディア要素の要求がクライアントデバイスから受信されたと決定すること（６４０）に応じて、前記第１のＡＢＲメディア要素を取得する最善のパッケージャを決定すること（６４５）と、前記クライアントデバイスを前記第１のＡＢＲメディア要素を取り出すべき前記最善のパッケージャに方向付けること（６５０）とをさらに備える請求項３に記載の方法（６００）。
5. ＡＢＲメディアの前記第１の要素の配信の制約を満たす最善のパッケージャが使用可能ではないと決定すること（６５５）に応じて、前記制約を満たすことができる新しいパッケージャのインスタンス化を開始すること（６６０）と、前記クライアントをＡＢＲメディアの前記第１の要素を取り出すべき前記新しいパッケージャに方向付けることとをさらに備える請求項４に記載の方法（６００）。
6. ＡＢＲメディアの前記第１の要素を、第１の配布ルートに沿って前記第１の複数のノードにプッシュすること（６７５）と、ＡＢＲメディアの前記第２の要素の配布を、前記第１のネットワークノードから第２の配布ルートに沿って所与のネットワークノードまでオンデマンドでプルすること（６８０）とをさらに備える請求項１から５のいずれか一項に記載の方法（６００）。
7. 前記クライアントが権利を有する前記ＡＢＲメディアに関連付けられているクライアントエンタイトルメント、ビジネス論理、および配信の制約に基づいて、クライアントデバイスのチャネルマップを動的に構築すること（６８５）をさらに備える請求項１から６のいずれか一項に記載の方法（６００）。
8. 適応ビットレートＡＢＲメディアを配布するための複数のネットワークノード（１１２、２０２）を備えるシステム（１００Ａ、２００）であって、
   第１のネットワークノードにおいて第１のＡＢＲメディア要素を最初に取り込み（６０５）、
   前記第１のパッケージャにおいて、第２のネットワークノードにおいて最初に取り込まれた第２のＡＢＲメディア要素を受信し（６１０）、
   ピアツーピア方式による第１の複数のノードへの前記第１および第２のＡＢＲメディア要素の配布を開始する（６１５）ように設定されたシステム。
9. 前記システムは、前記ＡＢＲメディアに関連付けられているクライアントエンタイトルメント、ビジネス論理、および配信の制約に基づいて、クライアントのチャネルマップを動的に構築する（６８５）ようにさらに設定される請求項８に記載のシステム（１００Ａ、２００）。
10. 前記システムは、前記第１のＡＢＲメディア要素が最初に取り込まれるとき、前記第１のＡＢＲメディア要素に関連付けられているサービスマニフェストを作成する（６９５）ようにさらに設定され、前記サービスマニフェストは複数の指令要素を備える請求項８または９に記載のシステム（１００Ａ、２００）。
11. 前記システムは、プロバイダのさまざまな地域の１つとさまざまなプロバイダとの間の境界を越えてサマリーサービスマニフェストを交換する（６９０）ようにさらに設定される請求項８から１０のいずれか一項に記載のシステム（１００Ａ、２００）。
12. 前記システムは、ルーティングされたＡＢＲメディアのコンテンツプロバイダに代わって前記境界においてエンタイトルメントを実施するためにサマリーマニフェストを使用するようにさらに設定される請求項１１に記載のシステム（１００Ａ、２００）。
13. 前記システムは、前記境界において、ルーティングされたＡＢＲメディアのダウンストリームプロバイダからＡＢＲメディア配信分析法をロールアップし、前記ルーティングされたＡＢＲメディアのアップストリームプロバイダに前記ＡＢＲメディア配信分析法を提供するためにサマリーマニフェストを使用するようにさらに設定される請求項１１に記載のシステム（１００Ａ、２００）。
14. 前記システムは、ルーティングされたＡＢＲメディアのダウンストリームプロバイダによりサービスレベルアグリーメントを実施するためにサマリーマニフェストを使用するようにさらに設定される請求項１１に記載のシステム（１００Ａ、２００）。
15. プロセッサによって実行されるとき、適応ビットレートＡＢＲメディアを配布するための方法を実行するプログラム命令のシーケンスを有する非一時的コンピュータ可読媒体であって、前記方法は、
    第１のネットワークノードにおいて第１のＡＢＲメディア要素を最初に取り込むこと（６０５）と、
    前記第１のネットワークノードにおいて、第２のノードにおいて最初に取り込まれた第２のＡＢＲメディア要素を受信すること（６１０）と、
    前記第１のネットワークノードから第１の複数のネットワークノードへのピアツーピア方式による前記第１および第２のＡＢＲメディア要素の配布を開始すること（６１５）とを備える、非一時的コンピュータ可読媒体。

Images