EP2077016A1 - Procédé de gestion de canaux de communication, signal et terminal correspondants - Google Patents

Procédé de gestion de canaux de communication, signal et terminal correspondants

Info

Publication number
EP2077016A1
EP2077016A1 EP07820660A EP07820660A EP2077016A1 EP 2077016 A1 EP2077016 A1 EP 2077016A1 EP 07820660 A EP07820660 A EP 07820660A EP 07820660 A EP07820660 A EP 07820660A EP 2077016 A1 EP2077016 A1 EP 2077016A1
Authority
EP
European Patent Office
Prior art keywords
content
channel
request
terminal
transmitted
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP07820660A
Other languages
German (de)
English (en)
Inventor
Jean-Claude Dufourd
Elouan Le Coq
Nicolas Pierre
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Streamazzo
Streamezzo SA
Original Assignee
Streamazzo
Streamezzo SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FR0608822A external-priority patent/FR2924885A1/fr
Application filed by Streamazzo, Streamezzo SA filed Critical Streamazzo
Publication of EP2077016A1 publication Critical patent/EP2077016A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management

Definitions

  • the field of the invention is that of the reproduction of multimedia content on a radiocommunication terminal, for example of the radiotelephone type, PDA (in English “Personal Digital Assistant", in French “personal digital assistant”), laptop, etc.
  • the invention is based on the transmission of a multimedia content, a portion of this content, and / or elements representative of it, to a radiocommunication terminal, via one or several transmission channels.
  • Multimedia content includes a set consisting of at least one animated graphic scene, also called multimedia scene, and a series of commands to change this scene from one state to another.
  • a multimedia scene corresponds in particular to the arrangement of a set of graphic objects in time and in space, with which the user of the radiocommunication terminal can interact.
  • Multimedia service also means a succession of content now for the user an impression of continuity, that this continuity is obtained by successive updates of the same multimedia scene or by juxtaposition of successive multimedia scenes.
  • the invention finds applications in all fields requiring a representation of the signals in the form of a spatio-temporal arrangement of graphic objects, with interactivity.
  • the invention applies to the already known graphic scene description formats such as the MPEG-4 / BIFS (in English “Binary Format Scene", in French “binary format for stage"), the SVG (in English “ Scalable Vector Graphics ", the” Synchronized Multimedia Integration Language “(SMIL), the XHTML (in English” extensible HyperText Markup Language ", in French” extensible hypertext markup language "), etc.
  • the invention finds applications when using graphic scene description formats such as those mentioned above on HTTP ("Hyper Text Transport Protocol") transmission channels over TCP / IP ("Transmission Control Control”).
  • Protocol / Internet Protocol "), or RTP Real Time Protocol ")
  • DVB Digital Video Broadcast
  • DMB Digital Multimedia Broadcast
  • 3GPP Third Generation Partnership Project
  • OMA Open Mobile Alliance
  • the design of a service that is to say the supply of information to a user of a radiocommunication terminal, implements the following schema: initial content is sent to the terminal; the user consumes it as and when sending the content, and makes a request; - A response content is then sent to the radiocommunication terminal, while the sending of the first content is still active. There is then a choice on the terminal: either the first content must be stopped and the second content (response content) can then use the same transmission channel as the first content; either the first content must continue to be received and played in parallel with the second content.
  • the service is therefore conceived as a sequence of contents sent to the user's terminal in response to interactive requests in a certain number of transmission channels.
  • the known techniques do not make it possible to decide, at the time of receiving the response content, to cut off the first communication (transmission of the first content) and to reuse this channel, or to open a new independent communication channel for the response content.
  • the original content sent to the terminal includes a first stream of music.
  • the user consumes it, that is, listens to the music stream, and makes a request for information about the music.
  • a new response content, including the requested information, is then sent to the radiocommunication terminal.
  • the transmission channel of the first content is always cut off when receiving a second content, which guarantees that the terminal uses only one communication channel (also called transmission channel) to that time.
  • a disadvantage of this behavior is that it does not make it possible to implement mixed network cooperation services, part of which is transmitted on one communication channel, and another part is simultaneously transmitted on another communication channel, this second channel may be of a type other than the first. Therefore, this behavior is particularly suitable for very constrained terminals that do not allow to open more than one communication channel at a time.
  • the first communication channel is always kept open when the second content is received, which makes it possible to implement services using network cooperation, part of which is transmitted over a communication channel, and another part is simultaneously transmitted on another communication channel, this second channel being of a type other than the first.
  • this behavior has major drawbacks: it does not allow to operate one or more services on highly constrained terminals that do not allow to open more than one communication channel at a time; it does not allow the communication to be cut off when the second content is received, which forces the terminal to consume the remainder of the first content.
  • the server of the first content may also be separate from the server of the second content, and thus not be informed of the request, and therefore continue sending until the originally scheduled end of the first content.
  • the reception of the first content is cut off as soon as the request for a second content is sent, which guarantees that the terminal uses only one communication channel at a time.
  • this behavior is particularly suitable for very constrained terminals that do not allow to open more than one communication channel at a time
  • An object of the invention is to implement such a technique to reuse an already open communication channel for receiving a previous content when receiving new content.
  • Another objective of the invention is to implement such a technique which can be used in particular on highly constrained terminals which do not make it possible to open more than one communication channel at a time, for services that can be run on such terminals.
  • Another object of the invention is to implement a resource-saving technique, ensuring that the terminal uses only one communication channel at a time, for the services which can be executed under these conditions.
  • Another object of the invention is to implement a technique for managing the number of communication channels used at each instant by the terminal.
  • Another object of the invention is to implement a technique allowing the reuse, for the reception of a new content or a new portion of the content, of a particular channel among the communication channels already open.
  • Another object of the invention is to implement such a technique for implementing services using network cooperation and a part of which is transmitted over a communication channel, and a another part is simultaneously transmitted on another communication channel, this second channel being of a type other than the first.
  • the invention aims to provide such a technique having better performance in terms of fluidity of services at the radiocommunication terminal.
  • the invention proposes a new solution that does not have all of these disadvantages of the prior art, in the form of a communication channel management method for the transmission of multimedia contents. at least one server to at least one radiocommunication terminal.
  • such a method comprises the following steps: transmission of a first content in a first channel; progressive restitution (or consumption) of said first content in a terminal; sending by said terminal a request for a second content, said request comprising control information indicating whether said second content is to be transmitted in said first channel, or in a second channel; progressive restitution of said second content.
  • the invention allows the progressive restitution of a first content
  • these different contents can be transmitted by separate servers, but to the same terminal.
  • the different communication channels implemented may be of different types (for example a bidirectional telephone channel and a one-way broadcast channel).
  • a request for a second content includes control information indicating whether the second content should be transmitted in the first channel, or in a second channel, depending on the type of content for example. Then, in response to this request, the second content can be transmitted in the communication channel of the first content, thereby interrupting the transmission of the first content, or in another communication channel.
  • the first communication channel can be reused to transmit the second content, thus preventing these terminals from having to open a second communication channel that would be of poor quality.
  • the progressive reproduction of the first content continues as long as a response to the request is not received.
  • the author of a service can thus design its service so as to wait a user of the terminal during the waiting time of a response to a request, continuing to present on the terminal the content being consumed.
  • the control information provides for the use of a second channel, the first and second contents are progressively restored at least partially simultaneously.
  • the second content may be displayed in a multimedia scene associated with the first content.
  • this multimedia scene may have been modified (by means of the scene modification commands) so as to improve the perception of the second content: for example, the sound volume associated with the first content is decreased during the rendering of the second content.
  • the second content is progressively restored in replacement of the first content.
  • the terminal sends a request to interrupt the transmission of the first content to the corresponding server, that is to say to the server providing the first content to the terminal.
  • the control information is an attribute of an element of a multimedia scene carrying a link to the server transmitting said second content.
  • ConnectionPipe This defines a new attribute, noted for example lsr: ConnectionPipe, to indicate whether the second content should be transmitted in the first channel, or in a second channel.
  • this "target” attribute only defines aspects related to rendering. More precisely, this attribute defines the space where the response to the query will be presented, ie where in the multimedia scene where the second content will be restored, but does not define the content distribution conditions, including which communication channel can be used.
  • XLink parameters as defined in the LASeR and SAF formats, also define aspects of rendering. More specifically, these parameters define how to consume a second content related to a first content, received in response to a request separate from that for the first content (main content).
  • said attribute can take one of at least three following values: new channel; - current channel; identifier of a predetermined channel.
  • the attribute can be set to "new"
  • New to define a new channel, or the "current” value to define the current channel, or to use a communication channel name (for example "X channel”) to identify a new channel. predetermined channel.
  • the management method implements a step of transmission by the terminal of a request for explicit closure of an open communication channel, by designating it by its identifier.
  • Another aspect of the invention relates to a communication channel management signal for implementing the communication channel management method described above. More precisely, such a signal emitted by a radiocommunication terminal, includes a control information field indicating whether a second content is to be transmitted in the first channel, or in a second communication channel.
  • control information field can take one of the following values: new channel; current channel; identifier of a predetermined channel.
  • such a signal may include a request to explicitly close an open communication channel by designating it by its identifier.
  • Yet another aspect of the invention relates to a radiocommunication terminal intended to receive at least one multimedia content broadcast by at least one server.
  • Such a terminal comprises means of: progressive restitution of a first content transmitted in a first channel;
  • Such a terminal is particularly suitable for implementing the method of managing the communication channels described above.
  • such a terminal comprises specific means for independently implementing each step of the communication channel management method.
  • Another embodiment of the invention relates to one or more computer program products downloadable from at least one communication network and / or recorded on a computer readable medium and / or executable by a processor, comprising instructions for code of program for implementing at least some steps of the transmission channel management method described above.
  • FIGS. and IB respectively illustrate the restitution of a first content in parallel with the restitution of a second content in two communication channels, and the restitution of a second content following the interruption of the restitution of a first content in a same communication channel
  • FIG. 2 illustrates an example of opening and closing of a second communication channel according to a particular embodiment of the invention
  • FIG. 3 presents the general principle of the invention, according to which a first content, then a second content are transmitted to a radiocommunication terminal, following a request from the terminal
  • FIG. 4 illustrates the various steps implemented according to a particular embodiment of the invention.
  • the general principle of the invention is based on the transmission of a server to a terminal of a first content in a first communication channel, and on the progressive reproduction (consumption) of this first content, with the possibility of interaction with the terminal user. More specifically, a particular embodiment of the invention provides for the transmission to a server of control information, during a request sent by a terminal to request the transmission of a second content, indicating whether this second content must be transmitted in the first channel, or in a second transmission channel.
  • the terminal Upon receiving the response to the request, the terminal can determine whether the reception of the first content must be interrupted and if the second content must reuse the same transmission channel as the first content, or if the reception and consumption of the first content must be continued in parallel with the reception and consumption of the response to the request transmitted in another transmission channel.
  • the invention proposes a completely new and inventive approach to the transmission of multimedia content to a radiocommunication terminal based on the management of the communication channels used during the successive sending of replies to requests within the network. the same service. More specifically, according to a particular embodiment, the invention proposes to report in a new content sent in response to a request information to manage the reuse or not of a communication channel already in use.
  • this transmission signal of a new content may contain information according to which the channel used by the content previously sent and still being consumed (first content), must be cut or not.
  • this signal may contain information that the new content (second content) sent in response to a request must reuse the channel already in use for content previously sent and still being consumed (ie ie re-use the first communication channel).
  • this signal may contain an identifier for the communication channel to be used for the new content sent in response to the request.
  • the server 35 transmits during a first step 41 a first content 37 to the communication terminal 36.
  • the first content 37 (or at least part of this content) is progressively restored on the terminal 36.
  • a transmission in "streaming" mode is used.
  • the user of the terminal 36 wishes to receive a second content, it sends to the server 35 a request 38 in a step 43, asking the server 35 to send the second content.
  • the request 38 also comprises control information indicating whether the second content must be transmitted in the first channel, or in a second channel.
  • the terminal 36 continues to restore the first content during the step 43.
  • the second content 39 is transmitted (in the first or in a second communication channel) and restored on the terminal.
  • this continuity can be obtained by successive updates of the same multimedia scene, the service is then designed so that the user does not see a page change, and all the responses to requests from the user being partial updates of the current scene. In this case, there is no replacement of one scene by another. It should be noted that, conventionally, the replacement is the preferred time to recover all the resources, and in particular any open communication channel.
  • the service begins with successive screens for choosing a first piece of music.
  • the user is considered to have chosen a piece.
  • a request is built and sent to the server.
  • the server responds as an update of the scene with an audio element with its control elements accompanied by a stream of music. This stream of music is played by the terminal at reception.
  • the user is considered to still interact with the service.
  • Some interactions are purely local, and do not give place requests to the server.
  • two types of situation must be distinguished: a first type of situation where the response to the request does not call into question the consumption of the music stream; a second type of situation where the response to the request assumes that the consumption of the music stream stops.
  • the request is, for example, a request for additional information on the music stream, such as a request for presentation of the CD cover, or a request to purchase the physical album.
  • the music stream is transmitted in a first communication channel.
  • the response to the request is transmitted in a second communication channel, then decoded and rendered in the scene that renders the stream of music.
  • this response is rendered in the form of information presented in a temporary window superimposed on the graphical elements related to the control of the consumption of the stream, previously called control elements.
  • the request is, for example, a request for a second stream of music.
  • the server of the second stream may be different from the server of the first stream Therefore it is not certain that the server of the first stream is aware of the request requesting a second stream, and therefore continues the transmission of the first stream. It is therefore the responsibility of the terminal to cut off the communication of the first stream, whether to inform the server of the cessation of consumption and / or to avoid having to delete packets of the first stream contained in the different areas.
  • network buffer Indeed, these buffers often correspond to several seconds of content, from 2 to 10 seconds depending on the situation, which is expensive in terms of resources.
  • this decision can be made through control information contained in the scene information, for example in the commands for changing the scene from one state to another.
  • the request is transmitted via the activation of an element a of the scene, for example a graphic object of the scene.
  • an element has several attributes, as defined in the LASeR and SAF formats. For example, enabling element a results in a call to a URL contained in the xlink: href attribute of this element a.
  • lsrxonnectionPipe added to the element a is defined. It is considered that this attribute can take the values:
  • current defining the current communication channel (in general, the first communication channel) or - an identifier of a predetermined channel, for example in the form of the name of a communication channel.
  • the attribute lsrxonnexionPipe must have the value "new" or the name of a second communication channel different from the name of the first communication channel in use for the music stream. If this first channel In-use communication for the music stream does not have a name, so the lsrxonnexionPipe attribute can have the value "new" or the name of any communication channel.
  • the attribute lsrxonnexionPipe must have the value "current" or the name of the first communication channel, in the course of use for the music stream. If this first communication channel currently in use for the music stream does not have a name, then the lsrxonnexionPipe attribute must have the value "current”.
  • An example of an algorithm used for the implementation of the invention, illustrated by means of scene fragments, is described below. It is understood that in a service situation in LASeR format, the binary equivalent of these scene fragments would be transmitted.
  • Appendix 1 which is an integral part of the description presents a fragment for the scene including the music stream "au” during consumption and comprising two possible queries, a request reql for a request to display the cover, corresponding in the first situation and a request req2 for a transmission request of a second flow corresponding to the second situation.
  • FIG. 1A illustrates the first situation, according to which the music stream "au” is transmitted in a first communication channel and the request does not call into question the consumption of the "au” stream.
  • the terminal Upon receipt of the response to the request reql, the terminal will not cut the reception of the music stream "au", and the display information of the pouch "poch” will be transmitted in a second communication channel.
  • FIG. 1B illustrates the second situation, according to which the music stream "au” is transmitted in a first communication channel and the request calls into question the consumption of the "au” stream.
  • the terminal When receiving the answer 11 at the request req2, the terminal will cut this reception.
  • the music stream "au” is no longer transmitted in the first channel of communication and a second stream noted “track” is transmitted in this first channel.
  • this second stream denoted "track” can be transmitted in a second communication channel.
  • Improvements to this service may be required interactively on a return channel, for example with a GSM, GPRS or UMTS mobile telephone connection.
  • the main feature of such a service is that the terminal remains connected throughout the duration of a broadcast on the DVB-H channel, to continue to receive the flow of basic information of the service.
  • the user is viewing a newscast (JT).
  • JT newscast
  • the beginning of the television newscast is transmitted on the DVB-H channel 20.
  • a request req 22 is sent to a server.
  • the DVB-H channel 20 is maintained and a telephone channel (eg UMTS type) 24 is created for managing the donation form.
  • the transmission of information is terminated and the transmission channel 24 used for receiving the donation form is naturally closed by the server.
  • the request 26 for the first song is sent.
  • the DVB-H channel is maintained, even if the volume of the newscast is temporarily reduced to 0.
  • Another UMTS 28 communication channel, named "song" is opened, and the song starts playing. to be played. The user continues to see the log, with the hotspots, while he is listening to the song. He then wants to go to the second song and activates another clickable area.
  • An object of the "interview" scene corresponding to an element configured as follows is activated:
  • the request 29 (req4) for the second song is sent.
  • the first song continues to play.
  • the connection on the song channel is cut off so that the channel can be reused for the second song.
  • the stamp contents of the first song are destroyed.
  • the second song begins to be played on the song channel.
  • the user then wishes to return to the newscast and transmits a request (req5) 31 return JT.
  • An object corresponding to a conditional element configured as follows is enabled:

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un 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). Selon l'invention, un tel procédé comprend les étapes suivantes : - transmission d'un premier contenu (37) dans un premier canal; - restitution progressive dudit premier contenu (37) dans un terminal; - émission par ledit terminal d'une requête (38) pour un deuxième 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 dudit deuxième contenu (39).

Description

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'un 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 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 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.
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 Génération 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 œuvre 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 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 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 œuvre 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.
Selon un deuxième comportement possible, le premier canal de communication est toujours maintenu ouvert lors de la réception du second contenu, ce qui permet de mettre en œuvre 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 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 œuvre 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 œuvre 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 œuvre 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 œuvre 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 de mettre en œuvre 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 œuvre une technique permettant la réutilisation, pour la réception d'un nouveau contenu ou d'une nouvelle portion du contenu, d'un canal 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 œuvre une telle technique permettant de mettre en œuvre 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 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 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 : - 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 œuvre 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 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. 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 lsr:ConnectionPipe, permettant d'indiquer si le deuxième contenu doit être transmis dans le premier canal, ou dans un deuxième canal.
On constate que dans le standard HTML (Hyper Text Markup 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 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 œuvre 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 <ClosePipe name= « canal X »/>.
Un autre aspect de l'invention concerne un signal de gestion de canaux de communication pour la mise en oeuvre du procédé de gestion de canaux de communication décrit précédemment. Plus précisément, un tel signal émis par un terminal de radiocommunication, 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.
En particulier, le champ d'information de contrôle peut prendre une des valeurs suivantes : nouveau canal ; canal courant ; identificateur d'un canal prédéterminé.
De plus, un tel signal peut comprendre une requête de fermeture explicite d'un canal de communication ouvert en le désignant par son identificateur.
Encore un autre aspect de l'invention concerne un terminal de radiocommunication destiné à recevoir au moins un contenu multimédia diffusé par au moins un serveur.
Un tel terminal 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 contenu doit être transmis dans ledit premier canal, ou dans un second canal ;
- restitution progressive dudit deuxième contenu.
Un tel terminal est notamment adapté à mettre en œuvre le procédé de gestion des canaux de communication décrit précédemment.
En particulier, un tel terminal comprend des moyens spécifiques permettant de mettre en œuvre indépendamment chaque étape du procédé de gestion des canaux de communication.
Finalement, un autre mode de réalisation de l'invention concerne un ou plusieurs produits programmes d'ordinateur téléchargeables depuis au moins un réseau de communication et/ou enregistrés sur un support lisible par ordinateur et/ou exécutables par un processeur, comprenant des instructions de code de programme pour la mise en œuvre d'au moins certaines étapes du procédé de gestion des canaux de transmission décrit précédemment.
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 : les figures IA et IB illustrent respectivement la restitution d'un premier contenu en parallèle à la restitution d'un second contenu dans deux canaux de communication, et la restitution d'un second contenu suite à l'interruption de la restitution d'un premier contenu dans un même canal de communication ; la figure 2 illustre un exemple d'ouverture et de fermeture d'un second canal de communication selon un mode de réalisation particulier de l'invention ; la figure 3 présente le principe général de l'invention, selon lequel un premier contenu, puis un deuxième contenu sont transmis à un terminal de radiocommunication, suite à une requête du terminal ; la figure 4 illustre les différentes étapes mises en œuvre 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 la transmission d'un serveur vers un terminal d'un premier contenu dans un premier canal de communication, et sur la restitution (consommation) progressive de ce premier contenu, avec possibilité d'interaction avec l'utilisateur du terminal. Plus précisément, un mode de réalisation particulier de l'invention prévoit la transmission à un serveur d'une information de contrôle, lors d'une requête émise par un terminal pour demander la transmission d'un deuxième contenu, indiquant si ce deuxième contenu doit être transmis dans le premier canal, ou dans un deuxième canal de transmission. Lors de la réception de la réponse à la requête, le terminal peut déterminer si la réception du premier contenu doit être interrompue et si le second contenu doit réutiliser le même canal de transmission que le premier contenu, ou si la réception et la consommation du premier contenu doit être poursuivie en parallèle de la réception et de la consommation de la réponse à la requête transmise dans un autre canal de transmission.
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 gestion des canaux de communication utilisés lors de l'envoi successif de réponses à des requêtes au sein d'un même service. Plus précisément, selon un mode de réalisation particulier, l'invention propose de signaler dans un nouveau contenu envoyé en réponse à 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 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 œuvre 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 dans 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 Scène Représentation », 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. Il 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 l'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 l'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 lsrxonnectionPipe 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 lsrxonnectionPipe, et permet en plus de couper ultérieurement le canal par une commande explicite, par exemple <ClosePipe name=«X»/> 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 lsrxonnexionPipe 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 lsrxonnexionPipe peut avoir la valeur « new » ou le 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 lsrxonnexionPipe 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 lsrxonnexionPipe doit avoir la valeur « current ». 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 fragment pour la scène comprenant le flux de musique « au » en cours de consommation et comprenant deux requêtes possibles, une requête reql 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. Par exemple, la figure IA 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 reql, le terminal ne coupera pas la réception du flux de musique « au », et les informations d'affichage de la pochette « poch » seront transmises dans un deuxième canal de communication.
La figure IB 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 11 de la réponse à la requête req2, le terminal coupera cette réception. Par conséquent, 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 « broadcast »
(diffusion), par exemple dans un environnement DVB-H. Des améliorations de ce service peuvent être requises de manière interactive sur un canal avec voie de retour, par exemple avec une connexion téléphonique mobile GSM, GPRS ou UMTS.
La caractéristique principale d'un tel service est que le terminal reste connecté pendant toute la durée d'une émission sur le canal DVB-H, pour continuer à recevoir le flux d'informations de base du service. Par exemple, l'utilisateur est en train de visionner un journal télévisé (JT). On note 21 le début du journal télévisé, transmis sur le canal DVB-H 20.
Au cours de ce journal, des informations supplémentaires sont régulièrement proposées sous la forme d'un bandeau défilant dans lequel des zones d'interaction (zones cliquables) donnent accès à des contenus supplémentaires. Voici deux exemples de contenus supplémentaires : - lors de l'interview d'une chanteuse à succès, encore appelé scène
« interview », une écoute de ses trois derniers succès est proposée ; - lors d'un sujet sur une catastrophe naturelle, encore appelé scène « catastrophe », un don en ligne à une organisation caritative est proposé. 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é comme suit est activé : <a id="req" lsr : connexionPipe="new" xlink : href="http : / / * . org/serv?gif t " /> 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 faire 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é :
<a id="req3" lsr : connexionPipe="song" xlink:href="http: //* . org/serv?song=l"/>
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é :
<a id="req4" lsr : connexionPipe≈" song" xlink:href="http: //* . org/serv?song=2"/>
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é :
<lsr : conditional id="req5"> <lsr : ClosePipe name="song"/>
... autres commandes liées au retour au JT... ... dont le retour du volume sonore normal du JT... </lsr : conditional>
A la suite de cette opération, le canal de transmission 28 « song » utilisé pour les deux chansons est fermé et la consommation du flux DVB-H 20 seulement continue.
ANNEXE 1
<saf : SAFSession ...>
<saf : sceneHeader .../> ... (flux d'image utilisés par la scène) ...
<saf :mediaHeader streamID="au" ...entête flux audio... /> <saf : sceneUnit ...> <lsr :NewScene>
<audio xlink:href="stream: au".../>
<a id="reql" lsr : connexionPipe="new" xlink:href="http: //* . org/serv?poch=6553"/>
<a id="req2" lsr : connexionPipe="current" xlink:href="http: //* . org/serv?track=7554"/>
</lsr :NewScene> </saf : sceneUnit> ... paquets audio ad lib ...

Claims

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 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 , 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 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.
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 œuvre 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 1 à 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 contenu doit être transmis dans ledit premier canal, ou dans un second canal ; restitution progressive dudit deuxième contenu.
EP07820660A 2006-10-06 2007-09-27 Procédé de gestion de canaux de communication, signal et terminal correspondants Withdrawn EP2077016A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0608822A FR2924885A1 (fr) 2006-10-06 2006-10-06 Procede de gestion de canaux de communication, signal et terminal correspondants
FR0610362A FR2924886B1 (fr) 2006-10-06 2006-11-27 Procede de gestion de canaux de communication, signal et terminal correspondants.
PCT/EP2007/060272 WO2008040677A1 (fr) 2006-10-06 2007-09-27 Procédé de gestion de canaux de communication, signal et terminal correspondants

Publications (1)

Publication Number Publication Date
EP2077016A1 true EP2077016A1 (fr) 2009-07-08

Family

ID=38870290

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07820660A Withdrawn EP2077016A1 (fr) 2006-10-06 2007-09-27 Procédé de gestion de canaux de communication, signal et terminal correspondants

Country Status (4)

Country Link
US (1) US9166861B2 (fr)
EP (1) EP2077016A1 (fr)
FR (1) FR2924886B1 (fr)
WO (1) WO2008040677A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2942395A1 (fr) * 2014-03-14 2015-09-17 The General Hospital Corporation Systeme et procede pour l'imagerie en volume et en spirale
MX369226B (es) * 2014-10-21 2019-11-01 Sony Corp Aparato de recepcion, metodo de recepcion, aparato de transmision, y metodo de transmision.
US11336744B2 (en) * 2018-01-16 2022-05-17 Comcast Cable Communications, Llc Methods and systems for communicating relevant content

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6882639B1 (en) * 1998-09-21 2005-04-19 Nortel Networks Limited Telecommunications middleware
US7844491B1 (en) * 1999-10-19 2010-11-30 Netzero, Inc. Sponsorship/advertising for an internet client
US6516191B1 (en) * 1999-11-24 2003-02-04 At&T Corp. Hypermedia links that address traffic channels in a wireless communication system
EP1463309A1 (fr) * 2003-03-26 2004-09-29 THOMSON Licensing S.A. Traitement d'un format de flux de données pour la réception audiovisuelle mobile
US20050069225A1 (en) * 2003-09-26 2005-03-31 Fuji Xerox Co., Ltd. Binding interactive multichannel digital document system and authoring tool
US20050123001A1 (en) * 2003-11-05 2005-06-09 Jeff Craven Method and system for providing video and data traffic packets from the same device
US20080046937A1 (en) * 2006-07-27 2008-02-21 LaSean T. Smith Playing Content on Multiple Channels of a Media Device

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2008040677A1 *

Also Published As

Publication number Publication date
US20100029313A1 (en) 2010-02-04
US9166861B2 (en) 2015-10-20
WO2008040677A1 (fr) 2008-04-10
FR2924886B1 (fr) 2013-03-22
FR2924886A1 (fr) 2009-06-12

Similar Documents

Publication Publication Date Title
KR101731133B1 (ko) 주문형 제공을 위한 스트리밍 콘텐츠의 어셈블링
EP3127336B1 (fr) Dispositif et procédé de commande a distance de la restitution de contenus multimedia
US20120143994A1 (en) Selectively receiving media content
US20120079000A1 (en) Selectively receiving media content
EP3646548B1 (fr) Procédé de transmission d&#39;un contenu audio interrompu dans un récepteur hybride, système, récepteur et programme associé au procédé
FR2845555A1 (fr) Procedes de reception et de diffusion de television interactive et dispositifs associes
US20120079059A1 (en) Selectively receiving media content
US20220060532A1 (en) Method for transmitting resources and electronic device
EP1579319B1 (fr) Dispositifs et procédés de décision conditionnelle d&#39;exécution de services reçus et de constitution de messages d&#39;informations associés, des services, et produits associés
WO2007031570A1 (fr) Transmission d&#39; un contenu multimedia vers un terminal de radiocommunication
WO2011073586A1 (fr) Pre-chargement de contenu entre un serveur de contenu et au moins un terminal
WO2008040677A1 (fr) Procédé de gestion de canaux de communication, signal et terminal correspondants
EP3942837A1 (fr) Procédé de gestion de contenus multimédia et dispositif pour la mise en oeuvre du procédé
EP1850602B1 (fr) Procédé et système pour accélérer l&#39;accès à un contenu à partir d&#39;un terminal mobile
FR2924885A1 (fr) Procede de gestion de canaux de communication, signal et terminal correspondants
EP4055831A1 (fr) Procédé de gestion de zapping de contenus multimédias numériques obtenu par téléchargement progressif adaptatif (has), dispositif de gestion, lecteur de flux multimédia et programme d&#39;ordinateur correspondants
Ekudden et al. On-demand mobile media- A rich service experience for mobile users
EP2854415B1 (fr) Procédé de transmission dynamique de données d&#39;information relatives à un programme audio et/ou vidéo
KR20200018890A (ko) 무선 스트리밍 방법
FR3096210A1 (fr) Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.
FR3093603A1 (fr) Procédé de navigation accélérée dans un contenu numérique obtenu par téléchargement progressif adaptatif (HAS), gestionnaire, lecteur de flux multimédia et programme d’ordinateur correspondants.
Patel et al. An Aggregate Functional Software Architecture on Android for End-2-End Real-Time Interactive Content Management to Cater IPTV Services on Digital Handheld Devices
SP et al. ARobust CLIENT ARCHITECTURE ON ANDROID TO CATER END-2-END REAL-TIME CONTENT MANAGEMENT AND PERSONALIZED IPTV SERVICES TO MOBILE INTERNET DEVICES
WO2016156386A1 (fr) Système de diffusion de contenus audio et/ou vidéo par un réseau wifi local, et appareils mettant en œuvre le procédé

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090430

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20100324

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20100804