(57)【要約】  【課題】  映像データの再生進行に伴って様々なプログラムを起動する場合、個々のプログラム間のリソース利用の競合を、好適に調停できる情報記録媒体を提供する  【解決手段】  映像データと、管理情報とが記録されており、管理情報は、映像データにおけるプログラムの有効区間と、その有効区間でプログラムを起動する際、必要となるリソースとを対応づけて示す。再生装置は、このプログラムの有効区間を参照して、複数プログラムによるリソース利用を調停する。【選択図】  図３
2006012369.tif 000002
【特許請求の範囲】
【請求項１】
映像データと、管理情報と、プログラムとが記録されており、
プログラムは、映像データの再生と並行して実行されるものであり、
管理情報は、
映像データの再生時間軸上におけるプログラムの有効区間と、その有効区間でプログラムを起動する際、必要となるリソースとを対応づけて示す
ことを特徴とする情報記録媒体。
【請求項２】
前記管理情報は、リソース利用の競合時におけるプログラムの優先度を示す優先度情報を含む
ことを特徴とする請求項１記載の情報記録媒体。
【請求項３】
前記管理情報は、前記有効区間の開始時にあたって、プログラムを自動実行するか否かを示す起動属性を含む
ことを特徴とする請求項１記載の情報記録媒体。
【請求項４】
前記情報記録媒体には、プレイリストを定義するプレイリスト情報が記録されており、
前記有効区間は、1つ以上のプレイリストから構成されるタイトル区間を用いて表現される
ことを特徴とする請求項１記載の情報記録媒体。
【請求項５】
映像データとプログラムが記録された情報記録媒体を再生する再生装置であって、
前記映像データを再生する再生部と、
前記プログラムを処理するプログラム処理部と、
映像データにおける有効区間と、その有効区間でプログラムを起動する際、必要となるリソースとを対応づけて示す管理情報を保持する保持部と、
管理情報を参照して、プログラムを強制終了する処理、及び、強制終了されたプログラムを復帰する処理を実行するプログラム管理部と
を備えることを特徴とする再生装置。
【請求項６】
前記リソース管理部は、
有効区間の遷移を示すイベントが発生した場合、映像データの現在の再生時点が、前記強制終了プログラムの有効区間内であるか、有効区間外であるかを判定し、有効区間外である場合、強制終了プログラムが保持していた情報を、削除する
ことを特徴とする請求項５記載の再生装置。
【請求項７】
前記リソース管理部は、
プログラムが強制終了されれば、当該プログラムに基づき前記管理情報を更新し、
前記強制終了プログラムの復帰は、前記更新された管理情報に基づいて行われる
ことを特徴とする請求項５記載の再生装置。  
【請求項８】
強制終了されたプログラムの復帰は、
プログラムの強制終了に関する所定の条件情報を取得して、取得した条件に基づき決定される、請求項７記載の再生装置。
【請求項９】
前記所定の条件情報は、ユーザ・プレファレンス情報である、請求項８記載の再生装置。
【請求項１０】
前記ユーザ・プレファレンス情報には、前記強制終了されたプログラムを自動的に再起動するか否かを示す、ことを特徴とする、請求項９載の再生装置。
【請求項１１】
前記強制終了プログラムの復帰は、ランチャー表示によってユーザに通知される、請求項７記載の再生装置。
【請求項１２】
前記ランチャー表示は、前記リソースが回復した場合、表示状態を変更することを特徴とする請求項１１記載の再生装置。
【請求項１３】
前記強制終了プログラムの復帰は、リソース回復時におけるポップアップ表示によって、ユーザに通知される、請求項７記載の再生装置。
【請求項１４】
リソース不足を示すイベントが発生した場合、プログラムの強制終了に関する所定の条件情報を取得して、取得した条件に基づいて、強制終了すべきプログラムを決定し、当該プログラムを強制終了する
ことを特徴とする請求項５記載の再生装置。
【請求項１５】
前記所定の条件情報は、ユーザ・プレファレンス情報である、請求項１４記載の再生装置。
【請求項１６】
前記ユーザ・プレファレンス情報には、ユーザへのポップアップ表示をするかどうかに関する情報が記載されていることを特徴とする、請求項１５記載の再生装置。
【請求項１７】
前記所定の条件情報は、前記管理情報の優先度情報である、請求項１４記載の再生装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像データを記録した情報記録媒体、その再生装置に関し、特に映像データにおける再生進行と同期して、プログラムを起動させたり、強制終了させる場合の改良に関する。
【背景技術】
【０００２】
映画ビジネスにあたっては、映画作品と、その映画作品にゆかりがある様々なアプリケーションとを同じ情報記録媒体に記録して、パッケージメディアとして販売するという形態が見られる。何故なら、ゲームプログラムやクイズプログラム、映画作品に登場するキャラクタを模したペットプログラムを、映画作品本編と同じパッケージメディアに記録しておけば、パッケージメディアの商品価値は高まり、消費者の購入意欲を刺激することができるからである。
【０００３】
それら様々なプログラムを再生装置が実行しようとすると、再生装置に実装されているリソースの利用が、複数プログラム間で競合する。かかる競合が発生した際に、調停を図る技術は、以下の特許文献１に開示されている。
この特許文献１に記載されたリソースの競合調停は、携帯電話上で動作する通信プログラムと、電話帳を編集する編集プログラムとの間で生じるリソース利用の競合を調停するというものである。電話帳編集プログラムの編集中に着信があり、通信プログラムを起動した際、上述したリソース利用の競合が生じる。この場合、特許文献１では、電話帳編集プログラムが利用していたデータをメモリに退避し、保存した上で、通信プログラムを起動する。着信など、何等のイベントが発生した際、そのイベントをトリガにして、リソース調停を図るというのがこの特許文献１に記載された技術の考え方である。
【特許文献１】特開２０００−２２４６６２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで情報記録媒体に記録された映画作品の再生進行に伴って、情報記録媒体に記録された様々なプログラムを実行させたいとの要望が、近年、映画作品の制作者から生じている。しかし映画作品の再生中において再生装置は、様々なリソースを利用して映像データの再生を行っているので、かかる利用状態で様々なアプリケーションを起動しようとすると、プログラム間でリソース利用の競合が生じる。このように映像データの再生進行に伴って、プログラムを実行させようとする場合、個々のプログラム間のリソース競合をどのように調停するかという考えは従来存在しなかった。
【０００５】
また特許文献１に記載された先行技術は、強制終了されたプログラムについての情報を退避しておくというものである。ここで強制終了されたプログラムが、何時復帰するかわからないので、退避された情報をいつまでも保存しておく必要がある。そうすると、強制終了されたプログラムが多ければ多いほど、退避情報が多くなり、メモリリソースを大きく浪費してしまう。
【０００６】
更に、先行技術における強制終了プログラムの復帰は、編集を行うためのリソースが常に存在していることを前提にしている。つまり特許文献１では、通信プログラム、編集プログラムの2つしかないのであるから、通信プログラムの処理が終われば、必ず編集プログラムが利用するリソースを確保できる。しかし現実には、リソース競合が複数のアプリケーション・プログラム間で発生していることが少なくない。そして1つのプログラムを、強制終了から復帰させる場合、そのプログラムが利用するリソースは、完全に回復しているとは限らない。完全回復がないまま、プログラムを復帰させれば、プログラムのハングアップを招きかねない。
【０００７】
本発明の第１の目的は、映像データの再生進行に伴って様々なプログラムを起動する場合、個々のプログラム間のリソース利用の競合を、好適に調停できる情報記録媒体を提供することである。
本発明の第２の目的は、強制終了されたプログラムが多数存在する場合でも、メモリリソースの浪費を防ぐことができる再生装置を提供することである。
【０００８】
本発明の第３の目的は、リソースを利用するプログラムが多数存在する場合でも、強制終了されたプログラムの復帰を安全に実行することができる再生装置を提供することである。
【課題を解決するための手段】
【０００９】
上記第１目的を達成するため、本発明に係る情報記録媒体は、映像データと、管理情報と、プログラムとが記録されており、プログラムは、映像データの再生と並行して実行されるものであり、管理情報は、映像データの再生時間軸上におけるプログラムの有効区間と、その有効区間でプログラムを起動する際、必要となるリソースとを対応づけて示すことを特徴としている。
【００１０】
上記第１目的を達成するため、本発明に係る再生装置は、前記映像データを再生する再生部と、前記プログラムを処理するプログラム処理部と、映像データにおける有効区間と、その有効区間でプログラムを起動する際、必要となるリソースとを対応づけて示す管理情報を保持する保持部と、管理情報を参照して、プログラムを強制終了する処理、及び、強制終了されたプログラムを復帰する処理を実行するプログラム管理部とを備えることを特徴としている。
【００１１】
上記第２目的を達成するため、本発明に係る再生装置における前記リソース管理部は、有効区間の遷移を示すイベントが発生した場合、映像データの現在の再生時点が、前記強制終了プログラムの有効区間内であるか、有効区間外であるかを判定し、有効区間外である場合、強制終了プログラムが保持していた情報を、削除することを特徴としている。
上記第３目的を達成するため、本発明に係る再生装置における前記リソース管理部は、プログラムが強制終了されれば、当該プログラムに基づき前記管理情報を更新し、前記強制終了プログラムの復帰は、前記更新された管理情報に基づいて行われることを特徴としている。
【発明の効果】
【００１２】
第１目的を達成する情報記録媒体は、プログラム起動に必要なリソースを示したリソース情報が、映像データの再生単位毎に記述されているので、このリソース情報を参照することにより、プログラム間のリソース調停を映像データの再生単位毎に行うことができる。つまりプログラムを強制終了したり、また別のプログラムを再起動するとの処理を、映像データの有効区間毎に行うことができる。
【００１３】
第２目的を達成する再生装置は、映像データの再生時点が進行し、リソース競合によって強制終了されたプログラムの有効区間外にまで到達した場合、そのプログラムが使用していたデータを自動的に削除することができるので、メモリの占有量を少なくすることが可能となる。それだけでなく、プログラムの復帰処理等、無駄な処理を実行する必要もなくなる。
【００１４】
ここで第３目的を達成する再生装置は、対応するリソースが利用不可能であることを示すよう、管理情報を更新した上で強制終了を行う。そしてこの管理情報を参照して、復帰を行うので、リソースが不足している場合、その不足に応じた、プログラム復帰を行うことができる。
ここで第３目的を達成する再生装置において前記強制終了されたプログラムの復帰は、プログラムの強制終了に関する所定の条件情報を取得して、取得した条件に基づき決定されてもよい。この前記所定の条件情報は、ユーザ・プレファレンス情報であってもよい。
【００１５】
ユーザの意図にそぐわないリソース競合調停が行われ、プログラムが強制終了された場合、そのプログラムをどのように再起動するかを、ユーザはプレリファレンスにより規定することができる。意図しない振る舞いを行った際のリカバリーを実現できるので、ユーザのニーズを考慮したシステムの構築が可能となる。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施の形態を、図面を参照しながら説明する。
最初に本発明の実施の形態について説明する。本実施例では、ＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）アプリケーションにおいてより豊かなインタラクティブ性の実現と、ＢＤアプリケーションのため、Ｊａｖａ（登録商標）のようなプログラミング環境の導入、および、リソース競合調停からのアプリケーションの復帰に関する内容である。
【００１７】
なお、汎用的なプログラミング環境としてＪａｖａ（登録商標）を想定しているが、Ｃ言語やその他のプログラミング言語であっても、同様である。
（ディスク上の論理データ構造）
図１は、ＢＤ−ＲＯＭ（以降、「ＢＤ」と称する場合もある）の構成、特にディスク媒体であるＢＤディスク（１０４）と、ディスクに記録されているデータ（１０１、１０２、１０３）の構成を示す図である。ＢＤディスク（１０４）に記録されるデータは、ＡＶデータ（１０３）と、ＡＶデータに関する管理情報及びＡＶ再生シーケンスなどのＢＤ管理情報（１０２）と、インタラクティブを実現するＢＤ再生プログラム（１０１）である。本実施の形態では、映画などのＡＶコンテンツを再生するためのＡＶアプリケーションを主眼においてのＢＤディスクの説明を行うが、ＢＤディスクをＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの様にコンピュータ用途の情報記録媒体としてしようすることも当然のことながら可能である。  
【００１８】
図２は、上述したＢＤディスクに記録されている論理データを示した図である。ＢＤディスクは、他の光ディスク、例えばＤＶＤやＣＤなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリード・インと外周のリード・アウトの間に論理データを記録できる論理アドレス空間を有している。また、リード・インの内側にはＢＣＡ（Ｂｕｒｓｔ  Ｃｕｔｔｉｎｇ  Ａｒｅａ）と呼ばれるドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがよくある。
【００１９】
論理アドレス空間には、ファイルシステム情報（ボリューム）を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは、ＵＤＦ（Ｕｎｉｖｅｒｓａｌ  Ｄｉｓｃ  Ｆｏｒｍａｔ）やＩＳＯ９６６０などのことであり、通常のＰＣと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっている。
【００２０】
本実施の形態の場合、ＢＤディスク上のディレクトリ、ファイル構造は、ルートディレクトリ（ＲＯＯＴ）直下にＢＤＶＩＤＥＯディレクトリが置かれている。このディレクトリはＢＤ−ＲＯＭで扱うＡＶコンテンツや管理情報などのデータ（図３で説明した３０１、３０２、３０３）が記録されているディレクトリである。
ＢＤＶＩＤＥＯディレクトリの下には、次の７種類のファイルが記録されている。
【００２１】
ＢＤ．ＩＮＦＯ（ファイル名固定）
「ＢＤ管理情報」の一つであり、ＢＤディスク全体に関する情報を記録したファイルである。ＢＤプレーヤは最初にこのファイルを読み出す。
ＢＤ．ＰＲＯＧ（ファイル名固定）
「ＢＤ再生プログラム」の一つであり、ＢＤディスク全体に関わるプログラムを記録したファイルである。
【００２２】
ＸＸＸ．ＰＬ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ管理情報」の一つであり、シナリオを記録するプレイリスト（Ｐｌａｙ  Ｌｉｓｔ）情報を記録したファイルである。プレイリスト毎に１つのファイルを持っている。
ＸＸＸ．ＰＲＯＧ（「ＸＸＸ」は可変、拡張子「ＰＲＯＧ」は固定）
「ＢＤ再生プログラム」の一つであり、前述したプレイリスト毎のプログラムを記録したファイルである。プレイリストとの対応はファイルボディ名（「ＸＸＸ」が一致する）によって識別される。
【００２３】
ＹＹＹ．ＶＯＢ（「ＹＹＹ」は可変、拡張子「ＶＯＢ」は固定）
「ＡＶデータ」の一つであり、ＶＯＢを記録したファイルである。ＶＯＢ毎に１つのファイルを持っている。
ＹＹＹ．ＶＯＢＩ（「ＹＹＹ」は可変、拡張子「ＶＯＢＩ」は固定）
「ＢＤ管理情報」の一つであり、ＡＶデータであるＶＯＢに関わる管理情報を記録したファイルである。ＶＯＢとの対応はファイルボディ名（「ＹＹＹ」が一致する）によって識別される。
【００２４】
ＺＺＺ．ＰＮＧ（「ＺＺＺ」は可変、拡張子「ＰＮＧ」は固定）
「ＡＶデータ」の一つであり、字幕及びメニューを構成するためのイメージデータＰＮＧ（Ｗ３Ｃによって標準化された画像フォーマットであり「ピング」と読む）を記録したファイルである。１つのＰＮＧイメージ毎に１つのファイルを持つ。
（プレーヤの構成）
次に、前述したＢＤディスクを再生するプレーヤの構成について図３及び図４を用いて説明する。
【００２５】
図３は、プレーヤの大まかな機能構成を示すブロック図である。
ＢＤディスク（３０１）上のデータは、光ピックアップ（３０２）を通して読み出される。読み出されたデータは夫々のデータの種類に応じて専用のメモリに記録される。ＢＤ再生プログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」ファイルの中身）はプログラム記録メモリ（３０３）に、ＢＤ管理情報（「ＢＤ．ＩＮＦＯ」、「ＸＸＸ．ＰＬ」または「ＹＹＹ．ＶＯＢＩ」）は管理情報記録メモリ（３０４）に、ＡＶデータ（「ＹＹＹ．ＶＯＢ」または「ＺＺＺ．ＰＮＧ」）はＡＶ記録メモリ（３０５）に夫々記録される。
【００２６】
プログラム記録メモリ（３０３）に記録されたＢＤ再生プログラムはプログラム処理部（３０７）によって、管理情報記録メモリ（３０４）に記録されたＢＤ管理情報は管理情報処理部（３０８）によって、また、ＡＶ記録メモリ（３０５）に記録されたＡＶデータはプレゼンテーション処理部（３０９）によって夫々処理される。
リソース管理部（３０６）は、ＣＰＵ、メモリ、デコーダ、ネットワーク等、プレーヤが備えているリソースの利用状況を把握する機能を持ち、プログラム処理部（３０７）より、プログラムの起動に際してリソース不足の通知を受けると、管理情報処理部（３０８）よりＢＤ管理情報を受け取り、起動するプログラムを判定して、プログラム処理部（３０７）に通知する。リソース調停の際、起動できなかったプログラム、あるいは、強制終了されたプログラムに関する情報を記憶しておき、リソースが利用可能になると、ユーザに対してユーザ・インターフェイスを介して通知する。ユーザから起動イベントを受け取ると、プログラム処理部（３０７）に通知する。
【００２７】
プログラム処理部（３０７）は、管理情報処理部（３０８）より再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムでは再生するプレイリストを動的に変える事が可能であり、この場合は管理情報処理部（３０８）に対してプレイリストの再生命令を送ることで実現する。プログラム処理部（３０７）は、ユーザからのイベント、即ちリモコンキーからのリクエストを受け、ユーザイベントに対応するプログラムがある場合は、実行処理する。
【００２８】
プログラムは管理情報処理部やプレゼンテーション処理部に指示を出し、プレイリストを介してＡＶストリームを再生するものもあれば、通常のＪａｖａ（登録商標）アプリケーション同様にイメージプレーン（３１０）に対して描画指示を行うものもある。
ＡＶストリームの再生のみを指示するアプリケーションの例としては、本編映画再生をユーザの指示に従って行う単純な再生アプリケーションが挙げられる。ＡＶ再生を行わないアプリケーションの例としては、フル画面をプログラムで描画するゲームのようなアプリケーションが挙げられる。ＡＶを再生しながらアプリケーションとして描画することも可能であり、再生中のＡＶの上にプログラムが描画したイメージ図を重ねたり、移動させてアニメーションを行ったりすることも可能である。
【００２９】
管理情報処理部（３０８）は、プログラム処理部（３０７）の指示を受け、対応するプレイリスト及びプレイリストに対応したＶＯＢの管理情報を解析し、プレゼンテーション処理部（３０９）に対象となるＡＶデータの再生を指示する。また、管理情報処理部（３０８）は、プレゼンテーション処理部（３０９）より基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部（３０９）にＡＶデータ再生の停止指示を行い、また、プログラム処理部（３０７）に対してプログラム実行タイミングを示すイベントを生成する。
【００３０】
プレゼンテーション処理部（３０９）は、映像、音声、字幕／イメージ夫々に対応するデコーダを持ち、管理情報処理部（３０８）からの指示に従い、ＡＶデータのデコード及び出力を行う。映像データ及び字幕／イメージの場合は、デコード後に夫々の専用プレーン、ビデオプレーン（３１１）及びイメージプレーン（３１０）に描画され、合成処理部（３１２）によって映像の合成処理が行われＴＶなどの表示デバイスへ出力される。
【００３１】
図３で示すように、ＢＤプレーヤは図１で示したＢＤディスクに記録されているデータ構成に基づいた構成をとっている。
図４は前述したプレーヤ構成を詳細化したブロック図である。図４では、ＡＶ記録メモリ（３０５）はイメージメモリ（４０８）とトラックバッファ（４０９）に、プログラム処理部（３０７）はプログラムプロセッサ（４０２）とＵＯＰマネージャ（４０３）に、管理情報処理部（３０８）はシナリオプロセッサ（４０５）とプレゼンテーションコントローラ（４０６）に、プレゼンテーション処理部（３０９）はクロック（４０７）、デマルチプレクサ（４１０）、イメージプロセッサ（４１１）、ビデオプロセッサ（４１２）とサウンドプロセッサ（４１３）に、リソース管理部（３０６）はリソースマネージャ（４１８）に夫々対応／展開している。
【００３２】
ＢＤディスク（３０１）から読み出されたＶＯＢデータ（ＭＰＥＧストリーム）はトラックバッファ（４０９）に、イメージデータ（ＰＮＧ）はイメージメモリ（４０８）に夫々記録される。デマルチプレクサ（４１０）がクロック（４０７）の時刻に基づき、トラックバッファ（４０９）に記録されたＶＯＢデータを抜き出し、映像データをビデオプロセッサ（４１２）に音声データをサウンドプロセッサ（４１３）に夫々送り込む。ビデオプロセッサ（４１２）及びサウンドプロセッサ（４１３）は夫々ＭＰＥＧシステム規格で定める通りに、デコーダバッファとデコーダから夫々構成されている。即ち、デマルチプレクサ（４１０）から送りこまれる映像、音声夫々のデータは、夫々のデコーダバッファに一時的に記録され、クロック（４０７）に従い個々のデコーダでデコード処理される。
【００３３】
イメージメモリ（４０８）に記録されたＰＮＧは、次の２つの処理方法がある。イメージデータが字幕用の場合は、プレゼンテーションコントローラ（４０６）によってデコードタイミングが指示される。クロック（４０７）からの時刻情報をシナリオプロセッサ（４０５）が一旦受け、適切な字幕表示が行えるように、字幕表示時刻（開始及び終了）になればプレゼンテーションコントローラ（４０６）に対して字幕の表示、非表示の指示を出す。プレゼンテーションコントローラ（４０６）からデコード／表示の指示を受けたイメージプロセッサ（４１１）は対応するＰＮＧデータをイメージメモリ（４０８）から抜き出し、デコードし、イメージプレーン（４１４）に描画する。
【００３４】
次に、イメージデータがメニュー用の場合は、プログラムプロセッサ（４０２）によってデコードタイミングが指示される。プログラムプロセッサ（４０２）が何時イメージのデコードを指示するかは、プログラムプロセッサ（４０２）が処理しているＢＤプログラ
ムに因るものであって一概には決まらない。
イメージデータ及び映像データは、図３で説明したように夫々デコード後にイメージプレーン（４１４）、ビデオプレーン（４１５）に記録され、合成処理部（４１６）によって合成出力される。
【００３５】
ＢＤディスク（３０１）から読み出された管理情報（シナリオ、ＡＶ管理情報）は、管理情報記録メモリ（４０４）に記録されるが、シナリオ情報（「ＢＤ．ＩＮＦＯ」及び「ＸＸＸ．ＰＬ」）はシナリオプロセッサ（４０５）によって読み出され処理される。また、ＡＶ管理情報（「ＹＹＹ．ＶＯＢＩ」）はプレゼンテーションコントローラ（４０６）によって読み出され処理される。
【００３６】
シナリオプロセッサ（４０５）は、プレイリストの情報を解析し、プレイリストによって参照されているＶＯＢとその再生位置をプレゼンテーションコントローラ（４０６）に指示し、プレゼンテーションコントローラ（４０６）は対象となるＶＯＢの管理情報（「ＹＹＹ．ＶＯＢＩ」）を解析して、対象となるＶＯＢを読み出すようにドライブコントローラ（４１７）に指示を出す。
【００３７】
ドライブコントローラ（４１７）はプレゼンテーションコントローラ（４０６）の指示に従い、光ピックアップを移動させ、対象となるＡＶデータの読み出しを行う。読み出されたＡＶデータは、前述したようにイメージメモリ（４０８）またはトラックバッファ（４０９）に記録される。
また、シナリオプロセッサ（４０５）は、クロック（４０７）の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ（４０２）に投げる。
【００３８】
プログラム記録メモリ（４０１）に記録されたＢＤプログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」）は、プログラムプロセッサ（４０２）によって実行処理される。プログラムプロセッサ（４０２）がＢＤプログラムを処理するのは、シナリオプロセッサ（４０５）からイベントが送られてきた場合か、ＵＯＰマネージャ（４０３）からイベントが送られてきた場合である。ＵＯＰマネージャ（４０３）は、ユーザからリモコンキーによってリクエストが送られてきた場合に、プログラムプロセッサ（４０２）にイベントを生成する。
【００３９】
リソースマネージャ（４１８）は、プログラムの起動に際し、プログラムプロセッサ（４０２）よりリソース不足の通知を受けると、シナリオプロセッサ（４０５）より読み出されたシナリオ情報のうち、「ＢＤ．ＩＮＦＯ」を取得して、起動するプログラムを判定して、プログラムプロセッサ（４０２）に通知する。リソース調停の際、起動できなかったプログラム、あるいは、強制終了されたプログラムに関する情報を記憶しておき、リソースが利用可能になると、ユーザに対してユーザ・インターフェイスを介して通知する。ユーザからリモコンキーによってリクエストが送られてきた場合に、ＵＯＰマネージャ（４０３）から起動イベントを受け取ると、プログラムプロセッサ（４０２）に通知して、記憶されていたプログラムがプログラムプロセッサ（４０２）によって実行処理される。
（ナビゲーションデータ構造）
図５を用いてＢＤディスク全体に関する情報（”ＢＤ．ＩＮＦＯ”）の内部構造について説明をする。
【００４０】
ＢＤディスク全体情報は、タイトルリスト（ＴｉｔｌｅＬｉｓｔ）とグローバルイベント用のイベントテーブル（ＥｖｅｎｔＴａｂｌｅ）から構成されている。
タイトルリスト（ＴｉｔｌｅＬｉｓｔ）は、ディスク内のタイトル数（Ｎｕｍｂｅｒ）と、これに続く各タイトル情報（Ｔｉｔｌｅ＃１〜Ｔｉｔｌｅ＃ｎ）から構成されている。個々のタイトル情報（Ｔｉｔｌｅ）は、タイトルに含まれるプレイリストのテーブル（ＰＬＴａｌｂｌｅ）とタイトル内のチャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）を含んでいる。プレイリストのテーブル（ＰＬＴａｂｌｅ）はタイトル内のプレイリストの数（Ｎｕｍｂｅｒ）と、プレイリスト名（Ｎａｍｅ）即ちプレイリストのファイル名を有している。
【００４１】
タイトルはユーザに認識されるＡＶストリームの再生及びアプリケーションの実行の単位であるが、同時にプレーヤがＡＶストリームの再生及びアプリケーションの実行を管
理する単位でもある。
チャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）は、当該タイトルに含まれるチャプタ数（Ｎｕｍｂｅｒ）と個々のチャプタ情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）から構成され、チャプタ情報（Ｃｈａｐｔｅｒ＃）は当該チャプタが含むセルのテーブル（ＣｅｌｌＴａｂｌｅ）を持ち、セルのテーブル（ＣｅｌｌＴａｂｌｅ）はセル数（Ｎｕｍｂｅｒ）と個々のセルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）から構成されている。セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃）は当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。
【００４２】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、グローバルイベントの数（Ｎｕｍｂｅｒ）と個々のグローバルイベントの情報を持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）と呼ばれ、ＢＤディスクがプレーヤに挿入された時、最初に呼ばれるイベントである。グローバルイベント用イベント情報はイベントタイプ（Ｔｙｐｅ）とイベントのＩＤ（ＩＤ）だけを持っている。
（アプリケーションの管理）
図６はタイトルリスト（６０１）が、アプリケーションの管理単位としてのタイトルを指し示している様子を示している。
【００４３】
タイトル＃１はディスク挿入時に再生されるトップメニューのタイトルである。ディスクが挿入されると、トップメニュー再生用のアプリケーション（６０２）が起動され、トップメニューの再生が開始される。トップメニュー再生用のアプリケーションとともに、ペットを出現させるためのアプリケーション（６０３）も起動させる。
トップメニュー再生から別の目的のタイトルに移りたい場合は、タイトル切り替えを行う。たとえば映画本編を再生アプリケーションを起動させたければ、本編再生を行うタイトル＃２に移動する。
【００４４】
タイトル＃１からタイトル＃２に移動すると、タイトル＃１の場合同様にタイトル＃２に関連したアプリケーション（６０４、６０５）が起動されるとともに、タイトル＃２に関係ないアプリケーション（８０２）は停止する。タイトル＃１にもタイトル＃２にも関係するアプリケーション（８０３）は、どちらのタイトルでも起動し続けることができ、タイトル＃１とタイトル＃２の間のタイトル遷移中に停止と再起動が起こるわけではない。
【００４５】
タイトル＃２は映画本編が再生されるタイトルである。タイトル＃１が選択されると、本編映像再生用のアプリケーション（６０４）が起動され、本編映像の再生が開始される。本編再生用のアプリケーションは、リモコンキーによる早送り・スキップなどのイベントを受けて、再生制御部に指示を出しプレーヤの動作をコントロールする。タイトル＃２が起動されると本編再生用アプリケーションとともに、ポップアップメニューを出現させるためのアプリケーション（６０５）も起動させる。
【００４６】
タイトル＃３はタイトル＃１及びタイトル＃２とは独立したタイトルであり、タイトル＃３が選択されると、タイトル＃１及びタイトル＃２で起動されていたアプリは停止し、タイトル＃３に関連したアプリケーション（６０６）が起動される。
図７はこれまで述べたような、タイトル単位でのアプリケーションの管理を実現するための管理情報について示している。
【００４７】
アプリケーション管理情報（７０１）は、アプリケーションが動作可能な区間を示している有効期間（７０２）、アプリケーションＩＤ（７０３）、タイトル開始時の起動状態（７０４）、リソース競合時にどのアプリケーションを優先して起動するかを判断するための優先度（７０５）、および、アプリケーションが起動するために必要とするリソースの情報（７０６）を管理しており、指定されたタイトル中でどのアプリケーションが起動されるかを管理している。
【００４８】
アプリケーション管理情報に記載されたリソース情報は、アプリケーションを起動する際の判断材料として用いてもよい。あるいは、リソース競合時に、強制的に終了されたアプリケーションの情報を保持しておき、リソースの解放に応じて自動的に再起動する際の必要リソースの確認として使用してもよい。リソースとしては、アプリケーションを起動するために必要となるメモリ量、アプリケーションが使用するスクリーン（画面領域）、ビデオデコーダ、オーディオデコーダ、ネットワーク、リモコンリソース等が挙げられる。
【００４９】
アプリケーションを起動するにあたり、リソース競合が発生する場合、リソース管理部（３０６）でどのアプリケーションを優先して起動するのかを判断するだけでなく、強制終了されたアプリケーションを記憶しておき、リソースが回復した時点でユーザに通知することで、極力ユーザの意思を尊重することが必要である。リソース管理部（３０６）の処理フローに関する詳細は、図９で述べることにして、ここでは割愛する。
【００５０】
アプリケーション＃１は、優先度（７０５）が「２００」、リソース情報（７０６）が「メモリ、スクリーン、ビデオデコーダ、オーディオデコーダ」であり、タイトル＃１開始時に自動的に起動されるアプリケーションである。
アプリケーションの終了の仕方としては、他のアプリやイベントによって終了することもある。このような場合、起動属性がＡｕｔｏＲｕｎ（自動的に起動）であっても、タイトル中で自動的に再起動することはない。タイトルが切り替わり、再びタイトル＃１が開始されたときは、自動的に起動される。
【００５１】
なお、アプリケーションＩＤとしては、Ａｐｐｌｅｔやｘｌｅｔなどの起動インターフェイスを持ったクラスファイル名などでよい。
また、複数のタイトルに対して、同じアプリケーションを登録しておくことにより、タイトルを越えてアプリケーションを起動させ続けることが可能となる。アプリケーション管理情報において、アプリケーション＃２は、優先度（７０５）が「１２０」、リソース情報（７０６）が「メモリ、スクリーン、オーディオデコーダ」であるが、タイトル開始時に自動的に起動はされない。アプリケーション＃２は、他のアプリケーションによって起動される、あるいはユーザ操作などのイベントにより起動される。アプリケーション＃２は、タイトル＃１にもタイトル＃２にも登録されているため、タイトル＃１からタイトル＃２に遷移する際、タイトル＃１終端で終了することなく、タイトル＃２に遷移する。このように複数タイトルに同一アプリケーションを登録しておけば、登録されているタイトル間を遷移する際にアプリケーションが終了後再起動されるようなことはない。
【００５２】
複数タイトルをまたげるアプリケーションであったとしても、登録されていないタイトルに遷移する際は終了される。アプリケーション＃２の例では、タイトル＃２からタイトル＃３（表記せず）に遷移する際は、アプリケーション＃２は終了される。
アプリケーション＃３は、優先度（７０５）が「２００」、リソース情報（７０６）が「メモリ、フルスクリーン、ビデオデコーダ、オーディオデコーダ」であり、前記アプリケーション＃２と同様に起動される。
【００５３】
図８は、タイトル遷移と、図７記載のアプリケーション管理情報（７０１）に従って起動、終了するアプリケーションの様子を示している。ここでは、アプリケーション＃２とアプリケーション＃３でリソース競合が起こった場合を例として挙げる。
まず、ディスク挿入と同時に、タイトル＃１が開始され、アプリケーション＃１が自動的に起動される（８０１）。しばらくすると、アプリケーション＃１がアプリケーション＃２を起動する（８０２）。タイトル＃１が終了すると、アプリケーション管理情報（７０１）にしたがって、アプリケーション＃１は終了される（８０３）。
【００５４】
次に、タイトル＃２が選択されると、アプリケーション＃２とアプリケーション＃３でリソース競合が起こり、リソース管理部（３０６）でリソース競合調停を行う。前記リソース競合調停の結果を受けて、アプリケーション＃２は強制的に終了され（８０４）、アプリケーション＃３が起動される（８０５）。アプリケーション＃３が終了され（８０６）、リソース管理部（３０６）はリソース解放の通知を受けると、アプリケーション＃２を再び起動し（８０７）、タイトル＃２が終了すると、アプリケーション管理情報（７０１）にしたがって、アプリケーション＃２は終了される。
【００５５】
図９は、本発明に係わるリソース管理部（３０６）の処理フローの一例である。ＢＤディスクが挿入されるとリソース管理部は、プログラム処理部（３０７）からのイベントを待つ。
プログラム処理部（３０７）からリソース不足イベントを受け取る（Ｓ１０１）と、リソース管理部は、優先的に起動するアプリケーションを選別して、そのほかのアプリケーションを強制的に終了するアプリケーション強制終了処理（Ｓ１０２）を行う。このステップに関しては、図１０にて詳細に説明することとして、ここでは割愛する。アプリケーションの強制終了が行われると、強制終了されたアプリケーションを復帰させるかどうか判定する（Ｓ１０３）。強制終了されたアプリケーションを復帰させる場合には、不足リソースを確認し（Ｓ１０４）、アプリケーション管理情報を更新する（Ｓ１０５）。更新後のアプリケーション管理情報は、図１１にて詳細に説明することとして、ここでは割愛する。アプリケーション管理情報を更新すると、強制終了されたアプリケーションの復帰処理（Ｓ１０６）を行う。このステップに関しては、図１２にて詳細に説明することとして、ここでは割愛する。強制終了されたアプリケーションを復帰させない場合には、何もせず終了する。
【００５６】
なお、Ｓ１０３の強制終了されたアプリケーションを復帰させるかどうかの判定処理は、その都度ユーザに確認するか、ユーザ・プレファレンスで予め設定できる。ユーザ・プレファレンスとは、ユーザが好みや特徴などを予め入力しておき、その情報を用いて、システムが各種処理を行うことができるようにするための情報である。ユーザ・プレファレンス情報は、電源を切ってもデータを記憶保持する読み書き自在な不揮発性メモリに保存されているものとする。
【００５７】
図１０は、本発明に係わるリソース管理部（３０６）のアプリケーション強制終了に関する処理フローの一例である。
まず、ユーザ・プレファレンス情報を取得する（Ｓ２０１）。取得したユーザ・プレファレンス情報中に、リソース競合調停時には、どのアプリケーションを優先的に起動するかユーザに問い合わせて確認をとるため、ポップアップ表示設定がなされているかどうか確認する（Ｓ２０２）。もし、ポップアップ表示設定がなされている場合には、ポップアップ表示を行い、ユーザの意思を仰ぐ（Ｓ２０４）。ユーザからの選択があれば、強制終了するアプリケーションに対してリソース消失通知を行う（Ｓ２０５）。ポップアップ表示設定もなされておらず、ユーザからの選択もない場合には、アプリケーション管理情報を読み込んで（Ｓ２０６）、優先度にもとづいて強制終了するアプリケーションを判断し（Ｓ２０７）、強制終了するアプリケーションに対してリソース消失通知を行う（Ｓ２０５）。リソース消失通知を行って一定時間経過（Ｓ２０８）しても、アプリケーションが自ら終了処理を行わない場合には、アプリケーションを強制的に終了する（Ｓ２０９）。
【００５８】
図１１は、リソース競合調停に必要な情報を加味して、タイトル単位でのアプリケーションの管理を実現するための管理情報について示している。図９にてアプリケーション管理情報更新後の一例を示している。
アプリケーション管理情報に、新たにリソースが利用可能かどうかを示す利用項目（１１０１）、強制終了されたアプリケーションであるかどうかを示す強制終了フラグ項目（１１０２）を追加している。利用項目は、強制終了フラグが「Ｙｅｓ」である場合にのみ有効（可、不可表記）となり、そうでない場合には無効（−）となる。また、利用項目は、リソース項目と対応しており、リソースが利用可能であれば「可」が、利用可能でなければ「不可」となる。
【００５９】
また、強制終了フラグは、リソース競合調停によって強制的に終了されたアプリケーションに関しては「Ｙｅｓ」、そうでないものに関しては「Ｎｏ」となる。
なお、強制終了された時点でのアプリケーションの状態を保存しておいても良い。アプリケーションの状態の例としては、ゲームアプリケーションを考えるとスコア情報、あるいは、登場キャラクターの状態等が挙げられる。
【００６０】
図１２は、本発明に係わるリソース管理部（３０６）の強制終了アプリケーション復帰に関する処理フローの一例である。
まず、ユーザ・プレファレンス情報を取得する（Ｓ３０１）。取得したユーザ・プレファレンス情報中に、リソース競合調停時には、強制終了されたアプリケーションを復帰する際にランチャー表示設定がなされているかどうか判定する（Ｓ３０２）。ここで、ランチャー表示とは、アプリケーション管理情報中の「強制終了」項目が「Ｙｅｓ」であるアプリケーションをアイコンで一覧表示し、カーソル等で選択することによって簡単に起動できるように表示することを意味している。ランチャー表示設定がなされている場合には、ランチャーを表示し（Ｓ３０３）、そうでない場合には、何もしない。そのうち、イベントを受信する（Ｓ３０４）。受信したイベントが、シナリオ遷移に関するイベントであるかどうか判定する（Ｓ３０５）。もし、シナリオ遷移に関するイベントであった場合には、アプリケーション管理情報中の「強制終了」項目が「Ｙｅｓ」であるアプリケーションの「有効期間」項目の内容と、現在再生されているシナリオ番号とを比較して、有効期間内であるかどうか判定する（Ｓ３０６）。もし、有効期間内ではないと判定された場合には、アプリケーション管理情報の「強制終了」項目を「Ｎｏ」に変更することにより更新して（Ｓ３１６）、終了する。Ｓ３０５の判定にて、シナリオ遷移に関するイベントでないと判定された場合には、リソース解放に関するイベントかどうか判定する（Ｓ３０７）。有効期間内であると判定された場合、あるいは、リソース解放に関するイベントでない場合には、イベントを受信するまで待つ。リソースに関するイベントである場合には、アプリケーション管理情報中の強制終了フラグが「Ｙｅｓ」であるアプリケーションが、再度起動するために必要なリソースがそろったかどうか判断する（Ｓ３０８）。このステップに関しては、図１３で詳細に説明することとして、ここでは説明を割愛する。アプリケーションが起動するために必要なリソースが完全回復かどうか判定し（Ｓ３０９）、そうであれば、強制終了アプリケーションの自動復帰設定がされているかどうか判定する（Ｓ３１０）。もし、自動復帰設定がされていなければ、現在ランチャー表示中かどうか判定する（Ｓ３１１）。ランチャー表示中であれば、ランチャー表示を更新（たとえば、状態に応じて色や大きさを変える）し（Ｓ３１２）、そうでない場合には、ポップアップ表示（Ｓ３１３）でユーザに通知する。リソース未回復である場合には、さらにイベントを待つ。自動復帰設定がされていた場合、あるいは、ユーザがランチャー、ポップアップから起動を選択すると（Ｓ３１４）、強制終了されたアプリケーションは再び起動され（Ｓ３１５）、アプリケーション管理情報の強制終了フラグが「Ｎｏ」に更新される（Ｓ３１６）。
【００６１】
なお、自動復帰設定がされていて、強制終了されたアプリケーションが複数存在する場合には、ユーザに問い合わせて復帰させるアプリケーションを選択してもらう。
図１３は、本発明に係わるリソース管理部（３０６）の強制終了アプリケーション復帰中のリソース回復判断に関する処理フローの一例である。
まず、アプリケーション管理情報を読み込む（Ｓ４０１）。アプリケーション管理情報の強制終了項目が「Ｙｅｓ」であるアプリケーションに関して、解放されたリソースを確認して（Ｓ４０２）、利用項目を更新する（Ｓ４０３）。アプリケーション管理情報の強制終了項目が「Ｙｅｓ」であるアプリケーションの利用項目が全て「可」表示であるかどうか判定して（Ｓ４０４）、そうであればリソース完全回復であり（Ｓ４０５）、そうでなければリソース未回復（Ｓ４０６）であると判定する。
【００６２】
このように、本実施形態では、ＢＤサービスを利用するユーザにとって、リソース競合調停を経て強制終了されたアプリケーションの情報を保持しておき、リソースが回復した時点で自動的にユーザに通知することにより、ユーザがリソースの空き状況を確認して、再度アプリケーションを検索、実行させる手間を省き、容易に強制終了されたアプリケーションを復帰させることができるだけでなく、リソース競合によって強制終了されたアプリケーションが動作範囲外になると自動的に保持している情報を削除することができるので、メモリの消費量を少なくすることが可能となるだけでなくアプリケーションの復帰処理等、無駄な処理を実行する必要もなくなる。
【００６３】
また、上記アプリケーション管理情報に起動に必要なリソース情報を記載することで、アプリケーションの動作を保障して、アプリケーションが動作可能な区間を明確化できる。
【産業上の利用可能性】
【００６４】
本発明によれば、映像データとプログラムとを含むコンテンツの開発にプログラミング環境を導入するため、特に、映像コンテンツの制作に携わる映画産業・民生機器産業において利用される可能性をもつ。
【図面の簡単な説明】
【００６５】
【図１】ＢＤ−ＲＯＭのデータ階層図
【図２】ＢＤ−ＲＯＭ上の論理空間の構成図
【図３】ＢＤ−ＲＯＭプレーヤの概要ブロック図
【図４】ＢＤ−ＲＯＭプレーヤの構成ブロック図
【図５】ＢＤディスク全体管理情報ファイルの構成図
【図６】アプリケーション管理単位の説明図
【図７】アプリケーション管理情報の説明図
【図８】タイトル遷移に応じたアプリケーション状態遷移の説明図
【図９】リソース管理部における処理フロー
【図１０】リソース管理部のアプリケーション強制終了における処理フロー
【図１１】リソース競合調停に必要な情報を加味したアプリケーション管理情報の説明図
【図１２】リソース管理部の強制終了アプリケーション復帰における処理フロー
【図１３】リソース管理部の強制終了アプリケーション復帰中のリソース回復判断における処理フロー
【符号の説明】
【００６６】
１０１    ＢＤ再生プログラム
１０２    ＢＤ管理データ
１０３    ＡＶデータ
１０４    ＢＤディスク
３０１    ＢＤディスク
３０２    光ピックアップ
３０３    プログラム記録メモリ
３０４    管理情報記録メモリ
３０５    ＡＶ記録メモリ
３０６    リソース管理部
３０７    プログラム処理部
３０８    管理情報処理部
３０９    プレゼンテーション処理部
３１０    イメージプレーン
３１１    ビデオプレーン
３１２    合成処理部
４０１    プログラム記録メモリ
４０２    プログラムプロセッサ
４０３    ＵＯＰマネージャ
４０４    管理情報記録メモリ
４０５    シナリオプロセッサ
４０６    プレゼンテーションコントローラ
４０７    クロック
４０８    イメージメモリ
４０９    トラックバッファ
４１０    デマルチプレクサ
４１１    イメージプロセッサ
４１２    ビデオプロセッサ
４１３    サウンドプロセッサ
４１４    イメージプレーン
４１５    ビデオプレーン
４１６    合成処理部
４１７    ドライブコントローラ
４１８    リソースマネージャ
６０１   タイトルリスト
６０２    トップメニューを再生するアプリケーション
６０３    ペットを表示するアプリケーション
６０４   本編映像データを再生するアプリケーション
６０５   ポップアップメニューを表示するアプリケーション
６０６   ゲームアプリケーション
７０１ アプリケーション管理情報
７０２ 有効期間
７０３ アプリケーションＩＤ
７０４  起動属性
７０５  アプリケーションの優先度
７０６  アプリケーションに必要なリソース
７０７  タイトル＃１におけるアプリケーション＃２の登録情報
７０８  タイトル＃２におけるアプリケーション＃２の登録情報
８０１ アプリケーション＃１の起動
８０２  アプリケーション＃１によるアプリケーション＃２の起動
８０３  タイトル終端におけるアプリケーションの終了
８０４  リソース競合調停によるアプリケーションの終了
８０５  アプリケーション＃３の起動
８０６  アプリケーション＃３の終了
８０７  リソース復帰によるアプリケーション＃２の起動
１１０１ リソースの利用可能性
１１０２ リソース競合調停にて強制終了されたかどうかを表すフラグ
Ｓ１０１    リソース不足イベント受信ステップ
Ｓ１０２    アプリ強制終了処理ステップ
Ｓ１０３    強制終了アプリ復帰判定ステップ
Ｓ１０４    不足リソース確認ステップ
Ｓ１０５    アプリ管理情報更新ステップ
Ｓ１０６    強制終了アプリ復帰処理ステップ
Ｓ２０１    プレファレンス取得ステップ
Ｓ２０２    ポップアップ表示設定判定ステップ
Ｓ２０３    ポップアップ表示ステップ
Ｓ２０４    ユーザ選択判定ステップ
Ｓ２０５    リソース消失通知ステップ
Ｓ２０６    アプリ管理情報読み込みステップ
Ｓ２０７    強制終了アプリ判断ステップ
Ｓ２０８    一定時間経過判定ステップ
Ｓ２０９    アプリ強制終了ステップ
Ｓ３０１    プレファレンス取得ステップ
Ｓ３０２    ランチャー表示設定判定ステップ
Ｓ３０３    ランチャー表示ステップ
Ｓ３０４    イベント受信ステップ
Ｓ３０５    シナリオ遷移イベント判定ステップ
Ｓ３０６    有効範囲内判定ステップ
Ｓ３０７    リソース解放イベント判定ステップ
Ｓ３０８    リソース回復判断ステップ
Ｓ３０９    リソース完全回復判定ステップ
Ｓ３１０    自動復帰設定判定ステップ
Ｓ３１１    ランチャー表示中判定ステップ
Ｓ３１２    ランチャー表示更新ステップ
Ｓ３１３    ポップアップ表示ステップ
Ｓ３１４    ユーザ選択ステップ
Ｓ３１５    強制終了アプリ復帰ステップ
Ｓ３１６    アプリ管理情報更新ステップ
Ｓ４０１    アプリ管理情報読み込みステップ
Ｓ４０２    回復リソース確認ステップ
Ｓ４０３    アプリ管理情報更新ステップ
Ｓ４０４    不足リソース有無判定ステップ
Ｓ４０５    リソース完全回復通知ステップ
Ｓ４０６    リソース未回復通知ステップ
【図１】
2006012369.tif 000003
【図２】
2006012369.tif 000004
【図３】
2006012369.tif 000005
【図４】
2006012369.tif 000006
【図５】
2006012369.tif 000007
【図６】
2006012369.tif 000008
【図７】
2006012369.tif 000009
【図８】
2006012369.tif 000010
【図９】
2006012369.tif 000011
【図１０】
2006012369.tif 000012
【図１１】
2006012369.tif 000013
【図１２】
2006012369.tif 000014
【図１３】
2006012369.tif 000015