(57)【要約】【課題】  インタラクティブ・メディア環境において、アプリケーションの寿命に対して論理モデルを作成することによって、アプリケーションを管理する。【解決手段】  モデルは、同時におよび／または連続的に走るアプリケーションに適用することができ、アプリケーション「状態」の構成体を用いたインタラクティブ・メディア環境におけるアプリケーション「状態」（７００）の構成体を用いたインタラクティブ・メディア環境におけるアプリケーションの作成、他のアプリケーションによるアプリケーションの操作、リソースの消費、アプリケーションのユーザに対する可視性、およびアプリケーションの停止を統御する。１組のブール・フラグを利用し、この１組のブール・フラグにおけるエレメントの一意の組み合わせによって、複数のアプリケーション状態（７００）を規定する。【選択図】      図７
2009500725.tif 000002
【特許請求の範囲】
【請求項１】
インタラクティブ・メディア環境においてアプリケーションを管理する方法であって、前記アプリケーションは、ビデオ・ストリームと同期した１つ以上のグラフィック・オブジェクトを供給し、前記方法が、
前記インタラクティブ・メディア環境においてアプリケーション寿命のための論理モデルをイネーブルするステップであって、前記論理モデルが複数のアプリケーション状態（７００）を含む、ステップと、
ブール・フラグ（図５）の一意の組み合わせによって、前記複数のアプリケーション状態（７００）における各アプリケーション状態を規定するステップと、
前記規定したアプリケーション状態にしたがって、実行時中における前記アプリケーションを、前記インタラクティブ・メディア環境における他のアプリケーションと共に、管理するステップと、
を備えた、方法。
【請求項２】
請求項１記載の方法において、前記ブール・フラグ（図６）は、有効、選択、準備完了、ロード終了、進展停止、ロード中、アクティブ、およびエラーを含む複数のブール・フラグから選択する、方法。
【請求項３】
請求項２記載の方法において、前記ビデオ・ストリームに関連するタイトル時間が、前記アプリケーションに対して指定した時間範囲内に納まるときに、前記有効ブール・フラグは真となり、前記有効ブール・フラグが真のときに、前記アプリケーション状態は有効となる、方法。
【請求項４】
請求項３記載の方法において、前記指定した時間範囲は、アプリケーション・プレーリスト（２９０）に含まれ、該プレーリスト（２９０）は、前記インタラクティブ・メディア環境に対する誘導または同期または初期構成を記述する、方法。
【請求項５】
請求項４記載の方法において、World Wide Web Consortiumが規定するＸＭＬ文書ファイル（１２）のようなマークアップ文書に、前記アプリケーション・プレーリスト（２９０）をエンコードする、方法。
【請求項６】
請求項１記載の方法において、前記管理するステップは、前記アプリケーション状態に応じて、前記インタラクティブ・メディア環境において利用可能なリソースを前記アプリケーションに割り当てることを含む、方法。
【請求項７】
請求項２記載の方法において、前記アプリケーションの静的属性が前記インタラクティブ・メディア環境におけるプレーヤ・オブジェクトの現行の動的属性と一致するとき、前記選択ブール・フラグは真となり、前記選択ブール・フラグが真のとき、前記アプリケーション状態は選択となる、方法。
【請求項８】
請求項２記載の方法において、前記アプリケーション状態が有効になると、前記準備完了ブール・フラグは真となり、前記準備完了ブール・フラグが真のき、前記アプリケーション状態は準備完了となる、方法。
【請求項９】
請求項８記載の方法において、前記準備完了ブール・フラグを前記アプリケーションのオートラン・フラグと関連付けることによって、前記アプリケーション状態が有効になったときに、前記オートラン・フラグを準備完了に設定する、方法。
【請求項１０】
請求項１記載の方法において、前記アプリケーションは、ビデオ・ストリームとフレーム同期する１つ以上のグラフィック・オブジェクトを提供する、方法。
【請求項１１】
請求項２記載の方法において、前記有効、選択、および準備完了のブール・フラグが全て真のとき、前記アプリケーションはアクティブ状態にある、方法。
【請求項１２】
請求項１記載の方法において、前記アプリケーションは、目録ファイル（２３０）において特定された、０以上のスクリプト・ファイル（１１７）と、０以上のマークアップ文書（１２０）とを有するスクリプト・ホスト（１１５）を含む、方法。
【請求項１３】
請求項１２記載の方法において、前記マークアップ文書（１２０）は、単独論理ＸＭＬ文書ファイルであり、ＸＭＬ<include>エレメントを用いることにより、複数の物理的ファイルを含むことができる、方法。
【請求項１４】
請求項１２記載の方法において、前記アプリケーションは、更に、前記１つ以上のスクリプト・ファイル（１１７）および前記０または１つのマークアップ文書（１２０）に利用可能なリソース（１２５）を含む、方法。
【請求項１５】
インタラクティブ・メディア環境において用いるためのインタラクティブ・メディア・プレーヤ（３０５）であって、
複数のフレームを有するストリーミング・ビデオを備えたビデオ・オブジェクト（３２５）を処理するビデオ・コンテンツ・プロセッサ（３１０）と、
複数のアプリケーション・オブジェクトを処理するインタラクティブ・コンテンツ・プロセッサ（３３５）であって、各アプリケーション・オブジェクトが、前記ビデオ・オブジェクト（３２５）と同期する１つ以上のグラフィック・オブジェクト（３２１）を提供する、インタラクティブ・コンテンツ・プロセッサ（３３５）と、
前記インタラクティブ・コンテンツ・プロセッサ（３３５）上で動作し、アプリケーション状態にしたがって前記アプリケーション・オブジェクトを管理するアプリケーション・マネージャ（３３０）であって、前記アプリケーション状態が、マークアップ文書（１２０）に記載されたブール・フラグの一意の組み合わせによって規定される、アプリケーション・マネージャと、
を備えた、インタラクティブ・メディア・プレーヤ。
【請求項１６】
請求項１５記載のインタラクティブ・メディア・プレーヤ（３０５）において、前記アプリケーション状態は、更に、永続的アプリケーション状態と一過性アプリケーション状態とを含む、インタラクティブ・メディア・プレーヤ。
【請求項１７】
請求項１５記載のインタラクティブ・メディア・プレーヤ（３０５）において、前記グラフィック・オブジェクトとビデオとの間の同期性は、時間同期、フレーム同期、およびコンテンツ同期の１つから選択する、インタラクティブ・メディア・プレーヤ。
【請求項１８】
インタラクティブ・メディア環境において実行中のアプリケーションを停止する方法であって、前記アプリケーションは、ビデオ・ストリームと同期する１つ以上のグラフィック・オブジェクトを提供し、前記方法が、
（ａ）前記インタラクティブ・メディア環境においてプレーヤ上で走っている現タイトルを休止させる（８２５）ことにより、前記アプリケーションを有効状態に保持して、前記ビデオ・オブジェクトに関連するタイトル時間が、前記アプリケーションに対する指定した時間範囲に納まるようにするステップと、
（ｂ）停止イベントを前記アプリケーションにおける停止イベント・ハンドラに送る（８２８）ステップと、
（ｃ）前記停止イベント・ハンドラが真の値を返すまで（８３３）、ステップ（ｂ）を繰り返すステップと、
（ｄ）前記現タイトルの再生を再開する（８４５）ステップと、
（ｅ）前記アプリケーションと関連のあるいずれのスクリプト・ホストおよびいずれのマークアップ文書も削除する（８４８）ことにより、前記アプリケーションを停止するステップと、
を備えた、方法。
【請求項１９】
請求項１８記載の方法であって、更に、前記停止イベント・ハンドラが真の値を返すまで、他のアプリケーションの活性化を保留するステップを含む、方法。
【請求項２０】
プロセッサによって実行されたとき請求項１８の方法を実行する命令がエンコードされた少なくとも１つのコンピュータ読み取り可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の申告）
本願は、２００５年７月１日に出願した仮特許出願第６０／６９５，９４４号の優先権を主張する。その内容は、ここで言及したことにより、本願にも含まれるものとする。
（技術分野）
記載する構成、システム、および方法は、一般的には、インタラクティブ・メディアに関し、更に特定すれば、インタラクティブ・メディア環境におけるアプリケーション状態の管理に関する。
【背景技術】
【０００２】
インタラクティブ・メディア環境は、この環境において走るアプリケーションに利用可能な処理能力、メモリ、およびその他のリソースに関して制約があるのが通例である。馴染みのあるインタラクティブ・メディアの一例に、ＤＶＤ（ディジタル・バーサタイル・ディスク）上にエンコードしたビデオがあり、ユーザはグラフィカル・メニューと対話して特定のビデオ・コンテンツまでたどり着くか、またはＤＶＤ内に著作されている特殊な機構を呼び出すことができる。
【０００３】
更に複雑なインタラクティブ・メディア環境では、リソースが限られているにも拘わらず、多数のアプリケーションを同時に走らせても、これらが衝突してビデオのようなメディア・コンテンツが止まってしまったりそれ以外の混乱を生ずることがないようにしなければならいことが予見される。加えて、特定のインタラクティブ体験を定めるために用いられる全てのアプリケーションは、常に見えており、ユーザに利用可能でなければならない。また、リソースの制約のために、アプリケーションを分割しある時間間隔で順次走らせなければならない場合もある。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
このような場合、リソースの衝突を防止するために、連続するアプリケーション間において淀みない遷移が必要となる。
【課題を解決するための手段】
【０００５】
インタラクティブ・メディア環境において、アプリケーションの寿命に対して論理モデルを作成することによって、アプリケーションを管理する。インタラクティブ・メディア環境におけるアプリケーションを用いて、ビデオ・オブジェクトと同期を取るようにグラフィカル・オブジェクトを作成および操作して、豊富なインタラクティブ体験を創作する。モデルは、同時におよび／または連続的に走るアプリケーションに適用することができ、アプリケーションの作成、他のアプリケーションによるアプリケーションの操作、リソースの消費、アプリケーションのユーザに対する可視性、およびアプリケーション「状態」の構成体(construct)を用いたインタラクティブ・メディア環境におけるアプリケーションの停止を統御する。
【０００６】
ブール・フラグの集合を利用し、このブール・フラグ集合における要素の一意の組み合わせが複数のアプリケーション状態を規定する。多数のアプリケーションは、通例、同時に走り、各々が状態間を移動し、アプリケーションおよびユーザとの対話処理を規定するスクリプト（例えば、Ecma Internationalが標準化したECMAScript）やマークアップ言語（例えば、World Wide Web Consortium (W3C)拡張可能マークアップ言語（ＸＭＬ）文書ファイル）に応じて、環境内におけるその実行時寿命(runtime lifetime)の間遷移状態を占有する。
【０００７】
環境におけるコンテンツのプレゼンテーション挙動を制御し、環境におけるアプリケーションの各々のアプリケーション状態に応じて、イベント、ピクチャ、サウンド、フォントのような、インタラクティブ・メディア環境におけるリソースを管理（例えば、アプリケーションによる割り当て、使用、および消費）する。
【０００８】
ブール・フラグ・モデルを用いたアプリケーション状態管理を実施する。例示の構成では、インタラクティブ・メディア・プレーヤを用いる。これは、インタラクティブ・コンテンツ・プロセッサおよびビデオ・コンテンツ・プロセッサを備えており、グラフィクスおよびビデオをリアル・タイムで同期を取って混合する。インタラクティブ・メディア・プレーヤは、何らかの設定をした専用ハードウェアにおいて実現するか、あるいはパーソナル・コンピュータにあるような汎用プロセッサと共にコンピュータ読み取り可能媒体を用いたソフトウェア実現例を用いて実現する。
【０００９】
図示する例では、ブール・フラグ集合は、有効、選択、準備完了、ロード終了、およびアクティブを含む要素を有する。ブール・フラグ集合は、プロセスにおける停止、ロード中、エラーという追加の要素を含むように拡張することもできる。
【００１０】
アプリケーション状態管理は、プロセッサ・サイクルおよびメモリを含むハードウェア・リソースが制限されている場合に、インタラクティブ・メディア著作者が多数のアプリケーションをリアル・タイムの設定で実施するための安定で予測可能な方法論を提供するという利点がある。加えて、論理アプリケーション状態管理モデルは、インタラクティブ・メディア著作者に、ディスク毎に容易にカスタム化することができる１つのアプリケーション「ライブラリ」を使用し、異なる言語を用いるが、共通のメニュー・ロジックを利用して、インタラクティブ・グラフィカル・メニューを実施することを可能にする。
【発明を実施するための最良の形態】
【００１１】
図１を参照すると、インタラクティブ・メディア環境において用いられるアプリケーション１１０を構成するエレメントのブロック図の一例が示されている。アプリケーションは、ユーザと、リモコンのようなユーザ・インターフェースを通じて、結合されているディスプレイ・デバイス上にグラフィクスやビデオをレンダリングするインタラクティブ・メディア・プレーヤとの間の双方向処理を可能にするために、インタラクティブ・メディア環境において用いられるのが通例である。更に具体的には、アプリケーションは、環境において、ビデオ再生を含む、種々のコンテンツ・オブジェクトのプレゼンテーション挙動を制御する。メニューやインタラクティブ・ボタンのようなグラフィック・オブジェクトのビデオ上でのプレゼンテーションも、アプリケーションを用いて実現する。更に、アプリケーションは環境においてオーディオ再生および音響も管理および制御する。尚、一般に、多数のアプリケーションが殆どのインタラクティブ・メディア設定で同時に走ることを想定する。しかしながら、多数のアプリケーションが同時に走ることは必須要件ではなく、特定の設定においてアプリケーションを分割または集合させる判断は、インタラクティブ・メディア著作者の設計上の選択である。また、アプリケーションは、特定の設定の要件に応じて、論理的にアプリケーション・ページに細分割することもできる。
【００１２】
アプリケーション１１０は、スクリプト・ホスト１１５を備えている。スクリプト・ホスト１１５は、０個以上のスクリプト・ファイル１１７および１１９と、０個以上のマークアップ文書１２０とを収容し、文書オブジェクト・モデル（ＤＯＭ）を生成するために用いられる。マークアップ文書１２０は、例えば、グラフィック・オブジェクトのコンテンツ、様式、タイミング、およびレイアウトに関する情報を含む。このように、マークアップ・コンテキストは、一般に、インタラクティブ・メディア環境においてグラフィック・プレーン上にグラフィクスを供給するために用いられる。
【００１３】
この図示の例では、マークアップ言語は、Ｗ３Ｃ規格に準拠したＸＭＬ文書ファイルである。図１に示すように、マークアップの<head>セクションにおける<include>エレメントを用いて、多数の物理的ＸＭＬファイルにアクセスすることができる。設定によっては、アプリケーションが一度に１つよりも多いアクティブなマークアップを有さないことが好ましい場合もある。しかしながら、アプリケーションは、マークアップにおける<link>エレメントを用いることによって、そのマークアップ１２０を切り換えることもできる。あるいは、アプリケーションは、現行のアプリケーション内部の機能オブジェクトへのアクセスを当該アプリケーションが得ることを可能にするアプリケーション・プログラミング・インターフェース（ＡＰＩ）を利用することによって、そのマークアップ１２０を切り換えることもできる。ＡＰＩを通じてloadMarkup()コールを用いると、アプリケーションは、ＡＰＩを通じて新しいマークアップのユニフォーム・リソース識別子（ＵＲＩ）を受け渡すことによって、マークアップ・ファイル１２０を切り換えることができる。
【００１４】
アプリケーションが新しいマークアップにアクセスする場合、ＡＰＩコールが有効になるのは、アプリケーションにおける現行のイベント・ハンドラがその現行のタスクを実行し終えた後である。新しいマークアップが一旦ロードされれば、これらのイベント・ハンドラを無効にするので、現行のマークアップに関連するイベント・ハンドラはいずれも、保留中の場合でも取り消される。
【００１５】
この図示の例では、スクリプト・ホスト１１５は、スクリプト・ファイル１１７および１１９を収容する。これらは、マークアップ１２０と共に、インタラクティブ・メディア体験を実施するために用いられる。スクリプト・ファイル１１７および１１９は、例えば、ECMA-262仕様書におけるEcma Internationalによって規定されるECMAScriptを用いて実施することができる。FCMA-262に該当する共通スクリプティング・プログラミング言語には、JavaScriptおよびJScriptが含まれる。設定によっては、ホスト環境および１組の共通ＡＰＩと共に、ECMAScript２６２の部分集合、具体的には、ECMA-327を用いて、スクリプト１１７および１１９を実施することが望ましい場合もある。殆どの設定において、システム・イベント、グラフィクス制御、ビデオ再生、リソース管理（例えば、キャッシュまたは永続的記憶リソース）、およびマークアップ１２０のみを用いて容易にまたは効率的に実施できないその他の問題(issue)と共に、ユーザからのインタラクティブ制御問題に対処するために、スクリプト・コンテキストを利用する。
【００１６】
ＡＰＩおよびリソースのアプリケーション１１０に対する可用性は、図１において参照番号１２５で示す。リソースは、たとえば、オーディオおよびビデオ・ファイル、フォント、ピクチャおよび画像（例えば、ＰＮＧ、ＪＰＥＧ、ＧＩＦ、ＢＭＰ、ＴＩＦＦ等を含む共通のファイル・フォーマット）、ならびに、特定の設定の状況に応じてアプリケーションが必要とし得るその他のリソースを含む。
【００１７】
各アプリケーション１１０は、スクリプトの変数、関数およびその他の状態についてのコンテキストを維持する、それ自体のスクリプト・ホスト１１５を維持する。殆どの設定では、アプリケーションが、例えば、全てのアプリケーションにわたって共有されるオブジェクトを用いることによって相互アプリケーション可視を可能にするように具体的に設定していなければ、１つのアプリケーションにおける変数および関数は、別のアプリケーションには見ることができない。例えば、この図示の例では、インタラクティブ・メディア・プレーヤ・オブジェクトは、１つのインスタンスを有し、これが全てのアプリケーションによって共有されている。したがって、任意に、例えばＣ＋＋オブジェクトを用いて、特殊なオブジェクトをスクリプト・ホスト１１５内部に配置して、シングルトン(singleton)（即ち、インスタンス化が制限されているオブジェクト）を実施することができ、全ての特殊オブジェクトは、例えば、プレーヤの同じ内部関数を参照する。この任意の形態では、インタラクティブ・メディア・スクリプトの著作者が、論理的に共通オブジェクトをシングルトンのように扱いつつ、１つのスクリプト・ホストにオブジェクトを露出するのに必要な機能性をスクリプト・ホスト１１５に実施させることを可能にする。
【００１８】
これより図２を参照すると、多数のマークアップ文書およびスクリプト間の関係を示す図の一例が設けられている。アプリケーション目録２３０が、先に記したように、図示のようにリソース１２５、スクリプト２０５、ならびにマークアップ文書２５１、２６０および２７５によって総合的に規定されるアプリケーションと双方向処理を行う。各アプリケーションは、通例、殆どの設定において１つのアプリケーション目録ファイルを用いるが、アプリケーション目録は、アプリケーションの実行時状態の一部ではない。この図示の例では、アプリケーション目録２３０は、ＸＭＬ文書ファイルとしてエンコードされている。
【００１９】
アプリケーション目録２３０は、アプリケーション１１０（図１）が用いる初期マークアップ・ファイル２５１、およびスクリプト・ファイル１１５（図１）に収容されている、図２における参照番号２０５を有する矩形によって集号笛に示されているスクリプト・ファイルを記述する。この図示の例におけるように、アプリケーション目録２３０が１つよりも多いスクリプトを掲示する場合、インタラクティブ・メディア・プレーヤにおいて全てのスクリプトがスクリプト・ハンドリング・エンジンにロードされる。つまり、多数のスクリプト・ファイルは、スクリプト著作者が全てのスクリプト・ファイルを連結して、アプリケーション目録２３０に掲示されている準に１つの大きなファイルにまとめたかのように、扱われそして振る舞う。
【００２０】
図２に示すように、アプリケーション目録２３０はリソース１２４を参照する。インタラクティブ・メディア環境においてアプリケーションに利用可能なリソースは、アプリケーション目録２３０において参照されるリソース１２５を基とする有向グラフを形成する。アプリケーション毎に許容されるグラフの範囲は、アプリケーション目録２３０によって禁止される。
【００２１】
図２は、インタラクティブ・メディア環境において走るアプリケーションを示す。先に記したように、アプリケーションは、一度に１つのアクティブ・マークアップのみを有することができ、アプリケーション・コンテンツはアプリケーションによって別々に保持されている。スクリプト２０５を通じた、マークアップ・ページ２５１、２６０および２７５の間の矢印によって示すように、アプリケーションはマークアップ・ページ２５１から２６０に、次いでその後ページ２６０から２７５に進むことができる。
【００２２】
インタラクティブ・メディア環境におけるアプリケーションによるコンテンツ実行の進展は、プレーリスト２９０によって誘導される。プレーリスト２９０は、とりわけ、プレーヤによってディスプレイ・デバイス上にレンダリングされるプレゼンテーション・オブジェクトを含む、環境におけるオブジェクト間の関係を記述する。これらのプレゼンテーション・オブジェクトは、アプリケーションによって生成したビデオ（以下で更に詳しく説明するような多数のストリームを含むことができる）およびグラフィクスを含むのが通例である。
【００２３】
更に、プレーリスト２９０は、インタラクティブ・メディア環境全体においてリソースを１つの管理実体として管理し、アプリケーションによるリソースの消費を効率的に割り当てそして制御する。アプリケーション目録２３０と同様、プレーリスト２９０は、殆どの設定においてＸＭＬ文書ファイルとして実施すると便利である。
【００２４】
図２におけるマークアップ・ページは、設定によっては、イベントに発火して(fire)実行コンテキスト（図１のスクリプト・ファイル１１７および１１９によって作成する）を得るために用いることができる。次いで、実行コンテキストは、現行のアプリケーション・マークアップによって作成されたＤＯＭを操作する。環境におけるオブジェクトの様式、コンテンツ、タイミング、およびレイアウト（図２におけるエレメント２５４、２６２および２７７によって表す）を指定するために、インタラクティブ・メディア環境においてマークアップを用いるので、スクリプトおよびマークアップの組み合わせにより、能力の総合的な集合の作成が可能となる。
【００２５】
図３は、インタラクティブ・コンテンツ・プロセッサ（ＩＣＰ）３３５、ビデオ・コンテンツ・プロセッサ（ＶＣＰ）３１０、およびミキサ３３９を含むインタラクティブ・メディア・プレーヤ３０５の一例のブロック図である。尚、図３に呈示する構成は、アプリケーション状態管理に関係する図示のインタラクティブ・メディア・プレーヤ３０５の機構および関数を記述する論理モデルを規定することを記しておく。つまり、インタラクティブ・メディア・プレーヤの実際の実現例は、種々の構造形態を利用しつつも、アプリケーション状態管理の便益を達成するために、ここに記載されているように、動作することができる。インタラクティブ・メディア・プレーヤ３０５は、通例、単体消費者用電子デバイスのような専用ハードウェアによって、あるいは、パーソナル・コンピュータにあるような汎用プロセッサと共にコンピュータ読み取り可能媒体を用いたソフトウェア実現例を用いて実現する。
【００２６】
ＶＣＰ３１０は、ＤＶＤドライブまたは高品位ＤＶＤ（ＨＤ−ＤＶＤ）ドライブのようなローカル光ドライブ、ローカル・メモリ、あるいはネットワークを通じたリモート・ブロードバンド・ソースを含む多数のソースから受信することができる１つ以上のメディア・ストリームを管理する。この図示の例では、ＶＣＰ３１０は、１つ以上のメディア・プロセッサ１，２．．．Ｎを含み、図３においてエレメント３０４および３０６によって示されている。メディア・プロセッサ３０４および３０６は、通例、オーディオおよびビデオを含む、受信したメディア・ストリームを処理して、対応する画像および音響をデコードおよびレンダリングし、オーディオ／ビデオ・ストリームとしてライン３２５上に出力する。オーディオ／ビデオ・ストリーム３２５は、例えば、「ピクチャ・イン・ピクチャ」型の構成を用いて多数の別個のビデオ・ウィンドウをレンダリングするために、複数のビデオ・エレメントを表すことができる。
【００２７】
メディア・プロセッサ３０４および３０６は、各々、メディア・ソース・インターフェース、デマルチプレクサ、およびデコーダを備えている。メディア・プロセッサ３０４および３０６は、任意に、解読能力も含んでもよい。ディスプレイ・デバイス３５を結合し、オーディオ／ビデオ・ストリームを受信し表示する。
【００２８】
メディア・クロック３１２は、受信した各メディアが関連する「メディア時間」を有するように利用する。インタラクティブ・メディア・プレーヤ３０５上でビデオ・ストリームが休止した場合、メディア・クロック３１２も休止させる。ユーザが実際の時間よりも速くまたは遅く進むようにビデオ・ストリームを設定した場合（例えば、ビデオを早送り、巻き戻し、またはスロー・モーション・モードにするとき。これらのモードのいずれを用いる場合も「トリック・プレー」と呼ぶ）、メディア・クロック３１２もそれに応じて高速化または低速化する。つまり、メディア時間は、メディア・クロックならびにメディア・プロセッサ３０４および３０６の動作から得られる。メディア時間は、ライン３１５を通じてＩＣＰ３３５内のプレーリスト・マネージャ３３７に渡される。
【００２９】
ＩＣＰ３３５は、全てのアプリケーション関連処理を行い、ハードウェア、ソフトウェア、ファームウェア、またはその組み合わせで実現することができる数個のコンポーネントで構成することができる。ＩＣＰ３３５のコンポーネントは、例えば、マークアップ・プロセッサ、スクリプト言語インタプリタ、およびＸＭＬ解析コンポーネント（図示せず）を含む。ＩＣＰ３３５は、ライン３２１上にグラフィクス・ストリームを出力する。グラフィクス・ストリームは、オーディオ／ビデオ・ストリーム３２５と同期が取られている。ミキサ３３９は、ライン３２１上のグラフィクス・ストリーム、およびライン３２５上のオーディオ／ビデオ・ストリームを取り込み、グラフィック・レイヤにおいてビデオ・ストリーム上にグラフィクスをレンダリングして、ユーザのためにインタラクティブ・メディア・セッションを実施する。
【００３０】
殆どの設定では、ＩＣＰ３３５が出力するグラフィクスは、フレーム毎に、ビデオ・ストリームと同期が取られている。しかしながら、このような同期は、例えば、時間（以下で規定するようなタイトル時間およびメディア時間）、ビデオにおけるコンテンツ、あるいはビデオに埋め込まれストリームにおける特定の時点を示すまたは印すために用いられるその他のメタデータを含む、その他の基準を用いても行うことができる。
【００３１】
ＩＣＰ３３５は、プレーリスト・マネージャ３３７およびタスク・マネージャ３３０を含む。プレーリスト・マネージャ３３７は、環境においてプレゼンテーション・オブジェクトを制御することを責務とする。これらのオブジェクトは、プレーヤ３０５上のビデオ再生を、インタラクティブ・グラフィクスを発生するために走っているアプリケーションと共に含む。プレーリスト・マネージャ３３７は、図２に添付刷るテキストにおいて先に述べたプレーリスト２９０を管理する。
【００３２】
また、プレーリスト・マネージャ３３７は、メディア・ストリームにおけるコンテンツの各部分に関連する「タイトル時間」も計算する。タイトルとは、通例ＤＶＤ著作者によって開始および終了時間が規定される、ビデオおよびオーディオ・コンテンツの一意のシーケンスである。しかしながら、このような著作者がタイトルと規定するものは任意であることができる。つまり、ビデオにおいて知覚される個々のコンテンツは、１つのタイトル、完全なタイトル、または多数のタイトルに跨るラン(run)の一部であるとすることができる。
【００３３】
タイトルの一例に、著作権警告がある。これは、米国においてアナログおよびディジタル・フォーマット双方で予め記録されているビデオ全ての前に位置する。ＤＶＤ上の特徴をなす呼び物（例えば、主要なムービー）は、別の例であり、多くの場合最も長いタイトルである。設定によっては、ムービーにおける個々の章が、ＤＶＤ著作者によって別個のタイトルに指定されている場合もある。このようなタイトル全てについて、タイトル時間は、メディア・クロック３１２上に示すタイトルが再生を開始してから経過した時間と規定する。
【００３４】
プレゼンテーション・クロック３６０がライン３６２上でプレーリスト・マネージャに結合されている。プレゼンテーション・クロック３６０は、実世界の時計と同じペースで時間が変化するクロックである（即ち、プレゼンテーション・クロック３６０が１秒進むには、実時間で１秒かかる）。メディア・クロック３１２とは対照的に、プレゼンテーション・クロック３６０は、決して止まらず、速くすることも遅くすることもできない。プレゼンテーション・クロック３６０からのプレゼンテーション時間をタスク・マネージャ３３０に受け渡し、タスク・マネージャ３３０は「アプリケーション時間」およびアプリケーション「ページ時間」を計算するためにこれを用いる。
【００３５】
アプリケーション時間とは、アプリケーションが開始して（または以下で更に詳しく述べる「アクティブ」状態に入って）以来経過した時間のことである。多数のアプリケーションが実行中である場合、各アプリケーションはそれ自体のアプリケーション時間の表記(notation)を有する。アプリケーション毎に、アプリケーション時間は常に、環境においてアプリケーションを起動したときに、ゼロから開始する。
【００３６】
例えば、プレゼンテーション時間が２０任意時間単位（Ａｐｐ１にとって０時間単位）のときにアプリケーションＡｐｐ１が開始し、プレゼンテーション時間が２５時間単位（Ａｐｐ２にとって０時間単位）のときにアプリケーションＡｐｐ２が開始した場合、プレゼンテーション時間が３５時間単位のときに、Ａｐｐ１のアプリケーション時間は１５時間単位であり、Ａｐｐ２のアプリケーション時間は１０時間単位となる。論理的にページに細分化されているアプリケーションでは、ページ時間は、アプリケーションのページをロードして以来経過した時間である。
【００３７】
図４は、ＩＣＰ４３５、ＶＣＰ４１０、およびミキサ４３９を含むメディア・プレーヤ４０５の第２例のブロック図である。インタラクティブ・メディア・プレーヤ４０５は、図３に示すインタラクティブ・メディア・プレーヤ３０５と形態および機能が類似している。しかしながら、注記すべきは、ＶＣＰ４３５がメディア・プロセッサ１、２．．．Ｎを含み（図４においてエレメント４０４および４０６で示す）、これらが別個のフィード４２５および４２７をミキサ４３９に供給するように構成されていることである。このような構成は、ミキシングの前に個々のメディア・ストリームの操作を行うような設定では望ましい場合もある。例えば、メディア・ストリームにおけるビデオのパンニングおよびズーミングのような画像処理／選択技法を、図４において参照番号４２５および４２７で表すＮ個の別個のフィードの内１つ以上において独立して実施することができる。
【００３８】
ビデオ／オーディオ・フィード４２５および４２７は、ＩＣＰ４３５からの同期グラフィクス・ストリームと共に、ミキサ４３９において混合され、ライン４４１からディスプレイ・デバイス４５５に出力される。ＩＣＰ４３５（プレーリスト・マネージャ４３７およびタスク・マネージャ４３０を備えている）、ＶＣＰ４１０におけるメディア・クロック４１２、およびプレゼンテーション・クロック４６０を含む、図４におけるその他のエレメントは、図３に示し添付した本文において記載したこれらの同等物と同様に構成され機能する。
【００３９】
これより、アプリケーションの寿命を管理するために作成された論理モデルの更に詳細な説明に移る。図５は、ブール・フラグを藻チタ、アプリケーション状態管理の第１の例示的な例において用いられる５つ１組のエレメントを示す。図示のように、この１組は、有効、選択、準備完了、ロード終了、およびアクティブというエレメントを備えている。この図示例では、アプリケーションが「有効」状態となるのは、タイトル時間がプレーリスト２９０（図２）におけるアプリケーションに対して指定した所定の時間範囲以内にあるときである。したがって、トリップ・プレーの結果、アプリケーションは有効になる場合もあることを記しておく。例えば、別の形態のトリック・プレー（早送り、巻き戻し、またはスロー・モーションに加えて）がＤＶＤの章員で楠を用いることによって、タイトルのある地点まで「ジャンプ」する。タイトルの特定の章にジャンプすると、現タイトル時間が、プレーリスト２９０に規定されている特定のアプリケーションにとって有効範囲内に入ることもあり得る。
【００４０】
アプリケーションが「選択」状態にあるのは、アプリケーションの静的属性がインタラクティブ・メディア・プレーヤ３０５の現ダイナミクス属性と一致するときである。静的属性とは、経時的に変化しない属性のことである。例えば、著作者が、プレーリスト２９０（図２）を組み立てて、特定の言語に結びつけるようにアプリケーションを規定する場合がある。インタラクティブ・メディア・プレーヤ３０５（図３）は、ユーザが選択した言語を用いて動作するようにアプリケーション・ランタイムに設定することができる。このように、プレーヤの現言語がダイナミック属性となる。何故ならこれは前もって決定されないからである。この例で更に続けると、メニュー・システムをフランス語で実施するように著作者がアプリケーションを設計し、次いでユーザがプレーヤ３０５の言語をフランス語に設定した場合、フランス語のメニュー・アプリケーションが選択状態に入る。逆に、アプリケーションが常に選択されていることも可能である。例えば、アプリケーションの著作者が言語を指定しない場合（つまり、アプリケーションがプレーヤ３０５に選択したいずれの言語でも一致する）、そのアプリケーションの静的属性、即ち、言語がプレーヤ３０５の現ダイナミック属性と一致するので、このアプリケーションが選択されることになる。
【００４１】
グループ識別（グループＩＤ）は、インタラクティブ・メディア・プレーヤ３０５のダイナミック属性を一致させることによって、アプリケーションを選択状態にさせるために用いることができる静的属性の別の例である。この場合、アプリケーションのグループに、インタラクティブ・メディア・セッション中のある時点において、例えば、ゲームを開始したときに、アクセスすることができる。次いで、先の例と同様に、グループＩＤがなく、したがって現在選択されているグループに依存しなければ、アプリケーションは常に選択状態となることができる。
【００４２】
一旦アプリケーションが有効になると（即ち、有効ブール・フラグが「真」になると）、オートラン（AutoRun）を実施するアプリケーションは「準備完了」状態となる。例えば、アプリケーションは、ビデオ・プログラムにおける所与の時点で常に開始する「ポップアップ」（即ち、下地のビデオを記述する疑似事実(factoid)を有する小さなテキスト・バルーン）を発生するために、オートランを用いることができる。
【００４３】
アプリケーションを準備完了状態に設定する第２のメカニズムは、ＡＰＩにアクセスし準備完了フラグを設定することである。ここでは、アプリケーションのオートラン属性が偽に設定されている場合、別のアプリケーションがＡＰＩを通じて当該アプリケーションの準備完了フラグを真に設定しなければならない。
【００４４】
有効、選択、および準備完了に設定されたアプリケーション（即ち、有効、選択、および準備完了ブール・フラグが真）は、リソースをロードし始める。ロードが完了すると、アプリケーションは「ロード終了」に設定される。
【００４５】
アプリケーションが「アクティブ」状態に設定されるのは、それが有効、選択、準備完了、およびロード終了であるときである（即ち、有効、選択、準備完了、およびロード終了ブール・フラグが真）。アプリケーションがアクティブのとき、そのアクティブ・ブール・フラグは真に設定される。アクティブ・ブール・フラグを用いることによって、アプリケーション停止時に、メモリを解放し、有効、選択、および準備完了フラグが再度設定される可能性がある場合に、あらゆる曖昧さを回避する。
【００４６】
図６は、ブール・フラグを用いたアプリケーション状態管理の第２の例示的な例において用いられる８つ１組に拡張したエレメントを示す。図５に示し、添付した本文に記載した図示の例と同様、拡張した１組のエレメントは、有効、選択、準備完了、ロード終了、およびアクティブというエレメントを含む。拡張した１組は、更に、停止、進行中、ロード中、およびエラーを含む。
【００４７】
図７に示し、添付した本文に記載するように、アプリケーションが「ロード中」状態にあるのは、活性化しており、アクティブ状態に移る前にロードしている間だけそこに留まる場合である。「停止進行中」状態に入るのは、以下で図８に示し添付する本文に記載する方法にアプリケーションが関与しているときである。
【００４８】
アプリケーションが「エラー」状態に設定されるのは、致命的なエラー（即ち、アプリケーションを、通常突然に、クラッシュまたはフリーズさせるエラーであり、そのためにアプリケーションはそれ自体では回復することができない）の場合である。エラー状態を使用することにより、致命的なエラーが発生したときに、アプリケーションをアイドルに引き戻すことが可能になる。
【００４９】
図５および図６は、ブール・フラグを用いたアプリケーション状態管理を実施するために用いることができる２組のエレメントを示す。しかしながら、これらのエレメント組は、インタラクティブ・メディア環境においてアプリケーションの寿命を管理するために有効な論理モデルを例示するために用いられていることを強調しておく。つまり、個々の状況において用いられるエレメントの数および選択は、それぞれの個々の要件に応じて変化することもあり得る。
【００５０】
図７は、アプリケーションの一過性および永続的状態を示す状態機械７００の図である。図示のように、２３の異なるアプリケーション状態が図には含まれている。各ボックス内部には、状態（および対応するブール・フラグ）、有効、選択、準備完了、およびロード終了が、それぞれ、「Ｖ」、「Ｓ」、「Ｒ」、および「Ｌ」と省略されている。したがって、例えば、あるタイトルが開始すると、図の最上部に示すように、ボックス７１０におけるアプリケーションは、それぞれ、ボックス７１７および７１５で示す選択または有効状態のいずれかに入ることができる。これに応じて、図７に示す図では、ブール・フラグが真のときは、Ｓ＝１およびＶ＝１で示されている。
【００５１】
ボックス７１５においてアプリケーションが有効状態にある（したがって、ブール・フラグＶ＝１）場合、アプリケーションは、Ｒ＝１のボックス７２６における準備完了状態に移動することができる。先に記したように、アプリケーションは、ＡＰＩコールActive()を呼び出すことによって、またはアプリケーションをオートランに設定すると（その場合、オートラン（AutoRun）＝１）、準備完了状態になることができる。図に示すように、準備完了になるには、アプリケーションが有効でなければならない。
【００５２】
ボックス７１５において、アプリケーションを選択し、ブール・フラグＳ＝１である場合、既に有効になっているので、アプリケーションはロード終了となり、Ｌ＝１である。ボックス７３０周囲の破線で示すように、「ロード中」状態は一過性である。何故なら、アプリケーションは、この状態を経由して永続的状態間で移動するからである（図７における永続的状態は、実線で示されている）。アプリケーションが活性化しているとき（即ち、アクティブ状態に入っているとき）、実際に機能的にプレーヤにロードする（即ち、そのマークアップを解析し、スクリプトを解釈し、必要なリソースを特定し、キャッシュする）のに十分な長さだけロード中状態となり、次いで、図７におけるボックス７３９で示すように、アクティブ状態に進む。
【００５３】
図８は、インタラクティブ・メディア・アプリケーションを停止する方法の一例を示すフロー・チャートである。アプリケーションは、ある最終処理を停止の一部として実行しなければならない場合があることは認められよう。例えば、ムービー・ビデオにおけるある章と同期されているインタラクティブ・ゲームは、タイトルが終了するときにユーザのスコアを保存しなければならない場合がある。アプリケーションがその有効時間を終了すると（即ち、有効状態にはない）、有効でないにも拘わらず、プログラム・コードを実行し、スクリプトに対する多数のコールバックを行って、保存（非同期の入出力を暗示する）を実行しなければならない。そして、スクリプトを実行するために、アプリケーションは、有効でないにも拘わらず、リソース上にい続けなければならない。このような結果は、リソース管理に対する単独責務を有するプレーリスト２９０（図２）の観念に反する。
【００５４】
したがって、アプリケーションは、有効である間に、停止処理を終了するのに十分な時間を常に確保しておかなければならない。しかしながら、アプリケーションは十分な時間を確保できない場合もあり、このような場合、アプリケーションを停止する特定のプロセス続いて実行する。例えば、アプリケーションの有効時間を超えるトリップ・プレーまたはジャンプが行われると、ビデオおよびその他のアプリケーションを開始する前に、アプリケーションが停止を完了しなければならない。
【００５５】
このプロセスはブロック８１０において開始する。判断ブロック８１５において、アプリケーションがリスナを「OnShutdown」イベントに登録したか否か判定を行う。登録していない場合、ブロック８１９に示すように、アプリケーションは有効の間に通常に停止することが許される。次いで、プロセスはブロック８２１において終了する。
【００５６】
アプリケーションがOnshutdownイベント・リスナを登録した場合、プロセスはブロック８２５に進み、現行のタイトルを解析する。タイトルを解析することによって、タイトル時間を凍結し、その結果、アプリケーションがスクリプトを走らせている間は、有効のままとなる。更に、タイトル時間が進まなければ新たな追加のアプリケーションが有効になることができないので、リソースの衝突が発生する可能性はない。プレゼンテーション・クロック（それぞれ図３および図４における３６０および４６０）は進み続け、  メディア時間は一時停止してアプリケーションにその停止処理を続けさせているが、アプリケーションのアプリケーション時間およびページ時間を進ませる。
【００５７】
ブロック８２８において、ハンドラが真の値を返すまで、OnShutdownイベントを繰り返しアプリケーション（即ち、イベント・リスナ）におけるハンドラに送る。これは、判断ブロック８３３に示す通りである。アプリケーションがイベント・リスナを用いる必要がない場合、アプリケーションはアプリケーションの停止時にスクリプトを走らせる必要がなく、ビデオ・ストリームに悪影響を及ぼす機会は最小限であると仮定することができる。したがって、ブロック８２５および８４５に示すプロセス（休止および再開）を最適化することができる。
【００５８】
一旦OnShutdown イベントがアプリケーションによって処理されたなら、ブロック８４５に示すように、現タイトルを再開する。ブロック８４８において、スクリプト・ホストおよびマークアップをアプリケーションから削除する。任意に、これら最後の２つのステップの順序を逆転させて、現タイトルの再開の前に、スクリプト・ホストおよびマークアップの削除を行うようにしてもよい。プロセスはブロック８５５において終了する。
【００５９】
停止時にスコアを保存しなければならないインタラクティブ・ゲームを可能にするアプリケーションの特定の場合、著作者は、ムービー・ビデオが「通常に」章から章に進展する（即ち、トリック・プレーの使用がない）ときに生ずる典型的な停止の場合を容易に処理することができる。この場合、アプリケーションの著作者が、プレーリスト２９０（図２）において有効状態のアプリケーション時間を延長して、後続のムービー・ビデオの章において典型的な停止プロセスを実行するのに十分な有効時間が得られるようにすることを予期することができる。
【００６０】
任意に、著作者は、ムービー・ビデオの章の最後に実行するコールバック・プロセスを呼び出し、コールバックを用いて保存動作を処理するようにタイマを設定することができる。この場合、（通常の進展であるが、トリック・プレーの進展ではない）、アプリケーションはonShutdownイベントに対するそのイベント・リスナを除去することによって、前述の最適化を実施することができる。
【００６１】
尚、以上の説明における例示の明確さおよび容易さのために、データ、プログラム、およびオペレーティング・システムのようなその他の実行可能プログラム・コンポーネントを離散ブロック、ボックス、またはその他のエレメントで示したことを記しておくが、このようなプログラムおよびコンポーネントは、種々の時点において異なるストレージ、メモリ、または用いられるあらゆるハードウェアの処理コンポーネントに存在する可能性があり、このようなホスト・ハードウェアにおける１つ以上のプロセッサによって実行されることは認められると共に、このことを強調しておく。
【００６２】
インタラクティブ・メディア環境においてアプリケーション状態を管理する構成および方法の種々の例を示し説明したが、これに添付する特許請求の範囲は、記載した特定の機構、構成、および方法には必ずしも限定される訳ではないことは言うまでもない。逆に、特定の機構、構成、または方法は、以下で更に特定的に特許請求する、インタラクティブ・メディア環境においてアプリケーション応対の管理を実施する形態例として開示したのである。
【図面の簡単な説明】
【００６３】
【図１】図１は、インタラクティブ・メディア環境において用いられるアプリケーションを構成するエレメントを示すブロック図の一例である。
【図２】図２は、多数のマークアップ文書およびスクリプト間における関係を示す図の一例である。
【図３】図３は、インタラクティブ・コンテンツ・プロセッサ、ビデオ・コンテンツ・プロセッサ、およびミキサを含むインタラクティブ・メディア・プレーヤの第１例のブロック図である。
【図４】図４は、インタラクティブ・メディア・プレーヤの第２例のブロック図である。
【図５】図５は、ブール・フラグを用いたアプリーション状態管理の第１の例示的な例において用いられる５つで１組のエレメントを示す。
【図６】図６は、ブール・フラグを用いたアプリーション状態管理の第２の例示的な例において用いられる８つで１組のエレメントを示す。
【図７】図７は、一過性および永続的アプリケーション状態を示す状態機械の図である。
【図８】図８は、インタラクティブ・メディア・アプリケーションを停止する方法の一例を示すフロー・チャートである。
【図１】
2009500725.tif 000003
【図２】
2009500725.tif 000004
【図３】
2009500725.tif 000005
【図４】
2009500725.tif 000006
【図５】
2009500725.tif 000007
【図６】
2009500725.tif 000008
【図７】
2009500725.tif 000009
【図８】
2009500725.tif 000010
【国際調査報告】
2009500725.tif 000011