ＢＤ−ＲＯＭには、ＡＶＣｌｉｐ及びプレイリスト情報からなるプレイリストと、アプリケーションと、ＢＤ−Ｊ Ｏｂｊｅｃｔとが記録されている。アプリケーションは、仮想マシン向けプログラミング言語で記述されたプログラムであり、仮想マシンによる実行が可能となる生存区間が、予め規定されている。前記ＢＤ−Ｊ Ｏｂｊｅｃｔには、プレイリスト管理テーブルが含まれている。プレイリスト管理テーブルは、アプリケーションの生存区間において、各アプリケーションの実行と同時に行うべきプレイリストの再生制御を示す。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想マシンを対象にしたアプリケーションの実行を制御する、アプリケーション制御の技術分野に属する発明であり、本制御技術をＢＤ−ＲＯＭ等の映画作品頒布のための記録媒体、ＢＤ−ＲＯＭを対象とした再生装置等に応用する場合の応用技術に深く係る。
【背景技術】
【０００２】
Ｊａｖａ（登録商標）プログラミング等、仮想マシンを対象にしたアプリケーション制御技術は、パソコンソフトの業界において深く浸透している。パソコンソフトから更に発展して、現在、Ｂｌｕ−ｒａｙ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（ＢＤ−ＲＯＭ）用再生装置における再生制御をＪａｖａ（登録商標）プログラミングで実現するための様々な工夫が検討されている。
同様の再生装置についての先行技術としては、以下の特許文献１に記載されたものが知られている。
【特許文献１】特許２８１３２４５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、Ｊａｖａ（登録商標）プログラミングで作成されたアプリケーションの動作というのは、リソースの使用状況やＣＰＵの負荷により変動を受ける不安定なものである。リソースが枯渇していたため、アプリケーションの起動に失敗したり、アプリケーションが異常終了したりして装置がブラックアウトするのは、パソコンソフトの業界では”よくあること”で済まされるかもしれないが、ＢＤ−ＲＯＭ再生装置の製造に携わる民生機器の分野では品質問題になりかねない。品質問題への波及がありうるので、メーカ各社は、Ｊａｖａ（登録商標）プログラミングによる装置制御の実現に二の足を踏むことが多かった（注；ブラックアウトとは、装置のソフトウェアがフリーズして表示画面が真っ暗になる状態をいう）。
【０００４】
本発明の目的は、記録媒体に対する制御を実現するようなアプリケーションが異常終了した場合、又は、起動に失敗した場合の、Ｆａｉｌ Ｓａｆｅを実現することができる記録媒体を提供する。
【課題を解決するための手段】
【０００５】
上記目的を達成するため、本発明に係る記録媒体はアプリケーションと、デジタルストリームと、管理情報とが記録されていて、前記アプリケーションは、仮想マシン向けプログラミング言語で記述されたプログラムであり、仮想マシンによる実行が可能となる生存区間が、予め規定されており、前記管理情報は、生存区間において、アプリケーションの実行と同時に行うべきデジタルストリームの再生制御を示すことを特徴としている。
【発明の効果】
【０００６】
本発明に係る記録媒体によれば、アプリケーション実行と同時に行うべきデジタルストリームの再生制御が生存区間毎に規定されている。そのため、アプリケーションの起動に失敗したり、アプリケーションの実行の途中でたとえアプリケーションが異常終了したとしても、同時になされているデジタルストリーム再生を継続することにより、”何かが写っている状態”をもたらすことができる。これにより、装置がブラックアウトしてしまうという最悪ケースを回避することができるので、装置を製造するメーカに、最低限度の安心感を与えることができる。
【０００７】
こうした安心感が与えられるので、品質問題への波及に神経を尖らせているメーカ各社に対しても、Ｊａｖａ（登録商標）アプリケーションによる再生装置制御の開発を強く後押しすることができる。こうした強い後押しにより、再生装置の低価格化、多様化が進めば、ＢＤ−ＲＯＭコンテンツの充実化を図ることができるので、コンテンツ関連産業の発達を強く牽引することができる。
【図面の簡単な説明】
【０００８】
［図１］本発明に係る再生装置の使用行為についての形態を示す図である。
［図２］ＢＤ−ＲＯＭにおけるファイル・ディレクトリ構成を示す図である。
［図３］ＰＬ情報の構成を示す図である。
［図４］ＡＶＣｌｉｐ時間軸と、ＰＬ時間軸との関係を示す図である。
［図５］４つのＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅによりなされた一括指定を示す図である。
［図６］ＰＬｍａｒｋ情報の内部構成を示す図である。
［図７］ＰＬｍａｒｋによるチャプター定義を示す図である。
［図８］ＳｕｂＰａｔｈ情報の内部構成を示す図である。
［図９］ＳｕｂＰｌａｙＩｔｅｍ時間軸上の再生区間定義と、同期指定とを示す図である。
［図１０］Ｍｏｖｉｅ Ｏｂｊｅｃｔの内部構成を示す図である。
［図１１］ＢＤ−Ｊ Ｏｂｊｅｃｔの内部構成を示す図である。
［図１２］（ａ）Ｊａｖａ（登録商標）アーカイブファイルに収められているプログラム、データを示す図である。
【０００９】
（ｂ）クラスファイルの内部構成を示す図である。
［図１３］ディスクコンテンツにおける状態遷移を示す図である。
［図１４］ＨＤＭＶモードの動的シナリオから構成されるＴｉｔｌｅを示す図である。
［図１５］ＢＤ−Ｊモードの動的シナリオ（ＢＤ−Ｊ Ｏｂｊｅｃｔ）により構成されるＴｉｔｌｅの内部構成を示す図である。
［図１６］プレイリスト管理テーブルをもたないＴｉｔｌｅを示す図である。
［図１７］ＨＤＭＶモードのＴｉｔｌｅから、ＢＤ−ＪモードのＴｉｔｌｅへの分岐を示す図である。
［図１８］ＢＤ−ＪモードのＴｉｔｌｅから、ＨＤＭＶモードのＴｉｔｌｅへの分岐を示す図である。
［図１９］ｉｎｄｅｘ．ｂｄｍｖの内部構成を示す図である。
［図２０］（ａ）アプリケーション管理テーブルの内部構成を示す図である。
【００１０】
（ｂ）アプリケーション管理テーブルを構成する情報要素の意味内容を示す図である。
［図２１］（ａ）ＢＤ−ＲＯＭ全体の時間軸を示す図である。（ｂ）ＢＤ−ＲＯＭ全体の時間軸における構成を示す図である。
［図２２］（ａ）（ｂ）ＢＤ−ＲＯＭ全体の時間軸において、識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−Ｊ Ｏｂｊｅｃｔから特定されるタイトル再生区間を示す図である。
［図２３］図２２（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。
［図２４］本編タイトル、オンラインショッピングタイトル、ゲームタイトルという３つのタイトルを含むディスクコンテンツを示す図である。
［図２５］（ａ）（ｂ）アプリケーション管理テーブル、生存区間の一例を示す図である。
［図２６］起動属性がとり得る三態様（Ｐｒｅｓｅｎｔ、ＡｕｔｏＲｕｎ、Ｓｕｓｐｅｎｄ）と、直前タイトルにおけるアプリケーション状態の三態様（非起動、起動中、Ｓｕｓｐｅｎｄ）とがとりうる組合せを示す図である。
［図２７］（ａ）プレイリスト管理テーブルの内部構成を示す図である。
【００１１】
（ｂ）プレイリスト管理テーブルを構成する情報要素の意味内容を示す図である。
［図２８］分岐先Ｔｉｔｌｅがとり得る三態様（プレイリスト管理テーブル無し、プレイリスト管理テーブル有りで尚且つＰｒｅｓｅｎｔ、プレイリスト管理テーブル有りで尚且つＡｕｔｏＰｌａｙ）と、直前タイトルにおけるＰＬの状態（非再生状態、再生中状態）とがとりうる６通りの組合せを示す図である。
［図２９］（ａ）プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例を示す図である。
【００１２】
（ｂ）図２９（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。
［図３１］（ａ）プレイリスト管理テーブルの他の記述例を示す図である。
【００１３】
（ｂ）図３０（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。
［図３１］（ａ）〜（ｃ）プレイリスト時間軸と、タイトルの再生区間との関係を示す図である。
［図３２］本発明に係る再生装置の内部構成を示す図である。
［図３３］ＲＯＭ２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。
［図３４］Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１〜モジュールマネージャ３４による処理を模式化した図である。
［図３５］アプリケーションマネージャ３６による処理を模式化した図である。
［図３６］Ｕｓｅｒ Ｅｖｅｎｔ Ｍａｎａｇｅｒ３７〜Ｄｅｆａｕｌｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ４０を示す図である。
［図３７］Ｊａｖａ（登録商標）仮想マシン３８の内部構成を示す図である。
［図３８］アプリケーション終了の４態様を示す図である。
［図３９］アプリケーションマネージャ３６による処理手順を示す図である。
［図４０］プレイリスト管理テーブル、アプリケーション管理テーブルの具体例を示す図である。
［図４１］（ａ）第２実施形態に係るＢＤ−Ｊ Ｏｂｊｅｃｔの内部構成を示す図である。
【００１４】
（ｂ）エラー管理テーブルの内部構成を示す図である。
［図４２］エラー管理テーブルにおける５つのフラグの意味内容を示す。
［図４３］（ａ）エラー管理テーブルが記述された２つのＴｉｔｌｅ（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２）を示す図である。
【００１５】
（ｂ）図４３（ａ）のように記載されたアプリケーション管理テーブル、エラー管理テーブルに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。
［図４４］第２実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。
［図４５］第２実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。
［図４６］アプリケーションマネージャ３６による通知処理の処理手順を示すフローチャートである。
［図４７］第３実施形態に係るアプリケーションマネージャ３６の処理手順を示す図である。
［図４８］（ａ）パレンタルレベルに基づく選択アルゴリズムの内容を示す。
【００１６】
（ｂ）Ｌａｎｇｕｅｇｅ ｆｏｒ Ａｕｄｉｏに基づく選択アルゴリズムの内容を示す。
（ｃ）Ｐｌａｙｅｒ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ｆｏｒ Ｖｉｄｅｏに基づく選択アルゴリズムの内容を示す。
［図４９］タイトルアンバウンダリーアプリケーションにＰＬ選択を行わせる過程を模式的に描いた図である。
［図５０］Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２によるＰＬ再生手順を示すフローチャートである。
［図５１］アングル切換、ＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔの受付手順を示すフローチャートである。
［図５２］ＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔＡＰＩがコールされた際の処理手順を示すフローチャートである。
［図５３］Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１による処理手順の詳細を示すフローチャートである。
［図５４］ＳｕｂＰｌａｙＩｔｅｍの再生手順を示すフローチャートである。
【符号の説明】
【００１７】
１ ＢＤ−ＲＯＭドライブ
２ リードバッファ
３ デマルチプレクサ
４ ビデオデコーダ
５ ビデオプレーン
６ Ｐ−Ｇｒａｐｈｉｃｓデコーダ
７ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン
８ 合成部
９ フォントゼネレータ
１０ Ｉ−Ｇｒａｐｈｉｃｓデコーダ
１１ スイッチ
１２ Ｉｎｔｅｒｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン
１３ 合成部
１４ ＣＬＵＴ部
１５ ＣＬＵＴ部
１６ オーディオデコーダ
２２ ユーザイベント処理部
２３ ＰＳＲセット
２４ ＣＰＵ
２５ シナリオメモリ
２６ ローカルメモリ
３３ ＨＤＭＶモジュール
３４ モジュールマネージャ
３５ ＢＤ−Ｊモジュール
３６ アプリケーションマネージャ
３７ ＵＯコントローラ
３８ Ｊａｖａ（登録商標）仮想マシン
４１ ＰＬＭＴプロセッサ
４２ パーミッションコントローラ
５２ ユーザクラスローダ
５３ メソッドエリア
５４ ワークメモリ
５５ａ，ｂ・・・ｎ スレッド
５６ａ，ｂ・・・ｄ Ｊａｖａ（登録商標）スタック
【発明を実施するための最良の形態】
【００１８】
（第１実施形態）
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体はＢＤ−ＲＯＭ１００であり、ＢＤ−ＲＯＭ１００は、再生装置２００、リモコン３００、テレビ４００により形成されるホームシアターシステムに、著作物を供給するという用途に供される。
【００１９】
このうちリモコン４００には、再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（Ｐａｕｓｅ Ｏｎ）、一時停止の解除（Ｐａｕｓｅ Ｏｆｆ）、Ｓｔｉｌｌ機能の解除（ｓｔｉｌｌ ｏｆｆ）、速度指定付きの早送り（Ｆｏｒｗａｒｄ Ｐｌａｙ（ｓｐｅｅｄ））、速度指定付きの巻戻し（Ｂａｃｋｗａｒｄ Ｐｌａｙ（ｓｐｅｅｄ））、音声切り換え（Ａｕｄｉｏ Ｃｈａｎｇｅ）、副映像切り換え（Ｓｕｂｔｉｔｌｅ Ｃｈａｎｇｅ）、アングル切り換え（Ａｎｇｌｅ Ｃｈａｎｇｅ）を受け付けるキーや、メニュー操作時にあたってのフォーカス移動操作を受け付けるＭｏｖｅＵｐキー、ＭｏｖｅＤｏｗｎキー、ＭｏｖｅＲｉｇｈｔキー、ＭｏｖｅＬｅｆｔキー、メニュー表示操作を受け付けるＰｏｐ−ｕｐキー、数値入力を受け付けるＮｕｍｅｒｉｃキーが存在する。
【００２０】
以上が本発明に係る記録媒体の使用形態についての説明である。
続いて本発明に係る記録媒体の生産行為について説明する。本発明に係る記録媒体は、ＢＤ−ＲＯＭのファイルシステム上における改良で実現することができる。図２は、ＢＤ−ＲＯＭにおけるファイル・ディレクトリ構成を示す図である。本図においてＢＤ−ＲＯＭには、Ｒｏｏｔディレクトリの下に、ＢＤＭＶディレクトリがある。
【００２１】
ＢＤＭＶディレクトリには、拡張子ｂｄｍｖが付与されたファイル
（ｉｎｄｅｘ．ｂｄｍｖ，ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖ，ＢＤ−Ｊ Ｏｂｊｅｃｔ．ｂｄｍｖ）がある。そしてこのＢＤＭＶディレクトリの配下には、更にＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦディレクトリ、ＳＴＲＥＡＭディレクトリ、ＢＤＪＡディレクトリと呼ばれる４つのサブディレクトリが存在する。
ＰＬＡＹＬＩＳＴディレクトリには、拡張子ｍｐｌｓが付与されたファイル
（００００１．ｍｐｌｓ，００００２．ｍｐｌｓ，００００３ｍｐｌｓ）がある。
【００２２】
ＣＬＩＰＩＮＦディレクトリには、拡張子ｃｌｐｉが付与されたファイル
（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ）がある。
ＳＴＲＥＡＭディレクトリには、拡張子ｍ２ｔｓが付与されたファイル
（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ，００００３．ｍ２ｔｓ）がある。
ＢＤＪＡディレクトリには、拡張子ｊａｒが付与されたファイル
（００００１．ｊａｒ，００００２．ｊａｒ，００００３ｊａｒ）がある。以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、ＢＤ−ＲＯＭ上に配置されていることがわかる。
【００２３】
本図において拡張子．ｍ２ｔｓが付与されたファイル
（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ，００００３．ｍ２ｔｓ・・・・・）は、ＡＶＣｌｉｐを格納している。ＡＶＣｌｉｐには、ＭａｉｎＣＬｉｐ、ＳｕｂＣｌｉｐといった種別がある。ＭａｉｎＣＬｉｐは、ビデオストリーム、オーディオストリーム、字幕を構成するプレゼンテーショングラフィクスストリーム（ＰＧストリーム）、メニューを構成するインタラクティブグラフィクスストリーム（ＩＧストリーム）というような複数エレメンタリストリームを多重化することで得られたデジタルストリームである。
【００２４】
ＳｕｂＣｌｉｐは、オーディオストリーム、グラフィクスストリーム、テキスト字幕ストリーム（ＴｅｘｔＳＴＳｔｒｅａｍ）等、１つのエレメンタリストリームのみにあたるデジタルストリームである。
拡張子”ｃｌｐｉ”が付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ・・・・・）は、ＡＶＣｌｉｐのそれぞれに１対１に対応する管理情報である。管理情報故に、Ｃｌｉｐ情報は、ＡＶＣｌｉｐにおけるストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、ＧＯＰの先頭位置を示すＥＰ＿ｍａｐをもっている。
【００２５】
拡張子”ｍｐｌｓ”が付与されたファイル（００００１．ｍｐｌｓ，００００２．ｍｐｌｓ，００００３．ｍｐｌｓ・・・・・）は、プレイリスト情報を格納したファイルである。プレイリスト情報は、ＡＶＣｌｉｐを参照してプレイリストを定義する情報である。図３は、ＰＬ情報の構成を示す図であり、本図の左側に示すように、プレイリスト情報は、『ＭａｉｎＰａｔｈ情報』、『ＰＬＭａｒｋ情報』、『ＳｕｂＰａｔｈ情報』から構成される。
【００２６】
ＭａｉｎＰａｔｈ情報（ＭａｉｎＰａｔｈ（））は、破線の矢印ｍｐ１に示すように複数のＰｌａｙＩｔｅｍ情報（ＰｌａｙＩｔｅｍ（））からなる。ＰｌａｙＩｔｅｍとは、１つ以上のＡＶＣｌｉｐ時間軸上において、Ｉｎ＿Ｔｉｍｅ，Ｏｕｔ＿Ｔｉｍｅを指定することで定義される再生区間である。ＰｌａｙＩｔｅｍ情報を複数配置させることで、複数再生区間からなるプレイリスト（ＰＬ）が定義される。図中の破線ｍｐ２は、ＰｌａｙＩｔｅｍ情報の内部構成をクローズアップしている。本図に示すようにＰｌａｙＩｔｅｍ情報は、対応するＡＶＣｌｉｐを示す『Ｃｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ』と、『Ｉｎ＿ｔｉｍｅ』と、『Ｏｕｔ＿ｔｉｍｅ』とからなる。図４は、ＡＶＣｌｉｐと、ＰＬとの関係を示す図である。第１段目はＡＶＣｌｉｐｉがもつ時間軸を示し、第２段目は、ＰＬがもつ時間軸を示す。ＰＬ情報は、ＰｌａｙＩｔｅｍ＃１，＃２，＃３という３つのＰｌａｙＩｔｅｍ情報を含んでおり、これらＰｌａｙＩｔｅｍ＃１，＃２，＃３のＩｎ＿ｔｉｍｅ，Ｏｕｔ＿ｔｉｍｅにより、３つの再生区間が定義されることになる。これらの再生区間を配列させると、ＡＶＣｌｉｐ時間軸とは異なる時間軸が定義されることになる。これが第２段目に示すＰＬ時間軸である。このように、ＰｌａｙＩｔｅｍ情報の定義により、ＡＶＣｌｉｐとは異なる時間軸の定義が可能になる。
【００２７】
ＡＶＣｌｉｐに対する指定は、原則１つであるが、複数ＡＶＣｌｉｐに対する一括指定もあり得る。この一括指定は、ＰｌａｙＩｔｅｍ情報における複数のＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅによりなされる。図５は、４つのＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅによりなされた一括指定を示す図である。本図において第１段目〜第４段目は、４つのＡＶＣｌｉｐ時間軸（ＡＶＣｌｉｐ＃１，＃２，＃３，＃４の時間軸）を示し、第５段目は、ＰＬ時間軸を示す。ＰｌａｙＩｔｅｍ情報が有する、４つのＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅにて、これら４つの時間軸が指定されている。こうすることで、ＰｌａｙＩｔｅｍが有するＩｎ＿ｔｉｍｅ，Ｏｕｔ＿ｔｉｍｅにより、択一的に再生可能な４つの再生区間が定義されることになる。これにより、ＰＬ時間軸には、切り換え可能な複数アングル映像からなる区間（いわゆるマルチアングル区間）が定義されることになる。
【００２８】
ＰＬｍａｒｋ情報（ＰＬｍａｒｋ（））は、ＰＬ時間軸のうち、任意の区間を、チャプターとして指定する情報である。図６は、ＰＬｍａｒｋ情報の内部構成を示す図であり、本図の引き出し線ｐｍ１に示すようにＰＬｍａｒｋ情報は、『ｒｅｆ＿ｔｏ＿ＰｌａｙＩｔｅｍ＿Ｉｄ』と、『Ｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐ』とを含む。図７は、ＰＬｍａｒｋによるチャプター定義を示す図である。本図において第１段目は、ＡＶＣｌｉｐ時間軸を示し、第２段目はＰＬ時間軸を示す。図中の矢印ｐｋ１，２は、ＰＬｍａｒｋにおけるＰｌａｙＩｔｅｍ指定（ｒｅｆ＿ｔｏ＿ＰｌａｙＩｔｅｍ＿Ｉｄ）と、一時点の指定（ｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐ）とを示す。これらの指定によりＰＬ時間軸には、３つのチャプター（Ｃｈａｐｔｅｒ＃１，＃２，＃３）が定義されることになる。以上がＰＬｍａｒｋについての説明である。続いてＳｕｂＰａｔｈ情報について説明する。
【００２９】
ＳｕｂＰａｔｈ情報（ＳｕｂＰａｔｈ（））は、ＳｕｂＣｌｉｐの時間軸上にＩｎ＿Ｔｉｍｅ，Ｏｕｔ＿Ｔｉｍｅを指定することで１つ以上の再生区間を定義する情報であり、図８に示す内部構成を有している。本図に示すようにＳｕｂＰａｔｈ情報は、破線の引き出し線ｓｈ１に示すように複数のＳｕｂＰｌａｙＩｔｅｍ情報（ＳｕｂＰｌａｙＩｔｅｍ（））からなる。破線ｓｈ２を用いてクローズアップしているように、ＳｕｂＰｌａｙＩｔｅｍ情報は、『Ｃｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ』と、『Ｉｎ＿ｔｉｍｅ』と、『Ｏｕｔ＿ｔｉｍｅ』と、『Ｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿Ｉｄ』と、『Ｓｙｎｃ＿ｓｔａｒｔ＿Ｐｔｓ＿ｏｆ＿ＰｌａｙＩｔｅｍ』とからなる。ＳｕｂＣｌｉｐの時間軸上に対する、Ｉｎ＿Ｔｉｍｅ，Ｏｕｔ＿Ｔｉｍｅの指定は、『Ｃｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ』、『Ｉｎ＿ｔｉｍｅ』、『Ｏｕｔ＿ｔｉｍｅ』によりなされる。『Ｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿Ｉｄ』及び『Ｓｙｎｃ＿ｓｔａｒｔ＿Ｐｔｓ＿ｏｆ＿ＰｌａｙＩｔｅｍ』は、ＳｕｂＣｌｉｐ時間軸上の再生区間と、ＰＬ時間軸とを同期させるという同期指定をなす。この同期指定により、ＰＬ時間軸と、ＳｕｂＰｌａｙＩｔｅｍ時間軸とは同期して進行することになる。
【００３０】
図９は、ＳｕｂＰｌａｙＩｔｅｍ時間軸上の再生区間定義と、同期指定を示す図である。本図において第１段目は、ＰＬ時間軸を示し、第２段目はＳｕｂＰｌａｙＩｔｅｍ時間軸を示す。図中のＳｕｂＰｌａｙＩｔｅｍ．ＩＮ＿ｔｉｍｅは再生区間の始点を、ＳｕｂＰｌａｙＩｔｅｍ．Ｏｕｔ＿ｔｉｍｅは再生区間の終点をそれぞれ示す。これによりＳｕｂＣｌｉｐ時間軸上にも再生区間が定義されていることがわかる。矢印Ｓｎ１においてＳｙｎｃ＿ＰｌａｙＩｔｅｍ＿Ｉｄは、ＰｌａｙＩｔｅｍに対する同期指定を示し、矢印Ｓｎ２においてｓｙｎｃ＿ｓｔａｒｔ＿ＰＴＳ＿ｏｆ＿ＰｌａｙＩｔｅｍは、ＰＬ時間軸におけるＰｌａｙＩｔｅｍ上の一時点の指定を示す。
【００３１】
複数ＡＶＣｌｉｐの切り換えを可能とするマルチアングル区間や、ＡＶＣｌｉｐ−ＳｕｂＣｌｉｐを同期させ得る同期区間の定義を可能とするのが、ＢＤ−ＲＯＭにおけるプレイリスト情報の特徴である。以上のＣｌｉｐ情報及びプレイリスト情報は、”静的シナリオ”に分類される。何故なら、以上のＣｌｉｐ情報及びプレイリスト情報により、静的な再生単位であるＰＬが定義されるからである。以上で静的シナリオについての説明を終わる。
【００３２】
続いて”動的なシナリオ”について説明する。動的シナリオとは、ＡＶＣｌｉｐの再生制御を動的に規定するシナリオデータである。”動的に”というのは、再生装置における状態変化やユーザからのキーイベントにより再生制御の中身がかわることをいう。ＢＤ−ＲＯＭでは、この再生制御の動作環境として２つのモードを想定している。１つ目は、ＤＶＤ再生装置の動作環境と良く似た動作環境であり、コマンドベースの実行環境である。２つ目は、Ｊａｖａ（登録商標）仮想マシンの動作環境である。これら２つの動作環境のうち１つ目は、ＨＤＭＶモードと呼ばれる。２つ目は、ＢＤ−Ｊモードと呼ばれる。これら２つの動作環境があるため、動的シナリオはこのどちらかの動作環境を想定して記述される。ＨＤＭＶモードを想定した動的シナリオはＭｏｖｉｅ Ｏｂｊｅｃｔと呼ばれ、管理情報により定義される。一方ＢＤ−Ｊモードを想定した動的シナリオはＢＤ−Ｊ Ｏｂｊｅｃｔと呼ばれる。
【００３３】
先ず初めにＭｏｖｉｅ Ｏｂｊｅｃｔについて説明する。
＜Ｍｏｖｉｅ Ｏｂｊｅｃｔ＞
Ｍｏｖｉｅ Ｏｂｊｅｃｔは、ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖというファイルに格納される。図１０は、ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖの内部構成を示す図である。本図の左端に示すようにＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖは、コード列”ＭＯＢＪ”を示す『ｔｙｐｅ＿ｉｎｄｉｃａｔｅｒ』と、『ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ』と、１つ以上のＭｏｖｉｅＯｂｊｅｃｔである『ＭｏｖｉｅＯｂｊｅｃｔｓ（）』とからなる。図中の図中の引き出し線ｖｈ１はＭｏｖｉｅＯｂｊｅｃｔｓの内部構成をクローズアップしている。ＭｏｖｉｅＯｂｊｅｃｔｓ（）は、自身のデータ長である『ｌｅｎｇｔｈ』と、自身に含まれるＭｏｖｉｅＯｂｊｅｃｔの個数である『ｎｕｍｂｅｒ＿ｏｆ＿ｍｏｂｊｓ』と、ｎｕｍｂｅｒ＿ｏｆ＿ｍｏｂｊｓ個のＭｏｖｉｅＯｂｊｅｃｔである『ＭｏｖｉｅＯｂｊｅｃｔｓ』とからなる。これらｎｕｍｂｅｒ＿ｏｆ＿ｍｏｂｊｓ個のＭｏｖｉｅＯｂｊｅｃｔは、識別子ｍｏｂｊ＿ｉｄをもって識別される。図中の引き出し線ｖｈ２は、識別子ｍｏｂｊ＿ｉｄにより特定される任意のＭｏｖｉｅＯｂｊｅｃｔ［ｍｏｂｊ＿ｉｄ］（）の内部構成をクローズアップしている。
【００３４】
この引き出し線に示すように、ＭｏｖｉｅＯｂｊｅｃｔは、ＭｅｎｕＣａｌｌがなされた際、ＭｅｎｕＣａｌｌ後の再生再開を意図しているか否かを示す『ｒｅｓｕｍｅ＿ｉｎｔｅｎｔｉｏｎ＿ｆｌａｇ』、ＭｅｎｕＣａｌｌをマスクするか否かを示す情報『ｍｅｎｕ＿ｃａｌｌ＿ｍａｓｋ』、タイトルサーチ機能をマスクするかを示す『ｔｉｔｌｅ＿ｓｅａｒｃｈ＿ｆｌａｇ』、ナビゲーションコマンドの個数である『ｎｕｍｂｅｒ＿ｏｆ＿ｎａｖｉｇａｔｉｏｎ＿ｃｏｍｍａｎｄ』、ｎｕｍｂｅｒ＿ｏｆ＿ｎａｖｉｇａｔｉｏｎ＿ｃｏｍｍａｎｄ個の『ナビゲーションコマンド』からなる。
【００３５】
ナビゲーションコマンド列は、条件分岐、再生装置における状態レジスタの設定、状態レジスタの設定値取得等を実現するコマンド列からなる。ＭｏｖｉｅＯｂｊｅｃｔにおいて記述可能なコマンドを以下に示す。
ＰｌａｙＰＬコマンド
書式：ＰｌａｙＰＬ（第１引数，第２引数）
第１引数は、プレイリストの番号で、再生すべきＰＬを指定することができる。第２引数は、そのＰＬに含まれるＰｌａｙＩｔｅｍや、そのＰＬにおける任意の時刻、Ｃｈａｐｔｅｒ、Ｍａｒｋを用いて再生開始位置を指定することができる。
【００３６】
ＰｌａｙＩｔｅｍによりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数を
ＰｌａｙＰＬａｔＰｌａｙＩｔｅｍ（）、
ＣｈａｐｔｅｒによりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数を
ＰｌａｙＰＬａｔＣｈａｐｔｅｒ（）、
時刻情報によりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数を
ＰｌａｙＰＬａｔＳｐｅｃｉｆｉｅｄ Ｔｉｍｅ（）という。
ＪＭＰコマンド
書式：ＪＭＰ引数
ＪＭＰコマンドは、現在の動的シナリオを途中で廃棄し（ｄｉｓｃａｒｄ）、引数たる分岐先動的シナリオを実行するという分岐である。ＪＭＰ命令の形式には、分岐先動的シナリオを直接指定している直接参照のものと、分岐先動的シナリオを間接参照している間接参照のものがある。
Ｍｏｖｉｅ Ｏｂｊｅｃｔにおけるナビゲーションコマンドの記述は、ＤＶＤにおけるナビゲーションコマンドの記述方式と良く似ているので、ＤＶＤ上のディスクコンテンツを、ＢＤ−ＲＯＭに移植するという作業を効率的に行うことができる。Ｍｏｖｉｅ Ｏｂｊｅｃｔについては、以下の国際公開公報に記載された先行技術が存在する。詳細については、本国際公開公報を参照されたい。
国際公開公報ＷＯ ２００４／０７４９７６
以上でＭｏｖｉｅ Ｏｂｊｅｃｔについての説明を終える。続いてＢＤ−Ｊ Ｏｂｊｅｃｔについて説明する。
＜ＢＤ−Ｊ Ｏｂｊｅｃｔ＞
ＢＤ−Ｊ Ｏｂｊｅｃｔは、Ｊａｖａ（登録商標）プログラミング環境で記述された、ＢＤ−Ｊモードの動的シナリオである。
【００３７】
図１１は、ＢＤ−Ｊ Ｏｂｊｅｃｔ．ｂｄｍｖの内部構成を示す図である。本図の左端に示すようにＢＤ−Ｊ Ｏｂｊｅｃｔ．ｂｄｍｖは、コード列”ＢＯＢＪ”を示す『ｔｙｐｅ＿ｉｎｄｉｃａｔｅｒ』と、『ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ』と、１つ以上のＢＤ−Ｊ Ｏｂｊｅｃｔである『ＢＤ−Ｊ Ｏｂｊｅｃｔｓ（）』とからなる。図中の図中の引き出し線ｂｈ１はＢＤ−Ｊ Ｏｂｊｅｃｔｓの内部構成をクローズアップしている。ＢＤ−Ｊ Ｏｂｊｅｃｔｓ（）は、自身のデータ長である『ｌｅｎｇｔｈ』と、自身に含まれるＢＤ−Ｊ Ｏｂｊｅｃｔの個数である『ｎｕｍｂｅｒ＿ｏｆ＿ｂｏｂｊｓ』と、ｎｕｍｂｅｒ＿ｏｆ＿ｂｏｂｊｓ個のＢＤ−Ｊ Ｏｂｊｅｃｔである『ＢＤ−Ｊ Ｏｂｊｅｃｔｓ』とからなる。これらｎｕｍｂｅｒ＿ｏｆ＿ｂｏｂｊｓ個のＢＤ−Ｊ Ｏｂｊｅｃｔは、識別子ｂｏｂｊ＿ｉｄをもって識別される。図中の引き出し線ｂｈ２は、識別子ｂｏｂｊ＿ｉｄにより特定される任意のＢＤ−Ｊ Ｏｂｊｅｃｔ［ｂｏｂｊ＿ｉｄ］（）の内部構成をクローズアップしている。
【００３８】
この引き出し線に示すように、本図に示すようにＢＤ−Ｊ Ｏｂｊｅｃｔは、『ｒｅｓｕｍｅ＿ｉｎｔｅｎｔｉｏｎ＿ｆｌａｇ［ｂｏｂｊ＿ｉｄ］』と、『ｍｅｎｕ＿ｃａｌｌ＿ｍａｓｋ［ｂｏｂｊ＿ｉｄ］』と、『ｔｉｔｌｅ＿ｓｅａｒｃｈ＿ｆｌａｇ［ｂｏｂｊ＿ｉｄ］』と、『Ａｐｐｌｉｃａｔｉｏｎ＿Ｍａｎａｇｅｍｅｎｔ＿Ｔａｂｌｅ［ｂｏｂｊ＿ｉｄ］』と、『Ｐｌａｙｌｉｓｔ＿Ｍａｎａｇｅｍｅｎｔ＿Ｔａｂｌｅ［ｂｏｂｊ＿ｉｄ］』とからなる。『ｒｅｓｕｍｅ＿ｉｎｔｅｎｔｉｏｎ＿ｆｌａｇ』、『ｍｅｎｕ＿ｃａｌｌ＿ｍａｓｋ』、『ｔｉｔｌｅ＿ｓｅａｒｃｈ＿ｆｌａｇ』を含んでいる点においてＢＤ−Ｊ ＯｂｊｅｃｔはＭｏｖｉｅ Ｏｂｊｅｃｔとほぼ同じである。
【００３９】
Ｍｏｖｉｅ Ｏｂｊｅｃｔとの違いは、ＢＤ−Ｊ Ｏｂｊｅｃｔにコマンドが直接記述されていない点である。つまりＭｏｖｉｅ Ｏｂｊｅｃｔにおいて制御手順は、ナビゲーションコマンドにより直接記述されていた。これに対しＢＤ−Ｊ Ｏｂｊｅｃｔでは、Ｊａｖａ（登録商標）アプリケーションに対する指定を『Ａｐｐｌｉｃａｔｉｏｎ＿Ｍａｎａｇｅｍｅｎｔ＿Ｔａｂｌｅ［ｂｏｂｊ＿ｉｄ］』上に記載することにより、間接的に制御手順を規定している。このような間接的な規定により、複数動的シナリオにおいて制御手順を共通化するという、制御手順の共通化を効率的に行うことができる。
【００４０】
またＭｏｖｉｅＯｂｊｅｃｔにおけるＰＬ再生は、ＰＬ再生を命じるナビゲーションコマンド（ＰｌａｙＰｌコマンド）の記述によりなされていたが、ＢＤ−Ｊ ＯｂｊｅｃｔにおけるＰＬ再生は、ＰＬ再生手順を示す『Ｐｌａｙｌｉｓｔ＿Ｍａｎａｇｅｍｅｎｔ＿Ｔａｂｌｅ［ｂｏｂｊ＿ｉｄ］』をＢＤ−Ｊ Ｏｂｊｅｃｔに組み込むことで記述が可能になる。それだけではなくアプリケーション管理テーブルから参照されるアプリケーションに、ＰＬ再生手順を組み込むことでも記述が可能になる。つまりプレイリスト管理テーブルの記述、アプリケーションにおけるＰＬ再生手順の記述のどちらであっても、プレイリスト再生の手順を組み込んでおくことができる。
【００４１】
ここでＪａｖａ（登録商標）アプリケーションについて説明する。Ｊａｖａ（登録商標）アプリケーションは、仮想マシンのヒープ領域（ワークメモリとも呼ばれる）にロードされた１つ以上のｘｌｅｔプログラムからなる。このワークメモリにロードされたｘｌｅｔプログラム、及び、データから、アプリケーションは構成されることになる。以上がＪａｖａ（登録商標）アプリケーションの構成である。
このＪａｖａ（登録商標）アプリケーションの実体にあたるのが、図２におけるＢＤＭＶディレクトリ配下のＢＤＪＡディレクトリに格納されたＪａｖａ（登録商標）アーカイブファイル（００００１．ｊａｒ，００００２．ｊａｒ）である。以降、Ｊａｖａ（登録商標）アーカイブファイルについて、図１２を参照しながら説明する。
【００４２】
＜Ｊａｖａ（登録商標）アーカイブファイル＞
Ｊａｖａ（登録商標）アーカイブファイル（図２の００００１．ｊａｒ，００００２．ｊａｒ）は、１つ以上のクラスファイル、１つ以上のデータファイル等を１つにまとめることで得られるファイルである。図１２（ａ）は、アーカイブファイルにより収められているプログラム、データを示す図である。本図におけるデータは、枠内に示すディレクトリ構造が配置された複数ファイルを、Ｊａｖａ（登録商標）アーカイバでまとめたものである。枠内に示すディレクトリ構造は、Ｒｏｏｔディレクトリ、Ｊａｖａ（登録商標）ディレクトリ、ｉｍａｇｅディレクトリとからなり、Ｒｏｏｔディレクトリにｃｏｍｍｏｎ．ｐｋｇが、Ｊａｖａ（登録商標）ディレクトリにクラスファイル（ａａａ．ｃｌａｓｓ，ｂｂｂ．ｃｌａｓｓ）が、ｉｍａｇｅディレクトリに、ｍｅｎｕ．ｊｐｇが配置されている。Ｊａｖａ（登録商標）アーカイブファイルは、これらをＪａｖａ（登録商標）アーカイバでまとめることで得られる。かかるクラスファイル及びデータは、ＢＤ−ＲＯＭからキャッシュに読み出されるにあたって展開され、キャッシュ上で、ディレクトリに配置された複数ファイルとして取り扱われる。Ｊａｖａ（登録商標）アーカイブファイルのファイル名における″ｚｚｚｚｚ″という５桁の数値は、アプリケーションのＩＤ（ａｐｐｌｉｃａｔｉｏｎＩＤ）を示す。本Ｊａｖａ（登録商標）アーカイブファイルがキャッシュに読み出された際、このファイル名における数値を参照することにより、任意のＪａｖａ（登録商標）アプリケーションを構成するプログラム，データを取り出すことができる。
本図におけるクラスファイル（図中のａａａ．ｃｌａｓｓ，ｂｂｂ．ｃｌａｓｓ）は、上述したｘｌｅｔプログラムに対応するクラスファイルである。ＢＤ−Ｊモードにおける再生手順は、このクラスファイルのインスタンスにあたるｘｌｅｔプログラムにより規定される。
【００４３】
ｘｌｅｔプログラムとは、ＪＭＦ（Ｊａｖａ（登録商標）Ｍｅｄｉａ ＦｒａｍｅＷｏｒｋ）方式のインターフェイスを利用することができるＪａｖａ（登録商標）プログラムであり、ＪＭＦ等の方式に従って、キーイベントに基づく処理を行う。ｘｌｅｔプログラムは、ＪＭＦ方式の処理が可能であるので、ＭＰＬＳファイルに対するインスタンス（ＪＭＦプレーヤインスタンス）を生成することにより、プレイリスト再生を再生装置に命じることができる。他にもｘｌｅｔプログラムでは、ファンクションＡＰＩのコールを記述することにより、ＢＤ−ＲＯＭ再生装置特有の処理を実行させることができる。
【００４４】
更にｘｌｅｔプログラムは、ＷＷＷサイトをアクセスしてコンテンツをダウンロードするという手順を実行することもできる。これによりダウンロードコンテンツと、プレイリスト再生とを交えた斬新な作品を再生させることができる。
ｘｌｅｔプログラムのクラスファイルについて説明する。図１２（ｂ）は、クラスファイルの内部構成を示す図である。本図に示すようにクラスファイルは、通常のクラスファイル同様、『コンスタントプール』、『インターフェイス』、『メソッド１，２，３・・・・ｎ』からなる。クラスファイルにおけるメソッドには、挙動のトリガになるキーイベントが予め登録されているメソッド（ＥｖｅｎｔＬｉｓｔｎｅｒ）と、ＪＭＦの再生手順を命じるメソッド（ＪＭＦプレーヤインスタンスのメソッド）、ＢＤ−ＲＯＭ再生装置側のファンクションＡＰＩをコールするメソッドがある。これらのメソッドは、自身に割り当てられたローカル変数や、自身をコールする際の引数を用いることにより、演算等の手順が記述されている。以上がＪａｖａ（登録商標）アーカイブファイルについての説明である。尚、本実施形態においてアプリケーションを構成するプログラム、データは、Ｊａｖａ（登録商標）アーカイブファイルにまとめられたが、ＬＺＨファイル、ｚｉｐファイルであってもよい。
【００４５】
以上が、ＢＤ−Ｊモードにおける動的シナリオについての説明である。
＜ＢＤ−ＲＯＭにおける状態遷移＞
ＤＶＤ−Ｖｉｄｅｏのような読出専用ディスクで供給されるディスクコンテンツは、トップメニューを中核とした構造になっている。そのトップメニューから、個々の著作物へと分岐して再生を行い、その後再び、ＴｏｐＭｅｎｕ Ｔｉｔｌｅに戻るという独特の状態遷移をなす。図１３は、ディスクコンテンツにおける状態遷移を示す図である。本図における四角枠は、Ｔｉｔｌｅである。Ｔｉｔｌｅとは、ディスクコンテンツ特有の状態遷移において、１つの”状態”にあたる再生単位である。Ｔｉｔｌｅには、ＢＤ−ＲＯＭのローディング時に最初に再生される『ＦｉｒｓｔＰｌａｙＴｉｔｌｅ』、Ｔｏｐ＿Ｍｅｎｕを構成する『Ｔｏｐ＿ｍｅｎｕＴｉｔｌｅ』、これら以外の一般的な『Ｔｉｔｌｅ』がある。また、図中の矢印ｊｈ１，２，３，４，５，６，７，８は、Ｔｉｔｌｅ間の分岐を象徴的に示す。本図に示される状態遷移とは、ＢＤ−ＲＯＭローディング時に、『ＦｉｒｓｔＰｌａｙＴｉｔｌｅ』が再生され、『Ｔｏｐ＿ｍｅｎｕＴｉｔｌｅ』への分岐が発生して、トップメニューに対する選択待ちになるというものである。ＢＤ−ＲＯＭのような映画作品頒布用の記録媒体の業界では、動的商標を、ローディング時に再生するという慣習が定着している。この動的商標は、映画作品の制作者や頒布者を表徴するものであり、ＦｉｒｓｔＰｌａｙＴｉｔｌｅは、ＢＤ−ＲＯＭのローディングされた際、なによりも先に、この動的商標を再生させるという役割分担を担う。
【００４６】
そしてユーザによるメニューに対する選択操作があれば、選択に従って該当Ｔｉｔｌｅの再生を行い、再びＴｏｐＭｅｎｕ Ｔｉｔｌｅに戻るとの処理を、ＢＤ−ＲＯＭのイジェクトがなされるまで延々と繰り返すというのが、ディスクコンテンツ特有の状態遷移である。
かかる状態遷移をなすＴｉｔｌｅは、ＨＤＭＶモードの動的シナリオ、ＢＤ−Ｊモードの動的シナリオから構成される。図１４は、ＨＤＭＶモードの動的シナリオから構成される２つのＴｉｔｌｅを示す図である。本図の第１段目は、識別子ｔｉｔｌｅ＿ｉｄにより識別される任意のＴｉｔｌｅ（ｔｉｔｌｅ＿ｉｄ）を示す。第２段目は、そのＴｉｔｌｅを構成している１つ以上のＭｏｖｉｅＯｂｊｅｃｔからなるＭｏｖｉｅＯｂｊｅｃｔ列を示す。第３段目は、ＭｏｖｉｅＯｂｊｅｃｔを構成するナビゲーションコマンドを示す。
【００４７】
他のＴｉｔｌｅへのＪｕｍｐを再生装置に命じるナビゲーションコマンド（ＪｕｍｐＴｉｔｌｅコマンド）をＭｏｖｉｅＯｂｊｅｃｔに記述しておくことにより、図１３に示したような、あるＴｉｔｌｅから別のＴｉｔｌｅへの分岐が実現されることになる。またＰＬ再生を命じるナビゲーションコマンド（ＰｌａｙＰＬコマンド）をＭｏｖｉｅＯｂｊｅｃｔに記述しておくことにより、本図第４段目に示すＰＬが、Ｔｉｔｌｅに帰属することになる。
【００４８】
ＰＬを帰属させることにより、ＨＤＭＶモードにおけるＴｉｔｌｅでは、動画再生を伴う映画作品を定義することができる。これがＨＤＭＶモードの動的シナリオにより定義されるＴｉｔｌｅの構成である。
続いてＢＤ−Ｊモードの動的シナリオにより構成されるＴｉｔｌｅの内部構成について説明する。図１５は、ＢＤ−Ｊモードの動的シナリオ（ＢＤ−Ｊ Ｏｂｊｅｃｔ）により構成されるＴｉｔｌｅの内部構成を示す図である。
【００４９】
第１段目は、識別子ｔｉｔｌｅ＿ｉｄにより識別される任意のＴｉｔｌｅを示し、第２段目は、そのＴｉｔｌｅを構成する唯一のＢＤ−Ｊ Ｏｂｊｅｃｔを示す。第３段目は、そのＢＤ−Ｊ Ｏｂｊｅｃｔの内部にあるアプリケーション管理テーブル、プレイリスト管理テーブルを示す。第４段目は、第３段目のアプリケーション管理テーブルにより動作することになるアプリケーションを示す。このアプリケーションは、第５段目に示すように、他のＴｉｔｌｅへのＪｕｍｐを再生装置に命じるメソッド（ＪｕｍｐＴｉｔｌｅＡＰＩをコールするメソッド）を含んでいるので、ＪｕｍｐＴｉｔｌｅＡＰＩのコールメソッドにより、図１３に示した他ののＴｉｔｌｅへの分岐が実現することになる。一方、第３段目にはプレイリスト管理テーブルが記述されているので、第４段目にあたっては、アプリケーションの実行と共にＰＬが再生されることになる。
【００５０】
ＢＤ−Ｊ Ｏｂｊｅｃｔには、アプリケーション管理テーブル，プレイリスト管理テーブルが含まれているので、第４段目に示すように、アプリケーション実行と、ＰＬ再生とが同時になされることになる。このようなアプリケーション実行と、ＰＬ再生との同時実行がＢＤ−ＪモードにおけるＴｉｔｌｅの特徴である。
プレイリスト管理テーブルは、全てのＢＤ−Ｊ Ｏｂｊｅｃｔに存在する訳ではない。プレイリスト管理テーブルは任意的な構成要素であり、プレイリスト管理テーブルをもつＢＤ−Ｊ Ｏｂｊｅｃｔもあるし、プレイリスト管理テーブルをもたないＢＤ−Ｊ Ｏｂｊｅｃｔもある。図１６は、プレイリスト管理テーブルをもたないＴｉｔｌｅを示す図である。アプリケーション管理テーブルしか存在しないため、プレイリスト管理テーブルをもたないようなＢＤ−Ｊ Ｏｂｊｅｃｔでは、第４段目に示すように、アプリケーション動作のみが規定される。以上によるアプリケーション動作の規定により、ＰＬ再生を伴わない、制御手順のみのＴｉｔｌｅが規定されることになる。
【００５１】
また図１４ではＨＤＭＶモードのＴｉｔｌｅから、ＨＤＭＶモードのＴｉｔｌｅへの分岐が記述されていたが、図１７に示すようにＨＤＭＶモードのＴｉｔｌｅから、ＢＤ−ＪモードのＴｉｔｌｅへの分岐もありえる。同様に図１５ではＢＤ−ＪモードのＴｉｔｌｅから、ＢＤ−ＪモードのＴｉｔｌｅへの分岐が記述されていたが、図１８に示すようにＢＤ−ＪモードのＴｉｔｌｅから、ＨＤＭＶモードのＴｉｔｌｅへの分岐もありえる。
【００５２】
上述したＴｉｔｌｅの内部構成において、あるＴｉｔｌｅの構成要素となるＭｏｖｉｅＯｂｊｅｃｔはどれであるか、又は、あるＴｉｔｌｅの構成要素となるＢＤ−Ｊ Ｏｂｊｅｃｔはどれであるのかを定義するのが、図２に示したｉｎｄｅｘ．ｂｄｍｖである。以降ｉｎｄｅｘ．ｂｄｍｖについて説明する。
Ｉｎｄｅｘ．ｂｄｍｖは、タイトルを構成する、Ｍｏｖｉｅ Ｏｂｊｅｃｔ又はＢＤ−Ｊ Ｏｂｊｅｃｔを示すテーブルである。
【００５３】
図１９は、ｉｎｄｅｘ．ｂｄｍｖの内部構成を示す図である。本図に示すようにｉｎｄｅｘ．ｂｄｍｖは、値”ＩＮＤＸ”を示す値をもつ『ｔｙｐｅ＿ｉｎｄｉｃａｔｏｒ』と、『ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ』と、本ファイルの先頭からＩｎｄｅｘｅｓまでの相対アドレスを示す『Ｉｎｄｅｘｅｓ＿ｓｔａｒｔ＿ａｄｄｒｅｓｓ』と、『Ｉｎｄｅｘｅｓ（）』とからなる。『Ｉｎｄｅｘｅｓ』は、各Ｔｉｔｌｅに対するインデックスであり、破線の引き出し線ｉｘ１でクローズアップしているように、『Ｉｎｄｅｘｅｓ』は、『ｌｅｎｇｔｈ』，『ＦｉｒｓｔＰｌａｙｂａｃｋ（）｛ＦｉｒｓｔＰｌａｙｂａｃｋ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ｝』，『ＴｏｐＭｅｎｕ（）｛ＴｏｐＭｅｎｕ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ｝』，『ｎｕｍｂｅｒ＿ｏｆ＿Ｔｉｔｌｅｓ』，『Ｔｉｔｌｅ［０］（）〜Ｔｉｔｌｅ［ｎｕｍｂｅｒ＿ｏｆ＿Ｔｉｔｌｅｓ−１］（）』からなる。
【００５４】
『ＦｉｒｓｔＰｌａｙｂａｃｋ（）｛ＦｉｒｓｔＰｌａｙｂａｃｋ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ｝』は、ＦｉｒｓｔＰｌａｙＴｉｔｌｅに対するＩｎｄｅｘであり、ＦｉｒｓｔＰｌａｙＴｉｔｌｅを構成するＭｏｖｉｅＯｂｊｅｃｔ識別子の参照値（ＦｉｒｓｔＰｌａｙｂａｃｋ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ）が格納される。
『ＴｏｐＭｅｎｕ（）｛ＴｏｐＭｅｎｕ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ｝』は、Ｔｏｐ−ＭｅｎｕＴｉｔｌｅに対するＩｎｄｅｘであり、Ｔｏｐ＿ｍｅｎｕＴｉｔｌｅを構成するＭｏｖｉｅＯｂｊｅｃｔ識別子の参照値（ＴｏｐＭｅｎｕ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ）が格納される。
【００５５】
『Ｔｉｔｌｅ［０］（）〜Ｔｉｔｌｅ［ｎｕｍｂｅｒ＿ｏｆ＿Ｔｉｔｌｅｓ−１］（）』は、ＦｉｒｓｔＰｌａｙＴｉｔｌｅ、Ｔｏｐ−ＭｅｎｕＴｉｔｌｅ以外のＴｉｔｌｅに対するＩｎｄｅｘであり、ｎｕｍｂｅｒ＿ｏｆ＿Ｔｉｔｌｅ個存在している。これらは識別子ｔｉｔｌｅ＿ｉｄをもって識別される。
ここで識別子ｔｉｔｌｅ＿ｉｄにより特定されるインデックスをＴｉｔｌｅ［ｔｉｔｌｅ＿ｉｄ］（）とする。図中の引き出し線ｉｘ２は、Ｔｉｔｌｅ［ｔｉｔｌｅ＿ｉｄ］（）に対する内部構成をクローズアップしている。
【００５６】
本図に示すように”Ｔｉｔｌｅ［ｔｉｔｌｅ＿ｉｄ］（）”は、”Ｔｉｔｌｅ［ｔｉｔｌｅ＿ｉｄ］が、分岐をもっているか否か等、Ｔｉｔｌｅの再生の類型を示す『Ｔｉｔｌｅ＿Ｐｌａｙｂａｃｋ＿Ｔｙｐｅ［ｔｉｔｌｅ＿ｉｄ］』と、このＴｉｔｌｅに対するサーチ機能の実行が許可されているか否かを示す『Ｔｉｔｌｅ＿ａｃｃｅｓｓ＿Ｆｌａｇ［ｔｉｔｌｅ＿ｉｄ］』と、Ｔｉｔｌｅを構成するＭｏｖｉｅＯｂｊｅｃｔを一意に示す『ｔｉｔｌｅ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ］ｔｉｔｌｅ＿ｉｄ］』とからなる。ここでＴｉｔｌｅを構成する動的シナリオがＢＤ−Ｊ Ｏｂｊｅｃｔであれば、『ｔｉｔｌｅ＿ｂｏｂｊ＿ｉｄ＿ｒｅｆ［ｔｉｔｌｅ＿ｉｄ］』が『ｔｉｔｌｅ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ［ｔｉｔｌｅ＿ｉｄ］』の代わりになる。『ｔｉｔｌｅ＿ｂｏｂｊ＿ｉｄ＿ｒｅｆ［ｔｉｔｌｅ＿ｉｄ］』は、Ｔｉｔｌｅを構成するＢＤ−Ｊ Ｏｂｊｅｃｔを一意に示す。
Ｉｎｄｅｘ．ｂｄｍｖについては、以下の国際公開公報に詳細が記載されている。詳細については、本公報を参照されたい。
国際公開公報ＷＯ ２００４／０２５６５１ Ａ１公報
＜アプリケーション管理テーブル＞
ＢＤ−Ｊ Ｏｂｊｅｃｔに含まれるアプリケーション管理テーブル及びプレイリスト管理テーブルは、本実施形態の主眼となる構成要素であり、その詳細について説明する。先ずアプリケーション管理テーブル（ＡＭＴ）について説明する。
【００５７】
図２０（ａ）は、アプリケーション管理テーブルの内部構成を示す図である。本図に示すようにアプリケーション管理テーブルは、『ｌｉｆｅ＿ｃｙｃｌｅ』と、『ａｐｌｉ＿ｉｄ＿ｒｅｆ』と、『ｒｕｎ＿ａｔｔｒｉｂｕｔｅ』と、『ｒｕｎ＿ｐｒｉｏｒｉｔｙ』からなる。
図２０（ｂ）は、アプリケーション管理テーブルを構成する情報要素の意味内容を示す。
【００５８】
『ｌｉｆｅ＿ｃｙｃｌｅ』は、アプリケーションの”生存区間”を示す。
『ａｐｌｉ＿ｉｄ＿ｒｅｆ』は、”アプリケーション識別子”に対する参照値が記述されることにより、左記の生存区間をもつアプリケーションがどれであるかを示す。アプリケーション識別子は、Ｊａｖａ（登録商標）アーカイブファイルにおいて、ファイル名として付与された５桁の数値ｚｚｚｚｚで表現される。『ａｐｌｉ＿ｉｄ＿ｒｅｆ』には、この５桁の数値が記述される。
【００５９】
『ｒｕｎ＿ａｔｔｒｉｂｕｔｅ』は、当該生存区間におけるアプリケーションの”起動属性”が記述される。起動属性には、ＡｕｔｏＲｕｎ、Ｐｒｅｓｅｎｔ、Ｓｕｓｐｅｄといった種別がある。
『ｒｕｎ＿ｐｒｉｏｒｉｔｙ』は、当該生存区間におけるアプリケーションの”起動優先度”が記述される。ＢＤ−Ｊ Ｏｂｊｅｃｔでは、これらの情報を用いてアプリケーションの挙動を制御する。
＜生存区間＞
アプリケーション管理テーブルに規定される情報のうち、生存区間について説明する。
【００６０】
生存区間とは、ＢＤ−ＲＯＭに記録されたコンテンツ全体の時間軸において、仮想マシンのワークメモリ上でアプリケーションが生存し得る区間を示す。ワークメモリにおける”生存”とは、そのアプリケーションを構成するｘｌｅｔプログラムが、ワークメモリに読み出され、仮想マシンによる実行が可能になっている状態をいう。
Ｊａｖａ（登録商標）仮想マシンにおいてアプリケーションを動作させる場合、時間軸の何処からアプリケーションによるサービスを開始し、時間軸の何処でアプリケーションによるサービスを終えるかという”サービスの開始点・終了点”を明確に規定することが重要になる。このサービスの開始点・終了点を規定するのが、アプリケーション管理テーブルにおける生存区間である。
【００６１】
それでは、図１３のような状態遷移をなすディスクコンテンツにおいて、Ｔｉｔｌｅの生存区間はどのように規定されるのであろうか。ＢＤ−ＲＯＭのローディングがなされた後、図１３において矢印ｊｈ１，２，３，４・・・・・に示された参照符号の数値順に分岐がなされ、ＢＤ−ＲＯＭがイジェクトされたものとする。そうすると、ＢＤ−ＲＯＭがローディングされてから、イジェクトされるまでの連続時間帯を一本の時間軸と同視することができる。この時間軸を、ディスク全体の時間軸とする。図２１（ａ）は、ディスク全体の時間軸を示す図であり、図２１（ｂ）は、この時間軸における構成を示す。図２１（ｂ）に示すように、ディスク全体の時間軸は、ＦｉｒｓｔＰｌａｙ Ｔｉｔｌｅが再生されている区間、ＴｏｐＭｅｎｕ Ｔｉｔｌｅが再生されている区間、ｔｉｔｌｅ＃１が再生されている区間等からなる。これらＴｉｔｌｅの再生区間はどのように規定されているかというと、Ｔｉｔｌｅは、１つ以上のＭｏｖｉｅＯｂｊｅｃｔ、又は、唯一のＢＤ−Ｊ Ｏｂｊｅｃｔから構成されるから、どれかのＭｏｖｉｅＯｂｊｅｃｔ又はＢＤ−Ｊ Ｏｂｊｅｃｔが、有効になっている期間をＴｉｔｌｅの再生区間と考えることができる。
【００６２】
つまりＦｉｒｓｔＰｌａｙ Ｔｉｔｌｅ、ＴｏｐＭｅｎｕ Ｔｉｔｌｅ、その他のＴｉｔｌｅは、何れも動的シナリオから構成されるから、Ｔｉｔｌｅを構成するＭｏｖｉｅＯｂｊｅｃｔ又はＢＤ−Ｊ Ｏｂｊｅｃｔのうち、どれかがカレントＭｏｖｉｅＯｂｊｅｃｔ、又は、カレントＢＤ−Ｊ ＯｂｊｅｃｔとしてＡｃｔｉｖａｔｅｄされ、再生装置内において解読・実行に供されている期間を、Ｔｉｔｌｅの再生区間と定義することができる。図２２（ａ）は、ＢＤ−ＲＯＭ全体の時間軸において、識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−Ｊ Ｏｂｊｅｃｔから特定されるタイトル再生区間を示す図である。ここで識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−Ｊ Ｏｂｊｅｃｔが、１つのＴｉｔｌｅを構成しているなら、その識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−Ｊ Ｏｂｊｅｃｔが有効になっているＢＤ−ＲＯＭ時間軸上の一区間を、Ｔｉｔｌｅの再生区間と考えることができる。
【００６３】
同様に、識別子ｍｏｂｊ＿ｉｄにより特定されるＭｏｖｉｅＯｂｊｅｃｔが、１つのＴｉｔｌｅを構成しているなら、その識別子ｍｏｂｊ＿ｉｄにより特定されるＭｏｖｉｅＯｂｊｅｃｔが有効になっている、ＢＤ−ＲＯＭ時間軸上の一区間を、Ｔｉｔｌｅの再生区間と考えることができる。
ここでＭｏｖｉｅＯｂｊｅｃｔ、ＢＤ−Ｊ ＯｂｊｅｃｔがＡｃｔｉｖａｔｅされている期間の終期は、Ｔｉｔｌｅ分岐（ＪｕｍｐＴｉｔｌｅ）がなされるまでである。つまり、Ｔｉｔｌｅ分岐（ＪｕｍｐＴｉｔｌｅ）がなされるまで、実行の対象になっている動的シナリオは、カレントＭｏｖｉｅＯｂｊｅｃｔ及びカレントＢＤ−Ｊ Ｏｂｊｅｃｔとして扱われるから、そのＭｏｖｉｅＯｂｊｅｃｔ又はＢＤ−Ｊ ＯｂｊｅｃｔにおいてＪｕｍｐＴｉｔｌｅが発生するまでの１つの区間を、Ｔｉｔｌｅ再生区間として扱う。
【００６４】
続いてＴｉｔｌｅ区間と、ＰＬ時間軸との関係について説明する。上述したようにＭｏｖｉｅＯｂｊｅｃｔ、ＢＤ−Ｊ Ｏｂｊｅｃｔでは、１つの処理手順としてＰＬ再生手順を記述することができる。ＰＬ再生手順の記述があれば、上述したＰＬ時間軸の全部又は一部がＴｉｔｌｅ区間に帰属することになる。図２２（ａ）の一例においてＢＤ−Ｊ Ｏｂｊｅｃｔに、プレイリスト管理テーブルが記述されているとする。この場合、ＢＤ−Ｊ Ｏｂｊｅｃｔに対応するＴｉｔｌｅ区間には、図２２（ｂ）に示すように、ＰＬ時間軸が帰属する。このＰＬ時間軸には更に、複数チャプター（Ｃｈａｐｔｅｒ＃１，＃２，＃３）が定義され得るため、ＢＤ−ＲＯＭ上の時間軸には、ＢＤ−ＲＯＭ全体−Ｔｉｔｌｅ−ＰＬ−チャプターというドメインが存在することになる。これらのドメインを用いて、アプリケーションの生存区間を記述することができる。尚、プレイリスト再生は、アプリケーション実行と同時になされため、プレイリスト再生の途中で、Ｔｉｔｌｅ分岐が発生することがある。この場合、１つのＴｉｔｌｅ再生区間内にはプレイリスト時間軸全体ではなく、プレイリスト時間軸の一部分のみが帰属することになる。つまり１つのＴｉｔｌｅの再生区間において、プレイリスト時間軸の全体が帰属するか、その一部分が帰属するかは、Ｔｉｔｌｅ分岐が何時発生するかによって変わる。
【００６５】
図２３は、図２２（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。本図に示すようにアプリケーションには、Ｔｉｔｌｅを生存区間にした”タイトルバウンダリアプリケーション”、Ｔｉｔｌｅ内におけるチャプターを生存区間にした”チャプターバウンダリアプリケーション”、ＢＤ−ＲＯＭ全体の時間軸を生存区間にした”タイトルアンバウンダリーアプリケーション”という３つの典型がある。
【００６６】
このうちタイトルバウンダリアプリケーションの生存区間は、そのタイトルの識別子を用いて定義することができる。またチャプターバウンダリアプリケーションの生存区間は、チャプターが属するタイトルの識別子と、そのチャプターの識別子との組みを用いて定義することができる。
プラットフォームが動作していたとしても、Ｔｉｔｌｅやチャプターという生存区間が終われば、リソースをアプリケーションから回収することができる。リソース回収の機会を保証するので、プラットフォームの動作を安定化させることができる。
【００６７】
近い将来、実施されるであろうディスクコンテンツを題材に選んで、アプリケーション管理テーブルにおける生存区間記述について、具体例を交えて説明する。ここで題材にするディスクコンテンツは、映像本編を構成する本編タイトル（ｔｉｔｌｅ＃１）、オンラインショッピングを構成するオンラインショッピングタイトル（ｔｉｔｌｅ＃２）、ゲームアプリケーションを構成するゲームタイトル（ｔｉｔｌｅ＃３）という、性格が異なる３つのタイトルを含むものである。図２４は、本編タイトル、オンラインショッピングタイトル、ゲームタイトルという３つのタイトルを含むディスクコンテンツを示す図である。本図における右側にはＩｎｄｅｘ．ｂｄｍｖを記述しており、左側には３つのタイトルを記述している。
【００６８】
右側における破線枠は、各アプリケーションがどのタイトルに属しているかという帰属関係を示す。３つのタイトルのうちｔｉｔｌｅ＃１は、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３という３つのアプリケーションからなる。ｔｉｔｌｅ＃２は、ａｐｐｌｉｃａｔｉｏｎ＃３、ａｐｐｌｉｃａｔｉｏｎ＃４という２つのアプリケーション、ｔｉｔｌｅ＃３は、ａｐｐｌｉｃａｔｉｏｎ＃５を含む。図２４の一例においてａｐｐｌｉｃａｔｉｏｎ＃３は、ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２の双方で起動される。
【００６９】
図２４の破線に示される帰属関係から各アプリケーションの生存区間をグラフ化すると、図２５（ａ）のようになる。本図において横軸は、タイトル再生区間であり、縦軸方向に各アプリケーションの生存区間を配置している。ここでａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２は、ｔｉｔｌｅ＃１のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃１内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃４は、ｔｉｔｌｅ＃２のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃２内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃５は、ｔｉｔｌｅ＃３のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃３内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃３は、ｔｉｔｌｅ＃１及びｔｉｔｌｅ＃２に帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃１−ｔｉｔｌｅ＃２にわたる。この生存区間に基づき、アプリケーション管理テーブルを記述すると、ｔｉｔｌｅ＃１，＃２，＃３のアプリケーション管理テーブルは図２５（ｂ）のようになる。このようにアプリケーション管理テーブルが記述されれば、ｔｉｔｌｅ＃１の再生開始時においてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３をワークメモリにロードしておく。そしてｔｉｔｌｅ＃２の開始時にａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２をワークメモリから削除してａｐｐｌｉｃａｔｉｏｎ＃３のみにするという制御を行う。これと同様にｔｉｔｌｅ＃２の再生開始時においてａｐｐｌｉｃａｔｉｏｎ＃４をワークメモリにロードしておき、ｔｉｔｌｅ＃３の開始時にａｐｐｌｉｃａｔｉｏｎ＃３，＃４をワークメモリから削除するという制御を行いうる。
【００７０】
更に、ｔｉｔｌｅ＃３の再生中においてａｐｐｌｉｃａｔｉｏｎ＃５をワークメモリにロードしておき、ｔｉｔｌｅ＃３の再生終了時にａｐｐｌｉｃａｔｉｏｎ＃５をワークメモリから削除するという制御を行いうる。
タイトル間分岐があった場合でも、分岐元−分岐先において生存しているアプリケーションはワークメモリ上に格納しておき、分岐元にはなく、分岐先にのみ存在するアプリケーションをワークメモリに読み込めば良いから、アプリケーションをワークメモリに読み込む回数は必要最低数になる。このように、読込回数を少なくすることにより、タイトルの境界を意識させないアプリケーション、つまりアンバウンダリなアプリケーションを実現することができる。
【００７１】
続いてアプリケーションの起動属性についてより詳しく説明する。起動属性には、自動的な起動を示す「ＡｕｔｏＲｕｎ」、自動起動の対象ではないが、仮想マシンのワークメモリに置いて良いことを示す「Ｐｒｅｓｅｎｔ」、仮想マシンのワークメモリにはおかれるが、ＣＰＵパワーの割り当ては不可となる「Ｓｕｓｐｅｎｄ」がある。
「ＡｕｔｏＲｕｎ」は、対応するタイトルの分岐と同時に、そのアプリケーションをワークメモリに読み込み、且つ実行する旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、その分岐先タイトルにおいて生存しており、かつ起動属性がＡｕｔｏＲｕｎに設定されたアプリケーションを仮想マシンのワークメモリに読み込み実行する。これによりそのアプリケーションは、タイトル分岐と共に自動的に起動されることになる。
【００７２】
起動属性「Ｐｒｅｓｅｎｔ」は、継続属性であり、分岐元ｔｉｔｌｅにおけるアプリケーションの状態を継続することを示す。また対応するアプリケーションを実行してよいことを示す属性である。起動属性が「Ｐｒｅｓｅｎｔ」である場合、この起動属性が付与されたアプリケーションは、他のアプリケーションからの呼び出しが許可されることになる。アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、起動中のアプリケーションから呼出があると、そのアプリケーションのａｐｐｌｉｃａｔｉｏｎＩＤが、アプリケーション管理テーブルに記述されていて、起動属性が「Ｐｒｅｓｅｎｔ」であるか否かを判定する。「Ｐｒｅｓｅｎｔ」であれば、そのアプリケーションをワークメモリにロードする。一方、その呼出先アプリケーションのａｐｐｌｉｃａｔｉｏｎＩＤがアプリケーション管理テーブルに記述されていない場合、そのアプリケーションはワークメモリにロードされない。アプリケーションによる呼出は、この「Ｐｒｅｓｅｎｔ」が付与されたアプリケーションに限られることになる。「Ｐｒｅｓｅｎｔ」は、起動属性を明示的に指定しない場合に付与されるデフォルトの起動属性であるから、あるアプリケーションの起動属性が無指定「−」である場合、そのアプリケーションの起動属性の起動属性はこのＰｒｅｓｅｎｔであることを意味する。
【００７３】
「Ｓｕｓｐｅｎｄ」とは、リソースは割り付けられているが、ＣＰＵパワーは割り当てられない状態にアプリケーションが置かれることをいう。かかるＳｕｓｐｅｎｄは、例えばゲームタイトルの実行中に、サイドパスを経由するという処理の実現に有意義である。
図２６は、起動属性がとり得る三態様（Ｐｒｅｓｅｎｔ、ＡｕｔｏＲｕｎ、Ｓｕｓｐｅｎｄ）と、直前タイトルにおけるアプリケーション状態の三態様（非起動、起動中、Ｓｕｓｐｅｎｄ）とがとりうる組合せを示す図である。直前状態が”非起動”である場合、起動属性が”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、起動されることになる。
【００７４】
直前状態が”非起動”であり、起動属性が”Ｐｒｅｓｅｎｔ”、”Ｓｕｓｐｅｎｄ”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。
直前状態が”起動中”である場合、起動属性が”Ｐｒｅｓｅｎｔ”、”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。
【００７５】
起動属性が”Ｓｕｓｐｅｎｄ”であるなら、アプリケーションの状態はＳｕｓｐｅｎｄされることになる。直前状態が”Ｓｕｓｐｅｎｄ”である場合、分岐先タイトルの起動属性が”Ｓｕｓｐｅｎｄ”ならＳｕｓｐｅｎｄを維持することになる。”Ｐｒｅｓｅｎｔ”又は”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、レジュームすることになる。アプリケーション管理テーブルにおいて生存区間及び起動属性を定義することにより、タイトル再生区間の進行に沿って、Ｊａｖａ（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。
【００７６】
尚、直前状態が”Ｓｕｓｐｅｎｄ”であり、分岐先タイトルの起動属性が”Ｐｒｅｓｅｎｔ”の場合は、直前状態、すなわちサスペンド状態を維持しても良い。
最後に、各アプリケーションに対する”起動優先度”について説明する。
この起動優先度は、０〜２５５の値をとり、メモリリソース枯渇時や、ＣＰＵ負荷が高まった時に、どのアプリケーションを強制的に終了させるか、また、どちらのアプリケーションからリソースを奪うかという処理をアプリケーションマネージャが行うにあたっての判断材料になる。この場合、アプリケーションマネージャは、起動優先度が低いアプリケーションの動作を終了し、起動優先度が高いアプリケーションの動作を継続させるとの処理を行う。
【００７７】
また起動優先度は、再生中ＰＬに対する要求が競合した場合のアプリケーション間の調停でも利用される。ここであるアプリケーションが、あるプレイリストの早送りしているものとする。ここで別のアプリケーションが同じプレイリストに対するポーズ要求を行ったとすると、これらのアプリケーションに付与された起動優先度を比較する。そして早送りを命じたアプリケーションの起動優先度が高いなら、かかるアプリケーションによる早送りを継続して行う。逆にポーズを命じたアプリケーションの起動優先度が高いなら、早送り中ＰＬをポーズを行う。
【００７８】
以上の生存区間・起動属性・起動優先度により、仮想マシン上で動作し得るアプリケーションの数を所定数以下に制限するよう規定しておくことがオーサリング時に可能なる。そのため、アプリケーションの安定動作を保証することができる。
＜プレイリスト管理テーブル＞
以上がアプリケーション管理テーブルについての説明である。続いてプレイリスト管理テーブルについて説明する。プレイリスト管理テーブルとは、アプリケーションの生存区間において、各アプリケーション実行と同時に行うべき再生制御を示すテーブルである。アプリケーションの動作というのは不安定であり、起動の失敗や異常終了がありうる。そこで起動失敗、異常終了があった場合のＦａｉｌ Ｓａｆｅ機構として、本実施形態ではアプリケーションの生存区間毎に、プレイリスト管理テーブルを設けている。プレイリスト管理テーブルは、あるアプリケーションの生存区間が開始した際、これと同時に行うべき再生制御を規定する情報である。この再生制御とは、プレイリスト情報に基づくＡＶＣｌｉｐ再生であり、プレイリスト情報による再生制御を同時に行うことで、アプリケーション実行と、プレイリスト再生とが同時になされることになる。プレイリスト管理テーブルは、アプリケーションの生存区間毎に設けられるとしたが、プレイリスト管理テーブルが設けられるアプリケーションは、タイトルバウンダリのアプリケーションに限られる。何故ならタイトルアンバウンダリーアプリケーションは、全タイトルを生存区間にしているため、アプリケーション実行と同時にプレイリスト再生を行うという制御は、適合しないからである。
【００７９】
チャプターバウンダリアプリケーションは、１つのプレイリスト内のチャプターからアプリケーション実行を開始するという前提の下で生存区間が規定されているため、プレイリスト再生を規定する必要はないからである。以上のことからプレイリスト管理テーブルは、１つ以上のＴｉｔｌｅからなる生存区間に定義されることになる。
図２７（ａ）は、プレイリスト管理テーブルの内部構成を示す図である。本図に示すようにプレイリスト管理テーブルは、『ＰＬ＿ｉｄ＿ｒｅｆ』と、『Ｐｌａｙｂａｃｋ＿Ａｔｔｒｉｂｕｔｅ』とからなる。
【００８０】
図２７（ｂ）は、プレイリスト管理テーブルを構成する情報要素の意味内容を示す。
『ＰＬ＿ｉｄ＿ｒｅｆ』は、ＰＬ識別子に対する”参照値”が記述されることにより、アプリケーションの生存区間において再生可能となるＰＬがどれであるかを示す。ＰＬ識別子は、ファイルＹＹＹＹＹ．ＭＰＬＳにおいて、ファイル名として付与された５桁の数値ＹＹＹＹＹで表現される。このＹＹＹＹＹが記述されることにより、『ＰＬ＿ｉｄ＿ｒｅｆ』は、対応するＴｉｔｌｅにおいて再生可能となるＰＬがどれであるかを示す。
【００８１】
『Ｐｌａｙｂａｃｋ＿Ａｔｔｒｉｂｕｔｅ』は、アプリケーション管理テーブルにおける起動属性に倣った属性であり、『ＰＬ＿ｉｄ＿ｒｅｆ』に記述されたＰＬを、タイトル開始時において、どのように再生するかを規定する再生属性である。ＰＬに対する再生属性には、『ＡｕｔｏＰｌａｙ』、『Ｐｒｅｓｅｎｔ』といった種別がある。
『ＡｕｔｏＰｌａｙ』とは、対応するタイトルの分岐と同時に、そのプレイリストを再生させる旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、その分岐先タイトルにおいて再生可能であり、かつ再生属性がＡｕｔｏＰｌａｙに設定されたプレイリストの再生を開始する。これにより起動属性がＡｕｔｏＰｌａｙに設定されたプレイリストは、タイトル分岐と共に自動的に起動されることになる。
【００８２】
『Ｐｒｅｓｅｎｔ』とは、起動属性におけるＰｒｅｓｅｎｔ同様、継続属性であり、分岐元ｔｉｔｌｅにおけるＰＬの状態を継続することを示す。また対応するプレイリストを再生してよいことを示す属性である。例えば連続して再生される２つのＴｉｔｌｅがあり、分岐元Ｔｉｔｌｅ側のプレイリスト管理テーブルでは、あるプレイリストの再生属性がＡｕｔｏＰｌａｙに設定され、分岐先Ｔｉｔｌｅ側のプレイリスト管理テーブルでは、そのプレイリストの再生属性がＰｒｅｓｅｎｔに設定されているものとする。ここでプレイリストの再生時間が２時間長であり、このうち１時間が経過した時点で分岐が発生したとする。この場合分岐先Ｔｉｔｌｅでは、再生属性がＰｒｅｓｅｎｔに設定されているので、分岐先Ｔｉｔｌｅにおいて、そのプレイリストは、１時間という再生済み区間の直後から、再生されることになる。このように再生属性をＰｒｅｓｅｎｔに設定しておけば、Ｔｉｔｌｅ間の分岐があった場合でも、プレイリスト再生をその残りの部分から開始することができる。これにより分岐し合う一連のＴｉｔｌｅにおいて、共通のプレイリストを再生するという”タイトル間におけるプレイリスト再生の共通化”を容易に実現することができる。また分岐先タイトルが複数ある場合、これら複数タイトルの再生属性を何れもＰｒｅｓｅｎｔにしておけば、複数のうちどれに分岐したとしても、１つの共通のプレイリスト再生を継続させることができる。
【００８３】
尚Ｔｉｔｌｅの境界は、シームレス再生を保証しなくてもよいので、上述したように複数Ｔｉｔｌｅ間で１つのプレイリストを再生しようとする場合、分岐前後でプレイリスト再生を中断させることは許容される。
また、再生属性が「Ｐｒｅｓｅｎｔ」である場合、この再生属性が付与されたプレイリストは、他のアプリケーションからの再生要求により再生されることになる。アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、起動中のアプリケーションから、プレイリストの再生要求があると、要求を受けたプレイリストのＰＬ＿ｉｄ＿ｒｅｆが、プレイリスト管理テーブルに記述されていて、再生属性が「ＡｕｔｏＰｌａｙ」か「Ｐｒｅｓｅｎｔ」のいずれかか否かを判定する。「ＡｕｔｏＰｌａｙ」か「Ｐｒｅｓｅｎｔ」のいずれかであれば、そのプレイリストを再生する。一方、要求を受けたプレイリストのＰＬ＿ｉｄ＿ｒｅｆがプレイリスト管理テーブルに記述されていない場合、そのプレイリストを再生しない。アプリケーションの要求によるプレイリスト再生は、この「ＡｕｔｏＰｌａｙ」か「Ｐｒｅｓｅｎｔ」のいずれかが付与されたプレイリストに限られることになる。「Ｐｒｅｓｅｎｔ」は、再生属性を明示的に指定しない場合に付与されるデフォルトの再生属性であるから、あるプレイリストの再生属性が無指定「−」であるとそのプレイリストの再生属性はこのＰｒｅｓｅｎｔであることを意味する。
【００８４】
図２８は、分岐先Ｔｉｔｌｅがとり得る三態様（プレイリスト管理テーブル無し（ｉ）、プレイリスト管理テーブル有りで尚且つＡｕｔｏＰｌａｙ（ｉｉ）、プレイリスト管理テーブル有りで尚且つＰｒｅｓｅｎｔ（ｉｉｉ））と、直前タイトルにおけるＰＬの状態（非再生状態、再生中状態）とがとりうる６通りの組合せを示す図である。
本図における６通りの組合せのうち、”直前状態＝非再生状態”と、”分岐先Ｔｉｔｌｅ＝プレイリスト管理テーブル有り、尚且つ、分岐先Ｔｉｔｌｅの再生属性＝ＡｕｔｏＰｌａｙ”との組合せにおいて、分岐先タイトルにおけるＰＬの再生は、自動的に開始することになる。
【００８５】
また”直前状態＝再生中状態”と、”分岐先Ｔｉｔｌｅ＝プレイリスト管理テーブル無し”との組合せにおいて、分岐先タイトルでのＰＬの再生は、自動的に停止することになる。
そしてこれら２つの組合せ以外は全て、分岐元Ｔｉｔｌｅの状態を継続することになる。プレイリスト管理テーブルに基づくプレイリスト再生の開始は、分岐元タイトルにおいて非再生状態であり、分岐先タイトルにおいてＡｕｔｏＰｌａｙ属性が付与されている場合に限られるので、タイトルの分岐発生する毎に、プレイリスト再生を開始させる必要はない。タイトル間の分岐が多数発生したとしても、プレイリスト再生を開始させる回数を必要最低数にすることができる。
プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例について図２９（ａ）を参照しながら説明する。ここで想定する具体例は、２つの連続するＴｉｔｌｅ（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２）であり、そのうちｔｉｔｌｅ＃１では、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２が記述されている。ｔｉｔｌｅ＃２ではＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３が記述されている。一方、ｔｉｔｌｅ＃１のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃１が、ｔｉｔｌｅ＃２のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃２が記述されているものとする。図２９（ｂ）は、図２９（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。
【００８６】
ｔｉｔｌｅ＃１においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、ｔｉｔｌｅ＃１の開始時にはａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２が自動的に起動され、ＰｌａｙＬｉｓｔ＃１の再生が自動的に開始される。
ｔｉｔｌｅ＃２においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、ｔｉｔｌｅ＃１側に記載はあるが、ｔｉｔｌｅ＃２側には記載がないａｐｐｌｉｃａｔｉｏｎ＃１の実行は停止させられる。同じくｔｉｔｌｅ＃１側に記載があるが、ｔｉｔｌｅ＃２側に記載がないＰｌａｙＬｉｓｔ＃１の再生も停止させられる。
【００８７】
ｔｉｔｌｅ＃１側に記載はないが、ｔｉｔｌｅ＃２側に記載があるＰｌａｙＬｉｓｔ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３は再生及び実行が自動的に開始することになる。タイトル分岐があれば、その分岐を契機に、再生すべきプレイリストを他のプレイリストに切り換えることができる。このようにアプリケーション管理テーブル、プレイリスト管理テーブルを用いることで分岐を契機にして、プレイリスト再生を切り換えるという処理をオーサリング段階において規定しておくことができる。
【００８８】
また図２９では、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３にはそれぞれ２００，１２８，２００の起動優先度が与えられている。これらの起動優先度を付与することにより、ＰｌａｙＬｉｓｔ＃１、ＰｌａｙＬｉｓｔ＃２に対する制御要求が競合した場合の調停を行わせることができる。ここでａｐｐｌｉｃａｔｉｏｎ＃１がＰｌａｙＬｉｓｔ＃１に対し早送りを命じているものとする。一方、ａｐｐｌｉｃａｔｉｏｎ＃２がポーズ要求を行ったとする。この場合、アプリケーション管理テーブルに各アプリケーションに対する起動優先度が規定されているため、この起動優先度に従って、両アプリケーションに対する調停がなされることになる。その結果、ａｐｐｌｉｃａｔｉｏｎ＃２による要求を退け、ａｐｐｌｉｃａｔｉｏｎ＃１による制御を継続するという処理をオーサリング時に規定しておくことができる。起動優先度をプレイリスト管理テーブルと併せて利用することにより、プレイリストに対する制御が競合した場合の調停さえも再生装置に行わせることができる。
【００８９】
プレイリスト管理テーブル記述の他の具体例について説明する。図３０（ａ）は、プレイリスト管理テーブルの他の記述例を示す図である。本図で想定しているのは、２つの連続するタイトル（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２）において、ｔｉｔｌｅ＃１側のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃１が、再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２が記述され、ｔｉｔｌｅ＃１側のアプリケーション管理テーブルには、ＡｕｔｏＰｌａｙアプリケーションであるａｐｐｌｉｃａｔｉｏｎ＃１と、実行可能なアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２が記述されている。一方ｔｉｔｌｅ＃２側のプレイリスト管理テーブルには再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２、ＰｌａｙＬｉｓｔ＃３が記述され、アプリケーション管理テーブルには、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃３が記述されている。図３０（ｂ）は、図３０（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。ｔｉｔｌｅ＃１のアプリケーション管理テーブルには、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃１が記述されているので、ｔｉｔｌｅ＃１の開始時にはａｐｐｌｉｃａｔｉｏｎ＃１が自動起動される。一方、ｔｉｔｌｅ＃１のアプリケーション管理テーブルには、実行可能アプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２が記述されているので、ａｐｐｌｉｃａｔｉｏｎ＃１からの呼出ｙｄ１によりａｐｐｌｉｃａｔｉｏｎ＃２が起動される。
【００９０】
ｔｉｔｌｅ＃２側のアプリケーション管理テーブルにおいてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２が非生存になっており、代わりにＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃３が記述されている。そのためｔｉｔｌｅ＃１−ｔｉｔｌｅ＃２の境界部では、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２を停止し、ａｐｐｌｉｃａｔｉｏｎ＃３を自動的に起動するとの処理がなされる。プレイリスト管理テーブルを参照すると、ｔｉｔｌｅ＃１側のプレイリスト管理テーブルは、ＰｌａｙＬｉｓｔ＃１、ＰｌａｙＬｉｓｔ＃２が再生可能と記述されており、そのうちＰｌａｙＬｉｓｔ＃１はＡｕｔｏＰｌａｙ属性になっている。そのためＰｌａｙＬｉｓｔ＃１は、ｔｉｔｌｅ＃１の開始時において自動的に再生される。
【００９１】
ｔｉｔｌｅ＃１側のプレイリスト管理テーブルには、ＰｌａｙＬｉｓｔ＃１の他、ＰｌａｙＬｉｓｔ＃２が再生可能であると記述されているので、ａｐｐｌｉｃａｔｉｏｎ＃１はＰｌａｙＬｉｓｔ＃１の再生を停止させ、代わりにＰｌａｙＬｉｓｔ＃２の再生を要求することにより、プレイリスト交代を実行することができる。
ｔｉｔｌｅ＃２側のプレイリスト管理テーブルには、再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２、ＰｌａｙＬｉｓｔ＃３が記述されている。そしてＡｕｔｏＰｌａｙ属性が付与されたプレイリストはない。そのため、仮にｔｉｔｌｅ＃１開始時において自動再生されたＰｌａｙＬｉｓｔ＃１の再生がｔｉｔｌｅ＃２まで継続したとしても、ＰｌａｙＬｉｓｔ＃１の再生は自動的に終了することになる。
【００９２】
しかしＰｌａｙＬｉｓｔ＃２再生が継続したままｔｉｔｌｅ＃２に至れば、ＰｌａｙＬｉｓｔ＃２再生はｔｉｔｌｅ＃２開始以降も継続する。ｔｉｔｌｅ＃２のプレイリスト管理テーブルには、再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２、ＰｌａｙＬｉｓｔ＃３が記述されている。そのため、ｔｉｔｌｅ＃２で実行中となるａｐｐｌｉｃａｔｉｏｎ＃３は、ＰｌａｙＬｉｓｔ＃２の再生を停止し、代わりにＰｌａｙＬｉｓｔ＃３の再生を要求することにより、再生中のプレイリストを交代させることができる。
【００９３】
次にプレイリスト管理テーブルによりタイトル再生区間がどのように規定されるかを、図３１を参照しながら説明する。
図３１（ａ）は、再生属性がＡｕｔｏＰｌａｙに設定されたタイトルのタイトル再生区間を示す図である。再生属性がＡｕｔｏＰｌａｙを示すよう設定されれば、タイトルの再生開始と同時に、ＡｕｔｏＰｌａｙＰＬの再生を開始する。ここでアプリケーションが正常に動作し、正常終了したとしても、このタイトル再生区間は、ＰＬ時間軸を基準にして定められる。
【００９４】
図３１（ｂ）は、プレイリスト管理テーブルにおいて再生属性が”ＡｕｔｏＰｌａｙ”を示すよう設定され、アプリケーションが異常終了した場合を示す。かかる異常終了により、どのアプリケーションも動作してない状態になるが、ＡｕｔｏＰｌａｙＰＬの再生は継続する。この場合も、ＡｕｔｏＰｌａｙＰＬのＰＬ時間軸がタイトル再生区間になる。
図３１（ｃ）は、プレイリスト管理テーブルにおいて再生属性が”ＡｕｔｏＰｌａｙ”を示すよう設定され、メインアプリの起動に失敗したケースを示す。この場合も、ＡｕｔｏＰｌａｙＰＬ再生は、アプリケーションの起動失敗とは関係なしに行われるので、ＡｕｔｏＰｌａｙＰＬの時間軸がタイトル再生区間になる。
【００９５】
以上のようにプレイリスト管理テーブルの再生属性を、”ＡｕｔｏＰｌａｙ”に設定しておけば、Ｊａｖａ（登録商標）アプリケーションの起動に、５〜１０秒という時間がかかったとしても、その起動がなされている間、”とりあえず何かが写っている状態”になる。タイトル実行開始時において、アプリケーション起動に時間がかかったとしても、画面は、”とりあえず何かが写っている状態”になる。これにより、アプリケーション起動に時間がかかることによるスタートアップディレイの長期化を補うことができる。
【００９６】
アプリケーション管理テーブル及びプレイリスト管理テーブルを定義することにより、タイトル再生区間の進行に沿って、Ｊａｖａ（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。以上が記録媒体についての説明である。続いて本発明に係る再生装置について説明する。
【００９７】
図３２は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムＬＳＩと、ドライブ装置という２つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムＬＳＩは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、ＢＤ−ＲＯＭドライブ１、リードバッファ２、デマルチプレクサ３、ビデオデコーダ４、ビデオプレーン５、Ｐ−Ｇｒａｐｈｉｃｓデコーダ６、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン７、合成部８、フォントゼネレータ９、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０、スイッチ１１、Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン１２、合成部１３、ＣＬＵＴ部１４、ＣＬＵＴ部１５、オーディオデコーダ１６、Ｎｅｔｗｏｒｋ Ｄｅｖｉｃｅ１７、Ｌｏｃａｌ Ｓｔｏｒａｇｅ１８、リードバッファ１９、デマルチプレクサ２０、命令ＲＯＭ２１、ユーザイベント処理部２２、ＰＳＲセット２３、ＣＰＵ２４、シナリオメモリ２５、ローカルメモリ２６、スイッチ２７から構成される。
【００９８】
先ず初めに、ＢＤ−ＲＯＭに記録されたＡＶＣｌｉｐ再生に係る構成要素（ＢＤドライブ１〜オーディオデコーダ１６）について説明する。
ＢＤ−ＲＯＭドライブ１は、ＢＤ−ＲＯＭのローディング／イジェクトを行い、ＢＤ−ＲＯＭに対するアクセスを実行する。
リードバッファ２は、ＦＩＦＯメモリであり、ＢＤ−ＲＯＭから読み出されたＴＳパケットが先入れ先出し式に格納される。
【００９９】
デマルチプレクサ（Ｄｅ−ＭＵＸ）３は、リードバッファ２からＴＳパケットを取り出して、このＴＳパケットを構成するＴＳパケットをＰＥＳパケットに変換する。そして変換により得られたＰＥＳパケットのうち、ＣＰＵ２４から設定されたＰＩＤをもつものをビデオデコーダ４、Ｐ−Ｇｒａｐｈｉｃｓデコーダ６、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０、オーディオデコーダ１６のどれかに出力する。
ビデオデコーダ４は、デマルチプレクサ３から出力された複数ＰＥＳパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込む。
【０１００】
ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ領域である。ビデオプレーン５における解像度は１９２０×１０８０であり、このビデオプレーン５に格納されたピクチャデータは、１６ビットのＹＵＶ値で表現された画素データにより構成される。ビデオプレーン５では、ビデオストリームにおける一フレーム毎の再生映像を、スケーリングすることができる。スケーリングとは、一フレーム毎の再生画像をビデオプレーン５全体の１／４（クオータという）、１／１（フルスケールという）のどちらかに変化させることである。かかるスケーリングを、ＢＤ−ＪモードにおいてＣＰＵ２４からの指示に従い実行するので、ビデオストリームの再生画像を、画面の隅に追いやったり、全面的に出すという画面演出が可能になる。
【０１０１】
Ｐ−Ｇｒａｐｈｉｃｓデコーダ６は、ＢＤ−ＲＯＭから読み出されたプレゼンテーショングラフィクスストリームをデコードして、非圧縮グラフィクスをＰｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン７に書き込む。グラフィクスストリームのデコードにより、字幕が画面上に現れることになる。
Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン７は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。本プレーンにおける解像度は１９２０×１０８０であり、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン７中の非圧縮グラフィクスの各画素は８ビットのインデックスカラーで表現される。ＣＬＵＴ（Ｃｏｌｏｒ Ｌｏｏｋｕｐ Ｔａｂｌｅ）を用いてかかるインデックスカラーを変換することにより、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン７に格納された非圧縮グラフィクスは、表示に供される。
【０１０２】
合成部８は、ビデオプレーン５に格納された非圧縮状態のピクチャデータ（ｉ）を、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン７の格納内容と合成する。
フォントゼネレータ９は、文字フォントを用いてｔｅｘｔＳＴストリームに含まれるテキストコードをビットマップに展開してＰｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン７に書き込む。
Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０は、ＨＤＭＶモードにおいてＢＤ−ＲＯＭ又はＬｏｃａｌ Ｓｔｏｒａｇｅ１８から読み出されたＩＧストリームをデコードして、非圧縮グラフィクスをＩｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン１２に書き込む。
【０１０３】
スイッチ１１は、フォントゼネレータ９が生成したフォント列、Ｐ−Ｇｒａｐｈｉｃｓデコーダ６のデコードにより得られたグラフィクスの何れかを選択的にＰｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン７に書き込むスイッチである。
Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン１２は、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０によるデコードで得られた非圧縮グラフィクスが書き込まれる。またＩｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン１２には、ＢＤ−Ｊモードにおいて、アプリケーションにより描画された文字やグラフィクスが書き込まれる。
【０１０４】
合成部１３は、Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン１２の格納内容と、合成部８の出力である合成画像（非圧縮状態のピクチャデータと、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン７の格納内容とを合成したもの）とを合成する。かかる合成により、アプリケーションがＩ−Ｇｒａｐｈｉｃｓデコーダ１０に書き込んだ文字・グラフィクスを、非圧縮状態のピクチャデータ上にオーバレイして、表示することができる。
【０１０５】
ＣＬＵＴ部１４は、ビデオプレーン５に格納された非圧縮グラフィクスにおけるインデックスカラーを、Ｙ，Ｃｒ，Ｃｂ値に変換する。
ＣＬＵＴ部１５は、Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン１２に格納された非圧縮グラフィクスにおけるインデックスカラーを、Ｙ，Ｃｒ，Ｃｂ値に変換する。
オーディオデコーダ１６は、デマルチプレクサ３から出力されたＰＥＳパケットを復号して、非圧縮形式のオーディオデータを出力する。
【０１０６】
以上がＡＶＣｌｉｐ再生に係る構成要素である。続いてＢＤ−Ｊモードでの動作に係る構成要素（Ｎｅｔｗｏｒｋ Ｄｅｖｉｃｅ１７〜Ｄｅ−ｍｕｘ２０）について説明する。
Ｎｅｔｗｏｒｋ Ｄｅｖｉｃｅ１７は、再生装置における通信機能を実現するものであり、ＢＤ−ＪモードにおいてＵＲＬ指定がＪａｖａ（登録商標）アプリケーションから与えられれば、そのＵＲＬにあたるｗｅｂサイトとのＴＣＰコネクション、ＦＴＰコネクション等を確立する。かかるコネクション確立によりｗｅｂサイトからのダウンロードをＪａｖａ（登録商標）アプリケーションに行わせる。
【０１０７】
Ｌｏｃａｌ Ｓｔｏｒａｇｅ１８は、Ｎｅｔｗｏｒｋ Ｄｅｖｉｃｅ１７により確立されたコネクションを通じてｗｅｂサイトからダウンロードされたコンテンツ等、ＢＤ−ＲＯＭ以外の記録媒体、通信媒体から供給されたコンテンツを、メタデータと共に格納しておくためのハードディスクである。このメタデータは、ダウンロードコンテンツをＬｏｃａｌ Ｓｔｏｒａｇｅ１８にバインドして管理するための情報であり、このＬｏｃａｌ Ｓｔｏｒａｇｅ１８をアクセスすることで、ＢＤ−Ｊモードにおけるアプリケーションは、ダウンロードコンテンツ長さを利用した様々な処理を行うことができる。
【０１０８】
リードバッファ１９は、ＦＩＦＯメモリであり、Ｌｏｃａｌ Ｓｔｏｒａｇｅ１８に格納されたダウンロードコンテンツに、ＳｕｂＣｌｉｐが含まれている場合、このＳｕｂＣｌｉｐを構成するＴＳパケットを、先入れ先出し式に格納する。
デマルチプレクサ（Ｄｅ−ＭＵＸ）２０は、リードバッファ１９からＴＳパケットを取り出して、ＴＳパケットをＰＥＳパケットに変換する。そして変換により得られたＰＥＳパケットのうち、所望のＰＩＤをもつものをフォントゼネレータ９、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０、オーディオデコーダ１６に出力する。
【０１０９】
以上のＮｅｔｗｏｒｋ Ｄｅｖｉｃｅ１７〜Ｄｅ−ｍｕｘ２０により、Ｊａｖａ（登録商標）アプリケーションがネットワークを通じてダウンロードしたコンテンツを、ＢＤ−ＲＯＭに記録されたコンテンツ同様再生させることができる。続いて、再生装置における統合制御を実現する構成要素（命令ＲＯＭ２１〜スイッチ２７）について説明する。
命令ＲＯＭ２１は、再生装置の制御を規定するソフトウェアを記憶している。
【０１１０】
ユーザイベント処理部２２は、リモコンや再生装置のフロントパネルに対するキー操作に応じて、その操作を行うユーザイベントをＣＰＵ２４に出力する。
ＰＳＲセット２３は、再生装置に内蔵されるレジスタであり、６４個のＰｌａｙｅｒ Ｓｔａｔｕｓ Ｒｅｇｉｓｔｅｒ（ＰＳＲ）と、４０９６個のＧｅｎｅｒａｌ Ｐｕｒｐｏｓｅ Ｒｅｇｉｓｔｅｒ（ＧＰＲ）とからなる。Ｐｌａｙｅｒ Ｓｔａｔｕｓ Ｒｅｇｉｓｔｅｒの設定値（ＰＳＲ）のうち、ＰＳＲ４〜ＰＳＲ８は、現在の再生時点を表現するのに用いられる。
【０１１１】
ＰＳＲ４は、１〜１００の値に設定されることで、現在の再生時点が属するタイトルを示し、０に設定されることで、現在の再生時点がトップメニューであることを示す。
ＰＳＲ５は、１〜９９９の値に設定されることで、現在の再生時点が属するチャプター番号を示し、０ｘＦＦＦＦに設定されることで、再生装置においてチャプター番号が無効であることを示す。
【０１１２】
ＰＳＲ６は、０〜９９９の値に設定されることで、現在の再生時点が属するＰＬ（カレントＰＬ）の番号を示す。
ＰＳＲ７は、０〜２５５の値に設定されることで、現在の再生時点が属するＰｌａｙＩｔｅｍ（カレントＰｌａｙ Ｉｔｅｍ）の番号を示す。
ＰＳＲ８は、０〜ＯｘＦＦＦＦＦＦＦＦの値に設定されることで、４５ＫＨｚの時間精度を用いて現在の再生時点（カレントＰＴＭ（Ｐｒｅｓｅｎｔａｔｉｏｎ ＴｉＭｅ））を示す。以上のＰＳＲ４〜ＰＳＲ８により、図２１（ａ）におけるＢＤ−ＲＯＭ全体の時間軸において、現在の再生時点はどこであるかを特定することができる。
【０１１３】
ＣＰＵ２４は、命令ＲＯＭ２１に格納されているソフトウェアを実行して、再生装置全体の制御を実行する。この制御の内容は、ユーザイベント処理部２２から出力されたユーザイベント、及び、ＰＳＲセット２３における各ＰＳＲの設定値に応じて動的に変化する。
シナリオメモリ２５は、カレントのＰＬ情報やカレントのＣｌｉｐ情報を格納しておくためのメモリである。カレントＰＬ情報とは、ＢＤ−ＲＯＭに記録されている複数ＰＬ情報のうち、現在処理対象になっているものをいう。カレントＣｌｉｐ情報とは、ＢＤ−ＲＯＭに記録されてい複数Ｃｌｉｐ情報のうち、現在処理対象になっているものをいう。
【０１１４】
ローカルメモリ２６は、ＢＤ−ＲＯＭからの読み出しは低速である故、ＢＤ−ＲＯＭの記録内容を一時的に格納しておくためのキャッシュメモリである。かかるローカルメモリ２６が存在することにより、ＢＤ−Ｊモードにおけるアプリケーション実行は、効率化されることになる。
スイッチ２７は、ＢＤ−ＲＯＭ及びＬｏｃａｌ Ｓｔｏｒａｇｅ１８から読み出された各種データを、リードバッファ２、リードバッファ１９、シナリオメモリ２５、ローカルメモリ２６のどれかに選択的に投入するスイッチである。
【０１１５】
以上が、本実施形態に係る再生装置のハードウェア構成である。続いて本実施形態に係る再生装置のソフトウェア構成について説明する。
図３３は、ＲＯＭ２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。本図に示すように、再生装置のレイア構成は、以下のａ），ｂ），ｃ）からなる。つまり、
ａ）ＢＤ Ｐｌａｙｅｒ Ｄｅｖｉｃｅの第１階層、
ｂ）ＢＤ Ｐｌａｙｅｒ Ｍｏｄｅｌの第２階層、
ｃ）Ａｐｐｌｉｃａｔｉｏｎ Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｍｅｎｔの第３階層からなる。
これらの階層のうち図３２に示した再生装置のハードウェア構成は、第１階層に属することになる。本図の第１階層”ＢＤ Ｐｌａｙｅｒ Ｄｅｖｉｃｅ”には、図３２に示したハードウェア構成のうちビデオデコーダ４、Ｐ−Ｇｒａｐｈｉｃｓデコーダ６、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０、オーディオデコーダ１６からなる”デコーダ”と、ビデオプレーン５、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン７、Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン１２からなる”プレーン”、ＢＤ−ＲＯＭ及びそのファイルシステム、Ｌｏｃａｌ Ｓｔｏｒａｇｅ１８及びそのファイルシステムを含む。
【０１１６】
第２階層”ＢＤ Ｐｌａｙｅｒ Ｍｏｄｅｌ”は、以下のｂ１），ｂ２）の層からなる。つまり、
ｂ２）Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２の層
ｂ１）Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０及びＰｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１の層
からなり、自身より上位の階層に対し、ファンクションＡＰＩを提供する。
第３階層”Ａｐｐｌｉｃａｔｉｏｎ Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｍｅｎｔ”は、以下のｃ１），ｃ２）の階層からなる。つまり、
ｃ１）モジュールマネージャ３４が存在する層、
ｃ２）ＨＤＭＶモジュール３３、ＢＤ−Ｊモジュール３５が存在する層
からなる。図３３のレイアモデルにおいてこのモジュールマネージャ３４が最上位の階層に位置するが、モジュールマネージャ３４は、ＨＤＭＶモジュール３３及びＢＤ−Ｊモジュール３５をバイパスしてＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に至る迂回路ｕｒ１を有している。この迂回路によりモジュールマネージャ３４は、図３３のレイアモデルにおいて”Ｌ”字形を逆さまにした形状をなし、Ｕｓｅｒ Ｅｖｅｎｔ Ｍａｎａｇｅｒ３７を内蔵した構成になっている。
【０１１７】
ＢＤ−Ｊモジュール３５は、いわゆるＪａｖａ（登録商標）プラットフォームであり、Ｊａｖａ（登録商標）仮想マシン３８を中核にした構成になっている。Ｊａｖａ（登録商標）仮想マシン３８内のワークメモリは、様々なシステムプログラムやアプリケーションが動作している。Ｊａｖａ（登録商標）仮想マシン３８の上位に描いた、アプリケーションマネージャ３６、Ｅｖｅｎｔ Ｌｉｓｔｎｅｒ Ｍａｎａｇｅｒ３９（Ｄｅｆａｕｌｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ４０）は、そうしたシステムプログラムの１つである。このうちアプリケーションマネージャ３６の中にはＰＬＭＴ Ｐｒｃｅｓｓｏｒ４１が存在している。またＢＤ−Ｊモジュール３５と、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２との間には、Ｐｅｒｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ４２が介在している。
【０１１８】
先ず初めに、第２層に属するＶｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０〜モジュールマネージャ３４について説明する。図３４は、Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０〜モジュールマネージャ３４による処理を模式化した図である。
Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０は、Ｌｏｃａｌ Ｓｔｏｒａｇｅ１８に格納されたダウンロードコンテンツを、ＢＤ−ＲＯＭにおけるディスクコンテンツと一体的に取り扱うための仮想的なファイルシステムである。ここでＬｏｃａｌ Ｓｔｏｒａｇｅ１８に格納されたダウンロードコンテンツは、ＳｕｂＣｌｉｐ、Ｃｌｉｐ情報、プレイリスト情報を含む。このダウンロードコンテンツにおけるプレイリスト情報はＢＤ−ＲＯＭ及びＬｏｃａｌ Ｓｔｏｒａｇｅ１８のどちらに存在するＣｌｉｐ情報であっても、指定できる点で、ＢＤ−ＲＯＭ上のプレイリスト情報と異なる。この指定にあたって、Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０上のプレイリスト情報は、ＢＤ−ＲＯＭやＬｏｃａｌ Ｓｔｏｒａｇｅ１８におけるファイルをフルパスで指定する必要はない。ＢＤ−ＲＯＭ上のファイルシステムやＬｏｃａｌ Ｓｔｏｒａｇｅ１８上のファイルシステムは、仮想的な１つのファイルシステム（Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０）として、認識されるからである。故に、ＰｌａｙＩｔｅｍ情報におけるＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ及びＳｕｂＰｌａｙＩｔｅｍ情報のＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅは、Ｃｌｉｐ情報の格納したファイルのファイルボデイにあたる５桁の数値を指定することにより、Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０、ＢＤ−ＲＯＭ上のＡＶＣｌｉｐを指定することができる。Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０を介してＬｏｃａｌ Ｓｔｏｒａｇｅ１８の記録内容を読み出し、ＢＤ−ＲＯＭの記録内容と動的に組み合わせることにより、様々な再生のバリエーションを産み出すことができる。Ｌｏｃａｌ Ｓｔｏｒａｇｅ１８と、ＢＤ−ＲＯＭとを組合せてなるディスクコンテンツは、ＢＤ−ＲＯＭにおけるディスクコンテンツと対等に扱われるので、本願における”ＢＤ−ＲＯＭ”は、Ｌｏｃａｌ Ｓｔｏｒａｇｅ１８＋ＢＤ−ＲＯＭの組合せからなる仮想的な記録媒体をも含むことにする。
【０１１９】
Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１は、ＡＶ再生ファンクションを実行する。再生装置のＡＶ再生ファンクションとは、ＤＶＤプレーヤ、ＣＤプレーヤから踏襲した伝統的な機能群であり、再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（Ｐａｕｓｅ Ｏｎ）、一時停止の解除（Ｐａｕｓｅ Ｏｆｆ）、Ｓｔｉｌｌ機能の解除（ｓｔｉｌｌ ｏｆｆ）、速度指定付きの早送り（Ｆｏｒｗａｒｄ Ｐｌａｙ（ｓｐｅｅｄ））、速度指定付きの巻戻し（Ｂａｃｋｗａｒｄ Ｐｌａｙ（ｓｐｅｅｄ））、音声切り換え（Ａｕｄｉｏ Ｃｈａｎｇｅ）、副映像切り換え（Ｓｕｂｔｉｔｌｅ Ｃｈａｎｇｅ）、アングル切り換え（Ａｎｇｌｅ Ｃｈａｎｇｅ）といった機能である。ＡＶ再生ファンクションを実現するべく、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１は、リードバッファ２上に読み出されたＡＶＣｌｉｐのうち、所望に時刻にあたる部分のデコードを行うよう、ビデオデコーダ４、Ｐ−Ｇｒａｐｈｉｃｓデコーダ６、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０、オーディオデコーダ１６を制御する。所望の時刻としてＰＳＲ８（カレントＰＴＭ）に示される箇所のデコードを行わせることにより、ＡＶＣｌｉｐにおいて、任意の時点を再生を可能することができる。
【０１２０】
再生制御エンジン（Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ（ＰＣＥ））３２は、プレイリストに対する再生制御ファンクション（ｉ）、ＰＳＲセット２３における状態取得／設定ファンクション（ｉｉ）といった諸機能を実行する。ＰＬに対する再生制御ファンクションとは、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１が行うＡＶ再生ファンクションのうち、再生開始や再生停止を、カレントＰＬ情報及びＣｌｉｐ情報に従って行わせることをいう。これら機能（ｉ）〜（ｉｉ）は、ＨＤＭＶモジュール３３〜ＢＤ−Ｊモジュール３５からのファンクションコールに応じて実行する。
【０１２１】
つまり、ＰＬ再生を命じるファンクションコールがあれば、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２は、再生が命じられたプレイリスト情報を、Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０経由でＢＤ−ＲＯＭ又はＬｏｃａｌ Ｓｔｏｒａｇｅ１８から読み出す。そのように読み出されたプレイリスト情報内のＰｌａｙＩｔｅｍ情報を参照し、そのＰｌａｙＩｔｅｍ情報においてＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅに記載されているＣｌｉｐ情報を、Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０経由でＢＤ−ＲＯＭ又はＬｏｃａｌ Ｓｔｏｒａｇｅ１８から読み出す。図３４における◎１，２，３，４は、Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０経由のプレイリスト情報読み出し（◎１）、プレイリスト情報を構成するＰｌａｙＩｔｅｍ情報の解読（◎２）、Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０経由のＣｌｉｐ情報読み出し（◎３）、Ｃｌｉｐ情報の解読（◎４）を模式化したものである。以上の過程を経てＣｌｉｐ情報、プレイリスト情報が解読されれば、ＡＶＣｌｉｐを構成するＴＳパケットを、Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０を通じてＰｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１に引き渡す。このようにしてＰｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１にＴＳパケットが順次渡れば、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１はＡＶＣｌｉｐを構成するＴＳパケットをデコーダに出力して、プレーンに表示させる。図中の☆１，２，３，４は、ＡＶＣｌｉｐを構成するＴＳパケットの読み出し（☆１，２）、Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０からＰｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１へのＴＳパケット引き渡し（☆３）、デコーダへのＴＳパケット投入（☆４）、デコーダから各種プレーンへのデコード結果出力（☆５）を模式的に示している。
【０１２２】
ＨＤＭＶモジュール３３は、ＨＤＭＶモードの実行主体であり、ｍｏｂｊ＿ｉｄにより分岐先ＭｏｖｉｅＯｂｊｅｃｔを指定したａｃｔｉｖａｔｅ要求（ａｃｔｉｖａｔｅ（ｍｏｂｊ＿ｉｄ））がモジュールマネージャ３４からなされれば、ＭｏｖｉｅＯｂｊｅｃｔ（ｍｏｂｊ＿ｉｄ）をローカルメモリ２６に読み出して、このＭｏｖｉｅ Ｏｂｊｅｃｔに記述されたナビゲーションコマンドを解読し、解読結果に基づきＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に対するファンクションコールを実行する。図２８において▽２，▽３，▽４が付された矢印は、モジュールマネージャ３４によるａｃｔｉｖａｔｅ（ｍｏｂｊ＿ｉｄ）（２）、ＭｏｖｉｅＯｂｊｅｃｔに記述されたナビゲーションコマンドの解読（３）、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に対するファンクションコール（４）を、模式的に示している。
【０１２３】
モジュールマネージャ３４は、ＢＤ−ＲＯＭから読み出されたＩｎｄｅＸ．ｂｄｍｖを保持して、分岐制御を行う。この分岐制御は、カレントタイトルを構成する動的シナリオにＴｅｒｍｉｎａｔｅイベントを発行し、分岐先タイトルを構成する動的シナリオにＡｃｔｉｖａｔｅイベントを発行することでなされる。ｔｉｔｌｅ＿ｉｄを指定したＪｕｍｐＴｉｔｌｅコマンド（ＪｕｍｐＴｉｔｌｅ（ｔｉｔｌｅ＿ｉｄ））をＭｏｖｉｅＯｂｊｅｃｔが実行した場合、カレントタイトルを構成するＭｏｖｉｅＯｂｊｅｃｔにＴｅｒｍｉｎａｔｅイベントを発行し、ｔｉｔｌｅ＿ｉｄに対応するタイトルを構成するＭｏｖｉｅ Ｏｂｊｅｃｔをａｃｔｉｖａｔｅするよう、ａｃｔｉｖａｔｅ（ｍｏｂｊ＿ｉｄ）イベントが発行する。図中の▽０，▽１，▽２が付された矢印は、ＪｕｍｐＴｉｔｌｅコマンドの実行（▽０）、モジュールマネージャ３４によるＩｎｄｅｘ．ｂｄｍｖ参照（▽１）、分岐先Ｔｉｔｌｅを構成するＭｏｖｉｅ Ｏｂｊｅｃｔのａｃｔｉｖａｔｅ（▽２）の通知を模式的に示している。ＪｕｍｐＴｉｔｌｅＡＰＩ（ＪｕｍｐＴｉｔｌｅ（ｔｉｔｌｅ＿ｉｄ））をＢＤ−Ｊ Ｏｂｊｅｃｔがコールした場合も同様であり、カレントタイトルを構成するＢＤ−Ｊ ＯｂｊｅｃｔにＴｅｒｍｉｎａｔｅイベントを発行し、そのｔｉｔｌｅ＿ｉｄに対応するタイトルを構成するＢＤ−Ｊ Ｏｂｊｅｃｔをａｃｔｉｖａｔｅするよう、ａｃｔｉｖａｔｅ（ｂｏｂｊ＿ｉｄ）をＢＤ−Ｊモジュール３５に発行する。
【０１２４】
以上がＰｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１〜モジュールマネージャ３４についての説明である。続いてアプリケーションマネージャ３６について、図３５を参照しながら説明する。図３５は、アプリケーションマネージャ３６を示す図である。
アプリケーションマネージャ３６は、タイトル分岐が発生する度に、分岐前タイトルでは実行されていないが、新たなタイトルではＡｕｔｏＲｕｎの起動属性を有するアプリケーションを起動するようＪａｖａ（登録商標）仮想マシン３８に指示する。それと共に、分岐前タイトルでは実行されていたが、新たなタイトルを生存区間としないアプリケーションを終了させる。これら起動制御及び終了制御は、カレントＢＤ−Ｊ Ｏｂｊｅｃｔにおけるアプリケーション管理テーブルを参照した上でなされる。ここでタイトル分岐があった場合、モジュールマネージャ３４からａｃｔｉｖａｔｅ（ｂｏｂｊ＿ｉｄ）が通知される。かかる通知があれば、ｂｏｂｊ＿ｉｄに対応するＢＤ−Ｊ ＯｂｊｅｃｔをカレントＢＤ−Ｊ Ｏｂｊｅｃｔにして、そのカレントＢＤ−Ｊ Ｏｂｊｅｃｔにおけるアプリケーション管理テーブルを参照することで、上述した自動起動すべきアプリケーション及び自動終了すべきアプリケーションを特定する。図３５における☆０，☆１，☆２，☆３は、ＴｉｔｌｅＪｕｍｐの発生（☆０）、ａｃｔｉｖａｔｅ（ｂｏｂｊ＿ｉｄ）の通知（☆１）、アプリケーション管理テーブル参照（☆２）、Ｊａｖａ（登録商標）仮想マシン３８に対するアプリケーション起動指示（☆３）という一連の過程を模式化して示す。この起動指示によりＪａｖａ（登録商標）仮想マシン３８は、ローカルメモリ２６からワークメモリにｘｌｅｔプログラムを読み出す（☆４，５）。
【０１２５】
以上がアプリケーションマネージャ３６についての説明である。続いてＵｓｅｒ Ｅｖｅｎｔ Ｍａｎａｇｅｒ３７〜Ｄｅｆａｕｌｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ４０について、図３６を参照しながら説明する。
Ｕｓｅｒ Ｅｖｅｎｔ Ｍａｎａｇｅｒ３７は、ユーザイベント処理部２２が受け付けたユーザイベントを、再生制御のためのユーザイベントと、キーイベントとに分離する。再生制御のためのユーザイベントとは、再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（Ｐａｕｓｅ Ｏｎ）、一時停止の解除（Ｐａｕｓｅ Ｏｆｆ）、Ｓｔｉｌｌ機能の解除（ｓｔｉｌｌ ｏｆｆ）、速度指定付きの早送り（Ｆｏｒｗａｒｄ Ｐｌａｙ（ｓｐｅｅｄ））、速度指定付きの巻戻し（Ｂａｃｋｗａｒｄ Ｐｌａｙ（ｓｐｅｅｄ））、音声切り換え（Ａｕｄｉｏ Ｃｈａｎｇｅ）、副映像切り換え（Ｓｕｂｔｉｔｌｅ Ｃｈａｎｇｅ）、アングル切り換え（Ａｎｇｌｅ Ｃｈａｎｇｅ）のどれかを命じるユーザイベントである。一方キーイベントとは、Ｐｏｐ−ｕｐキー，ＭｏｖｅＵｐキー，ＭｏｖｅＤｏｗｎキー，ＭｏｖｅＲｉｇｈｔキー，ＭｏｖｅＬｅｆｔキー，Ｎｕｍｅｒｉｃキーのどれかの押下を示すユーザイベントである。そして再生制御のためのユーザイベントに基づき、再生制御ファンクションをＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に実行させるためのファンクションコールを行う。このファンクションコールは、Ｕ０（Ｕｓｅｒ Ｏｐｅｒａｔｉｏｎ）と呼ばれ、ＨＤＭＶモジュール３３、ＢＤ−Ｊモジュール３５を介することなく、モジュールマネージャ３４における迂回路にあるＵＯコントローラ３７ａを用いてなされる。これにより再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（Ｐａｕｓｅ Ｏｎ）、一時停止の解除（Ｐａｕｓｅ Ｏｆｆ）というような再生制御は、遅延なくなされることになる。図中の☆１，２，３は、Ｕｓｅｒ Ｅｖｅｎｔ Ｍａｎａｇｅｒ３７による再生制御ユーザイベントと、キーイベントとの分離（☆１，２）、再生制御ユーザイベントに基づくＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に対するファンクションコール（☆３）を模式的に示している。
【０１２６】
Ｊａｖａ（登録商標）仮想マシン３８は、アプリケーションを構成するｘｌｅｔプログラムをワークメモリにロードして、ｘｌｅｔプログラムを解読し、解読結果に従って、下位層に対する制御を行う。下位層への制御は、ＪＭＦメソッドを図示しないＢＤミドルウェアに発行して、ＢＤ再生装置が対応しているファンクションコールに置き換させ、置換後のファンクションコールをＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に発行することでなされる。
【０１２７】
Ｅｖｅｎｔ Ｌｉｓｔｎｅｒ Ｍａｎａｇｅｒ３９は、キーイベントを解析し、イベントの振り分けを行う。図中の実線矢印◇１，◇２は、このＥｖｅｎｔ Ｌｉｓｔｎｅｒ Ｍａｎａｇｅｒ３９による振り分けを模式的に示す。ｘｌｅｔプログラム内のＥｖｅｎｔ Ｌｉｓｔｎｅｒに登録されたキーイベントなら、ＢＤ−Ｊ Ｏｂｊｅｃｔにより間接参照されているｘｌｅｔプログラムにかかるイベントを振り分ける。ｘｌｅｔプログラムのＥｖｅｎｔ Ｌｉｓｔｎｅｒには、ＪＭＦに対応したキーイベントが登録されているので、本キーイベントによりｘｌｅｔプログラムの起動が可能になる。キーイベントがＥｖｅｎｔ Ｌｉｓｔｎｅｒ非登録のキーイベントである場合、本キーイベントをＤｅｆａｕｌｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ４０に振り分ける。ＢＤ−ＲＯＭ再生装置において生じるキーイベントには、Ｅｖｅｎｔ Ｌｉｓｔｎｅｒに登録されていない多様なものがあり、これらのキーイベントが生じたとしても、漏れの無い処理を実行するためである。
【０１２８】
Ｄｅｆａｕｌｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ４０は、ｘｌｅｔプログラム内のＥｖｅｎｔ Ｌｉｓｔｎｅｒに登録されてないキーイベントがＥｖｅｎｔ Ｌｉｓｔｎｅｒ Ｍａｎａｇｅｒ３９から振り分けられると、そのＥｖｅｎｔ Ｌｉｓｔｎｅｒ非登録イベントに対応するファンクションコールをＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に対して実行する。このＤｅｆａｕｌｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ４０によるファンクションコールを模式的に示したのが、図中の矢印◇３である。
【０１２９】
ＰＬＭＴプロセッサ４１は、アプリケーションマネージャ３６の一構成要素であり、モジュールマネージャ３４からａｃｔｉｖａｔｅ（ｂｏｂｊ＿ｉｄ）がなされれば、そのｂｏｂｊ＿ｉｄにより特定されるＢＤ−Ｊ Ｏｂｊｅｃｔのプレイリスト管理テーブルを参照する。そして再生属性＝ＡｕｔｏＰｌａｙのＰＬが、そのＢＤ−Ｊ Ｏｂｊｅｃｔのプレイリスト管理テーブル内に存在すれば、そのＡｕｔｏＰｌａｙＰＬを再生するようＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に出力する。一方、ＰＬによる再生終了を示すＮｏｔｉｆｙイベントをＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２が発行すれば、その発行された時点をＴｉｔｌｅ終了時点として解釈する。図中の△１，２は、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に対するＰｌａｙＰＬファンクションのコール（△１）、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２からのＮｏｔｉｆｙイベント出力（△２）を模式化している。
【０１３０】
以上でＢＤ−Ｊモジュール３５内のレイヤ構成についての説明を終える。尚、Ｐｅｒｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ４２については、本実施形態における説明を割愛する。Ｐｅｒｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ４２の処理内容は、本実施形態よりも第３実施形態で詳述するのが望ましいからである。
＜Ｊａｖａ（登録商標）仮想マシン３８の内部構成＞
Ｊａｖａ（登録商標）仮想マシン３８の内部構成について説明する。図３７は、Ｊａｖａ（登録商標）仮想マシン３８の内部構成を示す図である。本図に示すようにＪａｖａ（登録商標）仮想マシン３８は、図３２に示したＣＰＵ２４と、ユーザクラスローダ５２、メソッドエリア５３、ワークメモリ５４、スレッド５５ａ，ｂ・・・ｎ、Ｊａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎとから構成される。
【０１３１】
ユーザクラスローダ５２は、ＢＤＪＡディレクトリのＪａｖａ（登録商標）アーカイブファイルにおけるクラスファイルをローカルメモリ２６等から読み出してメソッドエリア５３に格納する。このユーザクラスローダ５２によるクラスファイル読み出しは、ファイルパスを指定した読み出しをアプリケーションマネージャ３６がユーザクラスローダ５２に指示することでなされる。ファイルパスがローカルメモリ２６を示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するＪａｖａ（登録商標）アーカイブファイルにおけるクラスファイルを、ローカルメモリ２６からワークメモリ５４に読み出す。ファイルパスがＶｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０上のディレクトリを示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するＪａｖａ（登録商標）アーカイブファイルにおけるクラスファイルを、ＢＤ−ＲＯＭ又はＬｏｃａｌ Ｓｔｏｒａｇｅ１８からワークメモリ５４に読み出す。図３５に示したアプリケーション起動制御（☆３，４，５）は、このユーザクラスローダ５２によるクラスファイル読み出しにより実現される。読み出しが指示されたクラスファイルがローカルメモリ２６にない場合、ユーザクラスローダ５２は読み出し失敗をアプリケーションマネージャ３６に通知することになる。
【０１３２】
メソッドエリア５３は、ユーザクラスローダ５２によりローカルメモリ２６から読み出されたクラスファイルが格納される。
ワークメモリ５４は、いわゆるヒープエリアであり、様々なクラスファイルのインスタンスが格納される。図３３に示したアプリケーションマネージャ３６、Ｅｖｅｎｔ Ｌｉｓｔｎｅｒ Ｍａｎａｇｅｒ３９は、このワークメモリ５４に常駐するレジデントアプリケーションである。ワークメモリ５４には、これらレジデント型のインスタンスの他に、メソッドエリア５３に読み出されたクラスファイルに対応するインスタンスが格納される。このインスタンスが、アプリケーションを構成するｘｌｅｔプログラムである。かかるｘｌｅｔプログラムをワークメモリ５４に配置することによりアプリケーションは実行可能な状態になる。図３３、図３５、図３６のレイアモデルでは、このワークメモリ５４をＪａｖａ（登録商標）仮想マシン３８上位層に記述していた。これはワークメモリ５４上のアプリケーションマネージャ３６及びＥｖｅｎｔ Ｌｉｓｔｎｅｒ Ｍａｎａｇｅｒ３９を、わかり易く記述するための配慮に過ぎない。アプリケーションマネージャ３６及びＥｖｅｎｔ Ｌｉｓｔｎｅｒ Ｍａｎａｇｅｒ３９はインスタンスとしてスレッド５５ａ，ｂ・・・ｎにより実行されるというのが、現実的な記述になる。
【０１３３】
スレッド５５ａ，ｂ・・・ｎは、ワークメモリ５４に格納されたメソッドを実行する論理的な実行主体であり、ローカル変数や、オペランドスタックに格納された引数をオペランドにして演算を行い、演算結果を、ローカル変数又はオペランドスタックに格納する。図中の矢印ｋｙ１，ｋｙ２，ｋｙｎは、ワークメモリ５４からスレッド５５ａ，ｂ・・・ｎへのメソッド供給を象徴的に示している。物理的な実行主体がＣＰＵ唯１つであるのに対し、論理的な実行主体たるスレッドは、最大６４個Ｊａｖａ（登録商標）仮想マシン３８内に存在し得る。この６４個という数値内において、スレッドを新規に作成することも、既存のスレッドを削除することも可能であり、スレッドの動作数は、Ｊａｖａ（登録商標）仮想マシン３８の動作中において増減し得る。スレッドの数は適宜増やすことができるので、複数スレッドにより１つのインスタンスの並列実行を行い、インスタンスの高速化を図ることもできる。本図ではＣＰＵ２４と、スレッドとの対応関係は、１対多の関係にしているが、ＣＰＵが複数ある場合、ＣＰＵとスレッドとの対応関係は多対多の関係になりうる。スレッド５５ａ，ｂ・・・ｎによるメソッド実行は、メソッドをなすバイトコードを、ＣＰＵ２４のネイティブコードに変換した上、ＣＰＵ２４に発行することでなされる。このネイティブコード変換については、本願の主眼から外れるため、説明を省く。
【０１３４】
Ｊａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎは、スレッド５５ａ，ｂ・・・ｎと１対１の比率で存在しており、プログラムカウンタ（図中のＰＣ）と、１つ以上のフレームとを内部に持つ。”プログラムカウンタ”は、インスタンスにおいて、現在どの部分が実行されているかを示す。”フレーム”はメソッドに対する１回のコールに対して割り当てられたスタック式の領域であり、その１回のコール時の引数が格納される”オペランドスタック”と、コールされたメソッドが用いる”ローカル変数スタック（図中のローカル変数）”からなる。フレームは、コールが１回なされる度にＪａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎ上に積み上げられるのだから、あるメソッドが自身を再帰的に呼び出す場合も、このフレームは、１つ積み上げられることになる。ＪＭＦプレーヤインスタンスの再生メソッドをコールする場合、又は、ＪｕｍｐＴｉｔｌｅＡＰＩのコールをコールする場合にも、これらのコールに対応するフレームがＪａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎ上に積み上げられる。そしてこれらのフレームのオペランドスタックには、再生メソッドによる再生の対象となるＭＰＬＳファイルのファイル名、又は、ＪｕｍｐＴｉｔｌｅＡＰＩのコールのジャンプ先を示すｔｉｔｌｅ＿ｉｄ等が引数として格納される。
【０１３５】
以上のように構成されたＪａｖａ（登録商標）仮想マシン３８の内部構成において、アプリケーションマネージャ３６及びその構成要素たるＰＬＭＴ Ｐｒｃｅｓｓｏｒ４１がどのような処理を行うかを、詳細に説明する。
ｂｏｂｊ＿ｉｄのＢＤ−Ｊ Ｏｂｊｅｃｔのａｃｔｉｖａｔｅを要求するイベント（ａｃｔｉｖａｔｒｅｄ［ｂｏｂｊ＿ｉｄ］）をモジュールマネージャ３４が出力すれば、ワークメモリ５４上の一インスタンスであるアプリケーションマネージャ３６は、そのｂｏｂｊ＿ｉｄを有するＢＤ−Ｊ Ｏｂｊｅｃｔを新たにカレントＢＤ−Ｊ Ｏｂｊｅｃｔにする。そしてアプリケーションマネージャ３６は、分岐元タイトルにおける実行状態と、カレントＢＤ−Ｊ Ｏｂｊｅｃｔにおけるアプリケーションの起動属性とを照合して、自動起動すべきアプリケーション（ｉ）、自動終了すべきアプリケーション（ｉｉ）を判定する。
【０１３６】
（ｉ）自動起動すべきアプリケーションの判定は、分岐前タイトルにおいて非実行状態であるが、カレントＢＤ−Ｊ ＯｂｊｅｃｔにおいてＡｕｔｏＰｌａｙ属性を有するアプリケーションのａｐｌｉ＿ｉｄ＿ｒｅｆをカレントＢＤ−Ｊ Ｏｂｊｅｃｔのアプリケーション管理テーブルから検索することでなされる。かかるａｐｌｉ＿ｉｄ＿ｒｅｆがあれば、アプリケーション［ａｐｌｉ＿ｉｄ＿ｒｅｆ］についてのＪａｖａ（登録商標）アーカイブファイルに属するクラスファイルを、メソッドエリア５３に読み出ようユーザクラスローダ５２に指示し、そのクラスファイルに対するインスタンスをワークメモリ５４上に生成させる。こうしてカレントタイトルを生存区間としているアプリケーションが実行可能な状態になる。その後、アプリケーションにおけるメソッドをスレッド５５ａ，ｂ・・・ｎに実行させることで、アプリケーションを実行させる。
【０１３７】
（ｉｉ）自動終了すべきアプリケーションの判定は、分岐元タイトルにおいて実行状態であるが、カレントタイトルにおいて生存区間を有しないアプリケーションのａｐｌｉ＿ｉｄ＿ｒｅｆをカレントＢＤ−Ｊ Ｏｂｊｅｃｔのアプリケーション管理テーブルから検索することでなされる。かかるａｐｌｉ＿ｉｄ＿ｒｅｆがあれば、かかるアプリケーションを構成するｘｌｅｔプログラムを終了させる。これにより当該アプリケーションがワークメモリ５４上で占めていた領域や、そのアプリケーションのメソッド実行のためのＪａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎにおけるフレーム等のリソースが回収されることになる。
【０１３８】
アプリケーションマネージャ３６の構成要素たるＰＬＭＴ Ｐｒｃｅｓｓｏｒ４１は、分岐元タイトルにおける再生状態と、カレントタイトルにおけるプレイリストの再生属性とを照合して、自動再生すべきプレイリスト（ｉ）、自動終了すべきプレイリスト（ｉｉ）を判定する。
（ｉ）自動再生すべきプレイリストの判定は、分岐元タイトルにおいて非再生状態であり、カレントタイトルにおいてＡｕｔｏＰｌａｙ属性に設定されているプレイリストがプレイリスト管理テーブル内に存在するか否かの検索をプレイリスト管理テーブルに対して行うことでなされる。もしあれば、再生すべきプレイリストのＰＬ＿ｉｄ＿ｒｅｆを引数としたプレイリスト再生のファンクションコールを実行する。このコールにより、引数たるＰＬ＿ｉｄ＿ｒｅｆをオペランドスタックに格納したフレームがＪａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎに生成される。そしてプレイリスト再生のファンクションコールをスレッド５５ａ，ｂ・・・ｎが実行する。このファンクションコール実行によりＰｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１はプレイリスト再生を開始する。
【０１３９】
（ｉｉ）自動終了すべきプレイリストの判定は、分岐元タイトルにおいて再生中状態であり、カレントタイトルのプレイリスト管理テーブルに記述されてないプレイリストが存在するか否かの検索をプレイリスト管理テーブルに対して行うことでなされる。もしあれば、そのプレイリストの再生停止を命じるファンクションコールを実行して、そのプレイリストの再生のためのファンクションコールに対応するフレームをＪａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎから削除する。
【０１４０】
ワークメモリ５４上でのアプリケーション終了には、４つの態様がある。図３８は、アプリケーション終了の４態様を示す図である。１つ目は、リソースが枯渇したためアプリケーションマネージャ３６によるＴｅｒｍｉｎａｔｅイベント発行によりアプリケーションが終了するとの態様（☆１）、２つ目は、他のアプリケーションが発行したＴｅｒｍｉｎａｔｅイベントを、アプリケーションマネージャ３６を介して受け付けて、終了するとの態様（☆２）、３つ目は、アプリケーション管理テーブルに記述された生存区間が終了したため、アプリケーションマネージャ３６が発行したＴｅｒｍｉｎａｔｅイベントにより終了するとの態様（☆３）、４つ目は、アプリケーションが自身の終了プロセスを起動することにより終了するとの態様である（☆４）。これらの４つの態様のうち３つものが、アプリケーションマネージャ３６によりなされているため、アプリケーションマネージャ３６は、アプリケーション動作制御の中枢を掌握することがわかる。仮に、Ｔｅｒｍｉｎａｔｅイベントの発行でもアプリケーションが終了しない場合、アプリケーションマネージャ３６は、そのアプリケーションを強制終了させて、使用しているリソースを明け渡させることができる。強権的なリソース解放を担うのも、アプリケーションマネージャ３６の１つの特徴である。
【０１４１】
以上がＢＤ−Ｊモジュール３５の構成要素である。
（フローチャートの説明）
以上のアプリケーションマネージャ３６についての説明は、その概要に触れたに過ぎない。アプリケーションマネージャ３６の処理を更に詳しく示したのが図３９、図４０のフローチャートである。以降、これらのフローチャートを参照してアプリケーションマネージャ３６の処理手順についてより詳しく説明する。
【０１４２】
図３９は、アプリケーションマネージャ３６による処理手順を示す図である。本図における処理手順は、ステップＳ１−ステップＳ２−ステップＳ３−ステップＳ４からなるメインループを有している。ステップＳ１は、ＴｉｔｌｅＪｕｍｐがなされたか否かの判定であり、もしなされればＴｉｔｌｅ切り換えを行い（ステップＳ７）、分岐先Ｔｉｔｌｅのアプリケーション管理テーブルを参照することにより、分岐元Ｔｉｔｌｅで起動中で、分岐先Ｔｉｔｌｅで非生存のアプリケーションを終了させる（ステップＳ８）。一方、分岐先Ｔｉｔｌｅのプレイリスト管理テーブルを参照することにより、分岐元Ｔｉｔｌｅで再生中で、分岐先Ｔｉｔｌｅで非生存となるＰＬの再生を停止させる（ステップＳ９）。
【０１４３】
そして、分岐元Ｔｉｔｌｅでは非再生状態、分岐先ＴｉｔｌｅにおいてＡｕｔｏＰｌａｙ属性になっているＰＬをＰＬＭＴ Ｐｒｃｅｓｓｏｒ４１に判定させる（ステップＳ１０）。もし存在すればＰＬＭＴ Ｐｒｃｅｓｓｏｒ４１はＡｕｔｏＰｌａｙＰＬを再生するようＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に指示する（ステップＳ１１）。もし存在しないなら、ＡｕｔｏＰｌａｙＰＬは再生しない。
続くステップＳ１２〜ステップＳ１８からなる一連の手順は、分岐先Ｔｉｔｌｅを生存区間とするアプリケーションの起動を実現する。この手順は、ＡｕｔｏＲｕｎアプリケーションに対して起動指示を行い（ステップＳ１４）、起動に成功すれば（ステップＳ１５でＹｅｓ）、ＡｕｔｏＰｌａｙＰＬの再生画像をクオータ（１／４）に変換する（ステップＳ１８）という手順を実現するものである。
【０１４４】
一方このステップＳ１５がＮｏであればステップＳ１４〜ステップＳ１７からなるループ処理を実行することになる。本ループ処理における制御変数は、再起動カウンタである。再起動カウンタは、アプリケーションの再起動回数を規定するカウンタである。本再起動カウンタは、ステップＳ１２においてリセットされ、ステップＳ１６において、０か否かの判定がなされる。０でない場合、ステップＳ１７において再起動カウンタはデクリメントされる。以上のステップＳ１４、ステップＳ１５、ステップＳ１６、ステップＳ１７からなるループ処理により、再起動カウンタが０でない限り、ＡｕｔｏＲｕｎアプリケーションの起動は繰り返されることになる。かかる繰り返しにより、アプリケーションの起動が保証されることになる。
【０１４５】
ステップＳ２は、メインとなるアプリケーションが実行されてない状態かどうかの判定であり、もしそうであれば、ステップＳ５の判定を行う。ステップＳ５は、アプリケーションが正常終了したかの判定である。もし異常終了していればステップＳ１９、ステップＳ２０の処理を実行する。正常終了していればステップＳ１９〜ステップＳ２０を実行せず、ステップＳ１〜ステップＳ４からなるメインループに戻る。
【０１４６】
ステップＳ１９は、ＡｕｔｏＰｌａｙＰＬの再生中であるか否かの判定であり、もし再生中なら、ＡｕｔｏＰｌａｙＰＬの再生画像をフルスクリーン化するようＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に指示する（ステップＳ２０）。その後、ステップＳ１６に移行する。ステップＳ１６への移行により、異常終了時においてもステップＳ１４〜ステップＳ１７からなるループ処理が実行されることになる。これによりステップＳ１２において設定された再起動カウンタの回数が０になるまで、アプリケーションの再起動は繰り返されることになる。
【０１４７】
ステップＳ４は、ＢＤドライブ１にＢＤ−ＲＯＭが存在しているか否かの判定であり、もしＢＤ−ＲＯＭが存在しなければ、全てのアプリケーションに対し、終了指示を発する（ステップＳ６）。
図４０は、プレイリスト管理テーブル、アプリケーション管理テーブルの具体例を示す。図４０の第１段目は、Ｔｉｔｌｅの再生映像を示し、第２段目は、Ｔｉｔｌｅの時間軸を示す。第３段目はＰＬ再生の進行、第４段目は、アプリケーション実行を示す。第４段目においてａｐｐｌｉｃａｔｉｏｎ＃１は、Ｔｉｔｌｅの開始と共に起動されており、その後、時点ｔ１において動作状態になる。一方ＰｌａｙＬｉｓｔ＃１は、Ｔｉｔｌｅの開始と共に再生が開始されている。Ｐｌａｙｌｉｓｔ＃１の再生は、Ｔｉｔｌｅの開始と同じ時点に開始されているので、第１段目の左側に示すように、Ｔｉｔｌｅの再生開始直後から、アプリケーションが動作状態になるまでのスタートアップディレイにおいて、プレイリストの再生画像ｇｊ１がフルスクリーン表示される。一方、ａｐｐｌｉｃａｔｉｏｎ＃１は、時点ｔ１で動作状態になるので、ＰＬ再生画像を子画面、アプリケーションの実行画像を親画面にした合成画像ｇｊ２が時点ｔ１において表示されることになる。アプリケーションの実行画像は、Ｓｔａｒｔボタン，ｃｏｎｔｉｎｕｅボタン，ＰＯＷＥＲインディケータを配置したゲーム用の画面であり、Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン１２に対する描画処理をＪａｖａ（登録商標）アプリケーションが実行することでなされる。Ｊａｖａ（登録商標）アプリケーションがかかる描画処理を行うには、グラフィクス描画や文字描画のためのライブラリが必要になる。以降アプリケーション実行とＰＬ再生とが同時になされる限り、親子画面の表示は継続する。
【０１４８】
その後ａｐｐｌｉｃａｔｉｏｎ＃１が異常終了してしまい、時点ｔ２においてアプリケーションマネージャ３６がこの異常終了を検知したとする。矢印ｂｒ１は、この検知を象徴的に示す。そうするとステップＳ２０においてアプリケーションマネージャ３６は、ＰＬの再生画像をフルスクリーンにする。図中の時点ｔ３は、このフルスクリーン化のタイミングを示す。図中の第１段目の右側に、フルスクリーン化で得られた画像ｇｊ３を示す。
【０１４９】
以上のように本実施形態によれば、プレイリスト管理テーブルの再生属性を、”ＡｕｔｏＰｌａｙ”に設定しておくことにより、Ｊａｖａ（登録商標）アプリケーションが動作状態になるまで５〜１０秒という時間がかかったとしても、その間、”とりあえず何かが写っている状態”になる。この”とりあえず何かが写っている状態”によりタイトル実行開始時のスタートアップディレイを補うことができる。
【０１５０】
また、アプリケーションの起動に失敗したり、アプリケーションが異常したとしても、プレイリスト管理テーブルで規定されたプレイリストの再生を継続することにより、”とりあえず何かが写っている状態”になる。これにより、装置がブラックアウトしてしまうという最悪ケースを回避することができるので、装置を製造するメーカに、最低限度の安心感を与えることができる。
【０１５１】
（第２実施形態）
第２実施形態は、エラー終了時におけるリカバリー処理を、オーサリング時に規定しておくための改良に関する。かかるリカバリー処理を規定するため、本実施形態に係る記録媒体では、１つのＢＤ−Ｊ Ｏｂｊｅｃｔ内にエラー管理テーブルを設けている。図４１（ａ）は、第２実施形態に係るＢＤ−Ｊ Ｏｂｊｅｃｔの内部構成を示す図である。本図に示すように、ＢＤ−Ｊ Ｏｂｊｅｃｔにはアプリケーション管理テーブル、プレイリスト管理テーブルの他に、エラー管理テーブル（Ｅｒｒｏｒ Ｍａａｎｇｅｍｅｎｔ Ｔａｂｌｅ［ｂｏｂｊ＿ｉｄ］）が追加されている。図４１（ｂ）は、エラー管理テーブルの内部構成を示す図である。本図に示すように、エラー管理テーブルは、Ｎｕｍｂｅｒ＿ｏｆ＿ｒｅｃｏｖｅｒｙ個のリカバリー情報（ｒｅｃｏｖｅｒｙ（））からなる。識別子ｒｅｃｏｖｅｒｙ＿ｉｄで特定される、任意のリカバリー情報の内部構成を、引き出し線ｅｍ１にてクローズアップしている。この引き出し線によるとリカバリー情報は、リカバリー情報に対応するアプリケーションの識別子を、一意に特定する参照値『Ａｐｌｉ＿ｉｄ＿ｒｅｆ』、『Ｒｅｓｔａｒｔ＿Ａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇ』、『Ｃｏｎｔｉｎｕｏｕｓ＿Ｐｌａｙｂａｃｋ＿ｆｌａｇ』、『Ｓｅｌｅｃｔ＿Ｔｉｔｌｅ＿ｆｌａｇ』、『Ｎｏｔｉｆｙ＿Ｅｖｅｎｔ＿ｆｌａｇ』、『Ｒｅｂｏｏｔ＿ｆｌａｇ』という５つのｆｌａｇからなる。図４２は、これら５つのフラグの意味内容を示す。以降エラー管理テーブルにおける各フラグの意味内容について説明する。
【０１５２】
『Ｒｅｓｔａｒｔ＿Ａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇ』は、０に設定されることにより異常終了時に再起動しないことを示す。０以外の整数値ｎに設定されることにより、再起動をｎ回繰り返すことを示す。デフォルト値として本ｆｌａｇは、０に設定されている。
『Ｃｏｎｔｉｎｕｏｕｓ＿Ｐｌａｙｂａｃｋ＿ｆｌａｇ』は、０に設定されることにより異常終了時にＰＬ再生を継続しないことを示す。整数値１に設定されることにより、異常終了時にＰＬ再生を継続することを示し、２に設定されることにより、異常終了時に、フルスクリーン・一倍速でＰＬ再生を継続することを示す。デフォルト値として本ｆｌａｇは、０に設定されている。
【０１５３】
『Ｓｅｌｅｃｔ＿Ｔｉｔｌｅ＿ｆｌａｇ』は、０に設定されることにより異常終了時にＴｉｔｌｅ分岐を行わないことを示す。０以外の整数値ｎに設定された場合、Ｔｉｔｌｅ番号ｎにより特定されるＴｉｔｌｅにＪｕｍｐすることを示す。デフォルト値として本ｆｌａｇは、０に設定されている。
『Ｎｏｔｉｆｙ＿Ｅｖｅｎｔ＿ｆｌａｇ』は、０に設定されることにより異常終了時に、イベントを出力しないことを示す。０以外の整数値ｎに設定された場合、イベント番号ｎのイベントを出力することを示す。デフォルト値として本ｆｌａｇは、１に設定されている。
【０１５４】
『Ｒｅｂｏｏｔ＿ｆｌａｇ』は、０に設定されることにより異常終了時に、再生装置のブートストラップを行わないことを示す。整数値１に設定された場合、ブートストラップを行うことを示す。
以上のｆｌａｇが存在するので、アプリケーションが異常終了した際、どのようなリカバリ処理を実行するかをオーサリング時に予め規定しておくことができる。エラー管理テーブル記述の具体例について説明する。図４３（ａ）は、エラー管理テーブルが記述された２つのＴｉｔｌｅ（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２）を示す図である。ｔｉｔｌｅ＃１のアプリケーション管理テーブルには、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃１が記述されており、ｔｉｔｌｅ＃１のエラー管理テーブルにはこのａｐｐｌｉｃａｔｉｏｎ＃１が異常終了した際に用いられるべきＲｅｃｏｖｅｒｙ情報が記述されている。ｔｉｔｌｅ＃１のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃１が記述されている。
【０１５５】
ｔｉｔｌｅ＃２側のアプリケーション管理テーブルにはＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２が記述されており、ｔｉｔｌｅ＃２側のエラー管理テーブルには、このａｐｐｌｉｃａｔｉｏｎ＃２に対するＲｅｃｏｖｅｒｙ情報が記述されている。
図４３（ｂ）は、図４３（ａ）のように記載されたアプリケーション管理テーブル、エラー管理テーブルに基づくアプリケーション実行及びプレイリスト再生の進行を示す。ａｐｐｌｉｃａｔｉｏｎ＃１についてのＲｅｃｏｖｅｒｙ情報は、Ｃｏｎｔｉｎｕｏｕｓ＿Ｐｌａｙｂａｃｋ＿Ｆｌａｇ＝２と記述されているため、ａｐｐｌｉｃａｔｉｏｎ＃１の異常終了時にはプレイリスト再生が一倍速、フルスクリーンにより継続することになる。
【０１５６】
一方ａｐｐｌｉｃａｔｉｏｎ＃２についてのＲｅｃｏｖｅｒｙ情報は、Ｎｏｔｉｆｙ＿Ｅｖｅｎｔ＿Ｆｌａｇ＝２と記述されているので、ａｐｐｌｉｃａｔｉｏｎ＃２の異常終了には、番号＝２のイベントを出力することになる。
以上のようなＲｅｃｏｖｅｒｙ情報の記述により、アプリケーションが異常終了した際の処理を、Ｔｉｔｌｅ毎、アプリケーション毎に変化させることができる。
ＢＤ−Ｊ Ｏｂｊｅｃｔにおいて上述したエラー管理テーブルが追加されたため、本実施形態に係るアプリケーションマネージャ３６は図４４、図４５のフローチャートに従って処理を行う。図４４は、第２実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。本フローは、図３９同様、ステップＳ１〜ステップＳ４をメインループにしている。このメインアプリにおいてタイトルが選択された際の処理は、ステップＳ２１〜ステップＳ２７に示されるものとなる。
【０１５７】
ステップＳ２１では、分岐先Ｔｉｔｌｅにプレイリスト管理テーブルが存在するか否かの判定をＰＬＭＴ Ｐｒｃｅｓｓｏｒ４１に行わせる。もし存在すれば、分岐元Ｔｉｔｌｅにおいて非再生状態だが、分岐先ＴｉｔｌｅにおいてＡｕｔｏＰｌａｙ属性になっているＰＬの再生をＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に開始させて（ステップＳ２２）、その再生が成功したかどうかを判定する（ステップＳ２３）。もし成功すればステップＳ２５〜ステップＳ２８の処理を行う。成功しなければ図４５のフローチャートに移行する。
【０１５８】
分岐先Ｔｉｔｌｅにプレイリスト管理テーブルがない場合は、分岐元Ｔｉｔｌｅにおいて再生状態であったＰＬの再生をＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に停止させて（ステップＳ２４）、ステップＳ２５〜ステップＳ２８の処理を行う。
ステップＳ２５は、分岐先Ｔｉｔｌｅにアプリケーション管理テーブルが存在するか否かの判定である。もし存在すれば、分岐先アプリケーションにおけるＡｕｔｏＲｕｎアプリケーションを起動して（ステップＳ２６）、ステップＳ２７において起動に成功したか否かを判定する。成功すればステップＳ１〜ステップＳ４のループ処理に戻る。成功しなければ図４５のフローチャートに移行する。
【０１５９】
図４５のフローチャートは、アプリケーションが異常終了した場合の処理手順を示すフローチャートである。ステップＳ３０は、異常終了したアプリケーションが属するＴｉｔｌｅに、エラー管理テーブルが存在するか否かの判定であり、もし存在しなければステップＳ１〜ステップＳ４からなるループ処理に戻る。
存在すれば、ステップＳ３１〜ステップＳ４４の処理を経た上でステップＳ１〜ステップＳ４からなるループ処理に戻る。ステップＳ３１は、エラー管理テーブルにおけるＲｅｓｔａｒｔ＿Ａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇが０でないかの判定である。０でなければ、ステップＳ４０〜ステップＳ４４からなるループ処理を実行する。このループ処理は、 Ｒｅｓｔａｒｔ＿Ａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇの値ｎを再起動カウンタに設定して（ステップＳ４０）、ステップＳ４１〜ステップＳ４４のループ処理を実行するというものである。このループ処理の制御変数は再起動カウンタであり、この再起動カウンタが０になること（ステップＳ４１でＹｅｓ）、及び、アプリケーションの起動に成功したこと（ステップＳ４４でＹｅｓ）が本ループ処理の終了条件である。本ループ処理では、これらのステップＳ４１、ステップＳ４４がＮｏである限り、再起動カウンタをデクリメントして（ステップＳ４２）、ＡｕｔｏＲｕｎアプリケーションを起動するという（ステップＳ４３）を繰り返す。こうした繰り返しにより異常終了において、アプリケーションの再起動がなされるのである。Ｒｅｓｔａｒｔ＿Ａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇが０であれば、ステップＳ３２を実行する。
【０１６０】
ステップＳ３２は、Ｃｏｎｔｉｎｕｏｕｓ＿Ｐｌａｙｂａｃｋ＿ｆｌａｇが０であるか、１であるか、２であるかを判定するステップである。もし２であれば、ＡｕｔｏＰｌａｙＰＬの再生画像をフルスクリーン表示にして（ステップＳ３３）、ステップＳ１〜ステップＳ４からなるメインループに戻る。
もし１であれば、ＡｕｔｏＰｌａｙＰＬの再生画像をクオータ表示にしたまま（ステップＳ３４）、ステップＳ１〜ステップＳ４からなるメインループに戻る。
【０１６１】
もし０であれば、ステップＳ３５に移行する。
ステップＳ３５は、エラー管理テーブルのｓｅｌｅｖｔ＿ｔｉｔｌｅ＿ｆｌａｇが０でないか否かの判定であり、もし０であるならステップＳ３７に移行する。０でないなら、ｓｅｌｅｖｔ＿ｔｉｔｌｅ＿ｆｌａｇの値ｎを分岐先Ｔｉｔｌｅにして（ステップＳ３６）、図４４のステップＳ７に移行する。
ステップＳ３７は、エラー管理テーブルのＮｏｔｉｆｙ＿Ｅｖｅｎｔ＿ｆｌａｇが０でないか否かの判定であり、もし０であるならステップＳ３９に移行する。０でないなら、Ｎｏｔｉｆｙ＿Ｅｖｅｎｔ＿ｆｌａｇの値ｎから特定されるイベントｎを発生して（ステップＳ３８）、図４４のステップＳ１〜ステップＳ４のメインループに移行する。ステップＳ３９は、エラー管理テーブルのＢｏｏｔ＿ｆｌａｇが０でないか否かの判定であり、もし０であるならステップＳ１〜ステップＳ４からなるメインループに移行する。０でないなら、図４４の先頭に移行して、再生装置のブートストラップを実行する。
【０１６２】
以上のように本実施形態によれば、アプリケーションがエラー終了した際、再生装置はどのような処置をとるべきかを、装置側の製造者ではなく、オーサリング担当者が規定しておくことができる。
尚、エラー管理テーブルをもたないタイトルの再生時においてアプリケーションの異常終了が発生した場合に、リカバリー処理を行うようなプログラムを再生装置に組み込んでいてもよい。
【０１６３】
またＲｅｓｔａｒｔ＿Ａｐｐｌｉｃａｔｉｏｎ＿Ｆｌａｇ〜Ｒｂｏｏｔ＿Ｆｌａｇのどれかを指定するような引数をＴｉｔｌｅＪｕｍｐＡＰＩに設けておき、この引数に応じたリカバリー処理をアプリケーションマネージャ３６に実行させてもよい。
（第３実施形態）
第１実施形態においてＪａｖａ（登録商標）仮想マシンにおけるＰＬ再生は、ＢＤ−Ｊ Ｏｂｊｅｃｔ内のプレイリスト管理テーブルを用いて規定することができた。これに対し本実施形態では、アプリケーションのＪＭＦメソッドによるＰＬ再生を主眼としている。ここで問題になるのがプレイリスト管理テーブルである。つまりＰＬを再生してよいか否かは、ＢＤ−Ｊ Ｏｂｊｅｃｔ毎のプレイリスト管理テーブルに記述されているから、あるＴｉｔｌｅでは再生可能であるが、別のＴｉｔｌｅでは再生不可能になることがある。またＰＬ再生は可能であったとしても、著作権保護の観点から、ある種のアプリケーションからの再生を禁じたい場合がある。かかるＰＬ再生の制限を実現するため、第３実施形態では、Ｐｅｒｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ４２、アプリケーションマネージャ３６が以下の処理を行う。
【０１６４】
パーミッションコントローラ４２は、どれかのアプリケーションがＰＬ再生を要求した場合、そのアプリケーションと相互認証を行い、要求元アプリケーションにＰＬの再生権限があるかどうかを判定する。もしあれば、当該再生をＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に要求し、なければ不許可を示す応答イベントを要求元アプリケーションに出力する。このＰｅｒｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ４２による許否判定により、ある配給会社の配給にかかるＰＬを、別の配給会社の配給にかかるアプリケーションが要求したとしても、かかる要求を不許可にすることができる。そのため、正当権限なきアプリケーションによるＰＬの無断引用を避けることができる。許可とすべきＰＬとアプリケーションとの組合せ、不許可とすべきＰＬとアプリケーションとの組合せは、別途ＢＤ−ＲＯＭに記録されたＰｅｒｍｉｓｓｉｏｎファイルに規定されており、Ｐｅｒｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ４２による判定はこれに基づく。かかるファイルの詳細は本願の主眼ではないので説明を省略する。
【０１６５】
第３実施形態においてアプリケーションマネージャ３６は、現在の再生時点において再生可能なＰＬを、アプリケーションからの要求に応じて通知する。図４６は、このアプリケーションマネージャ３６による通知処理の処理手順を示すフローチャートである。本フローチャートでは、アプリケーションの起動中において、再生可能なＰＬの通知を求める要求（ＧｅｔＰＬ）をアプリケーションが発行したか否かの監視を行っている（ステップＳ４５）。もし発行されれば、現在の再生時点が属しているＴｉｔｌｅを構成するＢＤ−Ｊ Ｏｂｊｅｃｔに、プレイリスト管理テーブルが存在するか否かを判定する（ステップＳ４６）。ＰＬの記述があれば、プレイリスト管理テーブルに記述されたＰＬを再生可能なＰＬとして要求元のアプリケーションに通知する（ステップＳ４７）。
【０１６６】
ＰＬの記述がなければ、ＰＬ再生が不可能な旨を発行元アプリケーションに通知する（ステップＳ４８）。以上が第３実施形態に係るアプリケーションマネージャ３６の処理手順である。
続いてＰＬ再生が要求された場合のアプリケーションマネージャ３６の処理について説明する。第３実施形態に係るアプリケーションマネージャ３６は、図４７のフローチャートに従って処理を行う。
【０１６７】
図４７においてアプリケーションマネージャ３６は、ＰＬ再生を要求したアプリケーションが存在するか否かの判定を行っている（ステップＳ５１）。どれかのアプリケーションがＰＬ再生を要求すれば、要求元アプリケーションにＰＬ再生の権利が存在するか否かの認証をＰｅｒｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ４２に行わさせる（ステップＳ５２）。もし再生する権利があれば、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に再生開始を指示して（ステップＳ５３）、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２からのサクセス応答を待つ（ステップＳ５４）。
【０１６８】
かかる再生要求があるとＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２は、プレイリスト情報の正当性をチェックする。かかる正当性チェックには、プレイリスト情報、Ｃｌｉｐ情報、ＡＶＣｌｉｐが存在するＢＤ−ＲＯＭ及びＬｏｃａｌ Ｓｔｏｒａｇｅ１８において、正当なプレイリストを構成しているかというチェックやプレイリスト情報におけるｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅにより指定されるＣｌｉｐ情報及びＡＶＣｌｉｐがＢＤ−ＲＯＭ及びＬｏｃａｌ Ｓｔｏｒａｇｅ１８に現存するか否かというチェックがある。ｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅにより正しいファイルが参照されていない場合、又は、ＢＤ−ＲＯＭ及びＬｏｃａｌ Ｓｔｏｒａｇｅ１８から構成される仮想的なパッケージに矛盾があり、正しプレイリストを構成することができない場合、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２はｆａｌｓｅを示す応答を返すことになる。また要求元アプリケーションより、高い起動優先度をもつアプリケーションがそのＰＬを再生しており、ＰＬ再生を実現するリソースにおいて競合が生じている場合最もＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２は、ｆａｌｓｅを示す応答を返す。
【０１６９】
以上の過程を経てサクセス応答があれば、ＰＬ再生成功を示すイベントを要求元アプリケーションに出力する（ステップＳ５５）。
サクセス応答がなければ、ＰＬ再生失敗を示すイベントを要求元アプリケーションに出力する（ステップＳ５６）。一方、ステップＳ５２において要求元アプリケーションを再生する権利が要求元アプリケーションになければ、ＰＬ再生不可を示すイベントを要求元アプリケーションに出力する（ステップＳ５７）。
【０１７０】
以上のように本実施形態によれば、プレイリスト再生可否が各Ｔｉｔｌｅ毎でバラバラであり、プレイリスト再生の権限をもったアプリケーションやそうでないアプリケーション等様々なアプリケーションがあったとしても、適切なプレイリスト再生を、アプリケーションからの要求に応じて実行することができる。そのため、アプリケーション実行と、プレイリスト再生とを組み合わせた、多彩なコンテンツ表現が可能になる。
【０１７１】
（第４実施形態）
第１実施形態では、Ｔｉｔｌｅ開始時において、再生を開始したいプレイリストにＡｕｔｏＰｌａｙを示す再生属性を付与して、ＡｕｔｏＰｌａｙＰＬの再生を再生装置に命じていた。これに対し本実施形態では、アンバウンダリーアプリケーションをＢＤ−ＲＯＭに記録しておき、Ｔｉｔｌｅ開始時にあたって、自動的に再生を開始すべきＴｉｔｌｅをアンバウンダリーアプリケーションに選択させる改良に関する。
【０１７２】
アンバウンダリーアプリケーションは、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２のような、再生装置におけるレジデントアプリケーションと対等な立場にあるアプリケーションであり、プレイリスト管理テーブルに記述されている複数プレイリスト情報の中から再生装置側のＰＳＲ設定値に合致するものを選び、通知するとの処理をＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２からの要求に応じて実行する。
【０１７３】
ＰＬ選択をアンバウンダリーアプリケーションに行わせる場合、かかる選択が必要なＴｉｔｌｅにあたっては、プレイリスト管理テーブルにおける再生属性を、全て無指定に設定しておく。これは、”全てが無指定”であることを合図に、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２にＰＬ選択をタイトルアンバウンダリーアプリケーションに要求させるためである。
このアンバウンダリーアプリケーションによる選択は、オーサリング時に規定された選択アルゴリズムに基づく。図４８（ａ）〜（ｃ）は、アンバウンダリーアプリケーションに組み込まれた選択アルゴリズムの内容を表形式に示す図である。この表は、ＰＳＲの値が取り得る値の範囲と、ＰＳＲがそれらの値になった際、再生すべきＰＬとを対応付けて示している。このうち図４８（ａ）は、パレンタルレベルに基づく選択アルゴリズムの内容を示す。ここでパレンタルレベルは、再生装置においてＰＳＲ（１４）に示されている。具体的にいうと、ＰＳＲ（１４）には、ユーザの年齢を示す整数値が設定されており、これを再生装置はパレンタルレベルとして解釈する。図４８（ａ）において、ＰＳＲ（１４）がとりうる値は、１４歳未満、１４歳以上１８歳未満、１８歳以上という３つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきＰＬが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムによる選択を行えば、ＰＳＲの設定値が１４歳未満ならＰｌａｙＬｉｓｔ＃１が、１４以上１８歳未満ならＰｌａｙＬｉｓｔ＃２が、１８歳以上ならＰｌａｙＬｉｓｔ＃３がそれぞれ選択されることになる。
【０１７４】
図４８（ｂ）は、Ｌａｎｇｕｅｇｅ ｆｏｒ Ａｕｄｉｏに基づく選択アルゴリズムの内容を示す。ここでＬａｎｇｕｅｇｅ ｆｏｒ Ａｕｄｉｏは、再生装置においてＰＳＲ（１６）に示されている。具体的にいうと、ＰＳＲ（１６）には、整数値が設定されており、これを再生装置は音声再生用の言語設定として解釈する。図４８（ｂ）において、ＰＳＲ（１６）がとりうる値は、英語を示す値、日本語を示す値、その他の値という３つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきＰＬが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムによる選択を行えば、ＰＳＲ（１６）の設定値が英語を示すならＰｌａｙＬｉｓｔ＃１が、日本語を示すならＰｌａｙＬｉｓｔ＃２が、英語、日本語以外の値ならＰｌａｙＬｉｓｔ＃３がそれぞれ選択されることになる。
【０１７５】
図４８（ｃ）は、Ｐｌａｙｅｒ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ｆｏｒ Ｖｉｄｅｏに基づく選択アルゴリズムの内容を示す。ここでＰｌａｙｅｒ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ｆｏｒ Ｖｉｄｅｏは、再生装置においてＰＳＲ（１４）に示されている。具体的にいうと、ＰＳＲ（１４）には、整数値が設定されており、これを再生装置は映像再生用の環境設定として解釈する。図４８（ｃ）において、ＰＳＲ（１４）がとりうる値は、解像度５２５×６００ ＴＶｓｙｓｔｅｍ ＬｅｔｔｅｒＢｏｘ解像度５２５×６００ ＴＶｓｙｓｔｅｍ、１９２０×１０８０ ＴＶｓｙｓｔｅｍという３つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきＰＬが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムに従って選択を行えば、ＰＳＲ（１４）の設定値が解像度５２５×６００ ＴＶｓｙｓｔｅｍ ＬｅｔｔｅｒＢｏｘを示すものならＰｌａｙＬｉｓｔ＃１が、解像度５２５×６００を示すものならＰｌａｙＬｉｓｔ＃２が、ＴＶｓｙｓｔｅｍ、１９２０×１０８０ ＴＶｓｙｓｔｅｍを示すものならＰｌａｙＬｉｓｔ＃３がそれぞれ選択されることになる。図４８（ａ）〜（ｃ）に示したような選択アルゴリズムは、これらの図に示される条件分岐を、コンピュータ記述言語で記述することにより作成することができる。
【０１７６】
以上が本実施形態に係る記録媒体の改良である。続いて本実施形態に係る再生装置の改良について説明する。本実施形態での改良点は。主としてアプリケーションマネージャ３６、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２にある。
アプリケーションマネージャ３６は、Ｔｉｔｌｅの分岐が生じ、プレイリスト管理テーブルを参照した際、そのプレイリスト管理テーブルにＡｕｔｏＰｌａｙＰＬが存在するか否かを判定する。ＡｕｔｏＰｌａｙＰＬが無ければ、プレイリスト管理テーブルをＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に引き渡して、このプレイリスト管理テーブルに記載されているＰＬのうち、どれかを自動的に再生するようＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に要求する。
【０１７７】
Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２は、プレイリスト管理テーブルの引き渡しを受ければ、アンバウンダリーアプリケーションに対し、ＰＬ選択を行うよう要求する。この要求に応じてアンバウンダリーアプリケーションから再生可能なＰＬのリストが通知されれば、そのＰＬリストに記載されたＰＬのうち、ＰｌａｙＩｔｅｍから引き渡されたプレイリスト管理テーブルに存在するものを判定する。アンバウンダリーアプリケーションにより選択されたＰＬの中に、プレイリスト管理テーブルに記載されたものがあれば、それの再生を自動的に開始する。
【０１７８】
図４９は、タイトルアンバウンダリーアプリケーションにＰＬ選択を行わせる過程を模式的に描いた図である。本図の左側は再生装置におけるソフトウェアのレイヤ構成を示し、本図の右側に、ＢＤ−ＲＯＭの記録内容を示す。図中の◎１，２，３，４は、ＡｕｔｏＰｌａｙがないプレイリスト管理テーブルを発見した場合の、アプリケーションマネージャ３６からの通知（◎１）、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２による再生可能ＰＬの問合せ（◎２）、タイトルアンバウンダリーアプリケーションによるＰＳＲ設定値取得（◎３）、タイトルアンバウンダリーアプリケーションからＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２への再生可能なＰＬの通知（◎４）を模式的に描いている。
【０１７９】
尚、図４９においてタイトルアンバウンダリーアプリケーションは、ＢＤ−ＲＯＭ上に記述していたが、これはタイトルアンバウンダリーアプリケーションを、わかり易く記述するための配慮に過ぎない。タイトルアンバウンダリーアプリケーションは、Ｊａｖａ（登録商標）アプリケーションであるので、Ｊａｖａ（登録商標）仮想マシン３８内のワークメモリ５４においてインスタンスとしてスレッド５５により実行されるというのが、現実的な記述になる。
【０１８０】
以上のように本実施形態によれば、Ｔｉｔｌｅのバウンダリで生存しているようなアプリケーションに、上述したような判定を行わせるので、再生装置側のＰｌａｙｂａｃｋＣｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２は、ＢＤ−ＲＯＭにおける複数ＰＬのうち、再生装置側の状態設定に応じたものはどれであるかを、Ｔｉｔｌｅ開始時の早い段階で知得することができる。再生属性＝ＡｕｔｏＰｌａｙのアプリケーションを決めておかなくても、Ｔｉｔｌｅ開始時に再生を開始すべきＰＬを決定することができるので、ラングエージクレジットやパレンタルロックといった再生制御をＢＤ−Ｊモードにおいても実現することができる。
【０１８１】
尚、本実施形態における選択アルゴリズムは、ＰＳＲがとり得る値をプレイリストに対応づけたが、再生装置におけるＰＳＲの設定値が、想定外の値であった場合に、再生装置に再生させるプレイリストを予め規定しておいてもよい。
（第５実施形態）
第４実施形態においてタイトルアンバウンダリーアプリケーションは、ＰＳＲの設定値に応じて再生すべきＰＬを選択するという選択アルゴリズムを有していたが、本実施形態に係るタイトルアンバウンダリーアプリケーションは、１つのＰＬ内にマルチアングル区間がある場合、当該マルチアングル区間における複数アングルのどれかを選ぶとの処理を、タイトルアンバウンダリーアプリケーションに行わせる改良に関する。本実施形態に係るタイトルアンバウンダリーアプリケーションは、ＰＳＲがとりうる値の複数の範囲と、それら範囲毎に再生すべきアングルとを対応づけたものである。本実施形態において現在の再生時点がマルチアングル区間であるとＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２はタイトルアンバウンダリーアプリケーションに対し、何れのアングルを再生するかの問い合わせを行う。かかる問い合わせがあれば、タイトルアンバウンダリーアプリケーションは現在におけるＰＳＲ設定値を取得し、選択アルゴリズムを実行して、取得した設定値に応じたアングルを選択する。その選択結果をＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に通知してそのアングルの再生をＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に行わせる。
【０１８２】
以上のように本実施形態によれば、ＰＳＲがどの値であるとき、どのアングルを選択するというアルゴリズムを、オーサリング担当者が規定しておくことができるので、アングルを応用した様々なアプリケーションをオーサリング担当者は作り出すことができる。
（第６実施形態）
ＢＤ−Ｊモードにおいて、ＰＬ再生との同期をどのように実現するかという改良に関する。Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２は、ＰｌａｙＰＬＡＰＩファンクションがコールされれば、ＰＬ情報に基づく処理手順を実行する。ＰＬが２時間という再生時間を有するなら、この２時間の間、上述した処理は継続することになる。ここで問題になるのは、Ｊａｖａ（登録商標）仮想マシン３８がサクセス応答を返す時間と、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２が実際に処理を終える時間とのギャップである。Ｊａｖａ（登録商標）仮想マシン３８は、イベントドリブンの処理主体であるためコール直後に再生成功か、再生失敗かを示す応答を返すが、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２による実際の処理終了は２時間経過後であるので、サクセス応答をアプリケーションに返す時間を基準にしたのでは、２時間経過後にあたる処理終結を感知しえない。ＰＬ再生において早送り、巻戻し、Ｓｋｉｐが行われると、この２時間という再生期間は２時間前後に変動することになり、処理終結の感知は更に困難になる。
【０１８３】
Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２は、アプリケーションとスタンドアローンで動作するため、アプリケーションマネージャ３６は、ＰＬ再生の終了時点を正確に解釈することができない。そこで本実施形態では、アプリケーションが終了してようがいまいが、ワークメモリにＪＭＦプレーヤインスタンスがある限り、つまり、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１の制御権をＢＤ−Ｊモジュール３５が掌握している間、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２からＮｏｔｉｆｙイベントを待つ。そしてＮｏｔｉｆｙイベントがあれば、タイトルが終了したと解釈して、次のタイトルへの分岐を行うようモジュールマネージャ３４に通知する。こうすることにより、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２がＰＬ再生を終結した時点を、タイトルの終端とすることができる。
【０１８４】
以降図５０〜図５４のフローチャートを参照して、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２による具体的な制御手順を説明する。
図５０は、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２によるＰＬ再生手順を示すフローチャートである。この再生手順は、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１に対する制御（ステップＳ１０６）と、ＢＤ−ＲＯＭドライブ１又はＬｏｃａｌ Ｓｔｏｒａｇｅ１８に対する制御（ステップＳ１０８）とを主に含む。本フローチャートにおいて処理対象たるＰｌａｙＩｔｅｍをＰｌａｙＩｔｅｍ＃ｘとする。本フローチャートは、カレントＰＬ情報（．ｍｐｌｓ）の読み込みを行い（ステップＳ１０１）、その後、ステップＳ１０２〜ステップＳ１１０の処理を実行するというものである。ここでステップＳ１０２〜ステップＳ１１０は、ステップＳ１０９がＹｅｓになるまで、カレントＰＬ情報を構成するそれぞれのＰＩ情報について、ステップＳ１０３〜ステップＳ１１０の処理を繰り返すというループ処理を構成している。このループ処理において処理対象となるＰｌａｙＩｔｅｍを、ＰｌａｙＩｔｅｍ＃ｘ（ＰＩ＃ｘ）とよぶ。このＰｌａｙＩｔｅｍ＃ｘは、カレントＰＬの先頭のＰｌａｙＩｔｅｍに設定されることにより、初期化される（ステップＳ１０２）。上述したループ処理の終了要件は、このＰｌａｙＩｔｅｍ＃ｘがカレントＰＬの最後のＰｌａｙＩｔｅｍになることであり（ステップＳ１０９）、もし最後のＰｌａｙＩｔｅｍでなければ、カレントＰＬにおける次のＰｌａｙＩｔｅｍがＰｌａｙＩｔｅｍ＃ｘに設定される（ステップＳ１１０）。
【０１８５】
ループ処理において繰り返し実行されるステップＳ１０３〜ステップＳ１１０は、ＰｌａｙＩｔｅｍ＃ｘのＣｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されるＣｌｉｐ情報をシナリオメモリ２５に読み込み（ステップＳ１０３）、ＰｌａｙＩｔｅｍ＃ｘのＩｎ＿ｔｉｍｅを、カレントＣｌｉｐ情報のＥＰｍａｐを用いて、Ｉピクチャアドレスｕに変換し（ステップＳ１０４）、ＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅを、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて、Ｉピクチャアドレスｖに変換して（ステップＳ１０５）、これらの変換で得られたアドレスｖの次のＩピクチャを求めて、そのアドレスの１つ手前をアドレスｗに設定し（ステップＳ１０７）、そうして算出されたアドレスｗを用いて、ＩピクチャアドレスｕからアドレスｗまでのＴＳパケットの読み出しをＢＤ−ＲＯＭドライブ１又はＬｏｃａｌ Ｓｔｏｒａｇｅ１８に命じるというものである（ステップＳ１０８）。
【０１８６】
一方、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１に対しては、カレントＰＬＭａｒｋのｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐからＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅまでの出力を命じる（ステップＳ１０６）。以上のステップＳ１０５〜ステップＳ１０８により、ＡＶＣｌｉｐにおいて、ＰｌａｙＩｔｅｍ＃ｘにより指示されている部分の再生がなされることになる
その後、ＰｌａｙＩｔｅｍ＃ｘがカレントＰＬの最後のＰＩであるかの判定がなされる（ステップＳ１０９）。
【０１８７】
ＰｌａｙＩｔｅｍ＃ｘがカレントＰＬの最後のＰＩでなければ、カレントＰＬにおける次のＰｌａｙＩｔｅｍを、ＰｌａｙＩｔｅｍ＃ｘに設定して（ステップＳ１１０）、ステップＳ１０３に戻る。以上のステップＳ１０３〜ステップＳ１１０を繰り返することにより、ＰＬを構成するＰＩは順次再生されることになる。
図５１は、アングル切り換え手順及びＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔの手順を示すフローチャートである。本フローチャートは、図５０の処理手順と並行してなされるものであり、ステップＳ１１１〜Ｓ１１２からなるループ処理を繰り返すというものである。本ループにおけるステップＳ１１１は、アングル切り換えを要求するＡＰＩが、Ｊａｖａ（登録商標）仮想マシン３８からコールされたか否かの判定であり、アングル切り換えＡＰＩのコールがあれば、カレントＣｌｉｐ情報を切り換えるという操作を実行する。
【０１８８】
図５１のステップＳ１１５は、判定ステップであり、ＰｌａｙＩｔｅｍ＃ｘのｉｓ＿ｍｕｌｔｉ＿ａｎｇｌｅｓがオンであるか否かの判定を行う。ｉｓ＿ｍｕｌｔｉ＿ａｎｇｌｅｓとは、ＰｌａｙＩｔｅｍ＃ｘがマルチアングルに対応しているか否かを示すフラグであり、もしステップＳ１１５がＮｏであるならステップＳ１１３に移行する。ステップＳ１１５がＹｅｓであるなら、ステップＳ１１６〜ステップＳ１１９を実行する。ステップＳ１１６〜ステップＳ１１９は、切り換え後のアングル番号を変数ｙに代入して（ステップＳ１１６）、ＰｌａｙＩｔｅｍ＃ｘにおけるｙ番目のＣｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されているＣｌｉｐ情報をシナリオメモリ２１に読み出し（ステップＳ１１７）、カレントＰＴＭを、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いてＩピクチャアドレスｕに変換し（ステップＳ１１８）、ＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅを、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いてＩピクチャアドレスｖに変換する（ステップＳ１１９）というものである。こうしてＩピクチャアドレスｕ，ｖを変化した後、同時実行されている図５０側の処理を停止させた上でステップＳ１０６に移行する。ステップＳ１０６への移行により、別のＡＶＣｌｉｐからＴＳパケットが読み出されるので、映像内容が切り換わることになる。
【０１８９】
一方、図５１のループにおけるステップＳ１１２は、ＳｋｉｐＢａｃｋ／ＳｋｉｐＮｅｘｔを意味するＡＰＩがＪａｖａ（登録商標）仮想マシン３８からコールされたか否かの判定であり、もしコールされれば、図５２のフローチャートの処理手順を実行する。図５２は、ＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔＡＰＩがコールされた際の処理手順を示すフローチャートである。ＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔを実行するにあたっての処理手順は多種多様なものである。ここで説明するのはあくまでも一例に過ぎないことに留意されたい。
【０１９０】
ステップＳ１２１は、ＰＳＲで示されるカレントＰＩ番号、及び、カレントＰＴＭを変換することにより、カレントＭａｒｋ情報を得る。ステップＳ１２２は、押下されたのがＳｋｉｐＮｅｘｔキーであるか、ＳｋｉｐＢａｃｋキーであるかの判定であり、ＳｋｉｐＮｅｘｔキーであるならステップＳ１２３において方向フラグを＋１に設定し、ＳｋｉｐＢａｃｋキーであるならステップＳ１２４において方向フラグを−１に設定する。
【０１９１】
ステップＳ１２５は、カレントＰＬＭａｒｋの番号に方向フラグの値を足した番号を、カレントＰＬＭａｒｋの番号として設定する。ここでＳｋｉｐＮｅｘｔキーであるなら方向フラグは＋１に設定されているのでカレントＰＬＭａｒｋはインクリメントされることになる。ＳｋｉｐＢａｃｋキーであるなら方向フラグは−１に設定されているので、カレントＰＬＭａｒｋはデクリメントされることになる。
【０１９２】
ステップＳ１２６では、カレントＰＬＭａｒｋのｒｅｆ＿ｔｏ＿ＰｌａｙＩｔｅｍ＿Ｉｄに記述されているＰＩを、ＰｌａｙＩｔｅｍ＃ｘに設定し、ステップＳ１２７では、ＰｌａｙＩｔｅｍ＃ｘのＣｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されるＣｌｉｐ情報を読み込む。ステップＳ１２８では、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて、カレントＰＬＭａｒｋのｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐを、Ｉピクチャアドレスｕに変換する。一方ステップＳ１２９では、ＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅを，カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて，Ｉピクチャアドレスｖに変換する。ステップＳ１３０は、カレントＰＬＭａｒｋのｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐからＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅまでの出力をＰｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１に命じて、同時実行されている図５０側の処理を停止させた上で、図５０のステップＳ１０７に移行する。こうしてＩピクチャアドレスｕ，ｖを変化して、別の部分の再生を命じた上でステップＳ１０７への移行するので、別のＡＶＣｌｉｐからＴＳパケットが読み出されることになり、映像内容が切り換えが実現する。
【０１９３】
図５３は、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１による処理手順の詳細を示すフローチャートである。本フローチャートは、ＩピクチャのＰＴＳをカレントＰＴＭに設定した後で（ステップＳ１３１）、ステップＳ１３２〜ステップＳ１３７からなるループ処理を実行するものである。
続いてステップＳ１３２〜ステップＳ１３７におけるループ処理について説明する。このループ処理は、カレントＰＴＭにあたるピクチャ、オーディオの再生出力と、カレントＰＴＭの更新とを繰り返すものである。本ループ処理におけるステップＳ１３６は、ループ処理の終了要件を規定している。つまりステップＳ１３６は、カレントＰＴＭがＰＩ＃ｘのＯｕｔ＿ｔｉｍｅであることをループ処理の終了要件にしている。
【０１９４】
ステップＳ１３３は、早送りＡＰＩ、又は、早戻しＡＰＩがＪａｖａ（登録商標）仮想マシン３８からコールされたか否かの判定である。もしコールされれば、ステップＳ１３８において早送りか早戻しかの判定を行い、早送りであるなら、次のＩピクチャのＰＴＳをカレントＰＴＭに設定する（ステップＳ１３９）。このようにカレントＰＴＭを、次のＩピクチャのＰＴＳに設定することで、１秒飛びにＡＶＣｌｉｐを再生してゆくことができる。これにより、２倍速等でＡＶＣｌｉｐは順方向に早く再生されることになる。早戻しであるなら、カレントＰＴＭがＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅに到達したかを判定する（ステップＳ１４０）。もし到達してないのなら、１つ前のＩピクチャのＰＴＳをカレントＰＴＭに設定する（ステップＳ１４１）。このように読出先アドレスＡを、１つ前のＩピクチャに設定することで、ＡＶＣｌｉｐを後方向に１秒飛びに再生してゆくことができる。これにより、２倍速等でＡＶＣｌｉｐは、逆方向に再生されることになる。尚、早送り、巻戻しを実行するにあたっての処理手順は多種多様なものである。ここで説明するのはあくまでも一例に過ぎないことに留意されたい。
【０１９５】
ステップＳ１３４は、メニューコールＡＰＩがコールされたか否かの判定であり、もしコールされれば、現在の再生処理をサスペンドして（ステップＳ１４２）、メニュー処理用のメニュープログラムを実行する（ステップＳ１４３）。以上の処理により、メニューメニューコールがなされた場合は、再生処理を中断した上で、メニュー表示のための処理が実行されることになる。
【０１９６】
ステップＳ１３５は、ｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿ｉｄにより、ＰｌａｙＩｔｅｍ＃ｘを指定したＳｕｂＰｌａｙＩｔｅｍ＃ｙが存在するか否かの判定であり、もし存在すれば、図５４のフローチャートに移行する。図５４は、ＳｕｂＰｌａｙＩｔｅｍの再生手順を示すフローチャートである。本フローチャートでは、先ずステップＳ１４６において、カレントＰＴＭはＳｕｂＰｌａｙＩｔｅｍ＃ｙのｓｙｎｃ＿ｓｔａｒｔ＿ＰＴＳ＿ｏｆ＿ｐｌａｙＩｔｅｍであるか否かを判定する。もしそうであれば、ステップＳ１５３においてＳｕｂＰｌａｙＩｔｅｍ＃ｙに基づく再生処理を行うようＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に通知する。
【０１９７】
ステップＳ１３６がＹｅｓと判定された場合、ステップＳ１４４、ステップＳ１４５を実行する。ステップＳ１４４は、Ｖｉｒｔｕａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ３０からＮｏｔｉｆｙ Ｅｎｄ Ｏｆ Ｆｉｌｅイベントが出力され、尚且つ、デコーダからＮｏｔｉｆｙ Ｅｎｄ Ｏｆ Ｄｅｃｏｄｉｎｇイベントが出力されたかを判定する。もし出力されれば、Ｎｏｔｉｆｙ Ｅｎｄ Ｏｆ ＳｔｒｅａｍイベントをＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に出力する。
【０１９８】
図５４のステップＳ１４７〜ステップＳ１５２は、ＳｕｂＰｌａｙＩｔｅｍ＃ｙに基づく再生処理を示すフローチャートである。
ステップＳ１４７では、ＳｕｂＰｌａｙＩｔｅｍ＃ｙのＣｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されるＣｌｉｐ情報を読み込む。ステップＳ１４８では、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて、ＳｕｂＰｌａｙＩｔｅｍ＃ｙのＩｎ＿ｔｉｍｅを、アドレスαに変換する。一方ステップＳ１４９では、ＳｕｂＰｌａｙＩｔｅｍ＃ｙのＯｕｔ＿ｔｉｍｅを，カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて、アドレスβに変換する。ステップＳ１５０は、ＳｕｂＰｌａｙＩｔｅｍ＃ｙのＩｎ＿ｔｉｍｅからＳｕｂＰｌａｙＩｔｅｍ＃ｙのＯｕｔ＿ｔｉｍｅまでの出力をデコーダに命じる。これらの変換で得られたアドレスβの次のＩピクチャを求めて、そのアドレスの１つ手前をアドレスγに設定し（ステップＳ１５１）、そうして算出されたアドレスγを用いて、ＳｕｂＣｌｉｐ＃ｚにおけるアドレスαからアドレスγまでのＴＳパケットの読み出しをＢＤ−ＲＯＭドライブ１又はＬｏｃａｌ Ｓｔｏｒａｇｅ１８に命じるというものである（ステップＳ１５２）。
【０１９９】
また図５０に戻ってＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２の処理の説明の続きを行う。ステップＳ１１３はＰｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１による再生制御が完了したかの判定であり、最後のＰｌａｙＩｔｅｍ＃ｘに対して、図５３のフローチャートの処理が行われている限り、ステップＳ１１３がＮｏになる。図５３のフローチャートの処理が終了して初めて、ステップＳ１１３はＹｅｓになりステップＳ１１４に移行する。ステップＳ１１４は、Ｊａｖａ（登録商標）仮想マシン３８へのＮｏｔｉｆｙイベントの出力であり、この出力により、２時間という再生時間の経過をＪａｖａ（登録商標）仮想マシン３８は知ることができる。
【０２００】
以上のように本実施形態によれば、２時間という再生時間の経過時点をアプリケーションマネージャ３６は把握することができるので、プレイリストの再生終了と同期した処理をＪａｖａ（登録商標）仮想マシン３８に実行させることができる。
（備考）
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記（Ａ）（Ｂ）（Ｃ）（Ｄ）・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の技術分野の、出願当時の技術水準の特性に基づく。
【０２０１】
（Ａ）全ての実施形態では、本発明に係る光ディスクをＢＤ−ＲＯＭとして実施したが、本発明の光ディスクは、記録される動的シナリオ、Ｉｎｄｅｘ Ｔａｂｌｅに特徴があり、この特徴は、ＢＤ−ＲＯＭの物理的性質に依存するものではない。動的シナリオ、Ｉｎｄｅｘ Ｔａｂｌｅを記録しうる記録媒体なら、どのような記録媒体であってもよい。例えば、ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−ＲＷ，ＤＶＤ−Ｒ，ＤＶＤ＋ＲＷ，ＤＶＤ＋Ｒ，ＣＤ−Ｒ，ＣＤ−ＲＷ等の光ディスク、ＰＤ，ＭＯ等の光磁気ディスクであってもよい。また、コンパクトフラッシュ（登録商標）カード、スマートメディア、メモリスティック、マルチメディアカード、ＰＣＭ−ＣＩＡカード等の半導体メモリカードであってもよい。フレシキブルディスク、ＳｕｐｅｒＤｉｓｋ，Ｚｉｐ，Ｃｌｉｋ！等の磁気記録ディスク（ｉ）、ＯＲＢ，Ｊａｚ，ＳｐａｒＱ，ＳｙＪｅｔ，ＥＺＦｌｅｙ，マイクロドライブ等のリムーバルハードディスクドライブ（ｉｉ）であってもよい。更に、機器内蔵型のハードディスクであってもよい。
（Ｂ）全ての実施形態における再生装置は、ＢＤ−ＲＯＭに記録されたＡＶＣｌｉｐをデコードした上でＴＶに出力していたが、再生装置をＢＤ−ＲＯＭドライブのみとし、これ以外の構成要素をＴＶに具備させてもい、この場合、再生装置と、ＴＶとをＩＥＥＥ１３９４で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレイと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなす部分のみを、再生装置としてもよい。これらの再生装置は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、各実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。各実施形態に示した再生装置の有償・無償による譲渡（有償の場合は販売、無償の場合は贈与になる）、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。
【０２０２】
（Ｃ）各フローチャートに示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムの実施行為についての実施形態を示したが、再生装置から分離して、各実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為（１）や、有償・無償によりプログラムを譲渡する行為（２）、貸与する行為（３）、輸入する行為（４）、双方向の電子通信回線を介して公衆に提供する行為（５）、店頭展示、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為（６）がある。
【０２０３】
（Ｄ）各フロ−チャ−トにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフロ−チャ−トによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフロ−チャ−トの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。
【０２０４】
（Ｅ）ＢＤ−ＲＯＭに記録するにあたって、ＡＶＣｌｉｐを構成する各ＴＳパケットには、拡張ヘッダを付与しておくことが望ましい。拡張ヘッダは、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒと呼ばれ、『Ａｒｒｉｂｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐ』と、『ｃｏｐｙ＿ｐｅｒｍｉｓｓｉｏｎ＿ｉｎｄｉｃａｔｏｒ』とを含み４バイトのデータ長を有する。ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒ付きＴＳパケット（以下ＥＸ付きＴＳパケットと略す）は、３２個毎にグループ化されて、３つのセクタに書き込まれる。３２個のＥＸ付きＴＳパケットからなるグループは、６１４４バイト（＝３２×１９２）であり、これは３個のセクタサイズ６１４４バイト（＝２０４８×３）と一致する。３個のセクタに収められた３２個のＥＸ付きＴＳパケットを”Ａｌｉｇｎｅｄ Ｕｎｉｔ”という。
【０２０５】
ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時において、再生装置２００は、以下のような送信処理にてＡｌｉｇｎｅｄ Ｕｎｉｔの送信を行う。つまり送り手側の機器は、Ａｌｉｇｎｅｄ Ｕｎｉｔに含まれる３２個のＥＸ付きＴＳパケットのそれぞれからＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒを取り外し、ＴＳパケット本体をＤＴＣＰ規格に基づき暗号化して出力する。ＴＳパケットの出力にあたっては、ＴＳパケット間の随所に、ｉｓｏｃｈｒｏｎｏｕｓパケットを挿入する。この挿入箇所は、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒのＡｒｒｉｂｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐに示される時刻に基づいた位置である。ＴＳパケットの出力に伴い、再生装置２００はＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを出力する。ＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒは、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒにおけるコピー許否設定を示す。ここで「コピー禁止」を示すようＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを記述しておけば、ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時においてＴＳパケットは、他の機器に記録されることはない。
【０２０６】
（Ｆ）各実施形態において、記録媒体に記録されるデジタルストリームはＡＶＣｌｉｐであったが、ＤＶＤ−Ｖｉｄｅｏ規格、ＤＶＤ−Ｖｉｄｅｏ Ｒｅｃｏｒｄｉｎｇ規格のＶＯＢ（Ｖｉｄｅｏ Ｏｂｊｅｃｔ）であってもよい。ＶＯＢは、ビデオストリーム、オーディオストリームを多重化することにより得られたＩＳＯ／ＩＥＣ１３８１８−１規格準拠のプログラムストリームである。またＡＶＣｌｉｐにおけるビデオストリームは、ＭＰＥＧ４やＷＭＶ方式であってもよい。更にオーディオストリームは、Ｌｉｎｅａｒ−ＰＣＭ方式、Ｄｏｌｂｙ−ＡＣ３方式、ＭＰ３方式、ＭＰＥＧ−ＡＡＣ方式、Ｄｔｓ、ＷＭＡ（Ｗｉｎｄｏｗｓ（登録商標）ｍｅｄｉａ ａｕｄｉｏ）であってもよい。
【０２０７】
（Ｇ）各実施形態における映像作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
またビデオテープに記録されているアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。
【０２０８】
（Ｈ）ＢＤ−Ｊモジュール３５は、衛星放送受信のために機器に組み込まれたＪａｖａ（登録商標）プラットフォームであってもよい。ＢＤ−Ｊモジュール３５がかかるＪａｖａ（登録商標）プラットフォームであれば、本発明に係る再生装置は、ＭＨＰ用ＳＴＢとしての処理を兼用することになる。
更に携帯電話の処理制御のために機器に組み込まれたＪａｖａ（登録商標）プラットフォームであってもよい。かかるＢＤ−Ｊモジュール３５がかかるＪａｖａ（登録商標）プラットフォームであれば、本発明に係る再生装置は、携帯電話としての処理を兼用することになる。
【０２０９】
（Ｉ）レイアモデルにおいて、ＢＤ−Ｊモードの上にＨＤＭＶモードを配置してもよい。特にＨＤＭＶモードでの動的シナリオの解釈や、動的シナリオに基づく制御手順の実行は、再生装置に対する負担が軽いので、ＨＤＭＶモードをＢＤ−Ｊモード上で実行させても何等問題は生じないからである。また再生装置や映画作品の開発にあたって、動作保証が１つのモードで済むからである。
【０２１０】
更にＢＤ−Ｊモードだけで再生処理を実行してもよい。第５実施形態に示したように、ＢＤ−ＪモードでもＰＬの再生と同期した再生制御が可能になるから、強いてＨＤＭＶモードを設けなくてもよいという理由による。
（Ｊ）ＡＶＣｌｉｐに多重化されるべきインタラクティブグラフィクスストリームにナビゲーションコマンドを設けて、あるＰＬから別のＰＬへの分岐を実現しても良い。（Ｋ）第１実施形態では、１つのＢＤ−ＲＯＭに属する複数タイトルの全てを生存区間とするタイトルとしてタイトルアンバウンダリーアプリケーションを規定した。この他にも、複数のＢＤ−ＲＯＭに属するタイトルの全てを生存区間とするタイトルアンバウンダリーアプリケーションを規定してもよい。
【０２１１】
（Ｌ）第１実施形態でアプリケーション管理テーブルを作成するにあたって、同時実行し得るアプリケーションの数は、例えば４個以下に制限することが望ましい。
アプリケーションの同時実行数を４個以下に制限する理由は以下の通りである。ＢＤ−ＲＯＭの再生装置は、デジタル放送のチューナ機能を具備しているものが多く、そのチューナ機能を実現するアプリケーションがメモリに常駐（レジデント）していることも多い。かかるレジデントアプリケーションが動作する余地を生むため、アプリケーションの数は４つ以下に制限されている。４つのアプリケーションの内訳として、１つ目をタイトルアンバウンダリーアプリケーション、２つ目をタイトルバウンダリアプリケーション、３つ目をチャプターバウンダリーアプリケーションとしておくことが望ましい。
【０２１２】
（Ｍ）第２実施形態においてエラー管理テーブルは、１つのアプリケーションが異常終了した際、１つのリカバリー処理を実行するよう規定されていた。しかし１つのアプリケーションが異常終了した際、複数のリカバリー処理を実行するようにしてもよい。つまりあるアプリケーションが異常終了した際、プレイリスト再生を継続と、アプリケーションと再起動と、イベント出力とを再生装置に実行させてもよい。
【０２１３】
またアプリケーション毎ではなく、１つのタイトルにつき１つのリカバリー処理を規定するようエラー管理テーブルを構成してもよい。
（Ｎ）ＡＶＣｌｉｐには、メニューを表示して対話的な操作を受け付けるためのインタラクティブグラフィクスストリームを多重化しておくことができるため、トップメニューを表示して対話的な操作を受け付けるようなＡＶＣｌｉｐを、単に再生させるようなナビゲーションコマンドをＭｏｖｉｅＯｂｊｅｃｔに記述しておくだけで、トップメニュータイトルを製作してもよい。
【０２１４】
（Ｏ）各実施形態におけるディレクトリ・ファイル構成及びファイル内のデータ構造は一例であり、本発明の特徴である管理情報は、ディレクトリ・ファイル構成及びファイル内のデータ構造に依存しない。例えばＢＤ−Ｊモードの動作シナリオであるＢＤ−Ｊ Ｏｂｊｅｃｔは、識別子ｂｏｂｊ＿ｉｄと、識別子ＢＤ−Ｊが付与されたファイル（ＺＺＺＺＺ．ＢＤ−Ｊ）として、ＢＤＪＡディレクトリに配置し、ＢＤ−Ｊ Ｏｂｊｅｃｔ．ｂｄｍｖのＢＤ−Ｊ Ｏｂｊｅｃｔ［ｎ］（）には、識別子ｂｏｂｊ＿ｉｄのみを格納してよい。
【産業上の利用可能性】
【０２１５】
本発明に係る記録媒体及び再生装置は、ホームシアターシステムでの利用のように、個人的な用途で利用されることがありうる。しかし本発明は上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る記録媒体及び再生装置は、産業上の利用可能性を有する。
【図１】

【図２】

【図３】

【図４】

【図５】

【図６】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９】

【図２０】

【図２１】

【図２２】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７】

【図２８】

【図２９】

【図３０】

【図３１】

【図３２】

【図３３】

【図３４】

【図３５】

【図３６】

【図３７】

【図３８】

【図３９】

【図４０】

【図４１】

【図４２】

【図４３】

【図４４】

【図４５】

【図４６】

【図４７】

【図４８】

【図４９】

【図５０】

【図５１】

【図５２】

【図５３】

【図５４】

【特許請求の範囲】
【請求項１】
アプリケーションと、デジタルストリームと、管理情報とが記録された記録媒体であって、
前記アプリケーションは、
仮想マシン向けプログラミング言語で記述されたプログラムであり、
仮想マシンによる実行が可能となる生存区間が、予め規定されており、
前記管理情報は、
生存区間において、アプリケーションの実行と同時に行うべきデジタルストリームの再生制御を示す
ことを特徴とする記録媒体。
【請求項２】
前記記録媒体には更に、デジタルストリームの再生経路を規定するプレイリスト情報が複数記録されており、
前記管理情報により示される再生制御は、所定の再生属性が付加されたプレイリスト情報に示される再生経路に従って、デジタルストリームを再生することである、請求項１記載の記録媒体。
【請求項３】
所定の再生属性とは、プレイリスト情報に示される再生経路の再生を自動的に開始する旨を示す属性であり、
前記デジタルストリーム再生の同時実行は、
プレイリスト情報に自動再生を示す再生属性が付加されている場合になされる、ことを特徴とする請求項２記載の記録媒体。
【請求項４】
前記記録媒体には更に、生存区間がないタイトルアンバウンダリーアプリケーションが記録されており、
タイトルアンバウンダリーアプリケーションは、記録媒体に記録されている複数プレイリスト情報のうち、何れか１つを、再生装置における状態レジスタの格納値に応じて選択する処理を行い、
前記所定の再生属性とは、タイトルアンバウンダリーアプリケーションの選択を待って再生される旨を示す再生属性である
ことを特徴とする請求項２記載の記録媒体。
【請求項５】
管理情報は更に、アプリケーションの異常終了時に行うべきリカバリー処理を規定する再生継続フラグを含み、
前記再生継続フラグは所定の値に設定されることにより
アプリケーションと同時になされた再生制御を、アプリケーションの異常終了後も再生装置に継続させる旨を示す
ことを特徴とする請求項１記載の記録媒体。
【請求項６】
管理情報は更に、アプリケーションの異常終了時に行うべきリカバリー処理を規定するフラグを含み、
フラグには、
異常終了したアプリケーションを再起動するか否かを示すフラグ（ｉ）、
アプリケーションの異常終了時に、出力すべきイベントを示すフラグ（ｉｉ）、
再生装置をリブートするか否かを示すフラグ（ｉｉｉ）がある
ことを特徴とする請求項１記載の記録媒体。
【請求項７】
前記アプリケーションは、記録媒体において複数記録されており、
各アプリケーションのそれぞれは、複数タイトルのどれかに帰属しており、
前記アプリケーションの生存区間は、タイトルを用いて表現されている
ことを特徴とする請求項１記載の記録媒体。
【請求項８】
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、
同記録媒体に記録されたデジタルストリームを再生する再生制御エンジン部と、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させ、それと同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、再生制御エンジン部に実行させるアプリケーションマネージャと
を備えることを特徴とする再生装置。
【請求項９】
前記アプリケーションマネージャによる再生制御は、
アプリケーションの実行画像を親画面に配置し、デジタルストリームの再生画像を子画面に配置した合成画像を再生制御エンジン部に出力させる制御を含む
ことを特徴とする請求項８記載の再生装置。
【請求項１０】
前記アプリケーションマネージャは更に、
アプリケーションが起動されるまでのスタートアップディレイにおいて、デジタルストリームの再生画像を主画像として再生させるよう、再生制御エンジン部に対する制御を行い、
前記合成画像を、アプリケーションが正常に起動した後に再生制御エンジン部に表示させる
ことを特徴とする請求項９記載の再生装置。
【請求項１１】
前記アプリケーションマネージャは更に、
デジタルストリームの再生画像を主画像として再生させる制御を、アプリケーションの起動に失敗した際、及び、アプリケーションが異常終了した際にも実行する
ことを特徴とする請求項１０記載の再生装置。
【請求項１２】
前記記録媒体には、プレイリスト情報が複数記録されており、
前記アプリケーションマネージャによる再生制御とは、所定の再生属性が付加されたプレイリスト情報に示される再生経路に従って、デジタルストリームを再生させることである、請求項８記載の再生装置。
【請求項１３】
前記所定の再生属性とは、プレイリスト情報に示される再生経路の再生を自動的に開始する旨を示す再生属性である、ことを特徴とする請求項１２記載の再生装置。
【請求項１４】
前記記録媒体には更に、生存区間がないタイトルアンバウンダリーアプリケーションが記録されており、
タイトルアンバウンダリーアプリケーションは、記録媒体に記録されている複数プレイリスト情報のうち、何れか１つを、再生装置における状態レジスタの格納値に応じて選択する処理を行い、
前記所定の再生属性とは、タイトルアンバウンダリーアプリケーションの選択を待って再生される旨を示す再生属性であり、
前記再生制御エンジン部によるデジタルストリーム再生は、
所定の再生属性が付加されたプレイリスト情報のうちタイトルアンバウンダリーアプリケーションにより選択されたものに基づきなされる
ことを特徴とする請求項１２記載の再生装置。
【請求項１５】
前記管理情報は更に、アプリケーションの異常終了時に行うべきリカバリー処理を規定する再生継続フラグを含み、
前記アプリケーションマネージャは更に、前記再生継続フラグが所定の値に設定されているか否かの判定を行い、前記再生継続フラグが所定の値に設定されていれば、アプリケーションと同時になされた再生制御を、アプリケーションの異常終了後も再生制御エンジン部に継続させる
ことを特徴とする請求項８記載の再生装置。
【請求項１６】
前記アプリケーション毎の生存区間は、記録媒体に記録された管理情報に示されており、
管理情報は更に、アプリケーションの異常終了時に行うべきリカバリー処理を規定するフラグを含み、
アプリケーションマネージャは更に、管理情報内のフラグに基づき
異常終了したアプリケーションを再起動する制御（１）、
予め規定されたイベントを出力する制御（２）、
再生装置をリブートする制御（３）のどれかを実行する
ことを特徴とする請求項８記載の再生装置。
【請求項１７】
前記再生装置は、
何れかのプレイリスト情報を指定した再生がアプリケーションから命じられた場合、当該アプリケーションの正当性を認証するパーミッションコントローラを備え、
前記再生制御エンジン部がプレイリスト情報に基づく再生を行うのは、パーミッションコントローラが正当性ありと認証した場合である
ことを特徴とする請求項８記載の再生装置。
【請求項１８】
アプリケーションマネージャは、プレイリスト情報に基づく再生を行うアプリケーションが存在する場合、当該アプリケーションが再生可能なプレイリスト情報を判定して、当該アプリケーションに通知し、
前記再生制御エンジン部による再生は、通知されたプレイリスト情報に基づく
ことを特徴とする請求項８記載の再生装置。
【請求項１９】
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、同記録媒体に記録されたデジタルストリームを再生する再生制御エンジン部とを有したコンピュータが読み込むことができるプログラムであって、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させるステップと、
仮想マシンによる実行と同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、再生制御エンジン部に実行させるステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項２０】
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、同記録媒体に記録されたデジタルストリームを再生する再生制御エンジン部とを有したコンピュータに対する再生方法であって、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させるステップと、
仮想マシンによる実行と同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、再生制御エンジン部に実行させるステップと
をコンピュータに実行させることを特徴とする再生方法。
【請求項２１】
デジタルストリームを再生する再生装置に組み込むことができるシステム集積回路であって、
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させ、それと同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、実行させるアプリケーションマネージャと
を備えることを特徴とするシステム集積回路。

【国際公開番号】ＷＯ２００５／０４５８４０
【国際公開日】平成１７年５月１９日（２００５．５．１９）
【発行日】平成１９年５月２４日（２００７．５．２４）
【国際特許分類】
【出願番号】特願２００５−５１５３５１（Ｐ２００５−５１５３５１）
【国際出願番号】ＰＣＴ／ＪＰ２００４／０１６５９８
【国際出願日】平成１６年１１月９日（２００４．１１．９）
【特許番号】特許第３８５１３４１号（Ｐ３８５１３４１）
【特許公報発行日】平成１８年１１月２９日（２００６．１１．２９）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】