JP2009170085A - 読出装置、プログラム、読出方法 - Google Patents

Abstract

【課題】光ディスクの交換時において、アプリケーションのスタートアップディレイをなくしつつも、映画作品に関連しないようなアプリケーションを適切に終了させることができる読出装置を提供する。
【解決手段】アプリケーションマネージャは、第１ディスクから第２ディスクへの交換時において、“アプリケーションシグナリング”を行う。この際、第１ディスクで最後に再生されたタイトルに割り当てられたアプリケーション管理テーブルに示されており、尚且つ、第２ディスクで最初に再生されるタイトルに割り当てられたアプリケーション管理テーブルに示されているアプリケーションの実行を継続し、第１ディスクで再生されていたタイトルに割り当てられたアプリケーション管理テーブルに示されているが、第２ディスクで最初に再生されるタイトルに割り当てられたアプリケーション管理テーブルには示されていないアプリケーションの実行を終了させる。
【選択図】図３０

Description

本発明は、デジタル化された映画作品の再生と、アプリケーションの実行とを同時に実行する、再生制御技術の技術分野に属する発明である。

上述した再生制御技術は、デジタル化された映画作品と、様々なアプリケーションとを１つのパッケージに収めて販売するというメディアミックスを実現するにあたって、極めて重要な役割をなす。このアプリケーションが、映画作品の登場人物をキャラクタにしたゲーム的なプログラムであり、デジタル化された映画作品の一部分と同時に実行されるのなら、映像再生と、アプリケーション実行との相乗効果で、映画作品の人気を一層高めることができる。

かかる再生制御技術の先行技術としては、以下の特許文献１に記載されたものがある。
特許第２８１３２４５号公報

ところで近年の映画作品は、ある作品がヒットすれば、その続編が多く作られることが一般的である。そしてそれらシリーズ物の映画作品を複数の光ディスクに記録して、“ＤＶＤ−ＢＯＸ”と呼ばれる高額商品として、販売することは、映画ビジネスの分野において、１つの手法として確立されている。ここでそのように、複数の光ディスクにおいて、互いに関連しあう複数の映画作品が記録されている場合、アプリケーションをどのように制御すればよいかが問題になる。

例えばアプリケーションの実行が、１つの光ディスクが装填されている期間内に限られるとすれば、光ディスクが交換される度に、アプリケーションの終了、起動が繰り返され、アプリケーションのスタートアップディレイが長くなって、ユーザ操作に対するレスポンスが悪くなる。
逆に、アプリケーションの実行が、１つの光ディスクが装填されている期間内に限られないとすれば、光ディスクが装填されていない期間において、アプリケーションは動作していてもよいことになる。そうすると、例えば、読出装置に、悪意のプログラム（ウィルスソフト、スパイウェア等）が侵入していた場合、光ディスクが装填されていない状態で、かかる悪意のプログラムが動作していたとしても、かかるプログラムが悪意のプログラムなのか、映画作品を構成しているアプリケーションなのかが区別できない。そのため、この悪意のプログラムの動作を終了させることができず、みすみす悪意のプログラムに付け入れられるような隙を作ってしまうことになる。

本発明の目的は、光ディスクの交換時において、アプリケーションのスタートアップディレイをなくしつつも、映画作品に関連しないようなアプリケーションを適切に終了させることができる読出装置を提供することである。

上記目的を達成するため、上記目的を達成するため、本発明にかかる読出装置は、第１ディスクに記録されたコンテンツを読み取って再生する再生手段と、そのコンテンツに対応する管理テーブルに基づき、アプリケーションを実行するアプリケーション管理手段とを備え、アプリケーションには、ディスクアンバウンダリのものと、タイトルバウンダリものとがあり、前記アプリケーション管理手段は、ディスクアンバウンダリアプリケーションについては、第１ディスクから第２ディスクへの交換時において、第１ディスクにおけるコンテンツに対応する管理テーブルに示されており、尚且つ、第２ディスクで最初に再生されるコンテンツに対応する管理テーブルに示されている場合に実行を継続し、タイトルバウンダリアプリケーションについては、第１ディスクにおけるコンテンツの再生終了時に実行を終了することを特徴としている。

上記構成によれば、第１ディスクから第２ディスクへの交換時において、第１ディスクにおけるコンテンツに対応する管理テーブルに示されており、尚且つ、第２ディスクで最初に再生されるコンテンツに対応する管理テーブルに示されているアプリケーションの実行を継続するので、第１ディスク取出後にいったん終了し、第２ディスク装填時に、再度起動するという手間は不要になり、アプリケーションの起動のためのスタートアップディレイをほとんどなくすことができる。

第１ディスクで再生されていたコンテンツに対応するアプリケーションの実行を終了させるので、第２ディスクの管理テーブルに示されていないアプリケーションについては、第２ディスクの装填時に、動作が終了させられることになる。悪意のプログラムが侵入していたとしても、第２ディスクの装填を機会に、かかる悪意のプログラムを終了させることができるので、悪意のプログラムに対する対策を施すことができる。

(第１実施形態)
以降、本発明に係る読出装置の実施形態について説明する。先ず始めに、本発明に係る読出装置の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る読出装置の、使用行為についての形態を示す図である。図１において、本発明に係る読出装置は、読出装置２００である。この読出装置２００は、複数のBD-ROM１００からなるBD-BOX、リモコン３００、テレビ４００、AVアンプ５００、スピーカ６００から構成されるホームシアターシステムで使用される。

読出装置２００は、ネット対応型のデジタル家電機器であり、BD-ROM１００を再生する機能をもつ。
以上が、本発明に係る読出装置の使用行為の形態である。
続いて、BD-ROM１００の内部構成を説明する。図２は、BD-ROMにおけるファイル・ディレクトリ構成を示す図である。本図においてBD-ROMには、Rootディレクトリの下に、BDMVディレクトリがある。

＜BD-ROMの概要＞
図２は、BD-ROMの内部構成を示す図である。本図の第４段目にBD-ROMを示し、第３段目にBD-ROM上のトラックを示す。本図のトラックは、BD-ROMの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてBD-ROMの応用層フォーマット(アプリケーションフォーマット)を表現すると、図中の第１段目のようになる。この第1段目においてBD-ROMには、Rootディレクトリの下に、BDMVディレクトリがある。

BDMVディレクトリには、拡張子bdmvが付与されたファイル(index.bdmv,MovieObject.bdmv)がある。そしてこのBDMVディレクトリの配下には、更にPLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ、BDBJディレクトリ、BDJAディレクトリ、AUXDATAディレクトリと呼ばれる6つのサブディレクトリが存在する。
PLAYLISTディレクトリには、拡張子mplsが付与されたファイル(00001.mpls)がある。

CLIPINFディレクトリには、拡張子clpiが付与されたファイル(00001.clpi)がある。
STREAMディレクトリには、拡張子m2tsが付与されたファイル(00001.m2ts)がある。
BDBJディレクトリには、拡張子bobjが付与されたファイル(00001.bobj)が存在する。
BDJAディレクトリには、拡張子jarが付与されたファイル(00001.jar)がある。
以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、BD-ROM上に配置されていることがわかる。

＜BD-ROMの構成その１.AVClip＞
先ず初めに、拡張子.m2tsが付与されたファイルについて説明する。図３は、拡張子.m2tsが付与されたファイルがどのように構成されているかを模式的に示す図である。拡張子.m2tsが付与されたファイル(00001.m2ts)は、AVClipを格納している。AVClipはMPEG2-TransportStream形式のデジタルストリームである。このデジタルストリームは、フィルム映像、NTSC映像、PAL映像をデジタル化することにより得られたデジタルビデオ、デジタルオーディオを(上１段目)、PESパケットからなるエレメンタリストリームに変換し(上２段目)、更にTSパケットに変換して(上３段目)、同じく字幕系のプレゼンテーショングラフィクスストリーム(PresentatiionGraphics(PG)ストリーム)及び対話系のインタラクティブグラフィクスストリーム(Interactive Graphics(IG)ストリーム)を(下１、２段目)を、TSパケットに変換して(下３段目)、これらを多重化することで構成される。

PGストリームとは、動画の再生進行に伴った字幕表示を実現するエレメンタリストリームであり、IGストリームは、動画の再生進行に伴ったGUIを実現するエレメンタリストリームである。
ビデオストリームのうち、1つのPTSで再生される再生単位(ピクチャ等)を、“Video Presentation Unit”という。オーディオストリームのうち、1つのPTSで再生される再生単位を、“AudioPresentation Unit”という。

ここでAVClipを構成するPESパケットは、1つ以上の“STC_Sequence”を構成する。“STC_Sequence”とは、PESパケットの配列であって、そのPTS、DTSが参照しているSystemTime Clock(STC)の値に、STC不連続点(system time-base discontinuity)が存在しないものをいう。STC不連続点がないことがSTC_Sequenceの要件であるので、1つのSTC_Sequenceを構成するPESパケット列のうち、STC不連続点の直後に位置するPESパケットであって、PCR(ProgramClock Reference)を包含したものから、次のSTC不連続点の直前までが1つのSTC_Sequenceになる。

続いて、以上のように構成されたAVClipが、BD-ROMにどのように書き込まれるかを説明する。図４は、AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。本図の第１段目にAVClipを構成するTSパケットを示す。
AVClipを構成する188バイトのTSパケットは、第２段目に示すように4バイトのTS_extra_header(図中のハッチング部)、が付されて、192バイト長のSourceパケットになる。このTS_extra_headerは、Arrival_Time_Stampを含む。

AVClipを構成するSourceパケットは、第3段目におけるAVClipにおいて、1つ以上の“ATC_Sequence”を構成する。“ATC_Sequence”とは、Sourceパケットの配列であって、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、不連続点(noarrival time-base discontinutiy)が存在しないものをいう。いいかえれば、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、連続性が存在するSourceパケット列を“ATC_Sequence”という。

かかるATC_SequenceがAVClipになり、xxxxx.m2tsというファイル名でBD-ROMに記録される。
かかるAVClipは、通常のコンピュータファイル同様、複数のファイルエクステントに分割され、BD-ROM上の領域に記録される。第4段目はAVClipがどのようにBD-ROMに記録されるかを模式的に示す。この第4段目においてファイルを構成する各ファイルエクステントは、予め定められたＳexetent以上のデータ長を有する。

AVClipを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓexetentを検討する。
ここでBD-ROMにおいて光ピックアップのジャンプに要する時間は、
Ｔjump＝Ｔaccess+Ｔoverhead
で与えられる。

Ｔaccessは、ジャンプ距離に応じて与えられる時間(m秒)であり、
ジャンプ距離(論理ブロック数)が0〜5000であるなら179m秒、
ジャンプ距離(論理ブロック数)が5001〜10,000であるなら210m秒、
ジャンプ距離(論理ブロック数)が10,001〜20,000であるなら270m秒、
ジャンプ距離がハーフストロークであるなら990m秒、
ジャンプ距離がフルストロークであるなら1220m秒になる。

BD-ROMから読み出されたTSパケットは、リードバッファと呼ばれるバッファに格納された上、デコーダに出力されるが、リードバッファへの入力が、Rudというビットレートで行われ、ECCブロックにおけるセクタ数をSeccとした場合、
Ｔoverheadは、
Ｔoverhead≦(2×Secc×8)／Rud＝20m秒
という計算で与えられる。

BD-ROMから読み出されたTSパケットは、Sourceパケットの状態でリードバッファに格納された上、TS_Recording_rateという転送レートで、デコーダに供給される。
TS_Recording_rateという転送レートでの、デコーダへのTSパケット供給が跡絶えさせないなめには、Ｔjumpの間、リードバッファからデコーダへのTSパケット出力が継続している必要がある。ここでリードバッファからの出力は、TSパケットではなく、Sourceパケットの状態でなされるので、TSパケットのSourceパケットとのサイズ比を192/188とした場合、Ｔjumpの間、(192/188×TS_Recording_rate)という転送レートにより、リードバッファからのSourceパケット出力が継続している必要がある。

従って、リードバッファが、アンダーフローしないためのバッファ蓄積量は、
Ｂoccupied≧(Tjump/1000×8)×((192/188)×TS_Recording_rate)
となる。
リードバッファへの入力レートはRud、リードバッファからの出力レートはTS_Recording_rate×(192/188)であるので、リードバッファへの蓄積レートは、入力レート−出力レートの計算で与えられ、(Rud−TS_Recording_rate×(192/188))になる。

このＢoccupiedを、リードバッファに蓄積するのに要する時間Txは、
Tx＝Ｂoccupied/(Rud−TS_Recording_rate×(192/188))
になる。
BD-ROMからの読み出しには、この時間TxにおいてRudでのTSパケット入力を継続する必要があるので、AVClipを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓexetentは、
Ｓexetent＝Rud×Tx
＝Rud×Ｂoccupied/(Rud−TS_Recording_rate×(192/188))
≧Rud×(Tjump/1000×8)×((192/188)×TS_Recording_rate)
/(Rud−TS_Recording_rate×(192/188))
≧(Rud×Tjump/1000×8)×
×TS_Recording_rate×192/(Rud×188−TS_Recording_rate×192)
になる。

よって
Ｓexetent≧
(Tjump×Rud/1000×8)×
（TS_Recording_rate×192/(Rud×188−TS_Recording_rate×192))
になる。

AVClipを構成する各ファイルエクステントは、こうして算出されたＳextent以上のデータ長をもつことにより、AVClipを構成する各ファイルエクステントが、BD-ROM上において離散的に位置されたとしても、再生時においてデコーダへのTSパケット供給が途絶えさせることなく、連続的に読み出されることになる。
図５は、BD-ROMの物理単位と、1つのファイルエクステントを構成するSourceパケットとの対応関係を示す図である。第２段目に示すように、BD-ROM上には複数セクタが形成されている。ファイルエクステントを構成するSourceパケットは、第1段目に示すように、32個毎にグループ化されて、連続する3つのセクタに書き込まれる。32個のSourceパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。3個のセクタに収められた32個のSourceパケットを“AlignedUnit”といい、BD-ROMへの書き込みにあたっては、Aligned Unit単位で暗号化がなされる。

第３段目においてセクタは、32個単位で誤り訂正符号が付され、ECCブロックを構成する。読出装置はAligned Unitの単位でBD-ROMをアクセスする限り、32個の完結したSourceパケットを得ることができる。以上がBD-ROMに対するAVClipの書き込みのプロセスである。
＜エレメンタリストリームの種類＞
図６は、AVClipにどのようなエレメンタリストリームが多重化されているかを示す図である。

本図に示すように、AVClipには、0x1011のPIDをもつ高画質ビデオストリーム、0x1100から0x111FまでのPIDをもつPrimaryオーディオストリーム、0x1200から0x121FまでのPIDをもつPGストリーム、0x1400から0x141FまでのPIDをもつIGストリームが多重化されている。これらのエレメンタリストリームを構成するパケットは、それに対応するPIDが付与されており、このPIDを手掛かりにして多重分離されることになる。

＜BD-ROMの構成その２.Clip情報＞
続いて拡張子.clpiが付与されたファイルについて説明する。拡張子.clpiが付与されたファイル(00001.clpi)は、Clip情報を格納している。Clip情報は、個々のAVClipについての管理情報である。図７は、Clip情報の内部構成を示す図である。本図の左側に示すようにClip情報は、
i)AVClipについての情報を格納した『ClipInfo()』、
ii)ATC Sequence,STC Sequenceに関する情報を格納した『Sequence Info()』
iii)Program Sequenceに関する情報を格納した『Program Info()』
iv)『Characteristic Point Info(CPI())』からなる。

Sequence Infoは、AVClipに含まれる、1つ以上のSTC-Sequence、ATC-Sequenceについての情報である。これらの情報を設けておくことの意義は、STC、ATCの不連続点を、予め読出装置に通知するためである。つまりかかる不連続点が存在すると、AVClip内において同じ値のPTS,ATSが出現する可能性があり、再生時に不都合が生じる。STC,ATCが連続しているのは、トランスポートストリームのうち、どこからどこまでであるかを示すため、SequenceInfoは設けられている。

Program Infoとは、Program内容が一定である区間(Program Sequence)を示す情報である。Programとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム同士の集まりである。ProgramInfoを設けておくことの意義は、Program内容の変化点を、予め読出装置に通知するためである。ここでのProgram内容の変化点とは、ビデオストリームのPIDが変化したり、ビデオストリームの種類がSDTVからHDTVに変化している点等をいう。

続いてCharacteristic Point Infoについて説明する。図中の引き出し線cu2は、CPIの構成をクローズアップしている。引き出し線cu2に示すように、CPIは、Ne個のEP_map_for_one_stream_PID(EP_map_for_one_stream_PID(0)〜EP_map_for_one_stream_PID(Ne-1))からなる。これらEP_map_for_one_stream_PIDは、AVClipに属する個々のエレメンタリストリームについてのEP_mapである。EP_mapは、1つのエレメンタリストリーム上において、AccessUnit Delimiterが存在するエントリー位置のパケット番号(SPN_EP_start)を、エントリー時刻(PTS_EP_start)と対応づけて示す情報である。図中の引き出し線cu3は、EP_map_for_one_stream_PIDの内部構成をクローズアップしている。

これによると、EP_map_for_one_stream_PIDは、Nc個のEP_High(EP_High(0)〜EP_High(Nc-1))と、Nf個のEP_Low(EP_Low(0)〜EP_Low(Nf-1))とからなることがわかる。ここでEP_Highは、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPN_EP_start及びPTS_EP_startの上位ビットを表す役割をもち、EP_Lowは、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPN_EP_start及びPTS_EP_startの下位ビットを示す役割をもつ。

図中の引き出し線cu4は、EP_Highの内部構成をクローズアップしている。この引き出し線に示すように、EP_High(i)は、EP_Lowに対する参照値である『ref_to_EP_Low_id[i]』と、AccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの上位ビットを示す『PTS_EP_High[i]』と、Access Unit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの上位ビットを示す『SPN_EP_High[i]』とからなる。ここでiとは、任意のEP_Highを識別するための識別子である。

図中の引き出し線cu5は、EP_Lowの構成をクローズアップしている。引き出し線cu5に示すように、EP_Lowは、対応するAccess UnitがIDRピクチャか否かを示す『is_angle_change_point(EP_Low_id)』と、対応するAccessUnitのサイズを示す『I_end_position_offset(EP_Low_id)』と、対応するAccess Unit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの下位ビットを示す『PTS_EP_Low(EP_Low_id)』と、対応するAccessUnit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの下位ビットを示す『SPN_EP_Low(EP_Low_id)』とからなる。ここでEP_Low_idとは、任意のEP_Lowを識別するための識別子である。

＜Clip情報の説明その２.EP_map＞
以下、具体例を通じて、EP_mapについて説明する。図８は、映画のビデオストリームに対するEP_map設定を示す図である。第1段目は、表示順序に配置された複数のピクチャ(MPEG4-AVCに規定されたIDRピクチャ、Iピクチャ、Bピクチャ、Pピクチャ)を示し、第2段目は、そのピクチャにおける時間軸を示す。第4段目は、BD-ROM上のTSパケット列を示し、第3段目は、EP_mapの設定を示す。

第2段目の時間軸において、時点t1〜t7に、Access UnitとなるIDRピクチャ及びIピクチャが存在するものとする。そしてこれらのt1〜t7の時間間隔が、1秒程度であるとすると、映画に用いられるビデオストリームにおけるEP_mapは、t1〜t7をエントリー時刻(PTS_EP_start)として示し、これに対応づけてエントリー位置(SPN_EP_start)を示すよう、設定される。

＜プレイリスト情報＞
続いて、プレイリスト情報について説明する。拡張子“mpls”が付与されたファイル(00001.mpls)は、PlayList(PL)情報を格納したファイルである。
図９は、プレイリスト情報のデータ構造を示す図であり、本図において、引き出し線mp1に示すようにプレイリスト情報は、MainPathを定義するMainPath情報(MainPath())と、チャプターを定義するPlayListMark情報(PlayListMark())とからなる。

＜プレイリスト情報の説明その１.MainPath情報＞
先ずMainPathについて説明する。MainPathは、主映像たるビデオストリームやオーディオストリームに対して定義される再生経路である。
MainPathは、矢印mp1で示すように複数のPlayItem情報＃1・・・・＃mから定義される。PlayItem情報は、MainPathを構成する1つ以上の論理的な再生区間を定義する。PlayItem情報の構成は、引き出し線hs1によりクローズアップされている。この引き出し線に示すようにPlayItem情報は、再生区間のIN点及びOut点が属するAVClipの再生区間情報のファイル名を示す『Clip_Information_file_name』と、AVClipの符号化方式を示す『Clip_codec_identifier』と、PlayItemがマルチアングルを構成するか否かを示す『is_multi_angle』と、このPlayItemと、その1つ前のPlayItemとの接続を、シームレスに行うか否かを示す『connection_condition』と、このPlayItemが対象としているSTC_Sequenceを一意に示す『ref_to_STC_id[0]』と、再生区間の始点を示す時間情報『In_time』と、再生区間の終点を示す時間情報『Out_time』と、このPlayItemにおいてマスクすべきユーザオペレーションがどれであるかを示す『UO_mask_table』と、このPlayItemの途中へのランダムアクセスを許可するか否かを示す『PlayItem_random_access_flag』と、このPlayItemの再生終了後、最後のピクチャの静止表示を継続するか否かを示す『Still_mode』と、『STN_table』とから構成される。

図１０は、AVClipと、プレイリスト情報との関係を示す図である。第1段目は、プレイリスト情報がもつ時間軸を示す。第2段目から第5段目は、EP_mapにて参照されているビデオストリーム(図８に示したものと同じ)を示す。
プレイリスト情報は、PlayItem情報＃1,＃2という2つのPlayItem情報を含んでおり、これらPlayItem情報＃1,＃2のIn_time,Out_timeにより、2つの再生区間が定義されることになる。これらの再生区間を配列させると、AVClip時間軸とは異なる時間軸が定義されることになる。これが第1段目に示すPlayItem時間軸である。このように、PlayItem情報の定義により、AVClipとは異なる時間軸の定義が可能になる。

以上のClip情報及びプレイリスト情報は、”静的シナリオ”に分類される。何故なら、以上のClip情報及びプレイリスト情報により、静的な再生単位であるプレイリストが定義されるからである。以上で静的シナリオについての説明を終わる。
続いて”動的なシナリオ”について説明する。動的シナリオとは、AVClipの再生制御を動的に規定するシナリオデータである。”動的に”というのは、読出装置における状態変化やユーザからのキーイベントにより再生制御の中身がかわることをいう。BD-ROMでは、この再生制御の動作環境として2つのモードを想定している。1つ目は、DVD読出装置の動作環境と良く似た動作環境であり、コマンドベースの実行環境である。2つ目は、Java(登録商標）仮想マシンの動作環境である。これら2つの動作環境のうち1つ目は、HDMVモードと呼ばれる。2つ目は、BD-Jモードと呼ばれる。これら2つの動作環境があるため、動的シナリオはこのどちらかの動作環境を想定して記述される。HDMVモードを想定した動的シナリオはMovieObjectと呼ばれる。一方BD-Jモードを想定した動的シナリオはBD-J Objectと呼ばれる。

先ず初めにMovie Objectについて説明する。
＜Movie Object＞
Movie Objectは、図２に示したMovieObject.bdmvというファイルに格納され、ナビゲーションコマンド列を含む。
ナビゲーションコマンド列は、条件分岐、読出装置における状態レジスタの設定、状態レジスタの設定値取得等を実現するコマンド列からなる。Movie Objectにおいて記述可能なコマンドを以下に示す。

PlayPLコマンド
書式:PlayPL(第１引数，第２引数)
第１引数は、プレイリストの番号で、再生すべきプレイリストを指定することができる。第２引数は、そのプレイリストに含まれるPlayItemや、そのプレイリストにおける任意の時刻、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に移植するという作業を効率的に行うことができる。MovieObjectについては、以下の国際公開公報に記載された先行技術が存在する。詳細については、本国際公開公報を参照されたい。

国際公開公報W0 2004/074976
以上でMovie Objectについての説明を終える。続いてBD-J Objectについて説明する。
＜BD-J Object＞
BD-J Objectは、Java(登録商標）プログラミング環境で記述された、BD-Jモードの動的シナリオであり、00001〜00003.bobjというファイルに格納される。

図１１は、BD-J Objectの内部構成を示す図である。アプリケーション管理テーブル(AMT)、プレイリスト管理テーブル(PLMT)からなる。MovieObjectとの違いは、BD-J Objectにコマンドが直接記述されていない点である。つまりMovie Objectにおいて制御手順は、ナビゲーションコマンドにより直接記述されていた。これに対しBD-JObjectでは、Java(登録商標）アプリケーションに対する指定をアプリケーション管理テーブルに記載することにより、間接的に制御手順を規定している。このような間接的な規定により、複数動的シナリオにおいて制御手順を共通化するという、制御手順の共通化を効率的に行うことができる。

またMovieObjectにおけるプレイリスト再生は、プレイリスト再生を命じるナビゲーションコマンド(PlayPlコマンド)の記述によりなされるが、BD-JObjectにおけるプレイリスト再生は、プレイリスト再生手順を示すプレイリスト管理テーブルをBD-J Objectに組み込むことで記述が可能になる。
このBD-JモードにおけるJava(登録商標）アプリケーションについて説明する。ここでBD-Jモードが想定しているJava(登録商標）プラットフォームは、Java(登録商標）2Micro_Edition(J2ME)Personal Basis Profile(PBP 1.0)と、Globally Executable MHPspecification(GEM1.0.2)for package media targetsとをフル実装したものである。

このBD-JモードにおけるJava(登録商標）アプリケーションは、xletインターフェイスを通じて、Application Managerにより、制御される。xletインターフェイスは、“loaded”,“paused”、“active”,“destoryed”といった4つの状態をもつ。
上述したJava(登録商標）プラットフォームは、JFIF(JPEG)やPNG,その他のイメージデータを表示するためのスタンダードJava(登録商標）ライブラリを含む。このため、Java(登録商標）アプリケーションは、HDMVモードにおいてIGストリームにより実現されるGUIとは異なるGUIフレームワークを実現することができる。Java(登録商標）アプリケーションにおけるGUIフレームワークは、GEM1.0.2にて規定されたHAViフレームワークを含み、GEM1.0.2におけるリモートコントロールナビゲーション機構を含む。

これにより、Java(登録商標）アプリケーションは、HAViフレームワークに基づくボタン表示、テキスト表示、オンライン表示(BBSの内容)といった表示を、動画像の表示と組み合わせた画面表示を実現することができ、リモートコントロールを用いて、この画面表示に対する操作を行うことができる。
このJava(登録商標）アプリケーションの実体にあたるのが、図２におけるBDMVディレクトリ配下のBDJAディレクトリに格納されたJava(登録商標）アーカイブファイル(00001.jar)である。以降、Java(登録商標）アーカイブファイルについて説明する。

＜Java(登録商標）アーカイブファイル＞
Java(登録商標）アーカイブファイル(図２の00001.jar)は、1つ以上のクラスファイル、1つ以上のデータファイル等を1つにまとめることで得られるファイルであり、BD-Jモードにおいて動作すべきJava(登録商標）アプリケーションを構成する。
図１２は、アーカイブファイルにより収められているプログラム、データを示す図である。本図におけるプログラム、データは、枠内に示すディレクトリ構造が配置された複数ファイルを、java（登録商標）アーカイバでまとめたものである。枠内に示すディレクトリ構造は、Rootディレクトリ、Java(登録商標）1,2,3ディレクトリ、Image1,2,3ディレクトリとからなり、Rootディレクトリにcommon.pkgが、Java(登録商標）1,Java(登録商標）2,Java(登録商標）3ディレクトリにクラスファイル(00001.class〜00007.class)が、Image1,Image2,Image3ディレクトリに、00001.JPEG〜00003.JPEG、00001.PNG〜00003.PNGが配置されている。java（登録商標）アーカイブファイルは、これらをjava（登録商標）アーカイバでまとめることで得られる。かかるクラスファイル及びデータは、BD-ROMからキャッシュに読み出されるにあたって展開され、キャッシュ上で、ディレクトリに配置された複数ファイルとして取り扱われる。Java(登録商標）アーカイブファイルのファイル名における"zzzzz"という5桁の数値は、アプリケーションのID(applicationID)を示す。本Java(登録商標）アーカイブファイルがキャッシュに読み出された際、このファイル名における数値を参照することにより、任意のJava(登録商標）アプリケーションを構成するプログラム，データを取り出すことができる。

尚、本実施形態においてアプリケーションを構成するプログラム、データは、Java(登録商標）アーカイブファイルにまとめられたが、LZHファイル、zipファイルであってもよい。
以上が、BD-Jモードにおける動的シナリオについての説明である。
＜Index.bdmv＞
Index.bdmvは、Titleを構成する、Movie Object又はBD-J Objectを示すテーブルである。Titleとは、MovieObject、又は、BD-JObjectと、これらにより再生されるPLayListとなる再生単位であり、BD-ROMにおいて、1つのコンテンツとして扱われるものである。Index.bdmvは、Titleにおいて、あるTitleの構成要素となるMovieObjectはどれであるか、又は、あるTitleの構成要素となるBD-JObjectはどれであるのかを定義する。

Index.bdmvについては、以下の国際公開公報に詳細が記載されている。詳細については、本公報を参照されたい。
国際公開公報WO 2004/025651 A1公報
以降、図１１に示したアプリケーション管理テーブル、プレイリスト管理テーブルのそれぞれについてより詳しく説明する。

＜アプリケーション管理テーブル＞
アプリケーション管理テーブル(AMT)について説明する。アプリケーション管理テーブル(AMT)とは、上述したGEM1.0.2for packagemedia targetsにおける“アプリケーション シグナリング”を実装するテーブルである。“アプリケーション シグナリング”とは、GEM1.0.2が規定するMHP(MultimedeiHome Platform)において、“サービス”を生存区間としてアプリケーションの起動、実行を行う制御をいう。本実施形態におけるアプリケーション管理テーブルは、この“サービス”の代わりに、BD-ROMにおける“タイトル”を生存区間にして、アプリケーションの起動、実行の制御を実現する。

図１３（ａ）は、アプリケーション管理テーブルの内部構成を示す図である。本図に示すようにアプリケーション管理テーブルは、『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、Suspendといった種別がある。
『run_priority』は、当該生存区間におけるアプリケーションの”起動優先度”が記述される。BD-J Objectでは、これらの情報を用いてアプリケーションの挙動を制御する。
＜生存区間＞
アプリケーション管理テーブルに規定される情報のうち、生存区間について説明する。

生存区間とは、BD-ROM全体の時間軸において、仮想マシンのワークメモリ上でアプリケーションが生存し得る区間を示す。ワークメモリにおける”生存”とは、そのアプリケーションを構成するxletプログラムが、Java(登録商標）仮想マシン内のワークメモリに読み出され、Java(登録商標）仮想マシンによる実行が可能になっている状態をいう。
Java(登録商標）仮想マシンにおいてアプリケーションを動作させる場合、時間軸の何処からアプリケーションによるサービスを開始し、時間軸の何処でアプリケーションによるサービスを終えるかという”サービスの開始点・終了点”を明確に規定することが重要になる。このサービスの開始点・終了点を規定するのが、アプリケーション管理テーブルにおける生存区間である。

一方、DVD-Videoのような読出専用ディスクで供給されるディスクは、トップメニュータイトルを中核とした構造になっている。そのトップメニュータイトルから、個々の著作物へと分岐して再生を行い、その後再び、トップメニュータイトルに戻るという独特の状態遷移をなす。図１４は、ディスクにおける状態遷移を示す図である。本図における四角枠は、Titleである。Titleとは、ディスク特有の状態遷移において、1つの”状態”にあたる再生単位であり、このタイトルが、Java(登録商標）アプリケーションの生存区間として取り扱われる。

Titleには、BD-ROMのローディング時に最初に再生される『FirstPlayTitle』、Top-Menuを構成する『Top_menuTitle』、これら以外の一般的な『Title』がある。また、図中の矢印jh1,2,3,4,5,6,7,8は、Title間の分岐を象徴的に示す。本図に示される状態遷移とは、BD-ROMローディング時に、『FirstPlayTitle』が再生され、『Top_menuTitle』への分岐が発生して、トップメニューに対する選択待ちになるというものである。

トップメニューに対する選択操作がユーザによりなされれば、選択に従って該当Titleの再生を行い、再びTopMenu Titleに戻るとの処理を、BD-ROMのイジェクトがなされるまで延々と繰り返すというのが、ディスク特有の状態遷移である。
それでは、図１４のような状態遷移をなすディスクにおいて、Titleは、どのように生存区間として規定されるのであろうか。BD-ROMのローディングがなされた後、図１４において矢印jh1,2,3,4・・・・・に示された参照符号の数値順に分岐がなされ、BD-ROMがイジェクトされたものとする。そうすると、BD-ROMがローディングされてから、イジェクトされるまでの連続時間帯を一本の時間軸と同視することができる。この時間軸を、ディスク全体の時間軸とする。図１５（ａ）は、ディスク全体の時間軸を示す図であり、図１５（ｂ）は、この時間軸における構成を示す。図１５（ｂ）に示すように、ディスク全体の時間軸は、FirstPlayTitleが再生されている区間、TopMenu Titleが再生されている区間、title＃1〜＃3が再生されている区間等からなる。これらTitleの再生区間はどのように規定されているかというと、Titleは、唯一のBD-JObjectから構成されるから、BD-J Objectが、有効になっている期間をTitleの再生区間と考えることができる。同様に、Titleは、1つ又は複数のHDMVObjectから構成されるから、HDMV Objectが、有効になっている期間をTitleの再生区間と考えることができる。

つまりFirstPlay Title、TopMenu Title、その他のTitleは、何れも動的シナリオから構成されるから、Titleを構成するBD-JObjectのうち、どれかカレントBD-J ObjectとしてActivatedされ、読出装置内において解読・実行に供されている期間を、Titleの再生区間と定義することができる。図１６（ａ）は、BD-ROM全体の時間軸において、識別子bobj_idにより特定されるBD-JObjectから特定されるタイトル再生区間を示す図である。ここで識別子bobj_idにより特定されるBD-J Objectが、1つのTitleを構成しているなら、その識別子bobj_idにより特定されるBD-JObjectが有効になっているBD-ROM時間軸上の一区間を、Titleの再生区間と考えることができる。

ここでBD-J ObjectがActivateされている期間の終期は、Title分岐がなされるまでである。つまり、Title分岐がなされるまで、実行の対象になっている動的シナリオは、カレントBD-JObjectとして扱われるから、そのBD-J ObjectにおいてJumpTitleが発生するまでの1つの区間を、Title区間として扱う。
続いてTitle区間と、PL時間軸との関係について説明する。上述したようにMovieObject、BD-J Objectでは、1つの処理手順としてプレイリスト再生手順を記述することができる。プレイリスト再生手順の記述があれば、上述したPL時間軸の全部又は一部がTitle区間に帰属することになる。図１６（ａ）の一例においてBD-JObjectに、プレイリスト管理テーブルが記述されているとする。この場合、BD-J Objectに対応するTitle区間には、図１６（ｂ）に示すように、PL時間軸が帰属する。このPL時間軸には更に、複数チャプター(Chapter＃1,＃2,＃3)が定義され得るため、BD-ROM上の時間軸には、BD-ROM全体−Title−プレイリスト−チャプターというドメインが存在することになる。これらのドメインを用いて、アプリケーションの生存区間を記述することができる。尚、プレイリスト再生は、アプリケーション実行と同時になされため、プレイリスト再生の途中で、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負荷が高まった時に、どのアプリケーションを強制的に終了させるか、また、どちらのアプリケーションからリソースを奪うかという処理をアプリケーションマネージャが行うにあたっての判断材料になる。この場合、アプリケーションマネージャは、起動優先度が低いアプリケーションの動作を終了し、起動優先度が高いアプリケーションの動作を継続させるとの処理を行う。

また起動優先度は、再生中プレイリストに対する要求が競合した場合のアプリケーション間の調停でも利用される。ここであるアプリケーションが、あるプレイリストの早送りしているものとする。ここで別のアプリケーションが同じプレイリストに対するポーズ要求を行ったとすると、これらのアプリケーションに付与された起動優先度を比較する。そして早送りを命じたアプリケーションの起動優先度が高いなら、かかるアプリケーションによる早送りを継続して行う。逆にポーズを命じたアプリケーションの起動優先度が高いなら、早送り中プレイリストのポーズを行う。

以上の生存区間・起動属性・起動優先度により、仮想マシン上で動作し得るアプリケーションの数を所定数以下に制限するよう規定しておくことがオーサリング時に可能なる。そのため、アプリケーションの安定動作を保証することができる。
＜プレイリスト管理テーブル＞
以上がアプリケーション管理テーブルについての説明である。続いてプレイリスト管理テーブル(PLMT)について説明する。プレイリスト管理テーブルとは、アプリケーションの生存区間において、各アプリケーション実行と同時に行うべき再生制御を示すテーブルである。アプリケーションの動作というのは不安定であり、起動の失敗や異常終了がありうる。そこで起動失敗、異常終了があった場合のFailSafe機構として、本実施形態ではアプリケーションの生存区間毎に、プレイリスト管理テーブルを設けている。プレイリスト管理テーブルは、あるアプリケーションの生存区間が開始した際、これと同時に行うべき再生制御を規定する情報である。この再生制御とは、プレイリスト情報に基づくAVClip再生であり、プレイリスト情報による再生制御を同時に行うことで、アプリケーション実行と、プレイリスト再生とが同時になされることになる。

図２１（ａ）は、プレイリスト管理テーブルの内部構成を示す図である。本図に示すようにプレイリスト管理テーブルは、『PL_id_ref』と、『Playback_Attribute』とからなる。
図２１（ｂ）は、プレイリスト管理テーブルを構成する情報要素の意味内容を示す。
『PL_id_ref』は、プレイリスト識別子に対する”参照値”が記述されることにより、アプリケーションの生存区間において再生可能となるプレイリストがどれであるかを示す。プレイリスト識別子は、ファイルYYYYY.MPLSにおいて、ファイル名として付与された5桁の数値YYYYYで表現される。このYYYYYが記述されることにより、『PL_id_ref』は、対応するTitleにおいて再生可能となるプレイリストがどれであるかを示す。

『Playback_Attribute』は、アプリケーション管理テーブルにおける起動属性に倣った属性であり、『PL_id_ref』に記述されたプレイリストを、タイトル開始時において、どのように再生するかを規定する再生属性である。プレイリストに対する再生属性には、『AutoPlay』、『Present』といった種別がある。
『AutoPlay』とは、対応するタイトルの分岐と同時に、そのプレイリストを再生させる旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、その分岐先タイトルにおいて再生可能であり、かつ再生属性がAutoPlayに設定されたプレイリストの再生を開始する。これにより起動属性がAutoPlayに設定されたプレイリストは、タイトル分岐と共に自動的に起動されることになる。

『Present』とは、起動属性におけるPresent同様、継続属性であり、分岐元titleにおけるプレイリストの状態を継続することを示す。また対応するプレイリストを再生してよいことを示す属性である。例えば連続して再生される2つのTitleがあり、前のタイトル側のプレイリスト管理テーブルでは、あるプレイリストの再生属性がAutoPlayに設定され、カレントタイトル側のプレイリスト管理テーブルでは、そのプレイリストの再生属性がPresentに設定されているものとする。ここでプレイリストの再生時間が2時間長であり、このうち1時間が経過した時点で分岐が発生したとする。この場合カレントタイトルでは、再生属性がPresentに設定されているので、カレントタイトルにおいて、そのプレイリストは、1時間という再生済み区間の直後から、再生されることになる。このように再生属性をPresentに設定しておけば、Title間の分岐があった場合でも、プレイリスト再生をその残りの部分から開始することができる。これにより分岐し合う一連のTitleにおいて、共通のプレイリストを再生するという”タイトル間におけるプレイリスト再生の共通化”を容易に実現することができる。また分岐先タイトルが複数ある場合、これら複数タイトルの再生属性を何れもPresentにしておけば、複数のうちどれに分岐したとしても、1つの共通のプレイリスト再生を継続させることができる。

尚Titleの境界は、シームレス再生を保証しなくてもよいので、上述したように複数Title間で1つのプレイリストを再生しようとする場合、分岐前後でプレイリスト再生を中断させることは許容される。
また、再生属性が「Present」である場合、この再生属性が付与されたプレイリストは、他のアプリケーションからの再生要求により再生されることになる。アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、起動中のアプリケーションから、プレイリストの再生要求があると、要求を受けたプレイリストのPL_id_refが、プレイリスト管理テーブルに記述されていて、再生属性が「AutoPlay」か「Present」のいずれかか否かを判定する。「AutoPlay」か「Present」のいずれかであれば、そのプレイリストを再生する。一方、要求を受けたプレイリストのPL_id_refがプレイリスト管理テーブルに記述されていない場合、そのプレイリストを再生しない。アプリケーションの要求によるプレイリスト再生は、この「AutoPlay」か「Present」のいずれかが付与されたプレイリストに限られることになる。「Present」は、再生属性を明示的に指定しない場合に付与されるデフォルトの再生属性であるから、あるプレイリストの再生属性が無指定「−−」であるとそのプレイリストの再生属性はこのPresentであることを意味する。

図２２は、プレイリスト管理テーブル、アプリケーション管理テーブルにより規定されるタイトルの具体例を示す。図２２の第1段目は、Titleの再生映像を示し、第2段目は、Titleの時間軸を示す。第3段目はPLMTにより再生が規定されるプレイリスト、第4段目は、アプリケーション実行を示す。第4段目においてapplication＃1は、Titleの開始と共に起動されており、その後、時点t1において動作状態になる。一方PlayList＃1は、Titleの開始と共に再生が開始されている。Playlist＃1の再生は、Titleの開始と同じ時点に開始されているので、第1段目の左側に示すように、Titleの再生開始直後から、アプリケーションが動作状態になるまでのスタートアップディレイにおいて、プレイリストの再生画像gj1がフルスクリーン表示される。プレイリスト管理テーブルの再生属性を、”AutoPlay”に設定しておくことにより、Java(登録商標）アプリケーションが動作状態になるまで5〜10秒という時間がかかったとしても、その間、”とりあえず何かが写っている状態”になる。この”とりあえず何かが写っている状態”によりタイトル実行開始時のスタートアップディレイを補うことができる。

一方、application＃1は、時点t1で動作状態になるので、プレイリスト再生画像を子画面、アプリケーションの実行画像を親画面にした合成画像gj2が時点t1において表示されることになる。アプリケーションの実行画像は、Startボタン,continueボタン,POWERインディケータを配置したゲーム用のGUIフレームワークであり、かかるGUIフレームワークの描画処理をJava(登録商標）アプリケーションが実行することでなされる。

こうした、プレイリストの再生映像と、Java(登録商標）アプリケーションのGUIフレームワークとを組み合わせた再生映像をなすタイトルを構成することができるのが、PLMTの特徴である。
図２３は、カレントタイトルがとり得る三態様(プレイリスト管理テーブル無し(i)、プレイリスト管理テーブル有りで尚且つAutoPlay(ii)、プレイリスト管理テーブル有りで尚且つ無指定(iii))と、直前タイトルにおけるプレイリストの状態(非再生状態、再生中状態)とがとりうる6通りの組合せを示す図である。

本図における6通りの組合せのうち、”直前状態＝非再生状態”と、”カレントタイトル＝プレイリスト管理テーブル有り、尚且つ、カレントタイトルの再生属性＝AutoPlay”との組合せにおいて、分岐先タイトルにおけるプレイリストの再生は、自動的に開始することになる。
また”直前状態＝再生中状態”と、”カレントタイトル＝プレイリスト管理テーブル無し”との組合せにおいて、分岐先タイトルでのプレイリストの再生は、自動的に停止することになる。

そしてこれら2つの組合せ以外は全て、前のタイトルの状態を継続することになる。プレイリスト管理テーブルに基づくプレイリスト再生の開始は、分岐元タイトルにおいて非再生状態であり、分岐先タイトルにおいてAutoPlay属性が付与されている場合に限られるので、タイトルの分岐発生する毎に、プレイリスト再生を開始させる必要はない。タイトル間の分岐が多数発生したとしても、プレイリスト再生を開始させる回数を必要最低数にすることができる。

以上が記録媒体についての説明である。続いて本発明に係る読出装置について説明する。
図２４は、本発明に係る読出装置の内部構成を示す図である。本発明に係る読出装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る読出装置は、主としてシステムLSIと、ドライブ装置というパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、読出装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される読出装置は、BD-ROMドライブ１、リードバッファ２、デマルチプレクサ３、ビデオデコーダ４、ビデオプレーン５、バッファ６、オーディオデコーダ７、InteractiveGraphicsデコーダ１１、Interactive Graphicsプレーン１２、Presentation Graphicsデコーダ１３、PresentationGraphicsプレーン１４、JPEGデコーダ１５、Stillプレーン１６、合成部１７、STC生成部１８、ATC生成部１９、ローカルストレージ２０、命令ROM２１、シナリオメモリ２２、PSRセット２３、CPU２４、通信部２５、操作受付部２６から構成される。

BD-ROMドライブ１は、BD-ROMのローディング／イジェクトを行い、BD-ROMに対するアクセスを実行する。
リードバッファ２は、FIFOメモリであり、BD-ROMから読み出されたTSパケットが先入れ先出し式に格納される。
デマルチプレクサ３は、リードバッファ２からSourceパケットを取り出して、このSourceパケットを構成するTSパケットをPESパケットに変換する。そして変換により得られたPESパケットのうち、STN_Tableに記載されたからPIDをもつものをビデオデコーダ４、オーディオデコーダ７、InteractiveGraphicsデコーダ１１、Presentation Graphicsデコーダ１３のどれかに出力する。

ビデオデコーダ４は、デマルチプレクサ３から出力された複数PESパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込む。
ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、読出装置において一画面分の画素データを格納しておくためのメモリ領域である。ビデオプレーン５における解像度は1920×1080であり、このビデオプレーン５に格納されたピクチャデータは、16ビットのYUV値で表現された画素データにより構成される。ビデオプレーン５では、ビデオストリームにおける一フレーム毎の再生映像を、スケーリングすることができる。スケーリングとは、一フレーム毎の再生画像をビデオプレーン５全体の1/4(クオータという)、1/1(フルスケールという)のどちらかに変化させることである。かかるスケーリングを、BD-JモードにおいてCPU２４からの指示に従い実行するので、ビデオストリームの再生画像を、画面の隅に追いやったり、全面的に出すという画面演出が可能になる。

バッファ６は、デマルチプレクサ３から出力された、TSパケットを、先入れ先だし式に格納して、オーディオデコーダ７に供する。
オーディオデコーダ７は、Primaryオーディオストリームに対するデコード処理を行う。
Interactive Graphics(IG)デコーダ１１は、BD-ROM又はローカルストレージ２０から読み出されたIGストリームをデコードして、非圧縮グラフィクスをInteractiveGraphicsプレーン１２に書き込む。

Interactive Graphics(IG)プレーン１２は、HDMVモードにおいてIGデコーダ１１によるデコードで得られた非圧縮グラフィクスが書き込まれる。またBD-Jモードにおいて、アプリケーションにより描画された文字やグラフィクスが書き込まれる。
Presentation Graphics(PG)デコーダ１３は、BD-ROM又はローカルストレージ２０から読み出されたPGストリームをデコードして、非圧縮グラフィクスをPresentationGraphicsプレーン１１に書き込む。PGデコーダ１３によるデコードにより、字幕が画面上に現れることになる。

Presentation Graphics(PG)プレーン１４は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
JPEGデコーダ１５は、BD-ROM又はローカルストレージ２０に記録されているJPEGデータをデコードして、Stillプレーン１６に書き込む。
Stillプレーン１６は、JPEGデータを展開することで得られた非圧縮のグラフィクスデータが格納されるプレーンである。このグラフィクスデータは、Java(登録商標）アプリが描画する、GUIフレームワークのいわゆる“壁紙”として用いられる。

合成部１７は、Interactive Graphicsプレーン１２の格納内容と、Presentation Graphicsプレーン１４の格納内容と、ビデオプレーン５の格納内容と、Stillプレーン１６の格納内容とを合成した合成画像を得る。
STC生成部１８は、System Time Clock(STC)を生成する。そしてSTC_Sequenceの切り換わり時において、それまでのSTC_SequenceにおけるSTC値(STC1)に、STC_deltaと呼ばれるオフセット値を加算することにより、新しいSTC_SequenceのSTC値(STC2)を求めて、それまでのSTC_SequenceにおけるSTC値(STC1)と、新しいSTC_SequenceのSTC_Sequenceにおいて最後に再生されるピクチャの表示開始時刻をPTS1(1stEND)、ピクチャの表示期間をTppとし、後続STC_Sequenceにおいて最初に表示されるピクチャの開始時刻をPTS2(2ndSTART)とした場合、STC_deltaは
STC_delta＝PTS1(1stEND)＋Tpp−PTS2(2ndSTART)
として表現される。以上のようにSTC_deltaを求め、これが足し合わされたクロックの計数値を各デコーダに出力する。これにより各デコーダは、2つのSTC_Sequenceにあたるストリームを途切れなく再生してゆくことができる。以上により、1つのAVClipの中に、2以上のSTC_Sequenceが存在したとしても、また、連続して再生されるべき2以上のAVClipのそれぞれが、異なるSTC_Sequenceをもっていたとしても、これらのSTC_Sequence間のデコード処理を、シームレスに実行することができる。

ATC生成部１９は、Arrival Time Clock(ATC)を生成する。そしてATC_Sequenceの切り換わり時において、それまでのATC_SequenceにおけるATC値(ATC1)に、ATC_deltaと呼ばれるオフセット値を加算することにより、それまでのATC_SequenceにおけるATC値(ATC1)と、新しいATC_SequenceのATC値(ATC2)とを連続した値にする。この加算により、ATC2=ATC1+ATC_deltaになる。ATC_deltaとは、これまで読み出されているトランスポートストリーム(TS1)の最後のTSパケットの入力時点T1から、新たに読み出されたトランスポートストリーム(TS2)の最初のTSパケットの入力時点T2までのオフセット値をいい、“ATC_delta≧N1/TS_recording_rate”という計算式で与えられる。ここで入力時点T2は、TS2の最初のTSパケットの入力時点を、TS1の時間軸上に投影した時点を意味する。またN1は、TS1の最後のビデオPESパケットに後続する、TSパケットのパケット数である。BD-ROMにおいてかかるATC_deltaは、Clip情報に記述されるので、これを用いることにより、ATC_deltaを計算することができる。以上の計算により、これまでのATC_SequenceがもっているATC値(ATC1)と、新たなATC_SequenceがもっているATC値(ATC2)とを、連続した値にすることができる。ATC_deltaが足し合わされたクロックの計数値をデマルチプレクサ(De-MUX)３に出力することで、シームレスなバッファ制御を実現することができる。

また、バッファリングの連続性をみたすには、以下の1),2)を満たせば良い。
1) STC2(2ndSTART)＞STC2(1stEND)をみたすこと、
ここでSTC2(1stEND)は、STC1(1stEND)を、STC2の時間軸に投影した値であり、STC2(1stEND)=STC1(1stEND)-STC_deltaという計算式で与えられる。
2) TS1からのTSパケットの取り出しと、TS2からのTSパケットの取り出しとが、同じ時間軸に投影されたSTC1と、STC2とにより定義され、バッファのアンダーフローや、オーバーフローをもたらさないこと。

ローカルストレージ２０は、webサイトからダウンロードされたコンテンツ等、BD-ROM以外の記録媒体、通信媒体から供給されたコンテンツを、メタデータと共に格納しておくためのハードディスクである。このメタデータは、ダウンロードコンテンツをローカルストレージ２０にバインドして管理するための情報であり、このローカルストレージ２０をアクセスすることで、BD-Jモードにおけるアプリケーションは、ダウンロードコンテンツ長さを利用した様々な処理を行うことができる。

命令ROM２１は、読出装置の制御を規定するソフトウェアを記憶している。
シナリオメモリ２２は、カレントのPL情報やカレントのClip情報を格納しておくためのメモリである。カレントPL情報とは、BD-ROMに記録されている複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントClip情報とは、BD-ROMに記録されている複数Clip情報のうち、現在処理対象になっているものをいう。

PSRセット２３は、読出装置に内蔵されるレジスタであり、64個のPlayer Status/Setting Register(PSR)と、4096個のGeneralPurpose Register（GPR)とからなる。Player Status/Setting Registerの設定値(PSR)のうち、PSR4〜PSR8は、現在の再生時点を表現するのに用いられる。
PSR4は、1〜100の値に設定されることで、現在の再生時点が属するタイトルを示し、0に設定されることで、現在の再生時点がトップメニューであることを示す。

PSR5は、1〜999の値に設定されることで、現在の再生時点が属するチャプター番号を示し、0xFFFFに設定されることで、読出装置においてチャプター番号が無効であることを示す。
PSR6は、0〜999の値に設定されることで、現在の再生時点が属するプレイリスト(カレントPL)の番号を示す。

PSR7は、0〜255の値に設定されることで、現在の再生時点が属するPlayItem(カレントPlay Item)の番号を示す。
PSR8は、0〜OxFFFFFFFFの値に設定されることで、45KHzの時間精度を用いて現在の再生時点(カレントPTM(PresentationTiMe))を示す。以上のPSR4〜PSR8により、図１６（ａ）におけるBD-ROM全体の時間軸において、現在の再生時点はどこであるかを特定することができる。

CPU２４は、命令ROM２１に格納されているソフトウェアを実行して、読出装置全体の制御を実行する。この制御の内容は、操作受付部２６から出力されたユーザイベントを示す情報、及び、PSRセット２３における各PSRの設定値に応じて動的に変化する。
通信部２５は、読出装置における通信機能を実現するものであり、BD-JモードにおいてURL指定がJava(登録商標）アプリケーションから与えられれば、そのURLにあたるwebサイトとのTCPコネクション、FTPコネクション等を確立する。かかるコネクション確立によりwebサイトからのダウンロードをJava(登録商標）アプリケーションに行わせる。

操作受付部２６は、リモコンに対してなされた操作をユーザから受け付け、そうした操作、つまりユーザイベントを示す情報をCPU２４に通知する。
以上が、本実施形態に係る読出装置のハードウェア構成である。続いて本実施形態に係る読出装置のソフトウェア構成について説明する。
図２５は、命令ROM２１に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。本図に示すように、読出装置のレイア構成は、以下のa),b),c)からなる。つまり、
a)BD Player Deviceの第１階層、
b)BD Player Modelの第２階層、
c)Application Runtime Enviromentの第３階層からなる。

これらの階層のうち読出装置のハードウェア構成は、第１階層に属することになる。本図の第１階層”BD Player Device”には、ハードウェア構成のうちビデオデコーダ４、オーディオデコーダ７、IGデコーダ１１、PGデコーダ１３にあたる”デコーダ”と、ビデオプレーン５、IGプレーン１２、PGプレーン１４にあたる”プレーン”、BD-ROM及びそのファイルシステム、ローカルストレージ２０及びそのファイルシステムを含む。

第２階層”BD Player Model”は、以下のb1),b2)の層からなる。つまり、
b1)再生制御エンジン３２の層
b2)Virtual File System３０及び再生エンジン３１の層
からなり、自身より上位の階層に対し、ファンクションAPIを提供する。
第３階層”Application Runtime Enviroment”は、以下のc1),c2)の階層からなる。つまり、
c1)モジュールマネージャ３３が存在する層、
c2)BD-Jプラットフォーム３５が存在する層
からなる。

先ず初めに、第２層及び第３層に属するVirtual File System３０〜HDMVモジュール３４について説明する。
Virtual File System３０は、ローカルストレージ２０に格納されたダウンロードコンテンツを、BD-ROMにおけるディスクコンテンツと一体的に取り扱うための仮想的なファイルシステムである。ここでローカルストレージ２０に格納されたダウンロードコンテンツは、SubClip、Clip情報、プレイリスト情報を含む。このダウンロードコンテンツにおけるプレイリスト情報はBD-ROM及びローカルストレージ２０のどちらに存在するClip情報であっても、指定できる点で、BD-ROM上のプレイリスト情報と異なる。この指定にあたって、VirtualFile System３０上のプレイリスト情報は、BD-ROMやローカルストレージ２０におけるファイルをフルパスで指定する必要はない。BD-ROM上のファイルシステムやローカルストレージ２０上のファイルシステムは、仮想的な1つのファイルシステム(VirtualFile System３０)として、認識されるからである。故に、PlayItem情報は、Virtual File System３０上のAVClip、BD-ROM上のAVClipの何れに対しても、再生区間を指定することができる。VirtualFile System３０を介してローカルストレージ２０の記録内容を読み出し、BD-ROMの記録内容と動的に組み合わせることにより、様々な再生のバリエーションを産み出すことができる。ローカルストレージ２０と、BD-ROMとを組合せてなるディスクコンテンツは、BD-ROMにおけるディスクコンテンツと対等に扱われるので、本願における”BD-ROM”は、ローカルストレージ２０＋BD-ROMの組合せからなる仮想的な記録媒体をも含むことにする。

再生エンジン３１は、AV再生ファンクションを実行する。読出装置のAV再生ファンクションとは、DVDプレーヤ、CDプレーヤから踏襲した伝統的な機能群であり、再生開始(Play)、再生停止(Stop)、一時停止(PauseOn)、一時停止の解除(Pause Off)、Still機能の解除(still off)、速度指定付きの早送り(Forward Play(speed))、速度指定付きの巻戻し(BackwardPlay(speed))、音声切り換え(Audio Change)、副映像切り換え(Subtitle Change)、アングル切り換え(AngleChange)といった機能である。AV再生ファンクションを実現するべく、再生エンジン３１は、リードバッファ２上に読み出されたAVClipのうち、所望に時刻にあたる部分のデコードを行うよう、ビデオデコーダ４、PGデコーダ１３、IGデコーダ１１、オーディオデコーダ７を制御する。所望の時刻としてPSR8(カレントPTM)に示される箇所のデコードを行わせることにより、AVClipにおいて、任意の時点を再生を可能することができる。

再生制御エンジン(Playback Control Engine(PCE))３２は、プレイリストに対する再生制御ファンクション(i)、PSRセット２３における状態取得／設定ファンクション(ii)といった諸機能を実行する。プレイリストに対する再生制御ファンクションとは、再生エンジン３１が行うAV再生ファンクションのうち、再生開始や再生停止を、カレントPL情報及びClip情報に従って行わせることをいう。これら機能(i)〜(ii)は、HDMVモジュール３４〜BD-Jプラットフォーム３５からのファンクションコールに応じて実行する。

モジュールマネージャ３３は、BD-ROMから読み出されたIndex.bdmvを保持して、分岐制御を行う。この分岐制御は、カレントタイトルを構成する動的シナリオにTerminateイベントを発行し、分岐先タイトルを構成する動的シナリオにActivateイベントを発行することでなされる。
HDMVモジュール３４は、HDMVモードの実行主体であり、MovieObjectをメモリに読み出して、このMovie Objectに記述されたナビゲーションコマンドを解読し、解読結果に基づき再生制御エンジン３２に対するファンクションコールを実行する。

以上が再生エンジン３１〜HDMVモジュール３４についての説明である。続いてBD-Jプラットフォーム３５について説明する。
BD-Jプラットフォーム３５は、いわゆるJava(登録商標）プラットフォームであり、Java(登録商標）仮想マシン３６を中核にした構成になっている。BD-Jプラットフォーム３５は、上述したJava(登録商標）2Micro_Edition(J2ME)Personal Basis Profile(PBP 1.0)と、Globally Executable MHPspecification(GEM[1.0.2])for package media targetsに加え、BD-J Extentionを実装している。BD-JExtentionは、GEM[1.0.2]を越えた機能を、BD-Jプラットフォームに与えるために特化された、様々なパッケージを含んでいる。

以降、BD-Jプラットフォーム３５の内部構成について説明する。まず始めに、BD-Jプラットフォーム３５の中核となるJava(登録商標）仮想マシン３６について説明する。
＜Java(登録商標）仮想マシン３６＞
図２６は、Java(登録商標）仮想マシン３６の内部構成を示す図である。本図に示すようにJava(登録商標）仮想マシン３６は、図２４に示したCPU２４と、ユーザクラスローダ５２、メソッドエリア５３、ワークメモリ５４、スレッド５５a,b・・・n、Java(登録商標）スタック５６a,b・・・nとから構成される。

ユーザクラスローダ５２は、BDJAディレクトリのJava(登録商標）アーカイブファイルにおけるクラスファイルをシナリオメモリ２２等から読み出してメソッドエリア５３に格納する。このユーザクラスローダ５２によるクラスファイル読み出しは、ファイルパスを指定した読み出しをアプリケーションマネージャ３７がユーザクラスローダ５２に指示することでなされる。ファイルパスがシナリオメモリ２２を示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するJava(登録商標）アーカイブファイルにおけるクラスファイルを、シナリオメモリ２２からワークメモリ５４に読み出す。ファイルパスがVirtualFile System３０上のディレクトリを示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するJava(登録商標）アーカイブファイルにおけるクラスファイルを、BD-ROM又はローカルストレージ２０からワークメモリ５４に読み出す。アプリケーションの起動制御は、このユーザクラスローダ５２によるクラスファイル読み出しにより実現される。読み出しが指示されたクラスファイルがシナリオメモリ２２にない場合、ユーザクラスローダ５２は読み出し失敗をアプリケーションマネージャ３７に通知することになる。

メソッドエリア５３は、ユーザクラスローダ５２によりシナリオメモリ２２から読み出されたクラスファイルが格納される。
ワークメモリ５４は、いわゆるヒープエリアであり、様々なクラスファイルのインスタンスが格納される。図２５に示したアプリケーションマネージャ３７は、このワークメモリ５４に常駐するレジデントアプリケーションである。ワークメモリ５４には、これらレジデント型のインスタンスの他に、メソッドエリア５３に読み出されたクラスファイルに対応するインスタンスが格納される。このインスタンスが、アプリケーションを構成するxletプログラムである。かかるxletプログラムをワークメモリ５４に配置することによりアプリケーションは実行可能な状態になる。

図２５のレイアモデルでは、このワークメモリ５４上のアプリケーションマネージャ３７を、Java(登録商標）仮想マシン３６上に描いていたが、これはわかり易すさを意図した配慮に過ぎない。アプリケーションマネージャ３７及びアプリケーションはインスタンスとしてスレッド５５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つ積み上げられることになる。

以上がJava(登録商標）仮想マシンについての説明である。
＜アプリケーションマネージャ３７＞
アプリケーションマネージャ３７は、Java(登録商標）仮想マシン３６内のワークメモリ上で動作するシステムソフトウェアであり、タイトル間の分岐が生じた場合、前のタイトルに対応するAMTと、カレントタイトルに対応するAMTとを用いてシグナリングを実行する。このシグナリングは、前のタイトルに対応するAMTには記載されているが、カレントタイトルに対応するAMTには記載されていないアプリケーションの動作を終了させ、前のタイトルに対応するAMTには記載されておらず、カレントタイトルに対応するAMTには記載されているアプリケーションの動作を開始させるという制御である。

図２７は、BD-Jobjectにおけるアプリケーション管理テーブルに基づく、アプリケーションマネージャ３７の処理を示す図である。
図２７における☆1,☆2,☆3は、アプリケーション管理テーブル参照(☆1)、Java(登録商標）仮想マシン３６に対するアプリケーション起動指示(☆2)、Java(登録商標）仮想マシン３６による、Java(登録商標）アーカイブファイルに対する読み出し指示(☆3)、Java(登録商標）アプリケーションを定義するクラスファイルのクラスロード(☆4,5,6)という一連の過程を模式化して示す。この起動指示によりJava(登録商標）仮想マシン３６は、シナリオメモリ２２からワークメモリにxletプログラムを読み出す。

図２８は、BD-JobjectにおけるPLMTに基づく、アプリケーションマネージャ３７の処理を示す図である。▽1は、BD-JobjectにおけるPLMTの参照を示し、▽2は、再生エンジン３１に対するプレイリスト情報の読み出し指示を示す。
図２８における◎1,2,3,4は、Virtual File System３０経由のプレイリスト情報読み出し(◎1)、プレイリスト情報を構成するPlayItem情報の解読(◎2)、VirtualFile System３０経由のClip情報読み出し(◎3)、Clip情報の解読(◎4)を模式化したものである。以上の過程を経てClip情報、プレイリスト情報が解読されれば、AVClipを構成するTSパケットを、VirtualFile System３０を通じて再生エンジン３１に引き渡す。このようにして再生エンジン３１にTSパケットが順次渡れば、再生エンジン３１はAVClipを構成するTSパケットをデコーダに出力して、プレーンに表示させる。図中の☆1,2,3,4は、AVClipを構成するTSパケットの読み出し(☆1,2)、VirtualFile System３０から再生エンジン３１へのTSパケット引き渡し(☆3)、デコーダへのTSパケット投入(☆4)、デコーダから各種プレーンへのデコード結果出力(☆5)を模式的に示している。

以上が、アプリケーションマネージャ３７についての説明である。
＜機能制限部３８＞
機能制限部３８は、J2ME PBP 1.0におけるJSSE optional packageに該当する構成要素であり、アプリケーションに付与すべき機能に制限を与えたり、またその制限を解除する。J2MEPBP 1.0におけるJSSE optional packageは、BD-Jプラットフォームの実装において必須となるパッケージであり、JSSEは、Java(登録商標）2セキュリティモデルを実現する。Java(登録商標）2セキュリティモデルとは、Sigendアプリケーションを認証し、そして認証されたアプリケーションに、コア機能を越えた機能を許可するというものである。コア機能を越えた機能とは、以下のものがある。

・Local Storageの読み書き
・ネットワーク接続の利用
・BD-ROMのアクセス
・BD-ROMにおける他のタイトルの選択
・他のBD-Jプラットフォームの実行制御
これらの機能のPermissionを獲得するには、Permission request fileを利用せねばならない。上述した機能のPermissionは、このPermissionrequest fileから獲得することができる。

またJSSEは、セキュアなコネクションを確立するためのパッケージである、“Java(登録商標） Package for secure connection”を含む。
このパッケージを用いることでBD-Jプラットフォームはインターネットにおけるサーバとの接続を行うことができる。物理的な接続は、Ethernet（登録商標）,電話のそれぞれで違ってもよい。TCP/IPがサポートされ、HTTPプロトコルを使用することができることが接続の条件になる。BD-Jプラットフォームは、ネットワーク接続を利用する前に、認証されねばならず、またネットワーク接続のための適切なPermissionを得なければならない。

Java(登録商標）2セキュリティモデルに準じて、アプリケーションが実行することができる機能に制限を与えたり、この制限を解除したりするのが、機能制限部３８の特徴である。
以上で、BD-Jプラットフォーム３５の内部構成についての説明を終える。
＜ディスクを跨いだアプリケーションシグナリング＞
以上は、1つのBD-ROMのあるタイトルから、別のタイトルに再生が切り替わる場合のアプリケーションシグナリングについての説明である。以降、あるBD-ROMにおけるタイトルから、別のBD-ROMにおけるタイトルへと、再生が切り替わる場合のアプリケーションシグナリングについて説明する。

あるBD-ROM（ディスクA）におけるタイトルから、別のBD-ROM（ディスクA+1）におけるタイトルへと、再生が切り替わるケースとしては、長編の映画作品やシリーズ物の映画作品が、BD-BOXとして、複数のBD-ROMに収録されている場合が挙げられる。これは、映画作品が長編である場合や、映画作品がシリーズ物であるため、映画作品がディスク１枚に収まらない場合を想定している。この場合、1つの映画作品が、複数のBD-ROMにおいて、複数のタイトルとして収録されているので、ディスクの交換作業が必要になる。かかる交換作業では、ディスクAの最後に再生されていたタイトル（LastPlayタイトル）に対応するAMTと、ディスクA+1の最初に再生されるタイトル（FirstPlayタイトル）に対応するAMTとに基づきシグナリングを実行せねばならない。

かかるシグナリングは、新しいディスクのローディング時に、アプリケーションの起動、終了の制御がなされるので、アプリケーションによっては、ディスクの交換前後で、動作するものもでてくる。このように、ディスクの交換前後で動作するアプリケーションを“ディスクアンバウンダリィアプリケーション”という。逆に、ディスクの交換後に、動作を終了するアプリケーションを、“ディスクバウンダリィアプリケーション”という。

前編が終了した際に、ユーザーにディスク交換を促すメッセージを表示し、後編が収められたディスクが挿入されると、すぐに再生を開始できるような処理を行うアプリケーションを、ディスクアンバウンダリィアプリケーションとして規定するのが望ましい。
ここで、新たなディスクのローディング時に、シグナリングを行うのは以下の理由による。

通常、ディスクが抜かれた場合、全てのアプリケーションが終了する方が、ユーザーには理解しやすい。DVD-Videoにおける再生制御は、このように規定されている。かかる再生制御を規定するようなアプリケーションは、通常ディスクに対応付けられるアプリケーションであり、ディスクが抜かれたら、対応するディスクがなくなったとして、アプリケーションは終了させた方がよい。しかし特殊なケースではあるが、長編の映画作品やシリーズ物の映画作品が、BD-BOXとして、複数のBD-ROMに収録されている場合、アプリケーションがディスクの入れ替えを促すよう、処理を行えば、非常に便利である。このような事情により、ディスクアンバウンダリィアプリケーションが導入されている。

図２９は、ディスクバウンダリィアプリケーション、ディスクアンバウンダリィアプリケーションの動作を示す図である。第1段目は、ディスクAのローディング、ディスクAにおけるタイトルの再生、ディスクAのイジェクト、ディスクA+1のローディング、ディスクA+1におけるタイトルの再生といった一連の流れを示す。
第2段目は、ディスクAのLastPlayタイトルが再生されている期間、ディスクが無い期間、ディスクA+1のFirstPlayタイトルが再生されている期間を示す。

第3段目は、LastPlayタイトルの再生内容、ディスク交換を促すメッセージ、FirstPlayタイトルの再生内容を示す。第4段目、第5段目は、ディスクバウンダリィアプリケーション、ディスクアンバウンダリィアプリケーションの生存区間を示す。この第4段目によるとディスクバウンダリィアプリケーションは、ディスクAの装填中に動作を開始する。このディスクバウンダリィアプリケーションの生存区間は、ディスクAが装填されている期間、及びディスクがない期間も継続する。ディスクA+1がローディングされ、FirstPlayタイトルの再生が開始すれば、LastPlayタイトルに対応するAMTと、FirstPlayタイトルに対応するAMTとを照合することによる、シグナリングがなされ、かかる制御により、ディスクバウンダリィアプリケーションの動作は終了する。

一方、図２９の第5段目によるとディスクアンバウンダリィアプリケーションは、ディスクAの装填中に動作を開始する。このディスクアンバウンダリィアプリケーションの生存区間は、ディスクAがローディングされている期間、及びディスクがない期間においても継続する。ディスクA+1がローディングされ、FirstPlayタイトルの再生が開始すれば、LastPlayタイトルに対応するAMTと、FirstPlayタイトルに対応するAMTとを照合することによる、アプリケーションの起動ー終了制御がなされる。かかる制御により、ディスクアンバウンダリィアプリケーションは、その動作を継続する。

図３０（ａ）は、ディスクAにおけるLastPlayタイトルに対応するAMTと、ディスクA+1におけるFirstPlayタイトルに対応するAMTとを示す図であり、図３０（ｂ）は、2つのAMTが、図３０（ａ）のように規定されている場合の、シグナリングを示す図である。
図３０（ａ）において、ディスクAのLastPlayタイトルに対応するAMTには、アプリケーション＃1、アプリケーション＃2のIDが記載されており、ディスクA+1のFirstPlayタイトルに対応するAMTには、アプリケーション＃2のIDが記載されていることがわかる。

図３０（ｂ）の第1段目は、ディスクAのローディング、ディスクAにおけるタイトルの再生、ディスクAのイジェクト、ディスクA+1のローディング、ディスクA+1におけるタイトルの再生といった一連の流れを示す。
第2段目は、ディスクAのLastPlayタイトルが再生されている期間、ディスクが無い期間、ディスクA+1のFirstPlayタイトルが再生されている期間を示す。

第3段目は、LastPlayタイトルの再生内容、ディスク交換を促すメッセージ、FirstPlayタイトルの再生内容を示す。第4段目、第5段目は、アプリケーション＃1、アプリケーション＃2に対する制御を示す。
第4段目においてアプリケーション＃1は、ディスクAにおけるLastPlayタイトルのAMTに記載されているが、ディスクA+1におけるFirstPlayタイトルのAMTには記載されていないので、アプリケーションマネージャ３７は、アプリケーション＃1を終了させる。

第5段目においてアプリケーション＃2は、ディスクAにおけるLastPlayタイトルのAMTに記載されており、ディスクA+1におけるFirstPlayタイトルのAMTには記載されているので、アプリケーションマネージャ３７は終了処理を行わず、そのアプリケーション＃2はそのまま動作を続けることができる。
ディスクAに悪意を持ったアプリケーションが記録され、このアプリケーションが起動されているものとする。悪意のプログラムが実行しているにもかかわらず、ディスクAがイジェクトされ、ディスクA+1がローディングされた場合、その悪意のプログラムにより、ディスクA+1の内容がコピーされるという不測の事態が生じかねない。このような悪意のプログラムの動作を封じるため、アプリケーションマネージャ３７は、ディスクが存在しない期間において、動作を継続しているアプリケーションを、SignedアプリケーションからUnsignedアプリケーションに変化させるよう機能制限部３８に指示する。そして、ディスクA+1ローディング時のシグナリングにおいて、アプリケーションの動作を継続すると判定した際、動作を継続しているアプリケーションを、UnsignedアプリケーションからSignedアプリケーションに変化させる。かかる変化により、たとえディスクAに悪意のプログラムが存在していたとしても、かかる悪意のプログラムの機能は制限されるので、上述したようなディスクA+1の内容がコピーされる心配はなくなる。

また、ディスクA+1のFirstPlayタイトルに対応するAMTに、現在実行されているアプリケーションIDが登録されていない、あるいは間違ったディスクを挿入してしまった場合は、アプリケーションマネージャ３７が現在動作中のアプリケーションを終了させる。この仕組みによって、悪意のプログラムが、ディスクとともに動作する心配がなくなる。
図３１は、アプリケーションマネージャ３７の処理手順を示すフローチャートである。

本フローチャートは、まずステップＳ１〜ステップＳ２のループ処理を実行する。ステップＳ１は、タイトルジャンプが発生したかの判定であり、もしタイトルジャンプがあれば、ステップＳ３においてタイトルの切り替えを行う。
ステップＳ２は、ディスクイジェクトがなされたか否かの判定であり、もしディスクイジェクトがなされれば、動作中のSignedアプリケーションをUnsignedアプリケーションに変更させるよう機能制限部３８に指示して（ステップＳ４）、ディスク交換を促すメッセージを表示した上で（ステップＳ５）、新たなディスクのローディング待ちになる（ステップＳ６）。もしローディングがなされれば、ローディングされたディスクは、予定されていたものであるか否かを判定する（ステップＳ７）。もし、予定されていたものでなければ、ステップＳ８に移行する。

ここで、予定されたディスクがローディングされたかどうかの判定は、以下のような手順でなされる。BD-BOXを構成する各BD-ROMには、「次にローディングすべきディスクの識別子」が記録されている。アプリケーションマネージャ３７は、ディスクAのローディング時において、ディスクAに記録されていた「次にローディングすべきディスクの識別子」を読み取っている。そしてディスクAのイジェクト後、新たなBD-ROMがローディングされれば、そのディスクの識別子を読み取り、この新たなBD-ROMから読み取った識別子が、ディスクAに記録されていた「次にローディングすべきディスクの識別子」と一致するか否かを判定する。もし一致すれば、新たにローディングされたBD-ROMは、BD-BOXを構成する複数のBD-ROMのうち、続編を構成するものであり、「予定されたディスクがローディングされた」と判定結果を下す。

一致しなければ、新たにローディングされたBD-ROMは、BD-BOXにおける続編を構成するものではなく、「予定外のディスクがローディングされた」と判定結果を下す。このような判定手順により、ディスクA+1が正しくローディングされたか、まったく違うディスクがローディングされたかを、区別することができる。
ステップＳ８は、所定のメニューを表示してディスクをまたぐアプリケーションを終了してよいか否かを確認する。図３２（ａ）は、ディスク交換を促すメッセージの表示例であり、図３２（ｂ）は、ステップＳ８で表示されるメニューの一例である。図３２（ａ）のメッセージは、ディスクAの再生が終了した旨と、ディスクAをイジェクトして、ディスクA+1のローディングを促す旨とを含む。図３２（ｂ）のメニューは、「装填されたディスクでは実行できないアプリケーションが起動されています。アプリケーションを終了させてもよろしいでしょうか」とのメッセージと、「続行ボタン」、「ディスク入れ直しボタン」からなる。

かかるメニューを表示するその理由は、以下の通りである。
もしユーザーが間違って、ディスクA+1以外の別のディスクを挿入してしまった場合、そのディスクにおけるFirstPlayタイトルのAMTには、現在動作中のアプリケーションのIDが記述されていないので、別のディスクの再生が始まると同時に、現在動作中のアプリケーションは、終了されてしまう。

そもそも、ディスクアンバウンダリィアプリケーションは、ディスクが入れ替わっても動作していることが期待されている。本来は起動を続けて欲しいアプリケーションであるにもかかわらず、ユーザーが間違ってディスクを入れたことにより終了してしまっては、不便である。そのため、ディスクアンバウンダリィアプリケーションが起動しているにもかかわらず、新たに挿入されたディスクのFirstPlayタイトルにおけるAMTに、ディスクアンバウンダリィアプリケーションが示されていない場合、ユーザーが間違ったディスクを入れた可能性が高いとして、上述したメニューを表示し、現在実行中のディスクアンバウンダリィアプリケーションを終了してよいか確認する。

ステップＳ９は、メニューの続行ボタン、ディスク入れ直しボタンの何れが確定されたかの判定である。ユーザが、ディスクAには関係ない別のディスクの再生を望んでおり、続行ボタンを確定した場合、動作中のUnsignedアプリケーションの動作を終了し（ステップＳ１０）、新たなディスクのFirstPlayタイトルをカレントタイトルにして（ステップＳ１１）、カレントタイトルのAutoPlayプレイリストの再生を先頭から開始する（ステップＳ１２）。

挿入するディスクを間違えており、メニューにおける「ディスクを入れ直す」ボタンを確定した場合、ディスクをイジェクトし（ステップＳ２０）、ステップＳ６に移行する。この際、アプリケーションの終了はなされないので、アプリケーションの動作は継続する。
このように意図していたディスクとは違うディスクがローディングされた場合、タイトルアンバウンダリーアプリケーションが、関連がないディスクと同時に実行されないようにし、また、ディスクを入れなおすか、アプリケーションの動作を継続させるかの選択をユーザーに委ねることにより、ユーザーの混乱を防ぐことができる。

図３３は、予定されていなかったディスクがローディングされた場合におけるアプリケーションマネージャ３７の処理を模式的に示すタイミングチャートである。
本図における第1段目は、ディスクAのイジェクト、ディスクがない期間、予定されていないディスク(ディスクB)のローディングといった一連の流れを示す。
第2段目は、第1段目の流れにおいて、表示されるメッセージ、メニューを示す。ディスクがない期間では、「ディスク交換を促すメッセージ」が表示されているが、予定されていなかったディスクがローディングされれば、メニューを表示する。このメニューは、図３２（ｂ）に示したものである。

第3段目は、第2段目におけるメニューに対して、続行ボタンを確定した場合の処理を示す。この場合、ディスクアンバウンダリィアプリケーションの動作を終了して、新たにローディングされたディスクのFirstPlayタイトルの再生を開始する。
第4段目は、第2段目におけるメニューに対して、ディスク入れ直しボタンを確定した場合の処理を示す。この場合、ディスクアンバウンダリィアプリケーションの動作を終了せず、別のディスクがローディングされるのを待つ。この図３３に示したアプリケーションマネージャ３７の処理を、場合分けして示したのが図３４である。

図３４（ａ）は、予定されていたディスクをローディングした場合における処理を示し、図３４（ｂ）は、予定されていたディスクとは異なるディスクがローディングされ、そのディスクの再生をユーザが希望した場合におけるアプリケーションマネージャ３７の処理を示す。この（ｂ）では、予定されていたディスクとは異なるディスクがローディングされた場合、図３２（ｂ）に示したメニューが表示され、このメニューにおける続行ボタンを確定することにより、そのディスクに記録されたFirstPlayタイトルの再生が開始される。

図３４（ｃ）は、予定されていたディスクとは異なるディスクがローディングされ、そのディスクの再生をユーザが希望しなかった場合におけるアプリケーションマネージャ３７の処理を示す。この（ｃ）では、予定されていたディスクとは異なるディスクがローディングされた場合、図３２（ｂ）に示したメニューが表示され、このメニューにおけるディスク入れ直しボタンを確定することにより、そのディスクがイジェクトされることになる。

図３１における各ステップの処理の説明を再開する。
ローディングされたディスクが予定されていたものなら、ステップＳ７がYesになり、ステップＳ１３に移行する。
ステップＳ１３は、新たなディスクのFirstPlayタイトルをカレントタイトルにして（ステップＳ１３）、前タイトルのAMTに記載されていたが、カレントタイトルのAMTに記載されていない動作中Unsignedアプリケーションxが存在するか否かを判定する（ステップＳ１４）。かかるUnsignedアプリケーションが存在すれば、そのUnsignedアプリケーションxの動作を終了する（ステップＳ１５）。

ステップＳ１６は、前タイトルのAMTに記載されており、カレントタイトルのAMTに記載されている動作中Unsignedアプリケーションyが存在するか否かの判定である。かかるUnsignedアプリケーションyが存在すれば（ステップＳ１６でYes）、そのUnsignedアプリケーションyをSignedアプリケーションに変更するよう機能制限部３８に指示した上（ステップＳ１７）、アプリケーションの動作を継続する（ステップＳ１８）。

その後、ステップＳ１９において、カレントタイトルのAutoPlayプレイリストのうち、警告文など該当する先頭部分をスキップして、AutoPlayプレイリストの再生を開始する。その理由は、以下の通りである。
DVD-Videoなど、光ディスクに記録された映画作品の再生では、ディスクをローディングすると、コピー禁止などの警告文が表示され、その後、他のディスクの予告編などが流れ、メニューに移ることが慣習になっている。メニューで本編の再生を選んではじめて本編の再生が開始されるが、複数のディスクにまたがるコンテンツの場合、ディスクを入れ替えるたびに、このような警告文やメニューなどが表示されていては、コンテンツのつながり感が悪い。だが、これら警告文やメニューに関しては、BD-BOXにおいて、どのディスクから再生されても、必ず再生されるように、ディスクごとに挿入されているのが普通である。

そこで、本実施形態では、ディスクアンバウンダリィアプリケーションの動作が継続している場合において、予定していた通りのディスクA+1がローディングされた場合、“ディスクAからディスクA+1への交換時特有の再生制御”を実行して、警告文などにあたる先頭部分をスキップする。
図３５は、ディスクA+1のFirstPlayタイトルが通常再生される場合と、ディスクA+1のFirstPlayタイトルがスキップ再生される場合とを対比して示す図である。本図における第1段目は、ディスクAのローディング、ディスクAにおけるタイトルの再生、ディスクAのイジェクト、ディスクA+1のローディング、ディスクA+1におけるタイトルの再生といった一連の流れを示す。第2段目は、ディスクA+1のFirstPlayタイトルが通常再生がなされた場合を示し、第3段目は、ディスクA+1のFirstPlayタイトルの先頭部分がスキップされた場合を示す。第2段目、第3段目を比較すると、第2段目では、警告文、他のディスクの予告編が表示された後、本編が表示されているが、第3段目では、これらが表示されず、いきなり本編が開始されていることがわかる。このように、ディスクAを視聴後、ディスクA+1の視聴を継続するような場合、ディスクA+1のFirstPlayタイトルにおける、警告文等は、視聴しないで済むため、テンポよい連続再生を実現することができる。無論、ディスクAを再生せず、ディスクA+1から再生を開始する場合は、上述した警告文は、再生されるので、映画再生時における慣習を守ることができる。

以上が、アプリケーションマネージャ３７についての説明である。
以降図３６のフローチャートを参照して、再生制御エンジン３２による具体的な制御手順を説明する。
図３６は、再生制御エンジン３２によるプレイリスト再生手順を示すフローチャートである。この再生手順は、再生エンジン３１に対する制御(ステップＳ１０６)と、BD-ROMドライブ１又はローカルストレージ２０に対する制御(ステップＳ１０８)とを含む。本フローチャートにおいて処理対象たるPlayItemをPlayItem＃xとする。本フローチャートは、カレントPL情報(.mpls)の読み込みを行い(ステップＳ１０１)、その後、ステップＳ１０２〜ステップＳ１１０の処理を実行するというものである。ここでステップＳ１０２〜ステップＳ１１０は、ステップＳ１０９がYesになるまで、カレントPL情報を構成するそれぞれのPI情報について、ステップＳ１０３〜ステップＳ１１０の処理を繰り返すというループ処理を構成している。このループ処理において処理対象となるPlayItemを、PlayItem＃x(PI＃x)とよぶ。このPlayItem＃xは、ステップＳ１０２において初期化される。上述したループ処理の終了要件は、このPlayItem＃xがカレントプレイリストの最後のPlayItemになることであり(ステップＳ１０９)、もし最後のPlayItemでなければ、カレントプレイリストにおける次の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に変換する(ステップＳ１０５)。ここで、PlayItem＃xのOut_timeに相当するピクチャデータのデコードを行うには、アドレスvに位置するIピクチャだけでは足りず、PlayItem＃xのOut_timeに後続するピクチャデータも必要となる。何故なら、PlayItem＃xのOut_timeに相当するピクチャデータは、未来方向のピクチャデータを参照している可能性があるからである。

上述したように、EP_mapには、Access Unit、つまり、GOPの先頭にあたるIピクチャのアドレスが、Iピクチャの再生時刻と対応付けられて示されている。そのため、PlayItem＃xのOut_timeに相当するピクチャデータが帰属するGOPの終端アドレスは、EP_mapに示されているIピクチャアドレスのうち、Iピクチャアドレスvの次のものを特定して、その1つ手前のIピクチャのアドレス（アドレスwとする）を求めることで定めることができる（ステップＳ１０７）。そうして算出されたアドレスwを用いて、IピクチャアドレスuからアドレスwまでのTSパケットの読み出しをBD-ROMドライブ１又はローカルストレージ２０に命じれば(ステップＳ１０８)。PlayItem＃xのOut_timeに相当するピクチャデータが参照しているような、ピクチャデータは、全てデコーダ内に読み込まれることになる。

その後、PlayItem＃xがカレントプレイリストの最後のPIであるかの判定がなされる(ステップＳ１０９)。
PlayItem＃xがカレントプレイリストの最後のPIでなければ、カレントプレイリストにおける次のPlayItemを、PlayItem＃xに設定して(ステップＳ１１０)、ステップＳ１０３に戻る。以上のステップＳ１０３〜ステップＳ１１０を繰り返することにより、プレイリストを構成するPIは順次再生されることになる。

本フローチャートにおいて、ステップＳ１０２では、カレントのプレイリスト情報において、アプリケーションマネージャ３７から指示されたPlayItemが、PlayItem＃xに設定される。ここで、警告文等にあたるPlayItemではなく、本編の先頭にあたるPlayItemを、アプリケーションマネージャ３７が指示した場合は、かかる警告文等をスキップして、プレイリストの再生は開始されることになる。

以上のように本実施形態によれば、複数のディスクにまたがって、アプリケーションを連続して動作させることが可能になるので、アプリケーションが、ユーザにより選択された音声の言語属性や、字幕の言語属性などを保持している場合、ディスクを交換したとしても、かかる音声の言語属性や、字幕の言語属性など、再度設定する必要がない。これらの属性を再度設定することなく、交換後のディスクを再生することができるので、シリーズ物や長編の映画作品を、好適に再生させることができるという効果がある。

（第２実施形態）
本実施形態は、第１実施形態に示したJava(登録商標）アプリケーションの詳細に関する。具体的にいうと、このJava(登録商標）アプリケーションは、BD-BOXを構成する複数のBD-ROMのうち、２枚目以降のBD-ROM(第１実施形態で述べたディスクA+1)のFirstPlayタイトルを生存区間とすものである。このJava(登録商標）アプリケーションは、FirstPlayタイトルが再生され、起動された時に、“ディスクAからディスクA+1へと交換した場合であるか”、“ディスクAをローディングせず、ディスクA+1をダイレクトにローディングした場合であるか”をアプリケーションマネージャ３７に問い合わせる。そしてこの問い合わせの結果に応じて、再生制御を変化させる。

“ディスクA+1が直接、ローディングされた場合の再生制御”とは、BD-J Objectのプレイリスト記録テーブルに記述された、PlayList情報を構成する複数のPlayItem情報のうち、先頭のものから、再生を開始することである。
“ディスクAからディスクA+1への交換時特有の再生制御”とは、BD-J Objectのプレイリスト記録テーブルに記述されたAutoPlay属性をもつPlayList情報を構成する複数のPlayItem情報のうち、途中のものから、再生を開始すること（いわゆる第１実施形態に示したスキップ再生を実現すること）である。

またディスクAからディスクA+1に交換された場合、FirstPlayタイトルを生存区間とするJava(登録商標）アプリケーションはこのAutoPlay属性をもつPlayList情報とは、異なるPlayList情報を再生してもよい。この異なるPlayList情報が、警告文の再生を省いた再生経路を定義するものなら、第１実施形態で述べたような警告文を、ユーザに視聴させずに済み、複数ディスクの連続再生を快適に実行することができる。

以上のように本実施形態によれば、“ディスクAからディスクA+1へと交換した場合であるか”、“ディスクAをローディングせず、ディスクA+1をダイレクトにローディングした場合であるか”により、異なる処理を行うようなJava(登録商標）アプリケーションを、FirstPlayタイトルを生存区間とするJava(登録商標）アプリケーションとして、BD-BOXにおける複数BD-ROMのうち、1つに記録することにより、BD-BOXにおける複数BD-ROMの連続再生をテンポよくすることができる。

(備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、 以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の意思によることは留意されたい。

(アプリケーションIDの管理)
アプリケーションマネージャ３７が上述したようなディスクを跨いだシグナリングを実行する場合、アプリケーションIDをオーサリングサイトごとに管理して、重ならないようにするなど、ディスクA+1のアプリケーションIDと、悪意のプログラムのアプリケーションIDとが偶然重なってしまわないようにする必要がある。

（連続再生のための補足的な処理）
2つのディスクの連続再生を行うためには、アプリケーション自体を起動させるほかに、属性などを保存しておき、ディスクA+1挿入時に起動するアプリケーションから参照することが望ましい。
（アプリケーション終了時の確認方法）
アプリケーションマネージャ３７は、予定されていない光ディスクがローディングされた場合において、メニューにてアプリケーションの終了を確認したが、そうではなく、ローディングされたディスクの再生を開始してよいか否かを尋ねるなど、別の方法により、アプリケーションの動作を継続するか、終了するかを判断してもよい。

(制御手順の実現)
各実施形態においてフローチャートを引用して説明した制御手順や、機能的な構成要素による制御手順は、ハードウェア資源を用いて具体的に実現されていることから、自然法則を利用した技術的思想の創作といえ、“プログラムの発明”としての成立要件を満たす。

・本発明に係るプログラムの生産形態
本発明に係るプログラムは、コンピュータが実行することができる実行形式のプログラム(オブジェクトプログラム)であり、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVA（登録商標）バイトコードというように、様々な種類がある。またプログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップが実現されることもある。

本発明にかかるプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。

記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。

オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。以上の処理を経て、本発明に係るプログラムを作ることができる。

・本発明に係るプログラムの使用形態
本発明に係るプログラムは、以下のようにして使用することができる。
(i)組込プログラムとしての使用
本発明に係るプログラムを組込プログラムとして使用する場合、プログラムにあたるロードモジュールを、基本入出力プログラム(BIOS)や、様々なミドルウェア(オペレーションシステム)と共に、命令ROMに書き込む。こうした命令ROMを、制御部に組み込み、CPUに実行させることにより、本発明に係るプログラムを、読出装置２００の制御プログラムとして使用することができる。

(ii)アプリケーションとしての使用
読出装置２００が、ハードディスク内蔵モデルである場合は、基本入出力プログラム(BIOS)が命令ROMに組み込まれており、様々なミドルウェア(オペレーションシステム)が、ハードディスクにプレインストールされている。また、ハードディスクから、システムを起動するためのブートROMが、読出装置２００に設けられている。

この場合、ロードモジュールのみを、過搬型の記録媒体やネットワークを通じて、読出装置２００に供給し、1つのアプリケーションとしてハードディスクにインストールする。そうすると、読出装置２００は、ブートROMによるブートストラップを行い、オペレーションシステムを起動した上で、1つのアプリケーションとして、当該アプリケーションをCPUに実行させ、本発明に係るプログラムを使用する。

ハードディスクモデルの読出装置２００では、本発明のプログラムを1つのアプリケーションとして使用しうるので、本発明に係るプログラムを単体で譲渡したり、貸与したり、ネットワークを通じて供給することができる。
(命令ROM２１、CPU２４)
命令ROM２１、CPU２４は、一個のシステムLSIとして実現することができる。

システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる(このようなシステムLSIは、マルチチップモジュールと呼ばれる。)。
ここでパッケージの種別に着目するとシステムLSIには、QFP(クッド フラッド アレイ)、PGA(ピン グリッド アレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。

これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、読出装置２００の中核としての役割を果たす。
システムLSIにパッケージングされるベアチップは、“フロントエンド部”、“バックエンド部”、“デジタル処理部”からなる。“フロントエンド部”は、アナログ信号を、デジタル化する部分であり、“バックエンド部”はデジタル処理の結果、得られたデータを、アナログ化して出力する部分である。

各実施形態において内部構成図として示した各構成要素は、このデジタル処理部内に実装される。
先に“組込プログラムとしての使用”で述べたように、命令ROMには、プログラムにあたるロードモジュールや、基本入出力プログラム(BIOS)、様々なミドルウェア(オペレーションシステム)が書き込まれる。本実施形態において、特に創作したのは、このプログラムにあたるロードモジュールの部分なので、プログラムにあたるロードモジュールを格納した命令ROMを、ベアチップとしてパッケージングすることにより、本発明に係るシステムLSIは生産することができる。

具体的な実装については、SoC実装やSiP実装を用いることができ望ましい。SoC(System on chip)実装とは、1チップ上に複数の回路を焼き付ける技術である。SiP(Systemin Package)実装とは、複数チップを樹脂等で1パッケージにする技術である。以上の過程を経て、本発明に係るシステムLSIは、各実施形態に示した読出装置２００の内部構成図を基に作ることができる。

尚、上述のようにして生成される集積回路は、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。
さらに、各記録読出装置の構成要素の一部又は全てを1つのチップとして構成してもよい。集積回路化は、上述したSoC実装,SiP実装に限るものではなく、専用回路又は汎用プロセスで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA（FieldProgrammable Gate Array）や、LSI内部の回路セルの接続や設定を再構成可能なシリコンフィギュラブル・プロセッサを利用することが考えられる。更には、半導体技術の進歩又は派生する技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積回路化を行っても良い。例えば、バイオ技術の適応などが可能性としてありうる。

本発明に係る読出装置は、上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る読出装置は、産業上の利用可能性を有する。

本発明に係る読出装置の、使用行為についての形態を示す図である。 BD-ROMの内部構成を示す図である。 拡張子.m2tsが付与されたファイルがどのように構成されているかを模式的に示す図である。 AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。 BD-ROMの物理単位と、1つのファイルエクステントを構成するSourceパケットとの対応関係を示す図である。 AVClipにどのようなエレメンタリストリームが多重化されているかを示す図である。 Clip情報の内部構成を示す図である。 映画のビデオストリームに対するEP_map設定を示す図である。 プレイリスト情報のデータ構造を示す図である。 AVClipと、プレイリスト情報との関係を示す図である。 BD-J Objectの内部構成を示す図である。 アーカイブファイルにより収められているプログラム、データを示す図である。 （ａ）アプリケーション管理テーブルの内部構成を示す図である。 （ｂ）アプリケーション管理テーブルを構成する情報要素の意味内容を示す図である。 ディスクにおける状態遷移を示す図である。 （ａ）BD-ROM全体の時間軸を示す図である。 （ｂ）BD-ROM全体の時間軸における構成を示す図である。 （ａ）（ｂ）BD-ROM全体の時間軸において、BD-J Objectから特定されるタイトル再生区間を示す図である。 図１６（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。 本編タイトル、オンラインショッピングタイトル、ゲームタイトルという3つのタイトルを示す図である。 （ａ）（ｂ）アプリケーション管理テーブル、生存区間の一例を示す図である。 起動属性がとり得る三態様(Present、AutoRun、Suspend)と、直前タイトルにおけるアプリケーション状態の三態様(非起動、起動中、Suspend)とがとりうる組合せを示す図である。 （ａ）プレイリスト管理テーブルの内部構成を示す図である。 （ｂ）プレイリスト管理テーブルを構成する情報要素の意味内容を示す図である。 プレイリスト管理テーブル、アプリケーション管理テーブルにより規定されるタイトルの具体例を示す。 カレントタイトルがとり得る三態様(プレイリスト管理テーブル無し、プレイリスト管理テーブル有りで尚且つ無指定、プレイリスト管理テーブル有りで尚且つAutoPlay)と、直前タイトルにおけるPLの状態(非再生状態、再生中状態)とがとりうる6通りの組合せを示す図である。 本発明に係る読出装置の内部構成を示す図である。 ROM２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。 Java(登録商標）仮想マシン３６の内部構成を示す図である。 再生エンジン３１〜モジュールマネージャ３３による処理を模式化した図である。 BD-JobjectにおけるPLMTに基づく、アプリケーションマネージャ３７の処理を示す図である。 ディスクバウンダリィアプリケーション、ディスクアンバウンダリィアプリケーションの動作を示す図である。 （ａ）ディスクAにおけるLastPlayタイトルに対応するAMTと、ディスクA+1におけるFirstPlayタイトルに対応するAMTとを示す図である。 （ｂ）2つのAMTが、図３０（ａ）のように規定されている場合の、シグナリングを示す図である。 アプリケーションマネージャの処理手順を示すフローチャートである。 （ａ）ディスク交換を促すメッセージの表示例である。 （ｂ）図３１のステップＳ８で表示されるメニューの一例である。 予定されていなかったディスクがローディングされた場合におけるアプリケーションマネージャ３７の処理を模式的に示すタイミングチャートである。 （ａ）予定されていたディスクをローディングした場合における処理を示す。 （ｂ）予定されていたディスクとは異なるディスクがローディングされ、そのディスクの再生をユーザが希望した場合におけるアプリケーションマネージャ３７の処理を示す。 （ｃ）予定されていたディスクとは異なるディスクがローディングされ、そのディスクの再生をユーザが希望しなかった場合におけるアプリケーションマネージャ３７の処理を示す。 ディスクA+1のFirstPlayタイトルが通常再生される場合と、ディスクA+1のFirstPlayタイトルがスキップ再生される場合とを対比して示す図である。 再生制御エンジン３２によるプレイリスト再生手順を示すフローチャートである。

１ BD-ROMドライブ
２ リードバッファ
３ デマルチプレクサ
４ ビデオデコーダ
５ ビデオプレーン
７ オーディオデコーダ
１１ Interactive Graphicsデコーダ
１２ Interactive Graphicsプレーン
１３ Presentation Graphicsデコーダ
１４ Presentation Graphicsプレーン
１５ JPEGデコーダ
１６ Stillプレーン
１７ 合成部
１８ STC生成部
１９ ATC生成部
２１ 命令ROM
２２ シナリオメモリ
２３ PSRセット
２４ CPU
２５ 通信部
２６ 操作受付部
３０ Virtual File System
３１ 再生エンジン
３２ 再生制御エンジン
３３ モジュールマネージャ
３４ HDMVモジュール
３５ BD-Jプラットフォーム
３６ Java(登録商標）仮想マシン
３７ アプリケーションマネージャ
３８ 機能制限部

Claims (9)

1. 読出装置であって、
   第１ディスクに記録されたコンテンツを読み取って再生する再生手段と、
   そのコンテンツに対応する管理テーブルに基づき、アプリケーションを実行するアプリケーション管理手段とを備え、
   アプリケーションには、ディスクアンバウンダリのものと、タイトルバウンダリものとがあり、
   前記アプリケーション管理手段は、
   ディスクアンバウンダリアプリケーションについては、第１ディスクから第２ディスクへの交換時において、第１ディスクにおけるコンテンツに対応する管理テーブルに示されており、尚且つ、第２ディスクで最初に再生されるコンテンツに対応する管理テーブルに示されている場合に実行を継続し、タイトルバウンダリアプリケーションについては、第１ディスクにおけるコンテンツの再生終了時に実行を終了する
   ことを特徴とする読出装置。
2. 第１ディスクに再生されていたコンテンツに対応する管理テーブルに示されているが、第２ディスクで最初に再生されるコンテンツに対応する管理テーブルには示されていないアプリケーションが存在する場合、
   前記アプリケーション管理手段は、
   第１ディスク取出し後も、動作しているアプリケーションが存在している旨を表示して、動作中アプリケーションを終了させるか否かをユーザに問い合わせる旨のメニューを表示し、このメニューに対しユーザが肯定的な操作を行うことを条件にして、当該アプリケーションの実行を終了させる
   ことを特徴とする請求項１記載の読出装置。
3. 前記アプリケーション管理手段は、前記問い合わせる旨のメニューを、第２ディスクが装填された後に表示する
   ことを特徴とする請求項２記載の読出装置。
4. 前記読出装置は、第１ディスクが取出された際、実行中のアプリケーションによる機能に制限を付する機能制限手段を備え、
   前記機能制限手段は、
   ある実行中アプリケーションが、第１ディスクにおけるコンテンツに対応する管理テーブルに示されており、尚且つ、第２ディスクで最初に再生されるコンテンツに対応する管理テーブルに示されている場合、そのアプリケーションに課された制限を解除する
   ことを特徴とする請求項１記載の読出装置。
5. 前記コンテンツは、デジタルストリームを含み、
   第２ディスクで最初に再生されるコンテンツに対応するアプリケーションは、第１ディスクが装填されず、第２ディスクが装填された場合と、第１ディスクから第２ディスクへの交換がなされた場合とで、デジタルストリームに対する再生制御を変化させる
   ことを特徴とする請求項１記載の読出装置。
6. 前記再生制御の変化とは、
   第１ディスクが装填されず、第２ディスクが装填された場合に、前記コンテンツを構成するデジタルストリームを先頭から再生し、
   第１ディスクから第２ディスクへのディスク交換がなされた場合に、前記コンテンツを構成するデジタルストリームのうち、先頭部分をスキップして再生することである、請求項５記載の読出装置。
7. デジタルストリームに対する再生制御の変化とは、
   第１ディスクが装填されず、直接第２ディスクが装填された場合に、第１の再生経路情報を用いてデジタルストリームを再生し、
   第１ディスクから第２ディスクへのディスク交換がなされた場合に、第２の再生経路情報を用いてデジタルストリームを再生することである、請求項５記載の読出装置。
8. プログラムであって、
   第１ディスクに記録されたコンテンツを読み取って再生する再生ステップと、
   そのコンテンツに対応する管理テーブルに基づき、アプリケーションを実行するアプリケーション実行ステップとをコンピュータに実行させ、
   アプリケーションには、ディスクアンバウンダリのものと、タイトルバウンダリものとがあり、
   前記アプリケーション管理ステップは、
   ディスクアンバウンダリアプリケーションについては、第１ディスクから第２ディスクへの交換時において、第１ディスクにおけるコンテンツに対応する管理テーブルに示されており、尚且つ、第２ディスクで最初に再生されるコンテンツに対応する管理テーブルに示されている場合に実行を継続し、タイトルバウンダリアプリケーションについては、第１ディスクにおけるコンテンツの再生終了時に実行を終了させる処理をコンピュータに実行させる
   ことを特徴とするプログラム。
9. 読出方法であって、
   第１ディスクに記録されたコンテンツを読み取って再生する再生ステップと、
   そのコンテンツに対応する管理テーブルに基づき、アプリケーションを実行するアプリケーション実行ステップとを有し、
   アプリケーションには、ディスクアンバウンダリのものと、タイトルバウンダリものとがあり、
   前記アプリケーション管理ステップは、
   ディスクアンバウンダリアプリケーションについては、第１ディスクから第２ディスクへの交換時において、第１ディスクにおけるコンテンツに対応する管理テーブルに示されており、尚且つ、第２ディスクで最初に再生されるコンテンツに対応する管理テーブルに示されている場合に実行を継続し、タイトルバウンダリアプリケーションについては、第１ディスクにおけるコンテンツの再生終了時に実行を終了する
   ことを特徴とする読出方法。

Images