应用程序执行设备的制作方法

专利名称：应用程序执行设备的制作方法
技术领域：
本发明涉及服从DVB-MHP(数字视频广播多媒体家用平台)的应用程序执行设备。
背景技术：
根据DVB-MHP，广播设备能够定义多个应用程序(applicationprogram)(以下称为“应用程序(application)”)并广播它们。另一方面，应用程序执行设备(“应用程序执行设备”)，例如数字TV或STB，能够执行所接收的多个应用程序。一个应用程序由多个类文件和多个数据文件组成，其被多路复用到传输流(“TS”)中，然后广播。
为了发送应用程序，使用了对象传送带(object carousel)。对象传送带是采用TS进行分发(distribute)的文件系统和，并且其也是一种在DVB-MHP中的装置，用于分发组成应用程序的文件(“应用程序组成文件”)。对象传送带周期性地发送组成一个应用程序的各个目录和文件的分层结构。
具体说来，在发送服务中，广播设备首先向应用程序执行设备仅发送位于紧接着根目录之下的目录和文件。随后，其顺序地发送属于每个目录的目录和文件。应用程序执行设备顺序地缓存这些目录和文件。在此，即使当还没有缓存全部应用程序组成文件时(例如，当位于包括有与主例程(routine)相对应的类文件的一个目录之下的多个目录尚未被缓存时)，如果具有了用于应用程序启动的最少量的必需文件，那么该应用程序就会被执行。例如，如果到主例程的文件路径在高速缓冲存储器中准备就绪，则加载与主例程相对应的类文件。于是，当该实例启动时，应用程序被执行。
应注意专利参考文献1详述了本发明的现有技术。
<专利参考文献1>日本专利特许公报No.2000-358233。
<非专利参考文献1>书面标准(文件名Ts101812.V1.2.1.pdf，文献名数字视频广播(DVB)，多媒体家用平台(MHP)说明书1.0.2)，第39页，可由http://www.mhp.org/as of September 9，2004获得。

发明内容
本发明要解决的问题在只有部分应用程序组成文件被缓存在存储器中时应用程序运行的情况下，可能根据用户的操作或应用程序的操作会发生服务中的一个转换。当服务中的转换包括从一个传送应用程序的TS调谐到另一个TS且在该转换之后的新服务不允许应用程序启动的时候，就会引发问题。
如果这类服务转换发生，就执行一个结束该应用程序的过程。在此，在MHP说明书中，这种结束处理可以写入到应用程序上。因此，当结束一个应用程序时，应用程序执行设备执行该应用程序的结束处理。有时在执行结束处理的情况下，仍然需要将类文件缓存。即，例如，当结束处理被写入到独立的类文件中时。在此情况下，由于用于结束处理的类文件还没有被缓存，因此就在结束处理中引发了错误。
即，在结束处理中，如果在工作中的部分应用程序是主例程，就执行一个挂起过程，其中将程序正在使用的局部变量等等存储在堆栈中，为重新启动操作作准备。然而，如果该类文件尚未被缓存，则挂起过程就不能正常执行。在主例程已经接收到一些从用户而来的设定的情况下，由于挂起过程的故障，主例程的用户设定会丢失。如果用户设定丢失，当在做出服务转换之前的原始服务被再次选择时，用户就不得不再次输入所述设定。另外，终端可以冻结，或者损坏。在此，如果在挂起过程执行之前，主例程检查该类文件是否已被缓存，那么就可以避免这种用户设定的丢失和应用程序的冻结或出乎意料的关闭。然而，这引起了另一个问题，就是增加了主例程的代码，从而导致花费大量时间来加载主例程。
本发明是考虑到上述问题而做出的，目的在于提供一种应用程序执行设备，其实现了应用程序的稳定的结束处理，同时避免了加载周期的延长。
解决问题的方法带着解决所述问题的目的，本发明是一种应用程序执行设备，用于执行只能在所选择的服务中执行的应用程序，包括高速缓存单元；选择接收单元，用于接收来自用户的服务选择；文件接收单元，用于从由广播设备发送的对象传送带中接收应用程序组成文件，并将所述应用程序组成文件写入高速缓存单元，所述应用程序组成文件组成与由用户所选择的服务相关的应用程序；判断单元，用于判断高速缓存单元是否已经缓存了在应用程序组成文件中的、执行挂起过程所需的文件；以及执行控制单元，如果所述判断是肯定的，则促成在高速缓存单元中缓存的应用程序组成文件的执行。
发明的有益效果根据上述结构，在高速缓存单元缓存了在组成与服务相关的应用程序的文件中的执行挂起过程所需的文件之前，不执行应用程序。因此，本发明能够在应用程序的结束处理中正常执行挂起过程。
在此情况下，执行控制单元可以包括获取子单元，用于获取缓存保证属性信息，其指示在应用程序组成文件执行时对在文件读取中无故障的保证是否是必要的。在此，当所获取的缓存保证属性信息指示该保证是必要的时，执行控制单元控制所述执行。
因此，只有在缓存保证属性信息指示在应用程序组成文件执行时对在文件读取中无故障的保证是必要的时候，执行控制单元才控制所述执行。就是说，缓存保证属性信息允许选择适合于应用程序特性的操作。
在此情况下，执行控制单元可以包括获取子单元，用于获取优先级属性信息，其表示在存在多个应用程序的情况下，要将资源优先分配给哪个应用程序。在此，当获取的优先级属性信息指示一个预定阈值的数值或更高数值时，执行控制单元控制所述执行。
因此，只有在优先级属性信息表示一个预定阈值的数值或更高数值时，执行控制单元才控制所述执行。就是说，优先级属性信息允许选择适合于应用程序特性的操作。
在此情况下，执行控制单元可以包括获取子单元，用于获取服务绑定属性信息，其指示应用程序是否只能在用户所选择的服务中执行，并当所获取的服务绑定属性信息指示所述应用程序只能在用户所选择的服务中执行的时候，控制所述执行。
因此，只有在服务绑定属性信息指示应用程序只能在该服务中执行的时候，执行控制单元控制所述执行。就是说，服务绑定属性信息允许选择适合于应用程序特性的操作。
在此情况下，可以根据与所有应用程序组成文件相关的信息，来做出判断。
因此，可以判断执行挂起过程所需的文件是否已经被缓存。
在此情况下，执行控制单元可以包括提取子单元，用于从所述信息中提取目录属性，所述目录属性被指定给多个目录中的每一个，且指示一个已经对其指定了目录属性的目录是否包含一个或多个应用程序组成文件。在此，所获取的文件属于一个目录，该目录的被提取的目录属性指示该目录包括一个或多个应用程序组成文件。
因此，根据目录属性，如果执行挂起过程所需的、在一个其中包含有组成该应用程序的文件的目录中所存储的文件被缓存，则执行控制单元就执行该应用程序。因此，例如，即使当存在多个应用程序时，也只需缓存在由目录属性所指示的目录中存储的、执行挂起过程所需的文件，这实现了应用程序更快的启动。
本发明还可以是一种应用程序执行设备，用于执行只能在所选择的服务中执行的应用程序，包括高速缓存单元；选择接收单元，用于接收来自用户的服务选择；文件接收单元，用于从由广播设备发送的对象传送带中接收组成与由用户所选择的服务相关的应用程序的应用程序组成文件，并将所述应用程序组成文件写入所述高速缓存单元；以及接口单元，用于检查高速缓存单元是否已经缓存了在应用程序组成文件中的、执行挂起过程所需的文件。在此，当主例程启动时，应用程序通过接口单元检查高速缓存单元是否已经缓存了所需的文件，如果检查结果为否定的，就暂停应用程序组成文件的执行，直至所需的文件被缓存为止，当所需的文件被缓存时，继续所述执行。
因此，应用程序能够通过接口单元判断高速缓存单元是否已经缓存了执行挂起过程所需的文件。通过暂停所述执行直至所需的文件被缓存为止，可以保证在结束处理中的挂起过程的正常执行。
本发明还可以是一种应用程序执行设备，用于执行只能在预定服务中执行的应用程序，包括高速缓存单元；写入单元，用于从记录介质中读取应用程序组成文件，并将所述应用程序组成文件写入高速缓存单元，所述应用程序组成文件组成与由用户所选择的服务相关的应用程序；判断单元，用于判断高速缓存单元是否已经缓存了在应用程序组成文件中的、执行挂起过程所需的文件；以及执行控制单元，如果所述判断是肯定的，则促成在高速缓存单元中缓存的应用程序组成文件的执行。
因此，即使在从记录介质读取组成应用程序的文件的情况下，在执行挂起过程所需的文件被缓存之前，应用程序也不会被执行。因此，可以在应用程序的结束处理中正常执行挂起过程。


图1是系统图；图2是应用程序执行设备的功能框图；图3示出了与从AIT提取的应用程序相关的信息；图4示出了应用程序执行设备的分层结构；图5是对象传送带的原理图；图6是示出TS和组成TS的TS分组的语法的实例的示意图；图7是示出包括两个广播节目的TS的实例的示意图；图8是示出应用程序执行设备的处理过程的流程图；图9是示出由应用程序管理单元执行的应用程序执行控制过程的流程图；图10示出了由对象传送带分发的文件系统的特定实例；图11是实施例2的应用程序执行设备的功能图；图12示出了一个特定实例，其中，将缓存保证属性CG添加到DVB-MHP标准中；图13是示出实施例2的应用程序执行设备的处理过程的流程图；图14是示出由应用程序管理单元执行的应用程序执行过程的流程图；图15是实施例3的应用程序执行设备的功能框图；图16示出了一个特定实例，其中，将多目录属性CG添加到DVB-MHP标准中；图17是示出实施例3的应用程序执行设备的处理过程的流程图；图18是示出由应用程序管理单元执行的应用程序执行控制过程2的流程图；图19是实施例4的应用程序执行设备的功能框图；图20示出了一个特定实例，其中，将缓存保证属性和多传送带属性添加到DVB-MHP标准；图21示出了根据DVB-MHP标准在AIT中定义的原始应用程序描述符的实例；图22是示出实施例4的应用程序执行设备的处理过程的流程图；图23是应用程序管理单元的应用程序执行控制过程3的流程图；图24是一个特定实例，其中，文件系统被两个对象传送带分割并分发；以及图25是由主例程执行的执行控制的流程图。
参考标记的解释10 应用程序执行设备10a 应用程序执行设备10b 应用程序执行设备10c 应用程序执行设备20 广播设备101 服务接收单元102 接收单元103 去复用单元
104应用程序管理单元104a 应用程序管理单元104b 应用程序管理单元104c 应用程序管理单元105应用程序控制单元105a 应用程序控制单元105b 应用程序控制单元105c 应用程序控制单元106缓存完成监视单元106b 基于目录的缓存完成监视单元106c 缓存完成监视单元107传送带存储单元107c 传送带存储单元108应用程序执行单元109解码单元110输出单元401Java平台402JavaI/O403DSM-CC404解码器405应用程序管理器406Java虚拟机407类加载器408堆区域409线程单元410传送带接收单元1101 缓存保证属性提取单元1501 多目录属性提取单元1901 多传送带属性提取单元1902 传送带存储单元
1903 缓存完成监视单元最佳实施方式以下参照

了本发明的实施例。
实施例1在此解释本发明的应用程序执行设备的一个实施例。首先，联系本发明的应用程序执行设备的实现来说明使用应用。本发明的应用程序执行设备由用户用于如图1所示的数字广播系统中。图1的数字广播系统基于服从以DVB-MHP为代表的数字广播标准的常规数字广播系统，并包括应用程序执行设备10和广播设备20。
广播设备20使用广播信道广播MPEG2(运动图像专家组阶段2)中的TS。在TS中，广播节目的组成部分被多路复用。广播节目包括作为其组成部分的至少一个应用程序，通常还包括作为其组成部分的视频数据和音频数据。应用程序由多个类文件和多个数据文件组成。使用对象传送带发送应用程序。
应用程序执行设备10执行从已经从广播设备20接收到的TS中去复用的每一个应用程序。通常，应用程序执行设备10还重放视频和音频数据，并将其输出。
这样完成了应用程序执行设备10的使用应用的说明。接下来，说明应用程序执行设备10的产生应用。
<结构>
图2是示出应用程序执行设备10的结构的功能框图。如图2所示，应用程序执行设备10包括服务接收单元101；接收单元102；去复用单元103；应用程序管理单元104；传送带存储单元107；应用程序执行单元108；解码单元109；及输出单元110。
服务接收单元101管理服务选择。具体说来，服务接收单元101接收由用户通过遥控器信号的指令或者由应用程序的指令而做出的用于改变服务的请求，然后将该请求通知接收单元102。
接收单元102通过天线或有线电缆接收在携带有所选择的服务的TS载波频率中的信号，并对TS进行解调。随后，接收单元102将解调的TS发送到去复用单元103。在此，如果应用程序执行设备是从数字线路获得信号，则解调功能可以省略。
当接收到从接收单元102发送的TS时，去复用单元103将TS信号去复用为视频/音频数据、对象传送带和AIT(应用程序信息表)，AIT是与应用程序控制相关的信息。随后，去复用单元103分别向解码单元109、传送带存储单元107和应用程序控制单元105提供视频/音频数据、对象传送带和AIT。
应用程序管理单元104管理应用程序的生命周期。应用程序管理单元104包括应用程序控制单元105和缓存完成监视单元106。
应用程序控制单元105从AIT中提取在由服务接收单元101所通知的服务中要启动的应用程序的信息。另外，在从缓存完成监视单元106接收到缓存完成通知后，应用程序控制单元105向应用程序执行单元108给出用于开始应用程序执行的指令。应用程序控制单元105向缓存完成监视单元106发送所提取的应用程序信息。在此，具体说来，如图3所示，从AIT提取的应用程序信息由基本目录(base_directory)301、初始类(initial_class)302和类路径扩展(classpath_exptension)303组成。
基本目录301是一个目录，在其中存储了应用程序的主例程。基本目录301被认为是在类路径上自动形成第一目录。
初始类302是与基本目录301配对的信息，并指示要首先启动的类文件名。
类路径扩展303指示除主例程之外的类文件。
缓存完成监视单元106判断是否所有应用程序组成文件都已经被缓存。当所述判断为肯定时，缓存完成监视单元106通知应用程序控制单元105缓存完成。
传送带存储单元107采用将对象传送带作为一个文件系统而进行访问的方式，缓存用于与所选择的服务相对应的应用程序的对象传送带。随后，响应于从应用程序执行单元108而来的读取文件的请求，传送带存储单元107提供文件。具体说来，“缓存”在此意味着在诸如存储器之类的存储设备中存储某物。
应用程序执行单元108从传送带存储单元107读取由应用程序控制单元105指示的应用程序组成文件，随后，当接收到开始执行的指令时，解释并执行它们。具体说来，应用程序执行单元108是服从DVB-MHP的Java虚拟机。
解码单元109从去复用单元103接收视频/音频数据，并对其进行解码。
输出单元110输出解码的视频/音频数据和从应用程序执行单元108发送的图形。
图4示出了一个硬件平台的详细分层结构，该硬件平台是在应用程序执行设备10的功能框图中所示结构的实际实现的一个实例。如图所示，应用程序执行设备10由Java平台401、JavaI/O 402、DSM-CC(数字存储介质命令和控制)403及解码器404组成。
Java平台401包括Java虚拟机406和应用程序管理器405。Java虚拟机406将用Java语言所写的Java对象转换为应用程序执行设备10的CPU的本机码，并使CPU执行该码。更准确而言，Java虚拟机406将作为应用程序组成部分的xlet程序载入到堆区域中，解码xlet程序，并根据解码结果执行控制。
Java虚拟机406由类加载器407、堆区域408和线程单元409组成。
类加载器407从DSM-CC403将类文件读出到堆区域408。类加载器407的类文件读出是使用文件路径实现的。如果该文件路径指示DSM-CC403，类加载器407就从DSM-CC403中将类文件读出到堆区域408。
在堆区域408中，存储了各种类文件的实例。这些实例是组成应用程序的xlet程序。当这些xlet程序置于堆区域408中时，应用程序就成为可执行的。
线程单元409是逻辑执行实体，其执行存储在堆区域408中的实例。
应用程序管理器405指示类加载器407加载类。应用程序管理器405还判断JavaI/O 402是否已经对于所有应用程序组成文件中的每一个都返回了一个SUCCESS(成功)响应。在获得对于所有文件的SUCCESS响应的情况下，应用程序管理器405指示线程单元409开始应用程序执行。在此，对于其每一个都已经返回了SUCCESS响应的所有文件可以包括这样的文件即，对于该文件的已经返回的SUCCESS响应是在曾经返回FALSE(错误)响应之后再次载入该文件的结果。基于从AIT中提取的应用程序信息，来做出是否对于所有文件都已经返回了SUCCESS响应的判断。
JavaI/O 402对于从类加载器407而来的每个类文件的加载，向应用程序管理器405返回一个SUCCESS或FALSE响应。具体说来，当从类加载器407接收到具有文件路径详细说明的加载指令时，JavaI/O 402判断所指定的类文件是否已经缓存在DSM-CC403中。当所指定的类文件已经被缓存时，JavaI/O 402就将类文件加载到堆区域408中，随后向应用程序管理器405发送一个SUCCES响应。另一方面，当类文件没有被缓存时，JavaI/O 402向应用程序管理器405发送一个FALSE响应。
DSM-CC403管理类文件的缓存。
传送带接收单元410接收并缓存对象传送带。
解码器404解码视频/音频数据。
<数据>
图5A和5B示出了对象传送带发送应用程序组成文件的一种方法。图5A示出了从广播设备20发送的文件系统。图5B示出了正在从广播设备20发送到应用程序执行设备10的文件系统的一部分。如图5B所示，没有一次发送全部文件系统，该发送是在层到层(layer-to-lyaer)的基础上周期性地重复完成的。就是说，通过对于从任意时间点开始的一个周期获得多个文件并在应用程序执行设备10的存储器中扩展这些文件，使得应用程序执行设备10恢复文件。
图6是示出TS和组成TS的TS分组的语法的实例的示意图。TS由大量TS分组组成，每一个TS分组都是188字节。每个TS分组包括首部，其提供关于TS分组的信息，以及净荷(payload)，在其中记录实际数据。
首部包括同步字节；净荷单元开始指示符；传输优先级；分组标识符(PID)；扰频控制；适应字段控制；连续计数器；及适应字段。将一个(或多个)预定的位分发给这些组成部分的每一个，提供与TS分组相关的信息。
净荷包括分组的音频/视频数据和服务数据。每个音频/视频数据和服务数据分组由分组标识符来识别。对于每个分组，将音频/视频数据和服务数据多路复用到TS中，并从广播设备20发送到应用程序执行设备10。
图7是示出TS的一个实例的示意图，该TS包括两个广播节目，服务A和服务B。在此，假定对于每个广播节目，将一组音频数据和视频数据、作为与应用程序的控制相关的信息的AIT、和包含应用程序组成文件的对象传送带多路复用到一起并进行发送。在该TS中包含的广播节目由用于分发称为PMT(节目映射表)的表的一个TS分组表示。该TS分组的PID在用于分发称为PAT(节目关联表)的表的一个TS分组中示出，它的PID为“0”。PMT中存储了包括在服务中的视频、音频、AIT等的PID。采用PID识别TS分组的类型。通过参考PMT，只有组成目标节目的TS分组能够从流中取出。收集这些具有这种PID的分组使得原始视频能够被重放。
根据图7所示的实例，服务A的PID是100，而服务B的PID是200。另外，PMT包括音频数据、视频数据、AIT和对象传送带中每一个的PID，对象传送带分发包括多个应用程序组成文件的文件系统。在此，对于服务A，音频数据、视频数据、AIT和对象传送带在TS分组中分别被分配有PID101、102、103和104。对象传送带的组成部分标签是1104。AIT包括控制应用程序所必需的信息，例如用于开始及停止应用程序的控制指令、分发应用程序的对象传送带的组成部分标签(用于得到对象传送带的PID的链接信息)、以及首先用于开始应用程序文件路径。应用程序执行设备10基本上根据正在重放的节目信息中包含的AIT来控制应用程序。
<操作>
以下说明应用程序执行设备10的处理操作。图8是示出应用程序执行设备10的处理过程的流程图。首先，服务接收单元101接收一个与某服务相对应的数值，并将其通知接收单元102(S801)，该服务由在遥控器上的用户操作、从应用程序而来的请求或在电源接通时的初始设定来指定。接收单元102调谐到与接收的数值相对应的服务的载波上，接收TS，随后将接收的TS解调为数字数据(S802)。去复用单元103得到被多路复用到TS中的PMT和PAT，使用存储在PMT中的PID识别视频/音频数据、对象传送带和AIT，并对其进行去复用(S803)。解码单元109对由去复用单元103去复用的视频/音频数据进行解码，输出单元110输出由解码单元109解码的数据(S804)。传送带存储单元107缓存与应用程序相关的对象传送带，该应用程序是所选择的服务的启动目标(S805)。应用程序管理单元104执行应用程序执行控制过程(S806)。
图9是由应用程序管理单元104执行的应用程序执行控制过程的流程图。应用程序管理单元104指示应用程序执行单元108加载与初始类302相对应的类文件，初始类302是从AIT中提取的应用程序信息(S901)。判断要加载的文件是否存在于传送带存储单元107中(S902)。当所述判断为肯定时，将与初始类302相对应的类文件读取到应用程序执行单元108，应用程序管理单元104接收从JavaI/O而来的一个SUCCESS响应。在所述判断是否定的情况下，应用程序管理单元104接收从JavaI/O而来的一个FALSE响应(S904)。应用程序管理单元104判断是否存在与该应用程序相关的任何其它类文件(S905)。具体说来，基于基本目录301和类路径扩展303来做出上述判断，基本目录301和类路径扩展303是从AIT中提取的应用程序信息。当所述判断为肯定时，应用程序管理单元104指示应用程序执行单元108加载由基本目录301或类路径扩展303所指示的应用程序组成文件(S906)，随后移动到步骤S902。当所述判断为否定时，应用程序管理单元104判断是否已经接收到对于该应用程序的所有类文件的一个SUCCESS响应(S907)。在此，当所述判断为否定时，应用程序管理单元104再一次发出指令，用于加载已经返回FALSE响应的类文件(S908)。另一方面，当所述判断为肯定时，应用程序管理单元104指示应用程序执行单元108开始应用程序执行。响应于用于开始应用程序执行的指令，应用程序执行单元108解释并执行加载的类文件(S909)。
图10是由对象传送带分发的文件系统FS1的一个特定实例。文件系统FS1包括两个应用程序应用程序1和应用程序2。应用程序1由文件F1和文件FC组成；而应用程序2由文件F2和文件FC组成。在启动目标应用程序是应用程序1的情况下，应用程序控制单元105在从缓存完成监视单元106接收到缓存完成通知后，指示应用程序执行单元108开始应用程序执行。由于已经缓存了在文件系统FS1中所示的所有文件，因此传送带存储单元107能够响应应用程序执行单元108的读取文件的请求，而无需执行对所述文件的缓存过程。因此，即使是当应用程序执行单元108处于不能从接收单元102接收数据的状态，也可以保证文件的读取。
因此，根据本实施例，在从缓存完成监视单元106接收到缓存完成通知后，应用程序控制单元105向应用程序执行单元108发出用于开始应用程序执行的指令。这避免了当应用程序组成文件仍需被缓存时运行该应用程序，确保了在该应用程序的结束处理中的稳定运行。
另外，有时存在一个应用程序在部分应用程序组成文件已经被缓存在存储器中时运行，然后该应用程序或一个不同的应用程序在运行中执行调谐API的情况。即使在这种情况下，如上所述，通过在从缓存完成监视单元106接收到缓存完成通知之后执行该应用程序，就能够确保该应用程序的结束处理。
另外，在一个应用程序在部分应用程序组成文件已经被缓存在存储器时运行的情况下，由于例如在运行中有线电缆被拔出，从而导致了接收性能降低，因此有可能不能接收到TS。即使在这种情况下，通过在从缓存完成监视单元106接收到缓存完成通知之后执行该应用程序，就能够确保该应用程序的结束处理。
实施例2即使TS稍后改变了，通过在文件系统上的所有应用程序组成文件都已经被缓存到应用程序执行设备10中之后开始应用程序，实施例1确保了在该应用程序执行时的文件读取中无故障。然而，有一些应用程序不需要文件读取保证，其更加希望是缩短所述启动所花费的时间。给出这个因素，本实施例根据每个应用程序的特性，对其采取了不同的过程。
根据本实施例，在图1的数字广播系统中的广播节目除了在实施例1中所示的组成部分之外，还包括了作为其组成部分的一个属性，所述属性指示是否需要在应用程序执行时的文件读取中无故障的保证(以下，称为“缓存保证属性”)。
图11示出了根据本实施例的应用程序执行设备10a的功能框图。如图11所示，应用程序执行设备10a具有一种结构，在该结构中，将缓存保证属性提取单元1101添加到实施例1的应用程序执行设备10中。
缓存保证属性提取单元1101从AIT中提取缓存保证属性，并将其提供给应用程序控制单元105a，缓存保证属性是与在TS中的应用程序控制相关的信息。
本实施例的应用程序控制单元105a从由服务接收单元101所指定的服务的AIT中提取要启动的应用程序的信息。应用程序控制单元105a还向缓存完成监视单元106发送所提取的应用程序信息。当从缓存保证属性提取单元1101接收到该应用程序的缓存保证属性时，应用程序控制单元105a判断缓存保证属性是否是指示在文件读取中无故障的保证的必要性的属性。当所述判断结果为肯定时，应用程序控制单元105a执行应用程序的验证，并在接收到来自缓存完成监视单元106的缓存完成通知后，给出用于开始该应用程序执行的指令。当所述判断为否定时，应用程序控制单元105a向应用程序执行单元108给出用于开始该应用程序执行的指令，而无需等待从缓存完成监视单元106发送的缓存完成通知。
图12示出了一个特定实例，其中，将缓存保证属性CG添加到DVB-MHP标准中。如图12所示，在DVB-MHP的一个AIT中，将缓存保证属性CG添加到其中，作为在该AIT中定义的应用程序描述符的缓存保证标志字段。
<操作>
以下说明本实施例的应用程序执行设备10a操作。
图13是示出应用程序执行设备10a的处理过程的流程图。首先，服务接收单元101接收一个与某服务相对应的数值，并将其通知给接收单元102(S1301)，该服务由在遥控器上的用户操作、从应用程序而来的请求、或者在接通电源时刻的初始设定来指定。接收单元102调谐到与所接收的数值相对应的服务的载波上，接收TS，并且随后将接收到的TS解调为数字数据(S1302)。去复用单元103得到被多路复用到TS中的PMT和PAT，使用存储在PMT中的PID识别视频/音频数据、对象传送带和AIT，并对其进行去复用(S1303)。解码单元109对所述视频/音频数据进行解码，并且输出单元110输出解码的数据(S1304)。传送带存储单元107缓存与应用程序相关的对象传送带，所述应用程序是所选择服务的启动目标(S1305)。应用程序管理单元104a从缓存保证属性提取单元1101接收缓存保证属性，随后判断该缓存保证属性是否是指示在文件读取中无故障的保证的必要性的属性(S1306)。当所述判断为肯定时，应用程序管理单元104a执行图9的应用程序执行控制过程(S1307)。当所述判断为否定时，应用程序管理单元104a执行应用程序执行过程(S1308)。
图14是由应用程序管理单元104a所执行的应用程序执行过程的流程图。应用程序管理单元104a指示应用程序执行单元108加载与初始类302相对应的类文件，初始类302是从AIT中提取的应用程序信息(S1401)。判断要被加载的文件是否存在于传送带存储单元107中(S1402)。当所述判断为肯定时，将与初始类302相对应的类文件读取到应用程序执行单元108，并且应用程序管理单元104a从JavaI/O接收一个SUCCESS响应(S1404)。然后，应用程序管理单元104a向应用程序执行单元108给出用于开始执行的指令。被应用程序管理单元104a指示开始应用程序执行的应用程序执行单元108解释所加载的类文件并执行它(S1405)。当所述判断为否定时，应用程序管理单元104a从JavaI/O接收一个FALSE响应(S1403)，并随后移动到S1401。应用程序管理单元104a判断是否存在与该应用程序相关的任何其它类文件(S1406)。具体说来，基于基本目录301和类路径扩展303来做出上述判断，基本目录301和类路径扩展303是从AIT中提取的应用程序信息。当所述判断为否定时，应用程序管理单元104a结束该过程。当所述判断为肯定时，应用程序管理单元104a判断读取另一个文件的必要性(S1407)。在此，当所述判断为肯定时，应用程序管理单元104a给出用于加载必要的文件的指令(S1408)。然后，做出对于要加载的目标文件是否存在于传送带存储单元107中的判断(S1409)。当所述判断为肯定时，将该类文件读取到应用程序执行单元108，并且应用程序管理单元104a从JavaI/O接收一个SUCCESS响应(S1411)。然后，应用程序管理单元108执行所读取的类文件(S1405)。当所述判断为否定时，应用程序管理单元104a从JavaI/O接收一个FALSE响应(S1410)，并随后移动到S1408。这样，在应用程序执行过程中，应用程序管理单元104a向应用程序执行单元108给出用于开始应用程序执行的指令，而无需等待缓存完成通知。然后，被应用程序管理单元104a指示开始应用程序执行的应用程序执行单元108读取要首先执行的类文件，随后解释并执行该类文件。另外，每当组成应用程序的其它文件在解释/执行过程中变为必要的时候，应用程序执行单元108就读取它们，然后解释并执行所读取的类文件。
参照图10给出以下的解释。在由图10的对象传送带所分发的文件系统FS1的特定实例中，如果启动目标应用程序是应用程序1并且缓存保证属性是表示在文件读取中无故障的保证的必要性的属性，则执行与实施例1相同的过程。就是说，在从缓存完成监视单元106接收到缓存完成通知后，应用程序控制单元105a向应用程序执行单元108发送用于开始执行的指令。因此，传送带存储单元107能够响应读取文件的请求，而无需执行对所述文件的缓存过程。因此，即使是当应用程序执行单元108处于不能从接收单元102接收数据的状态时，也可以确保文件的读取。
另一方面，在启动目标应用程序是应用程序1并且缓存保证属性不是表示在文件读取中无故障的保证的必要性的属性的情况下，应用程序控制单元105a向应用程序执行单元108给出用于开始应用程序的指令，而无需等待从缓存完成监视单元106而来的缓存完成通知。因此，传送带存储单元107也可以响应从应用程序执行单元108而来的读取文件的请求，同时在当在没有做出文件读取请求期间对仍然要被缓存的文件进行缓存。因此，与等待所有文件被缓存的情况相比，能够更快的实现应用程序的启动。
因此，根据本实施例，缓存保证属性实现了根据应用程序是需要在文件读取中无故障的保证的应用程序，还是不需要相同保证的应用程序以及是否在启动速度和存储器效率上具有所期望的优先级，来做出启动方法的选择。
应指出，在本实施例中，缓存保证属性是作为包含在AIT中的新属性而被增加并使用的；然而本发明并不限于此。例如，可以替换地使用作为在图12的AIT中的现有属性的优先级属性AP，或者使用服务绑定属性SB。在具有多个应用程序的情况下，优先级属性AP是指示将资源优先分配给哪一个应用程序的属性。服务绑定属性SB是指示应用程序是否是服务绑定的属性。在应用程序是服务绑定的情况下，在当前服务被转换到另一个服务时，该应用程序结束。例如，当使用优先级属性时，应用程序控制单元105a判断优先级信息是否是在预定的阈值上或更高。然后，当所述判断为肯定时，在从缓存完成监视单元106接收到缓存完成通知之后，应用程序控制单元105a可以给出执行指令。
当使用服务绑定属性时，应用程序控制单元105a判断该服务绑定属性是否是服务绑定的。随后，当所述判断为肯定时，在从缓存完成监视单元106接收到缓存完成通知后，应用程序控制单元105a可以给出执行指令。因此，即使做出了到一个包括调谐的服务的转换，且对于该服务，在服务绑定应用程序的操作期间，尽管部分应用程序组成文件已经被缓存在存储器中也不允许应用程序的启动，当在服务中的转换之后要结束应用程序时，应用程序的结束处理能够被正常执行。
实施例3
在文件系统上存在组成多个应用程序的文件的情况下，在所有文件已经被缓存之后，实施例1给出了开始指令。然而，例如有时存在文件系统上的多个应用程序中只有一个是启动目标的情况。在此情况下，等待要缓存的多个应用程序的所有文件都完成是缺乏效率的。给出这个因素，在本实施例中，将一个标识符提供给组成单个应用程序的文件，以便区分这些文件与其它文件。随后，采用这些被分割并指定到多个目录之后进行分发的文件，应用程序执行设备在已经缓存了执行一个应用程序所必需的文件之后，给出用于开始执行的指令。
根据本实施例，在图1的数字广播系统中，在已经将应用程序组成文件分割并指定到多个目录之后对其进行分发。除了在实施例2中所示的组成部分之外，广播节目还包括作为其组成部分的一个属性，该属性指示包含有组成一个应用程序的文件的目录(以下称为“多目录属性”)。
在图15中，应用程序执行设备10b具有一个结构，在该结构中，将多目录属性提取单元1501以及替换缓存完成监视单元106的基于目录的缓存完成监视单元106b一起增加到实施例2的应用程序执行设备10a中。
多目录属性提取单元1501从AIT中提取多目录属性，并将其提供到应用程序控制单元105b，所述AIT是与在TS中的应用程序控制相关的信息。
基于目录的缓存完成监视单元106b判断包含在由多目录属性所示的目录中的所有应用程序组成文件是否都已经被缓存。如果所述判断为肯定，则基于目录的缓存完成监视单元106b就通知应用程序控制单元105b缓存完成。
本实施例的应用程序控制单元105b从由服务接收单元101所指定的服务的AIT中提取要启动的应用程序的信息。当从缓存保证属性提取单元1101接收到该应用程序的缓存保证属性时，应用程序控制单元105b判断缓存保证属性是否是指示在文件读取中无故障的保证的必要性的属性。当所述判断结果为肯定时，应用程序控制单元105b执行应用程序的验证，并在从基于目录的缓存完成监视单元106b接收到缓存完成通知后，给出用于开始应用程序执行的指令。当所述判断结果为否定时，应用程序控制单元105b向应用程序执行单元108给出用于开始应用程序执行的指令，而无需等待从基于目录的缓存完成监视单元106b发送的缓存完成通知。应用程序控制单元105b还向基于目录的缓存完成监视单元106b发送所提取的应用程序信息。
图16示出了一个特定实例，其中，将对于本实施例唯一性的多目录属性应用到DVB-MHP标准。如图16所示，在DVB-MHP的AIT中，多目录属性MD1是在AIT中定义的应用程序描述符(application_descriptor)中的现有基本目录字段的转换，而多目录属性MD2是作为扩展目录(extension_directory)字段而新增加到应用程序描述符中的。在此，多目录属性MD1示出了一个目录树的路径，其包括在应用程序组成文件中的、在启动应用程序时首先使用的文件。另一方面，多目录属性MD2示出了一个目录树的路径，其包括除那些包括在由多目录属性MD1所指示的目录树中的之外的应用程序组成文件。
<操作>
以下说明本实施例的应用程序执行设备10b的操作。
图17是示出应用程序执行设备10b的处理过程的流程图。首先，服务接收单元101接收一个与某服务相对应的数值，并将其通知接收单元102(S1701)，该服务由在遥控器上的用户操作、从应用程序而来的请求、或在接通电源时的初始设定来指定。接收单元102调谐到与接收的数值相对应的服务的载波上，接收TS，并随后将接收的TS解调为数字数据(S1702)。去复用单元103获得被多路复用到TS中的PMT和PAT，使用存储在PMT中的PID识别视频/音频数据、对象传送带和AIT，并对其进行去复用(S1703)。解码单元109对所述视频/音频数据进行解码，并且输出单元110输出解码的数据(S1704)。传送带存储单元107缓存与应用程序相关的对象传送带，所述应用程序是所选择服务的启动目标(S1705)。应用程序管理单元104b分别从缓存保证属性提取单元1101和多目录属性提取单元1501接收缓存保证属性和多目录属性，随后判断缓存保证属性是否是指示保证的必要性的属性(S1706)。当所述判断为肯定时，应用程序管理单元104b执行应用程序执行控制过程2(S1707)。当所述判断为否定时，应用程序管理单元104b执行图14的应用程序执行过程(S1708)。就是说，应用程序控制单元105b向应用程序执行单元108给出用于启动应用程序的指令，而无需等待从基于目录的缓存完成监视单元106b发送的缓存完成通知。
图18是示出由应用程序管理单元104b所执行的应用程序执行控制过程2的流程图。根据多目录属性，应用程序管理单元104b识别一个目录，该目录包括在应用程序组成文件中的、在应用程序启动时首先使用的文件(S1801)。随后，应用程序管理单元104b指示应用程序执行单元108加载与在所识别的目录中的初始类相对应的类文件(S1802)。判断要被加载的文件是否存在于传送带存储单元107中(S1803)。应用程序执行单元108加载与初始类相对应的类文件。在所述判断为肯定的情况下，将与初始类302相对应的类文件读取到应用程序执行单元108，应用程序管理单元104b从JavaI/O接收到一个SUCCESS响应(S1804)。在所述判断为否定的情况下，应用程序管理单元104b从JavaI/O接收一个FALSE响应(S1805)。应用程序管理单元104b判断是否有与该应用程序相关的任何类文件仍然留在由多目录属性所指示的目录中(S1806)。具体说来，基于基本目录301和类路径扩展303来做出所述判断，基本目录301和类路径扩展303是从AIT中提取的应用程序信息。当所述判断为肯定时，应用程序管理单元104b指示应用程序执行单元108加载由基本目录301或类路径扩展303所指示的应用程序组成文件(S1807)，随后移动到步骤S1803。当所述判断为否定时，应用程序管理单元104b判断是否存在由多目录属性指示的另一个目录(S1808)。在此，如果所述判断为肯定的，应用程序管理单元104b指示应用程序执行单元108加载在该目录中的文件(S1809)，随后移动到步骤S1803。如果所述判断为否定时，应用程序管理单元104b判断是否对于在由多目录属性所指示的目录中的所有文件都已经接收到一个SUCCESS响应(S1810)。如果所述判断为否定的，应用程序管理单元104b再一次发出用于加载对其已经返回了一个FALSE响应的类文件的指令(S1811)。另一方面，当所述判断为肯定时，应用程序管理单元104b指示应用程序执行单元108启动应用程序执行。响应于该用于启动应用程序执行的指令，应用程序执行单元108解释并执行加载的类文件(S1812)。
以下参照图10给出具体解释，图10示出了要由对象传送带分发的文件系统FS1的一个特定实例。在此，在启动目标应用程序是应用程序1并且缓存属性是指示在文件读取中无故障的保证的必要性的属性的情况下，在从基于目录的缓存完成监视单元106b接收到缓存完成通知后，应用程序控制单元105b向应用程序执行单元108发送用于启动应用程序的指令。在此，基于目录的缓存完成监视单元106b所监视的目标文件限于文件F1和文件FC。另外，多目录属性MD1是“/app1”；多目录属性MD2是“/common”。因此，基于目录的缓存完成监视单元106b通知应用程序控制单元105b缓存完成通知，而无需等待文件F2的缓存完成。因此，传送带存储单元107能够响应用于读取文件的请求，而无需执行对所述文件的缓存过程。结果，即使当应用程序执行单元108处于不能够从接收单元102接收数据的状态，也可以确保文件的读取。而且，通过限制要被缓存的文件，应用程序的启动能够加速。
另一方面，在启动目标应用程序是应用程序1并且缓存保证属性不是指示在文件读取中无故障的保证的必要性的属性的情况下，应用程序控制单元105b向应用程序执行单元108给出用于启动应用程序的指令，而无需等待从缓存完成监视单元106而来的缓存完成通知。因此，传送带存储单元107也可以响应从应用程序执行单元108而来的读取文件的请求，同时在当在没有做出文件读取请求期间对仍然要被缓存的文件进行缓存。因此，与等待由多目录属性所指示的目录中的所有文件都被缓存的情况相比，能够更快的实现应用程序的启动。
因此，根据本实施例，在基于多目录属性而仅仅缓存对于执行应用程序所必需的文件之后，就可以启动应用程序，这导致了应用程序的更快的启动。
实施例4本实施例的应用程序执行设备10c对于在已经被分割并指定到多个对象传送带之后进行分发的应用程序组成文件进行缓存，从而以受限的方式仅仅缓存对于执行应用程序所必需的文件。
根据本实施例，在图1的数字广播系统中，在已经将应用程序组成文件分割并指定到多个目录之后对其进行分发。除了在实施例2中所示的组成部分之外，广播节目还包括作为其组成部分的一个属性，其指示包含由组成一个应用程序的文件的对象传送带(以下称为“多传送带属性”)。
在本实施例中，假定组成一个应用程序的文件时在已经被分割并指定到两个对象传送带后进行分发的。
在图19中，应用程序执行设备10c具有一个结构，在该结构中，将多传送带属性提取单元1901与传送带存储单元1902和缓存完成监视单元1903一起增加到实施例2的应用程序执行设备10a中。
多传送带属性提取单元1901从AIT中提取多传送带属性，并将其提供到应用程序控制单元105c，AIT是与在TS中的应用程序控制相关的信息。
传送带存储单元1902采用将对象传送带作为一个文件系统而进行访问的方式存储包括在所选择服务中的一个对象传送带。响应于从应用程序执行单元108而来的读取文件的请求，传送带存储单元提供文件。在此，传送带存储单元是传送带存储单元1902和107中的已经缓存了由应用程序执行单元108所请求的文件的那一个传送带存储单元。
缓存完成监视单元1903判断是否整个对象传送带都已经被缓存在传送带存储单元1902中。如果所述判断为肯定的，缓存完成监视单元1903通知应用程序控制单元105c所述完成。
另外，本实施例的传送带存储单元107c将对象传送带作为一个文件系统而进行访问的方式，存储包括在所选择服务中的其它对象传送带。
本实施例的缓存完成监视单元106c判断是否整个对象传送带都已经被缓存在传送带存储单元107c中。如果所述判断是肯定的，缓存完成监视单元106c通知应用程序控制单元105c所述完成。
本实施例的应用程序控制单元105c从由服务接收单元101指定的服务的AIT中提取要启动的应用程序的信息。当从缓存保证属性提取单元1101接收到应用程序的缓存保证属性时，应用程序控制单元105c判断缓存保证属性是否是指示在文件读取中无故障的保证的必要性的属性。当所述判断结果为肯定时，应用程序控制单元105c执行应用程序的验证，并在从缓存完成监视单元1903和106c接收到缓存完成通知之后，给出用于开始应用程序执行的指令。当所述判断结果为否定时，应用程序控制单元105c向应用程序执行单元108给出用于开始应用程序执行的指令，而无需等待从缓存完成监视单元1903和106c发送的缓存完成通知。应用程序控制单元105c还向缓存完成监视单元1903和106c发送所提取的应用程序信息。
图20示出了一个特定实例，其中，将缓存保证属性CG和多传送带属性MC增加到DVB-MHP标准中。如图20所示，在DVB-MHP的AIT中，增加多传送带属性MC，作为在AIT中定义的应用程序描述符的transport_protocol_label(传输协议标记)字段的扩展。缓存保证属性CG与实施例2中的相同。图21示出了在服从DVB-MHP标准的AIT中定义的原始应用程序描述符的一个实例。传输协议标记属性TPL是对多传送带属性MC一部分扩展的原始属性，其能够指示多个分发路径。一个transport_protocol_label字段的值指示分发所有应用程序组成文件的一个对象传送带或“经由DVB多协议封装的IP”。采用一个for循环，能够指示多个transport_protocol_label字段的值，其能够指示多个分发路径。另一方面，在图20的扩展的多传送带属性MC中，将一个附加的for循环增加到所述能够指示多个分发路径的for循环中。该附加的for循环指示一个或多个对象传送带，所述传送带在一个分发路径中分发已经被分割的应用程序。在此，如同对象传送带，“经由DVB多协议封装的IP”是分发在TS中的文件系统，并用作用于在DVB-MHP标准中分发应用程序组成文件的方法。
<操作>
以下说明本实施例的应用程序执行设备10c的操作。图22是示出应用程序执行设备10c的处理过程的流程图。首先，服务接收单元101接收一个与某服务相对应的数值，并将其通知接收单元102(S2201)，该服务由在遥控器上的用户操作、从应用程序而来的请求、或在接通电源时的初始设定来指定。接收单元102调谐到与所接收的数值相对应的服务的载波上，接收TS，并随后将接收的TS解调为数字数据(S2202)。去复用单元103获得被多路复用到TS中的PMT和PAT，使用存储在PMT中的PID识别视频/音频数据、对象传送带和AIT，并对其进行去复用(S2203)。解码单元109对所述视频/音频数据进行解码，并且输出单元110输出解码的数据(S2204)。传送带存储单元107和1902缓存与应用程序相关的对象传送带，所述应用程序是所选服务的启动目标。就是说，将两个对象传送带分别缓存在不同的传送带存储单元中(S2205)。应用程序管理单元104c分别从缓存保证属性提取单元1101和多传送带属性提取单元1901接收缓存保证属性和多传送带属性，随后判断缓存保证属性是否是指示在文件读取中无故障的保证的必要性的属性(S2206)。当所述判断为肯定时，应用程序管理单元104c执行应用程序执行控制过程3(S2207)。当所述判断为否定时，应用程序管理单元104c执行图14的应用程序执行过程(S2208)。就是说，应用程序控制单元105c向应用程序执行单元108给出用于启动应用程序的指令，而无需等待从缓存完成监视单元1903和106c发送的缓存完成通知。
图23是示出由应用程序管理单元104c所执行的应用程序执行控制过程3的流程图。应用程序管理单元104c指示应用程序执行单元108加载与初始类302相对应的类文件，初始类302是从AIT中提取的应用程序信息(S2301)。判断要被加载的文件是否存在于传送带存储单元107c或传送带存储单元1902中(S2302)。在所述判断是肯定的情况下，将与初始类302相对应的类文件读取到应用程序执行单元108，并且应用程序管理单元104c从JavaI/O接收一个SUCCESS响应(S2303)。在所述判断是否定的情况下，应用程序管理单元104c从JavaI/O接收一个FALSE响应(S2304)。应用程序管理单元104c判断在由多传送带属性指示的传送带中是否存在另一个类文件(S2305)。具体说来，基于基本目录301和类路径扩展303来做出所述判断，基本目录301和类路径扩展303是从AIT中提取的应用程序信息。当所述判断为肯定时，应用程序管理单元104指示应用程序执行单元108加载由基本目录301或类路径扩展303所指示的应用程序组成文件(S2306)，随后移动到步骤S2302。当所述判断为否定时，应用程序管理单元104c判断是否对于在由多传送带属性所指示的传送带中的所有文件都已经接收到SUCCESS响应(S2307)。在此，如果所述判断是否定的，应用程序管理单元104c再一次发出指令，用于加载对其已经返回了FALSE响应的类文件(S2308)。另一方面，当所述判断为肯定时，应用程序管理单元104c指示应用程序执行单元108启动应用程序执行。响应于用于启动应用程序执行的指令，应用程序执行单元108解释并执行加载的类文件(S2309)。
图24是一个特定实例，其中，文件系统FS1被两个对象传送带分割并分发。如图24所示，文件系统FS1被分割为文件系统FS2和FS3，随后分别对其进行发送。文件系统FS2和FS3分别存储在传送带存储单元107c和1902。在此，在启动目标应用程序是应用程序1并且缓存保证属性是指示在文件读取中无故障的保证的必要性的属性的情况下，在从两个缓存完成监视单元106c和1903接收到缓存完成通知之后，应用程序控制单元105c向应用程序执行单元108发送用于启动应用程序的指令。因此，应用程序执行设备10c不用等待文件F2的缓存完成。于是，传送带存储单元107c和1902能够响应读取文件的请求，而无需执行所述文件的缓存过程。结果，即使当应用程序执行单元108处于不能从接收单元102接收数据的状态，也可以确保文件的读取。而且，通过限制要缓存的文件，应用程序的启动能加速。
另一方面，在启动目标应用程序是应用程序1并且缓存保证属性不是指示在文件读取中无故障的保证的必要性的属性的情况下，应用程序控制单元104c向应用程序执行单元108给出用于启动应用程序的指令，而无需等待从缓存完成监视单元106c和1903而来的缓存完成通知。因此，传送带存储单元107c和1902也可以响应从应用程序执行单元108而来的读取文件的请求，同时在当在没有做出文件读取请求期间对仍然要被缓存的文件进行缓存。因此，与等待在由多传送带属性所指示的传送带中的所有文件都被缓存的情况相比，能够更快的完成应用程序的启动。
这样，根据本实施例，能够将应用程序组成文件和其它文件分别指定到不同的传送带，并分别进行发送。因此，在仅仅缓存了应用程序执行所必需的文件之后，就可以启动应用程序，这导致了应用程序的更快的启动。
应指出在本实施例中，应用程序执行设备10c具有两组传送带存储单元和缓存完成监视单元；然而，它可以具有三组或更多组传送带存储单元和缓存完成监视单元。
<附加细节>
已经基于实施例说明了本发明的应用程序执行设备；然而，理所当然的本发明并不限于上述实施例。
在上述实施例中，数字广播系统包括一个应用程序执行设备和一个广播设备；然而，数字广播系统可以包括两个或多个应用程序执行设备和广播设备。
在上述实施例中，应用程序执行设备在缓存了所有应用程序组成文件之后，给出用于开始执行的指令；然而，如果缓存了在应用程序组成文件中的、执行应用程序结束处理中的挂起过程所必需的文件，就可以发出该指令。在此情况下，做出对于执行挂起过程所必需的另一个文件是否存在的判断，例如在图9的S905中。随后，在S907，判断是否对于在应用程序组成文件中的、执行挂起过程所必需的所有文件都已经接收到SUCCESS响应。这些判断是基于AIT做出的。
在上述实施例中，将每个属性都增加到在AIT中定义的现有描述符中；然而，可以将一个新的描述符增加到AIT中，或可以使用除AIT之外的表。
在上述实施例中，文件是通过对象传送带来发送的；然而，可以采用不同的分发方法，其中可以使用经由DVB多协议封装的IP、数据传送带或TCP/IP来代替对象传送带。可替换的，可以使用存储在DVD、BD或其它类型的记录介质中的文件。例如，由于HD视频在BD上播放，如果对HD视频的无缝重放给予了优先级，就会引起缓存错误。另外，在将BD从应用程序执行设备中取出的情况下会引起缓存错误。即使在这种情况下，根据上述处理，结束处理也能够适当的进行。
在上述实施例中，使用了应用程序执行设备；然而，本发明可以是包括在上述流程图中所示的步骤的一种方法以及包括程序代码的一种程序，所述程序代码使得计算机执行在上述流程图中所示的步骤。
在上述实施例中，缓存完成监视单元判断是否已经加载了所有应用程序组成文件；然而，可以添加一个缓存控制API(应用程序接口)，用于实现同类的过程。在此情况下，不是由应用程序管理单元，而是由应用程序的主例程来实现所述执行控制。图25是由主例程实现所述执行控制的流程图。首先，应用程序管理单元给出用于加载主例程的指令(S2501)。做出文件是否已被缓存的判断(S2502)，如果所述判断是肯定的，就加载它们。当加载了应用程序的主例程时，应用程序管理单元指示应用程序执行单元启动主例程(S2503)。主例程通过所述API检查所有应用程序组成类是否都已经被加载(S2504)。所述执行被挂起直至所有文件都被缓存为止(S2505)。当所有文件都已经被缓存，主例程的执行继续，整个应用程序也被执行(S2506)。然后，通过所述API向传送带存储单元发出指令，不要将应用程序组成文件缓存出来(cache out)(S2507)。
工业实用性本发明的应用程序执行设备能够在制造业中可操作地、连续地和重复地制造并销售。尤其的，其可以用作具有用于地面广播、卫星广播或有线数字广播的内置数字广播接收机和STB的电视机。
权利要求
1.一种应用程序执行设备，用于执行只能在所选择的服务中执行的应用程序，包括高速缓存单元；选择接收单元，用于接收来自用户的服务选择；文件接收单元，用于从由广播设备发送的对象传送带中接收应用程序组成文件，并将所述应用程序组成文件写入所述高速缓存单元，所述应用程序组成文件组成了与由所述用户所选择的服务相关的应用程序；判断单元，用于判断所述高速缓存单元是否已经缓存了在所述应用程序组成文件中的、执行挂起过程所需的文件；以及执行控制单元，如果所述判断是肯定的，则促成在所述高速缓存单元中缓存的应用程序组成文件的执行。
2.如权利要求1所述的应用程序执行设备，其中所述执行控制单元包括获取子单元，用于获取缓存保证属性信息，其指示在所述应用程序组成文件执行时文件读取中无故障的保证是否是必要的，以及当所获取的缓存保证属性信息指示所述保证是必要的时，所述执行控制单元控制所述执行。
3.如权利要求1所述的应用程序执行设备，其中所述执行控制单元包括获取子单元，用于获取优先级属性信息，其指示在存在多个应用程序的情况下，将资源优先分配给哪个应用程序，以及当所获取的优先级属性信息指示预定阈值的数值或更高的数值时，所述执行控制单元控制所述执行。
4.如权利要求1所述的应用程序执行设备，其中所述执行控制单元包括获取子单元，用于获取服务绑定属性信息，其指示所述应用程序是否只能在所述用户所选择的服务中执行，以及当所获取的服务绑定属性信息指示所述应用程序只能在所述用户所选择的服务中执行的时候，控制所述执行。
5.如权利要求1所述的应用程序执行设备，其中所述判断是基于与所有所述应用程序组成文件相关的信息而做出的。
6.如权利要求5所述的应用程序执行设备，其中所述执行控制单元包括提取子单元，用于从所述信息中提取目录属性，所述目录属性已经被指定给多个目录中的每一个，并且指示已经对其指定了所述目录属性的目录是否包括一个或多个所述应用程序组成文件，以及所获取的文件属于一个目录，该目录的被提取的目录属性指示该目录包括一个或多个所述应用程序组成文件。
7.一种计算机可读程序，用于使计算机执行一个过程，所述过程执行只能在所选择的服务中执行的应用程序，所述计算机可读程序使计算机执行选择接收代码，接收来自用户的服务选择；文件接收代码，从由广播设备发送的对象传送带中接收应用程序组成文件，并将所述应用程序组成文件写入所述计算机，所述应用程序组成文件组成了与由所述用户所选择的服务相关的应用程序；判断代码，判断所述计算机是否已经缓存了在所述应用程序组成文件中的、执行挂起过程所需的文件；以及执行控制代码，如果所述判断是肯定的，则促成在所述计算机中缓存的应用程序组成文件的执行。
8.一种应用程序执行方法，用于执行只能在所选择的服务中执行的应用程序，包括步骤接收来自用户的服务选择；从由广播设备发送的对象传送带中接收应用程序组成文件，并将所述应用程序组成文件写入计算机的高速缓冲存储器，所述应用程序组成文件组成了与由所述用户所选择的服务相关的应用程序；判断所述高速缓冲存储器是否已经缓存了在所述应用程序组成文件中的、执行挂起过程所需的文件；以及如果所述判断是肯定的，控制在所述高速缓冲存储器中缓存的应用程序组成文件的执行。
9.一种应用程序执行设备，用于执行只能在所选择的服务中执行的应用程序，包括高速缓存单元；选择接收单元，用于接收来自用户的服务选择；文件接收单元，用于从由广播设备发送的对象传送带中接收应用程序组成文件，并将所述应用程序组成文件写入所述高速缓存单元，所述应用程序组成文件组成了与由所述用户所选择服务相关的应用程序；以及接口单元，用于检查所述高速缓存单元是否已经缓存了在所述应用程序组成文件中的、执行挂起过程所需的文件，其中当主例程启动时，所述应用程序经由所述接口单元检查所述高速缓存单元是否已经缓存了所述所需的文件，如果所述检查的结果是否定的，就暂停所述应用程序组成文件的执行，直至所述所需的文件被缓存为止，并且当所述所需的文件被缓存时，继续所述执行。
10.一种应用程序执行设备，用于执行只能在预定服务中执行的应用程序，包括高速缓存单元；写入单元，用于从记录介质中读取应用程序组成文件，并将所述应用程序组成文件写入所述高速缓存单元，所述应用程序组成文件组成了与所述预定服务相关的应用程序；判断单元，用于判断所述高速缓存单元是否已经缓存了在所述应用程序组成文件中的、执行挂起过程所需的文件；以及执行控制单元，如果所述判断是肯定的，则促成在所述高速缓存单元中缓存的应用程序组成文件的执行。
全文摘要
本发明是一种应用程序执行设备，用于执行只能在所选择的服务中执行的应用程序，包括高速缓存单元；选择接收单元，用于接收来自用户的服务选择；文件接收单元，用于从由广播设备发送的对象传送带中接收应用程序组成文件，并将应用程序组成文件写入高速缓存单元，所述应用程序组成文件组成了与由用户所选则服务相关的应用程序；判断单元，用于判断高速缓存单元是否已经缓存了在应用程序组成文件中的、执行挂起过程所需的文件；及执行控制单元，如果判断是肯定的，则促成在高速缓存单元中缓存的应用程序组成文件的执行。
文档编号H04N5/00GK101052950SQ200580037528
公开日2007年10月10日 申请日期2005年11月1日 优先权日2004年11月2日
发明者平本建志 申请人:松下电器产业株式会社