MXPA02001441A - Generacion automatizada de paquetes condicionales de acceso para la ampliacion del ird via transferencia directa del software por radiofrecuencia en sistemas de television via satelite. - Google Patents

Generacion automatizada de paquetes condicionales de acceso para la ampliacion del ird via transferencia directa del software por radiofrecuencia en sistemas de television via satelite.

Info

Publication number
MXPA02001441A
MXPA02001441A MXPA02001441A MXPA02001441A MXPA02001441A MX PA02001441 A MXPA02001441 A MX PA02001441A MX PA02001441 A MXPA02001441 A MX PA02001441A MX PA02001441 A MXPA02001441 A MX PA02001441A MX PA02001441 A MXPA02001441 A MX PA02001441A
Authority
MX
Mexico
Prior art keywords
software
extension
ird
transmission
data
Prior art date
Application number
MXPA02001441A
Other languages
English (en)
Inventor
Fiallos Rosario
Original Assignee
Hughes Electronics Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hughes Electronics Corp filed Critical Hughes Electronics Corp
Publication of MXPA02001441A publication Critical patent/MXPA02001441A/es

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H04N21/8402—Generation or processing of descriptive data, e.g. content descriptors involving a version number, e.g. version number of EPG data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26233—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving content or additional data duration or size, e.g. length of a movie, size of an executable file
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26291—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for providing content or additional data updates, e.g. updating software modules, stored at the client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • H04N21/6547—Transmission by server directed to the client comprising parameters, e.g. for client setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/20—Adaptations for transmission via a GHz frequency band, e.g. via satellite
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Astronomy & Astrophysics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)
  • Radio Relay Systems (AREA)

Abstract

Un sistema y metodo automatico (10), para procesar previamente parametros de actualizacion de software (51), para transmitir a IRDs (40), por medio de transmisiones tradicionales sin la necesidad de intervencion manual repetida. Generalmente, la presente invencion es un sistema (10), que genera en forma automatica comandos de descarga de software que contienen todos los parametros necesarios (51), que un IRD (40), en una red de comunicacion por satelite requiere para completar una descarga de software, tal como, tiempo, frecuencia, y el lugar del software dentro de la corriente de datos entre otros parametros. La invencion (10), proporciona los datos de ampliacion del software (51) que seran transmitidos en paquetes de datos que comprenden una transmision satelital. La informacion transmitida incluye, la informacion de identificacion del receptor de transmision objetivo (IRD) y la informacion de ampliacion del software (51), para determinar si el IRD utilizado como objetivo (40), es de hecho el receptor correcto de los datos de ampliacion de software (51), y si el IRD (40) requiere una ampliacion del software. La urgencia de la ampliacion, esta determinada para permitir ampliaciones obligatorias, opcionales, diferidas a un periodo de tiempo posterior, o canceladas. La informacion de ampliacion es transmitida a traves de transmisiones por satelite tipicas (20) y ocurren en forma periodica sin intervencion humana, dependiendo de la version de ampliacion corriente de IRD (40).

Description

GENERACIÓN AUTOMATIZADA DE PAQUETES CONDICIONALES DE ACCESO PARA LA AMPLIACIÓN DEL IRD VIA TRANSFERENCIA DIRECTA DEL SOFTWARE POR RADIOFRECUENCIA EN SISTEMAS DE TELEVISIÓN VA SATÉLITE Campo del Invento La presente invención se refiere de manera general a un método y sistema para actualizar el software del IRDs del usuario en sistemas de radiotransmisión a base de satélite y más específicamente a un método y sistema automatizado para procesar previamente parámetros de actualización de software para la transmisión a los IRDs a través de radiotransmisiones tradicionales sin la necesidad de intervención manual repetida.
Antecedentes del Invento Los sistemas de televisión interactiva basados en satélite están incrementando su popularidad a nivel mundial, ya que los espectadores de la TV ahora tienen la capacidad de utilizar nuevos servicios tales como compras por televisión, orden de boletos, videos por pedidos y espectáculos de juegos interactivos. Las aplicaciones adicionales para la televisión interactiva, fluctúan desde comercialización hasta educación. También puede servir como un puente para la brecha entre los tipos de servicios de cable e Internet. Los componentes básicos de un sistema de televisión interactiva basada en satélite son una o más estaciones de transmisión en tierra, el sistema de enlace ascendente, uno o más satélites de comunicación, el sistema de enlace descendente, y una o más estaciones de recepción en tierra. Los satélites contienen tranceptores que reciben y transmiten señales, incluyendo programación de video, llamadas y datos por teléfono. Otros componentes clave del sistema son el Servidor de la Aplicación, para desarrollar aplicaciones y el suministro de información a través de la red al hogar del usuario; el Receptor/Decodificador Integrado interactivo (IRD), que corre el sistema de operación de TV abierto y descodifica las corrientes de video y audio; el Servidor de Transacción, el cual recibe respuestas del hogar y hacia el mismo para el Servidor de Cumplimiento del abastecedor de servicio, el cual procesa las órdenes del cliente. Frecuentemente, el IRD del usuario debe ser actualizado para permitir al mismo continuar utilizando las capacidades interactivas del sistema.
El fabricante del IRD debe suministrar al centro de radiotransmisión satelital con los parámetros IRD necesarios para completar una ampliación IRD. Los parámetros de actualización posteriormente pueden ser programados y transmitidos por medio de radiotransmisores RF tradicionales. Una desventaja asociada con la actualización de los IRDs en sistemas de radiotransmisión satelital convencionales, es que cada actualización debe realizarse en forma manual y requiere que el usuario ingrese la información de actualización (información de hora, frecuencia e identificación IRD) en forma manual, mientras que utiliza tres diferentes plataformas de software; DOS, Windows y UNIX, antes de completar la actualización. Este proceso largo consume tiempo, dinero y esfuerzo. Por lo tanto, lo que se necesita en la técnica es un sistema y método de actualización de software IRD automatizados que puedan generar en forma automática comandos de descarga de software para la transmisión al usuario por medio de radiotransmisiones tradicionales a base de satélite, y que permitan que los IRDs sean actualizados automáticamente sin la intervención repetida de un humano, mientras que se realiza sin la necesidad de ingresar la información de actualización a través de tres plataformas de software por separado. Por lo tanto, la presente invención está dirigida a la resolución efectiva de los problemas e inconvenientes antes mencionados de la técnica anterior .
Sumario del Invento Generalmente, la presente invención es un sistema que genera automáticamente comandos de descarga de software que contienen todos los parámetros necesarios que un IRD en una red de comunicación por satélite requiere para completar una descarga de software, tal como hora, frecuencia, el lugar del software dentro de la corriente de datos, entre otros parámetros. La presente invención, crea una escritura que será leído de los archivos sin la necesidad de intervención humana y se realiza sin la necesidad de utilizar tres plataformas (DOS, Windows, Unix) utilizando archivos de ingreso y procesamiento Unix con llamada automática. De manera específica, la presente invención es un método para generar en forma automática un comando de descarga de software para ampliar los IRDs en una red de comunicación a base de satélite que comprende los pasos de obtener un código de ampliación IRD e información IRD la cual es privada para un fabricante de IRD, generar un archivo que contiene la información privada del fabricante del IRD y el código de ampliación IRD formateado, transmitir el código de ampliación IRD formateado a un centro de radiotransmisión, ingresar los parámetros de actualización de IRD, seleccionar un IRD objetivo o una ubicación geográfica objetivo que contiene los IRDs que son para recibir el código de actualización, generar un comando de descarga de software, utilizando una sola plataforma de software, incluyendo el comando de descarga de software la información IRD objetivo formateada, crear un archivo de lote que incluye el comando de descarga de software y el código de ampliación IRD formateado, y transmitir los contenidos del archivo de lote en una radiotransmisión de enlace ascendente por satélite tradicional. Por lo tanto, es un objeto de la presente invención proporcionar un método y sistema automatizado para procesar previamente los parámetros de actualización de software para la transmisión a IRDs identificados por medio de radiotransmisiones tradicionales sin la necesidad de intervención manual repetida. Quedará entendido que tanto la descripción general anterior como la descripción detallada que se encuentra a continuación son a manera de explicación, y no son restrictivas de la presente invención, según es reclamada. Los dibujos que acompañan a la presente invención, los cuales están incorporados en y constituyen parte de la especificación, ilustran modalidades de la misma y junto con la descripción general, sirven para explicar los principios de la presente invención. De acuerdo con estos y otros objetos que se podrán apreciar de aquí en adelante, la presente invención será descrita con referencia particular a los dibujos que la acompañan.
Breve Descripción de los Dibujos La figura 1, ilustra un sistema de comunicación a base de satélite típico, que utiliza la presente invención . La figura 2, ilustra en forma de diagrama de bloque, el flujo de información total utilizando la modalidad preferida de la presente invención.
La figura 3, representa en forma de diagrama de bloque, los pasos específicos tomados por la modalidad preferida de la presente invención para generar en forma automática, comandos de descarga de software. La figura 4, representa un paquete de datos que ilustra la estructura de comando de un Anuncio de Ampliación utilizando la presente invención. La figura 5, representa un paquete de datos que ilustra la estructura de comando de un Anuncio Público utilizando la presente invención. La figura 6, representa un paquete de datos que ilustra la estructura de comando del Archivo de Carga tal como se presenta a la Estación de Radiotransmisión utilizando la presente invención. La figura 7, representa un paquete de datos que ilustra la estructura de comando de la parte del Encabezado del Archivo de Carga de la presente invención . La figura 8, representa un paquete de datos que ilustra la estructura de comando de la parte del Anuncio Privado del Archivo de Carga de la presente invención . La figura 9, representa un paquete de datos que ilustra la estructura de comando de la parte del bloque de datos del Archivo de Carga de la presente invención . La figura 10, representa un diagrama de flujo que ilustra los pasos tomados por la presente invención, para determinar si un IRD es para recibir información de ampliación de software.
Descripción Detallada del Invento Haciendo referencia a la figura 1, se muestra la arquitectura del sistema 10 de la presente invención. La presente invención es un método y sistema para ampliar el software IRD en una forma aerodinámica, no incomoda y eficiente. La figura 1, ilustra las partes de enlace ascendente y enlace descendente de una red de comunicación por satélite típica. Un Centro de Radiotransmisión 15 recibe parámetros IRD del fabricante del IRD. Esta información se incluye en la transmisión para una pluralidad de satélites de comunicación 20, las cuales posteriormente transmiten las señales de radiotransmisión a una antena de recepción del usuario 30. La antena 30. Está acoplada en forma eléctrica a un receptor de radiotransmisión (IRD) 40, el cual está acoplado en forma eléctrica a uno o más aparatos periféricos 50 tales como una televisión, computadora personal, PDA u otro aparato de recepción digital o análoga. La figura 2, ilustra en forma de diagrama de bloque, el proceso tomado por un operador de computadora que utiliza la presente invención, para generar en forma automática comandos de descarga de software que tienen todos los parámetros necesarios que requiere un IRD en una red de comunicación por satélite para completar una descarga de software. El proceso comprende la creación de un escritura de protección Unix para hacer posible la desviación de la tarea repetida que consume tiempo de utilizar múltiples programas de plataforma y tener que hacer interfase con cada uno. Un operador de computadora recibe el código de ampliación IRD 51 del fabricante de IRD, así como los parámetros de Comando CAP 52. Posteriormente, el operador corre un programa DOS (dtv2mpt) para generar una plantilla con datos privados del fabricante (propiedades del código que será descargado) y un archivo de Transporte de Paquetes Múltiples (MPT) (código formateado por el paquete (MPT) que será descargado) . Posteriormente, el archivo MPT es radiotransmitido en una radiotransmisión satelital tradicional en un número de Identificación de Servicio (SCID) y transpondedor previamente determinados. El SCID y el transpondedor son parte de los parámetros SWDL 51. Posteriormente, un escritura Unix, denominado CAPannounce se corre para generar un archivo CAP. El archivo CAP contiene información privada, el código de ampliación e información pública, suministrada por el radiotransmisor, incluyendo los IRDs objetivo que son para recibir la ampliación. Una vez que se han recibido y procesado los parámetros de código y comando, el paso 53, el código de software es formateado, los IRDs objetivos no identificados y tiene lugar, en el paso 54, las conversiones hexadecimales y de tiempo. El radiotransmisor decide si los IRDs específicos son para recibir la ampliación, si es así, ingresa los números de identificación adecuados. De manera alternativa, se identifica un geocódigo como correspondiente a una cierta región geográfica, en donde todos los IRDs dentro de la región son para recibir ampliaciones, paso 55. El resultado es un archivo de lote que es una salida a un centro de radiotransmisión en donde es enlazada en forma ascendente en una radiotransmisión satelital tradicional . Una vez que el código de ampliación 51 y los parámetros del comando CAP 52 han sido recibidos por el operador de la computadora, y los datos han sido formateados e ingresados, se pueden completar en forma automática los pasos restantes, por ejemplo, los pasos de identificar IRDs objetivos o áreas geográficas, frecuencia de actualizaciones, tiempo de cada actualización, etc., pueden ser programadas una vez y no necesitan ser programadas nuevamente. El escritura CAPannounce permite al software ampliarse para surgir en forma automática sin la necesidad de una reprogramación y reingreso de la fecha constantes. La figura 3, es un diagrama de bloque que ilustra el flujo de información del operador que ingresa parámetros de comando y la lista objetivo para la generación de un archivo de lote a través de la presentación del archivo a un Centro de Administración de Acceso Condicional (CAMC) para el enlace ascendente. Las variaciones de la presente invención, se pueden utilizar para la automatización de otra generación de lote tal como la llamada de regreso iniciada por el Cetro de Servicio al Cliente (CSS), descarga de parámetro del módem, y correo electrónico IRD. Se utiliza un Anuncio de Ampliación para notificar el IRD del usuario 40 cuando están disponibles oportunidades de ampliación. El anuncio aparece como un mensaje de "Envío de Datos" al IRD 40 por medio de un comando de la corriente de Paquetes de Acceso Condicional ("CAP") . Todo el proceso de ampliación del software opera como una serie de sesiones. El anuncio se utiliza para describir una sesión con gran detalle. Se define un número ID de sesión único para cada versión de ampliación de software. La misma transmisión de la versión del software en diferentes tiempos, puede tener la misma ID de sesión. Además, la misma transmisión de versión de software en diferentes tiempos puede tener la misma Versión de Sesión. Por ejemplo, dos sesiones con la misma ampliación de software pueden tener la misma ID de Sesión y Versión de Sesión, aunque diferentes tiempos de inicio. Esto es para permitir la flexibilidad de la red. La ampliación del software puede ser transmitida en un bajo rango de datos, continuo, dentro de las restricciones del campo de duración, o en un alto rango de datos en forma intermitente. En cualquier escenario, el IRD 40 procesa una ampliación del software. La ampliación comienza en el tiempo (s) de inicio de transmisión anunciado y se repite en forma antiparalela para la duración de sesión anunciada. El rango de operación puede ser tan bajo como de dos sesiones por día con dos transmisiones de la misma ampliación de software por sesión, hasta una transmisión continua. El número de transmisiones de la ampliación del software es igual a la duración dividida entre el tiempo requerido para transmitir la ampliación del software una vez. El tiempo requerido para transmitir la ampliación del software una vez es igual al tamaño de imagen de ampliación del software (más el encabezado) dividido entre el rango de datos de la transmisión. Por ejemplo, una transmisión de imagen de 1 Mega-byte en un rango de datos de 1 Mega-bit por segundo durante 16 segundos podría ser una transmisión de dos veces. Todos los IRDs deben tener la capacidad de soportar un rango de datos mínimo de lOOkbps. En este rango de datos, todos los IRDs reciben y procesan el archivo de ampliación de software en un tiempo consistente con 80 segundos por 1MB de código más, no más de 5 minutos adicionales hasta que el proceso de ampliación del software está completo y se despliega el video y audio. Para rango de datos más altos, ésta duración se aumenta de acuerdo con el rango de datos. Los anuncios son repetidos en forma continua antes y durante el transcurso de una ampliación. El tiempo de avance hasta la ampliación puede variar desde inmediatamente antes, hasta cualquier tiempo anterior, dependiendo de las características del programa de ampliación y de los acuerdos de operación. El ciclo de repetición para los anuncios puede correr desde varias veces un minuto, hasta una vez al día. Nominalmente, el tiempo del ciclo será de una vez cada 30 minutos incrementando posiblemente en frecuencia un corto tiempo antes de la transmisión de la ampliación del software. Sin embargo, el IRD debe tener la capacidad de acomodar cualquier frecuencia de anuncios. Después de la última sesión de ampliación del software, se envía un comando con el campo de urgencia ajustado a cero para cancelar cualquier intento de ampliación de software pendiente. El IRD 40 cancela una ampliación de software de transmisión anunciada previamente, pero puede ocurrir cuando se recibe un anuncio con un campo de urgencia ajustado a cero. Durante la operación nominal, se le asigna a cada ampliación de software un SCID único. El IRD 40 acepta y procesa preferentemente no más de una ampliación de software en un tiempo. El campo de versión de sesión permite que los parámetros de la red sean cambiados en cualquier tiempo antes de una ampliación del software sin invocar una interacción de la interfase del usuario. Cuando un valor de la Versión de Sesión es incrementado, el IRD 40 debe checar la variación en los campos de anuncio público tal como la Red ID, Transpondedor, SCID, Tiempo de Inicio, y Duración, y actualizar hasta el valor más reciente. El fabricante del IRD puede decidir remplazar todos los campos de anuncios públicos. El IRD 40 recibe toda la ampliación del software y lleva a cabo una verificación de la signatura digital en la imagen recibida. Debido a las condiciones de enlace teóricamente perfectas, el IRD 40 tiene la capacidad de recibir la ampliación del software en una sesión de transmisión. Si el IRD 40 no recibe en forma exitosa o en forma no valida la ampliación del software, el IRD no corrompe el código de operación y debe reanudar la operación normal . Si el IRD 40 está en el estado de ENCENDIDO al inicio de la recepción de la ampliación del software, el IRD despliega un texto en pantalla informando del estado inoperable temporalmente corriente del IRD durante la sesión de ampliación del software o hasta que el IRD ha recibido el código completo. Si el IRD 40 está en el estado de ENCENDIDO al inicio de la recepción de ampliación del software, el IRD debe desplegar una barra de estado, o indicar un porcentaje de estatus completo durante la ampliación del software. Se requiere de la recepción y procesamiento del CAP y guía de programación en forma continua antes de que comience la ampliación del software, y generalmente se prefieren durante la recepción del primer byte del código de ampliación del software a través de la verificación del código recibido, aunque antes de la escritura en la memoria no volátil ("FLASH") . No se requiere de la recepción y el procesamiento de la recepción del CAP y de la guía de programación durante el proceso de escritura en la memoria FLASH.
Está disponible un botón de opción de "Ampliación" en el menú principal para la información relacionada con la ampliación del software. Cuando ssee selecciona el botón de "Ampliación", deben estar presentes los botones de opción de información de "Ampliaciones Futuras" "Ampliaciones Pasadas". Un botón marcado, "Ampliaciones Futuras" proporciona información al usuario procedente del sistema del menú. Se debe desplegar la fecha, hora y versión de código de la ampliación. Un botón marcado "Ampliaciones Pasadas" proporciona información de la versión de código y datos y tiempo de recepción del usuario del menú del sistema. Si la configuración del ODU (Unidad Externa) no soporta una ampliación del software, el IRD debe rechazar el anuncio. El usuario tiene disponible la información que indica que se ha completado una vez una ampliación, la versión del código antiguo puede no ser restaurada. Si el IRD 40 no recibe la señal durante el tiempo de transmisión de ampliación del software (debido a desvanecimiento de lluvia, por ejemplo), el IRD debe reconocer, al momento de la readquisición, que no recibió la ampliación del software programada. Posteriormente, el IRD 40 despliega texto en pantalla que indica el intento no exitoso y que intentará nuevamente en la siguiente oportunidad. El Despliegue en Pantalla (OSD) debe terminar después de un período de 60 segundos y no reaparecer hasta que se realiza otro intento de ampliación no exitoso. Haciendo referencia a la figura 4, el archivo de Anuncio de Ampliación 60 comprende campos de comando público 70 y campos de comando privado 80 mantenidos en forma privada por los fabricantes del IRD. Los campos de comando público 70, aplican para todos los fabricantes del IRD. Los campos de comando privado 80 son únicos para cada fabricante de IRD. El fabricante del IRD suministra un campo en el anuncio de datos privado, especificando el número de intentos de ampliación del software antes de que se declare una falla. Un intento debe ser definido como, cuando ha iniciado una verificación de signatura en el código de descarga recibido antes de reemplazar el código corriente. Se supone que el IRD habrá recibido el número de bloque de datos igual al conteo de bloque de datos y los habrá ordenado en forma correcta. El IRD considera que la ampliación del software será una falla si la verificación fue correcta, pero la ampliación del software falló al reemplazar en forma adecuada el código corriente. Cuando el número intentado de ampliaciones de software intentados en forma no exitosa se alcanza, el IRD debe desplegar un texto en pantalla informando de la falta de éxito e instruyendo al usuario para tomar una acción adecuada. Si el IRD tiene la capacidad de desplegar video y audio, entonces después del reconocimiento del usuario el OSD debe desaparecer y el IRD debe desplegar video y audio . La meta del formato del anuncio es permitir al IRD identificar rápidamente si se requiere en un anuncio y permitirá a cada fabricante definir campos privados específicos para sus productos para filtraciones adicionales. El IRD 40 programa una sesión de recepción específica. La estructura del anuncio debe anunciar una sesión a la vez. Se pueden activar en cualquier momento múltiples anuncios. El IRD 40 almacena el siguiente anuncio disponible en la memoria no volátil. Posteriormente, el IRD 40 programa el siguiente tiempo de inicio disponible. Si el IRD tiene la capacidad de almacenar múltiples anuncios, estos son almacenados en forma cronológica con el siguiente tiempo de inicio disponible siendo accionado el primero por el IRD. Se descartan los anuncios con tiempos de inicio expirados. Lo que sigue a continuación, es una breve descripción de cada uno de los campos del comando público 70, transmitidos como parte del Anuncio de Ampliación 60. Aunque cada campo está descrito con un tamaño específico, está dentro del espíritu de la presente invención, proporcionar campos de datos de tamaño más grande si es necesario para la transferencia exitosa de la información de ampliación . La figura 5, muestra el formato de datos de comando para el campo de anuncio público 70. El campo ID del Fabricante 90, es normalmente un campo de 1/2-byte que identifica al fabricante del IRD de la presente ampliación del software. El ID del Fabricante debe coincidir exactamente con el ID del Fabricante almacenado en el IRD para la sesión de ampliación que será programada. A la luz de esto, deben coincidir otros parámetros (ver, figura 8) . El Código de Comando 100 normalmente tiene un campo de 1/2-byte que define el código de comando. En la presente modalidad, por ejemplo, las actualizaciones del software utilizan el código de comando que tiene un valor de 11. El bloque de la Versión de Comando 110, normalmente tiene un campo de 1-byte que específica la versión del código del comando. Esta versión inicial es de 0. El IRD no tomará acción e ignorará otras versiones. El bloque de Urgencia 120 normalmente tiene un campo de 1-byte que indica que tan afectado debe ser el IRD en realizar la ampliación. El IRD responde únicamente a ciertos valores. Por ejemplo, los valores de 0, 2, 100, 101 y 255 proporcionan información al IRD con respecto al nivel de urgencia concerniente a la presente ampliación. El anuncio es ignorado si los valores de Urgencias son diferentes a 0, 2 , 100, 101 ó 255 (en este ejemplo) . El bloque de ID de Sesión 130, normalmente tiene un campo de 3-bytes que identifica la sesión de ampliación del software. A cada sesión se le asigna un número de ID de Sesión único. La Versión de Sesión 140 normalmente tiene un campo de 1-byte que identifica la versión de la sesión de ampliación del software. La Versión de Sesión 140 permite la modificación de los parámetros de la red sin invocar la interacción del usuario.
Cualquier cambio en los campos de comando que inician a partir de la red ID hasta CRC_32 (explicado posteriormente), es procesado por el IRD 40 para determinar en forma adicional si se requiere de cualquier interacción de interfase del usuario. Un bloque de ID de Red 150, es un campo de 1-byte que identifica cual red de la ampliación del software surgirá. Por ejemplo, una Red de Satélite (A) puede consistir en la transmisión de servicios del satélite desde la ubicación de órbita del Oeste de 95 grados. Los valores de la ID de la red normalmente son definidos de 0 a 255. Así por ejemplo, si el valor del bloque de la ID de la red es de "0", entonces se define la Red A. Se pueden reservar otros IDs de la red para usos futuros. El bloque del Transpondedor 160, normalmente tiene un campo de 1-byte que indica que transpondedor de datos está encendido, por ejemplo, un valor de 1 puede referirse al transpondedor 1. Este campo utiliza un esquema de numeración a base de unos . El valor SCID 170 es un campo de 12-bits que identifica el paquete SCID que está llevando esta ampliación del software. Normalmente, no se utilizan los cuatro bits superiores y son enlistados como cero. Cada ampliación del software, identificada únicamente por el ID de Sesión 130, debe ser suministrado en un SCID único. El campo de Tiempo de Inicio 175 normalmente se refiere a un campo de 4-bytes que identifica el tiempo de inicio de la sesión de ampliación del software. Esto generalmente se define como el número de segundos GPS a partir del 6 de enero de 1980 a las 12 A.M. El campo de Duración 180, normalmente tiene un campo de 3-bytes que define la duración de la sesión de ampliación del software, medida en segundos. La duración debe ser un múltiplo entero de la transmisión de imágenes de la ampliación del software durante la sesión. El valor del Objetivo de Descargas de Emergencias 190, representa un campo de 4-bytes que hace posible al IRD del fabricante 40 permitir la recepción de una versión de código disminuida. Un valor del Objetivo de Descarga de Emergencia 190 de 0x00000000, hexadecimal, indica que el IRD del fabricante debe utilizar su método de ampliación por default, lo que significa que permite que únicamente sean introducidas al IRD versiones de código incrementada. Un valor del Objetivo de Descarga de Emergencia hexadecimal de no ceros 190, especifica la versión de código para la cual está dirigida esta ampliación. Si el valor del Objetivo de Descarga de Emergencia 190 especificado no coincide con el modelo y versión del software corriente del IRD, se debe rechazar el Anuncio de Ampliación 60. Si el valor del Objetivo de Descarga "de Emergencia 190 coincide con el modelo y Versión de Sesión 140 del software corriente, se debe procesar el Anuncio 60. El bloque de la Longitud de Información Privada 200 normalmente tiene un campo de un byte que contiene información que indica el número de bytes del campo de Datos de Información Privada 210. El campo de Datos de Información Privada 210 se refiere a una estructura de longitud variable que especifica los parámetros de ampliación del software privados para el fabricante, identificados por el ID del Fabricante. Los campos 200 y 210 contienen información que es suministrada por el fabricante del IRD y enviada al centro de transmisión satelital. Es en el centro de transmisión, en donde se crea el Anuncio 60, y en donde se incluye esta información .
El bloque CRC_32 220 es un campo de revisión de error de 4-bytes. Este es el MPEG CRC_32 estándar de la industria que aplica para todo el anuncio.
Cada actualización de software es suministrada utilizando un formato de paquete de datos MPT. La estructura MPT consiste en ensamblar 1 o más paquetes MPT juntos.
La tabla anterior se refiere a las definiciones Tipo Cuadro de Señal MPT. El Tipo de Cuadro es un campo de 4-bits que identifica esta versión del paquete MPT. Por ejemplo, los rangos de la versión pueden ser desde 0 hasta 15. Generalmente se utiliza un valor Tipo Cuadro de 2 para todas las ampliaciones del software. El campo de Tipo de Detección de Error, ilustrado en la tabla que se encuentra a continuación, normalmente es un campo de 2-bits que identifica el método de Reducción de Redundancia Cíclica (CRC) o Suma de Revisión que está siendo empleada. El valor del Tipo de Detección de Error de 0 = CRC_32 con un campo de señales MPT incluido en el cálculo CRC, generalmente es utilizado por todos los fabricantes.
Existen cuatro diferentes tipos de paquetes MPT. Estos son determinados por cuatro posibles combinaciones que resultan de las señales SOF y EOF que están siendo ajustados ya sea a 0 ó 1. El campo SOF es un campo de 1-bit. Cuando se ajusta a "1", indica que el inicio del Cuadro MPT ocurre en este paquete MPT. Cuando este campo se ajusta a "0", el paquete MPT no contiene el Encabezado del Cuadro MPT. El campo EOF normalmente tiene un campo de 1-bit; cuando se ajusta a "1", indica que la finalización de un Cuadro MPT ocurre en este paquete MPT. Cuando se ajusta a "0", el paquete MPT no contiene la Estela del Cuadro MPT. Los paquetes MPT son transmitidos en el orden en el que deben ser reensamblados. Generalmente no se permite transmitir los paquetes fuera de orden. Los paquetes MPT son multiplexados dentro de un Cuadro MPT. Esto es, una vez que se ajusta un bit SOF, todos los paquetes MPT subsecuentes en el SCID deben pertenecer al mismo Cuadro MPT, en orden. Los mecanismos de Detección de Error son por cuadro, ya sea si un cuadro completo debe ser recibido intacto o el cuadro completo debe ser descartado. Por ejemplo, si se caen los paquetes debido al transporte, desvanecimiento de lluvia, o cualquier razón, entonces todo el cuadro debe ser caído . La Estación de Transmisión 15 recibe un paquete de suministro de Ampliación de Software ("Archivo de Cargas") 230 procedente del fabricante del IRD. Se suministra a la Estación 15 como un archivo. El archivo consiste en un registro de encabezado seguido por el bloque de anuncio en uno o más bloques de datos. Cada bloque de datos debe estar garantizado para iniciar al comienzo de un cuadro MPT. Todo el archivo debe ser transmitido una o más veces durante una sesión de descarga. El formato de Archivo de Carga consiste en tres secciones: 1) Encabezado 240, 2) Bloque de Anuncio Privado 250 3) Bloque de Datos 260, mostrados en la figura 6. El propósito del Encabezado 240 es permitir que la Estación 15 tenga la capacidad de leer y comprender para lo que es un archivo en particular. Esto se utiliza principalmente para propósitos de administración y mantenimiento de archivos. Cada uno de los registros debe ser delimitado con un carácter de alimentación de línea. En la figura 7, se ilustra el formato del Encabezado 240. El formato de la estructura de datos del Encabezado comprende un Nombre de Archivo 270 que representa un campo de longitud variable que identifica el nombre del archivo de carga. El bloque del Fabricante 280 representa un campo de longitud variable que identifica el fabricante del IRD para la ampliación del software contenida en este archivo de carga. Otros campos son el campo de Modelo IRD 290, un campo de longitud variable que describe el modelo IRD para la ampliación del software en este archivo de carga, un campo de Versión de Descarga 300 que describe la versión de la ampliación del software contenida en el archivo de carga, el campo de Descripción de Archivo 310, el cual es un campo de texto de descripción de longitud variable para la ampliación de software contenida en este archivo de carga, un campo de Conteo de Bloque de Datos 320 que contiene hasta 10 caracteres que indica el número de bloques de datos contenidos en este archivo de carga, y el campo de Longitud de Archivo 330, que representa hasta 10 caracteres que indican el número de bytes para todos los campos en el archivo de actualización después del campo de Longitud de Archivo .
La figura 8, ilustra el formato del Bloque de Anuncio Privado 250. El campo de la Longitud de Información Privada 200, descrito anteriormente como parte de los campos de comando público 70, es un campo de 1-byte que indica el número de bytes en el Campo de Datos de Información Privada 210. La parte de Datos de Información Privada es una estructura de longitud variable preferentemente de no más de 62 bytes, que especifica los parámetros de ampliación del software privados para el fabricante identificados por el ID del Fabricante. La figura 9, muestra la estructura de formato del Bloque de Datos 260, el cual incluye un campo de Patrón Sincronizado 340 que debe ser ajustado a 0x55aacc55 para que signifique el comienzo de un bloque de datos, para facilitar el empaquetado de datos en un enlace ascendente. El bloque de Conteo de Bytes 350 es un campo de 4-bytes que indica el número de bytes de los Datos de Ampliación del Software. El campo de Datos de Ampliación del Software 360 es una estructura variable que contiene los datos de ampliación de software real, tal como es definido por el fabricante del IRD. Cada bloque de datos 260 debe ser utilizado para señalar puntos en la descarga que deben ser alineados a un Cuadro MPT. Se requiere al menos un bloque de datos. El fabricante del IRD puede colocar tanto como se requiera en el archivo de datos para cumplir con sus requerimientos de empaquetado. La parte de Datos 360 en cada bloque de datos 260, debe comenzar alineada en un Cuadro MPT inmediatamente después del campo de la ID de Sesión 130. El Patrón Sincronizado 340 y el conteo de Bytes 350 no son transmitidos, aunque son meramente enviados a la Estación de Transmisión 15. La señal SOF debe ser ajustada y la señal EOF debe ser despejada. Todos los paquetes MPT subsecuentes en el cuadro, excepto el último, deben tener despejadas tanto las señales SOF como EOF. El último paquete debe ser nulificado si los datos restantes en el bloque de datos, no llenan todo el paquete y se debe ajustar la señal EOF. La figura 10, ilustra las condiciones en las cuales el IRD debe aceptar un comando de ampliación de software y programar una ampliación. Si el IRD rechaza el comando de ampliación del software, entonces no se debe realizar un procesamiento adicional para la ampliación. Si el IRD acepta el comando de ampliación del software, entonces se debe programar un caso de ampliación en el tiempo indicado. Los pasos de la figura 8, son reproducidos a continuación: En caso de (ID del Fabricante 90 no igual al ID del Fabricante del IRD 280) Rechazo 370 En caso de (Código de Comando 100 no igual al comando de actualización del software) Comando de manejo diferente 380 En caso de (Versión de Comando 110 no igual a 0 ó a que el IRD 40 pueda manejar) Rechazo 370 En caso de (ID de la Red 150 no soportada) Rechazo 370 En caso de (Urgencia 120 igual a 0) Rechazo de cualquiera ampliaciones previamente programadas con los mismos parámetros 390 (ID de sesión) ADEMÁS Programa de Actualización del Software 400 La programación de ampliación está basada en el campo de Urgencia 120. la primera implementación de la capacidad de ampliación del software debe incorporar únicamente los valores de Urgencia ciertos tales como, por ejemplo, 0, 2, 100, 101, y 255. El anuncio debe ser ignorado si el valor de Urgencia, es diferente a O, 2, 100, 101, ó 255. El fabricante del IRD debe permitir flexibilidad para incorporar graduaciones de urgencia en ampliaciones futuras. El IRD no debe exhibir un desempeño anormal si el campo de Urgencia está definido en forma incorrecta diferente a 0, 2, 100, 101, y 255. Los siguientes, son ejemplos de valores de Urgencia y sus instrucciones correspondientes: 0 el IRD nunca es ampliado para el ID de Sesión 130 identificado en el anuncio 60 (utilizado para cancelar comandos de ampliación de software previos ) . 2 ampliación opcional: Si el IRD está en estado de espera, se lleva a cabo la ampliación del software. El IRD no es encendido para desplegar el OSD. Si por el contrario, el IRD está encendido, se despliega un texto en pantalla permitiendo al usuario retrasar la ampliación del software. Se despliega el OSD 2 minutos antes de la recepción de la ampliación del software. Se muestra la ampliación del retardo si está activo el Pago Por Evento (PPV) o un cronómetro programado, o si existe un conflicto entre la ampliación y un PPV o si está determinado un cronómetro programado o si una aplicación interactiva no sede el control del IRD dentro del tiempo de duración de la sesión. 100 auto-ampliación (Opcional): Si se determina un anuncio valido y el campo de Urgencia 120 se ajusta a un valor de 100, el IRD no debe considerar el tiempo de inicio y debe desplegar OSD durante 2 minutos antes de la recepción de la ampliación del software si el IRD está encendido. Si el IRD está en estado de espera, se debe llevar a cabo la ampliación del software en forma inmediata. No se debe encender el IRD para desplegar el OSD. Si el IRD está encendido, se despliega un texto en pantalla que permita al usuario retrasar la ampliación del software. Se retrasa la ampliación si el PPV se está mostrando o está activo un cronómetro programado o si se determina un conflicto entre la ampliación y un PPV o un cronómetro programado o si una aplicación interactiva no sede el control del IRD dentro del tiempo de duración de la sesión. 101 auto-ampliación (Obligatoria) : Si se determina un anuncio válido y se ajusta un campo de Urgencia 120 a un valor de 101, el IRD no debe considerar el tiempo de inicio y debe desplegar OSD durante 2 minutos antes de la recepción de la ampliación del software si el IRD está encendido. Si el IRD está en tiempo de espera, se debe llevar a cabo la ampliación del software. No se debe encender el IRD para desplegar el OSD. No se le debe dar la opción al usuario de retrasar la ampliación del software pendiente. La ampliación del software debe ocurrir aún si se está mostrando un PPV o si un cronómetro programado está activo o si existe un conflicto entre la ampliación y un PPV o si se determina un cronómetro programado. En el caso en donde una aplicación interactiva está en control del IRD y no sede el control del IRD dentro del tiempo de duración de la sesión, se debe realizar un solo intento para llevar a cabo la ampliación del software por parte del IRD al momento de la salida de la aplicación interactiva. 255 ampliación obligatoria: Si el IRD está en estado de espera, se debe realizar la ampliación del software. No se debe encender el IRD para desplegar el OSD. El usuario debe de ser notificado antes de iniciar la ampliación si el IRD está encendido. No se le debe proporcionar al usuario la opción de retrasar la ampliación del software pendiente cuando el campo de Urgencia está ajustado a 255. La ampliación del software debe ocurrir aún si se está mostrando un PPV o está activo un cronómetro programado. Se debe desplegar OSD 2 minutos antes de la recepción de la ampliación del software. El IRD debe comenzar a recibir la imagen de ampliación en el Tiempo de Inicio anunciado. Una vez programado, el IRD 40 intenta la ampliación en cada oportunidad hasta que la descarga tiene éxito, si alcanza el valor de umbral del número de intentos fallados, o hasta que se completa la duración de la sesión. En el caso en donde una aplicación interactiva está en control del IRD y no sede el control del IRD dentro del tiempo de duración de la sesión, se debe realizar un solo intento para llevar a cabo la ampliación del software por parte del IRD al momento de la salida de la aplicación interactiva. La presente invención ha sido mostrada y descrita en lo que se considera como la modalidad más práctica y preferida. Sin embargo, se reconoce que se pueden realizar cambios a la presente invención dentro del alcance de la misma, y que surgirán modificaciones obvias para los expertos en la técnica.

Claims (12)

  1. NOVEDAD DE LA INVENCIÓN Habiendo descrito la presente invención, se considera como novedad y por lo tanto, se reclama como propiedad lo contenido en las siguientes: REIVINDICACIONES 1.- Un método para generar en forma automática un comando de descarga de software para ampliar IRDs en una red de comunicación a base de satélite que comprende los pasos de: obtener el código de ampliación IRD y la información privada IRD para un fabricante del IRD; generar un archivo que contiene la información privada del fabricante IRD y un código de ampliación IRD formateado; transmitir el código de ampliación IRD formateado a un centro de transmisión; ingresar parámetros de ampliación IRD; seleccionar un IRD objetivo o un lugar geográfico objetivo que contiene IRDs, que son para recibir el código de ampliación; generar un comando de descarga de software utilizando una sola plataforma de software, incluyendo el comando de descarga de software información del IRD objetivo formateada; crear un archivo de lote que incluye el comando de descarga del software y el código de ampliación IRD formateado; y transmitir los contenidos del archivo de lotes en una transmisión de enlace ascendente por satélite tradicional .
  2. 2.- Un método para proporcionar datos de ampliación de software a un receptor en un sistema de transmisión por satélite, en donde el método comprende los pasos de: notificar a un receptor de transmisión cuando está disponible una ampliación de software; determinar la urgencia de la ampliación del software para el receptor de transmisión; programar una sesión de ampliación del software para el receptor de transmisión, comprendiendo la sesión de software una o más transmisiones de datos de ampliación de software, y transmitir en forma periódica paquetes de datos que contienen datos de ampliación del software para la sesión de ampliación del software programada, al receptor de transmisión.
  3. 3.- El método de conformidad con la reivindicación 2, en donde el paso de notificar al receptor de transmisión cuando la ampliación del software está disponible, está comprendida del paso de proporcionar un mensaje de anuncio de ampliación transmitible en el paquete de datos.
  4. 4.- El método de conformidad con la reivindicación 3, en donde el paso de programar la sesión de ampliación del software comprende los pasos de: almacenar uno o más parámetros de identificación privada dentro de un dispositivo de almacenamiento de memoria localizado en cada receptor de transmisión, proporcionando los parámetros de identificación privada por el fabricante del IRD; transmitir, dentro de los paquetes de datos, parámetros de identificación pública, proporcionando los parámetros de identificación pública por un abastecedor de transmisión de televisión por satélite; y determinar si los parámetros de identificación pública transmitidos son iguales a los parámetros de identificación privada almacenados, y si no es igual, cancelar la sesión de ampliación de software.
  5. 5.- El método de conformidad con la reivindicación 2, que comprende además los pasos de determinar si la sesión de ampliación del software está comprendida de más de una transmisión, y si es así, almacenar en forma secuencial, en un medio de almacenamiento de memoria, los datos de ampliación del software transmitidos en forma subsecuente correspondientes a la sesión de ampliación del software programado.
  6. 6.- Un sistema para proporcionar datos de ampliación de software a un receptor en un sistema de transmisión por satélite que comprende: uno o más aparatos periféricos; y un receptor de transmisión conectado en forma eléctrica a uno o más aparatos periféricos para notificar a un receptor de transmisión cuando está disponible una ampliación de software, teniendo la capacidad el receptor de transmisión de recibir la notificación de los paquetes de datos transmitidos que contienen una ampliación de software del receptor de transmisión, en donde los paquetes de datos transmitidos incluyen instrucciones legibles en computadora para determinar la urgencia de la ampliación del software del receptor de transmisión y la programación de una sesión de ampliación del software para el receptor de transmisión, comprendiendo la sesión del software, una o más transmisiones de datos de ampliación de software, en donde los paquetes de datos que contienen los datos de ampliación del software para la sesión de ampliación del software programado, son transmitidos en forma periódica al receptor de transmisión.
  7. 7.- El sistema de conformidad con la reivindicación 6, en donde el receptor de transmisión, es notificado de la ampliación del software recibiendo un mensaje de anuncio de ampliación, transmitido por medio de los paquetes de datos .
  8. 8.- El sistema de conformidad con la reivindicación 6, en donde las instrucciones legibles en computadora comprenden: uno o más parámetros de identificación privada dentro de un dispositivo de almacenamiento de memoria localizado en cada receptor de transmisión, proporcionando los parámetros de identificación privada por el fabricante del IRD; y parámetros de identificación pública, dentro de los paquetes de datos, proporcionando los parámetros de identificación pública por un abastecedor de transmisión de televisión por satélite, en donde si los parámetros de identificación pública transmitidos no son iguales a los parámetros de identificación privada almacenados se cancela la sesión de ampliación del software.
  9. 9.- Un programa de computadora almacenado en un medio legible en computadora, que representa las instrucciones para llevar a cabo un método para proporcionar datos de ampliación de software a un receptor en un sistema de transmisión satelital, que comprende los pasos de: notificar al receptor de transmisión cuando está disponible una ampliación del software; determinar la urgencia de la ampliación del software para el receptor de transmisión; programar una sesión de ampliación de software para el receptor de transmisión, comprendiendo la sesión del software una o más transmisiones de datos de ampliación de software; y transmitir en forma periódica paquetes de datos que contienen datos de ampliación del software para la sesión de ampliación de software programada, al receptor de transmisión.
  10. 10.- El programa de conformidad con la reivindicación 9, en donde el paso de notificar al receptor de transmisión cuando está disponible la ampliación del software, está comprendido de un mensaje de anuncio de ampliación, transmitido en los paquetes de datos.
  11. 11.- El programa de conformidad con la reivindicación 10, en donde el paso de programar la sesión de ampliación del software comprende los pasos de : almacenar uno o más parámetros de identificación privada dentro de un dispositivo de almacenamiento de memoria localizado en cada receptor de transmisión, proporcionando los parámetros de identificación privada por el fabricante del IRD; transmitir, dentro de los paquetes de datos, parámetros de identificación pública, proporcionando los parámetros de identificación pública por un abastecedor de transmisión de televisión por satélite; y determinar si los parámetros de identificación pública transmitidos son iguales a los parámetros de identificación privada almacenada, y si no son iguales, cancelar la sesión de ampliación del software .
  12. 12.- El programa de conformidad con la reivindicación 10, que comprende además los pasos de determinar si la sesión de ampliación del software está comprendida además de una transmisión, y si es así, almacenar en forma secuencial, en un medio de almacenamiento de memoria, los datos de ampliación del software transmitidos en forma subsecuente correspondientes a la sesión de ampliación del software programado . RESUMEN Un sistema y método automático (10), para procesar previamente parámetros de actualización de software (51), para transmitir a IRDs (40), por medio de transmisiones tradicionales sin la necesidad de intervención manual repetida. Generalmente, la presente invención es un sistema (10), que genera en forma automática comandos de descarga de software que contienen todos los parámetros necesarios (51), que un IRD (40), en una red de comunicación por satélite requiere para completar una descarga de software, tal como, tiempo, frecuencia, y el lugar del software dentro de la corriente de datos entre otros parámetros. La invención (10), proporciona los datos de ampliación del software (51) que serán transmitidos en paquetes de datos que comprenden una transmisión satelital. La información transmitida incluye, la información de identificación del receptor de transmisión objetivo (IRD) y la información de ampliación del software (51), para determinar si el IRD utilizado como objetivo (40), es de hecho el receptor correcto de los datos de ampliación de software (51), y si el IRD (40) requiere una ampliación del software. La urgencia de la ampliación, está determinada para ft ?I permitir ampliaciones obligatorias, opcionales, diferidas a un período de tiempo posterior, o canceladas. La información de ampliación es transmitida a través de transmisiones por satélite típicas (20) y ocurren en forma periódica sin intervención humana, dependiendo de la versión de ampliación corriente de IRD (40) . O7j/tl/
MXPA02001441A 2001-02-12 2002-02-11 Generacion automatizada de paquetes condicionales de acceso para la ampliacion del ird via transferencia directa del software por radiofrecuencia en sistemas de television via satelite. MXPA02001441A (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US26848001P 2001-02-12 2001-02-12
US09/948,976 US20020152467A1 (en) 2001-02-12 2001-09-07 Automated generation of conditional access packets for IRD upgrades via radio frequency software download in satellite television systems

Publications (1)

Publication Number Publication Date
MXPA02001441A true MXPA02001441A (es) 2002-11-29

Family

ID=26953116

Family Applications (1)

Application Number Title Priority Date Filing Date
MXPA02001441A MXPA02001441A (es) 2001-02-12 2002-02-11 Generacion automatizada de paquetes condicionales de acceso para la ampliacion del ird via transferencia directa del software por radiofrecuencia en sistemas de television via satelite.

Country Status (4)

Country Link
US (1) US20020152467A1 (es)
AR (1) AR035616A1 (es)
BR (1) BRPI0201818B1 (es)
MX (1) MXPA02001441A (es)

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7954127B2 (en) 2002-09-25 2011-05-31 The Directv Group, Inc. Direct broadcast signal distribution methods
US7263648B2 (en) * 2003-01-24 2007-08-28 Wegener Communications, Inc. Apparatus and method for accommodating loss of signal
US7032235B2 (en) * 2003-03-12 2006-04-18 Wegener Communications, Inc. Recasting DVB video system to recast digital broadcasts
US7171606B2 (en) * 2003-03-25 2007-01-30 Wegener Communications, Inc. Software download control system, apparatus and method
US7296204B2 (en) * 2003-05-30 2007-11-13 Wegener Communications, Inc. Error correction apparatus and method
US7206411B2 (en) 2003-06-25 2007-04-17 Wegener Communications, Inc. Rapid decryption of data by key synchronization and indexing
FR2860677B1 (fr) * 2003-10-07 2006-05-19 Sagem Procede de controle d'un parc de decodeurs
US7542757B2 (en) * 2003-11-20 2009-06-02 Agere Systems Inc. Method, system, and computer program product for over-the-air download to satellite radio
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
US8782711B2 (en) * 2004-03-31 2014-07-15 The Directv Group, Inc. Satellite television network and near real-time method for downloading and verifying a subscriber remote record request
GB0408459D0 (en) * 2004-04-15 2004-05-19 Imagination Tech Ltd Digital radio broadcasting systems and receivers
KR100643274B1 (ko) * 2004-06-15 2006-11-10 삼성전자주식회사 데이터의 다운로드 진행상태를 디스플레이 하는 장치 및그 방법
WO2006021829A1 (en) * 2004-08-26 2006-03-02 Ian Morrison Melamed Method and system for providing secure software updates via satellite transmission systems
GB0422529D0 (en) * 2004-10-11 2004-11-10 Invacom Ltd Apparatus for selected provision of linear and/or circular polarity signals
WO2006066451A1 (fr) * 2004-12-21 2006-06-29 Zte Corporation Procede servant a optimiser un logiciel de terminal video de teleconference
DE102005015402A1 (de) * 2005-02-02 2006-08-03 Rohde & Schwarz Sit Gmbh Datencontainer und zugehöriges Verfahren zur Übertragung von sicherheitsrelevanten Nutzdaten an Geräte bzw. Systeme
US9270732B2 (en) * 2005-03-14 2016-02-23 Rhapsody International Inc. System and method for automatically uploading updates
US7900230B2 (en) 2005-04-01 2011-03-01 The Directv Group, Inc. Intelligent two-way switching network
US8621525B2 (en) 2005-04-01 2013-12-31 The Directv Group, Inc. Signal injection via power supply
US8024759B2 (en) 2005-04-01 2011-09-20 The Directv Group, Inc. Backwards-compatible frequency translation module for satellite video delivery
US7950038B2 (en) 2005-04-01 2011-05-24 The Directv Group, Inc. Transponder tuning and mapping
US8549565B2 (en) 2005-04-01 2013-10-01 The Directv Group, Inc. Power balancing signal combiner
US7958531B2 (en) 2005-04-01 2011-06-07 The Directv Group, Inc. Automatic level control for incoming signals of different signal strengths
US7987486B2 (en) 2005-04-01 2011-07-26 The Directv Group, Inc. System architecture for control and signal distribution on coaxial cable
US7945932B2 (en) 2005-04-01 2011-05-17 The Directv Group, Inc. Narrow bandwidth signal delivery system
JP3112392U (ja) * 2005-05-10 2005-08-11 船井電機株式会社 Ｈｄｔｖ
US8789115B2 (en) 2005-09-02 2014-07-22 The Directv Group, Inc. Frequency translation module discovery and configuration
US7937732B2 (en) * 2005-09-02 2011-05-03 The Directv Group, Inc. Network fraud prevention via registration and verification
US20080016535A1 (en) * 2005-09-02 2008-01-17 The Directv Group, Inc. Frequency shift key control in video delivery systems
US8019275B2 (en) 2005-10-12 2011-09-13 The Directv Group, Inc. Band upconverter approach to KA/KU signal distribution
US7991348B2 (en) * 2005-10-12 2011-08-02 The Directv Group, Inc. Triple band combining approach to satellite signal distribution
US20090210911A1 (en) * 2005-10-26 2009-08-20 Thomson Licensing System And Method For Advertising The Availability Of A Software Upgrade
KR100751146B1 (ko) * 2005-12-05 2007-08-22 엘지전자 주식회사 Ｏａｄ 채널 변환 방법 및 이를 이용하는 방송 수신기
FR2903779B1 (fr) * 2006-07-11 2008-08-22 Alcatel Sa Dispositif de generation de messages de description de format de futurs messages relatifs a un systeme de navigation par satellites
KR20080009811A (ko) * 2006-07-25 2008-01-30 삼성전자주식회사 문자메시지를 이용한 ｏｔａ정보 제공장치 및 방법
EP2064885A4 (en) * 2006-09-01 2011-12-07 Bce Inc METHOD, SYSTEM AND DEVICE FOR TRANSMITTING PERSONALIZED CONTENTS TO A VIEWER
KR100782856B1 (ko) * 2006-09-26 2007-12-06 삼성전자주식회사 디지털 방송 수신기의 소프트웨어 업그레이드 방법 및 장치
US8719875B2 (en) 2006-11-06 2014-05-06 The Directv Group, Inc. Satellite television IP bitstream generator receiving unit
US8595360B2 (en) * 2006-11-07 2013-11-26 Motorola Mobility Llc Method, system and apparatus for distributing digital information including digital rights management information to a plurality of devices
US8712318B2 (en) 2007-05-29 2014-04-29 The Directv Group, Inc. Integrated multi-sat LNB and frequency translation module
CN101415173B (zh) * 2007-08-09 2013-12-18 华为技术有限公司 寻找拜访服务提供商的方法及终端、服务器
US8238813B1 (en) 2007-08-20 2012-08-07 The Directv Group, Inc. Computationally efficient design for broadcast satellite single wire and/or direct demod interface
KR100841434B1 (ko) * 2007-09-03 2008-06-25 삼성전자주식회사 영상표시장치 및 그의 ｅｄｉｄ 정보 변경 방법
KR20090024885A (ko) * 2007-09-05 2009-03-10 엘지전자 주식회사 영상표시기기에서 소프트웨어 업데이트 방법
US9942618B2 (en) 2007-10-31 2018-04-10 The Directv Group, Inc. SMATV headend using IP transport stream input and method for operating the same
EP2356798A1 (en) * 2008-11-10 2011-08-17 The DirecTV Group, Inc. Method and apparatus for managing software downloads in a broadcast communication system
BRPI1006912A2 (pt) 2009-01-06 2016-02-16 Directv Group Inc estimação de deriva de frequência para unidade externa de baixo custo
WO2010080087A1 (en) * 2009-01-12 2010-07-15 Thomson Licensing Systems and methods for interrupting upgrades of content distribution systems
JP5332854B2 (ja) * 2009-04-20 2013-11-06 ソニー株式会社 無線送信機、無線送信方法、無線受信機および無線受信方法
US8484672B2 (en) * 2010-01-07 2013-07-09 Shenzhen Tcl New Technology Ltd. Method and device for updating regional rating table
EP2434398A1 (en) * 2010-09-15 2012-03-28 ABB Technology AG A low or medium voltage electric power distribution network.
US10021509B2 (en) 2016-03-25 2018-07-10 At&T Mobility Ii Llc Methods and apparatus to provide an update via a satellite connection
US10827210B1 (en) * 2016-12-08 2020-11-03 CSC Holdings, LLC Systems and methods for signaling host devices via a broadcast channel with grouping filters
CN110209411B (zh) * 2019-04-25 2022-12-27 宁波三星医疗电气股份有限公司 一种计量自动化终端程序升级自适应方法
CN112003643B (zh) * 2020-08-13 2022-04-19 航天科工空间工程发展有限公司 一种用于卫星在轨软件重构的数据上注方法
CN114980035B (zh) * 2022-05-11 2023-03-17 军事科学院系统工程研究院网络信息研究所 一种卫星通信应用服务保障系统及实现方法

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0503545B1 (en) * 1991-03-08 1997-06-11 Matsushita Electric Industrial Co., Ltd. Data transfer device
US5440632A (en) * 1992-12-02 1995-08-08 Scientific-Atlanta, Inc. Reprogrammable subscriber terminal
US5563648A (en) * 1994-04-28 1996-10-08 Thomson Consumer Electronics, Inc. Method for controlling execution of an audio video interactive program
US5819034A (en) * 1994-04-28 1998-10-06 Thomson Consumer Electronics, Inc. Apparatus for transmitting and receiving executable applications as for a multimedia system
US5768539A (en) * 1994-05-27 1998-06-16 Bell Atlantic Network Services, Inc. Downloading applications software through a broadcast channel
US5666293A (en) * 1994-05-27 1997-09-09 Bell Atlantic Network Services, Inc. Downloading operating system software through a broadcast channel
US6976266B1 (en) * 1994-12-23 2005-12-13 Thomson Licensing S.A. Apparatus and method for processing a program guide in a digital video system
JP3372004B2 (ja) * 1995-03-31 2003-01-27 ソニー株式会社 電子番組ガイド装置、電子番組ガイドシステム、および電子番組ガイド方法
US5951639A (en) * 1996-02-14 1999-09-14 Powertv, Inc. Multicast downloading of software and data modules and their compatibility requirements
US6172972B1 (en) * 1996-05-28 2001-01-09 Microsoft Corporation Multi-packet transport structure and method for sending network data over satellite network
US5778390A (en) * 1996-06-07 1998-07-07 Electronic Data Systems Corporation Method and systems for creating duplicating, and archiving database files
JP2001514776A (ja) * 1997-02-27 2001-09-11 シーベル システムズ，インコーポレイティド ローカルな修正を組み込むソフトウェア配布の連続レベル移送の方法
US5805155A (en) * 1997-04-15 1998-09-08 Time Warner Entertainment Co. L.P. Time Warner Cable Virtual assets in an interactive television cable system
US6049830A (en) * 1997-05-13 2000-04-11 Sony Corporation Peripheral software download of a broadcast receiver
US5936667A (en) * 1997-05-13 1999-08-10 Sony Corporation System and method for testing and updating stored content of a remote transmitter for an entertainment system
US6202207B1 (en) * 1998-01-28 2001-03-13 International Business Machines Corporation Method and a mechanism for synchronized updating of interoperating software
JP4016359B2 (ja) * 1998-03-24 2007-12-05 ソニー株式会社 受信装置及びプログラム書き換え方法
US6470496B1 (en) * 1998-08-03 2002-10-22 Matsushita Electric Industrial Co., Ltd. Control program downloading method for replacing control program in digital broadcast receiving apparatus with new control program sent from digital broadcast transmitting apparatus
JP3950589B2 (ja) * 1998-08-28 2007-08-01 キヤノン株式会社 情報処理装置、プログラム更新方法および記憶媒体
US6393585B1 (en) * 1998-12-23 2002-05-21 Scientific-Atlanta, Inc. Method and apparatus for restoring operating systems in a set-top box environment
US6427236B1 (en) * 1999-03-03 2002-07-30 Microsoft Corporation Method for installing a patch based on patch criticality and software execution format
US6247238B1 (en) * 1999-04-15 2001-06-19 Greg Harvey Laser marking device
US6718374B1 (en) * 1999-04-21 2004-04-06 General Instrument Corporation Method and system for identifying and downloading appropriate software or formware specific to a particular model of set-top box in a cable television system
US6996627B1 (en) * 1999-05-25 2006-02-07 Realnetworks, Inc. System and method for providing update information
US6904611B1 (en) * 1999-09-03 2005-06-07 General Instrument Corporation Method and system for directing the download of software and firmware objects over a network such as a cable television system
US7069578B1 (en) * 2000-02-04 2006-06-27 Scientific-Atlanta, Inc. Settop cable television control device and method including bootloader software and code version table for maintaining and updating settop receiver operating system software
US20040139430A1 (en) * 2000-12-20 2004-07-15 Eatough David A. Multivendor package management

Also Published As

Publication number Publication date
AR035616A1 (es) 2004-06-16
BRPI0201818B1 (pt) 2016-04-19
BR0201818A (pt) 2003-06-10
US20020152467A1 (en) 2002-10-17

Similar Documents

Publication Publication Date Title
MXPA02001441A (es) Generacion automatizada de paquetes condicionales de acceso para la ampliacion del ird via transferencia directa del software por radiofrecuencia en sistemas de television via satelite.
US7051325B2 (en) Apparatus and method for upgrading software
US6266810B1 (en) Remote program downloading system and apparatus
US6658231B2 (en) Receiver for user-demand information and entertainment system using wide area digital broadcast
US8528038B2 (en) Process for downloading data preceded by announcement signals
US5699275A (en) System and method for remote patching of operating code located in a mobile unit
US7176808B1 (en) System and method for updating a network of remote sensors
US7673297B1 (en) Automatic software update detection and flexible installer for set-top boxes
US6658062B1 (en) User-demand information and entertainment system using wide area digital broadcast
CN1653819B (zh) 提供媒体内容的系统和方法
CN1728699B (zh) 数据广播的差分更新
HU230537B1 (hu) MPEG elkülönített táblázat, hozzá való szintaktikai elemző, ilyen elemzőt tartalmazó vevő és dekódoló berendezés, és berendezés egy MPEG elkülönített táblázat összeállítására
JPH10171664A (ja) ソフトウエアの更新方法、およびビデオレシーバ
JPH1198477A (ja) ソフトウェアダウンロードシステム
US20060041509A1 (en) Broadcasting of software packages
JP3261399B2 (ja) リモートメンテナンス方法およびリモートメンテナンス装置
JP4376321B2 (ja) 伝送データ・ストリームからデータ・セクションを抽出する方法
KR20010030926A (ko) 데이터를 다운로딩하는 방법
JPH11136658A (ja) 転送機能付き双方向ｔｖ受信機、およびそのための端末装置
CN100367244C (zh) 数据收发系统及其方法
EP1634456A1 (en) Interactive television system
ZA200703170B (en) Methods and devices for transmitting data to a mobile data processing unit
JPH11194943A (ja) 送信装置および受信装置
US8799433B2 (en) Method and apparatus for upgrading software of digital broadcasting receiver
WO1998043437A1 (en) Method of and apparatus for transmitting data for interactive tv applications

Legal Events

Date Code Title Description
FG Grant or registration