WO2006134008A1 - Procédé de présentation d'un catalogue de contenus multimédia a un terminal, serveur, terminal, signal de requête et programme informatique correspondants. - Google Patents
Procédé de présentation d'un catalogue de contenus multimédia a un terminal, serveur, terminal, signal de requête et programme informatique correspondants. Download PDFInfo
- Publication number
- WO2006134008A1 WO2006134008A1 PCT/EP2006/062287 EP2006062287W WO2006134008A1 WO 2006134008 A1 WO2006134008 A1 WO 2006134008A1 EP 2006062287 W EP2006062287 W EP 2006062287W WO 2006134008 A1 WO2006134008 A1 WO 2006134008A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- terminal
- catalog
- request
- server
- multimedia contents
- 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.)
- Ceased
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/2866—Architectures; Arrangements
- H04L67/30—Profiles
-
- 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/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- 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/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- 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/2866—Architectures; Arrangements
- H04L67/30—Profiles
- H04L67/303—Terminal profiles
-
- 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/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/565—Conversion or adaptation of application format or content
- H04L67/5651—Reducing the amount or size of exchanged application data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- 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
Definitions
- the field of the invention is that of the presentation of multimedia contents to a communication terminal. More specifically, the invention relates to the presentation of a list, or a catalog, of multimedia content transmitted by a server to a communication terminal, allowing a user to select one of several multimedia content.
- the vast majority of communication terminals for example radio telephones or personal assistants (PDAs) have technical characteristics for viewing multimedia content. However, these characteristics can vary substantially from one terminal to another.
- the content in turn, vary greatly, both in terms of size and size, and require means of restitution very different from each other.
- the communication network is not able to deliver the content selected by the user.
- the video is not downloaded.
- Another disadvantage of this technique of the prior art is that it does not ensure that the user can effectively view the selected multimedia content. Indeed, if the user does not have, or at least little information about the capabilities of the terminal or the types of multimedia content presented in the catalog, the techniques do not ensure that the content selected by the user will be correctly restored on the terminal of the latter. The user will attempt to download content that he can not, in any case, not return on his device.
- the invention particularly aims to overcome these disadvantages of the prior art.
- an object of the invention is to provide a multimedia catalog presentation technique making it possible to simplify the choice of users and not to require from them technical knowledge of the characteristics of their terminal.
- Another objective of the invention is to propose such a technique which eliminates or minimizes the risk of attempts to download content that can not be played on the terminal as a function of these characteristics and of the state of a transmission channel at a given time. given moment.
- the invention also aims to propose such a technique that does not require intervention or special knowledge on the part of the user.
- the invention aims to provide such a technique, which makes it possible to ensure the correct reproduction of the contents of a multimedia catalog presented to a user on his terminal.
- such a method comprises a step of adapting said catalog as a function of at least a first piece of information representative of a current transmission channel and / or of an available useful bit rate, so as to present said terminal multimedia content that can be transmitted to said terminal at a given time.
- the invention is based on a novel and inventive approach to the provision of multimedia content for a communication terminal user, implementing a first piece of information representative of a current transmission channel and / or an available payload.
- the invention proposes a dynamic approach to the catalog of multimedia contents by using this first piece of information.
- the contents actually accessible at a given moment are proposed to the user.
- the catalog may be different, even if the terminal remains the same.
- This first information advantageously comprises an indication of the type of communication standard available for said terminal at said given instant, for example GSM, GPRS, EDGE, UMTS, xDSL, ISDN, PSTN, etc. It makes it possible to refine the contents of the catalog to the multimedia contents that can be restored according to the state of the transmission channel.
- the adaptation of the catalog also takes account of at least one second piece of information representative of the characteristics of said terminal, so as to present to said terminal only multimedia contents that can be restored by said terminal.
- This second information may include at least one of the indications belonging to the group comprising: - a screen format;
- This second information makes it possible to refine the presentation of said catalog of multimedia contents to the contents that can be restored by said terminal according to the specific technical characteristics of the terminal.
- said server manages a first database associating the one or more second information with each type of terminal.
- This first database makes it possible to enrich the request sent by a terminal before it is taken into account for constituting the catalog.
- the adaptation of the catalog also takes account of at least a third piece of information representative of a subscription and / or a preference of the user of said terminal, in order to adapt even more finely the contents of the catalog to terminal, and to take into account the characteristics of the user, by selecting only the contents relating to his subscription and / or his usual preferences. It is thus possible to offer the user or not content that is paid for and / or reserved for certain users, for example as a function of access rights that he has fulfilled and / or parental control features. It is also possible to offer the user content adapted to his tastes.
- this third piece of information is stored in a second database of users, addressable from an identifier of said user, from the server interacting with the user's terminal.
- This second database can also associate each user with a list of at least one application installed in said terminal.
- This list can also be used to define an alternative strategy of fallback in the very unlikely case or none of the first and second information would be available at the time of the request.
- This fallback strategy may for example consist of assigning a minimum default profile, rather than displaying a deceptive error message.
- the request sent by said terminal to the server is a request in the format http, comprising a header.
- This header is used to insert said first, second and / or third information, in order to provide said server with all the parameters enabling it to process the user's request.
- the invention also relates to the structure of such a request, comprising at least one field carrying said first information.
- the invention also relates to the terminals able to implement the method described above and to issue such a request (request signal), and the corresponding servers.
- the invention finally relates to computer programs comprising instructions for implementing all or part of this method, in the terminals, the servers and the intermediate elements of the transmission channel.
- FIG. 1 presents a block diagram, according to the invention, of the processing of a request sent by the communication terminal in order to access the multimedia content of a catalog
- FIG. 2 illustrates the format of this request sent by the terminal of FIG. 1, when it is distributed to the server responsible for processing it
- FIG. 3 describes an embodiment of a presentation of an optimized multimedia content catalog, following a request issued by the terminal
- Figure 4 schematically illustrates the structure of the terminal of Figure 1
- Figure 5 schematically illustrates the structure of the server of Figure 1.
- the general principle of the invention is therefore based on the taking into account of information representative of the transmission channel in order to optimize the catalogs presented on a radiocommunication terminal. It also takes into account information on the type of terminal of the user.
- FIG. 1 is a simplified illustration of an exemplary architecture implementing an embodiment of the invention.
- the radiocommunication terminal 11 sends a request 12 to a multimedia content server 13 (composed, for example, of an http protocol management server 131 and an application server 132) through a server. transmission channel.
- a multimedia content server 13 composed, for example, of an http protocol management server 131 and an application server 132
- the structure of the terminal 11 is illustrated schematically in FIG. 4. It comprises an M 41 memory, and a processing unit 40 equipped with a ⁇ P microprocessor, which is controlled by a computer program (or application).
- the processing unit 40 receives as input, via a network input interface module E 43, server responses 44, which the microprocessor ⁇ P processes, according to the instructions of the program Pg 42, to generate requests 46 , which are transmitted via an S 45 network output interface module.
- the request 12 sent by the terminal 11 contains in particular information identifying the type of the terminal. This information is inserted by the terminal 11 during the transmission of the request 12.
- a dedicated equipment of this transmission channel 10 adds in the request 12 information representative of its state, for example by encapsulation in the header of the request. This information can also be encapsulated in the request 12 directly by the terminal 11, prior to its transmission.
- Such information may be an indication of the available bit rate on the transmission channel, depending on its size, and / or an indication of the type of radiocommunication standard accessible to the terminal (GSM, GPRS,
- the structure of the server 13 is illustrated schematically in FIG. 5. It comprises a memory M 51, and a processing unit 50 equipped with a microprocessor ⁇ P, which is controlled by a computer program (or application) Pg 52.
- processing unit 50 receives, via an input network interface module E 53, client requests 54, which the microprocessor ⁇ P processes, according to the instructions of program Pg 52, to generate responses 56, which are transmitted via an S 55 network output interface module.
- the server 13 therefore uses the information that it has in the header of the request 12 to contact a database of the terminals 14 and / or a database of the subscribers 15 in order to obtain precise information on the terminal.
- the user (request 141 and answer 142) on the one hand and on the subscription and / or the user's preferences on the other hand (request 151 and answer 152).
- the subscriber database 15 which can also be managed directly by the content server 13 or by a device with which it communicates, groups for example for each user radio services managed by the server 13, characteristics of the user's subscription, such as a maximum size of data that can be exchanged during a given subscription period, the type of subscription, or the type of software installed on the device. Access to one and / or the other of these two databases, from the data available in the initial request of the terminal 12 allows the server 13 to define a new request 16 which is issued on the database 17. This new request is an optimized request which is also constructed from the information added in the request 12 by the transmission channel 14, or by the terminal 11.
- the database of the catalogs 17 then sends a response 18 to the server 13.
- This response 18 contains a list of multimedia contents accessible to the terminal 11 according to the technical characteristics of the latter, the state of the channel 14, and possibly the subscription subscribed by the user.
- the latter then builds the page that will be presented to the terminal and returns it to the latter through the response 19 made to the initial request 12.
- a particular example of implementation of the process of FIG. 1 can be obtained from the following technical base, which comprises:
- a multimedia content server 13 comprising: an HTTP protocol management server (web server) 131 which may be, for example, type IIS, Apache, Netscape, SUN iPlanet (registered trademarks). It is it that receives the request 12 and builds the answer (the adapted catalog) 19. This answer is constituted, for example, pages of the video portal built dynamically, presenting the access to the video contents html ("Hypertext markup language") and wml ("wireless markup language”), as well as the best links (URLs ("Uniform Resource Locator”)) streaming, or download. They are also built dynamically.
- the request 19 is intended for the user of the radiocommunication terminal 11.
- the server 131 provides the application server 132 with all the parameters necessary for the system dynamics extracted from the http header.
- An application server 132 It can advantageously be based on:
- Java language can be implemented in the form of independent modules (“servlet”) or in the form of a dynamic JSP content generator ("Java Server Page”), for example IBM WebSphere, BEA Web Logic, Netscape Enterprise Server, Oracle Application Server, SUN
- ASP / COM type language ASP .NET, Microsoft Transaction Server (registered trademarks)
- a Web Services implementation or A PHP type language.
- Application Server implements the following features:
- the technical means implemented also include three databases:
- terminals which contains the multimedia characteristics of the targeted terminals, for example the power of its processor, the size of its screen or its decoding capabilities or the size of its memory, especially for downloading.
- databases can for example be based on tools such as MS SQL Server, MS Access, Oracle 8i, IBM DB2, Oracle, MySQL (registered trademarks).
- the request 12 is transmitted by the radiocommunication terminal. It can be completed by the terminal itself or progressively by one or more intermediate network equipment.
- An example of a completed request structure is illustrated in FIG. 2.
- URL link
- a third field 23 named “accept”, which makes it possible to recover the MIME types ("Multipurpose Internet Mail Extensions") supported by the terminal, and consequently the onboard multimedia reader (s).
- a fifth field 25 making it possible to exploit the characteristics specific to the user of the radiocommunication terminal, for example the terminal subscription offer.
- This request signal structure is very simple, and relies on known databases (http). It does not require any complex means, neither on the terminal side nor on the server side and the intermediate elements of the transmission channel.
- FIG. 3 shows an embodiment of the method for presenting a dynamic audiovisual file, following a request sent by the terminal.
- the principle of the embodiment of this system is as follows:
- the user through the browser 31 on board his radiocommunication terminal sends an HTTP request 311 which invokes a generic audiovisual file on a video portal, intended to broadcast content mode streaming or download.
- the system 32 using the management server of the HTTP protocol 321, retrieves the fields of the request concerning the terminal of the user: User Agent (UA) 21, link (URL) of the "User Agent Profile” (UAProf ) 22, "Accept” 23, and transmits 3211 to the application server 322. It also retrieves the generic video link selected by the user 3211.
- the application server :
- the application server 322 requests the management server of the HTTP protocol 321 to construct a response indicating that it is not possible to read the file selected by the user (3212) .
- the management server of the HTTP protocol 321 transmits this response to the radiocommunication terminal 31 which displays it (312). If the answer to the previous check 3221 does not make it possible to determine the capabilities of the terminal, the application server 322 tries to check if the terminal is compatible with streaming using the "User Agent" field. 21 by querying (3222) the database "terminals".
- the application server 322 asks the management server of the HTTP protocol 321 to construct a response indicating that it is not possible to read the file selected by the user (3212).
- the management server of the HTTP protocol 321 transmits this response to the radiocommunication terminal 31 which displays it (312).
- the application server tries to verify that the terminal is compatible with streaming ("streaming"). ") Using the user's ID by querying the" user preferences "database 3224. In this database the user will have informed, during a previous session, the streaming technology that he wants to use.
- the application server 322 requests the management server of the HTTP protocol 321 to construct a response indicating that it is not possible to read the file selected by the user 3212.
- the management server of the HTTP protocol 321 transmits this response to the radiocommunication terminal 31 which displays it 312.
- the application server If, using one of the preceding steps, the application server has succeeded in identifying the capabilities of the terminal, said application server then queries the content database 3226 to verify that the multimedia file chosen by the user is available in the correct format:
- the application server 322 requests the HTTP 321 management server to construct a response indicating that the requested file is not available to the terminal. 3213.
- the management server of the HTTP protocol 321 transmits this response to the radiocommunication terminal 31 which displays it (313).
- the application server 322 builds the optimum link (URL) 3228 and requests the management server of the HTTP protocol 321 to construct a response 3214 enabling the terminal 31 of the radiocommunication of the user 31.
- URL optimum link
- the terminal invokes, through the http request, a list or a page of said catalog.
- the server then builds this page or this list using information representative of the channel and / or the terminal in order to present to the terminal only the multimedia content that can be restored by the terminal.
- the invention is not limited to radiotelephone type terminals, but can be applied more generally to many types of terminals, such as PDAs, microcomputers, etc.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Information Transfer Between Computers (AREA)
Abstract
L'invention concerne un procédé de présentation d'un catalogue de contenus multimédia transmis par un serveur à un terminal de communication, suite à une requête émise par ledit terminal. Selon l'invention, un tel procédé comprend une étape d'adaptation dudit catalogue en fonction d'au moins une première information représentative d'un canal de transmission courant et/ou d'un débit utile disponible, de façon à ne présenter audit terminal que des contenus multimédia pouvant être transmis audit terminal à un instant donné.
Description
Procédé de présentation d'un catalogue de contenus multimédia à un terminal, serveur, terminal, signal de requête et programme informatique correspondants.
1. Domaine de l'invention Le domaine de l'invention est celui de la présentation de contenus multimédia à un terminal de communication. Plus précisément, l'invention concerne la présentation d'une liste, ou d'un catalogue, de contenus multimédia transmis par un serveur à un terminal de communication, permettant à un utilisateur de sélectionner un contenu multimédia parmi plusieurs. La grande majorité des terminaux de communication, par exemple des radiotéléphones ou des assistants personnels (PDA) possèdent des caractéristiques techniques permettant la visualisation de contenus multimédia. Cependant, ces caractéristiques peuvent varier sensiblement d'un terminal à l'autre. Les contenus, quant à eux, varient fortement, tant en terme de format que de taille, et nécessitent des moyens de restitution très différents les uns des autres.
2. Solutions de l'art antérieur
On connaît déjà plusieurs techniques de présentation de contenus multimédia sur des terminaux de radiocommunication. Elles supposent de multiples interactions avec l'utilisateur du terminal. L'ensemble de ces techniques impose en effet à l'utilisateur d'avoir la connaissance des caractéristiques du terminal et de ses capacités pour choisir, parmi un catalogue multimédia général, les contenus multimédia susceptibles d'être affichés et pris en charge.
Ces techniques sont donc fortement basées sur les choix de l'utilisateur et sur ses capacités à appréhender le fonctionnement de son terminal. Par exemple, pour lire un contenu audiovisuel sur son téléphone portable via le réseau Internet, l'utilisateur doit avoir la connaissance à priori :
- du (des) lecteur(s) de « streaming » (lecture en continue) installé(s) sur son terminal,
- du (des) moyen(s) de téléchargement installé(s) sur son terminal, - de son type de connexion à l'Internet,
- des caractéristiques de son terminal (graphiques, audio, capacité de traitement de décodage, etc.)
Ainsi, dans le cas de vidéos et en fonction de ces paramètres, l'utilisateur doit choisir lui-même parmi une liste de vidéos proposées sur un site « Web » ou « Wap », celle qu'il souhaite visualiser sur son téléphone, parmi une liste complète fournie par le gestionnaire de service.
Il peut être envisagé de préciser, en regard de chaque contenu, les caractéristiques minimales nécessaires. En dernier lieu, soit la vidéo sélectionnée s'affiche correctement, si tout se passe bien, soit l'utilisateur a commis une erreur. Dans ce cas, la vidéo n'est pas restituée.
Il est également possible que le réseau de communication ne soit pas à même de délivrer le contenu sélectionné par l'utilisateur. La vidéo n'est alors pas téléchargée.
3. Inconvénients de l'art antérieur Un inconvénient de ces techniques de l'art antérieur est qu'elles imposent à l'utilisateur un degré de connaissance minimal du monde informatique et multimédia. En effet, les techniques sont incapables de se passer de l'intervention de l'utilisateur pour présenter le contenu multimédia supposé adéquat à afficher. Pourtant, l'utilisateur moyen ne connaît pas précisément les caractéristiques et capacités de son terminal, ni les applications qu'il embarque.
Un autre inconvénient de cette technique de l'art antérieur est qu'elle ne permet pas de s'assurer que l'utilisateur pourra effectivement visualiser le contenu multimédia sélectionné. En effet, si l'utilisateur n'a pas, ou tout le moins peu, d'informations quant aux capacités de son terminal ou quant aux types de contenus multimédia présentés dans le catalogue, les techniques ne permettent pas de s'assurer que le contenu sélectionné par l'utilisateur sera correctement restitué sur le terminal de ce dernier. L'utilisateur tentera donc de télécharger des contenus qu'il ne pourra, en tout état de cause, pas restituer sur son terminal.
Encore un autre inconvénient de ces techniques est que les catalogues proposés sont souvent déceptifs, puisqu'une partie plus ou moins importante
peuvent ne pas être accessibles à un utilisateur. Celui-ci croit y avoir accès, tente un téléchargement et est finalement confronté à un échec. Au bout de quelques échecs, l'utilisateur abandonne le service, qui ne répond pas à ses attentes.
Ce risque d'échec est renforcé dans le domaine des radiocommunications, par le fait que dans certains lieux et/ou dans certaines situations, l'infrastructure ne permet pas la transmission dans de bonnes conditions, de certains contenus, même si, dans l'absolu, le terminal le permet.
4. Objectifs de l'invention
L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur.
Plus précisément, un objectif de l'invention est de fournir une technique de présentation de catalogues multimédia permettant de simplifier le choix des utilisateurs et de ne pas nécessiter de leur part de connaissances techniques des caractéristiques de leur terminal. Un autre objectif de l'invention est de proposer une telle technique qui supprime ou minimise le risque de tentatives de téléchargement de contenus ne pouvant être joués sur le terminal en fonction de ces caractéristiques et de l'état d'un canal de transmission à un instant donné.
Il convient de noter ici que ce dernier point fait partie intégrante de l'invention. En effet, ce problème identifié par les inventeurs n'a jamais été identifié ni traité auparavant.
L'invention a encore pour objectif de proposer une telle technique qui ne nécessite pas d'intervention ou de connaissance particulière de la part de l'utilisateur. En d'autres termes, l'invention a pour objectif de fournir une telle technique, qui permette de s'assurer de la bonne restitution des contenus d'un catalogue multimédia présenté à un utilisateur sur son terminal.
5. Exposé de l'invention
Ces objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints à l'aide d'un procédé de présentation d'un catalogue de contenus multimédia
transmis par un serveur à un terminal de communication, suite à une requête émise par ledit terminal.
Selon l'invention, un tel procédé comprend une étape d'adaptation dudit catalogue en fonction d'au moins une première information représentative d'un canal de transmission courant et/ou d'un débit utile disponible, de façon à ne présenter audit terminal que des contenus multimédia pouvant être transmis audit terminal à un instant donné.
Ainsi, l'invention repose sur une approche nouvelle et inventive de la mise à disposition de contenus multimédia à destination d'un utilisateur de terminal de communication, mettant en œuvre une première information représentative d'un canal de transmission courant et/ou d'un débit utile disponible.
Plus précisément, l'invention propose une approche dynamique du catalogue de contenus multimédia en utilisant cette première information. Ainsi seuls les contenus réellement accessibles à un instant donné, en fonction des disponibilités de l'infrastructure, sont proposés à l'utilisateur.
En un autre lieu et/ou un autre moment, le catalogue pourra être différent, même si le terminal reste le même.
Ainsi, sans connaissance particulière, le choix de l'utilisateur est aidé, puisque seuls les contenus possibles lui sont proposés. Cette première information comprend avantageusement une indication du type de standard de communication disponible pour ledit terminal audit instant donné, par exemple GSM, GPRS, EDGE, UMTS, xDSL, RNIS, RTC, etc. Elle permet d'affiner le contenu du catalogue aux contenus multimédia pouvant être restitués en fonction de l'état du canal de transmission. De façon préférentielle, l'adaptation du catalogue tient compte également d'au moins une deuxième information représentative des caractéristiques dudit terminal, de façon à ne présenter audit terminal que des contenus multimédia pouvant être restitués par ledit terminal.
Cette seconde information peut notamment comprendre au moins une des indications appartenant au groupe comprenant :
- un format d'écran ;
- une capacité de restitution d'images ;
- une capacité de restitution de sons ;
- une capacité de traitement ; - une capacité de mémorisation ;
- une liste d'applications disponibles ;
Cette seconde information permet d'affiner la présentation dudit catalogue de contenus multimédia aux contenus pouvant être restitués par ledit terminal en fonction des caractéristiques techniques propres du terminal. Avantageusement, ledit serveur gère une première base de données associant la ou lesdites deuxièmes informations à chaque type de terminal.
Cette première base de données permet d'enrichir la requête émise par un terminal, avant sa prise en compte pour la constitution du catalogue.
De façon préférentielle, l'adaptation du catalogue tient compte également d'au moins une troisième information représentative d'un abonnement et/ou d'une préférence de l'utilisateur dudit terminal, afin d'adapter encore plus finement le contenu du catalogue au terminal, et de prendre en compte les caractéristiques de l'utilisateur, en ne sélectionnant que les contenus relatifs à son abonnement et/ou à ses préférences usuelles. On peut ainsi proposer ou non à l'utilisateur des contenus payants et/ou réservés à certains utilisateurs, par exemple en fonction de droits d'accès dont il s'est acquitté et/ou de caractéristiques de contrôle parental. Il est également possible de proposer à l'utilisateur des contenus adaptés à ses goûts.
De façon avantageuse, cette troisième information est stockée dans une deuxième base de données d'utilisateurs, adressable à partir d'un identifiant dudit utilisateur, depuis le serveur interagissant avec le terminal de l'utilisateur.
Cette deuxième base de données peut également associer à chaque utilisateur une liste d'au moins une application installée dans ledit terminal. Cette liste peut aussi permettre de définir une stratégie alternative de repli dans le cas très peu probable ou aucune des premières et deuxièmes informations ne serait
disponible au moment de la requête. Cette stratégie de repli peut par exemple consister en l'attribution d'un profil par défaut minimum, plutôt qu'en l'affichage d'un message d'erreur déceptif.
Selon un mode de réalisation avantageux de l'invention, la requête émise par ledit terminal au serveur est une requête au format http, comprenant un entête.
Cet entête est utilisé pour insérer lesdites première, deuxième et/ou troisième informations, afin de fournir audit serveur l'ensemble des paramètres lui permettant de traiter la demande de l'utilisateur.
On procède ainsi à une encapsulation simple et efficace des différentes informations dans la requête.
L'invention concerne également la structure d'une telle requête, comprenant au moins un champ portant ladite première information.
L'invention concerne également les terminaux aptes à mettre en œuvre le procédé décrit ci-dessus et à émettre une telle requête (signal de requête), et les serveurs correspondants.
L'invention concerne enfin les programmes informatiques comprenant des instructions pour mettre en œuvre tout ou partie de ce procédé, dans les terminaux, les serveurs et les éléments intermédiaires du canal de transmission.
6. 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 préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un synoptique, selon l'invention, du traitement d'une requête émise par le terminal de communication en vue d'accéder au contenu multimédia d'un catalogue ; la figure 2 illustre le format de cette requête émise par le terminal de la figure 1, lorsqu'elle est distribuée au serveur chargé de la traiter ; la figure 3 décrit un mode de réalisation d'une présentation d'un catalogue de contenus multimédia optimisés, suite à une requête émise par le
terminal ; la figure 4 illustre, de façon schématique, la structure du terminal de la figure 1 ; la figure 5 illustre, de façon schématique, la structure du serveur de la figure 1.
7. Description d'un mode de réalisation de l'invention
7.1. Principe
Dans le cadre de la présente invention, on s'intéresse donc à la présentation automatique des contenus multimédia restituables à un terminal de radiocommunication en fonction de paramètres, et notamment, l'état courant d'un canal de transmission vers ledit terminal, et/ou les caractéristiques techniques dudit terminal.
Le principe général de l'invention repose donc sur la prise en compte d'une information représentative du canal de transmission afin d'optimiser les catalogues présentés sur un terminal de radiocommunication. On tient compte également de l'information sur le type de terminal de l'utilisateur.
La figure 1 est une illustration simplifiée d'un exemple d'architecture mettant en œuvre un mode de réalisation de l'invention. Le terminal de radiocommunication 11 émet une requête 12 à destination d'un serveur de contenu multimédia 13 (composé, par exemple, d'un serveur de gestion du protocole http 131 et d'un serveur d'application 132) au travers d'un canal de transmission.
La structure du terminal 11 est illustrée schématiquement par la figure 4. Il comprend une mémoire M 41, et une unité de traitement 40 équipée d'un microprocesseur μP, qui est piloté par un programme d'ordinateur (ou application)
Pg 42. L'unité de traitement 40 reçoit en entrée, via un module d'interface d'entrée réseau E 43, des réponses serveur 44, que le microprocesseur μP traite, selon les instructions du programme Pg 42, pour générer des requêtes 46, qui sont transmises via un module d'interface de sortie réseau S 45.
La requête 12 émise par le terminal 11 contient notamment une information identifiant le type du terminal. Cette information est insérée par le terminal 11 lors de l'émission de la requête 12.
Un équipement dédié de ce canal de transmission 10 ajoute dans la requête 12 une information représentative de son état, par exemple par encapsulation dans l'entête de la requête. Cette information peut également être encapsulée dans la requête 12 directement par le terminal 11, préalablement à son émission.
Une telle information peut être une indication du débit disponible sur le canal de transmission, en fonction de son encombrement, et/ou une indication du type de standard de radiocommunication accessible au terminal (GSM, GPRS,
UMTS, EDGE, xDSL, RNIS, RTC, etc.) en fonction de la couverture réseau de la zone géographique dans laquelle il se trouve, et/ou encore une indication d'un niveau de qualité du canal de transmission, fonction par exemple de distorsions liées à la configuration du terrain. La structure du serveur 13 est illustrée schématiquement par la figure 5. Il comprend une mémoire M 51, et une unité de traitement 50 équipée d'un microprocesseur μP, qui est piloté par un programme d'ordinateur (ou application) Pg 52. L'unité de traitement 50 reçoit en entrée, via un module d'interface d'entrée réseau E 53, des requêtes clients 54, que le microprocesseur μP traite, selon les instructions du programme Pg 52, pour générer des réponses 56, qui sont transmises via un module d'interface de sortie réseau S 55.
Le serveur 13 utilise donc les informations dont il dispose dans l'entête de la requête 12 afin de contacter une base de données des terminaux 14 et/ou une base de données des abonnés 15 en vue d'obtenir des informations précises sur le terminal de l'utilisateur (requête 141 et réponse 142) d'une part et sur l'abonnement et/ou les préférences de l'utilisateur d'autre part (requête 151 et réponse 152).
La base de données des terminaux 14, qui peut être gérée directement par le serveur de contenus 13 ou par un équipement avec lequel il communique, regroupe par exemple, pour chaque terminal d'une flotte gérée par le serveur de
contenus 13, un ensemble de caractéristiques techniques du terminal, telles que la puissance de son processeur, la taille de son écran...
De même, la base de données des abonnés 15, qui peut également être gérée directement par le serveur de contenus 13 ou par un équipement avec lequel il communique, regroupe par exemple, pour chaque utilisateur des services de radiocommunication gérés par le serveur 13, des caractéristiques de l'abonnement de l'utilisateur, telles qu'une taille maximale de données pouvant être échangées au cours d'une période d'abonnement donnée, le type d'abonnement ou encore le type de logiciels installés sur le terminal. L'accès à l'une et/ou l'autre de ces deux bases de données, à partir des données disponibles dans la requête initiale du terminal 12 permet au serveur 13 de définir une nouvelle requête 16 qui est émise sur la base de données des catalogues 17. Cette nouvelle requête est une requête optimisée qui est également construite à partir de l'information ajoutée dans la requête 12 par le canal de transmission 14, ou encore par le terminal 11.
La base de données des catalogues 17 renvoie alors une réponse 18 au serveur 13. Cette réponse 18 contient une liste de contenus multimédia accessibles au terminal 11 en fonction des caractéristiques techniques de ce dernier, de l'état du canal 14, et éventuellement de l'abonnement souscrit par l'utilisateur. Ce dernier construit alors la page qui va être présentée au terminal et la renvoie à ce dernier par le biais de la réponse 19 faite à la requête initiale 12.
Un exemple particulier d'implémentation du processus de la figure 1 peut être obtenu à partir du socle technique suivant, qui comprend :
Un serveur de contenus multimédia 13 comprenant : - Un serveur de gestion du protocole http (serveur Web) 131 qui peut être par exemple de type IIS, Apache, Netscape, SUN iPlanet (marques déposées). C'est lui qui réceptionne la requête 12 et construit la réponse (le catalogue adapté) 19. Cette réponse est constituée, par exemple, des pages du portail vidéo construites dynamiquement, présentant l'accès aux contenus vidéos html
(« hypertext markup langage ») et wml (« wireless markup langage »), ainsi que les meilleurs liens (URLs (« Uniform Resource Locator »)) de lecture en continu (streaming), ou de téléchargement. Elles sont aussi construites dynamiquement. La requête 19 est destinée à l'utilisateur du terminal de radiocommunication 11. Le serveur 131 fournit au serveur d'applications 132 l'ensemble des paramètres nécessaires à la dynamique du système extrait de l'entête http. Un serveur d'application 132. Il peut avantageusement être basé sur :
Le langage java et être implémenté sous la forme de modules indépendants (« servlet ») ou sous la forme d'un générateur dynamique de contenu JSP (« Java Server Page »), par exemple IBM WebSphere, BEA Web Logic, Netscape Enterprise server, Oracle Application Server, SUN
Iplanet (marques déposées),
Un langage de type ASP/COM (ASP .NET, Microsoft Transaction Server (marques déposées)), Une implémentation de Services Web ou Un langage de type PHP. erveur d'application met en œuvre les fonctionnalités suivantes :
Récupération du champ « User- Agent » des requêtes HTTP pour connaître le type de terminal connecté. Le résultat permet, par exemple, de déterminer le(s) lecteur(s) embarqués et/ou le(s) navigateur(s) installés.
Extraction d'un identifiant terminal (« U-A Profile ») pour interroger la base de données "Terminaux" 14. Le résultat permet de connaître les caractéristiques du terminal (caractéristiques de base et le cas échéant optionnelles), par
exemple ses caractéristiques d'écran, le nombre de couleurs et/ou le nombre de pixels.
Récupération du champ « accept » des requêtes http 12 pour connaître, le cas échéant, au travers des « Content Types » (« Types de contenus ») supportés par le mobile, le ou les applications embarquées sur le terminal et en particulier le(s) lecteur(s) installé(s) sur le terminal.
Interrogation de la base de données « Contenus » 17 pour récupérer les flux de contenus les mieux adaptés au terminal de l'utilisateur.
Construction de la page présentant les liens vers les contenus les mieux adaptés en fonction de la capacité multimédia du terminal ou d'une page d'erreur si le terminal n'est pas adapté à la lecture en continu (streaming) ou au téléchargement. Dans une variante de réalisation de l'invention, il est également possible de se passer du serveur d'application en utilisant une technologie de génération dynamique directement supportée par les serveurs Web 131 telle que CGI ou ASP. Ces technologies fournissent en effet des moyens de traitement de l'information sensiblement comparables à ceux proposés par le serveur d'application.
Les moyens techniques mis en œuvre comprennent aussi trois bases de données :
La base de données des "terminaux" 14, qui contient les caractéristiques multimédia des terminaux visés, par exemple la puissance de son processeur, la taille de son écran ou encore ses capacités de décodage ou la taille de sa mémoire, pour le téléchargement notamment.
La base de données des abonnements/préférences utilisateurs 15, qui contient les caractéristiques de l'abonnement de l'utilisateur, par exemple sa durée, le nombre de téléchargements autorisés, ainsi
que ses préférences, notamment quant aux logiciels qui sont installés sur son terminal, par exemple les logiciels de traitement et de restitution des contenus, et/ou des informations relatives à ses goûts ou ses spécificités (région, profession, âge, sexe...). - La bases de données "catalogues" 17, qui contient les références et descriptions de tous les contenus disponibles pour le portail vidéo et pour les terminaux visés.
Ces bases de données peuvent par exemple être basées sur des outils tels que MS SQLServer, MS Access, Oracle 8i, IBM DB2, Oracle, MySQL (marques déposées).
Les requêtes vers les bases de données (141, 151, 16) ainsi que les réponses à ces requêtes (142, 152, 18) devront permettre à la fois de récupérer les caractéristiques du terminal et de construire la page vidéo présentant les liens les mieux adaptés au terminal de l'utilisateur. 7.2. Exemple de requête
Selon l'invention, la requête 12 est émise par le terminal de radiocommunication. Elle peut être complétée par le terminal lui-même ou progressivement par un ou plusieurs équipements intermédiaires du réseau. Un exemple de structure de requête complétée est illustré en figure 2. Celle-ci comprend : un premier champ 21 « User Agent » : c'est un champ qui est fourni par tous les navigateurs implantés sur les terminaux de radiocommunications qui disposent de capacités multimédia. Ce champ permet d'identifier le type de terminal. - Une information spécifique 22 « User Agent Profile » contenue dans le premier champ 21 : il s'agit d'un lien (URL) qui est fourni par le constructeur de terminal et qui permet de récupérer l'ensemble des caractéristiques techniques du terminal, et qui permet de vérifier les caractéristiques du terminal directement sur le site Internet de son constructeur.
un troisième champ 23, nommé « accept », qui permet de récupérer les types MIME (« Multi Purpose Internet Mail Extensions ») supportés par le terminal, et par conséquent le(s) lecteur(s) multimédia embarqué(s). un quatrième champ 24, nommé « bearer » (ou « première information » selon les revendications), qui renseigne sur le type de canal de transmission utilisé par le terminal de radiocommunication, par exemple GPRS ou UMTS, xDSL, RNIS, RTC et/ou toute information relative à un débit instantané mesuré, un cinquième champ 25, permettant d'exploiter les caractéristiques propres à l'utilisateur du terminal de radiocommunication, par exemple l'offre d'abonnement du terminal.
Un dernier champ 26, à savoir la liste ou le catalogue qui a été demandé par le terminal. Cette structure de signal de requête est très simple, et s'appuie sur des bases connues (http). Elle ne nécessite aucun moyen complexe, ni du côté du terminal, ni du côté du serveur et des éléments intermédiaires du canal de transmission.
7.3. Exemple de mise en œuvre
On présente, en relation avec la figure 3, un mode de réalisation du procédé de présentation d'un fichier audiovisuel dynamique, suite à une requête émise par le terminal.
Le principe du mode de réalisation de ce système est le suivant : L'utilisateur à travers le navigateur 31 embarqué sur son terminal de radiocommunication lance une requête HTTP 311 qui invoque un fichier audiovisuel générique sur un portail vidéo, destiné à diffuser des contenus en mode lecture en continu (streaming) ou en téléchargement. Le système 32, à l'aide du serveur de gestion du protocole HTTP 321, récupère les champs de la requête concernant le terminal de l'utilisateur : User Agent (UA) 21, lien (URL) du « User Agent Profile » (UAProf) 22,
« accept » 23, et les transmet 3211 au serveur d'application 322. Il récupère également le lien vidéo générique choisi par l'utilisateur 3211. Le serveur d'application :
Essaie dans un premier temps de vérifier si le terminal est compatible avec la lecture en continu (streaming) à l'aide du champ
« accept » de l'entête http 3221.
Si la réponse à cette vérification 3221 est négative, le serveur d'application 322 demande au serveur de gestion du protocole HTTP 321 de construire une réponse indiquant qu'il n'est pas possible de lire le fichier sélectionné par l'utilisateur (3212). Le serveur de gestion du protocole HTTP 321 transmet cette réponse au terminal de radiocommunication 31 qui l'affiche (312). Si la réponse à la vérification précédente 3221 ne permet pas de déterminer les capacités du terminal, le serveur d'application 322 essaie de vérifier si le terminal est compatible avec la lecture en continu (streaming) à l'aide du champs « User Agent » 21 en interrogeant (3222) la base de données "terminaux". Si la réponse à la requête d'interrogation de la base de données des terminaux 3222 est négative, le serveur d'application 322 demande au serveur de gestion du protocole HTTP 321 de construire une réponse indiquant qu'il n'est pas possible de lire le fichier sélectionné par l'utilisateur (3212). Le serveur de gestion du protocole HTTP 321 transmet cette réponse au terminal de radiocommunication 31 qui l'affiche (312). - Si la réponse 3223 à la requête d'interrogation de la base de données des terminaux 3222 ne permet pas de déterminer les capacités du terminal, le serveur d'application tente de vérifier que le terminal est compatible avec la lecture en continu (« streaming ») à l'aide de l'identifiant de l'utilisateur en interrogeant la base de données "préférences utilisateur" 3224.
Dans cette base de données l'utilisateur aura renseigné, lors d'une précédente session, la technologie de lecture en continu (« streaming ») qu'il souhaite utiliser.
Si la réponse 3225 à la requête sur cette base de données 3224 est négative, le serveur d'application 322 demande au serveur de gestion du protocole HTTP 321 de construire une réponse indiquant qu'il n'est pas possible de lire le fichier sélectionné par l'utilisateur 3212. Le serveur de gestion du protocole HTTP 321 transmet cette réponse au terminal de radiocommunication 31 qui l'affiche 312.
Si, à l'aide d'une des étapes précédentes, le serveur d'application a réussi à identifier les capacités du terminal, ledit serveur d'application interroge alors la base de données contenus 3226 afin de vérifier que le fichier multimédia choisi par l'utilisateur est bien disponible dans le format adéquat :
Si la réponse 3227 à la requête sur cette base de données des contenus 3226 est négative, le serveur d'application 322 demande au serveur de gestion du protocole HTTP 321 de construire une réponse indiquant que le fichier demandé n'est pas disponible pour le terminal de radiocommunication de l'utilisateur 3213. Le serveur de gestion du protocole HTTP 321 transmet cette réponse au terminal de radiocommunication 31 qui l'affiche (313). Si la réponse 3227 à la requête sur cette base de données des contenus 3226 est positive, le serveur d'application 322 construit le lien (URL) optimum 3228 et demande au serveur de gestion du protocole HTTP 321 de construire une réponse 3214 permettant au terminal de radiocommunication de l'utilisateur 31 d'accéder à ce contenu 314.
Bien sûr, de nombreuses variantes et adaptations peuvent être apportées dans la mise en œuvre de ce procédé, dès lors que l'on prend en compte au moins une information représentative du canal pour adapter le catalogue.
7.4 Autres modes de réalisation Selon un autre mode de réalisation préférentiel, on peut prévoir de mettre en œuvre une invocation de liste ou de catalogue de données multimédia, par le terminal. Dans ce mode de réalisation, le terminal invoque, au travers de la requête http, une liste ou une page dudit catalogue. Le serveur construit alors cette page ou cette liste à l'aide des informations représentatives du canal et/ou du terminal afin de ne présenter au terminal que les contenus multimédia restituables par le terminal.
Par ailleurs, l'invention ne se limite pas aux terminaux de type radiotéléphones, mais peut s'appliquer plus généralement à de nombreux types de terminaux, comme les PDA, les micro-ordinateurs...
Claims
1. Procédé de présentation d'un catalogue de contenus multimédia transmis par un serveur à un terminal de communication, suite à une requête émise par ledit terminal, caractérisé en ce qu'il comprend une étape d'adaptation dudit catalogue en fonction d'au moins une première information représentative d'un canal de transmission courant et/ou d'un débit utile disponible, de façon à ne présenter audit terminal que des contenus multimédia pouvant être transmis audit terminal à un instant donné.
2. Procédé selon la revendication 1, caractérisé en ce que ladite première information comprend une indication d'un type de standard de communication disponible pour ledit terminal audit instant donné.
3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite adaptation du catalogue tient compte également d'au moins une deuxième information représentative des caractéristiques dudit terminal, de façon à ne présenter audit terminal que des contenus multimédia pouvant être restitués par ledit terminal.
4. Procédé selon la revendication 3, caractérisé en ce que ladite deuxième information comprend au moins une des indications appartenant au groupe comprenant :
- un format d'écran ;
- une capacité de restitution d'images ;
- une capacité de restitution de sons ;
- une capacité de traitement ; - une capacité de mémorisation ;
- une liste d'applications disponibles.
5. Procédé selon la revendication 4, caractérisé en ce que ledit serveur gère une première base de données associant la ou lesdites deuxièmes informations à chaque type de terminal.
6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite adaptation du catalogue tient compte également d'au moins une troisième information représentative d'un abonnement et/ou d'une préférence de l'utilisateur dudit terminal.
7. Procédé selon la revendication 6, caractérisé en ce que ladite troisième information est stockée dans une deuxième base de données d'utilisateurs, adressable à partir d'un identifiant dudit utilisateur.
8. Procédé selon la revendication 7, caractérisé en ce que ladite deuxième base de données associe également à chaque utilisateur une liste d'au moins une application installée dans ledit terminal.
9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ladite requête est une requête au format http, comprenant un entête, et en ce qu'on insère dans ledit entête lesdites première, deuxième et/ou troisième informations.
10. Serveur de contenus multimédia comprenant des moyens de transmission d'un catalogue de contenus multimédia à un terminal de communication en réponse à une requête émise par ledit terminal, caractérisé en ce qu'il comprend des moyens d'adaptation dudit catalogue en fonction d'au moins une première information représentative d'un canal de transmission courant et/ou d'un débit utile disponible, de façon à ne présenter audit terminal que des contenus multimédia pouvant être transmis audit terminal à un instant donné.
11. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en œuvre des étapes du procédé de présentation d'un catalogue de contenus multimédia selon l'une quelconque des revendications 1 à 8.
12. Procédé de requête d'un catalogue de contenus multimédia par un terminal de communication à l'aide d'une requête émise par ledit terminal, caractérisé en ce que ledit terminal insère dans cette requête au moins une information représentative de ses capacités.
13. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en œuvre des étapes du procédé d'invocation d'un catalogue de contenus multimédia selon la revendication 12.
14. Terminal de communication comprenant des moyens d'émission d'une requête vers un serveur et des moyens d'affichage d'un catalogue de contenus multimédia transmis par ledit serveur, en réponse à ladite requête, caractérisé en ce qu'il comprend des moyens d'insertion dans ladite requête d'au moins une première information représentative d'un canal de transmission courant et/ou d'un débit utile disponible, de façon à ce que ledit catalogue ne contienne que des contenus multimédia pouvant être transmis audit terminal à un instant donné.
15. Signal de requête de présentation d'un catalogue de contenus multimédia transmis par un serveur à un terminal de communication, suite à une requête préalable émise par ledit terminal, caractérisé en ce qu'il comprend un champ contenant au moins une première information représentative d'un canal de transmission courant et/ou d'un débit utile disponible, de façon à permettre une adaptation dudit catalogue par ledit serveur et à ne présenter audit terminal que des contenus multimédia pouvant être transmis audit terminal à un instant donné.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP06763140A EP1891552A1 (fr) | 2005-06-16 | 2006-05-12 | Procédé de présentation d'un catalogue de contenus multimédia a un terminal, serveur, terminal, signal de requête et programme informatique correspondants. |
| US11/917,704 US20090150512A1 (en) | 2005-06-16 | 2006-05-12 | Method for presenting a catalog of multimedia contents to a terminal, corresponding server, terminal, request signal and computer program |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0506130 | 2005-06-16 | ||
| FR0506130 | 2005-06-16 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2006134008A1 true WO2006134008A1 (fr) | 2006-12-21 |
Family
ID=35466509
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/EP2006/062287 Ceased WO2006134008A1 (fr) | 2005-06-16 | 2006-05-12 | Procédé de présentation d'un catalogue de contenus multimédia a un terminal, serveur, terminal, signal de requête et programme informatique correspondants. |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20090150512A1 (fr) |
| EP (1) | EP1891552A1 (fr) |
| WO (1) | WO2006134008A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11349904B2 (en) * | 2019-04-03 | 2022-05-31 | Citrix Systems, Inc. | Selecting a mode of delivery to provide access to a file systems and methods |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6167441A (en) * | 1997-11-21 | 2000-12-26 | International Business Machines Corporation | Customization of web pages based on requester type |
| US6345279B1 (en) * | 1999-04-23 | 2002-02-05 | International Business Machines Corporation | Methods and apparatus for adapting multimedia content for client devices |
| WO2002023857A2 (fr) * | 2000-09-11 | 2002-03-21 | Viafone, Inc. | Procede et systeme d'integration d'applications et de reseaux mobiles |
| US20020143972A1 (en) * | 2001-01-12 | 2002-10-03 | Charilaos Christopoulos | Interactive access, manipulation,sharing and exchange of multimedia data |
| EP1594287A1 (fr) * | 2004-04-12 | 2005-11-09 | Industry Academic Cooperation Foundation Kyunghee University | Procédés, dispositifs et média de stockage pour la mise à disposition des services multimédia en considérant la capabilité de terminal |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0674414B1 (fr) * | 1994-03-21 | 2002-02-27 | Avid Technology, Inc. | Appareil et processus installés sur ordinateur pour assurer un transport de données multimédia en temps réel dans un système informatique distribué |
| US6594699B1 (en) * | 1997-10-10 | 2003-07-15 | Kasenna, Inc. | System for capability based multimedia streaming over a network |
| US6470378B1 (en) * | 1999-03-31 | 2002-10-22 | Intel Corporation | Dynamic content customization in a clientserver environment |
| US7054938B2 (en) * | 2000-02-10 | 2006-05-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for network service reservations over wireless access networks |
| US20010047517A1 (en) * | 2000-02-10 | 2001-11-29 | Charilaos Christopoulos | Method and apparatus for intelligent transcoding of multimedia data |
| US7016963B1 (en) * | 2001-06-29 | 2006-03-21 | Glow Designs, Llc | Content management and transformation system for digital content |
| US7461067B2 (en) * | 2002-09-13 | 2008-12-02 | Motricity, Inc. | System for supporting production, management and delivery of media content for wireless devices |
-
2006
- 2006-05-12 WO PCT/EP2006/062287 patent/WO2006134008A1/fr not_active Ceased
- 2006-05-12 US US11/917,704 patent/US20090150512A1/en not_active Abandoned
- 2006-05-12 EP EP06763140A patent/EP1891552A1/fr not_active Withdrawn
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6167441A (en) * | 1997-11-21 | 2000-12-26 | International Business Machines Corporation | Customization of web pages based on requester type |
| US6345279B1 (en) * | 1999-04-23 | 2002-02-05 | International Business Machines Corporation | Methods and apparatus for adapting multimedia content for client devices |
| WO2002023857A2 (fr) * | 2000-09-11 | 2002-03-21 | Viafone, Inc. | Procede et systeme d'integration d'applications et de reseaux mobiles |
| US20020143972A1 (en) * | 2001-01-12 | 2002-10-03 | Charilaos Christopoulos | Interactive access, manipulation,sharing and exchange of multimedia data |
| EP1594287A1 (fr) * | 2004-04-12 | 2005-11-09 | Industry Academic Cooperation Foundation Kyunghee University | Procédés, dispositifs et média de stockage pour la mise à disposition des services multimédia en considérant la capabilité de terminal |
Non-Patent Citations (2)
| Title |
|---|
| INTERNATIONAL ORGANISATION FOR STANDARDISATION: "Call for Proposals for Lightweight Scene Representation", ISO/IEC JTC1/SC29/WG11 N6337, XX, XX, March 2004 (2004-03-01), pages 1 - 15, XP002335016 * |
| W3C-NILSSON ET AL: "Composite Capabilities/Preference Profiles: Requirements and Architecture", W3C WORKING DRAFT, XX, XX, 21 July 2000 (2000-07-21), pages 1 - 30, XP002335015 * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20090150512A1 (en) | 2009-06-11 |
| EP1891552A1 (fr) | 2008-02-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2124416B1 (fr) | Procédé de gestion de paramètres pour délivrer des contenus spontanés, procédé pour délivrer des contenus spontanés, procédé pour fournir des contenus spontanés, terminal et système distant associés | |
| US8307092B2 (en) | Method and system for collecting information about a user's media collections from multiple login points | |
| EP1204044A1 (fr) | Procédé et système d'optimisation de consultations d'ensembles de données par une pluralité de clients | |
| EP1943638A1 (fr) | Procede de gestion de polices de caracteres a l'interieur de scenes multimedia, programme d'ordinateur et terminal correspondants | |
| FR2870022A1 (fr) | Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair | |
| EP3155823A1 (fr) | Gestion par un équipement intermédiaire de la qualité de transmission d'un flux de données vers un terminal mobile | |
| FR2869133A1 (fr) | Systeme et procede de tracabilite de contenus electroniques syndiques via un reseau de communication de type internet | |
| FR3064437A1 (fr) | Procede de recommandation d'une pile de communication | |
| EP2513788A1 (fr) | Pre-chargement de contenu entre un serveur de contenu et au moins un terminal | |
| WO2006134008A1 (fr) | Procédé de présentation d'un catalogue de contenus multimédia a un terminal, serveur, terminal, signal de requête et programme informatique correspondants. | |
| WO2008050042A2 (fr) | Procede et systeme de gestion des capacites informatiques d'un terminal | |
| WO2011124810A1 (fr) | Gestion de service personnalisee dans un reseau ip | |
| FR2929480A1 (fr) | Procede de determination de donnees complementaires relatives a au moins un contenu, procede pour transmettre ces donnees complementaires, dispositif de traitement et serveur d'applications associes | |
| EP1494419B1 (fr) | Système de transmission de paramètres caractéristiques d'une session de communication d'un terminal vers un serveur distant | |
| EP4100905B1 (fr) | Plateforme de gestion des préférences en matière de données personnelles | |
| EP2320623B1 (fr) | Procédé de fourniture d'un service | |
| EP1894407B1 (fr) | Procede et dispositif de securite pour la gestion d'acces a des contenus multimedias | |
| EP1872552A2 (fr) | Procede d alerte lors d une modification de contenu et systeme pour la mise en oeuvre du procede | |
| EP4505341A1 (fr) | Système de distribution de contenu internet personnalisé | |
| EP2957104B1 (fr) | Procédé de sélection de la représentation des segments d'un contenu multimédia transmis sur un réseau de communication | |
| FR2883685A1 (fr) | Procede et systeme de partage d'attributs personnels, module de partage/d'insertion/de terminal, fournisseur d'acces internet, serveur proxy, fournisseur de services et programme d'ordinateur pour ce procede | |
| FR2927716A1 (fr) | Procede pour obtenir des informations relatives a des consultations de contenus et equipements associes | |
| FR2920937A1 (fr) | Procede de diffusion d'informations d'une plateforme integrant un serveur et une base de donnees vers un terminal mobile | |
| FR3079711A1 (fr) | Procede de gestion d'acces a un contenu numerique. | |
| WO2003030514A2 (fr) | Procede et systeme d'acces en lignes au contenu de serveurs en reseau par un cd-rom |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| WWW | Wipo information: withdrawn in national office |
Country of ref document: DE |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 2006763140 Country of ref document: EP |
|
| WWP | Wipo information: published in national office |
Ref document number: 2006763140 Country of ref document: EP |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 11917704 Country of ref document: US |