TRANSMISSION D ' UN CONTENU MULTIMEDIA VERS UN TERMINAL DE RADIOCOMMUNICATION

1. Domaine de l'invention

5 Le domaine de l'invention est celui de la restitution de contenus multimédia sur un terminal de radiocommunication, par exemple de type radiotéléphone, PDA (en anglais « Personal Digital Assistant », en français « assistant numérique personnel »), ordinateur portable, etc.

Plus précisément, l'invention repose sur la transmission d'un contenu 10 multimédia, d'une portion de ce contenu, et/ou d'éléments représentatifs de celui- ci, vers un terminal de radiocommunication.

On entend notamment par contenu multimédia un ensemble composé d'au moins une scène graphique animée, encore appelée scène multimédia, et d'une série de commandes permettant de faire évoluer cette scène d'un état à un autre. 15 Une scène multimédia correspond notamment à l'agencement d'un ensemble d'objets graphiques dans le temps et dans l'espace, avec lesquels l'utilisateur du terminal de radiocommunication peut interagir.

L'invention trouve des applications dans tous les domaines nécessitant une représentation des signaux sous forme d'un agencement spatio-temporel d'objets 20 graphiques, avec interactivité.

Notamment, l'invention s'applique aux formats de description de scènes graphiques déjà connus tels que le MPEG-4/BIFS (en anglais « Binary Format Scène », en français « format binaire pour scène »), le SVG (en anglais « Scalable Vector Graphics », en français « graphiques vectoriels adaptables »), le SMIL (en 25 anglais « Synchronized Multimedia Intégration Language », en français « langage d'intégration multimédia synchronisés »), le XHTML (en anglais « extensible HyperText Markup Language », en français « langage de balisage hypertexte extensible »), etc.

2. Art antérieur

30 Des techniques de transmission d'un contenu multimédia vers un terminal

de radiocommunication sont déjà connues.

Classiquement, selon une première technique de transmission, la conception d'un service, c'est-à-dire l'offre d'une information à un utilisateur d'un terminal de radiocommunication, met en œuvre le schéma suivant : - un contenu initial est envoyé sur le terminal ; l'utilisateur le consomme, et fait une requête ; un contenu de réponse est alors envoyé sur le terminal de radiocommunication, etc.

Le service est donc conçu comme une suite de contenus envoyés au terminal de l'utilisateur en réponse à des requêtes interactives.

Par exemple, si l'utilisateur demande un service météo, le contenu initial envoyé sur le terminal comprend les prévisions météorologiques pour la journée.

L'utilisateur le consomme, c'est-à-dire lit les prévisions météorologiques pour la journée, et fait une requête pour obtenir les prévisions météorologiques pour le lendemain.

Un nouveau contenu de réponse, comprenant les prévisions météorologiques pour le lendemain, est alors envoyé sur le terminal de radiocommunication, ce nouveau contenu remplaçant le contenu initial dans la mémoire du terminal. Selon cette première technique de transmission, chaque contenu de réponse envoyé comprend une scène entière, représentative du contenu requis, alors que dans le cadre de l'exemple précité, seuls les pictogrammes de description du temps qu'il fera seront modifiés, les autres objets graphiques composant la scène multimédia de présentation des prévisions météo restant inchangés (par exemple la carte de France sous jacente).

Par conséquent, un inconvénient majeur de cette première technique de l'art antérieur est qu'elle nécessite le téléchargement d'une scène entière en réponse à une requête de l'utilisateur, même s'il n'y a que peu de modifications entre le contenu initial et le contenu de réponse. Le téléchargement du contenu de réponse correspond donc au moins en

partie à du temps gaspillé, ce qui est coûteux en termes de ressources de transmission, d'autant plus que les services multimédia interactifs pour terminaux de radiocommunication disposent de la plus faible bande passante des réseaux mobiles (de l'ordre d'une dizaine de kilobits par seconde), et souffrent de l'exemple « interactif » de l'Internet grande vitesse.

De plus, le fait de charger une nouvelle scène introduit une rupture pour l'utilisateur : un éventuel contexte d'interactions locales est alors perdu, ainsi que d'éventuelles préférences d'utilisation. En effet, selon cette technique de l'art antérieur, le contenu initial est intégralement remplacé par un nouveau contenu. Par conséquent, lors d'une rupture d'une session de communication suivie d'un rétablissement de la session, il peut être nécessaire de charger de nouveau le contenu initial, par exemple pour retrouver les préférences d'utilisation de l'utilisateur.

Il existe par ailleurs d'autres techniques de transmission d'un contenu multimédia vers un terminal de radiocommunication.

Ainsi, selon une seconde technique, des commandes de scène permettent de créer des scènes qui sont ensuite envoyées progressivement vers le terminal de radiocommunication.

De telles commandes sont notamment définies dans les formats de description BIFS et LASeR (en anglais « Lightweight Application Scène Représentation », en français « Représentation de scènes applicatives légères »), tels que définis dans le document ISO/IEC 14496-20:2006, publié courant 2006, dont une version provisoire est disponible sous la référence MPEG N7480 : « Study Text of ISO/IEC 14496-20/FCD ». Ces commandes de scène permettent ainsi de commencer à jouer une scène avant la fin de son téléchargement, si les commandes sont envoyées dans l'ordre temporel croissant.

Cependant, un inconvénient de cette seconde technique est qu'elle nécessite également le chargement complet d'une scène entière en réponse à une interaction de l'utilisateur, même si selon cette technique le terminal de

radiocommunication peut commencer à jouer la scène pendant son téléchargement.

De plus, comme illustré en relation avec la figure 2A, la scène initiale 211 restituée par le terminal est remplacée, au fur et à mesure de la transmission du contenu multimédia, par une première scène mise à jour 22 \, puis une deuxième scène mise à jour 231, puis une troisième scène mise à jour 24 \, .... Le terminal perd ainsi la connaissance de la scène initiale, puisque la dernière scène mémorisée dans le terminal correspond à la dernière scène mise à jour (par exemple la troisième scène mise à jour 24 \). Ainsi, un inconvénient majeur de cette technique est qu'en cas d'interruption puis de rétablissement de la transmission, le terminal doit de nouveau charger la scène initiale, notamment si l'utilisateur souhaite récupérer ses préférences et/ou un éventuel contexte d'interactions locales.

Finalement, une troisième technique connue de transmission d'un contenu multimédia vers un terminal de radiocommunication est présentée.

Selon cette technique, le lecteur multimédia (terminal de radiocommunication) dispose d'un interprète d'un langage de programmation, par exemple de type ECMAScript ou Java (marques déposées). La scène comprend un script complexe qui se connecte à un serveur, implémente un protocole d'échange de données avec le serveur (analyse syntaxique -« parsing » en anglais- d'un document XML si les données échangées avec le serveur sont en XML par exemple) et construit des éléments dans la scène en fonction des données reçues.

Cette troisième technique revient à implémenter un équivalent des commandes de scènes à l'intérieur même du script de la scène. Cependant, cette technique n'est pas applicable aux terminaux mobiles actuels, puisque très peu de terminaux disposent de l'environnement, des ressources ou des performances nécessaires pour la mettre en œuvre.

De plus, un inconvénient majeur de cette technique est qu'elle engendre un coût d'implémentation élevé, et compte tenu des ressources actuelles, elle ne peut s'appliquer qu'aux scènes simples, comprenant des objets graphiques simples

effectuant peu de mouvements.

D'autres inconvénients de cette technique de l'art antérieur résident encore dans la taille du contenu, la complexité de la création du contenu, et l'interdépendance entre les contenus et les serveurs implémentant la même variante de protocole d'échange de données.

En effet, un contenu contenant un script de traitement du protocole d'échange de données avec le serveur a une taille minimale (hors scène proprement dite) d'environ 1000 à 40000 octets. La variabilité de la taille du script provient notamment de la possibilité de mettre en oeuvre des protocoles de type « XML », plus volumineux en termes de taille, ou binaires, moins volumineux, et de prévoir des protocoles plus ou moins complets en terme de nombre de commandes de modification de scène possibles.

Ainsi, la complexité de création d'un contenu selon cette technique de l'art antérieur est plus importante que celle d'un simple contenu « passif », c'est-à-dire sans script.

Enfin, un autre inconvénient de cette troisième technique est que pour être capable de servir des données à un tel contenu, le serveur doit implémenter le protocole d'échange de données utilisé par le contenu qu'il doit servir. Le serveur doit donc être le cas échéant modifié ou remplacé par un autre serveur, pour être adapté à un contenu utilisant un autre protocole d'échange de données.

3. Objectifs de l'invention

L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur.

Plus précisément, un objectif de l'invention est de fournir une technique de transmission d'un contenu multimédia vers un terminal de radiocommunication ne nécessitant pas le téléchargement de scènes complètes en réponse à une interaction.

Un autre objectif de l'invention est de mettre en œuvre une telle technique permettant de réduire le temps de réponse aux interactions par rapport aux techniques de l'art antérieur, notamment en cas d'interruption(s) dans la session

de communication.

Notamment, l'invention a pour objectif de fournir une telle technique présentant de meilleures performances en termes de fluidité des services au niveau du terminal de radiocommunication. L'invention a encore pour objectif de fournir une telle technique de transmission nécessitant peu de ressources en termes de bande passante.

Encore un autre objectif de l'invention est de fournir une telle technique permettant la réalisation de terminaux multimédia simples et peu coûteux, ne nécessitant pas de moyens de traitement importants, ni de gros moyens de mémorisation des données.

4. Exposé de l'invention

Ces objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints à l'aide d'un procédé de transmission d'un contenu multimédia d'un serveur à destination d'un terminal de radiocommunication, ledit contenu comprenant au moins une scène multimédia, dite scène initiale, et une série de commandes permettant de faire évoluer ladite scène initiale.

Selon l'invention, le procédé de transmission comprend :

- une étape de transmission du serveur vers le terminal d'une portion initiale du contenu, comprenant au moins la scène initiale ; - une étape de mémorisation suivie d'une étape de restitution de la portion initiale sur le terminal ;

- au moins une étape de transmission du serveur vers le terminal d'une portion complémentaire du contenu, sous la forme d'un complément d'au moins une portion précédemment reçue par le terminal, en réponse à une requête provenant du terminal ;

- une étape de mémorisation de la portion complémentaire, suivie d'une étape de restitution par le terminal de la scène multimédia mise à jour selon la requête, à partir des portions précédemment reçues.

Ainsi, l'invention propose une approche tout à fait nouvelle et inventive de la transmission d'un contenu multimédia vers un terminal de radiocommunication

reposant sur la transmission d'une portion initiale du contenu, puis sur la transmission de portions complémentaires du contenu, correspondant à des compléments ou différences, entre une ou plusieurs portions précédemment reçue(s) par le terminal (par exemple la portion initiale), suite à une requête du terminal.

De cette façon, le terminal peut restituer la scène multimédia mise à jour, en combinant le complément avec la scène initiale ou une scène multimédia précédemment mise à jour,

On remarque notamment que les étapes de transmission et de mémorisation de la portion complémentaire, et de restitution par le terminal de la scène multimédia mise à jour, peuvent être répétées autant de fois que nécessaire, et autant de fois qu'il y a de requêtes et donc de portions complémentaires de contenu.

En particulier, la portion initiale comprend au moins une commande de la série de commandes.

L'invention permet ainsi de structurer le contenu multimédia représentatif d'un service transmis à un terminal de radiocommunication, de manière à ce qu'une portion initiale du contenu, comprenant au moins la scène initiale et éventuellement des commandes de mise à jour de la scène initiale, soit d'abord transmise au terminal. Ensuite, en réponse à une première requête, une portion complémentaire est transmise au terminal sous la forme d'un complément de la portion initiale, permettant de restituer la scène multimédia mise à jour en réponse à la requête. Si une nouvelle requête est émise à destination du serveur, une autre portion complémentaire est transmise au terminal sous la forme d'un complément d'au moins une portion précédemment reçue par le terminal, permettant de restituer la scène multimédia mise à jour en réponse à la nouvelle requête, et ainsi de suite.

Ainsi, en structurant les services sous forme de portions successives de contenu, on transmet une suite de portions incrémentales de taille réduite par rapport aux techniques de l'art antérieur, ce qui permet de réduire le temps de

réponse des services mobiles.

Le flux vers le terminai de radiocommunication est donc constitué d'une suite de compléments, ou différences, entre les états successifs de la scène multimédia. Ce flux est réparti selon l'invention dans les différentes portions de contenus.

La technique selon l'invention permet ainsi d'obtenir un gain en temps de réponse aux interactions, et un gain en efficacité du service pour l'utilisateur et l'opérateur, puisqu'on obtient le même résultat (même contenu), en téléchargeant moins de données. L'invention offre ainsi une impression de continuité et de fluidité du service puisque celui-ci est conçu sous forme de modifications successives d'une scène multimédia, ainsi qu'une grande économie de temps puisque seule la modification du contenu courant est envoyée au terminal.

De plus, par rapport aux techniques reposant sur l'utilisation d'un script complexe se connectant à un serveur, et nécessitant l'utilisation d'un interprète de langage de programmation de type ECMAScript ou Java (marques déposées) par exemple, l'invention permet l'utilisation d'un lecteur multimédia nécessitant moins de ressources, donc disponible sur des terminaux de communication, par exemple des téléphones, moins coûteux. Par ailleurs, une portion de contenu étant plus simple et de taille réduite par rapport aux techniques de l'art antérieur, le coût de sa création et son temps de transmission sont moins élevés.

Finalement, tandis que selon la technique antérieure de type ECMAScript le serveur et le script du contenu multimédia implémentent nécessairement le même protocole de transmission d'information, l'invention permet une interopérabilité entre tous les serveurs et les contenus.

On considère également qu'un « complément » transmis dans une portion complémentaire comprend des commandes de modification de scène permettant de faire évoluer une scène courante vers une scène mise à jour en fonction d'une requête issue du terminal.

Ainsi, le terminal peut stocker dans un contexte local la portion initiale, comprenant la scène initiale et éventuellement des commandes permettant de faire évoluer cette scène, et les différents compléments transmis au fur et à mesure du serveur vers le terminal. Ce contexte local est donc incrémenté des différentes commandes transmises dans les portions complémentaires.

Par conséquent, tandis que selon l'art antérieur tel qu'illustré en figure 2A la scène initiale évolue, dans la mémoire du terminal, au cours des différentes mises à jour transmises par le serveur en réponse aux différentes requêtes d'un utilisateur, le terminal conserve toujours selon l'invention à sa disposition la scène initiale et les commandes permettant une mise à jour de la scène multimédia, dans un contexte local.

Par conséquent, en cas de rupture et de rétablissement d'une session de communication, il n'est pas nécessaire que le serveur re-transmette la scène initiale et/ou les commandes de modifications au terminal. En particulier, cette solution permet un travail « hors ligne », dans le sens où un utilisateur peut se déconnecter et se reconnecter sans perte d'informations.

A titre d'exemple, si on considère une scène initiale composée de plusieurs onglets, par exemple un onglet « Informations », un onglet « Cinéma », et un onglet « Musique », l'utilisateur du terminal peut choisir l'onglet « Cinéma », conduisant à l'affichage des programmes de cinéma de la semaine. Une fois le contenu restitué sur l'afficheur (par exemple un écran) du terminal, l'utilisateur ou (directement le terminal) peut choisir de se déconnecter (c'est-à-dire passer en mode « hors ligne »), le temps pour l'utilisateur de consulter le programme.

Le contexte local selon l'invention comprend alors la scène initiale, et une commande de modification de l'onglet affiché en « Cinéma ».

On considère que l'utilisateur souhaite ensuite regarder les informations du jour, en choisissant l'onglet « Informations ». Le terminal revient donc en mode

« en ligne », encore appelé mode connecté. Le contexte local comprend alors la scène initiale, la commande de modification de l'onglet affiché en « Cinéma », et une commande de modification de l'onglet « Cinéma » en « Informations ».

Selon l'art antérieur, le terminal a mis à jour dans sa mémoire la scène initiale lors du choix de l'onglet « cinéma », et l'a remplacée par les programmes de cinéma de la semaine. Le terminal doit donc envoyer une requête au serveur, lui demandant de lui transmettre de nouveau la scène initiale. On perd donc le contexte d'interactions locales.

Selon l'invention, le terminal dispose toujours en mémoire du contexte local, et peut donc rapidement retrouver les différentes commandes permettant de passer de la scène initiale, à la dernière scène restituée avant déconnexion.

Suite à la requête du terminal, le serveur n'a donc pas à transmettre de nouveau la scène initiale. Il lui suffit de transmettre au terminal une portion complémentaire, sous la forme d'un complément de la portion initiale permettant de mettre à jour la scène multimédia. En particulier, ces compléments sont prédéfinis par l'auteur, ou le programme du service, et ne sont pas calculés par le serveur. Le terminal peut alors restituer la scène multimédia mise à jour selon la requête de l'utilisateur, c'est-à-dire développer l'onglet « Informations », à partir de la portion initiale et de la portion complémentaire (et éventuellement d'autres portions complémentaires précédemment reçues par le terminal).

En particulier, un intérêt du passage en mode connecté/déconnecté réside dans la rapidité et dans le traitement simultané d'un nombre accru de requêtes. En effet, si tous les utilisateurs maintiennent leur connexion avec le serveur en permanence, c'est-à-dire si le service est conçu comme une scène unique du début à la fin du service, recevant des modifications au cours du temps, alors le nombre limite de clients que le serveur peut servir est N. En revanche, si les utilisateurs coupent la connexion après chaque réponse reçue du serveur, et rétablissent une connexion pour recevoir la prochaine réponse du serveur, alors le serveur n'est limité qu'à N requêtes simultanées.

En particulier, la requête provenant du terminal est une requête d'un utilisateur du terminal, ou une requête consécutive à la restitution de la scène multimédia mise à j our.

Ainsi, les compléments en réponse à ces requêtes peuvent être prédéfinis lors de la création ou le stockage du contenu multimédia dans le cadre d'une requête consécutive à la restitution de la scène. Par exemple, si un utilisateur clique sur un onglet « météo de demain », une fois la météo du lendemain restitué, un bouton « météo d'aujourd'hui » apparaît.

Les requêtes peuvent également provenir d'un utilisateur, conduisant à un découpage dynamique des compléments à transmettre au terminal.

Selon une variante de l'invention, le procédé de transmission de l'invention met en œuvre au moins deux voies de transmission distinctes, ou des sessions de transport différentes (voire avec des protocoles de transport différents), pour les différentes portions de contenu.

Ainsi, le complément transmis étant simple et demandant peu de ressources de transmission, la portion complémentaire peut être transmise sur des réseaux à faible débit. En particulier, la portion initiale du contenu est transmise à l'aide d'un canal à haut débit (par exemple via le réseau Internet) et/ou préalablement stockée dans le terminal.

Selon une variante de réalisation, les portions (portions initiales et/ou complémentaires) sont contenues dans des documents séparés sur le serveur. Par exemple, ces documents sont de type pages « Web », ou sont des contenus génériques de type « streamés » ou diffusés (« broadcastés »).

Par exemple, l'auteur (ou le programme du service) créé directement un contenu A, puis un autre document noté contenu C, tel que le contenu C soit défini comme la différence entre un contenu B et le contenu A (contenu C= contenu B - contenu A).

Selon ce mode de réalisation de l'invention, c'est le terminal qui reconstitue virtuellement le contenu B dans sa mémoire. Ainsi, le contenu B n'est pas mémorisé dans le serveur.

En particulier, ces documents séparés sont référencés par des adresses qui peuvent être distinctes, et peuvent être reçus par des moyens de transport de

données différents.

Selon un mode de réalisation particulier, le serveur transmet également au terminal un signal de configuration de la scène multimédia de type « Append » du format « LASeR ». Ce signal permet notamment d'avertir le terminal que les commandes qui lui sont envoyées sont des commandes de modification d'éléments d'une scène, et non une scène entière à télécharger.

Les commandes permettant de faire évoluer la scène sont, selon ce mode de réalisation particulier, des commandes de scène « LASeR Commands ». Un autre aspect de l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, comprenant des instructions de code de programme pour la mise en œuvre du procédé de transmission d'un contenu multimédia décrit précédemment. Encore un autre aspect de l'invention concerne encore un signal de transmission d'un contenu multimédia vers un terminal de radiocommunication, comprenant au moins deux portions de contenu, dont une portion initiale et au moins une portion complémentaire, ladite portion complémentaire étant transmise audit terminal sous la forme d'un complément d'au moins une portion précédemment reçue par ledit terminal, en réponse à une requête provenant dudit terminal.

Il est à noter que, dans un autre mode de réalisation, la portion initiale et les portions complémentaires peuvent être transmises sous forme indépendante, par exemple dans des canaux distincts, selon des protocoles de transport distincts, ...

Un autre aspect de l'invention concerne par ailleurs un terminal de radiocommunication destiné à recevoir un contenu multimédia, comprenant :

- des moyens de réception d'une portion initiale du contenu, comprenant au moins la scène initiale, et d'au moins une portion complémentaire du contenu, reçue sous la forme d'un complément d'au moins une portion

précédemment reçue par le terminal, en réponse à une requête provenant dudit terminal ;

- des moyens de mémorisation de la portion initiale et de la portion complémentaire ; - des moyens de restitution de la portion initiale et de la scène multimédia mise à jour selon la requête, à partir des portions précédemment reçues. En particulier, les moyens de réception du terminal sont adaptés à recevoir une pluralité de portions de contenu transmises suivant au moins deux voies de transmission distinctes. Encore un autre aspect de l'invention concerne un procédé de restitution d'un contenu multimédia dans un terminal de radiocommunication, comprenant une étape de mémorisation d'un ensemble d'au moins une scène initiale, et au moins une itération des étapes suivantes : émission d'une requête vers un serveur de diffusion d'un contenu multimédia ; réception d'un complément de la scène multimédia restituée par ledit terminal en réponse à ladite requête; détermination par ledit terminal de la scène multimédia mise à jour, combinant des données représentatives de ladite scène initiale ou d'une scène multimédia précédemment mise à jour, et dudit complément ; affichage de ladite scène multimédia mise à jour.

Finalement, un autre aspect de l'invention concerne un serveur de diffusion d'un contenu multimédia vers au moins un terminal de radiocommunication, comprenant :

- des moyens de transmission d'une portion initiale dudit contenu, comprenant au moins ladite scène initiale ;

- des moyens de traitement d'une requête ;

- des moyens de transmission d'une portion complémentaire dudit contenu, sous la forme d'un complément d'au moins une portion précédemment

reçue par ledit terminal, en réponse à ladite requête provenant dudit terminal.

5. Liste des figures

D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente le principe général de l'invention, selon lequel le contenu multimédia à transmettre vers le terminal de radiocommunication est découpé en au moins deux portions dont une portion initiale et au moins une portion complémentaire, la portion initiale étant d'abord transmise au terminal, puis une portion complémentaire étant transmise au terminal en réponse à une requête venant du terminal ; - les figures 2A (déjà commentée en relation avec l'art antérieur) et 2B présentent la scène initiale et ses mises à jour respectivement selon l'art antérieur et selon un mode de réalisation particulier de l'invention ; les figures 3A, 3B et 3C illustrent respectivement la scène initiale, une mise à jour de la scène initiale telle que restituée sur le terminal suite à une requête, et la portion complémentaire transmise par le serveur correspondant à ladite requête , selon la figure 1 ; la figure 4 présente une partie de la structure du terminal selon un mode de réalisation particulier de l'invention. 6. Description d'un mode de réalisation de l'invention

Le principe général de l'invention repose sur le partitionnement d'un contenu multimédia, comprenant au moins une scène multimédia et une série de commandes permettant de faire évoluer cette scène, en au moins deux portions, dont une portion initiale et au moins une portion complémentaire. Une première portion de contenu, dite portion initiale, est tout d'abord

transmise au terminal de radiocommunication. Ensuite, une portion dite complémentaire est transmise au terminal de radiocommunication, en réponse à une requête venant du terminal.

L'invention permet ainsi de reconstruire des scènes multimédia interactives donnant une impression de fluidité du service, tout en réduisant la quantité de données téléchargées par le terminal.

Le découpage du contenu multimédia à transmettre en scènes incrémentales permet également de réaliser une économie importante sur les serveurs. En effet, un serveur est habituellement limité au traitement de N clients en parallèle, le nombre N étant dépendant de la puissance de la machine, de la complexité du service, etc.

Si tous les utilisateurs maintiennent leur connexion avec le serveur en permanence, c'est-à-dire si le service est conçu comme une scène unique du début à la fin du service, recevant des modifications au cours du temps, alors le nombre limite de clients que le serveur peut servir est N.

En revanche, si les utilisateurs coupent la connexion après chaque réponse reçue du serveur, et rétablissent une connexion pour recevoir la prochaine réponse du serveur, alors le serveur n'est limité qu'à N requêtes simultanées. Le nombre de clients servis par un serveur est alors beaucoup plus important, d'un facteur lié au rapport entre le temps de transmission de la portion complémentaire et le temps moyen entre interactions utilisateurs, rapport qui peut dépasser 100.

Plus précisément, selon un mode de réalisation particulier de l'invention, la portion complémentaire transmise comprend un complément, sous la forme d'une commande de modification globale de scène, comprenant des commandes de modification d'au moins un élément de la scène (« LASeR Commands ») au format « LASeR ».

Selon une variante de ce mode de réalisation, une commande de modification globale de scène comprend également un signal de configuration de scène de type « append ». Ce mode « append » est défini classiquement dans la

norme LASeR pour indiquer qu'une scène courante ne comprend pas de scène initiale, mais seulement une suite de commandes applicables à la scène déjà chargée dans le terminal.

Les utilisateurs peuvent alors couper la connexion avec le serveur puisque ce dernier dispose du mode « append », qui permet selon l'invention de signaler que la réponse doit être ajoutée à la scène courante.

Par ailleurs, les serveurs ne pouvant conserver indéfiniment une session client ouverte, ils sont classiquement obligés de considérer qu'un client silencieux, c'est-à-dire n'émettant aucune requête à son attention, est automatiquement déconnecté au bout d'un temps donné.

Selon l'invention, le découpage du contenu multimédia à transmettre en scènes incrémentales permet au serveur de couper la connexion immédiatement, et de rétablir une connexion après un temps arbitrairement long.

On présente désormais un mode de réalisation particulier de l'invention, selon lequel la portion complémentaire transmise comprend une commande de modification globale de scène, comprenant des commandes de modification d'au moins un élément de la scène (« LASeR Commands »), au format « LASeR ».

Les commandes de scène, encore appelées commande de modification d'un élément de la scène, permettent notamment d'exprimer une modification d'une scène, c'est-à-dire un complément d'une scène précédemment restituée sur le terminal.

La figure 1 illustre notamment une application de l'invention selon laquelle un serveur 11 fournit un service à un terminal de radiocommunication 12.

On rappelle qu'un service est conçu comme une suite de contenus, ou de portions de contenu, envoyés au terminal de l'utilisateur, notamment en réponse à des requêtes interactives.

Selon l'invention, le contenu multimédia à transmettre vers le terminal de radiocommunication 12 comprend au moins une scène multimédia et une série de commande permettant de faire évoluer la scène multimédia. Le serveur 11 transmet d'abord une première portion, dite portion initiale,

au terminal de radiocommunication 12 au cours d'une étape 13 de transmission.

Le serveur 11 transmet ensuite une portion complémentaire comprenant des commandes de scène de LASeR au terminal 12 au cours d'une étape de transmission 14, en réponse à une requête provenant du terminal. Comme illustré en figure 5, lors d'une étape 52, le terminal 12 mémorise, dans un contexte local, la portion initiale transmise par le serveur 11 lors d'une étape 51.

Le terminal 12 restitue ensuite la scène initiale lors d'une étape 53.

Le serveur 11 transmet alors une portion complémentaire, sous la forme d'un complément de la scène initiale et/ou d'une portion complémentaire précédemment reçue, lors d'une étape de transmission d'une portion complémentaire 54, en réponse à une requête provenant du terminal. Le terminal mémorise la portion complémentaire lors d'une étape 55, ou mémorise directement les commandes de modification de scènes correspondant à cette portion complémentaire, dans un contexte local comprenant également la portion initiale.

Le terminal restitue ensuite une scène mise à jour, à partir de la portion initiale et de la portion complémentaire mémorisées, lors d'une étape 56.

Les étapes 54, 55 et 56 peuvent être répétées autant de fois que nécessaire et notamment autant de fois qu'il y a de requêtes provenant du terminal.

On présente notamment en relation avec les figures 3A, 3B et 3C un exemple de réalisation de l'invention, pour la transmission vers le terminal de radiocommunication 12 d'un service de météorologie.

On considère notamment dans cet exemple que la figure 3A correspond à une scène multimédia initiale, et représente les prévisions météorologiques pour la France pour le jour.

Lorsque l'utilisateur du terminal de radiocommunication 12 souhaite accéder au service météo, il envoie une requête au serveur 11.

Celui-ci lui envoie alors la carte météo du jour, correspondant à la portion initiale.

On peut notamment considérer que lorsque la portion initiale est volumineuse, et par conséquent longue à télécharger, elle n'est pas envoyée pendant une phase d'interaction. Au contraire, cette portion initiale peut par exemple être pré-chargée sur le terminal 12, ou être transmise via un canal de multi-diffusion (par exemple de type DVBH -en anglais « Digital Video Broadcasting Handheld », DMB -en anglais « Digital Multimedia Broadcast », ou multicast). Sa taille est donc moins critique.

Si l'utilisateur du terminal 12 souhaite visualiser la carte météo du lendemain, il doit envoyer une requête au serveur 11, lui demandant de lui transmettre la carte météo du lendemain, illustrée en figure 3B.

Selon les techniques de l'art antérieur, le serveur 11 retransmet intégralement la carte météo de la figure 3B, même si les modifications entre la carte du jour (figure 3A) et la carte du lendemain (figure 3B) sont mineures.

Ces modifications sont illustrées en figure 3C, le dessin en traits pointillés correspondant à la portion initiale et le dessin en traits pleins correspondant à la portion complémentaire.

Le serveur 11 transmet alors cette portion complémentaire au terminal de radiocommunication 12, sous la forme d'une scène additionnelle utilisant des commandes de scène du format LASeR. L'utilisateur peut alors formuler d'autres requêtes, et ainsi de suite.

On peut notamment remarquer que le temps entre la requête de l'utilisateur et l'arrivée de la réponse sur le terminal 12, en s'abstrayant du temps de création de la réponse par le serveur 11, est proportionnel à la taille de la réponse, et inversement proportionnel à la bande passante. Ainsi, tout gain sur la taille de la réponse a une influence positive cruciale sur le temps de réponse, donc de façon induite, sur l'interactivité.

Autrement dit, pour réduire la taille des contenus ou des portions de contenu multimédia à transmettre au terminal en réponse aux requêtes d'un utilisateur, et pour augmenter l'impression de fluidité du service, les contenus réponse sont considérés comme des modifications de la scène à partir de laquelle

l'utilisateur a envoyé la requête.

Ces modifications sont envoyées sous la forme d'une liste de commandes de scène. On présente ci-après un exemple de structure d'une portion initiale, comprenant au moins une scène multimédia, et une commande d'insertion de la scène, comportant : un fond de carte de France avec diverses informations complémentaires d'origine du service ; un texte TO : « le temps aujourd'hui », avec toutes les informations de police, de style, de couleur et de positionnement ; - cinq textes Tl à T5, présentant la température, du type « 15°C », en cinq points de la carte, avec toutes les informations de police, de style, de couleur et de positionnement associées ; un ensemble de liens ou boutons pour obtenir le temps demain et les jours suivants. La portion complémentaire, correspondant à une scène incrémentale, présente selon l'invention la structure suivante : un signal de configuration de type « append », présent dans une variante de ce mode de réalisation mais étant optionnel ; une commande de modification de la chaîne du texte TO en « le temps demain » ; cinq commandes de modifications des chaînes de textes Tl à T5 représentant la température ; une commande de remplacement du bouton ou lien « demain » par un bouton ou lien « aujourd'hui ». Selon le mode de réalisation particulier de l'invention, la scène incrémentale est créée en réponse à l'utilisation du bouton ou du lien « demain », c'est-à-dire en réponse à une requête d'un utilisateur. On constate notamment selon cet exemple que seules les chaînes de textes sont remplacées, mais pas leur police, style, couleur et positions. On peut remarquer que cette commande de modification globale,

comprenant le signal de configuration de la scène au mode « append » et les commandes de modification d'au moins un élément de la scène (« LASeR Commands ») sont potentiellement applicables à tous les formats de description de scènes multimédia. Ainsi, le format BIFS défini déjà des « BIFS Commands » qui sont similaires aux « LASeR Commands ». De même, les « LASeR Commands » sont applicables sans modification au format SVG.

De plus, ces fonctions sont déjà implémentées de manière efficace dans les téléphones, ce qui permet une implémentation de l'invention dans les terminaux actuels, même relativement contraints. Ainsi, en structurant le contenu multimédia à transmettre vers un terminal de radiocommunication, l'invention permet de diminuer la taille des portions de contenu à envoyer au terminal, ce qui offre le double avantage de réduire la consommation de bande passante, donc d'économiser en temps de réponse, et d'obtenir une continuité et fluidité du service au niveau du terminal, puisque seule le complément du contenu courant est envoyé au terminal plutôt que le contenu réponse complet.

De plus, comme illustré en figure 2B, le contexte local mémorisé par le terminal incrémenté à chaque réception d'une portion complémentaire permet de conserver les modifications successives subies par la portion initiale. Ainsi, dans le cas où le terminal coupe la connexion avec le serveur après la mise à jour n°3 (242) de la scène initiale 212, le terminal a mémorisé les différentes commandes de modification de scène correspondant aux mises à jour n°l (222), ⁿ °2 (232) ^e t n°3 (242), contrairement à l'art antérieur où le terminal n'avait mémorisé que la mise à jour n°3 (figure 2A). Lors de la connexion suivante, le terminal utilise le contexte local et la portion complémentaire pour restituer la scène mise à jour.

On présente en relation avec la figure 4, une partie de la structure du terminal selon ce mode de réalisation particulier de l'invention. Le terminal utilise une mémoire 41 pour mémoriser le contexte local lié à la portion initiale reçue du serveur, et peut s'en servir pour mémoriser les portions complémentaires reçues par le serveur.

Le micro-processeur 42 utilise le contexte local et chaque portion complémentaire pour reconstruire une scène mise à jour, et la transmettre au module d'affichage 43 qui restitue la scène mise à jour.