JP2013137791A - 対話型メディア環境におけるイベントのキューイング - Google Patents

Abstract

【課題】対話型メディア環境でリソースが限定されていても、フレームに正確でリアルタイムにユーザに応答する。
【解決手段】イベントに対応するワークアイテムの処理のスケジュールを決定するのに、イベント・キューが用いられる。ワークアイテムは、呼び出される方法と引数とを含む。ワークアイテムは、開始時間と終了時間とを更に含み、イベント・キューにおいて最初は開始時間によって以後はキューの中にインサートされた順序によって順序付けされる。アプリケーション・スレッドは、現在の又は以前の時間に対応する開始時間を有するワークアイテムにマーキングし（８１０）、キューからのマーキングされたワークアイテムを順に処理する（８２２）。このような処理は、アプリケーション・スレッドがワークアイテムの処理をいったん開始すると停止しないように実行される。終了時間が過ぎた場合には、ワークアイテムがイベント・キューから削除される。
【選択図】図８

Description

関連発明

この出願では、２００５年７月１日に出願された米国特許仮出願第６０／６９５，９４４号に基づく優先権を主張している。

この出願に記載される構成、システム及び方法は、広くは対話型メディアに関し、更に詳しくは対話型メディア環境におけるイベントのキューイングに関する。

対話型メディア環境は、典型的には、当該環境において動作するアプリケーションにとって利用可能な処理能力、メモリ及びそれ以外のリソース（資源）の点で制約のあるリソースリソースである。対話型メディアの一般的な１つの例として、ＤＶＤ（デジタル・バーサタイル・ディスク）上でエンコードされているビデオがあるが、この場合、ユーザは、グラフィカルなメニュ又はそれ以外の制御手段と対話し、特定のビデオ・コンテンツまで行き着いたり、ＤＶＤの中にオーサリングされている特別の特徴を呼び出すことができる。

より複雑な対話型メディア環境では、リソースが限定されているにもかかわらず、アプリケーションは、ビデオとの関係でフレームに正確でリアルタイムな態様でユーザに応答する必要がある。しかし、そのような目的を達成するリアルタイムでマルチスレッド型のプログラミングを用いると、スレッド管理や同期の問題に対処する際に、対話型メディアの作成者に多くの負担となる。

対話型メディア環境におけるすべてのアプリケーションがメディア・プレーヤにおける単一のアプリケーション・スレッドの上を動作する構成が提供される。イベント・キューは、環境において生じるイベントに対応するワークアイテム（作業項目）のアプリケーション・スレッドによる処理のスケジュールを決めるのに用いられる。ワークアイテムは、ワークアイテムが処理されるときに呼び出されるメソッドと、メソッドのための引数とを含む。従って、イベント・キューからのワークアイテムのスケジュール決定と処理とが、環境においてどの作業（ワーク）がいつ行われるかを決定する。典型的なイベントには、メディア・プレーヤを用いてユーザとの対話（インタラクション）から開始されるユーザ・イベントと、メディア・プレーヤによって開始されるシステム・イベントと、アプリケーションによって開始されるイベントとが含まれる。

様々な例においては、ワークアイテムは、開始時間と終了時間とを更に含み、イベント・キューの中で、最初は開始時間によって以後はキューの中にインサートされる時間によって順序付けされる。ある例では、アプリケーション・スレッドが、現在の又は以前の時間と対応する開始時間を有するワークアイテムをマーキングし（マークを付し）、マーキングされたワークアイテムをキューから順に処理する。すべての処理はコミット・ベースで実行され、よって、アプリケーション・スレッドはワークアイテムの処理をいったん開始すると停止しない。ワークアイテムは、その終了時間が経過した場合には、イベント・キューから削除される。処理の間に生じる新たなイベントに対するワークアイテムは、コミットされたワークアイテムの後に処理されるようにキューの最後にインサートされる。別の例では、新たなイベントに対するワークアイテムは、その相対的な開始時間に基づいてイベント・キューの中にインサートされ、コミットされたワークアイテムの後で処理される。反復的なイベントは、タイマ・イベントやアプリケーション・ドローイング・イベントのように、イベント・キューから削除される個別のオカレンスを有することがある。しかし、ワンショットの（すなわち、単一のオカレンスで非反復的な）イベントは削除されることはない。

効果としては、単一のアプリケーション・スレッドを備えたイベント・キューイング・モデルは、対話型メディアの作成者（オーサ、authors）が、プロセッサのサイクルやメモリを含むハードウェア・リソースが限定的である場合に、イベントをリアルタイムかつフレームに正確な態様で管理するための安定的で予測可能な方法を提供する。

対話型メディア環境において用いられるアプリケーションをマークアップする要素を示すブロック図である。 複数のマークアップ文書（ドキュメント）及びスクリプトの間の関係を示す例示的な図である。 対話型コンテンツ・プロセッサとビデオ・コンテンツ・プロセッサとミキサとを含む例示的なワークアイテムメディア・プレーヤのブロック図である。 第２の例示的な対話型メディア・プレーヤのブロック図である。 複数のイベント・キューと単一のアプリケーション・スレッドとを有する例示的な構成を示すブロック図である。 最初は開始時間により以後はワークアイテムがイベント・キューの中にインサートされた時間によるワークアイテムの順序付けを示す例示的なイベント・キューのブロック図である。 アプリケーション・スレッドが２つのワークアイテムをイベント・キューの最後に自動的にインサートする例示的な構成のブロック図である。 対話型メディア環境において生じるイベントと関連するワークアイテムをキューイングする例示的な方法の流れ図である。

図１を参照すると、対話型メディア環境の中で用いられるアプリケーション１１０をマークアップする要素のブロック図が示される。リモート・コントロールのようなユーザ・インターフェースによってユーザと対話型メディア・プレーヤ・レンダリング・グラフィックスの間のインタラクション及び（連結する、１つの）表示装置（テレビかモニターのような）上のビデオを可能にするため、アプリケーションは、対話型メディア環境の中で用いられるのが典型的である。より具体的には、アプリケーションは、この環境において、ビデオの再生を含む様々なコンテンツ・オブジェクトのプレゼンテーション行為を制御する。ビデオ上のメニュー及び対話型のボタンのようなグラフィックオブジェクトのプレゼンテーションもアプリケーションを用いて実現される。アプリケーションは、環境でさらにオーディオ・プレイバック及び音を管理しコントロールする。それは熟考される、多数のアプリケーションは、一般にほとんどの対話型メディア・セッティングの中で同時に作動するだろう。しかし、多数のアプリケーションが同時に実行する要求はない。また、アプリケーションを特別のセッティングに分割するか集める決定は対話型メディア著者の設計選択である。アプリケーションも、特定のセッティングの要求に依存するアプリケーション・ページへ論理上細分されることがある。

アプリケーション１１０は、０以上のスクリプトファイル１１７、１１９及び０を含んでいるスクリプト・ホスト１１５を含む。又は、より多くのマークアップが、ドキュメント・オブジェクト・モデル（ＤＯＭ）を生成するために用いられる１２０を文書化する。マークアップ・ドキュメント１２０は、グラフィックオブジェクトの内容、スタイル、タイミング及びレイアウトに、情報を関連づけることを例えば含んでいる。したがって、マークアップ・コンテキストは対話型メディア環境中のグラフィックス飛行機上のグラフィックスを提供するために一般に用いられる。

この実例となる例において、マークアップ・ドキュメントはＷ３Ｃ基準に従ってＸＭＬ文書ファイルである。図１に示されるように、多数の物理的なＸＭＬファイルは、マークアップの〈ヘッド〉セクションの中で〈加算〉エレメントを用いてアクセスされることがある。いくつかのセッティングでは、アプリケーションが一度に１つを超える活発なマークアップを持っていないことは望ましいことがある。しかし、アプリケーションはマークアップの中で〈リンク〉エレメントを使用することによりそのマークアップ１２０を切り替えることがある。又は、アプリケーションは、アプリケーションが現在のアプリケーション内の機能オブジェクトへのアクセスを獲得することを可能にするアプリケーションプログラムインターフェイス（ＡＰＩ）の利用により、そのマークアップ１２０を切り替えることがある。ＡＰＩによってｌｏａｄＭａｒｋｕｐ（）コールを用い、アプリケーションは、ＡＰＩを通して新しいマークアップのユニフォームリソースアイデンティファイヤ（ＵＲＩ）を渡すことにより、マークアップ・ファイル１２０を切り替えることがある。

アプリケーションが新しいマークアップにアクセスする時に、アプリケーションでの現イベントハンドラーがその現在のタスクを実行し終えた後だけ、ＡＰＩ呼び出しは効果を現わす。以前ロードした新しいマークアップがそれらのイベントハンドラーを無効にするとともに、未決のどんな現在のマークアップ関連のイベントハンドラーも取り消される。

この実例となる例において、スクリプト・ホスト１１５は、対話型メディア経験をインプリメントするためにマークアップ１２０と共に用いられるスクリプトファイル１１７及び１１９を含んでいる。スクリプトファイル１１７及び１１９は、ＥＣＭＡ−２６２スペック中のＥｃｍａインターナショナルによって定義されるようなＥＣＭＡＳｃｒｉｐｔを用いて、例えばインプリメントされることがある。ＥＣＭＡ−２６２の下で落ちる、共通をスクリプトにするプログラミング言語はＪａｖａＳｃｒｉｐｔ（登録商標）とＪＳｃｒｉｐｔを含んでいる。いくつかのセッティングでは、特別のＥＣＭＡ−３２７で、ＥＣＭＡＳｃｒｉｐｔ２６２の部分集合を用いて、ホスト環境及び１セットの共通のＡＰＩに加えて、スクリプト１１７及び１１９をインプリメントすることは望ましいことがある。ほとんどのセッティング中のスクリプト・コンテキストは単独でマークアップ１２０を用いて、容易に又は効率的にインプリメントされないシステム事象、グラフィックス・コントロール、ビデオ・プレイバック、資源管理（例えば、キャッシングか執拗な蓄積リソースに使用する）及び他の問題と共にユーザからの会話形制御問題に対処するために利用される。

アプリケーション１１０へのＡＰＩ及びリソースのアベイラビリテイは図１の中の参照番号１２５によって示される。リソースは例えば、オーディオ及びビデオファイル、フォント、画像及びイメージ（例えば共通ファイルフォーマット含有ＰＮＧ、ＪＰＥＧ、ＧＩＦ、ＢＭＰ、ＴＩＦＦなどの中の）、及び特定のセッティングの状況によるアプリケーションによって要求されることがあるのと同じくらい他のリソースを含んでいる。

アプリケーション１１０はそれぞれ、スクリプトの変数、機能及び他の状態用のコンテキストを維持するそれ自身のスクリプト・ホスト１１５を維持する。ほとんどのセッティングでは、すべてのアプリケーションを横切って共有されるオブジェクトの使用により、もしアプリケーションが例えば、そのようなアプリケーションをまたがる視程を可能にするためには特にセット・アップされなければ、１つのアプリケーションでの変数及び機能は別のアプリケーションに見えない。例えば、この実例となる例において、対話型メディア・プレーヤ・オブジェクトにはすべてのアプリケーションを横切って共有される単一のインスタンスがある。自由に、したがって、特別のものが反対するところで、シングルトン（つまり、１つの、制限のあるインスタンス化があるオブジェクト）をインプリメントするために、特別のオブジェクトはスクリプト・ホスト１１５（例えば、Ｃ＋＋オブジェクトを用いて）の内部で置かれることがある、すべての参照、例えば同じ内部機能、プレーヤを含む。対話型メディア・スクリプトの作成者は、スクリプト・ホスト１１５が単一のスクリプト・ホストにオブジェクトを露出するのに必要な機能性をインプリメントすることをまだ可能にする間にこのオプションの様相によって単集合として論理上共通オブジェクトを扱うことができる。

ここで、図２には、多数のマークアップ・ドキュメントの関係を示す実例となるダイアグラム及びスクリプトを参照することが提供される。アプリケーション２３０を明示することで上に注目されたとともに、リソース１２５、スクリプト２０５及びマークアップによって一般に定義されるアプリケーションと対話する、示されるように２５１、２６０及び２７５を文書化する。アプリケーションはそれぞれ典型的にはほとんどのセッティングの中で単独使用マニフェスト・ファイルを使用する。しかし、アプリケーション・マニフェストは、アプリケーションのランタイム状態の一部ではない。この例では、アプリケーション・マニフェスト２３０は、ＸＭＬ文書ファイルとしてエンコードされる。

アプリケーション・マニフェスト２３０は、スクリプト・ホスト１１５（図１）に含まれていたスクリプトファイル（集団的に図２の中の参照番号２０５を備えた長方形によって示された）と同様にアプリケーション１１０（図１）によって用いられる最初のマークアップ・ファイル２５１も記述する。この例のように、アプリケーション・マニフェスト２３０が１つのスクリプト以上に２３０のリストを明示する場合、スクリプトはすべて対話型メディア・プレーヤの中のスクリプト取り扱いエンジンにロードされる。したがって、複数のスクリプトファイルは処理され、あたかもスクリプトの制作者がアプリケーション・マニフェスト２３０でリストされた順に単一大きなファイルの中へのスクリプトファイルをすべて連結したかのように作用する。

図２に示されるように、アプリケーション・マニフェスト２３０はリソース１２５を指す。対話型メディア環境中のアプリケーションに利用可能なリソースは、アプリケーション・マニフェスト２３０に参考文献として載せられたリソース１２５によって定着して、有向グラフを形成する。各アプリケーションのグラフの許可された範囲は、アプリケーションマニフェスト２３０によって禁止される。

図２は、対話型メディア環境中で作動する３つのアプリケーションを示す。上に注意されるように、アプリケーションはそれぞれ一度に１つの活発なマークアップだけを持っていることがある。また、申請内容はアプリケーションによって個別にしておかれる。マークアップ・ページ２５１と２６０及び２７５の間の矢によって示されるように、スクリプト２０５によって、アプリケーションはマークアップ・ページ２５１〜２６０から、次にその後２６０〜２７５ページから進むことができる。

対話型メディア環境中のアプリケーションによるコンテキスト執行の進行は、他のもの（表示装置上にプレーヤによって与えられるプレゼンテーション・オブジェクトを含む環境中のオブジェクトの関係）の中に記述するプレイリスト２９０によってガイドされる。
これらのプレゼンテーション・オブジェクトは典型的にはビデオ（それはより詳細に下に記述されるような多数のストリームを含んでいるかもしれない）、及びアプリケーションによって生産されたグラフィックスを含んでいる。

プレイリスト２９０は、さらに効率的にアプリケーションによってリソースの消費を割り付けてコントロールするために単一の管理主体として対話型メディア環境を横切ってリソースを管理する。アプリケーションマニフェスト２３０でのように、プレイリスト２９０はＸＭＬ文書ファイルとして有利に、ほとんどのセッティングで具体化される。

実行コンテキスト（図１の中のスクリプトファイル１１７及び１１９によって作成された）へイベントを開始するために、図２の中のマークアップ・ページは、いくつかのセッティングの中で使用されてもよい。その後、実行コンテキストは、現在のアプリケーション・マークアップによって作成されたＤＯＭを操作する。マークアップが環境（図２の中の、エレメント２５３、２６２及び２７７によって表わされたとともに）中でグラフィック・オブジェクトのスタイル、内容、タイミング及びレイアウトを指定するために対話型メディア環境の中で用いられるとともに、スクリプトとマークアップの組合せは能力の包括的なセットの生成を可能にする。

図３は、対話型コンテンツ・プロセッサ（ＩＣＰ）３３５とビデオ・コンテンツ・プロセッサ（ＶＣＰ）３１０とミキサ３３９とを含む第１の例示的な対話型メディア・プレーヤ３０５のブロック図である。図３に示された構成は論理モデルを提供し、この論理モデルは、アプリケーション状態管理に関係する対話型メディア・プレーヤ３０５の特徴及び機能について説明している。したがって、対話型メディア・プレーヤの実際のインプリメンテーションは、様々な構成上の形式を有し、アプリケーション状態管理という目的を達成する。対話型メディア・プレーヤ３０５は、スタンド・アロンの消費者向きの電子機器など専用ハードウェア中で典型的に実現されるし、又は、パーソナル・コンピュータのような汎用プロセッサと共にコンピュータ可読な媒体によるソフトウェアとしての実現もありうる。

ＶＣＰ３１０は、ＤＶＤドライブや高精細ＤＶＤ（ＨＤ−ＤＶＤ）ドライブなどのローカルな光ドライブ、ローカル・メモリ又はネットワークを介したリモート・ブロードバンド・ソースを含む複数のソースから受け取られる１又は複数のメディア・ストリームを管理する。ＶＣＰ３１０は、この例では、図３の中の要素３０４及び３０６に示されるように１又は複数のメディア・プロセッサ１、２、・・・、Ｎを含む。メディア・プロセッサ３０４及び３０６は、オーディオ及びビデオを含む受け取ったメディア・ストリームを処理し、ライン３２５においてオーディオ／ビデオ・ストリームとして出力される対応のイメージ及び音声をレンダリングする。オーディオ／ビデオ・ストリーム３２５は、例えば、「ピクチャ・イン・ピクチャ」型のコンフィギュレーションを用いて複数の別個のビデオ・ウィンドウをレンダリングする複数のビデオ要素を表す。

メディア・プロセッサ３０４及び３０６は、それぞれが、メディア・ソース・インターフェース、デマルチプレクサ及びデコーダを含む。同様に、メディア・プロセッサ３０４及び３０６は、オプションであるが、復号化能力を含んでいることがある。表示装置３５５は、オーディオ／ビデオ・ストリームを受け取り表示するように結合されている。

それぞれの受信されたメディアが関連する「媒体時間」を有するように、媒体クロック３１２が用いられる。ビデオストリームが対話型メディア・プレーヤ３０５において休止される場合には、メディア・クロック３１２も休止する。ビデオ・ストリームがユーザによってリアルタイムよりも高速で又は低速となるように設定されると（例えば、「トリック再生」と称されるモードを用いて、早送り、巻き戻し、低速再生などが可能）メディア・クロック３１２は、それに従って高速化又は低速化される。メディア時間は、このようにメディア・クロックとメディア・プロセッサ３０４及び３０６の動作により導かれる。メディア時間は、ライン３１５を介して、ＩＣＰ３３５の中のプレイリスト・マネジャ３３７に送られる。メディア時間を含む対話型メディア環境における時間は、「チック」（ticks）という単位で計測されるのが通常である。

ＩＣＰ３３５は、アプリケーション関連の処理をすべて行ない、ハードウェア、ソフトウェア、ファームウェア又はその組合せにおいて実現されるいくつかの成分から構成される。ＩＣＰ３３５の成分は、例えば、マークアップ・エンジン、スクリプト言語インタプリタ及びＸＭＬパージング・コンポーネント（図示せず）を含む。ＩＣＰ３３５は、オーディオ／ビデオ・ストリーム３２５と同期してグラフィックス・ストリームをライン３２１上に出力する。ミキサー３３９は、グラフィックスがユーザのための対話型メディア・セッションを実行するためにビデオストリーム上のグラフィクス・レイヤでレンダリングされるように、グラフィックス・ストリーム・オンライン３２１及びオーディオ／ビデオストリームをライン３２５上で得る。

ほとんどの設定で、ＩＣＰ３３５は、フレームごとのベースでビデオ・ストリームと同期されるグラフィックスを出力する。しかし、そのような同期化は、例えば、時間（後述するタイトル時間、メディア時間を含む）、ビデオのコンテンツ、又は、ストリームにおける特定の点を指示する又はマーキングするのに用いられるビデオに埋め込まれたそれ以外のメタデータを含む他の方法でも可能である。

ＩＣＰ３３５は、プレイリスト・マネジャ３３７及びタスク・マネジャ３３０を含む。プレイリスト・マネジャ３３７は、この環境でプレゼンテーション・オブジェクトをコントロールする役割を有する。これらのオブジェクトは、対話型のグラフィックスを生成するように動作するアプリケーションと共に、プレーヤ３０５のビデオ・プレイバックを含む。プレイリスト・マネジャ３３７は、図２に伴うテキストにおいて上述したプレイリスト２９０を管理する。

プレイリストマネジャ３３７は、さらに、メディアストリームにおけるコンテンツのそれぞれの部分に関連した「タイトル時間」を計算する。タイトルは、ＤＶＤ制作者によって決められるのが通常である開始時間及び終了時間を備えたビデオ及びオーディオ・コンテンツの一意的なシーケンスである。しかし、著者がタイトルとして決めるものは任意のことがある。したがって、ビデオにおいて知覚される特定のコンテンツは、１つのタイトルの一部、完全なタイトル、複数のタイトルにわたる場合などがある。

タイトルの１つの例は、米国においてアナログ及びデジタルの両方のフォーマットにおいて、予め記録されたビデオに先行する著作権に関する警告である。ＤＶＤでフィーチャされたアトラクション（例えば、メインの映画）は別の例であり、多くの場合ｍ最長のタイトルである。いくつかのセッティングでは、１つの映画の中の個々の章（チャプタ）が、ＤＶＤ著者によって別個のもとして指定されることもある。すべてのそのようなタイトルについて、メディア・クロック３１２に示されるように、与えられたタイトルが再生を開始して以後に経過している時間をもって、タイトル時間と定義される。

プレゼンテーション・クロック３６０は、プレイリスト・マネジャにライン３６２を介して結合される。プレゼンテーション・クロック３６０はクロックであり、その時間は現実世界のクロックと同じペースで変化する（つまり、プレゼンテーション・クロック３６０が１秒だけ進むには、実時間でも１秒を要する）。メディア・クロック３１２とは対照的に、プレゼンテーション・クロック３６０は停止せず、高速化も低速化もできない。プレゼンテーション・クロック３６０からのプレゼンテーション時間は、「アプリケーション時間」とアプリケーションの「ページ時間」とを計算するためにそれを用いるタスク・マネジャ３３０に送られる。

アプリケーション時間とは、アプリケーションがスタートしてから（又は、より詳細に後述するように、「アクティブな」状態に入ってから）経過した時間である。複数のアプリケーションがランタイムにある場合、それぞれのアプリケーションはそれ自身のアプリケーション時間に関する概念を有する。各アプリケーションについては、アプリケーションがこの環境において開始されると、アプリケーション時間は常にゼロにおいてスタートする。

例えば、アプリケーションＡｐｐ１が２０の任意時間単位（Ａｐｐ１のためのゼロの時間単位）のプレゼンテーション時間で開始し、アプリケーションＡｐｐ２が２５時間単位（Ａｐｐ２に対するゼロ時間単位）のプレゼンテーション時間でスタートした場合には、３５時間単位のプレゼンテーション時間では、アプリケーション１のアプリケーション時間は１５時間単位であり、アプリケーション２のアプリケーション時間は１０時間単位である。論理的に複数のページに分割されるアプリケーションの場合には、ページ時間とは、アプリケーションのページがロードされてから経過した時間である。

図４は、ＩＣＰ４３５、ＶＣＰ４１０及びミキサー４３９を含む第２の例示的なメディア・プレーヤ４０５のブロック図である。対話型メディア・プレーヤ４０５は、図３に示される対話型メディア・プレーヤ３０５に形式及び機能に関して類似している。しかし、ＶＣＰ４３５は、別個のフィード４２５及び４２７をミキサ４３９に提供するように構成されているメディア・プロセッサ１、２、・・・、Ｎ（図４の要素４０４及び４０６で示されている）を含む。このような構成は、個々のメディアストリームの操作がミキシングに先立って行なわれるセッティングで望ましい。例えば、イメージ処理／セレクション技術では、メディア・ストリームにおけるビデオのパニングやズーミング（panning and zooming）は、図４の参照番号４２５及び４２７によって表されるＮ個の別個のフィードの中の１つ又は複数において独立の実現される。

オーディオ／ビデオ・フィード４２５及び４２７は、ＩＣＰ４３５からの同時のとれたグラフィックス・ストリームと共に、ミキサー４３９においてミキシングがなされ、ライン４４１を介して表示装置４５５へ出力される。ＩＣＰ４３５（プレイリスト・マネジャ４３７及びタスク・マネジャ４３０を含む）を含む図４の他の要素と、ＶＣＰ４１０の中のメディア・クロック４１２と、プレゼンテーション・クロック４６０とを含む図４の他の要素は、図３に示し対応の箇所で説明した場合と同様の態様で構成され機能する。

図５は、参照番号５１０、５１５、５１８によって指定される複数のイベント・キュー１、２、・・・、Ｎと単一のアプリケーション・スレッド５２３とを有する構成５００に関するブロック図である。この例示的な構成では、ＩＣＰ（図４のＩＣＰ４３５のような）の上で動作するすべてのアプリケーションが、シングル・スレッド。また、アプリケーション・スレッド５２３は、そのような目的のための専用である。ＩＣＰ４３５は、それ自体は必ずしもシングル・スレッドであることは必要ない。別のインプリメンテーションでは、ＩＣＰ４３５は、キャッシュの中へリソースを予めフェッチするためなど、他のスレッドを利用することがある。

イベント・キュー５１０、５１５及び５１８のそれぞれは、そのヘッド・エンド（図５の右側にある）からアプリケーション・スレッド５２３へ与えるように構成されている。複数のアプリケーションＡｐｐｌ、Ａｐｐ２、．．．、ＡｐｐＮは、参照番号５２７、５３０及び５３２によって指定されているが、それぞれ、代表として参照番号５３５によって指定されているワークアイテム（作業アイテム）をキュー５１０、５１５、５１８の中へそのテール・エンド（図５の左側の）からポストするように構成されている。

アプリケーション・イベントは、アプリケーションによって開始されるイベントである。これらは、スクリプト（例えば図１のスクリプト・ホスト１１５）かマークアップ（例えば図１のマークアップ１２０）のいずれかによって開始されたイベントを含む。アプリケーション・イベントは、ほとんどの場合、スクリプトによってのみ処理される。しかし、アプリケーション５２７、５３０及び５３２は、スクリプト又はマークアップ機能を直接に呼び出さない。その代わり、そのような機能は、すべて、アプリケーション・スレッド５２３がワークアイテムを処理するときに、アプリケーションのそれぞれのイベント・キューにワークアイテムの形式でポストされ、呼び出される。

別の構成では、アプリケーション以外のソースからのイベントも、イベント・キューを用いて予定が決められる。例えば、ユーザ・イベントは、リモート・コントロールを用いてユーザとの対話によって開始される。システム・イベントは、図４に示され以下のテキストにおいて説明されるプレーヤ４０５のような対話型メディア・プレーヤによって開始されるイベントである。

イベント・キュー５１０、５１５及び５１８中のワークアイテムは、それぞれが、図５に示されるようなフィールドを含んでいる。これらのフィールドは、アプリケーション関連付けフィールド５４０、メソッドフィールド５４５、開始時間フィールド５５２、終了時間フィールド５５５及びオプションのクロックセレクタ（クロック選択）フィールド５５８を含む。

アプリケーション関連付けフィールド５４０は、ワークアイテムが適用される特定のアプリケーションを指示する。メソッドフィールド５４５は、ワークアイテムがアプリケーション・スレッド５２３によって処理されるときに呼び出されるメソッドを含む。メソッドフィールド５４５は、更に、当該メソッドに対する引数を含む。

開始時間フィールド５５２及び終了時間フィールド５５５は、ワークアイテムのメソッドがいつ開始しいつ終了するかを示すのに用いられる。この例では、時間は、アプリケーション時間を用いて表現される。しかし、別の例では、開始時間フィールド５５２及び終了時間フィールド５５５は、特定の設定の要件に応じて、タイトル時間、アプリケーション時間又はページ時間で、別に表現される値を含んでいる。そのような場合、ワークアイテムによって用いられる特定の時間フレームは、クロックセレクタ・フィールド５５８に示される。利用された時間フレームとは関係なく、ワークアイテムのための開始時間は、常に終了時間よりも前でなければならない。

図６は、そこに含まれるワークアイテムの順序を示すイベント・キュー５１５のブロック図である。他のイベント・キュー５１０及び５１８（図５）は図解を単純化する目的で図６には含めていない。しかし、以下で述べる順序付けの方法は、他のそのようなイベント・キューに等しく適用可能である。

イベント・キュー５１５は、それぞれが参照番号６０５、６１０、６１５及び６２０によって示されるワークアイテム１、２、３、・・・、Ｎを含む。ワークアイテムは、それぞれが、図５に示され対応する部分で説明されるフィールドを含んでいる。

ワークアイテム６０５は、図６の中のブロック６３０に示されるように、開始時間１と、イベント・キュー５１５へのインサートのための関連する時間ｔ１とを含む。同様に、ワークアイテム６１０は、ブロック６３５に示されるように、開始時間２と、イベント・キュー５１５へのインサートのための関連する時間ｔ２とを含む。ワークアイテム６１５は、ブロック６４０に示されるように、開始時間３と、イベント・キュー５１５へのインサートのための関連する時間ｔ３とを含む。そして、ワークアイテム６２０は、ブロック６４５に示されるように、開始時間Ｎと、イベント・キュー５１５へのインサートのための関連する時間ｔＮとを含む。

この例では、ワークアイテムは、最初は開始時間によって以後はワークアイテムがイベント・キューにインサートされる時間によって、イベント・キュー５１５において順序が決められる。このような順序付けにより、結果的に、アプリケーション・スレッド５２３が、ワークアイテムを、開始時間の順序で、又は、２つのワークアイテムが同一の開始時間を有するときにはＦＩＦＯ（先入先出法）の順序で、処理することになる。

したがって、ワークアイテム６２０はイベント・キュー５１５のヘッドにあるから、開始時間Ｎ＜開始時間３、又は、開始時間Ｎ＝開始時間３の場合にはｔＮ＜ｔ３となる（すなわち、ワークアイテム６２０は、ワークアイテム６１５よりも前にイベント・キュー５１５の中にインサートされる）。ワークアイテム６０５、６１０及び６１５に対して同じ論理付けを用いると、次のようになる。

開始時間３＜開始時間２であるか、又は、
開始時間３＝開始時間２ならば、ｔ３＜ｔ２である。
開始時間２＜開始時間１であるか、又は、
開始時間２＝開始時間１ならば、ｔ２＜ｔ１２である。

イベント・キューの中のワークアイテムの順序付けは、２つの別の方法を用いても行なわれる。すなわち、イベント・キューにインサートされたとき、又は、ワークアイテムが処理に先立ってイベント・キューから抽出されるときには、ワークアイテムが順序付けられる。イベント・キューからのワークアイテムの処理が開始時間とその後のキュー・インサート時間とによって実行される限り、どちらの構成であっても、等しく使用することができる。

図７は、例示的な構成のブロック図であり、アプリケーション・スレッド５２３が、イベント・キュー５１５のテール・エンドの２つのワークアイテム７０５及び７１５を自動的にインサートしている。他のイベント・キュー５１０及び５１８（図５）は、図７では、図解を単純化するために示されていない。しかし、アプリケーション・スレッドによるワークアイテムの自動インサートは、以下で述べるように、他のそのようなイベント・キューに等しく適用可能である。示されるように、自動的にインサートされたワークアイテム７０５及び７１５は、イベント・キュー５１５において、ワークアイテム６０５及び６２０の後に続く。ある例では、アプリケーションがスタートしワークアイテムがそれぞれのチックに対して再度スケジュールを決められるときには、２つのワークアイテムの自動インサートが行なわれる。

ブロック７３０に示されるように、ワークアイテム７０５は、マークアップ・エンジン（例えば図４の中のＩＣＰ４３５に配置されたマークアップ・エンジン）へのコールを含み、アプリケーションＡｐｐ２ ５３０の中のページのタイミングを処理する。ブロック７３５では、ワークアイテム７１５は、マークアップへ呼び出しを含み、処理されたイベントを反映し表示装置（例えば、図４のディスプレイ４５５）においてマークアップをレンダリングするアプリケーションＡｐｐ２のマークアップをリフローする。ワークアイテム７０５及び７１５は、常に、アプリケーション・スレッド５２３によってアプリケーションのティックの中で処理される最後のワークアイテムである。

図８は、対話型メディア環境で生じるイベントに関連するワークアイテムをキューイングする例示的な方法の流れ図である。１つのアプリケーション・スレッドを用いてキューイングをするイベントの例では、この方法は、図４ないし７に示され対応する箇所で説明される構成によって実行される。示されている方法は、それぞれのチックに対して反復的に実行されるのが通常である。

このプロセスは、ブロック８０５で開始する。ブロック８１０では、アプリケーション・スレッド５２３（図５ないし７）は、自由にワークアイテムを処理することができる場合には、最初に、現在のチック又は以前のチックに対応する開始時間を有するイベント・キュー５１５の中のそれぞれのワークアイテムをマーキングする（マークを付する）。アプリケーション・スレッド５２３は、マーキングされたワークアイテムだけを処理する。したがって、イベント・キュー５１５の中のワークアイテムは、その開始時間より前には処理されない。

決定ブロック８１６では、マークを付されたワークアイテムの終了時間が既に経過している場合には、そのワークアイテムは、ブロック８１９に示されるように、イベント・キュー５１５から除去される。この場合には、そのワークアイテムに対する処理は行われない。アプリケーションＡｐｐ２ ５３０がそのページをリロード（再ロード）する場合には、アプリケーションのページ・クロックはゼロにリセットされ、当該アプリケーションのページ・クロックに基づくすべての処理中の（すなわち、キューイングされた）ワークアイテムは、あたかもちょうど終了時間に達したかのように、イベント・キューから削除される。

決定ブロック８１６において、マーキングされたワークアイテムの終了時間がまだ経過していない場合には、制御はブロック８２２に進み、アプリケーション・スレッド５２３はそのワークアイテムを処理する。図６との関係で上述した通り、それぞれのワークアイテムは、イベント・キュー５１５から順に処理される。すなわち、最初は開始時間によって、以後はそれぞれのワークアイテムがイベント・キュー５１５の中にインサートされた時間によって、である。

反復的なイベント及び単発の（つまり、非反復な単一のオカレンス）イベントとは、共に、図８に示される方法を用いて管理される。反復的なイベントは、関連するワークアイテムが次の予定された開始時間と等しい終了時間を有する周期的なイベントを含む。

周期的なイベントは、典型的には、タイマ・イベントやアプリケーション・ドローイング・イベントのようなイベントを含んでいる。例えば、アプリケーションのスクリプト（例えば、図１のスクリプト・ホスト１１５）は、１０秒に１回の割合でコールバックするタイマを作成する場合には、現在の時間に１０秒を加えた時間に等しい開始時間を有するタイマ・ワークアイテムをイベント・キュー５１５に追加する。いったんタイマ・ワークアイテムがイベント・キュー５１５から実行されると、開始時間及び終了時間は更に１０秒を加えることにより調節され、ワークアイテムは新しい開始時間に基づいて適切な位置においてイベント・キュー５１５に再度インサートされる。

可能な場合であれば常に、周期的なイベントは呼び出される。しかし、関連するワークアイテムにおける終了時間が過ぎる前にはアプリケーション・スレッド５２３によって処理できない場合には、特にその呼出しは削除され、次の呼出しは新しいワークアイテムを用いて予定が決められる。

効果としては、本発明によるイベント・キューイング・メソッドによると、イベントが呼び出される時間を示すタイマ・イベントまでパラメータを送ることを可能になる。このパラメータは、関連するワークアイテムにおける開始時間と同じでなければならない。上述したように、周期的なタイマ・イベントと関連するスクリプトは、呼び出された時間に正確に実行されないことがある。しかし、それぞれのワークアイテムはメソッドに対する引数を特定するメソッドフィールド５４５（図５）を含むので、引数の値は、実時間ではなく呼出しの意図した時間を反映する。従って、タイマ・イベントのためのハンドラは、それ自身が処理を行っている時間（つまりチック）を知っている。

単発のイベントは、不確定（ＩＮＦＩＮＩＴＥ）の終了時間を有する対応のワークアイテムを有する。したがって、単発のイベントは、イベント・キュー５１５から削除されない。例えば、単発のイベントが入力イベントである場合、そのイベントのハンドラは、不確定（ＩＮＦＩＮＩＴＥ）の終了時間を備えたイベント・キュー５１５におけるワークアイテムとして予定される。

ブロック８２２に示されるように、処理はコミット・ベースで行なわれる。すなわち、アプリケーション・スレッド５２３は、いったんイベント・キュー５１５からのワークアイテムの処理を開始すると、処理を停止することはない。例えば、長く動作しているスクリプトは異常終了（アボート）することがない。また、例外がスクリプトに順に注入され排除されることもない。そのようなスキームはスクリプトを処理する間はアプリケーション・スレッドを制約することができるが、上述したＩＣＰ（例えば、図４のＩＣＰ４３５）は、ワークアイテムの処理へのコミットがなされている間は動作し続ける他のスレッドを含むように構成されている。別の構成では、コミットされたワークアイテムの後で処理される相対的な開始時間に基づいて新たなイベントがイベント・キュー５１５の中にインサートされるのが望ましい。

ブロック８３０では、マークの付されたワークアイテムの処理中に作成される新たなワークアイテムは、どれも、その開始時間とは無関係に、マークの付されたワークアイテムの後にイベント・キュー５１５にインサートされる。ワークアイテムをマーキングし、コミットし、コミットされたワークアイテムの後にイベント・キュー（ブロック８１０、８２２及び８３０に示されたように）に新しいワークアイテムをインサートするプロセスにより、アプリケーションが何らかの可視的な進行を常に与えられることが保証される。

図８の中のブロック８３５及び８２８で示されるように、そして、図７に示され対応する記載において説明されるように、アプリケーション・スレッドは、自動的に、それぞれのチックに対して、それぞれのアプリケーションのイベント・キューに２つのワークアイテムをインサートする。これらのワークアイテムは、それぞれのアプリケーションのためにマークアップ・エンジンをコールして、アプリケーション・タイミングを評価しマークアップをリフローして表示装置においてレンダリングする。上述のように、ワークアイテムは、アプリケーションの開始時にインサートされ、各チックの後に予定される。さらに、これらの２つのワークアイテムは、常にアプリケーションのチックのために処理される最後の２つであり、イベント・キュー５１５から排除される周期的なイベントとして扱われる。

以上の記載ではデータ、プログラム及びオペレーティング・システムなどそれ以外の実行可能なプログラム成分は離散的なブロック、ボックス又はそれ以外の要素として示されているが、これは、単に、説明を単純化する目的のためである。これらのプログラムやコンポーネントは、異なる記憶装置、メモリ、又は、ホスト・ハードウェアにおける１又は複数のプロセッサによって用いられ処理される処理コンポーネントにおいて様々な時間に存在する。

対話型メディア環境においてアプリケーション状態を管理する様々な例示的な構成及び方法について以上で示し説明したが、特許請求の範囲に記載された発明の範囲は、以上で説明した特定の特徴、構成又は方法には限定されない。むしろ、ここに開示されている特定の特徴、構成又は方法は、対話型メディア環境においてアプリケーションの状態の管理を実現するための例に過ぎない。

Claims (20)

1. 一連のチックを用いて時間が計測される対話型メディア環境において生じるイベントに対応するワークアイテムの処理を管理する方法であって、
   イベント・キューに配置されており現在のチックにおける又は現在のチックよりも前の開始時間を有するワークアイテム（８１０）をマーキングするステップと、
   マーキングされており前記現在のチックよりも後の終了時間を有するワークアイテム（８２２）を処理するステップと、
   マーキングされており前記現在のチックよりも前の終了時間を有するワークアイテムを前記イベント・キュー（８１９）から削除するステップと、
   を含むことを特徴とする方法。
2. 請求項１記載の方法において、ワークアイテムは対話型メディア・アプリケーションによって開始された１又は複数のイベントを表すことを特徴とする方法。
3. 請求項２記載の方法において、前記１又は複数のイベントは前記対話型メディア・アプリケーションにおけるマークアップによって開始されることを特徴とする方法。
4. 請求項２記載の方法において、前記１又は複数のイベントは前記対話型メディア・アプリケーションにおけるスクリプトによって開始されることを特徴とする方法。
5. 請求項１記載の方法において、ワークアイテムは対話型メディア・プレーヤによって生成された１又は複数のイベントを表すことを特徴とする方法。
6. 請求項１記載の方法において、ワークアイテムは前記対話型メディア環境におけるユーザとの対話によって開始された１又は複数のイベントを表すことを特徴とする方法。
7. 一連のチックを用いて時間が計測される対話型メディア環境において生じるイベントに対応するワークアイテムの処理を管理するように構成されたアプリケーション・スケジューラであって、前記ワークアイテムはそれぞれが開始時間と終了時間とを含むタイムスタンプを有する、アプリケーション・スケジューラにおいて、
   前記ワークアイテムをキューイングするイベント・キューであって、ヘッド・エンドとテール・エンドとを有しており、ワークアイテムが前記イベント・キューの前記ヘッド・エンドから処理されるように構成されたイベント・キュー（５１５）と、
   アプリケーション・スレッドであって、
   現在のチック又は以前のチックと対応する開始時間を有するワークアイテムをマーキングするステップと、
   マーキングされたワークアイテムを処理するステップと、
   前記処理の間に生じる新たなイベントと関連するワークアイテムを前記イベント・キューの前記テール・エンドにインサートすることによりマーキングされたワークアイテムに続くようにするステップと、
   を実行するように構成されたアプリケーション・スレッド（５２３）と、
   を含むことを特徴とするアプリケーション・スケジューラ。
8. 請求項７記載のアプリケーション・スケジューラにおいて、前記インサートするステップは前記新たなイベントに対するタイムスタンプとは無関係に実行されることを特徴とするアプリケーション・スケジューラ。
9. 請求項７記載のアプリケーション・スケジューラにおいて、それぞれのワークアイテムは呼び出される方法を指示するフィールド（５４５）と前記方法のための引数とを含むことを特徴とするアプリケーション・スケジューラ。
10. 請求項７記載のアプリケーション・スケジューラにおいて、それぞれのワークアイテムは前記タイムスタンプがタイトル時間で測定されるのかページ時間で測定されるのかアプリケーション時間で測定されるのかを指示するクロック・セクタ・フィールド（５５８）を含むことを特徴とするアプリケーション・スケジューラ。
11. 請求項７記載のアプリケーション・スケジューラにおいて、前記対話型メディア環境において動作しているアプリケーションがそのページを再ロードすると前記アプリケーション・スレッドはすべてのワークアイテムを前記イベント・キューから削除することを特徴とするアプリケーション・スケジューラ。
12. 請求項７記載のアプリケーション・スケジューラにおいて、前記対話型メディア環境におけるすべてのアプリケーションはプレーバック・エンジンの同一のスレッドの上を動作することを特徴とするアプリケーション・スケジューラ。
13. 電子デバイスに配置された１又は複数のプロセッサによって実行されると、対話型メディア環境において生じる反復的イベント及び非反復的イベントと関連するワークアイテムの処理を管理する方法を実行するコンピュータ可読媒体であって、それぞれのワークアイテムは少なくとも開始時間を含むタイムスタンプを有し、前記方法は、
    イベント・キュー（５１５）におけるワークアイテムを、前記イベント・キューへの入力時間と前記入力時間に先行する開始時間とによって順序付けするステップと、
    前記イベント・キュー（５１５）からのワークアイテムを順にコミット・ベースで処理することにより、処理されたワークアイテムと関連するイベントが処理が完了する前に扱われるようにするステップと、
    反復的なイベントと関連するワークアイテムだけを前記イベント・キュー（５１５）から削除するステップと、
    を含むことを特徴とするコンピュータ可読媒体。
14. 請求項１３記載のコンピュータ可読媒体において、前記反復的なイベントは周期的なイベントであることを特徴とするコンピュータ可読媒体。
15. 請求項１３記載のコンピュータ可読媒体において、前記周期的なイベントは次の予定されている開始時間と等しい終了時間を有するワークアイテムによって表されることを特徴とするコンピュータ可読媒体。
16. 請求項１３記載のコンピュータ可読媒体において、前記順序付けするステップはワークアイテムの前記イベント・キュー（５１５）の中へのインサートの間に実行されることを特徴とするコンピュータ可読媒体。
17. 請求項１３記載のコンピュータ可読媒体において、前記順序付けするステップはワークアイテムの前記イベント・キュー（５１５）からの抽出の間に実行されることを特徴とするコンピュータ可読媒体。
18. 請求項１３記載のコンピュータ可読媒体において、ワークアイテム（７３０）を前記イベント・キュー（５１５）の中にインサートし対話型メディア・アプリケーションの中のマークアップ・エンジンをコールしタイミングの変更を評価するステップを更に含むことを特徴とするコンピュータ可読媒体。
19. 請求項１３記載のコンピュータ可読媒体において、ワークアイテム（７３５）を前記イベント・キュー（５１５）の中にインサートし対話型メディア・アプリケーションの中のマークアップ・エンジンをコールし対話型メディア・アプリケーションにおけるマークアップをリフローして前記マークアップを表示装置においてレンダリングするステップを更に含むことを特徴とするコンピュータ可読媒体。
20. 請求項１９記載のコンピュータ可読媒体において、一連のチックを用いて時間が前記対話型メディア環境において計測され、前記インサートされたワークアイテムがそれぞれのチックにおいて最後に処理されることを特徴とするコンピュータ可読媒体。

Images