MXPA05009450A - Metodo para proporcionar parches para software. - Google Patents
Metodo para proporcionar parches para software.Info
- Publication number
- MXPA05009450A MXPA05009450A MXPA05009450A MXPA05009450A MXPA05009450A MX PA05009450 A MXPA05009450 A MX PA05009450A MX PA05009450 A MXPA05009450 A MX PA05009450A MX PA05009450 A MXPA05009450 A MX PA05009450A MX PA05009450 A MXPA05009450 A MX PA05009450A
- Authority
- MX
- Mexico
- Prior art keywords
- patch
- client
- level
- client system
- data
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
Abstract
Un metodo para proporcionar parches para software instalados en una pluralidad de sistemas del cliente, cada uno con por lo menos un procesador de datos y una memoria y cada uno programado para mantener informacion representativa de un nivel de parche real y para generar datos de salida para procesamiento de datos de entrada proporcionados a una aplicacion instalada con datos representativos de un nivel de parche requerido unicamente si el nivel de parche real se encuentra en una relacion predefinida con el nivel de parche requerido, incluye obtener un codigo de programa por computadora para inclusion en un parche, el codigo dispuesto para cooperar con por lo menos parte del software instalado en un sistema del cliente para realizar una cierta funcion despues de que se ha aplicado el parche en el sistema del cliente, proporcionar un primer parche para aplicacion en por lo menos un primer sistema del cliente con una instruccion para actualizar el nivel del parche real manteniendo en el sistema del cliente para reflejar un siguiente nivel; el metodo se caracteriza por proporcionar un segundo parche para al menos otro de los sistemas del cliente con una instruccion para actualizar el nivel del parche real manteniendo en el sistema del cliente para reflejar el siguiente nivel; el codigo se proporciona unicamente en el primero de los primeros y segundos parches.
Description
METODO PARA PROPORCIONAR PARCHES PARA SOFTWARE
MEMORIA DESCRIPTIVA
La invención se refiere a métodos para proporcionar parches para software instalados en una pluralidad de sistemas del cliente, cada uno con por lo menos un procesador de datos y memoria y cada uno programado para mantener información representativa de un nivel de parche real y para generar datos de salida al procesar datos de entrada proporcionados a una aplicación instalada con datos representativos de un nivel de parche requerido únicamente si el nivel de parche real se encuentra en una relación predefinida con el nivel de parche requerido, cuyos métodos incluyen: obtener un código de programa por computadora para inclusión en un parche, el código dispuesto para cooperar con por lo menos parte del software instalado en un sistema del cliente para realizar una cierta función después de que el parche ha sido aplicado en el sistema del cliente, proporcionar un primer parche para aplicación en por lo menos un primer sistema del cliente con una instrucción para actualizar el nivel de parche real mantenido en el sistema del cliente para reflejar un siguiente nivel. La invención también se refiere a un sistema de procesamiento de datos que incluye un procesador y memoria, programados para ejecutar dichos métodos.
La invención también se refiere a un programa de computadora dispuesto, cuando corre en un sistema de procesamiento programable para permitir que el sistema lleve a cabo dichos métodos. La invención también se refiere a un método para procesar parches proporcionados a un sistema del cliente que tiene un procesador y memoria, una interfaz para recibir parches y una ¡nterfaz para cargar datos de entrada para una aplicación instalada en el sistema del cliente, cuyo método incluye mantener información representativa de un nivel de parche real y generar datos de salida al procesar los datos de entrada proporcionados a la aplicación únicamente si el nivel de parche real se encuentra en una relación predefinida con un nivel de parche requerido indicado en información proporcionada con los datos de entrada, en donde el sistema del cliente se configura para actualizar el nivel de parche real mantenido en el sistema del cliente para reflejar un siguiente nivel tras la aplicación de un parche proporcionado con una instrucción apropiada. La invención también se refiere a un dispositivo de procesamiento de datos, que incluye un procesador, memoria, una interfaz para recibir parches y una ¡nterfaz para cargar datos de entrada para una aplicación instalada en el dispositivo de procesamiento de datos. La invención también se refiere a un programa de computadora adicional. Ejemplos de los métodos definidos anteriormente son conocidos a partir de EP-A2-0 217 351. Esa publicación describe un aparato de control de comunicación que incluye un circuito de transmisión-recepción conectado a una red de computadora para comunicarse entre una estación local y otras estaciones remotas, una unidad de almacenamiento regrabable en donde se almacena un programa de comunicación, una unidad de comparación para determinar si o no un número de versión de un programa de control de comunicación en un paquete aceptado por el circuito de transmisión-recepción es más nuevo que el del programa de control de comunicación almacenado en la unidad de almacenamiento. Un controlador actualiza el programa en base a la salida desde el comparador al enviar a la estación remota un mensaje que solicita transferir la versión más nueva del programa de control de comunicación. Un problema del método conocido es que requiere que todas las estaciones permanezcan idénticas, o el uso de paquetes con diferentes números de versión. La nueva versión del programa de comunicación debe ser aplicable en todas las estaciones si todas continúan involucrándose en cambios de paquetes con el mismo número de versión. Es un objetivo de la invención proporcionar métodos de los tipos mencionados anteriormente que permitan actualización reforzada del software instalado en una de una pluralidad de sistemas del cliente y tomar en cuenta una diferenciación entre los sistemas del cliente. Este objetivo se logra mediante un método para proporcionar parches del tipo definido anteriormente, que se caracteriza por proporcionar un segundo parche para por lo menos otros de los sistemas del cliente con una instrucción para actualizar el nivel de parche real mantenido en el sistema del cliente para reflejar el siguiente nivel, en donde el código se proporciona únicamente en el primero del primer y segundo parches. En lo que sigue, el término parche se utiliza para mencionar una construcción de datos para proporcionar un sistema de procesamiento programable con una pieza de código adecuada para inserción en un software instalado para corregir y/o mejorar el software instalado. El parche puede incluir adicionalmente un código que se corre únicamente cuando el parche se aplica, por ejemplo para cambiar el valor de punteros para datos o archivos utilizados ya sea por uno o ambos de los software ya instalados y cualquier código en el parche a insertarse. De este modo, la aplicación se refiere al procedimiento por medio del cual un parche aceptado por el sistema del cliente se hace funcional. Debido a que ambos el primer sistema o sistemas del cliente y el otro sistema o sistemas del cliente reciben la instrucción para actualizar el nivel de parche real para reflejar el mismo valor, los datos de entrada para todos los sistemas del cliente pueden proporcionarse con únicamente un nivel de parche requerido una vez que todos los sistemas del cliente se han actualizado. De este modo, no es necesario diferenciar entre los sistemas del cliente cuando se proporcionan datos de entrada para utilizarse por lo aplicación instalada en todos los mismos. Ya que un parche con un contenido de código diferente se proporciona al otro sistema o sistemas del cliente, es posible tomar en cuenta diferentes configuraciones existentes del sistema del cliente o volver a configurar el primer sistema u otros sistemas del cliente en diferentes formas. De acuerdo con otro aspecto de la invención, en el método para proporcionar parches, un valor objetivo de por lo menos una identificación se proporciona con cada parche, cada sistema del cliente teniendo un filtro para aceptar un parche únicamente si los valores se encuentran en las relaciones definidas previamente respectivas a las identificaciones correspondientes almacenadas en el sistema del cliente. Ya que se proporciona la identificación con cada parche, la diferenciación entre sistemas del cliente se toma en cuenta sin tener que comunicarse con cada sistema del cliente individualmente antes de proporcionar un parche para el sistema del cliente. De este modo, se proporciona una manera eficaz de actualizar el software instalado en la pluralidad de sistemas del cliente. De hecho, el método es adecuado para transmitir o enviar colectivamente todos los parches para todos los sistemas del cliente, ya sea sobre una red o al proporcionar un portador de datos con todos los parches en el mismo. De acuerdo con una modalidad útil, un valor de una identificación del propietario objetivo se proporciona con por lo menos el primer parche, cada sistema del cliente proporcionado con una memoria una vez programable y tiene un filtro que permite al sistema del cliente aceptar un parche únicamente si la identificación del propietario objetivo se encuentra en una relación predefinida con una identificación del propietario correspondiente programada en la memoria una vez programable. De este modo, se evita que un sistema del cliente aplique el parche incorrecto como una consecuencia de modificación no autorizada intencional o accidental de las identificaciones almacenadas en el sistema del cliente. En una modalidad preferida, un valor de una identificación de modelo objetivo se proporciona con por lo menos el primer parche, cada sistema del cliente proporcionado con memoria programable y teniendo un filtro que permite al sistema del cliente aceptar un parche únicamente si la identificación de modelo objetivo se encuentra en una relación predefinida con una identificación de modelo correspondiente almacenada en la memoria programable. De este modo, es posible establecer diferentes configuraciones de los sistemas del cliente que fueron originalmente idénticas, al programar una identificación de modelo diferente. Esto es una manera relativamente eficaz de proporcionar diferentes versiones de un solo modelo básico del sistema del cliente. Preferiblemente, el método además incluye proporcionar un parche para un sistema del cliente, cuyo parche se configura para hacer que el sistema del cliente cambie la identificación de modelo almacenada en la memoria programable a un valor diferente.
De este modo, diferentes versiones de un solo modelo básico de un sistema del cliente puede establecerse aún después del suministro de los sistemas del cliente a sus usuarios respectivos, simplemente al proporcionar los parches apropiados. En una modalidad preferida, la información indicativa de cierto nivel de parche se proporciona con por lo menos el primer parche. Esto permite la provisión de parches que "saltan" unos pocos niveles. En una situación en donde un sistema del cliente ha perdido pocos parches en una secuencia que lo lleva a un nivel nuevo, esta variante evita tener que aplicar uno por uno todos los parches que han sido perdidos. En una modalidad preferida, por lo menos el primer parche se proporciona con información indicativa de un nivel de parche requerido para aplicar el parche, cada sistema del cliente teniendo un filtro que permite al sistema del cliente aplicar el parche únicamente si el nivel de parche real mantenido en el sistema del cliente se encuentra en una relación predefinida con el nivel del parche requerido para aplicar el parche. De este modo, se evita que el sistema del cliente aplique un parche que requiere aplicación anterior de uno de los primeros parches anteriores para funcionar de manera apropiada. De esta manera refuerza una orden destinada particular de aplicación de una serie de parches en el sistema del cliente. En una modalidad preferida, se proporciona un parche en por lo menos un Mensaje de Manejo de Derecho para transferir a por lo menos un sistema del cliente en comunicación con un sistema decodificador relacionado, la aplicación en por lo menos un sistema del cliente incluye al menos una rutina para generar datos de palabra de control que permiten a los datos de contenido aleatorizados proporcionados al sistema decodificador ser desaleatorizados de por lo menos parte de los Mensajes de Control de Derechos seguido por el sistema decodificador asociado al sistema del cliente. Esta variante es particularmente una aplicación útil de los métodos de conformidad con la invención, ya que refuerza el uso de software actualizado para generar datos de palabra de control. De este modo, puede utilizarse para enmendar una violación de seguridad en el sistema del cliente. En particular, la violación puede enmendarse en diferentes formas para diferentes sistemas del cliente. En una variante preferida, los Mensajes de Manejo de derecho se transmiten al sistema decodificador, el sistema decodificador enviando los Mensajes de Manejo de Derecho al sistema del cliente. De este modo, una actualización por aire de sistemas del cliente en localidades variadas también se hace posible. En una modalidad preferida, en donde la aplicación incluye por lo menos una rutina para descifrar partes de los Mensajes de Control de Derecho que contienen las palabras de control cifradas que permiten a los datos de contenido aleatorizados provistos al sistema decodificador ser desaleatorizados, al menos parte de los Mensajes de Manejo de Derecho incluyendo el parche se cifran para permitirles descifrarse utilizando por lo menos una palabra de control provista al sistema decodificador en por lo menos un Mensaje de Control de Encabezado con información representativa del nivel de parche requerido que corresponde a un valor último del nivel de parche real mantenido en el sistema del cliente antes de la aplicación del parche. De este modo, únicamente los sistemas del cliente que fueron capaces previamente de generar palabras de control se actualizan. En una modalidad preferida, un parche se comunica con por lo menos uno de los sistemas del cliente en un primer punto en el tiempo y el dato de entrada se proporciona primero a por lo menos uno de los sistemas del cliente con datos representativos del siguiente nivel de parche requerido en un segundo punto en el tiempo, separado del primer punto en el tiempo por un intervalo de tiempo de introducción. De este modo, un cierto intervalo de tiempo está disponible para aplicar el parche en el sistema del cliente. Esto permite un modelo de transmisión de la distribución del parche. El cliente puede desconectarse durante la primera transmisión del parche, pero permanecer funcional hasta que el parche se transmite de nueva cuenta y se recibe por el mismo. También es innecesario transferir parches a todos de un grupo de sistemas del cliente en un intervalo muy corto, de este modo facilitando la congestión en los casos en donde el parche se transfiere sobre una red.
De acuerdo con otro aspecto, la inversión proporciona un sistema de procesamiento de datos que incluye un procesador y memoria, programados para ejecutar un método de conformidad con la invención. De acuerdo con otro aspecto, la invención proporciona un programa de computadora dispuesto, cuando corre en un sistema de procesamiento programable para permitir que el sistema lleve a cabo un método de conformidad con la invención. De acuerdo con otro aspecto de la invención, el método para procesar parches proporcionado a un sistema del cliente se caracteriza por almacenar por lo menos un valor de identificación en el sistema del cliente y permite al sistema del cliente aceptar un parche únicamente si cada valor de identificación almacenado se encuentra en una relación predefinida con uno respectivo de un conjunto de por lo menos un valor de identificación objetivo proporcionado con el parche. De este modo, el sistema del cliente se dispone para aceptar únicamente un parche destinado para eso. Ya que el valor del nivel de parche real se actualiza, el sistema del cliente permanece capaz de manejar datos de entrada proporcionados con el mismo número de versión al mismo y cualquier otro sistema del cliente que recibe y aplica un parche con un efecto diferente. Una modalidad preferida incluye aceptar un parche, y aplicar el parche, en donde aplicar el parche incluye ejecutar instrucciones para volver a disponer la configuración de por lo menos parte de la memoria en el sistema del cliente.
De este modo, el sistema del cliente se hace adecuado para ejecutar el software mejorado. Además, el sistema del cliente puede también hacerse adecuado para procesar datos de entrada en un nuevo formato necesario para aplicación de un parche diferente en otro sistema del cliente que procesa el mismo tipo de datos de entrada. En dichos casos, la funcionalidad del sistema del cliente no es necesariamente alterada de ninguna manera por el parche. De acuerdo con otro aspecto, la invención proporciona un dispositivo de procesamiento de datos, que incluye un procesador, memoria, una interfaz para recibir parches y una interfaz para cargar datos de entrada para una aplicación instalada en el dispositivo de procesamiento de datos, en donde el dispositivo se programa para llevar a cabo un método de conformidad con la invención. Las interfaces para recibir los parches y para cargar datos de entrada pueden presentarse en una interfaz. En una modalidad preferida, la interfaz para recibir parches y la interfaz para cargar datos de entrada incluye una interfaz física para una unidad de lectura/escritura en un sistema de procesamiento de datos externo al dispositivo de procesamiento de datos. De este modo, el dispositivo de procesamiento de datos no necesita equiparse con un dispositivo para leer medios de almacenamiento. Además, puede acoplarse a una unidad de lectura/escritura que se comprende en un sistema conectado a una red, de manera que se hacen posibles actualizaciones remotas sobre grandes distancias. De acuerdo con otro aspecto, se proporciona un programa de computadora dispuesto, cuando corre en un sistema de procesamiento programable que incluye un procesador, memoria, una ¡nterfaz para recibir parches y una ¡nterfaz para cargar datos de entrada, para permitir que el sistema de procesamiento programable lleve a cabo un método de conformidad con la invención. La invención ahora se explicará a detalle con referencia a los dibujos anexos, en donde: la figura 1 muestra una infraestructura adecuada para implementar un método para proporcionar parches para tarjetas inteligentes; la figura 2 es una ilustración esquemática de los componentes funcionales de un chip en una tarjeta inteligente de la figura 1 ; y la figura 3 es una ilustración esquemática de la composición de un número de modelo como se mantiene en la tarjeta inteligente. La figura 1 se utiliza en la presente para ¡lustrar un método para mejorar la funcionalidad de dispositivos de procesamiento programables utilizados como subsistemas de acceso condicionales para acceder datos de contenido. Un código que proporciona funcionalidad adicional se crea en un centro de creación de parche 1. Se debe proporcionar a una o más tarjetas inteligentes, (también conocidas como tarjetas de circuito integrado). La primera, segunda, tercera y cuarta tarjetas inteligentes 2-5, respectivamente, se muestran en la figura 1 como ilustrativas de una población mucho más grande de tarjetas inteligentes. Para proporcionar el código a las tarjetas inteligentes 2-5, un método para proporcionar parches a describirse a continuación se lleva a cabo al menos una vez a medida que el código de parches se mueve a través del sistema ilustrado en la figura 1. Una primera variante del método se lleva a cabo mediante un centro de personalización 6 para proporcionar un parche a la primera tarjeta inteligente 2. Una segunda variante se lleva a cabo por el centro de personalización 6 para proporcionar parches para la segunda, tercera y cuarta tarjetas inteligentes 3-5, por medio de entidades intermedias. Una tercera variante del método se lleva a cabo mediante un primer sistema de acceso condicional (CA) 7 y un segundo sistema de CA 8. Una cuarta variante se lleva a cabo mediante un transmisor de difusión 9 y un sistema que incluye un servidor de video-en-demanda (VOD) 10 y un servidor para transmitir mensajes de manejo de derecho (EMM). Componentes funcionales de un circuito integrado en una tarjeta inteligente se ilustran en la figura 2. La tarjeta inteligente incluye un procesador 12, una memoria de solo lectura (ROM) de máscara 13, una memoria de acceso aleatorio (RAM) 14 y memoria de solo lectura programable eléctricamente borrable (EEPROM) 15. Además, incluye una interfaz en serie 16. Las modalidades alternativas útiles de la tarjeta inteligente incluyen un co-procesador criptográfrico y/o una batería. Las tarjetas inteligentes adecuadas son aquellas de un tipo de contacto o tipo sin contacto. Sin embargo, las figuras 1 y 2 muestran únicamente tarjetas inteligentes 2-5 del tipo de contacto. En todos los casos, la tarjeta inteligente incluye una interfaz física para una unidad de lectura/escritura (no se muestra en la figura 2) en un sistema de procesamiento de datos externa a la tarjeta inteligente. En una tarjeta inteligente tipo contacto, dicha interfaz incluirá una disposición de almohadillas de contacto para contacto con pasadores de contacto correspondientes en la unidad de lectura/escritura. Una tarjeta inteligente sin contacto puede incluir una disposición de antena, como se sabe en la técnica. Se observa que los métodos descritos en la presente son igualmente aplicables a la provisión de parches para otros tipos de dispositivos de procesamiento portátiles con una interfaz física a una unidad de lectura/escritura en un dispositivo de procesamiento de datos externo. Otro ejemplo de dicho dispositivo es una tarjeta que se apega al estándar PCMCIA, o un dispositivo de procesamiento comprendido de una tecla de bus serie universal (USB). Ejemplos adicionales se les ocurrirán a los expertos en la técnica. Además, los métodos descritos en la presente también se aplican para proporcionar parches para asegurar que el agente del software cumpla las funciones similares a aquellas de una tarjeta inteligente y se instalen directamente en una caja de conexión o un sistema decodificador similar. La ROM 13 de máscara contiene el sistema operativo del chip y se conforma como parte del procedimiento de fabricación. Los contenidos de la ROM 13 de máscara no pueden cambiarse. En el ejemplo de la figura 1 , los contenidos de la ROM 13 de máscara son ¡guales para cada una de las tarjetas inteligentes 2-5, salvo para un número de serie de tarjeta inteligente única y una identificación del propietario que difiere por conjunto de una o más tarjetas inteligentes proporcionadas a una entidad particular haciéndolas disponibles a los usuarios finales. En una modalidad alternativa, aún el valor de identificación del propietario y/o número de serie de la tarjeta inteligente se almacenan en una unidad de memoria la cual es regrabable física, pero la tarjeta inteligente se dispone para evitar la re-programación de por lo menos el valor de identificación del propietario. Los mecanismos de prevención incluyen enmascarar una memoria de solo lectura programable ópticamente borrable (no se muestra), o una configuración adecuada de una rutina de control de memoria en la ROM 13 de máscara. La RAM 14 forma el espacio de trabajo de memoria a utilizarse por el procesador 12 mientras ejecuta programas almacenados en la ROM 13 de máscara y/o en la EEPROM 15. La RAM 14 es un tipo de memoria volátil. La EEPROM 15 mantiene los datos de aplicación y programas de aplicación adicionales. Es un tipo de memoria no volátil que permite a los datos ser escritos y leídos bajo control de programa. Sus contenidos se conservan aún cuando no se proporciona energía al chip. Otro tipo de memoria no volátil en la cual regrabable podría utilizarse para implementar los métodos descritos en la presente, no solo una EEPROM 15. Una aplicación en el contexto de la presente es un programa, o software, que implementa una función realizada por la tarjeta inteligente.
Ciertas aplicaciones se instalan antes de que se distribuyan físicamente las tarjetas inteligentes a los usuarios finales. Esto implica cargar el código en EEPROM 15. Posteriormente, la tarjeta inteligente se configura para ejecutar el código en emisión de un comando apropiado. Dependiendo del tipo de tarjeta inteligente, los valores de filtro utilizados por el sistema operativo tendrán que ajustarse para asegurar que el código se ejecute cuando una instrucción a este efecto se proporciona a través de la ¡nterfaz en serie 6 o se hace una llamada por otra aplicación o rutina de software. Los punteros para las ubicaciones en la memoria, por ejemplo, RAM 14 o EEPROM 15 pueden también tener que ajustarse para permitir que se instale la aplicación para escribir a o leer desde las ubicaciones de memoria. Al menos una de las funciones realizadas por una aplicación en las tarjetas inteligentes 2-5 es de manera útil una función de protección de contenido, específicamente una función en el procesamiento criptográfico de datos. Por ejemplo, en el sistema mostrado en la figura 1 , la segunda tarjeta inteligente 3 y la tercera tarjeta inteligente 4 descifran los datos de entrada proporcionados en los Mensajes de Control de Derecho (ECM) y Mensajes de Manejo de Derecho (EMM) transmitidos por el transmisor de difusión 9 al primer y segundo dispositivos decodificadores receptores integrados (IRD) 17, 18 sobre una red de transmisión 19 de conformidad con, por ejemplo el algoritmo común de aleatorización estándar de la transmisión de video digital (DVB), o un estándar comparable. De igual manera, la cuarta tarjeta inteligente 5 descifra información proporcionada en ECM por el servidor VOD 10, y la información proporcionada en EMM por el servidor 11 a través de una red de comunicación 20, por ejemplo la Internet, a un tercera IRD 21. El dato de contenido se almacena en un servidor de contenido limpio 22. En un sistema de transmisión de contenido, una primer unidad de aleatorización 23 aleatoriza los datos de contenido recibidos desde el servidor de contenido limpio 22 utilizando una serie de palabras de control consecutivas (CW). Las CW se insertan en ECM mediante el primer sistema de CA 7, que regresa los ECM para cifrar mediante la primera unidad de aleatorización 23. La primera unidad de aleatorización 23 y el primer sistema de CA 7 pueden combinarse en uno. El primer sistema de CA 7 también inserta datos representativos de un nivel de parche requerido en algunos o todos los ECM. Ya que el ECM se cifra, los datos representativos del nivel de parche requeridos también se cifran. El primer sistema de CA 7 también proporciona EMM, utilizando información recibida desde un primer sistema de manejo del suscriptor (SMS) 24. El primer SMS 24 tiene acceso a una base de datos que almacena detalles de la segunda y tercera tarjetas inteligentes 3, 4 expedidas a subscriptores a un servicio de transmisión. Una unidad de multiplexión 25 multiplexa corrientes de ECM, EMM y datos de contenido aleatorizado en una corriente de transporte, que se proporciona a los subscriptores mediante el transmisor de difusión 9. Excepto para la inserción de datos representativos de un nivel de parche requerido, la operación del sistema de transmisión es más o menos estándar.
En un tipo de video-en-demanda de distribución de contenido, los datos de contenido limpio se proporcionan mediante el servidor de contenido limpio 22 a una segunda unidad de aleatorización 26. La segunda unidad de aleatorización 26 aleatoriza los datos de contenido para ser descifrables utilizando una serie de CW variables. De nueva cuenta, las CW se proporcionan al segundo sistema de CA 8, que regresa los EC incluyendo la información de palabra de control. Algunos o todos los ECM incluyen información representativa de un nivel de parche requerido, que se hace conocido al segundo sistema de CA 8 como lo es para el primer sistema de CA 7, en una manera ya descrita. Al menos la información de palabra de control y los datos de nivel de parche requeridos en ECM se cifran. El dato de contenido aleatorizado y ECM se almacenan para reproducción subsiguiente en el servidor de VOD 10. El sistema VOD es similar al sistema de transmisión, porque el segundo sistema de CA 8 se encuentra en comunicación con un segundo SMS 27, dispuesto para almacenar información con relación a la cuarta tarjeta inteligente 5, proporcionada a un usuario del sistema de VOD. La información incluye los servicios a los cuales tiene acceso la cuarta tarjeta inteligente, como también una identificación única de la cuarta tarjeta inteligente, por ejemplo su número de serie. El servidor 11 para transmitir EMM proporciona EMM a un usuario de la cuarta tarjeta inteligente 5 que permite a las CW en ECM almacenadas en el servidor de VOD 1 recuperarse, junto con los datos representativos del nivel de parche requerido. La operación de un sistema de VOD como se describió anteriormente es conocido como tal, salvo por la provisión de datos representativos de un nivel de parche requerido con la información de palabra de control en los ECM. Cuando la segunda tarjeta inteligente 3 se utiliza para acceder contenido aleatorizado transmito a través de la red de transmisión 19, se inserta en el primer IRD 17, que es externo a la segunda tarjeta inteligente 3 y se proporciona con un módulo de lectura/escritura de tarjeta inteligente (no se muestra). El primer IRD 17 incluye una unidad de des-aleatorización (no se muestra) para des-aleatorizar los datos de contenido aleatorizado utilizando palabras de control que recibe desde la primera tarjeta inteligente 3. El contenido des-aleatorizado se hace disponible en un primer dispositivo de entretenimiento 28, por ejemplo una televisión. La segunda tarjeta inteligente 3 incluye una aplicación para decodificar las partes codificadas de EMM y ECM, que son seguidas al mismo mediante el primer IRD 17. El segundo IRD 18 se conecta a un segundo dispositivo de entretenimiento 29. El segundo IRD 18 intercambia información con la tercera tarjeta inteligente 4. De igual manera, el tercer IRD 21 intercambia datos con la cuarta tarjeta inteligente 5 y hace a los datos contenido limpio disponibles a un tercer dispositivo de entretenimiento 30. La segunda, tercera y cuarta tarjetas inteligentes 3-5 operan en una manear similar, de manera que esta descripción en su mayoría utilizará la segunda tarjeta inteligente 3 como un ejemplo.
Un parche puede proporcionarse a la segunda tarjeta inteligente 3 para implementar una modificación al programa instalado para procesamiento criptográfico de la información de palabra de control en ECM o información de derecho en EMM. Dicha modificación puede ocasionarse por una violación en la seguridad descubierta durante el uso. Otras modificaciones fijan problemas en la funcionalidad del software no crítico instalado en cualquiera de las tarjetas inteligentes 3-5. Otros parches pueden mejorar la funcionalidad de algunas o todas las tarjetas inteligentes 3-5. Cada una de las tarjetas inteligentes 3-5 tiene un filtro instalado. La tarjeta inteligente filtra los parches que recibe, aceptando únicamente aquéllos que cumplen los criterios de filtro programados, utilizando información proporcionada con los parches. Un parche aceptado se carga en su EEPROM 15 para uso subsiguiente. Para hacer funcional al parche, éste debe aplicarse. Hasta este punto, el parche incluye el código que debe instalarse para uso repetido y subsecuente e instrucciones ejecutadas únicamente una vez durante la aplicación del parche. Lo último es un procedimiento similar a la instalación por primera vez del software. El filtro preferiblemente se implementa en el software. Es de manera útil parte del sistema operativo o al menos parte almacenado en la ROM 13 de máscara u otro tipo de memoria una vez programable. De este modo, no puede comprometerse a través de un ataque por medio de un pirata informático (hacker). El filtro, el sistema operativo o un programa cargador de parche especial mantienen información representativa de un nivel de parche real, que se almacena en EEPROM 15. Este componente de la tarjeta inteligente también es responsable de las instrucciones proporcionadas con un parche que le dice que actualice el nivel del parche real como se representa por la información almacenada en EEPROM 15. Este nivel de parche real de esta manera refleja el número de parches aplicados en la tarjeta inteligente. En la variante a describirse en la presente a detalle, las instrucciones se incluyen en un mensaje que porta el código del parche. Las instrucciones pueden ser alternativamente implícitas, porque la tarjeta inteligente incrementa el nivel de parche real automáticamente cada vez que se aplica un parche aceptado. En otra variante, las instrucciones pueden contenerse en parte del parche que incluye un código ejecutado una vez cuando se aplica el parche. Se recordará que por lo menos algunos de los ECM incluyen datos representativos de un nivel de parche requerido, además de la información de palabra de control cifrada. La información de palabra de control descifrada únicamente se proporcionará al des-aleatorizador en IRD 17, 18, 21 si el nivel de parche requerido se encuentra en una relación predefinida con el nivel de parche real. En donde el nivel de parche se incrementa cuando se aplica un parche, el nivel de parche requerido tendrá que ser menor a, igual a, el nivel de parche real, con el fin de que funcione la aplicación que proporciona las palabras de control descifradas. De este modo, los operadores del primer y segundo sistemas de CA 7, 8, aseguran que los parches se aplican en la segunda, tercera y cuarta tarjetas inteligentes 3-5, aún cuando no tengan control físico directo sobre las tarjetas inteligentes 3-5, que se encuentran en posesión de los suscriptores. Los parches se crean y analizan en el centro de creación de parches (PCC) 1. Cada parche se cifra y proporciona en un archivo al centro de personalización 6. El centro de personalización 6 proporciona parches para la primera, segunda, tercera y cuarta tarjetas inteligentes 2-5, con valores objetivos de identificaciones de las tarjetas inteligentes para las cuales se pretende el parche particular. El centro de personalización 6 proporciona parches directamente a la primera tarjeta inteligente 2, utilizando una unidad de lectura/escritura de tarjeta inteligente 31. La primera tarjeta inteligente 2 es, por ejemplo, una tarjeta que debe aún distribuirse a un usuario final. La segunda a cuarta tarjetas inteligentes 3-5, que ya se encuentran en uso en el campo, se proporcionan con parches a través del intermediario del primer y segundo sistemas de CA 7, 8. Los parches se proporcionan en mensajes al primer, segundo y tercer IRD 17, 18, 21 , que los envían a la segunda, tercera y cuarta tarjetas inteligentes 2-5. Específicamente, los parches se proporcionan en uno o varios E especiales generados por el primer y segundo sistemas de CA 7, 8. Cada una de las tarjetas inteligentes 2-5 puede recibir un parche con su propio código específico. De este modo, la funcionalidad de únicamente una de las mismas puede mejorarse, o un defecto en únicamente una de las mismas puede remediarse. Subsecuentemente, cada una de las tarjetas inteligentes 2-5 permanece capaz de procesar los ECM. Esto es así, ya que cada una de las tarjetas inteligentes 2-5 se proporciona con un parche y una instrucción para aplicar el parche. De este modo, cada una de las mismas es instruida para actualizar el nivel de parche real mantenido en su EEPROM 15 para reflejar un siguiente nivel. La funcionalidad provista por el parche puede diferir entre las tarjetas inteligentes. De hecho, algunas de las mismas pueden proporcionarse con parches que dejan la funcionalidad del software instalada en la tarjeta inteligente como estaba antes de la aplicación del parche, es decir, un "parche ficticio". Los parches se portan en mensajes dirigidos en el nivel de enlace, es decir, teniendo la dirección de IRD 17, 18, 21. También se proporcionan con un valor objetivo de por lo menos una identificación. Esto es de este modo una forma de dirigir en el nivel de aplicación. Los valores de identificación correspondientes se almacenan en cada una de las tarjetas inteligentes 2-5, de manera que conozca qué parche aceptar. El formato de los valores de identificación es tal que es posible dirigir un grupo de tarjetas inteligentes con un valor. En otras palabrea, los parches no necesitan dirigirse a cada tarjeta inteligente en forma individual. Esto hace un uso más eficaz de las redes de transmisión 19 y red de comunicación 20, ya que los mensajes que portan los parches pueden transmitirse o enviar colectivamente. Al menos uno de los E M especiales que portan un parche incluye una identificación de propietario objetivo. El filtro en la tarjeta inteligente compara la identificación del propietario objetivo con la identificación del propietario almacenada en la tarjeta inteligente. A la tarjeta inteligente se le permite aceptar el parche únicamente si los dos valores corresponden. Se recordará que los valores de identificación del propietario son únicos para proveedores de tarjetas inteligentes. De este modo, el operador del primer sistema de CA 7 tendrá un valor de identificación del propietario diferente del valor asignado al operador del segundo sistema de CA 8. Eso particularmente útil en donde varios operadores transmiten, envían colectivamente o unidifunden los EMM especiales a través de la misma red, por ejemplo la Internet. Los EMM especiales que portan un parche también incluyen un número de identificación de modelo objetivo. Cada una de las tarjetas inteligentes 2-5 se configura para almacenar un valor de identificación de modelo real en EEPROM 15. El valor de identificación de modelo real evoluciona durante la vida de la tarjeta inteligente para reflejar cambios en la configuración del software de la tarjeta inteligente. El formato de un valor de identificación de modelo 32 se muestra en la figura 3. Es un valor único que representa un cierto diseño de EEPROM 15 (número de sectores, productos y parches). Cuatro bits se utilizan para codificar una versión de modelo mayor 33, cuatro bits para codificar una versión de modelo menor 34, ocho bits para codificar un número de construcción 35 y ocho bits para codificar un número variante 36. Un parche únicamente se acepta si el número de modelo real se encuentra una relación predefinida con el valor de identificación de modelo objetivo proporcionado con el parche. Al menos las versiones de modelo mayor y menor 33, 34 deben corresponder, por ejemplo, o el número de modelo total debería ser el mismo. La primera parte del valor de identificación de modelo 32 refleja la configuración de hardware del circuito integrado de la tarjeta inteligente. La segunda parte el diseño de memoria correspondiente a la configuración de software instalado. Un uso del número de modelo es proporcionar la segunda tarjeta inteligente 3 y tercera tarjeta inteligente 4, que tiene el mismo valor de identificación del propietario, con diferente funcionalidad mientras se utilizan en el campo. Para realizar esto, la segunda tarjeta inteligente 3 y la tercera tarjeta inteligente 4 son ambas enviadas a un parche divisor, que se aplica. El nivel de parche incrementa consecuentemente. El parche divisor contiene el código que se ejecuta al recibir un comando apropiado en un EMM. Únicamente a una de la segunda y tercera tarjetas inteligentes, 3, 4 se le envía la instrucción para ejecutar el código. Cuando se ejecuta, el código identifica el número variante 36 del valor de identificación de modelo real mantenido en la segunda o tercera tarjeta inteligente 3, 4. Subsecuentemente, dos parches diferentes se transmiten mediante el transmisor de difusión 9. Uno es proporcionado con el número de modelo modificado como valor de identificación de modelo objetivo, el otro con el número de modelo previo, como el valor de identificación de modelo objetivo. Unicamente uno de estos parches incluye un código que proporciona funcionalidad mejorada tras la aplicación del parche. El otro parche puede ser un "parche ficticio".
La funcionalidad adicional puede requerir una organización diferente de EEPROM 15. Esto puede incluir variables de reasignación a utilizarse por ambas la segunda y tercera tarjetas inteligentes 3, 4. En cada caso, el parche divisor, o un parche separado, se envía a la segunda y tercera tarjetas inteligentes 3, 4. Dicho parche incluirá instrucciones para re-disponer la configuración de memoria de la tarjeta inteligente, cuyas instrucciones se llevan a cabo tras la aplicación del parche. Dicha configuración de memoria se adapta a la tarjeta inteligente. Por ejemplo, puede ser posible tener diferentes tamaños de memoria asignadas a diferentes tipos de datos. Esto podría realizarse para tomar en cuenta los tamaños de memoria física específicos disponibles en la tarjeta, limitaciones en términos de escala de dirección de memoria, etc. Dicho parche puede proporcionar la funcionalidad para reasignar datos a una parte o partes diferentes de la memoria disponible y/o tomar en cuenta limitaciones para almacenar datos. En una vanante preferida, el parche se configura, cuando se aplica en dispositivo del cliente, para detectar una configuración del dispositivo del cliente y para re-disponer la configuración de memoria de conformidad con la configuración detectada. Información adicional proporcionada en los EMM especiales que porta un parche incluye un nivel de parche objetivo. El filtro en la tarjeta inteligente únicamente permite a la tarjeta inteligente aceptar un parche si el parche se proporciona con un nivel de parche objetivo en una relación predefinida con nivel de parche real almacenado en EEPROM 15. Esto asegura que los parches se apliquen en cada una de las tarjetas inteligentes 2-5 en un orden predeterminado. Esto es útil, ya que el código en un parche puede requerir la disponibilidad de una función proporcionada por un parche anterior con el fin de funcionar apropiadamente. Ya que la segunda, tercera y cuarta tarjetas inteligentes 3-5 reciben parches por aire, y en mensajes seguidos por los primeros, segundos y terceros IRD 17, 18, 21 , existe la posibilidad de que una de estas tarjetas inteligentes 3-5 pierda un parche. En una variante alternativa, un parche que no satisface la relación predefinida puede aceptarse, pero almacenarse como un archivo en EEPROM 15 para aplicación futura. Un parche se proporciona de manera útil con información que refleja el siguiente nivel tras la aplicación del parche. Esto permite que una tarjeta inteligente "brinque" unos cuantos niveles. La tarjeta inteligente simplemente aplica un parche que combina las mejoras proporcionadas por un número de parche y actualiza el valor de nivel de parche real en EEPROM 15 para reflejar el siguiente nivel. Esto es útil si una de las segundas, terceras o cuartas tarjetas inteligentes 3-5 no se encuentra en comunicación con cualquiera de los primeros, segundos y terceros IRD 17, 18, 21 durante algún tiempo, o si estos IRD no se han encontrado en uso durante mucho tiempo. La característica también es útil para acelerar la instalación de varias mejoras a una construcción de software básica en la primera tarjeta inteligente 2, que aún debe distribuirse. Para proteger las tarjetas inteligentes 3-5 contra virus, los parches proporcionados sobre la red de transmisión 19 y la red de comunicación 20 se cifran y autentifican utilizando claves que forman pares de claves almacenadas de manera segura en las tarjetas inteligentes 3-5. Un EMM que porta parte o todos los parches contiene de manera útil el código de parche en forma aleatorizada, para permitir la desaleatorización utilizando una o más palabras de control proporcionadas en un ECM o ECM. En una variante, las tarjetas inteligentes 3-5 recuperan las palabras de control de ECM o ECM, y una unidad de desaleatorización en IRD 17, 18, 21 des-aleatoriza el código de parche. Por razones de seguridad, sin embargo se prefiere descifrar las partes cifradas de EMM (s) que portan el código de parche en la tarjeta inteligente 3-5. De este modo, la tarjeta inteligente 3-5 únicamente recibe el código de parche cifrado. Preferiblemente, cada incremento en el nivel de parche es seguido por un período de introducción. Durante el período de introducción, la relación predefinida entre el nivel de parche real almacenada en la segunda, tercera y cuarta tarjetas inteligentes 3-5 y el nivel de parche requerido indicado en los ECM no sólo se satisface si la segunda, tercera y cuarta tarjetas inteligentes 3-5 se encuentran en el siguiente, es decir, en el nivel de parche incrementado, sino también si se encuentran en un nivel de parche por debajo del siguiente nivel de parche. En una variante, a la segunda, tercera y cuarta tarjetas inteligentes 3-5 se les envía información indicativa de un intervalo de introducción. La aplicación responsable de reforzar el nivel de parche permite descifrar las palabras de control cifradas durante el intervalo de tiempo de introducción. El tiempo real puede obtenerse mediante la segunda, tercera y cuarta tarjetas inteligentes 3-5 desde las estampas de tiempo en mensajes de derecho aleatorizadas (ECM y/o EMM), desde un reloj interno o desde un reloj en uno de los IRD 17, 18, 21 , como se sabe en la técnica. En una variante simple preferida, un parche se comunica con por lo menos una de la segunda, tercera y cuarta tarjetas inteligentes 3-5 en un primer punto en el tiempo y se proporcionan primero datos de entrada a por lo menos una de las tarjetas inteligentes 3-5 con datos representativos del siguiente nivel del parche requerido en un segundo punto en el tiempo, separado del primer punto en el tiempo mediante un intervalo de introducción. De este modo, las tarjetas inteligentes 3-5 no necesitan mantener la trayectoria de tiempo para este propósito. Se ha observado que el centro de personalización 6 lleva a cabo variantes del método para proporcionar parches para software instalados en las tarjetas inteligentes 2-5. El centro de personalización 6 obtiene parches del centro de creación de parches 1. Si las tarjetas inteligentes 2-5 se mueven hacia arriba uno o más niveles del parche, al menos uno de los parches incluye un código de programa para sustituir o mejorar al menos parte de un componente de software instalado en una o más de las tarjetas inteligentes 2-5. Otros parches pueden no incluir códigos que proporcionan una mejora funcional del todo, o pueden proporcionar una mejora funcional diferente o modificación.
En el ejemplo mostrado, el centro de personalización 6 proporciona parches en dos maneras diferentes. En primer lugar, actualiza directamente la primera tarjeta inteligente 2, al proporcionarla con el parche apropiado y la información correspondiente a la información proporcionada a la segunda, tercera y cuarta tarjetas inteligentes 3-5 en especial EMM. De este modo, la primera tarjeta inteligente 2 recibe el parche con un valor de identificación del propietario objetivo y un valor de identificación de modelo objetivo, como también un nivel de parche requerido e información indicativa del siguiente nivel de parche, el valor del cual debe mantenerse en la primera tarjeta inteligente 2 tras la aplicación del parche. En segundo lugar, el centro de personalización 6 proporciona parches al primer y segundo sistema de CA 7, 8. Los parches para la segunda y tercera tarjetas inteligentes 3, 4 se proporcionan en un primer archivo de carga de parche. Un parche para la cuarta tarjeta inteligente 5 se proporciona en un segundo archivo de carga de parche. Adicionalmente, un primer archivo de tarjeta inteligente de carga se crea por el primer sistema de CA 7 y un segundo archivo de carga inteligente se crea para el segundo sistema de CA 8. Un archivo de carga de tarjeta inteligente incluye información de tarjeta inteligente única. El primer archivo de carga de tarjeta inteligente incluye los números de serie de la segunda y tercera tarjetas inteligentes 3, 4, como también la identificación de modelo objetivo, el nivel de parche requerido y el valor del siguiente nivel de parche global. De este modo, esto incluye de manera implícita una instrucción para la segunda y tercera tarjetas inteligentes 3, 4 para actualizar el nivel de parche real mantenido en la segunda y tercera tarjetas inteligentes 3, 4 para reflejar el siguiente nivel tras la aplicación del parche destinado para esto. Este parche, se recordará, es contenido en el archivo de carga de parche. El primer y segundo archivos de carga de parche y el primer y segundo archivos de carga de tarjeta inteligente se proporcionan al primer y segundo sistemas de CA 7, 8 mediante transmisión a través de una red o en un portador de datos, tal como un disco compacto. Ambos archivos se cifran y firman por el centro de creación de parches. Unicamente si el primer y segundo sistemas de CA tiene las claves correspondientes pueden tener acceso a los archivos y verificar sus orígenes. La invención no se limita a las modalidades descritas anteriormente, que pueden variarse dentro del alcance de las reivindicaciones anexas. Por ejemplo, algunos de los campos, tal como la versión 33 de modelo mayor del número de modelo real almacenado en una tarjeta inteligente puede almacenarse en una parte de la memoria que no es regrabable. También, los parches pueden transmitirse juntos en un o más EMM especiales a todas las tarjetas inteligentes 3-5, que filtran los correctos, o pueden enviar colectivamente y/o unidifundir por separado a aquellas tarjetas inteligentes 3-5 que realmente son para aplicar el parche pretendido.
Claims (4)
1- Método para proporcionar parches para software instalados en una pluralidad de sistemas del cliente (
2-5), cada uno teniendo al menos un procesador de datos (12) y memoria (1
3-15), y cada uno programado para mantener información representativa de un nivel de parche real y para generar datos de salida al procesar datos de entrada proporcionados a una aplicación instalada con datos representativos de un nivel de parche requerido únicamente si el nivel de parche real se encuentra en una relación predefinida con el nivel de parche requerido, cuyo método incluye: obtener un código de programa por computadora para inclusión en un parche, el código dispuesto para cooperar con por lo menos parte del software instalado en un sistema del cliente (2-5) para realizar una cierta función después de que el parche ha sido aplicado en el sistema del cliente, proporcionando un primer parche para aplicación en por lo menos un primer sistema del cliente con una instrucción para actualizar el nivel de parche real mantenido en el sistema del cliente (2-5) para reflejar un siguiente nivel, caracterizado porque proporciona un segundo parche para al menos uno de los otros sistemas del cliente (2-5) con una instrucción para actualizar el nivel de parche real mantenido en el sistema del cliente para reflejar el siguiente nivel, en donde el código se proporciona únicamente en el primero de los primeros y segundos parches. 2. - El método de conformidad con la reivindicación 1, o el preámbulo de la reivindicación 1 , caracterizado además porque el valor objetivo de por lo menos una identificación se proporciona con cada parche, cada sistema del cliente (2-5) teniendo un filtro para aceptar un parche únicamente si los valores se encuentran en relaciones predefinidas respectivas con las identificaciones correspondientes almacenadas en el sistema del cliente (2-5). 3. - El método de conformidad con la reivindicación 2, caracterizado además porque un valor de una identificación del propietario objetivo se proporciona con al menos el primer parche, cada sistema del cliente (2-5) proporcionado con una memoria una vez programable (13) y que tiene un filtro que permite al sistema del cliente (2-5) aceptar un parche únicamente si la identificación del propietario objetivo se encuentra en una relación predefinida con una identificación del propietario correspondiente programada en la memoria una vez programable. 4. - El método de conformidad con la reivindicación 2 ó 3, caracterizado además porque un valor de una identificación de modelo objetivo se proporciona con por lo menos el primer parche, cada sistema del cliente (2-5) proporcionado con memoria programable (15) y con un filtro que permite al sistema del cliente aceptar un parche únicamente si la identificación de modelo objetivo se encuentra en una relación predefinida con una identificación de modelo correspondiente almacenada en la memoria programable (15). 5. - El método de conformidad con la reivindicación 4, caracterizado además porque incluye proporcionar un parche para un sistema del cliente (2-5), cuyo parche se configura para hacer que el sistema del cliente cambie la identificación de modelo almacenada en la memoria programable (15) a un valor diferente. 6. - El método de conformidad con cualquiera de las reivindicaciones 1-5, caracterizado además porque la información indicativa de cierto nivel de parches se proporciona con por lo menos el primer parche. 7. - El método de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado además porque por lo menos el primer parche se proporciona con información indicativa de un nivel de parche requerida para aplicar el parche, cada sistema del cliente (2-5) con un filtro que permite al sistema del cliente aplicar el parche únicamente si el nivel de parche real mantenido en el sistema del cliente se encuentra en una relación predefinida con el nivel de parche requerido para aplicar el parche. 8. - El método de conformidad con cualquiera de las reivindicaciones 1-7, caracterizado además porque un parche se proporciona en al menos un mensaje de manejo de derecho para transferir a al menos un sistema del cliente (3-5) en comunicación con un sistema decodificador relacionado (17, 3; 18, 4; 21 , 5), la aplicación en por lo menos un sistema del cliente incluyendo al menos una rutina para generar datos de palabra de control que permiten que los datos de contenido aleatorizados proporcionados al sistema decodificador (17, 3; 18, 4; 21, 5) se des-aleatoricen desde al menos partes del mensaje de control de derecho seguido por el sistema decodificador relacionado para el sistema del cliente. 9. - El método de conformidad con la reivindicación 8, caracterizado además porque los mensajes de manejo de derecho se transmiten al sistema decodificador (17, 3; 18, 4; 21 , 5), el sistema de codificador enviando los mensajes de manejo de derecho al sistema del cliente (3-5). 10. - El método de conformidad con la reivindicación 8 ó 9, caracterizado además porque la aplicación incluye por lo menos una rutina para descifrar partes de los mensajes de control de derecho que contienen palabras de control cifradas que permiten a los datos de contenido aleatorizado proporcionarse al sistema decodificador a ser desaleatorizado y en donde al menos parte de los mensajes de manejo de derecho que incluyen el parche se cifran para permitirles ser descifrados utilizando al menos una palabra de control proporcionada al sistema decodificador en al menos un mensaje de control de derecho con información representativa de un nivel de parche requerido que corresponde a un valor último del nivel de parche real mantenido en el sistema del cliente antes de la aplicación de parche. 11. - El método de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado además porque un parche se comunica con por lo menos uno de los sistemas del cliente (2-5) en un primer punto en el tiempo y datos de entrada se proveen primero a por lo menos uno de los sistemas del cliente con datos representativos del siguiente nivel de parche requerido en un segundo punto en el tiempo, separado del primer punto en el tiempo por un intervalo de tiempo de introducción. 12. - El sistema de procesamiento de datos que incluye un procesador y memoria, programados para ejecutar un método de conformidad con cualquiera de las reivindicaciones 1- 1. 13. - Un medio legible por computadora dispuesto, cuando corre en un sistema de procesamiento programable para permitir al sistema llevar a cabo un método de conformidad con cualquiera de las reivindicaciones 1-1 . 14. - El método para procesar parches proporcionados a un sistema del cliente (2-5) con un procesador (12) y memoria (13-15), una interfaz (16) para recibir parches y una interfaz (16) para cargar datos de entrada para una aplicación instalada en el sistema del cliente (2-5), cuyo método incluye mantener información representativa de un nivel de parche real y generar datos de salida al procesar datos de entrada proporcionados a la aplicación únicamente si el nivel de parche real se encuentra en una relación predefinida con un nivel de parche requerido indicado en información proporcionada con los datos de entrada, en donde el sistema del cliente (2-5) se configura para actualizar el nivel de parche real mantenido en el sistema del cliente para reflejar un siguiente nivel tras la aplicación de un parche proporcionado con una instrucción apropiada, caracterizado por almacenar al menos un valor de identificación en el sistema del cliente y permitir al sistema del cliente aceptar un parche únicamente si cada valor de identificación almacenado se encuentra en una relación predefinida con uno respectivo de un conjunto de por lo menos un valor de identificación objetivo provisto con el parche. 15. - El método de conformidad con la reivindicación 14, caracterizado además porque el sistema del cliente (2-5) se proporciona con una memoria una vez programable (13), en donde los valores de identificación almacenados incluyen una identificación de propietario almacenada en una memoria una vez programable (13), y el método incluye permitir al sistema del cliente aceptar el parche únicamente si una identificación del propietario objetivo se proporciona con el parche y la identificación propietario objetivo se encuentra en una relación predefinida con la identificación del propietario almacenada en la memoria una vez programable. 16. - El método de conformidad con la reivindicación 14 ó 15, caracterizado además porque el sistema del cliente se proporciona con memoria programable (15) y el método incluye permitir al sistema del cliente aceptar un parche únicamente si el parche se proporciona con una identificación de modelo objetivo en una relación predefinida con una identificación de modelo correspondiente almacenada en la memoria programable (15). 17. - El método de conformidad con cualquiera de las reivindicaciones 1
4-16, caracterizado además porque el valor del siguiente nivel se deriva de la información proporcionada con el parche. 18. - El método de conformidad con cualquiera de las reivindicaciones 14-17, caracterizado además porque incluye derivar un valor de un nivel de parche requerido para aplicar el parche desde la información provista con el parche y permitir que al sistema del cliente (2-5) aplicar el parche únicamente si el nivel de parche requerido que aplica el parche se encuentra en una relación predefinida con el nivel de parche real. 19.- El método de conformidad con cualquiera de las reivindicaciones 14-18, caracterizado además porque el parche es recibido en un mensaje de manejo de derecho, y en donde al menos parte del mensaje de manejo de derecho se descifra para obtener al menos parte del parche. 20.- El método de conformidad con cualquiera de las reivindicaciones 4-19, caracterizado además porque incluye recibir datos de entrada que incluyen información cifrada con información que indique el nivel del parche requerido, y correr la aplicación para descifrar la información cifrada. 21 - El método de conformidad con cualquiera de las reivindicaciones 14-20, que incluye aceptar un parche, aplicar el parche, actualizar el nivel de parche real mantenido a partir de una reflexión de un valor previo para reflejar un siguiente nivel de parche, y subsecuentemente aplicar el parche, permitiendo que la aplicación procese datos de entrada proporcionados con una indicación de un nivel de parche requerido en la relación predefinida únicamente con el nivel previo durante una parte restante de un intervalo de tiempo de introducción que separa un primer punto en el tiempo, antes de la aplicación del parche, desde un segundo punto en el tiempo, luego del primer punto en el tiempo. 22.- El método de conformidad con cualquiera de las reivindicaciones 14-21 , que incluye aceptar un parche, y aplicar el parche, en donde aplicar el parche incluye ejecutar instrucciones para re-disponer la configuración de por lo menos parte de la memoria (14, 15) en el sistema del cliente (2-5). 23 - Dispositivo de procesamiento de datos, que incluye un procesador (12), memoria (13-15), un interfaz (16) para recibir parches y una interfaz (16) para cargar datos de entrada para una aplicación instalada en el dispositivo de procesamiento de datos (2-5), en donde el dispositivo de procesamiento de datos se programa para llevar a cabo un método de conformidad con cualquiera de las reivindicaciones 14-22. 24. - El dispositivo de procesamiento de datos de conformidad con la reivindicación 23, caracterizado además porque la interfaz (16) para recibir parches y la interfaz (16) para cargar datos de entrada incluye una interfaz física para una unidad de lectura/escritura (31 ) en un sistema de procesamiento de datos (6; 17; 18; 21) externo al dispositivo de procesamiento de datos (2-5). 25. - Un medio legible por computadora dispuesto, cuando corre en un sistema de procesamiento programable que incluye un procesador (12), memoria (13-15), un interfaz (16) para recibir parches y una interfaz ( 6) para cargar datos de entrada para permitir que el sistema de procesamiento programable lleve a cabo un método de conformidad con cualquiera de las reivindicaciones 14-22.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP04104285A EP1632848A1 (en) | 2004-09-06 | 2004-09-06 | Method of providing patches for software |
Publications (1)
Publication Number | Publication Date |
---|---|
MXPA05009450A true MXPA05009450A (es) | 2006-04-27 |
Family
ID=34929541
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
MXPA05009450A MXPA05009450A (es) | 2004-09-06 | 2005-09-05 | Metodo para proporcionar parches para software. |
Country Status (13)
Country | Link |
---|---|
US (1) | US20060136898A1 (es) |
EP (1) | EP1632848A1 (es) |
JP (1) | JP2006079611A (es) |
KR (1) | KR20060050967A (es) |
CN (1) | CN1776611A (es) |
AR (1) | AR050794A1 (es) |
AU (1) | AU2005205818A1 (es) |
BR (1) | BRPI0503688A (es) |
CA (1) | CA2517535A1 (es) |
MX (1) | MXPA05009450A (es) |
RU (1) | RU2005127726A (es) |
TW (1) | TW200609821A (es) |
ZA (1) | ZA200507121B (es) |
Families Citing this family (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8539469B2 (en) * | 2004-05-11 | 2013-09-17 | Microsoft Corporation | Efficient patching |
US7680825B2 (en) * | 2005-12-30 | 2010-03-16 | Sap Ag | Systems and methods for generating tenant-specific properties for use in a provider-tenant environment |
US7698284B2 (en) * | 2005-12-30 | 2010-04-13 | Sap Ag | Systems and methods for deploying a tenant in a provider-tenant environment |
US20070156902A1 (en) * | 2005-12-30 | 2007-07-05 | Becker Wolfgang A | Systems and methods for implementing a tenant space in a provider-tenant environment |
US7917607B2 (en) | 2005-12-30 | 2011-03-29 | Sap Ag | Software management systems and methods, including use of such systems and methods in a provider-tenant environment |
US20070156901A1 (en) * | 2005-12-30 | 2007-07-05 | Wolfgang Becker | Generation and use of table links in a provider-tenant environment |
US7689593B2 (en) | 2005-12-30 | 2010-03-30 | Sap Ag | Systems and methods for accessing a shared space in a provider-tenant environment |
US20070156849A1 (en) * | 2005-12-30 | 2007-07-05 | Wolfgang Becker | Systems and methods for delivering software upgrades in a provider-tenant environment |
US7693851B2 (en) * | 2005-12-30 | 2010-04-06 | Sap Ag | Systems and methods for implementing a shared space in a provider-tenant environment |
EP1811778A1 (fr) * | 2006-01-24 | 2007-07-25 | Nagracard S.A. | Méthode de mise à jour du microprogramme d'un module de sécurité |
US8775572B2 (en) | 2006-06-23 | 2014-07-08 | Microsoft Corporation | Public network distribution of software updates |
US7739348B2 (en) * | 2006-12-29 | 2010-06-15 | Sap Ag | Systems and methods for accessing a shared space in a provider-tenant environment by using middleware |
US20080162483A1 (en) * | 2006-12-29 | 2008-07-03 | Becker Wolfgang A | Methods and systems for protecting shared tables against unauthorized overwriting from a tenant space in a mega-tenancy environment |
US20080162587A1 (en) * | 2006-12-29 | 2008-07-03 | Ulrich Auer | Server synchronization for maintenance activities |
US20080162490A1 (en) * | 2006-12-29 | 2008-07-03 | Becker Wolfgang A | Methods and systems for automatic registration during deployment of a tenant |
US7933869B2 (en) * | 2006-12-29 | 2011-04-26 | Sap Ag | Method and system for cloning a tenant database in a multi-tenant system |
US20080162536A1 (en) * | 2006-12-29 | 2008-07-03 | Becker Wolfgang A | Systems and methods for extending shared data structures with tenant content in a provider-tenant environment |
US8069184B2 (en) | 2006-12-29 | 2011-11-29 | Sap Ag | Systems and methods to implement extensibility of tenant content in a provider-tenant environment |
EP2015173A1 (en) * | 2007-07-05 | 2009-01-14 | Hewlett-Packard Development Company, L.P. | Method of maintaining software updates by means of dependency expressions |
US20090132999A1 (en) * | 2007-11-21 | 2009-05-21 | At&T Corp. | Secure and fault-tolerant system and method for testing a software patch |
US7516367B1 (en) | 2008-05-30 | 2009-04-07 | International Business Machines Corporation | Automated, distributed problem determination and upgrade planning tool |
US11553250B2 (en) * | 2008-09-02 | 2023-01-10 | Comcast Cable Communications, Llc | Updating application code |
US8224828B2 (en) * | 2009-12-22 | 2012-07-17 | Sap Ag | Multi-client generic persistence for extension fields |
FR2967852B1 (fr) * | 2010-11-18 | 2013-07-05 | Freebox | Ensemble de diffusion par reseau ip de flux video numeriques embrouilles vers des terminaux ip directement relies a ce reseau |
JP5688297B2 (ja) * | 2011-01-06 | 2015-03-25 | 任天堂株式会社 | 通信システム、情報処理装置、通信プログラムおよび通信方法 |
JP5675373B2 (ja) | 2011-01-06 | 2015-02-25 | 任天堂株式会社 | 通信システム、情報処理装置、通信プログラムおよび通信方法 |
KR101246360B1 (ko) * | 2011-12-30 | 2013-03-22 | (주)네오위즈게임즈 | 메모리 및 임시 메모리를 이용한 패치 방법 및 그를 이용한 패치 서버, 패치 클라이언트 |
EP2849464A1 (en) * | 2013-09-17 | 2015-03-18 | Gemalto SA | Method of communicating between a server and a secure element |
US9547489B2 (en) * | 2014-03-31 | 2017-01-17 | Qualcomm Incorporated | System and method for modifying a sequence of instructions in a read-only memory of a computing device |
TWI550515B (zh) * | 2014-12-17 | 2016-09-21 | 晨星半導體股份有限公司 | 原始碼品質管理系統與方法 |
CN105867887A (zh) * | 2015-01-22 | 2016-08-17 | 晨星半导体股份有限公司 | 原始码质量管理系统与方法 |
US10846080B2 (en) | 2018-09-06 | 2020-11-24 | International Business Machines Corporation | Cooperative updating of software |
CN113434165A (zh) * | 2021-06-02 | 2021-09-24 | 武汉天喻信息产业股份有限公司 | 一种嵌入式操作系统的补丁更新方法及系统 |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5586304A (en) * | 1994-09-08 | 1996-12-17 | Compaq Computer Corporation | Automatic computer upgrading |
FR2741972B1 (fr) * | 1995-11-30 | 1998-01-02 | Thomson Multimedia Sa | Dispositif et procede de chargement d'une interface utilisateur |
US6216175B1 (en) * | 1998-06-08 | 2001-04-10 | Microsoft Corporation | Method for upgrading copies of an original file with same update data after normalizing differences between copies created during respective original installations |
US6952823B2 (en) * | 1998-09-01 | 2005-10-04 | Pkware, Inc. | Software patch generator using compression techniques |
US20020078262A1 (en) * | 2000-12-14 | 2002-06-20 | Curl Corporation | System and methods for providing compatibility across multiple versions of a software system |
KR100400542B1 (ko) * | 2001-02-28 | 2003-10-08 | 엘지전자 주식회사 | 디지털 방송 수신장치의 광고를 이용한 시스템 소프트웨어업그레이드 장치 및 방법 |
JP2003216449A (ja) * | 2002-01-23 | 2003-07-31 | Nec Corp | パッチ処理システム |
US20030221190A1 (en) * | 2002-05-22 | 2003-11-27 | Sun Microsystems, Inc. | System and method for performing patch installation on multiple devices |
US20050120384A1 (en) * | 2003-12-01 | 2005-06-02 | General Instrument Corporation | Methods and systems for enabling software and firmware downloads to high definition television appliances |
EP1808017B1 (en) * | 2004-11-01 | 2012-03-21 | NDS Limited | Efficient and secure renewal of entitlements |
-
2004
- 2004-09-06 EP EP04104285A patent/EP1632848A1/en not_active Withdrawn
-
2005
- 2005-08-30 US US11/216,269 patent/US20060136898A1/en not_active Abandoned
- 2005-08-30 CA CA002517535A patent/CA2517535A1/en not_active Abandoned
- 2005-08-31 TW TW094129889A patent/TW200609821A/zh unknown
- 2005-09-02 AR ARP050103683A patent/AR050794A1/es unknown
- 2005-09-02 BR BRPI0503688-7A patent/BRPI0503688A/pt not_active IP Right Cessation
- 2005-09-02 KR KR1020050081669A patent/KR20060050967A/ko not_active Application Discontinuation
- 2005-09-02 CN CN200510099820.1A patent/CN1776611A/zh active Pending
- 2005-09-05 AU AU2005205818A patent/AU2005205818A1/en not_active Abandoned
- 2005-09-05 MX MXPA05009450A patent/MXPA05009450A/es unknown
- 2005-09-05 JP JP2005256922A patent/JP2006079611A/ja not_active Withdrawn
- 2005-09-05 RU RU2005127726/09A patent/RU2005127726A/ru not_active Application Discontinuation
- 2005-09-05 ZA ZA200507121A patent/ZA200507121B/xx unknown
Also Published As
Publication number | Publication date |
---|---|
CA2517535A1 (en) | 2006-03-06 |
AU2005205818A1 (en) | 2006-03-23 |
KR20060050967A (ko) | 2006-05-19 |
CN1776611A (zh) | 2006-05-24 |
AR050794A1 (es) | 2006-11-22 |
BRPI0503688A (pt) | 2006-04-25 |
EP1632848A1 (en) | 2006-03-08 |
TW200609821A (en) | 2006-03-16 |
ZA200507121B (en) | 2006-06-28 |
JP2006079611A (ja) | 2006-03-23 |
US20060136898A1 (en) | 2006-06-22 |
RU2005127726A (ru) | 2007-03-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
MXPA05009450A (es) | Metodo para proporcionar parches para software. | |
CN100559829C (zh) | 管理音频/视频数据的单元和所述数据的访问控制方法 | |
US7043020B2 (en) | Smartcard for use with a receiver of encrypted broadcast signals, and receiver | |
CN1655133B (zh) | 用于外部数据存储的方法与系统 | |
US7243241B1 (en) | Data distributing apparatus and terminal apparatus for data distribution | |
US20040107349A1 (en) | Method for securing software updates | |
CN1255266A (zh) | 防止欺诈性接入一个条件接入系统的方法和装置 | |
US20110083020A1 (en) | Securing a smart card | |
CN101390368A (zh) | 在便携式通信对象中对安全数字内容的安全访问的管理 | |
CA2724795C (en) | Method for the allocation and management of subscriptions for the reception of broadcast products | |
US20120257749A1 (en) | Method and processing unit for secure processing of access controlled audio/video data | |
KR100980523B1 (ko) | 보안 데이터 처리 시스템, 전자 장치와 그의 보호 방법, 스마트 카드 및 컴퓨터 판독가능 저장 매체 | |
CN1922877B (zh) | 一个接收终端与多个访问控制卡相匹配的方法 | |
KR20020084076A (ko) | 호스트용 인터페이스 모듈 및 디코더 | |
US8401190B2 (en) | Portable security module pairing | |
US7454618B2 (en) | System and methods for transmitting encrypted data with encryption key | |
EP1053633B1 (en) | Configuring method and device | |
EP2425620B1 (en) | Method to secure access to audio/video content in a decoding unit | |
CN105376619B (zh) | 一种机顶盒及与智能卡的通讯方法 | |
JP2001344216A (ja) | 記録制限情報付メモリーカードを用いたダウンロードシステム | |
EP0884906A1 (en) | Conditional access system with programmable mode of access | |
US20080276083A1 (en) | Method for Transmitting a Message Containing a Description of an Action to be Executed in a Receiver Equipment | |
WO2006016181A1 (en) | Encryption in communications systems using over - the - air rekeying | |
EP1633145A1 (en) | Secured electronic device |