重放装置和重放方法

专利名称：重放装置和重放方法
技术领域：
本发明涉及“虚拟包”的重放技术。
背景技术：
“虚拟包”是用于以下的技术(i)生成完整地指示在只读记录介质(例如BD-ROM)上记录的内容以及在可读写记录介质(例如硬盘上)记录的内容的信息，以及(ii)重放或执行记录在这些记录介质上的数字流和应用程序(以下简称为应用程序)，就好像其被记录在一个虚拟的包中一样。
根据该技术，通过对记录在可重写硬盘上的数据进行更新，即使是在BD-ROM发行之后，也可以将产品的内容作为整个虚拟包而改变。例如，即使是记录有电影产品本身的BD-ROM发行之后，该电影产品的提供商也能够通过经由网络提供其他未发表电影产品的电影宣传片，向用户做最近电影产品的广告，不管什么时候发行该BD-ROM。
在以下专利文件中公开了涉及虚拟包的现有技术。
国际公开WO 2004/030356A1。

发明内容
本发明要解决的问题硬盘是可重写的事实暗示可以窜改硬盘上所记录的数据，并且存在提供商和用户受到不利情况的可能性。例如，这种不利情况包括，在BD-ROM上记录的数字流可能在违反提供商意愿的状态下被重放，从而可能降低产品的价值，并且BD-ROM上记录的数字流可能在执行硬盘上记录的非法应用程序的状态下被重放，从而使得重放装置遇到故障。
本发明的目的在于提供一种重放装置，其能够防止在可重写记录介质上记录的非法数据被执行，或者与只读记录介质上记录的数据组合地被播放。
解决问题的方法为了实现上述目的，本发明提供了一种重放装置，其重放相互结合的应用程序和数字流，所述重放装置包括读出单元，其用于读出安置在所述重放装置上的只读记录介质上记录的文件；存储单元，其中存储(i)多个文件，(ii)合并管理信息，其从所述多个文件中指定要与在所述只读记录介质中记录的内容组合使用的文件，以及(iii)签名信息，其用于判断所述合并管理信息的可靠性；判断单元，其用于根据所述签名信息判断所述合并管理信息的可靠性；包管理单元，其用于(a)在所述合并管理信息被判断为可靠的情况下，生成包信息，所述包信息指示通过将所述合并管理信息所指定的文件加入到所述只读记录介质的文件结构中而获得的新文件结构，以及(b)在所述合并管理信息被判断为不可靠的情况下，不生成指示所述新文件结构的包信息；重放单元，其用于根据由所述包管理单元所生成的包信息，重放记录在所述只读记录介质上或者存储在所述存储单元中的数字流；以及执行单元，其用于根据由所述包管理单元所生成的包信息，执行记录在所述只读记录介质上或者存储在所述存储单元中的应用程序。
本发明的效果采用以上布置，根据本发明的重放装置根据签名信息验证合并管理信息的可靠性，并且在所述合并管理信息不能被确认为可靠时，所述重放装置禁止从所述存储单元中存储的文件生成包信息。
采用该布置，可以防止在只读记录介质中记录的数据被与非法数据组合地执行或者重放。


图1示出了根据本发明的重放装置的使用形式；
图2示出在BD-ROM上的文件目录结构；图3示意性地示出如何构建AVClip；图4示出PL信息的结构；图5示出在AVClip时间轴与PL时间轴之间的关系；图6示出了采用4个Clip_Information_file_name的成批指定(batch specification)；图7示出了PLmark信息的内部结构；图8示出了使用PLmark的章节定义；图9示出了SubPath信息的内部结构；图10示出了在SubPlayItem时间轴上的同步指定和重放间隔定义；图11A示出了Java档案(archive)文件中包含的程序和数据；图11B示出类文件的内部结构；图12示出了BD-J对象的内部结构；图13示出了INDEX.BDMV的内部结构；图14示出了本地存储器的目录结构；图15示出了由本地存储器中的PL信息所定义的PlayList重放时间轴类型；图16A示出了在BD-ROM上和在本地存储器中存储的应用程序和AVClip；图16B示出了由在BD-ROM上和在本地存储器中存储的应用程序和AVClip所构成的标题；图17示出了合并管理信息文件的内部结构；图18示出了根据本发明的重放装置的内部结构；图19以层的形式示出了在指令ROM 21中存储的软件和硬件所构成的配置；图20示出了Java虚拟机30的内部结构；图21示出了重放状态的变换；图22示出了要由虚拟文件系统单元38执行的虚拟包信息的示例性结构；
图23A示出了整个光盘的时间轴；图23B示出了整个光盘的时间轴的结构；图24示出如何由于标题变化而更新虚拟包信息；图25示意性地示出Java应用程序是如何请求服务器传送构成虚拟包的文件的；图26示意性地示出Java应用程序是如何将从服务器传送来的文件存储到本地存储器中的；图27示意性地示出Java应用程序是如何请求虚拟文件系统更新虚拟包信息的；图28示意性地示出是如何对虚拟包信息进行更新的；图29是示出模块管理器33执行的标题重放控制的处理的流程图；图30是示出重放控制引擎32所执行的PlayList重放处理的处理过程的流程图；图31是示出要由Java应用程序执行的、下载构成虚拟包的文件的过程的流程图；图32是示出虚拟文件系统单元38所执行的准备处理的流程图；图33是示出由虚拟文件系统单元38所执行的更新处理的流程图；图34是流程图，示出了当由于标题调用而将当前标题的重放临时暂停时由重放控制引擎所执行的处理过程，以及当原始播放的标题的重放继续时由重放控制引擎所执行的处理过程；图35是虚拟包管理表的示例；图36是示出根据第三实施例，用于构建虚拟包的处理过程的流程图；图37是示出控制对文件的写入访问的API的处理过程的流程图；图38示出了在构成虚拟包的文件之一具有错误的情况下，如何生成错误被校正的校正文件；图39是示出根据第四实施例，用于构建虚拟包的处理过程的流程图；
图40是流程图，示出了在已经构建了虚拟包之后在对本地存储器中的文件进行写入访问的情况下，提供文件I/O功能的API的处理；图41示出了根据第五实施例的重放装置的内部结构；图42示出了根据第五实施例的虚拟包管理表的示例；图43是示出将下载的文件记录到本地存储器中的处理过程的流程图；图44是示出根据第五实施例，用于构建虚拟包的处理过程的流程图；图45示出了根据第六实施例的虚拟包构建的示例；图46是示出根据第六实施例，用于构建虚拟包的处理过程的流程图；图47是示出将文件移动到ACTIVE目录中的处理过程的流程图；图48是示出根据第六实施例，控制对文件的写入访问的API的处理过程的流程图；图49示出根据第七实施例的虚拟包的构建的示例；图50示意性地示出了是如何采用在SHARED目录下的ACTIVE目录和在disc#1目录下的ACTIVE目录构建虚拟包的；图51是示出了根据第七实施例，用于构建虚拟包的处理过程的流程图；图52描述了构建中间文件结构的过程；图53是详细示出图51中步骤S184中的处理的流程图；图54是示出虚拟文件系统单元38如何将本地存储器中的文件提供给其他模块的流程图；图55示意性地示出了在根据第九实施例的虚拟包构建过程中的显示；图56示出了在根据第九实施例的虚拟包构建处理中的失败显示；图57示意性地示出了在根据第九实施例的虚拟包构建处理中的成功显示；
图58是示出用于对与虚拟包的构建有关的显示进行更新的处理过程的流程图；以及图59示出了根据第九实施例的在本地存储器中的内容列表的显示。
具体实施例方式
第一实施例以下描述与本发明有关的重放装置的实施例。首先，描述与本发明有关的重放装置的实现形式中的使用形式。图1示出了与本发明有关的重放装置的使用形式。在图1中，与本发明有关的重放装置是重放装置200。重放装置200用于在包含重放装置200、遥控器300和电视机400的家庭剧场系统中提供电影作品。
在此完成了对与本发明有关的重放装置的使用形式的描述。接下来要描述的用于由与本发明有关的重放装置进行的重放的记录介质。与本发明有关的重放装置所播放的记录介质是BD-ROM。图2示出了BD-ROM的内部结构。
BD-ROM在图2的第四层级(tier)示出，而BD-ROM上的轨道(trace)在第三层级示出。图2所示的轨道源自从已经被画出各面的BD-ROM的内圆周螺旋至外圆周的轨道。该轨道包含导入区、卷区以及导出区。图2中的卷区具有包括物理层、文件系统层以及应用层的分层结构。采用目录结构表示的BD-ROM的应用格式给出了图2中的第一层级。BDMV目录放置在BD-ROM中的第一层级的ROOT目录下。
在BDMV目录下存在INDEX.BDMV文件和五个子目录，分别为PLAYLIST目录、CLIPINF目录、STREAM目录、BDJA目录和BOBJ目录。
STREAM目录存储形成主要数字流的文件，将扩展名“M2TS”指定给该文件(00001.M2TS)在PLAYLIST目录中存在扩展名指定为“MPLS”的文件(00001.MPLS)。
在CLIPINF目录中存在扩展名为“CLPI”的文件(00001.CLPI)。
在BDJA目录中存在具有扩展名为“JAR”的文件(00001.JAR)。
在BOBJ目录中存在具有扩展名为“BOBJ”的文件(00001.BOBJ)。
接下来描述这些文件<AVClip>
首先描述具有扩展名“M2TS”的文件。图3示意性地示出了具有扩展名“M2TS”的文件是如何构建的。每个具有扩展名“M2TS”的文件(00001.M2TS、00002.M2TS、00003.M2TS、...)存储AVClip。通过多路复用TS包来构成AVClip(中间层级)，TS包是通过将包含多个视频帧(图像pj1、pj2、pj3)的视频流和多个音频帧(上面第一层级)首先转换为PES包(上面第二层级)，然后转换为TS包(上面第三层级)，以及以相同方式将字幕显示图形流(下面第一层级的PG流)和对话交互图形流(下面第一层级的IG流)转换为TS包(下面第三层级)而得到的。
除了通过图3所示的多路复用获得的AVClip之外，还存在不是从多路复用得到的AVClip。这些AVClip称为子剪辑(SubClip)，包括组成音频流、图形流或者文本字幕流(TextSTStream)的AVClip。
<剪辑信息>
具有扩展名“CLPI”的文件(00001.CLPI)是与AVClip相对应的一条剪辑信息。剪辑信息，即管理信息，包括EP_map，EP_map示出了在AVClip中的流的GOP的头位置和诸如编码格式、帧频、比特率和分辨率等等之类的信息。
<播放列表信息>
具有扩展名“MPLS”的文件(00001.MPLS)存储播放列表(PL)信息。PL信息通过查询AVClip来定义播放列表。在图4的左侧示出了PL信息的结构，其包括主路径信息、PLMark信息和子路径信息。
主路径信息“MainPath()”包括播放项目信息“PlayItem()”，用箭头mp1指示。播放项目是通过在一个或多个AVClip时间轴上指定In_time和Out_time所定义的重放间隔。由多个播放间隔组成的播放列表(PL)是通过放置多条播放项目信息来定义的。图4中的箭头mp2示出了播放项目信息内部结构的特写(close up)。如图4所示，播放项目信息包括In_time、Out_time和示出相应AVClip的Clip_Information_file_name。图5示出了AVClip与PL之间的关系。第一层级示出了AVClip的时间轴，而第二层级示出了PL的时间轴。PL信息包括3条播放项目信息(PlayItem#1-#3)，PlayItem#1、#2和#3的In_time和Out_time定义三个播放间隔。当三个重放间隔排列成线时，对AVClip定义了的不同的时间轴。这就是第二层级的PL时间轴。因此通过在播放项目信息中的定义，能够对AVClip定义不同的时间轴。
通常，每次指定一个AVClip，但是也可以进行多个AVClip的成批指定。使用播放项目信息中的Clip_Information_file_name执行AVClip的成批指定。图6示出了使用4个Clip_Information_file_name的AVClip成批指定。图中的第一层级到第四层级示出了4个AVClip时间轴(AVClip#1-#4的时间轴)，第五层级示出了PL时间轴。4个时间轴采用在播放项目信息中包含的所述4个Clip_Information_file_name来指定。这允许由In_time和Out_time定义4个可选择播放的重放间隔。因此，在PL时间轴上定义由多条可转换角度的视频(所谓的多角度间隔)组成的间隔。
PLmark信息“PLmark()”指定在PL时间轴上的任意间隔为章节。图7示出了PLmark结构的内部结构，其包括ref_to_PlayItem_Id和Mark_time_stamp，如图7中的箭头pm1所指示。图8示出了使用PLmark的章节定义。图8中的第一层级示出了AVClip时间轴，而第二层级示出了PL时间轴。图8中的箭头pk1和pk2示出了播放项目(ref_to_PlayItem_Id)和Plmark中的时间点(Mark_time_stamp)的指定。作为这些指定的结果，在PL时间轴上定义了3个章节(章节#1-#3)。在此完成了PLmark的描述。接下来描述子路径信息。
子路径信息“SubPath()”通过指定子剪辑时间轴上的In_time和Out_time来定义一个或多个重放间隔，并且其具有图9所示的内部结构。子路径信息包括箭头sh1所指示的子播放项目信息“SubPlayItem()”。在箭头sh2标记的特写中，子播放项目信息包括Clip_Information_file_name、In_time、Out_time、sync_PlayItem_Id和sync_Start_PTS_of_PlayItem。采用Clip_Information_file_name、In_time和Out_time指定在子剪辑时间轴上的In_time和Out_time。sync_PlayItem_Id和sync_Start_PTs_of_PlayItem用于将在子剪辑时间轴上的重放间隔与PL时间轴进行同步。这就允许在子剪辑时间轴和PL时间轴两者上相互同步地进行处理。
图10示出在子剪辑时间轴上的重放间隔的同步指定和定义。图10中的第一层级示出了PL时间轴，第二层级示出了子剪辑时间轴。图10中的SubPlayItem.In_time和SubPlayItem.Out_time分别示出了重放间隔的开始和结束。因此显然，也在子剪辑时间轴上定义重放间隔。由箭头Sn1标记的sync_PlayItem_Id示出了播放项目的同步指定，由箭头Sn2标记的sync_Start_PTs_of_PlayItem示出了在PL时间轴上的播放项目中的时间点的指定。
在BD_ROM中的PL信息的特征在于，其使得可以定义使AVClip能够被切换的多角度间隔和使AVClip和子剪辑能够被同步的同步间隔。剪辑信息和PL信息被分类为“静态脚本(static scenarios)”。
以下描述“动态脚本”。在此，“动态”指由于在重放装置200中的用户键事件和和状态改变等等造成的重放控制内容的改变。采用BD_ROM，能够采用与Java应用程序相同的描述来描述重放控制。即，采用BD_ROM，Java应用程序作为动态脚本。
<Java应用程序>
以下描述Java应用程序。Java应用程序包括加载在虚拟机的堆区域(也称为工作存储器)中的一个或多个xlet程序。应用程序由工作存储器中加载的xlet程序以及数据构成。在此完成了对Java应用程序结构的描述。
Java应用程序的实体是在图2中的BDMV目录下的BDJA目录中存储的Java档案文件(00001.jar，00002.jar)。以下参考图11描述Java档案文件。
<Java档案文件>
Java档案文件(图9中的00001.JAR)是一个或多个类文件和数据文件等的集合。图11A示出了在档案文件中收集的程序和数据。图11A中的数据是由Java存档器(archiver)收集并排列在帧中所示的目录结构中的多个文件。该目录结构包括Root目录、Java目录和image目录，common.pkg文件放置在Root目录中，类文件(aaa.class，bbb.class)放置在Java目录中，menu.jpg文件放置在image目录中。Java档案文件是Java存档器将这些文件收集在一起的结果。当将类文件和数据从BD ROM读入到高速缓冲器中时，展开类文件和数据，并在高速缓冲器中将其看作存在于目录中的多个文件。在Java档案文件的文件名中的5位(five-digit)数值“zzzzz”示出了Java档案文件的ID，BD-J对象指使用这种值的Java档案文件。通过在已经将Java档案文件读入高速缓冲器时查询在文件名中的该数值，就可以提取构成任意Java应用程序的数据和程序。
图11A中的类文件与上述xlet程序相对应。采用由Java操作环境所支持的操作模式(BD-J模式)的重放过程规定使用与这些类文件的实例相对应的xlet程序。xlet程序是能够采用Java多媒体框架(JMF)接口的Java程序，并且其根据JMF等等、基于键事件来执行播放列表重放处理。
此外，xlet程序还能够执行访问WWW站点和下载内容的过程。这实现了通过将所下载内容与播放列表相混合创建的原始作品的重放。
接下来描述xlet程序的类文件。图11B示出了类文件的内部结构。如图11B所示，该类文件与普通类文件类似，具有常数池、接口、方法1、2、3、....n。在重放装置200中，在类文件中的方法包括由预先记载的键事件所触发的那些方法(时间监听器)和用于调用函数API(应用程序接口)的那些方法。通过采用分配给给定方法的局部变量和在调用该方法时出现的自变量，来描述在这些方法中的计算过程等等。在此完成了对Java档案文件的描述。
接下来描述具有扩展名“BOBJ”的文件。该文件存储BD-J对象。BD-J对象是通过将在播放列表中定义的AVClip序列与应用程序相关联来定义标题的信息。图12示出了BD-J对象的内部结构。BD-J对象示出了“应用程序管理表”和“播放列表信息参考值”。应用程序管理表通过枚举应用程序标识符(应用程序ID)和构成该应用程序的档案文件的ID，示出了其生命周期为标题的每个应用程序。换而言之，一个应用程序包括一个或多个Java档案文件。“播放列表信息参考值”示出了当标题开始时同时被重放的播放列表信息。
在此完成了对具有扩展名“BOBJ”的文件的描述。
应该注意的是，在以下列出的国际公开中，公开了对BD-J对象和应用程序管理表的描述，参考该公开以进行进一步详细描述国际公开WO 2005/045840接下来描述INDEX.BDMV文件。
INDEX.BDMV是整个BD-ROM的管理信息，包括诸如组织ID和光盘ID之类的信息，其中组织ID是标识电影产品提供商的标识符，光盘ID是为由提供商所提供的每个BD-ROM指定的标识符。当将光盘插入重放装置时，首先读出INDEX.BDMV，这样重放装置就一一对应地识别出光盘。另外，INDEX.BDMV包括一个表格，其相互对应地示出了在BD-ROM中的多个可播放标题和规定各标题的BD-J对象。以下描述可以记录在BD-ROM中的标题类型，其包括FirstPlayTitle、Top_menuTitle和Title#1、#2和#3。
在进行任何其他事情之前，在加载BD-ROM时，FirstPlayTitle承担播放BD-ROM的动态商标。因此，在加载BD-ROM时，FirstPlayTitle实现播放象征电影作品的制片商和/或者发行者的动态商标。
Top_menuTitle包括AVClip和用于播放在BD-ROM中的菜单分层的极顶部所放置的菜单的应用程序。
Title#1、#2和#3是与普通电影作品相对应的标题。因此，INDEX.BDMV是示出诸如FirstPlayTitle、Top_menuTitle、Title#1到#3之类的标题与单个BD-J对象的对应关系的文件。
图13示出了INDEX.BDMV的内部结构。如图所示，INDEX.BDMV包括多条标题信息，例如“FirstPlayTitle信息”、“Top_menuTitle信息”、“Title#1信息”、“Title#2信息”和“Title#3信息”。每条标题信息示出在标题号与规定标题的BD-J对象之间的对应关系。采用这样一条标题信息，就可以指定定义标题的BD-J对象，采用这种BD-J对象，就可以使得播放列表信息与应用程序相互结合地工作。因此完成对INDEX.BDMV的描述。
在以下列出的国际公开中，公开了对INDEX.BDMV的详细描述，参考该公开以进行进一步详细描述国际公开WO 2004/025651BD-ROM不是用于本发明的重放装置的唯一记录介质。磁记录装置(本地存储器)，诸如重放装置中内置的硬盘，也可用于本发明的重放装置。以下描述了在这种本地存储器上记录的数据。
图14示出了在本地存储器中的目录结构。
在这种目录结构中，子目录“organization#1”位于ROOT目录下，并且在该目录下是子目录“disc#1”和“disc#1”。将“organization#1”目录分配给特定的电影作品提供商。将“disc#1”和“disc#1”目录分别分配给由该提供商所提供的BD-ROM。在每个BD-ROM的INDEX.BDMV中指示的组织ID和光盘ID的值用于目录名。
在与特定提供商相对应的目录中提供与BD-ROM相对应的目录，允许分别存储与单个BD-ROM相关的下载数据。在这些子目录下存储播放列表信息、剪辑信息和AVClip，与BD-ROM中所存储的类似。还额外存在Java档案文件、合并管理信息文件和签名信息文件。
与在BD-ROM上的播放列表信息相比，在BD-ROM上播放列表仅仅指AVClip，而在本地存储器中的播放列表信息(在虚拟包中新加入的播放列表信息)指在BD-ROM上的AVClip和本地存储器18中的AVClip。
在此，描述了本地存储器中的播放列表信息由4条播放列表信息(播放项目信息#1-#4)构建的情况。在头条信息指在BD-ROM上的剪辑信息而剩余三条信息指在本地存储器中的信息的情况下，该播放列表信息从在BD-ROM上的AVClip和在本地存储器中的AVClip来定义单一流序列，如图15所示。
图15示出了由存储在本地存储器中的PL信息所定义的播放列表重放时间轴的种类。第一层级示出了在BD-ROM上存储的AVClip的重放时间轴，第二层级示出了在本地存储器中存储的PL信息中定义的播放列表的重放时间轴。第三层级示出了在本地存储器中存储的AVClip#3的重放时间轴。第四层级示出了在本地存储器中存储的AVClip#4的重放时间轴。第五层级示出了在本地存储器中存储的AVClip#5的重放时间轴。
在播放列表信息中的播放项目中，在播放项目信息#2、#3和#4指定AVClip#2、#3和#4作为重放间隔的情况下，播放列表信息能够将在BD-ROM上的AVClip和在本地存储器18中的AVClip两者规定为单一流序列。
如上所述，可以将在BD-ROM上的AVClip和在本地存储器18中的AVClip两者规定为单一流序列，并且通过将该流序列与在BD-ROM上或者本地存储器中的应用程序组合，可以从这些AVClip和从在BD-ROM上或者在本地存储器中记录的应用程序构建单一标题。在如图16A所示，在AVClip#1被记录在BD-ROM上并且AVClip#2到#4和应用程序被记录在本地存储器中的情况下，可以将这些AVClip和应用程序看作单一标题，如图16B所示。
接下来描述合并管理信息文件。该合并管理信息文件总体示出了构成虚拟包的所有这些文件，并且其在本地存储器中的disc#1和disc#2目录中。
图17示出了合并管理信息文件的示例性内部结构。合并管理信息文件包括与在本地存储器中的构成虚拟包的文件相关的存储位置信息。对于每个文件而言，该存储位置信息包括指示在本地存储器18中的文件的存储位置的文件路径，和指示从在该文件中的数据确定的并使用单向函数计算的文件的散列值的“散列值”。
接下来描述签名信息文件。签名信息文件示出了在合并管理信息文件上的提供商的电子签名。通常采用的电子签名是通过计算需要窜改验证(tamper-proof)的信息的散列值并使用某种密钥对该散列值进行加密来获得的。在根据本实施例的签名信息文件中，使用与重放装置持有的合并证书中的公钥相对应的密钥，对合并管理信息文件的散列值进行加密。
应该注意的是，合并证书是用于验证合并管理信息文件的证书，并且其包括提供商所发布的公钥。预先将提供商所提供的合并证书并入重放装置中。作为示例，对于合并证书的文件格式而言，可以使用X.509。X.509的详细说明写入在国际电报电话咨询委员会公布的CCITT Recommendation X.509(1988)，“The Directory-AuthenticationFramework”中。
应该注意的是，尽管以上描述示出预先将合并证书并入重放装置中，但是将合并证书记录在BD-ROM上也是可接受的。可替换地，从通过因特网提供合并证书的服务器装置中下载并获得合并证书也是可接受的。
在此完成了对记录介质的描述。以下描述与本发明相关的重放装置的内部结构。
<重放装置>
图18示出了本发明的重放装置的内部结构。本发明的重放装置可以根据图中所示的内部结构进行工业制造。本发明的重放装置主要包括两个部分，例如系统LSI和驱动装置，并且其可以通过将这些部分安放在重放装置的箱体中和安放在基板上进行工业制造。系统LSI是集成电路，在该集成电路中集成了用于实现重放装置功能的各种处理单元。采用这种方式制造的重放装置包括BD-ROM驱动器1、读缓冲器2、多路分解器3、视频解码器4、视频平面5、P图形解码器6、显示图形平面(presentation Graphic plane)7、组合单元8、字体生成器9、I图形解码器10、开关11、交互图形平面12、合成单元13、CLUT单元14、CLUT单元15、音频解码器16、网络设备17、指令ROM 21、用户事件处理单元22、PSR组23、CPU 24、脚本存储器25、本地存储器26和开关27。
首先描述与记录在BD-ROM上的AVClip的重放有关的组成组件(BD-ROM驱动器1至音频解码器16)。
BD-ROM驱动器1加载/退出，以及访问BD-ROM。
读缓冲器2是先进先出(FIFO)存储器，在该存储器中，根据先进先出存储从BD-ROM或者本地存储器18中读出的传输流(TS)包。
多路分解器(De-MUX)3从读缓冲器2中取出TS包，并将这些TS包转换为PES包。然后，在通过该转换获得PES包中，将具有由CPU 24设定的PID的PES包输出到视频解码器4、P图形解码器6、I图形解码器10以及音频解码器16中的一个。
视频解码器4对从多路分解器3输出的PES包进行解码，以获得未压缩格式的图像，并将这些图像写入视频平面5。
视频平面5用于存储未压缩图像。平面是在重放装置中的存储区，用于存储一个屏幕大小的像素数据。视频平面5具有1920×1080分辨率，所存储的图像数据由采用16比特YUV表示的像素数据构成。在视频平面5中，在视频流中的重放视频图像能够对于每帧进行缩放。缩放包括将每帧的重放视频图像改变为完整视频平面5的1/4(四分之一)或者1/1(全比例)。缩放是根据来自CPU 24的指令采用BD-J模式执行的，实现了屏幕的产生，从而将视频流的重放图像缩小到屏幕的角落或者投影到整个屏幕。
P图形解码器6对从BD-ROM中读出的显示图形流进行解码，并将未压缩图形写入显示图形平面7。作为对图形流解码的结果，字幕出现在屏幕上。
显示图形平面7是具有用于一屏大小数据的空间的存储器，其能够存储一屏大小的未压缩图形。该平面具有1920×1080的分辨率，在显示图形平面7中的未压缩图形的像素由8比特索引颜色来表示。在通过采用CLUT(颜色查询表)转换索引颜色，来将显示图形平面7中存储的的未压缩图形用于显示。
合成单元8将在视频平面5中存储的未图像数据(i)与显示图形平面7中所存储的进行合成。
字体生成器9使用字符字体扩展在位图中的textST流中包含的文本代码，并将所扩展的代码写入显示图形平面7。
I图形解码器10采用DVD-like模式对从BD-ROM或者本地存储器18中读出的IG流进行解码，并且将未压缩图形写入交互图形平面12。
开关11选择性地将由字体生成器9生成的字体序列和由P图形解码器6的解码得到的图形中的一个写入到显示图形平面7。
交互图形平面12被写有由I图形解码器10解码得到的未压缩图形。将由应用程序画出的字符和图形采用αRGB全彩色并采用BD-J模式写入到交互图形平面12中。
合成单元13将在交互图形平面12中所存储的内容与从合成单元8输出的合成图形进行合成(即，未压缩图像数据与在显示图形平面7中所存储的内容的合成)。该合成使得由应用程序写入到I图形解码器10中的字符和图形覆盖到未压缩图像数据上并进行显示。
CLUT单元14将在视频平面5中存储的未压缩图形中的索引颜色转换为Y、Cr、Cb值。
当采用DVD-like模式工作时，CLUT单元15将在交互图形平面12中存储的未压缩图形中的索引颜色转换为Y、Cr、Cb值。当采用BD-J模式工作时，CLUT单元15将αRGB全彩色转换为Y、Cr、Cb。
音频解码器16对从多路分解器3输出的PES包进行解码，并输出未压缩音频数据。
在此完成了对与AVClip重放有关的构成组件的描述。以下描述与BD-J模式工作有关的构成组件(网络设备17至De-MUX 20)网络设备17实现了在重放装置中的通信功能。在应用程序采用BD-J模式指定URL的情况下，网络设备17与该URL指示的站点建立TCP连接、FTP连接等等。作为所述连接被建立的结果，使得Java应用程序能够从该站点进行下载。
本地存储器18是硬盘，用于存储元数据以及从通信和BD-ROM之外的记录介质提供的内容，例如通过由网络设备17建立的连接从站点下载的内容。元数据是用于绑定和管理在本地存储器18中的所下载内容的信息。通过访问本地存储器18，采用BD-J模式的应用程序能够使用所下载内容执行各种处理。
读缓冲器19是FIFO存储器，其在子剪辑包含在BD-ROM上或者在本地存储器18中所存储的内容中的情况下，基于先进先出存储组成子剪辑的TS包。
多路分解器(De-MUX)20从读缓冲器19中取出TS包，并将所读出的TS包转换为PES包。然后，在通过该转换获得的PES包中，将具有所期望PID的PES包输出到字体生成器9、P图形解码器6和音频解码器16。
上述组件，即网络设备17到De-MUX 20使得Java应用程序通过网络下载的内容能够采用与在BD-ROM中所记录的内容相同的方式进行重放。以下描述了在重放装置中用于实现集体控制的构成组件(指令ROM 21一开关27)。
指令ROM 21存储规定与重放装置相关的控制的软件。
用户事件处理单元22响应于遥控器或者重放装置的前面板的键操作，将用于执行这些操作的用户事件输出到CPU 24。
PSR组23是重放装置中内置的电阻器，其包括64个独立的播放器状态寄存器(PSR)和4096个独立的通用寄存器(GPR)。PSR4到PSR8是表示当前重放时间点的PRS。
通过将PSR4设定为1-100的值，来指示当前重放点的标题。当将PSR4设定为“0”时，意味着当前重放点为顶部菜单。
通过将PSR5设定为1-999的值，来指示当前重放点的章节号。当PSR5设定为“0xFFFF”时，意味着在重放装置中的章节号为空。
通过将PSR6设定为0-999的值，来指示当前重放点所属的PL(当前PL)号。
通过将PSR7设定为0-255的值，来指示当前重放点所属的播放项目(当前播放项目)号。
通过将PSR8设定为0-0xFFFFFFFF的值，来指示使用45KHz时间精度的当前重放点(当前显示时间或者“PTM”)。PSR4到PSR8使得能够在整个BD-ROM的时间轴上指定重放的当前时间点。
CPU 24运行在指令ROM 21中存储的软件，以执行与整个重放装置相关的控制。这些控制根据从用户事件处理单元22输出的用户事件和在PSR组23中的PSR设定值而动态改变。
脚本存储器25用于存储当前PL信息和当前剪辑信息。当前PL信息是当前用于处理的BD-ROM中所记录的该条PL信息。当前剪辑信息是当前用于处理的BD-ROM中所记录的该条剪辑信息。
本地存储器26是高速缓存器，用于在从BD-ROM的读出速度慢时，暂时存储在BD-ROM上所记录的内容。本地存储器26的提供允许采用BD-J模式的应用程序高效运行。
开关27选择性地将从BD-ROM和本地存储器18读出的数据传递到读缓冲器2、读缓冲器19、脚本存储器25和本地存储器26中的一个。
因此完成对本发明的重放装置的硬件配置的描述。以下将描述本实施例的重放装置中的软件结构。
图19采用层结构形式示出了在指令ROM 21中存储的软件和硬件构成的配置。如图所示，重放装置的层结构包括以下(a)第一层，用于BD播放器设备(b)第二层，用于BD播放器模型以及(c)第三层，用于应用程序运行时间环境在这些层中，图18所示的重放装置的硬件配置属于第一层。图18所示的硬件结构中，图“BD播放器设备”中所示的第一层包括“解码器”，其包括视频解码器4、P图形解码器6、I图形解码器10、音频解码器16；“平面”，其包括视频平面5、显示图形平面7、交互图形平面12；BD-ROM及其文件系统；以及本地存储器18和及其文件系统。
第二层“BD播放器模型”包括以下两个层(b1)和(b2)(b2)用于重放控制引擎32的层；以及(b1)用于虚拟文件系统单元38和显示引擎31的层。
由第二层提供函数API，用于位于其上的层。
在这些层中，图18所示的PSR组23和脚本存储器25在重放控制引擎32中。
第三层“应用程序运行时间环境”包括以下栈层(c2)和(c1)
(c2)存在模块管理器33的层(c1)存在DVD-like模块29a和Java平台29b的层。
以下描述在该软件结构中的构成组件。
<DVD-like模块29a和Java平台29b>
DVD-like模块29a对导航命令进行解码，并根据解码结果执行对于重放控制引擎32的函数调用。
在以下国际申请中公开，在以下列出的国际公开中，公开了与DVD-like模块有关的现有技术和由该DVD-like模块所执行的Movie对象，参考该公开以进行进一步详细描述国际公开WO 2004/074976Java平台29b是所谓的Java平台，具有将以下内容按层排列的结构(d1-1)Java虚拟机30(d1-2)中间设备，用于使得Java虚拟机能够工作<Java虚拟机30>
Java虚拟机30加载将应用程序构建在工作存储器中的xlet程序，对该xlet程序进行解码，并根据解码结果对位于其下的层进行控制。对位于其下的层进行控制，是通过向中间设备发布方法以便将该方法替换为BD重放装置所对应的函数调用，并且在该替换之后将该函数调用发布到重放控制引擎32来实现的。
<Java虚拟机30的内部结构>
以下描述Java虚拟机30的内部结构。图20示出了Java虚拟机30的内部结构。如图所示，Java虚拟机30包括CPU 24、用户类加载器52、方法区53、工作存储器54、线程55a、55b、...55n以及Java栈56a、56b、...56n。
用户类加载器52从本地存储器26等等中的BDJA目录中的Java档案文件中读出类文件，并将所读出的类文件存储在方法区53中。当应用程序管理器36指定文件路径并命令用户类加载器52执行读出时，用户类加载器52读出该类文件。在该文件路径指示本地存储器26的情况下，用户类加载器52将从本地存储器26中的构成应用程序的Java档案文件中的类文件读出到工作存储器54中。在该文件路径指示在文件系统中的目录的情况下，用户类加载器52将从BD-ROM或者本地存储器18中的构成应用程序的Java档案文件中的类文件读出到工作存储器54中。
方法区53中存储由用户类加载器52从本地存储器26中读出的类文件。
工作存储器54是所谓的堆区域，其中存储各种类文件的实例。工作存储器54中存储与称为常驻应用程序的常驻类型应用程序和读入到方法区53中的类文件相对应的实例。这些实例中的每一个都是构成应用程序的xlet程序。当这样的xlet程序位于工作存储器54中时，应用程序变为可执行。
线程55a、55b、...55n是执行的逻辑对象，以执行在工作存储器54中存储的方法。线程55a、55b、...55n使用局部变量或者操作数栈中存储的自变量作为操作数执行计算，并将计算结果存储在局部变量或者操作数栈中。图中的箭头ky1、ky2和kyn示意性示出从工作存储器54向线程55a、55b、...55n提供的方法。尽管执行的物理对象仅仅是CPU，但是存在以下可能性，即在Java虚拟机30中存在多达64个作为执行的逻辑对象的线程。在64或者小于其的范围中，可以新生成线程和删除已有线程。当Java虚拟机30工作时，工作中的线程数量可以增加或降低。由于适当时线程数量可以增加，因此可以采用多个线程并行地执行一个实例，从而以较高速度执行该实例。
Java栈56a、56b、...56n和线程55a、55b、...55n按照一对一成比例存在。Java栈56a、56b、...56n中的每一个在自身中具有程序计数器(图中称为“PC”)和一个或多个帧。“程序计数器”示出了当前正在执行实例的哪个部分。“帧”是分配给对于方法的一个调用的栈类型区，并且其包括其中存储一个调用中的自变量的“操作数栈”，和由所调用方法使用的“局部变量栈”(在图中称为“局部变量”)。在每次进行调用时，将一帧栈入到Java栈56a、56b、...56n上；类似地，当方法进行自身递归调用时，栈入一帧。
因此完成了对Java虚拟机的内部结构的描述。采用这种结构的Java虚拟机用作由事件驱动的执行对象(即事件驱动的执行对象)。因此完成对Java虚拟机的描述<显示引擎31>
显示引擎31执行AV重放功能。重放装置的AV重放功能是源自DVD播放器和/或者CD播放器的传统功能，例如开始重放(播放)、停止重放(停止)、暂停重放(暂停开启)，取消重放暂停(暂停关闭)、取消静音功能(静音关闭)、以指定速度向前(向前播放(速度))，以指定速度回倒(向后播放(速度))、改变音频(音频改变)，改变子图像(字幕改变)、以及改变角度(角度变化)。为了实现AV重放功能，显示引擎31控制视频解码器4、P图形解码器6、I图形解码器10以及音频解码器16，以便对已经输入到读缓冲器2的并且与期望时间相对应的AVClip的部分进行解码。对于这种期望时间，可以通过对由PSR8指示的部分进行解码，来重放与任意时间相对应的AVClip的一部分。
<重放控制引擎32>
重放控制引擎32(PCE 32)执行各种功能，例如(i)对播放列表的重放控制功能，和(ii)获得/设定PSR组23的状态的功能。PL的重放控制功能使在由显示引擎31所执行的AV重放功能中，开始和停止根据当前PL信息和剪辑信息所执行的重放。根据来自DVD-like模块29a-Java平台29b的函数调用来执行这些功能(i)和(ii)。
以下描述由重放控制引擎32执行的处理与由Java虚拟机执行的处理之间的同步。当调用函数时，重放控制引擎32根据PL信息执行处理过程。在要重放的AVClip具有15分钟或者30分钟的重放时间段时，上述处理在该持续时间内持续。问题是，在Java虚拟机30返回成功响应的时刻与重放控制引擎32实际完成处理的时刻之间存在间隙。由于Java虚拟机30是时间驱动的处理的对象，因此其在调用之后立即返回一个指示重放是成功还是失败的响应；然而，重放控制引擎32在15或30分钟之后完成AVClip和播放项目的重放。从而，如果将成功响应返回到应用程序的时刻用作参考点，则不可能检测15或30分钟之后所发生的处理的结束。在PL重放过程中执行快速向前或倒带的情况下，这种15或30分钟的重放时间段向前或向后移动，并且检测处理的结束变得更加困难。为了解决该问题，当播放项目的重放完成时，或者当AVClip的重放完成时，重放控制引擎32输出事件到应用程序，该事件指示播放项目或AVClip的重放完成。由于该输出，应用程序能够找到重放控制引擎32已经完成播放项目或AVClip的重放的时刻。
<模块管理器33>
模块管理器33读出INDEX.BDMV并从在INDEX.BDMV中包含的多条标题信息中选择一条标题信息，作为一条当前标题信息。然后模块管理器33读出该当前标题信息所指示的BD-J对象，并控制重放控制引擎以便根据写入在该BD-J对象中的播放列表信息来执行重放控制。此外，模块管理器33控制Java虚拟机，以便读出并执行写入在该BD-J对象中的Java档案文件。
在此，在完成根据播放列表信息的数字流的重放的情况下，或者在用户调用菜单的情况下，模块管理器33读出定义另一标题的另一条标题信息，以便将该条标题信息选择作为一条当前标题信息。根据数字流的重放或者用户的菜单调用来选择另一条标题信息作为该条当前标题信息的处理将称为“标题转换”。
当这种“标题转换”重放执行时，就可以实现图21所示的状态变换(state shifting)。在图中拉长的圆表示标题。
标题包括当加载BD-ROM时重放的“FirstPlayTitle”、构成顶部菜单的“TOP_menu_Title”、和其他作为普通标题的“Title”。图中的箭头jh1、jh2、jh3、jh4、jh5、jh6、jh7、和jh8用符号指示标题之间的转移。该图中的状态变换是当加载BD-ROM时重放“FirstPlayTitle”，转移到“TOP_menu_Title”，然后等待在顶部菜单中的选择。
光盘内容所特有的状态变换是，重复进行以下处理直到BD-ROM被退出为止当用户执行操作来从菜单中进行选择时，根据该选择重放相应的标题，然后过程返回到TOP_menu Title。这种状态变换是在上述的模块管理器33的控制下实现的。
在以下列出的国际公开中，公开了标题和当前标题的选择，参考该公开以进行进一步详细描述国际公开WO 2005/036555国际公开WO 2005/036540国际公开WO 2005/036547因此完成了对Java虚拟机30、显示引擎31、重放控制引擎32和模块管理器33的描述。
Java虚拟机对重放控制引擎32的控制是通过虚拟包施加的。为了通过虚拟包实现对重放控制引擎32的控制，重放装置包括诸如网络管理模块37、虚拟文件系统单元38、管理信息转换模块39和方法执行模块40之类的构成组件。以下将描述这些构成组件。
<网络管理模块37>
网络管理模块37根据来自应用程序的方法调用，从由电影提供商运作的WWW站点下载构建虚拟包所必需的数据。构建虚拟包所必需的数据包括合并管理信息文件、签名信息文件、替代BD-ROM上文件的文件或者添加到BD-ROM上的文件(例如，播放列表信息、剪辑信息、AVClip和Java档案文件)的文件。当在工作存储器54中的应用程序提出下载请求时，网络管理模块37通过网络下载虚拟包的构建所必需的数据，并将所下载的数据写入到本地存储器18中。
<虚拟文件系统单元38>
虚拟文件系统单元38是属于第二层的构成组件之一，并且其根据来自应用程序的方法调用来构建虚拟包。虚拟包构建处理包括对构建该虚拟包的AVClip的状态管理，和虚拟包信息的生成处理。
1.虚拟包信息虚拟包信息是通过扩展在BD-ROM上记录的卷管理信息获得的。在此所述的卷管理信息是用于定义在记录介质上存在的目录文件结构的信息，其包括关于目录的目录管理信息和关于文件的文件管理信息。
虚拟包信息通过将新文件信息添加到指示BD-ROM上目录文件结构的卷管理信息中，来扩展在BD-ROM上的目录文件结构。要添加到BD卷管理信息中的新的文件管理信息是存储在本地存储器18中的播放列表信息、剪辑信息、AVClip和Java档案文件的文件管理信息。由于已经将这种文件管理信息添加到其中的虚拟包信息被生成并提供给重放控制引擎32，因此重放控制引擎32能够进行识别，就如同存储在本地存储器18中的播放列表信息、剪辑信息、AVClip和Java档案文件是存在于BD-ROM上。图22示出了由虚拟文件系统单元38执行的虚拟包信息的构建的示例。图的左上方是在BD-ROM上的目录文件结构，其与图2所示的相同。图的左下方是本地存储器18的目录文件结构，其与图14所示的相同。根据合并管理信息，将存储在本地存储器18上的播放列表信息、剪辑信息、AVClip和Java档案文件的文件管理信息添加到BD-ROM上的卷管理信息中。
更具体而言，执行以下过程(i)将在本地存储器18中的播放列表的文件管理信息(00002.MPLS)添加到BD卷管理信息中的MPLS目录的目录管理信息中。
(ii)将在本地存储器18中的剪辑信息#2、剪辑信息#3和剪辑信息#4(00002.CLPI、00003.CLPI、00004.CLPI)的文件管理信息添加到BD卷管理信息中的CLPI目录的目录管理信息中。
(iii)将在本地存储器18中的AVClip#2、AVClip#3和AVClip#4的文件管理信息(00002.M2TS、00003.M2TS、00004.M2TS)添加到BD卷管理信息中的STREAM目录的目录管理信息中。
应该注意的是，在BD-ROM上存在与合并管理信息文件所指定的虚拟包中的文件具有相同文件路径的文件的情况下，将在本地存储器中的文件管理信息写在卷管理信息中。采用该安排，将优先在虚拟包中使用存储在本地存储器中并由合并管理信息所引用的文件。
因此，已经获得了虚拟包信息。通过对卷管理信息进行这种添加，获得了虚拟包信息。
将采用这种方式生成的虚拟包信息提供给重放控制引擎32。从而，重放控制引擎32通过指定在访问文件时指示虚拟包的定位器，能够将存储在本地存储器18中的播放列表信息、剪辑信息和AVClip等同地看作记录在BD-ROM上的播放列表信息、剪辑信息和AVClip。
更具体而言，重放控制引擎32使用由虚拟包信息所指示的虚拟包的定位器来请求文件访问。响应于该请求，虚拟文件系统单元38根据合并管理信息文件，判断作为访问请求目标的文件的实体是记录在BD-ROM上还是在本地存储器18中。在判断结果为文件的实体记录在本地存储器18中的情况下，虚拟文件系统单元38将访问请目标转换为由合并管理信息文件指定并存储在本地存储器18中的文件的文件路径。
因此完成对虚拟包信息的生成的描述。
以下将解释虚拟包信息更新的定时。
对按照图21的箭头jh1、jh2、jh3、jh4等等所指示的参考数字的数值的顺序来执行转移，然后退出BD-ROM的情况进行解释。在该情况下，从加载BD-ROM时到退出BD-ROM时的连续时间线能够看作时整个光盘的时间轴。图23A示出了整个光盘的时间轴。图23B示出了该时间轴的配置。如图23B所示，整个光盘的时间轴包括重放FirstPlayTitle的间隔、重放Top_menu Title的间隔、重放标题#1的间隔等等。这些标题的重放间隔是根据以下思路进行定义的由于每个标题是由单个BD-J对象构成的，因此将特定BD-J对象有效的时间段看作一个标题的重放间隔。在标题的重放间隔之间的过渡部分，换而言之，从一个标题转换到另一个标题(以下称为标题变化)处的部分，是更新虚拟包信息的时间段。
图24示出了当发生标题变化时如何更新虚拟包信息。
图24的第一层级示出了在时间轴上的标题的播放间隔。第二层级示出了构成该标题的Java应用程序的执行状态。第三层级示出了数字流的重放状态。第四层级示出了虚拟文件系统单元38的状态。
在第一层级中所示的标题#1的重放时间间隔中，运行和重放由BD-J对象所指定的Java应用程序和AVClip，如第二层级和第三层级所示。在标题的这种重放间隔中更新虚拟包信息的情况下，标题的构成组件在执行处理或者重放处理过程中可以相互改变位置。当构成组件相互改变位置时，重放装置工作异常，并且存在可能发生诸如重放图像中断之类的不可恢复的情况的可能性。
为了处理该情况，当在标题#1的重放过程中请求虚拟包信息的更新时，虚拟文件系统单元38进入“准备中状态”，在其中，在构建虚拟包所必需的处理过程中，仅仅执行一些处理，这些处理在标题的重放时间间隔过程中能够并行处理，而不改变虚拟包的构建组件。在准备中阶段中的处理完成之后，虚拟文件系统单元38变换到“准备”状态并且等待直到发生标题变化。当发生标题变化时，虚拟文件系统单元38进入“更新”状态，在下一个标题的重放间隔之前，通过将由合并管理信息文件所引用的文件的文件管理信息添加到BD卷管理信息中来执行更新虚拟包信息的处理。在更新完成之后，虚拟文件系统单元38进入“稳定”状态，下一个标题的重放开始。在这种状态中，在选择从标题变化后的Top_menuTitle跳转回到标题#1的情况下，将重放标题#1以反映所更新的信息。
如上所述，对于标题变化，由于虚拟包信息被更新，即使是当标题#1正在重放时请求对虚拟包信息的更新，标题的构成组件也不会在标题#1正在重放时改变；因此，在重放过程中就不可能发生异常。
以下将参考图25到28描述虚拟包的构建的细节。
由例如提供商所安装的服务器来提供构成虚拟包的文件。在Java应用程序的控制下，通过诸如因特网之类的网络下载这些文件。应该注意的是，在下载中，使用因特网中通常使用的通信协议，例如HTTP或者HTTPS。
图25示出了Java应用程序如何是如何请求服务器发送构建虚拟包的文件。在图的中间所示的ROOT目录下的目录树指示在本地存储器中的目录结构。Java应用程序请求服务器应该通过发送记录在本地存储器中的合并管理信息文件来下载构成虚拟包的文件。
应该注意的是，当将第一次将BD-ROM安放在重放装置中时，本地存储器中没有记录合并管理信息文件，并且没有虚拟包被构建。在这种要第一次构建虚拟包的情况下，Java应用程序通过向服务器通知光盘ID来请求服务器应该下载构成虚拟包的文件。
接下来，图26示出了Java应用程序是如何将从服务器发送的文件记录在本地存储器中的。
如图26所示，Java应用程序在disc#1目录下生成与该光盘ID相对应的新目录(新MF目录)，并将在响应于该请求而从服务器发送的文件中的新的合并管理信息文件和与该管理信息相对应的签名信息文件，记录到新生成的目录中。其他文件立即记录在disc#1目录下。应该注意的是，通过使用提供文件I/O功能的API将定位器指定到本地存储器中，来执行文件的记录。应该注意的是，如果直接在disc#1目录下的已有合并管理信息文件和签名信息文件没有与要新下载的合并管理信息文件和签名信息文件相同的文件名，则也可以将所下载文件直接记录在disc#1目录下而不生成新的目录。
图27示出了Java应用程序是如何请求虚拟文件单元应该更新虚拟包信息的。如图所示，已经获得构成虚拟包的文件的Java应用程序，使用在新MF目录中记录的新合并管理信息文件的文件路径、签名信息文件的文件路径和光盘ID作为自变量，来调用更新请求方法，从而更新虚拟包信息。
图28示出虚拟包信息是如何更新的。
当调用更新请求方法时，虚拟文件系统单元38转换为准备中状态，执行能够在不改变与当前正在重放的标题相关的虚拟包的构成组件的情况下执行的一些处理。图的左侧所示的目录树示出了在准备中状态中的本地存储器。
更具体而言，在准备中状态下执行以下处理(1)判断由作为自变量的文件路径所指示的新合并管理信息文件是否可靠。
(2)判断由新合并管理信息文件所引用的文件是否存在于指定存储位置处。
(3)将由新合并管理信息文件所引用的文件和新合并管理信息文件的文件属性改变为只读属性。
当完成在准备中状态下执行的这些处理时，虚拟文件系统单元38转换为准备状态。应该注意的是，将要被映射到虚拟包上的在本地存储器中的文件的属性设定为只读属性；因此，在Java应用程序通过使用提供文件I/O功能的API将定位器指定到本地存储器中，来请求应该将数据写入到这些文件中的一些中的情况下，API将返回指示写入不被允许的异常。
当其后标题变化已经发生时，虚拟文件系统单元38将存在于在disc#1目录中的文件替换为新合并管理信息文件和签名信息文件，并在替换之后，通过根据在disc#1目录中的合并管理信息文件将文件管理信息添加到BD卷管理信息中，来将记录在本地存储器中的文件映射到虚拟包上。此时，在本地存储器中的由旧合并管理信息文件引用但不由新合并管理信息文件引用的一些文件的属性从只读属性改变为可读/可写属性。因此完成对虚拟包信息的构建的详细描述。
以下参考流程图，描述根据本发明的重放装置所执行的重放处理的细节。图29是示出由模块管理器33所执行的标题重放控制的处理的流程图。该流程图示出在将BD-ROM安放在重放装置之后和将其退出之前要执行的处理过程。在步骤S11中，将在INDEX.BDMV文件中指定的FirstPlayTitle设定为当前标题，在执行步骤S11的处理之后，执行步骤S12到S21的循环处理。
在步骤S12到S21的循环处理中，在步骤S12到S15中的处理是重放当前标题的过程。在步骤S12，从INDEX.BDMV中获得与当前标题相对应的一条标题信息，将在所获得的标题信息中指定的BD-J对象作为当前BD-J对象。在步骤S13中，控制重放控制引擎32，以便根据其参考值被写入到当前BD-J对象中的一条播放列表信息来执行PL重放。在步骤S14，控制Java平台29b，以便运行其标识符在当前BD-J对象的应用程序管理表中被指定的Java应用程序。在步骤S15，控制Java平台29b，以便终止其标识符没有在当前BD-J对象的应用程序管理表中被指定的其他Java应用程序。
在步骤S16到S19中的处理是用于判断标题是否已经结束的过程。在以下情况之一已经发生的情况下判定标题已经结束完成根据播放列表的PL重放(步骤S16)；标题调用，例如由于用户操作造成的菜单调用指令，已经发生(步骤S17)；诸如脚本转移之类的标题跳转已经发生(步骤S18)；以及作为标题的主要组件的应用程序已经结束(步骤S19)。
在判定标题已经结束的情况下，执行在步骤S20和S21中的处理。根据在步骤S16到S19中的哪一个判定用于确定标题结束，来指定下一个标题(步骤S20)，并将所指定的标题设定为新的当前标题(步骤S21)。作为上述处理的结果，在BD-ROM的插入与退出之间执行标题重放。
以下描述由重放控制引擎32所执行的播放列表重放的细节。图30是流程图，示出了由重放控制引擎32所执行的播放列表重放处理的处理过程。该流程图示出了根据由模块管理器33所命令的一条播放列表信息，从由播放列表所指定的AVClip的开始到结束的重放的处理过程。
首先，在作为指定播放列表信息的实体的MPLS文件是在本地存储器中的已经根据合并管理信息文件进行映射的文件的情况下，检查所指定文件是否被窜改(步骤S31)。在步骤S31中判定所指定文件已经被窜改的情况下，过程退出流程图，从而终止处理。在判定所指定文件没有被窜改的情况下，继续进行步骤S32中和该步骤之后的处理。
在步骤S32中执行如下处理，将在播放列表信息中的第一条播放项目信息设定为要进行处理的一条播放项目信息(以下简称为“播放项目信息i”)，在执行步骤S32的处理之后，执行从步骤S33到S41的循环处理。
在从步骤S33到S41的循环处理中，控制变量是变量i，在步骤S33到S41中的处理被执行后，控制变量i递增(步骤S41)，直到变量i超过播放项目的数量(“播放项目的数量”)在从步骤S33到S41的循环处理中，从步骤S33到S35中的处理是用于重放主路径的处理。在步骤S33的处理中，将写入到播放项目信息i中的Clip_Information_file_name中的AVClip作为用作重放目标的AVClipj。在步骤S34的处理中，在作为写AVClipj相对应的一条剪辑信息的实体的CLPI文件是在本地存储器中的已经根据合并管理信息文件进行映射的文件的情况下，检查在本地存储器中的这一文件是否已经被窜改。当一个或多个文件已经被窜改时，过程退出流程图，从而终止处理。在步骤S35中的处理中，命令驱动装置和解码器重放AVClipj中从PlayItem.In_time到PlayItem.Out_time的部分。
在步骤S36到步骤S39中的处理是用于重放子路径的过程。在步骤S34中，判断是否存在将播放项目信息i指定为Sync_PlayItem_id的子播放项目k。如果其不存在，则过程进入步骤S40如果其存在，则在步骤S37中的处理中，将写入到该子播放项目k的Clip_Information_file_name中的AVClip作为AVClip h。在步骤S38的处理中，在作为与AVClip h相对应的该条剪辑信息的实体的CLPI文件是在本地存储器中的已经根据合并管理信息文件进行映射的文件的情况下，检查在本地存储器中的这一文件是否已经被窜改。当这一文件已经被窜改时，过程退出流程图，从而终止处理。在步骤S39的处理中，命令驱动装置和解码器重放AVClip h中从sync_Start_PTS_of_PlayItem到Out_time的部分，然后过程进入步骤S40。
对构成播放列表信息的所有条播放项目重复上述处理。因此，执行由播放列表所定义的流序列的重放。
应该注意的是，采用以下过程执行在步骤S31、步骤S34和步骤S38中对文件是否已经被窜改的检查，具体而言(a)从合并管理信息文件中读出要检查的文件的散列值。
(b)使用要检查的文件计算散列值。
(c)如果在(a)和(b)中获得的值相等，则判定文件没有被窜改。如果在(a)和(b)中获得的值不相等，则判定文件已经被窜改。
可接受的是忽略对流文件(xxxxx.M2TS)的窜改的检查。原因是因为流文件的文件大小通常比其他文件大，根据文件大小，需要极其长的时间来计算散列值。另外，通常使用记录在BD-ROM上的密钥对该流文件本身进行加密，与其他文件相比，其更加难以被窜改。
以下参考流程图，描述由根据本发明的重放装置所执行的构建虚拟包的过程的细节。将虚拟包的构建划分为三个阶段，例如由Java应用程序下载构成虚拟包的文件、虚拟文件系统单元38进行的准备、以及虚拟文件系统单元38进行的更新。
首先，详细描述要由Java应用程序所执行的构建虚拟包的文件的下载的过程。图31是示出要由Java应用程序所执行的构建虚拟包的文件的下载的过程的流程图。
首先，Java应用程序通过将记录在本地存储器中的、与BD-ROM的光盘ID相对应的目录中的合并管理信息文件发送到服务器，来请求应该发送文件(步骤S291)。在步骤S292，Java应用程序等待直到从服务器接收到文件。应该注意的是，有时在本地存储器中没有记录合并管理信息文件，例如当该BD-ROM是首次安放在该重放装置中时。在该情况下，可接受的是具有以下安排其中在步骤S291的处理中，Java应用程序通过将BD-ROM上的光盘ID通知给服务器，来请求服务器应该发送文件。
当在步骤S292的待命过程中从服务器接收到文件数据时，在步骤S293和S294中将文件记录在本地存储器中。在步骤S293中，在与该光盘ID相对应的目录中生成新目录，并将所接收的合并管理信息文件和签名信息文件记录在该新目录中。在步骤S294，将已经下载的AVClip、剪辑信息、播放列表信息和Java档案文件写入与该光盘ID相对应的目录中。
当已经完成将文件记录在本地存储器中时，Java应用程序使用在新目录中的合并管理信息文件和签名信息文件的文件路径作为自变量，调用更新请求方法(步骤S295)。在步骤S296中，Java应用程序等待从该方法返回的值。
当返回值为FALSE的情况下(步骤S296是)，停止虚拟包的构建过程。当返回值为不是FALSE的情况下(步骤S296否)，虚拟文件系统单元38进入准备状态，并且当转换标题时更新虚拟包(步骤S297)。
以下详细描述要由虚拟文件系统单元38执行的准备处理。图32是示出要由虚拟文件系统单元38执行的准备处理的流程图。
该流程图示出在已经调用上载请求方法的情况下已经转换为准备中状态的虚拟文件系统单元38要执行的处理过程。
在步骤S51中，使用用作调用该方法的自变量的文件路径读出合并管理信息文件和签名信息文件，在步骤S51的处理之后，执行步骤S52到S54中的处理，在处理中，判断构建虚拟包是否是可接受的。
在步骤S52中，判断在步骤S51中读出的合并管理信息文件是否已经被窜改。在该合并管理文件判定为已经被窜改的情况下，将不允许进行虚拟包的构建。
更具体而言，执行以下过程(a)使用重放装置所持有的合并证书中的公钥来解密在签名信息文件中的加密散列值。
(b)计算合并管理信息文件的散列值。
(c)如果通过(a)中的解密过程获得的值等于在(b)中计算得到的值，则判定该合并管理信息文件没有被窜改并且是可靠的。如果通过(a)中的解密过程获得的值不等于在(b)中计算得到的值，则判定该合并管理信息文件已经被窜改并且是不可靠的。
步骤S53是用于判断是否允许调用该方法的Java应用程序来更新虚拟包的处理。在不允许调用者更新虚拟包的情况下，将不允许虚拟包的构建。
步骤S54是用于判断由该合并管理信息文件指定的文件是否实际存在于本地存储器中的处理。在不存在所指定文件的情况下，将不允许虚拟包的构建。
在步骤S52到S54中的一个中判断结果为不允许虚拟包的构建的情况下，将返回值“FALSE”返回到调用该方法的Java应用程序，然后处理终止。
另一方面，在步骤S52到S54中的一个中判断结果为允许虚拟包的构建的情况下，则要执行步骤S55中的处理。
步骤S55是用于读出合并管理信息文件、签名信息文件和由该合并管理信息文件所指定的文件并将它们的属性改变为只读属性的处理。因此完成对准备处理的细节描述。
应该注意的是，在步骤S52到S54中的一个中判断结果为不允许虚拟包的构建的情况下，可以接受的是具有一种安排，其中，将BD-ROM的卷管理信息提供给调用该更新请求方法的Java应用程序作为虚拟包信息，并且终止该更新请求方法的处理。采用该安排，如果合并管理信息文件已经被窜改并且处于非法状态下时，重放装置能够禁止包含本地存储器中的文件的虚拟包的构建，并且重放装置还能够采用与访问虚拟包相同的方式来访问BD-ROM上的文件。
以下将详细描述由虚拟文件系统单元38执行的更新处理。图33是示出由虚拟文件系统单元38执行的更新处理的流程图。
该流程图示出在由于更新请求方法而完成准备处理之后发生标题变化的情况下，由虚拟文件系统单元38所执行的处理过程。
首先，将由作为该方法自变量的文件路径所指定的合并管理信息文件和签名信息文件，移动到与当前正在重放的BD-ROM的光盘ID相对应的本地存储器中的目录中。此时，在该合并管理信息文件和签名信息文件已经存在于作为移动目的地的目录中的情况下，采用新的合并管理信息文件和签名信息文件改写已有文件(步骤S61)。随后，将由在本地存储器18中的合并管理信息文件所指定的一条播放列表信息的文件管理信息，添加到在BD卷管理信息中的PLAYLIST目录中的目录管理信息中(步骤S62)。
随后，执行步骤S63到步骤S67的循环处理。在该循环处理中，对在本地存储器18中存储的多条剪辑信息中的每一个重放在步骤S64到步骤S66中的处理(步骤S63、步骤S67)。
在该循环处理中，将由合并管理信息文件所指定的多条剪辑信息中的一个作为剪辑信息x，将该剪辑信息x的文件管理信息添加到在BD卷管理信息中的CLIPINF目录中的目录管理信息中(步骤S64)。此外，指定与该剪辑信息x相对应的AVClip x(步骤S65)，并且将AVClip x的文件管理信息添加到BD卷管理信息中的STREAM目录的目录管理信息中(步骤S66)。
当对所有条剪辑信息和所有AVClip重复上述处理时，将这些条剪辑信息和AVClip的文件管理信息添加到BD卷管理信息中。将作为该添加的结果而获得的这种BD卷管理信息作为虚拟包信息。将这种虚拟包信息提供给调用该更新请求方法的Java应用程序(步骤S68)，然后处理完成。因此完成对更新处理的细节描述。
如迄今所述，根据本发明，根据签名信息来验证合并管理信息的可靠性。在合并管理信息确认为不可靠的情况下，则防止使用记录在本地存储器中的文件来构建虚拟包。采用该安排，即使是本地存储器中的某些数据已经被窜改而虚拟包的构建没有被执行时，也可以避免执行被窜改的非法数据，和结合记录在只读记录介质上的数据对其进行重放的情况。因此，就不可能遇到由于数据的非法使用所造成的不利情况。
此外，当虚拟包被构建时，将作为可读/可写记录介质的本地存储器中的文件的属性锁定为只读属性；因此，就可以防止在构建了虚拟包之后，由于应用程序对未准备好的文件的访问造成的文件被重写。采用该安排，就可以防止虚拟包信息与在本地存储器中的文件实体不一致的情况。
第二实施例第二实施例涉及对在执行标题调用时的改进。标题调用要暂时暂停当前标题的重放，重放所调用的标题，以及在对所调用标题的执行完成之后，继续对原始播放的标题的重放。
由于将继续原始播放的标题的重放作为前提，因此当执行标题调用时，重放控制引擎32将存储在PSR中并用于重放控制的系统参数保存在备份PSR中，在所调用的标题被重放之后，重放控制引擎32将在保存在备份PSR中的参数恢复到PSR中。
以下是存储在PSR中的系统参数列表。PSR(0)到PSR(12)中存储指示重放状态的系统参数。PSR(13)到PSR(19)中存储由播放器设定的作为优选的系统参数。PSR(20)到PSR(32)是用于备份的PSR。
PSR(0)IG流号PSR(1)音频流号PSR(2)PG流/文本字幕流号
PSR(3)角度号PSR(4)当前正在重放的标题号PSR(5)当前正在重放的章节号PSR(6)当前正在重放的播放列表标识符PSR(7)当前正在重放的播放项目标识符PSR(8)重放时间信息PSR(9)导航计时器PSR(10)选择键信息PSR(11)IG流中的当前页标识符PSR(12)PG流中的用户样式标识符和文本字幕流PSR(13)父母级别(paretal level)PSR(14)字幕支持信息PSR(15)播放器设定值(音频)PSR(16)音频流的语言代码PSR(17)PG流和文本字幕流的语言代码PSR(18)菜单的语言代码PSR(19)播放器的版本信息PSR(20)PSR(0)的备份PSR(21)PSR(1)的备份PSR(22)PSR(2)的备份PSR(23)PSR(3)的备份PSR(24)PSR(4)的备份PSR(25)PSR(5)的备份PSR(26)PSR(6)的备份PSR(27)PSR(7)的备份PSR(28)PSR(8)的备份PSR(29)PSR(9)的备份PSR(30)PSR(10)的备份PSR(31)PSR(11)的备份PSR(32)PSR(12)的备份在此，如果在执行标题调用之后对虚拟包信息进行更新，则在标题调用之前与之后，在虚拟包信息中将会有些不同。
当要继续调用其他标题(即，被调用标题)的标题(即，调用标题)时，虚拟包信息已经改变；因此，就存在以下可能性当试图采用备份值来重放调用标题时，可能出现错误，因为备份值保持与以前相同。因此，当Java应用程序请求应该更新虚拟包信息时，将可以通过清除备份PSR来避免这种问题情况。然而，可能存在根据在虚拟包信息中的合并管理信息文件，所述改变不会造成任何影响的一些情况；因此，可接受的是，将在系统参数中的值是否应该被清除的问题留给Java应用程序。
图34是流程图，示出当暂时暂停当前标题的重放以便执行标题调用时由重放控制引擎所执行的处理过程，和当原始播放标题的重放继续时由重放控制引擎所执行的处理过程。
为了暂时暂停当前标题的重放，在步骤S71中将SPRM(0)到SPRM(12)保存到SPRM(20)到SPRM(32)中。
当在完成被调用标题的重放之后继续原始播放标题的重放时，在步骤S81中判断在暂停过程中虚拟包信息是否已经被更新。
在虚拟包信息没有被更新的情况下，将SPRM(20)到 SPRM(32)恢复到SPRM(0)到SPRM(12)(步骤S83)。在虚拟包信息已经被更新的情况下，将SPRM(20)到SPRM(32)初始化(步骤S82)，并且将执行步骤S83中的处理。
如迄今所述，根据本实施例，在执行了标题调用之后虚拟包信息被更新的情况下，将备份PSR的内容初始化；因此就不存在重放控制引擎根据标题调用之前的PSR而执行错误的重放处理的可能性。因此，就可以实现重放控制引擎的稳定工作。
应该注意的是，采用以下安排也是可接受的其中，当虚拟包信息被更新时，在系统端强制将系统参数的值清除，而不是将在是否应该清除备份PSR中的值的问题留给Java应用程序。
第三实施例在第一实施例中，已经描述以下配置其中，将在本地存储器中并相应于组织ID和BD-ROM的光盘ID的目录用作用于存储构建虚拟包的文件的位置。在第三实施例中，描述了以下配置其中，采用记录在本地存储器中的任意目录中的文件来构建虚拟包。
通过Java应用程序指定光盘ID和在本地存储器中的目录路径实现这种虚拟包构建，在本地存储器中，将用于虚拟包构建的文件记录为用于更新请求方法的自变量。
在根据第三实施例的重放装置中，虚拟文件系统单元38保持虚拟包管理表。图35示出了虚拟包管理表的示例。虚拟包管理表示出了光盘ID，其与指示在更新请求方法中所指定的本地存储器中的目录的路径相对应，来标识BD-ROM。当响应于更新请求而生成虚拟包信息时，虚拟文件系统单元38能够根据在虚拟包管理表中记载的信息，指定在虚拟包中使用的文件的存储目的地。
以下描述由根据本实施例的虚拟文件系统单元38所执行的虚拟包构建处理。图36是示出由根据第三实施例的虚拟文件系统单元38所执行的虚拟包构建处理过程的流程图。
该流程图示出了在Java应用程序已经发布更新请求方法的情况下，由虚拟文件系统单元38所执行的处理过程。
在步骤S91，判断指定为更新处理方法的自变量的光盘ID是否已经在虚拟包管理表中记载。
在所指定的光盘ID已经在虚拟包管理表中记载的情况下(步骤S91是)，在执行步骤S92到S94中的处理过程之后，执行在步骤95到S99中的处理过程。另一方面，在所指定的光盘ID没有在虚拟包管理表中记载的情况下，过程进而执行步骤S95到S99的处理过程。
在步骤S92到S94，从虚拟包管理表中删除具有所指定光盘ID的条目(entry)(步骤S92)，并判断由所指定光盘ID所标识的BD-ROM是否插入了BD-ROM驱动器1中(步骤S93)。在由所指定光盘ID所标识的BD-ROM已经插入的情况下(步骤S93是)，过程进入步骤S94。在其他情况下(步骤S93否)，过程进入步骤S95。在步骤S94，与所指定光盘ID相对应的虚拟包的构建被暂停。
步骤S95是用于判断所指定目录的签名是否可靠的处理过程。在当前示例中，用于判断所指定目录的签名是否可靠的处理是(a)检查在所指定目录下的合并管理信息文件是否未被窜改，以及然后(b)检查由合并管理信息文件所指定的文件是否未被窜改。
为了确定合并管理信息文件没有被窜改，执行以下过程(a-1)对虚拟包管理表计算散列值。
(a-2)使用由重放装置持有的合并证书中的公钥来对在所指定目录下的签名信息文件中的加密散列值进行解密。
(a-3)将所计算的散列值与解密的签名值进行比较，如果所述值相同，则确定合并管理信息文件没有被窜改。
为了确定由合并管理信息文件所指定的文件没有被窜改，执行以下过程(b-1)对由合并管理文件所指定的每个文件计算散列值。
(b-2)将所计算的散列值与写入到合并管理信息文件中的散列值进行比较，如果所述值相同，则确定由合并管理信息文件所指定的文件没有被窜改。
作为步骤S95的判断结果，在所指定目录的签名是可靠的情况下(步骤S95是)，过程进入步骤S96。在其他情况下，过程终止。
在步骤S96中，使用被指定为更新请求方法的自变量的光盘ID和目录路径，将新的条目添加到虚拟包管理表中。在步骤S97，判断由所指定光盘ID所标识的BD-ROM是否插入了BD-ROM驱动器1。在由所指定光盘ID所标识的BD-ROM已经插入的情况下(步骤S97是)，过程进入步骤S98。在其他情况下(步骤S97否)，处理终止。在步骤S98中，将其路径作为自变量而被指定的本地存储器中的目录下的内容读出，并且将属性设定为只读属性。在步骤S99中，采用其文件路径被指定的本地存储器和BD-ROM中的目录来构建虚拟包。因此完成根据第三实施例的用于构建虚拟包的处理过程的描述。
应该注意的是，上述处理过程是用于响应于更新请求而构建虚拟包的过程；然而，对于在BD-ROM新插入重放装置的情况下构建虚拟包的处理过程而言，从虚拟包管理表中搜索与所插入的BD-ROM的光盘ID相对应的目录路径，并且采用所检测到的目录路径作为指定目录路径来执行在图36的步骤95中和该步骤之后的处理过程，从而能够构建虚拟包。
此外，在响应于更新请求而构建虚拟包的处理过程中，作为在步骤S95中用于判断所指定目录的签名是否可靠的处理，首先(a)检查在所指定目录下的合并管理信息文件是否未被窜改，以及然后(b)检查由合并管理信息文件所指定的文件是否未被窜改；然而，对于在BD-ROM新插入重放装置的情况下构建虚拟包的处理过程而言，还可接受的是仅仅通过以下处理来在步骤S95中判断所指定目录的签名是否可靠(a)检查在所指定目录下的合并管理信息文件是否未被窜改，以便通过在步骤S96到S99中的处理构建虚拟包。在这种情况下，当Java应用程序作出对其文件路径已经写入到合并管理信息文件中的文件的访问请求时，执行如下处理(b)检查由合并管理信息文件所指定的文件是否未被窜改。仅仅在所述文件确认没有被窜改的情况下，才允许Java应用程序访问所指定文件。采用以下安排，减少了在插入并加载BD-ROM之后所必需的处理数量其中，在访问文件时而不是在构建虚拟包时执行散列值计算处理部分。因此，可以实现使启动更加快速的效应。
以下描述正在构建虚拟包时，Java应用程序为本地存储器指定定位器，并访问文件以将数据写入该文件的情况下要执行的操作。
图37是示出用于控制对文件的写入访问的API的处理过程的流程图。当Java应用程序采用指定本地存储器定位器请求写入访问时，判断目录属性是否因为正在构建虚拟包而被设定为只读属性(步骤S101)。在包含所指定文件的目录的属性被锁定在只读属性时(步骤S101是)，将指示不允许写入该文件的异常返回到Java应用程序，并终止处理(步骤S102)。在其他情况下(步骤S101否)，过程进入步骤S103。
在步骤S103，执行对本地存储器中的文件进行写入访问的处理。
根据上述处理过程，如果指定为访问目标的文件是构建虚拟包的文件，并且当作出访问请求时该虚拟包正在构建，则不允许访问该文件。
在此，即使是在当正在采用在contsID#1目录的指定构建虚拟包时，图38所示的contsID#1目录下的文件有错误时，由于在正在构建虚拟包时contsID#1目录的属性被设定为只读属性，因此不可能校正该文件的错误。
在这种情况下，具有文件校正功能的Java应用程序采用提供文件I/O功能的API生成称为contsID#2的目录，如图38所示，并且将在contsID#1目录下的文件复制到contsID#2目录中，从而校正文件中的错误。此时，如果用于AV数据的M2TS文件的内容中没有改变，则可接受的是在contsID#1目录下生成对M2TS文件的符号链接，而不是在contsID#2目录下生成复制文件。
在contsID#2下生成文件之后，Java应用程序使用contsID#2目录的路径(在图38中所示的示例中为“ROOT/organization#1/disc#1/contsID#2”)作为自变量发布更新请求方法。
因此，根据图36中所示的流程图，将采用在contsID#1目录下的文件的虚拟包的构建暂停，然后采用在contsID#2目录下的文件构建虚拟包。当已经构建了新的虚拟包时，将在本地存储器中的contsID#2的属性和其下内容的属性设定为只读属性。
应该注意的是，尽管在本实施例中使用符号链接，采用非直接引用的机制也是可以接受的，在该机制中，“ROOT/organization#1/disc#1/contsID#2/00002.M2TS”文件的内容为诸如“../contsID#2/00002.M2TS”之类的字符串。
如迄今所述，根据本实施例，可以采用在本地存储器中的任意目录的指定来构建虚拟包。此外，在通过将记录在多个记录介质上的文件进行合并来构建虚拟包的情况下，采用以下安排可以防止在虚拟包构建过程中将文件重写其中，将在作为可读/可写记录介质的本地存储器中所存储的文件的属性锁定为只读属性。因此，可以防止由该应用程序本身或者其他应用程序所造成的、在文件中的非法改变可能导致的错误。
此外，即使是在虚拟包没有创建时实体文件被窜改，也可以通过判断签名是否可靠来检测实体文件的窜改，并且避免虚拟包的构建。因此，可以在由于采用非法文件而可能导致的故障发生之前，将其阻止。
应该注意的是，本实施例包括在步骤S95中的处理，在该步骤中，作为当构建虚拟包时要使用的标准判断，判断所指定目录的签名是否是可靠的；然而，也可接受的是，不对签名的可靠性进行判断而构建虚拟包。
应该注意的是，在本实施例中，在构建虚拟包之后，将在本地存储器中的所指定目录的属性和其下内容的属性设定为只读属性；然而，采用以下安排也是可接受的其中，位于所指定目录下的目录和文件的属性也可以递归的设定为只读属性。
应该注意的是，在本实施例中，当虚拟包被构建时，将在本地存储器中的路径，例如“ROOT/organization#1/disc#1/contsID#1”，指定为更新请求方法的自变量；然而，采用以下安排也是可接受的其中仅仅指定contsID，以便从BD-ROM中获得组织ID和光盘ID。
第四实施例在第三实施例中，描述了以下配置其中，通过将被指定为更新请求方法的自变量的目录的属性设定为只读属性来防止构建虚拟包的、本地存储器中记录的文件的改变，以便避免虚拟包信息与在本地存储器中的实际目录-文件结果之间不一致的情况。
在第四实施例中，讨论了一种改进，采用所述改进，可以避免虚拟包信息与在本地存储器中的实际目录-文件结果之间不一致的同时，对在构成虚拟包的本地存储器中的文件进行写入访问。
图39是示出根据第四实施例用于构建虚拟包的处理过程的流程图。在该流程图与图36的流程图之间的差异在于，分别将步骤S98和S99改变为步骤S111和S112。在步骤S111中，将在本地存储器中并被指定为更新请求方法的自变量的目录和其下内容复制到另一记录介质中。在步骤S112中，使用已经复制到所述另一记录介质与BD-ROM中的目录和其下内容来构建虚拟包。因此完成对构建虚拟包的处理过程的描述。
以下描述Java应用程序进行的写入文件访问的处理过程。图40是流程图，示出了在虚拟包已经被构建之后对本地存储器中的文件进行写入访问的情况下，提供文件I/O功能的API的处理。该流程图与图37所示的流程图之间的差异在于，删除了步骤S101和S102。当采用对本地存储器定位器的指定来请求对在本地存储器中的文件进行写入访问时，在步骤S103对本地存储器中的文件进行写入访问，然后处理完成。
因此完成对应用程序进行的对文件的写入访问的处理过程的描述。
如迄今所述，根据本实施例，当通过对记录在多个记录介质上的文件进行合并来构建虚拟包时，将在作为可读/可写记录介质的本地存储器中的文件复制到另一记录介质中，即使是当构建虚拟包时在本地存储器中的文件被重写，虚拟包也可以查询已经被复制到该记录介质上并反映在重写之前的状态的文件。因此，即使是该应用程序本身或者其他应用程序执行了非法的文件改变，也可以防止可能发生的故障。
应该注意的是，在本实施例中，在本地存储器中的文件复制目的地是另一存储介质；然而，以下安排也是可以接受的其中，将文件复制到在本地存储器中的不能从Java应用程序直接引用的目录中，或者仅仅能够进行只读访问的目录中。
应该注意的是，在本实施例中，将在本地存储器中的指定目录和其下内容复制到另一记录介质上；然而，存储有AV流等等的文件的大小是很大的，复制需要时间，并且占用所述记录介质的存储空间。为了解决该情况，还可以接受的是，如图38的示例所示，对这种具有很大大小的文件使用符号链接。
第五实施例第五实施例描述了一种改进，其用于在将要构建虚拟包时防止文件被非法改变。
图41示出了根据第五实施例的重放装置的内部结构。根据本实施例的重放装置具有以下配置其中将加密器41和解密器42添加到图18所示的配置中。与图18中的相同的构成组件具有相同的参考符号，在此将省略对其的描述。
加密器41采用记录在插入到BD-ROM驱动器1中的BD-ROM的BCA(Burst Cutting Area烧录区)中的对于该光盘而言唯一的密钥信息，选择性地对要写入到本地存储器中的文件进行加密。加密器41要加密的文件，是在用于构建虚拟包并已经从服务器下载的文件中的用于AV数据的M2TS文件。在此所使用的加密方法为，例如，诸如AES、DES等等的传统加密方法。BCA是光盘中的导入区内侧的特定区域，所述光盘仅能够由驱动装置读出。由于没有应用程序能够从BCA区域中读出数据，因此BCA区域经常用于版权保护技术。
解密器42采用记录在插入到BD-ROM驱动器1中的BD-ROM的BCA中的对于该光盘而言唯一的密钥信息，对文件进行解密。解密器42所要解密的数据是从本地存储器中读出的M2TS文件。解密器42获得AV数据的访问单位(ACCESS UNIT)并对其进行解密，将被解密数据输出到重放机构。在此所使用的加密方法与加密器41所使用的加密方法相同，并用于对由加密器41加密的文件进行解密。
另外，根据本实施例的重放装置，在虚拟文件系统单元38中所保持的虚拟包管理表的结构与第三实施例中不同。图42示出了第五实施例的虚拟包管理表的示例。本实施例的虚拟包管理表与图35所示不同之处在于，其具有为其添加的签名数据。在虚拟包管理表中的签名数据是用于验证在用于构建虚拟包的目录中，在文件被记录到本地存储器中之后没有被重写。
在签名数据607中的多个注册信息中，分别与具有小文件大小的BDMV文件、MPLS文件和CLPI文件相对应的这些条注册信息601、602和603包括在虚拟包中使用的文件名和记录在本地存储器中的文件实体的散列值。当文件从服务器下载时，已经计算了在此设定的散列值。应该注意的是，散列值是采用用于获得从在文件中存储的数据中唯一确定的值的单向函数来计算。单向函数的一个示例是MD5，其是传统方法。另一方面，在签名数据中的多条注册信息中，用于具有很大文件大小的M2TS文件的注册信息606仅仅包括在虚拟包中使用的文件名，而不包括散列值。签名数据607是采用记录在BD-ROM的BCA中并对于光盘而言唯一的密钥信息进行加密的。
以下参考图43和44描述第五实施例的重放装置的操作的流程。首先，描述将从服务器下载的文件记录到本地存储器中的处理。图43是示出用于将所下载文件记录到本地存储器中的处理过程的流程图。
当Java应用程序从服务器下载要在构建虚拟包时使用的文件并将所下载文件写入到本地存储器中时，执行在本流程图中所示的处理。
当Java应用程序采用本地存储器定位器的指定来请求写入访问时，判断是否由于现在正在构建虚拟包而将目录的属性设定为只读属性(步骤S121)。在包含所指定文件的目录的属性被锁定到只读属性的情况下(步骤S121是)，将指示不允许写入该文件的异常返回给Java应用程序，并终止处理(步骤S122)。在其他情况下(步骤S121否)，过程进入步骤S123。
在步骤S123，判断所指定的文件是否是用于AV数据的M2TS文件。
在所指定文件是M2TS文件的情况下(步骤S123是)，由加密器41采用记录在插入到BD-ROM驱动器1中的BD-ROM的BCA中的对于该光盘而言唯一的密钥信息对该文件进行加密(步骤S124)。然后，将仅包含要在虚拟包中使用的指定文件的文件名的一个注册信息添加到签名数据中(步骤S125)，并且执行在步骤S127中和该步骤之后的处理。
当所指定文件不是M2TS文件的情况下(步骤S123否)，计算该指定文件的散列值。然后，将包含所计算的散列值和要在虚拟包中使用的指定文件的文件名的一条注册信息添加到签名数据中(步骤S126)，并且执行在步骤S127中和该步骤之后的处理。
在步骤S127，由加密器41采用记录在BD-ROM的BCA中的对于该光盘而言唯一的密钥信息对签名数据进行加密。在步骤S128，对本地存储器进行写入访问，将在步骤S127中加密的签名数据连同所指定文件记录到本地存储器中。因此完成对将从服务器下载的文件记录到本地存储器中的处理的描述。
以下描述要由虚拟文件系统单元38执行的构建虚拟包的处理。图44是示出构建虚拟包的处理过程的流程图。该流程图示出在Java应用程序使用光盘ID和其中存储用于构建虚拟包的数据的目录的路径作为自变量，发布更新请求方法的情况下要执行的处理过程。
在步骤S131中，判断是否已经为由所指定光盘ID所标识的BD-ROM构建了虚拟包。
在已经为由所指定光盘ID所标识的BD-ROM创建了虚拟包的情况下(步骤S131是)，过程进入步骤S132。在其他情况下，过程进入步骤S135。在步骤S132，将所指定光盘ID的条目从虚拟包管理表中删除。在步骤S133中，判断由所指定光盘ID标识的BD-ROM是否已经插入到BD-ROM驱动器1中。在已经插入由所指定光盘ID标识的BD-ROM的情况下(步骤S133是)，过程进入步骤S134。在其他情况下(步骤S93否)，过程进入步骤S135。在步骤S134，将与所指定光盘ID相对应的虚拟包的构建暂停。
在步骤S135，将指定为自变量的目录路径和记录在所指定目录中的签名数据，添加到指定为自变量的光盘ID的条目中。
在步骤S136，判断是否将由所指定光盘ID标识的BD-ROM插入BD-ROM驱动器1中。在由所指定光盘ID标识的BD-ROM已经插入的情况下(步骤S136是)，过程进入步骤S137。在其他情况下，处理终止。
在步骤S137，解密器42采用记录在BD-ROM的BCA中的对于该光盘而言唯一的密钥信息，对虚拟包管理表的签名数据进行解密。
在步骤S138，判断被解密的签名数据是否是可靠的。当以下3个条件都满足时，判定签名数据可靠(a)对具有已经设定的散列值的签名数据的所有文件中的每一个计算散列值，所计算的值等于在签名数据中所包括的散列值；(b)在本地存储器中存在其的签名数据不具有已经设定的散列值的M2TS文件，并且其未被删除；
(c)在本地存储器中的所指定目录中不存在没有在签名数据中记载的文件。
在签名数据判定为是可靠的情况下(步骤S138是)，过程进入步骤S139。在其他情况下，处理终止。在步骤S139，将在本地存储器中的所指定目录的属性和其下内容的属性设定为只读属性。在步骤S140，使用自变量指定的本地存储器中的目录和BD-ROM来构建虚拟包。因此完成对构建虚拟包的处理的描述。
此外，在将光盘新插入重放装置的情况下，从虚拟包管理表中搜索与所插入BD-ROM的光盘ID相对应的目录路径，并使用所检测的目录路径作为指定目录路径执行步骤S136中和该步骤之后的处理，以便构建虚拟包。
应该注意的是，在本实施例中，仅仅对包含在虚拟包中的M2TS文件进行加密/解密；而然，以下安排也是可以接受的对其他文件进行加密/解密，例如CLPI文件、BDMV文件和MPLS文件。此外，虽然对在经过加密之后将所下载的M2TS文件写入到本地存储器中的情况进行了描述；然而，以下安排也是可接受的其中，下载已经采用对该光盘而言唯一的密钥预先加密的M2TS文件。
应该注意的是，所述描述说明M2TS文件的散列值没有添加到签名数据中，以便当要执行重放时忽略计算散列值的处理，这是因为M2TS文件的大小是很大的；然而，在采用具有足够高的处理能力的重放装置的情况下，将M2TS文件的散列值添加到签名中也是可以接受的。另外，以下安排也是可以接受的其中，对其他文件进行加密、解密，例如CLPI文件、BDMV文件和MPLS文件，从而使得这些文件的散列值计算处理也如同M2TS文件一样被忽略。
应该注意的是，在本实施例中，当将文件写入到本地存储器中生成签名数据；然而，也可接受的是，当构建虚拟包时下载签名数据本身，并且指定所下载的签名数据。
在本实施例中，将对于该光盘而言唯一的密钥信息用作加密/解密的密钥；然而，也可接受的是，使用对于该光盘而言唯一的密钥信息和从对于终端装置而言唯一的密钥信息中生成的信息，作为加密/解密的密钥。
如迄今所述，根据本实施例，当通过将记录在多个记录介质上的文件进行合并来构建虚拟包时，采用对于该光盘而言唯一的密钥来对在作为可写/可读记录介质的本地存储器中记录的文件进行加密。可以防止，例如，在本地存储器中的实体文件被另一光盘上的应用程序所重写，或者防止通过将该本地存储器插入到诸如个人计算机的另一装置中进行的窜改。此外，由于采用对于该光盘而言唯一的密钥对签名数据进行加密并将其存储，因此可以检测对本地存储器中的文件的窜改，并可以防止采用这些文件构建虚拟包。因此，可以防止由于已经被非法窜改的文件的使用导致的故障，和防止提供商不期望的非法使用。
第六实施例第六实施例讨论了当正在构建虚拟包时，将文件从本地存储器移动到另一记录区域中的方法。
图45示出了根据第六实施例，由虚拟文件系统单元38所执行的虚拟包构建的示例。在该图的左上方，是在BD-ROM中的目录-文件结构。在该图的左下方是在构建虚拟包之前的本地存储器中的目录-文件结构。
在本实施例中的虚拟文件系统单元38将由更新请求方法的自变量所指定的目录(在图中的示例中为“ROOT/organization#1/disc#1/contsID#1”)下的文件移动到ACTIVE目录下，并从BD-ROM和ACTIVE目录中构建虚拟包。在该图的右下方是在移动所述文件之后在本地存储器中的目录-文件结构。
ACTIVE目录是与由更新请求方法的自变量所指定的光盘ID标识的BD-ROM一起构建虚拟包的目录。应用程序不能直接将数据写入到ACTIVE目录中。
以下描述根据第六实施例的重放装置的操作。首先，描述构建虚拟包的处理过程。
图46是示出根据第六实施例，构建虚拟包的处理过程的流程图。
在该流程图与图36所示流程图之间的差异在于，分别将步骤S98和S99改变为步骤S151和S152。在步骤S151，执行用于将在本地存储器中由自变量指定的目录下的文件移动到ACTIVE目录中的处理。在步骤S152，从ACTIVE目录中和BD-ROM中的内容构建虚拟包。因此完成对构建虚拟包的处理过程的描述。
以下描述在步骤S151中的处理的细节。图47是示出将文件移动到ACTIVE目录中的处理过程的流程图。
在该流程图中，判断在更新请求方法的自变量所指定的本地存储器中的目录下是否存在一个或多个文件(步骤S161)，如果存在一个或多个文件(步骤S161是)，则使用在所指定目录中的所述一个或多个文件作为处理目标，执行步骤S162到S164的处理。
在步骤S162，判断在目标文件的文件名中的第一个字符是否为“_”。在第一个字符为“_”的情况下(步骤S162是)，将具有通过从该目标文件的文件名中提取出第一个字符“_”而获得的文件名的文件，从ACTIVE目录中删除，并且将该目标文件本身也从所指定目录中删除(步骤S163)。在第一个字符不是“_”的情况下(步骤S162否)，将该目标文件从所指定目录移动到ACTIVE目录中(步骤S164)。
对在所指定目录下存在的所有文件执行步骤S162到步骤S164的处理，并且当在所指定目录下不存在文件时(步骤S161否)，终止处理。从而完成对将在本地存储器中的指定目录下的文件移动到ACTIVE目录中的处理的细节描述。
应该注意的是，替代根据目标文件的文件名是否为“_”来从ACTIVE目录中删除文件，也可以接受的是，提供进行删除预定(deletion reservation)的API。进行删除预定的API用于使得Java应用程序能够对在ACTIVE目录中的文件进行删除预定；然而，即使是该API进行了删除预定，也不会立即删除在ACTIVE目录中的文件。虚拟文件系统单元38将文件删除预定的内容存储到存储器中，并且当执行在AV目录中的文件的移动处理时，通过删除由所述删除预定所指定的ACTIVE目录中的文件，来执行步骤S162和S163中的替换处理。
以下描述由Java应用程序进行的写入文件访问的处理过程。
图48是示出控制对文件的写入访问的API的处理过程的流程图。当Java应用程序使用本地存储器定位器的指定来请求写入访问时，判断该写入访问是否是对在ACTIVE目录下的文件之一进行的写入访问(步骤S171)。
当该写入访问是对在ACTIVE目录下的文件之一进行的写入访问时(步骤S171是)，将指示不允许对文件进行写入的异常返回给Java应用程序，然后处理终止(步骤S172)。在其他情况中(步骤S171否)，过程进入步骤S173。
在步骤S173，对本地存储器中的文件进行写入访问。因此完成对文件的写入访问的处理过程的描述。
根据上述处理过程，在作为访问目标的文件是构成虚拟包的文件，并且如果当作出访问请求时正在构建虚拟包的情况下，将不会允许对该文件的访问。
应该注意的是，以下安排也是可以接受的其中，在虚拟包构建处理过程中允许Java应用程序将数据写入到ACTIVE目录中，以便Java应用程序执行将文件移动到ACTIVE目录中的处理。更具体而言，在图47的流程图中，虚拟文件系统单元38将在由Java应用程序指定的目录下的文件移动到ACTIVE目录中；然而，以下安排也是可接受的其中，在虚拟包构建处理过程中允许Java应用程序写入ACTIVE目录，以便将开始把文件移动到ACTIVE目录的处理的事件通知给Java应用程序，并且Java应用程序自己将文件移动到ACTIVE目录。
如迄今所述，根据本实施例，在通过将记录在多个记录介质中的文件进行合并来构建虚拟包的情况下，将在作为可读/可写记录介质的本地存储器中存储的一个或多个文件移动到ACTIVE目录中，应用程序不允许对ACTIVE目录进行写入访问；因此，可以防止当正在构建虚拟包时，采用来自该应用程序本身或者其他应用程序的非法文件来改变文件。
第七实施例第七实施例描述了在来自相同提供商的BD-ROM之间共享本地存储器中的内容的方法。在第七实施例的描述中，与在第六实施例中的相同部分的描述将被省略。
图49示出了根据第七实施例的虚拟包的构建的示例。在该图的左上方是在BD-ROM上的目录-文件结构，在该图的左下方是通过将构建虚拟包的文件移动到ACTIVE目录中以便构建虚拟包，而获得的在本地存储器中的目录-文件结构。
图49与图48的不同之处在于，ACTIVE目录不仅存在于ROOT/organization#1/disc#1下，还存在于ROOT/organization#1/SHARED下。
SHARED目录是能够由任何被验证的并且具有公共组织ID的应用程序从中读出数据和将数据写入的目录。
在需要将从服务器下载的文件作为公共使用的文件，来用于为具有不同光盘ID的多个BD-ROM构建虚拟包的情况下，将所下载文件保存在ROOT/organization#1/SHARED目录下而不是ROOT/organization#1/disc#1目录下。在SHARED目录下的目录结构与disc ID目录下的目录结构相同。对ACTIVE目录的操作也与第六实施例中所述相同。然而，应该注意的是，当要构建虚拟包时，不仅仅将在disc#1目录下的ACTIVE目录中的文件，而且将在SHARED目录下的ACTIVE目录下的文件合并来构建虚拟包。
本实施例的虚拟文件系统单元38将同时存在于本地存储器的SHARED目录下和本地存储器的disc ID目录下的一个或多个文件，作为在虚拟包中使用的文件记载到虚拟包信息中。另外，在具有相同名称的文件存在于以下的任意组合的情况下(i)BD-ROM上，(ii)本地存储器的SHARED目录下，以及(iii)本地存储器的disc ID目录下，(例如，0002.CLPI同时存在于BD-ROM上和本地存储器的disc#1目录下)，虚拟文件系统单元38使用本地存储器中的文件作为用于虚拟包构建的文件。在具有相同名称的文件存在于以下全部中的情况下(i)BD-ROM上，(ii)本地存储器的SHARED目录下，以及(iii)本地存储器的disc ID目录下，虚拟文件系统单元38使用在discID目录下的文件进行虚拟包构建。递归地对每个子目录重复进行这种合并处理。
图50示意性地示出了如何使用在SHARED目录下的ACTIVE目录和在disc#1目录下的ACTIVE目录来构建虚拟包。当虚拟包被构建时，将在SHARED目录下的ACTIVE目录中的文件与在BD-ROM上的文件进行合并，从而生成中间文件结构。该合并操作与在第四实施例中所述相同。随后，将该中间文件结构与在disc#1目录下的ACTIVE目录中的文件进行合并。从而通过将BD-ROM、在SHARED目录下的ACTIVE目录中的文件、以及在disc#1目录下的ACTIVE目录中的文件进行合并来构建虚拟包。该中间文件结构与在disc#1目录下的ACTIVE目录中的文件进行合并，是通过在将该中间文件结构看作BD-ROM的同时执行第四实施例中的合并操作来实现的。换而言之，在具有相同名称的文件同时存在于中间文件结构和discID下的ACTIVE 录中的情况下，disc#1目录下的ACTIVE目录具有最终优先级别。因此，优先级别按以下顺序升高BD-ROM、在SHARED目录下的ACTIVE目录、以及在disc#1目录下的ACTIVE目录。
可替换地，也可接受的是，将SHARED目录下的ACTIVE目录的优先级别降低，来构建虚拟包；即，优先级别按以下顺序升高在SHARED目录下的ACTIVE目录、BD-ROM、以及在disc#1目录下的ACTIVE目录。这意味着在具有相同的名称的文件同时存在于BD-ROM上和在本地存储器的SHARED目录下的情况下，使用在BD-ROM上的文件。参考图49进行解释，尽管00002.JAR和00002.CLPI同时存在于BD-ROM上和本地存储器中，对于00002.JAR，由于其在本地存储器中的SHARED目录下的ACTIVE目录中，因此使用在BD-ROM上的00002.JAR；对于00002.CLPI，因为其在本地存储器中的disc#1目录下的ACTIVE目录中，因此使用在本地存储器中的00002.CLPI。在对SHARED目录下的ACTIVE目录的访问限制微弱，并且存在第三方企图通过将恶意文件放置在SHARED目录下来非法地替换在BD-ROM上的文件的情况下，采用这种方式设定优先级别是有效的。
通过将在SHARED目录下的ACTIVE目录的优先级别降低到BD-ROM之下，可以禁止BD-ROM上的文件被替换，从而仅仅允许添加新文件。因此，可以增强安全级别。
应该注意的是，也可以接受的是，在BD-ROM上或者在SHARED目录下的ACTIVE目录中，提供定义有关在SHARED目录下的ACTIVE目录的优先级别是高于还是低于BD-ROM的优先级别的优先级别信息的文件。
上述虚拟包的构建是通过发布更新请求方法来实现的，更新请求方法指定以下作为自变量(i)其中记录有要在多个BD-ROM的虚拟包之间进行共享的文件的目录路径(在图49的示例中为“ROOT/organization#1/SHARED/contsID#3”)，(ii)其中记录有对于由光盘ID所标识的BD-ROM的虚拟包而言唯一的文件的目录路径(在图49中的示例中为“ROOT/organization#1/disc#1/contsID#1”)，以及(iii)光盘ID。
以下描述根据本发明的第七实施例的重放装置的操作。首先，解释构建虚拟包的处理过程。
图51是示出根据第七实施例的构建虚拟包的处理过程的流程图。图51的流程图与图36的流程图之间的差异在于，将步骤S98和S99改变为步骤S181到S184。
在步骤S181，执行以下处理，将在由自变量指定的、作为要在多个BD-ROM之间进行共享的文件的文件记录目的地的本地存储器中的目录下所存储的文件，移动到在SHARED目录下的ACTIVE目录中。采用与图47所示的过程相同的方式执行移动文件的处理。在步骤S182，使用在SHARED目录下的ACTIVE目录中和BD-ROM中的内容构建中间文件结构。在步骤S183，执行以下处理，将由自变量指定的、作为唯一性文件的文件记录目的地的目录下所存储的文件，移动到在discID目录下的ACTIVE目录中。采用与图47所示的过程相同的方式执行移动文件的处理。在步骤S184，将在discID目录下的ACTIVE目录中所存储的内容与在步骤S182中构建的中间文件结构进行合并，从而构建虚拟包。因此完成对虚拟包创建的处理过程的描述。
应该注意的是，以下的顺序可以颠倒(i)在步骤S182中的使用在SHARED目录下的ACTIVE目录和BD-ROM构建中间文件结构的步骤，以及(ii)在步骤S183中的将文件移动到discID目录下的ACTIVE目录中的步骤。
接下来，以下参考图52详细描述图51所示的步骤S182中的处理。当将在SHARED目录下的ACTIVE目录中的文件与在BD-ROM上的文件进行合并时，则首先在步骤S191，将或者存储在BD-ROM上或者存储在discID目录中，并且在其中写入优先级别信息的文件读出，以便检查SHARED目录和BD-ROM的优先级别。在SHARED目录的优先级别较高的情况下(步骤S191是)，过程进入步骤S192，获得示出在SHARED目录下的ACTIVE目录中的文件的文件列表。随后，对在BD-ROM上记录的所有文件中的每一个重复执行步骤S193到S195的循环处理。
在步骤S194，将记录在BD-ROM上的、还没有被处理的文件中的一些的文件名作为处理目标进行检查，判断在步骤S192中获得的文件列表是否包含与每个处理目标具有相同文件名的文件(步骤S193)。在文件列表不包含与处理目标具有相同文件名的文件的情况下(步骤S193否)，将该处理目标文件的文件名添加到文件列表(步骤S195)。对在BD-ROM上记录的所有文件中的每一个都进行在步骤S194和S195中的处理，并且当检查完所有文件时(步骤S193是)，将所获得的文件列表作为中间文件结构，完成处理。
另一方面，在步骤S191中BD-ROM的优先级别比SHARED目录高的情况下，过程进入步骤S196，获得记录在BD-ROM上的文件的列表。随后，对在SHARED目录下的ACTIVE目录中的所有文件的每一个都重复执行在步骤S197到S199中的循环处理。
在步骤S198中，在SHARED目录下的ACTIVE目录中的文件中，将还没有被处理的文件中的一些的文件名作为处理目标进行检查，判断在步骤S196中获得的文件列表是否包含与每个处理目标具有相同文件名的文件。在文件列表不包含与处理目标具有相同文件名的文件的情况下(步骤S198否)，将该处理目标文件的文件名添加到文件列表(步骤S199)。对在SHARED目录下的ACTIVE目录中所记录的所有文件中的每一个都进行在步骤S198和S195中的处理，并且当检查完所有文件时(步骤S197是)，将所获得的文件列表作为中间文件结构，完成处理。因此完成用于构建中间文件结构的过程。
应该注意的是，也可接受的是，预先确定缺省优先顺序，从而如果不存在指示优先级别信息的文件时，使用该缺省优先顺序。
图53是更详细地示出图51的步骤S184中执行的处理的流程图。首先，在步骤S201，获得在discID目录下的ACTIVE目录中的文件的文件名列表。在步骤S203，检查在图51中的步骤S182中获得的中间文件结构的文件列表中所包含的文件名。在没有具有相同文件名的文件的情况下，将中间文件结构中的文件的文件名添加到步骤S204中的列表中。对在中间文件结构中的所有文件中的每一个进行步骤S203和S204的处理，当在步骤S202判定检查完所有文件时，将所获得的文件列表作为虚拟包的文件结构列表，然后处理结束。因此完成对采用中间文件结构构建虚拟包的处理过程的描述。
如迄今所述，根据本实施例，在通过将记录在多个记录介质上的文件进行合并来构建虚拟包的情况下，将记录在作为可读/可写记录介质的HDD上的文件移动到ACTIVE目录中；因此，就不会存在以下可能性在正在构建虚拟包时，由于该应用程序本身或者其他应用程序进行的非法文件访问，导致在本地存储器中所存储的实体文件被改变。此外，通过在属于同一提供商的Java应用程序能够公共访问的位置处提供ACTIVE目录，就可以使得不同BD-ROM能够共享在本地存储器中所存储的内容。因此，本地存储器不需要存储具有很大文件大小的、相同实体的多个AV流等等。因此，就可以在BD-ROM之间有效地共享和利用数据。
第八实施例第八实施例描述了在本地存储器中所存储的用于构建虚拟包的文件被窜改的情况，用于检测窜改的一种方法。在第八实施例中，与第三实施例相同部分的描述被省略。将仅仅描述与第三实施例不同的部分。
当要用于构建虚拟包的本地存储器中的文件被窜改时，存在当重放虚拟包时执行提供商不期望的操作的可能性。因此，必须检测窜改。
为了检测窜改，根据本实施例的重放装置在将要构建虚拟包时，检查合并管理信息文件是否被窜改，并且当读出文件时，检查在HDD上的文件是否被窜改。
在构建虚拟包之后，在虚拟包的重放过程中，虚拟文件系统单元38有时可能提供存储在本地存储器中的一些文件用于DVD-like模块29a、Java平台29b、重放控制引擎32等等。因为这些文件存储在本地存储器中，因此在所述文件被所述模块使用之前，必须检查其是否未被窜改。可以将构建虚拟包的本地存储器中的文件按照窜改检查的必要性分为两种类型。
第一种类型是每个都具有小的文件大小的数据文件，其通常在响应重放装置时不会造成任何问题，即使是对整个文件检查窜改也是如此。例如，通常将“合并管理信息文件”分类到这种类型。
第二种类型是每个都具有很大文件大小的数据文件，其在响应重放装置时可能造成问题，这是因为对整个文件进行检查需要很长时间。例如，通常将MPEG流中的“AV数据(M2TS文件)”分类到这种类型。
以下描述在被分类到第一种类型的文件中的窜改检查。在结尾，将描述与对分类到第二种类型的文件执行检查的情况之间的差异。
图54是示出虚拟文件系统单元38将在本地存储器中的文件提供给另一模块的流程图。在步骤S211，检查所请求文件是否存在于本地存储器中。在所请求文件在本地存储器中时(步骤S211是)，在步骤S212中从本地存储器中获得该文件。随后，在步骤S213中，检查目标文件的散列值是否被写入到合并管理信息文件中。在散列值被写入到合并管理信息文件中的情况下(步骤S213是)，在步骤S214计算该文件的散列值，并将所计算的值与在合并管理信息文件中所写入的值进行比较，以判断所述值是否彼此相等。
在所计算的值与在合并管理信息文件中所写入的值不相等的情况下(步骤S214否)，在实际中将不执行该文件的加载。在步骤S211的判断结果是该文件不存在于本地存储器中时(步骤S211否)，在步骤S215从BD-ROM获得该文件。随后，实际在步骤S216中加载该文件，从而使得其他模块能够使用该文件。类似地，在散列值没有写入合并管理信息文件(步骤S213否)和所计算的值等于在合并管理信息文件中所写入的值的情况下(步骤S214)，实际在步骤S216中加载该文件，从而使得其他模块能够使用该文件。
应该注意的是，在虚拟文件系统单元38多次从本地存储中读出文件的情况下，可能在每次读出该文件时都执行窜改检查。还可以接受的是，在执行窜改之后，锁定该文件，从而使得在本地存储器中的信息不会被改变。
此外，以下安排也是可以接受的其中，虚拟文件系统单元38对要被其他模块所使用的一些或者全部文件预先执行窜改检查，并将被检查的文件存储在虚拟文件系统单元38或者锁定被检查文件。只要作出如下安排在从本地存储器中读出文件之后，在其他模块使用该文件之前计算该文件的散列值以检查窜改，就可以接受以任何方式实现该安排。
当检测到要被其他模块所使用的文件已经被窜改时，虚拟文件系统单元38暂停重放，从而使得将不会发生故障。在该情况下，可以接受的是，除了暂停重放之外，还通知用户或者通过Java平台29b通知Java应用程序，或者仅仅使用BD-ROM再次执行重放。可替换地，将这些处理中任意处理进行组合也是可以接受的。
对于每一个都具有很大文件大小，并且在响应重放装置时由于对整个文件进行检查需要很长时间的文件而言，使用一种方法来加密整个文件，从而使得在该文件被窜改之后不能被解密。在该情况下，以下安排也是可接受的其中，即使是将被加密文件的散列值写入到合并管理信息文件中，虚拟文件系统单元38也将其忽略，这是因为在被加密文件的一部分被窜改时，不可能将该文件解密为可靠文件。
可替换地，还可接受的是，仅仅对该文件的一部分检查窜改，或者仅仅检查该文件的大小。在对整个文件进行加密的情况下，存在整个文件可能被另一文件所替换的可能性。在这种情况下，通过检查该文件的大小，可以容易地执行窜改检查。还可以接受的是设定一种情况，在该情况下，虚拟文件系统单元38忽略所写入的散列值。例如，在该文件的大小大于特定值的情况下，或者在合并管理信息文件中所包含的文件名中的扩展名是特定值，例如.M2TS，的情况下，或者在合并管理信息文件中所包含的文件名是在特定目录下，例如STREAM目录，的情况下，忽略所写的散列值。
如迄今所述，根据本实施例，当通过对记录在多个记录介质上的文件进行合并来构建虚拟包时，如果在作为可读/可写记录介质的本地存储器中的实体文件已经被窜改，则可以判断散列值是否正确并检测实体文件的窜改，以便暂停重放。因此，可以在可能由于使用非法文件造成的故障发生之前，将其避免。
第九实施例第九实施例描述了用于在屏幕上显示虚拟包构建处理的状态的一种方法。在第九实施例的描述中，与第三实施例相同部分的描述被省略。将仅仅描述与第三实施例不同的部分。
图55示意性地示出了根据第九实施例，在虚拟包构建处理过程中的显示。
重放装置610示意性地表示重放装置的外部面貌。内置在重放装置610中的BD-ROM驱动器611加载和退出BD-ROM以及访问BD-ROM。在重放装置610的前面提供了荧光管显示设备612，其用于示出正在执行虚拟包构建处理，并且用作彩色显示单元，并且其通过显示颜色(例如，用橙色显示)来指示正在执行虚拟包构建处理。在重放装置610的前面提供了荧光管显示设备613，其用于通过改变所显示区域的比例来示出在与虚拟包构建相关的处理中，例如在验证处理中，的进度，并且其通过改变由来自荧光管的光所显示的区域的比例来指示虚拟包构建处理的进度。通过有线等等将诸如TV之类的显示装置614的输入单元(图中未示出)连接到重放装置610的输出单元(图中未示出)，并在屏幕上显示从重放装置610输出的图像。重放装置610将指示正在执行虚拟包构建的屏幕显示615输出到显示装置614，作为弹出消息面板等等，从而将其覆盖在内容重放显示屏幕上来进行显示。
作为弹出显示的屏幕显示615包括屏幕显示616，其通过改变所显示区域的比例，来显示与虚拟包构建有关的处理，例如验证处理，的进度，所述所显示区域通过改变在显示装置614的屏幕上的条形的比例，来视觉性地指示虚拟包构建处理的进度。
图56示意性地示出根据第九实施例，在虚拟包构建处理中的一个失败的显示。与图55相同的部分的描述将省略。将仅仅描述与图55不同的部分。在重放装置610的前面提供了荧光管显示617，其用于指示在虚拟包构建处理中的失败，并且通过显示颜色(例如，用红色显示)来指示虚拟包构建处理已经失败。在虚拟包构建处理已经失败的情况下，重放装置610将指示虚拟包构建处理失败的屏幕显示618输出到显示装置614，作为弹出消息面板等等，从而将其覆盖在内容重放显示屏幕上来进行显示。
图57示意性地示出了根据第九实施例，在虚拟包构建处理中的成功的显示。与图55相同的部分的描述将省略。将仅仅描述与图55不同的部分。在重放装置610的前面提供了荧光管显示619，其用于指示在虚拟包构建处理中的成功，并且通过显示颜色(例如，用绿色显示)来指示虚拟包构建处理已经成功。在虚拟包构建处理已经成功的情况下，重放装置610将指示虚拟包构建处理成功的屏幕显示620输出到显示装置614，作为弹出消息面板等等，从而将其覆盖在内容重放显示屏幕上来进行显示。
以下描述当正在构建虚拟包时，在屏幕上显示构建处理的状态的过程。图32是示出对与虚拟包构建处理相关的显示进行更新的处理过程的流程图。
该流程图是通过从图44所示的流程图中取出在步骤S131到S135中的处理过程，并加入在步骤S222和S223中的处理过程而获得的。
在步骤S221，将显示转换到图55所示的正在执行虚拟包处理的显示。在步骤S222，将显示转换到图56所示的虚拟包处理已经失败的显示。在步骤S223，将显示切换到图27所示的虚拟包处理已经成功的显示。还可以接受的是，在执行步骤S222中的处理或者在步骤S223中的处理之后，在指示虚拟包构建的状态的屏幕显示的输出完成之前，将该显示在屏幕上示出一段预定时间，并且执行正常的内容重放。
图59示出了根据第九实施例，在本地存储器中所存储的内容的列表的显示。与图55相同的部分的描述将省略。将仅仅描述与图55不同的部分。在本地存储器中所存储的内容列表的屏幕显示621，是用于在显示装置614上显示在虚拟包管理表中所管理的本地存储器中的内容列表的图像。示出了在该内容列表的虚拟包构建处理中已经失败的内容的屏幕显示622是用于通过在屏幕显示621中的图标，来向用户指示在签名验证中内容已经失败，所述屏幕显示621用于本地存储器中的内容列表的屏幕显示。屏幕显示623示出了在该内容列表的虚拟包构建处理中已经成功的内容，所述屏幕显示623是用于通过在屏幕显示621中的图标，来向用户指示在签名验证中内容已经成功，所述屏幕显示621用于本地存储器中的内容列表的屏幕显示。
应该注意的是，在本实施例中，将在虚拟包构建处理中已经失败的内容通知给用户；然而，以下安排也是可以接受的其中，系统自动删除这种内容。
其他修改示例迄今已经根据上述实施例示例描述了本发明。然而，不言而喻，本发明并不局限于上述实施例示例。本发明包括如下所述的其他示例。
(1)本发明可以构建为上述的方法。可替换地，本发明可以构建为计算机程序，所述计算机程序使用从这种计算机程序转换的计算机或者数字信号来实现所述方法。
另外，可接受的是，本发明构建为计算机可读记录介质，例如软盘、硬盘、CD-ROM、MO、DVD、DVD-ROM、DVD-RAM、BD(蓝光光盘)或者半导体存储器，所述计算机可读记录介质上记录有这种计算机程序和这种数字信号；或者本发明构建为所述记录介质上所记录的这种计算机程序或者这种数字信号。
此外，可以通过经由通信网、无线或有线通信线、诸如因特网之类的网络等等传输这种计算机程序或者这种数字信号，来实现本发明。
此外，可接受的是，认为本发明是包括微处理器和存储器的计算机系统，其中，所述存储器中存储上述计算机程序，并且所述微处理器根据所述计算机程序工作。
此外，可接受的是，通过输送记录在所述记录介质上的程序或者数字信号，或者经由上述网络等等进行输送，来基于计算机系统执行所述程序或数字信号。
(2)在第一到第九实施例中，将Java(注册商标)用作虚拟机的编程语言。然而，采用用作UNIXTM的OS的B-shell、Perl脚本、ECMA脚本等等来取代JavaTM编程语言也是可以接受的。换而言之，本发明并不局限于JavaTM。
(3)在第一到第九实施例中，在用于存储文件的本地存储器中的结构具有与BD-ROM上相同的目录结构；然而，只要清晰地表示文件之间的对应关系，本发明就不局限于采用相同的目录结构的情况。
(4)在第一到第九实施例中，将HDD用作可读/可写记录介质；然而，使用闪存等等作为可读/可写记录介质也是可接受的。
(5)在第一到第九实施例中，描述了具有对记录介质进行重放功能的重放装置；然而，不言而喻，本发明可以应用于不仅仅具有重放功能还具有记录功能的重放装置。
(6)在第一到第九实施例中，描述了重放BD-ROM的重放装置；然而，不言而喻，在以上实施例所述的记录在BD-ROM上的必要数据被记录在可写光学记录介质上的情况下，也能够实现相同的效果。
此外，不言而喻，在以上实施例所述的记录在BD-ROM上的必要数据被记录在取代光学记录介质的便携式记录介质(例如，诸如SD卡、或者小型闪存(CF)之类的半导体存储器)上的情况下，也能够实现相同的效果。
(7)可以接受的是，将任意所述实施例和修改示例进行组合。
工业适用性能够应用本发明的示例包括，诸如BD-ROM播放器之类的重放装置，在所述重放装置上安装了HDD，并且所述重放装置通过采用记录在可读/可写记录介质上的内容对记录在只读记录介质上的内容进行扩展，来执行重放。
权利要求
1.一种用于重放相互结合的应用程序和数字流的重放装置，所述重放装置包括读出单元，其用于读出在安放于所述重放装置上的只读记录介质上记录的文件；存储单元，其中存储(i)多个文件，(ii)合并管理信息，其从所述多个文件中指定要与在所述只读记录介质上记录的内容组合使用的文件，以及(iii)签名信息，其用于判断所述合并管理信息的可靠性；判断单元，其用于根据所述签名信息判断所述合并管理信息的可靠性；包管理单元，其用于(a)在所述合并管理信息被判断为可靠的情况下，生成包信息，所述包信息指示通过将所述合并管理信息所指定的文件加入到所述只读记录介质的文件结构中而获得的新文件结构，以及(b)在所述合并管理信息被判断为不可靠的情况下，不生成指所述新文件结构的所述包信息；重放单元，其用于根据由所述包管理单元生成的所述包信息，重放记录在所述只读记录介质上或者存储在所述存储单元中的所述数字流；以及执行单元，其用于根据由所述包管理单元生成的所述包信息，执行记录在所述只读记录介质上或者存储在所述存储单元中的所述应用程序。
2.如权利要求1所述的重放装置，其中一旦将所述只读记录介质安放到所述重放装置上，就执行由所述判断单元进行的判断和由所述包管理单元进行的所述包信息的生成。
3.如权利要求2所述的重放装置，其中所述合并管理信息包括指示所指定文件的散列值的散列信息，并且(a)在由所指定文件计算得到的散列值等于在所述散列信息中指示的所述散列值的情况下，所述重放单元和所述执行单元访问所指定文件，反之(b)在从所指定文件计算得到的所述散列值不等于在所述散列信息中指示的所述散列值的情况下，所述重放单元和所述执行单元不访问所指定文件。
4.如权利要求1所述的重放装置，其中当由所述执行单元执行的所述应用程序请求应该更新所述包信息时，执行由所述判断单元进行的判断。
5.如权利要求4所述的重放装置，其中所述合并管理信息包括指示所指定文件的散列值的散列信息，以及(a)在从所指定文件计算得到的散列值等于在所述散列信息中指示的所述散列值的情况下，所述重放单元和所述执行单元访问所指定文件，反之(b)在从所指定文件计算得到的所述散列值不等于在所述散列信息中指示的所述散列值的情况下，阻止所述重放单元和所述执行单元访问所指定文件。
6.如权利要求1所述的重放装置，其中所述签名信息包括通过使用预定密钥对所述合并管理信息的第一散列值进行加密而获得的加密散列值，所述第一散列值预先使用预定算法被计算，以及所述判断单元采用用于对使用所述预定密钥加密的信息进行解密的公钥来对所述加密散列值进行解密，使用所述预定算法计算所述合并管理信息的第二散列值，并在从所述解密中得到的所述第一散列值等于从所述计算中得到的所述第二散列值的情况下，判定所述合并管理信息是可靠的。
7.如权利要求1所述的重放装置，其中在所述合并管理信息被判定为不可靠的情况下，所述包管理单元还生成指示所述只读记录介质的所述文件结构的包信息。
8.如权利要求1所述的重放装置，其中在生成所述包信息之前，所述包管理单元将由所述合并管理信息指定的所述文件的属性设定为只读属性。
9.如权利要求1所述的重放装置，其中(a)在所述合并管理信息包括指示由所述合并管理信息指定的预定文件的散列值的散列信息的情况下，如果从所述预定文件中计算得到的散列值不等于由所述散列信息指示的所述值，则阻止所述重放单元和所述执行单元访问所述预定文件；以及(b)在所述合并管理信息不包括指示所述预定文件的散列值的所述散列信息的情况下，不阻止所述重放单元和所述执行单元访问所述预定文件。
10.如权利要求1所述的重放装置，还包括彩色显示单元，其用于在所述包管理单元正在生成所述包信息时，采用一种或多种颜色进行显示。
11.如权利要求1所述的重放装置，包括输出单元，其用于将信息输出到显示装置，其中在所述包管理单元正在生成所述包信息时，所述重放装置发出信号，以将所期望的信息输出到所述显示装置的显示屏幕。
12.如权利要求11所述的重放装置，其中所期望的信息指示由所述包管理单元进行的所述包信息生成的进度。
13.一种用于重放相互结合的应用程序和数字流的重放方法，其中只读记录介质上记录有第一组文件；可读/可写记录介质上记录有第二组文件、合并管理信息、以及用于判断所述合并管理信息的可靠性的签名信息，所述合并管理信息从所述第二组文件中指定要与记录在所述只读记录介质上的内容组合使用的文件，并且所述重放方法包括判断步骤，其根据所述签名信息判断所述合并管理信息的可靠性；包生成步骤，其(a)在所述合并管理信息被判断为可靠的情况下，生成包信息，所述包信息指示通过将所述合并管理信息指定的所述文件加入到所述只读记录介质的文件结构中而获得的新文件结构，以及(b)在所述合并管理信息被判断为不可靠的情况下，不生成指示所述新文件结构的所述包信息；重放步骤，其根据所生成的包信息，重放记录在所述只读记录介质上或者记录在所述可读/可写记录介质上的所述数字流；以及执行步骤，其根据所生成的包信息，执行记录在所述只读记录介质上或者记录在所述可读/可写记录介质上的所述应用程序。
全文摘要
在本地存储器(18)中，有多个文件，合并管理信息从所述多个文件中指定要与记录在只读记录记录介质上的内容结合使用的文件，以及签名信息用于判断所述合并管理信息的可靠性。虚拟文件系统单元(38)根据所述签名信息判断所述合并管理信息的可靠性。在所述合并信息被判断为是可靠的情况下，虚拟文件系统单元(38)生成包信息，所述包信息指示通过将所述合并管理信息所指定的文件加入到所述只读记录介质的文件结构中而获得的新文件结构。
文档编号G11B20/00GK1998048SQ20058002456
公开日2007年7月11日 申请日期2005年7月19日 优先权日2004年7月22日
发明者大芦雅弘, 田中敬一, 大户英隆, 杰尔马诺·莱克森林 申请人:松下电器产业株式会社