FR3059862A1 - Traitement d'une communication par un agent conversationnel automatise - Google Patents
Traitement d'une communication par un agent conversationnel automatise Download PDFInfo
- Publication number
- FR3059862A1 FR3059862A1 FR1662018A FR1662018A FR3059862A1 FR 3059862 A1 FR3059862 A1 FR 3059862A1 FR 1662018 A FR1662018 A FR 1662018A FR 1662018 A FR1662018 A FR 1662018A FR 3059862 A1 FR3059862 A1 FR 3059862A1
- Authority
- FR
- France
- Prior art keywords
- user
- communication
- botb
- target user
- terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims abstract description 263
- 238000012545 processing Methods 0.000 title claims abstract description 81
- 238000000034 method Methods 0.000 claims abstract description 62
- 230000008569 process Effects 0.000 claims description 37
- 230000009471 action Effects 0.000 claims description 16
- 238000004590 computer program Methods 0.000 claims description 16
- 238000012795 verification Methods 0.000 claims description 6
- 238000001514 detection method Methods 0.000 claims description 3
- 238000012544 monitoring process Methods 0.000 claims description 2
- 238000003672 processing method Methods 0.000 abstract description 17
- 230000003213 activating effect Effects 0.000 abstract 1
- 239000003795 chemical substances by application Substances 0.000 description 98
- 101000711846 Homo sapiens Transcription factor SOX-9 Proteins 0.000 description 9
- 102100034204 Transcription factor SOX-9 Human genes 0.000 description 9
- 230000004044 response Effects 0.000 description 9
- 101100232371 Hordeum vulgare IAT3 gene Proteins 0.000 description 5
- 230000000694 effects Effects 0.000 description 5
- 101100396152 Arabidopsis thaliana IAA19 gene Proteins 0.000 description 4
- 101100274486 Mus musculus Cited2 gene Proteins 0.000 description 4
- 101150096622 Smr2 gene Proteins 0.000 description 4
- 230000015572 biosynthetic process Effects 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000000977 initiatory effect Effects 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 238000003786 synthesis reaction Methods 0.000 description 4
- 230000002452 interceptive effect Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 241000276573 Cottidae Species 0.000 description 1
- 108020004414 DNA Proteins 0.000 description 1
- 101100286247 Mus musculus Id1 gene Proteins 0.000 description 1
- 101000993976 Sagittaria sagittifolia Proteinase inhibitor A Proteins 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 241000894007 species Species 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
- H04M3/527—Centralised call answering arrangements not requiring operator intervention
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/42365—Presence services providing information on the willingness to communicate or the ability to communicate in terms of media capability or network connectivity
- H04M3/42374—Presence services providing information on the willingness to communicate or the ability to communicate in terms of media capability or network connectivity where the information is provided to a monitoring entity such as a potential calling party or a call processing server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2203/00—Aspects of automatic or semi-automatic exchanges
- H04M2203/20—Aspects of automatic or semi-automatic exchanges related to features of supplementary services
- H04M2203/2072—Schedules, e.g. personal calendars
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
Abstract
L'invention concerne un procédé de traitement d'une communication, mis en œuvre par un serveur d'applications (SA2), comprenant : la réception d'une requête (RQ1) de communication provenant d'un premier terminal (TA) d'un utilisateur appelant (UA) ; l'activation, hors du réseau de communication du serveur d'applications (SA2), d'un agent conversationnel automatisé (BOTB) de l'utilisateur cible (UB) ; et le traitement (C16), sous le contrôle de l'agent conversationnel automatisé (BOTB), de la requête de communication (RQ1) afin d'établir un dialogue entre l'agent conversationnel automatisé (BOTB) et au moins l'un parmi le premier terminal (TA) et un autre agent conversationnel automatisé (BOTA) associé à l'utilisateur appelant (UA). L'invention concerne également un procédé de traitement mis en œuvre par le premier agent conversationnel automatisé (BOTB) pour traiter la requête de communication (RQ1).
Description
® RÉPUBLIQUE FRANÇAISE
INSTITUT NATIONAL DE LA PROPRIÉTÉ INDUSTRIELLE © N° de publication :
(à n’utiliser que pour les commandes de reproduction)
©) N° d’enregistrement national
059 862
62018
COURBEVOIE © Int Cl8 : H 04 M 3/533 (2017.01), H 04 M 3/428, 3/48, 1/658, 3/ 436, 1/663
DEMANDE DE BREVET D'INVENTION A1
| ©) Date de dépôt : 06.12.16. (© Priorité : | (© Demandeur(s) : ORANGE Société anonyme — FR. |
| ©) Date de mise à la disposition du public de la demande : 08.06.18 Bulletin 18/23. | @ Inventeur(s) : LABRANCHE MIGUEL et PASCUAL JUAN. |
| ©) Liste des documents cités dans le rapport de recherche préliminaire : Se reporter à la fin du présent fascicule | |
| (© Références à d’autres documents nationaux apparentés : | ©) Titulaire(s) : ORANGE Société anonyme. |
| ©) Demande(s) d’extension : | © Mandataire(s) : CABINET BEAU DE LOMENIE. |
ù>4/ TRAITEMENT D'UNE COMMUNICATION PAR UN AGENT CONVERSATIONNEL AUTOMATISE.
FR 3 059 862 - A1
L'invention concerne un procédé de traitement d'une communication, mis en oeuvre par un serveur d'applications (SA2), comprenant: la réception d'une requête (RQ1) de communication provenant d'un premier terminal (TA) d'un utilisateur appelant (UA); l'activation, hors du réseau de communication du serveur d'applications (SA2), d'un agent conversationnel automatisé (BOTB) de l'utilisateur cible (UB); et le traitement (C16), sous le contrôle de l'agent conversationnel automatisé (BOTB), de la requête de communication (RQ1) afin d'établir un dialogue entre l'agent conversationnel automatisé (BOTB) et au moins l'un parmi le premier terminal (TA) et un autre agent conversationnel automatisé (BOTA) associé à l'utilisateur appelant (UA).
L'invention concerne également un procédé de traitement mis en oeuvre par le premier agent conversationnel automatisé (BOTB) pour traiter la requête de communication (RQ1).
Arrière-plan de l'invention
L’invention se rapporte au domaine des télécommunications et porte plus particulièrement le traitement d'une tentative de communication entre plusieurs individus.
De nombreuses solutions de télécommunications sont aujourd'hui à disposition pour permettre l'établissement d'une communication entre deux personnes. Divers types de réseaux de communications (3G, 4G etc.) ont été déployés ces dernières années par les opérateurs pour offrir des services de communications adaptés aux besoins de leurs abonnés. Pour joindre un tiers, un utilisateur peut aujourd'hui faire usage d'un quelconque terminal afin d'établir une communication écrite ou orale, en effectuant par exemple un appel téléphonique ou en envoyant un message de type SMS, email, message via une messagerie instantanée...
La mise en relation entre l'appelant, à l'origine de la tentative de communication, et l'appelé, destinataire de cette communication, n'est toutefois pas toujours aisée. La tentative de communication initiée par l'appelant est susceptible d'échouer sans qu'il n'en connaisse la raison, par exemple parce que l'utilisateur appelé n'est pas disponible. Cet aléa quant aux chances de succès d'une mise en relation entre deux terminaux peut poser problème et décourage parfois l'utilisateur appelant de tenter cette communication en premier lieu.
Il existe aujourd'hui un besoin pour faciliter la mise en relation de plusieurs individus.
Objet et résumé de l'invention
A cet effet, la présente invention concerne un premier procédé de traitement d'une communication, mis en œuvre par un premier serveur d'applications, comprenant les étapes suivantes :
réception d'une requête de communication provenant d'un premier terminal d'un utilisateur appelant, ladite requête visant à établir une communication avec un deuxième terminal d'un utilisateur cible, le premier serveur d'applications étant compris dans un réseau de communication associé au deuxième terminal ; envoi, à un premier agent conversationnel automatisé associé à l'utilisateur cible, d'une commande de déclenchement pour activer ledit premier agent conversationnel automatisé, ce dernier étant situé hors du réseau de communication du deuxième terminal ; et traitement, sous le contrôle du premier agent conversationnel automatisé, de la requête de communication, ledit traitement comprenant l'établissement d'un dialogue entre le premier agent conversationnel automatisé et au moins l'un parmi le premier terminal et un deuxième agent conversationnel automatisé associé à l'utilisateur appelant.
La présente invention permet de faciliter la mise en relation de deux personnes ou plus. Une communication initiée par un utilisateur source peut être traitée en temps réel par l'agent conversationnel automatisé de l'utilisateur cible afin d'optimiser les chances pour l'utilisateur source de rentrer en contact avec l'utilisateur appelé.
L'utilisateur source, qui a initié la communication, est ainsi moins susceptible d'hésiter à contacter un tiers dans la mesure où la communication sera traitée selon les souhaits prédéfinis du tiers. L'agent conversationnel automatisé de l'utilisateur cible peut fournir toutes les informations nécessaires à l'utilisateur source sous la forme d'une notification simple, ou sous la forme d'un dialogue interactif par exemple. L'agent conversationnel automatisé de l'utilisateur cible peut par exemple indiquer à l'utilisateur source, sur son terminal, que l'utilisateur cible n'est pas disponible et/ou lui indiquer une date et/ou heure à laquelle il sera probablement disponible. Un dialogue peut s'établir si besoin entre le terminal de l'utilisateur source et l'agent conversationnel automatisé de l'utilisateur cible afin de répondre aux éventuelles questions de l'utilisateur source ou pour permettre la mise en œuvre d'un service particulier.
Selon le paramétrage choisi, l'agent conversationnel automatisé de l'utilisateur cible peut inviter l'utilisateur source à réitérer sa tentative de communication à un moment opportun, via le même réseau de communication de l'utilisateur cible ou via un autre réseau de communication utilisé par l'utilisateur cible.
L'agent conversationnel automatisé de l'utilisateur cible est positionné à l'extérieur de chacun des réseaux de communications associés à l'utilisateur cible, ce qui permet à ce dernier de recevoir de façon centralisée les évènements émis par chacun des réseaux de communications associé à l'utilisateur cible. Cette disposition permet en outre à l'agent conversationnel automatisé de l'utilisateur cible de piloter à distance le serveur d'applications situé dans le réseau de l'utilisateur cible et, le cas échéant chacun des autres serveurs d'applications associés à l'utilisateur cible, afin de traiter une quelconque communication entrant à destination de l'utilisateur cible.
Selon un mode de réalisation particulier, le premier procédé de traitement comprend un envoi, au premier agent conversationnel automatisé, d'au moins un évènement indicatif de la disponibilité de l'utilisateur cible afin de permettre audit premier agent conversationnel automatisé d'adapter ledit traitement en fonction dudit évènement. De façon avantageuse, cela permet à l'agent conversationnel automatisé de l'utilisateur cible de récolter des informations pertinentes concernant les activités de l'utilisateur cible et, plus généralement, sur son état de disponibilité présent et/ou futur. A partir de ces informations, l'agent conversationnel automatisé de l'utilisateur cible peut en déduire par exemple si l'utilisateur cible est actuellement disponible, ou sera disponible dans un futur plus ou moins proche (à définir), pour communiquer avec l'utilisateur source.
Selon un mode de réalisation particulier, le premier procédé de traitement comprend un envoi, au premier agent conversationnel automatisé, d'un identifiant de l'utilisateur appelant inclus dans la requête de communication afin de permettre audit premier agent conversationnel automatisé d'adapter ledit traitement en fonction de l'utilisateur appelant. Il est ainsi possible de personnaliser le traitement de la communication entrante en fonction de l'identité de l'utilisateur source.
Selon un mode de réalisation particulier, le premier procédé de traitement comprend une réception d'un identifiant du deuxième agent conversationnel automatisé associé à l'utilisateur appelant, ledit traitement comprenant l'établissement d'une communication entre les premier et deuxième agents conversationnels automatisés afin de traiter collectivement ladite requête de communication. De cette manière, l'agent conversationnel automatisé de l'utilisateur cible est capable de rentrer en contact avec l'agent conversationnel automatisé de l'utilisateur source de sorte à ce qu'une coopération s'effectue entre les deux agents conversationnel automatisés. Cette coopération permet de traiter de façon optimale la communication, facilitant ainsi la mise en relation des deux utilisateurs concernés. Un service peut notamment être mis en œuvre lors de cette coopération.
Dans un mode particulier de réalisation, les différentes étapes du premier procédé de traitement 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 dispositif tel qu'un serveur, ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un premier procédé de traitement tel que définis ci-dessus.
L'invention vise aussi un support d'enregistrement (ou support d’informations) lisible par un ordinateur, et comportant des instructions d’un programme d’ordinateur tel que mentionné ci-dessus.
La présente invention concerne également un deuxième procédé de traitement d'une communication, mis en œuvre par un premier agent conversationnel automatisé, comprenant les étapes suivantes :
réception d'une commande de déclenchement provenant d'un serveur d'applications, pour traiter une requête de communication provenant d'un premier terminal d'un utilisateur source visant à établir une communication avec un deuxième terminal d'un utilisateur cible, ledit serveur d'applications étant compris dans un réseau de communication associé au deuxième terminal et ledit premier agent conversationnel automatisé étant situé hors dudit réseau de communication ;
vérification que des évènements indicatifs de la disponibilité de l'utilisateur cible ont été reçus en provenance du réseau de communication du deuxième terminal et en provenance d'au moins un autre réseau de communication associé à l'utilisateur cible ;
détermination de l'état de disponibilité du deuxième utilisateur à partir d'au moins un dit évènement reçu ; et contrôle à distance du serveur d'applications pour réaliser un traitement de la requête de communication en fonction de l'état de disponibilité de l'utilisateur cible.
La présente invention permet de faciliter la mise en relation de deux personnes ou plus. Une communication initiée par un utilisateur source peut être traitée en temps réel par l'agent conversationnel automatisé de l'utilisateur cible afin d'optimiser les chances pour l'utilisateur source de rentrer en contact avec l'utilisateur appelé. Les avantages énoncés ci-avant en relation avec le premier procédé de traitement s'appliquent de façon analogue au deuxième procédé de traitement de l'invention.
Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend une réception d'une pluralité de dits évènements indicatifs de la disponibilité de l'utilisateur cible, en provenance du réseau de communication du deuxième terminal et en provenance dudit au moins un autre réseau de communication associé à l'utilisateur cible. L'agent conversationnel automatisé de l'utilisateur cible est ainsi capable de déterminer, à partir de ces évènements, l'état de disponibilité de l'utilisateur cible.
Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend l'établissement d'un dialogue entre le premier agent conversationnel automatisé et au moins l'un parmi le premier terminal et un deuxième agent conversationnel automatisé associé à l'utilisateur appelant. De cette manière, l'agent conversationnel automatisé peut traiter de façon interactive la communication avec l'utilisateur source ou son agent conversationnelle automatisé, et ainsi répondre de façon adaptée à chaque cas d'espèce.
Selon un mode de réalisation particulier, lors de l'étape de détermination du deuxième procédé de traitement, si l'utilisateur cible est déterminé comme n'étant pas disponible, le premier agent conversationnel automatisé réalise au moins l'une des actions définies ci-après.
- selon une première action, le premier agent conversationnel automatisé obtient une donnée de disponibilité renseignant sur l'état de disponibilité de l'utilisateur cible et commande l'envoi, par le serveur d'applications, de ladite donnée de disponibilité à au moins l'un parmi le premier terminal et le deuxième agent conversationnel automatisé. De cette manière, l'utilisateur source peut recontacter l'utilisateur cible à un moment approprié et optimiser ses chances de joindre l'utilisateur cible dans de bonnes conditions ;
- selon une deuxième action, le premier agent conversationnel automatisé envoie une notification de communication audit au moins un autre réseau de communication associé à l'utilisateur cible, ladite notification de communication informant de la tentative de communication initiée par le premier terminal. L'envoi de cette notification permet d'informer l'utilisateur cible de la tentative de communication initiée par le premier terminal sur le réseau de l'utilisateur cible. Cette notification comporte par exemple l'identifiant de l'utilisateur source afin d'informer l'utilisateur cible de l'identité de l'utilisateur source, ce qui permet à l'utilisateur cible de recontacter ultérieurement l'utilisateur source si besoin ;
- selon une troisième action, le premier agent conversationnel automatisé définit, par l'intermédiaire du serveur d'applications, un rendez-vous en coopération avec le premier terminal ou le deuxième agent conversationnel automatisé, et enregistre une nouvelle entrée indicative du rendez-vous dans des données d'agenda associées à l'utilisateur cible. L'utilisateur cible peut ainsi prendre connaissance, par l'intermédiaire d'un réseau de communication autre que le réseau initialement visé, du nouveau rendez-vous enregistré par son agent conversationnel automatisé ;
- selon une quatrième action, le premier agent conversationnel automatisé détermine un identifiant de l'utilisateur cible dans ledit au moins un autre réseau de communication et commande l'envoi, par le serveur d'applications, d'une invitation comportant ledit identifiant pour inviter l'utilisateur appelant à contacter l'utilisateur cible via ledit au moins un autre réseau de communication. L'utilisateur source peut ainsi tenter de contacter l'utilisateur cible sur un réseau de communication autre que le réseau initialement visé, optimisant ainsi les chances de joindre l'utilisateur cible dans de bonnes conditions ;
- selon une cinquième action, le premier agent conversationnel automatisé surveille l'état de disponibilité courant de l'utilisateur cible et, sur détection que l'état de disponibilité courant du deuxième utilisateur atteint un état prédéfini, commande l'envoi, par le serveur d'applications, d'une notification informant de l'état prédéfini à l'attention de l'utilisateur appelant. De cette manière, l'utilisateur source est informé dès que l'utilisateur cible est disponible, et éventuellement sous quelle condition il est disponible (type de communication acceptée etc.), ce qui permet de faciliter la mise en communications des deux parties.
Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend une réception, en provenance du serveur d'applications, d'un identifiant de l'utilisateur appelant, ledit traitement causé par le premier agent conversationnel automatisé lors du contrôle à distance étant fonction dudit identifiant de l'utilisateur appelant. Il est ainsi possible pour le premier agent conversationnel automatisé de personnaliser le traitement de chaque communication initié à l'attention de l'utilisateur cible.
Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend une détermination d'un niveau d'urgence de la requête de communication à partir de l'identifiant de l'utilisateur appelant ; et si le niveau d'urgence atteint un niveau prédéfini, le premier agent conversationnel automatisé cause l'envoi, par le serveur d'applications, d'une notification d'urgence à l'attention de l'utilisateur cible via le réseau de communications ou via ledit au moins un autre réseau de communications. L'utilisateur cible peut ainsi juger de l'importance d'une communication entrante et traiter en priorité les communications qu'il juge importante.
Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend les étapes suivantes :
- envoi d'une commande au serveur d'applications visant à établir, en réponse à ladite requête de communication, une communication entre les premier et deuxième terminaux ;
- déclenchement d'un décompte de temps à compter de l'envoi de la commande visant à établir une communication entre les premier et deuxième terminaux ; et
- en l'absence de réponse positive du deuxième terminal après un délai prédéfini, détermination que l'utilisateur cible n'est pas actuellement disponible.
L'agent conversationnel automatisé peut ainsi déterminer si l'utilisateur cible est actuellement disponible ou non et rentrer si besoin en communication avec l'utilisateur source et/ou l'agent conversationnel automatisé de ce dernier afin de traiter au mieux la communication.
Selon un mode de réalisation particulier, le deuxième procédé de traitement comprend une réception, en provenance du serveur d'applications, d'un identifiant du deuxième agent conversationnel automatisé associé à l'utilisateur appelant, ladite étape de contrôle à distance comprenant l'établissement d'une communication entre les premier et deuxième agents conversationnels automatisés via le serveur d'applications afin de traiter collectivement ladite requête de communication. De cette manière, l'agent conversationnel automatisé de l'utilisateur cible peut coopérer de façon interactive avec l'agent conversationnel automatisé de l'utilisateur source, de sorte à ce qu'ensemble ils répondent de façon adaptée à chaque cas d'espèce.
Selon un mode de réalisation particulier, lors dudit contrôle à distance, les premier et deuxième agents conversationnels automatisés échangent, via le serveur d'applications, des données associées aux utilisateurs appelant et cibles de sorte à réaliser collectivement au moins une action prédéterminée. Les agents conversationnels automatisés peuvent ainsi mettre en œuvre au moins un service permettant par exemple de faciliter la mise en relation immédiate ou future de l'utilisateur source et de l'utilisateur cible.
Dans un mode particulier de réalisation, les différentes étapes du deuxième procédé de traitement 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 dispositif tel qu'un serveur, ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un deuxième procédé de traitement tel que définis ci-dessus.
L'invention vise aussi un support d'enregistrement (ou support d'informations) lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
A noter que les programmes mentionnés dans le présent exposé peuvent 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.
De plus, les supports d'enregistrement mentionnés ci-avant peuvent ê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, les supports d'enregistrement peuvent correspondre à 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 Internet.
Alternativement, les supports d'enregistrement peuvent correspondre à 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.
La présente invention vise en outre un serveur d'applications comprenant :
un module de réception configuré pour recevoir une requête de communication provenant d'un premier terminal d'un utilisateur appelant, ladite requête visant à établir une communication avec un deuxième terminal d'un utilisateur cible, le premier serveur d'applications étant compris dans un réseau de communication associé au deuxième terminal ;
un module d'envoi configuré pour envoyer, à un premier agent conversationnel automatisé associé à l'utilisateur cible, une commande de déclenchement pour activer ledit premier agent conversationnel automatisé, ce dernier étant situé hors du réseau de communication du deuxième terminal ; et un module de traitement configuré pour réaliser un traitement de la requête de communication sous le contrôle du premier agent conversationnel automatisé, ledit traitement comprenant l'établissement d'un dialogue entre le premier agent conversationnel automatisé et au moins l'un parmi le premier terminal et un deuxième agent conversationnel automatisé associé à l'utilisateur appelant.
La présente invention vise également un agent conversationnel automatisé comprenant : un module de réception configuré pour recevoir une commande de déclenchement provenant d'un serveur d'applications, pour traiter une requête de communication provenant d'un premier terminal d'un utilisateur appelant visant à établir une communication avec un deuxième terminal d'un utilisateur cible, ledit serveur d'applications étant compris dans un réseau de communication associé au deuxième terminal et ledit agent conversationnel automatisé étant situé hors dudit réseau de communication ;
un module de vérification configuré pour vérifier si des évènements indicatifs de la disponibilité de l'utilisateur cible ont été reçus en provenance du réseau de communication du deuxième terminal et en provenance d'au moins un autre réseau de communication associé à l'utilisateur cible ;
un module de détermination configuré pour déterminer l'état de disponibilité du deuxième utilisateur à partir d'au moins un dit évènement reçu ; et un module de contrôle configuré pour contrôler à distance le serveur d'applications de sorte à réaliser un traitement de la requête de communication en fonction de l'état de disponibilité de l'utilisateur cible.
A noter que les différents modes de réalisation définis ci-avant en relation avec le premier procédé de traitement, d'une part, et avec le deuxième procédé de traitement, d'autre part, ainsi que les avantages associés à ces procédés, s'appliquent respectivement par analogie aux serveur d'applications et à l'agent conversationnel automatisé définis ciavant.
Selon un mode de réalisation particulier, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures:
- la figure 1 représente schématiquement un environnement comportant notamment un serveur d'applications et un agent conversationnel automatisé conformes à un mode de réalisation particulier de l'invention ;
- la figure 2 représente schématiquement la structure d'un serveur d'applications conforme à un mode de réalisation particulier de l'invention ;
- la figure 3 représente schématiquement la structure d'un agent conversationnel automatisé conforme à un mode de réalisation particulier de l'invention ; et
- la figure 4 représente, sous forme d'un ordinogramme, les étapes d'un premier procédé de traitement mis en œuvre par un serveur d'applications et les étapes d'un deuxième procédé de traitement mis en œuvre par un agent conversationnel automatisé, conformément à un mode de réalisation particulier de l'invention.
Description détaillée de plusieurs modes de réalisation
Comme indiqué précédemment, la technique proposée se rapporte au traitement d'une tentative de communication initiée par un premier terminal de communication à destination d'un tiers utilisant un autre terminal de communication.
L'invention se propose de faciliter la mise en relation entre un utilisateur appelant et un utilisateur appelé en utilisant au moins un agent conversationnel automatisé destiné à traiter automatiquement une demande de communication initié par l'utilisateur appelant à destination de l'utilisateur appelé. L'agent conversationnel automatisé peut centraliser des informations indicatives de la disponibilité de l'utilisateur appelé et traiter la demande de communication en fonction de la disponibilité de l'appelé afin de faciliter les interactions entre appelant et appelé.
L'invention, selon divers modes de réalisation, met ainsi en œuvre un serveur d'applications situé dans le réseau de communication auquel est connecté le terminal d'un utilisateur cible, ce serveur étant configuré pour recevoir une requête de communication provenant du terminal d'un utilisateur appelant, pour déclencher un agent conversationnel automatisé associé à l'utilisateur cible, et pour traiter cette requête de communication sous le contrôle de l'agent conversationnel automatisé. L'invention, selon divers modes de réalisation, concerne également un tel agent conversationnel automatisé, configuré pour être activé par le serveur d'applications, pour déterminer l'état de disponibilité de l'utilisateur cible à partir de données (ou évènements) reçues d'au moins un réseau de communication associé à l'utilisateur cible, et pour contrôler à distance le serveur d'applications afin de traiter la requête de communication de façon appropriée, notamment en fonction de l'état de disponibilité de l'utilisateur cible.
D'autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant.
Dans le présent exposé, des exemples de mise en œuvre de l'invention sont décrits dans le cadre d'un premier utilisateur tentant d'établir une communication avec un deuxième utilisateur. Dans ce contexte, la communication initiée par le premier utilisateur peut être de type quelconque, telle que par exemple un appel vocal initié par le premier utilisateur ou encore un message de type texte (SMS, email, message via un service de messagerie instantanée...) envoyé par le premier utilisateur. En outre, toujours dans ce contexte, l'utilisateur à l'origine de la communication (c.-à-d. initiant la communication) est dit utilisateur appelant ou utilisateur source, tandis que le deuxième utilisateur destinataire de la communication est dit utilisateur appelé ou utilisateur cible. Dans le cas d'une conférence téléphonique, on peut également envisager que plusieurs utilisateurs appelants initient un appel vers un même utilisateur cible.
Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.
Un mode de réalisation particulier de l'invention est à présent décrit en référence à la figure 1, où un utilisateur UA tente d'établir une communication vocale avec un autre utilisateur UB. Comme décrit par la suite, d'autres types de communication sont toutefois possibles dans le cadre de l'invention. Pour ce faire, l'utilisateur UA, dit utilisateur appelant ou utilisateur source, initie un appel téléphonique en direction du terminal TB1 de l'utilisateur cible UB.
Dans l'exemple considéré ici, le terminal TA de l'utilisateur UA est par exemple associé (ou connecté) à un premier réseau de communications RI, tandis que le terminal TB1 de l'utilisateur cible UB est associé (ou connecté) à un deuxième réseau de communications R2. Les terminaux TA et TB1 peuvent être de quelconques équipements aptes à établir ensemble une communication vocale, tels que des téléphones mobiles ou fixes etc. Les réseaux RI et R2 peuvent être par exemple des réseaux de téléphonie fixe ou mobile (de type 3G, 4G etc.).
Dans cet exemple, un premier serveur d'applications SA1 situé dans le réseau de communications RI fait le relais entres les appels de l'utilisateur appelant UA et l'extérieur. Lorsque l'utilisateur UA tente d'appeler l'utilisateur UB, le serveur d'applications SA1 est ici configuré pour transférer une requête de communication RQ1, émise par le terminal TA de l'utilisateur appelant UA, vers le réseau de communications R2 de l'utilisateur cible UB.
Le serveur d'applications SA1 présente ici la structure d'un ordinateur et comporte notamment au moins un processeur (non représenté) et une mémoire non volatile MRI (ROM ou Flash par exemple) constituant un support d'enregistrement, lisible par le serveur d'applications SA1, et sur lequel est enregistré un programme d'ordinateur PG1 conforme à un mode de réalisation particulier.
Dans l'exemple représenté en figure 1, le serveur d'applications SA1 contient en mémoire un identifiant ID-A de l'utilisateur UA dans le réseau RI. Cet identifiant ID-A est ici enregistré en association avec un identifiant ID-BOTA d'un agent conversationnel automatisé BOTA qui sera décrit ultérieurement.
Toujours dans cet exemple, un deuxième serveur d'applications SA2, situé dans le réseau de communications R2, est chargé de recevoir les appels à destination de l'utilisateur cible UB et de les transférer si besoin vers le terminal TB1 destinataire de l'appel. Sur réception de la requête d'appel RQ1, le serveur d'applications SA2 est ici configuré pour transférer l'appel au terminal TB1 ou pour activer un agent conversationnel automatisé BOTB associé à l'utilisateur cible UB, cet agent conversationnel automatisé BOTB étant situé hors du réseau R2.
Le serveur d'applications SA2 présente ici aussi la structure d'un ordinateur et comporte notamment au moins un processeur (non représenté) et une mémoire non volatile MR2 (ROM ou Flash par exemple) constituant un support d'enregistrement, lisible par le serveur d'applications SA2, et sur lequel est enregistré un programme d'ordinateur PG2 conforme à un mode de réalisation particulier. Dans cet exemple, le serveur d'applications SA2 dispose aussi en mémoire d'un identifiant ID-BOTB de l'agent conversationnel automatisé BOTB en association avec un identifiant ID-B1 de l'utilisateur cible U B dans le réseau R2.
Sur réception de la requête d'appel RQ1 émise par le terminal source TA, le serveur d'applications SA2 peut ainsi envoyer une commande CMD1 de déclenchement à l'agent conversationnel automatisé BOTB, cette commande visant à activer ledit agent conversationnel automatisé BOTB pour qu'il traite l'appel entrant initié par l'utilisateur source UA.
Dans le présent exposé, un agent conversationnel automatisé désigne une interface homme-machine configurée pour traiter de façon interactive la ou les requêtes d'un utilisateur (par exemple l'utilisateur source UA). Pour ce faire, l'agent conversationnel automatisé (désigné aussi sous l'appellation anglaise « chatbot » dans le présent exposé) est apte à dialoguer ou coopérer avec l'utilisateur de façon automatisée, sur la base de critères prédéfinis. L'agent conversationnel automatisé peut proposer certains services et prend le cas échéant en compte les demandes ou réponses de l'utilisateur avec lequel il interagit.
Dans le cas présent, le chatbot BOTB se présente sous la forme d'un programme d'ordinateur PG3 stocké dans une mémoire non-volatile MR3 (ROM ou Flash par exemple) et exécutable par au moins un processeur (non représenté) d'un équipement informatique, tel qu'un serveur, un ordinateur ou tout autre équipement informatique apte à exécuter ce type d'interface logicielle.
Le chatbot BOTB utilise une interface de programmation applicative (API), notée ΑΡΙΑ, pour coopérer à distance avec le serveur d'applications SA2 se trouvant dans le réseau de communications R2.
Selon un exemple particulier, le chatbot BOTB met en œuvre un service de messagerie vocale configuré pour traiter les communications entrantes à destination de l'utilisateur cible UB.
Par ailleurs, le chatbot BOTB est configuré pour recevoir le cas échéant des données (ou évènements) EV en provenance du réseau de communications R3 ainsi qu'en provenance d'au moins un autre réseau de communications associé à l'utilisateur cible UB, tel que les réseaux R3 et R4 représentés ici en figure 1. Ces évènements EV sont des données indicatives de la disponibilité de l'utilisateur associé, à savoir l'utilisateur cible UB dans cet exemple. Comme indiqué par la suite, divers types d'évènements EV peuvent être reçus par le chatbot BOTB.
On suppose ici que le réseau de communication R3 est un autre réseau auquel a souscrit l'utilisateur cible UB et auquel est associé (connecté) un autre terminal TB2 de l'utilisateur cible UB. Dans cet exemple, un serveur d'applications SA3 situé dans le réseau R3 est configuré pour traiter des appels émis ou à destination du terminal TB2. Le serveur d'applications SA3 est par exemple configuré pour envoyer le cas échéant au chatbot BOTB un ou des évènements EV indicatifs de la disponibilité de l'utilisateur cible UB.
Le serveur d'applications SA3 présente ici aussi la structure d'un ordinateur et comporte notamment au moins un processeur (non représenté) et une mémoire non volatile MR4 (ROM ou Flash par exemple) constituant un support d'enregistrement, lisible par le serveur d'applications SA3, et sur lequel est enregistré un programme d'ordinateur PG4 conforme à un mode de réalisation particulier. Dans cet exemple, le serveur d'applications SA3 dispose aussi en mémoire de l'identifiant ID-BOTB de l'agent conversationnel automatisé BOTB, associé par exemple à un identifiant ID-B2 de l'utilisateur cible UB dans le réseau R3.
Les réseaux de communications R2 e R3 sont ici des réseaux distincts mis en œuvre par des opérateurs différents.
La nature des évènements EV susceptibles d'être transmis par les réseaux de communication R2 et R3 au chatbot BOTB peut varier selon le cas d'usage. Ces évènements EV sont des données informant le chatbot BOTB des activités ou de la disponibilité de l'utilisateur cible UB. Un évènement EV envoyé par le serveur d'applications SA2 (ou respectivement SA3) peut par exemple indiquer que l'utilisateur cible UB a été impliqué dans un appel téléphonique à une certaine date et/ou heure, ou que l'utilisateur cible UB est en cours de communication. L'évènement EV peut par exemple spécifier que la communication en cours (ou passée) est une communication entrante (initiée par un tiers) ou sortante (initiée par l'utilisateur UB).
Le type d'évènement EV peut varier en fonction du type de communication que l'utilisateur cible UB peut réaliser via le réseau R2 (respectivement R3) auquel il a souscrit. Dans un exemple particulier, l'évènement EV indique par exemple que l'utilisateur UB est en cours de discussion sur un service de messagerie instantanée. Selon un autre exemple, l'évènement EV comprend une information sur la localisation de l'utilisateur cible UB. A partir de cette information de localisation, le chatbot B peut ainsi déterminer l'état de disponibilité de l'utilisateur cible UB.
Comme représenté en figure 1, on suppose également dans cet exemple que le réseau de communications R4 est encore un autre réseau mettant en œuvre un service auquel a souscrit l'utilisateur cible UB. Dans le cas considéré ici, le serveur d'applications SA4 met par exemple en œuvre un service de messagerie de type Outlook™ ou équivalent capable d'envoyer au chatbot BOTB des évènements EV indicatifs de la disponibilité de l'utilisateur cible UB. Un tel évènement EV peut être par exemple un évènement d'agenda indiquant une activité ou un rendez-vous de l'utilisateur cible UB à des dates et heures données. Un évènement EV émis par le serveur d'applications SA4 peut également correspondre à une activité de l'utilisateur cible UB détectée sur le service de messagerie, telle que la préparation ou l'envoi d'un email etc. On comprendra que l'exemple de ce service de messagerie n'est pas limitatif et que d'autres types de services et d'évènements sont possibles. En variante, le service mis en œuvre par le serveur d'applications SA4 est un réseau social tel que Facebook™, Twitter™ etc.
Dans l'exemple de réalisation décrit ici, le serveur d'applications SA4 présente aussi la structure d'un ordinateur et comporte notamment au moins un processeur (non représenté) et une mémoire non volatile MR5 (ROM ou Flash par exemple) constituant un support d'enregistrement, lisible par le serveur d'applications SA4, et sur lequel est enregistré un programme d'ordinateur PG5 conforme à un mode de réalisation particulier.
Concernant à nouveau le chatbot BOTB, ce dernier est par ailleurs configuré pour surveiller les évènements EV qu'il est susceptible de recevoir des différents réseaux R2, R3, R4 associés à l'utilisateur cible UB, ces évènements EV étant indicatifs de l'état de disponibilité dudit utilisateur cible UB. Comme représenté en figue 1, le chatbot BOTB peut enregistrer dans une mémoire les évènements EV et les traiter si besoin. A partir de ces évènements EV, le chatbot B est configuré pour déterminer l'état de disponibilité ou d'accessibilité (courant et/ou futur) de l'utilisateur associé, à savoir l'utilisateur cible UB dans cet exemple. Cet état de disponibilité peut indiquer si l'utilisateur cible UB est actuellement en position ou non pour recevoir une communication entrante (tel quel un appel téléphonique entrant dans cet exemple). L'état de disponibilité peut aussi renseigner sur la capacité de l'utilisateur cible UB à recevoir une communication dans le futur.
Dans cet exemple, le BOTB contient également en mémoire l'identifiant respectif IDBl, ID-B2 et ID-B3 de l'utilisateur cible UB dans chacun des réseaux R2, R3 et R4. On comprend que l'utilisateur cible UB dispose d'un identifiant propre pour chaque réseau de communication R2, R3 et R4 dont il est usager, cet identifiant lui étant par exemple attribué par l'opérateur du réseau correspondant. Un identifiant peut être une adresse email, un numéro de téléphone, un identifiant de messagerie instantanée ou autre, selon le cas.
Toujours dans cet exemple, le chatbot BOTB stocke également en mémoire des données DN1 à partir desquelles le chatbot BOTB peut déterminer comment un appel entrant doit être traité. Les données DN1 sont ici des règles de traitement prédéfinies, ces règles pouvant par exemple être définies à l'avance par l'utilisateur cible UB ou un tiers. Ces règles de traitement DN1 peuvent définir notamment :
- quand (date, heure...) l'utilisateur UB accepte ou non de répondre à une communication ;
- à quel type de communication l'utilisateur UB accepte ou non de répondre ;
- de quel utilisateur source il accepte ou non de recevoir une communication etc.
- dans quelles situations il accepte ou non de répondre à une communication.
La situation évoquée ci-dessus peut concerner notamment la localisation de l'utilisateur UB. Les règles de traitement DN1 peuvent combiner un ensemble de critères quelconques, parmi notamment ceux indiqués ci-dessus, afin de permettre au chatbot
BOTB de déterminer dans chaque situation si l'utilisateur cible UB souhaite ou non accepter une communication entrante.
Ces règles de traitement DN1 définissent ici dans quelles conditions l'utilisateur cible UB est d'accord pour accepter une communication entrante sur le réseau de communication R2 dont il est l'usager. On comprend toutefois que des règles de traitement DN1 du même type peuvent être stockées et utilisées par le chatbot BOTB pour traiter des communications entrantes à destination de l'utilisateur cible UB sur un autre réseau de communication auquel il est abonné, comme par exemple le réseau R3 dans cet exemple.
A titre d'exemple, une règle de traitement DN1 peut définir les règles suivantes :
- l'utilisateur UB est disponible pour les communications téléphoniques entre 9 heure et 19 heures, sauf s'il est en cours de communication sur l'un des réseaux de communications (ici R4) auquel il a souscrit ;
- l'utilisateur UB accepte toujours des communications écrites par messagerie instantanée sauf s'il est localisé à son domicile ou en cours de déplacement...
L'homme du métier peut naturellement adapter notamment les règles de traitement DN1 et les types d'évènement EV remontés par les réseaux de communication R2-R4 à l'agent conversationnel automatisé BOTB de l'usager afin de répondre de façon appropriée à chaque cas d'espèce.
Le serveur d'applications SA2 et le chatbot BOTB forment ensemble un système de traitement SY apte à traiter une requête de communication RQ1 émise par le terminal UA de l'utilisateur UA pour initier une communication avec l'utilisateur cible UB.
Selon le mode de réalisation particulier considéré ici en figure 1, un deuxième agent conversationnel automatisé (ou chatbot) BOTA, associé cette fois à l'utilisateur source UA, est situé hors du réseau de communications RI de sorte à pouvoir interagir à distance avec le serveur d'applications SA1 situé dans le réseau de communications SA1. En variante, le chatbot BOTA peut être situé dans le réseau RI. Le chatbot BOTA est par exemple mis en œuvre par le serveur d'applications SA1 lui-même. Comme expliqué par la suite dans un exemple de réalisation particulier, le chatbot BOTA est configuré pour coopérer si besoin avec le chatbot BOTB de l'utilisateur cible UB afin de traiter par exemple l'appel initié par l'utilisateur source UA à l'attention de l'utilisateur cible UB. Pour ce faire, les chabots BOTA et BOTB comprennent chacun dans cet exemple une interface de communication leur permettant de communiquer ensemble. Comme expliqué par la suite, des variantes de réalisation sont toutefois possibles selon lesquelles le deuxième agent conversationnel automatisé BOTA associé à l'utilisateur source UA n'est pas mis en œuvre ou du moins n'est pas utilisé.
Dans l'exemple considéré ici, le chatbot BOTA présente une structure identique ou analogue au chatbot BOTB. Plus précisément, Le chatbot BOTA se présente sous la forme d'un programme d'ordinateur PG6 stocké dans une mémoire non-volatile MR6 (ROM ou Flash par exemple) et exécutable par au moins un processeur (non représenté) d'un équipement informatique, tel qu'un serveur, un ordinateur ou tout autre équipement informatique apte à exécuter ce type d'interface logicielle.
Le chatbot BOTA utilise une API, notée API-A, pour coopérer à distance avec le serveur d'applications SA1 se trouvant dans le réseau de communications RI.
Dans cet exemple, le chatbot BOTA comprend aussi en mémoire des règles de traitement DN2 analogues aux règles de traitement DNA du chatbot BOTB, ces règles DN2 permettant le cas échéant au chatbot BOTA de déterminer la manière dont une communication doit être traitée, comme expliqué ultérieurement.
Bien que cela ne soit pas décrit ci-après par souci de simplicité, le chatbot BOTA peut également fonctionner de façon analogue au chatbot BOTB afin de traiter une communication qu'un tiers tenterait d'initier à l'attention de l'utilisateur UA, prenant cette fois la position de l'utilisateur cible. Selon un exemple particulier, le chatbot BOTA met en œuvre un service de messagerie vocale configuré pour traiter les communications entrantes à destination de l'utilisateur UA.
On comprendra que certains éléments généralement présents dans notamment un serveur d'applications, dans un chatbot ou encore dans un réseau de communications, ont été volontairement omis car ils ne sont pas nécessaires à la compréhension de la présente invention.
On comprendra que l'environnement représenté en figure 1, et notamment le système de traitement SY, n'est qu'un exemple de réalisation, d'autres mises en œuvre étant possibles dans le cadre de l'invention. L'homme du métier comprendra en particulier que certains éléments de cet environnement ne sont décrits ici que pour faciliter la compréhension de l'invention, ces éléments n'étant pas nécessaires pour mettre en œuvre l'invention.
Selon un mode de réalisation particulier représenté en figure 2, le serveur d'applications SA2 (et plus particulièrement son processeur) piloté par le programme d'ordinateur PG2 met en œuvre un certain nombre de modules, à savoir : un module de réception MD2, un module d'envoi MD4, un module de traitement MD6 et un module de suivi d'évènements MD8.
Le module de réception MD2 est configuré pour recevoir la requête RQ1 de communication provenant du terminal source TA comme représenté en figure 1, cette requête visant à établir une communication entre le terminal source TA et le terminal cible TB1.
Le module d'envoi MD4 est configuré pour envoyer, au chatbot BOTB associé à l'utilisateur cible UB, une commande de déclenchement CMD1 (figure 1) pour activer ledit chatbot BOTB.
Le module de traitement MD6 est configuré pour réaliser notamment un traitement de la requête de communication RQ1 reçue par le module de réception MD2, ce traitement étant réalisé sous le contrôle du chatbot BOTB qui commande le serveur d'applications SA2 à distance (c.-à-d. depuis l'extérieur du réseau R2). Comme expliqué par la suite, le traitement réalisé par le module de traitement MD6 peut comprendre l'établissement d'un dialogue ou d'une interaction entre le chatbot BOTB et au moins l'un parmi le terminal source TA de l'utilisateur appelant UA et le chatbot BOTA de l'utilisateur appelant UA. Si, dans une variante, l'utilisateur source UA ne dispose pas d'un chatbot pour l'assister, le dialogue se fait nécessairement entre le chatbot BOTB et le terminal TA de l'utilisateur source UA.
Plus généralement, on comprendra que le module de traitement MD6 peut être configuré pour réaliser un quelconque traitement en réponse à des instructions émises par un agent conversationnel automatisé externe au réseau de communications R2. Selon le cas, le traitement réalisé par le module de traitement MD6 peut par exemple être piloté à distance par le chatbot BOTB ou par un autre chatbot (tel que le chatbot BOTA) associé à un autre utilisateur que l'utilisateur UB.
Selon un mode de réalisation particulier représenté en figure 3, l'agent conversationnel automatisé BOTB (et plus particulièrement son processeur) piloté par le programme d'ordinateur PG3 met en œuvre un certain nombre de modules, à savoir : un module de réception MD10, un module de vérification MD12, un module de détermination MD14 et un module de contrôle MD16.
Le module de réception MD10 est configuré pour recevoir la commande de déclenchement CMD1 provenant du serveur d'applications SA1, cette commande déclenchant le traitement par le chatbot BOTB de la requête RQ1 de communication provenant du terminal TA de l'utilisateur source UA.
Le module de vérification MD12 est configuré pour vérifier si un ou des évènements EV indicatifs de la disponibilité de l'utilisateur cible UB ont été reçus en provenance du réseau de communication R2 du terminal TB1 et en provenance d'au moins un autre réseau de communication associé à l'utilisateur cible UB, à savoir les réseaux R3 et R4 dans cet exemple.
Le module de détermination MD14 est configuré pour déterminer l'état de disponibilité (courant et/ou futur) de l'utilisateur cible UB à partir d'au moins un évènement reçu EV reçu.
Le module de contrôle MD16 est configuré pour contrôler à distance (c'est-à-dire depuis l'extérieur du réseau R2) le serveur d'applications SA2 de sorte à réaliser un traitement de la requête de communication RQ1 en fonction de l'état de disponibilité de l'utilisateur cible UB. Comme déjà indiqué et comme illustré par la suite, le module de contrôle MD16 peut prendre en compte un certain nombre de paramètres pour déterminer l'état de disponibilité de l'utilisateur UB et la manière dont une communication entrante doit être traitée, en appliquant notamment les règles de traitement prédéfinies DN1 dans le cas présent.
Plus généralement, on comprendra que le module de contrôle MD16 peut être configuré pour contrôler, depuis l'extérieur du réseau R2, le serveur d'applications SA2 de sorte à réaliser un traitement adapté à chaque cas d'espèce.
Comme représenté en figure 1, le chatbot B est positionné à l'extérieur de chacun des réseaux de communications associés à l'utilisateur cible UB (à savoir R2, R3 et R4 dans cet exemple). Cette position externe du chatbot BOTB permet à ce dernier de recevoir de façon centralisée les évènements EV émis par chacun des réseaux de communications R2, R3, R4 auquel l'utilisateur UB a souscrit. Cette disposition permet en outre au chatbot BOTB de piloter à distance le serveur d'applications SA2 et, le cas échéant chacun des serveurs d'applications SA3 et SA4, afin de traiter une quelconque communication entrant dans un réseau de communication R2, R3 ou R4 à destination de l'usager UB.
Le fonctionnement des modules MD2-MD8 du serveur d'applications SA2 (figure 2) et des modules MD10-MD16 du chatbot BOTB (figure 3) apparaîtra plus précisément dans les exemples de réalisation décrits ci-après en référence à la figure 4. On comprendra que ces modules ne constituent qu'un exemple de mise en œuvre non limitatif de l'invention, des variantes étant à la portée de l'homme du métier.
Un mode de réalisation particulier de l'invention est à présent décrit en référence à la figure 4. Plus précisément, le serveur d'applications SA2 et l'agent conversationnel automatisé BOTB illustrés en figures 1-3 mettent chacun en œuvre un procédé de traitement en exécutant respectivement le programme d'ordinateur PG2, PG3.
Comme déjà expliqué en référence à la figure 1, on supposera à présent que l'utilisateur source UA utilise son terminal TA afin d'initier une communication vers le réseau de communications R2 à destination de l'utilisateur cible UB. Dans l'exemple considéré ici, on suppose que l'utilisateur source UB tente d'établir une conversation vocale en initiant un appel téléphonique à destination de l'utilisateur cible TB1.
Dans cet exemple, lors de l'initiation de l'appel, le terminal TA de l'utilisateur source UA envoie une requête RQ1 de communication qui est reçue en B2 par le serveur d'applications SA1. La requête RQ1 comprend l'identifiant ID-B1 de l'utilisateur cible UB dans le réseau de communications R2. A partir de cet identifiant ID-B1, le serveur d'applications SA1 détermine vers quelle destination doit être transmise la requête RQ1 de communication. Dans cet exemple, cette requête RQ1 comprend en outre l'identifiant IDA de l'utilisateur UA à l'origine de l'appel, bien que des variantes de réalisation sans l'inclusion d'un tel identifiant dans la requête RQ1 sont possibles (cas d'un appel anonyme par exemple).
Le serveur d'applications SA1 insert (B3) ensuite l'identifiant ID-BOTA du chatbot BOTA dans la requête RQ1 et envoie (B4) ladite requête RQ1, comportant l'identifiant IDBOTA, au réseau de communication R2. Le serveur d'applications SA2 reçoit la requête RQ1 en C4.
Dans cet exemple de réalisation, le serveur d'applications SA2 détecte, à partir de l'identifiant ID-B1 présent dans la requête RQ1, que la communication entrante est destinée à l'utilisateur cible UB. Le serveur d'applications SA2 envoie (C6) alors une commande de déclenchement CMD1 au chatbot BOTB chargé de traiter les communications de l'utilisateur cible UB. Le serveur d'applications SA2 détermine que le chatbot BOTB est en charge du traitement des communications à partir de l'identifiant IDBOTB enregistré en association avec l'identifiant ID-B1 de l'utilisateur cible UB dans le réseau R2.
On comprendra que des variantes sont possibles selon lesquelles le serveur d'applications SA2 tente dans un premier temps de joindre l'utilisateur cible UB sur son terminal TB1 et, en cas d'échec (par exemple en cas de non réponse après un délai prédéfini), procède alors à l'envoi C6 de la commande de déclenchement CMD1.
Dans l'exemple envisagé ici, la commande de déclenchement CMD1 envoyée en C6 par le serveur d'applications SA2 comprend l'identifiant ID-A de l'utilisateur source UA, l'identifiant ID-B1 de l'utilisateur cible UB et l'identifiant ID-BOTA du chatbot BOTA de l'utilisateur UA.
Comme illustré en figure 4, le chatbot BOTB de l'usager UB reçoit la commande de déclenchement CMD1 en D6. Sur réception de cette commande CMD1, le chatbot BOTB traite la communication entrante comme expliqué ci-après.
En parallèle, le chatbot BOTB reçoit (D7) au moins un évènement EV émis par l'un quelconque des réseaux de communications R2, R3, R4 associés à l'utilisateur cible UB, cet évènement EV étant indicatif de la disponibilité (ou de l'état d'accessibilité) de l'utilisateur UB. Dans un exemple particulier, le chatbot BOTB reçoit (D7) une pluralité de dits évènements EV en provenance du réseau de communication R2 et en provenance des autres réseaux de communication R3 et R4 associés à l'utilisateur cible UB. Le chatbot BOTB peut traiter chaque évènement EV en temps réel.
Dans l'exemple représenté en figure 4, on suppose que le chatbot BOTB reçoit (D8) un premier évènement EV1 émis (C8) par le serveur d'applications SA2, reçoit (D10) un deuxième évènement EV2 émis (F10) par le serveur d'applications SA3 et reçoit (D12) un troisième évènement EV3 émis (G12) par le serveur d'applications SA4. On comprend que chaque des évènements EV1, EV2, EV3 (notés collectivement EV) peut être reçu dans un ordre quelconque, avant ou après l'étape de réception D6 de la commande de déclenchement CMD1.
Dans cet exemple, les évènements EV1, EV2 et EV3 contiennent respectivement l'identifiant ID-B1, ID-B2 et ID-B3 de l'utilisateur cible UB dans chacun des réseaux R2, R3 et R4. Comme déjà indiqué, l'utilisateur cible UB dispose d'un identifiant propre pour chaque réseau de communication R2, R3 et R4 dont il est l'usager.
Le chatbot BOTB enregistre chaque évènement EV reçu dans sa mémoire et réalise si besoin tout traitement approprié.
Comme déjà indiqué, le chatbot BOTB contient en mémoire chacun des identifiants ID-B1, ID-B2 et ID-B3 de l'utilisateur cible UB. Le chatbot BOTB détecte ainsi que les évènements EV reçus concernent l'utilisateur UB et enregistre par conséquent ces évènements EV en association avec l'utilisateur cible UB.
Le chatbot BOTB vérifie ensuite en D13 si des évènements EV indicatifs de la disponibilité de l'utilisateur cible UB ont bien été reçus en provenance des réseaux de communications associés à l'utilisateur UB, à savoir les réseaux R2, R3, R4. Pour ce faire, le chatbot BOTB consulte ici sa mémoire et détecte les évènements EV1, EV2 et EV3 enregistrés en association avec l'utilisateur cible UB.
En D14, le chatbot BOTB détermine l'état de disponibilité de l'utilisateur cible UB à partir des évènements EV détectés en association avec l'utilisateur cible UB, et éventuellement à partir des règles de traitement DN1. L'état de disponibilité renseigne sur la capacité courante, et éventuellement future, de l'utilisateur cible UB à recevoir et traiter une nouvelle communication entrante.
Le chatbot BOTB peut en outre prendre en compte en D14 l'identifiant ID-A de l'utilisateur source UA pour déterminer l'état de disponibilité de l'utilisateur cible UB. Il est ainsi possible de personnaliser le traitement de la communication entrante en fonction de l'utilisateur source UA. Des variantes sont toutefois possibles selon lesquelles l'identité de l'utilisateur appelant n'est pas prise en compte par le chatbot BOTB.
Le chatbot BOTB contrôle (D16) ensuite à distance le serveur d'applications SA2 situé dans le réseau R2 pour réaliser un traitement de la requête de communication RQ1 émise par le terminal source TA, ce traitement étant fonction de l'état de disponibilité de l'utilisateur cible UB obtenu en D14. Le chatbot BOTB se comporte ici en tant que maître vis-à-vis du serveur d'applications SA2 qui se comporte comme esclave.
Dans cet exemple, le chatbot BOTB applique en outre en D16 la ou les règles de traitement DN1 pour déterminer, sur la base des évènements EV et éventuellement d'autres paramètres (l'identité ID-A de l'utilisateur source UA, localisation de l'utilisateur UB, date et/ou heure...), comment la communication initiée par l'utilisateur source UA à destination de l'utilisation cible UB doit être traitée. Il est ainsi possible d'adapter à chaque situation la meilleure manière de traiter une nouvelle communication.
Lors de ce contrôle à distance D16, le chatbot BOTB pilote le serveur d'applications SA2 en lui envoyant des commandes (ou instructions) et en traitant des données émises par le serveur d'applications SA2. Cette coopération entre le chatbot BOTB et le serveur d'applications SA2 (via des APIs adaptées) permet d'assurer le traitement automatisé de la communication initiée par l'utilisateur source UA, en conformité le cas échéant avec les règles prédéfinies DN1, et en prenant compte de l'activité de l'utilisateur cible UB sur les différents réseaux de communications R2, R3, R4 dont il est l'usager.
Le serveur d'applications SA2 traite (C16) ainsi, sous le contrôle du chatbot BOTB, la requête RQ1 de communication.
Comme représenté en figure 4, le traitement C16 commandé par le chatbot BOTB comprend par exemple l'établissement d'un dialogue (ou coopération) 20 entre le chatbot BOTB et le terminal TA de l'utilisateur source UA et/ou un dialogue (ou coopération) 30 entre le chatbot BOTB et le chatbot BOTA de l'utilisateur source UA. La ou les entités avec lesquelles le chatbot BOTB décide d'interagir dépend de la configuration de ce dernier et du cas d'espèce. Selon un mode de réalisation particulier, le chatbot BOTB est configuré pour coopérer (20, 30) avec le terminal TA et avec le chatbot BOTA lorsqu'un tel chatbot est disponible pour assister l'utilisateur source UA. Si un tel chatbot BOTA n'est pas disponible, le chatbot BOTB ne coopère qu'avec le terminal TA. Selon une autre variante, le chatbot BOTB n'interagit qu'avec le chatbot BOTA si ce dernier est disponible.
Dans l'exemple considéré, on suppose que le chatbot BOTB décide (D16), sur la base des évènements EV obtenus et des règles de traitement DN1 appliquées, d'interagir avec le terminal TA et avec le chatbot BOTA. Pour ce faire, le chatbot BOTB envoie (D16) par exemple une commande CMD2 comportant l'identifiant ID-A de l'utilisateur source UA dans le réseau RI, l'identifiant ID-B1 de l'utilisateur cible UB dans le réseau R2 et l'identifiant ID-BOTA du chatbot BOTA de l'utilisateur source UA. Le serveur d'applications SA2 reçoit cette commande CMD2 en C18 puis, en réponse à cette commande CMD2, envoie (C20) par exemple un message MSG2 vers le réseau RI. Ce message MSG2 peut être identique à la commande CMD2 ou être obtenu à partir de cette commande CMD2. Dans cet exemple, le message MSG2 comprend également l'identifiant ID-A de l'utilisateur source UA dans le réseau RI, l'identifiant ID-B1 de l'utilisateur cible UB dans le réseau R2 et l'identifiant ID-BOTA du chatbot BOTA de l'utilisateur source UA.
Comme représenté en figure 4, le serveur d'applications SAI reçoit le message MSG2 en B20 et transmet (B22) des messages MSG3 et MSG4 respectivement au terminal TA et au chatbot BOTA. L'utilisateur UA peut ainsi recevoir toute information utile de la part du chatbot BOTB. Le chatbot BOTB peut par exemple indiquer à l'utilisateur source UA, sur son terminal TA, que l'utilisateur cible UB n'est pas disponible et/ou lui indiquer une date et/ou heure à laquelle il sera disponible. Un dialogue peut s'établir si besoin entre le terminal TA et le chatbot BOTB afin de répondre aux éventuelles questions de l'utilisateur source UB ou pour permettre la mise en œuvre d'un service particulier.
Selon un exemple particulier, le chatbot BOTB met en œuvre un service de messagerie vocale qui permet un dialogue ou une interaction 20 entre l'utilisateur source UA et le chatbot BOTB.
Par ailleurs, le chatbot BOTA de l'utilisateur source UA peut également prendre connaissance de la situation à partir du message MSG4 reçu en E22 puis coopérer avec le chatbot BOTB afin de réaliser un traitement approprié. A titre d'exemple, les chatbots BOTA et BOTB peuvent coopérer ensemble pour définir un rendez-vous entre les utilisateurs UA et UB en fonction de leur disponibilité respective, en utilisant par exemple des données d'agenda auxquelles les chatbots BOTA et BOTB ont accès (sous forme d'évènements EV par exemple). Pour ce faire, les chatbots BOTA et BOTB établissent un canal de communication bidirectionnel passant par le serveur d'applications SA2 et par le réseau RI (en passant éventuellement par le serveur d'applications SAI).
De façon générale, le chatbot BOTB communique (D16) avec le terminal TA et/ou avec le chatbot BOTA par l'intermédiaire du réseau R2, et plus particulièrement via le serveur d'applications SA2 dans cet exemple de réalisation. Une relation de confiance existe de préférence entre l'opérateur du réseau R2 et le chatbot BOTB, cette confiance étant par exemple établie à partir d'une authentification du chatbot BOTB réalisée au préalable auprès du réseau R2. En faisant passer les échanges émis par et à destination du chatbot BOTA par le réseau R2, l'utilisateur source UA et son chatbot BOTA ont ainsi la garantie de l'authenticité du chatbot BOTB.
Dans l'exemple considéré ici, lors du traitement C16, le serveur d'applications SA2 assure un échange de données associées à l'utilisateur appelant UA et de données associées à l'utilisateur appelé UB entre l'agent conversationnel automatisé BOTB, d'une part, et le terminal TA et/ou le chatbot BOTA, d'autre part, de sorte à réaliser au moins une action prédéterminée. De façon avantageuse, lors de ce dialogue, le chatbot BOTB propose au moins un service donné à l'utilisateur source UA et/ou au chatbot BOTA, afin par exemple de faciliter la mise en relation actuelle ou future de l'utilisateur source UA avec l'utilisateur cible UB. Dans un exemple particulier, ce dialogue comporte l'envoi par le serveur d'applications SA2, sous le contrôle du chatbot BOTB, d'une proposition d'exécuter au moins un service exécutable par le réseau de communication R2 de l'utilisateur cible UB.
On comprend que diverses configurations sont envisageables dans le cadre de l'invention. Selon un exemple particulier, lors de l'étape D14 de détermination, si l'utilisateur cible UB est déterminé comme n'étant pas disponible, le chatbot BOTB réalise au moins l'une des actions suivantes :
o le chatbot BOTB obtient une donnée de disponibilité renseignant sur l'état de disponibilité (courant et/ou futur) de l'utilisateur cible UB, cette donnée correspondant par exemple à au moins un évènement EV reçu ou cette donnée étant obtenue à partir d'un ou plusieurs évènements EV reçus. Le chatbot BOTB commande alors l'envoi (D16), par le serveur d'applications SA2, de ladite donnée de disponibilité à au moins l'un parmi le terminal TA et l'agent conversationnel automatisé BOTA. L'utilisateur source UA et/ou son chatbot BOTA prennent ainsi connaissance de l'état de disponibilité actuel et/ou futur de l'utilisateur cible UB. La donnée de disponibilité peut indiquer si l'utilisateur cible UB est actuellement disponible ou non, en fonction par exemple du type de communication (appel téléphonique, email, SMS...) considéré. Cette donnée de disponibilité peut comporter un degré de probabilité que l'utilisateur cible UB sera disponible dans un point dans le temps déterminé (dans 10 minutes à compter de l'initiation de l'appel par exemple), ce degré de probabilité étant préalablement déterminé par le chatbot BOTB, par exemple à partir des évènements EV et éventuellement des règles de traitement DN1. De cette manière, l'utilisateur source UA peut recontacter l'utilisateur cible UB à un moment approprié et optimiser ses chances de joindre l'utilisateur cible UB dans de bonnes conditions.
o le chatbot BOTB envoie une notification de communication à un réseau de communication (R3 par exemple) associé à l'utilisateur cible UB, autre que le réseau de communication R2. Cette notification permet d'informer l'utilisateur cible UB de la tentative de communication initiée par le premier terminal TA sur le réseau R2. Cette notification comporte par exemple l'identifiant ID-A de l'utilisateur appelant UA afin d'informer l'utilisateur cible UB de l'identité de l'appelant, ce qui permet à l'utilisateur cible UB de recontacter ultérieurement l'utilisateur source UA si besoin.
o le chatbot BOTB définit, par l'intermédiaire du serveur d'applications SA2, un rendez-vous en coopération avec le premier terminal TA ou avec l'agent conversationnel automatisé BOTA, et le cas échéant il enregistre une nouvelle entrée indicative du rendez-vous dans des données d'agenda associées à l'utilisateur cible UB. Le chatbot BOTB envoie par exemple cette nouvelle entrée d'agenda au serveur d'applications SA4 du réseau R4 pour mettre à jour l'agenda de l'utilisateur cible UB en conséquence. Dans un exemple particulier, le chatbot BOTB envoie vers le réseau R4 à destination de l'utilisateur cible UB une notification relative à ladite nouvelle entrée. L'utilisateur cible UB peut ainsi prendre connaissance, à partir d'un terminal approprié (non représenté) connecté au réseau R4, du nouveau rendez-vous enregistré par son chatbot BOTB.
o le chatbot BOTB détermine un identifiant (par exemple ID-B2 ou ID-B3) de l'utilisateur cible UB dans un réseau de communication (respectivement R2 ou R3) et commande l'envoi, par le serveur d'applications SA2, d'une invitation à destination de l'utilisateur source UA, par exemple sur son terminal TA associé au réseau RI. Cette invitation comporte l'identifiant ID-B2 et/ou ID-B3 de l'utilisateur cible UB afin d'inviter l'utilisateur source UA à contacter l'utilisateur cible UB via le réseau de communication correspondant dont l'utilisateur cible UB est l'usager. L'utilisateur source UA peut ainsi tenter de contacter l'utilisateur cible UB sur un réseau de communication autre que le réseau R2 initialement visé, optimisant ainsi les chances de joindre l'utilisateur cible dans de bonnes conditions.
o Le chatbot BOT surveille l'état de disponibilité courant de l'utilisateur cible UB (à partir des évènements EV reçus) et, sur détection que l'état de disponibilité courant de l'utilisateur cible atteint un état prédéfini (par exemple état « disponible » ou « disponible pour les appels téléphoniques »), le chatbot BOTB commande l'envoi, par le serveur d'applications SA2, d'une notification informant de l'état prédéfini à destination de l'utilisateur source UA, par exemple sur son terminal TA. De cette manière, l'utilisateur source UA est informé dès que l'utilisateur cible UB est disponible, et éventuellement sous quelle condition il est disponible (type de communication acceptée etc.), ce qui permet de faciliter la mise en communications des deux parties.
Parmi les actions possibles, le chatbot BOTB peut également causer l'envoi, par le serveur d'applications SA2, à destination de l'utilisateur source UA, d'un ou d'une pluralité d'actions prédéfinies parmi lesquelles l'utilisateur source UA pourra choisir en fonction du cas d'espèce. Chaque action prédéfinie (ou option) proposée par le chatbot BOTB permet de faciliter les interactions entre les utilisateurs UA et UB. Ces propositions peuvent comporter au moins l'une quelconque parmi les exemples d'action décrits ci-avant (définition d'un rendez-vous, surveillance de l'état de disponibilité de l'utilisateur cible UB etc.). Ces propositions d'actions prédéfinies peuvent être adaptées par le chatbot BOTB en fonction de divers critères tels que par exemple l'identité de l'utilisateur source UA, afin de personnaliser le traitement la communication.
Selon une variante de réalisation, le chatbot BOTB ne prend pas en compte l'identité de l'utilisateur source UA pour déterminer en D14 l'état de disponibilité de l'utilisateur source UB et/ou pour déterminer en D16 le traitement à appliquer. Tel est le cas par exemple lorsque l'identifiant ID-A de l'utilisateur source UA n'est pas renseigné (communication anonyme) dans la requête RQ1 de communication envoyée en A2 (figures 1 et 4).
Par ailleurs, comme déjà indiqué, l'invention s'applique à divers types de communication, de type texte, vocale, vidéo par exemple. Lorsque la communication initiée par un utilisateur source est un appel téléphonique par exemple, cette tentative de communication peut viser un terminal particulier de l'utilisateur cible. Des variantes sont toutefois possibles selon lesquelles la tentative de communication initiée par l'utilisateur source vise une identité d'un utilisateur cible qui est indépendante d'un terminal donné. Ainsi, selon un mode de réalisation particulier, la communication initiée par l'utilisateur source UA en A2 est par exemple un message de type email, qui vise une identité d'un destinataire, cette identité étant indépendante du terminal pouvant être utilisé par l'utilisateur cible UB. Dans ce cas particulier, le serveur d'applications SA2 reçoit l'email en C4 puis demande en C6 au chatbot BOTB de traiter cet email (D7-D16) de façon analogue à celle décrite ci-avant en référence à un appel vocal. L'invention permet ainsi à l'utilisateur UA à l'origine de l'email d'être informé de l'indisponibilité courante du destinataire UB, d'un autre moyen de communication qu'il est invité à utiliser pour joindre le destinataire UB et/ou encore, un autre moment plus approprié pour contacter le destinataire UB. Si le chatbot BOTA est mis en œuvre, ce dernier est aussi en mesure de coopérer avec le chatbot BOTA pour offrir des services à l'utilisateur UA et/ou à l'utilisateur UB.
La présente invention permet de faciliter la mise en relation de deux utilisateurs (voire plus de deux utilisateurs). Une communication initiée par un utilisateur appelant peut être traitée en temps réel par l'agent conversationnel automatisé de l'utilisateur cible afin d'optimiser les chances pour l'utilisateur appelant de rentrer en contact avec l'utilisateur appelé, et ce dans les meilleurs conditions possibles. Un utilisateur appelant est ainsi moins susceptible d'hésiter à contacter un tiers dans la mesure où l'appel sera traité selon les souhaits prédéfinis du tiers. L'agent conversationnel automatisé de l'utilisateur cible peut fournir toutes les informations nécessaires à l'utilisateur appelant sous la forme d'une notification simple, ou sous la forme d'un dialogue interactif. En particulier, selon le paramétrage choisi, l'agent conversationnel automatisé de l'utilisateur cible pourra inviter l'utilisateur appelant à tenter une nouvelle communication à un moment particulier, à tenter une communication via un autre réseau de communication ou à destination d'un autre identifiant.
De manière générale, divers services peuvent être mis en œuvre par les chatbots BOTA et BOTB coopérant ensemble, ou alternativement par le chatbot BOTB sans l'intervention du chatbot BOTA. Les chatbots BOTA et BOTB peuvent par exemple dialoguer ensemble pour définir un rendez-vous, réserver une ressource quelconque (achat ticket de transport, réservation d'une salle de réunion ou d'une place à un évènement etc.) et prévenir chacun leur utilisateur respectif des dispositions qui ont été prises, éventuellement sous réserve de validation de la part des utilisateurs concernés.
Dans un exemple particulier, le chatbot BOTB, et éventuellement le chatbot BOTA lorsque celui-ci est mis en œuvre, s'appuie sur une intelligence artificielle pour prendre des décisions et traiter chaque communication de la façon la plus appropriée. Le chatbot BOTB par exemple peut apprendre au cours du temps la meilleure manière de traiter chaque situation donnée et ainsi adapter en conséquence son comportement à une situation ultérieure.
Par ailleurs, on notera que la mise en œuvre d'une synthèse vocale et/ou d'une reconnaissance vocale sont possibles pour permettre un dialogue aisé entre l'utilisateur source UA et le chatbot BOTB de l'utilisateur cible UB.
Dans un premier exemple de réalisation, la communication initiée par l'utilisateur source UA est de type vocale et, lors dudit contrôle à distance D16 (figure 4), l'agent conversationnel automatisé BOTB commande au serveur d'applications SA1 la réalisation d'une synthèse vocale à partir de données texte, et la réalisation d'une reconnaissance vocale de données vocales reçues par le serveur d'applications SA1 depuis le premier terminal TA. Autrement dit, dans ce premier cas, c'est le serveur d'applications SA2 qui se charge de faire le traitement sur la voix, en réalisant la synthèse vocale pour générer de la voix à l'attention de l'utilisateur cible et pour reconnaître la voix émise par l'utilisateur source UA.
Selon un deuxième exemple de réalisation, la communication initiée par l'utilisateur source UA est de type vocale et, lors dudit contrôle à distance D16 (figure 4), l'agent conversationnel automatisé BOTB envoie au serveur d'applications SA2 des données vocales (générées par BOTB) pour transmission au terminal source TA, et réalise une reconnaissance vocale de données vocales reçues depuis le terminal source TA via le serveur d'applications SA2. Autrement dit, dans ce deuxième cas, c'est le chatbot BOTB qui se charge de faire le traitement sur la voix, en réalisant la synthèse vocale pour générer de la voix à l'attention de l'utilisateur cible et pour reconnaître la voix émise par l'utilisateur source UA.
Quel que soit le mode de réalisation considéré, le chatbot BOTB de l'utilisateur cible UB peut être configuré pour adapter la langue de dialogue en fonction l'utilisateur source UA, par exemple en tenant compte de l'identifiant ID-A du terminal TA.
2J
Par ailleurs, selon une variante du mode de réalisation représenté en figure 4, le chatbot BOTB est configuré pour vérifier via le serveur d'applications SA2 si l'utilisateur cible UB est actuellement disponible sur son terminal TB1 en réponse à la requête RQ1 de communication émise par le terminal source TA. Pour ce faire, le chatbot BOTB envoie une commande au serveur d'applications SA2 visant à établir, en réponse à ladite requête RQ1 de communication, une communication entre les terminaux TA et TB1. Sur réception de cette commande, le serveur SA2 tente d'établir ladite communication. Le chatbot BOTB déclenche en outre un décompte de temps à compter de l'envoi de ladite commande visant à établir une communication entre les terminaux TA et TB1. En l'absence de réponse positive du terminal TB1 de l'utilisateur cible UB (par exemple, l'utilisateur cible UB décroche son téléphone) après un délai prédéfini (30 secondes par exemple), le chatbot BOTB détermine (D14) alors que l'utilisateur cible UB n'est pas actuellement disponible. Le chatbot BOTB peut alors déterminer (D14) la disponibilité future de l'utilisateur cible UB à partir du ou des évènements EV reçus (D7) et piloter (D16) le serveur d'applications SA2 comme déjà expliqué en référence à la figure 4.
Selon une variante du mode de réalisation représenté en Figure 4, le chatbot BOTB de l'utilisateur cible UB détermine en D16 un niveau d'urgence de la requête RQ1 de communication à partir de l'identifiant ID-B1 de l'utilisateur source. Ce niveau d'urgence peut est déterminé à partir des règles de traitement DN1 (figure 1), en prenant compte divers critères prédéfinis (la date/l'heure, le réseau ou le terminal sur lequel l'utilisateur cible est contacté etc.). Si le niveau d'urgence atteint un niveau prédéfini (par exemple un niveau 3 d'urgence sur une échelle de 5), le chatbot BOTB cause l'envoi d'une notification d'urgence à l'attention de l'utilisateur cible UB via le réseau de communications R2 (par l'intermédiaire du serveur d'applications SA2), ou via l'un parmi les autres réseaux R3, R4 de l'utilisateur cible UB. L'utilisateur cible UB peut ainsi juger de l'importance d'une communication entrante et traiter en priorité les communications qu'il juge importante.
Un homme du métier comprendra que les modes de réalisation et variantes décrits ciavant ne constituent que des exemples non limitatifs de mise en œuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un besoin bien particulier.
Claims (15)
- REVENDICATIONS1. Procédé de traitement d'une communication, mis en œuvre par un premier serveur d'applications (SA2), comprenant les étapes suivantes :réception (C4) d'une requête (RQ1) de communication provenant d'un premier terminal (TA) d'un utilisateur appelant (UA), ladite requête visant à établir une communication avec un deuxième terminal (TB1) d'un utilisateur cible (UB), le premier serveur d'applications (SA1) étant compris dans un réseau de communication (R2) associé au deuxième terminal (TB1) ;envoi (C6), à un premier agent conversationnel automatisé (BOTB) associé à l'utilisateur cible (UB), d'une commande de déclenchement (CMD1) pour activer ledit premier agent conversationnel automatisé, ce dernier étant situé hors du réseau de communication (R2) du deuxième terminal (TB1) ; et traitement (C16), sous le contrôle du premier agent conversationnel automatisé (BOTB), de la requête de communication (RQ1), ledit traitement comprenant ('établissement d'un dialogue entre le premier agent conversationnel automatisé (BOTB) et au moins l'un parmi le premier terminal (TA) et un deuxième agent conversationnel automatisé (BOTA) associé à l'utilisateur appelant (UA).
- 2. Procédé selon la revendication 1, comprenant un envoi (C8), au premier agent conversationnel automatisé (BOTB), d'au moins un évènement (EV1) indicatif de la disponibilité de l'utilisateur cible (UB) afin de permettre audit premier agent conversationnel automatisé (BOTB) d'adapter ledit traitement en fonction dudit évènement.
- 3. Procédé selon la revendication 1 ou 2, comprenant un envoi (C6), au premier agent conversationnel automatisé (BOTB), d'un identifiant (ID-A) de l'utilisateur appelant (UA) inclus dans la requête (RQ1) de communication afin de permettre audit premier agent conversationnel automatisé (BOTB) d'adapter ledit traitement en fonction de l'utilisateur appelant.
- 4. Procédé selon l'une quelconque des revendications 1 à 3, comprenant une réception (C4) d'un identifiant (ID-BOTA) du deuxième agent conversationnel automatisé (BOTA) associé à l'utilisateur appelant (UA), ledit traitement comprenant l'établissement d'une communication entre les premier et deuxième agents conversationnels automatisés (BOTB, BOTA) afin de traiter collectivement ladite requête (RQ1) de communication.
- 5. Procédé de traitement d'une communication, mis en œuvre par un premier agent conversationnel automatisé (BOTB), comprenant les étapes suivantes :réception d'une commande de déclenchement (CMD1) provenant d'un serveur d'applications (SA1), pour traiter une requête (RQ1) de communication provenant d'un premier terminal (TA) d'un utilisateur source (UA) visant à établir une communication avec un deuxième terminal (TB1) d'un utilisateur cible (UB), ledit serveur d'applications (SA1) étant compris dans un réseau de communication (R2) associé au deuxième terminal (TB1) et ledit premier agent conversationnel automatisé (BOTB) étant situé hors dudit réseau de communication (R2) ;vérification que des évènements indicatifs de la disponibilité de l'utilisateur cible ont été reçus en provenance du réseau de communication (R2) du deuxième terminal (TB1) et en provenance d'au moins un autre réseau de communication (R3) associé à l'utilisateur cible ;détermination de l'état de disponibilité du deuxième utilisateur à partir d'au moins un dit évènement reçu ; et contrôle à distance du serveur d'applications (SA2) pour réaliser un traitement de la requête de communication (RQ1) en fonction de l'état de disponibilité de l'utilisateur cible.
- 6. Procédé selon la revendication 5, comprenant une réception d'une pluralité de dits évènements indicatifs de la disponibilité de l'utilisateur cible, en provenance du réseau de communication (R2) du deuxième terminal (TB1) et en provenance dudit au moins un autre réseau de communication (R3) associé à l'utilisateur cible.
- 7. Procédé selon la revendication 5 ou 6, le traitement comprenant l'établissement d'un dialogue entre le premier agent conversationnel automatisé (BOTB) et au moins l'un parmi le premier terminal (TA) et un deuxième agent conversationnel automatisé (BOTB) associé à l'utilisateur appelant (UA).
- 8. Procédé selon l'une quelconque des revendications 5 à 7, dans lequel lors de l'étape de détermination, si l'utilisateur cible est déterminé comme n'étant pas disponible, le premier agent conversationnel automatisé (BOTB) réalise au moins l'une des actions suivantes :- obtention d'une donnée de disponibilité renseignant sur l'état de disponibilité de l'utilisateur cible (UB) et commande d'envoi, par le serveur d'applications (SA2), de ladite donnée de disponibilité à au moins l'un parmi le premier terminal (TA) et le deuxième agent conversationnel automatisé (BOTB) ;- envoi d'une notification de communication audit au moins un autre réseau de communication (R3) associé à l'utilisateur cible, ladite notification de communication informant de la tentative de communication initiée par le premier terminal (TA) ;- définition, par l'intermédiaire du serveur d'applications (SA2), d'un rendez-vous en coopération avec le premier terminal (TA) ou le deuxième agent conversationnel automatisé (BOTA), et enregistrement d'une nouvelle entrée indicative du rendezvous dans des données d'agenda associées à l'utilisateur cible ;- détermination d'un identifiant de l'utilisateur cible dans ledit au moins un autre réseau de communication (R3) et commande d'envoi, par le serveur d'applications (SA2), d'une invitation comportant ledit identifiant pour inviter l'utilisateur appelant à contacter l'utilisateur cible via ledit au moins un autre réseau de communication ; et- surveillance de l'état de disponibilité courant de l'utilisateur cible et, sur détection que l'état de disponibilité courant du deuxième utilisateur atteint un état prédéfini, commande d'envoi, par le serveur d'applications (SA2), d'une notification informant de l'état prédéfini à l'attention de l'utilisateur appelant.
- 9. Procédé selon l'une quelconque des revendications 5 à 8, comprenant une réception, en provenance du serveur d'applications (SA2), d'un identifiant (ID-A) de l'utilisateur appelant (UA), ledit traitement causé par le premier agent conversationnel automatisé (BOTB) lors du contrôle à distance étant fonction dudit identifiant de l'utilisateur appelant.
- 10. Procédé selon la revendication 9, comprenant une détermination d'un niveau d'urgence de la requête (RQ1) de communication à partir de l'identifiant (ID-A) de l'utilisateur appelant (UA) ; et si le niveau d'urgence atteint un niveau prédéfini, le premier agent conversationnel automatisé (BOTB) cause l'envoi, par le serveur d'applications (SA2), d'une notification d'urgence à l'attention de l'utilisateur cible (UB) via le réseau de communications (R2) ou via ledit au moins un autre réseau de communications (R3).
- 11. Procédé selon l'une quelconque des revendications 5 à 10, comprenant une réception, en provenance du serveur d'applications (SA1), d'un identifiant (IDBOTA) du deuxième agent conversationnel automatisé (BOTA) associé à l'utilisateur appelant (UA), ladite étape de contrôlé à distance comprenant l'établissement d'une communication entre les premier et deuxième agents conversationnels automatisés (BOTB, BOTA) via le serveur d'applications (SA2) afin de traiter collectivement ladite requête (RQ1) de communication.
- 12. Procédé selon la revendication 11, dans lequel, lors dudit contrôle à distance, les premier et deuxième agents conversationnels automatisés (BOTB, BOTA) échangent, via ie serveur d'applications (SA2), des données associées aux utilisateurs appelant et cible de sorte à réaliser collectivement au moins une action prédéterminée.
- 13. Programme d'ordinateur (PG2 ; PG3) comportant des instructions pour l'exécution des étapes d'un procédé selon l'une quelconque des revendications 1 à 12 lorsque ledit programme est exécuté par un ordinateur.
- 14. Serveur d'applications (SA2) comprenant :un module de réception (MD2) configuré pour recevoir une requête (RQ1) de communication provenant d'un premier terminal (TA) d'un utilisateur appelant (UA), ladite requête visant à établir une communication avec un deuxième terminal (TB1) d'un utilisateur cible (UB), le premier serveur d'applications (SA1) étant compris dans un réseau de communication (R2) associé au deuxième terminal (TB1) ;un module d'envoi (MD4) configuré pour envoyer, à un premier agent conversationnel automatisé (BOTB) associé à l'utilisateur cible (UB), une commande de déclenchement (CMD1) pour activer ledit premier agent conversationnel automatisé, ce dernier étant situé hors du réseau de communication (R2) du deuxième terminal (TB1) ; et un module de traitement (MD6) configuré pour réaliser un traitement de la requête de communication (RQ1) sous le contrôle du premier agent conversationnel automatisé (BOTB), ledit traitement comprenant l'établissement d'un dialogue entre le premier agent conversationnel automatisé (BOTB) et au moins l'un parmi le premier terminal (TA) et un deuxième agent conversationnel automatisé (BOTA) associé à l'utilisateur appelant (UA).
- 15. Agent conversationnel automatisé (BOTB) comprenant :un module de réception (MD10) configuré pour recevoir une commande de déclenchement (CMD1) provenant d'un serveur d'applications (SA1), pour traiter une requête (RQ1) de communication provenant d'un premier terminal (TA) d'un utilisateur appelant (UA) visant à établir une communication avec un deuxième terminal (TB1) d'un utilisateur cible (UB), ledit serveur d'applications (SA2) étant compris dans un réseau de communication (R2) associé au deuxième terminal (TB1) et ledit agent conversationnel automatisé (BOTB) étant situé hors dudit réseau de communication (R2) ;un module de vérification (MD12) configuré pour vérifier si des évènements indicatifs de la disponibilité de rutilisateur cible ont été reçus en provenance du réseau de communication (R2) du deuxième terminal (TB1) et en provenance d'au moins un autre réseau de communication (R3) associé à l'utilisateur cible ; un module de détermination (MD14) configuré pour déterminer l'état de disponibilité du deuxième utilisateur à partir d'au moins un dit évènement reçu ; et un module de contrôle (MD16) configuré pour contrôler à distance le serveur d'applications (SA2) de sorte à réaliser un traitement de la requête de communication (RQ1) en fonction de l'état de disponibilité de l'utilisateur cible.1/3
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1662018A FR3059862B1 (fr) | 2016-12-06 | 2016-12-06 | Traitement d'une communication par un agent conversationnel automatise |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1662018A FR3059862B1 (fr) | 2016-12-06 | 2016-12-06 | Traitement d'une communication par un agent conversationnel automatise |
| FR1662018 | 2016-12-06 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3059862A1 true FR3059862A1 (fr) | 2018-06-08 |
| FR3059862B1 FR3059862B1 (fr) | 2019-07-26 |
Family
ID=57796717
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1662018A Active FR3059862B1 (fr) | 2016-12-06 | 2016-12-06 | Traitement d'une communication par un agent conversationnel automatise |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3059862B1 (fr) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008039253A1 (fr) * | 2006-09-29 | 2008-04-03 | Siemens Communications, Inc. | Assistant rendez-vous réalisant un filtrage d'appels et fournissant des informations de disponibilité personnalisées |
| US20080147793A1 (en) * | 2006-10-31 | 2008-06-19 | Singh Munindar P | Method And System For Coordinating A Synchronous Activity |
-
2016
- 2016-12-06 FR FR1662018A patent/FR3059862B1/fr active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008039253A1 (fr) * | 2006-09-29 | 2008-04-03 | Siemens Communications, Inc. | Assistant rendez-vous réalisant un filtrage d'appels et fournissant des informations de disponibilité personnalisées |
| US20080147793A1 (en) * | 2006-10-31 | 2008-06-19 | Singh Munindar P | Method And System For Coordinating A Synchronous Activity |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3059862B1 (fr) | 2019-07-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9888125B2 (en) | Systems and methods for managing an event scheduling request in a telephony system | |
| US20120121077A1 (en) | System and method for brokering communication dependent tasks | |
| EP2504986B1 (fr) | Selection d'un mode de communication | |
| US20160309032A1 (en) | Enhancing call experiences through personal rules | |
| FR2931330A1 (fr) | Procede et systeme d'enregistrement automatique d'une session de communication | |
| EP3182671B1 (fr) | Procédé et dispositif pour un service de messagerie | |
| EP1509031A1 (fr) | Système et procédé d'acheminement intelligent des appels téléphoniques | |
| FR3059862B1 (fr) | Traitement d'une communication par un agent conversationnel automatise | |
| EP2487864A1 (fr) | Procédé et dispositif de gestion dynamique de la priorité de réception d'une communication d'un terminal | |
| EP3024182B1 (fr) | Procédé et dispositif de gestion d'un message | |
| WO2013076420A1 (fr) | Procede de gestion de la mise en relation numerique | |
| FR2888706A1 (fr) | Procede de mise en relation interpersonelle | |
| EP3688974B1 (fr) | Procédé de gestion d'un échec d'établissement d'une communication entre un premier et un second terminal | |
| EP3800874A1 (fr) | Procédé et dispositif de redirection d'une requête de communication | |
| CN113452829A (zh) | 基于用户存在和偏好的语音消息的实时转录和馈送 | |
| EP3013024B1 (fr) | Procédé de redirection d'une communication vers au moins un serveur de dépôt de messages | |
| US20230308546A1 (en) | System and methods for hybrid callback management using a callback cloud with call participant authentication | |
| EP2403214A1 (fr) | Procédé de mise en oeuvre de services dans un réseau de telecommunications | |
| FR2952262A1 (fr) | Autorisation d'etablissement d'appels simultanes | |
| EP4173274A1 (fr) | Procédé et serveur de traitement d'appels en provenance de terminaux d'utilisateurs pour la mise en relation avec des terminaux d'opérateurs | |
| EP4173273A1 (fr) | Procédé de traitement d'une requête provenant d'un terminal de communication | |
| EP2138966B1 (fr) | Récupération d'une information relative à une communciation téléphonique depuis un terminal téléphonique via un serveur de communication | |
| EP4191989A2 (fr) | Procédé de gestion d'un numéro de téléphone non attribué dans un réseau de communication, procédé de traitement d'une demande d attribution d'un numéro de téléphone, dispositifs, équipement de communication, système et programmes d ordinateur correspondants | |
| EP3804253A1 (fr) | Procédé de mise à jour d'une base de données d'un réseau de voix sur ip | |
| FR2897497A1 (fr) | Dispositif et procede de controle de communications, en vue de l'etablissement automatique d'une communication de messagerie instantanee lors d'une mise en attente en cours de communication telephonique ou multimedia |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20180608 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |
|
| PLFP | Fee payment |
Year of fee payment: 8 |