MXPA06004543A

MXPA06004543A - Metodo para autentificar y ejecutar un programa de aplicacion.

Info

Publication number: MXPA06004543A
Application number: MXPA06004543A
Authority: MX
Inventors: Tadao Kusudo
Original assignee: Matsushita Electric Ind Co Ltd
Priority date: 2003-12-18
Filing date: 2004-12-15
Publication date: 2006-06-23
Also published as: US20100138665A1; CA2542392A1; US20050138397A1; KR101099880B1; CN1898956A; KR20110031506A; JP2007535204A; US20120005481A1; US7698562B2; KR20060128885A; KR20110031505A; KR101070545B1; CN1898956B; WO2005060256A1; US8060749B2

Abstract

De acuerdo con una tecnica convencional, en caso de que un programa sea almacenado en una memoria no volatil una vez y luego activado, la autentificacion del programa se lleva a cabo inmediatamente antes de esta activacion. Sin embargo, se requieren calculos tales como el descifrado de valores cifrados antes de que inicie la activacion del programa, lo cual causa el problema de que la capacidad de respuesta se disminuye en proporcion al tiempo requerido para los calculos. Para poder resolver este problema, la autentificacion de un programa se lleva a cabo inmediatamente antes de que este programa sea almacenado, de tal manera que no se lleva a cabo una autentificacion o solo se lleve a cabo una parte de la autentificacion para verificar la validez de certificados en el momento de la activacion del programa.

Description

METODO PARA AUTENTIFICAR Y EJECUTAR UN PROGRAMA DE APLICACION Campo de la invención La presente invención se refiere a un método de ejecución de programas autentificados que verifica la credibilidad de un programa descargado y ejecuta el programa que ha sido verificado como creíble. Antecedentes de la invención La función en una televisión digital de descargar un programa y revisar/garantizar la credibilidad de este programa se describe en la especificación DVB-MHP "ETSI TS 101 812 VI.2.1" DVB-MHP especificación 1.0.2", y otras. Esta especificación DVB-MHP define la función de verificar que un programa sobrepuesto sobre una onda de transmisión que está siendo recibida no haya sido alterado así como si este programa fue emitido o no por una organización confiable. Esta función hace posible evitar que sean activados un programa rescrito que no opere como se requiere originalmente y por lo tanto pudiera infringir daño a la televisión digital, y un programa de una tercera parte apócrifa. Además, la solicitud de patente japonesa abierta al público No. 2000-29833 describe una técnica, la cual comprende un aparato servidor para acumular y transmitir datos y un aparato terminal para recibir datos- por medio de una red, para evitar que los datos acumulados se usen REF. : 171961 ilícitamente al acumular los datos recibidos en el aparato terminal. La figura 1 de la solicitud de patente japonesa abierta al público No. 2000-29833 ilustra la técnica de que el aparato servidor 10 copia datos almacenados en la unidad de almacenamiento 15 en la unidad de almacenamiento 23 en respuesta a una solicitud del aparato terminal 20, y cuando se desea usar los datos almacenados en la unidad de almacenamiento 23, la unidad de consulta 26 hace una solicitud al aparato servidor 10, la unidad de autentificación 13 lleva a cabo una auditoria acerca del uso de los datos, y si no hay problema, el aparato terminal 20 usa los datos . El aparato anterior es capaz de cargar datos después de revisar la credibilidad de los datos almacenados en una memoria no volátil incluso cuando la energía está encendida/apagada. Revisar la credibilidad de los programas y los datos se refiere en adelante como autentificació . Sin embargo, de acuerdo con una técnica convencional, en el caso de almacenar un programa en una memoria no volátil una vez para de esta manera activar este programa después de que el aparato sea encendido/apagado, la autentificación del programa se lleva a cabo inmediatamente antes de que sea activado. En este caso, es necesario llevar a cabo cálculos tales como descifrado de un valor cifrado antes de que inicie la activación del programa, lo cual causa un problema de que la capacidad de respuesta se disminuye más al requerirse cada vez m s tiempo para los cálculos . Especialmente en el caso en el que un programa se activa frecuentemente o cuando la capacidad de un programa es grande, la capacidad de respuesta se degrada cada vez más toda vez que la cantidad de cálculos se incrementa en proporción a la frecuencia y capacidad de activación. En vista del problema anterior, se desea proporcionar un aparato de autentificación de programas tal como una televisión digital con capacidad de respuesta incrementada que sea capaz de acortar el tiempo requerido antes de que un programa sea activado, garantizando al mismo tiempo la credibilidad del programa. Breve descripción de la invención La presente invención se dirige a proporcionar un método de ejecución de programas autentificados que sea tanto capaz de garantizar la credibilidad como de mejorar la capacidad de respuesta al llevar a cabo una autentificación inmediatamente antes de que un programa sea almacenado, y de no llevar a cabo autentificación alguna o sólo una parte de autentificación en el momento de la activación del programa. Para resolver el problema convencional, el método de ejecución de programas autentificados de acuerdo con la presente invención comprende : una etapa de autentificación y almacenamiento para autentificar un programa incluido en una corriente de transporte y almacenar el programa autentificado en un receptor de transmisión de acuerdo con la información que se refiere al almacenamiento de cada archivo de datos del programa, y una etapa de ejecución para ejecutar el programa almacenado autentificado, en donde la etapa de autentificación y almacenamiento incluye : una primera etapa de verificar si dos valores de refundición son consistentes o no, uno de los valores de refundición siendo calculado a partir de cada archivo de datos incluido en el programa y el otro valor de refundición siendo almacenado en un archivo de refundición que corresponde a cada uno de los archivos de datos; una segunda etapa de verificar si un archivo de certificados incluido en el programa es válido o no; una tercera etapa de verificar si un valor descifrado y un valor de refundición son consistentes o no, el valor descifrado se obtiene al descifrar un valor de firma de un archivo de firmas incluido en el programa usando una clave pública de un certificado de origen incluido en el archivo de certificados del programa, y el valor de refundición se calcula a partir de un archivo de refundición localizado en un directorio superior del programa; y una cuarta etapa de autentificar el programa y almacenar cada archivo de datos del programa autentificado de acuerdo con la información que se refiere al almacenamiento, en caso de que se satisfagan todas las siguientes condiciones: que los dos valores de refundición se verifiquen como consistentes en la primera etapa; que el archivo de certificados se verifique como válido en la segunda etapa y que el valor descifrado y el valor de refundición se verifiquen como consistentes en la tercera etapa, y la etapa de ejecución incluye una quinta etapa de verificar si el archivo de certificados incluido en el programa almacenado es válido o no, y en la etapa de ejecución, el programa almacenado es autentificado nuevamente y ejecutado sólo en caso de que el archivo de certificados incluido en el programa almacenado se verifique como válido en la quinta etapa. En consecuencia, se hace posible acortar el tiempo requerido antes de que un programa se active, mientras se garantiza al mismo tiempo la credibilidad del programa. Más aún, en caso de que el programa tenga una estructura de directorio, cada archivo de datos incluido en cada directorio y el archivo de refundición que corresponde a cada archivo de datos mencionado puede localizarse en un mismo directorio, y la primera etapa puede ejecutarse para cada archivo de datos incluido en cada directorio. En consecuencia, se hace posible revisar, para cada archivo de datos incluido en cada directorio, si el valor de refundición calculado a partir del archivo de datos y un valor de refundición almacenado en un archivo de refundición que corresponde al archivo de datos son consistentes o no. Además, la segunda etapa puede incluir una sexta etapa de verificar si dos certificados de raiz coinciden o no, uno de los certificados de raíz estando en el archivo de certificados incluido en el programa y el otro certificado de raíz estando instalado en el receptor de transmisión, y en la segunda etapa, el archivo de certificados puede verificarse como válido en caso de que coincidan los dos certificados de raíz. Aquí, la segunda etapa puede incluir además una séptima etapa de verificar un periodo de validez de cada certificado en el archivo de certificados incluido en el programa, y en la segunda etapa, el archivo de certificados puede verificarse como válido en caso de que se satisfagan ambas de las siguientes condiciones : que los dos certificados de raíz coincidan y que el tiempo en el cual se lleva a cabo la autentificacion esté dentro del periodo de validez de cada certificado en el archivo de certificados. En consecuencia, se hace posible evitar que un programa sea almacenado en caso de que los certificados de raíz no coincidan y el periodo de validez del certificado haya expirado . Además, la quinta etapa puede incluir una octava etapa de verificar si dos certificados de raíz coinciden o no, uno de los certificados de raíz estando en el archivo de certificados incluido en el programa almacenado y el otro certificado de raiz estando instalado en el receptor de transmisión, y en la quinta etapa, el archivo de certificados incluido en el programa almacenado puede verificarse como válido en caso de que los dos certificados de raíz coincidan. Aquí, la quinta etapa puede incluir además una novena etapa de verificar un periodo de validez de cada certificado en el archivo de certificados incluido en el programa almacenado, y en la quinta etapa, el archivo de certificados incluido en el programa almacenado puede verificarse como válido en caso de que se satisfagan ambas de las siguientes condiciones: que los dos certificados de raíz coincidan y que el momento en el cual se lleve a cabo la ejecución esté dentro del periodo de validez de cada certificado en el archivo de certificados. En consecuencia, se hace posible evitar que un programa sea ejecutado en caso de que los certificados de raiz no coincidan y el .periodo de validez del certificado haya ex irado . Nótese que sólo es posible incorporar la presente invención como un método de ejecución de programas autentificados como el mencionado arriba pero también como un aparato de ejecución de programas autentificados que incluya, como sus unidades, las etapas características incluidas en el método de ejecución de programas autentificados, y como un programa que ocasione que una computadora ejecute estas etapas . También se debe notar que este programa puede distribuirse en un medio de grabación tal como un CD-ROM y por medio de un medio de transmisión tal como la Internet. Como es obvio de las descripciones anteriores, el método de ejecución de programas autentificados de acuerdo con la presente invención es capaz de acortar el tiempo requerido antes de que un programa sea activado, garantizando al mismo tiempo la credibilidad del programa. La descripción de la solicitud de patente japonesa No. 2003-421616 presentada el 18 de diciembre de 2003 y la descripción de la solicitud de E.U.A. provisional No. 60/530663, presentada el 19 de diciembre de 2003, incluyendo la descripción, dibujos y reivindicaciones se incorporan en la presente a manera de referencia en su totalidad. Breve descripción de las figuras Estos y otros objetivos, ventajas y características de la invención se harán aparentes a partir de la siguiente descripción de las mismas tomada en conjunto 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 con una primera modalidad de la presente invención.

La figura 2 es un diagrama que muestra un ejemplo de usar bandas de frecuencia que se usarán para comunicaciones entre un centro distribuidor y aparatos terminales en el sistema de televisión por cable de acuerdo con la presente invención. La figura 3 es un diagrama que muestra un ejemplo de usar bandas de frecuencia que se usarán para comunicaciones entre el centro distribuidor y los aparatos terminales en el sistema de televisión por cable de acuerdo con la presente invención. La figura 4 es un diagrama que muestra un ejemplo de usar bandas de frecuencia que se usarán para comunicaciones entre el centro distribuidor y los aparatos terminales en el sistema de televisión por cable de acuerdo con la presente invención. La figura 5 es un diagrama que muestra una configuración de un aparato terminal en el sistema de televisión por cable de acuerdo con la presente invención . La figura "6 es un diagrama que muestra una vista externa ejemplar del aparato terminal en el sistema de televisión por cable de acuerdo con la presente invención. . La figura 7 es un diagrama que ' muestra una configuración de hardware de un POD 504 de acuerdo con la presente, invención.

La figura 8 es un diagrama que muestra una estructura de un programa almacenado en el POD 504 de acuerdo con 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 es un diagrama que muestra un ejemplo de una corriente de transporte MPEG2. La figura 11 es un diagrama que muestra una vista externa ejemplar de una unidad de entrada 513 en el caso en el que está configurada en forma de un panel frontal. La figura 12 es un diagrama que muestra una estructura del programa almacenado en un aparato terminal 500 de acuerdo con la presente invención. La figura 13A es un diagrama que muestra un ejemplo de una pantalla de presentación visual presentada por un visor 509 de acuerdo con la presente invención, y la figura 13B es un diagrama que muestra un ejemplo de una pantalla de presentación visual que es presentada por el visor 509 de acuerdo con la presente invención. La figura 14 es un diagrama que muestra un ejemplo de información almacenada en una unidad de almacenamiento secundaria 510 de acuerdo con la presente invención.

Las figuras 15A, 15B y 15C son diagramas, que muestran cada uno un ejemplo de información almacenada en una unidad de almacenamiento primaria 511 de acuerdo con la presente invención. La figura 16 es un diagrama esquemático que muestra los contenidos de una PAT especificada en la norma MPEG2 de acuerdo con la presente invención. La figura 17 es un diagrama esquemático que muestra los contenidos de una PMT especificada en la norma MPEG2 de acuerdo con la presente invención. La figura 18 es un diagrama esquemático que muestra los contenidos de una AIT especificada en la norma DVB-MHP de acuerdo con la presente invención. La figura 19 es un diagrama esquemático que muestra un sistema de archivos que será transmitido en el formato "DSMCC de acuerdo con la presente invención. La figura 20 es un diagrama esquemático que muestra los contenidos de XAIT de acuerdo con la presente invención. La figura 21 es un diagrama que muestra un ejemplo de información almacenada en la unidad de almacenamiento secundaria 510 de acuerdo con la presente invención. Las figuras 22A, 22B y 22C son diagramas, que muestran cada uno un ejemplo de archivos que incluyen valores de refundición de archivos o directorios de acuerdo con la presente invención.

La figura 23 es un diagrama que muestra una estructura de una cadena de certificados de acuerdo con la presente invención. La figura 24 es un diagrama que muestra una estructura de un certificado X. 509 de acuerdo con la presente invención. La figura 25 es un diagrama que muestra una estructura de un archivo de firmas de acuerdo con la presente invención. La figura 26 es un diagrama que muestra elementos constituyentes de un módulo de seguridad de acuerdo con la presente invención. La figura 27 es un diagrama de flujo que muestra una operación que será llevada a cabo cuando un sistema de archivos sea autentificado de acuerdo con la presente invención. La figura 28 es una gráfica de flujo en el caso en el que no se lleva a cabo autentificación alguna cuando se recibe una notificación de preactivación de programas de acuerdo con la presente invención. La figura 29 es una gráfica de flujo que muestra una operación que se llevará a cabo cuando una verificación de alteración se lleva a cabo para un sistema de archivos de acuerdo con la presente invención. La figura 30 es una gráfica de flujo que muestra una operación que se llevará a cabo cuando se lleva a cabo una revisión de alteración mediante el uso de un archivo de firmas de acuerdo con la presente invención . La figura 31 es una gráfica de flujo que muestra una operación que se llevará a cabo cuando una relación de cadenas entre un certificado de origen y un certificado intermedio se revisa de acuerdo con la presente invención. La figura 32 es una gráfica de flujo que ' muestra una operación que se llevará a cabo cuando una relación de cadena entre un certificado intermedio y un certificado de raíz se revisan de acuerdo con la presente invención. La figura 33 es una gráfica de flujo que muestra una operación que se llevará a cabo cuando una firma en un certificado de raíz se revisa de acuerdo con la presente invenci n . La figura 34 es un diagrama que muestra un ejemplo de un archivo que se usará para especificar archivos que se almacenarán de acuerdo con la presente invención. La figura 35 es una gráfica de flujo que muestra una operación que se llevará a cabo cuando la autentificación de un sistema de archivos se lleva a cabo de acuerdo con la presente invención. La figura 36 es una gráfica de flujo que muestra una operación que se llevará a cabo en el momento de revisar la validez de certificados X. 509 cuando se recibe una notificación de pre-activación de programas de acuerdo con la presente invención. La figura 37 es un diagrama que muestra una estructura simplificada de un archivo de códigos que será recibido desde un módulo de descarga de acuerdo con la presente invención. Las figuras 38A, 38B y 38C son diagramas, que muestran cada uno certificados poseídos por el aparato terminal que es reemplazado de acuerdo con la presente invenci n . La figura 39 es un diagrama de flujo que muestra una operación que se llevará a cabo cuando el reemplazo de certificados se lleve a cabo de acuerdo con la presente invención. La figura 40 es un gráfica de flujo que muestra una operación que se llevará a cabo en el momento de comparar certificados de raíz cuando se reciba una notificación de pre-activación de programa de acuerdo con la presente invención. La figura 41 es un diagrama que muestra una estructura de una GRL de acuerdo con la presente invención. La figura 42 es un diagrama esquemático que muestra una lista de certificados revocados en la CRL de acuerdo con la presente invención.

La figura 43 es un diagrama que muestra un ejemplo de un sistema de archivos que incluye una CRL de acuerdo con la presente invención. La figura 44 es un diagrama de flujo que muestra una operación que se llevará a cabo cuando se revisa la validez de la CRL con base en un valor de refundición y un valor de firma de acuerdo con la presente invención. La figura 45 es un gráfica de flujo que muestra una operación que se llevará a cabo cuando se revisa la validez de la CRL con base en una relación de cadena entre certificados y una comparación entre certificados de raíz de acuerdo con la presente invención . La figura 46 es un diagrama que muestra un ejemplo de un archivo que incluye valores de refundición de archivos o directorios de acuerdo con la presente invención. La figura 47 es una gráfica de flujo que muestra una operación para llevar a cabo la autentificación en caso de que exista una CLR en el momento de almacenamiento de programa de acuerdo con la presente invención. La figura 48 es un gráfica de flujo que muestra una operación para llevar a cabo la autentificación en caso de que exista una 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 que muestra un sistema de archivos ejemplar que incluye archivos que se usan para especificar archivos que se almacenarán de acuerdo con la presente invención y La figura 51 es un diagrama que muestra un archivo ejemplar que se usa para especificar archivos que se almacenarán de acuerdo con la presente invención. Descripción detallada de la invención A continuación se describen modalidades de la presente invención con referencia a las figuras. Primera Modalidad Se da una explicación de una modalidad preferida de un sistema de televisión por cable de acuerdo con la presente invención con referencia a las figuras. La figura 1 es un diagrama de bloques que muestra la relación entre aparatos que componen el sistema de cable, los cuales 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 modalidad, tres aparatos terminales están conectados a un centro distribuidor, pero es posible llevar a cabo la presente invención si un número arbitrario de aparatos terminales se conectan al centro distribuidor. El centro distribuidor 101 transmite, a varios aparatos terminales, señales de transmisión tales como video, audio y datos, y recibe datos transmitidos desde los aparatos terminales. Para lograr esto, las bandas de frecuencia se dividen para usar 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 12 es una tabla que muestra un ejemplo de bandas de frecuencia divididas. Existen casi dos tipos de bandas de frecuencia: Fuera de Banda (que se abreviará como OOB) y En Banda. Una banda de frecuencias de 5 - 130 MHz es asignada a OOB para usarse principalmente para el intercambio de datos entre el centro distribuidor 101 y el aparato terminal Allí, el aparato terminal B112 y el aparato terminal C113. Una banda de frecuencias de 130MHz~864MHz se asigna a En Banda para usarse principalmente por los canales de transmisión que incluyen video y audio. Se emplea QPSK para OOB, mientras que QAM64 se emplea para En Banda como técnicas de modulación. Una explicación detallada de las técnicas de modulación se omite aquí, toda vez que son técnicas conocidas públicamente las cuales no se les menciona mucho en la presente invención. La figura 3 muestra un ejemplo más específico de cómo se usa la banda de frecuencias 00B. Se usa una banda de frecuencias de 70MHz~74MHz para transmitir datos desde el centro distribuidor 101. En este caso, todos los aparatos terminales Allí, el aparato -terminal B112 y el aparato terminal C113 reciben los mismos datos desde el centro distribuidor 101. Mientras tanto, se usa una banda de frecuencias de 10.0MHz~10.1MHz para transmitir datos desde el aparato terminal Allí hasta el centro distribuidor 101. Se usa una' banda de frecuencias de 10. lMHz~10.2MHz para transmitir datos desde el aparato terminal B112 hasta el centro distribuidor 101. Se usa una banda de frecuencias de 10.2MHz~10.3MHz para transmitir datos del aparato terminal C113 al centro distribuidor 101. En consecuencia, se hace posible transmitir datos^ únicos para cada aparato terminal al centro distribuidor 101 desde el aparato terminal Allí, el aparato terminal B112 y el aparato terminal C113. La figura 4 muestra un uso ejemplar de la banda de frecuencias En Banda. Las bandas de frecuencias de 150~156MHz y 156~162MHz se asignan respectivamente a un canal de televisión 1 y un canal de televisión 2, y las frecuencias subsecuentes se asignan a canales de televisión a intervalos de SMHz. Frecuencias de 310MHz y las frecuencias subsecuentes se asignan a canales de radio a intervalos de 1MHz. Cada uno de los canales anteriores puede usarse ya sea para transmisión análoga o transmisión digital . En el caso de transmisión digital, los datos se transmiten en el formato de paquete de transporte que cumple con la especificación PEG2 , en cuyo caso los datos destinados a varios sistemas de transmisión de datos pueden ransmitirse, además de datos de audio y video. El centro distribuidor 101 está equipado con una unidad de modulación QPSK, una unidad de modulación QAM y similares para poder transmitir señales de transmisión adecuadas a las escalas de frecuencia respectivas. Además, el centro distribuidor 101 está equipado con una unidad de desmodulación QPSK para recibir datos provenientes de los aparatos terminales. Asimismo, el centro distribuidor 101 se asume que está equipado además con varios dispositivos relacionados con las unidades de modulación y unidad de desmodulación anteriores . Sin embargo, se omite aquí una explicación detallada de ellos toda vez 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 transmisión transmitidas desde el centro distribuidor 101. Además, el aparato terminal Allí, el aparato terminal B112 y el aparato terminal C113 transmiten datos únicos para cada aparato terminal al centro distribuidor 101. En la presente modalidad, estos tres aparatos terminales tendrán la misma configuración. La figura 5 es un diagrama de bloques que muestra una configuración de hardware de cada aparato terminal . Un aparato terminal está designado con el número 500, el cual está formado de una unidad de desmodulación QAM 501, una unidad de desmodulación QPSK 502, una unidad de modulación QPSK 503, un decodif icador TS 505, un decodificador de audio 50G, un altavoz 507, un decodificador de video 508 , un visor 509, una unidad de almacenamiento secundaria 510, una unidad de almacenamiento primaria 511, una ROM 512, una unidad de entrada 513 y una CPU 514. Además, un POD 504 puede conectarse/desconectarse del aparato terminal 500. La figura 6 muestra una televisión de forma delgada, la cual es una vista externa ejemplar del aparato terminal 500. El aparato terminal puede tener una variedad de configuraciones, pero en la presente modalidad, un aparato terminal que está configurado con base en OpenCable (TM) y OCAP se describe como un ejemplo. 601 Es un estuche de acero de la televisión de forma delgada, en el cual todos los componentes del aparato terminal 500 excepto por el POD 504 están contenidos. 602 Es un visor, el cual corresponde al visor 509 de la figura 5. 603 Es una unidad de panel frontal que está formada de varios botones y la cual corresponde a la unidad de entrada 513 en la figura 5. 604 Es una terminal de entrada de señales a la cual una línea de cable se conecta para transmitir/recibir señales hacia y desde el centro distribuidor 101. La' terminal de entrada de señales está conectada a la unidad de desmodulación QAM 501, la unidad de desmodulación QPSK 502 y la unidad de modulación QPSK 503 mostradas en la figura 5. 605 Es una tarjeta POD que corresponde al POD 504 de la figura 5. El POD 504 está incorporado independientemente del aparato terminal 500 y puede ser conctado/desconectado del aparato terminal 500, como en el caso de la tarjeta POD 605 de la figura 6. Más adelante se da una explicación detallada del POD 504. 606 Es una ranura de inserción dentro de la cual se inserta la tarjeta POD 605. En referencia a la figura 5, la unidad de desmodulación QAM 501 desmodula una señal que ha sido modulada por QAM y transmitida desde el centro distribuidor 101, de acuerdo con información de sintonización que incluye una frecuencia especificada por la CPU 514, y pasa el resultado al POD 504.

La unidad de desmodulación QPSK 502 desmodula una señal que ha sido modulada por QPSK y transmitida desde el centro distribuidor 101,. de acuerdo con información de sintonización que incluye una frecuencia especificada por la CPU 514, y pasa el resultado al POD 504. La unidad de modulación QPSK 503 desmodula por QPSK una señal pasada desde el POD 504, de acuerdo con información de desmodulación que incluye una frecuencia especificada por la CPU 514, y transmite el resultado al centro distribuidor 101. Como se muestra en la figura 6, el POD 504 puede desprenderse 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 CableCARD (TM) de OpenCable (TM) (OC-SP-CC-IF-I15-031121) y en las especificaciones mencionadas por esta especificación. Nótese que CableCARD en esta especificación se refiere a un POD. Aquí, se omite una descripción detallada y se da únicamente una explicación de elementos constituyentes relevantes para la presente invenció . La figura 7 es un diagrama de bloques que muestra una configuración interna del POD 504. El POD 504 está formado de una primera unidad deseudoaleatorizadora 701, una segunda unidad deseudoaleatorizadora 702, una unidad aleatorizadora 703, una unidad de almacenamiento primaria 704, una unidad de almacenamiento secundaria 705 y una CPU 706. La primera unidad deseudoaleatorizadora 701 recibe una señal aleatorizada desde la unidad de desmodulación QAM 501 del aparato terminal 500 bajo la instrucción de la CPU 706, y deseudoaleatoriza esta señal. Después, la primera unidad deseudoaleatorizadora 701 transmite la señal deseudoaleatorizada al decodificador TS 505 del aparato terminal 500. La información que se tiene que deseudoaleatorizar tal como una clave se proporciona por la CPU 706 de acuerdo con las necesidades. M s específicamente, el centro distribuidor 101 transmite varios canales de paga, y cuando el usuario compra el derecho de ver estos canales de paga, la primera unidad deseudoaleatorizadora 701 recibe información requerida tal como una clave desde la CPU 706 y lleva a cabo la deseudoaleatorización. En consecuencia, el usuario puede ver estos canales de paga. Cuando información requerida tal como una clave no se proporciona, la primera unidad deseudoaleatorizadora 701 pasa la señal recibida directamente al decodificador TS 505 sin llevar a cabo la deseudoaleatorización. La segunda unidad deseudoaleatorizadora 702 recibe una señal aleatorizada desde la unidad de desmodulación QPSK 502 del aparato terminal 500 bajo la instrucción de la CPU 706 y deseudoaleatoriza esta señal. Después, la segunda unidad deseudoaleatorizadora 702 pasa los datos deseudoaleatorizados a la CPU 706. La unidad aleatorizadora 703 aleatoriza los datos recibidos desde la CPU 706, bajo la instrucción de la CPU 706, y envía el resultado a la unidad de modulación QPS 503 del aparato terminal 500. La unidad de almacenamiento primaria 704, un elemento constituyente concreto del cual es una memoria primaria tal como una RAM, está destinada a almacenar datos temporalmente cuando la CPU 706 lleve a cabo procesamiento. La unidad de almacenamiento secundaria 705, un elemento constituyente concreto de la cual es una memoria de almacenamiento secundaria tal como una ROM volátil, está destinada a almacenar un programa que se ejecutará por la CPU 706 así como para almacenar datos que nunca deben ser eliminados incluso cuando se apague la energía. La CPU 706 ejecuta el programa almacenado en la unidad de almacenamiento secundaria 705. El programa está formado de varios subprogramas . La figura 8 muestra un ejemplo del programa almacenado en la unidad de almacenamiento secundaria 705. En la figura 8, un programa 800 está formado de varios subprogramas que incluyen un programa principal 801, un subprograma de inicialización 802, un subprograma de red 803, un subprograma de reproducción 804 y un subprograma de PPV 805.

Aquí, PPV, la cual es una abreviatura de Pago Por Evento, se refiere a un servicio que permite que el usuario vea cierto programa tal como una película sobre una base de cobro. Cuando el usuario ingresa su número de identificación personal, el hecho de que el usuario compró el derecho de ver el programa se notifica al centro distribuidor 101, y el programa es deseudoaleatorizado . En consecuencia, el usuario puede ver este programa. Esta visión del programa requiere que el usuario pague por la compra en una fecha posterior. El programa principal 801, el cual es el subprograma activado por la CPU 706 antes que nada cuando la energía es encendida, controla los demás subprogramas . El subprograma de inicialización 802, el cual es activado por el programa principal 801 cuando se enciende la energía, lleva a cabo el intercambio de información y similares con el aparato terminal 500 para llevar a cabo el procesamiento de inicialización. Este procesamiento de inicialización es definido en detalle en Especificación de Interfaz CableCARD (??) de OpenCable (TM) (OC-SP-CC-IF-115-031121) y en especificaciones mencionadas por esta especificación. Además, el subprograma de inicialización 802 también lleva a cabo procesamiento de inicialización no definido en estas especificaciones. Aquí, una parte de este procesamiento de inicialización es introducida. Cuando se enciende la energía, el subprograma de inicialización 802 notifica a la unidad de desmodulación QPSK 502 de una primera frecuencia almacenada en la unidad de almacenamiento secundaria 705 por la CPU 514 del aparato terminal 500. La unidad de desmodulación QPSK 502 lleva a cabo la sintonización usando la primera frecuencia proporcionada, y transmite la señal resultante a la unidad aleatoriazadora secundaria 702. Más aún, el subprograma de inicialización 802 proporciona a la unidad deseudoaleatorizadora secundaria 702 información de deseudoaleatorizacion tal como una primera clave almacenada en la unidad de almacenamiento secundaria 705. Como resultado, la unidad deseudoaleatorizadora secundaria 702 lleva a cabo la deseudoaleatorizacion y pasa el resultado a la CPU 706 que ejecuta el subprograma de inicialización 802. En consecuencia, el subprograma de inicialización 802 puede recibir la información. En la presente modalidad, el subprograma de inicialización 802 recibe información por medio del subprograma de red 803. Más adelante se da una descripción detallada de esto. Además, el subprograma de inicialización 802 notifica a la unidad de modulación QPSK 503 de una segunda frecuencia almacenada en la unidad de almacenamiento secundaria 705 por medio de la CPU 514 del aparato terminal 500. El subprograma de inicialización 802 proporciona a la unidad aleatorizadora 703 información de aleatorización almacenada en la unidad de almacenamiento secundaria 705.

Cuando el subprograma de inicialización 802 proporciona, por medio del subprograma de red 803, a la unidad aleatorizadora 703 la información que tiene que enviarse, la unidad aleatorizadora 703 aleatoriza los datos usando la información de batido proporcionada, y proporciona los datos aleatorizados a la unidad de modulación QPSK 503. La unidad de modulación QPSK 503 modula la información aleatorizada que recibió, y envía la información modulada al centro distribuidor 101. Como resultado, se hace posible que el subprograma de inicialización 802 lleve a cabo una comunicación de dos vías con el centro distribuidor 101 por medio del aparato terminal 500, la unidad deseudoaleatorizadora secundaria 702, la unidad aleatorizadora 703 y el subprograma de red 803. El subprograma de red 803, el cual se usa por varios subprogramas tales como el programa principal 801 y el subprograma de inicialización 802, es un subprograma destinado a llevar a cabo una comunicación bidireccional con el centro distribuidor 101. Más específicamente, el subprograma de red 803 se comporta como si otros subprogramas que usaran el subprograma de red 803 estuvieran llevando a cabo una comunicación bidireccional con el centro distribuidor 101 de acuerdo con TCP/IP. Una explicación detallada de TCP/IP se omite aquí, toda vez que es una técnica públicamente conocida que especifica los protocolos que se usarán cuando se intercambie información entre varias terminales . Cuando es activado por el subprograma de inicialización 802 en el momento del encendido, el subprograma de red 803 notifica, por medio del aparato terminal 500, al centro distribuidor 101 de una dirección MAC (una abreviatura de Control de Acceso a Medios) que es un identificador para identificar el POD 504 y el cual se almacena de antemano en la unidad de almacenamiento secundario 705, para de esta manera solicitar la obtención de una dirección IP. El centro distribuidor 101 notifica al POD 504 de la dirección IP por medio del aparato terminal 500, y el subprograma de red 803 almacena esta dirección IP en la unidad de almacenamiento primaria 704. De ahí en adelante, el centro distribuidor 101 y el POD 504 se comunican uno con otro usando esta dirección IP como el identificador del POD 504. El subprograma de reproducción 804 proporciona la primera unidad deseudoaleatorizadora 701 información de deseudoaleatorización tal como una segunda clave almacenada en la unidad de almacenamiento secundario 705 así como información de deseudoaleatorización tal como una tercera clave proporcionada por el aparato terminal 500, para permitir así que se lleve a cabo la deseudoaleatorización. Más aún, el subprograma de reproducción 804 recibe, por medio de su programa de red 803, información que indica que la señal ingresada en la primera unidad deseudoaleatorizadora 701 es un canal PPV. Después de la notificación de que la señal es un canal PPV, el subprograma de reproducción 804 activa el subprograma PPV 805. Cuando es activado, el subprograma PPV 805 presenta visualmente, sobre el aparato terminal 500, un mensaje que invita al usuario a comprar el programa, y acepta una entrada del usuario. En forma más específica, cuando la información que se desea que sea presentada visualmente sobre la pantalla es enviada a la CPU 514 del aparato terminal 500, un programa que corre en la CPU 514 del aparato terminal 500 muestra el mensaje sobre el visor 509 del aparato terminal 500. Después, cuando el usuario ingresa el número de identificación personal por medio de la unidad de entrada 513 del aparato terminal 500, la CPU 514 del aparato terminal 500 lo acepta, y lo envía al subprograma PPV 805 que corre en la CPU 706 del POD 504. El subprograma PPV 805 envía, al centro distribuidor 101, el número de identificación personal aceptado por medio del subprograma de red 803. Cuando este número de identificación personal es válido, el centro distribuidor 101 notifica, por medio del subprograma de red 803, al subprograma PPV 805 acerca de información de deseudoaleatorización requerida para deseudoaleatorizar tal como una cuarta clave. Subprograma PPV 805 proporciona a la primera unidad deseudoaleatorizadora 701 la información de deseudoaleatorización aceptada tal como la cuarta clave, y luego la primera unidad deseudoaleatorizadora 701 deseudoaleatoriza la señal ingresada. En referencia a la figura 5, el decodificador TS 505 lleva a cabo la filtración de la señal aceptada proveniente del POD 504, y pasa los datos necesarios al decodificador de audio 506, el decodificador de video 508 y la CPU 514. Aquí, la señal enviada desde el POD 504 es una corriente de transporte MPEG2. Una descripción detallada acerca de una corriente de transporte MPEG2 se da en la especificación MPEG ISO/IEC138181-1, y por lo tanto no se explica en detalle en la presente modalidad. Una corriente de transporte MPEG2 está compuesta de varios paquetes de longitud fija, y una ID de paquete se asigna a cada paquete. La figura 9 es un diagrama que muestra la estructura de un paquete. 900 Es un paquete, el cual contiene 188 bytes de longitud fija. Los cuatro bytes superiores es un encabezado 901 que almacena información para identificar el paquete, y los otros 184 bytes es una carga útil 902 que almacena información que se desea portar. 903 Muestra la ruptura del encabezado 901. Una ID de paquete está incluida en trece bytes a partir del primero al doceavo-vigésimo cuarto bit. La figura 10 es un diagrama esquemático que ilustra varias cadenas de paquetes que serán transmitidas. Un paquete 1001 contiene una ID de paquete ¾1" en su encabezado e incluye la primera información de video A en su carga útil . Un paquete 1002 contiene una ID de paquete "2" en su encabezado e incluye la primera información de audio A en su carga útil . Un paquete 1003 contiene una ID de paquete "3" en su encabezado e incluye la primera información de audio B en su carga útil . Un paquete 1004 contiene la ID de paquete ¾1" en su encabezado e incluye la segunda información de video A en su carga útil, la cual es la información subsecuente del paquete 1001. En forma similar, los paquetes 1005, 1026 y 1027 portan datos subsecuentes de los demás paquetes . Al concatenar los contenidos de las cargas útiles de paquetes con las mismas ID de paquetes de la manera anterior, es posible reproducir video y audio en orden sucesivo. Refiérase a la figura 10. Cuando la CPU 514 indica al decodificador TS 505 la ID de paquete "1" así como "el decodificador de video 508" como un destino de salida, el decodificador TS 505 extrae paquetes con la ID de paquete "1" de la corriente de transporte PEG2 recibida desde el POD 504, y los pasa al decodificador de video 508. En la figura 10, por lo tanto, sólo los datos de video se pasan al decodificador de video 508. Al mismo tiempo, cuando la CPU 514 indica al decodificador TS 505 la ID de paquete "2" así como "el decodificador de audio 506", el decodificador TS 505 extrae paquetes con la ID de paquete "2" de la corriente de transporte MPEG2 recibida del POD 504, y los pasa al decodificador de audio 506. En la figura 10, sólo los datos de audio se pasan al decodificador de video 508. Este procesamiento de extraer sólo los paquetes necesarios de acuerdo con las ID de paquete corresponde a la filtración que se llevará a cabo por el decodificador TS 505. El decodificador TS 505 es capaz de llevar a cabo más de un procesamiento de filtración simultáneamente después de recibir instrucciones de la CPU 514. En referencia a la figura 5, el decodificador de audio 506 concatena los datos de audio insertados en los paquetes en la corriente de transporte MPEG2 proporcionada por el decodificador TS 505, lleva a cabo la conversión digital a análoga en los datos concatenados y envia el resultado al altavoz 507. El altavoz 507 emite la señal proporcionada por el decodificador de audio 506 como audio. El decodificador de video 508 concatena datos de video insertados en los paquetes en la corriente de transporte MPEG2 proporcionada por el decodificador TS 505, lleva a cabo la conversión digital a análoga en los datos concatenados y envía el resultado al visor 509. El visor 509, un elemento constituyente concreto del cual es un CRT o un cristal líquido y similar, emite una señal de video proporcionada por el decodificador de video 508 y presenta visualmente . un mensaje especificado por la CPU 514, y así sucesivamente. La unidad de almacenamiento secundaria 510 , elementos constituyentes concretos de la cual son una memoria volátil como un disco duro y similares, almacena y borra datos y programas especificados por la CPU 514. Los datos y programas almacenados son referidos por la CPU 51 . Los datos y programas almacenados se mantienen bajo almacenamiento incluso mientras el aparato terminal 500 está apagado. La unidad de almacenamiento primaria 511, elementos constituyentes concretos de la cual son una RAM y similares, almacena temporalmente datos y programas especificados por la CPU 514 y los borra. Los datos y programas almacenados son referidos por la CPU 514. Los datos y programas almacenados son borrados cuando el aparato terminal 500 es apagado. La ROM 502 es un dispositivo de memoria de sólo lectura, elementos constituyentes concretos del cual son una ROM, un CD-ROM y un DVD, y similares. La ROM 512 almacena un programa que será ejecutado por la CPU 514. La unidad de entrada 513, elementos constituyentes de la cual son un panel frontal o un control remoto, acepta una entrada del usuario. La figura 11 muestra un ejemplo de la unidad de entrada 513 en el caso el que está configurada en forma de un panel frontal. 1100 Es un panel frontal, el cual corresponde a la unidad de panel frontal 603 mostrada en la figura 6. Este panel frontal 1100 está formado de siete botones: un botón de cursor hacia arriba 1101, un botón de cursor hacia abajo 1102, un botón de cursor a la izquierda 1103, un botón de cursor a la derecha 1104, un botón OK 1105, un botón cancelar 1106 y un botón BPG 1107. Cuando el usuario oprime un botón, el identificador de este botón oprimido se notifica a la CPU 514. La CPU 514 ejecuta el programa almacenado en la ROM 512. De acuerdo con instrucciones provenientes del programa que será e ecutado, la CPU 514 controla la unidad de desmodulación QAM 501, la unidad de desmodulación QPSK 502, la unidad de modulación QPSK 503, el POD 504, el decodificador TS 505, el visor 509, la unidad de almacenamiento secundaria 510, la unidad de almacenamiento primaria 511 y la ROM 512. La figura 12 es un diagrama que muestra una estructura ejemplar del programa que es almacenado en la ROM 512 y ejecutado por la CPU 514. Un programa 1200 está formado de varios subprogramas . Para ser más específicos, el programa 1200 está formado de un OS 1201, un EPG 1202, un JavaVM 1203, un administrador de servicios 1204 y una biblioteca Java 1205. El OS 1201 es un subprograma que será activado por la CPU 514 cuando sea encendido el aparato terminal 500. El OS 1201 es una abreviatura del sistema operativo, un ejemplo del cual es Linux y similares. El OS 1201 es un nombre genérico para una técnica conocida públicamente formada 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 el EPG 1202 y el JavaVM 1203 como subprogramas . Mientras tanto, la biblioteca 1201b proporciona a estos subprogramas varias funciones requeridas para controlar los elementos constituyentes del aparato terminal 500. Aguí, la sintonización se introduce como un ejemplo de estas funciones. Con la función de sintonización, la información de sintonización que incluye una frecuencia se recibe desde otro subprograma y se pasa después a la unidad de desmodulación QAM 501. En consecuencia, es posible que la unidad de desmodulación QAM 501 lleve a cabo la desmodulación con base en la información de sintonización proporcionada, y pase los datos desmodulados al POD 504. Como resultado, los demás subprogramas ' pueden controlar la unidad de desmodulación QAM por medio de la biblioteca 1201b. La EPG 1202 está formada de una unidad de presentación visual de programas 1202a para presentar visualmente una lista de programas al usuario asi como para aceptar una entrada del usuario, y una unidad de reproducción 1102b para seleccionar canales. Aquí, EPG es una abreviatura de Guía Eléctrica de Programas. La EPG 1202 es activada cuando el aparato terminal 500 es encendido. En la EPG 1202 activada, la unidad de presentación visual de programas 1202a espera una entrada del usuario por medio de la unidad de entrada 513 del aparato terminal 500. Aquí, en caso de que la unidad de entrada 503 tenga la forma de panel frontal ilustrada en la figura 11, cuando el usuario oprime el botón EPG 1107 en la unidad de entrada 513, se notifica a la CPU 514 del identificador de este botón EPG. La unidad de presentación visual de programas 1202a de la EPG 1202, la cual es un subprograma que corre en la GPU 514, acepta este identificador, y muestra información de programa sobre el visor 509. La figura 13A y figura 13B muestran ejemplos de una tabla de programas presentada visualmente sobre el visor 509. Véase figura 13A. La información de programas se presenta visualmente sobre el visor 509 en un patrón de rejilla. Una columna 1301 describe información de horarios. Una columna 1302 describe un nombre de canal "canal 1" y los programas que serán transmitidos durante periodos de tiempo que correspondan a las horarios respectivos descritos en la columna 1301. Se muestra que un programa "Noticias 9" es transmitido de 9:00 a 10:30, y "Cine ???" es transmitido de 10:30 a 12:00 en "Canal 1". Una columna 1303 describe un nombre de canal "Canal 2" y los programas que serán transmitidos durante periodos de tiempo que correspondan a los horarios respectivos descritos en la columna 1301, como en el caso de la columna 1302. Un programa Cine BBB" es transmitido de 9:00 a 11:00 y "Noticias 11" es transmitido de 11:00 a 12:00. 1330 Es un cursor. El cursor 1330 se mueve al oprimir el cursor a la izquierda 1103 o el cursor a la derecha 1104 sobre el panel frontal 1100. Cuando el cursor a la derecha 1104 es oprimido en el estado ilustrado en la figura 13A, el cursor 1330 se mueve hacia la derecha como se muestra en la figura 13B. Mientras tanto, cuando el cursor izquierdo 1103 es oprimido en el estado ilustrado en la figura 13B, el cursor 1330 se mueve hacia la izquierda como se muestra en la figura 13?. Cuando el botón OK 1105 en el panel frontal 1100 es oprimido en el estado mostrado en la figura 13A, la unidad de presentación visual de programas 1202a notifica a la unidad de reproducción 1202b el identificador de "Canal 1" . Mientras tanto, cuando el botón OK 1105 sobre el panel frontal 1100 es oprimido en el estado mostrado en la figura 13B, la unidad de presentación .visual de programas 1202a notifica a la unidad de reproducción 1102b el identificador de "Canal 2" . Más aún, la unidad de presentación visual de programas 1202a almacena periódicamente información de programas que será presentada visualmente desde el centro distribuidor 101 dentro de la unidad de almacenamiento primaria 511 por medio del POD 504. Generalmente, toma tiempo obtener información de programas del centro distribuidor. Sin embargo, se hace posible presentar visualmente de manera rápida una tabla de programas al presentar visualmente la información de programas que está prealmacenada en la unidad de almacenamiento primaria 514 al oprimir el botón EPG 1107 de la unidad de entrada 513. La unidad de reproducción 1102b reproduce el canal usando el identificador del canal recibido. La relación entre identificadores de canal y canales es prealmacenada por la unidad de almacenamiento secundaria 510 como información de canales. La figura 14 muestra un ejemplo de la información de canales almacenada en la unidad de almacenamiento secundaria 510. La información de canales es almacenada en forma tabular. Una columna 1401 describe los identificadores de los canales. Una columna 1402 describe los nombres de los canales. Una columna 1403 describe información de sintonización. Aquí la información de sintonización, se representa por valores que serán proporcionados a la unidad de desmodulación QAM 501 tales como frecuencia, velocidad de transmisión y relación de codificación. Una columna 1404 describe números de programa. Los números de programa son números usados para identificar PMTs definidos por la norma MPEG2. Una descripción acerca de PMT se da más adelante. Cada una de las lineas 1411-1414 indica un conjunto del identificador, nombre de canal e información de sintonización 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 u312MHz" como información de sintonización y "101" como un número de programa. La unidad de reproducción 1102b pasa el identificador del canal recibido directamente al administrador de servicios para de esta manera reproducir el canal . Además, cuando el usuario oprime el cursor hacia arriba 1101 y el cursor hacia abajo 1102 sobre el panel frontal 1100 mientras la reproducción está teniendo lugar, la unidad de reproducción 1102b recibe una notificación acerca de esta opresión por el usuario de la unidad de entrada 513 por medio de la CPU 514 y cambia el canal que está siendo reproducido a otro. Primero, la unidad de reproducción 1102b almacena, en la unidad de almacenamiento primaria 511, el identificador de canal que está siendo reproducido actualmente. Las figuras 15A, B y C muestran identificadores ejemplares de canales almacenados en la unidad de almacenamiento primaria 511. La figura 15A muestra que un identificador "3" es almacenado, y se muestra al hacer referencia a la figura 14 de que un canal con el nombre de canal "TV 3" está siendo reproducido. Cuando el usuario oprime el cursor hacia arriba 1101 en un estado ilustrado en la figura 15A, la unidad de reproducción 1102b se refiere a la información de canales mostrada en la figura 14, y pasa el identificador "2" de un canal con el nombre de canal de "Canal 2" al administrador de servicios para de esta manera reproducir nuevamente un canal con el nombre de canal de "Canal 2", el cual es el canal anterior en la tabla. Al mismo tiempo, la unidad de reproducción 1102b rescribe el identificador en el identificador de canal "2" almacenado en la unidad de almacenamiento primaria 511. La figura 15B muestra este identificador de canal reescrito. Mientras tanto, cuando el usuario oprime el cursor hacia abajo 1102 en el estado ilustrado en la figura 15A, la unidad de reproducción 1102b se refiere a la información de canal mostrada en la figura 14, y pasa el identificador "4" de un canal con el nombre de canal de "TV Japón" al administrador de servicios para reproducir nuevamente un canal con el nombre de canal "TV Japón" , el cual es el siguiente canal en la tabla. Al mismo tiempo, la unidad de reproducción 1102b rescribe el identificador en el identificador de canal "4" almacenado en la unidad de almacenamiento primaria 511. La figura 15C muestra este identificador de canal rescrito. El JavaVM 1203 es una máquina virtual Java que secuencialmente analiza y ejecuta programas escritos en el lenguaje Java (TM) . Los programas escritos en el lenguaje Java son compilados en códigos intermedios conocidos como códigos de byte los cuales no dependen de hardware. La máquina virtual Java es un intérprete 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 puede ser interpretada por la CPU 514 y pasan el resultado a la CPU 514 la cual lo ejecuta. La JavaVM 1203 es activada, con un programa Java que será ejecutado siendo especificado por el núcleo 1201a. En la presente modalidad, el núcleo 1201a especifica al administrador de servicio 1204 como un programa Java que será ejecutado. Un comentario detallado del lenguaje Java se da en muchos libros que incluyen "Especificación de Lenguaje Java" (ISBN 0-201-63451-1) . Por lo tanto, una descripción detallada acerca de éste se omite aquí. Asimismo, un comentario detallado sobre la operación del propio Java VM se da en muchos libros que incluyen "Especificación de Máquinas Virtuales Java" (ISBN 0-201-63451-X) . Por lo tanto, se omite aquí una descripción detallada acerca del mismo. El administrador de servicios 1204, el cual es un programa Java escrito en el lenguaje Java, es ejecutado por el JavaVM 1203 secuencialmente . Es posible que el administrador de servicios 1204 llame y sea llamado por otro subprograma no escrito en el lenguaje Java a través de la JNI (Interfaz Nativa Java) . Un comentario sobre la JNI se da en muchos libros que incluyen "Interfaz Nativa Java" . Por lo tanto, se omite una descripción detallada acerca de la misma. El administrador de servicios 1204 acepta el identificador del canal que proviene de la unidad de reproducción 1102b a través de la JNI . Primero, el administrador de servicios 1204 pasa el identificador del canal a un Sintonizador 1205c en la biblioteca Java 1205 para de esta manera solicitar la sintonización. El Sintonizador 1205c se refiere a la información de canal almacenada en la unidad de almacenamiento secundaria 510 para obtener la información de sintonización. Suponiendo que el administrador de servicios 1204 pasara 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 "15SMHz" , que corresponde al canal. El Sintonizador 1205c pasa la información de sintonización a la unidad de desmodulación QAM 501 por medio de la biblioteca 1201b del OS 1201. La unidad de desmodulación QAM 501 desmodula la señal enviada desde el centro distribuidor 101 de acuerdo con la información de sintonización dada a la unidad de desmodulación QAM 501, y pasa la señal resultante al POD 504. Después, el administrador de servicios 1204 solicita un CA 1205b dentro de la biblioteca Java 1205 para llevar a cabo la deseudoaleatorización . El CA 1205d proporciona al POD 504 la información requerida para la deseudoaleatorización a través de la biblioteca 1201b en el OS 1201. Con base en esta información proporcionada, el POD 504 deseudoaleatoriza la señal proporcionada por la unidad de desmodulación QAM 501 y pasa la señal resultante al decpdificador TS 505. Después, el administrador de servicios 1204 proporciona un JMF 1205a dentro de la biblioteca Java 1205 con el identificador del canal, para de esta manera solicitar la reproducción del video y audio . Primero, el JMF 1205a obtiene, de una PAT y una PMT, ID de paquete usadas para especificar el video y audio que será reproducido. PAT y PMT son tablas definidas por la norma MPEG-2 que muestran la alineación de programas incluida en una corriente de transporte MPEG2. PAT y PMT son portadas en las cargas útiles en paquetes incluidos en una corriente de transporte MPEG2, junto con audio y video. Refiérase a la especificación para una descripción detallada de PAT y PMT. Aquí, sólo se da una descripción general de PAT y PMT. PAT, la cual es una abreviatura de Tabla de Asociación de Programas, es portada en paquetes con la ID de paquete "0" . Para poder obtener la PAT, el JMF 1205a indica, al decodificador TS 505, la ID de paquete "0" y la CPU 514 a través de la biblioteca 1201b del OS 1201. Después, el decodificador TS 505 lleva a cabo la filtración con base en la ID de paquete "0", y pasa el resultado a la CPU 514. En consecuencia, el JMF 1205a puede recabar los paquetes PAT. La figura 16 ilustra una tabla que muestra esquemáticamente un ejemplo de la información PAT recabada. Una columna 1601 describe números de programa. Una columna 1602 describe 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 de número de programa de un canal y una ID de paquete que corresponde a éste. Aquí, se definen tres canales. La línea 1611 define un par del número de programa "101" y la ID de paquete "501". Suponiendo que el identificador de canal proporcionado al JMF 1205a sea "2", el JMF 1205a se refiere a la columna 1412 de la figura 14, para obtener así el número de programa "102" que corresponda a este identificador de canal, y después se refiere a la línea 1612 en la PAT mostrada en la figura 16, para de esta manera obtener la ID de paquete w502" que corresponde al número de programa "102" . PMT, la cual es una abreviatura de Tabla de Mapa de Programas, es portada en paquetes con las ID de paquete especificadas en la PAT. Para obtener la PMT, el JMF 1205a indica, al decodificador TS 505, una ID de paquete y la CPU 514 a través de la biblioteca 1201 del OS 1201. Aquí, una ID de paquete que será especificada es "502". Después, el decodificador TS 505 lleva a cabo la filtración con base en la ID de paquete "502", y pasa el resultado a la CPU 514. En consecuencia, el JMF 1205a puede recabar los paquetes PMT. La figura 17 ilustra una tabla que muestra esquemáticamente un ejemplo de la información PMT recabada. Una columna 1701 describe tipos de corriente. Una columna 1702 describe ID de paquete. La información especificada en los tipos de corriente respectivos es portada en las cargas útiles de paquetes con las ID de paquetes especificadas en la columna 1702. Una columna 1703 describe información adicional. Cada una de las líneas 1711-1714 es un par de una ID de paquete y el tipo de información que está siendo transmitida, la cual se conoce como una corriente elemental. La línea 1711, la cual es un par del tipo de corriente "audio" y la ID de paquete "5011", indica que datos de audio están almacenados en la carga útil del paquete con la ID de paquete "5011". El JMF 1205a obtiene, de la PMT, las ID de paquete del video y audio que será reproducido. En referencia a la figura 17, el JMF 1205a obtiene la ID de paquete de audio "5011" de la línea 1711, y la ID de paquete de video "5012" de la línea 1712. Después, el JMF 1205a proporciona al decodificador TS 505 pares de la ID de paquete de audio obtenida y el decodificador de audio 506 como un destino de salida así como la ID de paquete de video y el decodificador de video 508 como un destino de salida, por medio de la biblioteca 1201b del OS 1201. El decodificador TS 505 lleva a cabo la filtración con base en estas ID de paquete proporcionadas y los destinos de salida. Aquí, el paquete con la ID de paquete "5011" es pasado al decodificador de audio 506 y el paquete con la ID de paquete "5012" es pasado al decodificador de video 508. El decodificador de audio 506 lleva a cabo conversión digital a análoga en el paquete proporcionado, para reproducir de esta manera el audio por medio del altavoz 507. El decodificador de video 508 lleva a cabo la conversión digital a análoga en el paquete proporcionado, para de esta manera presentar visualmente el video sobre el visor 509. Finalmente, el administrador de servicios 1204 proporciona el identificador de canal a un AM 1205b en la biblioteca Java 1205, para de esta manera solicitar la reproducción de la transmisión de datos. Aquí, la reproducción de la transmisión de datos significa extraer un programa Java incluido en la corriente de transporte MPEG2 y causar que JavaVM 1203 lo ejecute. Como una técnica para insertar un programa Java en una corriente de transporte MPEG2, se usa un método conocido como DSMCC, el cual se describe en la especificación de MPEG ISO/IEC138181-6. Una explicación detallada de DSMCC se omite aquí. La especificación DSMCC define un método para codificar un sistema de archivos que comprende directorios y archivos usados por una computadora, en paquetes dentro de una corriente de transporte MPEG2. La información acerca del programa Java que será ejecutado es portada en paquetes en la corriente de transporte MPEG2 en forma de AIT. AIT es una abreviatura de Tabla de Información de Aplicaciones cuya definición se da en el capitulo diez de la norma DVB-MHP (conocido formalmente como la especificación ETSI TS 101 812 DVB-MHP VI.0.2) . Primero, para poder obtener la AIT, el AM 1205b obtiene la PAT y PMT como en el caso del JMF 1205a, para obtener asi la ID de paquete del paquete que almacena la AIT. Suponiendo que ¾2" sea el identificador de canal proporcionado y que la PAT mostrada en la figura 16 y la PMT mostrada en la figura 17 estén siendo transmitidas, el AM 1205b obtiene la PMT mostrada en la figura 17 de acuerdo con el mismo procedimiento seguido por el JMF 1205a. Posteriormente, el AM 1205b extrae, de la PMT, la ID de paquete de la corriente elemental cuyo tipo de corriente es "Datos" y la cual 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 de paquete "5013" de éste. El AM 1205b proporciona al decodificador TS 505 la ID de paquete de la AIT y la CPU 514 como un destino de salida a través de la biblioteca 1201b del OS 1201. Después, el decodificador TS 505 lleva a cabo la filtración con base en esta ID de paquete proporcionada, y pasa el resultado a la CPU 514. En consecuencia, el AM 1205b puede recabar los paquetes de AIT. La figura 18 es una tabla que muestra esquemáticamente un ejemplo de la información AIT recabada. Una columna 1801 describe identificadores de programas Java. De acuerdo con la especificación MHP, estos identificadores se definen como ID de Aplicación, los cuales identifican si un programa Java es un programa que debe ser autentificado por un administrador de seguridad 1205f del aparato terminal 500. No se requiere autentificación cuando el valor de un identificador está en la escala de 0x0 a 0x3fff, mientras que se requiere autentificación cuando el valor de un identificador está en la escala de 0x4000 a 0x7fff. Un programa Java cuyo valor identificador está dentro de la primera escala es referido como un "programa no firmado" y un programa Java cuyo valor identificador está dentro de la última escala es referido como un "programa firmado" . Una columna 1802 describe la información de control para controlar los programas Java. La información de control incluye "autoinicio" , "presente" y "eliminar" . "Autoinicio" significa que el aparato terminal 500 ejecuta automáticamente el programa rápidamente . "Presente" significa que el programa no es ejecutado automáticamente. "Eliminar" significa que el programa va a ser concluido. Una columna 1803 describe identificadores DSMCC usados para extraer ID de paquete que incluyen programas Java en el formato DSMCC. Una columna 1804 describe nombres de programa de los programas Java. Cada una de las líneas 1811 y 1812 es un conjunto de información acerca de un programa Java. El programa Java definido en la línea 1811 es un conjunto de un identificador "301", información de control "autoinicio" , un identificador DSMCC nl" y un nombre de programa "a/TopXlet" . El programa Java definido en la línea 1812 es un conjunto de un identificador "302", información de control "presente", un identificador DSMCC "1" y un nombre de programa "b/GameXlet" . Aquí, estos dos programas Java tienen el mismo identificador DSMCC. Esto indica que dos programas Java están incluidos en el sistema de archivos que ha sido codificado de acuerdo con el mismo método DSMCC. Aquí, sólo cuatro piezas de información se especifican para los programas Java respectivos, pero más piezas de información se especifican en la actualidad. Refiérase a la especificación DVB-MHP para detalles . El AM 1205b encuentra el programa Java "autoinicio" de la AIT, y extrae el identificador DSMCC correspondiente y el nombre del programa Java. En referencia a la figura 18, el AM 1205b extrae el programa Java en la línea 1811, y obtiene el identificador DSMCC "1" y el nombre de programa Java "a/TopXlet" .

Después, el AM 1205b obtiene, de la PMT, la ID de paquete de paquetes que almacenan programas Java en el formato DSMCC, usando el identificador DSMCC obtenido de la AIT. En forma más específica, el AM 1205b obtiene, de la PMT, la ID de paquete incluida en la corriente elemental cuyo tipo de corriente es "datos" y cuyo identificador DSMCC en la información adicional coincide . Aqui, suponiendo que este identificador DSMCC fuera ¦"1" y que la PMT fuera la mostrada en la figura 17, la corriente elemental en la línea 1714 satisface la condición anterior. Por lo tanto, la ID de paquete w5014" va a ser extraída. El AM 1205b indica, al decodificador TS 505, la ID de paquete de paquetes en los cuales los datos están insertados en el formato DSMCC así como a la CPU 514 como un destino de salida a través de la biblioteca 1201b del OS 1201. Aquí, se proporciona la ID de paquete "5014". Después, el decodificador TS 505 lleva a cabo la filtración con base en la ID de paquete proporcionada, y pasa el resultado a la CPU 514. En consecuencia, el AM 1205b puede recabar los paquetes requeridos. El AM 1205b reconstruye el sistema de archivos a partir de los paquetes recabados de acuerdo con el método DSMCC, y almacena el sistema de archivos reconstruido en la unidad de almacenamiento primaria 511. El proceso para extraer datos tales como el sistema de archivos de paquetes en el transporte MPEG2 y almacenar los datos extraídos en las unidades de almacenamiento tales como la unidad de almacenamiento primaria 511 es llamado en adelante descarga. La figura 19 muestra un ejemplo del sistema de archivos descargado. En el diagrama, los circuios representan directorios y los cuadrados representan archivos, en 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" . Posteriormente, el AM 1205b pasa, al JavaVM 1203, un programa Java que será ejecutado fuera del sistema de archivos descargado en la unidad de almacenamiento primaria 511. Aquí, suponiendo que el nombre de programa Java a ser ejecutado sea ¾a/TopXlet" , un archivo "a/TopXlet . class" resultado de anexar ?. class" al nombre de programa Java anterior es un archivo que será ejecutado. ?/" 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 será ejecutado. Después, el AM 1205b pasa el archivo 1904 al JavaVM 1203 toda vez que la columna 1801 que describe el identificador del programa Java indica programa no firmado, significando que no hay necesidad de solicitar al administrador de seguridad 1205f llevar a cabo la autentificacion de este programa Java.

El JavaVM 1203 ejecuta este programa Java recibido. Después de recibir el identificador de otro canal, el administrador de servicios 1204 concluye la reproducción del video y audio así como la ejecución del programa Java que están siendo llevadas a cabo a través de cada biblioteca incluida la biblioteca Java 1205, a través de cada biblioteca incluida en la misma biblioteca Java 1205, y luego lleva a cabo la reproducción del video y audio asi como la ejecución de un programa Java con base en el identificador de canal recién recibido. La biblioteca Java 1205 es una colección de varias bibliotecas Java 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 POD Lib 1205e, el administrador de seguridad 1205f, un módulo de descarga 1206 y similares. El administrador de servicios 1204 y el módulo de descarga 1206 llevan a cabo una comunicación de dos vias con el centro distribuidor 101 por medio de la POD Lib 1205e incluida en la biblioteca Java 1205. Esta comunicación de dos vías puede lograrse por la POD Lib 1205e usando la unidad de desmodulación QPSK 502 y la unidad de modulación QPSK 503 por medio de la biblioteca 1201b del OS 1201 y el POD 504. El módulo de descarga 1206 puede recibir datos de códigos desde el centro distribuidor 101 a través de esta comunicación. Los datos de código se refieren a los datos binarios que incluyen un certificado X.509 y/o firmware del aparato terminal 500. La figura 37 es un diagrama esquemático que muestra datos de código que describen únicamente una parte relacionada con la presente invención. Cuando se reciben datos de código 37, el módulo de descarga 1206 extrae un certificado de raíz 371 si éste está incluido, y lo pasa al administrador de seguridad 1205f. 372 Indica otros datos tales como firmware . El AM 1205b recibe, del centro distribuidor 101, información acerca de programas Java que el aparato terminal 500 debe almacenar en la unidad de almacenamiento secundaria 510. Esta información es referida como información XAIT. La información XAIT es transmitida entre el centro distribuidor 101 y el POD 504 de una manera arbitraria. La presente invención se puede llevar a cabo sin importar el formato de transmisión, siempre y cuando la información requerida como XAIT esté incluida. La figura 20 ilustra una tabla que muestra esquemáticamente un ejemplo de la información 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 es ejecutado automáticamente cuando el aparato terminal 500 es encendido, y "presente" significa que el programa no es ejecutado automáticamente. Una columna 2003 describe identificadores DSMCC usados para extraer ID de paquete que incluyen programas Java en el formato 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 líneas 2011 y 2012 es un conjunto de información acerca de los programas Java respectivos. El programa Java definido en la linea 2011 es un conjunto de un identificador "0x7001", información de control "autoinicio" , un identificador DSMCC "1" , y un nombre de programa "a/PPVlXlet" . Se puede saber a partir de esta ID de aplicación de programa Java si este programa Java es un programa firmado. Aquí, sólo cinco piezas de información se especifican para los programas Java respectivos, pero la presente invención puede llevarse a- cabo incluso cuando más piezas de información se definan. Después de recibir la información XAIT, el AM 1205b almacena el sistema de archivos proveniente de la corriente de transporte MPEG2 en la unidad de almacenamiento primaria 511, de acuerdo con el mismo procedimiento que el de descargar el programa Java de la información AIT. Después de esto, el AM 1205b lleva a cabo una notificación de prealmacenamiento al administrador de seguridad 105f inmediatamente antes de que almacena el sistema de archivos en la unidad de almacenamiento secundaria 510. En este momento, se inicia una operación de autentificación por el administrador de seguridad 1205f de acuerdo con la presente invención, pero sus detalles se describen más adelante. Después de la notificación proveniente del administrador de seguridad 1205f de que la activación es habilitada, el ?? 1205b almacena el sistema de archivos en la unidad de almacenamiento secundaria 510. Luego, el AM 1205b almacena, en la unidad de almacenamiento secundaria 510, el resultado de asociar la información XAIT con una posición de almacenamiento del sistema de archivos descargado. La figura 21 muestra un ejemplo de la información XAIT y el sistema de archivos descargado almacenados en la unidad de almacenamiento secundaria 510 en asociación uno con otro. Aquí, un archivo definido en la especificación OCAP se describe como un ejemplo. Los elementos de la figura 21 que son iguales a los de la figura 20 son iguales entre si, y por lo tanto se omite una explicación de estos elementos. Una columna 2101 almacena la posición de almacenamiento del sistema de archivos descargado. En la figura 21, estas posiciones de almacenamiento se indican por flechas. 2110 Es el sistema de archivos descargado, en el cual un directorio superior 2111, un directorio "a" 2112, un directorio wb" 2113, un archivo "PPVlXlet. class" 2114, un archivo "PPV2Xlet. clase" 2115, archivos "ocap. hashfile" 2116-2118, un archivo "ocap. certifícate. 1" 2119 y un archivo "ocap. signaturefile . 1" 2120 están incluidos. Los archivos 2116-2118 son archivos de refundición en los cuales los nombres de archivo o nombres de directorio y los valores de refundición correspondientes están incluidos. Las figuras 22?, 22B y 22C son diagramas esquemáticos que muestran los detalles de "ocap. hashfiles" . 221 En la figura 22A muestra '"ocap. hashfile" 2116, 222 en la figura 22B muestra "ocap. hashfile" 2117 y 223 en la figura 22C muestra "ocap. hashfile" 2118. El "ocap. hashfile" de 221, el cual existe en el directorio "/" 2111, incluye en la columna 2211, un archivo "ocap. certifícate . 1" 2119, un archivo "ocap. signaturefile . 1" 2120, un directorio "a" 2112 y un directorio "b" 2113 que existen en el mismo directorio 2111. Una columna 2212 indica qué algoritmo de refundición se usó para calcular cada valor descrito en una columna 2213. La columna 2213, la cual se refiere a los archivos o directorios en la columna 2211, incluye valores de refundición que fueron calculados mediante el uso del algoritmo de refundición especificado en la columna 2212. Actualmente, los algoritmos de refundición que se usan principalmente son SHA1 (Algoritmo de Refundición Seguro 1) y MD5 (Compendio de Mensajes 5) . Éstos son algoritmos públicamente conocidos para convertir datos con una longitud arbitraria en un valor de bytes de longitud fija, los cuales tienen las siguientes características : es imposible predecir los datos originales después de que son convertidos y se usan para revisar si un archivo ha sido destruido o alterado. Mientras tanto, un valor de refundición es un número seudo aleatorio que se genera mediante el uso de un algoritmo de refundición. Cuando un algoritmo de refundición es SHA1, la longitud de un valor de refundición es 20 bytes, mientras que cuando un algoritmo de refundición es MD5 , la longitud de un valor de refundición se convierte en 16 bytes. Para detalles acerca de SHA1 y MD5 , refiérase a "Norma de Refundición Segura FIPS-PUB 186-2" y "IETF RFC1321", respectivamente. Aquí , los valores de ref ndición que corresponden a los directorios respectivos "a" y "b" descritos en la columna 2211 son valores de refundición SHA1 que han sido calculados respectivamente para el archivo "ocap. hashfile" 2117 que existe en el directorio wa" y el archivo "oca . hashfile" 2118 que existe en el directorio "b" . Como en el caso del "ocap . hashfile" en 221, "ocap. hashfile" en 222 incluye el nombre de archivo, algoritmo de refundición y valor de refundición de un -archivo "PPVlXlet . class" 2114 que existe en el mismo directorio 2112. En forma similar, incluidos en 223 están el nombre de archivo, algoritmo de refundición y valor de refundición de un archivo "PPV2Xlet. class" 2115 que existe en el mismo directorio 2113.

Aquí, sólo se describen los atributos que están relacionados con la presente invención, y de esta manera se debe hacer referencia a la especificación OCAP "OpenCable (TM) Application Platform Specification OCAP 1.0 Profile (OC-SP-OCAP1.0-IF-I09-031121) " para detalles acerca de "ocap. hashfile" . Un archivo 2119 es una cadena de certificados. La figura 23 es un diagrama que muestra una estructura detallada del archivo "ocap. certiicate. 1" 2119. 231, El cual ilustra una estructura típica de "ocap. certifícate, x" (x es un entero positivo) , contiene un certificado de raíz 2311, un certificado intermedio 2312 y un certificado de origen 2313. Están en una relación de cadena en la cual el tenedor del certificado de raíz 2311 emite el certificado intermedio 2312 y el tenedor del certificado intermedio 2312 emite el certificado de origen 2313, por ejemplo. Nótese que de acuerdo con la especificación OCAP, una cadena de certificados relacionada con un archivo de firma "ocap. signaturefile . x" es "ocap. certifícate, x" que tiene el mismo valor "x" . En el caso de la figura 21, una cadena de certificados que corresponde al "ocap. signaturefile . 1" es el "ocap. certifícate. 1". Asimismo, el certificado de raíz 2311, el certificado intermedio 2312 y el certificado de origen 2313 están configurados en el mismo formato de certificado X. 509. Los certificados X. 509 se usan ampliamente en -varios campos de la industria de la información y comunicaciones como la norma de facto para formatos de representación de certificados, como una recomendación de la ITU-T. En la figura 23, sólo se ilustran tres certificados, pero hay un caso en el que existe una pluralidad de certificados intermedios. Sin embargo, en este caso, estos certificados intermedios deben estar en un estado de cadena en el cual estén relacionados unos con otros . La figura 24 es un diagrama que muestra la estructura de un certificado X. 509. Aqui, sólo se ilustran los atributos que se requieren para explicar la presente invención. Para detalles acerca de los certificados X. 509, refiérase a IETF RFC3280 "Internet X. 509 Public Key Infraestructure Certifícate and CRL Profile" . 241 Indica un área de atributo del certificado X. 509 y 242 incluye el valor de firma del certificado X. 509. El número de serie 2411 indica el número para identificar el certificado, el algoritmo de firma 2412 indica el algoritmo usado para determinar el valor de firma 242, su fecha y hora de actualización 2413 indica la fecha y hora cuando ese certificado X. 509 se hace válido, la siguiente fecha y hora de actualización 2414 indica la fecha y hora en la que este certificado X. 509 expira, el nombre de emisor 2415 indica el nombre de la autoridad que emitió este certificado X. 509, nombre de sujeto 2416 indica al tenedor de este certificado X. 509, clave pública 2417 indica la clave pública del nombre del sujeto 2416 y valor de firma 242 indica un valor que ha sido firmado (cifrado) con la clave privada del emisor de este certificado X. 509. En esta modalidad, esta fecha y hora de actualización 2413 y la siguiente fecha y hora de actualización 2414 necesitan información de fecha y hora, pero esta fecha y hora de actualización 2413 y la siguiente fecha y hora de actualización 2414 no siempre requieren información de tiempo. Como un sistema que utiliza clave pública y cable privada, los sistemas de cifrado de claves públicas se usan ampliamente para comercio electrónico y otros. En un sistema de cifrado de claves públicas, un texto cifrado es descifrado con una clave que es diferente a la clave usada para cifrar el texto simple. Ya que la clave para el cifrado y la clave para el descifrado son diferentes, es imposible calcular la clave para el cifrado a partir de la clave para el descifrado. Esta clave para el cifrado corresponde a la clave privada y esta clave para el descifrado corresponde a la clave pública. Ejemplos representativos de sistemas de cifrado con claves públicas incluyen RSA (Rivest-Shamir-Adleman) y DSA (Norma de Firma Digital) .' El archivo 2120 es un archivo de firma. La figura 25 es un diagrama esquemático que muestra al archivo "ocap. signaturefile . 1" 2120. 251 Indica un identificador de certificado para identificar qué certificado X. 509 está relacionado, 252 indica un algoritmo de firma de refundición y 253 indica un valor de firma que ha sido calculado a partir del "ocap. hashfile" 2116 mediante el uso del algoritmo de firma de refundición indicado en 252. Una vez que una programa Java es almacenado en la unidad de almacenamiento secundaria 510, es posible activar este programa Java sin tener que esperar la descarga siempre y cuando el AM 1205b haya recibido el XAIT mostrado en la figura 20, incluso en caso de que el programa Java haya sido borrado de la unidad de almacenamiento primaria 511 debido a causas tales como cambio de canal y apagado del aparato terminal 500. En otras palabras, en la figura 20, la información de control 2002 del programa "/a/PPVlXlet" es "autoinicio" . Así, en 2011, en la figura 21, cuando se hace una búsqueda de la posición de almacenamiento 2101 del sistema de archivos que corresponde al "/a/PPVlXlet" y luego el archivo 2114 se pasa al JavaVM 1203, el programa Java "PPVlXlet" almacenado en este sistema de archivos es activado . A continuación se da una descripción del administrador de seguridad 1205f que es una funcionalidad principal de la presente invención. El administrador de seguridad 1205f recibe, del administrador de servicios 1204, una notificación de pre-almacenamiento que indica que "/a/PPVlXlet" y "/b/PPVXlet2" indicados en 2004 en la figura 20 están a punto de ser almacenados. Luego de recibir esta notificación, el administrador de seguridad 1205f revisa el valor del identificador de programa Java 2001 para juzgar si éste es un programa no firmado o un programa firmado. Aquí, ya que el programa Java es un programa firmado, el administrador de seguridad 1205f lleva a cabo la autentificación del sistema de archivos más baja que el directorio "/" · Para verificar el sistema de archivos, se lleva a cabo la autentificación mediante el uso de los archivos de refundición ocap. hashfiles (2116-2118) , el ocap. certifícate. 1 (2119) y el ocap. signaturefile . 1 (2120) ilustrados en la figura 21. La figura 26 muestra los elementos constituyentes del administrador de seguridad 1205f para llevar a cabo la autentificación de un sistema de archivos. Una unidad de recepción de notificación 261 está destinada a recibir una notificación de pre-almacenamiento inmediatamente antes de que el AM 1205b esté a punto de almacenar un sistema de archivos, asi como para notificar este hecho a una unidad de juicio 262. La unidad de juicio 262 juzga un resultado de autentificación. Solicita a una unidad de cálculo de refundición 263 llevar a cabo cálculos de refundición para el sistema de archivos para recibir valores de refundición. La unidad de juicio 262 extrae, de entre los valores de refundición 2213, 2223 y 2233 que existen en el archivo ¾ocap . hashfile" , un valor que será comparado y revisa si coincide o no con los valores de refundición recibidos . Si no coinciden, la unidad de juicio 262 juzga que ha habido una alteración, y la autentificacion concluye en falla. Más aún, la unidad de juicio 262 extrae cada uno de los certificados X. 509 usando una unidad de extracción de certificados 265, y juzga si la hora actual no es antes que esta fecha y hora de actualización 2413 de cada uno de los certificados X. 509 y no después de la siguiente fecha y hora de actualización 2414 de cada uno de los certificados X. 509 (llámese, la hora actual está entre esta fecha y hora de actualización 2413 y la siguiente fecha y hora de actualización 2414 de cada uno de los certificados X. 509) . La fecha y hora actual se obtiene de la biblioteca 1201b del OS 1201. Si el periodo de validez no satisface "esta fecha y hora de actualización<fecha y hora áctual<siguiente fecha y hora de acutalización" , la unidad de juicio 262 juzga que la autentificacion es una falla. Más aún, para autentificar la cadena de certificados, la unidad de juicio 262 solicita a la unidad de cálculo de refundición 263 llevar a cabo un cálculo de refundición para el área de atributo 241 de cada uno de los certificados X. 509. Después, solicita a una unidad de descifrado de valores de firma 264 llevar a cabo un cálculo para descifrar el valor de firma 242 incluido en cada uno de los certificados X.509, y compara el valor descifrado resultante con los valores de refundición obtenidos por la unidad de cálculo de valores de refundición 263 para de esta manera revisar el estado de la cadena de certificados. Si no coinciden, significa que los certificados no están en una relación de cadena, y de esta manera se juzga que la autentificación es una falla. Mientras tanto, cuando estos valores coinciden y se ha verificado que los certificados están en una relación de cadena, se revisa si el certificado de raíz en la cadena de certificados está incluido en la unidad de almacenamiento secundaria 510 del aparato terminal 500. Si no esta incluida, la unidad de juicio 262 juzga que la autentificación es una falla, considerando que es imposible llevar a cabo una comparación. La unidad de juicio 262 juzga que la autentificación es exitosa cuando se satisfacen todas las siguientes condiciones: (1) no ha habido alteración alguna; (2) existe validez de periodo; (3) los certificados están en una relación de cadena y (4) los certificados de raíz coinciden. Cuando se solicita por la unidad de juicio 262 calcular un valor de refundición de cada uno de los archivos, la unidad de cálculo de refundición 263 extrae cada uno de los archivos de la biblioteca 1201b del OS 1201 para llevar a cabo cálculos de refundición para ellos, y pasa los valores resultantes a la unidad de juicio 262. Además, la unidad de cálculo de refundición 263 obtiene cada uno de los certificados X. 509 en la cadena de certificados 231 de la unidad de extracción de certificados 265, y lleva a cabo cálculos de refundición para el área de atributo 241 de cada uno de ellos . La unidad de juicio 262 solicita a la unidad de descifrado de valores de firma 264 llevar a cabo un cálculo para descifrar el valor de firma ya sea de cada uno de los certificados X. 509 u "ocap. signaturefile . x" . Cuando se lleva a cabo un cálculo para descifrar la firma de cada certificado X. 509, la unidad de descifrado de valores de firma 264 obtiene cada uno de los certificados X. 509 en la cadena de certificados 231 de la unidad de extracción de certificados 265, y luego lleva a cabo un cálculo para descifrar la firma de cada uno de ellos, y regresa el resultado a la unidad de juicio 262. Se pide a la unidad de extracción de certificados 265 extraer cada uno de los certificados X. 509 en la cadena de certificados 231 por la unidad de juicio 262, la unidad de cálculo de refundición 263 y la unidad de descifrado de valores de firma 264, y extrae y regresa los certificados X. 509.

La figura 27 es una gráfica de flujo que resume una operación llevada a cabo por el administrador de seguridad 1205f cuando lleva a cabo la autentificación de un sistema de archivos. Con base en esta gráfica de flujo, se da una explicación de la operación que se llevará a cabo en caso de que el sistema de archivos tenga la configuración mostrada en la figura 21. Luego de recibir una notificación de pre-almacenamiento para el sistema de archivos desde el AM 1205b (Etapa S271) , el administrador de seguridad 1205f lleva a cabo una revisión de alteración para el sistema de archivos más bajo que el director "/" de nivel superior del sistema de archivos (Etapa S272) . En la revisión de alteración, se verifica, al comparar valores de refundición, que no hay-corrupción o cambios en los archivos existentes en cada directorio del sistema de archivos. La figura 29 y la figura 30 son diagramas de flujo detallados de la Etapa S272. Primero, como se muestra en la Etapa S291, se calculan valores de refundición para los archivos respectivos "ocap. certifícate. 1" y "ocap. signaturefile . 1" y los directorios respectivos "a" y "b" que existen en el directorio "/" ¦ Nótese que los valores de refundición de los directorios "a" y "b" se calculan a partir del archivo "/a/ocap. hashfile" 222 y el archivo "/b/ocap. hashfile" 223, respectivamente. En la Etapa S293, los valores de refundición calculados en la Etapa S292 se comparan con cada uno de los valores de refundición descritos en 2213 en "/c-cap. hashfile" . En la Etapa S294, si alguno de los valores de refundición calculados difiere de los valores de refundición en 2213, se juzga que ha habido alteración (Etapa S297) . Mientras tanto, cuando todos los valores de refundición calculados coinciden con los valores de refundición 2213, se hace una transición a la Etapa S295. En la Etapa S295, se revisa si existe algún subdirectorio para el cual no se haya completado una revisión de alteración. En la etapa actual, los directorios "a" y "b" existen como los subdirectorios del directorio "/"/ para el cual no se han llevado a cabo aún revisiones de alteración. Por lo tanto, las revisiones de alteración tienen que llevarse a cabo para estos directorios"a" y "b" . Primero, la atención se centra en el directorio "a" en la Etapa S296, en donde se lleva a cabo un proceso equivalente al llevado a cabo para el directorio "/" . Después que se completa la revisión de alteración para el directorio "a" , se lleva a cabo una revisión de alteración para el directorio wb" . Cuando las revisiones de alteración para los directorios "a" y "b" han sido completadas, la atención se centra después en el directorio "/"/ Y se lleva a cabo el proceso para la Etapa S301 en la figura 30. En la Etapa S301, el certificado de origen 2313 es extraído del archivo "/ocap. certifícate. 1" 2119, el cual es la cadena de certificados 231. Después, en la Etapa S302, la clave pública 2414 es sacada del certificado de origen 2313 extraído. Posteriormente, en la Etapa S303, se calcula un valor de refundición para el archivo "/ocap. hashfile" . Mientras tanto, en la Etapa S304, se lleva a cabo el descifrado en el valor de firma 242 en el archivo w/ocap. signaturefile . 1" 2120, usando la clave pública 2417 que existe en el certificado de origen 2313 en el archivo "/ocap. certifícate. 1" . En la Etapa S305, se revisa si el valor de refundición calculado en la Etapa S303 es igual al valor obtenido en la Etapa S304 al descifrar el valor de firma. Si estos valores calculados coinciden, es posible juzgar que el sistema de archivos más bajo que el directorio w/" no ha sido alterado (Etapa S306) . Mientras tanto, si los valores calculados no coinciden, es posible juzgar que el sistema de archivos ha sido alterado (Etapa S307) . Nótese que se ha dado la descripción para un ejemplo en el cual se llevan a cabo revisiones de alteración iniciando con el directorio " de nivel superior hacia los subdirectorios en orden descendente, pero la presente invención no está limitada a esto. Por lo tanto, se pueden llevar a cabo 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 de la Etapa S272 en la figura 27.

En la Etapa S273, cuando el resultado en la Etapa S272 es "ha habido alteración", se juzga que la autentificación ha fallado y se hace una notificación acerca de este hecho (Etapa S279) , después de lo cual se concluye el proceso. Cuando el resultado de la Etapa S272 es "no ha habido alteración, se ejecuta el proceso para la Etapa S274. Ahora, en referencia a la figura 31-figura 33, se da una descripción detallada de la autentificación de cadenas de certificados (Etapa S274) . Suponiendo que se llevara a cabo primero una revisión para el certificado intermedio 2312 y el certificado de origen 2313, un diagrama de flujo para esto se muestra en la figura 31. Primero, el certificado intermedio 2312 y el certificado de origen 2313 son extraídos de la cadena de certificados 231 (Etapa S311) . De este certificado de origen 2313 extraído, se extraen esta fecha y hora de actualización 2413, siguiente fecha y hora de actualización 2414 y el nombre de emisor 2415 (Etapa S312) . De ellos, se juzga si la fecha y hora actual está entre esta fecha y hora de actualización 2413 y la siguiente fecha y hora de actualización 2414 durante la cual el certificado puede permanecer válido (Etapa S313) . Si está más allá del periodo durante el cual el certificado puede permanecer válido, la autentificación de la cadena de certificados concluye en falla (Etapa S319) . Mientras tanto, cuando se juzga que está dentro del periodo válido del certificado, el nombre de sujeto 2416 y la clave pública 2417 en el certificado intermedio 2312 son extraídos (Etapa S314) , y se hace una comparación entre el nombre de sujeto 2416 del certificado intermedio 2312 y el nombre de emisor 2415 del certificado de origen 2313 para juzgar si el certificado intermedio 2312 y el certificado de origen 2313 están en una relación de cadena o no (Etapa S315) . Si estos certificados no están en una relación de cadena, la autentificación de la cadena de certificados es una falla. Mientras tanto, cuando hay una relación de cadena entre ellos, se calcula un valor de refundición para el área de atributo 241 del certificado de origen 2313 (Etapa S316) . Más aún, el valor de firma 242 en el certificado de origen 2313 es descifrado con la clave pública 2417 del certificado intermedio 2312 (Etapa S317) . Cuando se completan la Etapa S316 y la Etapa S317, se revisa si el valor de refundición y el valor de firma descifrado obtenidos en las etapas respectivas coinciden o no (Etapa S318) . Si no coinciden, la autentificación de la cadena de certificados concluye en falla (Etapa S319) . Después, se lleva a cabo una revisión entre el certificado de raíz 2311 y el certificado intermedio 2312. La figura 32 es una gráfica de flujo que muestra este proceso. El certificado de raíz 2311 y el certificado intermedio 2312 son extraídos de la cadena de certificados 231 (Etapa S321) , y un proceso que es equivalente a la revisión llevada a cabo para el certificado intermedio y el certificado de origen 2313 se lleva a cabo para el certificado de raíz 2311 y el certificado intermedio 2312 (Etapa S322 ~ Etapa S328) . Cuando se juzgue en la Etapa S328 que los valores coinciden, se lleva a cabo una revisión únicamente para el certificado de raíz 2311. La figura 33 es una gráfica de flujo que muestra una revisión que se llevará a cabo únicamente para el certificado de raíz 2311. Del certificado de raíz 2311 extraído en la Etapa S321, se extraen esta fecha y hora de actualización 2413, siguiente fecha y hora de actualización 2414 y el nombre de emisor 2415 (Etapa S331) . De ellos, se juzga si la fecha y hora actual está entre esta fecha y hora de actualización 2413 y siguiente fecha y hora de actualización 2414 durante la cual el certificado puede permanecer válido (Etapa S332) . Si está más allá del periodo durante el cual el certificado puede permanecer válido, la autentificación de la cadena de certificados concluye en falla. Mientras tanto, cuando se juzga que está dentro del periodo de validez del certificado, se calcula un valor de refundición para el área de atributo 241 del certificado de raíz 2311 (Etapa S334) . Además, el valor de firma 242 en el certificado de raíz 2311 es descifrado con la clave pública 2417 del certificado de raíz 2311 (Etapa S335) . Cuando se completan la Etapa S334 y la Etapa S335, se revisa si el valor de refundición y el valor de firma descifrado obtenidos en las etapas respectivas coinciden o no (Etapa S336) . Si sí coinciden, la autentificacion de la cadena de certificados es exitosa (S337) , mientras que si no coinciden, la autentificacion de la cadena de certificados concluye en falla (Etapa S338) . En este unto, el proceso de la Etapa S274 concluye. El proceso se lleva a cabo de manera diferente en la Etapa S275 dependiendo del resultado de S274. Cuando el resultado de la etapa 274 es "la autentificacion de la cadena de certificados falló", se juzga que la autentificacion ha fallado y se hace una notificación acerca de esto (Etapa S279) , y luego la autentificacion para el sistema de archivos concluye. Mientras tanto, en el caso de "la autentificacion de la cadena de certificados tuvo éxito", se lleva a cabo el proceso de la Etapa S276. Después, la unidad de almacenamiento secundaria 510 del aparato terminal 500 es escrutada para un certificado que sea el mismo que el certificado de raíz 2311 del archivo "/ocap. certifícate. 1" 2119 (Etapa S276) . Cuando el mismo certificado no está presente en la unidad de almacenamiento secundaria 510, se juzga en la Etapa S277 que la autentificacion de la cadena de certificados 231 es una falla, y se hace una notificación acerca de esta falla de autentificacion (Etapa S279) , después de lo cual se concluye el proceso. Mientras tanto, cuando el certificado de raíz 2311 está incluido, se juzga que la autentificacion del sistema de archivos es exitosa, y se hace una notificación al AM 1205b acerca de este éxito de autentificación (Etapa S278) . En referencia a la figura 28, incluso si una notificación de pre-activación para un programa Java se recibe después de eso (Etapa S281) , el proceso es concluido sin que nada se lleve a cabo. En la primera modalidad, cuando un programa Java almacenado va a ser activado después de cierto periodo de tiempo, no hay necesidad de llevar a cabo la autentificación en ese punto toda vez que el sistema de archivos ya fue autentificado inmediatamente antes de que fuera almacenado. Aqui, se da una descripción del caso en el que el "archivo de descripción de aplicación" mostrado en la figura 34 existe en el sistema de archivos y sólo los archivos descritos en el mismo van a ser almacenados. De acuerdo con la especificación OCAP, por ejemplo, "archivo de descripción de aplicación" se describe en el formato XML (Lenguaje de Marcación Extensible) . La figura 34 muestra un ejemplo de "archivo de descripción de aplicación" . En la figura 34 no hay descripción del "PPV2Xlet. class" 2115 mostrado en la figura 21. En este caso, por lo tanto, el "PPV2Xlet. class" 2115 no está incluido como objetivos de almacenamiento. En este caso, no se calcula valor de refundición en S292 para el "PPV2Xlet . class" 2115 y de esta manera no se hace comparación en S293 con el valor de refundición en 2233 descrito en el archivo wocap. hashfile" 2118. En la etapa S294, se puede hacer una transición al proceso de S295 al estipular que los archivos no incluidos como objetivos de almacenamiento están fuera de aplicación. Segunda Modalidad Cuando un programa Java (PPVlXlet. class 2114 o PPV2Xlet. class 2115) incluido en el sistema de archivos va a ser activado cierto periodo de tiempo después de que este sistema de archivos sea almacenado, existe la posibilidad de que la validez de uno de los certificados X. 509 incluido en el archivo 2119 "/ocap. certifícate. 1" haya expirado (es decir, la fecha y hora de activación del programa Java>siguiente fecha y hora de actualización 2414) . Sin embargo, la primera modalidad permite que el programa Java sea activado incluso si un certificado X. 509 ya expirado está incluido en la cadena de certificados 231. Así, la presente modalidad se logra al añadir, a la primera modalidad, la función de 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 de certificados 231 no haya expirado. La figura 26 muestra los elementos constituyentes de la presente modalidad. Los elementos constituyentes 261-265 necesarios para la presente modalidad ya se describieron en la primera modalidad, y por lo tanto no se dan aquí las descripciones de los mismos . Como gráficas de flujo, la gráfica de flujo de la figura 27 es reemplazada por la gráfica de flujo de la figura 35 y se añade la gráfica de flujo de la figura 36. En referencia a la figura 35, los procesos que se llevarán a cabo inmediatamente antes de que el sistema de archivos sea almacenado (Etapa S351 a Etapa S357) son los mismos que los procesos explicados en la primera modalidad (Etapa S271 a Etapa S277) , y por lo tanto se omiten las descripciones de los mismos. Si la autentificación no es una falla, el proceso pasa a la siguiente gráfica de flujo mostrada en la figura 36. Cuando una notificación de que el PPVlXlet . class 2114, el cual es un programa Java, va a ser activado después de cierto periodo de tiempo (Etapa S361) , cada uno de los certificdos X. 509, es decir, el certificado de raíz 2311, el certificado intermedio 2312 y el certificado de origen 2313 son extraídos del archivo wocap. certifícate. 1" 2119 (Etapa S362) . Después, los archivos X. 509 extraídos se seleccionan uno por uno en orden iniciando con el certificado de origen hasta el certificado de raíz (Etapa S363) , y se revisa si la fecha y hora actual está entre esta fecha y hora de actualización 2413 y la siguiente fecha y hora de actualización 2414 de cada uno de los archivos X. 509 seleccionados (Etapa S364) . Si la fecha y hora actual no está entre esta fecha y hora de actualización 2413 y la siguiente fecha y hora de actualización 2414, se juzga que la autentif icación es una falla y se hace una notificación acerca de este hecho (Etapa S367) . En el otro caso, se revisa si se han llevado a cabo o no revisiones para todos los certificados X. 509 (Etapa S365). Si no se han completado revisiones para todos los certificados X. 509, el proceso es regresado a S363 , y los procesos subsecuentes se repiten. Mientras tanto, cuando todos los certificados X. 509 ya han sido revisados en la Etapa S365, se juzga que la auten ificación es exitosa, y se hace una notificación acerca de este éxito de autentificación (Etapa S366), después de lo cual el proceso concluye. Al añadir los procesos mostrados en la gráfica de flujo de la figura 36, se hace posible notificar al AM 1205b de la falla de autentificación para que un programa Java cuyo periodo de validez haya expirado no sea activado. Cuando es notificado por el administrador de seguridad 1205f de una falla de autentificación, el AM 1205b aporta la activación sin pasar este programa Java al JavaVM 1203.

Tercera Modalidad Como se describió en la primera modalidad, la unidad de almacenamiento secundaria 510 incluye un certificado X. 509 que es el certificado de raíz, el cual se compara con el certificado de raíz 2311 en la cadena de certificados 231. El certificado de raíz almacenado en la unidad de almacenamiento secundaria 510 es reemplazado por un nuevo certificado X. 509 (en adelante referido como reemplazo de certificados) en preparación para el caso en el que la credibilidad del certificado se degrada debido a pirateo cibernético y otros aspectos. El nuevo certificado X. 509 se transmite desde el centro distribuidor 101 hasta el aparato terminal 500 que será suministrado al administrador de seguridad 1205f por medio del módulo de descarga 106. Las figuras 38A, 38B y 38C son diagramas, que muestran cada uno un certificado de raíz en la unidad de almacenamiento secundaria 510 que es reemplazado (reemplazo de certificados) por administrador de seguridad 1205f. en este caso, un certificado A381 es un certificado viejo que será reemplazado, mientras que un certificado B382 es un certificado nuevo. 38-1 En la figura 38? muestra el certificado almacenado en la unidad de almacenamiento secundaria 510 antes de que se lleve a cabo el reemplazo de certificados, 38-2 en la figura 38B muestra el certificado en medio de ser reemplazado, y 38-3 en la figura 38C muestra el certificado almacenado en la unidad de almacenamiento secundaria 510 después de que se llevó a cabo el reemplazo de certificados . En la primera modalidad y la segunda modalidad, incluso cuando el reemplazo de certificados se lleva a cabo después de que un programa Java es almacenado, no se hace consideración alguna para un certificado nuevo en el momento de la activación del programa Java. Considérese, por ejemplo, que el certificado de raíz 2311 en la cadena de certificados 231 coincida con el certificado A3811 cuando el administrador de seguridad 1205f esté autentificando un programa Java en respuesta a su notificación de pre-almacenamiento y que el administrador de seguridad 1205f reciba una notificación de pre-activación para el programa Java después de que el certificado B381 sea reemplazado por el certificado B382. En este punto de tiempo, la unidad de almacenamiento secundaria 510 no incluye ningún certificado que coincida con el certificado de raíz 2311 en la cadena de certificados 231, significando que este certificado no es creíble. Sin embargo, en la primera modalidad y la segunda modalidad, ya que no se hace comparación alguna entre los certificados de raíz inmediatamente antes de la activación de un programa Java (es decir, el certificado de raíz 2311 en la cadena de certificados 231 no se compara con el certificado B382) , no se hace una notificación al AM 1205b acerca de la falla de auten ificación . Como resultado, el ?? 1205b hace que el programa Java sea activado. Así, a la presente modalidad se le añade la función de llevar a cabo una comparación de certificados de raíz en consideración del reemplazo de certificados en el momento de la activación del programa Java. La figura 26 muestra los elementos constituyentes en la presente modalidad. Los elementos constituyentes 261 -265 ya han sido descritos y por lo tanto se omiten las explicaciones de los mismos. Una unidad de reemplazo de certificados 266, una unidad de especificación de reemplazo de certificados 267 y una unidad de recepción de certificación 268 son agregadas. Cuando la unidad de especificación de reemplazo de certificados 267 juzga que un certificado que es más viejo que el certificado recibido está almacenado en la unidad de almacenamiento secundaria 510, la unidad de reemplazo de certificados 266 reemplaza ese certificado viejo con el certificado nuevo. Mientras tanto, cuando la unidad de especificación de reemplazo de certificados 267 juzga que no está almacenado un certificado más viejo, la unidad de reemplazo de certificados 266 almacena el certificado nuevo en la unidad de almacenamiento secundaria 510. La unidad de especificación de reemplazo de certificados 267 recibe el certificado recibido por la unidad de recepción de certificados 268. Después, revisa el certificado almacenado en la unidad de almacenamiento secundaria 510 para ver si es algún certificado cuyo emisor sea el mismo y el cual sea más viejo que el certificado recibido, mediante el uso de la librería 1201b del OS 1201. La unidad de recepción de certificados 268 recibe un certificado nuevo cuando el módulo de descarga 1206 recibe este certificado nuevo desde el centro distribuidor 101. Luego de recibir el certificado, la unidad de recepción de certificados 268 lo pasa a la unidad de reemplazo de certificados 266 y a · la unidad de especificación de reemplazo de certificados 267. Además, la figura -39 y la figura 40 se agregan subsecuentemente a la gráfica de flujo de la figura 35. La figura 39 es una gráfica de flujo en el momento de llevar a cabo el reemplazo de certificados, mientras que la figura 40 es una gráfica de flujo en el momento de activar el programa Java después de que se llevó a cabo el reemplazo de certificados. En referencia a la figura 39, cuando se recibe una solicitud para el reemplazo de certificados (Etapa S391) , el nombre de emisor de este certificado recibido es extraído (Etapa S392) . Se revisa si un certificado viejo que necesita ser reemplazado está presente en la unidad de almacenamiento secundaria 510 del aparato terminal 500 (Etapa S393) , y sólo cuando está presente un certificado viejo, este certificado es borrado. Después, el certificado recibido se almacena en la unidad de almacenamiento secundaria 510 (Etapa S395) . Cuando una notificación de activación para el programa Java se recibe después de cierto periodo de tiempo (Etapa S401) , la unidad de almacenamiento secundaria 510 es escrutada para el certificado que coincida con el certificado de raíz 2311 en la cadena de certificados 231 (Etapa S402) , y si hay alguno (Etapa S403) , se juzga que la autentificación es exitosa y se hace una notificación de este hecho (Etapa S404) . Si no hay un certificado que coincida (Etapa S403) , se juzga que la autentificación es una falla y se hace una notificación acerca de este hecho (Etapa S405) . Nótese que antes de que se juzgue en la etapa S404 que la autentificación es exitosa, también es posible concluir que la autentificación es exitosa después de verificar que cada uno de los certificados X. 509 en la cadena de certificados satisfaga "esta fecha y hora de actualización<fecha y hora actual<siguiente fecha y hora de actualización" . Más aún, además de revisar si coinciden los certificados de raíz, también es posible juzgar que la autentificación es exitosa/no exitosa después de llevar a cabo, antes de S402, la revisió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. Además, las descripciones anteriores han sido dadas para el caso en el que un certificado que deba ser reemplazado se especifique con base en el nombre de emisor, pero el certificado también puede ser especificado con base en otro valor de atributo tal como el nombre del su eto. Cuarta Modalidad Cuando un programa Java (PPVlXlet. class 2114 o PPV2Xlet . class 2115) incluido en el sistema de archivos va a ser activado cierto periodo de tiempo después de que este sistema de archivos sea almacenado, existe un caso en el que un certificado es revocado debido a razones que no son que la validez de alguno de los certificados X. 509 incluidos en el archivo "/ocap. certificate. 1" 2119 haya expirado y que el certificado de raiz fue reemplazado. Esta configuración permite que el programa Java sea activado incluso cuando exista un certificado revocado. Aqui, CRL (Lista de Revocación de Certificados) es un revocador de certificados ampliamente conocido. 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 más detalles acerca de la CRL, refiérase a IETF RF C3280 "Internet X. 509 Public Key Infraestructure Certificate and CRL Profile" . 411 Indica un área de atributo de la CRL, 412 indica el algoritmo de firma de un valor de firma 413, y 413 indica el valor de firma de la CRL. El nombre de emisor 4111 indica al emisor de esta CRL, esta fecha y hora de actualización 4112 indica la fecha y hora cuando la C L se hace válida, siguiente fecha y hora de actualización 4113 indica la fecha y hora cuando la validez de la CRL expira, y la lista de certificados revocados 4114 indica información acerca de certificados X. 509 revocados. La figura 42 es un diagrama que muestra la estructura de la lista de certificados revocados 4114. Sólo los atributos que son necesarios para explicar la presente invención se ilustran aquí, también. La información acerca de una pluralidad de certificados X. 509 revocados se almacena en la lista de certificados revocados 4114. En el caso de la figura 42, como información acerca de un "certificado A" 421 revocado, sólo se incluyen un número de serie 4211 para identificar en forma única el certificado y la fecha y hora 4112 cuando el "certificado A" 421 fue revocado. Otros certificados revocados también son equivalentes a 421. La figura 43 es una configuración ejemplar de un sistema de archivos que incluye una CRL. Un directorio 431, un directorio "a" 432, un archivo "SimpleXlet . class" 433, archivos "ocap. hashfile" 434~435, un archivo "ocap. certifícate. 1" 436, un archivo "ocap. signaturefile . 1" 437, un archivo "ocap. crl . 2" 438 y un archivo "ocap. certifícate. 2" 439 están almacenados internamente. La autentificación de un sistema de archivos que no incluye una CRL es como la descrita en la primera modalidad. Así, en la presente modalidad la atención se centra en el archivo "oca . crl . 2" 438 que está estructurado en el formato CRL y el archivo "ocap. certifícate. 2" 439 que es la cadena de certificados de este archivo. Nótese que de acuerdo con la especificación OCAP, la cadena de certificados "ocap. crl. X" es "ocap. certifícate, x" . En el caso de la figura 43, la cadena de certificados del "ocap. crl. 2 " es "ocap. certifícate. 2". La figura 46 es un diagrama esquemático que muestra al archivo "ocap. hashfile" 434. 461 Muestra los detalles del ocap. hashfile 434. El ocap. hashfile en 461, el cual existe en el directorio "/" 431, incluye los valores de refundición relacionados con cada uno del archivo "ocap. certifícate. 1" 436, el archivo "ocap. signatrefile . 1", el directorio "a" 432, el archivo "ocap. crl. 2" 438 y el archivo "ocap. certifícate. 2" 439 que existen en el mismo directorio 431. La figura 44 es una gráfica de flujo para explicar la autentificación de una CRL. Se da la siguiente descripción para un ejemplo en el cual el sistema de archivo esté en la configuración mostrada en la figura 43. Primero, esta fecha y hora de actualización 4112 y la siguiente fecha y hora de actualización 4113 se extraen de la CRL (Etapa S441) , y se revisa si la fecha y hora actual están entre esta fecha y hora de actualización 4112 y siguiente fecha y hora de actualización 4113 (Etapa S442) . Si no, se juzga que esta CRL es inválida (Etapa S447) . Si la fecha y hora actual están entre ellas, un valor de refundición para el área de atributo 411 se calcula para verificar de esta manera el valor de firma del archivo "ocap. crl . 2" 438 (Etapa S443) . Al mismo tiempo, la clave pública 2417 del certificado de origen 2313 se extrae del archivo "ocap. certifícate. 2" 439, el cual es una cadena de certificados (Etapa S444) y el valor de firma 413 del archivo "ocap. crl. 2" 438 es descifrado con la clave pública 2417 extraída (Etapa S445) . Después, se revisa si el valor de refundición obtenido en la Etapa S443 es igual al valor descifrado obtenido en la Etapa S445 (Etapa S44S) . Si no son iguales, se juzga que la CRL es inválida (Etapa S447) . Si son iguales, en referencia a la figura 45, se lleva a cabo la autentificación para el archivo "ocap. certifícate. 2" 439 que es una cadena de certificados (Etapa S451) . Un método para autentificar la cadena de certificados es el mismo que el mostrado en la figura 31 a la figura 33, y por lo tanto no se describe aquí. Posteriormente, se juzga si la autentificación de la cadena de certificados es exitosa o no (Etapa S452) , y si la autentificación es una falla, se juzga que esta CRL es inválida (Etapa S456) . Mientras tanto, si la autentificación es exitosa, la unidad de almacenamiento secundaria 510 es escrutada para un certificado que sea el mismo que el certificado de raíz (Etapa S453) . Aquí, si no hay certificado de raíz que coincida, se juzga que la autentificación es una falla y que esta CRL es inválida (Etapa S456) , mientras que si está incluido un certificado de raíz coincidente, se juzga que la autentificación es exitosa y que la CRL es válida (Etapa S455) . A continuación se describe una solución al problema de que un programa Java sea activado a pesar de que un certificado sea revocado de acuerdo con la CRL. Para soportar esto, a la presente modalidad se le añade la función de juzgar si un certificado que fue usado para autentificar un programa Java es o no uno revocado en la CRL, cuando se haga una notificación de activación para este programa Java. La figura 26 muestra los elementos constituyentes de la presente modalidad. Excepto por 262 al cual se le hizo cierta adición y 269 el cual no ha sido descrito aún, no se da una descripción para los elementos constituyentes que han sido descritos arriba. La unidad de juicio 262, la cual es además capaz de autentificar una CRL, solicita a la unidad de especificación de revocación de certificados 269 especificar un certificado que será revocado por la CRL. Después, cuando la unidad de recepción de notificación 261 recibe una notificación de pre-activación para un programa Java que esté relacionado con un certificado revocado especificado por la unidad de especificación de revocación de certificados 269, la unidad de juicio 262 juzga que la autentificación es una falla. Mientras tanto, cuando la unidad de recepción de notificación 261 recibe una notificación de pre-activación para el programa Java en el estado en el cual la unidad de juicio 262 ha fallado en autentificar la CRL y por lo tanto juzgó que esta CRL era inválida, la unidad de juicio 262 juzga que la autentificación es exitosa. Cuando la unidad de juicio 262 reconoce que la autentificación de la CRL fue exitosa, la unidad de especificación de revocación de certificados 269 especifica cuál de los certificados X. 509 extraído por la unidad de extracción de certificados 265 es un certificado revocado. Como gráficas de flujo, se añaden la figura 47 y la figura 48. La siguiente descripción se da de acuerdo con estas gráficas de flujo. Suponiendo que una notificación de pre-almacenamiento para el sistema de archivos mostrado en la figura 1 se haga ahora, se inicia el proceso mostrado en la gráfica de flujo de la figura 35, y el proceso de la Etapa S357 se completa a su debido tiempo. Suponiendo que una notificación de pre-almacenamiento para otro sistema de archivos mostrado en la figura 43 sea entonces aceptada, la Etapa S471 a Etapa S477 se ejecutan después de la conclusión de los procesos mostrados en la gráfica de flujo de la figura 44. Los procesos de la Etapa S471 a la Etapa S477 son los mismos que los de la Etapa S351 a la Etapa S357. Cuando se alcanza la Etapa S478 y si la autentificacion del archivo "ocap. crl. 2" 438 (las gráficas de flujo de la figura 44 y figura 45) es exitosa, la información acerca de los certificados revocados contenidos en este archivo es escrita en la base de datos de certificados revocados. La figura 49 es un diagrama esquemático que muestra la base de datos de certificados revocados. Los nombres de emisor se almacenan en una columna 491, los números de serie de certificados se almacenan en una columna 492 y las fechas y horas de revocación se almacenan en una columna 493. Aquí, cuando una notificación de pre-act ivación para el "PPVlXlet. class" 2114 es aceptada (Etapa S481), se revisa que alguno de los certificados X. 509 incluidos en la cadena de certificados 231 del archivo "ocap. certifícate. 1" 2119 está incluido en la base de datos de certificados revocados (Etapa S483) . Si ahí aplica alguno de los certificados, se juzga que la autentificacion es una falla y se hace una notificación' acerca de esto (Etapa S486) . Mientras tanto, cuando no hay una certificación aplicable, se lleva a cabo una revisión para la cadena de certificados completa (Etapa S484) , y se hace una notificación que juzga que la autentificacion es exitosa (Etapa 485) . A través de los procesos anteriores, es posible resolver el programa de que un programa Java que no deba ser activado sea activado, al juzgar que la autentificación del archivo es una falla para un sistema de archivos cuyo certificado fue válido en el momento de la verificación pero el cual regresó revocado por la CRL en el momento en el que el programa Java fue activado. Nótese que en la primera a cuarta modalidades, cuando se recibe una notificación de pre-activación para un programa Java, también es posible llevar a cabo verificaciones adicionales para ver si la estructura de árbol de un sistema de archivos es correcta o no mediante el uso del "ocap. hashfile" puesto en cada directorio. Más aún, sólo hay un certificado intermedio en una cadena de certificados por motivos de simplificación, pero puede haber una pluralidad de certificados intermedios. Sin embargo, todos los certificados intermedios tienen que estar en una relación de cadena cuando se lleve a cabo la autentificación de la cadena de certificados. Además, los siguientes procesos han sido descritos en orden de mención, pero la presente invención no está limitada a este orden: revisar la presencia/ausencia de alteración; autentificación de una cadena de certificados y revisión para ver si la unidad de almacenamiento secundaria incluye un certificado de raíz que sea el mismo que el certificado de raíz en la cadena de certificados. Más aún, en cuanto al almacenamiento de un sistema de archivos, el administrador de seguridad 1205f puede almacenarlo usando la biblioteca 1201b del OS. Asimismo, las primera a cuarta modalidades también son aplicables al caso en el que "archivo de descripción de aplicación" se proporcione en el directorio de nivel superior "/" de un sistema de archivos, y como sus contenidos, sólo una parte del sistema de archivos se indique como archivos que serán almacenados. Asi, no ocurre problema alguno si sólo se manejan los archivos que serán almacenados. Además, los programas han sido descritos arriba como objetivos de almacenamiento, pero datos que no sean programas también pueden ser objetivos de almacenamiento, significando que las primera a cuarta modalidades también son aplicables a datos. Más aún, existe la posibilidad de que más de un "ocap. certifícate, x" corresponda a "ocap. signaturefile . x" , en cuyo caso se requiere que sea exitosa la autentificación de al menos uno de los archivos "ocap. certifícate . x" . Asimismo, "ocap. certifícate, x" ha sido presentado como una cadena de certificados ejemplar, "ocap. hasfile" ha sido presentado como un archivo ejemplar que tiene un valor de refundición y "ocap. signaturefile . x" se ha presentado como un archivo ejemplar para revisar si "ocap. hashfile" en un directorio "/" ha sido alterado o no, pero la presente invención no está limitada a estos nombres de archivo.

Además, en caso de una falla en la autentificación, ésta puede llevarse a cabo nuevamente después de una redescarga . Más aún, en caso de una falla en la autentificación, un programa almacenado así como una cadena de certificados, un archivo de firma, archivos de refundición que hayan sido usados para la autentificación pueden ser borrados para de esta manera reservar capacidad suficiente para el área de almacenamiento. Aqui, se da una descripción para el caso en el que un sistema de archivos que constituye un programa tiene una configuración mostrada en la figura 50 y no hay descripción de archivos que se usarán para la autentificación como en el caso de "archivo de descripción de aplicación" mostrado en la figura 51. 5011 a 5020 mostrados en la figura 50 son equivalentes a 2111 a 2120 mostrados en la figura 21. 5021 Significa "archivo de descripción de aplicación" que describe los archivos que serán almacenados. En "archivo de descripción de aplicación" en la figura 51, no hay descripción de "ocap. certifícate. 1" 5019, "ocap. signaturefile . 1" 5020 y "ocap. hashfile" 5017 que se requieren para la autentificación. En este caso, si los archivos se almacenan justo como se muestra en la figura 51, los archivos requeridos para llevar a cabo la autentificación no serán almacenados. Así, la autentificación presentada en las segunda, tercera y cuarta modalidades no se puede llevar a cabo en el momento de la activación. Cuando un programa almacenado va a ser activado, y los archivos mostrados en la figura 50, la cual muestra archivos antes de que estos programas sean almacenados, están listos para su descarga, los archivos almacenados pueden usarse como los archivos que constituyan el programa y los archivos usados para la autentificación pueden ser descargados de nuevo para usarse en la autentificación. Sin embargo, puede haber un caso en el que los archivos mostrados en la figura 50, la cual muestra archivos antes de que el programa sea almacenado, no puedan ser descargados. Por lo tanto, los archivos requeridos para la autentificación pueden ser almacenados para el uso de la autentificación que se lleve a cabo en el momento de la activación del programa, incluso si no se describen en "archivo de descripción de aplicación" . Aunque sólo algunas modalidades ejemplares de esta invención han sido descritas en detalle arriba, los expertos en la técnica apreciarán fácilmente que muchas modificaciones son posibles en las modalidades ejemplares sin alejarse materialmente de las enseñanzas y ventajas novedosas de esta invención. En consecuencia, se intenta que todas estas modificaciones sean incluidas dentro del alcance de esta invención .

Aplicabilidad Industrial El método de ejecución de programas autentificados de acuerdo con la presente invención, el cual es capaz de garantizar la credibilidad de un programa así como de mejorar la capacidad de respuesta, es útil para mejorar temporalmente la funcionalidad de un receptor de televisión digital, así como para añadir una función a éste. Más aún, la presente invención es aplicable no sólo a televisiones digitales sino también a usos tales como la mejora temporal de la funcionalidad de, y la adición temporal de una función a dispositivos de información controlados por software tales como computadoras personales y teléfonos móviles. 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 citada invención, es el que resulta claro de la presente descripción de la invención.

Claims

REIVINDICACIONES Habiéndose descrito lá invención como, antecede, se reclama como propiedad lo contenido en las siguientes reivindicaciones:

1. Un método de ej ecución de programas autentificados, caracterizado porgue comprende: una etapa de autentificación y almacenamiento para autentificar un programa incluido en una corriente de transporte y almacenar el programa autentificado en un receptor de transmisión de acuerdo con la información que se refiera al almacenamiento de cada archivo de datos del programa, y una etapa de ejecución para ejecutar el programa almacenado autentificado, en donde la etapa de autentificación y almacenamiento incluye : una primera etapa de verificar si dos valores de refundición son consistentes o no, uno de los valores de refundición siendo calculado a partir de cada archivo de datos incluido en el programa y el otro valor de refundición siendo almacenado en un archivo de refundición que corresponde a cada uno de los archivos de datos ; una segunda etapa de verificar si un archivo de certificados incluido en el programa es válido o no ; una tercera etapa de verificar si un valor descifrado y un valor de refundición son consistentes o no, el valor descifrado se obtiene al descifrar un valor de firma de un archivo de firmas incluido en el programa usando una clave pública de un certificado de origen incluido en el archivo de certificados del programa, y el valor de refundición se calcula a partir de un archivo de refundición localizado en un directorio superior del programa; y una cuarta etapa de autentificar el programa y almacenar cada archivo de datos del programa autentificado de acuerdo con la información que se refiera al almacenamiento, en caso de que se satisfagan todas las siguientes condiciones: que los dos valores de refundición se verifiquen como consistentes en la primera etapa; que el archivo de certificados se verifique como válido en la segunda etapa y que el valor descifrado y el valor de refundición se verifiquen como consistentes en la tercera etapa, y la etapa de ejecución incluye una quinta etapa de verificar si el archivo de certificados incluido en el programa almacenado es válido o no, y en la etapa de ejecución, el programa almacenado es autentificado nuevamente y ejecutado sólo en caso de que el archivo de certificados incluido en el programa almacenado se verifique como válido en la quinta etapa.

2. El método de ejecución de programas autentificados de conformidad con la reivindicación 1, caracterizado porque en caso de que el programa tenga una estructura de directorio, cada archivo de datos incluido en cada directorio y el archivo de refundición que corresponde a cada archivo de datos mencionado se localizan en un mismo directorio, y la primera etapa se ejecuta para cada archivo de datos incluido en cada directorio.

3. El método de ej ecución de programas autentificados de conformidad con la reivindicación 1, caracterizado porque la segunda etapa incluye una sexta etapa de verificar si dos certificados de raíz coinciden o no, uno de los certificados de raíz estando en el archivo de certificados incluido en el programa y el otro certificado de raíz estando instalado en el receptor de transmisión, y en la segunda etapa, el archivo de certificados es verificado como válido en caso de que coincidan los dos certificados de raiz.

4. El método de ejecución de programas autentificados de conformidad con la reivindicación 3, caracterizado porque la segunda etapa incluye además una séptima etapa de verificar un periodo de validez de cada certificado en el archivo de certificados incluido en el programa, y en la segunda etapa, el archivo de certificados se verifica como válido en caso de que se satisfagan ambas de las siguientes condiciones: que los dos certificados de raíz coincidan y que el tiempo en el cual se lleve a cabo la autentificación esté dentro del periodo de validez de cada certificado en el archivo de certificados.

5. El método de ejecución de programas autentificados de conformidad con la reivindicación 1, caracterizado porque la quinta etapa incluye una octava etapa de verificar si dos certificados de raiz · coinciden o no, uno de los certificados de raíz estando en el archivo de certificados incluido en el programa almacenado y el otro certificado de raíz estando instalado en el receptor de transmisión, y en la quinta etapa, el archivo de certificados incluido en el programa almacenado se verifica como válido en caso de que los dos certificados de raíz coincidan.

6. El método de ejecución de programas autentificados de conformidad con la reivindicación 5, caracterizado porque la quinta etapa incluye además una novena etapa de verificar un periodo de validez de cada certificado en el archivo de certificados incluido en el programa almacenado, y en la quinta etapa, el archivo de certificados incluido en el programa almacenado se verifica como válido en caso de que se satisfagan ambas de las siguientes condiciones: que los dos certificados de raíz coincidan y que el momento en el cual se lleve a cabo la ejecución esté dentro del periodo de validez de cada certificado en el archivo de certificados.

7. El método de ej ecución de programas autentificados de conformidad con la reivindicación 1, caracterizado porque el programa no va a ser almacenado en caso de que al menos una de las siguientes condiciones se satisfaga: que los dos valores de refundición no se verifiquen como consistentes en la primera etapa; que el archivo de certificados no se verifique como válido en la segunda etapa y que el valor descifrado y el valor de refundición no se verifiquen como consistentes en la tercera etapa .

8. Un aparato de ejecución de programas autentificados, caracterizado porque comprende: una unidad de autentificación y almacenamiento para autentificar un programa incluido en una corriente de transporte y almacenar el programa autentificado de acuerdo con información que se refiera al almacenamiento de cada archivo de datos del programa, y una unidad de ejecución que funciona para ejecutar el programa almacenado autentificado, en donde la unidad de autentificación y almacenamiento incluye : una primera unidad de verificación que funciona para verificar si dos valores de refundición son consistentes o no, uno de los valores de refundición siendo calculado a partir de cada archivo de datos incluido en el programa y el otro valor de refundición siendo almacenado en un archivo de refundición que corresponde a cada uno de los archivos de datos ; una segunda unidad de verificación que funciona para verificar si un archivo de certificados incluido en el programa es válido o no; una tercera unidad de verificación que funciona para verificar si un valor descifrado y un valor de refundición son consistentes o no, el valor descifrado se obtiene al descifrar un valor de firma de un archivo de firmas incluido en el programa usando una clave pública de un certificado de origen incluido en el archivo de certificados del programa, y el valor de refundición se calcula a partir de un archivo de refundición localizado en un directorio superior del programa; y una unidad de almacenamiento que funciona para autentificar el programa y almacenar cada archivo de datos del programa autentificado de acuerdo con la información que se refiera al almacenamiento, en caso de que se satisfagan todas las siguientes condiciones: que los dos valores de refundición se verifiquen como consistentes por la primera unidad de verificación; que el archivo de certificados se verifique como válido por la segunda unidad de verificación y que el valor descifrado y el valor de refundición se verifiquen como consistentes por la tercera unidad de verificación, y la unidad de ejecución incluye una cuarta unidad de verificación que funciona para verificar si el archivo de certificados incluido en el programa almacenado es válido o no, en donde la unidad de ejecución autentifica el programa almacenado nuevamente y ejecuta el programa almacenado autentificado sólo en caso de que la cuarta unidad de verificación verifique que el archivo de certificados incluido en el programa almacenado es válido.

9. Un programa caracterizado porque hace que una computadora ejecute: una etapa de autentificación y almacenamiento para autentificar un programa incluido en una corriente de transporte y almacenar el programa autentificado en un receptor de transmisión de acuerdo con la información que se refiera al almacenamiento de cada archivo de datos del programa, y una etapa de ejecución para ejecutar el programa almacenado autentificado, en donde la etapa de autentificación y almacenamiento incluye: una primera etapa de verificar si dos valores de refundición son consistentes o no, uno de los valores de refundición siendo calculado a partir de cada archivo de datos incluido en el programa y el otro valor de refundición siendo almacenado en un archivo de refundición que corresponde a cada uno de los archivos de datos; una segunda etapa de verificar si un archivo de certificados incluido en el programa es válido o no; una tercera etapa de verificar si un valor descifrado y un valor de refundición son consistentes o no, el valor descifrado se obtiene al descifrar un valor de firma de un archivo de firmas incluido en el programa usando una clave pública de un certificado de origen incluido en el archivo de certificados del programa, y el valor de refundición se calcula a partir de un archivo de refundición localizado en un directorio superior del programa; y una cuarta etapa de autentificar el programa y almacenar cada archivo de datos del programa autentificado de acuerdo con la información que se refiera al almacenamiento, en caso de que se satisfagan todas las siguientes condiciones: que los dos valores de refundición se verifiquen como consistentes en la primera etapa; que el archivo de certificados se verifique como válido en la segunda etapa y que el valor descifrado y el valor de refundición se verifiquen como consistentes en la tercera etapa, y la etapa de ejecución incluye una quinta etapa de verificar si el archivo de certificados incluido en el programa almacenado es válido o no, y en la etapa de ejecución, el programa almacenado es autentificado nuevamente y ejecutado sólo en caso de que el archivo de certificados incluido en el programa almacenado se verifique como válido en la quinta etapa.

10. El método de ejecución de programas autentificados de conformidad con la reivindicación 1, caracterizado porque la etapa de autentificación y almacenamiento incluye además una décima etapa de almacenar temporalmente, en una primera unidad de almacenamiento que almacena datos temporalmente, cada archivo de datos del programa incluido en la corriente de transporte, de acuerdo con la información que se refiera al almacenamiento de cada archivo de datos del programa, en las primera a tercera etapas, se llevan a cabo las verificaciones respectivas en cada archivo de datos del programa almacenado en la primera unidad de almacenamiento en la décima etapa, y en la cuarta etapa, el programa es autentificado y cada archivo de datos del programa autentificado se almacena en una segunda unidad de almacenamiento, en la cual los datos almacenados no son borrados incluso cuando se apaga la energía, de acuerdo con la información que se refiere al almacenamiento, en caso de que se satisfagan: que los dos valores de refundición se verifiquen como consistentes en la primera etapa; que el archivo de certificados se verifique como válido en la segunda etapa y que el valor descifrado y el valor de refundición se verifiquen como consistentes en la tercera etapa.