Comme on le conçoit, une interface vocale permet de simplifier et de rendre plus conviviale un service proposé par un fournisseur de service à des utilisateurs de terminaux de télécommunications ou terminaux communicants.

Diverses techniques peuvent tre utilisées, à ce jour, pour l'élaboration d'une interface vocale.

Selon une première technique, les dispositifs fournisseurs de services reposent sur des environnements de description et d'exécution d'applications propriétaires. Les applications ne sont alors pas transposables d'un environnement à un autre, ce qui les rend peu réutilisables. Les seules interfaces ouvertes dans ces dispositifs ne permettent qu'un accès aux données de l'application. Par référence au modèle d'application en couches, ces dispositifs ne permettent qu'une modélisation en deux couches, ce qui est un frein à la portabilité et au développement de parties communes à plusieurs applications.

Une autre technique connue est basée sur l'utilisation d'une architecture client/serveur associée, le cas échéant, à l'utilisation d'un langage à balises tel que VoiceXML ("Voice eXtensible Markup Language"), c'est-à-dire un langage de description des interactions vocales homme-machine de services sous forme de pages.

Il s'agit de faire produire dynamiquement, par un serveur web, des scripts ou pages VoiceXML qui intègrent la présentation des informations et la navigation permettant l'enchaînement desdits scripts.

Si ces solutions permettent la réalisation d'applications portables, ou réutilisables dans d'autres environnements, qui se basent sur l'utilisation de langages de description standard spécifiques aux interfaces vocales, elles ne permettent cependant pas de séparer les couches de présentation et de déplacement ou navigation dans l'application. On observe ainsi très peu de développements communs à plusieurs applications et de réutilisations d'applications. De mme, les applications accessibles depuis plusieurs types de terminaux, en l'absence d'environnement logiciel spécialisé pour ce type d'application, sont réalisées à partir de deux applications distinctes, la première gérant la partie vocale, c'est-à-dire la présentation et la navigation, et la seconde gérant les parties graphiques. La seule partie commune est là encore la couche du modèle de données.

Il existe en outre des dispositifs à langage de description de flux vocal tels VoiceXML ("Voice eXtensible Markup Language") ou SALT ("Speech Application Language Tags"). Ces solutions, appelées Dialog Modules ou Speech Objects en langue anglaise, ne proposent pas de composants vocaux fonctionnant sur le principe requte-réponse utilisables par une couche applicative ayant en charge la navigation ou contrôle de l'application. Ces dispositifs ne sont pas utilisables en dehors d'un contexte d'exécution d'interpréteur VoiceXML ou SALT, c'est-à-dire qu'ils ne sont pas utilisables par une partie d'application chargée uniquement de la navigation et décrite dans un langage de description quelconque et recourant à ces dispositifs pour réaliser la partie présentation. De plus, seules des facilités optimisant la reconnaissance vocale sont proposées, comme la saisie de dates ou de nombres.

Ainsi, l'invention a pour but de proposer de réaliser un service à architecture distribuée, dans lequel il n'est pas nécessaire de réécrire complètement les modules de la couche contrôle, c'est-à-dire la partie dite de navigation de l'application, et de la couche de présentation, lorsqu'on ajoute un accès vocal à

un service, et pour laquelle la description de la partie navigation ou contrôle peut tre réalisée dans un langage quelconque, tandis que la description de la partie de présentation est réalisée avec le langage XML.

Ainsi, selon un aspect de l'invention, il est proposé un dispositif fournisseur de service à interface vocale pour terminaux de télécommunication. Le dispositif comprend une plate-forme de traitement apte à communiquer avec une plate-forme de contrôle hébergeant des moyens de contrôle d'une application mettant en oeuvre le service, et avec une plate-forme vocale, au travers d'un réseau de communication. La plate-forme vocale héberge des moyens d'exécution de fonctions génériques paramétrables et de gestion de communication avec les terminaux de télécommunication des utilisateurs distants. La plate-forme de traitement comprend des moyens de présentation vocale de l'application, des moyens de stockage des codes exécutables desdites fonctions génériques paramétrables. La plate-forme de traitement comprend en outre des moyens de traitement qui traitent une demande d'exécution d'une fonction générique paramétrable, de la part de la plate-forme de contrôle, et qui renvoient le résultat de l'exécution effectuée par la plate-forme vocale ainsi que le contexte de ladite demande.

Dans un mode de réalisation préféré, le dispositif utilise des flux vocaux et des flux de données écrits en langage de balisage étendu pour communiquer.

Dans un mode de réalisation avantageux, lesdits flux de données sont écrits en langage XML ("eXtensible Markup Language").

Dans un mode de réalisation préféré, les flux vocaux comprennent soit des données écrites en langage VoiceXML, soit des données écrites en langage SALT.

Ces langages sont actuellement les plus usités pour décrire des flux vocaux.

Dans un mode de réalisation avantageux, la plate-forme de traitement comprend en outre des moyens de gestion pour gérer des appels de fonctions génériques paramétrables effectués par la plate-forme de contrôle en utilisant le protocole SOAP. Lesdits moyens de gestion sont aptes à générer un flux XML correspondant aux fonctions génériques paramétrables appelées à destination d'un canal de communication gérant la synchronisation du transfert dudit flux vocal vers les moyens de traitement de demandes de codes exécutables.

SOAP est un protocole de communication s'appuyant sur le langage XML pour décrire les échanges et supporté notamment par les protocoles HTTP et SMTP.

Dans un mode de réalisation préféré, les échanges de données s'effectuent au moyen du protocole de communication HTTP.

Les données servent notamment à décrire à la fois le comportement et le contenu des fonctions génériques paramétrables ou composants vocaux.

Dans un mode de réalisation avantageux, le réseau de communication est le réseau Internet.

Selon un aspect de l'invention, il est également proposé un procédé fourniture de service à interface vocale pour terminaux de télécommunication mis en oeuvre au moyen d'un dispositif fournisseur de service selon décrit ci-dessus. On traite une demande d'exécution de code exécutable d'une fonction générique paramétrable, et on renvoie le résultat de l'exécution, après avoir fourni et fait exécuter les flux vocaux.

Dans un mode de mise en oeuvre préféré, on traite des appels de fonctions génériques paramétrables utilisant le protocole SOAP, on génère un flux vocal correspondant aux fonction appelées, et on synchronise la transmission du flux vocal pour le traitement des demandes d'exécution et pour le renvoi des résultats des exécutions des fonctions.

D'autres buts, caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée uniquement à titre d'exemple non limitatif, et faite en référence aux dessins annexés sur lesquels : la figure 1 illustre un dispositif informatique fournisseur de service à interface vocale pour terminaux communicants d'un réseau téléphonique selon l'invention ; la figure 2 illustre un dispositif informatique fournisseur de service à interface vocale pour terminaux communicants d'un réseau téléphonique selon l'invention, utilisant en outre le protocole SOAP ; La figure 1 représente un dispositif informatique fournisseur de service à interface vocale pour terminaux communicants tc d'un réseau téléphonique selon un aspect de l'invention. Ce dispositif est destiné à ajouter un accès vocal à des services existants, c'est-à-dire à permettre à des services existants d'échanger des données sous forme vocale avec les utilisateurs.

Dans le cadre de la présente description, par terminal de télécommunication ou terminal communicant, on entend par exemple un téléphone fixe ou mobile ou un assistant numérique personnel.

Comme on le voit sur la figure 1, ce dispositif comporte une architecture distribuée, c'est-à-dire une architecture selon laquelle l'application logicielle mettant en oeuvre le service est répartie sur plusieurs plates-formes communicantes et modélisée en couches.

Par une approche conceptuelle recourant au modèle en couches, une application peut se composer d'une partie contrôle, d'une partie données, et d'une partie présentation.

Ainsi, le dispositif fournisseur de service selon l'invention comporte des moyens de contrôle 2 permettant de gérer la navigation au sein de l'application, héberge des données 3 qui sont nécessaires au fonctionnement de l'application, c'est-à-dire à

la mise en oeuvre du service, et comporte des moyens de présentation 8 qui permettent notamment de présenter à un utilisateur distant une interface qui correspond au déroulement de l'application, c'est-à-dire une interface qui correspond au point de l'application atteint lors de la navigation.

Le dispositif comprend en outre une plate-forme vocale 4 hébergeant des moyens 5 d'exécution de fonctions ou composants logiciels génériques paramétrables--et de gestion de communication avec les terminaux communicants te des utilisateurs distants. Le dispositif comprend en outre des moyens 6 pour gérer des communications avec la plate-forme de traitement 7 au travers d'un réseau de communication 11. La plate-forme de contrôle 1 et la plate-forme vocale 4 ne communiquent pas directement entre-elles, mais par l'intermédiaire de la plate-forme de traitement 7. En d'autres termes, la plate-forme vocale 4 comprend des moyens 5 permettant l'exécution de fonctions génériques implémentées dans la plate-forme de traitement 7 sous la forme de briques ou de composants logiciels qui sont utiles à l'application et qui peuvent tre appelés par tout service pour sa mise en oeuvre vocale. Ils gèrent aussi les connexions avec les terminaux te d'utilisateurs distants et effectuent l'établissement et la gestion de communications à distance avec des terminaux communicants te d'utilisateurs distants, comme cela est connu en soi.

De plus, le dispositif comprend une plate-forme de traitement 7 comprenant des moyens 8 de présentation vocale de l'application mettant en oeuvre le service, des moyens de stockage 9 de codes exécutables pour l'exécution des fonctions génériques paramétrables, et des moyens de traitement 10 qui traitent une demande, de la part de la plate-forme de contrôle 1, d'exécution d'une fonction générique paramétrable, et qui renvoient le résultat de l'exécution effectuée par la plate-forme vocale 4 ainsi que le contexte de la demande. On entend par contexte, un ensemble de données comprenant au moins le numéro de session de la plate-

forme de contrôle 1. Les trois plates-formes 1,4, et 7 sont pourvues de tous les moyens matériels et logiciels leur permettant de communiquer par le réseau de communication 11, par exemple le réseau Internet.

Le dispositif informatique qui vient d'tre décrit est ainsi réalisé sous la forme d'une architecture distribuée accessible à distance pour un utilisateur et permet à un fournisseur de service d'ajouter à des parties d'un service mis en oeuvre des accès vocaux, c'est-à-dire une fonctionnalité d'échange de flux vocaux et ce rapidement et sans connaissance d'un langage spécifique au- domaine vocal. Ce dernier met en oeuvre un accès vocal au service en ne manipulant que des données décrivant le comportement et le contenu d'une fonction générique paramétrable souhaitée, qu'il décrit au moyen du langage XML dans le flux créé ou dans un appel effectué au moyen du protocole SOAP, en réponse à une requte signalant au service une connexion ou déconnexion d'un utilisateur du service, ou le résultat d'une fonction générique paramétrable précédente.

Un tel dispositif fournisseur de service s'utilise de la façon qui suit.

Un utilisateur établit une communication entre son terminal tc et la plate-forme vocale 4. Les moyens 5 sont ainsi mis en oeuvre pour gérer les connexions avec les terminaux distants tc.

On notera que la communication établie entre l'utilisateur distant et le dispositif peut s'effectuer directement en utilisant un réseau téléphonique.

La plate-forme vocale 4 envoie une première requte de flux vocal selon le protocole HTTP à la plate-forme de traitement 7. En argument de cette requte figurent notamment le numéro de téléphone appelant, le numéro de téléphone appelé, et une notification de connexion. Un tel protocole HTTP ("Hyper Text Transfer Protocol") est un protocole très répandu de transfert de données, à la portée d'un homme du métier. Il ne sera donc pas détaillé par la suite.

Les moyens de traitement 10 émettent alors une requte signalant la connexion de-l'utilisateur au service, à destination de la plate-forme de contrôle 1. En argument de cette requte émise par les moyens de traitement 10 figurent notamment l'événement de connexion, car à la première requte, les moyens de traitement 10 ne disposent pas encore du numéro de session desdits moyens de contrôle 1, ainsi que le numéro de téléphone appelant et le numéro de téléphone-appelé.

La plate-forme de contrôle 1 reçoit alors cette requte et lance l'exécution de l'application en mettant notamment en oeuvre les moyens de contrôle ou de navigation 2 et en utilisant les données 3. La partie navigation ou contrôle peut tre décrite dans un langage quelconque, par exemple les langages ou interfaces ASP,. net, JSP, PHP, CGI... Un flux XML décrivant un composant vocal de présentation est retourné, en réponse, à la plate-forme de traitement 7. En argument de ce flux XML, figurent éventuellement le numéro de session des moyens de contrôle 2 de la plate-forme de contrôle 1, le nom du composant d'interface, ou fonction générique paramétrable, demandé, et les paramètres de configuration du composant.

La plate-forme de traitement 7 traite cette requte en générant et transférant un flux vocal vers la plate-forme vocale 4, en réponse à ladite première requte envoyée par la plate-forme vocale 4. Le flux vocal est écrit en langage VoiceXML ou SALT, qui sont les plus communément utilisés, mais peuvent tre écrits dans d'autres langages. En argument de ce résultat d'exécution figure le numéro de session des moyens 10 de la plate-forme de traitement 7.

L'utilisateur connecté au service interagit alors avec la plate-forme vocale 4 en réponse au flux vocal reçu et exécuté par les moyens 5. Au cours ou au terme de la fonction proposée par le composant, une nouvelle requte à destination de la plate-forme de traitement 7 peut tre émise. En argument de cette requte, figurent alors le numéro de session de la plate-forme de traitement

7, le résultat de l'opération réalisée par le composant, et d'éventuels attributs du résultat.

Les moyens de traitement 10 émettent alors une requte signalant le résultat de l'opération réalisée par-le composant, à destination de la plate-forme de contrôle 1. En argument de cette requte émise par les moyens de traitement 10 figurent notamment l'événement de résultat, et éventuellement le numéro de session desdits moyens de contrôle 2 de la plate-forme de contrôle 1.

La suite du déroulement est similaire à ce qui a été décrit précédemment. La plate-forme de contrôle 1 est en outre susceptible de recevoir des demandes de fin du service en cas de déconnexion de l'utilisateur.

La figure 2 représente un dispositif similaire à celui de la figure 1, mais utilisant en outre le protocole SOAP ("Simple Object Access Protocol"), c'est-à-dire un protocole d'accès objet.

Un tel protocole est constitué par un protocole classique à la portée d'un homme du métier et ne sera donc pas davantage décrit. On notera cependant qu'il s'appuie sur des protocoles tels que le protocole HTTP pour l'exécution de procédures distantes et permet de s'affranchir des contrôles de syntaxe XML. Dans ce mode de réalisation, le dispositif comporte ainsi une brique additionnelle qui permet d'éviter de manipuler des données sous forme XML lors de l'échange de flux entre la plate-forme de traitement 7 et la plate-forme de contrôle 1.

Le dispositif comprend ainsi, en outre, des moyens de traitement 12 pour traiter les appels de composants logiciels effectués par la plate-forme de contrôle 1 en utilisant le protocole SOAP. Ces moyens de traitement 12 sont conçus pour générer un flux XML, correspondant aux composants appelés, à destination d'un canal de communication 13 qui gère la synchronisation du transfert avec l'entité produisant le flux vocal vers les moyens de traitement 10 des demandes d'exécutions de codes exécutables et des réponses consécutives.

Pour l'utilisation du service, un utilisateur établit une communication entre son terminal communicant tc et la plate- forme vocale 4, comme mentionné précédemment. La plate-forme vocale 4 envoie une première requte HTTP de flux vocal à la plate-forme de traitement 7. Les moyens de traitement 10 transmettent cette requte signalant la connexion de l'utilisateur au service, à destination de la plate-forme de contrôle 1. En argument de cette requte émise par les moyens de traitement 10 figurent notamment l'événement de connexion, car à la première requte, les moyens de traitement 10 ne disposent pas encore du numéro de session des moyens de contrôle 2 de la plate-forme de contrôle 1.

Comme dans l'exemple précédemment décrit, la plate- forme de contrôle 1 reçoit cette requte et lance l'exécution de l'application en utilisant notamment les moyens de contrôle 2 et les données 3. La plate-forme 1 invoque alors une fonction générique auprès des moyens de traitement d'appel 12 de composants effectué par la plate-forme de contrôle 1 en utilisant le protocole SOAP. En argument de cette requte. figurent le numéro de session des moyens de contrôle 2 de la plate-forme de contrôle 1, le nom du composant d'interface demandé, et les paramètres de configuration du composant.

Les moyens de traitement d'appel 12 de composants de la plate-forme de traitement 7 traitent cette requte en générant et transférant un flux vocal dans une file d'attente de synchronisation du canal de communication 13. Cela entraîne des acquittements en cascades des requtes précédentes. Le canal de communication 13 transmet un flux vocal aux moyens de traitement 10 qui génèrent et transfèrent un flux vocal, en réponse, vers la plate-forme vocale 4. On notera que le flux vocal est de préférence écrit en langage VoiceXML ou SALT, ce qui présente l'avantage d'utiliser un langage largement répandu.

Evidemment, d'autres langages peuvent tre utilisés.

L'utilisateur entre alors, comme précédemment décrit, en communication avec la plate-forme vocale 4. Une nouvelle requte à destination de la plate-forme de traitement 7 peut alors, le cas échéant, tre émise. Dans ce cas, en argument de cette requte, figurent le numéro de session desdits moyens de traitement 10 de la plate-forme de traitement 7, le résultat de l'opération réalisée par le composant, et d'éventuels attributs du résultat.

La suite du déroulement est similaire à ce qui a été décrit précédemment, la plate-forme de contrôle 1 pouvant en outre tre susceptible de recevoir des demandes de fin de service en cas de déconnexion de l'utilisateur.

Comme on le conçoit, les fonctions mises en oeuvre par les briques ou composants logiciels d'exécution de fonctions génériques réalisent des fonctions génériques, c'est-à-dire universelles, qui sont paramétrables afin d'tre intégrées dans le plus grand nombre de services possibles. Par exemple, les fonctions génériques paramétrables comprennent une fonction d'identification d'un utilisateur, permettant à un utilisateur de s'identifier, et optionnellement par exemple de s'authentifier, de choisir un mode d'identification en se basant sur un vocabulaire de noms sous forme vocale d'un annuaire ou répertoire, ou sur d'autres types de vocabulaire (codes postaux, dates...), ou de quitter la partie du service en cours en énonçant ou tapant sur un clavier des commandes paramétrées. Les fonctions génériques paramétrables comprennent en outre une fonction menu permettant de proposer des choix à l'utilisateur, avec optionnellement, par exemple, une confirmation de choix ou une possibilité de quitter la partie du service en cours, ainsi que différents formulaires correspondant à des successions de menus et d'acquisitions d'informations avec diverses options. Elles comprennent également des fonctions de déplacement ou"navigation"dans le service dans lesquelles les données de listes à manipuler sont décrites selon des définitions de type de document (DTD ou

Definition Type Document en langue anglaise ou selon des schémas XML), les documents correspondants étant passés en argument des fonctions, et une fonction de déconnexion du service.

A chaque fonction générique paramétrable est associée une définition du type de document ou un schéma XML.

Bien entendu, d'autres fonctions peuvent également tre envisagées et intégrées à la demande à un service préexistant, et ce, de manière particulièrement simple. Il suffit pour cela de construire une nouvelle fonction générique et d'y intégrer les différentes interfaces de la solution.

L'invention permet donc d'ajouter un accès vocal, c'est-à- dire de manière générale un échange de données en mode vocal à un service à architecture distribuée, sans nécessiter la réécriture complète de la partie navigation ou contrôle ni de la partie présentation de l'application du service considérée. La description de la partie navigation peut tre réalisée dans un langage quelconque, tandis que la description de la partie présentation est réalisée au moyen du langage XML