FR3003966A1 - Procede d'adaptation dynamique d'un environnement logiciel execute a partir d'un terminal de communication d'un utilisateur, au cours d'une communication entre l'utilisateur et au moins un interlocuteur. - Google Patents

Abstract

Un procédé d'adaptation dynamique d'un environnement logiciel exécuté à partir d'un terminal de communication d'un utilisateur, au cours d'une communication entre l'utilisateur et au moins un interlocuteur, au travers d'un réseau de communication, est remarquable en ce qu'il comporte : a) - l'obtention (E1, E2) en temps réel de données textuelles à partir d'un flux de conversation temps réel échangé entre l'utilisateur et l'interlocuteur ; b) - la détermination (E3) d'un contexte applicatif courant de l'environnement logiciel, relatif à l'obtention des données textuelles ; c) - la recherche (E3) d'au moins un mot-clé dans les données textuelles, au moins un mot-clé à rechercher étant déterminé en fonction du contexte applicatif courant ; d) - la détermination (E4), à partir d'au moins un mot-clé trouvé dans les données textuelles, d'au moins une fonctionnalité de service pertinente à exécuter dans le contexte applicatif courant de l'environnement logiciel.

Description

L'invention concerne l'adaptation dynamique d'un environnement logiciel exécuté à partir d'un terminal de communication d'un utilisateur, au cours d'une communication entre cet utilisateur et au moins un interlocuteur, au travers d'un réseau de communication. En particulier, l'invention vise des applications de communication entre des clients et une plateforme de gestion de la relation client, en anglais Customer Relationship Management (CRM). Dans ce type d'applications, un client peut être en communication avec un agent ou téléconseiller, selon différents modes de communication : téléphone, visioconférence, messages électroniques (emails), messagerie instantanée (chat, en anglais). Parallèlement à la communication entre le client et l'agent, ce dernier accède via un terminal de communication tel qu'un ordinateur personnel (PC) à une plateforme logicielle réalisant un environnement applicatif que l'agent utilise pour répondre aux requêtes de son interlocuteur (client). Il peut s'agir par exemple d'une plateforme de vente à distance, ou d'une plateforme de support en ligne dédiée à des services de télécommunications ou centres d'appels. Dans ce type d'applications, il est connu que l'agent ou téléconseiller consulte en même temps qu'il communique par messages (SMS par exemple) ou par communication vocale avec son interlocuteur, un outil d'aide destiné à lui apporter une aide pour déterminer la réponse la plus adaptée aux questions ou requêtes transmises par le client. Ce type d'outil d'aide parfois désigné par système ou outil de "scripting", indique classiquement au téléconseiller, une liste de réponses possibles en fonction d'une étape courante d'un processus relationnel, désigné parfois par "processus métier" en cours d'exécution entre le téléconseiller et son interlocuteur. Par exemple, si l'étape en cours d'un processus de vente est l'étape livraison, le téléconseiller pourra se voir proposer une liste (script) prédéfinie de réponses possibles du client - par exemple "livraison et installation à domicile", "livraison au point vente", "ne sait pas", "autre" -, et en fonction de la réponse effective du client, l'agent devra cliquer sur la réponse correspondante de la liste pour être orienté vers une nouvelle étape du processus de vente.

Dans ce type d'applications (CRM), en plus de l'aide à la décision procurée par les outils de scripting susmentionnés, il existe des techniques permettant de fournir au téléconseiller une aide contextuelle par la proposition de lancement d'applications en fonction d'un contenu textuel d'un message reçu par le téléconseiller. Le document brevet US 2012/0263292 Al illustre une telle technique d'aide contextuelle destinée à une suite logicielle utilisée par un agent d'un service client (Customer Service Representative). Cependant, les techniques connues à ce jour d'adaptation dynamique d'un environnement logiciel en fonction de messages échangés entre un téléconseiller et un client ne s'appliquent pas à des communications temps réel entre les deux interlocuteurs, telles que des communications vocales (téléphoniques ou par visioconférence) ou par messagerie instantanée (chat). La présente invention vise notamment à améliorer la situation exposée ci-dessus, en proposant selon un premier aspect, un procédé d'adaptation dynamique d'un environnement logiciel exécuté à partir d'un terminal de communication d'un utilisateur, au cours d'une communication entre l'utilisateur et au moins un interlocuteur, au travers d'un réseau de communication. Ce procédé comporte : a) - l'obtention en temps réel de données textuelles à partir d'un flux de conversation temps réel échangé entre l'utilisateur et l'interlocuteur ; b) - la détermination d'un contexte applicatif courant de l'environnement logiciel, relatif à l'obtention de ces données textuelles ; c) - la recherche d'au moins un mot-clé dans les données textuelles, le ou les mots-clés à rechercher étant déterminés en fonction du contexte applicatif courant ; d) - la détermination, à partir d'au moins un mot-clé trouvé dans les données textuelles, d'au moins une fonctionnalité de service pertinente à exécuter dans le contexte applicatif courant de l'environnement logiciel. Ainsi, selon l'invention, c'est l'obtention en temps réel des données textuelles issues d'un flux de conversation temps réel (par exemple un flux vocal d'une communication téléphonique) qui déclenche la détermination du contexte applicatif courant, lequel à son tour permet de déterminer les mots-clés à rechercher dans les données textuelles obtenues. Par rapport aux solutions connues à ce jour, ces caractéristiques procurent, de manière générale, d'une part une meilleure réactivité dans la proposition d'applications contextuelles faite à l'utilisateur de l'environnement logiciel ou plateforme de services, et d'autre part, une meilleure adéquation entre les applications ou fonctionnalités de service proposées et le contexte courant d'utilisation de l'environnement logiciel dans le cadre de la communication en cours entre l'utilisateur et son interlocuteur (respectivement un téléconseiller et un client, par exemple) . En particulier, selon un mode de réalisation de l'invention, l'étape b) de détermination d'un contexte applicatif courant inclut : - l'identification d'un processus applicatif en cours d'exécution dans l'environnement logiciel au moment de l'obtention des données textuelles ; et - la détermination d'une liste de services applicatifs susceptibles d'être exécutés au cours du processus applicatif identifié. Ainsi, selon ce mode de réalisation, c'est l'identification du processus en cours d'exécution au moment où les données textuelles, caractéristiques de la communication en cours, ont été obtenues, qui permet d'obtenir une liste d'applications pertinentes relativement au contexte de la communication, puisque de manière classique dans le cadre de relations entre un client et un téléconseiller via une plateforme de services, les échanges sont encadrés par des processus applicatifs prédéfinis, tels que par exemple, des processus désignés par "achat", "vente", "panne matérielle", etc., et que le téléconseiller suit scrupuleusement via l'interface utilisateur affichée sur son terminal de communication. Plus précisément, selon une caractéristique du mode de réalisation précité, chaque service applicatif identifié dans la liste d'applications pertinentes, est défini par une structure de données définissant au moins une fonctionnalité, chaque fonctionnalité étant définie par au moins un type de donnée d'entrée pour l'exécution de la fonctionnalité considérée, et dans lequel à l'étape c) chaque mot-clé recherché dans les données textuelles correspond à un type de donnée d'entrée défini pour une fonctionnalité associée à un service applicatif identifié dans la liste.

Par ailleurs, selon une autre caractéristique, à l'étape c) la recherche d'un mot- clé donné dans les données textuelles est effectuée par un analyseur sémantique spécifique. Plus précisément, selon un exemple de réalisation, un type de données d'entrée d'une fonctionnalité applicative considérée est décrit sous forme d'une étiquette (tag en anglais) sémantique dans un langage de script, par exemple le langage RDF/XML (Resource Description Framework / eXtensible Markup Language). Pour chaque type de donnée d'entrée, un analyseur sémantique est utilisé pour extraire, à partir des données textuelles, des suites de mots conformes au type de donnée d'entrée considéré. Chaque suite de mots trouvée dans les données textuelles, qui est en conformité avec le type de données d'entrée considéré, constitue par conséquent un mot-clé au sens de la présente invention. Selon une caractéristique particulière du procédé selon l'invention, l'étape d) de détermination d'au moins une fonctionnalité de service pertinente, comprend la sélection de chaque service applicatif de la liste pour lequel au moins un type de donnée d'entrée d'une fonctionnalité associée a été trouvé dans les données textuelles. Ainsi, selon ce mode de réalisation, à partir des fonctionnalités de services associées aux services applicatifs identifiés dans la liste d'applications retenues comme étant pertinentes vis-à-vis du processus applicatif en cours, on ne sélectionne, en tant que fonctionnalités de services pertinentes à lancer automatiquement ou après validation par l'utilisateur, que celles dont les caractéristiques d'au moins un type de données d'entrée ont été retrouvées dans des mots ou expressions présents dans les données textuelles issues du flux de conversation.

Selon des applications particulières du procédé selon l'invention : - le flux de conversation temps réel est un flux de communication vocale, et dans ce cas, à l'étape a) susmentionnée, les données textuelles sont obtenues après traitement de reconnaissance vocale appliqué au flux de conversation ; - le flux de conversation temps réel est un flux de messagerie instantanée, et dans ce cas, à l'étape a), les données textuelles sont obtenues après traitement de correction syntaxique appliqué au flux de conversation. Selon un deuxième aspect, la présente invention concerne un dispositif d'adaptation dynamique d'un environnement logiciel exécuté sur un terminal de communication d'un utilisateur, au cours d'une communication entre l'utilisateur et au moins un interlocuteur, au travers d'un réseau de communication. Un tel dispositif selon l'invention comporte : - un module d'obtention de données textuelles, conçu pour obtenir des données textuelles en temps réel à partir d'un flux de conversation temps réel échangé entre l'utilisateur et l'interlocuteur sur le réseau de communication ; - un module de détermination de contexte, conçu pour déterminer un contexte applicatif courant de l'environnement logiciel au moment de l'obtention des données textuelles ; - un module de traitement de données textuelles, conçu pour rechercher dans les données textuelles au moins un mot-clé déterminé en fonction du contexte applicatif courant de l'environnement logiciel ; - un module de détermination de service, conçu pour déterminer, à partir d'au moins un mot-clé trouvé dans les données textuelles, au moins une fonctionnalité de service pertinente à exécuter dans le contexte applicatif courant de l'environnement logiciel. En pratique, les modules précités d'un dispositif selon l'invention peuvent être incorporés dans un seul et même serveur sur le réseau, hébergeant une plateforme de services selon l'invention, ou bien répartis sur diverses entités sur le réseau (serveurs, terminal d'utilisateur, ...). Selon un troisième aspect, l'invention a pour objet un (ou plusieurs) programme(s) d'ordinateur stocké(s) sur un support d'informations, comprenant des instructions de programme dont l'exécution par un processeur provoque la mise en oeuvre d'un procédé d'adaptation dynamique d'un environnement logiciel, tel que brièvement exposé plus haut. En pratique, un tel programme est constitué de plusieurs modules logiciels réalisant chacun tout ou partie des fonctions d'un dispositif selon l'invention tel que succinctement exposé ci-dessus. Ces modules logiciels peuvent être incorporés dans un seul équipement sur un réseau de communication, ou bien répartis sur plusieurs entités matérielles reliées au réseau. Par ailleurs, chaque module logiciel peut utiliser n'importe quel langage de programmation, et comprendre des programmes sous 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 par conséquent un support d'enregistrement d'informations lisible par un ordinateur, et comportant des instructions de programme d'ordinateur. Un tel support d'enregistrement peut être constitué par n'importe quelle entité ou dispositif capable de stocker un tel 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 amovible tel qu'une clé USB ou un moyen d'enregistrement magnétique, tel qu'un disque dur. D'autre part, un module logiciel ou programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Les avantages procurés par un dispositif d'adaptation dynamique d'un environnement logiciel, selon l'invention et d'un programme d'ordinateur selon l'invention, sont identiques à ceux, exposés plus haut, procurés par un procédé d'adaptation dynamique d'un environnement logiciel, selon l'invention, et ne seront par conséquent pas rappelés ici. D'autres caractéristiques et avantages de la présente invention ressortiront de la description détaillée qui suit, laquelle fait référence aux dessins annexés dans lesquels : - la figure 1 illustre de manière simplifiée les étapes principales d'un procédé, selon l'invention, d'adaptation dynamique d'un environnement logiciel exécuté à partir d'un terminal de communication d'un utilisateur ; - la figure 2 illustre de manière plus détaillée les opérations mises en oeuvre au cours de l'étape d'analyse de données textuelles représentée à la figure 1 ; - la figure 3 représente sous forme fonctionnelle une architecture logicielle selon un exemple de mise en oeuvre de l'invention ; et - la figure 4 représente une interface graphique utilisateur d'une plateforme de services dans laquelle la présente invention est mise en oeuvre. La figure 1 illustre de manière simplifiée les étapes principales d'un procédé, selon l'invention, d'adaptation dynamique d'un environnement logiciel exécuté à partir d'un terminal de communication d'un utilisateur. Comme représenté sur la figure 1, à l'étape El, une session de communication est établie entre (au moins) un client et (au moins) un téléconseiller d'une plateforme de services (centre d'appels, par exemple). Il s'agit dans le cadre de la présente invention d'une communication temps réel telle qu'une communication audio seulement (téléphonique) ou vidéo et audio (vidéoconférence). Il peut s'agir également d'une communication par messagerie instantanée que l'on peut qualifier de "temps réel" dans la mesure où les questions du client et les réponses du conseiller se succèdent rapidement.

Une fois la session de communication établie, le flux conversationnel produit par le dialogue entre les deux interlocuteurs subit un prétraitement (étape E2) pour extraire de ce flux les données textuelles les plus pertinentes. Pour réaliser ce prétraitement, on peut utiliser serveur vocal équipé d'un module de reconnaissance vocale. On peut utiliser par exemple la plateforme de serveur vocal AllobizTM commercialisée par la société France Télécom Tm associée avec un module de reconnaissance vocale fourni par la société NuanceTM. Dans le cas où le flux conversationnel initial est un flux textuel issu d'un dialogue par messagerie instantanée (chat), le prétraitement consiste à corriger le texte des erreurs de frappe, transformer un langage de type SMS (langage dont les caractéristiques orthographiques voire grammaticales sont modifiées afin de réduire sa longueur, pour faciliter les échanges en particulier dans le cadre d'échanges de messages courts SMS (short message service)) en langage naturel apte à subir un traitement d'analyse sémantique. En particulier, pour la correction de texte exprimé en langage type SMS, on peut utiliser la plate-forme connue sous l'acronyme "Tilt", développée par la société France Télécom, pour le traitement automatique des langues naturelles. Une fois le flux conversationnel transformé et/ou corrigé pour obtenir des données textuelles (Texte) aptes à subir un traitement d'analyse (E3) notamment sémantique, celles-ci sont fournies en entrée à un module d'analyse inclus dans le dispositif d'adaptation dynamique de l'environnement logiciel, conforme à l'invention, pour réaliser des opérations de : - détermination d'un contexte applicatif courant de l'environnement logiciel, relatif à l'obtention des données textuelles ; - recherche d'au moins un mot-clé dans les données textuelles, chaque mot-clé à rechercher étant déterminé en fonction du contexte applicatif courant ; - détermination, à partir d'au moins un mot-clé trouvé dans les données textuelles, d'au moins une fonctionnalité de service pertinente à exécuter dans le contexte applicatif courant de l'environnement logiciel.

Une fois les opérations susmentionnées effectuées, lors de l'étape E4 qui suit, des suggestions de lancement de services sont présentées au téléconseiller, et/ou des services sont lancés de manière automatique dans l'environnement logiciel. La figure 2 illustre de manière plus détaillée les opérations mises en oeuvre au cours de l'étape d'analyse (E3) de données textuelles représentée à la figure 1. A l'étape E31, un module gestionnaire de processus et d'applications, détermine, suite à l'obtention de données textuelles issues du flux de conversation temps réel, le contexte applicatif courant. A cette fin, un processus applicatif P est déterminé (processus métier) ainsi que l'état EP de ce processus, c'est-à-dire l'étape du processus en cours d'exécution au moment de l'échange conversationnel entre l'interlocuteur et l'utilisateur (téléconseiller) de l'environnement logiciel. Le module gestionnaire de processus a accès également à une liste L1 répertoriant l'ensemble des services applicatifs fournis par l'environnement logiciel. Par exemple, dans une plate-forme de vente, le processus en cours P peut être le processus 'VENTE' et l'étape EP de ce processus, l'étape 'LIVRAISON'. Dans le mode de réalisation exposé, le processus en cours est déterminé par consultation d'un système de Scripting décrivant les différents processus et étapes correspondantes sous la forme d'une structure de type arborescente dans laquelle on identifie les différents processus, et pour chaque processus, les différentes étapes du processus, et enfin pour chaque étape, on identifie les applications pouvant être exécutées. Ainsi, si la liste L1 précitée identifie l'ensemble des services applicatifs pour l'ensemble des processus, à chaque étape d'un processus donné correspond une liste L2 de services applicatifs disponibles (L2 étant un sous-ensemble de L1). A l'étape E31, l'identification d'un processus applicatif en cours d'exécution dans l'environnement logiciel au moment de l'obtention des données textuelles, est donc suivie de la détermination d'une liste L2 de services applicatifs susceptibles d'être exécutés au cours du processus applicatif identifié, cette liste L2 correspondant à l'étape courante du processus identifié.

Cette liste L2 est fournie en entrée à un second module chargé d'extraire (étape E32) la "signature fonctionnelle" (définie plus bas) de chaque service applicatif identifié dans la liste L2. En effet, dans le mode de réalisation décrit, chaque service applicatif (de la liste L1) est défini par une table mémoire dans laquelle sont enregistrés notamment : - un identifiant (id) du service ; - un lien URL (Uniform Resource Locator) pointant vers un index sous forme de table fournissant pour chaque fonctionnalité associée au service applicatif considéré, une description appelée "signature fonctionnelle". Par ailleurs, selon un mode de réalisation, un mode d'exécution peut être codé pour chaque service applicatif ou chaque fonctionnalité de service. Ce mode d'exécution peut être par exemple : - 'automatique' : l'application (service ou fonctionnalité) est automatiquement lancée lorsque l'étape du processus correspondant est atteinte par l'utilisateur (téléconseiller) et devient donc l'état courant du processus ; - 'semi-automatique : l'application est proposée à l'utilisateur lorsque celui-ci atteint l'étape du processus correspondante ; -'semi-automatique anticipé' : l'application est proposée à l'utilisateur lorsque celui-ci atteint l'étape du processus correspondante, avec comme données d'entrée celles détectées (dans les données textuelles) qui sont conformes aux types de données d'entrée définis pour l'application. La Table 1 ci-dessous donne un exemple de signatures fonctionnelles associées à un service de cartographie. Id Un l Type input Icône Verbe 1 http://domaine/maps/locate.php postalAddress domaine/../locate.png Localiser 2 http://domaine/maps/route.php postalAddress domaine/../route.png Calculer l'itinéraire Table 1 Ce service applicatif de cartographie, illustré par la Table 1, pourrait être identifié par exemple dans une liste L2 obtenue pour une étape "Livraison" d'un processus métier "Vente" en cours, mis en oeuvre dans une plate-forme de vente en ligne utilisée par un téléconseiller en communication avec un client. Comme indiqué dans la Table 1, ce service de cartographie comprend deux fonctionnalités distinctes "Localiser" et "Calculer l'itinéraire". Dans cet exemple, chacune de ces deux fonctionnalités accepte en entrée le même type de données (colonne Type input) identifié par l'étiquette postalAddress. De retour à la figure 2, à l'étape E32, une fois les signatures fonctionnelles extraites pour l'ensemble des services applicatifs identifiés dans la liste L2, une liste S2 de fonctionnalités de services est créée et transmise à un module d'extraction sémantique chargé de rechercher (étape E33) dans les données textuelles T des suites de mots ou expressions, dites "mots-clés", correspondant aux types de données d'entrée des fonctionnalités identifiées dans la liste S2. En pratique, selon un mode de réalisation, un extracteur sémantique pour chaque type de donnée d'entrée (identifié dans la colonne Type input de la Table 1) associé aux fonctionnalités identifiées, est appliqué au texte T.

A l'issue de l'étape E33, le module d'extraction sémantique de mots-clés fournit une liste des fonctionnalités de services (désignée par L_pertinente finale), sous-ensemble de la liste S2, pour lesquelles au moins un mot-clé a été détecté dans les données textuelles T, et dont l'exécution est par conséquent pertinente vis-à-vis du contexte applicatif courant, lequel prend en compte la conversation en cours entre l'interlocuteur (client) et l'utilisateur (téléconseiller), et l'état du processus métier en cours d'utilisation dans l'environnement logiciel.

En relation avec la figure 3, on va à présent décrire fonctionnellement une architecture logicielle, donnée à titre d'exemple, dans laquelle on peut mettre en oeuvre la présente invention. Dans cet exemple, un client se connecte via son terminal de communication (smartphone par exemple) à un site web (SW) qui lui donne accès à un centre d'appel grâce à une fonctionnalité, CC, de "click-to-call" ou 020 en abrégé" (cliquer pour appeler en français). Lorsque le client clique sur le bouton 020 du site web, une conférence téléphonique est lancée via un serveur de pont de conférence (CONF) mettant en relation téléphonique le client avec un agent connecté à son environnement logiciel ENV via un terminal de type PC (non représenté).

La conférence téléphonique en cours entre le client et l'agent est par ailleurs "écoutée" par un serveur de reconnaissance vocale RV, en pratique le flux vocal échangé selon le protocole RTP (Real Time Protocol) est dupliqué et transmis au serveur vocal. Le serveur vocal RV effectue, en plus de la reconnaissance vocale proprement dite, un prétraitement sémantique (comme décrit plus haut) et transmet en conséquence, selon le protocole VXML (Voice Extensible Markup Language) au dessus du protocole HTTP (Hypertext Transfer Protocol), des données textuelles à un serveur d'application AS réalisant les fonctions d'analyse/extraction sémantique et de déclenchement d'actions (c'est-à-dire, prise de décisions, lancement d'applications contextuelles).

Les actions déclenchées par le serveur AS sont transmises à l'environnement utilisateur ENV via un serveur XMPP (Extensible Messaging and Presence Protocol) - par exemple un serveur de messagerie instantanée haute performance connu sous le nom de ejabberd - en utilisant le protocole XMPP au dessus de HTTP. Par ailleurs, l'environnement utilisateur ENV communique sur le réseau, en utilisant le format de données JSON (JavaScript Object Notation) au dessus du protocole HTTP, avec un gestionnaire de processus métiers GEST et avec une base de données DB contenant en particulier la liste (L-1) des services disponibles et les fonctionnalités associées. La base de données DB et le gestionnaire de processus GEST sont accessibles au serveur d'application AS pour la mise en oeuvre d'un procédé d'adaptation dynamique de l'environnement logiciel (ENV), selon l'invention, tel que décrit plus haut. La figure 4 représente une interface graphique utilisateur d'une plateforme de vente de matériel d'électronique grand public, dans laquelle la présente invention est mise en oeuvre. Dans cet exemple, le flux conversationnel est un flux de messagerie instantanée affiché dans une zone Z1 de l'interface. Le processus métier courant est le processus 'Vente', et l'étape en cours dans ce processus est l'étape "Livraison".

Durant l'interaction avec le client, le téléconseiller est guidé par un outil de Scripting qui affiche dans une zone Z2 de l'interface des propositions de questions à poser, et en dessous les réponses possibles du client attendues. En fonction de la réponse faite par le client, affichée dans la zone Z1, le téléconseiller clique sur la réponse possible correspondante de la zone Z2 pour être à nouveau guidé vers une nouvelle étape du processus ou un nouveau processus, le cas échéant. Dans cet exemple, dans la zone Z1, on peut voir que le client indique qu'il souhaite être livré à l'adresse : "167 Boulevard Davout, 75020, Paris". Cette adresse est une information textuelle présente dans les données textuelles affichées dans la zone Z1, qui après mise en oeuvre de l'analyse sémantique selon l'invention, constitue un mot-clé puisque cette information correspond au type de donnée d'entrée postalAddress d'au moins une fonctionnalité (cf. Table 1). En conséquence, comme résultat de la mise en oeuvre de l'invention, dans la zone Z3 de l'interface, une proposition est faite au téléconseiller de lancer le service "Localiser " avec comme donnée d'entrée l'adresse indiquée par le client.

Dans cet exemple un autre service est proposé au téléconseiller : celui de "chercher le client" dans une base de données de clients, avec comme donnée d'entrée l'adresse email que le client a fournie au cours de la conversation restituée dans la zone Z1 : test.test@orange.com.30

Claims (10)

1. REVENDICATIONS1. Procédé d'adaptation dynamique d'un environnement logiciel exécuté à partir d'un terminal de communication d'un utilisateur, au cours d'une communication entre ledit utilisateur et au moins un interlocuteur, au travers d'un réseau de communication, caractérisé en ce qu'il comporte : a) - l'obtention (El, E2) en temps réel de données textuelles à partir d'un flux de conversation temps réel échangé entre l'utilisateur et l'interlocuteur ; b) - la détermination (E3) d'un contexte applicatif courant de l'environnement logiciel, relatif à l'obtention desdites données textuelles ; c) - la recherche (E3) d'au moins un mot-clé dans lesdites données textuelles, ledit au moins un mot-clé à rechercher étant déterminé en fonction dudit contexte applicatif courant ; d) - la détermination (E4), à partir d'au moins un mot-clé trouvé dans les données textuelles, d'au moins une fonctionnalité de service pertinente à exécuter dans le contexte applicatif courant de l'environnement logiciel.
2. 2. Procédé selon la revendication 1, dans lequel l'étape b) de détermination d'un contexte applicatif courant inclut : - l'identification d'un processus applicatif en cours d'exécution dans l'environnement logiciel au moment de l'obtention desdites données textuelles ; et - la détermination d'une liste (L2) de services applicatifs susceptibles d'être exécutés au cours du processus applicatif identifié.
3. 3. Procédé selon la revendication 2, dans lequel chaque service applicatif identifié dans ladite liste (L2) est défini par une structure de données définissant au moins une fonctionnalité, chaque fonctionnalité étant définie par au moins un type de donnée d'entrée pour l'exécution de ladite fonctionnalité, et dans lequel à l'étape c) chaque mot-clé recherché dans lesdites données textuelles correspond à un type de donnée d'entrée défini pour une fonctionnalité associée à un service applicatif identifié dans ladite liste (L2).
4. 4. Procédé selon la revendication 3, à l'étape c) la recherche d'un mot-clé donné dans lesdites données textuelles est effectuée par un analyseur sémantique spécifique.
5. 5. Procédé selon la revendication 3 ou 4, dans lequel l'étape d) de détermination d'au moins une fonctionnalité de service pertinente, comprend la sélection de chaque service applicatif de ladite liste (L2) pour lequel au moins un type de donnée d'entrée d'une fonctionnalité associée a été trouvé dans lesdites données textuelles.
6. 6. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre une étape e) d'affichage, sur une interface graphique exécutée dans le terminal de l'utilisateur, d'éléments graphiques proposant le lancement d'au moins une fonctionnalité de service pertinente.
7. 7. Procédé selon l'une quelconque des revendications 1 à 6, dans lequel ledit flux de conversation temps réel est un flux de communication vocale, et dans lequel, à l'étape a), lesdites données textuelles sont obtenues après traitement de reconnaissance vocale appliqué audit flux de conversation.
8. 8. Procédé selon l'une quelconque des revendications 1 à 6, dans lequel ledit flux de conversation temps réel est un flux de messagerie instantanée, et dans lequel, à l'étape a), lesdites données textuelles sont obtenues après traitement de correction syntaxique appliqué audit flux de conversation. 25
9. 9. Dispositif d'adaptation dynamique d'un environnement logiciel exécuté sur un terminal de communication d'un utilisateur, au cours d'une communication entre ledit utilisateur et au moins un interlocuteur, au travers d'un réseau de communication, caractérisé en ce qu'il comporte : 30 - un module d'obtention de données textuelles, conçu pour obtenir des données textuelles à partir d'un flux de conversation temps réel échangé entre l'utilisateur et l'interlocuteur sur le réseau de communication ; - un module de détermination de contexte, conçu pour déterminer un contexte applicatif courant de l'environnement logiciel au moment de l'obtention desdites 35 données textuelles ; 20- un module de traitement de données textuelles, conçu pour rechercher dans les données textuelles au moins un mot-clé déterminé en fonction du contexte applicatif courant de l'environnement logiciel ; - un module de détermination de service, conçu pour déterminer, à partir d'au moins un mot-clé trouvé dans les données textuelles, au moins une fonctionnalité de service pertinente à exécuter dans le contexte applicatif de l'environnement logiciel.
10. 10. Programme d'ordinateur stocké sur un support d'informations, comprenant des instructions de programme dont l'exécution par un processeur provoque la mise en oeuvre d'un procédé d'adaptation dynamique d'un environnement logiciel, selon l'une quelconque des revendications 1 à 8.