MXPA06014020A

MXPA06014020A - Metodo para autenticar y ejecutar un programa.

Info

Publication number: MXPA06014020A
Application number: MXPA06014020A
Authority: MX
Inventors: Tadao Kusudo; Yoshio Kawakami
Original assignee: Matsushita Electric Ind Co Ltd
Priority date: 2004-07-14
Filing date: 2005-07-12
Publication date: 2007-02-08
Also published as: CA2566801A1; US8397078B2; TW200610345A; JP2008507154A; BRPI0512023A; US20110307702A1; US8037317B2; CN100583987C; KR20070043783A; WO2006006719A1; CN1985516A; KR20120002625A; US20060015746A1; EP1766974A1

Abstract

Diferente de la tecnologia para un programa descargado a traves de ondas convencionales de difusion, en el caso de descarga de un programa via una red, existe la posibilidad que este programa se active sin percibir que el programa esta alterado. Por esta razon, cuando un programa se descarga via una red, se construye una jerarquia de archivo para el programa localizado en un servidor en una area local de una terminal. De manera subsiguiente, se realiza la autenticacion del programa con respecto a la jerarquia de archivo construida en el area local, y se garantiza la credibilidad del programa.

Description

MÉTODO PARA AUTENTICAR Y EJECUTAR UN PROGRAMA Campo de la Invención La presente invención se refiere a un método para autenticar y ejecutar un programa, para verificar la credibilidad de un programa descargado, y para ejecutar el programa para el cual se ha autentificado la credibilidad. Antecedentes de la Invención La función en una televisión digital de descargar un programa y verificar/garantizar la credibilidad de este programa se describe en la especificación de DVB-MHP "ETSI TS 101 812 Vi.2.1 DVB-MHP Specification 1.0.2", Traducción del Japonés de la Solicitud Internacional PCT (Tokuhyo) 2002- 508624, y de más. Éstas incluyen funciones para verificar que un programa sobrepuesto en ondas de difusión que se reciben no se ha alterado, y la verificación en cuanto a si este programa se emitió por una organización confiable. Con esto, es posible impedir la activación de un programa re-escrito que opere de manera diferente del original, un programa que corresponde a una tercera parte de engaño y demás, que infligiría daño en una televisión digital. Posteriormente en la presente, el acto de confirmar la credibilidad de estos programas se debe referir como autenticación . Además de un programa sobrepuesto en ondas de REF:177295 difusión que se reciben, la especificación de DVB-MHP "ETSI TS 101 812 VI.2.1 DVB-MHP Standard 1.0.2" también considera la descarga, mediante una red tal como la Internet, y la verificación de un programa localizado en un servidor. Sin embargo, diferente del caso de un programa descargado a través de ondas convencionales de difusión, el caso de descarga mediante una red puede ocasionar un problema de seguridad. El problema de seguridad mencionado aquí se refiere a la posibilidad que un archivo que constituye un programa usado en la autenticación de un programa (subsecuentemente referido como archivo de configuración) y un archivo de configuración de un programa usado cuando se activa un programa en un aparato terminal puede ser diferente para uno o todos los archivos. Este es el caso cuando, después de que un aparato terminal descarga el archivo de configuración de un programa de un servidor y lo autentica, está alterado el archivo de configuración del programa localizado en el servidor. Cuando está alterado el archivo de configuración y subsiguientemente se vuelve a descargar por el aparato terminal, no se puede usar normalmente por más tiempo el programa estructurado de este archivo de configuración. Adicionalmente, existe una tecnología para poner conjuntamente varios archivos como uno en un formato de archivo llamado JAR (Archivo Java) que se basa en el formato de archivo ZIP bien conocido. Al usar esta tecnología, se comprime el tamaño del archivo y se puede acortar el tiempo requerido para la descarga, en comparación a cuando no se usa un JAR. Sin embargo, cuando se usa el JAR en casos donde se actualizan frecuentemente los datos localizados en el servidor, los archivos de formato JAR tienen que elaborarse cada vez que se actualizan los datos. Esto reparte una carga en el servidor y hay casos donde no es deseable. Por ejemplo, el caso de un servidor que proporciona un programa que usa información de precios de inventario se somete esta categoría como información de precios de inventario y similares que cambia constantemente en tiempo real . En vista del problema mencionado anteriormente, se requiere un aparato de autenticación tal como una televisión digital, y demás, que garantice la credibilidad de un programa descargado, mediante una red, desde un servidor en el cual estén arreglados archivos y directorios en una estructura jerárquica sin el uso de archivos representados en el formato JAR. Breve Descripción de la Invención En la presente invención, se construye una jerarquía de archivos de un programa localizado en un servidor, en un área local de un aparato terminal, cuando se descarga el programa mediante una red. Adicionalmente, la presente invención tiene el objetivo de proporcionar un método para autenticar y ejecutar un programa, que garantice la credibilidad de un programa al realizar la autenticación del programa con respecto a la jerarquía de archivos construida en el área local . A fin de solucionar el problema existente, el método para autenticar y ejecutar un programa de acuerdo a la presente invención es un método para autenticar y ejecutar un programa, que incluye: un paso de autenticación de almacenamiento de i) descargar, desde un servidor predeterminado, un programa que almacena, en una estructura de directorio, al menos un archivo de datos que requiere verificación de alteración, de acuerdo a la información que identifica una ubicación de almacenamiento de un programa, ii) autenticar el archivo de datos descargado que requiere verificación de alteración, y iii) almacenar el programa en un receptor de difusión, la información que se especifica en una corriente de transporte, y el servidor que se conecta a una red, y un paso de ejecución para ejecutar el programa de autenticado, en donde el paso de autenticación de almacenamiento incluyen: un primer paso de descarga, el receptor de difusión, todos los archivo de datos que requieren verificación de alteración listados en un archivo inservible para tener una estructura de directorio que es la misma como la estructura de directorio del programa almacenado del servidor, en base a un directorio y un archivo de datos listados en el archivo inservible incluido en un directorio que constituye la estructura de directorio, un segundo paso para verificar si dos valores de troceo corresponden o no, uno de los valores de troceo que se calcula de cada uno de los archivos de datos que requieren verificación de alteración y el otro valor de cálculo de direccionamiento que se almacena en el archivo inservible que lista los archivos de datos, un tercer paso de verificación de validez de un archivo de certificado incluido en el programa, un cuarto paso para verificar si un valor de desencriptado y un valor de cálculo de direccionamiento corresponden o no, el valor de desencriptado que se obtiene al desencriptar un valor de identificación de un archivo de identificación incluido en el programa usando una clave pública de un certificado de entrada incluido en el archivo de certificado del programa, y el valor de cálculo de direccionamiento que se calcula de un archivo inservible localizado en un directorio superior del programa, y un quinto paso de" autenticar el programa y almacenar el programa autenticado, en el caso donde se satisfagan todo lo siguiente: los dos valores de troceo se verifica que corresponden en el segundo paso; el archivo de certificado se verifica que es válido en el tercer paso; y el valor desencriptado y el valor de cálculo de direccionamiento se verifica que corresponden en el cuarto paso, y el paso de ejecución incluye un paso de verificación para verificar si el archivo de certificado incluido en el programa almacenado es válido o no, y en el paso de ejecución, el programa almacenado se autentica nuevamente y se ejecuta sólo en el caso donde el archivo de certificado incluido en el programa almacenado se verifique que es válido en el paso de verificación. Por consiguiente, es posible construir, en el área de almacenamiento local, una jerarquía de archivos que es la misma como aquella en el servidor, y se pueda garantizar la credibilidad. Adicionalmente, es posible impedir que se instale un programa que se ha alterado en el servidor, en el receptor de difusión, a pesar de la autenticación exitosa. Con esto, aún con la alteración en el servidor, este programa se puede usar normalmente en el receptor de difusión. Además, el programa no necesita ser descargado nuevamente, y se puede omitir la autenticación en esta descarga. Esto mejora la conveniencia para un usuario quien tiene que esperar hasta que se termine la terminación de la autenticación para la activación de un programa. Además, la presente invención, el servidor presenta archivos en la forma de una jerarquía de archivos, sin usar archivos comprimidos mostrados en JAR. Por lo tanto, aún en el caso donde el servidor incluye archivos con datos actualizados frecuentemente, es posible reducir la carga, colocado en el servidor, de tener que volver a hacer los archivos comprimidos cada vez que se lleve a cabo la actualización. Adicionalmente, el tercer paso incluye un sexto paso para verificar si dos certificados de raíz corresponden o no, uno de los certificados de raíz que está en el archivo de certificado incluido en el programa y el otro certificado de raíz que se localiza en el receptor de difusión, y en el tercer paso, el archivo de certificado se puede verificar que sea válido en el caso donde correspondan los dos certificados de raíz. Aquí, el tercer paso incluye además un séptimo paso para verificar un periodo de validez de cada certificado en el archivo de certificado incluido en el programa, y en el tercer paso, el archivo de certificado se puede verificar que sea válido en el caso donde se satisfagan ambos de lo siguiente: los dos certificados de raíz corresponden, el tiempo en el cual se realiza la autenticación está dentro del periodo de validez de cada certificado en el archivo de certificado. Por consiguiente, es posible prevenir el almacenamiento de un programa que tiene un certificado de raíz de no correspondencia, o un certificado con un periodo de validez que ya se haya vencido. Adicionalmente, este paso de verificación incluye un octavo paso para verificar si dos certificados de raíz corresponden o no, o uno de los certificados de raíz que está en el archivo de certificado incluido en el programa almacenado y el otro certificado de raíz que se localiza en el receptor de difusión, y en el paso de verificación, el archivo de certificado incluido en el programa almacenado se puede verificar que sea válido en el caso donde correspondan los dos certificados de raíz. Aquí, el paso de verificación incluye además un noveno paso para verificar un periodo de validez de cada certificado en el archivo de certificado incluido en el programa almacenado, y en el paso de verificación, el archivo de certificado incluido en el programa almacenado se puede verificar que sea válido en el caso donde se satisfagan ambas de las siguientes: los dos certificados de raíz corresponden, y el tiempo en el cual se realiza la ejecución está dentro del periodo de validez de cada certificado en el archivo de certificado. Por consiguiente, es posible prevenir la ejecución de un programa que tiene un certificado de raíz de no correspondencia, o un certificado con un periodo de validez que se haya vencido ya. Adicionalmente, el programa no necesita ser almacenado en el caso donde se satisfaga al menos una de la siguiente: los dos valores de troceo se verifica que estén en correspondencia en el segundo paso, el archivo de certificado no se verifica que sea válido en el tercer paso, y el valor desencriptado y el valor de cálculo de direccionamiento no se verifican que estén en correspondencia en el cuarto paso. Por consiguiente, es posible prevenir el almacenamiento de, por ejemplo, un programa que se ha alterado en el servidor . Adicionalmente, el primer paso puede incluir un décimo paso para construir, por debajo de un directorio superior en el receptor de difusión, o un directorio que es el mismo como un directorio especificado por un archivo inservible, y descargar en el directorio correspondiente construido en el receptor de difusión, un archivo de datos que requiere verificación de alteración especificada por un archivo inservible almacenado en el directorio especificado por el archivo inservible almacenado en el directorio superior en el servidor, en el caso donde el directorio se especifique por el archivo inservible almacenado en el directorio superior que constituye el programa, en el servidor. Por consiguiente, es posible construir, en el receptor de difusión, una jerarquía de archivo que es la misma como aquella en el servidor, y descargar un archivo de datos que requiera verificación de alteración en el directorio correspondiente construido en el receptor de difusión. Además, la presente invención se puede realizar, no sólo como un método para autentificar y ejecutar un programa tal como aquel mencionado anteriormente, sino también como un aparato para autenticar y ejecutar un programa, que tiene los pasos característicos incluidos en este método como componentes, y también como un programa que hace que una computadora ejecute estos pasos característicos. Además, se sobreentiende que un programa se puede distribuir mediante un medio de grabación tal como un CD-ROM y un medio de transmisión tal como la Internet. De acuerdo al método para autenticar y ejecutar un programa de la presente invención, es posible construir, en un área local de almacenamiento, una jerarquía de archivos que es la misma como aquella en el servidor, y se puede garantizar la credibilidad de un programa. Adicionalmente, es posible impedir que se instale un programa que se ha alterado en el servidor, en el receptor de difusión, a pesar de la autenticación exitosa. Por consiguiente, aún cuando se haya alterado en el servidor, el programa se puede usar normalmente en el receptor de difusión. Información Adicional Acerca de los Antecedentes Técnicos a esta Solicitud La descripción de la Solicitud Norteamericana Provisional No. 60/587511 presentada el 14 de julio del 2004 incluyendo la especificación, dibujos y reivindicaciones se incorpora en la presente como referencia en su totalidad. Breve Descripción de las Figuras Estos y otros objetos, ventajas y características de la invención llegarán a ser evidentes a partir de la siguiente descripción de la misma tomada en unión con las figuras anexas que ilustran una modalidad específica de la invención. En las figuras : La Figura 1 es un diagrama que muestra una estructura de un sistema de televisión por cable de acuerdo a una primera modalidad de la presente invención; La Figura 2 muestra un ejemplo del uso de las bandas de frecuencia usadas para comunicaciones entre un centro distribuidor y aparatos terminales en el sistema de televisión por cable de acuerdo a la presente invención; La Figura 3 muestra un ejemplo del uso de las bandas de frecuencia usadas para comunicaciones entre el centro distribuidor y los aparatos terminales en el aparato de televisión de acuerdo a la presente invención; La Figura 4 muestra un ejemplo del uso de las bandas de frecuencia usadas para comunicaciones entre el centro distribuidor y los aparatos terminales en el sistema de televisión por cable de acuerdo a la presente invención; La Figura 5 es un diagrama que muestra una configuración de un aparato terminal en un sistema de televisión de por cable de acuerdo a la presente invención; La Figura 6 muestra un ejemplo de una vista externa del aparato terminal en el sistema de televisión por cable de acuerdo a la presente invención; La Figura 7 es un diagrama que muestra una configuración de equipo de cómputo de un POD de acuerdo a la presente invención; La Figura 8 es un diagrama que muestra la estructura de un programa almacenado en el POD de acuerdo a la presente invención; La Figura 9 es un diagrama que muestra una estructura de un paquete definido en la norma MPEG; La Figura 10 muestra un ejemplo de una corriente de transporte de MPEG2; La Figura 11 muestra una vista externa de ejemplo de una unidad de entrada en el caso donde se configure en la forma de un panel frontal; La Figura 12 es un diagrama que muestra una estructura del programa almacenado en un aparato terminal de acuerdo a la presente invención; Las Figuras 13A y 13B muestran un ejemplo de una pantalla de visualización exhibida por una visualización en pantalla de acuerdo a la presente invención; La Figura 14 muestra un ejemplo de la información almacenada en una unidad secundaria de almacenamiento de acuerdo a la presente invención; Las Figuras 15A a 15C muestran un ejemplo de información almacenada en una unidad de almacenamiento primaria de acuerdo a la presente invención; La Figura 16 es un diagrama esquemático que muestra los contenidos de un PAT especificado en la norma MPEG2 de acuerdo a la presente invención; La Figura 17 es un diagrama esquemático que muestra los contenidos de un PMT especificado en la norma MPEG2 de acuerdo a la presente invención; La Figura 18 es un diagrama esquemático que muestra los contenidos de un AIT especificado en la norma DVB-MHP de acuerdo a la presente invención; La Figura 19 es un diagrama esquemático que muestra los sistemas de archivos que se van a transmitir en el formato de DSMCC de acuerdo a la presente invención; La Figura 20 es un diagrama esquemático que muestra los contenidos de XAIT de acuerdo a la presente invención; La Figura 21 muestra un ejemplo de la información almacenada en la unidad secundaria de almacenamiento de acuerdo a la presente invención; Las Figuras 22A a 22C muestran un ejemplo de archivos que almacenan valores de troceo de nombres de archivos o nombres de directorio de acuerdo a la presente invención; La Figura 23 es un diagrama que muestra una estructura de una cadena de certificados de acuerdo a la presente invención; La Figura 24 es un diagrama que muestra una estructura de un certificado de X.509 de acuerdo a la presente invención; La Figura 25 es un diagrama que muestra una estructura de un archivo de identificación de acuerdo a la presente invención; La Figura 26 es un diagrama que muestra los elementos constituyentes de un módulo de seguridad de acuerdo a la presente invención; La Figura 27 es un diagrama de flujo que muestra una operación que se va a realizar cuando un sistema de archivo se autentica de acuerdo con la presente invención; La Figura 28 es un diagrama de flujo en el caso donde no se realice la autenticación cuando se reciba una instrucción de autenticación de acuerdo a la presente invención; La Figura 29 es un diagrama de flujo que muestra una operación que se va a realizar cuando se realiza la verificación de alteración para un sistema de archivo de acuerdo a la presente invención; La Figura 30 es un diagrama de flujo que muestra una operación que se va a realizar cuando se realiza la verificación de alteración por el uso de un archivo de identificación de acuerdo a la presente invención. La Figura 31 es un diagrama de flujo que muestra una operación que se va a realizar cuando una relación de cadena entre un certificado de entrada y un certificado intermedio se verifica de acuerdo a la presente invención; La Figura 32 es un diagrama de flujo que muestra una operación que se va a realizar cuando se verifica de acuerdo a la presente invención una relación de cadena entre un certificado intermedio y un certificado de raíz; La Figura 33 es un diagrama de flujo que muestra una operación que se va a realizar cuando una identificación en un certificado de raíz se verifica de acuerdo a la presente invención; La Figura 34 muestra un ejemplo de un archivo que se va a usar para especificar archivos que se van a almacenar de acuerdo a la presente invención; La Figura 35 es un diagrama de flujo que muestra una operación que se va a realizar cuando se realiza la autenticación de un sistema de archivos de acuerdo a la presente invención; La Figura 36 es un diagrama de flujo que muestra una operación que se va a realizar en el momento de verificar la validez de los certificados X.509 cuando se recibe una instrucción de autenticación de acuerdo a la presente invención; La Figura 37 es un diagrama que muestra una estructura simplificada de un archivo de código que se va a recibir de un módulo de descarga de acuerdo a la presente invención; Las Figuras 38A a 38C son diagramas que muestran un certificado poseído por el aparato terminal que se reemplaza de acuerdo a la presente invención; La Figura 39 es un diagrama de flujo que muestra una operación que se va a realizar cuando se realiza el reemplazo de certificado de acuerdo a la presente invención; La Figura 40 es un diagrama de flujo que muestra una operación que va a realizar en el momento de comparar los certificados de raíz cuando se recibe una instrucción de autorización de acuerdo a la presente invención; La Figura 41 es un diagrama que muestra una estructura de un CRL de acuerdo a la presente invención; La Figura 42 es un diagrama esquemático que muestra una lista de certificado revocada en la CRL de acuerdo a la presente invención; La Figura 43 es un ejemplo de un sistema de archivos que incluye un CRL de acuerdo con la presente invención; La Figura 44 es un de diagrama de flujo que muestra una operación que se va a realizar cuando se verifica la validez de la CRL en base a un valor de cálculo de direccionamiento y un valor d identificación de acuerdo con la presente invención; La Figura 45 es un diagrama de flujo que muestra una operación que se va a realizar cuando se verifica la validez de la CRL en base a una relación de cadena entre los certificados y una comparación entre los certificados de raíz de acuerdo con la presente invención; La Figura 46 muestra un ejemplo de un archivo que almacena valores de troceo en nombres de archivo o nombres de directorio de acuerdo con la presente invención; La Figura 47 es un diagrama de flujo que muestra una operación para realizar la autenticación en el caso donde exista un CRL en el momento de almacenamiento de programa de acuerdo con la presente invención ; La Figura 48 es un diagrama de flujo que muestra una operación para realizar la autenticación en el caso donde exista un CRL en el momento de activación del programa; La Figura 49 es un diagrama esquemático que muestra una base de datos de certificados revocados de acuerdo con la presente invención; La Figura 50 es un diagrama esquemático que muestra detalles de XAIT de acuerdo con la presente invención; La Figura 51 es diagrama esquemático que muestra un patrón de conexión de una red de acuerdo con la presente invención; La Figura 52 es un diagrama que muestra elementos constituyentes y elementos relacionados de un AM de acuerdo con la presente invención; La Figura 53 es un ejemplo de una jerarquía de archivos de acuerdo a la presente invención; Las Figuras 54A y 54B muestran un ejemplo de un archivo que almacena valores de troceo en nombres de archivo o nombres de directorio de acuerdo con la presente invención; La Figura 55 es un diagrama de flujo que muestra una operación que se va a realizar cuando se construye una jerarquía de archivos en un área local y se realiza la autenticación de acuerdo a la presente invención; La Figura 56 es un diagrama esquemático que muestra detalles de XAIT de acuerdo con la presente invención; La Figura 57 es un ejemplo de una jerarquía de archivos de acuerdo a la presente invención; y Las Figuras 58A a 58C muestran un ejemplo de un archivo que almacena valores de troceo de nombres de archivo o nombres de directorio, de acuerdo a la presente invención. Descripción Detallada de la Invención Más adelante en la presente, las modalidades de la presente invención se van a describir con referencia a los diagramas . Primera Modalidad La modalidad del sistema de televisión por cable en la presente invención se debe explicar con referencia a los diagramas. La Figura 1 es un diagrama de bloques que muestra la relación entre los aparatos que componen el sistema de cable, que son un centro distribuidor 101, y tres aparatos terminales: un aparato terminal Allí, un aparato terminal B112, y un aparato terminal C113. En la presente terminal, se conectan tres aparatos terminales a un centro distribuidor, pero es posible llevar a cabo la presente invención aún con un número arbitrario de aparatos terminales que se conectan al centro distribuidor. El centro distribuidor 101 transmite, a aparatos terminales plurales, señales de difusión tal como vídeo, audio y datos, y recibe datos transmitidos desde los aparatos terminales. A fin de realizar esto, las bandas de frecuencia se dividen para el uso en la transmisión de datos entre el centro distribuidor 101, y el aparato terminal Allí, el aparato terminal B112, y el aparato terminal C113. La Figura 2 es una tabla que muestra un ejemplo de bandas de frecuencia divididas . Hay aproximadamente dos tipos de bandas de frecuencia: fuera de banda (para ser abreviado como OOB) y En Banda. Una banda de frecuencia de 5 ~ 103 MHz se asigna a OOB para ser usada principalmente para intercambios de datos entre el centro distribuidor 101, y el aparato terminal Allí, el aparato terminal B112, y el aparato terminal C113. Una banda de frecuencia de 103 MHz ~ 864 MHz se asigna a En Banda para ser usada principalmente para canales de difusión que incluyen video y audio. Se emplea QPSK para OOB, en tanto que se emplea QAM64 para En Banda como técnicas de modulación. Se omite aquí una explicación detallada de las técnicas de modulación, puesto que son técnicas públicamente conocidas que se refieren menos a la presente invención. La Figura 3 muestra un ejemplo más específico de cómo se usa una banda de frecuencia de OOB.

Se usa una banda de frecuencia de 70 MHz ~ 74 MHz para transmitir datos desde el centro distribuidor 101. En este caso, todos de él aparato terminal Allí, el aparato terminal B112, y el aparato terminal C113 reciben los mismos datos del centro distribuidor 101. Entre tanto, se usa una banda de frecuencia de 10.1 MHz - 10.1 MHz para transmitir datos desde el aparato terminal Allí al centro distribuidor 101. Se usa una banda de frecuencia de 10.1 MHz ~ 10.2 MHz para transmitir datos desde al aparato terminal B112 al centro distribuidor 101. Se usa una banda de frecuencia de 10.2 MHz ~ 10.3 MHz para transmitir datos desde el aparato terminal C113 al centro distribuidor 101. Por con siguiente, los datos que son único a cada aparato terminal se pueden transmitir al centro distribuidor 101 desde el aparato terminal Allí, el aparato terminal B112, y el aparato terminal C113. La Figura 4 muestra un uso de ejemplo de la banda de frecuencia de En Banda. Las bandas de frecuencia de 150 ~ 156 MHz y 156 ~ 162 MHz se asignan respectivamente a un canal 1 de televisión y a un canal 2 de televisión, y las frecuencias subsiguientes se asignan a los canales de televisión en intervalos de 6 MHz. Se asignan 310 MHz y las frecuencias subsiguientes a los canales radioeléctricos a intervalos de 1 MHz. Cada uno de los canales anteriores se puede usar ya sea para difusión analógica o difusión digital. En el caso de difusión digital, se transmiten datos en un formato de paquete de transporte de acuerdo con la especificación MPEG2 , caso en el cual los datos propuestos para varios sistemas de difusión de datos se pueden transmitir, además de datos de audio y vídeo. El centro distribuidor 101 está equipado con una unidad de modulación de QPSK, una unidad de modulación de QAM, y similares a fin de transmitir señales de difusión adecuadas a los respectivos intervalos de frecuencia. Además, el centro distribuidor 101 está equipado con una unidad de desmodulación de QPSK para recibir datos de los aparatos terminales . También, el centro distribuidor 101 se asume que está equipado además con varios dispositivos relacionados a las unidades de modulación anteriores y la unidad de desmodulación. Sin embargo, se omiten explicaciones detalladas de éstos, puesto que la presente invención se refiere principalmente a los aparatos terminales. El aparato terminal Allí, el aparato terminal B112, y el aparato terminal C113 reciben y reproducen señales de difusión transmitidas desde el centro distribuidor 101. Adicionalmente, el aparato terminal Allí, el aparato terminal B112 y el aparato terminal C113 transmiten datos únicos a cada aparato terminal al centro distribuidor 101. En la presente modalidad, estos tres aparatos terminales deben tener la misma configuración. La Figura 5 es un diagrama de bloques que muestra una configuración de equipo de cómputo de cada aparato terminal. Un aparato terminal 500 incluye una unidad 501 de desmodulación de QAM, una unidad 502 de desmodulación de QPSK, una unidad 503 de desmodulación de QPSK, un descodificador 505 de QPSK, un descodificador 506 de audio, un altavoz 507, un descodificador 508 de video, un aparato de visualización 509, una unidad 510 secundaria de almacenamiento, una unidad 511 primaria de almacenamiento, una ROM 512, una unidad 513 de entrada, y una CPU 514. Además, un POD 504 se puede unir a y/desprender del aparato terminal 500. La Figura 6 muestra una televisión de perfil delgado, que es una vista externa de ejemplo del aparato terminal 500. El aparato terminal puede venir en una variedad de configuraciones, pero en la presente modalidad, se describe como un ejemplo un aparato terminal que se configura en base a OpenCable(MR> y OCAP. Un alojamiento 601 de una televisión de perfil delgado, contiene todos los elementos constituyentes del aparato terminal 500, excepto por el POD 504. Un aparato de visualización 602 corresponde al aparato de visualización 509 en la Figura 5. Una unidad 603 de panel frontal está constituida de varios botones y corresponde a la unidad 513 de entrada en la Figura 5. Una terminal 604 de entrada de señal se conecta a una línea de cable para transmitir/recibir señales hacia y desde el centro distribuidor 101. Además, la terminal 604 de entrada de señal se conecta a la unidad 501 de desmodulación de QPSK, la unidad 502 de desmodulación de QPSK, y la unidad 503 de modulación de QPSK mostrada en la Figura 5. Una tarjeta 605 de POD corresponde al POD 504 en la Figura 5. El POD 504 se incorpora independientemente del aparato terminal 500 y se puede unir a/desprender del aparato terminal 500, como en el caso de la tarjeta 605 de POD en la Figura 6. Se da más adelante una explicación más detallada del POD 504. Una ranura 606 de inserción es una ranura de inserción en la cual se inserta la tarjeta 605 de POD. Con referencia a la Figura 5, la unidad 501 de desmodulación de QAM desmodula una señal que se ha QAM-modulado en y transmitido desde el centro distribuidor 101, de acuerdo a la información de sintonización que incluye una frecuencia especificada por la CPU 514, y pasa el resultado al POD 504. La unidad 502 de desmodulación de QPSK desmodula una señal que se ha QPSK-desmodulado en y transmitido desde el centro distribuidor 101, de acuerdo a la información de sintonización que incluye una frecuencia especificada por la CPU 514, y pasa el resultante al POD 504. La unidad 503 QPSK QPSK-desmodula una señal pasada desde el POD 504, de acuerdo a la información de desmodulación que incluye una frecuencia especificada por la CPU 514, y trasmite la resultante al centro distribuidor 101. Como se muestra en la Figura 6, el POD 504 es desprendible del cuerpo principal del aparato terminal 500. La definición de la interfaz de conexión entre el cuerpo principal de la terminal 500 y el POD 504 se da en la especificación de interfaz de OpenCable (MR) CableCARD (MR) (OC-SP-CC-IF-I15-031121) y en especificaciones referidas por esta especificación. Se señala que CableCARD en esta especificación se refiere a un POD. Aquí, se omite una descripción detallada, y se da sólo una explicación de las porciones pertinentes a la presente invención. La Figura 7 es un diagrama de bloques que muestra una configuración interna del POD 504. El POD 504 está constituido de una primera unidad 701 desencriptadora, una segunda unidad 702 desencriptadora, una unidad 703 desencriptadora, una unidad 704 primaria de almacenamiento, una unidad 705 secundaria de almacenamiento, y una CPU 706. La primera unidad desencriptadora 701, bajo instrucción de la CPU 706, recibe una señal encriptada de la unidad 501 de desmodulación de QAM del aparato terminal 500 y desencripta esta señal. Entonces, la primera unidad desencriptadora 701 transmite la señal desencriptada al descodificador 505 de TS del aparato terminal 500. La información requerida para desencriptar esta clave se proporciona por la CPU 706 conforme sea necesario. De manera más específica, el centro distribuidor 101 difunde varios canales de paga, y cuando el usuario compra el derecho para ver estos canales de paga, la primera unidad 701 desencriptadora recibe información requerida tal como una clave de la CPU 706 y realiza la desencriptación, y el usuario es capaz de ver estos canales de paga. Cuando no se proporciona la información requerida tal como una clave, la primera unidad 701 desencriptadora pasa la señal recibida directamente al descodificador 505 de TS sin realizar el desencriptado . La segunda unidad 702 desencriptadora, bajo instrucción de la CPU 706, recibe una señal encriptada de la unidad 502 de desmodulación de QPSK del aparato terminal 500 y desencripta esta señal. Entonces, la segunda unidad 702 desencriptadora pasa los datos desencriptados a la CPU 706. La unidad encriptadora 703, bajo la instrucción de la CPU 706, encripta los datos recibidos de la CPU 706 y envía la resultante a la unidad 503 de modulación de QPSK del aparato terminal 500. La unidad 704 primaria de almacenamiento, constituida específicamente de una memoria primaria tal como la RAM, se utiliza para almacenar datos temporalmente cuando la CPU 706 realiza el procesamiento. La unidad 705 secundaria de almacenamiento, constituida específicamente de una memoria secundaria de almacenamiento tal como una ROM flash, se utiliza para almacenar un programa que se va a ejecutar por la CPU 706 así como para almacenar datos que no se deben suprimir aún cuando se desconecte la energía. La CPU 706 ejecuta el programa almacenado en la unidad 705 secundaria de almacenamiento. El programa está constituido de varios subprogramas. La Figura 8 muestra un ejemplo del programa almacenado en la unidad 705 secundaria de almacenamiento. En la Figura 8, un programa 800 está constituido de subprogramas plurales que incluyen un programa principal 801, un subprograma 802 de inicialización, un subprograma 803 de red, un subprograma 804 de reproducción, y un subprograma 805 de PPV. Aquí, el PPV, que es una abreviación de Pago Por Ver, se refiere a un servicio que permite al usuario ver un cierto programa tal como una película, en base a un cargo. Cuando el usuario introduce su número de identificación personal, se notifica la compra del derecho para ver el programa al centro distribuidor 101, se cancela la encriptación, y este programa se puede ver por el usuario. Con esta visión, se le requiere al usuario que pague el precio de compra en una fecha posterior. El programa principal 801, que es el subprograma activado primero por la CPU 706 cuando se conecta la energía, controla los otros subprogramas . El subprograma 802 de inicialización, que se activa por el programa principal 801 cuando se activa la energía, realiza el intercambio de información con el aparato terminal 500 y realiza la inicialización. Este procesamiento de inicialización se define en detalle en la especificación de interfaz de OpenCable (MR) CableCARD (MR) (OC-SP-CC-IF-I15-031121) y en especificaciones que se refieren a esta especificación. Además, el subprograma 802 de inicialización también realiza el procesamiento de inicialización no definido en estas especificaciones. Aquí, se introduce una parte de este procesamiento de inicialización. Cuando se enciende la energía, el subprograma 802 de inicialización notifica a la unidad 502 de desmodulación de QPSK de una primera frecuencia almacenada en la unidad 705 secundaria de almacenamiento mediante la CPU 514 del aparato terminal 500. La unidad 502 de desmodulación de QPSK realiza la sintonía usando la primera frecuencia proporcionada, y transmite la señal resultante a la unidad 702 encriptadora secundaria. Además, el subprograma 802 de inicialización proporciona a la unidad 702 desencriptadora secundaria con información de desencriptación tal como una primera clave almacenada en la unidad 705 secundaria de almacenamiento. Como resultado, la unidad 702 desencriptadora secundaria realiza la desencriptación y pasa la resultante a la CPU 706 ejecutando el subprograma 802 de inicialización.

Como tal, el subprograma 802 de inicialización puede recibir la información. En la presente modalidad, el subprograma 802 de inicialización recibe información mediante el subprograma 803 de red. Se da más adelante una descripción detallada de esto. Adicionalmente, el subprograma 802 de inicialización notifica a la unidad 503 de modulación de QPSK de una segunda frecuencia almacenada en la unidad 705 secundaria de almacenamiento mediante la CPU 514 del aparato terminal 500. El subprograma 802 de inicialización proporciona a la unidad 703 encriptadora con la información de encriptación almacenada en la unidad 705 secundaria de almacenamiento. Cuando el subprograma 802 de inicialización proporciona, mediante el subprograma 803 de red, a la unidad encriptadora 703 con información requerida para ser enviada, la unidad 703 encriptadora encripta los datos usando la información de encriptación proporcionada, y proporciona los datos encriptados a la unidad 503 de modulación de QPSK. La unidad 503 de modulación de QPSK modula la información encriptada que recibe, y envía la información modulada al centro distribuidor 101. Como resultado, llega a ser posible que el subprograma 802 de inicialización lleve a cabo una comunicación bidireccional con el centro distribuidor 101 mediante el aparato terminal 500, la unidad desencriptadora secundaria 702, la unidad encriptadora 703, y el subprograma 803 de red. El subprograma 803 de red, que se usa por subprogramas plurales tal como el programa principal 801 y el subprograma 802 de inicialización, es un subprograma propuesto para llevar a cabo una comunicación bidireccional con el centro distribuidor 101. De manera más específica, el subprograma 803 de red se comporta como si otros subprogramas que usan el subprograma 803 de red estuvieran llevando a cabo una comunicación bidireccional con el centro distribuidor 101 de acuerdo con TCP/IP. Se omite aquí una descripción detallada de TCP/IP, puesto que es una técnica públicamente conocida para especificar los protocolos que se van a usar cuando se intercambia información entre terminales plurales. Cuando se activa por el subprograma 802 de inicialización en el momento del encendido, el subprograma 803 de red notifica, mediante el aparato terminal 500, al centro distribuidor 101 de una dirección de MAC (una abreviación de Dirección de Control de Acceso de Medio) que es un identificador para identificar el POD 504 y que se almacena en la unidad 705 secundaria de almacenamiento de antemano, para la petición para la obtención de una dirección IP. El centro distribuidor 101 notifica al POD 504 de la dirección IP mediante el aparato terminal 500, y el subprograma 803 de red almacena esta dirección IP en la unidad 704 primaria de almacenamiento. De aquí, el centro distribuidor 101 y el POD 504 se comunican entre sí usando esta dirección IP como el identificador del POD 504. El subprograma 804 de reproducción proporciona a la primera unidad 701 desencriptadora con la información de desencriptación tal como una segunda clave almacenada en la unidad 705 secundaria de almacenamiento así como la información de desencriptación tal como una tercera clave proporcionada por el aparato terminal 500, para permitir que se realice el desencriptado. Además, el subprograma 804 de reproducción recibe, mediante el subprograma 803 de red información que indica que la señal introducida en la primera unidad desencriptadora 701 es un canal de PPV. En la notificación que la señal es un canal de PPV, el subprograma 804 de reproducción activa el subprograma 805 de PPV. Cuando se activa, el subprograma 805 de PPV exhibe, en el aparato terminal 500, un mensaje que avisa al usuario de la compra del programa, y tiene acceso a una entrada del usuario. De manera más específica, cuando la información propuesta para ser exhibida en la pantalla se envía a la CPU 514 del aparato terminal 500, un programa que corre en la CPU 514 del aparato terminal 500 muestra el mensaje en la pantalla 509 del aparato terminal 500. Entonces, cuando el usuario introduce el número de identificación personal mediante la unidad 513 de entrada del aparato terminal 500, la CPU 514 del aparato terminal 500 lo acepta, y lo envía al subprograma 805 de PPV que corre en la CPU 706 del POD 504. El subprograma 805 de PPV envía, al centro distribuidor 101, el número de identificación personal aceptado mediante el subprograma 803 de red. Cuando este número de identificación personal es válido, el centro distribuidor 101 notifica, mediante el subprograma 803 de red, al subprograma 805 de PPV de la información de desencriptación requerida para desencriptar esta cuarta clave. El subprograma 805 de PPV proporciona a la primera unidad desencriptadora 701 con la información de desencriptación aceptada tal como la cuarta clave, y entonces la primera unidad 701 desencriptadora desencripta la señal que se introduce. Con referencia a la Figura 5, el descodificador 505 de TS realiza la filtración de la señal aceptada del POD 504, y pasa los datos necesarios al descodificador de audio 506, el descodificador 508 de video, y la CPU 514. Aquí, la señal enviada desde el POD 504 es una corriente de transporte de MPEG2. Se da una descripción detallada acerca de una corriente de transporte de MPEG2 en la especificación de MPEG ISO/IEC138181-1, y por lo tanto se debe omitir la explicación detallada en la presente modalidad. Una corriente de transporte de MPEG2 se compone de varios paquetes de longitud fija, y una ID de paquetes se asigna a cada paquete. La Figura 9 es un diagrama que muestra la estructura de un paquete. 900 es un paquete estructurado por 188 bytes que tiene longitud fija. Los cuatro bytes superiores son un encabezado 901 que almacena información para identificar el paquete, los 184 bytes restantes son una carta útil 902 que contienen la información que se va a transmitir. 903 muestra la descomposición del encabezado 901. Una ID de paquetes se incluye en los 13 bits del doceavo al veinticuatroavo bit desde la parte superior. La Figura 10 es un diagrama esquemático que ilustra las cadenas plurales de paquetes que se van a transmitir. Un paquete 1001 transporta una ID de paquete "1" en su encabezado e incluye la primera información del video A en su carga útil. Un paquete 1002 tiene una ID de paquete "2" en su encabezado e incluye la primera información del audio A en su carga útil. Un paquete 1003 tiene una ID de paquete "3" en su encabezado incluye la primera información del audio B en su carga útil. Un paquete 1004 tiene la ID "1" de paquete en su encabezado en incluye la segunda información del video A en su carga útil, y es la continuación del paquete 1001. De manera similar, los paquetes 1005, 1026 y 1027 tienen los datos de seguimiento de los otros paquetes. Al concatenar los contenidos de las cargas útiles de los paquetes con las mismas ID de los paquetes de la manera anterior, es posible reproducir un video y audio continuo. Con referencia a la Figura 10, cuando la CPU 514 indica, a el descodificador 505 de TS, la ID "1" de paquete así como "el descodificador 508 de video" como un destino de salida, el descodificador 505 de TS extrae los paquetes de la ID "1" de paquete de la corriente de transporte de MPEG2 recibida del POD 504, y los pasa al descodificador 508 de video. En la Figura 10, por lo tanto, sólo se pasan los datos de video sobre el descodificador 508 de video. Al mismo tiempo, cuando la CPU 514 lo indica, al descodificador 505 de TS, la ID "2" de paquete así como "el descodificador 505 de audio", el descodificador TS extrae los paquetes con la ID "2" de paquete de la corriente de transporte de MPEG2 recibida del POD 504, y los pasa al descodificador 506 de audio. En la Figura 10, sólo se pasan los datos de audio sobre el descodificador 508 de video. Este proceso de extraer sólo los paquetes necesarios de acuerdo a las ID de los paquetes corresponde a la filtración realizada por el descodificador 505 de TS . El descodificador 505 TS es capaz de realizar más de un procesamiento de filtración de información simultánea, en la instrucción de la CPU 514. Con referencia a la Figura 5, el descodificador 506 de audio concatena los datos de audio incrustados en los paquetes en la corriente de transporte de MPEG2 proporcionada pro el descodificador 505 de TS, realiza la conversión de digital a analógico en los datos concatenados, y transfiere la resultante al altavoz 507.

El altavoz 507 realiza la salida de audio de la señal proporcionada por el descodificador 506 de audio. El descodificador 508 de video concatena los datos de video incrustados en los paquetes en la corriente de transporte de MPEG2 proporcionada por el descodificador 505 de TS, realiza la conversión de digital a analógico en los datos concatenados, y transfiere la resultante a la pantalla 509. La pantalla 509, configura de forma específica de un CRT o un cristal líquido y similar, produce la señal de video proporcionada por el descodificador 508 de video y exhibe un mensaje especificado por la CPU 514, y así sucesivamente. La unidad 510 secundaria de almacenamiento, constituida específicamente de una memoria instantánea o un disco duro y similar, almacena y suprime los datos y programas especificados por la CPU 514. Los datos y programas almacenados se refieren por la CPU 514. Los datos y programas almacenados se mantienen en almacenamiento aún cuando se corte la energía al aparato terminal 500. La unidad 511 primaria de almacenamiento, constituido específicamente de una RAM y similar almacena y suprime temporalmente datos y programas especificados por la CPU 514. Los datos y programas almacenados se refieren por la CPU 514, los datos y programas almacenados se suprimen cuando se corta la energía al aparato terminal 500. La ROM 512 es un dispositivo de memoria de lectura únicamente, específicamente constituido de una ROM, un CD-ROM, o un DVD, y similares. La ROM 512 almacena un programa que se va a ejecutar por la CPU 514. La unidad 513 de entrada, constituida específicamente en un panel frontal o control remoto, acepta una entrada del usuario. La Figura 11 muestra un ejemplo de la unidad 513 de entrada en el caso donde se configura en la forma de un panel frontal. 1100 es un panel frontal, que corresponde a la unidad 603 de panel frontal mostrada en la Figura 6. Este panel frontal 1100 está constituido de siete botones: un botón 1101 de cursor hacia arriba, un botón 1102 de cursor hacia abajo, un botón 1103 de cursor hacia la izquierda, un botón 1104 de cursor a la derecha, un botón 1105 de ACEPTAR, un botón 1106 de cancelar, y un botón 1107 de EPG. Cuando el usuario presiona un botón, el identificador de este botón presiona se notifica a la CPU 514. La CPU 514 ejecuta el programa almacenado en la ROM 512. Siguiendo las instrucciones del programa que se va a ejecutar, la CPU 514 controla la unidad 501 de desmodulación de QAM, la unidad 502 de desmodulación de QPSK, la unidad 503 de modulación de QPSK, el POD 504, el descodificador 505 de TS; la pantalla 509, la unidad secundaria 510 de almacenamiento, la unidad primaria 511 de almacenamiento, y la ROM 512. La Figura 12 es un diagrama que muestra una estructura de ejemplo del programa que se almacena en la ROM 512 y se ejecuta por la CPU 514. Un programa 1200 está constituido de varios subprogramas. Para ser más específicos, el programa 1200 está constituido de un OS 1201, un EPG 1202, un JavaVM 1203, un gestor de servicio 1204, y una biblioteca Java 1205. El OS 1201 es un subprograma activado por la CPU 154 cuando se enciende la energía al aparato terminal 500. El OS 1201 significa sistema operativo, un ejemplo del cual es Linux y similares. El OS 1201 es un nombre genérico para tecnología públicamente conocida constituida de un núcleo 1201a para ejecutar un subprograma en paralelo con otro subprograma y de una biblioteca 1201b, y por lo tanto se omite una explicación detallada. En la presente modalidad, el núcleo 1201a del OS 1201 ejecuta la EPG 1202 y la JavaVM 1203 como subprogramas. Entre tanto, la biblioteca 1201b proporciona estos subprogramas con funciones plurales requeridas para controlar los elementos constituyentes del aparato terminal 500. Aquí, se introduce la sintonía como un ejemplo de estas funciones. En la función de sintonía, la información de sintonía que incluye una frecuencia se recibe de otro subprograma y entonces se pasa sobre la unidad 501 de desmodulación de QAM. Por consiguiente, es posible que la unidad 501 de desmodulación de QAM realice la desmodulación en base a la información de sintonía proporcionada, y pase los datos desmodulados al POD 504. Como resultado, los otros subprogramas pueden controlar la unidad de desmodulación de QAM mediante la biblioteca 1201b. La EPG 1202 está constituida de una unidad 1202a de visualización de programa para visualizar una lista de programas al usuario así como para aceptar una entrada del usuario, y una unidad de reproducción 1102b para seleccionar canales. Aquí, EPG es una abreviación de Guía Electrónica de Programas. La EPG 1202 se activa cuando se enciende la energía al aparato terminal 500. En la EPG 1202 activada, la unidad 1202a de visualización de programas espera una entrada del usuario mediante la unidad 513 de entrada del aparato terminal 500. Aquí, en el caso donde la unidad 513 de entrada tome la forma del panel frontal ilustrado en la Figura 11, cuando el usuario presiona el botón 1107 de EPG en la unidad 513 de entrada, la CPU 514 se notifica del identificador de este botón de EPG. La unidad 1202a de visualización de programas de la EPG 1202, que es un subprograma que corre en la CPU 514, acepta este notificador y muestra la información de programa en la pantalla 509. La Figura 13A y la Figura 13B muestran un ejemplo de una tabla de programa exhibida en la pantalla 509. Con referencia a la Figura 13A; la información de programa se exhibe en la pantalla 509 en un patrón de rejillas. Una columna 1301 describe la información de tiempo. Una columna 1302 describe un nombre de canal "Canal 1" y los programas que se van a difundir durante los periodos de tiempo que corresponden a los respectivos tiempos descritos en la columna 1301. Se muestra que un programa "Noticias 9" se difunde desde 9:00 a 10:30, y "Cinema AAA" se difunde desde 10:30 a 12:00 en el "Canal 1". Una columna 1303 describe un nombre de canal "Canal 2" y los programas que se van a difundir durante los periodos de tiempo que corresponden a los respectivos tiempos descritos en la columna 1301, como en el caso de la columna 1302. Un programa "Cinema BBB" se difunde desde las 9:00 a las 11:00, y "Noticias 11" se difunde desde 11:00 a 12:00. 1330 es un cursor. El cursor 1330 se mueve en la presión del cursor a la izquierda 1103 o el cursor a la derecha 1104 en el panel frontal 1100. Cuando se presiona el cursor a la derecha 1104 en el estado ilustrado en la Figura 13A, el cursor 1330 se mueve hacia la derecha como se muestra en la Figura 13B. Entre tanto, cuando se presiona el cursor a la izquierda 1103 en el estado listado en la Figura 13B, el cursor 1330 se mueve hacia la izquierda como se muestra en la Figura 13A. Cuando se presiona el botón 1105 de ACEPTAR en el panel frontal 1100 en el estado mostrado en la Figura 13A, la unidad 1202a de visualización de programas notifica a la unidad 1102b de reproducción del identificador de "Canal 1". Entre tanto, cuando se presiona el botón 1105 de ACEPTAR en el panel frontal 1100 en el estado mostrado en la Figura 13B, la unidad 1202a de visualización de programas notifica a la unidad 1102b de reproducción del identificador de "Canal 2". Adicionalmente, la unidad 1202a de visualización de programas almacena temporalmente la información de programas que se van a exhibir desde el centro distribuidor 101 en la unidad 511 primaria de almacenamiento mediante el POD 504. En general, toma tiempo obtener la información del programa del centro distribuidor. Sin embargo, llega a ser posible exhibir rápidamente una tabla de programas al exhibir la información de programas que está pre-almacenada en la unidad 511 de almacenamiento primaria al presionar el botón 1107 de EPG de la unidad 513 de entrada. La unidad 1102b de reproducción reproduce el canal usando el identificador recibido del canal. La relación entre los identificadores de canal y los canales que pre-almacena por la unidad 510 de almacenamiento secundaria como la información de canal. La Figura 14 muestra un ejemplo de la información de canal almacenada en la unidad 510 de almacenamiento secundaria . La información de canal se almacena de forma tabular. Una columna 1401 describe los identificadores de los canales. Una columna 1402 describe los nombres de los canales. Una columna 1403 describe la información de sintonía. Aquí, la información de sintonía se representa por valores que se van a proporcionar a la unidad 501 de desmodulación de QAM tal como frecuencia, velocidad de transmisión, relación de codificación. Una columna 1404 describe números de programas . Los números de programas son números usados para identificar los PMT definidos por la norma de MPEG2. Una descripción acerca de PMT se da más adelante . Cada una de las líneas 1411 ~ 1414 indica un conjunto del identificador, nombre de canal e información de sintonía de cada canal. La línea 1411 describe un conjunto que incluye "1" como un identificador, "Canal 1" como un nombre de canal, una frecuencia de "312 MHz" como la información de sintonía, y "101" como un número de programa. La unidad 1102b de reproducción pasa al identificador del canal recibido directamente al gestor de servicio a fin de reproducir el canal . Además, cuando el usuario presiona el cursor hacia arriba 1101 y el cursor hacia abajo 1102 en el panel frontal 1100 en tanto que está tomando lugar la reproducción, la unidad 1102b de reproducción recibe una notificación acerca de esta selección del usuario de la unidad 513 de entrada mediante la CPU 514, y conmuta el canal que se reproduce a otro. Primero, la unidad 1102b de reproducción almacena, en la unidad 511 primaria de almacenamiento, el identificador del canal que actualmente se está reproducción. Las Figuras 15A, 15B y 15C muestran identificadores de ejemplo de canales almacenados en la unidad 511 primaria de almacenamiento. La Figura 15A muestra que se almacena un identificador "3" y la referencia en la Figura 14 se muestra que se está reproduciendo un canal con el nombre de canal "TV 3". Cuando el usuario presiona el cursor hacia arriba 1101 en un estado ilustrado en la Figura 15A, la unidad 1102b de reproducción se refiere a la información de canal mostrado en la Figura 14, y pasa el identificador "2" de un canal con el nombre de canal de "Canal 2" al gestor de servicio a fin de reproducir nuevamente un canal con el nombre de "Canal 2", que es el canal anterior en la tabla. Al mismo tiempo, la unidad 1102b de reproducción vuelve a escribir el identificador en el identificador de canal "2" almacenado en la unidad 511 primaria de almacenamiento. La Figura 15B muestra este identificador de canal re-escrito. Entre tanto, cuando el usuario presiona el cursor hacia abajo 1102 en el estado ilustrado en la Figura 15A, la unidad 1102b de reproducción se refiere a la información de canal mostrado en la Figura 14, y pasa el identificador "4" de un canal con el nombre de canal de "TV Japón" al gestor de servicio a fin de reproducir nuevamente un canal con el nombre de canal de "TV Japón", que es el siguiente canal en la tabla. Al mismo tiempo, la unidad 1102b de reproducción reescribe el identificador en el identificador "4" de canal almacenado en la unidad 511 primaria de almacenamiento. La Figura 15C muestra este identificador de canal reescrito. La JavaVM 1203 es una máquina virtual Java que analiza y ejecuta secuencialmente programas escritos en lenguaje Java (MR) . Los programas escritos en el lenguaje Java se compilan en códigos intermedios conocidos como códigos de bytes que no dependen del equipo . La máquina virtual Java es un interpretador que ejecuta estos códigos de bytes. Algunas de las máquinas virtuales Java traducen los códigos de bytes en una forma ejecutable que se pueden interpretar por la CPU 514 y pasa la resultante a la CPU 514, que lo ejecuta. La JavaVM 1203 se activa, con un programa Java que se ejecute que se especifique por el núcleo 1201a. En la presente modalidad, el núcleo 1201a especifica el gestor de servicio 1204 como un programa Java que se va a ejecutar. Un comentario detallado del lenguaje Java se da en muchos libros que incluyen "Java Language Specification" (ISBN 0-201-63451-1) . Por lo tanto, se omite aquí una descripción detallada acerca de esto. También, se da un comentario de la operación de la JavaVM mismas en muchos libros, que incluyen "Java Virtual Machine Specification" (ISBN 0-201-63451-X) . Por lo tanto, se omite aquí una descripción detallada acerca de esto. El gestor del servicio 1204, que es un programa Java escrito en lenguaje Java, se ejecuta por la JavaVM 1203 de forma secuencial. Es posible que el gestor 1204 de servicio llame y se llame por otro subprograma no escrito en el lenguaje Java a través de la JNI (interfaz nativa Java) . Un complementario en la JNI se da en muchos libros que incluyen "interfaz nativa Java". Por lo tanto, se omite en la presente una descripción detallada acerca de esto. El gestor 1204 de servicio acepta el identificador del canal de la unidad 1102b de reproducción a través de la JNI. Primero, el gestor 1202 de servicio pasa el identificador del canal a un sintonizador 1205c en la biblioteca 1205 Java para pedir la sintonización. El sintonizador 1205c se refiere a la información de canal almacenada en la unidad 510 secundario de almacenamiento para obtener la información de sintonización. Asumiendo que el gestor 1204 de servicio pasa el identificador "2" del canal al sintonizador 1205c, el sintonizador 1205c se refiere a la columna 1412 mostrada en la Figura 14, y obtiene la información de sintonización "156MHz", que corresponde al canal. El sintonizador 1205c pasa la información de sintonización a la unidad 501 de desmodulación de QAM mediante la biblioteca 1201b del OS 1201. La unidad 501 de desmodulación de QAM desmodula la señal enviada desde el centro distribuidor 101 de acuerdo a la información de sintonización dada a la unidad 501 de desmodulación de QAM, y pasa la señal resultante al POD 504. Entonces, el gestor 1204 de servicio pide un CA 1205b dentro de la biblioteca Java 1205 para realizar la desencriptación. El CA 1205d proporciona el POD 504 con la información requerida para desencriptar a través de la biblioteca 1201b en el OS 1201. En base a esta información proporcionada, el POD 504 desencripta la señal proporcionada por la unidad 501 de desmodulación de QAM, y pasa la señal resultante al descodificador 505 de TS. Entonces, el gestor 1204 de servicio proporciona un JMF 1205a dentro de la biblioteca java 1205 con el identificador del canal, para pedir la reproducción del video y audio. Primero, el JMF 1205a obtiene, de una PAT y de una PMT, las ID de los paquetes usadas para especificar el video y audio que se va a reproducir. La PAT y la PMT son tablas definidas por la norma MPEG2 que muestran la alineación del programa incluida en una corriente de transporte de MPEG2. La PAT y la PMT se transportan en las cargas útiles en los paquetes incluidos en una corriente de transporte MPEG2 , junto con video y audio. Referirse a la especificación para una descripción detallada de PAT y PMT. Aquí, sólo se da una vista general de PAT y PMT. La PAT, que es una abreviación de tabla de asociación de programas, se transporta en los paquetes con la ID "0" del paquete. A fin de obtener la PAT, el JMF 1205a indica, al descodificador 505 de TS, la ID "0" del paquete y la CPU 514 a través de la biblioteca 1201b del OS 1201. Entonces, el descodificador 505 de TS realiza la filtración en base a la ID "0" del paquete, y pasa la resultante a la CPU 514. Por consiguiente, el JMF 1205a puede recolectar los paquetes de PAT. La Figura 16 ilustra una tabla que muestra esquemáticamente un ejemplo de la información recolectada de PAT. Una columna describe los números de programa. Una columna 1602 describe las ID de paquete. Las ID de paquete mostradas en la columna 1602 se usan para obtener la PAT. Cada una de las líneas 1611 ~ 1613 es un par del número de programa de un canal y una ID de paquete que le corresponde. Aquí, se definen tres canales. La línea 1611 define un par del número "101" de programa y la ID "501" de paquete. Asumiendo que el identificador de canal proporcionado al JMF 1205a es "w" y el JMF 1205a se refiere a la columna 1412 en la Figura 14, para obtener el número "102" de programa que corresponde a cada identificador de canal, y entonces se refiere a la columna 1612 en la PAT mostrada en la Figura 16, para obtener el ID "502" de paquete que corresponde al número "102" de programa. La PMT, que es una abreviación de tabla de correlación de programas, se transporta en los paquetes con las ID de paquete especificadas en las PAT. A fin de obtener la PMT, el JMF 1205a indica, al descodificador 505 de TS, una ID de paquete y la CPU 514 a través de la biblioteca 1201b del OS 1201. Aquí, una ID de paquete que se va a especificar es "502". Entonces, el descodificador 505 de TS realiza la filtración en base a la ID "502 de paquete, y pasa la resultante a la CPU 514. Por consiguiente, el JMF 1205a puede recolectar los paquetes de PMT. La Figura 17 ilustra una tabla que muestra esquemáticamente un ejemplo de la información de PMT recolectada. Una columna 1701 describe los tipos de corriente. Una columna 1702 describe las ID de paquete. La información especificada en los tipos respectivos de corriente se transporta en las cargas útiles de los paquetes con las ID de paquete especificadas en la columna 1702. Una columna 1703 describe información adicional. Cada una de las filas 1711 ~ 1714 es un par de una ID de paquete y el tipo de información que se transmite, que se conoce como una corriente elemental. La fila 1711, que es un par del tipo "audio" de corriente y la ID "5011" de paquete, indica que los datos de audio se almacenan en la carga útil del paquete con la ID "5011" de paquete. El JMF 1205a obtiene, de la PMT, las ID de paquete del video de audio que se va a reproducir. Con referencia a la Figura 17, el JMF 1205a obtiene la ID "5011" de paquete de audio de la línea 1711, y la ID "5012" de paquete de video de la línea 1712. Entonces, el JMF 1205a proporciona el descodificador 505 de TS con pares de la ID de paquete de audio obtenida y el descodificador 506 de audio como un destino de salida así como la ID de paquete de video y el descodificador 508 de video como un destino de salida, mediante la biblioteca 1201b del OS 1201. El descodificador 505 de TS realiza la filtración en base a estas ID de paquete proporcionadas y en base a los destinos de salida. Aquí, el paquete con la ID "5011" de paquete se pasa al descodificador 506 de audio y el paquete con la ID "5012" de paquete se pasa al descodificador 508 de video. El descodificador 506 de audio realiza la conversión de digital a analógico en el paquete proporcionado, para reproducir el audio mediante el altavoz 507. El descodificador 508 de video realiza la conversión de digital a analógico en el paquete proporcionado, para exhibir el video en la pantalla 509. Finalmente, el gestor 1204 de servicio proporciona el identificador de canal a un AM 1205b en la biblioteca 1205 Java, para pedir la reproducción de la difusión de datos. Aquí, la reproducción de la difusión de datos significa extraer un programa Java incluido en la corriente de transporte MPEG2 y hace que la JavaVM 1203 lo ejecute. Como una técnica para incrustar un programa Java en una corriente de transporte de MPEG2 , se usa un método conocido como DSMCC, que se describe en la especificación ISO/IEC138181-6 de MPEG. Se omite en la presente una explicación detallada de DSMCC. La sintonización de DSMCC define un método para descodificar un sistema de archivos comprendido de directorios y archivos usados por una computadora, en paquetes dentro de una corriente de transporte de MPEG2. La información acerca del programa Java que se va a ejecutar se transporta en paquetes en la corriente de transporte de MPEG2 en la forma de AIT. La AIT es una abreviación de tabla de información de aplicación cuya definición se da en el décimo capítulo de la norma DVB-MHP (anteriormente conocida como especificación Vi.0.2 de ETSI TS 101 812) . Primero, a fin de obtener la AIT, el AM 1205b obtiene la PAT y la PMT como en el caso del JMF 1205a, para obtener la ID de paquete del paquete que almacena la AIT. Asumiendo que "2" es el identificador de canal proporcionado y que la PAT mostrada en la Figura 16 y la PMT mostrada en la Figura 17 se están transmitiendo, el AM 1205b obtiene la PMT mostrada en la Figura 17 de acuerdo al mismo procedimiento seguido por el JMF 1205a. De manera subsiguiente, el AM 1205b se extrae, de la PMT, la ID de paquete de la corriente elemental cuyo tipo de corriente es "dato" y que tiene "AIT" como información adicional. Como se muestra en la Figura 17, la corriente elemental en la línea 1713 corresponde a esta corriente elemental, y por lo tanto, el AM 1205b obtiene la ID "5013" de paquete de éste. El AM 1205b proporciona el descodificador 505 de TS con la ID de paquete de la AIT y de la CPU 514 como un destino de salida a través de la biblioteca 1201b del OS 1201. Entonces, el descodificador 505 de TS realiza la filtración en base a esta ID de paquete proporcionada, y pasa la resultante a la CPU 514. Por consiguiente, el AM 1205b puede recolectar los paquetes de la AIT. La Figura 18 es una tabla que muestra esquemáticamente un ejemplo de la información de AIT recolectada. Una columna 1801 describe identificadores de programas Java. De acuerdo a la especificación de MHP, estos identificadores se definen como ID de aplicación, que identifican si un programa Java es un programa que se debe autenticar por un gestor 1205f de seguridad del aparato 500 terminal . No se requiere autenticación cuando el valor de un identificador está en el intervalo de 0x0 a 0.x3fff, en tanto que se requiere autenticación cuando el valor de un identificador está en el intervalo de 0x4000 a 0x7fff. Un programa Java cuyo valor de identificador cae dentro del intervalo anterior se refiere como un "programa no signado" y un programa Java cuyo valor de identificador. Cae dentro del intervalo último se refiere como un "programa signado" . Una columna 1802 describe la información de control para controlar los programas Java. La información de control incluye "autoinicio" , "presente", y "aniquilación". "Autoinicio significa que el aparato terminal 500 ejecuta automáticamente el programa prontamente. "Presente" significa que el programa no se ejecuta de forma automática. "Aniquilación" significa que el programa se va a terminar. Una columna 1803 describe los identificadores de DSMCC usados para extraer las ID de paquete que incluyen los programas Java en el formato de DSMCC. Una columna 1804 describe los nombres de programa de los programas Java. Cada una de las filas 1811 y 1812 es un conjunto de información acerca de un programa Java. El programa Java definido en la fila 1811 es un conjunto de un identificador "301", información de control "autoinicio", un identificador "1" de DSMCC, y un nombre de programa "a/TopXlet". El programa Java definido en la fila 1812 es un conjunto de un identificador "302", información de control "presente", un identificador "1" de DSMCC, un nombre de programa "b/GameXlet" . Aquí, estos dos programas Java tienen el mismo identificador de DSMCC. Esto indica que se incluyen dos programas Java en el sistema de archivos que se han codificado de acuerdo al mismo método de DSMCC. Aquí, sólo se especifican cuatro puntos de información para los respectivos programas Java, pero se especifican más puntos de información en realidad. Referirse a la especificación de DVB-MHP para detalle. El AM 1205b encuentra el programa Java "autoinicio" de la AIT, y extrae el identificador de DSMCC correspondiente y el nombre de programa Java. Con referencia a la Figura 18, el AM 1205b extrae el programa Java en la línea 1811, y obtiene el identificador "1" de DSMCC y el nombre de programa Java "a/TopXlet" . Entonces, el AM 1205b obtiene, de la PMT, la ID de paquete de los paquetes que almacenan programas Java en el formato de DSMCC, usando el identificador de DSMCC obtenido de la AIT. De manera más específica, el AM 1205b obtiene, de la PMT, el ID de paquete incluido en la corriente elemental cuyo tipo de corriente es "dato" y cuyo identificador de DSMCC en la información adicional corresponde. Aquí, asumiendo que este identificador de DSMCC es "1" y la PMT es la mostrada en la Figura 17, la corriente elemental en la línea 1714 satisface la condición anterior. Por lo tanto, la ID "5014" de paquete se va a extraer. El AM 1205b indica, al descodificador 505 de TS, la ID de paquete de los paquetes en los cuales se incrustan los datos en el formato de DSMCC así como la CPU 514 como un destino de salida a través de la biblioteca 1201b del OS 1201. Aquí, se proporciona la ID "5014" de paquete. Entonces, el descodificador 505 de TS realiza la filtración en base a la ID de paquete proporcionada, y pasa la resultante a la CPU 514. Por consiguiente, el AM 1205b puede recolectar los paquetes requeridos. El AM 1205b reconstruye el sistema de archivos de los paquetes recolectados de acuerdo al método DSMCC, y almacena el sistema de archivos reconstruido en la unidad 511 de almacenamiento primaria. El proceso para extraer datos tal como el sistema de archivos de los paquetes en el transporte MPEG2 y almacena los datos extraídos en las unidades de almacenamiento tal como la unidad 511 de almacenamiento primaria se llama posteriormente descarga. La Figura 19 muestra un ejemplo del sistema de archivo descargado. En el diagrama, los círculos representan directorios y los cuadrados representan archivos, donde 1901 es un directorio de raíz, 1902 es un directorio "a", 1903 es un directorio "b", 1904 es un archivo "TopXlet . class" , y 1905 es un archivo "GameXlet . class" . De manera subsiguiente, el AM 1205b pasa, a la JavaVM 1203, un programa Java que se va a ejecutar del sistema de archivos descargado en la unidad 511 primaria de almacenamiento. Aquí, asumiendo que el nombre de programa Java que se va a ejecutar es "a/TopXlet", un archivo "a/TopXlet .class" , que resulta del apéndice de ".class" al nombre de programa Java anterior, es un archivo que se va a ejecutar. "/" es un delimitador entre un directorio y un nombre de archivo, y como se muestra en la Figura 19, el archivo 1904 es un programa Java que se va a ejecutar. Entonces, el AM 1205b pasa el archivo 1904 a la JavaVM 1203 puesto que la columna 1801 que describe el identificador del programa Java indica un programa no signado, significando que no hay necesidad de pedir que el gestor 1205f de seguridad realice la autenticación del programa Java. La JavaVM 1203 ejecuta este programa Java recibido. En la recepción del identificador de otro canal, el gestor 1204 de servicio termina la reproducción del video y audio así como la ejecución del programa Java que se está llevando a cabo a través de cada biblioteca incluida en la biblioteca 1205 Java, a través de cada biblioteca incluida en la misma biblioteca Java 1205, y entonces realiza la reproducción del video y audio así como la ejecución de un programa Java en base al identificador de canal recién recibido . El gestor 1205f de seguridad se requiere para garantizar la credibilidad de un programa ejecutado en el aparato terminal. Si el aparato se ha alterado y este programa es capaz de operar en el aparato terminal , se pueden desperdiciar los recursos del aparato terminal, tal como una memoria, y puede llegar a ser inestable la operación del aparato terminal como una totalidad. También es posible que la información en el aparato terminal se transmita de forma arbitraria, usando un recurso tal como una red. El gestor 1205f de seguridad verifica la credibilidad y confiabilidad de un programa de modo que no surgen estas ocurrencias . Los detalles del gestor 1204f de seguridad que proporciona esta función de autenticación se van describir más adelante. La biblioteca Java 1205 es una colección de bibliotecas Java plurales almacenadas en la ROM 512. En la presente modalidad, la biblioteca Java 1205 incluye el JMF 1205a, el AM 1205b, el sintonizador 1205c, el CA 1205d, una biblioteca de POD 1205e, el gestor 1204f de seguridad, un módulo 1206 de descarga, y similares. El gestor 1204 de servicio y el módulo 1206 de descarga llevan a cabo una comunicación bidireccional con el centro distribuidor 101 mediante la biblioteca de POD 1205e incluida en la biblioteca Java 1205. Esta comunicación bidireccional se puede realizar por la biblioteca 1205e de POD usando la unidad 502 de desmodulación del QPSK y la unidad 503 de modulación de QPSK mediante la biblioteca 1201b del OS 1201 y el POD 504. El módulo 1206 de descarga puede recibir datos de código del centro distribuidor 101 a través de esta comunicación. Los datos de código se refieren a datos binarios que incluyen un certificado X.509 y/o programa en circuito del aparato terminal 500. La Figura 37 es un diagrama esquemático que muestra los datos de código que describen sólo una parte relacionada a la presente invención. Cuando se reciben los datos 37 de código, el módulo 1206 de descarga extrae un certificado 371 de raíz si se incluye, y lo pasa al gestor 1205f de seguridad. 372 indica otros datos tal como programa en circuito. El AM 1205b recibe, del centro distribuidor 101, la información acerca de los programas Java que el aparato terminal 500 debe almacenar en la unidad 510 secundaria de almacenamiento, una instrucción de activación de programa Java, un nombre del programa que se va a activar, y así sucesivamente. Esta información se refiere como información de XAIT. La información de XAIT se transmite entre el centro distribuidor 101 y el POD 504 de una forma arbitraria. La presente invención se puede implementar a pesar del formato de transmisión, en tanto que se incluye a la información requerida para XAIT. La Figura 20 ilustra una tabla que muestra esquemáticamente un ejemplo de la información de XAIT obtenida del centro distribuidor 101. Una columna 2001 describe los identificadores de programas Java. Una columna 2002 describe información de control para controlar los programas Java. La información de control incluye "autoinicio" y "presente" . "Autoinicio significa que el programa se ejecuta automáticamente cuando se enciende el aparato terminal 500, y "presente" significa que el programa no se va a ejecutar de forma automática. Una columna 2003 describe los identificadores de DSMCC usados para extraer las ID de paquete que incluye los programas Java en el formato de DSMCC . Una columna 2004 describe los nombres de programa de los programas Java. Una columna 2005 describe las prioridades de los programas Java. Cada una de las filas 2011 y 2012 es un conjunto de información acerca de los programas Java respectivos. El programa Java definido en la fila 2011 es un conjunto de un identificador "0x4001", información de control "autoinicio", un identificador "1" de DSMCC, y un nombre de programa "a/PPVlXlet " . Se puede conocer de su ID de aplicación de programas Java que este programa Java es un programa signado. Aquí, sólo se especifican cinco puntos de información para los programas Java respectivos, pero la presente invención se puede implementar aún cuando se definan más puntos de información. En la recepción de la información de XAIT, el AM 1205b retiene el sistema de archivos de la corriente de transporte de MPEG2 en la unidad 511 de almacenamiento primaria, de acuerdo al mismo procedimiento como aquél para descargar el programa Java de la información de XAIT, o lo almacena en la unidad secundaria 510 de almacenamiento cuando una instrucción para almacenar el programa Java se da en la información de XAIT. Durante la retención de la unidad 511 primaria de almacenamiento o durante el almacenamiento en la unidad 510 secundaria de almacenamiento, la posición de almacenamiento del archivo descargado se asocia con la información de XAIT. La Figura 21 muestra un ejemplo de la información de XAIT y el sistema de archivo descargado almacenado en la unidad 511 primaria de almacenamiento o la unidad 510 secundaria de almacenamiento, en asociación entre sí. aquí, un archivo definido en la especificación de OCAP "OpenCable (TM) Application Platform Specification OCAP 1.0 Profile (OC-SP-OCAPl.0-111-040604) " se describe como un ejemplo. Los elementos en la Figura 21 que son los mismos como aquéllos en la Figura 20 son los mismos entre sí, y por lo tanto se omite una explicación para estos elementos. Una columna 2101 almacena la posición de almacenamiento del sistema de archivo descargado. En la Figura 21, estas posiciones de almacenamiento se indican por flechas. 2110 es el sistema de archivo descargado en el cual se incluyen un directorio superior 2111, un directorio "a" 2112, un directorio "b" 2113, un archivo "PPVlXlet. class" 2114, un archivo "PPV2Xlet . class" 2115, los archivos "ocap.hashfile" 2116 ~ 2118, un archivo "ocap.certificates.1" 2119, y un archivo "ocap.signaturefile.l" 2120. Los archivos 2116 ~ 2118 son archivos de ' troceo en los cuales se incluyen los nombres de archivo o nombres de directorio y sus valores de troceo. 221 en la Figura 22A, 222 en la Figura 22B, y 223 en la Figura 22C son diagramas esquemáticos que representan los detalles de "ocap.hashfile" 2116, "ocap.hashfile" 2117, y "ocap.hashfile" 2118, respectivamente. El "ocap.hashfile" de 221, que existe en el directorio "/" 2111, incluye, en la columna 2211, un archivo "ocap.certificates .1" 2119, un archivo "ocap.signaturefile.l" 2120, un directorio "a" 2112, y un directorio "b" 2113 que existen en el mismo directorio 2111. Una columna 2211 indica que algoritmo de cálculo de clave se usó para calcular cada valor descrito en una columna 2213. La columna 2213, que se refiere a los archivos o directorios en la columna 2211, incluye valores de troceo que se calcularon por el uso del algoritmo de cálculo de clave especificado en la columna 2212. Corrientemente, los algoritmos de troceo que se pueden usar principalmente son SHAl (algoritmo 1 de troceo seguro) y MD5 (digestión de mensaje 5) . Estos son algoritmos públicamente conocidos para convertir datos con una longitud arbitraria en un valor de bytes de longitud fija, que tiene las siguientes características: es imposible predecir los datos originales después si estos se convierten; y se usan para verificar si se ha dañado o alterado un archivo. Entre tanto, un valor de cálculo de direccionamiento es un número pseudo-aleatorio que se genera por el uso de un algoritmo de cálculo de clave. Cuando un algoritmo de cálculo de clave es SHAl, la longitud de un valor de cálculo de direccionamiento es 20 bytes, en tanto que cuando un algoritmo de cálculo de clave es MD5, la longitud de un valor de cálculo de direccionamiento se convierte a 16 bytes. Para detalles acerca de SHAl y MD5, referirse a "FIPS-PUB 186-2 Secure Hash Standard" e "IETF RFC1321", respectivamente. Aquí, los valores de troceo que corresponden a los directorios "a" y "b" respectivos descritos en la columna 2211 son los valores de troceo de SHAl que se han calculado respectivamente para el archivo "ocap.hashfile" 2117 que existe en el directorio "a" y el archivo "ocap.hashfile" 2118 que existe en el directorio "b" . Como en el caso del archivo "ocap.hashfile" en 221, el archivo "ocap.hashfile" en 222 incluye el nombre de archivo, el algoritmo de cálculo de clave, y el valor de cálculo de direccionamiento del archivo "PPVlXlet . class" 2114 que existe en el mismo directorio 2112. De manera similar, incluido en 223 están el nombre de archivo, el algoritmo de cálculo de clave, y el valor de cálculo de direccionamiento de un archivo "PPV2Xlet .class" 2115 que existe en el mismo directorio 2113. Aquí, sólo se describen atributos que se relacionan a la presente invención, y de esta manera la especificación de OCAP "OpenClave (TM) Application Platform Specification OCAP 1.0 Profile (OC-SP-OCAPl .0-IF-I09-031121) " se debe referir con respecto a la estructura detallada del archivo "ocap.hashfile" . Un archivo 2119 es una cadena de certificados. La Figura 23 es un diagrama que muestra una estructura detallada del archivo "ocap. certificates .1" 2119. 231, que representa una estructura típica de "ocap. certificates .x" (x es un número entero positivo) , contiene un certificado 2311 de raíz, un certificado intermedio 2312, y un certificado 2313 de hoja. Están en una relación de cadena en la cual el retenedor del certificado 2311 de raíz emite el certificado intermedio 2312 y el retenedor de certificado intermedio 2312 emite el certificado 2313 de raíz, a manera de ejemplo. Se señala que de acuerdo a la especificación de OCAP, una cadena de certificados relacionada a un archivo de identificación "ocap. signaturefile.x" es "ocap. certificates .x" que tiene el En el caso de la Figura 21, una cadena de certificados que corresponde al "ocap.signaturefile.l" es el "ocap.certificates .1" . También, el certificado 2311 de raíz, el certificado 2312 intermedio, y el certificado 2313 de hoja se configuran en el mismo formato de certificado X.509. Los certificados X.509 se usan ampliamente en varios campos en la industria de información y comunicaciones como una norma de facto para el formato de representación de certificados, a través de la recomendación de la ITU-T. En la Figura 23, sólo se ilustran tres certificados, pero hay ocasiones donde existe una pluralidad de certificados intermedios. En este caso, sin embargo, estos certificados intermedios deben estar en un estado encadenado en el cual se relacionan entre sí . La Figura 24 es un diagrama que muestra la estructura de un certificado X.509. Aquí, sólo se ilustran los atributos que se requieren para explicar la presente invención. Para detalles acerca de los certificados X.509, referirse a IETF RFC3280 "Internet X.509 Public Key Infrastructure Certifícate and CRL Profile" . 241 indica un área de atributo del certificado X.509 y 242 indica el valor de identificación de certificado X.509. El número de serie 2411 indica el número para identificar el certificado, el algoritmo 2412 de identificación indica el algoritmo usado para determinar el valor 242 de identificación, esta fecha y tiempo 2413 de actualización indica la fecha y tiempo cuando este certificado X.509 llega a ser válido, la siguiente fecha y tiempo 2414 de actualización indica la fecha y tiempo cuando este certificado X.509 expira, el nombre 2415 de emisor indica el nombre de la autoridad que emitió este certificado X.509, el nombre 2416 de sujeto indica el retenedor o poseedor de este certificado X.509, la clave pública 2417 indica la clave pública del nombre 2416 de sujeto, y el valor 242 de identificación indica un valor que se ha asignado (encriptado) con la clave privada del emisor de este certificado X.509. Como un sistema que utiliza clave pública y clave privada, se usan ampliamente criptosistemas de clave pública para comercio electrónico y otros. En un criptosistema de clave pública, se desencripta un texto encriptado con una clave que es diferente de la clave usada para encriptar el texto plano. Puesto que la clave para la encriptación y la clave para la desencriptación son diferentes, es imposible estimar la clave para la encriptación a partir de la clave para la desencriptación. Esta clave para la encriptación corresponde a la clave privada y esta clave para la desencriptación corresponde a la clave pública. Los ejemplos representativos de criptosistemas de clave pública incluyen RSA (Rivest-Shamir-Adleman) y DSA (norma de identificación digital) . El archivo 2120 es un archivo de identificación. La Figura 25 es un diagrama esquemático que muestra el archivo "ocap.signaturefile.l" 2120. 251 indica un identificador de certificado para identificar qué certificado X.509 está relacionado, 252 indica un algoritmo de identificación de troceo, y 253 indica un valor de identificación que se ha calculado del "ocap.hashfile" 2116 por el uso del algoritmo de identificación de troceo indicado en 252. En el caso donde se almacenen programas Java en la unidad 510 de almacenamiento secundaria, es posible activar este programa Java sin necesidad de esperar la descarga en tanto que el AM 1205b ha recibido la XAIT mostrada en la Figura 20, aún en el caso donde el programa Java se suprimió de la unidad 511 primaria de almacenamiento debido a causas tal como el apagar la energía al aparato terminal 500. En la Figura 20, la información 2002 de control del programa " /a/PPVlXlet" es "autoinicio". De esta manera, en 2011 en la Figura 21, cuando se hace una búsqueda para la posición 2101 del sistema de archivos que corresponde al "/a/PPVlXlet" y entonces el archivo 2114 se pasa a la JavaVM 1203, el programa Java "PPVlXlet" almacenado en este sistema de archivos se activa. Además, antes de la activación del programa Java, el AM 1205b verifica el valor del identificador 2001 de programa Java y juzga si es un programa no signado o un programa signado. Si es un programa signado, el gestor 1205f de seguridad se instruye para llevar a cabo la autenticación. A continuación, se hará una descripción del gestor 1205f de seguridad que realiza la autenticación.

Al ser instruido por el AM 1205b para autenticar un archivo, el gestor 1205f de seguridad verifica el valor del identificador 2001 de programa Java para juzgar si es un programa no signado o un programa signado. Aquí, puesto que el programa Java es un programa signado, el gestor 1205f de seguridad realiza la autenticación del sistema de archivos menor que el directorio "/". Para verificar el sistema de archivos, se realiza la autenticación por el uso del ocap.hashfiles (2116 ~ 2118), el ocap. certificates .1 (2119), y el ocap.signaturefile.l (2120) ilustrados en la Figura 21. La Figura 26 muestra los elementos constituyentes del gestor 1205f de seguridad que realiza la autenticación de un sistema de archivos. Una unidad 261 de recepción de notificación se propone que reciba una instrucción de autenticación de archivo del AM 1205b así como la notificación de la instrucción a una unidad 262 de juicio. La unidad 262 de juicio juzga un resultado de autenticación. Pide a una unidad 263 de cálculo de troceo hacer cálculos de troceo para el sistema de archivos para recibir valores de troceo. La unidad 262 de juicio extrae, de entre los valores 2213, 2223 y 2233 de troceo que existen en el archivo "ocap.hashfile", un valor que se va a comparar y verificar si o no corresponde a los valores de troceo recibidos. Si no corresponden, la unidad 262 de juicio juzga si ha habido alteración, y termina en falla la autenticación. Adicionalmente, la unidad 262 de juicio extrae cada uno de los certificados X.509 usando una unidad 265 de extracción de certificado, y juzga si el tiempo actual está entre esta fecha y tiempo 2413 de actualización y la siguiente fecha y tiempo 2414 de actualización de cada uno de los certificados X.509. La fecha y tiempo actuales se obtienen de la biblioteca 1201b del OS 1201. Si el periodo de validez no satisface "esta fecha y tiempo de actual < fecha y tiempo de actualización siguiente", la unidad 262 de juicio juzga que la autenticación es una falla. Además, a fin de autenticar la cadena de certificados, la unidad 262 de juicio pide a la unidad 263 de cálculo de troceo hacer un cálculo de troceo para el área 241 de atributo de cada uno de los certificados X.509. Entonces, pide a una unidad 264 de descripción de valor de identificación hacer un cálculo para desencriptar el valor 242 de identificación incluido en cada uno de los certificados X.509, y compara el valor desencriptado resultante con los valores de troceo obtenidos por la unidad 263 de cálculo de valor de cálculo de direccionamiento para verificar el estado de la cadena de certificados. Si no corresponden, significa que los certificados no están en una relación de cadena, y de esta manera la autenticación se juzga que es una falla. Entre tanto, cuando estos valores corresponden y se ha verificado que los certificados están en una relación de cadena, se verifica si el certificado de raíz en la cadena de certificados se incluye en la unidad 510 secundaria de almacenamiento del aparato terminal 500. Si no se incluye, la unidad 262 de juicio juzga que la autenticación es una falla, cuando parece ser imposible la comparación. La unidad 262 de juicio juzga que la autenticación es exitosa cuando todo lo siguiente se satisface: (1) no ha habido alteración; (2) hay un periodo de validez; (3) certificados que están en una relación de cadena; y (4) los certificados de raíz corresponden. Cuando se pide por la unidad 262 de juicio calcular un valor de cálculo de direccionamiento de cada uno de los archivos, la unidad 263 de cálculo de troceo extrae cada uno de los archivos de la biblioteca 1201b del OS 1201 para realizar los cálculos de troceo para estos, y pasan los valores resultantes de la unidad 262 de juicio. Además, la unidad 263 de cálculo de troceo obtiene cada uno de los certificados X.509 en la cadena 231 de certificado de la unidad 265 de extracción de certificado, y realiza los cálculos de troceo para el área 241 de atributo de cada uno de ellos. La unidad 264 de desencriptación de valor de identificación se requiere por la unidad 262 de juicio que realice un cálculo para desencriptar el valor de identificación de ya sea cada certificado X.509 o "ocap. signaturefile. x" . Cuando se realiza un cálculo para desencriptar la identificación de cada certificado X.509, la unidad 264 de desencriptación de valor de identificación obtiene cada uno de los certificados de X.509 en la cadena 231 de certificado de la unidad 265 de extracción de certificado, y entonces realiza un cálculo para desencriptar la identificación de cada uno de ellos, y regresa la resultante a la unidad 262 de juicio. La unidad 265 de extracción de certificado se le requiere que extraiga cada uno de los certificados X.509 en la cadena 231 de certificado por la unidad 262 de juicio, la unidad 263 de cálculo de troceo, y la unidad 264 de desencriptación de valor de identificación, y extrae y regresa los certificados X.509. La Figura 27 es un diagrama de flujo que resume una operación realizada por el gestor 1205f de seguridad cuando realiza la autenticación de un sistema de archivos. En base a este diagrama de flujo, se da una explicación de la operación que se va a realizar en el caso donde el sistema de archivos tenga la configuración mostrada en la Figura 21. En la recepción de una instrucción de autenticación para el sistema de archivos, del AM 1205b (Paso S271) , el gestor 1205f de seguridad lleva a cabo la verificación de alteración en el sistema de archivos menor que el directorio "/" de nivel superior del sistema de archivos (Paso S272). En la verificación de la alteración, se verifica, al comparar los valores de troceo, que no haya daño o cambios en los archivos que existen en cada directorio del sistema de archivos. La Figura 29 y la Figura 30 son diagramas de flujo detallados del Paso S272. Primero, como se muestra en el Paso S291, se calculan valores de troceo para los archivos respectivos "ocap. certificates .1" y "ocap.signaturefile.l" y los directorios respectivos "a" y "b" que existen en el directorio "/". Se señala que los valores de troceo de los directorios "a" y "b" se calculan del archivo "/a/ocap.hashfile" 222 y el archivo " /b/ocap.hashfile" 223, respectivamente. En el Paso S293, los valores de troceo calculados en el Paso S292 se comparan con cada uno de los valores de troceo descritos en 2213 en "/ocap.hashfile". En el Paso S294, si cualquiera de los valores de troceo calculados difiere de los valores de troceo en 221, se juzga que ha habido alteración (Paso S297). Entre tanto, cuando todos los valores de troceo calculados corresponden a los valores de troceo 2213, se hace una transición al Paso S295. En el Paso S295, se verifica si existe cualquier subdirectorio para el cual no se haya terminado la verificación de alteración. En la etapa actual, los directorios "a" y "b" existen como los subdirectorios del directorio "/", para el cual aun no se ha realizado la verificación de alteración. Por lo tanto, la verificación de alteración necesita ser realizada para estos directorios "a" y "b" . Primero, se pone enfoque en el directorio "a" en el Paso S296, donde se realiza un proceso equivalente al realizado para el directorio "/". Después de que se termina la verificación de alteración del directorio "a", se realiza la verificación de alteración para el directorio "b" . Cuando se ha terminado la verificación de alteración para los directorios "a" y "b" , entonces se pone enfoque en el directorio "/", y se realiza el proceso para el paso "S301" en la Figura 30. En el paso S301, el certificado 2313 de hoja se extrae del archivo "/ocap. certificates .1" 2119, que es la cadena 231 de certificado. Entonces, en el Paso S302, la clave pública 2917 se toma del certificado 2313 de hoja extraído. De manera subsiguiente, en el paso S303, se calcula un valor de cálculo de direccionamiento para el archivo "/ocap.hashfile" 221. Entre tanto, en el Paso S304, se realiza una desencriptación en el valor 242 de identificación en el archivo" "/ocap. signaturefile.1" 2120, usando la clave publica 2417 que existe en el certificado 2313 de hoja en el archivo " /ocap. certificatesfile.1" 2119. En el Paso S305, se verifica si el valor de cálculo de direccionamiento calculado en el paso S303 es igual al error obtenido en el Paso S304 al desencriptar el valor de identificación. Si estos valores calculados corresponden, es posible juzgar que el sistema de archivo es menor que el directorio "/" no se ha alterado "Paso S306" . Entre tanto, si los valores calculados no corresponden, es posible juzgar que el sistema de archivo se ha alterado (paso S307) . Se señala que se ha dado una descripción para un ejemplo en el cual se realiza una verificación de alteración iniciando con el directorio "/" de nivel superior a los subdirectorios en orden descendente, pero la presente invención no se limita a esto. Por lo tanto, se pueden realizar procesos iniciando con el directorio de nivel más bajo hacia el directorio de nivel superior en orden ascendente. A través de los procesos anteriores, se obtiene el resultado del paso S272 en la Figura 27. En el Paso S273, cuando el resultado en el Paso S272 es "ha habido alteración" se juzga que ha fallado la autenticación y se hace una notificación acerca de este hecho (Paso S279), después de lo cual se termina el proceso. Cuando el resultado del Paso S272 es "ninguna alteración", se ejecuta el proceso para el Paso S274. Entonces, con referencia a la Figura 31 a la Figura 33, se da una descripción detallada de la autenticación "Paso S274) de la cadena de certificados. Asumiendo que se realiza primero una verificación para el certificado 2312 intermedio y el certificado 2313 de hoja, en la Figura 31 se muestra un diagrama de flujo para esto. Primero, el certificado intermedio 2312 y el certificado 2313 de hoja se extraen de la cadena 231 de certificado (Paso S311) . De este certificado 2313 de hoja extraído, esta fecha y tiempo 2413 de actualización, la siguiente fecha y tiempo 2414 de actualización, y el nombre 2415 del emisor se extraen (Paso S312) . De estos, se juzga si la fecha y tiempo actual están entre esta fecha y tiempo 2313 de actualización y siguiente fecha y tiempo 2414 de actualización durante el cual puede permanecer válido (Paso S313) de certificado. Si esta más allá del periodo durante el cual puede permanecer válido el certificado, la autenticación de la cadena de certificados da por resultado falla (Paso S319) . Entre tanto, cuando se juzga que esta dentro del periodo válido del certificado, el nombre 2416 de sujeto y la clave pública 2417 en el certificado intermedio 2312 se extraen (Paso S314) , y se hace una comparación entre el nombre 2416 de sujeto del certificado intermedio 2312 y el nombre 2415 de emisor del certificado 2313 de hoja para juzgar si el certificado intermedio 2312 y el certificado 2313 de hoja están en una relación de cadena o no (Paso S315) . Si estos certificados no están en una relación de cadena, la autenticación de la cadena de certificados es una falla. Entre tanto, cuando existe una relación de cadena entre estos, un valor de cálculo de direccionamiento del área 241 de atributo del certificado 2313 de hoja se calcula (Paso S316) . Adicionalmente, el valor 242 de identificación en el certificado 2313 de hoja se desencripta con la clave pública 2417 del certificado 2312 intermedio (Paso S313) . Cuando se termina en el Paso S316 y el Paso 317, se verifica si el valor de cálculo de direccionamiento y el valor de identificación desencriptado obtenidos en los pasos respectivos corresponden o no (Paso S318) sino corresponden, la autenticación de la cadena de certificados termina en falla (Paso S319) . Entonces, se realiza una verificación entre el certificado 2311 de raíz y el certificado intermedio 2312. La Figura 32 es un diagrama de flujo que muestra este proceso. El certificado 2311 de raíz y el certificado intermedio 2312 se extraen de la cadena 231 de certificado (Paso S321) , y un proceso que es equivalente a la verificación realizada para el certificado intermedio 2312 y el certificado 1312 de hoja se realiza para el certificado 2311 de raíz y el certificado intermedio 2312 (Pasos S322 ~ Paso S328) . Cuando se juzga en el Paso S328 que los valores corresponden, se realiza una verificación únicamente para el certificado 2311 de raíz. La Figura 33 es un diagrama de flujo que muestra una verificación que se va a realizar únicamente para el certificado 2311 de raíz. El certificado 2311 de raíz extraído en el Paso S321, esta fecha y tiempo 2313 de actualización, la siguiente fecha y tiempo 2314 de actualización, y el nombre 2415 de emisor se extraen (Paso S331) . De estos, se juzga si la fecha y tiempo actual están entre esta fecha y tiempo 2413 de actualización y la siguiente fecha y tiempo 2414 de actualización durante el cual permanece válido el certificado (Paso S332) . Si están más allá del periodo durante el cual puede permanecer válido el certificado, la autenticación de la cadena de certificados termina en falla. Entre tanto, cuando se juzga que esta dentro del periodo de validez del certificado, se calcula (Paso S334) un valor del troceo para el área 241 de atributos del certificado 2311 de raíz. Adicionalmente, el valor 242 de identificación en el certificado 2311 de raíz se desencripta con la clave pública 2417 del certificado 2311 de raíz (Paso S335) . Cuando se termina en el Paso S334 y el Paso S335, se verifica si el valor de cálculo de direccionamiento y el valor de identificación desencriptado obtenidos en los pasos anteriores corresponden o no (Paso S336) . Si corresponden, la autenticación de la cadena de certificados es exitosa (S337) , en tanto que sino corresponden la autenticación de la cadena de certificados termina en falla (Paso S338) . En este punto, termina el proceso del Paso S274. El proceso se realiza de forma diferente en el Paso S275 dependiendo del resultado de S274. Cuando el resultado del Paso S274 es "autenticación fallida de la cadena de certificados", se juzga que la autenticación ha fallado y se hace acerca de esto una notificación (Paso S279), y entonces se termina la autenticación para el sistema de archivos. Entre tanto, en el caso de "autenticación exitosa de la cadena de certificados", se realiza el proceso del Paso S276. Entonces, la unidad 510 secundaria de almacenamiento del aparato terminal 500 se investiga para un certificado que es el mismo o como el certificado 2311 de raíz del archivo "/ocap.certificates.l" 2119 (Paso S276) . Cuando no esta presente el mismo certificado en la unidad 510 secundaria de almacenamiento, se juzga en el Paso S277 que la autenticación de la cadena 231 de certificado es una falla, y se hace una notificación acerca de esta falla de autenticación (Paso S279) , después de lo cual se termina el proceso. Entre tanto, cuando se incluye el certificado 2311 de raíz, se juzga que la autenticación del sistema de archivos es exitosa, y se hace una notificación al AM 1205b acerca de este éxito de autenticación (Paso S278) . Y con referencia a la Figura 28, aun si se recibe una instrucción de autenticación de programa java (Paso S281) de forma subsiguiente, el proceso se puede terminar sin realizar nada. Esto es debido a que se ha llevado a cabo la autenticación del programa java, y no hay necesidad de autenticación en este punto. Adicionalmente, cuando se signa una instrucción de almacenamiento en la información de XAIT en el caso donde existan el "archivo de descripción y aplicación" en el sistema de archivos, los sistemas de archivos descritos en el mismo se van almacenar. En la especificación de OCAP, por ejemplo, se describe el "archivo de descripción de aplicación" en el formato XML (Lenguaje de Etiquetación Extensible) . La Figura 34 muestra un ejemplo del "archivo de descripción de aplicación" Segunda Modalidad Cuando un programa Java (PPVlXlet. Class 2114 o PPV2Xlet. Class 2115) incluido en el sistema de archivos se va a activar en un cierto periodo de tiempo después de que se almacene este sistema de archivos, hay posibilidad que se venza la validez de uno de los certificados X.509 incluidos en el archivo "/ocap.certificates.l" 2119 (es decir, la fecha y tiempo de activación del programa Java > siguiente fecha y tiempo 2414 de actualización) . Puesto que la descripción anterior permite que el programa Java se active aún si se incluye un certificado X.509 ya vencido en la cadena 231 de certificado, también existe la tecnología para verificar, en el momento de activar un programa Java, que la validez de cada uno de los certificados 2311, 2312 y 2313 incluidos en la cadena 231 de certificado no se venza. La Figura 26 muestra los elementos constituyentes en el mismo. Los elementos constituyentes 261-265 necesarios para esta tecnología se describen ya en la primera modalidad, y por lo tanto no se dan en la presente las descripciones de los mismos . Como diagramas de flujo, el diagrama de la Figura 27 se reemplaza por el diagrama de flujo de la Figura 35 y se adiciona al diagrama de flujo de la Figura 36. Con referencia a la Figura 35, como los procesos que se van a realizar inmediatamente antes de que se almacene el sistema de archivos (paso S351 a paso S357) son los mismos como procesos explicados en la primera modalidad (paso S271 a paso S277), se omiten las descripciones de los mismos. Si la autenticación no es una falla, el proceso va sobre el diagrama de flujo mostrado en la Figura 36. cuando una notificación que el PPVlXlet .class 2114, que es un programa Java, se va a activar después de un cierto periodo de tiempo (paso S361) , cada uno de los certificados X.509, es decir, el certificado 2311 de raíz, el certificado intermedio 2312, y el certificado 2313 de hoja se extraen del archivo "ocap.certificates.l" 2119 (paso S362) . Entonces, los certificados de X.509 extraídos se seleccionan uno por uno a fin de iniciar con el certificado de entrada al certificado de raíz (paso S363), y se verifica que la fecha y tiempo actual están entre esta fecha y tiempo 2413 de actualización y la siguiente fecha y tiempo 2414 de actualización de cada uno de los archivos X.509 seleccionados (paso S364) . Si la fecha y tiempo actual no están entre esta fecha y tiempo 2413 de actualización en la siguiente fecha y tiempo 2414 de actualización, se juzga que la autenticación es una falla y se hace una notificación acerca de este hecho (paso S367). En otro caso, se verifica si se han realizado verificaciones para todos los certificados X.509 o no (paso S365) . Si no se han terminado las verificaciones para todos los certificados X.509, el proceso se regresa a S363, y se repiten los procesos subsiguientes. Entre tanto, cuando todos los certificados X.509 se han verificado ya en el paso S365, se juzga que es exitosa la autentificación, y se hace una notificación acerca de este éxito de autenticación (paso S366) , después de que se termina el proceso. Al adicionar los procesos mostrados en el diagrama de flujo de la Figura 36, llega a ser posible notificar al AM 1205b de la falla de autenticación de modo que no se activará un programa Java cuyo periodo de validez haya vencido. Después de que se notifica por el gestor 1205f de seguridad de la falla de autenticación, el AM 1205b aborta la activación sin pasar este programa Java a la JavaVM 1203.

Tercera modalidad Como se describe anteriormente, la unidad secundaria 510 de almacenamiento incluye un certificado X.509 que es el certificado de raíz, que se compara con el certificado 2311 de raíz en la cadena 231 de certificado. El certificado de raíz almacenado en la unidad 510 secundaria de almacenamiento se reemplaza con un nuevo certificados .509 (referido más adelante en la presente como reemplazo de certificado) en la preparación para el caso donde la credibilidad del certificado se degrada debido a falsificación y otros. El nuevo certificado X.509 se transmite desde el centro distribuidor 101 al aparato terminal 500 para ser distribuido al gestor 1205f de seguridad mediante el módulo 106 de descarga. Las Figuras 38A a 38C son diagramas que muestran un certificado de raíz en la unidad secundaria 510 de almacenamiento que se reemplaza (reemplazo de certificado) por el gestor 1205f de seguridad. En este caso, un certificado A381 es un certificado anterior que se va a reemplazar, en tanto que un certificado B382 es un nuevo certificado. 38-1 de la Figura 38A muestra el certificado almacenado en la unidad secundaria 510 de almacenamiento antes de que se realice el reemplazo de certificado, 38-2 de la Figura 38B muestra el certificado en el punto intermedio de ser procesado, y 38-3 de la Figura 38C muestra el certificado almacenado en la unidad secundaria 510 de almacenamiento después de que se realiza el reemplazo de certificado. La descripción anterior, aún cuando se realiza el reemplazo de certificado después de que se almacena un programa Java, el nuevo certificado no se toma en consideración en el momento de la activación del programa Java. Considerando que, por ejemplo, el certificado 2311 de raíz en la cadena 231 de certificado corresponde al certificado A3811 cuando el gestor 1205f de seguridad está autenticando un programa Java en respuesta a una instrucción de autenticación y que el gestor 1205f de seguridad recibe una instrucción de autenticación para el programa Java después de que el certificado A3811 se reemplaza por el certificado B3812. En este punto de tiempo, la unidad 510 secundaria de almacenamiento no incluye ningún certificado que corresponda al certificado 2311 de raíz en la cadena 231 de certificado, significando que no es creíble este certificado. Sin embargo, en la descripción anterior, puesto que no se hace comparación entre los certificados de raíz inmediatamente antes de la activación de un programa Java (es decir, el certificado 2311 de raíz en la cadena 231 de certificado no se compara con el certificado B3812), no se hace una notificación al AM 1205b acerca de la falla de autenticación. Como resultado, el AM 1205b hace que se active el programa Java. De esta manera, existe tecnología para revisar una comparación de los certificados de raíz en consideración al reemplazo de certificado en el tiempo de activación del programa Java. La Figura 26 muestra los elementos constituyentes de esta tecnología. Los elementos constituyentes 261 ~ 265 se han descrito y por lo tanto se omiten las explicaciones de los mismos. Se adicionan una unidad 266 de reemplazo de certificado, una unidad 267 de especificación de reemplazo de certificado y una unidad 268 de recepción de certificación. Cuando la unidad 267 de especificación de reemplazo de certificado juzga que un certificado es más anterior que el certificado recibido se almacena en la unidad secundaria 510 de almacenamiento, la unidad 266 de reemplazo de certificado reemplaza este certificado anterior con el nuevo certificado. Entre tanto, cuando la unida 267 de especificación de reemplazo de certificado juzga que no se almacena el certificado anterior, la unidad 6266 de reemplazo de certificado almacena el nuevo certificado en la unidad secundaria 510 de almacenamiento. La unidad 267 de especificación de reemplazo de certificado recibe el certificado recibido por la unidad 268 de reemplazo de certificado. Entonces, verifica el certificado almacenado en la unidad 510 secundario de almacenamiento par ver si hay algún certificado cuyo emisor es el mismo y que es más anterior que el certificado recibido, por el uso de la biblioteca 1201b del OS 1201. La unidad 268 de recepción de certificado recibe un nuevo certificado cuando el módulo 1206 de descarga recibe este nuevo certificado del centro distribuidor 101. En la recepción del certificado, la unidad 268 de reemplazo de certificado lo pasa la unidad 266 de reemplazo de certificado y a la unidad 267 de especificación de reemplazo de certificado. Además, la Figura 39 y la Figura 40 se adicionan de manera subsiguiente al diagrama de flujo de la Figura 35. La Figura 39 es un diagrama de flujo en el momento de revisar el reemplazo de certificado, en tanto que la Figura 40 es un diagrama de flujo en el momento de activar el programa Java después de que se realiza el reemplazo de certificado. Con referencia a la Figura 39, cuando se recibe una petición para el reemplazo de certificado (paso S391) , el nombre del emisor de este certificado recibido se extrae (paso S392). Se verifica si un certificado anterior que necesita ser reemplazado está presente en la unidad secundaria 510 de almacenamiento del aparato terminal 500 (paso S397), y sólo cuando está presente un certificado anterior, este certificado se suprime. Entonces, el certificado recibido se almacena en la unidad secundaria 510 de almacenamiento (paso S395) . Cuando se recibe una notificación de activación para el programa Java después de un cierto periodo de tiempo (paso S401) , la unidad 510 de almacenamiento secundaria se busca para el certificado que corresponde al certificado 2311 de raíz de la cadena 231 de certificado (paso S402) , y si hay alguno (paso S403), se juzga que es exitosa la autenticación y se hace una notificación acerca de este hecho (paso S404) . Si no hay certificado de correspondencia (paso S403), se juzga que la autenticación es una falla, y se hace una notificación acerca de este hecho (paso S405) . Se señala que antes de que se juzgue en el paso S404 que es exitosa la autenticación, también es posible concluir que la autenticación es exitosa después de verificar que cada uno de los certificados X.509 en la cadena de certificados satisface "esta fecha y tiempo de actualización < la fecha y tiempo actual < a siguiente fecha y tiempo de actualización" . Adicionalmente, además de verificar si los certificados de raíz corresponden, también es posible juzgar que la autentificación es exitosa/no exitosa después de realizar, antes de S402, la verificación mostrada en la Figura 31 ~ Figura 33 para ver si los certificados en la cadena de certificados están en una relación de cadena o no. Adicionalmente, las descripciones anteriores sean dado para el caso donde un certificado que se debe reemplaza se especifica en base al nombre del emisor, pero el certificado también se puede especificar en base a otro valor de atributo tal como el nombre del sujeto. Cuarta modalidad Cuando un programa Java (PPVlXlet. Class 2144 o PPV2Xlet. Class 2115) incluido en el sistema de archivo se va a activa en un cierto periodo de tiempo después de que se almacena este sistema de archivos, es un caso donde se revoca un certificado debido a razones diferentes de la validez de cualquiera de los certificados X.509 incluidos en el archivo "/ocap.certificates.l" 2119 se vence y que se reemplazo el certificado de raíz. Esta configuración permite que el programa Java se active aún cuando se revoque el certificado. Aquí, CRL (Lista de Revocación de Certificado) es un revocador ampliamente reconocido de certificados. La Figura 41 es un diagrama que muestra la estructura de una CRL. Aquí, sólo se ilustran los atributos necesarios para explicar la presente invención. Para mayor detalles acerca de la CRL, referirse a IETF RF C3280 "Internet X.509 Public Key INfrastructure Certifícate and CRL Profile" . 411 indica un área de atributos de la CRL, 412 indica el algoritmo de identificación de un valor 413 de identificación, y 413 indica el valor de identificación de la CRL. El nombre 4111 de emisor indica el emisor de esta CRL, esta fecha y tiempo 4112 de actualización indica la fecha y tiempo cuando llega a ser válida la CRL, la siguiente fecha y tiempo 4113 de actualización indica la fecha y tiempo cuando vence la validez de la CRL, y la lista 4114 de certificados revocados indica la información acerca de los certificados X.509 revocados. La Figura 42 es un diagrama que muestra la estructura de la lista 4114 de certificados revocados. Sólo se ilustran aquí también los atributos que son necesarios par explicar la presente invención. La información acerca de una pluralidad de certificados X.509 revocados se almacena en la lista 4114 de certificados revocados. En el caso de la Figura 42, como información acerca de un "certificado A" 421 revocado, se incluye un número de serie 4211 para identificar de forma única el certificado y fecha y tiempo 4212 cuando el "certificado A" 421 llega a ser revocado. Otros certificados revocados también son equivalentes a 421. La Figura 43 es una configuración de ejemplo de un sistema de archivos que incluye una CRL. Un directorio "/" 431, un directorio "a" 421, un archivo "SimpleXLet . class" 433, los archivos "ocap.hashfile" 434 ~ 435, un archivo "ocap.certificates.l" 436, un archivo "ocap.signaturefile.l" 437, un archivo "ocap. cr1.2" 438, y un archivo "ocap. certificates .2" 439 se almacenan de manera interna. La autenticación en el sistema de archivos que no incluye una CRL es como se describe en la primera modalidad. De esta manera, se pone enfoque en la primera modalidad en el archivo "ocap. cr1.2" 438 que se estructura en el formato de CRL y el archivo "ocap. certificates .2" 439 que es la cadena del certificado de este archivo. Se señala que de acuerdo a la especificación de OCAP, la cadena de certificados de "ocap.crl.x" es "ocap.certificates .x. En el caso de la Figura 43, la cadena de certificados del "ocap.crl.2" es "ocap. certificates .2" . La Figura 46 es un diagrama esquemático que muestra el archivo "ocap.hashfile" 434. 461 muestra los detalles del archivo ocap.hashfile 434. El archivo ocap.hashfile en 461, que existe en el directorio "/" 431 incluye los valores de troceo relacionados a cada uno de los archivos "ocap.certificates.l" 436, el archivo "ocap.signaturefile.l" 437, el directorio "a" 432, y el archivo "ocap.crl.2" 438, y el archivo "ocap. certificates .2" 439 que existen en el mismo directorio 431. La Figura 44 es un diagrama de flujo para explicar la autentificación de una CRL. La siguiente descripción se da para un ejemplo en el cual el sistema de archivos tiene la configuración mostrada en la Figura 43. Aquí, esta fecha y tiempo 4112 de actualización y la siguiente fecha y tiempo 4113 de actualización se extraen de la CRL (paso S441), y se verifica si la fecha y tiempo actual están entre esta fecha y tiempo 4112 de actualización y la siguiente fecha y tiempo 4113 de actualización (paso S442). Si no es así, esta CRL se juzga que es inválida (paso S447) . Si la fecha y tiempo actual están entre éstos, se calcula un valor de cálculo de direccionamiento para el área 411 de atributos a fin de verificar el valor de identificación del archivo "ocap.crl.2" 438 (paso S443) . Al mismo tiempo, la clave pública 2417 del certificado 2313 de hojas se extrae del archivo "ocap. certificates .2" 439, que es una cadena de certificados (paso S444) , y el valor 413 de identificación del archivo "ocap.crl.2" 438 se desencripta con la clave pública 2417 extraída (paso S445) . Entonces, se verifica si el valor de cálculo de direccionamiento obtenido en el paso S433 es igual al valor desencriptado obtenido en el paso S445 (paso S446) . Si no son iguales, se juzga que la CRL es inválida (paso S447) . Si son iguales, con referencia a la Figura 45, se realiza la autentificación para el archivo "ocap. certificates.2" 439 que es una cadena de certificados (paso S451) . Un método para autentificar la cadena de certificados es el mismo como aquel mostrado en la Figura 31 a la Figura 33, y por lo tanto no se describe en la presente. De manera subsiguiente, se juzga si la autenticación de la cadena de certificados es exitosa o no (paso S452), y si la autenticación es una falla, esta CRL se juzga que es inválida (paso S456) . Entre tanto, si es exitosa la autenticación, la unidad secundaria 510 de almacenamiento se busca para un certificado que es el mismo como el certificado de raíz (paso S453). Aquí, si no hay certificado de raíz de correspondencia, se juzga que la autenticación es una falla y que esta CRL es inválida (paso S456) , en tanto que se si se incluye un certificado de raíz de correspondencia, se juzga que la autenticación es exitosa y que la CRL es válida (paso S455) . Lo siguiente describe una solución al problema de la activación de un programa Java a pesar de la revocación de un certificado de acuerdo a la CRL. A fin de soportar esto, existe tecnología para juzgar si o no un certificado que se usó para autentificar un programa Java es uno revocado en la CRL, cuando se hace una notificación de activación para este programa Java. La Figura 26 muestra los elementos constituyentes de esta tecnología. Excepto por 262 al cual se hace una adición y 269 que aún no se ha descrito, no se da descripción para los elementos constituyentes que se han descrito anteriormente. La unidad 262 de juicio, que es además capaz e autenticar una CRL, pide a la unidad 269 de especificación de certificación de certificado que especifica un certificado que se va a revocar por la CRL. Entonces, la unidad 261 de recepción de notificación recibe una instrucción de autenticación para un programa Java que está relacionado a un certificado revocado especificado por la unidad 269 de especificación de revocación de certificado, la unidad 262 de juicio juzga que la autenticación es una falla. Entre tanto, cuando la unidad 261 de recepción de notificación recibe una instrucción de autenticación para el programa Java en el estado en el cual la unidad 262 de juicio ha fallado en autenticar la CRL y por lo tanto juzga que la CRL es válida, la unidad 262 de juicio juzga que la autenticación es exitosa. Cuando la unidad 262 de juicio reconoce que fue exitosa la autenticación de la CRL, la unidad 269 de especificación de revocación de certificado especifica que uno de los certificados X.509 extraído por la unidad 265 de extracción de certificado es un certificado revocado. Como diagramas de flujo, se adicionan la Figura 47 y la Figura 48. La siguiente descripción se da de acuerdo a estos diagramas de flujo. Asumiendo que se hace ahora una instrucción de autenticación para el sistema de archivos mostrado en la Figura 21, se inician los procesos mostrados en el diagrama de flujo de la Figura 35, y se termina en debido tiempo el proceso del paso S357. Asumiendo que entonces se acepta una instrucción de autenticación para otros sistemas de archivo mostrado en la Figura 43, se ejecutan del paso S471 al paso S477 después de la terminación de los procesos mostrados en el diagrama de flujo de la Figura 44. Los procesos del paso S471 al paso S477 son los mismos como aquellos del paso S351 al paso S357. Cuando el paso S478 se alcanza y si la autenticación del archivo "ocap. cr1.2" 438 (los diagramas de flujo de la Figura 44 y la Figura 45) es exitosa, la información acerca de los certificados revocados contenida en este archivo se describen a la base de datos de los certificados revocados. La Figura 49 es un diagrama esquemático que muestra la base de datos de los certificados revocados. Se almacenan nombres de emisor en una columna 491, se almacenan números de serie de certificado en una columna 492, y en la columna 493 se almacenan fechas y tiempos de revocación. Aquí, cuando se acepta (paso S481) una instrucción de autenticación para el "PPVlXletl . class" 2114, se verifica si cualquiera de los certificados X.509 incluido en la cadena 231 de certificado del archivo "ocap.certificates.l" 2119 se incluye en la base de datos de certificados revocados (paso S483). Si cualquiera de los certificados aplica, se juzga que la autenticación es una falla y se hace una notificación acerca de esto (paso S486) . Entre tanto, cuando no hay certificado aplicable, se realiza una verificación para la cadena total de certificado (paso S484) , y se hace una notificación que juzga si la autenticación es exitosa (paso S485) . A través de los procesos anteriores, es posible solucionar el problema que el programa Java que no se debe activar se active, al juzgar que la autenticación del archivo es una falla para un sistema de archivos cuyo certificado fue válido en el tiempo de desmodulación pero que se volvió revocado por la CRL por el momento en que se activó el programa Java . Se señala que cuando se recibe una instrucción de autenticación para un programa Java, también es posible realizar adicionalmente la verificación para ver si la estructura de árbol de un sistema de archivos es correcta o no por el uso de "ocap.hashfile" colocado en cada directorio. Adicionalmente, sólo hay un certificado intermedio en una cadena de certificados para propósitos de simplificación, pero puede haber una pluralidad de certificados intermedios. Sin embargo, debe haber una relación de cadena entre todos los certificados intermedios cuando se realiza la autenticación de su cadena de certificados. Además, se han descrito los siguientes procesos a fin de mencionar, pero la presente invención no se limita a este orden: verificar la presencia/ausencia de alteración; la autenticación de una cadena de certificados; y verificar para ver si la unidad de almacenamiento secundaria incluye un certificado de raíz que son los mismos como el certificado de raíz en la cadena de certificados. Adicionalmente, en cuanto al almacenamiento de un sistema de archivos, el gestor 1205f de seguridad puede almacenarlo usando la biblioteca 1201b del OS. También, la primera a cuarta modalidades también son aplicables al caso donde se proporciona el "archivo de descripción de aplicación" en el directorio "/" de nivel superior de un sistema de archivos, y como sus contenidos, sólo se indica una parte del sistema de archivos como los archivos que se van a almacenar. De esta manera, no se presentan problemas y sólo se manejan archivos que se van a almacenar. Además, se han descrito anteriormente programas como objetivo de almacenamiento, pero también pueden ser objetivos de almacenamiento datos diferentes de los programas, significando que de la primera ala cuarta modalidades también son aplicables a los datos. Adicionalmente, existe la posibilidad que más de un "ocap. certificates .x" corresponda a "ocap. signaturefile .x" , caos en el cual la autenticación de al menos uno de los archivos "ocap. certificates .x" se requiera que sea exitosa. También, "ocap. certificates .x" se ha presentado como una cadena de certificados de ejemplo, "ocap.hashfile" se ha presentado como un archivo de ejemplo que tiene un valor de cálculo de direccionamiento, y "ocap. signaturefile.x" se ha presentado como un archivo de ejemplo para verificar si "ocap.hashfile" en un directorio de "/" se ha alterado o no, por la presente invención no se limita a estos nombres de archivo . Además, en el caso de falla de autenticación, se puede realizar la autenticación nuevamente después de la redescarga .

Quinta modalidad Hasta este punto, se ha llevado a cabo la explicación para el caso de descargar un programa Java de ondas de difusión. De aquí, se debe hacer una explicación con respecto a la autenticación en el caso de la descarga de un archivo mediante una red representada por la Internet. La descarga de un programa Java mediante una red se ha considerado aún en la especificación de DVD-MPH "ETSI TS 101 812 VI.2.1 DVB-MHP Standard 1.0.2", y la especificación de OCAP "OpenCable (MR) Application Plattaform Specification OCAP 1.0 Profile (OC-SP-OCAPl .0-111-040604) . Al mismo tiempo, existe una tecnología para poner conjuntamente varios archivos como uno en un formato de archivo llamado JAR (archivo Java) que se basa en el formato de archivo ZIP bien conocido. Usando esta tecnología, el tamaño del archivo se comprime y se puede acortar el tiempo requerido para descargar, en comparación a cuando no se usa JAR. Sin embargo, cuando se usa JAR en caso donde se actualicen frecuentemente los datos localizados en el servidor, se requiere que los archivos se vuelvan a elaborar en el formato JAR cada vez que se actualizan los datos. Esto reparte una carga al servidor y hay casos donde no es deseable. Por ejemplo, el caso de un servidor que proporciona un programa que usa información de precios de inventario cae bajo esta categoría puesto que la información de los precios de inventario y similares cambia constantemente el tiempo real. Más adelante en la presente, se debe enfocar al caso donde se colocan archivos y directorios en un estructura jerárquica en el servidor, sin el uso de JAR. Aún en el caso donde un aparato terminal de descargue de un servidor mediante una red, existe la necesidad de verificar que los archivos que configuran el programa se garanticen, si el programa que se va a descargar es un programa asignado. Adicionalmente, los archivos que configuran un programa se requieren cuando se instala realmente y se activa el programa. Sin embargo, cuando se descarga del servidor entre el tiempo de certificación e instalación (o activación del programa) , aún si la terminal termina la autenticación, existe la posibilidad que el programa en el servidor se alterará en el momento en que se descargue durante la instalación. De esta manera, una invención que supera este problema se describe más adelante en la presente. La Figura 50 ilustra una tabla que muestra esquemáticamente la AIT o la XAIT. En comparación con la Figura 20, una columna 5003 es diferente y se adiciona una columna 5006. Además de esto, la columna 5001 a la columna 5005, tienen el mismo significado como la columna 2001 a la columna 2005, respectivamente, en la Figura 20. Sin embargo, la columna 5003 es el identificador de DSMCC descrito anteriormente cuando el valor es "1" y es un identificador IP que indica la descarga de un programa Java mediante una red IP cuando el valor es "2". La columna 5004 describe el nombre del programa del programa Java. La columna 5005 describe la prioridad del programa Java. La columna 5006 describe la URL que indica el servidor en el cual está el programa Java que se va a descargar y su posición de almacenamiento. Una línea 5011 describe un conjunto de información de programa Java. El programa Java definido en la línea 5011 es el conjunto que tiene un identificador "OX5001", la información de control "autoinicio", un identificador "2" y un nombre de programa "a/PPV3Xlet" . Se conoce de la ID de aplicación de identificador del programa Java que el programa Java es un programa asignado. Puesto que la URL es http://panasonic.com/app, el aparato terminal descarga el programa Java del directorio asignado a "app" de "panasonic.com", y su subdirectorio, usando HTTP. Aquí, HTTP con mayúsculas es una tecnología bien conocida que es ampliamente usada en la actualidad cuando se descarga una página de inicio de un servidor web en otro lado de la Internet. El HTTP se describe en detalle en RFC2612. Aquí, aunque sólo se especifican seis puntos de información para el programa Java, la presente invención se puede implementar aún cuando se definan más puntos de información. La Figura 51 es un diagrama esquemático que muestra una configuración cuando se descarga un programa Java mediante una red IP. Un centro distribuidor 5101 y un aparato terminal 5102 se conectan mediante una red 5104 de CATV. Adicionalmente, el centro distribuidor 5101, el aparato terminal 5102 y un servidor 5103 donde se localiza un programa Java, se conectan mediante una red 5105 IP tal como la Internet . La Figura 52 ilustra los elementos constituyentes de la AM 1205b. una unidad 5201 de extracción de información de señal extrae la información de señal de AIT o XAIT, de la manera anteriormente descrita, y esta información de señal se pasa sobre una unidad 5202 de construcción de jerarquía de archivos. La unidad 5202 de construcción de jerarquía de archivos descarga secuencialmente, mediante el POD 504, un programa Java localizado en el servidor 5103 así como archivos relacionados a este programa Java, y construye, en el área de la unidad 511a primaria de almacenamiento, la jerarquía de archivos que es la misma como aquella en el servidor 5103. Cuando se termina la construcción de la jerarquía, el gestor 1205f de seguridad instruye para empezar la autenticación. Cuando es exitosa la autenticación, la construcción, la unidad 5202 de construcción de jerarquía de archivos pide una unidad 5203 de instalación que se instale, y la unidad 5203 de instalación empieza la instalación. La autenticación de un programa Java descargado mediante una red IP se debe explicar con referencia a la Figura 51 y Figura 52. Cuando una XAIT que indica, "0x5001" como el identificador 5001 de programa Java, "autoinicio" como la información 5002 de control para el programa Java, "2" como el identificador 5003 de IP, " /a/PPV3Xlet " como un nombre 5004 de programa, "200" como la prioridad 5005, y "http://panasonic.com/app" como la URL 5006, se signa al aparato terminal 5102 del centro distribuidor 5101 de la Figura 51, la unidad 5201 de extracción de información de señal interpreta primero esta información de señal. En este caso, juzga del valor del identificador del programa Java que el programa Java es un programa signado, y juzga del identificador IP que la descarga se está llevando a cabo mediante una red IP. Entonces se envía una instrucción a la unidad 5202 de construcción de jerarquía de archivos para construir, en la unidad primaria 511 de almacenamiento, una jerarquía de archivos que es la misma como la jerarquía de archivos que existe en la URL "http://panasonic.com/app" en el servidor 5103. La Figura 53 muestra un ejemplo de la jerarquía de archivos de la URL "http://panasonic.com/app". 5301 es la jerarquía completa de archivos de "http://panasonic.com/app", 5302 es el directorio de raíz de 5301, 5303 y 5307; 5304 y 5305 tienen el mismo significado como 2116-2118, 2119 y 2120, respectivamente, y por lo tanto se omite su explicación. 5308 es un programa Java y 5309 muestra los datos leídos del programa Java. 5401 en la Figura 54A y 5402 en la Figura 54B ilustran los detalles de "ocap.hashfile" 5305 y 5307, respectivamente. Puesto que los significados para 5401 y 5402 son los mismos como la explicación de la Figura 22, se debe omitir aquí la explicación. Al recibir la instrucción de la unidad 5201 de instrucción de información de señal, la unidad 5202 de construcción de jerarquía de archivos descarga primero "ocap.hashfile" 5303 usando http. Se señala que aunque más adelante en la presente se asume el uso de http para la descarga mediante una red IP, también son suficientes otros protocolos en tanto que sea posible la descarga. Como se conoce del "ocap.hashfile" 5303 que el "/" 5302 incluye "ocap.certificates.l", "ocap.signaturefile.l", y "a", estos se descargan de forma secuencial. Aquí, cuando la descarga falla puesto que "a" es un directorio. En ese momento, se intenta la descarga de "a/ocap.hashfile" . Puesto que realmente existe "a/ocap.hashfile" 5307, la descarga es exitosa, y se colocan como archivos "ocap.hashfile", "ocap.certificates.l", y "ocap.signaturefile.l", y además, "a" se coloca como un directorio, en la unidad 511 primaria de almacenamiento. Además, cuando se lee la existencia de "PPV3Xlet. class" y "data.txt" en el directorio "a" del "a/ocap.hashfile", estos se descargan, y una jerarquía de archivos que es la misma como aquella de la URL "http://panasonic.com/app" se construye en la unidad 511 primaria de almacenamiento. Además, en el caso donde un programa Java se va a almacenar en la unidad 510 secundaria de almacenamiento, la jerarquía de archivo se puede construir en la unidad 510 secundaria de almacenamiento, en lugar de la unidad primaria 511 de almacenamiento. Además, si se incluye un "archivo de descripción de aplicación" en el caso donde el programa Java se va a almacenar en la unidad secundaria 510 de almacenamiento, se puede referir para la construcción de la jerarquía de archivos en lugar del "ocap.hashfile", puesto que el "archivo de descripción de aplicación" incluye información en la jerarquía de archivo. Cuando la unidad 5202 de construcción de jerarquía de archivo construye la jerarquía de archivos, el gestor 1205f de seguridad se instruye para autenticar la jerarquía de archivos construida. Aunque se lleve a cabo la autenticación de la jerarquía de archivos cuando el gestor 1205f de seguridad recibe la instrucción de autenticación, se debe omitir la explicación con respecto a la autenticación puesto que se ha descrito ya anteriormente. La Figura 55 muestra un diagrama de flujo durante la autenticación de un programa descargado mediante una red. Cuando la XAIT mostrada en 5011 se recibe (paso S5501) , se juzga del identificador 5001 de programa Java si es un programa signado o un programa no signado (paso S5502). Si no es un programa signado, se llevan a cabo la instalación y activación "paso S5507) . Si es un programa signado, se lleva a cabo la verificación en cuanto a si es un identificador de DSMCC o un identificador IP (paso S5503). Si es un identificador IP, la jerarquía de archivos indicada por la URL 5006 se construye en la unidad primaria 511 de almacenamiento o la unidad secundaria 510 de almacenamiento, que es un área local (paso S5504) . En el caso donde sea un identificador de DSMCC en el paso S5503, o cuando se termina el paso S5504, el gestor 1205f de seguridad se instruye para autenticar la jerarquía de archivos que existe en el área local (paso S5505) . El paso 5505 corresponde al diagrama de flujo en la Figura 27. Entonces, depende de si o no el gestor 1205f de seguridad sea exitosa con la autenticación (paso S5506) , con la instalación y activación del programa que se lleva a cabo si es exitoso (paso S5507). Adicionalmente, puede fallar la autenticación de parte de o todos los archivos localizados en el servidor. Esto es debido a que es concebible que la descarga se lleve a cabo durante el tiempo de actualización. En la preparación para estos casos, la descarga y autenticación se pueden recuperar durante un número predeterminado de veces o después de esperar que transcurra una cantidad predeterminada de tiempo. Además, también es posible exhibir un mensaje que indique la falla de la autenticación en la pantalla 509 para avisar al usuario para que decida sí o no reintentar. Adicionalmente, durante la descarga de un programa Java de la XAIT en la Figura 56, hay casos donde la jerarquía de archivos del programa localizado en el servidor 5103 posee la jerarquía de archivo mostrada en la Figura 57, y los detalles de "ocap.hashfile" 5611, 5621 y 5631 corresponden a 5710 en la Figura 58A, 5720 en la Figura 58B, y 5730 en la Figura 58C, en otras palabras, hay casos donde se lleva a cabo la autenticación usando diferentes archivos de autenticación (ocap. certificate.x y ocap. signaturefile. x) para el directorio "/b" 5630 y el directorio "/" 5610. En este punto, puesto que el algoritmo de cálculo de clave del directorio "/b" se representa como "no autenticado", como se muestra en 5710 de la Figura 58A, el directorio "/b" y más abajo están temporalmente fuera del alcance de la autenticación. Bajo esta condición, cuando se da una señal que activa un programa bajo el directorio "/a" 5620 en lugar del directorio "/b" 5630, la unidad 5202 de construcción de jerarquía de archivos crea un directorio "/b" vacío en el área local, y el directorio "/b" 5630 per sé, no necesitan ser construidos. El directorio "/b" 5630 se puede construir en el área local donde hay un acceso hecho en o por abajo del directorio "/b" 5630 y se requiere la autenticación, tal como cuando "PPV4Xlet .class" 5622 intenta subsiguientemente usar "PPVvideo.mpg" 5635 por abajo del directorio "/b" 5630, o cuando la activación de "PPV5Xlet. class" 5634 por abajo del directorio "/b" 5630 se signa. Además, lo mismo se aplica, no sólo a los directorios, sino también a los archivos, y se crea alternativamente un archivo vacío que tiene un tamaño "0" en el área local de modo que un archivo designado como "no autenticado" no necesita ser descargado a la jerarquía de archivos del área local. Sin embargo, cuando hay un acceso a este archivo, se lleva a cabo la descarga a la jerarquía de archivos. La creación de un directorio vacío o un archivo vacío se lleva a cabo puesto que el nombre de archivo/nombre de directorio listado en el archivo inservible y el nombre de archivo/nombre de directorio que existe dentro de la jerarquía de archivos debe corresponder entre sí . Adicionalmente, hay casos donde el programa Java signado instalado y activado de la jerarquía de archivos construida en el área local pueden descargar un archivo en el mismo directorio como este programa Java, mediante una red IP.

Si por oportunidad, el programa Java descarga de forma no intencional parte de un programa (archivo de clase) que puede dañar el aparato terminal, la operación del mismo ocasiona algo crítico. Por consiguiente, en el caso donde una petición de instalación para un archivo de clase se origina en el programa Java, la unidad 5203 de instalación verifica con la unidad 5202 de construcción de jerarquía de archivos en cuanto a si está correcto instalar este archivo de clase. Cuando se pide por la unidad 5203 de instalación para verificar si está correcto instalar, la unidad 5202 de construcción de jerarquía de archivos encuentra sí o no este archivo de clase está listado en el ocap.hashfile que existe en la jerarquía de archivos. La instalación de este archivo de clase se permite si se lista, y si no, se retrasa la instalación. Además, hay la necesidad de preparar el caso donde el ocap.hashfile se sobrescribe y llega a ser bloqueado si se lista o no el archivo de clase. En la instalación de un archivo de clase, es posible dar instrucciones al gestor 1205f de seguridad para llevar a cabo la autenticación, pedir a la unidad 5202 de construcción de jerarquía de archivos que verifique si está correcto instalar el archivo de clase, y llevar a cabo la instalación únicamente cuando sea exitosa la autenticación y la autorización de instalación. Aunque algunas modalidades de ejemplo de esta invención se han descrito en detalle anteriormente, aquellos expertos en la técnica apreciarán fácilmente que son posibles muchas modificaciones en las modalidades de ejemplo sin apartarse materialmente de las nuevas enseñanzas y ventajas de esta invención. Por consiguiente, todas estas modificaciones se propone que se incluyan dentro del alcance de esta invención. Aplicabilidad industrial El método para autenticar y ejecutar un programa en la presente invención puede construir, en un área de almacenamiento local, la misma jerarquía de archivos como en el servidor y garantizar la credibilidad de un programa, y es útil para una mejora de función, adición de función y demás, en un receptor de televisión digital. Además, el método para autenticar y ejecutar un programa en la presente invención se puede aplicar, no sólo en una televisión digital, sino también en aplicaciones tal como mejora de función, adición de función y demás, en dispositivos de información controlados por programa de cómputo, tal como una computadora personal y un teléfono móvil. Se hace constar que con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la presente invención, es el que resulta claro a partir de la presente descripción de la invención.

Claims

REIVINDICACIONES
Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes reivindicaciones: 1. Método para autenticar y ejecutar un programa, caracterizado porque comprende: un paso de autenticación y almacenamiento de i) descargar, desde un servidor predeterminado, un programa constituido de al menos un archivo de datos, en una estructura de directorio, que requiere verificación de alteración, de acuerdo a la información que identifica una ubicación de almacenamiento de un programa, ii) autenticar el archivo de datos descargado que requiere verificación de alteración, y iii) almacenar el programa en un receptor de difusión, la información que se especifica en una corriente de transporte, y el servidor que se conecta a una red; y un paso de ejecución para ejecutar el programa de autenticado; en donde el paso de autenticación y almacenamiento incluyen: un primer paso de descarga, en el receptor de difusión, todos los archivos de datos que requieren verificación de alteración listados en un archivo inservible para tener una estructura de directorio que es la misma como la estructura de directorio del programa almacenado del servidor, en base a un directorio y un archivo de datos listados en el archivo inservible incluido en un directorio que constituye la estructura de directorio; un segundo paso para verificar si dos valores de troceo corresponden o no, uno de los valores de troceo que se calcula de cada uno de los archivos de datos que requieren verificación de alteración y el otro valor de cálculo de direccionamiento que se almacena en el archivo inservible que lista los archivos de datos; un tercer paso para verificar la validez de un archivo de certificado incluido en el programa un cuarto paso de verificar si un valor de desencriptado y un valor de cálculo de direccionamiento corresponden o no, el valor de desencriptado que se obtiene al desencriptar un valor de identificación de un archivo de identificación incluido en el programa usando una clave pública de un certificado de entrada incluido en el archivo de certificado del programa, y el valor de cálculo de direccionamiento que se calcula de un archivo inservible localizado en un directorio superior del programa; y un quinto paso de autenticar el programa y almacenar el programa autenticado, en el caso donde se satisfacen todo lo siguiente: los dos valores de troceo se verifica que correspondan en el segundo paso; el archivo de certificado se verifica que es válido en el tercer paso; y el valor desencriptado y el valor de cálculo de direccionamiento se verifica que correspondan en el cuarto paso, y el paso de ejecución incluye un paso de verificación para verificar si el archivo de certificado incluido en el programa almacenado es válido o no, y en el paso de ejecución, el programa almacenado se autentica nuevamente y se ejecuta sólo en el caso donde el archivo de certificado incluido en el programa almacenado se verifica que es válido en el paso de verificación. 2. Método de conformidad con la reivindicación 1, caracterizado porque el tercer paso incluye un sexto paso para verificar si dos certificados de raíz corresponden o no, uno de los certificados de raíz que está en el archivo de certificado incluido en el programa y el otro certificado de raíz que se localiza en el receptor de difusión, y en el tercer paso, el archivo de certificado se verifica que sea válido donde los dos certificados de raíz correspondan .
3. Método de conformidad con la reivindicación 2 , caracterizado porque el tercer paso incluye además: un séptimo paso para verificar un periodo de validez de cada certificado en el archivo de certificado incluido en el programa, y en el tercer paso, el archivo de certificado se verifica que sea válido en el caso donde se satisfacen ambos de los siguientes: los dos certificados de raíz corresponden y el momento en el cual se realiza la autenticación está dentro del periodo de validez de cada certificado en el archivo de certificado.
4. Método de conformidad con la reivindicación 1, caracterizado porque el paso de verificación incluye: un octavo paso para verificar si los dos certificados de raíz corresponden o no, o uno de los certificados de raíz que está en el archivo de certificado incluido en el programa almacenado y el otro certificado de raíz que se localiza en el receptor de difusión, y en el paso de verificación, el archivo de certificado incluido en el programa almacenado verifica que sea válido en el caso donde correspondan los dos certificados de raíz.
5. Método de conformidad con la reivindicación 4, caracterizado porque el paso de verificación incluye además un noveno paso para verificar un periodo de validez de cada certificado en el archivo de certificado incluido en el programa almacenado, y en el paso de verificación, el archivo de certificado incluido en el programa almacenado verifica que sea válido en el caso donde se satisfagan ambas de los siguientes: los dos certificados de raíz corresponden; y el tiempo en el cual se realiza la ejecución está dentro del periodo de validez de cada certificado en el archivo de certificado.
6. Método de conformidad con la reivindicación 1, caracterizado porque el programa no se almacena en el caso donde se satisface al menos uno de lo siguiente: los dos valores de troceo no se verifica que correspondan en el segundo paso; el archivo de certificado no se verifica que sea valido en el tercer paso; y el valor desencriptado y el valor de cálculo de direccionamiento no se verifica que corresponda en el cuarto paso.
7. Método de conformidad con la reivindicación 1, caracterizado porque el primer paso incluye un décimo paso de construir, por abajo de un directorio superior en el receptor de difusión, un directorio que es el mismo como un directorio especificado por un archivo inservible, y descargar en el directorio correspondiente construido en el receptor de difusión, un archivo de datos que requiere verificación de alteración especificada por un archivo inservible almacenado en el directorio especificado por el archivo inservible almacenado en el directorio superior en el servidor, en el caso donde el directorio se especifique por el archivo inservible almacenado en el directorio superior que constituye el programa, en el servidor.
8. Aparato para autenticar y ejecutar un programa, caracterizado porque comprende: una unidad de autenticación y almacenamiento operable i) para descargar, desde un servidor predeterminado, un programa constituido de al menos un archivo de datos en una estructura de directorio, que requiere verificación de alteración, de acuerdo a información que identifica una ubicación de almacenamiento de un programa, ii) autenticar el archivo de datos descargado que requiere verificación de alteración, y iii) almacenar el programa en un receptor de difusión, la información que se especifica en una corriente de transporte, y el servidor que se conecta a una red, y una unidad de ejecución operable para ejecutar el programa autenticado, en donde la unidad de autenticación de almacenamiento incluyen: una unidad de construcción de jerarquía de archivos operable para descargar, en el receptor de difusión, todos los archivos de datos que requieren verificación de alteración listados en un archivo inservible para tener una estructura de directorio que es la misma como la estructura de directorio del programa almacenado del servidor, en base a un directorio y un archivo de datos listado en el archivo inservible incluido en un directorio que constituye la estructura de directorio; una primera unidad de verificación operable para verificar si dos valores de troceo corresponden o no, uno de los valores de troceo que se calcula de cada uno de los archivos de datos que requieren verificación de alteración y el otro valor de cálculo de direccionamiento que se almacena en el archivo inservible que describe los archivos de datos; una segunda unidad de verificación operable para verificar una validez de un archivo de certificado incluido en el programa; una tercera unidad de verificación operable para verificar si corresponden o no un valor desencriptado y un valor de cálculo de direccionamiento, el valor desencriptado que se obtiene al desencriptar un valor de identificación de un archivo de identificación incluido en el programa usando una clave pública de un certificado de entrada incluido en el archivo de certificado del programa, y el valor de cálculo de direccionamiento que se calcula de un archivo inservible localizado en un directorio superior del programa; y una unidad de almacenamiento operable para autenticar el programa y para almacenar el programa autenticado, en el caso donde se satisfacen todo lo siguiente: los dos valores de troceo se verifica que correspondan por la primera unidad de verificación; el archivo de certificado se verifica que es válido por la segunda unidad de verificación; y el valor desencriptado y el valor de cálculo de direccionamiento se verifica que correspondan por la tercera unidad de verificación, y la unidad de verificación incluye una cuarta unidad de verificación operable para verificar si el archivo el archivo de certificado incluido en el programa almacenado es válido o no, y el paso de ejecución es operable para autenticar nuevamente y para ejecutar el programa almacenado sólo en el caso donde el archivo de certificado incluido en el programa almacenado se verifica que sea válido por la cuarta unidad de verificación.
9. Programa, caracterizado porque es para hacer que una computadora ejecute: un paso de autenticación y almacenamiento de i) descargar, desde un servidor predeterminado, un programa ejecutable constituido de al menos un archivo de datos, en una estructura de directorio, que requiere verificación de alteración, de acuerdo a la información que identifica una ubicación de almacenamiento de un programa ejecutable, ii) autenticar el archivo de datos descargado que requiere verificación de alteración, y iii) almacenar el programa ejecutable en un receptor de difusión, la información que se especifica en una corriente de transporte, y el servidor que se conecta a una red; : y un paso de ejecución para ejecutar el programa ejecutable autenticado, en donde el paso de autenticación de almacenamiento incluye: un primer paso de descarga, en el receptor de difusión, de todos los archivos de datos que requieren verificación de alteración listados en un archivo inservible para tener una estructura de directorio que es la misma como la estructura de directorio del programa ejecutable almacenado del servidor, en base a un directorio y un archivo de datos listado incluido en el archivo inservible incluido en un directorio que constituye la estructura de directorio; un segundo paso para verificar si dos valores de troceo corresponden o no, uno de los valores de troceo que se calcula de cada uno de los archivos de datos que requieren verificación de alteración y el otro valor de cálculo de direccionamiento que está almacenado en el archivo inservible que describe los archivos de datos; un tercer paso de para verificar una validez de un archivo de certificado incluido en el programa ejecutable; un cuarto paso de verificar si un valor de desencriptado y un valor de cálculo de direccionamiento corresponden o no, el valor de desencriptado que se obtiene al desencriptar un valor de identificación de un archivo de identificación incluido en el programa ejecutable usando una clave pública de un certificado de entrada incluido en el archivo de certificado del programa ejecutable, y el valor de cálculo de direccionamiento que se calcula de un archivo inservible localizado en un directorio superior del programa ejecutable; y un quinto paso de autenticar el programa ejecutable y almacenar el programa ejecutable autenticado, en el caso donde se satisfacen todo lo siguiente: los dos valores de troceo se verifica que correspondan en el segundo paso; el archivo de certificado se verifica que sea válido en el tercer paso; y el valor desencriptado y el valor de cálculo de direccionamiento se verifica que correspondan en el cuarto paso, y el paso de ejecución incluye un paso de verificación para verificar si el archivo de certificado incluido en el programa ejecutable almacenado es válido o no, y en el paso de ejecución, el programa ejecutable almacenado se autentica nuevamente y se ejecuta sólo en el caso donde el archivo de certificado incluido en el programa ejecutable almacenado se verifica que sea válido en el paso de verificación.