EP1891790A1 - 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

Info

Publication number
EP1891790A1
EP1891790A1 EP20060763567 EP06763567A EP1891790A1 EP 1891790 A1 EP1891790 A1 EP 1891790A1 EP 20060763567 EP20060763567 EP 20060763567 EP 06763567 A EP06763567 A EP 06763567A EP 1891790 A1 EP1891790 A1 EP 1891790A1
Authority
EP
European Patent Office
Prior art keywords
server
terminal
application
characterized
communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP20060763567
Other languages
German (de)
English (en)
Inventor
Vincent Teze
Claude Daloz
François Toutain
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FR0506196 priority Critical
Application filed by France Telecom SA filed Critical France Telecom SA
Priority to PCT/EP2006/062982 priority patent/WO2006134055A1/fr
Publication of EP1891790A1 publication Critical patent/EP1891790A1/fr
Application status is Withdrawn legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/60Media handling, encoding, streaming or conversion
    • H04L65/601Media manipulation, adaptation or conversion
    • H04L65/602Media manipulation, adaptation or conversion at the source
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00
    • H04L29/02Communication control; Communication processing
    • H04L29/06Communication control; Communication processing characterised by a protocol
    • H04L29/0602Protocols characterised by their application
    • H04L29/06027Protocols for multimedia communication

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


  [0001]     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.

[0002]    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.

[0003]    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

[0004]    (aussi appelées applicatifs) s'exécutant sur des serveurs distants. Chaque serveur peut être une machine unique ou être distribué sur plusieurs machines.

[0005]    L'invention s'applique notamment, mais non exclusivement, au cas d'un serveur fournissant au moins un service multimédia interactif à des visiophones.

[0006]    2. Art antérieur

[0007]    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.

[0008]    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.

[0009]    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.

[0010]    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.

[0011]    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.

[0012]    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.

[0013]    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 oeuvre 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.

[0014]    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

[0015]    (applicatif) sans la piloter.

[0016]    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 oeuvre et peu coûteuse.

[0017]    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

[0018]    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.

[0019]    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).

[0020]    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.

[0021]    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.

[0022]    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).

[0023]    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.

[0024]    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.

[0025]    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.

[0026]    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.

[0027]    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.

[0028]    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.

[0029]    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.

[0030]    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.

[0031]    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.

[0032]    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

[0033]    ; 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

[0034]    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

[0035]    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.

[0036]    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.

[0037]    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).

[0038]    Dans une étape 21, le serveur exécute une application visant à offrir un service multimédia interactif au terminal.

[0039]    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.

[0040]    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.

[0041]    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, ...).

[0042]    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.

[0043]    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.

[0044]    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).

[0045]    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

[0046]    (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).

[0047]    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 oeuvre particulière, en voix sur IP avec le protocole de signalisation SIP.

[0048]    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, ...).

[0049]    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.

[0050]    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

[0051]    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

[0052]    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

[0053]    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

[0054]    " 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.

[0055]    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

[0056]    (" 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.

[0057]    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.

[0058]    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.

[0059]    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.

[0060]    Le serveur de traitement 42 peut avoir ou non des sorties sur la machine d'exécution de l'applicatif.

[0061]    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.

[0062]    Le serveur de traitement 42 peut se présenter sous plusieurs formes, par exemple

[0063]    - un module externe à l'application, qui permet de capturer une partie de l'écran

[0064]    (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).

[0065]    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

[0066]    80 équipée d'un microprocesseur, qui est piloté par un programme d'ordinateur (ou application) 82.

[0067]    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.

[0068]    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

REVENDICATIONS
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.
EP20060763567 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 Withdrawn EP1891790A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0506196 2005-06-17
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

Publications (1)

Publication Number Publication Date
EP1891790A1 true EP1891790A1 (fr) 2008-02-27

Family

ID=35448202

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20060763567 Withdrawn 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

Country Status (3)

Country Link
US (1) US20090119408A1 (fr)
EP (1) EP1891790A1 (fr)
WO (1) WO2006134055A1 (fr)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
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
US7185014B1 (en) 2000-09-22 2007-02-27 Axeda Corporation Retrieving data from a server
US8108543B2 (en) 2000-09-22 2012-01-31 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
US8964830B2 (en) 2002-12-10 2015-02-24 Ol2, Inc. System and method for multi-stream video compression using multiple encoding formats
US20090118019A1 (en) 2002-12-10 2009-05-07 Onlive, Inc. System for streaming databases serving real-time applications used through streaming interactive video
US8549574B2 (en) 2002-12-10 2013-10-01 Ol2, Inc. Method of combining linear content and interactive content compressed together as streaming interactive video
US9446305B2 (en) 2002-12-10 2016-09-20 Sony Interactive Entertainment America Llc System and method for improving the graphics performance of hosted applications
US8366552B2 (en) 2002-12-10 2013-02-05 Ol2, Inc. System and method for multi-stream video compression
US9077991B2 (en) 2002-12-10 2015-07-07 Sony Computer Entertainment America Llc System and method for utilizing forward error correction with video compression
US8893207B2 (en) 2002-12-10 2014-11-18 Ol2, Inc. System and method for compressing streaming interactive video
US8711923B2 (en) 2002-12-10 2014-04-29 Ol2, Inc. System and method for selecting a video encoding format based on feedback data
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
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
US9108107B2 (en) 2002-12-10 2015-08-18 Sony Computer Entertainment America Llc Hosting and broadcasting virtual events using streaming interactive video
US9061207B2 (en) 2002-12-10 2015-06-23 Sony Computer Entertainment America Llc Temporary decoder apparatus and method
US8949922B2 (en) 2002-12-10 2015-02-03 Ol2, Inc. System for collaborative conferencing using streaming interactive video
US8387099B2 (en) * 2002-12-10 2013-02-26 Ol2, Inc. System for acceleration of web page delivery
US8840475B2 (en) 2002-12-10 2014-09-23 Ol2, Inc. Method for user session transitioning among streaming interactive video servers
US10201760B2 (en) 2002-12-10 2019-02-12 Sony Interactive Entertainment America Llc System and method for compressing video based on detected intraframe motion
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
US9138644B2 (en) 2002-12-10 2015-09-22 Sony Computer Entertainment America Llc System and method for accelerated machine switching
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
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 株式会社日立製作所 アプリケーションとデータの管理方法、管理システム、それに用いられるシンクライアント端末、管理サーバ、および、リモート計算機
CN101931718A (zh) * 2010-07-23 2010-12-29 中兴通讯股份有限公司 基于可视电话实现互动游戏的方法及终端
US9168457B2 (en) 2010-09-14 2015-10-27 Sony Computer Entertainment America Llc System and method for retaining system state

Family Cites Families (6)

* Cited by examiner, † Cited by third party
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
KR100605528B1 (ko) * 2003-04-07 2006-07-28 (주)엔토시스 멀티미디어 컨텐츠 제작 전송 방법 및 시스템
US20040255041A1 (en) * 2003-06-12 2004-12-16 Shih-Li Wen System and method for multimedia messages interchange between different communication interfaces
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

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2006134055A1 (fr) 2006-12-21
US20090119408A1 (en) 2009-05-07

Similar Documents

Publication Publication Date Title
JP5379167B2 (ja) Sip−httpアプリケーション相関器
US6816579B2 (en) Method and system for releasing a voice response unit from a protocol session
US10187530B2 (en) Telephony web event system and method
EP1961190B1 (fr) Procede et reseau pour proposer un eventail de services a un abonne
US7647374B2 (en) Method for managing sessions between network parties, methods, network element and terminal for managing calls
US8651960B2 (en) System, method and computer program for enabling an interactive game
US7286521B1 (en) Localized voice over internet protocol communication
US6789120B1 (en) Real-time audio/video communication method for use on the internet and device therefor
US7865607B2 (en) Servlet model for media rich applications
US20070050448A1 (en) Method and system for information collaboration over an IP network via handheld wireless communication devices
EP1419616B1 (fr) Fonctionnement de telephones internet ameliores
RU2499359C2 (ru) Управляемое клиентом динамическое перенаправление вызова
US8990412B2 (en) Session sharing system, session sharing method, session sharing program, and user terminal
US7783701B2 (en) System and method for provisioning universal stateless digital and computing services
US20130100229A1 (en) Web based access to video associated with calls
CN100583882C (zh) 便于第三方呼叫和设备控制的系统和方法
US7149287B1 (en) Universal voice browser framework
US20040244056A1 (en) System and method for providing direct, context-sensitive customer support in an interactive television system
US7885272B2 (en) Remote control of device by telephone or other communication devices
KR100585781B1 (ko) 모바일 인스턴트 메시징 서비스의 파일 전송 방법
US8793338B2 (en) Providing content delivery during a call hold condition
US8126121B2 (en) Multi-modal communications method
US6671364B2 (en) System and method of triggering services for call control
US8037191B2 (en) Low-level remote sharing of local devices in a remote access session across a computer network
US6928150B2 (en) Call charging notification

Legal Events

Date Code Title Description
17P Request for examination filed

Effective date: 20071121

AK Designated contracting states:

Kind code of ref document: A1

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

DAX Request for extension of the european patent (to any country) deleted
17Q First examination report

Effective date: 20080425

RIN1 Inventor (correction)

Inventor name: DALOZ, CLAUDE

Inventor name: TOUTAIN, FRANCOIS

Inventor name: TEZE, VINCENT

DAX Request for extension of the european patent (to any country) deleted
RAP1 Transfer of rights of an ep application

Owner name: ORANGE

18D Deemed to be withdrawn

Effective date: 20150102

R18D Ep-application deemed to be withdrawn: (correction)

Effective date: 20150103

R18D Ep-application deemed to be withdrawn: (correction)

Effective date: 20150106