Brevet FR2840484A1 — publié le 20031205

DESCRIPTION La presente invention concerne les serveurs vocaux comprenant une plateforma vocale offrant un ensemble de fonctions vocales et un module d'application vocale controlant la plate-forma pour gerer la communication entre 0 un terminal utilisateur et la plate-forma. Plus particulierement, I'invention concerne le mode de controle de la plate-forma par le module d'application. De maniere generale, un servour vocal interactif (SVI) peut etre defini comme un serveur vocal a partir duquel un utilisateur peut echanger des messages vocaux, c'est-a-dire dialoguer, avec un systeme informatique. Typiquement, I'utilisateur communique avec le serveur vocal interactif, au moyen d'un terminal approprie (par ex. un telephone), au travers d'un reseau d'acces, par exemple un reseau telephonique commute (RTC) ou un reseau numerique (RNIS). De maniere conventionnelle, un serveur vocal interactif comprend une plate-forma vocale, constituee d'un ensemble de ressources materielles et logicielles, fournissant un ensemble de fonctionnalites vocales, telles que par exemple, la telephonic, la reconnaissance vocale, la synthese vocale, etc. Ces fonctionnalites vent generalement fournies sous la forme d'une bibliotheque de fonctions vocales. Un serveur vocal interactif comprend, d'autre part, un module d'application vocale (logiciel de dialogue) implementant la logique de dialogue, qui controle la plate-forma vocale pour assurer la gestion des echanges de messages vocaux entre un utilisateur connecte au serveur, typiquement au travers d'un reseau telephonique, et la plate-forma vocale. Le module d'application vocale controle la plate-forma par l'envoi a celle-ci de commandes destinees a mettre en ceuvre les fonctions vocales fournies par la plateforma. FTR&D/04218 (Ferrieux et al.) 2 2840484 En particulier, ces commandes declenchent dans la plate-forma des appels aux fonctions vocales. Le module d'application est generalement intimement lie, du point de vue de sa structure et du langage de programmation qu'il utilise, a la plateforma vocale et en particulier aux fonctionnalites qutelle offre. Les fonctionnalites offertes par la plate-forma vocale vent en effet generalement vues par le logiciel de dialogue, comme des primitives, typiquement des fonctions programmees, qui vent appelees lors de ['execution du logiciel de dialogue. Les appels de fonctions offertes par la plate-forma vent generalement effectues par le logiciel de dialogue au travers d'une API (Application Program Intefface). Le choix du langage de programmation utilisable pour concevoir un logiciel de dialogue destine a une plate-forma vocale donnee est done tres limite. Par ailleurs, le couplage etroit qui existe entre le (ou les) langage(s) de programmation utilise(s) pour decrire la logique de dialogue, et les fonctions offertes par la plate-forma vocale, a pour consequence qu'un logiciel de dialogue conc,u pour une plate-forma vocale donnee n'est generalement pas utilisable avec une autre plate- forma vocale, a moins de subir prealablement une adaptation (portage du code) a l'environnement informatique de l'autre plate-forma. II en resulte done un defaut de portabilite et de modularite d'un logiciel d'application vocale considere, vis-a-vis des plate-formes vocales d is poni bles su r le ma rche. Le langage VoiceXML (Voice eXtensible Markup Language) permet dans une certaine mesure de remedier au defaut de portabilite precise, dans le cadre z5 du developpement d'applications vocales sur le Web. Le langage VoiceXML est un langage textuel, de syntaxe XML, permettant de decrire des dialogues voca ux. Cependant, I'util isatio n de ce lang age rend tres d iffici le le ch oix d 'un autre langage de programmation pour concevoir un logiciel de dialogue. D'autre part, la definition des fonctions vocales avec VoiceXML est effectuee a un tres so haut niveau, ce qui limite les possibilites de personnalisation des fonctionnalites vocales, selon ['application consideree. FTR&D/04218 (Ferrieux et al.) 3 2840484 Le but de la presente invention est de resoudre les inconvenients precites relatifs a ['architecture conventionnelle d'un serveur vocal. Conformement a ['invention, ce but est atteint par un serveur vocal, remarquable en ce qu'il comprend des moyens de communication apses a mettre en couvre un protocole de communication de type client-serveur entre le module d'application et la plate-forma, vis-a-vis duquel le module d'application est le client et la plate-forma le serveur, et selon lequel ltenvoi de chaque commande par le module d'application est suivi de l'envoi d'une reponse par la plate-forma, la reception de cette reponse par le module d'application conditionnant l'envoi d'une commande suivante. Grace a ce protocole de communication, il n'y a plus de dependence entre le langage de programmation utilise pour decrire la logique de dialogue dans le module d'application et les fonctions offertes par la plate-forma vocale. En effet, un tel protocole etablit un ensemble de conventions necessaires pour faire cooperer le module d'application et la plate-forma independamment de leur structure interne respective. Selon une caracteristique preferee de ['invention, le module d'application vocale et la plate-forma vocale vent implantes respectivement sur des systemes informatiques distincts relies l'un avec l'autre par l'intermediaire d'un reseau de communication, par exemple un reseau local, voire un reseau de type Internet. Grace a cette caracteristique, on peut s'affranchir des contraintes de systemes d'exploitation (OS) puisque la plate-forma vocale (le serveur) et le module d'application (le client) peuvent etre implantes sur des ordinateurs distincts ayant un systeme d'exploitation different. Selon une autre caracteristique avantageuse, les moyens de reception de messages de requete de la plate-forma vocale vent apses a recevoir des messages en provenance de plusieurs modules d'application distincts, la plate vocale comprenant en outre des moyens de gestion de files d'attente apses a traiter les files d'attente d'execution d'evenements generes par le traitement des commandes re,cues de chaque module d'application. Ainsi, la plate-forma vocale peut gerer simultanement les requetes de plusieurs modules d'applications vocales (clients) distincts qui sont, par FTR&D/04218 (Ferrieux et al.) 4 2840484 exemple, implantes respectivement sur des systemes informatiques distincts, relies via un reseau de communication a la plate-forma vocale. Selon une caracteristique particuliere de ['invention, les moyens de communication du serveur vocal comprennent une vole de transmission apte a permettre la transmission d'informations entre le module d'application et la plate-forma, selon un protocole de transmission predefini. Selon un mode de realisation particulier, la vole de transmission est constituee par une connexion selon le protocole de transmission TCP (Transmission Control Protocol). L'utilisation du protocole TCP comme protocole de transmission permet une integration aisee d'un servour vocal interactif selon ['invention dans le reseau Internet. Selon une caracteristique preferee de ['invention, le protocole de communication est un protocole textuel ligne-a-ligne. Ainsi, contrairement a un protocole de type binaire ou les informations vent transmises sous forme de mots binaires, par exemple des octets, un protocole selon ['invention de type textuel permet de staffranchir de tout probleme d'ordre des mots binaires transmis, dans le cadre de la reconstitution de ['information transmise. Par ailleurs, un protocole textuel dans lequel I'information est transmise ligne par ligne a ['aide de separateurs non ambigus, offre l'avantage de garantir une grande simplicite lors de la mise au point. L'invention concerne aussi des programmes d'ordinateur executables dans une plate-forma vocale ou dans un module d'application vocale, et apses a mettre en oeuvre un protocole de communication selon ['invention. D'autres particularites et avantages de ['invention appara^tront encore dans la description detaillee ci-apres de modes preferes de realisation, decrits a l'appui du dessin annexe, sur lequel la FIGURE 1 est un bloc-diagramme d'un servour vocal interactif selon ['invention. En reference a la FIG. 1, un serveur vocal interactif 1 selon ['invention comprend de maniere classique une plate-forma vocale 10, constituee d'un FTR&DI04218 (Ferrieux et al.) 2840484 ensemble de ressources materielles et logicielles, et fournissant un ensemble de fonctions vocales (13), telles que par exemple la reconnaissance vocale et la synthese vocale. Ces fonctions vent generalement fournies sous la forme d'une bibliotheque de fonctions vocales. Ces fonctions ou ressources vocales vent accessibles par un module de controle 12 de la plate-forma, typiquement via des interfaces de programme 131 de type API (Application Program Intefface). Les types de ressources vocales (13) les plus utiles dans le contexte des serveurs vocaux sont: la telephonic, la synthese vocale ou la restitution de o sons preenregistres, la reconnaissance vocale, la detection de multifrequences a deux tonalites (DTMF - dual tone multilrequency), I'enregistrement de sons. Le serveur vocal 1 comprend classiquement un module d'application vocale 20 qui implemente une logique de dialogue 22 permettant de gerer la communication entre un terminal utilisateur 3 et le serveur vocal 1. A cet effet, 1 le module d'application 20 genere et envoie au module de controle 12 de la plate-forma, d es com m a nd es dont ['execution est destinee a mettre en ceuvre les fonctions vocales 13. Le terminal utilisateur 3 est typiquement un posse de telephone fixe ou mobile connecte au serveur vocal 1 via un reseau d'acces 2 typiquement un zo reseau commute analogique (RTC) ou numerique (RNIS). Le serveur vocal 1 est connecte de maniere classique au reseau d'acces 2 par l'intermediaire d'une interface reseau 11 comprenant une carte d'acces reseau 1 11, un composant pilote 112 qui gere ['emission / reception d'informations sur la carte d'acces 111. s L'interface reseau 11 comprend par ailleurs un module logiciel intermediaire 113 (middleware) qui fournit une interFace 114 de type API permettant au module de controle 12 de la plate-forma de recuperer les flux de signaux provenant de la carte d'acces 111 ou de transmettre des flux de signaux via la carte d'acces au reseau d'acces 2. Conformement a ['invention, le module d'application vocale 20 est independent du module de controle 12 et done de la plate-forma 10. A cet effet, le module d'application 20 et la plate-forma 10 communiquent via une vole de FTR&D/04218 (Ferrieux et al.) 6 2840484 transmission 18 selon un protocole de communication de type clientserveur, vis-a-vis duquel le module d'application vocale 20 est le client et la plate-forma est le serveur. La vole de transmission 18 est apte a assurer la transmission dtinformations entre le module d'application 20 et la plate-forma 10 selon un protocole de transmission predefini. Selon un mode de realisation prefere de realisation de ['invention, ce protocole de transmission est le protocole TCP (Transmission Control Protocol). Le module d'application 20 et la plate-forma vocale 10 communiquent alors au travers d'une connexion TCP. Comme cela sera exposb plus loin dans la description, selon le protocole de communication de ['invention, I'envoi de chaque commande par le module d'application 20 est suivi de l'envoi d'une reponse par la plate-forma 10 (plus precisement par le module de controle 12) dont le contenu est indicatif du resultat de traitement de la commande. La reception de cette reponse par le module d'application est necessaire pour que celui-ci puisse transmettre a nouveau une commande a la plate-forma. Le serveur vocal 1 selon ['invention comprend par consequent des moyens de communication qui vent apses a mettre en couvre le protocole de communication client-serveur entre le module d'application 20 et la plateforma 10. Dans le module d'application vocale 20, les moyens de communication precites comprennent, d'une part, des moyens de traitement du dialogue incorpores dans la logique de dialogue 22, et apses a generer des commandes codees selon le protocole de communication de ['invention. D'autre part, le module d'application 20 comprend une interface de communication 21. L'interface 21 inclut des moyens d'envoi de messages de requete sur la vole de transmission 18 selon le protocole de transmission (TCP), les messages de requete integrant les commandes generees par la logique de dialogue. L'interface de communication 21 comprend en outre des moyens de reception de messages de reponse issus de la plate-forma au travers de la vole FTR&D/04218 (Ferrieux et al.) 7 2840484 de transmission selon le protocole de transmission (TCP) et des moyens d'extraction de reponses codees selon le protocole de communication de ['invention, a partir des messages de reponses re,cus. Correlativement, conformement a ['invention, le module de controle 12 de la plate-forma vocale 10, comporte une interface de communication 122. L'interface de communication 122 comprend des moyens de reception de messages de requete emis par le module d'application 20 au travers de la vole de transmission 18 selon le protocole de transmission choisi. L'interface 122 comprend d'autre part des moyens d'extraction de commandes codees selon le 0 protocole de communication de ['invention, a partir des messages de requete re,cus du module d'application 20. L'interface 122 comporte enfin des moyens d'envoi au travers de la vole de transmission 18, selon le protocole de transmission, de messages de reponses integrant des reponses aux commandes re,cues. Le module de controle 12 comprend par ailleurs une unite de traitement 121 apte a traiter les commandes extraites des messages de requete re,cus, et a generer des reponses codees selon le protocole de communication de ['invention, consecutivement au traitement de commandes re,cues du module d'application 20. o Selon un mode prefere de realisation, le module d'application vocale 20 et la plate-forma vocale 10 vent implantes respectivement sur des systemes informatiques distincts relies l'un avec l'autre par l'intermediaire d'un reseau de communication. Dans ce mode de realisation, la vole de transmission 18 est constituee par une connexion TCP etablie sur un chemin au travers du reseau de communication. Selon un mode prefere de realisation, le reseau de communication est l'lnternet. Dans cette configuration, selon ['invention on peut prevoir d'utiliser la meme plate-forma vocale pour plusieurs modules d'application vocale distincts, repartis sur le reseau de communication, et connectables a la plate-forma 10 au travers de connexions TCP. FTR&DI04218 (Ferrieux et al.) 8 2840484 Dans ce cas, la plate-forma vocale 10 remplit alors veritablement un role de serveur de fonctions vocales executables a distance, vis-a-vis des differents modules d'application 20 consideres. A cet effet, conformement a ['invention, I'unite de traitement 121 de la plate-forma vocale est apte a traiter en parallele des commandes extraites de messages de requete re,cus de plusieurs modules d'application distincts, clients de la plate-forma. Dans la suite de ltexpose, on designee parfois le module d'application vocale par "module client", et la plate-forma vocale par les termes "plate-forma serveur". La plate-forma 10 comprend alors, dans le but de gerer en parallele les contextes differents lies aux modules clients distincts, des moyens de stockage permettant de stocker, dans une file d'attente dediee a chaque module d'application client, des informations concernant des evenements survenus en relation avec le traitement de commandes regues du module d'application client con sidere. Ces moye ns de stockage vent p referentie llement incorpores d an s ['unite de traitement 121. Comme cela sera expose plus teas dans la description en liaison avec la description de la commande d'attente d'evenements 'wat' (voir point d) infra), les evenements consideres vent relatifs a l'utilisation des fonctions vocales (13). Le module de controle 12 de la plate-forma 10 comprend par consequent des moyens de gestion des files d'attente d'evenements liees aux differents modules d'application clients. On va a present detailler un exemple de protocole de communication :5 selon ['invention, entre une plate-forma vocale et un (ou plusieurs) module d'application vocale. Conformement a ['invention, il stagit d'un protocole de type clientserveur, vis-a-vis duquel, le module d'application vocale est le "client", tandis que la plate-forma vocale est le "serveur". Selon le protocole de communication de ['invention, le module d'application (20) communique avec la plate-forma (10) par l'envoi de commandes. Apres traitement de cheque commande re,cue, la plate-forma FTR&D/04218 (Ferrieux et al.) g 2840484 vocale repond au module d'application par l'envoi d'un message de reponse dont le contenu est indicatif du resultat du traitement de la commande. De ce point de vue, on peut dire que le protocole de ['invention definit des commandes "synchrones", dans le sens ou la plate-forma vocale traite sequentiellement les commandes re,cues du module d'application client considere. En effet, la plate-forma serveur traite une commande donnee et fournit une reponse avant de prendre en consideration la commande suivante; par consequent l'ordre de reception, dans le module d'application, de reponses emises par la plate-forma suite au traitement de deux commandes consecutives, ne risque pas d'etre inverse. Le protocole de communication selon ['invention peut done se resumer a un ensemble de commandes synchrones emises par le module client et des acquittements associes, emis par la plate-forma serveur. Selon un mode prefere de realisation de ['invention, le protocole de communication est un protocole de type textuel, ctest-a-dire qu'il consiste en un echange de messages textuels (ASCII). Cela permet ainsi de rendre ce protocole insensible aux problemes d'ordre des mots binaires, qui peuvent se reveler, par exemple lorsque les processeurs du client et du serveur vent de nature differente (par ex., processeur Intel) et processeur Motorola). o Qui plus est. selon un mode prefere de realisation, le protocole de communication est un protocole textuel de type "ligne a ligne". Les separateurs non ambigus, que constituent les caracteres de "retour a la ligne", augmentent la lisibilite des commandes et simplifient la mise au point de ['application. La syntaxe generale des commandes et des reponses est du type de s celle utilisee pour les interpreteurs de commandes UNIX (UNIX shells), c'est-a- dire, une liste d'unites lexicales (tokens) delimitees par un nombre quelconque de blancs et eventuellement entourees de guillemets, la liste se terminant par un "saut de ligne" (newline (\n)). Les messages de reponses envoyes par la plate-forma serveur indiquent simplement si ['execution de la precedente commande recue du module d'application s'est bien deroulee (reponse 'OK') ou non (reponse 'ERROR'). FTR&D/04218 (Ferrieux et al.) 1 0 2840484 Le premier element lexical (token) d'une reponse est. selon un mode de realisation, soit 'OK', soit 'ERROR', et les elements suivants fournissent des informations complementaires. Les commandes definies selon le protocole de ['invention incluent d'une part des commandes cites "generiques" destinees a commander notamment ['allocation des fonctions (encore designees par "ressources") vocales, la liberation de fonctions vocales, I'attente d'evenements, ou encore destinees a ['administration globale ou locale du systeme client-servour selon ['invention. Par exemple, parmi les commandes d'administration globale on trouve des commandes visant a acceder a la liste de modules d'application clients d'une plate-forma serveur donnee, ou visant a terminer une connexion cliente. D'autre part, il est definit selon le protocole de communication de ['invention, des commandes cites "specifiques" destinees a agir chacune sur une fonction vocale (13) particuliere de la plate-forma (10). Les commandes specifiques concernent une ressource de traitement particuliere de la plate-forma serveur: par exemple, le reglage de parametres de reconnaissance vocale, la demande de synthese vocale ou d'interruption de synthese d'un enonce, etc. On donne ci-dessous un exemple de commandes generiques selon un exemple de mise en ceuvre d'un protocole de communication selon ['invention. Commandes generiques a) Com m ande d'al location d'u ne ressou rce de traitement (fon ctio n voca le) fournie par la plate-forma 2s La syntaxe est la suivante: new Cette commande permet d'allouer la ressource identifiee par la chane de caracteres 'nom_de_ressource' dont le type est defini par la chane de caracteres 'type_de_ressource'. Les types de ressources disponibles correspondent a des modules logiciels externes - c'est-a-dire, accessibles via une interface de type API; il s'agit le plus souvent de bibliotheques (libraries) - fournis par la plate-forma FTR8DI04218 (Ferrieux et al.) vocale, par exemple un module de synthese vocale, de reconnaissance vocale, de telephonic etc. La ressource ainsi creee devient alors disponible pour recevoir et repondre aux commandes specifiques a cette ressource definies par la syntaxe suivante. [ ...I Les commandes specifiques vent decrites plus teas dans la description. b) Commande de liberation d'une ressource de traitement fournie par la plate forme La syntaxe est la suivante: delete Cette commande libere la ressource identifiee per tnom_de_ressource'. c) Commandes d'administration (locale) des ressources de traitement Les commandes 'link et 'unlink vent des commandes permettant respectivement d'etablir ou de detruire une connexion de flux d'informations entre deux ressources. Ainsi, la commande: link permet d'etablir une connexion entre le flux de signal de sortie de la ressource identifiee par 'ress1' et le flux de signal d'entree de la ressource identifiee par 'ress2'.. Et la commande: unlik permet a ['inverse de detruire ladite connexion. Par "flux de signal", on entend ici par exemple des echantillons sonores qui transitent entre deux ressources de traitement. d) Commande d'attente d'evenements La syntaxe est la suivante: wait .* Cette commande permet de placer le mod u le d 'application vocale qui a envoye cette commande, dans un etat d'attente d'un evenement venant de la ressource . FTR&D/04218 (Ferrieux et al.) 1 2 2840484 La commande: wait .* I .* place le module d'application dans l'attente d'un evenement venant de la ressource ou de la ressource . De tels evenements vent par exemple la fin de ['activation de la ressource de reconnaissance vocale ou l'arrivee d'un appel telephonique entrant, c'est-a-dire provenant d'un terminal utilisateur distant. Lorsque l'evenement attendu est intervenu, le contenu eventuel de l'evenement est retourne en argument de la reponse 'OK' de la plate-forma. Par exemple, si la ressource est une fonction de reconnaissance vocale, le message de reponse retourne par la plate-forma vocale pourra etre le suivant: OK evt= .reco_done result=Sommaire Dans cette reponse donnee a titre d'exemple, le resultat de l'evenement de reconnaissance vocale mis en ceuvre par la ressource "ress2" est la selection par l'utilisateur distant, du menu vocal "Sommaire". Tous les evenements non selectionnes par le "masque" donne en argument d'une commande wait vent alors elimines. Ainsi, meme si des evenements generes par une ressource vocale consideree ne vent pas exploitables par un module d'application, ce dernier, grace au masque fourni en argument d'une commande wait, ne les recupere pas et n'est done pas perturbe par ces evenements. II en resulte une grande souplesse pour faire bvoluer les ressources vocales independamment du module d'application considere. De plus, cela permet d'eviter ['accumulation inutile d'evenements dans la file d'attente d'evenements de la plate-forma vocale, qui est attribuee au module d'application considere. Commandes speciflques Comme dit plus haut dans la description, les ressources vocales les plus utiles dans le contexte des serveurs vocaux sont: la telephonic, la synthese vocale ou la restitution de sons, la reconnaissance vocale, la detection de frequences DTMF, I'enregistrement de sons preenregistres. FTR&D/04218 (Ferrieux et al.) 13 2840484 Chaque type de ressource possede des caracteristiques propres et done necessite des commandes specifiques. On donne ci-apres des exemples de commandes specifiques selon un exemple de mise en aeuvre de protocole de communication selon ['invention. e) Exemple de commandes relatives a une ressource de telephonic new t Telephonie t 1isten 0296057685 wait t. * t dial 0296057685 t answer t hangup Dans cet exemple, la commande 'new t Telephonfe' alloue une ressource de telephonic, identifiee par "t", disponible dans la bibliotheque (13) de fonctions vocales de la plate-forma. La commande 't listen 0296057685' met la ressource t en attente d'un appel entrant sur le numero 0296057685, c'est-a-dire le numero d'appel du serveur vocal interactif (1). Un appel entrant, en provenance d'un terminal utilisateur distant (3), generera un evenement que la module d'application pourra attendre suite a l'envoi d'une commande 'wait t *'. La commande 't answef permet de specifier a la ressource t d'accepter un appel entrant. La commande 't dial 0296057685' permet de creer un appel sortant par la ressource de telephonic t depuis le numero 0296057685. La commande 't hangup' permet de commander a la ressource t de raccrocher. f) Exemple de commandes relatives a une ressource de synthese vocale new s Synthese link s t s say "Bonjour, bienvenue... " FTR&D/04218 (Ferrieux et al.) 14 2840484 Dans cet exemple, la commande 'new s Synthese' alloue une ressource de synthese vocale, identifiee par "s", disponible dans la bibliotheque (13) de fonctions vocales de la plate-forma (10) La commande 'link s t' permet d'etablir une connexion entre le flux de signal de sortie de la ressource de synthese s et le flux de signal d'entree de la ressource de telephonic f (voir plus haut - Commande generique link). La commande: s say '80njour, blenvenue u qui suit la commande link cidessus permet alors de synthetiser le message entre les guillemets et de le transmettre via la ressource de telephonic t. g) Exemple de commandes relatives a une ressource de reconnaissance vocale rew r Reco link t r r setparam model=OuiNon r start wa i t r. * Dans cet exemple, la commande 'new r Reco' alloue une ressource de reconnaissance vocale, identifiee par "r", disponible dans la bibliotheque (13) de fonctions vocales de la plate-forma (10) La commande 'link t r' permet d'etablir une connexion entre le flux de signal de sortie de la ressource de telephonic t et le flux de signal d'entree de la ressource de reconnaissance r (voir plus haut- Commande generique link). La commande 'r setparam model=OuiNon' permet de parametrer la z reconnaissance vocale selon un modele predefini "OuiNon" selon lequell'utilisateur distant (du terminal 3) doit repondre aux messages vocaux qui lui vent transmis par "out" ou par "non". Enfin la commande 'r start' initialise le processus de reconnaissance vocale. Ce dernier declenchera alors un evenement qui pourra etre recupere par le module d'application, par l'intermediaire de la commande 'wait r. *'. FTR&DtO4218 (Ferrieux et al.) q5 2840484 L'exemple expose ci-dessus de mise en cauvre d'un protocole de communication selon ['invention, notamment en ce qui concerne la syntaxe et ['attribution des noms aux commandes, permet avantageusement de circonscrire la tache de la plateforma serveur (10) a celle d'un noyau logiciel (kemel) totalement independent du materiel utilise pour la plate-forma ainsi que des modules fonctionnels externes offerts (bibliotheque de fonctions 13). Le role de ce noyau logiciel se limite ainsi principalement aux operations suivantes: - accepter de nouvelles connexions TCP; - traiter les commandes generiques re,cues via les connexions TCP avec envoi des reponses correspondantes selon le protocole de communication; - fournir ltenvironnement d'execution et d'interconnexion ('link' / 'unlink') des modules externes (fonctions vocales) charges a la demande ('new' / delete'); - gerer une file d'attente d'evenements pour chaque module d'application client; et deleguer le traitement des commandes specifiques aux ressources fonctionnelles concernees. Conformement a ['invention, I'architecture client-serveur entre la plate forme vocale (serveur) et le ou les modules d'application (clients) permet done de maximiser la modularite et la portabilite de la plate-forma. Par ailleurs, le protocole de communication selon ['invention permet d'instaurer une separation claire des cycles de vie entre la plate-forma et les modules d'application: la plate-forma peut rester pratiquement inchangee tres longtemps (aux mises a jour logicielles pres), alors que les modules clients peuvent etre recycles tres frequemment, par exemple selon les considerations ergonomiques concernant le dialogue entre l'utilisateur et le serveur vocal. L'evolution des modules d'application, qui est independante de celle de la plate forme vocale, peut par consequent s'effectuer sans provoquer de perturbation de service vis-a-vis de l'utilisateur. so Enfin, le protocole de communication selon ['invention permet de confiner les flux d'informations sonores (par ex. vocales) qui vent par nature temps reel, a l'interieur de la plate-forma vocale, liberant ainsi le protocole de FTR&D/04218 (Ferrieux et al.) 1 6 2840484 communication des problemes de gestion de bande passante et de controle de flux. Pour terminer la description de la presente invention, on donne ci-apres dans l'Annexe qui suit, un exemple d'echange de messages selon un protocole de communication selon ['invention, entre une plate-forma serveur et un module d'application vocale, client de la plate-forma. Bien entendu, la presente invention n'est nullement limitee aux modes de realisation decrits ici, mais englobe, bien au contraire, toute variante a la portee de l'homme du metier. FTR&DI04218 (Ferrieux et al.) 1 7 2840484 ANNEXE Exemple d'echanges de messanes entre une Plate-forme serveur et un module d'application client (MAC) Notations: >: commande envoyee du module dapplication vers la plate-forma. I**... **/: commentaires. /** Preparation de ressources en amonf de l'attente d'appel dion utilisateur distant **/ > new t tel /**allocationressourcedetelephonie**/ new s synt /**allocationressource desynthese**/ new r reco /** aJlocation ressource de reconnaissance **/ r setparam model=OuiNon link t r link s t t listen 0296057685 wait t.* /** Arrivee d'un appel entrant provenant du numero utilisateur 0296052404 **J t answer 18 2840484 /** Dialogue avec le terminal utilisateur distant **/ > s say "Bonjour, bienvenue..." s say "Voulez-vous..." r start /** Initialisation processus de reconnaissance vocale **/ wait r.*lt.* /** MAC affends evenement sur r ou sur f **/ > 0K evt=r.result res=Oui /**Reponsecontientresult.evenementsurr: reponse "out" de l'utilisateur distant **/ /** Suite du dialogue avec l'utilisateur disfant **/ /** Raccrochage du terminal utilisateur distant **/ > wait r.*lt.* /** MAC affends evenement sur r ou sur t **/ /** FIN **/ FTR&D/04218 (Ferrieux et al.) 9 2840484 REVENDICATIONS 1. Serveur vocal (1) comprenant une plate-forma vocale (10) offrant un ensemble de fonctions vocales (13) et un module d'application vocale (20) controlant la plate-forma par ltenvoi a celle-ci de commandes destinees a mettre en ceuvre lesdites fonctions, caracterise en ce qutil comprend des moyens de communication (12, 18, 20) apses a mettre en ceuvre un protocole de communication de type client-serveur entre le module d'application et la plate-forma, vis-a-vis duquel le module d'application est le client et la plate forme le serveur, et selon lequel l'envoi de chaque commande par le module d'application est SUiYi de l'envoi d'une reponse par la plate-forma, la reception de cette reponse par le module d'application conditionnant l'envoi d'une commande suivante. 2. Serveur vocal selon la revendication 1, caracterise en ce que lesdits moyens de communication comprennent une vole de transmission (18) apte a permettre la transmission dtinformations entre le module d'application zo (20) et la plate-forma (10) selon un protocole de transmission predefini. 3. Serveur vocal selon la revendication 2, caracterise en ce que lesdits moyens de communication comprennent en outre dans le module d'application vocale (20): z - des moyens de traitement (22) du dialogue apses a generer des commandes codees selon ledit protocole de communication, - des moyens d'envoi (21) de messages de requete integrant lesdites commandes generees, au travers de la vole de transmission (18), selon ledit protocole de transmission, so - des moyens de reception (21) de messages de reponse issus de la plate-forma (10) au travers de la vole de transmission (18) selon ledit protocole de transmission et FTR&Dl04218 (Ferrieux et al.) 2840484 - des moyens d'extraction (21) de reponses codees selon ledit protocole de communication, a partir des messages de reponses re,cus. 4. Serveur vocal selon la revendication 3, caracterise en ce que lesdits moyens de communication comprennent en outre, dans la plate-forma vocale (10): - des moyens de reception (122) de messages de requete emis par le module d'application (20) au travers de la vole de transmission (18) selon le protocole de transmission et - des moyens d'extraction (122) de commandes codees selon ledit protocole de communication, a partir des messages de requete re,cus, - des moyens de traitement (121) apses a traiter les commandes extraites des messages de requete re,cus, et a generer des reponses codees selon ledit protocole de communication, consecutivement au traitement de commandes re,cues du module d'application (20), - des moyens d'envoi (122) de messages de reponses integrant les reponses generees, au travers de la vole de transmission (18), selon ledit protocole de transmission. zo 5. Serveur vocal selon l'une quelconque des revendications 1 a 4, dans lequel le module d'application vocale (20) et la plate-forma vocale (10) vent implantes respectivement sur des systemes informatiques distincts relies l'un avec l'autre par l'intermediaire d'un reseau de communication, par exemple l'lnternet. 6. Serveur vocal selon la revendication 4 ou 5, caracterise en ce que les moyens de traitement (121) de la plate-forma vocale vent apses a traiter en parallele des commandes extraites de messages de requete re,cus d'une pluralite de modules d'application distincts, clients de la plate-forma. 7. Serveur vocal selon la revendication 6, caracterise en ce que la plateforma (10) comporte en outre des moyens de stockage apses a stocker, FTR&DI04218 (Femeux et al.) 21 2840484 dans une file d'attente dediee a chaque module d'application client (20), des informations concernant des evenements survenus en relation avec le traitement de commandes re,cues du module d'application client considere, et relatifs a l'utilisation desdites fonctions vocales (13). 8. Serveur vocal selon l'une quelconque des revendications 2 a 7, dans lequel la vole de transmission (18) est constituee par une connexion selon le protocole de transmission TCP. 9. Serveur vocal selon l'une quelconque des revendications precedentes, caracterise en ce que, selon ledit protocole de communication, le module d'application (20) communique avec la plateforma (10) par l'envoi de commandes incluant: - des commandes generiques pour commander notamment ['allocation de fonctions vocales, la liberation de fonctions vocales, et l'attente d'evenements; et - des commandes specifiques destinees a agir chacune sur une fonction vocale particuliere de la plate-forma; la plate-forma vocale repond ant ap res traitement de chaq ue comma nd e re,cue, par l'envoi d'un message de reponse dont le contenu est indicatif du resultat du traitement de la commande. 10. Serveur vocal selon l'une quelconque des revendications precedentes, caracterise en ce que ledit protocole de communication est un protocole textuel ligne-a-ligne. 11. Systeme informatique comprenant un module d'application vocale pour un serveur vocal scion l'une quelconque des revendications 1 a 10. 12. Systeme informatique comprenant une plate-forma vocale pour un serveur vocal selon l'une quelconque des revendications 1 a 10.