JP5795404B2 - 被管理ネットワークを介したテレビ放送および非被管理ネットワークを介した双方向コンテンツのクライアントデバイスへの提供 - Google Patents

Description

（優先権）
この国際的な特許出願は、「Ｐｒｏｖｉｄｉｎｇ Ｔｅｌｅｖｉｓｉｏｎ Ｂｒｏａｄｃａｓｔｓ ｏｖｅｒ ａ Ｍａｎａｇｅｄ Ｎｅｔｗｏｒｋ ａｎｄ Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｎｔｅｎｔ ｏｖｅｒ ａｎ Ｕｎｍａｎａｇｅｄ Ｎｅｔｗｏｒｋ ｔｏ ａ Ｃｌｉｅｎｔ Ｄｅｖｉｃｅ」と題する、２００８年６月２５日出願の米国仮特許出願第６１／１３３，１０２号からの優先権を主張し、この仮特許出願の全体が本明細書において参照により援用される。

（技術分野および背景技術）
本発明は、遠隔デバイスに双方向コンテンツを提供するためのシステムおよび方法に関し、より具体的には、被管理ネットワークおよび非被管理ネットワークの両方を採用するシステムおよび方法に関する。

ケーブルテレビシステムでは、ケーブルヘッドエンドが、１人以上の加入者にコンテンツを伝送し、コンテンツは、符号化された形態で伝送される。典型的には、コンテンツは、デジタルＭＰＥＧ映像として符号化され、各加入者は、ＭＰＥＧ映像ストリームを復号化可能なセットトップボックスまたはケーブルカードを有する。一次コンテンツの提供に加え、ケーブルプロバイダは、現在、ウェブページまたは限定（ｗａｌｌｅｄ−ｇａｒｄｅｎ）コンテンツ等の双方向コンテンツを提供可能である。ウェブページ上の映像コンテンツおよび映像コンテンツを復号化するために要求されるアプリケーションまたはスクリプトを含む、インターネットのさらなる動的化に伴って、ケーブルプロバイダは、これらの動的ウェブページを加入者が視聴可能となるように適応している。要求加入者に符号化された形態で動的ウェブページを伝送するために、ケーブルヘッドエンドは、要求されたウェブページを読み出し、ウェブページをレンダリングする。したがって、ケーブルヘッドエンドは、最初に、動的ウェブページ内に現れる任意の符号化コンテンツを復号化しなければならない。例えば、映像がウェブページ上で再生されるべき場合、ヘッドエンドは、符号化映像を読み出し、映像の各フレームを復号化しなければならない。次いで、ケーブルヘッドエンドは、各フレームをレンダリングし、インターネットウェブページの一連のビットマップ画像を形成する。したがって、ウェブページは、ウェブページを形成するコンテンツのすべてが最初に復号化される場合にのみ、一緒に合成可能である。合成フレームが完了すると、合成された映像は、ＭＰＥＧエンコーダ等のエンコーダに送信され、再符号化される。次いで、圧縮されたＭＰＥＧ映像フレームが、ＭＰＥＧ映像ストリームとして、ユーザのセットトップボックスに送信される。

ケーブルテレビネットワークにおけるそのような合成符号化映像フレームの生成は、全符号化コンテンツが最初に復号化され、次いで、合成され、レンダリングされ、再符号化されなければならないため、集中的ＣＰＵおよびメモリ処理を必要とする。特に、ケーブルヘッドエンドは、コンテンツのすべてをリアルタイムで復号化および再符号化しなければならない。したがって、動的ウェブページとの双方向環境において、ユーザに操作させることは、必要とされる処理のため、ケーブルオペレータにとって、非常にコストがかかる。加えて、そのようなシステムは、符号化映像の再符号化のため、画質が劣化されるというさらなる欠点を有する。

衛星テレビシステムは、それが一方向の伝送に限定されるという問題に苦慮する。したがって、衛星テレビプロバイダは、「オンデマンド」または双方向のサービスを提示することができない。結果として、衛星テレビネットワークは、その加入者に対する被管理ネットワークの提供に限定され、双方向情報へのユーザに要求されるアクセスを提供することができない。他の通信システムは、例えば、双方向通信をサポートしない一方向のケーブルカードまたはケーブルシステムを有するケーブル加入者に、双方向コンテンツを提供することができない。

（発明の概要）
本発明の第１の実施形態では、非被管理ネットワーク上でユーザの表示デバイスに双方向コンテンツが提供される。クライアントデバイスは、クライアントデバイスにおいて、被管理ネットワーク上で、双方向識別子を含有する放送コンテンツ信号を受信する。双方向識別子は、ヘッダ内に含まれるか、またはデジタル映像データ内に埋め込まれるトリガであってもよい。トリガは、データストリーム、または指定されたフレーム、または起動のための時間内のトリガの時間位置に応じた時間成分を有してもよい。加えて、トリガは有効期限を有してもよく、このトリガは、ある期間の後、失効し得る。トリガの識別に応答して、クライアントデバイスは非被管理ネットワーク上で双方向コンテンツのための要求を送信する。例えば、被管理ネットワークは、一方向の衛星テレビネットワーク、ＩＰテレビネットワーク、またはケーブルテレビ放送ネットワークであってもよく、非被管理ネットワークはインターネットであってもよい。クライアントデバイスは、被管理ネットワークからのデータの受信と、非被管理ネットワークからのデータの受信とを切り替える。非被管理ネットワーク上で受信される双方向コンテンツは、ユーザのクライアントデバイスと関連付けられた表示デバイスに提供される。放送コンテンツ信号は、複数の放送プログラムを含有してもよく、クライアントデバイスは、関連付けられた表示デバイスに放送プログラムのうちの１つを選択的に出力する。双方向コンテンツは、１つ以上のソースから発生してもよい。例えば、双方向コンテンツは、遠隔サーバから来る映像コンテンツとともに、処理局で発生するテンプレートで構成されてもよい。処理局は、双方向コンテンツを収集し、双方向コンテンツをまとめてステッチングし、双方向コンテンツをクライアントデバイスによって復号化可能な形式に符号化し、非被管理ネットワーク上で双方向コンテンツをクライアントデバイスに伝送することができる。

ある実施形態では、被管理ネットワークおよび非被管理ネットワークの両方が単一通信リンク上で動作してもよい。例えば、非被管理ネットワークは、ケーブルまたはＤＳＬリンク上でＩＰプロトコルを使用するインターネットであってもよく、被管理ネットワークは、テレビプログラムを放送するＩＰプロトコルテレビネットワークであってもよい。本発明の実施形態では、クライアントデバイスは、非被管理ネットワークおよび被管理ネットワークの両方のためのポートを含み、トリガの存在等のイベントが生じた場合にスイッチに２つのネットワークを切り替えさせるためのプロセッサを含む。クライアントデバイスはまた、１つ以上のデコーダを含む。各デコーダは、異なるネットワークからのデータに対して動作してもよい。クライアントデバイスはまた、ユーザ入力デバイスから命令を受信するための赤外線ポートを含んでもよい。

いくつかの実施形態では、トリガは、放送コンテンツ信号内で発生しない場合がある。むしろ、トリガは、クライアントデバイスと通信し、かつクライアントデバイスにネットワークを切り替えさせる、ユーザによる入力デバイスとの対話の結果、発生してもよい。例えば、ユーザは、クライアントデバイスを通してユーザのテレビに提示される衛星放送を視聴しているかもしれない。ユーザがリモコンデバイス上のボタンを押下した結果生じる双方向セッションのための要求を受信すると、クライアントデバイスは、衛星放送の提示と、非被管理ネットワーク上でのコンテンツの提供とを切り替える。クライアントデバイスは、双方向セッションを処理局に要求し、処理局を通して双方向コンテンツが提供される。クライアントデバイスは、処理局からの伝送を受信し、ユーザのテレビに双方向コンテンツを復号化して提示する。

別の実施形態では、ＱＡＭチューナ等のチューナが、テレビに連結された別個のボックスの中、またはテレビの一部としてのいずれかで提供される。ＱＡＭチューナは、放送ケーブルコンテンツを受信する。テレビには、ＩＰ（インターネットプロトコル）通信を使用するインターネットへの接続を提供する、ＩＰデバイスが連結される。ＩＰデバイスは、テレビに外付けまたは内蔵型であってもよい。放送コンテンツは、テレビの中のプロセッサに、ＩＰ接続を介して双方向セッションのための要求を処理局に転送するＩＰデバイスへ信号をダイレクトさせる、トリガ信号を含む。処理局はプロセッサを割り当て、次いで、双方向コンテンツを読み出して、ステッチングしてまとめ、ＩＰデバイスに双方向コンテンツを提供する。次いで、ＩＰデバイスはテレビに双方向コンテンツを提供する。テレビはデコーダを含んでもよく、あるいはＩＰデバイスがデコーダを含んでもよい。

本発明の上述の特徴は、付随の図面への参照と併せて、以下の詳細な説明を参照することによって、より容易に理解されるであろう。
図１は、本発明の一変形例を実装するための通信環境を示すブロック図である。 図１Ａは、地域処理局および映像コンテンツ配信ネットワークを示す。 図１Ｂ．１は、例示の合成ストリーム表示および対話レイアウトファイルである。 図１Ｂ．２は、例示の合成ストリーム表示および対話レイアウトファイルである。 図１Ｂ．３は、例示の合成ストリーム表示および対話レイアウトファイルである。 図１Ｂ．４は、例示の合成ストリーム表示および対話レイアウトファイルである。 図１Ｂ．５は、例示の合成ストリーム表示および対話レイアウトファイルである。 図１Ｂ．６は、例示の合成ストリーム表示および対話レイアウトファイルである。 図１Ｃは、オーサリング環境内のフレームの構造を示す。 図１Ｄは、要素へのマクロブロック別のフレームの分解を示す。 図２は、ディスプレイ上に合成される複数のソースを示す略図である。 図３は、グルーミングを組み込むシステムの略図である。 図４は、グルーミング前、グルーミング後、およびグルーミングされたセクション内の映像オーバーレイを伴う、映像フレームを示す略図である。 図５は、例えば、Ｂ−フレームの除去等、グルーミングが行なわれる方法を示す略図である。 図６は、ＭＰＥＧフレーム構造を示す略図である。 図７は、Ｉ、Ｂ、およびＰフレームに対するグルーミングプロセスを示すフローチャートである。 図８は、領域境界動きベクトルの除去を描写する略図である。 図９は、ＤＣＴ係数の並べ換えを示す略図である。 図１０は、代替のグルーマを示す。 図１１は、映像フレームの実施例である。 図１２は、互いに対してランダム位置から開始する映像フレームを示す略図である。 図１３は、複数のＭＰＥＧ要素がピクチャ内に合成された、ディスプレイの略図である。 図１４は、複数の要素から成るピクチャのスライス分解を示す略図である。 図１５は、ステッチングに備えたスライスベースの符号化を示す略図である。 図１６は、ピクチャへの映像要素の合成を詳述する略図である。 図１７は、２４×２４サイズのマクロブロックから成る背景への１６×１６サイズのマクロブロック要素の合成を詳述する略図である。 図１８は、合成ピクチャの符号化および構築に伴うステップを示すフローチャートである。 図１９は、グルーミングの単純な実施例を提供する略図である。 図２０は、合成される要素が矩形状または連続状である必要がないことを示す略図である。 図２１は、単一要素が非連続状である、画面上の要素の略図を示す。 図２２は、複数の処理局および／またはセッションプロセッサにマルチキャストするために、一次放送コンテンツをグルーミングするためのグルーマを示す。 図２３は、表示デバイス上に表示される際のカスタマイズされたモザイクの実施例を示す。 図２４は、双方向ＭＰＥＧコンテンツを提供するためのＩＰベースのネットワークの略図である。 図２５は、双方向ＭＰＥＧコンテンツを提供するためのケーブルベースのネットワークの略図である。 図２６は、ケーブルベースのネットワークと併用するための負荷平衡装置のリソース割り当てプロセスのフローチャートである。 図２７は、負荷平衡のためのケーブルネットワーク要素間の通信を示すために使用される、システム略図である。 図２８は、非管理ＩＰネットワークを通して加入者に双方向コンテンツを提供することができる、管理された放送コンテンツ衛星ネットワークを示す。 図２９は、クライアントデバイスが被管理ネットワークを通して放送コンテンツを受信し、非被管理ネットワークを通して双方向コンテンツを要求および提供される、別の環境を示す。

（特定の実施形態の詳細な説明）
以下の詳細な説明および添付の特許請求の範囲において使用されるように、用語「領域」は、連続状または非連続状であるＭＰＥＧ（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）スライスの論理グループ化を意味するものとする。用語「ＭＰＥＧ」が使用される場合、ＭＰＥＧ−２およびＭＰＥＧ−４を含む、ＭＰＥＧ規格のあらゆる変形例を指すものとする。以下の実施形態に説明されるような本発明は、双方向ＭＰＥＧコンテンツの環境と、処理局とテレビ等の関連付けられたディスプレイを有するクライアントデバイスとの間の通信とを提供する。本発明は、ＭＰＥＧ仕様および符号化を詳細に参照するが、本発明の原理は、ブロックベースの変換に基づく他の符号化技術と併用されてもよい。以下の明細書および添付の特許請求の範囲において使用されるように、用語「符号化する」、「符号化される」、および「符号化」は、デジタルデータ信号を圧縮し、圧縮されたデジタルデータ信号をプロトコルまたは規格にフォーマットするプロセスを指すものとする。符号化映像データは、空間表現以外の任意の状態にあることが可能である。例えば、符号化映像データは、変換符号化、量子化、およびエントロピ符号化されるか、またはそれらの任意の組み合わせであってもよい。したがって、変換符号化されたデータは、符号化されているとみなされよう。

本願は、テレビとして表示デバイスを指すが、表示デバイスは、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、またはディスプレイを含む他のデバイスであってもよい。ＭＰＥＧコンテンツを復号化可能なセットトップボックス等の復号化デバイスを含むクライアントデバイスは、ユーザの表示デバイスと関連付けられる。ある実施形態では、デコーダは、表示デバイスの一部であってもよい。双方向ＭＰＥＧコンテンツは、オーサリング環境内に生成され、アプリケーション設計者に、コンテンツプロバイダおよび一次放送局からの映像コンテンツを含む、種々の要素からの１つ以上の場面を有するアプリケーションを生成する双方向ＭＰＥＧコンテンツを設計させる。アプリケーションファイルは、アクティブビデオマークアップ言語（ＡＶＭＬ）で形成される。オーサリング環境によって生成されるＡＶＭＬファイルは、単一フレーム／ページ内の映像グラフィカル要素（すなわち、ＭＰＥＧスライス）、映像グラフィカル要素のサイズ、各場面に対するページ／フレーム内の映像グラフィカル要素のレイアウト、映像グラフィカル要素へのリンク、および場面に対する任意のスクリプトを定義する、ＸＭＬベースのファイルである。ある実施形態では、ＡＶＭＬファイルは、テキストエディタ内における作成またはオーサリング環境による生成とは対照的に、直接作成されてもよい。映像グラフィカル要素は、静的グラフィック、動的グラフィック、または映像コンテンツであってもよい。場面内の各要素は、実際には、画像のシーケンスであって、静的グラフィックは、繰り返し表示され、経時的に変化しない画像であることを認識されたい。要素はそれぞれ、グラフィックのためのＭＰＥＧデータおよびグラフィックと関連付けられた動作の両方を含むことが可能なＭＰＥＧオブジェクトであってもよい。双方向ＭＰＥＧコンテンツは、ユーザが対話可能な場面内に複数の双方向ＭＰＥＧオブジェクトを含むことが可能である。例えば、場面は、ボタンＭＰＥＧオブジェクトであって、そのオブジェクトに対する映像グラフィックを形成する符号化ＭＰＥＧデータを提供するボタンＭＰＥＧオブジェクトを含んでもよく、また、ボタン状態を追跡するための手順を含んでもよい。ＭＰＥＧオブジェクトは、スクリプトと協働して作用してもよい。例えば、ＭＰＥＧボタンオブジェクトは、その状態（オン／オフ）を追跡し得る一方、場面内のスクリプトは、そのボタンが押下された際に何が生じるかを判定する。スクリプトは、映像コンテンツが再生または停止されているかどうかをボタンが示すように、ボタン状態を映像プログラムと関連付けてもよい。ＭＰＥＧオブジェクトは、常にオブジェクトの一部として関連付けられたアクションを有する。ある実施形態では、ボタンＭＰＥＧオブジェクト等のＭＰＥＧオブジェクトは、ボタンの状態の追跡記録以上のアクションを行なってもよい。また、そのような実施形態では、ＭＰＥＧオブジェクトは、外部プログラムに対する呼び出しを含んでもよく、ＭＰＥＧオブジェクトは、ボタングラフィックが使用中となると、プログラムにアクセスする。したがって、再生／一時停止ＭＰＥＧオブジェクトボタンの場合、ＭＰＥＧオブジェクトは、ボタンの状態を追跡するコードを含んでもよく、状態変化に基づいてグラフィカルオーバーレイを提供し、および／または映像プレイヤオブジェクトに、ボタンの状態に応じて、映像コンテンツを再生もしくは一時停止させる。

アプリケーションがオーサリング環境内に生成され、双方向セッションが要求クライアントデバイスによって要求されると、処理局は、双方向セッションのためのプロセッサを割り当てる。

処理局において動作可能な割り当てられたプロセッサは、仮想マシンを起動し、要求されたアプリケーションにアクセスし、実行する。プロセッサは、ＭＰＥＧ形式での伝送のために、場面のグラフィカル部分を調製する。クライアントデバイスによるＭＰＥＧ伝送の受信およびユーザのディスプレイ上での表示に応じて、ユーザは、クライアントデバイスと通信する入力デバイスを使用することによって、表示されたコンテンツと対話可能である。クライアントデバイスは、通信ネットワークを通して、処理局または他の遠隔場所において割り当てられたプロセッサ上で動作するアプリケーションに、ユーザからの入力要求を送信する。それに応答して、割り当てられたプロセッサは、ＭＰＥＧオブジェクトの要求および状態（以下、総称して、アプリケーション状態と称される）に基づいて、グラフィカルレイアウトを更新する。新しい要素は、場面に追加されるか、または場面内で差し替えられるか、あるいは完全に新しい場面が生成されてもよい。割り当てられたプロセッサは、場面に対する要素およびオブジェクトを収集し、割り当てられたプロセッサまたは別のプロセッサのいずれかが、オブジェクト（単数または複数）に従って、データおよび動作を処理し、ユーザのテレビ上への表示のために送受信機に伝送される、ＭＰＥＧ形式における修正されたグラフィカル表現を生成する。上述の流れは、割り当てられたプロセッサが処理局に位置することを示すが、割り当てられたプロセッサは、遠隔場所に位置して、ネットワーク接続を通して、処理局との通信のみを必要としてもよい。同様に、割り当てられたプロセッサは、クライアントデバイスとのあらゆるトランザクションを扱うように説明されるが、また、他のプロセッサが、アプリケーションのためのグラフィカルレイアウトのコンテンツ（ＭＰＥＧオブジェクト）の要求およびアセンブリに関与してもよい。

図１は、本発明の一変形例を実装するための通信環境１００を示すブロック図である。通信環境１００は、アプリケーションプログラマに対して、エンドユーザとの２方向の双方向性のためのアプリケーションを作成可能にする。エンドユーザは、テレビ等のクライアントデバイス１１０上でアプリケーションを視聴し、アップストリームネットワーク１２０を通して、コマンドをアップストリームに送信することによって、コンテンツと対話可能であって、アップストリームおよびダウンストリームは、処理局へのリターンパスリンクを提供する、同一ネットワークまたは別個のネットワークの一部であってもよい。アプリケーションプログラマは、１つ以上の場面を含むアプリケーションを生成する。各場面は、ＨＴＭＬウェブページと同等物であるが、場面内の各要素は、映像のシーケンスである点が異なる。アプリケーションプログラマは、場面のグラフィカル表現を設計し、音声および映像ファイル等の要素ならびにボタン等のオブジェクトへのリンクを組み込み、場面を制御する。アプリケーションプログラマは、グラフィカルオーサリングツール１３０を使用して、オブジェクトおよび要素をグラフィカルに選択する。オーサリング環境１３０は、アプリケーションプログラマに、映像オブジェクトを生成する要素と方法を関連付けさせる、グラフィカルインターフェースを含んでもよい。グラフィックは、ＭＰＥＧ符号化映像、グルーミングされたＭＰＥＧ映像、静止画像、または別の形式における映像であってもよい。アプリケーションプログラマは、コンテンツプロバイダ１６０（ニュースソース、映画スタジオ、ＲＳＳフィード等）および一次放送ソース（放送メディアおよびケーブル、オンデマンド映像ソース、ならびにウェブベースの映像ソース）１７０を含むいくつかのソースからのコンテンツをアプリケーションに組み込み可能である。アプリケーションプログラマは、ＡＶＭＬ（アクティブビデオマークアップ言語）におけるファイルとしてアプリケーションを生成し、映像コンテンツ配信ネットワーク１５０内のプロキシ／キャッシュ１４０にアプリケーションファイルを送信する。ＡＶＭＬファイル形式は、ＸＭＬ形式である。例えば、サンプルのＡＶＭＬファイルを示す図１Ｂを参照されたい。

コンテンツプロバイダ１６０は、ＭＰＥＧ映像／音声として映像コンテンツを符号化してもよく、またはコンテンツは、別のグラフィカル形式（例えば、ＪＰＥＧ、ＢＩＴＭＡＰ、Ｈ２６３、Ｈ２６４、ＶＣ−１等）であってもよい。続いて、コンテンツは、グルーマ／スケーラ１９０において、グルーミングおよび／またはスケーリングされ、ステッチングを可能にする好ましい符号化ＭＰＥＧ形式にコンテンツを配置してもよい。コンテンツが好ましいＭＰＥＧ形式に配置されない場合、処理局は、コンテンツを要求するアプリケーションがクライアントデバイスによって要求されると、形式をグルーミングする。コンテンツプロバイダからのコンテンツ等、放送メディアサービスからの一次放送コンテンツ１７０は、グルーミングされるであろう。一次放送コンテンツは、好ましくは、コンテンツを処理局に転送する前に、ステッチングのために、好ましいＭＰＥＧ形式にコンテンツを符号化するグルーマ／スケーラ１８０において、グルーミングおよび／またはスケーリングされる。

コンテンツプロデューサ１６０からの映像コンテンツは、アプリケーションプログラマによって生成されるアプリケーションとともに、映像コンテンツ配信ネットワーク１５０を通して配信され、配信点１４０に保存される。これらの配信点は、図１内のプロキシ／キャッシュとして表される。コンテンツプロバイダは、双方向処理局と併用するために、映像コンテンツ配信ネットワーク内のプロキシ／キャッシュ１４０位置にそのコンテンツを配置する。したがって、コンテンツプロバイダ１６０は、そのコンテンツを映像コンテンツ配信ネットワーク１５０のキャッシュ１４０に提供可能であって、本アーキテクチャを実装する１つ以上の処理局は、アプリケーションのために必要とされると、映像コンテンツ配信ネットワーク１５０を通して、コンテンツにアクセスしてもよい。映像コンテンツ配信ネットワーク１５０は、ローカルネットワーク、地域ネットワーク、またはグローバルネットワークであってもよい。したがって、処理局における仮想マシンがアプリケーションを要求すると、アプリケーションは、配信点のうちの１つから読み出されることが可能であって、アプリケーションのＡＶＭＬファイル内に定義されるようなコンテンツが、同一または異なる配信点から読み出されることが可能である。

システムのエンドユーザは、セットトップボックス等のクライアントデバイス１１０を通して、処理局１０５にコマンドを送信することによって、双方向セッションを要求可能である。図１では、単一の処理局のみが示される。しかしながら、実際のアプリケーションでは、異なる地域に位置する複数の処理局が存在してもよく、処理局はそれぞれ、図１Ｂに示されるように、映像コンテンツ配信ネットワークと通信する。処理局１０５は、双方向セッションのために、エンドユーザのためのプロセッサを割り当てる。プロセッサは、あらゆるアドレッシングおよびリソースの割り当てを含むセッションを維持する。明細書および添付の特許請求の範囲において使用されるように、用語「仮想マシン」１０６は、割り当てられたプロセッサ同様に、処理局とクライアントデバイスとの間のセッション管理、およびリソースの割り当て（すなわち、双方向セッションのためのプロセッサの割り当て）等の機能を果たす、処理局における他のプロセッサを指すものとする。

仮想マシン１０６は、そのアドレスをクライアントデバイス１１０に通信し、双方向セッションが確立される。次いで、ユーザは、クライアントデバイス１１０を通して、双方向アプリケーション（ＡＶＭＬ）の提示を要求可能である。要求は、仮想マシン１０６によって受信され、それに応答して、仮想マシン１０６は、プロキシ／キャッシュ１４０からＡＶＭＬファイルを読み出し、仮想マシン１０６によってアクセス可能なメモリキャッシュ１０７内にインストールさせる。仮想マシン１０６は、複数のクライアントデバイス１１０と同時通信してもよく、クライアントデバイスは、異なるデバイスタイプであってもよいことを認識されたい。例えば、第１のデバイスは、携帯電話であってもよく、第２のデバイスは、セットトップボックスであってもよく、第３のデバイスは、パーソナルデジタルアシスタントであってもよく、ここで、各デバイスは、同一または異なるアプリケーションにアクセスする。

アプリケーションに対する要求に応答して、仮想マシン１０６は、アプリケーションを処理し、場面の一部である要素およびＭＰＥＧオブジェクトをプロキシ／キャッシュから、仮想マシン１０６と関連付けられたメモリ１０７内へと移動させることを要求する。ＭＰＥＧオブジェクトは、視覚的成分およびアクション可能な成分の両方を含む。視覚的成分は、１つ以上のＭＰＥＧスライスとして符号化されるか、または別のグラフィカル形式で提供されてもよい。アクション可能な成分は、オブジェクトの状態を保存していてもよく、計算を行なうか、関連付けられたプログラムにアクセスするか、またはオーバーレイグラフィックを表示してグラフィカル成分をアクティブとして識別することを含んでもよい。オーバーレイグラフィックは、クライアントデバイスに伝送される信号によって生成されてもよく、ここで、クライアントデバイスは、表示デバイス上のオーバーレイプレーン内にグラフィックを生成する。場面は、静的グラフィックではなく、むしろ、フレームのコンテンツが経時的に変化し得る複数の映像フレームを含むことを認識されたい。

仮想マシン１０６は、アプリケーション状態を含む場面情報に基づいて、場面に対する種々の要素およびオブジェクトの、サイズおよび位置を判定する。各グラフィカル要素は、連続状または非連続状ＭＰＥＧスライスから形成されてもよい。仮想マシンは、各グラフィカル要素に対するスライスのすべての位置を追跡する。グラフィカル要素を規定するスライスはすべて、領域を形成する。仮想マシン１０６は、各領域を追跡する。ＡＶＭＬファイル内の表示位置情報に基づいて、映像フレーム内の要素および背景に対するスライス位置が設定される。グラフィカル要素が未だグルーミングされた形式にない場合、仮想マシンは、その要素を要素レンダラに転送する。レンダラは、グラフィカル要素をビットマップとしてレンダリングし、レンダラは、ビットマップをＭＰＥＧ要素エンコーダ１０９に転送する。ＭＰＥＧ要素エンコーダは、ビットマップをＭＰＥＧ映像シーケンスとして符号化する。ＭＰＥＧエンコーダは、一連のＰ−フレームを出力するように、ビットマップを処理する。未だ事前符号化および事前グルーミングされていないコンテンツの実施例は、パーソナライズされたコンテンツである。例えば、ユーザが音楽ファイルを処理局に保存しており、提示されるグラフィック要素がユーザの音楽ファイルのリストである場合、本グラフィックは、仮想マシンによって、ビットマップとしてリアルタイムで生成されるであろう。仮想マシンは、ビットマップをレンダリングし、かつグルーミングのために、ビットマップをＭＰＥＧ要素エンコーダ１０９に転送する、要素レンダラ１０８にビットマップを転送する。

グラフィカル要素がＭＰＥＧ要素エンコーダによってグルーミングされた後、ＭＰＥＧ要素エンコーダ１０９は、他のユーザによる他の双方向セッションのための仮想マシン１０６によるその後の読み出しのために、グラフィカル要素をメモリ１０７に転送する。また、ＭＰＥＧエンコーダ１０９は、ＭＰＥＧ符号化グラフィカル要素をステッチャ１１５に転送する。要素のレンダリングおよび要素のＭＰＥＧ符号化は、仮想マシン１０６と同一または別個のプロセッサ内で達成されてもよい。また、仮想マシン１０６は、アプリケーション内に解釈される必要がある何かしらのスクリプトが存在するかどうか判定する。スクリプトが存在する場合、スクリプトは、仮想マシン１０６によって解釈される。

アプリケーション内の各場面は、静的グラフィック、ユーザ対話に基づいて変化するオブジェクトグラフィック、および映像コンテンツを含む、複数の要素を含むことが可能である。例えば、場面は、複数のボタンを有する音声映像およびマルチメディアコンテンツ（オブジェクトグラフィック）の再生のためのメディアプレイヤとともに、背景（静的グラフィック）、およびストリーミング映像コンテンツを表示するための映像コンテンツウインドウ（映像コンテンツ）を含んでもよい。メディアプレイヤの各ボタンそれ自体が、その独自の関連付けられた方法を含む、別個のオブジェクトグラフィックであってもよい。

仮想マシン１０６は、フレームに対して、グラフィカル要素（背景、メディアプレイヤグラフィック、および映像フレーム）のそれぞれを取得し、各要素の位置を判定する。オブジェクトおよび要素（背景、映像コンテンツ）のすべてが取得されると、要素およびグラフィカルオブジェクトは、要素およびＭＰＥＧオブジェクトに対する位置付け情報とともに、ステッチャ／合成器１１５に転送される。ステッチャ１１５は、仮想マシン１０６によって提供されるマッピングに従って、要素（映像コンテンツ、ボタン、グラフィック、背景）のそれぞれをステッチングしてまとめる。要素はそれぞれ、マクロブロック境界上に配置され、ステッチングしてまとめられると、要素は、ＭＰＥＧ映像フレームを形成する。定期的に、シーケンスをレフレッシュし、欠落マクロブロックを回避するために、場面フレームの要素がすべて符号化され、参照Ｐ−フレームを形成する。次いで、ＭＰＥＧ映像ストリームは、ダウンストリームネットワークを通して、クライアントデバイスのアドレスに伝送される。プロセスは、映像フレームのそれぞれに対して継続する。本明細書は、符号化プロセスとしてＭＰＥＧを参照するが、また、他の符号化プロセスが、本システムと併用されてもよい。

仮想マシン１０６、または他のプロセッサ、あるいは処理局１０５におけるプロセスは、要素のそれぞれおよび画面上の要素の位置に関する情報を維持する。また、仮想マシン１０６は、要素のそれぞれと関連付けられたオブジェクトに対する方法へのアクセスを有する。例えば、メディアプレイヤは、複数のルーチンを含む、メディアプレイヤオブジェクトを有してもよい。ルーチンは、再生、停止、早送り、巻き戻し、および一時停止を含むことが可能である。ルーチンはそれぞれ、コードを含み、ルーチンのうちの１つの起動のために、ユーザが要求を処理局１０５に送信すると、オブジェクトがアクセスされ、ルーチンが実行される。ルーチンは、ＪＡＶＡ（登録商標）ベースのアプレット、解釈されるスクリプト、または仮想マシンと関連付けられたオペレーティングシステム内で実行可能な別個のコンピュータプログラムであってもよい。

また、処理局１０５は、テレビと関連付けられたクライアントデバイスからプロセッサによって受信された信号に基づいて実行または解釈するために、ルーチンを判定するためのリンクされたデータ構造を生成してもよい。リンクされたデータ構造は、内包のマッピングモジュールによって形成されてもよい。データ構造は、各リソースおよび関連付けられたオブジェクトを、それぞれ他のリソースおよびオブジェクトに対して関連付ける。例えば、ユーザが、既に再生コントロールを使用中である場合、メディアプレイヤオブジェクトが起動され、映像コンテンツが表示される。映像コンテンツがメディアプレイヤウインドウ内で再生されるのに伴って、ユーザは、ユーザの遠隔コントロール上の方向キーを押下可能である。本実施例では、方向キーの押下は、停止ボタンの押下を示す。送受信機は、方向信号を生成し、割り当てられたプロセッサは、方向信号を受信する。仮想マシン１０６または処理局１０５における他のプロセッサは、リンクされたデータ構造にアクセスし、方向キー押下の方向に要素の位置を特定する。データベースは、要素がメディアプレイヤオブジェクトの一部である停止ボタンであることを示し、プロセッサは、映像コンテンツを停止するためのルーチンを実行する。ルーチンは、要求されたコンテンツを停止させる。最後の映像コンテンツフレームは、静止され、押下された停止ボタングラフィックは、ステッチャモジュールによって、フレーム内に組み込まれる。また、ルーチンは、フォーカスグラフィックを含むことにより、停止ボタンの周囲にフォーカスを提供してもよい。例えば、仮想マシンは、ステッチャに、１マクロブロック幅の境界線で、フォーカスを有するグラフィックを内包させることが可能である。したがって、映像フレームが復号化および表示されると、ユーザは、ユーザが対話可能なグラフィック／オブジェクトを識別可能となる。次いで、フレームは、マルチプレクサに転送され、ダウンストリームネットワークを通して、クライアントデバイスに送信される。ＭＰＥＧ符号化映像フレームは、クライアントデバイス（携帯電話、ＰＤＡ）または別個の表示デバイス（モニタ、テレビ）のいずれか上に表示されるクライアントデバイスによって復号化される。本プロセスは、最小の遅延を伴って生じる。このようにして、アプリケーションからの各場面は、複数の映像フレームをもたらし、それぞれ、メディアプレイヤアプリケーション状態のスナップショットを表す。

仮想マシン１０６は、クライアントデバイスからコマンドを繰り返し受信し、コマンドに応答して、直接または間接的にオブジェクトにアクセスし、ユーザ対話およびアプリケーション対話モデルに応答して、オブジェクトのルーチンを実行または解釈する。そのようなシステムでは、ユーザのテレビ上に表示される映像コンテンツ題材は、単なる復号化されたＭＰＥＧコンテンツであって、双方向性のための処理はすべて、処理局において生じ、割り当てられた仮想マシンによって編成される。したがって、クライアントデバイスは、デコーダのみを必要とし、コンテンツのいずれかをキャッシュまたは処理する必要はない。

クライアントデバイスからのユーザ要求を通して、処理局は、映像要素を別の映像要素と置換可能であることを認識されたい。例えば、ユーザは、映画のリストから選択して表示してもよく、したがって、ユーザが２つの映画間の切り替えを選択する場合、第１の映像コンテンツ要素は、第２の映像コンテンツ要素によって差し替えられる。各要素の位置、および要素を形成する領域の、リストを維持する仮想マシンは、場面内の要素を容易に置換し、新しいＭＰＥＧ映像フレームを生成可能であって、フレームは、ステッチングしてまとめられ、ステッチャ１１５内の新しい要素を含む。

図１Ａは、デジタルコンテンツ配信ネットワーク１００Ａと、コンテンツプロバイダ１１０Ａと、処理局１２０Ａとの間の相互運用を示す。本実施例では、コンテンツプロバイダ１３０Ａは、コンテンツを映像コンテンツ配信ネットワーク１００Ａに配信する。コンテンツプロバイダ１３０Ａまたは映像コンテンツ配信ネットワークと関連付けられたプロセッサのいずれかが、処理局１２０Ａの双方向ＭＰＥＧコンテンツの生成と互換性のあるＭＰＥＧ形式にコンテンツを変換する。デジタルコンテンツ配信ネットワーク１００Ａのコンテンツ管理サーバ１４０Ａは、コンテンツが世界的／全国的範囲のものである場合、異なる領域に位置するプロキシ／キャッシュ１５０Ａ−１５４Ａ間にＭＰＥＧ符号化コンテンツを配信する。コンテンツが地域的／ローカル的範囲のものである場合、コンテンツは、地域的／ローカル的プロキシ／キャッシュ内に常駐する。コンテンツは、アクセス回数を増加させるために、全国または全世界を通して異なる位置においてミラーリングされてもよい。エンドユーザが、そのクライアントデバイス１６０Ａを通して、地域処理局からアプリケーションを要求すると、地域処理局は、要求されたアプリケーションにアクセスする。要求されたアプリケーションは、映像コンテンツ配信ネットワーク内に位置してもよく、あるいはアプリケーションは、地域処理局または相互接続された処理局のネットワーク内にローカルに常駐してもよい。アプリケーションが読み出されると、地域処理局において割り当てられた仮想マシンは、読み出される必要がある映像コンテンツを判定する。コンテンツ管理サーバ１４０Ａは、仮想マシンが映像コンテンツ配信ネットワーク内のコンテンツの位置を特定する補助を行なう。コンテンツ管理サーバ１４０Ａは、コンテンツが、地域またはローカルのプロキシ／キャッシュ上に位置するかどうか判定可能であり、また、最も近いプロキシ／キャッシュを特定可能である。例えば、アプリケーションは、広告を含んでもよく、コンテンツ管理サーバは、ローカルプロキシ／キャッシュから広告を読み出すように仮想マシンに指図する。また、図１Ａに示されるように、中西部および南東部の地域処理局１２０Ａは両方とも、ローカルプロキシ／キャッシュ１５３Ａ、１５４Ａを有する。これらのプロキシ／キャッシュは、ローカルニュースおよびローカル広告を含有してもよい。したがって、南東部内のエンドユーザに提示される場面は、中西部内のエンドユーザへのものとは異なって現れてもよい。各エンドユーザには、異なるローカルニュース記事または異なる広告が提示されてもよい。コンテンツおよびアプリケーションが読み出されると、仮想マシンは、コンテンツを処理し、ＭＰＥＧ映像ストリームを生成する。次いで、ＭＰＥＧ映像ストリームは、要求クライアントデバイスへと向けられる。次いで、エンドユーザは、コンテンツと対話して、新しいコンテンツによって更新された場面を要求してもよく、処理局における仮想マシンは、映像コンテンツ配信ネットワークのプロキシ／キャッシュから新しい映像コンテンツを要求することによって、場面を更新する。

（オーサリング環境）
オーサリング環境は、双方向アプリケーションを開発するために、図１Ｃに示されるようなグラフィカルエディタを含む。アプリケーションは、１つ以上の場面を含む。図１Ｂに示されるように、アプリケーションウインドウは、アプリケーションが３つの場面（場面１、場面２、および場面３）から構成されることを示す。グラフィカルエディタは、デベロッパに、ユーザと関連付けられた表示デバイス上に最終的に示されるであろう表示を形成する場面の中に配置される要素を選択させる。いくつかの実施形態では、要素は、アプリケーションウインドウ内にドラッグ・アンド・ドロップされる。例えば、デベロッパは、メディアプレイヤオブジェクトおよびメディアプレイヤボタンオブジェクトを含むことを所望してもよく、ツールバーからこれらの要素を選択し、ウインドウ内に要素をドラッグ・アンド・ドロップするであろう。グラフィカル要素がウインドウ内にあると、デベロッパは、要素を選択可能となり、要素のためのプロパティウインドウが提供される。プロパティウインドウは、少なくとも、グラフィカル要素の位置（アドレス）、およびグラフィカル要素のサイズを含む。グラフィカル要素がオブジェクトと関連付けられる場合、プロパティウインドウは、デベロッパが、ビットマップイベント画面に切り替え、関連付けられたオブジェクトパラメータを変更することを可能にするタブを含むであろう。例えば、ユーザは、ボタンと関連付けられた機能を変更してもよく、またはボタンと関連付けられたプログラムを定義してもよい。

図１Ｄに示されるように、システムのステッチャは、オーサリング環境の出力であるＡＶＭＬファイルに基づいて、場面に対する一連のＭＰＥＧフレームを生成する。場面内の各要素／グラフィカルオブジェクトは、領域を定義する異なるスライスから構成される。要素／オブジェクトを定義する領域は、連続状または非連続状であってもよい。システムは、マクロブロック境界上にグラフィックを形成するスライスをスナップする。各要素は、連続状スライスを有する必要はない。例えば、背景は、それぞれが複数のマクロブロックから構成されるいくつかの非連続状スライスを有する。背景は、静的である場合、内部符号化されたマクロブロックによって定義可能である。同様に、ボタンのそれぞれに対するグラフィックは、内部符号化可能である。しかしながら、ボタンは、状態と関連付けられ、複数の可能なグラフィックを有する。例えば、ボタンは、第１の状態「オフ」および第２の状態「オン」を有してもよく、第１のグラフィックは、非押下状態にあるボタンの画像を示し、第２のグラフィックは、押下状態にあるボタンを示す。また、図１Ｃは、映画に対するウインドウである、第３のグラフィカル要素を示す。映画スライスは、内部符号化および相互符号化マクロブロックの混合で符号化され、コンテンツに基づいて、動的に変化する。同様に、背景が動的である場合、背景は、グルーミングに関する以下の要件に従って、内部符号化および相互符号化マクロブロックの両方で符号化可能である。

ユーザがクライアントデバイスを通してアプリケーションを選択すると、処理局は、オーサリング環境のグラフィカルエディタからのレイアウトに従って、要素をステッチングしてまとめる。オーサリング環境の出力は、アクティブビデオマークアップ言語ファイル（ＡＶＭＬ）を含む。ＡＶＭＬファイルは、ボタン、関連付けられたグラフィックのアドレス、およびグラフィックのサイズ等の多状態要素に関する状態情報を提供する。ＡＶＭＬファイルは、各要素に対するＭＰＥＧフレーム内の位置を示し、各要素と関連付けられたオブジェクトを示し、ユーザのアクションに基づいて、ＭＰＥＧフレームに対する変更を定義するスクリプトを含む。例えば、ユーザは、命令信号を処理局に送信してもよく、処理局は、受信した命令信号に基づいて、ＡＶＭＬファイルを使用して、一式の新しいＭＰＥＧフレームを構築する。ユーザは、種々の映像要素間の切り替えを所望してもよく、命令信号を処理局に送信してもよい。処理局は、フレームに対するレイアウト内の映像要素を除去し、第２の映像要素を選択し、第２の映像要素をＭＰＥＧフレーム内の第１の映像要素の位置にステッチングさせる。本プロセスは、以下に説明される。

（ＡＶＭＬファイル）
アプリケーションプログラミング環境は、ＡＶＭＬファイルを出力する。ＡＶＭＬファイルは、ＸＭＬベースの構文を有する。ＡＶＭＬファイル構文は、ルートオブジェクト＜ＡＶＭＬ＞を含む。他の最上位レベルタグは、アプリケーションが開始するとロードされる第１の場面を指定する＜ｉｎｉｔｉａｌｓｃｅｎｅ＞を含む。＜ｓｃｒｉｐｔ＞タグは、スクリプトを識別し、＜ｓｃｅｎｅ＞タグは、場面を識別する。また、タグ内のデータを適用するための階層が存在するように、最上位レベルタグのそれぞれに対して下位レベルタグが存在してもよい。例えば、最上位レベルストリームタグは、映像ストリームのための＜ａｓｐｅｃｔ ｒａｔｉｏ＞、＜ｖｉｄｅｏ ｆｏｒｍａｔ＞、＜ｂｉｔ ｒａｔｅ＞、＜ａｕｄｉｏ ｆｏｒｍａｔ＞、および＜ａｕｄｉｏ ｂｉｔ ｒａｔｅ＞を含んでもよい。同様に、場面タグは、場面内の要素のそれぞれを含んでもよい。例えば、背景のための＜ｂａｃｋｇｒｏｕｎｄ＞、ボタンオブジェクトのための＜ｂｕｔｔｏｎ＞、および静止グラフィックのための＜ｓｔａｔｉｃ ｉｍａｇｅ＞である。他のタグは、要素のサイズおよび位置のための＜ｓｉｚｅ＞および＜ｐｏｓ＞を含み、場面内の各要素に対する下位レベルタグであってもよい。ＡＶＭＬファイルの実施例は、図１Ｂに提供される。

（グルーマ）
図２は、要求クライアントデバイスのテレビに提供可能な代表的表示の略図である。ディスプレイ２００は、画面上に現れる３つの別個の映像コンテンツ要素を示す。要素＃１
２１１は、要素＃２ ２１５および要素＃３ ２１７が挿入される背景である。

図３は、図２の表示を生成可能なシスムの第１の実施形態を示す。本略図では、３つの映像コンテンツ要素が、要素＃１ ３０３、要素＃２ ３０５、および要素＃３ ３０７の符号化映像として供給される。グルーマ３１０はそれぞれ、符号化映像コンテンツ要素を受信し、グルーマは、ステッチャ３４０がグルーミングされた映像コンテンツ要素を単一の合成された映像３８０に結合する前に、各要素を処理する。当業者には、グルーマ３１０が、単一プロセッサまたは並行に動作する複数のプロセッサであってもよいことを理解されたい。グルーマは、コンテンツプロバイダの施設または一次放送提供者の施設における、処理局内に位置してもよい。グルーマは、グルーマ１９０および１８０がステッチャ１１５に直接連結されてない図１に示されるように、ステッチャに直接接続されなくてもよい。

ステッチングのプロセスは、以下に説明されるが、要素が最初にグルーミングされる場合、はるかにより効率的に行なうことが可能である。

グルーミングは、圧縮された映像内に存在する相互依存性の一部を除去する。グルーマは、ＩおよびＢフレームをＰフレームに変換し、クロッピングまたは除去された映像の別のフレームのセクションを参照する、任意の迷子の（ｓｔｒａｙ）動きベクトルを固定する。したがって、グルーミングされた映像ストリームは、他のグルーミングされた映像ストリームおよび符号化静止画像と組み合わせて使用され、合成ＭＰＥＧ映像ストリームを形成可能である。各グルーミングされた映像ストリームは、複数のフレームを含み、これらフレームは、別のグルーミングされたフレーム内に容易に挿入可能であって、複数の合成フレームは、一緒にグループ化され、ＭＰＥＧ映像ストリームを形成する。グルーミングされたフレームは、１つ以上のＭＰＥＧスライスから形成されてもよく、ＭＰＥＧ映像ストリーム内のＭＰＥＧ映像フレームよりサイズが小さくてもよいことに留意されたい。

図４は、複数の要素４１０、４２０を含有する合成映像フレームの実施例である。本合成映像フレームは、例証目的のために提供される。図１に示されるようなグルーマは、映像シーケンスがステッチャ内でステッチングされてまとめらることが可能であるように、単一要素のみを受信し、その要素（映像シーケンス）をグルーミングする。グルーマは、複数の要素を同時に受信しない。本実施例では、背景映像フレーム４１０は、スライス当たり１列を含む（これは、実施例に過ぎず、列は、任意の数のスライスから構成され得る）。図１に示されるように、場面内の要素すべての位置を含む、映像フレームのレイアウトは、ＡＶＭＬファイル内のアプリケーションプログラマによって定義される。例えば、アプリケーションプログラマは、場面に対する背景要素を設計してもよい。したがって、アプリケーションプログラマは、ＭＰＥＧ映像として符号化される背景を有してもよく、背景がプロキシキャッシュ１４０内に配置されるのに先立って、背景をグルーミングしてもよい。したがって、アプリケーションが要求されると、アプリケーションの場面内の要素はそれぞれ、グルーミングされた映像であってもよく、グルーミングされた映像は、容易にステッチングしてまとめることが可能である。コンテンツプロバイダおよび一次放送局に対して、２つのグルーマが図１内に示されるが、グルーマは、システムの他の部分に存在してもよいことに留意されたい。

示されるように、映像要素４２０は、背景映像フレーム４１０内に挿入される（また、実施例に過ぎないが、本要素は、列当たり複数のスライスからも構成され得る）。オリジナル映像フレーム４１０内のマクロブロックが、その値を判定する際、別のマクロブロックを参照し、動画像４２０がその場所に挿入されるために参照マクロブロックがフレームから除去される場合、マクロブロック値は、再計算される必要がある。同様に、後続フレーム内の別のマクロブロックをマクロブロックが参照し、そのマクロブロックが除去され、他のソース題材がその場所に挿入される場合、マクロブロック値は、再計算される必要がある。これは、映像４３０をグルーミングすることによって対処される。映像フレームは、列が複数のスライスを含有し、その一部が、代用映像コンテンツと整合するように特異的にサイズ調整および配置されるように処理される。本プロセスが完了後は、現在のスライスの一部をオーバーレイ映像と置換し、オーバーレイ４４０を伴うグルーミングされた映像をもたらすという単純な作業である。グルーミングされた映像ストリームは、その特定のオーバーレイを対処するように特異的に定義されている。異なるオーバーレイは、異なるグルーミングパラメータを指図するであろう。したがって、このタイプのグルーミングは、ステッチングに備えて、映像フレームを複数のスライスにセグメント化するプロセスに対処する。スライスをオーバーレイ要素に追加する必要は決してないことに留意されたい。スライスは、受信要素、すなわち、オーバーレイが配置されるであろう要素にのみ追加される。グルーミングされた映像ストリームは、ストリームのグルーミングされた特徴に関する情報を含有可能である。提供可能な特徴は、１．グルーミングされたウインドウの左上および右下角の位置、２．左上角のみの位置、次いで、ウインドウのサイズ、を含む。スライスのサイズは、画素レベルまで正確である。

また、映像ストリーム内の特徴情報を提供するための２つの方法が存在する。１つ目は、スライスヘッダ内に情報を提供することである。２つ目は、拡張データスライス構造内にその情報を提供することである。これらの選択肢のうちのいずれかを使用して、仮想マシンおよびステッチャ等の後続処理段階に、必要情報の転送を成功させることが可能である。

図５は、グルーミング前後の映像グラフィカル要素に対する映像シーケンスを示す。オリジナルの到来する符号化ストリーム５００は、当業者に公知であるように、ＭＰＥＧ Ｉ−フレーム５１０、Ｂ−フレーム５３０、５５０、およびＰ−フレーム５７０のシーケンスを有する。このオリジナルストリームでは、Ｉ−フレームは、他のフレームすべて（ＢおよびＰの両方）に対する参照５１２として使用される。これは、Ｉ−フレームから他のフレームすべてへの矢印を介して示される。また、Ｐ−フレームは、両方のＢ−フレームに対する参照フレーム５７２として使用される。グルーマは、ストリームを処理し、全フレームをＰ−フレームと置換する。最初に、オリジナルＩ−フレーム５１０が、内部符号化されたＰ−フレーム５２０に変換される。次に、Ｂ−フレーム５３０、５５０が、Ｐ−フレーム５４０および５６０に変換５３５され、直前のフレームのみ参照するように修正される。また、Ｐ−フレーム５７０は、その参照５７４をオリジナルＩ−フレーム５１０からＰ−フレーム５７０の直前の新しく生成されたＰ−フレーム５６０に移動させるように修正される。結果として得られるＰ−フレーム５８０は、グルーミングされた符号化フレーム５９０の出力ストリームに示される。

図６は、標準的ＭＰＥＧ−２ビットストリーム構文の略図である。ＭＰＥＧ−２は、実施例として使用され、本発明は、本実施例に限定されるものとしてみなされるべきではない。ビットストリームの階層構造は、シーケンスレベルで開始する。これは、シーケンスヘッダ６００を含有し、ピクチャのグループ（ＧＯＰ）データ６０５が続く。ＧＯＰデータは、ＧＯＰヘッダ６２０を含有し、ピクチャデータ６２５が続く。ピクチャデータ６２５は、ピクチャヘッダ６４０を含有し、スライスデータ６４５が続く。スライスデータ６４５は、あるスライスオーバーヘッド６６０から成り、マクロブロックデータ６６５が続く。最後に、マクロブロックデータ６６５は、あるマクロブロックオーバーヘッド６８０から成り、ブロックデータ６８５が続く（ブロックデータは、さらに分割されるが、この参照の目的のためには必要とされない）。シーケンスヘッダは、グルーマ内で規準として作用する。しかしながら、全フレームがＰ−フレームであるため、グルーマのＧＯＰヘッダ出力は存在しない。ヘッダの残りは、必要とされる出力パラメータを満たすように修正されてもよい。

図７は、映像シーケンスをグルーミングするためのフローを提供する。最初に、フレームタイプが判定される７００（Ｉ−フレーム７０３、Ｂ−フレーム７０５、またはＰ−フレーム７０７）。Ｉ−フレーム７０３は、Ｂ−フレーム７０５同様に、Ｐ−フレームに変換される必要がある。加えて、Ｉ−フレームは、ステッチャが必要とするピクチャ情報に整合させる必要がある。例えば、この情報は、ピクチャヘッダ内に設定される符号化パラメータを示してもよい。したがって、第１のステップは、ピクチャヘッダ内の情報が、全グルーミングされた映像シーケンスに対して一貫性であるように、ピクチャヘッダ情報７３０を修正することである。ステッチャ設定は、アプリケーション内に含まれ得るシステムレベル設定である。これらは、ビットストリームの全レベルに対して使用されるであろうパラメータである。修正を必要とする項目は、以下の表に提供され、

次に、スライスオーバーヘッド情報７４０が修正されなければならない。修正するパラメータは、以下の表に提供され、

次に、マクロブロックオーバーヘッド７５０情報が、修正を必要としてもよい。修正されるべき値は、以下の表に提供され、

最後に、ブロック情報７６０が、修正を必要としてもよい。修正される項目は、以下の表に与えられる。すなわち、

ブロック変更が完了すると、プロセスを映像の次のフレームから再開可能である。

フレームタイプがＢ−フレーム７０５である場合、また、Ｉ−フレームに必要とされる同一ステップが、Ｂ−フレームに必要とされる。しかしながら、加えて、動きベクトル７７０が修正を必要とする。２つのシナリオが存在する。Ｂ−フレームは、Ｉ−フレームまたはＰ−フレーム直後に続く、あるいはＢ−フレームは、別のＢ−フレームに続く。Ｂ−フレームがＩまたはＰフレームのいずれかに続く場合、ＩまたはＰフレームを参照として使用する動きベクトルは、同一のままであることが可能であって、残差のみ、変更が必要とされるであろう。これは、前向き参照動きベクトルが残差であるように変換するくらい単純であってもよい。

別のＢ−フレームに続くＢ−フレームの場合、動きベクトルおよびその残差は両方とも、修正される必要があるであろう。第２のＢ−フレームは、ここでは、その直前のＰフレームに新しく変換されたＢを参照しているはずである。最初に、Ｂ−フレームおよびその参照が復号化され、動きベクトルおよび残差が再計算される。フレームが復号化され、動きベクトルを更新するが、ＤＣＴ係数を再符号化する必要がないことに留意されたい。これらは、同一のままである。動きベクトルおよび残差のみ、計算および修正される。

最後のフレームタイプは、Ｐ−フレームである。また、本フレームタイプは、Ｉ−フレームと同一パスを辿る。図８は、領域境界に隣接するマクロブロックに対する動きベクトルの修正を示す。領域境界上の動きベクトルは、他の映像要素が挿入される背景要素と最も関連することを認識されたい。したがって、背景要素のグルーミングは、アプリケーションクリエイタによって達成されてもよい。同様に、映像要素がクロッピングされ、背景要素内の「ホール」に挿入される場合、クロッピングされた要素は、「ホール」外側の位置をポイントする動きベクトルを含んでもよい。クロッピングされた画像に対する動きベクトルのグルーミングは、映像要素がクロッピングされる必要があるサイズをコンテンツクリエイタが既知の場合、コンテンツクリエイタによって行なわれてもよく、またはグルーミングは、挿入されるべき映像要素が背景内の「ホール」のサイズより大きい場合、要素レンダラおよびＭＰＥＧエンコーダと組み合わせて、仮想マシンによって達成されてもよい。

図８は、背景要素から除去される領域を囲繞する動きベクトルによって生じる課題をグラフィック的に示す。図８の実施例では、場面は、２つの領域、＃１ ８００および＃２
８２０を含む。不適切な動きベクトル参照の２つの実施例が存在する。第１の事例では、領域＃１ ８００（背景）に挿入される領域＃２ ８２０は、動き８４０に対する参照として、領域＃１ ８００（背景）を使用する。したがって、領域＃２内の動きベクトルは、補正される必要がある。不適切な動きベクトル参照の第２の事例は、領域＃１ ８００が、動き８６０に対する参照として、領域＃２ ８２０を使用する場合に生じる。グルーマは、同一領域内のフレームを使用して再符号化するか、またはマクロブロックを内部符号化されたブロックに変換することのいずれかによって、これらの不適切な動きベクトル参照を除去する。

また、動きベクトルを更新し、フレームタイプを変更することに加えて、グルーマは、フィールドベースの符号化マクロブロックからフレームベースの符号化マクロブロックに変換してもよい。図９は、フィールドベースからフレームベースの符号化マクロブロックへの変換を示す。参照として、フレームベースのブロック集合９００が圧縮される。圧縮されたブロック集合９１０は、同一ブロック内に同一情報を含有するが、ここでは、圧縮された形態で含有されている。一方、また、フィールドベースのマクロブロック９４０も、圧縮される。これが行なわれると、全偶数列（０、２、４、６）は、上方ブロック（０および１）に配置される一方、奇数列（１、３、５、７）は、下方ブロック（２および３）に配置される。圧縮されたフィールドベースのマクロブロック９５０が、フレームベースのマクロブロック９７０に変換されると、係数は、あるブロックから別のブロックに移動される必要がある９８０。すなわち、列は、奇偶ではなく、番号順に再構築されなければならない。フィールドベースの符号化では、ブロック２および３にあった列１および３は、ここでは、それぞれ、ブロック０または１に戻される。対応して、列４および６は、ブロック０および１から移動し、ブロック２および３に配置される。

図１０は、グルーミングプラットフォームの第２の実施形態を示す。全構成要素は、第１の実施形態のグルーマ１１１０Ａおよびステッチャ１１３０Ａと同一である。また、入力も、同一である（入力＃１ １１０３Ａ、入力＃２ １１０５Ａ、および入力＃３ １１０７Ａ、ならびに合成された出力１２８０）。本システムにおける差異は、ステッチャ１１４０Ａが、同期およびフレームタイプ情報の両方のフィードバックをグルーマ１１１０Ａのそれぞれに提供することである。同期およびフレームタイプ情報によって、ステッチャ１２４０は、グルーマ１１１０Ａが続くＧＯＰ構造を定義可能である。本フィードバックおよびＧＯＰ構造によって、グルーマの出力は、もはやＰ−フレームだけではなく、Ｉ−フレームおよびＢ−フレームを含むことも可能である。フィードバックを伴わない実施形態の制限は、いずれのグルーマにもステッチャが構築していたフレームのタイプが未知であることである。ステッチャ１１４０Ａからのフィードバックを伴うこの第２の実施形態では、グルーマ１１１０Ａには、ステッチャが構築しているピクチャタイプを既知であって、したがって、グルーマは、整合するフレームタイプを提供するであろう。これは、同一データレートを仮定すると、ピクチャ品質を改良し、より多くの参照フレームおよび既存フレームのより少ない修正に起因して、品質レベルが一定に維持されると仮定すると、データレートを低下させる一方、同時に、Ｂ−フレームが許容されるため、ビットレートを低減する。

（ステッチャ）
図１１は、図１に示されるステッチャ等のステッチャモジュールを実装するための環境を示す。ステッチャ１２００は、異なるソースから映像要素を受信する。非圧縮コンテンツ１２１０は、ステッチャ１２００におけるその到着に先立って、図１に示されるＭＰＥＧ要素エンコーダ等のエンコーダ１２１５内で符号化される。圧縮または符号化された映像１２２０は、符号化される必要はない。しかしながら、両方の場合において、音声１２１７、１２２７を映像１２１９、１２２９から分離する必要がある。音声は、ストリーム内に含まれるように、音声セレクタ１２３０に供給される。映像は、バッファ１２５０に入れられる前に、フレーム同期ブロック１２４０に供給される。フレームコンストラクタ１２７０は、コントローラ１２７５からの入力に基づいて、バッファ１２５０からデータを引き出す。フレームコンストラクタ１２７０からの映像は、映像と整合するように音声が遅延１２６０された後、音声とともに、マルチプレクサ１２８０に供給される。マルチプレクサ１２８０は、音声および映像ストリームを結合し、任意の標準的デコーダ上で再生可能な合成された符号化出力ストリーム１２９０を出力する。プログラムまたはトランスポートストリームにデータストリームを多重化することは、当業者には周知である。符号化映像ソースは、リアルタイム、保存場所からのもの、または両方の組み合わせであることが可能である。ソースすべてがリアルタイムで到着する必要はない。

図１２は、一時的に同期していない３つの映像コンテンツ要素の実施例を示す。３つの要素を同期させるために、要素＃１ １３００は、「アンカ」または「参照」フレームとして使用される。すなわち、それはマスタフレームとして使用され、他の全フレームは、それに整合されるであろう（これは、実施例に過ぎず、システムは、到来する映像ソースのいずれからも別個のその独自のマスタフレーム参照を有し得る）。出力フレームタイミング１３７０、１３８０は、要素＃１ １３００のフレームタイミングと整合するように設定される。要素＃２および＃３ １３２０、１３４０は、要素＃１ １３００と整合しない。したがって、そのフレーム開始の位置が特定され、バッファ内に保存される。例えば、要素＃２ １３２０は、１フレーム遅延され、したがって、参照フレームとともに合成される前に、全体的フレームが利用可能である。要素＃３は、参照フレームよりもはるかに遅い。要素＃３は、２つのフレームにわたって集められ、２つのフレームにわたって提示される。すなわち、要素＃３ １３４０の各フレームは、参照フレームのフレームレートと整合するために、２つの連続的フレームに対して表示される。反対に、フレーム（図示せず）が参照フレームの２倍の速度で流れる場合、フレームが１つおきに欠落されるであろう（図示せず）。恐らく、全要素がほぼ同一速度で流れているため、フレームが、同期を維持するために、繰り返されるかまたは欠落される必要がある頻度は低いであろう。

図１３は、例示的合成映像フレーム１４００を示す。本実施例では、フレームは、ピクチャ当たり３０列１４２０を伴う列当たり４０マクロブロック１４１０から成る。サイズは、実施例として使用され、本発明の範囲を制限するように意図されるものではない。フレームは、種々位置に合成される要素１４４０を有する背景１４３０を含む。これらの要素１４４０は、映像要素、静止要素等であることが可能である。すなわち、フレームは、全体的な背景で構築され、次いで、異なる要素と置換される特定のエリアを有する。この特定の実施例は、背景上に合成される４つの要素を示す。

図１４は、ピクチャ内のスライスを例示する画面のより詳細な変形例を示す。略図は、列当たり４０マクロブロックおよびピクチャ当たり３０列（非制限的、例示目的に過ぎない）から成るピクチャを描写する。しかしながら、また、スライスに分割されるピクチャも示す。スライスのサイズは、列全体１５９０（陰影として示される）または列内の数マクロブロック１５８０（要素＃４ １５２８内の斜線を伴う矩形として示される）であることが可能である。背景１５３０は、各領域の幅に整合するスライスサイズを伴う複数の領域に分割されている。これは、要素＃１ １５２２を見ると、より分かるであろう。要素＃１ １５２２は、１２のマクロブロック幅であるように定義されている。次いで、背景１５３０および要素＃１ １５２２の両方に対する本領域のスライスサイズは、そのマクロブロックの正確な数となるように定義される。次いで、要素＃１ １５２２は、６つのスライスから成り、各スライスは、１２のマクロブロックを含有する。同様に、要素＃２ １５２４は、スライス当たり８つのマクロブロックの４つのスライスから成り、要素＃３ １５２６は、スライス当たり２３のマクロブロックの１８のスライスであって、要素＃４ １５２８は、スライス当たり５つのマクロブロックの１７のスライスである。背景１５３０および要素は、任意の数のスライスから成るように定義可能であって、ひいては、任意の数のマクロブロックであり得ることは明白である。これは、所望の任意の様式にピクチャおよび要素を配列するために、完全なる柔軟性を提供する。映像フレーム内の要素の位置付けとともに、各要素に対するスライスコンテンツを決定するプロセスは、ＡＶＭＬファイルを使用して、図１の仮想マシンによって決定される。

図１５は、仮想マシンによる、ステッチャ内でステッチングを生じさせるための背景１６００の調製を示す。仮想マシンは、ＡＶＭＬファイルに基づいて、非圧縮背景を収集し、背景を要素エンコーダに転送する。仮想マシンは、背景内の位置を転送し、要素は、フレーム内に配置されるであろう。示されるように、背景１６２０は、仮想マシンによって、背景の要素エンコーダへの転送に先立って、要素（単数または複数）が配置される（べき）場所と正確に整合するホールとともに、特定のスライス構成に分割されている。エンコーダは、背景を圧縮し、要素（単数または複数）が配置される場所に「ホール」または「複数のホール」を残す。エンコーダは、圧縮された背景をメモリに転送する。次いで、仮想マシンは、メモリにアクセスし、場面に対する各要素を読み出し、要素のそれぞれに対する各スライスの位置のリストとともに、符号化要素をステッチャに転送する。ステッチャは、スライスのそれぞれを取り込み、スライスを適切な位置に配置する。

この特定のタイプの符号化は、「スライスベースの符号化」と呼ばれる。スライスベースのエンコーダ／仮想マシンは、出力フレームの所望のスライス構造を認知しており、その符号化を適切に行なうものである。すなわち、エンコーダは、スライスのサイズおよびそれらが属する場所を知っている。必要とされる場合にホールを残す場所を知っている。所望の出力スライス構成を認知していることによって、仮想マシンは、容易にステッチングされる出力を提供する。

図１６は、背景要素が圧縮された後の合成プロセスを示す。背景要素１７００は、要素１７４０が配置されるべきホールとともに、７つのスライスに圧縮されている。合成画像１７８０は、背景要素１７００および要素１７４０の組み合わせの結果を示す。合成映像フレーム１７８０は、挿入されたスライスを灰色で示す。本略図は、背景上に合成される単一要素を描写するが、ユーザのディスプレイ上に適合するであろう任意の数の要素を合成可能である。さらに、背景または要素に対する列当たりスライスの数は、示されているものよりも多いことも可能である。背景および要素の、スライス開始およびスライス終了点は、整合されなければならない。

図１７は、背景要素１８００（２４画素×２４画素）と追加された映像コンテンツ要素１８４０（１６画素×１６画素）との間の異なるマクロブロックサイズを示す略図である。合成された映像フレーム１８８０は、２つの場合を示す。水平には、画素は、背景８００内には、２４画素／ブロック×４ブロック＝９６画素幅、映像コンテンツ要素１８４０に対しては、１６画素／ブロック×６ブロック＝９６画素幅であるように整合される。しかしながら、垂直には、差異が存在する。背景１８００は、２４画素／ブロック×３ブロック＝７２画素高である。要素１８４０は、１６画素／ブロック×４ブロック＝６４画素高である。これは、８画素の垂直ギャップ１８６０を残す。ステッチャは、そのような差異を認知し、要素または背景のいずれかを外挿し、ギャップを充填可能である。また、明暗の境界領域が存在するように、ギャップを残すことも可能である。本実施例は、２４×２４および１６×１６のマクロブロックサイズを使用するが、マクロブロックサイズの任意の組み合わせを容認可能である。ＤＣＴベースの圧縮形式は、意図される本発明の範囲から逸脱することなく、１６×１６以外のサイズのマクロブロックに依存してもよい。同様にまた、ＤＣＴベースの圧縮形式は、意図される本発明の範囲から逸脱することなく、時間的予測のために、可変サイズのマクロブロックに依存してもよい。最後に、また、コンテンツの周波数領域表現は、意図される本発明の範囲から逸脱することなく、他のフーリエ関連変換を使用して達成されてもよい。

また、合成された映像フレーム内にオーバーラップが存在することも可能である。再び図１７を参照すると、要素１８４０は、４つのスライスから成る。本要素が、実際には、５つのスライスである場合、合成された映像フレーム１８８０内の背景要素１８００とオーバーラップするであろう。本衝突を解決するための複数の方法が存在するが、最も容易には、要素の４つのスライスのみ合成し、５つ目を欠落させる。また、第５のスライスを背景列に合成し、衝突する背景列をスライスに分割し、第５の要素スライスと衝突する背景スライスを除去することも可能である（次いで、第６の要素スライスを追加し、任意のギャップを充填することも可能である）。

異なるスライスサイズの可能性は、到来する背景および映像要素が適切であるか確認するためのチェックを行なう合成機能を必要とする。すなわち、それぞれが完全（例えば、フレーム全体）である、サイズ衝突が存在しないか等を確かめる。

図１８は、フレームの要素を描写する略図である。単純合成ピクチャ１９００は、要素１９１０および背景要素１９２０から成る。要求された場面に対する映像フレームの構築を制御するために、ステッチャは、仮想マシンによって提供されるような各要素に対する位置情報に基づいて、データ構造１９４０を構築する。データ構造１９４０は、マクロブロックの数およびマクロブロックが位置する場所を記述する、リンクされたリストを含有する。例えば、データ列１ １９４３は、ステッチャが、背景に対するバッファであるバッファＢから、４０のマクロブロックを取り込むはずであることを示す。データ列２ １９４５は、バッファＢから１２のマクロブロック、次いで、バッファＥ（要素１９１０に対するバッファ）から８つのマクロブロック、次いで、バッファＢから別の２０のマクロブロックを取り込むはずである。これは、ステッチャがデータ構造を使用して、バッファＢから４０のマクロブロックを取り込む、最後の列１９４７まで継続する。バッファ構造１９７０は、各背景または要素に対して別個のエリアを有する。Ｂバッファ１９７３は、Ｂマクロブロック内にステッチングのための全情報を含有する。Ｅバッファ１９７５は、Ｅマクロブロック内にステッチングのための情報を有する。

図１９は、複数の符号化要素からピクチャを構築するためのプロセスを描写するフローチャートである。シーケンス２０００は、映像フレーム組成２０１０を開始することによって始まる。最初に、フレームが、同期２０１５され、次いで、各列２０２０が、適切なスライス２０３０をつかむことによって構築される。次いで、スライスが、挿入２０４０され、システムは、それが列の終了２０５０であるかどうかチェックする。そうでない場合、プロセスは、列の終了２０５０に到達するまで、「次のスライスをフェッチ」ブロック２０３０に戻る。列が完了すると、システムは、それがフレームの終了２０８０であるかどうかチェックする。そうではない場合、プロセスは、「各列に対して」２０２０ブロックに戻る。フレームが完了すると、システムは、それが場面に対するシーケンスの終了２０９０であるかどうかチェックする。そうではない場合、「フレームを合成」２０１０ステップに戻る。そうである場合、場面に対するフレームまたは映像フレームのシーケンスは、完了２０９０する。そうではない場合、フレーム構築プロセスを繰り返す。シーケンスの終了２０９０に到達した場合、場面は完了であって、プロセスが終了するか、または別のフレームの構築を開始可能である。

ステッチャの性能は、ステッチャにフレーム形式に関する情報を事前に提供することによって、改良（より少ないプロセッサパワーでより高速にフレームを構築）可能である。例えば、仮想マシンは、ステッチャに、挿入されるフレーム内のエリアの開始位置およびサイズを提供してもよい。代替として、情報は、各スライスに対する開始位置であり得、次いで、ステッチャは、サイズ（２つの開始位置間の差異）を解明可能である。本情報は、仮想マシンによって外部から提供可能であるか、または仮想マシンは、情報を各要素に組み込み可能である。例えば、スライスヘッダの一部を使用して、本情報を伝えることが可能である。ステッチャは、フレーム構造のこの事前知識を使用して、必要とされる十分前に、要素の合成を開始可能である。

図２０は、システムのさらなる改良を示す。上記グルーマセクションにて説明したように、グラフィカル映像要素は、グルーミング可能であって、それによって、既に圧縮され、かつ、ステッチングしてまとめられるために復号化される必要がない、ステッチング可能な要素を提供する。図２０では、フレームは、いくつかの符号化スライス２１００を有する。各スライスは、列全体である（これは、実施例として使用されているに過ぎず、列は、グルーミングに先立って、複数のスライスから成り得る）。仮想マシンは、ＡＶＭＬファイルと組み合わせて、合成された映像フレーム内において特定の位置に配置される特定のサイズの要素２１４０が存在すべきであるかどう判定する。グルーマは、到来する背景２１００を処理し、列全体の符号化スライスを、所望の要素２１４０位置の周囲およびその中のエリアに整合する、より小さいスライスに変換する。結果として得られるグルーミングされた映像フレーム２１８０は、所望の要素２１４０に整合するスライス構成を有する。次いで、ステッチャは、グルーミングされたフレーム２１８０から、＃３および＃６を除く全スライスを選択することによって、ストリームを構築する。それらのスライスの代わりに、ステッチャは、要素２１４０スライスをつかみ、所定の場所でそれを使用する。このように、背景は、圧縮された領域を残すことなく、システムは、依然として、要素２１４０をフレームに合成可能である。

図２１は、合成されるべき要素を規定するために利用可能な柔軟性を示す。要素は、異なる形状およびサイズであることが可能である。要素は、連続的に常駐する必要はなく、実際、単一要素は、背景によって分離される複数の画像から形成可能である。本図は、背景要素２２３０（灰色エリア）を示し、その上に合成される単一要素２２１０（白色エリア）を有している。本略図では、合成される要素２２１０は、エリアであって、シフトされる、異なるサイズである、かつ単一列上に要素の複数の部分が存在する場所でさえある、エリアを有する。ステッチャは、表示を生成するために使用される複数の要素があたかも存在しているかのように、本ステッチングを行なうことが可能である。フレームに対するスライスは、連続的に、Ｓ１〜Ｓ４５と標識される。これらは、要素が配置されるであろうスライス位置を含む。また、要素は、ＥＳ１〜ＥＳ１４のそのスライス番号付けを有する。要素スライスは、単一要素ファイルから引き出される場合であっても、所望に応じて、背景内に配置可能である。

要素スライスに対するソースは、いくつかの選択肢のうちの任意の１つであることが可能である。それは、リアルタイム符号化ソースに由来可能である。別個のスライスから構築される複合スライスであることが可能であって、１つは、背景を有し、他は、テキストを有する。キャッシュからフェッチされる事前符号化要素であることも可能である。これらの実施例は、例示目的に過ぎず、要素ソースに対する選択肢を限定するように意図されない。

図２２は、一次放送コンテンツをグルーミングするためのグルーマ２３４０を使用する実施形態を示す。コンテンツは、グルーマ２３４０によって、リアルタイムで受信される。各チャネルは、コンテンツが容易にステッチングしてまとめられることが可能であるように、グルーマ２３４０によってグルーミングされる。図２２のグルーマ２３４０は、一次放送チャネルのすべてをグルーミングするために、複数のグルーマモジュールを含んでもよい。次いで、グルーミングされたチャネルは、１つ以上の処理局２３１０、２３２０、２３３０、および、アプリケーション内での使用のために、処理局のそれぞれの内の１つ以上の仮想マシンにマルチキャストされてもよい。示されるように、クライアントデバイスは、クライアントによって選択される、一次放送ソースおよび／または他のグルーミングされたコンテンツのモザイク２３５０の受信のためのアプリケーションを要求する。モザイク２３５０は、図２３に示されるように、複数のソース２３７１〜２３７６を同時に視聴可能な背景フレーム２３６０を含む場面である。例えば、ユーザが視聴を所望する複数のスポーツイベントが存在する場合、ユーザは、モザイク内で同時視聴するために、スポーツイベントを搬送するチャネルのそれぞれを要求可能である。ユーザは、ＭＰＥＧオブジェクト（編集）２３８０を選択し、次いで、表示されるべき所望のコンテンツソースを編集することさえ可能である。例えば、グルーミングされたコンテンツは、一次／ライブ放送から、また、他の映像コンテンツ（すなわち、映画、事前録画されたコンテンツ等）からも選択可能である。モザイクは、ユーザ選択された題材、および、広告等の処理局／セッションプロセッサによって提供される題材の両方を含むことさえあり得る。図２２に示されるように、クライアントデバイス２３０１〜２３０５はそれぞれ、チャネル１を含むモザイクを要求する。したがって、チャネル１に対してマルチキャストグルーミングされたコンテンツは、個人化されたモザイクの構造内で異なる仮想マシンおよび異なる処理局によって使用される。

クライアントデバイスがモザイクアプリケーションに対する要求を送信すると、クライアントデバイスと関連付けられた処理局は、要求されたモザイクアプリケーションに対するクライアントデバイスのために、プロセッサ／仮想マシンを割り当てる。割り当てられた仮想マシンは、ステッチャを使用して、所望のチャネルから、グルーミングされたコンテンツを合成することによって、個人化されたモザイクを構築する。仮想マシンは、クライアントが要求したチャネルのモザイクを有するＭＰＥＧストリームをクライアントデバイスに送信する。したがって、コンテンツをステッチングしてまとめることが可能なように、最初に、コンテンツをグルーミングすることによって、モザイクを生成する仮想マシンは、最初に、所望のチャネルを復号化し、背景内のチャネルをビットマップとしてレンダリングし、次いで、ビットマップを符号化する必要がない。

モザイク等のアプリケーションは、クライアントデバイスと関連付けられたディスプレイ上のアプリケーションの表示のために、クライアントデバイスを通して直接、またはＰＣ等の別のデバイスを通して間接的に、要求可能である。ユーザは、ユーザのアカウントに関する情報を提供することによって、処理局と関連付けられたウェブサイトにログイン可能である。処理局と関連付けられたサーバは、アプリケーションを選択するための選択画面をユーザに提供するであろう。ユーザがモザイクアプリケーションを選択する場合、サーバは、ユーザがモザイク内での視聴を所望するコンテンツをユーザに選択させるであろう。モザイクに対して選択されたコンテンツに応答して、かつユーザのアカウント情報を使用して、処理局サーバは、要求をセッションプロセッサに向け、ユーザのクライアントデバイスとの双方向セッションを確立する。次いで、セッションプロセッサは、処理局サーバによって所望のアプリケーションを通知される。セッションプロセッサは、所望のアプリケーション（本実施例では、モザイクアプリケーション）を読み出し、要求されたＭＰＥＧオブジェクトを取得する。次いで、処理局サーバは、要求された映像コンテンツをセッションプロセッサに通知し、セッションプロセッサは、ステッチャと協働して、モザイクを構築し、モザイクをＭＰＥＧ映像ストリームとしてクライアントデバイスに提供する。したがって、処理局サーバは、双方向セッションを設定し、アプリケーションを要求し、表示のためのコンテンツを選択する際、クライアントデバイスの機能を果たすためのスクリプトまたはアプリケーションを含んでもよい。モザイク要素は、アプリケーションによって既定であってもよいが、また、ユーザ構成可能であって、個人化されたモザイクをもたらしてもよい。

図２４は、ＩＰベースのコンテンツ配信システムの略図である。本システムでは、コンテンツは、放送ソース２４００、コンテンツプロバイダ２４１０によって供給されるプロキシキャッシュ２４１５、構成および管理ファイル２４２０を含有するネットワーク接続ストレージ（ＮＡＳ）２４２５、または他の図示されないソースに由来してもよい。例えば、ＮＡＳは、コンテンツの位置に関する情報を提供するアセットメタデータを含んでもよい。本コンテンツは、負荷平衡スイッチ２４６０を通して利用可能であり得る。ＢｌａｄｅＳｅｓｓｉｏｎプロセッサ／仮想マシン２４６０は、コンテンツに対して異なる処理機能を果たすことにより、配信のためにコンテンツを準備可能である。コンテンツは、セットトップボックス２４９０等のクライアントデバイスを介して、ユーザによって要求される。本要求は、コントローラ２４３０によって処理され、コントローラ２４３０は、次いで、リソースおよびパスを構成することにより、本コンテンツを提供する。クライアントデバイス２４９０は、コンテンツを受信し、それをユーザのディスプレイ２４９５上に提示する。

図２５は、ケーブルベースのコンテンツ配信システムの略図である。構成要素の多くは、同一であって、コントローラ２５３０、放送ソース２５００、プロキシキャッシュ２５１５を介してそのコンテンツを提供するコンテンツプロバイダ２５１０、ファイルサーバＮＡＳ２５２５を介する構成および管理ファイル２５２０、セッションプロセッサ２５６０、負荷平衡スイッチ２５５０、セットトップボックス２５９０等のクライアントデバイス、およびディスプレイ２５９５を含む。しかしながら、また、異なる物理的メディアに起因して必要とされる機器のいくつかの付加的部品も存在する。この場合、追加されるリソースは、ＱＡＭ変調器２５７５、リターンパス受信機２５７０、結合器およびダイプレクサ２５８０、ならびにセッションおよびリソースマネージャ（ＳＲＭ）２５４０を含む。ＱＡＭアップコンバータ２５７５は、ユーザにデータ（コンテンツ）をダウンストリーム伝送することを要求される。これらの変調器は、ユーザへと続く同軸ケーブルを通して搬送可能な形態にデータを変換する。相応して、リターンパス受信機２５７０はまた、セットトップ２５９０からのケーブルをたどるデータを復調するために使用される。結合器およびダイプレクサ２５８０は、ダウンストリームＱＡＭチャネルを結合し、かつアップストリームリターンチャネルを分割する、受動的デバイスである。ＳＲＭは、ＱＡＭ変調器が構成され、かつ割り当てられる方法、およびストリームがクライアントデバイスにルーティングされる方法を制御する存在である。

これらの付加的リソースは、システムにコストを追加する。その結果、ＩＰネットワーク等の非ブロッキングシステムに類似するあるレベルの性能をユーザに配信するために必要とされる、付加的リソースの数を最小化することが所望される。ケーブルネットワークリソースとネットワーク上のユーザとの間に１対１の対応が存在しないため、リソースは、共有されなければならない。共有されるリソースは、ユーザがリソースを要求すると割り当てされ、次いで、ユーザがそのリソースの利用を終了すると解除可能なように管理されなければならない。これらのリソースの適切な管理は、それが行なわれない場合、リソースが最も必要とされる時に利用不可能であり得るため、オペレータにとって重要である。これが生じる場合、ユーザは、「お待ちください」メッセージ、または最悪の場合、「サービス利用不可」メッセージのいずれかを受信する。

図２６は、ユーザからの入力に基づいて、新しい双方向セッションを構成するために必要とされるステップを示す略図である。本略図は、割り当てられるか、または管理されるか、あるいは割当もしくは管理を行なうために使用されなければならない項目のみを描写する。典型的要求は、以下に列挙されるステップを辿るであろう。すなわち、
（１）セットトップボックス２６０９が、コントローラ２６０７からコンテンツを要求する２６１０
（２）コントローラ２６０７が、ＳＲＭ２６０３からＱＡＭ帯域幅を要求する２６２０
（３）ＳＲＭ２６０３が、ＱＡＭの可用性をチェックする２６２５
（４）ＳＲＭ２６０３が、ＱＡＭ変調器を割り当てる２６３０
（５）ＱＡＭ変調器が、確認を返す２６３５
（６）ＳＲＭ２６０３が、コントローラにＱＡＭ割り当ての成功を確認する２６４０
（７）コントローラ４０７が、セッションプロセッサを割り当てる２６５０
（８）セッションプロセッサが、割り当ての成功を確認する２６５３
（９）コントローラ２６０７が、コンテンツを割り当てる２６５５
（１０）コントローラ２６０７が、セットトップ２６０９を構成する２６６０
これは、以下を含む：
ａ．同調する周波数
ｂ．取得するプログラム、または代替として、復号化するためのＰＩＤ
ｃ．キーストロークのキャプチャのために、セッションプロセッサに接続するためのＩＰポート
（１１）セットトップ２６０９が、チャネルに同調する２６６３
（１２）セットトップ２６０９が、コントローラ２６０７に成功を確認する２６６５
である。

コントローラ２６０７は、セットトップボックス２６０９からサービスに対する要求に基づいて、リソースを割り当てる。コントローラ２６０７は、セットトップまたはサーバが「セッションの終了」を送信すると、これらのリソースを解除する。コントローラ２６０７は、最小の遅延で迅速に反応可能であるが、ＳＲＭ２６０３は、設定数の毎秒ＱＡＭセッション、すなわち、２００のみを割り当て可能である。本レートを超える需要は、ユーザに容認不可能な遅延をもたらす。例えば、５００の要求が同時に到着する場合、最後のユーザは、その要求が叶うまで５秒待機する必要があるであろう。また、要求が叶うのではなく、「サービス利用不可能」等のエラーメッセージが表示され得る可能性もある。

上述の実施例は、ケーブルＴＶネットワーク上のＡＶＤＮセッションに対する要求および応答シーケンスを説明するが、以下の実施例は、ＩＰＴＶネットワーク上の類似シーケンスを説明する。シーケンス自体は、特許請求の範囲ではなく、ＡＶＤＮがＩＰＴＶネットワーク上でどのように作用するかの例示であることに留意されたい。すなわち、
（１）クライアントデバイスが、セッションマネージャ（すなわち、コントローラプロキシ）を介して、コントローラからコンテンツを要求する
（２）セッションマネージャは、コントローラに要求を転送する
（３）コントローラは、セッションマネージャ（すなわち、クライアントプロキシ）を介して、要求されたコンテンツに応答する
（４）セッションマネージャは、ユニキャストセッションをオープンし、ユニキャストＩＰセッション上で、クライアントにコントローラ応答を転送する
（５）クライアントデバイスは、ユニキャストＩＰセッション上で送信されるコントローラ応答を取得する
（６）セッションマネージャは、マルチキャストＩＰセッション上で応答を同時にナローキャストすることにより、帯域幅使用量最適化技術と同一のコンテンツを同時に要求するノードグループ上の他のクライアントと共有してもよい
である。

図２７は、性能改良のために各エリアを開示するために使用される、簡略化システムの略図である。本略図は、管理されるであろうデータおよび機器のみに焦点を当て、他の全ての非被管理項目を除去する。したがって、スイッチ、リターンパス、結合器等は、明確化のために除去される。本略図を使用して、エンドユーザからコンテンツ起点に戻るように作用する各項目を検討する。

第１の問題は、ＳＲＭ２７２０によるＱＡＭ２７７０およびＱＡＭチャネル２７７５の割り当てである。特に、リソースは、ＳＲＭ過負荷を防止するように、すなわち、ＳＲＭ２７２０に対する要求がその毎秒セッションのレートを超える際に、ユーザが認識するであろう遅延を排除するように管理されなければならない。

ＳＲＭ「過負荷」を防止するために、「時間ベースのモデル化」が使用されてもよい。時間ベースのモデル化の場合、コントローラ２７００は、過去のトランザクション、特に、高負荷期間の履歴を監視する。この以前の履歴を使用することによって、コントローラ２７００は、高負荷期間が生じ得る時、例えば、毎時０分を予測可能である。コントローラ２７００は、本知識を使用して、その期間が生じる前に、リソースを事前に割り当てる。すなわち、予測アルゴリズムを使用して、将来のリソース要求を判定する。実施例として、コントローラ２７００が、４７５名のユーザが特定の時間に参加するであろうと考える場合、その負荷に遭遇する際には、リソースが既に割り当てられており、ユーザが遅延を認識できないように、それらのリソースの割り当てを５秒早く開始可能である。

第２に、リソースは、オペレータからの入力に基づいて、事前に割り当て可能である。オペレータが、主要イベント、例えば、有料スポーツイベントが放送されることを既知の場合、見越して、リソースを事前に割り当てることを所望してもよい。両方の場合において、ＳＲＭ２７２０は、非使用時およびイベント後、使用していないＱＡＭ２７７０リソースを解放する。

第３に、ＱＡＭ２７７０は、以前の履歴から独立した「変化率」に基づいて割り当て可能である。例えば、コントローラ２７００が、トラフィックの突然の急増を認識する場合、付加的セッションを追加する際にＱＡＭ割り当てステップを回避するために、必要とされるものよりも多くのＱＡＭ帯域幅を要求可能である。突然の予想外の急増の例は、賞金が獲得され得ることを示すプログラムの一部としてのボタンをユーザが選択する場合である。

現在、各セッションが追加される場合、ＳＲＭ２７２０に対する要求は１つである。代わりに、コントローラ２７００は、ＱＡＭ２７７０全体または単一のＱＡＭの帯域幅の大部分を要求し、本発明がそのＱＡＭチャネル２７７５内のデータを取り扱うことを可能にし得る。本システムの一側面は、わずか１、２、または３Ｍｂ／秒のチャネルを生成する能力であるため、これは、最大２７の要求を単一要求と置換することによって、ＳＲＭ２７２０に対する要求数を低減可能である。

また、ユーザは、既にアクティブセッション中にある場合であっても、異なるコンテンツを要求すると、遅延を経験するであろう。現在、セットトップ２７９０が、アクティブセッション中であって、新しい集合のコンテンツ２７３０を要求する場合、コントローラ２７００は、ＳＲＭ２７２０に、ＱＡＭ２７７０の割り当てを解除するように指図する必要があり、次いで、コントローラ２７００は、セッションプロセッサ２７５０およびコンテンツ２７３０の割り当てを解除しなければならず、次いで、ＳＲＭ２７２０から別のＱＡＭ２７７０を要求し、次いで、異なるセッションプロセッサ２７５０およびコンテンツ２７３０を割り当てる。代わりに、コントローラ２７００は、ＱＡＭ変調器２７７０に供給している映像ストリーム２７５５を変更し、それによって、以前に確立されたパスを未変化のまま残すことが可能である。変更を達成するためのいくつかの方法が存在する。第１に、ＱＡＭ変調器２７７０は、ネットワーク上に存在するので、コントローラ２７００は、単に、ＱＡＭ２７７０を駆動するセッションプロセッサ２７５０を変更可能である。第２に、コントローラ２７００は、セッションプロセッサ２７５０からセットトップ２７９０への接続を未変化のまま残すが、セッションプロセッサ２７５０に供給するコンテンツ２７３０を変更することが可能である（例えば、「ＣＮＮ Ｈｅａｄｌｉｎｅ Ｎｅｗｓ」から「ＣＮＮ Ｗｏｒｌｄ Ｎｏｗ」）。これらの方法は両方とも、ＱＡＭ初期化およびセットトップ同調遅延を排除する。

したがって、リソースは、これらの双方向サービスを提供するために必要とされる機器の量を最小限にするように知的に管理される。特に、コントローラは、ＱＡＭ２７７０に供給する映像ストリーム２７５５を操作可能である。これらのストリーム２７５５をプロファイリングすることによって、コントローラ２７００は、ＱＡＭ２７７０内のチャネル使用量を最大限にすることが可能である。すなわち、各ＱＡＭチャネル２７７５内のプログラム数を最大限にし、無駄な帯域幅およびＱＡＭ２７７０の必要数を低減可能である。ストリームをプロファイリングするための３つの主要手段が存在する（定式、事前プロファイリング、およびライブフィードバック）。

第１のプロファイリング方法は、ＱＡＭチャネル２７７５を充填するために使用される種々の映像ストリームのビットレートを加算することから成る、定式である。特に、単一映像ストリーム２７５５を生成するために使用される多くの映像要素が存在する場合がある。各要素の最大ビットレートが合算されることにより、映像ストリーム２７５５に対する総計ビットレートを取得可能である。全映像ストリーム２７５５のビットレートを監視することによって、コントローラ２７００は、最も効率的にＱＡＭチャネル２７７５を使用する映像ストリーム２７５５の組み合わせを生成可能である。例えば、４つの映像ストリーム２７５５（２つは、１６Ｍｂ／秒、２つは、２０Ｍｂ／秒）が存在する場合、コントローラは、各チャネル当たりビットレートのうちの１つを割り当てることによって、３８．８Ｍｂ／秒ＱＡＭチャネル２７７５を最良に充填可能である。次いで、これは、映像を配信するために、２つのＱＡＭチャネル２７７５を必要とする。しかしながら、定式プロファイリングを伴わない場合、恐らく、２つの１６Ｍｂ／秒映像ストリーム２７５５は、単一の３８．８Ｍｂ／秒ＱＡＭチャネル２７７５に結合され、次いで、各２０Ｍｂ／秒映像ストリーム２７５５は、その独自の３８．８Ｍｂ／秒ＱＡＭチャネル２７７５を有さなければならないため、３つのＱＡＭチャネル２７７５の結果となり得る。

第２の方法は、事前プロファイリングである。本方法では、コンテンツ２７３０に対するプロファイルは、受信または内部生成される。プロファイル情報は、ストリームとともにメタデータに、または別個のファイルに、提供可能である。プロファイリング情報は、映像全体から、または代表的サンプルから生成可能である。次いで、コントローラ２７００は、ストリーム内の種々の時間におけるビットレートを認知し、本情報を使用して、効果的に映像ストリーム２７５５を結合可能である。例えば、２つの映像ストリーム２７５５が両方とも、２０Ｍｂ／秒のピークレートを有した場合、そのピークに基づいて割り当てられる帯域幅であるなら、異なる３８．８Ｍｂ／秒ＱＡＭチャネル２７７５に割り当てられる必要があるであろう。しかしながら、コントローラが、公称ビットレートが１４Ｍｂ／秒であることを既知であって、かつそのそれぞれのプロファイルを既知であって、したがって、同時ピークが存在しない場合、コントローラ２７００は、ストリーム２７５５を単一の３８．８Ｍｂ／秒ＱＡＭチャネル２７７５に結合可能である。特定のＱＡＭビットレートは、上述の実施例のみに対して使用され、限定として解釈されるべきではない。

プロファイリングのための第３の方法は、システムによって提供されるフィードバックを介する。システムは、コントローラ２７００に、ストリームを構築するために使用される全映像要素に対する現在のビットレート、および構築後のストリームの総計ビットレートを通知可能である。さらに、システムは、コントローラ２７００に、保存された要素のビットレートをその使用に先立って通知可能である。本情報を使用して、コントローラ２７００は、ＱＡＭチャネル２７７５を充填するための最も効率的態様で映像ストリーム２７５５を結合可能である。

また、３つのプロファイリング方法のいずれかまたはすべてを組み合わせて使用することも容認可能であることに留意されたい。すなわち、これら方法が個別に使用されなければならないという制限はない。

また、システムは、リソース自体の使用量に対処可能である。例えば、セッションプロセッサ２７５０が１００名のユーザをサポート可能であって、現在、３５０名のアクティブなユーザが存在する場合、４つのセッションプロセッサを必要とする。しかしながら、需要が、例えば、８０名のユーザに低下すると、それらのリソースを単一のセッションプロセッサ２７５０に再割り当てし、それによって、３つのセッションプロセッサの残りのリソースを節約することは理にかなうであろう。また、これは、故障の状況において有用である。リソースが故障する場合、本発明は、セッションを、利用可能な他のリソースに再割り当て可能である。このように、ユーザへの途絶が最小限にされる。

また、システムは、予想される使用量に応じて、機能を他の目的に転用可能である。セッションプロセッサ２７５０は、いくつかの異なる機能、例えば、映像の処理、音声の処理等を実装可能である。コントローラ２７００は、使用量の履歴を有するため、セッションプロセッサ２７００上の機能を調節し、予測される需要を満たすことが可能である。例えば、昼下がりに、典型的に、音楽に対する需要が高い場合、コントローラ２７００は、需要を見越して、付加的セッションプロセッサ２７５０を再割り当てし、音楽を処理可能である。相応して、夕方に、ニュースに対する需要が高い場合、コントローラ２７００は、需要を見越して、セッションプロセッサ２７５０を適宜再割り当てする。システムの柔軟性および予測は、最小量の機器で最適なユーザ経験を提供可能にする。すなわち、機器は、単一の目的のみを有し、その目的は要求されるのではないため、アイドル状態の機器は存在しない。

図２８は、非管理ＩＰネットワークを通して加入者に双方向コンテンツを提供することができる、管理された放送コンテンツ衛星ネットワークを示す。被管理ネットワークは、伝送されるコンテンツがサービスプロバイダによってのみ決定され、エンドユーザによっては決定されない通信ネットワークである。したがって、サービスプロバイダが、提示されるコンテンツに対する運営管理上の制御を有する。この定義は、物理的な相互接続とは無関係であり、論理的関連である。実際、両方のネットワークが同一物理リンク上で動作してもよい。被管理ネットワークでは、ユーザは、サービスプロバイダによって放送される複数のチャネルからあるチャネルを選択することができるが、全体のコンテンツはサービスプロバイダによって決定され、ユーザはネットワーク外の他のいずれのコンテンツにもアクセスすることができない。被管理ネットワークは、閉鎖型ネットワークである。非被管理ネットワークは、ユーザがサービスプロバイダ以外の団体にコンテンツを要求し、コンテンツを受信することを可能にする。例えば、インターネットは非被管理ネットワークであり、インターネットと通信中のユーザは、複数のソースのうちの１つからのコンテンツを受信するように選択することができ、インターネットサービスプロバイダ（ＩＳＰ）によって提供されるコンテンツによって限定されない。被管理ネットワークは、例えば、衛星ネットワーク、ケーブルネットワーク、およびＩＰテレビネットワークであってもよい。

図２８に示されるように、放送コンテンツは、被管理ネットワーク局２８０１によって１つ以上の指定されたチャネル上で衛星２８００にアップロードされる。チャネルは、別個の周波数であってもよく、あるいはチャネルは、デリミタ（すなわち、ヘッダ情報）によってまとめて関係付けられるデータの関連であってもよい。受信衛星２８００は、加入者によって選択され得る複数のチャネルを含む放送コンテンツを再伝送する。加入者宅の衛星受信機２８０２は伝送を受信し、セットトップボックス等のクライアントデバイス２８０３にその伝送を転送する。クライアントデバイスは衛星伝送を復号化し、加入者の表示デバイス２８０４上での視聴のために、選択されたチャネルを提供する。

放送された伝送の放送コンテンツ内には、１つ以上のトリガが存在する。トリガは、可能な双方向コンテンツの指示子である。例えば、トリガには、放送コンテンツ内に挿入されるか、または放送コンテンツを含有するフレームの一部であるかのいずれかである広告が付随してもよい。トリガは、１つ以上の映像フレームと関連付けられてもよく、１つ以上の映像フレームに対するヘッダ内に埋め込まれてもよく、アナログ伝送信号の一部であってもよく、または、放送コンテンツが伝送されるメディアに依存して、デジタルデータの一部であってもよい。広告に応答して、ユーザはリモコン等のユーザ入力デバイス（図示せず）を使用して、その広告に関係する双方向コンテンツを要求してもよい。他の実施形態において、トリガは自動的に双方向セッションを開始させ、コンテンツを受信するためのネットワークを被管理ネットワークと非被管理ネットワークとの間で切り替えさせる。それに応じて、クライアントデバイス２８０３は、衛星ネットワーク２８００からの放送コンテンツ２８０５の受信と、インターネット等の非被管理ネットワーク２８０６を介したコンテンツの受信および伝送とを切り替える。クライアントデバイスは、被管理ネットワークからの伝送を受信および復号化する単一のボックスを含んでもよく、また、非被管理ネットワークとの双方向通信も含んでもよい。したがって、クライアントデバイスは、２つの別個の受信機と、少なくとも１つの送信機とを含んでもよい。クライアントデバイスは、被管理ネットワークおよび非被管理ネットワークの両方に共有される単一プロセッサを有してもよく、またはクライアントデバイス内に別個のプロセッサがあってもよい。ソフトウェアモジュールが、２つのネットワーク間の切り替えを制御する。

このように、ソフトウェアモジュールは、両方のネットワークと通信する中心的な構成要素である。代替の実施形態では、２つのボックスが通信チャネルを含む、別個のクライアント復号化ボックスが、被管理ネットワークおよび非被管理ネットワークに利用されてもよい。例えば、２つのボックスは、ＩＰまたはＵＤＰプロトコルを介して通信してもよく、ここで、第１のボックスが第２のボックスに割り込みを送信するか、または出力抑制信号を送信してもよい。ボックスには、いつポート同士が接続され、２つのボックスともが接続を調整するかを認識する、ディスカバリエージェントを提供してもよい。通信チャネルは、２つのボックスが、ボックスの出力を切り替えることができるように通信することを可能にする。したがって、各ボックスは、ボックスがコマンドを送信し、もう一方のボックスの少なくとも出力ポートを制御することを可能にする、共通の通信プロトコルを使用して動作する。衛星ベースのシステムに関する本実施形態の説明は、例示目的であるに過ぎず、この説明は、被管理ネットワークおよび非被管理ネットワークの両方を含む実施形態に容易に適用され得ることを認識されたい。

ユーザが、クライアントデバイス２８０２に伝送を送信することによって双方向コンテンツを要求すると、クライアントデバイス２８０２はトリガを抽出し、非被管理ネットワークを通して処理局２８１０にトリガを伝送する。処理局２８１０は、ルックアップテーブル内の双方向コンテンツに関連するインターネットアドレスの検索か、クライアントデバイスから受信された伝送からのインターネットアドレスの抽出のいずれかを行なう。処理局は、インターネット２８３０を通して適切なコンテンツサーバ２８２０に要求を転送する。双方向コンテンツは処理局２８１０に戻され、処理局２８１０は、クライアントデバイス２８０３と互換性のある形式になるように双方向コンテンツを処理する。例えば、処理局２８１０は、上記で論議されたようなＭＰＥＧ映像ストリームとしてのそのコンテンツのステッチングをスケーリングすることによって、トランスコーディングを符号化してもよい。映像ストリームはその後、一連のＩＰパケットとして非被管理ネットワーク２８０６を介して処理局２８１０からクライアントデバイス２８０３へと伝送することができる。そのような実施形態では、クライアントデバイス２８０２は衛星デコーダを含み、また、非管理ＩＰネットワークを介して通信を送信および受信するためのポートも含む。要求された双方向コンテンツがクライアントデバイス２８０３によって受信されると、クライアントデバイスは、衛星放送チャネルの出力と、非被管理ネットワークを介して受信された双方向コンテンツの出力とを切り替えることができる。ある実施形態では、音声コンテンツは引き続き衛星伝送によって受信され、映像のみが衛星通信チャネルとＩＰ通信チャネルとの間で切り替えられてもよい。衛星伝送からの音声チャネルは、非管理ＩＰネットワークを通して受信される映像と混合される。他の実施形態において、音声および映像の両方の信号が、被管理ネットワークと非被管理ネットワークとの間で切り替えられる。

当業者には、トリガが広告に限定される必要はなく、他の形態の双方向コンテンツと関係し得ることを認識されたい。例えば、放送される伝送は、スポーツイベントを競技しているチームの統計に関する双方向コンテンツのユーザによる読み出しを可能にする、スポーツイベント中のトリガを含んでもよい。

いくつかの実施形態では、トリガが伝送内で識別されると、双方向セッションが自動的に確立され、上述のように２つ以上のソースからの双方向コンテンツがともにマージされる。次いで、双方向コンテンツが通信ネットワークを通してクライアントデバイスに提供され、復号化される。したがって、ユーザは、双方向セッションが確立される前にクライアントデバイスへの入力を提供する必要はない。

ある実施形態では、クライアントデバイスは、被管理ネットワークおよび非被管理ネットワークの両方からコンテンツを受信してもよく、一方からの情報をもう一方からの情報と置換してもよい。例えば、放送コンテンツは、広告用の識別可能な挿入ポイント（例えば、タイムコード、ヘッダ情報等）とともに被管理ネットワークを介して伝送されてもよい。放送コンテンツは挿入ポイントに広告を含有してもよく、クライアントデバイスは、放送される広告を被管理ネットワークを介して伝送される広告と置換することができ、ここで、クライアントデバイスは、被管理ネットワークと非被管理ネットワークとを広告の時間の間切り替える。

図２９は、クライアントデバイス２９０２が被管理ネットワーク２９００を通して放送コンテンツを受信し、かつ、非被管理ネットワーク２９０１を通して双方向コンテンツが要求および提供される、別の環境を示す。本実施形態では、処理局２９１０は、ケーブルシステム２９００を介して放送コンテンツを配信する。放送コンテンツは、複数の放送プログラムのうちの１つの選択に備えるセットトップボックス２９０２との対話に基づいて、ユーザによって選択可能である。放送プログラムのうちの１つ以上が、放送内（すなわち、放送と関連付けられるヘッダ内、デジタルデータ内、またはアナログ信号内）にトリガを含む。クライアントデバイス２９１０が放送信号を受信し、選択された放送コンテンツを出力すると、クライアントデバイス２９０２上で実行中のプログラムはトリガを識別し、一時バッファにトリガを保存する。放送プログラムの進行につれてトリガが変化する場合、クライアントデバイスはバッファを更新する。例えば、トリガは時間的有効期限を有してもよい。トリガは、映像コンテンツからのいくつかの映像フレームと関連付けられてもよく、したがって、時間的に制限され得る。他の実施形態において、トリガは処理局に送信され、そこで保存されてもよい。そのような実施形態では、各放送チャネルに対するトリガのうちの１つのコピーのみを保存する必要がある。

ユーザは、クライアントデバイス２９０２と通信するユーザ入力デバイス（すなわち、リモコン）を使用して、双方向コンテンツを要求してもよい。例えば、クライアントデバイスは、セットトップボックス、メディアゲートウェイ、またはビデオゲームシステムであってもよい。クライアントデバイスが要求を受信すると、クライアントデバイスは、トリガを保持する一時バッファにアクセスすることにより、その要求と関連付けられたトリガを識別する。トリガは単に、非被管理ネットワーク２９０１を通して処理局２９１０にアップストリーム転送される識別子であってもよく、あるいはトリガは、ルーティング情報（すなわち、ＩＰアドレス）を含有してもよい。クライアントデバイス２９０２は、クライアントデバイスの識別子とともにトリガを処理局に伝送する。処理局２９１０は双方向コンテンツのための要求を受信し、トリガ識別子を使用して、ＩＰアドレスのリストを含有するルックアップテーブルにアクセスするか、または、処理局がインターネット２９３０を通してコンテンツサーバ２９２０に位置する双方向コンテンツをＩＰアドレスに要求するかのいずれかを行う。クライアントデバイスと処理局との間で連結される非被管理ネットワークは、インターネットの一部とみなされてもよい。双方向コンテンツは、インターネット上のサーバまたはコンテンツサーバのいずれかから処理局に送信される。処理局は、双方向コンテンツをクライアントデバイスと互換性のある形式に処理する。双方向コンテンツは、ＭＰＥＧ映像ストリームに変換されて、処理局からクライアントデバイスへと複数のＩＰパケットとしてダウンストリーム送信されてもよい。ＭＰＥＧ映像ストリームはＭＰＥＧに準拠し、標準的なＭＰＥＧデコーダによって容易に復号化可能である。双方向コンテンツは１つ以上のソースから発生してもよく、コンテンツは、一連の映像フレームを形成するために再フォーマットされ、スケーリングされ、およびステッチングしてまとめられてもよい。双方向コンテンツは、静止要素、動的要素、ならびに静止要素および動的要素の両方を、双方向コンテンツを構成する１つ以上の映像フレーム内に含んでもよい。クライアントデバイス２９０２が双方向コンテンツを受信すると、クライアントデバイスは、被管理ネットワークから受信されている放送コンテンツを、非被管理ネットワークからの双方向コンテンツの受信へと切り替える。クライアントデバイス２９０２は受信された双方向コンテンツを復号化し、ユーザは、双方向コンテンツと対話することができ、処理局が、クライアントデバイスからコンテンツにおける変更に対する要求を受信する。要求に応答して、処理局はコンテンツを読み出し、コンテンツを映像ストリームとして符号化し、非被管理ネットワークを介してクライアントデバイスにコンテンツを送信する。

他の実施形態において、双方向セッションに対する要求を生じさせるトリガは、放送コンテンツの外部で生じてもよい。例えば、要求は、ユーザのリモコン等の入力デバイスとの対話に応答してもたらされてもよい。リモコンによって生成された信号はクライアントデバイスに送信され、クライアントデバイスは、被管理ネットワークを介した放送コンテンツの受信を、非被管理ネットワークを介した双方向セッションに対する要求を行うことへと切り替えることによって応答する。双方向セッションに対する要求は、通信ネットワークを介して処理局に伝送される。処理局はプロセッサを割り当て、プロセッサとクライアントデバイスとの間で接続が調整される。クライアントデバイスは、セットトップボックス、メディアゲートウェイ、消費者電子デバイス、または、インターネット等のネットワークを通して遠隔制御信号を伝送し、標準的なＭＰＥＧ符号化された映像ストリームを受信および復号化することができる他のデバイスであってもよい。処理局のプロセッサは、２つ以上のソースから双方向コンテンツを収集する。例えば、ＭＰＥＧオブジェクトを含むＡＶＭＬテンプレートを使用してもよく、ＭＰＥＧ映像コンテンツは、ローカルに保存されたソース、またはネットワーク接続を通して到達可能であるソースから読み出されてもよい。例えば、ネットワークはＩＰネットワークであってもよく、ＭＰＥＧ映像コンテンツは、インターネット内のサーバ上に保存されてもよい。割り当てられたプロセッサは、双方向コンテンツをステッチングしてまとめさせる。次いで、ステッチされたコンテンツは、ネットワーク接続を介してクライアントデバイスに伝送され、クライアントデバイスは、復号化して、復号化されたコンテンツを表示デバイスに提示する。

一実施例として、外付け式または内蔵型ＱＡＭチューナを含むテレビは、ケーブルテレビ放送信号を受信する。ケーブルテレビ放送信号は、１つ以上のトリガを含むか、あるいはユーザが入力デバイスを使用して要求信号を生成する。テレビは、ケーブルテレビ放送信号の復号化中にトリガを解析するか、または入力デバイスから要求を受信するかのいずれかを行い、その結果、インターネット（非被管理ネットワーク）に連結されるＩＰデバイスへの信号を生成させる。テレビは、ディスプレイへのケーブルテレビ放送信号の出力を抑制する。ＩＰデバイスは、インターネット接続上に位置する処理局との双方向セッションを要求することによって、トリガまたは要求信号に応答する、別個の外付けボックスであるか、またはテレビに内蔵型であってもよい。プロセッサが処理局によって割り当てられ、ＩＰデバイスと割り当てられたプロセッサとの間で接続が調整される。割り当てられたプロセッサは、２つ以上のソースから双方向コンテンツを生成し、ＭＰＥＧ基本ストリームを生成する。ＭＰＥＧ基本ストリームは、ＩＰデバイスに伝送される。次いで、ＩＰデバイスがＭＰＥＧ基本ストリームをテレビに出力し、テレビは、双方向コンテンツを復号化し、テレビのディスプレイに提示する。入力デバイスとのユーザによるさらなる対話に応答して、割り当てられたプロセッサによって、基本ストリームへの更新が達成され得る。ユーザがテレビ放送コンテンツに戻ることを決定するか、または双方向コンテンツが終了すると、テレビは、テレビコンテンツ放送信号の抑制を中止し、テレビ放送信号を復号化し、ディスプレイに提示する。したがって、システムは、トリガまたは要求信号の結果として、被管理ネットワークと非被管理ネットワークとの間で切り替え、ここで、双方向コンテンツ信号が、テレビから遠隔の場所で２つ以上のソースから生成される
当業者には、前述の実施形態が、衛星テレビシステムおよびケーブルテレビシステムに制限されず、本実施形態は、電話システムを使用するＩＰＴＶネットワーク等のＩＰＴＶネットワークにも等しく適用可能であることを認識されたい。そのような実施形態では、ＩＰＴＶネットワークが被管理ネットワークになり、非被管理ネットワークはインターネットへの接続（例えば、ＤＳＬモデム、無線インターネットネットワーク接続、Ｅｔｈｅｒｎｅｔ（登録商標）インターネット接続）となる。

本発明は、多くの異なる形態で具現化されてもよく、プロセッサ（例えば、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、または汎用コンピュータ）と併用するためのコンピュータプログラム論理、プログラマブル論理デバイス（例えば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または他のＰＬＤ）と併用するためのプログラマブル論理、個別の部品、集積回路（例えば、特定用途向け集積回路（ＡＳＩＣ））、あるいはそれらの任意の組み合わせを含む任意の他の手段を含むが、それらに決して限定されない。本発明の一実施形態では、主に、並べ換え論理はすべて、コンピュータ可読メディア内等に保存されるコンピュータ実行可能形態に変換され、かつ、オペレーティングシステムの制御下のアレイ内のマイクロプロセッサによって実行される、一式のコンピュータプログラム命令として実装されてもよい。

本明細書に前述した機能の全部または一部を実装するコンピュータプログラム論理は、種々の形態で具現化されてもよく、ソースコード形態、コンピュータ実行可能形態、および種々の中間形態（例えば、アセンブラ、コンパイラ、ネットワーカー、またはロケータによって生成される形態）を含むが、それらに決して限定されない。ソースコードは、種々のオペレーティングシステムまたはオペレーティング環境と併用するための種々のプログラミング言語（例えば、オブジェクトコード、アセンブリ言語、あるいはＦＯＲＴＲＡＮ、Ｃ、Ｃ＋＋、ＪＡＶＡ（登録商標）、またはＨＴＭＬ等の高水準言語）のいずれかに実装される一連のコンピュータプログラム命令を含んでもよい。ソースコードは、種々のデータ構造および通信メッセージを定義および使用してもよい。ソースコードは、コンピュータ実行可能形態（例えば、インタプリタを介して）であってもよく、あるいはソースコードは、（例えば、トランスレータ、アセンブラ、またはコンパイラを介して）コンピュータ実行可能形態に変換されてもよい。

コンピュータプログラムは、半導体メモリデバイス（例えば、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、またはフラッシュプログラマブルＲＡＭ）、磁気メモリデバイス（例えば、ディスケットまたは固定ディスク）、光学メモリデバイス（例えば、ＣＤ−ＲＯＭ）、ＰＣカード（例えば、ＰＣＭＣＩＡカード）、あるいは他のメモリデバイス等の有形記憶媒体内に永久もしくは一時的に、任意の形態（例えば、ソースコード形態、コンピュータ実行可能形態、または中間形態）で固定されてもよい。コンピュータプログラムは、種々の通信技術のいずれかを使用して、コンピュータに伝送可能な信号中に、任意の形態で固定されてもよく、アナログ技術、デジタル技術、光技術、無線技術、ネットワーク技術、およびネットワーク間通信技術を含むが、それらに決して限定されない。コンピュータプログラムは、付随の印刷されたまたは電子ドキュメント付きのリムーバブル記憶媒体（例えば、パッケージソフトウェアまたは磁気テープ）として任意の形態で配信されるか、コンピュータシステム（例えば、システムＲＯＭまたは固定ディスク上）にプリインストールされるか、あるいは通信システム（例えば、インターネットまたはワールドワイドウェブ）を介してサーバまたは電子掲示板から配信されてもよい。

本明細書に前述した機能の全部または一部を実装するハードウェア論理（プログラマブル論理デバイスと併用するためのプログラマブル論理を含む）は、従来の手動方法を使用して設計されてもよく、あるいは、コンピュータ支援設計（ＣＡＤ）、ハードウェア記述言語（例えば、ＶＨＤＬまたはＡＨＤＬ）、またはＰＬＤプログラミング言語（例えば、ＰＡＬＡＳＭ、ＡＢＥＬ、またはＣＵＰＬ）等の種々のツールを使用して、設計、キャプチャ、シミュレーション、もしくは電子的に文書化されてもよい。

本発明は、特に、特定の実施形態を参照して、図示および説明されたが、当業者は、添付の請求項によって規定されるように、本発明の意向および範囲から逸脱することなく、形態および詳細における種々の変更が実施形態において成され得ることを理解するであろう。当業者には明白であるように、パノラマに対する上述の技術は、非パノラマ画像としてキャプチャされた画像に適用されてもよく、その逆も然りである。

本発明の実施形態は、限定することなく、以下の請求項によって説明され得る。これらの実施形態は、プロセスステップによって、請求項に説明されたが、また、以下の請求項におけるプロセスステップを実行可能な、関連付けられたディスプレイを有するコンピュータを備える装置も、本発明に含まれる。同様に、以下の請求項におけるプロセスステップを実行するためのコンピュータ実行可能命令を含み、コンピュータ可読メディア上に保存される、コンピュータプログラム製品も、本発明内に含まれる。

Claims (9)

1. クライアントデバイスに圧縮映像コンテンツとして送信される映像コンテンツとの双方向性を可能にするシステムであって、前記圧縮映像コンテンツは、複数の合成映像フレームを含み、
   前記システムは、
   前記クライアントデバイスから離れて配置され、前記クライアントデバイスとの双方向セッションを制御し、前記圧縮映像コンテンツに含まれる第１の圧縮グラフィカル要素についての状態情報を保持するためのプロセッサと、
   前記プロセッサに応答して、周波数ドメインにおいて、少なくとも前記第１の圧縮グラフィカル要素と第２の圧縮グラフィカル要素を共にステッチングして新たな圧縮映像フレームを形成するステッチャと、を備え、
   前記状態情報は、前記第１の圧縮グラフィカル要素の状態を含み、前記状態は、前記第１圧縮グラフィカル要素に関して行われたユーザ入力操作に関連付けられ、
   前記プロセッサが、前記第１の圧縮グラフィカル要素の状態における変化を要求する信号を受信した場合に、前記プロセッサは、前記第１の圧縮グラフィカル要素の状態変化を示す新たな圧縮グラフィカル要素を取得し、前記ステッチャは、前記周波数ドメインにおいて、前記新たな圧縮グラフィカル要素を前記第２の圧縮グラフィカル要素にステッチすることにより、前記クライアントデバイスに送信される新たな圧縮映像コンテンツを定義する新たな合成映像フレームを形成することを特徴とする、システム。
2. 請求項１に記載のシステムであって、
   前記新たな圧縮映像コンテンツを、前記要求を行ったクライアントデバイスに送信する送信機をさらに備えたシステム。
3. 請求項１に記載のシステムであって、
   前記第１の圧縮グラフィカル要素は、１つ以上のＭＰＥＧ符号化映像フレームであるシステム。
4. 請求項１に記載のシステムであって、
   各々の圧縮グラフィカル要素は、ブロックベースの変換によって符号化されているシステム。
5. 請求項１に記載のシステムであって、
   前記第１の圧縮グラフィカル要素の状態は、前記第１の圧縮グラフィカル要素のオンまたはオフの状態を示す、システム。
6. 請求項１に記載のシステムであって、
   前記第１の圧縮グラフィカル要素の状態は、前記圧縮映像コンテンツ内の映像プログラムが再生されているか停止されているかを示す、システム。
7. 請求項１に記載のシステムであって、
   前記プロセッサは、前記第１の圧縮グラフィカル要素の状態の変化を要求する信号を受信した場合に、さらにスクリプトを実行する、システム。
8. 請求項７に記載のシステムであって、
   前記スクリプトは、
   前記圧縮映像コンテンツ内の映像プログラムが再生されているか停止されているかを判定することと、前記映像プログラムが再生されている場合には、前記映像プログラムの再生を停止する操作を実行し、前記映像プログラムが停止されている場合には、前記映像プログラムを再び再生する操作を実行することの指示を含む、システム。
9. 請求項１に記載のシステムであって、
   前記プロセッサは、前記第１の圧縮グラフィカル要素の状態の変化を要求する信号を受信した場合に、さらに外部プログラムの呼び出しを実行する、システム。