FR2758430A1 - Procede et systeme de telechargement de donnees numeriques par satellite - Google Patents

Abstract

Il s'agit d'un procédé et d'un système de téléchargement de données numériques par satellite dans un dispositif terminal (36) pour utilisateur. On émet intervalles réguliers des données correspondant à un programme de chargement d'une mémoire Flash (75) intégrée au dispositif terminal. Le programme à jour comprend une mise à jour des programmes drivers (85), du système d'exploitation du dispositif terminal (82) et d'au moins un programme d'application spécifique (88). On émet les données du programme à jour avec une identification du constructeur du décodeur utilisé, du dispositif terminal utilisé, du numéro de version dudit programme à jour et un sous-champ réservé à la différenciation entre certains types d'utilisateurs. Lorsque le terminal est activé, on teste régulièrement si la version de programme de mise à jour reçue est différente de celle présente dans la mémoire Flash (75), et, lorsque la comparaison montre une différence, on propose à l'utilisateur une mise à jour de ladite mémoire Flash (75).par.

Description

PROCEDE ET SYSTEME DE TELECHARGEMENT DE DONNEES
NUMERIQUES PAR SATELLITE
La présente invention concerne un procédé de téléchargement de données numériques retransmises par satellite, dans au moins un dispositif terminal muni d'un décodeur et propre à être connecté à un appareil récepteur de télévision.

Elle concerne également un système mettant en oeuvre un tel procédé.

L'invention trouve une application particulièrement importante, bien que non exclusive, dans le domaine de la transmission de bouquets de programmes de télévision et/ou de radios en numérique, utilisant des satellites géostationnaires de rediffusion vers des antennes de réception directe par des utilisateurs téléspectateurs grand public et/ou appartenant à des réseaux de télévision par câble.

L'invention est particulièrement, mais non limitativement, adaptée à la retransmission de programmes télévisés mettant en oeuvre le standard européen DVB (initiales anglo-saxonnes de "Digital
Video Broadcasting") utilisant la norme de compression MPEG-2 élaborée par le Groupe d'experts
MPEG (initiales anylo-saxonnes de "Motion Pictures
Experts Group") formé en 1990 par L'TAO
("International Standard Organization").

A partir de la fin des années 1980, le développement d'algorithmes de compression vidéo efficace a eti effet permis de réduire de façon importante le dépit nécessaire à la retransmission d'images, ramenant celui-ci à des valeurs acceptables pour une transmission par satellite.

Simultanément une intégration des circuits de compression et des mémoires a permis de réduire les coûts de réalisation de tels circuits.

En 1994, les premières émissions numériques à destination du grand public ont ainsi pu voir le jour aux Etats-Unis avec le projet connu sous le dénomination "Direc TV".

En Europe, le Groupe ELG (initiales anglo-saxonnes de "European Launching Group") a de son côté donné naissance au standard DVB, permettant le développement rapide de la télévision numérique.

Les systèmes proposés à ce jour, du type Direct
TV, ou encore tels que ceux suggérés par la norme
DVB, présentent cependant des inconvénients.

Ces systèmes sont en effet, et notamment, basés sur une conception propriétaire des dispositifs terminaux, conçus pour être propres à chacun des fournisseurs de bouquet numérique, ces derniers ne souhaitant pas favoriser la possibilité pour l'utilisateur final de s'adresser à un fournisseur concurrent en utilisant un même dispositif terminal.

La présente invention vise à fournir un procédé et un système répondant mieux que ceux antérieurement connus aux exigellces de la pratique, notamment en ce qu'elle autorise l'utilisation de dispositifs terminaux ni-ilversels non affectés a priori à iin fournisseur d bouquets ou de service spécifique.

De plus l'invention permet une tus à jour immédiate à leurs derIzieres version, des services et logiciels mis on oeuvre sur le terminal par le fournisseur de houquets, autorisant ainsi un service amélioré avec une parfaite fiabilité et sans nécesslté d'intervention externe par uri revendeur ou par un opérateur de service de maintenance, ce qui permet également des économies de coûts.

Dans ce but, l'invention propose notamment un procédé de téléchargement de données numériques par satellite, dans au moins un dispositif terminal pour utilisateur, ledit dispositif étant muni d'un décodeur et propre à être connecté à un appareil récepteur de télévision, caractérisé en ce que en même temps que les données correspondant aux signaux de télévision retransmis, on émet à intervalles réguliers des données correspondant à la mise à jour du programme de fonctionnement du dispositif terminal chargé dans une mémoire Flash intégrée au dispositif terminal, dit programme à jour, ledit programme à jour comprenant la mise à jour des programmes de mise en oeuvre des fonctions matérielles du décodeur, dits programmes drivers, du système d'exploitation du dispositif terminal et d'au moins un programme d'application spécifique, on émet les données du programme à jour avec un champ d'identification comportant une identification du constructeur du décodeur utilisé, du dispositif terminal utilisé, du numéro de version dudit programme à jour et un sous-champ réservé à la différenciation entre certains types d'utilisateurs, on active le dispositif terminal en réception par l'inrermédiaire d'une carte à puce préalablement programmée et irlsérée dans le terminal, lorsque le dispositif terminal est activé, on teste régulièrement si le numéro de version du programme à loiii reçu est différent de celui présent dans la mémoire Flash, et, cirque la comparaison montre une différence, on propose à l'utilisateur une mise à jour de ladite mémoire Flash, l'utilisateur pouvant alors soit effectuer, soit différer le téléchargement du programme à jour dans ladite mémoire Flash.

Dans des modes de réalisation avantageux, on a de plus recours à l'une et/ou à l'autre des dispositions suivantes
- en cas de décision de téléchargement par l'utilisateur, on télécharge d'abord le programme à jour dans une mémoire vive ou EEPROM du décodeur, la mise à jour de la mémoire Flash n'étant effectuée que si l'acquisition en mémoire vive ou EEPROM est correcte, à partir de ladite mémoire vive ou EEPROM
- le procédé comporte une étape préalable de test permettant la mise à jour du programme via une ligne série
- le procédé comporte une étape de forçage de la mise à jour par l'utilisateur ;
- lors de la mise sous tension du dispositif terminal, on teste l'intégrité du programme de fonctionnement dudit dispositif terminal présent dans la mémoire Flash et on lance automatiquement le téléchargement du programme à jour en cas de défaut d'intégrité ;
- on sécurise les données transmises correspondantes au programme à jour, de sorte que seules les données transmises par un opérateur autorisé peuvent être téléchargées
- pour sécuriser les données correspondantes au programme à jour, on transmet au décodeu lesdites données sous forme de blocs de données contiguës, à chaque bloc étant .is;ocal une en-t etc respondant à une adresse donnée d Ta mémoire Flash, on décrit les blocs de donnees contiguës à traiter dans un bloc en tête, à chaque bloc de données on associe une signature, les signatures de chacun des blocs de almées décrits dans un bloc en-tête et ant adjointes aud@@ bloc en tête, et on associe audit bloc en-tête une signature à partir de laquelle est calculée une signature chiffrée, transmise avec ledit bloc en-tête
- l'algorithme de chiffrement de la signature du bloc en-tête est un algorithme de type RS, avec une clé privée pour le calcul de la signature chiffrée à partir de la signature non chiffrée, et une clé publique pour le calcul de la signature non chiffrée à partir de la signature chiffrée
- la retransmission des signaux de télévision et le téléchargement mettent en oeuvre la norme européenne DVB à partir de flux de données compressées selon la norme MPEG-2, l'identification d'un service de mise à jour du programme de fonctionnement du dispositif terminal se faisant à partir des données de signalisation du réseau présentes dans les tables PSI et SI, le service de mise à jour étant identifié dans la table NIT, la description du flux qui la porte étant donnée par la table PMT, et l'identification des décodeurs concernés étant donnée par la table SDT.

La signalisation des sigles ci-dessus correspond à celle décrite dans la norme MPEG-2.

L'invention propose également 011 système de téléchargemerlt de données numériques retransmises par satellite, pour utilisateur muni d@ un dispositif terminal comportant un décodeur, mettant en oeuvre le procédé de téléchargement décrit c-dessus.

L'invention sera mieux comprise a ta lecture de la description giii nuit d'un mode cie réalisation donné à titre d'exemple notai limitatif.

La descript ion se réfère aix dessins qui l'accompagnent dans lesquelles
- La figure 1 est un schéma-bloc de la chaîne d'émission/transmission/réception selon la norme DVB utilisée dans le cadre du mode de réalisation de l'invention plus particulièrement décrit ici.

- La figure 2 montre le train de transport MPEG-2 à partir de paquets transports élémentaires PES
(correspondant aux initiales anglo-saxonnes de "Packetized Elementary Stream") utilisant le mode de compression des données mis en oeuvre dans la norme
DVB.

- Les figures 3A et 3B montrent respectivement la constitution d'un paquet transport, et le détail de l'en-tête d'un paquet transport selon la norme DVB.

- La figure 4 montre schématiquement le système mettant en oeuvre le procédé selon l'invention.

- La figure 5 est un schéma-bloc fonctionnel d'un dispositif terminal appartenant au système de la figure 4.

- La figure 6 est un schéma de principe de l'architecture logicielle du dispositif terminal de la figure 5.

- La figure 7 est un schéma de principe illustrant la mise à jour de la mémoire Flash du dispositif terminal par le procédé de téléchargement selon l'invention.

La figure 8 donne un schéma de principe de la sécurisation des transmissions de donnée Tors du téléchargement selon un mode de réalisation de 1 ' invention.

- La figure 9 est un organigramme du procédé de téléchargement selon le mode de réalisation de 1' invention plus particulièrement décrit @c@.

- La figure 10 est t schéma icutrant l'enchaînement de 1 'affichage observé sur le dispositif terminal lors d'un téléchargement selon un mode de réalisation de l'invention.

La figure 1 montre une chaîne 1 d'émission / transmission / réception de signaux de télévision numérique.

Elle comprend une première suite 2 d'étapes correspondant à l'émission, et une deuxième suite 3, symétrique de la suite 2, d'étapes correspondant à la réception de données numériques correspondant à des signaux de télévision retransmis selon le standard
DVB utilisée dans le cadre de l'invention plus particulièrement décrit ici.

Le rôle de la suite 2 d'étapes est de fournir sur un seul canal, par exemple de largeur de bande de 33 MHz à 36 MHz, un multiplex de programmes MPEG-2.

MPEG-2 constitue la norme pour le codage de source du système défini par le standard DVB. Elle comporte trois parties : MPEG-2 System (ISO/IEC 13818-1),
MPEG-2 Video (ISO/IEC 13818-2) et MPEG-2 Audio (ISO/IEC 13818-3).

Dans la suite de la description les sigles utilisés correspondent au standard DVB et à la norme
MPEG-2. Ils sont repris en référence aux initiales en terminologie anglo-saxonne, cette dernière étant alors indiquée entre parenthèses lors de Ta première mention du signal concerné.

Les signaux vidéo et audio des programmes 'i'...' à transmettre vers les téléspectateurs, attaquent autant de codeurs 5, 5'. MPE(3 2, par exemple de l'ordre de quatre à huit par canal selon les paramètres de codage choisis, lesdits coder fournissant en sortie les PES (Packetized Element ary
Stram) 6, 6'... vidéo et audio à 1' enr-oe du multiplexeur 7.

Ces PES sont utilisés par le multiplexeur 7 pour former des paquets transport 8 de 188 octet n qui vont maintenant être détaillés en référence aux figures 2, 3A et 3B, avant de revenir à la description de la figure 1.

Plus précisément, il est donc prévu (Cf. figure 2) un train transport 9 de MPEG-2, destiné à combiner plusieurs programmes ne partageant pas forcément la même horloge système STC à l'intérieur d'un même multiplex.

Ce train transport 9 comprend une suite de PES PES1, PES2.

Chaque PES comporte un en-tête 10.

Bien entendu, les différents PES (vidéo, audio...) formant un programme donné partagent la même horloge système pour permettre le décodage.

Dans l'exemple de la figure 2, PES1 est découpé entre les paquets transport PT1, PT3 et PT4 et PES2 équivaut exactement au paquet PT6.

D'autres paquets transports PT2, PT5, PT7 viennent s'intercaler et correspondent notamment et pour une part au programme à jour téléchargé dans la mémoire
Flash selon l'invention, retransmis en même temps que les signaux de télévision.

Chaque paquet transport PT comprend un en-tête 11 de paquet transport, et des données élémentaires 12, par exemple audio, vidéo, pour un signal de télévision.

Comme chaque paquet transport comporte 188 octets, il existe eri général un champ d'adaptation 13
(Cf. également figure 3A) pour terminer le PES dont la fin doit obligatoirement correspondre avec celle d'un paquet transport.

Un paquet transport pourra eventuellement et par ailleurs n'être constitué que d'un champ d'adaptation de 184 octets.

Pour compléter le description en référence à la norme, on a représenté sur la figure 3B la forme de l'en-tête 11 d'un paquet transport PT.

La figure 3B correspond par ailleurs au tableau ci-après

<tb> <SEP> CHAMP <SEP> DEFINITION <SEP> (COMMENTAIRE) <SEP> NOMBRE
<tb> <SEP> DE <SEP> BITS
<tb> sync~byte <SEP> octet <SEP> de <SEP> synchronisation <SEP> 8
<tb> <SEP> 10000111 <SEP> (47 <SEP> hex)
<tb> ei <SEP> transport~error~indicator <SEP> 1
<tb> <SEP> (indique <SEP> erreur <SEP> détectée <SEP> en
<tb> <SEP> amont)
<tb> pusi <SEP> payloabunit~start~indicator <SEP> 1
<tb> <SEP> (début <SEP> PES <SEP> dans <SEP> le <SEP> paquet)
<tb> tpr <SEP> transport~priority <SEP> (indicateur <SEP> 1
<tb> <SEP> de <SEP> priorité)
<tb> PID <SEP> Packet <SEP> Identifier <SEP> 13
<tb> <SEP> (identification <SEP> du <SEP> paquet)
<tb> scr~flags <SEP> transport~scrambling~flags <SEP> 2
<tb> <SEP> (type <SEP> d'embrouillage <SEP> transport)
<tb> af <SEP> adaptationfield~flag(champ <SEP> 1
<tb> <SEP> d'adaptation <SEP> dans <SEP> le <SEP> paquet)
<tb> pf <SEP> payload~flag <SEP> (données <SEP> utiles <SEP> 1
<tb> <SEP> dans <SEP> le <SEP> paquet)
<tb> cc <SEP> continuity~counter <SEP> (compteur <SEP> 4
<tb> <SEP> continuité <SEP> entre <SEP> tronçons <SEP> PES)
<tb>
Il est maintenant décrit sommairement ci-après l'information spécifique des programmes PSI (Program
Specific Information) de la norme DVB MPEG 2 permettant au décodeur de se retrouver dans le multiplex transport MPEG-2 utilisé dans le mode de réalisation de l'invention plus particulièrement décrit ici.

La PAT (Program Association Table), dont la présence est obligatoire, est transportée par les paquets dont l'indicateur PID (Packet Indentifier) porte le numéro 0 (PID = 0 x 0000).

Son rôle est d'indiquer, pour chaque programme convoyé par le multiplex transport, le lien entre le numéro de programme (de O à 65 535) et le PID des paquets transportant une table PMT (Program Map
Table) indiquant la carte du programme.

Rappelons qu'un programme peut aussi bien ici être un programme de télévision numérisé, qu'un programme véhiculant simplement des données numériques quelconques.

La PAT est toujours transmise en clair, même si tous les programmes sont embrouillés.

La PMT (Program Map Table) est quant à elle présente pour chaque programme présent dans le multiplex.

La PMT indique principalement en clair les PID des trains élémentaires 9 constituant le programme et optionnellement ceux d'autres informations privées relatives au programme qui peuvent, elles, etre embroulllées.

La PMT peut ainsi être transportée par des paquets cie PIL arbitraires définis par l'émetteur dans J a PAT
(saut Ô x 0000 et O x 0001).

La CAT (Conditional Acces Table) concerne les accès conditionnels.

E? Te est transportée par les paquets de
PID = O x 0001 et indique les PID des paquets transportant les EMM (Flltitlement Management Message) pour un cli plusieurs systèmes de contrôle d'accès.

A ces tables, la norme DVB ajoute une information complémentaire DVB-SI (DVB-Service Information) permettant au récepteur de se configurer automatiquement et à l'utilisateur de naviguer dans les nombreux services offerts au moyen d'un guide électronique de programmes EPG (Electronic Program guide).

Le DVB-SI se compose de quatre tables principales et de trois tables facultatives.

Les tables principales de DVB-SI sont la table NIT
(Network Information Table), la table SDT (Service
Description Table), la table EIT (Event Information
Table) et la table TDT (Time and Date Table).

La NIT transporte des informations spécifiques relatives à un réseau constitué de plusieurs canaux physiques (dont plusieurs trains transports indépendants), telles que (au minimum) les fréquences et/ou les numéros de canaux du réseau utilisés lors de la configuration du décodeur du dispositif terminal.

La SDT liste les noms et d'autres paramètres associés à chaque service d'un même multiplex.

La EIT est utilisée pour la transmission d'informations relatives aux événements en cours ou à venir dans le multiplex reçu actuellement, et éventuellement sur d'autres multiplex.

La TDT est utilisée pour la remise à l'heure de l'horloge interne du dispositif terminal récepteur.

Les tables facultatives de DVB-SI sont la table
BAT (Bouquet Association Table) , la table RST
(Running Statuts Table) et la table ST (Stuffing Table)
La table BAT est utilisée pour grouper la présentation à J 'utilisateur de bouquets de services associés. Un service particulier peut appartenir à un ou plusieurs bouquets.

La RST est transmise pour la mise à jour rapide d'un ou plusieurs événements, une seule fois, au moment où un changement se produit (à la différence des autres tables qui sont transmises de façon répétitive).

Les ST sont des tables de bourrage utilisées par exemple pour invalider des tables devenues inutiles.

La fréquence de répétition des tables n'est pas imposée par le norme, mais elle doit toutefois être suffisante (10 à 50 fois par seconde) pour permettre au décodeur d'accéder assez rapidement au programme recherché.

En référence à nouveau à la figure 1, il est prévu dans l'invention une étape d'embrouillage au stade du multiplexeur 7.

Des paquets CAT transportant les informations de contrôles d'accès EMM sont insérés, ainsi que les informations des tables PAT et PMT, et celles du guide de programme EPG.

C'est également à ce stade que sont insérés les données correspondant à la mise à jour de la mémoire
Flash selon l'invention, qui sera décrite par la suite.

Les paquets transports 8 de T 3 octets sont corrigés cri 15 par codage do Poed Solornon selon la norme DVS; une correct ion complémentaire par code convulsif multiplie également le débit par un facteurcompris entre 1,14 et 2, avant reformatage des données, suivie d' un filtrage et d'une conversion D/A pour fournir les signaux I et Q analogique références 16 sur la figure 1.

Les signaux 16 modulent (étape 17) en MDP4
(Modulation de Phase a quatre états) ou QSPK
("Quadrature Phase Shift Keying" en langage anglosaxon) une porteuse intermédiaire FI 18, par exemple de 70 MHz qui est alors transposée en 19, dans la bande de fréquence appropriée à sa transmission par la voie montante du satellite, de l'ordre de 13 à 15Ghz.

La porteuse FI subit ensuite un nouveau changement de fréquence dans le transpondeur 20 avant sa diffusion vers les téléspectateurs dans la bande 10,7 à 12,75 Ghz via le satellite 21.

La chaîne 1 permettant le téléchargement selon l'invention comprend une deuxième suite 3 d'étapes de réception.

Les étapes de réception sont symétriques des étapes d'émission qui viennent d'être décrites.

Une première étape 22 permet un premier abaissement de fréquence dans la tête de réception de l'antenne, et amène la fréquence du signal entre 950 et 2150 Mhz.

Une deuxième étape 23 de changement de fréquence ramène la porteuse FI 24 aux alentours de 480 Mhz.

La porteuse est démodulée en 25 pour fournir les valeurs I et Q analogiques 16.

Après conversion analogique/numérique, filtrage et reformatage de I et X, en 26, la correction d'erreur permet de retrouver les paquets transports 8 de 188 octets.

I,e démultiplexeur 27 sélectionne les PES corresporidarît ati programme choisi par T 'utilisateur éventuellement desernbroulllés au préalable grâce aux
EMM ou ECM et a la clé privée de l'utilisateur présente sur la carte à puce de ce dernier.

Le décodeur MfEO, 2 28 reconstruit alors les images et le son du programme sélectionné.

On a représenté sur la figure 4 le schéma de fonctionnement du système 29 selon l'invention, qui s'intègre à l'organisation imposée par les normes DVB et MpEG-2.

Dans le mode de réalisation plus particulièrement décrit, il est prévu une station Sun Microsystem 30 connectée au multiplexeur 31 tête de réseau qui attaque par le moduleur 32 une ou plusieurs antennes paraboliques 33 d'émission correspondant à autant de transpondeurs vers le satellite 34.

Le satellite 34 réémet (voie descendante) vers les antennes paraboliques de réception 35 connectées aux dispositifs terminaux 36, eux-mêmes raccordés via des prises péritel aux appareils récepteur de télévision 37.

Pour permettre le téléchargement selon l'invention, l'opérateur du bouquet constitue les fichiers blocs 38 du code source qui seront décrits ultérieurement, par exemple en mémoire de stockage 39 permettant la mise à jour de la mémoire Flash du dispositif terminal.

Par ailleurs, il programme la commande du flux à générer en 40.

Pour ce faire, un flux 41 de téléchargement est déclaré dans les fichiers 42 de signalisation SI selon la norme DVB.

Plus précisément le flux de téléchargement est déclaré dans la NIT Actual (Service~list~descriptor, type "Mise à jour du terminal"), le nom du service de mise à jour du dispositif terminal étant précisé dans la SDT Actual.

De même, l'identification du constructeur du décodeur (manufacturer~ID), du dispositif terminal utilisé (hardware~ID) et de certains types d'utilisateurs (usage~ID) , ainsi que la version du programme de fonctionnement du terminal (version~ID) sont introduites dans les paquets correspondants.

Lors de sa mise en service, le décodeur du dispositif terminal 36 scrute la NIT Actual.

Si un flux de téléchargement est déclaré dans la
NIT Actual (service~list~descriptor, type "Mise à jour du terminal"), le dispositif terminal identifie sur quel transpondeur il est en mesure de trouver le flux à télécharger, il mémorise les informations caractéristiques de ce transpondeur qui figurent dans la NIT Actual puis il récupère le flux diffusé par ce transpondeur.

Le dispositif terminal récupère alors la SDT
Actual sur ce transpondeur, qui lui donne le nom du service de mise à jour du dispositif terminal qu'il a localisé dans le NIT Actuel. A partir du nom, le décodeur examine si le flux lui est destiné
(vérification du "manufacturer~ID", du "hardware-ID" et du "usage~ID") et si la version logicielle du programme de fonctionnement est différente de celle qu'il a en mémoire Flash (vérification du "version~ID")
Si la version est différente, le dispositif terminal numérique propose à T' abonné la mise à jour.

L'abonné a alors la possibilité de déclencher cette mise à jour instantanément ou a la possibilité de la différer.

Le schéma-bloc de la figure 5 représente les blocs fonctionrlels d'un dispositif tc-rmina O O utilisable avec le système selon l'invention.

Les signaux OT en provenancre di satellite sont amplifiés et convertis dans la gamme 950-2150 Mhz par le convertisseur à faible bruit tNC 52 tLow Noise
Conventer) situe au foyer de la parabole 53, puis appliqués à l'entrée antenne 54 du dispositif.

Le tuner (ou "front-end") 55, le plus souvent commandé par un bus RC, sélectionne le canal désiré dans la gamme 950-2150 Mhz, le transpose à une valeur
FI de 480 Mhz et effectue la sélectivité requise au moyen d'un filtre à onde de surface (FOS); le signal amplifié est démodulé de façon cohérente selon les axes 0 et 90 pour fournir les signaux I et Q analogiques en sortie.

La récupération correcte, se fait en coopération avec les étages suivants qui asservissent par une boucle la fréquence et la phase de l'oscillateur du démodulateur.

Les signaux I et Q sont appliqués chacun à un convertisseur analogique/numérique (ADC) 56 fonctionnant au double de la fréquence symbole (de l'ordre de 30 Mhz en Europe). Il s'agit le plus souvent d'un double convertisseur d'une résolution de six bits, capable d'échantillonner le signal à plus de 60 Mhz. Là encore, la fréquence d'échantillonnage est asservie à la fréquence symbole au moyen d'une boucle à verrouillage de phase.

Le bloc QPSK 57, outre les fonctions de récupération d'horloge et de porteuse (boucles de verrouillage de phase, mentionnées précédemment) réalise le filtrage demi-Nyquist complémentaire de celui appliqué à l'émission sur les signaux i 'j Q, fournis par exemple sur 2 x 3 ou 4 bits au bloc fonctionnel suivant 58 (FEC).

Le bloc 58 FEC distingue au moyen d'une logique majoritaire les 0 des 1, puis effectue J 'erisenhie do la correction d'erreurs, c'est-à-dire le décodage de
Viterbi du code convulsif de l'emissicDn, 1 e désentrelacement, le décodage de Reed-Solomon et le débrassage; les données en sortie 59 (paquets transports de 188 octets) sont en général fournies sous forme parallèle (huit bits de données plus signaux de contrôle dont l'un signale la présence éventuelle d'erreurs non correctibles).

Les paquets transports attaquent le bloc 60 DESCR
(désembrouilleur) qui communique avec le processeur principal 61 par un bus parallèle 61' permettant le transfert rapide de données. Il assume la sélection et le désembrouillage des paquets du programme choisi, sous le contrôle du dispositif de contrôle d'accès. Il est parfois combiné avec le démultiplexeur.

Le bloc DEMUX (démultiplexeur) 62 permet la sélection au moyen de filtres des PES correspondant au programme choisi par l'utilisateur.

Les PES audio et vidéo issus du démultiplexeur sont ensuite appliqués au bloc MPEG 63, généralement un décodeur combiné audio/vidéo, qui assure également les fonctions de générateur d'écran graphique nécessaire au guide de programmes (EPG). Le décodag de la série 68 ou un RISC, qui commande tous les circuits précédents, interprète les ordres en provenance de la commande à distance, gère le lecteur 69 de carte à puce 70 et les interfaces 71 de communication avec le nombre extérieur 72 (voir ciaprès).

Il est connecté via le bus 61' de données aux mémoires RAM 72, ROM 74, Flash 75 et E2PROM 76 qui sont agencées pour être mises en oeuvre selon l'invention, comme cela va être décrit ci-après en référence aux figures 6 et 7.

Le dispositif de contrôle d'accès comporte en général un ou deux lecteurs 69 de carte à puce 70 (le second étant alors prévu pour une carte bancaire).

Dans le cas d'un module de contrôle d'accès détachable (utilisant le "commun interface", matérialisé par la présence d'un ou plusieurs slots
PCMCIA), le dispositif de contrôle d'accès ainsi que le désembrouilleur sont situés dans un module au format PCMIA. Le démultiplexeur 62, intégré au dispositif terminal, reçoit alors des paquets transports en clair.

Enfin, le dispositif terminal 50 peut communiquer avec le monde extérieur 72 (PC, modem. .) par un ou plusieurs interfaces normalisés : série RS232, prallèle IEEE1284, ligne teléphonique (modem intégré), nécessaires pour T'interactivité et l'accès à de nouveaux services (téléchargement de fichiers ou de logiciel, téléachat, télépaiement, accès aux réseaux. .)
On va maintenant décrire ci-après la préparation des flux qui va permettre une diffusion optimisée du programme mis à jour selon l'invention.

Pour diffuser les informations fichiers blocs, image de la mise à jour du dispositif terminal, il faut en effet les transformer en flux MPEG.

Pour ce faire, plusieurs solutions sont envisageables, des outils dépendant du système d'exploitation retenu pour le dispositif terminal permettant cette intégration.

Ces outils sont à la portée de l'homme du métier et ne seront pas décrits plus avant.

Un fichier de commande est par ailleurs nécessaire pour la génération du flux. Ce fichier est une entrée pour un premier outil de transformation, par exemple l'outil connu sous la dénomination "flinterp" développé par la Société THOMSON Sun Interactive (TSI) dans le cadre du système d'exploitation connu sous la dénomination OpenTV, pour télévision numérique interactive et proposé par la même Société.

Le fichier de commande déclare les données à intégrer et précise la manière dont le flux final doit être organisé.

Par exemple, ce fichier de déclaration de l'application présente dans l'ordre les arguments à préciser de la façon suivante
1. app~name nom donné à l'application.

2. appel identifiant de l'application en valeur décimale. Dans le cas du téléchargement selon le mode de réalisation de l'invention plus particulièrement décrit, cette valeur décrit le champ UPDATE~ID. a valeur décimale est calculée à partir de la valoir hexadécimale composée de la manière suivante
manufacturer id + hardware~id + usage Id version id.

3. vapp~expiration~date : date donnée à laquelle l'opérateur souhaite annuler la validité. Ce champ n'est pas utile pour la fonction de mise à jour.

4. app~authorization : champ d'attribution des droits aux données transmises.

5. app~storage~limit : champ qui définit les limites de l'espace mémoire occupable par les données transmises.

6. memory~required : champ d'attribution de la ressource mémoire aux données transmises.

7. duration : champ donnant à la directive de compilation une idée sur la durée que prendra le flux en transmission; il est exprimé en nombre d'images par seconde ("frames/seconde" en langage anglosaxon) . Ce champ est de dimension importante du fait des composantes de type "vidéo".

8. output~filename nom arbitraire à donner au résultat de la compilation. Ce nom, suivi de l'extension "flow", est en entrée d'un deuxième outil lié au système d'exploitation, par exemple l'outil "mpeg2mux" dans l'exemple pris en référence au système d'exploitation OpenTV.

IJn fichier du "directive de l'insertion du bloc directory" est également prévu.

I1 permet de spécifier les instants d'insertion dans le flux du bloc d'en-tête qui décrit les données transmises. @ Il est généré automatiquemerit par l 'outil de compilation.

Deux marnières de procéder existent par exemple pour ce f ichor dit "Insert~directory"
On peut soit enchaîner les lignes d' Insertion, soit déclarer les insertions sur une ligne en précisant le début de l'insertion, le délai entre les insertions, et la durée depuis le début de 1 ' insertion pendant laquelle il faut insérer.

Par exemple la déclaration des blocs peut se faire de la façon suivante
Pour la déclaration du premier module, dans le langage de programmation retenu avec le système d'exploitation OpenTV
new~module 0 autoexec TPS 65000
flags 0 hashed+autorun
source 0 "data~bloc numéro 1"
set~hash~signature 0
insert 0
Pour les autre modules, on réalise alors la boucle suivante
new~module i data TPSi
flags i hashed+autorun
source i "data~bloc numéro (i+1)"
set~hash~signature i
insert i
Les directives "hashed+set~hash~signature" génèrent dans le code produit les données de signatures. Elles sont toutes initialisées à zéro.

Les étapes d'insertion dans le flow de signaux de télévision transmis par satellite sont maintenant précisées ci-après toujours en référence au système d'exploitation OpenTV.

L'étape d'insertion dans le flux produit apparaît par le directive "insert numéro dll module".

Selon le mode de réalisation, elle est mise juste après la déclaration du bloc concerne.

A noter qu'OpenTV offre également la possibilité d'une insertion groupée à le fin de toutes déclarations, ou d'une insertion hétérogène, au choix du producteur. Cela n'a aucune incidence sur le flux final
Le flux de mise à jour du terminal numérique est quant à lui signalé dans la trame DVB comme suit:
Table NIT Actual
- on déclare dans le service~list~descriptor, qui comprend la liste des services sur un transporteur particulier, un service de type privé (type 0x84) qui donne la valeur propriétaire de l'opérateur, par exemple TPS, pour identifier un flux de mise à jour du terminal numérique;
- on déclare dans le TPS~OPTV~Appli List des- criptor, qui comprend la liste des services auxquels un type d'application particulier est associé, un service de type privé (type 0x84), ici encore valeur propriétaire de l'opérateur pour identifier un flux de mise à jour du terminal numérique.

Table SDT Actual
- on déclare le nom du service de mise à jour du terminal qui transporte les informations "manufacturer~ID" (identification du fabricant de terminaux numériques), "hardware~ID" (identification de la plate-forme de terminaux numériques) "usage~ID" (identification d'une catégorie de terminaux numériques de même plate-forme hardware) "version ID" (identification de la version logicielle mise à jour).

Table PMT
- on déclare un private~data~specifier~descriptor, dont le but est d'identifter le flux comme un service opérateur véhiculant des données privées (ut il isatiori de la valeur fixée pat Te DVR Group pour l'opérateur déterminé)
on déclare îin OpenTV~indicat 'r description dont le but est d'identifier le flux @omme un flux diffusé comme rîn flux OpenTV,
- on déclare un OpenTV~stream~descriptor, dont le but est d'indiquer le table id utilisée pour véhiculer des données (valeur propriétaire de l'opérateur pour un flux de mise à jour du terminal)
L'organisation du flux MPEG-2 DVB est par ailleurs effectuée conformément à la norme MPEG-2 DVB, le flux de mise à jour du terminal étant composé de paquets de 188 octets, à savoir des paquets de données privées pour les données servant à mettre à jour le terminal numérique et des paquets de signalisation SI (NIT, SDT, PMT) permettant d'identifier la présence, les destinataires, le niveau du flux de téléchargement.

Comme on l'a vu en référence à la figure 5, le dispositif terminal utilisé selon l'invention dispose par ailleurs des ressources matérielles suivantes, de façon connue en elle-même
- une mémoire RAM volatile 73, de travail, directement adressable par le processeur 61,
- une mémoire Flash EPROM 75 non volatile, reprogrammable, directement adressable par le microprocesseur 61, destinée à recevoir le programme de fonctionnement du dispositif, et plus particulièrement de son décodeur. Cette mémoire est appelée mémoire Flash dans la présente description,
- une mémoire ROM 74 non volatile et non reprogrammable saris intervent ion mdtfiLielle, directement adressable par le processeur t L,
- une mémoire non volatile E2PROM 76, destinée à recevoir des données de configuration du décodeur.

Selon le mode de roalisation plus particulièrement décrit ici, chaque décodeur de dispositif terminal intègre une couche logicielle système qui permet d'installer et de faire fonctionner des applications identiques indépendamment du décodeur, c' est -à-dire sas qu'il soit nécessaire d'adapter ce dernier ou de recompiler lesdites applications.

En d'autres termes, les applications traduites en langage interprété sont indépendantes du microprocesseur utilisé par les décodeurs.

En référence maintenant aux figures 6 et 7, l'architecture logicielle 80 du décodeur selon le mode de réalisation de l'invention plus particulièrement décrit ici, se base sur une distinction en 3 niveaux de fonctionnalités, inspirée des couches OSI, à savoir une couche 81 dite drivers, une couche système 82 et une couche applications interactives 83.

Ces couches téléchargées à partir des émissions diffusées 84 sont prévues résidentes en mémoire Flash 75 (Cf. figure 7).

Plus précisément (Cf. figure 6), la couche drivers 81 concerne l'ensemble des programmes 85 qui permettent de mettre en oeuvre les fonctions matérielles offertes par le décodeur, dits programmes divers.

Les services offerts par les programmes drivers 85 sont conformes à la spécification d'interface de la couche système. Cette interface est définie pour les services standards et pour les services spécifiques, de façon connue en elle-même. Ces irlterfaces sont les mêmes pour tous les décodeurs.

La couche drivers 81 qui gère 1 os fonctions matérielles du décodeur est p t te e spécifique pour chaque version matérielle di de- ut.

La couche système 82 germe quant à elle 1 tc comportement du décodeur. Elle ofîr les services généraux 86 nécessaires à son fonctionnement et les services 87 appelés par les applications interactives.

Les applications interactives 88 Écrit appel aux services de la couche système via l'interpréteur.

C'est par ailleurs la couche système qui gère l'activation et le téléchargement des applications interactives.

La couche système est chargée sur le décodeur en code directement interprétable par le processeur.

Pour la couche système, le passage d'un décodeur à un autre correspond donc principalement à une reconfiguration des ressources mémoire et à une recompilation du code.

Enfin, la couche applications interactives 83 rassemble les applications d'interface 88 avec l'utilisateur et les ressources associées.

Lorsqu'elles sont sur le décodeur, ces applications sont décrites en langage interprété et font appel aux services offerts par la couche système.

Sauf à faire appel à des ressources spécifiques à un décodeur, les applications sont identiques sur les différents décodeurs.

Les applications, et les ressources associées, sont soit résidentes, c'est-à-dire mémorisées de manière permanente dans le décodeur, soit dynamiques, c'est-à-dire téléchargées par la couche système à partir du flux MPEG-2.

Les applications associées à tino émission particulières ou a caractère éphémère, sont diffusées sur le multiplex MPEG pn général en môme temps que l'émission associée.

Ces applications sont téléchargées en mémoire RAM 73 volatile du décodeur (Cf. figure 7) pour entre exécutées ou consommées immédiatement elles ne sont pas conservées par le décodeur au delà de leur utilisation.

Les applications à caractère permanent, appelées applications résidentes, sont stockées en mémoire
Flash non volatile 74 du décodeur.

Selon l'invention, ces applications peuvent être mises à jour sur le décodeur via le flux MPEG en utilisant les services de la couche système.

Plus précisément, selon l'invention, l'ensemble de la couche système et des applications résidentes peut être mis à jour en utilisant la fonction de mise à jour du terminal numérique par téléchargement.

Pour le décodeur, on distingue donc trois cas de téléchargement
- ie téléchargement d'applications en RAM 73 ou téléchargement dynamique,
- le téléchargement d'applications en mémoire
Flash 75 ou téléchargement d'applications résidentes,
- la mise à jour du terminal numérique selon l'invention.

La fonction de téléchargement d'applications en
RAM 80 est effectuée par la couche système 82.

La fonction de téléchargement d'applications en mémoire Flash 75 permet, à couche système constante, de mettre à jour les applications 88 et ressources qui sont résidentes sur le terminal.

Cette fonction permet de télécharger de nouvelles applications de gestion du décodeur ; elle permet également la personnalisation de l'interface utilisateur des décodeurs.

La fonction de téléchargement d'applicatlons ell mémoire Flash est toujours effectuée par Ta couche système 82.

Enfin, la fonction de mise à jour du tcrml: numérique permet la mise à jour complète des logiciels résidents dans le décodeur ; elle est utilisée pour la mise à jour de la couche système 82 du décodeur et de la couche drivers 81.

Autrement dit, la fonction mise à jour du terminal réinitialise l'ensemble de la mémoire Flash 75 du décodeur ; toutes les applications qui auraient été téléchargées antérieurement (par la fonction de téléchargement d'applications en mémoire Flash) sont ainsi effacées.

Il convient par ailleurs de noter que la fonction de démarrage du décodeur, à la mise en service et la fonction dite "loader" de lancement de la mise à jour du terminal se trouve en mémoire morte ROM 74 non effaçable et/ou en mémoire Flash non effaçable et préservée.

Les données qui sont transmises au décodeur par la fonction de mise à jour du terminal pour la réinitialisation de sa mémoire Flash sont par ailleurs strictement les mêmes pour tous les décodeurs d'un même type matériel et qui présentent une même couche système.

Remarquons qu'à une date donnée, il existe une pluralité de types de décodeurs en service, présentant une configuration différente.

Or chaque type de décodeur dépend de son fabricant, de la plate-forme matérielle (dispositif terminal auquel il appartient) sur lequel il est construit, de son usage (location / vente / vente subventionnée...), tous ces paramètres ayant cri impact sur les fonctions de contrôle d'accès, et donc sur la couche système mis en oeuvre par le décodeur.

Par ailleurs, pour un type de décodeur donné (origine / type de matériel / usage) , il existe plusieurs versions du programme de fÉr t icririement du dispositif terminal. Cependant, une Seule version de logiciel système peut être proposée à un instant donné sur le réseau de diffusion.

C'est pour tenir compte de tous ces éléments qu'il a donc été imaginé la solutiori proposée par l'invention.

Ainsi, comme on l'a vu, on rappelle qu'à chaque service de mise à jour du programme ont été associés les paramètres suivants
- manufacturer ID : identification du fabricant du dispositif terminal,
- hardware ID : identification du matériel,
- usage~ID : identification de l'usage du décodeur,
- version~ID : identification de la version du programme de fonctionnement à jour.

Dans le mode de réalisation plus particulièrement décrit ici, chacun de ces paramètres est codé sur un octet (soit 256 valeurs disponibles) .

Ils peuvent par ailleurs et par exemple être regroupés de la manière suivante
- décoder ID : identification du type de décodeur.

Il regroupe les identificateurs "manufacturer ID" "hardware ID" et "usage ID",
- update ID : identification du service de mise à jour. Il regroupe les identificateurs "decoder ID" et "version ID".

La fonction de mise à jour du dispositif terminal peut aussi être mise en oeuvre soit en utilisant les services de diffusion de données d'un réseau de transmission par câble, soit en utilisant la ligne de série disponible sur le dispositif terminal, par exemple directement à partii- d 'un PC ou (Si' une station de travail.

On va maintenant décrire plus précisément le processus de mise à jour du terminal en référence a la figure 8.

La mise à jour s'appuie sur la transmission de données qui sont l'image binaire des données 90 à programmer en mémoire Flash 75, transmi ses au décodeur avec l'indication de l'adresse à laquelle elles doivent être recopiées dans ladite mémoire.

Plus précisément, les données à télécharger sont transmises au décodeur sous forme de blocs de données contiguës, à recopier à une adresse donnée de la mémoire Flash. Plusieurs blocs 91, 91'... vont ainsi pouvoir être définis pour un même téléchargement.

A chaque bloc de données est associée une en-tête, 92, 92' donnant son adresse.

Pour permettre à la fonction de mise à jour du terminal d'acquérir et de programmer en mémoire Flash les différents blocs 91, 91', dits blocs images, qui constituent la nouvelle programmation, les blocs qui sont à traiter sont décrits dans un bloc en-tête 93, 93'
Les blocs image sont eux-mêmes transportés sous forme de blocs données 94, 94'...

Enfin, un bloc en-tête général 95 identifie en 95' l'application qui est téléchargée et donne la liste des blocs données générés à partir des blocs images et qui composent l'application.

Des informations 96, 96' de sécurisation du transport, par exemple comprenant un CPC (Cyclic Redundoncy Check) de validation des données sont également ajoutées à ces blocs images.

Dans un mode de réalisation avantageux de l'invention, il est également prévu une sécurisation de la fonction de téléchargement.

La fonction de mise à jour du terminal numérique interdit ainsi le téléchargement de données qui ne sont pas transmises par un opérateur autorise.

En référence à la figure 8, la sécurisation de la fonction de téléchargement est effectuée de la manière suivante
- on associe à chaque bloc données 94, 94' une signature 97, 97' ; cette signature est par exemple une suite de bits calculée à partir de données dudit bloc données,
- on adjoint les signatures de chacun des blocs données référencés par le bloc en-tête au bloc entête 95,
- on associe audit bloc en-tête 95 une signature à partir de laquelle est calculée une signature chiffrée 98 ; cette signature chiffrée est par exemple une suite de bits, calculée à partir de la signature du bloc en-tête général 95.

La signature chiffrée 98 du bloc en-tête 95 est ensuite transmise avec le bloc en-tête 95.

Plus précisément, la signature d'un bloc données est calculée à partir des données du bloc, par un algorithme qui permet un calcul rapide de la signature mais qui rend irréaliste, voire impossible, l'opération inverse qui consisterait à générer des données dont la signature serait égale à une valeur donnée.

Lorsqu'unie signature est associée à un bloc de données, cette signature permet ainsi de vérifier l'authenticité du bloc de données.

L'algorithme de calcul de la signature à partir d'un bloc de données est par exemple l'algorithme de "hashage", la largeur de la signature étant de 128 bits.

La signature chiffrée 98 du bloc en-tête 95 est quant à elle calculée à partir de la signature nori chiffrée du bloc en-tête.

Seules les personnes autorisées sont à même de calculer une signature chiffrée à partir d'une signature non chiffrée.

L'opération inverse, qui permet de retrouver la signature non chiffrée à partir d'une signature chiffrée 98 est par contre une fonction publique, dont le coût en temps de calcul est compatible avec les temps de traitements admissibles pour la fonction de téléchargement selon l'invention.

L'association de la signatures chiffrée 98 au bloc en-tête 95 permet ainsi de s'assurer de l'authenticité du bloc en-tête, et donc des données qu'il transporte.

Cette authentification permet donc de s'assurer de l'authenticité des signatures 97, 97' des blocs de données qui sont incluses dans le bloc en-tête.

L'algorithme de chiffrement de la signature du bloc en-tête est un algorithme de type RS (Reed
Solomon), avec une clé privée (pour le calcul de la signature chiffrée à partir de la signature non chiffrée) et une clé publique (pour le calcul de la signature non chiffrée à partir de la signature chiffrée) . La largeur de la signature chiffrée est ici de 1024 bits.

Dans un mode de réalisation avantageux et pour augmenter la fiabilité et le robustesse du système selon l'invention, il est prévu une possibilité automatique de mise à jour du terminal dans les cas de corruption de la mémoire Flash du décodeur (cas d 'tino interruption par une coupure secteur pendant l'operation de mise à gour de la mémoire Flash par exempi^ ) .

Dans ce cas, la fonction de mise à jour du terminal est alors associée directement à la fonction de démarrage du processeur.

Les conditions d'activation de la fonction de mise à joi- selon le mode de réalisation de l'invention plus particulièrement décrit ici, ainsi que le séquencement interne de la mise à jour vont maintenant être détaillés.

Dans l'exemple de la syntaxe plus particulièrement décrit, le bloc en-tête 95 correspond au "module directory" et les blocs 94, 94' de téléchargement aux "modules à télécharger".

Dans un mode de réalisation de l'invention, on a vu qu'une configuration du téléchargement par la ligne série était prévue.

Elle se fait alors à l'aide d'un outil de téléchargement qui consiste en un PC et d'un logiciel de dialogue avec le décodeur.

Les données pour mettre à jour le décodeur sont alors stockées sur le PC sous forme de fichier, avec un fichier par bloc, la fonction de mise à jour du terminal numérique par la ligne série étant prioritaire par rapport à toutes les autres fonctions du terminal.

Une fois les initialisations effectuées, le programme de démarrage émet une trame d'identification sur la ligne série. Si en retour, il reçoit une demande de téléchargement, il lance la fonction de mise à jour du terminal par la ligne série.

Lorsque les doiiiiées du programme mis à jour sont par contre transmises via le flux MPEG selon le téléchargement de t' invention, elles ~ sont transportées dans un service DVB de données privoos.

Le type de ce service (all cris DVB : "service~type") est un type particulier OTV terminal upclate" ; ce type est détirii pour l'occasion, dans le plage réservée aux utilisateurs (range "user defined" 0x80 to OxE).

Le service utilise la syntaxe des sections à entête longue, mais toutes les sous-tables sont contenues dans une section unique.

Par ailleurs le programme mis à jour du terminal n'est pas associé, dans le multiplex qui le porte, à un mécanisme de contrôle d'accès (au sens MPEG-2 /
DVB).

Rappelons que le principe de la transmission des blocs est le suivant : chaque bloc est découpé en éléments d'une taille maximum de 4064 octets. A chaque élément est associé un en-tête (de 16 octets) ; un élément et son en-tête sont transportés par une sous-table MPEG.

L'identification d'un service de mise à jour du terminal sur le réseau se fait à partir des données de signalisation du réseau (tables PSI et tables SI).

Plus précisément, un service de mise à jour du terminal est identifié dans la NIT ; la description du flux qui le porte est donnée par la PMT l'identification des décodeurs auxquels il s'adresse est donnée par la SDT.

Selon l'invention, le services de mise à jour du terminal est associé à trois valeurs des paramètres "manufacturer ID" ; "hardware ID" et "user ID".

Au sens MPE(,-2 / DVB, un service est identifié par les paramètres "original-network~id" ; "transport~stream~id" et "servlce~id" qui lui sont associés par la définition de la NIT.

Un service e de titi se à @ cor de terminal numérique est par ailleurs un service du type "OTV terminal update".

Il comprend une unique composante du type "MPEG
Transport Privato Section" (0x05).

La PMT du service comprend quant à lui deux descripteurs privés dont les valeurs de "tag" sont prédéterminées.

Dans l'exemple plus particulièrement décrit ici, la syntaxe de la PMT d'un service de mise à jour du terminal est ainsi la suivante
TS~program~map~section~fr~OTV~terminal~update()
table~id (8 bits) = 0x02
section~syntax~indicator (1 bit)
'0' (1 bit)
reserved (2 bits)
section~lenght (12 bits) = 27
program~number (16 bits)
reserved (2 bits)
version~number (5 bits)
current~next~indicator (1 bit)
section~number (8 bits) = 0x00
last~section~number (8 bits) = 0x00
reserved (3 bits)
PCR~PID (13 bits) = 0
reserved (4 bits)
program info lenght (12 bits) -
stream~type (8 > 8 bits ~ 0x05
reserved (3 bits)
elementary~PID (13 bits) -PtD du service
reserved (4 biti
ES~info~lenght (12 bits) 9
{
descriptor~tag (8 bits) = 0x89
descriptor~lenght (8 bits) - 0x04
Private (32 bits) = 0x54534900
descriptor~tag (8 bits) = 0x90
descriptor~lenght (8 bits) = 0x01
table~ID (8 bits) = 0x84
descriptor~tag (8 bits) = 0x0f
descriptor~lenght (8 bits) = 0x04
private~data~indicator~value = 0x00000010
CRC~32 (32 bits)
L'examen dans la SDT du nom des services de type "OTV terminal update" (définis par la NIT) permet de détecter la présence d'un programme de mise à jour du terminal qui concerne le décodeur ; il permet également de détecter si la version du programme à jour diffusée sur le flux est celle qui se trouve sur le décodeur ou si elle est postérieure.

Ces informations sont alors traitées par le logiciel applicatif du décodeur.

* Pour la fonction de mise à jour du terminal, un service de mise à jour du terminal est par exemple identifié par
- le paramètre "update ID",
- les paramètres de programmation de la chaîne d'acquisition de signal qui permettent de se connecter au multiplex sur lequel test dix fusé le service,
- le numéro du flux élémentaire PID) qui transporte le service.

Les blocs sont ensuite transmis par éléments.

Chaque élément est. par exemple transporté par une section à en-tête Jonque dont la syntaxe est par exemple la suivante
unit~section~for~OTV~termina~update ()
table~id (8 bits) = 0x40
section~syntaxindicator (1 bit)
'0' (1 bit)
reserved (2 bits)
section~lenght (12 bits)
block il (16 bits)
reserved (2 bits)
version~number (5 bits)
current~next~indicator (1 bit)
section~number (8 bits) = 0x00
last~section~number (8 bits) = 0x00
update~ID (32 bits)
unused (32 bits)
block~offset (32 bits)
unused (32 bits)
date (NUMERIQUE*32 bits)
CRC~32 (32 bits)
Le mécanisme d'acquisition des différents éléments qui composent un bloc est le même que celui utilisé par l'acquisition des données OpenTV pris à titre d'exemple de système d'exploitation utilisable avec l'invention.

On va maintenant décrire le déroulement de la mise à jour du terminal selon le mode de réalisation do l'invention plus particulièrement décrit ici en référence à la figure 9.

Rappelons au préalable que la mise à jour prévue dans le mode de réalisation plus particulièrement décrit ici peut être activée pour les raisons suivantes
forçage de la fonction de mise à jour par le clavier,
- demande de mise à jour du terminal par l'application,
- test d'intégrité des données en mémoire Flash négatif.

Les demandes de mise à jour du terminal par l'outillage de mise à jour par ligne série et par forçage de la fonction par le clavier sont testées à la mise sous tension du décodeur.

Le test d'intégrité des données en mémoire Flash et la demande de mise à jour en provenance de l'application sont testées à chaque mise en services du décodeur.

Pour permettre un éventuel redémarrage du décodeur dans le cas où les données en mémoire Flash du décodeur ne seraient pas intègres et où l'identification du service de téléchargement donné en E2EPROM ne serait pas valide (service absent, données invalides ou données non intègres) , la fonction de téléchargement possède avantageusement dans ses données l'identification de services par défaut.

La figure 9 montre le synoptique 99 de téléchargement selon l'invention.

Le programme de mise à jour teste tout d'abord (étape 100) l'intégrité du programme "loader", qui reste chargé en permanence dans la mémoire ROM 74 d'r dispositif, et qui va donc permettre la mise à joui- de la mémoire Flash grâce à une programmation connue en elle-même.

Si le test est OK (101), on recherche en 102 la présence d'un PC de téléchargement.

Si le PC est présent (104) , la possibilité d'acquisition du nouveau "programme mis à ci jour" de fonctionnement du terminal via la prise série RS232 est alors vérifiée (étapes 105 et 106) , ptris en cas de test positif, la programmation de la mémoire Flash est réalisée (108).

La validité de la programmation est ensuite testée (109), une boucle 110 de reprise du chargement étant alors suivie s'il y a lieu.

En cas de chargement correct, un test d'intégrité 111 de la zone Système de la mémoire Flash est réalisé.

Si le test est OK (test 112), le nouveau programme mis à jour est activé (étape 113), et l'utilisateur peut reprendre la visualisation des signaux de télévision.

Si aucun PC n'est présent (114), on vérifie (étape 115) si le téléchargement forcé est demandé par l'utilisateur.

Si oui (116), le dispositif acquiert les données sur le mutliplex en 117, vérifie (étape 118) si l'acquisition des données est correcte, et en cas de test positif autorise la programmation de la mémoire
Flash en 119.

Un test 120 de vérification est ensuite réalisé avant l'activation du nouveau programme mis à jour dans la mémoire Flash en 113.

Si aucun téléchargement forcé n'est requis, les données d'identification du flux (NIT, SDT) sont récupérés en 121.

Si une nouvelle version du programme mis à jour est disponible (étape 122), une étape 123 de proposition d téléchargement à l'utilisateur est effectuée.

Si oui (124) ou passe à l'étape 117, sinon le test 112 est réalisé, renvoyant à l'acquisition 117, ou directement à l'activation du programme de fonctionnement du système permettant à l'utilisateur de récupérer la réception des signaux de télévision.

Dans le mode de réalisation préféré selon l'invention, le "loader" chargé en mémoire ROM comme décrit ci-avant utilise le clavier et les afficheurs de la face avant du dispositif terminal comme ressources d'interface homme-machine.

La télécommande et l'écran TV ne sont par contre pas exploités (télécommande sans effet, écran TV noir).

Le programme loader indique la phase dans laquelle il se trouve (Cf. figure 10).

Le décodeur terminal étant mis en service, et la carte de l'utilisateur étant opérationnelle dans le lecteur de carte dudit dispositif, le dispositif terminal est alors dit à l'état de veille.

Il est mis en marche par l'utilisateur, par exemple par le biais d'une télécommande.

A la sortie de son état de veille, un message sur l'écran du récepteur de télévision propose la mise à jour si nécessaire.

L'utilisateur peut alors accepter de la faire en confirmant avec une touche OK ou décider de la faire une prochaine fois en activant une touche Quitter.

Si l'utilisateur accepte, la procédure est initiée.

Deux phases principales sont à considérer
- les tests (124) intégrités, recherche du PC de téléchargement,
- le téléchargement (125).

Quelle que soit la phase, la détection d'un défaut majeur entraîne par ailleurs 1 'affichage 126 d'un code erreur spécifique 127. L'affichaye est maintenu jusqu'à 1 'acquittement par 1 l'utilisateur.

Pendant la phase test 124, le loader affiche
(étape 128) 4 tirets (afficheur 129). . Le but est de signaler à l'utilisateur la prise en compte par le décodeur de sa demande de sortie de veille.

Cet état dure environ 500ms (300ms pour la recherche du PC de téléchargement + 200ms temps de traitement divers) avant de donner la main au logiciel opérationnel en 130.

L'entrée en phase téléchargement 131 se traduit par l'affichage 132 des lettres "LD" sur 2 afficheurs gauches. Les 2 afficheurs droits (Cf. figure 10) indiquent sa sous-phase
- "01" recherche des informations de
téléchargement,
- "02" acquisition des données,
- "03" vérification des données,
"04" programmation de la mémoire Flash.

A noter que si l'utilisateur a accepté la mise à jour, l'écran de l'appareil de télévision reste noir.

Lorsque la procédure est terminée, un message s'affiche sur l'écran et l'utilisateur peut alors accéder à nouveau aux programmes de télévision en confirmant avec la touche OK.

Comme il va de soi et comme il résulte d'ailleurs de ce qui précède, la présente invention ne se limite pas au mode de réalisation plus particulièrement décrit mais en embrasse au contraire toutes les variantes et notamment celles ou d'autres systèmes d'exploitation qu'OpenTV et/ou d'autres normes de télétransmission de données numériques ct/oc systèmes de compression de données et/ou systèmes de sécurisation sont utilisés.

Claims (10)

REVENDICATIONS

1. Procédé de téléchargement de données numériques par satellite dans au moins un dispositif terminal

(36, 50) pour utilisateur, ledit dispositif étant muni d'un décodeur et propre à être connecté à un appareil récepteur (37) de télévision, caractérisé en ce que

en même temps que les données correspondant aux signaux de télévision retransmis, on émet à intervalles réguliers des données correspondant à un programme de chargement d'une mémoire Flash (75) intégrée au dispositif terminal, dit programme à jour, ledit programme à jour comprenant une mise à jour des programmes de mise en oeuvre des fonctions matérielles du décodeur, dits programmes drivers (85), du système d'exploitation du dispositif terminal (82)et d'au moins un programme d'application spécifique (88),

on émet les données du programme à jour avec un champ d'identification comportant une identification du constructeur du décodeur utilisé, du dispositif terminal utilisé, du numéro de version dudit programme à jour et un sous-champ réservé à la différenciatioll entre certains types d'utilisateurs,

on active le dispositif terminal en réception par l'intermédiaire d'une carte à puce (70) préalablement programmée et insérée dans le terminal,

lorsque le terminal est activé, on teste régulièrement si la version de programme de mise à jour recue est différente de celle présente dans la mémoire Flash (75),

et, lors la comparaison montre une différence, on propose à l'utilisateur une mise à jour de ladite mémoire Flash (75), , l'utilisateur pouvant alors soit effectuer, soit différer le téléchargement du programme à jour dans ladite mémoire Flash.

2. Procédé de téléchargement selon la revendication 1, caractérisé en ce que en cas de décision de téléchargement par l'utilisateur, on télécharge d'abord le programme à jour dans une mémoire vive ou EEPROM du décodeur, la mise à jour de la mémoire Flash (75) n'étant effectuée que si l'acquisition en mémoire vive est correcte, à partir de ladite mémoire vive ou EEPROM.

3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que il comporte une étape préalable de test (102, 104) permettant la mise à jour du programme via une ligne série.

4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que il comporte une étape (105) de forçage de la mise à jour par l'utilisateur.

5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, lors de la mise sous tension du dispositif terminal, on teste (100) l'intégrité du programme de fonctionnement dudit dispositif teimiril présent dans la mémoire Flash et on lance automatiquement le téléchargement du programme à lotir n cas de défaut d'intégrité.

6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en en ce que on sécurise les données transmise correspondantes au programme à jour, de sorte que seules les données transmises par un opérateur autorise peuvent être téléchargées.

7. Procédé selon la revendication C, caractérisé en ce que, pour sécuriser les données correspondantes au programme à jour, on transmet au décodeur lesdites données sous forme de blocs de données contiguës (91, 91'), à chaque bloc étant associé une en-tête (92, 92')correspondant à une adresse donnée de la mémoire

Flash (75),

on décrit les blocs de données contiguës à traiter dans un bloc en-tête (95),

à chaque bloc de données on associe une signature

(97, 97'), les signatures de chacun des blocs de données décrits dans un bloc en-tête étant adjointes audit bloc en-tête (95),

et on associe audit bloc en-tête une signature à partir de laquelle est calculée une signature chiffrée (98), transmise avec ledit bloc en-tête.

8. Procédé selon la revendication 7, caractérisé en ce que l'algorithme de chiffrement de la signature du bloc en-tête est un algorithme de type RS, avec une clé privée pour le calcul de la signature chiffrée à partir de la signature non chiffrée, et une clé publique pour le calcul de la signature non chiffrée à partir de la signature chiffrée.

9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce quo, la retransmission des signaux de télévision et le téléchargement mettent en oeuvre la norme européenne

DVB à partir de fîtix de données compressées selon la norme MPEG-2, l'identification d'un service de mise à jour du programme de fonctionnement du terminal se faisant à partir- des données de signalisation du réseau présentes dais les tables PSI et SI le service de mise à jour étant identifié dans la table

NIT, la description dii flux qui la porte étant donnée par la table PMT, et l'identification des décodeurs concernés étant donnée par la table SDT.

10. Système (29) de téléchargement de données numériques retransmises par satellite, pour utilisateur muni d'un dispositif terminal comportant un décodeur, propre à être connecté à un appareil récepteur de télévision, caractérisé en ce que le système comporte des moyens propres à mettre en oeuvre le procédé de téléchargement de données numériques selon l'une quelconque des revendications précédentes.