(57)【要約】ＢＤ−ＲＯＭには、ＡＶＣｌｉｐ及びプレイリスト情報からなるプレイリストと、アプリケーションと、ＢＤ−Ｊ  Ｏｂｊｅｃｔとが記録されている。アプリケーションは、仮想マシン向けプログラミング言語で記述されたプログラムであり、仮想マシンによる実行が可能となる生存区間が、予め規定されている。前記ＢＤ−Ｊ  Ｏｂｊｅｃｔには、プレイリスト管理テーブルが含まれている。プレイリスト管理テーブルは、アプリケーションの生存区間において、各アプリケーションの実行と同時に行うべきプレイリストの再生制御を示す。【特許請求の範囲】
【請求項１】
アプリケーションと、デジタルストリームと、管理情報とが記録された記録媒体であって、
前記アプリケーションは、
仮想マシン向けプログラミング言語で記述されたプログラムであり、
仮想マシンによる実行が可能となる生存区間が、予め規定されており、
前記管理情報は、
生存区間において、アプリケーションの実行と同時に行うべきデジタルストリームの再生制御を示す
ことを特徴とする記録媒体。
【請求項２】
前記記録媒体には更に、デジタルストリームの再生経路を規定するプレイリスト情報が複数記録されており、
前記管理情報により示される再生制御は、所定の再生属性が付加されたプレイリスト情報に示される再生経路に従って、デジタルストリームを再生することである、請求項１記載の記録媒体。
【請求項３】
所定の再生属性とは、プレイリスト情報に示される再生経路の再生を自動的に開始する旨を示す属性であり、
前記デジタルストリーム再生の同時実行は、
プレイリスト情報に自動再生を示す再生属性が付加されている場合になされる、ことを特徴とする請求項２記載の記録媒体。
【請求項４】
前記記録媒体には更に、生存区間がないタイトルアンバウンダリーアプリケーションが記録されており、
タイトルアンバウンダリーアプリケーションは、記録媒体に記録されている複数プレイリスト情報のうち、何れか１つを、再生装置における状態レジスタの格納値に応じて選択する処理を行い、
前記所定の再生属性とは、タイトルアンバウンダリーアプリケーションの選択を待って再生される旨を示す再生属性である
ことを特徴とする請求項２記載の記録媒体。
【請求項５】
管理情報は更に、アプリケーションの異常終了時に行うべきリカバリー処理を規定する再生継続フラグを含み、
前記再生継続フラグは所定の値に設定されることにより
アプリケーションと同時になされた再生制御を、アプリケーションの異常終了後も再生装置に継続させる旨を示す
ことを特徴とする請求項１記載の記録媒体。
【請求項６】
管理情報は更に、アプリケーションの異常終了時に行うべきリカバリー処理を規定するフラグを含み、
フラグには、
異常終了したアプリケーションを再起動するか否かを示すフラグ（ｉ）、
アプリケーションの異常終了時に、出力すべきイベントを示すフラグ（ｉｉ）、
再生装置をリブートするか否かを示すフラグ（ｉｉｉ）がある
ことを特徴とする請求項１記載の記録媒体。
【請求項７】
前記アプリケーションは、記録媒体において複数記録されており、
各アプリケーションのそれぞれは、複数タイトルのどれかに帰属しており、
前記アプリケーションの生存区間は、タイトルを用いて表現されている
ことを特徴とする請求項１記載の記録媒体。
【請求項８】
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、
同記録媒体に記録されたデジタルストリームを再生する再生制御エンジン部と、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させ、それと同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、再生制御エンジン部に実行させるアプリケーションマネージャと
を備えることを特徴とする再生装置。
【請求項９】
前記アプリケーションマネージャによる再生制御は、
アプリケーションの実行画像を親画面に配置し、デジタルストリームの再生画像を子画面に配置した合成画像を再生制御エンジン部に出力させる制御を含む
ことを特徴とする請求項８記載の再生装置。
【請求項１０】
前記アプリケーションマネージャは更に、
アプリケーションが起動されるまでのスタートアップディレイにおいて、デジタルストリームの再生画像を主画像として再生させるよう、再生制御エンジン部に対する制御を行い、
前記合成画像を、アプリケーションが正常に起動した後に再生制御エンジン部に表示させる
ことを特徴とする請求項９記載の再生装置。
【請求項１１】
前記アプリケーションマネージャは更に、
デジタルストリームの再生画像を主画像として再生させる制御を、アプリケーションの起動に失敗した際、及び、アプリケーションが異常終了した際にも実行する
ことを特徴とする請求項１０記載の再生装置。
【請求項１２】
前記記録媒体には、プレイリスト情報が複数記録されており、
前記アプリケーションマネージャによる再生制御とは、所定の再生属性が付加されたプレイリスト情報に示される再生経路に従って、デジタルストリームを再生させることである、請求項８記載の再生装置。
【請求項１３】
前記所定の再生属性とは、プレイリスト情報に示される再生経路の再生を自動的に開始する旨を示す再生属性である、ことを特徴とする請求項１２記載の再生装置。
【請求項１４】
前記記録媒体には更に、生存区間がないタイトルアンバウンダリーアプリケーションが記録されており、
タイトルアンバウンダリーアプリケーションは、記録媒体に記録されている複数プレイリスト情報のうち、何れか１つを、再生装置における状態レジスタの格納値に応じて選択する処理を行い、
前記所定の再生属性とは、タイトルアンバウンダリーアプリケーションの選択を待って再生される旨を示す再生属性であり、
前記再生制御エンジン部によるデジタルストリーム再生は、
所定の再生属性が付加されたプレイリスト情報のうちタイトルアンバウンダリーアプリケーションにより選択されたものに基づきなされる
ことを特徴とする請求項１２記載の再生装置。
【請求項１５】
前記管理情報は更に、アプリケーションの異常終了時に行うべきリカバリー処理を規定する再生継続フラグを含み、
前記アプリケーションマネージャは更に、前記再生継続フラグが所定の値に設定されているか否かの判定を行い、前記再生継続フラグが所定の値に設定されていれば、アプリケーションと同時になされた再生制御を、アプリケーションの異常終了後も再生制御エンジン部に継続させる
ことを特徴とする請求項８記載の再生装置。
【請求項１６】
前記アプリケーション毎の生存区間は、記録媒体に記録された管理情報に示されており、
管理情報は更に、アプリケーションの異常終了時に行うべきリカバリー処理を規定するフラグを含み、
アプリケーションマネージャは更に、管理情報内のフラグに基づき
異常終了したアプリケーションを再起動する制御（１）、
予め規定されたイベントを出力する制御（２）、
再生装置をリブートする制御（３）のどれかを実行する
ことを特徴とする請求項８記載の再生装置。
【請求項１７】
前記再生装置は、
何れかのプレイリスト情報を指定した再生がアプリケーションから命じられた場合、当該アプリケーションの正当性を認証するパーミッションコントローラを備え、
前記再生制御エンジン部がプレイリスト情報に基づく再生を行うのは、パーミッションコントローラが正当性ありと認証した場合である
ことを特徴とする請求項８記載の再生装置。
【請求項１８】
アプリケーションマネージャは、プレイリスト情報に基づく再生を行うアプリケーションが存在する場合、当該アプリケーションが再生可能なプレイリスト情報を判定して、当該アプリケーションに通知し、
前記再生制御エンジン部による再生は、通知されたプレイリスト情報に基づく
ことを特徴とする請求項８記載の再生装置。
【請求項１９】
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、同記録媒体に記録されたデジタルストリームを再生する再生制御エンジン部とを有したコンピュータが読み込むことができるプログラムであって、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させるステップと、
仮想マシンによる実行と同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、再生制御エンジン部に実行させるステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項２０】
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、同記録媒体に記録されたデジタルストリームを再生する再生制御エンジン部とを有したコンピュータに対する再生方法であって、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させるステップと、
仮想マシンによる実行と同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、再生制御エンジン部に実行させるステップと
をコンピュータに実行させることを特徴とする再生方法。
【請求項２１】
デジタルストリームを再生する再生装置に組み込むことができるシステム集積回路であって、
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させ、それと同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、実行させるアプリケーションマネージャと
を備えることを特徴とするシステム集積回路。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、仮想マシンを対象にしたアプリケーションの実行を制御する、アプリケーション制御の技術分野に属する発明であり、本制御技術をＢＤ−ＲＯＭ等の映画作品頒布のための記録媒体、ＢＤ−ＲＯＭを対象とした再生装置等に応用する場合の応用技術に深く係る。
【背景技術】
【０００２】  Ｊａｖａ（登録商標）プログラミング等、仮想マシンを対象にしたアプリケーション制御技術は、パソコンソフトの業界において深く浸透している。パソコンソフトから更に発展して、現在、Ｂｌｕ−ｒａｙ  Ｄｉｓｃ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ（ＢＤ−ＲＯＭ）用再生装置における再生制御をＪａｖａ（登録商標）プログラミングで実現するための様々な工夫が検討されている。
同様の再生装置についての先行技術としては、以下の特許文献１に記載されたものが知られている。
【特許文献１】特許２８１３２４５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】  ところで、Ｊａｖａ（登録商標）プログラミングで作成されたアプリケーションの動作というのは、リソースの使用状況やＣＰＵの負荷により変動を受ける不安定なものである。リソースが枯渇していたため、アプリケーションの起動に失敗したり、アプリケーションが異常終了したりして装置がブラックアウトするのは、パソコンソフトの業界では”よくあること”で済まされるかもしれないが、ＢＤ−ＲＯＭ再生装置の製造に携わる民生機器の分野では品質問題になりかねない。品質問題への波及がありうるので、メーカ各社は、Ｊａｖａ（登録商標）プログラミングによる装置制御の実現に二の足を踏むことが多かった（注；ブラックアウトとは、装置のソフトウェアがフリーズして表示画面が真っ暗になる状態をいう）。【０００４】  本発明の目的は、記録媒体に対する制御を実現するようなアプリケーションが異常終了した場合、又は、起動に失敗した場合の、Ｆａｉｌ  Ｓａｆｅを実現することができる記録媒体を提供する。
【課題を解決するための手段】
【０００５】  上記目的を達成するため、本発明に係る記録媒体はアプリケーションと、デジタルストリームと、管理情報とが記録されていて、前記アプリケーションは、仮想マシン向けプログラミング言語で記述されたプログラムであり、仮想マシンによる実行が可能となる生存区間が、予め規定されており、前記管理情報は、生存区間において、アプリケーションの実行と同時に行うべきデジタルストリームの再生制御を示すことを特徴としている。
【発明の効果】
【０００６】  本発明に係る記録媒体によれば、アプリケーション実行と同時に行うべきデジタルストリームの再生制御が生存区間毎に規定されている。そのため、アプリケーションの起動に失敗したり、アプリケーションの実行の途中でたとえアプリケーションが異常終了したとしても、同時になされているデジタルストリーム再生を継続することにより、”何かが写っている状態”をもたらすことができる。これにより、装置がブラックアウトしてしまうという最悪ケースを回避することができるので、装置を製造するメーカに、最低限度の安心感を与えることができる。【０００７】  こうした安心感が与えられるので、品質問題への波及に神経を尖らせているメーカ各社に対しても、Ｊａｖａ（登録商標）アプリケーションによる再生装置制御の開発を強く後押しすることができる。こうした強い後押しにより、再生装置の低価格化、多様化が進めば、ＢＤ−ＲＯＭコンテンツの充実化を図ることができるので、コンテンツ関連産業の発達を強く牽引することができる。
【図面の簡単な説明】
【０００８】［図１］本発明に係る再生装置の使用行為についての形態を示す図である。
［図２］ＢＤ−ＲＯＭにおけるファイル・ディレクトリ構成を示す図である。
［図３］ＰＬ情報の構成を示す図である。
［図４］ＡＶＣｌｉｐ時間軸と、ＰＬ時間軸との関係を示す図である。
［図５］４つのＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅによりなされた一括指定を示す図である。
［図６］ＰＬｍａｒｋ情報の内部構成を示す図である。
［図７］ＰＬｍａｒｋによるチャプター定義を示す図である。
［図８］ＳｕｂＰａｔｈ情報の内部構成を示す図である。
［図９］ＳｕｂＰｌａｙＩｔｅｍ時間軸上の再生区間定義と、同期指定とを示す図である。
［図１０］Ｍｏｖｉｅ  Ｏｂｊｅｃｔの内部構成を示す図である。
［図１１］ＢＤ−Ｊ  Ｏｂｊｅｃｔの内部構成を示す図である。
［図１２］（ａ）Ｊａｖａ（登録商標）アーカイブファイルに収められているプログラム、データを示す図である。【０００９】  （ｂ）クラスファイルの内部構成を示す図である。
［図１３］ディスクコンテンツにおける状態遷移を示す図である。
［図１４］ＨＤＭＶモードの動的シナリオから構成されるＴｉｔｌｅを示す図である。
［図１５］ＢＤ−Ｊモードの動的シナリオ（ＢＤ−Ｊ  Ｏｂｊｅｃｔ）により構成されるＴｉｔｌｅの内部構成を示す図である。
［図１６］プレイリスト管理テーブルをもたないＴｉｔｌｅを示す図である。
［図１７］ＨＤＭＶモードのＴｉｔｌｅから、ＢＤ−ＪモードのＴｉｔｌｅへの分岐を示す図である。
［図１８］ＢＤ−ＪモードのＴｉｔｌｅから、ＨＤＭＶモードのＴｉｔｌｅへの分岐を示す図である。
［図１９］ｉｎｄｅｘ．ｂｄｍｖの内部構成を示す図である。
［図２０］（ａ）アプリケーション管理テーブルの内部構成を示す図である。【００１０】  （ｂ）アプリケーション管理テーブルを構成する情報要素の意味内容を示す図である。
［図２１］（ａ）ＢＤ−ＲＯＭ全体の時間軸を示す図である。（ｂ）ＢＤ−ＲＯＭ全体の時間軸における構成を示す図である。
［図２２］（ａ）（ｂ）ＢＤ−ＲＯＭ全体の時間軸において、識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−Ｊ  Ｏｂｊｅｃｔから特定されるタイトル再生区間を示す図である。
［図２３］図２２（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。
［図２４］本編タイトル、オンラインショッピングタイトル、ゲームタイトルという３つのタイトルを含むディスクコンテンツを示す図である。
［図２５］（ａ）（ｂ）アプリケーション管理テーブル、生存区間の一例を示す図である。
［図２６］起動属性がとり得る三態様（Ｐｒｅｓｅｎｔ、ＡｕｔｏＲｕｎ、Ｓｕｓｐｅｎｄ）と、直前タイトルにおけるアプリケーション状態の三態様（非起動、起動中、Ｓｕｓｐｅｎｄ）とがとりうる組合せを示す図である。
［図２７］（ａ）プレイリスト管理テーブルの内部構成を示す図である。【００１１】  （ｂ）プレイリスト管理テーブルを構成する情報要素の意味内容を示す図である。
［図２８］分岐先Ｔｉｔｌｅがとり得る三態様（プレイリスト管理テーブル無し、プレイリスト管理テーブル有りで尚且つＰｒｅｓｅｎｔ、プレイリスト管理テーブル有りで尚且つＡｕｔｏＰｌａｙ）と、直前タイトルにおけるＰＬの状態（非再生状態、再生中状態）とがとりうる６通りの組合せを示す図である。
［図２９］（ａ）プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例を示す図である。【００１２】  （ｂ）図２９（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。
［図３１］（ａ）プレイリスト管理テーブルの他の記述例を示す図である。【００１３】  （ｂ）図３０（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。
［図３１］（ａ）〜（ｃ）プレイリスト時間軸と、タイトルの再生区間との関係を示す図である。
［図３２］本発明に係る再生装置の内部構成を示す図である。
［図３３］ＲＯＭ２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。
［図３４］Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１〜モジュールマネージャ３４による処理を模式化した図である。
［図３５］アプリケーションマネージャ３６による処理を模式化した図である。
［図３６］Ｕｓｅｒ  Ｅｖｅｎｔ  Ｍａｎａｇｅｒ３７〜Ｄｅｆａｕｌｔ  Ｏｐｅｒａｔｉｏｎ  Ｍａｎａｇｅｒ４０を示す図である。
［図３７］Ｊａｖａ（登録商標）仮想マシン３８の内部構成を示す図である。
［図３８］アプリケーション終了の４態様を示す図である。
［図３９］アプリケーションマネージャ３６による処理手順を示す図である。
［図４０］プレイリスト管理テーブル、アプリケーション管理テーブルの具体例を示す図である。
［図４１］（ａ）第２実施形態に係るＢＤ−Ｊ  Ｏｂｊｅｃｔの内部構成を示す図である。【００１４】  （ｂ）エラー管理テーブルの内部構成を示す図である。
［図４２］エラー管理テーブルにおける５つのフラグの意味内容を示す。
［図４３］（ａ）エラー管理テーブルが記述された２つのＴｉｔｌｅ（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２）を示す図である。【００１５】  （ｂ）図４３（ａ）のように記載されたアプリケーション管理テーブル、エラー管理テーブルに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。
［図４４］第２実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。
［図４５］第２実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。
［図４６］アプリケーションマネージャ３６による通知処理の処理手順を示すフローチャートである。
［図４７］第３実施形態に係るアプリケーションマネージャ３６の処理手順を示す図である。
［図４８］（ａ）パレンタルレベルに基づく選択アルゴリズムの内容を示す。【００１６】  （ｂ）Ｌａｎｇｕｅｇｅ  ｆｏｒ  Ａｕｄｉｏに基づく選択アルゴリズムの内容を示す。
（ｃ）Ｐｌａｙｅｒ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｆｏｒ  Ｖｉｄｅｏに基づく選択アルゴリズムの内容を示す。
［図４９］タイトルアンバウンダリーアプリケーションにＰＬ選択を行わせる過程を模式的に描いた図である。
［図５０］Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２によるＰＬ再生手順を示すフローチャートである。
［図５１］アングル切換、ＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔの受付手順を示すフローチャートである。
［図５２］ＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔＡＰＩがコールされた際の処理手順を示すフローチャートである。
［図５３］Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１による処理手順の詳細を示すフローチャートである。
［図５４］ＳｕｂＰｌａｙＩｔｅｍの再生手順を示すフローチャートである。
【符号の説明】
【００１７】    １  ＢＤ−ＲＯＭドライブ
２  リードバッファ
３  デマルチプレクサ
４  ビデオデコーダ
５  ビデオプレーン
６  Ｐ−Ｇｒａｐｈｉｃｓデコーダ
７  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン
８  合成部
９  フォントゼネレータ
１０  Ｉ−Ｇｒａｐｈｉｃｓデコーダ
１１  スイッチ
１２  Ｉｎｔｅｒｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン
１３  合成部
１４  ＣＬＵＴ部
１５  ＣＬＵＴ部
１６  オーディオデコーダ
２２  ユーザイベント処理部
２３  ＰＳＲセット
２４  ＣＰＵ
２５  シナリオメモリ
２６  ローカルメモリ
３３  ＨＤＭＶモジュール
３４  モジュールマネージャ
３５  ＢＤ−Ｊモジュール
３６  アプリケーションマネージャ
３７  ＵＯコントローラ
３８  Ｊａｖａ（登録商標）仮想マシン
４１  ＰＬＭＴプロセッサ
４２  パーミッションコントローラ
５２  ユーザクラスローダ
５３  メソッドエリア
５４  ワークメモリ
５５ａ，ｂ・・・ｎ  スレッド
５６ａ，ｂ・・・ｄ  Ｊａｖａ（登録商標）スタック
【発明を実施するための最良の形態】
【００１８】  （第１実施形態）
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体はＢＤ−ＲＯＭ１００であり、ＢＤ−ＲＯＭ１００は、再生装置２００、リモコン３００、テレビ４００により形成されるホームシアターシステムに、著作物を供給するという用途に供される。【００１９】  このうちリモコン４００には、再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（Ｐａｕｓｅ  Ｏｎ）、一時停止の解除（Ｐａｕｓｅ  Ｏｆｆ）、Ｓｔｉｌｌ機能の解除（ｓｔｉｌｌ  ｏｆｆ）、速度指定付きの早送り（Ｆｏｒｗａｒｄ  Ｐｌａｙ（ｓｐｅｅｄ））、速度指定付きの巻戻し（Ｂａｃｋｗａｒｄ  Ｐｌａｙ（ｓｐｅｅｄ））、音声切り換え（Ａｕｄｉｏ  Ｃｈａｎｇｅ）、副映像切り換え（Ｓｕｂｔｉｔｌｅ  Ｃｈａｎｇｅ）、アングル切り換え（Ａｎｇｌｅ  Ｃｈａｎｇｅ）を受け付けるキーや、メニュー操作時にあたってのフォーカス移動操作を受け付けるＭｏｖｅＵｐキー、ＭｏｖｅＤｏｗｎキー、ＭｏｖｅＲｉｇｈｔキー、ＭｏｖｅＬｅｆｔキー、メニュー表示操作を受け付けるＰｏｐ−ｕｐキー、数値入力を受け付けるＮｕｍｅｒｉｃキーが存在する。【００２０】  以上が本発明に係る記録媒体の使用形態についての説明である。
続いて本発明に係る記録媒体の生産行為について説明する。本発明に係る記録媒体は、ＢＤ−ＲＯＭのファイルシステム上における改良で実現することができる。図２は、ＢＤ−ＲＯＭにおけるファイル・ディレクトリ構成を示す図である。本図においてＢＤ−ＲＯＭには、Ｒｏｏｔディレクトリの下に、ＢＤＭＶディレクトリがある。【００２１】  ＢＤＭＶディレクトリには、拡張子ｂｄｍｖが付与されたファイル
（ｉｎｄｅｘ．ｂｄｍｖ，ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖ，ＢＤ−Ｊ  Ｏｂｊｅｃｔ．ｂｄｍｖ）がある。そしてこのＢＤＭＶディレクトリの配下には、更にＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦディレクトリ、ＳＴＲＥＡＭディレクトリ、ＢＤＪＡディレクトリと呼ばれる４つのサブディレクトリが存在する。
ＰＬＡＹＬＩＳＴディレクトリには、拡張子ｍｐｌｓが付与されたファイル
（００００１．ｍｐｌｓ，００００２．ｍｐｌｓ，００００３ｍｐｌｓ）がある。【００２２】  ＣＬＩＰＩＮＦディレクトリには、拡張子ｃｌｐｉが付与されたファイル
（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ）がある。
ＳＴＲＥＡＭディレクトリには、拡張子ｍ２ｔｓが付与されたファイル
（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ，００００３．ｍ２ｔｓ）がある。
ＢＤＪＡディレクトリには、拡張子ｊａｒが付与されたファイル
（００００１．ｊａｒ，００００２．ｊａｒ，００００３ｊａｒ）がある。以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、ＢＤ−ＲＯＭ上に配置されていることがわかる。【００２３】  本図において拡張子．ｍ２ｔｓが付与されたファイル
（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ，００００３．ｍ２ｔｓ・・・・・）は、ＡＶＣｌｉｐを格納している。ＡＶＣｌｉｐには、ＭａｉｎＣＬｉｐ、ＳｕｂＣｌｉｐといった種別がある。ＭａｉｎＣＬｉｐは、ビデオストリーム、オーディオストリーム、字幕を構成するプレゼンテーショングラフィクスストリーム（ＰＧストリーム）、メニューを構成するインタラクティブグラフィクスストリーム（ＩＧストリーム）というような複数エレメンタリストリームを多重化することで得られたデジタルストリームである。【００２４】  ＳｕｂＣｌｉｐは、オーディオストリーム、グラフィクスストリーム、テキスト字幕ストリーム（ＴｅｘｔＳＴＳｔｒｅａｍ）等、１つのエレメンタリストリームのみにあたるデジタルストリームである。
拡張子”ｃｌｐｉ”が付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ・・・・・）は、ＡＶＣｌｉｐのそれぞれに１対１に対応する管理情報である。管理情報故に、Ｃｌｉｐ情報は、ＡＶＣｌｉｐにおけるストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、ＧＯＰの先頭位置を示すＥＰ＿ｍａｐをもっている。【００２５】  拡張子”ｍｐｌｓ”が付与されたファイル（００００１．ｍｐｌｓ，００００２．ｍｐｌｓ，００００３．ｍｐｌｓ・・・・・）は、プレイリスト情報を格納したファイルである。プレイリスト情報は、ＡＶＣｌｉｐを参照してプレイリストを定義する情報である。図３は、ＰＬ情報の構成を示す図であり、本図の左側に示すように、プレイリスト情報は、『ＭａｉｎＰａｔｈ情報』、『ＰＬＭａｒｋ情報』、『ＳｕｂＰａｔｈ情報』から構成される。【００２６】  ＭａｉｎＰａｔｈ情報（ＭａｉｎＰａｔｈ（））は、破線の矢印ｍｐ１に示すように複数のＰｌａｙＩｔｅｍ情報（ＰｌａｙＩｔｅｍ（））からなる。ＰｌａｙＩｔｅｍとは、１つ以上のＡＶＣｌｉｐ時間軸上において、Ｉｎ＿Ｔｉｍｅ，Ｏｕｔ＿Ｔｉｍｅを指定することで定義される再生区間である。ＰｌａｙＩｔｅｍ情報を複数配置させることで、複数再生区間からなるプレイリスト（ＰＬ）が定義される。図中の破線ｍｐ２は、ＰｌａｙＩｔｅｍ情報の内部構成をクローズアップしている。本図に示すようにＰｌａｙＩｔｅｍ情報は、対応するＡＶＣｌｉｐを示す『Ｃｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ』と、『Ｉｎ＿ｔｉｍｅ』と、『Ｏｕｔ＿ｔｉｍｅ』とからなる。図４は、ＡＶＣｌｉｐと、ＰＬとの関係を示す図である。第１段目はＡＶＣｌｉｐｉがもつ時間軸を示し、第２段目は、ＰＬがもつ時間軸を示す。ＰＬ情報は、ＰｌａｙＩｔｅｍ＃１，＃２，＃３という３つのＰｌａｙＩｔｅｍ情報を含んでおり、これらＰｌａｙＩｔｅｍ＃１，＃２，＃３のＩｎ＿ｔｉｍｅ，Ｏｕｔ＿ｔｉｍｅにより、３つの再生区間が定義されることになる。これらの再生区間を配列させると、ＡＶＣｌｉｐ時間軸とは異なる時間軸が定義されることになる。これが第２段目に示すＰＬ時間軸である。このように、ＰｌａｙＩｔｅｍ情報の定義により、ＡＶＣｌｉｐとは異なる時間軸の定義が可能になる。【００２７】  ＡＶＣｌｉｐに対する指定は、原則１つであるが、複数ＡＶＣｌｉｐに対する一括指定もあり得る。この一括指定は、ＰｌａｙＩｔｅｍ情報における複数のＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅによりなされる。図５は、４つのＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅによりなされた一括指定を示す図である。本図において第１段目〜第４段目は、４つのＡＶＣｌｉｐ時間軸（ＡＶＣｌｉｐ＃１，＃２，＃３，＃４の時間軸）を示し、第５段目は、ＰＬ時間軸を示す。ＰｌａｙＩｔｅｍ情報が有する、４つのＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅにて、これら４つの時間軸が指定されている。こうすることで、ＰｌａｙＩｔｅｍが有するＩｎ＿ｔｉｍｅ，Ｏｕｔ＿ｔｉｍｅにより、択一的に再生可能な４つの再生区間が定義されることになる。これにより、ＰＬ時間軸には、切り換え可能な複数アングル映像からなる区間（いわゆるマルチアングル区間）が定義されることになる。【００２８】  ＰＬｍａｒｋ情報（ＰＬｍａｒｋ（））は、ＰＬ時間軸のうち、任意の区間を、チャプターとして指定する情報である。図６は、ＰＬｍａｒｋ情報の内部構成を示す図であり、本図の引き出し線ｐｍ１に示すようにＰＬｍａｒｋ情報は、『ｒｅｆ＿ｔｏ＿ＰｌａｙＩｔｅｍ＿Ｉｄ』と、『Ｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐ』とを含む。図７は、ＰＬｍａｒｋによるチャプター定義を示す図である。本図において第１段目は、ＡＶＣｌｉｐ時間軸を示し、第２段目はＰＬ時間軸を示す。図中の矢印ｐｋ１，２は、ＰＬｍａｒｋにおけるＰｌａｙＩｔｅｍ指定（ｒｅｆ＿ｔｏ＿ＰｌａｙＩｔｅｍ＿Ｉｄ）と、一時点の指定（ｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐ）とを示す。これらの指定によりＰＬ時間軸には、３つのチャプター（Ｃｈａｐｔｅｒ＃１，＃２，＃３）が定義されることになる。以上がＰＬｍａｒｋについての説明である。続いてＳｕｂＰａｔｈ情報について説明する。【００２９】  ＳｕｂＰａｔｈ情報（ＳｕｂＰａｔｈ（））は、ＳｕｂＣｌｉｐの時間軸上にＩｎ＿Ｔｉｍｅ，Ｏｕｔ＿Ｔｉｍｅを指定することで１つ以上の再生区間を定義する情報であり、図８に示す内部構成を有している。本図に示すようにＳｕｂＰａｔｈ情報は、破線の引き出し線ｓｈ１に示すように複数のＳｕｂＰｌａｙＩｔｅｍ情報（ＳｕｂＰｌａｙＩｔｅｍ（））からなる。破線ｓｈ２を用いてクローズアップしているように、ＳｕｂＰｌａｙＩｔｅｍ情報は、『Ｃｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ』と、『Ｉｎ＿ｔｉｍｅ』と、『Ｏｕｔ＿ｔｉｍｅ』と、『Ｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿Ｉｄ』と、『Ｓｙｎｃ＿ｓｔａｒｔ＿Ｐｔｓ＿ｏｆ＿ＰｌａｙＩｔｅｍ』とからなる。ＳｕｂＣｌｉｐの時間軸上に対する、Ｉｎ＿Ｔｉｍｅ，Ｏｕｔ＿Ｔｉｍｅの指定は、『Ｃｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ』、『Ｉｎ＿ｔｉｍｅ』、『Ｏｕｔ＿ｔｉｍｅ』によりなされる。『Ｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿Ｉｄ』及び『Ｓｙｎｃ＿ｓｔａｒｔ＿Ｐｔｓ＿ｏｆ＿ＰｌａｙＩｔｅｍ』は、ＳｕｂＣｌｉｐ時間軸上の再生区間と、ＰＬ時間軸とを同期させるという同期指定をなす。この同期指定により、ＰＬ時間軸と、ＳｕｂＰｌａｙＩｔｅｍ時間軸とは同期して進行することになる。【００３０】  図９は、ＳｕｂＰｌａｙＩｔｅｍ時間軸上の再生区間定義と、同期指定を示す図である。本図において第１段目は、ＰＬ時間軸を示し、第２段目はＳｕｂＰｌａｙＩｔｅｍ時間軸を示す。図中のＳｕｂＰｌａｙＩｔｅｍ．ＩＮ＿ｔｉｍｅは再生区間の始点を、ＳｕｂＰｌａｙＩｔｅｍ．Ｏｕｔ＿ｔｉｍｅは再生区間の終点をそれぞれ示す。これによりＳｕｂＣｌｉｐ時間軸上にも再生区間が定義されていることがわかる。矢印Ｓｎ１においてＳｙｎｃ＿ＰｌａｙＩｔｅｍ＿Ｉｄは、ＰｌａｙＩｔｅｍに対する同期指定を示し、矢印Ｓｎ２においてｓｙｎｃ＿ｓｔａｒｔ＿ＰＴＳ＿ｏｆ＿ＰｌａｙＩｔｅｍは、ＰＬ時間軸におけるＰｌａｙＩｔｅｍ上の一時点の指定を示す。【００３１】  複数ＡＶＣｌｉｐの切り換えを可能とするマルチアングル区間や、ＡＶＣｌｉｐ−ＳｕｂＣｌｉｐを同期させ���る同期区間の定義を可能とするのが、ＢＤ−ＲＯＭにおけるプレイリスト情報の特徴である。以上のＣｌｉｐ情報及びプレイリスト情報は、”静的シナリオ”に分類される。何故なら、以上のＣｌｉｐ情報及びプレイリスト情報により、静的な再生単位であるＰＬが定義されるからである。以上で静的シナリオについての説明を終わる。【００３２】  続いて”動的なシナリオ”について説明する。動的シナリオとは、ＡＶＣｌｉｐの再生制御を動的に規定するシナリオデータである。”動的に”というのは、再生装置における状態変化やユーザからのキーイベントにより再生制御の中身がかわることをいう。ＢＤ−ＲＯＭでは、この再生制御の動作環境として２つのモードを想定している。１つ目は、ＤＶＤ再生装置の動作環境と良く似た動作環境であり、コマンドベースの実行環境である。２つ目は、Ｊａｖａ（登録商標）仮想マシンの動作環境である。これら２つの動作環境のうち１つ目は、ＨＤＭＶモードと呼ばれる。２つ目は、ＢＤ−Ｊモードと呼ばれる。これら２つの動作環境があるため、動的シナリオはこのどちらかの動作環境を想定して記述される。ＨＤＭＶモードを想定した動的シナリオはＭｏｖｉｅ  Ｏｂｊｅｃｔと呼ばれ、管理情報により定義される。一方ＢＤ−Ｊモードを想定した動的シナリオはＢＤ−Ｊ  Ｏｂｊｅｃｔと呼ばれる。【００３３】  先ず初めにＭｏｖｉｅ  Ｏｂｊｅｃｔについて説明する。
＜Ｍｏｖｉｅ  Ｏｂｊｅｃｔ＞
Ｍｏｖｉｅ  Ｏｂｊｅｃｔは、ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖというファイルに格納される。図１０は、ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖの内部構成を示す図である。本図の左端に示すようにＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖは、コード列”ＭＯＢＪ”を示す『ｔｙｐｅ＿ｉｎｄｉｃａｔｅｒ』と、『ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ』と、１つ以上のＭｏｖｉｅＯｂｊｅｃｔである『ＭｏｖｉｅＯｂｊｅｃｔｓ（）』とからなる。図中の図中の引き出し線ｖｈ１はＭｏｖｉｅＯｂｊｅｃｔｓの内部構成をクローズアップしている。ＭｏｖｉｅＯｂｊｅｃｔｓ（）は、自身のデータ長である『ｌｅｎｇｔｈ』と、自身に含まれるＭｏｖｉｅＯｂｊｅｃｔの個数である『ｎｕｍｂｅｒ＿ｏｆ＿ｍｏｂｊｓ』と、ｎｕｍｂｅｒ＿ｏｆ＿ｍｏｂｊｓ個のＭｏｖｉｅＯｂｊｅｃｔである『ＭｏｖｉｅＯｂｊｅｃｔｓ』とからなる。これらｎｕｍｂｅｒ＿ｏｆ＿ｍｏｂｊｓ個のＭｏｖｉｅＯｂｊｅｃｔは、識別子ｍｏｂｊ＿ｉｄをもって識別される。図中の引き出し線ｖｈ２は、識別子ｍｏｂｊ＿ｉｄにより特定される任意のＭｏｖｉｅＯｂｊｅｃｔ［ｍｏｂｊ＿ｉｄ］（）の内部構成をクローズアップしている。【００３４】  この引き出し線に示すように、ＭｏｖｉｅＯｂｊｅｃｔは、ＭｅｎｕＣａｌｌがなされた際、ＭｅｎｕＣａｌｌ後の再生再開を意図しているか否かを示す『ｒｅｓｕｍｅ＿ｉｎｔｅｎｔｉｏｎ＿ｆｌａｇ』、ＭｅｎｕＣａｌｌをマスクするか否かを示す情報『ｍｅｎｕ＿ｃａｌｌ＿ｍａｓｋ』、タイトルサーチ機能をマスクするかを示す『ｔｉｔｌｅ＿ｓｅａｒｃｈ＿ｆｌａｇ』、ナビゲーションコマンドの個数である『ｎｕｍｂｅｒ＿ｏｆ＿ｎａｖｉｇａｔｉｏｎ＿ｃｏｍｍａｎｄ』、ｎｕｍｂｅｒ＿ｏｆ＿ｎａｖｉｇａｔｉｏｎ＿ｃｏｍｍａｎｄ個の『ナビゲーションコマンド』からなる。【００３５】  ナビゲーションコマンド列は、条件分岐、再生装置における状態レジスタの設定、状態レジスタの設定値取得等を実現するコマンド列からなる。ＭｏｖｉｅＯｂｊｅｃｔにおいて記述可能なコマンドを以下に示す。
ＰｌａｙＰＬコマンド
書式：ＰｌａｙＰＬ（第１引数，第２引数）
第１引数は、プレイリストの番号で、再生すべきＰＬを指定することができる。第２引数は、そのＰＬに含まれるＰｌａｙＩｔｅｍや、そのＰＬにおける任意の時刻、Ｃｈａｐｔｅｒ、Ｍａｒｋを用いて再生開始位置を指定することができる。【００３６】  ＰｌａｙＩｔｅｍによりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数を
ＰｌａｙＰＬａｔＰｌａｙＩｔｅｍ（）、
ＣｈａｐｔｅｒによりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数を
ＰｌａｙＰＬａｔＣｈａｐｔｅｒ（）、
時刻情報によりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数を
ＰｌａｙＰＬａｔＳｐｅｃｉｆｉｅｄ  Ｔｉｍｅ（）という。
ＪＭＰコマンド
書式：ＪＭＰ引数
ＪＭＰコマンドは、現在の動的シナリオを途中で廃棄し（ｄｉｓｃａｒｄ）、引数たる分岐先動的シナリオを実行するという分岐である。ＪＭＰ命令の形式には、分岐先動的シナリオを直接指定している直接参照のものと、分岐先動的シナリオを間接参照している間接参照のものがある。
Ｍｏｖｉｅ  Ｏｂｊｅｃｔにおけるナビゲーションコマンドの記述は、ＤＶＤにおけるナビゲーションコマンドの記述方式と良く似ているので、ＤＶＤ上のディスクコンテンツを、ＢＤ−ＲＯＭに移植するという作業を効率的に行うことができる。Ｍｏｖｉｅ  Ｏｂｊｅｃｔについては、以下の国際公開公報に記載された先行技術が存在する。詳細については、本国際公開公報を参照されたい。
国際公開公報ＷＯ  ２００４／０７４９７６
以上でＭｏｖｉｅ  Ｏｂｊｅｃｔについての説明を終える。続いてＢＤ−Ｊ  Ｏｂｊｅｃｔについて説明する。
＜ＢＤ−Ｊ  Ｏｂｊｅｃｔ＞
ＢＤ−Ｊ  Ｏｂｊｅｃｔは、Ｊａｖａ（登録商標）プログラミング環境で記述された、ＢＤ−Ｊモードの動的シナリオである。【００３７】  図１１は、ＢＤ−Ｊ  Ｏｂｊｅｃｔ．ｂｄｍｖの内部構成を示す図である。本図の左端に示すようにＢＤ−Ｊ  Ｏｂｊｅｃｔ．ｂｄｍｖは、コード列”ＢＯＢＪ”を示す『ｔｙｐｅ＿ｉｎｄｉｃａｔｅｒ』と、『ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ』と、１つ以上のＢＤ−Ｊ  Ｏｂｊｅｃｔである『ＢＤ−Ｊ  Ｏｂｊｅｃｔｓ（）』とからなる。図中の図中の引き出し線ｂｈ１はＢＤ−Ｊ  Ｏｂｊｅｃｔｓの内部構成をクローズアップしている。ＢＤ−Ｊ  Ｏｂｊｅｃｔｓ（）は、自身のデータ長である『ｌｅｎｇｔｈ』と、自身に含まれるＢＤ−Ｊ  Ｏｂｊｅｃｔの個数である『ｎｕｍｂｅｒ＿ｏｆ＿ｂｏｂｊｓ』と、ｎｕｍｂｅｒ＿ｏｆ＿ｂｏｂｊｓ個のＢＤ−Ｊ  Ｏｂｊｅｃｔである『ＢＤ−Ｊ  Ｏｂｊｅｃｔｓ』とからなる。これらｎｕｍｂｅｒ＿ｏｆ＿ｂｏｂｊｓ個のＢＤ−Ｊ  Ｏｂｊｅｃｔは、識別子ｂｏｂｊ＿ｉｄをもって識別される。図中の引き出し線ｂｈ２は、識別子ｂｏｂｊ＿ｉｄにより特定される任意のＢＤ−Ｊ  Ｏｂｊｅｃｔ［ｂｏｂｊ＿ｉｄ］（）の内部構成をクローズアップしている。【００３８】  この引き出し線に示すように、本図に示すようにＢＤ−Ｊ  Ｏｂｊｅｃｔは、『ｒｅｓｕｍｅ＿ｉｎｔｅｎｔｉｏｎ＿ｆｌａｇ［ｂｏｂｊ＿ｉｄ］』と、『ｍｅｎｕ＿ｃａｌｌ＿ｍａｓｋ［ｂｏｂｊ＿ｉｄ］』と、『ｔｉｔｌｅ＿ｓｅａｒｃｈ＿ｆｌａｇ［ｂｏｂｊ＿ｉｄ］』と、『Ａｐｐｌｉｃａｔｉｏｎ＿Ｍａｎａｇｅｍｅｎｔ＿Ｔａｂｌｅ［ｂｏｂｊ＿ｉｄ］』と、『Ｐｌａｙｌｉｓｔ＿Ｍａｎａｇｅｍｅｎｔ＿Ｔａｂｌｅ［ｂｏｂｊ＿ｉｄ］』とからなる。『ｒｅｓｕｍｅ＿ｉｎｔｅｎｔｉｏｎ＿ｆｌａｇ』、『ｍｅｎｕ＿ｃａｌｌ＿ｍａｓｋ』、『ｔｉｔｌｅ＿ｓｅａｒｃｈ＿ｆｌａｇ』を含んでいる点においてＢＤ−Ｊ  ＯｂｊｅｃｔはＭｏｖｉｅ  Ｏｂｊｅｃｔとほぼ同じである。【００３９】  Ｍｏｖｉｅ  Ｏｂｊｅｃｔとの違いは、ＢＤ−Ｊ  Ｏｂｊｅｃｔにコマンドが直接記述されていない点である。つまりＭｏｖｉｅ  Ｏｂｊｅｃｔにおいて制御手順は、ナビゲーションコマンドにより直接記述されていた。これに対しＢＤ−Ｊ  Ｏｂｊｅｃｔでは、Ｊａｖａ（登録商標）アプリケーションに対する指定を『Ａｐｐｌｉｃａｔｉｏｎ＿Ｍａｎａｇｅｍｅｎｔ＿Ｔａｂｌｅ［ｂｏｂｊ＿ｉｄ］』上に記載することにより、間接的に制御手順を規定している。このような間接的な規定により、複数動的シナリオにおいて制御手順を共通化するという、制御手順の共通化を効率的に行うことができる。【００４０】  またＭｏｖｉｅＯｂｊｅｃｔにおけるＰＬ再生は、ＰＬ再生を命じるナビゲーションコマンド（ＰｌａｙＰｌコマンド）の記述によりなされていたが、ＢＤ−Ｊ  ＯｂｊｅｃｔにおけるＰＬ再生は、ＰＬ再生手順を示す『Ｐｌａｙｌｉｓｔ＿Ｍａｎａｇｅｍｅｎｔ＿Ｔａｂｌｅ［ｂｏｂｊ＿ｉｄ］』をＢＤ−Ｊ  Ｏｂｊｅｃｔに組み込むことで記述が可能になる。それだけではなくアプリケーション管理テーブルから参照されるアプリケーションに、ＰＬ再生手順を組み込むことでも記述が可能になる。つまりプレイリスト管理テーブルの記述、アプ���ケーションにおけるＰＬ再生手順の記述のどちらであっても、プレイリスト再生の手順を組み込んでおくことができる。【００４１】  ここでＪａｖａ（登録商標）アプリケーションについて説明する。Ｊａｖａ（登録商標）アプリケーションは、仮想マシンのヒープ領域（ワークメモリとも呼ばれる）にロードされた１つ以上のｘｌｅｔプログラムからなる。このワークメモリにロードされたｘｌｅｔプログラム、及び、データから、アプリケーションは構成されることになる。以上がＪａｖａ（登録商標）アプリケーションの構成である。
このＪａｖａ（登録商標）アプリケーションの実体にあたるのが、図２におけるＢＤＭＶディレクトリ配下のＢＤＪＡディレクトリに格納されたＪａｖａ（登録商標）アーカイブファイル（００００１．ｊａｒ，００００２．ｊａｒ）である。以降、Ｊａｖａ（登録商標）アーカイブファイルについて、図１２を参照しながら説明する。【００４２】  ＜Ｊａｖａ（登録商標）アーカイブファイル＞
Ｊａｖａ（登録商標）アーカイブファイル（図２の００００１．ｊａｒ，００００２．ｊａｒ）は、１つ以上のクラスファイル、１つ以上のデータファイル等を１つにまとめることで得られるファイルである。図１２（ａ）は、アーカイブファイルにより収められているプログラム、データを示す図である。本図におけるデータは、枠内に示すディレクトリ構造が配置された複数ファイルを、Ｊａｖａ（登録商標）アーカイバでまとめたものである。枠内に示すディレクトリ構造は、Ｒｏｏｔディレクトリ、Ｊａｖａ（登録商標）ディレクトリ、ｉｍａｇｅディレクトリとからなり、Ｒｏｏｔディレクトリにｃｏｍｍｏｎ．ｐｋｇが、Ｊａｖａ（登録商標）ディレクトリにクラスファイル（ａａａ．ｃｌａｓｓ，ｂｂｂ．ｃｌａｓｓ）が、ｉｍａｇｅディレクトリに、ｍｅｎｕ．ｊｐｇが配置されている。Ｊａｖａ（登録商標）アーカイブファイルは、これらをＪａｖａ（登録商標）アーカイバでまとめることで得られる。かかるクラスファイル及びデータは、ＢＤ−ＲＯＭからキャッシュに読み出されるにあたって展開され、キャッシュ上で、ディレクトリに配置された複数ファイルとして取り扱われる。Ｊａｖａ（登録商標）アーカイブファイルのファイル名における″ｚｚｚｚｚ″という５桁の数値は、アプリケーションのＩＤ（ａｐｐｌｉｃａｔｉｏｎＩＤ）を示す。本Ｊａｖａ（登録商標）アーカイブファイルがキャッシュに読み出された際、このファイル名における数値を参照することにより、任意のＪａｖａ（登録商標）アプリケーションを構成するプログラム，データを取り出すことができる。
本図におけるクラスファイル（図中のａａａ．ｃｌａｓｓ，ｂｂｂ．ｃｌａｓｓ）は、上述したｘｌｅｔプログラムに対応するクラスファイルである。ＢＤ−Ｊモードにおける再生手順は、このクラスファイルのインスタンスにあたるｘｌｅｔプログラムにより規定される。【００４３】  ｘｌｅｔプログラムとは、ＪＭＦ（Ｊａｖａ（登録商標）Ｍｅｄｉａ  ＦｒａｍｅＷｏｒｋ）方式のインターフェイスを利用することができるＪａｖａ（登録商標）プログラムであり、ＪＭＦ等の方式に従って、キーイベントに基づく処理を行う。ｘｌｅｔプログラムは、ＪＭＦ方式の処理が可能であるので、ＭＰＬＳファイルに対するインスタンス（ＪＭＦプレーヤインスタンス）を生成することにより、プレイリスト再生を再生装置に命じることができる。他にもｘｌｅｔプログラムでは、ファンクションＡＰＩのコールを記述することにより、ＢＤ−ＲＯＭ再生装置特有の処理を実行させることができる。【００４４】  更にｘｌｅｔプログラムは、ＷＷＷサイトをアクセスしてコンテンツをダウンロードするという手順を実行することもできる。これによりダウンロードコンテンツと、プレイリスト再生とを交えた斬新な作品を再生させることができる。
ｘｌｅｔプログラムのクラスファイルについて説明する。図１２（ｂ）は、クラスファイルの内部構成を示す図である。本図に示すようにクラスファイルは、通常のクラスファイル同様、『コンスタントプール』、『インターフェイス』、『メソッド１，２，３・・・・ｎ』からなる。クラスファイルにおけるメソッドには、挙動のトリガになるキーイベントが予め登録されているメソッド（ＥｖｅｎｔＬｉｓｔｎｅｒ）と、ＪＭＦの再生手順を命じるメソッド（ＪＭＦプレーヤインスタンスのメソッド）、ＢＤ−ＲＯＭ再生装置側のファンクションＡＰＩをコールするメソッドがある。これらのメソッドは、自身に割り当てられたローカル変数や、自身をコールする際の引数を用いることにより、演算等の手順が記述されている。以上がＪａｖａ（登録商標）アーカイブファイルについての説明である。尚、本実施形態においてアプリケーションを構成するプログラム、データは、Ｊａｖａ（登録商標）アーカイブファイルにまとめられたが、ＬＺＨファイル、ｚｉｐファイルであってもよい。【００４５】  以上が、ＢＤ−Ｊモードにおける動的シナリオについての説明である。
＜ＢＤ−ＲＯＭにおける状態遷移＞
ＤＶＤ−Ｖｉｄｅｏのような読出専用ディスクで供給されるディスクコンテンツは、トップメニューを中核とした構造になっている。そのトップメニューから、個々の著作物へと分岐して再生を行い、その後再び、ＴｏｐＭｅｎｕ  Ｔｉｔｌｅに戻るという独特の状態遷移をなす。図１３は、ディスクコンテンツにおける状態遷移を示す図である。本図における四角枠は、Ｔｉｔｌｅである。Ｔｉｔｌｅとは、ディスクコンテンツ特有の状態遷移において、１つの”状態”にあたる再生単位である。Ｔｉｔｌｅには、ＢＤ−ＲＯＭのローディング時に最初に再生される『ＦｉｒｓｔＰｌａｙＴｉｔｌｅ』、Ｔｏｐ＿Ｍｅｎｕを構成する『Ｔｏｐ＿ｍｅｎｕＴｉｔｌｅ』、これら以外の一般的な『Ｔｉｔｌｅ』がある。また、図中の矢印ｊｈ１，２，３，４，５，６，７，８は、Ｔｉｔｌｅ間の分岐を象徴的に示す。本図に示される状態遷移とは、ＢＤ−ＲＯＭローディング時に、『ＦｉｒｓｔＰｌａｙＴｉｔｌｅ』が再生され、『Ｔｏｐ＿ｍｅｎｕＴｉｔｌｅ』への分岐が発生して、トップメニューに対する選択待ちになるというものである。ＢＤ−ＲＯＭのような映画作品頒布用の記録媒体の業界では、動的商標を、ローディング時に再生するという慣習が定着している。この動的商標は、映画作品の制作者や頒布者を表徴するものであり、ＦｉｒｓｔＰｌａｙＴｉｔｌｅは、ＢＤ−ＲＯＭのローディングされた際、なによりも先に、この動的商標を再生させるという役割分担を担う。【００４６】  そしてユーザによるメニューに対する選択操作があれば、選択に従って該当Ｔｉｔｌｅの再生を行い、再びＴｏｐＭｅｎｕ  Ｔｉｔｌｅに戻るとの処理を、ＢＤ−ＲＯＭのイジェクトがなされるまで延々と繰り返すというのが、ディスクコンテンツ特有の状態遷移である。
かかる状態遷移をなすＴｉｔｌｅは、ＨＤＭＶモードの動的シナリオ、ＢＤ−Ｊモードの動的シナリオから構成される。図１４は、ＨＤＭＶモードの動的シナリオから構成される２つのＴｉｔｌｅを示す図である。本図の第１段目は、識別子ｔｉｔｌｅ＿ｉｄにより識別される任意のＴｉｔｌｅ（ｔｉｔｌｅ＿ｉｄ）を示す。第２段目は、そのＴｉｔｌｅを構成している１つ以上のＭｏｖｉｅＯｂｊｅｃｔからなるＭｏｖｉｅＯｂｊｅｃｔ列を示す。第３段目は、ＭｏｖｉｅＯｂｊｅｃｔを構成するナビゲーションコマンドを示す。【００４７】  他のＴｉｔｌｅへのＪｕｍｐを再生装置に命じるナビゲーションコマンド（ＪｕｍｐＴｉｔｌｅコマンド）をＭｏｖｉｅＯｂｊｅｃｔに記述しておくことにより、図１３に示したような、あるＴｉｔｌｅから別のＴｉｔｌｅへの分岐が実現されることになる。またＰＬ再生を命じるナビゲーションコマンド（ＰｌａｙＰＬコマンド）をＭｏｖｉｅＯｂｊｅｃｔに記述しておくことにより、本図第４段目に示すＰＬが、Ｔｉｔｌｅに帰属することになる。【００４８】  ＰＬを帰属させることにより、ＨＤＭＶモードにおけるＴｉｔｌｅでは、動画再生を伴う映画作品を定義することができる。これがＨＤＭＶモードの動的シナリオにより定義されるＴｉｔｌｅの構成である。
続いてＢＤ−Ｊモードの動的シナリオにより構成されるＴｉｔｌｅの内部構成について説明する。図１５は、ＢＤ−Ｊモードの動的シナリオ（ＢＤ−Ｊ  Ｏｂｊｅｃｔ）により構成されるＴｉｔｌｅの内部構成を示す図である。【００４９】  第１段目は、識別子ｔｉｔｌｅ＿ｉｄにより識別される任意のＴｉｔｌｅを示し、第２段目は、そのＴｉｔｌｅを構成する唯一のＢＤ−Ｊ  Ｏｂｊｅｃｔを示す。第３段目は、そのＢＤ−Ｊ  Ｏｂｊｅｃｔの内部にあるアプリケーション管理テーブル、プレイリスト管理テーブルを示す。第４段目は、第３段目のアプリケーション管理テーブルにより動作することになるアプリケーションを示す。このアプリケーションは、第５段目に示すように、他のＴｉｔｌｅへのＪｕｍｐを再生装置に命じるメソッド（ＪｕｍｐＴｉｔｌｅＡＰＩをコールするメソッド）を含んでいるので、ＪｕｍｐＴｉｔｌｅＡＰＩのコールメソッドにより、図１３に示した他ののＴｉｔｌｅへの分岐が実現することになる。一方、第３段目にはプレイリスト管理テーブルが記述されているので、第４段目にあたっては、アプリケーションの実行と共にＰＬが再生されることになる。【００５０】  ＢＤ−Ｊ  Ｏｂｊｅｃｔには、アプリケーション管理テーブル，プレイリスト管理テーブルが含まれているので、第４段目に示すように、アプリケーション実行と、ＰＬ再生とが同時になされることになる。このようなアプリケーション実行と、ＰＬ再生との同時実行がＢＤ−ＪモードにおけるＴｉｔｌｅの特徴である。
プレイリスト管理テーブルは、全てのＢＤ−Ｊ  Ｏｂｊｅｃｔに存在する訳ではない。プレイリスト管理テーブルは任意的な構成要素であり、プレイリスト管理テーブルをもつＢＤ−Ｊ  Ｏｂｊｅｃｔもあるし、プレイリスト管理テーブルをもたないＢＤ−Ｊ  Ｏｂｊｅｃｔもある。図１６は、プレイリスト管理テーブルをもたないＴｉｔｌｅを示す図である。アプリケーション管理テーブルしか存在しないため、プレイリスト管理テーブルをもたないようなＢＤ−Ｊ  Ｏｂｊｅｃｔでは、第４段目に示すように、アプリケーション動作のみが規定される。以上によるアプリケーション動作の規定により、ＰＬ再生を伴わない、制御手順のみのＴｉｔｌｅが規定されることになる。【００５１】  また図１４ではＨＤＭＶモードのＴｉｔｌｅから、ＨＤＭＶモードのＴｉｔｌｅへの分岐が記述されていたが、図１７に示すようにＨＤＭＶモードのＴｉｔｌｅから、ＢＤ−ＪモードのＴｉｔｌｅへの分岐もありえる。同様に図１５ではＢＤ−ＪモードのＴｉｔｌｅから、ＢＤ−ＪモードのＴｉｔｌｅへの分岐が記述されていたが、図１８に示すようにＢＤ−ＪモードのＴｉｔｌｅから、ＨＤＭＶモードのＴｉｔｌｅへの分岐もありえる。【００５２】  上述したＴｉｔｌｅの内部構成において、あるＴｉｔｌｅの構成要素となるＭｏｖｉｅＯｂｊｅｃｔはどれであるか、又は、あるＴｉｔｌｅの構成要素となるＢＤ−Ｊ  Ｏｂｊｅｃｔはどれであるのかを定義するのが、図２に示したｉｎｄｅｘ．ｂｄｍｖである。以降ｉｎｄｅｘ．ｂｄｍｖについて説明する。
Ｉｎｄｅｘ．ｂｄｍｖは、タイトルを構成する、Ｍｏｖｉｅ  Ｏｂｊｅｃｔ又はＢＤ−Ｊ  Ｏｂｊｅｃｔを示すテーブルである。【００５３】  図１９は、ｉｎｄｅｘ．ｂｄｍｖの内部構成を示す図である。本図に示すようにｉｎｄｅｘ．ｂｄｍｖは、値”ＩＮＤＸ”を示す値をもつ『ｔｙｐｅ＿ｉｎｄｉｃａｔｏｒ』と、『ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ』と、本ファイルの先頭からＩｎｄｅｘｅｓまでの相対アドレスを示す『Ｉｎｄｅｘｅｓ＿ｓｔａｒｔ＿ａｄｄｒｅｓｓ』と、『Ｉｎｄｅｘｅｓ（）』とからなる。『Ｉｎｄｅｘｅｓ』は、各Ｔｉｔｌｅに対するインデックスであり、破線の引き出し線ｉｘ１でクローズアップしているように、『Ｉｎｄｅｘｅｓ』は、『ｌｅｎｇｔｈ』，『ＦｉｒｓｔＰｌａｙｂａｃｋ（）｛ＦｉｒｓｔＰｌａｙｂａｃｋ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ｝』，『ＴｏｐＭｅｎｕ（）｛ＴｏｐＭｅｎｕ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ｝』，『ｎｕｍｂｅｒ＿ｏｆ＿Ｔｉｔｌｅｓ』，『Ｔｉｔｌｅ［０］（）〜Ｔｉｔｌｅ［ｎｕｍｂｅｒ＿ｏｆ＿Ｔｉｔｌｅｓ−１］（）』からなる。【００５４】  『ＦｉｒｓｔＰｌａｙｂａｃｋ（）｛ＦｉｒｓｔＰｌａｙｂａｃｋ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ｝』は、ＦｉｒｓｔＰｌａｙＴｉｔｌｅに対するＩｎｄｅｘであり、ＦｉｒｓｔＰｌａｙＴｉｔｌｅを構成するＭｏｖｉｅＯｂｊｅｃｔ識別子の参照値（ＦｉｒｓｔＰｌａｙｂａｃｋ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ）が格納される。
『ＴｏｐＭｅｎｕ（）｛ＴｏｐＭｅｎｕ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ｝』は、Ｔｏｐ−ＭｅｎｕＴｉｔｌｅに対するＩｎｄｅｘであり、Ｔｏｐ＿ｍｅｎｕＴｉｔｌｅを構成するＭｏｖｉｅＯｂｊｅｃｔ識別子の参照値（ＴｏｐＭｅｎｕ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ）が格納される。【００５５】  『Ｔｉｔｌｅ［０］（）〜Ｔｉｔｌｅ［ｎｕｍｂｅｒ＿ｏｆ＿Ｔｉｔｌｅｓ−１］（）』は、ＦｉｒｓｔＰｌａｙＴｉｔｌｅ、Ｔｏｐ−ＭｅｎｕＴｉｔｌｅ以外のＴｉｔｌｅに対するＩｎｄｅｘであり、ｎｕｍｂｅｒ＿ｏｆ＿Ｔｉｔｌｅ個存在している。これらは識別子ｔｉｔｌｅ＿ｉｄをもって識別される。
ここで識別子ｔｉｔｌｅ＿ｉｄにより特定されるインデックスをＴｉｔｌｅ［ｔｉｔｌｅ＿ｉｄ］（）とする。図中の引き出し線ｉｘ２は、Ｔｉｔｌｅ［ｔｉｔｌｅ＿ｉｄ］（）に対する内部構成をクローズアップしている。【００５６】  本図に示すように”Ｔｉｔｌｅ［ｔｉｔｌｅ＿ｉｄ］（）”は、”Ｔｉｔｌｅ［ｔｉｔｌｅ＿ｉｄ］が、分岐をもっているか否か等、Ｔｉｔｌｅの再生の類型を示す『Ｔｉｔｌｅ＿Ｐｌａｙｂａｃｋ＿Ｔｙｐｅ［ｔｉｔｌｅ＿ｉｄ］』と、このＴｉｔｌｅに対するサーチ機能の実行が許可されているか否かを示す『Ｔｉｔｌｅ＿ａｃｃｅｓｓ＿Ｆｌａｇ［ｔｉｔｌｅ＿ｉｄ］』と、Ｔｉｔｌｅを構成するＭｏｖｉｅＯｂｊｅｃｔを一意に示す『ｔｉｔｌｅ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ］ｔｉｔｌｅ＿ｉｄ］』とからなる。ここでＴｉｔｌｅを構成する動的シナリオがＢＤ−Ｊ  Ｏｂｊｅｃｔであれば、『ｔｉｔｌｅ＿ｂｏｂｊ＿ｉｄ＿ｒｅｆ［ｔｉｔｌｅ＿ｉｄ］』が『ｔｉｔｌｅ＿ｍｏｂｊ＿ｉｄ＿ｒｅｆ［ｔｉｔｌｅ＿ｉｄ］』の代わりになる。『ｔｉｔｌｅ＿ｂｏｂｊ＿ｉｄ＿ｒｅｆ［ｔｉｔｌｅ＿ｉｄ］』は、Ｔｉｔｌｅを構成するＢＤ−Ｊ  Ｏｂｊｅｃｔを一意に示す。
Ｉｎｄｅｘ．ｂｄｍｖについては、以下の国際公開公報に詳細が記載されている。詳細については、本公報を参照されたい。
国際公開公報ＷＯ  ２００４／０２５６５１  Ａ１公報
＜アプリケーション管理テーブル＞
ＢＤ−Ｊ  Ｏｂｊｅｃｔに含まれるアプリケーション管理テーブル及びプレイリスト管理テーブルは、本実施形態の主眼となる構成要素であり、その詳細について説明する。先ずアプリケーション管理テーブル（ＡＭＴ）について説明する。【００５７】  図２０（ａ）は、アプリケーション管理テーブルの内部構成を示す図である。本図に示すようにアプリケーション管理テーブルは、『ｌｉｆｅ＿ｃｙｃｌｅ』と、『ａｐｌｉ＿ｉｄ＿ｒｅｆ』と、『ｒｕｎ＿ａｔｔｒｉｂｕｔｅ』と、『ｒｕｎ＿ｐｒｉｏｒｉｔｙ』からなる。
図２０（ｂ）は、アプリケーション管理テーブルを構成する情報要素の意味内容を示す。【００５８】  『ｌｉｆｅ＿ｃｙｃｌｅ』は、アプリケーションの”生存区間”を示す。
『ａｐｌｉ＿ｉｄ＿ｒｅｆ』は、”アプリケーション識別子”に対する参照値が記述されることにより、左記の生存区間をもつアプリケーションがどれであるかを示す。アプリケーション識別子は、Ｊａｖａ（登録商標）アーカイブファイルにおいて、ファイル名として付与された５桁の数値ｚｚｚｚｚで表現される。『ａｐｌｉ＿ｉｄ＿ｒｅｆ』には、この５桁の数値が記述される。【００５９】  『ｒｕｎ＿ａｔｔｒｉｂｕｔｅ』は、当該生存区間におけるアプリケーションの”起動属性”が記述される。起動属性には、ＡｕｔｏＲｕｎ、Ｐｒｅｓｅｎｔ、Ｓｕｓｐｅｄといった種別がある。
『ｒｕｎ＿ｐｒｉｏｒｉｔｙ』は、当該生存区間におけるアプリケーションの”起動優先度”が記述される。ＢＤ−Ｊ  Ｏｂｊｅｃｔでは、これらの情報を用いてアプリケーションの挙動を制御する。
＜生存区間＞
アプリケーション管理テーブルに規定される情報のうち、生存区間について説明する。【００６０】  生存区間とは、ＢＤ−ＲＯＭに記録されたコンテンツ全体の時間軸において、仮想マシンのワークメモリ上でアプリケーションが生存し得る区間を示す。ワークメモリにおける”生存”とは、そのアプリケーションを構成するｘｌｅｔプログラムが、ワークメモリに読み出され、仮想マシンによる実行が可能になっている状態をいう。
Ｊａｖａ（登録商標）仮想マシンにおいてアプリケーションを動作させる場合、時間軸の何処からアプリケーションによるサービスを開始し、時間軸の何処でアプリケーションによるサービスを終えるかという”サービスの開始点・終了点”を明確に規定することが重要になる。このサービスの開始点・終了点を規定するのが、アプリケーション管理テーブルにおける生存区間である。【００６１】  それでは、図１３のような状態遷移をなすディスクコンテンツにおいて、Ｔｉｔｌｅの生存区間はどのように規定されるのであろうか。ＢＤ−ＲＯＭのローディングがなされた後、図１３において矢印ｊｈ１，２，３，４・・・・・に示された参照符号の数値順に分岐がなされ、ＢＤ−ＲＯＭがイジェクトされたものとする。そうすると、ＢＤ−ＲＯＭがローディングされてから、イジェクトされるまでの連続時間帯を一本の時間軸と同視することができる。この時間軸を、ディスク全体の時間軸とする。図２１（ａ）は、ディスク全体の時間軸を示す図であり、図２１（ｂ）は、この時間軸における構成を示す。図２１（ｂ）に示すように、ディスク全体の時間軸は、ＦｉｒｓｔＰｌａｙ  Ｔｉｔｌｅが再生されている区間、ＴｏｐＭｅｎｕ  Ｔｉｔｌｅが再生されている区間、ｔｉｔｌｅ＃１が再生されている区間等からなる。これらＴｉｔｌｅの再生区間はどのように規定されているかというと、Ｔｉｔｌｅは、１つ以上のＭｏｖｉｅＯｂｊｅｃｔ、又は、唯一のＢＤ−Ｊ  Ｏｂｊｅｃｔから構成されるから、どれかのＭｏｖｉｅＯｂｊｅｃｔ又はＢＤ−Ｊ  Ｏｂｊｅｃｔが、有効になっている期間をＴｉｔｌｅの再生区間と考えることができる。【００６２】  つまりＦｉｒｓｔＰｌａｙ  Ｔｉｔｌｅ、ＴｏｐＭｅｎｕ  Ｔｉｔｌｅ、その他のＴｉｔｌｅは、何れも動的シナリオから構成されるから、Ｔｉｔｌｅを構成するＭｏｖｉｅＯｂｊｅｃｔ又はＢＤ−Ｊ  Ｏｂｊｅｃｔのうち、どれかがカレントＭｏｖｉｅＯｂｊｅｃｔ、又は、カレントＢＤ−Ｊ  ＯｂｊｅｃｔとしてＡｃｔｉｖａｔｅｄされ、再生装置内において解読・実行に供されている期間を、Ｔｉｔｌｅの再生区間と定義することができる。図２２（ａ）は、ＢＤ−ＲＯＭ全体の時間軸において、識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−Ｊ  Ｏｂｊｅｃｔから特定されるタイトル再生区間を示す図である。ここで識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−Ｊ  Ｏｂｊｅｃｔが、１つのＴｉｔｌｅを構成しているなら、その識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−Ｊ  Ｏｂｊｅｃｔが有効になっているＢＤ−ＲＯＭ時間軸上の一区間を、Ｔｉｔｌｅの再生区間と考えることができる。【００６３】  同様に、識別子ｍｏｂｊ＿ｉｄにより特定されるＭｏｖｉｅＯｂｊｅｃｔが、１つのＴｉｔｌｅを構成しているなら、その識別子ｍｏｂｊ＿ｉｄにより特定されるＭｏｖｉｅＯｂｊｅｃｔが有効になっている、ＢＤ−ＲＯＭ時間軸上の一区間を、Ｔｉｔｌｅの再生区間と考えることができる。
ここでＭｏｖｉｅＯｂｊｅｃｔ、ＢＤ−Ｊ  ＯｂｊｅｃｔがＡｃｔｉｖａｔｅされている期間の終期は、Ｔｉｔｌｅ分岐（ＪｕｍｐＴｉｔｌｅ）がなされるまでである。つまり、Ｔｉｔｌｅ分岐（ＪｕｍｐＴｉｔｌｅ）がなされるまで、実行の対象になっている動的シナリオは、カレントＭｏｖｉｅＯｂｊｅｃｔ及びカレントＢＤ−Ｊ  Ｏｂｊｅｃｔとして扱われるから、そのＭｏｖｉｅＯｂｊｅｃｔ又はＢＤ−Ｊ  ＯｂｊｅｃｔにおいてＪｕｍｐＴｉｔｌｅが発生するまでの１つの区間を、Ｔｉｔｌｅ再生区間として扱う。【００６４】  続いてＴｉｔｌｅ区間と、ＰＬ時間軸との関係について説明する。上述したようにＭｏｖｉｅＯｂｊｅｃｔ、ＢＤ−Ｊ  Ｏｂｊｅｃｔでは、１つの処理手順としてＰＬ再生手順を記述することができる。ＰＬ再生手順の記述があれば、上述したＰＬ時間軸の全部又は一部がＴｉｔｌｅ区間に帰属することになる。図２２（ａ）の一例においてＢＤ−Ｊ  Ｏｂｊｅｃｔに、プレイリスト管理テーブルが記述されているとする。この場合、ＢＤ−Ｊ  Ｏｂｊｅｃｔに対応するＴｉｔｌｅ区間には、図２２（ｂ）に示すように、ＰＬ時間軸が帰属する。このＰＬ時間軸には更に、複数チャプター（Ｃｈａｐｔｅｒ＃１，＃２，＃３）が定義され得るため、ＢＤ−ＲＯＭ上の時間軸には、ＢＤ−ＲＯＭ全体−Ｔｉｔｌｅ−ＰＬ−チャプターというドメインが存在することになる。これらのドメインを用いて、アプリケーションの生存区間を記述することができる。尚、プレイリスト再生は、アプリケーション実行と同時になされため、プレイリスト再生の途中で、Ｔｉｔｌｅ分岐が発生することがある。この場合、１つのＴｉｔｌｅ再生区間内にはプレイリスト時間軸全体ではなく、プレイリスト時間軸の一部分のみが帰属することになる。つまり１つのＴｉｔｌｅの再生区間において、プレイリスト時間軸の全体が帰属するか、その一部分が帰属するかは、Ｔｉｔｌｅ分岐が何時発生するかによって変わる。【００６５】  図２３は、図２２（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。本図に示すようにアプリケーションには、Ｔｉｔｌｅを生存区間にした”タイトルバウンダリアプリケーション”、Ｔｉｔｌｅ内におけるチャプターを生存区間にした”チャプターバウンダリアプリケーション”、ＢＤ−ＲＯＭ全体の時間軸を生存区間にした”タイトルアンバウンダリーアプリケーション”という３つの典型がある。【００６６】  このうちタイトルバウンダリアプリケーションの生存区間は、そのタイトルの識別子を用いて定義することができる。またチャプターバウンダリアプリケーションの生存区間は、チャプターが属するタイトルの識別子と、そのチャプターの識別子との組みを用いて定義することができる。
プラットフォームが動作していたとしても、Ｔｉｔｌｅやチャプターという生存区間が終われば、リソースをアプリケーションから回収することができる。リソース回収の機会を保証するので、プラットフォームの動作を安定化させることができる。【００６７】  近い将来、実施されるであろうディスクコンテンツを題材に選んで、アプリケーション管理テーブルにおける生存区間記述について、具体例を交えて説明する。ここで題材にするディスクコンテンツは、映像本編を構成する本編タイトル（ｔｉｔｌｅ＃１）、オンラインショッピングを構成するオンラインショッピングタイトル（ｔｉｔｌｅ＃２）、ゲームアプリケーションを構成するゲームタイトル（ｔｉｔｌｅ＃３）という、性格が異なる３つのタイトルを含むものである。図２４は、本編タイトル、オンラインショッピングタイトル、ゲームタイトルという３つのタイトルを含むディスクコンテンツを示す図である。本図における右側にはＩｎｄｅｘ．ｂｄｍｖを記述しており、左側には３つのタイトルを記述している。【００６８】  右側における破線枠は、各アプリケーションがどのタイトルに属しているかという帰属関係を示す。３つのタイトルのうちｔｉｔｌｅ＃１は、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３という３つのアプリケーションからなる。ｔｉｔｌｅ＃２は、ａｐｐｌｉｃａｔｉｏｎ＃３、ａｐｐｌｉｃａｔｉｏｎ＃４という２つのアプリケーション、ｔｉｔｌｅ＃３は、ａｐｐｌｉｃａｔｉｏｎ＃５を含む。図２４の一例においてａｐｐｌｉｃａｔｉｏｎ＃３は、ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２の双方で起動される。【００６９】  図２４の破線に示される帰属関係から各アプリケーションの生存区間をグラフ化すると、図２５（ａ）のようになる。本図において横軸は、タイトル再生区間であり、縦軸方向に各アプリケーションの生存区間を配置している。ここでａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２は、ｔｉｔｌｅ＃１のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃１内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃４は、ｔｉｔｌｅ＃２のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃２内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃５は、ｔｉｔｌｅ＃３のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃３内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃３は、ｔｉｔｌｅ＃１及びｔｉｔｌｅ＃２に帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃１−ｔｉｔｌｅ＃２にわたる。この生存区間に基づき、アプリケーション管理テーブルを記述すると、ｔｉｔｌｅ＃１，＃２，＃３のアプリケーション管理テーブルは図２５（ｂ）のようになる。このようにアプリケーション管理テーブルが記述されれば、ｔｉｔｌｅ＃１の再生開始時においてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３をワークメモリにロードしておく。そしてｔｉｔｌｅ＃２の開始時にａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２をワークメモリから削除してａｐｐｌｉｃａｔｉｏｎ＃３のみにするという制御を行う。これと同様にｔｉｔｌｅ＃２の再生開始時においてａｐｐｌｉｃａｔｉｏｎ＃４をワークメモリにロードしておき、ｔｉｔｌｅ＃３の開始時にａｐｐｌｉｃａｔｉｏｎ＃３，＃４をワークメモリから削除するという制御を行いうる。【００７０】  更に、ｔｉｔｌｅ＃３の再生中においてａｐｐｌｉｃａｔｉｏｎ＃５をワークメモリにロードしておき、ｔｉｔｌｅ＃３の再生終了時にａｐｐｌｉｃａｔｉｏｎ＃５をワークメモリから削除するという制御を行いうる。
タイトル間分岐があった場合でも、分岐元−分岐先において生存しているアプリケーションはワークメモリ上に格納しておき、分岐元にはなく、分岐先にのみ存在するアプリケーションをワークメモリに読み込めば良いから、アプリケーションをワークメモリに読み込む回数は必要最低数になる。このように、読込回数を少なくすることにより、タイトルの境界を意識させないアプリケーション、つまりアンバウンダリなアプリケーションを実現することができる。【００７１】  続いてアプリケーションの起動属性についてより詳しく説明する。起動属性には、自動的な起動を示す「ＡｕｔｏＲｕｎ」、自動起動の対象ではないが、仮想マシンのワークメモリに置いて良いことを示す「Ｐｒｅｓｅｎｔ」、仮想マシンのワークメモリにはおかれるが、ＣＰＵパワーの割り当ては不可となる「Ｓｕｓｐｅｎｄ」がある。
「ＡｕｔｏＲｕｎ」は、対応するタイトルの分岐と同時に、そのアプリケーションをワークメモリに読み込み、且つ実行する旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、その分岐先タイトルにおいて生存しており、かつ起動属性がＡｕｔｏＲｕｎに設定されたアプリケーションを仮想マシンのワークメモリに読み込み実行する。これによりそのアプリケーションは、タイトル分岐と共に自動的に起動されることになる。【００７２】  起動属性「Ｐｒｅｓｅｎｔ」は、継続属性であり、分岐元ｔｉｔｌｅにおけるアプリケーションの状態を継続することを示す。また対応するアプリケーションを実行してよいことを示す属性である。起動属性が「Ｐｒｅｓｅｎｔ」である場合、この起動属性が付与されたアプリケーションは、他のアプリケーションからの呼び出しが許可されることになる。アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、起動中のアプリケーションから呼出があると、そのアプリケーションのａｐｐｌｉｃａｔｉｏｎＩＤが、アプリケーション管理テーブルに記述されていて、起動属性が「Ｐｒｅｓｅｎｔ」であるか否かを判定する。「Ｐｒｅｓｅｎｔ」であれば、そのアプリケーションをワークメモリにロードする。一方、その呼出先アプリケーションのａｐｐｌｉｃａｔｉｏｎＩＤがアプリケーション管理テーブルに記述されていない場合、そのアプリケーションはワークメモリにロードされない。アプリケーションによる呼出は、この「Ｐｒｅｓｅｎｔ」が付与されたアプリケーションに限られることになる。「Ｐｒｅｓｅｎｔ」は、起動属性を明示的に指定しない場合に付与されるデフォルトの起動属性であるから、あるアプリケーションの起動属性が無指定「−」である場合、そのアプリケーションの起動属性の起動属性はこのＰｒｅｓｅｎｔであることを意味する。【００７３】  「Ｓｕｓｐｅｎｄ」とは、リソースは割り付けられているが、ＣＰＵパワーは割り当てられない状態にアプリケーションが置かれることをいう。かかるＳｕｓｐｅｎｄは、例えばゲームタイトルの実行中に、サイドパスを経由するという処理の実現に有意義である。
図２６は、起動属性がとり得る三態様（Ｐｒｅｓｅｎｔ、ＡｕｔｏＲｕｎ、Ｓｕｓｐｅｎｄ）と、直前タイトルにおけるアプリケーション状態の三態様（非起動、起動中、Ｓｕｓｐｅｎｄ）とがとりうる組合せを示す図である。直前状態が”非起動”である場合、起動属性が”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、起動されることになる。【００７４】  直前状態が”非起動”であり、起動属性が”Ｐｒｅｓｅｎｔ”、”Ｓｕｓｐｅｎｄ”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。
直前状態が”起動中”である場合、起動属性が”Ｐｒｅｓｅｎｔ”、”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。【００７５】  起動属性が”Ｓｕｓｐｅｎｄ”であるなら、アプリケーションの状態はＳｕｓｐｅｎｄされることになる。直前状態が”Ｓｕｓｐｅｎｄ”である場合、分岐先タイトルの起動属性が”Ｓｕｓｐｅｎｄ”ならＳｕｓｐｅｎｄを維持することになる。”Ｐｒｅｓｅｎｔ”又は”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、レジュームすることになる。アプリケーション管理テーブルにおいて生存区間及び起動属性を定義することにより、タイトル再生区間の進行に沿って、Ｊａｖａ（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。【００７６】  尚、直前状態が”Ｓｕｓｐｅｎｄ”であり、分岐先タイトルの起動属性が”Ｐｒｅｓｅｎｔ”の場合は、直前状態、すなわちサスペンド状態を維持しても良い。
最後に、各アプリケーションに対する”起動優先度”について説明する。
この起動優先度は、０〜２５５の値をとり、メモリリソース枯渇時や、ＣＰＵ負荷が高まった時に、どのアプリケーションを強制的に終了させるか、また、どちらのアプリケーションからリソースを奪うかという処理をアプリケーションマネージャが行うにあたっての判断材料になる。この場合、アプリケーションマネージャは、起動優先度が低いアプリケーションの動作を終了し、起動優先度が高いアプリケーションの動作を継続させるとの処理を行う。【００７７】  また起動優先度は、再生中ＰＬに対する要求が競合した場合のアプリケーション間の調停でも利用される。ここであるアプリケーションが、あるプレイリストの早送りしているものとする。ここで別のアプリケーションが同じプレイリストに対するポーズ要求を行ったとすると、これらのアプリケーションに付与された起動優先度を比較する。そして早送りを命じたアプリケーションの起動優先度が高いなら、かかるアプリケーションによる早送りを継続して行う。逆にポーズを命じたアプリケーションの起動優先度が高いなら、早送り中ＰＬをポーズを行う。【００７８】  以上の生存区間・起動属性・起動優先度により、仮想マシン上で動作し得るアプリケーションの数を所定数以下に制限するよう規定しておくことがオーサリング時に可能なる。そのため、アプリケーションの安定動作を保証することができる。
＜プレイリスト管理テーブル＞
以上がアプリケーション管理テーブルについての説明である。続いてプレイリスト管理テーブルについて説明する。プレイリスト管理テーブルとは、アプリケーションの生存区間において、各アプリケーション実行と同時に行うべき再生制御を示すテーブルである。アプリケーションの動作というのは不安定であり、起動の失敗や異常終了がありうる。そこで起動失敗、異常終了があった場合のＦａｉｌ  Ｓａｆｅ機構として、本実施形態ではアプリケーションの生存区間毎に、プレイリスト管理テーブルを設けている。プレイリスト管理テーブルは、あるアプリケーションの生存区間が開始した際、これと同時に行うべき再生制御を規定する情報である。この再生制御とは、プレイリスト情報に基づくＡＶＣｌｉｐ再生であり、プレイリスト情報による再生制御を同時に行うことで、アプリケーション実行と、プレイリスト再生とが同時になされることになる。プレイリスト管理テーブルは、アプリケーションの生存区間毎に設けられるとしたが、プレイリスト管理テーブルが設けられるアプリケーションは、タイトルバウンダリのアプリケーションに限られる。何故ならタイトルアンバウンダリーアプリケーションは、全タイトルを生存区間にしているため、アプリケーション実行と同時にプレイリスト再生を行うという制御は、適合しないからである。【００７９】  チャプターバウンダリアプリケーションは、１つのプレイリスト内のチャプターからアプリケーション実行を開始するという前提の下で生存区間が規定されているため、プレイリスト再生を規定する必要はないからである。以上のことからプレイリスト管理テーブルは、１つ以上のＴｉｔｌｅからなる生存区間に定義されることになる。
図２７（ａ）は、プレイリスト管理テーブルの内部構成を示す図である。本図に示すようにプレイリスト管理テーブルは、『ＰＬ＿ｉｄ＿ｒｅｆ』と、『Ｐｌａｙｂａｃｋ＿Ａｔｔｒｉｂｕｔｅ』とからなる。【００８０】  図２７（ｂ）は、プレイリスト管理テーブルを構成する情報要素の意味内容を示す。
『ＰＬ＿ｉｄ＿ｒｅｆ』は、ＰＬ識別子に対する”参照値”が記述されることにより、アプリケーションの生存区間において再生可能となるＰＬがどれであるかを示す。ＰＬ識別子は、ファイルＹＹＹＹＹ．ＭＰＬＳにおいて、ファイル名として付与された５桁の数値ＹＹＹＹＹで表現される。このＹＹＹＹＹが記述されることにより、『ＰＬ＿ｉｄ＿ｒｅｆ』は、対応するＴｉｔｌｅにおいて再生可能となるＰＬがどれであるかを示す。【００８１】  『Ｐｌａｙｂａｃｋ＿Ａｔｔｒｉｂｕｔｅ』は、アプリケーション管理テーブルにおける起動属性に倣った属性であり、『ＰＬ＿ｉｄ＿ｒｅｆ』に記述されたＰＬを、タイトル開始時において、どのように再生するかを規定する再生属性である。ＰＬに対する再生属性には、『ＡｕｔｏＰｌａｙ』、『Ｐｒｅｓｅｎｔ』といった種別がある。
『ＡｕｔｏＰｌａｙ』とは、対応するタイトルの分岐と同時に、そのプレイリストを再生させる旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、その分岐先タイトルにおいて再生可能であり、かつ再生属性がＡｕｔｏＰｌａｙに設定されたプレイリストの再生を開始する。これにより起動属性がＡｕｔｏＰｌａｙに設定されたプレイリストは、タイトル分岐と共に自動的に起動されることになる。【００８２】  『Ｐｒｅｓｅｎｔ』とは、起動属性におけるＰｒｅｓｅｎｔ同様、継続属性であり、分岐元ｔｉｔｌｅにおけるＰＬの状態を継続することを示す。また対応するプレイリストを再生してよいことを示す属性である。例えば連続して再生される２つのＴｉｔｌｅがあり、分岐元Ｔｉｔｌｅ側のプレイリスト管理テーブルでは、あるプレイリストの再生属性がＡｕｔｏＰｌａｙに設定され、分岐先Ｔｉｔｌｅ側のプレイリスト管理テーブルでは、そのプレイリストの再生属性がＰｒｅｓｅｎｔに設定されているものとする。ここでプレイリストの再生時間が２時間長であり、このうち１時間が経過した時点で分岐が発生したとする。この場合分岐先Ｔｉｔｌｅでは、再生属性がＰｒｅｓｅｎｔに設定されているので、分岐先Ｔｉｔｌｅにおいて、そのプレイリストは、１時間という再生済み区間の直後から、再生されることになる。このように再生属性をＰｒｅｓｅｎｔに設定しておけば、Ｔｉｔｌｅ間の分岐があった場合でも、プレイリスト再生をその残りの部分から開始することができる。これにより分岐し合う一連のＴｉｔｌｅにおいて、共通のプレイリストを再生するという”タイトル間におけるプレイリスト再生の共通化”を容易に実現することができる。また分岐先タイトルが複数ある場合、これら複数タイトルの再生属性を何れもＰｒｅｓｅｎｔにしておけば、複数のうちどれに分岐したとしても、１つの共通のプレイリスト再生を継続させることができる。【００８３】  尚Ｔｉｔｌｅの境界は、シームレス再生を保証しなくてもよいので、上述したように複数Ｔｉｔｌｅ間で１つのプレイリストを再生しようとする場合、分岐前後でプレイリスト再生を中断させることは許容される。
また、再生属性が「Ｐｒｅｓｅｎｔ」である場合、この再生属性が付与されたプレイリストは、他のアプリケーションからの再生要求により再生されることになる。アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、起動中のアプリケーションから、プレイリストの再生要求があると、要求を受けたプレイリストのＰＬ＿ｉｄ＿ｒｅｆが、プレイリスト管理テーブルに記述されていて、再生属性が「ＡｕｔｏＰｌａｙ」か「Ｐｒｅｓｅｎｔ」のいずれかか否かを判定する。「ＡｕｔｏＰｌａｙ」か「Ｐｒｅｓｅｎｔ」のいずれかであれば、そのプレイリストを再生する。一方、要求を受けたプレイリストのＰＬ＿ｉｄ＿ｒｅｆがプレイリスト管理テーブルに記述されていない場合、そのプレイリストを再生しない。アプリケーションの要求によるプレイリスト再生は、この「ＡｕｔｏＰｌａｙ」か「Ｐｒｅｓｅｎｔ」のいずれかが付与されたプレイリストに限られることになる。「Ｐｒｅｓｅｎｔ」は、再生属性を明示的に指定しない場合に付与されるデフォルトの再生属性であるから、あるプレイリストの再生属性が無指定「−」であるとそのプレイリストの再生属性はこのＰｒｅｓｅｎｔであることを意味する。【００８４】  図２８は、分岐先Ｔｉｔｌｅがとり得る三態様（プレイリスト管理テーブル無し（ｉ）、プレイリスト管理テーブル有りで尚且つＡｕｔｏＰｌａｙ（ｉｉ）、プレイリスト管理テーブル有りで尚且つＰｒｅｓｅｎｔ（ｉｉｉ））と、直前タイトルにおけるＰＬの状態（非再生状態、再生中状態）とがとりうる６通りの組合せを示す図である。
本図における６通りの組合せのうち、”直前状態＝非再生状態”と、”分岐先Ｔｉｔｌｅ＝プレイリスト管理テーブル有り、尚且つ、分岐先Ｔｉｔｌｅの再生属性＝ＡｕｔｏＰｌａｙ”との組合せにおいて、分岐先タイトルにおけるＰＬの再生は、自動的に開始することになる。【００８５】  また”直前状態＝再生中状態”と、”分岐先Ｔｉｔｌｅ＝プレイリスト管理テーブル無し”との組合せにおいて、分岐先タイトルでのＰＬの再生は、自動的に停止することになる。
そしてこれら２つの組合せ以外は全て、分岐元Ｔｉｔｌｅの状態を継続することになる。プレイリスト管理テーブルに基づくプレイリスト再生の開始は、分岐元タイトルにおいて非再生状態であり、分岐先タイトルにおいてＡｕｔｏＰｌａｙ属性が付与されている場合に限られるので、タイトルの分岐発生する毎に、プレイリスト再生を開始させる必要はない。タイトル間の分岐が多数発生したとしても、プレイリスト再生を開始させる回数を必要最低数にすることができる。
プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例について図２９（ａ）を参照しながら説明する。ここで想定する具体例は、２つの連続するＴｉｔｌｅ（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２）であり、そのうちｔｉｔｌｅ＃１では、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２が記述されている。ｔｉｔｌｅ＃２ではＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３が記述されている。一方、ｔｉｔｌｅ＃１のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃１が、ｔｉｔｌｅ＃２のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃２が記述されているものとする。図２９（ｂ）は、図２９（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。【００８６】  ｔｉｔｌｅ＃１においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、ｔｉｔｌｅ＃１の開始時にはａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２が自動的に起動され、ＰｌａｙＬｉｓｔ＃１の再生が自動的に開始される。
ｔｉｔｌｅ＃２においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、ｔｉｔｌｅ＃１側に記載はあるが、ｔｉｔｌｅ＃２側には記載がないａｐｐｌｉｃａｔｉｏｎ＃１の実行は停止させられる。同じくｔｉｔｌｅ＃１側に記載があるが、ｔｉｔｌｅ＃２側に記載がないＰｌａｙＬｉｓｔ＃１の再生も停止させられる。【００８７】  ｔｉｔｌｅ＃１側に記載はないが、ｔｉｔｌｅ＃２側に記載があるＰｌａｙＬｉｓｔ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３は再生及び実行が自動的に開始することになる。タイトル分岐があれば、その分岐を契機に、再生すべきプレイリストを他のプレイリストに切り換えることができる。このようにアプリケーション管理テーブル、プレイリスト管理テーブルを用いることで分岐を契機にして、プレイリスト再生を切り換えるという処理をオーサリング段階において規定しておくことができる。【００８８】  また図２９では、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３にはそれぞれ２００，１２８，２００の起動優先度が与えられている。これらの起動優先度を付与することにより、ＰｌａｙＬｉｓｔ＃１、ＰｌａｙＬｉｓｔ＃２に対する制御要求が競合した場合の調停を行わせることができる。ここでａｐｐｌｉｃａｔｉｏｎ＃１がＰｌａｙＬｉｓｔ＃１に対し早送りを命じているものとする。一方、ａｐｐｌｉｃａｔｉｏｎ＃２がポーズ要求を行ったとする。この場合、アプリケーション管理テーブルに各アプリケーションに対する起動優先度が規定されているため、この起動優先度に従って、両アプリケーションに対する調停がなされることになる。その結果、ａｐｐｌｉｃａｔｉｏｎ＃２による要求を退け、ａｐｐｌｉｃａｔｉｏｎ＃１による制御を継続するという処理をオーサリング時に規定しておくことができる。起動優先度をプレイリスト管理テーブルと併せて利用することにより、プレイリストに対する制御が競合した場合の調停さえも再生装置に行わせることができる。【００８９】  プレイリスト管理テーブル記述の他の具体例について説明する。図３０（ａ）は、プレイリスト管理テーブルの他の記述例を示す図である。本図で想定しているのは、２つの連続するタイトル（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２）において、ｔｉｔｌｅ＃１側のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃１が、再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２が記述され、ｔｉｔｌｅ＃１側のアプリケーション管理テーブルには、ＡｕｔｏＰｌａｙアプリケーションであるａｐｐｌｉｃａｔｉｏｎ＃１と、実行可能なアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２が記述されている。一方ｔｉｔｌｅ＃２側のプレイリスト管理テーブルには再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２、ＰｌａｙＬｉｓｔ＃３が記述され、アプリケーション管理テーブルには、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃３が記述されている。図３０（ｂ）は、図３０（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。ｔｉｔｌｅ＃１のアプリケーション管理テーブルには、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃１が記述されているので、ｔｉｔｌｅ＃１の開始時にはａｐｐｌｉｃａｔｉｏｎ＃１が自動起動される。一方、ｔｉｔｌｅ＃１のアプリケーション管理テーブルには、実行可能アプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２が記述されているので、ａｐｐｌｉｃａｔｉｏｎ＃１からの呼出ｙｄ１によりａｐｐｌｉｃａｔｉｏｎ＃２が起動される。【００９０】  ｔｉｔｌｅ＃２側のアプリケーション管理テーブルにおいてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２が非生存になっており、代わりにＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃３が記述されている。そのためｔｉｔｌｅ＃１−ｔｉｔｌｅ＃２の境界部では、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２を停止し、ａｐｐｌｉｃａｔｉｏｎ＃３を自動的に起動するとの処理がなされる。プレイリスト管理テーブルを参照すると、ｔｉｔｌｅ＃１側のプレイリスト管理テーブルは、ＰｌａｙＬｉｓｔ＃１、ＰｌａｙＬｉｓｔ＃２が再生可能と記述されており、そのうちＰｌａｙＬｉｓｔ＃１はＡｕｔｏＰｌａｙ属性になっている。そのためＰｌａｙＬｉｓｔ＃１は、ｔｉｔｌｅ＃１の開始時において自動的に再生される。【００９１】  ｔｉｔｌｅ＃１側のプレイリスト管理テーブルには、ＰｌａｙＬｉｓｔ＃１の他、ＰｌａｙＬｉｓｔ＃２が再生可能であると記述されているので、ａｐｐｌｉｃａｔｉｏｎ＃１はＰｌａｙＬｉｓｔ＃１の再生を停止させ、代わりにＰｌａｙＬｉｓｔ＃２の再生を要求することにより、プレイリスト交代を実行することができる。
ｔｉｔｌｅ＃２側のプレイリスト管理テーブルには、再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２、ＰｌａｙＬｉｓｔ＃３が記述されている。そしてＡｕｔｏＰｌａｙ属性が付与されたプレイリストはない。そのため、仮にｔｉｔｌｅ＃１開始時において自動再生されたＰｌａｙＬｉｓｔ＃１の再生がｔｉｔｌｅ＃２まで継続したとしても、ＰｌａｙＬｉｓｔ＃１の再生は自動的に終了することになる。【００９２】  しかしＰｌａｙＬｉｓｔ＃２再生が継続したままｔｉｔｌｅ＃２に至れば、ＰｌａｙＬｉｓｔ＃２再生はｔｉｔｌｅ＃２開始以降も継続する。ｔｉｔｌｅ＃２のプレイリスト管理テーブルには、再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２、ＰｌａｙＬｉｓｔ＃３が記述されている。そのため、ｔｉｔｌｅ＃２で実行中となるａｐｐｌｉｃａｔｉｏｎ＃３は、ＰｌａｙＬｉｓｔ＃２の再生を停止し、代わりにＰｌａｙＬｉｓｔ＃３の再生を要求することにより、再生中のプレイリストを交代させることができる。【００９３】  次にプレイリスト管理テーブルによりタイトル再生区間がどのように規定されるかを、図３１を参照しながら説明する。
図３１（ａ）は、再生属性がＡｕｔｏＰｌａｙに設定されたタイトルのタイトル再生区間を示す図である。再生属性がＡｕｔｏＰｌａｙを示すよう設定されれば、タイトルの再生開始と同時に、ＡｕｔｏＰｌａｙＰＬの再生を開始する。ここでアプリケーションが正常に動作し、正常終了したとしても、このタイトル再生区間は、ＰＬ時間軸を基準にして定められる。【００９４】  図３１（ｂ）は、プレイリスト管理テーブルにおいて再生属性が”ＡｕｔｏＰｌａｙ”を示すよう設定され、アプリケーションが異常終了した場合を示す。かかる異常終了により、どのアプリケーションも動作してない状態になるが、ＡｕｔｏＰｌａｙＰＬの再生は継続する。この場合も、ＡｕｔｏＰｌａｙＰＬのＰＬ時間軸がタイトル再生区間になる。
図３１（ｃ）は、プレイリスト管理テーブルにおいて再生属性が”ＡｕｔｏＰｌａｙ”を示すよう設定され、メインアプリの起動に失敗したケースを示す。この場合も、ＡｕｔｏＰｌａｙＰＬ再生は、アプリケーションの起動失敗とは関係なしに行われるので、ＡｕｔｏＰｌａｙＰＬの時間軸がタイトル再生区間になる。【００９５】  以上のようにプレイリスト管理テーブルの再生属性を、”ＡｕｔｏＰｌａｙ”に設定しておけば、Ｊａｖａ（登録商標）アプリケーションの起動に、５〜１０秒という時間がかかったとしても、その起動がなされている間、”とりあえず何かが写っている状態”になる。タイトル実行開始時において、アプリケーション起動に時間がかかったとしても、画面は、”とりあえず何かが写っている状態”になる。これにより、アプリケーション起動に時間がかかることによるスタートアップディレイの長期化を補うことができる。【００９６】  アプリケーション管理テーブル及びプレイリスト管理テーブルを定義することにより、タイトル再生区間の進行に沿って、Ｊａｖａ（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。以上が記録媒体についての説明である。続いて本発明に係る再生装置について説明する。【００９７】  図３２は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムＬＳＩと、ドライブ装置という２つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムＬＳＩは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、ＢＤ−ＲＯＭドライブ１、リードバッファ２、デマルチプレクサ３、ビデオデコーダ４、ビデオプレーン５、Ｐ−Ｇｒａｐｈｉｃｓデコーダ６、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン７、合成部８、フォントゼネレータ９、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０、スイッチ１１、Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン１２、合成部１３、ＣＬＵＴ部１４、ＣＬＵＴ部１５、オーディオデコーダ１６、Ｎｅｔｗｏｒｋ  Ｄｅｖｉｃｅ１７、Ｌｏｃａｌ  Ｓｔｏｒａｇｅ１８、リードバッファ１９、デマルチプレクサ２０、命令ＲＯＭ２１、ユーザイベント処理部２２、ＰＳＲセット２３、ＣＰＵ２４、シナリオメモリ２５、ローカルメモリ２６、スイッチ２７から構成される。【００９８】  先ず初めに、ＢＤ−ＲＯＭに記録されたＡＶＣｌｉｐ再生に係る構成要素（ＢＤドライブ１〜オーディオデコーダ１６）について説明する。
ＢＤ−ＲＯＭドライブ１は、ＢＤ−ＲＯＭのローディング／イジェクトを行い、ＢＤ−ＲＯＭに対するアクセスを実行する。
リードバッファ２は、ＦＩＦＯメモリであり、ＢＤ−ＲＯＭから読み出されたＴＳパケットが先入れ先出し式に格納される。【００９９】  デマルチプレクサ（Ｄｅ−ＭＵＸ）３は、リードバッファ２からＴＳパケットを取り出して、このＴＳパケットを構成するＴＳパケットをＰＥＳパケットに変換する。そして変換により得られたＰＥＳパケットのうち、ＣＰＵ２４から設定されたＰＩＤをもつものをビデオデコーダ４、Ｐ−Ｇｒａｐｈｉｃｓデコーダ６、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０、オーディオデコーダ１６のどれかに出力する。
ビデオデコーダ４は、デマルチプレクサ３から出力された複数ＰＥＳパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込む。【０１００】  ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ領域である。ビデオプレーン５における解像度は１９２０×１０８０であり、このビデオプレーン５に格納されたピクチャデータは、１６ビットのＹＵＶ値で表現された画素データにより構成される。ビデオプレーン５では、ビデオストリームにおける一フレーム毎の再生映像を、スケーリングすることができる。スケーリングとは、一フレーム毎の再生画像をビデオプレーン５全体の１／４（クオータという）、１／１（フルスケールという）のどちらかに変化させることである。かかるスケーリングを、ＢＤ−ＪモードにおいてＣＰＵ２４からの指示に従い実行するので、ビデオストリームの再生画像を、画面の隅に追いやったり、全面的に出すという画面演出が可能になる。【０１０１】  Ｐ−Ｇｒａｐｈｉｃｓデコーダ６は、ＢＤ−ＲＯＭから読み出されたプレゼンテーショングラフィクスストリームをデコードして、非圧縮グラフィクスをＰｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン７に書き込む。グラフィクスストリームのデコードにより、字幕が画面上に現れることになる。
Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン７は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。本プレーンにおける解像度は１９２０×１０８０であり、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン７中の非圧縮グラフィクスの各画素は８ビットのインデックスカラーで表現される。ＣＬＵＴ（Ｃｏｌｏｒ  Ｌｏｏｋｕｐ  Ｔａｂｌｅ）を用いてかかるインデックスカラーを変換することにより、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン７に格納された非圧縮グラフィクスは、表示に供される。【０１０２】  合成部８は、ビデオプレーン５に格納された非圧縮状態のピクチャデータ（ｉ）を、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン７の格納内容と合成する。
フォントゼネレータ９は、文字フォントを用いてｔｅｘｔＳＴストリームに含まれるテキストコードをビットマップに展開してＰｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン７に書き込む。
Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０は、ＨＤＭＶモードにおいてＢＤ−ＲＯＭ又はＬｏｃａｌ  Ｓｔｏｒａｇｅ１８から読み出されたＩＧストリームをデコードして、非圧縮グラフィクスをＩｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン１２に書き込む。【０１０３】  スイッチ１１は、フォントゼネレータ９が生成したフォント列、Ｐ−Ｇｒａｐｈｉｃｓデコーダ６のデコードにより得られたグラフィクスの何れかを選択的にＰｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン７に書き込むスイッチである。
Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン１２は、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０によるデコードで得られた非圧縮グラフィクスが書き込まれる。またＩｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン１２には、ＢＤ−Ｊモードにおいて、アプリケーションにより描画された文字やグラフィクスが書き込まれる。【０１０４】  合成部１３は、Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン１２の格納内容と、合成部８の出力である合成画像（非圧縮状態のピクチャデータと、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン７の格納内容とを合成したもの）とを合成する。かかる合成により、アプリケーションがＩ−Ｇｒａｐｈｉｃｓデコーダ１０に書き込んだ文字・グラフィクスを、非圧縮状態のピクチャデータ上にオーバレイして、表示することができる。【０１０５】  ＣＬＵＴ部１４は、ビデオプレーン５に格納された非圧縮グラフィクスにおけるインデックスカラーを、Ｙ，Ｃｒ，Ｃｂ値に変換する。
ＣＬＵＴ部１５は、Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン１２に格納された非圧縮グラフィクスにおけるインデックスカラーを、Ｙ，Ｃｒ，Ｃｂ値に変換する。
オーディオデコーダ１６は、デマルチプレクサ３から出力されたＰＥＳパケットを復号して、非圧縮形式のオーディオデータを出力する。【０１０６】  以上がＡＶＣｌｉｐ再生に係る構成要素である。続いてＢＤ−Ｊモードでの動作に係る構成要素（Ｎｅｔｗｏｒｋ  Ｄｅｖｉｃｅ１７〜Ｄｅ−ｍｕｘ２０）について説明する。
Ｎｅｔｗｏｒｋ  Ｄｅｖｉｃｅ１７は、再生装置における通信機能を実現するものであり、ＢＤ−ＪモードにおいてＵＲＬ指定がＪａｖａ（登録商標）アプリケーションから与えられれば、そのＵＲＬにあたるｗｅｂサイトとのＴＣＰコネクション、ＦＴＰコネクション等を確立する。かかるコネクション確立によりｗｅｂサイトからのダウンロードをＪａｖａ（登録商標）アプリケーションに行わせる。【０１０７】  Ｌｏｃａｌ  Ｓｔｏｒａｇｅ１８は、Ｎｅｔｗｏｒｋ  Ｄｅｖｉｃｅ１７により確立されたコネクションを通じてｗｅｂサイトからダウンロードされたコンテンツ等、ＢＤ−ＲＯＭ以外の記録媒体、通信媒体から供給されたコンテンツを、メタデータと共に格納しておくためのハードディスクである。このメタデータは、ダウンロードコンテンツをＬｏｃａｌ  Ｓｔｏｒａｇｅ１８にバインドして管理するための情報であり、このＬｏｃａｌ  Ｓｔｏｒａｇｅ１８をアクセスすることで、ＢＤ−Ｊモードにおけるアプリケーションは、ダウンロードコンテンツ長さを利用した様々な処理を行うことができる。【０１０８】  リードバッファ１９は、ＦＩＦＯメモリであり、Ｌｏｃａｌ  Ｓｔｏｒａｇｅ１８に格納されたダウンロードコンテンツに、ＳｕｂＣｌｉｐが含まれている場合、このＳｕｂＣｌｉｐを構成するＴＳパケットを、先入れ先出し式に格納する。
デマルチプレクサ（Ｄｅ−ＭＵＸ）２０は、リードバッファ１９からＴＳパケットを取り出して、ＴＳパケットをＰＥＳパケットに変換する。そして変換により得られたＰＥＳパケットのうち、所望のＰＩＤをもつものをフォントゼネレータ９、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０、オーディオデコーダ１６に出力する。【０１０９】  以上のＮｅｔｗｏｒｋ  Ｄｅｖｉｃｅ１７〜Ｄｅ−ｍｕｘ２０により、Ｊａｖａ（登録商標）アプリケーションがネットワークを通じてダウンロードしたコンテンツを、ＢＤ−ＲＯＭに記録されたコンテンツ同様再生させることができる。続いて、再生装置における統合制御を実現する構成要素（命令ＲＯＭ２１〜スイッチ２７）について説明する。
命令ＲＯＭ２１は、再生装置の制御を規定するソフトウェアを記憶している。【０１１０】  ユーザイベント処理部２２は、リモコンや再生装置のフロントパネルに対するキー操作に応じて、その操作を行うユーザイベントをＣＰＵ２４に出力する。
ＰＳＲセット２３は、再生装置に内蔵されるレジスタであり、６４個のＰｌａｙｅｒ  Ｓｔａｔｕｓ  Ｒｅｇｉｓｔｅｒ（ＰＳＲ）と、４０９６個のＧｅｎｅｒａｌ  Ｐｕｒｐｏｓｅ  Ｒｅｇｉｓｔｅｒ（ＧＰＲ）とからなる。Ｐｌａｙｅｒ  Ｓｔａｔｕｓ  Ｒｅｇｉｓｔｅｒの設定値（ＰＳＲ）のうち、ＰＳＲ４〜ＰＳＲ８は、現在の再生時点を表現するのに用いられる。【０１１１】  ＰＳＲ４は、１〜１００の値に設定されることで、現在の再生時点が属するタイトルを示し、０に設定されることで、現在の再生時点がトップメニューであることを示す。
ＰＳＲ５は、１〜９９９の値に設定されることで、現在の再生時点が属するチャプター番号を示し、０ｘＦＦＦＦに設定されることで、再生装置においてチャプター番号が無効であることを示す。【０１１２】  ＰＳＲ６は、０〜９９９の値に設定されることで、現在の再生時点が属するＰＬ（カレントＰＬ）の番号を示す。
ＰＳＲ７は、０〜２５５の値に設定されることで、現在の再生時点が属するＰｌａｙＩｔｅｍ（カレントＰｌａｙ  Ｉｔｅｍ）の番号を示す。
ＰＳＲ８は、０〜ＯｘＦＦＦＦＦＦＦＦの値に設定されることで、４５ＫＨｚの時間精度を用いて現在の再生時点（カレントＰＴＭ（Ｐｒｅｓｅｎｔａｔｉｏｎ  ＴｉＭｅ））を示す。以上のＰＳＲ４〜ＰＳＲ８により、図２１（ａ）におけるＢＤ−ＲＯＭ全体の時間軸において、現在の再生時点はどこであるかを特定することができる。【０１１３】  ＣＰＵ２４は、命令ＲＯＭ２１に格納されているソフトウェアを実行して、再生装置全体の制御を実行する。この制御の内容は、ユーザイベント処理部２２から出力されたユーザイベント、及び、ＰＳＲセット２３における各ＰＳＲの設定値に応じて動的に変化する。
シナリオメモリ２５は、カレントのＰＬ情報やカレントのＣｌｉｐ情報を格納しておくためのメモリである。カレントＰＬ情報とは、ＢＤ−ＲＯＭに記録されている複数ＰＬ情報のうち、現在処理対象になっているものをいう。カレントＣｌｉｐ情報とは、ＢＤ−ＲＯＭに記録されてい複数Ｃｌｉｐ情報のうち、現在処理対象になっているものをいう。【０１１４】  ローカルメモリ２６は、ＢＤ−ＲＯＭからの読み出しは低速である故、ＢＤ−ＲＯＭの記録内容を一時的に格納しておくためのキャッシュメモリである。かかるローカルメモリ２６が存在することにより、ＢＤ−Ｊモードにおけるアプリケーション実行は、効率化されることになる。
スイッチ２７は、ＢＤ−ＲＯＭ及びＬｏｃａｌ  Ｓｔｏｒａｇｅ１８から読み出された各種データを、リードバッファ２、リードバッファ１９、シナリオメモリ２５、ローカルメモリ２６のどれかに選択的に投入するスイッチである。【０１１５】  以上が、本実施形態に係る再生装置のハードウェア構成である。続いて本実施形態に係る再生装置のソフトウェア構成について説明する。
図３３は、ＲＯＭ２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。本図に示すように、再生装置のレイア構成は、以下のａ），ｂ），ｃ）からなる。つまり、
ａ）ＢＤ  Ｐｌａｙｅｒ  Ｄｅｖｉｃｅの第１階層、
ｂ）ＢＤ  Ｐｌａｙｅｒ  Ｍｏｄｅｌの第２階層、
ｃ）Ａｐｐｌｉｃａｔｉｏｎ  Ｒｕｎｔｉｍｅ  Ｅｎｖｉｒｏｍｅｎｔの第３階層からなる。
これらの階層のうち図３２に示した再生装置のハードウェア構成は、第１階層に属することになる。本図の第１階層”ＢＤ  Ｐｌａｙｅｒ  Ｄｅｖｉｃｅ”には、図３２に示したハードウェア構成のうちビデオデコーダ４、Ｐ−Ｇｒａｐｈｉｃｓデコーダ６、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０、オーディオデコーダ１６からなる”デコーダ”と、ビデオプレーン５、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン７、Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン１２からなる”プレーン”、ＢＤ−ＲＯＭ及びそのファイルシステム、Ｌｏｃａｌ  Ｓｔｏｒａｇｅ１８及びそのファイルシステムを含む。【０１１６】  第２階層”ＢＤ  Ｐｌａｙｅｒ  Ｍｏｄｅｌ”は、以下のｂ１），ｂ２）の層からなる。つまり、
ｂ２）Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２の層
ｂ１）Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０及びＰｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１の層
からなり、自身より上位の階層に対し、ファンクションＡＰＩを提供する。
第３階層”Ａｐｐｌｉｃａｔｉｏｎ  Ｒｕｎｔｉｍｅ  Ｅｎｖｉｒｏｍｅｎｔ”は、以下のｃ１），ｃ２）の階層からなる。つまり、
ｃ１）モジュールマネージャ３４が存在する層、
ｃ２）ＨＤＭＶモジュール３３、ＢＤ−Ｊモジュール３５が存在する層
からなる。図３３のレイアモデルにおいてこのモジュールマネージャ３４が最上位の階層に位置するが、モジュールマネージャ３４は、ＨＤＭＶモジュール３３及びＢＤ−Ｊモジュール３５をバイパスしてＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に至る迂回路ｕｒ１を有している。この迂回路によりモジュールマネージャ３４は、図３３のレイアモデルにおいて”Ｌ”字形を逆さまにした形状をなし、Ｕｓｅｒ  Ｅｖｅｎｔ  Ｍａｎａｇｅｒ３７を内蔵した構成になっている。【０１１７】  ＢＤ−Ｊモジュール３５は、いわゆるＪａｖａ（登録商標）プラットフォームであり、Ｊａｖａ（登録商標）仮想マシン３８を中核にした構成になっている。Ｊａｖａ（登録商標）仮想マシン３８内のワークメモリは、様々なシステムプログラムやアプリケーションが動作している。Ｊａｖａ（登録商標）仮想マシン３８の上位に描いた、アプリケーションマネージャ３６、Ｅｖｅｎｔ  Ｌｉｓｔｎｅｒ  Ｍａｎａｇｅｒ３９（Ｄｅｆａｕｌｔ  Ｏｐｅｒａｔｉｏｎ  Ｍａｎａｇｅｒ４０）は、そうしたシステムプログラムの１つである。このうちアプリケーションマネージャ３６の中にはＰＬＭＴ  Ｐｒｃｅｓｓｏｒ４１が存在している。またＢＤ−Ｊモジュール３５と、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２との間には、Ｐｅｒｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ４２が介在している。【０１１８】  先ず初めに、第２層に属するＶｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０〜モジュールマネージャ３４について説明する。図３４は、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０〜モジュールマネージャ３４による処理を模式化した図である。
Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０は、Ｌｏｃａｌ  Ｓｔｏｒａｇｅ１８に格納されたダウンロードコンテンツを、ＢＤ−ＲＯＭにおけるディスクコンテンツと一体的に取り扱うための仮想的なファイルシステムである。ここでＬｏｃａｌ  Ｓｔｏｒａｇｅ１８に格納されたダウンロードコンテンツは、ＳｕｂＣｌｉｐ、Ｃｌｉｐ情報、プレイリスト情報を含む。このダウンロードコンテンツにおけるプレイリスト情報はＢＤ−ＲＯＭ及びＬｏｃａｌ  Ｓｔｏｒａｇｅ１８のどちらに存在するＣｌｉｐ情報であっても、指定できる点で、ＢＤ−ＲＯＭ上のプレイリスト情報と異なる。この指定にあたって、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０上のプレイリスト情報は、ＢＤ−ＲＯＭやＬｏｃａｌ  Ｓｔｏｒａｇｅ１８におけるファイルをフルパスで指定する必要はない。ＢＤ−ＲＯＭ上のファイルシステムやＬｏｃａｌ  Ｓｔｏｒａｇｅ１８上のファイルシステムは、仮想的な１つのファイルシステム（Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０）として、認識されるからである。故に、ＰｌａｙＩｔｅｍ情報におけるＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ及びＳｕｂＰｌａｙＩｔｅｍ情報のＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅは、Ｃｌｉｐ情報の格納したファイルのファイルボデイにあたる５桁の数値を指定することにより、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０、ＢＤ−ＲＯＭ上のＡＶＣｌｉｐを指定することができる。Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０を介してＬｏｃａｌ  Ｓｔｏｒａｇｅ１８の記録内容を読み出し、ＢＤ−ＲＯＭの記録内容と動的に組み合わせることにより、様々な再生のバリエーションを産み出すことができる。Ｌｏｃａｌ  Ｓｔｏｒａｇｅ１８と、ＢＤ−ＲＯＭとを組合せてなるディスクコンテンツは、ＢＤ−ＲＯＭにおけるディスクコンテンツと対等に扱われるので、本願における”ＢＤ−ＲＯＭ”は、Ｌｏｃａｌ  Ｓｔｏｒａｇｅ１８＋ＢＤ−ＲＯＭの組合せからなる仮想的な記録媒体をも含むことにする。【０１１９】  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１は、ＡＶ再生ファンクションを実行する。再生装置のＡＶ再生ファンクションとは、ＤＶＤプレーヤ、ＣＤプレーヤから踏襲した伝統的な機能群であり、再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（Ｐａｕｓｅ  Ｏｎ）、一時停止の解除（Ｐａｕｓｅ  Ｏｆｆ）、Ｓｔｉｌｌ機能の解除（ｓｔｉｌｌ  ｏｆｆ）、速度指定付きの早送り（Ｆｏｒｗａｒｄ  Ｐｌａｙ（ｓｐｅｅｄ））、速度指定付きの巻戻し（Ｂａｃｋｗａｒｄ  Ｐｌａｙ（ｓｐｅｅｄ））、音声切り換え（Ａｕｄｉｏ  Ｃｈａｎｇｅ）、副映像切り換え（Ｓｕｂｔｉｔｌｅ  Ｃｈａｎｇｅ）、アングル切り換え（Ａｎｇｌｅ  Ｃｈａｎｇｅ）といった機能である。ＡＶ再生ファンクションを実現するべく、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１は、リードバッファ２上に読み出されたＡＶＣｌｉｐのうち、所望に時刻にあたる部分のデコードを行うよう、ビデオデコーダ４、Ｐ−Ｇｒａｐｈｉｃｓデコーダ６、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０、オーディオデコーダ１６を制御する。所望の時刻としてＰＳＲ８（カレントＰＴＭ）に示される箇所のデコードを行わせ��ことにより、ＡＶＣｌｉｐにおいて、任意の時点を再生を可能することができる。【０１２０】  再生制御エンジン（Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ（ＰＣＥ））３２は、プレイリストに対する再生制御ファンクション（ｉ）、ＰＳＲセット２３における状態取得／設定ファンクション（ｉｉ）といった諸機能を実行する。ＰＬに対する再生制御ファンクションとは、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１が行うＡＶ再生ファンクションのうち、再生開始や再生停止を、カレントＰＬ情報及びＣｌｉｐ情報に従って行わせることをいう。これら機能（ｉ）〜（ｉｉ）は、ＨＤＭＶモジュール３３〜ＢＤ−Ｊモジュール３５からのファンクションコールに応じて実行する。【０１２１】  つまり、ＰＬ再生を命じるファンクションコールがあれば、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２は、再生が命じられたプレイリスト情報を、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０経由でＢＤ−ＲＯＭ又はＬｏｃａｌ  Ｓｔｏｒａｇｅ１８から読み出す。そのように読み出されたプレイリスト情報内のＰｌａｙＩｔｅｍ情報を参照し、そのＰｌａｙＩｔｅｍ情報においてＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅに記載されているＣｌｉｐ情報を、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０経由でＢＤ−ＲＯＭ又はＬｏｃａｌ  Ｓｔｏｒａｇｅ１８から読み出す。図３４における◎１，２，３，４は、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０経由のプレイリスト情報読み出し（◎１）、プレイリスト情報を構成するＰｌａｙＩｔｅｍ情報の解読（◎２）、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０経由のＣｌｉｐ情報読み出し（◎３）、Ｃｌｉｐ情報の解読（◎４）を模式化したものである。以上の過程を経てＣｌｉｐ情報、プレイリスト情報が解読されれば、ＡＶＣｌｉｐを構成するＴＳパケットを、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０を通じてＰｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１に引き渡す。このようにしてＰｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１にＴＳパケットが順次渡れば、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１はＡＶＣｌｉｐを構成するＴＳパケットをデコーダに出力して、プレーンに表示させる。図中の☆１，２，３，４は、ＡＶＣｌｉｐを構成するＴＳパケットの読み出し（☆１，２）、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０からＰｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１へのＴＳパケット引き渡し（☆３）、デコーダへのＴＳパケット投入（☆４）、デコーダから各種プレーンへのデコード結果出力（☆５）を模式的に示している。【０１２２】  ＨＤＭＶモジュール３３は、ＨＤＭＶモードの実行主体であり、ｍｏｂｊ＿ｉｄにより分岐先ＭｏｖｉｅＯｂｊｅｃｔを指定したａｃｔｉｖａｔｅ要求（ａｃｔｉｖａｔｅ（ｍｏｂｊ＿ｉｄ））がモジュールマネージャ３４からなされれば、ＭｏｖｉｅＯｂｊｅｃｔ（ｍｏｂｊ＿ｉｄ）をローカルメモリ２６に読み出して、このＭｏｖｉｅ  Ｏｂｊｅｃｔに記述されたナビゲーションコマンドを解読し、解読結果に基づきＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に対するファンクションコールを実行する。図２８において▽２，▽３，▽４が付された矢���は、モジュールマネージャ３４によるａｃｔｉｖａｔｅ（ｍｏｂｊ＿ｉｄ）（２）、ＭｏｖｉｅＯｂｊｅｃｔに記述されたナビゲーションコマンドの解読（３）、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に対するファンクションコール（４）を、模式的に示している。【０１２３】  モジュールマネージャ３４は、ＢＤ−ＲＯＭから読み出されたＩｎｄｅＸ．ｂｄｍｖを保持して、分岐制御を行う。この分岐制御は、カレントタイトルを構成する動的シナリオにＴｅｒｍｉｎａｔｅイベントを発行し、分岐先タイトルを構成する動的シナリオにＡｃｔｉｖａｔｅイベントを発行することでなされる。ｔｉｔｌｅ＿ｉｄを指定したＪｕｍｐＴｉｔｌｅコマンド（ＪｕｍｐＴｉｔｌｅ（ｔｉｔｌｅ＿ｉｄ））をＭｏｖｉｅＯｂｊｅｃｔが実行した場合、カレントタイトルを構成するＭｏｖｉｅＯｂｊｅｃｔにＴｅｒｍｉｎａｔｅイベントを発行し、ｔｉｔｌｅ＿ｉｄに対応するタイトルを構成するＭｏｖｉｅ  Ｏｂｊｅｃｔをａｃｔｉｖａｔｅするよう、ａｃｔｉｖａｔｅ（ｍｏｂｊ＿ｉｄ）イベントが発行する。図中の▽０，▽１，▽２が付された矢印は、ＪｕｍｐＴｉｔｌｅコマンドの実行（▽０）、モジュールマネージャ３４によるＩｎｄｅｘ．ｂｄｍｖ参照（▽１）、分岐先Ｔｉｔｌｅを構成するＭｏｖｉｅ  Ｏｂｊｅｃｔのａｃｔｉｖａｔｅ（▽２）の通知を模式的に示している。ＪｕｍｐＴｉｔｌｅＡＰＩ（ＪｕｍｐＴｉｔｌｅ（ｔｉｔｌｅ＿ｉｄ））をＢＤ−Ｊ  Ｏｂｊｅｃｔがコールした場合も同様であり、カレントタイトルを構成するＢＤ−Ｊ  ＯｂｊｅｃｔにＴｅｒｍｉｎａｔｅイベントを発行し、そのｔｉｔｌｅ＿ｉｄに対応するタイトルを構成するＢＤ−Ｊ  Ｏｂｊｅｃｔをａｃｔｉｖａｔｅするよう、ａｃｔｉｖａｔｅ（ｂｏｂｊ＿ｉｄ）をＢＤ−Ｊモジュール３５に発行する。【０１２４】  以上がＰｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１〜モジュールマネージャ３４についての説明である。続いてアプリケーションマネージャ３６について、図３５を参照しながら説明する。図３５は、アプリケーションマネージャ３６を示す図である。
アプリケーションマネージャ３６は、タイトル分岐が発生する度に、分岐前タイトルでは実行されていないが、新たなタイトルではＡｕｔｏＲｕｎの起動属性を有するアプリケーションを起動するようＪａｖａ（登録商標）仮想マシン３８に指示する。それと共に、分岐前タイトルでは実行されていたが、新たなタイトルを生存区間としないアプリケーションを終了させる。これら起動制御及び終了制御は、カレントＢＤ−Ｊ  Ｏｂｊｅｃｔにおけるアプリケーション管理テーブルを参照した上でなされる。ここでタイトル分岐があった場合、モジュールマネージャ３４からａｃｔｉｖａｔｅ（ｂｏｂｊ＿ｉｄ）が通知される。かかる通知があれば、ｂｏｂｊ＿ｉｄに対応するＢＤ−Ｊ  ＯｂｊｅｃｔをカレントＢＤ−Ｊ  Ｏｂｊｅｃｔにして、そのカレントＢＤ−Ｊ  Ｏｂｊｅｃｔにおけるアプリケーション管理テーブルを参照することで、上述した自動起動すべきアプリケーション及び自動終了すべきアプリケーションを特定する。図３５における☆０，☆１，☆２，☆３は、ＴｉｔｌｅＪｕｍｐの発生（☆０）、ａｃｔｉｖａｔｅ（ｂｏｂｊ＿ｉｄ）の通知（☆１）、アプリケーション管理テーブル参照（☆２）、Ｊａｖａ（登録商標）仮想マシン３８に対するアプリケーション起動指示（☆３）という一連の過程を模式化して示す。この起動指示によりＪａｖａ（登録商標）仮想マシン３８は、ローカルメモリ２６からワークメモリにｘｌｅｔプログラムを読み出す（☆４，５）。【０１２５】  以上がアプリケーションマネージャ３６についての説明である。続いてＵｓｅｒ  Ｅｖｅｎｔ  Ｍａｎａｇｅｒ３７〜Ｄｅｆａｕｌｔ  Ｏｐｅｒａｔｉｏｎ  Ｍａｎａｇｅｒ４０について、図３６を参照しながら説明する。
Ｕｓｅｒ  Ｅｖｅｎｔ  Ｍａｎａｇｅｒ３７は、ユーザイベント処理部２２が受け付けたユーザイベントを、再生制御のためのユーザイベントと、キーイベントとに分離する。再生制御のためのユーザイベントとは、再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（Ｐａｕｓｅ  Ｏｎ）、一時停止の解除（Ｐａｕｓｅ  Ｏｆｆ）、Ｓｔｉｌｌ機能の解除（ｓｔｉｌｌ  ｏｆｆ）、速度指定付きの早送り（Ｆｏｒｗａｒｄ  Ｐｌａｙ（ｓｐｅｅｄ））、速度指定付きの巻戻し（Ｂａｃｋｗａｒｄ  Ｐｌａｙ（ｓｐｅｅｄ））、音声切り換え（Ａｕｄｉｏ  Ｃｈａｎｇｅ）、副映像切り換え（Ｓｕｂｔｉｔｌｅ  Ｃｈａｎｇｅ）、アングル切り換え（Ａｎｇｌｅ  Ｃｈａｎｇｅ）のどれかを命じるユーザイベントである。一方キーイベントとは、Ｐｏｐ−ｕｐキー，ＭｏｖｅＵｐキー，ＭｏｖｅＤｏｗｎキー，ＭｏｖｅＲｉｇｈｔキー，ＭｏｖｅＬｅｆｔキー，Ｎｕｍｅｒｉｃキーのどれかの押下を示すユーザイベントである。そして再生制御のためのユーザイベントに基づき、再生制御ファンクションをＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に実行させるためのファンクションコールを行う。このファンクションコールは、Ｕ０（Ｕｓｅｒ  Ｏｐｅｒａｔｉｏｎ）と呼ばれ、ＨＤＭＶモジュール３３、ＢＤ−Ｊモジュール３５を介することなく、モジュールマネージャ３４における迂回路にあるＵＯコントローラ３７ａを用いてなされる。これにより再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（Ｐａｕｓｅ  Ｏｎ）、一時停止の解除（Ｐａｕｓｅ  Ｏｆｆ）というような再生制御は、遅延なくなされることになる。図中の☆１，２，３は、Ｕｓｅｒ  Ｅｖｅｎｔ  Ｍａｎａｇｅｒ３７による再生制御ユーザイベントと、キーイベントとの分離（☆１，２）、再生制御ユーザイベントに基づくＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に対するファンクションコール（☆３）を模式的に示している。【０１２６】  Ｊａｖａ（登録商標）仮想マシン３８は、アプリケーションを構成するｘｌｅｔプログラムをワークメモリにロードして、ｘｌｅｔプログラムを解読し、解読結果に従って、下位層に対する制御を行う。下位層への制御は、ＪＭＦメソッドを図示しないＢＤミドルウェアに発行して、ＢＤ再生装置が対応しているファンクションコールに置き換させ、置換後のファンクションコールをＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に発行することでなされる。【０１２７】  Ｅｖｅｎｔ  Ｌｉｓｔｎｅｒ  Ｍａｎａｇｅｒ３９は、キーイベントを解析し、イベントの振り分けを行う。図中の実線矢印◇１，◇２は、このＥｖｅｎｔ  Ｌｉｓｔｎｅｒ  Ｍａｎａｇｅｒ３９による振り分けを模式的に示す。ｘｌｅｔプログラム内のＥｖｅｎｔ  Ｌｉｓｔｎｅｒに登録されたキーイベントなら、ＢＤ−Ｊ  Ｏｂｊｅｃｔにより間接参照されているｘｌｅｔプログラムにかかるイベントを振り分ける。ｘｌｅｔプログラムのＥｖｅｎｔ  Ｌｉｓｔｎｅｒには、ＪＭＦに対応したキーイベントが登録されているので、本キーイベントによりｘｌｅｔプログラムの起動が可能になる。キーイベントがＥｖｅｎｔ  Ｌｉｓｔｎｅｒ非登録のキーイベントである場合、本キーイベントをＤｅｆａｕ���ｔ  Ｏｐｅｒａｔｉｏｎ  Ｍａｎａｇｅｒ４０に振り分ける。ＢＤ−ＲＯＭ再生装置において生じるキーイベントには、Ｅｖｅｎｔ  Ｌｉｓｔｎｅｒに登録されていない多様なものがあり、これらのキーイベントが生じたとしても、漏れの無い処理を実行するためである。【０１２８】  Ｄｅｆａｕｌｔ  Ｏｐｅｒａｔｉｏｎ  Ｍａｎａｇｅｒ４０は、ｘｌｅｔプログラム内のＥｖｅｎｔ  Ｌｉｓｔｎｅｒに登録されてないキーイベントがＥｖｅｎｔ  Ｌｉｓｔｎｅｒ  Ｍａｎａｇｅｒ３９から振り分けられると、そのＥｖｅｎｔ  Ｌｉｓｔｎｅｒ非登録イベントに対応するファンクションコールをＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に対して実行する。このＤｅｆａｕｌｔ  Ｏｐｅｒａｔｉｏｎ  Ｍａｎａｇｅｒ４０によるファンクションコールを模式的に示したのが、図中の矢印◇３である。【０１２９】  ＰＬＭＴプロセッサ４１は、アプリケーションマネージャ３６の一構成要素であり、モジュールマネージャ３４からａｃｔｉｖａｔｅ（ｂｏｂｊ＿ｉｄ）がなされれば、そのｂｏｂｊ＿ｉｄにより特定されるＢＤ−Ｊ  Ｏｂｊｅｃｔのプレイリスト管理テーブルを参照する。そして再生属性＝ＡｕｔｏＰｌａｙのＰＬが、そのＢＤ−Ｊ  Ｏｂｊｅｃｔのプレイリスト管理テーブル内に存在すれば、そのＡｕｔｏＰｌａｙＰＬを再生するようＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に出力する。一方、ＰＬによる再生終了を示すＮｏｔｉｆｙイベントをＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２が発行すれば、その発行された時点をＴｉｔｌｅ終了時点として解釈する。図中の△１，２は、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に対するＰｌａｙＰＬファンクションのコール（△１）、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２からのＮｏｔｉｆｙイベント出力（△２）を模式化している。【０１３０】  以上でＢＤ−Ｊモジュール３５内のレイヤ構成についての説明を終える。尚、Ｐｅｒｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ４２については、本実施形態における説明を割愛する。Ｐｅｒｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ４２の処理内容は、本実施形態よりも第３実施形態で詳述するのが望ましいからである。
＜Ｊａｖａ（登録商標）仮想マシン３８の内部構成＞
Ｊａｖａ（登録商標）仮想マシン３８の内部構成について説明する。図３７は、Ｊａｖａ（登録商標）仮想マシン３８の内部構成を示す図である。本図に示すようにＪａｖａ（登録商標）仮想マシン３８は、図３２に示したＣＰＵ２４と、ユーザクラスローダ５２、メソッドエリア５３、ワークメモリ５４、スレッド５５ａ，ｂ・・・ｎ、Ｊａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎとから構成される。【０１３１】  ユーザクラスローダ５２は、ＢＤＪＡディレクトリのＪａｖａ（登録商標）アーカイブファイルにおけるクラスファイルをローカルメモリ２６等から読み出してメソッドエリア５３に格納する。このユーザクラスローダ５２によるクラスファイル読み出しは、ファイルパスを指定した読み出しをアプリケーションマネージャ３６がユーザクラスローダ５２に指示することでなされる。ファイルパスがローカルメモリ２６を示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するＪａｖａ（登録商標）アーカイブファイルにおけるクラスファイルを、ローカルメモリ２６からワークメモリ５４に読み出す。ファイルパスがＶｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０上のディレクトリを示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するＪａｖａ（登録商標）アーカイブファイルにおけるクラスファイルを、ＢＤ−ＲＯＭ又はＬｏｃａｌ  Ｓｔｏｒａｇｅ１８からワークメモリ５４に読み出す。図３５に示したアプリケーション起動制御（☆３，４，５）は、このユーザクラスローダ５２によるクラスファイル読み出しにより実現される。読み出しが指示されたクラスファイルがローカルメモリ２６にない場合、ユーザクラスローダ５２は読み出し失敗をアプリケーションマネージャ３６に通知することになる。【０１３２】  メソッドエリア５３は、ユーザクラスローダ５２によりローカルメモリ２６から読み出されたクラスファイルが格納される。
ワークメモリ５４は、いわゆるヒープエリアであり、様々なクラスファイルのインスタンスが格納される。図３３に示したアプリケーションマネージャ３６、Ｅｖｅｎｔ  Ｌｉｓｔｎｅｒ  Ｍａｎａｇｅｒ３９は、このワークメモリ５４に常駐するレジデントアプリケーションである。ワークメモリ５４には、これらレジデント型のインスタンスの他に、メソッドエリア５３に読み出されたクラスファイルに対応するインスタンスが格納される。このインスタンスが、アプリケーションを構成するｘｌｅｔプログラムである。かかるｘｌｅｔプログラムをワークメモリ５４に配置することによりアプリケーションは実行可能な状態になる。図３３、図３５、図３６のレイアモデルでは、このワークメモリ５４をＪａｖａ（登録商標）仮想マシン３８上位層に記述していた。これはワークメモリ５４上のアプリケーションマネージャ３６及びＥｖｅｎｔ  Ｌｉｓｔｎｅｒ  Ｍａｎａｇｅｒ３９を、わかり易く記述するための配慮に過ぎない。アプリケーションマネージャ３６及びＥｖｅｎｔ  Ｌｉｓｔｎｅｒ  Ｍａｎａｇｅｒ３９はインスタンスとしてスレッド５５ａ，ｂ・・・ｎにより実行されるというのが、現実的な記述になる。【０１３３】  スレッド５５ａ，ｂ・・・ｎは、ワークメモリ５４に格納されたメソッドを実行する論理的な実行主体であり、ローカル変数や、オペランドスタックに格納された引数をオペランドにして演算を行い、演算結果を、ローカル変数又はオペランドスタックに格納する。図中の矢印ｋｙ１，ｋｙ２，ｋｙｎは、ワークメモリ５４からスレッド５５ａ，ｂ・・・ｎへのメソッド供給を象徴的に示している。物理的な実行主体がＣＰＵ唯１つであるのに対し、論理的な実行主体たるスレッドは、最大６４個Ｊａｖａ（登録商標）仮想マシン３８内に存在し得る。この６４個という数値内において、スレッドを新規に作成することも、既存のスレッドを削除することも可能であり、スレッドの動作数は、Ｊａｖａ（登録商標）仮想マシン３８の動作中において増減し得る。スレッドの数は適宜増やすことができるので、複数スレッドにより１つのインスタンスの並列実行を行い、インスタンスの高速化を図ることもできる。本図ではＣＰＵ２４と、スレッドとの対応関係は、１対多の関係にしているが、ＣＰＵが複数ある場合、ＣＰＵとスレッドとの対応関係は多対多の関係になりうる。スレッド５５ａ，ｂ・・・ｎによるメソッド実行は、メソッドをなすバイトコードを、ＣＰＵ２４のネイティブコードに変換した上、ＣＰＵ２４に発行することでなされる。このネイティブコード変換については、本願の主眼から外れるため、説明を省く。【０１３４】  Ｊａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎは、スレッド５５ａ，ｂ・・・ｎと１対１の比率で存在しており、プログラムカウンタ（図中のＰＣ）と、１つ以上のフレームとを内部に持つ。”プログラムカウンタ”は、インスタンスにおいて、現在どの部分が実行されているかを示す。”フレーム”はメソッドに対する１回のコールに対して割り当てられたスタック式の領域であり、その１回のコール時の引数が格納される”オペランドスタック”と、コールされたメソッドが用いる”ローカル変数スタック（図中のローカル変数）”から��る。フレームは、コールが１回なされる度にＪａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎ上に積み上げられるのだから、あるメソッドが自身を再帰的に呼び出す場合も、このフレームは、１つ積み上げられることになる。ＪＭＦプレーヤインスタンスの再生メソッドをコールする場合、又は、ＪｕｍｐＴｉｔｌｅＡＰＩのコールをコールする場合にも、これらのコールに対応するフレームがＪａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎ上に積み上げられる。そしてこれらのフレームのオペランドスタックには、再生メソッドによる再生の対象となるＭＰＬＳファイルのファイル名、又は、ＪｕｍｐＴｉｔｌｅＡＰＩのコールのジャンプ先を示すｔｉｔｌｅ＿ｉｄ等が引数として格納される。【０１３５】  以上のように構成されたＪａｖａ（登録商標）仮想マシン３８の内部構成において、アプリケーションマネージャ３６及びその構成要素たるＰＬＭＴ  Ｐｒｃｅｓｓｏｒ４１がどのような処理を行うかを、詳細に説明する。
ｂｏｂｊ＿ｉｄのＢＤ−Ｊ  Ｏｂｊｅｃｔのａｃｔｉｖａｔｅを要求するイベント（ａｃｔｉｖａｔｒｅｄ［ｂｏｂｊ＿ｉｄ］）をモジュールマネージャ３４が出力すれば、ワークメモリ５４上の一インスタンスであるアプリケーションマネージャ３６は、そのｂｏｂｊ＿ｉｄを有するＢＤ−Ｊ  Ｏｂｊｅｃｔを新たにカレントＢＤ−Ｊ  Ｏｂｊｅｃｔにする。そしてアプリケーションマネージャ３６は、分岐元タイトルにおける実行状態と、カレントＢＤ−Ｊ  Ｏｂｊｅｃｔにおけるアプリケーションの起動属性とを照合して、自動起動すべきアプリケーション（ｉ）、自動終了すべきアプリケーション（ｉｉ）を判定する。【０１３６】  （ｉ）自動起動すべきアプリケーションの判定は、分岐前タイトルにおいて非実行状態であるが、カレントＢＤ−Ｊ  ＯｂｊｅｃｔにおいてＡｕｔｏＰｌａｙ属性を有するアプリケーションのａｐｌｉ＿ｉｄ＿ｒｅｆをカレントＢＤ−Ｊ  Ｏｂｊｅｃｔのアプリケーション管理テーブルから検索することでなされる。かかるａｐｌｉ＿ｉｄ＿ｒｅｆがあれば、アプリケーション［ａｐｌｉ＿ｉｄ＿ｒｅｆ］についてのＪａｖａ（登録商標）アーカイブファイルに属するクラスファイルを、メソッドエリア５３に読み出ようユーザクラスローダ５２に指示し、そのクラスファイルに対するインスタンスをワークメモリ５４上に生成させる。こうしてカレントタイトルを生存区間としているアプリケーションが実行可能な状態になる。その後、アプリケーションにおけるメソッドをスレッド５５ａ，ｂ・・・ｎに実行させることで、アプリケーションを実行させる。【０１３７】  （ｉｉ）自動終了すべきアプリケーションの判定は、分岐元タイトルにおいて実行状態であるが、カレントタイトルにおいて生存区間を有しないアプリケーションのａｐｌｉ＿ｉｄ＿ｒｅｆをカレントＢＤ−Ｊ  Ｏｂｊｅｃｔのアプリケーション管理テーブルから検索することでなされる。かかるａｐｌｉ＿ｉｄ＿ｒｅｆがあれば、かかるアプリケーションを構成するｘｌｅｔプログラムを終了させる。これにより当該アプリケーションがワークメモリ５４上で占めていた領域や、そのアプリケーションのメソッド実行のためのＪａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎにおけるフレーム等のリソースが回収されることになる。【０１３８】  アプリケーションマネージャ３６の構成要素たるＰＬＭＴ  Ｐｒｃｅｓｓｏｒ４１は、分岐元タイトルにおける再生状態と、カレントタイトルにおけるプレイリストの再生属性とを照合して、自動再生すべきプレイリスト（ｉ）、自動終了すべきプレイリスト（ｉｉ）を判定する。
（ｉ）自動再生すべきプレイリストの判定は、分岐元タイトルにおいて非再生状態であり、カレントタイトルにおいてＡｕｔｏＰｌａｙ属性に設定されているプレイリストがプレイリスト管理テーブル内に存在するか否かの検索をプレイリスト管理テーブルに対して行うことでなされる。もしあれば、再生すべきプレイリストのＰＬ＿ｉｄ＿ｒｅｆを引数としたプレイリスト再生のファンクションコールを実行する。このコールにより、引数たるＰＬ＿ｉｄ＿ｒｅｆをオペランドスタックに格納したフレームがＪａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎに生成される。そしてプレイリスト再生のファンクションコールをスレッド５５ａ，ｂ・・・ｎが実行する。このファンクションコール実行によりＰｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１はプレイリスト再生を開始する。【０１３９】  （ｉｉ）自動終了すべきプレイリストの判定は、分岐元タイトルにおいて再生中状態であり、カレントタイトルのプレイリスト管理テーブルに記述されてないプレイリストが存在するか否かの検索をプレイリスト管理テーブルに対して行うことでなされる。もしあれば、そのプレイリストの再生停止を命じるファンクションコールを実行して、そのプレイリストの再生のためのファンクションコールに対応するフレームをＪａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎから削除する。【０１４０】  ワークメモリ５４上でのアプリケーション終了には、４つの態様がある。図３８は、アプリケーション終了の４態様を示す図である。１つ目は、リソースが枯渇したためアプリケーションマネージャ３６によるＴｅｒｍｉｎａｔｅイベント発行によりアプリケーションが終了するとの態様（☆１）、２つ目は、他のアプリケーションが発行したＴｅｒｍｉｎａｔｅイベントを、アプリケーションマネージャ３６を介して受け付けて、終了するとの態様（☆２）、３つ目は、アプリケーション管理テーブルに記述された生存区間が終了したため、アプリケーションマネージャ３６が発行したＴｅｒｍｉｎａｔｅイベントにより終了するとの態様（☆３）、４つ目は、アプリケーションが自身の終了プロセスを起動することにより終了するとの態様である（☆４）。これらの４つの態様のうち３つものが、アプリケーションマネージャ３６によりなされているため、アプリケーションマネージャ３６は、アプリケーション動作制御の中枢を掌握することがわかる。仮に、Ｔｅｒｍｉｎａｔｅイベントの発行でもアプリケーションが終了しない場合、アプリケーションマネージャ３６は、そのアプリケーションを強制終了させて、使用しているリソースを明け渡させることができる。強権的なリソース解放を担うのも、アプリケーションマネージャ３６の１つの特徴である。【０１４１】  以上がＢＤ−Ｊモジュール３５の構成要素である。
（フローチャートの説明）
以上のアプリケーションマネージャ３６についての説明は、その概要に触れたに過ぎない。アプリケーションマネージャ３６の処理を更に詳しく示したのが図３９、図４０のフローチャートである。以降、これらのフローチャートを参照してアプリケーションマネージャ３６の処理手順についてより詳しく説明する。【０１４２】  図３９は、アプリケーションマネージャ３６による処理手順を示す図である。本図における処理手順は、ステップＳ１−ステップＳ２−ステップＳ３−ステップＳ４からなるメインループを有している。ステップＳ１は、ＴｉｔｌｅＪｕｍｐがなされたか否かの判定であり、もしなされればＴｉｔｌｅ切り換えを行い（ステップＳ７）、分岐先Ｔｉｔｌｅのアプリケーション管理テーブルを参照することにより、分岐元Ｔｉｔｌｅで起動中で、分岐先Ｔｉｔｌｅで非生存のアプリケーションを終了させる（ステップＳ８）。一方、分岐先Ｔｉｔｌｅのプレイリスト管理テーブルを参照することにより、分岐元Ｔｉｔｌｅで再生中で、分岐先Ｔｉｔｌｅで非生存となるＰＬの再生を停止させる（ステップＳ９）。【０１４３】  そして、分岐元Ｔｉｔｌｅでは非再生状態、分岐先ＴｉｔｌｅにおいてＡｕｔｏＰｌａｙ属性になっているＰＬをＰＬＭＴ  Ｐｒｃｅｓｓｏｒ４１に判定させる（ステップＳ１０）。もし存在すればＰＬＭＴ  Ｐｒｃｅｓｓｏｒ４１はＡｕｔｏＰｌａｙＰＬを再生するようＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に指示する（ステップＳ１１）。もし存在しないなら、ＡｕｔｏＰｌａｙＰＬは再生しない。
続くステップＳ１２〜ステップＳ１８からなる一連の手順は、分岐先Ｔｉｔｌｅを生存区間とするアプリケーションの起動を実現する。この手順は、ＡｕｔｏＲｕｎアプリケーションに対して起動指示を行い（ステップＳ１４）、起動に成功すれば（ステップＳ１５でＹｅｓ）、ＡｕｔｏＰｌａｙＰＬの再生画像をクオータ（１／４）に変換する（ステップＳ１８）という手順を実現するものである。【０１４４】  一方このステップＳ１５がＮｏであればステップＳ１４〜ステップＳ１７からなるループ処理を実行することになる。本ループ処理における制御変数は、再起動カウンタである。再起動カウンタは、アプリケーションの再起動回数を規定するカウンタである。本再起動カウンタは、ステップＳ１２においてリセットされ、ステップＳ１６において、０か否かの判定がなされる。０でない場合、ステップＳ１７において再起動カウンタはデクリメントされる。以上のステップＳ１４、ステップＳ１５、ステップＳ１６、ステップＳ１７からなるループ処理により、再起動カウンタが０でない限り、ＡｕｔｏＲｕｎアプリケーションの起動は繰り返されることになる。かかる繰り返しにより、アプリケーションの起動が保証されることになる。【０１４５】  ステップＳ２は、メインとなるアプリケーションが実行されてない状態かどうかの判定であり、もしそうであれば、ステップＳ５の判定を行う。ステップＳ５は、アプリケーションが正常終了したかの判定である。もし異常終了していればステップＳ１９、ステップＳ２０の処理を実行する。正常終了していればステップＳ１９〜ステップＳ２０を実行せず、ステップＳ１〜ステップＳ４からなるメインループに戻る。【０１４６】  ステップＳ１９は、ＡｕｔｏＰｌａｙＰＬの再生中であるか否かの判定であり、もし再生中なら、ＡｕｔｏＰｌａｙＰＬの再生画像をフルスクリーン化するようＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に指示する（ステップＳ２０）。その後、ステップＳ１６に移行する。ステップＳ１６への移行により、異常終了時においてもステップＳ１４〜ステップＳ１７からなるループ処理が実行されることになる。これによりステップＳ１２において設定された再起動カウンタの回数が０になるまで、アプリケーションの再起動は繰り返されることになる。【０１４７】  ステップＳ４は、ＢＤドライブ１にＢＤ−ＲＯＭが存在しているか否かの判定であり、もしＢＤ−ＲＯＭが存在しなければ、全てのアプリケーションに対し、終了指示を発する（ステップＳ６）。
図４０は、プレイリスト管理テーブル、アプリケーション管理テーブルの具体例を示す。図４０の第１段目は、Ｔｉｔｌｅの再生映像を示し、第２段目は、Ｔｉｔｌｅの時間軸を示す。第３段目はＰＬ再生の進行、第４段目は、アプリケーション実行を示す。第４段目においてａｐｐｌｉｃａｔｉｏｎ＃１は、Ｔｉｔｌｅの開始と共に起動されており、その後、時点ｔ１において動作状態になる。一方ＰｌａｙＬｉｓｔ＃１は、Ｔｉｔｌｅの開始と共に再生が開始されている。Ｐｌａｙｌｉｓｔ＃１の再生は、Ｔｉｔｌｅの開始と同じ時点に開始されているので、第１段目の左側に示すように、Ｔｉｔｌｅの再生開始直後から、アプリケーションが動作状態になるまでのスタートアップディレイにおいて、プレイリストの再生画像ｇｊ１がフルスクリーン表示される。一方、ａｐｐｌｉｃａｔｉｏｎ＃１は、時点ｔ１で動作状態になるので、ＰＬ再生画像を子画面、アプリケーションの実行画像を親画面にした合成画像ｇｊ２が時点ｔ１において表示されることになる。アプリケーションの実行画像は、Ｓｔａｒｔボタン，ｃｏｎｔｉｎｕｅボタン，ＰＯＷＥＲインディケータを配置したゲーム用の画面であり、Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン１２に対する描画処理をＪａｖａ（登録商標）アプリケーションが実行することでなされる。Ｊａｖａ（登録商標）アプリケーションがかかる描画処理を行うには、グラフィクス描画や文字描画のためのライブラリが必要になる。以降アプリケーション実行とＰＬ再生とが同時になされる限り、親子画面の表示は継続する。【０１４８】  その後ａｐｐｌｉｃａｔｉｏｎ＃１が異常終了してしまい、時点ｔ２においてアプリケーションマネージャ３６がこの異常終了を検知したとする。矢印ｂｒ１は、この検知を象徴的に示す。そうするとステップＳ２０においてアプリケーションマネージャ３６は、ＰＬの再生画像をフルスクリーンにする。図中の時点ｔ３は、このフルスクリーン化のタイミングを示す。図中の第１段目の右側に、フルスクリーン化で得られた画像ｇｊ３を示す。【０１４９】  以上のように本実施形態によれば、プレイリスト管理テーブルの再生属性を、”ＡｕｔｏＰｌａｙ”に設定しておくことにより、Ｊａｖａ（登録商標）アプリケーションが動作状態になるまで５〜１０秒という時間がかかったとしても、その間、”とりあえず何かが写っている状態”になる。この”とりあえず何かが写っている状態”によりタイトル実行開始時のスタートアップディレイを補うことができる。【０１５０】  また、アプリケーションの起動に失敗したり、アプリケーションが異常したとしても、プレイリスト管理テーブルで規定されたプレイリストの再生を継続することにより、”とりあえず何かが写っている状態”になる。これにより、装置がブラックアウトしてしまうという最悪ケースを回避することができるので、装置を製造するメーカに、最低限度の安心感を与えることができる。【０１５１】  （第２実施形態）
第２実施形態は、エラー終了時におけるリカバリー処理を、オーサリング時に規定しておくための改良に関する。かかるリカバリー処理を規定するため、本実施形態に係る記録媒体では、１つのＢＤ−Ｊ  Ｏｂｊｅｃｔ内にエラー管理テーブルを設けている。図４１（ａ）は、第２実施形態に係るＢＤ−Ｊ  Ｏｂｊｅｃｔの内部構成を示す図である。本図に示すように、ＢＤ−Ｊ  Ｏｂｊｅｃｔにはアプリケーション管理テーブル、プレイリスト管理テーブルの他に、エラー管理テーブル（Ｅｒｒｏｒ  Ｍａａｎｇｅｍｅｎｔ  Ｔａｂｌｅ［ｂｏｂｊ＿ｉｄ］）が追加されている。図４１（ｂ）は、エラー管理テーブルの内部構成を示す図である。本図に示すように、エラー管理テーブルは、Ｎｕｍｂｅｒ＿ｏｆ＿ｒｅｃｏｖｅｒｙ個のリカバリー情報（ｒｅｃｏｖｅｒｙ（））からなる。識別子ｒｅｃｏｖｅｒｙ＿ｉｄで特定される、任意のリカバリー情報の内部構成を、引き出し線ｅｍ１にてクローズアップしている。この引き出し線によるとリカバリー情報は、リカバリー情報に対応するアプリケーションの識別子を、一意に特定する参照値『Ａｐｌｉ＿ｉｄ＿ｒｅｆ』、『Ｒｅｓｔａｒｔ＿Ａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇ』、『Ｃｏｎｔｉｎｕｏｕｓ＿Ｐｌａｙｂａｃｋ＿ｆｌａｇ』、『Ｓｅｌｅｃｔ＿Ｔｉｔｌｅ＿ｆｌａｇ』、『Ｎｏｔｉｆｙ＿Ｅｖｅｎｔ＿ｆｌａｇ』、『Ｒｅｂｏｏｔ＿ｆｌａｇ』という５つのｆｌａｇからなる。図４２は、これら５つのフラグの意味内容を示す。以降エラー管理テーブルにおける各フラグの意味内容について説明する。【０１５２】  『Ｒｅｓｔａｒｔ＿Ａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇ』は、０に設定されることにより異常終了時に再起動しないことを示す。０以外の整数値ｎに設定されることにより、再起動をｎ回繰り返すことを示す。デフォルト値として本ｆｌａｇは、０に設定されている。
『Ｃｏｎｔｉｎｕｏｕｓ＿Ｐｌａｙｂａｃｋ＿ｆｌａｇ』は、０に設定されることにより異常終了時にＰＬ再生を継続しないことを示す。整数値１に設定されることにより、異常終了時にＰＬ再生を継続することを示し、２に設定されることにより、異常終了時に、フルスクリーン・一倍速でＰＬ再生を継続することを示す。デフォルト値として本ｆｌａｇは、０に設定されている。【０１５３】  『Ｓｅｌｅｃｔ＿Ｔｉｔｌｅ＿ｆｌａｇ』は、０に設定されることにより異常終了時にＴｉｔｌｅ分岐を行わないことを示す。０以外の整数値ｎに設定された場合、Ｔｉｔｌｅ番号ｎにより特定されるＴｉｔｌｅにＪｕｍｐすることを示す。デフォルト値として本ｆｌａｇは、０に設定されている。
『Ｎｏｔｉｆｙ＿Ｅｖｅｎｔ＿ｆｌａｇ』は、０に設定されることにより異常終了時に、イベントを出力しないことを示す。０以外の整数値ｎに設定された場合、イベント番号ｎのイベントを出力することを示す。デフォルト値として本ｆｌａｇは、１に設定されている。【０１５４】  『Ｒｅｂｏｏｔ＿ｆｌａｇ』は、０に設定されることにより異常終了時に、再生装置のブートストラップを行わないことを示す。整数値１に設定された場合、ブートストラップを行うことを示す。
以上のｆｌａｇが存在するので、アプリケーションが異常終了した際、どのようなリカバリ処理を実行するかをオーサリング時に予め規定しておくことができる。エラー管理テーブル記述の具体例について説明する。図４３（ａ）は、エラー管理テーブルが記述された２つのＴｉｔｌｅ（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２）を示す図である。ｔｉｔｌｅ＃１のアプリケーション管理テーブルには、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃１が記述されており、ｔｉｔｌｅ＃１のエラー管理テーブルにはこのａｐｐｌｉｃａｔｉｏｎ＃１が異常終了した際に用いられるべきＲｅｃｏｖｅｒｙ情報が記述されている。ｔｉｔｌｅ＃１のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃１が記述されている。【０１５５】  ｔｉｔｌｅ＃２側のアプリケーション管理テーブルにはＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２が記述されており、ｔｉｔｌｅ＃２側のエラー管理テーブルには、このａｐｐｌｉｃａｔｉｏｎ＃２に対するＲｅｃｏｖｅｒｙ情報が記述されている。
図４３（ｂ）は、図４３（ａ）のように記載されたアプリケーション管理テーブル、エラー管理テーブルに基づくアプリケーション実行及びプレイリスト再生の進行を示す。ａｐｐｌｉｃａｔｉｏｎ＃１についてのＲｅｃｏｖｅｒｙ情報は、Ｃｏｎｔｉｎｕｏｕｓ＿Ｐｌａｙｂａｃｋ＿Ｆｌａｇ＝２と記述されているため、ａｐｐｌｉｃａｔｉｏｎ＃１の異常終了時にはプレイリスト再生が一倍速、フルスクリーンにより継続することになる。【０１５６】  一方ａｐｐｌｉｃａｔｉｏｎ＃２についてのＲｅｃｏｖｅｒｙ情報は、Ｎｏｔｉｆｙ＿Ｅｖｅｎｔ＿Ｆｌａｇ＝２と記述されているので、ａｐｐｌｉｃａｔｉｏｎ＃２の異常終了には、番号＝２のイベントを出力することになる。
以上のようなＲｅｃｏｖｅｒｙ情報の記述により、アプリケーションが異常終了した際の処理を、Ｔｉｔｌｅ毎、アプリケーション毎に変化させることができる。
ＢＤ−Ｊ  Ｏｂｊｅｃｔにおいて上述したエラー管理テーブルが追加されたため、本実施形態に係るアプリケーションマネージャ３６は図４４、図４５のフローチャートに従って処理を行う。図４４は、第２実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。本フローは、図３９同様、ステップＳ１〜ステップＳ４をメインループにしている。このメインアプリにおいてタイトルが選択された際の処理は、ステップＳ２１〜ステップＳ２７に示されるものとなる。【０１５７】  ステップＳ２１では、分岐先Ｔｉｔｌｅにプレイリスト管理テーブルが存在するか否かの判定をＰＬＭＴ  Ｐｒｃｅｓｓｏｒ４１に行わせる。もし存在すれば、分岐元Ｔｉｔｌｅにおいて非再生状態だが、分岐先ＴｉｔｌｅにおいてＡｕｔｏＰｌａｙ属性になっているＰＬの再生をＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に開始させて（ステップＳ２２）、その再生が成功したかどうかを判定する（ステップＳ２３）。もし成功すればステップＳ２５〜ステップＳ２８の処理を行う。成功しなければ図４５のフローチャートに移行する。【０１５８】  分岐先Ｔｉｔｌｅにプレイリスト管理テーブルがない場合は、分岐元Ｔｉｔｌｅにおいて再生状態であったＰＬの再生をＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に停止させて（ステップＳ２４）、ステップＳ２５〜ステップＳ２８の処理を行う。
ステップＳ２５は、分岐先Ｔｉｔｌｅにアプリケーション管理テーブルが存在するか否かの判定である。もし存在すれば、分岐先アプリケーションにおけるＡｕｔｏＲｕｎアプリケーションを起動して（ステップＳ２６）、ステップＳ２７において起動に成功したか否かを判定する。成功すればステップＳ１〜ステップＳ４のループ処理に戻る。成功しなければ図４５のフローチャートに移行する。【０１５９】  図４５のフローチャートは、アプリケーションが異常終了した場合の処理手順を示すフローチャートである。ステップＳ３０は、異常終了したアプリケーションが属するＴｉｔｌｅに、エラー管理テーブルが存在するか否かの判定であり、もし存在しなければステップＳ１〜ステップＳ４からなるループ処理に戻る。
存在すれば、ステップＳ３１〜ステップＳ４４の処理を経た上でステップＳ１〜ステップＳ４からなるループ処理に戻る。ステップＳ３１は、エラー管理テーブルにおけるＲｅｓｔａｒｔ＿Ａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇが０でないかの判定である。０でなければ、ステップＳ４０〜ステップＳ４４からなるループ処理を実行する。このループ処理は、  Ｒｅｓｔａｒｔ＿Ａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇの値ｎを再起動カウンタに設定して（ステップＳ４０）、ステップＳ４１〜ステップＳ４４のループ処理を実行するというものである。このループ処理の制御変数は再起動カウンタであり、この再起動カウンタが０になること（ステップＳ４１でＹｅｓ）、及び、アプリケーションの起動に成功したこと（ステップＳ４４でＹｅｓ）が本ループ処理の終了条件である。本ループ処理では、これらのステップＳ４１、ステップＳ４４がＮｏである限り、再起動カウンタをデクリメントして（ステップＳ４２）、ＡｕｔｏＲｕｎアプリケーションを起動するという（ステップＳ４３）を繰り返す。こうした繰り返しにより異常終了において、アプリケーションの再起動がなされるのである。Ｒｅｓｔａｒｔ＿Ａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇが０であれば、ステップＳ３２を実行する。【０１６０】  ステップＳ３２は、Ｃｏｎｔｉｎｕｏｕｓ＿Ｐｌａｙｂａｃｋ＿ｆｌａｇが０であるか、１であるか、２であるかを判定するステップである。もし２であれば、ＡｕｔｏＰｌａｙＰＬの再生画像をフルスクリーン表示にして（ステップＳ３３）、ステップＳ１〜ステップＳ４からなるメインループに戻る。
もし１であれば、ＡｕｔｏＰｌａｙＰＬの再生画像をクオータ表示にしたまま（ステップＳ３４）、ステップＳ１〜ステップＳ４からなるメインループに戻る。【０１６１】  もし０であれば、ステップＳ３５に移行する。
ステップＳ３５は、エラー管理テーブルのｓｅｌｅｖｔ＿ｔｉｔｌｅ＿ｆｌａｇが０でないか否かの判定であり、もし０であるならステップＳ３７に移行する。０でないなら、ｓｅｌｅｖｔ＿ｔｉｔｌｅ＿ｆｌａｇの値ｎを分岐先Ｔｉｔｌｅにして（ステップＳ３６）、図４４のステップＳ７に移行する。
ステップＳ３７は、エラー管理テーブルのＮｏｔｉｆｙ＿Ｅｖｅｎｔ＿ｆｌａｇが０でないか否かの判定であり、もし０であるならステップＳ３９に移行する。０でないなら、Ｎｏｔｉｆｙ＿Ｅｖｅｎｔ＿ｆｌａｇの値ｎから特定されるイベントｎを発生して（ステップＳ３８）、図４４のステップＳ１〜ステップＳ４のメインループに移行する。ステップＳ３９は、エラー管理テーブルのＢｏｏｔ＿ｆｌａｇが０でないか否かの判定であり、もし０であるならステップＳ１〜ステップＳ４からなるメインループに移行する。０でないなら、図４４の先頭に移行して、再生装置のブートストラップを実行する。【０１６２】  以上のように本実施形態によれば、アプリケーションがエラー終了した際、再生装置はどのような処置をとるべきかを、装置側の製造者ではなく、オーサリング担当者が規定しておくことができる。
尚、エラー管理テーブルをもたないタイトルの再生時においてアプリケーションの異常終了が発生した場合に、リカバリー処理を行うようなプログラムを再生装置に組み込んでいてもよい。【０１６３】  またＲｅｓｔａｒｔ＿Ａｐｐｌｉｃａｔｉｏｎ＿Ｆｌａｇ〜Ｒｂｏｏｔ＿Ｆｌａｇのどれかを指定するような引数をＴｉｔｌｅＪｕｍｐＡＰＩに設けておき、この引数に応じたリカバリー処理をアプリケーションマネージャ３６に実行させてもよい。
（第３実施形態）
第１実施形態においてＪａｖａ（登録商標）仮想マシンにおけるＰＬ再生は、ＢＤ−Ｊ  Ｏｂｊｅｃｔ内のプレイリスト管理テーブルを用いて規定することができた。これに対し本実施形態では、アプリケーションのＪＭＦメソッドによるＰＬ再生を主眼としている。ここで問題になるのがプレイリスト管理テーブルである。つまりＰＬを再生してよいか否かは、ＢＤ−Ｊ  Ｏｂｊｅｃｔ毎のプレイリスト管理テーブルに記述されているから、あるＴｉｔｌｅでは再生可能であるが、別のＴｉｔｌｅでは再生不可能になることがある。またＰＬ再生は可能であったとしても、著作権保護の観点から、ある種のアプリケーションからの再生を禁じたい場合がある。かかるＰＬ再生の制限を実現するため、第３実施形態では、Ｐｅｒｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ４２、アプリケーションマネージャ３６が以下の処理を行う。【０１６４】  パーミッションコントローラ４２は、どれかのアプリケーションがＰＬ再生を要求した場合、そのアプリケーションと相互認証を行い、要求元アプリケーションにＰＬの再生権限があるかどうかを判定する。もしあれば、当該再生をＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に要求し、なければ不許可を示す応答イベントを要求元アプリケーションに出力する。このＰｅｒｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ４２による許否判定により、ある配給会社の配給にかかるＰＬを、別の配給会社の配給にかかるアプリケーションが要求したとしても、かかる要求を不許可にすることができる。そのため、正当権限なきアプリケーションによるＰＬの無断引用を避けることができる。許可とすべきＰＬとアプリケーションとの組合せ、不許可とすべきＰＬとアプリケーションとの組合せは、別途ＢＤ−ＲＯＭに記録されたＰｅｒｍｉｓｓｉｏｎファイルに規定されており、Ｐｅｒｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ４２による判定はこれに基づく。かかるファイルの詳細は本願の主眼ではないので説明を省略する。【０１６５】  第３実施形態においてアプリケーションマネージャ３６は、現在の再生時点において再生可能なＰＬを、アプリケーションからの要求に応じて通知する。図４６は、このアプリケーションマネージャ３６による通知処理の処理手順を示すフローチャートである。本フローチャートでは、アプリケーションの起動中において、再生可能なＰＬの通知を求める要求（ＧｅｔＰＬ）をアプリケーションが発行したか否かの監視を行っている（ステップＳ４５）。もし発行されれば、現在の再生時点が属しているＴｉｔｌｅを構成するＢＤ−Ｊ  Ｏｂｊｅｃｔに、プレイリスト管理テーブルが存在するか否かを判定する（ステップＳ４６）。ＰＬの記述があれば、プレイリスト管理テーブルに記述されたＰＬを再生可能なＰＬとして要求元のアプリケーションに通知する（ステップＳ４７）。【０１６６】  ＰＬの記述がなければ、ＰＬ再生が不可能な旨を発行元アプリケーションに通知する（ステップＳ４８）。以上が第３実施形態に係るアプリケーションマネージャ３６の処理手順である。
続いてＰＬ再生が要求された場合のアプリケーションマネージャ３６の処理について説明する。第３実施形態に係るアプリケーションマネージャ３６は、図４７のフローチャートに従って処理を行う。【０１６７】  図４７においてアプリケーションマネージャ３６は、ＰＬ再生を要求したアプリケーションが存在するか否かの判定を行っている（ステップＳ５１）。どれかのアプリケーションがＰＬ再生を要求すれば、要求元アプリケーションにＰＬ再生の権利が存在するか否かの認証をＰｅｒｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ４２に行わさせる（ステップＳ５２）。もし再生する権利があれば、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に再生開始を指示して（ステップＳ５３）、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２からのサクセス応答を待つ（ステップＳ５４）。【０１６８】  かかる再生要求があるとＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２は、プレイリスト情報の正当性をチェックする。かかる正当性チェックには、プレイリスト情報、Ｃｌｉｐ情報、ＡＶＣｌｉｐが存在するＢＤ−ＲＯＭ及びＬｏｃａｌ  Ｓｔｏｒａｇｅ１８において、正当なプレイリストを構成しているかというチェックやプレイリスト情報におけるｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅにより指定されるＣｌｉｐ情報及びＡＶＣｌｉｐがＢＤ−ＲＯＭ及びＬｏｃａｌ  Ｓｔｏｒａｇｅ１８に現存するか否かというチェックがある。ｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅにより正しいファイルが参照されていない場合、又は、ＢＤ−ＲＯＭ及びＬｏｃａｌ  Ｓｔｏｒａｇｅ１８から構成される仮想的なパッケージに矛盾があり、正しプレイリストを構成することができない場合、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２はｆａｌｓｅを示す応答を返すことになる。また要求元アプリケーションより、高い起動優先度をもつアプリケーションがそのＰＬを再生しており、ＰＬ再生を実現するリソースにおいて競合が生じている場合最もＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２は、ｆａｌｓｅを示す応答を返す。【０１６９】  以上の過程を経てサクセス応答があれば、ＰＬ再生成功を示すイベントを要求元アプリケーションに出力する（ステップＳ５５）。
サクセス応答がなければ、ＰＬ再生失敗を示すイベントを要求元アプリケーションに出力する（ステップＳ５６）。一方、ステップＳ５２において要求元アプリケーションを再生する権利が要求元アプリケーションになければ、ＰＬ再生不可を示すイベントを要求元アプリケーションに出力する（ステップＳ５７）。【０１７０】  以上のように本実施形態によれば、プレイリスト再生可否が各Ｔｉｔｌｅ毎でバラバラであり、プレイリスト再生の権限をもったアプリケーションやそうでないアプリケーション等様々なアプリケーションがあったとしても、適切なプレイリスト再生を、アプリケーションからの要求に応じて実行することができる。そのため、アプリケーション実行と、プレイリスト再生とを組み合わせた、多彩なコンテンツ表現が可能になる。【０１７１】  （第４実施形態）
第１実施形態では、Ｔｉｔｌｅ開始時において、再生を開始したいプレイリストにＡｕｔｏＰｌａｙを示す再生属性を付与して、ＡｕｔｏＰｌａｙＰＬの再生を再生装置に命じていた。これに対し本実施形態では、アンバウンダリーアプリケーションをＢＤ−ＲＯＭに記録しておき、Ｔｉｔｌｅ開始時にあたって、自動的に再生を開始すべきＴｉｔｌｅをアンバウンダリーアプリケーションに選択させる改良に関する。【０１７２】  アンバウンダリーアプリケーションは、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２のような、再生装置におけるレジデントアプリケーションと対等な立場にあるアプリケーションであり、プレイリスト管理テーブルに記述されている複数プレイリスト情報の中から再生装置側のＰＳＲ設定値に合致するものを選び、通知するとの処理をＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２からの要求に応じて実行する。【０１７３】  ＰＬ選択をアンバウンダリーアプリケーションに行わせる場合、かかる選択が必要なＴｉｔｌｅにあたっては、プレイリスト管理テーブルにおける再生属性を、全て無指定に設定しておく。これは、”全てが無指定”であることを合図に、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２にＰＬ選択をタイトルアンバウンダリーアプリケーションに要求させるためである。
このアンバウンダリーアプリケーションによる選択は、オーサリング時に規定された選択アルゴリズムに基づく。図４８（ａ）〜（ｃ）は、アンバウンダリーアプリケーションに組み込まれた選択アルゴリズムの内容を表形式に示す図である。この表は、ＰＳＲの値が取り得る値の範囲と、ＰＳＲがそれらの値になった際、再生すべきＰＬとを対応付けて示している。このうち図４８（ａ）は、パレンタルレベルに基づく選択アルゴリズムの内容を示す。ここでパレンタルレベルは、再生装置においてＰＳＲ（１４）に示されている。具体的にいうと、ＰＳＲ（１４）には、ユーザの年齢を示す整数値が設定されており、これを再生装置はパレンタルレベルとして解釈する。図４８（ａ）において、ＰＳＲ（１４）がとりうる値は、１４歳未満、１４歳以上１８歳未満、１８歳以上という３つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきＰＬが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムによる選択を行えば、ＰＳＲの設定値が１４歳未満ならＰｌａｙＬｉｓｔ＃１が、１４以上１８歳未満ならＰｌａｙＬｉｓｔ＃２が、１８歳以上ならＰｌａｙＬｉｓｔ＃３がそれぞれ選択されることになる。【０１７４】  図４８（ｂ）は、Ｌａｎｇｕｅｇｅ  ｆｏｒ  Ａｕｄｉｏに基づく選択アルゴリズムの内容を示す。ここでＬａｎｇｕｅｇｅ  ｆｏｒ  Ａｕｄｉｏは、再生装置においてＰＳＲ（１６）に示されている。具体的にいうと、ＰＳＲ（１６）には、整数値が設定されており、これを再生装置は音声再生用の言語設定として解釈する。図４８（ｂ）において、ＰＳＲ（１６）がとりうる値は、英語を示す値、日本語を示す値、その他の値という３つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきＰＬが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムによる選択を行えば、ＰＳＲ（１６）の設定値が英語を示すならＰｌａｙＬｉｓｔ＃１が、日本語を示すならＰｌａｙＬｉｓｔ＃２が、英語、日本語以外の値ならＰｌａｙＬｉｓｔ＃３がそれぞれ選択されることになる。【０１７５】  図４８（ｃ）は、Ｐｌａｙｅｒ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｆｏｒ  Ｖｉｄｅｏに基づく選択アルゴリズムの内容を示す。ここでＰｌａｙｅｒ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｆｏｒ  Ｖｉｄｅｏは、再生装置においてＰＳＲ（１４）に示されている。具体的にいうと、ＰＳＲ（１４）には、整数値が設定されており、これを再生装置は映像再生用の環境設定として解釈する。図４８（ｃ）において、ＰＳＲ（１４）がとりうる値は、解像度５２５×６００  ＴＶｓｙｓｔｅｍ  ＬｅｔｔｅｒＢｏｘ解像度５２５×６００  ＴＶｓｙｓｔｅｍ、１９２０×１０８０  ＴＶｓｙｓｔｅｍという３つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきＰＬが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムに従って選択を行えば、ＰＳＲ（１４）の設定値が解像度５２５×６００  ＴＶｓｙｓｔｅｍ  ＬｅｔｔｅｒＢｏｘを示すものならＰｌａｙＬｉｓｔ＃１が、解像度５２５×６００を示すものならＰｌａｙＬｉｓｔ＃２が、ＴＶｓｙｓｔｅｍ、１９２０×１０８０  ＴＶｓｙｓｔｅｍを示すものなら���ｌａｙＬｉｓｔ＃３がそれぞれ選択されることになる。図４８（ａ）〜（ｃ）に示したような選択アルゴリズムは、これらの図に示される条件分岐を、コンピュータ記述言語で記述することにより作成することができる。【０１７６】  以上が本実施形態に係る記録媒体の改良である。続いて本実施形態に係る再生装置の改良について説明する。本実施形態での改良点は。主としてアプリケーションマネージャ３６、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２にある。
アプリケーションマネージャ３６は、Ｔｉｔｌｅの分岐が生じ、プレイリスト管理テーブルを参照した際、そのプレイリスト管理テーブルにＡｕｔｏＰｌａｙＰＬが存在するか否かを判定する。ＡｕｔｏＰｌａｙＰＬが無ければ、プレイリスト管理テーブルをＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に引き渡して、このプレイリスト管理テーブルに記載されているＰＬのうち、どれかを自動的に再生するようＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に要求する。【０１７７】  Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２は、プレイリスト管理テーブルの引き渡しを受ければ、アンバウンダリーアプリケーションに対し、ＰＬ選択を行うよう要求する。この要求に応じてアンバウンダリーアプリケーションから再生可能なＰＬのリストが通知されれば、そのＰＬリストに記載されたＰＬのうち、ＰｌａｙＩｔｅｍから引き渡されたプレイリスト管理テーブルに存在するものを判定する。アンバウンダリーアプリケーションにより選択されたＰＬの中に、プレイリスト管理テーブルに記載されたものがあれば、それの再生を自動的に開始する。【０１７８】  図４９は、タイトルアンバウンダリーアプリケーションにＰＬ選択を行わせる過程を模式的に描いた図である。本図の左側は再生装置におけるソフトウェアのレイヤ構成を示し、本図の右側に、ＢＤ−ＲＯＭの記録内容を示す。図中の◎１，２，３，４は、ＡｕｔｏＰｌａｙがないプレイリスト管理テーブルを発見した場合の、アプリケーションマネージャ３６からの通知（◎１）、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２による再生可能ＰＬの問合せ（◎２）、タイトルアンバウンダリーアプリケーションによるＰＳＲ設定値取得（◎３）、タイトルアンバウンダリーアプリケーションからＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２への再生可能なＰＬの通知（◎４）を模式的に描いている。【０１７９】  尚、図４９においてタイトルアンバウンダリーアプリケーションは、ＢＤ−ＲＯＭ上に記述していたが、これはタイトルアンバウンダリーアプリケーションを、わかり易く記述するための配慮に過ぎない。タイトルアンバウンダリーアプリケーションは、Ｊａｖａ（登録商標）アプリケーションであるので、Ｊａｖａ（登録商標）仮想マシン３８内のワークメモリ５４においてインスタンスとしてスレッド５５により実行されるというのが、現実的な記述になる。【０１８０】  以上のように本実施形態によれば、Ｔｉｔｌｅのバウンダリで生存しているようなアプリケーションに、上述したような判定を行わせるので、再生装置側のＰｌａｙｂａｃｋＣｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２は、ＢＤ−ＲＯＭにおける複数ＰＬのうち、再生装置側の状態設定に応じたものはどれであるかを、Ｔｉｔｌｅ開始時の早い段階で知得することができる。再生属性＝ＡｕｔｏＰｌａｙのアプリケーションを決めておかなくても、Ｔｉｔｌｅ開始時に再生を開始すべきＰＬを決定することができるので、ラングエージクレジットやパレンタルロックといった再生制御をＢＤ−Ｊモードにおいても実現することができる。【０１８１】  尚、本実施形態における選択アルゴリズムは、ＰＳＲがとり得る値をプレイリストに対応���けたが、再生装置におけるＰＳＲの設定値が、想定外の値であった場合に、再生装置に再生させるプレイリストを予め規定しておいてもよい。
（第５実施形態）
第４実施形態においてタイトルアンバウンダリーアプリケーションは、ＰＳＲの設定値に応じて再生すべきＰＬを選択するという選択アルゴリズムを有していたが、本実施形態に係るタイトルアンバウンダリーアプリケーションは、１つのＰＬ内にマルチアングル区間がある場合、当該マルチアングル区間における複数アングルのどれかを選ぶとの処理を、タイトルアンバウンダリーアプリケーションに行わせる改良に関する。本実施形態に係るタイトルアンバウンダリーアプリケーションは、ＰＳＲがとりうる値の複数の範囲と、それら範囲毎に再生すべきアングルとを対応づけたものである。本実施形態において現在の再生時点がマルチアングル区間であるとＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２はタイトルアンバウンダリーアプリケーションに対し、何れのアングルを再生するかの問い合わせを行う。かかる問い合わせがあれば、タイトルアンバウンダリーアプリケーションは現在におけるＰＳＲ設定値を取得し、選択アルゴリズムを実行して、取得した設定値に応じたアングルを選択する。その選択結果をＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に通知してそのアングルの再生をＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に行わせる。【０１８２】  以上のように本実施形態によれば、ＰＳＲがどの値であるとき、どのアングルを選択するというアルゴリズムを、オーサリング担当者が規定しておくことができるので、アングルを応用した様々なアプリケーションをオーサリング担当者は作り出すことができる。
（第６実施形態）
ＢＤ−Ｊモードにおいて、ＰＬ再生との同期をどのように実現するかという改良に関する。Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２は、ＰｌａｙＰＬＡＰＩファンクションがコールされれば、ＰＬ情報に基づく処理手順を実行する。ＰＬが２時間という再生時間を有するなら、この２時間の間、上述した処理は継続することになる。ここで問題になるのは、Ｊａｖａ（登録商標）仮想マシン３８がサクセス応答を返す時間と、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２が実際に処理を終える時間とのギャップである。Ｊａｖａ（登録商標）仮想マシン３８は、イベントドリブンの処理主体であるためコール直後に再生成功か、再生失敗かを示す応答を返すが、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２による実際の処理終了は２時間経過後であるので、サクセス応答をアプリケーションに返す時間を基準にしたのでは、２時間経過後にあたる処理終結を感知しえない。ＰＬ再生において早送り、巻戻し、Ｓｋｉｐが行われると、この２時間という再生期間は２時間前後に変動することになり、処理終結の感知は更に困難になる。【０１８３】  Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２は、アプリケーションとスタンドアローンで動作するため、アプリケーションマネージャ３６は、ＰＬ再生の終了時点を正確に解釈することができない。そこで本実施形態では、アプリケーションが終了してようがいまいが、ワークメモリにＪＭＦプレーヤインスタンスがある限り、つまり、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１の制御権をＢＤ−Ｊモジュール３５が掌握している間、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２からＮｏｔｉｆｙイベントを待つ。そしてＮｏｔｉｆｙイベントがあれば、タイトルが終了したと解釈して、次のタイトルへの分岐を行うようモジュールマネージャ３４に通知する。こうすることにより、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２がＰＬ再生を終結した時点を、タイトルの終端とすることができる。【０１８４】  以降図５０〜図５４のフローチャートを参照して、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２による具体的な制御手順を説明する。
図５０は、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２によるＰＬ再生手順を示すフローチャートである。この再生手順は、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１に対する制御（ステップＳ１０６）と、ＢＤ−ＲＯＭドライブ１又はＬｏｃａｌ  Ｓｔｏｒａｇｅ１８に対する制御（ステップＳ１０８）とを主に含む。本フローチャートにおいて処理対象たるＰｌａｙＩｔｅｍをＰｌａｙＩｔｅｍ＃ｘとする。本フローチャートは、カレントＰＬ情報（．ｍｐｌｓ）の読み込みを行い（ステップＳ１０１）、その後、ステップＳ１０２〜ステップＳ１１０の処理を実行するというものである。ここでステップＳ１０２〜ステップＳ１１０は、ステップＳ１０９がＹｅｓになるまで、カレントＰＬ情報を構成するそれぞれのＰＩ情報について、ステップＳ１０３〜ステップＳ１１０の処理を繰り返すというループ処理を構成している。このループ処理において処理対象となるＰｌａｙＩｔｅｍを、ＰｌａｙＩｔｅｍ＃ｘ（ＰＩ＃ｘ）とよぶ。このＰｌａｙＩｔｅｍ＃ｘは、カレントＰＬの先頭のＰｌａｙＩｔｅｍに設定されることにより、初期化される（ステップＳ１０２）。上述したループ処理の終了要件は、このＰｌａｙＩｔｅｍ＃ｘがカレントＰＬの最後のＰｌａｙＩｔｅｍになることであり（ステップＳ１０９）、もし最後のＰｌａｙＩｔｅｍでなければ、カレントＰＬにおける次のＰｌａｙＩｔｅｍがＰｌａｙＩｔｅｍ＃ｘに設定される（ステップＳ１１０）。【０１８５】  ループ処理において繰り返し実行されるステップＳ１０３〜ステップＳ１１０は、ＰｌａｙＩｔｅｍ＃ｘのＣｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されるＣｌｉｐ情報をシナリオメモリ２５に読み込み（ステップＳ１０３）、ＰｌａｙＩｔｅｍ＃ｘのＩｎ＿ｔｉｍｅを、カレントＣｌｉｐ情報のＥＰｍａｐを用いて、Ｉピクチャアドレスｕに変換し（ステップＳ１０４）、ＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅを、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて、Ｉピクチャアドレスｖに変換して（ステップＳ１０５）、これらの変換で得られたアドレスｖの次のＩピクチャを求めて、そのアドレスの１つ手前をアドレスｗに設定し（ステップＳ１０７）、そうして算出されたアドレスｗを用いて、ＩピクチャアドレスｕからアドレスｗまでのＴＳパケットの読み出しをＢＤ−ＲＯＭドライブ１又はＬｏｃａｌ  Ｓｔｏｒａｇｅ１８に命じるというものである（ステップＳ１０８）。【０１８６】  一方、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１に対しては、カレントＰＬＭａｒｋのｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐからＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅまでの出力を命じる（ステップＳ１０６）。以上のステップＳ１０５〜ステップＳ１０８により、ＡＶＣｌｉｐにおいて、ＰｌａｙＩｔｅｍ＃ｘにより指示されている部分の再生がなされることになる
その後、ＰｌａｙＩｔｅｍ＃ｘがカレントＰＬの最後のＰＩであるかの判定がなされる（ステップＳ１０９）。【０１８７】  ＰｌａｙＩｔｅｍ＃ｘがカレントＰＬの最後のＰＩでなければ、カレントＰＬにおける次のＰｌａｙＩｔｅｍを、ＰｌａｙＩｔｅｍ＃ｘに設定して（ステップＳ１１０）、ステップＳ１０３に戻る。以上のステップＳ１０３〜ステップＳ１１０を繰り返することにより、ＰＬを構成するＰＩは順次再生されることになる。
図５１は、アングル切り換え手順及びＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔの手順を示すフローチャートである。本フローチャートは、図５０の処理手順と並行してなされるものであり、ステップＳ１１１〜Ｓ１１２からなるループ処理を繰り返すというものである。本ループにおけるステップＳ１１１は、アングル切り換えを要求するＡＰＩが、Ｊａｖａ（登録商標）仮想マシン３８からコールされたか否かの判定であり、アングル切り換えＡＰＩのコールがあれば、カレントＣｌｉｐ情報を切り換えるという操作を実行する。【０１８８】  図５１のステップＳ１１５は、判定ステップであり、ＰｌａｙＩｔｅｍ＃ｘのｉｓ＿ｍｕｌｔｉ＿ａｎｇｌｅｓがオンであるか否かの判定を行う。ｉｓ＿ｍｕｌｔｉ＿ａｎｇｌｅｓとは、ＰｌａｙＩｔｅｍ＃ｘがマルチアングルに対応しているか否かを示すフラグであり、もしステップＳ１１５がＮｏであるならステップＳ１１３に移行する。ステップＳ１１５がＹｅｓであるなら、ステップＳ１１６〜ステップＳ１１９を実行する。ステップＳ１１６〜ステップＳ１１９は、切り換え後のアングル番号を変数ｙに代入して（ステップＳ１１６）、ＰｌａｙＩｔｅｍ＃ｘにおけるｙ番目のＣｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されているＣｌｉｐ情報をシナリオメモリ２１に読み出し（ステップＳ１１７）、カレントＰＴＭを、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いてＩピクチャアドレスｕに変換し（ステップＳ１１８）、ＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅを、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いてＩピクチャアドレスｖに変換する（ステップＳ１１９）というものである。こうしてＩピクチャアドレスｕ，ｖを変化した後、同時実行されている図５０側の処理を停止させた上でステップＳ１０６に移行する。ステップＳ１０６への移行により、別のＡＶＣｌｉｐからＴＳパケットが読み出されるので、映像内容が切り換わることになる。【０１８９】  一方、図５１のループにおけるステップＳ１１２は、ＳｋｉｐＢａｃｋ／ＳｋｉｐＮｅｘｔを意味するＡＰＩがＪａｖａ（登録商標）仮想マシン３８からコールされたか否かの判定であり、もしコールされれば、図５２のフローチャートの処理手順を実行する。図５２は、ＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔＡＰＩがコールされた際の処理手順を示すフローチャートである。ＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔを実行するにあたっての処理手順は多種多様なものである。ここで説明するのはあくまでも一例に過ぎないことに留意されたい。【０１９０】  ステップＳ１２１は、ＰＳＲで示されるカレントＰＩ番号、及び、カレントＰＴＭを変換することにより、カレントＭａｒｋ情報を得る。ステップＳ１２２は、押下されたのがＳｋｉｐＮｅｘｔキーであるか、ＳｋｉｐＢａｃｋキーであるかの判定であり、ＳｋｉｐＮｅｘｔキーであるならステップＳ１２３において方向フラグを＋１に設定し、ＳｋｉｐＢａｃｋキーであるならステップＳ１２４において方向フラグを−１に設定する。【０１９１】  ステップＳ１２５は、カレントＰＬＭａｒｋの番号に方向フラグの値を足した番号を、カレントＰＬＭａｒｋの番号として設定する。ここでＳｋｉｐＮｅｘｔキーであるなら方向���ラグは＋１に設定されているのでカレントＰＬＭａｒｋはインクリメントされることになる。ＳｋｉｐＢａｃｋキーであるなら方向フラグは−１に設定されているので、カレントＰＬＭａｒｋはデクリメントされることになる。【０１９２】  ステップＳ１２６では、カレントＰＬＭａｒｋのｒｅｆ＿ｔｏ＿ＰｌａｙＩｔｅｍ＿Ｉｄに記述されているＰＩを、ＰｌａｙＩｔｅｍ＃ｘに設定し、ステップＳ１２７では、ＰｌａｙＩｔｅｍ＃ｘのＣｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されるＣｌｉｐ情報を読み込む。ステップＳ１２８では、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて、カレントＰＬＭａｒｋのｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐを、Ｉピクチャアドレスｕに変換する。一方ステップＳ１２９では、ＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅを，カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて，Ｉピクチャアドレスｖに変換する。ステップＳ１３０は、カレントＰＬＭａｒｋのｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐからＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅまでの出力をＰｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１に命じて、同時実行されている図５０側の処理を停止させた上で、図５０のステップＳ１０７に移行する。こうしてＩピクチャアドレスｕ，ｖを変化して、別の部分の再生を命じた上でステップＳ１０７への移行するので、別のＡＶＣｌｉｐからＴＳパケットが読み出されることになり、映像内容が切り換えが実現する。【０１９３】  図５３は、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１による処理手順の詳細を示すフローチャートである。本フローチャートは、ＩピクチャのＰＴＳをカレントＰＴＭに設定した後で（ステップＳ１３１）、ステップＳ１３２〜ステップＳ１３７からなるループ処理を実行するものである。
続いてステップＳ１３２〜ステップＳ１３７におけるループ処理について説明する。このループ処理は、カレントＰＴＭにあたるピクチャ、オーディオの再生出力と、カレントＰＴＭの更新とを繰り返すものである。本ループ処理におけるステップＳ１３６は、ループ処理の終了要件を規定している。つまりステップＳ１３６は、カレントＰＴＭがＰＩ＃ｘのＯｕｔ＿ｔｉｍｅであることをループ処理の終了要件にしている。【０１９４】  ステップＳ１３３は、早送りＡＰＩ、又は、早戻しＡＰＩがＪａｖａ（登録商標）仮想マシン３８からコールされたか否かの判定である。もしコールされれば、ステップＳ１３８において早送りか早戻しかの判定を行い、早送りであるなら、次のＩピクチャのＰＴＳをカレントＰＴＭに設定する（ステップＳ１３９）。このようにカレントＰＴＭを、次のＩピクチャのＰＴＳに設定することで、１秒飛びにＡＶＣｌｉｐを再生してゆくことができる。これにより、２倍速等でＡＶＣｌｉｐは順方向に早く再生されることになる。早戻しであるなら、カレントＰＴＭがＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅに到達したかを判定する（ステップＳ１４０）。もし到達してないのなら、１つ前のＩピクチャのＰＴＳをカレントＰＴＭに設定する（ステップＳ１４１）。このように読出先アドレスＡを、１つ前のＩピクチャに設定することで、ＡＶＣｌｉｐを後方向に１秒飛びに再生してゆくことができる。これにより、２倍速等でＡＶＣｌｉｐは、逆方向に再生されることになる。尚、早送り、巻戻しを実行するにあたっての処理手順は多種多様なものである。ここで説明するのはあくまでも一例に過ぎないことに留意されたい。【０１９５】  ステップＳ１３４は、メニューコールＡＰＩがコールされたか否かの判定であり、もしコールされれば、現在の再生処理をサスペンドして（ステップＳ１４２）、メニュー処理用のメニュープログラムを実行する（ステップＳ１４３）。以上の処理により、メニューメニューコールがなされた場合は、再生処理を中断した上で、メニュー表示のための処理が実行されることになる。【０１９６】  ステップＳ１３５は、ｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿ｉｄにより、ＰｌａｙＩｔｅｍ＃ｘを指定したＳｕｂＰｌａｙＩｔｅｍ＃ｙが存在するか否かの判定であり、もし存在すれば、図５４のフローチャートに移行する。図５４は、ＳｕｂＰｌａｙＩｔｅｍの再生手順を示すフローチャートである。本フローチャートでは、先ずステップＳ１４６において、カレントＰＴＭはＳｕｂＰｌａｙＩｔｅｍ＃ｙのｓｙｎｃ＿ｓｔａｒｔ＿ＰＴＳ＿ｏｆ＿ｐｌａｙＩｔｅｍであるか否かを判定する。もしそうであれば、ステップＳ１５３においてＳｕｂＰｌａｙＩｔｅｍ＃ｙに基づく再生処理を行うようＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に通知する。【０１９７】  ステップＳ１３６がＹｅｓと判定された場合、ステップＳ１４４、ステップＳ１４５を実行する。ステップＳ１４４は、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０からＮｏｔｉｆｙ  Ｅｎｄ  Ｏｆ  Ｆｉｌｅイベントが出力され、尚且つ、デコーダからＮｏｔｉｆｙ  Ｅｎｄ  Ｏｆ  Ｄｅｃｏｄｉｎｇイベントが出力されたかを判定する。もし出力されれば、Ｎｏｔｉｆｙ  Ｅｎｄ  Ｏｆ  ＳｔｒｅａｍイベントをＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に出力する。【０１９８】  図５４のステップＳ１４７〜ステップＳ１５２は、ＳｕｂＰｌａｙＩｔｅｍ＃ｙに基づく再生処理を示すフローチャートである。
ステップＳ１４７では、ＳｕｂＰｌａｙＩｔｅｍ＃ｙのＣｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されるＣｌｉｐ情報を読み込む。ステップＳ１４８では、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて、ＳｕｂＰｌａｙＩｔｅｍ＃ｙのＩｎ＿ｔｉｍｅを、アドレスαに変換する。一方ステップＳ１４９では、ＳｕｂＰｌａｙＩｔｅｍ＃ｙのＯｕｔ＿ｔｉｍｅを，カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて、アドレスβに変換する。ステップＳ１５０は、ＳｕｂＰｌａｙＩｔｅｍ＃ｙのＩｎ＿ｔｉｍｅからＳｕｂＰｌａｙＩｔｅｍ＃ｙのＯｕｔ＿ｔｉｍｅまでの出力をデコーダに命じる。これらの変換で得られたアドレスβの次のＩピクチャを求めて、そのアドレスの１つ手前をアドレスγに設定し（ステップＳ１５１）、そうして算出されたアドレスγを用いて、ＳｕｂＣｌｉｐ＃ｚにおけるアドレスαからアドレスγまでのＴＳパケットの読み出しをＢＤ−ＲＯＭドライブ１又はＬｏｃａｌ  Ｓｔｏｒａｇｅ１８に命じるというものである（ステップＳ１５２）。【０１９９】  また図５０に戻ってＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２の処理の説明の続きを行う。ステップＳ１１３はＰｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１による再生制御が完了したかの判定であり、最後のＰｌａｙＩｔｅｍ＃ｘに対して、図５３のフローチャートの処理が行われている限り、ステップＳ１１３がＮｏになる。図５３のフローチャートの処理が終了して初めて、ステップＳ１１３はＹｅｓになりステップＳ１１４に移行する。ステップＳ１１４は、Ｊａｖａ（登録商標）仮想マシン３８へのＮｏｔｉｆｙイベントの出力であり、この出力により、２時間という再生時間の経過をＪａｖａ（登録商標）仮想マシン３８は知ることができる。【０２００】  以上のように本実施形態によれば、２時間という再生時間の経過時点をアプリケーションマネージャ３６は把握することができるので、プレイリストの再生終了と同期した処理をＪａｖａ（登録商標）仮想マシン３８に実行させることができる。
（備考）
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記（Ａ）（Ｂ）（Ｃ）（Ｄ）・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の技術分野の、出願当時の技術水準の特性に基づく。【０２０１】  （Ａ）全ての実施形態では、本発明に係る光ディスクをＢＤ−ＲＯＭとして実施したが、本発明の光ディスクは、記録される動的シナリオ、Ｉｎｄｅｘ  Ｔａｂｌｅに特徴があり、この特徴は、ＢＤ−ＲＯＭの物理的性質に依存するものではない。動的シナリオ、Ｉｎｄｅｘ  Ｔａｂｌｅを記録しうる記録媒体なら、どのような記録媒体であってもよい。例えば、ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−ＲＷ，ＤＶＤ−Ｒ，ＤＶＤ＋ＲＷ，ＤＶＤ＋Ｒ，ＣＤ−Ｒ，ＣＤ−ＲＷ等の光ディスク、ＰＤ，ＭＯ等の光磁気ディスクであってもよい。また、コンパクトフラッシュ（登録商標）カード、スマートメディア、メモリスティック、マルチメディアカード、ＰＣＭ−ＣＩＡカード等の半導体メモリカードであってもよい。フレシキブルディスク、ＳｕｐｅｒＤｉｓｋ，Ｚｉｐ，Ｃｌｉｋ！等の磁気記録ディスク（ｉ）、ＯＲＢ，Ｊａｚ，ＳｐａｒＱ，ＳｙＪｅｔ，ＥＺＦｌｅｙ，マイクロドライブ等のリムーバルハードディスクドライブ（ｉｉ）であってもよい。更に、機器内蔵型のハードディスクであってもよい。
（Ｂ）全ての実施形態における再生装置は、ＢＤ−ＲＯＭに記録されたＡＶＣｌｉｐをデコードした上でＴＶに出力していたが、再生装置をＢＤ−ＲＯＭドライブのみとし、これ以外の構成要素をＴＶに具備させてもい、この場合、再生装置と、ＴＶとをＩＥＥＥ１３９４で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレイと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなす部分のみを、再生装置としてもよい。これらの再生装置は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、各実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。各実施形態に示した再生装置の有償・無償による譲渡（有償の場合は販売、無償の場合は贈与になる）、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。【０２０２】  （Ｃ）各フローチャートに示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムの実施行為についての実施形態を示したが、再生装置から分離して、各実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為（１）や、有償・無償によりプログラムを譲渡する行為（２）、貸与する行為（３）、輸入する行為（４）、双方向の電子通信回線を介して公衆に提供する行為（５）、店頭展示、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為（６）がある。【０２０３】  （Ｄ）各フロ−チャ−トにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフロ−チャ−トによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフロ−チャ−トの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。【０２０４】  （Ｅ）ＢＤ−ＲＯＭに記録するにあたって、ＡＶＣｌｉｐを構成する各ＴＳパケットには、拡張ヘッダを付与しておくことが望ましい。拡張ヘッダは、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒと呼ばれ、『Ａｒｒｉｂｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐ』と、『ｃｏｐｙ＿ｐｅｒｍｉｓｓｉｏｎ＿ｉｎｄｉｃａｔｏｒ』とを含み４バイトのデータ長を有する。ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒ付きＴＳパケット（以下ＥＸ付きＴＳパケットと略す）は、３２個毎にグループ化されて、３つのセクタに書き込まれる。３２個のＥＸ付きＴＳパケットからなるグループは、６１４４バイト（＝３２×１９２）であり、これは３個のセクタサイズ６１４４バイト���＝２０４８×３）と一致する。３個のセクタに収められた３２個のＥＸ付きＴＳパケットを”Ａｌｉｇｎｅｄ  Ｕｎｉｔ”という。【０２０５】  ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時において、再生装置２００は、以下のような送信処理にてＡｌｉｇｎｅｄ  Ｕｎｉｔの送信を行う。つまり送り手側の機器は、Ａｌｉｇｎｅｄ  Ｕｎｉｔに含まれる３２個のＥＸ付きＴＳパケットのそれぞれからＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒを取り外し、ＴＳパケット本体をＤＴＣＰ規格に基づき暗号化して出力する。ＴＳパケットの出力にあたっては、ＴＳパケット間の随所に、ｉｓｏｃｈｒｏｎｏｕｓパケットを挿入する。この挿入箇所は、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒのＡｒｒｉｂｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐに示される時刻に基づいた位置である。ＴＳパケットの出力に伴い、再生装置２００はＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを出力する。ＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒは、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒにおけるコピー許否設定を示す。ここで「コピー禁止」を示すようＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを記述しておけば、ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時においてＴＳパケットは、他の機器に記録されることはない。【０２０６】  （Ｆ）各実施形態において、記録媒体に記録されるデジタルストリームはＡＶＣｌｉｐであったが、ＤＶＤ−Ｖｉｄｅｏ規格、ＤＶＤ−Ｖｉｄｅｏ  Ｒｅｃｏｒｄｉｎｇ規格のＶＯＢ（Ｖｉｄｅｏ  Ｏｂｊｅｃｔ）であってもよい。ＶＯＢは、ビデオストリーム、オーディオストリームを多重化することにより得られたＩＳＯ／ＩＥＣ１３８１８−１規格準拠のプログラムストリームである。またＡＶＣｌｉｐにおけるビデオストリームは、ＭＰＥＧ４やＷＭＶ方式であってもよい。更にオーディオストリームは、Ｌｉｎｅａｒ−ＰＣＭ方式、Ｄｏｌｂｙ−ＡＣ３方式、ＭＰ３方式、ＭＰＥＧ−ＡＡＣ方式、Ｄｔｓ、ＷＭＡ（Ｗｉｎｄｏｗｓ（登録商標）ｍｅｄｉａ  ａｕｄｉｏ）であってもよい。【０２０７】  （Ｇ）各実施形態における映像作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
またビデオテープに記録されているアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。【０２０８】  （Ｈ）ＢＤ−Ｊモジュール３５は、衛星放送受信のために機器に組み込まれたＪａｖａ（登録商標）プラットフォームであってもよい。ＢＤ−Ｊモジュール３５がかかるＪａｖａ（登録商標）プラットフォームであれば、本発明に係る再生装置は、ＭＨＰ用ＳＴＢとしての処理を兼用することになる。
更に携帯電話の処理制御のために機器に組み込まれたＪａｖａ（登録商標）プラットフォームであってもよい。かかるＢＤ−Ｊモジュール３５がかかるＪａｖａ（登録商標）プラットフォームであれば、本発明に係る再生装置は、携帯電話としての処理を兼用することになる。【０２０９】  （Ｉ）レイアモデルにおいて、ＢＤ−Ｊモードの上にＨＤＭＶモードを配置してもよい。特にＨＤＭＶモードでの動的シナリオの解釈や、動的シナリオに基づく制御手順の実行は、再生装置に対する負担が軽いので、ＨＤＭＶモードをＢＤ−Ｊモード上で実行させても何等問題は生じないからである。また再生装置や映画作品の開発にあたって、動作保証が１つのモードで済むからである。【０２１０】  更にＢＤ−Ｊモードだけで再生処理を実行してもよい。第５実施形態に示したように、ＢＤ−ＪモードでもＰＬの再生と同期した再生制御が可能になるから、強いてＨＤＭＶモードを設けなくてもよいという理由による。
（Ｊ）ＡＶＣｌｉｐに多重化されるべきインタラクティブグラフィクスストリームにナビゲーションコマンドを設けて、あるＰＬから別のＰＬへの分岐を実現しても良い。（Ｋ）第１実施形態では、１つのＢＤ−ＲＯＭに属する複数タイトルの全てを生存区間とするタイトルとしてタイトルアンバウンダリーアプリケーションを規定した。この他にも、複数のＢＤ−ＲＯＭに属するタイトルの全てを生存区間とするタイトルアンバウンダリーアプリケーションを規定してもよい。【０２１１】  （Ｌ）第１実施形態でアプリケーション管理テーブルを作成するにあたって、同時実行し得るアプリケーションの数は、例えば４個以下に制限することが望ましい。
アプリケーションの同時実行数を４個以下に制限する理由は以下の通りである。ＢＤ−ＲＯＭの再生装置は、デジタル放送のチューナ機能を具備しているものが多く、そのチューナ機能を実現するアプリケーションがメモリに常駐（レジデント）していることも多い。かかるレジデントアプリケーションが動作する余地を生むため、アプリケーションの数は４つ以下に制限されている。４つのアプリケーションの内訳として、１つ目をタイトルアンバウンダリーアプリケーション、２つ目をタイトルバウンダリアプリケーション、３つ目をチャプターバウンダリーアプリケーションとしておくことが望ましい。【０２１２】  （Ｍ）第２実施形態においてエラー管理テーブルは、１つのアプリケーションが異常終了した際、１つのリカバリー処理を実行するよう規定されていた。しかし１つのアプリケーションが異常終了した際、複数のリカバリー処理を実行するようにしてもよい。つまりあるアプリケーションが異常終了した際、プレイリスト再生を継続と、アプリケーションと再起動と、イベント出力とを再生装置に実行させてもよい。【０２１３】  またアプリケーション毎ではなく、１つのタイトルにつき１つのリカバリー処理を規定するようエラー管理テーブルを構成してもよい。
（Ｎ）ＡＶＣｌｉｐには、メニューを表示して対話的な操作を受け付けるためのインタラクティブグラフィクスストリームを多重化しておくことができるため、トップメニューを表示して対話的な操作を受け付けるようなＡＶＣｌｉｐを、単に再生させるようなナビゲーションコマンドをＭｏｖｉｅＯｂｊｅｃｔに記述しておくだけで、トップメニュータイトルを製作してもよい。【０２１４】  （Ｏ）各実施形態におけるディレクトリ・ファイル構成及びファイル内のデータ構造は一例であり、本発明の特徴である管理情報は、ディレクトリ・ファイル構成及びファイル内のデータ構造に依存しない。例えばＢＤ−Ｊモードの動作シナリオであるＢＤ−Ｊ  Ｏｂｊｅｃｔは、識別子ｂｏｂｊ＿ｉｄと、識別子ＢＤ−Ｊが付与されたファイル（ＺＺＺＺＺ．ＢＤ−Ｊ）として、ＢＤＪＡディレクトリに配置し、ＢＤ−Ｊ  Ｏｂｊｅｃｔ．ｂｄｍｖのＢＤ−Ｊ  Ｏｂｊｅｃｔ［ｎ］（）には、識別子ｂｏｂｊ＿ｉｄのみを格納してよい。
【産業上の利用可能性】
【０２１５】  本発明に係る記録媒体及び再生装置は、ホームシアターシステムでの利用のように、個人的な用途で利用されることがありうる。しかし本発明は上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る記録媒体及び再生装置は、産業上の利用可能性を有する。
【図１】
2005045840.tif 000002
【図２】
2005045840.tif 000003
【図３】
2005045840.tif 000004
【図４】
2005045840.tif 000005
【図５】
2005045840.tif 000006
【図６】
2005045840.tif 000007
【図７】
2005045840.tif 000008
【図８】
2005045840.tif 000009
【図９】
2005045840.tif 000010
【図１０】
2005045840.tif 000011
【図１１】
2005045840.tif 000012
【図１２】
2005045840.tif 000013
【図１３】
2005045840.tif 000014
【図１４】
2005045840.tif 000015
【図１５】
2005045840.tif 000016
【図１６】
2005045840.tif 000017
【図１７】
2005045840.tif 000018
【図１８】
2005045840.tif 000019
【図１９】
2005045840.tif 000020
【図２０】
2005045840.tif 000021
【図２１】
2005045840.tif 000022
【図２２】
2005045840.tif 000023
【図２３】
2005045840.tif 000024
【図２４】
2005045840.tif 000025
【図２５】
2005045840.tif 000026
【図２６】
2005045840.tif 000027
【図２７】
2005045840.tif 000028
【図２８】
2005045840.tif 000029
【図２９】
2005045840.tif 000030
【図３０】
2005045840.tif 000031
【図３１】
2005045840.tif 000032
【図３２】
2005045840.tif 000033
【図３３】
2005045840.tif 000034
【図３４】
2005045840.tif 000035
【図３５】
2005045840.tif 000036
【図３６】
2005045840.tif 000037
【図３７】
2005045840.tif 000038
【図３８】
2005045840.tif 000039
【図３９】
2005045840.tif 000040
【図４０】
2005045840.tif 000041
【図４１】
2005045840.tif 000042
【図４２】
2005045840.tif 000043
【図４３】
2005045840.tif 000044
【図４４】
2005045840.tif 000045
【図４５】
2005045840.tif 000046
【図４６】
2005045840.tif 000047
【図４７】
2005045840.tif 000048
【図４８】
2005045840.tif 000049
【図４９】
2005045840.tif 000050
【図５０】
2005045840.tif 000051
【図５１】
2005045840.tif 000052
【図５２】
2005045840.tif 000053
【図５３】
2005045840.tif 000054
【図５４】
2005045840.tif 000055
【手続補正書】
【提出日】平成17年8月1日(2005.8.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
アプリケーションと、デジタルストリームと、管理情報とが記録された記録媒体であって、
前記アプリケーションは、
仮想マシン向けプログラミング言語で記述されたプログラムであり、
仮想マシンによる実行が可能となる生存区間が、予め規定されており、
前記管理情報は、
生存区間において、アプリケーションの実行と同時に行うべきデジタルストリームの再生制御を示す
ことを特徴とする記録媒体。
【請求項２】
前記記録媒体には更に、デジタルストリームの再生経路を規定するプレイリスト情報が複数記録されており、
前記管理情報により示される再生制御は、所定の再生属性が付加されたプレイリスト情報に示される再生経路に従って、デジタルストリームを再生することである、請求項１記載の記録媒体。
【請求項３】
所定の再生属性とは、プレイリスト情報に示される再生経路の再生を自動的に開始する旨を示す属性であり、
前記デジタルストリーム再生の同時実行は、
プレイリスト情報に自動再生を示す再生属性が付加されている場合になされる、ことを特徴とする請求項２記載の記録媒体。
【請求項４】
前記記録媒体には更に、生存区間がないタイトルアンバウンダリーアプリケーションが記録されており、
タイトルアンバウンダリーアプリケーションは、記録媒体に記録されている複数プレイリスト情報のうち、何れか1つを、再生装置における状態レジスタの格納値に応じて選択する処理を行い、
前記所定の再生属性とは、タイトルアンバウンダリーアプリケーションの選択を待って再生される旨を示す再生属性である
ことを特徴とする請求項２記載の記録媒体。
【請求項５】
管理情報は更に、アプリケーションの異常終了時に行うべきリカバリー処理を規定する再生継続フラグを含み、
前記再生継続フラグは所定の値に設定されることにより
アプリケーションと同時になされた再生制御を、アプリケーションの異常終了後も再生装置に継続させる旨を示す
ことを特徴とする請求項１記載の記録媒体。
【請求項６】
管理情報は更に、アプリケーションの異常終了時に行うべきリカバリー処理を規定するフラグを含み、  
フラグには、
異常終了したアプリケーションを再起動するか否かを示すフラグ(i)、
アプリケーションの異常終了時に、出力すべきイベントを示すフラグ(ii)、
再生装置をリブートするか否かを示すフラグ(iii)がある
ことを特徴とする請求項１記載の記録媒体。
【請求項７】
前記アプリケーションは、記録媒体において複数記録されており、
各アプリケーションのそれぞれは、複数タイトルのどれかに帰属しており、
前記アプリケーションの生存区間は、タイトルを用いて表現されている
ことを特徴とする請求項１記載の記録媒体。
【請求項８】
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、
同記録媒体に記録されたデジタルストリームを再生する再生制御エンジン部と、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させ、それと同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、再生制御エンジン部に実行させるアプリケーションマネージャと
を備えることを特徴とする再生装置。
【請求項９】
前記アプリケーションマネージャによる再生制御は、
アプリケーションの実行画像を親画面に配置し、デジタルストリームの再生画像を子画面に配置した合成画像を再生制御エンジン部に出力させる制御を含む
ことを特徴とする請求項８記載の再生装置。
【請求項１０】
前記アプリケーションマネージャは更に、
アプリケーションが起動されるまでのスタートアップディレイにおいて、デジタルストリームの再生画像を主画像として再生させるよう、再生制御エンジン部に対する制御を行い、
前記合成画像を、アプリケーションが正常に起動した後に再生制御エンジン部に表示させる
ことを特徴とする請求項９記載の再生装置。
【請求項１１】
前記アプリケーションマネージャは更に、
デジタルストリームの再生画像を主画像として再生させる制御を、アプリケーションの起動に失敗した際、及び、アプリケーションが異常終了した際にも実行する
ことを特徴とする請求項１０記載の再生装置。
【請求項１２】
前記記録媒体には、プレイリスト情報が複数記録されており、
前記アプリケーションマネージャによる再生制御とは、所定の再生属性が付加されたプレイリスト情報に示される再生経路に従って、デジタルストリームを再生させることである、請求項８記載の再生装置。
【請求項１３】
前記所定の再生属性とは、プレイリスト情報に示される再生経路の再生を自動的に開始する旨を示す再生属性である、ことを特徴とする請求項１２記載の再生装置。
【請求項１４】
前記記録媒体には更に、生存区間がないタイトルアンバウンダリーアプリケーションが記録されており、
タイトルアンバウンダリーアプリケーションは、記録媒体に記録されている複数プレイリスト情報のうち、何れか1つを、再生装置における状態レジスタの格納値に応じて選択する処理を行い、
前記所定の再生属性とは、タイトルアンバウンダリーアプリケーションの選択を待って再生される旨を示す再生属性であり、
前記再生制御エンジン部によるデジタルストリーム再生は、
所定の再生属性が付加されたプレイリスト情報のうちタイトルアンバウンダリーアプリケーションにより選択されたものに基づきなされる
ことを特徴とする請求項１２記載の再生装置。
【請求項１５】
前記管理情報は更に、アプリケーションの異常終了時に行うべきリカバリー処理を規定する再生継続フラグを含み、
前記アプリケーションマネージャは更に、前記再生継続フラグが所定の値に設定されているか否かの判定を行い、前記再生継続フラグが所定の値に設定されていれば、アプリケーションと同時になされた再生制御を、アプリケーションの異常終了後も再生制御エンジン部に継続させる
ことを特徴とする請求項８記載の再生装置。
【請求項１６】
前記アプリケーション毎の生存区間は、記録媒体に記録された管理情報に示されており、
管理情報は更に、アプリケーションの異常終了時に行うべきリカバリー処理を規定するフラグを含み、
アプリケーションマネージャは更に、管理情報内のフラグに基づき
異常終了したアプリケーションを再起動する制御(1)、
予め規定されたイベントを出力する制御(2)、
再生装置をリブートする制御(3)のどれかを実行する
ことを特徴とする請求項８記載の再生装置。
【請求項１７】
前記再生装置は、
何れかのプレイリスト情報を指定した再生がアプリケーションから命じられた場合、当該アプリケーションの正当性を認証するパーミッションコントローラを備え、
前記再生制御エンジン部がプレイリスト情報に基づく再生を行うのは、パーミッションコントローラが正当性ありと認証した場合である
ことを特徴とする請求項８記載の再生装置。
【請求項１８】
アプリケーションマネージャは、プレイリスト情報に基づく再生を行うアプリケーションが存在する場合、当該アプリケーションが再生可能なプレイリスト情報を判定して、当該アプリケーションに通知し、
前記再生制御エンジン部による再生は、通知されたプレイリスト情報に基づく
ことを特徴とする請求項８記載の再生装置。
【請求項１９】
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、同記録媒体に記録されたデジタルストリームを再生する再生制御エンジン部とを有したコンピュータが読み込むことができるプログラムであって、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させるステップと、
仮想マシンによる実行と同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、再生制御エンジン部に実行させるステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項２０】
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、同記録媒体に記録されたデジタルストリームを再生する再生制御エンジン部とを有したコンピュータに対する再生方法であって、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させるステップと、
仮想マシンによる実行と同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、再生制御エンジン部に実行させるステップと
をコンピュータに実行させることを特徴とする再生方法。
【請求項２１】
デジタルストリームを再生する再生装置に組み込むことができるシステム集積回路であって、
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させ、それと同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、実行させるアプリケーションマネージャと
を備えることを特徴とするシステム集積回路。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【書類名】明細書
【発明の名称】
記録媒体、再生装置、プログラム、再生方法、システム集積回路
【技術分野】
【０００１】
本発明は、仮想マシンを対象にしたアプリケーションの実行を制御する、アプリケーション制御の技術分野に属する発明であり、本制御技術をBD-ROM等の映画作品頒布のための記録媒体、BD-ROMを対象とした再生装置等に応用する場合の応用技術に深く係る。
【背景技術】
【０００２】
Java（登録商標）プログラミング等、仮想マシンを対象にしたアプリケーション制御技術は、パソコンソフトの業界において深く浸透している。パソコンソフトから更に発展して、現在、Blu-ray Disc Read Only Memory(BD-ROM)用再生装置における再生制御をJava（登録商標）プログラミングで実現するための様々な工夫が検討されている。
同様の再生装置についての先行技術としては、以下の特許文献１に記載されたものが知られている。
【特許文献１】特許２８１３２４５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、Java（登録商標）プログラミングで作成されたアプリケーションの動作というのは、リソースの使用状況やCPUの負荷により変動を受ける不安定なものである。リソースが枯渇していたため、アプリケーションの起動に失敗したり、アプリケーションが異常終了したりして装置がブラックアウトするのは、パソコンソフトの業界では”よくあること”で済まされるかもしれないが、BD-ROM再生装置の製造に携わる民生機器の分野では品質問題になりかねない。品質問題への波及がありうるので、メーカ各社は、Java（登録商標）プログラミングによる装置制御の実現に二の足を踏むことが多かった(注;ブラックアウトとは、装置のソフトウェアがフリーズして表示画面が真っ暗になる状態をいう)。
【０００４】
本発明の目的は、記録媒体に対する制御を実現するようなアプリケーションが異常終了した場合、又は、起動に失敗した場合の、Fail Safeを実現することができる記録媒体を提供する。
【課題を解決するための手段】
【０００５】
上記目的を達成するため、本発明に係る記録媒体は  アプリケーションと、デジタルストリームと、管理情報とが記録されていて、前記アプリケーションは、仮想マシン向けプログラミング言語で記述されたプログラムであり、仮想マシンによる実行が可能となる生存区間が、予め規定されており、前記管理情報は、生存区間において、アプリケーションの実行と同時に行うべきデジタルストリームの再生制御を示すことを特徴としている。
【発明の効果】
【０００６】
本発明に係る記録媒体によれば、アプリケーション実行と同時に行うべきデジタルストリームの再生制御が生存区間毎に規定されている。そのため、アプリケーションの起動に失敗したり、アプリケーションの実行の途中でたとえアプリケーションが異常終了したとしても、同時になされているデジタルストリーム再生を継続することにより、”何かが写っている状態”をもたらすことができる。これにより、装置がブラックアウトしてしまうという最悪ケースを回避することができるので、装置を製造するメーカに、最低限度の安心感を与えることができる。
【０００７】
こうした安心感が与えられるので、品質問題への波及に神経を尖らせているメーカ各社に対しても、Java（登録商標）アプリケーションによる再生装置制御の開発を強く後押しすることができる。こうした強い後押しにより、再生装置の低価格化、多様化が進めば、BD-ROMコンテンツの充実化を図ることができるので、コンテンツ関連産業の発達を強く牽引することができる。
【発明を実施するための最良の形態】
【０００８】
(第１実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体はBD-ROM1００であり、BD-ROM１００は、再生装置２００、リモコン３００、テレビ４００により形成されるホームシアターシステムに、著作物を供給するという用途に供される。
【０００９】
このうちリモコン４００には、再生開始(Play)、再生停止(Stop)、一時停止(Pause On)、一時停止の解除(Pause Off)、Still機能の解除(still off)、速度指定付きの早送り(Forward Play(speed))、速度指定付きの巻戻し(Backward Play(speed))、音声切り換え(Audio Change)、副映像切り換え(Subtitle Change)、アングル切り換え(Angle Change)を受け付けるキーや、メニュー操作時にあたってのフォーカス移動操作を受け付けるMoveUpキー、MoveDownキー、MoveRightキー、MoveLeftキー、メニュー表示操作を受け付けるPop-upキー、数値入力を受け付けるNumericキーが存在する。
【００１０】
以上が本発明に係る記録媒体の使用形態についての説明である。
続いて本発明に係る記録媒体の生産行為について説明する。本発明に係る記録媒体は、BD-ROMのファイルシステム上における改良で実現することができる。図２は、BD-ROMにおけるファイル・ディレクトリ構成を示す図である。本図においてBD-ROMには、Rootディレクトリの下に、BDMVディレクトリがある。
【００１１】
BDMVディレクトリには、拡張子bdmvが付与されたファイル(index.bdmv,MovieObject.bdmv,BD-J Object.bdmv)がある。そしてこのBDMVディレクトリの配下には、更にPLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ、BDJAディレクトリと呼ばれる4つのサブディレクトリが存在する。
PLAYLISTディレクトリには、拡張子mplsが付与されたファイル(00001.mpls,00002.mpls,00003mpls)がある。
【００１２】
CLIPINFディレクトリには、拡張子clpiが付与されたファイル(00001.clpi,00002.clpi,00003.clpi)がある。
STREAMディレクトリには、拡張子m2tsが付与されたファイル(00001.m2ts,00002.m2ts,00003.m2ts)がある。
BDJAディレクトリには、拡張子jarが付与されたファイル(00001.jar,00002.jar,00003jar)がある。以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、BD-ROM上に配置されていることがわかる。
【００１３】
本図において拡張子.m2tsが付与されたファイル(00001.m2ts,00002.m2ts,00003.m2ts・・・・・)は、AVClipを格納している。AVClipには、MainCLip、SubClipといった種別がある。MainCLipは、ビデオストリーム、オーディオストリーム、字幕を構成するプレゼンテーショングラフィクスストリーム(PGストリーム)、メニューを構成するインタラクティブグラフィクスストリーム(IGストリーム)というような複数エレメンタリストリームを多重化することで得られたデジタルストリームである。
【００１４】
SubClipは、オーディオストリーム、グラフィクスストリーム、テキスト字幕ストリーム(TextSTStream)等、1つのエレメンタリストリームのみにあたるデジタルストリームである。
拡張子”clpi”が付与されたファイル(00001.clpi,00002.clpi,00003.clpi・・・・・)は、AVClipのそれぞれに1対1に対応する管理情報である。管理情報故に、Clip情報は、AVClipにおけるストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、GOPの先頭位置を示すEP_mapをもっている。
【００１５】
拡張子”mpls”が付与されたファイル(00001.mpls,00002.mpls,00003.mpls・・・・・)は、プレイリスト情報を格納したファイルである。プレイリスト情報は、AVClipを参照してプレイリストを定義する情報である。図３は、PL情報の構成を示す図であり、本図の左側に示すように、プレイリスト情報は、『MainPath情報』、『PLMark情報』、『SubPath情報』から構成される。
【００１６】
MainPath情報(MainPath())は、破線の矢印mp1に示すように複数のPlayItem情報(PlayItem())からなる。PlayItemとは、1つ以上のAVClip時間軸上において、In_Time,Out_Timeを指定することで定義される再生区間である。PlayItem情報を複数配置させることで、複数再生区間からなるプレイリスト(PL)が定義される。図中の破線mp2は、PlayItem情報の内部構成をクローズアップしている。本図に示すようにPlayItem情報は、対応するAVClipを示す『Clip_information_file_name』と、『In_time』と、『Out_time』とからなる。図４は、AVClipと、PLとの関係を示す図である。第1段目はAVClipがもつ時間軸を示し、第2段目は、PLがもつ時間軸を示す。PL情報は、PlayItem#1,#2,#3という3つのPlayItem情報を含んでおり、これらPlayItem#1,#2,#3のIn_time,Out_timeにより、3つの再生区間が定義されることになる。これらの再生区間を配列させると、AVClip時間軸とは異なる時間軸が定義されることになる。これが第2段目に示すPL時間軸である。このように、PlayItem情報の定義により、AVClipとは異なる時間軸の定義が可能になる。
【００１７】
AVClipに対する指定は、原則1つであるが、複数AVClipに対する一括指定もあり得る。この一括指定は、PlayItem情報における複数のClip_Information_file_nameによりなされる。図５は、4つのClip_Information_file_nameによりなされた一括指定を示す図である。本図において第1段目〜第4段目は、4つのAVClip時間軸(AVClip#1,#2,#3,#4の時間軸)を示し、第5段目は、PL時間軸を示す。PlayItem情報が有する、4つのClip_Information_file_nameにて、これら4つの時間軸が指定されている。こうすることで、PlayItemが有するIn_time,Out_timeにより、択一的に再生可能な4つの再生区間が定義されることになる。これにより、PL時間軸には、切り換え可能な複数アングル映像からなる区間(いわゆるマルチアングル区間)が定義されることになる。
【００１８】
PLmark情報(PLmark())は、PL時間軸のうち、任意の区間を、チャプターとして指定する情報である。図６は、PLmark情報の内部構成を示す図であり、本図の引き出し線pm1に示すようにPLmark情報は、『ref_to_PlayItem_Id』と、『Mark_time_stamp』とを含む。図７は、PLmarkによるチャプター定義を示す図である。本図において第1段目は、AVClip時間軸を示し、第2段目はPL時間軸を示す。図中の矢印pk1,2は、PLmarkにおけるPlayItem指定(ref_to_PlayItem_Id)と、一時点の指定(mark_time_stamp)とを示す。これらの指定によりPL時間軸には、3つのチャプター(Chapter#1,#2,#3)が定義されることになる。以上がPLmarkについての説明である。続いてSubPath情報について説明する。
【００１９】
SubPath情報(SubPath())は、SubClipの時間軸上にIn_Time,Out_Timeを指定することで1つ以上の再生区間を定義する情報であり、図８に示す内部構成を有している。本図に示すようにSubPath情報は、破線の引き出し線sh1に示すように複数のSubPlayItem情報(SubPlayItem())からなる。破線sh2を用いてクローズアップしているように、SubPlayItem情報は、『Clip_information_file_name』と、『In_time』と、『Out_time』と、『Sync_PlayItem_Id』と、『Sync_start_Pts_of_PlayItem』とからなる。SubClipの時間軸上に対する、In_Time,Out_Timeの指定は、『Clip_information_file_name』、『In_time』、『Out_time』によりなされる。『Sync_PlayItem_Id』及び『Sync_start_Pts_of_PlayItem』は、SubClip時間軸上の再生区間と、PL時間軸とを同期させるという同期指定をなす。この同期指定により、PL時間軸と、SubPlayItem時間軸とは同期して進行することになる。
【００２０】
図９は、SubPlayItem時間軸上の再生区間定義と、同期指定を示す図である。本図において第1段目は、PL時間軸を示し、第2段目はSubPlayItem時間軸を示す。図中のSubPlayItem.IN_timeは再生区間の始点を、SubPlayItem.Out_timeは再生区間の終点をそれぞれ示す。これによりSubClip時間軸上にも再生区間が定義されていることがわかる。矢印Sn1においてSync_PlayItem_Idは、PlayItemに対する同期指定を示し、矢印Sn2においてsync_start_PTS_of_PlayItemは、PL時間軸におけるPlayItem上の一時点の指定を示す。
【００２１】
複数AVClipの切り換えを可能とするマルチアングル区間や、AVClip−SubClipを同期させ得る同期区間の定義を可能とするのが、BD-ROMにおけるプレイリスト情報の特徴である。以上のClip情報及びプレイリスト情報は、”静的シナリオ”に分類される。何故なら、以上のClip情報及びプレイリスト情報により、静的な再生単位であるPLが定義されるからである。以上で静的シナリオについての説明を終わる。
【００２２】
続いて”動的なシナリオ”について説明する。動的シナリオとは、AVClipの再生制御を動的に規定するシナリオデータである。”動的に”というのは、再生装置における状態変化やユーザからのキーイベントにより再生制御の中身がかわることをいう。BD-ROMでは、この再生制御の動作環境として2つのモードを想定している。1つ目は、DVD再生装置の動作環境と良く似た動作環境であり、コマンドベースの実行環境である。2つ目は、Java（登録商標）仮想マシンの動作環境である。これら2つの動作環境のうち1つ目は、HDMVモードと呼ばれる。2つ目は、BD-Jモードと呼ばれる。これら2つの動作環境があるため、動的シナリオはこのどちらかの動作環境を想定して記述される。HDMVモードを想定した動的シナリオはMovie Objectと呼ばれ、管理情報により定義される。一方BD-Jモードを想定した動的シナリオはBD-J Objectと呼ばれる。
【００２３】
先ず初めにMovie Objectについて説明する。
＜Movie Object＞
Movie Objectは、MovieObject.bdmvというファイルに格納される。図１０は、MovieObject.bdmvの内部構成を示す図である。本図の左端に示すようにMovieObject.bdmvは、コード列”MOBJ”を示す『type_indicater』と、『version_number』と、1つ以上のMovieObjectである『MovieObjects()』とからなる。図中の図中の引き出し線vh1はMovieObjectsの内部構成をクローズアップしている。MovieObjects()は、自身のデータ長である『length』と、自身に含まれるMovieObjectの個数である『number_of_mobjs』と、number_of_mobjs個のMovieObjectである『MovieObjects』とからなる。これらnumber_of_mobjs個のMovieObjectは、識別子mobj_idをもって識別される。図中の引き出し線vh2は、識別子mobj_idにより特定される任意のMovieObject[mobj_id]()の内部構成をクローズアップしている。
【００２４】
この引き出し線に示すように、MovieObjectは、MenuCallがなされた際、MenuCall後の再生再開を意図しているか否かを示す『resume_intention_flag』、MenuCallをマスクするか否かを示す情報『menu_call_mask』、タイトルサーチ機能をマスクするかを示す『title_search_flag』、ナビゲーションコマンドの個数である『number_of_navigation_command』、number_of_navigation_command個の『ナビゲーションコマンド』からなる。
【００２５】
ナビゲーションコマンド列は、条件分岐、再生装置における状態レジスタの設定、状態レジスタの設定値取得等を実現するコマンド列からなる。Movie Objectにおいて記述可能なコマンドを以下に示す。
PlayPLコマンド
書式:PlayPL(第１引数，第２引数)
第１引数は、プレイリストの番号で、再生すべきPLを指定することができる。第２引数は、そのPLに含まれるPlayItemや、そのPLにおける任意の時刻、Chapter、Markを用いて再生開始位置を指定することができる。
【００２６】
PlayItemによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatPlayItem()、
ChapterによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatChapter()、
時刻情報によりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatSpecified Time()という。
JMPコマンド
書式：JMP 引数
JMPコマンドは、現在の動的シナリオを途中で廃棄し(discard)、引数たる分岐先動的シナリオを実行するという分岐である。JMP命令の形式には、分岐先動的シナリオを直接指定している直接参照のものと、分岐先動的シナリオを間接参照している間接参照のものがある。
Movie Objectにおけるナビゲーションコマンドの記述は、DVDにおけるナビゲーションコマンドの記述方式と良く似ているので、DVD上のディスクコンテンツを、BD-ROMに移植するという作業を効率的に行うことができる。Movie Objectについては、以下の国際公開公報に記載された先行技術が存在する。詳細については、本国際公開公報を参照されたい。
国際公開公報W0 2004/074976
以上でMovie Objectについての説明を終える。続いてBD-J Objectについて説明する。
＜BD-J Object＞
BD-J Objectは、Java（登録商標）プログラミング環境で記述された、BD-Jモードの動的シナリオである。
【００２７】
図１１は、BD-J Object.bdmvの内部構成を示す図である。本図の左端に示すようにBD-J Object.bdmvは、コード列”BOBJ”を示す『type_indicater』と、『version_number』と、1つ以上のBD-J Objectである『BD-J Objects()』とからなる。図中の図中の引き出し線bh1はBD-J Objectsの内部構成をクローズアップしている。BD-J Objects()は、自身のデータ長である『length』と、自身に含まれるBD-J Objectの個数である『number_of_bobjs』と、number_of_bobjs個のBD-J Objectである『BD-J Objects』とからなる。これらnumber_of_bobjs個のBD-J Objectは、識別子bobj_idをもって識別される。図中の引き出し線bh2は、識別子bobj_idにより特定される任意のBD-J Object[bobj_id]()の内部構成をクローズアップしている。
【００２８】
この引き出し線に示すように、本図に示すようにBD-J Objectは、『resume_intention_flag[bobj_id]』と、『menu_call_mask[bobj_id]』と、『title_search_flag[bobj_id]』と、『Application_Management_Table[bobj_id]』と、『Playlist_Management_Table[bobj_id]』とからなる。『resume_intention_flag』、『menu_call_mask』、『title_search_flag』を含んでいる点においてBD-J ObjectはMovie Objectとほぼ同じである。
【００２９】
Movie Objectとの違いは、BD-J Objectにコマンドが直接記述されていない点である。つまりMovie Objectにおいて制御手順は、ナビゲーションコマンドにより直接記述されていた。これに対しBD-J Objectでは、Java（登録商標）アプリケーションに対する指定を『Application_Management_Table[bobj_id]』上に記載することにより、間接的に制御手順を規定している。このような間接的な規定により、複数動的シナリオにおいて制御手順を共通化するという、制御手順の共通化を効率的に行うことができる。
【００３０】
またMovieObjectにおけるPL再生は、PL再生を命じるナビゲーションコマンド(PlayPlコマンド)の記述によりなされていたが、BD-J ObjectにおけるPL再生は、PL再生手順を示す  『Playlist_Management_Table[bobj_id]』をBD-J Objectに組み込むことで記述が可能になる。それだけではなくアプリケーション管理テーブルから参照されるアプリケーションに、PL再生手順を組み込むことでも記述が可能になる。つまりプレイリスト管理テーブルの記述、アプリケーションにおけるPL再生手順の記述のどちらであっても、プレイリスト再生の手順を組み込んでおくことができる。
【００３１】
ここでJava（登録商標）アプリケーションについて説明する。Java（登録商標）アプリケーションは、仮想マシンのヒープ領域(ワークメモリとも呼ばれる)にロードされた1つ以上のxletプログラムからなる。このワークメモリにロードされたxletプログラム、及び、データから、アプリケーションは構成されることになる。以上がJava（登録商標）アプリケーションの構成である。
【００３２】
このJava（登録商標）アプリケーションの実体にあたるのが、図２におけるBDMVディレクトリ配下のBDJAディレクトリに格納されたJava（登録商標）アーカイブファイル(00001.jar,00002.jar)である。以降、Java（登録商標）アーカイブファイルについて、図１２を参照しながら説明する。
＜Java（登録商標）アーカイブファイル＞
Java（登録商標）アーカイブファイル(図２の00001.jar,00002.jar)は、1つ以上のクラスファイル、1つ以上のデータファイル等を1つにまとめることで得られるファイルである。図１２（ａ）は、アーカイブファイルにより収められているプログラム、データを示す図である。本図におけるデータは、枠内に示すディレクトリ構造が配置された複数ファイルを、Java（登録商標）アーカイバでまとめたものである。枠内に示すディレクトリ構造は、Rootディレクトリ、Java（登録商標）ディレクトリ、imageディレクトリとからなり、Rootディレクトリにcommon.pkgが、Java（登録商標）ディレクトリにクラスファイル(aaa.class,bbb.class)が、imageディレクトリに、menu.jpgが配置されている。Java（登録商標）アーカイブファイルは、これらをJava（登録商標）アーカイバでまとめることで得られる。かかるクラスファイル及びデータは、BD-ROMからキャッシュに読み出されるにあたって展開され、キャッシュ上で、ディレクトリに配置された複数ファイルとして取り扱われる。Java（登録商標）アーカイブファイルのファイル名における"zzzzz"という5桁の数値は、アプリケーションのID(applicationID)を示す。本Java（登録商標）アーカイブファイルがキャッシュに読み出された際、このファイル名における数値を参照することにより、任意のJava（登録商標）アプリケーションを構成するプログラム，データを取り出すことができる。
本図におけるクラスファイル(図中のaaa.class,bbb.class)は、上述したxletプログラムに対応するクラスファイルである。BD-Jモードにおける再生手順は、このクラスファイルのインスタンスにあたるxletプログラムにより規定される。
【００３３】
xletプログラムとは、JMF(Java（登録商標） Media FrameWork)方式のインターフェイスを利用することができるJava（登録商標）プログラムであり、JMF等の方式に従って、キーイベントに基づく処理を行う。xletプログラムは、JMF方式の処理が可能であるので、MPLSファイルに対するインスタンス(JMFプレーヤインスタンス)を生成することにより、プレイリスト再生を再生装置に命じることができる。他にもxletプログラムでは、ファンクションAPIのコールを記述することにより、BD-ROM再生装置特有の処理を実行させることができる。
【００３４】
更にxletプログラムは、WWWサイトをアクセスしてコンテンツをダウンロードするという手順を実行することもできる。これによりダウンロードコンテンツと、プレイリスト再生とを交えた斬新な作品を再生させることができる。
xletプログラムのクラスファイルについて説明する。図１２（ｂ）は、クラスファイルの内部構成を示す図である。本図に示すようにクラスファイルは、通常のクラスファイル同様、『コンスタントプール』、『インターフェイス』、『メソッド1,2,3・・・・n』からなる。クラスファイルにおけるメソッドには、挙動のトリガになるキーイベントが予め登録されているメソッド(EventListner)と、JMFの再生手順を命じるメソッド(JMFプレーヤインスタンスのメソッド)、BD-ROM再生装置側のファンクションAPIをコールするメソッドがある。これらのメソッドは、自身に割り当てられたローカル変数や、自身をコールする際の引数を用いることにより、演算等の手順が記述されている。以上がJava（登録商標）アーカイブファイルについての説明である。尚、本実施形態においてアプリケーションを構成するプログラム、データは、Java（登録商標）アーカイブファイルにまとめられたが、LZHファイル、zipファイルであってもよい。
【００３５】
以上が、BD-Jモードにおける動的シナリオについての説明である。
＜BD-ROMにおける状態遷移＞
DVD-Videoのような読出専用ディスクで供給されるディスクコンテンツは、トップメニューを中核とした構造になっている。そのトップメニューから、個々の著作物へと分岐して再生を行い、その後再び、TopMenu Titleに戻るという独特の状態遷移をなす。図１３は、ディスクコンテンツにおける状態遷移を示す図である。本図における四角枠は、Titleである。Titleとは、ディスクコンテンツ特有の状態遷移において、1つの”状態”にあたる再生単位である。Titleには、BD-ROMのローディング時に最初に再生される『FirstPlayTitle』、Top-Menuを構成する『Top_menuTitle』、これら以外の一般的な『Title』がある。また、図中の矢印jh1,2,3,4,5,6,7,8は、Title間の分岐を象徴的に示す。本図に示される状態遷移とは、BD-ROMローディング時に、『FirstPlayTitle』が再生され、『Top_menuTitle』への分岐が発生して、トップメニューに対する選択待ちになるというものである。BD-ROMのような映画作品頒布用の記録媒体の業界では、動的商標を、ローディング時に再生するという慣習が定着している。この動的商標は、映画作品の制作者や頒布者を表徴するものであり、FirstPlayTitleは、BD-ROMのローディングされた際、なによりも先に、この動的商標を再生させるという役割分担を担う。
【００３６】
そしてユーザによるメニューに対する選択操作があれば、選択に従って該当Titleの再生を行い、再びTopMenu Titleに戻るとの処理を、BD-ROMのイジェクトがなされるまで延々と繰り返すというのが、ディスクコンテンツ特有の状態遷移である。
かかる状態遷移をなすTitleは、HDMVモードの動的シナリオ、BD-Jモードの動的シナリオから構成される。図１４は、HDMVモードの動的シナリオから構成される2つのTitleを示す図である。本図の第1段目は、識別子title_idにより識別される任意のTitle(title_id)を示す。第2段目は、そのTitleを構成している1つ以上のMovieObjectからなるMovieObject列を示す。第3段目は、MovieObjectを構成するナビゲーションコマンドを示す。
【００３７】
他のTitleへのJumpを再生装置に命じるナビゲーションコマンド(JumpTitleコマンド)をMovieObjectに記述しておくことにより、図１３に示したような、あるTitleから別のTitleへの分岐が実現されることになる。またPL再生を命じるナビゲーションコマンド(PlayPLコマンド)をMovieObjectに記述しておくことにより、本図第4段目に示すPLが、Titleに帰属することになる。
【００３８】
PLを帰属させることにより、HDMVモードにおけるTitleでは、動画再生を伴う映画作品を定義することができる。これがHDMVモードの動的シナリオにより定義されるTitleの構成である。
続いてBD-Jモードの動的シナリオにより構成されるTitleの内部構成について説明する。図１５は、BD-Jモードの動的シナリオ(BD-J Object)により構成されるTitleの内部構成を示す図である。
【００３９】
第1段目は、識別子title_idにより識別される任意のTitleを示し、第2段目は、そのTitleを構成する唯一のBD-J Objectを示す。第3段目は、そのBD-J Objectの内部にあるアプリケーション管理テーブル、プレイリスト管理テーブルを示す。第4段目は、第3段目のアプリケーション管理テーブルにより動作することになるアプリケーションを示す。このアプリケーションは、第5段目に示すように、他のTitleへのJumpを再生装置に命じるメソッド(JumpTitleAPIをコールするメソッド)を含んでいるので、JumpTitleAPIのコールメソッドにより、図１３に示した他ののTitleへの分岐が実現することになる。一方、第3段目にはプレイリスト管理テーブルが記述されているので、第4段目にあたっては、アプリケーションの実行と共にPLが再生されることになる。
【００４０】
BD-J Objectには、アプリケーション管理テーブル，プレイリスト管理テーブルが含まれているので、第4段目に示すように、アプリケーション実行と、PL再生とが同時になされることになる。このようなアプリケーション実行と、PL再生との同時実行がBD-JモードにおけるTitleの特徴である。
プレイリスト管理テーブルは、全てのBD-J Objectに存在する訳ではない。プレイリスト管理テーブルは任意的な構成要素であり、プレイリスト管理テーブルをもつBD-J Objectもあるし、プレイリスト管理テーブルをもたないBD-J Objectもある。図１６は、プレイリスト管理テーブルをもたないTitleを示す図である。アプリケーション管理テーブルしか存在しないため、プレイリスト管理テーブルをもたないようなBD-J Objectでは、第4段目に示すように、アプリケーション動作のみが規定される。以上によるアプリケーション動作の規定により、PL再生を伴わない、制御手順のみのTitleが規定されることになる。
【００４１】
また図１４ではHDMVモードのTitleから、HDMVモードのTitleへの分岐が記述されていたが、図１７に示すようにHDMVモードのTitleから、BD-JモードのTitleへの分岐もありえる。同様に図１５ではBD-JモードのTitleから、BD-JモードのTitleへの分岐が記述されていたが、図１８に示すようにBD-JモードのTitleから、HDMVモードのTitleへの分岐もありえる。
【００４２】
上述したTitleの内部構成において、あるTitleの構成要素となるMovieObjectはどれであるか、又は、あるTitleの構成要素となるBD-J Objectはどれであるのかを定義するのが、図２に示したindex.bdmvである。以降index.bdmvについて説明する。
Index.bdmvは、タイトルを構成する、Movie Object又はBD-J Objectを示すテーブルである。
【００４３】
図１９は、index.bdmvの内部構成を示す図である。本図に示すようにindex.bdmvは、値”INDX”を示す値をもつ『type_indicator』と、『version_number』と、本ファイルの先頭からIndexesまでの相対アドレスを示す『Indexes_start_address』と、『Indexes()』とからなる。『Indexes』は、各Titleに対するインデックスであり、破線の引き出し線ix1でクローズアップしているように、『Indexes』は、『length』,『FirstPlayback(){FirstPlayback_mobj_id_ref}』,『TopMenu(){TopMenu_mobj_id_ref}』,『number_of_Titles』,『Title[0]()〜Title[number_of_Titles-1]()』からなる。
【００４４】
『FirstPlayback(){FirstPlayback_mobj_id_ref}』は、FirstPlayTitleに対するIndexであり、FirstPlayTitleを構成するMovieObject識別子の参照値(FirstPlayback_mobj_id_ref)が格納される。
『TopMenu(){TopMenu_mobj_id_ref}』は、Top-MenuTitleに対するIndexであり、Top_menuTitleを構成するMovieObject識別子の参照値(TopMenu_mobj_id_ref)が格納される。
【００４５】
『Title[0]()〜Title[number_of_Titles-1]()』は、FirstPlayTitle、Top-MenuTitle以外のTitleに対するIndexであり、number_of_Title個存在している。これらは識別子title_idをもって識別される。
ここで識別子title_idにより特定されるインデックスをTitle[title_id]()とする。図中の引き出し線ix2は、Title[title_id]()に対する内部構成をクローズアップしている。
【００４６】
本図に示すように”Title[title_id]()”は、”Title[title_id]が、分岐をもっているか否か等、Titleの再生の類型を示す『Title_Playback_Type[title_id]』と、このTitleに対するサーチ機能の実行が許可されているか否かを示す『Title_access_Flag[title_id]』と、Titleを構成するMovieObjectを一意に示す『title_mobj_id_ref[title_id]』とからなる。ここでTitleを構成する動的シナリオがBD-J Objectであれば、『title_bobj_id_ref[title_id]』が『title_mobj_id_ref[title_id]』の代わりになる。『title_bobj_id_ref[title_id]』は、Titleを構成するBD-J Objectを一意に示す。
Index.bdmvについては、以下の国際公開公報に詳細が記載されている。詳細については、本公報を参照されたい。
国際公開公報WO 2004/025651 A1公報
＜アプリケーション管理テーブル＞
BD-J Objectに含まれるアプリケーション管理テーブル及びプレイリスト管理テーブルは、本実施形態の主眼となる構成要素であり、その詳細について説明する。先ずアプリケーション管理テーブル(AMT)について説明する。
【００４７】
図２０（ａ）は、アプリケーション管理テーブルの内部構成を示す図である。本図に示すようにアプリケーション管理テーブルは、『life_cycle』と、『apli_id_ref』と、『run_attribute』と、『run_priority』からなる。
図２０（ｂ）は、アプリケーション管理テーブルを構成する情報要素の意味内容を示す。
【００４８】
『life_cycle』は、アプリケーションの”生存区間”を示す。
『apli_id_ref』は、”アプリケーション識別子”に対する参照値が記述されることにより、左記の生存区間をもつアプリケーションがどれであるかを示す。アプリケーション識別子は、Java（登録商標）アーカイブファイルにおいて、ファイル名として付与された5桁の数値zzzzzで表現される。『apli_id_ref』には、この5桁の数値が記述される。
【００４９】
『run_attribute』は、当該生存区間におけるアプリケーションの”起動属性”が記述される。起動属性には、AutoRun、Present、Suspedといった種別がある。
『run_priority』は、当該生存区間におけるアプリケーションの”起動優先度”が記述される。BD-J Objectでは、これらの情報を用いてアプリケーションの挙動を制御する。
＜生存区間＞
アプリケーション管理テーブルに規定される情報のうち、生存区間について説明する。
【００５０】
生存区間とは、BD-ROMに記録されたコンテンツ全体の時間軸において、仮想マシンのワークメモリ上でアプリケーションが生存し得る区間を示す。ワークメモリにおける”生存”とは、そのアプリケーションを構成するxletプログラムが、ワークメモリに読み出され、仮想マシンによる実行が可能になっている状態をいう。
Java（登録商標）仮想マシンにおいてアプリケーションを動作させる場合、時間軸の何処からアプリケーションによるサービスを開始し、時間軸の何処でアプリケーションによるサービスを終えるかという”サービスの開始点・終了点”を明確に規定することが重要になる。このサービスの開始点・終了点を規定するのが、アプリケーション管理テーブルにおける生存区間である。
【００５１】
それでは、図１３のような状態遷移をなすディスクコンテンツにおいて、Titleの生存区間はどのように規定されるのであろうか。BD-ROMのローディングがなされた後、図１３において矢印jh1,2,3,4・・・・・に示された参照符号の数値順に分岐がなされ、BD-ROMがイジェクトされたものとする。そうすると、BD-ROMがローディングされてから、イジェクトされるまでの連続時間帯を一本の時間軸と同視することができる。この時間軸を、ディスク全体の時間軸とする。図２１（ａ）は、ディスク全体の時間軸を示す図であり、図２１（ｂ）は、この時間軸における構成を示す。図２１（ｂ）に示すように、ディスク全体の時間軸は、FirstPlay Titleが再生されている区間、TopMenu Titleが再生されている区間、title#1が再生されている区間等からなる。これらTitleの再生区間はどのように規定されているかというと、Titleは、1つ以上のMovieObject、又は、唯一のBD-J Objectから構成されるから、どれかのMovieObject又はBD-J Objectが、有効になっている期間をTitleの再生区間と考えることができる。
【００５２】
つまりFirstPlay Title、TopMenu Title、その他のTitleは、何れも動的シナリオから構成されるから、Titleを構成するMovieObject又はBD-J Objectのうち、どれかがカレントMovieObject、又は、カレントBD-J ObjectとしてActivatedされ、再生装置内において解読・実行に供されている期間を、Titleの再生区間と定義することができる。図２２（ａ）は、BD-ROM全体の時間軸において、識別子bobj_idにより特定されるBD-J Objectから特定されるタイトル再生区間を示す図である。ここで識別子bobj_idにより特定されるBD-J Objectが、1つのTitleを構成しているなら、その識別子bobj_idにより特定されるBD-J Objectが有効になっているBD-ROM時間軸上の一区間を、Titleの再生区間と考えることができる。
【００５３】
同様に、識別子mobj_idにより特定されるMovieObjectが、1つのTitleを構成しているなら、その識別子mobj_idにより特定されるMovieObjectが有効になっている、BD-ROM時間軸上の一区間を、Titleの再生区間と考えることができる。
ここでMovieObject、BD-J ObjectがActivateされている期間の終期は、Title分岐(JumpTitle)がなされるまでである。つまり、Title分岐(JumpTitle)がなされるまで、実行の対象になっている動的シナリオは、カレントMovieObject及びカレントBD-J Objectとして扱われるから、そのMovieObject又はBD-J ObjectにおいてJumpTitleが発生するまでの1つの区間を、Title再生区間として扱う。
【００５４】
続いてTitle区間と、PL時間軸との関係について説明する。上述したようにMovieObject、BD-J Objectでは、1つの処理手順としてPL再生手順を記述することができる。PL再生手順の記述があれば、上述したPL時間軸の全部又は一部がTitle区間に帰属することになる。図２２（ａ）の一例においてBD-J Objectに、プレイリスト管理テーブルが記述されているとする。この場合、BD-J Objectに対応するTitle区間には、図２２（ｂ）に示すように、PL時間軸が帰属する。このPL時間軸には更に、複数チャプター(Chapter#1,#2,#3)が定義され得るため、BD-ROM上の時間軸には、BD-ROM全体−Title−PL−チャプターというドメインが存在することになる。これらのドメインを用いて、アプリケーションの生存区間を記述することができる。尚、プレイリスト再生は、アプリケーション実行と同時になされため、プレイリスト再生の途中で、Title分岐が発生することがある。この場合、1つのTitle再生区間内にはプレイリスト時間軸全体ではなく、プレイリスト時間軸の一部分のみが帰属することになる。つまり1つのTitleの再生区間において、プレイリスト時間軸の全体が帰属するか、その一部分が帰属するかは、Title分岐が何時発生するかによって変わる。
【００５５】
図２３は、図２２（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。本図に示すようにアプリケーションには、Titleを生存区間にした”タイトルバウンダリアプリケーション”、Title内におけるチャプターを生存区間にした”チャプターバウンダリアプリケーション”、BD-ROM全体の時間軸を生存区間にした”タイトルアンバウンダリーアプリケーション”という3つの典型がある。
【００５６】
このうちタイトルバウンダリアプリケーションの生存区間は、そのタイトルの識別子を用いて定義することができる。またチャプターバウンダリアプリケーションの生存区間は、チャプターが属するタイトルの識別子と、そのチャプターの識別子との組みを用いて定義することができる。  
プラットフォームが動作していたとしても、Titleやチャプターという生存区間が終われば、リソースをアプリケーションから回収することができる。リソース回収の機会を保証するので、プラットフォームの動作を安定化させることができる。
【００５７】
近い将来、実施されるであろうディスクコンテンツを題材に選んで、アプリケーション管理テーブルにおける生存区間記述について、具体例を交えて説明する。ここで題材にするディスクコンテンツは、映像本編を構成する本編タイトル(title#1)、オンラインショッピングを構成するオンラインショッピングタイトル(title#2)、ゲームアプリケーションを構成するゲームタイトル(title#3)という、性格が異なる3つのタイトルを含むものである。図２４は、本編タイトル、オンラインショッピングタイトル、ゲームタイトルという3つのタイトルを含むディスクコンテンツを示す図である。本図における右側にはIndex.bdmvを記述しており、左側には3つのタイトルを記述している。
【００５８】
右側における破線枠は、各アプリケーションがどのタイトルに属しているかという帰属関係を示す。3つのタイトルのうちtitle#1は、application#1、application#2、application#3という3つのアプリケーションからなる。title#2は、application#3、application#4という2つのアプリケーション、title#3は、application#5を含む。図２４の一例においてapplication#3は、title#1、title#2の双方で起動される。
【００５９】
図２４の破線に示される帰属関係から各アプリケーションの生存区間をグラフ化すると、図２５（ａ）のようになる。本図において横軸は、タイトル再生区間であり、縦軸方向に各アプリケーションの生存区間を配置している。ここでapplication#1、application#2は、title#1のみに帰属しているので、これらの生存区間は、title#1内に留まっている。application#4は、title#2のみに帰属しているので、これらの生存区間は、title#2内に留まっている。application#5は、title#3のみに帰属しているので、これらの生存区間は、title#3内に留まっている。application#3は、title#1及びtitle#2に帰属しているので、これらの生存区間は、title#1−title#2にわたる。この生存区間に基づき、アプリケーション管理テーブルを記述すると、title#1,#2,#3のアプリケーション管理テーブルは図２５（ｂ）のようになる。このようにアプリケーション管理テーブルが記述されれば、title#1の再生開始時においてapplication#1、application#2、application#3をワークメモリにロードしておく。そしてtitle#2の開始時にapplication#1、application#2をワークメモリから削除してapplication#3のみにするという制御を行う。これと同様にtitle#2の再生開始時においてapplication#4をワークメモリにロードしておき、title#3の開始時にapplication#3,#4をワークメモリから削除するという制御を行いうる。
【００６０】
更に、title#3の再生中においてapplication#5をワークメモリにロードしておき、title#3の再生終了時にapplication#5をワークメモリから削除するという制御を行いうる。
タイトル間分岐があった場合でも、分岐元−分岐先において生存しているアプリケーションはワークメモリ上に格納しておき、分岐元にはなく、分岐先にのみ存在するアプリケーションをワークメモリに読み込めば良いから、アプリケーションをワークメモリに読み込む回数は必要最低数になる。このように、読込回数を少なくすることにより、タイトルの境界を意識させないアプリケーション、つまりアンバウンダリなアプリケーションを実現することができる。
【００６１】
続いてアプリケーションの起動属性についてより詳しく説明する。起動属性には、自動的な起動を示す「AutoRun」、自動起動の対象ではないが、仮想マシンのワークメモリに置いて良いことを示す「Present」、仮想マシンのワークメモリにはおかれるが、CPUパワーの割り当ては不可となる「Suspend」がある。
「AutoRun」は、対応するタイトルの分岐と同時に、そのアプリケーションをワークメモリに読み込み、且つ実行する旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、その分岐先タイトルにおいて生存しており、かつ起動属性がAutoRunに設定されたアプリケーションを仮想マシンのワークメモリに読み込み実行する。これによりそのアプリケーションは、タイトル分岐と共に自動的に起動されることになる。
【００６２】
起動属性「Present」は、継続属性であり、分岐元titleにおけるアプリケーションの状態を継続することを示す。また対応するアプリケーションを実行してよいことを示す属性である。起動属性が「Present」である場合、この起動属性が付与されたアプリケーションは、他のアプリケーションからの呼び出しが許可されることになる。アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、起動中のアプリケーションから呼出があると、そのアプリケーションのapplicationIDが、アプリケーション管理テーブルに記述されていて、起動属性が「Present」であるか否かを判定する。「Present」であれば、そのアプリケーションをワークメモリにロードする。一方、その呼出先アプリケーションのapplicationIDがアプリケーション管理テーブルに記述されていない場合、そのアプリケーションはワークメモリにロードされない。アプリケーションによる呼出は、この「Present」が付与されたアプリケーションに限られることになる。「Present」は、起動属性を明示的に指定しない場合に付与されるデフォルトの起動属性であるから、あるアプリケーションの起動属性が無指定「−−」である場合、そのアプリケーションの起動属性の起動属性はこのPresentであることを意味する。
【００６３】
「Suspend」とは、リソースは割り付けられているが、CPUパワーは割り当てられない状態にアプリケーションが置かれることをいう。かかるSuspendは、例えばゲームタイトルの実行中に、サイドパスを経由するという処理の実現に有意義である。
図２６は、起動属性がとり得る三態様(Present、AutoRun、Suspend)と、直前タイトルにおけるアプリケーション状態の三態様(非起動、起動中、Suspend)とがとりうる組合せを示す図である。直前状態が”非起動”である場合、起動属性が”AutoRun”であるなら、分岐先タイトルにおいてそのアプリケーションは、起動されることになる。
【００６４】
直前状態が”非起動”であり、起動属性が”Present”、”Suspend”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。
直前状態が”起動中”である場合、起動属性が”Present”、”AutoRun”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。
【００６５】
起動属性が”Suspend”であるなら、アプリケーションの状態はSuspendされることになる。直前状態が”Suspend”である場合、分岐先タイトルの起動属性が”Suspend”ならSuspendを維持することになる。”Present”又は”AutoRun”であるなら、分岐先タイトルにおいてそのアプリケーションは、レジュームすることになる。アプリケーション管理テーブルにおいて生存区間及び起動属性を定義することにより、タイトル再生区間の進行に沿って、Java（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。
【００６６】
尚、直前状態が”Suspend”であり、分岐先タイトルの起動属性が”Present”の場合は、直前状態、すなわちサスペンド状態を維持しても良い。
最後に、各アプリケーションに対する”起動優先度”について説明する。
この起動優先度は、0〜255の値をとり、メモリリソース枯渇時や、CPU負荷が高まった時に、どのアプリケーションを強制的に終了させるか、また、どちらのアプリケーションからリソースを奪うかという処理をアプリケーションマネージャが行うにあたっての判断材料になる。この場合、アプリケーションマネージャは、起動優先度が低いアプリケーションの動作を終了し、起動優先度が高いアプリケーションの動作を継続させるとの処理を行う。
【００６７】
また起動優先度は、再生中PLに対する要求が競合した場合のアプリケーション間の調停でも利用される。ここであるアプリケーションが、あるプレイリストの早送りしているものとする。ここで別のアプリケーションが同じプレイリストに対するポーズ要求を行ったとすると、これらのアプリケーションに付与された起動優先度を比較する。そして早送りを命じたアプリケーションの起動優先度が高いなら、かかるアプリケーションによる早送りを継続して行う。逆にポーズを命じたアプリケーションの起動優先度が高いなら、早送り中PLをポーズを行う。
【００６８】
以上の生存区間・起動属性・起動優先度により、仮想マシン上で動作し得るアプリケーションの数を所定数以下に制限するよう規定しておくことがオーサリング時に可能なる。そのため、アプリケーションの安定動作を保証することができる。
＜プレイリスト管理テーブル＞
以上がアプリケーション管理テーブルについての説明である。続いてプレイリスト管理テーブルについて説明する。プレイリスト管理テーブルとは、アプリケーションの生存区間において、各アプリケーション実行と同時に行うべき再生制御を示すテーブルである。アプリケーションの動作というのは不安定であり、起動の失敗や異常終了がありうる。そこで起動失敗、異常終了があった場合のFail Safe機構として、本実施形態ではアプリケーションの生存区間毎に、プレイリスト管理テーブルを設けている。プレイリスト管理テーブルは、あるアプリケーションの生存区間が開始した際、これと同時に行うべき再生制御を規定する情報である。この再生制御とは、プレイリスト情報に基づくAVClip再生であり、プレイリスト情報による再生制御を同時に行うことで、アプリケーション実行と、プレイリスト再生とが同時になされることになる。プレイリスト管理テーブルは、アプリケーションの生存区間毎に設けられるとしたが、プレイリスト管理テーブルが設けられるアプリケーションは、タイトルバウンダリのアプリケーションに限られる。何故ならタイトルアンバウンダリーアプリケーションは、全タイトルを生存区間にしているため、アプリケーション実行と同時にプレイリスト再生を行うという制御は、適合しないからである。
【００６９】
チャプターバウンダリアプリケーションは、1つのプレイリスト内のチャプターからアプリケーション実行を開始するという前提の下で生存区間が規定されているため、プレイリスト再生を規定する必要はないからである。以上のことからプレイリスト管理テーブルは、1つ以上のTitleからなる生存区間に定義されることになる。
図２７（ａ）は、プレイリスト管理テーブルの内部構成を示す図である。本図に示すようにプレイリスト管理テーブルは、『PL_id_ref』と、『Playback_Attribute』とからなる。
【００７０】
図２７（ｂ）は、プレイリスト管理テーブルを構成する情報要素の意味内容を示す。
『PL_id_ref』は、PL識別子に対する”参照値”が記述されることにより、アプリケーションの生存区間において再生可能となるPLがどれであるかを示す。PL識別子は、ファイルYYYYY.MPLSにおいて、ファイル名として付与された5桁の数値YYYYYで表現される。このYYYYYが記述されることにより、『PL_id_ref』は、対応するTitleにおいて再生可能となるPLがどれであるかを示す。
【００７１】
『Playback_Attribute』は、アプリケーション管理テーブルにおける起動属性に倣った属性であり、『PL_id_ref』に記述されたPLを、タイトル開始時において、どのように再生するかを規定する再生属性である。PLに対する再生属性には、『AutoPlay』、『Present』といった種別がある。
『AutoPlay』とは、対応するタイトルの分岐と同時に、そのプレイリストを再生させる旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、その分岐先タイトルにおいて再生可能であり、かつ再生属性がAutoPlayに設定されたプレイリストの再生を開始する。これにより起動属性がAutoPlayに設定されたプレイリストは、タイトル分岐と共に自動的に起動されることになる。
【００７２】
『Present』とは、起動属性におけるPresent同様、継続属性であり、分岐元titleにおけるPLの状態を継続することを示す。また対応するプレイリストを再生してよいことを示す属性である。例えば連続して再生される2つのTitleがあり、分岐元Title側のプレイリスト管理テーブルでは、あるプレイリストの再生属性がAutoPlayに設定され、分岐先Title側のプレイリスト管理テーブルでは、そのプレイリストの再生属性がPresentに設定されているものとする。ここでプレイリストの再生時間が2時間長であり、このうち1時間が経過した時点で分岐が発生したとする。この場合分岐先Titleでは、再生属性がPresentに設定されているので、分岐先Titleにおいて、そのプレイリストは、1時間という再生済み区間の直後から、再生されることになる。このように再生属性をPresentに設定しておけば、Title間の分岐があった場合でも、プレイリスト再生をその残りの部分から開始することができる。これにより分岐し合う一連のTitleにおいて、共通のプレイリストを再生するという”タイトル間におけるプレイリスト再生の共通化”を容易に実現することができる。また分岐先タイトルが複数ある場合、これら複数タイトルの再生属性を何れもPresentにしておけば、複数のうちどれに分岐したとしても、1つの共通のプレイリスト再生を継続させることができる。
【００７３】
尚Titleの境界は、シームレス再生を保証しなくてもよいので、上述したように複数Title間で1つのプレイリストを再生しようとする場合、分岐前後でプレイリスト再生を中断させることは許容される。
また、再生属性が「Present」である場合、この再生属性が付与されたプレイリストは、他のアプリケーションからの再生要求により再生されることになる。アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、起動中のアプリケーションから、プレイリストの再生要求があると、要求を受けたプレイリストのPL_id_refが、プレイリスト管理テーブルに記述されていて、再生属性が「AutoPlay」か「Present」のいずれかか否かを判定する。「AutoPlay」か「Present」のいずれかであれば、そのプレイリストを再生する。一方、要求を受けたプレイリストのPL_id_refがプレイリスト管理テーブルに記述されていない場合、そのプレイリストを再生しない。アプリケーションの要求によるプレイリスト再生は、この「AutoPlay」か「Present」のいずれかが付与されたプレイリストに限られることになる。「Present」は、再生属性を明示的に指定しない場合に付与されるデフォルトの再生属性であるから、あるプレイリストの再生属性が無指定「−−」であるとそのプレイリストの再生属性はこのPresentであることを意味する。
【００７４】
図２８は、分岐先Titleがとり得る三態様(プレイリスト管理テーブル無し(i)、プレイリスト管理テーブル有りで尚且つAutoPlay(ii)、プレイリスト管理テーブル有りで尚且つPresent(iii))と、直前タイトルにおけるPLの状態(非再生状態、再生中状態)とがとりうる6通りの組合せを示す図である。
本図における6通りの組合せのうち、”直前状態＝非再生状態”と、”分岐先Title＝プレイリスト管理テーブル有り、尚且つ、分岐先Titleの再生属性＝AutoPlay”との組合せにおいて、分岐先タイトルにおけるPLの再生は、自動的に開始することになる。
【００７５】
また”直前状態＝再生中状態”と、”分岐先Title＝プレイリスト管理テーブル無し”との組合せにおいて、分岐先タイトルでのPLの再生は、自動的に停止することになる。
そしてこれら2つの組合せ以外は全て、分岐元Titleの状態を継続することになる。プレイリスト管理テーブルに基づくプレイリスト再生の開始は、分岐元タイトルにおいて非再生状態であり、分岐先タイトルにおいてAutoPlay属性が付与されている場合に限られるので、タイトルの分岐発生する毎に、プレイリスト再生を開始させる必要はない。タイトル間の分岐が多数発生したとしても、プレイリスト再生を開始させる回数を必要最低数にすることができる。
プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例について図２９（ａ）を参照しながら説明する。ここで想定する具体例は、2つの連続するTitle(title#1、title#2)であリ、そのうちtitle#1では、AutoRunアプリケーションとしてapplication#1、application#2が記述されている。title#2ではAutoRunアプリケーションとしてapplication#2、application#3が記述されている。一方、title#1のプレイリスト管理テーブルには、AutoPlayプレイリストとしてPlayList#1が、title#2のプレイリスト管理テーブルには、AutoPlayプレイリストとしてPlayList#2が記述されているものとする。図２９（ｂ）は、図２９（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。
【００７６】
title#1においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、title#1の開始時にはapplication#1、application#2が自動的に起動され、PlayList#1の再生が自動的に開始される。
title#2においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、title#1側に記載はあるが、title#2側には記載がないapplication#1の実行は停止させられる。同じくtitle#1側に記載があるが、title#2側に記載がないPlayList#1の再生も停止させられる。
【００７７】
title#1側に記載はないが、title#2側に記載があるPlayList#2、application#3は再生及び実行が自動的に開始することになる。タイトル分岐があれば、その分岐を契機に、再生すべきプレイリストを他のプレイリストに切り換えることができる。このようにアプリケーション管理テーブル、プレイリスト管理テーブルを用いることで分岐を契機にして、プレイリスト再生を切り換えるという処理をオーサリング段階において規定しておくことができる。
【００７８】
また図２９では、application#1、application#2、application#3にはそれぞれ200,128,200の起動優先度が与えられている。これらの起動優先度を付与することにより、PlayList#1、PlayList#2に対する制御要求が競合した場合の調停を行わせることができる。ここでapplication#1がPlayList#1に対し早送りを命じているものとする。一方、application#2がポーズ要求を行ったとする。この場合、アプリケーション管理テーブルに各アプリケーションに対する起動優先度が規定されているため、この起動優先度に従って、両アプリケーションに対する調停がなされることになる。その結果、application#2による要求を退け、application#1による制御を継続するという処理をオーサリング時に規定しておくことができる。起動優先度をプレイリスト管理テーブルと併せて利用することにより、プレイリストに対する制御が競合した場合の調停さえも再生装置に行わせることができる。
【００７９】
プレイリスト管理テーブル記述の他の具体例について説明する。図３０（ａ）は、プレイリスト管理テーブルの他の記述例を示す図である。本図で想定しているのは、2つの連続するタイトル(title#1、title#2)において、title#1側のプレイリスト管理テーブルには、AutoPlayプレイリストとしてPlayList#1が、再生可能なプレイリストとしてPlayList#2が記述され、title#1側のアプリケーション管理テーブルには、AutoPlayアプリケーションであるapplication#1と、実行可能なアプリケーションとしてapplication#2が記述されている。一方title#2側のプレイリスト管理テーブルには再生可能なプレイリストとしてPlayList#2、PlayList#3が記述され、アプリケーション管理テーブルには、AutoRunアプリケーションとしてapplication#3が記述されている。図３０（ｂ）は、図３０（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。title#1のアプリケーション管理テーブルには、AutoRunアプリケーションとしてapplication#1が記述されているので、title#1の開始時にはapplication#1が自動起動される。一方、title#1のアプリケーション管理テーブルには、実行可能アプリケーションとしてapplication#2が記述されているので、application#1からの呼出yd1によりapplication#2が起動される。
【００８０】
title#2側のアプリケーション管理テーブルにおいてapplication#1、application#2が非生存になっており、代わりにAutoRunアプリケーションとしてapplication#3が記述されている。そのためtitle#1−title#2の境界部では、application#1、application#2を停止し、application#3を自動的に起動するとの処理がなされる。プレイリスト管理テーブルを参照すると、title#1側のプレイリスト管理テーブルは、PlayList#1、PlayList#2が再生可能と記述されており、そのうちPlayList#1はAutoPlay属性になっている。そのためPlayList#1は、title#1の開始時において自動的に再生される。
【００８１】
title#1側のプレイリスト管理テーブルには、PlayList#1の他、PlayList#2が再生可能であると記述されているので、application#1はPlayList#1の再生を停止させ、代わりにPlayList#2の再生を要求することにより、プレイリスト交代を実行することができる。
title#2側のプレイリスト管理テーブルには、再生可能なプレイリストとしてPlayList#2、PlayList#3が記述されている。そしてAutoPlay属性が付与されたプレイリストはない。そのため、仮にtitle#1開始時において自動再生されたPlayList#1の再生がtitle#2まで継続したとしても、PlayList#1の再生は自動的に終了することになる。
【００８２】
しかしPlayList#2再生が継続したままtitle#2に至れば、PlayList#2再生はtitle#2開始以降も継続する。title#2のプレイリスト管理テーブルには、再生可能なプレイリストとしてPlayList#2、PlayList#3が記述されている。そのため、title#2で実行中となるapplication#3は、PlayList#2の再生を停止し、代わりにPlayList#3の再生を要求することにより、再生中のプレイリストを交代させることができる。  
【００８３】
次にプレイリスト管理テーブルによりタイトル再生区間がどのように規定されるかを、図３１を参照しながら説明する。
図３１（ａ）は、再生属性がAutoPlayに設定されたタイトルのタイトル再生区間を示す図である。再生属性がAutoPlayを示すよう設定されれば、タイトルの再生開始と同時に、AutoPlayPLの再生を開始する。ここでアプリケーションが正常に動作し、正常終了したとしても、このタイトル再生区間は、PL時間軸を基準にして定められる。
【００８４】
図３１（ｂ）は、プレイリスト管理テーブルにおいて再生属性が”AutoPlay”を示すよう設定され、アプリケーションが異常終了した場合を示す。かかる異常終了により、どのアプリケーションも動作してない状態になるが、AutoPlayPLの再生は継続する。この場合も、AutoPlayPLのPL時間軸がタイトル再生区間になる。
図３１（ｃ）は、プレイリスト管理テーブルにおいて再生属性が”AutoPlay”を示すよう設定され、メインアプリの起動に失敗したケースを示す。この場合も、AutoPlayPL再生は、アプリケーションの起動失敗とは関係なしに行われるので、AutoPlayPLの時間軸がタイトル再生区間になる。
【００８５】
以上のようにプレイリスト管理テーブルの再生属性を、”AutoPlay”に設定しておけば、Java（登録商標）アプリケーションの起動に、5〜10秒という時間がかかったとしても、その起動がなされている間、”とりあえず何かが写っている状態”になる。タイトル実行開始時において、アプリケーション起動に時間がかかったとしても、画面は、”とりあえず何かが写っている状態”になる。これにより、アプリケーション起動に時間がかかることによるスタートアップディレイの長期化を補うことができる。
【００８６】
アプリケーション管理テーブル及びプレイリスト管理テーブルを定義することにより、タイトル再生区間の進行に沿って、Java（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。以上が記録媒体についての説明である。続いて本発明に係る再生装置について説明する。
【００８７】
図３２は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムLSIと、ドライブ装置という2つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、BD-ROMドライブ１、リードバッファ２、デマルチプレクサ３、ビデオデコーダ４、ビデオプレーン５、P-Graphicsデコーダ６、Presentation Graphicsプレーン７、合成部８、フォントゼネレータ９、I-Graphicsデコーダ１０、スイッチ１１、Interactive Graphicsプレーン１２、合成部１３、CLUT部１４、CLUT部１５、オーディオデコーダ１６、Network Device１７、Local Storage１８、リードバッファ１９、デマルチプレクサ２０、命令ROM２１、ユーザイベント処理部２２、PSRセット２３、CPU２４、シナリオメモリ２５、ローカルメモリ２６、スイッチ２７から構成される。
【００８８】
先ず初めに、BD-ROMに記録されたAVClip再生に係る構成要素(BDドライブ１〜オーディオデコーダ１６)について説明する。
BD-ROMドライブ１は、BD-ROMのローディング／イジェクトを行い、BD-ROMに対するアクセスを実行する。
リードバッファ２は、FIFOメモリであり、BD-ROMから読み出されたTSパケットが先入れ先出し式に格納される。
【００８９】
デマルチプレクサ(De-MUX)３は、リードバッファ２からTSパケットを取り出して、このTSパケットを構成するTSパケットをPESパケットに変換する。そして変換により得られたPESパケットのうち、CPU２４から設定されたPIDをもつものをビデオデコーダ４、P-Graphicsデコーダ６、I-Graphicsデコーダ１０、オーディオデコーダ１６のどれかに出力する。
ビデオデコーダ４は、デマルチプレクサ３から出力された複数PESパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込む。
【００９０】
ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ領域である。ビデオプレーン５における解像度は1920×1080であり、このビデオプレーン５に格納されたピクチャデータは、16ビットのYUV値で表現された画素データにより構成される。ビデオプレーン５では、ビデオストリームにおける一フレーム毎の再生映像を、スケーリングすることができる。スケーリングとは、一フレーム毎の再生画像をビデオプレーン５全体の1/4(クオータという)、1/1(フルスケールという)のどちらかに変化させることである。かかるスケーリングを、BD-JモードにおいてCPU２４からの指示に従い実行するので、ビデオストリームの再生画像を、画面の隅に追いやったり、全面的に出すという画面演出が可能になる。
【００９１】
P-Graphicsデコーダ６は、BD-ROMから読み出されたプレゼンテーショングラフィクスストリームをデコードして、非圧縮グラフィクスをPresentation Graphicsプレーン７に書き込む。グラフィクスストリームのデコードにより、字幕が画面上に現れることになる。
Presentation Graphicsプレーン７は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。本プレーンにおける解像度は1920×1080であり、Presentation Graphicsプレーン７中の非圧縮グラフィクスの各画素は8ビットのインデックスカラーで表現される。CLUT(Color Lookup Table)を用いてかかるインデックスカラーを変換することにより、Presentation Graphicsプレーン７に格納された非圧縮グラフィクスは、表示に供される。
【００９２】
合成部８は、ビデオプレーン５に格納された非圧縮状態のピクチャデータ(i)を、Presentation Graphicsプレーン７の格納内容と合成する。
フォントゼネレータ９は、文字フォントを用いてtextSTストリームに含まれるテキストコードをビットマップに展開してPresentation Graphicsプレーン７に書き込む。
I-Graphicsデコーダ１０は、HDMVモードにおいてBD-ROM又はLocal Storage１８から読み出されたIGストリームをデコードして、非圧縮グラフィクスをInteractive Graphicsプレーン１２に書き込む。
【００９３】
スイッチ１１は、フォントゼネレータ９が生成したフォント列、P-Graphicsデコーダ６のデコードにより得られたグラフィクスの何れかを選択的にPresentation Graphicsプレーン７に書き込むスイッチである。
Interactive Graphicsプレーン１２は、I-Graphicsデコーダ１０によるデコードで得られた非圧縮グラフィクスが書き込まれる。またInteractive Graphicsプレーン１２には、BD-Jモードにおいて、アプリケーションにより描画された文字やグラフィクスが書き込まれる。
【００９４】
合成部１３は、Interactive Graphicsプレーン１２の格納内容と、合成部８の出力である合成画像(非圧縮状態のピクチャデータと、Presentation Graphicsプレーン７の格納内容とを合成したもの)とを合成する。かかる合成により、アプリケーションがI-Graphicsデコーダ１０に書き込んだ文字・グラフィクスを、非圧縮状態のピクチャデータ上にオーバレイして、表示することができる。
【００９５】
CLUT部１４は、ビデオプレーン５に格納された非圧縮グラフィクスにおけるインデックスカラーを、Y,Cr,Cb値に変換する。
CLUT部１５は、Interactive Graphicsプレーン１２に格納された非圧縮グラフィクスにおけるインデックスカラーを、Y,Cr,Cb値に変換する。
オーディオデコーダ１６は、デマルチプレクサ３から出力されたPESパケットを復号して、非圧縮形式のオーディオデータを出力する。
【００９６】
以上がAVClip再生に係る構成要素である。続いてBD-Jモードでの動作に係る構成要素(Network Device１７〜De-mux２０)について説明する。
Network Device１７は、再生装置における通信機能を実現するものであり、BD-JモードにおいてURL指定がJava（登録商標）アプリケーションから与えられれば、そのURLにあたるwebサイトとのTCPコネクション、FTPコネクション等を確立する。かかるコネクション確立によりwebサイトからのダウンロードをJava（登録商標）アプリケーションに行わせる。
【００９７】
Local Storage１８は、Network Device１７により確立されたコネクションを通じてwebサイトからダウンロードされたコンテンツ等、BD-ROM以外の記録媒体、通信媒体から供給されたコンテンツを、メタデータと共に格納しておくためのハードディスクである。このメタデータは、ダウンロードコンテンツをLocal Storage１８にバインドして管理するための情報であり、このLocal Storage１８をアクセスすることで、BD-Jモードにおけるアプリケーションは、ダウンロードコンテンツ長さを利用した様々な処理を行うことができる。
【００９８】
リードバッファ１９は、FIFOメモリであり、Local Storage１８に格納されたダウンロードコンテンツに、SubClipが含まれている場合、このSubClipを構成するTSパケットを、先入れ先出し式に格納する。
デマルチプレクサ(De-MUX)２０は、リードバッファ１９からTSパケットを取り出して、TSパケットをPESパケットに変換する。そして変換により得られたPESパケットのうち、所望のPIDをもつものをフォントゼネレータ９、I-Graphicsデコーダ１０、オーディオデコーダ１６に出力する。
【００９９】
以上のNetwork Device１７〜De-mux２０により、Java（登録商標）アプリケーションがネットワークを通じてダウンロードしたコンテンツを、BD-ROMに記録されたコンテンツ同様再生させることができる。続いて、再生装置における統合制御を実現する構成要素(命令ROM２１〜スイッチ２７)について説明する。
命令ROM２１は、再生装置の制御を規定するソフトウェアを記憶している。
【０１００】
ユーザイベント処理部２２は、リモコンや再生装置のフロントパネルに対するキー操作に応じて、その操作を行うユーザイベントをCPU２４に出力する。
PSRセット２３は、再生装置に内蔵されるレジスタであり、64個のPlayer Status Register(PSR)と、4096個のGeneral Purpose Register（GPR)とからなる。Player Status Registerの設定値(PSR)のうち、PSR4〜PSR8は、現在の再生時点を表現するのに用いられる。
【０１０１】
PSR4は、1〜100の値に設定されることで、現在の再生時点が属するタイトルを示し、0に設定されることで、現在の再生時点がトップメニューであることを示す。
PSR5は、1〜999の値に設定されることで、現在の再生時点が属するチャプター番号を示し、0xFFFFに設定されることで、再生装置においてチャプター番号が無効であることを示す。
【０１０２】
PSR6は、0〜999の値に設定されることで、現在の再生時点が属するPL(カレントPL)の番号を示す。
PSR7は、0〜255の値に設定されることで、現在の再生時点が属するPlayItem(カレントPlay Item)の番号を示す。
PSR8は、0〜OxFFFFFFFFの値に設定されることで、45KHzの時間精度を用いて現在の再生時点(カレントPTM(Presentation TiMe))を示す。以上のPSR4〜PSR8により、図２１（ａ）におけるBD-ROM全体の時間軸において、現在の再生時点はどこであるかを特定することができる。
【０１０３】
CPU２４は、命令ROM２１に格納されているソフトウェアを実行して、再生装置全体の制御を実行する。この制御の内容は、ユーザイベント処理部２２から出力されたユーザイベント、及び、PSRセット２３における各PSRの設定値に応じて動的に変化する。
シナリオメモリ２５は、カレントのPL情報やカレントのClip情報を格納しておくためのメモリである。カレントPL情報とは、BD-ROMに記録されている複数PL情報のうち、現在処理対象になっているものをいう。カレントClip情報とは、BD-ROMに記録されている複数Clip情報のうち、現在処理対象になっているものをいう。
【０１０４】
ローカルメモリ２６は、BD-ROMからの読み出しは低速である故、BD-ROMの記録内容を一時的に格納しておくためのキャッシュメモリである。かかるローカルメモリ２６が存在することにより、BD-Jモードにおけるアプリケーション実行は、効率化されることになる。
スイッチ２７は、BD-ROM及びLocal Storage１８から読み出された各種データを、リードバッファ２、リードバッファ１９、シナリオメモリ２５、ローカルメモリ２６のどれかに選択的に投入するスイッチである。
【０１０５】
以上が、本実施形態に係る再生装置のハードウェア構成である。続いて本実施形態に係る再生装置のソフトウェア構成について説明する。
図３３は、ROM２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。本図に示すように、再生装置のレイア構成は、以下のa),b),c)からなる。つまり、
a)BD Player Deviceの第１階層、
b)BD Player Modelの第２階層、
c)Application Runtime Enviromentの第３階層からなる。
これらの階層のうち図３２に示した再生装置のハードウェア構成は、第１階層に属することになる。本図の第１階層”BD Player Device”には、図３２に示したハードウェア構成のうちビデオデコーダ４、P-Graphicsデコーダ６、I-Graphicsデコーダ１０、オーディオデコーダ１６からなる”デコーダ”と、ビデオプレーン５、Presentation Graphicsプレーン７、Interactive Graphicsプレーン１２からなる”プレーン”、BD-ROM及びそのファイルシステム、Local Storage１８及びそのファイルシステムを含む。
【０１０６】
第２階層”BD Player Model”は、以下のb1),b2)の層からなる。つまり、
b2)Playback Control Engine３２の層
b1)Virtual File System３０及びPresentation Engine３１の層
からなり、自身より上位の階層に対し、ファンクションAPIを提供する。
第３階層”Application Runtime Enviroment”は、以下のc1),c2)の階層からなる。つまり、
c1)モジュールマネージャ３４が存在する層、
c2)HDMVモジュール３３、BD-Jモジュール３５が存在する層
からなる。図３３のレイアモデルにおいてこのモジュールマネージャ３４が最上位の階層に位置するが、モジュールマネージャ３４は、HDMVモジュール３３及びBD-Jモジュール３５をバイパスしてPlayback Control Engine３２に至る迂回路ur1を有している。この迂回路によりモジュールマネージャ３４は、図３３のレイアモデルにおいて”Ｌ”字形を逆さまにした形状をなし、User Event Manager３７を内蔵した構成になっている。
【０１０７】
BD-Jモジュール３５は、いわゆるJava（登録商標）プラットフォームであり、Java（登録商標）仮想マシン３８を中核にした構成になっている。Java（登録商標）仮想マシン３８内のワークメモリは、様々なシステムプログラムやアプリケーションが動作している。Java（登録商標）仮想マシン３８の上位に描いた、アプリケーションマネージャ３６、Event Listner Manager３９(Default Operation Manager４０)は、そうしたシステムプログラムの1つである。このうちアプリケーションマネージャ３６の中にはPLMT Prcessor４１が存在している。またBD-Jモジュール３５と、Playback Control Engine３２との間には、Permission Controller４２が介在している。
【０１０８】
先ず初めに、第２層に属するVirtual File System３０〜モジュールマネージャ３４について説明する。図３４は、Virtual File System３０〜モジュールマネージャ３４による処理を模式化した図である。
Virtual File System３０は、Local Storage１８に格納されたダウンロードコンテンツを、BD-ROMにおけるディスクコンテンツと一体的に取り扱うための仮想的なファイルシステムである。ここでLocal Storage１８に格納されたダウンロードコンテンツは、SubClip、Clip情報、プレイリスト情報を含む。このダウンロードコンテンツにおけるプレイリスト情報はBD-ROM及びLocal Storage１８のどちらに存在するClip情報であっても、指定できる点で、BD-ROM上のプレイリスト情報と異なる。この指定にあたって、Virtual File System３０上のプレイリスト情報は、BD-ROMやLocal Storage１８におけるファイルをフルパスで指定する必要はない。BD-ROM上のファイルシステムやLocal Storage１８上のファイルシステムは、仮想的な1つのファイルシステム(Virtual File System３０)として、認識されるからである。故に、PlayItem情報におけるClip_Information_file_name及びSubPlayItem情報のClip_Information_file_nameは、Clip情報の格納したファイルのファイルボデイにあたる5桁の数値を指定することにより、Virtual File System３０、BD-ROM上のAVClipを指定することができる。Virtual File System３０を介してLocal Storage１８の記録内容を読み出し、BD-ROMの記録内容と動的に組み合わせることにより、様々な再生のバリエーションを産み出すことができる。Local Storage１８と、BD-ROMとを組合せてなるディスクコンテンツは、BD-ROMにおけるディスクコンテンツと対等に扱われるので、本願における”BD-ROM”は、Local Storage１８＋BD-ROMの組合せからなる仮想的な記録媒体をも含むことにする。
【０１０９】
Presentation Engine３１は、AV再生ファンクションを実行する。再生装置のAV再生ファンクションとは、DVDプレーヤ、CDプレーヤから踏襲した伝統的な機能群であり、再生開始(Play)、再生停止(Stop)、一時停止(Pause On)、一時停止の解除(Pause Off)、Still機能の解除(still off)、速度指定付きの早送り(Forward Play(speed))、速度指定付きの巻戻し(Backward Play(speed))、音声切り換え(Audio Change)、副映像切り換え(Subtitle Change)、アングル切り換え(Angle Change)といった機能である。AV再生ファンクションを実現するべく、Presentation Engine３１は、リードバッファ２上に読み出されたAVClipのうち、所望に時刻にあたる部分のデコードを行うよう、ビデオデコーダ４、P-Graphicsデコーダ６、I-Graphicsデコーダ１０、オーディオデコーダ１６を制御する。所望の時刻としてPSR8(カレントPTM)に示される箇所のデコードを行わせることにより、AVClipにおいて、任意の時点を再生を可能することができる。
【０１１０】
再生制御エンジン(Playback Control Engine(PCE))３２は、プレイリストに対する再生制御ファンクション(i)、PSRセット２３における状態取得／設定ファンクション(ii)といった諸機能を実行する。PLに対する再生制御ファンクションとは、Presentation Engine３１が行うAV再生ファンクションのうち、再生開始や再生停止を、カレントPL情報及びClip情報に従って行わせることをいう。これら機能(i)〜(ii)は、HDMVモジュール３３〜BD-Jモジュール３５からのファンクションコールに応じて実行する。
【０１１１】
つまり、PL再生を命じるファンクションコールがあれば、Playback Control Engine３２は、再生が命じられたプレイリスト情報を、Virtual File System３０経由でBD-ROM又はLocal Storage１８から読み出す。そのように読み出されたプレイリスト情報内のPlayItem情報を参照し、そのPlayItem情報においてClip_Information_file_nameに記載されているClip情報を、Virtual File System３０経由でBD-ROM又はLocal Storage１８から読み出す。図３４における◎1,2,3,4は、Virtual File System３０経由のプレイリスト情報読み出し(◎1)、プレイリスト情報を構成するPlayItem情報の解読(◎2)、Virtual File System３０経由のClip情報読み出し(◎3)、Clip情報の解読(◎4)を模式化したものである。以上の過程を経てClip情報、プレイリスト情報が解読されれば、AVClipを構成するTSパケットを、Virtual File System３０を通じてPresentation Engine３１に引き渡す。このようにしてPresentation Engine３１にTSパケットが順次渡れば、Presentation Engine３１はAVClipを構成するTSパケットをデコーダに出力して、プレーンに表示させる。図中の☆1,2,3,4は、AVClipを構成するTSパケットの読み出し(☆1,2)、Virtual File System３０からPresentation Engine３１へのTSパケット引き渡し(☆3)、デコーダへのTSパケット投入(☆4)、デコーダから各種プレーンへのデコード結果出力(☆5)を模式的に示している。      【０１１２】
HDMVモジュール３３は、HDMVモードの実行主体であり、mobj_idにより分岐先MovieObjectを指定したactivate要求(activate(mobj_id))がモジュールマネージャ３４からなされれば、MovieObject(mobj_id)をローカルメモリ２６に読み出して、このMovie Objectに記述されたナビゲーションコマンドを解読し、解読結果に基づきPlayback Control Engine３２に対するファンクションコールを実行する。図２８において▽2,▽3,▽4が付された矢印は、モジュールマネージャ３４によるactivate(mobj_id)(2)、Movie Objectに記述されたナビゲーションコマンドの解読(3)、Playback Control Engine３２に対するファンクションコール(4)を、模式的に示している。
【０１１３】
モジュールマネージャ３４は、BD-ROMから読み出されたIndex.bdmvを保持して、分岐制御を行う。この分岐制御は、カレントタイトルを構成する動的シナリオにTerminateイベントを発行し、分岐先タイトルを構成する動的シナリオにActivateイベントを発行することでなされる。title_idを指定したJumpTitleコマンド(JumpTitle(title_id))をMovieObjectが実行した場合、カレントタイトルを構成するMovieObjectにTerminateイベントを発行し、title_idに対応するタイトルを構成するMovie Objectをactivateするよう、activate(mobj_id)イベントが発行する。図中の▽0,▽1,▽2が付された矢印は、JumpTitleコマンドの実行(▽0)、モジュールマネージャ３４によるIndex.bdmv参照(▽1)、分岐先Titleを構成するMovie Objectのactivate(▽2)の通知を模式的に示している。JumpTitleAPI(JumpTitle(title_id))をBD-J Objectがコールした場合も同様であり、カレントタイトルを構成するBD-J ObjectにTerminateイベントを発行し、そのtitle_idに対応するタイトルを構成するBD-J Objectをactivateするよう、activate(bobj_id)をBD-Jモジュール３５に発行する。
【０１１４】
以上がPresentation Engine３１〜モジュールマネージャ３４についての説明である。続いてアプリケーションマネージャ３６について、図３５を参照しながら説明する。図３５は、アプリケーションマネージャ３６を示す図である。
アプリケーションマネージャ３６は、タイトル分岐が発生する度に、分岐前タイトルでは実行されていないが、新たなタイトルではAutoRunの起動属性を有するアプリケーションを起動するようJava（登録商標）仮想マシン３８に指示する。それと共に、分岐前タイトルでは実行されていたが、新たなタイトルを生存区間としないアプリケーションを終了させる。これら起動制御及び終了制御は、カレントBD-J Objectにおけるアプリケーション管理テーブルを参照した上でなされる。ここでタイトル分岐があった場合、モジュールマネージャ３４からactivate(bobj_id)が通知される。かかる通知があれば、bobj_idに対応するBD-J ObjectをカレントBD-J Objectにして、そのカレントBD-J Objectにおけるアプリケーション管理テーブルを参照することで、上述した自動起動すべきアプリケーション及び自動終了すべきアプリケーションを特定する。図３５における☆0,☆1,☆2,☆3は、TitleJumpの発生(☆0)、activate(bobj_id)の通知(☆1)、アプリケーション管理テーブル参照(☆2)、Java（登録商標）仮想マシン３８に対するアプリケーション起動指示(☆3)という一連の過程を模式化して示す。この起動指示によりJava（登録商標）仮想マシン３８は、ローカルメモリ２６からワークメモリにxletプログラムを読み出す(☆4,5)。
【０１１５】
以上がアプリケーションマネージャ３６についての説明である。続いてUser Event Manager３７〜Default Operation Manager４０について、図３６を参照しながら説明する。
User Event Manager３７は、ユーザイベント処理部２２が受け付けたユーザイベントを、再生制御のためのユーザイベントと、キーイベントとに分離する。再生制御のためのユーザイベントとは、再生開始(Play)、再生停止(Stop)、一時停止(Pause On)、一時停止の解除(Pause Off)、Still機能の解除(still off)、速度指定付きの早送り(Forward Play(speed))、速度指定付きの巻戻し(Backward Play(speed))、音声切り換え(Audio Change)、副映像切り換え(Subtitle Change)、アングル切り換え(Angle Change)のどれかを命じるユーザイベントである。一方キーイベントとは、Pop-upキー,MoveUpキー,MoveDownキー,MoveRightキー,MoveLeftキー,Numericキーのどれかの押下を示すユーザイベントである。そして再生制御のためのユーザイベントに基づき、再生制御ファンクションをPlayback Control Engine３２に実行させるためのファンクションコールを行う。このファンクションコールは、U0(User Operation)と呼ばれ、HDMVモジュール３３、BD-Jモジュール３５を介することなく、モジュールマネージャ３４における迂回路にあるUOコントローラ３７aを用いてなされる。これにより再生開始(Play)、再生停止(Stop)、一時停止(Pause On)、一時停止の解除(Pause Off)というような再生制御は、遅延なくなされることになる。図中の☆1,2,3は、User Event Manager３７による再生制御ユーザイベントと、キーイベントとの分離(☆1,2)、再生制御ユーザイベントに基づくPlayback Control Engine３２に対するファンクションコール(☆3)を模式的に示している。
【０１１６】
Java（登録商標）仮想マシン３８は、アプリケーションを構成するxletプログラムをワークメモリにロードして、xletプログラムを解読し、解読結果に従って、下位層に対する制御を行う。下位層への制御は、JMFメソッドを図示しないBDミドルウェアに発行して、BD再生装置が対応しているファンクションコールに置き換させ、置換後のファンクションコールをPlayback Control Engine３２に発行することでなされる。
【０１１７】
Event Listner Manager３９は、キーイベントを解析し、イベントの振り分けを行う。図中の実線矢印◇1,◇2は、このEvent Listner Manager３９による振り分けを模式的に示す。xletプログラム内のEvent Listnerに登録されたキーイベントなら、BD-J Objectにより間接参照されているxletプログラムにかかるイベントを振り分ける。xletプログラムのEvent Listnerには、JMFに対応したキーイベントが登録されているので、本キーイベントによりxletプログラムの起動が可能になる。キーイベントがEvent Listner非登録のキーイベントである場合、本キーイベントをDefault Operation Manager４０に振り分ける。BD-ROM再生装置において生じるキーイベントには、Event Listnerに登録されていない多様なものがあり、これらのキーイベントが生じたとしても、漏れの無い処理を実行するためである。
【０１１８】
Default Operation Manager４０は、xletプログラム内のEvent Listnerに登録されてないキーイベントがEvent Listner Manager３９から振り分けられると、そのEvent Listner非登録イベントに対応するファンクションコールをPlayback Control Engine３２に対して実行する。このDefault Operation Manager４０によるファンクションコールを模式的に示したのが、図中の矢印◇3である。
【０１１９】
PLMTプロセッサ４１は、アプリケーションマネージャ３６の一構成要素であり、モジュールマネージャ３４からactivate(bobj_id)がなされれば、そのbobj_idにより特定されるBD-J Objectのプレイリスト管理テーブルを参照する。そして再生属性＝AutoPlayのPLが、そのBD-J Objectのプレイリスト管理テーブル内に存在すれば、そのAutoPlayPLを再生するようPlayback Control Engine３２に出力する。一方、PLによる再生終了を示すNotifyイベントをPlayback Control Engine３２が発行すれば、その発行された時点をTitle終了時点として解釈する。図中の△1,2は、Playback Control Engine３２に対するPlayPLファンクションのコール(△1)、Playback Control Engine３２からのNotifyイベント出力(△2)を模式化している。
【０１２０】
以上でBD-Jモジュール３５内のレイヤ構成についての説明を終える。尚、Permission Controller４２については、本実施形態における説明を割愛する。Permission Controller４２の処理内容は、本実施形態よりも第３実施形態で詳述するのが望ましいからである。
＜Java（登録商標）仮想マシン３８の内部構成＞
Java（登録商標）仮想マシン３８の内部構成について説明する。図３７は、Java（登録商標）仮想マシン３８の内部構成を示す図である。本図に示すようにJava（登録商標）仮想マシン３８は、図３２に示したCPU２４と、ユーザクラスローダ５２、メソッドエリア５３、ワークメモリ５４、スレッド５５a,b・・・n、Java（登録商標）スタック５６a,b・・・nとから構成される。
【０１２１】
ユーザクラスローダ５２は、BDJAディレクトリのJava（登録商標）アーカイブファイルにおけるクラスファイルをローカルメモリ２６等から読み出してメソッドエリア５３に格納する。このユーザクラスローダ５２によるクラスファイル読み出しは、ファイルパスを指定した読み出しをアプリケーションマネージャ３６がユーザクラスローダ５２に指示することでなされる。ファイルパスがローカルメモリ２６を示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するJava（登録商標）アーカイブファイルにおけるクラスファイルを、ローカルメモリ２６からワークメモリ５４に読み出す。ファイルパスがVirtual File System３０上のディレクトリを示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するJava（登録商標）アーカイブファイルにおけるクラスファイルを、BD-ROM又はLocal Storage１８からワークメモリ５４に読み出す。図３５に示したアプリケーション起動制御(☆3,4,5)は、このユーザクラスローダ５２によるクラスファイル読み出しにより実現される。読み出しが指示されたクラスファイルがローカルメモリ２６にない場合、ユーザクラスローダ５２は読み出し失敗をアプリケーションマネージャ３６に通知することになる。
【０１２２】
メソッドエリア５３は、ユーザクラスローダ５２によりローカルメモリ２６から読み出されたクラスファイルが格納される。
ワークメモリ５４は、いわゆるヒープエリアであり、様々なクラスファイルのインスタンスが格納される。図３３に示したアプリケーションマネージャ３６、Event Listner Manager３９は、このワークメモリ５４に常駐するレジデントアプリケーションである。ワークメモリ５４には、これらレジデント型のインスタンスの他に、メソッドエリア５３に読み出されたクラスファイルに対応するインスタンスが格納される。このインスタンスが、アプリケーションを構成するxletプログラムである。かかるxletプログラムをワークメモリ５４に配置することによりアプリケーションは実行可能な状態になる。図３３、図３５、図３６のレイアモデルでは、このワークメモリ５４をJava（登録商標）仮想マシン３８上位層に記述していた。これはワークメモリ５４上のアプリケーションマネージャ３６及びEvent Listner Manager３９を、わかり易く記述するための配慮に過ぎない。アプリケーションマネージャ３６及びEvent Listner Manager３９はインスタンスとしてスレッド５５a,b・・・nにより実行されるというのが、現実的な記述になる。
【０１２３】
スレッド５５a,b・・・nは、ワークメモリ５４に格納されたメソッドを実行する論理的な実行主体であり、ローカル変数や、オペランドスタックに格納された引数をオペランドにして演算を行い、演算結果を、ローカル変数又はオペランドスタックに格納する。図中の矢印ky1,ky2,kynは、ワークメモリ５４からスレッド５５a,b・・・nへのメソッド供給を象徴的に示している。物理的な実行主体がCPU唯1つであるのに対し、論理的な実行主体たるスレッドは、最大64個Java（登録商標）仮想マシン３８内に存在し得る。この64個という数値内において、スレッドを新規に作成することも、既存のスレッドを削除することも可能であり、スレッドの動作数は、Java（登録商標）仮想マシン３８の動作中において増減し得る。スレッドの数は適宜増やすことができるので、複数スレッドにより1つのインスタンスの並列実行を行い、インスタンスの高速化を図ることもできる。本図ではCPU２４と、スレッドとの対応関係は、1対多の関係にしているが、CPUが複数ある場合、CPUとスレッドとの対応関係は多対多の関係になりうる。スレッド５５a,b・・・nによるメソッド実行は、メソッドをなすバイトコードを、CPU２４のネイティブコードに変換した上、CPU２４に発行することでなされる。このネイティブコード変換については、本願の主眼から外れるため、説明を省く。
【０１２４】
Java（登録商標）スタック５６a,b・・・nは、スレッド５５a,b・・・nと1対1の比率で存在しており、プログラムカウンタ(図中のPC)と、1つ以上のフレームとを内部に持つ。”プログラムカウンタ”は、インスタンスにおいて、現在どの部分が実行されているかを示す。”フレーム”はメソッドに対する1回のコールに対して割り当てられたスタック式の領域であり、その1回のコール時の引数が格納される”オペランドスタック”と、コールされたメソッドが用いる”ローカル変数スタック(図中のローカル変数)”とからなる。フレームは、コールが1回なされる度にJava（登録商標）スタック５６a,b・・・n上に積み上げられるのだから、あるメソッドが自身を再帰的に呼び出す場合も、このフレームは、1つ積み上げられることになる。JMFプレーヤインスタンスの再生メソッドをコールする場合、又は、JumpTitleAPIのコールをコールする場合にも、これらのコールに対応するフレームがJava（登録商標）スタック５６a,b・・・n上に積み上げられる。そしてこれらのフレームのオペランドスタックには、再生メソッドによる再生の対象となるMPLSファイルのファイル名、又は、JumpTitleAPIのコールのジャンプ先を示すtitle_id等が引数として格納される。
【０１２５】
以上のように構成されたJava（登録商標）仮想マシン３８の内部構成において、アプリケーションマネージャ３６及びその構成要素たるPLMT Prcessor４１がどのような処理を行うかを、詳細に説明する。
bobj_idのBD-J Objectのactivateを要求するイベント(activatred[bobj_id])をモジュールマネージャ３４が出力すれば、ワークメモリ５４上の一インスタンスであるアプリケーションマネージャ３６は、そのbobj_idを有するBD-J Objectを新たにカレントBD-J Objectにする。そしてアプリケーションマネージャ３６は、分岐元タイトルにおける実行状態と、カレントBD-J Objectにおけるアプリケーションの起動属性とを照合して、自動起動すべきアプリケーション(i)、自動終了すべきアプリケーション(ii)を判定する。
【０１２６】
(i)自動起動すべきアプリケーションの判定は、分岐前タイトルにおいて非実行状態であるが、カレントBD-J ObjectにおいてAutoPlay属性を有するアプリケーションのapli_id_refをカレントBD-J Objectのアプリケーション管理テーブルから検索することでなされる。かかるapli_id_refがあれば、アプリケーション[apli_id_ref]についてのJava（登録商標）アーカイブファイルに属するクラスファイルを、メソッドエリア５３に読み出ようユーザクラスローダ５２に指示し、そのクラスファイルに対するインスタンスをワークメモリ５４上に生成させる。こうしてカレントタイトルを生存区間としているアプリケーションが実行可能な状態になる。その後、アプリケーションにおけるメソッドをスレッド５５a,b・・・nに実行させることで、アプリケーションを実行させる。
【０１２７】
(ii)自動終了すべきアプリケーションの判定は、分岐元タイトルにおいて実行状態であるが、カレントタイトルにおいて生存区間を有しないアプリケーションのapli_id_refをカレントBD-J Objectのアプリケーション管理テーブルから検索することでなされる。かかるapli_id_refがあれば、かかるアプリケーションを構成するxletプログラムを終了させる。これにより当該アプリケーションがワークメモリ５４上で占めていた領域や、そのアプリケーションのメソッド実行のためのJava（登録商標）スタック５６a,b・・・nにおけるフレーム等のリソースが回収されることになる。
【０１２８】
アプリケーションマネージャ３６の構成要素たるPLMT Prcessor４１は、分岐元タイトルにおける再生状態と、カレントタイトルにおけるプレイリストの再生属性とを照合して、自動再生すべきプレイリスト(i)、自動終了すべきプレイリスト(ii)を判定する。
(i)自動再生すべきプレイリストの判定は、分岐元タイトルにおいて非再生状態であり、カレントタイトルにおいてAutoPlay属性に設定されているプレイリストがプレイリスト管理テーブル内に存在するか否かの検索をプレイリスト管理テーブルに対して行うことでなされる。もしあれば、再生すべきプレイリストのPL_id_refを引数としたプレイリスト再生のファンクションコールを実行する。このコールにより、引数たるPL_id_refをオペランドスタックに格納したフレームがJava（登録商標）スタック５６a,b・・・nに生成される。そしてプレイリスト再生のファンクションコールをスレッド５５a,b・・・nが実行する。このファンクションコール実行によりPresentation Engine３１はプレイリスト再生を開始する。
【０１２９】
(ii)自動終了すべきプレイリストの判定は、分岐元タイトルにおいて再生中状態であり、カレントタイトルのプレイリスト管理テーブルに記述されてないプレイリストが存在するか否かの検索をプレイリスト管理テーブルに対して行うことでなされる。もしあれば、そのプレイリストの再生停止を命じるファンクションコールを実行して、そのプレイリストの再生のためのファンクションコールに対応するフレームをJava（登録商標）スタック５６a,b・・・nから削除する。
【０１３０】
ワークメモリ５４上でのアプリケーション終了には、4つの態様がある。図３８は、アプリケーション終了の4態様を示す図である。1つ目は、リソースが枯渇したためアプリケーションマネージャ３６によるTerminateイベント発行によりアプリケーションが終了するとの態様(☆1)、2つ目は、他のアプリケーションが発行したTerminateイベントを、アプリケーションマネージャ３６を介して受け付けて、終了するとの態様(☆2)、3つ目は、アプリケーション管理テーブルに記述された生存区間が終了したため、アプリケーションマネージャ３６が発行したTerminateイベントにより終了するとの態様(☆3)、4つ目は、アプリケーションが自身の終了プロセスを起動することにより終了するとの態様である(☆4)。これらの4つの態様のうち3つものが、アプリケーションマネージャ３６によりなされているため、アプリケーションマネージャ３６は、アプリケーション動作制御の中枢を掌握することがわかる。仮に、Terminateイベントの発行でもアプリケーションが終了しない場合、アプリケーションマネージャ３６は、そのアプリケーションを強制終了させて、使用しているリソースを明け渡させることができる。強権的なリソース解放を担うのも、アプリケーションマネージャ３６の1つの特徴である。
【０１３１】
以上がBD-Jモジュール３５の構成要素である。
(フローチャートの説明)
以上のアプリケーションマネージャ３６についての説明は、その概要に触れたに過ぎない。アプリケーションマネージャ３６の処理を更に詳しく示したのが図３９、図４０のフローチャートである。以降、これらのフローチャートを参照してアプリケーションマネージャ３６の処理手順についてより詳しく説明する。
【０１３２】
図３９は、アプリケーションマネージャ３６による処理手順を示す図である。本図における処理手順は、ステップＳ１−ステップＳ２−ステップＳ３−ステップＳ４からなるメインループを有している。ステップＳ１は、TitleJumpがなされたか否かの判定であり、もしなされればTitle切り換えを行い(ステップＳ７)、分岐先Titleのアプリケーション管理テーブルを参照することにより、分岐元Titleで起動中で、分岐先Titleで非生存のアプリケーションを終了させる(ステップＳ８)。一方、分岐先Titleのプレイリスト管理テーブルを参照することにより、分岐元Titleで再生中で、分岐先Titleで非生存となるPLの再生を停止させる(ステップＳ９)。
【０１３３】
そして、分岐元Titleでは非再生状態、分岐先TitleにおいてAutoPlay属性になっているPLをPLMT Prcessor４１に判定させる(ステップＳ１０)。もし存在すればPLMT Prcessor４１はAutoPlayPLを再生するようPlayback Control Engine３２に指示する(ステップＳ１１)。もし存在しないなら、AutoPlayPLは再生しない。
続くステップＳ１２〜ステップＳ１８からなる一連の手順は、分岐先Titleを生存区間とするアプリケーションの起動を実現する。この手順は、AutoRunアプリケーションに対して起動指示を行い(ステップＳ１４)、起動に成功すれば(ステップＳ１５でYes)、  AutoPlayPLの再生画像をクオータ(1/4)に変換する(ステップＳ１８)という手順を実現するものである。
【０１３４】
一方このステップＳ１５がNoであればステップＳ１４〜ステップＳ１７からなるループ処理を実行することになる。本ループ処理における制御変数は、再起動カウンタである。再起動カウンタは、アプリケーションの再起動回数を規定するカウンタである。本再起動カウンタは、ステップＳ１２においてリセットされ、ステップＳ１６において、0か否かの判定がなされる。0でない場合、ステップＳ１７において再起動カウンタはデクリメントされる。以上のステップＳ１４、ステップＳ１５、ステップＳ１６、ステップＳ１７からなるループ処理により、再起動カウンタが0でない限り、AutoRunアプリケーションの起動は繰り返されることになる。かかる繰り返しにより、アプリケーションの起動が保証されることになる。
【０１３５】
ステップＳ２は、メインとなるアプリケーションが実行されてない状態かどうかの判定であり、もしそうであれば、ステップＳ５の判定を行う。ステップＳ５は、アプリケーションが正常終了したかの判定である。もし異常終了していればステップＳ１９、ステップＳ２０の処理を実行する。正常終了していればステップＳ１９〜ステップＳ２０を実行せず、ステップＳ１〜ステップＳ４からなるメインループに戻る。
【０１３６】
ステップＳ１９は、AutoPlayPLの再生中であるか否かの判定であり、もし再生中なら、AutoPlayPLの再生画像をフルスクリーン化するようPlayback Control Engine３２に指示する(ステップＳ２０)。その後、ステップＳ１６に移行する。ステップＳ１６への移行により、異常終了時においてもステップＳ１４〜ステップＳ１７からなるループ処理が実行されることになる。これによりステップＳ１２において設定された再起動カウンタの回数が0になるまで、アプリケーションの再起動は繰り返されることになる。
【０１３７】
ステップＳ４は、BDドライブ１にBD-ROMが存在しているか否かの判定であり、もしBD-ROMが存在しなければ、全てのアプリケーションに対し、終了指示を発する(ステップＳ６)。
図４０は、プレイリスト管理テーブル、アプリケーション管理テーブルの具体例を示す。図４０の第1段目は、Titleの再生映像を示し、第2段目は、Titleの時間軸を示す。第3段目はPL再生の進行、第4段目は、アプリケーション実行を示す。第4段目においてapplication#1は、Titleの開始と共に起動されており、その後、時点t1において動作状態になる。一方PlayList#1は、Titleの開始と共に再生が開始されている。Playlist#1の再生は、Titleの開始と同じ時点に開始されているので、第1段目の左側に示すように、Titleの再生開始直後から、アプリケーションが動作状態になるまでのスタートアップディレイにおいて、プレイリストの再生画像gj1がフルスクリーン表示される。一方、application#1は、時点t1で動作状態になるので、PL再生画像を子画面、アプリケーションの実行画像を親画面にした合成画像gj2が時点t1において表示されることになる。アプリケーションの実行画像は、Startボタン,continueボタン,POWERインディケータを配置したゲーム用の画面であり、Interactive Graphicsプレーン１２に対する描画処理をJava（登録商標）アプリケーションが実行することでなされる。Java（登録商標）アプリケーションがかかる描画処理を行うには、グラフィクス描画や文字描画のためのライブラリが必要になる。以降アプリケーション実行とPL再生とが同時になされる限り、親子画面の表示は継続する。
【０１３８】
その後application#1が異常終了してしまい、時点t2においてアプリケーションマネージャ３６がこの異常終了を検知したとする。矢印br1は、この検知を象徴的に示す。そうするとステップＳ２０においてアプリケーションマネージャ３６は、PLの再生画像をフルスクリーンにする。図中の時点t3は、このフルスクリーン化のタイミングを示す。図中の第1段目の右側に、フルスクリーン化で得られた画像gj3を示す。
【０１３９】
以上のように本実施形態によれば、プレイリスト管理テーブルの再生属性を、”AutoPlay”に設定しておくことにより、Java（登録商標）アプリケーションが動作状態になるまで5〜10秒という時間がかかったとしても、その間、”とりあえず何かが写っている状態”になる。この”とりあえず何かが写っている状態”によりタイトル実行開始時のスタートアップディレイを補うことができる。
【０１４０】
また、アプリケーションの起動に失敗したり、アプリケーションが異常したとしても、プレイリスト管理テーブルで規定されたプレイリストの再生を継続することにより、”とりあえず何かが写っている状態”になる。これにより、装置がブラックアウトしてしまうという最悪ケースを回避することができるので、装置を製造するメーカに、最低限度の安心感を与えることができる。
【０１４１】
(第２実施形態)
第２実施形態は、エラー終了時におけるリカバリー処理を、オーサリング時に規定しておくための改良に関する。かかるリカバリー処理を規定するため、本実施形態に係る記録媒体では、1つのBD-J Object内にエラー管理テーブルを設けている。図４１（ａ）は、第２実施形態に係るBD-J Objectの内部構成を示す図である。本図に示すように、BD-J Objectにはアプリケーション管理テーブル、プレイリスト管理テーブルの他に、エラー管理テーブル(Error Maangement Table[bobj_id])が追加されている。図４１（ｂ）は、エラー管理テーブルの内部構成を示す図である。本図に示すように、エラー管理テーブルは、Number_of_recovery個のリカバリー情報(recovery())からなる。識別子recovery_idで特定される、任意のリカバリー情報の内部構成を、引き出し線em1にてクローズアップしている。この引き出し線によるとリカバリー情報は、リカバリー情報に対応するアプリケーションの識別子を、一意に特定する参照値『Apli_id_ref』、『Restart_Application_flag』、『Continuous_Playback_flag』、『Select_Title_flag』、『Notify_Event_flag』、『Reboot_flag』という5つのflagからなる。図４２は、これら5つのフラグの意味内容を示す。以降エラー管理テーブルにおける各フラグの意味内容について説明する。
【０１４２】
『Restart_Application_flag』は、0に設定されることにより異常終了時に再起動しないことを示す。0以外の整数値nに設定されることにより、再起動をn回繰り返すことを示す。デフォルト値として本flagは、0に設定されている。
『Continuous_Playback_flag』は、0に設定されることにより異常終了時にPL再生を継続しないことを示す。整数値1に設定されることにより、異常終了時にPL再生を継続することを示し、2に設定されることにより、異常終了時に、フルスクリーン・一倍速でPL再生を継続することを示す。デフォルト値として本flagは、0に設定されている。
【０１４３】
『Select_Title_flag』は、0に設定されることにより異常終了時にTitle分岐を行わないことを示す。0以外の整数値nに設定された場合、Title番号nにより特定されるTitleにJumpすることを示す。デフォルト値として本flagは、0に設定されている。
『Notify_Event_flag』は、0に設定されることにより異常終了時に、イベントを出力しないことを示す。0以外の整数値nに設定された場合、イベント番号nのイベントを出力することを示す。デフォルト値として本flagは、1に設定されている。
【０１４４】
『Reboot_flag』は、0に設定されることにより異常終了時に、再生装置のブートストラップを行わないことを示す。整数値1に設定された場合、ブートストラップを行うことを示す。
以上のflagが存在するので、アプリケーションが異常終了した際、どのようなリカバリ処理を実行するかをオーサリング時に予め規定しておくことができる。  エラー管理テーブル記述の具体例について説明する。図４３（ａ）は、エラー管理テーブルが記述された2つのTitle(title#1、title#2)を示す図である。title#1のアプリケーション管理テーブルには、AutoRunアプリケーションとしてapplication#1が記述されており、title#1のエラー管理テーブルにはこのapplication#1が異常終了した際に用いられるべきRecovery情報が記述されている。title#1のプレイリスト管理テーブルには、AutoPlayプレイリストとしてPlayList#1が記述されている。
【０１４５】
title#2側のアプリケーション管理テーブルにはAutoRunアプリケーションとしてapplication#2が記述されており、title#2側のエラー管理テーブルには、このapplication#2に対するRecovery情報が記述されている。
図４３（ｂ）は、図４３（ａ）のように記載されたアプリケーション管理テーブル、エラー管理テーブルに基づくアプリケーション実行及びプレイリスト再生の進行を示す。application#1についてのRecovery情報は、Continuous_Playback_Flag＝2と記述されているため、application#1の異常終了時にはプレイリスト再生が一倍速、フルスクリーンにより継続することになる。
【０１４６】
一方application#2についてのRecovery情報は、Notify_Event_Flag=2と記述されているので、application#2の異常終了には、番号=2のイベントを出力することになる。
以上のようなRecovery情報の記述により、アプリケーションが異常終了した際の処理を、Title毎、アプリケーション毎に変化させることができる。
BD-J Objectにおいて上述したエラー管理テーブルが追加されたため、本実施形態に係るアプリケーションマネージャ３６は図４４、図４５のフローチャートに従って処理を行う。図４４は、第２実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。本フローは、図３９同様、ステップＳ１〜ステップＳ４をメインループにしている。このメインアプリにおいてタイトルが選択された際の処理は、ステップＳ２１〜ステップＳ２７に示されるものとなる。
【０１４７】
ステップＳ２１では、分岐先Titleにプレイリスト管理テーブルが存在するか否かの判定をPLMT Prcessor４１に行わせる。もし存在すれば、分岐元Titleにおいて非再生状態だが、分岐先TitleにおいてAutoPlay属性になっているPLの再生をPlayback Control Engine３２に開始させて(ステップＳ２２)、その再生が成功したかどうかを判定する(ステップＳ２３)。もし成功すればステップＳ２５〜ステップＳ２８の処理を行う。成功しなければ図４５のフローチャートに移行する。
【０１４８】
分岐先Titleにプレイリスト管理テーブルがない場合は、分岐元Titleにおいて再生状態であったPLの再生をPlayback Control Engine３２に停止させて(ステップＳ２４)、ステップＳ２５〜ステップＳ２８の処理を行う。
ステップＳ２５は、分岐先Titleにアプリケーション管理テーブルが存在するか否かの判定である。もし存在すれば、分岐先アプリケーションにおけるAutoRunアプリケーションを起動して(ステップＳ２６)、ステップＳ２７において起動に成功したか否かを判定する。成功すればステップＳ１〜ステップＳ４のループ処理に戻る。成功しなければ図４５のフローチャートに移行する。
【０１４９】
図４５のフローチャートは、アプリケーションが異常終了した場合の処理手順を示すフローチャートである。ステップＳ３０は、異常終了したアプリケーションが属するTitleに、エラー管理テーブルが存在するか否かの判定であり、もし存在しなければステップＳ１〜ステップＳ４からなるループ処理に戻る。
存在すれば、ステップＳ３１〜ステップＳ４４の処理を経た上でステップＳ１〜ステップＳ４からなるループ処理に戻る。ステップＳ３１は、エラー管理テーブルにおけるRestart_Application_flagが0でないかの判定である。0でなければ、ステップＳ４０〜ステップＳ４４からなるループ処理を実行する。このループ処理は、Restart_Application_flagの値nを再起動カウンタに設定して(ステップＳ４０)、ステップＳ４１〜ステップＳ４４のループ処理を実行するというものである。このループ処理の制御変数は再起動カウンタであり、この再起動カウンタが0になること(ステップＳ４１でYes)、及び、アプリケーションの起動に成功したこと(ステップＳ４４でYes)が本ループ処理の終了条件である。本ループ処理では、これらのステップＳ４１、ステップＳ４４がNoである限り、再起動カウンタをデクリメントして(ステップＳ４２)、AutoRunアプリケーションを起動するという(ステップＳ４３)を繰り返す。こうした繰り返しにより異常終了において、アプリケーションの再起動がなされるのである。Restart_Application_flagが0であれば、ステップＳ３２を実行する。
【０１５０】
ステップＳ３２は、Continuous_Playback_flagが0であるか、1であるか、2であるかを判定するステップである。もし2であれば、AutoPlayPLの再生画像をフルスクリーン表示にして(ステップＳ３３)、ステップＳ１〜ステップＳ４からなるメインループに戻る。
もし1であれば、AutoPlayPLの再生画像をクオータ表示にしたまま(ステップＳ３４)、ステップＳ１〜ステップＳ４からなるメインループに戻る。
【０１５１】
もし0であれば、ステップＳ３５に移行する。
ステップＳ３５は、エラー管理テーブルのselevt_title_flagが0でないか否かの判定であり、もし0であるならステップＳ３７に移行する。0でないなら、selevt_title_flagの値nを分岐先Titleにして(ステップＳ３６)、図４４のステップＳ７に移行する。
ステップＳ３７は、エラー管理テーブルのNotify_Event_flagが0でないか否かの判定であり、もし0であるならステップＳ３９に移行する。0でないなら、Notify_Event_flagの値nから特定されるイベントnを発生して(ステップＳ３８)、図４４のステップＳ１〜ステップＳ４のメインループに移行する。ステップＳ３９は、エラー管理テーブルのBoot_flagが0でないか否かの判定であり、もし0であるならステップＳ１〜ステップＳ４からなるメインループに移行する。0でないなら、図４４の先頭に移行して、再生装置のブートストラップを実行する。
【０１５２】
以上のように本実施形態によれば、アプリケーションがエラー終了した際、再生装置はどのような処置をとるべきかを、装置側の製造者ではなく、オーサリング担当者が規定しておくことができる。
尚、エラー管理テーブルをもたないタイトルの再生時においてアプリケーションの異常終了が発生した場合に、リカバリー処理を行うようなプログラムを再生装置に組み込んでいてもよい。
【０１５３】
またRestart_Application_Flag〜Rboot_Flagのどれかを指定するような引数をTitleJumpAPIに設けておき、この引数に応じたリカバリー処理をアプリケーションマネージャ３６に実行させてもよい。
(第３実施形態)
第１実施形態においてJava（登録商標）仮想マシンにおけるPL再生は、BD-J Object内のプレイリスト管理テーブルを用いて規定することができた。これに対し本実施形態では、アプリケーションのJMFメソッドによるPL再生を主眼としている。ここで問題になるのがプレイリスト管理テーブルである。つまりPLを再生してよいか否かは、BD-J Object毎のプレイリスト管理テーブルに記述されているから、あるTitleでは再生可能であるが、別のTitleでは再生不可能になることがある。またPL再生は可能であったとしても、著作権保護の観点から、ある種のアプリケーションからの再生を禁じたい場合がある。かかるPL再生の制限を実現するため、第３実施形態では、Permission Controller４２、アプリケーションマネージャ３６が以下の処理を行う。
【０１５４】
パーミッションコントローラ４２は、どれかのアプリケーションがPL再生を要求した場合、そのアプリケーションと相互認証を行い、要求元アプリケーションにPLの再生権限があるかどうかを判定する。もしあれば、当該再生をPlayback Control Engine３２に要求し、なければ不許可を示す応答イベントを要求元アプリケーションに出力する。このPermission Controller４２による許否判定により、ある配給会社の配給にかかるPLを、別の配給会社の配給にかかるアプリケーションが要求したとしても、かかる要求を不許可にすることができる。そのため、正当権限なきアプリケーションによるPLの無断引用を避けることができる。許可とすべきPLとアプリケーションとの組合せ、不許可とすべきPLとアプリケーションとの組合せは、別途BD-ROMに記録されたPermissionファイルに規定されており、Permission Controller４２による判定はこれに基づく。かかるファイルの詳細は本願の主眼ではないので説明を省略する。
【０１５５】
第３実施形態においてアプリケーションマネージャ３６は、現在の再生時点において再生可能なPLを、アプリケーションからの要求に応じて通知する。図４６は、このアプリケーションマネージャ３６による通知処理の処理手順を示すフローチャートである。本フローチャートでは、アプリケーションの起動中において、再生可能なPLの通知を求める要求(GetPL)をアプリケーションが発行したか否かの監視を行っている(ステップＳ４５)。もし発行されれば、現在の再生時点が属しているTitleを構成するBD-J Objectに、プレイリスト管理テーブルが存在するか否かを判定する(ステップＳ４６)。PLの記述があれば、プレイリスト管理テーブルに記述されたPLを再生可能なPLとして要求元のアプリケーションに通知する(ステップＳ４７)。
【０１５６】
PLの記述がなければ、PL再生が不可能な旨を発行元アプリケーションに通知する(ステップＳ４８)。以上が第３実施形態に係るアプリケーションマネージャ３６の処理手順である。
続いてPL再生が要求された場合のアプリケーションマネージャ３６の処理について説明する。第３実施形態に係るアプリケーションマネージャ３６は、図４７のフローチャートに従って処理を行う。
【０１５７】
図４７においてアプリケーションマネージャ３６は、PL再生を要求したアプリケーションが存在するか否かの判定を行っている(ステップＳ５１)。どれかのアプリケーションがPL再生を要求すれば、要求元アプリケーションにPL再生の権利が存在するか否かの認証をPermission Controller４２に行わさせる(ステップＳ５２)。もし再生する権利があれば、Playback Control Engine３２に再生開始を指示して(ステップＳ５３)、Playback Control Engine３２からのサクセス応答を待つ(ステップＳ５４)。
【０１５８】
かかる再生要求があるとPlayback Control Engine３２は、プレイリスト情報の正当性をチェックする。かかる正当性チェックには、プレイリスト情報、Clip情報、AVClipが存在するBD-ROM及びLocal Storage１８において、正当なプレイリストを構成しているかというチェックやプレイリスト情報におけるclip_Information_file_nameにより指定されるClip情報及びAVClipがBD-ROM及びLocal Storage１８に現存するか否かというチェックがある。clip_Information_file_nameにより正しいファイルが参照されていない場合、又は、BD-ROM及びLocal Storage１８から構成される仮想的なパッケージに矛盾があり、正しプレイリストを構成することができない場合、Playback Control Engine３２はfalseを示す応答を返すことになる。また要求元アプリケーションより、高い起動優先度をもつアプリケーションがそのPLを再生しており、PL再生を実現するリソースにおいて競合が生じている場合最もPlayback Control Engine３２は、falseを示す応答を返す。  
【０１５９】
以上の過程を経てサクセス応答があれば、PL再生成功を示すイベントを要求元アプリケーションに出力する(ステップＳ５５)。
サクセス応答がなければ、PL再生失敗を示すイベントを要求元アプリケーションに出力する(ステップＳ５６)。一方、ステップＳ５２において要求元アプリケーションを再生する権利が要求元アプリケーションになければ、PL再生不可を示すイベントを要求元アプリケーションに出力する(ステップＳ５７)。
【０１６０】
以上のように本実施形態によれば、プレイリスト再生可否が各Title毎でバラバラであり、プレイリスト再生の権限をもったアプリケーションやそうでないアプリケーション等様々なアプリケーションがあったとしても、適切なプレイリスト再生を、アプリケーションからの要求に応じて実行することができる。そのため、アプリケーション実行と、プレイリスト再生とを組み合わせた、多彩なコンテンツ表現が可能になる。
【０１６１】
(第４実施形態)
第１実施形態では、Title開始時において、再生を開始したいプレイリストにAutoPlayを示す再生属性を付与して、AutoPlayPLの再生を再生装置に命じていた。これに対し本実施形態では、アンバウンダリーアプリケーションをBD-ROMに記録しておき、Title開始時にあたって、自動的に再生を開始すべきTitleをアンバウンダリーアプリケーションに選択させる改良に関する。
【０１６２】
アンバウンダリーアプリケーションは、Playback Control Engine３２のような、再生装置におけるレジデントアプリケーションと対等な立場にあるアプリケーションであり、プレイリスト管理テーブルに記述されている複数プレイリスト情報の中から再生装置側のPSR設定値に合致するものを選び、通知するとの処理をPlayback Control Engine３２からの要求に応じて実行する。
【０１６３】
PL選択をアンバウンダリーアプリケーションに行わせる場合、かかる選択が必要なTitleにあたっては、プレイリスト管理テーブルにおける再生属性を、全て無指定に設定しておく。これは、”全てが無指定”であることを合図に、Playback Control Engine３２にPL選択をタイトルアンバウンダリーアプリケーションに要求させるためである。
【０１６４】
このアンバウンダリーアプリケーションによる選択は、オーサリング時に規定された選択アルゴリズムに基づく。図４８（ａ）〜（ｃ）は、アンバウンダリーアプリケーションに組み込まれた選択アルゴリズムの内容を表形式に示す図である。この表は、PSRの値が取り得る値の範囲と、PSRがそれらの値になった際、再生すべきPLとを対応付けて示している。このうち図４８（ａ）は、パレンタルレベルに基づく選択アルゴリズムの内容を示す。ここでパレンタルレベルは、再生装置においてPSR(14)に示されている。具体的にいうと、PSR(14)には、ユーザの年齢を示す整数値が設定されており、これを再生装置はパレンタルレベルとして解釈する。図４８（ａ）において、PSR(14)がとりうる値は、14歳未満、14歳以上18歳未満、18歳以上という3つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきPLが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムによる選択を行えば、PSRの設定値が14歳未満ならPlayList#1が、14以上18歳未満ならPlayList#2が、18歳以上ならPlayList#3がそれぞれ選択されることになる。
【０１６５】
図４８（ｂ）は、Languege for Audioに基づく選択アルゴリズムの内容を示す。ここでLanguege for Audioは、再生装置においてPSR(16)に示されている。具体的にいうと、PSR(16)には、整数値が設定されており、これを再生装置は音声再生用の言語設定として解釈する。図４８（ｂ）において、PSR(16)がとりうる値は、英語を示す値、日本語を示す値、その他の値という3つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきPLが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムによる選択を行えば、PSR(16)の設定値が英語を示すならPlayList#1が、日本語を示すならPlayList#2が、英語、日本語以外の値ならPlayList#3がそれぞれ選択されることになる。
【０１６６】
図４８（ｃ）は、Player Configuration for Videoに基づく選択アルゴリズムの内容を示す。ここでPlayer Configuration for Videoは、再生装置においてPSR(14)に示されている。具体的にいうと、PSR(14)には、整数値が設定されており、これを再生装置は映像再生用の環境設定として解釈する。図４８（ｃ）において、PSR(14)がとりうる値は、解像度525×600 TVsystem LetterBox  解像度525×600  TVsystem、1920×1080 TVsystemという3つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきPLが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムに従って選択を行えば、PSR(14)の設定値が解像度525×600 TVsystem LetterBoxを示すものならPlayList#1が、解像度525×600を示すものならPlayList#2が、 TVsystem、1920×1080 TVsystemを示すものならPlayList#3がそれぞれ選択されることになる。図４８（ａ）〜（ｃ）に示したような選択アルゴリズムは、これらの図に示される条件分岐を、コンピュータ記述言語で記述することにより作成することができる。
【０１６７】
以上が本実施形態に係る記録媒体の改良である。続いて本実施形態に係る再生装置の改良について説明する。本実施形態での改良点は。主としてアプリケーションマネージャ３６、Playback Control Engine３２にある。
アプリケーションマネージャ３６は、Titleの分岐が生じ、プレイリスト管理テーブルを参照した際、そのプレイリスト管理テーブルにAutoPlayPLが存在するか否かを判定する。AutoPlayPLが無ければ、プレイリスト管理テーブルをPlayback Control Engine３２に引き渡して、このプレイリスト管理テーブルに記載されているPLのうち、どれかを自動的に再生するようPlayback Control Engine３２に要求する。
【０１６８】
Playback Control Engine３２は、プレイリスト管理テーブルの引き渡しを受ければ、アンバウンダリーアプリケーションに対し、PL選択を行うよう要求する。この要求に応じてアンバウンダリーアプリケーションから再生可能なPLのリストが通知されれば、そのPLリストに記載されたPLのうち、PlayItemから引き渡されたプレイリスト管理テーブルに存在するものを判定する。アンバウンダリーアプリケーションにより選択されたPLの中に、プレイリスト管理テーブルに記載されたものがあれば、それの再生を自動的に開始する。
【０１６９】
図４９は、タイトルアンバウンダリーアプリケーションにPL選択を行わせる過程を模式的に描いた図である。本図の左側は再生装置におけるソフトウェアのレイヤ構成を示し、本図の右側に、BD-ROMの記録内容を示す。図中の◎1,2,3,4は、AutoPlayがないプレイリスト管理テーブルを発見した場合の、アプリケーションマネージャ３６からの通知(◎1)、Playback Control Engine３２による再生可能PLの問合せ(◎2)、タイトルアンバウンダリーアプリケーションによるPSR設定値取得(◎3)、タイトルアンバウンダリーアプリケーションからPlayback Control Engine３２への再生可能なPLの通知(◎4)を模式的に描いている。
【０１７０】
尚、図４９においてタイトルアンバウンダリーアプリケーションは、BD-ROM上に記述していたが、これはタイトルアンバウンダリーアプリケーションを、わかり易く記述するための配慮に過ぎない。タイトルアンバウンダリーアプリケーションは、Java（登録商標）アプリケーションであるので、Java（登録商標）仮想マシン３８内のワークメモリ５４においてインスタンスとしてスレッド５５により実行されるというのが、現実的な記述になる。
【０１７１】
以上のように本実施形態によれば、Titleのバウンダリで生存しているようなアプリケーションに、上述したような判定を行わせるので、再生装置側のPlayback Control Engine３２は、BD-ROMにおける複数PLのうち、再生装置側の状態設定に応じたものはどれであるかを、Title開始時の早い段階で知得することができる。再生属性＝AutoPlayのアプリケーションを決めておかなくても、Title開始時に再生を開始すべきPLを決定することができるので、ラングエージクレジットやパレンタルロックといった再生制御をBD-Jモードにおいても実現することができる。
【０１７２】
尚、本実施形態における選択アルゴリズムは、PSRがとり得る値をプレイリストに対応づけたが、再生装置におけるPSRの設定値が、想定外の値であった場合に、再生装置に再生させるプレイリストを予め規定しておいてもよい。
(第５実施形態)
第４実施形態においてタイトルアンバウンダリーアプリケーションは、PSRの設定値に応じて再生すべきPLを選択するという選択アルゴリズムを有していたが、本実施形態に係るタイトルアンバウンダリーアプリケーションは、1つのPL内にマルチアングル区間がある場合、当該マルチアングル区間における複数アングルのどれかを選ぶとの処理を、タイトルアンバウンダリーアプリケーションに行わせる改良に関する。本実施形態に係るタイトルアンバウンダリーアプリケーションは、PSRがとりうる値の複数の範囲と、それら範囲毎に再生すべきアングルとを対応づけたものである。本実施形態において現在の再生時点がマルチアングル区間であるとPlayback Control Engine３２はタイトルアンバウンダリーアプリケーションに対し、何れのアングルを再生するかの問い合わせを行う。かかる問い合わせがあれば、タイトルアンバウンダリーアプリケーションは現在におけるPSR設定値を取得し、選択アルゴリズムを実行して、取得した設定値に応じたアングルを選択する。その選択結果をPlayback Control Engine３２に通知してそのアングルの再生をPlayback Control Engine３２に行わせる。
【０１７３】
以上のように本実施形態によれば、PSRがどの値であるとき、どのアングルを選択するというアルゴリズムを、オーサリング担当者が規定しておくことができるので、アングルを応用した様々なアプリケーションをオーサリング担当者は作り出すことができる。
(第６実施形態)
BD-Jモードにおいて、PL再生との同期をどのように実現するかという改良に関する。Playback Control Engine３２は、PlayPLAPIファンクションがコールされれば、PL情報に基づく処理手順を実行する。PLが2時間という再生時間を有するなら、この2時間の間、上述した処理は継続することになる。ここで問題になるのは、Java（登録商標）仮想マシン３８がサクセス応答を返す時間と、Playback Control Engine３２が実際に処理を終える時間とのギャップである。Java（登録商標）仮想マシン３８は、イベントドリブンの処理主体であるためコール直後に再生成功か、再生失敗かを示す応答を返すが、Playback Control Engine３２による実際の処理終了は2時間経過後であるので、サクセス応答をアプリケーションに返す時間を基準にしたのでは、2時間経過後にあたる処理終結を感知しえない。PL再生において早送り、巻戻し、Skipが行われると、この2時間という再生期間は2時間前後に変動することになり、処理終結の感知は更に困難になる。
【０１７４】
Playback Control Engine３２は、アプリケーションとスタンドアローンで動作するため、アプリケーションマネージャ３６は、PL再生の終了時点を正確に解釈することができない。そこで本実施形態では、アプリケーションが終了してようがいまいが、ワークメモリにJMFプレーヤインスタンスがある限り、つまり、Presentation Engine３１の制御権をBD-Jモジュール３５が掌握している間、Playback Control Engine３２からNotifyイベントを待つ。そしてNotifyイベントがあれば、タイトルが終了したと解釈して、次のタイトルへの分岐を行うようモジュールマネージャ３４に通知する。こうすることにより、Playback Control Engine３２がPL再生を終結した時点を、タイトルの終端とすることができる。
【０１７５】
以降図５０〜図５４のフローチャートを参照して、Playback Control Engine３２による具体的な制御手順を説明する。
図５０は、Playback Control Engine３２によるPL再生手順を示すフローチャートである。この再生手順は、Presentation Engine３１に対する制御(ステップＳ１０６)と、BD-ROMドライブ１又はLocal Storage１８に対する制御(ステップＳ１０８)とを主に含む。本フローチャートにおいて処理対象たるPlayItemをPlayItem#xとする。本フローチャートは、カレントPL情報(.mpls)の読み込みを行い(ステップＳ１０１)、その後、ステップＳ１０２〜ステップＳ１１０の処理を実行するというものである。ここでステップＳ１０２〜ステップＳ１１０は、ステップＳ１０９がYesになるまで、カレントPL情報を構成するそれぞれのPI情報について、ステップＳ１０３〜ステップＳ１１０の処理を繰り返すというループ処理を構成している。このループ処理において処理対象となるPlayItemを、PlayItem#x(PI#x)とよぶ。このPlayItem#xは、カレントPLの先頭のPlayItemに設定されることにより、初期化される(ステップＳ１０２)。上述したループ処理の終了要件は、このPlayItem#xがカレントPLの最後のPlayItemになることであり(ステップＳ１０９)、もし最後のPlayItemでなければ、カレントPLにおける次のPlayItemがPlayItem#xに設定される(ステップＳ１１０)。
【０１７６】
ループ処理において繰り返し実行されるステップＳ１０３〜ステップＳ１１０は、PlayItem#xのClip_information_file_nameで指定されるClip情報をシナリオメモリ２５に読み込み(ステップＳ１０３)、PlayItem#xのIn_timeを、カレントClip情報のEPmapを用いて、Iピクチャアドレスuに変換し(ステップＳ１０４)、PlayItem#xのOut_timeを、カレントClip情報のEP_mapを用いて、Iピクチャアドレスvに変換して(ステップＳ１０５)、これらの変換で得られたアドレスvの次のIピクチャを求めて、そのアドレスの1つ手前をアドレスwに設定し(ステップＳ１０７)、そうして算出されたアドレスwを用いて、IピクチャアドレスuからアドレスwまでのTSパケットの読み出しをBD-ROMドライブ１又はLocal Storage１８に命じるというものである(ステップＳ１０８)。
【０１７７】
一方、Presentation Engine３１に対しては、カレントPLMarkのmark_time_stampからPlayItem#xのOut_timeまでの出力を命じる(ステップＳ１０６)。以上のステップＳ１０５〜ステップＳ１０８により、AVClipにおいて、PlayItem#xにより指示されている部分の再生がなされることになる
その後、PlayItem#xがカレントPLの最後のPIであるかの判定がなされる(ステップＳ１０９)。
【０１７８】
PlayItem#xがカレントPLの最後のPIでなければ、カレントPLにおける次のPlayItemを、PlayItem#xに設定して(ステップＳ１１０)、ステップＳ１０３に戻る。以上のステップＳ１０３〜ステップＳ１１０を繰り返することにより、PLを構成するPIは順次再生されることになる。
図５１は、アングル切り換え手順及びSkipBack,SkipNextの手順を示すフローチャートである。本フローチャートは、図５０の処理手順と並行してなされるものであり、ステップＳ１１１〜Ｓ１１２からなるループ処理を繰り返すというものである。本ループにおけるステップＳ１１１は、アングル切り換えを要求するAPIが、Java（登録商標）仮想マシン３８からコールされたか否かの判定であり、アングル切り換えAPIのコールがあれば、カレントClip情報を切り換えるという操作を実行する。
【０１７９】
図５１のステップＳ１１５は、判定ステップであり、PlayItem#xのis_multi_anglesがオンであるか否かの判定を行う。is_multi_anglesとは、PlayItem#xがマルチアングルに対応しているか否かを示すフラグであり、もしステップＳ１１５がNoであるならステップＳ１１３に移行する。ステップＳ１１５がYesであるなら、ステップＳ１１６〜ステップＳ１１９を実行する。ステップＳ１１６〜ステップＳ１１９は、切り換え後のアングル番号を変数yに代入して(ステップＳ１１６)、PlayItem#xにおけるy番目のClip_information_file_nameで指定されているClip情報をシナリオメモリ２１に読み出し(ステップＳ１１７)、カレントPTMを、カレントClip情報のEP_mapを用いてIピクチャアドレスuに変換し(ステップＳ１１８)、PlayItem#xのOut_timeを、カレントClip情報のEP_mapを用いてIピクチャアドレスvに変換する(ステップＳ１１９)というものである。こうしてIピクチャアドレスu,vを変化した後、同時実行されている図５０側の処理を停止させた上でステップＳ１０６に移行する。ステップＳ１０６への移行により、別のAVClipからTSパケットが読み出されるので、映像内容が切り換わることになる。
【０１８０】
一方、図５１のループにおけるステップＳ１１２は、SkipBack/SkipNextを意味するAPIがJava（登録商標）仮想マシン３８からコールされたか否かの判定であり、もしコールされれば、図５２のフローチャートの処理手順を実行する。図５２は、SkipBack,SkipNextAPIがコールされた際の処理手順を示すフローチャートである。SkipBack,SkipNextを実行するにあたっての処理手順は多種多様なものである。ここで説明するのはあくまでも一例に過ぎないことに留意されたい。
【０１８１】
ステップＳ１２１は、PSRで示されるカレントPI番号、及び、カレントPTMを変換することにより、カレントMark情報を得る。ステップＳ１２２は、押下されたのがSkipNextキーであるか、SkipBackキーであるかの判定であり、SkipNextキーであるならステップＳ１２３において方向フラグを+1に設定し、SkipBackキーであるならステップＳ１２４において方向フラグを-1に設定する。
【０１８２】
ステップＳ１２５は、カレントPLMarkの番号に方向フラグの値を足した番号を、カレントPLMarkの番号として設定する。ここでSkipNextキーであるなら方向フラグは+1に設定されているのでカレントPLMarkはインクリメントされることになる。SkipBackキーであるなら方向フラグは-1に設定されているので、カレントPLMarkはデクリメントされることになる。
【０１８３】
ステップＳ１２６では、カレントPLMarkのref_to_PlayItem_Idに記述されているPIを、PlayItem#xに設定し、ステップＳ１２７では、PlayItem#xのClip_information_file_nameで指定されるClip情報を読み込む。ステップＳ１２８では、カレントClip情報のEP_mapを用いて、カレントPLMarkのmark_time_stampを、Iピクチャアドレスuに変換する。一方ステップＳ１２９では、PlayItem#xのOut_timeを,カレントClip情報のEP_mapを用いて,Iピクチャアドレスvに変換する。ステップＳ１３０は、カレントPLMarkのmark_time_stampからPlayItem#xのOut_timeまでの出力をPresentation Engine３１に命じて、同時実行されている図５０側の処理を停止させた上で、図５０のステップＳ１０７に移行する。こうしてIピクチャアドレスu,vを変化して、別の部分の再生を命じた上でステップＳ１０７への移行するので、別のAVClipからTSパケットが読み出されることになり、映像内容が切り換えが実現する。
【０１８４】
図５３は、Presentation Engine３１による処理手順の詳細を示すフローチャートである。本フローチャートは、IピクチャのPTSをカレントPTMに設定した後で(ステップＳ１３１)、ステップＳ１３２〜ステップＳ１３７からなるループ処理を実行するものである。
続いてステップＳ１３２〜ステップＳ１３７におけるループ処理について説明する。このループ処理は、カレントPTMにあたるピクチャ、オーディオの再生出力と、カレントPTMの更新とを繰り返すものである。本ループ処理におけるステップＳ１３６は、ループ処理の終了要件を規定している。つまりステップＳ１３６は、カレントPTMがPI#xのOut_timeであることをループ処理の終了要件にしている。
【０１８５】
ステップＳ１３３は、早送りAPI、又は、早戻しAPIがJava（登録商標）仮想マシン３８からコールされたか否かの判定である。もしコールされれば、ステップＳ１３８において早送りか早戻しかの判定を行い、早送りであるなら、次のIピクチャのPTSをカレントPTMに設定する(ステップＳ１３９)。このようにカレントPTMを、次のIピクチャのPTSに設定することで、1秒飛びにAVClipを再生してゆくことができる。これにより、2倍速等でAVClipは順方向に早く再生されることになる。早戻しであるなら、カレントPTMがPlayItem#xのOut_timeに到達したかを判定する(ステップＳ１４０)。もし到達してないのなら、1つ前のIピクチャのPTSをカレントPTMに設定する(ステップＳ１４１)。このように読出先アドレスAを、1つ前のIピクチャに設定することで、AVClipを後方向に1秒飛びに再生してゆくことができる。これにより、2倍速等でAVClipは、逆方向に再生されることになる。尚、早送り、巻戻しを実行するにあたっての処理手順は多種多様なものである。ここで説明するのはあくまでも一例に過ぎないことに留意されたい。
【０１８６】
ステップＳ１３４は、メニューコールAPIがコールされたか否かの判定であり、もしコールされれば、現在の再生処理をサスペンドして(ステップＳ１４２)、メニュー処理用のメニュープログラムを実行する(ステップＳ１４３)。以上の処理により、メニューメニューコールがなされた場合は、再生処理を中断した上で、メニュー表示のための処理が実行されることになる。
【０１８７】
ステップＳ１３５は、sync_PlayItem_idにより、PlayItem#xを指定したSubPlayItem#yが存在するか否かの判定であり、もし存在すれば、図５４のフローチャートに移行する。図５４は、SubPlayItemの再生手順を示すフローチャートである。本フローチャートでは、先ずステップＳ１４６において、カレントPTMはSubPlayItem#yのsync_start_PTS_of_playItemであるか否かを判定する。もしそうであれば、ステップＳ１５３においてSubPlayItem#yに基づく再生処理を行うようPlayback Control Engine３２に通知する。
【０１８８】
ステップＳ１３６がYesと判定された場合、ステップＳ１４４、ステップＳ１４５を実行する。ステップＳ１４４は、Virtual File System３０からNotify End Of Fileイベントが出力され、尚且つ、デコーダからNotify End Of Decodingイベントが出力されたかを判定する。もし出力されれば、Notify End Of StreamイベントをPlayback Control Engine３２に出力する。
【０１８９】
図５４のステップＳ１４７〜ステップＳ１５２は、SubPlayItem#yに基づく再生処理を示すフローチャートである。
ステップＳ１４７では、SubPlayItem#yのClip_information_file_nameで指定されるClip情報を読み込む。ステップＳ１４８では、カレントClip情報のEP_mapを用いて、SubPlayItem#yのIn_timeを、アドレスαに変換する。一方ステップＳ１４９では、SubPlayItem#yのOut_timeを,カレントClip情報のEP_mapを用いて、アドレスβに変換する。ステップＳ１５０は、SubPlayItem#yのIn_timeからSubPlayItem#yのOut_timeまでの出力をデコーダに命じる。これらの変換で得られたアドレスβの次のIピクチャを求めて、そのアドレスの1つ手前をアドレスγに設定し(ステップＳ１５１)、そうして算出されたアドレスγを用いて、SubClip#zにおけるアドレスαからアドレスγまでのTSパケットの読み出しをBD-ROMドライブ１又はLocal Storage１８に命じるというものである(ステップＳ１５２)。
【０１９０】
また図５０に戻ってPlayback Control Engine３２の処理の説明の続きを行う。ステップＳ１１３はPresentation Engine３１による再生制御が完了したかの判定であり、最後のPlayItem#xに対して、図５３のフローチャートの処理が行われている限り、ステップＳ１１３がNoになる。図５３のフローチャートの処理が終了して初めて、ステップＳ１１３はYesになりステップＳ１１４に移行する。ステップＳ１１４は、Java（登録商標）仮想マシン３８へのNotifyイベントの出力であり、この出力により、2時間という再生時間の経過をJava（登録商標）仮想マシン３８は知ることができる。
【０１９１】
以上のように本実施形態によれば、2時間という再生時間の経過時点をアプリケーションマネージャ３６は把握することができるので、プレイリストの再生終了と同期した処理をJava（登録商標）仮想マシン３８に実行させることができる。
(備考)
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記(A)(B)(C)(D)・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の技術分野の、出願当時の技術水準の特性に基づく。
【０１９２】
(A)全ての実施形態では、本発明に係る光ディスクをBD-ROMとして実施したが、本発明の光ディスクは、記録される動的シナリオ、Index Tableに特徴があり、この特徴は、BD-ROMの物理的性質に依存するものではない。動的シナリオ、Index Tableを記録しうる記録媒体なら、どのような記録媒体であってもよい。例えば、DVD-ROM,DVD-RAM,DVD-RW,DVD-R,DVD+RW,DVD+R,CD-R,CD-RW等の光ディスク、PD,MO等の光磁気ディスクであってもよい。また、コンパクトフラッシュ（登録商標）カード、スマートメディア、メモリスティック、マルチメディアカード、PCM-CIAカード等の半導体メモリカードであってもよい。フレシキブルディスク、SuperDisk,Zip,Clik!等の磁気記録ディスク(i)、ORB,Jaz,SparQ,SyJet,EZFley,マイクロドライブ等のリムーバルハードディスクドライブ(ii)であってもよい。更に、機器内蔵型のハードディスクであってもよい。
(B) 全ての実施形態における再生装置は、BD-ROMに記録されたAVClipをデコードした上でTVに出力していたが、再生装置をBD-ROMドライブのみとし、これ以外の構成要素をTVに具備させてもい、この場合、再生装置と、TVとをIEEE1394で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレィと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなす部分のみを、再生装置としてもよい。これらの再生装置は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、各実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。各実施形態に示した再生装置の有償・無償による譲渡(有償の場合は販売、無償の場合は贈与になる)、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。
【０１９３】
(C)各フローチャートに示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムの実施行為についての実施形態を示したが、再生装置から分離して、各実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為(1)や、有償・無償によりプログラムを譲渡する行為(2)、貸与する行為(3)、輸入する行為(4)、双方向の電子通信回線を介して公衆に提供する行為(5)、店頭展示、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為(6)がある。
【０１９４】
(D)各フロ−チャ−トにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフロ−チャ−トによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフロ−チャ−トの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。
【０１９５】
(E)BD-ROMに記録するにあたって、AVClipを構成する各TSパケットには、拡張ヘッダを付与しておくことが望ましい。拡張ヘッダは、TP_extra_headerと呼ばれ、『Arribval_Time_Stamp』と、『copy_permission_indicator』とを含み4バイトのデータ長を有する。TP_extra_header付きTSパケット(以下EX付きTSパケットと略す)は、32個毎にグループ化されて、3つのセクタに書き込まれる。32個のEX付きTSパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。3個のセクタに収められた32個のEX付きTSパケットを”Aligned Unit”という。
【０１９６】
IEEE1394を介して接続されたホームネットワークでの利用時において、再生装置２００は、以下のような送信処理にてAligned Unitの送信を行う。つまり送り手側の機器は、Aligned Unitに含まれる32個のEX付きTSパケットのそれぞれからTP_extra_headerを取り外し、TSパケット本体をDTCP規格に基づき暗号化して出力する。TSパケットの出力にあたっては、TSパケット間の随所に、isochronousパケットを挿入する。この挿入箇所は、TP_extra_headerのArribval_Time_Stampに示される時刻に基づいた位置である。TSパケットの出力に伴い、再生装置２００はDTCP_Descriptorを出力する。DTCP_Descriptorは、TP_extra_headerにおけるコピー許否設定を示す。ここで「コピー禁止」を示すようDTCP_Descriptorを記述しておけば、IEEE1394を介して接続されたホームネットワークでの利用時においてTSパケットは、他の機器に記録されることはない。
【０１９７】
(F)各実施形態において、記録媒体に記録されるデジタルストリームはAVClipであったが、DVD-Video規格、DVD-Video Recording規格のVOB(Video Object)であってもよい。VOBは、ビデオストリーム、オーディオストリームを多重化することにより得られたISO/IEC13818-1規格準拠のプログラムストリームである。またAVClipにおけるビデオストリームは、MPEG4やWMV方式であってもよい。更にオーディオストリームは、Linear-PCM方式、Dolby-AC3方式、MP3方式、MPEG-AAC方式、Dts、WMA(Windows （登録商標）media audio)であってもよい。
【０１９８】
(G)各実施形態における映像作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
またビデオテープに記録されているアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。
【０１９９】
(H)BD-Jモジュール３５は、衛星放送受信のために機器に組み込まれたJava（登録商標）プラットフォームであってもよい。BD-Jモジュール３５がかかるJava（登録商標）プラットフォームであれば、本発明に係る再生装置は、MHP用STBとしての処理を兼用することになる。
更に携帯電話の処理制御のために機器に組み込まれたJava（登録商標）プラットフォームであってもよい。かかるBD-Jモジュール３５がかかるJava（登録商標）プラットフォームであれば、本発明に係る再生装置は、携帯電話としての処理を兼用することになる。
【０２００】
(I)レイアモデルにおいて、BD-Jモードの上にHDMVモードを配置してもよい。特にHDMVモードでの動的シナリオの解釈や、動的シナリオに基づく制御手順の実行は、再生装置に対する負担が軽いので、HDMVモードをBD-Jモード上で実行させても何等問題は生じないからである。また再生装置や映画作品の開発にあたって、動作保証が1つのモードで済むからである。
【０２０１】
更にBD-Jモードだけで再生処理を実行してもよい。第５実施形態に示したように、BD-JモードでもPLの再生と同期した再生制御が可能になるから、強いてHDMVモードを設けなくてもよいという理由による。
(J)AVClipに多重化されるべきインタラクティブグラフィクスストリームにナビゲーションコマンドを設けて、あるPLから別のPLへの分岐を実現しても良い。  (K)第１実施形態では、1つのBD-ROMに属する複数タイトルの全てを生存区間とするタイトルとしてタイトルアンバウンダリーアプリケーションを規定した。この他にも、複数のBD-ROMに属するタイトルの全てを生存区間とするタイトルアンバウンダリーアプリケーションを規定してもよい。
【０２０２】
(L)第１実施形態でアプリケーション管理テーブルを作成するにあたって、同時実行し得るアプリケーションの数は、例えば4個以下に制限することが望ましい。
アプリケーションの同時実行数を4個以下に制限する理由は以下の通りである。BD-ROMの再生装置は、デジタル放送のチューナ機能を具備しているものが多く、そのチューナ機能を実現するアプリケーションがメモリに常駐(レジデント)していることも多い。かかるレジデントアプリケーションが動作する余地を生むため、アプリケーションの数は4つ以下に制限されている。4つのアプリケーションの内訳として、1つ目をタイトルアンバウンダリーアプリケーション、2つ目をタイトルバウンダリアプリケーション、3つ目をチャプターバウンダリーアプリケーションとしておくことが望ましい。
【０２０３】
(M)第２実施形態においてエラー管理テーブルは、1つのアプリケーションが異常終了した際、1つのリカバリー処理を実行するよう規定されていた。しかし1つのアプリケーションが異常終了した際、複数のリカバリー処理を実行するようにしてもよい。つまりあるアプリケーションが異常終了した際、プレイリスト再生を継続と、アプリケーションと再起動と、イベント出力とを再生装置に実行させてもよい。
【０２０４】
またアプリケーション毎ではなく、1つのタイトルにつき1つのリカバリー処理を規定するようエラー管理テーブルを構成してもよい。
(N)AVClipには、メニューを表示して対話的な操作を受け付けるためのインタラクティブグラフィクスストリームを多重化しておくことができるため、トップメニューを表示して対話的な操作を受け付けるようなAVClipを、単に再生させるようなナビゲーションコマンドをMovieObjectに記述しておくだけで、トップメニュータイトルを製作してもよい。
【０２０５】
(O)各実施形態におけるディレクトリ・ファイル構成及びファイル内のデータ構造は一例であり、本発明の特徴である管理情報は、ディレクトリ・ファイル構成及びファイル内のデータ構造に依存しない。例えばBD-Jモードの動作シナリオであるBD-J Objectは、識別子bobj_idと、識別子BD-Jが付与されたファイル(ZZZZZ.BD-J)として、BDJAディレクトリに配置し、BD-J Object.bdmvのBD-J Object[n]()には、識別子bobj_idのみを格納してよい。
【産業上の利用可能性】
【０２０６】
本発明に係る記録媒体及び再生装置は、ホームシアターシステムでの利用のように、個人的な用途で利用されることがありうる。しかし本発明は上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る記録媒体及び再生装置は、産業上の利用可能性を有する。
【図面の簡単な説明】
【０２０７】
【図１】  本発明に係る再生装置の使用行為についての形態を示す図である。
【図２】  BD-ROMにおけるファイル・ディレクトリ構成を示す図である。
【図３】  PL情報の構成を示す図である。
【図４】  AVClip時間軸と、PL時間軸との関係を示す図である。
【図５】  4つのClip_Information_file_nameによりなされた一括指定を示す図である。
【図６】  PLmark情報の内部構成を示す図である。
【図７】  PLmarkによるチャプター定義を示す図である。
【図８】  SubPath情報の内部構成を示す図である。
【図９】  SubPlayItem時間軸上の再生区間定義と、同期指定とを示す図である。
【図１０】  Movie Objectの内部構成を示す図である。
【図１１】  BD-J Objectの内部構成を示す図である。
【図１２】
（ａ）Java（登録商標）アーカイブファイルに収められているプログラム、データを示す図である。
（ｂ）クラスファイルの内部構成を示す図である。
【図１３】  ディスクコンテンツにおける状態遷移を示す図である。
【図１４】  HDMVモードの動的シナリオから構成されるTitleを示す図である。
【図１５】  BD-Jモードの動的シナリオ(BD-J Object)により構成されるTitleの内部構成を示す図である。
【図１６】  プレイリスト管理テーブルをもたないTitleを示す図である。
【図１７】  HDMVモードのTitleから、BD-JモードのTitleへの分岐を示す図である。
【図１８】  BD-JモードのTitleから、HDMVモードのTitleへの分岐を示す図である。
【図１９】  index.bdmvの内部構成を示す図である。
【図２０】
（ａ）アプリケーション管理テーブルの内部構成を示す図である。
（ｂ）アプリケーション管理テーブルを構成する情報要素の意味内容を示す図である。
【図２１】
（ａ）BD-ROM全体の時間軸を示す図である。
（ｂ）  BD-ROM全体の時間軸における構成を示す図である。
【図２２】（ａ）（ｂ）  BD-ROM全体の時間軸において、識別子bobj_idにより特定されるBD-J Objectから特定されるタイトル再生区間を示す図である。  
【図２３】  図２２（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。
【図２４】  本編タイトル、オンラインショッピングタイトル、ゲームタイトルという3つのタイトルを含むディスクコンテンツを示す図である。
【図２５】（ａ）（ｂ）アプリケーション管理テーブル、生存区間の一例を示す図である。
【図２６】  起動属性がとり得る三態様(Present、AutoRun、Suspend)と、直前タイトルにおけるアプリケーション状態の三態様(非起動、起動中、Suspend)とがとりうる組合せを示す図である。
【図２７】
（ａ）プレイリスト管理テーブルの内部構成を示す図である。
（ｂ）プレイリスト管理テーブルを構成する情報要素の意味内容を示す図である。
【図２８】  分岐先Titleがとり得る三態様(プレイリスト管理テーブル無し、プレイリスト管理テーブル有りで尚且つPresent、プレイリスト管理テーブル有りで尚且つAutoPlay)と、直前タイトルにおけるPLの状態(非再生状態、再生中状態)とがとりうる6通りの組合せを示す図である。
【図２９】
（ａ）プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例を示す図である。
（ｂ）図２９（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。
【図３０】
（ａ）プレイリスト管理テーブルの他の記述例を示す図である。
（ｂ）図３０（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。
【図３１】
（ａ）〜（ｃ）  プレイリスト時間軸と、タイトルの再生区間との関係を示す図である。
【図３２】  本発明に係る再生装置の内部構成を示す図である。
【図３３】  ROM２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。
【図３４】  Presentation Engine３１〜モジュールマネージャ３４による処理を模式化した図である。
【図３５】  アプリケーションマネージャ３６による処理を模式化した図である。
【図３６】  User Event Manager３７〜Default Operation Manager４０を示す図である。
【図３７】  Java（登録商標）仮想マシン３８の内部構成を示す図である。
【図３８】  アプリケーション終了の4態様を示す図である。
【図３９】  アプリケーションマネージャ３６による処理手順を示す図である。
【図４０】  プレイリスト管理テーブル、アプリケーション管理テーブルの具体例を示す図である。
【図４１】
（ａ）第２実施形態に係るBD-J Objectの内部構成を示す図である。
【０２１３】
（ｂ）  エラー管理テーブルの内部構成を示す図である。
【図４２】  エラー管理テーブルにおける5つのフラグの意味内容を示す。
【図４３】
（ａ）エラー管理テーブルが記述された2つのTitle(title#1、title#2)を示す図である。
（ｂ）図４３（ａ）のように記載されたアプリケーション管理テーブル、エラー管理テーブルに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。
【図４４】  第２実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。
【図４５】  第２実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。
【図４６】  アプリケーションマネージャ３６による通知処理の処理手順を示すフローチャートである。
【図４７】  第３実施形態に係るアプリケーションマネージャ３６の処理手順を示す図である。
【図４８】
（ａ）パレンタルレベルに基づく選択アルゴリズムの内容を示す。
（ｂ）Languege for Audioに基づく選択アルゴリズムの内容を示す。
（ｃ）Player Configuration for Videoに基づく選択アルゴリズムの内容を示す。
【図４９】  タイトルアンバウンダリーアプリケーションにPL選択を行わせる過程を模式的に描いた図である。
【図５０】  Playback Control Engine３２によるPL再生手順を示すフローチャートである。
【図５１】  アングル切換、SkipBack,SkipNextの受付手順を示すフローチャートである。
【図５２】  SkipBack,SkipNextAPIがコールされた際の処理手順を示すフローチャートである。
【図５３】  Presentation Engine３１による処理手順の詳細を示すフローチャートである。
【図５４】  SubPlayItemの再生手順を示すフローチャートである。
【符号の説明】
【０２０８】
１    BD-ROMドライブ
２    リードバッファ
３    デマルチプレクサ
４    ビデオデコーダ
５    ビデオプレーン
６    P-Graphicsデコーダ
７    Presentation Graphicsプレーン
８    合成部
９    フォントゼネレータ
１０    I-Graphicsデコーダ
１１    スイッチ
１２    Interctive Graphicsプレーン
１３    合成部
１４    CLUT部
１５    CLUT部
１６    オーディオデコーダ
２２    ユーザイベント処理部
２３    PSRセット
２４    CPU
２５    シナリオメモリ
２６    ローカルメモリ
３３    HDMVモジュール
３４    モジュールマネージャ
３５    BD-Jモジュール
３６    アプリケーションマネージャ
３７    UOコントローラ
３８    Java（登録商標）仮想マシン
４１    PLMTプロセッサ
４２    パーミッションコントローラ
５２    ユーザクラスローダ
５３    メソッドエリア
５４    ワークメモリ
５５a,b・・・n    スレッド
５６a,b・・・d    Java（登録商標）スタック
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2005045840.tif 000056
【図２】
2005045840.tif 000057
【図３】
2005045840.tif 000058
【図４】
2005045840.tif 000059
【図５】
2005045840.tif 000060
【図６】
2005045840.tif 000061
【図７】
2005045840.tif 000062
【図８】
2005045840.tif 000063
【図９】
2005045840.tif 000064
【図１０】
2005045840.tif 000065
【図１１】
2005045840.tif 000066
【図１２】
2005045840.tif 000067
【図１３】
2005045840.tif 000068
【図１４】
2005045840.tif 000069
【図１５】
2005045840.tif 000070
【図１６】
2005045840.tif 000071
【図１７】
2005045840.tif 000072
【図１８】
2005045840.tif 000073
【図１９】
2005045840.tif 000074
【図２０】
2005045840.tif 000075
【図２１】
2005045840.tif 000076
【図２２】
2005045840.tif 000077
【図２３】
2005045840.tif 000078
【図２４】
2005045840.tif 000079
【図２５】
2005045840.tif 000080
【図２６】
2005045840.tif 000081
【図２７】
2005045840.tif 000082
【図２８】
2005045840.tif 000083
【図２９】
2005045840.tif 000084
【図３０】
2005045840.tif 000085
【図３１】
2005045840.tif 000086
【図３２】
2005045840.tif 000087
【図３３】
2005045840.tif 000088
【図３４】
2005045840.tif 000089
【図３５】
2005045840.tif 000090
【図３６】
2005045840.tif 000091
【図３７】
2005045840.tif 000092
【図３８】
2005045840.tif 000093
【図３９】
2005045840.tif 000094
【図４０】
2005045840.tif 000095
【図４１】
2005045840.tif 000096
【図４２】
2005045840.tif 000097
【図４３】
2005045840.tif 000098
【図４４】
2005045840.tif 000099
【図４５】
2005045840.tif 000100
【図４６】
2005045840.tif 000101
【図４７】
2005045840.tif 000102
【図４８】
2005045840.tif 000103
【図４９】
2005045840.tif 000104
【図５０】
2005045840.tif 000105
【図５１】
2005045840.tif 000106
【図５２】
2005045840.tif 000107
【図５３】
2005045840.tif 000108
【図５４】
2005045840.tif 000109
【手続補正書】
【提出日】平成17年10月3日(2005.10.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
アプリケーションと、デジタルストリームと、管理情報とが記録された記録媒体であって、
前記アプリケーションは、
仮想マシン向けプログラミング言語で記述されたプログラムであり、
仮想マシンによる実行が可能となる生存区間が、予め規定されており、
前記管理情報は、
生存区間において、アプリケーションの実行と同時に行うべきデジタルストリームの再生制御を示す
ことを特徴とする記録媒体。
【請求項２】
前記記録媒体には更に、デジタルストリームの再生経路を規定するプレイリスト情報が複数記録されており、
前記管理情報により示される再生制御は、所定の再生属性が付加されたプレイリスト情報に示される再生経路に従って、デジタルストリームを再生することである、請求項１記載の記録媒体。
【請求項３】
所定の再生属性とは、プレイリスト情報に示される再生経路の再生を自動的に開始する旨を示す属性であり、
前記デジタルストリーム再生の同時実行は、
プレイリスト情報に自動再生を示す再生属性が付加されている場合になされる、ことを特徴とする請求項２記載の記録媒体。
【請求項４】
前記記録媒体には更に、生存区間がないタイトルアンバウンダリーアプリケーションが記録されており、
タイトルアンバウンダリーアプリケーションは、記録媒体に記録されている複数プレイリスト情報のうち、何れか1つを、再生装置における状態レジスタの格納値に応じて選択する処理を行い、
前記所定の再生属性とは、タイトルアンバウンダリーアプリケーションの選択を待って再生される旨を示す再生属性である
ことを特徴とする請求項２記載の記録媒体。
【請求項５】
前記アプリケーションは、記録媒体において複数記録されており、
各アプリケーションのそれぞれは、複数タイトルのどれかに帰属しており、
前記アプリケーションの生存区間は、タイトルを用いて表現されている
ことを特徴とする請求項１記載の記録媒体。
【請求項６】
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、
同記録媒体に記録されたデジタルストリームを再生する再生制御エンジン部と、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させ、それと同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、再生制御エンジン部に実行させるアプリケーションマネージャと
を備えることを特徴とする再生装置。
【請求項７】
前記記録媒体には、プレイリスト情報が複数記録されており、
前記アプリケーションマネージャによる再生制御とは、所定の再生属性が付加されたプレイリスト情報に示される再生経路に従って、デジタルストリームを再生させることである、請求項６記載の再生装置。
【請求項８】
前記所定の再生属性とは、プレイリスト情報に示される再生経路の再生を自動的に開始する旨を示す再生属性である、ことを特徴とする請求項７記載の再生装置。
【請求項９】
前記記録媒体には更に、生存区間がないタイトルアンバウンダリーアプリケーションが記録されており、
タイトルアンバウンダリーアプリケーションは、記録媒体に記録されている複数プレイリスト情報のうち、何れか1つを、再生装置における状態レジスタの格納値に応じて選択する処理を行い、
前記所定の再生属性とは、タイトルアンバウンダリーアプリケーションの選択を待って再生される旨を示す再生属性であり、
前記再生制御エンジン部によるデジタルストリーム再生は、
所定の再生属性が付加されたプレイリスト情報のうちタイトルアンバウンダリーアプリケーションにより選択されたものに基づきなされる
ことを特徴とする請求項７記載の再生装置。
【請求項１０】
前記再生装置は、
何れかのプレイリスト情報を指定した再生がアプリケーションから命じられた場合、当該アプリケーションの正当性を認証するパーミッションコントローラを備え、
前記再生制御エンジン部がプレイリスト情報に基づく再生を行うのは、パーミッションコントローラが正当性ありと認証した場合である
ことを特徴とする請求項７記載の再生装置。
【請求項１１】
アプリケーションマネージャは、プレイリスト情報に基づく再生を行うアプリケーションが存在する場合、当該アプリケーションが再生可能なプレイリスト情報を判定して、当該アプリケーションに通知し、
前記再生制御エンジン部による再生は、通知されたプレイリスト情報に基づく
ことを特徴とする請求項７記載の再生装置。
【請求項１２】
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、同記録媒体に記録されたデジタルストリームを再生する再生制御エンジン部とを有したコンピュータが読み込むことができるプログラムであって、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させるステップと、
仮想マシンによる実行と同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、再生制御エンジン部に実行させるステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項１３】
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、同記録媒体に記録されたデジタルストリームを再生する再生制御エンジン部とを有したコンピュータに対する再生方法であって、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させるステップと、
仮想マシンによる実行と同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、再生制御エンジン部に実行させるステップと
をコンピュータに実行させることを特徴とする再生方法。
【請求項１４】
デジタルストリームを再生する再生装置に組み込むことができるシステム集積回路であって、
記録媒体に記録されたアプリケーションを実行する仮想マシン部と、
各アプリケーションの生存区間が到来すれば、アプリケーションを仮想マシンに実行させ、それと同時に、記録媒体に記録された管理情報に基づくデジタルストリームの再生を、実行させるアプリケーションマネージャと
を備えることを特徴とするシステム集積回路。
【手続補正書】
【提出日】平成18年7月7日(2006.7.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
アプリケーションと、デジタルストリームと前記アプリケーション及び前記デジタルストリームに関連するタイトルと、管理情報とが記録された記録媒体であって、
前記アプリケーションは、
仮想マシン向けプログラミング言語で記述されたプログラムであり、
前記記録媒体に記録されたタイトルの再生区間において、前記仮想マシンのワークメモリ上に前記アプリケーションが読み出され、前記仮想マシンによる前記アプリケーションの実行が可能となる生存区間が、予め規定されており、
前記管理情報は、
前記生存区間において、前記アプリケーションの実行とともに行うべき前記タイトルに関連するデジタルストリームの再生制御を示す
ことを特徴とする記録媒体。
【請求項２】
記録媒体からワークメモリ上に読み出されたアプリケーションを実行する仮想マシン部と、
前記記録媒体に記録されたデジタルストリームであって、前記記録媒体に記録されたタイトルに関連するデジタルストリームを再生する再生制御エンジン部と、
前記記録媒体に記録されたタイトルの再生区間において、前記仮想マシン部のワークメモリ上に前記アプリケーションが読み出され、前記仮想マシン部による前記アプリケーションの実行が可能となる生存区間が到来すれば、前記記録媒体に記録されたアプリケーションを前記ワークメモリに読み出して、前記仮想マシン部に実行させ、前記実行とともに、前記記録媒体に記録された管理情報に基づき前記タイトルに関連するデジタルストリームの再生を、再生制御エンジン部に実行させるアプリケーションマネージャと
を備えることを特徴とする再生装置。
【請求項３】
記録媒体からワークメモリ上に読み出されたアプリケーションを実行する仮想マシン部と、前記記録媒体に記録されたデジタルストリームであって、前記記録媒体に記録されたタイトルに関連するデジタルストリームを再生する再生制御エンジン部とを有したコンピュータが読み込むことができるプログラムであって、
前記記録媒体に記録されたタイトルの再生区間において、前記仮想マシン部のワークメモリ上に前記アプリケーションが読み出され、前記仮想マシン部による前記アプリケーションの実行が可能となる生存区間が到来すれば、前記記録媒体に記録されたアプリケーションを前記ワークメモリに読み出して、前記仮想マシン部に実行させるステップと、
前記仮想マシンによる実行とともに、前記記録媒体に記録された管理情報に基づき前記タイトルに関連するデジタルストリームの再生を、再生制御エンジン部に実行させるステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項４】
記録媒体からワークメモリ上に読み出されたアプリケーションを実行する仮想マシン部と、前記記録媒体に記録されたデジタルストリームであって、前記記録媒体に記録されたタイトルに関連するデジタルストリームを再生する再生制御エンジン部とを有したコンピュータに対する再生方法であって、
前記記録媒体に記録されたタイトルの再生区間において、前記仮想マシン部のワークメモリ上に前記アプリケーションが読み出され、前記仮想マシン部による前記アプリケーションの実行が可能となる生存区間が到来すれば、前記記録媒体に記録されたアプリケーションを前記ワークメモリに読み出して、前記仮想マシン部に実行させるステップと、
前記仮想マシン部による実行とともに、前記記録媒体に記録された管理情報に基づき前記タイトルに関連するデジタルストリームの再生を、前記再生制御エンジン部に実行させるステップと
をコンピュータに実行させることを特徴とする再生方法。
【請求項５】
記録媒体に記録されたデジタルストリームであって、前記記録媒体に記録されたタイトルに関連するデジタルストリームを再生する再生装置に組み込むことができるシステム集積回路であって、
前記記録媒体からワークメモリ上に読み出されたアプリケーションを実行する仮想マシン部と、
前記記録媒体に記録されたタイトルの再生区間において、前記仮想マシン部のワークメモリ上に前記アプリケーションが読み出され、前記仮想マシン部による前記アプリケーションの実行が可能となる生存区間が到来すれば、前記記録媒体に記録されたアプリケーションを前記ワークメモリに読み出して、前記仮想マシン部に実行させ、前記実行とともに、前記記録媒体に記録された管理情報に基づき前記タイトルに関連するデジタルストリームの再生を、実行させるアプリケーションマネージャと
を備えることを特徴とするシステム集積回路。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００５
【補正方法】変更
【補正の内容】
【０００５】
上記目的を達成するため、本発明に係る記録媒体は、アプリケーションと、デジタルストリームと前記アプリケーション及び前記デジタルストリームに関連するタイトルと、管理情報とが記録された記録媒体であって、前記アプリケーションは、仮想マシン向けプログラミング言語で記述されたプログラムであり、前記記録媒体に記録されたタイトルの再生区間において、前記仮想マシンのワークメモリ上に前記アプリケーションが読み出され、前記仮想マシンによる前記アプリケーションの実行が可能となる生存区間が、予め規定されており、前記管理情報は、前記生存区間において、前記アプリケーションの実行とともに行うべき前記タイトルに関連するデジタルストリームの再生制御を示すことを特徴としている。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】変更
【補正の内容】
【０００６】
本発明に係る記録媒体によれば、アプリケーションの生存区間において、実行中のアプリケーションとともに行うべきデジタルストリームの再生制御が規定されている。そのため、アプリケーションの起動に失敗したり、アプリケーションの実行の途中でたとえアプリケーションが異常終了したとしても、同時になされているデジタルストリーム再生を継続することにより、”何かが写っている状態”をもたらすことができる。これにより、装置がブラックアウトしてしまうという最悪ケースを回避することができるので、装置を製造するメーカに、最低限度の安心感を与えることができる。
【国際調査報告】
2005045840.tif 000110
2005045840.tif 000111
2005045840.tif 000112
2005045840.tif 000113