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

記録媒体、再生装置、プログラム、再生方法。 Download PDF

Info

Publication number
JPWO2005036555A1
JPWO2005036555A1 JP2005514682A JP2005514682A JPWO2005036555A1 JP WO2005036555 A1 JPWO2005036555 A1 JP WO2005036555A1 JP 2005514682 A JP2005514682 A JP 2005514682A JP 2005514682 A JP2005514682 A JP 2005514682A JP WO2005036555 A1 JPWO2005036555 A1 JP WO2005036555A1
Authority
JP
Japan
Prior art keywords
application
title
playback
attribute
branch
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2005514682A
Other languages
English (en)
Other versions
JP3825463B2 (ja
Inventor
航 池田
航 池田
啓明 岩本
啓明 岩本
岡田　智之
智之 岡田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Application granted granted Critical
Publication of JP3825463B2 publication Critical patent/JP3825463B2/ja
Publication of JPWO2005036555A1 publication Critical patent/JPWO2005036555A1/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102—Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105—Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/21—Disc-shaped record carriers characterised in that the disc is of read-only, rewritable, or recordable type
    • G11B2220/213—Read-only discs
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G11B2220/25—Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537—Optical discs
    • G11B2220/2541—Blu-ray discs; Blue laser DVR discs

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Indexing, Searching, Synchronizing, And The Amount Of Synchronization Travel Of Record Carriers (AREA)
  • Television Signal Processing For Recording (AREA)

Abstract

ＢＤ−ＲＯＭには、分岐可能な複数タイトルと、各タイトルの再生時に実行可能なＪａｖａアプリケーションとが記録されている。タイトルは、ＡＶＣｌｉｐと、アプリケーション管理テーブルとを有しており、前記アプリケーションは、仮想マシン向けプログラミング言語で記述されたプログラムであり、アプリケーション管理テーブルは、アプリケーションと、対応するタイトルにおけるアプリケーションの起動属性とを対応づけて示し、起動属性には、分岐元におけるアプリケーションの状態を継続させる継続属性（Ｐｅｒｓｉｓｔｅｎｔ）と、分岐元においてアプリケーションが非起動状態である場合、当該アプリケーションを自動的に起動させるＡｕｔｏＲｕｎ属性とがある。

Description

本発明は、仮想マシンを対象にしたプログラムの起動を制御する、起動制御技術の技術分野に属する発明であり、本起動制御技術を記録媒体、民生用の再生装置、プログラムに応用する場合の応用技術に深く係る。
Ｊａｖａプログラム等、仮想マシンを対象にした制御技術は、通信、放送を初め、様々な技術分野に浸透している。特に放送分野においては、デジタル映像の再生に従って、Ｊａｖａアプリケーションを動作させるという技術が既に確立されており、Ｊａｖａアプリケーションによるメニュー制御を伴った様々なサービスが、視聴者の興味を集めている。
放送分野から更に発展して、現在ディスクコンテンツにおける再生制御をＪａｖａプログラミングで実現するための様々な工夫が検討されている。ここでディスクコンテンツの再生進行は、一本の再生時間軸に沿った単純なものではなく、ある再生時間軸から別の再生時間軸への分岐が有り得る複雑なものである。このディスクコンテンツにおいてこの分岐の単位は、タイトルと呼ばれる。タイトルは、１つ以上の再生時間軸をもち、アプリケーションはこのタイトル内の時間軸上に、起動時点、終了時点が定義されることになる。ここで、あるタイトル内の時間軸に沿ってアプリケーションを動作させようとすると、タイトルからタイトルへの分岐が発生した際、現在起動中のアプリケーションを全て終了させたり、更に、改めてアプリケーションを起動しなおすという手間が多く発生する。ここで、１つのタイトル終了から、次のタイトル開始までをタイトルバウンダリというが、多くのアプリケーションを起動させたり、終了させる必要があると、このタイトルバウンダリの期間が異様に長くなり、分岐先タイトルの再生がなかなか開始しないという事態が生じる。
本発明の目的は、アプリケーションロードやアプリケーション終了が何度も繰り返されることによる、タイトルバウンダリの長期間化を避けることができる再生装置を提供することである。
上記目的は、アプリケーションと、対応するタイトルにおけるアプリケーションの起動属性とを対応づけて示す管理テーブルが記録されており、起動属性には、分岐元タイトルにおいてアプリケーションが非起動状態である場合、当該分岐先タイトルにおいてアプリケーションを自動的に起動させる自動起動属性がある、ことを特徴とした記録媒体により達成される。この記録媒体における自動起動属性は、分岐元においてアプリケーションが非起動状態である場合、当該アプリケーションを自動的に起動させる旨を示しているので、分岐元非起動−分岐先自動起動属性の組合せのみアプリケーションを起動する。アプリケーションの起動は、分岐元非起動−分岐先自動起動属性の組合せ時に限られるので、タイトル間の分岐により、再生が複雑に進行したとしても、アプリケーション起動処理が冗長に行われることにない。冗長なアプリケーション起動を避けることができるので、タイトルバウンダリを短期間にすることができる。これによりタイトルバウンダリをユーザに意識させないスムーズな再生制御を実現することができる。このため、複数タイトルにわたるような長編もののコンテンツや、ＤＶＤ−ＢＯＸのように、複数ＢＤ−ＲＯＭに記録されたシリーズ物コンテンツを提供する場合に真価を発揮する。
図１は、本発明に係る再生装置の使用行為についての形態を示す図である。
図２は、ＢＤ−ＲＯＭにおけるファイル・ディレクトリ構成を示す図である。
図３は、ＡＶＣｌｉｐ時間軸と、ＰＬ時間軸との関係を示す図である。
図４は、４つのＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅによりなされた一括指定を示す図である。
図５は、ＰＬｍａｒｋによるチャプター定義を示す図である。
図６は、ＳｕｂＰｌａｙＩｔｅｍ時間軸上の再生区間定義と、同期指定とを示す図である。
図７（ａ）は、Ｍｏｖｉｅオブジェクトの内部構成を示す図である。
図７（ｂ）は、ＢＤ−Ｊオブジェクトの内部構成を示す図である。
図７（ｃ）は、Ｊａｖａアプリケーションの内部構成を示す図である。
図８（ａ）は、Ｊａｖａアーカイブファイルに収められているプログラム、データを示す図である。
図８（ｂ）は、ｘｌｅｔプログラムの一例を示す図である。
図９（ａ）は、トップメニュー、ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２といった一連のタイトルを示す図である。
図９（ｂ）は、ＰｌａｙＬｉｓｔ＃１、Ｐ１ａｙＬｉｓｔ＃２の時間軸を足し合わせた時間軸を示す図である。
図１０は、本編タイトル、オンラインショッピングタイトル、ゲームタイトルという３つのタイトルを含むディスクコンテンツを示す図である。
図１１は、図１０に示した３つのタイトルの再生画像の一例を示す図である。
図１２（ａ）は、図１０の破線に示される帰属関係から各アプリケーションの生存区間をグラフ化した図である。
図１２（ｂ）は、図１２（ａ）の生存区間を規定するため、記述されたアプリケーション管理テーブルの一例を示す図である。
図１３（ａ）は、起動属性設定の一例を示す図である。
図１３（ｂ）は、他のアプリケーションからのアプリケーション呼出があって初めて起動するアプリケーション（ａｐｐｌｉｃａｔｉｏｎ＃２）を示す図である。
図１４（ａ）（ｂ）は、Ｓｕｓｐｅｎｄが有意義となるアプリケーション管理テーブル、生存区間の一例を示す図である。
図１５は、起動属性がとり得る三態様（Ｐｅｒｓｉｓｔｅｎｔ、ＡｕｔｏＲｕｎ、Ｓｕｓｐｅｎｄ）と、直前タイトルにおけるアプリケーション状態の三態様（非起動、起動中、Ｓｕｓｐｅｎｄ）とがとりうる組合せを示す図である。
図１６は、本発明に係る再生装置の内部構成を示す図である。
図１７（ａ）は、ＢＤ−ＲＯＭに存在しているＪａｖａアーカイブファイルを、ローカルメモリ２９上でどのように識別するかを示す図である。
図１７（ｂ）は、図１７（ａ）の応用を示す図である。
図１８は、ＲＯＭ２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。
図１９は、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１〜モジュールマネージャ３４による処理を模式化した図である。
図２０は、アプリケーションマネージャ３６による処理を模式化した図である。
図２１は、ワークメモリ３７〜Ｄｅｆａｕｌｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ４０を示す図である。
図２２は、アプリケーションマネージャ３６による分岐時の制御手順を示す図である。
図２３は、アプリケーション終了処理の処理手順を示すフローチャートである。
図２４は、アプリケーション終了の過程を模式的に示した図である。
図２５（ａ）は、ＰＬ時間軸上に生存区間を定めたアプリケーション管理テーブルを示す図である。
図２５（ｂ）は、図２５（ａ）のアプリケーション管理テーブルに基づき、アプリケーションの生存区間を示した図である。
図２６（ａ）は、ＰＬ時間軸から定まるタイトル時間軸を示す。
図２６（ｂ）は、メインとなるアプリケーションの生存区間から定まるタイトル時間軸を示す。
図２６（ｃ）は、複数アプリケーションの生存区間から定まるタイトル時間軸を示す図である。
図２７は、タイトル再生時におけるアプリケーションマネージャ３６の処理手順を示すフローチャートである。
図２８（ａ）は、ＢＤ−ＲＯＭにより実現されるメニュー階層を示す図である。
図２８（ｂ）は、メニュー階層を実現するためのＭＯＶＩＥオブジェクトを示す図である。
図２９は、Ｉｎｄｅｘ Ｔａｂｌｅと、Ｉｎｄｅｘ Ｔａｂｌｅから各Ｍｏｖｉｅオブジェクトへの分岐とを模式化した図である。
図３０（ａ）は、図２９（ｂ）のようにＩｎｄｅｘ Ｔａｂｌｅが記述された場合における分岐を示す。
図３０（ｂ）は、非ＡＶ系タイトルが強制終了した際における分岐を示す図である。
図３１は、モジュールマネージャ３４の処理手順を示すフローチャートである。
図３２は、アプリケーションマネージャ３６によるアプリケーション強制終了の動作例を示す図である。
図３３は、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２によるＰＬ再生手順を示すフローチャートである。
図３４は、アングル切換、ＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔの受付手順を示すフローチャートである。
図３５は、ＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔＡＰＩがコールされた際の処理手順を示すフローチャートである。
図３６は、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１による処理手順の詳細を示すフローチャートである。
図３７は、ＳｕｂＰｌａｙＩｔｅｍの再生手順を示すフローチャートである。
図３８は、第５実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。
図３９は、データ管理テーブルの一例を示す図である。
図４０は、ＢＤ−Ｊオブジェクトが想定している実行モデルを示す図である。
図４１（ａ）は、ローカルメモリ２９におけるＪａｖａアーカイブファイル生存を示す生存区間を示す図である。
図４１（ｂ）は、図４１（ａ）でのＪａｖａアーカイブファイル生存区間を規定するため、記述されたデータ管理テーブルを示す図である。
図４２は、カルーセル化によるＪａｖａアーカイブファイル埋め込みを示す図である。
図４３（ａ）は、インターリーブ化によるＡＶＣｌｉｐ埋め込みを示す図である。
図４３（ｂ）は、読込属性の３つの類型を示す図である。
図４４（ａ）は、データ管理テーブルの一例を示す図である。
図４４（ｂ）は、図４４（ａ）のデータ管理テーブルの割り当てによるローカルメモリ２９の格納内容の変遷を示す図である。
図４５（ａ）は、新旧再生装置におけるローカルメモリ２９のメモリ規模を対比して示す図である。
図４５（ｂ）は、読込優先度が設定されたデータ管理テーブルの一例を示す図である。
図４６は、アプリケーションマネージャ３６によるプリロード制御の処理手順を示す図である。
図４７（ａ）は、ａｐｐｌｉｃａｔｉｏｎＩＤが同一であるが、読込優先度は互いに異なる複数のアプリケーションを規定するデータ管理テーブルの一例を示す図である。
図４７（ｂ）は、図４７（ａ）のデータ管理テーブルの割り当てによるローカルメモリ２９の格納内容の変遷を示す図である。
図４８（ａ）は、プリロードされるべきアプリケーション、ロードされるべきアプリケーションに同一のａｐｐｌｉｃａｔｉｏｎＩＤを付与するよう記述されたデータ管理テーブルの一例を示す図である。
図４８（ｂ）は、メモリ規模が小さい再生装置におけるローカルメモリ２９の格納内容の変遷を示す図である。
図４８（ｃ）は、メモリ規模が大きい再生装置におけるローカルメモリ２９の格納内容の変遷を示す図である。
図４９は、データ管理テーブルに基づくアプリケーションマネージャ３６によるロード処理の処理手順を示す図である。
図５０は、アプリケーションｑの生存区間に、現在の再生時点が到達した場合のアプリケーションマネージャ３６による処理手順を示す図である。
図５１は、Ｊａｖａ仮想マシン３８によるアプリケーションの読み込みがどのようにして行われるかを模式化した図である。
図５２（ａ）は、第７実施形態に係るＢＤ−Ｊオブジェクトの内部構成を示す図である。
図５２（ｂ）は、プレイリスト管理テーブルの一例を示す図である。
図５２（ｃ）は、分岐先タイトルのプレイリスト管理テーブルにおいて、再生属性がＡｕｔｏＰｌａｙに設定されたＰＬが存在する場合、再生装置がどのような処理を行うかを示す図である。
図５３（ａ）は、再生属性が非自動再生を示すよう設定された場合の非ＡＶ系タイトルにおけるタイトル時間軸を示す図である。
図５３（ｂ）は、再生属性がＡｕｔｏＰｌａｙに設定された非ＡＶ系タイトルのタイトル時間軸を示す図である。
図５３（ｃ）は、プレイリスト管理テーブルにおいて再生属性が”ＡｕｔｏＰｌａｙ”を示すよう設定され、アプリケーションが強制終了した場合を示す図である。
図５３（ｄ）は、プレイリスト管理テーブルにおいて再生属性が”ＡｕｔｏＰｌａｖ”を示すよう設定され、メインアプリの起動に失敗したケースを示す図である。
図５４は、第７実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。
図５５は、プレイリスト管理テーブルにおいて”再生属性＝ＡｕｔｏＰｌａｙ”に設定されることにより、どのような再生が行われるかを模式化した図である。
図５６（ａ）（ｂ）は、アプリケーションの扱いと、起動属性との関係を示した図である。
図５７は、第８実施形態に係るＪａｖａ仮想マシン３８によるアプリケーションの読み込みがどのようにして行われるかを模式化した図である。
図５８（ａ）（ｂ）は、第９実施形態に係る読込優先度の一例を示す図である。
図５９（ａ）は、グループ属性が付与されたデータ管理テーブルを示す図である。
図５９（ｂ）は、アプリケーション管理テーブルに基づくローカルメモリ２９に対するアクセスを示す図である。
図６０は、アプリケーション管理テーブルの割当単位のバリエーションを示す図である。
（第１実施形態）
以降、本発明に係る再生装置の実施形態について説明する。先ず始めに、本発明に係る再生装置の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る再生装置の、使用行為についての形態を示す図である。図１において、本発明に係る再生装置は再生装置２００であり、テレビ３００、リモコン４００と共にホームシアターシステムを形成する。
このＢＤ−ＲＯＭ１００は、再生装置２００、リモコン３００、テレビ４００により形成されるホームシアターシステムに、映画作品を供給するという用途に供される。
以上が本発明に係る再生装置の使用形態についての説明である。
続いて本発明に係る再生装置の再生の対象となる、記録媒体であるＢＤ−ＲＯＭについて説明する。ＢＤ−ＲＯＭにより、ホームシアターシステムに供給されるディスクコンテンツは、互いに分岐可能な複数タイトルから構成される。各タイトルは、１つ以上のプレイリストと、このプレイリストを用いた動的な制御手順とからなる。
プレイリストとは、１つ以上のデジタルストリームと、そのデジタルストリームにおける再生経路とから構成され、”時間軸”の概念をもつＢＤ−ＲＯＭ上のアクセス単位である。以上のプレイリストと、動的な制御手順とを包含しているため、タイトルはデジタルストリーム特有の時間軸の概念と、コンピュータプログラム的な性質とを併せもっている。
図２は、ＢＤ−ＲＯＭにおけるファイル・ディレクトリ構成を示す図である。本図においてＢＤ−ＲＯＭには、Ｒｏｏｔディレクトリの下に、ＢＤＭＶディレクトリがある。
ＢＤＭＶディレクトリには、拡張子ｂｄｍｖが付与されたファイル（ｉｎｄｅｘ．ｂｄｍｖ，ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖ）と、拡張子ＢＤ−Ｊが付与されたファイル（００００１．ＢＤ−Ｊ，００００２．ＢＤ−Ｊ，００００３．ＢＤ−Ｊ）がある。そしてこのＢＤＭＶディレクトリの配下には、更にＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦディレクトリ、ＳＴＲＥＡＭディレクトリ、ＢＤＡＲディレクトリと呼ばれる４つのサブディレクトリが存在する。
ＰＬＡＹＬＩＳＴディレクトリには、拡張子ｍｐｌｓが付与されたファイル（００００１．ｍｐｌｓ，００００２．ｍｐｌｓ，００００３ｍｐｌｓ）がある。
ＣＬＩＰＩＮＦディレクトリには、拡張子ｃｌｐｉが付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ）がある。
ＳＴＲＥＡＭディレクトリには、拡張子ｍ２ｔｓが付与されたファイル（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ，００００３．ｍ２ｔｓ）がある。
ＢＤＡＲディレクトリには、拡張子ｊａｒが付与されたファイル（００００１．ｊａｒ，００００２．ｊａｒ，００００３ｊａｒ）がある。以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、ＢＤ−ＲＯＭ上に配置されていることがわかる。
本図において拡張子．ｍ２ｔｓが付与されたファイル（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ，００００３．ｍ２ｔｓ・・・・・）は、ＡＶＣｌｉｐを格納している。ＡＶＣｌｉｐには、ＭａｉｎＣＬｉｐ、ＳｕｂＣｌｉｐといった種別がある。ＭａｉｎＣＬｉｐは、ビデオストリーム、オーディオストリー厶、プレゼンテーショングラフィクスストリーム、インタラクティブグラフィクスストリームというような複数エレメンタリストリームを多重化することで得られたデジタルストリームである。
ＳｕｂＣｌｉｐは、オーディオストリーム、グラフィクスストリーム、テキスト字幕ストリーム等、１つのエレメンタリストリームのみにあたるデジタルストリームである。
拡張子”ｃｌｐｉ”が付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ・・・・・）は、ＡＶＣｌｉｐのそれぞれに１対１に対応する管理情報である。管理情報故に、Ｃｌｉｐ情報は、ＡＶＣｌｉｐにおけるストリームの符号化形式、フレームレート、ビットレート、解像度等の情報や、頭出し位置を示すＥＰ＿ｍａｐをもっている。
拡張子”ｍｐｌｓ”が付与されたファイル（００００１．ｍｐｌｓ，００００２．ｍｐｌｓ，００００３．ｍｐｌｓ・・・・・）は、プレイリスト情報を格納したファイルである。プレイリスト情報は、ＡＶＣｌｉｐを参照してプレイリストを定義する情報である。プレイリストは、ＭａｉｎＰａｔｈ情報、ＰＬＭａｒｋ情報、ＳｕｂＰａｔｈ情報から構成される。
ＭａｉｎＰａｔｈ情報は、複数のＰｌａｙＩｔｅｍ情報からなる。ＰｌａｙＩｔｅｍとは、１つ以上のＡＶＣｌｉｐ時間軸上において、Ｉｎ＿Ｔｉｍｅ，Ｏｕｔ＿Ｔｉｍｅを指定することで定義される再生区間である。ＰｌａｙＩｔｅｍ情報を複数配置させることで、複数再生区間からなるプレイリスト（ＰＬ）が定義される。図３は、ＡＶＣｌｉｐと、ＰＬとの関係を示す図である。第１段目はＡＶＣｌｉｐがもつ時間軸を示し、第２段目は、ＰＬがもつ時間軸を示す。ＰＬ情報は、ＰｌａｙＩｔｅｍ＃１，＃２，＃３という３つのＰｌａｙＩｔｅｍ情報を含んでおり、これらＰｌａｙＩｔｅｍ＃１，＃２，＃３のＩｎ＿ｔｉｍｅ，Ｏｕｔ＿ｔｉｍｅにより、３つの再生区間が定義されることになる。これらの再生区間を配列させると、ＡＶＣｌｉｐ時間軸とは異なる時間軸が定義されることになる。これが第２段目に示すＰＬ時間軸である。このように、ＰｌａｙＩｔｅｍ情報の定義により、ＡＶＣｌｉｐとは異なる時間軸の定義が可能になる。
ＡＶＣｌｉｐに対する指定は、原則１つであるが、複数ＡＶＣｌｉｐに対する一括指定もあり得る。この一括指定は、ＰｌａｙＩｔｅｍ情報における複数のＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅによりなされる。図４は、４つのＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅによりなされた一括指定を示す図である。本図において第１段目〜第４段目は、４つのＡＶＣｌｉｐ時間軸（ＡＶＣｌｉｐ＃１，＃２，＃３，＃４の時間軸）を示し、第５段目は、ＰＬ時間軸を示す。ＰｌａｙＩｔｅｍ情報が有する、４つのＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅにて、これら４つの時間軸が指定されている。こうすることで、ＰｌａｙＩｔｅｍが有するＩｎ＿ｔｉｍｅ，Ｏｕｔ＿ｔｉｍｅにより、択一的に再生可能な４つの再生区間が定義されることになる。これにより、ＰＬ時間軸には、切り換え可能な複数アングル映像からなる区間（いわゆるマルチアングル区間）が定義されることになる。
ＰＬｍａｒｋ情報は、ＰＬ時間軸のうち、任意の区間を、チャプターとして指定する情報である。図５は、ＰＬｍａｒｋによるチャプター定義を示す図である。本図において第１段目は、ＡＶＣｌｉｐ時間軸を示し、第２段目はＰＬ時間軸を示す。図中の矢印ｐｋ１，２は、ＰＬｍａｒｋにおけるＰｌａｙＩｔｅｍ指定（ｒｅｆ＿ｔｏ＿ＰｌａｙＩｔｅｍ＿Ｉｄ）と、一時点の指定（ｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐ）とを示す。これらの指定によりＰＬ時間軸には、３つのチャプター（Ｃｈａｐｔｅｒ＃１，＃２，＃３）が定義されることになる。
ＳｕｂＰａｔｈ情報は、複数のＳｕｂＰｌａｙＩｔｅｍ情報からなる。ＳｕｂＰｌａｙＩｔｅｍ情報は、ＳｕｂＣｌｉｐの時間軸上にＩｎ＿Ｔｉｍｅ，Ｏｕｔ＿Ｔｉｍｅを指定することで再生区間を定義する。またＳｕｂＰｌａｙＩｔｅｍ情報は、ＳｕｂＣｌｉｐ時間軸上の再生区間を、ＰＬ時間軸に同期させるという同期指定が可能であり、この同期指定により、ＰＬ時間軸と、ＳｕｂＰｌａｙＩｔｅｍ情報時間軸とは同期して進行することになる。図６は、ＳｕｂＰｌａｙＩｔｅｍ時間軸上の再生区間定義と、同期指定を示す図である。本図において第１段目は、ＰＬ時間軸を示し、第２段目はＳｕｂＰｌａｙＩｔｅｍ時間軸を示す。図中のＳｕｂＰｌａｙＩｔｅｍ．ＩＮ＿ｔｉｍｅは再生区間の始点を、ＳｕｂＰｌａｙＩｔｅｍ．Ｏｕｔ＿ｔｉｍｅは再生区間の終点をそれぞれ示す。これによりＳｕｂＣｌｉｐ時間軸上にも再生区間が定義されていることがわかる。矢印Ｓｎ１においてＳｙｎｃ＿ＰｌａｙＩｔｅｍ＿Ｉｄは、ＰｌａｙＩｔｅｍに対する同期指定を示し、矢印Ｓｎ２においてｓｙｎｃ＿ｓｔａｒｔ＿ＰＴＳ＿ｏｆ＿ＰｌａｙＩｔｅｍは、ＰＬ時間軸におけるＰｌａｙＩｔｅｍ上の一時点の指定を示す。
複数ＡＶＣｌｉｐの切り換えを可能とするマルチアングル区間や、ＡＶＣｌｉｐ−ＳｕｂＣｌｉｐを同期させ得る同期区間の定義を可能とするのが、ＢＤ−ＲＯＭにおけるプレイリスト情報の特徴である。以上のＣｌｉｐ情報及びプレイリスト情報は、”静的シナリオ”に分類される。何故なら、以上のＣｌｉｐ情報及びプレイリスト情報により、静的な再生単位であるＰＬが定義されるからである。以上で静的シナリオについての説明を終わる。
続いて”動的なシナリオ”について説明する。動的シナリオとは、ＡＶＣｌｉｐの再生制御を動的に規定するシナリオデータである。”動的に”というのは、再生装置における状態変化やユーザからのキーイベントにより再生制御の中身がかわることをいう。ＢＤ−ＲＯＭでは、この再生制御の動作環境として２つのモードを想定している。１つ目は、ＤＶＤ再生装置の動作環境と良く似た動作環境であり、コマンドベースの実行環境である。２つ目は、Ｊａｖａ仮想マシンの動作環境である。これら２つの動作環境のうち１つ目は、ＨＤＭＶモードと呼ばれる。２つ目は、ＢＤ−Ｊモードと呼ばれる。これら２つの動作環境があるため、動的シナリオはこのどちらかの動作環境を想定して記述される。ＨＤＭＶモードを想定した動的シナリオはＭｏｖｉｅオブジェクトと呼ばれ、管理情報により定義される。一方ＢＤ−Ｊモードを想定した動的シナリオはＢＤ−Ｊオブジェクトと呼ばれる。
先ず初めにＭｏｖｉｅオブジェクトについて説明する。
＜Ｍｏｖｉｅオブジェクト＞
Ｍｏｖｉｅオブジェクトは、”タイトル”の構成要素であり、ファイルＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖに格納される。図７（ａ）は、Ｍｏｖｉｅオブジェクトの内部構成を示す図である。Ｍｏｖｉｅオブジェクトは、属性情報、複数のナビゲーションコマンドからなるコマンド列からなる。
属性情報は、ＰＬ時間軸において、ＭｅｎｕＣａｌｌがなされた際、ＭｅｎｕＣａｌｌ後の再生再開を意図しているか否かを示す情報（ｒｅｓｕｍｅ＿ｉｎｔｅｎｔｉｏｎ＿ｆｌａｇ）、ＰＬ時間軸においてＭｅｎｕＣａｌｌをマスクするかを示す情報（ｍｅｎｕ＿ｃａｌｌ＿ｍａｓｋ）、タイトルサーチをマスクするかを示す情報（ｔｉｔｌｅ＿ｓｅａｒｃｈ＿ｆｌａｇ）からなる。Ｍｏｖｉｅオブジェクトは、”時間軸”＋”プログラム的制御”という２つの性質を併せ持つことができるで、本編再生を実行するもの等、多様な種類のタイトルがこのＭｏｖｉｅオブジェクトにより記述されることになる。
ナビゲーションコマンド列は、条件分岐、再生装置における状態レジスタの設定、状態レジスタの設定値取得等を実現するコマンド列からなる。Ｍｏｖｉｅオブジェクトにおいて記述可能なコマンドを以下に示す。
ＰｌａｙＰＬコマンド
書式：ＰｌａｙＰＬ（第１引数，第２引数）
第１引数は、プレイリストの番号で、再生すべきＰＬを指定することができる。第２引数は、そのＰＬに含まれるＰｌａｙＩｔｅｍや、そのＰＬにおける任意の時刻、Ｃｈａｐｔｅｒ、Ｍａｒｋを用いて再生開始位置を指定することができる。
ＰｌａｙＩｔｅｍによりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数をＰｌａｙＰＬａｔＰｌａｙＩｔｅｍ（）、
ＣｈａｐｔｅｒによりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数をＰｌａｙＰＬａｔＣｈａｐｔｅｒ（）、
時刻情報によりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数をＰｌａｙＰＬａｔＳｐｅｃｉｆｉｅｄ Ｔｉｍｅ（）という。
ＪＭＰコマンド
書式：ＪＭＰ引数
ＪＭＰコマンドは、現在の動的シナリオを途中で廃棄し（ｄｉｓｃａｒｄ）、引数たる分岐先動的シナリオを実行するという分岐である。ＪＭＰ命令の形式には、分岐先動的シナリオを直接指定している直接参照のものと、分岐先動的シナリオを間接参照している間接参照のものがある。
Ｍｏｖｉｅオブジェクトにおけるナビゲーションコマンドの記述は、ＤＶＤにおけるナビゲーションコマンドの記述方式と良く似ているので、ＤＶＤ上のディスクコンテンツを、ＢＤ−ＲＯＭに移植するという作業を効率的に行うことができる。Ｍｏｖｉｅオブジェクトについては、以下の国際公開公報に記載された先行技術が存在する。詳細については、本国際公開公報を参照されたい。
国際公開公報ＷＯ ２００４／０７４９７６
以上でＭｏｖｉｅオブジェクトについての説明を終える。続いてＢＤ−Ｊオブジェクトについて説明する。
＜ＢＤ−Ｊオブジェクト＞
拡張子ＢＤ−Ｊが付与されたファイル（００００１．ＢＤ−Ｊ，００００２．ＢＤ−Ｊ，００００３．ＢＤ−Ｊ）は、ＢＤ−Ｊオブジェクトを構成する。ＢＤ−Ｊオブジェクトは、Ｊａｖａプログラミング環境で記述された、ＢＤ−Ｊモードの動的シナリオである。図７（ｂ）は、ＢＤ−Ｊオブジェクトの内部構成を示す図である。本図に示すようにＢＤ−Ｊオブジェクトは、Ｍｏｖｉｅオブジェクト同様の属性情報、アプリケーション管理テーブルからなる。属性情報を有している点でＢＤ−ＪオブジェクトはＭｏｖｉｅオブジェクトとほぼ同じである。Ｍｏｖｉｅオブジェクトとの違いは、ＢＤ−Ｊオブジェクトはコマンドが直接記述されていない点である。つまりＭｏｖｉｅオブジェクトにおいて制御手順は、ナビゲーションコマンドにより直接記述されていた。これに対しＢＤ−Ｊオブジェクトでは、そのタイトルを生存区間としているＪａｖａアプリケーションをアプリケーション管理テーブル上に定めることにより、間接的に制御手順を規定している。このような間接的な規定により、複数タイトルにおいて制御手順を共通化するという、制御手順の共通化を効率的に行うことができる。
図７（ｃ）は、Ｊａｖａアプリケーションの内部構成を示す図である。本図においてアプリケーションは、仮想マシンのヒープ領域（ワークメモリとも呼ばれる）にロードされた１つ以上のｘｌｅｔプログラムからなる。このワークメモリでは、１つ以上のスレッドが動作しており、ワークメモリにロードされたｘｌｅｔプログラム、及び、スレッドから、アプリケーションは構成されることになる。以上がアプリケーションの構成である。
このアプリケーションの実体にあたるのが、ＢＤＭＶディレクトリ配下のＢＤＡＲディレクトリに格納されたＪａｖａアーカイブファイル（００００１．ｊａｒ，００００２．ｊａｒ）である。以降、Ｊａｖａアーカイブファイルについて説明する。
Ｊａｖａアーカイブファイル（００００１．ｊａｒ，００００２．ｊａｒ）は、Ｊａｖａアプリケーションを構成するプログラム、データを格納したアーカイブファイルである。図８（ａ）は、アーカイブファイルにより収められているプログラ厶、データを示す図である。本図におけるデータは、枠内に示すディレクトリ構造が配置された複数ファイルを、ｊａｖａアーカイバでまとめたものである。枠内に示すディレクトリ構造は、ｒｏｏｔディレクトリ、ｊａｖａディレクトリ、ｉｍａｇｅディレクトリとからなり、ｒｏｏｔディにｃｏｍｍｏｎ．ｐｋｇが、ｊａｖａディレクトリにａａａ．ｃｌａｓｓ，ｂｂｂ．ｃｌａｓｓが、ｉｍａｇｅディレクトリに、ｍｅｎｕ．ｊｐｇが配置されている。ｊａｖａアーカイブファイルは、これらをｊａｖａアーカイバでまとめることで得られる。かかるデータは、ＢＤ−ＲＯＭからキャッシュに読み出されるにあたって展開され、キャッシュ上で、ディレクトリに配置された複数ファイルとして取り扱われる。Ｊａｖａアーカイブファイルのファイル名における”ｘｘｘｘｘ”という５桁の数値は、アプリケーションのＩＤ（ａｐｐｌｉｃａｔｉｏｎＩＤ）を示す。本Ｊａｖａアーカイブファイルがキャッシュに読み出された際、このファイル名における数値を参照することにより、任意のＪａｖａアプリケーションを構成するプログラム，データを取り出すことができる。
Ｊａｖａアーカイブファイルにおいて１つにまとめられるファイルには、ｘｌｅｔプログラムがある。
ｘｌｅｔプログラムは、ＪＭＦ（Ｊａｖａ Ｍｅｄｉａ Ｆｒａｍｅ Ｗｏｒｋ）インターフェイスを利用することができるＪａｖａプログラムである。ｘｌｅｔプログラムは、キーイベントを受信するＥｖｅｎｔＬｉｓｔｎｅｒ等、複数の関数からなり、ＪＭＦ等の方式に従って、受信したキーイベントに基づく処理を行う。
図８（ｂ）は、ｘｌｅｔプログラムの一例を示す図である。ＪＭＦ Ａ”ＢＤ：／／００００１．ｍｐｌｓ”；は、ＰＬを再生するプレーヤインスタンスの生成をＪａｖａ仮想マシンに命じるメソッドである。Ａ．ｐｌａｙは、ＪＭＦプレーヤインスタンスに再生を命じるメソッドである。かかるＪＭＦプレーヤインスタンス生成は、ＪＭＦライブラリに基づきなされる。ｘｌｅｔプログラムの記述は、ＢＤ−ＲＯＭのＰＬに限らず、時間軸をもったコンテンツ全般に適用可能なＪＭＦの記述である。このような記述が可能であるので、Ｊａｖａプログラミングに長けたソフトハウスに、ＢＤ−Ｊオブジェクト作成を促すことができる。
図８（ｂ）におけるＪｕｍｐＴＩｔｌｅ（）；は、ファンクションＡＰＩのコールである。このファンクションＡＰＩは、他のタイトルへの分岐（図中ではｔｉｔｌｅ＃１）を再生装置に命じるものである。ここでファンクションＡＰＩとは、ＢＤ−ＲＯＭ再生装置により供給されるＡＰＩ（Ａｐｐｌｉａｔｉｏｎ Ｉｎｔｅｒｆａｃｅ）である。ＪｕｍｐＴｉｔｌｅコマンドの他にも、ファンクションＡＰＩのコールにより、ＢＤ−ＲＯＭ再生装置特有の処理をｘｌｅｔプログラムに記述することができる。
ＢＤ−ＪモードにおいてＰＬ再生は、ＪＭＦインターフェイスにより規定される。このＪＭＦプレーヤインスタンスは、ＰＬ時間軸を定めるものだから、タイトル時間軸は、このＪＭＦプレーヤインスタンスをもったタイトルから定まる。また
ＢＤ−Ｊモードにおいてタイトルからタイトルへの分岐はＪｕｍｐＴｉｔｌｅＡＰＩのコールにより規定される。ＪｕｍｐＴｉｔｌｅＡＰＩコールは、いわばタイトルの終了時点を定めるものなので、こうしたＪＭＦプレーヤインスタンス、ＪｕｍｐＴｉｔｌｅＡＰＩコールをもったアプリケーションが、ＢＤ−Ｊモードにおいてタイトルの開始及び終了を律することになる。かかるアプリケーションを本編再生アプリケーションという。
以上が、ＢＤ−Ｊモードにおける動的シナリオについての説明である。このＢＤ−Ｊモードにおける動的シナリオにより、ＰＬ再生と、プログラム的制御とを併せもったタイトルが定義されることになる。尚、本実施形態においてアプリケーションを構成するプログラム、データは、Ｊａｖａアーカイブファイルにまとめられたが、ＬＺＨファイル、ｚｉｐファイルであってもよい。
＜タイトル時間軸＞
タイトルを構成する静的シナリオ、動的シナリオについて説明を終えたところで、これらによりどのような時間軸が定義されるかについて説明する。タイトルにより定義される時間軸は、”タイトル時間軸”と呼ばれる。タイトル時間軸とは、Ｍｏｖｉｅオブジェクト、又は、ＢＤ−Ｊオブジェクトにより再生が命じられるＰＬにより構成される。ここで一例を挙げるのは、図９（ａ）のようなタイトルである。このタイトルは、トップメニュー→ｔｉｔｌｅ＃１→ｔｉｔｌｅ＃２→トップメニュー、トップメニュー→ｔｉｔｌｅ＃３→トップメニューという一連のタイトルである。かかるタイトルのうち、ｔｉｔｌｅ＃１はＰ１ａｙＬｉｓｔ＃１、ＰｌａｙＬｉｓｔ＃２、ｔｉｔｌｅ＃２がＰ１ａｙＬｉｓｔ＃３、ｔｉｔｌｅ＃３がＰｌａｙＬｉｓｔ＃４の再生を命じるものなら、図９（ｂ）のように、ＰｌａｙＬｉｓｔ＃１、ＰｌａｙＬｉｓｔ＃２の時間軸を足し合わせた時間軸を、ｔｉｔｌｅ＃１はもつことになる。同様にｔｉｔｌｅ＃２は、ＰｌａｙＬｉｓｔ＃３時間軸からなる時間軸を、ｔｉｔｌｅ＃３はＰｌａｙＬｉｓｔ＃４時間軸からなる時間軸を持つことになる。これらタイトル時間軸におけるＰＬ時間軸ではシームレス再生が保証されるが、タイトル時間軸間ではシームレス再生の保証は必要でなくなる。Ｊａｖａアプリケーションを動作させるにあたっては、Ｊａｖａアプリケーションを、仮想マシンのワークメモリ上に存在させてもよい期間（サービス期間）を、こうしたタイトル時間軸上に定義せねばならない。ＢＤ−ＪモードにおいてＪａｖａアプリケーションを動作させるにあたっては、互いに分岐し合う時間軸上に、Ｊａｖａアプリケーションのサービス期間を定義せねばならない。このサービス期間の定義が、ＢＤ−ＲＯＭ向けのプログラミングを行うにあたっての留意点になる。
最後に、ｉｎｄｅｘ．ｂｄｍｖに格納されたＩｎｄｅｘＴａｂｌｅにつぃて説明する。ＩｎｄｅｘＴａｂｌｅは、タイトル番号と、Ｍｏｖｉｅオブジェクト、ＢＤ−Ｊオブジェクトとを対応づけるテーブルであり、動的シナリオから動的シナリオへの分岐の際、参照される間接参照用テーブルである。ＩｎｄｅｘＴａｂｌｅは、複数ラベルのそれぞれに対するＩｎｄｅｘからなる。各Ｉｎｄｅｘには、そのラベルに対応する動的シナリオの識別子が記述されている。こうしたＩｎｄｅｘＴａｂｌｅを参照することで、Ｍｏｖｉｅオブジェクト、ＢＤ−Ｊオブジェクトの違いを厳密に区別することなく、分岐を実現することができる。ＩｎｄｅｘＴａｂｌｅについては、以下の国際公開公報に詳細が記載されてぃる。詳細については、本公報を参照されたい。
国際公開公報ＷＯ ２００４／０２５６５１Ａ１公報
以上がＢＤ−ＲＯＭに記録されているファイルについて説明である。
＜アプリケーション管理テーブル＞
ＪＭＦプレーヤインスタンス、ＪｕｍｐＴｉｔｌｅＡＰＩコールをもったアプリケーションが、タイトル時間軸を律することは上述した通りだが、ＪＭＦプレーヤインスタンスやＪｕｍｐＴｉｔｌｅＡＰＩのコールをもたないその他のアプリケーションを、タイトル時間軸上で動作させる場合、時間軸の何処からアプリケーションによるサービスを開始し、時間軸の何処でアプリケーションによるサービスを終えるかという”サービスの開始点・終了点”を明確に規定することが重要になる。本実施形態では、アプリケーションによるサービスが開始してから、終了するまでを、”アプリケーションの生存”として定義する。アプリケーションの生存を定義するための情報は、ＢＤ−Ｊオブジェクトにおけるアプリケーション管理テーブルに存在する。以降アプリケーション管理テーブルについてより詳しく説明する。
アプリケーション管理テーブル（ＡＭＴ）は、各タイトルが有しているタイトル時間軸において、仮想マシンのワークメモリ上で生存し得るアプリケーションを示す情報である。ワークメモリにおける生存とは、そのアプリケーションを構成するｘｌｅｔプログラムが、ワークメモリに読み出され、仮想マシンによる実行が可能になっている状態をいう。図７（ｂ）における破線矢印ａｔ１は、アプリケーション管理テーブルの内部構成をクローズアップして示す。この内部構成に示すように、アプリケーション管理テーブルは、『生存区間』と、そのタイトルを生存区間としているアプリケーションを示す『ａｐｐｌｉｃａｔｉｏｎＩＤ』と、そのアプリケーションの『起動属性』とからなる。
近い将来、実施されるであろうディスクコンテンツを題材に選んで、アプリケーション管理テーブルにおける生存区間記述について、具体例を交えて説明するここで題材にするディスクコンテンツは、映像本編を構成する本編タイトル（ｔｉｔｌｅ＃１）、オンラインショッピングを構成するオンラインショッピングタイトル（ｔｉｔｌｅ＃２）、ゲームアプリケーションを構成するゲームタイトル（ｔｉｔｌｅ＃３）という、性格が異なる３つのタイトルを含むものである。図１０は、本編タイトル、オンラインショッピングタイトル、ゲームタイトルという３つのタイトルを含むディスクコンテンツを示す図である。本図における右側にはＩｎｄｅｘＴａｂｌｅを記述しており、左側には３つのタイトルを記述している。
右側における破線枠は、各アプリケーションがどのタイトルに属しているかという帰属関係を示す。３つのタイトルのうちｔｉｔｌｅ＃１は、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３という３つのアプリケーションからなる。ｔｉｔｌｅ＃２は、ａｐｐｌｉｃａｔｉｏｎ＃３、ａｐｐｌｉｃａｔｉｏｎ＃４という２つのアプリケーション、ｔｉｔｌｅ＃３は、ａｐｐｌｉｃａｔｉｏｎ＃５を含む。図１１は、図１０に示した３つのタイトルの再生画像の一例を示す図である。これら３つのタイトルの再生画像において、図１１（ａ）（ｂ）の本編タイトル、オンラインショッピングタイトルには、ショッピングカートを模した映像（カートｃｒ１）１が存在するが、図１１（ｃ）のゲームタイトルには、カート映像が存在しない。カートｃｒ１は、本編タイトル、オンラインショッピングタイトルにおいて共通して表示しておく必要があるので、カートプログラムたるａｐｐｌｉｃａｔｉｏｎ＃３を、ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２の双方で起動するようにしている。このように複数タイトルで起動するようなアプリケーションには、上述したカートアプリの他に、映画作品に登場するマスコットを模したエージェントアプリ、メニューコール操作に応じてメニュー表示を行うメニューアプリがある。
図１０の破線に示される帰属関係から各アプリケーションの生存区間をグラフ化すると、図１２（ａ）のようになる。本図において横軸は、タイトル時間軸であり、縦軸方向に各アプリケーションの生存区間を配置してぃる。ここでａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２は、ｔｉｔｌｅ＃１のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃１内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃４は、ｔｉｔｌｅ＃２のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃２内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃５は、ｔｉｔｌｅ＃３のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃３内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃３は、ｔｉｔｌｅ＃１及びｔｉｔｌｅ＃２に帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃１−ｔｉｔｌｅ＃２にわたる。この生存区間に基づき、アプリケーション管理テーブルを記述すると、ｔｉｔｌｅ＃１，＃２，＃２のアプリケーション管理テーブルは図１２（ｂ）のようになる。このようにアプリケーション管理テーブルが記述されれば、ｔｉｔｌｅ＃１の再生開始時においてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３をワークメモリにロードしておく。そしてｔｉｔｌｅ＃２の開始時にａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２をワークメモリから削除してａｐｐｌｉｃａｔｉｏｎ＃３のみにするという制御を行う。これと同様にｔｉｔｌｅ＃２の再生開始時においてａｐｐｌｉｃａｔｉｏｎ＃４をワークメモリにロードしておき、ｔｉｔｌｅ＃３の開始時にａｐｐｌｉｃａｔｉｏｎ＃３，＃４をワークメモリから削除するという制御を行いうる。
更に、ｔｉｔｌｅ＃３の再生中においてａｐｐｌｉｃａｔｉｏｎ＃５をワークメモリにロードしておき、ｔｉｔｌｅ＃３の再生終了時にａｐｐｌｉｃａｔｉｏｎ＃５をワークメモリから削除するという制御を行いうる。
タイトル間分岐があった場合でも、分岐元−分岐先において生存しているアプリケーションはワークメモリ上に格納しておき、分岐元にはなく、分岐先にのみ存在するアプリケーションをワークメモリに読み込めば良いから、アプリケーションをワークメモリに読み込む回数は必要最低数になる。このように、読込回数を少なくすることにより、タイトルの境界を意識させないアプリケーション、つまりアンバウンダリなアプリケーションを実現することができる。
続いてアプリケーションの起動属性について説明する。起動属性には、自動的な起動を示す「ＡｕｔｏＲｕｎ」、自動起動の対象ではないが、仮想マシンのワークメモリに置いて良いことを示す「Ｐｅｒｓｉｓｔｅｎｔ」、仮想マシンのワークメモリにはおかれるが、ＣＰＵパワーの割り当ては不可となる「Ｓｕｓｐｅｎｄ」がある。
「ＡｕｔｏＲｕｎ」は、対応するタイトルの分岐と同時に、そのアプリケーションをワークメモリに読み込み、且つ実行する旨を示す生存区間である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、その分岐先タイトルにおいて生存しており、かつ起動属性がＡｕｔｏＲｕｎに設定されたアプリケーションを仮想マシンのワークメモリに読み込み実行する。これによりそのアプリケーションは、タイトル分岐と共に自動的に起動されることになる。起動属性をＡｕｔｏＲｕｎに設定しておくアプリケーションとしては、ＪＭＦプレーヤインスタンス及びＪｕｍｐＴｉｔｌｅＡＰＩコールをもつようなアプリケーションが挙げられる。何故なら、このようなアプリケーションは、タイトル時間軸を律する側のアプリケーションであり、このようなアプリケーションを自動的に起動にしないと、タイトル時間軸の概念が曖昧になってしまうからである。
起動属性「Ｐｅｒｓｉｓｔｅｎｔ」は、継続属性であり、分岐元ｔｉｔｌｅにおけるアプリケーションの状態を継続することを示す。またワークメモリにロードしてよいことを示す属性である。起動属性が「Ｐｅｒｓｉｓｔｅｎｔ」である場合、この起動属性が付与されたアプリケーションは、他のアプリケーションからの呼び出しが許可されることになる。アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、起動中のアプリケーションから呼出があると、そのアプリケーションのａｐｐｌｉｃａｔｉｏｎＩＤが、アプリケーション管理テーブルに記述されていて、起動属性が「Ｐｅｒｓｉｓｔｅｎｔ」であるか否かを判定する。「Ｐｅｒｓｉｓｔｅｎｔ」であれば、そのアプリケーションをワークメモリにロードする。一方、その呼出先アプリケーションのａｐｐｌｉｃａｔｉｏｎＩＤがアプリケーション管理テーブルに記述されていない場合、そのアプリケーションはワークメモリにロードされない。アプリケーションによる呼出は、この「Ｐｅｒｓｉｓｔｅｎｔ」が付与されたアプリケーションに限られることになる。
「Ｐｅｒｓｉｓｔｅｎｔ」は、起動属性を明示的に指定しない場合に付与されるデフォルトの起動属性であるから、あるアプリケーションの起動属性が無指定「−−」である場合、そのアプリケーションの起動属性の起動属性はこのＰｅｒｓｉｓｔｅｎｔであることを意味する。
これらの起動属性が、図１１のアプリケーションにおいてどのように記述されているかについて説明する。図１３は、図１２の３つのアプリケーションに対する起動属性の設定例である。図１２に示した３つのアプリケーションのうちａｐｐｌｉｃａｔｉｏｎ＃２は、図１３（ｂ）に示すように他のアプリケーションからのアプリケーション呼出があって初めて起動するアプリケーションであるとする。残りのａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃３は、ｔｉｔｌｅ＃１の開始と同時に自動的に起動されるアプリケーションであるとする。この場合、図１３（ａ）に示すように、アプリケーション管理テーブルにおける各アプリケーションの起動属性を、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃３は「ＡｕｔｏＲｕｎ」、ａｐｐｌｉｃａｔｉｏｎ＃２は、「Ｐｅｒｓｉｓｔｅｎｔ」と設定しておく。この場合、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃３は、ｔｉｔｌｅ＃１への分岐時において自動的にワークメモリにロードされ、実行されることになる。一方ａｐｐｌｉｃａｔｉｏｎ＃２は、起動属性がＰｅｒｓｉｓｔｅｎｔなので、「ａｐｐｌｉｃａｔｉｏｎ＃３は仮想マシンのワークメモリ上にロードしてよいアプリケーション」であるとの消極的な意味に解される。故に、ａｐｐｌｉｃａｔｉｏｎ＃２は、ａｐｐｌｉｃａｔｉｏｎ＃１からの呼出があって初めて仮想マシンのワークメモリにロードされ、実行されることになる。以上の生存区間・起動属性により、仮想マシン上で動作し得るアプリケーションの数を４個以下に制限し、総スレッド数を６４個以下に制限することが可能なので、アプリケーションの安定動作を保証することができる。
続いてＳｕｓｐｅｎｄについて説明する。
Ｓｕｓｐｅｎｄとは、リソースは割り付けられているがＣＰＵパワーは割り当てられない状態にアプリケーションが置かれることをいう。かかるＳｕｓｐｅｎｄは、例えばゲームタイトルの実行中に、サイドパスを経由するという処理の実現に有意義である。図１４（ａ）（ｂ）はＳｕｓｐｅｎｄが有意義となる事例を示す図である。図１４（ｂ）に示すように、３つのタイトル（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２、ｔｉｔｌｅ＃３）があり、そのうちｔｉｔｌｅ＃１、ｔｉｔｌｅ＃３はゲームアプリを実行するが、途中のｔｉｔｌｅ＃２はサイドパスであり、映像再生を実現するものである。サイドパスでは、映像再生を実現する必要があるため、ゲームの実行を中断させることになる。ゲームアプリでは途中のスコア等が計数されているため、リソースの格納値はｔｉｔｌｅ＃２の前後で維持したい。この場合、ｔｉｔｌｅ＃２の開始時点でゲームアプリをＳｕｓｐｅｎｄし、ｔｉｔｌｅ＃３の開始時点でａｐｐｌｉｃａｔｉｏｎ＃２をレジュームするというようにアプリケーション管理テーブルを記述する。こうすることでｔｉｔｌｅ＃２においてａｐｐｌｉｃａｔｉｏｎ＃２は、リソースは割り付けられているので、リソースの格納値は維持される。しかし、ＣＰＵパワーは割り当てられない状態なので仮想マシンによりａｐｐｌｉｃａｔｉｏｎ＃２は実行されることはない。これにより、ゲームタイトルの実行中に、サイドパスを実行するという処理が実現される。
図１５は、起動属性がとり得る三態様（Ｐｅｒｓｉｓｔｅｎｔ、ＡｕｔｏＲｕｎ、Ｓｕｓｐｅｎｄ）と、直前タイトルにおけるアプリケーション状態の三態様（非起動、起動中、Ｓｕｓｐｅｎｄ）とがとりうる組合せを示す図である。直前状態が”非起動”である場合、起動属性が”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、起動されることになる。
直前状態が”非起動”であり、起動属性が”Ｐｅｒｓｉｓｔｅｎ”、”Ｓｕｓｐｅｎｄ”であるなら、分岐先タイトルにおいてそのアプリケーションは、何ももせず、状態を継続することになる。
直前状態が”起動中”である場合、起動属性が”Ｐｅｒｓｉｓｔｅｎｔ”、”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。
起動属性が”Ｓｕｓｐｅｎｄ”であるなら、アプリケーションの状態はＳｕｓｐｅｎｄされることになる。直前状態が”Ｓｕｓｐｅｎｄ”である場合、分岐先タイトルの起動属性が”Ｓｕｓｐｅｎｄ”ならＳｕｓｐｅｎｄを維持することになる。”Ｐｅｒｓｉｓｔｅｎｔ”、”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、レジュー厶することになる。アプリケーション管理テーブルにおいて生存区間及び起動属性を定義することにより、タイトル時間軸の進行に沿って、Ｊａｖａアプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。以上が記録媒体についての説明である。続いて本発明に係る再生装置について説明する。
図１６は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムＬＳＩと、ドライブ装置という２つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムＬＳＩは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、ＢＤ−ＲＯＭドライブ１、リードバッファ２、デマルチプレクサ３、ビデオデコーダ４、ビデオプレーン５、Ｐ−Ｇｒａｐｈｉｃｓデコーダ９、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン１０、合成部１１、フォントゼネレータ１２、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１３、スイッチ１４、Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン１５、合成部１６、ＨＤＤ１７、リードバッファ１８、デマルチプレクサ１９、オーディオデコーダ２０、シナリオメモリ２１、ＣＰＵ２２、キーイベント処理部２３、命令ＲＯＭ２４、スイッチ２５、ＣＬＵＴ部２６、ＣＬＵＴ部２７、ＰＳＲセット２８、ローカルメモリ２９から構成される。
ＢＤ−ＲＯＭドライブ１は、ＢＤ−ＲＯＭのローディング／イジェクトを行い、ＢＤ−ＲＯＭに対するアクセスを実行する。
リードバッファ２は、ＦＩＦＯメモリであり、ＢＤ−ＲＯＭから読み出されたＴＳパケットが先入れ先出し式に格納される。
デマルチプレクサ（Ｄｅ−ＭＵＸ）３は、リードバッファ２からＴＳパケットを取り出して、このＴＳパケットを構成するＴＳパケットをＰＥＳパケットに変換する。そして変換により得られたＰＥＳパケットのうち、ＣＰＵ２２から設定されたＰＩＤをもつものをビデオデコーダ４、オーディオデコーダ２０、Ｐ−Ｇｒａｐｈｉｃｓデコーダ９、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１３のどれかに出力する。
ビデオデコーダ４は、デマルチプレクサ３から出力された複数ＰＥＳパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込む。
ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ領域である。再生装置に複数のプレーンを設けておき、これらプレーンの格納内容を画素毎に加算して、映像出力を行えば、複数の映像内容を合成させた上で映像出力を行うことができる。ビデオプレーン５における解像度は１９２０×１０８０であり、このビデオプレーン５に格納されたピクチャデータは、１６ビットのＹＵＶ値で表現された画素データにより構成される。
Ｐ−Ｇｒａｐｈｉｃｓデコーダ９は、ＢＤ−ＲＯＭ、ＨＤＤ１７から読み出されたプレゼンテーショングラフィクスストリームをデコードして、非圧縮グラフィクスをＰｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン１０に書き込む。グラフィクスストリームのデコードにより、字幕が画面上に現れることになる。
Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン１０は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。本プレーンにおける解像度は１９２０×１０８０であり、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン１０中の非圧縮グラフィクスの各画素は８ビットのインデックスカラーで表現される。ＣＬＵＴ（Ｃｏｌｏｒ Ｌｏｏｋｕｐ Ｔａｂｌｅ）を用いてかかるインデックスカラーを変換することにより、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン１０に格納された非圧縮グラフィクスは、表示に供される。
合成部１１は、非圧縮状態のピクチャデータ（ｉ）を、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン１０の格納内容と合成する。
フォントゼネレータ１２は、文字フォントを用いてｔｅｘｔＳＴストリームに含まれるテキストコードをビットマップに展開する。
Ｉ−Ｇｒａｐｈｉｃｓデコーダ１３は、ＢＤ−ＲＯＭ又はＨＤＤ１７から読み出されたインタラクティブグラフィクスストリームをデコードして、非圧縮グラフィクスをＩｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン１５に書き込む。
スイッチ１４は、フォントゼネレータ１２が生成したフォント列、Ｐ−Ｇｒａｐｈｉｃｓデコーダ９のデコードにより得られたグラフィクスの何れかを選択的にＰｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン１０に書き込むスイッチである。
Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン１５は、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１３によるデコードで得られた非圧縮グラフィクスが書き込まれる。
合成部１６は、Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン１０の格納内容と、合成部８の出力である合成画像（非圧縮状態のピクチャデータと、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｇｒａｐｈｉｃｓプレーン７の格納内容とを合成したもの）とを合成する。
ＨＤＤ１７は、ネットワーク等を介してダウンロードされたＳｕｂＣｌｉｐ、Ｃｌｉｐ情報、プレイリスト情報が格納される内蔵媒体である。このＨＤＤ１７中のプレイリスト情報はＢＤ−ＲＯＭ及びＨＤＤ１７のどちらに存在するＣｌｉｐ情報であっても、指定できる点で異なる。この指定にあたって、ＨＤＤ１７上のプレイリスト情報は、ＢＤ−ＲＯＭ上のファイルをフルパスで指定する必要はない。本ＨＤＤ１７は、ＢＤ−ＲＯＭと一体になって、仮想的な１つのドライブ（バーチャルパッケージと呼ばれる）として、再生装置により認識されるからである。故に、ＰｌａｙＩｔｅｍ情報におけるＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ及びＳｕｂＰｌａｙＩｔｅｍ情報のＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅは、Ｃｌｉｐ情報の格納したファイルのファイルボデイにあたる５桁の数値を指定することにより、ＨＤＤ１７、ＢＤ−ＲＯＭ上のＡＶＣｌｉｐを指定することができる。このＨＤＤの記録内容を読み出し、ＢＤ−ＲＯＭの記録内容と動的に組み合わせることにより、様々な再生のバリエーションを産み出すことができる。
リードバッファ１８は、ＦＩＦＯメモリであり、ＨＤＤ１７から読み出されたＴＳパケットが先入れ先出し式に格納される。
デマルチプレクサ（Ｄｅ−ＭＵＸ）１９は、リードバッファ１８からＴＳパケットを取り出して、ＴＳパケットをＰＥＳパケットに変換する。そして変換により得られたＰＥＳパケットのうち、所望のｓｔｒｅａｍＰＩＤをもつものをフォントゼネレータ１２に出力する。
オーディオデコーダ２０は、デマルチプレクサ１９から出力されたＰＥＳパケットを復号して、非圧縮形式のオーディオデータを出力する。
シナリオメモリ２１は、カレントのＰＬ情報やカレントのＣｌｉｐ情報を格納しておくためのメモリである。カレントＰＬ情報とは、ＢＤ−ＲＯＭに記録されている複数ＰＬ情報のうち、現在処理対象になっているものをいう。カレントＣｌｉｐ情報とは、ＢＤ−ＲＯＭに記録されている複数Ｃｌｉｐ情報のうち、現在処理対象になっているものをいう。
ＣＰＵ２２は、命令ＲＯＭ２４に格納されているソフトウェアを実行して、再生装置全体の制御を実行する。
キーイベント処理部２３は、リモコンや再生装置のフロントパネルに対するキー操作に応じて、その操作を行うキーイベントを出力する。
命令ＲＯＭ２４は、再生装置の制御を規定するソフトウェアを記憶している。
スイッチ２５は、ＢＤ−ＲＯＭ及びＨＤＤ１７から読み出された各種データを、リードバッファ２、リードバッファ１８、シナリオメモリ２１、ローカルメモリ２９のどれかに選択的に投入するスイッチである。
ＣＬＵＴ部２６は、ビデオプレーン５に格納された非圧縮グラフィクスにおけるインデックスカラーを、Ｙ，Ｃｒ，Ｃｂ値に変換する。
ＣＬＵＴ部２７は、Ｉｎｔｅｒａｃｔｉｖｅ Ｇｒａｐｈｉｃｓプレーン１５に格納された非圧縮グラフィクスにおけるインデックスカラーを、Ｙ，Ｃｒ，Ｃｂ値に変換する。
ＰＳＲセット２８は、再生装置に内蔵されるレジスタであり、６４個のＰｌａｙｅｒ Ｓｔａｔｕｓ Ｒｅｇｉｓｔｅｒ（ＰＳＲ）と、４０９６個のＧｅｎｅｒａｌ Ｐｕｒｐｏｓｅ Ｒｅｇｉｓｔｅｒ（ＧＰＲ）とからなる。Ｐｌａｙｅｒ Ｓｔａｔｕｓ Ｒｅｇｉｓｔｅｒの設定値（ＰＳＲ）のうち、ＰＳＲ４〜ＰＳＲ８は、現在の再生時点を表現するのに用いられる。
ＰＳＲ４は、１〜１００の値に設定されることで、現在の再生時点が属するタイトルを示し、０に設定されることで、現在の再生時点がトップメニューであることを示す。
ＰＳＲ５は、１〜９９９の値に設定されることで、現在の再生時点が属するチャプター番号を示し、ＯｘＦＦＦＦに設定されることで、再生装置においてチャプター番号が無効であることを示す。
ＰＳＲ６は、０〜９９９の値に設定されることで、現在の再生時点が属するＰＬ（カレントＰＬ）の番号を示す。
ＰＳＲ７は、０〜２５５の値に設定されることで、現在の再生時点が属するＰｌａｙ Ｉｔｅｍ（カレントＰｌａｙ Ｉｔｅｍ）の番号を示す。
ＰＳＲ８は、０〜ＯｘＦＦＦＦＦＦＦＦの値に設定されることで、４５ＫＨｚの時間精度を用いて現在の再生時点（カレントＰＴＭ（Ｐｒｅｓｅｎｔａｔｉｏｎ ＴｉＭｅ））を示す。以上のＰＳＲ４〜ＰＳＲ８により、現在の再生時点が特定されることになる。
ローカルメモリ２９は、ＢＤ−ＲＯＭからの読み出しは低速である故、ＢＤ−ＲＯＭの記録内容を一時的に格納しておくためのキャッシュメモリである。かかるローカルメモリ２９が存在することにより、ＢＤ−Ｊモードにおけるアプリケーション実行は、効率化されることになる。図１７（ａ）は、ＢＤ−ＲＯＭに存在しているＪａｖａアーカイブファイルを、ローカルメモリ２９上でどのように識別するかを示す図である。図１７（ａ）の表は、左欄にＢＤ−ＲＯＭ上のファイル名を、右欄にローカルメモリ２９上のファイル名をそれぞれ示してぃる。これら右欄、左欄を比較すれば、ローカルメモリ２９におけるファイルは、ディレクトリ指定”ＢＤＪＡ”を省いたファイルパスで指定されていることがわかる。
図１７（ｂ）は、図１７（ａ）の応用を示す図である。本応用例は、ヘッダ＋データという形式で、ファイルに格納されているデータを格納するというものである。何をヘッダに用いるかというと、ローカルメモリ２９におけるファイルパスを用いる。図１７（ｂ）に示したように、ローカルメモリ２９ではＢＤ−ＲＯＭにおけるファイルパスの一部を省略したものをファイルパスに用いるから、当該ファイルパスをヘッダに格納することで、各データにおけるＢＤ−ＲＯＭ上の所在を明らかにすることができる。
以上が、本実施形態に係る再生装置のハードウェア構成である。続いて本実施形態に係る再生装置のソフトウェア構成について説明する。
図１８は、ＲＯＭ２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。本図に示すように、再生装置のレイア構成は、以下のａ），ｂ），ｃ），ｄ−１），ｄ−２），ｅ），ｆ）からなる。つまり、
ａ）物理的なハードウェア階層の上に、
ｂ）ＡＶＣｌｉｐによる再生を制御するＰｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１、
ｃ）プレイリスト情報及びＣｌｉｐ情報に基づく再生制御を行うＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２、
という２つの階層があり、
最上位の階層に
ｅ）タイトル間の分岐を実行するモジュールマネージャ３４がある。
これらＨＤＭＶモジュール３３、モジュールマネージャ３４の間に、
ｄ−１）Ｍｏｖｉｅオブジェクトの解読・実行主体であるＨＤＭＶモジュール３３と、
ｄ−２）ＢＤ−Ｊオブジェクトの解読・実行を行うＢＤ−Ｊモジュール３５とが同じ階層に置かれている。
ＢＤ−Ｊモジュール３５は、いわゆるＪａｖａプラットフォームであり、ワークメモリ３７を含むＪａｖａ仮想マシン３８を中核にした構成になっていて、アプリケーションマネージャ３６、Ｅｖｅｎｔ Ｌｉｓｔｎｅｒ Ｍａｎａｇｅｒ３９、Ｄｅｆａｕｌｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ４０から構成される。先ず初めに、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１〜モジュールマネージャ３４について説明する。図１９は、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１〜モジュールマネージャ３４による処理を模式化した図である。
Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１は、ＡＶ再生機能を実行する。再生装置のＡＶ再生機能とは、ＤＶＤプレーヤ、ＣＤプレーヤから踏襲した伝統的な機能群であり、再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（Ｐａｕｓｅ Ｏｎ）、一時停止の解除（Ｐａｕｓｅ Ｏｆｆ）、Ｓｔｉｌｌ機能の解除（ｓｔｉｌｌ ｏｆｆ）、速度指定付きの早送り（Ｆｏｒｗａｒｄ Ｐｌａｙ（ｓｐｅｅｄ））、速度指定付きの巻戻し（Ｂａｃｋｗａｒｄ Ｐｌａｙ（ｓｐｅｅｄ））、音声切り換え（Ａｕｄｉｏ Ｃｈａｎｇｅ）、副映像切り換え（Ｓｕｂｔｉｔｌｅ Ｃｈａｎｇｅ）、アングル切り換え（Ａｎｇｌｅ Ｃｈａｎｇｅ）といった機能である。ＡＶ再生機能を実現するべく、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１は、リードバッファ２上に読み出されたＡＶＣｌｉｐのうち、所望に時刻にあたる部分のデコードを行うよう、ビデオデコーダ４、Ｐ−Ｇｒａｐｈｉｃｓデコーダ９、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１３、オーディオデコーダ２０を制御する。所望の時刻としてＰＳＲ８（カレントＰＴＭ）に示される箇所のデコードを行わせることにより、ＡＶＣｌｉｐにおいて、任意の時点を再生を可能することができる。図中の◎１は、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１よるデコード開始を模式化して示す。
再生制御エンジン（Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ（ＰＣＥ））３２は、プレイリストの再生機能（ｉ）、再生装置における状態取得／設定機能（ｉｉ）といった諸機能を実行する。ＰＬの再生機能とは、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１が行うＡＶ再生機能のうち、再生開始や再生停止を、カレントＰＬ情報及びＣｌｉｐ情報に従って行わせることをいう。これら機能（ｉ）〜（ｉｉ）は、ＨＤＭＶモジュール３３〜ＢＤ−Ｊモジュール３５からのファンクションコールに応じて実行する。つまり再生制御エンジン３２は、ユーザ操作による指示、レイヤモデルにおける上位層からの指示に応じて、自身の機能を実行する。図１９において、◎２，◎３が付された矢印は、Ｃｌｉｐ情報及びプレイリスト情報に対するＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２の参照を模式的に示す。
ＨＤＭＶモジュール３３は、ＭＯＶＩＥモードの実行主体であり、モジュールマネージャ３４から分岐先を構成するＭｏｖｉｅオブジェクトが通知されれば、分岐先タイトルを構成するＭｏｖｉｅオブジェクトをローカルメモリ２９に読み出して、このＭｏｖｉｅオブジェクトに記述されたナビゲーションコマンドを解読し、解読結果に基づきＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に対するファンクションコールを実行する。図１９において▽２，▽３，▽４が付された矢印は、モジュールマネージャ３４からの分岐先Ｍｏｖｉｅオブジェクトの通知（２）、Ｍｏｖｉｅオブジェクトに記述されたナビゲーションコマンドの解読（３）、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に対するファンクションコール（４）を、模式的に示している。
モジュールマネージャ３４は、ＢＤ−ＲＯＭから読み出されたＩｎｄｅｘ Ｔａｂｌｅを保持して、分岐制御を行う。この分岐制御は、ＪｕｍｐＴｉｔｌｅコマンドをＨＤＭＶモジュール３３が実行した場合、又は、タイトルジャンプＡＰＩがＢＤ−Ｊモジュール３５からコールされた場合、そのジャンプ先となるタイトル番号を受け取って、そのタイトルを構成するＭｏｖｉｅオブジェクト又はＢＤ−ＪオブジェクトをＨＤＭＶモジュール３３又はＢＤ−Ｊモジュール３５に通知するというものである。図中の▽０，▽１，▽２が付された矢印は、ＪｕｍｐＴｉｔｌｅコマンドの実行（０）、モジュールマネージャ３４によるＩｎｄｅｘＴａｂｌｅ参照（１）、分岐先Ｍｏｖｉｅオブジェクト（２）の通知を模式的に示している。
以上がＰｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１〜モジュールマネージャ３４についての説明である。続いてアプリケーションマネージャ３６について、図２０を参照しながら説明する。図２０は、アプリケーションマネージャ３６を示す図である。
アプリケーションマネージャ３６は、アプリケーション管理テーブルを参照したアプリケーションの起動制御、タイトルの正常終了時における制御を実行する。
起動制御とは、モジュールマネージャ３４から分岐先となるＢＤ−Ｊオブジェクトが通知される度に、そのＢＤ−Ｊオブジェクトを読み出し、そのＢＤ−Ｊオブジェクト内のアプリケーション管理テーブルを参照してローカルメモリ２９アクセスを行う。そして現在の再生時点を生存区間とするアプリケーションを構成するｘｌｅｔプログラムを、ワークメモリに読み出すという制御である。図２０における☆１，☆２，☆３は、起動制御における分岐先ＢＤ−Ｊオブジェクトの通知（１）、アプリケーション管理テーブル参照（２）、Ｊａｖａ仮想マシン３８に対する起動指示を模式化して示す。この起動指示によりＪａｖａ仮想マシン３８は、ローカルメモリ２９からワークメモリ３７にｘｌｅｔプログラムを読み出す（☆５）。
タイトルの終了制御には、正常終了時の制御と、異常終了時の制御とがある。正常終了時の制御には、タイトルを構成するアプリケーションによりジャンプタイトルＡＰＩがコールされて、分岐先タイトルへの切り換えを分岐制御の主体（モジュールマネージャ３４）に要求するという制御がある。この終了制御における、モジュールマネージャ３４通知を模式化して示したのが矢印☆６である。ここでタイトルを正常終了するにあたって、タイトルを構成するアプリケーションは、起動されたままであってもよい。何故なら、アプリケーションを終了するか否かは、分岐先タイトルにおいて判断するからである。本実施形態では深く触れないが、アプリケーションマネージャ３６は、ＢＤ−ＲＯＭからローカルメモリ２９にＪａｖａアーカイブファイルを読み出す（８）との処理を行う。このローカルメモリ２９への読み出しを模式化したのが☆８である。
以上がアプリケーションマネージャ３６についての説明である。続いてワークメモリ３７〜Ｄｅｆａｕｌｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ４０について、図２１を参照しながら説明する。
ワークメモリ３７は、アプリケーションを構成するｘｌｅｔプログラムが配置されるヒープ領域である。ワークメモリ３７は、本来Ｊａｖａ仮想マシン３８内に存在するが、図２１では、作図の便宜上、ワークメモリ３７をＪａｖａ仮想マシン３８上位層に記述している。ワークメモリ３７上のｘｌｅｔプログラムには、ＥｖｅｎｔＬｉｓｔｎｅｒや、ＪＭＦプレーヤインスタンスが含まれる。
Ｊａｖａ仮想マシン３８は、アプリケーションを構成するｘｌｅｔプログラムをワークメモリ３７にロードして、ｘｌｅｔプログラムを解読し、解読結果に従った処理を実行する。上述したようにｘｌｅｔプログラムは、ＪＭＦプレーヤインスタンス生成を命じるメソッド、このＪＭＦプレーヤインスタンスの実行を命じるメソッドを含むので、これらのメソッドで命じられた処理内容を実現するよう、下位層に対する制御を行う。ＪＭＦプレーヤインスタンス生成が命じられば、Ｊａｖａ仮想マシン３８は、ＢＤ−ＲＯＭ上のＹＹＹＹ．ＭＰＬＳファイルに関連付けられたＪＭＦプレーヤインスタンスを得る。また、ＪＭＦプレーヤインスタンスにおけるＪＭＦメソッドの実行が命じられれば、このＪＭＦメソッドをＢＤミドルウェアに発行して、ＢＤ再生装置が対応しているファンクションコールに置き換させる。そして置換後のファンクションコールをＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に発行する。
Ｅｖｅｎｔ Ｌｉｓｔｎｅｒ Ｍａｎａｇｅｒ３９は、ユーザ操作により生じたイベント（キーイベント）を解析し、イベントの振り分けを行う。図中の実線矢印◇１，◇２は、このＥｖｅｎｔ Ｌｉｓｔｎｅｒ Ｍａｎａｇｅｒ３９による振り分けを模式的に示す。ＳＴＡＲＴ、ＳＴＯＰ、ＳＰＥＥＤ等、ｘｌｅｔプログラム内のＥｖｅｎｔ Ｌｉｓｔｎｅｒに登録されたキーイベントなら、ＢＤ−Ｊオブジェクトにより間接参照されているｘｌｅｔプログラムにかかるイベントを振り分ける。ＳＴＡＲＴ、ＳＴＯＰ、ＳＰＥＥＤは、ＪＭＦに対応したイベントであり、ｘｌｅｔプログラムのＥｖｅｎｔ Ｌｉｓｔｎｅｒには、これらのキーイベントが登録されているので、本キーイベントによりｘｌｅｔプログラムの起動が可能になる。キーイベントがＥｖｅｎｔ Ｌｉｓｔｎｅｒ非登録のキーイベントである場合、本キーイベントをＤｅｆａｕｌｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ４０に振り分ける。音声切り換え、アングル切り換え等、ＢＤ−ＲＯＭ再生装置において生じるキーイベントには、Ｅｖｅｎｔ Ｌｉｓｔｎｅｒに登録されていない多様なものがあり、これらのキーイベントが生じたとしても、漏れの無い処理を実行するためである。
Ｄｅｆａｕｌｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ４０は、ｘｌｅｔプログラム内のＥｖｅｎｔ Ｌｉｓｔｎｅｒに登録されてないキーイベントがＥｖｅｎｔ Ｌｉｓｔｎｅｒ Ｍａｎａｇｅｒ３９から振り分けられると、そのＥｖｅｎｔ Ｌｉｓｔｎｅｒ非登録イベントに対応するファンクションコールをＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に対して実行する。このＤｅｆａｕｌｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ４０によるファンクションコールを模式的に示したのが、図中の矢印◇３である。尚、図２１においてＥｖｅｎｔ Ｌｉｓｔｎｅｒ非登録イベントはＥｖｅｎｔ Ｌｉｓｔｎｅｒ Ｍａｎａｇｅｒ３９、Ｄｅｆａｕｌｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ４０により振り分けられたが、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２がダイレクトにＥｖｅｎｔ Ｌｉｓｔｎｅｒ非登録イベントを受け取り、再生制御を行ってもよい（図中の◇４）。
。
（フローチャートの説明）
以上のアプリケーションマネージャ３６についての説明は、その概要に触れたに過ぎない。アプリケーションマネージャ３６の処理を更に詳しく示したのが図２２、図２３のフローチャートである。以降、これらのフローチャートを参照してアプリケーションマネージャ３６の処理手順についてより詳しく説明する。
図２２は、アプリケーションマネージャ３６による分岐時の制御手順を示す図である。本フローチャートは、ステップＳ２〜ステップＳ５がなす条件を満たすアプリケーション（アプリケーションｘという）を、起動又は終了させるという処理である。
ステップＳ２は、分岐元タイトルで非起動だが、分岐先タイトルで生存していて、分岐先タイトルにおける起動属性がＡｕｔｏＲｕｎ属性のアプリケーションｘが存在するか否かの判定であり、もしあれば、ローカルメモリ２９に対するキャッシュセンスを行う。キャッシュセンスの結果、アプリケーションｘがローカルメモリ２９上に有れば（ステップＳ７でＹｅｓ）、ローカルメモリ２９からワークメモリ３７にアプリケーションｘを読み込む（ステップＳ８）。ローカルメモリ２９に無ければ、ＢＤ−ＲＯＭからローカルメモリ２９にアプリケーションｘを読み込んだ上で、ローカルメモリ２９からワークメモリ３７にアプリケーションｘを読み込む（ステップＳ９）。
ステップＳ３は、分岐元タイトルで起動中で、分岐先タイトルで非生存のアプリケーションｘが存在するかどうかの判定である。もし存在するのなら、アプリケーションｘをワークメモリ３７から削除して終了させる（ステップＳ１０）。
ステップＳ４は、分岐元Ｓｕｓｐｅｎｄ、分岐先ＡｕｔｏＲｕｎ又はＰｅｒｓｉｓｔｅｎｔのアプリケーションが存在するか否かの判定である。もし存在するなら、アプリケーションｘをＲｅｓｕｍｅする（ステップＳ１１）。
ステップＳ５は、分岐元タイトルで起動中で、分岐先Ｓｕｓｐｅｎｄのアプリーションが存在するか否かの判定である。もし存在すれば、アプリケーションｘをＳｕｓｐｅｎｄする（ステップＳ１２）。
個々のアプリケーションを終了させるにあたってのアプリケーションマネージャ３６の処理は、図２３に示すものとなる。図２３は、アプリケーション終了処理の処理手順を示すフローチャートである。本図は、終了すべき複数アプリケーションのそれぞれについて、ステップＳ１６〜ステップＳ２０の処理を繰り返すループ処理になっている（ステップＳ１５）。本ループ処理においてアプリケーションマネージャ３６は起動中アプリケーションを終了するようなｔｅｒｍｉｎａｔｅイベントを発行し（ステップＳ１６）、タイマセットして（ステップＳ１７）、ステップＳ１８〜ステップＳ２０からなるループ処理に移行する。このｔｅｒｍｉｎａｔｅイベントをＥｖｅｎｔ Ｌｉｓｔｎｅｒが受信すれば、対応するｘｌｅｔプログラムは、終了プロセスを起動する。終了プロセスが終了すれば、そのｘｌｅｔプログラムはワークメモリ３７から解放され、終了することになる。
ステップＳ１８〜ステップＳ２０のループ処理の継続中、タイマはカウントダウンを継続する。本ループ処理においてステップＳ１８は、発行先アプリケーションが終了したか否かの判定であり、もし終了していればこのアプリケーションに対する処理を終える。ステップＳ１９は、タイマがタイムアウトしたか否かの判定であり、タイムアウトすれば、ステップＳ２０において発行先アプリケーションをワークメモリ３７から削除してアプリケーションを強制終了する。
以上のモジュールマネージャ３４の処理を、図２４を参照しながら説明する。
図２４は、アプリケーション終了の過程を模式的に示した図である。本図における第１段目は、アプリケーションマネージャ３６を、第２段目は、３つのアプリケーションを示す。図２４の第２段目、左側のアプリケーションは、ｔｅｒｍｉｎａｔｅイベントを受信して終了プロセスに成功したアプリケーションを示す。図２４の第２段目、中列のアプリケーションは、ｔｅｒｍｉｎａｔｅイベントを受信したが終了プロセスに失敗したアプリケーションを示す。第２段目、右側のアプリケーションは、ＥｖｅｎｔＬｉｓｔｎｅｒが実装されていないので、ｔｅｒｍｉｎａｔｅイベントを受信することができなかったアプリケーションを示す。
第１段目−第２段目間の矢印ｅｐ１，ｅｐ２は、アプリケーションマネージャによるｔｅｒｍｉｎａｔｅイベント発行を模式的に示し、矢印ｅｐ３は、終了プロセス起動を模式的に示している。
第３段目は、終了プロセス成功時における状態遷移後の状態であり、このアプリケーションは、自身の終了プロセスにより終了することになる。これらｘｌｅｔプログラムのように、所定の期間内に終了しないアプリケーションがあれば、アプリケーションマネージャ３６は、それらを強制的にワークメモリ３７から取り除く。第４段目は、アプリケーションマネージャ３６による強制終了を示す。かかる第４段目の強制終了を規定するのも、アプリケーションマネージャ３６の１つの使命といえる。
以上のように本実施形態によれば、分岐元タイトルで起動しており、分岐先タイトルで生存していないアプリケーションは、自動的に終了させられるので、条件付き分岐により再生が複雑に進行する場合でも、再生装置におけるリソースの限界を越える数のアプリケーション立ち上げはなされ無い。分岐前後におけるアプリケーション動作を保証することができるので、デジタルストリームを再生させながら、アプリケーションを実行させるようなディスクコンテンツを多く頒布することができる。
（第２実施形態）
第１実施形態においてアプリケーションの生存区間は、タイトル時間軸と一致していたが、第２実施形態は、ＰＬ時間軸の一部をアプリケーションの生存区間とすることを提案する。ＰＬ時間軸の一部は、チャプターにより表現されるので、チャプターにて開始点、終了点を記述することにより、アプリケーションの生存区間を規定することができる。図２５（ａ）は、ＰＬ時間軸上に生存区間を定めたアプリケーション管理テーブルを示す図である。図２５（ａ）においてアプリケーション管理テーブルには、３つのアプリケーションが記述されており、このうちａｐｐｌｉｃａｔｉｏｎ＃２は、ｔｉｔｌｅ＃１のＣｈａｐｔｅｒ＃２からＣｈａｐｔｅｒ＃３までが生存区間に指定され、起動属性にＡｕｔｏＲｕｎが規定されている。このためａｐｐｌｉｃａｔｉｏｎ＃２は、図２５（ｂ）に示すように、Ｃｈａｐｔｅｒ＃２の始点で起動され、Ｃｈａｐｔｅｒ＃３の終点で終了することになる。
一方ａｐｐｌｉｃａｔｉｏｎ＃３は、ｔｉｔｌｅ＃１のＣｈａｐｔｅｒ＃４からＣｈａｐｔｅｒ＃６までが生存区間に指定されている。このためａｐｐｌｉｃａｔｉｏｎ＃３は、図２５（ｂ）に示すように、図２５（ｂ）に示すように、Ｃｈａｐｔｅｒ＃４の始点で起動され、Ｃｈａｐｔｅｒ＃６の終点で終了することになる。
こうして記述されたアプリケーション管理テーブルに基づき、処理を行うため本実施形態に係るアプリケーションマネージャ３６は、ＰＬｍａｒｋより指示されるチャプター開始点に到達する度に、そのチャプター開始点から生存区間が始まるアプリケーションが存在するか否かを判定し、もし存在すればそのアプリケーションをワークメモリ３７にロードする。
同様に、チャプター開始点に到達する度に、そのチャプターの直前のチャプターで生存区間が終わるアプリケーションが存在するか否かを判定し、もし存在すればそのアプリケーションをワークメモリ３７から解放する。
チャプターという単位でアプリケーションの生存を管理すれば、アプリケーションの生存区間をより細かい精度で指定することができる。しかしディスクコンテンツには、時間軸の逆向がありうることに留意せねばならない。逆行とは、巻戻しにより時間軸を逆向きに進行することである。チャプターの境界でこの逆行と、進行とが繰り返されれば、ワークメモリへのロード、廃棄が何度もなされ、余分な読出負荷が生じる。そこで本実施形態では、アプリケーションの起動時期を、タイトルに入ってＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２による通常再生が開始された瞬間にしている。ここでＰＬの再生には、通常再生、トリック再生がある。トリック再生とは、早送り、巻戻し、ＳｋｉｐＮｅｘｔ，ＳｋｉｐＢａｃｋがある。かかる、早送り、巻戻し、ＳｋｉｐＮｅｘｔ，ＳｋｉｐＢａｃｋがなされている間、アプリケーション起動を開始せず、通常再生が開始されて初めて、アプリケーションを起動するのである。通常再生開始の瞬間を基準にすることにより、上述したような生存区間前後の行き来があった場合でも、アプリケーションの起動が必要以上に繰り返されることはない。尚、通常再生開始の瞬間を、アプリケーションの起動基準にするとの処理は、生存区間がｔｉｔｌｅである場合にも、実行してよい。
以上のように本実施形態によれば、ＰＬより小さい、チャプターの単位でアプリケーションの生存区間を規定することができるので、緻密なアプリケーション制御を実現することができる。
（第２実施形態の変更例）
図２５では、各アプリケーションに優先度が付与されている。この優先度は、０〜２５５の値をとり、アプリケーション間でリソースの使用が競合等が競合した場合、どちらのアプリケーションを強制的に終了させるか、また、どちらのアプリケーションからリソースを奪うかという処理をアプリケーションマネージャ３６が行うにあたって、判断材料になる。図２５の一例では、ａｐｐｌｉｃａｔｉｏｎ＃１の優先度は２５５，ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３の優先度は１２８なので、ａｐｐｌｉｃａｔｉｏｎ＃１−ａｐｐｌｉｃａｔｉｏｎ＃２の競合時において、アプリケーションマネージャ３６は優先度が低いａｐｐｌｉｃａｔｉｏｎ＃２を強制終了するとの処理を行う。
（第３実施形態）
ＢＤ−ＲＯＭにより供されるディスクコンテンツは、互いに分岐可能な複数タイトルから構成される。各タイトルは、１つ以上のＰＬと、このＰＬを用いた制御手順とからなるもの以外に、再生装置に対する制御手順のみからなる非ＡＶ系タイトルがある。本実施形態は、この非ＡＶ系タイトルについて説明する。
こうした非ＡＶ系タイトルのタイトルでは、どのようにタイトル時間軸を定めるのかが問題になる。図２６（ａ）は、ＰＬ時間軸から定まるタイトル時間軸を示す。この場合ＰＬ時間軸がタイトル時間軸になり、このタイトル時間軸上にアプリケーションの生存区間が定まる。この基準となるＰＬ時間軸がない場合、タイトル時間軸は図２６（ｂ）（ｃ）のように定めるべきである。
図２６（ｂ）は、メインとなるアプリケーションの生存区間から定まるタイトル時間軸を示す。メインアプリとは、タイトルにおいて起動属性がＡｕｔｏＲｕｎに設定され、タイトル開始時に自動起動される唯一のアプリケーションであり、例えばランチャーアプリと呼ばれるものがこれにあたる。ランチャーアプリとは、他のアプリケーションを起動するアプリケーションプログラムである。
この図２６（ｂ）の考え方は、メインアプリが起動している限り、タイトル時間軸は継続していると考え、メインアプリが終了すれば、時間軸を終結させるというものである。図２６（ｃ）は、複数アプリケーションの生存区間から定まるタイトル時間軸を示す図である。タイトルの開始点で起動されるのは１つのアプリケーションであるが、このアプリケーションが他のアプリケーションを呼び出し、更にこのアプリケーションが別のアプリケーションを呼び出すとの処理が繰り返されるというケースがある。この場合、どれかのアプリケーションが起動している限り、タイトル時間軸は継続していると考え、どのアプリケーションも起動していない状態が到来すれば、そこでタイトル時間軸は終結するという考え方である。このように非ＡＶ系タイトルのタイトル時間軸を定めれば、ＡＶタイトルであっても、非ＡＶ系タイトルであっても、タイトル時間軸の終結と同時に、所定のタイトルに分岐するという処理を画一的に行うことができる。尚非ＡＶタイトルにおけるタイトル時間軸は、ＡＶタイトルと対比する上で、想定した架空の時間軸に過ぎない。故に再生装置は、非ＡＶタイトルにおけるタイトル時間軸上を逆行したり、任意の位置に頭出しすることができない。
以上は本実施形態における記録媒体に対する改良である。続いて本実施形態における再生装置に対する改良について説明する。
上述したような手順でタイトル終了を行うため第３実施形態に係るアプリケーションマネージャ３６は、図２７に示すような処理で処理を行う。図２７は、タイトル再生時におけるアプリケーションマネージャ３６の処理手順を示すフローチャートである。本フローチャートは、タイトル再生中、ステップＳ２１〜ステップＳ２３を繰り返すというループ構造になっている。
ステップＳ２１は、タイトルジャンプＡＰＩが呼び出されたか否かの判定であり、呼び出されれば、ジャンプ先タイトルへの分岐をモジュールマネージャ３４に要求する（ステップＳ２７）。
ステップＳ２２は、タイトル内のアプリケーション呼出を担っているようなメインアプリが存在するか否かの判定であり、もし存在するなら、それの起動の有無を確認する（ステップＳ２５）。起動してなければ、”タイトルの終わり”であると解釈し、モジュールマネージャ３４に終結を通知する（ステップＳ２６）。
ステップＳ２３は、メインアプリがない場合に実行されるステップであり（ステップＳ２２でＮｏ）、どのアプリケーションも起動してない状態かどうかを判定する。もしそうなら、同じく”タイトルの終わり”であると解釈し、モジュールマネージャ３４に終結を通知する（ステップＳ２６）。
以上のように本実施形態によれば、ＰＬ再生を伴わないタイトルであっとしても、アプリケーション実行中は分岐せず、アプリケーション実行が終了して初めて分岐するという処理が可能になる。
（第４実施形態）
本実施形態は、ＤＶＤと同様のメニュー制御をＢＤ−ＲＯＭ上で実現する場合の改良に関する。図２８（ａ）は、ＢＤ−ＲＯＭにより実現されるメニュー階層を示す図である。本図におけるメニュー階層は、ＴｏｐＭｅｎｕを最上位に配し、このＴｏｐＭｅｎｕから下位のＴｉｔｌｅＭｅｎｕ、ＳｕｂＴｉｔｌｅＭｅｎｕ、ＡｕｄｉｏＭｅｎｕを選択できる構造になっている。図中の矢印ｓｗ１，２，３は、ボタン選択によるメニュー切り換えを模式的に示す。ＴｏｐＭｅｎｕとは、音声選択、字幕選択、タイトル選択の何れを行うかを受け付けるボタン（図中のボタンｓｎ１，ｓｎ２，ｓｎ３）を配置したメニューである。
ＴｉｔｌｅＭｅｎｕとは、映画作品（ｔｉｔｌｅ）の劇場版を選択するか、ディレクターズカット版を選択するか、ゲーム版を選択するか等、映画作品の選択を受け付けるボタンを配置したメニューである。ＡｕｄｉｏＭｅｎｕとは、音声再生を日本語で行うか、英語で行うかを受け付けるボタンを配置したメニュー、ＳｕｂＴｉｔｌｅＭｅｎｕとは、字幕表示を日本語で行うか、英語で行うかを受け付けるボタンを配置したメニューである。
こうした階層をもったメニューを動作させるためのＭＯＶＩＥオブジェクトを図２８（ｂ）に示す。図２８（ｂ）においてＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖには、ＦｉｒｓｔＰｌａｙ ＯＢＪ、ＴｏｐＭｅｎｕ ＯＢＪ、ＡｕｄｉｏＭｅｎｕ ＯＢＪ、ＳｕｂＴｉｔｌｅＭｅｎｕ ＯＢＪが格納されている。
ＦｉｒｓｔＰｌａｙオブジェクト（ＦｉｒｓｔＰｌａｙ ＯＢＪ）は、再生装置へのＢＤ−ＲＯＭのローディング時に自動的に実行される動的シナリオである。
ＴｏｐＭｅｎｕオブジェクト（ＴｏｐＭｅｎｕ ＯＢＪ）は、ＴｏｐＭｅｎｕの挙動を制御する動的シナリオである。ユーザがメニューコールを要求した際、呼び出されるのはこのＴｏｐＭｅｎｕオブジェクトである。ＴｏｐＭｅｎｕオブジェクトは、ユーザからの操作に応じてＴｏｐＭｅｎｕ中のボタンの状態を変えるものや、ボタンに対する確定操作に応じて分岐を行う分岐コマンドを含む。この分岐コマンドは、ＴｏｐＭｅｎｕからＴｉｔｌｅＭｅｎｕ、ＴｏｐＭｅｎｕからＳｕｂＴｉｔｌｅＭｅｎｕ、ＴｏｐＭｅｎｕからＡｕｄｉｏＭｅｎｕというメニュー切り換えを実現するものである。
ＡｕｄｉｏＭｅｎｕオブジェクト（ＡｕｄｉｏＭｅｎｕ ＯＢＪ）は、ＡｕｄｉｏＭｅｎｕの挙動を制御する動的シナリオであり、ユーザからの操作に応じてＡｕｄｉｏＭｅｎｕ中のボタンの状態を変えるコマンドや、ボタンに対する確定操作に応じて音声設定を更新するコマンドを含む。
ＳｕｂＴｉｔｌｅＭｅｎｕオブジェクト（ＳｕｂＴｉｔｌｅＭｅｎｕ ＯＢＪ）は、ＳｕｂＴｉｔｌｅＭｅｎｕの挙動を制御する動的なシナリオであり、ユーザからの操作に応じてＳｕｂＴｉｔｌｅＭｅｎｕ中のボタンの状態を変えるコマンドや、ボタンに対する確定操作に応じて字幕設定用のＰＳＲを更新するコマンドを含む。
ＴｉｔｌｅＭｅｎｕオブジェクト（ＴｉｔｌｅＭｅｎｕ ＯＢＪ）は、ＴｉｔｌｅＭｅｎｕの挙動を制御する動的シナリオであり、ＴｉｔｌｅＭｅｎｕ中のボタンの状態を変えるものや、ボタンに対する確定操作に応じて分岐を行う分岐コマンドをふくむ。
これらのメニュー用ＭＯＶＩＥオブジェクトにより、ＤＶＤで実現されているようなメニューの挙動を実現することができる。以上がメニュー制御に関連するＭＯＶＩＥオブジェクトである。
図２９は、Ｉｎｄｅｘ Ｔａｂｌｅと、Ｉｎｄｅｘ Ｔａｂｌｅから各Ｍｏｖｉｅオブジェクトへの分岐とを模式化した図である。本図では左側にＩｎｄｅｘ Ｔａｂｌｅの内部構成を示している。本実施形態におけるＩｎｄｅｘ Ｔａｂｌｅには、ＦｉｒｓｔＰＬａｙＩＮＤＥＸ、ＴｏｐＭｅｎｕＩＮＤＥＸ，Ａｕｄｉｏ ＭｅｎｕＩＮＤＥＸ、Ｓｕｂｔｉｔｌｅ ＭｅｎｕＩＮＤＥＸ、ｔｉｔｌｅ ＭｅｎｕＩＮＤＥＸ、ｔｉｔｌｅ＃１〜＃ｍＩＮＤＥＸ、ｔｉｔｌｅ＃ｍ＋１〜＃ｎＩＮＤＥＸ、ｔｉｔｌｅ＃０ＩＮＤＥＸを含む。図中の矢印ｂｃ１，２は、Ｉｎｄｅｘ ＴａｂｌｅからＦｉｒｓｔＰｌａｙＯＢＪへの分岐と，ＦｉｒｓｔＰｌａｙＯＢＪからＴｏｐＭｅｎｕへの分岐とを模式的に示し、矢印ｂｃ３，４，５は、ＴｏｐＭｅｎｕからＴｉｔｌｅＭｅｎｕ、ＳｕｂＴｉｔｌｅＭｅｎｕ、ＡｕｄｉｏＭｅｎｕへの分岐を模式的に示している。矢印ｂｃ６，７，８は、ＴｉｔｌｅＭｅｎｕから各Ｍｏｖｉｅオブジェクトへの分岐を模式的に示している。
ＦｉｒｓｔＰＬａｙＩＮＤＥＸ、ＴｏｐＭｅｎｕＩＮＤＥＸ，Ａｕｄｉｏ ＭｅｎｕＩＮＤＥＸ、Ｓｕｂｔｉｔｌｅ ＭｅｎｕＩＮＤＥＸ、ｔｉｔｌｅ ＭｅｎｕＩＮＤＥＸは、それぞれ、ＦｉｒｓｔＰＬａｙＯＢＪ、ＴｏｐＭｅｎｕＯＢＪ，Ａｕｄｉｏ ＭｅｎｕＯＢＪ、Ｓｕｂｔｉｔｌｅ ＭｅｎｕＯＢＪ、ｔｉｔｌｅ ＭｅｎｕＯＢＪについてのＩｎｄｅｘであり、これらの識別子が記述される。
ｔｉｔｌｅ＃１〜＃ｍＩＮＤＥＸは、ＢＤ−ＲＯＭにおいて１からｍ番目にエントリーされているｔｉｔｌｅについてのＩｎｄｅｘであり、これら１からｍまでのｔｉｔｌｅ番号の選択時において分岐先となるＭＯＶＩＥオブジェクトの識別子（ＩＤ）が記述される。
ｔｉｔｌｅ＃ｍ＋１〜＃ｎＩＮＤＥＸは、ＢＤ−ＲＯＭにおいてｍ＋１からｎ番目にエントリーされているｔｉｔｌｅについてのＩｎｄｅｘであり、これらｍ＋１からｎまでのｔｉｔｌｅ番号の選択時において分岐先となるＢＤ−Ｊオブジェクトの識別子（ＩＤ）が記述される。
ｔｉｔｌｅ＃０ＩＮＤＥＸは、ＢＤ−Ｊオブジェクトの強制終了時において分岐先になるべきＭｏｖｉｅオブジェクト又はＢＤ−Ｊオブジェクトを規定するＩＮＤＥＸである。本実施形態では、ＴｏｐＭｅｎｕＯＢＪについての識別子が、このｔｉｔｌｅ＃０ＩＮＤＥＸに格納されている。
図３０（ａ）は、図２９のようにＩｎｄｅｘ Ｔａｂｌｅが記述された場合における分岐を示す。Ｉｎｄｅｘ Ｔａｂｌｅがこのように記述されているので、ラベルｔｉｔｌｅ＃１〜ｔｉｔｌｅ＃ｍを分岐先とした分岐コマンドの実行時には、ｔｉｔｌｅ＃１Ｉｎｄｅｘ〜ｔｉｔｌｅ＃ｍＩｎｄｅｘからＭｏｖｉｅオブジェクト＃１〜＃ｍの識別子が取り出される。ラベルｔｉｔｌｅ＃ｍ＋１〜ｔｉｔｌｅ＃ｎを分岐とした分岐コマンドの実行時には、ｔｉｔｌｅ＃ｍ＋１Ｉｎｄｅｘ〜ｔｉｔｌｅ＃ｎＩｎｄｅｘからＢＤ−Ｊオブジェクト＃ｍ＋１〜＃ｎの識別子が取り出される。ＢＤ−Ｊオブジェクト＃ｍ＋１〜＃ｎの識別子は、ファイル名を表す５桁の数値であるので、『００００１．ＢＤ−Ｊ，００００２．ＢＤ−Ｊ，００００３．ＢＤ−Ｊ・・・』が取り出され、そのファイル名の動的シナリオがメモリに読み出されて、実行されることになる。これがＩｎｄｅｘ Ｔａｂｌｅを用いた分岐処理である。
図３０（ｂ）は、ＢＤ−Ｊオブジェクト実行時の強制終了時における分岐を示す図である。強制終了時における分岐では、ｔｉｔｌｅ＃０Ｉｎｄｅｘから識別子が取り出されて、その識別子の動的シナリオが再生装置により実行される。この識別子が、トップメニュータイトルの識別子なら、アプリケーション強制終了時には、自動的にトップメニューＯＢＪが選択されることになる。
以上は本実施形態における記録媒体に対する改良である。続いて本実施形態における再生装置に対する改良について説明する。上述した記録媒体の改良に対応するため、再生装置内のモジュールマネージャ３４は図３１に示すような処理手順で処理を行う。図３１は、モジュールマネージャ３４の処理手順を示すフローチャートである。本フローチャートは、ステップＳ３１、ステップＳ３２からなるループ処理を構成しており、ステップＳ３１又はステップＳ３２のどちらかがＹｅｓになった際、対応する処理を実行するものである。
ステップＳ３１は、タイトルジャンプＡＰＩの呼び出しがあったか否かの判定である。もしタイトルジャンプＡＰＩの呼び出しがあれば、分岐先ラベルであるタイトル番号ｊを取得し（ステップＳ３３）、Ｉｎｄｅｘ Ｔａｂｌｅにおけるタイトル番号ｊのＩｎｄｅｘから、ＩＤｊを取り出して（ステップＳ３４）、ＩＤｊのＭｏｖｉｅオブジェクト又はＢＤ−Ｊオブジェクトを、ＨＤＭＶモジュール３３又はＢＤ−Ｊモジュール３５に実行させる（ステップＳ３５）。
ステップＳ３２は、タイトル終了がアプリケーションマネージャ３６から通知されたか否かの判定であり、もし通知されれば（ステップＳ３２でＹｅｓ）、トップメニュータイトルを構成するトップメニューＯＢＪをＨＤＭＶモジュール３３又はモジュールマネージャ３４に実行させる（ステップＳ３６）。
以上のアプリケーションマネージャ３６によるアプリケーション強制終了の動作例を、図３２を参照しながら説明する。ここで再生すべきタイトルは、落下するタイル片を積み重ねるというゲー厶アプリを含む非ＡＶ系タイトルである。図３２の下段は、アプリケーションの生存区間からなるタイトル時間軸を示し、上段は、タイトル時間軸において表示される画像を示す。非ＡＶ系タイトルがゲームアプリである場合、このゲームアプリの生存区間において、図３２の上段左側のように、ゲームアプリの一画面が表示される。ゲームアプリにバグがあり、異常終了すると、アプリケーションマネージャ３６は図２３のフローチャートに従ってゲームアプリを強制終了させ、タイトルの終了をモジュールマネージャ３４に通知する。タイトル終了が通知されると、モジュールマネージャ３４はトップメニュータイトルに分岐する。そうすると、図３２の上段右側に示すような画像が表示され、ユーザの操作待ちになる。
以上のように本実施形態によれば、プログラムが含むが、デジタルストリームは含まないような非ＡＶ系タイトルの終了時においても、トップメニュータイトルに分岐するという制御が可能になる。これによりアプリケーションプログラムがエラー終了したとしても、ブラックアウトやハングアップの発生を回避することができる。
（第５実施形態）
ＢＤ−Ｊモードにおいて、ＰＬ再生との同期をどのように実現するかという改良に関する。図８（ｂ）の一例においてＪＭＦプレーヤインスタンスの再生を命じるＪＭＦプレーヤインスタンス（Ａ．ｐｌａｙ；）をＪａｖａ仮想マシン３８が解読した場合、Ｊａｖａ仮想マシン３８はＰＬ再生ＡＰＩをコールして、コール直後に”サクセス”を示す応答をアプリケーションに返す。
Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２は、ＰＬ再生ＡＰＩがコールされれば、ＰＬ情報に基づく処理手順を実行する。ＰＬが２時間という再生時間を有するなら、この２時間の間、上述した処理は継続することになる。ここで問題になるのは、Ｊａｖａ仮想マシン３８がサクセス応答を返す時間と、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２が実際に処理を終える時間とのギャップである。Ｊａｖａ仮想マシン３８は、イベントドリブンの処理主体であるためコール直後に再生成功か、再生失敗かを示す応答を返すが、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２による実際の処理終了は２時間経過後であるので、サクセス応答をアプリケーションに返す時間を基準にしたのでは、２時間経過後にあたる処理終結を感知しえない。ＰＬ再生において早送り、巻戻し、Ｓｋｉｐが行われると、この２時間という再生期間は２時間前後に変動することになり、処理終結の感知は更に困難になる。
Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２は、アプリケーションとスタンドアローンで動作するため、第３実施形態のような終了判定では、ＰＬ再生の終了をタイトル終了と解釈することができない。そこで本実施形態では、アプリケーションが終了してようがいまいが、ワークメモリ３７にＪＭＦプレーヤインスタンスがある限り、つまり、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１の制御権をＢＤ−Ｊモジュール３５が掌握している間、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２から再生終結イベントを待つ。そして再生終結イベントがあれば、タイトルが終了したと解釈して、次のタイトルへの分岐を行うようモジュールマネージャ３４に通知する。こうすることにより、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２がＰＬ再生を終結した時点を、タイトルの終端とすることができる。
以降図３３〜図３７のフローチャートを参照して、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２による具体的な制御手順を説明する。
図３３は、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２によるＰＬ再生手順を示すフローチャートである。この再生手順は、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１に対する制御（ステップＳ４６）と、ＢＤ−ＲＯＭドライブ１又はＨＤＤ１７に対する制御（ステップＳ４８）とを主に含む。本フローチャートにおいて処理対象たるＰｌａｙＩｔｅｍをＰｌａｙＩｔｅｍ＃ｘとする。本フローチャートは、カレントＰＬ情報（．ｍｐｌｓ）の読み込みを行い（ステップＳ４１）、その後、ステップＳ４２〜ステップＳ５０の処理を実行するというものである。ここでステップＳ４２〜ステップＳ５０は、ステップＳ４９がＹｅｓになるまで、カレントＰＬ情報を構成するそれぞれのＰＩ情報について、ステップＳ４３〜ステップＳ５０の処理を繰り返すというループ処理を構成している。このループ処理において処理対象となるＰｌａｙＩｔｅｍを、ＰｌａｙＩｔｅｍ＃ｘ（ＰＩ＃ｘ）とよぶ。このＰｌａｙＩｔｅｍ＃ｘは、カレントＰＬの先頭のＰｌａｙＩｔｅｍに設定されることにより、初期化される（ステップＳ４２）。上述したループ処理の終了要件は、このＰｌａｙＩｔｅｍ＃ｘがカレントＰＬの最後のＰｌａｙＩｔｅｍになることであり（ステップＳ４９）、もし最後のＰｌａｙＩｔｅｍでなければ、カレントＰＬにおける次のＰｌａｙＩｔｅｍがＰｌａｙＩｔｅｍ＃ｘに設定される（ステップＳ５０）。
ループ処理において繰り返し実行されるステップＳ４３〜ステップＳ５０は、ＰｌａｙＩｔｅｍ＃ｘのＣｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されるＣｌｉｐ情報をシナリオメモリ２１に読み込み（ステップＳ４３）、ＰｌａｙＩｔｅｍ＃ｘのＩｎ＿ｔｉｍｅを、カレントＣｌｉｐ情報のＥＰｍａｐを用いて、Ｉピクチャアドレスｕに変換し（ステップＳ４４）、ＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅを、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて、Ｉピクチャアドレスｖに変換して（ステップＳ４５）、これらの変換で得られたアドレスｖの次のＩピクチャを求めて、そのアドレスの１つ手前をアドレスｗに設定し（ステップＳ４７）、そうして算出されたアドレスｗを用いて、ＩピクチャアドレスｕからアドレスｗまでのＴＳパケットの読み出しをＢＤ−ＲＯＭドライブ１又はＨＤＤ１７に命じるというものである（ステップＳ４８）。
一方、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１に対しては、カレントＰＬＭａｒｋのｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐからＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅまでの出力を命じる（ステップＳ４６）。以上のステップＳ４５〜ステップＳ４８により、ＡＶＣｌｉｐにおいて、ＰｌａｙＩｔｅｍ＃ｘにより指示されている部分の再生がなされることになる
その後、ＰｌａｙＩｔｅｍ＃ｘがカレントＰＬの最後のＰＩであるかの判定がなされる（ステップＳ４９）。
ＰｌａｙＩｔｅｍ＃ｘがカレントＰＬの最後のＰＩでなければ、カレントＰＬにおける次のＰｌａｙＩｔｅｍを、ＰｌａｙＩｔｅｍ＃ｘに設定して（ステップＳ５０）、ステップＳ４３に戻る。以上のステップＳ４３〜ステップＳ５０を繰り返することにより、ＰＬを構成するＰＩは順次再生されることになる。
図３４は、アングル切り換え手順及びＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔの手順を示すフローチャートである。本フローチャートは、図３３の処理手順と並行してなさるものであり、ステップＳ５１〜Ｓ５２からなるループ処理を繰り返すというものである。本ループにおけるステップＳ５１は、アングル切り換えを要求するＡＰＩが、Ｊａｖａ仮想マシン３８からコールされたか否かの判定であり、アングル切り換えＡＰＩのコールがあれば、カレントＣｌｉｐ情報を切り換えるという操作を実行する。
図３４のステップＳ５５は、判定ステップであり、ＰｌａｙＩｔｅｍ＃ｘのｉｓ＿ｍｕｌｔｉ＿ａｎｇｌｅｓがオンであるか否かの判定を行う。ｉｓ＿ｍｕｌｔｉ＿ａｎｇｌｅｓとは、ＰｌａｙＩｔｅｍ＃ｘがマルチアングルに対応しているか否かを示すフラグであり、もしステップＳ５５がＮｏであるならステップＳ５３に移行する。ステップＳ５５がＹｅｓであるなら、ステップＳ５６〜ステップＳ５９を実行する。ステップＳ５６〜ステップＳ５９は、切り換え後のアングル番号を変数ｙに代入して（ステップＳ５６）、ＰｌａｙＩｔｅｍ＃ｘにおけるｙ番目のＣｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されているＣｌｉｐ情報をシナリオメモリ２１に読み出し（ステップＳ５７）、カレントＰＴＭを、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いてＩピクチャアドレスｕに変換し（ステップＳ５８）、ＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅを、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いてＩピクチャアドレスｖに変換する（ステップＳ５９）というものである。こうしてＩピクチャアドレスｕ，ｖを変化した後、ステップＳ４６に移行する。ステップＳ４６への移行により、別のＡＶＣｌｉｐからＴＳパケットが読み出されるので、映像内容が切り換わることになる。
一方、図３４のループにおけるステップＳ５２は、ＳｋｉｐＢａｃｋ／ＳｋｉｐＮｅｘｔを意味するＡＰＩがＪａｖａ仮想マシン３８からコールされたか否かの判定であり、もしコールされれば、図３５のフローチャートの処理手順を実行する。図３５は、ＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔＡＰＩがコールされた際の処理手順を示すフローチャートである。ＳｋｉｐＢａｃｋ，ＳｋｉｐＮｅｘｔを実行するにあたっての処理手順は多種多様なものである。ここで説明するのはあくまでも一例に過ぎないことに留意されたい。
ステップＳ６１は、ＰＳＲで示されるカレントＰＩ番号、及び、カレントＰＴＭを変換することにより、カレントＭａｒｋ情報を得る。ステップＳ６２は、押下されたのがＳｋｉｐＮｅｘｔキーであるか、ＳｋｉｐＢａｃｋキーであるかの判定であり、ＳｋｉｐＮｅｘｔキーであるならステップＳ６３において方向フラグを＋１に設定し、ＳｋｉｐＢａｃｋキーであるならステップＳ６４において方向フラグを−１に設定する。
ステップＳ６５は、カレントＰＬＭａｒｋの番号に方向フラグの値を足した番号を、カレントＰＬＭａｒｋの番号として設定する。ここでＳｋｉｐＮｅｘｔキーであるなら方向フラグは＋１に設定されているのでカレントＰＬＭａｒｋはインクリメントされることになる。ＳｋｉｐＢａｃｋキーであるなら方向フラグは−１に設定されているので、カレントＰＬＭａｒｋはデクリメントされることになる。
ステップＳ６６では、カレントＰＬＭａｒｋのｒｅｆ＿ｔｏ＿ＰｌａｙＩｔｅｍ＿Ｉｄに記述されているＰＩを、ＰｌａｙＩｔｅｍ＃ｘに設定し、ステップＳ６７では、ＰｌａｙＩｔｅｍ＃ｘのＣｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されるＣｌｉｐ情報を読み込む。ステップＳ６８では、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて、カレントＰＬＭａｒｋのｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐを、Ｉピクチャアドレスｕに変換する。一方ステップＳ６９では、ＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅを，カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて，Ｉピクチャアドレスｖに変換する。ステップＳ７０は、カレントＰＬＭａｒｋのｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐからＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅまでの出力をＰｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１に命じた上で、図３３のステップＳ４７に移行する。こうしてＩピクチャアドレスｕ，ｖを変化して、別の部分の再生を命じた上でステップＳ４７への移行するので、別のＡＶＣｌｉｐからＴＳパケットが読み出されることになり、映像内容が切り換えが実現する。
図３６は、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１による処理手順の詳細を示すフローチャートである。本フローチャートは、ＩピクチャのＰＴＳをカレントＰＴＭに設定した後で（ステップＳ７１）、ステップＳ７２〜ステップＳ７７からなるループ処理を実行するものである。
続いてステップＳ７２〜ステップＳ７７におけるループ処理について説明する。このループ処理は、カレントＰＴＭにあたるピクチャ、オーディオの再生出力と、カレントＰＴＭの更新とを繰り返すものである。本ループ処理におけるステップＳ７６は、ループ処理の終了要件を規定している。つまりステップＳ７６は、カレントＰＴＭがＰＩ＃ｘのＯｕｔ＿ｔｉｍｅであることをループ処理の終了要件にしている。
ステップＳ７３は、早送りＡＰＩ、又は、早戻しＡＰＩがＪａｖａ仮想マシン３８からコールされたか否かの判定である。もしコールされれば、ステップＳ７８において早送りか早戻しかの判定を行い、早送りであるなら、次のＩピクチャのＰＴＳをカレントＰＴＭに設定する（ステップＳ７９）。このようにカレントＰＴＭを、次のＩピクチャのＰＴＳに設定することで、１秒飛びにＡＶＣｌｉｐを再生してゆくことができる。これにより、２倍速等でＡＶＣｌｉｐは順方向に早く再生されることになる。早戻しであるなら、カレントＰＴＭがＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅに到達したかを判定する（ステップＳ８０）。もし到達してないのなら、１つ前のＩピクチャのＰＴＳをカレントＰＴＭに設定する（ステップＳ８１）。このように読出先アドレスＡを、１つ前のＩピクチャに設定することで、ＡＶＣｌｉｐを後方向に１秒飛びに再生してゆくことができる。これにより、２倍速等でＡＶＣｌｉｐは、逆方向に再生されることになる。尚、早送り、巻戻しを実行するにあたっての処理手順は多種多様なものである。ここで説明するのはあくまでも一例に過ぎないことに留意されたい。
ステップＳ７４は、メニューコールＡＰＩがコールされたか否かの判定であり、もしコールされれば、現在の再生処理をサスペンドして（ステップＳ８２）、メニュー処理用のメニュープログラムを実行する（ステップＳ８３）。以上の処理により、メニューメニューコールがなされた場合は、再生処理を中断した上で、メニュー表示のための処理が実行されることになる。
ステップＳ７５は、ｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿ｉｄにより、ＰｌａｙＩｔｅｍ＃ｘを指定したＳｕｂＰｌａｙＩｔｅｍ＃ｙが存在するか否かの判定であり、もし存在すれば、図３７のフローチャートに移行する。図３７は、ＳｕｂＰｌａｙＩｔｅｍの再生手順を示すフローチャートである。本フローチャートでは、先ずステップＳ８６において、カレントＰＴＭはＳｕｂＰｌａｙＩｔｅｍ＃ｙのｓｙｎｃ＿ｓｔａｒｔ＿ＰＴＳ＿ｏｆ＿ｐｌａｙＩｔｅｍであるか否かを判定する。もしそうであれば、ステップＳ９３においてＳｕｂＰｌａｙＩｔｅｍ＃ｙに基づく再生処理を行うようＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に通知する。
図３７のステップＳ８７〜ステップＳ９２は、ＳｕｂＰｌａｙＩｔｅｍ＃ｙに基づく再生処理を示すフローチャートである。
ステップＳ８７では、ＳｕｂＰｌａｙＩｔｅｍ＃ｙのＣｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されるＣｌｉｐ情報を読み込む。ステップＳ８８では、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて、ＳｕｂＰｌａｙＩｔｅｍ＃ｙのＩｎ＿ｔｉｍｅを、アドレスαに変換する。一方ステップＳ８９では、ＳｕｂＰｌａｙＩｔｅｍ＃ｙのＯｕｔ＿ｔｉｍｅを，カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて、アドレスβに変換する。ステップＳ９０は、ＳｕｂＰｌａｙＩｔｅｍ＃ｙのＩｎ＿ｔｉｍｅからＳｕｂＰｌａｙＩｔｅｍ＃ｙのＯｕｔ＿ｔｉｍｅまでの出力をデコーダに命じる。これらの変換で得られたアドレスβの次のＩピクチャを求めて、そのアドレスの１つ手前をアドレスγに設定し（ステップＳ９１）、そうして算出されたアドレスγを用いて、ＳｕｂＣｌｉｐ＃ｚにおけるアドレスαからアドレスγまでのＴＳパケットの読み出しをＢＤ−ＲＯＭドライブ１又はＨＤＤ１７に命じるというものである（ステップＳ９２）。
また図３３に戻ってＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２の処理の説明の続きを行う。ステップＳ５３はＰｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１による再生制御が完了したかの判定であり、最後のＰｌａｙＩｔｅｍ＃ｘに対して、図３６のフローチャートの処理が行われている限り、ステップＳ５３がＮｏになる。図３６のフローチャートの処理が終了して初めて、ステップＳ５３はＹｅｓになりステップＳ５４に移行する。ステップＳ５４は、Ｊａｖａ仮想マシン３８への再生終結イベントの出力であり、この出力により、２時間という再生時間の経過をＪａｖａ仮想マシン３８は知ることができる。
以上が本実施形態におけるＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１の処理である。続いて本実施形態におけるアプリケーションマネージャ３６処理手順ついて説明する。図３８は、第５実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。
図３８のフローチャートは、図２７のフローチャートを改良したものである。その改良点は、ステップＳ２１−ステップＳ２２間にステップＳ２４が追加され、このステップＳ２４がＹｅｓになった際、実行されるステップＳ１０１が存在する点である。
ステップＳ２４は、ＪＭＦプレーヤインスタンスがワークメモリ３７に存在するか否かの判定であり、もし存在しなければステップＳ２２に移行する。存在すれば、ステップＳ１０１に移行する。ステップＳ１０１は、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２から再生終結イベントが出力されたか否かの判定であり、もし出力されれば、ワークメモリ中のＪａｖａプレーヤインスタンスを消滅させた上で（ステップＳ１０２）、タイトル終了をモジュールマネージャ３４に通知する（ステップＳ２６）。通知されねば、ステップＳ２１〜ステップＳ２４からなるループ処理を繰り返す。
以上のフローチャートにおいて、ワークメモリ３７にＪＭＦプレーヤインスタンスが存在する限り（ステップＳ２４でＹｅｓ）、ステップＳ２２、ステップＳ２３はスキップされる。そのため、たとえ全てのアプリケーションが終了したとしてもタイトルは継続中と解釈される。
以上のように本実施形態によれば、２時間という再生時間の経過時点をアプリケーションマネージャ３６は把握することができるので、ＰＬ再生の終了条件にメニューを表示して、このメニューに対する操作に応じて他のタイトルに分岐するという制御を実現することができる。
（第６実施形態）
第６実施形態は、ＢＤ−Ｊオブジェクトにデータ管理テーブルを設ける改良に関する。
データ管理テーブル（ＤＭＴ）は、そのタイトル時間軸においてローカルメモリ２９上にロードすべきＪａｖａアーカイブファイルを、読込属性と、読込優先度とに対応づけて示すテーブルである。”ローカルメモリ２ｂにおける生存”とは、そのアプリケーションを構成するＪａｖａアーカイブファイルがローカルメモリ２９から読み出され、Ｊａｖａ仮想マシン３８内のワークメモリ３７への転送が可能になっている状態をいう。図３９は、データ管理テーブルの一例を示す図である。本図に示すようにデータ管理テーブルは、アプリケーションの『生存区間』と、その生存区間をもったアプリケーションを識別する『ａｐｐｌｉｃａｔｉｏｎＩＤ』と、そのアプリケーションの『読込属性』と、『読込優先度』とを示す。
上述したようにアプリケーション管理テーブルには、生存区間という概念があり、データ管理テーブルにも同じ生存区間という概念がある。アプリケーション管理テーブルと同じ概念を、データ管理テーブルに設けておくというのは一見無駄のように思えるがこれには意図がある。
図４０は、ＢＤ−Ｊオブジェクトが想定している実行モデルを示す図である。本図における実行モデルは、ＢＤ−ＲＯＭ、ローカルメモリ２９、Ｊａｖａ仮想マシン３８からなり、ＢＤ−ＲＯＭ、ローカルメモリ２９、ワークメモリ３７という三者の関係を示す。矢印ｍｙ１は、ＢＤ−ＲＯＭ→ローカルメモリ２９間の読み込みを示し、矢印ｍｙ２は、ローカルメモリ２９→ワークメモリ３７間の読み込みを示す。矢印上の注釈は、これらの読み込みが、どのようなタイミングでなされるかを示す。注釈によると、ＢＤ−ＲＯＭ→ローカルメモリ２９間の読み込みは、いわゆる”先読み”であり、アプリケーションが必要となる以前の時点に行われねばならない。
また注釈によると、ローカルメモリ２９→ワークメモリ３７間の読み込みは、アプリケーションが必要になった際になされることがわかる。”必要になった際”とは、アプリケーションの生存区間が到来した時点（１）、アプリケーションの呼出が他のアプリケーション又はアプリケーションマネージャ３６から指示された時点（２）を意味する。
矢印ｍｙ３は、ワークメモリ３７におけるアプリケーションの占有領域の解放を示し、矢印ｍｙ４は、ローカルメモリ２９におけるアプリケーションの占有領域の解放を示す。矢印上の注釈は、これらの読み込みが、どのようなタイミングでなされるかを示す。注釈によると、ワークメモリ３７上の解放は、アプリケーション終了と同時になされることがわかる。一方ローカルメモリ２９上の解放は、Ｊａｖａ仮想マシン３８にとって必要でなくなった時点でなされる。この必要でなくなった時点とは、”終了時点”ではない。”終了した上、再起動の可能性もない時点”であること、つまり該当するｔｉｔｌｅが終了した時点を意味する。上述した読込・解放のうち、ワークメモリ３７における解放時点は、アプリケーション管理テーブルにおける生存区間から判明する。しかし”アプリケーションが必要となる以前の時点”、”終了した上、再起動の可能性もない時点”については、規定し得ない。そこで、オーサリング段階において、かかる時点をディスクコンテンツ全体の時間軸上で規定しておくため、本実施形態では各アプリケーションが生存している区間を、アプリケーション管理テーブルとは別に、データ管理テーブルに記述するようにしている。つまり”アプリケーションが必要となる以前の時点”をデータ管理テーブルにおける生存区間の始点と定義し、”終了した上、再起動の可能性もない時点”をデータ管理テーブルの終点と定義することにより、上述したローカルメモリ２９上の格納内容の遷移をオーサリング時に規定しておくことができる。これがデータ管理テーブルの記述意義である。
データ管理テーブルによるローカルメモリ２９生存区間の記述について説明する。ここで制作しようとするディスクコンテンツは３つのタイトル（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２、ｔｉｔｌｅ＃３）からなり、これらタイトルの時間軸において、図４１（ｂ）に示すようなタイミングで、ローカルメモリ２９を使用したいと考える。この場合、ｔｉｔｌｅ＃１時間軸の開始点においてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２を構成するＪａｖａアーカイブファイルをローカルメモリ２９に読み込み、ｔｉｔｌｅ＃１時間軸の継続中、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２をローカルメモリ２９に常駐させておく。そしてｔｉｔｌｅ＃２時間軸の始点で、ａｐｐｌｉｃａｔｉｏｎ＃１を構成するＪａｖａアーカイブファイルをローカルメモリ２９から解放して、代わりにａｐｐｌｉｃａｔｉｏｎ＃３を構成するＪａｖａアーカイブファイルをローカルメモリ２９に読み込んで、常駐させるというものである（以降、アプリケーションを構成するＪａｖａアーカイブファイルは、アプリケーションと同義に扱う。）。この場合のデータ管理テーブルの記述は、図４１（ａ）の通りであり、アプリケーションのａｐｐｌｉｃａｔｉｏｎＩＤを、その生存区間に対応づけて記述することで、ローカルメモリ２９に常駐すべきアプリケーションを表現する。図４１（ａ）では、ａｐｐｌｉｃａｔｉｏｎ＃１のａｐｐｌｉｃａｔｉｏｎＩＤがｔｉｔｌｅ＃１と対応づけられて記述されており、ａｐｐｌｉｃａｔｉｏｎ＃２のａｐｐｌｉｃａｔｉｏｎＩＤはｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２と対応づけられ、ａｐｐｌｉｃａｔｉｏｎ＃３のａｐｐｌｉｃａｔｉｏｎＩＤはｔｉｔｌｅ＃３と対応づけられて記述されていることがわかる。こうすることで、ローカルメモリ２９占有の時間的遷移がオーサリング担当者により規定されることになる。
データ管理テーブル、アプリケーション管理テーブルの組合せとしては、アプリケーション管理テーブルに規定する生存区間は、細かい再生単位にし、データ管理テーブルに規定する生存区間は、大まかな再生単位にすることが望ましい。大まかな再生単位には、タイトル、ＰＬといった非シームレスな再生単位が望ましい。一方、細かい再生単位としては、ＰＬ内のチャプターというようにシームレスな再生単位が望ましい。アプリケーションの生存区間をタイトル毎、ＰＬ毎に定めれば、アプリケーションはローカルメモリ２９上に存在するので、そのタイトルの再生中においてアプリケーションは何時でも取り出せる状態になる。そうであれば、アプリケーションの生存区間を細かく定めたとしても、アプリケーションを即座に、仮想マシン上のワークメモリに読み出すことができるので、アプリケーションの起動・終了が頻繁になされたとしても、スムーズなアプリケーション実行を実現することができる。
次に、読込属性について説明する。
図２においてＪａｖａアーカイブファイルは、ＡＶＣｌｉｐとは別の記録領域に記録されることを前提にしていた。しかしこれは一例に過ぎない。Ｊａｖａアーカイブファイルは、ＢＤ−ＲＯＭにおいてＡＶＣｌｉｐが占める記録領域に埋め込まれることがある。この埋め込みの態様には、カルーセル化、インターリーブユニット化という２種類がある。
ここで”カルーセル化”とは、対話的な放送の実現のために同一内容を繰り返しするという放送方式に変換することである。ＢＤ−ＲＯＭは、放送されたデータを格納するものではないが、本実施形態では、カルーセルの放送形式に倣ってＪＡＶＡアーカイブファイルを格納するようにしている。図４２は、カルーセル化によるＪａｖａアーカイブファイル埋め込みを示す図である。第１段目は、ＡＶＣｌｉｐ中に埋め込むＪａｖａアーカイブファイルであり、第２段目は、セクション化を示す。第３段目は、ＴＳパケット化、第４段目は、ＡＶＣｌｉｐを構成するＴＳパケット列を示す。こうしてセクション化、ＴＳパケット化されたデータ（図中の”Ｄ”）が、ＡＶＣｌｉｐに埋め込まれるのである。カルーセルによりＡＶＣｌｉｐに多重化されたＪａｖａアーカイブファイルは、読み出すにあたって、低帯域で読み出されることになる。この低帯域での読み出しは、概して２〜３分というように長期間を要するため、再生装置はＪａｖａアーカイブファイルを２〜３分をかけて読み込むことになる。
図４３は、インターリーブ化によるＪａｖａアーカイブファイル埋め込みを示す図である。第１段目は、埋め込まれるべきＡＶＣｌｉｐ、第２段目は、ＡＶＣｌｉｐにインターリーブ化されたＪａｖａアーカイブファイル、第３段目は、ＢＤ−ＲＯＭの記録領域におけるＡＶＣｌｉｐ配置である。本図に示すように、ストリームに埋め込まれるべきＪａｖａアーカイブファイルは、インターリーブ化され、ＡＶＣｌｉｐを構成するＸＸＸＸＸ．ｍ２ｔｓを構成する分割部分（図中のＡＶＣｌｉｐ２／４，３／４）の合間に記録される。インターリーブ化によりＡＶＣｌｉｐに多重化されたＪａｖａアーカイブファイルは、カルーセル化と比較して、高い帯域で読み出されることになる。この高い帯域での読み出しであるため、再生装置はＪａｖａアーカイブファイルを比較的短期間に読み込むことになる。
カルーセル化・インターリーブ化されたＪａｖａアーカイブファイルは、プリロードされるのではない。ＢＤ−ＲＯＭにおけるＡＶＣｌｉｐの記録領域のうち、カルーセル化・インターリーブ化されたＪａｖａアーカイブファイルが埋め込まれた部分に、現在の再生時点が到達した際、再生装置のローカルメモリ２９にロードされる。Ｊａｖａアーカイブファイルの記録態様には、図２に示すものの他に、図４２、図４３（ａ）に示すものがあるので、読込属性は、図４３（ｂ）に示すように、設定されうる。図４３（ｂ）に示すように、読込属性は、タイトル再生に先立ち、ローカルメモリ２９に読み込まれる旨を示す”Ｐｒｅｌｏａｄ”と、タイトル再生中に、カルーセル化方式で読み込まれる旨を示す”Ｌｏａｄ．Ｃａｒｏｕｓｅｌ”と、タイトル再生中に、インターリーブ化方式で読み込まれる旨を示す”Ｌｏａｄ．ＩｎｔｅｒＬｅａｖｅ”とがある。読込属性には、カルーセル化されているか、インターリーブ化されているかが添え字で表現されているが、これを省略してもよい。
データ管理テーブルにおける生存区間の具体的な記述例について、図４４を参照しながら説明する。図４４（ａ）は、データ管理テーブルの一例を示す図である。図４４（ｂ）は、かかるデータ管理テーブルの割り当てによるローカルメモリ２９の格納内容の変遷を示す図である。本図は、縦軸方向にローカルメモリ２９における占有領域を示し、横軸を、１つのタイトル内のＰＬ時間軸としている。データ管理テーブルにおいてａｐｐｌｉｃａｔｉｏｎ＃１は、１つのタイトル内のＰＬ時間軸全体を生存区間とするよう記述されているので、このタイトルのＣｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃５においてローカルメモリ２９内の領域を占有することになる。データ管理テーブルにおいてａｐｐｌｉｃａｔｉｏｎ＃２は、タイトル内のＰＬ＃１におけるＣｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃２を生存区間とするよう記述されているので、このタイトルのＣｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃２においてローカルメモリ２９内の領域を占有することになる。データ管理テーブルにおいてａｐｐｌｉｃａｔｉｏｎ＃３は、タイトル内のＰＬ＃１におけるＣｈａｐｔｅｒ＃４〜Ｃｈａｐｔｅｒ＃５を生存区間とするよう記述されているので、このタイトルのＣｈａｐｔｅｒ＃４〜Ｃｈａｐｔｅｒ＃５においてローカルメモリ２９内の領域を占有することになる。以上で、データ管理テーブルにおける生存区間についての説明を終える。
続いて読込優先度について説明する。読込優先度とは、ローカルメモリ２９への読み込みに対する優劣を決める優先度である。読込優先度には複数の値がある。２段階の優劣を設けたい場合、Ｍａｎｄａｔｏｒｙを示す値、ｏｐｔｉｏｎａｌを示す値を読込優先度に設定する。この場合、Ｍａｎｄａｔｏｒｙは高い読込優先度を意味し、ｏｐｔｉｏｎａｌは、低い読込優先度を意味する。３段階の優劣を設けたい場合、Ｍａｎｄａｔｏｒｙを示す値、ｏｐｔｉｏｎａｌ：ｈｉｇｈ、ｏｐｔｉｏｎａｌ：ｌｏｗを示す値を読込優先度に設定する。Ｍａｎｄａｔｏｒｙは、最も高い読込優先度を示し、ｏｐｔｉｏｎａｌ：ｈｉｇｈは、中程度の読込優先度、ｏｐｔｉｏｎａｌ：ｌｏｗは、最も低い読込優先度を示す。データ管理テーブルにおける読込優先度の具体的な記述例について、図４５（ａ）（ｂ）を参照しながら説明する。この具体例で、想定しているローカルメモリ２９のメモリ規模は、図４５（ａ）に示すようなものである。図４５（ａ）は、新旧再生装置におけるローカルメモリ２９のメモリ規模を対比して示す図である。矢印ｍｋ１は旧再生装置におけるメモリ規模を、矢印ｍｋ２は新再生装置におけるメモリ規模をそれぞれ示す。この矢印の対比から、新再生装置におけるローカルメモリ２９のメモリ規模は、旧再生装置のそれと比較して、三倍以上である状態を想定している。このようにメモリ規模にバラツキがある場合、アプリケーションは、図４５に示すような２つのグループに分類される。１つ目は、どのようなメモリ規模であっても読み込むんでおくべきアプリケーション（＃１，＃２）である。２つ目は、旧再生装置での読み込みは望まないが、新再生装置での読み込みは希望するアプリケーション（＃３，＃４）である。読み込もうとするアプリケーションが、これら２つのグループに分類されれば、前者に帰属するアプリケーションに、読込優先度＝Ｍａｎｄａｔｏｒｙを設定し、後者に属するアプリケーションに、読込優先度＝Ｏｐｔｉｏｎａｌを設定する。図４５（ｂ）は、読込優先度が設定されたデータ管理テーブルの一例を示す図である。データ管理テーブルをこのように設定した上で、ａｐｐｌｉｃａｔｉｏｎ＃１〜ａｐｐｌｉｃａｔｉｏｎ＃４をＢＤ−ＲＯＭに記録すれば、あらゆるメモリ規模の再生装置での再生を保証しつつも、メモリ規模が大きい再生装置では、より大きなサイズのデータを利用したアプリケーションを再生装置に再生させることができる。
以上は本実施形態における記録媒体に対する改良である。続いて本実施形態における再生装置に対する改良について説明する。上述した記録媒体の改良に対応するため、アプリケーションマネージャ３６は図４６に示すような処理手順で処理を行う。
図４６は、アプリケーションマネージャ３６によるプリロード制御の処理手順を示す図である。本フローチャートは、再生すべきタイトルにおけるデータ管理テーブルを読み込み（ステップＳ１１１）、データ管理テーブルにおいて最も高い読込優先度をもちつつ、ａｐｐｌｉｃａｔｉｏｎＩＤが最も小さいアプリケーションをアプリケーションｉにした上で（ステップＳ１１２）、ステップＳ１１３、ステップＳ１１４の判定を経た上で、アプリケーションｉをローカルメモリ２９にプリロードする（ステップＳ１１５）という処理を、ステップＳ１１６がＮｏ及びステップＳ１１７がＮｏと判定されるまで、繰り返すというループ処理を構成している。
ステップＳ１１３は、アプリケーションｉの読込属性がプリロードであるか否かの判定であり、ステップＳ１１４は、アプリケーションの読込優先度が＝ＭａｎｄａｔｏｒｙであるかＯｐｔｉｏｎａｌであるかの判定である。ステップＳ１１３においてプリロードと判定され、ステップＳ１１４において読込優先度がＭａｎｄａｔｏｒｙと判定されれば、アプリケーションはローカルメモリ２９にプリロードされることになる（ステップＳ１１５）。もしステップＳ１１３において読込属性がロードであると判定されれば、ステップＳ１１４〜ステップＳ１１５はスキップされることになる。
ループ処理の終了要件を規定する２つのステップのうちステップＳ１１６は、ａｐｐｌｉｃａｔｉｏｎＩＤが次に高く、アプリケーションｉと同一読込優先度のアプリケーションｋが存在するか否かを判定するものである。そのようなアプリケーションｋが存在するなら、そのアプリケーションｋをアプリケーションｉにする（ステップＳ１１９）。
ループ処理の終了要件を規定する２つのステップのうちステップＳ１１７は、データ管理テーブルにおいて次に低い読込優先度をもつアプリケーションが存在するか否かの判定であり、もし存在すれば、その次に低い読込優先度をもつアプリケーションのうち、最も小さいａｐｐｌｉｃａｔｉｏｎＩＤをアプリケーションｋを選んで（ステップＳ１１８）、そのアプリケーションｋをアプリケーションｉにする（ステップＳ１１９）。これらステップＳ１１６、ステップＳ１１７がＹｅｓになっている限り、上述したステップＳ１１３〜ステップＳ１１５の処理は繰り返されることになる。ステップＳ１１６、ステップＳ１１７において、該当するアプリケーションが無くなれば本フローチャートの処理は終了することになる。
ステップＳ１２０〜ステップＳ１２３は、ステップＳ１１４において読込優先度＝Ｏｐｔｉｏｎａｌであると判定された場合に、実行される処理である。
ステップＳ１２０は、同じａｐｐｌｉｃａｔｉｏｎＩＤをもち、読込優先度が高いアプリケーションｊが存在するか否かの判定である。
ステップＳ１２１は、ローカルメモリ２９の残り容量がアプリケーションｉのサイズを上回るか否かを判定するステップである。ステップＳ１２０がＮｏ、ステップＳ１２１がＹｅｓである場合、ステップＳ１１５においてアプリケーションｉがローカルメモリ２９にプリロードされることになる。ステップＳ１２０がＮｏ、ステップＳ１２１がＮｏである場合、アプリケーションｉはローカルメモリ２９にプリロードされずそのままステップＳ１１６に移行することになる。
こうしておくと、読込優先度＝Ｏｐｔｉｏｎａｌのデータは、ステップＳ１２０−ステップＳ１２１の判定がＹｅｓにならないと、ローカルメモリ２９へのプリロードがなされない。メモリ規模が小さい旧再生装置は、２〜３個のアプリケーションを読み込んだ程度で、ステップＳ１２１の判定はＮｏになるが、メモリ規模が大きい新再生装置は、更に多くのアプリケーションを読み込んだとしても、ステップＳ１２１の判定はＮｏにならない。以上のように、旧再生装置では、ローカルメモリ２９にＭａｎｄａｔｏｒｙのアプリケーションのみが読み込まれ、新再生装置には、Ｍａｎｄａｔｏｒｙのアプリケーションと、Ｏｐｔｉｏｎａｌのアプリケーションとが読み込まれることになる。
ステップＳ１２２は、ステップＳ１２０においてＹｅｓと判定された場合に実行されるステップである。同じａｐｐｌｉｃａｔｉｏｎＩＤをもち、読込優先度が高いアプリケーションｊがローカルメモリ２９上に存在する場合、ローカルメモリ２９の残り容量と、アプリケーションｊのサイズとの和が、アプリケーションｉのサイズを上回るか否かを判定し（ステップＳ１２２）、もし上回れば、アプリケーションｉを用いてローカルメモリ２９上のアプリケーションｊを上書きすることによりプリロードする（ステップＳ１２３）。下回る場合は、アプリケーションｉはローカルメモリ２９にプリロードされずそのままステップＳ１１６に移行することになる。
ステップＳ１１５、ステップＳ１２３による読込処理の一例を、図４７（ａ）を参照しながら説明する。図４７（ａ）は、この具体例が想定しているデータ管理テーブルの一例を示す図である。本図における３つのアプリケーションは、それぞれ３つのファイルに格納されており、ａｐｐｌｉｃａｔｉｏｎＩＤは同じであるが（ａｐｐｌｉｃａｔｉｏｎＩＤ＝１）、読込優先度は互いに異なる（ｍａｎｄａｔｏｒｙ，ｏｐｔｉｏｎａｌ：ｈｉｇｈ，ｏｐｔｉｏｎａｌ：ｌｏｗ）。こうしたデータ管理テーブルが処理対象であると、ステップＳ１１５により、読込優先度＝Ｍａｎｄａｔｏｒｙのアプリケーションはローカルメモリ２９に読み込まれる。しかし読込優先度＝Ｏｐｔｉｏｎａｌのアプリケーションについては、ステップＳ１２０〜ステップＳ１２２の判定を経た上で、ステップＳ１２３において読み込まれる。ステップＳ１１５と違いステップＳ１２３では、既にローカルメモリ２９にある同じａｐｐｌｉｃａｔｉｏｎＩＤのアプリケーションを上書きしてゆくよう、プリロードがなされるので、複数アプリケーションのうち１つが排他的に、ローカルメモリ２９にロードされることになる。
ｉ）読込優先度＝ｍａｎｄａｔｏｒｙのアプリケーションを読み込んだ後、読込優先度＝ｏｐｔｉｏｎａｌ：ｈｉｇｈのアプリケーションを読み込むにあたって、ステップＳ１２２がＮｏと判定されればれば、読込優先度＝ｍａｎｄａｔｏｒｙのアプリケーションがローカルメモリ２９に残ることになる。読込優先度＝ｍａｎｄａｔｏｒｙのアプリケーションを読み込んだ後、読込優先度＝ｏｐｔｉｏｎａｌ：ｈｉｇｈのアプリケーションを読み込むにあたって、ステップＳ１２２がＹｅｓと判定されれば、読込優先度＝ｏｐｔｉｏｎａｌ：ｈｉｇｈのアプリケーションにより、読込優先度＝ｍａｎｄａｔｏｒｙのアプリケーションは上書きされ、読込優先度＝ｏｐｔｉｏｎａｌ：ｈｉｇｈのアプリケーションがローカルメモリ２９に残ることになる。
ｉｉ）読込優先度＝ｏｐｔｉｏｎａｌ：ｈｉｇｈのアプリケーションを読み込んだ後、読込優先度＝ｏｐｔｉｏｎａｌ：ｌｏｗのアプリケーションを読み込むにあたって、ステップＳ１２２がＮｏと判定されればれば、読込優先度＝Ｍａｎｄａｔｏｒｙのアプリケーションがローカルメモリ２９に残ることになる。読込優先度＝ｏｐｔｉｏｎａｌ：ｈｉｇｈのアプリケーションを読み込んだ後、読込優先度＝ｏｐｔｉｏｎａｌ：ｌｏｗのアプリケーションを読み込むにあたって、ステップＳ１２２がＹｅｓと判定されれば、読込優先度＝ｏｐｔｉｏｎａｌ：ｌｏｗのアプリケーションにより、読込優先度＝ｏｐｔｉｏｎａｌ：ｈｉｇｈのアプリケーションは上書きされ（ステップＳ１２３）、読込優先度＝ｏｐｔｉｏｎａｌ：ｌｏｗのアプリケーションがローカルメモリ２９に残ることになる。
ローカルメモリ２９の容量が許す限り、ローカルメモリ２９上のアプリケーションを上書きしてゆくとの処理が繰り返されるので、ローカルメモリ２９の格納内容は、図４７（ｂ）に示すように、ｍａｎｄａｔｏｒｙ＝ｏｐｔｉｏｎａｌ：ｈｉｇｈ＝＞ｏｐｔｉｏｎａｌ：ｌｏｗと遷移してゆくことになる。メモリ規模に応じて、サイズが異なるＪａｖａアーカイブファイルをローカルメモリ２９にロードすることができるので、メモリ規模が小さい再生装置については、必要最小限の解像度をもったサムネール画像を有するＪａｖａアーカイブファイルを、メモリ規模が中程度の再生装置については、中程度の解像度をもったＳＤ画像を有するＪａｖａアーカイブファイルを、メモリ規模が大規模である再生装置については、高解像度をもったＨＤ画像を有するＪａｖａアーカイブファイルをローカルメモリ２９にロードすることができる。かかるロードにより、メモリ規模に応じて解像度が異なる画像を表示させることができ、オーサリング担当者によるタイトル制作の表現の幅が広がる。
図４８は、データ管理テーブルを参照した読取処理の具体例を示す図である。本図における２つのアプリケーションは、同じａｐｐｌｉｃａｔｉｏｎＩＤ（ａｐｐｌｉｃａｔｉｏｎ＃３）が付与された２つのアプリケーションを示す図である。そのうち一方は、ＡＶＣｌｉｐ中に埋め込まれていて、読込優先度がｍａｎｄａｔｏｒｙに設定されている。他方は、ＡＶＣｌｉｐとは別ファイルに記録されていて、読込優先度がＯｐｔｉｏｎａｌに設定されている。前者のアプリケーションは、ＡＶＣｌｉｐに埋め込まれているので、その埋込部分にあたる生存区間が、生存区間（ｔｉｔｌｅ＃１：ｃｈａｐｔｅｒ＃４〜＃５）として記述されている。これらのアプリケーションのうちａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３には、ロードを示す読込属性が付与されている。ａｐｐｌｉｃａｔｉｏｎ＃２はＣｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃２を生存区間にしており、ａｐｐｌｉｃａｔｉｏｎ＃３はＣｈａｐｔｅｒ＃４〜Ｃｈａｐｔｅｒ＃５を生存区間にしているので、タイトル時間軸においてどちらか一方が排他的にローカルメモリ２９上に常駐することになる。図４８（ｂ）は、タイトル時間軸上の別々の時点において、排他的に格納されるａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３を示す図である。これは必要最低限のメモリ規模しかもたない再生装置での再生を念頭に置いた配慮である。こうした内容のデータ管理テーブルが処理対象であるとアプリケーションマネージャ３６は、上述した図４６のフローチャートによりメモリ規模に応じて異なる処理を行う。
後者のアプリケーションは、読込優先度＝ロードであるので、ローカルメモリ２９にロードされる。かかる処理により、Ｍａｎｄａｔｏｒｙなメモリ規模さえあれば、アプリケーションマネージャはデータをローカルメモリ２９にロードすることができる。ここで問題になるのは、メモリ規模が大きい再生装置による読み込み時である。メモリ規模が大きいにも拘らず、Ｃｈａｐｔｅｒ＃４〜Ｃｈａｐｔｅｒ＃５に到達するまでａｐｐｌｉｃａｔｉｏｎ＃３を読み込めないというのは、メモリ規模の無駄になる。そこで本図のデータ管理テーブルには、同じａｐｐｌｉｃａｔｉｏｎ＃３にプリロードを示す読込属性を付与してＢＤ−ＲＯＭに記録しておき、これらに同じａｐｐｌｉｃａｔｉｏｎＩＤを付与している。
前者のアプリケーションは、読込優先度＝Ｏｐｔｉｏｎａｌであるので、ステップＳ１２１がＹｅｓになった場合に限り、プリロードされる（ステップＳ１１５）。こうすることで、メモリ規模が大きい再生装置は、ｔｉｔｌｅ＃１、Ｃｈａｐｔｅｒ＃４〜Ｃｈａｐｔｅｒ＃５の到達を待つことなく、ＡＶＣｌｉｐに埋め込まれているのと同じアプリケーションをローカルメモリ２９にロードすることができるのである（図４８（ｃ））。
以上がプリロード時における処理である。続いてロード時における処理手順について説明する。
図４９は、データ管理テーブルに基づくロード処理の処理手順を示す図である。本フローチャートは、ステップＳ１３１〜ステップＳ１３３からなるループ処理を、タイトル再生が継続されている間、繰り返すというものである。
ステップＳ１３１は、ＡｕｔｏＲｕｎを示す起動属性を有したアプリケーションの生存区間が到来したか否かの判定である。もし到来すれば、ＡｕｔｏＲｕｎを示す起動属性を有したアプリケーションをアプリケーションｑにして（ステップＳ１３４）、アプリケーションｑを起動する旨の起動指示をＪａｖａ仮想マシン３８に発行して、アプリケーションｑをローカルメモリ２９からワークメモリ３７に読み出させる（ステップＳ１３５）。
ステップＳ１３３は、タイトル内ＰＬの再生が全て終了したかの判定である。この判定は、第５実施形態に示したように、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２からの再生終結イベントがあったか否かでなされる。もし終了すれば、本フローチャートの処理を終了する。
ステップＳ１３２は、起動中アプリケーションからの呼出があったか否かの判定である。もしあれば、呼出先アプリケーションをアプリケーションｑにして（ステップＳ１３６）、現在の再生時点は、アプリケーション管理テーブルにおけるアプリケーションｑの生存区間であるか否かを判定する（ステップＳ１３７）。もし生存区間でなければ、起動失敗を表示して（ステップＳ１４８）、ステップＳ１３１〜ステップＳ１３３からなるループ処理に戻る。生存区間であれば、図５０のフローチャートに従い、ロード処理を行う。
図５０におけるステップＳ１３８は、現在の再生時点がデータ管理テーブルにおけるアプリケーションｑの生存区間であるか否かを示す判定である。もし生存区間でなければ、アプリケーションｑはローカルメモリ２９にロードすることができない。この場合、アプリケーションｑを起動する旨の起動指示をＪａｖａ仮想マシン３８に発行し、ローカルメモリ２９を介することなく、直接アプリケーションｑをＢＤ−ＲＯＭからワークメモリ３７に読み出させる。この場合アプリケーションを読み出すためのヘッドシークが発生するから、ＰＬ再生は中断することになる（ステップＳ１４５）。
もし生存区間であれば、ステップＳ１３９において、アプリケーションには読込属性が付加されているか否かを判定する。読込属性がないということは、アプリケーションｑは、カルーセル化、若しくはインターリーブ化されていないことを意味する。しかし読込属性が付加されていなくても、ローカルメモリ２９にアプリケーションｑを置くことは許される。そこで再生中断を承知の上、アプリケーションの読み出しを行う。つまりＢＤ−ＲＯＭからローカルメモリ２９へとアプリケーションを読み出した上で、アプリケーションをワークメモリ３７に読み出す（ステップＳ１４０）。
ステップＳ１４１〜ステップＳ１４６は、ステップＳ１３９がＹｅｓと判定された場合になされる処理である。ステップＳ１４１では、読込属性を参照することで、アプリケーションがプリロードされているか否かを判定する。プリロードされていれば、ステップＳ１３５に移行する。
ステップＳ１４２は、読込属性がロードである場合に実行される判定ステップであり、アプリケーションｑがカルーセル化されているか、インターリーブ化されているかを判定する。インターリーブ化されていれば、キャッシュセンスをＪａｖａ仮想マシン３８に実行させる（ステップＳ１４３）。ローカルメモリ２９にアプリケーションｑが存在すれば、ステップＳ１３５に移行して、アプリケーションｑをＪａｖａ仮想マシン３８にロードさせる。
ローカルメモリ２９にアプリケーションがなければ、トップメニュータイトルに分岐する等の例外処理を行う（ステップＳ１４４）。カルーセル化されていれば、タイマをセットし（ステップＳ１４８）、そのタイマがタイムアウトするまで（ステップＳ１４７）、キャッシュセンスをＪａｖａ仮想マシン３８に実行させる（ステップＳ１４６）。もしローカルメモリ２９にアプリケーションｑが出現すれば、図４９のステップＳ１３５に移行して、アプリケーションｑをＪａｖａ仮想マシン３８にロードさせる。タイムアウトすれば、トップメニュータイトルに分岐する等の例外処理を行う（ステップＳ１４４）。
図５１は、Ｊａｖａ仮想マシン３８によるアプリケーションの読み込みがどのようにして行われるかを模式化した図である。
矢印◎１，２は、アプリケーション管理テーブルに生存していて、データ管理テーブルに生存しており、カルーセル化，インターリーブ化を示す読込属性が存在するＪａｖａアーカイブファイルの読み込みを示す。矢印◎１は、ステップＳ６５、６７においてなされるローカルメモリ２９センスを示す。このローカルメモリ２９センスは、カルーセル又はインターリーブ化により埋め込まれたデータが、ローカルメモリ２９に存在するかもしれないためローカルメモリ２９内をセンスるというものである。矢印◎２は、ステップＳ１３５に対応する読み込みであり、アプリケーションがローカルメモリ２９に存在していた場合の、ローカルメモリ２９からワークメモリ３７へのロードを示す。×付きの矢印は、ローカルメモリ２９にデータがない場合を示す。
矢印▽１，２は、アプリケーション管理テーブルに生存しているが、データ管理テーブルに生存しておらず、読込属性が存在しないＪａｖａアーカイブファイルの読み込みを示す。
矢印▽１は、ステップＳ１４５における読み込みに対応するものであり、Ｊａｖａ仮想マシン３８によるＢＤ−ＲＯＭからのダイレクトリードの要求を示す。矢印▽２はその要求による、ＢＤ−ＲＯＭからワークメモリ３７へのＪａｖａアーカイブファイル読み出しを示す。
矢印☆１，２，３は、アプリケーション管理テーブルに生存していて、データ管理テーブルに生存しているが、読込属性が存在しないＪａｖａアーカイブファイルの読み込みを示す。
矢印☆１は、ステップＳ１４０における読み込みに対応するものであり、Ｊａｖａ仮想マシン３８によるＢＤ−ＲＯＭからのダイレクトリードの要求を示す。矢印☆２はその要求による、ローカルメモリ２９へのＪａｖａアーカイブファイルの読み出しを示す。矢印☆３はローカルメモリ２９からワークメモリ３７へのＪａｖａアーカイブファイルの読み出しを示す。
以上のように本実施形態によれば、ローカルメモリ２９上で同時に常駐されるアプリケーションの数が所定数以下になるように規定しておくことができるので、ローカルメモリ２９からの読み出し時におけるキャッシュミスを極力回避することができる。キャッシュミスのないアプリケーション読み出しを保証することができるので、アプリケーション呼出時にあたては、ＡＶＣｌｉｐの再生を止めてまで、ＢＤ−ＲＯＭからアプリケーションを読み出すことはなくなる。ＡＶＣｌｉｐ再生を途切れさせないので、ＡＶＣｌｉｐのシームレス再生を保証することができる。
（第７実施形態）
第３実施形態では、非ＡＶ系タイトルの時間軸をアプリケーションの生存区間に基づき定めることにした。しかしアプリケーションの動作というのは不安定であり、起動の失敗や異常終了がありうる。本実施形態は、起動失敗、異常終了があった場合のＦａｉｌ Ｓａｆｅ機構を提案するものである。図５２（ａ）は、第７実施形態に係るＢＤ−Ｊオブジェクトの内部構成を示す図である。図７（ｂ）と比較して本図が新規なのは、プレイリスト管理テーブルが追加されている点である。
図５２（ｂ）は、プレイリスト管理テーブルの一例を示す図である。本図に示すようにプレイリスト管理テーブルは、ＰＬの指定と、そのＰＬの再生属性とからなる。ＰＬの指定は、対応するタイトルのタイトル時間軸において、再生可能となるＰＬを示す。ＰＬの再生属性は、指定されたＰＬを、タイトル再生の開始と同時に自動再生するか否かを示す（こうして自動再生されるＰＬをデフォルトＰＬという）。
次にプレイリスト管理テーブルによりタイトル時間軸がどのように規定されるかを、図５３を参照しながら説明する。図５３（ａ）は、再生属性が非自動再生を示すよう設定された場合の非ＡＶ系タイトルにおけるタイトル時間軸を示す図である。この場合、デフォルトＰＬは再生されないから、非ＡＶ系タイトル同様、アプリケーションの生存区間からタイトル時間軸が定まる。
図５３（ｂ）は、再生属性がＡｕｔｏＰｌａｙに設定された非ＡＶ系タイトルのタイトル時間軸を示す図である。再生属性がＡｕｔｏＰｌａｙを示すよう設定されれば、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２は非ＡＶ系タイトルの再生開始と同時に、デフォルトＰＬの再生を開始する。しかしアプリケーションが正常に動作し、正常終了したとしても、このタイトル時間軸は、ＰＬ時間軸を基準にして定められる。
図５３（ｃ）は、プレイリスト管理テーブルにおいて再生属性が”ＡｕｔｏＰｌａｙ”を示すよう設定され、アプリケーションが異常終了した場合を示す。かかる異常終了により、どのアプリケーションも動作してない状態になるが、デフォルトＰＬの再生は継続する。この場合も、デフォルトＰＬのＰＬ時間軸がタイトル時間軸になる。
図５３（ｄ）は、プレイリスト管理テーブルにおいて再生属性が”ＡｕｔｏＰｌａｙ”を示すよう設定され、メインアプリの起動に失敗したケースを示す。この場合も、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２によるデフォルトＰＬ再生は、アプリケーションの起動失敗とは関係なしに行われるので、デフォルトＰＬの時間軸がタイトル時間軸になる。
以上のようにプレイリスト管理テーブルの再生属性を、”ＡｕｔｏＰｌａｙ”に設定しておけば、Ｊａｖａアプリケーションの起動に、５〜１０秒という時間がかかったとしても、その起動がなされている間、”とりあえず何かが写っている状態”になる。この”とりあえず何かが写っている状態”によりタイトル実行開始時のスタートアップディレイを補うことができる。
以上は本実施形態における記録媒体に対する改良である。続いて本実施形態における再生装置に対する改良について説明する。
図５２（ｃ）は、分岐先タイトルのプレイリスト管理テーブルにおいて、再生属性がＡｕｔｏＰｌａｙに設定されたＰＬが存在する場合、再生装置がどのような処理を行うかを示す図である。本図に示すように、再生属性がＡｕｔｏＰｌａｙに設定されたＰＬが、分岐先タイトルのプレイリスト管理テーブルに存在すれば、ＢＤ−Ｊモジュール３５内のアプリケーションマネージャ３６は、タイトル分岐直後にこのＡｕｔｏＰｌａｙＰＬの再生を開始するようＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に指示する。このように再生属性がＡｕｔｏＰｌａｙのＰＬは、タイトル分岐直後に再生開始が命じられることになる。
上述した記録媒体の改良に対応するため、アプリケーションマネージャ３６は図５４に示すような処理手順で処理を行う。
図５４は、第７実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。本フローチャートは、図３８のフローチャートにおいてステップＳ２１の前にステップＳ１０３、ステップＳ１０４を追加し、ステップＳ２１と、ステップＳ２２との間にステップＳ１００を追加し、ステップＳ２３−ステップＳ２６間に、ステップＳ１０５を追加したものである。
ステップＳ１０３は、対応するタイトルのプレイリスト管理テーブルの再生属性がＡｕｔｏＰｌａｙであるか否かの判定である。もしＡｕｔｏＰｌａｙなら、デフォルトＰＬに対する再生制御をＰｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２に開始させる（ステップＳ１０４）。
ステップＳ１００は、Ｐｒｅｓｅｎｔａｔｉｏｎ Ｅｎｇｉｎｅ３１による再生中であるか否かを判定する。もし再生中であるなら、ステップＳ１０１に移行する。
ステップＳ１０５は、ステップＳ２３がＹｅｓ、ステップＳ２５がＮｏである場合に実行される判定ステップであり、再生属性がＡｕｔｏＰｌａｙであるか否かを示す。もし否であるなら、タイトル終了をモジュールマネージャ３４に通知する。もしＡｕｔｏＰｌａｙであるなら、ステップＳ１０１に移行して、処理を継続する。
図５５は、プレイリスト管理テーブルにおいて”再生属性＝ＡｕｔｏＰｌａｙ”に設定されることにより、どのような再生が行われるかを模式化した図である。ここで再生すべきタイトルは、落下するタイル片を積み重ねるというゲー厶アプリを含む非ＡＶ系タイトルである。この非ＡＶ系タイトルにおいて、プレイリスト管理テーブルの再生属性がＡｕｔｏＰｌａｙに設定されていれば、Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅ３２によるデフォルトＰＬ再生も開始する。ゲームアプリの実行と、デフォルトＰＬ再生とが並列的になされるので、図５５の上段の左側に示すように、前景をゲームアプリの画面とし、背景をデフォルトＰＬの再生画像とした合成画像が表示されることになる。このゲームアプリは途中で異常終了したとする。ゲームアプリはアプリケーションマネージャ３６により強制終了させられるが、デフォルトＰＬの再生が継続してなされるため、タイトルは、何かが写っている状態になる。このようなプレイリスト管理テーブルにおける再生属性の指定により、非ＡＶ系タイトル内のゲームアプリが異常終了した場合でも、ハングアップやブラックアウトがない動作を維持することができる。
（第８実施形態）
第１実施形態においてＢＤ−Ｊオブジェクトは、データ管理テーブル、アプリケーション管理テーブルという２つのテーブルを具備していたが、本実施形態は、これらを１つのテーブルに統合するという形態を開示する。かかる統合にあたって、図５６（ａ）に示すように、データ管理テーブルにおける読込属性という項目を廃し、代わりに起動属性にＲｅａｄｙ属性という属性を設ける。Ｒｅａｄｙ属性とは、他のアプリケーションからの呼出又はアプリケーションマネージャ３６からの呼出に備えて、ローカルメモリ２９に予めアプリケーションをロードしておく旨を示す起動属性の類型である。
図５６（ｂ）は、アプリケーションの扱いと、起動属性との関係を示した図である。第１実施形態に示したようにアプリケーションの扱いには、プリロードされるか否か（１）、現在の再生時点が有効区間に到来した際自動的に起動されるか、他からの呼出に応じて起動されるか（２）、タイトル再生進行に従ってロードされるか（３）、生存しているかという違いがあり、これらの違いにより、図５６（ｂ）に示すような５つの態様が出現する。このうち起動属性がＡｕｔｏＲｕｎに設定されるのは、プリロードがなされ、”自動起動”である場合、及び、ロードがなされ、”自動起動”である場合である。
一方、起動属性がＲｅａｄｙ属性に設定されるのは、プリロード、又は、ロードがなされ、起動項目が”呼出起動”を示している場合である。
尚、ワークメモリ３７では生存しているが、ローカルメモリ２９にはロードされない”との類型が存在し得ない。これは、アプリケーション・データ管理テーブルでは、ワークメモリ３７の生存区間と、ローカルメモリ２９の生存区間とが一体だからである。
起動属性として、このＲｅａｄｙ属性を追加されたので、アプリケーションマネージャ３６はタイトル再生に先立ち、起動属性がＡｕｔｏＲｕｎに設定されたアプリケーション、及び、起動属性がＲｅａｄｙ属性に設定されたアプリケーションをローカルメモリ２９にプリロードするとの処理を行う。こうすることにより、読込属性を設けなくても、アプリケーションをローカルメモリ２９にプリロードしておくとの処理が可能になる。
図５７は、第８実施形態に係るＪａｖａ仮想マシン３８によるアプリケーションの読み込みがどのようにして行われるかを模式化した図である。本図における読み込みは、図５１をベースにして作図している。
矢印◎１，２は、アプリケーション・データ管理テーブルに生存していて、起動属性がＲｅａｄｙ属性に設定されているＪａｖａアーカイブファイルの読み込みを示す。
矢印☆１，２，３は、アプリケーション・データ管理テーブルに生存していおり、起動属性がＰｅｒｓｉｓｔｅｎｔであるアプリケーションの読み込みを示す。
これらの矢印◎１，２、矢印☆１，２，３は、図５１でも記述されていたものだが、図５１に記述していた、▽１，２の矢印に該当する読み込み”は、図５７では存在しない。これは、アプリケーション・データ管理テーブルは、アプリケーション管理テーブル、データ管理テーブルを一体化したものなので、アプリケーション管理テーブル＝生存、データ管理テーブル＝非存在という組合せは表現し得ないからである。
以上のように本実施形態によれば、データ管理テーブル、アプリケーション管理テーブルを１つのテーブル（アプリケーション・データ管理テーブル）にまとめることができるので、アプリケーションマネージャ３６による処理を簡略化することができる。尚、読込優先度をなくすことによりアプリケーション・データ管理テーブルをより簡略化にしても良い。
（第９実施形態）
第１実施形態では、アプリケーションをローカルメモリ２９に読み込むにあたって、読込優先度を参照して、この読込優先度に従い、読み込み処理に優劣を与えた。これに対し第９実施形態は、Ｏｐｔｉｏｎａｌを意味する情報と、０から２５５までの数値との組合せにより読込優先度を表す実施形態である。
図５８（ａ）（ｂ）は、第９実施形態に係る読込優先度の一例を示す図である。２５５、１２８は、０から２５５までの読込優先度の一例であり、本例におけるａｐｐｌｉｃａｔｉｏｎ＃２は、ａｐｐｌｉｃａｔｉｏｎ＃３より読込優先度が高いことを意味する。
本実施形態においてアプリケーションマネージャ３６は、第１実施形態同様、先ずＭａｎｄａｔｏｒｙを示す読込優先度が付与されたアプリケーションをローカルメモリ２９に読み込む。
その後、Ｏｐｔｉｏｎａｌを示す読込優先度が付与されたアプリケーションに対しては、ローカルメモリ２９における容量が、アプリケーションのサイズを上回るか否かを判定する。もし上回るなら、読込優先度＝Ｏｐｔｉｏｎａｌが付与されたアプリケーションをそのままローカルメモリ２９に読み込む。もし下回るなら、アプリケーションを構成するデータのうち、読込優先度を表す数値が高いアプリケーションをローカルメモリ２９に読み込む。そして、ローカルメモリ２９における残りの領域に、読込優先度を表す数値が低いアプリケーションを読み出す。
こうすることでＯｐｔｉｏｎａｌ扱いのアプリケーションについては、全体を格納する容量が再生装置のローカルメモリ２９になくても、その一部分をローカルメモリ２９に格納しておくことができる。
（第１０実施形態）
第１実施形態においてアプリケーションマネージャ３６は、同じａｐｐｌｉｃａｔｉｏｎＩＤが付与されたアプリケーションを、読込優先度に従い排他的にローカルメモリ２９にロードするとしたが、第１０実施形態は、アプリケーションにグループ属性を与えることにより、排他的なロードを実現する。図５９は、グループ属性が付与されたデータ管理テーブルを示す図である。グループ属性には、排他グループなし、排他グループあり、といった、２通りの設定が可能であり、排他グループありの場合、そのグループ番号が記述される。図５９（ａ）におけるｔｉｔｌｅ＃１の「−」は、排他グループが存在しないことを示す。一方、ｔｉｔｌｅ＃２，＃３の「ｇｒｏｕｐ＃１」は、排他グループがあり、ｔｉｔｌｅ＃２，＃３は、ｇｒｏｕｐ＃１という排他グループに帰属していることを示す。以上が本実施形態に係る記録媒体の改良である。
本実施形態に係る再生装置は、データ管理テーブルに基づいて各アプリケーションをローカルメモリ２９に読み込んだ後、ローカルメモリ２９のアプリケーションにおけるグループ属性をベリファイする。同じ排他グループに帰属するアプリケーションが、ローカルメモリ２９上に２つ以上存在していれば、そのうち一方をローカルメモリ２９から削除する。
こうすることにより、ローカルメモリ２９の利用効率を向上させることができる。排他グループの具体例としては、ランチャーアプリと、このアプリにより起動されるアプリとからなるグループが相応しい。本アプリケーションにより起動されるアプリケーションは、原則１つに限られるので、ローカルメモリ２９には、ランチャー＋１個のアプリケーションのみが存在する筈である。もし３つ以上のアプリケーションが存在していれば、これをローカルメモリ２９から削除するという処理をアプリケーションマネージャ３６は行う必要があるので、各アプリケーションのグループ属性を設け、ローカルメモリ２９上で存在するアプリケーションがランチャー＋１個のアプリケーションになっているかどうかのチェックを行うのである。
図５９（ａ）は、アプリケーション管理テーブルに基づくローカルメモリ２９に対するアクセスを示す図である。本図において、読込優先度＝Ｏｐｔｉｏｎａｌと設定されたａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３のグループ属性は、ｇｒｏｕｐ＃１であるので、これらのアプリケーションは、同じ排他グループに属することになる。３つのアプリケーションのうち、ａｐｐｌｉｃａｔｉｏｎ＃１は上述したランチャーアプリケーションであり、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３は、これにより起動されるアプリケーションであるので、どちらかのみがローカルメモリ２９上に存在するよう、グループ属性が付与されている。アプリケーションマネージャ３６は、これらａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３のグループ属性を参照して、どちらか１つをローカルメモリ２９から削除するとの処理を行う。かかる削除によりローカルメモリ２９に余白が生まれる。
（第１１実施形態）
第１実施形態では、アプリケーション管理テーブルをタイトル毎に持たせるとしたが、本実施形態では、このアプリケーション管理テーブルの割当単位を変更させることを提案する。図６０は、割当単位のバリエーションを示す図である。本図において第１段目は、ＢＤ−ＲＯＭに記録されている３つのアプリケーション管理テーブルを示し、第２段目は、タイトル単位、第３段目は、ディスク単位、第４段目は、複数ＢＤ−ＲＯＭからなるディスクセット単位を示す。図中の矢印は、アプリケーション管理テーブルの割り当てを模式化して示している。この矢印を参照すると、第１段目におけるアプリケーション管理テーブル＃１，＃２，＃３のそれぞれは、第２段目に示したｔｉｔｌｅ＃１，＃２，＃３のそれぞれに割り当てられていることがわかる。また、ディスク単位ではアプリケーション管理テーブル＃４が割り当てられており、ディスクセット全体に対しはアプリケーション管理テーブル＃５が割り当てられている。このようにアプリケーション管理テーブルの割当単位を、タイトルより大きい単位にすることにより、１つのＢＤ−ＲＯＭがローディングされている間、生存するようなアプリケーションや複数ＢＤ−ＲＯＭのうちどれかがローディングされている間、生存するようなアプリケーションを定義することができる。
（備考）
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記（Ａ）（Ｂ）（Ｃ）（Ｄ）・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の技術分野の、出願当時の技術水準の特性に基づく。
（Ａ）全ての実施形態では、本発明に係る光ディスクをＢＤ−ＲＯＭとして実施したが、本発明の光ディスクは、記録される動的シナリオ、Ｉｎｄｅｘ Ｔａｂｌｅに特徴があり、この特徴は、ＢＤ−ＲＯＭの物理的性質に依存するものではない。動的シナリオ、Ｉｎｄｅｘ Ｔａｂｌｅを記録しうる記録媒体なら、どのような記録媒体であってもよい。例えば、
ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−ＲＷ，ＤＶＤ−Ｒ，ＤＶＤ＋ＲＷ，ＤＶＤ＋Ｒ，ＣＤ−Ｒ，ＣＤ−ＲＷ等の光ディスク、ＰＤ，ＭＯ等の光磁気ディスクであってもよい。また、コンパクトフラッシュカード、スマートメディア、メモリスティック、マルチメディアカード、ＰＣＭ−ＣＩＡカード等の半導体メモリカードであってもよい。フレシキブルディスク、ＳｕｐｅｒＤｉｓｋ，Ｚｉｐ，Ｃｌｉｋ！等の磁気記録ディスク（ｉ）、ＯＲＢ，Ｊａｚ，ＳｐａｒＱ，ＳｙＪｅｔ，ＥＺＦｌｅｙ，マイクロドライブ等のリムーバルハードディスクドライブ（ｉｉ）であってもよい。更に、機器内蔵型のハードディスクであってもよい。
（Ｂ）全ての実施形態における再生装置は、ＢＤ−ＲＯＭに記録されたＡＶＣｌｉｐをデコードした上でＴＶに出力していたが、再生装置をＢＤ−ＲＯＭドライブのみとし、これ以外の構成要素をＴＶに具備させてもい、この場合、再生装置と、ＴＶとをＩＥＥＥ１３９４で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレィと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなす部分のみを、再生装置としてもよい。これらの再生装置は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、各実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。各実施形態に示した再生装置の有償・無償による譲渡（有償の場合は販売、無償の場合は贈与になる）、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。
（Ｃ）各フローチャートに示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムの実施行為についての実施形態を示したが、再生装置から分離して、各実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラ厶を生産する行為（１）や、有償・無償によりプログラムを譲渡する行為（２）、貸与する行為（３）、輸入する行為（４）、双方向の電子通信回線を介して公衆に提供する行為（５）、店頭展示、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為（６）がある。
（Ｄ）各フローチャートにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフローチャートによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフローチャートの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。
（Ｅ）Ｃｈａｐｔｅｒを一覧表示するためのＭｅｎｕ（Ｃｈａｐｔｅｒ Ｍｅｎｕ）と、これの挙動を制御するＭＯＶＩＥオブジェクトとをＢＤ−ＲＯＭに記録しておき、Ｔｏｐ Ｍｅｎｕから分岐できるようにしてもよい。またリモコンキーのＣｈａｐｔｅｒキーの押下により呼出されるようにしてもよい。
（Ｆ）ＢＤ−ＲＯＭに記録するにあたって、ＡＶＣｌｉｐを構成する各ＴＳパケットには、拡張ヘッダを付与しておくことが望ましい。拡張ヘッダは、ＴＰ ｅｘｔｒａ ｈｅａｄｅｒと呼ばれ、『Ａｒｒｉｂｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐ』と、『ｃｏｐｙ＿ｐｅｒｍｉｓｓｉｏｎ＿ｉｎｄｉｃａｔｏｒ』とを含み４バイトのデータ長を有する。ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒ付きＴＳパケット（以下ＥＸ付きＴＳパケットと略す）は、３２個毎にグループ化されて、３つのセクタに書き込まれる。３２個のＥＸ付きＴＳパケットからなるグループは、６１４４バイト（＝３２×１９２）であり、これは３個のセクタサイズ６１４４バイト（＝２０４８×３）と一致する。３個のセクタに収められた３２個のＥＸ付きＴＳパケットを”Ａｌｉｇｎｅｄ Ｕｎｉｔ”という。
ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時において、再生装置２００は、以下のような送信処理にてＡｌｉｇｎｅｄ Ｕｎｉｔの送信を行う。つまり送り手側の機器は、Ａｌｉｇｎｅｄ Ｕｎｉｔに含まれる３２個のＥＸ付きＴＳパケットのそれぞれからＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒを取り外し、ＴＳパケット本体をＤＴＣＰ規格に基づき暗号化して出力する。ＴＳパケットの出力にあたっては、ＴＳパケット間の随所に、ｉｓｏｃｈｒｏｎｏｕｓパケットを挿入する。この挿入箇所は、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒのＡｒｒｉｂｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐに示される時刻に基づいた位置である。ＴＳパケットの出力に伴い、再生装置２００はＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを出力する。ＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒは、ＴＰ＿ｅｘｔｒａ＿ｈｅａｄｅｒにおけるコピー許否設定を示す。ここで「コピー禁止」を示すようＤＴＣＰ＿Ｄｅｓｃｒｉｐｔｏｒを記述しておけば、ＩＥＥＥ１３９４を介して接続されたホームネットワークでの利用時においてＴＳパケットは、他の機器に記録されることはない。
（Ｇ）各実施形態において、記録媒体に記録されるデジタルストリームはＡＶＣｌｉｐであったが、ＤＶＤ−Ｖｉｄｅｏ規格、ＤＶＤ−Ｖｉｄｅｏ Ｒｅｃｏｒｄｉｎｇ規格のＶＯＢ（Ｖｉｄｅｏ Ｏｂｊｅｃｔ）であってもよい。ＶＯＢは、ビデオストリーム、オーディオストリームを多重化することにより得られたＩＳＯ／ＩＥＣ１３８１８−１規格準拠のプログラムストリームである。またＡＶＣｌｉｐにおけるビデオストリームは、ＭＰＥＧ４やＷＭＶ方式であってもよい。更にオーディオストリームは、Ｌｉｎｅａｒ−ＰＣＭ方式、Ｄｏｌｂｙ−ＡＣ３方式、ＭＰ３方式、ＭＰＥＧ−ＡＡＣ方式、Ｄｔｓ、ＷＭＡ（Ｗｉｎｄｏｗｓ ｍｅｄｉａ ａｕｄｉｏ）であってもよい。
（Ｈ）各実施形態における映像作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
またビデオテープに記録されているアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。
（Ｉ）ＢＤ−Ｊモジュール３５は、衛星放送受信のために機器に組み込まれたＪａｖａプラットフォームであってもよい。ＢＤ−Ｊモジュール３５がかかるＪａｖａプラットフォームであれば、本発明に係る再生装置は、ＭＨＰ用ＳＴＢとしての処理を兼用することになる。
更に携帯電話の処理制御のために機器に組み込まれたＪａｖａプラットフォームであってもよい。かかるＢＤ−Ｊモジュール３５がかかるＪａｖａプラットフォームであれば、本発明に係る再生装置は、携帯電話としての処理を兼用することになる。
（Ｋ）レイアモデルにおいて、ＢＤ−Ｊモードの上にＭＯＶＩＥモードを配置してもよい。特にＭＯＶＩＥモードでの動的シナリオの解釈や、動的シナリオに基づく制御手順の実行は、再生装置に対する負担が軽いので、ＭＯＶＩＥモードをＢＤ−Ｊモード上で実行させても何等問題は生じないからである。また再生装置や映画作品の開発にあたって、動作保証が１つのモードで済むからである。
更にＢＤ−Ｊモードだけで再生処理を実行してもよい。第５実施形態に示したように、ＢＤ−ＪモードでもＰＬの再生と同期した再生制御が可能になるから、強いてＭＯＶＩＥモードを設けなくてもよいという理由による。
（Ｌ）ＡＶＣｌｉｐに多重化されるべきインタラクティブグラフィクスストリームにナビゲーションコマンドを設けて、あるＰＬから別のＰＬへの分岐を実現しても良い。
本発明に係る再生装置は、ホームシアターシステムでの利用のように、個人的な用途で利用されることがありうる。しかし本発明は上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る再生装置は、産業上の利用可能性を有する。
【書類名】明細書
【技術分野】
【０００１】
本発明は、仮想マシンを対象にしたプログラムの起動を制御する、起動制御技術の技術分野に属する発明であり、本起動制御技術を記録媒体、民生用の再生装置、プログラムに応用する場合の応用技術に深く係る。
【背景技術】
【０００２】
Javaプログラム等、仮想マシンを対象にした制御技術は、通信、放送を初め、様々な技術分野に浸透している。特に放送分野においては、デジタル映像の再生に従って、Javaアプリケーションを動作させるという技術が既に確立されており、Javaアプリケーションによるメニュー制御を伴った様々なサービスが、視聴者の興味を集めている。
かかる背景技術には、以下に示される文献公知発明が存在する。
【特許文献１】 特許第2813245号
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで放送分野から更に発展して、現在ディスクコンテンツにおける再生制御をJavaプログラミングで実現するための様々な工夫が検討されている。ここでディスクコンテンツの再生進行は、一本の再生時間軸に沿った単純なものではなく、ある再生時間軸から別の再生時間軸への分岐が有り得る複雑なものである。このディスクコンテンツにおいてこの分岐の単位は、タイトルと呼ばれる。タイトルは、1つ以上の再生時間軸をもち、アプリケーションはこのタイトル内の時間軸上に、起動時点、終了時点が定義されることになる。ここで、あるタイトル内の時間軸に沿ってアプリケーションを動作させようとすると、タイトルからタイトルへの分岐が発生した際、現在起動中のアプリケーションを全て終了させたり、更に、改めてアプリケーションを起動しなおすという手間が多く発生する。ここで、1つのタイトル終了から、次のタイトル開始までをタイトルバウンダリというが、多くのアプリケーションを起動させたり、終了させる必要があると、このタイトルバウンダリの期間が異様に長くなり、分岐先タイトルの再生がなかなか開始しないという事態が生じる。
【０００４】
本発明の目的は、アプリケーションロードやアプリケーション終了が何度も繰り返されることによる、タイトルバウンダリの長期間化を避けることができる再生装置を提供することである。
【課題を解決するための手段】
【０００５】
上記目的は、アプリケーションと、対応するタイトルにおけるアプリケーションの起動属性とを対応づけて示す管理テーブルが記録されており、起動属性には、分岐元タイトルにおいてアプリケーションが非起動状態である場合、当該分岐先タイトルにおいてアプリケーションを自動的に起動させる自動起動属性がある、ことを特徴とした記録媒体により達成される。
【発明の効果】
【０００６】
この記録媒体における自動起動属性は、分岐元においてアプリケーションが非起動状態である場合、当該アプリケーションを自動的に起動させる旨を示しているので、分岐元非起動−分岐先自動起動属性の組合せのみアプリケーションを起動する。アプリケーションの起動は、分岐元非起動−分岐先自動起動属性の組合せ時に限られるので、タイトル間の分岐により、再生が複雑に進行したとしても、アプリケーション起動処理が冗長に行われることにない。冗長なアプリケーション起動を避けることができるので、タイトルバウンダリを短期間にすることができる。これによりタイトルバウンダリをユーザに意識させないスムーズな再生制御を実現することができる。このため、複数タイトルにわたるような長編もののコンテンツや、DVD−BOXのように、複数BD-ROMに記録されたシリーズ物コンテンツを提供する場合に真価を発揮する。
【発明を実施するための最良の形態】
【０００７】
(第１実施形態)
以降、本発明に係る再生装置の実施形態について説明する。先ず始めに、本発明に係る再生装置の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る再生装置の、使用行為についての形態を示す図である。図１において、本発明に係る再生装置は再生装置２００であり、リモコン３００、テレビ４００と共にホームシアターシステムを形成する。
【０００８】
このBD-ROM１００は、再生装置２００、リモコン３００、テレビ４００により形成されるホームシアターシステムに、映画作品を供給するという用途に供される。
以上が本発明に係る再生装置の使用形態についての説明である。
続いて本発明に係る再生装置の再生の対象となる、記録媒体であるBD-ROMについて説明する。BD-ROMにより、ホームシアターシステムに供給されるディスクコンテンツは、互いに分岐可能な複数タイトルから構成される。各タイトルは、1つ以上のプレイリストと、このプレイリストを用いた動的な制御手順とからなる。
【０００９】
プレイリストとは、1つ以上のデジタルストリームと、そのデジタルストリームにおける再生経路とから構成され、”時間軸”の概念をもつBD-ROM上のアクセス単位である。以上のプレイリストと、動的な制御手順とを包含しているため、タイトルはデジタルストリーム特有の時間軸の概念と、コンピュータプログラム的な性質とを併せもっている。
図２は、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が付与されたファイル(00001.mpls,00002.mpls,00003mpls)がある。
CLIPINFディレクトリには、拡張子clpiが付与されたファイル(00001.clpi,00002.clpi,00003.clpi)がある。
STREAMディレクトリには、拡張子m2tsが付与されたファイル(00001.m2ts,00002.m2ts,00003.m2ts)がある。
【００１２】
BDARディレクトリには、拡張子jarが付与されたファイル(00001.jar,00002.jar,00003jar)がある。以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、BD-ROM上に配置されていることがわかる。
本図において拡張子.m2tsが付与されたファイル(00001.m2ts,00002.m2ts,00003.m2ts・・・・・)は、AVClipを格納している。AVClipには、MainCLip、SubClipといった種別がある。MainCLipは、ビデオストリーム、オーディオストリーム、プレゼンテーショングラフィクスストリーム、インタラクティブグラフィクスストリームというような複数エレメンタリストリームを多重化することで得られたデジタルストリームである。
【００１３】
SubClipは、オーディオストリーム、グラフィクスストリーム、テキスト字幕ストリーム等、1つのエレメンタリストリームのみにあたるデジタルストリームである。
拡張子”clpi”が付与されたファイル(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情報は、複数のPlayItem情報からなる。PlayItemとは、1つ以上のAVClip時間軸上において、In_Time,Out_Timeを指定することで定義される再生区間である。PlayItem情報を複数配置させることで、複数再生区間からなるプレイリスト(PL)が定義される。図３は、AVClipと、PLとの関係を示す図である。第1段目はAVClipがもつ時間軸を示し、第2段目は、PLがもつ時間軸を示す。PL情報は、PlayItem#1,#2,#3という3つのPlayItem情報を含んでおり、これらPlayItem#1,#2,#3のIn_time,Out_timeにより、3つの再生区間が定義されることになる。これらの再生区間を配列させると、AVClip時間軸とは異なる時間軸が定義されることになる。これが第2段目に示すPL時間軸である。このように、PlayItem情報の定義により、AVClipとは異なる時間軸の定義が可能になる。
【００１６】
AVClipに対する指定は、原則1つであるが、複数AVClipに対する一括指定もあり得る。この一括指定は、PlayItem情報における複数のClip_Information_file_nameによりなされる。図４は、4つのClip_Information_file_nameによりなされた一括指定を示す図である。本図において第1段目〜第4段目は、4つのAVClip時間軸(AVClip#1,#2,#3,#4の時間軸)を示し、第5段目は、PL時間軸を示す。PlayItem情報が有する、4つのClip_Information_file_nameにて、これら4つの時間軸が指定されている。こうすることで、PlayItemが有するIn_time,Out_timeにより、択一的に再生可能な4つの再生区間が定義されることになる。これにより、PL時間軸には、切り換え可能な複数アングル映像からなる区間(いわゆるマルチアングル区間)が定義されることになる。
【００１７】
PLmark情報は、PL時間軸のうち、任意の区間を、チャプターとして指定する情報である。図５は、PLmarkによるチャプター定義を示す図である。本図において第1段目は、AVClip時間軸を示し、第2段目はPL時間軸を示す。図中の矢印pk1,2は、PLmarkにおけるPlayItem指定(ref_to_PlayItem_Id)と、一時点の指定(mark_time_stamp)とを示す。これらの指定によりPL時間軸には、3つのチャプター(Chapter#1,#2,#3)が定義されることになる。
【００１８】
SubPath情報は、複数のSubPlayItem情報からなる。SubPlayItem情報は、SubClipの時間軸上にIn_Time,Out_Timeを指定することで再生区間を定義する。またSubPlayItem情報は、SubClip時間軸上の再生区間を、PL時間軸に同期させるという同期指定が可能であり、この同期指定により、PL時間軸と、SubPlayItem情報時間軸とは同期して進行することになる。図６は、SubPlayItem時間軸上の再生区間定義と、同期指定を示す図である。本図において第1段目は、PL時間軸を示し、第2段目はSubPlayItem時間軸を示す。図中のSubPlayItem.IN_timeは再生区間の始点を、SubPlayItem.Out_timeは再生区間の終点をそれぞれ示す。これによりSubClip時間軸上にも再生区間が定義されていることがわかる。矢印Sn1においてSync_PlayItem_Idは、PlayItemに対する同期指定を示し、矢印Sn2においてsync_start_PTS_of_PlayItemは、PL時間軸におけるPlayItem上の一時点の指定を示す。
【００１９】
複数AVClipの切り換えを可能とするマルチアングル区間や、AVClip−SubClipを同期させ得る同期区間の定義を可能とするのが、BD-ROMにおけるプレイリスト情報の特徴である。以上のClip情報及びプレイリスト情報は、”静的シナリオ”に分類される。何故なら、以上のClip情報及びプレイリスト情報により、静的な再生単位であるPLが定義されるからである。以上で静的シナリオについての説明を終わる。
【００２０】
続いて”動的なシナリオ”について説明する。動的シナリオとは、AVClipの再生制御を動的に規定するシナリオデータである。”動的に”というのは、再生装置における状態変化やユーザからのキーイベントにより再生制御の中身がかわることをいう。BD-ROMでは、この再生制御の動作環境として2つのモードを想定している。1つ目は、DVD再生装置の動作環境と良く似た動作環境であり、コマンドベースの実行環境である。2つ目は、Java仮想マシンの動作環境である。これら2つの動作環境のうち1つ目は、HDMVモードと呼ばれる。2つ目は、BD-Jモードと呼ばれる。これら2つの動作環境があるため、動的シナリオはこのどちらかの動作環境を想定して記述される。HDMVモードを想定した動的シナリオはMovieオブジェクトと呼ばれ、管理情報により定義される。一方BD-Jモードを想定した動的シナリオはBD-Jオブジェクトと呼ばれる。
【００２１】
先ず初めにMovieオブジェクトについて説明する。
＜Movieオブジェクト＞
Movieオブジェクトは、”タイトル”の構成要素であり、ファイルMovieObject.bdmvに格納される。図７（ａ）は、Movieオブジェクトの内部構成を示す図である。Movieオブジェクトは、属性情報、複数のナビゲーションコマンドからなるコマンド列からなる。
【００２２】
属性情報は、PL時間軸において、MenuCallがなされた際、MenuCall後の再生再開を意図しているか否かを示す情報(resume_intention_flag)、PL時間軸においてMenuCallをマスクするかを示す情報(menu_call_mask)、タイトルサーチをマスクするかを示す情報(title_search_flag)からなる。Movieオブジェクトは、”時間軸”+”プログラム的制御”という2つの性質を併せ持つことができるで、本編再生を実行するもの等、多様な種類のタイトルがこのMovieオブジェクトにより記述されることになる。
【００２３】
ナビゲーションコマンド列は、条件分岐、再生装置における状態レジスタの設定、状態レジスタの設定値取得等を実現するコマンド列からなる。Movieオブジェクトにおいて記述可能なコマンドを以下に示す。

PlayPLコマンド
書式:PlayPL(第１引数，第２引数)
第１引数は、プレイリストの番号で、再生すべきPLを指定することができる。第２引数は、そのPLに含まれるPlayItemや、そのPLにおける任意の時刻、Chapter、Markを用いて再生開始位置を指定することができる。
【００２４】
PlayItemによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatPlayItem()、
ChapterによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatChapter()、
時刻情報によりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatSpecified Time()という。

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


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

国際公開公報W0 2004/074976

以上でMovieオブジェクトについての説明を終える。続いてBD-Jオブジェクトについて説明する。
【００２５】
＜BD-Jオブジェクト＞
拡張子BD-Jが付与されたファイル(00001.BD-J,00002.BD-J,00003.BD-J)は、BD-Jオブジェクトを構成する。BD-Jオブジェクトは、Javaプログラミング環境で記述された、BD-Jモードの動的シナリオである。図７（ｂ）は、BD-Jオブジェクトの内部構成を示す図である。本図に示すようにBD-Jオブジェクトは、Movieオブジェクト同様の属性情報、アプリケーション管理テーブルからなる。属性情報を有している点でBD-JオブジェクトはMovieオブジェクトとほぼ同じである。Movieオブジェクトとの違いは、BD-Jオブジェクトはコマンドが直接記述されていない点である。つまりMovieオブジェクトにおいて制御手順は、ナビゲーションコマンドにより直接記述されていた。これに対しBD-Jオブジェクトでは、そのタイトルを生存区間としているJavaアプリケーションをアプリケーション管理テーブル上に定めることにより、間接的に制御手順を規定している。このような間接的な規定により、複数タイトルにおいて制御手順を共通化するという、制御手順の共通化を効率的に行うことができる。
【００２６】
図７（ｃ）は、Javaアプリケーションの内部構成を示す図である。本図においてアプリケーションは、仮想マシンのヒープ領域(ワークメモリとも呼ばれる)にロードされた1つ以上のxletプログラムからなる。このワークメモリでは、1つ以上のスレッドが動作しており、ワークメモリにロードされたxletプログラム、及び、スレッドから、アプリケーションは構成されることになる。以上がアプリケーションの構成である。
【００２７】
このアプリケーションの実体にあたるのが、BDMVディレクトリ配下のBDARディレクトリに格納されたJavaアーカイブファイル(00001.jar,00002.jar)である。以降、Javaアーカイブファイルについて説明する。
Javaアーカイブファイル(00001.jar,00002.jar)は、Javaアプリケーションを構成するプログラム、データを格納したアーカイブファイルである。図８（ａ）は、アーカイブファイルにより収められているプログラム、データを示す図である。本図におけるデータは、枠内に示すディレクトリ構造が配置された複数ファイルを、javaアーカイバでまとめたものである。枠内に示すディレクトリ構造は、rootディレクトリ、javaディレクトリ、imageディレクトリとからなり、rootディにcommon.pkgが、javaディレクトリにaaa.class,bbb.classが、imageディレクトリに、menu.jpgが配置されている。javaアーカイブファイルは、これらをjavaアーカイバでまとめることで得られる。かかるデータは、BD-ROMからキャッシュに読み出されるにあたって展開され、キャッシュ上で、ディレクトリに配置された複数ファイルとして取り扱われる。Javaアーカイブファイルのファイル名における"xxxxx"という5桁の数値は、アプリケーションのID(applicationID)を示す。本Javaアーカイブファイルがキャッシュに読み出された際、このファイル名における数値を参照することにより、任意のJavaアプリケーションを構成するプログラム，データを取り出すことができる。
【００２８】
Javaアーカイブファイルにおいて1つにまとめられるファイルには、xletプログラムがある。
xletプログラムは、JMF(Java Media FrameWork)インターフェイスを利用することができるJavaプログラムである。xletプログラムは、キーイベントを受信するEventListner等、複数の関数からなり、JMF等の方式に従って、受信したキーイベントに基づく処理を行う。
【００２９】
図８（ｂ）は、xletプログラムの一例を示す図である。JMF A”BD://00001.mpls”;は、PLを再生するプレーヤインスタンスの生成をJava仮想マシンに命じるメソッドである。A.playは、JMFプレーヤインスタンスに再生を命じるメソッドである。かかるJMFプレーヤインスタンス生成は、JMFライブラリに基づきなされる。xletプログラムの記述は、BD-ROMのPLに限らず、時間軸をもったコンテンツ全般に適用可能なJMFの記述である。このような記述が可能であるので、Javaプログラミングに長けたソフトハウスに、BD-Jオブジェクト作成を促すことができる。
【００３０】
図８（ｂ）におけるJumpTItle();は、ファンクションAPIのコールである。このファンクションAPIは、他のタイトルへの分岐(図中ではtitle#1)を再生装置に命じるものである。ここでファンクションAPIとは、BD-ROM再生装置により供給されるAPI(AppliationInterface)である。JumpTitleコマンドの他にも、ファンクションAPIのコールにより、BD-ROM再生装置特有の処理をxletプログラムに記述することができる。
【００３１】
BD-JモードにおいてPL再生は、JMFインターフェイスにより規定される。このJMFプレーヤインスタンスは、PL時間軸を定めるものだから、タイトル時間軸は、このJMFプレーヤインスタンスをもったタイトルから定まる。また
BD-Jモードにおいてタイトルからタイトルへの分岐はJumpTitleAPIのコールにより規定される。JumpTitleAPIコールは、いわばタイトルの終了時点を定めるものなので、こうしたJMFプレーヤインスタンス、JumpTitleAPIコールをもったアプリケーションが、BD-Jモードにおいてタイトルの開始及び終了を律することになる。かかるアプリケーションを本編再生アプリケーションという。
【００３２】
以上が、BD-Jモードにおける動的シナリオについての説明である。このBD-Jモードにおける動的シナリオにより、PL再生と、プログラム的制御とを併せもったタイトルが定義されることになる。尚、本実施形態においてアプリケーションを構成するプログラム、データは、Javaアーカイブファイルにまとめられたが、LZHファイル、zipファイルであってもよい。
【００３３】
＜タイトル時間軸＞
タイトルを構成する静的シナリオ、動的シナリオについて説明を終えたところで、これらによりどのような時間軸が定義されるかについて説明する。タイトルにより定義される時間軸は、”タイトル時間軸”と呼ばれる。タイトル時間軸とは、Movieオブジェクト、又は、BD-Jオブジェクトにより再生が命じられるPLにより構成される。ここで一例を挙げるのは、図９（ａ）のようなタイトルである。このタイトルは、トップメニュー→title#1→title#2→トップメニュー、トップメニュー→title#3→トップメニューという一連のタイトルである。かかるタイトルのうち、title#1はPlayList#1、PlayList#2、title#2がPlayList#3、title#3がPlayList#4の再生を命じるものなら、図９（ｂ）のように、PlayList#1、PlayList#2の時間軸を足し合わせた時間軸を、title#1はもつことになる。同様にtitle#2は、PlayList#3時間軸からなる時間軸を、title#3はPlayList#4時間軸からなる時間軸を持つことになる。これらタイトル時間軸におけるPL時間軸ではシームレス再生が保証されるが、タイトル時間軸間ではシームレス再生の保証は必要でなくなる。Javaアプリケーションを動作させるにあたっては、Javaアプリケーションを、仮想マシンのワークメモリ上に存在させてもよい期間(サービス期間)を、こうしたタイトル時間軸上に定義せねばならない。BD-JモードにおいてJavaアプリケーションを動作させるにあたっては、互いに分岐し合う時間軸上に、Javaアプリケーションのサービス期間を定義せねばならない。このサービス期間の定義が、BD-ROM向けのプログラミングを行うにあたっての留意点になる。
【００３４】
最後に、index.bdmvに格納されたIndexTableについて説明する。IndexTableは、タイトル番号と、Movieオブジェクト、BD-Jオブジェクトとを対応づけるテーブルであり、動的シナリオから動的シナリオへの分岐の際、参照される間接参照用テーブルである。IndexTableは、複数ラベルのそれぞれに対するIndexからなる。各Indexには、そのラベルに対応する動的シナリオの識別子が記述されている。こうしたIndexTableを参照することで、Movieオブジェクト、BD-Jオブジェクトの違いを厳密に区別することなく、分岐を実現することができる。IndexTableについては、以下の国際公開公報に詳細が記載されている。詳細については、本公報を参照されたい。

国際公開公報WO 2004/025651 A1公報

以上がBD-ROMに記録されているファイルについて説明である。
【００３５】
＜アプリケーション管理テーブル＞
JMFプレーヤインスタンス、JumpTitleAPIコールをもったアプリケーションが、タイトル時間軸を律することは上述した通りだが、JMFプレーヤインスタンスやJumpTitleAPIのコールをもたないその他のアプリケーションを、タイトル時間軸上で動作させる場合、時間軸の何処からアプリケーションによるサービスを開始し、時間軸の何処でアプリケーションによるサービスを終えるかという”サービスの開始点・終了点”を明確に規定することが重要になる。本実施形態では、アプリケーションによるサービスが開始してから、終了するまでを、”アプリケーションの生存”として定義する。アプリケーションの生存を定義するための情報は、BD-Jオブジェクトにおけるアプリケーション管理テーブルに存在する。以降アプリケーション管理テーブルについてより詳しく説明する。
【００３６】
アプリケーション管理テーブル(AMT)は、各タイトルが有しているタイトル時間軸において、仮想マシンのワークメモリ上で生存し得るアプリケーションを示す情報である。ワークメモリにおける生存とは、そのアプリケーションを構成するxletプログラムが、ワークメモリに読み出され、仮想マシンによる実行が可能になっている状態をいう。図７（ｂ）における破線矢印at1は、アプリケーション管理テーブルの内部構成をクローズアップして示す。この内部構成に示すように、アプリケーション管理テーブルは、『生存区間』と、そのタイトルを生存区間としているアプリケーションを示す『applicationID』と、そのアプリケーションの『起動属性』とからなる。
【００３７】
近い将来、実施されるであろうディスクコンテンツを題材に選んで、アプリケーション管理テーブルにおける生存区間記述について、具体例を交えて説明する。ここで題材にするディスクコンテンツは、映像本編を構成する本編タイトル(title#1)、オンラインショッピングを構成するオンラインショッピングタイトル(title#2)、ゲームアプリケーションを構成するゲームタイトル(title#3)という、性格が異なる3つのタイトルを含むものである。図１０は、本編タイトル、オンラインショッピングタイトル、ゲームタイトルという3つのタイトルを含むディスクコンテンツを示す図である。本図における右側にはIndexTableを記述しており、左側には3つのタイトルを記述している。
【００３８】
右側における破線枠は、各アプリケーションがどのタイトルに属しているかという帰属関係を示す。3つのタイトルのうちtitle#1は、application#1、application#2、application#3という3つのアプリケーションからなる。title#2は、application#3、application#4という2つのアプリケーション、title#3は、application#5を含む。図１１は、図１０に示した3つのタイトルの再生画像の一例を示す図である。これら3つのタイトルの再生画像において、図１１（ａ）（ｂ）の本編タイトル、オンラインショッピングタイトルには、ショッピングカートを模した映像(カートcr1)1が存在するが、図１１（ｃ）のゲームタイトルには、カート映像が存在しない。カートcr1は、本編タイトル、オンラインショッピングタイトルにおいて共通して表示しておく必要があるので、カートプログラムたる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」、自動起動の対象ではないが、仮想マシンのワークメモリに置いて良いことを示す「Persistent」、仮想マシンのワークメモリにはおかれるが、CPUパワーの割り当ては不可となる「Suspend」がある。
「AutoRun」は、対応するタイトルの分岐と同時に、そのアプリケーションをワークメモリに読み込み、且つ実行する旨を示す生存区間である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、その分岐先タイトルにおいて生存しており、かつ起動属性がAutoRunに設定されたアプリケーションを仮想マシンのワークメモリに読み込み実行する。これによりそのアプリケーションは、タイトル分岐と共に自動的に起動されることになる。起動属性をAutoRunに設定しておくアプリケーションとしては、JMFプレーヤインスタンス及びJumpTitleAPIコールをもつようなアプリケーションが挙げられる。何故なら、このようなアプリケーションは、タイトル時間軸を律する側のアプリケーションであり、このようなアプリケーションを自動的に起動にしないと、タイトル時間軸の概念が曖昧になってしまうからである。
【００４２】
起動属性「Persistent」は、継続属性であり、分岐元titleにおけるアプリケーションの状態を継続することを示す。またワークメモリにロードしてよいことを示す属性である。起動属性が「Persistent」である場合、この起動属性が付与されたアプリケーションは、他のアプリケーションからの呼び出しが許可されることになる。アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、起動中のアプリケーションから呼出があると、そのアプリケーションのapplicationIDが、アプリケーション管理テーブルに記述されていて、起動属性が「Persistent」であるか否かを判定する。「Persistent」であれば、そのアプリケーションをワークメモリにロードする。一方、その呼出先アプリケーションのapplicationIDがアプリケーション管理テーブルに記述されていない場合、そのアプリケーションはワークメモリにロードされない。アプリケーションによる呼出は、この「Persistent」が付与されたアプリケーションに限られることになる。
【００４３】
「Persistent」は、起動属性を明示的に指定しない場合に付与されるデフォルトの起動属性であるから、あるアプリケーションの起動属性が無指定「−−」である場合、そのアプリケーションの起動属性の起動属性はこのPersistentであることを意味する。
これらの起動属性が、図１１のアプリケーションにおいてどのように記述されているかについて説明する。図１３は、図１２の3つのアプリケーションに対する起動属性の設定例である。図１２に示した3つのアプリケーションのうちapplication#2は、図１３（ｂ）に示すように他のアプリケーションからのアプリケーション呼出があって初めて起動するアプリケーションであるとする。残りのapplication#1、application#3は、title#1の開始と同時に自動的に起動されるアプリケーションであるとする。この場合、図１３（ａ）に示すように、アプリケーション管理テーブルにおける各アプリケーションの起動属性を、application#1、application#3は「AutoRun」、application#2は、「Persistent」と設定しておく。この場合、application#1、application#3は、title#1への分岐時において自動的にワークメモリにロードされ、実行されることになる。一方application#2は、起動属性がPersistentなので、「application#3は仮想マシンのワークメモリ上にロードしてよいアプリケーション」であるとの消極的な意味に解される。故に、application#2は、application#1からの呼出があって初めて仮想マシンのワークメモリにロードされ、実行されることになる。以上の生存区間・起動属性により、仮想マシン上で動作し得るアプリケーションの数を4個以下に制限し、総スレッド数を64個以下に制限することが可能なので、アプリケーションの安定動作を保証することができる。
【００４４】
続いてSuspendについて説明する。
Suspendとは、リソースは割り付けられているが、CPUパワーは割り当てられない状態にアプリケーションが置かれることをいう。かかるSuspendは、例えばゲームタイトルの実行中に、サイドパスを経由するという処理の実現に有意義である。図１４（ａ）（ｂ）はSuspendが有意義となる事例を示す図である。図１４（ｂ）に示すように、3つのタイトル(title#1、title#2、title#3)があり、そのうちtitle#1、title#3はゲームアプリを実行するが、途中のtitle#2はサイドパスであり、映像再生を実現するものである。サイドパスでは、映像再生を実現する必要があるため、ゲームの実行を中断させることになる。ゲームアプリでは途中のスコア等が計数されているため、リソースの格納値はtitle#2の前後で維持したい。この場合、title#2の開始時点でゲームアプリをSuspendし、title#3の開始時点でapplication#2をレジュームするというようにアプリケーション管理テーブルを記述する。こうすることでtitle#2においてapplication#2は、リソースは割り付けられているので、リソースの格納値は維持される。しかし、CPUパワーは割り当てられない状態なので仮想マシンによりapplication#2は実行されることはない。これにより、ゲームタイトルの実行中に、サイドパスを実行するという処理が実現される。
【００４５】
図１５は、起動属性がとり得る三態様(Persistent、AutoRun、Suspend)と、直前タイトルにおけるアプリケーション状態の三態様(非起動、起動中、Suspend)とがとりうる組合せを示す図である。直前状態が”非起動”である場合、起動属性が”AutoRun”であるなら、分岐先タイトルにおいてそのアプリケーションは、起動されることになる。
直前状態が”非起動”であり、起動属性が”Persistent”、”Suspend”であるなら、分岐先タイトルにおいてそのアプリケーションは、何ももせず、状態を継続することになる。
【００４６】
直前状態が”起動中”である場合、起動属性が”Persistent”、”AutoRun”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。
起動属性が”Suspend”であるなら、アプリケーションの状態はSuspendされることになる。直前状態が”Suspend”である場合、分岐先タイトルの起動属性が”Suspend”ならSuspendを維持することになる。”Persistent”、”AutoRun”であるなら、分岐先タイトルにおいてそのアプリケーションは、レジュームすることになる。アプリケーション管理テーブルにおいて生存区間及び起動属性を定義することにより、タイトル時間軸の進行に沿って、Javaアプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。以上が記録媒体についての説明である。続いて本発明に係る再生装置について説明する。
【００４７】
図１６は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムLSIと、ドライブ装置という2つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、BD-ROMドライブ１、リードバッファ２、デマルチプレクサ３、ビデオデコーダ４、ビデオプレーン５、P-Graphicsデコーダ９、PresentationGraphicsプレーン１０、合成部１１、フォントゼネレータ１２、I-Graphicsデコーダ１３、スイッチ１４、Interactive Graphicsプレーン１５、合成部１６、HDD１７、リードバッファ１８、デマルチプレクサ１９、オーディオデコーダ２０、シナリオメモリ２１、CPU２２、キーイベント処理部２３、命令ROM２４、スイッチ２５、CLUT部２６、CLUT部２７、PSRセット２８、ローカルメモリ２９から構成される。
【００４８】
BD-ROMドライブ１は、BD-ROMのローディング／イジェクトを行い、BD-ROMに対するアクセスを実行する。
リードバッファ２は、FIFOメモリであり、BD-ROMから読み出されたTSパケットが先入れ先出し式に格納される。
デマルチプレクサ(De-MUX)３は、リードバッファ２からTSパケットを取り出して、このTSパケットを構成するTSパケットをPESパケットに変換する。そして変換により得られたPESパケットのうち、CPU２２から設定されたPIDをもつものをビデオデコーダ４、オーディオデコーダ２０、P-Graphicsデコーダ９、I-Graphicsデコーダ１３のどれかに出力する。
【００４９】
ビデオデコーダ４は、デマルチプレクサ３から出力された複数PESパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込む。
ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ領域である。再生装置に複数のプレーンを設けておき、これらプレーンの格納内容を画素毎に加算して、映像出力を行えば、複数の映像内容を合成させた上で映像出力を行うことができる。ビデオプレーン５における解像度は1920×1080であり、このビデオプレーン５に格納されたピクチャデータは、16ビットのYUV値で表現された画素データにより構成される。
【００５０】
P-Graphicsデコーダ９は、BD-ROM、HDD１７から読み出されたプレゼンテーショングラフィクスストリームをデコードして、非圧縮グラフィクスをPresentationGraphicsプレーン１０に書き込む。グラフィクスストリームのデコードにより、字幕が画面上に現れることになる。
Presentation Graphicsプレーン１０は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。本プレーンにおける解像度は1920×1080であり、PresentationGraphicsプレーン１０中の非圧縮グラフィクスの各画素は8ビットのインデックスカラーで表現される。CLUT(Color Lookup Table)を用いてかかるインデックスカラーを変換することにより、PresentationGraphicsプレーン１０に格納された非圧縮グラフィクスは、表示に供される。
【００５１】
合成部１１は、非圧縮状態のピクチャデータ(i)を、Presentation Graphicsプレーン１０の格納内容と合成する。
フォントゼネレータ１２は、文字フォントを用いてtextSTストリームに含まれるテキストコードをビットマップに展開する。
I-Graphicsデコーダ１３は、BD-ROM又はHDD１７から読み出されたインタラクティブグラフィクスストリームをデコードして、非圧縮グラフィクスをInteractiveGraphicsプレーン１５に書き込む。
【００５２】
スイッチ１４は、フォントゼネレータ１２が生成したフォント列、P-Graphicsデコーダ９のデコードにより得られたグラフィクスの何れかを選択的にPresentationGraphicsプレーン１０に書き込むスイッチである。
Interactive Graphicsプレーン１５は、I-Graphicsデコーダ１３によるデコードで得られた非圧縮グラフィクスが書き込まれる。
【００５３】
合成部１６は、Interactive Graphicsプレーン１０の格納内容と、合成部８の出力である合成画像(非圧縮状態のピクチャデータと、PresentationGraphicsプレーン７の格納内容とを合成したもの)とを合成する。
HDD１７は、ネットワーク等を介してダウンロードされたSubClip、Clip情報、プレイリスト情報が格納される内蔵媒体である。このHDD１７中のプレイリスト情報はBD-ROM及びHDD１７のどちらに存在するClip情報であっても、指定できる点で異なる。この指定にあたって、HDD１７上のプレイリスト情報は、BD-ROM上のファイルをフルパスで指定する必要はない。本HDD１７は、BD-ROMと一体になって、仮想的な1つのドライブ(バーチャルパッケージと呼ばれる)として、再生装置により認識されるからである。故に、PlayItem情報におけるClip_Information_file_name及びSubPlayItem情報のClip_Information_file_nameは、Clip情報の格納したファイルのファイルボデイにあたる5桁の数値を指定することにより、HDD１７、BD-ROM上のAVClipを指定することができる。このHDDの記録内容を読み出し、BD-ROMの記録内容と動的に組み合わせることにより、様々な再生のバリエーションを産み出すことができる。
【００５４】
リードバッファ１８は、FIFOメモリであり、HDD１７から読み出されたTSパケットが先入れ先出し式に格納される。
デマルチプレクサ(De-MUX)１９は、リードバッファ１８からTSパケットを取り出して、TSパケットをPESパケットに変換する。そして変換により得られたPESパケットのうち、所望のstreamPIDをもつものをフォントゼネレータ１２に出力する。
【００５５】
オーディオデコーダ２０は、デマルチプレクサ１９から出力されたPESパケットを復号して、非圧縮形式のオーディオデータを出力する。
シナリオメモリ２１は、カレントのPL情報やカレントのClip情報を格納しておくためのメモリである。カレントPL情報とは、BD-ROMに記録されている複数PL情報のうち、現在処理対象になっているものをいう。カレントClip情報とは、BD-ROMに記録されている複数Clip情報のうち、現在処理対象になっているものをいう。
【００５６】
CPU２２は、命令ROM２４に格納されているソフトウェアを実行して、再生装置全体の制御を実行する。
キーイベント処理部２３は、リモコンや再生装置のフロントパネルに対するキー操作に応じて、その操作を行うキーイベントを出力する。
命令ROM２４は、再生装置の制御を規定するソフトウェアを記憶している。
【００５７】
スイッチ２５は、BD-ROM及びHDD１７から読み出された各種データを、リードバッファ２、リードバッファ１８、シナリオメモリ２１、ローカルメモリ２９のどれかに選択的に投入するスイッチである。
CLUT部２６は、ビデオプレーン５に格納された非圧縮グラフィクスにおけるインデックスカラーを、Y,Cr,Cb値に変換する。
【００５８】
CLUT部２７は、Interactive Graphicsプレーン１５に格納された非圧縮グラフィクスにおけるインデックスカラーを、Y,Cr,Cb値に変換する。
PSRセット２８は、再生装置に内蔵されるレジスタであり、64個のPlayer Status Register(PSR)と、4096個のGeneralPurpose Register（GPR)とからなる。Player Status Registerの設定値(PSR)のうち、PSR4〜PSR8は、現在の再生時点を表現するのに用いられる。
【００５９】
PSR4は、1〜100の値に設定されることで、現在の再生時点が属するタイトルを示し、0に設定されることで、現在の再生時点がトップメニューであることを示す。
PSR5は、1〜999の値に設定されることで、現在の再生時点が属するチャプター番号を示し、0xFFFFに設定されることで、再生装置においてチャプター番号が無効であることを示す。
【００６０】
PSR6は、0〜999の値に設定されることで、現在の再生時点が属するPL(カレントPL)の番号を示す。
PSR7は、0〜255の値に設定されることで、現在の再生時点が属するPlay Item(カレントPlay Item)の番号を示す。
PSR8は、0〜OxFFFFFFFFの値に設定されることで、45KHzの時間精度を用いて現在の再生時点(カレントPTM(PresentationTiMe))を示す。以上のPSR4〜PSR8により、現在の再生時点が特定されることになる。
【００６１】
ローカルメモリ２９は、BD-ROMからの読み出しは低速である故、BD-ROMの記録内容を一時的に格納しておくためのキャッシュメモリである。かかるローカルメモリ２９が存在することにより、BD-Jモードにおけるアプリケーション実行は、効率化されることになる。図１７（ａ）は、BD-ROMに存在しているJavaアーカイブファイルを、ローカルメモリ２９上でどのように識別するかを示す図である。図１７（ａ）の表は、左欄にBD-ROM上のファイル名を、右欄にローカルメモリ２９上のファイル名をそれぞれ示している。これら右欄、左欄を比較すれば、ローカルメモリ２９におけるファイルは、ディレクトリ指定"BDJA"を省いたファイルパスで指定されていることがわかる。
【００６２】
図１７（ｂ）は、図１７（ａ）の応用を示す図である。本応用例は、ヘッダ＋データという形式で、ファイルに格納されているデータを格納するというものである。何をヘッダに用いるかというと、ローカルメモリ２９におけるファイルパスを用いる。図１７（ｂ）に示したように、ローカルメモリ２９ではBD-ROMにおけるファイルパスの一部を省略したものをファイルパスに用いるから、当該ファイルパスをヘッダに格納することで、各データにおけるBD-ROM上の所在を明らかにすることができる。
【００６３】
以上が、本実施形態に係る再生装置のハードウェア構成である。続いて本実施形態に係る再生装置のソフトウェア構成について説明する。
図１８は、ROM２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。本図に示すように、再生装置のレイア構成は、以下のa),b),c),d-1),d-2),e),f)からなる。つまり、
a)物理的なハードウェア階層の上に、
b)AVClipによる再生を制御するPresentation Engine３１、
c)プレイリスト情報及びClip情報に基づく再生制御を行うPlayback Control Engine３２、
という2つの階層があり、
最上位の階層に
e)タイトル間の分岐を実行するモジュールマネージャ３４がある。
【００６４】
これらHDMVモジュール３３、モジュールマネージャ３４の間に、
d-1)Movieオブジェクトの解読・実行主体であるHDMVモジュール３３と、
d-2)BD-Jオブジェクトの解読・実行を行うBD-Jモジュール３５とが同じ階層に置かれている。
BD-Jモジュール３５は、いわゆるJavaプラットフォームであり、ワークメモリ３７を含むJava仮想マシン３８を中核にした構成になっていて、アプリケーションマネージャ３６、EventListner Manager３９、Default Operation Manager４０から構成される。先ず初めに、Presentation Engine３１〜モジュールマネージャ３４について説明する。図１９は、PresentationEngine３１〜モジュールマネージャ３４による処理を模式化した図である。
【００６５】
Presentation Engine３１は、AV再生機能を実行する。再生装置のAV再生機能とは、DVDプレーヤ、CDプレーヤから踏襲した伝統的な機能群であり、再生開始(Play)、再生停止(Stop)、一時停止(PauseOn)、一時停止の解除(Pause Off)、Still機能の解除(still off)、速度指定付きの早送り(Forward Play(speed))、速度指定付きの巻戻し(BackwardPlay(speed))、音声切り換え(Audio Change)、副映像切り換え(Subtitle Change)、アングル切り換え(Angle Change)といった機能である。AV再生機能を実現するべく、PresentationEngine３１は、リードバッファ２上に読み出されたAVClipのうち、所望に時刻にあたる部分のデコードを行うよう、ビデオデコーダ４、P-Graphicsデコーダ９、I-Graphicsデコーダ１３、オーディオデコーダ２０を制御する。所望の時刻としてPSR8(カレントPTM)に示される箇所のデコードを行わせることにより、AVClipにおいて、任意の時点を再生を可能することができる。図中の1は、PresentationEngine３１によるデコード開始を模式化して示す。
【００６６】
再生制御エンジン(Playback Control Engine(PCE))３２は、プレイリストの再生機能(i)、再生装置における状態取得／設定機能(ii)といった諸機能を実行する。PLの再生機能とは、PresentationEngine３１が行うAV再生機能のうち、再生開始や再生停止を、カレントPL情報及びClip情報に従って行わせることをいう。これら機能(i)〜(ii)は、HDMVモジュール３３〜BD-Jモジュール３５からのファンクションコールに応じて実行する。つまり再生制御エンジン３２は、ユーザ操作による指示、レイヤモデルにおける上位層からの指示に応じて、自身の機能を実行する。図１９において、2,3が付された矢印は、Clip情報及びプレイリスト情報に対するPlaybackControl Engine３２の参照を模式的に示す。
【００６７】
HDMVモジュール３３は、MOVIEモードの実行主体であり、モジュールマネージャ３４から分岐先を構成するMovieオブジェクトが通知されれば、分岐先タイトルを構成するMovieオブジェクトをローカルメモリ２９に読み出して、このMovieオブジェクトに記述されたナビゲーションコマンドを解読し、解読結果に基づきPlaybackControl Engine３２に対するファンクションコールを実行する。図１９において▽2,▽3,▽4が付された矢印は、モジュールマネージャ３４からの分岐先Movieオブジェクトの通知(2)、Movieオブジェクトに記述されたナビゲーションコマンドの解読(3)、PlaybackControl Engine３２に対するファンクションコール(4)を、模式的に示している。
【００６８】
モジュールマネージャ３４は、BD-ROMから読み出されたIndex Tableを保持して、分岐制御を行う。この分岐制御は、JumpTitleコマンドをHDMVモジュール３３が実行した場合、又は、タイトルジャンプAPIがBD-Jモジュール３５からコールされた場合、そのジャンプ先となるタイトル番号を受け取って、そのタイトルを構成するMovieオブジェクト又はBD-JオブジェクトをHDMVモジュール３３又はBD-Jモジュール３５に通知するというものである。図中の▽0,▽1,▽2が付された矢印は、JumpTitleコマンドの実行(0)、モジュールマネージャ３４によるIndexTable参照(1)、分岐先Movieオブジェクト(2)の通知を模式的に示している。
【００６９】
以上がPresentation Engine３１〜モジュールマネージャ３４についての説明である。続いてアプリケーションマネージャ３６について、図２０を参照しながら説明する。図２０は、アプリケーションマネージャ３６を示す図である。
アプリケーションマネージャ３６は、アプリケーション管理テーブルを参照したアプリケーションの起動制御、タイトルの正常終了時における制御を実行する。
【００７０】
起動制御とは、モジュールマネージャ３４から分岐先となるBD-Jオブジェクトが通知される度に、そのBD-Jオブジェクトを読み出し、そのBD-Jオブジェクト内のアプリケーション管理テーブルを参照してローカルメモリ２９アクセスを行う。そして現在の再生時点を生存区間とするアプリケーションを構成するxletプログラムを、ワークメモリに読み出すという制御である。図２０における☆1,☆2,☆3は、起動制御における分岐先BD-Jオブジェクトの通知(1)、アプリケーション管理テーブル参照(2)、Java仮想マシン３８に対する起動指示を模式化して示す。この起動指示によりJava仮想マシン３８は、ローカルメモリ２９からワークメモリ３７にxletプログラムを読み出す(☆5)。
【００７１】
タイトルの終了制御には、正常終了時の制御と、異常終了時の制御とがある。正常終了時の制御には、タイトルを構成するアプリケーションによりジャンプタイトルAPIがコールされて、分岐先タイトルへの切り換えを分岐制御の主体(モジュールマネージャ３４)に要求するという制御がある。この終了制御における、モジュールマネージャ３４通知を模式化して示したのが矢印☆6である。ここでタイトルを正常終了するにあたって、タイトルを構成するアプリケーションは、起動されたままであってもよい。何故なら、アプリケーションを終了するか否かは、分岐先タイトルにおいて判断するからである。本実施形態では深く触れないが、アプリケーションマネージャ３６は、BD-ROMからローカルメモリ２９にJavaアーカイブファイルを読み出す(8)との処理を行う。このローカルメモリ２９への読み出しを模式化したのが☆8である。
【００７２】
以上がアプリケーションマネージャ３６についての説明である。続いてワークメモリ３７〜Default Operation Manager４０について、図２１を参照しながら説明する。
ワークメモリ３７は、アプリケーションを構成するxletプログラムが配置されるヒープ領域である。ワークメモリ３７は、本来Java仮想マシン３８内に存在するが、図２１では、作図の便宜上、ワークメモリ３７をJava仮想マシン３８上位層に記述している。ワークメモリ３７上のxletプログラムには、EventListnerや、JMFプレーヤインスタンスが含まれる。
【００７３】
Java仮想マシン３８は、アプリケーションを構成するxletプログラムをワークメモリ３７にロードして、xletプログラムを解読し、解読結果に従った処理を実行する。上述したようにxletプログラムは、JMFプレーヤインスタンス生成を命じるメソッド、このJMFプレーヤインスタンスの実行を命じるメソッドを含むので、これらのメソッドで命じられた処理内容を実現するよう、下位層に対する制御を行う。JMFプレーヤインスタンス生成が命じられば、Java仮想マシン３８は、BD-ROM上のYYYY.MPLSファイルに関連付けられたJMFプレーヤインスタンスを得る。また、JMFプレーヤインスタンスにおけるJMFメソッドの実行が命じられれば、このJMFメソッドをBDミドルウェアに発行して、BD再生装置が対応しているファンクションコールに置き換させる。そして置換後のファンクションコールをPlaybackControl Engine３２に発行する。
【００７４】
Event Listner Manager３９は、ユーザ操作により生じたイベント(キーイベント)を解析し、イベントの振り分けを行う。図中の実線矢印◇1,◇2は、このEventListner Manager３９による振り分けを模式的に示す。START、STOP、SPEED等、xletプログラム内のEvent Listnerに登録されたキーイベントなら、BD-Jオブジェクトにより間接参照されているxletプログラムにかかるイベントを振り分ける。START、STOP、SPEEDは、JMFに対応したイベントであり、xletプログラムのEventListnerには、これらのキーイベントが登録されているので、本キーイベントによりxletプログラムの起動が可能になる。キーイベントがEventListner非登録のキーイベントである場合、本キーイベントをDefault Operation Manager４０に振り分ける。音声切り換え、アングル切り換え等、BD-ROM再生装置において生じるキーイベントには、EventListnerに登録されていない多様なものがあり、これらのキーイベントが生じたとしても、漏れの無い処理を実行するためである。
【００７５】
Default Operation Manager４０は、xletプログラム内のEvent Listnerに登録されてないキーイベントがEventListner Manager３９から振り分けられると、そのEvent Listner非登録イベントに対応するファンクションコールをPlaybackControl Engine３２に対して実行する。このDefault Operation Manager４０によるファンクションコールを模式的に示したのが、図中の矢印◇3である。尚、図２１においてEventListner非登録イベントはEvent Listner Manager３９、Default Operation Manager４０により振り分けられたが、PlaybackControl Engine３２がダイレクトにEvent Listner非登録イベントを受け取り、再生制御を行ってもよい(図中の◇4)。
。
【００７６】
(フローチャートの説明)
以上のアプリケーションマネージャ３６についての説明は、その概要に触れたに過ぎない。アプリケーションマネージャ３６の処理を更に詳しく示したのが図２２、図２３のフローチャートである。以降、これらのフローチャートを参照してアプリケーションマネージャ３６の処理手順についてより詳しく説明する。
【００７７】
図２２は、アプリケーションマネージャ３６による分岐時の制御手順を示す図である。本フローチャートは、ステップＳ２〜ステップＳ５がなす条件を満たすアプリケーション(アプリケーションxという)を、起動又は終了させるという処理である。
ステップＳ２は、分岐元タイトルで非起動だが、分岐先タイトルで生存していて、分岐先タイトルにおける起動属性がAutoRun属性のアプリケーションxが存在するか否かの判定であり、もしあれば、ローカルメモリ２９に対するキャッシュセンスを行う。キャッシュセンスの結果、アプリケーションxがローカルメモリ２９上に有れば(ステップＳ７でYes)、ローカルメモリ２９からワークメモリ３７にアプリケーションxを読み込む(ステップＳ８)。ローカルメモリ２９に無ければ、BD-ROMからローカルメモリ２９にアプリケーションxを読み込んだ上で、ローカルメモリ２９からワークメモリ３７にアプリケーションxを読み込む(ステップＳ９)。
ステップＳ３は、分岐元タイトルで起動中で、分岐先タイトルで非生存のアプリケーションxが存在するかどうかの判定である。もし存在するのなら、アプリケーションxをワークメモリ３７から削除して終了させる(ステップＳ１０)。
ステップＳ４は、分岐元Suspend、分岐先AutoRun又はPersistentのアプリケーションが存在するか否かの判定である。もし存在するなら、アプリケーションxをResumeする(ステップＳ１１)。
【００７８】
ステップＳ５は、分岐元タイトルで起動中で、分岐先Suspendのアプリケーションが存在するか否かの判定である。もし存在すれば、アプリケーションxをSuspendする(ステップＳ１２)。
個々のアプリケーションを終了させるにあたってのアプリケーションマネージャ３６の処理は、図２３に示すものとなる。図２３は、アプリケーション終了処理の処理手順を示すフローチャートである。本図は、終了すべき複数アプリケーションのそれぞれについて、ステップＳ１６〜ステップＳ２０の処理を繰り返すループ処理になっている(ステップＳ１５)。本ループ処理においてアプリケーションマネージャ３６は起動中アプリケーションを終了するようなterminateイベントを発行し(ステップＳ１６)、タイマセットして(ステップＳ１７)、ステップＳ１８〜ステップＳ２０からなるループ処理に移行する。このterminateイベントをEventListnerが受信すれば、対応するxletプログラムは、終了プロセスを起動する。終了プロセスが終了すれば、そのxletプログラムはワークメモリ３７から解放され、終了することになる。
【００７９】
ステップＳ１８〜ステップＳ２０のループ処理の継続中、タイマはカウントダウンを継続する。本ループ処理においてステップＳ１８は、発行先アプリケーションが終了したか否かの判定であり、もし終了していればこのアプリケーションに対する処理を終える。ステップＳ１９は、タイマがタイムアウトしたか否かの判定であリ、タイムアウトすれば、ステップＳ２０において発行先アプリケーションをワークメモリ３７から削除してアプリケーションを強制終了する。
【００８０】
以上のモジュールマネージャ３４の処理を、図２４を参照しながら説明する。
図２４は、アプリケーション終了の過程を模式的に示した図である。本図における第1段目は、アプリケーションマネージャ３６を、第2段目は、3つのアプリケーションを示す。図２４の第2段目、左側のアプリケーションは、terminateイベントを受信して終了プロセスに成功したアプリケーションを示す。図２４の第2段目、中列のアプリケーションは、terminateイベントを受信したが終了プロセスに失敗したアプリケーションを示す。第2段目、右側のアプリケーションは、EventListnerが実装されていないので、terminateイベントを受信することができなかったアプリケーションを示す。
【００８１】
第1段目−第2段目間の矢印ep1,ep2は、アプリケーションマネージャによるterminateイベント発行を模式的に示し、矢印ep3は、終了プロセス起動を模式的に示している。
第3段目は、終了プロセス成功時における状態遷移後の状態であり、このアプリケーションは、自身の終了プロセスにより終了することになる。これらxletプログラムのように、所定の期間内に終了しないアプリケーションがあれば、アプリケーションマネージャ３６は、それらを強制的にワークメモリ３７から取り除く。第4段目は、アプリケーションマネージャ３６による強制終了を示す。かかる第4段目の強制終了を規定するのも、アプリケーションマネージャ３６の1つの使命といえる。
【００８２】
以上のように本実施形態によれば、分岐元タイトルで起動しており、分岐先タイトルで生存していないアプリケーションは、自動的に終了させられるので、条件付き分岐により再生が複雑に進行する場合でも、再生装置におけるリソースの限界を越える数のアプリケーション立ち上げはなされ無い。分岐前後におけるアプリケーション動作を保証することができるので、デジタルストリームを再生させながら、アプリケーションを実行させるようなディスクコンテンツを多く頒布することができる。
【００８３】
(第２実施形態)
第１実施形態においてアプリケーションの生存区間は、タイトル時間軸と一致していたが、第２実施形態は、PL時間軸の一部をアプリケーションの生存区間とすることを提案する。PL時間軸の一部は、チャプターにより表現されるので、チャプターにて開始点、終了点を記述することにより、アプリケーションの生存区間を規定することができる。図２５（ａ）は、PL時間軸上に生存区間を定めたアプリケーション管理テーブルを示す図である。図２５（ａ）においてアプリケーション管理テーブルには、3つのアプリケーションが記述されており、このうちapplication#2は、title#1のChapter#2からChapter#3までが生存区間に指定され、起動属性にAutoRunが規定されている。このためapplication#2は、図２５（ｂ）に示すように、Chapter#2の始点で起動され、Chapter#3の終点で終了することになる。
【００８４】
一方application#3は、title#1のChapter#4からChapter#6までが生存区間に指定されている。このためapplication#3は、図２５（ｂ）に示すように、図２５（ｂ）に示すように、Chapter#4の始点で起動され、Chapter#6の終点で終了することになる。
こうして記述されたアプリケーション管理テーブルに基づき、処理を行うため本実施形態に係るアプリケーションマネージャ３６は、PLmarkにより指示されるチャプター開始点に到達する度に、そのチャプター開始点から生存区間が始まるアプリケーションが存在するか否かを判定し、もし存在すればそのアプリケーションをワークメモリ３７にロードする。
【００８５】
同様に、チャプター開始点に到達する度に、そのチャプターの直前のチャプターで生存区間が終わるアプリケーションが存在するか否かを判定し、もし存在すればそのアプリケーションをワークメモリ３７から解放する。
チャプターという単位でアプリケーションの生存を管理すれば、アプリケーションの生存区間をより細かい精度で指定することができる。しかしディスクコンテンツには、時間軸の逆向がありうることに留意せねばならない。逆行とは、巻戻しにより時間軸を逆向きに進行することである。チャプターの境界でこの逆行と、進行とが繰り返されれば、ワークメモリへのロード、廃棄が何度もなされ、余分な読出負荷が生じる。そこで本実施形態では、アプリケーションの起動時期を、タイトルに入ってPlaybackControl Engine３２による通常再生が開始された瞬間にしている。ここでPLの再生には、通常再生、トリック再生がある。トリック再生とは、早送り、巻戻し、SkipNext,SkipBackがある。かかる、早送り、巻戻し、SkipNext,SkipBackがなされている間、アプリケーション起動を開始せず、通常再生が開始されて初めて、アプリケーションを起動するのである。通常再生開始の瞬間を基準にすることにより、上述したような生存区間前後の行き来があった場合でも、アプリケーションの起動が必要以上に繰り返されることはない。尚、通常再生開始の瞬間を、アプリケーションの起動基準にするとの処理は、生存区間がtitleである場合にも、実行してよい。
【００８６】
以上のように本実施形態によれば、PLより小さい、チャプターの単位でアプリケーションの生存区間を規定することができるので、緻密なアプリケーション制御を実現することができる。
(第２実施形態の変更例)
図２５では、各アプリケーションに優先度が付与されている。この優先度は、0〜255の値をとり、アプリケーション間でリソースの使用が競合等が競合した場合、どちらのアプリケーションを強制的に終了させるか、また、どちらのアプリケーションからリソースを奪うかという処理をアプリケーションマネージャ３６が行うにあたって、判断材料になる。図２５の一例では、application#1の優先度は255,application#2、application#3の優先度は128なので、application#1−application#2の競合時において、アプリケーションマネージャ３６は優先度が低いapplication#2を強制終了するとの処理を行う。
【００８７】
(第３実施形態)
BD-ROMにより供されるディスクコンテンツは、互いに分岐可能な複数タイトルから構成される。各タイトルは、1つ以上のPLと、このPLを用いた制御手順とからなるもの以外に、再生装置に対する制御手順のみからなる非AV系タイトルがある。本実施形態は、この非AV系タイトルについて説明する。
【００８８】
こうした非AV系タイトルのタイトルでは、どのようにタイトル時間軸を定めるのかが問題になる。図２６（ａ）は、PL時間軸から定まるタイトル時間軸を示す。この場合PL時間軸がタイトル時間軸になり、このタイトル時間軸上にアプリケーションの生存区間が定まる。この基準となるPL時間軸がない場合、タイトル時間軸は図２６（ｂ）（ｃ）のように定めるべきである。
【００８９】
図２６（ｂ）は、メインとなるアプリケーションの生存区間から定まるタイトル時間軸を示す。メインアプリとは、タイトルにおいて起動属性がAutoRunに設定され、タイトル開始時に自動起動される唯一のアプリケーションであり、例えばランチャーアプリと呼ばれるものがこれにあたる。ランチャーアプリとは、他のアプリケーションを起動するアプリケーションプログラムである。
【００９０】
この図２６（ｂ）の考え方は、メインアプリが起動している限り、タイトル時間軸は継続していると考え、メインアプリが終了すれば、時間軸を終結させるというものである。図２６（ｃ）は、複数アプリケーションの生存区間から定まるタイトル時間軸を示す図である。タイトルの開始点で起動されるのは1つのアプリケーションであるが、このアプリケーションが他のアプリケーションを呼び出し、更にこのアプリケーションが別のアプリケーションを呼び出すとの処理が繰り返されるというケースがある。この場合、どれかのアプリケーションが起動している限り、タイトル時間軸は継続していると考え、どのアプリケーションも起動していない状態が到来すれば、そこでタイトル時間軸は終結するという考え方である。このように非AV系タイトルのタイトル時間軸を定めれば、AVタイトルであっても、非AV系タイトルであっても、タイトル時間軸の終結と同時に、所定のタイトルに分岐するという処理を画一的に行うことができる。尚非AVタイトルにおけるタイトル時間軸は、AVタイトルと対比する上で、想定した架空の時間軸に過ぎない。故に再生装置は、非AVタイトルにおけるタイトル時間軸上を逆行したり、任意の位置に頭出しすることができない。
【００９１】
以上は本実施形態における記録媒体に対する改良である。続いて本実施形態における再生装置に対する改良について説明する。
上述したような手順でタイトル終了を行うため第３実施形態に係るアプリケーションマネージャ３６は、図２７に示すような処理で処理を行う。図２７は、タイトル再生時におけるアプリケーションマネージャ３６の処理手順を示すフローチャートである。本フローチャートは、タイトル再生中、ステップＳ２１〜ステップＳ２３を繰り返すというループ構造になっている。
【００９２】
ステップＳ２１は、タイトルジャンプAPIが呼び出されたか否かの判定であり、呼び出されれば、ジャンプ先タイトルへの分岐をモジュールマネージャ３４に要求する(ステップＳ２７)。
ステップＳ２２は、タイトル内のアプリケーション呼出を担っているようなメインアプリが存在するか否かの判定であり、もし存在するなら、それの起動の有無を確認する(ステップＳ２５)。起動してなければ、”タイトルの終わり”であると解釈し、モジュールマネージャ３４に終結を通知する(ステップＳ２６)。
【００９３】
ステップＳ２３は、メインアプリがない場合に実行されるステップであり(ステップＳ２２でNo)、どのアプリケーションも起動してない状態かどうかを判定する。もしそうなら、同じく”タイトルの終わり”であると解釈し、モジュールマネージャ３４に終結を通知する(ステップＳ２６)。
以上のように本実施形態によれば、PL再生を伴わないタイトルであっとしても、アプリケーション実行中は分岐せず、アプリケーション実行が終了して初めて分岐するという処理が可能になる。
【００９４】
(第４実施形態)
本実施形態は、DVDと同様のメニュー制御をBD-ROM上で実現する場合の改良に関する。図２８（ａ）は、BD-ROMにより実現されるメニュー階層を示す図である。本図におけるメニュー階層は、TopMenuを最上位に配し、このTopMenuから下位のTitleMenu、SubTitleMenu、AudioMenuを選択できる構造になっている。図中の矢印sw1,2,3は、ボタン選択によるメニュー切り換えを模式的に示す。TopMenuとは、音声選択、字幕選択、タイトル選択の何れを行うかを受け付けるボタン(図中のボタンsn1,sn2,sn3)を配置したメニューである。
【００９５】
TitleMenuとは、映画作品(title)の劇場版を選択するか、ディレクターズカット版を選択するか、ゲーム版を選択するか等、映画作品の選択を受け付けるボタンを配置したメニューである。AudioMenuとは、音声再生を日本語で行うか、英語で行うかを受け付けるボタンを配置したメニュー、SubTitleMenuとは、字幕表示を日本語で行うか、英語で行うかを受け付けるボタンを配置したメニューである。
【００９６】
こうした階層をもったメニューを動作させるためのMOVIEオブジェクトを図２８（ｂ）に示す。図２８（ｂ）においてMovieObject.bdmvには、FirstPlayOBJ、TopMenu OBJ、AudioMenu OBJ、SubTitleMenu OBJが格納されている。
FirstPlayオブジェクト(FirstPlay OBJ)は、再生装置へのBD-ROMのローディング時に自動的に実行される動的シナリオである。
【００９７】
TopMenuオブジェクト(TopMenu OBJ)は、TopMenuの挙動を制御する動的シナリオである。ユーザがメニューコールを要求した際、呼び出されるのはこのTopMenuオブジェクトである。TopMenuオブジェクトは、ユーザからの操作に応じてTopMenu中のボタンの状態を変えるものや、ボタンに対する確定操作に応じて分岐を行う分岐コマンドを含む。この分岐コマンドは、TopMenuからTitleMenu、TopMenuからSubTitleMenu、TopMenuからAudioMenuというメニュー切り換えを実現するものである。
【００９８】
AudioMenuオブジェクト(AudioMenu OBJ)は、AudioMenuの挙動を制御する動的シナリオであり、ユーザからの操作に応じてAudioMenu中のボタンの状態を変えるコマンドや、ボタンに対する確定操作に応じて音声設定を更新するコマンドを含む。
SubTitleMenuオブジェクト(SubTitleMenu OBJ)は、SubTitleMenuの挙動を制御する動的なシナリオであり、ユーザからの操作に応じてSubTitleMenu中のボタンの状態を変えるコマンドや、ボタンに対する確定操作に応じて字幕設定用のPSRを更新するコマンドを含む。
【００９９】
TitleMenuオブジェクト(TitleMenu OBJ)は、TitleMenuの挙動を制御する動的シナリオであり、TitleMenu中のボタンの状態を変えるものや、ボタンに対する確定操作に応じて分岐を行う分岐コマンドをふくむ。
これらのメニュー用MOVIEオブジェクトにより、DVDで実現されているようなメニューの挙動を実現することができる。以上がメニュー制御に関連するMOVIEオブジェクトである。
【０１００】
図２９は、Index Tableと、Index Tableから各Movieオブジェクトへの分岐とを模式化した図である。本図では左側にIndex Tableの内部構成を示している。本実施形態におけるIndexTableには、FirstPLayINDEX、TopMenuINDEX, Audio MenuINDEX、Subtitle MenuINDEX、titleMenuINDEX、title#1〜#mINDEX、title#m+1〜#nINDEX、title#0INDEXを含む。図中の矢印bc1,2は、IndexTableからFirstPlayOBJへの分岐と,FirstPlayOBJからTopMenuへの分岐とを模式的に示し、矢印bc3,4,5は、TopMenuからTitleMenu、SubTitleMenu、AudioMenuへの分岐を模式的に示している。矢印bc6,7,8は、TitleMenuから各Movieオブジェクトへの分岐を模式的に示している。
【０１０１】
FirstPLayINDEX、TopMenuINDEX, Audio MenuINDEX、Subtitle MenuINDEX、titleMenuINDEXは、それぞれ、FirstPLayOBJ、TopMenuOBJ, Audio MenuOBJ、Subtitle MenuOBJ、titleMenuOBJについてのIndexであり、これらの識別子が記述される。
title#1〜#mINDEXは、BD-ROMにおいて1からm番目にエントリーされているtitleについてのIndexであり、これら1からmまでのtitle番号の選択時において分岐先となるMOVIEオブジェクトの識別子(ID)が記述される。
【０１０２】
title#m+1〜#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に格納されている。
【０１０３】
図３０（ａ）は、図２９のようにIndex Tableが記述された場合における分岐を示す。Index Tableがこのように記述されているので、ラベルtitle#1〜title#mを分岐先とした分岐コマンドの実行時には、title#1Index〜title#mIndexからMovieオブジェクト#1〜#mの識別子が取り出される。ラベルtitle#m+1〜title#nを分岐とした分岐コマンドの実行時には、title#m+1Index〜title#nIndexからBD-Jオブジェクト#m+1〜#nの識別子が取り出される。BD-Jオブジェクト#m+1〜#nの識別子は、ファイル名を表す5桁の数値であるので、『00001.BD-J,00002.BD-J,00003.BD-J・・・』が取り出され、そのファイル名の動的シナリオがメモリに読み出されて、実行されることになる。これがIndexTableを用いた分岐処理である。
【０１０４】
図３０（ｂ）は、BD-Jオブジェクト実行時の強制終了時における分岐を示す図である。強制終了時における分岐では、title#0Indexから識別子が取り出されて、その識別子の動的シナリオが再生装置により実行される。この識別子が、トップメニュータイトルの識別子なら、アプリケーション強制終了時には、自動的にトップメニューOBJが選択されることになる。

以上は本実施形態における記録媒体に対する改良である。続いて本実施形態における再生装置に対する改良について説明する。上述した記録媒体の改良に対応するため、再生装置内のモジュールマネージャ３４は図３１に示すような処理手順で処理を行う。図３１は、モジュールマネージャ３４の処理手順を示すフローチャートである。本フローチャートは、ステップＳ３１、ステップＳ３２からなるループ処理を構成しており、ステップＳ３１又はステップＳ３２のどちらかがYesになった際、対応する処理を実行するものである。
【０１０５】
ステップＳ３１は、タイトルジャンプAPIの呼び出しがあったか否かの判定である。もしタイトルジャンプAPIの呼び出しがあれば、分岐先ラベルであるタイトル番号jを取得し(ステップＳ３３)、IndexTableにおけるタイトル番号jのIndexから、IDjを取り出して(ステップＳ３４)、IDjのMovieオブジェクト又はBD-Jオブジェクトを、HDMVモジュール３３又はBD-Jモジュール３５に実行させる(ステップＳ３５)。
【０１０６】
ステップＳ３２は、タイトル終了がアプリケーションマネージャ３６から通知されたか否かの判定であり、もし通知されれば(ステップＳ３２でYes)、トップメニュータイトルを構成するトップメニューOBJをHDMVモジュール３３又はモジュールマネージャ３４に実行させる(ステップＳ３６)。
以上のアプリケーションマネージャ３６によるアプリケーション強制終了の動作例を、図３２を参照しながら説明する。ここで再生すべきタイトルは、落下するタイル片を積み重ねるというゲームアプリを含む非AV系タイトルである。図３２の下段は、アプリケーションの生存区間からなるタイトル時間軸を示し、上段は、タイトル時間軸において表示される画像を示す。非AV系タイトルがゲームアプリである場合、このゲームアプリの生存区間において、図３２の上段左側のように、ゲームアプリの一画面が表示される。ゲームアプリにバグがあり、異常終了すると、アプリケーションマネージャ３６は図２３のフローチャートに従ってゲームアプリを強制終了させ、タイトルの終了をモジュールマネージャ３４に通知する。タイトル終了が通知されると、モジュールマネージャ３４はトップメニュータイトルに分岐する。そうすると、図３２の上段右側に示すような画像が表示され、ユーザの操作待ちになる。
【０１０７】

以上のように本実施形態によれば、プログラムが含むが、デジタルストリームは含まないような非AV系タイトルの終了時においても、トップメニュータイトルに分岐するという制御が可能になる。これによりアプリケーションプログラムがエラー終了したとしても、ブラックアウトやハングアップの発生を回避することができる。
【０１０８】
(第５実施形態)
BD-Jモードにおいて、PL再生との同期をどのように実現するかという改良に関する。図８（ｂ）の一例においてJMFプレーヤインスタンスの再生を命じるJMFプレーヤインスタンス(A.play;)をJava仮想マシン３８が解読した場合、Java仮想マシン３８はPL再生APIをコールして、コール直後に”サクセス”を示す応答をアプリケーションに返す。
【０１０９】
Playback Control Engine３２は、PL再生APIがコールされれば、PL情報に基づく処理手順を実行する。PLが2時間という再生時間を有するなら、この2時間の間、上述した処理は継続することになる。ここで問題になるのは、Java仮想マシン３８がサクセス応答を返す時間と、PlaybackControl Engine３２が実際に処理を終える時間とのギャップである。Java仮想マシン３８は、イベントドリブンの処理主体であるためコール直後に再生成功か、再生失敗かを示す応答を返すが、PlaybackControl Engine３２による実際の処理終了は2時間経過後であるので、サクセス応答をアプリケーションに返す時間を基準にしたのでは、2時間経過後にあたる処理終結を感知しえない。PL再生において早送り、巻戻し、Skipが行われると、この2時間という再生期間は2時間前後に変動することになり、処理終結の感知は更に困難になる。
【０１１０】
Playback Control Engine３２は、アプリケーションとスタンドアローンで動作するため、第３実施形態のような終了判定では、PL再生の終了をタイトル終了と解釈することができない。そこで本実施形態では、アプリケーションが終了してようがいまいが、ワークメモリ３７にJMFプレーヤインスタンスがある限り、つまり、PresentationEngine３１の制御権をBD-Jモジュール３５が掌握している間、Playback Control Engine３２から再生終結イベントを待つ。そして再生終結イベントがあれば、タイトルが終了したと解釈して、次のタイトルへの分岐を行うようモジュールマネージャ３４に通知する。こうすることにより、PlaybackControl Engine３２がPL再生を終結した時点を、タイトルの終端とすることができる。
【０１１１】
以降図３３〜図３７のフローチャートを参照して、Playback Control Engine３２による具体的な制御手順を説明する。
図３３は、Playback Control Engine３２によるPL再生手順を示すフローチャートである。この再生手順は、PresentationEngine３１に対する制御(ステップＳ４６)と、BD-ROMドライブ１又はHDD１７に対する制御(ステップＳ４８)とを主に含む。本フローチャートにおいて処理対象たるPlayItemをPlayItem#xとする。本フローチャートは、カレントPL情報(.mpls)の読み込みを行い(ステップＳ４１)、その後、ステップＳ４２〜ステップＳ５０の処理を実行するというものである。ここでステップＳ４２〜ステップＳ５０は、ステップＳ４９がYesになるまで、カレントPL情報を構成するそれぞれのPI情報について、ステップＳ４３〜ステップＳ５０の処理を繰り返すというループ処理を構成している。このループ処理において処理対象となるPlayItemを、PlayItem#x(PI#x)とよぶ。このPlayItem#xは、カレントPLの先頭のPlayItemに設定されることにより、初期化される(ステップＳ４２)。上述したループ処理の終了要件は、このPlayItem#xがカレントPLの最後のPlayItemになることであり(ステップＳ４９)、もし最後のPlayItemでなければ、カレントPLにおける次のPlayItemがPlayItem#xに設定される(ステップＳ５０)。
【０１１２】
ループ処理において繰り返し実行されるステップＳ４３〜ステップＳ５０は、PlayItem#xのClip_information_file_nameで指定されるClip情報をシナリオメモリ２１に読み込み(ステップＳ４３)、PlayItem#xのIn_timeを、カレントClip情報のEPmapを用いて、Iピクチャアドレスuに変換し(ステップＳ４４)、PlayItem#xのOut_timeを、カレントClip情報のEP_mapを用いて、Iピクチャアドレスvに変換して(ステップＳ４５)、これらの変換で得られたアドレスvの次のIピクチャを求めて、そのアドレスの1つ手前をアドレスwに設定し(ステップＳ４７)、そうして算出されたアドレスwを用いて、IピクチャアドレスuからアドレスwまでのTSパケットの読み出しをBD-ROMドライブ１又はHDD１７に命じるというものである(ステップＳ４８)。
【０１１３】
一方、Presentation Engine３１に対しては、カレントPLMarkのmark_time_stampからPlayItem#xのOut_timeまでの出力を命じる(ステップＳ４６)。以上のステップＳ４５〜ステップＳ４８により、AVClipにおいて、PlayItem#xにより指示されている部分の再生がなされることになる
その後、PlayItem#xがカレントPLの最後のPIであるかの判定がなされる(ステップＳ４９)。
【０１１４】
PlayItem#xがカレントPLの最後のPIでなければ、カレントPLにおける次のPlayItemを、PlayItem#xに設定して(ステップＳ５０)、ステップＳ４３に戻る。以上のステップＳ４３〜ステップＳ５０を繰り返することにより、PLを構成するPIは順次再生されることになる。
図３４は、アングル切り換え手順及びSkipBack,SkipNextの手順を示すフローチャートである。本フローチャートは、図３３の処理手順と並行してなされるものであり、ステップＳ５１〜Ｓ５２からなるループ処理を繰り返すというものである。本ループにおけるステップＳ５１は、アングル切り換えを要求するAPIが、Java仮想マシン３８からコールされたか否かの判定であり、アングル切り換えAPIのコールがあれば、カレントClip情報を切り換えるという操作を実行する。
【０１１５】
図３４のステップＳ５５は、判定ステップであり、PlayItem#xのis_multi_anglesがオンであるか否かの判定を行う。is_multi_anglesとは、PlayItem#xがマルチアングルに対応しているか否かを示すフラグであり、もしステップＳ５５がNoであるならステップＳ５３に移行する。ステップＳ５５がYesであるなら、ステップＳ５６〜ステップＳ５９を実行する。ステップＳ５６〜ステップＳ５９は、切り換え後のアングル番号を変数yに代入して(ステップＳ５６)、PlayItem#xにおけるy番目のClip_information_file_nameで指定されているClip情報をシナリオメモリ２１に読み出し(ステップＳ５７)、カレントPTMを、カレントClip情報のEP_mapを用いてIピクチャアドレスuに変換し(ステップＳ５８)、PlayItem#xのOut_timeを、カレントClip情報のEP_mapを用いてIピクチャアドレスvに変換する(ステップＳ５９)というものである。こうしてIピクチャアドレスu,vを変化した後、ステップＳ４６に移行する。ステップＳ４６への移行により、別のAVClipからTSパケットが読み出されるので、映像内容が切り換わることになる。
【０１１６】
一方、図３４のループにおけるステップＳ５２は、SkipBack/SkipNextを意味するAPIがJava仮想マシン３８からコールされたか否かの判定であり、もしコールされれば、図３５のフローチャートの処理手順を実行する。図３５は、SkipBack,SkipNextAPIがコールされた際の処理手順を示すフローチャートである。SkipBack,SkipNextを実行するにあたっての処理手順は多種多様なものである。ここで説明するのはあくまでも一例に過ぎないことに留意されたい。
【０１１７】
ステップＳ６１は、PSRで示されるカレントPI番号、及び、カレントPTMを変換することにより、カレントMark情報を得る。ステップＳ６２は、押下されたのがSkipNextキーであるか、SkipBackキーであるかの判定であり、SkipNextキーであるならステップＳ６３において方向フラグを+1に設定し、SkipBackキーであるならステップＳ６４において方向フラグを-1に設定する。
【０１１８】
ステップＳ６５は、カレントPLMarkの番号に方向フラグの値を足した番号を、カレントPLMarkの番号として設定する。ここでSkipNextキーであるなら方向フラグは+1に設定されているのでカレントPLMarkはインクリメントされることになる。SkipBackキーであるなら方向フラグは-1に設定されているので、カレントPLMarkはデクリメントされることになる。
【０１１９】
ステップＳ６６では、カレントPLMarkのref_to_PlayItem_Idに記述されているPIを、PlayItem#xに設定し、ステップＳ６７では、PlayItem#xのClip_information_file_nameで指定されるClip情報を読み込む。ステップＳ６８では、カレントClip情報のEP_mapを用いて、カレントPLMarkのmark_time_stampを、Iピクチャアドレスuに変換する。一方ステップＳ６９では、PlayItem#xのOut_timeを,カレントClip情報のEP_mapを用いて,Iピクチャアドレスvに変換する。ステップＳ７０は、カレントPLMarkのmark_time_stampからPlayItem#xのOut_timeまでの出力をPresentationEngine３１に命じた上で、図３３のステップＳ４７に移行する。こうしてIピクチャアドレスu,vを変化して、別の部分の再生を命じた上でステップＳ４７への移行するので、別のAVClipからTSパケットが読み出されることになり、映像内容が切り換えが実現する。
【０１２０】
図３６は、Presentation Engine３１による処理手順の詳細を示すフローチャートである。本フローチャートは、IピクチャのPTSをカレントPTMに設定した後で(ステップＳ７１)、ステップＳ７２〜ステップＳ７７からなるループ処理を実行するものである。
続いてステップＳ７２〜ステップＳ７７におけるループ処理について説明する。このループ処理は、カレントPTMにあたるピクチャ、オーディオの再生出力と、カレントPTMの更新とを繰り返すものである。本ループ処理におけるステップＳ７６は、ループ処理の終了要件を規定している。つまりステップＳ７６は、カレントPTMがPI#xのOut_timeであることをループ処理の終了要件にしている。
【０１２１】
ステップＳ７３は、早送りAPI、又は、早戻しAPIがJava仮想マシン３８からコールされたか否かの判定である。もしコールされれば、ステップＳ７８において早送りか早戻しかの判定を行い、早送りであるなら、次のIピクチャのPTSをカレントPTMに設定する(ステップＳ７９)。このようにカレントPTMを、次のIピクチャのPTSに設定することで、1秒飛びにAVClipを再生してゆくことができる。これにより、2倍速等でAVClipは順方向に早く再生されることになる。早戻しであるなら、カレントPTMがPlayItem#xのOut_timeに到達したかを判定する(ステップＳ８０)。もし到達してないのなら、1つ前のIピクチャのPTSをカレントPTMに設定する(ステップＳ８１)。このように読出先アドレスAを、1つ前のIピクチャに設定することで、AVClipを後方向に1秒飛びに再生してゆくことができる。これにより、2倍速等でAVClipは、逆方向に再生されることになる。尚、早送り、巻戻しを実行するにあたっての処理手順は多種多様なものである。ここで説明するのはあくまでも一例に過ぎないことに留意されたい。
【０１２２】
ステップＳ７４は、メニューコールAPIがコールされたか否かの判定であり、もしコールされれば、現在の再生処理をサスペンドして(ステップＳ８２)、メニュー処理用のメニュープログラムを実行する(ステップＳ８３)。以上の処理により、メニューメニューコールがなされた場合は、再生処理を中断した上で、メニュー表示のための処理が実行されることになる。
【０１２３】
ステップＳ７５は、sync_PlayItem_idにより、PlayItem#xを指定したSubPlayItem#yが存在するか否かの判定であり、もし存在すれば、図３７のフローチャートに移行する。図３７は、SubPlayItemの再生手順を示すフローチャートである。本フローチャートでは、先ずステップＳ８６において、カレントPTMはSubPlayItem#yのsync_start_PTS_of_playItemであるか否かを判定する。もしそうであれば、ステップＳ９３においてSubPlayItem#yに基づく再生処理を行うようPlaybackControl Engine３２に通知する。
【０１２４】
図３７のステップＳ８７〜ステップＳ９２は、SubPlayItem#yに基づく再生処理を示すフローチャートである。
ステップＳ８７では、SubPlayItem#yのClip_information_file_nameで指定されるClip情報を読み込む。ステップＳ８８では、カレントClip情報のEP_mapを用いて、SubPlayItem#yのIn_timeを、アドレスαに変換する。一方ステップＳ８９では、SubPlayItem#yのOut_timeを,カレントClip情報のEP_mapを用いて、アドレスβに変換する。ステップＳ９０は、SubPlayItem#yのIn_timeからSubPlayItem#yのOut_timeまでの出力をデコーダに命じる。これらの変換で得られたアドレスβの次のIピクチャを求めて、そのアドレスの1つ手前をアドレスγに設定し(ステップＳ９１)、そうして算出されたアドレスγを用いて、SubClip#zにおけるアドレスαからアドレスγまでのTSパケットの読み出しをBD-ROMドライブ１又はHDD１７に命じるというものである(ステップＳ９２)。
【０１２５】
また図３３に戻ってPlayback Control Engine３２の処理の説明の続きを行う。ステップＳ５３はPresentation Engine３１による再生制御が完了したかの判定であり、最後のPlayItem#xに対して、図３６のフローチャートの処理が行われている限り、ステップＳ５３がNoになる。図３６のフローチャートの処理が終了して初めて、ステップＳ５３はYesになりステップＳ５４に移行する。ステップＳ５４は、Java仮想マシン３８への再生終結イベントの出力であり、この出力により、2時間という再生時間の経過をJava仮想マシン３８は知ることができる。
【０１２６】
以上が本実施形態におけるPlayback Control Engine３２、Presentation Engine３１の処理である。続いて本実施形態におけるアプリケーションマネージャ３６処理手順について説明する。図３８は、第５実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。
図３８のフローチャートは、図２７のフローチャートを改良したものである。その改良点は、ステップＳ２１−ステップＳ２２間にステップＳ２４が追加され、このステップＳ２４がYesになった際、実行されるステップＳ１０１が存在する点である。
【０１２７】
ステップＳ２４は、JMFプレーヤインスタンスがワークメモリ３７に存在するか否かの判定であり、もし存在しなければステップＳ２２に移行する。存在すれば、ステップＳ１０１に移行する。ステップＳ１０１は、PlaybackControl Engine３２から再生終結イベントが出力されたか否かの判定であり、もし出力されれば、ワークメモリ中のJavaプレーヤインスタンスを消滅させた上で(ステップＳ１０２)、タイトル終了をモジュールマネージャ３４に通知する(ステップＳ２６)。通知されねば、ステップＳ２１〜ステップＳ２４からなるループ処理を繰り返す。
【０１２８】
以上のフローチャートにおいて、ワークメモリ３７にJMFプレーヤインスタンスが存在する限り(ステップＳ２４でYes)、ステップＳ２２、ステップＳ２３はスキップされる。そのため、たとえ全てのアプリケーションが終了したとしてもタイトルは継続中と解釈される。
以上のように本実施形態によれば、2時間という再生時間の経過時点をアプリケーションマネージャ３６は把握することができるので、PL再生の終了条件にメニューを表示して、このメニューに対する操作に応じて他のタイトルに分岐するという制御を実現することができる。
【０１２９】
(第６実施形態)
第６実施形態は、BD-Jオブジェクトにデータ管理テーブルを設ける改良に関する。
データ管理テーブル(DMT)は、そのタイトル時間軸においてローカルメモリ２９上にロードすべきJavaアーカイブファイルを、読込属性と、読込優先度とに対応づけて示すテーブルである。”ローカルメモリ２９における生存”とは、そのアプリケーションを構成するJavaアーカイブファイルがローカルメモリ２９から読み出され、Java仮想マシン３８内のワークメモリ３７への転送が可能になっている状態をいう。図３９は、データ管理テーブルの一例を示す図である。本図に示すようにデータ管理テーブルは、アプリケーションの『生存区間』と、その生存区間をもったアプリケーションを識別する『applicationID』と、そのアプリケーションの『読込属性』と、『読込優先度』とを示す。
【０１３０】
上述したようにアプリケーション管理テーブルには、生存区間という概念があり、データ管理テーブルにも同じ生存区間という概念がある。アプリケーション管理テーブルと同じ概念を、データ管理テーブルに設けておくというのは一見無駄のように思えるがこれには意図がある。
図４０は、BD-Jオブジェクトが想定している実行モデルを示す図である。本図における実行モデルは、BD-ROM、ローカルメモリ２９、Java仮想マシン３８からなり、BD-ROM、ローカルメモリ２９、ワークメモリ３７という三者の関係を示す。矢印my1は、BD-ROM→ローカルメモリ２９間の読み込みを示し、矢印my2は、ローカルメモリ２９→ワークメモリ３７間の読み込みを示す。矢印上の注釈は、これらの読み込みが、どのようなタイミングでなされるかを示す。注釈によると、BD-ROM→ローカルメモリ２９間の読み込みは、いわゆる”先読み”であり、アプリケーションが必要となる以前の時点に行われねばならない。
【０１３１】
また注釈によると、ローカルメモリ２９→ワークメモリ３７間の読み込みは、アプリケーションが必要になった際になされることがわかる。”必要になった際”とは、アプリケーションの生存区間が到来した時点(1)、アプリケーションの呼出が他のアプリケーション又はアプリケーションマネージャ３６から指示された時点(2)を意味する。
矢印my3は、ワークメモリ３７におけるアプリケーションの占有領域の解放を示し、矢印my4は、ローカルメモリ２９におけるアプリケーションの占有領域の解放を示す。矢印上の注釈は、これらの読み込みが、どのようなタイミングでなされるかを示す。注釈によると、ワークメモリ３７上の解放は、アプリケーション終了と同時になされることがわかる。一方ローカルメモリ２９上の解放は、Java仮想マシン３８にとって必要でなくなった時点でなされる。この必要でなくなった時点とは、”終了時点”ではない。”終了した上、再起動の可能性もない時点”であること、つまり該当するtitleが終了した時点を意味する。上述した読込・解放のうち、ワークメモリ３７における解放時点は、アプリケーション管理テーブルにおける生存区間から判明する。しかし”アプリケーションが必要となる以前の時点”、”終了した上、再起動の可能性もない時点”については、規定し得ない。そこで、オーサリング段階において、かかる時点をディスクコンテンツ全体の時間軸上で規定しておくため、本実施形態では各アプリケーションが生存している区間を、アプリケーション管理テーブルとは別に、データ管理テーブルに記述するようにしている。つまり”アプリケーションが必要となる以前の時点”をデータ管理テーブルにおける生存区間の始点と定義し、”終了した上、再起動の可能性もない時点”をデータ管理テーブルの終点と定義することにより、上述したローカルメモリ２９上の格納内容の遷移をオーサリング時に規定しておくことができる。これがデータ管理テーブルの記述意義である。
【０１３２】
データ管理テーブルによるローカルメモリ２９生存区間の記述について説明する。ここで制作しようとするディスクコンテンツは3つのタイトル(title#1、title#2、title#3)からなり、これらタイトルの時間軸において、図４１（ｂ）に示すようなタイミングで、ローカルメモリ２９を使用したいと考える。この場合、title#1時間軸の開始点においてapplication#1、application#2を構成するJavaアーカイブファイルをローカルメモリ２９に読み込み、title#1時間軸の継続中、application#1、application#2をローカルメモリ２９に常駐させておく。そしてtitle#2時間軸の始点で、application#1を構成するJavaアーカイブファイルをローカルメモリ２９から解放して、代わりにapplication#3を構成するJavaアーカイブファイルをローカルメモリ２９に読み込んで、常駐させるというものである(以降、アプリケーションを構成するJavaアーカイブファイルは、アプリケーションと同義に扱う。)。この場合のデータ管理テーブルの記述は、図４１（ａ）の通りであり、アプリケーションのapplicationIDを、その生存区間に対応づけて記述することで、ローカルメモリ２９に常駐すべきアプリケーションを表現する。図４１（ａ）では、application#1のapplicationIDがtitle#1と対応づけられて記述されており、application#2のapplicationIDはtitle#1、title#2と対応づけられ、application#3のapplicationIDはtitle#3と対応づけられて記述されていることがわかる。こうすることで、ローカルメモリ２９占有の時間的遷移がオーサリング担当者により規定されることになる。
【０１３３】
データ管理テーブル、アプリケーション管理テーブルの組合せとしては、アプリケーション管理テーブルに規定する生存区間は、細かい再生単位にし、データ管理テーブルに規定する生存区間は、大まかな再生単位にすることが望ましい。大まかな再生単位には、タイトル、PLといった非シームレスな再生単位が望ましい。一方、細かい再生単位としては、PL内のチャプターというようにシームレスな再生単位が望ましい。アプリケーションの生存区間をタイトル毎、PL毎に定めれば、アプリケーションはローカルメモリ２９上に存在するので、そのタイトルの再生中においてアプリケーションは何時でも取り出せる状態になる。そうであれば、アプリケーションの生存区間を細かく定めたとしても、アプリケーションを即座に、仮想マシン上のワークメモリに読み出すことができるので、アプリケーションの起動・終了が頻繁になされたとしても、スムーズなアプリケーション実行を実現することができる。
【０１３４】
次に、読込属性について説明する。
図２においてJavaアーカイブファイルは、AVClipとは別の記録領域に記録されることを前提にしていた。しかしこれは一例に過ぎない。Javaアーカイブファイルは、BD-ROMにおいてAVClipが占める記録領域に埋め込まれることがある。この埋め込みの態様には、カルーセル化、インターリーブユニット化という2種類がある。
【０１３５】
ここで”カルーセル化”とは、対話的な放送の実現のために同一内容を繰り返しするという放送方式に変換することである。BD-ROMは、放送されたデータを格納するものではないが、本実施形態では、カルーセルの放送形式に倣ってJAVAアーカイブファイルを格納するようにしている。図４２は、カルーセル化によるJavaアーカイブファイル埋め込みを示す図である。第1段目は、AVClip中に埋め込むJavaアーカイブファイルであり、第2段目は、セクション化を示す。第3段目は、TSパケット化、第4段目は、AVClipを構成するTSパケット列を示す。こうしてセクション化、TSパケット化されたデータ(図中の”D”)が、AVClipに埋め込まれるのである。カルーセルによりAVClipに多重化されたJavaアーカイブファイルは、読み出すにあたって、低帯域で読み出されることになる。この低帯域での読み出しは、概して2〜3分というように長期間を要するため、再生装置はJavaアーカイブファイルを2〜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アーカイブファイルが埋め込まれた部分に、現在の再生時点が到達した際、再生装置のローカルメモリ２９にロードされる。Javaアーカイブファイルの記録態様には、図２に示すものの他に、図４２、図４３（ａ）に示すものがあるので、読込属性は、図４３（ｂ）に示すように、設定されうる。図４３（ｂ）に示すように、読込属性は、タイトル再生に先立ち、ローカルメモリ２９に読み込まれる旨を示す”Preload”と、タイトル再生中に、カルーセル化方式で読み込まれる旨を示す”Load.Carousel”と、タイトル再生中に、インターリーブ化方式で読み込まれる旨を示す”Load.InterLeave”とがある。読込属性には、カルーセル化されているか、インターリーブ化されているかが添え字で表現されているが、これを省略してもよい。
【０１３８】
データ管理テーブルにおける生存区間の具体的な記述例について、図４４を参照しながら説明する。図４４（ａ）は、データ管理テーブルの一例を示す図である。図４４（ｂ）は、かかるデータ管理テーブルの割り当てによるローカルメモリ２９の格納内容の変遷を示す図である。本図は、縦軸方向にローカルメモリ２９における占有領域を示し、横軸を、1つのタイトル内のPL時間軸としている。データ管理テーブルにおいてapplication#1は、1つのタイトル内のPL時間軸全体を生存区間とするよう記述されているので、このタイトルのChapter#1〜Chapter#5においてローカルメモリ２９内の領域を占有することになる。データ管理テーブルにおいてapplication#2は、タイトル内のPL#1におけるChapter#1〜Chapter#2を生存区間とするよう記述されているので、このタイトルのChapter#1〜Chapter#2においてローカルメモリ２９内の領域を占有することになる。データ管理テーブルにおいてapplication#3は、タイトル内のPL#1におけるChapter#4〜Chapter#5を生存区間とするよう記述されているので、このタイトルのChapter#4〜Chapter#5においてローカルメモリ２９内の領域を占有することになる。以上で、データ管理テーブルにおける生存区間についての説明を終える。

続いて読込優先度について説明する。読込優先度とは、ローカルメモリ２９への読み込みに対する優劣を決める優先度である。読込優先度には複数の値がある。2段階の優劣を設けたい場合、Mandatoryを示す値、optionalを示す値を読込優先度に設定する。この場合、Mandatoryは高い読込優先度を意味し、optionalは、低い読込優先度を意味する。3段階の優劣を設けたい場合、Mandatoryを示す値、optional:high、optional:lowを示す値を読込優先度に設定する。Mandatoryは、最も高い読込優先度を示し、optional:highは、中程度の読込優先度、optional:lowは、最も低い読込優先度を示す。データ管理テーブルにおける読込優先度の具体的な記述例について、図４５（ａ）（ｂ）を参照しながら説明する。この具体例で、想定しているローカルメモリ２９のメモリ規模は、図４５（ａ）に示すようなものである。図４５（ａ）は、新旧再生装置におけるローカルメモリ２９のメモリ規模を対比して示す図である。矢印mk1は旧再生装置におけるメモリ規模を、矢印mk2は新再生装置におけるメモリ規模をそれぞれ示す。この矢印の対比から、新再生装置におけるローカルメモリ２９のメモリ規模は、旧再生装置のそれと比較して、三倍以上である状態を想定している。このようにメモリ規模にバラツキがある場合、アプリケーションは、図４５に示すような2つのグループに分類される。1つ目は、どのようなメモリ規模であっても読み込むんでおくべきアプリケーション(#1,#2)である。2つ目は、旧再生装置での読み込みは望まないが、新再生装置での読み込みは希望するアプリケーション(#3,#4)である。読み込もうとするアプリケーションが、これら2つのグループに分類されれば、前者に帰属するアプリケーションに、読込優先度=Mandatoryを設定し、後者に属するアプリケーションに、読込優先度=Optionalを設定する。図４５（ｂ）は、読込優先度が設定されたデータ管理テーブルの一例を示す図である。データ管理テーブルをこのように設定した上で、application#1〜application#4をBD-ROMに記録すれば、あらゆるメモリ規模の再生装置での再生を保証しつつも、メモリ規模が大きい再生装置では、より大きなサイズのデータを利用したアプリケーションを再生装置に再生させることができる。
【０１３９】
以上は本実施形態における記録媒体に対する改良である。続いて本実施形態における再生装置に対する改良について説明する。上述した記録媒体の改良に対応するため、アプリケーションマネージャ３６は図４６に示すような処理手順で処理を行う。
図４６は、アプリケーションマネージャ３６によるプリロード制御の処理手順を示す図である。本フローチャートは、再生すべきタイトルにおけるデータ管理テーブルを読み込み(ステップＳ１１１)、データ管理テーブルにおいて最も高い読込優先度をもちつつ、applicationIDが最も小さいアプリケーションをアプリケーションiにした上で(ステップＳ１１２)、ステップＳ１１３、ステップＳ１１４の判定を経た上で、アプリケーションiをローカルメモリ２９にプリロードする(ステップＳ１１５)という処理を、ステップＳ１１６がNo及びステップＳ１１７がNoと判定されるまで、繰り返すというループ処理を構成している。
【０１４０】
ステップＳ１１３は、アプリケーションiの読込属性がプリロードであるか否かの判定であり、ステップＳ１１４は、アプリケーションの読込優先度が=MandatoryであるかOptionalであるかの判定である。ステップＳ１１３においてプリロードと判定され、ステップＳ１１４において読込優先度がMandatoryと判定されれば、アプリケーションはローカルメモリ２９にプリロードされることになる(ステップＳ１１５)。もしステップＳ１１３において読込属性がロードであると判定されれば、ステップＳ１１４〜ステップＳ１１５はスキップされることになる。
【０１４１】
ループ処理の終了要件を規定する2つのステップのうちステップＳ１１６は、applicationIDが次に高く、アプリケーションiと同一読込優先度のアプリケーションkが存在するか否かを判定するものである。そのようなアプリケーションkが存在するなら、そのアプリケーションkをアプリケーションiにする(ステップＳ１１９)。
ループ処理の終了要件を規定する2つのステップのうちステップＳ１１７は、データ管理テーブルにおいて次に低い読込優先度をもつアプリケーションが存在するか否かの判定であり、もし存在すれば、その次に低い読込優先度をもつアプリケーションのうち、最も小さいapplicationIDをアプリケーションkを選んで(ステップＳ１１８)、そのアプリケーションkをアプリケーションiにする(ステップＳ１１９)。これらステップＳ１１６、ステップＳ１１７がYesになっている限り、上述したステップＳ１１３〜ステップＳ１１５の処理は繰り返されることになる。ステップＳ１１６、ステップＳ１１７において、該当するアプリケーションが無くなれば本フローチャートの処理は終了することになる。
【０１４２】
ステップＳ１２０〜ステップＳ１２３は、ステップＳ１１４において読込優先度＝Optionalであると判定された場合に、実行される処理である。
ステップＳ１２０は、同じapplicationIDをもち、読込優先度が高いアプリケーションjが存在するか否かの判定である。
ステップＳ１２１は、ローカルメモリ２９の残り容量がアプリケーションiのサイズを上回るか否かを判定するステップである。ステップＳ１２０がNo、ステップＳ１２１がYesである場合、ステップＳ１１５においてアプリケーションiがローカルメモリ２９にプリロードされることになる。ステップＳ１２０がNo、ステップＳ１２１がNoである場合、アプリケーションiはローカルメモリ２９にプリロードされずそのままステップＳ１１６に移行することになる。
【０１４３】
こうしておくと、読込優先度＝Optionalのデータは、ステップＳ１２０−ステップＳ１２１の判定がYesにならないと、ローカルメモリ２９へのプリロードがなされない。メモリ規模が小さい旧再生装置は、2〜3個のアプリケーションを読み込んだ程度で、ステップＳ１２１の判定はNoになるが、メモリ規模が大きい新再生装置は、更に多くのアプリケーションを読み込んだとしても、ステップＳ１２１の判定はNoにならない。以上のように、旧再生装置では、ローカルメモリ２９にMandatoryのアプリケーションのみが読み込まれ、新再生装置には、Mandatoryのアプリケーションと、Optionalのアプリケーションとが読み込まれることになる。
【０１４４】
ステップＳ１２２は、ステップＳ１２０においてYesと判定された場合に実行されるステップである。同じapplicationIDをもち、読込優先度が高いアプリケーションjがローカルメモリ２９上に存在する場合、ローカルメモリ２９の残り容量と、アプリケーションjのサイズとの和が、アプリケーションiのサイズを上回るか否かを判定し(ステップＳ１２２)、もし上回れば、アプリケーションiを用いてローカルメモリ２９上のアプリケーションjを上書きすることによりプリロードする(ステップＳ１２３)。下回る場合は、アプリケーションiはローカルメモリ２９にプリロードされずそのままステップＳ１１６に移行することになる。
【０１４５】
ステップＳ１１５、ステップＳ１２３による読込処理の一例を、図４７（ａ）を参照しながら説明する。図４７（ａ）は、この具体例が想定しているデータ管理テーブルの一例を示す図である。本図における3つのアプリケーションは、それぞれ3つのファイルに格納されており、applicationIDは同じであるが(applicationID=1)、読込優先度は互いに異なる(mandatory,optional:high,optional:low)。こうしたデータ管理テーブルが処理対象であると、ステップＳ１１５により、読込優先度＝Mandatoryのアプリケーションはローカルメモリ２９に読み込まれる。しかし読込優先度＝Optionalのアプリケーションについては、ステップＳ１２０〜ステップＳ１２２の判定を経た上で、ステップＳ１２３において読み込まれる。ステップＳ１１５と違いステップＳ１２３では、既にローカルメモリ２９にある同じapplicationIDのアプリケーションを上書きしてゆくよう、プリロードがなされるので、複数アプリケーションのうち1つが排他的に、ローカルメモリ２９にロードされることになる。

i)読込優先度＝mandatoryのアプリケーションを読み込んだ後、読込優先度＝optional:highのアプリケーションを読み込むにあたって、ステップＳ１２２がNoと判定されればれば、読込優先度＝mandatoryのアプリケーションがローカルメモリ２９に残ることになる。読込優先度＝mandatoryのアプリケーションを読み込んだ後、読込優先度＝optional:highのアプリケーションを読み込むにあたって、ステップＳ１２２がYesと判定されれば、読込優先度＝optional:highのアプリケーションにより、読込優先度＝mandatoryのアプリケーションは上書きされ、読込優先度＝optional:highのアプリケーションがローカルメモリ２９に残ることになる。
【０１４６】
ii)読込優先度＝optional:highのアプリケーションを読み込んだ後、読込優先度＝optional:lowのアプリケーションを読み込むにあたって、ステップＳ１２２がNoと判定されればれば、読込優先度＝Mandatoryのアプリケーションがローカルメモリ２９に残ることになる。読込優先度＝optional:highのアプリケーションを読み込んだ後、読込優先度＝optional:lowのアプリケーションを読み込むにあたって、ステップＳ１２２がYesと判定されれば、読込優先度＝optional:lowのアプリケーションにより、読込優先度＝optional:highのアプリケーションは上書きされ(ステップＳ１２３)、読込優先度＝optional:lowのアプリケーションがローカルメモリ２９に残ることになる。
【０１４７】
ローカルメモリ２９の容量が許す限り、ローカルメモリ２９上のアプリケーションを上書きしてゆくとの処理が繰り返されるので、ローカルメモリ２９の格納内容は、図４７（ｂ）に示すように、mandatory＝optional:high＝>optional:lowと遷移してゆくことになる。メモリ規模に応じて、サイズが異なるJavaアーカイブファイルをローカルメモリ２９にロードすることができるので、メモリ規模が小さい再生装置については、必要最小限の解像度をもったサムネール画像を有するJavaアーカイブファイルを、メモリ規模が中程度の再生装置については、中程度の解像度をもったSD画像を有するJavaアーカイブファイルを、メモリ規模が大規模である再生装置については、高解像度をもったHD画像を有するJavaアーカイブファイルをローカルメモリ２９にロードすることができる。かかるロードにより、メモリ規模に応じて解像度が異なる画像を表示させることができ、オーサリング担当者によるタイトル制作の表現の幅が広がる。

図４８は、データ管理テーブルを参照した読取処理の具体例を示す図である。本図における2つのアプリケーションは、同じapplicationID(application#3)が付与された2つのアプリケーションを示す図である。そのうち一方は、AVClip中に埋め込まれていて、読込優先度がmandatoryに設定されている。他方は、AVClipとは別ファイルに記録されていて、読込優先度がOptionalに設定されている。前者のアプリケーションは、AVClipに埋め込まれているので、その埋込部分にあたる生存区間が、生存区間(title#1:chapter#4〜#5)として記述されている。これらのアプリケーションのうちapplication#2、application#3には、ロードを示す読込属性が付与されている。application#2はChapter#1〜Chapter#2を生存区間にしており、application#3はChapter#4〜Chapter#5を生存区間にしているので、タイトル時間軸においてどちらか一方が排他的にローカルメモリ２９上に常駐することになる。図４８（ｂ）は、タイトル時間軸上の別々の時点において、排他的に格納されるapplication#2、application#3を示す図である。これは必要最低限のメモリ規模しかもたない再生装置での再生を念頭に置いた配慮である。こうした内容のデータ管理テーブルが処理対象であるとアプリケーションマネージャ３６は、上述した図４６のフローチャートによりメモリ規模に応じて異なる処理を行う。
【０１４８】
後者のアプリケーションは、読込優先度＝ロードであるので、ローカルメモリ２９にロードされる。かかる処理により、Mandatoryなメモリ規模さえあれば、アプリケーションマネージャはデータをローカルメモリ２９にロードすることができる。ここで問題になるのは、メモリ規模が大きい再生装置による読み込み時である。メモリ規模が大きいにも拘らず、Chapter#4〜Chapter#5に到達するまでapplication#3を読み込めないというのは、メモリ規模の無駄になる。そこで本図のデータ管理テーブルには、同じapplication#3にプリロードを示す読込属性を付与してBD-ROMに記録しておき、これらに同じapplicationIDを付与している。
【０１４９】
前者のアプリケーションは、読込優先度＝Optionalであるので、ステップＳ１２１がYesになった場合に限り、プリロードされる(ステップＳ１１５)。こうすることで、メモリ規模が大きい再生装置は、title#1、Chapter#4〜Chapter#5の到達を待つことなく、AVClipに埋め込まれているのと同じアプリケーションをローカルメモリ２９にロードすることができるのである(図４８（ｃ）)。
【０１５０】
以上がプリロード時における処理である。続いてロード時における処理手順について説明する。
図４９は、データ管理テーブルに基づくロード処理の処理手順を示す図である。本フローチャートは、ステップＳ１３１〜ステップＳ１３３からなるループ処理を、タイトル再生が継続されている間、繰り返すというものである。
【０１５１】
ステップＳ１３１は、AutoRunを示す起動属性を有したアプリケーションの生存区間が到来したか否かの判定である。もし到来すれば、AutoRunを示す起動属性を有したアプリケーションをアプリケーションqにして(ステップＳ１３４)、アプリケーションqを起動する旨の起動指示をJava仮想マシン３８に発行して、アプリケーションqをローカルメモリ２９からワークメモリ３７に読み出させる(ステップＳ１３５)。
【０１５２】
ステップＳ１３３は、タイトル内PLの再生が全て終了したかの判定である。この判定は、第５実施形態に示したように、Playback Control Engine３２からの再生終結イベントがあったか否かでなされる。もし終了すれば、本フローチャートの処理を終了する。
ステップＳ１３２は、起動中アプリケーションからの呼出があったか否かの判定である。もしあれば、呼出先アプリケーションをアプリケーションqにして(ステップＳ１３６)、現在の再生時点は、アプリケーション管理テーブルにおけるアプリケーションqの生存区間であるか否かを判定する(ステップＳ１３７)。もし生存区間でなければ、起動失敗を表示して(ステップＳ１４８)、ステップＳ１３１〜ステップＳ１３３からなるループ処理に戻る。生存区間であれば、図５０のフローチャートに従い、ロード処理を行う。
【０１５３】
図５０におけるステップＳ１３８は、現在の再生時点がデータ管理テーブルにおけるアプリケーションqの生存区間であるか否かを示す判定である。もし生存区間でなければ、アプリケーションqはローカルメモリ２９にロードすることができない。この場合、アプリケーションqを起動する旨の起動指示をJava仮想マシン３８に発行し、ローカルメモリ２９を介することなく、直接アプリケーションqをBD-ROMからワークメモリ３７に読み出させる。この場合アプリケーションを読み出すためのヘッドシークが発生するから、PL再生は中断することになる(ステップＳ１４５)。
【０１５４】
もし生存区間であれば、ステップＳ１３９において、アプリケーションには読込属性が付加されているか否かを判定する。読込属性がないということは、アプリケーションqは、カルーセル化、若しくはインターリーブ化されていないことを意味する。しかし読込属性が付加されていなくても、ローカルメモリ２９にアプリケーションqを置くことは許される。そこで再生中断を承知の上、アプリケーションの読み出しを行う。つまりBD-ROMからローカルメモリ２９へとアプリケーションを読み出した上で、アプリケーションをワークメモリ３７に読み出す(ステップＳ１４０)。
【０１５５】
ステップＳ１４１〜ステップＳ１４６は、ステップＳ１３９がYesと判定された場合になされる処理である。ステップＳ１４１では、読込属性を参照することで、アプリケーションがプリロードされているか否かを判定する。プリロードされていれば、ステップＳ１３５に移行する。
ステップＳ１４２は、読込属性がロードである場合に実行される判定ステップであり、アプリケーションqがカルーセル化されているか、インターリーブ化されているかを判定する。インターリーブ化されていれば、キャッシュセンスをJava仮想マシン３８に実行させる(ステップＳ１４３)。ローカルメモリ２９にアプリケーションqが存在すれば、ステップＳ１３５に移行して、アプリケーションqをJava仮想マシン３８にロードさせる。
【０１５６】
ローカルメモリ２９にアプリケーションがなければ、トップメニュータイトルに分岐する等の例外処理を行う(ステップＳ１４４)。カルーセル化されていれば、タイマをセットし(ステップＳ１４８)、そのタイマがタイムアウトするまで(ステップＳ１４７)、キャッシュセンスをJava仮想マシン３８に実行させる(ステップＳ１４６)。もしローカルメモリ２９にアプリケーションqが出現すれば、図４９のステップＳ１３５に移行して、アプリケーションqをJava仮想マシン３８にロードさせる。タイムアウトすれば、トップメニュータイトルに分岐する等の例外処理を行う(ステップＳ１４４)。
【０１５７】
図５１は、Java仮想マシン３８によるアプリケーションの読み込みがどのようにして行われるかを模式化した図である。
矢印1,2は、アプリケーション管理テーブルに生存していて、データ管理テーブルに生存しており、カルーセル化,インターリーブ化を示す読込属性が存在するJavaアーカイブファイルの読み込みを示す。矢印1は、ステップＳ６５、６７においてなされるローカルメモリ２９センスを示す。このローカルメモリ２９センスは、カルーセル又はインターリーブ化により埋め込まれたデータが、ローカルメモリ２９に存在するかもしれないためローカルメモリ２９内をセンスするというものである。矢印2は、ステップＳ１３５に対応する読み込みであり、アプリケーションがローカルメモリ２９に存在していた場合の、ローカルメモリ２９からワークメモリ３７へのロードを示す。×付きの矢印は、ローカルメモリ２９にデータがない場合を示す。
【０１５８】
矢印▽1,2は、アプリケーション管理テーブルに生存しているが、データ管理テーブルに生存しておらず、読込属性が存在しないJavaアーカイブファイルの読み込みを示す。
矢印▽1は、ステップＳ１４５における読み込みに対応するものであり、Java仮想マシン３８によるBD-ROMからのダイレクトリードの要求を示す。矢印▽2はその要求による、BD-ROMからワークメモリ３７へのJavaアーカイブファイル読み出しを示す。
【０１５９】
矢印☆1,2,3は、アプリケーション管理テーブルに生存していて、データ管理テーブルに生存しているが、読込属性が存在しないJavaアーカイブファイルの読み込みを示す。
矢印☆1は、ステップＳ１４０における読み込みに対応するものであり、Java仮想マシン３８によるBD-ROMからのダイレクトリードの要求を示す。矢印☆2はその要求による、ローカルメモリ２９へのJavaアーカイブファイルの読み出しを示す。矢印☆3はローカルメモリ２９からワークメモリ３７へのJavaアーカイブファイルの読み出しを示す。
【０１６０】
以上のように本実施形態によれば、ローカルメモリ２９上で同時に常駐されるアプリケーションの数が所定数以下になるように規定しておくことができるので、ローカルメモリ２９からの読み出し時におけるキャッシュミスを極力回避することができる。キャッシュミスのないアプリケーション読み出しを保証することができるので、アプリケーション呼出時にあたては、AVClipの再生を止めてまで、BD-ROMからアプリケーションを読み出すことはなくなる。AVClip再生を途切れさせないので、AVClipのシームレス再生を保証することができる。
【０１６１】
(第７実施形態)
第３実施形態では、非AV系タイトルの時間軸をアプリケーションの生存区間に基づき定めることにした。しかしアプリケーションの動作というのは不安定であり、起動の失敗や異常終了がありうる。本実施形態は、起動失敗、異常終了があった場合のFailSafe機構を提案するものである。図５２（ａ）は、第７実施形態に係るBD-Jオブジェクトの内部構成を示す図である。図７（ｂ）と比較して本図が新規なのは、プレイリスト管理テーブルが追加されている点である。
【０１６２】
図５２（ｂ）は、プレイリスト管理テーブルの一例を示す図である。本図に示すようにプレイリスト管理テーブルは、PLの指定と、そのPLの再生属性とからなる。PLの指定は、対応するタイトルのタイトル時間軸において、再生可能となるPLを示す。PLの再生属性は、指定されたPLを、タイトル再生の開始と同時に自動再生するか否かを示す(こうして自動再生されるPLをデフォルトPLという)。
【０１６３】
次にプレイリスト管理テーブルによりタイトル時間軸がどのように規定されるかを、図５３を参照しながら説明する。図５３（ａ）は、再生属性が非自動再生を示すよう設定された場合の非AV系タイトルにおけるタイトル時間軸を示す図である。この場合、デフォルトPLは再生されないから、非AV系タイトル同様、アプリケーションの生存区間からタイトル時間軸が定まる。
【０１６４】
図５３（ｂ）は、再生属性がAutoPlayに設定された非AV系タイトルのタイトル時間軸を示す図である。再生属性がAutoPlayを示すよう設定されれば、PlaybackControl Engine３２は非AV系タイトルの再生開始と同時に、デフォルトPLの再生を開始する。しかしアプリケーションが正常に動作し、正常終了したとしても、このタイトル時間軸は、PL時間軸を基準にして定められる。
【０１６５】
図５３（ｃ）は、プレイリスト管理テーブルにおいて再生属性が”AutoPlay”を示すよう設定され、アプリケーションが異常終了した場合を示す。かかる異常終了により、どのアプリケーションも動作してない状態になるが、デフォルトPLの再生は継続する。この場合も、デフォルトPLのPL時間軸がタイトル時間軸になる。
図５３（ｄ）は、プレイリスト管理テーブルにおいて再生属性が”AutoPlay”を示すよう設定され、メインアプリの起動に失敗したケースを示す。この場合も、PlaybackControl Engine３２によるデフォルトPL再生は、アプリケーションの起動失敗とは関係なしに行われるので、デフォルトPLの時間軸がタイトル時間軸になる。
【０１６６】
以上のようにプレイリスト管理テーブルの再生属性を、”AutoPlay”に設定しておけば、Javaアプリケーションの起動に、5〜10秒という時間がかかったとしても、その起動がなされている間、”とりあえず何かが写っている状態”になる。この”とりあえず何かが写っている状態”によりタイトル実行開始時のスタートアップディレイを補うことができる。
【０１６７】
以上は本実施形態における記録媒体に対する改良である。続いて本実施形態における再生装置に対する改良について説明する。
図５２（ｃ）は、分岐先タイトルのプレイリスト管理テーブルにおいて、再生属性がAutoPlayに設定されたPLが存在する場合、再生装置がどのような処理を行うかを示す図である。本図に示すように、再生属性がAutoPlayに設定されたPLが、分岐先タイトルのプレイリスト管理テーブルに存在すれば、BD-Jモジュール３５内のアプリケーションマネージャ３６は、タイトル分岐直後にこのAutoPlayPLの再生を開始するようPlaybackControl Engine３２に指示する。このように再生属性がAutoPlayのPLは、タイトル分岐直後に再生開始が命じられることになる。
【０１６８】
上述した記録媒体の改良に対応するため、アプリケーションマネージャ３６は図５４に示すような処理手順で処理を行う。
図５４は、第７実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。本フローチャートは、図３８のフローチャートにおいてステップＳ２１の前にステップＳ１０３、ステップＳ１０４を追加し、ステップＳ２１と、ステップＳ２２との間にステップＳ１００を追加し、ステップＳ２３−ステップＳ２６間に、ステップＳ１０５を追加したものである。
【０１６９】
ステップＳ１０３は、対応するタイトルのプレイリスト管理テーブルの再生属性がAutoPlayであるか否かの判定である。もしAutoPlayなら、デフォルトPLに対する再生制御をPlaybackControl Engine３２に開始させる(ステップＳ１０４)。
ステップＳ１００は、Presentation Engine３１による再生中であるか否かを判定する。もし再生中であるなら、ステップＳ１０１に移行する。
【０１７０】
ステップＳ１０５は、ステップＳ２３がYes、ステップＳ２５がNoである場合に実行される判定ステップであり、再生属性がAutoPlayであるか否かを示す。もし否であるなら、タイトル終了をモジュールマネージャ３４に通知する。もしAutoPlayであるなら、ステップＳ１０１に移行して、処理を継続する。
図５５は、プレイリスト管理テーブルにおいて”再生属性＝AutoPlay”に設定されることにより、どのような再生が行われるかを模式化した図である。ここで再生すべきタイトルは、落下するタイル片を積み重ねるというゲームアプリを含む非AV系タイトルである。この非AV系タイトルにおいて、プレイリスト管理テーブルの再生属性がAutoPlayに設定されていれば、PlaybackControl Engine３２によるデフォルトPL再生も開始する。ゲームアプリの実行と、デフォルトPL再生とが並列的になされるので、図５５の上段の左側に示すように、前景をゲームアプリの画面とし、背景をデフォルトPLの再生画像とした合成画像が表示されることになる。このゲームアプリは途中で異常終了したとする。ゲームアプリはアプリケーションマネージャ３６により強制終了させられるが、デフォルトPLの再生が継続してなされるため、タイトルは、何かが写っている状態になる。このようなプレイリスト管理テーブルにおける再生属性の指定により、非AV系タイトル内のゲームアプリが異常終了した場合でも、ハングアップやブラックアウトがない動作を維持することができる。
【０１７１】
(第８実施形態)
第１実施形態においてBD-Jオブジェクトは、データ管理テーブル、アプリケーション管理テーブルという2つのテーブルを具備していたが、本実施形態は、これらを1つのテーブルに統合するという形態を開示する。かかる統合にあたって、図５６（ａ）に示すように、データ管理テーブルにおける読込属性という項目を廃し、代わりに起動属性にReady属性という属性を設ける。Ready属性とは、他のアプリケーションからの呼出又はアプリケーションマネージャ３６からの呼出に備えて、ローカルメモリ２９に予めアプリケーションをロードしておく旨を示す起動属性の類型である。
【０１７２】
図５６（ｂ）は、アプリケーションの扱いと、起動属性との関係を示した図である。第１実施形態に示したようにアプリケーションの扱いには、プリロードされるか否か(1)、現在の再生時点が有効区間に到来した際自動的に起動されるか、他からの呼出に応じて起動されるか(2)、タイトル再生進行に従ってロードされるか(3)、生存しているかという違いがあり、これらの違いにより、図５６（ｂ）に示すような5つの態様が出現する。このうち起動属性がAutoRunに設定されるのは、プリロードがなされ、”自動起動”である場合、及び、ロードがなされ、”自動起動”である場合である。
【０１７３】
一方、起動属性がReady属性に設定されるのは、プリロード、又は、ロードがなされ、起動項目が”呼出起動”を示している場合である。
尚、ワークメモリ３７では生存しているが、ローカルメモリ２９にはロードされない”との類型が存在し得ない。これは、アプリケーション・データ管理テーブルでは、ワークメモリ３７の生存区間と、ローカルメモリ２９の生存区間とが一体だからである。
【０１７４】
起動属性として、このReady属性を追加されたので、アプリケーションマネージャ３６はタイトル再生に先立ち、起動属性がAutoRunに設定されたアプリケーション、及び、起動属性がReady属性に設定されたアプリケーションをローカルメモリ２９にプリロードするとの処理を行う。こうすることにより、読込属性を設けなくても、アプリケーションをローカルメモリ２９にプリロードしておくとの処理が可能になる。
【０１７５】
図５７は、第８実施形態に係るJava仮想マシン３８によるアプリケーションの読み込みがどのようにして行われるかを模式化した図である。本図における読み込みは、図５１をベースにして作図している。
矢印1,2は、アプリケーション・データ管理テーブルに生存していて、起動属性がReady属性に設定されているJavaアーカイブファイルの読み込みを示す。
【０１７６】
矢印☆1,2,3は、アプリケーション・データ管理テーブルに生存していおり、起動属性がPersistentであるアプリケーションの読み込みを示す。
これらの矢印1,2、矢印☆1,2,3は、図５１でも記述されていたものだが、図５１に記述していた、▽1,2の矢印に該当する読み込み”は、図５７では存在しない。これは、アプリケーション・データ管理テーブルは、アプリケーション管理テーブル、データ管理テーブルを一体化したものなので、アプリケーション管理テーブル＝生存、データ管理テーブル＝非存在という組合せは表現し得ないからである。
【０１７７】
以上のように本実施形態によれば、データ管理テーブル、アプリケーション管理テーブルを1つのテーブル(アプリケーション・データ管理テーブル)にまとめることができるので、アプリケーションマネージャ３６による処理を簡略化することができる。尚、読込優先度をなくすことによりアプリケーション・データ管理テーブルをより簡略化にしても良い。
【０１７８】
(第９実施形態)
第１実施形態では、アプリケーションをローカルメモリ２９に読み込むにあたって、読込優先度を参照して、この読込優先度に従い、読み込み処理に優劣を与えた。これに対し第９実施形態は、Optionalを意味する情報と、0から255までの数値との組合せにより読込優先度を表す実施形態である。
【０１７９】
図５８（ａ）（ｂ）は、第９実施形態に係る読込優先度の一例を示す図である。255、128は、0から255までの読込優先度の一例であり、本例におけるapplication#2は、application#3より読込優先度が高いことを意味する。
本実施形態においてアプリケーションマネージャ３６は、第１実施形態同様、先ずMandatoryを示す読込優先度が付与されたアプリケーションをローカルメモリ２９に読み込む。
【０１８０】
その後、Optionalを示す読込優先度が付与されたアプリケーションに対しては、ローカルメモリ２９における容量が、アプリケーションのサイズを上回るか否かを判定する。もし上回るなら、読込優先度＝Optionalが付与されたアプリケーションをそのままローカルメモリ２９に読み込む。もし下回るなら、アプリケーションを構成するデータのうち、読込優先度を表す数値が高いアプリケーションをローカルメモリ２９に読み込む。そして、ローカルメモリ２９における残りの領域に、読込優先度を表す数値が低いアプリケーションを読み出す。
【０１８１】
こうすることでOptional扱いのアプリケーションについては、全体を格納する容量が再生装置のローカルメモリ２９になくても、その一部分をローカルメモリ２９に格納しておくことができる。
(第１０実施形態)
第１実施形態においてアプリケーションマネージャ３６は、同じapplicationIDが付与されたアプリケーションを、読込優先度に従い排他的にローカルメモリ２９にロードするとしたが、第１０実施形態は、アプリケーションにグループ属性を与えることにより、排他的なロードを実現する。図５９は、グループ属性が付与されたデータ管理テーブルを示す図である。グループ属性には、排他グループなし、排他グループあり、といった、2通りの設定が可能であり、排他グループありの場合、そのグループ番号が記述される。図５９（ａ）におけるtitle#1の「−」は、排他グループが存在しないことを示す。一方、title#2,#3の「group#1」は、排他グループがあり、title#2,#3は、group#1という排他グループに帰属していることを示す。以上が本実施形態に係る記録媒体の改良である。
【０１８２】
本実施形態に係る再生装置は、データ管理テーブルに基づいて各アプリケーションをローカルメモリ２９に読み込んだ後、ローカルメモリ２９のアプリケーションにおけるグループ属性をベリファイする。同じ排他グループに帰属するアプリケーションが、ローカルメモリ２９上に2つ以上存在していれば、そのうち一方をローカルメモリ２９から削除する。
【０１８３】
こうすることにより、ローカルメモリ２９の利用効率を向上させることができる。排他グループの具体例としては、ランチャーアプリと、このアプリにより起動されるアプリとからなるグループが相応しい。本アプリケーションにより起動されるアプリケーションは、原則1つに限られるので、ローカルメモリ２９には、ランチャー＋１個のアプリケーションのみが存在する筈である。もし3つ以上のアプリケーションが存在していれば、これをローカルメモリ２９から削除するという処理をアプリケーションマネージャ３６は行う必要があるので、各アプリケーションのグループ属性を設け、ローカルメモリ２９上で存在するアプリケーションがランチャー＋１個のアプリケーションになっているかどうかのチェックを行うのである。
【０１８４】
図５９（ａ）は、アプリケーション管理テーブルに基づくローカルメモリ２９に対するアクセスを示す図である。本図において、読込優先度＝Optionalと設定されたapplication#2、application#3のグループ属性は、group#1であるので、これらのアプリケーションは、同じ排他グループに属することになる。3つのアプリケーションのうち、application#1は上述したランチャーアプリケーションであり、application#2、application#3は、これにより起動されるアプリケーションであるので、どちらかのみがローカルメモリ２９上に存在するよう、グループ属性が付与されている。アプリケーションマネージャ３６は、これらapplication#2、application#3のグループ属性を参照して、どちらか1つをローカルメモリ２９から削除するとの処理を行う。かかる削除によりローカルメモリ２９に余白が生まれる。
【０１８５】
(第１１実施形態)
第１実施形態では、アプリケーション管理テーブルをタイトル毎に持たせるとしたが、本実施形態では、このアプリケーション管理テーブルの割当単位を変更させることを提案する。図６０は、割当単位のバリエーションを示す図である。本図において第1段目は、BD-ROMに記録されている3つのアプリケーション管理テーブルを示し、第2段目は、タイトル単位、第3段目は、ディスク単位、第4段目は、複数BD-ROMからなるディスクセット単位を示す。図中の矢印は、アプリケーション管理テーブルの割り当てを模式化して示している。この矢印を参照すると、第1段目におけるアプリケーション管理テーブル#1,#2,#3のそれぞれは、第2段目に示したtitle#1,#2,#3のそれぞれに割り当てられていることがわかる。また、ディスク単位ではアプリケーション管理テーブル#4が割り当てられており、ディスクセット全体に対しはアプリケーション管理テーブル#5が割り当てられている。このようにアプリケーション管理テーブルの割当単位を、タイトルより大きい単位にすることにより、1つのBD-ROMがローディングされている間、生存するようなアプリケーションや複数BD-ROMのうちどれかがローディングされている間、生存するようなアプリケーションを定義することができる。

(備考)
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記(A)(B)(C)(D)・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の【技術分野】
【０１８６】
の、出願当時の技術水準の特性に基づく。
(A)全ての実施形態では、本発明に係る光ディスクをBD-ROMとして実施したが、本発明の光ディスクは、記録される動的シナリオ、Index Tableに特徴があり、この特徴は、BD-ROMの物理的性質に依存するものではない。動的シナリオ、IndexTableを記録しうる記録媒体なら、どのような記録媒体であってもよい。例えば、DVD-ROM,DVD-RAM,DVD-RW,DVD-R,DVD+RW,DVD+R,CD-R,CD-RW等の光ディスク、PD,MO等の光磁気ディスクであってもよい。また、コンパクトフラッシュカード、スマートメディア、メモリスティック、マルチメディアカード、PCM-CIAカード等の半導体メモリカードであってもよい。フレシキブルディスク、SuperDisk,Zip,Clik!等の磁気記録ディスク(i)、ORB,Jaz,SparQ,SyJet,EZFley,マイクロドライブ等のリムーバルハードディスクドライブ(ii)であってもよい。更に、機器内蔵型のハードディスクであってもよい。

(B) 全ての実施形態における再生装置は、BD-ROMに記録されたAVClipをデコードした上でTVに出力していたが、再生装置をBD-ROMドライブのみとし、これ以外の構成要素をTVに具備させてもい、この場合、再生装置と、TVとをIEEE1394で接続されたホームネットワークに組み入れることができる。また、実施形態における再生装置は、テレビと接続して利用されるタイプであったが、ディスプレィと一体型となった再生装置であってもよい。更に、各実施形態の再生装置において、処理の本質的部分をなす部分のみを、再生装置としてもよい。これらの再生装置は、何れも本願明細書に記載された発明であるから、これらの何れの態様であろうとも、各実施形態に示した再生装置の内部構成を元に、再生装置を製造する行為は、本願の明細書に記載された発明の実施行為になる。各実施形態に示した再生装置の有償・無償による譲渡(有償の場合は販売、無償の場合は贈与になる)、貸与、輸入する行為も、本発明の実施行為である。店頭展示、カタログ勧誘、パンフレット配布により、これらの譲渡や貸渡を、一般ユーザに申し出る行為も本再生装置の実施行為である。
【０１８７】
(C)各フローチャートに示したプログラムによる情報処理は、ハードウェア資源を用いて具体的に実現されていることから、上記フローチャートに処理手順を示したプログラムは、単体で発明として成立する。全ての実施形態は、再生装置に組み込まれた態様で、本発明に係るプログラムの実施行為についての実施形態を示したが、再生装置から分離して、各実施形態に示したプログラム単体を実施してもよい。プログラム単体の実施行為には、これらのプログラムを生産する行為(1)や、有償・無償によりプログラムを譲渡する行為(2)、貸与する行為(3)、輸入する行為(4)、双方向の電子通信回線を介して公衆に提供する行為(5)、店頭展示、カタログ勧誘、パンフレット配布により、プログラムの譲渡や貸渡を、一般ユーザに申し出る行為(6)がある。
(D)各フロ−チャ−トにおいて時系列に実行される各ステップの「時」の要素を、発明を特定するための必須の事項と考える。そうすると、これらのフロ−チャ−トによる処理手順は、再生方法の使用形態を開示していることがわかる。各ステップの処理を、時系列に行うことで、本発明の本来の目的を達成し、作用及び効果を奏するよう、これらのフロ−チャ−トの処理を行うのであれば、本発明に係る記録方法の実施行為に該当することはいうまでもない。
【０１８８】
(E)Chapterを一覧表示するためのMenu(Chapter Menu)と、これの挙動を制御するMOVIEオブジェクトとをBD-ROMに記録しておき、TopMenuから分岐できるようにしてもよい。またリモコンキーのChapterキーの押下により呼出されるようにしてもよい。
(F)BD-ROMに記録するにあたって、AVClipを構成する各TSパケットには、拡張ヘッダを付与しておくことが望ましい。拡張ヘッダは、TP_extra_headerと呼ばれ、『Arrival_Time_Stamp』と、『copy_permission_indicator』とを含み4バイトのデータ長を有する。TP_extra_header付きTSパケット(以下EX付きTSパケットと略す)は、32個毎にグループ化されて、3つのセクタに書き込まれる。32個のEX付きTSパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。3個のセクタに収められた32個のEX付きTSパケットを”AlignedUnit”という。
【０１８９】
IEEE1394を介して接続されたホームネットワークでの利用時において、再生装置２００は、以下のような送信処理にてAligned Unitの送信を行う。つまり送り手側の機器は、AlignedUnitに含まれる32個のEX付きTSパケットのそれぞれからTP_extra_headerを取り外し、TSパケット本体をDTCP規格に基づき暗号化して出力する。TSパケットの出力にあたっては、TSパケット間の随所に、isochronousパケットを挿入する。この挿入箇所は、TP_extra_headerのArrival_Time_Stampに示される時刻に基づいた位置である。TSパケットの出力に伴い、再生装置２００はDTCP_Descriptorを出力する。DTCP_Descriptorは、TP_extra_headerにおけるコピー許否設定を示す。ここで「コピー禁止」を示すようDTCP_Descriptorを記述しておけば、IEEE1394を介して接続されたホームネットワークでの利用時においてTSパケットは、他の機器に記録されることはない。
【０１９０】
(G)各実施形態において、記録媒体に記録されるデジタルストリームはAVClipであったが、DVD-Video規格、DVD-Video Recording規格のVOB(VideoObject)であってもよい。VOBは、ビデオストリーム、オーディオストリームを多重化することにより得られたISO/IEC13818-1規格準拠のプログラムストリームである。またAVClipにおけるビデオストリームは、MPEG4やWMV方式であってもよい。更にオーディオストリームは、Linear-PCM方式、Dolby-AC3方式、MP3方式、MPEG-AAC方式、Dts、WMA(Windowsmedia audio)であってもよい。
【０１９１】
(H)各実施形態における映像作品は、アナログ放送で放送されたアナログ映像信号をエンコードすることにより得られたものでもよい。デジタル放送で放送されたトランスポートストリームから構成されるストリームデータであってもよい。
またビデオテープに記録されているアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。更にビデオカメラから直接取り込んだアナログ／デジタルの映像信号をエンコードしてコンテンツを得ても良い。他にも、配信サーバにより配信されるデジタル著作物でもよい。
【０１９２】
(I)BD-Jモジュール３５は、衛星放送受信のために機器に組み込まれたJavaプラットフォームであってもよい。BD-Jモジュール３５がかかるJavaプラットフォームであれば、本発明に係る再生装置は、MHP用STBとしての処理を兼用することになる。
更に携帯電話の処理制御のために機器に組み込まれたJavaプラットフォームであってもよい。かかるBD-Jモジュール３５がかかるJavaプラットフォームであれば、本発明に係る再生装置は、携帯電話としての処理を兼用することになる。
【０１９３】
(J)レイアモデルにおいて、BD-Jモードの上にMOVIEモードを配置してもよい。特にMOVIEモードでの動的シナリオの解釈や、動的シナリオに基づく制御手順の実行は、再生装置に対する負担が軽いので、MOVIEモードをBD-Jモード上で実行させても何等問題は生じないからである。また再生装置や映画作品の開発にあたって、動作保証が1つのモードで済むからである。
【０１９４】
更にBD-Jモードだけで再生処理を実行してもよい。第５実施形態に示したように、BD-JモードでもPLの再生と同期した再生制御が可能になるから、強いてMOVIEモードを設けなくてもよいという理由による。
(K)AVClipに多重化されるべきインタラクティブグラフィクスストリームにナビゲーションコマンドを設けて、あるPLから別のPLへの分岐を実現しても良い。
【産業上の利用可能性】
【０１９５】
本発明に係る再生装置は、ホームシアターシステムでの利用のように、個人的な用途で利用されることがありうる。しかし本発明は上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る再生装置は、産業上の利用可能性を有する。
【図面の簡単な説明】
【０１９６】
【図１】本発明に係る再生装置の使用行為についての形態を示す図である。
【図２】BD-ROMにおけるファイル・ディレクトリ構成を示す図である。
【図３】AVClip時間軸と、PL時間軸との関係を示す図である。
【図４】4つのClip_Information_file_nameによりなされた一括指定を示す図である。
【図５】PLmarkによるチャプター定義を示す図である。
【図６】SubPlayItem時間軸上の再生区間定義と、同期指定とを示す図である。
【図７】
（ａ）Movieオブジェクトの内部構成を示す図である。
（ｂ）BD-Jオブジェクトの内部構成を示す図である。
（ｃ）Javaアプリケーションの内部構成を示す図である。
【図８】
（ａ）Javaアーカイブファイルに収められているプログラム、データを示す図である。
（ｂ）xletプログラムの一例を示す図である。
【図９】
（ａ）トップメニュー、title#1、title#2といった一連のタイトルを示す図である。
（ｂ）PlayList#1、PlayList#2の時間軸を足し合わせた時間軸を示す図である。
【図１０】本編タイトル、オンラインショッピングタイトル、ゲームタイトルという3つのタイトルを含むディスクコンテンツを示す図である。
【図１１】図１０に示した3つのタイトルの再生画像の一例を示す図である。
【図１２】
（ａ）図１０の破線に示される帰属関係から各アプリケーションの生存区間をグラフ化した図である。
（ｂ）図１２（ａ）の生存区間を規定するため、記述されたアプリケーション管理テーブルの一例を示す図である。
【図１３】
（ａ）起動属性設定の一例を示す図である。
（ｂ）他のアプリケーションからのアプリケーション呼出があって初めて起動するアプリケーション(application#2)を示す図である。
【図１４】
（ａ）（ｂ）Suspendが有意義となるアプリケーション管理テーブル、生存区間の一例を示す図である。
【図１５】起動属性がとり得る三態様(Persistent、AutoRun、Suspend)と、直前タイトルにおけるアプリケーション状態の三態様(非起動、起動中、Suspend)とがとりうる組合せを示す図である。
【図１６】本発明に係る再生装置の内部構成を示す図である。
【図１７】
（ａ）BD-ROMに存在しているJavaアーカイブファイルを、ローカルメモリ２９上でどのように識別するかを示す図である。
（ｂ）図１７（ａ）の応用を示す図である。
【図１８】ROM２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。
【図１９】Presentation Engine３１〜モジュールマネージャ３４による処理を模式化した図である。
【図２０】アプリケーションマネージャ３６による処理を模式化した図である。
【図２１】ワークメモリ３７〜Default Operation Manager４０を示す図である。
【図２２】アプリケーションマネージャ３６による分岐時の制御手順を示す図である。
【図２３】アプリケーション終了処理の処理手順を示すフローチャートである。
【図２４】アプリケーション終了の過程を模式的に示した図である。
【図２５】
（ａ）PL時間軸上に生存区間を定めたアプリケーション管理テーブルを示す図である。
（ｂ）図２５（ａ）のアプリケーション管理テーブルに基づき、アプリケーションの生存区間を示した図である。
【図２６】（ａ）PL時間軸から定まるタイトル時間軸を示す。
（ｂ）メインとなるアプリケーションの生存区間から定まるタイトル時間軸を示す。
（ｃ）複数アプリケーションの生存区間から定まるタイトル時間軸を示す図である。
【図２７】タイトル再生時におけるアプリケーションマネージャ３６の処理手順を示すフローチャートである。
【図２８】
（ａ）BD-ROMにより実現されるメニュー階層を示す図である。
（ｂ）メニュー階層を実現するためのMOVIEオブジェクトを示す図である。
【図２９】Index Tableと、Index Tableから各Movieオブジェクトへの分岐とを模式化した図である。
【図３０】
（ａ）図２９（ｂ）のようにIndex Tableが記述された場合における分岐を示す。
（ｂ）非AV系タイトルが強制終了した際における分岐を示す図である。
【図３１】モジュールマネージャ３４の処理手順を示すフローチャートである。
【図３２】アプリケーションマネージャ３６によるアプリケーション強制終了の動作例を示す図である。
【図３３】Playback Control Engine３２によるPL再生手順を示すフローチャートである。
【図３４】アングル切換、SkipBack,SkipNextの受付手順を示すフローチャートである。
【図３５】SkipBack,SkipNextAPIがコールされた際の処理手順を示すフローチャートである。
【図３６】Presentation Engine３１による処理手順の詳細を示すフローチャートである。
【図３７】SubPlayItemの再生手順を示すフローチャートである。
【図３８】第５実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。
【図３９】データ管理テーブルの一例を示す図である。
【図４０】BD-Jオブジェクトが想定している実行モデルを示す図である。
【図４１】
（ａ）ローカルメモリ２９におけるJavaアーカイブファイル生存を示す生存区間を示す図である。
（ｂ）図４１（ａ）でのJavaアーカイブファイル生存区間を規定するため、記述されたデータ管理テーブルを示す図である。
【図４２】カルーセル化によるJavaアーカイブファイル埋め込みを示す図である。
【図４３】
（ａ）インターリーブ化によるAVClip埋め込みを示す図である。
（ｂ）読込属性の3つの類型を示す図である。
【図４４】
（ａ）データ管理テーブルの一例を示す図である。
（ｂ）図４４（ａ）のデータ管理テーブルの割り当てによるローカルメモリ２９の格納内容の変遷を示す図である。
【図４５】
（ａ）新旧再生装置におけるローカルメモリ２９のメモリ規模を対比して示す図である。
（ｂ）読込優先度が設定されたデータ管理テーブルの一例を示す図である。
【図４６】アプリケーションマネージャ３６によるプリロード制御の処理手順を示す図である。
【図４７】
（ａ）applicationIDが同一であるが、読込優先度は互いに異なる複数のアプリケーションを規定するデータ管理テーブルの一例を示す図である。
（ｂ）図４７（ａ）のデータ管理テーブルの割り当てによるローカルメモリ２９の格納内容の変遷を示す図である。
【図４８】
（ａ）プリロードされるべきアプリケーション、ロードされるべきアプリケーションに同一のapplicationIDを付与するよう記述されたデータ管理テーブルの一例を示す図である。
（ｂ）メモリ規模が小さい再生装置におけるローカルメモリ２９の格納内容の変遷を示す図である。
（ｃ）メモリ規模が大きい再生装置におけるローカルメモリ２９の格納内容の変遷を示す図である。
【図４９】データ管理テーブルに基づくアプリケーションマネージャ３６によるロード処理の処理手順を示す図である。
【図５０】アプリケーションqの生存区間に、現在の再生時点が到達した場合のアプリケーションマネージャ３６による処理手順を示す図である。
【図５１】Java仮想マシン３８によるアプリケーションの読み込みがどのようにして行われるかを模式化した図である。
【図５２】
（ａ）第７実施形態に係るBD-Jオブジェクトの内部構成を示す図である。
（ｂ）プレイリスト管理テーブルの一例を示す図である。
（ｃ）分岐先タイトルのプレイリスト管理テーブルにおいて、再生属性がAutoPlayに設定されたPLが存在する場合、再生装置がどのような処理を行うかを示す図である。
【図５３】
（ａ）再生属性が非自動再生を示すよう設定された場合の非AV系タイトルにおけるタイトル時間軸を示す図である。
（ｂ）再生属性がAutoPlayに設定された非AV系タイトルのタイトル時間軸を示す図である。
（ｃ）プレイリスト管理テーブルにおいて再生属性が”AutoPlay”を示すよう設定され、アプリケーションが強制終了した場合を示す図である。
（ｄ）プレイリスト管理テーブルにおいて再生属性が”AutoPlay”を示すよう設定され、メインアプリの起動に失敗したケースを示す図である。
【図５４】第７実施形態に係るアプリケーションマネージャ３６の処理手順を示すフローチャートである。
【図５５】プレイリスト管理テーブルにおいて”再生属性＝AutoPlay”に設定されることにより、どのような再生が行われるかを模式化した図である。
【図５６】
（ａ）（ｂ）アプリケーションの扱いと、起動属性との関係を示した図である。
【図５７】第８実施形態に係るJava仮想マシン３８によるアプリケーションの読み込みがどのようにして行われるかを模式化した図である。
【図５８】
（ａ）（ｂ）第９実施形態に係る読込優先度の一例を示す図である。
【図５９】
（ａ）グループ属性が付与されたデータ管理テーブルを示す図である。
（ｂ）アプリケーション管理テーブルに基づくローカルメモリ２９に対するアクセスを示す図である。
【図６０】アプリケーション管理テーブルの割当単位のバリエーションを示す図である。
【符号の説明】
【０１９７】
１ BD-ROMドライブ
２ リードバッファ
３ デマルチプレクサ
４ ビデオデコーダ
５ ビデオプレーン
９ P-Graphicsデコーダ
１０ Presentation Graphicsプレーン
１１ 合成部
１２ フォントゼネレータ
１３ I-Graphicsデコーダ
１４ スイッチ
１５ Interactive Graphicsプレーン
１６ 合成部
１７ HDD
１８ リードバッファ
１９ デマルチプレクサ
２０ オーディオデコーダ
２１ シナリオメモリ
２２ CPU
２３ キーイベント処理部
２４ 命令ROM
２５ スイッチ
２６ CLUT部
２７ CLUT部
２８ PSRセット
２９ ローカルメモリ
３１ Presentation Engine
３２ 再生制御エンジン
３３ HDMVモジュール
３４ モジュールマネージャ
３６ アプリケーションマネージャ
３７ ワークメモリ
３８ Java仮想マシン
３９ Event Listner Manager
４０ Default Operation Manage
上記目的は、分岐可能な複数タイトルと、各タイトルの再生時に実行可能なアプリケーションとが記録された記録媒体であって、タイトルは、デジタルストリームと、管理テーブルとを有しており、前記アプリケーションは、仮想マシン向けプログラミング言語で記述されたプログラムであり、管理テーブルは、アプリケーションと、対応するタイトルにおけるアプリケーションの起動属性とを対応づけて示し、前記起動属性は、タイトル間の分岐が発生した場合、分岐先タイトルにおいて、アプリケーションを、どのように制御するかを示すことを特徴とした記録媒体により達成される。
この記録媒体における起動属性は、タイトル間の分岐が発生した場合、分岐先タイトルにおいて、アプリケーションを、どのように制御するかを示しているので、タイトル間の分岐により、再生が複雑に進行した場合、冗長なアプリケーション起動の発生を避けることができ、タイトルバウンダリを短期間にすることができる。これによりタイトルバウンダリをユーザに意識させないスムーズな再生制御を実現することができる。このため、複数タイトルにわたるような長編もののコンテンツや、DVD−BOXのように、複数BD-ROMに記録されたシリーズ物コンテンツを提供する場合に真価を発揮する。

Claims (7)

  1. 分岐可能な複数タイトルと、各タイトルの再生時に実行可能なアプリケーションとが記録された記録媒体であって、
    タイトルは、デジタルストリームと、管理テーブルとを有しており、
    前記アプリケーションは、
    仮想マシン向けプログラミング言語で記述されたプログラムであり、
    管理テーブルは、アプリケーションと、対応するタイトルにおけるアプリケーションの起動属性とを対応づけて示し、
    起動属性には、
    分岐元タイトルにおいてアプリケーションが非起動状態である場合、当該分岐先タイトルにおいてアプリケーションを自動的に起動させる自動起動属性がある、ことを特徴とする記録媒体。
  2. デジタルストリームを含むタイトルの再生と、アプリケーションの実行とを同時に行う再生装置であって、
    １つのタイトルに帰属するデジタルストリームを再生する再生制御エンジン部と、
    複数タイトル間の分岐を制御するモジュールマネージャと、
    アプリケーションを実行するモジュールとを備え、
    アプリケーションには、起動属性が前記タイトル毎に付与されており、
    モジュールは、
    タイトル間の分岐が発生した際、分岐元タイトルにおけるアプリケーションの状態と、分岐先タイトルにおけるアプリケーションの起動属性とに基づき、分岐先タイトルにおけるアプリケーションの状態を制御するアプリケーションマネージャと
    を備えることを特徴とする再生装置。
  3. アプリケーションに付与された起動属性が状態継続を示しており、当該アプリケーションが分岐元タイトルにおいて非起動である場合、
    前記アプリケーションマネージャは、分岐先タイトルにおいても、当該アプリケーションを非起動にしておき、
    アプリケーションに付与された起動属性が状態継続を示しており、当該アプリケーショシが分岐元タイトルにおいて起動中である場合、
    前記アプリケーションマネージャは、分岐先タイトルにおいても、当該アプリケーションを起動中にする
    ことを特徴とする請求項２記載の再生装置。
  4. アプリケーションに付与された起動属性が自動起動を示しており、当該アプリケーションが分岐元タイトルにおいて非起動である場合、
    前記アプリケーションマネージャは、分岐先タイトルにおいて、当該アプリケーションを起動し、
    アプリケーションに付与された起動属性が自動起動を示しており、当該アプリケーションが分岐元タイトルにおいて起動中である場合、
    前記アプリケーションマネージャは、分岐先タイトルにおいて、当該アプリケーションの状態を継続する
    ことを特徴とする請求項２記載の再生装置。
  5. アプリケーションに付与された起動属性がサスペンドを示しており、当該アプリケーションが分岐元タイトルにおいて起動中である場合、
    前記アプリケーションマネージャは、分岐先タイトルにおいて、再生装置のリソースを当該アプリケーションに占有させるが、再生装置のＣＰＵパワーはアプリケーションに割り当てない状態に前記アプリケーションを遷移させる
    ことを特徴とする請求項２記載の再生装置。
  6. デジタルストリームを含むタイトルの再生と、アプリケーションの実行とを同時にコンピュータに実行させるプログラムであって、
    アプリケーションには、起動属性が前記タイトル毎に付与されており、
    プログラムは、
    タイトル間の分岐が発生した際、分岐元タイトルにおけるアプリケーションの状態と、分岐先タイトルにおけるアプリケーションの起動属性とに基づき、分岐先タイトルにおけるアプリケーションの状態をコンピュータに制御させる
    ことを特徴とするプログラム。
  7. デジタルストリームを含むタイトルの再生と、アプリケーションの実行とを同時にコンピュータに実行させる再生方法であって、
    アプリケーションには、起動属性が前記タイトル毎に付与されており、
    再生方法は、
    タイトル間の分岐が発生した際、分岐元タイトルにおけるアプリケーションの状態と、分岐先タイトルにおけるアプリケーションの起動属性とに基づき、分岐先タイトルにおけるアプリケーションの状態をコンピュータに制御させる
    ことを特徴とする再生方法。
JP2005514682A 2003-10-10 2004-10-12 記録媒体、再生装置、プログラム、再生方法。 Expired - Fee Related JP3825463B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP2003352913 2003-10-10
JP2003352913 2003-10-10
JP2003379758 2003-11-10
JP2003379758 2003-11-10
PCT/JP2004/015339 WO2005036555A1 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、プログラム、再生方法

Publications (2)

Publication Number Publication Date
JP3825463B2 JP3825463B2 (ja) 2006-09-27
JPWO2005036555A1 true JPWO2005036555A1 (ja) 2006-12-28

Family

ID=34436929

Family Applications (6)

Application Number Title Priority Date Filing Date
JP2005514677A Active JP4117006B2 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、記録方法、再生方法
JP2005514681A Active JP4182110B2 (ja) 2003-10-10 2004-10-12 再生装置、プログラム、再生方法。
JP2005514678A Expired - Fee Related JP4091078B2 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、記録方法、再生方法
JP2005514680A Active JP4262250B2 (ja) 2003-10-10 2004-10-12 再生装置、プログラム、再生方法。
JP2005514682A Expired - Fee Related JP3825463B2 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、プログラム、再生方法。
JP2008140512A Expired - Fee Related JP4262296B2 (ja) 2003-10-10 2008-05-29 システムｌｓｉ

Family Applications Before (4)

Application Number Title Priority Date Filing Date
JP2005514677A Active JP4117006B2 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、記録方法、再生方法
JP2005514681A Active JP4182110B2 (ja) 2003-10-10 2004-10-12 再生装置、プログラム、再生方法。
JP2005514678A Expired - Fee Related JP4091078B2 (ja) 2003-10-10 2004-10-12 記録媒体、再生装置、記録方法、再生方法
JP2005514680A Active JP4262250B2 (ja) 2003-10-10 2004-10-12 再生装置、プログラム、再生方法。

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2008140512A Expired - Fee Related JP4262296B2 (ja) 2003-10-10 2008-05-29 システムｌｓｉ

Country Status (7)

Country Link
US (10) US7515812B2 (ja)
EP (9) EP2267711A3 (ja)
JP (6) JP4117006B2 (ja)
KR (7) KR101059290B1 (ja)
CN (2) CN101702320B (ja)
TW (1) TW200518070A (ja)
WO (5) WO2005036545A1 (ja)

Families Citing this family (88)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200518070A (en) 2003-10-10 2005-06-01 Matsushita Electric Ind Co Ltd Recording medium, reproduction device, program, and reproduction method
US8218951B2 (en) 2003-10-30 2012-07-10 Samsung Electronics Co., Ltd. Storage medium storing program management information, and reproducing method and apparatus
KR101121382B1 (ko) 2003-11-10 2012-03-13 파나소닉 주식회사 기록매체, 재생장치, 재생방법
KR20050066264A (ko) 2003-12-26 2005-06-30 엘지전자 주식회사 고밀도 광디스크의 메뉴 구성방법 및 실행방법과기록재생장치
KR20050066265A (ko) * 2003-12-26 2005-06-30 엘지전자 주식회사 고밀도 광디스크의 메뉴 구성방법 및 실행방법과기록재생장치
JP4626799B2 (ja) * 2004-07-12 2011-02-09 ソニー株式会社 再生装置および方法、情報提供装置および方法、データ、記録媒体、並びにプログラム
CN101814310B (zh) 2004-07-22 2012-11-28 松下电器产业株式会社 重放装置和重放方法
JP4332195B2 (ja) * 2004-07-22 2009-09-16 パナソニック株式会社 アプリケーション連動再生を行う再生装置、再生方法、及び再生プログラム
KR100694123B1 (ko) * 2004-07-30 2007-03-12 삼성전자주식회사 동영상 데이터와 어플리케이션 프로그램이 기록된 저장매체 및 그 재생 장치 및 방법
KR100677132B1 (ko) * 2004-09-09 2007-02-02 삼성전자주식회사 동영상 재생 및 프로그래밍 기능을 위한 멀티미디어데이터를 기록한 저장 매체, 그 재생 장치 및 재생 방법
CN101057288B (zh) 2004-11-09 2010-12-22 汤姆森许可贸易公司 把内容绑定到可移动存储器上的方法和装置
KR20060059572A (ko) * 2004-11-29 2006-06-02 삼성전자주식회사 플레이리스트를 자동 재생하기 위한 정보를 포함하는 저장매체, 그 재생 장치 및 재생 방법
JP5265920B2 (ja) * 2004-12-06 2013-08-14 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 複数の記憶媒体にインターラクティブ性を拡張する方法と装置
KR20060081337A (ko) * 2005-01-07 2006-07-12 엘지전자 주식회사 비밀키를 이용한 암호화 및 복호화 방법
KR101049133B1 (ko) * 2005-01-21 2011-07-15 엘지전자 주식회사 기록매체, 기록매체의 재생방법과 재생장치
EP1843351B1 (en) 2005-01-28 2012-08-22 Panasonic Corporation Recording medium, program, and reproduction method
EP1696321A1 (en) 2005-02-23 2006-08-30 Deutsche Thomson-Brandt Gmbh Method and apparatus for executing software applications
EP2317516B1 (en) * 2005-02-04 2013-04-17 Panasonic Corporation Readout apparatus, recording method and readout method
US7844355B2 (en) * 2005-02-18 2010-11-30 Panasonic Corporation Stream reproduction device and stream supply device
US8787131B2 (en) 2005-02-28 2014-07-22 Koninklijke Philips N.V. Fallback mechanism for data reproduction
JP2008537273A (ja) * 2005-03-03 2008-09-11 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 光ディスクアプリケーション用のストリームファイルシステム
US7191215B2 (en) * 2005-03-09 2007-03-13 Marquee, Inc. Method and system for providing instantaneous media-on-demand services by transmitting contents in pieces from client machines
US9176955B2 (en) * 2005-03-09 2015-11-03 Vvond, Inc. Method and apparatus for sharing media files among network nodes
US7698451B2 (en) * 2005-03-09 2010-04-13 Vudu, Inc. Method and apparatus for instant playback of a movie title
US8904463B2 (en) * 2005-03-09 2014-12-02 Vudu, Inc. Live video broadcasting on distributed networks
US20090019468A1 (en) * 2005-03-09 2009-01-15 Vvond, Llc Access control of media services over an open network
US20090025046A1 (en) * 2005-03-09 2009-01-22 Wond, Llc Hybrid architecture for media services
US20080022343A1 (en) 2006-07-24 2008-01-24 Vvond, Inc. Multiple audio streams
US7937379B2 (en) * 2005-03-09 2011-05-03 Vudu, Inc. Fragmentation of a file for instant access
US8219635B2 (en) * 2005-03-09 2012-07-10 Vudu, Inc. Continuous data feeding in a distributed environment
US8099511B1 (en) 2005-06-11 2012-01-17 Vudu, Inc. Instantaneous media-on-demand
US8799757B2 (en) * 2005-07-01 2014-08-05 Microsoft Corporation Synchronization aspects of interactive multimedia presentation management
US8020084B2 (en) * 2005-07-01 2011-09-13 Microsoft Corporation Synchronization aspects of interactive multimedia presentation management
US20080238938A1 (en) * 2005-08-29 2008-10-02 Eklund Don Effects for interactive graphic data in disc authoring
JP4972933B2 (ja) * 2005-12-28 2012-07-11 ソニー株式会社 データ構造、記録装置、記録方法、記録プログラム、再生装置、再生方法および再生プログラム
US20070223889A1 (en) * 2006-03-16 2007-09-27 Dandekar Shree A Embedded high definition media management module for information handling systems
JP2007328692A (ja) * 2006-06-09 2007-12-20 Canon Inc 代数演算方法及びその装置、プログラム
US8296812B1 (en) 2006-09-01 2012-10-23 Vudu, Inc. Streaming video using erasure encoding
EP1923781A1 (en) * 2006-11-14 2008-05-21 Thomson Holding Germany GmbH & Co. OHG Method and device for sequentially processing a plurality of programs
US8015548B2 (en) * 2007-03-22 2011-09-06 Arcsoft, Inc. Method for obtaining context of corresponding Xlet while playing BD-J title
EP2234109B8 (en) * 2007-12-17 2016-06-01 Panasonic Intellectual Property Corporation of America Individual sales oriented recording medium, recording device, reproducing device and method for them
KR100943907B1 (ko) * 2008-01-10 2010-02-24 엘지전자 주식회사 데이터 재생방법 및 기록재생장치 및 디지털 방송수신장치
EP2107567A1 (en) * 2008-04-04 2009-10-07 Deutsche Thomson OHG Data carrier carrying a set of machine-interpretable instructions and media content which is presented upon execution of said machine-interpretable instructions
JP5406178B2 (ja) * 2008-04-16 2014-02-05 パナソニック株式会社 再生装置、再生方法、プログラム
EP2270801B1 (en) 2008-04-16 2018-12-05 Panasonic Intellectual Property Management Co., Ltd. Recording medium, recording device, recording method, and reproduction device
KR101486772B1 (ko) * 2008-06-04 2015-02-04 삼성전자주식회사 재생 위치에 따라 디지털 컨텐츠를 관리하는 방법과 장치및 실행하는 방법 및 장치
JP2010009408A (ja) * 2008-06-27 2010-01-14 Sony Corp 情報処理装置、およびデータ処理方法、並びにプログラム
JP5395074B2 (ja) 2008-07-16 2014-01-22 パナソニック株式会社 再生装置、再生方法、プログラム
US8045429B2 (en) 2008-07-29 2011-10-25 Fujitsu Ten Limited Control apparatus and method for content reproducing
US8566869B2 (en) 2008-09-02 2013-10-22 Microsoft Corporation Pluggable interactive television
US20100088602A1 (en) * 2008-10-03 2010-04-08 Microsoft Corporation Multi-Application Control
WO2010054120A2 (en) * 2008-11-06 2010-05-14 Deluxe Digital Studios, Inc. Methods, systems and apparatuses for use in updating a portable storage medium
JP5368470B2 (ja) * 2008-11-06 2013-12-18 パナソニック株式会社 再生装置、再生方法、再生プログラム、及び集積回路
CN103747226B (zh) * 2008-12-04 2015-11-04 三菱电机株式会社 视频信息再现方法和视频信息再现装置
JP5433239B2 (ja) * 2009-01-15 2014-03-05 日本放送協会 放送型アプリケーションの起動システム
KR101862351B1 (ko) * 2009-01-21 2018-05-29 삼성전자주식회사 콘텐트 정보 제공 및 재생 방법 및 장치
KR20100111996A (ko) * 2009-04-08 2010-10-18 삼성전자주식회사 가상 이미지 파일 처리 방법 및 장치
EP2254117B1 (en) 2009-05-20 2018-10-31 Sony DADC Austria AG Method for copy protection
EP2254119B1 (en) 2009-05-20 2019-03-13 Sony DADC Austria AG Method for copy protection
RU2539717C2 (ru) 2009-05-20 2015-01-27 Сони Дадк Аустриа Аг Способ защиты от копирования
EP2254120A1 (en) 2009-05-20 2010-11-24 Sony DADC Austria AG Method for copy protection
EP2254116A1 (en) 2009-05-20 2010-11-24 Sony DADC Austria AG Method for copy protection
EP2254118A1 (en) 2009-05-20 2010-11-24 Sony DADC Austria AG Method for copy protection
US9263085B2 (en) 2009-05-20 2016-02-16 Sony Dadc Austria Ag Method for copy protection
EP2254121A1 (en) 2009-05-20 2010-11-24 Sony DADC Austria AG Method for copy protection
JP5215255B2 (ja) * 2009-07-10 2013-06-19 シャープ株式会社 プログラム実行装置、プログラム実行方法、コンテンツ再生装置、プログラムおよび記録媒体
WO2011007417A1 (ja) * 2009-07-14 2011-01-20 パイオニア株式会社 再生装置及び方法、並びにコンピュータプログラム
US8401370B2 (en) * 2010-03-09 2013-03-19 Dolby Laboratories Licensing Corporation Application tracks in audio/video containers
JP2011216165A (ja) 2010-04-01 2011-10-27 Alpine Electronics Inc ビデオ再生装置、コンピュータプログラム及びレジューム再生方法
US8909029B2 (en) * 2010-10-13 2014-12-09 Sony Corporation Capturing playback key events in BD players
US8648959B2 (en) 2010-11-11 2014-02-11 DigitalOptics Corporation Europe Limited Rapid auto-focus using classifier chains, MEMS and/or multiple object focusing
JP6018797B2 (ja) * 2011-05-20 2016-11-02 日本放送協会 受信機
US8355305B1 (en) * 2011-07-14 2013-01-15 Disney Enterprises, Inc. System and method for initialization of media asset modules for improved execution sequence on a playback environment
JP5857636B2 (ja) 2011-11-02 2016-02-10 ソニー株式会社 情報処理装置、情報処理方法及びプログラム
EP2720473B1 (en) * 2012-04-19 2020-09-02 Saturn Licensing LLC Reception device, reception method, transmission device, transmission method, and program
KR20140018743A (ko) * 2012-08-03 2014-02-13 삼성전자주식회사 디스크리스 어플리케이션 재생 장치 및 기록 장치, 재생 방법 및 기록 방법과 디스크리스 어플리케이션을 기록한 정보저장매체
CN102917246B (zh) * 2012-08-31 2015-01-14 北京视博云科技有限公司 一种基于虚拟机的应用数据提供方法、装置及系统
KR20140039504A (ko) * 2012-09-24 2014-04-02 삼성전자주식회사 블루레이 디스크 재생 장치 및 블루레이 디스크 로딩 방법
JP6316196B2 (ja) * 2012-10-10 2018-04-25 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ 受信装置、受信方法、送信装置、送信方法、及び、プログラム
DE112014001637T5 (de) 2013-03-28 2015-12-24 Mitsubishi Electric Corporation Wiedergabevorrichtung, Steuerverfahren und Programm
CN104679578B (zh) * 2015-03-12 2018-09-07 绚视软件科技(上海)有限公司 BD-java平台上的最小内存自适应机制及使用方法
CN104951340B (zh) * 2015-06-12 2018-07-06 联想(北京)有限公司 一种信息处理方法及装置
JPWO2017056194A1 (ja) * 2015-09-29 2017-10-05 株式会社東芝 情報機器または情報通信端末および、情報処理方法
KR102401772B1 (ko) * 2015-10-02 2022-05-25 삼성전자주식회사 전자 장치에서 어플리케이션 실행 장치 및 방법
US10204059B2 (en) 2016-09-29 2019-02-12 International Business Machines Corporation Memory optimization by phase-dependent data residency
CN106980579B (zh) 2016-09-30 2020-08-14 阿里巴巴集团控股有限公司 一种图片加载方法及装置
EP3310066A1 (en) * 2016-10-14 2018-04-18 Spotify AB Identifying media content for simultaneous playback
JP7119858B2 (ja) * 2018-09-28 2022-08-17 ブラザー工業株式会社 工具寿命管理装置、工作機械、表示処理方法及びコンピュータプログラム

Family Cites Families (71)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0491104A (ja) 1990-08-06 1992-03-24 Ootex Kk 光重合反応開始剤
JPH0759608B2 (ja) 1990-08-06 1995-06-28 株式会社クラレ イミド化アクリル樹脂粒子体の処理方法
JPH0491078A (ja) 1990-08-06 1992-03-24 Kao Corp イミダゾール誘導体
JP2609749B2 (ja) 1990-08-31 1997-05-14 日本電気アイシーマイコンシステム株式会社 電流供給回路
JP2798490B2 (ja) 1990-09-03 1998-09-17 日本電気アイシーマイコンシステム株式会社 発振回路
JPH064166A (ja) 1992-06-24 1994-01-14 Okayama Nippon Denki Software Kk ジョブの有効期間設定装置
JPH06230946A (ja) 1993-02-07 1994-08-19 Fuji Xerox Co Ltd 自動プログラム開始装置
DE69601571T2 (de) 1995-08-21 1999-07-01 Matsushita Electric Ind Co Ltd Multimedia optische platte, die in der lage ist den bildinhalt fuer laengere zeit frisch zu halten und wiedergabegeraet und verfahren dafuer
EP0788105B1 (en) * 1995-08-21 1999-10-20 Matsushita Electric Industrial Co., Ltd. Multimedia optical disk for easily realizing branch reproduction to parental lock section with a little amount of control information and reproducing device therefor
CN100364009C (zh) 1995-08-21 2008-01-23 松下电器产业株式会社 再生设备及记录方法
CN1118049C (zh) 1995-08-21 2003-08-13 松下电器产业株式会社 根据交互控制实现意外性场景展开的多媒体光盘再生装置
EP0777230A1 (de) * 1995-12-04 1997-06-04 Markus Zwickl CDs enthaltend zusätzliche Textinformation
DE69735947T2 (de) * 1996-04-12 2006-10-26 Matsushita Electric Industrial Co., Ltd., Kadoma Optische Multimedia-Platte die sowohl Videotitel mit AV-Funktionen sowie Videotitel ohne solche Funktionen speichert, die augenblicklich unterscheiden kann zwischen Arten von Titeln und Wiedergabegerät und Wiedergabeverfahren für solch eine Platte
DE69701436T2 (de) 1996-05-09 2000-07-06 Matsushita Electric Ind Co Ltd Optische multimedia-scheibe, wiedergabevorrichtung und -verfahren zur überlagerung eines untergeordneten bildes auf ein hauptbild in einer ausgeglichenen weise, unabhängig von der schirmposition des hauptbildes
JPH1063362A (ja) 1996-08-16 1998-03-06 Nec Corp レジューム要因別に複数のプログラム状態を保持可能なサスペンドレジューム方法
JP3948051B2 (ja) 1997-04-30 2007-07-25 ソニー株式会社 編集装置及びデータ編集方法
JP3655433B2 (ja) 1997-06-20 2005-06-02 パイオニア株式会社 コンピュータ読み取り可能な記録媒体及び情報再生装置
JPH11219313A (ja) 1998-02-02 1999-08-10 Mitsubishi Electric Corp コンテンツ先読み方法
WO1999050771A1 (en) 1998-03-31 1999-10-07 International Business Machines Corporation A method and apparatus for creating an electronic commerce system
JPH11296381A (ja) 1998-04-08 1999-10-29 Matsushita Electric Ind Co Ltd 仮想マシン及びコンパイラ
JP3262539B2 (ja) 1998-06-15 2002-03-04 株式会社ディジタル・ビジョン・ラボラトリーズ データ放送方式及び同方式に適用されるデータ受信装置
EP0989743A1 (en) * 1998-09-25 2000-03-29 CANAL+ Société Anonyme Application data table for a multiservice digital transmission system
JP2000149514A (ja) 1998-11-10 2000-05-30 Alpine Electronics Inc ディスク再生装置
US7634787B1 (en) 1999-06-15 2009-12-15 Wink Communications, Inc. Automatic control of broadcast and execution of interactive applications to maintain synchronous operation with broadcast programs
JP2001022625A (ja) 1999-07-09 2001-01-26 Sony Corp データ記録装置、データ記録方法、データ取得装置、データ取得方法
US6874145B1 (en) * 1999-07-13 2005-03-29 Sun Microsystems, Inc. Methods and apparatus for implementing an application lifecycle design for applications
EP1194840B1 (en) 1999-07-13 2005-02-09 Sun Microsystems, Inc. Digital television receiver for managing execution of an application according to an application lifecycle
JP3756708B2 (ja) * 1999-09-30 2006-03-15 株式会社東芝 情報処理端末装置およびそのファイル管理方法
AU770707B2 (en) * 1999-10-29 2004-02-26 Opentv, Corp. Playback of interactive programs
ES2211641T3 (es) 1999-10-29 2004-07-16 Opentv, Corp. Sistema y metodo para el registro de datos "pushed".
JP2003514335A (ja) 1999-11-10 2003-04-15 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 記録担体、記録担体を再生する装置、記録担体を再生する方法、記録担体を記録する装置及び記録担体を記録する方法
JP2001238161A (ja) 2000-02-25 2001-08-31 Sony Corp 情報付加装置、情報付加方法および記録媒体
US7200857B1 (en) 2000-06-09 2007-04-03 Scientific-Atlanta, Inc. Synchronized video-on-demand supplemental commentary
EP2546833A3 (en) 2000-04-21 2014-08-20 Sony Corporation Information processing apparatus, method and computer program
GB0016062D0 (en) * 2000-06-30 2000-08-23 Koninkl Philips Electronics Nv Playback of applications with non-linear time
JP2002057990A (ja) * 2000-08-09 2002-02-22 Nec Corp 映像再生システム及びそれに用いるデータ同期方式
GB2370658A (en) 2000-12-29 2002-07-03 Metadyne Ltd A modular software framework
JP2002238161A (ja) 2001-02-14 2002-08-23 Yanmar Diesel Engine Co Ltd 分散電源用発電機の出力方法
JP2002269929A (ja) 2001-03-08 2002-09-20 Hitachi Ltd ディスク装置
JP2002369154A (ja) * 2001-04-02 2002-12-20 Matsushita Electric Ind Co Ltd ディジタル映像コンテンツの映像再生装置、映像再生方法、映像再生プログラム、パッケージメディア
KR20030007706A (ko) * 2001-04-02 2003-01-23 마츠시타 덴끼 산교 가부시키가이샤 디지털 영상 콘텐츠의 영상재생 장치, 영상재생 방법,영상재생 프로그램, 패키지 미디어
KR100771264B1 (ko) 2001-05-12 2007-10-29 엘지전자 주식회사 스크립트 파일이 포함 기록된 기록매체와, 그 재생장치 및방법
JP2003032637A (ja) 2001-07-16 2003-01-31 Sharp Corp データ放送受信装置
DE60223483T2 (de) 2001-10-29 2008-09-18 Humax Co. Ltd., Yougin Verfahren zum aufzeichenen eines digitalen Rundfunkprogramms und zeitbasierter Wiedergabe eines aufgezeichneten Rundfunkprogramms und zugehörige Vorrichtung
TW200300928A (en) 2001-11-30 2003-06-16 Sony Corportion Information processing method and apparatus, program storage medium, program and information recording medium
JP3921593B2 (ja) 2001-11-30 2007-05-30 ソニー株式会社 情報処理装置および方法、プログラム格納媒体、プログラム、並びに情報記録媒体
US6968445B2 (en) 2001-12-20 2005-11-22 Sandbridge Technologies, Inc. Multithreaded processor with efficient processing for convergence device applications
GB0130534D0 (en) 2001-12-20 2002-02-06 Aspex Technology Ltd Improvements relating to data transfer addressing
AU2003206150A1 (en) * 2002-02-07 2003-09-02 Samsung Electronics Co., Ltd Information storage medium containing display mode information, and reproducing apparatus and method therefor
JP4532810B2 (ja) * 2002-02-22 2010-08-25 キヤノン株式会社 画像処理装置、画像処理装置の制御方法、プログラム、及びコンピュータ読み取り可能な記憶媒体
JP2003249057A (ja) 2002-02-26 2003-09-05 Toshiba Corp デジタル情報媒体を用いるエンハンスド・ナビゲーション・システム
JP3990928B2 (ja) 2002-03-19 2007-10-17 キヤノン株式会社 テレビジョン放送受信装置、再生方法及びプログラム
US7814025B2 (en) * 2002-05-15 2010-10-12 Navio Systems, Inc. Methods and apparatus for title protocol, authentication, and sharing
WO2004001752A1 (en) * 2002-06-24 2003-12-31 Lg Electronics Inc. Recording medium having data structure for managing reproduction of multiple title video data recorded thereon and recording and reproducing methods and apparatuses
DE10228103A1 (de) 2002-06-24 2004-01-15 Bayer Cropscience Ag Fungizide Wirkstoffkombinationen
US20040114915A1 (en) * 2002-08-26 2004-06-17 Samsung Electronics Co., Ltd. Apparatus for reproducing AV data in interactive mode, method of handling user input, and information storage medium therefor
CN1695197B (zh) * 2002-09-12 2012-03-14 松下电器产业株式会社 播放设备、播放方法、以及记录介质的记录方法
WO2004049151A2 (en) 2002-11-26 2004-06-10 Matsushita Electric Industrial Co., Ltd. Apparatus for managing removable storage media that can be connected thereto, and method, program, and system lsi for managing removable storage media
JP3908724B2 (ja) 2002-12-09 2007-04-25 株式会社東芝 情報再生装置及び情報再生方法
KR101027200B1 (ko) 2003-02-21 2011-04-06 파나소닉 주식회사 기록매체, 재생장치, 기록방법 및 재생방법
KR100957799B1 (ko) 2003-03-06 2010-05-13 엘지전자 주식회사 대화형 디스크의 재생환경 설정방법
US7563748B2 (en) 2003-06-23 2009-07-21 Cognis Ip Management Gmbh Alcohol alkoxylate carriers for pesticide active ingredients
KR101014665B1 (ko) 2003-10-06 2011-02-16 삼성전자주식회사 프리로드 정보가 기록된 정보저장매체, 그 재생장치 및재생방법
JP4091105B2 (ja) 2003-10-10 2008-05-28 松下電器産業株式会社 記録媒体、再生装置、記録方法、再生方法
TW200518070A (en) 2003-10-10 2005-06-01 Matsushita Electric Ind Co Ltd Recording medium, reproduction device, program, and reproduction method
JP4117019B2 (ja) 2003-10-10 2008-07-09 松下電器産業株式会社 記録媒体、再生装置、記録方法、再生方法
JP4091104B2 (ja) 2003-10-10 2008-05-28 松下電器産業株式会社 記録媒体、再生装置、記録方法、再生方法
US7467197B2 (en) * 2005-01-20 2008-12-16 International Business Machines Corporation Workflow anywhere: invocation of workflows from a remote device
JP2007265852A (ja) 2006-03-29 2007-10-11 Matsushita Electric Ind Co Ltd 複合集電体およびその製造方法
JP2007265850A (ja) 2006-03-29 2007-10-11 Konica Minolta Holdings Inc 有機エレクトロルミネッセンス素子の製造方法及び製造装置
JP2007265851A (ja) 2006-03-29 2007-10-11 Molex Inc ケーブル用コネクタ

Also Published As

Publication number Publication date
EP2267711A2 (en) 2010-12-29
US20070089146A1 (en) 2007-04-19
WO2005036546A1 (ja) 2005-04-21
CN101702320A (zh) 2010-05-05
KR20090088969A (ko) 2009-08-20
EP1675117A4 (en) 2010-01-06
KR20080043888A (ko) 2008-05-19
KR101051846B1 (ko) 2011-07-25
KR100937791B1 (ko) 2010-01-20
WO2005036555A1 (ja) 2005-04-21
KR101051843B1 (ko) 2011-07-26
JP4262296B2 (ja) 2009-05-13
US20090165024A1 (en) 2009-06-25
WO2005036547A1 (ja) 2005-04-21
JPWO2005036554A1 (ja) 2006-12-28
US8107788B2 (en) 2012-01-31
US20060282612A1 (en) 2006-12-14
KR101059290B1 (ko) 2011-08-24
EP1672637A4 (en) 2010-02-24
EP1675118A4 (en) 2010-01-06
CN101702320B (zh) 2011-11-23
KR20070026322A (ko) 2007-03-08
TWI352342B (ja) 2011-11-11
JP3825463B2 (ja) 2006-09-27
JPWO2005036545A1 (ja) 2006-12-28
JP4262250B2 (ja) 2009-05-13
JP4091078B2 (ja) 2008-05-28
US7630615B2 (en) 2009-12-08
EP1677302A4 (en) 2007-03-14
US20070089156A1 (en) 2007-04-19
KR100937790B1 (ko) 2010-01-20
US7515812B2 (en) 2009-04-07
EP2239737A3 (en) 2010-11-17
US20080205859A1 (en) 2008-08-28
US8131130B2 (en) 2012-03-06
KR101059343B1 (ko) 2011-08-24
US7702222B2 (en) 2010-04-20
EP2239737A2 (en) 2010-10-13
EP2267711A3 (en) 2013-04-17
KR20070028289A (ko) 2007-03-12
US7623769B2 (en) 2009-11-24
US8437625B2 (en) 2013-05-07
JP4117006B2 (ja) 2008-07-09
US20070274680A1 (en) 2007-11-29
US20100202278A1 (en) 2010-08-12
KR20070028290A (ko) 2007-03-12
US8509596B2 (en) 2013-08-13
EP1944771A2 (en) 2008-07-16
US20080304811A1 (en) 2008-12-11
EP1944772A2 (en) 2008-07-16
JP4182110B2 (ja) 2008-11-19
EP1675119A1 (en) 2006-06-28
US8406604B2 (en) 2013-03-26
EP1675117A1 (en) 2006-06-28
KR20080043887A (ko) 2008-05-19
EP1675119A4 (en) 2010-01-06
CN101840718B (zh) 2013-01-23
EP1944772A3 (en) 2010-01-06
WO2005036554A1 (ja) 2005-04-21
US20100014832A1 (en) 2010-01-21
JP2008287864A (ja) 2008-11-27
US7715696B2 (en) 2010-05-11
WO2005036545A1 (ja) 2005-04-21
TW200518070A (en) 2005-06-01
EP1675118A1 (en) 2006-06-28
KR20070017099A (ko) 2007-02-08
CN101840718A (zh) 2010-09-22
JPWO2005036547A1 (ja) 2006-12-28
JPWO2005036546A1 (ja) 2006-12-28
EP1944771A3 (en) 2010-01-06
KR100937792B1 (ko) 2010-01-20
EP1672637A1 (en) 2006-06-21
US20100260016A1 (en) 2010-10-14
EP1677302A1 (en) 2006-07-05

Similar Documents

Publication Publication Date Title
JP3825463B2 (ja) 記録媒体、再生装置、プログラム、再生方法。
KR101076198B1 (ko) 기록매체, 재생장치, 기록방법, 재생방법
JP4012563B2 (ja) 記録媒体、再生装置、プログラム、再生方法。
JP4117019B2 (ja) 記録媒体、再生装置、記録方法、再生方法
JP4091105B2 (ja) 記録媒体、再生装置、記録方法、再生方法
JP4091104B2 (ja) 記録媒体、再生装置、記録方法、再生方法

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20060620

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20060627

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20060629

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090707

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100707

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110707

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120707

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130707

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130707

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140707

Year of fee payment: 8

LAPS Cancellation because of no payment of annual fees