(57)【要約】  インタラクティブメディア環境において、複数のアプリケーションに入力イベントが分配され、各アプリケーションは０個以上のスクリプトコンポーネント及び０個以上のマークアップファイルを含み、ディスプレイ上の当該アプリケーションの視覚的要素の位置に対応するＺ順を有する（１６０８）。入力イベントの処理順が利用され、インタラクティブメディア環境での注目のアプリケーションには（ユーザイベントの受け取りのために）入力イベントを消費する最初の機会が与えられる（１６１４）。注目のアプリケーションが入力イベントを消費しない場合、入力イベントは上から下への逆Ｚ順で残りのアプリケーションに配信される（１６３２）。各アプリケーションは、入力イベントを消費するか、入力イベントを一層低いＺ順を有するアプリケーションに渡すか（１６０８）、入力イベントを一層低いＺ順を有するアプリケーションから隠すか（１６０８）、又は別のやり方で入力イベントを処理する機能によって動作可能化される。入力イベントの処理は、アプリケーション（１６３６）が入力イベントを消費するときに停止する。
2009500727.tif 000002
【特許請求の範囲】
【請求項１】
インタラクティブメディア環境において入力イベントを処理するための方法であって、
前記インタラクティブメディア環境において実行されている複数のアプリケーションのそれぞれに対するＺ順を維持するステップ（１６０８）であって、前記Ｚ順が表示上の視覚的要素の相対的な順序を示すステップと、
最高のＺ順から最低のＺ順に向かって適用することによって、注目のアプリケーションで始まり（１６１４）、残りのアプリケーションが続く（１６３２）よう、前記複数のアプリケーションに前記入力イベントを配信するステップと、
前記入力イベントがアプリケーションによって消費されると、イベントの処理を終了するステップ（１６３６）と
を含む方法。
【請求項２】
前記入力イベントが、ユーザイベント、システムイベント、ナビゲーションイベント及びアプリケーションイベントのうちの１つから選択される、請求項１に記載の方法。
【請求項３】
前記消費することは前記入力イベントを処理することを含む、請求項１に記載の方法。
【請求項４】
前記消費することは、前記入力イベントを処理することと、より低いＺ順を有するアプリケーションに前記入力イベントが配信されるように偽の消費の指示を返すこととを含む、請求項１に記載の方法。
【請求項５】
前記消費することは、前記入力イベントをより低いＺ順を有するアプリケーションから隠すために肯定的な消費の指示を返すこと以外の処理を含まない、請求項１に記載の方法。
【請求項６】
複数のアプリケーションが実行されているインタラクティブメディア環境において入力イベントを処理するための方法であって、
前記インタラクティブメディア環境において実行されている複数のアプリケーションのそれぞれに関するＺ順を維持するステップ（１６０８）であって、前記Ｚ順が前記アプリケーションに関する優先順位を示すステップと、
前記入力イベントに対する１つ又は複数のワークアイテム（５３５）をイベント待ち行列（５１５）に配置するステップと、
優先度順に前記入力イベントを前記イベント待ち行列から前記複数のアプリケーションに配信するステップ（１６１４、１６３２）と
を含む方法。
【請求項７】
マークアップ（１２０）が前記ワークアイテム（５３５）を配置する、請求項６に記載の方法。
【請求項８】
インタラクティブメディア再生システム（３０５、４０５）が前記ワークアイテム（５３５）を配置する、請求項６に記載の方法。
【請求項９】
前記１つ又は複数のワークアイテム（５３５）を配置することは、前記１つ又は複数のワークアイテム（７０５、７１５）を前記イベント待ち行列（５１５）に、マークを付けられたワークアイテムの後に挿入することを含む、請求項６に記載の方法。
【請求項１０】
一連のチックを使用して前記インタラクティブメディア環境において時間が計数され、前記挿入された１つ又は複数のワークアイテム（７０５、７１５）がチック毎に最後に処理される、請求項９に記載の方法。
【請求項１１】
前記入力イベントは、前記１つ又は複数のワークアイテム（５３５）を配置するアプリケーションとは異なるアプリケーションによって処理される、請求項６に記載の方法。
【請求項１２】
電子装置における１つ又は複数のプロセッサによって実行されるときに入力イベントを処理するための方法を実施するコンピュータ可読媒体であって、
前記方法が、
インタラクティブメディア環境内で実行されている複数のアプリケーションのそれぞれに対するＺ順を維持するステップ（１６０８）であって、前記Ｚ順が表示上の視覚的要素の相対的な順序を示すステップと、
最高のＺ順から最低のＺ順に向かって適用することによって、注目のアプリケーションで始まり（１６１４）、残りのアプリケーションが続く（１６３２）よう、前記複数のアプリケーションに前記入力イベントを配信するステップと、
アプリケーションが前記入力イベントを捕捉することを可能にするステップ（１６１７）と
を含むコンピュータ可読媒体。
【請求項１３】
前記入力イベントを捕捉するアプリケーションが前記入力イベントを処理する、請求項１２に記載のコンピュータ可読媒体。
【請求項１４】
前記入力イベントを捕捉するアプリケーションが前記入力イベントを消費する、請求項１２に記載のコンピュータ可読媒体。
【請求項１５】
前記入力イベントが消費される場合にフラグが返される、請求項１４に記載のコンピュータ可読媒体。
【請求項１６】
アプリケーションオブジェクトが前記入力イベントを処理する、請求項１２に記載のコンピュータ可読媒体。
【請求項１７】
アプリケーション内での入力イベントの処理が、前記アプリケーション及びマークアップオブジェクトが前記アプリケーションオブジェクトを最上位にして単一のＤＯＭ内にあるかのように進む、請求項１６に記載のコンピュータ可読媒体。
【請求項１８】
スクリプトが前記入力イベントを最初に処理し、その後にマークアップを処理する、請求項１２に記載のコンピュータ可読媒体。
【請求項１９】
前記入力イベントがマークアップによって処理されない場合、前記入力イベントがアプリケーションオブジェクトを通して上に移動する、請求項１８に記載のコンピュータ可読媒体。
【請求項２０】
前記入力イベントに合うアクセスキー属性をマークアップが含む場合に前記マークアップが前記入力イベントを受け取る、請求項１２に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の申告）
本出願は、参照により本明細書に援用される２００５年７月１日に出願された米国仮出願第６０／６９５，９４４号の利益を主張するものである。
【０００２】
技術分野
記載の構成、システム及び方法は、概してインタラクティブメディアに関し、より具体的には、インタラクティブメディア環境における複数のアプリケーションへの入力イベントの配信に関する。
【０００３】
背景技術
典型的には、インタラクティブメディア環境は、利用可能な処理能力、メモリ、及び、当該環境において実行されているアプリケーションが利用可能なその他のリソースに関してリソース制限される。インタラクティブメディアの１つの一般的な例は、ＤＶＤ上に符号化されたビデオであり、ユーザは、特定のビデオコンテンツへナビゲートし又はＤＶＤ（デジタルバーサタイルディスク）にオーサリングされる特別な機能を呼び出すためにグラフィカルなメニュー又は他の制御と対話することができる。
【０００４】
典型的なインタラクティブメディア環境において、グラフィックス及びメニューなどの視覚的要素には、表示スクリーン上の要素に関する視覚的な順序を提供する「Ｚ順」が与えられる。Ｚ順は、表示スクリーンから外に向かって伸びる架空のｚ軸に沿って視覚的要素が互いにどのように積み重なって見えるのかを制御する。より低いＺ順を有する視覚的要素は表示の後ろの方に（見ている人から遠くに）あるように見え、一方、高いＺ順を有する視覚的要素は低いＺ順を持つ要素の上に（したがって見ている人の近くに）あるように見える。
【０００５】
視覚的要素を生成するために使用される複数のアプリケーションがインタラクティブメディア環境において実行されているとき、入力イベントがアプリケーションに配信されなければならない。入力イベントはリソース効率の良いやり方で処理されなければならない。さらに、アプリケーションは、ユーザに対して豊かなインタラクティブな経験を動的にもたらすように、環境からの入力に応答してグラフィカルな出力を生成することを可能にされなければならない。
【０００６】
概要
インタラクティブメディア環境において、入力イベントが複数のアプリケーションに配信される。各アプリケーションは、０個以上のスクリプトコンポーネント及び０個以上のマークアップファイルを含み、表示上のアプリケーションの視覚的要素の位置に対応するＺ順を有する。入力イベントの処理順が利用され、（アプリケーションのユーザイベントの受け取りのために）注目されるアプリケーションに、入力イベントを消費する最初の機会が与えられる。注目されるアプリケーションが入力イベントを消費しない場合、入力イベントは上から下へ逆Ｚ順で残りのアプリケーションに配信される。各アプリケーションは、入力イベントを消費するか、入力イベントをより低いＺ順を有するアプリケーションに渡すか、入力イベントをより低いＺ順を有するアプリケーションから隠すか、又は別のやり方で入力イベントを処理する機能によって動作可能化される。入力イベントの処理は、アプリケーションが入力イベントを消費するときに停止する。
【０００７】
有利なことに、優先度順の（すなわち、注目されるアプリケーションの後に残りのアプリケーションが逆Ｚ順で続く順番の）入力イベントの配信は、最もインタラクティブなアプリケーションを優先させるので、プロセッササイクル及びメモリを含むハードウェアリソースが制限される環境において入力イベントは効率的に処理される。さらに、インタラクティブメディアの作者が応答性の高いインタラクティブな動作を有するアプリケーションを作成することができる予測可能なプラットフォームが提供される。
【０００８】
詳細な説明
図１を参照すると、インタラクティブメディア環境において使用されるアプリケーション１１０を構成する要素の例示的なブロック図が示される。典型的には、アプリケーションは、結合された表示装置（テレビジョン又はモニタなど）上にグラフィックス及びビデオをレンダリングするインタラクティブメディアプレーヤとユーザとの間の対話をリモコンなどのユーザインターフェースを通じて可能にするためにインタラクティブメディア環境において使用される。より詳細には、アプリケーションは環境において、ビデオの再生を含む、様々なコンテンツオブジェクトの表示動作を制御する。ビデオ上のメニュー及びインタラクティブなボタンなどのグラフィックオブジェクトの表示もアプリケーションを使用して実現される。さらに、アプリケーションは、環境におけるオーディオの再生とサウンドを管理し制御する。概して、多くのインタラクティブメディアの設定において複数のアプリケーションが同時に実行されていることになることが考えられる。しかし、複数のアプリケーションが同時に実行される必要はなく、特定の設定においてアプリケーションを分割するか、集約するかの判断は、インタラクティブメディアの作者の設計上の選択である。アプリケーションは、具体的な設定要件に応じてアプリケーションページに論理的にさらに分割されることもできる。
【０００９】
アプリケーション１１０は、０個以上のスクリプトファイル１１７及び１１９を含むスクリプトホスト１１５と、ドキュメントオブジェクトモデル（ＤＯＭ）を生成するために使用される０個以上のマークアップドキュメント１２０とを含む。マークアップドキュメント１２０は、例えば、グラフィックオブジェクトのコンテンツ、スタイル、タイミング及びレイアウトに関する情報を含む。したがって、マークアップコンテキストは、概して、インタラクティブメディア環境のグラフィックス平面上にグラフィックスを提供するために使用される。
【００１０】
この例示的な例において、マークアップドキュメントは、Ｗ３Ｃ規格に準じたＸＭＬドキュメントファイルである。図１に示すように、複数の物理的なＸＭＬファイルは、マークアップの＜ｈｅａｄ＞セクション内の＜ｉｎｃｌｕｄｅ＞要素を使用してアクセスされることができる。いくつかの設定において、アプリケーションは２つ以上のアクティブなマークアップを一度に持たないことが好ましいことがある。しかし、アプリケーションは、マークアップでの＜ｌｉｎｋ＞要素を使用することによって、そのマークアップ１２０を切り換えることができる。代替として、アプリケーションは、そのときのアプリケーション内の機能オブジェクトにアプリケーションがアクセスすることを可能にするアプリケーションプログラミングインターフェース（ＡＰＩ）を利用することによって、そのマークアップ１２０を切り換えることができる。ＡＰＩを介するｌｏａｄＭａｒｋｕｐ（）呼び出しを使用して、アプリケーションは、ＡＰＩを通じて新しいマークアップのユニフォームリソースアイデンティファイア（ＵＲＩ）を渡すことによって、マークアップファイル１２０を切り換えることができる。
【００１１】
アプリケーションが新しいマークアップにアクセスする場合、ＡＰＩ呼び出しは、アプリケーションでのそのときのイベントハンドラがそのときのタスクを実行し終わった後でのみ実施される。保留中の任意のそのときのマークアップ関連イベントハンドラは、新しいマークアップがロードされてそれらのイベントハンドラを無効化すると、キャンセルされる。
【００１２】
この例示的な例において、スクリプトホスト１１５は、インタラクティブメディア体験を実現するためにマークアップ１２０と共に使用されるスクリプトファイル１１７及び１１９を含む。スクリプトファイル１１７及び１１９は、例えば、ＥＣＭＡ−２６２仕様においてＥｃｍａ  Ｉｎｔｅｒｎａｔｉｏｎａｌによって定義されたＥＣＭＡＳｃｒｉｐｔを使用して実装されることができる。ＥＣＭＡ−２６２に分類される一般的なスクリプトプログラミング言語はＪａｖａＳｃｒｉｐｔ及びＪＳｃｒｉｐｔを含む。いくつかの設定においては、ＥＣＭＡＳｃｒｉｐｔ２６２のサブセット、特にＥＣＭＡ−３２７をホスト環境及び１組の共通ＡＰＩと共に使用してスクリプト１１７及び１１９を実行することが望ましい。多くの設定におけるスクリプトコンテキストは、システムイベント、グラフィックスの制御、ビデオの再生、リソースの管理（例えば、キャッシュ又は永続的な記憶リソースの使用）、及びマークアップ１２０のみを使用することによっては容易に又は効率的に実施されないその他の問題と共に、ユーザからのインタラクティブな制御の問題を扱うために利用される。
【００１３】
図１において、アプリケーション１１０に対するＡＰＩ及びリソースの可用性が参照番号１２５によって示される。リソースは、例えば、オーディオ及びビデオファイルと、フォントと、（例えば、ＰＮＧ、ＪＰＥＧ、ＧＩＦ、ＢＭＰ、ＴＩＦＦなどの一般的なファイルフォーマットの）ピクチャ及びイメージと、具体的な設定の状況に応じてアプリケーションによって要求され得るその他のリソースとを含む。
【００１４】
各アプリケーション１１０は、スクリプトの変数、関数及びその他の状態に関するコンテキストを維持する独自のスクリプトホスト１１５を維持する。多くの設定において、１つのアプリケーションでの変数及び関数は、例えば、全てのアプリケーション間で共有されるオブジェクトを使用することによってアプリケーション間での可視性を可能にするようにアプリケーションが特に構成されていないならば、別のアプリケーションからは見えない。例えば、この例示的な例において、インタラクティブメディアプレーヤオブジェクトは、全てのアプリケーションによって共有される単一のインスタンスを有する。したがって、オプションとして、特別なオブジェクトが例えばＣ＋＋オブジェクトを使用してスクリプトホスト１１５内に配置され、特別なオブジェクトの全ては例えばプレーヤの同じ内部関数を参照するシングルトン（すなわち、インスタンス化が制限されているオブジェクト）を実装する。このオプションの態様は、オブジェクトを単一のスクリプトホストに提示するために必要な機能をスクリプトホスト１１５が実行することを可能にしながら、インタラクティブメディアスクリプトの作者が共通オブジェクトを論理的にシングルトンとして扱うことを可能にする。
【００１５】
ここで図２を参照すると、複数のマークアップドキュメントとスクリプトとの間の関係を示す例示的な図が提供される。上記のとおり、アプリケーションマニフェスト２３０は、上述のようにリソース１２５、スクリプト２０５及びマークアップドキュメント２５１、２６０、２７５によって一般に定義されるアプリケーションと対話する。典型的には、各アプリケーションは、多くの設定において、単一のアプリケーションマニフェストファイルを使用するが、アプリケーションマニフェストはアプリケーションのランタイム状態の一部ではない。この例示的な例において、アプリケーションマニフェスト２３０はＸＭＬドキュメントファイルとして符号化される。
【００１６】
アプリケーションマニフェスト２３０は、アプリケーション１１０によって使用されるべき初期マークアップファイル２５１（図１）と、スクリプトホスト１１５に含まれる（図２において参照番号２０５を有する長方形によって集合的に示される）スクリプトファイルとを記述する。この例示的な例におけるように、アプリケーションマニフェスト２３０が２つ以上のスクリプトを列挙する場合、全てのスクリプトがインタラクティブメディアプレーヤのスクリプト処理エンジンにロードされる。こうして、複数のスクリプトファイルは、アプリケーションマニフェスト２３０に列挙された順番で、スクリプトの作者が全てのスクリプトファイルを単一の大きなファイルに連結したかのように扱われて動作する。
【００１７】
図２に示すように、アプリケーションマニフェスト２３０はリソース１２５を参照する。インタラクティブメディア環境においてアプリケーションが利用可能なリソースは、アプリケーションマニフェスト２３０において参照されるリソース１２５を根とする有向グラフを形成する。各アプリケーションに関するグラフの許容範囲は、アプリケーションマニフェスト２３０によって規制される。
【００１８】
図２は、インタラクティブメディア環境において動作しているアプリケーションを示す。上述のように、アプリケーションは１度に１つのアクティブなマークアップのみを有することができ、アプリケーションのコンテンツはアプリケーションによって別々に保たれる。マークアップページ２５１、２６０、２７５の間の矢印によって示されるように、スクリプト２０５を介して、アプリケーションはマークアップページ２５１から２６０に進むことができ、次いでページ２６０から２７５に進むことができる。
【００１９】
インタラクティブメディア環境におけるアプリケーションによるコンテキストの実行の進行は、プレーヤによってディスプレイデバイス上にレンダリングされる表示オブジェクトを含む環境内のオブジェクト間の関係を特に記述するプレイリスト２９０によって導かれる。典型的には、これらの表示オブジェクトは、（以下で詳細に説明するように、複数のストリームを含むことができる）ビデオと、アプリケーションによって生成されるグラフィックスとを含む。
【００２０】
さらに、プレイリスト２９０は、アプリケーションによるリソースの消費を効率的に割り当てて制御するために、インタラクティブメディア環境でのリソースを単一の管理エンティティとして管理する。アプリケーションマニフェスト２３０と同様に、プレイリスト２９０は、有利なことに、多くの設定においてＸＭＬドキュメントファイルとして具現化されることができる。
【００２１】
図２のマークアップページは、（図１のスクリプトファイル１１７及び１１９によって生成された）実行コンテキストにイベントを発行するために、いくつかの設定において使用されることができる。次いで、実行コンテキストは、そのときのアプリケーションのマークアップによって生成されたＤＯＭを操作する。（図２において要素２５３、２６２、２７７によって表されるように）環境においてグラフィカルオブジェクトのスタイル、コンテンツ、タイミング及びレイアウトを指定するためにインタラクティブメディア環境においてマークアップが使用されるとき、スクリプトとマークアップとの組合せが包括的な機能の組の生成を可能にする。
【００２２】
図３は、インタラクティブコンテンツプロセッサ（ＩＣＰ）３３５、ビデオコンテンツプロセッサ（ＶＣＰ）３１０及びミキサ３３９を含む第１の例示的なインタラクティブメディアプレーヤ３０５のブロック図である。留意されるように、図３において示される構成は、アプリケーションの状態管理に関する例示的なインタラクティブメディアプレーヤ３０５の特徴及び機能を記述する論理的なモデルを提供する。したがって、インタラクティブメディアプレーヤの実際の実装は、アプリケーションの状態管理の利点を実現するために本明細書において説明されるように動作しながら、様々な構造的形態を利用することができる。典型的には、インタラクティブメディアプレーヤ３０５は、スタンドアロンの家庭用電子機器などの専用ハードウェアで実現され、又は代替として、パーソナルコンピュータに見られる汎用プロセッサなどの汎用プロセッサと共にコンピュータ可読媒体を使用するソフトウェア実装を使用して実現される。
【００２３】
ＶＣＰ３１０は、ＤＶＤドライブ又は高精細ＤＶＤ（ＨＤ−ＤＶＤ）ドライブなどのローカルの光学式ドライブ、ローカルのメモリ或いはネットワーク上のリモートのブロードバンドソースを含む複数のソースから受信されることができる１つ又は複数のメディアストリームを管理する。この例示的な例において、ＶＣＰ３１０は、図３において要素３０４及び３０６によって示される１つ又は複数のメディアプロセッサ１、２、・・・、Ｎを含む。メディアプロセッサ３０４及び３０６は、典型的にはオーディオ及びビデオを含む受信メディアストリームを処理し、対応するイメージ及び音声をデコード及びレンダリングして、ライン３２５上にオーディオ／ビデオストリームとして出力する。オーディオ／ビデオストリーム３２５は、例えば、「ピクチャインピクチャ」タイプの構成を使用して複数の別個のビデオウィンドウをレンダリングするように、複数のビデオ要素を表示することができる。
【００２４】
メディアプロセッサ３０４及び３０６は、それぞれメディアソースインターフェース、デマルチプレクサ及びデコーダを含む。メディアプロセッサ３０４及び３０６はオプションとしてデクリプト機能をも含むことができる。表示装置３５５がオーディオ／ビデオストリームを受信及び表示するために結合される。
【００２５】
各受信メディアが関連する「メディア時間」を持つように、メディアクロック３１２が利用される。ビデオストリームがインタラクティブメディアプレーヤ３０５上で一時停止されると、メディアクロック３１２も一時停止される。ビデオストリームがユーザによって実時間よりも速く又は遅く進むように設定されるとき（例えば、ビデオが早送り、巻き戻し又はスローモーションモード（これらのモードのうちのいずれかを使用することは「トリック再生」と呼ばれる）にされるとき）、メディアクロック３１２はそれに応じて速さを上げ又は下げる。したがって、メディア時間はメディアクロックとメディアプロセッサ３０４及び３０６の動作とから導出される。メディア時間は、ライン３１５を介してＩＣＰ３３５のプレイリストマネージャ３３７に渡される。典型的には、メディア時間を含むインタラクティブメディア環境での時間は「チック」を単位として計数される。
【００２６】
ＩＣＰ３３５は全てのアプリケーションに関連する処理を実行し、ハードウェア、ソフトウェア、ファームウェア又はそれらの組合せで実現されることができる複数のコンポーネントから構成されることができる。ＩＣＰ３３５のコンポーネントは、例えば、マークアップエンジン、スクリプト言語インタープリタ及びＸＭＬ構文解析コンポーネント（図示せず）を含む。ＩＣＰ３３５は、オーディオ／ビデオストリーム３２５と同期しているグラフィックスストリームをライン３２１上に出力する。ユーザに対するインタラクティブメディアセッションを実行するためにグラフィックスがビデオストリーム上のグラフィックスレイヤにレンダリングされるように、ミキサ３３９はライン３２１上のグラフィックスストリームとライン３２５上のオーディオ／ビデオストリームとを取得する。
【００２７】
多くの設定において、ＩＣＰ３３５は、フレーム単位でビデオストリームと同期されるグラフィックスを出力する。しかし、そのような同期は、例えば、（以下で定義されるタイトル時間及びメディア時間を含む）時間、ビデオのコンテンツ、又は、ストリームでの特定の時点を示す又はマークするために使用されるビデオに埋め込まれたその他のメタデータを含むその他の基準を使用して実行されることができる。
【００２８】
ＩＣＰ３３５は、プレイリストマネージャ３３７及びタスクマネージャ３３０を含む。プレイリストマネージャ３３７は環境での表示オブジェクトを制御する役割を担う。これらのオブジェクトは、インタラクティブなグラフィックスを生成するために実行されているアプリケーションと、プレーヤ３０５上でのビデオ再生とを含む。プレイリストマネージャ３３７は、図２に付随する本文において上述したプレイリスト２９０を管理する。
【００２９】
また、プレイリストマネージャ３３７は、メディアストリームのコンテンツの各部に関連する「タイトル時間」を計算する。タイトルは、典型的にはＤＶＤの作者によって定義される開始及び終了時間を有するビデオ及びオーディオコンテンツの一意的なシーケンスである。しかし、そのような作者が何をタイトルとして定義するかは任意である。したがって、ビデオにおいて知覚される特定のコンテンツは、１つのタイトルの一部であったり、完全なタイトルであったり、複数のタイトルに渡ったりする。
【００３０】
タイトルの一例は、米国におけるアナログ又はデジタルのフォーマットでの全ての予め記録されたビデオに先立つ著作権警告である。ＤＶＤ上の特色となる呼び物（例えば、メインムービー）は別の例であり、多くの場合、最も長いタイトルである。いくつかの設定において、映画の個々のチャプタが、ＤＶＤの作者によってタイトルを分けるように指定され得る。全てのそのようなタイトルに対して、タイトル時間が、メディアクロック３１２上に示される、所与のタイトルが再生を開始してからの経過時間として定義される。
【００３１】
プレゼンテーションクロック３６０が、ライン３６２上でプレイリストマネージャに結合される。プレゼンテーションクロック３６０は、実世界の時計と同じ速さでクロック時間が変わるクロックである（すなわち、プレゼンテーションクロック３６０が１秒進むのに１秒の実時間を要する）。メディアクロック３１２と対称的に、プレゼンテーションクロック３６０は停止することはなく、速くされることも遅くされることもできない。プレゼンテーションクロック３６０からのプレゼンテーション時間が、当該プレゼンテーション時間を使用して「アプリケーション時間」及びアプリケーションの「ページ時間」を計算するタスクマネージャ３３０に渡される。
【００３２】
アプリケーション時間は、アプリケーションが開始してからの（又は、以下で一層詳細に説明されるように「アクティブ」状態になってからの）経過時間である。複数のアプリケーションが実行されているとき、各アプリケーションはそのアプリケーション独自のアプリケーション時間の概念を有する。各アプリケーションに対して、アプリケーション時間は、アプリケーションが環境において開始されるときに必ず０から始まる。
【００３３】
例えば、アプリケーションＡｐｐ１が任意の２０時間単位のプレゼンテーション時間において開始し（これがＡｐｐ１に対して０時間単位である）、アプリケーションＡｐｐ２が２５時間単位のプレゼンテーション時間において開始する（これがＡｐｐ２に対して０時間単位である）場合、３５時間単位のプレゼンテーション時間において、Ａｐｐ１のアプリケーション時間は１５時間単位であり、Ａｐｐ２のアプリケーション時間は１０時間単位である。論理的に更にページに分割されるアプリケーションに対しては、ページ時間は、アプリケーションのページがロードされてからの経過時間である。
【００３４】
図４は、ＩＣＰ４３５、ＶＣＰ４１０及びミキサ４３９を含む第２の例示的なメディアプレーヤ４０５のブロック図である。インタラクティブメディアプレーヤ４０５は形態及び機能の点で図３に示すインタラクティブメディアプレーヤ３０５と類似している。しかし、特に、ＶＣＰ４３５は、ミキサ４３９に別々のフィード４２５及び４２７を行うように構成される（図４において要素４０４及び４０６によって示される）メディアプロセッサ１、２、・・・、Ｎを含む。そのような構成は、個々のメディアストリームの操作がミキシングの前に実行される一部の設定においては望ましい。例えば、図４において参照番号４２５及び４２７で表されるＮ個の別々のフィードのうちの１つ又は複数に対して、メディアストリーム内のビデオのパン及びズームなどの画像処理／選択技術が個々に実行されることができる。
【００３５】
オーディオ／ビデオフィード４２５及び４２７は、ＩＣＰ４３５からの同期グラフィックスストリームと共にミキサ４３９でミキシングされ、表示装置４５５へのライン４４１上に出力される。（プレイリストマネージャ４３７及びタスクマネージャ４３０を含む）ＩＣＰ４３５と、ＶＣＰ４１０におけるメディアクロック４１２と、プレゼンテーションクロック４６０とを含む図４のその他の要素は、図３に図示され且つ付随する本文において説明された、それらの要素の対応物と同様に構成され且つ機能する。
【００３６】
図５は、それぞれ参照番号５１０、５１５及び５１８で示される複数のイベント待ち行列１、２、・・・、Ｎと、単一のアプリケーションスレッド５２３とを有する例示的な配置５００のブロック図である。この例示的な配置において、（図４のＩＣＰ４３５などの）ＩＣＰ上で実行されている全てのアプリケーションはシングルスレッド化され、アプリケーションスレッド５２３はそのような目的に供される。しかし、ＩＣＰ４３５は必ずしもそれ自体がシングルスレッド化される必要はない。代替的な実装において、ＩＣＰ４３５は、例えば、リソースをキャッシュにプリフェッチするために、他のスレッドを利用することができる。
【００３７】
イベント待ち行列５１０、５１５及び５１８のそれぞれは、それらの待ち行列の（図５の右側に位置する）ヘッドエンドからアプリケーションスレッド５２３にフィードするように構成される。それぞれ参照番号５２７、５３０及び５３２で示される複数のアプリケーションＡｐｐ１、Ａｐｐ２、・・・、ＡｐｐＮは、代表として参照番号５３５によって示されるワークアイテムを待ち行列の（図５の左側の）テールエンドから待ち行列５１０、５１５及び５１８に配置するように構成される。
【００３８】
アプリケーションイベントは、アプリケーションによって発火されるイベントである。これらは、スクリプト（例えば、図１のスクリプトホスト１１５）によって又はマークアップ（例えば、図１のマークアップ１２０）によって発火されるイベントを含む。多くのシナリオにおいて、アプリケーションイベントはスクリプトによってのみ処理される。しかし、アプリケーション５２７、５３０及び５３２は、スクリプト又はマークアップ機能を直接には呼び出さない。その代わりに、全てのそのような機能はアプリケーションのそれぞれのイベント待ち行列にワークアイテムの形態で配置され、それらのワークアイテムはアプリケーションスレッド５２３が当該ワークアイテムを処理するときに呼び出される。
【００３９】
代替の構成において、アプリケーション以外のソースからのイベントが、イベント待ち行列を使用して同様にスケジューリングされる。例えば、ユーザイベントが、リモコンを用いたユーザインタラクションによって発火される。システムイベントは、図４に示され且つ付随する本文において説明されたプレーヤ４０５などのインタラクティブメディアプレーヤによって発火されるイベントであり、例えば、ビデオタイトルにおけるチャプタ変更を含む。
【００４０】
イベント待ち行列５１０、５１５及び５１８における各ワークアイテムは、図５に示されるフィールドを含む。これらのフィールドは、アプリケーション関連付けフィールド５４０、メソッドフィールド５４５、開始時間フィールド５５２、終了時間フィールド５５５及びオプションのクロックセレクタフィールド５５８を含む。
【００４１】
アプリケーション関連付けフィールド５４０は、ワークアイテムが適用される特定のアプリケーションを示す。メソッドフィールド５４５は、ワークアイテムがアプリケーションスレッド５２３によって処理されるときに呼び出されるメソッドを含む。メソッドフィールド５４５はメソッドに対する引数も含む。
【００４２】
開始時間フィールド５５２及び終了時間フィールド５５５は、ワークアイテムのメソッドが何時開始するか及び何時終了するかを示すためにそれぞれ使用される。この例示的な例において、時間はアプリケーション時間を使用して表される。しかし、代替の例においては、開始時間フィールド５５２及び終了時間フィールド５５５は、特定の設定の要件に応じて、代りにタイトル時間、アプリケーション時間又はページ時間で表されることができる値を含む。そのような場合、ワークアイテムによって使用される特定のタイムフレームがクロックセレクタフィールド５５８に示される。利用されるタイムフレームに無関係に、ワークアイテムに関する開始時間は必ず終了時間より前でなければならない。
【００４３】
図６は、イベント待ち行列５１５に含まれるワークアイテムの順序付けを示すイベント待ち行列５１５のブロック図である。その他のイベント待ち行列５１０及び５１８（図５）は、説明を分かり易くするために図６には示されない。しかし、以下で説明される順序付けの方法は、そのようなその他のイベント待ち行列にも等しく適用可能である。
【００４４】
イベント待ち行列５１５は、それぞれ参照番号６０５、６１０、６１５及び６２０によって示されるワークアイテム１、２、３、・・・、Ｎを含む。各ワークアイテムは、図５に示され且つ付随する本文において説明されたフィールドを含む。
【００４５】
ワークアイテム６０５は、図６のブロック６３０に示されるように、開始時間１とイベント待ち行列５１５への関連する挿入時間ｔ１とを含む。同様に、ワークアイテム６１０は、ブロック６３５に示されるように、開始時間２とイベント待ち行列５１５への関連する挿入時間ｔ２とを含む。ワークアイテム６１５は、ブロック６４０に示されるように、開始時間３とイベント待ち行列５１５への関連する挿入時間ｔ３とを含む。また、ワークアイテム６２０は、ブロック６４５に示されるように、開始時間Ｎとイベント待ち行列５１５への関連する挿入時間ｔＮとを含む。
【００４６】
この例示的な例において、ワークアイテムは、まず開始時間によって、次いで、ワークアイテムがイベント待ち行列に挿入される時間によって、イベント待ち行列５１５において順序付けられる。そのような順序付けは、開始時間の順序で、又は２つのワークアイテムが同じ開始時間を有するときにはＦＩＦＯ（ファーストイン、ファーストアウト）順でワークアイテムを処理するアプリケーションスレッド５２３を生じる。
【００４７】
したがって、ワークアイテム６２０はイベント待ち行列５１５のヘッドにあるので、その意味は、開始時間Ｎ＜開始時間３であり、又は、開始時間Ｎ＝開始時間３ならばｔＮ＜ｔ３である（すなわち、ワークアイテム６２０はワークアイテム６１５よりも前にイベント待ち行列５１５に挿入された）。ワークアイテム６０６、６１０及び６１５に対してこの同じ推論に従うと、
開始時間３＜開始時間２；
又は、開始時間３＝開始時間２ならば、ｔ３＜ｔ２；
開始時間２＜開始時間１；
又は、開始時間２＝開始時間１ならば、ｔ２＜ｔ１。
【００４８】
イベント待ち行列でのワークアイテムの順序付けは２つの代替方法で実行される。すなわち、ワークアイテムは、イベント待ち行列に挿入されるとき、又は処理の前にワークアイテムがイベント待ち行列から取り出されるときに順序付けられることができる。いずれの構成も、イベント待ち行列からのワークアイテムの処理が開始時間とその後の待ち行列挿入時間とによって実行される限り、等しく利用可能である。
【００４９】
図７は、アプリケーションスレッド５２３が２つのワークアイテム７０５及び７１５をイベント待ち行列５１５の最後尾に自動的に挿入する例示的な構成のブロック図である。その他のイベント待ち行列５１０及び５１８（図５）は、説明を分かり易くするために図７には示されない。しかし、以下で説明されるアプリケーションスレッドによるワークアイテムの自動挿入は、そのような他のイベント待ち行列にも等しく適用可能である。図示されるように、自動的に挿入されるワークアイテム７０５及び７１５は、イベント待ち行列５１５においてワークアイテム６０５及び６２０の後に続く。例示的な例において、２つのワークアイテムの自動挿入はアプリケーションが開始するときに実行され、ワークアイテムは各チック後に再スケジューリングされる。
【００５０】
ワークアイテム７０５は、ブロック７３０に示すように、アプリケーションＡｐｐ２  ５３０でのページに対するタイミングを処理するためのマークアップエンジン（例えば、図４においてＩＣＰ４３５に配置されるマークアップエンジン）に対する呼び出しを含む。ブロック７３５において、ワークアイテム７１５は、処理されたイベントを反映するようアプリケーションＡｐｐ２のマークアップをリフローし、次いでマークアップを表示装置（例えば、図４の表示装置４５５）上にレンダリングするための、マークアップに対する呼び出しを含む。ワークアイテム７０５及び７１５は常に、アプリケーションスレッド５２３によってアプリケーションのチックにおいて処理される最後のワークアイテムである。
【００５１】
図８は、インタラクティブメディア環境において発生するイベントに関連するワークアイテムを待ち行列に入れるための方法の流れ図である。単一のアプリケーションスレッドを用いたイベント待ち行列化の例示的な例において、方法は、図４〜図７に示され且つ付随する本文において説明された構成によって実行される。典型的には、方法は、チック毎に繰り返し実行される。
【００５２】
プロセスはブロック８０５において開始する。ブロック８１０において、アプリケーションスレッド５２３（図５〜７）がワークアイテムを処理するために空いているとき、アプリケーションスレッド５２３は最初に、開始時間がそのときの又は以前のチックに対応する、イベント待ち行列５１５での各ワークアイテムにマークを付す。アプリケーションスレッド５２３は、マークを付けられたワークアイテムのみを処理することになる。したがって、イベント待ち行列５１５でのワークアイテムは、そのワークアイテムの開始時間より前に処理されることはない。
【００５３】
判断ブロック８１６において、マークを付けられたワークアイテムの終了時間が既に過ぎている場合、ブロック８１９に示されるように、ワークアイテムはイベント待ち行列５１５から削除される。そのような場合、そのワークアイテムに対するいかなる処理も実行されない。アプリケーションＡｐｐ２  ５３０がそのページをリロードするならば、アプリケーションのページのクロックが０にリセットされ、当該アプリケーションのページのクロックに基づく全ての未処理の（すなわち、待ち行列に入れられた）ワークアイテムは、それらのワークアイテムの終了時間に達したかのようにイベント待ち行列から削除される。
【００５４】
判断ブロック８１６において、マークを付けられたワークアイテムの終了時間が過ぎていない場合、制御はブロック８２２に渡され、アプリケーションスレッド５２３がワークアイテムを処理する。図６に付随する説明において上述したように、各ワークアイテムは、イベント待ち行列５１５からの順で、すなわち、最初に開始時間によって、そして続いて各ワークアイテムがイベント待ち行列５１５に挿入された時間によって処理される。
【００５５】
反復的なイベント及びワンショットの（すなわち、１回しか起こらない非反復的な）イベントが、図８に示された方法を使用して管理される。反復的なイベントは、関連するワークアイテムが次のスケジューリングされた開始時間に等しい終了時間を有する周期的イベントを含み得る。すなわち、それぞれの周期的イベントは、イベントの周期に等しい継続時間を有する。
【００５６】
典型的には、周期的イベントは、タイマイベント及びアプリケーション描画イベントのようなイベントを含む。例えば、（例えば、図１のスクリプトホスト１１５における）アプリケーションのスクリプトが、１０秒毎に１回再呼び出しするタイマを生成する場合、そのアプリケーションのスクリプトは、そのときの時間に１０秒足した時間に等しい開始時間を有するタイマワークアイテムをイベント待ち行列５１５に追加することになる。終了時間は、開始時間に１０秒足した時間に設定される。タイマワークアイテムがイベント待ち行列５１５から実行されると、開始時間及び終了時間が、さらに１０秒足すことによって調整され、ワークアイテムがイベント待ち行列５１５に新しい開始時間に基づく適切な位置に再挿入される。
【００５７】
周期的イベントは可能なときにいつでも呼び出される。しかし、周期的イベントが、それらに関連するワークアイテムの終了時間が過ぎる前にアプリケーションスレッド５２３によって処理されることができない場合、その特定の呼び出しは破棄され、次の呼び出しが新しいワークアイテムを用いてスケジューリングされる。したがって、周期的イベントはワークアイテムタイムアウトになり易い。
【００５８】
有利なことに、イベント待ち行列化方法は、イベントが呼び出されるべき時間を示すために、タイマイベントにパラメータを渡すことを可能にする。このパラメータは、関連するワークアイテム内の開始時間と同じでなければならない。周期的タイマイベントに関連するスクリプトは、上述のように、呼び出された時間きっかりに実行されないことがある。しかし、各ワークアイテムは、メソッドに対する引数を指定するメソッドフィールド５４５（図５）を含むので、引数の値は意図された呼び出し時間を反映し、実際の時間を反映しない。したがって、タイマイベントに対するハンドラは、何時（すなわち、どのチックに）処理を行うかを知ることになる。
【００５９】
ワンショットのイベントは、無限の終了時間を有する対応するワークアイテムを有する。したがって、ワンショットのイベントはイベント待ち行列５１５から削除されない。例えば、ワンショットのイベントが入力イベントである場合、そのイベントのハンドラは、無限の終了時間を有するワークアイテムとしてイベント待ち行列５１５においてスケジューリングされる。
【００６０】
ブロック８２２に示されるように、処理は委任された形で実行される。すなわち、アプリケーションスレッド５２３がイベント待ち行列５１５からのワークアイテムを処理し始めると、アプリケーションスレッド５２３は処理を停止しない。例えば、長時間続く可能性があるスクリプトは中止されず、スクリプトを取り消すためにスクリプトに例外が投入されることもない。そのようなスキームはアプリケーションスレッドがスクリプトを処理する間にアプリケーションスレッドを拘束し得るが、上述のように、ＩＣＰ（例えば、図４のＩＣＰ４３５）は、ワークアイテムの委任された処理の間に実行を継続する他のスレッドを含むように構成されることができる。
【００６１】
ブロック８３０において、マークが付けられたワークアイテムの処理の間に生成された任意の新しいワークアイテムが、それらのワークアイテムの開始時間に無関係に、イベント待ち行列５１５において、マークを付けられたワークアイテムの後に挿入される。（ブロック８１０、８２２及び８３０に示されるように）ワークアイテムにマークを付け、それらのワークアイテムを委任し、イベント待ち行列での委任されたワークアイテムの後に新しいワークアイテムを挿入することは、アプリケーションに何らかの可視的な進展が常に与えられることを保証する。
【００６２】
図８のブロック８３５及び８２８に示すように、アプリケーションスレッドは、図７に示され且つ付随する本文において説明されたように、チック毎に各アプリケーションのイベント待ち行列に２つのワークアイテムを自動的に挿入する。これらのワークアイテムは各アプリケーションに対するマークアップエンジンを呼び出してアプリケーションのタイミングを評価し、次いでマークアップをリフローし、表示装置上にレンダリングする。上述のように、これらのワークアイテムはアプリケーションが開始すると挿入され、各チック後に再スケジューリングされる。さらに、これら２つのワークアイテムは必ず、アプリケーションのチックに対して処理されるべき最後の２つのワークアイテムであり、イベント待ち行列５１５から削除され得る周期的イベントとして扱われる。
【００６３】
図９は、機能及び／又はソースによって表示装置上の視覚的要素を論理的にグルーピングするための、例示的なグラフィカル合成モデルにおいて使用される１組のグラフィックス平面９００の図である。グラフィックス平面の組９００は、カーソル平面９０５、グラフィックス平面９１２、サブピクチャ平面９１８、サブビデオ平面９２２及びメインビデオ平面９２５を含む。カーソル平面９０５は、ポインタのようなカーソルオブジェクトが表示される、グラフィックス平面の組９００での最も上側の平面（すなわち、ユーザ９３０によって最も近い平面として知覚される）である。残りの平面は、図９において矢印９３５によって示すように、左から右へ表示の前側から後側に向かって配列される。
【００６４】
グラフィックス平面の組９００での全ての平面は、キャンバスと呼ばれる通常のｘｙ座標系を使用する。第３の次元が、図９において参照番号９４０によって示されるように表示装置から外に向かって突き出るｚ軸によって示される。インタラクティブメディア環境において実行されるアプリケーションは、特定の平面に属する。アプリケーションは明示的に又は任意に平面に割り当てられることはできず、関連付けはアプリケーションの型式に基づいて暗黙的になされる。例えば、サブタイトルアプリケーションはサブピクチャ平面９１８においてレンダリングするが、多くの他のアプリケーションはグラフィックス平面９１２においてレンダリングする。
【００６５】
グラフィックス平面９１２はグラフィックス平面の組９００の第２の平面であり、以下で説明するように、プレゼンテーションエンジンによって生成される。上述のように、インタラクティブメディア環境においてグラフィックス及びメニューなどのインタラクティブコンテンツを生成するアプリケーションは、典型的には、グラフィックス平面９１２にレンダリングされる。
【００６６】
サブピクチャ平面９１８はグラフィックス平面の組９００の第３の平面であり、典型的には、それぞれのアプリケーションによって生成されたサブタイトル及び／又はキャプションを表示するために使用される。サブビデオ平面９２２はグラフィックス平面の組９００での第４の平面であり、典型的には、「ピクチャインピクチャ」（ＰＩＰ）配置において二次的なビデオ表示として使用される。参照番号９４２によって示されるＰＩＰウィンドウのようなＰＩＰウィンドウは、メインビデオディスプレイよりも小さいことが多く、低減された解像度、異なるアスペクト比などの他の異なる特徴を有することができる。
【００６７】
メインビデオ平面９２５はグラフィックス平面の組９００内の第５の平面であり、平面のスタックの最も下側に位置付けられる。典型的には、メインビデオ平面９２５は、図３に付随する説明において上述したように、ビデオタイトルを含むインタラクティブメディア環境においてビデオコンテンツを表示するために使用される。図９に示すように、グラフィックス平面の組９００での全ての平面は、以下に説明するように、グラフィックスレンダリングエンジンによって単一のディスプレイ９５０にミキシング及び合成される。
【００６８】
図１０は、ＡｐｐＡと呼ばれる第１の例示的なアプリケーションにおける３つの視覚的要素のＺ順を示す図である。アプリケーション内のＺ順はアプリケーションのＺ順とは異なることが強調される。すなわち、アプリケーションはアプリケーション内のＺ順を有する視覚的要素を生成し、アプリケーション自体は、（図４のＩＣＰ４３５などの）ＩＣＰ上で実行されている複数のアプリケーションの間でＺ順が決められる。
【００６９】
アプリケーションＡｐｐＡは、図示されたように積み重ねられた配列の、それぞれＺ順０、１、２を有する要素１０１０（十字）、要素１０２０（星）及び要素１０３０（矢印）を含む３つの視覚的要素を生成する。したがって、１組のＮ個の要素に対して、１組のＺ順の値は、スタックにおいて最も低い要素に対する０で始まり、スタックにおいて最も高い要素に対するＮ−１で終わる。要素１０１０、１０２０及び１０３０は表示１０４５上に描かれる。図１０のウィンドウ１０５０は、表示１０４５において「沿層方向に」見たかのように、ＡｐｐＡによって生成された視覚的要素のＺ順を示す。表示１０４５及びウィンドウ１０５０は、ｘｙｚ座標１０５５によって示すように、互いに対して方向付けられる。
【００７０】
図１１は、ＡｐｐＢと呼ばれる第２の例示的なアプリケーションでの視覚的要素のＺ順を示す図である。アプリケーションＡｐｐＢは、表示１１４５上の積み重ねられた配列の、それぞれＺ順０、１、２を有する要素１１１０（三角形）、要素１０２０（楕円）及び要素１０３０（長方形）を含む３つの視覚的要素を生成する。ウィンドウ１１５０は、ＡｐｐＢによって生成された視覚的要素のＺ順を、ｘｙｚ座標１１５５によって示される表示１１４５の沿層方向の図において示す。
【００７１】
図１２は、アプリケーションＡｐｐＡ及びＡｐｐＢから生成された視覚的要素（集合的に参照番号１２１０によって示される）を有する合成された表示１２４５を示す図である。ウィンドウ１２５０は、（ｘｙｚ座標１２５５によって示される）表示１２４５の沿層方向の図を提供し、アプリケーションＡｐｐＡ及びＡｐｐＢが互いに対して相対的なＺ順を有することを示す。さらに、アプリケーションＡｐｐＡ及びＡｐｐＢはそれぞれ、図１０及び図１１に示され且つ付随する本文において説明したように、それらの視覚的要素に関するＺ順がアプリケーション内で維持される視覚的要素を生成する。
【００７２】
図１３は、アプリケーションが優先度順にレンダリングされ、後から前への順序で合成される例示的な配置１３００を示す図である。配置１３００は、ｘｙｚ座標１３５５によって示されるようにユーザ１３３０の方に向けられた表示の沿層方向の図１３５０を含む。他の例示的な配置（図１３には図示せず）においては、レンダリングは特定の設定要件に応じて後から前に（すなわち、Ｚ順に）実行される。
【００７３】
それぞれ参照番号１３０５、１３１０、１３１５、１３２０及び１３２５によって示されるＡｐｐＡ、ＡｐｐＢ、ＡｐｐＣ、ＡｐｐＤ及びＡｐｐＥを含む５つのアプリケーションがインタラクティブメディア環境において実行されている。アプリケーションは、矢印１３５２に示すように、ウィンドウ１３５０においてＺ順に後側から前側へ合成される。合成はＺ順＝０を有するアプリケーションＡｐｐＡ１３０５で始まり、Ｚ順＝４を有するアプリケーションＡｐｐＤ１３２５で終わる。
【００７４】
この例示的な例において、図１３によって示す時点に示されるように、アプリケーションＡｐｐＣ１３２０が、ユーザイベントを受信する視覚的要素１３５８を生成する注目のアプリケーションである。しかし、動的な環境で実行されているので、典型的には、注目の特定のアプリケーションは設計により時間と共に変わり、全てのアプリケーションはビデオタイトルが進行するにつれて典型的にはＺ順で前後へ移動することができる（しかし、アプリケーションは、メインビデオが停止され、一時停止され又はコマ止めされる場合でさえ、アプリケーションが実行されて動作するときには、Ｚ順を変更することができることも強調される）。さらに、注目のアプリケーションは、スタックのどの位置にあってもよい（すなわち、任意のＺ順を持つことができる）。しかし、多くのシナリオにおいては、注目のアプリケーションは、ユーザの期待に合ったやり方でユーザ１３３０と対話し、（例えば、リモコン１３３２からの）ボタンの押下げ、マウスクリックなどのユーザイベントを受信できるように、表示順の一番前側へ向かう。
【００７５】
矢印１３６２によって示すように、アプリケーションは、注目のアプリケーション（例えば、アプリケーションＡｐｐＤ１３２０）で始まって、その後に残りのアプリケーションが前側から後側へ、すなわち逆Ｚ順で続く優先度順においてレンダリングされる。
【００７６】
図１４は、アプリケーションが優先度順にレンダリングされ、後から前への順序で合成される例示的な方法に関する流れ図である。方法はブロック１４０５において開始する。ブロック１４１２において、インタラクティブメディア環境で実行されているアプリケーションに関して、上述のようにＺ順が維持される。特定のビデオタイトルに関連するアプリケーションに対する初期Ｚ順が、絶対値（例えば、１、２、５、７、・・・、８７など）を用いてプレイリスト２９０（図２）によって指定される。これらの絶対値は、任意の関係を断つようプレイリストの辞書式順序付けを用いてプレイリストのＺ順に基づいて全てのアプリケーションをソートすることにより、直ちに相対的Ｚ順序付けに変換される。
【００７７】
ブロック１４１５において、アプリケーションは、ビデオタイトルの進行につれてその相対的Ｚ順序付けを操作するためのメソッドを呼び出すことを可能にされる。そのようなメソッドは、例えば、ａ）平面内のＺ順の最上位にアプリケーションを移動させること、ｂ）平面内のＺ順の最下位にアプリケーションを移動させること、及びｃ）アプリケーションのＺ順を、表示スタックにおいて当該アプリケーションより上のアプリケーションの直上になるように変更することを含む。
【００７８】
上述のように、アプリケーションは、Ｚ順操作メソッドの呼び出しを通してＺ順においてアプリケーションがどれだけ移動できるかに制限を課す特定の平面に属する。例えば、サブタイトルアプリケーションを最上位に移動させるためのメソッドを呼び出すと、当該サブタイトルアプリケーションはサブピクチャ平面９１８（図９）における最上位のアプリケーションサブタイトルアプリケーションになるが、そこに生成される視覚的要素は、グラフィックス平面９１２でのアプリケーションによってそのグラフィックス平面９１２にレンダリングされる視覚的要素によって見えなくされる（すなわち、隠される）。同様に、通常のインタラクティブアプリケーションを最下位に移動させるためのメソッドを呼び出すと、当該インタラクティブアプリケーションはグラフィックス平面９１２における最下位のアプリケーションになるが、全てのサブタイトルアプリケーションよりも上にあるままにされる。
【００７９】
ブロック１４１６において、アプリケーションは、アプリケーションのＺ順が変わったことの通知を提供するためのイベントを受信する。代替として、そのような通知は、アプリケーションが最上位のアプリケーションに又は最上位のアプリケーションから離れて移行するときに受信されるように構成される。例えば、そのような通知は、メニュー生成アプリケーションによって生成されたメニューが最も高いＺ順を持つ位置に移動するときにゲームアプリケーションがそれ自体を一時停止させることを可能にする。
【００８０】
例示的な方法はブロック１４１８において継続し、アプリケーションからの視覚的要素は１つ又は複数のグラフィックスバッファにレンダリングされる。多くのシナリオにおいて、レンダリングは注目のアプリケーションで始まり、その後に残りのアプリケーションが表示の最上部から下に向かう逆Ｚ順で続く優先度順で実行される。描画（すなわち、２次元「２Ｄ」描画）は、ＰＮＧ（ポータブルネットワークグラフィックス）ファイルをレンダリングするのとほぼ同じやり方で次にグラフィックスバッファにレンダリングされる、アプリケーションのマークアップ（例えば、図１のマークアップ１２０）におけるオブジェクトを「キャンバス」に描画することによって処理される。
【００８１】
図１４に示す例示的な方法において、バッファリングのステップは、周期的なレンダリングイベントに対応するワークアイテムをそれぞれのアプリケーションのイベント待ち行列に配置することによってアプリケーションがレンダリングされるように構成される。この構成と共に使用されることができるイベント待ち行列及び関連する方法は、図５〜図８に示され、付随する本文において説明される。
【００８２】
ワークアイテムの配置は、アプリケーションフレームのレンダリングがワークアイテムのタイムアウトを受け易いことを意味する。したがって、優先度が再生システムのどこかに置かれる場合に、新しいアプリケーションフレームがビデオフレーム毎に常にレンダリングされるとは限らないという可能性に対処するために、アプリケーションの二重バッファリングが実行される。そのような場合、最も新しい利用可能なフレームが、新しいフレームが完成されるまで引き続き示されることになる。
【００８３】
ブロック１４２１において、表示を合成する前に、各アプリケーションは、そのマークアップ（例えば、図１のマークアップ１２０）に＜ｃｌｅａｒｒｅｃｔ＞要素を含むかどうかを確かめるようチェックされる。そのような要素は、メインビデオ平面９２５を見ることができる、アプリケーションによって生成されたグラフィックス内の開口（すなわち、「穴」）を生成するために含まれる。＜ｃｌｅａｒｒｅｃｔ＞要素は長方形の開口を生成するが、他の規則的な幾何学形状、不規則な形状及び他の任意の形状も、特定の設定要件に応じて利用可能である。
【００８４】
＜ｃｌｅａｒｒｅｃｔ＞などの要素や他のそのような開口生成要素は、方法のブロック１４１８においてアプリケーションがレンダリングされるようなときにはグラフィックスバッファに含まれない。その代わりに、アプリケーション内の穴を通じてメインビデオ平面９２５が見られるように、合成期間に＜ｃｌｅａｒｒｅｃｔ＞要素を有するアプリケーションよりも低いＺ順を有するアプリケーションにおいて穴が開けられる。優先度順でレンダリングが実行されるので、アプリケーションがバッファにレンダリングされるときに＜ｃｌｅａｒｒｅｃｔ＞要素を実行することは実用的でない。＜ｃｌｅａｒｒｅｃｔ＞要素がそのように実行され、より優先順位の低いアプリケーションが直ちには更新されなかったとすると、穴が不適切に現れる可能性がある。これが発生するのは、例えば、Ｚ順が変わった場合、又は、優先順位の低いアプリケーションがタイムアウトの間に更新されるのを待っている間に＜ｃｌｅａｒｒｅｃｔ＞要素を有するアプリケーションが終了した場合である。
【００８５】
ブロック１４２５において、アプリケーションは、図１２に示され且つ付随する本文において説明したように、後側から前側へＺ順に合成される。多くの設定において、各アプリケーションに対する最も新しいバッファされたフレームを使用して各アプリケーションのマークアップをグラフィックス平面９１２にレンダリングする単純なペインターズアルゴリズムは使用できない。さらに、上述のように、＜ｃｌｅａｒｒｅｃｔ＞又は他の開口生成要素は合成ステップ中に実行されることができる。例示的な方法はブロック１４３３において終了する。
【００８６】
図１５は、例示的な再生システム１５００のブロック図である。ナビゲーションマネージャ１５０５は、インタラクティブメディア環境で実行されているＮ個のアプリケーションの厳密な順序付けを維持する。各アプリケーションには０からＮ−１までのＺ順が与えられ、全てのアプリケーションは一意的なＺ順を有する。順序付けに飛びはなく、任意の２つのアプリケーションは同じＺ順を持たない。Ｚ順０は表示１５１２の最も下側に現れ、Ｚ順Ｎ−１は最も上側に現れる。ビデオタイトルが時間的に進行するにつれて、ナビゲーションマネージャ１５０５は、上述のように、アプリケーションに対するＺ順を、プレイリスト（例えば、図２のプレイリスト２９０）によって設定された初期Ｚ順値から動的に維持する。
【００８７】
ナビゲーションマネージャ１５０５は、プレゼンテーションエンジン１５１５及びグラフィックスレンダリングエンジン１５１８に結合される。多くの設定において、プレゼンテーションエンジン１５１５は、グラフィックス平面の組９００での平面のそれぞれを、それらの平面とそこでのアプリケーションの表示１５１２上での合成を実行するグラフィックスレンダリングエンジン１５１８に提供するように構成される。
【００８８】
プレゼンテーションエンジン１５１５とグラフィックスレンダリングエンジン１５１８との間に、それぞれ参照番号１５２２、１５２６及び１５２８によって示される１つ又は複数のグラフィックスバッファ１、２、・・・、Ｎが配置される。Ｎ個のグラフィックスバッファは、１対１でそれぞれのアプリケーションにマッピングするように構成される。すなわち、Ｎｂｕｆｆｅｒｓ＝Ｎａｐｐｌｉｃａｔｉｏｎｓ。代替の構成においては、全てのアプリケーションに対して（参照番号１５４０によって示される）単一のバッファが利用され、又は、グラフィックバッファはバラバラにアプリケーションにマッピングされる。
【００８９】
図１６は、入力イベントを複数のアプリケーションに分配するための例示的な方法に関する流れ図である。方法はブロック１６０５において開始する。ブロック１６０８において、インタラクティブメディア環境において、例えばＩＣＰ４３５（図４）上でそのとき実行されている複数のＮ個のアプリケーションに対してＺ順が注目される。
【００９０】
入力イベントは注目のアプリケーションに最初に配信され、その後に複数のＮ個のアプリケーションのうちの全ての残りのアプリケーションに逆Ｚ順に配信される。したがって、ブロック１６１４において、入力イベントは注目のアプリケーションに配信される。この例示的な方法において、入力イベントが、ユーザイベント、システムイベント、アプリケーションイベント及びナビゲーションイベントを含む。ユーザイベント、システムイベント及びアプリケーションイベントは、図５に付随する本文において上で説明されている。典型的には、ナビゲーションイベントは、上、下、左、右などに関するボタンの押下げに対応するリモコン（例えば、図１３のリモコン１３３２）からのイベントを含む。
【００９１】
判断ブロック１６１７において、注目のアプリケーションが入力イベントを消費する場合、ブロック１６２５において入力イベントの処理は停止し、方法は終了する。注目のアプリケーションが入力イベントを消費しない場合、ブロック１６３２において、入力イベントは複数のアプリケーションの中で最も高いＺ順を有するアプリケーションに配信される。最も高いＺ順を有するアプリケーションが入力イベントを消費する場合、ブロック１６４０において入力イベントの処理は停止し、方法は終了する。
【００９２】
最も高いＺ順を有するアプリケーションがイベントを消費しない場合、次に高いＺ順を有するアプリケーションに入力イベントの配信が行われる。アプリケーションが入力イベントを消費するまで、又は、入力イベントが配信されることができるアプリケーションがなくなるまで、ブロック１６４５においてＺ順が逆順にカウントダウンされ、方法がブロック１６４８を通って繰り返し継続する。この後者の場合、ブロック１６５０において入力イベントの処理は停止し、方法は終了する。
【００９３】
アプリケーション内の入力イベントの処理は、アプリケーションと（例えば、図１のマークアップ１２０からの）マークアップオブジェクトが、アプリケーションオブジェクトを最上位にして全て単一のＤＯＭに配列されたかのように進む。Ｗ３Ｃイベントモデルと一致して、そのような配列は、入力イベントがアプリケーションのマークアップに渡される前にアプリケーションオブジェクトが入力イベントを捕捉することを可能にする。各オブジェクトにおいて、オブジェクトには入力イベントを捕捉する機会が与えられる。捕捉が行われると、入力イベントハンドラはさらなる入力イベントの処理を停止する選択肢を持つ。マークアップにおいて処理されない入力イベントは、アプリケーションオブジェクトを介してバブルバックアップする。このように、アプリケーション内のイベント処理は、アプリケーションをまたがるイベント処理のためのモデルと統合される。多くの設定において、マークアップはユーザイベント及びナビゲーションイベントだけを処理することができることに留意されたい。典型的には、アプリケーションイベント及びシステムイベントはスクリプトを介してのみ処理される。
【００９４】
アプリケーションのマークアップにおける多くの視覚的要素は、指定された「キー」を特定の視覚的要素に割り当てる「アクセスキー」属性を受け取るように構成される。したがって、一致するアクセスキー属性を有するアプリケーションにおける任意の視覚的要素は、それを処理した後で入力イベントを消費する。ナビゲーションイベントも同様に処理される。
【００９５】
マークアップにおける＜ｅｖｅｎｔ＞要素を使用して実行されるアプリケーションイベントは、図５〜図８に示され且つ付随する本文において説明されたように、対応するワークアイテムを生成し、イベント待ち行列にスケジューリングする。したがって、＜ｅｖｅｎｔ＞要素は、そのイベントハンドラに対する関数呼び出しとして現れない。これが生じるのは、上述のように、新しいワークアイテムがイベント待ち行列に、全てのマークを付けられたワークアイテムの後に挿入されて処理されるからであり、これは十中八九は次のチックに起こる。さらに、イベントは優先度順（すなわち、注目のアプリケーションの後に残りのアプリケーションが逆Ｚ順で続く順番）で全てのアプリケーションに配信されるので、アプリケーションイベントは、該アプリケーションイベントを生成したアプリケーション以外のアプリケーションによって処理されることができる。システムイベントもワークアイテムのパラダイムを使用して生成され、スケジューリングされる。
【００９６】
（図４のＩＣＰ４３５などの）ＩＣＰはスクリプトが特定の入力イベントを処理するかどうかを事前に知らないので、スクリプトによって処理される入力イベントは、マークアップを伴う状態とは異なる状況を呈する。したがって、スクリプトに関する入力イベントハンドラは、入力イベントが消費されたかどうかを示すためのフラグを返さなければならない。真を返すことは入力が消費されたことを示し、偽を返すことは入力イベントが消費されなかったことを示す。
【００９７】
アプリケーションのスクリプトには、処理されていない入力イベントを処理する最初の機会が与えられる。したがって、スクリプトは、アクセスキー及びナビゲーション入力イベントに対してマークアップによって実行されるデフォルトのプレーヤ動作を無効にすることができる。
【００９８】
留意されるように、本明細書において使用される「消費される」及び「処理される」は、多くの場合、同じことを意味する。しかし、いくつかのシナリオにおいては、それらは厳密には同じでない。例えば、アプリケーションは、入力イベントを一層低いＺ順を有するアプリケーションから隠すために当該アプリケーションが入力イベントに何かを行うとしても、入力イベントを消費することを望むことがある。あるいは、アプリケーションはイベントを処理するための何らかの処置を行うが、入力イベントが更に低いＺ順へ向かうように、入力イベントを処理しなかったことを示す偽のフラグを返すこともある。
【００９９】
図１５に示す例示的な方法の一例がここで説明される。ユーザは、リモコン（例えば、図１３のリモコン１３３２）上の上、下、左及び右のボタンに応答するインタラクティブゲームを実行している。ゲームは、表示装置上の最も上側のアプリケーションである（すなわち、ゲームはＺ順＝Ｎ−１を有する）。ゲームの作者は、リモコン上の「メニュー」ボタンを処理するようにはゲームを設計していない。
【０１００】
メニューアプリケーションがゲームと同時に実行されている。そのメニューアプリケーションは、低いＺ順を有するので、ゲームより下に現れ、又は、表示上に視覚的要素を持たない（したがって、全く見えない）。メニューアプリケーションはゲームよりも低いＺ順を有するので、メニューアプリケーションはゲームによって処理されない入力イベントのみを受信する。ユーザがリモコン上の上、下、左及び右のキーを押しているとき、ゲームはそれらのキーをマークアップにおいて処理し、又は、ゲームは、それらのキーに対して真のフラグを返し且つそれ以外の全てに対しては偽を返すスクリプトハンドラによって処理する。
【０１０１】
ユーザがゲームを停止することを決定するとき、リモコン上のメニューボタンが押される。この入力イベントは、該入力イベントを処理しない（注目のアプリケーションとしての）ゲームアプリケーションに最初に配信される。次に、入力イベントはメニューアプリケーションに配信され、そのメニューアプリケーションは、該メニューアプリケーションを最高のＺ順で表示の最も上側に移動させるためのメソッド（このメソッドは図１４に付随する説明に記載される）を呼び出すことによって応答する。そのような移動により、ユーザがメニューをナビゲートできるよう、リモコンからのその後の上、下、左及び右の入力イベントが最初にメニューアプリケーションに届くことが保証される。
【０１０２】
留意されるように、説明を明確に且つ容易にする目的で、上記説明において、データ、プログラム及びオペレーティングシステムなどの他の実行可能なプログラムコンポーネントは別個のブロック、ボックス又はその他の要素において図示されているが、認識され且つ強調されるように、そのようなプログラム及びコンポーネントは、使用される任意のハードウェアホストの異なる記憶装置、メモリ又は処理コンポーネントに様々な時間に常駐することができ、そのようなホストハードウェアでの１つ又は複数のプロセッサによって実行される。
【０１０３】
インタラクティブメディア環境においてアプリケーションの状態を管理するための様々な例示的な構成及び方法を図示して説明してきたが、理解されるように、本明細書に添付された請求項の範囲は、説明された特定の特徴、構成又は方法に必ずしも限定されない。むしろ、特定の特徴、構成又は方法は、一層具体的に特許請求されたインタラクティブメディア環境において管理されるアプリケーションの状態を実装する例示的な形態として開示される。
【図面の簡単な説明】
【０１０４】
【図１】インタラクティブメディア環境において使用されるアプリケーションを構成する要素を示す例示的なブロック図である。
【図２】複数のマークアップドキュメントとスクリプトとの間の関係を示す例示的な図である。
【図３】インタラクティブコンテンツプロセッサ、ビデオコンテンツプロセッサ及びミキサを含む例示的なインタラクティブメディアプレーヤのブロック図である。
【図４】第２の例示的なインタラクティブメディアプレーヤのブロック図である。
【図５】複数のイベント待ち行列及び単一のアプリケーションスレッドを有する例示的な構成のブロック図である。
【図６】最初に開始時間による、次いで、ワークアイテムがイベント待ち行列に挿入された時間によるワークアイテムの順序付けを示す例示的なイベント待ち行列のブロック図である。
【図７】アプリケーションスレッドが２つのワークアイテムをイベント待ち行列の最後に自動的に挿入する例示的な構成のブロック図である。
【図８】インタラクティブメディア環境において発生するイベントに関連するワークアイテムを待ち行列に入れるための例示的な方法の流れ図である。
【図９】例示的なグラフィカル合成モデルにおいて使用される１組の平面の図である。
【図１０】第１の例示的なアプリケーション内の視覚的要素のＺ順を示す図である。
【図１１】第２の例示的なアプリケーション内の視覚的要素のＺ順を示す図である。
【図１２】図１０及び図１１に示すアプリケーションから生成された視覚的要素を有する合成された表示を示す図である。
【図１３】アプリケーションが優先度順にレンダリングされ、逆さまの順序で合成される例示的な構成を示す図である。
【図１４】アプリケーションが優先度順にレンダリングされ、逆さまの順序で合成される例示的な方法に関する流れ図である。
【図１５】例示的な再生システムのブロック図である。
【図１６】入力イベントを複数のアプリケーションに分配するための例示的な方法に関する流れ図である。
【図１】
2009500727.tif 000003
【図２】
2009500727.tif 000004
【図３】
2009500727.tif 000005
【図４】
2009500727.tif 000006
【図５】
2009500727.tif 000007
【図６】
2009500727.tif 000008
【図７】
2009500727.tif 000009
【図８】
2009500727.tif 000010
【図９】
2009500727.tif 000011
【図１０】
2009500727.tif 000012
【図１１】
2009500727.tif 000013
【図１２】
2009500727.tif 000014
【図１３】
2009500727.tif 000015
【図１４】
2009500727.tif 000016
【図１５】
2009500727.tif 000017
【図１６】
2009500727.tif 000018
【国際調査報告】
2009500727.tif 000019