Brevet FR2838017A1 — publié le 20031003

Procédé pour générer des applications interactives, notamment pour des terminaux de télévision numérique La présente invention concerne la réalisation d'applications interactives, notamment pour télévision numérique. Des applications interactives sont encodées dans un signal distribué sur un canal de transmission numérique (par câble, satellite ou réseau hertzien). Les terminaux qui reçoivent ce signal sont constitués notamment par des récepteurs TV munis d'un module de télécommande, formant des plates-formes d'exécution à disposition d'utilisateurs. Une partie au moins des applications interactives sont ainsi destinées à être installées sur une plate-forme d'exécution pour mettre en #uvre une succession de rubriques thématiques sous forme de menu. De telles applications interactives sont associées ou non à des programmes de télévision. Elles peuvent concerner aussi bien des applications de type magazine TV que des services tels que des prévisions météorologiques, une gestion de portefeuilles boursiers, ou autres. A chaque rubrique d'un menu d'application interactive correspond une scène thématique avec un habillage graphique et/ou sonore associé à cette scène. Ainsi, l'édition d'une scène thématique sur un poste TV implique, sur l'écran du poste, un habillage graphique et, par des moyens de restitution sonore associés, un habillage sonore. L'habillage graphique peut consister en l'incorporation dans l'écran TV de séquences animées (issues de fichiers video au format mpeg ou autres), d'images en mode point (issues de fichiers bitmap, gif, ou autres), ou encore de texte avec des attributs d'édition de texte associés (caractères, fontes, couleur). L'habillage sonore peut consister en une séquence sonore qui est jouée pendant la scène thématique (lecture d'un fichier au format WAV ou autre). Généralement, le menu est hiérarchisé en rubriques et sous-rubriques, avec un ou plusieurs niveaux de sousrubriques. Ainsi, une pluralité de sous-rubriques peuvent être associées à une même rubrique principale, elle-même pouvant être la rubrique fille d'une rubrique mère d'un niveau supérieur. En principe, les rubriques du menu hiérarchisé sont classées par thèmes (programme TV, sport, météorologie, ou autres). On comprendra ainsi qu'à chaque rubrique du menu peuvent être associés un habillage graphique et/ou sonore, ainsi qu'un contenu thématique de la rubrique. Par exemple, le contenu thématique d'une sous-rubrique peut être relatif à du basket-ball, tandis que le contenu thématique de sa rubrique mère est relatif au sport, de façon générale. Le passage d'une rubrique du menu à une autre rubrique, ou plus généralement la navigation dans le menu, sont conditionnés par des couples événement/action. Un événement peut consister en un actionnement d'un organe de la télécommande par l'utilisateur, par exemple pour accéder à une rubrique choisie, tandis que l'action associée consiste, dans ce cas, en l'édition (affichage à l'écran et restitution sonore) d'une scène thématique correspondant à la rubrique choisie. Les terminaux d'accès à ces applications sont dotés de systèmes d'exploitation permettant le traitement d'images vidéo et la restitution sonore, pour éditer et mettre en #uvre les applications interactives. Cependant, ce type d'applications peut être accessible par l'intermédiaire de systèmes d'accès très différents tels que : OPEN TV commercialisé par la société OPEN TV Incorporated aux Etats-Unis, - Media Highway, distribué en France par la société CANAL +, Mheg système ouvert répondant au système de normalisation ISO, - le système MHP-DVB de JAVA dédié à la télévision, en cours d'établissement, et - un navigateur HTML ou XML qui met en #uvre un interpréteur HTML ou XML (ou browser ). En principe, le développement des applications ne peut être réalisé que pour un système d'exploitation donné, correspondant à celui du système d'accès final utilisé. Dans la demande publiée WO 01/04747, il a été proposé un système de développement rapide d'applications interactives capable de mettre en corrélation des couples événement/action. Le système génère une liste générale de couples possibles comprenant des champs d'identification. Pour préparer les applications interactives qui seront effectivement distribuées sur le réseau, on sélectionne dans la liste précitée, en amont de la tête du réseau de distribution, les couples événement/action susceptibles d'être utilisés pour la mise en #uvre des applications interactives distribuées, en attribuant des valeurs choisies dans les champs d'identification des couples sélectionnés. Un tel système permet de surmonter, de façon très avantageuse, les problèmes liés aux différences entre systèmes d'accès, non compatibles, et aux différences entre terminaux, notamment en terme de capacité des terminaux (taille des mémoires vives RAM, rapidité de traitement des processeurs, ou encore fontes disponibles pour l'édition de textes). Néanmoins, comme indiqué ci-avant, les applications interactives mettent généralement en #uvre des menus hiérarchisés par thèmes. Ainsi, l'ajout ou la suppression d'un thème nécessite la reconstruction complète du menu et de l'application interactive correspondante. L'actualisation des menus d'applications interactives nécessite donc une programmation lourde de la part de l'opérateur. De même, si un utilisateur de terminal souhaite seulement une sélection des applications interactives distribuées selon un profil qui lui est propre (accord parental restreint, ou encore favoris systématiques dans un menu général), l'opérateur devrait, en principe, fournir un menu adapté aux exigences de l'utilisateur. Si le système de développement de la demande WO 01/04747 permet une rapide adaptation à une modification du système d'accès ou du terminal, il ne permet pas en revanche une réorganisation rapide des menus d'applications interactives lorsqu'une modification de tels menus est souhaitée. La présente invention vient améliorer la situation. Elle propose à cet effet un procédé de réalisation d'applications interactives, dans lequel : - on prépare des tables de données comprenant au moins, pour chaque rubrique courante d'un menu, un identifiant d'un n#ud correspondant à cette rubrique courante et un identifiant d'un n#ud père correspondant à une rubrique mère de cette rubrique courante dans le menu, - et l'on génère, à partir des données des tables, une liste comprenant au moins des éléments descriptifs des n#uds et hiérarchisée selon un arbre logique dont les n#uds sont positionnés en fonction desdits identifiants de n#uds. Le cas échéant, le procédé se poursuit par une lecture de la liste par un interpréteur, comme on le verra plus loin, pour construire une application interactive correspondant au menu dont les rubriques sont déclarées avec un identifiant valide dans la liste, ce menu étant hiérarchisé en fonction des valeurs des identifiants. Ainsi, selon l'un des avantages que procure la présente invention, l'opérateur peut disposer initialement d'une table complète dans laquelle sont répertoriées une pluralité de rubriques possibles sous forme de n#uds. A ces rubriques sont associées des sous-rubriques respectives, ainsi que des sous-rubriques filles d'un ou plusieurs niveaux encore inférieurs. Si, dans cette table complète, il est souhaité de supprimer une rubrique thématique particulière, l'opérateur attribue un code d'identifiant prédéterminé au n#ud correspondant à cette rubrique (par exemple un code d'indisponibilité) et cette rubrique, ainsi que ses rubriques filles dans l'arborescence du menu, n'apparaîtra pas lorsque l'application interactive correspondante sera mise en #uvre. Dans un mode de réalisation préféré, on génère une liste principale comportant plusieurs sous-listes hiérarchiquement imbriquées selon l'arbre logique précité. La liste comprend, pour chaque n#ud, des éléments respectivement descriptifs : - de la position de ce n#ud dans l'arbre logique, - de contenants d'informations d'une rubrique correspondant à ce n#ud, - et d'attributs associés à chaque contenant d'informations. Dans ce mode de réalisation, les tables de données comportent : - une première table de données relatives à des positions de n#uds dans l'arbre logique, cette table comprenant pour chaque n#ud au moins : # l'identifiant de ce n#ud, # l'identifiant du n#ud père de ce n#ud, # et un nom attribué à ce n#ud, - une seconde table de données relatives aux contenants d'informations, cette table comprenant pour chaque contenant au moins : # un identifiant de ce contenant, # l'identifiant du n#ud auquel est associé ce contenant, # et un nom de contenant, - et une troisième table de données relatives à des attributs associés aux contenants d'informations, comportant pour chaque attribut au moins : # un identifiant de cet attribut, # l'identifiant du contenant auquel est associé l'attribut, # et un nom de l'attribut. Ainsi, les éléments des tables ont un lien de hiérarchie d'une table à l'autre : on affecte à chaque attribut courant (élément de la table des attributs) un identifiant de contenant père (élément de la table des contenants) et, à ce contenant père, un identifiant de n#ud père (élément de la table des n#uds). Dans ce mode de réalisation, chaque table comprend donc un identifiant d'un élément de la table, un nom de cet élément et un identifiant d'un élément père d'une autre table. Dans une réalisation plus élaborée, la liste principale précitée comporte en outre des éléments descriptifs d'applications interactives dans lesquelles interviennent un ou plusieurs n#uds. En plus des trois tables ci-avant, on prévoit une quatrième table de données relatives aux applications interactives, cette quatrième table comprenant pour chaque application interactive : # un identifiant de cette application interactive, # ainsi qu'un nom attribué à cette application interactive. La première table de données comprend en outre, pour chaque n#ud, l'identifiant de l'application interactive dans laquelle une rubrique associée à ce n#ud intervient. Ainsi, un élément de la table des n#uds est lié hiérarchiquement à un élément père de la table déclarative des applications interactives. En variante, on prévoit un jeu de première, seconde et troisième tables de données par application interactive. Dans cette variante, on génère ainsi une liste principale par application interactive. Chaque application interactive étant susceptible de s'étendre sur plusieurs niveaux successifs de rubriques, on prévoit avantageusement, pour chaque n#ud de la première table, des données relatives à un nom de niveau dans lequel intervient ce n#ud, la liste hiérarchisée comprenant en outre des éléments descriptifs de niveaux de n#uds. Le cas échéant, un nom de niveau peut viser le niveau d'un ensemble de rubriques dans un menu, tandis qu'un nom de niveau suivant vise un niveau inférieur relatif à un ensemble de sous-rubriques de l'une des rubriques précitées. Avantageusement, les contenants d'informations sont répertoriés par classes thématiques et la seconde table comporte en outre des données relatives à un nom de classe thématique à laquelle appartient chaque contenant d'informations. Ainsi, la liste hiérarchisée comprend en outre des éléments descriptifs de classes de contenants. Le cas échéant, si un utilisateur souhaite un profil d'application interactive particulier (contrôle parental ou autre), les contenants d'informations étant ainsi accessibles par classes thématiques, on identifie facilement les contenants d'informations des rubriques du menu non souhaités, pour les supprimer. Les attributs précités peuvent être de différents types. Avantageusement, les attributs de la table des attributs sont classés par types choisis parmi un ensemble comprenant au moins : # une chaîne de caractères alpha-numériques, tel qu'un texte, # un chemin d'accès vers un composant d'habillage graphique et/ou sonore, tel qu'un lien vers un fichier multimédia, # et un agrégat d'attributs, tel qu'un ensemble définissant une police de texte (taille, fonte, style ou autres) . Ainsi, la table des attributs comprend en outre des données relatives à un type d'attribut et la liste hiérarchisée comprend en outre des éléments descriptifs de types d'attributs. Avantageusement, la liste hiérarchisée comprend, d'une part, des éléments descriptifs de noms d'attributs et, d'autre part, des éléments descriptifs de valeurs d'attributs, et la troisième table comprend en outre des données relatives à une valeur de chaque attribut. Ainsi, on déclare aussi bien un nom d'attribut dans la table d'attributs (par exemple un nom taille de caractère de texte ) que la valeur de cet attribut (par exemple 12 ). La valeur d'un attribut peut être aussi thématique (par exemple ARIAL peut être une valeur thématique de l'attribut de nom fonte de caractère de texte ). Dans une réalisation sophistiquée, la sous-liste déclarative précitée qui comprend les éléments descriptifs d'attributs, comporte des sous-listes secondaires d'éléments descriptifs d'attributs, imbriquées selon un arbre logique de n#uds d'attributs, et la troisième table comprend en outre des données relatives à un identifiant d'un attribut père de chaque attribut. Ainsi, un attribut père dans la sous-liste d'attributs peut correspondre en fait à un agrégat d'attributs, lesquels sont identifiés dans une sous-liste secondaire. On génère donc, à partir de la table des attributs, une hiérarchie parmi les attributs. Selon un aspect avantageux, on prépare en outre un dossier, dit média , de données d'informations de contenus de rubriques et/ou d'habillage graphique (et/ou sonore) de rubriques. La liste hiérarchisée précitée comprend alors des descriptions de chemins d'accès vers des données de ce dossier. Dans une réalisation particulière, ces chemins d'accès peuvent être définis en tant qu'attributs (ou valeurs d'attributs), tels que des liens de type URL (pour Uniform Resource Locator ). En variante ou en complément, la liste hiérarchisée peut aussi comporter au moins un chemin d'accès vers au moins une liste secondaire, qui elle, comprend des chemins d'accès vers des données du dossier média. Chaque application interactive étant susceptible de s'étendre sur plusieurs niveaux successifs de rubriques comme indiqué ci-avant, on prépare avantageusement un dossier de données d'informations et l'on génère une liste hiérarchisée comprenant des chemins d'accès vers des données dudit dossier, pour chaque niveau d'une application interactive. Ainsi, le procédé selon l'invention, dans sa forme générale, permet à un opérateur ou à un utilisateur du terminal d'accéder facilement aux contenus des applications interactives distribuées et de les modifier rapidement. Le procédé peut être mis en #uvre aussi bien par l'opérateur que l'utilisateur. A ce titre, la présente invention vise aussi un système de réalisation d'applications interactives, comportant : - une tête de réseau agencée pour distribuer des signaux représentatifs d'applications interactives sur un canal de transmission numérique, - une plate-forme d'exécution agencée pour recevoir ces signaux et propre à installer les applications interactives pour mettre en #uvre une succession de rubriques thématiques sous forme de menu. Dans le système au sens de la présente invention, la tête de réseau comporte : - un éditeur de tables de données comprenant au moins, pour chaque rubrique courante d'un menu, un identifiant d'un n#ud correspondant à cette rubrique courante et un identifiant d'un n#ud père correspondant à une rubrique mère de cette rubrique courante dans le menu, - et un automate de formatage capable de générer, à partir des données des tables, une liste comprenant au moins des éléments descriptifs des n#uds et hiérarchisée selon un arbre logique dont les n#uds sont positionnés en fonction des identifiants de n#uds. Dans une première réalisation, la tête de réseau est agencée pour envoyer à la plate-forme d'exécution les données des tables, ainsi que l'automate de formatage, en vue de générer la liste hiérarchisée précitée au niveau de la plate-forme d'exécution. Avantageusement, la plate-forme d'exécution comporte des moyens de mise à jour des données des tables pour générer des menus en fonction d'un profil d'utilisateur du terminal. Dans une seconde réalisation, la tête de réseau envoie seulement la liste hiérarchisée à la plate-forme d'exécution, la liste hiérarchisée étant générée au niveau de la tête de réseau. Avantageusement, la tête de réseau comporte dans cette seconde réalisation des moyens de mise à jour des tables de données et elle envoie à la plate-forme d'exécution une liste mise à jour en fonction de spécificités du terminal (telles qu'une capacité mémoire du terminal, un accès conditionné à des rubriques prédéterminées de menu, un accès conditionné à des applications interactives prédéterminées, ou autres). Selon un aspect avantageux, les données des tables sont initialement codées sous la forme d'un script de fichier texte. Les moyens de mise à jour peuvent comporter simplement un éditeur de texte pour ajouter et/ou supprimer et/ou modifier des rubriques et/ou des contenus de rubriques de menu. De façon générale, la plate-forme d'exécution comprend des moyens d'interprétation de la liste hiérarchisée pour mettre en #uvre sur la plate-forme d'exécution un menu hiérarchisé en correspondance de la liste. Selon un autre aspect avantageux, la tête de réseau envoie à la plate-forme d'exécution un dossier dit média , comprenant des données d'informations de contenus de rubriques et/ou d'habillage graphique (et/ou sonore) de rubriques. La liste hiérarchisée comprend alors des descriptions de chemins d'accès vers des données du dossier média. Les moyens d'interprétation précités sont capables d'identifier les chemins d'accès de la liste et comportent avantageusement des fichiers exécutables (dits communément pluggins ) pour lire les fichiers du dossier média et mettre ainsi en #uvre le contenu de chaque rubrique du menu sur la plate-forme d'exécution, en correspondance d'un habillage graphique (et/ou sonore) décrit dans la liste hiérarchisée. Chaque application interactive étant susceptible de s'étendre sur plusieurs niveaux successifs de rubriques, la tête de réseau envoie avantageusement à la plate-forme d'exécution : - un dossier comprenant des données d'informations de contenus de rubriques et/ou d'habillage graphique et/ou sonore de rubriques, - une liste hiérarchisée comprenant des descriptions de chemins d'accès vers des données du dossier média, pour chaque niveau de l'application interactive. Ainsi, dans un système au sens de la présente invention, la liste hiérarchisée est générée à partir des tables de données, à l'aide d'un automate de formatage. Cependant, le formatage des tables pour générer la liste s'effectue sous le contrôle d'un fichier de définition de type de document (désigné communément par l'abréviation DTD pour Document Type Définition ). Un tel fichier constitue donc un moyen important pour mettre en #uvre l'invention. A ce titre, la présente invention vise aussi une structure de données comprenant des données du fichier DTD et comportant alors une succession de balises déclaratives comprenant au moins : - une déclaration de n#uds correspondants aux rubriques, - une déclaration d'éléments correspondants aux contenants de rubriques, - et une déclaration d'attributs associés aux contenants de rubriques. En pratique, notamment dans le cas d'une transmission des tables au terminal pour une génération de liste au niveau du terminal, les données du fichier DTD sont encodées avec les données des tables et, dans une réalisation avantageuse, la structure de données comporte donc : - une première table de données relatives à des positions de n#uds dans un arbre logique représentatif d'une arborescence du menu, telle que la première table des n#uds du type ci-avant, - une seconde table de données relatives à des contenants d'informations, telle que la seconde table des contenants du type ci-avant, et une troisième table de données relatives à des attributs associés aux contenants d'informations, telle que la troisième table des attributs du type ci-avant. La structure de données comprend en outre des moyens de formatage des données des tables pour générer une liste hiérarchisée sous le contrôle de la succession de balises déclaratives précitée (DTD). Dans une réalisation avantageuse, la succession de balises déclaratives est sous la forme d'un fichier de définition de type de document (DTD), cette définition étant suivant un métalangage tel que SGML ou XML. Avantageusement, la liste hiérarchisée se présente sous la forme d'un métafichier (XML ou HTML) destiné à être lu et interprété sur une plate-forme d'exécution. Le formatage des données selon un métafichier (XML ou HTML) est d'un intérêt certain pour générer ou modifier des arborescences, telles que des menus hiérarchisés dans la présente application de l'invention. On distingue les listes d'éléments descriptifs de rubriques et/ou de contenants de rubriques d'un menu (en référence à des thèmes du menu), des listes d'éléments descriptifs de contenus des rubriques du menu (en référence à des informations contenues dans le menu). Pour générer ces listes d'éléments descriptifs de contenus de rubriques (comportant notamment des liens vers un ou plusieurs dossiers média), on utilise un fichier de définition de type de document (DTD) mais dont la structure des données est encore différente de celle énoncée ci-avant. Pour générer de telles listes d'éléments descriptifs de contenus de rubriques, la présente invention prévoit une structure de données comportant des données de ce fichier DTD, sous la forme d'une succession de balises déclaratives comprenant au moins : - une déclaration d'un objet en tant que contenu d'une rubrique, - une déclaration d'un état de l'objet, - une déclaration d'un automate d'interactions susceptible de générer des couples événement/action propres à modifier l'état de l'objet. On entend par contenu d'une rubrique , par exemple un contenu audiovisuel, ou un contenu d'informations sous forme de texte, au autre. On entend par état de l'objet , par exemple un état sélectionné , un état sélectionnable , un état caché , ou autre. Dans une réalisation, on transmet au terminal une liste de contenus de rubriques avec au moins un dossier média pour un niveau d'application interactive, la liste comportant des chemins d'accès vers des fichiers du dossier média. Pour passer à un sous-niveau de l'application interactive, on prévoit une seconde transmission d'une autre liste avec des chemin d'accès vers un autre dossier média. Dans une variante avantageuse, on transmet au terminal la structure de données précitée comprenant les données du fichier DTD, avec un ou plusieurs dossiers média, ce qui permet, au niveau du terminal, de générer une liste de contenus de rubriques sélectionnés par l'utilisateur suivant son profil (accord parental ou autre). Ainsi, la structure de données précitée comprend en outre : - au moins un dossier média comprenant : # des données éditoriales de contenus de rubriques, # des fichiers multimédia (fichiers sons, fichiers images, fichiers vidéo, ou autres) et/ou des fichiers d'informations (fichiers texte, fichiers de polices de texte, et autres). La structure de données comprend en outre des moyens de formatage des données du dossier média pour générer, sous le contrôle de la succession de balises déclaratives précitée (DTD), au moins une liste comprenant au moins une description d'un chemin d'accès à un fichier du dossier média, ou encore une description d'un chemin d'accès à une autre liste pour prévoir un changement de niveau dans l'application interactive. Avantageusement, la succession de balises déclaratives se présente donc sous la forme d'un fichier de définition de type de document (DTD) suivant un métalangage de type SGML ou XML. La liste ainsi générée est sous la forme d'un métafichier tel qu'une page HTML ou XML qui peut être lue et interprétée sur une plate-forme d'exécution pour mettre en #uvre, sur cette plate-forme d'exécution, le contenu d'au moins une rubrique en correspondance des données du dossier média. Avantageusement, la succession de balises déclaratives précitée comprend en outre une déclaration d'une organisation graphique de l'objet pour éditer en correspondance le contenu de la rubrique sur la plateforme d'exécution. Il peut s'agir par exemple d'une définition de position d'une image sur l'écran du poste TV. D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels : - la figure 1 représente schématiquement un système de développement d'applications interactives, pour télévision numérique, comprenant un serveur et un terminal pour mettre en #uvre les applications interactives distribuées par le serveur ; - la figure 2 représente des tables de données comprenant des identifiants d'éléments d'applications interactives, les données de ces tables étant destinées à être formatées selon une liste hiérarchisée ; - la figure 3 représente schématiquement les étapes d'un procédé d'une mise en forme d'une liste hiérarchisée et d'interprétation de cette liste pour la mise en #uvre d'une application interactive sur une plate-forme d'exécution ; - la figure 4 représente schématiquement une arborescence de la liste hiérarchisée en fonction des identifiants que comprennent les tables de données, avec, dans l'exemple représenté, une suppression de branches de l'arborescence commandée par l'utilisateur du terminal ; - la figure 5A représente partiellement la liste hiérarchisée précitée, éditée sous la forme d'un tableau, à partir d'un programme tableur tel que ACCESS ; - la figure 5B représente partiellement une liste hiérarchisée éditée sous la forme d'un tableau, dans lequel les colonnes comprennent respectivement les identifiants de n#uds, les identifiants de n#uds pères, les identifiants des applications interactives associées, le nom des n#uds et le niveau des n#uds dans l'application interactive associée ; - la figure 5C représente partiellement la liste hiérarchisée précitée, éditée sous la forme d'un tableau, avec des n#uds supprimés sur commande d'un utilisateur du terminal, dans l'exemple représenté ; - les figures 6A, 6B et 6C représentent des affichages sur un écran d'une plate-forme d'exécution, respectivement d'un habillage graphique associé à une rubrique de menus, d'un habillage graphique associé à une seconde rubrique d'un même niveau du menu, et d'un habillage graphique associé à une sous-rubrique d'un niveau inférieur du menu ; - la figure 7A représente partiellement une arborescence d'un n#ud vers des attributs associés à des contenants d'informations ; et - la figure 7B représente schématiquement les tables transmises à différents niveaux de déroulement d'une application interactive. En annexe I sont retranscrites les tables de données (fichier TableO pour un menu portail d'accueil ) relatives à un premier niveau dans le déroulement d'une application interactive. En annexe II sont retranscrites les tables de données (fichier TableOl pour une rubrique programmes TV ) relatives à un second niveau dans le déroulement de l'application interactive. En annexe III sont partiellement retranscrites les instructions d'un automate de formatage AFT des tables de données en langage JAVA. En annexe IV sont retranscrites les données d'un fichier de définition de type de document DTD pour générer une liste hiérarchisée, du type précité. En annexe V est partiellement retranscrite une liste hiérarchisée, en langage XML (fichier menuO.xml), obtenue à partir des tables de l'annexe I. En annexe VI est partiellement retranscrite une liste hiérarchisée, en langage XML (fichier menuOl.xml), obtenue à partir des tables de l'annexe II. En annexe VII sont retranscrites les données d'un fichier de définition de type de document DTD pour générer un fichier XML de déclaration d'habillage graphique de rubriques de menus d'applications interactives. En annexe VIII sont partiellement retranscrites les données du fichier XML précité, de déclaration d'habillage graphique, obtenu par formatage de données sous le contrôle du fichier DTD de l'annexe VII. En annexe IX est retranscrite une liste hiérarchisée, en langage XML (fichier menu0bis.xml), variante de la liste de l'annexe V car elle déclare à la fois des rubriques de menus et un habillage graphique associé à chaque rubrique. On se réfère tout d'abord à la figure 1 sur laquelle une tête de réseau 2 d'un serveur transmet par le réseau hertzien (antenne AS, dans l'exemple représenté) un signal comportant des données de télévision numérique, ainsi que des données d'application interactives destinées à être mises en #uvre sur une plate-forme d'exécution comprenant, dans l'exemple décrit, un terminal 1 et un poste de télévision muni d'un écran ECR, cette plate-forme d'exécution comprenant une antenne AT propre à recevoir le signal émis du serveur. Les applications interactives sont installées en un point du réseau de transmission numérique afin de permettre une transmission de ces applications interactives, soit sur demande d'un utilisateur dans le cas où ces applications interactives sont transmises par l'intermédiaire du WWW ("World Wide Web"), sous forme de documents HTML, soit encore télédiffusées de manière cyclique lorsque le canal de transmission numérique est un canal de télévision, comme dans l'exemple représenté sur la figure 1. En particulier, les données cycliques peuvent contenir des documents XML ou HTML et des applications en langage interprété JAVA, par exemple avec le système d'accès MHP-DVB indiqué ci-avant. En variante, la transmission de documents HTML peut être effectuée à partir d'un site WWW et d'un serveur dédié. Cependant, comme on le verra plus loin, la présente invention permet avantageusement de s'affranchir d'une voie d'accès à un site WWW, puisque l'utilisateur peut, lui-même, selon son profil, programmer directement son terminal 1, pour sélectionner les rubriques du menu diffusé cycliquement, qu'il souhaite éditer sur son poste. Chaque application interactive consiste en une succession de scènes thématiques qui peuvent incorporer des images en mode point ou des images vidéo (portant la référence IM sur la figure 1), des séquences sonores et des informations sous forme de fichier texte. Ainsi, en se référant à la figure 1, sur l'écran ECR du poste de la plate-forme d'exécution, il apparaît une image IM vidéo ou en mode point sur un fond d'écran BCG, ainsi qu'un texte TXT, le cas échéant se référant à un événement représenté dans l'image IM, et un pictogramme PIC permettant à l'utilisateur de démarrer une séquence animée vidéo ou une séquence sonore, en relation avec un événement représenté dans l'image IM. Sur une partie inférieure de l'écran ECR apparaît une barre de menus BM qui, dans l'exemple représenté, se présente sous la forme d'un bandeau déroulant comprenant des rubriques de menus (dans l'exemple représenté guide de programme radio, actualités, météorologie, guide de programmes TV, retour au menu précédent ou quitter l'application "menu"). Les rubriques représentées sur la barre de menus BM sont, en partie au moins, sélectionnables à partir d'un organe de saisie 11 (tel qu'une télécommande). Un curseur CU se déplace le long de la barre de menus BM pour indiquer visuellement à l'utilisateur la rubrique courante qu'il peut sélectionner. Par exemple, lorsque la plate-forme d'exécution utilise le système d'accès OPEN TV, le système d'exploitation est, en principe, dédié à l'application interactive considérée et le module de commande permettant la sélection de rubriques dans le déroulement de l'application interactive est constitué par un module de commande 11, telle qu'une télécommande universelle à boutons, permettant de commander le téléviseur muni du moniteur d'affichage ECR. On comprendra ainsi que la plate-forme d'exécution précitée comprend un poste de télévision muni d'un écran d'affichage ECR, une télécommande universelle 11 à boutons, le terminal d'accès 1 et, le cas échéant, l'antenne de réception AT. En se référant aux figures 6A, 6B et 6C, l'écran de la plate-forme d'exécution peut afficher des séquences animées vidéo (issues par exemple de fichiers MPEG, AVI ou autres), des images fixes (par exemple des images en mode point "bit map"), des pictogrammes PIC (par exemple des images en mode vectoriel), ainsi qu'un texte TXT (auquel est associé une fonte choisie, une taille de caractères choisie, ou autres). En particulier, l'écran est séparé en deux zones Zl et Z2, une zone supérieure dans laquelle sont présentés les éléments d'habillage graphique d'une rubrique du menu et une zone inférieure Z2 dans laquelle est représentée la barre de menus BM avec les noms de ces rubriques. Bien entendu, la délimitation (représentée ici en traits pointillés) entre les zones supérieure et inférieure de l'écran n'apparaît pas, en pratique, sur l'écran de la plate-forme d'exécution. L'utilisateur du terminal, lorsqu'il sélectionne par exemple la rubrique TV, voit apparaître à l'écran un guide de programmes de télévision présenté sous la forme d'une suite d'images IM et de textes TXT en correspondance de ces images IM (figure 6A). Lorsque l'utilisateur actionne avec son organe de saisie 11, une flèche "droite", l'habillage graphique associé à la nouvelle rubrique "NEWS" (pour les actualités) apparaît sur l'écran de la plate-forme d'exécution avec de nouvelles images et, dans l'exemple représenté sur la figure 6B, des pictogrammes en correspondance de ces images IM. En se référant à la figure 6C, lorsque l'utilisateur valide une rubrique dans la barre de menus BM (la rubrique "NEWS" dans l'exemple représenté), l'utilisateur voir apparaître une seconde barre de menus BM2, tandis que les attributs de représentation de l'ancienne barre de menus BM1 sont modifiés : les rubriques non sélectionnées de l'ancienne barre de menus BM1 sont représentées en parties grisées. Avantageusement, il est conservé préférentiellement une rémanence des rubriques mères anciennement sélectionnées, lorsque l'on passe d'une rubrique du menu à une sous-rubrique. De plus, à chaque rubrique et/ou sous-rubrique du menu correspond un habillage graphique, d'une part, de la barre de menus dans laquelle figure cette rubrique (zone inférieure Z2 de l'écran) et, d'autre part, d'un contenu éditorial associé à cette rubrique (dans la zone supérieure Zl de l'écran). On comprendra ainsi que les rubriques et sousrubriques du menu d'applications interactives respectent un chaînage logique, selon une arborescence qui sera décrite ci-après. On se réfère maintenant à la figure 2 sur laquelle des tables de données Tl, T2, T3 et T4 sont initialement préparées, en attribuant des valeurs à des identifiants qu'elle comporte, la liste hiérarchisée précitée étant obtenue à partir d'un formatage de ces tables de données Tl à T4 comme on le verra plus loin Dans l'exemple décrit, la table T4 comprend des données relatives à toutes les applications interactives envisagées par le serveur. Elle peut se présenter sous la forme d'un fichier texte, ou script, dont le nom de fichier attribué est t~Appl. Cette table T4 contient l'ensemble des identifiants d'applications interactives destinées à être reçues par le terminal 1 ou par une famille de terminaux recevant des applications interactives distribuées par un même opérateur. La table T4 comprend donc un identifiant de l'application interactive ID~Appl, ainsi qu'un nom (variable "Name") qui est attribué à cette application interactive. Par exemple, un identifiant d'application interactive peut être la langue dans laquelle cette application interactive doit être mise en #uvre (français, anglais, espagnol ou autre). Ainsi, on comprendra qu'une valeur numérique est attribuée à l'identifiant d'application interactive ID~Appl, par exemple "1" pour une application interactive en français, à laquelle on donne le nom "French" (variable "Name"). De même, une application interactive en anglais aura un identifiant ID~Appl de valeur numérique "2" et le nom donné à cette application interactive devient Name "English". La table Tl de la figure 2 est une table sousjacente de la table des applications interactives T4. Elle se présente elle aussi sous la forme d'un fichier texte ou script, de nom "t~N". Cette table Tl est destinée à représenter les différents n#uds de l'arborescence que met en #uvre les déroulements respectifs de toutes les applications interactives envisagées. Chaque application est identifiée dans la table Tl par la variable ID~Appl. Dans l'exemple décrit, les paramètres de la table T2 sont : - un identifiant numérique d'un n#ud courant ID~N; - un identifiant numérique d'un n#ud père de ce n#ud courant ID~PN ; - l'identifiant numérique de l'application interactive qui met en #uvre ces n#uds ID~Appl - la variable "Name" (en principe une variable alphanumérique) correspondant au nom du n#ud courant ; et - la variable "Level" (variable alphanumérique dans l'exemple décrit) correspondant à un niveau du n#ud dans l'arborescence de l'application interactive. Cette variable de niveau permet le regroupement de n#uds par classes. Avantageusement, on constitue ainsi une liste de n#uds en regroupant les n#uds d'un même n#ud père, d'une part, et les n#uds de même variable de niveau, d'autre part. A titre d'exemple, on peut se référer à la figure 5B dans laquelle tous les n#uds de la liste sont associés à une même application interactive, d'identifiant "3". En particulier, le premier niveau de l'application interactive correspond à la variable "Mainlist". Ce niveau "Mainlist" correspond au premier niveau de l'application interactive d'identifiant "3", lorsque l'on charge un menu de portail d'accueil pour mettre en #uvre l'application interactive "3". Ainsi, le n#ud racine de l'application interactive (premier n#ud père) a pour nom de niveau la variable "Mainlist". L'identifiant numérique de ce n#ud racine est "1". Ainsi, la ligne 11 de la figure 5B est relative au nom de n#ud "programme radio" d'identifiant de n#ud "3" et d'identifiant de n#ud père "1" (n#ud racine). En suivant le même exemple, la ligne suivante est relative au n#ud de nom "Liste des radios". Il s'agit alors d'un niveau inférieur dans l'arborescence de l'application interactive mise en oeuvre, ce niveau inférieur portant le nom "radiolist". L'identifiant du n#ud "liste des radios" est 30 (colonne ID~N), tandis que l'identifiant de son n#ud père ("programme radio") a la valeur numérique "3" (colonne ID~PN). Dans un autre exemple sur la figure 5B, l'arborescence de l'application interactive commence par le n#ud racine "Mainlist", un autre n#ud fils de ce n#ud racine est le noeud "Sports" d'identifiant "5". Un n#ud fils du n#ud "Sports" est le n#ud "Football", dans le niveau "Sportlist". L'identifiant du noeud "Football" est "52". Dans un niveau encore inférieur "Sportfoot", un n#ud fils du n#ud "Football" est "contenusportfootball", portant l'identifiant "520". On se réfère à nouveau à la figure 2, dans laquelle la table T2 comprend des données relatives à des contenants d'informations des applications interactives mises en #uvre. Elle se présente aussi sous la forme d'un fichier texte ou script, de nom de fichier t~El. En principe, la table T2 ne contient que des informations liées à un n#ud ou plusieurs n#uds de la table Tl, mais aucune information propre au contenu même des rubriques du menu. Les paramètres de la table T2 sont les suivants : - un identifiant de contenant d'informations ID~El ; - un identifiant d'un n#ud courant auquel ce contenant d'informations est associé ID~N ; - une variable "Name" correspondant au nom donné à ce contenant d'informations ; et - une variable "ClassEl" (en principe alphanumérique) relative à une classe de contenant d'informations, tel qu'un thème du menu, ou encore un profil d'utilisateur. La table T3 de la figure 2 est relative aux attributs associés à ses contenants d'informations. Elle se présente sous la forme d'un fichier texte ou script, de nom de fichier t~Attr. Ainsi, on comprendra que chaque ligne de cette table identifie un contenu d'informations. Un attribut peut avoir une structure relativement complexe. Par exemple un contenant d'informations "événement sportif" peut être constitué d'une date, d'un lieu, d'une équipe hôte, d'une équipe invitée. Le contenant d'informations "événement sportif" est, en principe, répertorié dans la table T2. En revanche, la date, le lieu et les équipes précitées seront des attributs répertoriés dans la table T3. Néanmoins," on comprendra que la date est elle même formée d'un jour, d'un mois et d'une année. Ainsi, un attribut peut être l'attribut courant d'un attribut père et, à cet effet, la table T3 des attributs comprend : - un identifiant d'un attribut courant ID~Attr ; - un identifiant d'attribut père de cet attribut courant ID PAttr . on créé ainsi une hiérarchie au sein même de la table des attributs T3 ; - un identifiant d'un contenant d'informations dans la table T2, ID~E1 ; un nom donné à l'attribut courant (variable alphanumérique "Name" ) ; - une valeur (variable "Val") donnée à cet attribut courant, qui sera décrite ci-après ; et - une variable "Type" associée à cet attribut courant et qui sera décrite ci-après. Comme indiqué ci-avant pour un contenant "événement sportif", le nom de l'attribut courant peut être la variable "Name" : "Equipe invitée". Dans ce cas, la variable Val correspond à la valeur de cet attribut, par exemple "Marseille" dans l'exemple décrit. On comprend ainsi que la variable Val (en principe alphanumérique) peut être une valeur thématique associée à un attribut. Cependant, il peut encore s'agir d'une valeur physique. Par exemple, "12" est la valeur Val de l'attribut "taille de caractère". La variable Type est relative à un type d'attribut courant, parmi : - un texte sous la forme d'une chaîne de caractères alphanumériques (Type = TXT) ; - un chemin d'accès, telle qu'une adresse URL (Type = URL) ; et un agrégat d'attributs tel que, par exemple, les caractéristiques d'une police : la taille, la fonte, le style (gras, souligné, italique) . Dans ce dernier cas, la variable Type est "GrpAttr". La chaîne de caractères alphanumériques précitée peut correspondre à la partie de texte dans la zone 1 de l'habillage graphique en correspondance des rubriques du menu, ou encore au texte dans la barre de menus BM, dans la zone 2 de l'écran d'affichage. L'adresse URL précitée peut correspondre à un chemin d'accès vers un composant, tel qu'un fichier multimédia (image, séquence animée, séquence sonore ou autre) pour l'habillage dans la zone 1 de l'écran, ou encore vers une liste hiérarchisée secondaire correspondant à un niveau différent (supérieur ou inférieur) dans la mise en #uvre de l'application interactive sur la plate-forme d'exécution, comme on le verra plus loin. Dans le cas d'un agrégat d'attributs, on comprendra que l'identifiant de l'agrégat d'attributs correspond à l'identifiant d'un attribut père ID~PAttr d'une pluralité d'attributs courants. D'une manière générale, on comprendra que les tables Tl à T4 sont hiérarchisées comme suit : chaque table aval comprend des identifiants d'éléments qui sont décrits de façon complète dans une table amont, selon une caractéristique avantageuse de la présente invention. Dans un mode de réalisation préféré, la table des n#uds Tl est hiérarchisée "en interne" puisqu'elle comprend des données relatives, à la fois, à un n#ud courant et à un n#ud père de ce n#ud courant déclarés dans la même table. Il en est de même pour la table des attributs T3, dans le mode de réalisation préféré représenté sur la figure 2. En variante du mode de réalisation représenté sur la figure 2, la table T4 des applications interactives peut être supprimée. Dans ce cas, pour chaque application interactive considérée, on prévoit un jeu de trois tables de données Tl, T2 et T3, respectivement relatives aux n#uds de l'application interactive considérée, aux contenants d'informations de ces n#uds et aux attributs de ces contenants d'informations. De plus, dans une variante moins sophistiquée du mode de réalisation représenté sur la figure 2, la table des contenants d'informations T2 peut être supprimée. Dans ce cas, les données relatives au contenant d'informations peuvent être incorporées dans la table Tl des n#uds, ou encore dans la table T3 des attributs. Néanmoins, la suppression de la table des contenants d'informations T2 rend plus complexe la structure des tables Tl et/ou T3 et la mise à jour des données dans les tables de n#uds Tl et d'attributs T3 s'avère plus délicate. On se réfère maintenant à la figure 7A pour décrire un exemple de classes de contenants d'informations répertoriés dans la table T2. Le n#ud de la table Tl, portant le nom "Programme TV", comporte l'identifiant ID~N de valeur numérique "1" (encadré 61 dans la figure 7A). Dans la table des contenants d'informations T2, l'identifiant de ce n#ud "Programme TV" est répertorié pour trois classes de contenants d'informations (encadrés 62,63 et 64 de la figure 7A). Les identifiants des contenants d'informations regroupés dans la classe "ContenerLogique" sont identifiés par les valeurs numériques "11" à "14". Cette classe d'éléments peut être relative à un élément thématique tel que la date du jour pour afficher les rubriques d'un guide des programmes de télévision correspondant à cette date. Dans l'encadré 65, les attributs associés aux contenants d'informations dans la classe de l'encadré 62 seront ainsi la date, avec sa valeur du jour, le cas échéant, l'heure en cours, avec sa valeur, ou autre. Une seconde classe de contenants d'informations (encadré 63 dans la figure 7A) est relative à la navigation d'une rubrique à une sous-rubrique. Ainsi, les attributs associés à cette classe de contenants d'informations (encadré 66 dans la figure 7A) correspondent, par exemple, à un chemin d'accès vers une liste hiérarchisée suivante (fichier au format XML dans l'exemple décrit). Comme on le verra plus loin, cette liste hiérarchisée suivante comprend toutes les informations relatives au niveau suivant dans l'application interactive mise en #uvre (sous-rubrique "Programme TV" du portail d'accueil principal). Ainsi, on comprendra que la table des attributs T3 peut comporter des chemins d'accès vers une seconde liste hiérarchisée lorsque l'on passe d'un premier niveau à un second niveau dans l'application interactive. Le fichier correspondant à la liste hiérarchisée suivante porte ici le nom "menu0l.xml". La troisième classe de contenants d'informations (encadré 64 de la figure 7A) est relative à l'habillage graphique dans la zone supérieure Zl de l'écran ECR de la plate-forme d'exécution. Ainsi, les attributs associés au contenant d'informations dans cette classe "contenerEdito" comprennent un chemin d'accès vers un fichier "programmeTV.XML" (encadré 67 de la figure 7A). Dans ce fichier "programmeTV.XML" sont répertoriés des liens URL vers des fichiers multimédia (son, image, vidéo ou autre) pour produire l'habillage graphique de la zone supérieure de l'écran d'affichage. Ainsi, les classes de la table T2 peuvent être relatives à un thème logique (par exemple l'heure et la date), à un thème de menu (pour passer d'une rubrique à l'autre) ou encore à un thème d'habillage de rubrique (habillage de la zone Zl). On se réfère maintenant à la figure 3 pour décrire un procédé de transmission d'application interactive du serveur 2 au terminal 1, précités. On prévoit, dans cette réalisation, une diffusion cyclique de l'ensemble des applications interactives destinées à être mises en #uvre sur de la plate-forme d'exécution. Dans un mode de réalisation préféré, les tables de données Tl à T4 sont formatées au niveau du terminal 1, pour générer une liste hiérarchisée représentative d'une rubrique de menus. Dans ce mode de réalisation, l'opérateur distribuant les applications interactives prépare, au niveau de la tête de réseau, le contenu des tables de données d'applications interactives T4, de n#uds Tl, de contenants d'informations T2 et d'attributs T3. Ces tables de données sont encodées et transmises dans un signal hertzien, à partir du serveur 2 et à destination du terminal 1. Préférentiellement, les tables de données Tl à T4 sont transmises avec un dossier média 36 comprenant par exemple des fichiers multimédia d'habillage graphique, sonores ou autres, comme on le verra plus loin. Dans un mode de réalisation préféré, le terminal 1 comprend une mémoire dans laquelle sont pré-enregistrées des données numériques d'un automate de formatage de table 30. L'annexe III retranscrit partiellement un automate de formatage en langage JAVA, capable de générer une liste hiérarchisée en langage XML à partir des tables de données Tl à T4. Bien entendu, l'automate de formatage qui est retranscrit en annexe fait intervenir des classes JAVA et, le cas échéant, d'autres programmes JAVA, non retranscrits ici. L'automate de formatage 30 permet de générer un document au format XML, ici la liste hiérarchisée 31, et de valider ce document XML sous le contrôle d'un fichier de définition de type de document 35 (fichier DTD du type précité). L'annexe IV retranscrit le contenu d'un fichier de définition de type de document adapté pour éditer des listes hiérarchisées en correspondance de rubriques de menus affichées dans la barre de menus BM sur l'écran ECR. Le fichier DTD 35 est préférentiellement transmis avec les tables de données Tl à T4, du serveur 2 au terminal 1. En variante, le fichier DTD peut être stocké en mémoire du terminal 1. Par ailleurs, l'utilisateur du terminal peut saisir, à partir d'un organe de commande approprié du terminal, un profil d'utilisateur qu'il choisit. Les données de profil d'utilisateur 32 sont ainsi entrées en mémoire du terminal 1. Lorsque le terminal reçoit les tables de données Tl à T4, le cas échéant avec l'automate de formatage des tables 30 et le fichier DTD 35, le terminal 1 (en particulier avec des moyens de calcul tels qu'un processeur approprié et une mémoire de travail RAM en coopération) génère une liste hiérarchisée 31 dont le contenu est modifié ou actualisé en fonction du profil d'utilisateur mémorisé par le terminal 1. En se référant à la figure 5A, la liste hiérarchisée 31, initialement au format XML, a été interprétée et éditée sous la forme d'un fichier ACCESS". On remarque avantageusement la structure arborescente de la liste qui commence par une déclaration de l'application interactive portant l'identifiant "3". Ensuite, un n#ud racine portant l'identifiant "1" est le n#ud père d'une pluralité de n#uds successifs portant les identifiants "2" à "13". A cette pluralité de n#uds successifs correspondent donc les rubriques du menu principal "Main List" qu'affiche l'écran de la plate-forme d'exécution ECR, en tant que portail d'accueil Préférentiellement, on prévoit un jeu de tables de données par niveaux successifs d'applications interactives (passage d'une rubrique à une sous-rubrique). En effet, en se référant à la figure 7B, l'application interactive se déroule dans l'exemple représenté, sur trois niveaux, ainsi un premier niveau "Level 0" correspond à une barre de menus de type portail d'accueil. Le jeu de tables transmises Table 0 est retranscrit à l'annexe I. En particulier, la table des n#uds comporte les rubriques principales du portail d'accueil, dont la rubrique "Programmes TV". Ainsi, lorsque l'utilisateur actionne un bouton de commande pour afficher le portail d'accueil, le terminal 1 a déjà capturé dans le signal hertzien distribué cycliquement les tables de l'annexe I, le cas échéant un dossier média pour l'habillage graphique et le fichier DTD de l'annexe IV. La liste hiérarchisée résultant du formatage des tables de l'annexe I est donnée en langage XML à l'annexe V. La liste hiérarchisée ainsi générée correspond à un fichier "MenuO.XML". Seules les deux premières pages de ce fichier XML sont retranscrites en annexe V. Avantageusement, les tables du portail d'accueil sont capturées systématiquement en mémoire du terminal 1, tandis que l'affichage du portail d'accueil est conditionné par l'actionnement d'une touche de la télécommande 11. En revanche, lorsque l'utilisateur commande l'affichage du portail d'accueil, le terminal 1 capture en mémoire les tables correspondant au niveau inférieur "Level 1" dans l'application interactive distribuée. En effet, on tient compte ici d'un retard induit par la période de capture effectuée par le terminal. Ainsi, même si l'utilisateur ne demande l'affichage que d'une rubrique du menu du portail d'accueil, le terminal capture au préalable et charge en mémoire toutes les tables de données relatives à toutes les rubriques du portail d'accueil, de manière à ne pas retarder l'affichage d'une rubrique particulière du portail d'accueil que sélectionnerait ensuite l'utilisateur. L'annexe II retranscrit le jeu de tables de données Table 01 du niveau "Level 1" pour générer une liste hiérarchisée correspondant à la rubrique "Programme TV". Cette liste hiérarchisée se présente sous la forme d'un fichier XML portant le nom "Menu01.XML", dont les deux premières pages seulement sont retranscrites à l'annexe VI. Comme indiqué ci-avant, les autres tables du niveau "Level 1" sont aussi chargées et d'autres listes peuvent être générées, par exemple une liste relative à la rubrique "Actualités" (fichier Menu02.XML), on encore une rubrique "Sports" (Ficher Menu03.XML). Finalement, si l'utilisateur sélectionne la rubrique "Programme TV", le terminal 1 capture alors toutes les tables de données du niveau inférieur "Level 2" et relatives aux sous-rubriques de la rubrique mère "Programme TV". Bien entendu, on peut prévoir une capture de plusieurs niveaux successifs, selon la "profondeur" du terminal, c'est-à-dire suivant ses capacités de mémoire et de traitement. En principe, à chaque actionnement d'une touche de la télécommande 11 par l'utilisateur, correspond un couple évènement/action qui peut être défini en tant qu'attribut dans une table d'attributs T3 capturée par le terminal au préalable. En se référant à nouveau à la figure 3, la liste hiérarchisée 31 (par exemple dans un langage XML ou HTML) est interprétée (encadré 33) par un interpréteur JAVA approprié. On prévoit en outre (encadré 34) une bibliothèque de fichiers exécutables (dits "pluggings") pour lire les fichiers du dossier média 36 pour l'habillage graphique des rubriques sur l'écran ECR. En variante du mode de réalisation représenté sur la figure 3, les tables de données Tl à T4 peuvent être préparées en tête de réseau. De plus, l'automate de formatage de table peut être prévu en tête de réseau, avec le fichier DTD, de manière à générer la liste hiérarchisée au niveau de la tête de réseau. Cette liste hiérarchisée peut être prévue initialement dans un langage XML et encodée pour être envoyée au terminal par le réseau hertzien. Dans ce cas, le terminal ne comporte qu'un interpréteur JAVA de la liste et les pluggings pour interpréter les fichiers des dossiers média envoyés. Néanmoins, ce mode de réalisation est moins avantageux dans la mesure où l'utilisateur du terminal ne peut pas programmer directement son profil au niveau du terminal. Dans un premier mode de réalisation, l'habillage graphique de la zone Z1 de l'écran de la plate-forme d'exécution ECR s'effectue indépendamment de l'habillage graphique de la barre de menus dans la zone inférieure Z2 de l'écran d'affichage ECR. Pour cela, on prévoit un dossier média comprenant les fichiers multimédia précités (portant la référence 36 sur la figure 3), ainsi qu'un fichier de définition de type de document (non représenté sur la figure 3) propre à l'habillage graphique de la zone supérieure Zl de l'écran ECR. L'annexe VII retranscrit un tel fichier de définition de type de document. Pour chaque page d'application interactive, on déclare des objets (image, texte, son, clip vidéo ou autre) et leurs différents états (normal, sélectionné, surbrillant, caché, ou autre). On déclare en outre un automate des interactions (flèche haut, flèche bas, flèche droite, flèche gauche) ce qui permet de naviguer au sein même de la zone supérieure Zl de l'écran (par exemple pour atteindre et sélectionner un pictogramme et démarrer ainsi une séquence sonore ou vidéo). Dans ce fichier de définition de type de document, on déclare en outre une organisation graphique des objets dans la zone Zl de l'écran ECR. Le fichier XML résultant du formatage sous le contrôle du fichier de définition de type de document de l'annexe VII est retranscrit en annexe VIII. Avantageusement, ce fichier en langage XML comprend des liens vers des fichiers multimédia du dossier Media 36, ainsi que des chaînes de caractères alphanumériques pour éditer des textes dans la zone Zl supérieure de l'écran ECR. Seules les deux premières pages de ce fichier XML sont retranscrites dans l'annexe VIII. Dans un second mode de réalisation, plus avantageux, on prévoit un fichier DTD commun pour l'habillage graphique de la zone Zl et pour la déclaration des rubriques dans la zone Z2 du menu d'application interactive. De même, on prévoit un habillage graphique dans la zone Zl en correspondance d'une rubrique sélectionnée dans le menu de l'application interactive mise en #uvre. La liste hiérarchisée est alors générée à partir des tables de données Tl à T4, la table des attributs T3 comprenant des chemins d'accès au dossier média, ainsi qu'une définition de l'organisation graphique des objets dans la zone Zl et une définition d'un automate des interactions (une définition de couple événement/action). Selon ce second mode de réalisation, l'annexe IX retranscrit une liste hiérarchisée au format XML qui est une variante du fichier "MenuO.XML" de l'annexe V. Ainsi, cette liste hiérarchisée est représentative du portail d'accueil de l'application interactive. Avantageusement, dans cette variante, chaque rubrique du portail d'accueil est répertoriée avec un chemin d'accès vers une page au format HTML (lien "URL"). Ces pages HTML comprendront avantageusement des chemins d'accès vers des fichiers multimédia du dossier média 36 et des chemins d'accès vers d'autres pages HTML relatives à des sous-rubriques. Dans ce qui suit, on décrit une actualisation du contenu d'un menu d'application interactive, par exemple par commande d'un profil d'utilisateur mémorisé dans le terminal 1. Une condition choisie ici pour qu'un n#ud devienne un élément d'une liste hiérarchisée, après formatage, est que ce n#ud ait le même père que les autres éléments de la liste. Ainsi, en modifiant l'identifiant ID~PN de la table Tl des n#uds, on peut ajouter ou supprimer un élément d'une liste. De la même manière, il est facile d'ajouter ou de supprimer un élément et ses attributs associés en modifiant le paramètre ID~N dans la table T2 des contenants d'informations. On peut ajouter ou supprimer des données relatives à un contenant d'informations en modifiant la valeur du paramètre ID~E1 dans la table T3 des attributs. En se référant à la figure 5B, l'identifiant du n#ud père associé aux rubriques "Actualités" et "Vos Magazines" a été modifié et une valeur prédéterminée lui a été attribuée ("10 000" dans l'exemple décrit). Ce code de valeur numérique indique que les rubriques précitées ne seront pas affichées, ni accessibles, lors de la mise en #uvre de l'application interactive sur la plate-forme d'exécution. De même, les sous-rubriques de ces rubriques "Actualités" et "Vos Magazines" n'apparaîtront pas dans la liste hiérarchisée. En effet, en se référant à la figure 5C, les rubriques portant les identifiants "4" et "6" n'apparaissent plus. On se réfère maintenant à la figure 4 pour décrire une arborescence modifiée selon un profil d'utilisateur choisi. Dans l'exemple, une application interactive 1 est mise en #uvre (encadré 41) . Un n#ud racine NO propose un portail d'accueil avec une pluralité de rubriques (encadré 42). Parmi les rubriques habituelles, il est prévu par exemple une rubrique "e-mails" (portant l'identifiant "9" dans la figure 5C). Si le terminal de l'utilisateur n'est pas agencé pour recevoir des messages électroniques de type e-mail, le n#ud N1 correspondant (encadré 43 de la figure 4) est supprimé. En pratique, on peut attribuer un code "10 000" à l'identifiant du n#ud père de ce n#ud "email" dans la table Tl des noeuds. Par ailleurs, si l'utilisateur sélectionne un profil parental choisi, des classes de contenants d'informations peuvent être supprimées (encadrés 45 et 46 de la figure 4). Dans ce cas, l'identifiant du n#ud N2 (encadré 44) dans la table des contenants d'informations T2 sera affecté d'une valeur "10 000". Dans une réalisation à base d'une implémentation complète en langage XML, le terminal est avantageusement équipé d'un analyseur syntaxique (ou parseur XML avec API pour Application Protocol Interface ), lequel permet de supprimer le n#ud complet correspondant à la rubrique e-mail ou certains n#uds de la rubrique profil parental (et leurs n#uds et attributs sousjacents) . Par ailleurs, certains terminaux peuvent ne pas être équipés de mémoire suffisante ou de capacité de traitement suffisante pour lire des séquences vidéo relativement longues. Dans ce cas, les attributs relatifs à de telles séquences vidéo (par exemple des liens vers le fichier de déclaration d'habillage graphique de l'annexe VIII) peuvent être supprimés (encadré 49 de la figure 4). De la même manière, l'identifiant de contenant d'informations dans la table T3 des attributs est affecté d'une valeur "10 000", pour cet attribut "Attr2" (encadré 49 de la figure 4). En revanche, pour d'autres attributs tels que "Attrl" (encadré 48), l'identifiant du contenant d'informations dans la table T3 des attributs est affecté d'une valeur correcte, qui correspond bien au contenant d'informations correspondant dans la table T2 (contenant d'informations E3 de l'encadré 47). Finalement, le terminal, en lisant et en interprétant la liste hiérarchisée ainsi générée, se comporte véritablement comme un ordinateur muni d'un système d'exploitation qui lui est propre, de façon parfaitement autonome. Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci-avant à titre d'exemple. Elle s'étend à d'autres variantes. Ainsi, on comprendra que les listes hiérarchisées peuvent se présenter sous la forme de fichiers au format XML, mais encore sous d'autres formes de fichiers tels qu'une page HTML, ou encore une page texte ou scripte, susceptible d'être interprétée par un interpréteur JAVA adéquat. Dans les annexes respectives I et II, les tables de données sont regroupées sous la forme d'un seul fichier. Un caractère "retour ligne" peut être interprété pendant le formatage comme une séparation des données des tables. En variante, on peut prévoir un fichier (texte ou script) par table. Par ailleurs, les listes hiérarchisées retranscrites en annexe sont au format XML. En variante, il peut s'agir de pages HTML. Bien entendu, les applications interactives peuvent être distribuées par un réseau hertzien comme décrit ci-avant, ou encore par un réseau câblé, ou autre. De manière plus générale, la présente invention ne se limite pas aux applications pour télévision numérique, mais encore à toutes applications mettant en #uvre des menus hiérarchisés. ANNEXE I TableO Table t~Appl "1" ; "Metalistfrench" Table t~N "01" ;"0";"1";"Menu0";"niveau0" illir ; liolit ;iijit ;"ProgrammeTV";"niveau0l' "10" ;"01";"1";"Quitter";"niveau0" "2";"Ol";"1";"Programmeradio";"niveau0" "10" ;"01";"1";"Quitter";"niveau0" "4" ;"01";"1";"Sports";"niveau0" "5" ;"01";"1";"Vosmagazines";"niveau0" "6" ;"01";"1";"Vielocale";"niveau0" n 7 ii ; n o i " ; i ; "ViePrat ique " ; "niveauO "8" ;"01";"1";"Email";"niveau0" "9" ;"01";"1";"Internet";"niveau0" Table t~El "100";"10";"Lquitter";"contenerlogique" "101";"10";"Equitter";"contenerEdito" "102";"10";"Nquitter";"contenernavigation" "103";"10";"Nquitter";"contenernavigation" "11" ;"1";"Ltv";"contenerlogique" "12" ;"1";"Etv";"contenerEdito" "13" ;"1";"Ntv";"contenernavigation" "21";"2";"Lradio";"contenerlogique" "22";"2";"Eradio";"contenerEdito" "23";"2";"Nradio";"contenernavigation" "31";"3";"Lactualite";"contenerlogique" "32";"3";"Eactualite";"contenerEdito" "33";"3";"Nactualite";"contenernavigation" "41";"4";"Lsport";"contenerlogique" "42";"4";"Esport";"contenerEdito" "43";"4";"Nsport";"contenernavigation" "51";"5";"Lmagazine";"contenerlogique" "52";"5";"Emagazine";"contenerEdito" "53";"5";"Nmagazine";"contenernavigation" "61";"6";"Llocal";"contenerlogique" "62";"6";"Elocal";"contenerEdito" "63";"6";"Nlocal";"contenernavigation" "71";"7";"Lpratique";"contenerlogique" "72" ;"7";"Epratique";"contenerEdito" "73";"7";"Npratique";"contenernavigation" "81";"8";"Lemail";"contenerlogique" "82";"8";"Eemail";"contenerEdito" "83";"8";"Nemail";"conternernavigation" "91";"9";"Linternet";"contenerlogique" "92";"9";"Einternet";"contenerEdito" "93";"9";"Ninternet";"contenernavigation" Table t Attr "1100";"0";"11";"date";"27/11/2001";"date" "1111";"0";"11";"descriptionetatl";"Programmes TV";"texte" "1112";"1111";"11";"descriptionetat2";"PROGRAMMES TV";"texte" "1113";"1111";"11";"descriptionetat3";"programmes TV";"texte" "1121" ;"0";"11";"position";"1";"nombre" "1122";"1121";"11";"scrollmount";"200";"pixels" "1123";"1121";"11";"scrolldelay";"10";"ms" "1124";"1111";"11";"police";"helvetica";"caractere" "1125";"1111";"11";"taille";"16";"caractere" "1126";"1111";"11";"style";"gras";"stylecaractere" "1127";"1111";"11";"couleur";"0,0,0";"couleurRVB" "1128";"1111";"11";"background";"10,10,10";"couleurRVB" "1130";"1131";"11";"PiCtoetat2";"plCtOZOOml.jpg";"image" "1131";"0";"11";"Pictoetatl";"pictonormall.gif";"image" "1132";"1131";"11";"Pictoetat3";"pictoeteintl.gif";"image" "1500";"0";"12";"urleditohtml";"programmetv.html";"url" "1501"-"0"-"13" "urlmetalistdtdStvdbml" "menu01.xm1"-"url" "1502";"1500";"12";"descriptionedito";"description éditorial programme Tv";"texte" "1503";"1500";"12";"date";"date de mise à jour de l'édito programme Tv";"date" "1504";"0";"12";"urleditoxml";"programmetv.xml";"url" "1505";"0";"12";"urleditogif";"programmetv.gif";"image" "1506";"1504";"12";"descriptionxml";"description suivant la DTD de l'habillage zone l""Tvi.dtd""";"texte" "1507";"1501";"13";"description";"Url du pivotnavigation suivant DTD ""STVDbml.dtd""Element Application, ElementNoeud, Element Element,Element Attribut";"texte" "1508"-"0";"13";"urlmetalistbis";"menubis0l.xml";"url" "1509";"1508";"13";"description";"Url de pivotnavigation suivant un formatsimple";"texte" "1510";"1505";"12";"description";"autre type de présentation de la partie éditoriale de l'habillage zone 1 sous forme d'une image codée gif";"texte" "4100";"0";"41";"date";"27/11/2001";"date" "4111";"0";"41";"descriptionetatl";"Sports";"texte" "4112";"4111";"41";"descriptionetat2";"SPORTS";"texte" "4113";"4111";"41";"descriptionetat3";"sports";"texte" "4121" ;"0";"41";"position";"4i";"nombre" "4122";"4121";"41";"scrollmount";"200";"pixels" "4123";"4121";"41";"scrolldelay";"10";"mS" "4124""4111""41""police""helvetica""caractere" "4125";"4111";"41";"taille";"16";"caractere" "4126";"4111";"41";"style";"gras";"stylecaractere" "4127";"4111";"41";"couleur";"0,0,0";"couleurRVB" "4128";"4111";"41";"background";"10,10,10";"couleurRVB" "4130";"413l";"41";"Pictoetat2";"pictozooml.jpg";"image" "4131";"0";"41";"Pictoetatl";"pictonormall.gif";"image" "4132";"4131";"41";"Pictoetat3";"pictoeteintl.gif";"image" "4500";"0";"42";"urleditohtml";"programmetv.html";"url" "4501" floit ;1143";"urlmetalistdtdStvdbml";"menuO4.xml";"url" "4502";"4500";"42";"descriptionedito";"description éditorial sport";"texte" "4503";"4500";"42";"date";"date de mise à jour de 1' éditorial sport";"date" "4504";"0";"42";"urleditoxml";"sport.xml";"url" "4505";"0";"42";"urleditogif";"sport.gif";"image" "4506";"4504";"42";"descriptionxml";"description suivant la DTD de l'habillage zone 1""Tv.dtd""";"texte" "4507";"4501";"42";"description";"Url du pivotnavigation suivant DTD ""STVDbml.dtd""Element Application, ElementNoeud, Element Element,Element Attribut";"texte" "4508" "0";"42";"urlmetalistbis";"menubis04.xml";"url" "4509";"4508";"42";"description";"Url de pivotnavigation suivant un formatsimple";"texte" "4510";"4505";"42";"description"; "autre type de présentation de la partie éditoriale de la zone 1 sous forme d'une image codée gif";"texte" ANNEXE II TableOl Table t~Appl "1" ;"Metalistfrench" Table t~N "01" ;"0";"1";"Menunl";"niveau01" "1" ; "01" ; "1" ; "maintenant"; "niveauOl" "10" ;"01";"1";"suivant";"niveau01" "2" ;"01";"1";"cesoir";"niveau01" "3" ;"01";"1";"grille";"niveau01" "4" ;"01";"1";"themes";"niveau01" "5" ;"01";"1";"mosaique";"niveau01" "6" ;"01";"1";"cineatTV";"niveau01" "7";"01";"1";"selectionportail";"niveau0l" "8" ;"01";"1";"retour";"niveau01" Table t~El "11" ;"1";"Lmaintenant";"contenerlogique" "12" ;"1";"Emaintenant";"contenerEdito" "13";"1";"Nmaintenant";"contenerNavigation" "21";"2";"Lsuivant";"contenerlogique" "22";"2";"Esuivant";"contenerEdito" "23";"2";"Nsuivant";"contenerNavigation" "31";"3";"Lcesoir";"contenerlogique" "32";"3";"Ecesoir";"contenerEdito" "33";"3";"Ncesoir";"contenerNavigation" Table t Attr "1100";"0";"11";"date";"27/11/2001";"texte" "1111" 11011 "11" ;"descriptionetatl"; "Maintenant"; "texte" "1112";"1111";"11";"descriptionetat2";"Maintenant";"texte" "1113";"1111";"11";"descriptionetat3";"maintenant";"texte" "1121";"0";"11";"position";"1";"nombre" "1122";"1121";"11";"scrollmount";"200";"pixels" "1123";"1121";"11";"scrolldelay";"10";"ms" "1124";"1111";"11";"police";"helvetica";"caractere" "1125";"1111";"11";"taille";"16";"caractere" "1126";"1111";"11";"style";"gras";"stylecaractere" "1127";"1111";"11";"couleur";"0,0,0";"couleurRVB" "1128";"1111";"11";"background";"10,10,10";"couleurRVB" "1130";"113l";"11";"Pictoetat2";"pictozooml.jpg";"image" "1131";"0";"11";"Pictoetatl";"pictonormall.gif";"image" "1132";"1131";"11";"pictoetat3";"pictoeteintl.gif";"image" "1500" "0"-"12"-"urleditohtml" "maintenant.html" "url" "1501""0"-"13";"urlmetalistdtdStvdbml";"menu010.xml";"url " "1502";"1500";"12";"descriptionedito";"description éditorial maintenant";"texte" "1503";"1500";"12";"date";"date de mise à jour de l'édito maintenant";"date" "1504"-"0"-"12";"urleditoxml";"maintenant.xml";"url" "1505";"0";"12";"urleditogif";"maintenant.gif";"image" "1506";"1504";"12";"descriptionxml";"description suivant le format pivot du pivotdisplay suivant DTD ""Tvi.dtd""" ;"texte" "1507";"1501";"13";"description";"Url du pivotnavigation suivant DTD ""STVDbml.dtd"" Element Application, ElementNoeud, Element Element,Element Attribut";"texte" "1508" "0""13";"urlmetalistbis";"menubisOl0.xml";"url" "1509";"1508";"13";"description";"Url de pivotnavigation suivant un formatsimple";"texte" "1510";"1505";"12";"description";"autre type de présentation de la partie éditoriale dans la zone zl sous forme d'une image codée gif";"texte" ANNEXE III import java.sql.*; import java.io.*; import org.apache.xerces.dom.*; import org.apache.xerces.parsers.*; import java.util.*; import java.lang.*; import org.xml.sax.*; import org.log4j.*; import fr.TDF.SApplication.extractor.extractorException.*; import org.apache.xml.serialize .*; // START OF MODIFIABLE ZONE@OBJID@32810@1703936116:1616@N@Descriptor@Javadoc // END OF MODIFIABLE ZONE@OBJID@32810@1703936116:1616@E@Descriptor@Javadoc public class Extractor extends fr.TDF.SApplication.extractor.ExtractEventListener // START OF MODIFIABLE ZONE@OBJID@33056@1703936116:1786@N@Descriptor@Javadoc /** * STVDbFactory * Objet encapsulant le connecteur */ // END OF MODIFIABLE ZONE@OBJID@33056@1703936116:1786@E@Descriptor@Javadoc protected fr.TDF.SApplication.extractor.STVDbFactory STVDbFactoryPart; public fr.TDF.SApplication.extractor.STVDbFactory getSTVDbFactoryPart () { return this.STVDbFactoryPart; public void setSTVDbFactoryPart (fr.TDF.SApplication.extractor.STVDbFactory value) this.STVDbFactoryPart = value; } public int cardSTVDbFactoryPart () { if ( this.STVDbFactoryPart == null ) return 0; else return 1; // START OF MODIFIABLE ZONE@OBJID@36418@1703936116:3271@N@Descriptor@Javadoc /** * Document de sortie au format STVDbML */ // END OF MODIFIABLE ZONE@OBJID@36418@1703936116:3271@E@Descriptor@Javadoc protected static org.apache.xerces.dom.DocumentImpl STVDbDocPart; public org.apache.xerces.dom.DocumentImpl getSTVDbDocPart () { return this.STVDbDocPart; } public void setSTVDbDocPart (org.apache.xerces.dom.DocumentImpl value) this.STVDbDocPart = value; public int cardSTVDbDocPart () if ( this.STVDbDocPart == null ) return 0; else return 1; // START OF MODIFIABLE ZONE@OBJID@33137@1703936116:1827@N@Descriptor@Javadoc /** EExtractEventListener * @param evt ExtractEvent attrapé */ // END OF MODIFIABLE ZONE@OBJID@33137@1703936116:1827@E@Descriptor@Javadoc public void CatchEvent( fr.TDF.SApplication.extractor.ExtractEvent evt) { // START OF MODIFIABLE ZONE@OBJID@33154@1703936116:1830@T // Start Trace cat.info("Evenement atrappe par un objet de la classe" + this.getClass().getName()); // End Trace try Class fact = Class.forName(evt.classeSTVDbFactory); STVDbFactoryPart = (STVDbFactory)fact.newInstance(); STVDbFactoryPart.setUri(evt.srcData); // Start Trace cat.debug(IISTVDbFactory cree"); cat.debug("classe . " + fact.getName()); cat.debug("Uri . " + STVDbFactoryPart.getUri()); // End Trace } catch (java.lang.ClassNotFoundException e) cat.error(e.toString()); System.out.println(e.toString()); System.exit(l); } catch (java.lang.InstantiationException e) cat.error(e.toString()); System.out.println (e.toString()); System. exit (1) ; catch (java.lang.IllegalAccessException e) cat.error(e.toString()); System.out.println(e.toString()); System.exit(l); } try { // Start Trace cat.info("Lancement de la creation d'un document"); // End Trace STVDbDocPart = STVDbFactoryPart.CreateDoc(evt.srcData); catch (DocValideException e) cat.error(e.toString()); System.out.println(e.toString()); System. exit (1) ; try cat.info("Document valide"); cat.info("Serialisation du document"); OutputFormat format = new OutputFormat(); format.setEncoding("ISO-8859-1"); format.setIndenting (true); format.setIndent (100); format.setLineSeparator("\n"); format.setLineWidth(O); format.setMethod(Method.FOP); XMLSerializer serialiser = new XMLSerializer(new FileOutputStream(evt.cibleData), format); serialiser.serialize(STVDbDocPart); cat.info("Document Serialisé"); catch (IOException e) { System.out.println(e.toString()); } // END OF MODIFIABLE ZONE@OBJID@33154@1703936116:1830@E } ANNEXE IV ID~Application CDATA #REQUIRED name CDATA #IMPLIED > ID~Noeud CDATA #REQUIRED ID~Pere CDATA #REQUIRED ID~Application CDATA #REQUIRED name CDATA #IMPLIED Niveau CDATA #REQUIRED > ID~Element CDATA #REQUIRED ID~Noeud CDATA #REQUIRED ClassElement CDATA #REQUIRED name CDATA #IMPLIED > ID~Attr CDATA #REQUIRED ID Pere CDATA #IMPLIED ID Element CDATA #IMPLIED Type CDATA #REQUIRED name CDATA #REQUIRED valeur CDATA #IMPLIED > ANNEXE V MenuO.xml 27/11/2001 200 10 Programmes TV helvetica 16 gras 0,0,0 10,10,10 PROGRAMMES TV programmes TV pictonormall.gif pictozooml.jpg pictoeteintl.gif menubisOl.xml Url de pivotnavigation suivant un formatsimple ANNEXE VI MenuOl.xml 27/11/2001 200 10 Maintenant helvetica 16 gras 0,0,0 10,10,10 Maintenant maintenant pictonormall.gif pictozooml.jpg pictoeteintl.gif menubisi010.xml Url de pivotnavigation suivant un format simple ANNEXE VII ...................................................... -> ...................................................... -> - Enriched the Page and tvi tags with background type and source (added a background at tvi level). - Added meta informations - Added tvi and page level event~hooks --> default-state in IMPLIED form)--> DEFINITIONS ENTITY : DATA Type ANNEXE VIII true false labell Une page Afp 255,255,255 Arial,2,32 Afp obj486 true true Arial Narrow,3,20 192,192,192 128,128,128 4 Page l true true suitedeladepeche SUITE Arial,1,14 "/> ANNEXE IX O 0 Programmes Tv Description programmetv du portail @TV programmetv.html /> 16 novembre 2001 1 1 Programmes radios description des programmes radios du portail @TV programmesradio.html /> 16 novembre 2001 2 2 Actalités Accès aux pages html d'actualités du portail @TV actualites.html /> 16 novembre 2001 3 3 sports Acces aux pages sports du portail @TV sports.html /> 16 novembre 2001 4 4 Vos Magazines accès à la première page de vos magazines du portail @TV magazine.html /> 16 novembre 2001 5 5 vielocale accès à la première page de vos magazines du portail @TV local.html /> 16 novembre 2001 6 6 vie pratique accès à la première page de vos magazines du portail @TV pratique.html /> 16 novembre 2001 7 7 vie pratique accès à la première page de vos magazines du portail @TV pratique.html /> 16 novembre 2001 8 8 emails accès à la première page du service d'emails email.html /> 16 novembre 2001 9 9 internet accès au portail wanadoo http://www.voila.fr/ /> 16 novembre 2001 10 10 Quitter Comment quitter le portail @TV s'il n'y pas d'url c'est la dernière url qui est sauvegardée / /> 16 novembre 2001 REVENDICATIONS 1. Procédé de réalisation d'applications interactives, une partie au moins des applications interactives, distribuées sur un canal de transmission numérique, étant destinées à être installées sur une plate-forme d'exécution pour mettre en #uvre une succession de rubriques thématiques sous forme de menu, dans lequel : - on prépare des tables de données (T1,T2,T3,T4) comprenant au moins, pour chaque rubrique courante d'un menu, un identifiant d'un n#ud correspondant à cette rubrique courante et un identifiant d'un n#ud père correspondant à une rubrique mère de cette rubrique courante dans le menu, - et l'on génère, à partir des données des tables, une liste comprenant au moins des éléments descriptifs des n#uds et hiérarchisée selon un arbre logique dont les n#uds sont positionnés en fonction desdits identifiants de n#uds. 2. Procédé selon la revendication 1, dans lequel on génère une liste principale comportant plusieurs sous-listes hiérarchiquement imbriquées selon ledit arbre logique et comprenant, pour chaque n#ud, des éléments respectivement descriptifs : - de la position de ce n#ud dans l'arbre logique, - de contenants d'informations d'une rubrique correspondant à ce n#ud, - et d'attributs associés à chaque contenant d'informations, et dans lequel les tables de données comportent : - une première table de données relatives à des positions de n#uds dans l'arbre logique (t~N), comprenant pour chaque n#ud au moins : # l'identifiant de ce n#ud (ID~N), # l' identifiant du n#ud père de ce n#ud (ID~PN), # et un nom attribué à ce n#ud (Name), - une seconde table de données relatives aux contenants d'informations (t~El), comprenant pour chaque contenant au moins : # un identifiant de ce contenant (ID~E1), # l'identifiant du n#ud auquel est associé ce contenant (ID~N) , # et un nom de contenant (Name), - et une troisième table de données relatives à des attributs associés aux contenants d'informations (t~Attr), comportant pour chaque attribut au moins : # un identifiant de cet attribut (ID~Attr), # l'identifiant du contenant auquel est associé l'attribut (ID~E1), # et un nom de l'attribut (Name). 3. Procédé selon la revendication 2, dans lequel : - ladite liste principale comporte en outre des éléments descriptifs d'applications interactives dans lesquelles interviennent un ou plusieurs n#uds, - lesdites tables de données comportent une quatrième table de données relatives aux applications interactives (t~Appl), comprenant pour chaque application interactive : # un identifiant de cette application interactive (ID~Appl) , # ainsi qu'un nom attribué à cette application interactive (Name), - et la première table de données comprend en outre, pour chaque n#ud, l'identifiant de l'application interactive dans laquelle une rubrique associée à ce n#ud intervient (ID~Appl) . 4. Procédé selon la revendication 2, dans lequel on prévoit un jeu de première, seconde et troisième tables de données par application interactive. 5. Procédé selon l'une des revendications 3 et 4, dans lequel, chaque application interactive étant susceptible de s'étendre sur plusieurs niveaux successifs de rubriques : - la première table de données comprend en outre, pour chaque n#ud, des données relatives à un nom de niveau dans lequel intervient ce n#ud (Niveau), - et la liste hiérarchisée comprend en outre des éléments descriptifs de niveaux de n#uds. 6. Procédé selon l'une des revendications 2 à 5, dans lequel : les contenants d'informations sont répertoriés par classes thématiques (classEl), - la seconde table (t~El) comporte en outre des données relatives à un nom de classe thématique à laquelle appartient chaque contenant d'informations, - et la liste hiérarchisée comprend en outre des éléments descriptifs de classes de contenants. 7. Procédé selon l'une des revendications 2 à 6, dans lequel : - les attributs sont classés par types d'attributs choisis parmi un ensemble comprenant au moins : # une chaîne de caractères alpha-numériques (txt), # un chemin d'accès (URL) vers un composant d'habillage graphique et/ou sonore, # et un agrégat d'attributs (GrpAttr), - la troisième table comprend en outre des données relatives à un type d'attribut (Type), - et la liste hiérarchisée comprend en outre des éléments descriptifs de types d'attributs. 8. Procédé selon l'une des revendications 2 à 7, dans lequel la liste hiérarchisée comprend, d'une part, des éléments descriptifs de noms d'attributs et, d'autre part, des éléments descriptifs de valeurs d'attributs, et la troisième table comprend en outre des données relatives à une valeur de chaque attribut (Valeur). 9. Procédé selon l'une des revendications 2 à 8, dans lequel la sous-liste déclarative comprenant les éléments descriptifs d'attributs comporte des sous-listes secondaires d'éléments descriptifs d'attributs, imbriquées selon un arbre logique de n#uds d'attributs, et la troisième table (t~Attr) comprend en outre des données relatives à un identifiant d'un attribut père de chaque attribut (ID~PAttr). 10. Procédé selon l'une des revendications précédentes, dans lequel : - on prépare en outre un dossier de données d'informations (36) de contenus de rubriques et/ou d'habillage graphique et/ou sonore de rubriques, - et ladite liste hiérarchisée comprend en outre des descriptions de chemins d'accès vers des données dudit dossier. 11. Procédé selon la revendication 10, dans lequel ladite liste hiérarchisée comporte en outre au moins un chemin d'accès vers une liste secondaire comprenant des chemins d'accès vers des données dudit dossier. 12. Procédé selon l'une des revendications 10 et 11, dans lequel, chaque application interactive étant susceptible de s'étendre sur plusieurs niveaux successifs de rubriques (Level 0, Level 1, Level 2), on prépare un dossier de données d'informations (36) et l'on génère une liste hiérarchisée comprenant des chemins d'accès vers des données dudit dossier, pour chaque niveau d'une application interactive. 13. Système de réalisation d'applications interactives, comportant : - une tête de réseau (2,AS) agencée pour distribuer des signaux représentatifs d'applications interactives sur un canal de transmission numérique, - une plate-forme d'exécution (1,11,ECR,AT) agencée pour recevoir lesdits signaux et propre à installer lesdites applications interactives pour mettre en #uvre une succession de rubriques thématiques sous forme de menu, caractérisé en ce que la tête de réseau comporte : un éditeur de tables de données (Tl,T2,T3,T4) comprenant au moins, pour chaque rubrique courante d'un menu, un identifiant d'un n#ud correspondant à cette rubrique courante et un identifiant d'un n#ud père correspondant à une rubrique mère de cette rubrique courante dans le menu, - et un automate de formatage (AFT) capable de générer, à partir des données des tables, une liste comprenant au moins des éléments descriptifs des n#uds et hiérarchisée selon un arbre logique dont les n#uds sont positionnés en fonction desdits identifiants de n#uds. 14. Système selon la revendication 13, caractérisé en ce que la tête de réseau est agencée pour envoyer à la plateforme d'exécution les données desdites tables, ainsi que l'automate de formatage, en vue de générer ladite liste hiérarchisée au niveau de la plate-forme d'exécution. 15. Système selon la revendication 14, caractérisé en ce que la plate-forme d'exécution comporte des moyens de mise à jour des données desdites tables pour générer des menus en fonction d'un profil d'utilisateur du terminal (32). 16. Système selon la revendication 13, caractérisé en ce que la tête de réseau est agencée pour envoyer ladite liste hiérarchisée à la plate-forme d'exécution. 17. Système selon la revendication 16, caractérisé en ce que la tête de réseau comporte des moyens de mise à jour des tables de données et est agencée pour envoyer à la plate-forme d'exécution une liste hiérarchisée, mise à jour en fonction de spécificités dudit terminal choisies parmi un ensemble comprenant au moins une capacité mémoire du terminal, un accès conditionné à des rubriques prédéterminées de menu et un accès conditionné à des applications interactives prédéterminées. 18. Système selon l'une des revendications 15 et 17, caractérisé en ce que les données des tables sont initialement codées sous la forme d'un script de fichier texte, et en ce que les moyens de mise à jour comportent un éditeur de texte pour ajouter et/ou supprimer et/ou modifier des rubriques et/ou des contenus de rubriques de menu. 19. Système selon l'une des revendications 13 à 18, caractérisé en ce que la plate-forme d'exécution comprend des moyens d'interprétation (33) de ladite liste pour mettre en #uvre sur la plate-forme d'exécution un menu hiérarchisé en correspondance de la liste. 20. Système selon la revendication 19, caractérisé en ce que la tête de réseau est agencée pour envoyer à la plateforme d'exécution un dossier (36) comprenant des données d'informations de contenus de rubriques et/ou d'habillage graphique et/ou sonore de rubriques, en ce que ladite liste hiérarchisée comprend en outre des descriptions de chemins d'accès vers des données dudit dossier, et en ce que lesdits moyens d'interprétation sont agencés pour lire les chemins d'accès de ladite liste et comportent en outre des fichiers exécutables (34) pour mettre en #uvre le contenu de chaque rubrique du menu sur ladite plate-forme d'exécution, en correspondance d'un habillage graphique et/ou sonore décrit dans la liste hiérarchisée. 21. Système selon la revendication 20, caractérisé en ce que, chaque application interactive étant susceptible de s'étendre sur plusieurs niveaux successifs de rubriques, la tête de réseau est agencée pour envoyer à la plateforme d'exécution : - un dossier comprenant des données d'informations de contenus de rubriques et/ou d'habillage graphique et/ou sonore de rubriques, - une liste hiérarchisée comprenant des descriptions de chemins d'accès vers des données dudit dossier, ou un jeu de tables de données pour générer une telle liste, pour chaque niveau de l'application interactive (Level 0, Level 1, Level 2). 22. Structure de données pour développer des listes d'éléments descriptifs de rubriques et/ou de contenants de rubriques d'un menu d'applications interactives destinées à être installées sur une plate-forme d'exécution pour la mise en en #uvre d'une succession de rubriques thématiques sous forme de menu, caractérisée en ce qu'elle comporte une succession de balises déclaratives (DTD) comprenant au moins : - une déclaration de n#uds correspondants aux rubriques, - une déclaration d'éléments correspondants aux contenants de rubriques, - et une déclaration d'attributs associés aux contenants de rubriques. 23. Structure de données selon la revendication 22, caractérisée en ce qu'elle comporte en outre : - une première table de données (t~N) relatives à des positions de n#uds dans un arbre logique représentatif d'une arborescence du menu, comprenant pour chaque n#ud au moins : # l' identifiant de ce n#ud (ID~N), # l'identifiant du n#ud père de ce n#ud (ID~PN) # et un nom attribué à ce n#ud (Name), - une seconde table de données relatives aux contenants d'informations (t~El), comprenant pour chaque contenant au moins . # un identifiant de ce contenant (ID~E1), # l'identifiant du n#ud auquel est associé ce contenant (ID~N) , # et un nom de contenant (Name), une troisième table de données relatives à des attributs associés aux contenants d'informations (t~Attr), comportant pour chaque attribut au moins : # un identifiant de cet attribut (ID~Attr), # l'identifiant du contenant auquel est associé l'attribut (ID~E1), # et un nom de l'attribut (Name), et des moyens de formatage des données desdites première, seconde et troisième tables pour générer, sous le contrôle de ladite succession de balises déclaratives (DTD), une liste hiérarchisée selon ledit arbre logique et comprenant, pour chaque n#ud de l'arbre logique, des éléments respectivement descriptifs : - de la position de ce n#ud dans l'arbre logique, - de contenants d'informations d'une rubrique correspondant à ce n#ud, - et d'attributs associés à chaque contenant d'informations. 24. Structure de données selon l'une des revendications 22 et 23, caractérisée en ce que ladite succession de balises déclaratives est sous la forme d'un fichier de définition de type de document (DTD) suivant un métalangage (XML), et en ce que ladite liste hiérarchisée est sous la forme d'un métafichier (XML ; HTML) destiné à être lu et interprété sur une plate-forme d'exécution pour mettre en #uvre une arborescence de menu en correspondance de l'arbre logique de n#uds. 25. Structure de données pour développer des listes d'éléments descriptifs de contenus de rubriques d'un menu d'applications interactives destinées à être installées sur une plate-forme d'exécution pour la mise en en #uvre d'une succession de rubriques thématiques sous forme de menu, caractérisée en ce qu'elle comporte une succession de balises déclaratives (DTD) comprenant au moins : - une déclaration d'un objet en tant que contenu d'une rubrique (audio, vidéo, texte,...) - une déclaration d'un état de l'objet (sélectionné, sélectionnable, caché, ...) , - une déclaration d'un automate d'interactions susceptible de générer des couples événement/action propres à modifier l'état de l'objet. 26. Structure de données selon la revendication 25, caractérisée en ce qu'elle comporte en outre : - un dossier média (36) comprenant : # des données éditoriales de contenus de rubriques, # des fichiers parmi un ensemble comprenant au moins des fichiers sons, des fichiers images, des fichiers vidéo, des fichiers texte, des fichiers de polices de texte, - ainsi que des moyens de formatage des données du dossier média pour générer, sous le contrôle de ladite succession de balises déclaratives (DTD), au moins une liste (xml ; html) comprenant au moins une description d'un chemin d'accès à un fichier dudit dossier média et/ou une description d'un chemin d'accès à une autre liste. 27. Structure de données selon la revendication 26, caractérisée en ce que ladite succession de balises déclaratives est sous la forme d'un fichier de définition de type de document (DTD) suivant un métalangage (XML), et en ce que ladite liste est sous la forme d'un métafichier (xml ; html) destiné à être lu et interprété sur une plate-forme d'exécution pour mettre en #uvre le contenu d'au moins une rubrique sur ladite plate-forme d'exécution, en correspondance des données du dossier média. 28. Structure de données selon l'une des revendications 25 à 27, caractérisée en ce que ladite succession de balises déclaratives comprend en outre une déclaration d'une organisation graphique de l'objet pour éditer en correspondance le contenu de la rubrique sur la plateforme d'exécution.