CN101702320B - 再现装置 - Google Patents

Abstract

BD-ROM的再现装置进行标题的再现和应用程序的执行，包括再现属于标题的AVClip的播放控制引擎(32)，控制在多个标题之间的分支的模块管理器(34)和执行一个以上的应用程序的BD-J模块(35)。BD-J模块(35)包括Java虚拟机(38)和应用程序管理器(36)，所述应用程序管理器(36)在1)任何一个应用程序都没有启动的状态，2)主程序终止的情况下，解释为标题执行终止而进行终止处理。模块管理器(34)在终止处理执行后，选择顶端菜单标题等的下一标题。

Description

再现装置

本申请是申请日为2004年10月12日、申请号为“200480029694.6”并且发明名称为“再现装置、程序、再现方法”的在中国递交的专利申请的分案申请。 

技术领域

本发明是属于同时执行数字化后的视频作品的再现和应用程序的执行的再现控制技术的技术领域的发明，本再现控制技术更深地涉及应用于民用的再现装置、程序中的情况下的应用技术。 

背景技术

视频业务有将数字化的视频作品和游戏应用程序收纳在一个包中进行销售的媒体组合的形式。该游戏应用程序若将游戏的出现人物作为角色(character)，并与数字化的视频作品的一部分同时执行，则通过基于视频再现和游戏执行两者的复合效应，视频作品的人气进一步提高。 

但是，应用程序有程度差，多多少少有漏洞。因潜在错误而使装置中断(black out)，这可能在个人计算机软件领域中“经常有”，但是在民用设备领域中不能不说是质量问题。由于可能涉及质量问题，所以各制造公司对于同时执行应用程序的进行和数字流再现的再现装置的实现没有信心(注：所谓中断是指装置的软件中断(freeze)而显示画面变为全暗的状态)。 

发明内容

本发明的目的是提供一种避免涉及质量问题，可同时执行应用程序的执行和数字流再现的再现装置。 

上述目的通过再现装置来实现。该再现装置进行标题的再现和应用程序的执行，其特征在于，包括：再现控制引擎部，再现属于标题的数字流；模块管理器，控制多个标题之间的分支；模块，执行一个以上的应用程序； 所述模块包含虚拟机部和应用程序管理器；所述应用程序管理器在一个以上的应用程序成为预定的状态时，解释为标题执行终止并进行终止处理；所述模块管理器在所述标题终止后，选择预定的标题。

在包含应用程序、但不包含数字流这样的标题终止时，也可进行分支到预定的标题的控制。由此，即使应用程序出错终止，或应用程序的启动失败，也可保证协调的控制。 

由于有这样的控制，所以对于对涉及质量问题很敏感的制造公司而言，可以有力推进同时执行流再现和应用程序执行的再现装置的开发。通过这种有力推进，若再现装置的低价化、多样化发展，则可以实现BD-ROM内容的充实，所以可以有力推进内容相关产业的发展。 

附图说明

图1是表示本发明的再现装置的使用行为方式的图； 

图2是表示BD-ROM中的文件·目录结构的图； 

图3是表示AVClip时间轴和PL时间轴的关系的图； 

图4是表示通过4个Clip_Information_file_name进行的统一指定的图； 

图5是表示基于PLmark的章定义的图； 

图6是表示SubPlayItem时间轴上的再现区间定义和同步指定的图； 

图7(a)是表示Movie对象的内部结构的图； 

图7(b)是表示BD-J对象的内部结构的图； 

图7(c)是表示Java应用程序的内部结构的图； 

图8(a)是表示在Jave归档文件中容纳的程序、数据的图； 

图8(b)是表示xlet程序的一例的图； 

图9(a)是表示顶端菜单、title#1、title#2的一系列标题的图； 

图9(b)是表示PlayList#1、PlayList#2的时间轴一致的时间轴的图； 

图10是表示包含主标题、在线购物标题、游戏标题三个标题的盘内容的图； 

图11是表示图10所示的三个标题的再现图像的一例的图； 

图12(a)是根据图10的虚线所示的隶属关系来将各应用程序的生存区间图表化的图； 

图12(b)是为规定图12(a)的生存区间而描述的应用程序管理表的一例的图； 

图13(a)是表示启动属性设定的一例的图； 

图13(b)是表示有来自其他应用程序的应用程序调用而开始启动的应用程序(application#2)的图； 

图14(a)、(b)是表示挂起(Suspend)为有意义的应用程序管理表、生存区间的一例的图； 

图15是表示启动属性可取的三种形态(Persistent、AutoRun、Suspend)和之前标题中的应用程序状态的三种形态(非启动、启动中、挂起(Suspend))可取的组合的图； 

图16是表示本发明的再现装置的内部结构的图； 

图17(a)是表示在本地存储器29上怎样识别BD-ROM上存在的Java应用程序的图； 

图17(b)是表示图17(a)的应用的图； 

图18是将由ROM24中存储的软件和硬件构成的部件置换为层结构来描述的图； 

图19是将基于展示引擎31～模块管理器34的处理的情况模式化的图； 

图20是将基于应用程序管理器36的处理的情况模式化的图； 

图21是表示工作存储器37～缺省操作管理器40的图； 

图22是表示基于应用程序管理器36的分支时的控制过程的图； 

图23是表示应用程序终止处理的处理过程的流程图； 

图24是模式表示了应用程序终止的过程的图； 

图25(a)是表示在PL时间轴上定义生存区间的应用程序管理表的图； 

图25(b)是根据图25(a)的应用程序管理表，来表示应用程序的生存区间的图； 

图26(a)表示基于PL时间轴设定的标题时间轴； 

图26(b)是表示基于主应用程序的生存区间决定的标题时间轴； 

图26(c)是表示基于多个应用程序的生存区间设定的标题时间轴的图； 

图27是表示标题再现时的应用程序管理器36的处理过程的流程图； 

图28(a)是表示通过BD-ROM实现的菜单等级的图； 

图28(b)是表示用于实现菜单等级的MOVIE对象的图； 

图29是将索引表和从索引表向各Movie对象的分支的情况模式化的图； 

图30(a)表示如图29(b)那样描述了索引表的情况下的分支； 

图30(b)是表示非AV系标题强制终止时的分支的图； 

图31是表示模块管理器34的处理过程的流程图； 

图32是表示基于应用程序管理器36的应用程序强制终止的动作例的图； 

图33是表示基于重放控制引擎32的PL再现过程的流程图； 

图34是表示角度切换、Skip Back、Skip Next的接收过程的流程图； 

图35是表示调用了Skip Back、Skip NextAPI时的处理过程的流程图； 

图36是表示基于展示引擎31的处理过程的细节的流程图； 

图37是表示SubPlayItem的再现过程的流程图； 

图38是表示第五实施方式的应用程序管理器36的处理过程的流程图； 

图39是表示数据管理表的一例的图； 

图40是表示BD-J对象假定的执行模块的图； 

图41(a)是表示本地存储器29中的Java归档文件生存的生存区间的图； 

图41(b)是表示为了规定图41(a)的Java归档文件生存区间而描述的数据管理表的图； 

图42是表示基于循环方式(carousel method)的Java归档文件嵌入的图； 

图43(a)是表示基于交叉(interleave)方式的AVClip嵌入的图； 

图43(b)是表示读入属性的三种类型的图； 

图44(a)是表示数据管理表的一例的图； 

图44(b)是表示基于图44(a)的数据管理表的分配的本地存储器29的存储内容的变迁的图； 

图45(a)是对比表示新旧再现装置中的本地存储器29的存储器规模的图； 

图45(b)是表示设置了读入优先级的数据管理表的一例的图； 

图46是表示基于应用程序管理器36的预装载控制的处理过程的图； 

图47(a)是表示规定了applicationID相同，但是读入优先级彼此不同的应用程序的数据管理表的一例的图；

图47(b)是基于图47(a)的数据管理表的分配的本地存储器29的存储内容的改变的图； 

图48(a)是表示描述为在应预装载的应用程序、应装载的应用程序上添加同一applicationID的数据管理表的一例的图； 

图48(b)是表示在存储器规模小的再现装置中的本地存储器29的存储内容的改变的图； 

图48(c)是表示在存储器规模大的再现装置中的本地存储器29的存储内容的改变的图； 

图49是表示基于根据数据管理表的应用程序管理器36的装载处理的处理过程的图； 

图50是表示基于当前的再现时刻到达应用程序q的生存区间的情况下的应用程序管理器36的处理过程的图； 

图51是将怎样进行基于Java虚拟机38的应用程序的读入的情况模式化的图； 

图52(a)是表示第七实施方式的BD-J对象的内部结构的图； 

图52(b)是表示播放列表管理表的一例的图； 

图52(c)是表示在分支目标分支目标标题的播放列表管理表中，存在再现属性设定为AutoPlay的PL的情况下，再现装置进行怎样的处理的图； 

图53(a)是表示设定为再现属性表示非自动再现的情况下的非AV系标题中的标题时间轴的图； 

图53(b)是表示再现属性设定为AutoPlay的非AV系标题的标题时间轴的图； 

图53(c)是表示在播放列表管理表中设定为再现属性表示“AutoPlay”，应用程序强制终止的情况的图； 

图53(d)是表示在播放列表管理表中设定为再现属性表示“AutoPlay”，主应用程序的启动失败的情况的图； 

图54是表示第七实施方式的应用程序管理器36的处理过程的图； 

图55是表示将通过播放列表管理表中设定为“再现属性＝AutoPlay”而进行怎样的再现的情况模式化的图； 

图56(a)、(b)是表示应用程序的处理和启动属性的关系的图； 

图57是将怎样进行基于第八实施方式的Java虚拟机38的应用程序的读入的情况模式化的图； 

图58(a)、(b)是表示第九实施方式的读入优先级的一例的图； 

图59(a)是表示添加了组属性的数据管理表的图； 

图59(b)是表示对于基于应用程序管理表的本地存储器29的访问的图； 

图60是表示应用程序管理表的分配单位的变化的图。 

具体实施方式

(第一实施方式) 

下面，说明本发明的再现装置的实施方式。首先，开始说明本发明的再现装置的实施方式中，使用行为方式。图1是表示本发明的再现装置的使用行为方式。图1中，本发明的再现装置是再现装置200，与电视机300、遥控器400共同形成家庭影院系统。 

该BD-ROM100用于向由再现装置200、遥控器300、电视机400形成的家庭影院系统供给视频作品。 

以上是本发明的再现装置的使用方式的说明。 

接着，说明作为本发明的再现装置的再现对象的记录媒体BD-ROM。通过BD-ROM，向家庭影院系统供给的盘内容由彼此可分支的多个标题构成。各标题由一个以上的播放列表和使用该播放列表的动态控制过程构成。 

所谓播放列表是指由一个以上的数字流和该数字流中的再现路径构成，是具有“时间轴”的概念的BD-ROM上的访问单位。由于包含以上的播放列表和动态控制过程，所以标题兼有数字流特有的时间轴的概念和计算机程序的性质。 

图2是表示BD-ROM中的文件·目录结构的图。该图中，BD-ROM在根目录下有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，00003.mpls)。 

CLIPINF目录中有添加了扩展符clpi的文件(00001.clpi，00002.clpi，00003.clpi)。 

STREAM目录中有添加了扩展符m2ts的文件(00001.m2ts，00002.m2ts，00003.m2ts)。 

BDAR目录中有添加了扩展符jar的文件(00001.jar，00002.jar，00003.jar)。可以看出通过以上的目录结构，在BD-ROM上配置了彼此不同类别的多个文件。 

该图中添加了扩展符m2ts的文件(00001.m2ts，00002.m2ts，00003.m2ts...)存储有AVClip。AVClip有MainClip、SubClip的类别。MainClip是通过对视频流、音频流、展示图形流、交互图形流这样的多个元素流进行多路复用来得到的数字流。 

SubClip是音频流、图形流、文本字幕流等相当于仅一个元素流时的数字流。 

添加了扩展符“clpi”的文件(00001.clpi，00002.clpi，00003.clpi...) 是分别一一对应于AVClip的管理信息。由于是管理信息，所以Clip信息具有AVClip中的流的编码形式、帧频、比特率、分辨率等信息和表示提示(cue)位置位置的EP_map。 

添加了扩展符“mpls”的文件(00001.mpls，00002.mpls，00003.mpls...)是存储播放列表信息的文件。播放列表信息是参考AVClip来定义播放列表的信息。播放列表由MainPath信息、PLMark信息、SubPath信息构成。 

MainPath信息由多个PlayItem信息构成。所谓PlayItem是指在一个以上的AVClip时间轴上，通过指定In_Time，Out_Time来定义的再现区间。通过配置多个PlayItem信息，来定义由多个再现区间构成的播放列表(PL)。图3是表示AVClip和PL的关系的图。第一级表示AVClip具有的时间轴，第二级表示PL具有的时间轴。PL信息包含PlayItem#1、#2、#3三个PlayItem信息，通过这些PlayItem#1、#2、#3的In_Time，Out_Time来定义三个再现区间。若排列这些再现区间，则定义了与AVClip时间轴不同的时间轴。其是第二级表示的PL时间轴。这样，通过PlayItem信息的定义，可以进行与AVClip不同的时间轴的定义。 

对于AVClip的指定原则上是一个，但是也可对多个AVClip统一指定。该统一指定通过PlayItem信息中的多个Clip_Information_file_name来进行。图4是表示通过4个Clip_Information_file_name来进行的统一指定的图。该图中，第一级～第四级表示4个AVClip时间轴(AVClip#1、#2、#3、#4的时间轴)，第五级表示PL时间轴。通过PlayItem信息具有的4个Clip_Information_file_name来指定这四个时间轴。由此，通过PlayItem具有的In_Time、Out_Time，来定义可择一再现的4个再现区间。由此，在PL时间轴上定义了由可切换的多个角度视频构成的区间(所谓的多角度区间)。 

PLmark信息是PL时间轴上将任意的区间指定为章节的信息。图5是表示基于PLmark的章节定义的图。该图中，第一级表示AVClip时间轴，第二级表示PL时间轴。图中的箭头pk1、2表示PLmark中的PlayItem指定(ref_to_PlayItem_Id)和一个时刻的指定(mark_time_stamp)。通过这些指定在PL时间轴上定义了三个章节(Chapter#1、#2、#3)。 

SubPath信息由多个SubPlayItem信息构成。SubPlayItem信息通过在 SubClip的时间轴上指定In_Time、Out_Time来定义再现区间。另外，SubPlayItem信息可以进行使SubClip时间轴上的再现区间与PL时间轴同步的同步指定，通过该同步指定，来使PL时间轴和SubPlayItem信息时间轴同步行进。图6是表示SubPlayItem时间轴上的再现区间定义和同步指定的图。该图中，第一级表示PL时间轴，第二级表示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信息和播放信息分类为“静态脚本(scenario)”。这是因为通过以上的Clip信息和播放列表信息，定义了作为静态再现单位的PL。以上，结束对静态脚本的说明。 

接着，说明“动态脚本”。所谓动态脚本是指动态规定AVClip的再现控制的脚本数据。所谓“动态”是指通过再现装置的状态变化和来自用户的键事件再现控制的内容变化。BD-ROM中，作为该再现控制的动作环境假定了两个模式。第一个是与DVD再现装置的动作环境极其类似的动作环境，是指令库的执行环境。第二个是Java虚拟机的动作环境。这两个动作环境中的第一个称作HDMV模式，第二个称作BD-J模式。由于有这两个动作环境，所以假定其中一个动作环境来描述动态脚本。将假定了HDMV模式的动态脚本称作Movie对象，通过管理信息来进行定义。另一方面，将假定了BD-J模式的动态脚本称作BD-J对象。 

首先，开始说明Movie对象。 

<Movie对象> 

Movie对象是“标题”的构成要素，存储在文件MovieObject.bdmv中。图7(a)是表示Movie对象的内部结构的图。Movie对象由包括属性信息、多个导航指令的指令串构成。 

属性信息包括：在PL时间轴中，进行了MenuCall(调用菜单)时， 表示是否想要MenuCall后的再现重新开始的信息(resume_intention_flag)；在PL时间轴上表示是否屏蔽了MenuCall的信息(menu call mask)；和表示是否屏蔽了标题搜索的信息(title_search_flag)。Movie对象可以兼有“时间轴”+“程序控制”两个性质，从而通过该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对象，存在有在下面的国际公开公报中记载的在先的技术。对于细节，要参考该国际公开公报。 

国际公开公报WO2004/074976 

终止以上对Movie对象的说明。接着说明BD-J对象。 

<BD-J对象> 

添加了扩展符BD-J的文件(00001.BD-J、00002.BD-J、00003.BD-J)构成BD-J对象。BD-J对象是在Java编程环境下描述的BD-J模式的动态脚本。图7(b)是表示BD-J对象的内部结构的图。如该图所示，BD-J对象由与Movie对象同样的属性信息、应用程序管理表构成。在具有属性信息方面，BD-J对象与Movie对象大致相同。与Movie对象不同的是BD-J对象没有直接描述指令。即，在Movie对象中，控制过程由导航指令来直接描述。与此相对，BD-J对象中，通过在应用程序管理表上定义以该标题为生存区间的Java应用程序，来间接规定控制过程。通过这种间接的规定，可以高效进行在多个标题中使控制过程公共的控制过程的公共化。 

图7(c)是表示Java应用程序的内部结构的图。该图中，应用程序由在虚拟机的堆(heap)区域(还称作工作存储器)上装载的一个以上的xlet程序构成。在该工作存储器中，一个以上的线程动作，由在工作存储器上装载的xlet程序和线程构成应用程序。以上是应用程序的构成。 

相当于该应用程序的实体的是在BDMV目录下的BDAR目录上存储的Java归档(archive)文件(00001.jar、00002.jar)。下面，说明Java归档文件。 

Java归档文件(00001.jar、00002.jar)是存储了构成Java应用程序的程序和数据的Java归档文件。图8(a)是表示由归档文件容纳的程序、数据的图。该图中的数据通过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归档文件中归纳为一个的文件中有xlet程序。 

Xlet程序是可利用JMF(Java Media Frame Work)接口的Java程序。 Xlet程序由接收键事件的EventListner等多个函数构成，根据JMF等的方式，来进行基于所接收的键事件的处理。 

图8(b)是表示xlet程序的一例的图。JMF A“BD://00001.mpls”是向Java虚拟机命令再现PL的播放器实例(player instance)的生成的方法。A.play是向JMF播放器实例命令再现的方法。该JMF播放器实例生成是基于JMF库(library)进行。Xlet程序的描述并不限于BD-ROM的PL，是可适用于具有时间轴的内容整体的JMF的描述。由于可以进行这种描述，所以可以督促擅长Java编程的软件进行BD-J对象的生成。 

图8(b)中的JumpTitle()是应用程序API的调用。该应用程序API向再现装置命令向其他标题的分支(图中是title#1)。这里所谓应用程序API是指通过BD-ROM再现装置供给的API(Appliation Interface)。除了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构成。这里举出一例的是如图9(a)这样的标题。该标题是顶部菜单→title#1→title#2→顶部菜单、顶部菜单→title#3→顶部菜单的一系列的标题。这些标题中，若title#1命令PlayList#1、PlayList#2的再现，title#2命令PlayList#3的再现，title#3 指令PlayList#4的再现，则如图9(b)那样，title#1具有将PlayList#1、PlayList#2的时间轴相加的时间轴。同样，title#2具有由PlayList#3时间轴构成的时间轴，PlayList#3具有由PlayList#4时间轴构成的时间轴。在这些标题时间轴的PL时间轴上保证了无缝再现，但是在标题时间轴间不需要保证无缝再现。每次Java应用程序动作时，必需将可以在虚拟机的工作存储器上存在Java应用程序的期间(服务期间)定义在这样的标题时间轴上。在BD-J模式中，每次Java应用程序动作时，必需在彼此互相分支的时间轴上定义Java应用程序的服务期间。该服务期间的定义是每次进行面向BD-J的编程时的注意点。 

最后，说明index.bdmv中所存储的IndexTabel。IndexTable是使标题号、Movie对象、BD-J对象对应的表，是在从动态脚本向动态脚本分支时所参考的间接参考用表。IndexTable由分别对多个标签的Index构成。各Index描述了对应于该标签的动态脚本的识别符。通过参考这种IndexTable，可以实现分支，而不用严格区分Movie对象、BD-J对象的不同。对于IndexTable其细节记载在下面的国际公开公报中。对于细节要参考该公报。 

国际公开公报WO2004/025651A1公报 

以上是对BD-ROM上记录的文件的说明。 

<应用程序管理表> 

具有JMF播放器实例、JumpTitleAPI调用的应用程序规定标题时间轴的情况如上那样，但是在标题时间轴上使不具有JMF播放器实例、JumpTitleAPI调用的其他应用程序动作的情况下，明确规定从时间轴的何处开始基于应用程序的服务，在时间轴的何处终止基于应用程序的服务的“服务开始点·终止点”很重要。在本实施方式中，将开始基于应用程序的服务后到终止定义为“应用程序的生存”。用于定义应用程序的生存的信息存在于BD-J对象的应用程序管理表中。之后更详细地说明应用程序管理表。 

应用程序管理表(AMT)是在各标题具有的标题时间轴中，表示在虚拟机的工作存储器上可生存的应用程序的信息。所谓工作存储器中的生存是指可向工作存储器读出构成该应用程序的xlet程序，并进行基于虚拟机的执行的状态。图7(b)中的虚线箭头at1展开(closeup)表示应用程序管理表的内部结构。如该内部结构所示，应用程序管理表由“生存区间”、 表示将该标题作为生存区间的应用程序的“applicationID”和该应用程序的“启动属性”构成。 

在不久的将来，将要实施的盘内容选作题材，而掺杂具体例来说明应用程序管理表中的生存区间描述。这里作为题材的盘内容包含构成主视频的主标题(title#1)、构成在线购物的在线购物标题(title#2)、构成游戏应用程序的游戏标题(title#3)这三个特性不同的标题。图10表示包含主标题、在线购物标题、游戏标题三个标题的盘内容的图。在该图中的右侧描述了IndexTable，左侧描述了三个标题。 

右侧的虚线框表示各应用程序属于哪个标题的隶属关系。三个标题中，title#1由application#1、application#2、application#3三个应用程序构成。title#2包含application#3、application#4两个应用程序，title#3包含application#5。图11是表示图10所示的三个标题的再现图像的一例的图。在这三个标题的再现图像中，在图11(a)、(b)的主标题、在线购物标题上存在以购物车为基础的影像(车cr1)1，在图11(c)的游戏标题上不存在车影像。由于车cr1需要在主标题、在线购物标题中公共显示，所以在title#1、title#2两者中启动作为车应用程序的application#3。这种多个标题中启动的应用程序上除了上述的车应用程序之外，还有根据模仿视频作品中出现的MASCOT(自动过程计算机操作测试)的代理应用程序、菜单调用操作来进行菜单显示的菜单应用程序。 

若根据图10的虚线所示的隶属关系来将各应用程序的生存区间图表化，则变为如图12(a)。该图中，横轴表示标题时间轴，纵轴方向上配置了各应用程序的生存区间。这里由于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的应用程序管理表变为如图12(b)所示。若这样来描述应用程序管理表，则在title#1的再现开始时，将application#1、application#2、application#3装载在工作存储器中。并且，在title#2开始时，进行从工作存储器中删除application#1、application#2，仅设为 application#3的控制。与此相同，在title#2的开始时，进行将application#4装载在工作存储器中，在title#3的开始时，进行从工作存储器中删除application#3、application#4的控制。 

进一步，进行在title#3的再现中，将application#5装载在工作存储器中，并在title#3的再现终止时，从工作存储器中删除application#5的控制。 

由于在有标题间分支的情况下，将在分支源-分支目标中生存的应用程序存储在工作存储器上，将仅在分支目标而不在分支源存在的应用程序读入到工作存储器中就可以，所以将应用程序读入到工作存储器的次数为必要最低次数。这样，通过减小读入次数，可以实现不会意识到标题的边界的应用程序，即，无边际的应用程序。 

接着说明应用程序的启动属性。启动属性有表示自动的启动的“AutoRun”、表示不是自动启动的对象，但是也可放在虚拟机的工作存储器上的“Persistent”、虽然放在虚拟机的工作存储器上，但是不能进行CPU功率的分配的“Suspend”。 

“AutoRun”是与对应的标题的分支一起将该应用程序读入到工作存储器中，且表示执行的内容的生存区间。若存在从某个标题向其他标题的分支，则进行应用程序管理的管理主体(应用程序管理器)将在该分支目标标题中生存，且启动属性设定为AutoRun的应用程序向虚拟机的工作存储器的读入来进行执行。由此，该应用程序与标题分支一起来自动启动。作为将启动属性设定为AutoRun的应用程序，可举出具有JMF播放器实例和JumpTitleAPI调用这样的应用程序。这是因为这种应用程序是规定标题时间轴侧的应用程序，若不自动启动这种应用程序，标题时间轴的概念不清。 

启动属性“Persisten”是继续属性，表示继续分支源标题中的应用程序的状态。另外，是表示也可装载在工作存储器中的属性。在启动属性是“Persistent”的情况下，添加了该启动属性的应用程序允许来自其他应用程序的调用。进行应用程序管理的管理主体(应用程序管理器)若从启动中的应用程序有调用，则将该应用程序的applicationID描述在应用程序管理表中，并判断启动属性是否是“Persistent”。若是“Persistent”，则将该应用程序装载在工作存储器中。另一方面，在没有将该调用目标应用程序的applicationID描述在应用程序管理表上的情况下，不将该应用程序装载在工 作存储器中。基于应用程序的调用限于添加了该“Persistent”的应用程序。 

由于“Persistent”是没有明示指定启动属性的情况下所添加的缺省的启动属性，所以在某个应用程序的启动属性是无指定“--”的情况下，是指该应用程序的启动属性是该Persistent。 

说明这些启动属性在图11的应用程序中怎样描述。图13是对于图12的三个应用程序的启动属性的设定例。图12所示的三个应用程序中application#2如图13(b)所示，设为有来自其他应用程序的应用程序调用、并开始启动的应用程序。与其余的application#1、application#3是与title#1的开始同时自动启动的应用程序。这时，如图13(a)所示，将应用程序管理表中的各应用程序的启动属性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对例如在游戏标题的执行中，经过旁路(sidepass)的处理有意义。图14(a)(b)是表示Suspend有意义的事例的图。如图14(b)所示，有三个标题(title#1、title#2、title#3)，其中title#1、title#3执行游戏应用程序，但是中间的title#2是旁路，用来实现视频再现。在旁路中，由于需要实现视频再现，所以使游戏的执行中断。由于在游戏应用程序中计数了过程中的分数等，所以要在title#2的前后维持资源的存储植。这时，描述应用程序管理表，使其在title#2的开始时刻挂起游戏应用程序，在title#3的开始时刻重新开始application#2。由此，由于在title#2中，application#2分配了资源，所以维持了资源的存储植。但是，由于是没有分配CPU功率的状态，所以不会通过虚拟机来执行application#2。由此， 在游戏标题的执行中，实现了执行旁路的处理。 

图15是表示启动属性可取的三种形态(Persistent、AutoRun、Suspend)和最近前面的标题中的应用程序状态的三种形态(非启动、启动中、Suspend)可取的组合的图。在最近前面状态是“非启动”的情况下，若启动属性是“AutoRun”，则在分支目标标题中，启动该应用程序。 

若最近前面状态是“非启动”，启动属性为“Persistent”、“Suspend”，则分支目标标题中，其应用程序什么都不做，继续状态。 

在最近前面状态是“启动中”的情况下，若启动属性为“Persistent”、“Suspend”，则分支目标标题中，其应用程序什么都不做，继续状态。 

若启动属性为“Suspend”，则应用程序的状态为挂起。在最近前面状态为“Suspend”的情况下，若分支目标标题的启动属性是“Suspend”，则维持挂起。若为“Persistent”、“AutoRun”，则在分支目标标题中，重新开始该应用程序。通过在应用程序管理表中定义生存期间和启动属性，沿着标题时间轴的行进，可以进行使Java应用程序动作的同步控制，可以特别送出伴随视频再现、应用程序执行的各种应用程序。以上是对于记录媒体的说明。接着说明本发明的再现装置。 

图16是表示本发明的再现装置的内部结构的图。本发明的再现装置根据该图所示的内部结构来进行工业生产。本发明的再现装置主要由系统LSI和驱动装置的两个部件构成，通过将这些部件安装在装置的壳体和基板上来可进行工业生产。系统LSI是集成了实现再现装置的功能的各种处理部的集成电路。这样生产的再现装置由BD-ROM驱动器1、读缓存器2、多路分配器3、视频译码器4、视频平面5、P-Graphics译码器9、展示图形平面10、合成部11、字体生成器12、I-Graphics译码器13、开关14、交互图形平面15、合成部16、HDD17、读缓存器18、多路分配器19、音频译码器20、脚本(scenario)存储器21、CPU22、键事件处理部23、指令ROM24、开关25、CLUT部26、PSR组28、本地存储器29构成。 

BD-ROM驱动器1进行BD-ROM的装载/注入，执行对于BD-ROM的访问。 

读缓存器2是FIFO存储器，以先入先出方式存储从BD-ROM中读出的TS包。 

多路分配器(De-MUX)3从读缓存器2中取出TS包，并将构成该TS包的TS包转换为PES包。并且，将通过转换得到的PES包中具有由CPU22设定的PID的包输出到视频译码器4、音频译码器20、P-Graphics译码器9和I-Graphics译码器13中之一。 

视频译码器4解码从多路分配器3输出的多个PES包后得到非压缩形式的图像，并写入到视频平面5上。 

视频平面5是用于存储非压缩形式的图像的平面。所谓平面是指在再现装置中存储一个画面的象素数据用的存储器区域。在再现装置上设置多个平面，按每个象素来相加这些平面的存储内容，进行视频输出时，可以在合成多个视频内容之后，进行视频输出。视频平面5中的分辨率为1920×1080，在该视频平面5上存储的图像数据由以16比特的YUV值表现的象素数据构成。 

P-Graphics译码器9对从BD-ROM、HDD17中读出的展示图形流进行译码，并将非压缩图形写入到展示图形平面10中。通过图形流的译码，在画面上表现字幕。 

展示图形平面10是具有一个画面的区域的存储器，可以存储一个画面的非压缩图形。本平面的分辨率是1920×1080，展示图形平面10中的非压缩图形的各象素用8比特的索引彩色来表示。通过使用CLUT(Color LookupTable)来转换该索引彩色，来将在展示图形平面10中存储的非压缩图形供给显示。 

合成部11将非压缩状态的图像数据(i)与展示图形平面10的存储内容合成。 

字体生成器12使用文字字体，将textST流中包含的文本码展开为位图。 

I-Graphics译码器13对从BD-ROM或HDD17中读出的交互图形流进行译码，并将非压缩图形写入到交互图形平面15上。 

开关14是将字体生成器12生成的字体串、通过P-Graphics译码器9的译码得到的图形中的某一个有选择地写入到展示图形平面10的开关。 

交互图形平面15写入基于I-Graphics译码器13进行的译码得到的非压缩图形。 

合成部16合成交互图形平面10的存储内容和作为合成部8的输出的 合成图像(合成了非压缩状态的图像数据和展示图形平面7的存储内容的内容)。 

HDD17是存储了经网络等下载的SubClip、Clip信息、播放列表信息的内置媒体。在该HDD17中的播放列表信息即使是存在于BD-ROM和HDD17的其中之一的Clip信息，在可以进行指定的方面不同。每次该指定时，HDD17上的播放列表信息不需要通过全路径(full path)指定BD-ROM上的文件。这是因为本HDD17与BD-ROM为一体，作为虚拟的一个驱动器(称作虚拟包)，通过再现装置来识别。因此，PlayItem信息中的Clip_Information_file_name和SubPlayItem信息的Clip_Information_file_name，通过指定相当于存储了Clip信息的文件的文件主体的5位数值，可以指定HDD17、BD-ROM上的AVClip。通过读出该HDD的记录内容，并与BD-ROM的记录内容动态组合，可以产生各种不同的再现。 

读缓冲器18是FIFO存储器，以先入先出的形式来存储从HDD17读出的TS包。 

多路分配器(De-MUX)19从读缓存器18取出TS包，并将TS包转换为PES包。并且，将通过转换得到的PES包中具有希望的streamPID的包输出到字体生成器12中。 

音频译码器20对从多路分配器19输出的PES包进行译码，并输出非压缩形式的音频数据。 

脚本存储器21是用于存储当前的PL信息和当前的Clip信息的存储器。所谓当前PL信息是指BD-ROM中记录的多个PL信息中作为当前处理对象的信息。所谓当前Clip信息是指在BD-ROM中记录的多个Clip信息中，作为当前处理对象的信息。 

CPU22执行在指令ROM24中存储的软件，并执行再现装置整体的控制。 

键事件处理部23根据对于遥控器和再现装置的前面板的键操作，输出进行该操作的键事件。 

指令ROM24存储规定再现装置的控制的软件。 

开关25是将从BD-ROM和HDD17读出的各种数据有选择地输入到读 缓存器2、读缓存器18、脚本存储器21、本地存储器29中某一个的开关。 

CLUT部26将视频平面5中存储的非压缩图形中的索引彩色转换为Y，Cr，Cb值。 

CLUT部27将交互图形平面15中存储的非压缩图形中的索引彩色转换为Y，Cr，Cb值。 

PSR组28是内置在再现装置中的寄存器，由64个播放器状态寄存器(PSR)和4096个通用寄存器(GPR)构成。播放器状态寄存器的设定值(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～0xFFFFFFFF的值，而使用45KHz的时间精度来表示当前的再现时刻(当前PTM(Presentation Time))。通过以上的PSR4～PSR8，来确定当前的再现时刻。 

本地存储器29由于从BD-ROM的读出为低速，所以是用于暂时存储BD-ROM的记录内容的高速缓存器。因存在该本地存储器29，可以使BD-J模式中的应用程序执行高效。图17(a)是表示在本地存储器29上怎样识别BD-ROM中存在的Java归档文件的图。图17(a)的表中，在左栏表示BD-ROM上的文件名，在右栏表示本地存储器29上的文件名。若比较这些右栏、左栏，可以看出通过省去目录指定“BDJA”的文件路径来指定本地存储器29中的文件。 

图17(b)是表示图17(a)的应用的图。本应用例以头+数据的形式存储文件中所存储的数据。将本地存储器9中的文件路径用于头。如图17(b)所示，由于在本地存储器29中将省略了BD-ROM中的文件路径的一部分的内容用于文件路径，所以通过将该文件路径存储在头中，可以明确 各数据在BD-ROM中的位置。 

以上是本实施方式的再现装置的硬件结构。接着，说明本实施方式中的再现装置的软件结构。 

图18是将由ROM24中存储的软件和硬件构成的部分转换为层结构来描述的图。如该图所示，再现装置的层结构由下面的a)、b)、c)、d-1)、d-2)、e)、f)构成。即，在a)物理的硬件等级上存在b)控制基于AVClip的再现的展示引擎31、和c)进行基于播放列表信息和Clip信息的再现控制的重放控制引擎32的这两个等级，在最上层的等级上有e)执行标题间的分支的模块管理器34。 

在这些HDMV模块33、模块管理器34之间，d-1)作为Movie对象的译码·执行主体的HDMV模块33、和d-2)进行BD-J对象的译码·执行的BD-J模块35放在同一等级上。 

BD-J模块35是所谓的Java平台，为包含工作存储器37的Java虚拟机38为核心的结构，由应用程序管理器36、事件监听管理器(event listnermanager)39、缺省操作管理器40构成。首先，最先说明展示引擎31～模块管理器34。图19是将基于展示引擎31～模块管理器34的处理模式化的图。 

展示引擎31执行AV再现功能。所谓再现装置的AV再现功能是指从DVD播放器、CD播放器继承的传统的功能群，是再现开始(Play)、再现停止(Stop)、暂时停止(Pause ON)、暂时停止的解除(Pause Off)、静止功能的解除(Still off)、带速度指定的快进(Forward Play(speed))、带速度指定的倒带(Backward Play(speed))、声音切换(Audio Change)、副视频切换(Subtitle Change)、角度切换(Angle Change)的功能。为实现AV再现功能，展示引擎31控制视频译码器4、P-Graphics译码器9、I-Graphics译码器13和音频译码器20，以进行读出到读缓存器2上的AVClip中相当于希望时刻的部分的译码。作为希望的时刻，通过进行PSR8(当前PTM)所示的位置的解释，在AVClip中，可以再现任意的时刻。图中的◎1将基于展示引擎31的译码开始模式化来进行表示。 

再现控制引擎(Playback Control Engine(PCE))32执行播放列表的再现功能(i)、再现装置中的状态取得/设定功能(ii)的各功能。所谓PL的 再现功能是指根据当前PL信息和Clip信息来进行展示引擎31进行的AV再现功能中的再现开始和再现停止。根据来自用DMV模块33～BD-J模块35的应用程序调用来执行这些功能(i)～(ii)。即，再现控制引擎32根据基于用户操作的指示、来自层模块中的上层位置的指示，来执行自身的功能。图19中，带◎2◎3的箭头将重放控制引擎32对Clip信息和播放列表信息的参考模式化来表示。 

HDMV模块33是MOVIE模式的执行主体，若从模块管理器34通知构成分支目标的Movie对象，则将构成分支目标标题的Movie对象读出到本地存储器29中，并对在该Movie对象中描述的导航指令进行译码，根据译码结果来执行对重放控制引擎32的应用程序调用。图19中带 

2、 3、 

4的箭头，将来自模块管理器34的分支目标Movie对象的通知(2)、Movie对象中描述的导航指令的译码(3)、对于重放控制引擎32的应用程序调用(4)模式化来表示。 

模块管理器34保持从BD-ROM中读出的索引表，并进行分支控制。该分支控制在HDMV模块33执行JumpTitle指令的情况下，或从BD-J模块35调用标题跳转API的情况下，接收作为该跳转目标的跳转号，并向HDMV模块33或BD-J模块35通知构成该标题的Movie对象或BD-J对象。图中的带 

0、 

1、 

2的箭头将JumpTitle指令的执行(0)、模块管理器34进行的IndexTable参考(1)和分支目标Movie对象(2)的通知模式化来表示。 

以上是对展示引擎31～模块管理器34的说明。接着，参考图20来说明应用程序管理器36。图20是表示应用程序管理器36的图。 

应用程序管理器36执行参考了应用程序管理表的应用程序的启动控制、执行标题正常终止时的控制。

所谓启动控制是指在每次从模块管理器34通知作为分支目标的BD-J模块时，读出该BD-J对象，并参考该BD-J对象内的应用程序管理表来进行本地存储器29访问。并且，所谓启动控制是将构成把当前的再现时刻作为生存区间的应用程序的xlet程序读出到工作存储器的控制。图20中的☆1、☆2、☆3将启动控制中的分支目标BD-J对象的通知(1)、应用程序管理表参考(2)、对于Java虚拟机38的启动指示模式化来表示。通过该启动 指示，Java虚拟机38从本地存储器29读出xlet程序到工作存储器37(☆5)。 

标题的终止控制有正常终止时的控制和异常终止时的控制。正常控制时的控制，有通过构成标题的应用程序来调用跳转标题API、并向分支控制的主体(模块管理器34)请求向分支目标标题的切换的控制。该终止控制中的将模块管理器34通知模式化表示的是箭头☆6。这里，每次正常终止标题时，也可原样启动构成标题的应用程序。这是因为在分支目标标题中判断是否终止应用程序。在本实施方式中虽然没有较深地涉及到，但是应用程序管理器36进行从BD-ROM向本地存储器29读出Java归档文件(8)的处理。将向该本地存储器29的读出模式化的是☆8。 

以上是对应用程序管理器36的说明。接着，参考图21来说明工作存储器37～缺省操作管理器40。 

工作存储器37是配置了构成应用程序的xlet程序的群区域。工作存储器37本来存在于Java虚拟机38内，但是在图21中，为了作图的方便，在Java虚拟机38上层位置描述工作存储器37。工作存储器37上的xlet程序包含EventListner和JMF播放器实例。 

Java虚拟机38将构成应用程序的xlet程序装载在工作存储器37上，对xlet程序进行译码，来执行基于译码结果的处理。如上所述，由于xlet程序包含命令JMF播放器实例生成的方法和命令该JMF播放器实例的执行的方法，所以为了实现通过这些方法命令的处理内容，进行对于下层的控制。若命令JMF播放器实例生成，则Java虚拟机38得到与BD-ROM上的YYYY.MPLS文件相关的JMF播放器实例。另外，若指令JMF播放器实例中的JMF方法的执行，则向BD中间件发出该JMF方法，并置换为BD再现装置对应的应用程序调用。并且，向重放控制引擎32发出置换后的应用程序调用。 

事件监听管理器39分析通过用户操作生成的事件(键事件)，并进行事件的分配。图中的实线箭头◇1、◇2将基于该事件监听管理器39的分配进行模式化来表示。若是SRART、STOP、SPEED等在xlet程序内的EventListner上登记的键事件，则分配通过BD-J对象间接参考的有关xlet程序的事件。START、STOP、SPEED是对应于JMF的事件，由于在xlet程序的 Event Listner上登记了这些键事件，所以通过本键事件可以进行xlet程序的启动。在键事件是Event Listner未登记的键事件的情况下，将本键事件分配给缺省操作管理器40。这是因为声音切换、角度切换等BD-ROM再现装置中产生的键事件上存在没有在Event Listner上登记的各种事件，即使产生了这些键事件，也执行没有遗漏的处理。 

缺省操作管理器40若从事件监听管理器39分配没有在xlet程序内的Event Listner上登记的键事件，则对重放控制引擎32执行对应于该EventListner未登记事件的应用程序调用。模式化地表示基于该缺省操作管理器40的应用程序调用是图中的箭头◇3。另外，虽然图21中通过事件监听管理器39、缺省操作管理器40来分配Event Listner未登记事件，但是也可以由重放控制引擎32直接接收EventListner未登记事件，来进行再现控制(图中的◇4)。 

(流程图的说明) 

以上的对于应用程序管理器36的说明不过是涉及其概要。更详细地表示应用程序管理器36的处理的是图22、图23的流程图。之后，参考这些流程图来更详细说明应用程序管理器36的处理过程。 

图22是表示基于应用程序管理器36的分支时的控制过程的图。本流程图是启动或终止满足步骤S2～步骤S5构成的条件的应用程序(是指应用程序x)的处理。 

步骤S2中判断是否存在应用程序x，该应用程序x虽然在分支源标题中为非启动、但在分支目标标题中生存、且分支目标标题中的启动属性是AutoRun属性，并且若存在该应用程序x，则进行对于本地存储器29的高速缓存传感。若高速缓存传感的结果，在本地存储器29上有应用程序x(步骤S7中”是”)，则从本地存储器29向工作存储器37读入应用程序x(步骤S8)。若本地存储器29中没有，则从BD-ROM向本地存储器29读入应用程序x后，从本地存储器29向工作存储器37读入应用程序x(步骤S9)。 

步骤S3中判断是否存在分支源标题中为启动中、且在分支目标标题中非生存的应用程序x。若存在，则从工作存储器37中删除应用程序x后终止(步骤S10)。 

步骤S4中判断是否存在分支源Suspend、分支目标AutoRun或Persistent 的应用程序。若存在，则重新开始应用程序x(步骤S11)。 

步骤S5中判断是否存在在分支源标题中为启动中、且分支目标Suspend的应用程序。若存在，则挂起应用程序x(步骤S12)。 

每次各应用程序终止时的应用程序管理器36的处理如图23所示。图23是表示应用程序终止处理的处理过程的流程图。该图示出分别对于应终止的多个应用程序重复进行步骤S16～步骤S20的处理的循环处理(步骤S15)。在本循环处理中，应用程序管理器36发出要终止启动中应用程序的终止事件(步骤S16)，进行定时器设置(步骤S17)，并进入到由步骤S18～步骤S20构成的循环处理。若Event Listner接收到该终止事件，则对应的xlet程序启动终止处理。若终止处理终止，则从工作存储器37中释放该xlet程序，并终止。 

在步骤S18～步骤S20的循环处理的继续中，定时器持续计数。在本循环处理中，步骤S18是发送目标应用程序是否终止的判断，若已终止，则终止对该应用程序的处理。步骤S19是定时器是否超时的判断，若超时，则在步骤S20中，从工作存储器37中删除发送目标应用程序来强制终止应用程序。 

参考图24来说明以上的模块管理器34的处理。 

图24是模式地表示应用程序终止的过程的图。该图中的第一级表示应用程序管理器36，第二级表示三个应用程序。图24的第二级、左侧的应用程序表示接收终止事件后，终止处理成功的应用程序。图24的第二级、中间的应用程序表示接收终止事件后，终止处理失败的应用程序。第二级、右侧的应用程序由于没有安装EventListner，故表示不能接收终止事件的应用程序。 

第一级-第二级的箭头ep1、ep2模式地表示基于应用程序管理器的终止事件发送，箭头ep3模式地表示终止处理启动。 

第三级是终止处理成功时的状态转移后的状态，该应用程序通过本身的终止处理来终止。若存在如这些xlet程序那样，在预定期间内有没有终止的应用程序，则应用程序管理器36从工作存储器37中强制去除这些。第四级表示基于应用程序管理器36的强制终止。规定该第四级的强制终止也是应用程序管理器36的一个任务。 

如上所述，根据本实施方式，由于自动终止在分支源标题中启动并在分支目标标题中不生存的应用程序，所以即使在通过带条件的分支再现复杂地进行的情况下，不会进行超过再现装置的资源的界限的数目的应用程序启动。由于可以保证分支前后的应用程序动作，所以可以更多地发布边再现数字流边执行应用程序的盘内容。 

(第二实施方式) 

第一实施方式中应用程序的生存区间与标题时间轴一致，但是第二实施方式提出了将PL时间轴的一部分作为应用程序的生存区间的方案。由于PL时间轴的一部分通过章节来表现，所以通过由章节来描述开始点、终止点，可以规定应用程序的生存区间。图25(a)是表示在PL时间轴上规定生存区间的应用程序管理表的图。图25(a)中，在应用程序管理表中描述了三个应用程序，其中application#2将title#1的Chapter#2到Chapter#3指定为生存区间，并在启动属性上规定了AutoRun。因此，application#2如图25(b)所示，在Chapter#2的起点启动，并在Chapter#3的终点终止。 

另一方面，application#3将title#1的Chapter#4到Chapter#6指定为生存区间。因此，application#3如图25(b)所示，在Chapter#4的起点启动，在Chapter#6的终点终止。 

为了根据这样描述的应用程序管理表进行处理，本实施方式的应用程序管理器36在每次达到通过Plmark指定的章节起始点时，判断是否存在生存区间从该章节起始点开始的应用程序，若存在，则将该应用程序装载到工作存储器37中。 

同样，在每次到达章节起始点时，判断在该章节最近前面的章节中是否存在生存区间终止的应用程序，若存在，则从工作存储器37中释放该应用程序。 

若以章节为单位来管理应用程序的生存，则可以以更精细的精度来指定应用程序的生存区间。但是，必须注意在盘内容上可以有时间轴的反向。所谓反向是指通过倒带使时间轴反向行进。若在章节的边界重复进行该反向和行进，则几次进行向工作存储器的装载、废弃，产生了多余的读出负载。因此，在本实施方式中，应用程序的启动时期为进入标题而开始基于重放控制引擎32的通常再现的瞬间。这里PL的再现有通常再现、技巧 (trick)再现。所谓技巧再现有快进、倒带、跳下一个(SkipNext)、跳上一个(SkipBack)。在进行该快进、倒带、SkipNext、SkipBack的期间，不开始应用程序启动，而开始通常再现后，开始启动应用程序。在通过以通常再现开始的瞬间为基准，有如上所述的生存区间前后的到来的情况下，不需要重复需要以上的应用程序的启动。另外，也可在生存区间为title的情况下，执行将通常再现开始的瞬间作为应用程序的启动基准的处理。 

如上所述，根据本实施方式，由于可以以比PL小的章节为单位来规定应用程序的生成区间，所以可以实现精细的应用程序控制。

(第二实施方式的变形例) 

图25中，向各应用程序添加优先级。该优先级取0～255的值，在应用程序之间资源的使用冲突等冲突了的情况下，每次应用程序管理器36进行将使其中一个应用程序强制终止，或从其中一个应用程序争夺资源的处理时，上述优先级的值成为判断材料。图25的一例中，由于application#1的优先级为255，application#2、application#3的优先级为128，所以在application#1-application#2冲突时，应用程序管理器36进行强制终止优先级低的application#2的处理。 

(第三实施方式) 

由BD-ROM供给的盘内容由可彼此分支的多个标题构成。各标题除了由一个以上的PL和使用该PL后的控制过程构成之外，有仅由对再现装置的控制过程构成的非AV系标题。本实施方式说明该非AV系标题。 

在这种非AV系标题中，问题为怎样来决定标题时间轴。图26(a)表示从PL时间轴决定的标题时间轴。这时PL时间轴为标题时间轴，在该标题时间轴上决定应用程序的生存区间。在没有作为该基准的PL时间轴的情况下，标题时间轴应如图26(b)、(c)那样来决定。 

图26(b)表示从主要的应用程序的生存区间决定的标题时间轴。所谓主应用程序是指在标题中将启动属性设定为AutoRun，在标题开始时自动启动的唯一的应用程序，例如，称作启动应用程序的程序相当于此。所谓启动应用程序是指启动其他应用程序的应用程序。 

该图26(b)的考虑认为只要主应用程序启动，标题时间轴就继续，若主应用程序终止，则使时间轴终止。图26(c)是表示从多个应用程序的生 存区间决定的标题时间轴的图。有这样的情况：在标题的开始点启动的是一个应用程序，但是该应用程序重复进行调用其他应用程序，进一步该应用程序调用其他应用程序的处理。这时，只要其中一个应用程序启动，就认为标题时间轴持续，若任何一个应用程序都没有启动的状态到来，则由此认为标题时间轴终止。这样，若决定非AV系统标题的标题时间轴，无论是AV标题还是非AV系统标题，都可以与标题时间轴的终止同时划一地进行分支到预定的标题的处理。另外，非AV标题中的标题时间轴在与AV标题对比时，不过是假定的想象的时间轴。因此，再现装置可以在非AV标题中的标题时间轴上逆行或定位到任意的位置。 

以上是对于本实施方式中的记录媒体的改进。接着，说明对于本实施方式中的再现装置的改进。 

为了以如上所述的过程来进行标题终止，第三实施方式的应用程序管理器36以如图27所示的处理来进行处理。图27是表示标题再现时的应用程序管理器36的处理过程的流程图。本流程图中为在标题再现中，重复步骤S21～S23的循环结构。 

步骤S21中判断是否调出了标题跳转API，若调出，则向模块管理器34请求向跳转目标标题的分支(步骤S27)。 

步骤S22中判断是否存在承担标题内的应用程序调用这样的主应用程序，若存在，则确认其启动的有无(步骤S25)。若没有启动，则解释为“标题的终止”，向模块管理器34通知终止(步骤S26)。 

步骤S23是没有主应用程序的情况下执行的步骤(步骤S22中”否”)，判断是否为没有启动任何应用程序的状态。若是，则同样解释为“标题的终止”，而向模块管理器34通知终止(步骤S26)。 

如上所述，根据本实施方式，即使是不伴随PL再现的标题，也可进行在应用程序执行中不进行分支，在应用程序执行终止后进行分支的处理。 

(第四实施方式) 

本实施方式涉及在BD-ROM上实现与DVD相同的菜单控制的情况的改进。图28(a)是表示通过BD-ROM实现的菜单等级的图。该图中的菜单等级在最上层配置TopMenu，可以从该TopMenu选择下层的TitleMenu、SubTitleMenu、AudioMenu的结构。图中的箭头sw1、2、3模式地表示基 于按钮选择的菜单的切换。所谓TopMenu是指配置了接收进行声音选择、字幕选择、标题选择中之一的按钮(图中的按钮sn1、sn2、sn3)的菜单。 

所谓TitleMenu是指配置了接受选择视频作品(title)的电影版、选择导演的剪辑(director’s cut)版或选择游戏版等视频作品的选择的按钮的菜单。所谓AudioMenu是指配置了接受用日语或用英语进行声音再现的按钮的菜单，所谓SubTitleMenu是指配置了接受用日语或用英语进行字幕显示的按钮的菜单。 

图28(b)表示用于使具有这种等级的菜单动作的MOVIE对象。图28(b)中在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对象。 

图29是模式化了索引表和从索引表向各Movie对象的分支的图。该图 中左侧表示索引表的内部结构。在本实施方式的索引表中包含FirstPlayINDEX、TopMenuINDEX、Audio MenuINDEX、SubtitleMenuINDEX、titleMenuINDEX、title#1～#mINDEX、title#m+1～Nindex、title#0INDEX。图中的箭头bc1、2模式地表示从Index Table向FirstPlayOBJ的分支、从FirstPlayOBJ向TopMenu的分支，箭头bc3、4、5模式表示从TopMenu向TitleMenu、SubTitleMenu、AudioMenu的分支。箭头bc6、7、8模式地表示从TitleMenu向各Movie对象的分支。 

FirstPLayINDEX、TopMenuINDEX、Audio MenuINDEX、SubtitleMenuINDEX、title MenuINDEX分别是对于FirstPLay OBJ、TopMenuOBJ、Audio MenuOBJ、Subtitle MenuOBJ、title MenuOBJ的Index，描述了这些识别符。 

Title#1～#mINDEX是BD-ROM中从第一个进入到第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中。 

图30(a)表示如图29那样描述了Index Table的情况下的分支。由于这样来描述Index Table，所以在将标签title#1～title#m作为分支目标的分支指令的执行时，从title#1～title#m INDEX中取出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...”，将该标题名的动态脚本读出到存储器中，来执行。其是使用了索引表的分支处理。 

图30(b)是表示BD-J对象执行时的强制终止时的分支的图。在强制终止时的分支中，从title#0Index取出识别符，并通过再现装置来执行该识 别符的动态脚本。若该识别符为顶端菜单标题的识别符，则在应用程序强制终止时，自动选择顶端菜单OBJ。 

以上是对于本实施方式中的记录媒体的改进。接着，说明对于本实施方式中的再现装置的改进。由于对应于上述的记录媒体的改进，所以再现装置内的模块管理器34以如图31所示的处理过程来进行处理。图31是表示模块管理器34的处理过程的流程图。本流程图构成由步骤S31、步骤S32构成的循环处理，并在步骤S31或步骤S32中之一为”是”时，执行对应的处理。 

步骤S31判断是否有标题跳转API的调用。若有标题跳转API的调用，则取得作为分支目标标签的标题号j(步骤S33)，并从索引表中的标题号j的索引中取得IDj(步骤S34)，而使HDMV模块33或BD-J模块35执行IDj的Movie对象或BD-J对象(步骤S35)。 

步骤S32判断是否从应用程序管理器36通知标题终止的，若通知(步骤S32中”是”)，则使HDMV模块33或模块管理器34执行构成顶端菜单标题的顶部菜单OBJ(步骤S36)。 

参考图32来说明基于以上的应用程序管理器36的应用程序强制终止的动作例。这里应再现的标题是包含堆积降落的瓦(tile)片的游戏应用程序的非AV系标题。图32的下级表示由应用程序的生存区间构成的标题时间轴，上级表示标题时间轴中显示的图像。在非AV系标题是游戏应用程序的情况下，在该游戏应用程序的生存区间中，如图32的上段左侧那样，显示游戏应用程序的一画面。若应用程序有错误，而异常终止，则应用程序管理器36根据图23的流程图来使游戏应用程序强制终止，并向模块管理器34通知标题的终止。若通知了标题终止，则模块管理器34分支到顶端菜单标题。这样，显示如图32的上段右侧所示的图像，等待用户的操作。 

如上所述，根据本实施方式，在包含程序，但是不包含数字流的非AV系标题终止时，可以进行分支到顶端菜单标题的控制。由此，即使应用程序出错终止，也可避免停机和破坏(bang up)的产生。 

(第五实施方式) 

涉及BD-J模式中怎样实现与PL再现的同步的改进。在图8(b)的一例中，在Java虚拟机38对命令JMF播放器实例的再现的JMF播放器实例 (A.play；)进行译码的情况下，Java虚拟机38调用PL再现API，在调用后，紧接着向应用程序返回表示“成功”的响应。 

重放控制引擎32在调用PL再现API时，执行基于PL信息的处理过程。若PL具有两小时的再现时间，则上述的处理持续该两小时的时间。这里成为问题的是Java虚拟机38返回成功响应的时间和重放控制引擎32实际终止处理的时间的间隔。Java虚拟机38由于是作为驱动事件的处理主体，所以在调用之后紧接着返回表示再现成功或再现失败的响应，但是由于基于重放控制引擎32的实际的处理终止在经过2小时后，所以在将访问响应返回应用程序的时间作为基准的情况中，不能感测相当于2小时经过后的处理终结。若在PL再现中进行快进、倒带、Skip，则该2小时的再现期间在2小时前后改变，处理终结的感测更加困难。 

重放控制引擎32由于在与应用程序孤立的状态下动作，所以在如第三实施方式那样的终止判断中，不能将PL再现的终止解释为标题终止。因此，在本实施方式中，虽然应用程序已经终止，但是只要工作存储器37上存在JMF播放器实例，即，在BD-J模块35掌握展示引擎31的控制权的期间，从重放控制引擎32等待再现终止事件。并且，若存在再现终止事件，则解释为标题终止，并为了进行向下一标题的分支，向模块管理器34进行通知。由此，可以将重放控制引擎32终止PL再现的时刻作为标题的终止。 

之后，参考图33～图37的流程图来说明基于重放控制引擎32的具体的控制过程。 

图33是表示基于重放控制引擎32的PL再现控制过程的流程图。该再现过程主要包含对于展示引擎31的控制(步骤S46)和对于BD-ROM驱动器1或HDD17的控制(步骤S48)。将本流程图中作为处理对象的PlayItem设作PlayItem#x。本流程图进行当前PL信息(.mpls)的读取(步骤S41)，之后，执行步骤S42～步骤S50的处理。这里，步骤S42～步骤S50在步骤S49为”是”之前，对于构成当前PL信息的各个PI信息，重复进行步骤S43～步骤S50的处理的循环处理。将该循环处理中作为处理对象的PlayItem称作PlayItem#x(PI#x)。该PlayItem#x通过设定为当前PL的头的PlayItem来进行初始化(步骤S42)。上述的循环处理的终止要件是该PlayItem#x是当前PL的最后的PlayItem(步骤S49)，若是最后的PlayItem， 则将当前PL的下一PlayItem设定为PlayItem#x(步骤S50)。 

循环处理中重复执行的步骤S43～步骤S50将由PlayItem#x的Clip_information_file_name指定的Clip信息读入到脚本存储器21中(步骤S43)，并使用当前Clip信息的Epmap，来将PlayItem#x的In_time转换为I图像地址u(步骤S44)，使用当前Clip信息的EP_map来将PlayItem#x的Out_time转换为I图像地址v(步骤S45)，并求出通过这些转换得到的地址v的下一I图像之后，将该地址的前一个设定为地址w(步骤S47)。使用这样算出的地址w，来向BD-ROM驱动器1或HDD17命令从I图像地址u到地址w的TS包的读出(步骤S48)。 

另一方面，对展示引擎31，命令从当前PLMark的mark_time_stamp到PlayItem#x的Out_time为止的输出(步骤S46)。通过以上的步骤S45～步骤S48，在AVClip中，进行由PlayItem#x指示的部分的再现。 

之后，判断PlayItem#x是否为当前PL的最后的PI(步骤S49)。 

若PlayItem#x不是当前PL的最后的PI，则将当前PL中的下一PlayItem设定为PlayItem#x(步骤S50)，而回到步骤S43。通过重复以上的步骤S43～步骤S50，依次再现构成PL的PI。 

图34是表示角度切换过程和Skip Back、Skip Next的过程的流程图。本流程图与图33的处理过程并行，重复由步骤S51～S52构成的循环处理。本循环中的步骤S51中判断请求角度切换的API是否是从Java虚拟机38调用的，若存在角度切换API的调用，则执行切换当前Clip信息的操作。 

图34的步骤S55是判断步骤，进行PlayItem#x的is_multi_angles是否为ON的判断，所谓is_multi_angles是表示PlayItem#x是否对应于多角度的标志，若步骤S55为”否”，则进入到步骤S53。若步骤S55为”是”，则执行步骤S56～步骤S59。步骤S56～步骤S59将切换后的角度号代入自变量y(步骤S56)，并向脚本存储器21读出由PlayItem#x中的第y的Clip_information_file_name指定的Clip信息(步骤S57)，使用当前Clip信息的EP_map将当前PTM转换为I图像地址u(步骤S58)，并使用当前Clip信息的EP_map来将PlayItem#x的Out_time转换为I图像地址v(步骤S59)。这样，在变化了I图像地址u、v后，进入到步骤S46。由于通过向步骤S46的进入，从其他AVClip读出TS包，所以切换视频内容。 

另一方面，图34的循环中的步骤S52判断是否从Java虚拟机38调用含义为Skip Back/Skip Next的API，若调用，则执行图35的流程图的处理过程。图35是表示调用Skip Back，Skip NextAPI时的处理过程的流程图。每次执行Skip Back，Skip Next时的处理过程多种多样。注意这里说明的只不过是一例。 

步骤S61通过转换用PSR表示的当前PI号和当前PTM，来得到当前Mark信息。步骤S62判断按下的键是Skip Next键还是Skip Back键，若是Skip Next键，则在步骤S63中将方向标志设定为+1，若为Skip Back键，则在步骤S64中将方向标志设定为-1。 

步骤S65将在当前PLMark的号上补上了方向标志的值后的号设定为当前PLMark的号。这里，若是SkipNext键，则将方向标志设定为+1，所以增加当前PLMark。若是Skip Next键，则将方向标志设为-1，所以减去当前PLMark。 

步骤S66中，将在当前的PLMark的ref_to_PlayItem_Id上描述的PI设为PlayItem#x，在步骤S67中，读入由PlayItem#x的Clip_information_file_name指定的Clip信息。在步骤S68中，使用当前Clip信息的EP_map，来将当前PLMark的mark_time_stamp转换为I图像地址u。另一方面，在步骤S69中，使用当前Clip信息的EP_map将PlayItem#x的Out_time转换为I图像地址v。步骤S70在向展示引擎31命令从当前PLMark的mark_time_stamp到PlayItem#x的Out_time的输出后，进入到图33的步骤S47。这样，在变化I图像地址u、v后，命令其他部分的再现后，向步骤S47进入，所以变为从其他AVClip中读出TS包，实现切换视频内容。 

图36是表示基于展示引擎31的处理过程的细节的流程图。本流程图在将I图像的PTS设定为当前PTM后(步骤S71)，执行由步骤S72～步骤S77构成的循环处理。 

接着，说明步骤S72～步骤S77中的循环处理。该循环处理重复相当于当前PTM的图像、音频的再现输出和当前PTM的更新。本循环处理中的步骤S76规定循环处理的终止要件。即，步骤S76将当前PTM为PI#x的Out_time情况作为循环处理的终止要件。 

步骤S73判断是否从Java虚拟机38调用快进API或快倒API。若是，则在步骤S78中进行快进或快倒的判断，若是快进，则将下一I图像的PTS设作当前PTM(步骤S79)。这样，通过将当前PTM设定为下一I图像的PTS，可以在一秒中很快地再现AVClip。由此，AVClip以2倍速等沿顺方向很快再现。若是快倒，则判断当前PTM是否达到PlayItem#x的Out_time(步骤S80)。若没有达到，则将前一个I图像的PTS设定为当前PTM(步骤S81)。通过这样将读出端地址A设作前一个的I图像，可以沿后方向在一秒内很快再现AVClip。由此，以2倍速等沿逆方向来再现AVClip。另外，执行快进、倒带时的处理过程多种多样。注意这里说明的只不过是一例。 

步骤S74判断是否调用菜单调用API，若调用，则挂起当前的再现处理(步骤S82)，执行菜单处理用菜单程序(步骤S83)。通过以上的处理，在进行了菜单调用的情况下，在中断再现处理后，执行菜单显示用的处理。 

步骤S75通过Syn_PlayItem_id判断是否存在指定了PlayItem#x的SubPlayItem#y，若存在，则进入到图37的流程图。图37是表示SubPlayItem的再现过程的流程图。本流程图中，首先在步骤S86中，判断当前PTM是否是SubPlayItem#y的sync_start_of_playItem。若这样，则在步骤S93中通知重放控制引擎32进行基于SubPlayItem#y的再现处理。 

图37的步骤S87～步骤S92是表示基于SubPlayItem#y的再现处理的流程图。 

在步骤S87中，读入通过SubPlayItem#y的Clip_information_file_name指定的Clip信息。在步骤S88中，使用当前Clip信息的EP_map，将SubPlayItem#y的In_time转换为地址α。另一方面，在步骤S89中，使用当前Clip信息的EP_map，将SubPlayItem#y的Out_time转换为地址β。步骤S90向译码器命令从SubPlayItem#y的In_time到SubPlayItem#y的Out_time的输出。求出通过这些转换得到的地址β的下一I图像，并将该地址的前一个设作地址γ(步骤S91)，使用这样算出的地址γ，向BD-ROM驱动器1或HDD17命令从SubClip#z的地址α到地址γ的TS包的读出(步骤S92)。 

另外，回到图33来进行重放控制引擎32的处理的说明的继续。步骤S53是基于展示引擎31的再现控制是否完成的判断，对于最后的 PlayItem#x，只要进行图36的流程图的处理，步骤S53成为”否”。图36的流程图的处理终止后，步骤S53才变为”是”，并进入到步骤S54。步骤S54是向Java虚拟机38的再现终止事件的输出，通过该输出，Java虚拟机38可以知道两个小时的再现时间的经过。 

以上是本实施方式中的重放控制引擎32、展示引擎31的处理。接着说明本实施方式中应用程序管理器36的处理过程。图38是表示第五实施方式的应用程序管理器36的处理过程的流程图。 

图38的流程图改进了图27的流程图。其改进点是，在步骤S21-步骤S22之间追加了步骤S24，在该步骤S24为”是”时，存在所执行的步骤S101。 

步骤S24判断工作存储器37中是否存在JMF播放器实例，若不存在，则进入到步骤S22。若存在，则进入到步骤S101。步骤S101判断是否从重放控制引擎32输出了再现终止事件，若输出了，则在消除工作存储器中的Java播放器实例后(步骤S102)，向模块管理器34通知标题终止(步骤S26)。若没有通知，则重复由步骤S21～步骤S24构成的循环处理。 

在以上的流程图中，只要在工作存储器37上存在JMF播放器实例(步骤S24中为”是”)，就跳过步骤S22、步骤S23。因此，例如，即使所有的应用程序终止，也解释为标题继续中。 

如上这样，根据本实施方式，应用程序管理器36可以把握两个小时的再现时间的经过时刻，所以可以实现在PL再现的终止条件上显示菜单，并根据对于该菜单的操作来分支到其他标题的控制。 

(第六实施方式) 

第六实施方式涉及在BD-J对象上设置了数据管理表的改进。 

数据管理表(DMT)是表示在其标题时间轴上使应装载到本地存储器29上的Java归档文件与读入属性和读入优先级对应的表。所谓本地存储器29中的生存是指可从本地存储器29中读出构成该应用程序的Java归档文件，并传送到Java虚拟机38内的工作存储器37的状态。图39是表示数据管理表的一例的图。如该图所示，数据管理表表示应用程序的“生存区间”、识别具有该生存区间的应用程序的“applicationID”和该应用程序的“读入属性”、“读入优先级”。 

如上所述，应用程序管理表中存在称作生存区间的概念，数据管理表中也存在相同的生存区间的概念。将与应用程序管理表相同的概念设置在数据管理表中，看上去认为浪费，但是其有含义。 

图40是表示BD-J对象假定的执行模型的图。该图中的执行模型由BD-ROM、本地存储器29、Java虚拟机38构成，表示BD-ROM、本地存储器29、工作存储器37三者的关系。箭头my1表示BD-ROM→本地存储器29之间的读入，箭头my2表示本地存储器29→工作存储器37之间的读入。箭头上的注解表示在怎样的定时下进行这些读取。基于注解，BD-ROM→本地存储器29之间的读入是所谓的“先读”，必须在需要应用程序之前的时刻进行。 

另外，若基于注解，则清楚在需要应用程序时进行本地存储器29→工作存储器37之间的读入。所谓“需要时”是指应用程序的生存区间到来时刻(1)和从其他应用程序或应用程序管理器36指示了应用程序的调用的时刻(2)。 

箭头my3表示工作存储器37中的应用程序的占有区域的释放，箭头my4表示本地存储器19中的应用程序的占有区域的释放。箭头上的注解表示在哪个定时上进行这些读入。若基于注解，则明白与应用程序终止同时进行工作存储器37上的释放。另一方面，在对于Java虚拟机38来说不需要的时刻进行本地存储器29上的释放。所谓不需要的时刻不是“终止时刻”。是指“终止后，没有重新启动的可能性的时刻”，即，该title终止的时刻。从应用程序管理表中的生存区间来判断上述的读入·释放中工作存储器37中的释放时刻。但是不能对“需要应用程序之前的时刻”、“终止后，没有重新启动的可能性的时刻”进行规定。因此，在授权阶段中，由于在盘内容整体的时间轴上规定了该时刻，所以在本实施方式中，将各应用程序生存的区间描述在与应用程序管理表不同的数据管理表上。即，将“需要应用程序之前的时刻”定义为数据管理表中的生存区间的始点，将“终止后，没有重新启动的可能性的时刻”定义为数据管理表的终点，从而可以在授权时规定上述本地存储器29上的存储内容的迁移。其是数据管理表的描述意义。 

说明基于数据管理表的本地存储器29生存区间的描述。这里要制作的 盘内容由三个标题(title#1、titile#2、title#3)构成，这些标题的时间轴上，认为要以如图41(b)所示的定时，使用本地存储器29。这时，在title#1时间轴的开始点中将构成application#1、application#2的Java归档文件读入到本地存储器29中，在title#1时间轴的继续中，使application#1、application#2常驻在本地存储器29上。并且，在title#2时间轴的起始点，从本地存储器29中释放构成application#1的Java归档文件，并代替此，将构成application#3的Java归档文件读入到本地存储器29中，而进行常驻(之后，构成应用程序的Java归档文件与应用程序同样地处理)。这时的数据管理表的描述如图41(a)那样，通过与其生存区间对应地描述应用程序的applicationID，来表现应在本地存储器29中常驻的应用程序。图41(a)中，可以看出与title#1对应地来描述application#1的applicationID，与title#1、title#2对应地来描述application#2的applicationID，与title#3对应地来描述application#3的applicationID。由此，通过授权承担者来规定本地存储器29占有的时间迁移。 

作为数据管理表、应用程序管理表的组合，最好在应用程序管理表中规定的生存区间为小的再现单位，在数据管理表中规定的生存区间为大的再现单位。大的再现单位最好是标题、PL这样的非无缝的再现单位。另一方面，作为小的再现单位，最好是如PL内的章节那样的无缝的再现单位。若按每个标题、PL来定义应用程序的生存区间，由于应用程序存在于工作存储器29上，所以在其标题的再现中为无论何时都可取出应用程序的状态。若这样，由于即使精细地定义应用程序的生存区间，也可立即将应用程序读出到虚拟机上的工作存储器上，所以即使频繁进行应用程序的启动·终止，也可实现平滑地执行应用程序。 

接着，说明读入属性。 

图2中，以Java归档文件记录在与AVClip不同的记录区域上为前提。但是，其不过是一例。Java归档文件存在嵌入到BD-ROM中AVClip所占有的记录区域的情况。该嵌入的方式有循环(carousel)、交叉单元化两种。 

这里所谓“循环”是指为实现对话广播而转换为重复同一内容的广播方式。BD-ROM虽然没有存储广播的数据，但是在本实施方式中，模仿循环的广播形式来存储JAVA归档文件。图42是表示基于循环的Java归档文 件嵌入的图。第一级是在AVClip中嵌入的Java归档文件，第二级表示分段化。第三级表示TS包化，第四级表示构成AVClip的TS包串。将这样分段化、TS包化的数据(图中的“D”)嵌入到AVClip中。通过循环，在AVClip中多路复用的Java归档文件在每次读出时，低频读出。由于该低频的读出需要大致2～3分钟这样的长时间，所以再现装置花费2～3分钟来读入Java归档文件。 

图43表示基于交叉的Java归档文件嵌入的图。第一级是应嵌入的AVClip，第二级是在AVClip中交叉的Java归档文件，第三级是BD-ROM的记录区域中的AVClip配置。如该图所示，应嵌入在流中的Java归档文件进行交叉后，记录在形成构成AVClip的XXXXX.m2ts的分割部分(图中的AVClip2/4，3/4)的间隔上。通过交叉在AVClip上多路复用的Java归档文件，与循环比较，以高频带读出。由于是该高频带的读出，所以再现装置在较短期间读入Java归档文件。 

不预先装载循环·交叉后的Java归档文件。在当前的再现时刻到达BD-ROM中的AVClip的记录区域中的、嵌入了循环·交叉后的Java归档文件的部分时，装载到再现装置的本地存储器29中。Java归档文件的记录形态除了图2所示的形态之外，有图42、图43(a)所示的形态，所以如图43(b)所示那样来设置读入属性。如图43(b)所示，读入属性有表示在标题再现之前、并向本地存储器29读入的“Preload”、和表示在标题再现中以循环方式读入的“Load.Carousel”、以及表示在标题再现中以交叉方式读入的“Load.InterLeave”。读入属性中用后缀来表现循环或交叉，但是也可省略。 

参考图44来说明数据管理表中的生存区间的具体的描述例。图44(a)是表示数据管理表的一例的图。图44(b)是表示基于该数据管理表的分配的本地存储器29的存储内容的变化的图。该图在纵轴方向上表示本地存储器29中的占有区域，横轴为一个标题内的PL时间轴。由于数据管理表中，application#1描述为一个标题内的PL时间轴整体为生存区间，所以在该标题的Chapter#1～Chapter#5中占有本地存储器29内的区域。application#2描述为在数据管理表中使标题内的PL#1中的Chapter#1～Chapter#2为生存区间，所以在该标题的Chapter#1～Chapter#2中占有本地存储器29 内的区域。由于application#3描述为在数据管理表中使标题内的PL#1中的Chapter#4～Chapter#5为生存区间，所以在该标题的Chapter#4～Chapter#5中占有本地存储器29内的区域。结束以上对数据管理表中的生存区间的说明。 

接着说明读入优先级。所谓读入优先级是指决定对于向本地存储器29的读入的优劣的优先级。读入优先级有多个值。在想要设置两个等级的优劣的情况下，将表示强制(Mandatory)的值、表示可选(optional)的值设定为读入优先级。这时，Mandatory是指高的读入优先级，optional是指低的读入优先级。在想要设置三个等级的优劣的情况下，将表示Mandatory的值、表示optional:high、optional:low的值设定为读入优先级。Mandatory表示最高的读入优先级，optional:high表示中等的读入优先级，optional:low表示最低的读入优先级。参考图45(a)、(b)来说明数据管理表中的读入优先级的具体的描述例。在该具体例中，假定的本地存储器29的存储器规模如图45(a)所示。图45(a)是对比表示新旧再现装置中的本地存储器29的存储器规模的图。箭头mk1表示旧再现装置中的存储器规模，箭头mk2表示新再现装置中的存储器规模。根据该箭头的对比，假定新再现装置中的本地存储器29的存储器规模与旧再现装置的存储器规模相比为三倍以上的状态。这样，在存储器规模有偏差的情况下，应用程序分类为如图45所示那样的两个组。第一个无论是什么样的存储器规模都应读入的应用程序(#1，#2)。第二个是不希望旧再现装置的读入，但是希望新再现装置的读入的应用程序(#3，#4)。若将要读入的应用程序分类为这两个组，则在属于前者的应用程序上设置读入优先级＝Mandatory，并在属于后者的应用程序上设置读入优先级＝Optional。图45(b)是表示设置了读入优先级的数据管理表的一例的图。若这样来设置数据管理表后，将application#1～application#4记录在BD-ROM上，则保证了一切的存储器规模的再现装置上的再现，同时在存储器规模大的再现装置上，可以使再现装置再现利用了更大的大小的数据的应用程序。 

以上是对于本实施方式的记录媒体的改进。接着说明对于本实施方式中的再现装置的改进。由于对应于上述的记录媒体的改进，所以应用程序管理器36以图46所示的处理过程来进行处理。 

图46是表示基于应用程序管理器36的预装载控制的处理过程的图。本流程图构成如下的循环处理：在读入应再现的标题中的数据管理表(步骤S111)、在数据管理表中具有最高的读入优先级，同时，将applicaitonID最小的应用程序设为应用程序i后(步骤S112)，在经过了步骤S113、步骤S114的判断后，重复进行将应用程序i预装载到本地存储器29上(步骤S115)的处理，直到判断为步骤S116为”否”和步骤S117为”否”。 

步骤S113判断应用程序i的读入属性是否是预装载，步骤S114判断应用程序的读入优先级是＝Mandatory还是Optional。若在步骤S113中判断为预装载，在步骤S114中将读入优先级判断为Mandatory，则将应用程序预装载到本地存储器29中(步骤S115)。若在步骤S113中判断为读入属性是装载，则跳过步骤S114～步骤S115。 

规定循环处理的终止要件的两个步骤中步骤S116，判断是否存在applicationID次高、读入优先级与应用程序I相同的应用程序k。若存在这种应用程序k，将该应用程序k设为应用程序i(步骤S119)。 

规定循环处理的终止要件的两个步骤中步骤S117判断数据管理表中是否存在具有次低的读入优先级的应用程序，若存在，将具有该次低的读入优先级的应用程序中最小的applciationID中选作应用程序k(步骤S118)，将该应用程序k设作应用程序i(步骤S119)。只要这些步骤S116、步骤S117为”是”，则重复上述的步骤S113～步骤S115的处理。步骤S116、步骤S117中，若没有相应的应用程序，则本流程图的处理终止。 

步骤S120～步骤S123是在步骤S14中判断为读入优先级＝Optional的情况下执行的处理。 

步骤S120判断是否存在具有相同的applicationID、且读入优先级高的应用程序j。 

步骤S121判断本地存储器29的残留容量是否高于应用程序i的大小。在步骤S120为”否”，步骤S121为”是”的情况下，在步骤S115中，将应用程序i预装载到本地存储器29中。在步骤S120为”否”，步骤S121为”否”的情况下，不将应用程序i装载到本地存储器29上而仍进入到步骤S116。 

这样，若读入优先级＝Optional的数据在步骤S120-步骤S121的判断 不是”是”时，不进行向本地存储器29的预装载。存储器规模小的旧再现装置为读入了2～3个应用程序的程度，在步骤S121的判断为”否”，但是存储器规模大的新再现装置即使读入更多的应用程序，步骤S121的判断也不成为”否”。如上这样，在旧再现装置中，仅向本地存储器29读入Mandatory的应用程序，向新再现装置读入Mandatory的应用程序和Optional的应用程序。 

步骤S122是在步骤S120中判断为”是”的情况下执行的步骤。在本地存储器29上存在具有同一applicationID、且读入优先级高的应用程序j的情况下，判断本地存储器29的剩余容量和应用程序j的大小的和是否超过了应用程序i的大小(步骤S122)，若超过，则通过使用应用程序i来覆盖本地存储器29上的应用程序j，来进行预装载(步骤S123)。在低的情况下，不将应用程序i预装载到本地存储器29中来原样进入到步骤S116。 

参考图47(a)来说明基于步骤S115、步骤S123的读入处理的一例。图47(a)是表示该具体例假定的数据管理表的一例的图。将该图中的三个应用程序分别存储在三个文件中，applicationID相同(applicationID＝1)，但是读入优先级分别不同(mandatory，optional:high，optional:low)。若这样的数据管理表为处理对象，则通过步骤S115，将读入优先级＝Mandatory的应用程序读入到本地存储器29中。但是，对于读入优先级＝Optional的应用程序，在经过了步骤S120～步骤S122的判断后，在步骤S123中进行读入。在与步骤S115不同的步骤S123中，由于进行预装载，以使其覆盖已经存在于本地存储器29中的相同的applicationID的应用程序，所以排他地将多个应用程序中的一个装载到本地存储器29中。 

i)在读入了读入优先级＝mandatory的应用程序后，每次读入读入优先级＝optional:high的应用程序时，若步骤S122判断为”否”，则在本地存储器29中保留读入优先级＝mandatory的应用程序。在读入了读入优先级＝mandatory的应用程序后，每次读入读入优先级＝option:high的应用程序时，若步骤S122判断为”是”，则通过读入优先级＝optional:high的应用程序，来覆盖读入优先级＝mandatory的应用程序，并在本地存储器29中保留读入优先级＝optional:high的应用程序。 

ii)在读入了读入优先级＝optional:high的应用程序后，每次读入读 入优先级＝optional:low的应用程序时，若步骤S122判断为”否”，则在本地存储器29中保留读入优先级＝Mandatory的应用程序。在读入了读入优先级＝optional:high的应用程序后，每次读入读入优先级＝optional:low的应用程序时，若步骤S122判断为”是”，则通过读入优先级＝optional:low的应用程序，来覆盖读入优先级＝optional:high的应用程序(步骤S123)，在本地存储器29中保留读入优先级＝optional:low的应用程序。 

由于只要本地存储器29的容量允许，重复覆盖本地存储器29上的应用程序的处理，所以本地存储器29的存储内容如图47(b)所示，而变为mandatory＝optional:high＝＞optional:low。由于可以根据存储器规模，将大小不同的Java归档文件装载到本地存储器29中，所以对于存储器规模小的再现装置，将具有必要最小限度的分辨率的缩略图像的Java归档文件装载到本地存储器29中，对于存储器规模为中等程度的再现装置，将具有中等程度的分辨率的SD图像的Java归档文件装载到本地存储器29中，对于存储器规模大规模的再现装置，将具有高分辨率的HD图像的Java归档文件装载到本地存储器29中。通过该装载，可以根据存储器大小来显示分辨率不同的图像，授权承担者的标题制作的表现范围宽。 

图48是表示参考数据管理表的读取处理的具体例的图。该图中的两个应用程序是表示添加了同一applicationID(application#3)的两个应用程序。其中一个嵌入到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作为生存区间，所以在标题时间轴上排他性地在本地存储器29上常驻其中一个。图48(b)是表示在标题时间轴上的不同的时刻，排他性地存储的application#2、application#3的图。其是考虑了仅要在必要最低限度的存储器规模的再现装置上的再现为目的的。若这种内容的数据管理表为处理对象，则应用程序管理器36通过上述的图46的流程图来根据存储器规模进行不同的处理。 

由于读入优先级＝装载，所以将后者的应用程序装载到本地存储器29上。通过该处理，只要有Mandatory的存储器规模，则应用程序管理器可以将数据装载到本地存储器29上。这里成为问题的是基于存储器规模大的再现装置的读入时。不管存储器规模大小，在到达Chapter#4～Chapter#5之前，不读入application#3是存储器规模的浪费。因此，在该图的数据管理表中向同一application#3添加表示预装载的读入属性而记录在BD-ROM上，并向其添加相同的applicationID。 

由于前者的应用程序读入优先级＝Optional，所以只要是步骤S121为”是”的情况下，就进行预装载(步骤S115)。由此，存储器规模大的再现装置可以将与在AVClip中嵌入的应用程序相同的应用程序装载到本地存储器中，而不用等待title#1、Chapter#4～Chapter#5的到达(图48(c))。 

以上是预装载时的处理。接着说明装载时的处理过程。 

图49是表示基于数据管理表的装载处理的处理过程的图。本流程图在持续标题再现的期间，重复进行由步骤S131～步骤S 133构成的循环处理。 

步骤S131是具有表示AutoRun的启动属性的应用程序的生存区间是否到来的判断。若到来，则将具有表示AutoRun的启动属性的应用程序设作应用程序q(步骤S134)，向Java虚拟机38发出表示启动应用程序q的启动指示，并从本地存储器29向工作存储器37读出应用程序q(步骤S135)。 

步骤S133判断标题内PL的再现是否完全终止。该判断如第五实施方式，通过是否存在来自重放控制引擎32的再现终止事件来进行。若终止，则终止本流程图的处理。 

步骤S132判断是否有来自启动中应用程序的调用。若有，则将调用目标应用程序设为应用程序q(步骤S136)，判断当前的再现时刻是否是应用程序管理表中的应用程序q的生存区间(步骤S137)。若不是生存区间，则显示启动失败(步骤S148)，回到由步骤S131～步骤S133构成的循环处理。若是生存区间，则根据图50的流程图来进行装载处理。 

图50中的步骤S138判断表示当前再现时刻是否是数据管理表中的应用程序q的生存区间。若不是生存区间，则不能将应用程序q装载到本地存储器29中。这时，向Java虚拟机38发出表示启动应用程序q的启动指示，并直接将应用程序q从BD-ROM读出到工作存储器37中，而不用经 过本地存储器29。这时由于产生了用于读出应用程序的头搜索，所以PL再现中断(步骤S145)。 

若是生存区间，则在步骤S139中，判断是否在应用程序上添加了读入属性。所谓没有读入属性是指没有循环或交叉应用程序q。但是，即使没有添加读入属性，也允许在本地存储器29上放置应用程序。因此，在知道再现中断后，进行应用程序的读出。即，在将应用程序从BD-ROM读出到本地存储器29后，将应用程序读出到工作存储器37(步骤S140)。 

步骤S141～步骤S146是在步骤S139被判断为”是”的情况下所作的处理。在步骤S141中，通过参考读入属性，来判断是否预装载了应用程序。若进行了预装载，则进入到步骤S135。 

步骤S142是在读入属性是装载的情况下所执行的判断步骤，判断是否循环、交叉应用程序q。若进行了交叉，则使Java虚拟机38执行高速缓存传感(步骤S143)。若在本地存储器29上存在应用程序q，则进入到步骤S135，使应用程序q装载到Java虚拟机38上。 

若本地存储器29上没有应用程序，则进行分支到顶端菜单标题等的例外处理(步骤S144)。若进行了循环，则设置定时器(步骤S148)，在该定时器超时之前(步骤S147)，使Java虚拟机38执行高速缓存传感(步骤S146)。若在本地存储器29上出现应用程序q，则进入到图49的步骤S135，将应用程序q装载到Java虚拟机38上。若超时，则进行分支到顶端菜单标题等的例外处理(步骤S144)。 

图51是模式化了怎样进行基于Java虚拟机38的应用程序的读入的图。 

箭头◎1、2表示：在应用程序管理表上生存、且在数据管理表上生存、且存在表示循环、交叉的读入属性的Java归档文件的读入。箭头◎1表示在步骤S65、67中进行的本地存储器29传感。该本地存储29传感由于可能在本地存储器29中存在通过循环或交叉嵌入的数据，所以在本地存储器29内进行传感。箭头◎2表示对应于步骤S135的读入，表示：应用程序存在于本地存储器29中的情况下的、从本地存储器29向工作存储器37的装载。带×的箭头表示在本地存储器29上没有数据的情况。 

箭头 

1、2表示：在应用程序管理表上生存、但是不在数据管理表中生存、且读入属性不存在的Java归档文件的读入。 

箭头 

1对应于步骤S145中的读入，表示：基于Java虚拟机38的来自BD-ROM的直接读取的请求。箭头 

2表示基于该要求的从BD-ROM向工组存储器37的Java归档文件读出。 

箭头☆1、2、3表示：在应用程序管理表上生存、在数据管理表上生存、但是读入属性不存在的Java归档文件的读入。 

箭头☆1对应于步骤S140中的读入，表示：基于Java虚拟机38的来自BD-ROM的直接读取请求。箭头☆2表示基于该请求的Java归档文件向本地存储器29的读出。箭头☆3表示从本地存储器29向工作存储器37的Java归档文件的读出。 

如上所述，根据本实施方式，由于可以将在本地存储器29上同时常驻的应用程序的数目规定为预定数目以下，所以可以尽量避免从本地存储器29读出时的高速缓存损失。由于可以保证没有高速缓存损失的应用程序的读出，所以每次应用程序调用时，不会从BD-ROM中读出应用程序，直到停止AVClip的再现。由于没有中途切断AVClip再现，所以可以保证AVClip的无缝再现。 

(第七实施方式) 

第三实施方式中，根据应用程序的生存区间来决定非AV系标题的时间轴。但是，应用程序的动作不稳定，会有启动的失败和异常终止。本实施方式提出了有启动失败、异常终止的情况下的失败安全机构。图52(a)是表示第七实施方式的BD-J对象的内部结构的图。与图7(b)相比，该图的新的方面是追加了播放列表管理表。 

图52(b)是表示播放列表管理表的一例的图。如该图所示，播放列表管理表由PL的指定和该PL的再现属性构成。PL的指定表示在对应的标题的标题时间轴中，可进行再现的PL。PL的再现属性表示是否与标题再现的开始同时自动再现所指定的PL(将这样自动再现的PL称作缺省PL)。 

接着，参考图53来说明怎样通过播放列表管理表来规定标题时间轴。图53(a)是设定为再现属性表示表示非自动再现的情况下的非AV系标题中的标题时间轴的图。这时，由于没有再现缺省PL，所以非AV系标题同样从应用程序的生存区间来决定标题时间轴。 

图53(b)是表示将再现属性设定为AutoPlay的非AV系标题的标题时 间轴的图。若设定为再现属性表示AutoPlay，则重放控制引擎32与非AV系统标题的再现开始同时，开始缺省PL的再现。但是，即使应用程序正常动作，正常终止，以PL时间轴为基准来决定该标题时间轴。 

图53(c)表示在播放列表管理表中设定为再现属性表示“AutoPlay”，应用程序异常终止的情况。通过该异常终止，变为什么应用程序都不动作的状态，但是缺省PL的再现继续。这时，缺省PL的PL时间轴为标题时间轴。 

图53(d)表示在播放列表管理表中设定为再现属性表示“AutoPlay”，主应用程序的启动失败的情况。这时由于基于重放控制引擎32的缺省PL再现也与应用程序的启动失败无关地进行，所以缺省PL的时间轴变为标题时间轴。 

如上所述，若将播放列表管理表的再现属性设定为“AutoPlay”，在Java应用程序的启动中，在即使花费5～10秒的时间，进行该启动的期间，变为“总之是复制什么的状态”。通过为该“总之是复制什么的状态”，可以补偿标题执行开始时的启动延时。 

以上是对于本实施方式中的记录媒体的改进。接着说明对于本实施方式的再现装置的改进。 

图52(c)是表示在分支目标标题的播放列表管理表中，存在将再现属性设定为AutoPlay的PL的情况下，再现装置进行怎样的处理的图。如该图所示，若再现属性被设定为AutoPlay的PL存在于分支目标标题的播放列表管理表中，则BD-J模块35内的应用程序管理器36指示重放控制引擎32，在标题分支紧之后开始该AutoPlayPL的再现。这样，再现属性为AutoPlay的PL在标题分支紧之后，命令再现开始。 

由于对应于上述的记录媒体的改进，所以应用程序管理器36以如图54所示的处理过程来进行处理。 

图54是表示第七实施方式的应用程序管理器36的处理过程的流程图。本流程图在图38的流程图中，在步骤S21之前追加步骤S103、步骤S104，在步骤S21、步骤S22之间追加步骤S100，在步骤S23～步骤S26之间追加步骤S105。 

步骤S103判断对应的标题的播放列表管理表的再现属性是否是 AutoPlay。若是AutoPlay，则使重放控制引擎32开始对缺省PL的再现控制(步骤S104)。 

步骤S100判断是否是基于展示引擎31的再现中。若为再现中，则进入到步骤S101。 

步骤S105是在步骤S23为”是”，步骤S25为”否”的情况下执行的判断步骤，表示再现属性是否是AutoPlay。若为否，则向模块管理器34通知标题终止。若为AutoPlay，则进入到步骤S101后继续处理。 

图55是模式化表示通过在播放列表管理表中设定为“再现属性＝AutoPlay”来进行怎样的再现的图。这里，应进行再现的标题是包含叠加降落的瓦片的游戏应用程序的非AV系标题。在该非AV系标题中，若将播放列表管理表的再现属性设定为AutoPlay，则还开始基于重放控制引擎32的缺省PL再现。由于并行进行游戏应用程序的执行和缺省PL再现，所以如图55的上级的左侧所示，显示了将前景作为游戏应用程序的画面，将背景作为缺省PL的再现图像的合成图像。设该游戏应用程序在中途异常终止。虽然游戏应用程序通过应用程序管理器36进行了强制终止，但是缺省PL的再现继续，所以标题变为复制什么的状态。通过这种播放列表管理表中的再现属性的指定，即使在非AV系统标题内的游戏应用程序异常终止的情况下，也可维持没有破坏和停机的动作。 

(第八实施方式) 

第一实施方式中BD-J对象具有数据管理表、应用程序管理表二个标题，但是本实施方式公开了将这些综合到一个表的形态。在该综合时，如图56(a)所示，废弃数据管理表中的读入属性项目，代替其，在启动属性上设置称作Ready属性的属性。所谓Ready属性是指包含于来自其他应用程序的调用和来自应用程序管理器36的调用中具有的、表示在本地存储器29上预先装载应用程序的启动属性的类型。 

图56(b)是表示应用程序的处理和启动属性的关系的图。如第一实施方式所示，应用程序的处理有：是否预装载(1)，当前的再现时刻在有效区间到来时自动启动，或根据其他的调用来启动(2)，根据标题再现进行来进行装载(3)，存在有是否生存的不同，根据这些不同，出现了如图56(b)所示的5种形态。其中，将启动属性设定为AutoRun的是进行预装载， “自动启动”的情况和进行装载，“自动启动”的情况。 

另一方面，启动属性设定为Ready属性，是表示预装载或进行装载、启动项目为“调用启动”的情况。 

另外，不会存在在工作存储器37中生存，但是在本地存储器29中不进行装载的类型。这是因为在应用程序数据管理表中，工作存储器37的生存区间和本地存储器29的生存区间一体。 

作为启动属性，由于追加了该Ready属性，所以应用程序管理器36在标题再现之前，进行将启动属性设定为AutoRun的应用程序和将启动属性设定为Ready属性的应用程序预装载到本地存储器29中的处理。由此，即使不设置读入属性，也可进行将应用程序预装载到本地存储器29中的处理。 

图57是模式化怎么进行第八实施方式的基于Java虚拟机38的应用程序的读入的图。以图51以基础来做出了该图中的读入的表现图。 

箭头◎1、2表示：在应用程序·数据管理表中生存、且将启动属性设定为Ready属性的Java归档文件的读入。 

箭头☆1、2、3表示：在应用程序·数据管理表中生存、且启动属性为Persistent的应用程序的读入。 

这些箭头◎1、2，箭头☆1、2、3在图51中进行了描述，但是在图57中不存在在图51中描述的相当于 1、2的箭头的读入。这是因为应用程序·数据管理表一体化了应用程序管理表和数据管理表，所以不能表现应用程序管理表＝生存、数据管理表＝不存在的组合。 

如上所述，根据本实施方式，由于可以将数据管理表、应用程序管理表整理为一个表(应用程序数据管理表)，所以可以简化基于应用程序管理器36的处理。另外，通过没有读入优先级，可以更简化应用程序·数据管理表。 

(第九实施方式) 

第一实施方式中，在将应用程序读入到本地存储器29中时，参考读入优先级，根据该读入优先级，对读入处理赋予优劣。与此相对，第九实施方式是表示通过含义为Optional的信息和0到255的数值的组合来表示读入优先级的实施方式。 

图58(a)(b)是表示第九实施方式的读入优先级的一例的图。255、 128是0到255的读入优先级的一例，含义是本例中的application#2读入优先级比application#3高。 

在本实施方式中，应用程序管理器36与第一实施方式相同，首先将添加了表示Mandatory的读入优先级的应用程序读入到本地存储器29。 

之后，对于添加了表示Optional的读入优先级的应用程序，判断本地存储器29中的容量是否超过了应用程序的大小。若超过，则将添加了读入优先级＝Optional的应用程序原样读入到本地存储器29。若小，则将构成应用程序的数据中，表示读入优先级的数值最高的应用程序读入到本地存储器29中。并且，向本地存储器29中的其余的区域读出表示读入优先级的数值低的应用程序。 

由此，对于Optional处理的应用程序，即使在再现装置的本地存储器29上没有存储整体的容量，也可将其一部分存储到本地存储器29中。 

(第十实施方式) 

第一实施方式中应用程序管理器36将添加了同样applicationID的应用程序，根据读入优先级排他地装载到本地存储器29中，但是第十实施方式中，通过对应用程序施加组属性，来实现排他的装载。图59是表示添加了组属性的数据管理表的图。组属性可以有不是排他组、是排他组的两种设定。在是排他组的情况下，描述其组号。图59(a)中的title#1的“-”表示不存在排他组。另一方面，title#2、#3的“group#1”有排他组，title#2、#3表示属于group#1的排他组。以上是本实施方式的记录媒体的改进。 

本实施方式的再现装置在根据数据管理表，将各应用程序读入到本地存储器29后，来核对本地存储器29的应用程序中的组属性。同样，若属于排他组的应用程序在本地存储器29上存在两个以上，则从本地存储器29中删除其中一个。 

由此，可以提高本地存储器29的使用效率。作为排他组的具体例，由启动应用程序和通过该程序启动的应用程序构成的组对应。由于通过本应用程序启动的应用程序原则上限于一个，所以在本地存储器29上应该仅存在启动+1个的应用程序。若存在三个以上的应用程序，则需要应用程序管理器36进行从本地存储器29中删除其的处理，所以设置各应用程序的组属性，并进行在本地存储器29上存在的应用程序是否是启动+1个的应用 程序的校验。 

图59(a)是表示对基于应用程序管理表的本地存储器29的访问的图。该图中，由于设定为读入优先级＝Optional的application#2、application#3的组属性是group#1，所以这些应用程序属于同样排他组。三个应用程序中，application#1是上述的启动应用程序，由于application#2，application#3是由其启动的应用程序，所以添加组属性，使得仅某个存在于本地存储器29中。应用程序管理器36参考这些application#2，application#1＝3的组属性，进行从本地存储器29中删除某一个的处理。通过该删除在本地存储器29上产生了空余。 

(第十一实施方式) 

第一实施方式中，使每个标题具有应用程序管理表，但是在本实施方式中，提出了使该应用程序管理表的分配单位改变的提案。图60是表示分配单位的变化的图。该图中，第一级表示在BD-ROM上记录的三个应用程序管理表，第二级表示标题单位，第三级表示盘单位，第四级表示由多个BD-ROM构成的盘设置单位。图中的箭头模式地表示应用程序管理表的分配。若参考该箭头，则可以看出第一级中的应用程序管理表#1、#2、#3分别分配到第二级表示的title#1、#2、#3上。另外，以盘为单位来分配应用程序管理表#4，对盘设置整体分配应用程序管理表#5。这样，通过将应用程序管理表的单位设为比标题大的单位，可以在装载了一个BD-ROM的期间，装载了要生存的应用程序和多个BD-ROM中某一个的期间，定义要生存的应用程序。 

(参考) 

以上的说明不应表示本发明的所有实施行为的形态。通过实施了下面(A)(B)(C)(D)...的改变的形态的实施行为方式，也可以实施本发明。本申请的权利要求的各发明是扩展了以上记载的多个实施方式及其变形方式的记载乃至一般化的记载。扩展乃至一般化的程序基于本发明的技术领域的申请当时的技术水平的特性。 

(A)所有的实施方式中，将本发明的光盘作为BD-ROM来实施，但是本发明的光盘在记录的动态脚本，索引表上有特征，该特征不依赖于BD-ROM的物理性质。若是记录了动态脚本、索引表的记录媒体，可以是 任何记录媒体。例如，可以是DVD-ROM、DVD-RAM、DVD-RW、DVD-R、DVD+RW、DVD+R、CD-R、CD-RW等的光盘、PD、MO等的光磁盘。另外，也可以是压缩闪存卡、智能媒体(smart media)、存储棒、多媒体卡、PCM-CIA卡等的半导体存储卡。也可以是软盘、SuperDisk、Zip、Clik！等磁记录盘(i)、ORB、Jaz、SparQ、SyJet、EZFley、微驱动器等可移动硬盘驱动器(ii)，进一步也可以是机器内置型的硬盘驱动器。 

(B)所有的实施方式中的再现装置在译码了在对BD-ROM上记录的AVClip进行了译码后输出到TV，但是，再现装置也可仅为BD-ROM驱动器，在TV上具有除此之外的构成要素，这时，可以将再现装置和TV组装到由IEEE1394连接的家庭网络中。另外，实施方式的再现装置是与电视机相连来使用的驱动器，但是也可以是与显示器为一体的再现装置。进一步，在各实施方式的再现装置中，可以仅将成为处理的本质部分的部分作为再现装置。由于这些再现装置都是在本说明书中记载的发明，所以即便是这些的任何一个形态，以各实施方式所示的再现装置的内部结构为基础，来制造再现装置的行为也为本申请的说明书中记载的发明的实施行为。各实施方式所示的再现装置的基于有偿·无偿的转让(有偿的情况下是贩卖、无偿的情况下是赠与)、出借、输入的行为都是本发明的实施方式。通过店面展示、目录要约、小册子发布，向一般用户提议这些的转让和出租的行为也是本再现装置的实施行为。 

(C)由于使用硬件资源来具体实现基于各流程图所示的程序的信息处理，所以上述流程图中表示了处理过程的程序单体作为发明成立。所有的实施方式以组装到再现装置的形态来表示了对于本发明的程序的实施行为的实施方式，但是也可从再现装置分离，来实施各实施方式中表示的程序单体。程序单体的实施行为有生产这些程序的行为(1)、通过有偿·无偿来转让程序的行为(2)、出借的行为(3)、输入的行为(4)和经双向的电子通信线路向公众提供的行为(5)、和通过(6)店面展示、目录要约、小册子发布，向一般用户提议程序的转让和出租的行为。 

(D)认为各流程图中按时间序列执行的各步骤的“时间”的要素为特定发明用的必须的事项。这样，可以看出基于这些流程图的处理过程公开了再现方法的使用方式。若通过按时间序列来进行各步骤的处理，进 行这些流程图的处理来实现本发明的本来的目的，达到作用和效果，则当然相当于本发明的记录方法的实施行为。 

(E)也可在BD-ROM上记录一览显示Chapter用的菜单(ChapterMenu)和控制其举动的MOVIE对象，而从顶端菜单中分支。另外，也可通过遥控器键的Chapter键的按下来进行调用。 

(F)每次记录在BD-ROM上时，最好在构成AVClip的各TS包上添加扩展头。扩展头称作TP_extra_header，包含“Arribval_Time_Stamp”和“copy_permission_indicator”，具有4字节的数据长度。带TP_extra_header的TS包(下面简写为带EX的TS包)按每32个来进行分组，并写入到三个扇区中。由32个带EX的TS包构成的组是6144字节(＝32×192)，其与三个扇区大小6144字节(＝2048×3)一致。将容纳在三个扇区中的32个带EX的TS包称作“排列的单元(Aligned Unit)”。 

在经IEEE1394相连的本地网络的使用时，再现装置200通过如下这样的发送处理来进行Aligned Unit的发送。即，发送侧的设备分别从在AlignedUnit中包含的32个带EX的TS包取出TP_extra_header，并根据DTCP标准来加密TS包标题后输出。每次TS包的输出时，在TS包之间的任意位置上插入同步的(isochronous)包。该插入位置是基于TP_extra_header的Arribval_Time_Stamp所示的时刻的位置。随着TS包的输出，再现装置200输出DTCP_Descriptor。DTCP_Descriptor表示TP_extra_header中的复制允许设置，这里若描述DTCP_Descriptor，使其表示“禁止复制”，则在经IEEE1394相连的本地网的使用时TS包不记录在其他设备上。 

(G)在各实施方式中，在记录媒体上记录的数字流是AVClip，但是也可以是DVD-Video标准、DVD-Video记录标准的VOB(videoObject)。VOB是通过多路复用视频流、音频流得到的ISO/IEC13818-1规格标准的节目流。另外，AVClip中的视频流也可以是MPEG4和MMV方式。进一步，音频流也可以是Linear-PCM方式、Dolby-AV3方式、MP3方式、MPEG-AAC方式、Dts、WMA(Windows media audio)。 

(H)各实施方式中的视频作品也可通过对用模拟广播广播的模拟视频信号进行编码来得到。也可以是由通过数字广播广播的传输流构成的流数据。 

另外，也可对在录像带上记录的模拟/数字的视频信号进行编码来得到内容。进一步，也可以对从摄像机直接取得的模拟/数字的视频信号进行编码来得到内容。除此之外，也可以是通过发送服务器发送的数字作品。 

(I)BD-J模块35也可以是为进行卫星广播接收而在设备上嵌入的Java平台。BD-J模块35若是该Java平台，则本发明的再现装置兼有作为MHP用STB的处理。 

进一步，也可以是为进行便携电话的处理控制在设备中嵌入的Java平台。若BD-J模块35是该Java平台，则本发明的再现装置兼有作为便携电话的处理。 

(K)在层模型中，也可以在BD-J模式上配置MOVIE模式。这是因为尤其由于MOVIE模式下的动态脚本的解释和基于动态脚本的控制过程的执行对于再现装置的负担轻，所以即使在BD-J模式上执行MOVIE模式也可不会产生任何问题。这是因为在再现装置和视频作品的开发时，在一个模式下完成动作保证。 

进一步，也可仅在BD-J模式下执行再现处理。如第五实施方式所示那样，由于可以在BD-J模式下进行与PL的再现同步的再现控制，所以是不用强制设置MOVIE模式的理由。 

(L)也可通过在应多路复用在AVClip上的交互图像流上设置导航指令，来实现从某个PL向其他PL的分支。 

产业上的可用性 

本发明的再现装置可以在如家庭影院系统中使用那样，可以在个人用途中使用。但是本发明在上述实施方式中公开了内部结构，由于根据该内部结构可以批量生产，所以实质上可以在工业上使用。由此，本发明的再现装置具有产业上的可利用性。 

Claims (2)

1.一种再现装置，进行标题再现和应用程序执行，所述再现装置中装载有记录媒体，所述记录媒体在其上记录有索引表、多个操作模式对象、多个播放列表和多个应用程序，其中，

所述多个应用程序中的每一个是按每个标题来管理生存区间的Java语言程序；

所述多个播放列表中的每一个是由数字流和路径信息规定的再现单元，所述路径信息规定所述数字流的再现路径；

所述索引表表示所述记录媒体上可选择的多个标题与所述多个操作模式对象之间的对应；

所述多个操作模式对象中的每一个规定第二模式中的控制过程，所述第二模式是两种模式中的第二种，其中的第一模式是所述再现装置以命令为基础进行操作的模式，所述第二模式是所述再现装置以应用程序为基础进行操作的模式，并且所述多个操作模式对象中的每一个包括：(i)应用程序管理表，表示其生存区间是与每个操作模式对象相对应的标题的应用程序；以及(ii)播放列表管理表，表示播放列表的指定和所指定的播放列表的再现属性；以及

所述再现装置包括：

模块管理器，用于从所述索引表中表示的所述标题中选择标题；

再现控制引擎部，用于再现所述播放列表；以及

虚拟机部，用于执行所述应用程序；

其中，所述再现属性表示是否在选择所述标题的同时开始再现所指定的播放列表，以及

当所述再现属性为自动再现时，所指定的播放列表被定义为在选择所述标题的同时再现的缺省播放列表。

2.如权利要求1所述的再现装置，其中，

即使与所述缺省播放列表对应的应用程序被应用程序管理器强制终止，所述再现控制引擎部也继续所述缺省播放列表的所述再现。

Images