Brevet FR2832578A1 — publié le 20030523

L'invention concerne un procédé de chargement d'un programme de navigation utilisable dans un réseau domestique, ainsi que le dispositif de chargement. Dans le monde informatique il existe des réseaux de tailles différentes. Certains réseaux comme Internet permettent de relier des millions de terminaux entre eux. La communication avec de tels réseaux s'effectue à l'aide de serveurs, les serveurs dialoguent entre eux à l'aide d'un protocole, HTTP par exemple, et s'échangent les requêtes et les réponses à ces requêtes. L'utilisateur qui est face à son terminal demande une information, celle-ci est fournie par un serveur sous la forme par exemple de pages d'écran écrit dans le langage HTML. L'élaboration de requête est facilitée par un programme appelé navigateur ou browser selon la terminologie anglaise, ou Web browser s'il s'agit d'un navigateur adapté à Internet. Chaque terminal qui dispose d'un tel programme peut interroger des serveurs distants et recevoir des pages d'écran affichables sur le terminal. Il existe aussi des réseaux dits domestiques. Ces réseaux permettent de communiquer d'une pièce à une autre au sein d'une habitation. Les différents éléments d'un réseau domestiques dialoguent entre eux soit par ondes radioélectriques, soit à l'aide de câbles électriques. Dans ce dernier cas, il existe plusieurs standards de bus de communication, par exemple ETHERNET ou 1394. Le protocole ETHERNET décrit des transmissions par trames dites HDLC de longueur variable, les informations sont modulées, il supporte également le protocole de communication IP. Les débits sur ce réseau sont typiquement de 100 Mbits par seconde, il est particulièrement bien adapté aux applications bureautiques et informatiques sans exigences de temps réel. Les transmissions par un bus 1394 s'effectue aussi à l'aide de fils électrique et un haut débit permettant notamment de transmettre de la vidéo. Un des protocoles qu'il est possible de mettre en oeuvre sur le réseau 1394 s'appelle HAVI, la dernière spécification HAVi a été publiée le 15 mai 2001, sous le titre The HAVI specification par l'organisation HAVi standardisation , c'est la version 1.1. A l'aide d'un réseau 1394, on peut relier entre eux des ordinateurs personnels, des terminaux audiovisuels, des écrans, des magnétoscopes, des disques durs ou lecteurs de disque DVD, des caméras,... en résumé tout appareil informatique ou audiovisuel. Pour bénéficier des avantages des deux standards de réseaux, on peut disposer au sein d'un réseau domestique, d'au moins deux réseaux dont les standards de communication sont différents. Un réseau domestique peut aussi être raccordé à un réseau extérieur, par une ligne téléphonique ou par un câble optique. Ainsi, un réseau 1394 peut dialoguer avec Internet à l'aide d'un élément appelé passerelle, ou gateway selon la terminologie anglaise. Le Gateway va transmettre les différentes requêtes provenant des appareils du réseau domestique, attendre la réponse et la transmettre à l'appareil du réseau domestique qui a élaboré la requête. Pour obtenir une réponse d'un réseau Internet, il faut élaborer la requête selon son langage, HTTP en l'occurrence. Le Gateway contient un programme serveur ou Web server qui construit les requêtes, les envoie au réseau Internet, puis reçoit les pages HTML et les transmet au Web Browser qui a lancé la requête. S'il veut avoir accès à un réseau extérieur, un terminal d'un réseau domestique doit disposer d'un Web browser qui est intégré au terminal. Ce terminal doit dialoguer avec le Gateway selon son protocole de communication, ce qui oblige le Gateway à posséder autant d'interfaces de communication qu'il y a de sous-réseaux. De plus, les terminaux du réseau domestique peuvent provenir de fabricants différents, ils n'intègrent pas toujours un Web Browser, ce qui empêche au moment de leur installation d'être immédiatement opérationnels. Certain protocole intègre dans leur spécification leurs propres interfaces graphiques (par exemple pour HAVi, une interface est appelée DDI , une autre basée sur l'utilisation du langage Java est appelée Level 2 Ul ). Ces interfaces sont différentes de HTML, de telle sorte qu'un appareil HAVi ne possède pas par défaut de Web browser, ni même de couches HTTP/TCP/IP. La présente solution vise à pallier aux inconvénients en permettant à un utilisateur de dialoguer avec un Web browser, quel que soit la configuration du réseau domestique et le type de terminal avec lequel il dialogue. L'objet de la présente invention est un procédé de téléchargement d'un module interface utilisateur au sein d'un réseau domestique comprenant un dispositif de communication avec un réseau extérieur (GATEWAY) et au moins deux sous-réseaux A et B sur lesquels sont connectés des appareils, le réseau A comprenant au moins un appareil doté d'un navigateur résident, le réseau B comprenant au moins un appareil doté d'une mémoire, caractérisé en ce que le dispositif de communication (GATEWAY) possède un moyen de réception de pages graphiques et un module d'interface utilisateur compatible avec le protocole du réseau B, et en ce qu'il comporte les étapes suivantes : - appel au niveau d'un terminal du réseau B d'un programme de navigation (Web Browser), - téléchargement du module d'interface utilisateur du dispositif de communication (GATEWAY) dans la mémoire du terminal, et lancement dudit module téléchargé, - affichage d'une page graphique au niveau du terminal B en réponse à une requête, la page graphique étant identique à celle affichée par au moins un terminal du réseau A lorsque la même requête est lancée au niveau de ce terminal. De cette façon, le terminal qui n'est pas muni au départ d'un Web Browser, reçoit du Gateway un module logiciel d'Interface utilisateur permettant d'élaborer des requêtes compatibles avec celles traitées par le réseau extérieur et d'afficher des pages en réponse à ces requêtes. La communication avec le Gateway est basée sur le protocole de communication de ce terminal. Cette solution permet de ne télécharger de module logiciel dans un terminal que si l'utilisateur en a besoin. Selon un premier perfectionnement, le procédé comprend une étape de réception d'une page graphique incorporant un module logiciel, et une étape de traitement du module logiciel par le module d'interface utilisateur préalablement chargé L'objet de la présente invention est aussi un système de communication comprenant au moins un premier terminal (A) et une Unité centrale reliés entre eux par un premier réseau domestique (Réseau A) et un second terminal (B) relié à l'unité centrale par un second réseau (Réseau B) dont le protocole est différent du premier, l'unité centrale comprenant un dispositif de communication vers un réseau extérieur et une application de navigation, le terminal B étant muni d'un programme d'affichage de page graphique faisant appel à l'application de navigation, le terminal (A) étant doté d'une mémoire ; caractérisé en ce que l'application de navigation contient un module d'interface utilisateur (Havlet) et un moyen d'émission du dudit module d'interface utilisateur vers le terminal (A), et en ce que le module d'interface utilisateur une fois téléchargé dans le terminal élabore des requêtes, charge et affiche sur un écran des pages d'écran graphique provenant du réseau extérieur en utilisant l'application de navigation, la page graphique étant identiquement affichée sur l'écran d'un terminal (A) que sur l'écran d'un terminal (B) lorsque la même requête est lancée au niveau des terminaux (A) et (B). L'invention, avec ses caractéristiques et avantages, ressortira plus clairement à la lecture de la description d'un exemple de réalisation particulier non limitatif fait en référence aux dessins annexés dans lesquels : - la figure 1 est un schéma d'un réseau domestique selon un exemple de réalisation, - la figure 2 est un schéma d'un exemple de réalisation d'un sousréseau du réseau domestique comprenant un terminal doté d'un Web Browser résident, - la figure 3 est un schéma d'un exemple de réalisation d'un sousréseau doté d'un terminal HAVi sans Web Browser, - la figure 4 est un schéma d'un exemple de réalisation du sousréseau HAVi montrant le téléchargement d'une Havlet pour disposer d'un Web Browser au niveau du terminal, - la figure 5 est un schéma d'une variante de l'exemple de réalisation d'un sous-réseau du réseau domestique montrant le téléchargement d'une Havlet, - la figure 6 présente un schéma d'un réseau domestique doté d'un cache selon un exemple de réalisation. La figure 1 montre un réseau domestique relié à un réseau extérieur. Le réseau domestique comprend deux sous-réseaux, l'un de type HAVi (réseau A), l'autre de type UPnP (acronyme de Universal Plug and Play ) (réseau B). Le premier réseau est plutôt destiné à relier entre eux des appareils audiovisuels tels qu'un téléviseur 1.1. 1 doté d'une télécommande, un magnétoscope 1.1. 2 ou une caméra 1.1. 3. Le second réseau est d'avantage orienté vers le monde informatique, il comporte un ordinateur personnel 1.2. 1, une imprimante 1.2. 2 et un appareil photo numérique 1.2. 3. Les deux réseaux 1.1 et 1.2 sont tous les deux connectés au Gateway 1.3 qui possède de son coté une liaison avec un réseau extérieur 1.4. Le Web server doit être au niveau du Gateway pour avoir accès à tous les sousréseaux que compose le réseau domestique. Le Web server communique avec un Web browser via le protocole HTTP, l'interface utilisateur téléchargée est écrite en HTML, mais peut comporter des extensions SCRIPT, ou applet. Il existe deux types de terminaux HAVi selon qu'il dispose d'un Web browser résident ou non, ce Web Browser traitant des données écrites en HTML. La figure 2 montre l'organisation des différents modules logiciels au niveau du sous-réseau 1394, dans le cas où le contrôleur HAVI possède un Web browser résident. Le schéma serait le même si le réseau appelé B est de type UPnP. Le Gateway contient une application appelée OSGi-OSGi est l'acronyme de Open Service Gateway initiative dont la fonction est de proposer un canevas architectural permettant de supporter une communication avec des structures telles que HAVi ou UPnP. L'application OSGi telle que décrite dans ce document contient une interface utilisateur qui est basée sur le langage HTML, les pages Web sont construites par l'application OSGi, stockées dans le Web serveur, puis envoyées du Web serveur au Web Browser du terminal HAVi qui les demande. L'interface utilisateur résidente dans le terminal HAVi affiche sur l'écran ces pages. La communication des requêtes de pages HTML du Web Browser au Web serveur s'appuie sur le protocole HTTP. La configuration est la même lorsqu'il s'agit d'un réseau IP classique, l'accès aux pages HTML est basé sur le protocole HTTP et le Web browser est résident dans le terminal IP. Les terminaux HAVI n'ont pas tous la possibilité de contenir un Web Browser. En effet, ces terminaux proviennent de plusieurs fabricants qui n'offre pas tous la possibilité de posséder un Web Browser intégré. On a dit précédemment qu'un terminal de base HAVi possède ses propres interfaces graphiques différentes de HTML, il ne possède donc pas de Web browser, ni même de couches HTTPITCPIIP. La figure 3 montre l'organisation des différents modules logiciels au niveau du sous-réseau 1394, dans le cas où le contrôleur HAVi ne possède pas un Web browser résident. Il faut cependant garantir qu'un utilisateur puisse voir de la même façon les pages HTML quel que soit le type du terminal. L'application OSGi permet d'accéder à des protocoles de type HAVi (représenté sur la figure 3 par Stack HAVi ) ou UPnP, IP (représenté sur la figure par Other Network Stack ), et donc permet de dialoguer à des sous-réseaux de types différents. L'application s'exécutant sur le gateway peut communiquer avec les deux sous-réseaux à la fois et donc contrôler n'importe quel appareil de ces deux sous-réseaux. L'application OSGi crée des pages écrites en HTML constituant l'interface utilisateur, les met à disposition à travers le Web server, qui les envoie sur requête au terminaux disposant d'un Web browser résident en utilisant un protocole HTTP. Les pages écrites en langage HTML sont affichées par le Web Browser du terminal. L'élément du Gateway appelé Web Proxy FCM est le module logiciel HAVi qui réalise la fonction de passerelle entre le terminal HAVi et le réseau extérieur, ce module identifie la fonction du Gateway pour tous les autres éléments du sous-réseau HAVi. Le Web Proxy FCM reçoit les requêtes provenant d'un terminal HAVi, appelle le Web serveur pour récupérer les informations (c'est le sens de la flèche entre le Web Server et le Web Proxy FCM), reçoit les réponses et les transmet en retour via le réseau HAVi. Au niveau du protocole HAVi, il n'existe pas d'IP sur HAVi, donc un terminal de type HAVi n'a pas accès à ces pages HTML à partir d'un écran connecté à un réseau de type HAVI. La solution selon le présent exemple de réalisation consiste à charger un Web browser dans un terminal HAVi. Cette solution est illustrée à la figure 4. La partie interface utilisateur va interagir avec la partie de l'application résidente dans le gateway, c'est à dire avec le Web server. Le présent exemple de réalisation prévoit le téléchargement de la partie interface utilisateur d'un Web Browser lorsque le terminal HAVi ne possède pas de Web Browser résident. Pour cela, le DCM (Device Control Module) représentant la Gateway contient une module logiciel d'Interface utilisateur Havlet , qui est un programme exécutable en byte-code JAVA. Etant un programme exécutable, il doit être téléchargé dans un terminal du réseau HAVi doté d'un interpréteur, selon la terminologie HAVi, un tel terminal s'appelle un HAVi FAV Device)). Cette Havlet constitue une interface utilisateur basée sur le langage Java. Cette havlet spécifique lance lors de son installation dans le HAVi FAV device un Web browser. Le présent exemple de réalisation permet de ne pas faire de changements dans la spécification HAVi pour supporter une communication directement au niveau TCP voire IP Une variante de réalisation consiste en ce que l'havlet du DCM de la Gateway peut être la même que celle contenue dans l'application OSGi. L'havlet quel que soit sa source est transférée du Gateway au HAVi FAV Device, grâce au protocole HAVi. L'installation de l'havlet permet d'installer un Web browser dans un HAVi FAV Device car lors du lancement de l'havlet, le Web browser contenu dans l'havlet est également lancé. Les pages graphiques HTML peuvent contenir un module logiciel permettant une animation au niveau de l'affichage, ou un lien vers d'autres pages. Ce module logiciel, appelé une applet est un programme écrit par exemple en langage JAVA, il est téléchargé dans le Web browser du terminal HAVI avec la page HTML. Cette applet peut ne faire que de la présentation (graphisme Java), mais elle peut aussi communiquer avec le Web server. Cette communication peut se faire avec HTTP mais une applet a aussi la possibilité de passer directement par la couche TCP (en-dessous de HTTP). Or le Web proxy tel qu'il est défini spécifie l'encapsulation de HTTP dans les messages HAVi mais pas de TCP (ni UDP, autre protocole de couche 4, ou même directement de IP, protocole de couche 3). Un présent perfectionnement du présent exemple de réalisation consiste à intégrer les paquets IP dans les messages HAVi. On a donc le paquet HTTP empaqueté dans le paquet TCP lui-même empaqueté dans le paquet IP, le tout étant transmis dans un paquet codé selon le protocole HAVi. Cependant, cette solution nécessite de modifier les spécifications HAVi car le Web proxy FCM ne sait pas traiter des messages http. L'application OSGi reste au niveau du Gateway, c'est uniquement l'interface utilisateur qui est téléchargée dans un HAVi FAV Device. Ceci permet de minimiser les transmissions d'information, et de déporter le traitement, la construction et le maintien des pages HTML s'effectuant au niveau du Gateway et l'affichage des pages au niveau du HAVi FAV Device. Le fait de disposer de la même interface quel que soit le réseau utilisé permet de la rendre homogène et garantie à l'utilisateur de dialoguer toujours avec la même interface. Le téléchargement s'effectue de la façon suivante. Le terminal HAVi dispose d'une application de navigation qui ne permet pas de lancer des requêtes mais qui contient un appel à un module de chargement de l'Havlet. L'utilisateur lançant l'application déclenche automatiquement le chargement de l'havlet si celle-ci n'est pas déjà en mémoire du terminal. Une fois que le programme exécutable de l'havlet est dans la mémoire, celui est exécuté et les pages d'introduction du Web Browser sont affichées. L'utilisateur peut alors introduire ses requêtes et les émettre vers la Gateway ou le réseau extérieur, de la même façon que si le terminal dispose d'un Web Browser résident. Lorsque l'utilisateur sort de l'application, celle-ci peut se fermer et la mémoire occupée peut être allouée à une autre application. Un second perfectionnement, illustrée à la figure 5 consiste en ce que l'application OSGi est déclarée en tant qu'application HAVi, de telle sorte que tout appareil HAVi connecté au réseau la reconnaisse. Une application HAVi est apte à fournir une havlet, de la même manière qu'un DCM. L'intérêt de se servir de l'havlet de l'application est qu'il n'y a plus besoin du module Web Proxy FCM., l'application appelée maintenant OSG/HAVi peut aussi accéder au protocole de type HAVi (représenté sur la figure par Stack HAVi ) ou UPnP, IP (représenté sur la figure par Other Network Stack ), et donc peut dialoguer avec des sous-réseaux de types différents. Ce perfectionnement offre une autre possibilité de la communication entre le Web browser et son application. On ne passe pas par les messages HAVi pour transmettre les informations entre le Web browser et l'application. On utilise un moyen de plus bas-niveau (selon les couches de communication standardisé OSI) qui est directement les paquets 1394. Pour cela, un module HAVi permet l'accès à ces paquets, c'est le CMM (Communication Media Manager). Cette communication utilise moins de données car elle diminue le nombre d'emboîtements des messages dus au passage à travers les différents niveaux de communication. Le dialogue entre l'havlet et son application se fait typiquement par des messages HAVi. Ce qui est contenu dans le corps des messages n'est pas standardisé et est donc entièrement sous le contrôle de l'application et de l'havlet. C'est pourquoi il est possible d'utiliser un moyen de transport des paquets HTTP dans les messages HAVI, de la même manière que ce que fait le Web Proxy FCM. Mais l'intérêt est qu'il est possible d'empaqueter dans les messages HAVi non plus HTTP mais directement les paquets TCP ou même IP. Et cela sans avoir à modifier le standard HAVi. Le perfectionnement favorise le fait qu'une applet est capable de passer directement par la couche TCP. L'utilisateur peut choisir de passer non plus des messages Havi mais directement 1394, à l'aide d'un CMM (Communication Media Manager). Ceci permet d'éviter un emboîtement des messages empaquetés selon les formats des différentes couches de communication traversées. Une autre possibilité pour la communication entre l'havlet et son application est de ne plus utiliser les messages HAVi comme moyen de transport sur le 1394, mais directement des messages 1394. Cela est possible dans HAVi grâce à un module appelé le CMM. Ce module fournit une interface aux autres modules HAVi pour utiliser les fonctionnalités basniveau du bus 1394. L'avantage d'un tel procédé est d'éviter la surcharge des emboîtements successifs et donc il en résulte une meilleure efficacité dans l'échange de messages entre l'havlet et son application. Un perfectionnement de la présente invention consiste à stocker dans un cache les pages HTML rapatriées par le HAVi FAV Device. Le cache est typiquement un disque dur connecté à l'un ou l'autre des sous-réseaux, tout autre moyen de mémorisation de grande capacité convient également, par exemple un disque optique re-inscriptible. Le mécanisme d'utilisation d'un cache permet de retrouver des pages HTML précédemment chargées d'un site Web par exemple, et ainsi éviter une nouvelle connexion lorsque l'utilisateur désire les faire apparaître de nouveau à l'écran. Ceci permet de retrouver plus rapidement l'information car la page à rechercher est dans la mémoire du réseau domestique, et donc il n'y a plus besoin d'aller la charger de l'extérieur. Selon la figure 6, la mémoire cache est une mémoire gérée par un programme de gestion (le File Manager selon la terminologie anglaise), par exemple relié au disque dur. Selon un premier mode de réalisation, le Web Proxy envoie les pages téléchargées au terminal pour être affichées et au cache pour les mémoriser. La mémorisation s'effectue en spécifiant le terminal qui est à l'origine de la requête de façon que ce même terminal puisse retrouver facilement en interrogeant le cache les pages précédemment chargées. Selon un autre mode de réalisation, la requête de mémorisation dans le cache est fournit par le Web Browser du terminal. Le File Manager du cache gère donc la fonction cache des terminaux HAVi qui possèdent un Web browser téléchargé. Plusieurs File Manager peuvent coexister sur le réseau HAVi et se partager le cache. Une variante consiste en ce que l'appareil de l'utilisateur contient son propre cache et enregistre localement les pages HTML téléchargées, il n'y a alors plus besoin de faire appel à un cache global au réseau. Cette variante évite notamment d'encombrer le réseau car l'information se trouve directement dans le terminal. REVENDICATIONS 1. Procédé de téléchargement d'un module interface utilisateur au sein d'un réseau domestique comprenant un dispositif de communication (GATEWAY) avec un réseau extérieur et au moins deux sous-réseaux A et B dont les protocoles sont différents et sur lesquels sont connectés des appareils, le réseau B comprenant au moins un appareil doté d'un navigateur, le réseau A comprenant au moins un appareil doté d'une mémoire ; caractérisé en ce que le dispositif de communication (GATEWAY) possède un moyen de réception de pages graphiques et un module d'interface utilisateur compatible avec le protocole du réseau A, et en ce qu'il comporte les étapes suivantes : - appel au niveau d'un terminal du réseau A d'un programme de navigation (Web Browser), - téléchargement du module d'interface utilisateur du dispositif de communication (GATEWAY) dans la mémoire du terminal du réseau A, et lancement dudit module téléchargé, - affichage d'une page graphique au niveau du terminal A en réponse à une requête, la page graphique étant identique à celle affichée par au moins un terminal du réseau B lorsque la même requête est lancée au niveau de ce terminal. 2. Procédé de téléchargement selon la revendication 1 caractérisé en qu'il comporte une étape de réception d'une page graphique incorporant un module logiciel, et une étape de traitement du module logiciel par le module d'interface utilisateur préalablement chargé. 3. Procédé de téléchargement selon la revendication 1 ou 2 caractérisé en qu'il comporte une étape de mémorisation dans un dispositif (CACHE) connecté au dispositif de communication (GATEWAY) des pages graphiques reçues du réseau extérieur et affichées sur le terminal A. 4. Système de communication comprenant au moins un premier terminal (A) et une Unité centrale (GATEWAY) reliés entre eux par un premier réseau domestique (Réseau A) et un second terminal (B) relié à l'unité centrale par un second réseau (Réseau B) dont le protocole est différent du premier, l'unité centrale comprenant un dispositif de communication vers un réseau extérieur et une application de navigation, le terminal B étant muni d'un programme d'affichage de page graphique faisant appel à l'application de navigation, le terminal (A) étant doté d'une mémoire ; caractérisé en ce que l'application de navigation contient un module d'interface utilisateur (Havlet) et un moyen d'émission du dudit module d'interface utilisateur vers le terminal (A), et en ce que le module d'interface utilisateur une fois téléchargé dans le terminal élabore des requêtes, charge et affiche sur un écran des pages d'écran graphique provenant du réseau extérieur en utilisant l'application de navigation, la page graphique étant identiquement affichée sur l'écran d'un terminal (A) que sur l'écran d'un terminal (B) lorsque la même requête est lancée au niveau des terminaux (A) et (B). 5. Système de communication selon la revendication 4 caractérisé en ce que le module d'interface utilisateur comporte un moyen d'exécution d'un module logiciel intégré à au moins une page graphique reçue, ledit module logiciel lançant une requête dans un format déterminé, ladite requête est empaqueté par le module d'interface utilisateur pour être transmis à l'unité de traitement qui la transfère ensuite au réseau extérieur. 6. Système de communication selon la revendication 4 ou 5 caractérisé en ce qu'il comporte un moyen de mémorisation des pages graphiques chargées par les terminaux du réseau A à la suite de requêtes élaborées par le module d'interface utilisateur.