WO2006134055A1 - Procede de gestion de l'execution par un serveur d'une application offrant au moins un service multimedia interactif a au moins un terminal, produit programme d'ordinateur et serveur correspondants - Google Patents
Procede de gestion de l'execution par un serveur d'une application offrant au moins un service multimedia interactif a au moins un terminal, produit programme d'ordinateur et serveur correspondants Download PDFInfo
- Publication number
- WO2006134055A1 WO2006134055A1 PCT/EP2006/062982 EP2006062982W WO2006134055A1 WO 2006134055 A1 WO2006134055 A1 WO 2006134055A1 EP 2006062982 W EP2006062982 W EP 2006062982W WO 2006134055 A1 WO2006134055 A1 WO 2006134055A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- server
- terminal
- application
- communication
- converting
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 40
- 230000002452 interceptive effect Effects 0.000 title claims abstract description 22
- 238000004891 communication Methods 0.000 claims abstract description 41
- 238000012545 processing Methods 0.000 claims description 44
- 230000011664 signaling Effects 0.000 claims description 21
- 238000006243 chemical reaction Methods 0.000 claims description 7
- 238000004590 computer program Methods 0.000 claims description 6
- 108091006146 Channels Proteins 0.000 claims 1
- 238000012544 monitoring process Methods 0.000 abstract 1
- 230000008569 process Effects 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 206010010904 Convulsion Diseases 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 238000006073 displacement reaction Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 238000003909 pattern recognition Methods 0.000 description 1
- 238000002203 pretreatment Methods 0.000 description 1
- 238000012559 user support system Methods 0.000 description 1
Classifications
-
- 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/75—Media network packet handling
- H04L65/762—Media network packet handling at the source
-
- 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/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
Definitions
- a method of managing the execution by a server of an application providing at least one interactive multimedia service to at least one terminal, corresponding computer program product and server.
- the field of the invention is that of audio and / or video communications, which take place on a switched telephone network type communication network, integrated services digital network, packet-switched network, or wireless telephone network, or any network that allows audio and / or video communication.
- the invention relates to a technique allowing terminals capable of receiving multimedia streams (containing information of the audio and / or video type) to access interactive multimedia services offered by applications.
- Each server can be a single machine or distributed on multiple machines.
- the invention applies in particular, but not exclusively, to the case of a server providing at least one interactive multimedia service to videophones.
- a WEB browser is an example of a thin client integrated by a terminal. It allows the particular terminal to connect to an http server, using the http protocol (hypertext transfer protocol), to transfer and display web pages in HTML ("HyperText Markup Language" or hypertext markup language) . It is important to note that, with regard to the outputs of the application executed by the server, the server does not transmit to the terminal a multimedia stream (Web pages) that the terminal can present directly, without prior processing. The server transmits information (HTML tags) that the device's web browser must process in order to generate a multimedia stream.
- HTML HyperText Markup Language
- the terminal does not transmit directly to the server the user's inputs (made for example via a keyboard or a joystick), without pre-treatment.
- the device's web browser must process these entries to convert them to http requests that are then sent to the server.
- PCs personal computers
- GotoMyPC registered trademark
- PcAnyWhere registered trademark
- Symantec software for remote control of a PC
- one of the objectives of the present invention is to provide a management technique for execution by a server of an application offering at least one interactive multimedia service to at least one terminal, this technique being able to be implemented with terminals with limited capacity, without the need for these terminals to run a thin client.
- the invention also aims, in at least one embodiment, to provide such a technique allowing the terminal to access an application (application) by controlling it.
- the invention also aims, in at least one embodiment, to provide such a technique allowing the terminal to access an application
- Another object of the invention in at least one embodiment, is to provide such a technique that is simple to implement and inexpensive.
- a complementary objective of the invention in at least one embodiment, is to provide such a technique that does not require any modification of the existing low capacity terminals, such as videophone for example. 4. Presentation of the invention
- the method comprises the following steps performed by the server: conversion of the outputs of the application in the form of at least a first multimedia stream that can be presented by said at least one terminal; and - transmitting said at least one first multimedia stream to said at least one terminal, via a communication established between the server and said at least one terminal.
- the general principle of the invention is therefore to perform, in the server, a conversion on the outputs of the application, so that after conversion they are compatible with the terminals, without them run a particular thin client (browser Web or other).
- it is the server that adapts the service, and more specifically the outputs of the application, to the most basic terminals, which are only required to be able to receive multimedia streams (for example a stream audio video, for a videophone).
- the invention allows one or more basic terminals to individually or multiple access to a multitude of services running on a remote server (which itself is executed by a single machine or several machines).
- the method further comprises the following steps performed by the server: reception of the inputs of the application that said at least one terminal transmits to the server, via said communication; and converting application entries into commands to control the application.
- the terminal or terminals can control the application, despite that they do not run any particular thin client (web browser or other). Again, it is the server that adapts the service to the most basic terminals, which are only required to be able to send the inputs of the application (for example DTMF signals generated by user support on a keyboard, for a videophone).
- the server receives the application inputs from said at least one terminal in at least one second multimedia stream and / or in at least one signaling channel associated with said communication.
- the step of converting the outputs of the application in the form of at least one first multimedia stream is based on a technique belonging to the group comprising (non-exhaustive list): capture at determined times of an image of screen resulting from the execution of the application, and conversion of the captured image sequence thus achieved into at least one video stream, in real time; implementation by the application of a direct display in memory, and conversion of the direct display in memory in at least one video stream.
- the server comprises a signaling server and a processing server, and the processing server performs the step of converting the outputs of the application and the step of transmitting said at least one first multimedia stream.
- the invention can be applied both in the case where the server is run on one or more machines dedicated to the provision of said at least one interactive multimedia service that in the case where the server is run on one or more machines not dedicated to providing said at least one interactive multimedia service.
- said at least one terminal is a basic terminal not integrating any particular processing capability.
- the terminal is for example a videophone. It is clear that, more generally, the invention applies to any type of terminal capable of receiving and presenting a multimedia stream coming from the server and, if the terminal must pilot the application, to send in a raw manner (c ' that is, without processing) the application's entries to the server.
- the server is seen by said at least one terminal as a call termination point.
- the server is intercalated in a transparent manner, at the end of a communication between said at least one terminal and another terminal.
- the invention also relates to a computer program product downloadable from a communication network and / or recorded on a computer readable medium and / or executable by a processor, this computer program product including program code instructions for the computer program. execution of the steps of the aforementioned method, when said program is executed on a computer.
- the invention also relates to a server of the type enabling the execution of an application offering at least one interactive multimedia service to at least one terminal connected to the server via a communication network.
- the server comprises: means for converting the outputs of the application in the form of at least one first multimedia stream that can be presented by the at least one terminal
- FIG. 1 shows an exemplary system in which the method according to the invention can be implemented, comprising a server according to the invention
- FIG. 2 presents a flowchart of a particular embodiment of the method according to the invention
- FIG. 3 is a simplified representation of the service rendered to a terminal by a server according to the invention
- FIG. 4 shows a functional block diagram of a particular embodiment of the server according to the invention, comprising a signaling server and a processing server
- FIGS. 5, 6 and 7 each show a distinct example of exchange kinematics between a terminal and the signaling and processing servers appearing in FIG. 4
- Figure 8 shows the structure of a machine running a server according to the invention. 6.
- the invention therefore relates to a method for managing the execution by a server of an application offering at least one interactive multimedia service to at least one terminal connected to the server via a communication network.
- the server 1 provides an interactive multimedia service to one or both of the terminals 2, 3, which are, for example, videophones.
- the terminals 2, 3, which are, for example, videophones.
- a communication is established, via a communication network 4, between the server 1 and the terminals 2, 3.
- server 1 is running on a single machine.
- the invention also applies in the case where the server is run on several machines.
- FIG. 2 a particular embodiment of the method according to the invention is presented. For example, it is assumed that a terminal (for example the one referenced 2 in FIG. 1) wishes to benefit from a multimedia service offered by the server (referenced 1 in FIG. 1).
- the server executes an application aimed at providing an interactive multimedia service to the terminal.
- the server checks whether the application has generated an output. In the case of a positive verification in step 22, the server performs a step 23 of converting this output of the application into at least one first multimedia stream that can be presented directly, without prior processing, by the terminal. Then, in a step 24, the server transmits this or these first streams to the terminal, via a communication established between the server and the terminal. Finally, the server returns to step 22. In case of negative verification in step 22, the server server returns directly to step 22.
- the server checks in a step 25 if the terminal has transmitted to him, directly and without prior treatment, an entry of the application.
- the server receives the input transmitted by the terminal in a step 26.
- the server converts this input (for example a DTMF signal) into one or more commands to control the application.
- the server returns to step 22.
- the server returns directly to step 25.
- a session gives rise to the execution of an application on an interactive service server (this can be a dedicated server or an advanced terminal at an individual); the outputs of the application (video display, audio output, ...) are sent in the form of media streams to one or more connected terminals according to their capabilities; and the entries entered on the terminal or terminals can be sent to the application and allow to control it from the terminal that generated the entries.
- the inputs can be of various types: DTMF ("Dual Tone MultiFrequency", or “multifrequency two-tone"), voice, video with pattern recognition or gestures in a video stream (the recognition can then be done on the machine receiving the flow), or others.
- DTMF Dual Tone MultiFrequency
- voice voice
- video with pattern recognition or gestures in a video stream the recognition can then be done on the machine receiving the flow
- the invention makes it possible to produce interactive applications that can be used and controlled from any terminal with limited capabilities (compatible with the type of application that is to be made accessible).
- This application may be a game, a configuration interface of its services, or any other type of application with potential user interactions.
- Several terminals can be in communication with the application (multiplayer games, document sharing, presentations, ).
- the invention offers the possibility of accessing an application without controlling it from a terminal. In this case, no entry of the application is entered on the terminal, and the method is limited to steps 21 to 24 of Figure 2.
- the client terminal here plays the role of the service server and the client software is the application executed by this server.
- the client software (or a module installed on its machine) can capture the output of the client software and convert it to a media stream accepted by the terminal with limited capabilities of the "hot line".
- the client software or a module installed on its machine
- the service delivered to a terminal 2 by a server 1 according to the invention can be represented by the diagram of FIG.
- the interactive services server can be seen as a terminal (as in the case of a service portal which is called directly, simply by dialing a number (or an alias) as for the establishment of a conventional telephone call).
- the server can be inserted transparently in cutoff during the establishment of a call to a correspondent (active services during communication).
- the application server switches off the communication, it does not actually switch off unless necessary (for example, if the caller or called party is not subscribed to the service specific, the communication normally takes place) or at the request of one of the users.
- the exchanges between the terminal 2 and the server 1 we can distinguish those
- the inputs (commands) 33 transmitted to the server by the terminal can be either messages in the signaling of the communication (case of DTMFs in ESFFO messages in SIP), or media streams which are interpreted by the server as commands (like for example speech recognition).
- the service may, for example, be rendered by means of two pieces of equipment: a signaling server (41) (traditionally called AS for "Application Server” in the SIP world) and a processing server (or PS for " Processing Server ”) 42.
- a signaling server (41) traditionally called AS for "Application Server” in the SIP world
- a processing server or PS for " Processing Server ”
- the server 1 discussed above itself comprises the signaling server 41 and the processing server 42.
- the processing database 43, data or content servers, .
- a communication (here the example is given with only one participant, the terminal 2) takes place in two stages: the caller 2 dials the service number, the signaling server 41 determines the processing server 42 available corresponding to the requested service and makes the media streams 44 of the caller 2 sent to the processing server 42 and that the media streams 45 of the processing server 42 are sent to the caller 2; the caller 2 can interact with the processing server 42 by means of the input device of his terminal, the commands being sent in the form of a media stream or in the signaling (and in this case relayed by the SIP-serviet 46) and interpreted by the processing server 42.
- the role of the signaling server 41 is now presented, in connection with the examples of exchange kinematics of FIGS. 5, 6 and 7.
- the call establishment proceeds normally, except that the signaling server
- SIP-serviet 46 written in Java. It requires passing some SIP protocol request messages ("Session
- the servlet 46 consults the payload of the message, which is a description in SDP format ("Session Description Protocol") of the different flows that will be involved in the communication (that is, the streams that the caller 2 wishes to receive in the communication session).
- the servlet 46 indicates to the processing server 42 the addresses 52 associated with each stream of the caller intended to interact with the processing server 42.
- the processing server 42 supplies the servlet 46 with the addresses 53 corresponding to the streams of the server. processing server 42 associated with the caller. This is done by means of a programming interface (or API for "Application Programming
- the servlet 46 simulates a called terminal by accepting the call by returning to the caller 2 a SIP message "200OK" 54 containing the addresses and flow types associated with the processing server 42. The servlet 46 also intercepts the acknowledgment SIP message.
- DTMF in-band or out-of-band (DTMF) DTMF, etc. It is possible that the servlet 46 is responsible for receiving these inputs (triggers), in which case it transmits them to the processing server 42.
- the triggers are conveyed in the form of DTMF out-of-band.
- the processing server 42 transmits media streams 61 transmitted to the caller 2.
- the caller 2 controls the application by pressing, for example, a key on the keyboard of his terminal. In the example, this produces a message "ESfFO (DTMF)" 62 of the SIP protocol which carries the DTMF digit associated with this key.
- the signaling server 41 intercepts this "INFO (DTMF)" message 62, and transmits a trigger request 63 to the processing server 42. The latter acts on this trigger as a function of the current application.
- the trigger causes an update of the media stream 64 sent to the caller 2.
- the kinematics illustrated in Figure 7 relates to the termination of the call (call) by the caller. It is assumed that the processing server 42 and the caller 2 are sending flows 71.
- the signaling server 41 intercepts the end-of-call SIP message "BYE" 72 sent by the caller and transmits a stop request 73 from the service to the processing server 42. The latter responds with an acknowledgment message 74 and the signaling server 41 sends a SIP message "200OK" 75 to the caller in order to terminate the call in turn.
- the caller and the processing server 42 stop all transmissions of media streams between them (which is symbolized by the dots referenced 76).
- the role of the processing server 42 is now presented. It acts as an end of communication terminal with regard to the media streams. It exposes the aforementioned API 48, allowing the servlet 46 included in the signaling server 41 to initialize the input / output addresses, and possibly to drive the application of the processing server 42 if the caller inputs are received by the servlet.
- RTCP Real-Time Transport Protocol
- the processing server 42 may or may not have outputs on the machine running the application.
- the service delivered by the processing server 42 may be more or less complex and may be a menu to other services that will then be executed by the processing server 42 or simply relayed by it or provided directly by a new server after transfer .
- the processing server 42 may be in several forms, for example
- This module also functions as a robot application that makes it possible, for example, to take control of the cursor (displacements and generation of clicks) as a function of the incoming information (inputs of the application) coming from the control terminals; a module integrated in the application, which retrieves a display buffer (for example, but this is valid for all other types of output of the application) to convert it to RTP media stream.
- This module then retrieves the inputs from the terminals and can act directly on the elements of the application.
- the interactive services server is itself a communication termination element for both the flows and the signaling. It can also be an element in the communication network, or a correspondent in the same way as the requesting terminal of the service (case of a "peer-to-peer" network for example).
- FIG. 8 shows the structure of a machine running a server according to the invention, the server itself executing an application offering at least one interactive multimedia service.
- the machine includes a memory 81, and a processing unit
- the processing unit 80 receives outputs from the application 83, which the microprocessor processes, according to the instructions of the program 82, to convert them into one or more multimedia streams 84 transmitted to one or more terminals so that they present them directly. , without prior treatment.
- the processing unit 80 also receives inputs from the application 85, transmitted by one or more terminals, which the microprocessor processes, according to the instructions of the program 82, to convert them into one or more commands 86 making it possible to control the application.
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Telephonic Communication Services (AREA)
Abstract
L'invention concerne un procédé de gestion de l'exécution par un serveur (1) d'une application offrant au moins un service multimédia interactif à au moins un terminal (2) relié au serveur (1) via un réseau de communication (4). Selon l'invention, le procédé comprend les étapes suivantes effectuées par le serveur (1): conversion (23) des sorties de l'application sous la forme d'au moins un premier flux multimédia pouvant être présenté par ledit au moins un terminal (2); et transmission (24) dudit au moins un premier flux multimédia audit au moins un terminal (2), via une communication établie entre le serveur (1) et ledit au moins un terminal (2). Dans un node de réalisation particulier, le procédé comprend en outre les étapes suivantes effectuées par le serveur (1): réception (26) des entrées de l'application que ledit au moins un terminal (2) transmet au serveur (1), via ladite communication; et conversion (27) des entrées de l'application en commandes permettant de piloter l'application.
Description
Procédé de gestion de l'exécution par un serveur d'une application offrant au moins un service multimédia interactif à au moins un terminal, produit programme d'ordinateur et serveur correspondants.
1. Domaine de l'invention Le domaine de l'invention est celui des communications audio et/ou vidéo, qui ont lieu sur un réseau de communication de type réseau téléphonique commuté, réseau numérique à intégration de services, réseau à commutation de paquets, ou réseau de téléphonie sans fil, ou tout réseau qui permet la communication audio et/ou vidéo.
Plus précisément, l'invention concerne une technique permettant à des terminaux capables de recevoir des flux multimédias (contenant des informations de type audio et/ou vidéo) d'accéder à des services multimédia interactifs offerts par des applications
(aussi appelées applicatifs) s'exécutant sur des serveurs distants. Chaque serveur peut être une machine unique ou être distribué sur plusieurs machines.
L'invention s'applique notamment, mais non exclusivement, au cas d'un serveur fournissant au moins un service multimédia interactif à des visiophones.
2. Art antérieur
Aujourd'hui, seuls les terminaux possédant une grande capacité, comme certains téléphones mobiles, peuvent exécuter eux-mêmes un applicatif (par exemple, un jeux java téléchargé). Pour les terminaux ne possédant pas une si grande capacité, l'applicatif peut être exécuté sur un serveur (généralement dédié), sous réserve que les terminaux possèdent un minimum de capacités pour y installer un client léger (logiciel ou matériel) permettant d'interagir avec le serveur.
Un navigateur WEB est un exemple de client léger intégré par un terminal. Il permet au terminal notamment de se connecter à un serveur http, en utilisant le protocole http (protocole de transfert hypertexte), pour transférer et afficher des pages Web au format HTML (« HyperText Markup Language », ou langage de balisage d'hypertexte). Il est important de noter que, en ce qui concerne les sorties de l'application exécutée par le serveur, le serveur ne transmet pas au terminal un flux multimédia (pages Web) que le terminal peut présenter directement, sans traitement préalable. Le serveur transmet des informations (balises HTML) que le navigateur Web du terminal doit traiter afin de
générer un flux multimédia. De même, en ce qui concerne les entrées de l'application exécutée par le serveur, le terminal ne transmet pas directement au serveur les saisies de l'utilisateur (effectuées par exemple via un clavier ou une manette de commande (joystick)), sans traitement préalable. Le navigateur Web du terminal doit traiter ces saisies pour les convertir en requêtes http qui sont ensuite envoyées au serveur.
Outre le navigateur WEB, il existe pour les ordinateurs personnels (PC) des techniques permettant d'utiliser à distance une machine. On connaît par exemple les logiciels « GotoMyPC » (marque déposée) de Citrix Systems ou encore « PcAnyWhere » (marque déposée) de Symantec, qui sont des logiciels de prise de contrôle à distance d'un PC. Avec ces techniques, les applications s'exécutent sur une machine distante, le terminal (PC) n'étant utilisé que comme périphérique d'entrée et d'affichage. Mais là encore, le terminal (PC) doit avoir un minimum de capacité pour l'exécution d'un client léger.
Or, il existe de nombreux terminaux à capacité limitée (les visiophones actuels par exemple) qui ne possèdent pas ce minimum de capacité pour l'exécution d'un client léger, et qui ne peuvent donc pas accéder à des services multimédia interactifs offerts par des applicatifs s'exécutant sur des serveurs distants.
En d'autres termes, de nombreux services interactifs actuels sont inaccessibles depuis des terminaux basiques car ils nécessitent que les terminaux y accédant soient équipés d'un client (logiciel ou matériel) particulier.
En outre, les périphériques d'entrées sur ces terminaux à capacité limitée sont souvent très limités (par exemple DTMF uniquement sur le visiophone) et leur sortie vidéo ne peut supporter que des flux vidéos dans des formats bien spécifiques. 3. Objectifs de l'invention L'invention a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique.
Plus précisément, l'un des objectifs de la présente invention est de fournir une technique de gestion de l'exécution par un serveur d'une application offrant au moins un service multimédia interactif à au moins un terminal, cette technique pouvant être mise en œuvre avec des terminaux à capacité limitée, sans qu'il soit nécessaire que ces terminaux exécutent un client léger.
L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique permettant au terminal d'accéder à une application (applicatif) en la pilotant.
L'invention a également pour objectif, dans au moins une variante de réalisation, de fournir une telle technique permettant au terminal d'accéder à une application
(applicatif) sans la piloter.
Un autre objectif de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique qui soit simple à mettre en œuvre et peu coûteuse.
Un objectif complémentaire de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique qui ne nécessite aucune modification des terminaux à faible capacité existants, comme le visiophone par exemple. 4. Exposé de l'invention
Ces différents objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints selon l'invention à l'aide d'un procédé de gestion de l'exécution par un serveur d'une application offrant au moins un service multimédia interactif à au moins un terminal relié au serveur via un réseau de communication. Selon l'invention, le procédé comprend les étapes suivantes effectuées par le serveur : conversion des sorties de l'application sous la forme d'au moins un premier flux multimédia pouvant être présenté par ledit au moins un terminal ; et - transmission dudit au moins un premier flux multimédia audit au moins un terminal, via une communication établie entre le serveur et ledit au moins un terminal.
Le principe général de l'invention consiste donc à effectuer, dans le serveur, une conversion sur les sorties de l'application, de façon qu'après conversion elles soient compatibles avec les terminaux, sans que ces derniers exécutent un client léger particulier (navigateur Web ou autre). En d'autres termes, c'est le serveur qui adapte le service, et plus précisément les sorties de l'application, aux terminaux les plus basiques, auxquels on demande seulement d'être capables de recevoir des flux multimédias (par exemple un flux audio vidéo, pour un visiophone).
Ainsi, l'invention permet à un ou plusieurs terminaux basiques d'accéder individuellement ou à plusieurs à une multitude de services s'exécutant sur un serveur distant (qui lui-même est exécuté par une unique machine ou plusieurs machines).
Il suffit que ces terminaux basiques soient capables de présenter la sortie de l'application correspondant au service, voire (dans le mode de réalisation avantageux détaillé ci-après) de piloter cette application.
Dans un mode de réalisation avantageux de l'invention, le procédé comprend en outre les étapes suivantes effectuées par le serveur : réception des entrées de l'application que ledit au moins un terminal transmet au serveur, via ladite communication ; et conversion des entrées de l'application en commandes permettant de piloter l'application.
Dans ce cas, le ou les terminaux peuvent piloter l'application, malgré qu'ils n'exécutent aucun client léger particulier (navigateur Web ou autre). A nouveau, c'est le serveur qui adapte le service aux terminaux les plus basiques, auxquels on demande seulement d'être capables d'envoyer les entrées de l'application (par exemple des signaux DTMF générés par appui de l'utilisateur sur un clavier, pour un visiophone).
De façon avantageuse, le serveur reçoit les entrées de l'application, provenant dudit au moins un terminal, dans au moins un second flux multimédia et/ou dans au moins un canal de signalisation associé à ladite communication.
Avantageusement, l'étape de conversion des sorties de l'application sous la forme d'au moins un premier flux multimédia est basée sur une technique appartenant au groupe comprenant (liste non exhaustive) : capture à des instants déterminés d'une image d'écran résultant de l'exécution de l'application, puis conversion de la suite d'images capturées ainsi réalisée en au moins un flux vidéo, en temps réel ; réalisation par l'application d'un affichage direct en mémoire, puis conversion de l'affichage direct en mémoire en au moins un flux vidéo.
Cette liste, spécifique à la vidéo, n'est pas exhaustive. Dans un mode de réalisation particulier de l'invention, le serveur comprend un serveur de signalisation et un serveur de traitement, et le serveur de traitement effectue
l'étape de conversion des sorties de l'application et l'étape de transmission dudit au moins un premier flux multimédia.
Comme expliqué en détail par la suite, cette décomposition en serveur de signalisation et serveur de traitement est valable dans le cas d'une réalisation avec SIP- servlet.
L'invention peut s'appliquer aussi bien dans le cas où le serveur est exécuté sur une ou plusieurs machines dédiées à la fourniture dudit au moins un service multimédia interactif que dans le cas où le serveur est exécuté sur une ou plusieurs machines non dédiées à la fourniture dudit au moins un service multimédia interactif. Dans une application particulière, ledit au moins un terminal est un terminal basique n'intégrant aucune capacité de traitement particulière.
Le terminal est par exemple un visiophone. Il est clair que, plus généralement, l'invention s'applique à tout type de terminal capable de recevoir et présenter un flux multimédia provenant du serveur et, si le terminal doit piloter l'application, d'envoyer de façon brute (c'est-à-dire sans traitement) les entrées de l'application au serveur.
Dans un premier mode de réalisation particulier de l'invention, le serveur est vu par ledit au moins un terminal comme un point de terminaison d'appel.
Dans un second mode de réalisation particulier de l'invention, le serveur s'intercale de façon transparente, en coupure d'une communication entre ledit au moins un terminal et un autre terminal.
L'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, ce produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé précité, lorsque ledit programme est exécuté sur un ordinateur.
L'invention concerne aussi un serveur du type permettant l'exécution d'une application offrant au moins un service multimédia interactif à au moins un terminal relié au serveur via un réseau de communication. Selon l'invention, le serveur comprend:
des moyens de conversion des sorties de l'application sous la forme d'au moins un premier flux multimédia pouvant être présenté par ledit au moins un terminal
; et des moyens de transmission dudit au moins un premier flux multimédia audit au moins un terminal, via une communication établie entre le serveur et ledit au moins un terminal. 5. Liste des figures
D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : la figure 1 présente un exemple de système dans lequel peut être mis en oeuvre le procédé selon l'invention, comprenant un serveur selon l'invention ; la figure 2 présente un organigramme d'un mode de réalisation particulier du procédé selon l'invention ; - la figure 3 est une représentation simplifiée du service rendu à un terminal par un serveur selon l'invention ; la figure 4 présente un schéma bloc fonctionnel d'un mode de réalisation particulier du serveur selon l'invention, comprenant un serveur de signalisation et un serveur de traitement ; - les figures 5, 6 et 7 présentent chacune un exemple distinct de cinématique d'échange entre un terminal et les serveurs de signalisation et de traitement apparaissant sur la figure 4 ; et la figure 8 présente la structure d'une machine exécutant un serveur selon l'invention. 6. Description détaillée
L'invention concerne donc un procédé de gestion de l'exécution par un serveur d'une application offrant au moins un service multimédia interactif à au moins un terminal relié au serveur via un réseau de communication.
Ainsi, dans l'exemple illustré sur la figure 1, le serveur 1 fournit un service multimédia interactif à l'un des terminaux 2, 3 (ou aux deux), qui sont par exemple des
visiophones. Pour cela, une communication est établie, via un réseau de communication 4, entre le serveur 1 et les terminaux 2, 3.
Dans cet exemple, le serveur 1 est exécuté sur une machine unique. L'invention s'applique également dans le cas où le serveur est exécuté sur plusieurs machines. On présente maintenant, en relation avec la figure 2, un mode de réalisation particulier du procédé selon l'invention. On suppose par exemple qu'un terminal (par exemple celui référencé 2 sur la figure 1) souhaite bénéficier d'un service multimédia offert par le serveur (référencé 1 sur la figure 1).
Dans une étape 21, le serveur exécute une application visant à offrir un service multimédia interactif au terminal.
Dans une étape 22, le serveur vérifie si l'application a généré une sortie. En cas de vérification positive à l'étape 22, le serveur effectue une étape 23 de conversion de cette sortie de l'application en au moins un premier flux multimédia pouvant être présenté directement, sans traitement préalable, par le terminal. Puis, dans une étape 24, le serveur transmet ce ou ces premiers flux au terminal, via une communication établie entre le serveur et le terminal. Enfin, le serveur revient à l'étape 22. En cas de vérification négative à l'étape 22, le serveur le serveur revient directement à l'étape 22.
En parallèle, le serveur vérifie dans une étape 25 si le terminal lui a transmis, directement et sans traitement préalable, une entrée de l'application. En cas de vérification positive à l'étape 25, le serveur reçoit l'entrée transmise par le terminal, dans une étape 26. Puis, dans une étape 27, le serveur convertit cette entrée (par exemple un signal DTMF) en une ou plusieurs commandes permettant de piloter l'application. Enfin, le serveur revient à l'étape 22. En cas de vérification négative à l'étape 25, le serveur revient directement à l'étape 25. Ainsi, dans ce mode de réalisation particulier, le procédé de l'invention permet de mettre en place un mécanisme gérant l'exécution d'une application sur un serveur distant mais dont les sorties et entrées sont situées sur (au moins) un terminal même basique. Les critères de ce mécanisme sont : une session donne lieu à l'exécution d'une application sur un serveur de services interactifs (cela peut être un serveur dédié ou bien un terminal évolué chez un particulier) ;
les sorties de l'application (affichage vidéo, sortie audio, ...) sont envoyées sous forme de flux médias à un ou plusieurs terminaux connectés suivant leurs capacités ; et les entrées saisies sur le ou les terminaux peuvent être envoyées à l'application et permettent de le piloter depuis le terminal ayant généré les entrées.
Les entrées peuvent être de divers types : DTMF (« Dual Tone MultiFrequency », ou « multifréquence à deux tonalités »), vocal, vidéo avec reconnaissance de formes ou gestes dans un flux vidéo (la reconnaissance pouvant alors se faire sur la machine recevant le flux), ou autres. Ainsi, l'invention permet de réaliser des applicatifs interactifs utilisables et pilotables depuis n'importe quel terminal à capacités limitées (compatibles avec le type d'applicatif que l'on souhaite rendre accessible). Cet applicatif peut être un jeu, une interface de configuration de ses services, ou tout autre type d'applicatifs avec interactions potentielles de l'utilisateur. Plusieurs terminaux peuvent être en communication avec l'applicatif (jeux multi-joueurs, partage de documents, présentations, ...).
Il est à noter que dans une variante de réalisation, l'invention offre la possibilité d'accéder à un applicatif sans le piloter depuis un terminal. Dans ce cas, aucune entrée de l'application n'est saisie sur le terminal, et le procédé est limité aux étapes 21 à 24 de la figure 2.
Cette variante s'applique par exemple dans le cadre d'un service d'assistance téléphonique (« hot line ») d'un logiciel, le professionnel pouvant voir et guider à distance le client sur son logiciel. Le terminal du client joue ici le rôle du serveur de services et le logiciel du client est l'application exécutée par ce serveur. Dans ce cas, le logiciel du client (ou un module installé sur sa machine) permet de capturer la sortie du logiciel du client et de la convertir en flux média accepté par le terminal à capacités limitées de la « hot line ». On peut alors imaginer que ce soit le terminal à capacités limitées de la « hot line » qui initie l'appel ou bien que ce soit le terminal du client.
Dans tous les cas (voix sur IP (VoIP), RTC, Mobile, ...), le service rendu à un terminal 2 par un serveur 1 selon l'invention peut être représenté par le schéma de la figure 3.
Le serveur de services interactifs peut être vu comme un terminal (cas d'un portail de service que l'on appelle directement, simplement en composant un numéro (ou un alias) comme pour l'établissement d'une communication téléphonique classique).
Selon une alternative, le serveur peut s'intercaler de façon transparente en coupure lors de l'établissement d'un appel vers un correspondant (services actifs en cours de communication). Dans ce cas d'un fonctionnement où le serveur d'applicatifs se met en coupure de la communication, il ne se met effectivement en coupure que si nécessaire (par exemple, si l'appelant ou l'appelé n'est pas abonné au service spécifique, la communication se déroule normalement) ou à la demande d'un des utilisateurs. Parmi les échanges entre le terminal 2 et le serveur 1, on peut distinguer ceux
(référencés 31) relatifs à l'établissement de l'appel, ceux (référencés 32) relatifs aux flux multimédias et ceux (référencés 33) relatifs aux entrées (commandes) transmises au serveur par le terminal afin de déclencher une action (symbolisée par la flèche référencée 34) dans l'application. Les entrées (commandes) 33 transmises au serveur par le terminal peuvent être soit des messages dans la signalisation de la communication (cas des DTMF dans des messages ESfFO en SIP), soit des flux médias qui sont interprétés par le serveur comme des commandes (comme par exemple de la reconnaissance vocale).
On présente maintenant, en relation avec la figure 4, un mode de réalisation particulier du serveur selon l'invention 1, dans une mise en œuvre particulière, en voix sur IP avec le protocole de signalisation SIP.
Dans ce cas, le service peut, par exemple, être rendu au moyen de deux équipements : un serveur de signalisation (41) (traditionnellement appelé AS pour « Application Server » dans le monde SIP) et un serveur de traitement (ou PS pour « Processing Server ») 42. En d'autres termes, le serveur 1 discuté ci-dessus comprend lui-même le serveur de signalisation 41 et le serveur de traitement 42. A cela s'ajoutent tous les éventuels éléments nécessaires à rendre le traitement (base de données 43, serveurs de données ou de contenus, ...).
Une communication (ici l'exemple est donné avec un seul participant, le terminal 2) se déroule en deux temps :
l'appelant 2 compose le numéro du service, le serveur de signalisation 41 détermine le serveur de traitements 42 disponible correspondant au service demandé et fait en sorte que les flux médias 44 de l'appelant 2 soient envoyés vers le serveur de traitements 42 et que les flux médias 45 du serveur de traitements 42 soient envoyés vers l'appelant 2 ; l'appelant 2 peut interagir avec le serveur de traitements 42 au moyen du périphérique d'entrée de son terminal, les commandes étant envoyées sous forme de flux média ou dans la signalisation (et dans ce cas relayées par la SIP-serviet 46) et interprétées par le serveur de traitements 42. On présente maintenant, en relation avec les exemples de cinématique d'échange des figures 5, 6 et 7, le rôle du serveur de signalisation 41.
Dans la cinématique d'un établissement d'appel (illustrée sur la figure 5), l'établissement d'appel procède normalement, à ceci près que le serveur de signalisation
41 intercepte la demande d'établissement de communication, afin de forcer les échanges de flux média entre l'appelant 2 et le serveur de traitement 42. Dans un mode particulier de réalisation, cette interception est effectuée par une SIP-serviet 46, écrite en java. Elle requiert de voir passer certains messages de requêtes du protocole SIP (« Session
Initiation Protocol »). Lorsqu'un message SIP « INVITE » 51 est reçu via un canal de signalisation 47, la servlet 46 consulte la charge utile du message, qui est une description au format SDP (« Session Description Protocol ») des différents flux qui vont être impliqués dans la communication (c'est-à-dire les flux que l'appelant 2 souhaite recevoir dans la session de communication). La servlet 46 indique au serveur de traitement 42 les adresses 52 associées à chaque flux de l'appelant destiné à interagir avec le serveur de traitement 42. En retour, le serveur de traitement 42 fournit à la servlet 46 les adresses 53 correspondant aux flux du serveur de traitement 42 associés à l'appelant. Ceci se fait au moyen d'une interface de programmation (ou API pour « Application Programming
Interface ») 48 qui peut être propriétaire, ou standard (par exemple SIP). La servlet 46 simule un terminal appelé en acceptant la communication en retournant à l'appelant 2 un message SIP « 200OK » 54 contenant les adresses et types de flux associés au serveur de traitement 42. La servlet 46 intercepte également le message SIP d'acquittement
« ACK » 55 de l'appelant 2 suite au message SIP « 200OK » 54, afin d'envoyer au
serveur de traitement 42 une requête 56 de lancement de l'applicatif. Après que l'appel a été établi, le serveur de traitement 42 et l'appelant 2 s'envoient des flux 57.
Pour le pilotage de l'applicatif par l'appelant, plusieurs techniques connues peuvent être envisagées pour véhiculer les saisies de l'appelant dans la session de communication : vocal, flux vidéo puis reconnaissance de gestes, DTMF intrabande
(« in-band DTMF ») ou DTMF hors-bande (« out-of-band DTMF »), etc. Il est possible que la servlet 46 soit chargée de la réception de ces saisies (déclenchements), auquel cas elle les transmet au serveur de traitement 42.
Dans la cinématique illustrée sur la figure 6, relative au pilotage de l'applicatif par l'appelant, on suppose à titre d'exemple que les déclenchements (saisies) sont véhiculées sous la forme de DTMF hors-bande. On suppose également que le serveur de traitement 42 émet des flux médias 61 émis vers l'appelant 2. L'appelant 2 pilote l'applicatif en pressant, par exemple, une touche du clavier de son terminal. Dans l'exemple, ceci produit un message « ESfFO (DTMF) » 62 du protocole SIP qui véhicule le digit DTMF associé à cette touche. Le serveur de signalisation 41 intercepte ce message « INFO (DTMF) » 62, et transmet une requête de déclenchement 63 au serveur de traitement 42. Celui-ci agit sur ce déclenchement en fonction de l'applicatif en cours. Dans cet exemple, le déclenchement entraîne une mise à jour des flux médias 64 émis vers l'appelant 2. Certains applicatifs peuvent mettre à jour continuellement ces flux médias sans intervention de l'appelant, selon la nature de l'applicatif.
La cinématique illustrée sur la figure 7 est relative à la terminaison de la communication (appel) par l'appelant. On suppose que le serveur de traitement 42 et l'appelant 2 s'envoient des flux 71. Le serveur de signalisation 41 intercepte le message SIP de fin de communication « BYE » 72 envoyé par l'appelant et transmet une requête 73 d'arrêt du service au serveur de traitement 42. Celui-ci répond par un message d'acquittement 74 et le serveur de signalisation 41 émet un message SIP « 200OK » 75 vers l'appelant afin de terminer à son tour la communication. L'appelant et le serveur de traitement 42 stoppent toutes émissions de flux médias entre eux (ce qui est symbolisé par les pointillés référencés 76). On présente maintenant le rôle du serveur de traitement 42.
II agit comme un terminal de fin de communication en ce qui concerne les flux médias. Il expose l'API 48 précitée, permettant à la servlet 46 comprise dans le serveur de signalisation 41 d'initialiser les adresses d'entrée/sortie, et éventuellement de piloter l'applicatif du serveur de traitement 42 si les saisies de l'appelant sont reçues par la servlet.
Il est capable de convertir les sorties de l'applicatif en de nombreux formats de données véhiculés par les flux médias, au moyen de nombreux codées audio et/ou vidéos. Il implémente les protocoles de transport des flux, tels que RTP (pour « Real- Time Transport Protocol » ou RTCP (pour « Real- Time Transport Control Protocol »). Un mécanisme de déclaration auprès de la servlet 46 peut être géré par le serveur de traitement 42 afin de se déclarer disponible pour prendre la communication.
Le serveur de traitement 42 peut avoir ou non des sorties sur la machine d'exécution de l'applicatif.
Le service délivré par le serveur de traitement 42 peut être plus ou moins complexe et peut être un menu vers d'autres services qui seront ensuite exécutés par le serveur de traitement 42 ou simplement relayés par lui ou encore fournis directement par un nouveau serveur après transfert.
Le serveur de traitement 42 peut se présenter sous plusieurs formes, par exemple
- un module externe à l'application, qui permet de capturer une partie de l'écran
(sortie de l'application) et de la convertir en flux médias RTP vers les terminaux. Ce module fonctionne également comme une application robot permettant de prendre par exemple le contrôle du curseur (déplacements et génération de clics) en fonction des informations entrantes (entrées de l'application) en provenance des terminaux de pilotage ; un module intégré à l'application, qui permet de récupérer une mémoire tampon (buffer) d'affichage (par exemple, mais cela est valable pour tous les autres types de sorties de l'application) pour le convertir en flux médias RTP. Ce module récupère alors les entrées provenant des terminaux et peut agir directement sur les éléments de l'application.
Dans d'autres modes de réalisations, le serveur de services interactifs est lui- même un élément de terminaison de communication aussi bien pour les flux que pour la signalisation. Il peut aussi être un élément dans le réseau de communication, ou bien un correspondant au même titre que le terminal demandeur du service (cas d'un réseau "peer-to-peer" par exemple).
La figure 8 présente enfin la structure d'une machine exécutant un serveur selon l'invention, le serveur exécutant lui-même un applicatif offrant au moins un service multimédia interactif. La machine comprend une mémoire 81, et une unité de traitement
80 équipée d'un microprocesseur, qui est piloté par un programme d'ordinateur (ou application) 82.
L'unité de traitement 80 reçoit des sorties de l'applicatif 83, que le microprocesseur traite, selon les instructions du programme 82, pour les convertir en un ou plusieurs flux multimédias 84 transmis à un ou plusieurs terminaux afin que ces derniers les présentent directement, sans traitement préalable. L'unité de traitement 80 reçoit par ailleurs des entrées de l'applicatif 85, transmises par un ou plusieurs terminaux, que le microprocesseur traite, selon les instructions du programme 82, pour les convertir en une ou plusieurs commandes 86 permettant de piloter l'applicatif.
Il est clair que de nombreux autres modes de réalisation de l'invention peuvent être envisagés. On peut notamment prévoir que le serveur selon l'invention soit exécuté sur plusieurs machines.
Claims
1. Procédé de gestion de l'exécution par un serveur (1) d'une application offrant au moins un service multimédia interactif à au moins un terminal (2) relié au serveur via un réseau de communication (3), caractérisé en ce qu'il comprend les étapes suivantes effectuées par le serveur : conversion (23) des sorties de l'application sous la forme d'au moins un premier flux multimédia pouvant être présenté par ledit au moins un terminal ; et transmission (24) dudit au moins un premier flux multimédia audit au moins un terminal, via une communication établie entre le serveur et ledit au moins un terminal.
2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre les étapes suivantes effectuées par le serveur : réception (26) des entrées de l'application que ledit au moins un terminal transmet au serveur, via ladite communication ; et - conversion (27) des entrées de l'application en commandes permettant de piloter l'application.
3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que le serveur reçoit les entrées de l'application, provenant dudit au moins un terminal, dans au moins un second flux multimédia et/ou dans au moins un canal de signalisation associé à ladite communication.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'étape de conversion des sorties de l'application sous la forme d'au moins un premier flux multimédia est basée sur une technique appartenant au groupe comprenant : capture à des instants déterminés d'une image d'écran résultant de l'exécution de l'application, puis conversion de la suite d'images capturées ainsi réalisée en au moins un flux vidéo, en temps réel ; réalisation par l'application d'un affichage direct en mémoire, puis conversion de l'affichage direct en mémoire en au moins un flux vidéo.
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que le serveur (1) comprend un serveur de signalisation (41) et un serveur de traitement (42), et en ce que le serveur de traitement effectue l'étape de conversion des sorties de l'application et l'étape de transmission dudit au moins un premier flux multimédia.
6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit au moins un terminal (2) est un terminal basique n'intégrant aucune capacité de traitement particulière.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que le serveur est vu par ledit au moins un terminal comme un point de terminaison d'appel.
8. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que le serveur s'intercale de façon transparente, en coupure d'une communication entre ledit au moins un terminal et un autre terminal.
9. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 8, lorsque ledit programme est exécuté sur un ordinateur.
10. Serveur (1) du type permettant l'exécution d'une application offrant au moins un service multimédia interactif à au moins un terminal (2) relié au serveur via un réseau de communication (3), caractérisé en ce qu'il comprend : des moyens de conversion des sorties de l'application sous la forme d'au moins un premier flux multimédia pouvant être présenté par ledit au moins un terminal
; et des moyens de transmission dudit au moins un premier flux multimédia audit au moins un terminal, via une communication établie entre le serveur et ledit au moins un terminal.
11. Serveur selon la revendication 10, caractérisé en ce qu'il comprend en outre : des moyens de réception des entrées de l'application que ledit au moins un terminal transmet au serveur, via ladite communication ; et des moyens de conversion des entrées de l'application en commandes permettant de piloter l'application.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/917,695 US20090119408A1 (en) | 2005-06-17 | 2006-06-07 | Method for managing execution by a server of an application providing at least one interactive multimedia service to at least one terminal, corresponding computer program product and server |
EP06763567A EP1891790A1 (fr) | 2005-06-17 | 2006-06-07 | Procede de gestion de l'execution par un serveur d'une application offrant au moins un service multimedia interactif a au moins un terminal, produit programme d'ordinateur et serveur correspondants |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0506196 | 2005-06-17 | ||
FR05/06196 | 2005-06-17 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2006134055A1 true WO2006134055A1 (fr) | 2006-12-21 |
Family
ID=35448202
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2006/062982 WO2006134055A1 (fr) | 2005-06-17 | 2006-06-07 | Procede de gestion de l'execution par un serveur d'une application offrant au moins un service multimedia interactif a au moins un terminal, produit programme d'ordinateur et serveur correspondants |
Country Status (3)
Country | Link |
---|---|
US (1) | US20090119408A1 (fr) |
EP (1) | EP1891790A1 (fr) |
WO (1) | WO2006134055A1 (fr) |
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8366552B2 (en) | 2002-12-10 | 2013-02-05 | Ol2, Inc. | System and method for multi-stream video compression |
US8387099B2 (en) * | 2002-12-10 | 2013-02-26 | Ol2, Inc. | System for acceleration of web page delivery |
US8526490B2 (en) | 2002-12-10 | 2013-09-03 | Ol2, Inc. | System and method for video compression using feedback including data related to the successful receipt of video content |
US8606942B2 (en) | 2002-12-10 | 2013-12-10 | Ol2, Inc. | System and method for intelligently allocating client requests to server centers |
US8711923B2 (en) | 2002-12-10 | 2014-04-29 | Ol2, Inc. | System and method for selecting a video encoding format based on feedback data |
US8769594B2 (en) | 2002-12-10 | 2014-07-01 | Ol2, Inc. | Video compression system and method for reducing the effects of packet loss over a communication channel |
US8840475B2 (en) | 2002-12-10 | 2014-09-23 | Ol2, Inc. | Method for user session transitioning among streaming interactive video servers |
US8893207B2 (en) | 2002-12-10 | 2014-11-18 | Ol2, Inc. | System and method for compressing streaming interactive video |
US8949922B2 (en) | 2002-12-10 | 2015-02-03 | Ol2, Inc. | System for collaborative conferencing using streaming interactive video |
US8964830B2 (en) | 2002-12-10 | 2015-02-24 | Ol2, Inc. | System and method for multi-stream video compression using multiple encoding formats |
US9003461B2 (en) | 2002-12-10 | 2015-04-07 | Ol2, Inc. | Streaming interactive video integrated with recorded video segments |
US9032465B2 (en) | 2002-12-10 | 2015-05-12 | Ol2, Inc. | Method for multicasting views of real-time streaming interactive video |
US9061207B2 (en) | 2002-12-10 | 2015-06-23 | Sony Computer Entertainment America Llc | Temporary decoder apparatus and method |
US9077991B2 (en) | 2002-12-10 | 2015-07-07 | Sony Computer Entertainment America Llc | System and method for utilizing forward error correction with video compression |
US9084936B2 (en) | 2002-12-10 | 2015-07-21 | Sony Computer Entertainment America Llc | System and method for protecting certain types of multimedia data transmitted over a communication channel |
US9138644B2 (en) | 2002-12-10 | 2015-09-22 | Sony Computer Entertainment America Llc | System and method for accelerated machine switching |
US9168457B2 (en) | 2010-09-14 | 2015-10-27 | Sony Computer Entertainment America Llc | System and method for retaining system state |
US9192859B2 (en) | 2002-12-10 | 2015-11-24 | Sony Computer Entertainment America Llc | System and method for compressing video based on latency measurements and other feedback |
US9314691B2 (en) | 2002-12-10 | 2016-04-19 | Sony Computer Entertainment America Llc | System and method for compressing video frames or portions thereof based on feedback information from a client device |
US9446305B2 (en) | 2002-12-10 | 2016-09-20 | Sony Interactive Entertainment America Llc | System and method for improving the graphics performance of hosted applications |
US10201760B2 (en) | 2002-12-10 | 2019-02-12 | Sony Interactive Entertainment America Llc | System and method for compressing video based on detected intraframe motion |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7117239B1 (en) | 2000-07-28 | 2006-10-03 | Axeda Corporation | Reporting the state of an apparatus to a remote computer |
US8108543B2 (en) | 2000-09-22 | 2012-01-31 | Axeda Corporation | Retrieving data from a server |
US7185014B1 (en) | 2000-09-22 | 2007-02-27 | Axeda Corporation | Retrieving data from a server |
US7254601B2 (en) | 2001-12-20 | 2007-08-07 | Questra Corporation | Method and apparatus for managing intelligent assets in a distributed environment |
US7178149B2 (en) | 2002-04-17 | 2007-02-13 | Axeda Corporation | XML scripting of soap commands |
US7966418B2 (en) | 2003-02-21 | 2011-06-21 | Axeda Corporation | Establishing a virtual tunnel between two computer programs |
US8370479B2 (en) | 2006-10-03 | 2013-02-05 | Axeda Acquisition Corporation | System and method for dynamically grouping devices based on present device conditions |
US8065397B2 (en) | 2006-12-26 | 2011-11-22 | Axeda Acquisition Corporation | Managing configurations of distributed devices |
JP4789819B2 (ja) * | 2007-01-31 | 2011-10-12 | 株式会社日立製作所 | アプリケーションとデータの管理方法、管理システム、それに用いられるシンクライアント端末、管理サーバ、および、リモート計算機 |
PT3679941T (pt) | 2009-06-18 | 2022-11-10 | Serenity Pharmaceuticals Llc | Administração segura de desmopressina |
CN101931718A (zh) * | 2010-07-23 | 2010-12-29 | 中兴通讯股份有限公司 | 基于可视电话实现互动游戏的方法及终端 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2004091227A1 (fr) * | 2003-04-07 | 2004-10-21 | Sk Telecom Co., Ltd | Procede et systeme pour la creation/transmission de contenu multimedia |
US20040255041A1 (en) * | 2003-06-12 | 2004-12-16 | Shih-Li Wen | System and method for multimedia messages interchange between different communication interfaces |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6324568B1 (en) * | 1999-11-30 | 2001-11-27 | Siebel Systems, Inc. | Method and system for distributing objects over a network |
US6643621B1 (en) * | 2000-09-14 | 2003-11-04 | Cisco Technology, Inc. | Methods and apparatus for referencing and processing audio information |
KR100937418B1 (ko) * | 2003-08-09 | 2010-01-18 | 엘지전자 주식회사 | 부재중 메시지 저장 기능을 갖는 pvr 장치 및 그 방법 |
US7614075B2 (en) * | 2004-08-13 | 2009-11-03 | Microsoft Corporation | Dynamically generating video streams for user interfaces |
-
2006
- 2006-06-07 US US11/917,695 patent/US20090119408A1/en not_active Abandoned
- 2006-06-07 WO PCT/EP2006/062982 patent/WO2006134055A1/fr active Application Filing
- 2006-06-07 EP EP06763567A patent/EP1891790A1/fr not_active Withdrawn
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2004091227A1 (fr) * | 2003-04-07 | 2004-10-21 | Sk Telecom Co., Ltd | Procede et systeme pour la creation/transmission de contenu multimedia |
US20040255041A1 (en) * | 2003-06-12 | 2004-12-16 | Shih-Li Wen | System and method for multimedia messages interchange between different communication interfaces |
Cited By (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9032465B2 (en) | 2002-12-10 | 2015-05-12 | Ol2, Inc. | Method for multicasting views of real-time streaming interactive video |
US9192859B2 (en) | 2002-12-10 | 2015-11-24 | Sony Computer Entertainment America Llc | System and method for compressing video based on latency measurements and other feedback |
US8366552B2 (en) | 2002-12-10 | 2013-02-05 | Ol2, Inc. | System and method for multi-stream video compression |
US8606942B2 (en) | 2002-12-10 | 2013-12-10 | Ol2, Inc. | System and method for intelligently allocating client requests to server centers |
US9061207B2 (en) | 2002-12-10 | 2015-06-23 | Sony Computer Entertainment America Llc | Temporary decoder apparatus and method |
US8711923B2 (en) | 2002-12-10 | 2014-04-29 | Ol2, Inc. | System and method for selecting a video encoding format based on feedback data |
US8769594B2 (en) | 2002-12-10 | 2014-07-01 | Ol2, Inc. | Video compression system and method for reducing the effects of packet loss over a communication channel |
US8840475B2 (en) | 2002-12-10 | 2014-09-23 | Ol2, Inc. | Method for user session transitioning among streaming interactive video servers |
US8881215B2 (en) | 2002-12-10 | 2014-11-04 | Ol2, Inc. | System and method for compressing video based on detected data rate of a communication channel |
US8893207B2 (en) | 2002-12-10 | 2014-11-18 | Ol2, Inc. | System and method for compressing streaming interactive video |
US8949922B2 (en) | 2002-12-10 | 2015-02-03 | Ol2, Inc. | System for collaborative conferencing using streaming interactive video |
US9077991B2 (en) | 2002-12-10 | 2015-07-07 | Sony Computer Entertainment America Llc | System and method for utilizing forward error correction with video compression |
US8964830B2 (en) | 2002-12-10 | 2015-02-24 | Ol2, Inc. | System and method for multi-stream video compression using multiple encoding formats |
US9003461B2 (en) | 2002-12-10 | 2015-04-07 | Ol2, Inc. | Streaming interactive video integrated with recorded video segments |
US8526490B2 (en) | 2002-12-10 | 2013-09-03 | Ol2, Inc. | System and method for video compression using feedback including data related to the successful receipt of video content |
US10201760B2 (en) | 2002-12-10 | 2019-02-12 | Sony Interactive Entertainment America Llc | System and method for compressing video based on detected intraframe motion |
US8953675B2 (en) | 2002-12-10 | 2015-02-10 | Ol2, Inc. | Tile-based system and method for compressing video |
US9084936B2 (en) | 2002-12-10 | 2015-07-21 | Sony Computer Entertainment America Llc | System and method for protecting certain types of multimedia data transmitted over a communication channel |
US9108107B2 (en) | 2002-12-10 | 2015-08-18 | Sony Computer Entertainment America Llc | Hosting and broadcasting virtual events using streaming interactive video |
US9138644B2 (en) | 2002-12-10 | 2015-09-22 | Sony Computer Entertainment America Llc | System and method for accelerated machine switching |
US9155962B2 (en) | 2002-12-10 | 2015-10-13 | Sony Computer Entertainment America Llc | System and method for compressing video by allocating bits to image tiles based on detected intraframe motion or scene complexity |
US10130891B2 (en) | 2002-12-10 | 2018-11-20 | Sony Interactive Entertainment America Llc | Video compression system and method for compensating for bandwidth limitations of a communication channel |
US8387099B2 (en) * | 2002-12-10 | 2013-02-26 | Ol2, Inc. | System for acceleration of web page delivery |
US9272209B2 (en) | 2002-12-10 | 2016-03-01 | Sony Computer Entertainment America Llc | Streaming interactive video client apparatus |
US9314691B2 (en) | 2002-12-10 | 2016-04-19 | Sony Computer Entertainment America Llc | System and method for compressing video frames or portions thereof based on feedback information from a client device |
US9420283B2 (en) | 2002-12-10 | 2016-08-16 | Sony Interactive Entertainment America Llc | System and method for selecting a video encoding format based on feedback data |
US9446305B2 (en) | 2002-12-10 | 2016-09-20 | Sony Interactive Entertainment America Llc | System and method for improving the graphics performance of hosted applications |
RU2507568C2 (ru) * | 2007-12-05 | 2014-02-20 | Ол2, Инк. | Система для ускорения доставки веб-страницы |
US9168457B2 (en) | 2010-09-14 | 2015-10-27 | Sony Computer Entertainment America Llc | System and method for retaining system state |
Also Published As
Publication number | Publication date |
---|---|
US20090119408A1 (en) | 2009-05-07 |
EP1891790A1 (fr) | 2008-02-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1891790A1 (fr) | Procede de gestion de l'execution par un serveur d'une application offrant au moins un service multimedia interactif a au moins un terminal, produit programme d'ordinateur et serveur correspondants | |
US20080152101A1 (en) | Web-based telephony system and method | |
US20090316688A1 (en) | Method for controlling advanced multimedia features and supplemtary services in sip-based phones and a system employing thereof | |
WO2004017636A1 (fr) | Procede de diffusion en temps reel de fichiers multimedias au cours d'une visioconference, sans rupture de communication, et interface homme-machine pour la mise en oeuvre | |
EP3087706B1 (fr) | Procédé et système de communication entre navigateurs web, utilisant un environnement de communication unifiée | |
EP1890457A1 (fr) | Accès à services interactifs à travers de l'Internet | |
WO2009147348A2 (fr) | Procédé et système d'enregistrement automatique d'une session de communication | |
EP2888861B1 (fr) | Accès a distance a des contenus a partir d'un client léger | |
WO2016083751A1 (fr) | Procede de communication entre un terminal equipe d'un client webrtc et un terminal accessible via un cœur de reseau ims | |
EP2073493B1 (fr) | Procédé de communication multimédia, serveur et produit programme d'ordinateur correspondants | |
EP2232832B1 (fr) | Procede de communication entre un serveur de communication et un terminal | |
WO2007015012A1 (fr) | Service de personnalisation de communications par traitement des flux media audio et/ou video | |
WO2007093616A1 (fr) | Procédé et dispositif de gestion d'au moins un groupe d'utilisateurs, produit programme d'ordinateur correspondant | |
CA2506549C (fr) | Procede de traitement de donnees audio sur un reseau et dispositif de mise en oeuvre de ce procede | |
EP1995930B1 (fr) | Procédé de transcodage de sessions de type SIP | |
EP2282475B1 (fr) | Procédé et dispositif de restitution d'un contenu multimédia | |
EP2064855A1 (fr) | Procede de communication entre plusieurs terminaux | |
WO2013128094A1 (fr) | Procede et dispositif de mise a disposition d'au moins une donnee de communication | |
EP1005206A1 (fr) | Système multimédia de transmission de données | |
WO2009013439A2 (fr) | Procede de controle d'un fournisseur de services a partir d'un terminal mobile | |
EP2134060A1 (fr) | Procédé et système de communication Internet dans lequel un appelé peut choisir suivant quelle modalité il veut être joint | |
EP1181801A1 (fr) | Procede de signalisation entre un systeme de commutation et un equipement telephonique terminal, et systeme et equipement pour la mise en oeuvre | |
TW201322725A (zh) | 網頁電話暨檔案分享系統及方法 | |
WO2014202910A1 (fr) | Procede d'acquisition d'un module de codage/decodage dans un reseau de telecommunications | |
FR2930101A1 (fr) | Procede et dispositif d'acces a un dispositif de memorisation reseau a partir de reseaux prives differents par l'intermediaire d'une messagerie instantanee |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2006763567 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWW | Wipo information: withdrawn in national office |
Country of ref document: DE |
|
WWP | Wipo information: published in national office |
Ref document number: 2006763567 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 11917695 Country of ref document: US |