WO2007141446A1 - Système de gestion d'un service interactif multimodal - Google Patents
Système de gestion d'un service interactif multimodal Download PDFInfo
- Publication number
- WO2007141446A1 WO2007141446A1 PCT/FR2007/051357 FR2007051357W WO2007141446A1 WO 2007141446 A1 WO2007141446 A1 WO 2007141446A1 FR 2007051357 W FR2007051357 W FR 2007051357W WO 2007141446 A1 WO2007141446 A1 WO 2007141446A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- task
- execution
- module
- description
- functional description
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
Definitions
- Multimodal interactive service management system Multimodal interactive service management system
- the invention lies in the field of multimodal interactive services.
- multimodality in a general way, we will define "multimodality" as the use of several modalities in an alternating or parallel way, in a combined or redundant way.
- a modality regardless of input or output, is defined by:
- the invention applies to interactive services accessible by at least one of these methods:
- I P I nternet Protocol
- interactive multimodal services may be based on the use of one or more presentation formalisms.
- HTML HyperText Markup Language
- XML Extended Markup Language
- SALT Speech Application Language Language
- GDialogXML metalanguage is also known for defining multimodal and / or multilanguage applications. This metalanguage comes from the European Gemini project (2002-2004), one of whose objectives was to develop tools to quickly create dialogue systems.
- the GDialogXML metalanguage is based on a formalism based on the notion of dialogue state.
- I l allows several levels of modalization, including a functional level (the State Flow Model), this level to define, in a very general way, the main steps of a multimodal interactive service.
- a functional level the State Flow Model
- the invention relates to a system for managing an interactive service, this service being accessible by a plurality of modalities.
- This system comprises a synchronization module capable of interpreting a functional description of a plurality of tasks that may be executed during an implementation of this service. It also includes, for each modality, an execution module able to:
- the synchronization module included in the system receives operational data relating to the execution of the tasks by the various methods.
- These operational data are for example constituted by an identifier of the task being executed by a modality, and by a state of execution of this task.
- the synchronization module has, thanks to these operational data, a complete vision of the progress of the service by each of the different modalities.
- This operational data is used by the execution module to maintain consistency and synchronization between the different modalities.
- the invention also relates, in a second aspect, a synchronization module of a plurality of access modes to an interactive service.
- This synchronization module comprises:
- At least one execution module included in the management system according to the invention is able to receive such a command and to execute the task whose identifier is included in said command.
- the interactive multimodal service is described at a functional level, regardless of the nature of the different modalities, in a so-called “functional description” file.
- This file advantageously allows to design an interactive multimodal service in a generic way by a set of tasks and transitions between these tasks.
- the parts of the functional description of service that are not sufficiently generic can be deported in software components referenced in the functional description file.
- the functional description file is in XML format.
- the aforementioned software components may be servlets.
- each modality is associated with an execution module able to communicate with the aforementioned synchronization module.
- Each of these execution modules is capable of interpreting a technical description specific to this modality.
- this technical description is described in a file called "technical description file”, in a format specific to each modality. This file contains some or all of the tasks described in the functional description file.
- the synchronization module has the main function of ensuring the synchronization between the execution of the tasks by the different modalities.
- each execution module of a modality is able to send to the synchronization module operational data relating to a task executed by this execution module, and to receive, from this synchronization module, the identifier of the next task that must be implemented by this runtime.
- the multimodal interactive service management system in accordance with the invention thus makes it possible to synchronize the different modalities at certain points of the interactive dialogue, while leaving a great freedom for each of these modalities in the execution of the different tasks, all in a coherent environment described in the functional description file.
- a graphic modality can group an identification task and an authentication task, these two tasks preferably having to be separated in a voice mode.
- the functional description therefore does not prejudge the implementation in a modality.
- the formalism, in the functional description file, remains at a functional level and does not take into account the technical capabilities of implementation by a given modality.
- the functional description of the service relies on tasks, transitions between these tasks, and events.
- the functional description file gives, for each task, a literal description thereof; this description can be seen as a comment of the task.
- the functional description file makes it possible to associate predetermined types with at least certain tasks.
- the type "general meeting” is defined.
- a “general gathering” task is different from the others in that entering a modality into a task of this type forces the other modalities to join this task.
- the synchronization module is able to send, to each of the execution modules, a command comprising the identifier of a task of general assembly type to be executed, since it has received operational data representative of the fact that this task was active in at least one of the execution modules.
- the "execution threshold" type is defined.
- An "execution threshold” task is a task associated with a threshold whose value represents the number of times that this task must be performed by one or more of the active modalities, regardless of the types of modalities. If the threshold is reached, the modality performs the following task.
- the synchronization module is able to send, to each of the execution modules, a command comprising the identifier of a next task to be executed as soon as it has received messages.
- operational data representative of the fact that a task of "execution threshold” type had been executed a number of times at least equal to the threshold mentioned above by the execution modules taken as a whole.
- the task of broadcasting these messages may advantageously be a task of the "execution threshold" type. Thus, it diffuses a predetermined number of times (set by the threshold) the advertising message to a user who would access the service by different modalities.
- the functional description associates, with at least one so-called "rendezvous task", a deblocking condition linked to the reception, by the execution module, of at least one operational datum representative of a predetermined execution state of this rendezvous task by at least one of the execution modules, the synchronization module being able to: wait for the detection of the realization of said unlocking condition or a higher priority event for sending, to at least one execution module, a command comprising the identifier of said appointment task.
- a modality arrives in an "appointment" type task, it remains in the state of completion of this task until the rendezvous condition is fulfilled, or a more priority event occurs. sets off.
- the unblocking condition is linked to the reception, by the execution module, of at least one operational datum representative of an execution state predetermined one of at least one active task in one of the execution modules.
- the functional description makes it possible to specify at least one event outside said active tasks in said execution modules, and the synchronization module is able to send at least one execution module. , on detection of the realization of this event, a command representative of an action that must execute said execution module.
- the functional description makes it possible to specify events whose occurrence, or rather the detection of the occurrence by the synchronization module, triggers a particular action.
- Events are defined for a given task or for all service tasks. They are trigger conditions for actions related to the detection, by the synchronization module, of an event external to the active tasks in the various execution modules of the modalities.
- the functional description file comprises a so-called "compound” task, namely a task comprising at least two sub-tasks.
- the description of this compound task in the technical description file specific to at least one of said execution modules is limited to the technical description of at least some of these sub-tasks.
- the operational data sent to the synchronization module by this execution module are constituted by operational data of each of the sub-tasks specific to this module, obtained as and when they are executed.
- the invention also relates to a method for synchronizing a plurality of access modalities to an interactive service.
- This method uses a functional description of a plurality of tasks that may be executed during the implementation of this service.
- This process comprises: a step of receiving operational data relating to a task executed by an execution module associated with a modality;
- the different steps of the synchronization method are determined by instructions of computer programs.
- the invention also relates to a computer program on an information medium, this program being capable of being implemented in a synchronization module or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a synchronization method as described above.
- This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
- the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
- the information carrier may be any entity or device capable of storing the program.
- the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
- the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
- the program according to the invention can in particular be downloaded to a network of the Internet type.
- the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
- FIG. 1 shows a management system according to the invention in a particular embodiment of the invention
- FIG. 2 represents, in flowchart form, the main steps of a management method according to the invention
- FIGS. 3 to 5 represent, in chronogram form, synchronization mechanisms that can be used in the invention.
- Appendices A to F are functional description XML files according to the invention.
- Fig 1 represents a management system 10 according to the invention.
- the management system 10 is a server capable of communicating with a computer 11 and with a cellular telephone 12 via telecommunications networks not shown here.
- This management system 10 makes it possible to provide an interactive multimodal service whose functional description is given in the XML file of Annex A. From a functional point of view, it is understood from reading this appendix that the service has two main tasks, named respectively "Connection” and "Home”.
- the task "Connection” is a task by which the user connects by identifying and authenticating himself. This task is followed by the "Home” task in which the user is presented with his personal space.
- the "Connection” task in order to specify the transition between the "Connection” task and the "Home” task, a field delimited by the ⁇ Destination> and ⁇ / Destination> tags is used.
- the "Connection” task is a complex task that has two sub-tasks "Identification” and "Authentication”.
- Appendix B is particularly useful in the context of a voice dialogue, because a voice mode is difficult to enter several information simultaneously, in this case a user identifier and a password.
- the implementation, by the various modalities, of the tasks described functionally in the file 200 is very free.
- the voice dialogue of the voice modality is broken down into as many subtasks as the functional description allows.
- the visual modality only refers to the "Connection" task, the other two sub-tasks being performed simultaneously.
- the interactive service management system 10 comprises a synchronization module 20 capable of interpreting the functional description file 200 whose content is that of the XML file of Appendix B.
- the user can access the multimodal interactive service by the personal computer 11 and the mobile phone 12, which defines two access modes, namely a graphic mode for the personal computer 11 and a voice mode for the mobile phone 12.
- the management system 10 also comprises two execution modules 31 and 32 associated respectively with the graphic mode and the voice mode.
- Each of these execution modules 31, 32 is capable of interpreting a technical description file 310, 320 specific to the modality with which it is associated.
- the functional description file 200 is in XML format and the Java language is used in an N-TI ERS environment for the module. synchronization 20 and for the execution modules 31, 32 of the different modes.
- the functional description file 200 makes it possible to define the interactive multimodal service functionally, legibly and generically, as well as synchronization elements that are implemented in one or more of the modalities.
- synchronization elements may in particular be constituted by events or tasks of "rendezvous", “general meeting” or “execution threshold” type.
- each of the modes implements in the technical description files 310, 320 these synchronization points in the form of an exchange of HTTP requests / responses with the synchronization module.
- these synchronization points can be implemented as function calls.
- the synchronization module 20 comprises a processor 21, a random access memory 22, a read-only memory 23, and means 24 for communication with the execution modules 31 and 32 of each of the modalities.
- the read-only memory 23 stores a computer program comprising instructions for executing the steps of a synchronization method according to the invention.
- This validation generates a request R1 sent by the personal computer 1 1 to the execution engine 31 associated with the graphic mode.
- the execution module 31 checks, in the body of the task "Connection" of the technical description file, that the entry is valid.
- This synchronization request R2 comprises the identifier of the active task ("Connection" task) and a representative execution state because this connection task has terminated normally.
- This synchronization request R2 is received by the communication means 20 of the synchronization module 20 during a step E10 of the synchronization method.
- This reception step E10 is followed by a step E20 during which the synchronization module 20 selects the next task to be executed by the execution module 31 associated with the graphic modality.
- This selection uses on the one hand the functional description file 200 and on the other hand the status data received from the other modalities.
- the 200 specifies that, when status data representative of access to a new game level are received by the synchronization module 20, all the modalities must execute the task associated with this new level.
- the task associated with this new step is a so-called "general meeting" task within the meaning of the invention.
- the synchronization module 20 selects, during a step E20, the task of executing this new step. Then, during a step E30, the synchronization module 20 sends, to the execution engine 31 of the graphic mode, a command R3 comprising the identifier of the task of execution of the new step.
- This command R3 is processed by the execution engine 31 of the voice modality and transmitted, as a response R4, to the personal computer 11.
- the execution module 20 then sends a command to each of the execution engines associated with all the modalities, so that each of these execution engines executes the general gathering task RG as specified in the technical description file. specific to this engine.
- each of the execution engines executes a task of its own, for example the respective tasks D, E and Z.
- a task of the "execution threshold" type For example, the use of a task of the "execution threshold" type.
- this task named "Taski” is associated with a value threshold 1.
- the modality M1 switches from task A to a task S of type "execution threshold”, then at time t4, this task S to task B.
- the category M2 therefore switches directly to task C.
- the modality M3 is not concerned.
- FIG. 5 represents an exemplary embodiment in which the unblocking condition is linked to the fact that the modalities M1 and M2 must synchronize at the level of an RV task of "rendezvous" type.
- the modality M2 switches, at time t2, in the "rendezvous" task, it remains in this state until the task M1 switches to it, at time t3.
- the modality M3 is not concerned with the appointment.
- Appendix F gives an example of a functional description file specifying an event (named "Event") within the meaning of the invention. According to the invention, an event can occur at any time during the execution of a task. I l will be the subject of a treatment or not according to whether it appears or not in the file 200 of functional description. In the previously described examples, the tag is used
- these transitions can be of different types.
- the static type transitions will be considered according to which the name of the next task to be executed in the functional description file is explicitly filled in.
- the invention also supports "dynamic" type transitions for which a software component is executed which determines, at the time of its execution, the next task to be executed.
- the invention also supports "return to the previous task” type transitions according to which the next task to be performed corresponds to the last task performed.
- the invention also supports transitions of the "conditional" type, these transitions comprising a set of conditions that are evaluated sequentially, these conditions possibly being constituted by an event, a test on the preceding tasks or any condition.
- the invention applies to all types of interactive multimodal services, regardless of the complexity of implementing a modality.
- the services covered by the invention may be in natural language, in keyword detection
- the invention also supports complex terms, of the type of a mobile terminal that includes visual and vocal capabilities.
- the invention also supports other types of modalities, namely in particular an odor diffuser, sensory sensors of virtual reality or a haptic arm.
- the transition is triggered as soon as the user has provided his username and password ⁇ / Description> ⁇ Destination> Accueik / Destination> ⁇ / Transition> ⁇ / Task>
- the user enters his password
- the transition is triggered that the user has provided a valid password
- a generalMeeting task has no specific element related to the generalMeeting type. The arrival of a modality in this task triggers the call of all the other modalities towards this task->
- a threshold task must contain a Threshold element indicating the maximum number of times the task should be executed. ->
- a rendezvous task must contain an Appointment element.
- This element contains a wait attribute that can be set to [afterProceeding
- the description element is used to describe the action to be performed.
- a transition element can be used at this level if the event must cause a change of task ->
- the transitions can be STATI C, DYNAMI C, CONDI Tl ONAL or PREVI OUS_TASK ->
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Stored Programmes (AREA)
Abstract
Ce système de gestion d'un service interactif, service accessible par une pluralité de modalités, comporte un module (20) de synchronisation apte à interpréter une description fonctionnelle (200) d'une pluralité de tâches susceptibles d'être exécutées au cours d'une mise en oeuvre dudit service. Il comporte également, pour chacune des modalités précitées, un module d'exécution (31) apte à : - interpréter une description technique (310) d'au moins une de ces tâches, cette description technique étant spécifique à la modalité; et - envoyer, au module de synchronisation (20), des données opérationnelles relatives à une tâche exécutée par le module d'exécution (31).
Description
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>
Claims
1. Système (10) de gestion d'un service interactif, ce service étant accessible par une pluralité de modalités (M1 , M2, M3), ce système (10) comportant un module (20) de synchronisation apte à interpréter (E20) une description fonctionnelle (200) d'une pluralité de tâches susceptibles d'être exécutées au cours d'une mise en œuvre dudit service, et, pour chacune (M1 ) desdites modalités, un module d'exécution (31 ) apte à :
- interpréter une description technique (310) d'au moins une desdites tâches, cette description technique étant spécifique à ladite modalité (M1 ) ; et - envoyer, audit module de synchronisation (20), des données opérationnelles relatives à une tâche exécutée par ledit module d'exécution (31 ).
2. Système de gestion selon la revendication 1 caractérisé en ce que ledit module de synchronisation (20) est apte à:
- sélectionner (E20) une tâche, à partir de ladite description fonctionnelle (200) et de données opérationnelles reçues en provenance d'au moins un desdits modules d'exécution (31 , 32), et
- envoyer (E30), à au moins un desdits modules d'exécution (31 ), une commande (R3) comportant un identifiant de la tâche ainsi sélectionnée.
3. Système de gestion selon la revendication 2 caractérisé en ce qu'il comporte au moins un module d'exécution (31 ) apte à recevoir (E30) ladite commande (R3) en provenance dudit module de synchronisation (20) et à exécuter la tâche dont l'identifiant est compris dans ladite commande (R3).
4. Système de gestion selon la revendication 2 ou 3, caractérisé en ce que ledit module de synchronisation (200) est apte à envoyer (E30), à chacun desdites modules d'exécution (31 , 32), une commande (R3) comportant l'identifiant d'une tâche à exécuter, dès lors qu'il a reçu des données opérationnelles représentatives du fait que cette tâche est active dans au moins un desdits modules d'exécution (31 ).
5. Système de gestion selon l'une quelconque des revendications 2 à 4, caractérisé en ce que ladite description fonctionnelle
(200) comporte au moins un seuil associé à une première tâche, et en ce que ledit module de synchronisation (20) est apte à envoyer (E30), à chacun desdites modules d'exécution (31 , 32), une commande (R3) comportant l'identifiant d'une deuxième tâche, dès lors qu'il a reçu des données opérationnelles représentatives du fait que ladite première tâche a été exécutée un nombre de fois au moins égal audit seuil par lesdits modules d'exécution (31 , 32) pris dans leur ensemble.
6. Système de gestion selon l'une quelconque des revendications 2 à 5 caractérisé en ce que :
- ladite description fonctionnelle (200) associe, à au moins une tâche dite « tâche de rendez-vous », une condition de déblocage liée à la réception (E10), par ledit module d'exécution (200), d'au moins une donnée opérationnelle représentative d'un état d'exécution prédéterminé de ladite tâche de rendez-vous par au moins un desdits modules d'exécution (31 ) ; et en ce que ledit module de synchronisation (20) est apte à :
- attendre la détection (E20) de la réalisation de ladite condition de déblocage ou d'un événement plus prioritaire pour envoyer (EΞ30), à au moins un desdits modules d'exécution (31 ), une commande (R3) comportant l'identifiant de la tâche suivante à réaliser.
7. Système de gestion selon l'une quelconque des revendications 2 à 6 caractérisé en ce que : - ladite description fonctionnelle (200) spécifie un événement extérieur auxdites tâches actives dans lesdits modules d'exécution (31 , 32) ; et en ce que ledit module de synchronisation (20) est apte à :
- envoyer (EΞ30), à au moins un desdits modules d'exécution (31 ), sur détection (EΞ20) de la réalisation dudit événement, une commande (R3) représentative d'une action que doit exécuter ledit module d'exécution.
8. Système de gestion selon l'une quelconque des revendications 1 à 7, caractérisé en ce que :
- ladite description fonctionnelle (200) décrit une tâche composée d'au moins deux sous- tâches ; en ce que : - la description technique (310) de ladite tâche composée spécifique à au moins un desdits modules d'exécution (31 ) se limite à la description technique d'au moins certaines de ces sous-tâches ; et en ce que :
- les données opérationnelles envoyées (E10) audit module de synchronisation (20) par ce module d'exécution (31 ) sont constituées par des données opérationnelles de chacune des sous-tâches spécifiques à ce module (31 ), obtenues au fur et à mesure de leur exécution.
9. Système de gestion selon l'une quelconque des revendications 1 à 7, dans ladite description fonctionnelle (200) est formalisée dans un fichier au format XML, ce fichier comportant au moins un lien vers un composant logiciel apte à effectuer ladite sélection (EΞ30).
10. Module de synchronisation (20) d'une pluralité de modalités (M1 , M2, M3) d'accès à un service interactif comportant : - des moyens (21 ) d'interprétation d'une description fonctionnelle (200) d'une pluralité de tâches susceptibles d'être exécutées dans une mise en œuvre de ce service ;
- des moyens (24) de réception de données opérationnelles relatives à une tâche exécutée par un module d'exécution (31 ) associé à une modalité (M1 ) ;
- des moyens (21 ) pour sélectionner une tâche, à partir de données opérationnelles reçues en provenance d'au moins un module d'exécution (31 , 32) et de ladite description fonctionnelle (200) ; et
- des moyens (24) d'envoi, à au moins un module d'exécution (31 ), d'une commande (R3) comportant un identifiant de la tâche ainsi sélectionnée.
11. Procédé de synchronisation d'une pluralité de modalités d'accès (M1 , M2, M3) à un service interactif, ce procédé étant caractérisé en ce qu'il utilise (E20) une description fonctionnelle (200) d'une pluralité de tâches susceptibles d'être exécutées au cours de la mise en œuvre de ce service, et en ce qu'il comporte : - une étape (E10) de réception de données opérationnelles relatives à une tâche exécutée par un module d'exécution (31 ) associé à une modalité (M1 ) ;
- une étape (E20) 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
(31 , 32) et de ladite description fonctionnelle (200) ; et
- une étape (EΞ30) d'envoi, à au moins un module d'exécution (31 ), d'une commande (R3) comportant un identifiant de la tâche ainsi sélectionnée.
12. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de synchronisation selon la revendication 1 1 lorsque ledit programme est exécuté par un ordinateur (20).
13. Support d'enregistrement (23) lisible par un ordinateur (20) sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de synchronisation selon la revendication 1 1.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0652012 | 2006-06-02 | ||
| FR0652012 | 2006-06-02 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2007141446A1 true WO2007141446A1 (fr) | 2007-12-13 |
Family
ID=37625323
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/FR2007/051357 WO2007141446A1 (fr) | 2006-06-02 | 2007-05-30 | Système de gestion d'un service interactif multimodal |
Country Status (1)
| Country | Link |
|---|---|
| WO (1) | WO2007141446A1 (fr) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE202012010986U1 (de) | 2012-11-15 | 2013-03-18 | Foseco International Ltd. | Speisersystem |
| DE202013102133U1 (de) | 2013-04-16 | 2013-05-27 | Foseco International Ltd. | Speiserelement |
| DE202016104786U1 (de) | 2015-09-02 | 2016-11-21 | Foseco International Ltd. | Speiserelement |
| DE202016104787U1 (de) | 2015-09-02 | 2016-11-28 | Foseco International Ltd. | Speisersystem |
| DE202017102321U1 (de) | 2017-03-31 | 2017-07-14 | Foseco International Limited | Speiserelement |
| US9968993B2 (en) | 2014-09-02 | 2018-05-15 | Foseco International Limited | Feeder system |
| US10286445B2 (en) | 2015-09-02 | 2019-05-14 | Foseco International Limited | Feeder system |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003073198A2 (fr) * | 2002-02-27 | 2003-09-04 | Motorola Inc. | Systeme et procede de communication multimodale concurrente |
-
2007
- 2007-05-30 WO PCT/FR2007/051357 patent/WO2007141446A1/fr active Application Filing
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2003073198A2 (fr) * | 2002-02-27 | 2003-09-04 | Motorola Inc. | Systeme et procede de communication multimodale concurrente |
Non-Patent Citations (2)
| Title |
|---|
| S. W. HAMERICH ET AL.: "The GEMINI Platform: Semi-Automatic Generation of Dialogue Applications", PROCEEDINGS OF THE INTERSPEECH-2004 ICSLP, vol. IV, 4 October 2004 (2004-10-04), pages 2629 - 2632, XP002416545, Retrieved from the Internet <URL:http://lorien.die.upm.es/~lfdharo/Papers/GEMINI_ICSLP2004_ALL.pdf> [retrieved on 20070124] * |
| STEFAN W. HAMERICH ET AL.: ""XML-Based Dialogue Descriptions in the GEMINI project", PROCEEDINGS OF THE BERLINER XML-TAGE 2003, 13 October 2003 (2003-10-13), pages 404 - 412, XP002416544, Retrieved from the Internet <URL:http://www-gth.die.upm.es/projects/gemini/92.pdf> [retrieved on 20070124] * |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE202012010986U1 (de) | 2012-11-15 | 2013-03-18 | Foseco International Ltd. | Speisersystem |
| DE202013102133U1 (de) | 2013-04-16 | 2013-05-27 | Foseco International Ltd. | Speiserelement |
| EP2792432A1 (fr) | 2013-04-16 | 2014-10-22 | Foseco International Limited | Élément d'alimentation |
| US9968993B2 (en) | 2014-09-02 | 2018-05-15 | Foseco International Limited | Feeder system |
| DE202016104786U1 (de) | 2015-09-02 | 2016-11-21 | Foseco International Ltd. | Speiserelement |
| DE202016104787U1 (de) | 2015-09-02 | 2016-11-28 | Foseco International Ltd. | Speisersystem |
| US10022783B2 (en) | 2015-09-02 | 2018-07-17 | Foseco International Limited | Feeder system |
| US10286445B2 (en) | 2015-09-02 | 2019-05-14 | Foseco International Limited | Feeder system |
| US10500634B2 (en) | 2015-09-02 | 2019-12-10 | Foseco International Limited | Feeder system |
| US10639706B2 (en) | 2015-09-02 | 2020-05-05 | Foseco International Limited | Feeder system |
| DE202017102321U1 (de) | 2017-03-31 | 2017-07-14 | Foseco International Limited | Speiserelement |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Carnell et al. | Spring microservices in action | |
| EP2336885B1 (fr) | Procédé pour afficher dans un navigateur web le rendu produit par une application | |
| WO2007141446A1 (fr) | Système de gestion d'un service interactif multimodal | |
| FR2814881A1 (fr) | Procede d'optimisation, par un element d'architecture de reseau, de la consultation de donnees | |
| EP0843259A1 (fr) | Système de gestion et de traitement de transactions distribuées d'objets et procédé d'objets et procédé mis en oeuvre par ledit système | |
| FR2814828A1 (fr) | Procede d'optimisation, par une terminal, de la consultation de donnees | |
| EP2689559B1 (fr) | Procédé et dispositif de configuration sur la base de règles de gestion | |
| US20150113504A1 (en) | Virtual hybrid application | |
| EP2169569A1 (fr) | Procédé et système de communication entre applications web distinctes | |
| EP2187321B1 (fr) | Procédé et dispositif d'édition d'un objet représenté dans une page web | |
| EP2633683B1 (fr) | Exécution déportée d'une application logicielle au sein d'un réseau | |
| EP2633440B1 (fr) | Indexation et execution d'applications logicielles dans un reseau | |
| EP2223215B1 (fr) | Procédé de contrôle d'au moins un processus applicatif et produit programme d'ordinateur correspondant | |
| FR2990667A1 (fr) | Procede de gestion d'une installation electronique d'un vehicule automobile et installation electronique ainsi mise en oeuvre | |
| EP2171577A1 (fr) | Systeme et procede de generation automatique d'une application logicielle | |
| WO2007010139A2 (fr) | Procede et dispositif d'interaction entre des applications informatiques et un site distant | |
| CN103186659A (zh) | 基于社区的网络服务的用户界面注释 | |
| EP2271051B1 (fr) | Procédé d'exécution d'un service applicatif dans un environnement web | |
| EP2561454A1 (fr) | Système informatique de partage et procédé correspondant | |
| FR2923036A1 (fr) | Procede de composition automatique de services web et systeme informatique pour la mise en oeuvre d'un tel procede | |
| Balme et al. | Ethylene: composants dynamiques pour la mise en œuvre d'IHM plastiques en informatique ambiante | |
| WO2005036850A1 (fr) | Dispositif fournisseur de service a interface vocale pour terminaux de telecommunication, et procede de fourniture de service correspondant | |
| FR2947934A1 (fr) | Procede de tracabilite et d'imputabilite dynamiques des echanges dans un environnement ouvert de type internet | |
| FR2829656A1 (fr) | Procede d'annotation de documents informatiques, et systeme associe | |
| Dillon et al. | Modeling the dynamics of web-based service and resource-oriented digital ecosystems |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 07766124 Country of ref document: EP Kind code of ref document: A1 |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 07766124 Country of ref document: EP Kind code of ref document: A1 |