FR3059862B1 - Traitement d'une communication par un agent conversationnel automatise - Google Patents

Traitement d'une communication par un agent conversationnel automatise Download PDF

Info

Publication number
FR3059862B1
FR3059862B1 FR1662018A FR1662018A FR3059862B1 FR 3059862 B1 FR3059862 B1 FR 3059862B1 FR 1662018 A FR1662018 A FR 1662018A FR 1662018 A FR1662018 A FR 1662018A FR 3059862 B1 FR3059862 B1 FR 3059862B1
Authority
FR
France
Prior art keywords
communication
user
botb
target user
automated conversational
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.)
Active
Application number
FR1662018A
Other languages
English (en)
Other versions
FR3059862A1 (fr
Inventor
Miguel Labranche
Juan Pascual
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1662018A priority Critical patent/FR3059862B1/fr
Publication of FR3059862A1 publication Critical patent/FR3059862A1/fr
Application granted granted Critical
Publication of FR3059862B1 publication Critical patent/FR3059862B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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

Arrière-plan de l'invention L’invention se rapporte au domaine des télécommunications et porte plusparticulièrement le traitement d'une tentative de communication entre plusieurs individus.
De nombreuses solutions de télécommunications sont aujourd'hui à disposition pourpermettre l'établissement d'une communication entre deux personnes. Divers types deréseaux de communications (3G, 4G etc.) ont été déployés ces dernières années par lesopérateurs pour offrir des services de communications adaptés aux besoins de leursabonnés. Pour joindre un tiers, un utilisateur peut aujourd'hui faire usage d'unquelconque terminal afin d'établir une communication écrite ou orale, en effectuant parexemple un appel téléphonique ou en envoyant un message de type SMS, email, messagevia une messagerie instantanée...
La mise en relation entre l'appelant, à l'origine de la tentative de communication, etl'appelé, destinataire de cette communication, n'est toutefois pas toujours aisée. Latentative de communication initiée par l'appelant est susceptible d'échouer sans qu'il n'enconnaisse la raison, par exemple parce que l'utilisateur appelé n'est pas disponible. Cetaléa quant aux chances de succès d'une mise en relation entre deux terminaux peut poserproblème et décourage parfois l'utilisateur appelant de tenter cette communication enpremier 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'unecommunication, 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'unutilisateur appelant, ladite requête visant à établir une communication avec undeuxième terminal d'un utilisateur cible, le premier serveur d'applications étantcompris 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 decommunication du deuxième terminal ; et traitement, sous le contrôle du premier agent conversationnel automatisé, de larequête de communication, ledit traitement comprenant l'établissement d'undialogue entre le premier agent conversationnel automatisé et au moins l'unparmi 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 ouplus. Une communication initiée par un utilisateur source peut être traitée en temps réelpar l'agent conversationnel automatisé de l'utilisateur cible afin d'optimiser les chancespour 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 souhaitsprédéfinis du tiers. L'agent conversationnel automatisé de l'utilisateur cible peut fournirtoutes les informations nécessaires à l'utilisateur source sous la forme d'une notificationsimple, ou sous la forme d'un dialogue interactif par exemple. L'agent conversationnelautomatisé de l'utilisateur cible peut par exemple indiquer à l'utilisateur source, sur sonterminal, 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 leterminal de l'utilisateur source et l'agent conversationnel automatisé de l'utilisateur cibleafin de répondre aux éventuelles questions de l'utilisateur source ou pour permettre lamise en œuvre d'un service particulier.
Selon le paramétrage choisi, l'agent conversationnel automatisé de l'utilisateur ciblepeut inviter l'utilisateur source à réitérer sa tentative de communication à un momentopportun, via le même réseau de communication de l'utilisateur cible ou via un autreréseau de communication utilisé par l'utilisateur cible. L'agent conversationnel automatisé de l'utilisateur cible est positionné à l'extérieur dechacun des réseaux de communications associés à l'utilisateur cible, ce qui permet à cedernier de recevoir de façon centralisée les évènements émis par chacun des réseaux decommunications associé à l'utilisateur cible. Cette disposition permet en outre à l'agentconversationnel automatisé de l'utilisateur cible de piloter à distance le serveurd'applications situé dans le réseau de l'utilisateur cible et, le cas échéant chacun desautres serveurs d'applications associés à l'utilisateur cible, afin de traiter une quelconquecommunication entrant à destination de l'utilisateur cible.
Selon un mode de réalisation particulier, le premier procédé de traitement comprendun envoi, au premier agent conversationnel automatisé, d'au moins un évènementindicatif de la disponibilité de l'utilisateur cible afin de permettre audit premier agent conversationnel automatisé d'adapter ledit traitement en fonction dudit évènement. Defaçon avantageuse, cela permet à l'agent conversationnel automatisé de l'utilisateur ciblede 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 cesinformations, l'agent conversationnel automatisé de l'utilisateur cible peut en déduire parexemple si l'utilisateur cible est actuellement disponible, ou sera disponible dans un futurplus ou moins proche (à définir), pour communiquer avec l'utilisateur source.
Selon un mode de réalisation particulier, le premier procédé de traitement comprendun envoi, au premier agent conversationnel automatisé, d'un identifiant de l'utilisateurappelant inclus dans la requête de communication afin de permettre audit premier agentconversationnel automatisé d'adapter ledit traitement en fonction de l'utilisateur appelant.Il est ainsi possible de personnaliser le traitement de la communication entrante enfonction de l'identité de l'utilisateur source.
Selon un mode de réalisation particulier, le premier procédé de traitement comprendune réception d'un identifiant du deuxième agent conversationnel automatisé associé àl'utilisateur appelant, ledit traitement comprenant l'établissement d'une communicationentre les premier et deuxième agents conversationnels automatisés afin de traitercollectivement ladite requête de communication. De cette manière, l'agentconversationnel automatisé de l'utilisateur cible est capable de rentrer en contact avecl'agent conversationnel automatisé de l'utilisateur source de sorte à ce qu'une coopérations'effectue entre les deux agents conversationnel automatisés. Cette coopération permetde traiter de façon optimale la communication, facilitant ainsi la mise en relation des deuxutilisateurs concernés. Un service peut notamment être mis en oeuvre lors de cettecoopération.
Dans un mode particulier de réalisation, les différentes étapes du premier procédé detraitement sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un supportd'informations, ce programme étant susceptible d'être mis en œuvre dans un dispositif telqu'un serveur, ou plus généralement dans un ordinateur, ce programme comportant desinstructions adaptées à la mise en œuvre des étapes d’un premier procédé de traitementtel que définis ci-dessus. L'invention vise aussi un support d'enregistrement (ou support d’informations) lisiblepar un ordinateur, et comportant des instructions d’un programme d’ordinateur tel quementionné ci-dessus.
La présente invention concerne également un deuxième procédé de traitement d'unecommunication, mis en œuvre par un premier agent conversationnel automatisé,comprenant les étapes suivantes : réception d'une commande de déclenchement provenant d'un serveurd'applications, pour traiter une requête de communication provenant d'unpremier terminal d'un utilisateur source visant à établir une communication avecun deuxième terminal d'un utilisateur cible, ledit serveur d'applications étant compris dans un réseau de communicationassocié 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 cibleont été reçus en provenance du réseau de communication du deuxième terminalet 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'aumoins un dit évènement reçu ; et contrôle à distance du serveur d'applications pour réaliser un traitement de larequête de communication en fonction de l'état de disponibilité de l'utilisateurcible.
La présente invention permet de faciliter la mise en relation de deux personnes ouplus. Une communication initiée par un utilisateur source peut être traitée en temps réelpar l'agent conversationnel automatisé de l'utilisateur cible afin d'optimiser les chancespour 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çonanalogue au deuxième procédé de traitement de l'invention.
Selon un mode de réalisation particulier, le deuxième procédé de traitementcomprend une réception d'une pluralité de dits évènements indicatifs de la disponibilité del'utilisateur cible, en provenance du réseau de communication du deuxième terminal et enprovenance 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 traitementcomprend l'établissement d'un dialogue entre le premier agent conversationnelautomatisé et au moins l'un parmi le premier terminal et un deuxième agentconversationnel automatisé associé à l'utilisateur appelant. De cette manière, l'agentconversationnel automatisé peut traiter de façon interactive la communication avecl'utilisateur source ou son agent conversationnelle automatisé, et ainsi répondre de façonadaptée à chaque cas d'espèce.
Selon un mode de réalisation particulier, lors de l'étape de détermination dudeuxiè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 actionsdéfinies ci-après. - selon une première action, le premier agent conversationnel automatisé obtientune donnée de disponibilité renseignant sur l'état de disponibilité de l'utilisateurcible et commande l'envoi, par le serveur d'applications, de ladite donnée dedisponibilité à au moins l'un parmi le premier terminal et le deuxième agentconversationnel automatisé. De cette manière, l'utilisateur source peut recontacterl'utilisateur cible à un moment approprié et optimiser ses chances de joindrel'utilisateur cible dans de bonnes conditions ; - selon une deuxième action, le premier agent conversationnel automatisé envoieune notification de communication audit au moins un autre réseau decommunication associé à l'utilisateur cible, ladite notification de communicationinformant de la tentative de communication initiée par le premier terminal. L'envoide cette notification permet d'informer l'utilisateur cible de la tentative decommunication 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 afind'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 avecle premier terminal ou le deuxième agent conversationnel automatisé, etenregistre une nouvelle entrée indicative du rendez-vous dans des donnéesd'agenda associées à l'utilisateur cible. L'utilisateur cible peut ainsi prendreconnaissance, par l'intermédiaire d'un réseau de communication autre que leréseau initialement visé, du nouveau rendez-vous enregistré par son agentconversationnel 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éseaude communication et commande l'envoi, par le serveur d'applications, d'uneinvitation comportant ledit identifiant pour inviter l'utilisateur appelant à contacterl'utilisateur cible via ledit au moins un autre réseau de communication. L'utilisateursource peut ainsi tenter de contacter l'utilisateur cible sur un réseau decommunication autre que le réseau initialement visé, optimisant ainsi les chancesde joindre l'utilisateur cible dans de bonnes conditions ; - selon une cinquième action, le premier agent conversationnel automatisé surveillel'état de disponibilité courant de l'utilisateur cible et, sur détection que l'état dedisponibilité 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 estinformé dès que l'utilisateur cible est disponible, et éventuellement sous quellecondition il est disponible (type de communication acceptée etc.), ce qui permetde faciliter la mise en communications des deux parties.
Selon un mode de réalisation particulier, le deuxième procédé de traitementcomprend une réception, en provenance du serveur d'applications, d'un identifiant del'utilisateur appelant, ledit traitement causé par le premier agent conversationnelautomatisé lors du contrôle à distance étant fonction dudit identifiant de l'utilisateurappelant. Il est ainsi possible pour le premier agent conversationnel automatisé depersonnaliser le traitement de chaque communication initié à l'attention de l'utilisateurcible.
Selon un mode de réalisation particulier, le deuxième procédé de traitementcomprend 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 conversationnelautomatisé 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 unautre réseau de communications. L'utilisateur cible peut ainsi juger de l'importance d'unecommunication entrante et traiter en priorité les communications qu'il juge importante.
Selon un mode de réalisation particulier, le deuxième procédé de traitementcomprend 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 etdeuxième terminaux ; - déclenchement d'un décompte de temps à compter de l'envoi de la commandevisant à é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 estactuellement disponible ou non et rentrer si besoin en communication avec l'utilisateursource et/ou l'agent conversationnel automatisé de ce dernier afin de traiter au mieux lacommunication.
Selon un mode de réalisation particulier, le deuxième procédé de traitementcomprend une réception, en provenance du serveur d'applications, d'un identifiant dudeuxième agent conversationnel automatisé associé à l'utilisateur appelant, ladite étapede 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 detraiter collectivement ladite requête de communication. De cette manière, l'agentconversationnel automatisé de l'utilisateur cible peut coopérer de façon interactive avecl'agent conversationnel automatisé de l'utilisateur source, de sorte à ce qu'ensemble ilsré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 etdeuxiè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 collectivementau moins une action prédéterminée. Les agents conversationnels automatisés peuventainsi mettre en œuvre au moins un service permettant par exemple de faciliter la mise enrelation 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 supportd'informations, ce programme étant susceptible d'être mis en œuvre dans un dispositif telqu'un serveur, ou plus généralement dans un ordinateur, ce programme comportant desinstructions adaptées à la mise en œuvre des étapes d'un deuxième procédé detraitement tel que définis ci-dessus. L'invention vise aussi un support d'enregistrement (ou support d'informations) lisiblepar un ordinateur, et comportant des instructions d'un programme d'ordinateur tel quementionné ci-dessus. A noter que les programmes mentionnés dans le présent exposé peuvent utilisern'importe quel langage de programmation, et être sous la forme de code source, codeobjet, ou de code intermédiaire entre code source et code objet, tel que dans une formepartiellement compilée, ou dans n'importe quelle autre forme souhaitable.
De plus, les supports d'enregistrement mentionnés ci-avant peuvent être n'importequelle entité ou dispositif capable de stocker le programme. Par exemple, le support peutcomporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROMde circuit microélectronique, ou encore un moyen d'enregistrement magnétique, parexemple une disquette (floppy dise) ou un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un supporttransmissible 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'inventionpeut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, les supports d'enregistrement peuvent correspondre à un circuitintégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter oupour ê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 communicationprovenant d'un premier terminal d'un utilisateur appelant, ladite requête visant àétablir une communication avec un deuxième terminal d'un utilisateur cible, lepremier serveur d'applications étant compris dans un réseau de communicationassocié au deuxième terminal ; un module d'envoi configuré pour envoyer, à un premier agent conversationnelautomatisé associé à l'utilisateur cible, une commande de déclenchement pouractiver 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 decommunication sous le contrôle du premier agent conversationnel automatisé,ledit traitement comprenant l'établissement d'un dialogue entre le premier agentconversationnel automatisé et au moins l'un parmi le premier terminal et undeuxiè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 dedéclenchement provenant d'un serveur d'applications, pour traiter une requêtede communication provenant d'un premier terminal d'un utilisateur appelantvisant à établir une communication avec un deuxième terminal d'un utilisateurcible, ledit serveur d'applications étant compris dans un réseau de communicationassocié au deuxième terminal et ledit agent conversationnel automatisé étantsitué hors dudit réseau de communication ; un module de vérification configuré pour vérifier si des évènements indicatifs dela disponibilité de l'utilisateur cible ont été reçus en provenance du réseau decommunication du deuxième terminal et en provenance d'au moins un autreréseau de communication associé à l'utilisateur cible ; un module de détermination configuré pour déterminer l'état de disponibilité dudeuxième utilisateur à partir d'au moins un dit évènement reçu ; et un module de contrôle configuré pour contrôler à distance le serveurd'applications de sorte à réaliser un traitement de la requête de communicationen 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 lepremier 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 ci-avant.
Selon un mode de réalisation particulier, l'invention est mise en œuvre au moyen decomposants logiciels et/ou matériels. Dans cette optique, le terme « module » peutcorrespondre dans ce document aussi bien à un composant logiciel, qu'à un composantmaté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 ladescription faite ci-dessous, en référence aux dessins annexés qui en illustrent desexemples de réalisation dépourvus de tout caractère limitatif. Sur les figures: - la figure 1 représente schématiquement un environnement comportantnotamment 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'applicationsconforme à un mode de réalisation particulier de l'invention ; - la figure 3 représente schématiquement la structure d'un agent conversationnelautomatisé 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 premierprocédé de traitement mis en œuvre par un serveur d'applications et les étapesd'un deuxième procédé de traitement mis en œuvre par un agentconversationnel automatisé, conformément à un mode de réalisation particulierde l'invention.
Description détaillée de plusieurs modes de réalisation
Comme indiqué précédemment, la technique proposée se rapporte au traitementd'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 etun 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 desinformations indicatives de la disponibilité de l'utilisateur appelé et traiter la demande decommunication en fonction de la disponibilité de l'appelé afin de faciliter les interactionsentre appelant et appelé. L'invention, selon divers modes de réalisation, met ainsi en œuvre un serveurd'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 communicationprovenant du terminal d'un utilisateur appelant, pour déclencher un agent conversationnelautomatisé associé à l'utilisateur cible, et pour traiter cette requête de communicationsous le contrôle de l'agent conversationnel automatisé. L'invention, selon divers modes deréalisation, concerne également un tel agent conversationnel automatisé, configuré pourêtre activé par le serveur d'applications, pour déterminer l'état de disponibilité del'utilisateur cible à partir de données (ou évènements) reçues d'au moins un réseau decommunication associé à l'utilisateur cible, et pour contrôler à distance le serveurd'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 deré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écritsdans le cadre d'un premier utilisateur tentant d'établir une communication avec undeuxième utilisateur. Dans ce contexte, la communication initiée par le premier utilisateurpeut être de type quelconque, telle que par exemple un appel vocal initié par le premierutilisateur ou encore un message de type texte (SMS, email, message via un service demessagerie instantanée...) envoyé par le premier utilisateur. En outre, toujours dans cecontexte, l'utilisateur à l'origine de la communication (c.-à-d. initiant la communication)est dit utilisateur appelant ou utilisateur source, tandis que le deuxième utilisateurdestinataire de la communication est dit utilisateur appelé ou utilisateur cible. Dans le casd'une conférence téléphonique, on peut également envisager que plusieurs utilisateursappelants initient un appel vers un même utilisateur cible.
Sauf indications contraires, les éléments communs ou analogues à plusieurs figuresportent les mêmes signes de référence et présentent des caractéristiques identiques ouanalogues, de sorte que ces éléments communs ne sont généralement pas à nouveaudécrits par souci de simplicité.
Un mode de réalisation particulier de l'invention est à présent décrit en référence à lafigure 1, où un utilisateur UA tente d'établir une communication vocale avec un autreutilisateur UB. Comme décrit par la suite, d'autres types de communication sont toutefoispossibles dans le cadre de l'invention. Pour ce faire, l'utilisateur UA, dit utilisateurappelant ou utilisateur source, initie un appel téléphonique en direction du terminal TB1de l'utilisateur cible UB.
Dans l'exemple considéré ici, le terminal TA de l'utilisateur UA est par exempleassocié (ou connecté) à un premier réseau de communications RI, tandis que le terminalTB1 de l'utilisateur cible UB est associé (ou connecté) à un deuxième réseau decommunications R2. Les terminaux TA et TB1 peuvent être de quelconques équipements aptes à établir ensemble une communication vocale, tels que des téléphones mobiles oufixes etc. Les réseaux RI et R2 peuvent être par exemple des réseaux de téléphonie fixeou mobile (de type 3G, 4G etc.).
Dans cet exemple, un premier serveur d'applications SA1 situé dans le réseau decommunications RI fait le relais entres les appels de l'utilisateur appelant UA etl'extérieur. Lorsque l'utilisateur UA tente d'appeler l'utilisateur UB, le serveur d'applicationsSA1 est ici configuré pour transférer une requête de communication RQ1, émise par leterminal TA de l'utilisateur appelant UA, vers le réseau de communications R2 del'utilisateur cible UB.
Le serveur d'applications SA1 présente ici la structure d'un ordinateur et comportenotamment 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 leserveur d'applications SA1, et sur lequel est enregistré un programme d'ordinateur PG1conforme à un mode de réalisation particulier.
Dans l'exemple représenté en figure 1, le serveur d'applications SA1 contient enmémoire un identifiant ID-A de l'utilisateur UA dans le réseau RI. Cet identifiant ID-A estici enregistré en association avec un identifiant ID-BOTA d'un agent conversationnelautomatisé BOTA qui sera décrit ultérieurement.
Toujours dans cet exemple, un deuxième serveur d'applications SA2, situé dans leréseau de communications R2, est chargé de recevoir les appels à destination del'utilisateur cible UB et de les transférer si besoin vers le terminal TB1 destinataire del'appel. Sur réception de la requête d'appel RQ1, le serveur d'applications SA2 est iciconfiguré pour transférer l'appel au terminal TB1 ou pour activer un agentconversationnel automatisé BOTB associé à l'utilisateur cible UB, cet agentconversationnel automatisé BOTB étant situé hors du réseau R2.
Le serveur d'applications SA2 présente ici aussi la structure d'un ordinateur etcomporte notamment au moins un processeur (non représenté) et une mémoire nonvolatile MR2 (ROM ou Flash par exemple) constituant un support d'enregistrement, lisiblepar le serveur d'applications SA2, et sur lequel est enregistré un programme d'ordinateurPG2 conforme à un mode de réalisation particulier. Dans cet exemple, le serveurd'applications SA2 dispose aussi en mémoire d'un identifiant ID-BOTB de l'agentconversationnel automatisé BOTB en association avec un identifiant ID-B1 de l'utilisateurcible U B dans le réseau R2.
Sur réception de la requête d'appel RQ1 émise par le terminal source TA, le serveurd'applications SA2 peut ainsi envoyer une commande CMD1 de déclenchement à l'agentconversationnel automatisé BOTB, cette commande visant à activer ledit agent conversationnel automatisé BOTB pour qu'il traite l'appel entrant initié par l'utilisateursource UA.
Dans le présent exposé, un agent conversationnel automatisé désigne une interfacehomme-machine configurée pour traiter de façon interactive la ou les requêtes d'unutilisateur (par exemple l'utilisateur source UA). Pour ce faire, l'agent conversationnelautomatisé (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 decritères prédéfinis. L'agent conversationnel automatisé peut proposer certains services etprend le cas échéant en compte les demandes ou réponses de l'utilisateur avec lequel ilinteragit.
Dans le cas présent, le chatbot BOTB se présente sous la forme d'un programmed'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 équipementinformatique, tel qu'un serveur, un ordinateur ou tout autre équipement informatiqueapte à 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éseaude communications R2.
Selon un exemple particulier, le chatbot BOTB met en œuvre un service demessagerie vocale configuré pour traiter les communications entrantes à destination del'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'enprovenance 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 desdonnées indicatives de la disponibilité de l'utilisateur associé, à savoir l'utilisateur cible UBdans 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 asouscrit l'utilisateur cible UB et auquel est associé (connecté) un autre terminal TB2 del'utilisateur cible UB. Dans cet exemple, un serveur d'applications SA3 situé dans le réseauR3 est configuré pour traiter des appels émis ou à destination du terminal TB2. Le serveurd'applications SA3 est par exemple configuré pour envoyer le cas échéant au chatbotBOTB 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 etcomporte notamment au moins un processeur (non représenté) et une mémoire nonvolatile 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'ordinateurPG4 conforme à un mode de réalisation particulier. Dans cet exemple, le serveurd'applications SA3 dispose aussi en mémoire de l'identifiant ID-BOTB de l'agentconversationnel automatisé BOTB, associé par exemple à un identifiant ID-B2 del'utilisateur cible UB dans le réseau R3.
Les réseaux de communications R2 e R3 sont ici des réseaux distincts mis en œuvrepar des opérateurs différents.
La nature des évènements EV susceptibles d'être transmis par les réseaux decommunication 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 ladisponibilité de l'utilisateur cible UB. Un évènement EV envoyé par le serveurd'applications SA2 (ou respectivement SA3) peut par exemple indiquer que l'utilisateurcible UB a été impliqué dans un appel téléphonique à une certaine date et/ou heure, ouque l'utilisateur cible UB est en cours de communication. L'évènement EV peut parexemple spécifier que la communication en cours (ou passée) est une communicationentrante (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 quel'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 esten 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. Apartir de cette information de localisation, le chatbot B peut ainsi déterminer l'état dedisponibilité de l'utilisateur cible UB.
Comme représenté en figure 1, on suppose également dans cet exemple que leréseau de communications R4 est encore un autre réseau mettant en œuvre un serviceauquel a souscrit l'utilisateur cible UB. Dans le cas considéré ici, le serveur d'applicationsSA4 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 ladisponibilité 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 SA4peut également correspondre à une activité de l'utilisateur cible UB détectée sur le servicede messagerie, telle que la préparation ou l'envoi d'un email etc. On comprendra quel'exemple de ce service de messagerie n'est pas limitatif et que d'autres types de serviceset d'évènements sont possibles. En variante, le service mis en œuvre par le serveurd'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 lastructure d'un ordinateur et comporte notamment au moins un processeur (nonreprésenté) et une mémoire non volatile MR5 (ROM ou Flash par exemple) constituant unsupport d'enregistrement, lisible par le serveur d'applications SA4, et sur lequel estenregistré un programme d'ordinateur PG5 conforme à un mode de réalisation particulier.
Concernant à nouveau le chatbot BOTB, ce dernier est par ailleurs configuré poursurveiller 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 dedisponibilité dudit utilisateur cible UB. Comme représenté en figue 1, le chatbot BOTBpeut enregistrer dans une mémoire les évènements EV et les traiter si besoin. A partir deces évènements EV, le chatbot B est configuré pour déterminer l'état de disponibilité oud'accessibilité (courant et/ou futur) de l'utilisateur associé, à savoir l'utilisateur cible UBdans cet exemple. Cet état de disponibilité peut indiquer si l'utilisateur cible UB estactuellement en position ou non pour recevoir une communication entrante (tel quel unappel téléphonique entrant dans cet exemple). L'état de disponibilité peut aussirenseigner sur la capacité de l'utilisateur cible UB à recevoir une communication dans lefutur.
Dans cet exemple, le BOTB contient également en mémoire l'identifiant respectif ID-Bl, ID-B2 et ID-B3 de l'utilisateur cible UB dans chacun des réseaux R2, R3 et R4. Oncomprend que l'utilisateur cible UB dispose d'un identifiant propre pour chaque réseau decommunication R2, R3 et R4 dont il est usager, cet identifiant lui étant par exempleattribué par l'opérateur du réseau correspondant. Un identifiant peut être une adresseemail, un numéro de téléphone, un identifiant de messagerie instantanée ou autre, selonle cas.
Toujours dans cet exemple, le chatbot BOTB stocke également en mémoire desdonnées DN1 à partir desquelles le chatbot BOTB peut déterminer comment un appelentrant doit être traité. Les données DN1 sont ici des règles de traitement prédéfinies, cesrè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 à unecommunication ; - à 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 del'utilisateur UB. Les règles de traitement DN1 peuvent combiner un ensemble de critèresquelconques, 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 nonaccepter une communication entrante.
Ces règles de traitement DN1 définissent ici dans quelles conditions l'utilisateur cibleUB est d'accord pour accepter une communication entrante sur le réseau decommunication R2 dont il est l'usager. On comprend toutefois que des règles detraitement DN1 du même type peuvent être stockées et utilisées par le chatbot BOTBpour traiter des communications entrantes à destination de l'utilisateur cible UB sur unautre réseau de communication auquel il est abonné, comme par exemple le réseau R3dans 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 9heure et 19 heures, sauf s'il est en cours de communication sur l'un des réseauxde communications (ici R4) auquel il a souscrit ; - l'utilisateur UB accepte toujours des communications écrites par messagerieinstantané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 traitementDN1 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çonappropriée à chaque cas d'espèce.
Le serveur d'applications SA2 et le chatbot BOTB forment ensemble un système detraitement SY apte à traiter une requête de communication RQ1 émise par le terminal UAde 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 agentconversationnel automatisé (ou chatbot) BOTA, associé cette fois à l'utilisateur source UA,est situé hors du réseau de communications RI de sorte à pouvoir interagir à distanceavec le serveur d'applications SA1 situé dans le réseau de communications SA1. Envariante, le chatbot BOTA peut être situé dans le réseau RI. Le chatbot BOTA est parexemple mis en œuvre par le serveur d'applications SA1 lui-même. Comme expliqué par lasuite dans un exemple de réalisation particulier, le chatbot BOTA est configuré pourcoopérer si besoin avec le chatbot BOTB de l'utilisateur cible UB afin de traiter parexemple l'appel initié par l'utilisateur source UA à l'attention de l'utilisateur cible UB. Pource faire, les chabots BOTA et BOTB comprennent chacun dans cet exemple une interfacede communication leur permettant de communiquer ensemble. Comme expliqué par lasuite, des variantes de réalisation sont toutefois possibles selon lesquelles le deuxièmeagent 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 ouanalogue au chatbot BOTB. Plus précisément, Le chatbot BOTA se présente sous la formed'un programme d'ordinateur PG6 stocké dans une mémoire non-volatile MR6 (ROM ouFlash 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 équipementinformatique apte à exécuter ce type d'interface logicielle.
Le chatbot BOTA utilise une API, notée API-A, pour coopérer à distance avec leserveur 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 detraitement DN2 analogues aux règles de traitement DNA du chatbot BOTB, ces règlesDN2 permettant le cas échéant au chatbot BOTA de déterminer la manière dont unecommunication 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 unecommunication qu'un tiers tenterait d'initier à l'attention de l'utilisateur UA, prenant cettefois 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 communicationsentrantes à destination de l'utilisateur UA.
On comprendra que certains éléments généralement présents dans notamment unserveur 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ésenteinvention.
On comprendra que l'environnement représenté en figure 1, et notamment lesystè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 particulierque certains éléments de cet environnement ne sont décrits ici que pour faciliter lacompréhension de l'invention, ces éléments n'étant pas nécessaires pour mettre en œuvrel'invention.
Selon un mode de réalisation particulier représenté en figure 2, le serveurd'applications SA2 (et plus particulièrement son processeur) piloté par le programmed'ordinateur PG2 met en œuvre un certain nombre de modules, à savoir : un module deréception MD2, un module d'envoi MD4, un module de traitement MD6 et un module desuivi d'évènements MD8.
Le module de réception MD2 est configuré pour recevoir la requête RQ1 decommunication provenant du terminal source TA comme représenté en figure 1, cetterequête visant à établir une communication entre le terminal source TA et le terminal cibleTB1.
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 activerledit chatbot BOTB.
Le module de traitement MD6 est configuré pour réaliser notamment un traitementde la requête de communication RQ1 reçue par le module de réception MD2, cetraitement étant réalisé sous le contrôle du chatbot BOTB qui commande le serveurd'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 comprendrel'établissement d'un dialogue ou d'une interaction entre le chatbot BOTB et au moins l'unparmi le terminal source TA de l'utilisateur appelant UA et le chatbot BOTA de l'utilisateurappelant UA. Si, dans une variante, l'utilisateur source UA ne dispose pas d'un chatbotpour l'assister, le dialogue se fait nécessairement entre le chatbot BOTB et le terminal TAde l'utilisateur source UA.
Plus généralement, on comprendra que le module de traitement MD6 peut êtreconfiguré pour réaliser un quelconque traitement en réponse à des instructions émisespar un agent conversationnel automatisé externe au réseau de communications R2. Selonle 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'agentconversationnel automatisé BOTB (et plus particulièrement son processeur) piloté par leprogramme d'ordinateur PG3 met en œuvre un certain nombre de modules, à savoir : unmodule de réception MD10, un module de vérification MD12, un module de déterminationMD14 et un module de contrôle MD16.
Le module de réception MD10 est configuré pour recevoir la commande dedéclenchement CMD1 provenant du serveur d'applications SA1, cette commandedéclenchant le traitement par le chatbot BOTB de la requête RQ1 de communicationprovenant du terminal TA de l'utilisateur source UA.
Le module de vérification MD12 est configuré pour vérifier si un ou des évènementsEV indicatifs de la disponibilité de l'utilisateur cible UB ont été reçus en provenance duréseau de communication R2 du terminal TB1 et en provenance d'au moins un autreréseau de communication associé à l'utilisateur cible UB, à savoir les réseaux R3 et R4dans cet exemple.
Le module de détermination MD14 est configuré pour déterminer l'état dedisponibilité (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-à-diredepuis l'extérieur du réseau R2) le serveur d'applications SA2 de sorte à réaliser untraitement de la requête de communication RQ1 en fonction de l'état de disponibilité del'utilisateur cible UB. Comme déjà indiqué et comme illustré par la suite, le module decontrôle MD16 peut prendre en compte un certain nombre de paramètres pourdéterminer l'état de disponibilité de l'utilisateur UB et la manière dont une communicationentrante doit être traitée, en appliquant notamment les règles de traitement prédéfiniesDN1 dans le cas présent.
Plus généralement, on comprendra que le module de contrôle MD16 peut êtreconfiguré pour contrôler, depuis l'extérieur du réseau R2, le serveur d'applications SA2 desorte à 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 chacundes réseaux de communications associés à l'utilisateur cible UB (à savoir R2, R3 et R4dans cet exemple). Cette position externe du chatbot BOTB permet à ce dernier derecevoir de façon centralisée les évènements EV émis par chacun des réseaux decommunications R2, R3, R4 auquel l'utilisateur UB a souscrit. Cette disposition permet enoutre 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 quelconquecommunication entrant dans un réseau de communication R2, R3 ou R4 à destination del'usager U B.
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émentdans les exemples de réalisation décrits ci-après en référence à la figure 4. Oncomprendra que ces modules ne constituent qu'un exemple de mise en œuvre nonlimitatif 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 à lafigure 4. Plus précisément, le serveur d'applications SA2 et l'agent conversationnelautomatisé BOTB illustrés en figures 1-3 mettent chacun en œuvre un procédé detraitement 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 quel'utilisateur source UA utilise son terminal TA afin d'initier une communication vers leréseau de communications R2 à destination de l'utilisateur cible UB. Dans l'exempleconsidéré ici, on suppose que l'utilisateur source UB tente d'établir une conversationvocale 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 sourceUA envoie une requête RQ1 de communication qui est reçue en B2 par le serveurd'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 serveurd'applications SA1 détermine vers quelle destination doit être transmise la requête RQ1 decommunication. Dans cet exemple, cette requête RQ1 comprend en outre l'identifiant ID-A de l'utilisateur UA à l'origine de l'appel, bien que des variantes de réalisation sansl'inclusion d'un tel identifiant dans la requête RQ1 sont possibles (cas d'un appel anonymepar exemple).
Le serveur d'applications SA1 insert (B3) ensuite l'identifiant ID-BOTA du chatbotBOTA dans la requête RQ1 et envoie (B4) ladite requête RQ1, comportant l'identifiant ID-BOTA, au réseau de communication R2. Le serveur d'applications SA2 reçoit la requêteRQ1 en C4.
Dans cet exemple de réalisation, le serveur d'applications SA2 détecte, à partir del'identifiant ID-B1 présent dans la requête RQ1, que la communication entrante estdestinée à l'utilisateur cible UB. Le serveur d'applications SA2 envoie (C6) alors unecommande de déclenchement CMD1 au chatbot BOTB chargé de traiter lescommunications de l'utilisateur cible UB. Le serveur d'applications SA2 détermine que lechatbot BOTB est en charge du traitement des communications à partir de l'identifiant ID-BOTB enregistré en association avec l'identifiant ID-B1 de l'utilisateur cible UB dans leréseau R2.
On comprendra que des variantes sont possibles selon lesquelles le serveurd'applications SA2 tente dans un premier temps de joindre l'utilisateur cible UB sur sonterminal TB1 et, en cas d'échec (par exemple en cas de non réponse après un délaipré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 C6par 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 del'utilisateur UA.
Comme illustré en figure 4, le chatbot BOTB de l'usager UB reçoit la commande dedéclenchement CMD1 en D6. Sur réception de cette commande CMD1, le chatbot BOTBtraite 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'unquelconque 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é) del'utilisateur UB. Dans un exemple particulier, le chatbot BOTB reçoit (D7) une pluralité dedits évènements EV en provenance du réseau de communication R2 et en provenance desautres réseaux de communication R3 et R4 associés à l'utilisateur cible UB. Le chatbotBOTB 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) undeuxième évènement EV2 émis (F10) par le serveur d'applications SA3 et reçoit (D12) untroisième évènement EV3 émis (G12) par le serveur d'applications SA4. On comprend quechaque des évènements EV1, EV2, EV3 (notés collectivement EV) peut être reçu dans unordre quelconque, avant ou après l'étape de réception D6 de la commande dedéclenchement CMD1.
Dans cet exemple, les évènements EV1, EV2 et EV3 contiennent respectivementl'identifiant ID-B1, ID-B2 et ID-B3 de l'utilisateur cible UB dans chacun des réseaux R2, R3et R4. Comme déjà indiqué, l'utilisateur cible UB dispose d'un identifiant propre pourchaque 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 sibesoin tout traitement approprié.
Comme déjà indiqué, le chatbot BOTB contient en mémoire chacun des identifiantsID-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 ladisponibilité de l'utilisateur cible UB ont bien été reçus en provenance des réseaux decommunications 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 EV3enregistré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 surla capacité courante, et éventuellement future, de l'utilisateur cible UB à recevoir et traiterune nouvelle communication entrante.
Le chatbot BOTB peut en outre prendre en compte en D14 l'identifiant ID-A del'utilisateur source UA pour déterminer l'état de disponibilité de l'utilisateur cible UB. Il estainsi possible de personnaliser le traitement de la communication entrante en fonction del'utilisateur source UA. Des variantes sont toutefois possibles selon lesquelles l'identité del'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 émisepar le terminal source TA, ce traitement étant fonction de l'état de disponibilité del'utilisateur cible UB obtenu en D14. Le chatbot BOTB se comporte ici en tant que maîtrevis-à-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 detraitement DN1 pour déterminer, sur la base des évènements EV et éventuellementd'autres paramètres (l'identité ID-A de l'utilisateur source UA, localisation de l'utilisateurUB, 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'applicationsSA2 en lui envoyant des commandes (ou instructions) et en traitant des données émisespar le serveur d'applications SA2. Cette coopération entre le chatbot BOTB et le serveurd'applications SA2 (via des APIs adaptées) permet d'assurer le traitement automatisé dela communication initiée par l'utilisateur source UA, en conformité le cas échéant avec lesrègles prédéfinies DN1, et en prenant compte de l'activité de l'utilisateur cible UB sur lesdiffé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, larequête RQ1 de communication.
Comme représenté en figure 4, le traitement C16 commandé par le chatbot BOTBcomprend par exemple l'établissement d'un dialogue (ou coopération) 20 entre le chatbotBOTB et le terminal TA de l'utilisateur source UA et/ou un dialogue (ou coopération) 30entre le chatbot BOTB et le chatbot BOTA de l'utilisateur source UA. La ou les entités aveclesquelles le chatbot BOTB décide d'interagir dépend de la configuration de ce dernier etdu 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 chatbotest disponible pour assister l'utilisateur source UA. Si un tel chatbot BOTA n'est pasdisponible, 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 basedes évènements EV obtenus et des règles de traitement DN1 appliquées, d'interagir avecle terminal TA et avec le chatbot BOTA. Pour ce faire, le chatbot BOTB envoie (D16) parexemple une commande CMD2 comportant l'identifiant ID-A de l'utilisateur source UAdans le réseau RI, l'identifiant ID-B1 de l'utilisateur cible UB dans le réseau R2 etl'identifiant ID-BOTA du chatbot BOTA de l'utilisateur source UA. Le serveur d'applicationsSA2 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'utilisateursource UA dans le réseau RI, l'identifiant ID-B1 de l'utilisateur cible UB dans le réseau R2et l'identifiant ID-BOTA du chatbot BOTA de l'utilisateur source UA.
Comme représenté en figure 4, le serveur d'applications SA1 reçoit le messageMSG2 en B20 et transmet (B22) des messages MSG3 et MSG4 respectivement au terminalTA et au chatbot BOTA. L'utilisateur UA peut ainsi recevoir toute information utile de lapart du chatbot BOTB. Le chatbot BOTB peut par exemple indiquer à l'utilisateur sourceUA, sur son terminal TA, que l'utilisateur cible UB n'est pas disponible et/ou lui indiquerune date et/ou heure à laquelle il sera disponible. Un dialogue peut s'établir si besoinentre le terminal TA et le chatbot BOTB afin de répondre aux éventuelles questions del'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 demessagerie vocale qui permet un dialogue ou une interaction 20 entre l'utilisateur sourceUA et le chatbot BOTB.
Par ailleurs, le chatbot BOTA de l'utilisateur source UA peut également prendreconnaissance de la situation à partir du message MSG4 reçu en E22 puis coopérer avec lechatbot BOTB afin de réaliser un traitement approprié. A titre d'exemple, les chatbotsBOTA et BOTB peuvent coopérer ensemble pour définir un rendez-vous entre lesutilisateurs UA et UB en fonction de leur disponibilité respective, en utilisant par exempledes données d'agenda auxquelles les chatbots BOTA et BOTB ont accès (sous formed'évènements EV par exemple). Pour ce faire, les chatbots BOTA et BOTB établissent uncanal de communication bidirectionnel passant par le serveur d'applications SA2 et par leréseau RI (en passant éventuellement par le serveur d'applications SA1).
De façon générale, le chatbot BOTB communique (D16) avec le terminal TA et/ouavec le chatbot BOTA par l'intermédiaire du réseau R2, et plus particulièrement via leserveur d'applications SA2 dans cet exemple de réalisation. Une relation de confianceexiste 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 aupréalable auprès du réseau R2. En faisant passer les échanges émis par et à destinationdu chatbot BOTA par le réseau R2, l'utilisateur source UA et son chatbot BOTA ont ainsi lagarantie de l'authenticité du chatbot BOTB.
Dans l'exemple considéré ici, lors du traitement C16, le serveur d'applications SA2assure un échange de données associées à l'utilisateur appelant UA et de donnéesassociées à l'utilisateur appelé UB entre l'agent conversationnel automatisé BOTB, d'unepart, et le terminal TA et/ou le chatbot BOTA, d'autre part, de sorte à réaliser au moinsune action prédéterminée. De façon avantageuse, lors de ce dialogue, le chatbot BOTBpropose au moins un service donné à l'utilisateur source UA et/ou au chatbot BOTA, afinpar exemple de faciliter la mise en relation actuelle ou future de l'utilisateur source UAavec l'utilisateur cible UB. Dans un exemple particulier, ce dialogue comporte l'envoi par leserveur 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 del'utilisateur cible UB.
On comprend que diverses configurations sont envisageables dans le cadre del'invention. Selon un exemple particulier, lors de l'étape D14 de détermination, sil'utilisateur cible UB est déterminé comme n'étant pas disponible, le chatbot BOTB réaliseau moins l'une des actions suivantes : o le chatbot BOTB obtient une donnée de disponibilité renseignant sur l'état dedisponibilité (courant et/ou futur) de l'utilisateur cible UB, cette donnéecorrespondant 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 BOTBcommande alors l'envoi (D16), par le serveur d'applications SA2, de ladite donnéede disponibilité à au moins l'un parmi le terminal TA et l'agent conversationnelautomatisé BOTA. L'utilisateur source UA et/ou son chatbot BOTA prennent ainsiconnaissance de l'état de disponibilité actuel et/ou futur de l'utilisateur cible UB. Ladonnée de disponibilité peut indiquer si l'utilisateur cible UB est actuellementdisponible ou non, en fonction par exemple du type de communication (appeltéléphonique, email, SMS...) considéré. Cette donnée de disponibilité peutcomporter un degré de probabilité que l'utilisateur cible UB sera disponible dansun point dans le temps déterminé (dans 10 minutes à compter de l'initiation del'appel par exemple), ce degré de probabilité étant préalablement déterminé par lechatbot BOTB, par exemple à partir des évènements EV et éventuellement desrègles de traitement DN1. De cette manière, l'utilisateur source UA peutrecontacter l'utilisateur cible UB à un moment approprié et optimiser ses chancesde joindre l'utilisateur cible UB dans de bonnes conditions. o le chatbot BOTB envoie une notification de communication à un réseau decommunication (R3 par exemple) associé à l'utilisateur cible UB, autre que leréseau de communication R2. Cette notification permet d'informer l'utilisateur cibleUB de la tentative de communication initiée par le premier terminal TA sur leréseau R2. Cette notification comporte par exemple l'identifiant ID-A del'utilisateur appelant UA afin d'informer l'utilisateur cible UB de l'identité del'appelant, ce qui permet à l'utilisateur cible UB de recontacter ultérieurementl'utilisateur source UA si besoin. o le chatbot BOTB définit, par l'intermédiaire du serveur d'applications SA2, unrendez-vous en coopération avec le premier terminal TA ou avec l'agentconversationnel automatisé BOTA, et le cas échéant il enregistre une nouvelleentré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'agendade l'utilisateur cible UB en conséquence. Dans un exemple particulier, le chatbotBOTB envoie vers le réseau R4 à destination de l'utilisateur cible UB unenotification relative à ladite nouvelle entrée. L'utilisateur cible UB peut ainsiprendre 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) del'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é auréseau RI. Cette invitation comporte l'identifiant ID-B2 et/ou ID-B3 de l'utilisateurcible UB afin d'inviter l'utilisateur source UA à contacter l'utilisateur cible UB via leré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 unréseau de communication autre que le réseau R2 initialement visé, optimisant ainsiles 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 BOTBcommande l'envoi, par le serveur d'applications SA2, d'une notification informantde l'état prédéfini à destination de l'utilisateur source UA, par exemple sur sonterminal TA. De cette manière, l'utilisateur source UA est informé dès quel'utilisateur cible UB est disponible, et éventuellement sous quelle condition il estdisponible (type de communication acceptée etc.), ce qui permet de faciliter lamise en communications des deux parties.
Parmi les actions possibles, le chatbot BOTB peut également causer l'envoi, par leserveur 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 ducas d'espèce. Chaque action prédéfinie (ou option) proposée par le chatbot BOTB permetde faciliter les interactions entre les utilisateurs UA et UB. Ces propositions peuventcomporter 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 UBetc.). Ces propositions d'actions prédéfinies peuvent être adaptées par le chatbot BOTBen fonction de divers critères tels que par exemple l'identité de l'utilisateur source UA, afinde 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'utilisateursource UB et/ou pour déterminer en D16 le traitement à appliquer. Tel est le cas parexemple 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 decommunication, de type texte, vocale, vidéo par exemple. Lorsque la communicationinitiée par un utilisateur source est un appel téléphonique par exemple, cette tentative decommunication peut viser un terminal particulier de l'utilisateur cible. Des variantes sonttoutefois possibles selon lesquelles la tentative de communication initiée par l'utilisateursource 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'utilisateursource UA en A2 est par exemple un message de type email, qui vise une identité d'undestinataire, cette identité étant indépendante du terminal pouvant être utilisé parl'utilisateur cible UB. Dans ce cas particulier, le serveur d'applications SA2 reçoit l'email enC4 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 dudestinataire UB, d'un autre moyen de communication qu'il est invité à utiliser pour joindrele destinataire UB et/ou encore, un autre moment plus approprié pour contacter ledestinataire UB. Si le chatbot BOTA est mis en œuvre, ce dernier est aussi en mesure decoopé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 appelantpeut être traitée en temps réel par l'agent conversationnel automatisé de l'utilisateur cibleafin d'optimiser les chances pour l'utilisateur appelant de rentrer en contact avecl'utilisateur appelé, et ce dans les meilleurs conditions possibles. Un utilisateur appelantest ainsi moins susceptible d'hésiter à contacter un tiers dans la mesure où l'appel seratraité selon les souhaits prédéfinis du tiers. L'agent conversationnel automatisé del'utilisateur cible peut fournir toutes les informations nécessaires à l'utilisateur appelantsous la forme d'une notification simple, ou sous la forme d'un dialogue interactif. Enparticulier, selon le paramétrage choisi, l'agent conversationnel automatisé de l'utilisateurcible pourra inviter l'utilisateur appelant à tenter une nouvelle communication à unmoment particulier, à tenter une communication via un autre réseau de communicationou à destination d'un autre identifiant.
De manière générale, divers services peuvent être mis en œuvre par les chatbotsBOTA et BOTB coopérant ensemble, ou alternativement par le chatbot BOTB sansl'intervention du chatbot BOTA. Les chatbots BOTA et BOTB peuvent par exempledialoguer 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 BOTAlorsque celui-ci est mis en œuvre, s'appuie sur une intelligence artificielle pour prendredes décisions et traiter chaque communication de la façon la plus appropriée. Le chatbotBOTB par exemple peut apprendre au cours du temps la meilleure manière de traiterchaque situation donnée et ainsi adapter en conséquence son comportement à unesituation ultérieure.
Par ailleurs, on notera que la mise en œuvre d'une synthèse vocale et/ou d'unereconnaissance vocale sont possibles pour permettre un dialogue aisé entre l'utilisateursource LIA et le chatbot BOTB de l'utilisateur cible UB.
Dans un premier exemple de réalisation, la communication initiée par l'utilisateursource UA est de type vocale et, lors dudit contrôle à distance D16 (figure 4), l'agentconversationnel automatisé BOTB commande au serveur d'applications SA1 la réalisationd'une synthèse vocale à partir de données texte, et la réalisation d'une reconnaissancevocale de données vocales reçues par le serveur d'applications SA1 depuis le premierterminal TA. Autrement dit, dans ce premier cas, c'est le serveur d'applications SA2 qui secharge de faire le traitement sur la voix, en réalisant la synthèse vocale pour générer dela voix à l'attention de l'utilisateur cible et pour reconnaître la voix émise par l'utilisateursource UA.
Selon un deuxième exemple de réalisation, la communication initiée par l'utilisateursource UA est de type vocale et, lors dudit contrôle à distance D16 (figure 4), l'agentconversationnel automatisé BOTB envoie au serveur d'applications SA2 des donnéesvocales (générées par BOTB) pour transmission au terminal source TA, et réalise unereconnaissance vocale de données vocales reçues depuis le terminal source TA via leserveur d'applications SA2. Autrement dit, dans ce deuxième cas, c'est le chatbot BOTBqui se charge de faire le traitement sur la voix, en réalisant la synthèse vocale pourgénérer de la voix à l'attention de l'utilisateur cible et pour reconnaître la voix émise parl'utilisateur source UA.
Quel que soit le mode de réalisation considéré, le chatbot BOTB de l'utilisateur cibleUB peut être configuré pour adapter la langue de dialogue en fonction l'utilisateur sourceUA, par exemple en tenant compte de l'identifiant ID-A du terminal TA.
Par ailleurs, selon une variante du mode de réalisation représenté en figure 4, lechatbot BOTB est configuré pour vérifier via le serveur d'applications SA2 si l'utilisateurcible UB est actuellement disponible sur son terminal TB1 en réponse à la requête RQ1 decommunication émise par le terminal source TA. Pour ce faire, le chatbot BOTB envoieune commande au serveur d'applications SA2 visant à établir, en réponse à ladite requêteRQ1 de communication, une communication entre les terminaux TA et TB1. Sur réceptionde cette commande, le serveur SA2 tente d'établir ladite communication. Le chatbot BOTBdéclenche en outre un décompte de temps à compter de l'envoi de ladite commandevisant à établir une communication entre les terminaux TA et TB1. En l'absence deréponse positive du terminal TB1 de l'utilisateur cible UB (par exemple, l'utilisateur cibleUB décroche son téléphone) après un délai prédéfini (30 secondes par exemple), lechatbot BOTB détermine (D14) alors que l'utilisateur cible UB n'est pas actuellementdisponible. Le chatbot BOTB peut alors déterminer (D14) la disponibilité future del'utilisateur cible UB à partir du ou des évènements EV reçus (D7) et piloter (D16) leserveur 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 BOTBde l'utilisateur cible UB détermine en D16 un niveau d'urgence de la requête RQ1 decommunication à partir de l'identifiant ID-B1 de l'utilisateur source. Ce niveau d'urgencepeut est déterminé à partir des règles de traitement DN1 (figure 1), en prenant comptedivers critères prédéfinis (la date/l'heure, le réseau ou le terminal sur lequel l'utilisateurcible est contacté etc.). Si le niveau d'urgence atteint un niveau prédéfini (par exemple unniveau 3 d'urgence sur une échelle de 5), le chatbot BOTB cause l'envoi d'une notificationd'urgence à l'attention de l'utilisateur cible UB via le réseau de communications R2 (parl'intermédiaire du serveur d'applications SA2), ou via l'un parmi les autres réseaux R3, R4de l'utilisateur cible UB. L'utilisateur cible UB peut ainsi juger de l'importance d'unecommunication 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 ci-avant ne constituent que des exemples non limitatifs de mise en œuvre de l'invention. Enparticulier, l'homme du métier pourra envisager une quelconque adaptation oucombinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à unbesoin bien particulier.

Claims (8)

  1. REVENDICATIONS
    1. Procédé de traitement d'une communication, mis en œuvre par un serveurd'applications (SA2), comprenant les étapes suivantes : réception (C4) d'une requête (RQ1) de communication provenant d'un premierterminal (TA) d'un utilisateur appelant (UA), ladite requête visant à établir unecommunication avec un deuxième terminal (TB1) d’un utilisateur cible (UB), leserveur d'applications (SA2) étant compris dans un réseau de communication(R2) associé au deuxième terminai (TB1) ; envoi (C6), à un premier agent conversationnel automatisé (BOTB) associé àl'utilisateur cible (UB), d’une commande de déclenchement (CMD1) pour activerledit premier agent conversationnel automatisé, ce dernier étant situé hors duréseau de communication (R2) du deuxieme terminal (TB1) ; et traitement (C16), sous 1e contrôle du premier agent conversationnel automatisé(BOTB), de la requête de communication (RQ1), ledit traitement comprenantré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 agentconversationnel automatisé (BOTA) associé à l'utilisateur appelant (UA) ; dans lequel la requête (RQ1) de communication reçue lors de l'étape de réceptioncomprend 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 etdeuxième agents conversationnels automatisés (BOTB, BOTA) afin de traitercollectivement ladite requête (RQ1) de communication,
  2. 2. Procédé selon la revendication 1, comprenant un envoi (C8), au premier agentconversationnel automatisé (BOT), d'au moins un évènement (EV1) Indicatif de ladisponibilité de l'utilisateur cible (UB) afin de permettre audit premier agentconversationnel automatisé (BOTB) d'adapter ledit traitement en fonction duditévènement. 3. Procédé selon la revendication 1 ou 2, comprenant un envol (C6), au premieragent 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 del'utiiisateur appelant.
  3. 4. 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 serveurd'applications (SA1), pour traiter une requête (RQ1) de communicationprovenant d'un premier terminal (TA) d'un utilisateur source (UA) visant à établirune communication avec un deuxième terminal (TB1) d'un utilisateur cible (UB),ledit serveur d'applications (SA2) étant compris dans un réseau decommunication (R2) associé au deuxième terminai (TB1) et ledit premier agentconversationnel automatisé (BOTB) étant situé hors dudit réseau decommunication (R2) ; vérification que des évènements indicatifs de la disponibilité de l'utilisateur cibleont été reçus en provenance du réseau de communication (R2) du deuxièmeterminal (TB1) et en provenance d'au moins un autre réseau de communication(RB) associé à l'utilisateur cible ; détermination de l'état de disponibilité du deuxième utilisateur à partir d'aumoins 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é del'utilisateur cible. dans lequel la commande de déclenchement (CMD1) reçue lors de l'étape deréception comprend un identifiant (IDBOTA) d'un deuxième agent conversationneli automatisé (BOTA) associé à l'utilisateur appelant (UA), ladite étape de contrôle à distance comprenant l'établissement d’une communicationentre les premier et deuxième agents conversationnels automatisés (BOTB, BOTA) via leserveur d'applications (SA2) afin de traiter collectivement ladite requête (RQ.I) decommunication.
  4. 5. Procédé selon la revendication 4, comprenant une réception d'une pluralité dedits événements indicatifs de la disponibilité de l'utilisateur cible, en provenance duréseau de communication (R2) du deuxième terminai (TB1) et en provenance dudit aumoins un autre réseau de communication (R3) associé à i'utih’sateur cible. 6. Procédé selon la revendication 4 ou 5, te traitement comprenant l'établissementd'un dialogue entre ie premier agent conversationnel automatisé (BOTB) et. au moins l'un parmi le premier terminai (TA) et le deuxième agent conversationnel automatisé (8OTA)associé à l'utilisateur appelant (UA).
  5. 7. Procédé selon l'une quelconque des revendications 4 à dans lequel lors del'é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 actionssuivantes : - obtention d'une donnée de disponibilité renseignant sur l'état de disponibilité del'utilisateur cible (UB) et commande d'envoi, par le serveur d'applications (SA2), deladite donnée de disponibilité à au moins l'un parmi le premier terminal (TA) et tedeuxième agent conversationnel automatisé (BOTB) ; - envoi d'une notification de communication audit au moins un autre réseau decommunication (R3) associé à l'utilisateur cible, ladite notification decommunication informant de la tentative de communication initiée par le premierterminal (TA) ; - définition, par l'intermédiaire du serveur d'applications (SA2), d'un rendez-vous encoopération avec le premier terminal (TA) ou 1e deuxième agent conversationnelautomatisé (BOTA), et enregistrement d'une nouvelle entrée indicative du rendez-vous 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 autreréseau de communication (RB) 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 decommunication ; et - surveillance de l'état de disponibilité courant de l'utilisateur cible et, sur détectionque 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 notificationinformant de l'état prédéfini à l'attention de l'utilisateur appelant.
  6. 8. Procédé selon l'une quelconque des revendications 4 à 7, comprenant uneréception, en provenance du serveur d'applications (SA2), d'un identifiant (ID-A) del’utilisateur appelant (UA), ledit traitement causé par le premier agent conversationnelautomatisé (BOTB) lors du contrôle à distance étant fonction dudit identifiant del'utilisateur appelant. 9. Procédé selon la revendication 8, comprenant une détermination d'un niveaud'urgence de la requête (RQ1) de communication à partir de l'identifiant (ID-A) del'utilisateur appelant (UA) ; et si 1e niveau d'urgence atteint un niveau prédéfini, le premier agent conversationnelautomatisé (BOTB) cause renvoi, par le serveur d'applications (SA2), d'une notificationd'urgence à l'attention de l'utilisateur cible (UB) via le réseau de communications (R2) ouvia ledit au moins un autre réseau de communications (R3).
  7. 10. Procédé selon l'une quelconque des revendications 4 à 9,. dans lequel, lors duditcontrôle à distance, les premier et deuxième agents conversationnels automatisés (BOTB,BOTA) échangent, via le serveur d'applications (SA2), des données associées auxutilisateurs appelant et cible de sorte à réaliser collectivement au moins une actionprédéterminée, 11. Programme d'ordinateur (PG2 ; PG3) comportant des instructions pour l'exécutiondes étapes d'un procédé selon l'une quelconque des revendications 1 à 10 lorsque leditprogramme est exécuté par un ordinateur. 12. Serveur d'applications (SA2) comprenant : un module de réception (MD2) configuré: pour recevoir une requête (RQ1) decommunication provenant d'un premier terminal (TA) d'un utilisateur appelant(UA), ladite requête visant à établir une communication avec un deuxièmeterminal (TB1) d'un utilisateur cible (UB). le serveur d'applications (SA2) étantcompris dans un réseau de communication (R2) associé au deuxième terminalσΒ1)Τ un module d'envoi (MD4) configuré pour envoyer, à un premier agentconversationnel automatisé (BOTB) associé à l'utilisateur cible (UB), unecommande de déclenchement (CMD1) pour activer ledit premier agentconversationnel automatisé, ce dernier étant, situé hors du réseau decommunication (R2) du deuxième terminal (TB1) pet un module de traitement (MD6) configuré pour réaliser un traitement de larequête de communication (RQ1) sous le contrôle du premier agentconversationnel automatisé (BOTB), ledit traitement comprenant l'établissementd'un dialogue entre le premier agent conversationnel automatisé (BOTB) et aumoins l'un parmi le premier terminal (TA) et un deuxième agent conversationnelautomatisé (BOTA) associé à l'utilisateur appelant (UA) ; dans lequel la requête (RQ1) de communication comprend un identifiant (ID-BOTA)du deuxième agent conversationnel automatisé (BOTA) associé à ('utilisateur appelant(UA), 1e module de traitement étant configuré pour que ledit traitement comprennerétablissement d'une communication entre les premier et deuxième agentsconversationnels automatisés (BOTB, BOTA) afin de traiter collectivement ladite requête(RQ1) de communication.
  8. 13. Agent conversationnel automatisé (BOTB) comprenant : un module de réception (MD10) configuré pour recevoir une commande dedéclenchement (CMD1) provenant d'un serveur d'applications (SA1), pour traiterune requête (RQ1) de communication provenant d'un premier terminal (TA) d'unutilisateur appelant (UA) visant à établir une communication avec un deuxièmeterminal (TB1) d’un utilisateur cible (UB), ledit serveur d'applications (SA2) étant compris dans un réseau decommunication (R2) associé au deuxième terminal (TB1) et ledit agentconversationnel automatisé (BOTB) étant situé hors dudit réseau decommunication (R2) ; un module de vérification (MD12) configuré pour vérifier si des évènementsindicatifs de la disponibilité de l'utilisateur cible ont été reçus en provenance duréseau de communication (R2) du deuxième terminal (TB.I) et en provenanced'au moins un autre réseau de communication (RB) associé à l'utilisateur cible ; un module de détermination (MD14) configuré pour déterminer l’état dedisponibilité 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 ie serveurd'applications (SA2) de sorte à réaliser un traitement: de la requête decommunication (RQ1) en fonction de l'état de disponibilité de l’utilisateur cible ; dans lequel la commande de déclenchement (CMD1) comprend un identifiant(IDBOTA) d'un deuxième agent conversationnel automatisé (BOTA) associé à l'utilisateurappelant (UA), le module de contrôle (MD16) étant configuré pour que le contrôle àdistance du serveur d'applications (SA2) comprenne l'établissement d'une communicationentre les premier et deuxième agents conversationnels automatisés (BOTB, BOTA) via leserveur d'applications (SA2) afin de traiter collectivement ladite requête (RQl) decommunication.
FR1662018A 2016-12-06 2016-12-06 Traitement d'une communication par un agent conversationnel automatise Active FR3059862B1 (fr)

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
FR1662018 2016-12-06
FR1662018A FR3059862B1 (fr) 2016-12-06 2016-12-06 Traitement d'une communication par un agent conversationnel automatise

Publications (2)

Publication Number Publication Date
FR3059862A1 FR3059862A1 (fr) 2018-06-08
FR3059862B1 true 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)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8054961B2 (en) * 2006-09-29 2011-11-08 Siemens Enterprise Communications, Inc. MeetMe assistant
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
FR3059862A1 (fr) 2018-06-08

Similar Documents

Publication Publication Date Title
US9888125B2 (en) Systems and methods for managing an event scheduling request in a telephony system
US9516167B2 (en) Media channel management apparatus for network communications sessions
EP1632081B1 (fr) Procede et systeme de communication d'un fichier de donnees sur une reseau et de teleconference sur un reseau de telephonie
US20140096209A1 (en) Pre-authenticated calling for voice applications
US9444936B2 (en) Interaction request processing according to client pre-configured schedule
US20120121077A1 (en) System and method for brokering communication dependent tasks
US20180103150A1 (en) Mobility bonding network
FR2931330A1 (fr) Procede et systeme d'enregistrement automatique d'une session de communication
US9635179B1 (en) Consumer care system
US20230308546A1 (en) System and methods for hybrid callback management using a callback cloud with call participant authentication
FR2983023A1 (fr) Procede de gestion de la mise en relation numerique.
FR3059862B1 (fr) Traitement d'une communication par un agent conversationnel automatise
EP1509031A1 (fr) Système et procédé d'acheminement intelligent des appels téléphoniques
EP3688974B1 (fr) Procédé de gestion d'un échec d'établissement d'une communication entre un premier et un second terminal
EP3035723B1 (fr) Procédé de transmission de données en relation avec une communication
EP3024182A1 (fr) Procédé et dispositif de gestion d'un message
CN113452829A (zh) 基于用户存在和偏好的语音消息的实时转录和馈送
EP3013024B1 (fr) Procédé de redirection d'une communication vers au moins un serveur de dépôt de messages
EP4173274B1 (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
EP3804253A1 (fr) Procédé de mise à jour d'une base de données d'un réseau de voix sur ip
EP2538646A2 (fr) Serveur d'application apte à contrôler une conférence téléphonique
EP1744508A2 (fr) Procédé de mise en relation interpersonnelle
FR2952262A1 (fr) Autorisation d'etablissement d'appels simultanes
US10542151B2 (en) System and method for using a mobile application operating on an advisor device to communicate with a client device
FR2962287A1 (fr) Procede et dispositif de generation d'un identifiant de communication

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

PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10