技术领域 本发明涉及一种已验证程序运行方法，其检验所下载的程序的 可靠性并运行已被检验为可靠的程序。 背景技术 在数字电视中下载程序以及检查/保证该程序的可靠性的功能已 在DVB-MHP规范“ETSI TS 101 812 V1.2.1 DVB-MHP Specification 1.0.2”等中描述了。这个DVB-MHP规范规定了检验叠加到广播电 波上的被接收的程序没有被篡改以及检验该程序是否由可信赖的机 构发行的功能。这个功能使得防止被改写的程序和电子欺骗第三方 的程序被激活成为可能，其中，该被改写的程序没有按照初始所要 求的那样工作，由此可能对数字电视造成损害。 此外，日本公开的专利申请No.2000-29833描述了一项技术， 它由存储和发送数据的服务器装置和通过网络接收数据的终端装置 组成，该技术可以防止利用在终端装置上存储接收到的数据来对存 储的数据进行非法使用。日本公开的专利申请No.2000-29833的图 1描绘了该技术，其中，响应于来自终端装置20的请求，服务器装 置10将保存在存储单元15中的数据拷贝到存储单元23中，且当想 使用保存在存储单元23中的数据时，查询单元26向服务器装置10 进行查询，认证单元13对该数据的使用进行审核，如果没有问题， 则终端装置20使用该数据。即使电源打开/关闭，上述装置也能够 在对保存于非易失性存储器中的数据进行可靠性检查后下载该数 据。检查程序和数据的可靠性在下文中称作验证。 但是，根据常规技术，在一旦在把程序保存到非易失性存储器 中以在该装置通电/断电后激活该程序的情况下，紧接着在程序被激 活之前对其进行验证。在这种情况下，在开始激活所述程序之前， 执行诸如对已加密值进行解密之类的计算是有必要的，这造成了随 着计算需要越长的时间响应度降低越多的问题。尤其是在程序被频 繁地激活或是程序容量很大的情况下，响应度变得越来越低，因为 计算量与激活频率和容量成正比地增加。 鉴于上述问题，期望提供一种诸如具有高响应度的数字电视这 样的程序验证装置，它能够在保证程序可靠性的同时，缩短程序被 激活之前所需的时间。 发明内容 本发明的目的在于提供一种已验证程序运行方法，其能够通过 紧接着在程序被存储前执行验证以及在程序激活时不执行验证或仅 执行一部分验证，来保证可靠性并且改善响应度。 为了解决上述常规问题，根据本发明的已验证程序运行方法包 括：验证和保存步骤，验证包括在传输流中的程序，并且根据与所 述已验证程序的每一个数据文件的存储相关的信息，将所述程序保 存到广播接收机中；以及运行步骤，运行所述保存的已验证程序； 其中所述验证和保存步骤包括：第一步骤，检验两个哈希值是否一 致，所述哈希值的其中一个是根据在所述程序中包括的每一个数据 文件计算得到的，另一个哈希值保存在与所述每一个数据文件相对 应的哈希文件中；第二步骤，检验在所述程序中包括的证书文件是 否有效；第三步骤，检验解密值和哈希值是否一致，所述解密值是 通过使用在所述程序的所述证书文件中包括的叶证书的公开密钥， 来解密在所述程序中包括的签名文件的签名值而获得的，所述哈希 值是通过根据位于所述程序的顶级目录中的哈希文件计算得到的； 以及第四步骤，在满足所有以下条件的情况下：在所述第一步骤中 所述两个哈希值被检验是一致的；在所述第二步骤中所述证书文件 被检验是有效的；以及在所述第三步骤中所述解密值和哈希值被检 验是一致的，验证所述程序并根据所述与存储有关的信息来保存所 述已验证程序的每一个数据文件，以及所述运行步骤包括第五步 骤，检验在所述保存的程序中包括的所述证书文件是否有效，以及 在所述运行步骤中，再次验证所述保存的程序，并且仅在所述第五 步骤中在所述保存的程序中所包括的所述证书文件被检验为有效的 情况下，运行所述保存的程序。 因此，缩短在程序被激活前的所需时间同时保证程序可靠性变 得可能。 此外，在所述程序具有目录结构的情况下，在每一个目录中所 包括的每一个数据文件和与所述每一个数据文件相对应的所述哈希 文件都位于相同的目录中，以及为在每一个目录中所包括的每一个 数据文件运行所述第一步骤。 因此，对于包含在每个目录中的每个数据文件，检验根据数据 文件计算得出的哈希值和保存在与所述数据文件相对应的哈希文件 中的哈希值是否一致变得可能。 此外，所述第二步骤包括第六步骤，检验两个根证书是否匹 配，所述根证书的其中一个位于在所述程序内所包括的所述证书文 件中，另一个根证书安装在所述广播接收机中，以及在所述第二步 骤中，在所述两个根证书匹配的情况下所述证书文件被检验为有 效。 在这里，第二步骤还包含第七步骤，检验在所述程序内包括的 所述证书文件中的每一个证书的有效期，以及在所述第二步骤中， 在满足以下两个条件的情况下：所述两个根证书匹配；以及执行所 述验证的时间在所述证书文件中的每一个证书的有效期内，所述证 书文件被检验为有效。 因此，在根证书不匹配以及所述证书期满的情况下，防止程序 被保存变得可能。 此外，第五步骤包括第八步骤，检验两个根证书是否匹配，所 述根证书的其中一个位于在所述保存的程序中包括的所述证书文件 内，另一个根证书安装在所述广播接收机中，以及在所述第五步骤 中，在所述两个根证书匹配的情况下，在所述保存的程序内包括的 所述证书文件被检验为有效。 在这里，第五步骤还包括第九步骤，检验在所述保存的程序内 包括的所述证书文件中的每一个证书的有效期，以及在所述第五步 骤中，在满足以下两个条件的情况下：所述两个根证书匹配；以及 执行所述运行的时间位于在所述证书文件中的每一个证书的有效期 内，在所述保存的程序中包括的所述证书文件被检验为有效。 因此，在根证书不匹配以及所述证书期满的情况下，防止该程 序被运行变得可能。 注意，不仅可以将本发明实现为上述的已验证程序运行方法， 而且可以将本发明实现为包括作为其单元的、所述已验证程序运行 方法中包括的特征步骤的已验证程序运行装置，以及作为使得计算 机运行这些步骤的程序。还应该注意，可以在诸如CD-ROM这样的 记录介质上和经由诸如因特网这样的传输介质来分发该程序。 从以上描述可以明显看出，根据本发明的已验证程序运行方法 能够在保证程序可靠性的同时缩短在程序被激活前的所需时间。 在此，以参考的方式作为其整体插入在2003年12月18日提交 的日本专利申请No.2003-421616和在2003年12月19日提交的临 时美国专利申请No.60/530663的所有内容，包括说明书、附图和权 利要求书。 附图说明 根据下面结合举例说明本发明具体实施例的附图的描述，本发 明的这些以及其它目的、优点和特点将变得明显。 图1是示出了根据本发明第一实施例的有线电视系统的结构的 框图； 图2是示出了根据本发明的有线电视系统中使用将用于在首端 和多个终端装置之间通信的频带的示例图； 图3是示出了根据本发明的有线电视系统中使用将用于所述首 端和所述终端装置之间通信的频带的示例图； 图4是示出了根据本发明的有线电视系统中使用将用于所述首 端和所述终端装置之间通信的频带的示例图； 图5是示出了根据本发明的有线电视系统中的终端装置结构的 示意图； 图6是示出了根据本发明的有线电视系统中的终端装置示例外 观图的示意图； 图7是示出了根据本发明的POD 504硬件结构的示意图； 图8是示出了根据本发明的POD 504中所存储的程序结构的示 意图； 图9是示出了MPEG标准中所定义的分组结构的示意图； 图10是示出了MPEG2传输流示例的示意图； 图11是示出了在以面板形式配置输入单元513的情况下输入单 元513的示例外观图的示意图； 图12是示出了根据本发明的存储在终端装置500中的程序结构 的示意图； 图13A是示出了根据本发明的由显示装置509所显示的一个显 示屏示例的示意图，图13B是示出了根据本发明的由显示装置509 所显示的一个显示屏示例的示意图； 图14是示出了根据本发明的在辅助存储单元510中所存储的信 息示例的示意图； 图15A、15B和15C是每一个示出了根据本发明的在主存储单 元511中所存储的信息示例的示意图； 图16是示出了根据本发明的在MEPG2标准中所规定的PAT内 容的示意图； 图17是示出了根据本发明的在MEPG2标准中所规定的PMT内 容的示意图； 图18是示出了根据本发明的在DVB-MHP标准中所规定的AIT 内容的示意图； 图19是示出了根据本发明的将以DSMCC格式传输的文件系统 的示意图； 图20是示出了根据本发明的XAIT内容的示意图； 图21是示出了根据本发明的在辅助存储单元510中所存储的信 息示例的示意图； 图22A、22B和22C是分别示出了根据本发明的包含文件或目 录的哈希值的文件示例的示意图； 图23是示出了根据本发明的证书链结构的示意图； 图24是示出了根据本发明的X.509证书结构的示意图； 图25是示出了根据本发明的签名文件结构的示意图； 图26是示出了根据本发明的安全模块组件的示意图； 图27是示出了根据本发明的在验证文件系统时所执行的操作的 流程图； 图28是根据本发明的在接收到程序预激活通知时不执行验证的 情况下的流程图； 图29是示出了根据本发明的在对文件系统执行篡改检查时的操 作的流程图； 图30是示出了根据本发明的在通过使用签名文件来执行篡改检 查时的操作的流程图； 图31是示出了根据本发明的在检查叶证书和中间证书之间的链 关系时所执行的操作的流程图； 图32是示出了根据本发明的在检查中间证书和根证书之间的链 关系时所执行的操作的流程图； 图33是示出了根据本发明的在检查根证书中的签名时所执行的 操作的流程图； 图34是示出了根据本发明的用于指定将被存储的文件的文件示 例的示意图； 图35是示出了根据本发明的在执行文件系统的验证时所执行的 操作的流程图； 图36是示出了根据本发明的当接收到预激活通知时在检查 X.509证书的有效性的时候所执行的操作的流程图； 图37是示出了根据本发明的将从下载模块中接收到的编码文件 简化结构的示意图； 图38A、38B和38C是每一个示出了根据本发明的由终端装置 拥有的证书被替换的示意图； 图39是示出了根据本发明的当执行证书替换时所执行的操作的 流程图； 图40是示出了根据本发明的当接收到预激活通知时在比较根证 书的时候所执行的操作的流程图； 图41是示出了根据本发明的CRL结构的示意图； 图42是示出了根据本发明的CRL中已被撤销证书列表的示意 图； 图43是示出了根据本发明的包含CRL的文件系统示例的示意 图； 图44是示出了根据本发明的当基于哈希值和签名值检查CRL 的有效性时所执行的操作的流程图； 图45是示出了根据本发明的当基于证书间的关系和根证书间的 比较结果来检查CRL的有效性时所执行的操作的流程图； 图46是示出了根据本发明的包含有文件或目录的哈希值的文件 示例的示意图； 图47是示出了根据本发明的用于在程序保存时存在CRL的情 况下执行验证的操作的流程图； 图48是示出了用于在激活程序时存在CRL的情况下执行验证 的操作的流程图； 图49是示出了根据本发明的已撤销证书数据库的示意图； 图50是示出了根据本发明的包含有用于指定将被存储的文件的 文件的文件系统示例的示意图； 图51是示出了根据本发明的用于指定将被存储的文件的文件示 例的示意图。 最优实施例 下面结合附图对本发明的实施例进行描述。 (第一实施例) 下面将参照附图来说明根据本发明的有线电视系统的优选实施 例。图1是示出了组成所述有线系统的装置之间的关系的方框图， 这些装置是首端101和三个终端装置：终端装置A111、终端装置 B112以及终端装置C113。在本实施例中，虽然三个终端装置连接 到一个首端，但是如果任意数量的终端装置连接到该首端则实现本 发明也是可以的。 首端101向多个终端装置传送诸如视频、音频和数据这样的广 播信号，并且接收从这些终端装置传送的数据。为了实现这个功 能，对频带进行划分以用于在首端101和终端A111、终端B112以 及终端C113之间的数据传送。图2是示出了已划分频带示例的表。 粗略地说有两种类型的频带：带外(缩写为OOB)和带内。频带 5～130MHz被分配给OOB，主要用于首端101和终端装置A111、 终端装置B112以及终端装置C113之间进行数据交换。频带 130MHz～864MHz被分配给带内，主要用于包含视频和音频的广播 频道。OOB使用QPSK，而带内使用QAM64作为调制技术。这里 省略了调制技术的详细说明，因为它们是与本发明几乎不相关的公 知技术。图3示出了如何使用OOB频带的更具体示例。频带 70MHz～74MHz用于从首端101传送数据。在这种情况下，所有终 端装置A111、终端装置B112以及终端装置C113从首端101接收相 同的数据。同时，频带10.0MHz～10.1MHz用于从终端装置A111 向首端101传送数据，频带10.1MHz～10.2MHz用于从终端装置 B112向首端101传送数据，频带10.2MHz～10.3MHz用于从终端装 置C113向首端101传送数据。因此，从终端装置A111、终端装置 B112和终端装置C113向首端101传送对于每个终端装置唯一的数 据是可能的。图4示出了使用带内频带的示例。频带150～156MHz 和156～162MHz被分别分配给电视频道1和电视频道2，且后面的 频率以6MHz的间隔分配给电视频道。310MHz和后面的频率以 1MHz的间隔分配给无线电频道。上述频道的每一个可用于模拟广 播或数字广播。在数字广播的情况下，以遵循MPEG2规范的分组 格式来传送数据，在这种情况下，除了音频和视频数据外，还能够 传送打算用于各种数据广播系统的数据。 首端101配置有QPSK调制单元、QAM调制单元等以向各个频 率范围传送合适的广播信号。此外，首端101配置有QPSK解调单 元用于从终端装置接收数据。而且，还假定首端101配置有与上述 调制单元和解调单元相关的各种设备。但是，这里省略它们的详细 说明，因为本发明主要涉及终端装置。 终端装置A111、终端装置B112以及终端装置C113接收并再 现从首端101传送的广播信号。此外，终端装置A111、终端装置 B112以及终端装置C113向首端101传送对于每个终端装置唯一的 数据。在本实施例中，这三个终端装置可以有相同的结构。 图5是示出了每个终端装置的硬件结构的框图。500是一个终端 装置，其由QAM解调单元501、QPSK解调单元502、QPSK调制 单元503、TS解码器505、音频解码器506、扬声器507、视频解码 器508、显示器509、辅助存储单元510、主存储单元511、ROM 512、输入单元513和CPU 514组成。此外，POD 504可与终端装 置500相连或分离。 图6示出了一种薄形电视，其是终端装置500的示例外观图。 虽然该终端装置能够以各种结构来出现，但在本实施例中，将基于 OpenCable(TM)和OCAP而配置的终端装置描述为一个示例。 601是薄形电视的铁盒，其中包含除POD 504外的终端装置500 的所有组件。 602是显示器，其与图5中的显示器509相对应。 603是面板单元，其由多个按钮组成并与图5中的输入单元513 相对应。 604是信号输入终端，电缆线与其连接用于向首端101传送信号 和从首端101接收信号。该信号输入终端连接到图5中的QAM解调 单元501、QPSK解调单元502以及QPSK调制单元503。 605是与图5中的POD 504相对应的POD卡。如在图6中的 POD卡605的情况下，POD 504独立于终端装置500而实现，并且 能够与终端装置500连接/分离。稍后将给出POD 504的详细说明。 606是插入POD卡605的插槽。 参照图5，根据包含由CPU 514指定的频率的调谐信息，QAM 解调单元501对在首端101中已被QAM调制并从首端101传送的信 号进行解调，并将结果传递给POD 504。 根据包含由CPU 514指定的频率的调谐信息，QPSK解调单元 502对在首端101中已被QPSK调制并从首端101传送的信号进行解 调，并将结果传递给POD 504。 根据包含由CPU 514指定的频率的解调信息，QPSK调制单元 503对从POD 504传递来的信号进行QPSK解调，并将结果传送给 首端101。 如图6所示，POD 504与终端装置500的主体相分离。终端500 的主体与POD 504之间的连接接口的定义已在OpenCable(TM) CableCARD(TM)Interface Specification(OC-SP-CC-IF-I15- 031121)中以及此规范所参考的规范中给出。注意此规范中的 CableCARD指的是POD。这里省略了详细描述，并仅对与本发明相 关的组件加以说明。 图7是示出POD 504内部结构的框图。POD 504由第一解扰器 单元701、第二解扰器单元702、扰码器单元703、主存储单元 704、辅助存储单元705和CPU 706。 根据来自CPU 706的指令，第一解扰器单元701从终端装置 500的QAM解调单元501中接收已加扰的信号，并对该信号进行解 扰。然后，第一解扰器单元701向终端装置500的TS解码器505传 送已解扰的信号。根据需要，由CPU706提供解扰器所需的诸如密 钥这样的信息。更特别地，首端101广播若干个付费频道，且当用 户购买了收看这些付费频道的权限时，第一解扰器单元701从CPU 706接收诸如密钥这样的所需信息并执行解扰。因此，用户能够收 看这些付费频道。当诸如密钥这样的所需信息不被提供时，第一解 扰器单元701没有执行解扰而直接将接收的信号传递给TS解码单元 505。 根据来自CPU 706的指令，第二解扰器单元702从终端装置 500的QPSK解调单元502中接收已加扰的信号，并且对该信号进行 解扰。然后，第二解扰器单元702将该已解扰的数据传递给CPU 706。 根据来自CPU 706的指令，扰码器单元703对从CPU 706接收 到的数据进行加扰，并且将结果发送到终端装置500的QPSK调制 单元503中。 其具体组件是诸如RAM这样的主存储器的主存储单元704，打 算用于当CPU 706执行处理时临时存储数据。 其具体组件是诸如快闪ROM这样的辅助存储器的辅助存储单 元705，用于存储CPU 706所运行的程序以及用于存储即使关闭电 源也从不被删除的数据。 CPU 706运行保存在辅助存储单元705中的程序。该程序由若 干个子程序组成。图8示出了在辅助存储单元705中保存的程序示 例。在图8中，程序800由若干子程序组成，包括主程序801、初始 化子程序802、网络子程序803、再现子程序804和PPV子程序 805。 在这里，PPV是每视付费的缩写，指的是允许用户在计费的基 础上观看诸如电影这样的某种节目的服务。当用户输入他/她的身份 识别码时，用户购买观看该节目的权限的事实被通知给首端101， 并且解扰该节目。因此，用户能够观看该节目。观看此节目需要用 户在日后对该购买付款。 主程序801是当开启电源时由CPU 706首先激活的子程序，其 控制其它子程序。 初始化子程序802，在开启电源时由主程序801激活，其实施 与终端装置500的信息交换等以执行初始化处理。该初始化处理已 在OpenCable(TM)CableCARD(TM)Interface Specification(OC- SP-CC-IF-I15-031121)中以及该规范所参考的规范中详细定义。此 外，初始化子程序802也执行在这些规范中没有定义的初始化处 理。这里，引入该初始化处理的一部分。当开启电源时，初始化子 程序802经由终端装置500的CPU 514向QPSK解调单元502通知 存储在辅助存储单元705中的第一频率。QPSK解调单元502使用提 供的第一频率进行调谐，并将得到的信号传送给第二解扰器单元 702。此外，初始化子程序802向第二解扰器单元702提供诸如存储 在辅助存储单元705中的第一密钥这样的解扰信息。因此，第二解 扰器单元702执行解扰并将结果传递给运行子程序802的CPU 706。因此，初始化子程序能够接收该信息。在本实施例中，初始化 子程序802经由网络子程序803接收信息。稍后将给出关于这的详 细描述。 此外，初始化子程序802经由终端装置500的CPU 514向 QPSK调制单元503通知存储在辅助存储单元705中的第二频率。初 始化子程序802向扰码器单元703提供存储在辅助存储单元705中 的加扰信息。当初始化子程序802经由网络子程序803向扰码器单 元703提供被发送的所需信息时，扰码器单元703使用所提供的加 扰信息对数据进行加扰，并将该已加扰的数据提供给QPSK调制单 元503。QPSK调制单元503对接收到的已加扰信息进行调制，并将 该已调制信息发送到首端101。 因此，初始化子程序802经由终端装置500、第二解扰器单元 702、扰码器单元703和网络子程序803实施与首端101的双向通信 变成可能。 由诸如主程序801和初始化子程序802这样的若干个子程序所 使用的网络子程序803，是用于实施与首端101的双向通信的子程 序。更为特别地，网络子程序803表现为似乎使用网络子程序803 的其它子程序正在实施与首端101的遵循TCP/IP的双向通信。这里 省略了TCP/IP的详细说明，因为它是指定当在多个终端之间交换信 息时所使用的协议的公知技术。当开启电源的时刻被初始化子程序 802激活时，网络子程序803经由终端装置500向首端101通知一个 MAC地址(媒体接入控制的缩写)以请求获得IP地址，所述MAC 地址是标识POD 504的标识符并且预先保存在辅助存储单元705 中。首端101经由终端装置500将所述IP地址通知给POD 504，网 络子程序803将该IP地址存储到主存储单元704中。此后，首端 101和POD 504使用该IP地址作为POD 504的标识符来相互通信。 再现子程序804向第一解扰器单元701提供存储在辅助存储单 元705中的诸如第二密钥这样的解扰信息和由终端装置500提供的 诸如第三密钥这样的解扰信息，以允许执行解扰。此外，再现子程 序804经由网络子程序803接收信息，该信息表明在第一解扰器单 元701中输入的信号是一个PPV频道。根据该信号是PPV频道的通 知，再现子程序804激活PPV子程序805。 当被激活以后，PPV子程序805在终端装置500上显示提示用 户购买该节目的消息，然后接收来自用户的输入。更特别地，当想 要在屏幕上显示的信息被发送给终端装置500的CPU 514时，在终 端装置500的CPU 514上运行的程序将该消息显示在终端装置500 的显示器509上。然后，当用户经由终端装置500的输入单元513 输入身份识别码时，终端装置500的CPU 514接收它并将它发送给 在POD 504的CPU 706上运行的PPV子程序805。PPV子程序805 经由网络子程序803将所接收的个人身份识别码发送给首端101。 当该个人身份识别码有效时，首端101经由网络子程序803向PPV 子程序805通知诸如第四密钥这样的解扰所需的解扰信息。PPV子 程序805向第一解扰器单元701提供所接收的诸如第四密钥这样的 解扰信息，然后第一解扰器单元701对输入信号进行解扰。 参照图5，TS解码器505对从POD 504接收的信息执行过滤， 并将必要的数据传递给音频解码器506、视频解码器508和CPU 514。在这里，从POD 504发送的信号是MPEG2传输流。在MPEG 规范ISO/IEC138181-1中已给出了关于MPEG2传输流的详细描述， 因此本实施例不对它进行详细说明。MPEG2传输流由多个长度固定 的分组组成，并且每个分组都分配一个分组ID。图9是示出了分组 结构的示意图。900是一个分组，其包括固定长度的188字节。头四 个字节是头部901，存储用于标识该分组的信息，其余的184字节 是载荷902，存储想要承载的信息。903示出了头部901的分解。分 组ID包含于从1st到12th～24th比特的13个比特中。图10是举例说 明将要传送的多个分组串的示意图。分组1001在它的头部中包含有 分组ID“1”，并在它的载荷中包含有视频A的第一信息。分组 1002在它的头部中包含有分组ID“2”，并在它的载荷中包含有音 频A的第一信息。分组1003在它的头部中包含有分组ID“3”，并 在它的载荷中包含有音频B的第一信息。 分组1004在它的头部中包含有分组ID“1”，并在它的载荷中 包含有视频A的第二信息，该第二信息是分组1001的后续信息。类 似地，分组1005、1026和1027承载了其它分组的后续数据。通过 以上述方式来连接具有相同分组ID的分组的载荷内容，以连续的次 序来再现视频和音频是可能的。 参照图10，当CPU 514向TS解码器505指示分组ID“1”和 作为输出目标的“视频解码器508”时，TS解码器505从POD 504 接收到的MPEG2传输流中提取出分组ID为“1”的分组，并将它 们传递给视频解码器508。因此，在图10中只有视频数据会被传递 给视频解码器508。同时，当CPU 514向TS解码器505指示分组 ID“2”和作为输出目标的“音频解码器506”时，TS解码器505从 POD 504接收到的MPEG2传输流中提取出分组ID为“2”的分组， 并将它们传递给音频解码器506。在图10中，只有音频数据会被传 递给音频解码器508。 该根据分组ID仅提取需要的分组的处理与将由TS解码器505 执行的过滤相对应。TS解码器505能够根据来自CPU 514的指令同 时执行多于一个过滤处理。 参照图5，音频解码器506将嵌入在由TS解码器505提供的 MPEG2传输流中的分组内的音频数据连接起来，对该已连接的数据 执行数模转换，并将结果输出到扬声器507。 扬声器507将音频解码器506所提供的信号作为音频输出。 视频解码器508将嵌入在由TS解码器505提供的MPEG2传输 流中的分组内的视频数据连接起来，对该已连接的数据执行数模转 换，并将结果输出到显示器509中。 其具体组件为CRT或者液晶显示屏等的显示器509输出由视频 解码器508所提供的视频信号，并且显示由CPU 514指定的信息 等。 其具体组件为快闪存储器、硬盘等的辅助存储单元510，保存 和删除由CPU 514指定的数据和程序。所保存的数据和程序由CPU 514提出。即使当终端装置500被关闭电源时，所保存的数据和程序 仍然保存在存储器中。 其具体组件为RAM等的主存储器511，临时保存由CPU 514指 定的数据和程序，并删除它们。所保存的数据和程序由CPU 514提 出。当终端装置500被关闭电源时，所保存的数据和程序被删除。 ROM 512是只读存储设备，其具体组件为ROM、CD-ROM和 DVD等。ROM 512保存将由CPU 514运行的程序。 其具体组件为面板或者远程控制器的输入单元513，接收来自 用户的输入。图11示出了在以面板形式配置输入单元513的情况下 输入单元513的示例。1100是面板，其与图6中示出的面板单元 603相对应，该面板1100由七个按钮组成：向上光标按钮1101、向 下光标按钮1102、向左光标按钮1103、向右光标按钮1104、OK按 钮1105、取消按钮1106和EPG按钮1107。当用户按下一个按钮 时，该被按下的按钮的标识符就会通知给CPU 514。 CPU 514运行保存在ROM 512中的程序。根据来自该程序的将 被运行的指令，CPU 514控制QAM解调单元501、QPSK解调单元 502、QPSK调制单元503、POD 504、TS解码器505、显示器509、 辅助存储单元510、主存储单元511以及ROM 512。 图12是示出了保存在ROM 512中并由CPU 514运行的程序的 示例结构的示意图。 程序1200由多个个子程序组成。更为具体地，程序1200由OS 1201、EPG 1202、JavaVM 1203、业务管理器1204和Java库1205 组成。 OS 1201是当终端装置500被开启电时将由CPU 514激活的子 程序。OS 1201是操作系统的缩写，操作系统的示例是Linux等。 OS 1201是由用于与另一程序并行地运行一个子程序的内核1201a和 库1201b所组成的公知技术的通用名称，因此省略它的详细说明。 在本实施例中，OS 1201的内核1201a运行EPG 1202和JavaVM 1203作为子程序。同时，库1201b向这些子程序提供控制终端装置 500的组件所需的多个功能。 在这里，引入调谐作为这类功能的一个例子。对于调谐功能， 从另一子程序中接收包含频率的调谐信息且随后将其传递到QAM 解调单元501。因此，QAM解调单元501基于所提供的调谐信息来 执行解调并将该已解调的数据传递给POD 504是可能的。结果，其 余子程序能够经由库1201b来控制该QAM解调单元。 EPG 1202由用于向用户显示节目列表以及接收来自用户的输入 的节目显示单元1202a和用于选择频道的再现单元1102b组成。这 里，EPG是电子节目向导的缩写。当终端装置500被通电时EPG 1202被激活。在该已激活的EPG 1202中，节目显示单元1202a等候 经由终端装置500的输入单元513来自用户的输入。这里，在输入 单元513采用图11中举例说明的面板形式的情况下，当用户按下输 入单元513上的EPG按钮1107时，CPU 514被告知该EPG按钮的 标识符。作为运行在CPU 514上的子程序的EPG 1202的节目显示 单元1202a，接收这个标识符，并在显示器509上显示节目信息。图 13A和13B示出了在显示器509上显示的节目表的示例。参见图 13A，以表格的形式在显示器509上显示节目信息。列1301描述了 时间信息。列1302描述了频道名称“频道1”和在与列1301中所描 述的各个时间相对应的时间段期间将要广播的节目。示出了在“频 道1”上从9:00到10:30广播节目“新闻9”，以及从10:30到 12:00广播“电影AAA”。与列1302的情形一样，列1303描述了 频道名称“频道2”和在与列1301中所描述的时间相对应的时间段 期间将要广播的节目。从9:00到11:00广播节目“电影BBB”，从 11:00到12:00广播“新闻11”。1330是一个光标。当按下面板 1100上的向左光标1103或向右光标1104时，光标1330将移动。当 在图13A中举例说明的状态中按下向右光标1104时，光标1330如 图13B中所示的向右移动。同时，当在图13B中举例说明的状态中 按下向左光标1103时，光标1330如图13A所示的向左移动。 当在图13A中所示的状态中按下面板1100上的OK按钮1105 时，节目显示单元1202a向再现单元1102b通知“频道1”的标识 符。同时当在图13B中所示的状态中按下面板1100上的OK按钮 1105时，节目显示单元1202a向再现单元1102b通知“频道2”的 标识符。 此外，节目显示单元1202a周期性地经由POD504将来自首端 101的将要显示的节目信息保存到主存储单元511中。通常，需要花 费时间从首端中获取节目信息。然而，通过在按下输入单元513的 EPG按钮1107时显示预先保存在主存储单元511中的节目信息来快 速显示节目表变得可能。 再现单元1102b使用接收的频道标识符来再现频道。频道标识 符和频道之间的关系由辅助存储单元510预先保存为频道信息。图 14示出了保存在辅助存储单元510中的频道信息的一个示例。以列 表的形式保存频道信息。列1401描述频道的标识符。列1402描述 频道名称。列1403描述调谐信息。在这里，调谐信息由提供给 QAM解调单元501的诸如频率、传送速率和编码比率这样的值来表 示。列1404描述节目编号。节目编号是用于标识由MPEG2标准所 定义的PMTs的号码。关于PMT的描述将在稍后给出。行1411～ 1414的每一个指示每个频道的标识符、频道名称和调谐信息的集 合。行1411描述了包括以“1”作为标识符、“频道1”作为频道 名称、频率“312MHz”作为调谐信息以及“101”作为节目编号的 一个集合。再现单元1102b将接收到的频道的标识符直接传递给业 务管理器以再现该频道。 此外，当再现正在发生的同时用户按下面板1100上的向上光标 1101和向下光标1102时，再现单元1102b经由CPU 514从输入单 元513接收关于用户的该按压的通知，并将正被再现的频道切换到 另一频道。首先，再现单元1102b在主存储单元511中保存当前被 再现的频道的标识符。图15A、B和C示出了保存在主存储单元 511中的频道的标识符的示例。图15A示出标识符“3”被存储，并 且参照图14示出了正在再现频道名称为“TV3”的频道。当用户在 图15A中所举例说明的状态中按下向上光标1101时，再现单元 1102b查阅图14中所示的频道信息，并将频道名称为“频道2”的 频道的标识符“2”传递给服务管理器，以最新再现频道名称为 “频道2”的频道，该频道是表中的前一个频道。同时，再现单元 1102b将主存储单元511中保存的标识改写为频道标识符“2”。图 15B示出了该已改写的频道标识符。同时，当用户在图15A中所举 例说明的状态中按下向下光标1102时，再现单元1102b查阅图14 中所示的频道信息，并将频道名称为“TV Japan”的频道的标识符 “4”传递给服务管理器，以最新再现频道名称为“TV Japan”的频 道，该频道是表中的下一个频道。同时，再现单元1102b将主存储 单元511中的标识改写为频道标识符“4”。图15C示出了该已改写 的频道标识符。 JavaVM 1203是一种顺序地分析并运行以Java(TM)语言编写的 程序的Java虚拟机。以Java语言编写的程序被编译成不依赖于硬件 的被称为字节码的中间代码。Java虚拟机是运行该字节码的解释 器。某些Java虚拟机将字节码翻译成CPU 514能够解释的可运行形 式，并将结果传递给运行它的CPU 514。当内核1201a指定将被运 行的Java程序时，JavaVM 1203被激活。在本实施例中，内核 1201a将业务管理器1204指定为将被运行的Java程序。包括“Java Language Specification”(ISBN 0-201-63451-1)在内的许多书中都给出 了Java语言的详细解释。因此，这里省略它的详细描述。同时，包 括“Java Virtual Machine Specification”(ISBN 0-201-63451-X)在内的 许多书中都给出了关于Java VM本身的操作的详细解释。因此这里 省略关于它的详细描述。 作为以Java语言编写的Java程序的业务管理器1204，由 JavaVM 1203顺序地运行。通过JNI(Java本地接口)业务管理器1204 调用另一不是以Java语言编写的子程序或被其调用是可能的。包括 “Java Native Interface”(ISBN 0-201-63451-X)在内的许多书中都给 出了关于JNI的解释。因此这里省略关于它的详细描述。 业务管理器1204通过JNI从再现单元1102b中接收频道的标识 符。 首先，业务管理器1204将频道的标识符传递给Java库1205中 的调谐器1205c，以请求调谐。调谐器1205c查阅保存在辅助存储单 元510中的频道信息以获取调谐信息。假设业务管理器1204把频道 的标识符“2”传递给调谐器1205c，那么调谐器1205c就查阅图14 中所示的列1412，并且获取与该频道相对应的调谐信息 “156MHz”。调谐器1205c经由OS 1201的库1201b将该调谐信息 传递给QAM解调单元501。QAM解调单元501根据给它的调谐信 息对从首端101发送来的信号进行解调，并将结果信号传递给POD 504。 接下来，业务管理器1204请求Java库1205内部的CA 1205b 执行解扰。CA 1205d通过OS 1201中的库1201b向POD 504提供解 扰所需的信息。基于该提供的信息，POD 504对QAM解调单元501 所提供的信号进行解扰，并将结果信号传递给TS解码器505。 接下来，业务管理器1204向Java库1205内部的JMF 1205a提 供频道的标识符，以请求再现视频和音频。 首先，JMF 1205a从PAT和PMT中获取用于指定将要再现的视 频和音频的分组ID。PAT和PMT是由MPEG-2标准所定义的表 格，其示出了包含于MPEG2传输流中的节目队列。PAT和PMT与 音频和视频一起被承载于MPEG2传输流中所包含的分组的载荷 中。请参考详细描述PAT和PMT的规范。这里，仅给出了PAT和 PMT的概述。作为节目关联表的缩写的PAT，承载于分组ID为 “0”的分组中。为了获取PAT，JMF 1205a通过OS 1201的库 1201b向TS解码器505指示分组ID“0”和CPU 514。然后，TS解 码器505基于分组ID“0”执行过滤，并将结果传递给CPU 514。 因此，JMF 1205a能够收集PAT分组。图16举例说明了示意性地示 出已收集的PAT信息的一个示例的表格。列1601描述了节目编 号。列1602描述了分组ID。列1602中所示的分组ID用来获取 PAT。行1611～1613的每一个是一对频道的节目编号和与其相应的 分组ID。这里，定义了三个频道。行1611定义了一对节目编号 “101”和分组ID“501”。假设提供给JMF 1205a的频道标识符是 “2”，则JMF 1205a就参阅图14中的列1412以获取与该频道标识 符相应的节目编号“102”，然后查阅图16所示的PAT中的行1612 以获取与节目编号“102”相应的分组ID“502”。作为节目映射表 的缩写的PMT，承载于具有在PAT中所指定的分组ID的分组中。 为了获取PMT，JMF 1205a通过OS 1201的库1201b向TS解码器 505指示分组ID和CPU 514。这里，所指定的分组ID为“502”。 然后，TS解码器505基于分组ID“502”执行过滤，并将结果传递 给CPU 514。因此，JMF 1205a能够收集PMT分组。图17举例说 明了示意性地示出已收集的PMT信息的表格。列1701描述流类 型。列1702描述分组ID。在各个流类型中所指定的信息承载于具 有在列1702中所指定的分组ID的分组的载荷中。列1703描述附加 信息，行1711～1714的每一个是一对要传送的被称为基本流的信息 的分组ID和类型。作为一对流类型“音频”和分组ID“5011”的 行1711，指示该音频数据保存在分组ID为“5011”的分组的载荷 中。JMF 1205a从PMT中获取将要再现的视频和音频的分组ID。参 见图17，JMF 1205a从行1711中获取音频分组ID“5011”，以及 从行1712中获取视频分组ID“5012”。 然后，JMF 1205a经由OS 1201的库1201b向TS解码器505提 供多对获取的音频分组ID和作为输出目的地的音频解码器506，以 及视频分组ID和作为输出目的地的视频解码器508。TS解码器505 基于该提供的分组ID和输出目的地执行过滤。这里，分组ID为 “5011”的分组被传递给音频解码器506，分组ID为“5012”的分 组被传递给视频解码器508。音频解码器506对所提供的分组执行 数模转换以经由扬声器507再现音频。视频解码器508对所提供的 分组执行数模转换以在显示器509上显示视频。 最后，业务管理器1204向Java库1205中的AM 1205b提供频 道标识符，以请求数据广播再现。这里，数据广播再现指的是提取 包含于MPEG2传输流中的Java程序，并使JavaVM 1203运行它。 作为将Java程序嵌入到MPEG2传输流中的技术，使用称为 DSMCC的方法，其在MPEG规范ISO/IEC138181-6中描述了。这 里省略了DSMCC的详细说明。DSMCC规范定义了一种方法，用于 在MPEG2传输流中以分组的形式对计算机所使用的包含目录和文 件的文件系统进行编码。关于将要运行的Java程序的信息以AIT的 格式承载于MPEG2传输流中的分组中。AIT是应用信息表的缩写， 其定义在DVB-MVP标准(正式被称为ETSI TS 101 812 DVB-MHP specification V1.0.2)的第十章中给出。 首先，为了获取AIT，与JMF 1205a的情形一样，AM 1205b获 取PAT和PMT，以得到保存AIT的分组的分组ID。假设“2”是所 提供的频道标识符，且在图16中示出的PAT以及图17中示出的 PMT将要被传送，那么AM 1205b根据JMF 1205a所遵循的相同步 骤来获取图17中示出的PMT。接下来，AM 1205b从该PMT中提 取其流类型为“数据”且具有作为附加信息的“AIT”的基本流的 分组ID。如图17所示，行1713中的基本流对应该基本流，因此， AM 1205b从它那里获取分组ID“5013”。 AM 1205b将AIT的分组ID和作为输出目的地的CPU 514经由 OS 1201的库1201b提供给TS解码器505。然后，TS解码器505基 于该提供的分组ID执行过滤，并将结果传递给CPU 514。因此， AM 1205b能够收集AIT的分组。图18举例说明了示意性地示出已 收集的AIT信息的表格。列1801描述Java程序的标识。根据MHP 规范，这些标识定义为应用ID，以标识Java程序是否应该被终端装 置500的安全管理器1205f验证。当标识符值处于0x0到0x3fff的范 围内时，不需要验证，而当标识值处于0x4000到0x7ffff的范围内 时，需要验证。其标识符值落入前者范围内的Java程序被称为“未 签名程序”，而其标识符值落入后者范围内的Java程序被称为“已 签名程序”。列1802描述了用于控制Java程序的控制信息。该控制 信息包括“autostart”、“present”和“kill”。“autostart”指的是 终端装置500马上自动运行程序。“present”指的是该程序不被自 动运行。“kill”指的是该程序将被终止。列1803描述了用于提取 包含有DSMCC格式的Java程序的分组ID的DSMCC标识符。列 1804描述了Java程序的程序名字。行1811和1812的每一个是关于 Java程序的信息集合。行1811中所定义的Java程序是标识符 “301”、控制信息“autostart”、DSMCC标识符“1”以及程序名 称“a/TopXlet”的集合。行1812所定义的Java程序是标识符 “302”、控制信息“present”、DSMCC标识符“1”以及程序名 称“b/GameXlet”的集合。这里，这两个Java程序具有相同的 DSMCC标识符。这表示两个Java程序包括在已经按照相同的 DSMCC方法进行了编码的文件系统中。这里，仅为各个Java程序 指定了四种信息，但实际上可以指定更多信息。详情请参见DVB- MHP规范。 AM 1205b从AIT中找出“autostart”Java程序，并提取相应的 DSMCC标识符和Java程序名称。参见图18，AM 1205b提取行 1818中的Java程序，并且获取DSMCC标识符“1”以及Java程序 名称“a/TopXlet”。 接下来，AM 1205b使用从AIT获取的DSMCC标识符，从 PMT中获取保存DSMCC格式的Java程序的分组的分组ID。更具 体而言，AM 1205b从PMT中获取流类型为“数据”且附加信息中 的DSMCC标识符相匹配的基本流中所包含的分组ID。 这里，假定该DSMCC标识符为“1”，且PMT为图17中所 示，那么行1714中的基本流满足上述条件。因此，分组ID “5014”将被提取。 AM 1205b将嵌入有DSMCC格式的数据的分组的分组ID和作 为输出目的地的CPU 514，经由OS 1201的库1201b指示给TS解码 器505。这里，提供分组ID“5014”。然后，TS解码器504基于所 提供的分组ID执行过滤，并将结果传递给CPU 514。因此，AM 1205b能够收集所需的分组。AM 1205b根据DSMCC方法从收集到 的分组重建文件系统，并将该重建的文件系统保存到主存储单元 511中。在下文中将用于从MPEG2传输的分组中提取诸如文件系统 这样的数据并将该提取的数据存储到诸如主存储单元511这样的存 储单元中的处理称为下载。 图19示出了已下载的文件系统的示例。在该图中，圆圈代表目 录，方框代表文件，其中1901是根目录、1902是目录“a”、1903 是目录“b”、1904是文件“TopXlet.class”，以及1905是文件 “GameXlet.class”。 接下来，AM 1205b将已下载到主存储单元511的文件系统中的 将要运行的Java程序传递给JavaVM 1203。在这里，假定将要运行 的Java程序名称为“a/TopXlet”，那么将“.class”附加到上述Java 程序名称得到的文件“a/TopXlet.class”是将要运行的文件。“/”是 目录和文件名称之间的分割符，并且如图19所示，文件1904是将 要运行的Java程序。接下来，AM 1205b将文件1904传递给 JavaVM 1203，由于描述该Java程序的标识符的列1801表示未签名 程序，因此意味着不需要请求安全管理器1205f来对该Java程序执 行验证。 JavaVM 1203运行该接收的Java程序。 在接收到另一频道的标识符时，业务管理器1204通过Java库 1205中所包括的每个库来终止视频和音频的再现，以及终止正通过 在该相同的Java库1205中所包括的每个库而实现的Java程序的运 行，然后基于该最新接收的频道标识符来执行视频和音频的再现以 及Java程序的运行。 Java库1205是保存在ROM 512中的多个Java库的集合。在本 实施例中，Java库1205包括JMF 1205a、AM 1205b、调谐器 1205c、CA 1205d、POD库1205e、安全管理器1205f和下载的模块 1206等。 业务管理器1204和下载的模块1206经由Java库1205中所包含 的POD库1205e与首端101进行双向通信。通过POD库1205e使用 QPSK解调单元502和QPSK调制单元503经由OS 1201的库1201b 和POD 504来实现这个双向通信。 下载的模块1206能够通过这个通信从首端101中接收代码数 据。代码数据指的是包含X.509证书和/或终端装置500的固件的二 进制数据。图37是示出了代码数据的示意图，该代码数据仅描述了 与本发明相关的部分。当接收到代码数据37时，如果包含有根证书 371，则下载的模块1206提取该证书，并将其传递给安全管理器 1205f。372表示诸如固件这样的其它数据。 AM 1205b从首端101接收与终端装置500应该保存在辅助存储 单元510中的Java程序有关的信息。该信息被称作XAIT信息。该 XAIT信息以任意形式在首端101和POD 504之间传送。只要包含 有作为XAIT的所需信息，那么无论哪种传输格式，都可实现本发 明。 图20举例说明了示意性地示出从首端101获取的XAIT信息的 示例的表格。列2001描述Java程序的标识符。列2002描述用于控 制该Java程序的控制信息。该控制信息包括“autostart”和 “present”。“autostart”表示当终端装置500被通电时自动运行程 序，而“present”表示不自动运行程序。列2003描述用于提取包含 有DSMCC格式的Java程序的分组ID的DSMCC标识符。列2004 描述了Java程序的程序名称。列2005描述了Java程序的优先级。 行2011和2012的每一个是关于各个Java程序的信息集合。在行 2011中所定义的Java程序是标识符“0x7001”、控制信息 “autostart”、DSMCC标识符“1”以及程序名称“a/PPV1Xlet”的 集合。从它的Java程序应用ID可以看出，这个Java程序是一个已 签名程序。在这里，仅为各个Java程序指定了五种信息，但是即使 定义了更多种信息，也能实现本发明。 当接收到XAIT信息时，根据与用于从AIT信息中下载Java程 序的步骤相同的步骤，AM 1205b将来自MPEG2传输流的文件系统 保存到主存储单元511中。在此之后，紧接着在AM 1205b将文件 系统保存到辅助存储单元510之前，它向安全管理器105f发出一个 预保存通知。此时，由根据本发明的安全管理器1205f发起验证操 作，稍后描述其细节。一旦从安全管理器1205f获知激活已被启 动，AM 1205b将文件系统保存到辅助存储单元510中。接下来， AM 1205b把XAIT信息和已下载文件系统的存储位置进行关联的结 果保存到辅助存储单元510中。图21示出了相互关联地保存在辅助 存储单元510中的XAIT信息和已下载文件系统的示例。这里，将 OSAP规范中所定义的文件作为示例来描述。图21中与图20中的元 件相同的元件相互是一样的，因此这里省略这些元件的说明。列 2101保存已下载文件系统的存储位置。在图21中，该存储位置由箭 头来表示。2110是已下载文件系统，其中包含顶级目录2111、目录 “a”2112、目录“b”2113、文件“PPV1Xlet.calss”2114、文件 “PPV2Xlet.class”2115、文件“ocap.hashfile”2116～2118、文件 “ocap.certificate.1”2119以及文件“ocap.signaturefile.1”2120。 文件2116～2118是包含文件名称或目录名称以及相应哈希值的 哈希文件。图22A、22B和22C是示出“ocap.hashfiles”的细节的 示意图。图22A中的221示出了“ocap.hashfile”2116，图22B中的 222示出了“ocap.hashfile”2117，以及图22C中的223示出了 “ocap.hashfile”2118。存在于“/”目录2111中的“ocap.hashfile” 221在列2211中包括存在于相同目录2111中的 “ocap.certificate.1”文件2119、“ocap.signaturefile.1”文件2120、 “a”目录2112和“b”目录2113。列2212表示了使用何种哈希算 法来计算列2213中描述的每个值。与列2211中的文件或目录相关 的列2213包含通过使用由列2212指定的算法计算得到的哈希值。 目前，主要使用的哈希算法是SHA1(安全哈希算法1)和MD5(消息 摘要5)。这些都是用于将具有任意长度的数据转换为固定长度字节 值的公知算法，其具有如下特征：在原始分组被转换后预测该原始 分组是不可能的；并且他们用于检查文件是否已经被破坏或篡改。 同时，哈希值是通过利用哈希算法而产生的伪随机数。当哈希算法 是SHA1时，哈希值的长度是20字节，而当哈希算法是MD5时， 哈希值的长度转换为16字节。对于有关SHA1和MD5的细节，请 分别参考“FIPS-PUB 186-2 Secure Hash Standard”和“IETF RFC 1321”。在这里，与列2211中所描述的各个目录“a”和“b”相对 应的哈希值是已经分别为存在于“a”目录中的“ocap.hashfile”文 件2117和存在于“b”目录中的“ocap.hashfile”文件2118计算的 SHA1哈希值。 与221中的“ocap.hashfile”情形一样，222中的 “ocap.hashfile”包括文件名、哈希算法以及存在于同一目录2112 中的“PPV1Xlet.class”文件2114的哈希值。类似地，223中所包括 的是文件名、哈希算法和存在于同一目录2113下的 “PPV2Xlet.class”文件2115的哈希值。 在这里，只描述与本发明相关的属性，对于关于 “ocap.hashfile”的详细信息，可参照OCAP规范“OpenCabel(TM) Application Platform Specifcation OCAP 1.0 Profile(OC-SP-OCAP1.0- IF-I09-031121)”。 文件2119是证书链。图23是示出了“ocap.certificate.1”文件 2119的详细结构的示意图。描述“ocap.certificate.x”(x是正整数) 的典型结构的231，包括根证书2311、中间证书2312以及叶证书 2313。它们处于链状关系，其中例如根证书2311的持有者发布中间 证书2312，中间证书2312的持有者发布叶证书2313。注意，根据 OCAP规范，与签名文件“ocap.signaturefile.x”相关的证书链是具 有相同值“x”的“ocap.certificate.x”。在图21的情况下，与 “ocap.signaturefile.1”相对应的证书链是“ocap.certificate.1”。同 样，根证书2311、中间证书2312以及叶证书2313也以相同的 X.509证书格式来配置。如ITU-T所推荐的，在信息和通信行业的 各个领域中X.509证书被广泛地用作证书表现格式的实际标准。在 图23中，虽然仅举例说明了三个证书，但存在多个中间证书的情况 也是有的。然而，在这种情况下，这些中间证书必须处于它们相互 关联的链状状态中。 图24是示出了X.509证书的结构的示意图。这里，仅举例说明 描述本发明所需的属性。对于关于X.509证书的详细描述，请参见 IETF RFC3280“Internet X.509 Public Key Infrastructure Certificate and CRL Profile”。241表示X.509证书的属性区域，242表示X.509 证书的签名值。序列号2411表示了标识该证书的号码，签名算法 2412表示用于确定签名值242的算法，本更新日期和时间2413表示 X.509证书变得有效的日期和时间，下一更新日期和时间2413表示 X.509证书期满的日期和时间，发布者名称2415表示发布本X.509 证书的管理机构名称，主体名称2416表示X.509证书的持有者，公 开密钥2417表示主体名称2416的公开密钥，以及签名值242表示 已经使用本X.509证书的发布者的私有密钥进行签名(加密)的值。在 这个实施例中，虽然本更新日期和时间2413以及下一更新日期和时 间2414需要日期和时间的信息，但是本更新日期和时间2413以及 下一更新日期和时间2414并不总是需要时间信息。作为利用公开密 钥和私有密钥的系统，公开密钥密码系统被广泛用于电子商务和其 它领域。在公开密钥密码系统中，使用与用于加密明文的密钥不相 同的密钥来解密已加密的文本。由于加密的密钥和解密的密钥是不 同的，因此不可能根据解密的密钥来推测加密的密钥。这个加密的 密钥对应于私有密钥，而这个解密的密钥对应于公开密钥。典型的 公开密钥密码系统包括RSA(Rivest-Shamir-Adleman)和DSA(数字签 名标准)。 文件2120是签名文件，图25是示出了“ocap.signaturefile.1” 文件2120的示意图。251表示标识相关的X.509证书的标识符，252 表示哈希签名算法，以及253表示签名值，该签名值已经使用252 中所表示的哈希签名算法从“ocap.hashfile”2116中计算得出。 一旦Java程序被保存到辅助存储单元510中，即使在诸如频道 改变和终端装置500的断电这样的原因导致该Java程序被从主存储 单元511中删除的情况下，只要AM 1205b已经接收到图20中所示 的XAIT信息，那么不需要等待下载而激活该Java程序是可能的。 换言之，在图20中，程序“/a/PPV1Xlet”的控制信息2002是 “autostart”。因此，在图21的2011中，当搜索与“/a/PPV1Xlet” 相对应的文件系统的存储位置2101并且然后文件2114被传递给 JavaVM 1203时，激活保存在该文件系统中的Java程序 “PPV1Xlet”。 接下来，描述作为本发明的主要功能模块的安全管理器 1205f。 安全管理器1205f从业务管理器1204中接收预保存通知，该 预保存通知表示出图20的2004中所表示的“/a/PPV1Xlet”和 “/b/PPVXlet2”将要被保存。当接收到该通知时，安全管理器 1205f检查Java程序标识符2001的值以判定它是未签名程序还是已 签名程序。在这里，因为该Java程序是一个已签名程序，因此安全 管理器对低于“/”目录的文件系统进行验证。为了检验该文件系 统，通过使用图21中所举例说明的ocap.hashfile(2116～2118)、 ocap.certificate.1(2119)以及ocap.signaturefile.1来进行验证。 图26示出了用于对文件系统进行验证的安全管理器1205f的 组件。 通知接收单元261用于紧接着AM 1205b将要保存之前接收预 保存通知，以及用于将该事情通知给判断单元262。 判断单元262判断验证结果。它请求哈希计算单元263对文件 系统进行哈希计算以接收哈希值。判断单元262从存在于 “ocap.hashfile”文件内的哈希值2213、2223以及2233中提取出将 要比较的值，并且检查它是否匹配该接收到的哈希值。如果它们不 匹配，则判断单元262判定已被篡改，并且验证以失败结束。 此外，判断单元262利用证书提取单元265来提取X.509证书 的每一个，并且判断当前时间是否不在每一个X.509证书文件的本 更新日期和时间2313之前，以及是否不在每一个X.509证书文件的 下一更新日期和时间2414之后(即，当前时间在每一个X.509证书 文件的本更新日期和时间2313与下一更新日期和时间2414之间)。 当前日期和时间从OS 1201的库1201b中获得。如果有效期不满足 “本更新日期和时间＜当前日期和时间＜下一更新日期和时间”， 则判断单元262判定验证失败。 此外，为了验证证书链，判断单元262请求哈希计算单元263 对每一个X.509证书的属性区域241进行哈希计算。然后，它请求 签名值解密单元264进行计算用于对包含于每一个X.509证书中的 签名值242进行解密，然后将得到的已解密值与由哈希值计算单元 263所获取的哈希值进行比较，以检查证书链的状态。如果它们不 匹配，则意味着证书不处于链状关系中，因此判定验证失败。同 时，如果该值匹配且检验出证书处于链状关系中，则检查该证书链 中的根证书是否被包含在终端装置500的辅助存储单元510中。如 果不被包含，则判断单元262判定验证失败，认为执行比较是不可 能的。 当以下条件全都满足时，判断单元262判定验证成功：(1)不 存在篡改；(2)在有效期内；(3)证书处于链状关系中；以及 (4)根证书匹配。 当判断单元262请求计算每个文件的哈希值时，哈希计算单元 263从OS 1201的库1201b中提取每个文件以对它们执行哈希计算， 并将得到的值传递给判断单元262。此外，哈希计算单元263从证 书提取单元265中获取证书链231中的每个X.509证书，并对它们 的每一个的属性区域241执行哈希计算。 签名值解密单元264被判断单元262请求执行计算用于对每个 X.509证书或“ocap.signaturefile.x”的签名值进行解密。当执行计 算以对每个X.509证书的签名进行解密时，签名值解密单元264从 证书提取单元265中获取证书链231中的每一个X.509证书，然后 执行计算用于对它们的每一个的签名进行解密，并向判断单元262 返回结果。 证书提取单元265被判断单元262、哈希计算单元263和签名值 解密单元264请求以提取证书链231中的每一个X.509证书，并且 提取和返回X.509证书。 图27是一个概括当对文件系统执行验证时由安全管理器1205f 执行的操作的流程图。基于这个流程图，描述在文件系统具有图21 中所示的结构时所执行的操作。当从AM1205b中接收到文件系统的 预保存通知时(步骤S271)，安全管理器1205f对比该文件系统的顶 级“/”目录低的该文件系统进行篡改检查(步骤S272)。在该篡改检 查中，通过比较哈希值来检验出存在于该文件系统的每个目录中的 文件没有损坏或改变。 图29和图30是步骤S272的详细流程图。首先，如步骤S291 中所示，为各个文件“ocap.certificate.1”和“ocap.signaturefile.1” 以及存在于“/”目录中的各个目录“a”和“b”计算哈希值。注 意，目录“a”和“b”的哈希值分别从“/a/ocap.hashfile”文件222 和“/b/ocap.hashfile”文件223中计算得到。在步骤S293中，在步 骤292中计算的哈希值与“/ocap.hashfile”中的2213中所描述的每 个哈希值进行比较。在步骤S294中，如果所计算的哈希值的任何一 个与2213中的哈希值都不相同，则判定已经被篡改(步骤S297)。同 时，当所有所计算的哈希值与2213中的哈希值都匹配时，则转到步 骤S295。在步骤S295中，检查是否存在未完成篡改检查的子目 录。在当前阶段，目录“a”和“b”作为“/”目录中仍未执行篡改 检查的子目录。因此，需要对这些目录“a”和“b”执行篡改检 查。首先，在步骤S296中，焦点放在“a”目录上，其中执行与对 “/”目录所执行的处理相同的处理。在完成“a”目录的篡改检查 后，对“b”目录执行篡改检查。当对目录“a”和“b”的篡改检查 都完成时，然后焦点放在“/”目录，并且执行图30中的步骤S301 的处理。在步骤S301中，叶证书2313被从作为证书链231的 “/ocap.certificate.1”文件2119中提取出来。然后，在步骤S302 中，从所提取的叶证书2313中取得公开密钥2417。接下来，在步 骤S303中，计算“/ocap.hashfile”文件221的哈希值。同时，在步 骤S304中，使用存在于“/ocap.certificate.1”文件2119的叶证书 2313中的公开密钥2417对“/ocap.signaturefile.1”文件2120中的签 名值242进行解密。在步骤S305中，通过解密该签名值来检查在步 骤S303中所计算的哈希值是否等于在步骤S304中所取得的值。如 果这些计算的值相匹配，那么可判定在“/”目录以下的文件系统未 被篡改(步骤S306)。同时，如果该计算的值不相匹配，则可判定该 文件系统已被篡改(步骤S307)。注意，虽然已经描述了以降序的方 式从顶级“/”目录开始向着子目录的方向执行篡改检查，但是本发 明并不局限于此。因此，可以以升序的方式从最低级目录开始向着 顶级目录的方向来执行处理。通过上述处理，获取图27中步骤 S272的结果。 在步骤S273中，当步骤S272的结果为“已被篡改”时，判定 验证已经失败且发出关于该事情的通告(步骤S279)，此后结束处 理。当步骤S272的结果为“没有篡改”时，则执行步骤S274的处 理。 接下来，参见图31到图33，给出了证书链验证的详细描述(步 骤S274)。假设首先检查中间证书2312和叶证书2313，在图31中 示出了其流程图。首先，从证书链231中提取出来中间证书2313和 叶证书2313(步骤S311)。从该提取的叶证书2313中，提取本更新 日期和时间2413、下一更新日期和时间2414以及发布者名称2415 (步骤S312)。其中，判断当前日期和时间是否在所述本更新日期和 时间2413与下一个更新日期和时间2414之间，在这段时间期间证 书保持有效(步骤S313)。如果它超出了证书能够保持有效的期限， 则证书链的验证以失败结束(步骤S319)。同时，当判定它在该证书 的有效期限内时，则提取中间证书2312中的主体名称2416和公开 密钥2417(步骤S314)，然后在中间证书2312的主体名称2416与叶 证书2313的发布者名称2415之间进行比较，以判断中间证书2312 与叶证书2313是否处于链状关系中(步骤S315)。如果这些证书不处 于链状关系中，那么证书链的验证失败。同时，当它们之间存在链 状关系时，计算叶证书2313的属性区域241的哈希值(步骤S316)。 此外，使用中间证书2312的公开密钥2417对叶证书2313中的签名 值242进行解密(步骤S317)。当步骤S316和步骤S317都完成时， 则检查各个步骤中得到的哈希值和已解密的签名值是否匹配(步骤 S318)。如果它们不相匹配，则证书链的验证以失败结束(步骤 S319)。 接下来，在根证书2311与中间证书2312之间进行检查。图 32是示出这个处理的流程图。从证书链231中提取出根证书2311和 中间证书2312(步骤S321)，然后对根证书2311和中间证书2312执 行与对中间证书2312和叶证书2313所执行的检查相同的处理(步骤 S322～步骤S328)。 当在步骤S328中判定该值相匹配时，仅对根证书2311执行检 查。图33是示出了仅对根证书2311执行检查的流程图。从在步骤 S321中所提取出的根证书2311中，提取出本更新日期和时间 2413、下一更新日期和时间2414，以及发布者名称2415(步骤 S331)。其中，判断当前日期和时间是否在所述本更新日期和时间 2413与下一更新日期和时间2414之间，在这段时间内证书保持有效 (步骤S332)。如果它超出了证书能够保持有效的期限，则证书链的 验证以失败结束。同时，当判定它处于证书的有效期限内时，计算 根证书2311的属性区域241的哈希值(步骤S334)。此外，使用根证 书2311的公开密钥2417对根证书2311的签名值242进行解密(步骤 S335)。当步骤S334和步骤S335都完成时，则检查在各个步骤中得 到的哈希值和已解密的签名值是否匹配(步骤S336)。假如它们相匹 配，则证书链的验证成功(步骤S337)，反之如果它们不相匹配，则 证书链的验证以失败结束(步骤S338)。此时，步骤S274的处理结 束。 取决于步骤S274的结果，在步骤S275中执行不同的处理。当 步骤S274的结果为“证书链的验证失败”时，判定验证已经失败， 并且发出关于它的通知(步骤S279)，随后，结束文件系统的验证。 同时，在“证书链的验证成功”的情况下，则执行S276的处理。 接下来，从终端装置500的辅助存储单元510中搜索与 “/ocap.certificate.1”文件2119的根证书2311相同的证书(步骤 S276)。当辅助存储单元510中不存在该相同证书时，在步骤S277 中判定证书链231的验证失败，并且发出该验证失败的通知(步骤 S279)，此后，该处理结束。同时，当包含有根证书2311时，则判 定文件系统的验证成功，并且向AM 1205b发出关于验证成功的通 知(步骤S278)。参见图28，即使在其后接收到Java程序的预激活通 知(步骤S281)，该处理仍什么都不执行而结束。 在第一实施例中，当在某个时间之后将激活所保存的Java程 序时，在那时不需要执行验证，因为紧接着在文件系统被保存之前 已经验证了该文件系统。 这里，将描述图34中所示的“应用描述文件”存在于文件系 统中并且只有在其中所描述的文件将被保存的情形。例如，根据 OCAP规范，以XML(可扩展标记语言)的格式来描述“应用描述文 件”。图34示出了“应用描述文件”的一个示例。在图34中，没 有图21中所示的“PPV2Xlet.class”2115的描述。因此，在这种情 况下，“PPV2Xlet.class”2115没有作为存储目标被包括。在这种情 况下，在步骤S292中没有为“PPV2Xlet.class”2115计算哈希值， 因此在步骤S293中不会与在“ocap.hashfile”文件2118中所描述的 2233内的哈希值进行比较。在步骤S294中，可以通过规定不被作 为存储目标包括的文件在应用之外来转换到步骤S295的处理。 (第二实施例) 当在文件系统被保存之后的某个时间将激活包含于该文件系统 中的Java程序(PPV1Xlet.class 2114或者PPV2Xlet.class 2115)时，存 在包括在“/ocap.certificate.1”文件2119中的X.509证书的其中一个 的有效性期满的可能性(即，Java程序的激活日期和时间＞下一更新 日期和时间2414)。然而，即使在证书链231中包含已经期满的 X.509证书的情况下，第一实施例仍然允许Java程序被激活。 因此，通过向第一实施例增加在激活Java程序时检验包括在证 书链231中的每个证书2311、2312以及2313的有效性没有期满的 功能，来实现本实施例。图26示出了本实施例中的组件。已经在第 一个实施例中描述了本实施例必需的组件261-265，因此这里不给出 其的描述。 对于流程图，图27的流程图被图35的流程图替换并且增加了 图36的流程图。 参见图35，紧接着在文件被保存之前将要执行的处理(步骤 8351到步骤S357)与在第一个实施例中所说明的处理(步骤S271到 步骤S277)相同，因此省略其描述。如果验证没有失败，则该处理进 行到图36中所示的流程图。当通知作为Java程序的PPV1Xlet.class 2114在某个时间之后将被激活时(步骤S361)，从“ocap.certificate.1” 文件2119中提取出每一个X.509证书，即，根证书2311、中间证书 2312以及叶证书2313(步骤S362)。然后，从叶证书开始到根证书逐 一地选择该提取的X.509证书(步骤S363)，并且检查当前日期和时 间是否处于每一个所选择的X.509证书的本更新日期和时间2413与 下一更新日期和时间2414之间(步骤S364)。如果当前日期和时间不 处于本更新日期和时间2413与下一更新日期和时间2414之间，则 判定验证失败，并且发出关于该事情的通知(步骤S367)。在另一情 况下，检查是否已经对所有的X.509证书执行了检查(步骤S365)。 如果对所有X.509证书还没有完成检查，那么处理返回到S363，重 复后续步骤。同时，当在步骤S365中已经检查所有X.509证书时， 判定验证成功，并且发出关于验证成功的通知(步骤S366)，此后处 理结束。通过增加图36的流程图所示的处理，向AM 1205b通知验 证失败以便其有效期已经期满的Java程序不会被激活变得可能。当 安全管理器1205f通知验证失败时，AM 1205b在没有向JavaVM 1203传递该Java程序的情况下中止所述激活。 (第三实施例) 如第一实施例中所描述的，辅助存储单元510包括作为根证书 的X.509证书，其与证书链231中的根证书2311进行比较。为了防 备由剽窃等导致降低证书的可靠性的情形，保存在辅助存储单元 510中的根证书被新的X.509证书替换(以下称作为证书替换)。新的 X.509证书从首端101传送到终端装置500，以经由下载的模块106 传递给安全管理器1205f。 图38A、38B和38C的每一个是示出了辅助存储单元510中的 根证书被安全管理器1205f替换(证书替换)的示意图。在这种情况 下，证书A381是一个将被替换的旧证书，而证书B382是一个新证 书。图38A中的38-1示出了在执行证书替换之前保存在辅助存储单 元510中的证书，图38B的38-2示出了正在替换当中的证书，以及 图38C的38-3示出了在执行证书替换后保存在辅助存储单元510中 的证书。 在第一和第二实施例中，即使在Java程序被保存之后执行证 书替换，在Java程序的激活时间也没有考虑新证书。例如，考虑以 下：当安全管理器1205f响应于它的预保存通知而正在验证Java程 序时，证书链231中的根证书2311与证书A3811匹配；以及在证书 A381被证书B382替换后，安全管理器1205f接收Java程序的预激 活通知。在这个时候，辅助存储单元510不包括与证书链231中的 根证书相匹配的任何证书，意味着该证书是不可靠的。然而，在第 一和第二实施例中，由于紧接着在Java程序的激活之前没有在根证 书之间进行比较(即，证书链231中的根证书2311没有与证书B382 进行比较)，因此，没有向AM 1205b发出关于验证失败的通知。结 果，AM 1205b使Java程序被激活。 因此，本实施例增加在Java程序激活时由于证书替换而进行 根证书比较的功能。 图26示出了本实施例的组件。由于已经描述组件261～265， 因此省略其说明。增加了证书替换单元266、证书替换规范单元267 以及证书接收单元268。 当证书替换规范单元267判定比所接收到的证书旧的证书被保 存在辅助存储单元510中时，证书替换单元266使用新的证书替换 该旧的证书。同时，当证书替换规范单元267判定没有较旧的证书 被保存时，证书替换单元266将新的证书保存到辅助存储单元510 中。 证书替换规范单元267接收由证书接收单元268所接收到的证 书。然后，通过使用OS 1201的库1201b，它检查保存在辅助存储 单元510中的证书，以查看是否存在其发布者相同并且比所接收到 的证书旧的任何证书。 当下载的模块1206从首端101接收新的证书时，证书接收单 元268接收该新的证书。当接收到该证书时，证书接收单元268将 其传递给证书替换单元266和证书替换规范单元267。 此外，图39和图40随后被增加到图35的流程图。 图39是执行证书替换时的流程图，而图40是执行证书替换之 后激活Java程序时的流程图。参见图39，当接收到证书替换的请求 时(步骤S391)，提取出该接收的证书的发布者名称(步骤S392)。检 查在终端装置500的辅助存储单元500中是否存在将需要替换的旧 证书(步骤S393)，且仅当存在旧证书时，删除该证书。然后，将该 接收的证书保存到辅助存储单元510中(步骤S395)。当在某个时间 后接收到该Java程序的激活通知时(步骤S401)，在辅助存储单元 510中搜索与证书链231中的根证书2311相匹配的证书(步骤 S402)，如果存在任何证书(步骤S403)，则判定验证成功并且发出关 于这个事情的通知(步骤S404)。如果不存在相匹配的证书(步骤 S403)，则判定验证失败，且发出关于这个事情的通知(步骤S405)。 注意，在步骤S404中判定验证成功之前，在检验证书链中的每个 X.509证书满足“本更新日期和时间＜当前日期和时间＜下一更新日 期和时间”后推断出验证是成功的也是可能的。 此外，除了检查根证书是否匹配外，在S402之前执行图31～ 图33所示的检查以查看证书链中的证书是否处于链状关系中之后来 判定验证是成功的/不成功的也是可能的。 此外，虽然对基于发布者名称来指定应当被替换的证书的情形 给出了上述描述，但是，也可以基于诸如主体名称这样的另外属性 值来指定证书。 (第四个实施例) 当在文件系统被保存之后的某个时间将激活包括在该文件系统 中的Java程序(PPV1Xlet.class 2114或者PPV2Xlet.class 2115)时，存 在一种情况，其中，由除了包括于“/ocap.certificate.1”文件2119中 的任一X.509证书的有效期期满和根证书被替换之外的原因引起证 书被撤销。这种配置即使存在被撤销的证书也允许Java程序被激 活。 这里，CRL(证书撤销列表)是一种广为人知的证书撤销者。图 41是示出了CRL结构的示意图。这里，仅举例说明解释本发明所需 的属性。对于有关CRL的更多详情，请参考IETF RFC 3280 “Internet X.509 Public Key Infrastructure Certificate and CRL Profile”。411表示CRL的属性区域，412表示签名值413的签名算 法，以及413表示CRL的签名值。发布者名称4111表示这个CRL 的发布者，本更新日期和时间4112表示该CRL生效的日期和时 间，下一日期和时间4113表示该CRL的有效性期满的日期和时 间，以及被撤销证书列表4114表示关于被撤销的X.509证书的信 息。图42是示出了被撤销证书列表4114结构的示意图。这里，也 仅举例说明解释本发明所需的属性。被撤销证书列表4114中存储了 关于多个被撤销的X.509证书的信息。在图42的情况下，作为关于 被撤销的“证书A”421的信息，包括了用于唯一标识了该证书的序 列号4211和“证书A”421被撤销的日期和时间4212。其它被撤销 证书也与421相同。 图43是包含有CRL的文件系统的一种示例配置。内部保存了 “/”目录432、“a”目录432、“SimpleXlet.class”文件433、 “ocap.hashfile”文件434～435、“ocap.certificate.1”文件436、 “ocap.signaturefile.1”文件437、“ocap.crl.2”文件438，以及 “ocap.certificate.2”文件439。对不包含CRL的文件系统的验证与 第一实施例中所描述的相同。因此，在本实施例中，焦点放在以 CRL格式构造的“ocap.crl.2”文件438和作为该文件的证书链的 “ocap.certifificate.2”文件439上。注意，根据OCAP规范， “ocap.crl.x”的证书链是“ocap.certificate.x”。在图43的情况中， “ocap.crl.2”的证书链是“ocap.certificate.2”。 图46是示出了“ocap.hashfile”文件434结构的示意图。461 示出了ocap.hashfile 434的详情。461中存在于“/”目录431中的 ocap.hashfile，包含与存在于相同目录431中的每一个 “ocap.certificate.1”文件436、“ocap.signaturefile.1”文件437、 “a”目录432、“ocap.crl.2”文件438以及“ocap.certificate.2”文 件439相关的哈希值。 图44是说明CRL的验证的流程图。下面将描述其中文件系统 具有图43中所示的配置的示例。首先，从CRL中提取本更新日期 和时间4112以及下一更新日期和时间4113(步骤S441)，然后检查 当前日期和时间是否在所述本更新日期和时间4112与下一更新日期 和时间4113之间(步骤S442)。如果不在，则判定该CRL无效(步骤 S447)。如果当前日期和时间在它们之间，则计算属性区域411的哈 希值，以检验“ocap.crl.2”文件438的签名值(步骤S443)。同时， 从作为证书链的“ocap.certificate.2”文件439中提取叶证书2313的 公开密钥2417(步骤S444)，并且使用所提取的公开密钥2417对 “ocap.crl.2”文件438的签名值413进行解密(步骤S445)。然后， 检查步骤S443中获取的哈希值是否等于步骤S445中获取的解密值 (步骤S446)。如果它们不相等，则判定该CRL无效(步骤S447)。如 果它们相等，参见图45，那么对作为证书链的“ocap.certificate.2” 文件439执行验证(步骤S451)。验证证书链的方法与图31到图33 中所示的方法相同，因此这里描述它。接下来，判断证书链的验证 是否成功(步骤S452)，并且如果该验证失败，则判定该CRL无效 (步骤S456)。同时，如果该验证成功，则从辅助存储单元510中搜 索与根证书相同的证书(步骤S453)。在这里，如果没有匹配的根证 书，则判定该验证失败以及该CRL无效(步骤S456)，反之如果存在 相匹配的根证书，则判定该验证成功以及该CRL有效(步骤S455)。 下面描述了解决这一问题的方法，即尽管按照CRL证书被撤 销了但Java程序仍被激活。为了支持这，本实施例增加以下功能， 即当发出Jave程序的激活通知时，判断用于验证该Jave程序的证书 是否为CRL中的被撤销证书。 图26示出了本实施例的组件。除了对其做了一些增加的262 和仍没有描述的269之外，对上面已经过描述的组件不再给出描 述。 还能验证CRL的判断单元262，请求证书撤销规范单元269指 定将由CRL撤销的证书。然后，当通知接收单元261接收到与证书 撤销规范单元269所指定的被撤销证书相关的Java程序的预激活通 知时，判断单元262判定验证失败。同时，当在判断单元262已经 不能验证CRL且因此判定该CRL无效的状态下，通知接收单元261 接收到Java程序的预激活通知时，判断单元262判定验证成功。 当判断单元262认为该CRL的验证成功时，证书撤销规范单 元269指定由证书提取单元265所提取的X.509证书中的哪一个证 书是被撤销证书。 对于流程图而言，增加图47和图48。下面给出根据这些流程 图的描述。假设现在发出图21中所示的文件系统的预保存通知，则 启动图35的流程图中所示的处理，并且在适当的时候完成步骤 S357的处理。假设然后接收到图43中所示的另一文件系统的预保 存通知，那么在完成图44的流程图中所示的处理后，执行步骤 S471到步骤S477。步骤S471到步骤S477的处理与步骤S351到 S357的处理相同。当到达步骤S478并且如果“ocap.crl.2”文件438 的验证(图44和45的流程图)成功时，关于该文件中所包含的被撤销 证书的信息被写入到被撤销证书数据库中。图49是示出了该被撤销 证书数据库的示意图。在列491中保存发布者名称，在列492中保 存证书序列号，以及在列493中保存撤销的日期和时间。在这里， 当接收到“PPV1Xlet.class”2114的预激活通知时(步骤S481)，检查 在“ocap.certificate.1”文件2119的证书链231中包含的X.509证书 的任意一个，是否包括在被撤销证书数据库中(步骤S483)。如果存 在该证书的任意一个，则判定验证失败且发出关于此的通知(步骤 S486)。同时，当没有适用的证书时，对整个证书链进行检查(步骤 S484)，且发出判定验证成功的通知(步骤S485)。经由上述处理，通 过对于其证书在检验时是有效的但在Java程序被激活时该证书被 CRL撤销的文件系统，判断文件的验证失败，来解决该不应当被激 活的Java程序被激活的问题。 注意，在第一到第四个实施例中，当接收到Jave程序的预激 活通知时，通过使用放置在每个目录中的“ocap.hashfile”来进一步 进行检验以查看文件系统的树结构是否正确是可能的。 此外，虽然为了简化的目的，在证书链中仅有一个中间证书， 但是可以有多个中间证书。然而，当执行它的证书链的验证时，所 有中间证书都必须处于链状关系中。 此外，虽然已经以上述次序描述了以下处理，但是本发明并不 限于该次序：检查存在/不存在篡改；验证证书链；检查以查看辅助 存储单元是否包括与证书链中的根证书相同的根证书。 此外，对于文件系统的保存，安全管理器1205f可以使用OS 的库1201b来保存它。同样，第一到第四个实施例也可用于这样的 情形，其中“应用描述文件”被放置在在文件系统的顶级目录“/” 中，而就它的内容而言，仅将文件系统的一部分表示为将要保存的 文件。因此，如果仅处理将要保存的文件，则不会出现问题。 此外，虽然上面将程序描述为存储目标，但是除了程序之外的 数据也可以是存储目标，意味着第一到第四个实施例也可应用到数 据上。 此外，存在多于一个“ocap.certificate.x”对应于“ocap. signaturefile.x”的可能性，在这种情况下，“ocap.certificate.x”文 件的至少一个的验证需要是成功的。 同样，虽然已经将“ocap.certifidcate.x”呈现为一个示例证书 链，已经将“ocap.hashfile”呈现为具有哈希值的示例文件，以及已 经将“ocap.signaturefile.x”呈现为一个示例文件用于检查在“/”目 录中的“ocap.hashfile”是否已经被篡改，但是本发明并不局限于这 些文件名称。 而且，在认证失败的情况下，可以在重新下载之后再次进行认 证。 此外，在认证失败的情况下，所保存的程序连同已经用于验证 的证书链、签名文件和哈希文件可以被删除，以保留足够的容量用 于存储空间。 在这里，描述了这样一种情形，其中组成程序的文件系统具有 图50中所示的配置，但是如图51中所示的“应用描述文件”的情 形那样，没有描述将用于验证的文件。图50中所示的5011到5020 等同于图21中所示的2111到2120。5021表示“应用描述文件”， 其描述将要保存的文件。在图51的“应用描述文件”中，没有描述 验证所需的“ocap.certificate.1”5019、“ocap.signaturefile.1”5020 和“ocap.hashfile”5017。在这种情况下，假如文件正如图51所示 的那样被存储，那么执行验证所需的文件将不被保存。因此，在激 活时不能执行在第二、三和四实施例中呈现的验证。当所保存的程 序将要被激活，并且在示出该程序被保存之前的文件的图50中所示 的文件已做好下载的准备，该保存的文件可以用作组成该程序的文 件，以及用于验证的文件可以再次下载用于验证。 然而，也可以存在这样的情况，其中示出程序被保存之前的文 件的图50中所示的文件不能被下载。因此，即使在“应用描述文 件”中没有描述它们，验证所需的文件也可以被保存以用于在程序 激活时执行验证。 尽管上面仅对本发明的一些示意性实施例进行了详细的描述， 但是本领域的技术人员应当理解在没有本质上脱离本发明的新颖性 教导和优点的情况下，在该示意性实施例中进行许多变形是可能 的。因此，所有这样的变形都被认为是在本发明的范围之内。 工业实用性 根据本发明的能够保证程序可靠性和提高响应度的已验证程序 的运行方法，对临时提高数字电视接收机的功能和将功能增加给它 是很有用的。此外，本发明不仅可用于数字电视，而且也可用于诸 如临时提高诸如个人电脑和移动电话这样的信息设备的功能和临时 增加功能给该信息设备。