Système de gestion d'un service interactif multimodal

Arrière-plan de l'invention

L'invention se situe dans le domaine des services interactifs multimodaux.

D'une façon générale, nous définirons la "multimodalité" comme l'utilisation de plusieurs modalités de manière alternée ou parallèle, de façon combinée ou redondante.

Du point de vue système, une modalité, quelle soit d'entrée ou de sortie, se définit par :

- un système représentationnel ;

- un dispositif physique d'interaction ; ou par

- l'association d'un système représentationnel et d'un dispositif physique d'interaction.

A titre d'exemple non limitatif, l'invention s'applique à des services interactifs accessibles par au moins une de ces modalités :

- téléphonie fixe ;

- téléphonie mobile ;

- téléphonie I P (I nternet Protocol) ;

- accès I nternet ;

- vidéo.

Dans le contexte de l'invention, les services multimodaux interactifs peuvent être basés sur l'utilisation d'un ou plusieurs formalismes de présentation.

Ces formalismes peuvent être standardisés, et par exemple conformes aux standards :

- HTML (HyperText Markup Language) et XML (Eξxtended Markup Language) ; et

- VoiceXML : langage XML normalisé par le W3C (World Wide Web Consortium) et définissant les interactions vocales.

On connaît déjà deux langages standardisés utilisés pour le développement de services multimodaux interactifs. Ces langages permettent d'ajouter une interface vocale à un site Web :

- le langage SALT (Speech Application Language Tags) qui peut être utilisé dans un document décrit au format HTML ou avec tout autre type

de description dérivé de SGML (Standard Generalized Markup Language) ; et

- le langage X+ V basé sur la combinaison de XHTML et de Voice XML

Malheureusement les langages SALT et X+ V ne permettent pas de donner une description fonctionnelle du service multimodal.

On connaît également le métalangage GDialogXML permettant de définir des applications multimodales et/ou multilangues. Ce métalangage est issu du projet européen Gemini (2002-2004) dont l'un des objectifs était d'élaborer des outils pour créer rapidement des systèmes de dialogue.

Le métalangage GDialogXML repose sur un formalisme basé sur la notion d'état de dialogue.

I l permet plusieurs niveaux de modalisation, dont un niveau fonctionnel (le State Flow Model), ce niveau permettant de définir, de façon très générale, les principales étapes d'un service interactif multimodal.

Mais ce langage ne permet pas de définir des mécanismes de cohérence et de synchronisation entre les différentes modalités.

Objet et résumé de l'invention

Selon un premier aspect, l'invention concerne un système de gestion d'un service interactif, ce service étant accessible par une pluralité de modalités.

Ce système comporte un module de synchronisation apte à interpréter une description fonctionnelle d'une pluralité de tâches susceptibles d'être exécutées au cours d'une mise en œuvre de ce service. I l comporte aussi, pour chacune des modalités, un module d'exécution apte à :

- interpréter une description technique d'au moins une des tâches précitées, cette description technique étant spécifique à cette modalité ; et

- envoyer, au module de synchronisation, des données opérationnelles relatives à une tâche exécutée par ce module d'exécution.

Ainsi, le module de synchronisation inclus dans le système selon l'invention reçoit des données opérationnelles relatives à l'exécution des tâches par les différentes modalités.

Ces données opérationnelles sont par exemple constituées par un identifiant de la tâche en cours d'exécution par une modalité, et par un état d'exécution de cette tâche.

Le module de synchronisation possède, grâce à ces données opérationnelles une vision complète du déroulement du service par chacune des différentes modalités.

Ces données opérationnelles sont utilisées par le module d'exécution pour maintenir la cohérence et la synchronisation entre les différentes modalités. Aussi, l'invention concerne également, sous un deuxième aspect, un module de synchronisation d'une pluralité de modalités d'accès à un service interactif.

Ce module de synchronisation comporte :

- des moyens d'interprétation d'une description fonctionnelle d'une pluralité de tâches susceptibles d'être exécutées dans une mise en œuvre de ce service ;

- des moyens de réception de données opérationnelles relatives à une tâche exécutée par un module d'exécution associé à une de ces modalités ; - des moyens pour sélectionner une tâche, à partir de données opérationnelles reçues en provenance d'au moins un de ces modules d'exécution et de la description fonctionnelle précitée ; et

- des moyens d'envoi, à au moins un module d'exécution, d'une commande comportant un identifiant de la tâche ainsi sélectionnée. Dans un mode particulier de réalisation de l'invention, au moins un module d'exécution inclus dans le système de gestion selon l'invention est apte à recevoir une telle commande et à exécuter la tâche dont l'identifiant est compris dans ladite commande.

La contribution de ce module d'exécution à la prestation du service est donc sous le contrôle du module de synchronisation.

Dans un mode particulier de réalisation de l'invention, le service multimodal interactif est décrit à un niveau fonctionnel, indépendamment de la nature des différentes modalités, dans un fichier dit "de description fonctionnelle".

Ce fichier permet avantageusement de concevoir un service multimodal interactif de façon générique par un ensemble de tâches et de transitions entre ces tâches.

Dans un mode de réalisation particulier, les parties de la description fonctionnelle de service qui ne sont pas suffisamment génériques peuvent être déportées dans des composants logiciels référencés dans le fichier de description fonctionnelle.

Dans un cas particulier de réalisation de l'invention, le fichier de description fonctionnelle est au format XML Dans ce cas, les composants logiciels précités peuvent être des servlets.

Le module de synchronisation inclus dans le système de gestion conforme à l'invention permet d'assurer la cohérence et la synchronisation entre les différentes tâches, selon le mécanisme décrit dans le fichier de description fonctionnelle. Conformément à l'invention, chaque modalité est associée à un module d'exécution apte à communiquer avec le module de synchronisation précité. Chacun de ces modules d'exécution est apte à interpréter une description technique spécifique à cette modalité.

Dans un mode particulier de réalisation, cette description technique est décrite dans un fichier dit « fichier de description technique », dans un format spécifique à chaque modalité. Ce fichier reprend certaines ou toutes les tâches décrites dans le fichier de description fonctionnelle.

Le module de synchronisation conforme à l'invention a pour fonction principale d'assurer la synchronisation entre l'exécution des tâches par les différentes modalités.

Pour ce faire, chaque module d'exécution d'une modalité est apte à envoyer au module de synchronisation des données opérationnelles relatives à une tâche exécutée par ce module d'exécution, et à recevoir, en provenance de ce module de synchronisation, l'identifiant de la prochaine tâche qui doit être mise en œuvre par ce module d'exécution.

Le système de gestion de service interactif multimodal conforme à l'invention permet donc de synchroniser les différentes modalités à des points déterminés du dialogue interactif, tout en laissant une grande liberté à chacune de ces modalités dans l'exécution des différentes tâches,

le tout dans un environnement cohérent décrit dans le fichier de description fonctionnelle.

Par exemple, la mise en œuvre des tâches fonctionnelles dans la description technique d'une modalité peut être plus détaillée ou regrouper plusieurs tâches fonctionnelles en fonction des capacités de cette modalité. Ainsi, une modalité graphique peut regrouper une tâche d'identification et une tâche d'authentification, ces deux tâches devant préférentiellement être séparées dans une modalité vocale.

La description fonctionnelle ne préjuge donc pas de l'implémentation dans une modalité. Le formalisme, dans le fichier de description fonctionnelle, reste à un niveau fonctionnel et ne tient pas compte des capacités techniques de mise en œuvre par une modalité donnée.

La responsabilité de mise en œuvre technique par les modalités incombe à la description technique faite dans le fichier de description technique associé à cette modalité.

Dans un mode particulier de réalisation de l'invention, la description fonctionnelle du service s'appuie sur des tâches, des transitions entre ces tâches, et des événements. Dans un mode particulier de réalisation de l'invention, le fichier de description fonctionnelle donne, pour chacune des tâches, une description littérale de celles-ci ; cette description peut être vue comme un commentaire de la tâche.

Dans un mode particulier de réalisation de l'invention, le fichier de description fonctionnelle permet d'associer des types prédéterminés à au moins certaines tâches.

Dans un mode particulier de réalisation de l'invention, on définit le type "rassemblement général". Une tâche de type "rassemblement général" se différencie des autres en ce que l'entrée d'une modalité dans une tâche de ce type force les autres modalités à rejoindre cette tâche.

Dans ce mode particulier, le module de synchronisation conforme à l'invention est apte à envoyer, à chacun des modules d'exécution, une commande comportant l'identifiant d'une tâche de type rassemblement général à exécuter, dès lors qu'il a reçu des données opérationnelles représentatives du fait que cette tâche était active dans au moins un des modules d'exécution.

Dans un mode particulier de réalisation de l'invention, on définit le type "seuil d'exécution".

Une tâche de type "seuil d'exécution" est une tâche associée à un seuil dont la valeur représente le nombre de fois que cette tâche doit être réalisée par une ou plusieurs des modalités actives, indépendamment des types de modalités. Si le seuil est atteint, la modalité exécute la tâche suivante.

Dans ce mode particulier de réalisation, le module de synchronisation conforme à l'invention est apte à envoyer, à chacun des modules d'exécution, une commande comportant l'identifiant d'une prochaine tâche à exécuter dès lors qu'il a reçu des données opérationnelles représentatives du fait qu'une tâche de type "seuil d'exécution" avait été exécutée un nombre de fois au moins égal au seuil précité par les modules d'exécution pris dans leur ensemble. Lorsqu'un service interactif diffuse des messages publicitaires, la tâche de diffusion de ces messages pourra avantageusement être une tâche de type "seuil d'exécution". Ainsi, on ne diffuse qu'un nombre prédéterminé de fois (fixé par le seuil) le message publicitaire à un utilisateur qui accéderait au service par différentes modalités. Dans un mode particulier de réalisation de l'invention, la description fonctionnelle associe, à au moins tâche dite « tâche de rendez- vous », une condition de déblocage liée à la réception, par le module d'exécution, d'au moins une donnée opérationnelle représentative d'un état d'exécution prédéterminé de cette tâche de rendez-vous par au moins un des modules d'exécution, le module de synchronisation étant apte à : - attendre la détection de la réalisation de ladite condition de déblocage ou d'un événement plus prioritaire pour envoyer, à au moins un module d'exécution, une commande comportant l'identifiant de ladite tâche de rendez-vous. Ainsi, si une modalité arrive dans une tâche de type "rendez- vous", elle reste dans l'état de réalisation de cette tâche jusqu'à ce que la condition de rendez-vous se réalise, ou qu'un événement plus prioritaire se déclenche.

Pour une tâche de type "rendez- vous", la condition de déblocage est liée à la réception, par le module d'exécution, d'au moins une donnée opérationnelle représentative d'un état d'exécution

prédéterminé d'au moins une tâche active dans un des modules d'exécution.

Dans un mode de réalisation particulier, on peut préciser, dans le fichier de description fonctionnelle, si la tâche doit être exécutée avant ou après la réalisation de la condition de déblocage.

Dans un mode particulier de réalisation de l'invention, la description fonctionnelle permet de spécifier au moins un événement extérieur auxdites tâches actives dans lesdits modules d'exécution, et le module de synchronisation est apte à envoyer, à au moins un module d'exécution, sur détection de la réalisation de cet événement, une commande représentative d'une action que doit exécuter ledit module d'exécution.

Autrement dit, la description fonctionnelle permet de préciser des événements dont l'occurrence, ou plutôt la détection de l'occurrence par le module de synchronisation, déclenche une action particulière.

Les événements sont définis pour une tâche donnée ou pour l'ensemble des tâches du service. I ls constituent des conditions de déclenchement d'actions liées à la détection, par le module de synchronisation, d'un événement extérieur aux tâches actives dans les différents modules d'exécution des modalités.

Dans un mode particulier de réalisation de l'invention, le fichier de description fonctionnelle comporte une tâche dite « composée », à savoir une tâche comportant au moins deux sous-tâches.

La description de cette tâche composée dans le fichier de description technique spécifique à au moins un desdits modules d'exécution se limite à la description technique d'au moins certaines de ces sous-tâches. Et les données opérationnelles envoyées au module de synchronisation par ce module d'exécution sont constituées par des données opérationnelles de chacune des sous-tâches spécifiques à ce module, obtenues au fur et à mesure de leur exécution.

L'invention concerne également un procédé de synchronisation d'une pluralité de modalités d'accès à un service interactif.

Ce procédé utilise une description fonctionnelle d'une pluralité de tâches susceptibles d'être exécutées au cours de la mise en œuvre de ce service. Ce procédé comporte :

- une étape de réception de données opérationnelles relatives à une tâche exécutée par un module d'exécution associé à une modalité ;

-une étape de sélection d'une tâche, à partir de données opérationnelles reçues en provenance d'au moins un module d'exécution et de la description fonctionnelle précitée ; et

- une étape d'envoi, à au moins un module d'exécution, d'une commande comportant un identifiant de la tâche ainsi sélectionnée.

Dans un mode particulier de réalisation, les différentes étapes du procédé de synchronisation sont déterminées par des instructions de programmes d'ordinateurs.

En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un module de synchronisation ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de synchronisation tel que décrit ci-dessus.

Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.

D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type I nternet.

Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

Brève description des dessins

D'autres caractéristiques et avantages de la présente invention ressorti ront de la description faite ci-dessous, en référence aux dessins et annexes qui en illustrent plusieurs exemples de réalisation dépourvus de tout caractère limitatif. Dans ces figures et annexes :

- la figure 1 représente un système de gestion conforme à l'invention dans un mode particulier de réalisation de l'invention ;

- la figure 2 représente, sous forme d'organigramme, les principales étapes d'un procédé de gestion conforme à l'invention ; - les figures 3 à 5 représentent, sous forme de chronogramme, des mécanismes de synchronisation pouvant être utilisés dans l'invention ; et

- les annexes A a F sont des fichiers XML de description fonctionnelle conformes à l'invention.

Description détaillée d'un mode de réalisation

La figu re 1 représente un système de gestion 10 conforme à l'invention.

Dans ce mode de réalisation, le système de gestion 10 est un serveur apte à communiquer avec un ordinateur 11 et avec un téléphone cellulaire 12 via des réseaux de télécommunications non représentés ici.

Ce système 10 de gestion permet de fournir un service interactif multimodal dont la description fonctionnelle est donnée dans le fichier XML de l'an nexe A. D'un point de vue fonctionnel, on comprend, à la lecture de cette annexe, que le service comporte deux tâches principales, nommées respectivement "Connexion" et "Accueil".

La tâche "Connexion" est une tâche par laquelle l'utilisateur se connecte en s'identifiant et en s'authentifiant. Cette tâche est suivie par la tâche "Accueil" dans laquelle on présente à l'utilisateur son espace personnel.

Dans ce mode particulier de réalisation de l'invention, afin de spécifier la transition entre la tâche "Connexion" et la tâche "Accueil", on utilise un champ délimité par les balises < Destination> et </Destination> .

A l'an nexe B, on a donné, pour le même service, le contenu d'un fichier XML de description fonctionnelle à un niveau plus détaillé.

Dans ce fichier, la tâche "Connexion" est une tâche complexe qui comporte deux sous-tâches "Identification" et "Authentification".

La représentation détaillée de l'annexe B est particulièrement judicieuse dans le contexte d'un dialogue vocal, du fait qu'une modalité vocale est difficilement adaptée pour saisir plusieurs informations simultanément, en l'espèce un identifiant utilisateur et un mot de passe.

Conformément à l'invention, l'implémentation, par les différentes modalités, des tâches décrites fonctionnellement dans le fichier 200 est très libre. En conséquence, le dialogue vocal de la modalité vocale est décomposé en autant de sous-tâches que la description fonctionnelle le permet. En revanche, la modalité visuelle ne se réfère qu'à la tâche "Connexion", les deux autres sous-tâches étant réalisées simultanément.

Le système de gestion de service interactif 10 conforme à l'invention comporte un module de synchronisation 20 apte à interpréter le fichier de description fonctionnelle 200 dont le contenu est celui du fichier XML de l'annexe B.

Dans l'exemple décrit ici, l'utilisateur peut accéder au service interactif multimodal par l'ordinateur personnel 11 et par le téléphone mobile 12, ce qui définit deux modalités d'accès, à savoir une modalité graphique pour l'ordinateur personnel 11 et une modalité vocale pour le téléphone mobile 12.

Le système de gestion 10 comporte également deux modules d'exécution 31 et 32 associés respectivement à la modalité graphique et à la modalité vocale.

Chacun de ces modules d'exécution 31 , 32 est apte à interpréter un fichier de description technique 310, 320 spécifique à la modalité à laquelle il est associé.

Dans le mode de réalisation décrit ici, le fichier 200 de description fonctionnelle est conforme au format XML et on utilise le langage Java dans un environnement N-TI ERS pour le module de

synchronisation 20 et pour les modules d'exécution 31 , 32 des différentes modalités.

Le fichier 200 de description fonctionnelle permet de définir le service multimodal interactif de façon fonctionnelle, de manière lisible et générique, ainsi que des éléments de synchronisation qui sont implémentés dans une ou plusieurs des modalités.

Ces éléments de synchronisation peuvent notamment être constitués par des événements ou des tâches de type "rendez- vous", "rassemblement général" ou "seuil d'exécution". Dans l'exemple décrit ici, chacune des modalités implémente dans les fichiers de description technique 310, 320 ces points de synchronisation sous la forme d'un échange de requêtes/ réponses HTTP avec le module 20 de synchronisation. En variante, ces points de synchronisation peuvent être implémentés sous forme d'appels de fonctions.

On supposera ici que dans le fichier de description technique 310 lié à la modalité graphique, les sous-tâches d' "Identification" et d' "Authentification" sont réalisées dans une seule page Web qui contient deux zones de saisie à cet effet et un bouton de validation. En revanche, la tâche "Connexion" nécessitera, dans le fichier

320 de description technique lié à la modalité vocale, deux phases d'interaction, une pour demander la donnée d'identification et l'autre pour demander la donnée d'authentification.

Le module 20 de synchronisation conforme à l'invention comporte un processeur 21 , une mémoire vive 22, une mémoire morte 23, et des moyens 24 de communication avec les modules d'exécution 31 et 32 de chacune des modalités.

Dans l'exemple de réalisation décrit ici, la mémoire morte 23 mémorise un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé de synchronisation conforme à l'invention.

Les principales étapes de ce procédé sont données sous forme d'organigramme à la figu re 2.

Nous supposerons maintenant que l'utilisateur de l'ordinateur personnel 11 saisit, au moyen de l'interface Web, son identifiant et son

mot de passe d'identification, puis il valide cette saisie par l'appui sur une touche OK prévue à cet effet.

Cette validation génère une requête R1 émise par l'ordinateur personnel 1 1 à destination du moteur d'exécution 31 associé à la modalité graphique.

Sur réception de cette requête R1 , le module d'exécution 31 vérifie, dans le corps de la tâche "Connexion" du fichier de description technique, que la saisie est valide.

Dans l'exemple décrit ici, nous supposerons que le fichier de description technique 310 spécifie qu'une fois cette vérification terminée, une requête de synchronisation R2 doit être envoyée au module de synchronisation 20.

Cette requête de synchronisation R2 comporte l'identifiant de la tâche active (tâche "Connexion") et un état d'exécution représentatif du fait que cette tâche de connexion s'est terminée normalement.

Cette requête de synchronisation R2 est reçue par les moyens 24 de communication du module 20 de synchronisation au cours d'une étape E10 du procédé de synchronisation.

Cette étape E10 de réception est suivie par une étape E20 au cours de laquelle le module de synchronisation 20 sélectionne la prochaine tâche que doit exécuter le module d'exécution 31 associé à la modalité graphique.

Cette sélection utilise d'une part le fichier de description fonctionnelle 200 et d'autre part les données d'état reçues en provenance des autres modalités.

On supposera dans cet exemple que l'utilisateur est, dans son téléphone mobile 12, dans une application de jeu et qu'une tâche du module 32 d'exécution décrite dans le fichier de description technique 320 a envoyé, au module de synchronisation 20, des données d'état représentatives de l'accès à un nouveau palier dans ce jeu.

Dans l'exemple décrit ici, le fichier de description fonctionnelle

200 spécifie que, lorsque des données d'état représentatives d'un accès à un nouveau palier de jeu sont reçues par le module de synchronisation 20, toutes les modalités doivent exécuter la tâche associée à ce nouveau palier.

Autrement dit, la tâche associée à ce nouveau palier est une tâche dite "de rassemblement général" au sens de l'invention.

En conséquence, le module de synchronisation 20 sélectionne, au cours d'une étape E20, la tâche d'exécution de ce nouveau palier. Puis, au cours d'une étape E30, le module de synchronisation 20 envoie, au moteur 31 d'exécution de la modalité graphique, une commande R3 comportant l'identifiant de la tâche d'exécution du nouveau palier.

Cette commande R3 est traitée par le moteur 31 d'exécution de la modalité vocale et transmise, sous forme d'une réponse R4, à l'ordinateur personnel 11.

Sur réception de cette requête R4, l'interface graphique de l'ordinateur personnel 1 1 charge le nouveau palier de jeu.

Nous allons maintenant décrire, en référence à l'an nexe C et à la figu re 3, l'utilisation d'une tâche de type "rassemblement général" conformément à un mode particulier de réalisation de l'invention.

Dans le fichier de description fonctionnelle donné à l'annexe C, on utilise l'expression "generalMeeting = true" pour spécifier que la tâche "Taski " est une tâche de type "rassemblement général". Ce fichier spécifie une transition selon laquelle la tâche "Taski " doit être suivie par la tâche "TaskN".

Sur le chronogramme de la figure 3, on considère qu'à l'instant t1 les modalités M1 , M2, M3 exécutent respectivement les tâches actives A, B et Y. On suppose qu'à l'instant t2 la modalité M1 bascule dans la tâche active C et que la modalité M2 bascule dans la tâche active RG de type "rassemblement général".

Le module d'exécution 20 envoie alors une commande à chacun des moteurs d'exécution associés à toutes les modalités, de sorte que chacun de ces moteurs d'exécution exécute la tâche de rassemblement général RG de la façon spécifiée dans le fichier de description technique propre à ce moteur.

Puis, une fois cette tâche exécutée, chacun des moteurs d'exécution exécute une tâche qui lui est propre, par exemple les tâches respectives D, E et Z.

Nous allons maintenant décrire en référence à l'an nexe D et à la figu re 4, l'utilisation d'une tâche de type "seuil d'exécution".

A l'annexe D, cette tâche de nom "Taski " est associée à un seuil de valeur 1. En référence à la figure 4, nous supposerons qu'à l'instant t2, la modalité M1 bascule de la tâche A vers une tâche S de type "seuil d'exécution", puis à l'instant t4, de cette tâche S vers la tâche B.

Ainsi, lorsque la modalité M2 bascule de la tâche B à la tâche S, (instant t3) cette tâche S n'est pas mise en œuvre du fait qu'elle a déjà été mise en œuvre une fois, en l'occurrence par la modalité M1.

La modalité M2 bascule donc directement dans la tâche C.

Dans l'exemple de la figure 4, la modalité M3 n'est pas concernée.

En référence à l'an nexe E et à la figu re 5, nous allons maintenant décrire l'utilisation d'une tâche de type "rendez-vous" conformément à l'invention.

Dans l'exemple de l'annexe E, la tâche Taski est de type "rendezVous". On lui associe un attribut "wait=AfterProcessing", pour préciser le fait que la tâche doit être exécutée avant le test de la réalisation de la condition de déblocage du rendez-vous.

Plus précisément, la figure 5 représente un exemple de réalisation dans lequel la condition de déblocage est liée au fait que les modalités M1 et M2 doivent se synchroniser au niveau d'une tâche RV de type "rendez- vous". Ainsi, lorsque la modalité M2 bascule, à l'instant t2, dans la tâche "rendez- vous", elle reste dans cet état jusqu'à ce que la tâche M1 y bascule à son tour, à l'instant t3.

Concrètement, ceci se traduit par le fait que le module de synchronisation 20 attend la réception de données provenant des modules d'exécution associés à chacune de ces modalités, et représentatives du fait que chacune de ces tâches RV s'est déroulée normalement.

Dans l'exemple de la figure 5, la modalité M3 n'est pas concernée par le rendez-vous.

L'an nexe F donne un exemple de fichier de description fonctionnelle spécifiant un événement (de nom "Evénement") au sens de l'invention.

Conformément à l'invention, un événement peut intervenir à tout moment lors de la réalisation d'une tâche. I l fera l'objet d'un traitement ou non suivant qu'il apparaît ou non dans le fichier 200 de description fonctionnelle. Dans les exemples précédemment décrits, on utilise la balise

"Destination" pour spécifier, dans une tâche, la prochaine tâche à exécuter.

Dans un mode de réalisation particulier, ces transitions peuvent être de différents types. On considérera notamment les transitions de type statique selon lesquelles on renseigne explicitement le nom de la prochaine tâche à exécuter dans le fichier de description fonctionnelle.

L'invention supporte également les transitions de type "dynamique" pour lesquelles on exécute un composant logiciel qui détermine, au moment de son exécution, la prochaine tâche à exécuter.

L'invention supporte également les transitions de type "retour à la tâche précédente" selon lequel la prochaine tâche à exécuter correspond à la dernière tâche réalisée.

L'invention supporte également les transitions de type "conditionnel", ces transitions comportant un ensemble de conditions qui sont évaluées séquentiellement, ces conditions pouvant notamment être constituées par un événement, un test sur les tâches précédentes ou une condition quelconque.

L'invention s'applique à tous les types de services multimodaux interactifs, quelle que soit la complexité de mise en œuvre d'une modalité.

Par exemple, pour une modalité vocale, les services couverts par l'invention peuvent être en langage naturel, en détection de mots clés

(multi word spotting), en mots enrobés ou isolés, mais aussi des services utilisant des interactions avec les touches du téléphone mobile 12, par exemple DTMF.

Pour les modalités visuelles, il peut s'agir d'une application Web simple sur un téléviseur.

L'invention supporte également des modalités complexes, du type d'un terminal mobile qui comporte des capacités visuelles et vocales.

L'invention supporte également d'autres types de modalités, à savoir notamment un diffuseur d'odeurs, des capteurs sensoriels de réalité virtuelle ou un bras haptique.

An nexe A

< Service name= "Orange">

< !-- Tâche connexion --> <Task name= "Connexion">

< Description> L'utilisateur se connecte en s'identifiant et en s'authentifiant</Description>

< Transition type= "STATI C"> < Description>

La transition est déclenchée dès que l'utilisateur a fourni son identifiant et son mot de passe </Description> < Destination>Accueik/Destination> </Transition> </Task>

< !-- Tâche accueil --> <Task name= "Accueil">

< Description> Présenter à l'utilisateur son espace personnek Description>

</Task>

</ Servi ce>

An nexe B

< !-- Tâche connexion --> <Task name= "Connexion">

< Description> L'utilisateur se connecte en s'identifiant et en s'authentifiant</Description>

< !-- Sous-tâche identification --> <Task name= " Identification'^

< Description> L'utilisateur saisi son numéro de téléphone< / Description>

< Transition type= "STATI C>

< Description> La transition est déclenchée que l'utilisateur a fourni un numéro de téléphone</Description> < Destination>Authentification</Destination> </Transition> </Task>

< !-- Sous-tâche authentification --> <Task name= "Authentification">

< Description>

L'utilisateur saisi son mot de passe

</Description>

< Transition type= "STATI C">

< Description>

La transition est déclenchée que l'utilisateur a fourni un mot de passe valide

</Description>

< Destination>Accueik/Destination> </Transition> </Task> </Task>

An nexe C

<Task name= "Taski " generalMeeting= "true">

< !-- Cest un général meeting. Une tâche de type generalMeeting n'a pas d'élément spécifique lié au type generalMeeting. L'arrivée d'une modalité dans cette tâche déclenche l'appel de toutes les autres modalités vers cette tâche->

< Description> Description de la tâche à réaliser. </Description>

< Transition type= "STATI C">

< Description> Description de la transition statique sous forme littérale< / Description>

< Destination>TaskN</Destination> </Transition> </Task>

An nexe D

<Task name= "Taski " threshold= "true">

< !-- L'élément description ci-dessous correspond à la description de la tâche. -->

< Description> Description de la tâche à réaliser. </Description>

< !-- Une tâche de type threshold contient obligatoirement un élément Threshold indiquant le nombre maximum de fois où la tâche doit être exécutée. -->

<Threshold name= "TaskThreshold" value= "1 ">

< Description> La tâche n'est réalisée qu'une fois. </Description> </Threshold>

< Transition type= "STATI C">

< Description> Description de la transition statique sous forme littérale< / Description> < Destination>TaskN</Destination>

</Transition> </Task>

An nexe E

<Task name= "Taski " rendezVous= "true">

< !-- L'élément description ci-dessous correspond à la description de la tâche. -->

< Description> Description de la tâche à réaliser. </Description>

< !-- Une tâche de type rendezVous contient obligatoirement un élément RendezVous. Cet élément contient un attribut wait pouvant prendre la valeur [afterProceeding| beforeProceeding] suivant que l'attente des autres canaux doit être réalisée après ou avant la réalisation de la tâche -->

< RendezVous name= "RDV1 " wait= "afterProceeding">

< !-- La description est plus qu'informative, elle permet de préciser les canaux attendus pour le rendez-vous. -->

< Description> Description du rendez-vous</Description> < Condition> Description de la condition à remplir pour le rendez- vous</Condition>

</RendezVous>

< Transition type= "STATI C">

< Description> Description de la transition statique sous forme littérale< / Description> < Destination>TaskN</Destination>

</Transition> </Task>

An nexe F

< Event name= "Evenement">

< !- L'élément description permet de décrire l'action à réaliser.

I l peut n'avoir qu'un caractère informatif ou bien être utile à l'exécution du service -->

< Description> Description de l'événement sous forme littérale< / Description>

< !-- Un élément transition peut être utilisé à ce niveau si l'événement doit provoquer un changement de tâche -->

< !-- Les transitions peuvent être de type STATI C, DYNAMI C, CONDI Tl ONAL ou PREVI OUS_TASK ->

< Transition type= "STATI C">

< Description> Description de la transition statique sous forme littérale< / Description>

< Destination>TaskN</Destination> </Transition> </Event>