WO2005036554A1 - 記録媒体、再生装置、プログラム、再生方法 - Google Patents

Abstract

　BD-ROMには、分岐可能な複数のタイトルと、Javaアプリケーションとが記録されている。Javaアプリケーションは、仮想マシン向けプログラミング言語で記述されたプログラムであり、仮想マシンによる実行が可能となる生存区間が、予め規定されており、前記各タイトルは、アプリケーション管理テーブルを含み、アプリケーション管理テーブルは、タイトルを生存区間とするアプリケーションを、各タイトル毎に示す。

Description

明細書 記録媒体、 再生装置、 プログラム、 再生方法 技術分野

, 本発明は、 デジタル化された映像の再生と、 アプリケーションの実行とを同時に 実行する、 再生制御技術の技術分野に属する発明であり、 本再生制御技術を記録 媒体、 民生用の再生装置、 プログラムに応用する場合の応用技術に深く係る。 ' 背景技術

記録媒体を用いた映画ビジネスには、 デジタル化された映画作品と、 オンライ ンショッピング用のアプリケ一シヨンとを同じ記録媒体に記録して販売するとい う販売戦略がある。映画作品に関連するキャラクタ 'グッズを、オンラインで販売 するような仕組みを一枚の記録媒体に組み込めば、 映画作品と、 アプリケーショ ンとの相乗効果により、キャラクタ'グッズの売り上げを高めることができるので はないかという、 制作者側の目論見がある。 かかるコンテンツを実現するにあた つて、 今後登場する記録媒体及び再生装置には、 より自由度が高いアプリケーシ ョン実行環境の整備が要望されている。

ここでかかるデジタル化された映画作品と、 オンラインショッピング用のアブ リケ一シヨンとの同時実行を実現するには、 デジタル映像の再生に従って、 アブ リケーシヨンを動作させるという技術が必要になる。 デジタルストリームの再生 に従って、 Javaアプリケーションを動作させる技術としては、 DVB-MHP規格 における" シグナリング" が知られている。 シグナリングとは、 デジタルストリ ームの再生時間軸において、 アプリケーションを起動すべき時点、 終了させるベ き時点を定義しておき、 この時点に、 AIT(application Information Table)と呼ば れる情報を送信して、この AITに従った制御を再生装置に行わせるというもので ある。

しかしながらデイスクコンテンッの再生進行は、再生時間軸の逆向がありうる。 逆行とは、 巻戻しにより時間軸を逆向きに進行することである。 アプリケ一ショ ンを起動すべき時点、 終了させるべき時点の前後でこの逆行と、 進行とが何度も なされ、 いったりきたりが繰り返されれば、 ワークメモリへのロード、 廃棄が何 度もなされ、 余分な読出負荷が生じてしまう。

発明の開示

本発明の目的は、 再生時間軸において再生の逆行があつたとしても、 余分な読 出負荷の発生を避けることができる再生装置を提供することである。

上記目的は、 分岐可能な複数のタイトルと、 アプリケーションとが記録された 記録媒体であって、 前記アプリケーションは、 仮想マシン向けプログラミング言 語で記述されたプログラムであり、 仮想マシンによる実行が可能となる生存区間 が、 予め規定されており、 前記各タイトルは、 管理テーブルを含み、 管理テープ ルは、 タイ トルを生存区間とするアプリケーションを、 各タイトル毎に示すこと を特徴とする記録媒体により達成される。 ―

タイ トルは、 時間軸と制御手順とからなり、 タイトルからタイ トルへの分岐は 分岐コマンドで規定されているので、 たとえ一個のタイ トルにおける時間軸内に おいて巻戻しがあつたとしても、 当該分岐コマンドによる分岐がなされる前の、 分岐元タイ トルまで、再生は逆行することはない。 タイトルは、"再生の逆行が有 り得ない単位" であり、 このタイ トルを元に、 アプリケーションの生存区間を規 定すれば、 ワークメモリへの読み込み、 廃棄が何度も繰り返されることはない。 読み込み、 廃棄の繰り返しがなくなるので、 余分な読出負荷の発生を避けること ができる。

図面の簡単な説明

図 1は、 本発明に係る再生装置の使用行為についての形態を示す図である。 図 2は、 BD-ROMにおけるファイル 'ディ レクトリ搆成を示す図である。

図 3は、 AVClip時間軸と、 PL時間軸との関係を示す図である。

図 4は、 4つの Clip— Information— file一 nameによりなされた一括指定を示す図 である。

図 5は、 PLmarkによるチャプター定義を示す図である。

図 6は、 SubPlayltem時間軸上の再生区間定義と、同期指定とを示す図である。 図 7 ( a ) は、 Movieオブジェクトの内部構成を示す図である。

図 7 ( b ) は、 BD-Jオブジェクトの内部構成を示す図である。

図 7 ( c ) は、 Javaアプリケーションの内部構成を示す図である。

図 8 ( a ) は、 Javaアーカイブファイルに収められているプログラム、 データ を示す図である。

図 8 (b) は、 xletプログラムの一例を示す図である。

図 9 (a) は、 トップメニュー、 title#l、 title#2といった一連のタイ トルを示 す図である。

図 9 (b) は、 PlayLis #l、 PlayList#2の時間軸を足し合わせた時間軸を示す 図である。

図 10は、 本編タイトル、 オンラインショッピングタイトル、 ゲームタイ トル という 3つのタイトルを含むディスクコンテンツを示す図である。

図 1 1は、 図 10に示した 3つのタイ トルの再生画像の一例を示す図である。 図 12 (a) は、 図 1 0の破線に示される帰属関係から各アプリケーションの 生存区間をグラフ化した図である。

図 12 (b) は、 図 1 2 (a) の生存区間を規定するため、 記述されたアプリ. ケーション管理テーブルの一例を示す図である。

図 13 (a) は、 起動属性設定の一例を示す図である。

図 13 (b) は、 他のアプリケーションからのアプリケーション呼出があって 初めて起動するアプリケーション (application#2)を示す図である。

図 14 (a) (b) は、 Suspend が有意義となるアプリケーション管理テープ ル、 生存区間の一例を示す図である。

図 15は、 起動属性がとり得る三態様 (Persistent, AutoRun、 Suspend)と、 直前タィトルにおけるアプリケーション状態の三態様 (非起動、起動中、 Suspend) とがとりうる組合せを示す図である。

図 16は、 本発明に係る再生装置の内部構成を示す図である。

図 17 (a) は、 BD-ROMに存在している Javaアーカイブファイルを、 ロー カルメモリ 29上でどのように識別するかを示す図である。

図 17 (b) は、 図 17 (a) の応用を示す図である。

図 18は、 ROM24に格納されたソフトウエアと、ハードウエアとからなる部 分を、 レイァ構成に置き換えて描いた図である。

図 1 9は、 Presentation Engine 31〜モジュールマネージャ 34による処理 を模式化した図である。

図 20は、アプリケーションマネージャ 36による処理を模式化した図である。 図 21は、 ワークメモリ 37—Default Operation Manager 40を示す図であ る。

図 22は、 アプリケーションマネージャ 36による分岐時の制御手順を示す図 である。

図 23は、アプリケーション終了処理の処理手順を示すフローチャートである。 図 24は、 アプリケーション終了の過程を模式的に示した図である。

図 25 (a) は、 PL時間軸上に生存区間を定めたアプリケーション管理テー プルを示す図である。

図 25 (b) は、 図 25 (a) のアプリケーション管理テーブルに基づき、 ァ プリケ一シヨンの生存区間を示した図である。 ' '

図 26 (a) は、 PL時間軸から定まるタイ トル時間軸を示す。

図 26 (b) は、 メインとなるアプリケーションの生存区間から定まる夕イ ト ル時間軸を示す。

図 26 (c) は、 複数アプリケーションの生存区間から定まるタイ トル時間軸 を示す図である。

図 27は、 タイ トル再生時におけるアプリケーションマネージャ 36の処理手 順を示すフローチャートである。

図 28 (a) は、 BD-ROMにより実現されるメニュー階層を示す図である。 図 28 (b) は、 メニュー階層を実現するための MOVIEオブジェクトを示す 図である。

図 29は、 Index Tableと、 Index Tableから各 Movieオブジェクトへの分岐 とを模式化した図である。

図 30 (a) は、 図 29 (b) のように Index Tableが記述された場合におけ る分岐を示す。

図 30 (b) は、 非 AV系タイトルが強制終了した際における分岐を示す図で ある。

図 31は、モジュールマネージャ 34の処理手順を示すフローチャートである。 図 32は、 アプリケーションマネージャ 36によるアプリケーション強制終了 の動作例を示す図である。

図 33は、 Playback Control Engine 32による PL再生手順を示すフローチヤ ートである。

図 34は、 アンダル切換、 SkipBack,SkipNextの受付手順を示すフローチヤ一 トである。

図 35は、 SkipBack,SkipNextAPIがコールされた際の処理手順を示すフロー チャートである。

図 36は、 Presentation Engine 31による処理手順の詳細を示すフローチヤ ートである。

図 37は、 SubPlayltemの再生手順を示すフローチヤ一トである。

図 38は、 第 5実施形態に係るアプリケーションマネージャ 36の処理手順を 示すフローチヤ一トである。 - 図 39は、 データ管理テーブルの一例を示す図である。

図 40は、 BD-Jオブジェクトが想定している実行モデルを示す図である。 図 41 (a) は、 口一カルメモリ 29における Javaアーカイブファイル生存 を示す生存区間を示す図である。

図 41 (b) は、 図 41 (a) での Javaアーカイブファイル生存区間を規定 するため、 記述されたデータ管理テーブルを示す図である。

図 42は、 カルーセル化による Javaアーカイブファイル埋め込みを示す図で ある。

図 43 (a) は、 インターリーブ化による AVClip埋め込みを示す図である。 図 43 (b) は、 読込属性の 3つの類型を示す図である。

図 44 (a) は、 データ管理テーブルの一例を示す図である。

図 44 (b) は、 図 44 (a) のデータ管理テーブルの割り当てによるロー力 ルメモリ 29の格納内容の変遷を示す図である。

図 45 (a) は、 新旧再生装置におけるローカルメモリ 29のメモリ規模を対 比して示す図である。

図 45 (b) は、 読込優先度が設定されたデータ管理テーブルの一例を示す図 である。

図 46は、 アプリケーションマネージャ 36によるプリ口一ド制御の処理手順 を示す図である。

図 47 (a) は、 applicationID が同一であるが、 読込優先度は互いに異なる 複数のアプリケーションを規定するデータ管理テーブルの一例を示す図である。 図 47· (b) は、 図 47 (a) のデータ管理テーブルの割り当てによるロー力 ルメモリ 29の格納内容の変遷を示す図である。

図 48 (a) は、 プリロードされるべきアプリケーション、 ロードされるべき アプリケーションに同一の applicationIDを付与するよう記述されたデータ管理 テーブルの一例を示す図である。

図 48 (b) は、 メモリ規模が小さい再生装置におけるローカルメモリ 29の 格納内容の変遷を示す図である。

図 48 (c) は、 メモリ規模が大きい再生装置におけるローカルメモリ 29の 格納内容の変遷を示す図である。 ―

図 49は、 データ管理テーブルに基づくアプリケーションマネージャ 36によ るロード処理の処理手順を示す図である。

図 50は、 アプリケーシヨン qの生存区間に、 現在の再生時点が到達した場合 のアプリケーションマネージャ 36による処理手順を示す図である。

図 51は、 Java仮想マシン 38によるアプリケーシヨンの読み込みがどのよう にして行われるかを模式化した図である。

図 52 (a) は、 第 7実施形態に係る BD-Jオブジェクトの内部構成を示す図 である。

図 52 (b) は、 プレイリスト管理テーブルの一例を示す図である。

図 52 (c) は、 分岐先タイ トルのプレイリスト管理テ一ブルにおいて、 再生 属性が AutoPlayに設定された PLが存在する場合、 再生装置がどのような処理 を行うかを示す図である。

図 53 (a) は、 再生属性が非自動再生を示すよう設定された場合の非 AV系 タイ トルにおけるタイ トル時間軸を示す図である。

図 53 ( b ) は、 再生属性が AutoPlayに設定された非 AV系タイ トルのタイ トル時間軸を示す図である。

図 53 (c) は、 プレイリスト管理テーブルにおいて再生属性が" AutoPlay" を示すよう設定され、 アプリケーションが強制終了した場合を示す図である。 図 53 (d) は、 プレイリスト管理テーブルにおいて再生属性が" AutoPlay" を示すよう設定され、 メインアプリの起動に失敗したケースを示す図である。 図 5 4は、 第 7実施形態に係るアプリケーションマネージャ 3 6の処理手順を 示すフローチャートである。

図 5 5は、 プレイリスト管理テーブルにおいて" 再生属性 =AutoPlay" に設定 されることにより、 どのような再生が行われるかを模式化した図である。

図 5 6 ( a ) ( b ) は、 アプリケーションの扱いと、 起動属性との関係を示した 図である。

図 5 7は、 第 8実施形態に係る Java仮想マシン 3 8によるアプリケーション の読み込みがどのようにして行われるかを模式化した図である。

図 5 8 ( a ) ( b ) は、 第 9実施形態に係る読込優先度の一例を示す図である。 図 5 9 ( a ) は、 グループ属性が付与されたデータ管理 一ブルを示す図であ る。

図 5 9 ( b ) は、 アプリケーション管理テーブルに基づくローカルメモリ 2 9 に対するアクセスを示す図である。

図 6 0は、 アプリケーション管理テーブルの割当単位のバリエーションを示す 図である。

発明を実施するための最良の形態

(第 1実施形態）

以降、 本発明に係る再生装置の実施形態について説明する。 先ず始めに、 本発 明に係る再生装置の実施行為のうち、 使用行為についての形態を説明する。 図 1 は、 本発明に係る再生装置の、 使用行為に'ついての形態を示す図である。 図 1に おいて、 本発明に係る再生装置は再生装置 2 0 0であり、 テレビ 3 0 0、 リモコ ン 4 0 0と共にホームシアターシステムを形成する。

この BD-ROM 1 0 0は、 再生装置 2 0 0、 リモコン 3 0 0、 テレビ 4 0 0に より形成されるホームシアターシステムに、 映画作品を供給するという用途に供 される。

以上が本発明に係る再生装置の使用形態についての説明である。

続いて本発明に係る再生装置の再生の対象となる、 記録媒体である BD-ROM について説明する。 BD-ROM により、 ホームシアターシステムに供給されるデ イスクコンテンツは、 互いに分岐可能な複数タイトルから構成される。 各タイ ト ルは、 1つ以上のプレイリストと、 このプレイリストを用いた動的な制御手順と からなる。

プレイリストとは、 1 つ以上のデジタルストリームと、 そのデジタルストリー ムにおける再生経路とから構成され、"時間軸" の概念をもつ BD-ROM上のァク セス単位である。以上のプレイリストと、動的な制御手順とを包含しているため、 タイトルはデジタルストリーム特有の時間軸の概念と、 コンピュータプログラム 的な性質とを併せもっている。

図 2は、 BD-ROMにおけるファイル 'ディ レクトリ構成を示す図である。 本図 において BD-ROMには、 Rootディ レクトリの卞に、 BDMVディ レクトリがあ る。

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

PLAYLIST ディ レク ト リ には、 拡張子 mpls が付与されたファイル (O0001.mpls，00002.mpls，00003mpls)がある。

CLIPINF ディ レク ト リ には、 拡張子 clpi が付与されたフ ァ イ ル (O0001.clpi,00002.clpi,00003.clpi)がある。

STREAM ディ レク ト リ には、 拡張子 m2ts が付与されたフ ァ イ ル (00001.m2ts,00002.m2ts,00003.ni2ts)がある。

BDAR デ ィ レク ト リ には、 拡張子 jar が付与されたフ ァ イ ル (00001.]'ar，00002jar，00003;iar)がある。 以上のディ レクトリ構造により、 互いに 異なる種別の複数ファィルが、 BD-ROM上に配置されていることがわかる。

本 図 に お い て 拡 張 子 .m2ts が 付 与 さ れ た フ ァ イ ル

(00001.m2ts,00002.m2ts,00003.m2ts- · · · は、 AVClipを格納している。 AVClip には、 MainCLip、 SubClip といった種別がある。 MainCLip は、 ビデオストリ —ム、 オーディオストリーム、 プレゼンテーショングラフィクスストリーム、 ィ ン夕ラクティブグラフ.ィクスストリームというような複数エレメンタリストリ一 ムを多重化することで得られたデジタルストリームである。 4 015330

SubClipは、 オーディオストリーム、 グラフィクスストリーム、 テキスト字幕 ストリーム等、 1 つのエレメンタリストリームのみにあたるデジタルストリーム である。

拡張子" dpi" が付与されたフアイル (00001.clpi，00002.clpi,00003.clpi- -…) は、 AVClipのそれぞれに 1対 1に対応する管理情報である。管理情報故に、 Clip 情報は、 AVClip におけるストリームの符号化形式、 フレームレート、 ビットレ —ト、 解像度等の情報や、 頭出し位置を示す EP— mapをもっている。

拡 張 子 " mpls " が 付 与 さ れ た フ ァ イ ル

(00001.mpls,00002.mpls,00003.mpls )は、 プレイリスト情報を格納したフ アイルである。 プレイリスト情報は、 AVClip を参照して レイリストを定義す る情報である。 プレイリストは、 MainPath情報、 PLMark情報、 SubPath情報 から構成される。

MainPath情報は、 複数の Hayltem情報からなる。 Playltemとは、 1つ以上 の AVClip時間軸上において、 In— hne,OutJThneを指定することで定義される 再生区間である。 Playltem 情報を複数配置させることで、 複数再生区間からな るプレイリスト（PL)が定義される。 図 3は、 AVClipと、 PLとの関係を示す図で ある。第 1段目は AVClipがもつ時間軸を示し、第 2段目は、 PLがもつ時間軸を 示す。 PL情報は、 Playltem#l,#2，#3という 3つの Playltem情報を含んでおり、 これら Playltem#l,#2，#3の Injime, Out— timeにより、 3つの再生区間が定義さ れることになる。 これらの再生区間を配列させると、 AVClip 時間軸とは異なる 時間軸が定義されることになる。 これが第 2段目に示す PL時間軸である。 この ように、 Playltem情報の定義により、 AVClipとは異なる時間軸の定義が可能に なる。

AVClipに対する指定は、 原則 1つであるが、複数 AVClipに対する一括指定も あ り 得 る 。 こ の一括指定 は 、 Playltem 情報 に お け る 複数の Clip— Information— file— name に よ り な さ れ る 。 図 4 は 、 4 つ の Clip— Information— file_nameによりなされた一括指定を示す図である。本図にお いて第 1段目〜第 4段目は、 4つの AVClip時間軸 (AVClip#l，#2,#3，#4の時間軸） を示し、 第 5 段目は、 PL 時間軸を示す。 Playltem 情報が有する、 4 つの Clip— Information— file— nameにて、 これら 4つの時間軸が指定されている。 こう することで、 Playltemが有する In_time，Out— timeにより、択一的に再生可能な 4つの再生区間が定義されることになる。 これにより、 PL時間軸には、切り換え 可能な複数ァングル映像からなる区間 (いわゆるマルチアングル区間)が定義され ることになる。

PLmark情報は、 PL時間軸のうち、 任意の区間を、 チャプターとして指定す る情報である。 図 5は、 PLmarkによるチャプター定義を示す図である。 本図に おいて第 1段目は、 AVClip時間軸を示し、第 2段目は PL時間軸を示す。 図中の 矢印 pkl,2は、 PLmarkにおける Playltem指定 (ref_to_PlayItem— Id)と、一時点 の指定 (mark— time_stamp)とを示す。 これらの指定により PL時間軸には、 3つ のチャプター (Chapter#l，#2，#3)が定義されることになる。 ·

SubPath情報は、 複数の SubPlayltem情報からなる。 SubPlayltem情報は、 SubClipの時間軸上に In_Time，Out— Timeを指定することで再生区間を定義する。 また SubPlayltera情報は、 SubClip時間軸上の再生区間を、 PL時間軸に同期さ せるという同期指定が可能であり、 この同期指定により、 PL 時間軸と、 SubPlayltem 情報時間軸とは同期して進行することになる。 図 6は、 SubPlayltem時間軸上の再生区間定義と、 同期指定を示す図である。本図におい て第 1段目は、 PL時間軸を示し、 第 2段目は SubPlayltem時間軸を示す。 図中 の SubPlayltem.IN— timeは再生区間の始点を、 SubPlayltem.Out— timeは再生 区間の終点をそれぞれ示す。 これにより SubClip時間軸上にも再生区間が定義さ れていることがわかる。 矢印 Snlにおいて Sync_PlayItem_Idは、 Playltemに 対する同期指定を示し、矢印 Sn2において sync— start— PTS_of_PlayItemは、 PL 時間軸における Playltem上の一時点の指定を示す。

複数 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ォブジヱクトと呼ばれ、 管理情報により定義される。 一方 BD-J モードを想定した動的シナリオは BD-Jォブジェクトと呼ばれる。

先ず初めに Movieォブジェクトについて説明する。 ·

< Movieオブジェクト >

Movie オブジェク トは、" タイ トル" の構成要素であり、 フ ァイル MovieObject.bdmvに格納される。 図 7 ( a ) は、 Movieオブジェクトの内部構 成を示す図である。 Movieォブジヱクトは、 属性情報、 複数のナビゲーシヨンコ マンドからなるコマンド列からなる。

属性情報は、 PL時間軸において、 MenuCallがなされた際、 MenuCall後の再 生再開を意図しているか否かを示す情報 (resume— intention— flag)、 PL時間軸に おいて MenuCallをマスクするかを示す情報 (menu— call— mask)、タイトルサーチ をマスクするかを示す情報 (title_search— flag)からなる。 Movieオブジェクトは、 " 時間軸" +" プログラム的制御" という 2 'つの性質を併せ持つことができるで、 本編再生を実行するもの等、多様な種類のタイ トルがこの Movieォブジヱタトに より記述されることになる。

ナビゲーシヨンコマンド列は、 条件分岐、 再生装置における状態レジスタの設 定、 状態レジスタの設定値取得等を実現するコマンド列からなる。 Movieォブジ ヱクトにおいて記述可能なコマンドを以下に示す。

PlayPLコマンド

書式: PlayPL (第 1引数， 第 2引数）

第 1引数は、プレイリストの番号で、再生すべき PLを指定することができる。 第 2引数は、 その PLに含まれる Playltemや、 その PLにおける任意の時刻、 0

Chapter, Markを用いて再生開始位置を指定することができる。

Playltem により PL 時間軸上の再生開始位置を指定した PlayPL 関数を

PlayPLatPlayItemO、

Chapter により PL 時間軸上の再生開始位置を指定した PlayPL 関数を PlayPLatChapterO,

時刻情報により PL 時間軸上の再生開始位置を指定した PlayPL 関数を PlayPLatSpecified TimeOという。

JMPコマンド

書式： JMP引数 '

JMPコマンドは、現在の動的シナリォを途中で廃棄し (discard),引数たる分岐 先動的シナリオを実行するという分岐である。 JMP命令の形式には、分岐先動的 シナリオを直接指定している直接参照のものと、 分岐先動的シナリオを間接参照 している間接参照のものがある。

Movie ォプジェクトにおけるナピゲ一シヨンコマンドの記述は、 DVD におけ るナビゲ一シヨンコマンドの記述方式と良く似ているので、 DVD 上のディスク コンテンツを、 BD-ROM に移植するという作業を効率的に行うことができる。 Movieオブジェクトについては、 以下の国際公開公報に記載された先行技術が存 在する。 詳細については、 本国際公開公報を参照されたい。 国際公開公報 W02004/074976 以上で Movieオブジェクトについての説明を終える。続いて BD-Jオブジェク トについて説明する。

く BD-Jオブジェクト >

拡張子 BD-Jが付与されたファィル (00001.BD-J,00002.BD-J,00003.BD-J)は、 BD-Jォプジェクトを構成する。 BD-Jォブジェクトは、 Javaプログラミング環 境で記述された、 BD-Jモードの動的シナリオである。 図 7 ( b ) は、 BD-Jォブ ジヱクトの内部構成を示す図である。 本図に示すように BD-Jォブジェクトは、 T JP2004/015330

Movie オブジェクト同様の属性情報、 アプリケーション管理テーブルからなる。 属性情報を有している点で BD-Jォブジ： Lクトは Movieォブジヱタトとほぼ同じ である。 Movieオブジェクトとの違いは、 BD-Jォブジェクドはコマンドが直接 記述されていない点である。つまり Movieォブジヱクトにおいて制御手順は、 ナ ピゲーシヨンコマンドにより直接記述されていた。 これに対し BD-Jオブジェク トでは、 そのタイトルを生存区間としている Javaアプリケーションをアプリケ ーシヨン管理テーブル上に定めることにより、間接的に制御手順を規定している。 このような間接的な規定により、 複数タイ トルにおいて制御手順を共通化すると いう、 制御手順の共通化を効率的に行うことができる。

図 7 ( c ) は、 Javaアプリケーションの内部構成を示す囪である。 本図におい てアプリケーションは、 仮想マシンのヒープ領域 (ワークメモリとも呼ばれる）に ロードされた 1つ以上の xletプログラムからなる。 このワークメモリでは、 1つ 以上のスレツドが動作しており、 ワークメモリに口一ドされた xletプログラム、 及ぴ、 スレッドから、 アプリケーションは構成されることになる。 以上がアプリ ケ一シヨンの構成である。

このアプリケーションの実体にあたるの力 BDMVディ レクトリ配下の BDAR ディ レクトリに格納された Java アーカイブファイル (00001.]'ar，00002.;jar)であ る。 以降、 Javaアーカイブファイルについて説明する。

Javaアーカイブフアイル (00001.jar,00002.jar)は、 Javaアプリケーションを構 成するプログラム、データを格納したアーカイブファイルである。図 8 ( a )は、 アーカイブファイルにより収められているプログラム、 データを示す図である。 本図におけるデータは、 枠内に示すディ レクトリ構造が配置された複数ファイル を、; javaアーカイバでまとめたものである。枠内に示すディ レクトリ構造は、 root ディ レクトリ、 javaディ レクトリ、 imageディ レクトリとからなり、 rootディに common.pk が、 javaティレクトリに aaa.class,bbb.ciass力 imageティ レクト リに、 menu.jpgが配置されている。 ； javaアーカイブファイルは、 これらを; java アーカイバでまとめることで得られる。 かかるデータは、 BD-ROM からキヤッ シュに読み出されるにあたって展開され、 キャッシュ上で、 ディレクトリに配置 された複数ファイルとして取り扱われる。 Javaアーカイブファイルのファイル名 における "xxxxx"という 5桁の数値は、 アプリケーションの ID(applicationlD)を 示す。 本 Javaアーカイブファイルがキャッシュに読み出された際、 このフアイ ル名における数値を参照することにより、 任意の Javaアプリケーションを構成 するプログラム， データを取り出すことができる。

Javaアーカイブファイルにおいて 1つにまとめられるファイルには、 xletプ ログラムがある。

xletプログラムは、 JMF(Java Media Frame Work)インターフェイスを利用す ることができる Javaプログラムである。 xletプログラムは、 キーイベントを受 信する EventListner等、 複数の関数からなり、 JMF等の方式に従って、 受信し たキーィベントに基づく処理を行う。

図 8 ( b )は、 xletプログラムの一例を示す図である。 JMFλ"BD:〃00001.mpls"; は、PLを再生するプレーヤィンスタンスの生成を Java仮想マシンに命じるメソ ッドである。 A.playは、 JMFプレーヤインスタンスに再生を命じるメソッドで ある。 かかる JMFプレーヤインスタンス生成は、 JMFライブラリに基づきなさ れる。 xletプログラムの記述は、 BD-ROMの PLに限らず、 時間軸をもったコン テンッ全般に適用可能な JMFの記述である。このような記述が可能であるので、 Javaプログラミングに長けたソフトハウスに、 BD-Jオブジェクト作成を促すこ とができる。 '

図 8 ( b ) における JumpTItleO;は、 ファンクション APIのコールである。 こ のファンクション APIは、他のタイトルへの分岐 (図中では title#l)を再生装置に 命じるものである。 ここでファンクション APIとは、 BD-ROM再生装置により 供給される APKAppliation Interface)である。 JmnpTitleコマンドの他にも、 フ アンクシヨン APIのコールにより、 BD-ROM再生装置特有の処理を xletプログ ラムに記述することができる。

BD-Jモ一ドにおいて PL再生は、 JMFィンターフェイスにより規定される。 この JMFプレーヤインスタンスは、 PL時間軸を定めるものだから、 タイトル時 間軸は、 この JMFプレ一ャインスタンスをもったタイ トルから定まる。 また

BD-Jモ一ドにおいてタイトルからタイトルへの分岐は JmnpTitleAPIのコー ルにより規定される。 JmnpTitleAPI コールは、 いわばタイトルの終了時点を定 めるものなので、 こうした JMFプレーヤインスタンス、 JumpTitleAPI コ一ル をもったアプリケーションが、 BD-J モードにおいてタイ トルの開始及び終了を 律することになる。かかるアプリケーションを本編再生アプリケ一ションという。 以上が、 BD-Jモードにおける動的シナリオについての説明である。 この BD-J モードにおける動的シナリオにより、 PL再生と、 プログラム的制御とを併せも つたタイ トルが定義されることになる。 尚、 本実施形態においてアプリケ一ショ ンを構成するプログラム、データは、 Javaアーカイブファイルにまとめられたが、 LZHファイル、 zipフアイルであつてもよい。

くタイトル時間軸 >

タイ トルを構成する静的シナリオ、 動的シナリオについて説明を終えたところ で、 これらによりどのような時間軸が定義されるかについて説明する。 タイトル により定義される時間軸は、"タイトル時間軸"と呼ばれる。タイトル時間軸とは、 Movieォブジェクト、 又は、 BD-Jォプジェクトにより再生が命じられる PL に より構成される。 ここで一例を挙げるのは、図 9 ( a )のようなタイ トルである。 このタイ トルは、 トップメニュ一" title#l→title#2→トップメニュー、 トップメ 二ュ一" title#3→トップメニューという一連のタイ トルである。 かかるタイトル のうち、 title#lは PlayList#l、 PlayList#2、 title#2が PlayList#3、 title#3が PlayList#4の再生を命じるものなら、図 9 ( b )のように、 PlayList#l、 PlayList#2 の時間軸を足し合わせた時間軸を、 title#lはもつことになる。同様に title#2は、 PlayLis #3時間軸からなる時間軸を、 title#3は PlayList#4時間軸からなる時間 軸を持つことになる。 これらタイ トル時間軸における PL時間軸ではシームレス 再生が保証されるが、 タイ トル時間軸間ではシームレス再生の保証は必要でなく なる。 Javaアプリケーションを動作させるにあたっては、 Javaアプリケーショ ンを、 仮想マシンのワークメモリ上に存在させてもよい期間 (サービス期間)を、 こうしたタイ トル時間軸上に定義せねばならない。 BD-Jモードにおいて Javaァ プリケーシヨンを動作させるにあたっては、 互いに分岐し合う時間軸上に、 Java アプリケーションのサービス期間を定義せねばならない。 このサービス期間の定 義が、 BD-ROM向けのプログラミングを行うにあたっての留意点になる。

最後に、 index.bdmvに格納された IndexTableについて説明する。 IndexTable は、 タイトル番号と、 Movieオブジェクト、 BD-Jォブジェクトとを対応づける テーブルであり、 動的シナリオから動的シナリオへの分岐の際、 参照される間接 参照用テ一ブルである。 IndexTable は、 複数ラベルのそれぞれに対する Index P T/JP2004/015330 からなる。 各 Indexには、 そのラベルに対応する動的シナリオの識別子が記述さ れている。 こうした IndexTableを参照することで、 Movieオブジェクト、 BD-J オブジェクトの違いを厳密に区別することなく、 分岐を実現することができる。 IndexTableについては、以下の国際公開公報に詳細が記載されている。詳細につ いては、 本公報を参照されたい。 国際公開公報 WO 2004/025651 A1公報 以上が BD-ROMに記録されているファイルについて説明である。

くアプリケーション管理テーブル〉

JMFプレーヤィンスタンス、 JumpTitleAPIコールをもったアプリケーション が、 タイトル時間軸を律することは上述した通りだが、 JMFプレーヤインスタン スゃ JumpTitleAPIのコールをもたないその他のアプリケーションを、 タイ トル 時間軸上で動作させる場合、 時間軸の何処からアプリケーシヨンによるサービス を開始し、 時間軸の何処でアプリケーションによるサービスを終えるかという" サービスの開始点'終了点"を明確に規定することが重要になる。本実施形態では、 アプリケーションによるサービスが開始してから、終了するまでを、"アプリケ一 シヨンの生存" として定義する。 アプリケーションの生存を定義するための情報 は、 BD-J オブジェクトにおけるアプリケーション管理テーブルに存在する。 以 降アプリケーション管理テーブルについてより詳しく説明する。

アプリケーション管理テーブル (AMT)は、 各タイ トルが有しているタイ トル時 間軸において、 仮想マシンのワークメモリ上で生存し得るアプリケーションを示 す情報である。 ワークメモリにおける生存とは、 そのアプリケーションを構成す る xletプログラムが、 ワークメモリに読み出され、仮想マシンによる実行が可能 になっている状態をいう。 図 7 (b ) における破線矢印 atlは、 アプリケーショ ン管理テープルの内部構成をクローズアップして示す。 この内部構成に示すよう に、 アプリケーション管理テーブルは、 『生存区間』 と、 そのタイ トルを生存区間 としているアプリケーションを示す『applicationID』 と、 そのアプリケーション の 『起動属性』 とからなる。

近い将来、 実施されるであろうディスクコンテンツを題材に選んで、 アプリケ P T/JP2004/015330 ーション管理テーブルにおける生存区間記述について、具体例を交えて説明する。 ここで題材にするディスクコンテンツは、 映像本編を構成する本編タイ トル

(title#l)、 オンラインショッピングを構成するオンラインショッピングタイ トル (title#2)、 ゲームアプリケーションを構成するゲームタイ トル (title#3)という、性 格が異なる 3つのタイトルを含むものである。 図 1 0は、 本編タイ トル、 オンラ ィンショッビングタイ トル、 ゲームタイトルという 3つのタイ トルを含むディス クコンテンツを示す図である。 本図における右側には IndexTable を記述してお り、 左側には 3つのタイ トルを記述している。

右側における破線枠は、 各アプリケーションがどのタイ トルに属しているかと いう帰属関係を示す。 3 つのタイ トルのうち title#l —は、 application#l、 application#2, application#3という 3つのアプリケーションからなる。 title#2 は、 application#3、 application#4という 2つのアプリケーション、 title#3は、 application#5を含む。 図 1 1は、 図 1 0に示した 3つのタイ トルの再生画像の 一例を示す図である。 これら 3つのタイ トルの再生画像において、 図 1 1 ( a ) ( b ) の本編タイ トル、 オンラインショッビングタイ トルには、 ショッピング力 一トを模した映像 (カート crl)lが存在するが、 図 1 1 ( c ) のゲームタイトルに は、 カート映像が存在しない。 カート crlは、 本編タイトル、 オンラインショッ ビングタイ トルにおいて共通して表示しておく必要があるので、 カートプロダラ ムたる application#3を、 title#l、 title#2の双方で起動するようにしている。 こ のように複数タイ トルで起動するようなアプリケーションには、 上述したカート アプリの他に、 映画作品に登場するマスコットを模したエージヱントアプリ、 メ ニューコール操作に応じてメ二ュ一表示を行うメニューアプリがある。

図 1 0の破線に示される帰属関係から各アプリケーションの生存区間をグラフ 化すると、 図 1 2 ( a ) のようになる。 本図において横軸は、 タイトル時間軸で あり、 縦軸方向に各アプリケーションの生存区間を配置している。 ここで application#l、 application#2は、 title#lのみに帰属しているので、 これらの生 存区間は、 title#l内に留まっている。 application#4は、 title#2のみに帰属して いるので、 これらの生存区間は、 title#2内に留まっている。 application#5は、 title#3 のみに帰属しているので、 これらの生存区間は、 title#3 内に留まってい る。 application^は、 title#l及ぴ title#2に帰属しているので、 これらの生存区 間は、 title#l— title#2にわたる。 この生存区間に基づき、 アプリケーション管理 テーブルを記述すると、 title#l,#2，#2のアプリケーション管理テーブルは図 1 2 ( b )のようになる。このようにアプリケーション管理テーブルが記述されれば、 title#l の再生開始時において application#l、 application#2、 application#3 を ワークメモリにロードしておく。 そして title#2 の開始時に application#l、 application#2をワークメモリから削除して application#3のみにするという制御 を行う。 これと同様に title#2の再生開始時において application#4をワークメモ リにロードしておき、 title#3の開始時に application#3,#4をワークメモリから削 除するという制御を行いうる。

更に、 title#3の再生中において application#5をワーク^モリにロードしてお き、 title#3の再生終了時に application#5をワークメモリから削除するという制 御を行いうる。

タイ トル間分岐があった場合でも、 分岐元一分岐先において生存しているアブ リケ一シヨンはワークメモリ上に格納しておき、 分岐元にはなく、 分岐先にのみ 存在するアプリケーションをワークメモリに読み込めば良いから、 アプリケーシ ヨンをワークメモリに読み込む回数は必要最低数になる。 このように、 読込回数 を少なくすることにより、 タイトルの境界を意識させないアプリケーション、 つ まりアンバウンダリなアプリケーションを実現することができる。

続いてアプリケーションの起動属性について説明する。 起動属性には、 自動的 な起動を示す 「AutoRun」、 自動起動の対象ではないが、 仮想マシンのワークメ モリに置いて良いことを示す「Persistent」、仮想マシンのワークメモリにはおか れるが、 CPUパワーの割り当ては不可となる 「Suspend」 がある。

「AutoRun」 は、 対応するタイ トルの分岐と同時に、 そのアプリケーションを ワークメモリに読み込み、 且つ実行する旨を示す生存区間である。 あるタイ トル から、別のタイ トルへの分岐があると、 アプリケーション管理を行う管理主体 (ァ プリケーシヨンマネージャ）は、その分岐先タイ トルにおいて生存しており、 かつ 起動属性が AutoRunに設定されたアプリケーションを仮想マシンのワークメモ リに読み込み実行する。 これによりそのアプリケーションは、 タイトル分岐と共 に自動的に起動されることになる。 起動属性を AutoRun に設定しておくアプリ ケーシヨンとしては、 JMFプレーヤインスタンス及び JumpTitleAPI コールを もつようなアプリケーションが挙げられる。 何故なら、 このようなアプリケ一シ ヨンは、 タイ トル時間軸を律する側のアプリケーションであり、 このようなァプ リケーシヨンを自動的に起動にしないと、 タイ トル時間軸の概念が曖昧になって しまうからである。

起動属性 「； Persistent] は、 継続属性であり、 分岐元 titieにおけるアプリケー ションの状態を継続することを示す。 またワークメモリにロードしてよいことを 示す属性である。 起動属性が 「Persistent」 である場合、 この起動属性が付与さ れたアプリケーションは、 他のアプリケーションからの呼び出しが許可されるこ とになる。 アプリケーション管理を行う管理主体 (アプリケーションマネージャ） は、 起動中のアプリケーションから呼出があると、 そのアプリケーションの applicationID が、 アプリケーション管理テーブルに記述されていて、 起動属性 が 「Persistent」 であるか否かを判定する。 「Persistent」 であれば、 そのアプリ ケーシヨンをワークメモリにロードする。 一方、 その呼出先アプリケーションの applicationID がアプリケーション管理テ一ブルに記述されていない場合、 その アプリケーションはワークメモリにロードされない。 アプリケーションによる呼 出は、 この「Persistent」が付与されたアプリケーションに限られることになる。

「Persistent」 は、 起動属性を明示的に指定しない場合に付与されるデフオル トの起動属性であるから、 あるアプリケーションの起動属性が無指定 「一—」 で ある場合、そのアプリケーションの起動属性の起動属性はこの Persistentである ことを意味する。

これらの起動属性が、 図 1 1のアプリケーションにおいてどのように記述され ているかについて説明する。 図 1 3は、 図 1 2の 3つのアプリケーションに対す る起動属性の設定例である。 図 1 2に示した 3 つのアプリケーションのうち application^^ は、 図 1 3 ( b ) に示すように他のアプリケーションからのアブ リケーシヨン呼出があって初めて起動するアプリケーションであるとする。 残り の application#l、 application#3は、 title#lの開始と同時に自動的に起動される アプリケーションであるとする。 この場合、 図 1 3 ( a ) に示すように、 アプリ ケーシ ョ ン管理テ一プルにおける各アプリケーシ ョ ンの起動属性を、 appdcation#l、 appucation#3は 「Autojtiun」、 applicat;ion#2は、 I Pei'sistentJ と設定しておく。 この場合、 application#l、 application#3は、 title#lへの分岐 時において自動的にワークメモリにロードされ、 実行されることになる。 一方 application#2は、 起動属性が Persistentなので、 「application#3は仮想マシン のワークメモリ上にロードしてよいアプリケーション」 であるとの消極的な意味 に解される。 故に、 application#2は、 application#lからの呼出があって初めて 仮想マシンのワークメモリにロードされ、 実行されることになる。 以上の生存区 間-起動属性により、 仮想マシン上で動作し得るアプリケーションの数を 4個以 下に制限し、 総スレッド数を 64個以下に制限することが可能なので、 アプリケ —ションの安定動作を保証することができる。

続いて Suspendについて説明する。

Suspend とは、 リソースは割り付けられているが、 CPljパワーは割り当てら れない状態にアプリケーションが置かれることをいう。かかる Suspendは、例え ばゲームタイトルの実行中に、 サイドバスを経由するという処理の実現に有意義 である。 図 1 4 ( a ) ( b ) は Suspendが有意義となる事例を示す図である。 図 1 4 ( b ) に示すように、 3 つのタイ トル (title#l、 title#2、 title#3)があり、 そ のうち title#l、 title#3はゲームアプリを実行するが、 途中の title#2はサイ ドパ スであり、 映像再生を実現するものである。 サイドパスでは、 映像再生を実現す る必要があるため、 ゲームの実行を中断させることになる。 ゲームアプリでは途 中のスコア等が計数されているため、 リソースの格納値は title#2 の前後で維持 したい。 この場合、 title#2の開始時点でゲームアプリを Suspendし、 title#3の 開始時点で application#2をレジュ一ムするというようにアプリケーション管理 テーブルを記述する。 こうすることで title#2において application#2は、 リソ一 スは割り付けられているので、 リソースの格納値は維持される。 しかし、 CPUパ ヮ一は割り当てられない状態なので仮想マシンにより application#2は実行され ることはない。 これにより、 ゲームタイ トルの実行中に、 サイドパスを実行する という処理が実現される。

図 1 5は、 起動属性がとり得る三態様 (Persistent、 AutoRun, Suspend)と、 直前夕ィトルにおけるアプリケーション状態の三態様 (非起動、起動中、 Suspend) とがとりうる組合せを示す図である。 直前状態が" 非起動" である場合、 起動属 性が" AutoRun"であるなら、分岐先タイトルにおいてそのアプリケーションは、 起動されることになる。 直前状態が" 非起動" であり、 起動属性が" Persistent" " Suspend" である なら、 分岐先タイトルにおいてそのアプリケーションは、 何ももせず、 状態を継 続することになる。

直前状態が" 起動中" である場合、 起動属性が" Persistent" AutoRun" で あるなら、 分岐先タイトルにおいてそのアプリケーションは、 何もせず、 状態を 継続することになる。

起動属性が" Suspend" であるなら、 アプリケーションの状態は Suspendされ ることになる。 直前状態が" Suspend" である場合、 分岐先タイトルの起動属性 が" Suspend" なら Suspendを維持することになる。" Persistent" ." AutoRun" であるなら、 分岐先タイ トルにおいてそのアプリケーションは、 レジュ一ムする ことになる。 アプリケーション管理テーブルにおいて生存区間及び起動属性を定 義することにより、 タイ トル時間軸の進行に沿って、 Javaアプリケーションを動 作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、 様々なアプリケーションを世に送り出すことができる。 以上が記録媒体について の説明である。 続いて本発明に係る再生装置について説明する。

図 1 6は、 本発明に係る再生装置の内部構成を示す図である。 本発明に係る再 生装置は、 本図に示す内部に基づき、 工業的に生産される。 本発明に係る再生装 置は、 主としてシステム LSIと、 ドライブ装置という 2つのパーツからなり、 こ れらのパーツを装置のキャビネット及び基板に実装することで工業的に生産する ことができる。 システム LSIは、 再生装置の機能を果たす様々な処理部を集積し た集積回路である。 こうして生産される再生装置は、 BD-ROM ドライブ 1、 リ ードバッファ 2、 デマルチプレクサ 3、 ビデオデコーダ 4、 ビデオプレーン 5、 P-Graphicsデコーダ 9、 Presentation Graphicsプレーン 1 0、 合成部 1 1、 フ オントゼネレ一タ 1 2、 I-Graphics デコーダ 1 3、 スィッチ 1 4、 Interactive Graphicsプレーン 1 5、 合成部 1 6、 HDD 1 7、 リ一ドパッファ 1 8、 デマル チプレクサ 1 9、 オーディオデコーダ 2 0、 シナリオメモリ 2 1、 CPU 2 2、 キ 一イベント処理部 2 3、 命令 ROM 2 4、 スィッチ 2 5、 01^1で部2 6、 CLUT 部 2 7、 PSRセット 2 8、 口一カルメモリ 2 9から構成される。

BD-ROM ドライブ 1は、 BD-ROM のローデイング Zイジェク トを行い、 BD-ROMに対するアクセスを実行する。 15330 リ一ドバッファ 2は、 FIFOメモリであり、 BD-ROMから読み出された TSノ、。 ケットが先入れ先出し式に格納される。

デマルチプレクサ (De-MUX) 3は、 リードバッファ 2から TS バケツトを取り 出して、 この TSバケツトを構成する TSバケツトを PESパケットに変換する。 そして変換により得られた PESパケットのうち、 CPU 2 2から設定された: PID をもつものをビデオデコーダ 4、オーディォデコーダ 2 0、 P-Graphicsデコーダ 9、 I-Graphicsデコーダ 1 3のどれかに出力する。

ビデオデコーダ 4は、 デマルチプレクサ 3から出力された複数 PES バケツト を復号して非圧縮形式のピクチャを得てビデオプレーン 5に書き込む。

ビデオプレーン 5は、 非圧縮形式のピクチャを格納して くためのプレーンで ある。 プレーンとは、 再生装置において一画面分の画素データを格納しておくた めのメモリ領域である。 再生装置に複数のプレーンを設けておき、 これらプレー ンの格納内容を画素毎に加算して、 映像出力を行えば、 複数の映像内容を合成さ せた上で映像出力を行うことができる。ビデオプレーン 5における解像度は 1920 X 1080であり、 このビデオプレーン 5に格納されたピクチャデータは、 16ビッ トの YUV値で表現された画素データにより構成される。

P-Graphicsデコーダ 9は、 BD_ROM、 HDD 1 7から読み出されたプレゼンテ ーシヨ ングラフィ クスス ト リームをデコー ドして、 非圧縮グラフ ィ クスを Presentation Graphicsプレーン 1 0に書き込む。 グラフィクスストリームのデ コードにより、 字幕が画面上に現れるこどになる。

Presentation Graphicsプレーン 1 0は、 一画面分の領域をもったメモリであ り、 一画面分の非圧縮グラフィクスを格納することができる。 本プレーンにおけ る解像度は 1920 X 1080であり、 Presentation Graphicsプレーン 1 0中の非圧 縮グラフィクスの各画素は 8 ビッ トのィンデックスカラーで表現される。 CLUT(Color Lookup Table)を用いてかかるインデックスカラ一を変換すること により、 Presentation Graphicsプレーン 1 0に格納された非圧縮グラフィクス は、 表示に供される。

合成部 1 1は、 非圧縮状態のピクチャデータ (i)を、 Presentation Graphicsプ レーン 1 0の格納内容と合成する。

フォントゼネレータ 1 2は、 文字フォントを用いて textST ストリームに含ま れるテキストコードをビットマップに展開する。

I-Graphicsデコーダ 1 3は、 BD-ROM又は HDD 1 7から読み出されたィンタ ラクティブグラフイクスストリームをデコードして、 非圧縮グラフィクスを Interactive Graphicsプレーン 1 5に ざ込 。

スィッチ 1 4は、 フォントゼネレータ 1 2が生成したフォント列、 P-Graphics デコーダ 9のデコードにより得られたグラフィ クスの何れかを選択的に Presentation Graphicsプレーン 1 0に書き込むスイッチである。

Interactive Graphicsプレーン 1 5は、 I'Graphicsデコーダ 1 3によるデコー ドで得られた非圧縮グラフィクスが書き込まれる。

合成部 1 6は、 Interactive Graphicsプレーン 1 0の格納内容と、 合成部 8の 出力である合成画像 (非圧縮状態のピクチャデータと、 Presentation Graphicsプ レーン 7の格納内容とを合成したもの）とを合成する。

HDD 1 7は、 ネットワーク等を介してダウンロードされた SubClip、 Clip情 報、 プレイリスト情報が格納される内蔵媒体である。 この HDD 1 7中のプレイ リスト情報は BD-ROM及び HDD 1 7のどちらに存在する Clip情報であつても、 指定できる点で異なる。この指定にあたって、 HDD 1 7上のプレイリスト情報は、 BD-ROM 上のファイルをフルパスで指定する必要はない。 本 HDD 1 7は、 BD-ROMと一体になつて、 仮想的な 1つのドライブ (バーチャルパッケージと呼 ばれる）として、 再生装置により認識されるからである。 故に、 Playltem情報に お け る Clip_Information_file— name 及 ぴ SubPlayltem 情 報 の Clip— Information— file_nameは、 Clip情報の格納したファイルのファイルボディ にあたる 5桁の数値を指定することにより、 HDD 1 7、 BD-ROM上の AVClip を指定することができる。 この HDDの記録内容を読み出し、 BD-ROMの記録内 容と動的に組み合わせることにより、 様々な再生のバリエーションを産み出すこ とができる。

リードバッファ 1 8は、 FIFOメモりであり、 HDD 1 7から読み出された TS パケットが先入れ先出し式に格納される。

デマルチプレクサ (De-MUX) 1 9は、 リ一ドバッファ 1 8から TS パケットを 取り出して、 TSバケツトを PESバケツトに変換する。 そして変換により得られ た PESパケットのうち、 所望の streamPIDをもつものをフォントゼネレ一タ 1 2に出力する。

オーディオデコーダ 2 0は、 デマルチプレクサ 1 9から出力された PES パケ ットを復号して、 非圧縮形式のオーディオデータを出力する。

シナリオメモリ 2 1は、カレントの PL情報や力レントの Clip情報を格納して おくためのメモリである。 カレント PL情報とは、 BD-ROMに記録されている複 数 PL情報のうち、 現在処理対象になっているものをいう。 カレント Clip情報と は、 BD-ROMに記録されている複数 Clip情報のうち、 現在処理対象になつてい るものをいう。

CPU2 2は、 命令 ROM2 4に格納されているソフトゥヱァを実行して、 再生 装置全体の制御を実行する。 - キーイベント処理部 2 3は、 リモコンや再生装置のフロントパネルに対するキ 一操作に応じて、 その操作を行うキーィベントを出力する。

命令 ROM2 4は、 再生装置の制御を規定するソフトウェアを記憶している。 スィッチ 2 5は、 BD-ROM及び HDD 1 7から読み出された各種データを、 リ ードバッファ 2、 リードバッファ 1 8、 シナリオメモリ 2 1、 ローカルメモリ 2 9のどれかに選択的に投入するスィツチである。

CLUT部 2 6は、 ビデオプレーン 5に格納された非圧縮グラフィクスにおける インデックスカラーを、 Y,Cr，Cb値に変換する。

GLUT部 2 7は、 Interactive Graphicsプレーン 1 5に格納された非圧縮ダラ フィクスにおけるインデックスカラーを、 Y，Cr，Cb値に変換する。

PSR セット 2 8は、 再生装置に内蔵されるレジスタであり、 64個の Player Status Register(PSR)と、 4096個の General Purpose Register (GPR)とからな る。 Player Status Registerの設定値 (PSR)のうち、 PSR4〜PSR8は、 現在の再 生時点を表現するのに用いられる。

PSR4は、 1〜： 100の値に設定されることで、現在の再生時点が属するタイ トル を示し、 0 に設定されることで、 現在の再生時点がトップメニューであることを 示す。

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

PSR7 は、 0〜255 の値に設定されることで、 現在の再生時点が属する Play Item (力レント Play Item)の番号を示す。

PSR8は、 0〜OxFFFFFFFFの値に設定されることで、 45KHzの時間精度を 用いて現在の再生時点 (力レント PTM(Presentation TiMe))を示す。以上の PSR4 〜PSR8により、 現在の再生時点が特定されることになる。

ローカルメモリ 2 9は、 BD-ROMからの読み出しは低速である故、 BD-ROM の記録内容を一時的に格納しておくためのキャッシュメモリである。 かかるロー カルメモリ 2 9が存在することにより、 BD-J モードにおけるアプリケーション 実行は、 効率化されることになる。 図 1 7 ( a ) は、 BD-ROM に存在している Javaアーカイブファイルを、口一カルメモリ 2 9上でどのように識別するかを示 す図である。 図 1 7 ( a ) の表は、 左欄に BD-ROM上のファイル名を、 右欄に ローカルメモリ 2 9上のファイル名をそれぞれ示している。 これら右欄、 左欄を 比較すれば、ローカルメモリ 2 9におけるファィルは、ディ レクトリ指定" BDJA" を省いたファィルパスで指定されていることがわかる。

図 1 7 ( b ) は、 図 1 7 ( a ) の応用を示す図である。 本応用例は、 ヘッダ + データという形式で、 ファイルに格納されているデータを格納するというもので ある。 何をヘッダに用いるがというと、 ローカルメモリ 2 9におけるファイルパ スを用いる。 図 1 7 (b ) に示したように、 ローカルメモリ 2 9では BD-ROM におけるファイルパスの一部を省略したものをファイルパスに用いるから、 当該 ファイルパスをヘッダに格納することで、 各データにおける BD-ROM上の所在 を明らかにすることができる。

以上が、 本実施形態に係る再生装置のハードウ ア構成である。 続いて本実施 形態に係る再生装置のソフトウヱァ構成について説明する。

図 1 8は、： OM 2 4に格納されたソフトウエアと、ハードウエアとからなる部 分を、 レイァ構成に置き換えて描いた図である。 本図に示すように、 再生装置の レイァ構成は、 以下の a),b),c)，d-l),d-2)，e)，£>からなる。 つまり、

a)物理的なハードウヱァ階層の上に、

b)AVClipによる再生を制御する Presentation Engine 3 1、 04 015330 c)プレイリスト情報及び Clip情報に基づく再生制御を行う Playback Control Engine 3 2、

という 2つの階層があり、

最上位の階層に

e)タイ トル間の分岐を実行するモジュールマネージャ 3 4がある。

これら HDMVモジュール 3 3、 モジュールマネージャ 3 4の間に、

d-l)Movieオブジェクトの解読'実行主体である HDMVモジュール 3 3と、 d-2)BD-Jオブジェクトの解読'実行を行う BD-Jモジュール 3 5とが同じ階層 に置かれている。

BD-Jモジュール 3 5は、いわゆる Javaプラットフオームであり、 ワークメモ リ 3 7を含む Java仮想マシン 3 8を中核にした構成になっていて、 アプリケー ショ ンマネージャ 3 6、 Event Listner Manager 3 9、 Default Operation Manager 4 0から構成される。 先ず初めに、 Presentation Engine 3 1〜モジュ ールマネージャ 3 4について説明する。 図 1 9は、 Presentation Engine 3 1〜 モジュールマネ一ジャ 3 4による処理を模式化した図である。

Presentation Engine 3 1は、 AV再生機能を実行する。 再生装置の AV再生機 能とは、 DVDプレーヤ、 CDプレーヤから踏襲した伝統的な機能群であり、 再生 開始 (Play)、再生停止 (Stop；)、一時停止 (Pause On)、一時停止の解除 (Pause 0¾)、 Still機能の解除 (still of£)、速度指定付きの早送り (Forward Play(speed))、速度指 定付きの巻戻し (Backward Play(speed))、 音声切り換え (Audio Change), 副映像 切り換え (Subtitle Change).ァンダル切り換え (Angle Change)といつた機能であ る。 AV再生機能を実現するべく、 Presentation Engine 3 1は、 リードバッファ 2上に読み出された AVClipのうち、 所望に時刻にあたる部分のデコードを行う よう、 ビデオデコーダ 4、 P-Graphicsデコーダ 9、 I-Graphics デコーダ 1 3、 オーディオデコーダ 2 0を制御する。 所望の時刻として PSR8(力レント PTM)に 示される箇所のデコードを行わせることにより、 AVClip において、 任意の時点 を再生を可能することができる。 図中の ©1は、 Presentation Engine 3 1による デコード開始を模式化して示す。

再生制御ェンジン (Playback Control Engine(PCE)) 3 2は、 プレイリストの再 生機能 (i)、 再生装置における状態取得/設定機能 (ii)といつた諸機能を実行する。 PLの再生機能とは、 Presentation Engine 3 1が行う AV再生機能のうち、 再生 開始や再生停止を、カレント PL情報及び Clip情報に従って行わせることをいう。 これら機能 (i)〜(ii)は、 HDMVモジュール 3 3〜BD-Jモジュール 3 5からのファ ンクシヨンコールに応じて実行する。 つまり再生制御エンジン 3 2は、 ユーザ操 作による指示、 レイヤモデルにおける上位層からの指示に応じて、 自身の機能を 実行する。 図 1 9において、 ©2,©3が付された矢印は、 Clip情報及びプレイリ スト情報に対する Playback Control Engine 3 2の参照を模式的に示す。

HDMVモジュール 3 3は、 MOVIEモ一ドの実行主体であり、 モジュールマネ ージャ 3 4から分岐先を構成する Movieォブジヱクトが通知されれば、分岐先タ ィ トルを構成する Movieオブジェクトを口一カルメモリ 2 9に読み出して、この Movieオブジェクトに記述されたナピゲ一シヨンコマンドを解読し、 解読結果に 基づき Playback Control Engine 3 2に対するファンクションコールを実行する。 図 1 9において V2,V3，V4が付された矢印は、モジュールマネージャ 3 4からの 分岐先 Movieオブジェクトの通知 (2)、 Movieオブジェクトに記述されたナビゲ ーシヨンコマンドの解読 (3)、 Playback Control Engine 3 2に対するファンクシ ヨンコール (4)を、 模式的に示している。

モジュールマネージャ 3 4は、 BD-ROMから読み出された Index Tableを保持 して、 分岐制御を行う。 この分岐制御は、 JmnpTitleコマンドを HDMVモジュ —ル 3 3が実行した場合、 又は、 タイトルジャンプ APIが BD-Jモジュール 3 5 からコールされた場合、 そのジャンプ先と'なるタイ トル番号を受け取って、 その 夕イ トルを構成する Movieォブジェクト又は BD-Jオブジェクトを HDMVモジ ユール 3 3又は BD-Jモジュール 3 5に通知するというものである。 図中の V0， ▽1,V2が付された矢印は、 JumpTitleコマンドの実行 (0)、 モジュールマネージ ャ 3 4による IndexTable参照 (1)、分岐先 Movieオブジェクト（2)の通知を模式的 に示している。

以上が Presentation Engine 3 1〜モジュールマネージャ 3 4についての説明 である。 続いてアプリケーションマネージャ 3 6について、 図 2 0を参照しなが ら説明する。 図 2 0は、 アプリケーションマネージャ 3 6を示す図である。

アプリケーションマネージャ 3 6は、 アプリケーション管理テーブルを参照し たアプリケーションの起動制御、タイトルの正常終了時における制御を実行する。 起動制御とは、 モジュールマネージャ 3 4から分岐先となる BD-Jオブジェク トが通知される度に、 その BD-Jオブジェクトを読み出し、 その BD-Jオブジェ クト内のアプリケーション管理テ一ブルを参照して口一カルメモリ 2 9アクセス を行う。 そして現在の再生時点を生存区間とするアプリケーションを構成する xletプログラムを、 ワークメモリに読み出すという制御である。 図 2 0における ^1,-^2,^3は、 起動制御における分岐先 BD-Jオブジェクトの通知 (1)、 アプリ ケーション管理テーブル参照 (2)、 Java仮想マシン 3 8に対する起動指示を模式 化して示す。 この起動指示により Java仮想マシン 3 8は、 ローカルメモリ 2 9 からワークメモリ 3 7に xletプログラムを読み出す ( 5)。

タイ トルの終了制御には、 正常終了時の制御と、 異常終了時の制御とがある。 正常終了時の制御には、 タイ トルを構成するアプリケーションによりジャンプタ ィ トル API がコールされて、 分岐先タイ トルへの切り換えを分岐制御の主体 (モ ジュールマネージャ 3 4 )に要求するという制御がある。 この終了制御における、 モジュールマネージャ 3 4通知を模式化して示したのが矢印 6 である。 ここで タイトルを正常終了するにあたって、 タイ トルを構成するアプリケーションは、 起動されたままであってもよい。 何故なら、 アプリケーションを終了するか否か は、 分岐先タイトルにおいて判断するからである。 本実施形態では深く触れない が、 アプリケーションマネージャ 3 6は、 BD ROM からローカルメモリ 2 9に Java アーカイブファイルを読み出す (8)との処理を行う。 このローカルメモリ 2 9への読み出しを模式化したのが 8であ ¾。

以上がアプリケーションマネージャ 3 6についての説明である。 続いてワーク メモリ 3 7〜Default Operation Manager 4 0について、 図 2 1を参照しながら 説明する。

ワークメモリ 3 7は、 アプリケーションを構成する xletプログラムが配置され るヒープ領域である。 ワークメモリ 3 7は、 本来 Java仮想マシン 3 8内に存在 するが、 図 2 1では、 作図の便宜上、 ワークメモリ 3 7を Java仮想マシン 3 8 上位層に記述している。 ワークメモリ 3 7上の xlet プログラムには、 EventListnerや、 JMFプレーヤインスタンスが含まれる。

Java仮想マシン 3 8は、 アプリケーションを構成する letプログラムをヮ一 クメモリ 3 7にロードして、 xletプログラムを解読し、 解読結果に従った処理を JP2004/015330 実行する。 上述したように xletプログラムは、 JMFプレーヤインスタンス生成 を命じるメソッド、 この JMFプレーヤインスタンスの実行を命じるメソッ ドを 含むので、 これらのメソッドで命じられた処理内容を実現するよう、 下位層に対 する制御を行う。 JMFプレーヤインスタンス生成が命じられば、 Java仮想マシ ン 3 8は、 BD-ROM上の YYYY.MPLSフアイルに関連付けられた JMFプレー ャインスタンスを得る。 また、 JMFプレーヤインスタンスにおける JMFメソッ ドの実行が命じられれば、 この JMFメソッドを BD ミ ドルウェアに発行して、 BD再生装置が対応しているファンクションコールに置き換させる。 そして置換 後のファンクションコールを Playback Control Engine 3 2に発行する。

Event Listner Manager 3 9は、 ユーザ操作により生じたイベント（キ一ィベン ト）を解析し、ィベントの振り分けを行う。図中の実線矢印ぐ1，02は、この Event Listner Manager 3 9による振り分けを模式的に示す。 START、 STOP, SPEED 等、 xletプログラム内の Event Listnerに登録されたキーイベントなら、 BD-J オブジェクトにより間接参照されている xletプログラムにかかるィベントを振り 分ける。 STAET、 STOP, SPEED は、 JMF に対応したイベントであり、 xlet プログラムの Event Listnerには、これらのキーイベントが登録されているので、 本キ一イベントにより xlet プログラムの起動が可能になる。 キ一イベントが Event Listner 非登録のキ一ィベントである場合、 本キーィベントを Default Operation Manager 4 0に振り分ける。 音声切り換え、 アンダル切り換え等、 BD-ROM再生装置において生じるキーイベントには、 Event Listnerに登録され ていない多様なものがあり、 これらのキーイベントが生じたとしても、 漏れの無 い処理を実行するためである。

Default Operation Manager 4 0は、 xletプログラム内の Event Listnerに登 録されてないキ一ィベントが Event Listner Manager 3 9から振り分けられると、 その Event Listner 非登録イベン ト に対応するフ ァンクショ ンコールを Playback Control Engine 3 2に対して実行する。 この Default Operation Manager 4 0によるファンクションコールを模式的に示したのが、 図中の矢印◊ 3である。 尚、 図 2 1において Event Listner非登録ィベントは Event Listner Manager 3 9、 Default Operation Manager 4 0により振り分けられたが、 Playback Control Engine 3 2がダイレクトに Event Listner非登録ィベントを 受け取り、 再生制御を行ってもよい (図中の◊ 。

(フローチャートの説明）

以上のアプリケーションマネージャ 3 6についての説明は、 その概要に触れた に過ぎない。 アプリケーションマネージャ 3 6の処理を更に詳しく示したのが図 2 2、 図 2 3のフローチャートである。 以降、 これらのフローチャートを参照し てアプリケーションマネージャ 3 6の処理手順についてより詳しく説明する。 図 2 2は、 アプリケーションマネージャ 3 6による分岐時の制御手順を示す図 である。 本フローチャートは、 ステップ S 2〜ステップ S 5がなす条件を満たす アプリケ一ション（アプリケ一シヨン X という）を、 起動又は終了させるという処 理である。 - ステップ S 2は、 分岐元タイトルで非起動だが、 分岐先タイ トルで生存してい て、 分岐先タイ トルにおける起動属性が AutoRun属性のアプリケーション Xが 存在するか否かの判定であり、 もしあれば、 ローカルメモリ 2 9に対するキヤッ シュセンスを行う。 キャッシュセンスの結果、 アプリケーション Xがローカルメ モリ 2 9上に有れば (ステップ S 7で Yes)、ローカルメモリ 2 9からワークメモリ 3 7にアプリケーション Xを読み込む（ステップ S 8)。 口一カルメモリ 2 9に無 ければ、 BD-ROMからローカルメモリ 2 9にアプリケーション Xを読み込んだ 上で、 口一カルメモリ 2 9からワークメモリ 3 7にアプリケーション Xを読み込 む (ステップ S 9)。

ステップ S 3は、 分岐元夕ィトルで起動中で、 分岐先タィトルで非生存のアブ リケ一シヨン Xが存在するかどうかの判定である。 もし存在するのなら、 アプリ ケーシヨン Xをワークメモリ 3 7から削除して終了させる（ステップ S 1 0)。 ステップ S 4は、 分岐元 Suspend、 分岐先 AutoRun又は Persistentのアプリ ケーシヨンが存在するか否かの判定である。 もし存在するなら、 アプリケ一ショ ン Xを Resumeする（ステップ S 1 1 )。

ステップ S 5は、分岐元タィトルで起動中で、分岐先 Suspendのアプリケーシ ヨンが存在するか否かの判定である。 もし存在すれば、 アプリケーション X を Suspendする（ステップ S 1 2 )。

個々のアプリケーションを終了させるにあたってのアプリケーションマネージ ャ 3 6の処理は、 図 2 3に示すものとなる。 図 2 3は、 アプリケーション終了処 理の処理手順を示すフローチャートである。 本図は、 終了すべき複数アプリケー シヨンのそれぞれについて、 ステップ S 1 6〜ステップ S 2 0の処理を繰り返す ループ処理になっている（ステップ S 1 5)。 本ループ処理においてアプリケーシ ョンマネージャ 3 6は起動中アプリケーションを終了するような terminateィベ ントを発行し（ステップ S 1 6 )、 タイマセットして (ステップ S 1 7)、 ステップ S 1 8〜ステップ S 2 0からなるループ処理に移行する。 この terminateイベント を Event Listnerが受信すれば、 対応する xletプログラムは、 終了プロセスを起 動する。終了プロセスが終了すれば、 その letプログラムはワークメモリ 3 7か ら解放され、 終了することになる。

ステップ S 1 8〜ステップ S 2 0のループ処理の継続中、 タイマはカウントダ ゥンを継続する。 本ループ処理においてステップ S 1 8は、 発行先アプリケーシ

3ンが終了したか否かの判定であり、 もし終了していればこのアプリケ一シヨン に対する処理を終える。 ステップ S 1 9は、 タイマがタイムアウトしたか否かの 判定でぁリ、 タイムアウトすれば、 ステップ S 2 0において発行先アプリケーシ ヨンをワークメモリ 3 7から削除してアプリケーションを強制終了する。

以上のモジュールマネージャ 3 4の処理を、 図 2 4を参照しながら説明する。 図 2 4は、 アプリケーション終了の過程を模式的に示した図である。 本図にお ける第 1段目は、 アプリケーションマネージャ 3 6を、 第 2段目は、 3つのァプ リケーションを示す。図 2 4の第 2段目、左側のアプリケーションは、 terminate イベントを受信して終了プロセスに成功したアプリケーションを示す。 図 2 4の 第 2段目、 中列のアプリケーションは、 terminateイベントを受信したが終了プ 口セスに失敗したアプリケーションを示す。 第 2段目、 右側のアプリケーション は、 EventListnerが実装されていないので、 terminateイベントを受信すること ができなかったアプリケーションを示す。

第 1段目—第 2段目間の矢印 epl,ep2は、 アプリケーションマネージャによる terminateイベント発行を模式的に示し、 矢印 ep3は、 終了プロセス起動を模式 的に示している。

第 3段目は、 終了プロセス成功時における状態遷移後の状態であり、 このアブ リケーシヨンは、 自身の終了プロセスにより終了することになる。 これら xletプ ログラムのように、 所定の期間内に終了しないアプリケーションがあれば、 ァプ 4 015330 リケーシヨンマネージャ 3 6は、 それらを強制的にワークメモリ 3 7.から取り除 く。 第 4段目は、 アプリケーションマネージャ 3 6による強制終了を示す。 かか る第 4段目の強制終了を規定するのも、 アプリケーションマネージャ 3 6の 1つ の使命といえる。

以上のように本実施形態によれば、 分岐元タイトルで起動しており、 分岐先タ ィ トルで生存していないアプリケーションは、 自動的に終了させられるので、 条 件付き分岐により再生が複雑に進行する場合でも、 再生装置におけるリソースの 限界を越える数のアプリケーション立ち上げはなされ無い。 分岐前後におけるァ プリケ一シヨン動作を保証することができるので、 デジタルストリームを再生さ せながら、 アプリケーションを実行させるようなディスクコンテンツを多く頒布 することができる。

(第 2実施形態）

第 1実施形態においてアプリケーションの生存区間は、 タイ トル時間軸と一致 していたが、 第 2実施形態は、 PL 時間軸の一部をアプリケーションの生存区間 とすることを提案する。 PL時間軸の一部は、チャプターにより表現されるので、 チャプターにて開始点、 終了点を記述することにより、 アプリケーションの生存 区間を規定することができる。 図 2 5 ( a ) は、 PL時間軸上に生存区間を定め たアプリケーション管理テーブルを示す図である。 図 2 5 ( a ) においてアプリ ケ一シヨン管理テ一ブルには、 3つのアプリケーションが記述されており、 この うち application#2は、 title#lの Chapter#2から Chapter#3までが生存区間に 指定され、 起動属性に AutoRunが規定されている。 このため application#2は、 図 2 5 ( b ) に示すように、 Chaptei#2の始点で起動され、 Chapter#3の終点で 終了することになる。

一方 application#3は、 title#lの Chapter#4から Chapter#6までが生存区間 に指定されている。 このため application#3は、 図 2 5 ( b ) に示すように、 図 2 5 ( b ) に示すように、 Chaptei#4の始点で起動され、 Chaptei#6の終点で終 了することになる。

こうして記述されたアプリケーション管理テーブルに基づき、 処理を行うため 本実施形態に係るアプリケーションマネージャ 3 6は、 PLmarkにより指示され るチヤプタ一開始点に到達する度に、 そのチヤプタ一開始点から生存区間が始ま るアプリケーションが存在するか否かを判定し、 もし存在すればそのアプリケー シヨンをワークメモリ 3 7にロードする。

同様に、 チャプター開始点に到達する度に、 そのチャプターの直前のチヤプタ —で生存区間が終わるアプリケーションが存在するか否かを判定し、 もし存在す ればそのアプリケ一ションをワークメモリ 3 7から解放する。

チャプターという単位でアプリケ一シヨンの生存を管理すれば、 アプリケ一シ ョンの生存区間をより細かい精度で指定することができる。 しかしディスクコン テンッには、 時間軸の逆向がありうることに留意せねばならない。 逆行とは、 巻 戻しにより時間軸を逆向きに進行することである。 チャプターの境界でこの逆行 と、 進行とが繰り返されれば、 ワークメモリへのロード、 廃棄が何度もなされ、 余分な読出負荷が生じる。 そこで本実施形態では、 アプリケーションの起動時期 を、 タイ トルに入って Playback Control Engine 3 による通常再生が開始され た瞬間にしている。 ここで PLの再生には、 通常再生、 トリック再生がある。 ト リック再生とは、早送り、巻戻し、 SkipNext，SkipBackがある。かかる、早送り、 巻戻し、 SkipNext,SkipBackがなされている間、 アプリケーション起動を開始せ ず、 通常再生が開始されて初めて、 アプリケーションを起動するのである。 通常 再生開始の瞬間を基準にすることにより、 上述したような生存区間前後の行き来 があった場合でも、 アプリケーションの起動が必要以上に繰り返されることはな い。尚、通常再生開始の瞬間を、アプリケーションの起動基準にするとの処理は、 生存区間が titleである場合にも、 実行してよい。

以上のように本実施形態によれば、 PL より小さい、 チャプターの単位でアブ リケ一シヨンの生存区間を規定することができるので、 緻密なアプリケーション 制御を実現することができる。

(第 2実施形態の変更例）

図 2 5では、 各アプリケーションに優先度が付与されている。 この優先度は、 0〜255の値をとり、アプリケーション間でリソースの使用が競合等が競合した場 合、 どちらのアプリケーションを強制的に終了させるか、 また、 どちらのアプリ ケーションからリソースを奪うかという処理をアプリケーシヨンマネージャ 3 6 が行うにあたって、 判断材料になる。 図 2 5の一例では、 application#l の優先 度は 255，application#2、 appUcation#3の優先度は 128なので、 application#l -application#2 の競合時において、 アプリケーションマネージャ 3 6は優先度 が低い application#2を強制終了するとの処理を行う。

(第 3実施形態）

BD-ROM により供されるディスクコンテンツは、 互いに分岐可能な複数タイ トルから構成される。各タイ トルは、 1つ以上の; PLと、 この PLを用いた制御手 順とからなるもの以外に、 再生装置に対する制御手順のみからなる非 AV系タイ トルがある。 本実施形態は、 この非 AV系タイ トルについて説明する。

こうした非 AV系タイ トルのタイトルでは、 どのようにタイ トル時間軸を定め るのかが問題になる。 図 2 6 ( a ) は、 PL時間軸から定まるタイ トル時間軸を 示す。 この場合 PL時間軸がタイトル時間軸になり、 このタイ トル時間軸上にァ プリケーシヨンの生存区間が定まる。 この基準となる PL時間軸がない場合、 タ ィトル時間軸は図 2 6 (b ) ( c ) のように定めるべきである。

図 2 6 ( b ) は、 メインとなるアプリケーションの生存区間から定まるタイ ト ル時間軸を示す。 メインアプリとは、 タイ トルにおいて起動属性が AutoRun に 設定され、 タイ トル開始時に自動起動される唯一のアプリケーションであり、 例 えばランチャーアプリと呼ばれるものがこれにあたる。 ランチャーアプリとは、 他のアプリケーションを起動するアプリケ一ションプログラムである。

この図 2 6 ( b ) の考え方は、 メインアプリが起動している限り、 タイ トル時 間軸は継続していると考え、 メインアプリが終了すれば、 時間軸を終結させると いうものである。 図 2 6 ( c ) は、 複数アプリケーションの生存区間から定まる タイトル時間軸を示す図である。 タイトルの開始点で起動されるのは 1つのアブ リケーションであるが、 このアプリケーションが他のアプリケーションを呼び出 し、 更にこのアプリケーシヨンが別のアプリケ一シヨンを呼び出すとの処理が繰 り返されるというケースがある。 この場合、 どれかのアプリケーションが起動し ている限り、 タイ トル時間軸は継続していると考え、 どのアプリケーションも起 動していない状態が到来すれば、 そこでタイトル時間軸は終結するという考え方 である。 このように非 AV系タイトルのタイ トル時間軸を定めれば、 AVタイトル であっても、 非 AV系タイトルであっても、 タイトル時間軸の終結と同時に、 所 定のタイトルに分岐するという処理を画一的に行うことができる。 尚非 AVタイ トルにおけるタイ トル時間軸は、 AV タイトルと対比する上で、 想定した架空の 0 時間軸に過ぎない。 故に再生装置は、 非 AVタイトルにおけるタィ トル時間軸上 を逆行したり、 任意の位置に頭出しすることができない。

以上は本実施形態における記録媒体に対する改良である。 続いて本実施形態に おける再生装置に対する改良について説明する。

上述したような手順でタイ トル終了を行うため第 3実施形態に係るアプリケー シヨンマネージャ 3 6は、 図 2 7に示すような処理で処理を行う。 図 2 7は、 タ ィ トル再生時におけるアプリケーションマネージャ 3 6の処理手順を示すフロー チャートである。 本フローチャートは、 タイトル再生中、 ステップ S 2 1〜ステ ップ S 2 3を繰り返すというループ構造になっている。

ステップ S 2 1は、タイ トルジャンプ APIが呼び出されたか否かの判定であり、 呼び出されれば、 ジャンプ先タイ トルへの分岐をモジュールマネージャ 3 4に要 求する（ステップ S 2 7)。 ,

ステップ S 2 2は、 タイトル内のアプリケーション呼出を担っているようなメ インアプリが存在するか否かの判定であり、 もし存在するなら、 それの起動の有 無を確認する（ステップ S 2 5)。 起動してなければ、" タイ トルの終わり" である と解釈し、 モジュールマネージャ 3 4に終結を通知する（ステップ S 2 6)。

ステップ S 2 3は、メインアプリがない場合に実行されるステップであり（ステ ップ S 2 2で No)、 どのアプリケーションも起動してない状態かどうかを判定す る。 もしそうなら、 同じく" タイ トルの終わり" であると解釈し、 モジュールマ ネージャ 3 4に終結を通知する（ステップ S 2 6)。

以上のように本実施形態によれば、 PL再生を伴わないタイ トルであっとして も、 アプリケーション実行中は分岐せず、 アプリケーション実行が終了して初め て分岐するという処理が可能になる。

(第 4実施形態）

本実施形態は、 DVDと同様のメニュー制御を BD-ROM上で実現する場合の改 良に関する。 図 2 8 ( a ) は、 BD-ROM により実現されるメニュー階層を示す 図である。 本図におけるメニュー階層は、 TbpMenu を最上位に配し、 この IbpMenuから下位の TitleMenu、 SubTitleMenu, AudioMenuを選択できる構 造になっている。 図中の矢印 swl，2，3は、 ポタン選択によるメニュー切り換えを 模式的に示す。 TopMenu とは、 音声選択、 字幕選択、 タイ トル選択の何れを行 うかを受け付けるボタン（図中のボタン snl，sn2，sn3)を配置したメニューである。 TitleMenu とは、 映画作品 (title)の劇場版を選択するか、 ディ レクタ一ズカツ ト版を選択するか、 ゲーム版を選択するか等、 映画作品の選択を受け付けるボタ ンを配置したメニューであさ。 AudioMenu とは、 音声再生を日本語で行うか、 英語で行うかを受け付けるボタンを配置したメニュー、 SubTitleMenuとは、 字 幕表示を日本語で行うか、 英語で行うかを受け付けるボタンを配置したメニュー である。

こうした階層をもったメニューを動作させるための MOVIEオブジェクトを図 2 8 ( b )に示す。図 2 8 ( b )において MovieObject.bdmvには、 FirstPlay OBJ、 TbpMenu OBJ, AudioMenu OBJ, SubTitleMenu OBJが格納されている。

FirstPlayォブジ工クト（FirstPlay OBJ)は、 再生装置への BD-ROMのローデ ィング時に自動的に実行される動的シナリオである。

TbpMenuォブジヱクト（TopMenu OBJ)は、 TopMenuの挙動を制御する動的シ ナリオである。 ユーザがメニューコールを要求した際、 呼び出されるのはこの TopMenuオブジェクトである。 TopMenuオブジェクトは、 ユーザからの操作に 応じて TbpMenu中のボタンの状態を変えるものや、 ボタンに対する確定操作に 応じて分岐を行う分岐コマンドを含む。 この分岐コマンドは、 TopMenu から TitleMenu. TopMenuから SubTitleMenu、 TopMenuから AudioMenuという メニュー切り換えを実現するものである。

AudioMenuォブジェクト（AudioMenu OBJ)は、 AudioMenuの挙動を制御す る動的シナリォであり、 ユーザからの操作に応じて AudioMenu中のボタンの状 態を変えるコマンドゃ、 ボタンに対する確定操作に応じて音声設定を更新するコ マンドを含む。 '

SubTitleMenuォブジェクト（SubTitleMenu OBJ)は、 SubTitleMenuの挙動を 制御する動的なシナリオであり、 ユーザからの操作に応じて SubTitleMenu中の ボタンの状態を変えるコマンドゃ、 ボタンに対する確定操作に応じて字幕設定用 の PSRを更新するコマンドを含む。

TitleMenuオブジェクト（TitleMenu OBJ)は、 itleMenuの挙動を制御する動 的シナリオであり、 itleMenu中のボタンの状態を変えるものや、 ボタンに対す る確定操作に応じて分岐を行う分岐コマンドをふくむ。 これらのメニュー用 MOVIEオブジェクトにより、 DVDで実現されているよ うなメニューの挙動を実現することができる。 以上がメニュー制御に関連する MOVIEオブジェクトである。

図 2 9は、 Index Tableと、 Index Tableから各 Movieォブジェクトへの分岐 とを模式化した図である。本図では左側に Index Tableの内部構成を示している。 本実施形態における Index Table には、 FirstPLayINDEX、 TopMenuINDEX, Audio MenuINDEX, Subtitle MenuINDEX, title MenuINDEX. title#l~ #mINDEX、 title#m+l〜#nINDEX、 title#0INDEX を含む。 図中の矢印 bcl，2 は、 Index Tableから FirstPlayOBJへの分岐と， FirstPlayOBJから TopMenuへ の分岐とを模式的に示し、 矢印 bc3，4,5 は、 TopMenu から itleMenu、 Sub itleMenu, AudioMenuへの分岐を模式的に示している。 矢印 bc6，7，8は、 TitleMenuから各 Movieオブジェクトへの分岐を模式的に示している。

FirstPLaylNDEX、 TopMenuINDEX, Audio MenuINDEX、 Subtitle MenuINDEX, title MenuINDEXは、それぞれ、 FirstPLayOBJ, IbpMenuOBJ, Audio MenuOBJ, Subtitle MenuOBJ, title MenuOBJについての Indexであ り、 これらの識別子が記述される。

title#l〜#mINDEXは、 BD-ROMにおいて 1から m番目にエントリーされて \、る titleについての Indexであり、これら 1から瓜までの title番号の選択時に おいて分岐先となる MOVIEオブジェクトの識別子 (ID)が記述される。

title#m+l〜#nINDEXは、 BD-ROMにおいて m+1から n番目にエントリー されている titleについての Indexであり、 これら m+1から nまでの title番号 の選択時において分岐先となる BD-Jォブジヱクトの識別子 (ID)が記述される。 title#0INDEXは、 BD-Jォブジヱクトの強制終了時において分岐先になるべき Movieォブジェクト又は BD-Jォブジェクトを規定する INDEXである。 本実施 形態では、 TopMenuOBJについての識別子が、 この title#0INDEXに格納され ている。

図 3 0 ( a ) は、 図 2 9のように Index Tableが記述された場合における分岐 を示す。. Index Tableがこのように記述されているので、 ラベル title#l〜title#m を分岐先とした分岐コマンドの実行時には、 title#llndex〜titie#mlndex から Movieォブジェクト #l〜#mの識別子が取り出される。ラベル title#m+l〜title#n 15330 を分岐とした分岐コマンドの実行時には、 title#m+llndex〜title#nlndex から BD-J オブジェクト #m+l〜#n の識別子が取り出される。 BD-J ォブジェクト #m+l〜#n の識別子は、 フ ァイル名を表す 5 桁の数値であるので、 r00001.BD-J,00002.BD-J,00003.BD-J · · ·』が取り出され、そのファイル名の動 的シナリオがメモリに読み出されて、実行されることになる。これが Index Table を用いた分岐処理である。

図 3 0 ( b ) は、 BD-J オブジェクト実行時の強制終了時における分岐を示す 図である。 強制終了時における分岐では、 title#01ndexから識別子が取り出され て、 その識別子の動的シナリオが再生装置により実行される。 この識別子が、 ト ップメニュータイ トルの識別子なら、 アプリケーション強制終了時には、 自動的 にトップメニュ一OBJが選択されることになる。 以上は本実施形態における記録媒体に対する改良である。 続いて本実施形態に おける再生装置に対する改良について説明する。 上述した記録媒体の改良に対応 するため、 再生装置内のモジュールマネージャ 3 4は図 3 1に示すような処理手 順で処理を行う。 図 3 1は、 モジュールマネージャ 3 4の処理手順を示すフロー チャートである。 本フローチャートは、 ステップ S 3 1、 ステップ S 3 2からな るループ処理を構成しており、 ステップ S 3 1又はステップ S 3 2のどちらかが Yesになった際、 対応する処理を実行するものである。

ステップ S 3 1は、タイトルジャンプ A^Iの呼び出しがあつたか否かの判定で ある。 もしタイ トルジャンプ APIの呼び出しがあれば、 分岐先ラベルであるタイ トル番号 ]' を取得し (ステップ S 3 3)、 Index Table におけるタイ トル番号 j の Indexから、 IDjを取り出して (ステツプ S 3 4)、 IDjの Movieオブジェクト又は BD-Jォブジェクトを、 HDMVモジュール 3 3又は BD-Jモジュール 3 5に実行 させる（ステップ S 3 5)。

ステップ S 3 2は、 タイトル終了がアプリケーションマネージャ 3 6から通知 されたか否かの判定であり、 もし通知されれば (ステップ S 3 2で Yes)、 トップメ ニュータイ トルを構成するトップメニュー OBJを HDMVモジュール 3 3又はモ ジュールマネージャ 3 4に実行させる（ステップ S 3 6)。

以上のアプリケーションマネージャ 3 6によるアプリケ一ション強制終了の動 作例を、 図 3 2を参照しながら説明する。 ここで再生すべきタイトルは、 落下す るタイル片を積み重ねるというゲームアプリを含む非 AV系タイトルである。 図 3 2の下段は、 アプリケーションの生存区間からなるタイ トル時間軸を示し、 上 段は、 タイ トル時間軸において表示される画像を示す。 非 AV系タイ トルがゲー ムアプリである場合、 このゲームアプリの生存区間において、 図 3 2の上段左側 のように、 ゲームアプリの一画面が表示される。 ゲームアプリにバグがあり、 異 常終了すると、 アプリケーションマネージャ 3 6は図 2 3のフローチャートに従 つてゲームアプリを強制終了させ、 タイ トルの終了をモジュールマネージャ 3 4 に通知する。 タイ トル終了が通知されると、 モジュールマネージャ 3 4はトップ メニュータイトルに分岐する。 そうすると、 図 3 2の上段右側に示すような画像 が表示され、 ユーザの操作待ちになる。 以上のように本実施形態によれば、 プログラムが含むが、 デジタルストリーム は含まないような非 AV系タイトルの終了時においても、 トップメニュータイ ト ルに分岐するという制御が可能になる。 これによりアプリケーションプログラム がエラー終了したとしても、 ブラックァゥトゃハングアップの発生を回避するこ とができる。

(第 5実施形態）

BD-Jモードにおいて、 PL再生との同期をどのように実現するかという改良に 関する。 図 8 ( b ) の一例において JMFプレーヤインスタンスの再生を命じる JMF プレーヤィンスタンス (A.play;)を Java仮想マシン 3 8が解読した場合、 Java仮想マシン 3 8は PL再生 APIをコールして、 コール直後に" サクセス" を示す応答をアプリケ一ションに返す。

Playback Control Engine 3 は、 PL再生 APIがコ一ルされれば、 PL情報に 基づく処理手順を実行する。 PLが 2時間という再生時間を有するなら、 この 2 時間の間、 上述した処理は継続することになる。 ここで問題になるのは、 Java 仮想マシン 3 8がサクセス応答を返す時間と、 Playback Control Engine 3 2が 実際に処理を終える時間とのギヤップである。 Java仮想マシン 3 8は、 ィベント ドリブンの処理主体であるためコール直後に再生成功か、 再生失敗かを示す応答 を返すが、 Playback Control Engine 3 2による実際の処理終了は 2時間経過後 5330

であるので、 サクセス応答をアプリケーションに返す時間を基準にしたのでは、

2時間経過後にあたる処理終結を感知しえない。 PL再生において早送り、巻戻し、 Skipが行われると、この 2時間という再生期間は 2時間前後に変動することにな り、 処理終結の感知は更に困難になる。

Playback Control Engine 3 2は、 アプリケーションとスタンドアローンで動 作するため、 第 3実施形態のような終了判定では、 PL再生の終了をタイ トル終 了と解釈することができない。 そこで本実施形態では、 アプリケーションが終了 してようがいまいが、 ワークメモリ 3 7に JMFプレーヤィンスタンスがある限 り、つまり、 Presentation Engine 3 1の制御権を BD-Jモジュール 3 5が掌握し ている間、 Playback Control Engine 3 2から再生終結イベントを待つ。 そして 再生終結イベントがあれば、 タイ トルが終了したと解釈して、 次のタイトルへの 分岐を行うようモジュールマネージャ 3 4に通知する。 こうすることにより、 Playback Control Engine 3 2が PL再生を終結した時点を、タイ トルの終端とす ることができる。

以降図 3 3〜図 3 7のフローチャートを参照して、 Playback Control Engine 3 2による具体的な制御手順を説明する。

図 3 3は、 Playback Control Engine 3 2による PL再生手順を示すフローチヤ ートである。 この再生手順は、 Presentation Engine 3 1に対する制御 (ステップ S 4 6 )と、 BD-ROM ドライブ 1又は HDD 1 7に対する制御 (ステップ S 4 8 ) とを主に含む。本フローチャートにおいて処理対象たる Playltemを Playltem#x とする。本フローチャートは、 カレント PL情報 (.mpls)の読み込みを行い (ステツ プ S 4 1 )、 その後、 ステップ S 4 2〜ステップ S 5 0の処理を実行するというも のである。 ここでステップ S 4 2〜ステップ S 5 0は、 ステップ S 4 9が Yesに なるまで、 カレント PL情報を構成するそれぞれの PI情報について、 ステップ S 4 3〜ステップ S 5 0の処理を繰り返すというループ処理を構成している。 この ル―プ処理において処理対象となる Playltemを、 PlayItem#x(PI#x)とよぶ。 こ の Playltem#xは、 カレント PLの先頭の Playltemに設定されることにより、初 期化される（ステップ S 4 2 )。 上述したループ処理の終了要件は、 この Playltem# がカレント PLの最後の Playltemになることであり（ステップ S 4 9 )、 もし最後の Playltemでなければ、 カレント PLにおける次の Playltemが Playltem#xに設定される（ステップ S 5 0 )。

ループ処理において繰り返し実行されるステップ S 4 3〜ステップ S 5 0は、 Playltem# の Clip一 information_file_nameで指定される Clip情報をシナリオメ モリ 2 1に読み込み（ステップ S 4 3)、 Playltem#xの In— timeを、カレント Clip 情報の EPmap を用いて、 I ピクチャアドレス u に変換し（ステップ S 4 4)、 Playltem#xの Out— timeを、 カレント Clip情報の EP— mapを用いて、 Iピクチ ャアドレス Vに変換して（ステップ S 4 5)、 これらの変換で得られたァドレス V の次の Iピクチャを求めて、 そのアドレスの 1つ手前をァドレス wに設定し（ス テツプ S 4 7 )、 そうして算出されたァドレス wを用いて、 Iピクチャアドレス u からアドレス wまでの TSパケットの読み出しを BD-ROMドライブ 1又は HDD 1 7に命じるというものである（ステップ S 4 8)。

一方、 Presentation Engine 3 1 に対しては、 カ レン ト PLMark の mark_time_stam から Playltem#xの Out_timeまでの出力を命じる（ステップ S 4 6 )。 以上のステップ S 4 5〜ステップ S 4 8により、 AVClip において、 Playltem#xにより指示されている部分の再生がなされることになる

その後、 Playltem#xがカレント PLの最後の PIであるかの判定がなされる（ス テツプ S 4 9 )。

Playltem#xがカレント PLの最後の PIでなければ、 カレント PLにおける次 の Playltemを、 Playltem#xに設定して（ステツプ S 5 0)、 ステップ S 4 3に戻 る。 以上のステップ S 4 3〜ステップ S 5 0を繰り返することにより、 PL を構 成する PIは順次再生されることになる。

図 3 4は、 アングル切り換え手順及ぴ SkipBack，SkipNextの手順を示すフ口 一チャートである。 本フローチャートは、 図 3 3の処理手順と並行してなされる ものであり、 ステップ S 5 1〜S 5 2からなるループ処理を繰り返すというもの である。 本ループにおけるステップ S 5 1は、 アングル切り換えを要求する API が、 Java仮想マシン 3 8からコールされたか否かの判定であり、 アングル切り換 え APIのコールがあれば、 カレント Clip情報を切り換えるという操作を実行す る。

図 3 4のステップ S 5 5は、 判定ステップであり、 Playltem#x の is— multi— angles がオンであるか否かの判定を行う。 is— multi— angles とは、 Playltem#x がマルチアングルに対応しているか否かを示すフラグであり、 もし ステップ S 5 5が Noであるならステップ S 5 3に移行する。 ステップ S 5 5が Yesであるなら、 ステップ S 5 6〜ステップ S 5 9を実行する。 ステップ S 5 6 〜ステップ S 5 9は、切り換え後のアングル番号を変数 yに代入して (ステップ S 5 6)、 Playltem#xにおける y番目の Clip— information_file_nanieで指定されて いる Clip情報をシナリオメモリ 2 1に読み出し (ステップ S 5 7)、カレント PTM を、 カレント Clip情報の EP— mapを用いて Iピクチャアドレス uに変換し（ステ ップ S 5 8)、 Playltem#xの Outjimeを、 カレント Clip情報の EP一 mapを用 いて Iピクチャアドレス Vに変換する（ステップ S 5 9)というものである。 こう して Iピクチャアドレス u，vを変化した後、 ステップ S 4 6に移行する。 ステツ プ S 4 6への移行により、 別の AVClipから TSバケツトが読み出されるので、 映像内容が切り換わることになる。

一方、 図 3 4のループにおけるステップ S 5 2は、 SkipBack/SkipNextを意味 する APIが Java仮想マシン 3 8からコールされたか否かの判定であり、 もしコ ールされれば、 図 3 5のフローチャートの処理手順を実行する。 図 3 5は、 SkipBack, SkipNextAPIがコールされた際の処理手順を示すフローチャートであ る。 SkipBack,SkipNextを実行するにあたっての処理手順は多種多様なものであ る。 ここで説明するのはあくまでも一例に過ぎないことに留意されたい。

ステップ S 6 1は、 PSRで示される力レント PI番号、 及び、 カレント PTM を変換することにより、 カレント Mark情報を得る。 ステップ S 6 2は、 押下さ れたのが SkipNext キーであるか、 SkipBack キーであるかの判定であり、 SkipNext キーであるならステップ S 6 3において方向フラグを +1 に設定し、 SkipBackキーであるならステップ S 6 4において方向フラグを- 1に設定する。 ステップ S 6 5は、カレント PLMarkの番号に方向フラグの値を足した番号を、 力レント PLMarkの番号として設定する。 ここで SkipNextキーであるなら方向 フラグは +1に設定されているのでカレント PLMarkはインクリメントされるこ とになる。 SkipBackキーであるなら方向フラグは- 1に設定されているので、 力 レント PLMarkはデクリメントされることになる。

ステップ S 6 6では、 カレント PLMarkの ref— to— Playltem— Idに記述されて いる PI を、 Playltem# に設定し、 ステップ S 6 7では、 Playltem#x の Clip— information— file— nameで指定される Clip情報を読み込む。 ステップ S 6 8では、 カレント Clip 情報の EP— map を用いて、 カ レント PLMark の mark_time_stampを、 Iピクチャアドレス uに変換する。一方ステップ S 6 9で は、 Playltem#xの Outjimeを,カレント Clip情報の EP— mapを用いて, Iピク チヤア ド レス V に変換する。 ステップ S 7 0は、 カ レン ト PLMark の mark— time— stamp 力、り Playltein#x の Out— time までの出力を Presentation Engine 3 1に命じた上で、 図 3 3のステップ S 4 7に移行する。 こうして Iピク チヤアドレス u，vを変化して、 別の部分の再生を命じた上でステップ S 4 7への 移行するので、 別の AVClipから TSバケツトが読み出されることになり、 映像 内容が切り換えが実現する。 - 図 3 6は、 Presentation Engine 3 1による処理手順の詳細を示すフローチヤ ートである。 本フローチャートは、 Iピクチャの PTSを力レント PTMに設定し た後で (ステップ S 7 1 )、 ステップ S 7 2〜ステップ S 7 7からなるループ処理 を実行するものである。

続いてステップ S 7 2〜ステップ S 7 7におけるループ処理について説明する。 このループ処理は、カレント PTMにあたるピクチャ、オーディォの再生出力と、 カレント PTMの更新とを繰り返すものである。 本ループ処理におけるステップ S 7 6は、 ループ処理の終了要件を規定している。 つまりステップ S 7 6は、 力 レント PTMが PI#xの Out— timeであることをループ処理の終了要件にしている。 ステップ S 7 3は、 早送り API、 又は、 早戻し APIが Java仮想マシン 3 8か らコールされたか否かの判定である。 もしコールされれば、 ステップ S 7 8にお いて早送りか早戻しかの判定を行い、 早送りであるなら、 次の Iピクチャの PTS を力レント PTMに設定する（ステップ S 7 9)。 このように力レント PTMを、 次 の Iピクチャの PTSに設定することで、 1秒飛びに AVClipを再生してゆくこと ができる。 これにより、 2倍速等で AVClipは順方向に早く再生されることにな る。 早戻しであるなら、 カレント PTMが Playltem#xの Out_timeに到達した かを判定する（ステップ S 8 0)。 もし到達してないのなら、 1つ前の Iピクチャの PTSを力レント PTMに設定する（ステップ S 8 1 )。 このように読出先ァドレス Aを、 1つ前の Iピクチャに設定することで、 AVClipを後方向に 1秒飛びに再生 してゆくことができる。 これにより、 2倍速等で AVClip は、 逆方向に再生され ることになる。 尚、 早送り、 巻戻しを実行するにあたっての処理手順は多種多様 なものである。 ここで説明するのはあくまでも一例に過ぎないことに留意された い。

ステップ S 7 4は、 メニューコール APIがコールされたか否かの判定であり、 もしコールされれば、 現在の再生処理をサスペンドして（ステップ S 8 2 )、 メニ ユー処理用のメニュープログラムを実行する（ステップ S 8 3 )。 以上の処理によ り、 メニューメニューコールがなされた場合は、 再生処理を中断した上で、 メニ ユー表示のための処理が実行されることになる。

ステップ S 7 5は、 sync— Playltem_id により、 Playltem# を指定した SubPlayItem#yが存在するか否かの判定であり、 もし存在すれば、図 3 7のフロ 一チャートに移行する。 図 3 7は、 SubPlayltemの再生手順を示すフローチヤ一 トである。本フローチャートでは、先ずステップ S 8 6において、 カレント PTM は SubPlayItem#yの sync— start— PTS_of_j)layIteniであるか否かを判定する。も しそうであれば、 ステップ S 9 3において SubPlayItem#yに基づく再生処理を 行うよう Playback Control Engine 3 2に通知する。

図 3 7のステップ S 8 7〜ステップ S 9 2は、 SubPlayItem#yに基づく再生処 理を示すフローチャートである。

ステップ S 8 7では、 SubPlayItem#yの Clip— information— file— nameで指定 される Clip情報を読み込む。ステップ S 8 8では、カレント Clip情報の EP— map を用いて、 SubPlayItem#yの In— time を、 アドレス に変換する。 一方ステツ プ S 8 9では、 SubPlayItem# の Outjimeを,カレント Clip情報の EP_mapを 用いて、 アドレス に変換する。 ステップ S 9 0は、 SubPlayItem#yの In— time から SubPlayItem#yの Out— timeまでの出力をデコーダに命じる。 これらの変 換で得られたァドレス 13の次の Iピクチャを求めて、 そのァドレスの 1つ手前を アドレス yに設定し (ステップ S 9 1 )、そうして算出されたアドレス yを用いて、 SubClip#zにおけるアドレス aからアドレス Ίまでの TSパケヅ卜の読み出しを BD-ROM ドライブ 1又は HDD 1 7に命じるというものである（ステップ S 9 2)。 また図 3 3に戻って： Playback Control Engine 3 2の処理の説明の続きを行う。 ステップ S 5 3は Presentation Engine 3 1による再生制御が完了したかの判定 であり、 最後の Playltem#xに対して、 図 3 6のフ口一チャートの処理が行われ ている限り、 ステップ S 5 3が Noになる。 図 3 6のフローチャートの処理が終 了して初めて、 ステップ S 5 3は Yesになりステップ S 5 4に移行する。 ステツ プ S 5 4は、 Java仮想マシン 3 8への再生終結イベントの出力であり、 この出力 により、 2時間という再生時間の経過を Java仮想マシン 3 8は知ることができ る。

以上が本実施形態における Playback Control Engine 3 2、 Presentation Engine 3 1の処理である。続いて本実施形態におけるアプリケーションマネージ ャ 3 6処理手順について説明する。 図 3 8は、 第 5実施形態に係るアプリケ一シ ョンマネージャ 3 6の処理手順を示すフローチャートである。

図 3 8のフローチャートは、 図 2 7のフローチャートを改良したものである。 その改良点は、ステップ S 2 1一ステップ S 2 2間にステップ S 2 4が追加され、 このステップ S 2 4が Yesになった際、 実行されるステップ S 1 0 1が存在する 点である。

ステップ S 2 4は、 JMFプレーヤィンスタンスがワークメモリ 3 7に存在する か否かの判定であり、 もし存在しなければステップ S 2 2に移行する。 存在すれ ば、 ステップ S 1 0 1に移行する。 ステップ S 1 0 1は、 Playback Control Engine 3 2から再生終結イベントが出力されたか否かの判定であり、 もし出力さ れれば、 ワークメモリ中の Javaプレーヤィンスタンスを消滅させた上で (ステツ プ S 1 0 2)、 タイ トル終了をモジュールマネージャ 3 4に通知する（ステップ S 2 6)。通知されねば、 ステップ S 2 1〜ステップ S 2 4からなるループ処理を繰 り返す。

以上のフローチャートにおいて、 ワークメモリ 3 7に JMFプレーヤィンスタ ンスが存在する限り（ステップ S 2 4で Yes；)、 ステップ S 2 2、ステップ S 2 3は スキップされる。 そのため、 たとえ全てのアプリケーションが終了したとしても タイトルは継続中と解釈される。

以上のように本実施形態によれば、 2時間という再生時間の経過時点をアプリ ケーシヨンマネージャ 3 6は把握することができるので、 PL再生の終了条件に メニューを表示して、 このメニューに対する操作に応じて他のタイ トルに分岐す るという制御を実現することができる。

(第 6実施形態） 0 第 6実施形態は、 BD-J オブジェクトにデータ管理テーブルを設ける改良に関 する。

データ管理テーブル (DMT)は、 そのタイ トル時間軸においてローカルメモリ 2 9上にロードすべき Javaアーカイブファイルを、 読込属性と、 読込優先度とに 対応づけて示すテーブルである。" 口一カルメモリ 2 9における生存" とは、 その アプリケーションを構成する Javaアーカイブファイルがローカルメモリ 2 9か ら読み出され、 Java仮想マシン 3 8内のワークメモリ 3 7への転送が可能になつ ている状態をいう。 図 3 9は、 データ管理テーブルの一例を示す図である。 本図 に示すようにデータ管理テーブルは、 アプリケーションの 『生存区間』 と、 その 生存区間をもったアプリケーションを識別する 『applicationID』 と、 そのアプリ ケーシヨンの 『読込属性』 と、 『読込優先度』 とを示す。

上述したようにアプリケ一ション管理テーブルには、 生存区間という概念があ り、 データ管理テーブルにも同じ生存区間という概念がある。 アプリケーション 管理テーブルと同じ概念を、 データ管理テーブルに設けておくというのは一見無 駄のように思えるがこれには意図がある。

図 4 0は、 BD-J オブジェクトが想定している実行モデルを示す図である。 本 図における実行モデルは、 BD-ROM、 ローカルメモリ 2 9、 Java仮想マシン 3 8からなり、 BD-ROM、 ローカルメモリ 2 9、 ワークメモリ 3 7という三者の関 係を示す。 矢印 mylは、 BD_ROM→ローカルメモリ 2 9間の読み込みを示し、 矢印 my2は、' ローカルメモリ 2 9→ワークメモリ 3 7間の読み込みを示す。矢印 上の注釈は、 これらの読み込みが、 どのようなタイミングでなされるかを示す。 注釈によると、 BD-ROM→ローカルメモリ 2 9間の読み込みは、 いわゆる" 先読 み" であり、 アプリケーションが必要となる以前の時点に行われねばならない。 また注釈によると、 ローカルメモリ 2 9→ワークメモリ 3 7間の読み込みは、 アプリケーションが必要になった際になされることがわかる。" 必要になった際" とは、 アプリケーションの生存区間が到来した時点 (1)、 アプリケーションの呼出 が他のアプリケーション又はアプリケーションマネージャ 3 6から指示された時 点 (2)を意味する。

矢印 my3は、ワークメモリ 3 7におけるアプリケーションの占有領域の解放を 示し、矢印 my4は、 ローカルメモリ 2 9におけるアプリケーションの占有領域の P2004/015330 解放を示す。 矢印上の注釈は、 これらの読み込みが、 どのようなタイミングでな されるかを示す。 注釈によると、 ワークメモリ 3 7上の解放は、 アプリケーショ ン終了と同時になされることがわかる。 一方ローカルメモリ 2 9上の解放は、 Java仮想マシン 3 8にとつて必要でなくなつた時点でなされる。この必要でなく なった時点とは、" 終了時点" ではない。" 終了した上、 再起動の可能性もない時 点"であること、つまり該当する titleが終了した時点を意味する。上述した読込- 解放のうち、 ワークメモリ 3 7における解放時点は、 アプリケーション管理テー ブルにおける生存区間から判明する。 しかし" アプリケーションが必要となる以 前の時点"、" 終了した上、 再起動の可能性もない時点" については、 規定し得な い。 そこで、 ォーサリング段階において、 かかる時点をディスクコンテンツ全体 の時間軸上で規定しておくため、 本実施形態では各アプリケーションが生存して いる区間を、 アプリケーション管理テーブルとは別に、 データ管理テ一ブルに記 述するようにしている。 つまり" アプリケーションが必要となる以前の時点" を データ管理テーブルにおける生存区間の始点と定義し、"終了した上、再起動の可 能性もない時点" をデータ管理テ一プルの終点と定義することにより、 上述した 口一カルメモリ 2 9上の格納内容の遷移をォーサリング時に規定しておくことが できる。 これがデ一タ管理テ一ブルの記述意義である。

データ管理テーブルによるローカルメモリ 2 9生存区間の記述について説明す る。 ここで制作しょうとするディスクコンテンツは 3 つのタイ トル (title#l、 title#2、 title#3)からなり、 これらタイトルの時間軸において、 図 4 1 ( b ) に示 すようなタイミングで、 ローカルメモリ 2 9を使用したいと考える。 この場合、 title#l時間軸の開始点において application#l、 application#2を構成する Java ァ一力イブフアイルをローカルメモリ 2 9に読み込み、 title#l 時間軸の継続中、 application#l, application#2 をローカルメモリ 2 9に常駐させておく。 そして title#2時間軸の始点で、 application#lを構成する Javaアーカイブフアイルを口 一カルメモリ 2 9から解放して、代わりに application#3を構成する Javaァ一力 イブファイルを口一カルメモリ 2 9に読み込んで、 常駐させるというものである (以降、 アプリケーションを構成する Javaアーカイブファイルは、 アプリケーシ ヨンと同義に扱う。 ）。 この場合のデータ管理テーブルの記述は、 図 4 1 ( a ) の 通りであり、 アプリケーションの applicationIDを、 その生存区間に対応づけて 04 015330 記述することで、ローカルメモリ 2 9に常駐すべきアプリケーションを表現する。 図 4 1 ( a ) では、 application#lの applicationlDが title#lと対応づけられて 記述されており、 application#2の applicationlDは title#l、 title#2と対応づけ られ、 application#3の applicationlDは title#3と対応づけられて記述されてい ることがわかる。 こうすることで、 ローカルメモリ 2 9占有の時間的遷移がォー サリング担当者により規定されることになる。

データ管理テーブル、 アプリケーション管理テ一プルの組合せとしては、 ァプ リケーシヨン管理テーブルに規定する生存区間は、 細かい再生単位にし、 データ 管理テーブルに規定する生存区間は、 大まかな再生単位にすることが望ましい。 大まかな再生単位には、 タイ トル、 PL といった非シームレスな再生単位が望ま しい。 一方、 細かい再生単位としては、 PL 内のチャプターというようにシ一ム レスな再生単位が望ましい。 アプリケーションの生存区間をタイ トル毎、 PL毎 に定めれば、 アプリケーションは口一カルメモリ 2 9上に存在するので、 その夕 ィ トルの再生中においてアプリケーションは何時でも取り出せる状態になる。 そ うであれば、 アプリケーションの生存区間を細かく定めたとしても、 アプリケー シヨンを即座に、 仮想マシン上のワークメモリに読み出すことができるので、 ァ プリケーシヨンの起動'終了が頻繁になされたとしても、スムーズなアプリケ一シ ョン実行を実現することができる。

次に、 読込属性について説明する。

図 2において Javaアーカイブフアイルほ、 AVClipとは別の記録領域に記録さ れることを前提にしていた。 しかしこれは一例に過ぎない。 Javaアーカイブファ ィルは、 BD-ROMにおいて AVClipが占める記録領域に埋め込まれることがある。 この埋め込みの態様には、 カル一セル化、 インターリーブユニット化という 2種 類がある。

ここで" カルーセル化" とは、 対話的な放送の実現のために同一内容を繰り返 しするという放送方式に変換することである。 BD-ROM は、 放送されたデータ を格納するものではないが、 本実施形態では、 カルーセルの放送形式に倣って JAVA アーカイブファイルを格納するようにしている。 図 4 2は、 カル一セル化 による Javaアーカイブファイル埋め込みを示す図である。 第 1段目は、 AVClip 中に埋め込む Javaアーカイブファイルであり、 第 2段目は、 セクション化を示 す。 第 3段目は、 TSバケツト化、 第 4段目は、 AVClipを構成する TSバケツト 列を示す。 こうしてセクション化、 TSバケツト化されたデータ（図中の" D" )が、 AVCli に埋め込まれるのである。カルーセルにより AVClipに多重化された Java アーカイブファイルは、読み出すにあたって、低帯域で読み出されることになる。 この低帯域での読み出しは、 概して 2〜3分というように長期間を要するため、 再生装置は Javaアーカイブファイルを 2〜3分をかけて読み込むことになる。 図 4 3は、 ィンターリーブ化による Javaアーカイブファイル埋め込みを示す 図である。 第 1段目は、 埋め込まれるべき AVClip、 第 2段目は、 AVClipにイン タ一リ一ブ化された Javaアーカイブファイル、第 3段目は、 BD-ROMの記録領 域における AVClip配置である。 本図に示すように、 ストリームに埋め込まれる べき Java アーカイブファイルは、 インターリーブ化され、 AVClip を構成する XXXXX.m2ts を構成する分割部分 (図中の AVClip2/4,3/4)の合間に記録される。 インタ一リ一ブ化により AVClipに多重化された Javaアーカイブフアイルは、力 ルーセル化と比較して、 高い帯域で読み出されることになる。 この高い帯域での 読み出しであるため、 再生装置は Javaアーカイブフアイルを比較的短期間に読 み込むことになる。

カル一セル化'インターリーブ化された Javaアーカイブファイルは、 プリ口一 ドされるのではない。 BD-ROMにおける AVClipの記録領域のうち、 カルーセル ィ匕 'インターリーブ化された Javaアーカイブファイルが埋め込まれた部分に、現 在の再生時点が到達した際、 再生装置のローカルメモリ 2 9にロードされる。 Javaアーカイブファイルの記録態様には、 図 2に示すものの他に、 図 4 2、 図 4 3 ( a ) に示すものがあるので、 読込属性は、 図 4 3 ( b ) に示すように、 設定 されうる。 図 4 3 ( b ) に示すように、 読込属性は、 タイトル再生に先立ち、 口 一カルメモリ 2 9に読み込まれる旨を示す" Preload" と、 タイ トル再生中に、 カルーセル化方式で読み込まれる旨を示す" Load. Carousel" と、 タイ トル再生 中に、 インターリーブ化方式で読み込まれる旨を示す" Load.InterLeave" とが ある。 読込属性には、 カル一セル化されているか、 インターリーブ化されている かが添え字で表現されているが、 これを省略してもよい。

データ管理テーブルにおける生存区間の具体的な記述例について、 図 4 4を参 照しながら説明する。 図 4 4 ( a ) は、 データ管理テーブルの一例を示す図であ 2004/015330 る。 図 4 4 ( b ) は、 かかるデータ管理テーブルの割り当てによるローカルメモ リ 2 9の格納内容の変遷を示す図である。 本図は、 縦軸方向にローカルメモリ 2 9における占有領域を示し、横軸を、 1つのタイトル内の PL時間軸としている。 データ管理テーブルにおいて application#lは、 1つのタイ トル内の PL時間軸全 体を生存区間とするよう記述されているので、 このタイ トルの Chapter#l〜 C aptei#5においてローカルメモリ 2 9内の領域を占有することになる。 データ 管理テーブルにおいて application#2は、タイトル内の PL#1における Chapter#l ~ Chapter を生存区間とするよう記述されているので、 このタイ トルの Cliapter#l〜Cliapter#2においてローカルメモリ 2 9内の領域を占有することに なる。 データ管理テーブルにおいて application#3は、 タイトル内の PL#1にお ける Chapter#4~Chapter#5を生存区間とするよう記述されているので、このタ ィトルの Chapter#4〜Chapter#5 においてローカルメモリ 2 9内の領域を占有 することになる。 以上で、 データ管理テーブルにおける生存区間についての説明 を終える。 続いて読込優先度について説明する。 読込優先度とは、 ローカルメモリ 2 9へ の読み込みに対する優劣を決める優先度である。読込優先度には複数の値がある。 2段階の優劣を設けたい場合、 Mandatoryを示す値、 optionalを示す値を読込優 先度に設定する。 この場合、 Mandatory は高い読込優先度を意味し、 optional は、 低い読込優先度を意味する。 3段階の優劣を設けたい場合、 Mandatoryを示 す値、 optional:high、 optional:lowを示す値を読込優先度に設定する。 Mandatory は、 最も高い読込優先度を示し、 optional:high は、 中程度の読込優先度、 optional:lowは、 最も低い読込優先度を示す。 データ管理テーブルにおける読込 優先度の具体的な記述例について、 図 4 5 ( a ) ( b ) を参照しながら説明する。 この具体例で、 想定しているローカルメモリ 2 9のメモリ規模は、 図 4 5 ( a ) に示すようなものである。 図 4 5 ( a ) は、 新旧再生装置における口一カルメモ リ 2 9のメモリ規模を対比して示す図である。 矢印 mkl は旧再生装置における メモリ規模を、 矢印 mk2 は新再生装置におけるメモリ規模をそれぞれ示す。 こ の矢印の対比から、 新再生装置におけるローカルメモリ 2 9のメモリ規模は、 旧 再生装置のそれと比較して、 三倍以上である状態を想定している。 このようにメ モリ規模にバラツキがある場合、 アプリケーションは、 図 4 5に示すような 2つ のグループに分類される。 1つ目は、 どのようなメモリ規模であっても読み込む んでおくべきアプリケーション (#1,#2)である。 2つ目は、 旧再生装置での読み込 みは望まないが、新再生装置での読み込みは希望するアプリケ一ション (#3，#4)で ある。 読み込もうとするアプリケーションが、 これら 2つのグループに分類され れば、 前者に帰属するァプリケーシヨンに、 読込優先度 -Mandatoryを設定し、 後者に属するアプリケーションに、読込優先度 -Optionalを設定する。図 4 5 ( b ) は、 読込優先度が設定されたデータ管理テーブルの一例を示す図である。 データ 管理テーブルをこのように設定した上で、 application#l〜 application#4 を BD-ROM に記録すれば、 あらゆるメモリ規模の再生装置での再生を保証しつつ も、 メモリ規模が大きい再生装置では、 より大きなサイズのデータを利用したァ プリケーシヨンを再生装置に再生させることができる。

以上は本実施形態における記録媒体に対する改良である。 続いて本実施形態に おける再生装置に対する改良について説明する。 上述した記録媒体の改良に対応 するため、 アプリケーションマネージャ 3 6は図 4 6に示すような処理手順で処 理を行う。

図 4 6は、 アプリケーションマネージャ 3 6によるプリロード制御の処理手順 を示す図である。 本フローチャートは、 再生すべきタイトルにおけるデータ管理 テーブルを読み込み（ステップ S 1 1 1 )、 データ管理テーブルにおいて最も高い 読込優先度をもちつつ、 applicationID が最も小さいアプリケーションをアプリ ケーシヨン iにした上で (ステップ S 1 1 2)、 ステップ S 1 1 3、ステップ S 1 1 4の判定を経た上で、 アプリケーション iをローカルメモリ 2 9にプリロードす る（ステップ S 1 1 5)という処理を、ステップ S 1 1 6が No及びステップ S 1 1 7が Noと判定されるまで、 繰り返すというループ処理を構成している。

ステップ S 1 1 3は、 アプリケーション iの読込属性がプリロードであるか否 かの判定であり、 ステップ S 1 1 4は、 アプリケーショ ンの読込優先度が =Mandatoryであるか Optionalであるかの判定である。 ステップ S 1 1 3にお いてプリロードと判定され、ステップ S 1 1 4において読込優先度が Mandatory と判定されれば、 アプリケーションはローカルメモリ 2 9にプリ口一ドされるこ とになる（ステップ S I 1 5 )。 もしステップ S 1 1 3において読込属性がロード 4 015330 であると判定されれば、 ステップ S 1 1 4〜ステップ S 1 1 5はスキップされる ことになる。

ループ処理の終了要件を規定する 2 つのステップのうちステップ S 1 1 6は、 applicationIDが次に高く、アプリケーション iと同一読込優先度のァプリケ一シ ヨン kが存在するか否かを判定するものである。 そのようなアプリケーション k が存在するなら、そのアプリケーション kをアプリケーション iにする（ステップ

ループ処理の終了要件を規定する 2 つのステップのうちステップ S 1 1 7は、 データ管理テーブルにおいて次に低い読込優先度をもつアプリケーションが存在 するか否かの判定であり、 もし存在すれば、 その次に低い読込優先度をもつアブ リケーションのうち、 最も小さい applicationIDをアプリケ一シヨン kを選んで (ステップ S 1 1 8)、 そのアプリケーション kをアプリケーション iにする（ステ ップ S 1 1 9)。 これらステップ S 1 1 6、 ステップ S 1 1 7が Yesになっている 限り、 上述したステップ S 1 1 3〜ステップ S 1 1 5の処理は繰り返されること になる。 ステップ S 1 1 6、 ステップ S 1 1 7において、 該当するアプリケーシ ョンが無くなれば本フローチヤ一卜の処理は終了することになる。

ステップ S 1 2 0〜ステップ S 1 2 3は、 ステップ S 1 1 4において読込優先 度 =Optionalであると判定された場合に、 実行される処理である。

ステップ S 1 2 0は、 同じ applicationIDをもち、 読込優先度が高いァプリケ ーシヨン； jが存在するか否かの判定である。

ステップ S 1 2 1は、 口一カルメモリ 2 9の残り容量がアプリケーション iの サイズを上回るか否かを判定するステップである。 ステップ S 1 2 0が No、 ス テツプ S 1 2 1が Yesである場合、 ステップ S 1 1 5においてアプリケーション iが口一カルメモリ 2 9にプリロードされることになる。ステップ S 1 2 0が No、 ステップ S 1 2 1が Noである場合、 アプリケーション iはローカルメモリ 2 9 にプリロードされずそのままステップ S 1 1 6に移行することになる。

こうしておくと、読込優先度 = Optionalのデータは、 ステップ S 1 2 0—ステ ップ S 1 2 1の判定が Yesにならないと、 ローカルメモリ 2 9へのプリロードが なされない。 メモリ規模が小さい旧再生装置は、 2~3個のアプリケーションを読 み込んだ程度で、 ステップ S 1 2 1の判定は Noになるが、 メモリ規模が大きい 新再生装置は、 更に多くのアプリケーションを読み込んだとしても、 ステップ S 1 2 1の判定は Noにならない。 以上のように、 旧再生装置では、 口一カルメモ リ 2 9に Mandatoryのアプリケ一ションのみが読み込まれ、 新再生装置には、 Mandatory のアプリケーションと、 Optional のアプリケーションとが読み込ま れることになる。

ステップ S 1 2 2は、 ステップ S 1 2 0において Yesと判定された場合に実行 されるステップである。 同じ applicationlDをもち、 読込優先度が高いアプリケ —シヨン jがローカルメモリ 2 9上に存在する場合、 口一カルメモリ 2 9の残り 容量と、 アプリケーション ; jのサイズとの和が、 アプリケーション iのサイズを 上回るか否かを判定し（ステップ S 1 2 2)、 もし上回れば、 アプリケーション i を用いてローカルメモリ 2 9上のアプリケーション ; jを上書きすることによりプ リロ一ドする（ステップ S 1 2 3 )。下回る場合は、アプリケーション iはローカル メモリ 2 9にプリロードされずそのままステップ S 1 1 6に移行することになる。 ステップ S 1 1 5、 ステップ S 1 2 3による読込処理の一例を、 図 4 7 ( a ) を参照しながら説明する。 図 4 7 ( a ) は、 この具体例が想定しているデータ管 理テ一ブルの一例を示す図である。 本図における 3つのアプリケーションは、 そ れぞれ 3 つのファイルに格納されており、 applicationlD は同じであるが (applicationlD^l) 、 読 込 優 先 度 は 互 い に 異 な る (mandatory，optional:high，optional:low)₀ こっしたデータ管理テ一ブルが処理メォ 象であると、 ステップ S 1 1 5により、読込優先度 = Mandatoryのアプリケーシ ョンは口一カルメモリ 2 9に読み込まれる。 しかし読込優先度 = Optionalのァプ リケ一シヨンについては、 ステップ S 1 2 0〜ステップ S 1 2 2の判定を経た上 で、 ステップ S 1 2 3において読み込まれる。 ステップ S 1 1 5と違いステップ S 1 2 3では、 既にローカルメモリ 2 9にある同じ applicationlDのアプリケ一 シヨンを上書きしてゆくよう、 プリロードがなされるので、 複数アプリケ一ショ ンのうち 1つが排他的に、 ローカルメモリ 2 9にロードされることになる。

0読込優先度 = mandatoryのアプリケーションを読み込んだ後、 読込優先度 = optional: igh のアプリケーションを読み込むにあたって、 ステップ S 1 2 2が Noと判定されればれば、 読込優先度 = mandatoryのアプリケーションが口一力 ルメモリ 2 9に残ることになる。読込優先度 -mandatoryのアプリケーションを 読み込んだ後、読込優先度 =optional:highのアプリケ一ションを読み込むにあた つて、 ステップ S 1 2 2が Yesと判定されれば、

のァ プリケーシヨンにより、読込優先度 = mandatoryのアプリケ一ションは上書きさ れ、読込優先度 =optional:highのアプリケーションがローカルメモリ 2 9に残る ことになる。

.ii)読込優先度 =optional:highのアプリケーションを読み込んだ後、読込優先度 = optional:lowのアプリケーションを読み込むにあたって、 ステップ S 1 2 2が Noと判定されればれば、 読込優先度 = Mandatoryのアプリケーションがロー力 ルメモリ 2 9に残ることになる。読込優先度 = optional:highのアプリケーション を読み込んだ後、 読込優先度 =optional:lowのアプリケーションを読み込むにあ たって、 ステップ S 1 2 2が Yesと判定されれば、 読込優先度 =optional:lowの アプリケーションにより、読込優先度 = optional:highのアプリケーションは上書 きされ (ステップ S 1 2 3 )、 読込優先度 =optional:low のアプリケーションが口 —カルメモリ 2 9に残ることになる。

口一カルメモリ 2 9の容量が許す限り、 口一カルメモリ 2 9上のアプリケーシ ョンを上書きしてゆくとの処理が繰り返されるので、 ローカルメモリ 2 9の格納 内容は、 図 4 7 ( b ) に示すよつに、 mandatory =optional:high=>optional:low と遷移してゆくことになる。 メモリ規模に応じて、 サイズが異なる Javaァ一力 イブファイルをローカルメモリ 2 9にロードすることができるので、 メモリ規模 • が小さい再生装置については、 必要最小限の解像度をもったサムネール画像を有 する Javaアーカイブファイルを、 メモリ規模が中程度の再生装置については、 中程度の解像度をもった SD画像を有する Javaァーカイブファィルを、 メモリ 規模が大規模である再生装置については、 高解像度をもった HD 画像を有する Javaアーカイブファイルをローカルメモリ 2 9にロードすることができる。かか るロードにより、 メモリ規模に応じて解像度が異なる画像を表示させることがで き、 ォーサリング担当者によるタイトル制作の表現の幅が広がる。 図 4 8は、 データ管理テーブルを参照した読取処理の具体例を示す図である。 本図における 2つのアプリケーションは、 同じ applicationID(application#3)が 付与された 2 つのアプリケーションを示す図である。 そのうち一方は、 AVClip 中に埋め込まれていて、 読込優先度が mandatory に設定されている。 他方は、 AVClipとは別フ 7ィルに記録されていて、 読込優先度が Optionalに設定されて いる。 前者のアプリケーションは、 AVClip に埋め込まれているので、 その埋込 部分にあたる生存区間が、 生存区間 (title#l:chapter#4〜#5)として記述されてい る。 これらのアプリケーションのうち application#2、 application#3には、 ロー ドを示す読込属性が付与されている。 application#2 は Chapter#l〜Chapter#2 を生存区間にしており、 application#3は Chapter#4〜Chaptei#5を生存区間に しているので、 タイトル時間軸においてどちらか一方が排他的に口一カルメモリ 2 9上に常駐することになる。 図 4 8 ( b ) は、 タイトル時間軸上の別々の時点 において、 排他的に格納される application#2、 application#3 を示す図である。 これは必要最低限のメモリ規模しかもたない再生装置での再生を念頭に置いた配 慮である。 こうした内容のデ一タ管理テーブルが処理対象であるとアプリケーシ ョンマネージャ 3 6は、 上述した図 4 6のフローチャートによりメモリ規模に応 じて異なる処理を行う。

後者のアプリケーションは、 読込優先度 =ロードであるので、 口一カルメモリ 2 9にロードされる。 かかる処理により、 Mandatoryなメモリ規模さえあれば、 アプリケーシヨンマネージャはデータをローカルメモリ 2 9にロードすることが できる。 ここで問題になるのは、 メモリ規模が大きい再生装置による読み込み時 である。 メモリ規模が大きいにも拘らず、 Chapter#4〜Chapter#5に到達するま で application#3を読み込めないというのは、 メモリ規模の無駄になる。 そこで 本図のデータ管理テーブルには、 同じ application#3にプリ口一ドを示す読込属 性を付与して BD-ROMに記録しておき、 これらに同じ applicationIDを付与し ている。

前者のアプリケーションは、読込優先度 =Optionalであるので、 ステップ S 1 2 1が Yesになった場合に限り、 プリロードされる（ステップ S 1 1 5 )。 こうす ることで、 メモリ規模が大きい再生装置は、 title#l、 Chapter#4〜Chapter#5の 到達を待つことなく、 AVClip に埋め込まれているのと同じアプリケーションを ローカルメモリ 2 9にロードすることができるのである (図 4 8 ( c ) )。

以上がプリロード時における処理である。 続いてロード時における処理手順に ついて説明する。

図 4 9は、データ管理テーブルに基づくロード処理の処理手順を示す図である。 本フローチャートは、 ステップ S 1 3 1〜ステップ S 1 3 3からなるループ処理 を、 タイ トル再生が継続されている間、 繰り返すというものである。

ステップ S 1 3 1は、 AutoRunを示す起動属性を有したアプリケーションの生 存区間が到来したか否かの判定である。 もし到来すれば、 AutoRunを示す起動属 性を有したアプリケーションをアプリケーション qにして（ステップ S 1 3 4)、 アプリケーション qを起動する旨の起動指示を Java仮想マシン 3 8に発行して、 アプリケーション qをローカルメモリ 2 9からワークメモリ 3 7に読み出させる (ステップ S 1 3 5)。

ステップ S 1 3 3は、 タイトル内 PLの再生が全て終了したかの判定である。 この判定は、 第 5実施形態に示したように、 Playback Control Engine 3 2から の再生終結イベントがあつたか否かでなされる。 もし終了すれば、 本フローチヤ —トの処理を終了する。

ステップ S 1 3 2は、 起動中アプリケーションからの呼出があつたか否かの判 定である。 もしあれば、呼出先アプリケーションをアプリケーション qにして（ス テツプ S 1 3 6)、 現在の再生時点は、 アプリケーション管理テ一ブルにおける アプリケーション qの生存区間であるか否かを判定する（ステップ S 1 3 7)。 も し生存区間でなければ、 起動失敗を表示して (ステップ S 1 4 8)、 ステップ S 1 3 1〜ステップ S 1 3 3からなるループ処理に戻る。 生存区間であれば、 図 5 0 のフローチャートに従い、 ロード処理を行う。

図 5 0におけるステップ S 1 3 8は、 現在の再生時点がデータ管理テーブルに おけるアプリケーシヨン qの生存区間であるか否かを示す判定である。 もし生存 区間でなければ、 アプリケーション qはローカルメモリ 2 9にロードすることが できない。 この場合、 アプリケーション qを起動する旨の起動指示を Java仮想 マシン 3 8に発行し、 ローカルメモリ 2 9を介することなく、 直接アプリケ一シ ヨン qを BD-ROMからワークメモリ 3 7に読み出させる。 この場合アプリケー シヨンを読み出すためのへッドシークが発生するから、 PL再生は中断すること になる（ステップ S 1 4 5)。

もし生存区間であれば、 ステップ S 1 3 9において、 アプリケーションには読 込属性が付加されているか否かを判定する。 読込属性がないということは、 アブ リケ一シヨン qは、 カルーセル化、 若しくはインターリーブ化されていないこと を意味する。 しかし読込属性が付加されていなくても、 口一カルメモリ 2 9にァ プリケ一シヨン qを置くことは許される。 そこで再生中断を承知の上、 アプリケ . ーシヨンの読み出しを行う。 つまり BD-ROMから口一カルメモリ 2 9へとァプ リケーシヨンを読み出した上で、 アプリケーションをワークメモリ 3 7に読み出 す (ステップ S 1 4 0)。

ステップ S 1 4 1〜ステップ S 1 4 6は、 ステップ S 1 3 9が Yesと判定され た場合になされる処理である。 ステップ S 1 4 1では、 読込属性を参照すること で、 アプリケーションがプリロードされているか否かを判定する。 プリロードさ れていれば、 ステップ S 1 3 5に移行する。

ステップ S 1 4 2は、 読込属性がロードである場合に実行される判定ステップ であり、 アプリケーション qがカルーセル化されているか、 インターリーブイ匕さ れているかを判定する。 インターリーブ化されていれば、 キャッシュセンスを Java仮想マシン 3 8に実行させる（ステップ S 1 4 3)。 口一カルメモリ 2 9にァ プリケーシヨン qが存在すれば、 ステップ S 1 3 5に移行して、 アプリケーショ ,ン qを Java仮想マシン 3 8にロードさせる。

ローカルメモリ 2 9にアプリケーションがなければ、 トップメニュータイ トル に分岐する等の例外処理を行う（ステップ S 1 4 4)。 カルーセル化されていれば、 タイマをセットし（ステップ S 1 4 8)、 そのタイマがタイムァゥトするまで (ステ ップ S 1 4 7)、キャッシュセンスを Java仮想マシン 3 8に実行させる（ステップ S 1 4 6)。 もしローカルメモリ 2 9にアプリケ一ション qが出現すれば、 図 4 9 のステップ S 1 3 5に移行して、 アプリケーション qを Java仮想マシン 3 8に ロードさせる。 タイムアウトすれば、 トップメニュータイトルに分岐する等の例 外処理を行う（ステップ S 1 4 4)。

図 5 1は、 Java仮想マシン 3 8によるアプリケーシヨンの読み込みがどのよう にして行われるかを模式ィ匕した図である。

矢印 ©1,2 は、 アプリケーション管理テーブルに生存していて、 データ管理テ 一ブルに生存しており、カルーセル化，ィンターリーブ化を示す読込属性が存在す る Javaアーカイブファイルの読み込みを示す。 矢印 ©1は、 ステップ S 6 5、 6 7においてなされる口一カルメモリ 2 9センスを示す。 この口一カルメモリ 2 9センスは、 カルーセル又はインターリーブ化により埋め込まれたデータが、 口 一カルメモリ 2 9に存在するかもしれないため口一カルメモリ 2 9内をセンズす るというものである。矢印 ©2は、ステップ S 1 3 5に対応する読み込みであり、 アプリケーションがローカルメモリ 2 9に存在していた場合の、 ローカルメモリ 2 9からワークメモリ 3 7へのロードを示す。 X付きの矢印は、 ローカルメモリ 2 9にデータがない場合を示す。

矢印 Vl，2 は、 アプリケーション管理テーブルに生存しているが、 データ管理 テーブルに生存しておらず、 読込属性が存在しない Javaアーカイブファイルの 読み込みを示す。

矢印 VIは、 ステップ S 1 4 5における読み込みに対応するものであり、 Java 仮想マシン 3 8による BD-ROMからのダイレクトリ一ドの要求を示す。矢印 V2 はその要求による、 BD-ROMからワークメモリ 3 7への Javaアーカイブフアイ ル読み出しを示す。

矢印 1,2，3は、 アプリケーション管理テーブルに生存していて、データ管理テ 一ブルに生存しているが、 読込属性が存在しない Javaアーカイブファイルの読 み込みを示す。

矢印 1は、 ステップ S 1 4 0における読み込みに対応するものであり、 Java 仮想マシン 3 8による BD-ROMからのダイレクトリードの要求を示す。矢印 2 はその要求による、 ローカルメモリ 2 9への Javaアーカイブファイルの読み出 しを示す。 矢印 3 は口一カルメモリ 2 9からワークメモリ 3 7への Javaァ一 カイプフアイルの読み出しを示す。

以上のように本実施形態によれば、 ローカルメモリ 2 9上で同時に常駐される アプリケーションの数が所定数以下になるように規定しておくことができるので、 ローカルメモリ 2 9からの読み出し時におけるキャッシュミスを極力回避するこ とができる。 キャッシュミスのないアプリケーシヨン読み出しを保証することが できるので、アプリケーション呼出時にあたては、 AVClipの再生を止めてまで、 BD-ROMからアプリケーションを読み出すことはなくなる。 AVClip再生を途切 れさせないので、 AVClipのシームレス再生を保証することができる。

(第 7実施形態） 30 第 3実施形態では、 非 AV系タイ トルの時間軸をアプリケーションの生存区間 に基づき定めることにした。 しかしアプリケーションの動作というのは不安定で あり、 起動の失敗や異常終了がありうる。 本実施形態は、 起動失敗、 異常終了が あった場合の Fail Safe機構を提案するものである。 図 5 2 ( a ) は、 第 7実施 形態に係る BD-Jオブジェクトの内部構成を示す図である。 図 7 (b ) と比較し て本図が新規なのは、 プレイリスト管理テーブルが追加されている点である。 図 5 2 (b ) は、 プレイリスト管理テーブルの一例を示す図である。 本図に示 すようにプレイリスト管理テーブルは、 PLの指定と、その PLの再生属性とから なる。 PL の指定は、 対応するタイ トルのタイ トル時間軸において、 再生可能と なる PLを示す。 PLの再生属性は、 指定された PLを、 タイ トル再生の開始と同 時に自動再生するか否かを示す (こうして自動再生される PLをデフオルト PLと いう)。

次にプレイリスト管理テ一ブルによりタイ トル時間軸がどのように規定される かを、 図 5 3を参照しながら説明する。 図 5 3 ( a ) は、 再生属性が非自動再生 を示すよう設定された場合の非 AV系タイ トルにおけるタイ トル時間軸を示す図 である。 この場合、デフォルト PLは再生されないから、非 AV系タイトル同様、 アプリケ一ションの生存区間からタイ トル時間軸が定まる。

図 5 3 ( b ) は、 再生属性が AutoPlayに設定された非 AV系タイトルのタイ トル時間軸を示す図である。 再生属性が AutoPlay を示すよう設定されれば、 Playback Control Engine 3 2は非 AV系タイトルの再生開始と同時に、デフオル ト PLの再生を開始する。 しかしアプリケーションが正常に動作し、 正常終了し たとしても、 このタイ トル時間軸は、 PL時間軸を基準にして定められる。

図 5 3 ( c ) は、 プレイリスト管理テーブルにおいて再生属性が" AutoPlay" を示すよう設定され、 アプリケーションが異常終了した場合を示す。 かかる異常 終了により、どのアプリケーションも動作してない状態になるが、デフォルト PL の再生は継続する。 この場合も、 デフォルト PLの PL時間軸がタイトル時間軸 になる。

図 5 3 ( d ) は、 プレイリスト管理テーブルにおいて再生属性が" AutoPlay" を示すよう設定され、メインアプリの起動に失敗したケースを示す。この場合も、 Playback Control Engine 3 2によるデフォルト PL再生は、アプリケーションの 15330 起動失敗とは関係なしに行われるので、 デフォルト PLの時間軸がタイ トル時間 軸になる。

以上のようにプレイリスト管理テーブルの再生属性を、" AutoPlay" に設定し ておけば、 Javaアプリケーションの起動に、 5〜10秒という時間がかかったとし ても、 その起動がなされている間、" とりあえず何かが写っている状態" になる。 この" とりあえず何かが写っている状態" によりタイトル実行開始時のスタート アップディ レイを補うことができる。

以上は本実施形態における記録媒体に対する改良である。 続いて本実施形態に おける再生装置に対する改良について説明する。

図 5 2 ( c ) は、 分岐先タイトルのプレイリスト管理テーブルにおいて、 再生 属性が AutoPlayに設定された PLが存在する場合、 再生装置がどのような処理 を行うかを示す図である。 本図に示すように、 再生属性が AutoPlayに設定され た PLが、分岐先タィ トルのプレイリスト管理テーブルに存在すれば、 BD-Jモジ ユール 3 5内のアプリケーシ 3ンマネージャ 3 6は、 タイ トル分岐直後にこの AutoPlayPLの再生を開始するよう Playback Control Engine 3 2に指示する。 このように再生属性が AutoPlayの PLは、 タイトル分岐直後に再生開始が命じ られることになる。

上述した記録媒体の改良に対応するため、 アプリケーションマネージャ 3 6は 図 5 4に示すような処理手順で処理を行う。

図 5 4は、 第 7実施形態に係るアプリケーションマネージャ 3 6の処理手順を 示すフローチャートである。 本フローチャートは、 図 3 8のフローチャートにお いてステップ S 2 1の前にステップ S 1 0 3、 ステップ S 1 0 4を追加し、 ステ ップ S 2 1と、 ステップ S 2 2との間にステップ S 1 0 0を追加し、 ステップ S 2 3 _ステップ S 2 6間に、 ステップ S 1 0 5を追加したものである。

ステップ S 1 0 3は、 対応するタイトルのプレイリスト管理テーブルの再生属 性が AutoPlayであるか否かの判定である。 もし AutoPlayなら、 デフォルト PL に対する再生制御を Playback Control Engine 3 2に開始させる（ステップ S 1 0 4)。

ステップ S 1 0 0は、 Presentation Engine 3 1による再生中であるか否かを 判定する。 もし再生中であるなら、 ステップ S 1 0 1に移行する。 ステップ S I 0 5は、 ステップ S 2 3が Yes、 ステップ S 2 5が Noである場 合に実行される判定ステップであり、再生属性が AutoPlayであるか否かを示す。 もし否であるなら、 タイ トル終了をモジュールマネージャ 3 4に通知する。 もし AutoPlayであるなら、 ステップ S 1 0 1に移行して、 処理 ¾継続する。

図 5 5は、 プレイリスト管理テーブルにおいて" 再生属性 = AutoPlay" に設定 されることにより、 どのような再生が行われるかを模式化した図である。 ここで 再生すべきタイトルは、 落下するタイル片を積み重ねるというゲームアプリを含 む非 AV系タイ トルである。 この非 AV系タイ トルにおいて、 プレイリスト管理 テーブルの再生属性が AutoPlayに設定されていれば、 Playback Control Engine 3 2によるデフォルト PL再生も開始する。 ゲームアプリの実行と、 デフォルト PL再生とが並列的になされるので、 図 5 5の上段の左側に示すように、 前景を ゲームアプリの画面とし、 背景をデフォルト PLの再生画像とした合成画像が表 示されることになる。 このゲームアプリは途中で異常終了したとする。 ゲームァ プリはアプリケーションマネージャ 3 6により強制終了させられるが、 デフオル ト PLの再生が継続してなされるため、 タイ トルは、 何かが写っている状態にな る。このようなプレイリスト管理テーブルにおける再生属性の指定により、非 AV 系タイトル内のゲームアプリが異常終了した場合でも、 ハングアップやブラック ァゥトがない動作を維持することができる。

(第 8実施形態）

第 1実施形態において BD-Jオブジェクトは、 データ管理テーブル、 アプリケ ーシヨン管理テーブルという 2 つのテーブルを具備していたが、 本実施形態は、 これらを 1つのテーブルに統合するという形態を開示する。 かかる統合にあたつ て、 図 5 6 ( a ) に示すように、 データ管理テーブルにおける読込属性という項 目を廃し、 代わりに起動属性に Ready属性という属性を設ける。 Ready属性と は、 他のアプリケーションからの呼出又はアプリケーションマネージャ 3 6から の呼出に備えて、 口一カルメモリ 2 9に予めアプリケーシヨンをロードしておく 旨を示す起動属性の類型である。

図 5 6 ( b ) は、 アプリケーションの扱いと、 起動属性との関係を示した図で ある。 第 1実施形態に示したようにアプリケーションの扱いには、 プリロードさ れるか否か (1)、 現在の再生時点が有効区間に到来した際自動的に起動されるか、 P T/JP2004/015330 他からの呼出に応じて起動されるか (2)、 タイ トル再生進行に従ってロードされる か (3)、 生存しているかという違いがあり、 これらの違いにより、 図 5 6 ( b ) に 示すような 5つの態様が出現する。 このうち起動属性が AutoRunに設定される のは、 プリロードがなされ、" 自動起動" である場合、 及び、 ロードがなされ、" 自動起動" である場合である。

一方、 起動属性が Ready属性に設定されるのは、 プリロード、 又は、 ロードが なされ、 起動項目が" 呼出起動" を示している場合である。

尚、 ワークメモリ 3 7では生存している力 口一カルメモリ 2 9にはロードさ れない" との類型が存在し得ない。 これは、 アプリケーション 'データ管理テープ ルでは、 ワークメモリ 3 7の生存区間と、 ローカルメモリ 2 9の生存区間とがー 体だからである。

起動属性として、 この Ready属性を追加されたので、 アプリケーションマネー ジャ 3 6はタイ トル再生に先立ち、 起動属性が AutoRunに設定されたアプリケ —シヨン、及び、起動属性が Ready属性に設定されたアプリケーションをロー力 ルメモリ 2 9にプリロードするとの処理を行う。 こうすることにより、 読込属性 を設けなくても、 アプリケーションをローカルメモリ 2 9にプリ口一ドしておく との処理が可能になる。

図 5 7は、 第 8実施形態に係る Java仮想マシン 3 8によるアプリケーション の読み込みがどのようにして行われるかを模式化した図である。 本図における読 み込みは、 図 5 1をベースにして作図している。

矢印 ©1，2は、 アプリケーション 'データ管理テーブルに生存していて、 起動属 性が Ready属性に設定されている Javaアーカイブファイルの読み込みを示す。 矢印 1，2,3は、 アプリケーション 'データ管理テーブルに生存していおり、 起 動属性が Persistentであるアプリケーションの読み込みを示す。

これらの矢印 ©1,2、 矢印 1，2,3は、 図 5 1でも記述されていたものだが、 図 5 1に記述していた、 Vl,2 の矢印に該当する読み込み" は、 図 5 7では存在し ない。 これは、 アプリケーション 'データ管理テーブルは、 アプリケーション管理 テーブル、 データ管理テーブルを一体化したものなので、 アプリケーション管理 テーブル =生存、 データ管理テーブル =非存在という組合せは表現し得ないから である。 以上のように本実施形態によれば、 データ管理テーブル、 アプリケーション管 理テーブルを 1つのテーブル (アプリケーション 'データ管理テーブル)にまとめる ことができるので、 アプリケーシヨンマネージャ 3 6による処理を簡略化するこ とができる。尚、読込優先度をなくすことによりアプリケーション'データ管理テ 一ブルをより簡略化にしても良い。

(第 9実施形態）

第 1実施形態では、 アプリケーションをローカルメモリ 2 9に読み込むにあた つて、 読込優先度を参照して、 この読込優先度に従い、 読み込み処理に優劣を与 えた。 これに対し第 9実施形態は、 Optionalを意味する情報と、 0から 255まで の数値との組合せにより読込優先度を表す実施形態である。

図 5 8 ( a ) ( b ) は、 第 9実施形態に係る読込優先度の一例を示す図である。 255、 128 は、 0 から 255 までの読込優先度の一例であり、 本例における application#2は、 application#3より読込優先度が高いことを意味する。

本実施形態においてアプリケーシヨンマネージャ 3 6は、 第 1実施形態同様、 先ず Mandatoryを示す読込優先度が付与されたアプリケーションを口一カルメ モリ 2 9に読み込む。

その後、 Optionalを示す読込優先度が付与されたアプリケーションに対しては、 口一カルメモリ 2 9における容量が、 アプリケーションのサイズを上回るか否か を判定する。 もし上回るなら、読込優先度 Optionalが付与されたアプリケーシ ヨンをそのままローカルメモリ 2 9に読み込む。 もし下回るなら、 アプリケーシ ョンを構成するデータのうち、 読込優先度を表す数値が高いアプリケーションを ローカルメモリ 2 9に読み込む。 そして、 ローカルメモリ 2 9における残りの領 域に、 読込優先度を表す数値が低いアプリケーションを読み出す。 こうすることで Optional扱いのアプリケーションについては、 全体を格納す る容量が再生装置のローカルメモリ 2 9になくても、 その一部分をローカルメモ リ 2 9に格納しておくことができる。

(第 1 0実施形態）

第 1実施形態においてアプリケーションマネージャ 3 6は、同じ applicationID が付与されたアプリケーションを、 読込優先度に従い排他的にローカルメモリ 2 9にロードするとしたが、 第 1 0実施形態は、 アプリケーションにグループ属性 を与えることにより、 排他的なロードを実現する。 図 5 9は、 グループ属性が付 与されたデータ管理テーブルを示す図である。 グループ属性には、 排他グループ なし、 排他グループあり、 といった、 2通りの設定が可能であり、 排他グループ ありの場合、 そのグループ番号が記述される。 図 5 9 ( a ) における title#l の 「一」は、排他グループが存在しないことを示す。一方、 title#2,#3の「group#l」 は、 排他グループがあり、 title#2,#3 は、 group#l という排他グループに帰属し ていることを示す。 以上が本実施形態に係る記録媒体の改良である。

本実施形態に係る再生装置は、 データ管理テーブルに基づいて各アプリケ一シ ヨンをローカルメモリ 2 9に読み込んだ後、 ローカルメモリ 2 9のアプリケ一シ ョンにおけるグループ属性をベリフアイする。 同じ排他グループに帰属するアブ リケーシヨンが、 ローカルメモリ 2 9上に 2つ以上存在していれば、 そのうち一 方をローカルメモリ 2 9から削除する。

こうすることにより、 ローカルメモリ 2 9の利用効率を向上させることができ る。 排他グループの具体例としては、 ランチャーアプリと、 このアプリにより起 動されるアプリとからなるグループが相応しい。 本アプリケーションにより起動 されるアプリケーションは、原則 1つに限られるので、ローカルメモリ 2 9には、 ランチャー + 1個のアプリケーションのみが存在する箦である。 もし 3つ以上の アプリケーションが存在していれば、 これをローカルメモリ 2 9から削除すると いう処理をアプリケーションマネージャ 3 6は行う必要があるので、 各アプリケ ーシヨンのグループ属性を設け、 ローカルメモリ 2 9上で存在するアプリケ一シ ヨンがランチャー + 1個のアプリケーションになっているかどうかのチェックを 行うのである。

図 5 9 ( a ) は、 アプリケーション管理テ一ブルに基づくローカルメモリ 2 9 に対するアクセスを示す図である。 本図において、読込優先度 = Optionalと設定 された application#2、 appUcation#3のグループ属性は、 group#lであるので、 これらのアプリケーションは、 同じお他グループに属することになる。 3つのァ プリケーシヨンのうち、 application#l は上述したランチャ一アプリケーション であり、 application#2、 application#3 は、 これにより起動されるアプリケ一シ ヨンであるので、 どちらかのみがローカルメモリ 2 9上に存在するよう、 グルー プ属性が付与されている。 アプリケーシ ョ ンマネージャ 3 6は、 これら application#2、 application#3のグループ属性を参照して、 どちらか 1つをロー カルメモリ 2 9から削除するとの処理を行う。 かかる削除によりローカルメモリ 2 9に余白が生まれる。

(第 1 1実施形態）

第 1実施形態では、 アプリケーション管理テーブルをタイトル毎に持たせると したが、 本実施形態では、 このアプリケーション管理テーブルの割当単位を変更 させることを提案する。 図 6 0は、 割当単位のバリエーションを示す図である。 本図において第 1段目は、 BD-ROMに記録されている 3つのアプリケーション 管理テーブルを示し、 第 2段目は、 タイトル単位、 第 3段目は、 ディスク単位、 第 4段目は、複数 BD-ROMからなるディスクセッ ト単位を示す。図中の矢印は、 アプリケ一シヨン管理テ一ブルの割り当てを模式化して示している。 この矢印を 参照すると、第 1段目におけるアプリケーション管理テーブル #1,#2,#3のそれぞ れは、第 2段目に示した title#l,#2，#3のそれぞれに割り当てられていることがわ かる。 また、 ディスク単位ではアプリケーション管理テーブル #4が割り当てられ ており、ディスクセット全体に対しはアプリケーション管理テーブル #5が割り当 てられている。 このようにアプリケーション管理テーブルの割当単位を、 タイ ト ルより大きい単位にすることにより、 1つの BD-ROMがローディングされてい る間、 生存するようなアプリケーシヨンや複数 BD-ROMのうちどれかがローデ ィングされている間、生存するようなアプリケーションを定義することができる。

(備考）

以上の説明は、 本発明の全ての実施行為の形態を示している訳ではない。 下記 (A)(B)(C)(D)……の変更を施した実施行為の形態によっても、 本発明の実施は可 能となる。 本願の請求項に係る各発明は、 以上に記載した複数の実施形態及びそ れらの変形形態を拡張した記載、 ないし、 一般化した記載としている。 拡張ない し一般化の程度は、 本発明の技術分野の、 出願当時の技術水準の特性に基づく。

(A)全ての実施形態では、本発明に係る光ディスクを BD-ROMとして実施した が、 本発明の光ディスクは、 記録される動的シナリオ、 Index Tableに特徴があ り、 この特徴は、 BD-ROM の物理的性質に依存するものではない。 動的シナリ 4 015330 ォ、 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に具備させてもい、 この場合、 再生装置と、 Vとを IEEE1394 で接続されたホームネットワークに組み入れることができる。 また、 実施形態における再生装置は、 テレビと接続して利用されるタイプであつたが、 ディスプレイと一体型となった再生装置であってもよい。 更に、 各実施形態の再 生装置において、 処理の本質的部分をなす部分のみを、 再生装置としてもよい。 これらの再生装置は、 何れも本願明細書に記載された発明であるから、 これらの 何れの態様であろうとも、 各実施形態に示した再生装置の内部構成を元に、 再生 装置を製造する行為は、 本願の明細書に記載された発明の実施行為になる。 各実 施形態に示した再生装置の有償'無償による譲渡 (有償の場合は販売、 無償の場合 は贈与になる)、 貸与、 輸入する行為も、 本発明の実施行為である。 店頭展示、 力 タログ勧誘、 パンフレット配布により、 これらの譲渡や貸渡を、 一般ユーザに申 し出る行為も本再生装置の実施行為である。

(C)各フローチャートに示したプログラムによる情報処理は、ハードウヱァ資源 を用いて具体的に実現されていることから、 上記フローチャートに処理手順を示 したプログラムは、 単体で発明として成立する。 全ての実施形態は、 再生装置に 組み込まれた態様で、 本発明に係るプログラムの実施行為についての実施形態を 示したが、 再生装置から分離して、 各実施形態に示したプログラム単体を実施し てもよい。 プログラム単体の実施行為には、 これらのプログラムを生産する行為 T JP2004/015330

(1)や、 有償'無償によりプログラムを譲渡する行為 (2)、 貸与する行為 (3)、 輸入す る行為 (4)、双方向の電子通信回線を介して公衆に提供する行為 (5)、店頭展示、 力 タログ勧誘、 パンフレッ ト配布により、 プログラムの譲渡や貸渡を、 一般ユーザ に申し出る行為 (6)がある。

(D)各フローチャートにおいて時系列に実行される各ステップの「時」の要素を、 発明を特定するための必須の事項と考える。 そうすると、 これらのフローチヤ一 トによる処理手順は、 再生方法の使用形態を開示していることがわかる。 各ステ ツプの処理を、 時系列に行うことで、 本発明の本来の目的を達成し、 作用及び効 果を奏するよう、 これらのフローチャートの処理を行うのであれば、 本発明に係 る記録方法の実施行為に該当することはいうまでもない。

(E)Chapterを一覧表示するための Menu(Chapter Menu)と、 これの挙動を制 御する MOVIEオブジェクトとを BD-ROMに記録しておき、 Top Menuから分 岐できるようにしてもよい。またリモコンキーの Chapterキーの押下により呼出 されるようにしてもよい。

(F)BD-ROMに記録するにあたつて、 AVClipを構成する各 TSパケットには、 拡張へッダを付与しておくことが望ましい。 拡張へッダは、 TP— extra— headerと 呼ばれ、 『Arribval— ime一 Stamp』 と、 u copy_permissioii— indicator』 と 含み 4 バイ 卜のデータ長を有する。 TP— extra— header付き TSバケツト（以下 EX付き TSパケットと略す)は、 32個毎にグループィ匕されて、 3つのセクタに書き込まれ る。 32個の EX付き TSバケツ トからなるグループは、 6144バイ ト（=32 x 192) であり、 これは 3個のセクタサイズ 6144バイト（=2048 X 3)と一致する。 3個の セクタに収められた 32個の EX付き TSパケットを" Aligned Unit" という。

IEEE1394を介して接続されたホームネットワークでの利用時において、 再生 装置 2 0 0は、以下のような送信処理にて Aligned Unitの送信を行う。つまり送 り手側の機器は、 Aligned Unitに含まれる 32個の EX付き TSパケットのそれ ぞれから TP— extra— headerを取り外し、 TSパケット本体を DTCP規格に基づき 暗号化して出力する。 TSバケツトの出力にあたっては、 TSバケツト間の随所に、 isochronous ノ、。ケッ トを揷入する。 この揷入箇所は、 TP_extra— header の Arribval_Time_Stampに示される時刻に基づいた位置である。 TSバケツトの出 力に伴い、 再生装置 2 0 0は DTCP_Desci'iptorを出力する。 DTCP_Descriptor 15330

は、 TP— extra— headerにおけるコピー許否設定を示す。 .ここで 「コピー禁止」 を 示すよう DTCP— Descriptorを記述しておけば、 IEEE1394を介して接続された ホームネットワークでの利用時において TSバケツトは、 他の機器に記録される ことはない。

(G)各実施形態において、 記録媒体に記録されるデジタルストリ一ムは 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)であってもよい。

(H)各実施形態における映像作品は、アナ口グ放送で放送されたアナ口グ映像信 号をエンコードすることにより得られたものでもよい。 デジタル放送で放送され たトランスポートストリームから構成されるストリームデータであってもよい。 またビデオテ一プに記録されているアナ口グ Zデジ夕ルの映像信号をェンコ一 ドしてコンテンツを得ても良い。 更にビデオカメラから直接取り込んだアナ口グ zデジタルの映像信号をエンコードしてコンテンツを得ても良い。 他にも、 配信 サーバにより配信されるデジタル著作物でもよい。

(I) BD-J モジュール 3 5は、 衛星放送受信のために機器に組み込まれた Java プラットフオームであってもよい。 BD-Jモジュール 3 5がかかる Javaプラット フォームであれば、 本発明に係る再生装置は、 MHP用 STBとしての処理を兼用 することになる。

更に携帯電話の処理制御のために機器に組み込まれた Javaプラットフォーム であってもよい。 かかる BD-Jモジュール 3 5がかかる Javaプラットフォーム であれば、 本発明に係る再生装置は、 携帯電話としての処理を兼用することにな る。

(K)レイァモデルにおいて、 BD-Jモードの上に MOVIEモードを配置してもよ い。 特に MOVIEモードでの動的シナリオの解釈や、 動的シナリオに基づく制御 手順の実行は、 再生装置に対する負担が軽いので、 MOVIEモードを BD-Jモー ド上で実行させても何等問題は生じないからである。 また再生装置や映画作品の 15330 開発にあたって、 動作保証が 1つのモ一ドで済むからである。

更に BD-Jモードだけで再生処理を実行してもよい。 第 5実施形態に示したよ うに、 BD-Jモードでも PLの再生と同期した再生制御が可能になるから、強いて MOVIEモードを設けなくてもよいという理由による。

(DAVClip に多重化されるべきインタラクティブグラフィクスストリームにナ ピゲ一シヨンコマンドを設けて、 ある PLから別の PLへの分岐を実現しても良 い。

産業上の利用可能性

本発明に係る再生装置は、 ホームシアターシステムでの利用のように、 個人的な 用途で利用されることがありうる。 しかし本発明は上記実施形態に内部構成が開 示されており、 この内部構成に基づき量産することが明らかなので、 資質におい て工業上利用することができる。 このことから本発明に係る再生装置は、 g業上 の利用可能性を有する。

Claims

請求の範囲

1 . 分岐可能な複数のタイ トルと、 アプリケーションとが記録された記録媒体 であって、

前記アプリケーションは、

仮想マシン向けプログラミング言語で記述され'たプログラムであり、 仮想マシ ンによる実行が可能となる生存区間が、 予め規定されており、

前記各タイ トルは、 管理テーブルを含み、

管理テーブルは、

タイ トルを生存区間とするアプリケーションを、 各タイトル毎に示す ことを特徴とする記録媒体。

2. 前記記録媒体には、 アプリケーションを構成するデータ及びプログラムを 格納したアーカイブファイルが記録されており、

前記各タイトルを生存区間とするアプリケーションは、

前記そのアプリケーションを格納したアーカイブファイルの識別子と、 タイト ルを一意に示すタイ トル番号との組みにより表現される

ことを特徴とする請求項 1記載の記録媒体。

3. デジタルストリームを含むタイ トルの再生と、 アプリケーションの実行と を同時に行う再生装置であって、

複数タイ トル間の分岐を制御するモジュールマネージャと、

1つのタイトルに帰属するデジタルストリームを再生する再生制御エンジン部 と、

タイ トルの分岐が発生する度に、 分岐先タイ トルを生存区間としたアプリケー シヨンの起動制御、 及び、 分岐先タイトルを生存区間としていないアプリケーシ ョンの終了制御を行うアプリケーションマネージャとを備える

ことを特徴とする再生装置。

4. タイトルは、 アプリケーション管理テーブルを含み、 アプリケーション管理テーブルは、 対応するタイトルを生存区間にしている 1 つ以上のアプリケーションを示し、

前記アプリケーションマネージャによる起動制御には、

タイ トルの分岐があった場合、 分岐先タイ トルを生存区間にしているアプリケ —シヨンが存在するかをアプリケーション管理テーブルを参照して判定し、 生存 区間としたアプリケーションが存在する場合のみ、 当該アプリケーションを起動 する制御がある

ことを特徴とする請求項 3記載の再生装置。

5. 前記アプリケーションマネージャによる起動制御には、

1つのタイトルにおいて起動しているアプリケーションからアプリケーション 呼出があった場合、 呼出先アプリケーションが、 当該タイトルを生存区間にして いるか否かをテーブルを参照して判定し、 生存区間にしている場合のみ、 呼出先 アプリケーシヨンを起動する制御がある

ことを特徴とする請求項 4記載の再生装置。

6. タイ トルは、 テーブルを含み、

テーブルは、 対応するタイ トルを生存区間にしている 1つ以上のアプリケーシ ョンを示し、

前記アプリケーションマネージャによる終了制御には、

タイ トルの分岐があった場合、 起動中アプリケーションのうち、 分岐先タイ ト ルを生存区間にしていないものが存在するかをテーブルを参照して判定し、 当該 アプリケーションが存在する場合のみ、 当該アプリケーションを終了するよう制 御ことである

ことを特徴とする請求項 1記載の再生装置。

7. 前記分岐は、 タイ トルへのジャンプを再生装置に命じるアプリケーション インタ一フヱイスにより実現され、

前記アプリケーションは、 前記アプリケーションィンターフヱイスをコールす る手順を含み、 モジュールマネージャは、 仮想マシンによる前記手順の解読に応じて分岐を実 行する、 ことを特徴とする請求項 3記載の再生装置。

8. 前記再生制御ェンジンによるデジタルストリームの再生には、 トリック再 生と、 通常再生とがあり、

前記アプリケーションマネージャは、

分岐先タイトルにおいてデジタルストリームの通常再生が開始した時点に、 ァ プリケーションの起動処理を開始する

ことを特徴とする請求項 3記載の再生装置。

9. デジタルストリームを含むタイ トルの再生と、 アプリケーションの実行と を同時に、 コンピュータに実行させるプログラムであって、

タイ トルの分岐が発生する度に、 分岐先タイ トルを生存区間としたアプリケー シヨンの起動制御、 及び、 分岐先タイ トルを生存区間としていないアプリケ一シ ョンの終了制御をコンピュータに行わせる

ことを特徴とするプログラム。

1 0. デジタルストリームを含むタイ トルの再生と、 アプリケーションの実行 とを同時に、 コンピュータに実行させる再生方法であって、

タイ トルの分岐が発生する度に、 分岐先タイ トルを生存区間としたアプリケー シヨンの起動制御、 及び、 分岐先タイ トルを生存区間としていないアプリケ一シ ョンの終了制御をコンピュータに行わせる

ことを特徴とする再生方法。