Brevet FR2924886A1 — publié le 20090612

Procédé de gestion de canaux de communication, signal et terminal correspondants. 1. Domaine de l'invention 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 multimédia, d'une portion de ce contenu, et/ou d'éléments représentatifs de celui- ci, vers un terminal de radiocommunication, par l'intermédiaire d'un ou plusieurs canaux de transmission. 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. Une scène multimédia correspond notamment à l'agencement d'urri ensemble d'objets graphiques dans le temps et dans l'espace, avec lesquels l'utilisateur du terminal de radiocommunication peut interagir. On entend aussi par service multimédia une succession de contenu maintenant pour l'utilisateur une impression de continuité, que cette continuité soit obtenue par mises à jour successives de la même scène multimédia ou par juxtaposition de scènes multimédia successives. 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 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 Scene �, en français � format binaire pour scène �), le SVG (en anglais � Scalable Vector Graphics �, en français � graphiques vectoriels adaptables �), le SMIL (en anglais � Synchronized Multimedia Integration Language �, en français � langage d'intégration multimédia synchronisés �), le XI-ITML (en anglais � eXtensible HyperText Markup Language �, en français � langage de balisage hypertexte extensible �), etc. Par exemple, l'invention trouve des applications lors de l'utilisation de formats de description de scènes graphiques tels que ceux cités précédemment sur des canaux de transmission de type HTTP (� Hyper Text Transport Protocol �) sur TCP/IP (� Transmission Control Protocol / Internet Protocol �), ou RTP (� Real Time Protocol �), et plus généralement sur les types de canaux de transmission utilisés entre autres par les normes DVB (Digital Video Broadcast), DMB (Digital Multimedia Broadcast), 3GPP (Third Generation Partnership Project), OMA (Open Mobile Alliance), etc.. 2. Art antérieur 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 oeuvre le schéma suivant : un contenu initial est envoyé sur le terminal ; - l'utilisateur le consomme au fur et à mesure de l'envoi du contenu, et fait une requête ; - un contenu de réponse est alors envoyé sur le terminal de radiocommunication, alors que l'envoi du premier contenu est encore actif. Il y a alors un choix sur le terminal : soit le premier contenu doit être arrêté et le second contenu (contenu de réponse) peut alors utiliser le même canal de transmission que le premier contenu ; soit le premier contenu doit continuer à être reçu et joué en parallèle avec le second contenu. 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 dans un certain nombre de canaux de transmission. Les techniques connues ne permettent pas de décider, au moment de la réception du contenu réponse, de couper la première communication (transmission du premier contenu) et de réutiliser ce canal, ou d'ouvrir un nouveau canal de communication indépendant pour le contenu réponse. Par exemple, si l'utilisateur demande un service de téléchargement de musique, le contenu initial envoyé sur le terminal comprend un premier flux de musique. L'utilisateur le consomme, c'est-à-dire écoute le flux de musique, et fait 10 une requête pour obtenir des informations sur la musique. Un nouveau contenu de réponse, comprenant les informations demandées, est alors envoyé sur le terminal de radiocommunication. Selon un premier comportement possible, le canal de transmission du premier contenu est toujours coupé lors de la réception d'un second contenu, ce 15 qui garantit que le terminal n'utilise qu'un seul canal de communication (encore appelé canal de transmission) à la fois. Cependant, un inconvénient de ce comportement est qu'il ne permet pas de mettre en oeuvre des services mixtes de coopération de réseau dont une partie est transmise sur un canal de communication, et une autre partie est simultanément transmise sur un autre canal 20 de communication, ce second canal pouvant être d'un autre type que le premier. Par conséquent, ce comportement est particulièrement adapté aux terminaux très contraints qui ne permettent pas d'ouvrir plus d'un canal de communication à la fois. Selon un deuxième comportement possible, le premier canal de 25 communication est toujours maintenu ouvert lors de la réception du second contenu, ce qui permet de mettre en oeuvre des services utilisant la coopération de réseaux, dont une partie est transmise sur un canal de communication, et une autre partie est simultanément transmise sur un autre canal de communication, ce second canal pouvant être d'un autre type que le premier. Par contre, ce 30 comportement présente des inconvénients majeurs : - il ne permet pas de faire fonctionner un ou plusieurs services sur des terminaux très contraints qui ne permettent pas d'ouvrir plus d'un canal de communication à la fois ; - il ne permet pas de couper la communication lors de la réception du second contenu, ce qui force le terminal à consommer le reste du premier contenu.De ce fait, même si le serveur a arrêté d'envoyer des données pour ce premier contenu, les tampons de transmission du réseau sont pleins et plusieurs secondes de contenu vont encore être reçues et donc consommer inutilement des ressources sur le terminal. Le serveur du premier contenu peut aussi être distinct du serveur du second contenu, et donc ne pas être informé de la requête, et par conséquent poursuivre l'envoi jusqu'à la fin initialement prévue du premier contenu. Selon un troisième comportement possible, la réception du premier contenu est coupée dès l'émission de la requête d'un second contenu, ce qui garantit que le terminal n'utilise qu'un seul canal de communication à la fois. Cependant, un inconvénient de ce comportement est qu'il ne permet pas de mettre en oeuvre des services mixtes de coopération de réseau dont une partie est transmise sur un canal de communication, et une autre partie est simultanément transmise sur un autre canal de communication, ce second canal pouvant être d'un autre type que le premier. Par conséquent, ce comportement est particulièrement adapté aux terminaux très contraints qui ne permettent pas d'ouvrir plus d'un canal de communication à la fois 3. Objectifs de l'invention L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur. Un objectif de l'invention, selon au moins un mode de réalisation, est de mettre en oeuvre une telle technique permettant de réutiliser un canal de communication déjà ouvert pour la réception d'un contenu précédent lors de la réception d'un nouveau contenu. Un autre objectif de l'invention, selon au moins un mode de réalisation, est de mettre en oeuvre une telle technique utilisable en particulier sur les terminaux très contraints qui ne permettent pas d'ouvrir plus d'un canal de communication à la fois, pour les services qui peuvent être exécutés sur de tels terminaux. Un autre objectif de l'invention, selon au moins un mode de réalisation, est de mettre en oeuvre une technique économe en termes de ressources, garantissant que le terminal n'utilise qu'un seul canal de communication à la fois, pour les services qui peuvent être exécutés dans ces conditions. Un autre objectif de l'invention, selon au moins un mode de réalisation, est 10 de mettre en oeuvre une technique permettant la gestion du nombre de canaux de communication utilisés à chaque instant par le terminal. Un autre objectif de l'invention, selon au moins un mode de réalisation, est de mettre en oeuvre une technique permettant la réutilisation, pour la réception d'un nouveau contenu ou d'une nouvelle portion du contenu, d'un canal 15 particulier parmi les canaux de communication déjà ouverts. Un autre objectif de l'invention, selon au moins un mode de réalisation, est de mettre en oeuvre une telle technique permettant de mettre en oeuvre des services utilisant la coopération de réseaux et dont une partie est transmise sur un canal de communication, et une autre partie est simultanément transmise sur un autre canal 20 de communication, ce second canal pouvant être d'un autre type que le premier. 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. 4. Exposé de l'invention 25 L'invention propose une solution nouvelle qui ne présente pas l'ensemble de ces inconvénients de l'art antérieur, sous la forme d'un procédé de gestion de canaux de communication pour la transmission de contenus multimédia d'au moins un serveur vers au moins un terminal de radiocommunication. Selon l'invention, un tel procédé comprend les étapes suivantes 30 -transmission d'un premier contenu dans un premier canal restitution (ou consommation) progressive dudit premier contenu dans un terminal ; émission par ledit terminal d'une requête pour un deuxième contenu, ladite requête comprenant une information de contrôle indiquant si ledit deuxième contenu doit être transmis dans ledit premier canal, ou dans un second canal ; - restitution progressive dudit deuxième contenu. Ainsi, l'invention permet la restitution progressive d'un premier contenu (par exemple en mode � streaming �) transmis via un premier canal de communication, et la restitution d'un deuxième contenu suite à une requête du terminal, transmis via le premier canal de communication ou via un deuxième canal. En particulier, ces différents contenus peuvent être transmis par des serveurs distincts, mais à destination d'un même terminal. Il est également important de noter que les différents canaux de communication mis en oeuvre peuvent être de différents types (par exemple un canal bidirectionnel téléphonique et un canal monodirectionnel de diffusion). Ainsi, une requête pour un deuxième contenu comprend une information de contrôle indiquant si le deuxième contenu doit être transmis dans le premier canal, ou dans un second canal, en fonction du type de contenu par exemple. Puis, en réponse à cette requête, le deuxième contenu peut être transmis dans le canal de communication du premier contenu, interrompant ainsi la transmission du premier contenu, ou dans un autre canal de communication. Par exemple, dans le cadre de terminaux fortement contraints, on peut réutiliser le premier canal de communication pour transmettre le deuxième contenu, évitant ainsi à ces terminaux d'avoir à ouvrir un deuxième canal de communication qui serait de mauvaise qualité. Selon un mode de réalisation particulier de l'invention, la restitution progressive du premier contenu se poursuit tant qu'une réponse à la requête n'est pas reçue. L'auteur d'un service peut ainsi concevoir son service de manière à faire patienter un utilisateur du terminal pendant les temps d'attente d'une réponse à une requête, en continuant à présenter sur le terminal le contenu en cours de consommation. Selon un aspect particulier de l'invention, si l'information de contrôle prévoit l'utilisation d'un second canal, les premier et deuxième contenus sont restitués progressivement au moins partiellement de façon simultanée. Ainsi, le deuxième contenu peut être affiché dans une scène multimédia associée au premier contenu. En particulier, cette scène multimédia peut avoir été modifiée (au moyen des commandes de modification de scène) de façon à améliorer la perception du deuxième contenu : par exemple, le volume sonore associé au premier contenu est diminué lors de la restitution du deuxième contenu. Selon un autre aspect de l'invention, si l'information de contrôle prévoit 15 l'utilisation du premier canal uniquement, le deuxième contenu est restitué progressivement en remplacement du premier contenu. De plus, selon une variante, le terminal émet une requête d'interruption de la transmission du premier contenu à destination du serveur correspondant, c'est-à-dire à destination du serveur fournissant le premier contenu au terminal. 20 Selon un mode de réalisation particulier de l'invention, l'information de contrôle est un attribut d'un élément d'une scène multimédia portant un lien vers le serveur transmettant ledit deuxième contenu. On définit ainsi un nouvel attribut, noté par exemple Isr:ConnectionPipe, permettant d'indiquer si le deuxième contenu doit être transmis dans le premier 25 canal, ou dans un deuxième canal. On constate que dans le standard HTML (Hyper Text Marku.p Language), un élément a peut également posséder un nouvel attribut, de type �target �. Toutefois, il est important de remarquer que cet attribut � target � définit uniquement des aspects relatifs à la restitution. Plus précisément, cet attribut 30 définit l'espace où la réponse à la requête va être présentée, c'est-à-dire l'endroit dans la scène multimédia où le deuxième contenu va être restitué, mais ne définit pas les conditions de distribution des contenus, et notamment quel canal de communication peut être utilisé. De même, des paramètres XLink, tels que définis dans les formats LASeR et SAF, définissent également des aspects relatifs à la restitution. Plus précisément, ces paramètres définissent la façon de consommer un deuxième contenu lié à un premier contenu, reçu en réponse à une requête séparée de celle pour le premier contenu (contenu principal). De nouveau, il est important de noter qu'aucun de ces paramètres ne concerne le mode de distribution ou la gestion des canaux de communication utilisés, comme le propose l'invention selon au moins un mode de réalisation. En particulier, selon un mode de réalisation particulier de l'invention, ledit attribut peut prendre une des au moins trois valeurs suivantes : nouveau canal ; -canal courant ; identificateur d'un canal prédéterminé. Par exemple, l'attribut peut prendre la valeur � new � (en français � nouveau �) pour définir un nouveau canal, ou bien la valeur � current � (en français � courant �) pour définir le canal courant, ou encore utiliser un nom de canal de communication (par exemple � canal X �) pour identifier un canal prédéterminé. Selon une caractéristique particulière de l'invention, le procédé de gestion met en oeuvre une étape d'émission par le terminal d'une requête de fermeture explicite d'un canal de communication ouvert, en le désignant par son identificateur. En utilisant le format XML, cette requête de fermeture, encore appelée � directive �, peut être notée Plus précisément, selon un mode de réalisation particulier, l'invention propose de signaler dans un nouveau contenu envoyé en réponse a une requête l'information permettant de gérer la réutilisation ou non d'un canal de communication déjà en cours d'utilisation. En particulier, ce signal de transmission d'un nouveau contenu peut contenir une information selon laquelle le canal utilisé par le contenu précédemment envoyé et encore en cours de consommation (premier contenu), doit être coupé ou pas. De plus, ce signal peut contenir une information selon laquelle le nouveau contenu (deuxième contenu) envoyé en réponse à une requête doit réutiliser le canal déjà en cours d'utilisation pour le contenu précédemment envoyé et encore en cours de consommation (c'est-à-dire ré-utiliser le premier canal de communication). Par ailleurs, ce signal peut contenir un identificateur pour le canal de communication à utiliser pour le nouveau contenu envoyé en réponse à la requête. En effet, on considère que l'utilisation de l'un et/ou l'autre des canaux de communication est dépendant du type de service demandé lors d'une requête, et doit donc découler des intentions de l'auteur d'un contenu. Par conséquent, le � comportement � des canaux de communication est modifié selon la situation rencontrée. Jusqu'à présent, des raisons liées au type de contenu et à la situation de 30 service ne permettaient pas de décider, au moment de la requête, de couper ou non la réception du premier contenu. Selon l'invention, si le contenu est un flux de musique par exemple, il est envisageable que l'auteur souhaite que, l'utilisateur puisse continuer à écouter cette musique pendant l'attente liée au temps de transmission de la requête au serveur, au temps de réaction du serveur et au temps de retour de la réponse à la requête. On illustre ainsi en relation avec les figures 3 et 4 un exemple de mise en oeuvre de l'invention. On considère pour ce faire un unique serveur 35, fournissant un service à un terminal de radiocommunication 36. Il est bien entendu que l'invention couvre également le cas de la transmission d'informations de plusieurs serveurs à au moins un terminal de radiocommunication. On considère selon cet exemple que le serveur 35 transmet au cours d'une première étape 41 un premier contenu 37 au terminal de communication 36. Au cours d'une étape 42, le premier contenu 37 (ou au moins une partie de ce contenu) est restitué progressivement sur le terminal 36. Autrement dit, on utilise une transmission en mode � streaming �. Si l'utilisateur du terminal 36 souhaite recevoir un deuxième contenu, il émet à destination du serveur 35 une requête 38 au cours d'une étape 43, demandant au serveur 35 de lui envoyer le deuxième contenu. Selon un mode de réalisation particulier de l'invention, la requête 38 comprend également une information de contrôle indiquant si le deuxième contenu doit être transmis dans le premier canal, ou dans un second canal. Selon ce mode de réalisation particulier, tant que la réponse à la requête 38 n'est pas reçue, le terminal 36 continue à restituer le premier contenu au cours de l'étape 43. Selon une autre approche, il est possible d'interrompre la restitution du premier contenu immédiatement après l'émission de la requête ou après un laps de temps prédéterminé. Finalement, au cours d'une étape 44, le deuxième contenu 39 est transmis (dans le premier ou clans un second canal de communication) et restitué sur le terminal. On décrit ci-après, en relation avec la figure , un exemple de mode de réalisation particulier de l'invention s'appuyant (de façon non exclusive mais simplement illustrative) sur l'utilisation d'un environnement LASeR (en anglais � Lightweight Application Scene Representation �, en français � Représentation de scènes applicatives légères �) et SAF (en anglais � Simple Aggregation Format �). Soit un service au format LASeR de téléchargement de morceaux de musique. On rappelle qu'un service est une succession de contenus, maintenant pour l'utilisateur une impression de continuité, un contenu étant 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. Par exemple, cette continuité peut être obtenue par mises à jour successives de la même scène multimédia, le service étant alors conçu de manière à ce que l'utilisateur ne voit pas de changement de page, et toutes les réponses à des requêtes de l'utilisateur étant des mises à jour partielles de la scène courante. Dans ce cas, il n'y a pas de remplacement d'une scène par une autre. II est à noter que, classiquement, le remplacement est le moment préféré pour récupérer toutes les ressources, et en particulier tout canal de communication ouvert. Dans cet exemple de réalisation, le service commence par des écrans successifs de choix d'un premier morceau de musique. On considère que [utilisateur a choisi un morceau. Lors d'une interaction locale (choix du morceau), une requête est construite puis envoyée au serveur. Le serveur répond sous la forme d'une mise à jour de la scène comportant un élément audio avec ses éléments de contrôle accompagnés d'un flux de musique. Ce flux de musique est joué, par le terminal, à réception. On considère que l'utilisateur interagit encore avec le service. Certaines interactions sont purement locales, et ne donnent pas lieu à des requêtes vers le serveur. Pour les interactions qui donnent lieu à un dialogue avec le serveur, il faut distinguer deux types de situation : - un premier type de situation où la réponse à la requête ne remet pas en cause la consommation du flux de musique ; - un second type de situation où la réponse à la requête suppose que la consommation du flux de musique s'arrête. Dans le premier type de situation, la requête est, par exemple, une demande d'information complémentaire sur le flux de musique, comme par exemple une demande de présentation de la pochette du CD, ou une demande d'achat de l'album physique. Dans ce cas, le flux de musique est transmis dans un premier canal de communication. La réponse à la requête est quant à elle transmise dans un deuxième canal de communication, puis décodée et rendue dans la scène qui restitue le flux de musique. Par exemple, cette réponse est restituée sous la forme d'information présentée dans une fenêtre temporaire superposée aux éléments graphiques liés au contrôle de la consommation du flux, appelés précédemment éléments de contrôle. Dans le second type de situation, la requête est, par exemple, une demande d'un deuxième flux de musique. Il faut dans ce cas arrêter de consommer le premier flux avant de commencer à consommer le deuxième flux. En particulier, le serveur du deuxième flux peut être différent du serveur du premier flux Par conséquent il n'est pas certain que le serveur du premier flux soit au courant de la requête demandant un deuxième flux, et continue donc la transmission du premier flux. Il est donc de la responsabilité du terminal de couper la communication du premier flux, que ce soit pour informer le serveur de l'arrêt de la consommation et/ou pour éviter d'avoir à supprimer des paquets du premier flux contenus dans les différentes zones de tampon du réseau. En effet, ces zones tampons correspondent souvent à plusieurs secondes de contenu, de 2 à 10 secondes selon les situations, ce qui est coûteux en terme de ressources. Il est donc important de pouvoir, au moment de la réception de chaque réponse : -soit poursuivre la consommation d'un flux en cours et utiliser un nouveau canal de communication pour la réponse ; - soit arrêter la consommation d'un flux en cours et réutiliser un même canal de communication pour la consommation de la réponse. Selon ce mode de réalisation de l'invention, cette décision peut être prise grâce à une information de contrôle contenue dans les informations de scène, par exemple dans les commandes permettant de faire évoluer la scène d'un état à un autre. Par exemple, on suppose que la requête est transmise par 1' intermédiaire de l'activation d'un élément a de la scène, par exemple un objet graphique de la scène. Un tel élément comprend plusieurs attributs, tels que définis dans les formats LASeR et SAF. Par exemple, l'activation de l'élément a se traduit par un appel à une URL contenue dans l'attribut xlink:href de cet élément a. Selon ce mode de réalisation, on définit un nouvel attribut Isr:connectionPipe ajouté à l'élément a. On considère que cet attribut peut prendre les valeurs : ù � new � définissant un nouveau canal de communication, ù � current � définissant le canal de communication courant (en général, le premier canal de communication) ou ù un identificateur d'un canal prédéterminé, par exemple sous la forme du nom d'un canal de communication. Utiliser un nom de canal de communication � X � est équivalent à donner la valeur � new � à l'attribut lsr:connectionPipe, et permet en plus de couper ultérieurement le canal par une commande explicite, par exemple en format XML. En reprenant la première situation évoquée précédemment, selon laquelle la réponse à la requête ne remet pas en cause la consommation du flux de musique, l'attribut Isr:connexionPipe doit avoir la valeur � new � ou le nom d'un deuxième canal de communication différent du nom du premier canal de communication en cours d'utilisation pour le flux de musique. Si ce premier canal de communication en cours d'utilisation pour le flux de musique n'a pas de nom, alors l'attribut Isr:connexionPipe peut avoir la valeur � new � ou [e nom d'un canal de communication quelconque. De même, en reprenant la deuxième situation évoquée précédemment, selon laquelle la réponse à la requête arrête la consommation du flux de musique, l'attribut lsr:connexionPipe doit avoir la valeur �current� ou le nom du premier canal de communication, en cours d'utilisation pour le flux de musique. Si ce premier canal de communication en cours d'utilisation pour le flux de musique n'a pas de nom, alors l'attribut lsr:connexionPipe doit avoir la valeur � current �. IO On décrit ci-après un exemple d'algorithme utilisé pour la mise en oeuvre de l'invention, illustré au moyen de fragments de scène. On comprend que dans une situation de service au format LASeR, l'équivalent binaire de ces fragments de scène serait transmis. L'annexe 1, qui fait partie intégrante de la description présente un 15 fragment pour la scène comprenant le flux de musique � au � en cours de consommation et comprenant deux requêtes possibles, une requête regl pour une demande d'affichage de la pochette, correspondant à la première situation et une requête req2 pour une demande de transmission d'un second flux, correspondant à la deuxième situation. 20 Par exemple, la figure lA illustre la première situation, selon laquelle le flux de musique � au � est transmis dans un premier canal de communication et la requête ne remet pas en cause la consommation du flux � au � Lors de la réception 10 de la réponse à la requête regl, le terminal ne coupera pas la réception du flux de musique � au �, et les informations d'affichage de la pochette 25 � poch � seront transmises dans un deuxième canal de communication. La figure 1B illustre quant à elle la deuxième situation, selon laquelle le flux de musique � au � est transmis dans un premier canal de communication et la requête remet en cause la consommation du flux � au �.Lors de la réception I l de la réponse à la requête req2, le terminal coupera cette réception. Par conséquent, 30 le flux de musique � au � n'est plus transmis dans le premier canal de communication et un deuxième flux noté � track � est transmis dans ce premier canal. Selon une variante, ce deuxième flux noté � track � peut être transmis dans un deuxième canal de communication. On décrit désormais en relation avec la figure 2 un autre exemple d'application de l'invention est décrit dans le cadre d'un service dont la partie principale est diffusée sans voie de retour, autrement dit en mode . Lors de la scène � catastrophe �, une zone cliquable apparaît. L'utilisateur clique pour demander le formulaire de don. Ce formulaire de don est spécifique de l'opérateur téléphonique, et donc envoyé sur un canal téléphonique. Un objet de la scène � catastrophe �correspondant à l'élément a configuré cornme suit est activé : Lors de l'activation de cette zone cliquable, une requête req 22 est envoyée à un serveur. A la réception de la réponse 23, le canal DVB-H 20 est maintenu et un canal téléphonique (par exemple de type UMTS) 24 est créé pour la gestion du formulaire de don. A la fin de l'opération, la transmission d'information est terminée et le canal de transmission 24 utilisé pour la réception du formulaire de don est naturellement clos 25 par le serveur. Lors de la scène � interview �, une zone cliquable apparaît. L'utilisateur clique pour demander l'écoute du premier morceau (� requête chanson 1 �(req3) 26). Pour des raisons externes, les trois morceaux ne peuvent pas fare partie des données liées à l'émission du journal télévisé mais doivent être reçus par un canal téléphonique. Un objet de la scène � interview �correspondant à l'élément a configuré comme suit est activé : Lors de l'activation de cette zone cliquable, la requête 26 pour la première chanson est envoyée. A la réception de la réponse 27, le canal DVB-H est maintenu, même si le volume sonore du journal télévisé est temporairement réduit à 0. Un autre canal de communication UMTS 28, nommé � song � est ouvert, et la chanson commence à être jouée. L'utilisateur continue à voir le journal, avec les zones cliquables, pendant qu'il écoute la chanson. Il souhaite alors passer à la seconde chanson et active une autre zone cliquable. Un objet de la scène � interview �correspondant à un élément a configuré comme suit est activé : Lors de l'activation de cette seconde zone cliquable, la requête 29 (req4) pour la seconde chanson est envoyée. Dans cet exemple, la première chanson continue à être jouée. A la réception de la seconde réponse 30, la connexion sur le canal � song � est coupée pour que le canal puisse être réutilisé pour la seconde chanson. Le contenu des tampons de la première chanson est détruit. La seconde chanson commence à être jouée sur le canal � song �. L'utilisateur souhaite alors revenir au journal télévisé et transmet une requête (req5) 31 de retour JT. Un objet correspondant à un élément conditionnel configuré comme suit est activé : ... autres commandes liées au retour au JT... ... dont le retour du volume sonore normal du JT... A la suite de cette opération, le canal de transmission 28 � song � utilisé 10 pour les deux chansons est fermé et la consommation du flux DVB-H 20 seulement continue. ANNEXE 1 ... (flux d'image utilisés par la scène) ... .entête flux audio... /> ..DTD: ... paquets audio ad lib ... REVENDICATIONS 1. Procédé de gestion de canaux de communication pour la transmission de contenus multimédia d'au moins un serveur (35) vers au moins un terminal de radiocommunication (36), caractérisé en ce qu'il comprend les étapes suivantes : - transmission (41) d'un premier contenu (37) dans un premier canal ; - restitution progressive (42) dudit premier contenu (37) dans un terminal ; - émission (43) par ledit terminal d'une requête (38) pour un deuxième IO contenu (39), ladite requête (38) comprenant une information de contrôle indiquant si ledit deuxième contenu (39) doit être transmis dans ledit premier canal, ou dans un second canal ; - restitution progressive (44) dudit deuxième contenu (39). 2. Procédé de gestion de canaux de communication selon la revendication 1, 15 caractérisé en ce que ladite restitution progressive dudit premier contenu se poursuit tant qu'une réponse à ladite requête n'est pas reçue. 3. Procédé de gestion de canaux de communication selon l'une quelconque des revendications 1 et 2, caractérisé en ce que, si ladite information de contrôle prévoit l'utilisation d'un second canal, les premier et deuxième contenus sont 20 restitués progressivement au moins partiellement de façon simultanée. 4. Procédé de gestion de canaux de communication selon l'une quelconque des revendications 1 et 2, caractérisé en ce que, si ladite information de contrôle prévoit l'utilisation dudit premier canal uniquement, ledit deuxième contenu est restitué progressivement en remplacement dudit premier contenu. 25 5. Procédé de gestion de canaux de communication selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite information de contrôle est un attribut d'un élément d'une scène multimédia portant un lien vers le serveur transmettant ledit deuxième contenu. 6. Procédé de gestion de canaux de communication selon la revendication 5, caractérisé en ce que ledit attribut peut prendre une des au moins trois valeurs suivantes: - nouveau canal ; canal courant ; identificateur d'un canal prédéterminé. 7. Procédé de gestion de canaux de communication selon la revendication 6, caractérisé en ce qu'il met en oeuvre une étape d'émission par ledit terminal d'une requête de fermeture explicite d'un canal de communication ouvert, en le désignant par son identificateur. 8. Signal de gestion de canaux de communication pour la mise en oeuvre du procédé de gestion de canaux de communication selon l'une quelconque des revendications I à 7, ledit signal étant émis par un terminal de radiocommunication, caractérisé en ce qu'il comprend un champ d'information de contrôle indiquant si un deuxième contenu doit être transmis dans le premier canal, ou dans un second canal de communication. 9. Signal de gestion selon la revendication 8, caractérisé en ce que ledit champ d'information de contrôle peut prendre une des au moins 'trois valeurs suivantes : nouveau canal ; - canal courant ; identificateur d'un canal prédéterminé. 10. Signal de gestion selon la revendication 9, caractérisé en ce qu'il comprend une requête de fermeture explicite d'un canal de communication ouvert en le désignant par son identificateur. 11. Terminal de radiocommunication (36) destiné à recevoir au moins un contenu multimédia diffusé par au moins un serveur (35), caractérisé en ce qu'il comprend des moyens de :- restitution progressive d'un premier contenu transmis dans un premier canal ; - émission d'une requête pour un deuxième contenu, ladite requête comprenant une information de contrôle indiquant si ledit deuxième 5 contenu doit être transmis dans ledit premier canal, ou dans un second canal ; restitution progressive dudit deuxième contenu.