(57)【要約】      （修正有）【課題】記録媒体に対する制御を実現するようなアプリケーションが異常終了した場合、又は、起動に失敗した場合の、Ｆａｉｌ  Ｓａｆｅを提供する。【解決手段】ＢＤ−ＲＯＭには、アプリケーションと、デジタルストリームと、これ等に関連するタイトルと、管理情報とが記録されている。アプリケーションは、仮想マシン向けプログラミング言語で記述されたプログラムであり、仮想マシンによる実行が可能となる生存区間が、予め規定されている。アプリケーションの異常終了や起動失敗の際、一つのタイトルの再生区間において、前記一つのタイトルに帰属するアプリケーションを読み出し、前記仮想マシン部に実行させ、前記管理情報に基づき、前記一つのタイトルに関連するデジタルストリームの再生を行い、装置がブラックアウトするのを回避する。【選択図】図２０
2008140533.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションと、デジタルストリームと、前記アプリケーション及び前記デジタルストリームに関連する複数のタイトルと、管理情報とが記録された記録媒体であって、
前記アプリケーションは、
仮想マシン向けプログラミング言語で記述されたプログラムであり、
前記記録媒体に記録されたタイトルの再生区間において、前記仮想マシンのワークメモリ上に前記アプリケーションが読み出され、前記仮想マシンによる前記アプリケーションの実行が可能となる生存区間が、予め規定されており、
前記アプリケーションは、前記複数のタイトルのどれかに帰属しており、
前記アプリケーションの生存区間は、前記アプリケーションが帰属するタイトルを用いて表現されており、
前記管理情報は、
前記生存区間に対応するタイトルに帰属するアプリケーションの実行とともに行うべき前記タイトルに関連するデジタルストリームの再生制御を示す情報を含む
ことを特徴とする記録媒体。
【請求項２】
記録媒体からワークメモリ上に読み出されたアプリケーションを実行する仮想マシン部と、
前記記録媒体に記録されたデジタルストリームであって、前記記録媒体に記録された複数のタイトルのうちの一のタイトルに関連するデジタルストリームを再生する再生制御エンジン部と、
前記記録媒体に記録された複数のタイトルのうちの一のタイトルの再生区間において、前記一のタイトルに帰属するアプリケーションがあれば、前記仮想マシン部のワークメモリ上に前記一のタイトルに帰属するアプリケーションを読み出して、前記仮想マシン部に実行させ、前記仮想マシン部による実行とともに、前記記録媒体に記録された管理情報に基づき前記一のタイトルに関連するデジタルストリームの再生を、前記再生制御エンジン部に実行させるアプリケーションマネージャ部とを備える
ことを特徴とする再生装置。
【請求項３】
記録媒体からワークメモリ上に読み出されたアプリケーションを実行する仮想マシン部と、
前記記録媒体に記録されたデジタルストリームであって、前記記録媒体に記録された複数のタイトルのうちの一のタイトルに関連するデジタルストリームを再生する再生制御エンジン部と
を有したコンピュータが読み込むことができるプログラムであって、
前記記録媒体に記録された複数のタイトルのうちの一のタイトルの再生区間において、前記一のタイトルに帰属するアプリケーションがあれば、前記仮想マシン部のワークメモリ上に前記一のタイトルに帰属するアプリケーションを読み出して、前記仮想マシン部に実行させるステップと、
前記仮想マシン部による実行とともに、前記記録媒体に記録された管理情報に基づき前記一のタイトルに関連するデジタルストリームの再生を、前記再生制御エンジン部に実行させるステップと
をコンピュータに実行させることを特徴とするプログラム。
【請求項４】
記録媒体からワークメモリ上に読み出されたアプリケーションを実行する仮想マシン部と、
前記記録媒体に記録されたデジタルストリームであって、前記記録媒体に記録された複数のタイトルのうちの一のタイトルに関連するデジタルストリームを再生する再生制御エンジン部と
を有したコンピュータに対する再生方法であって、
前記記録媒体に記録された複数のタイトルのうちの一のタイトルの再生区間において、前記一のタイトルに帰属するアプリケーションがあれば、前記仮想マシン部のワークメモリ上に前記一のタイトルに帰属するアプリケーションを読み出して、前記仮想マシン部に実行させるステップと、
前記仮想マシン部による実行とともに、前記記録媒体に記録された管理情報に基づき前記一のタイトルに関連するデジタルストリームの再生を、前記再生制御エンジン部に実行させるステップと
をコンピュータに実行させることを特徴とする再生方法。
【請求項５】
記録媒体に記録されたデジタルストリームであって、前記記録媒体に記録されたタイトルに関連するデジタルストリームを再生する再生装置に組み込むことができるシステム集積回路であって、
前記記録媒体からワークメモリ上に読み出されたアプリケーションを実行する仮想マシン部と、
前記記録媒体に記録された複数のタイトルのうちの一のタイトルの再生区間において、前記一のタイトルに帰属するアプリケーションがあれば、前記仮想マシン部のワークメモリ上に前記一のタイトルに帰属するアプリケーションを読み出して、前記仮想マシン部に実行させ、前記仮想マシン部による実行とともに、前記記録媒体に記録された管理情報に基づき前記一のタイトルに関連するデジタルストリームの再生を、実行させるアプリケーションマネージャ部とを備える
ことを特徴とするシステム集積回路。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想マシンを対象にしたアプリケーションの実行を制御する、アプリケーション制御の技術分野に属する発明であり、本制御技術を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)、アングル切り換え(AngleChange)を受け付けるキーや、メニュー操作時にあたってのフォーカス移動操作を受け付ける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に示すように複数のSub-PlayItem情報(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の内部構成を示す図である。本図の左端に示すようにMovieOb-ject.bdmvは、コード列”MOBJ”を示す『type_indicater』と、『version_number』と、1つ以上のMovieObjectである『MovieObjects()』とからなる。図中の図中の引き出し線vh1はMovieObjectsの内部構成をクローズアップしている。MovieObjects()は、自身のデータ長である『length』と、自身に含まれるMovieObjectの個数である『num-ber_of_mobjs』と、number_of_mobjs個のMovieObjectである『MovieObjects』とからなる。これらnumber_of_mobjs個のMovieObjectは、識別子mobj_idをもって識別される。図中の引き出し線vh2は、識別子mobj_idにより特定される任意のMovieOb-ject[mobj_id]()の内部構成をクローズアップしている。
【００２４】
この引き出し線に示すように、MovieObjectは、MenuCallがなされた際、MenuCall後の再生再開を意図しているか否かを示す『resume_intention_flag』、MenuCallをマスクするか否かを示す情報『menu_call_mask』、タイトルサーチ機能をマスクするかを示す『title_search_flag』、ナビゲーションコマンドの個数である『num-ber_of_navigation_command』、number_of_navigation_command個の『ナビゲーションコマンド』からなる。
【００２５】
ナビゲーションコマンド列は、条件分岐、再生装置における状態レジスタの設定、状態レジスタの設定値取得等を実現するコマンド列からなる。Movie Objectにおいて記述可能なコマンドを以下に示す。
PlayPLコマンド
書式:PlayPL(第１引数，第２引数)
第１引数は、プレイリストの番号で、再生すべきPLを指定することができる。第２引数は、そのPLに含まれるPlayItemや、そのPLにおける任意の時刻、Chapter、Markを用いて再生開始位置を指定することができる。
【００２６】
PlayItemによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLat-PlayItem()、
ChapterによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlay-PLatChapter()、
時刻情報によりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLat-Specified 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-JObject[bobj_id]()の内部構成をクローズアップしている。
【００３１】
この引き出し線に示すように、本図に示すようにBD-J Objectは、『re-sume_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-JObjectもあるし、プレイリスト管理テーブルをもたない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』と、『In-dexes()』とからなる。『Indexes』は、各Titleに対するインデックスであり、破線の引き出し線ix1でクローズアップしているように、『Indexes』は、『length』,『First-Playback()FirstPlayback_mobj_id_ref』,『TopMenu()TopMenu_mobj_id_ref』,『num-ber_of_Titles』,『Title[0]()〜Title[number_of_Titles-1]()』からなる。
【００４７】
『FirstPlayback()FirstPlayback_mobj_id_ref』は、FirstPlayTitleに対するIndexであり、FirstPlayTitleを構成するMovieObject識別子の参照値(FirstPlay-back_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-JObjectから特定されるタイトル再生区間を示す図である。ここで識別子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-JObjectとして扱われるから、そのMovieObject又はBD-J ObjectにおいてJumpTitleが発生するまでの1つの区間を、Title再生区間として扱う。
【００５８】
続いてTitle区間と、PL時間軸との関係について説明する。上述したようにMovieOb-ject、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ストリームをデコードして、非圧縮グラフィクスをInteractiveGraphicsプレーン１２に書き込む。
【００９８】
スイッチ１１は、フォントゼネレータ９が生成したフォント列、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 StatusRegister(PSR)と、4096個のGeneral Purpose Register（GPR)とからなる。PlayerStatus 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つである。このうちアプリケーションマネージャ３６の中にはPLMTPrcessor４１が存在している。また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)、一時停止の解除(PauseOff)、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に対する再生制御ファンクションとは、PresentationEngine３１が行う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)をローカルメモリ２６に読み出して、このMovieObjectに記述されたナビゲーションコマンドを解読し、解読結果に基づきPlaybackControl Engine３２に対するファンクションコールを実行する。図２８において▽2,▽3,▽4が付された矢印は、モジュールマネージャ３４によるactivate(mobj_id)(2)、MovieObjectに記述されたナビゲーションコマンドの解読(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-JObjectにおけるアプリケーション管理テーブルを参照することで、上述した自動起動すべきアプリケーション及び自動終了すべきアプリケーションを特定する。図３５における
☆0,☆1,☆2,☆3は、TitleJumpの発生(☆0)、activate(bobj_id)の通知(☆1)、アプリケーション管理テーブル参照(☆2)、Java（登録商標）仮想マシン３８に対するアプリケーション起動指示(☆3)という一連の過程を模式化して示す。この起動指示によりJava（登録商標）仮想マシン３８は、ローカルメモリ２６からワークメモリにxletプログラムを読み出す(☆4,5)。
【０１２１】
以上がアプリケーションマネージャ３６についての説明である。続いてUser EventManager３７〜Default Operation Manager４０について、図３６を参照しながら説明する。
User Event Manager３７は、ユーザイベント処理部２２が受け付けたユーザイベントを、再生制御のためのユーザイベントと、キーイベントとに分離する。再生制御のためのユーザイベントとは、再生開始(Play)、再生停止(Stop)、一時停止(Pause On)、一時停止の解除(Pause Off)、Still機能の解除(still off)、速度指定付きの早送り(ForwardPlay(speed))、速度指定付きの巻戻し(Backward Play(speed))、音声切り換え(AudioChange)、副映像切り換え(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３９から振り分けられると、そのEventListner非登録イベントに対応するファンクションコールを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 ControlEngine３２に対するPlayPLファンクションのコール(△1)、Playback Control Engine３２からのNotifyイベント出力(△2)を模式化している。
【０１２６】
以上でBD-Jモジュール３５内のレイヤ構成についての説明を終える。尚、PermissionController４２については、本実施形態における説明を割愛する。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 ListnerManager３９は、このワークメモリ５４に常駐するレジデントアプリケーションである。ワークメモリ５４には、これらレジデント型のインスタンスの他に、メソッドエリア５３に読み出されたクラスファイルに対応するインスタンスが格納される。このインスタンスが、アプリケーションを構成する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４１に判定させる(ステップＳ１０)。もし存在すればPLMTPrcessor４１は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を示す。
【０１４５】
以上のように本実施形態によれば、プレイリスト管理テーブルの再生属性を、”Auto-Play”に設定しておくことにより、Java（登録商標）アプリケーションが動作状態になるまで5〜10秒という時間がかかったとしても、その間、”とりあえず何かが写っている状態”になる。この”とりあえず何かが写っている状態”によりタイトル実行開始時のスタートアップディレイを補うことができる。
【０１４６】
また、アプリケーションの起動に失敗したり、アプリケーションが異常したとしても、プレイリスト管理テーブルで規定されたプレイリストの再生を継続することにより、”とりあえず何かが写っている状態”になる。これにより、装置がブラックアウトしてしまうという最悪ケースを回避することができるので、装置を製造するメーカに、最低限度の安心感を与えることができる。
【０１４７】
(第２実施形態)
第２実施形態は、エラー終了時におけるリカバリー処理を、オーサリング時に規定しておくための改良に関する。かかるリカバリー処理を規定するため、本実施形態に係る記録媒体では、1つのBD-J Object内にエラー管理テーブルを設けている。図４１（ａ）は、第２実施形態に係るBD-J Objectの内部構成を示す図である。本図に示すように、BD-JObjectにはアプリケーション管理テーブル、プレイリスト管理テーブルの他に、エラー管理テーブル(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側のエラー管理テーブルには、このapplica-tion＃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の再生をPlaybackControl 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のどれかを指定するような引数をTitle-JumpAPIに設けておき、この引数に応じたリカバリー処理をアプリケーションマネージャ３６に実行させてもよい。
(第３実施形態)
第１実施形態においてJava（登録商標）仮想マシンにおけるPL再生は、BD-J Object内のプレイリスト管理テーブルを用いて規定することができた。これに対し本実施形態では、アプリケーションのJMFメソッドによるPL再生を主眼としている。ここで問題になるのがプレイリスト管理テーブルである。つまりPLを再生してよいか否かは、BD-JObject毎のプレイリスト管理テーブルに記述されているから、ある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 ControlEngine３２は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を指定したSub-PlayItem＃yが存在するか否かの判定であり、もし存在すれば、図５４のフローチャートに移行する。図５４は、SubPlayItemの再生手順を示すフローチャートである。本フローチャートでは、先ずステップＳ１４６において、カレントPTMはSubPlayItem＃yのsync_start_PTS_of_playItemであるか否かを判定する。もしそうであれば、ステップＳ１５３においてSubPlayItem＃yに基づく再生処理を行うようPlayback ControlEngine３２に通知する。
【０１９３】
ステップＳ１３６がYesと判定された場合、ステップＳ１４４、ステップＳ１４５を実行する。ステップＳ１４４は、Virtual File System３０からNotify End Of Fileイベントが出力され、尚且つ、デコーダからNotify End Of Decodingイベントが出力されたかを判定する。もし出力されれば、Notify End Of StreamイベントをPlayback ControlEngine３２に出力する。
【０１９４】
図５４のステップＳ１４７〜ステップＳ１５２は、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 Configura-tion 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（登録商標）スタック
【図１】
2008140533.tif 000003
【図２】
2008140533.tif 000004
【図３】
2008140533.tif 000005
【図４】
2008140533.tif 000006
【図５】
2008140533.tif 000007
【図６】
2008140533.tif 000008
【図７】
2008140533.tif 000009
【図８】
2008140533.tif 000010
【図９】
2008140533.tif 000011
【図１０】
2008140533.tif 000012
【図１１】
2008140533.tif 000013
【図１２】
2008140533.tif 000014
【図１３】
2008140533.tif 000015
【図１４】
2008140533.tif 000016
【図１５】
2008140533.tif 000017
【図１６】
2008140533.tif 000018
【図１７】
2008140533.tif 000019
【図１８】
2008140533.tif 000020
【図１９】
2008140533.tif 000021
【図２０】
2008140533.tif 000022
【図２１】
2008140533.tif 000023
【図２２】
2008140533.tif 000024
【図２３】
2008140533.tif 000025
【図２４】
2008140533.tif 000026
【図２５】
2008140533.tif 000027
【図２６】
2008140533.tif 000028
【図２７】
2008140533.tif 000029
【図２８】
2008140533.tif 000030
【図２９】
2008140533.tif 000031
【図３０】
2008140533.tif 000032
【図３１】
2008140533.tif 000033
【図３２】
2008140533.tif 000034
【図３３】
2008140533.tif 000035
【図３４】
2008140533.tif 000036
【図３５】
2008140533.tif 000037
【図３６】
2008140533.tif 000038
【図３７】
2008140533.tif 000039
【図３８】
2008140533.tif 000040
【図３９】
2008140533.tif 000041
【図４０】
2008140533.tif 000042
【図４１】
2008140533.tif 000043
【図４２】
2008140533.tif 000044
【図４３】
2008140533.tif 000045
【図４４】
2008140533.tif 000046
【図４５】
2008140533.tif 000047
【図４６】
2008140533.tif 000048
【図４７】
2008140533.tif 000049
【図４８】
2008140533.tif 000050
【図４９】
2008140533.tif 000051
【図５０】
2008140533.tif 000052
【図５１】
2008140533.tif 000053
【図５２】
2008140533.tif 000054
【図５３】
2008140533.tif 000055
【図５４】
2008140533.tif 000056