La présente invention concerne le domaine des robots de dialogues, notamment dans le cadre de la gestion d'événements.

Un robot de dialogue est un module conversationnel (programmé ou basé sur une intelligence artificielle) permettant d'interagir avec un utilisateur réel en langage naturel. Cette interaction peut être de tout type (ex. par voix, par texte, par vidéo, etc.).

On désigne par langage naturel le langage parlé par les hommes (par opposition au langage informatique).

Les robots de dialogue (ou « chatbot » en anglais) existants permettent le plus souvent à un utilisateur de poser une question. Le robot tente alors d'y répondre ou demande à l'utilisateur de préciser la question ou de confirmer la compréhension dudit robot. Un robot de dialogue est habituellement opéré dans un serveur, et il existe un canal de communication entre le robot et l'utilisateur (par exemple, une application de messagerie texte, comme Facebook Messenger ou Skype, ou un canal de communication par SMS) qui permet à un utilisateur d'interroger le robot.

Par exemple, un robot conversationnel peut être utilisé pour permettre à un utilisateur de :

- commander un billet de train (ex. « Bonjour, je souhaite réserver une place dans le prochain Paris-Marseille ») ;

- consulter la météo (ex. « Bonjour, dois-je prendre mon parapluie aujourd'hui ? ») ; - connaître les films à l'affiche au cinéma (ex. « Quel est le film à l'affiche avec un « proton pack » et des fantômes ? »). Néanmoins, les échanges entre les robots et les utilisateurs sont souvent instantanés :

- si un utilisateur revient discuter avec le robot plusieurs fois de suite, le robot n'aura aucune connaissance des échanges précédents ; - si un utilisateur confie un désir / un souhait au robot, le robot ne peut traiter l'information (le désir / le souhait étant un concept futur).

Il y a ainsi un besoin pour permettre au robot conversationnel de réagir, hors présence de l'utilisateur, à un souhait exprimé antérieurement par l'utilisateur.

La présente invention vient améliorer la situation. Selon un premier aspect, il est proposé un procédé d'alerte de la survenance d'un événement, mis en œuvre par des moyens informatiques, le procédé comprenant :

- réception d'une requête utilisateur ;

- interprétation de la requête utilisateur à l'aide d'un moteur sémantique et détermination d'une demande d'abonnement à un événement contenu dans la requête ;

- détermination d'un serveur d'événements en fonction de l'événement ;

- envoi au serveur d'événements d'une requête d'abonnement à l'événement ;

- réception d'un premier message associé à une survenance de l'événement ; - envoi d'un deuxième message informant de la survenance de l'événement.

Ainsi, l'événement faisant l'objet de la requête utilisateur peut être asynchrone par rapport à cette requête. Le moteur sémantique ne réalise donc pas une simple interaction immédiate avec l'utilisateur (i.e. une réponse instantanée de type « Question : Quel temps fait-il ? » « Réponse : La température extérieure est de 20°C »).

Au contraire, le procédé proposé permet de désynchroniser la question de l'utilisateur (ou l'expression de son souhait) et la réponse du robot de dialogue (ex. « Question : Pouvez-vous me prévenir lorsque le film de la soirée sur la chaîne 25 commence ? », « Réponse (asynchrone) : Le film 'Les visiteurs 3' commence dans 5 minutes »).

Bien entendu, il est peu envisageable de prévoir, au sein du robot de dialogue, l'ensemble des événements qui peuvent être demandés par l'utilisateur. La complexité de codage d'un tel robot de dialogue serait trop importante. Ainsi, dans un ou plusieurs modes de réalisation, en fonction de l'événement demandé par l'utilisateur, le robot de dialogue peut déléguer à un autre serveur (appelé serveur d'événements) la surveillance de l'événement : - un serveur de télévision pour des événements liés à des programmes télévisuels ;

- un serveur de bourse pour des événements liés à des cours boursiers ;

- un serveur d'alertes météo pour des événements liés à des événements météorologiques majeurs (ex. tempêtes, froids extrêmes, tsunamis, etc.) ; - etc.

Dès lors, en fonction de l'événement, un serveur d'événements spécifique pourra être identifié.

Par ailleurs, dans un mode de réalisation particulier du procédé proposé, le deuxième message peut être un message en langage naturel.

En effet, l'envoi dudit deuxième message en langage naturel permet une interaction aisée avec l'utilisateur.

Dans un mode de réalisation particulier du procédé proposé,, la requête utilisateur peut être reçue via un canal de communication textuelle.

En effet, l'interprétation des messages textuels en langage naturel est éprouvée et permet une implémentation aisée. En outre, dans un mode de réalisation particulier du procédé proposé, le moteur sémantique peut être un moteur utilisant une intelligence artificielle.

Ainsi, il est possible de réaliser un apprentissage spécifique dudit moteur sémantique pour lui permettre d'identifier spécifiquement une liste d'événements prédéfinis. Le taux de reconnaissance est donc amélioré.

Dans une réalisation particulière, la détermination du serveur peut être effectuée par une recherche dans une base de données de l'événement. À cet effet, il est possible de prévoir une base de données préétablie (par exemple, au sein du robot de dialogue) comportant une association entre les événements (ou les types d'événements) et le serveur d'événements.

De manière alternative ou en complément, la détermination du serveur d'événements peut comprendre, dans un ou plusieurs modes de réalisation :

- l'envoi d'un troisième message à un serveur d'interrogation, le troisième message comprenant l'événement ou un type de l'événement.

- la réception d'un quatrième message en provenance du serveur d'interrogation, le quatrième message comprenant une information relative au serveur d'événements.

Ainsi, il est possible de déléguer à un serveur tiers (ou serveur d'interrogation) la fonction d'identification du serveur d'événements à utiliser en fonction de l'événement demandé. Dès lors, la complexité d'implémentation du robot de dialogue s'en trouve réduite.

Selon un deuxième aspect, il est proposé un dispositif d'alerte de la survenance d'un événement, le dispositif comprenant : une interface configurée pour une réception d'une requête utilisateur ; un circuit implémentant un moteur sémantique pour l'interprétation de la requête utilisateur, le moteur sémantique étant apte à déterminer une demande d'abonnement à un événement contenu dans la requête ; un circuit configuré pour la détermination d'un serveur d'événements en fonction de l'événement ; une interface configurée pour l'envoi au serveur d'événements d'une requête d'abonnement à l'événement ; une interface configurée pour la réception d'un premier message associé à une survenance de l'événement ; une interface configurée pour l'envoi d'un deuxième message informant l'utilisateur de la survenance de l'événement.

Un programme informatique, mettant en œuvre tout ou partie du procédé décrit ci- avant, installé sur un équipement préexistant, est en lui-même avantageux.

Ainsi, selon un autre aspect, il est proposé un programme d'ordinateur, chargeable dans une mémoire associée à un processeur, et comprenant des portions de code pour la mise en œuvre du procédé proposé lors de l'exécution dudit programme par le processeur, ainsi qu'un ensemble de données représentant, par exemple par voie de compression ou d'encodage, ledit programme d'ordinateur.

Ce programme peut utiliser n'importe quel langage de programmation (par exemple, un langage-objet ou autre), et être sous la forme d'un code source interprétable, d'un code partiellement compilé ou d'un code totalement compilé. Une partie de la figure 1 décrite en détail ci-après peut former l'organigramme de l'algorithme général d'un tel programme informatique.

Un autre aspect concerne un support de stockage non-transitoire d'un programme exécutable par ordinateur, comprenant un ensemble de données représentant un ou plusieurs programmes, lesdits un ou plusieurs programmes comprenant des instructions pour, lors de l'exécution desdits un ou plusieurs programmes par un ordinateur comprenant une unité de traitement couplée de manière opérationnelle à des moyens mémoire et à un module d'interface entrées/sorties, conduire l'ordinateur à alerter de la survenance d'un événement selon le procédé proposé.

D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels :

- la figure 1 illustre un ordinogramme général dans un mode de réalisation particulier;

- la figure 2 illustre un exemple de dispositif dans un mode de réalisation particulier pour la mise en œuvre des procédés décrits dans les présentes.

La figure 1 illustre un ordinogramme général dans un mode de réalisation particulier.

Lorsqu'un utilisateur 151 souhaite être averti/alerté de la survenance d'un événement, il peut envoyer (101 ) sa requête 1 1 1 à un robot de dialogue 152. Cette requête est alors exprimée en langage naturel.

Cette requête peut être transmise textuellement (via une application de messagerie : email, SMS, FaceBook Messenger, Twitter, etc.), oralement (ex. par téléphone) ou encore visuellement (ex. par Skype).

Sur réception (102) de la requête 1 1 1 , le robot de dialogue 152 l'interprète (103) à l'aide d'une analyse syntaxique et/ou sémantique afin d'identifier la commande d'abonnement à un événement.

Une telle interprétation peut faire appel à des techniques de type « NLU » (pour « Natural Language Understanding » en anglais). Le robot de dialogue peut notamment s'appuyer sur un moteur d'intelligence artificiel, le moteur ayant préalablement été entraîné pour la reconnaissance spécifique d'une liste d'événements prédéfinis, par exemple.

Les événements visés par la requête de l'utilisateur peuvent être de manière non- limitative :

- une demande d'alerte lorsque le cours de bourse d'un titre est inférieur ou supérieur à un seuil prédéfini ;

- une demande d'alerte lorsqu'un fichier sur un serveur est modifié ;

- une demande d'alerte lorsqu'une émission TV est sur le point de débuter ;

- une demande d'alerte lorsqu'un produit sur un site de vente est de nouveau disponible ;

- une demande d'alerte lorsque la température extérieure est inférieure ou supérieure à un seuil prédéfini ;

- une demande d'alerte lorsque un utilisateur est en ligne / disponible ;

- une demande d'alerte lorsque un virement bancaire a été reçu ;

- etc.

Bien entendu, si le robot de dialogue a un doute concernant la commande d'abonnement ou concernant l'événement, il peut demander à l'utilisateur de préciser sa requête (non représentée).

Une fois l'événement identifié, il est possible de déterminer le serveur d'événements qui pourra traiter cette requête d'abonnement (104) :

(i) si le robot de dialogue possède une base de données permettant de trouver le serveur d'événements correspondant à l'événement (ou au type d'événement), cette détermination peut s'effectuer directement à l'aide de cette base de données ;

(ii) si le robot de dialogue ne possède pas une telle base ou si aucune correspondance n'existe dans cette base, le robot de dialogue peut envoyer un message à un serveur tiers (ou serveur d'interrogation) afin qu'il identifie, pour lui, un serveur d'événements susceptible de traiter la requête d'abonnement.

Une fois le serveur d'événements 153 identifié, il est possible d'envoyer un message 1 12 informant ledit serveur d'événements 153 de la demande utilisateur. Le serveur d'événements stocke alors cette demande (105).

Lorsque l'événement survient, le serveur d'événements 153 peut alors en être averti (ex. base de données temps réel, base de données temps comportant des fonctions de type « trigger », mécanisme dit de « push »). Il est également possible que le serveur d'événements 153 vérifie régulièrement l'état de l'événement demandé (ex. survenance ou non-survenance). Le serveur d'événements 153 peut alors construire un message 1 13 (106) afin d'informer le robot de dialogue de la survenance.

Lors de la réception du message 1 13 (107), le robot de dialogue peut effectuer un certain nombre d'actions (ex. mis à jour d'une base de données, mise à jour d'un système de facturation, insertion d'une entrée dans un journal d'historique). Ces actions peuvent être préprogrammées ou peuvent dépendre de l'événement. Il est aussi possible de déterminer (108) à quel(s) utilisateur(s) correspond l'événement associé au message 1 13 (i.e. Ies/I'utilisateur(s) ayant demandé d'être averti de la survenance de l'événement) : cette information peut être contenue dans le message 1 13 ou cette information peut avoir préalablement été stockée par le robot de dialogue dans une base de données locale (ex. « l'utilisateur X a demandé la surveillance de l'événement Y »).

Une fois l'utilisateur identifié, il est possible de créer (109) un message 1 14, en langage naturel par exemple, afin d'informer (1 10) l'utilisateur de la survenance de l'événement.

Il est proposé selon un autre aspect un procédé de désabonnement, dont un ou plusieurs modes de réalisation peuvent être décrits de manière similaire au procédé d'abonnement décrit en relation de la figure 1 . Dès lors les considérations précédentes s'appliquent également au procédé de désabonnement proposé. Lorsqu'un utilisateur 151 souhaite se désabonner d'un événement auquel il est abonné, il peut envoyer sa requête à un robot de dialogue 152. Cette requête peut être alors exprimée en langage naturel.

Sur réception de la requête de désabonnement, le robot de dialogue 152 l'interprète à l'aide d'une analyse syntaxique et/ou sémantique afin d'identifier la commande de désabonnement.

Bien entendu, si le robot de dialogue a un doute concernant la commande de désabonnement ou concernant l'événement visé par ce désabonnement, il peut demander à l'utilisateur de préciser sa requête.

Une fois l'événement identifié, il est possible de déterminer le serveur d'événements qui pourra traiter cette requête de désabonnement :

(i) si le robot de dialogue possède une base de données permettant de trouver le serveur d'événements correspondant à l'événement (ou au type d'événement), cette détermination peut s'effectuer directement à l'aide de cette base de données ;

(ii) si le robot de dialogue possède une base de données stockant le serveur identifié lors de la phase d'abonnement, cette détermination peut s'effectuer directement à l'aide de cette base de données ;

(iii) si le robot de dialogue ne possède pas de telles bases ou si aucune correspondance n'existe dans cette base, le robot de dialogue peut envoyer un message à un serveur tiers (ou serveur d'interrogation) afin qu'il identifie, pour lui, un serveur d'événements susceptible de traiter la requête de désabonnement.

Une fois le serveur d'événements 153 identifié, il est possible d'envoyer un message informant ledit serveur d'événements 153 de la demande utilisateur. Le serveur d'événements :

- supprime l'information selon laquelle l'utilisateur a demandé à être averti de la survenance de l'événement, ou

- annule la demande de l'utilisateur d'être averti de la survenance de l'événement. Bien entendu, si la demande de désabonnement ne correspond pas à un événement pour lequel l'utilisateur s'est abonné, le serveur d'événements ou le robot peut ignorer la demande de l'utilisateur ou l'informer de ce fait.

La demande de désabonnement de l'utilisateur peut être une demande de désabonnement temporaire (ex. « Ne me préviens pas de la vente de l'objet X durant les 3 prochaines heures »). Ainsi, le robot peut procéder au procédé de désabonnement décrit précédemment puis, une fois la fin de la période temporaire atteinte, procéder au réabonnement auprès du serveur d'événements, ou simplement filtrer les messages du serveur d'événements afin de ne pas transmettre les messages 1 14 durant la période temporaire.

La demande de désabonnement peut être générique (ex. « Désabonne-moi des événements relatifs à la télévision »). Sous cette hypothèse, le robot de discussion 152 peut identifier plusieurs événements et/ou plusieurs serveurs pour lesquels un désabonnement doit être effectué. Bien entendu, la demande de désabonnement peut être plus complexe (ex. générique et temporaire).

La figure 2 représente un exemple de dispositif dans un mode de réalisation particulier pour la mise en œuvre des procédés décrits dans les présentes. Dans ce mode de réalisation, le dispositif 200, comprend une mémoire 205 pour stocker des instructions permettant la mise en œuvre du procédé proposé, et des données temporaires pour réaliser les différents modes de réalisation du procédé proposé tel que décrits précédemment.

Le dispositif comporte en outre un circuit de commande 204. Ce circuit de commande peut être, par exemple :

- un processeur apte à interpréter des instructions sous la forme de programme informatique, ou

- une carte électronique configurée par description dans le silicium du procédé proposé, ou encore - une puce électronique programmable comme une puce FPGA (pour « Field- Programmable Gâte Array » en anglais).

Le dispositif comporte une interface d'entrée 203 pour la réception de la requête utilisateur (notamment), et une interface de sortie 206 pour la fourniture du message informant l'utilisateur de la survenance de l'événement. Enfin, le dispositif peut comporter, pour permettre une interaction aisée avec un utilisateur, un écran 201 et un clavier 202. Bien entendu, le clavier est facultatif, notamment dans le cadre d'un dispositif ayant la forme d'un serveur, par exemple.

En fonction du mode de réalisation, le dispositif 200 peut être un ordinateur, un réseau d'ordinateurs, un composant électronique, ou un autre appareil comportant un processeur couplé de manière opérationnelle à une mémoire, ainsi que, selon le mode de réalisation choisi, une unité de stockage de données, et d'autres éléments matériels associés comme une interface de réseau et un lecteur de support pour lire un support de stockage amovible et écrire sur un tel support (non représentés sur la figure). Le support de stockage amovible peut être, par exemple, un disque compact (CD), un disque vidéo/polyvalent numérique (DVD), un disque flash, une clé USB, etc. En fonction du mode de réalisation, la mémoire, l'unité de stockage de données ou le support de stockage amovible contient des instructions qui, lorsqu'elles sont exécutées par le circuit de commande 204, amènent ce circuit de commande 204 à effectuer ou contrôler les parties interface d'entrée 203, interface de sortie 206, stockage de données 205 et/ou traitement de données des exemples de mise en œuvre du procédé proposé décrits dans les présentes. Le circuit de commande 204 peut être un composant implémentant un processeur ou une unité de calcul pour l'alerte de la survenance d'un événement selon le procédé proposé et le contrôle des unités 203, 205 et 206 du dispositif 200.

En outre, le dispositif 200 peut être mis en œuvre sous forme logicielle, auquel cas il prend la forme d'un programme exécutable par un processeur, ou sous forme matérielle (ou « hardware »), comme un circuit intégré spécifique application (ASIC), un système sur puce (SOC), ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA (Field Programmable Gâte Array). Les SOC {System On Chip) ou système sur puce sont des systèmes embarqués qui intègrent tous les composants d'un système électronique dans une puce unique. Un ASIC {Application Spécifie Integrated Circuit) est un circuit électronique spécialisé qui regroupe des fonctionnalités sur mesure pour une application donnée. Les ASIC sont généralement configurés lors de leur fabrication et ne peuvent être que simulés par l'utilisateur. Les circuits logiques programmables de type FPGA (Field-Programmable Gâte Array) sont des circuits électroniques reconfigurables par l'utilisateur.

Le dispositif 200 peut également utiliser des architectures hybrides, comme par exemple des architectures basées sur un CPU+FPGA, un GPU {Graphics Processing Unit) ou un MPPA {Multi-Purpose Processor Array).

Par ailleurs, le schéma fonctionnel présenté sur la figure 1 est un exemple typique d'un programme dont certaines instructions peuvent être réalisées auprès du dispositif d'alertes décrit. À ce titre, la figure 1 peut correspondre à l'organigramme de l'algorithme général d'un programme informatique dans un mode de réalisation particulier.

Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemples ; elle s'étend à d'autres variantes.

D'autres réalisations sont possibles.

En fonction du mode de réalisation choisi, certains actes, actions, événements ou fonctions de chacune des méthodes décrites dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans certains modes de réalisation, certains actes, actions ou événements sont effectués ou se produisent concurremment et non pas successivement. Bien que décrits à travers un certain nombre d'exemples de réalisation détaillés, le procédé d'alerte proposé et l'équipement pour la mise en œuvre du procédé comprennent différentes variantes, modifications et perfectionnements qui apparaîtront de façon évidente à l'homme de l'art, étant entendu que ces différentes variantes, modifications et perfectionnements font partie de la portée de l'invention, telle que définie par les revendications qui suivent. De plus, différents aspects et caractéristiques décrits ci-dessus peuvent être mis en œuvre ensemble, ou séparément, ou bien substitués les uns aux autres, et l'ensemble des différentes combinaisons et sous combinaisons des aspects et caractéristiques font partie de la portée de l'invention. En outre, il se peut que certains systèmes et équipements décrits ci-dessus n'incorporent pas la totalité des modules et fonctions décrits pour les modes de réalisation préférés.