FR3094809A1 - Procédé et dispositif pour la gestion d’évènements - Google Patents

Procédé et dispositif pour la gestion d’évènements Download PDF

Info

Publication number
FR3094809A1
FR3094809A1 FR1903521A FR1903521A FR3094809A1 FR 3094809 A1 FR3094809 A1 FR 3094809A1 FR 1903521 A FR1903521 A FR 1903521A FR 1903521 A FR1903521 A FR 1903521A FR 3094809 A1 FR3094809 A1 FR 3094809A1
Authority
FR
France
Prior art keywords
data
action
user data
rules
user
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.)
Pending
Application number
FR1903521A
Other languages
English (en)
Inventor
Thibault Serot
Maxime GODEAU
Jeremy TEYSSEDRE
Mathieu Philippe Alexis BEYNEL
Amar Muharemovic
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.)
Amadeus SAS
Original Assignee
Amadeus SAS
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 Amadeus SAS filed Critical Amadeus SAS
Priority to FR1903521A priority Critical patent/FR3094809A1/fr
Priority to US16/837,473 priority patent/US11868316B2/en
Publication of FR3094809A1 publication Critical patent/FR3094809A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/1734—Details of monitoring file system events, e.g. by the use of hooks, filter drivers, logs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Databases & Information Systems (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • Economics (AREA)
  • Artificial Intelligence (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Evolutionary Computation (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Medical Informatics (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Multimedia (AREA)
  • Computational Linguistics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Les modes de réalisation de l’invention fournissent un dispositif de gestion d’événements (1) pour gérer des événements comprenant un détecteur d’événement (101) configuré pour détecter l’apparition d’un événement lié aux données transmises par un système de transmission de données (10) et pour extraire des données d’utilisateur relatives à l’événement détecté d’un stockage de données d’utilisateur (11), les données d’utilisateur extraites comprenant les données d’utilisateur stockées dans au moins une entrée du stockage de données d’utilisateur (11). Le dispositif de gestion d’événements comprenant par ailleurs un gestionnaire de règles (102) configuré pour déterminer une ou plusieurs actions à exécuter en appliquant une ou plusieurs règles utilisant les données d’utilisateur extraites, le dispositif de gestion d’événements (1) étant configuré pour déclencher l’exécution d’au moins une action déterminée. Le système peut par ailleurs actualiser les règles de façon dynamique en utilisant les données de rétroaction reçues pour lesdites actions exécutées. Figure pour l’abrégé : Fig. 1

Description

PROCÉDÉ ET DISPOSITIF POUR LA GESTION D’ÉVÈNEMENTS
La présente invention concerne de façon générale la gestion d’informations et plus spécifiquement un dispositif de gestion d’évènements, un procédé et un programme d’ordinateur.
CONTEXTE
Les systèmes informatiques modernes, tels que le système de transmission de données, collectent un immense volume de données provenant de diverses sources de données, incluant les données d’utilisateur nécessaires pour les applications en cours d’exécution dans les systèmes.
Un système de transmission de données comprend généralement une ou plusieurs structures de donnée dans lesquelles sont agrégées les données d’utilisateur reçues de ces sources de données. Un système de transmission de données entre généralement ces données d’utilisateur de façon statique dans les applications en cours d’exécution dans le système.
Cependant, les systèmes de transmission de données modernes sont soumis à de fortes contraintes en matière de temps de réponse. Cela implique de traiter un important volume de données avec des performances computationnelles élevées afin de pouvoir transmettre une réponse aux dispositifs clients avec une faible latence.
Les données transmises par un système de transmission de données sont généralement transmises pour un ensemble donné d’utilisateurs, en réponse à une demande d’un client reçue d’un dispositif client. Les données transmises peuvent représenter, par exemple, des produits qui seront utilisés par l’ensemble des utilisateurs, tels que des billets de voyage, des billets de spectacle, des livres électroniques, des articles de vidéo ou de musique, etc. Dans le processus de transmission de données aux dispositifs client pour un ensemble donné d’utilisateurs, les utilisateurs sont généralement identifiés dans le système de transmission de données en utilisant des informations relatives aux utilisateurs. Le système de transmission de données conserve généralement ces données d’utilisateur dans une ou plusieurs structures de donnée de stockage. Le système de transmission de données peut aussi récupérer des données supplémentaires relatives à l’utilisateur à partir de diverses sources de données hétérogènes (internes ou externes au système).
Ces données d’utilisateur représentent un immense volume de données hétérogènes conservées par le système de transmission de données qui constituent les ressources clés. Les systèmes de transmission de données existants utilisent un nombre d’applications qui nécessitent un accès à ces données d’utilisateur. L’exécution de ces applications nécessite généralement d’importantes ressources computationnelles en raison de l’hétérogénéité des données d’utilisateur, la diversité des sources desquelles elles sont reçues et le nombre très important d’utilisateurs associé à ces données, ce qui peut augmenter la latence globale du système de transmission de données.
Par ailleurs, un système de transmission de données exécute aussi un nombre d’applications ou est connecté à des applications externes qui peuvent être impactées en temps réel par des événements liés aux données d’utilisateur conservées par le système de transmission de données.
Cependant, les systèmes de transmission de données existants ne sont pas capables de détecter ces événements en temps réel de façon dynamique tout en maintenant un temps de réponse optimal et un haut niveau de disponibilité des données d’utilisateur.
Un système amélioré de transmission de données capable de détecter en temps réel de façon dynamique des événements liés aux données d’utilisateur est donc nécessaire.
RÉSUMÉ
Pour surmonter ces problèmes, un dispositif de gestion d’évènements pour gérer des évènements est fourni. Le dispositif comprend un détecteur d’événements configuré pour détecter l’apparition d’un événement lié à des données délivrées par un système de transmission de données et pour extraire des données d’utilisateur relatives à l’événement détecté d’un stockage de données d’utilisateur, les données d’utilisateur extraites comprenant les données d’utilisateur stockées dans au moins une entrée du stockage de données d’utilisateur. Le dispositif de gestion d’événements comprenant par ailleurs un gestionnaire de règles configuré pour déterminer une plusieurs actions à exécuter en appliquant une ou plusieurs règles utilisant les données d’utilisateur extraites, le dispositif de gestion d’événements étant configuré pour déclencher l’exécution d’au moins une action déterminée.
Dans un mode de réalisation, le gestionnaire de règles comprend une mémoire de règles pour stocker des règles et un moteur de règles pour gérer les règles stockées dans la mémoire de règles.
Chaque règle comprend une partie conditions comprenant une combinaison logique d’au moins une condition et une partie actions comprenant une combinaison logique d’au moins une action, le moteur de règles étant configuré pour déterminer ladite au moins une action à exécuter de la partie actions de chaque règle appliquée en fonction de la vérification de la combinaison logique de conditions de la règle appliquée.
Dans certains modes de réalisation, les règles peuvent être stockées dans la mémoire de règles sous forme d’une ou de plusieurs structures de donnée d’arbre associées aux règles, le moteur de règles étant configuré pour appliquer une règle aux données extraites en analysant au moins une structure de donnée d’arbre.
Chaque structure de donnée d’arbre peut être associée à une règle donnée de la mémoire de règles et représente la partie conditions de la règle.
Dans certains modes de réalisation, le dispositif comprend par ailleurs une unité d’extraction de données configurée pour extraire les données d’utilisateur du stockage de données d’utilisateur en réponse à l’événement détecté, l’unité d’extraction de données étant par ailleurs configurée pour extraire des données liées à l’événement de l’événement détecté.
L’unité d’extraction de données est configurée pour générer un fichier de description intégrant les données d’utilisateur extraites et/ou les données relatives à l’événement extrait, le fichier de description étant utilisé par le gestionnaire de règles pour déterminer ladite au moins une action à exécuter.
Dans certains modes de réalisation, le gestionnaire de règles est configuré pour sélectionner ladite une ou plusieurs règles à appliquer en utilisant les données d’utilisateur extraites et/ou les données liées à l’événement extraites de l’événement détecté et/ou les données de sources de données externes.
Le stockage de données d’utilisateur comprend une ou plusieurs entrées, les données d’utilisateur stockées dans chaque entrée du stockage de données d’utilisateur comprenant des informations d’utilisateur relatives aux données transmises par ledit système de transmission de données à l’ensemble des utilisateurs.
Dans certains modes de réalisation, le dispositif comprend un moteur d’apprentissage automatique configuré pour déterminer un score de pertinence d’action pour chaque action exécutée, en utilisant des valeurs de rétroaction reçues pour l’action exécutée au cours d’une période.
Le dispositif est configuré pour actualiser les règles de façon dynamique dans la mémoire de règles sur la base des scores de pertinence d’action déterminés pour les actions exécutées associées aux règles.
Dans certains modes de réalisation, le dispositif peut par ailleurs comprendre une base de données de pertinence d’action configurée pour stocker, pour chaque action exécutée, le score de pertinence d’action déterminée pour l’action par le moteur d’apprentissage automatique. Le gestionnaire de règles peut ensuite être configuré pour déterminer une action à exécuter sous la forme d’une combinaison logique d’actions utilisant au moins un opérateur booléen, le système étant configuré pour déclencher l’exécution d’au moins une des actions de la combinaison logique déterminée par le gestionnaire de règles sur la base du score de pertinence d’action associé aux actions de la combinaison logique dans la base de données de pertinence d’actions.
Il est par ailleurs fourni un procédé pour gérer des événements dans un système de transmission de données. Le procédé comprend :
– la détection de l’apparition d’un événement relatif aux données transmises par le système de transmission de données,
– l’extraction des données d’utilisateur relatives à l’événement d’un stockage de données d’utilisateur, les données d’utilisateur extraites comprenant des données d’utilisateur stockées dans au moins une entrée du stockage de données d’utilisateur,
– la détermination d’une ou plusieurs actions à exécuter en appliquant une ou plusieurs règles utilisant les données d’utilisateur extraites comprises dans chacune des entrées du stockage de données d’utilisateur,
– le déclenchement de l’exécution de ladite au moins une action déterminée.
Il est également fourni un programme d’ordinateur comprenant des instructions de code de programme pour exécuter le procédé conformément aux modes de réalisation précités lorsque le programme fonctionne sur un ordinateur.
Les modes de réalisation de l’invention permettent de détecter de façon dynamique en temps réel des événements liés à des données d’utilisateur et de déclencher des actions en réponse aux événements détectés. Ils permettent par ailleurs d’actualiser les règles utilisées pour déclencher des actions en utilisant des données de méta-apprentissage.
Les dessins en annexe qui sont incorporés et constituent une partie de cette spécification, illustrent divers modes de réalisation de l’invention et, avec la description générale de l’invention ci-dessus et la description détaillée des modes de réalisation donnée ci-dessous, servent à expliquer les modes de réalisation de l’invention. Dans les dessins, des références à des chiffres similaires sont utilisées pour indiquer des éléments similaires dans les diverses visualisations.
La est un diagramme bloc de l’environnement d’un système de transmission de données implémentant un dispositif de gestion d’événements, conformément à certains modes de réalisation ;
La est un diagramme bloc d’un exemple d’environnement d’exploitation adapté à l’implémentation des aspects de la présente invention.
La est un diagramme bloc d’un dispositif de détection d’événements, conforme à des modes de réalisation ;
La est un organigramme décrivant un procédé pour gérer des événements, conformément à des modes de réalisation ;
La est un organigramme décrivant un procédé pour gérer des règles en utilisant des données de rétroaction, conformément à un mode de réalisation ;
La montre une structure de donnée d’arbre utilisée pour représenter un exemple de règle gérée par le gestionnaire de règles, conformément à un mode de réalisation ; et
La est une vue schématique d’un exemple de système de fonctionnement pour héberger un composant du dispositif de gestion d’événements.
La Figure 1 montre un exemple d’environnement 100 d’un système de transmission de données 10 configuré pour transmettre des données à un ou plusieurs utilisateurs via des dispositifs clients 2. Le système de transmission de données 10 peut utiliser une ou plusieurs structures de donnée 11 (également appelées ci-après « stockage de données d’utilisateur ») configurées pour stocker des données d’utilisateur relatives aux utilisateurs, telles que des données d’utilisateur qui sont collectées à partir d’une ou plusieurs sources de données. Le stockage de données d’utilisateur 11 peut être inclus dans le système de transmission de données 10 ou stocké dans un système externe connecté au système de transmission de données.
Selon des modes de réalisation, le système de transmission de données 10 peut comprendre un dispositif de gestion d’événements 1 configuré pour détecter des événements liés aux données transmises par un système de transmission de données (10) tels que des événements ayant un impact sur les données transmises par le système de transmission de données aux utilisateurs et pour déclencher des actions en réponse aux événements détectés en utilisant des règles. Le dispositif de gestion d’événements 1 peut comprendre un détecteur d’événements 101 configuré pour détecter l’apparition d’un événement et pour sélectionner des données d’utilisateur relatives à l’événement détecté dans un stockage de données d’utilisateur 11, les données d’utilisateur sélectionnées comprenant les données d’utilisateur liées à au moins une entrée du stockage de données d’utilisateur 11. Le dispositif de gestion d’événements 1 peut par ailleurs comprendre un gestionnaire de règles 102 configuré pour déterminer une ou plusieurs actions à déclencher en appliquant une ou plusieurs règles basées sur des événements (appelées ci-après « règles ») utilisant les données d’utilisateur sélectionnées, en lien avec chaque entrée dans le stockage de données d’utilisateur. Le dispositif de gestion d’événements 1 peut ensuite déclencher l’exécution d’au moins certaines des actions déterminées.
Un « événement », tel qu’utilisé ici, fait référence à tout événement lié à des données transmises par le système de transmission de données 10. Une « règle » peut dépendre de données relatives à un événement détecté et/ou à des données d’utilisateur extraites du stockage de données d’utilisateur et/ou à des données provenant de sources de données externes telles que des conditions météorologiques.
Dans certains modes de réalisation, le dispositif de gestion d’événements 1 peut par ailleurs être configuré pour actualiser les règles de façon dynamique sur la base d’un score de pertinence d’action déterminé, pour chaque action exécutée, en utilisant des valeurs de rétroaction reçues pour une action exécutée au cours d’une période, conformément à un processus d’apprentissage automatique visant les règles.
Le détecteur d’événements 101 surveille ainsi l’apparition d’événements qui peuvent avoir un impact sur les données transmises précédemment à des utilisateurs ou qui sont en cours de transmission à des utilisateurs, afin de déclencher de façon dynamique des actions en fonction des événements détectés.
Le système de transmission de données 10 peut être connecté à un ou plusieurs dispositifs clients 2 via un ou plusieurs réseaux de communication 5.
Chaque dispositif client 2 peut être un dispositif informatique personnel, une tablette informatique, un terminal client léger (thin client), un smartphone et/ou un autre dispositif informatique de ce genre. Chaque dispositif client 2 peut héberger des navigateurs Web et/ou un logiciel d’applications personnalisées (p. ex. un système client), et peut inclure une interface utilisateur client.
Chaque dispositif client 2 peut par ailleurs inclure une application de navigateur Web qui communique avec une application de serveur Web hébergée par le système de transmission de données 10.
Le réseau de communication 5 peut inclure un ou plusieurs réseaux privés et/ou publics (p. ex. Internet) qui permettent l’échange de données, tels qu’Internet, un réseau de zone locale (LAN), un réseau de zone étendue (WAN), un réseau cellulaire voix/données, une ou plusieurs connexions par bus à grande vitesse et/ou d’autres types de réseaux de communication de ce genre. Chaque réseau de communication 5 peut utiliser des technologies de communication normales et/ou des protocoles tels que 4G, Ethernet, 802.11, TCP/IP (Protocole de contrôle de transmission/Protocole Internet), HTTP (Protocole de transport hypertexte), FTP (Protocole de transfert de fichier), etc. Les données peuvent être échangées sur chaque réseau 5 selon des technologies d’échange de données différentes et/ou des formats tels que le langage de balisage hypertexte (HTML), le modèle JSON et le langage de balisage étendu (XML).
Le stockage de données d’utilisateur 11 peut stocker diverses données d’utilisateur relatives à des utilisateurs du système de transmission de données 10.
Tel qu’utilisé ici, un « utilisateur » du système de transmission de données 10 fait référence à un utilisateur associé à des données transmises par le système de transmission de données 10 à un dispositif client 2, l’utilisateur étant identifié au cours du processus de transmission de données à l’utilisateur pour indiquer que cet utilisateur sera le consommateur des données. Un utilisateur peut être identifié en soumettant un ensemble d’informations relatives à l’utilisateur au système de transmission de données 10, en réponse à la sélection de données par l’utilisateur lui-même ou par un autre utilisateur différent pour l’utilisateur et agissant pour le compte de l’utilisateur des données via un dispositif client 2.
Tel qu’utilisé ici les « données » transmises par le système de transmission de données font référence à tout contenu qui peut être fourni à un dispositif client 2 via une interface utilisateur sous la forme de produits, chaque produit étant potentiellement associé à un ou plusieurs produits complémentaires relatifs aux produits (représentant les services complémentaires). Le terme « produit » sera également utilisé ci-après pour faire référence aux données transmises par le système de transmission de données. Chaque produit peut être représenté par un ensemble de paramètres. Dans certains modes de réalisation, un produit peut être associé à une valeur de produits (également appelée « prix du produit »). Chaque produit peut être sous-divisé en parties élémentaires (également appelées ci-après « segments »). Un segment d’un produit fait référence à la plus petite portion d’un produit qui peut être délivré par le système de transmission de données 10.
Une représentation des produits délivrés par le système de transmission de données 10 peut être générée sur une interface graphique d’utilisateur d’un dispositif client 2 en utilisant divers éléments de représentation tels que du texte électronique, des images, des photos, des enregistrements audio et d’autres formes de données qui peuvent être traitées, stockées et renvoyées.
Dans certains modes de réalisation, un produit peut être délivré à un groupe d’utilisateurs comprenant deux ou plusieurs utilisateurs, dans une même session de transmission de produits, en réponse à une requête de client unique, par exemple pour la livraison d’un divertissement, d’un produit hôtelier de voyage à un groupe d’utilisateurs qui souhaitent participer ensemble à une activité de divertissement (musées, théâtre, représentation, etc.), réserver une chambre dans le même hôtel le même jour, voyager ensemble.
En réponse à une requête d’un client comprenant un ensemble de paramètres de requête, le système de transmission de données 10 peut effectuer une recherche dans une base de données de produits en utilisant un algorithme de recherche implémenté par le moteur de recherche pour déterminer un ensemble de produits candidats correspondant à la requête du client. L’ensemble des produits candidats peut être filtré en utilisant divers critères de filtrage. Dans un mode de réalisation, l’ensemble des produits candidats peut être filtré en utilisant des données de disponibilité représentant la disponibilité en temps réel ou quasiment en temps réel des produits candidats et/ou des informations relatives à la valeur des produits tels que les prix des produits candidats. Les produits filtrés peuvent être ordonnés en fonction d’un ensemble de critères d’ordre, tels que les valeurs des produits. Un résultat des produits filtrés peut être généré sur l’interface client du dispositif client 2 à partir duquel la requête a été émise. L’affichage peut prendre en compte l’ordre des produits filtrés.
L’utilisateur qui a émis la requête à partir du dispositif client 2 peut sélectionner un des produits candidats affichés et initier une session de réservation pour réserver le produit sélectionné pour un plusieurs les utilisateurs. La session de réservation peut être finalisée sous réserve de l’aboutissement réussi d’une transaction de réservation ou d’une transaction de paiement consistant à recevoir un paiement qui correspond à une valeur (prix) déterminée à partir de la valeur de produit (prix du produit) associée au produit.
La session de réservation peut par ailleurs inclure de solliciter et de recevoir des informations relatives à l’ensemble des utilisateurs pour lequel le produit sera livré.
Une entrée peut être créée dans le stockage de données d’utilisateur 11 en réponse à la réservation du produit pour l’ensemble identifié des utilisateurs. Un identifiant d’entrée peut être attribué à chaque entrée créée dans le stockage de données d’utilisateur. L’entrée associée à l’ensemble identifié des utilisateurs pour le produit sélectionné peut inclure :
– Des informations d’utilisateur relatives à l’ensemble des utilisateurs et comprenant i) des informations d’utilisateur reçues du dispositif client émetteur 2 au cours de la session de réservation et ii) des informations d’utilisateur supplémentaires récupérées à partir d’autres bases de données d’utilisateur connectées au système de transmission de données en utilisant les identifiants d’utilisateur correspondant à chaque utilisateur de l’ensemble des utilisateurs ;
– Des informations de produits relatives aux produits réservés pour l’ensemble des utilisateurs au cours de la session de réservation.
– Des informations de système de transmission de données comprenant des informations relatives au système de transmission de données.
Dans un exemple d’ application de l’invention pour un système de transmission de produits de voyage 10, les données d’utilisateur stockées dans le stockage de données 11 peuvent être des données relatives au voyageur(s) et les informations relatives aux données transmises par ledit système de transmission de données peuvent être des informations de produit de voyage telles qu’un produit de vol (billets d’avion).
Les informations d’utilisateur peuvent inclure :
– Des informations personnelles associées à chaque utilisateur de l’ensemble des utilisateurs telles que le nom de l’utilisateur, le genre de l’utilisateur, la nationalité, le lieu et la date de naissance, l’adresse, l’identifiant, le numéro de téléphone, les détails du passeport, etc. ;
– Les informations de profil d’utilisateur comprenant des informations relatives au profil du client de chaque utilisateur (utilisateur fréquent, réservations antérieures, préférences de l’utilisateur, etc.).
Dans un exemple d’application de l’invention à un système de transmission de produits de voyage 10 délivrant des produits de voyage à un utilisateur en réponse à une requête de voyage comprenant des paramètres de requête, le stockage de données d’utilisateur 11 peut être un fichier appelé « fichier de nom de passager (PNR) », stocké dans une base de données d’un système de réservation informatique (CRS). Dans cet exemple d’application, le stockage de données d’utilisateur 11 (PNR) peut comprendre pour chaque utilisateur (appelé un « passager ») diverses données collectées à partir d’une ou plusieurs sources de données :
– Des informations personnelles associées au passager, telles que le nom du passager et/ou les informations de contact du passager et/ou les informations d’identification relatives à l’utilisateur qui a demandé le produit et effectué la transaction ;
– Des informations de produit (p. ex. des informations d’itinéraire) correspondant aux produits achetés par le passager ou par un groupe de passagers voyageant ensemble et/ou des détails d’identification de produit (référence ou numéro du produit, durée limite d’utilisation du produit).
Dans un exemple d’application de l’invention où le système de transmission de données 10 peut être configuré pour délivrer des produits de voyage hétérogènes, les PNR peuvent être utilisés pour tout type de produits délivrés par le système de transmission de données (billets d’avion ou de train, réservation de chambres d’hôtel, voiture, etc.).
Le PNR peut également stocker des informations d’utilisateur supplémentaires telles que les données de programme de fidélisation, les préférences de l’utilisateur (p. ex. les demandes de type de sièges), les demandes particulières de l’utilisateur (SSR) (p. ex. des exigences de repas, une assistance en fauteuil roulant, des enfants non accompagnés) et/ou des informations de produits supplémentaires telles que le montant des taxes payées par d’autres entités pour le produit, le type de paiement, etc.
Un fichier PNR peut être créé dans la base de données d’utilisateur 11, en réponse à la sélection d’un produit par un utilisateur pour le passager(s) et la finalisation d’une transaction d’achat par l’utilisateur pour le produit. Le CRS peut faire partie d’un système centralisé de distribution de données, tel qu’un système de distribution global GDS, partagé par plusieurs systèmes de transmission de données ou un CRS indépendant. Chaque fichier PNR créé peut être identifié dans la base de données d’utilisateur 11 en utilisant en identifiant d’entrée (également appelé « localisateur d’enregistrement » dans une application de l’invention à un PNR). Le localisateur d’enregistrement associé à l’entrée d’utilisateur dans le stockage de données d’utilisateur 11 peut être un identifiant alpha ou alphanumérique qui sera associé à l’entrée d’utilisateur dans le stockage de données d’utilisateur 11, même si l’entrée est modifiée par la suite. Le localisateur d’enregistrement peut aussi être désigné comme numéro de confirmation, numéro de réservation, code de confirmation, références de réservation, numéro de PNR, et ainsi de suite.
Des copies de l’information de PNR peuvent être envoyées aux CRS d’autres systèmes de transmission de données connectés qui délivrent des produits similaires. Les CRS recevant les copies du PNR créé peuvent créer à leur tour des copies du PNR créées dans leur propre stockage de données d’utilisateur 11 afin de pouvoir délivrer d’autres portions demandées de l’itinéraire de l’utilisateur. Autrement, plusieurs systèmes de transmission de données délivrant des produits similaires peuvent héberger leur CRS dans un GDS et partager leurs PNR par l’entremise du GDS. Les localisateurs d’enregistrement des PNR copiés sont communiqués en retour au CRS qui détient le PNR créé. Des mises à jour du PNR peuvent ensuite être échangées lorsque le statut du voyage change dans un quelconque des CRS.
Chaque composant/champ (nom d’utilisateur, informations de produits, durée limite du produit, etc.) d’un PNR peut être identifié par un code.
Un PNR sert donc d’identifiant unique d’un système de transmission de données spécifique qui est utilisé pour enregistrer un produit spécifique.
Les modes de réalisation de l’invention peuvent être mis en œuvre sur un système informatique comprenant un ou plusieurs ordinateurs ou serveurs en réseau. Les systèmes informatiques peuvent fournir le traitement et les fonctions de base de données pour le fournisseur de contenu.
Faisant maintenant référence à la figure 2, un exemple d’environnement de fonctionnement 200 est montré conformément à un mode de réalisation de l’invention dans lequel le système de transmission de données 10 est un système de réservation de voyage. L’environnement 200 peut inclure un système centralisé de distribution de données 20 tel qu’un GDS (système global de distribution), un ou plusieurs systèmes de fournisseurs indirects de contenu 21 tels que des systèmes de transporteurs et des systèmes de vendeurs indirects tels qu’un système d’agence de voyages 22 et un ou plusieurs dispositifs clients 2. Chacun des systèmes centralisés de distribution de données 20, des systèmes de fournisseurs indirects de contenu 21, des systèmes de vendeurs indirects 22 et des dispositifs utilisateurs 2 peut communiquer via un réseau 5. Les systèmes de fournisseurs indirects de contenu 21 peuvent inclure chacun un système de réservation informatique (CRS) et/ou un système de facturation pour la compagnie aérienne respective qui permet au système centralisé de distribution de données 20 et/ou au système du vendeur indirect 22 de réserver et de payer des billets d’avion. Les systèmes des fournisseurs indirects de contenu 21 peuvent aussi interagir les uns avec les autres, soit directement ou via le système centralisé de distribution de données 20, pour permettre à un transporteur émetteur de vendre des billets pour des sièges fournis par un transporteur de fait. Le transporteur de fait peut ensuite facturer le transporteur émetteur pour les services fournis.
Le système centralisé de distribution de données 20 peut être configuré pour faciliter la communication entre les systèmes de fournisseurs indirects de contenu 21 et les systèmes de vendeurs indirects 22 en permettant aux agents de voyage, aux transporteurs émetteurs, aux autres vendeurs indirects de rechercher des segments disponibles et d’effectuer des réservations sur un ou plusieurs systèmes de fournisseurs indirects de contenu 21 via le système centralisé de distribution de données 20. Le système centralisé de distribution de données 20 peut maintenir des liens avec chacun des systèmes des transporteurs 21 via le réseau 5. Ces liens peuvent permettre au système centralisé de distribution de données 20 d’obtenir des données de disponibilité et de programmation pour des segments à partir des systèmes de fournisseurs indirects de contenu 21, et des requêtes de réservation de propositions de voyage aux systèmes des fournisseurs de contenu 21. Les systèmes de fournisseurs de contenu 21 et les systèmes de vendeurs indirects 22 peuvent ainsi réserver des vols, des billets de train ou d’autres types de segments sur de multiples transporteurs via une connexion unique au système centralisé de distribution de données 20. Le système centralisé de distribution de données 20 peut stocker et/ou conserver un enregistrement de nom de passager (PNR) qui inclut un ensemble complet des données pour un itinéraire de voyage, incluant les segments de multiples transporteurs et/ou d’autres services de voyage comprenant le voyage, tels que les réservations d’hôtel et de voiture de location.
Un système de vendeur indirect 22 tel qu’une agence de voyages peut inclure un serveur Web qui fournit un site Web accessible au grand public. Ce site Web peut être configuré pour fournir un accès à des produits de voyage, en effectuant une recherche pour des produits de voyage en réponse à une requête de voyage. Dans ce but, le système du vendeur 22 peut fournir à des utilisateurs un accès à des données en utilisant une ou plusieurs bases de données hébergées par le système centralisé de distribution de données 20, les systèmes de fournisseurs 21 et/ou les systèmes de vendeurs 22. Autrement, le système de vendeur 22 peut être un système propriétaire (p. ex. le système d’une agence de voyages) qui fournit un accès à un ensemble limité d’utilisateurs (p. ex ; les fournisseurs de services de voyage ou les agents de voyage) auquel cas l’accès peut être fourni par l’entremise d’un site Web privé ou une autre application.
Le système de transmission de données 10 peut être en communication avec le système du vendeur 22 via le réseau 5 une autre connexion appropriée. Dans d’autres modes de réalisation de l’invention, tout ou une portion du système de transmission de données 10 peut être intégré dans un ou plusieurs des autres systèmes 20, 21, 22, 23. Les utilisateurs ou agents de voyage peuvent utiliser le système vendeur 22 pour générer et/ou rechercher des produits de voyage qui satisfont une requête de voyage reçue de l’utilisateur en utilisant le système de transmission de données 10.
Le système de distribution global 20, les systèmes transporteurs 21, le système de l’agence de voyages 22, le système du fournisseur de voyage 2 et les dispositifs clients 2 de l’environnement d’exploitation peuvent être implémentés sur un ou plusieurs dispositifs informatiques ou systèmes, appelés collectivement un ordinateur, tel qu’un ordinateur.
La Figure 3 est un diagramme bloc d’un dispositif de détection d’événements 1 conforme à des modes de réalisation de l’invention ;
Les modes de réalisation de l’invention permettent la détection d’événements liés aux données d’utilisateur stockées dans l’unité de stockage de données 11 et le déclenchement d’actions d’une ou de plusieurs applications internes ou externes en utilisant des règles autoadaptatives.
Comme le montre la figure 3, le dispositif de gestion d’événements 1 peut comprendre une unité de détection d’événements 30 configurée pour détecter l’apparition d’un événement lié à au moins un utilisateur identifié dans une entrée du stockage de base de données d’utilisateur 11. Les événements peuvent être des événements internes au système (événements internes) ou des événements externes au système (événements externes). Les événements peuvent être détectés de diverses manières en utilisant les informations reçues par des applications internes ou des dispositifs externes connectés au système de transmission de données 10.
Dans un exemple d’application de l’invention à un système de transmission de données 10 délivrant des produits de voyage tels que des billets d’avion, un événement peut par exemple être :
– une perturbation dans l’itinéraire d’un utilisateur identifiée dans une entrée du stockage de base de données d’utilisateur 11 associée à un utilisateur ;
– l’émission d’un billet (correspondant à un produit de voyage) identifiée dans une entrée du stockage de base de données d’utilisateur 11 associée à un utilisateur ;
– le retard d’un vol (produit de voyage) identifié dans une entrée du stockage de base de données d’utilisateur 11 associée à un utilisateur.
De façon plus générale, le type d’événement détecté par l’unité de détection d’événements 30 peut comprendre :
– des événements externes indépendants de l’utilisateur qui ne sont pas spécifiques à un ensemble d’utilisateurs tels que par exemple un événement de football en Russie à une date donnée ; l’unité d’extraction de données 31 extraira alors de l’unité de stockage de données 11 des données correspondant à des utilisateurs identifiés comme étant des supporters de football, récupérera des données d’utilisateur supplémentaires corrélées à ces utilisateurs identifiés dans le stockage de données d’utilisateur 11, les transformera en un fichier de description et transmettra le fichier de description au moteur de règles 4 pour le mappage d’actions en utilisant les règles correspondant aux données extraites.
– des événements externes indépendants de l’utilisateur qui sont spécifiques à un ou à plusieurs utilisateurs tels que par exemple une réservation pour un produit de vol donné pour la Russie ; l’unité d’extraction de données 31 extraira alors de l’unité de stockage de données 11 des données correspondant à des utilisateurs pour lesquels existe une réservation pour le produit de vol donné à destination de la Russie, récupérera des données d’utilisateur supplémentaires corrélées à ces utilisateurs identifiés dans le stockage de données d’utilisateur 11, les transformera en un fichier de description et transmettra le fichier de description au moteur de règles 4 pour le mappage d’actions en utilisant les règles correspondant aux données extraites.
Le dispositif de gestion d’événements 1 peut par ailleurs comprendre une unité d’extraction de données 31 configurée pour extraire des données d’utilisateur relatives à l’événement détecté dans le stockage de données d’utilisateur 11. L’unité d’extraction de données 31 peut comprendre un analyseur de données 311 pour déterminer les données d’utilisateur qui doivent être extraites du stockage de données d’utilisateur sur la base de l’événement détecté. L’unité d’extraction de données 31 peut comprendre un parseur pour analyser les informations d’événement reçues, une unité de division pour séparer les informations d’événement analysées dans un ensemble de portions et une unité de sélection pour sélectionner des données à partir d’au moins certaines des portions, les données sélectionnées représentent les données extraites à partir d’une unité d’extraction de données 31.
L’unité d’extraction de données 31 peut être adaptée pour extraire des données de formats divers dans le stockage de données d’utilisateur 11. L’unité d’extraction de données 31 peut être configurée pour transformer le format des données extraites en un format homogène. Dans un mode de réalisation, l’unité d’extraction de données 31 peut extraire les données d’utilisateur dans un fichier de description ayant un format homogène tel qu’un fichier XSLT (le langage extensible de transformation de feuilles de style). L’unité d’extraction de données 31 peut par ailleurs extraire des données relatives à des événements à partir de l’événement détecté et intégrer ces données relatives à l’événement dans le fichier de description.
Le gestionnaire de règles 102 peut utiliser des données d’utilisateur et les données relatives à l’événement extraites par l’unité d’extraction de données 31 pour déterminer les règles qui doivent être appliquées aux données d’utilisateur extraites.
Le dispositif de gestion d’événements 1 peut par ailleurs comprendre une unité de déclenchement d’actions 32 configurée pour déclencher une action dans le système de transmission de données 10 sur la base des données extraites du stockage de données d’utilisateur 11 en réponse à l’événement détecté. L’action peut être exécutée par une ou plusieurs applications ou fonctions implémentées dans le système de transmission de données 10 et/ou par une ou plusieurs applications externes. Dans des modes de réalisation, dans lesquels l’action déclenchée est exécutée au moins partiellement par une ou plusieurs applications externes, l’unité d’extraction de données 31 peut être configurée pour envoyer au moins une partie des données extraites des données d’utilisateur vers l’application(s) externe(s) au système de transmission de données 10, par exemple une application fonctionnant dans un système externe ou dispositif 3.
Dans un mode de réalisation, l’unité de détection d’événements 30 peut comprendre un interprète de données 300 capable d’interpréter les événements notifiés au système de transmission de données 10. L’unité de détection d’événements 30 peut par ailleurs comprendre un module de corrélation 302 configuré pour calculer une corrélation entre un événement interprété et des données d’événements prédéfinies stockées dans le système de transmission de données 10. L’interprète de données 300 de l’unité de détection d’événements peut utiliser au moins un processeur pour interpréter en temps réel les données correspondant à un événement entrant.
L’unité de déclenchement d’action 33 peut être configurée pour appliquer un ensemble de règles 400 géré par un moteur de règles 4 du gestionnaire de règles 102.
Par exemple, dans une application de l’invention à un système de transmission de produits de voyage 10, l’unité de détection d’événement 30 peut détecter un événement correspondant à la « détection d’une perturbation dans l’itinéraire d’un utilisateur ». L’unité d’extraction de données 31 peut ensuite extraire le profil de l’utilisateur correspondant dans le stockage de données d’utilisateur 11 (tels que des informations relatives à sa carte de fidélité, etc.), transmettre les données extraites à l’unité de déclenchement d’action 33 qui à son tour peut déclencher une action correspondant à l’émission d’un fichier à un système de notification externe 3 comprenant une proposition d’indemnisation pour l’utilisateur, par exemple sous la forme d’un bon d’achat, le fichier étant généré en utilisant les règles 400 fournies par le moteur de règles, en fonction des données d’utilisateur extraites. Le système de notification externe 3 peut par exemple générer un message électronique devant être envoyé à l’adresse courriel de l’utilisateur comprenant une offre d’indemnisation.
Le moteur de règles 4 peut comprendre une mémoire de règles 40 pour stocker les règles appliquées aux données reçues de l’unité d’extraction de données 31.
Tel qu’utilisé ici, une « règle » gérée par le moteur de règles 4 fait référence à une ou plusieurs conditions logiques relatives à un ensemble de paramètres qui, dépendant de leur évaluation par rapport aux valeurs de paramètres reçues, définit une ou plusieurs actions à exécuter par le système de transmission de données. Une règle est donc une instruction conditionnelle. Une RÈGLE peut par exemple être exprimée sous la forme :
Une règle comprend donc une partie conditions qui est évaluée sur la base des données d’utilisateur extraites et une partie actions représentant des actions qui doivent être déclenchées si l’évaluation des conditions exprimées dans la partie conditions est aboutie avec succès. Dans la description suivante de certains modes de réalisation de l’invention, l’expression « une règle associée à une action » sera utilisée pour faire référence à une règle qui renvoie l’action comme conséquence d’une évaluation des conditions de la règle.
Tel qu’utilisé ici, une « action » définit une fonction d’une opération ou d’une application qui doit être déclenchée par l’unité de déclenchement d’action 33 en utilisant une ou plusieurs ressources du système de transmission de données 10. Le « déclenchement d’une action » fait référence à « l’exécution de l’action ».
Les conditions liées à une règle donnée peuvent être définies en utilisant des termes stockés dans un dépôt de grammaire 41, tel que des termes devant être mappés sur plusieurs composants du système de transmission de données 10.
Une règle lie ainsi les paramètres des conditions logiques aux données fournies provenant des/vers les composants du système de transmission de données. En particulier, une condition pour une règle donnée est évaluée en utilisant des valeurs de paramètres correspondant aux données extraites par l’unité d’extraction de données 31 et détermine des actions à mapper sur des applications internes et/ou externes et devant être déclenchées par l’unité de déclenchement d’action 33 en fonction de cette évaluation.
Par exemple, en supposant que l’unité de détection d’événements 30 détecte un événement interne relatif au profil d’un utilisateur ou à un changement dans les informations d’un utilisateur, le moteur de règles 4 peut appliquer une règle R : IF {C1 AND C2 AND C3 AND C4} THEN A1, avec :
C1= {Pour une réservation donnée B dans le profil d’utilisateur associé à un utilisateur donné U},
C2 = {Point limite = BLR} (Bengaluru),
C3= {Réservation de cabine = J},
C4= {Métrique de jours jusqu’au départ = 5}.
L’application de la règle R par le moteur de règles 4 renverra l’action A1 IF la combinaison de conditions = {C1 AND C2 AND C3 AND C4} est vérifiée, avec :
A1= Réservation d’un taxi à destination pour l’utilisateur U.
Pour déclencher l’action A1, l’unité de déclenchement d’action 32 peut récupérer l’heure d’arrivée de l’itinéraire correspondant dans le stockage de données d’utilisateur 11.
Dans un autre exemple, il est supposé que l’unité de détection d’événements 30 détecte un événement externe, le moteur de règles 4 peut appliquer une règle R' : IF {C1 AND C2} THEN A1, avec :
C’1= Il y a une correspondance à Nice Arena ;
C’2 = L’utilisateur U' a un vol partant à peu près en même temps de NCE (Nice).
L’application de la règle R' par le moteur de règles 4 renverra l’action A'1 IF la combinaison de conditions = {C’1 AND C’2} est vérifiée, avec :
A'1= envoyant un court message en utilisant une application de système de messagerie courte à l’utilisateur U' incluant une recommandation de quitter son domicile 4 h à l’avance.
L’exécution d’une règle produit donc ainsi un résultat qui identifie une ou plusieurs actions devant être déclenchées par l’unité de déclenchement d’action 33.
Le détecteur d’événement 101 peut par ailleurs comprendre une unité de publication 34 configurée pour publier des données à une ou plusieurs applications externes d’un système ou d’un dispositif externe 3 en réponse au déclenchement d’une action par l’unité de déclenchement d’action 33. Dans un mode de réalisation, l’unité de publication 34 peut publier des données au système ou au dispositif externe 3 sous forme d’une liste agrégée d’une ou de plusieurs données de profil d’utilisateur correspondant aux données d’utilisateur filtrées en fonction du système ou du dispositif externe 3.
L’application externe du système externe ou du dispositif 3 vers laquelle les données d’utilisateur sont publiées peut être une application utilisant des données d’utilisateur à exécuter, telles qu’une application de messagerie électronique, une application d’interface de programmation, etc.
Des modes de réalisation de l’invention permettent ainsi la transformation de données d’utilisateur agrégées dans le stockage de données d’utilisateur 11 en actions en réponse aux événements détectés en utilisant les règles fournies par le moteur de règles 4.
Par conséquent, les données d’utilisateur peuvent être extraites de façon dynamique en réponse à un événement détecté (interne et/ou externe) et des actions peuvent aussi être déclenchées de façon dynamique en appliquant les règles fournies par le moteur de règles 4 aux données d’utilisateur extraites
Le moteur de règles 4 peut être configuré pour appairer une ou plusieurs règles avec des données reçues de l’unité d’extraction de données 31 en utilisant une structure de donnée d’arbre. L’unité d’extraction de données 31 peut fournir des données d’utilisateur extraites au moteur de règles 4 sous la forme d’un fichier de description tel qu’un fichier XSLT. L’unité d’extraction de données 31 peut par ailleurs inclure des données d’événement relatives à l’événement détecté dans le fichier de description.
L’utilisation d’une structure de donnée d’arbre par le moteur de règles 4 permet de déterminer des corrélations entre les données d’utilisateur extraites et des actions.
La structure de donnée d’arbre peut comprendre un ensemble de nœuds commençant à partir d’un nœud racine. Chaque nœud représente une règle relative à un ensemble de paramètres et les nœuds enfants représentent des valeurs possibles pour le paramètre de la règle. Un exemple de la partie conditions d’une règle comprenant des conditions peut par exemple être : IF « un événement de football en Russie à une date donnée » (C1) et IF « le passager a une réservation pour la Russie à une date donnée » (C2).
La structure de donnée d’arbre représente ainsi la partie conditions de la règle.
Un exemple de structure de donnée d’arbre 60 est décrite dans la figure 6.
La mémoire de règles 401 peut comprendre une ou plusieurs bases de données pour stocker les structures de donnée d’arbre.
Dans un mode de réalisation, le gestionnaire de règles 102 peut par ailleurs comprendre un moteur d’apprentissage automatique orienté règles 6, connecté au moteur de règles 4. Le moteur d’apprentissage 6 peut être configuré pour recevoir des données de rétroaction relatives à l’action exécutée d’un ensemble d’utilisateurs au cours d’une période d’apprentissage prédéfinie et pour déterminer un score de pertinence d’action basé sur les données de rétroaction reçues d’un ensemble d’au moins un utilisateur.
Le dispositif de gestion d’événements 1 peut par exemple soumettre une demande de rétroaction, relative à une action à un ensemble d’utilisateurs pour lesquels l’action a été exécutée en invitant les utilisateurs de l’ensemble d’utilisateurs à fournir une valeur de rétroaction pour l’action exécutée sous forme d’un score de pertinence d’action attribué à l’action exécutée. Dans certains modes de réalisation, l’utilisateur peut être invité à sélectionner une valeur de score parmi un nombre de valeurs de score prédéfinies sur le dispositif utilisateur 2. Les valeurs de score prédéfinies peuvent par exemple comprendre une valeur de récompense, une valeur de pénalités et une valeur neutre (si l’utilisateur ne fournit pas de rétroaction). Le système de transmission de données 10 peut recevoir en retour une valeur de score pour l’action exécutée d’au moins certains des utilisateurs provenant de leurs dispositifs utilisateurs 2. Le moteur d’apprentissage 6 peut ensuite calculer un score de pertinence pour l’action exécutée basé sur les valeurs de score reçues (rétroactions d’utilisateur). Autrement, la rétroaction d’utilisateur pour une action exécutée peut être déterminée de façon dynamique pour chaque utilisateur pour lequel une action a été déclenchée sur la base des données collectées pour l’utilisateur en lien avec l’action déclenchée (par exemple, une rétroaction d’utilisateur peut être fixée à un score de récompense si un utilisateur a utilisé une indemnisation offerte correspondant à une action déclenchée).
Le moteur d’apprentissage 6 peut ensuite calculer un score de pertinence pour chaque action exécutée et transmettre le score de pertinence associé à l’action correspondante au moteur de règles 4. Le moteur d’apprentissage peut utiliser des informations d’utilisateur supplémentaires dans le stockage de données d’utilisateur 11 pour pondérer les scores d’actions élémentaires reçus par les utilisateurs avant de calculer le score global de pertinence d’action.
Dans un mode de réalisation, le moteur de règles 4 peut actualiser les règles 400 qui sont appliquées pour déterminer une action à déclencher sur la base du score de pertinence reçu du moteur d’apprentissage 6 pour l’action, au cours de l’exécution. L’actualisation de la règle peut inclure la suppression, l’addition et/ou la modification des règles associées à une action.
Lorsque la partie conditions des règles est implémentée sous la forme de structures de donnée d’arbre, le moteur de règles 4 peut être configuré pour actualiser une règle en actualisant la structure de donnée d’arbre correspondante en fonction du score global de pertinence calculé pour une action exécutée relative à la règle.
Dans un mode de réalisation, le moteur de règles 4 peut être utilisé en mode test pour tester une ou plusieurs règles avec l’ensemble sélectionné des utilisateurs testeurs et pour sélectionner les règles devant être implémentées en mode opérations sur la base des rétroactions reçues par des utilisateurs testeurs.
Le moteur de règles 4 implémente donc l’apprentissage automatique orienté règles permettant d’actualiser de façon adaptative une règle 400 sur la base des valeurs de rétroaction d’utilisateur reçues pour l’action exécutée comme résultat de l’application de la règle).
Autrement, l’attribution d’un score de pertinence d’action et/les attributions d’actions élémentaires reçues des utilisateurs pour les actions exécutées peuvent être utilisées par le détecteur d’événement 101 pour déterminer les actions qui doivent être déclenchées en réponse à un événement. Dans ces modes de réalisation, la partie actions d’une règle peut être définie avec un opérateur booléen, dénoté « OP » qui peut par exemple être un opérateur booléen OR ou AND. La partie actions de la règle peut donc être sous la forme {Action A1OP Action A2OP A3… OP ACTION Aj… OP Action AM}. Dans certains modes de réalisation, la liste des actions {A1, Aj, …,AM} associée à la partie actions d’une règle peut changer dans le temps conséquemment aux actualisations de règles.
Dans un mode de réalisation, le dispositif de gestion d’événements 1 peut être configuré pour corréler chaque action exécutée avec le score de pertinence d’action déterminé par le moteur d’apprentissage automatique 6. Le moteur de règles 4 peut ensuite sélectionner au moins une des actions Ai de la partie actions d’une règle en fonction du score de pertinence associé à l’action Ai. Dans un mode de réalisation, le dispositif de gestion d’événements 1 peut utiliser une mémoire de pertinence d’action (non illustrée) telle qu’une base de données pour corréler chaque action exécutée avec le score de pertinence d’action déterminé par le moteur d’apprentissage automatique 6.
Dans un autre mode de réalisation, le dispositif de gestion d’événements 1 peut être configuré pour corréler chaque action exécutée avec un utilisateur donné et avec un score d’action élémentaire (valeur de rétroaction) reçu de l’utilisateur donné par le moteur d’apprentissage 6. Le moteur de règles 4 peut déterminer au moins une des actions Ai de la partie actions de la règle devant être déclenchée pour l’utilisateur(s) identifié par les données d’utilisateur extraites en utilisant le score d’action élémentaire associé à l’action Ai et à l’utilisateur(s). Dans un autre mode de réalisation, le dispositif de gestion d’événements 1 peut utiliser une mémoire de pertinence d’action (non illustrée) telle qu’une base de données pour corréler chaque action exécutée avec un utilisateur donné et avec un score d’action élémentaire (valeur de rétroaction) reçu de l’utilisateur donné par le moteur d’apprentissage 6.
De façon avantageuse, conformément aux modes de réalisation de l’invention, les règles peuvent être actualisées (créées, supprimées, modifiées) de façon dynamique au cours du fonctionnement du système de transmission de données sans avoir besoin d’interrompre le système pour actualiser la règle, ce qui assure une continuité du service et la pertinence des actions déclenchées. Chacune des actions déclenchées peut donc être réintroduite dans le système de transmission de données pour une adaptation dynamique des règles gérées par le moteur de règles.
Le moteur de règles 4 peut être initialisé au cours du lancement avec un ensemble de règles prédéfini dans la mémoire de règles 401 formant un ensemble de règles de commencement. L’ensemble des règles peut ensuite être affiné de façon dynamique pendant l’exécution en utilisant les données de rétroaction reçues par le moteur d’apprentissage 6.
Par conséquent, l’opération du moteur de règles 4 peut être accélérée tout en évitant d’avoir recours à un processus de validation de règles pour charger de nouvelles règles en mémoire, supprimer des règles de la mémoire ou actualiser les règles. Cela évite aussi de conserver des règles incohérentes. Par conséquent, le taux de remplissage de la mémoire de règles 401 maintenue par le moteur de règles 4 et donc la latence du moteur de règles 4 peuvent être optimisés.
Les modes de réalisation de l’invention fournissent donc un système de gestion d’événements 1 à haute disponibilité, capable de conserver des règles autoadaptatives. Le système de gestion d’événements 1 permet par ailleurs au système de transmission de données de générer des actions en fonction de l’événement détecté et des règles maintenues par le moteur de règles en utilisant des applications du système de transmission de données 10 en temps réel ou quasi réel (ce qui signifie qu’entre un événement détecté et le déclenchement d’une action, le temps de réponse est moins de quelques secondes).
On doit noter par ailleurs que le fonctionnement du système de gestion d’événements 1 permet la détection instantanée d’événements sans limiter l’accès à d’autres applications aux données d’utilisateur maintenues dans le stockage de données d’utilisateur 11.
La Figure 4 est un organigramme décrivant un processus de détection d’événement, conformément à certains modes de réalisation.
À l’étape 402, un événement est détecté parmi une liste d’événements prédéfinis à partir des informations reçues des dispositifs ou systèmes internes ou externes, l’événement étant lié à un ou plusieurs utilisateurs identifiés dans au moins une entrée du stockage de base de données d’utilisateur 11.
À l’étape 404, les données d’utilisateur liées à l’événement détecté peuvent être extraites du stockage de données d’utilisateur 11. Les données d’utilisateur peuvent être liées à une ou plusieurs entrées du stockage de données d’utilisateur 11. L’étape 404 peut comprendre la génération d’un fichier de description intégrant les données extraites, tel que par exemple un fichier XSLT.
À l’étape 406, les règles peuvent être appliquées aux données d’utilisateur extraites. L’étape 404 peut être appliquée de façon séquentielle ou en parallèle pour chaque entrée du stockage de données d’utilisateur 11 avec laquelle les données d’utilisateur extraites ont un lien.
À l’étape 408, pour les données d’utilisateur extraites associées à une entrée donnée du stockage de données d’utilisateur 11, une ou plusieurs actions dépendant des données extraites sont déterminées comme résultat de l’application des règles à l’étape 406.
À l’étape 410, les actions déterminées à l’étape 408 peuvent être exécutées.
À l’étape 412, pour chaque action exécutée une ou plusieurs valeurs de rétroaction d’actions peuvent être reçues d’un ensemble d’utilisateurs. L’ensemble des utilisateurs peut représenter les utilisateurs impactés par l’action exécutée qui peut inclure les utilisateurs identifiés dans les données d’utilisateur extraites et/ou d’autres utilisateurs identifiés dans le stockage de données d’utilisateur 11. Les valeurs de rétroaction d’actions peuvent être reçues sous forme d’un score d’action élémentaire sélectionné parmi un ensemble prédéfini de valeurs ou par exemple dans un éventail de valeurs. Les valeurs de rétroaction reçues pour chaque action exécutée peuvent être stockées dans une mémoire de rétroaction d’action en association avec l’action exécutée, telle qu’un tableau.
La figure 5 est un organigramme décrivant un procédé pour actualiser les règles maintenues par le moteur de règles de façon dynamique, conformément à des modes de réalisation.
Le procédé de la figure 5 peut être déclenché si, pour chaque action exécutée, si le nombre de valeurs de rétroaction reçu est supérieur ou égal à une valeur de seuil, ou si une durée prédéfinie ou autrement après une durée prédéfinie (bloc 500).
À l’étape 504, pour l’action exécutée (bloc 502), les scores élémentaires reçus des utilisateurs pour l’action exécutée peuvent être récupérés à partir de la mémoire de valeurs de rétroaction.
À l’étape 506, un score global de pertinence d’action pour l’action exécutée peut être calculé sur la base des scores élémentaires récupérés. Dans un mode de réalisation, le calcul du score de pertinence d’action peut inclure la détermination d’une valeur statistique telle qu’une valeur moyenne à partir du score d’action élémentaire. Dans certains modes de réalisation, l’étape de calcul d’un score de pertinence d’action pour une action exécutée peut inclure de pondérer préalablement la détermination d’un score d’action élémentaire reçu d’un ou de plusieurs utilisateurs en fonction d’un ensemble de critères de pondération. Les critères de pondération peuvent inclure par exemple une information relative à l’utilisateur émetteur (c.-à-d. l’utilisateur qui a renvoyé le score d’action élémentaire au système de transmission de données) telle qu’une information de profil d’utilisateur associée à l’utilisateur dans le stockage de données d’utilisateur 11, une information de durée (telle qu’un délai représentant le moment auquel l’action a été exécutée et le moment auquel le score élémentaire a été transmis par l’utilisateur au système de transmission de données), etc.
À l’étape 508, les règles associées à l’action exécutée dans la mémoire de règles 40 peuvent être actualisées de façon dynamique (c.-à-d., création d’une nouvelle règle(s), suppression d’une règle(s) existante et/ou modification d’une règle(s) existante) par le moteur de règles 4 en utilisant le score de pertinence d’action calculé.
Bien qu’il ne soit pas limité assez application, le dispositif de gestion d’événements et le procédé conforme au mode de réalisation de l’invention ont des avantages particuliers pour les données d’utilisateur collectées à partir de diverses sources d’informations hétérogènes. Dans certains modes de réalisation, le dispositif de gestion d’événements 1 peut être connecté en temps réel à des sources de données externes, telles que des systèmes de réseaux sociaux, pour collecter divers types d’information telles que des conditions météorologiques, des informations relatives à des événements particuliers (événements sportifs, concerts, coupes du monde, etc.), des perturbations (grèves du public, manifestation, etc.).
De façon avantageuse le dispositif de gestion d’événements 1 permet la détection d’événements en temps réel, l’identification de données d’utilisateurs qui ont été affectées par l’événement et la détermination dynamique d’actions à exécuter par les applications internes et/ou externes à partir des données d’utilisateur identifiées.
Faisant maintenant référence à la figure 7, le système de transmission de données 100 et un ou plusieurs blocs du dispositif de gestion d’événements 1 peuvent être implémentés sur un ou plusieurs dispositifs ou systèmes informatiques, collectivement désignés comme un ordinateur, tels que l’ordinateur 8. L’ordinateur 8 peut inclure un processeur 82, une mémoire 84, un dispositif de mémoire de stockage de masse 86, une interface entrée/sortie (I/O) 88 et une interface homme-machine (HMI) 89. L’ordinateur 8 peut aussi être couplé de façon fonctionnelle à une ou plusieurs ressources extérieures 92 par l’intermédiaire du réseau 5 et/ou l’interface I/O 88. Les ressources externes peuvent inclure, mais de façon non exhaustive, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau basés sur le cloud, ou toute autre ressource informatique appropriée qui peut être utilisée par l’ordinateur 8.
Le processeur 82 peut inclure un ou plusieurs dispositifs sélectionnés : microprocesseurs, microcontrôleurs, processeurs de signaux numériques, micro-ordinateurs, unités centrales de traitement, réseaux de portes programmables, dispositifs logiques programmables, machines à état défini, circuits logiques, circuits analogiques, circuits numériques, ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) sur la base d’instructions de fonctionnement enregistrées dans la mémoire 84. La mémoire 84 peut inclure un seul dispositif ou une pluralité de dispositifs de mémoire, notamment, mais sans s’y limiter, la mémoire à lecture seule (ROM), la mémoire à accès aléatoire (RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, l’antémémoire (cache memory) ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de masse 86 peut inclure des dispositifs de stockage de données tels qu’un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l’état solide non volatile, ou tout autre dispositif capable de stocker des informations. Une base de données 94 peut résider sur le dispositif de mémoire de masse 86 et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits ici.
Le processeur 82 peut fonctionner sous le contrôle d’un système d’exploitation 96 qui réside dans la mémoire 84. Le système d’exploitation 96 peut gérer les ressources de l’ordinateur de telle façon que le code de programme de l’ordinateur, intégré sous forme d’un ou plusieurs logiciels d’application tels qu’une application 98 qui réside dans la mémoire 84, puisse disposer d’instructions exécutées par le processeur 82. Dans un autre mode de réalisation, le processeur 82 peut exécuter l’application 98 directement et dans ce cas, le système d’exploitation 96 peut être omis. Une ou plusieurs structures de donnée 99 peuvent également résider dans la mémoire 84, et peuvent être utilisées par le processeur 82, le système d’exploitation 96, ou l’application 98 pour stocker ou manipuler des données.
L’interface I/O 88 peut fournir une interface machine qui couple le processeur 82 de façon fonctionnelle avec d’autres dispositifs et systèmes, tels que le réseau 91 (réseau 91 qui peut être le réseau 91 par exemple) et/ou la ressource externe 92. Le serveur d’application 98 peut ainsi collaborer avec le réseau 91 et/ou avec la ressource externe 92 en communiquant par l’intermédiaire de l’interface I/O 88 pour fournir les divers éléments, fonctions, applications, processus, modules composant les modes de réalisation de l’invention. L’application 98 peut aussi comporter un code de programme qui est exécuté par une ou plusieurs ressources externes 92, ou repose autrement sur les fonctions ou signaux fournis par d’autres composants de système ou de réseau externes à l’ordinateur 8. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles, les hommes de métier comprendront que les modes de réalisation de l’invention peuvent inclure des applications situées à l’extérieur de l’ordinateur 8, distribuées à des ordinateurs multiples ou à d’autres ressources externes 92, ou fournies par des ressources informatiques (matérielle et logicielle) qui sont fournies comme service sur le réseau 91, tel qu’un service informatique en nuage.
Le HMI 89 peut être couplé de façon fonctionnelle avec le processeur 82 de l’ordinateur 8 d’une manière connue pour permettre à un utilisateur de l’ordinateur 8 d’interagir directement avec l’ordinateur 8. Le HMI 89 peut inclure un affichage vidéo et/ou alphanumérique, un écran tactile, un haut-parleur et tout autre indicateur visuel et audio capable de communiquer des données à l’utilisateur. Le HMI 89 peut aussi inclure des dispositifs de saisie et des contrôles tels qu’un clavier alphanumérique, un dispositif de pointage, des boutons poussoirs, des boutons de contrôle, des microphones, etc. capables d’accepter des commandes ou des saisies de l’utilisateur et de transmettre la saisie entrée au processeur 82.
Une base de données 94 peut résider sur le dispositif de mémoire de masse 86, et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits ici. La base de données 94 peut inclure des données ainsi que les structures de donnée qui les accommodent pour stocker et organiser les données. En particulier, la base de données 94 peut être aménagée avec toute organisation ou structure de base de données, notamment, mais de façon non restrictive, une base de données relationnelle, une base de données de type hiérarchique, une base de données en réseau, une base de données orientée objet, ou des combinaisons de celles-là. Un système de gestion de base de données sous forme de logiciel informatique d’application qui s’exécute sous la forme d’instructions sur le processeur 82 peut être utilisé pour accéder à l’information ou aux données stockées dans des fichiers de la base de données 94 en réponse à une interrogation, lorsqu’une interrogation peut être déterminée de façon dynamique et exécutée par le système d’exploitation 96, les autres applications 98, ou un ou plusieurs modules. Bien que des modes de réalisation de l’invention puissent être décrits ici en utilisant une terminologie de base de données relationnelle, hiérarchique, de réseau, orientée objet, ou autre terminologie dans des cas spécifiques, les hommes de métier comprendront que les modes de réalisation de l’invention peuvent utiliser tout modèle de gestion de base de données approprié, et ne sont pas limités à un quelconque type particulier de base de données.
En général les routines exécutées pour mettre en œuvre les modes de réalisation de l’invention, qu’elles soient implémentées dans le cadre d’un système d’exploitation ou d’une application spécifique, d’un composant, d’un programme, d’un objet, d’un module ou d’une séquence d’instructions, ou même un sous-ensemble de ceux-ci, peuvent être désignées ici comme « code de programme informatique » ou simplement « code de programme ». Un code de programme comporte typiquement des instructions lisibles par ordinateur qui résident à divers moments dans divers dispositifs de mémoire et de stockage dans un ordinateur et qui, lorsqu’elles sont lues et exécutées par un ou plusieurs processeurs dans un ordinateur, amènent l’ordinateur à effectuer des opérations nécessaires à l’exécution d’opérations et/ou d’éléments propres à la mise en œuvre des aspects variés des modes de réalisation de l’invention. Les instructions d’un programme, lisibles par ordinateur, pour mettre en œuvre les opérations des modes de réalisation de l’invention peuvent être, par exemple, le langage d’assemblage, ou encore un code source ou un code objet écrit en combinaison avec un ou plusieurs langages de programmation.
Divers codes de programme décrits ici peuvent être identifiés, selon l’application dans laquelle ils sont implémentés, dans des modes de réalisation spécifiques de l’invention. Cependant, on notera qu’une quelconque nomenclature d’un programme particulier ici est utilisée uniquement par commodité ; ainsi l’invention ne peut être limitée à un seul usage dans toute application spécifique identifiée et/ou sous-entendue par ladite nomenclature. Par ailleurs, au vu du nombre généralement infini de moyens par lesquels les programmes informatiques peuvent être organisés selon des sous-programmes, procédures, procédés, modules, objets, et ainsi de suite, ainsi que les façons variées d’affecter les fonctionnalités d’un programme parmi diverses couches de logiciels qui sont hébergées dans un ordinateur typique [p. ex., les systèmes d’exploitation, les bibliothèques, les interfaces d’application de programme (API’s), les applications, les petites applications (applets) etc.], on notera que les modes de réalisation de l’invention ne sont pas limités à l’organisation spécifique et à l’affectation spécifique des fonctionnalités de programme telles qu’elles sont décrites ici.
Le code de programme mis en œuvre dans l’une/l’un quelconque des applications/modules décrit(e)s ici peut être distribué individuellement ou collectivement comme un produit-programme, sous une variété de formes. En particulier, le code de programme peut être distribué en utilisant un support de stockage lisible par ordinateur, disposant en lui-même d’instructions de programme lisibles par ordinateur, permettant à un processeur de mettre en œuvre des aspects des modes de réalisation de l’invention.
Les supports de stockage lisibles par ordinateur, qui sont intrinsèquement non transitoires, peuvent inclure des supports tangibles volatiles et non volatiles, amovibles et non amovibles, implémentés dans tout procédé ou technologie de stockage d’information, tels que des instructions de programme lisibles par ordinateur, des structures de données, des modules de programme, ou d’autres données. Les supports de stockage lisibles par ordinateur peuvent aussi comprendre des mémoires RAM, ROM, à lecture exclusivement, programmable et effaçable (EPROM), à lecture exclusivement, programmable et effaçable électriquement (EEPROM), une mémoire flash, ou toute technologie de support solide de mémoire (disque compact portable doté d’une mémoire à lecture seule (CD-ROM), ou tout autre stockage optique, cassettes magnétiques, bandes d’enregistrement magnétiques, disques de stockage magnétiques, autres dispositifs de stockage magnétiques, ou tout autre support pouvant être utilisé pour stocker l’information désirée, et apte à être lu par un ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme des signaux transitoires en soi (par exemple, des ondes radio ou toutes autres ondes électromagnétiques se propageant entre un support de transmission telle qu’un guide d’ondes, ou des signaux électriques transmis par câble). Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d’appareil de traitement de données programmable ou sur tout autre dispositif de support de stockage lisible par ordinateur, ou vers un ordinateur externe ou vers un dispositif de stockage externe par un réseau.
Les instructions de programme lisibles par ordinateur, enregistrées sur un support lisible par ordinateur, peuvent être utilisées pour amener un ordinateur, d’autres types d’appareils programmables de traitement de données, ou d’autres dispositifs, à fonctionner d’une façon particulière, de sorte que les instructions stockées sur le support lisible par ordinateur produisent un article de fabrication incluant les instructions qui mettent en œuvre les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou diagrammes blocs. Les instructions de programme informatique peuvent être fournies à un ou plusieurs processeurs d’un ordinateur à usage général ou un ordinateur dédié ou un autre appareil programmable de traitement de données pour produire une machine, de sorte que les instructions, lorsqu’elles sont exécutées par ledit un ou plusieurs processeurs, accomplissent une série de calculs pour mettre en œuvre les fonctions, actions, et/ou les opérations spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs.
Bien que l’invention ait été illustrée par une description de divers modes de réalisation et bien que ces modes de réalisation aient décrits de façon très détaillée, il n’est pas dans l’intention de restreindre ou de limiter d’une quelconque manière le champ d’application des revendications annexées à de tels détails. Des avantages et des modifications supplémentaires apparaîtront aisément aux hommes de métier. Bien que les modes de réalisation des figures 4 et 5 aient été décrits selon un ordre de traitement particulier, l’homme de métier comprendra aisément que l’invention n’est pas limitée à cette séquence d’étapes et que certaines étapes peuvent être implémentées dans un ordre différent. De façon générale, dans certains autres modes de réalisation, les fonctions, les actions et/ou des opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou des diagrammes blocs peuvent être réordonnées, traitées en série, et/ou traitées en même temps conformément aux modes de réalisation de l’invention. De plus, tout organigramme, diagramme séquentiel et/ou diagramme bloc peuvent inclure plus ou moins de blocs que ceux qui sont illustrés, tout en restant cohérents avec les modes de réalisation de l’invention.
Par ailleurs, l’invention n’est pas limitée aux systèmes de transmission de données 10 pour délivrer des produits de voyage et peut s’appliquer à divers types de système de transmission de données. Par exemple, le système de détection d’événement peut être implémenté dans un outil d’optimisation de vente pour détecter les événements correspondant à des changements de tendances de vente, déclencher des actions en réponse aux événements détectés pour optimiser les ventes en utilisant des règles d’action et actualiser les règles de façon dynamique en réponse aux rétroactions d’utilisateurs reçues pour les actions exécutées.
Dans un autre exemple d’application de l’invention, le système de détection d’événement peut être implémenté dans un système de positionnement global utilisé dans un véhicule pour détecter des événements de perturbations de trafic, tels qu’une manifestation ou de mauvaises conditions météorologiques, pour déclencher des actions en réponse aux événements détectés et pour actualiser les règles en réponse aux valeurs de rétroaction reçues pour les actions exécutées.

Claims (14)

  1. Dispositif de gestion d’événements (1) pour gérer des événements, dans lequel le dispositif comprend un détecteur d’événements (101) configuré pour détecter l’apparition d’un événement lié à des données transmises par un système de transmission de données (10) et pour extraire des données d’utilisateur relatives à l’événement détecté d’un stockage de données d’utilisateur (11), les données d’utilisateur extraites comprenant des données d’utilisateur stockées dans au moins une entrée du stockage de données d’utilisateur (11), le dispositif de gestion d’évènement (1) comprenant par ailleurs un gestionnaire de règles (102) configuré pour déterminer une ou plusieurs actions à exécuter en appliquant une ou plusieurs règles utilisant lesdites données d’utilisateur extraites, le dispositif de gestion d’événements (1) étant configuré pour déclencher l’exécution de ladite au moins une action déterminée.
  2. Dispositif selon la revendication 1, dans lequel le gestionnaire de règles (102) comprend une mémoire de règles (401) pour stocker des règles et un moteur de règles (4) pour gérer lesdites règles stockées dans la mémoire de règles (401).
  3. Dispositif selon la revendication 2, dans lequel chaque règle comprend une partie conditions comprenant une combinaison logique d’au moins une condition et une partie actions comprenant une combinaison logique d’au moins une action, le moteur de règles (4) étant configuré pour déterminer ladite au moins une action à exécuter de la partie actions de chaque règle appliquée en fonction de la vérification de la combinaison logique des conditions de la règle appliquée.
  4. Dispositif selon l’une quelconque des revendications 2 et 3, dans lequel les règles sont stockées dans la mémoire de règles (401) sous forme d’une ou de plusieurs structures de donnée d’arbre associées aux règles, le moteur de règles (4) étant configuré pour appliquer une règle à ladite donnée extraite en analysant au moins une structure de donnée d’arbre.
  5. Dispositif selon la revendication 4 dans lequel chaque structure de donnée d’arbre est associée à une règle donnée de la mémoire de règles (401) et représente la partie conditions de la règle.
  6. Dispositif selon l’une quelconque des revendications précédentes, dans lequel le dispositif (1) comprend par ailleurs une unité d’extraction de données (31) configurée pour extraire les données d’utilisateur du stockage de données d’utilisateur (11) en réponse à l’événement détecté, l’unité d’extraction de données (31) étant par ailleurs configurée pour extraire des données liées à l’événement de l’événement détecté.
  7. Dispositif selon la revendication 6, dans lequel l’unité d’extraction de données (31) est configurée pour générer un fichier de description intégrant les données d’utilisateur extraites et/ou les données relatives à l’événement extrait, le fichier de description étant utilisé par le gestionnaire de règles (102) pour déterminer ladite au moins une action à exécuter.
  8. Dispositif selon la revendication 6, dans lequel le gestionnaire de règles (102) est configuré pour sélectionner ladite une ou plusieurs règles à appliquer en utilisant les données d’utilisateur extraites et/ou les données liées à l’événement extrait de l’événement détecté et/ou les données de sources de données externes.
  9. Dispositif selon l’une quelconque des revendications précédentes, dans lequel le stockage de données d’utilisateur (11) comprend une ou plusieurs entrées, les données d’utilisateur stockées dans chaque entrée du stockage de données d’utilisateur comprenant des informations d’utilisateur relatives à un ensemble d’utilisateurs et/ou aux informations de données transmises par ledit système de transmission de données à l’ensemble des utilisateurs.
  10. Dispositif selon l’une quelconque des revendications précédentes 2 à 9, dans lequel le dispositif (1) comprend un moteur d’apprentissage automatique (6) configuré pour déterminer un score de pertinence d’action pour chaque action exécutée, en utilisant des valeurs de rétroaction reçues pour l’action exécutée au cours d’une période.
  11. Dispositif selon la revendication 10, dans lequel le dispositif est configuré pour actualiser les règles de façon dynamique dans la mémoire de règles (401) sur la base des scores de pertinence d’action déterminés pour les actions exécutées associées aux règles
  12. Dispositif selon la revendication 10, dans lequel le dispositif comprend par ailleurs une base de données de pertinence d’action configurée pour stocker, pour chaque action exécutée, le score de pertinence d’action déterminé pour l’action par le moteur d’apprentissage automatique (6), dans lequel le gestionnaire de règles (102) est configuré pour déterminer une action à exécuter sous forme d’une combinaison logique d’actions en utilisant au moins un opérateur booléen, le système (10) étant configuré pour déclencher l’exécution d’au moins une des actions de la combinaison logique déterminée par le gestionnaire de règles (102) sur la base du score de pertinence d’action associé aux actions de la combinaison logique dans la base de données de pertinence d’action.
  13. Procédé pour gérer des événements dans un système de transmission de données, dans lequel le procédé comprend :
    – la détection (402) de l’apparition d’un événement lié aux données transmises par le système de transmission de données (10),
    - l’extraction(404) des données d’utilisateur relatives à l’évènement d’un stockage de données d’utilisateur (11), les données d’utilisateur extraites comprenant des données d’utilisateur stockées dans au moins une entrée du stockage de données d’utilisateur(11),
    – la détermination (406) d’une ou de plusieurs actions à exécuter en appliquant une ou plusieurs règles utilisant les données d’utilisateur extraites comprises dans chacune desdites entrées du stockage de données d’utilisateur.
    – le déclenchement (408) de l’exécution de ladite au moins une action déterminée.
  14. Programme d’ordinateur comprenant des instructions de code de programme pour exécuter les étapes du procédé selon l’une quelconque des revendications 12 et 13 lorsque ledit programme fonctionne sur un ordinateur.
FR1903521A 2019-04-02 2019-04-02 Procédé et dispositif pour la gestion d’évènements Pending FR3094809A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1903521A FR3094809A1 (fr) 2019-04-02 2019-04-02 Procédé et dispositif pour la gestion d’évènements
US16/837,473 US11868316B2 (en) 2019-04-02 2020-04-01 Event management device and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1903521A FR3094809A1 (fr) 2019-04-02 2019-04-02 Procédé et dispositif pour la gestion d’évènements
FR1903521 2019-04-02

Publications (1)

Publication Number Publication Date
FR3094809A1 true FR3094809A1 (fr) 2020-10-09

Family

ID=67875544

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1903521A Pending FR3094809A1 (fr) 2019-04-02 2019-04-02 Procédé et dispositif pour la gestion d’évènements

Country Status (2)

Country Link
US (1) US11868316B2 (fr)
FR (1) FR3094809A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3021788A1 (fr) * 2014-05-30 2015-12-04 Amadeus Sas
FR3062228A1 (fr) * 2017-01-23 2018-07-27 Amadeus S.A.S. Base de donnees agregative d'enregistrements contexte

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9013294B1 (en) * 2012-01-24 2015-04-21 Alarm.Com Incorporated Alarm probability
US10642843B2 (en) * 2015-05-28 2020-05-05 Google Llc World knowledge triggers
US11250343B2 (en) * 2017-06-08 2022-02-15 Sap Se Machine learning anomaly detection
US20200005243A1 (en) * 2018-06-27 2020-01-02 Microsoft Technology Licensing, Llc Automating candidate workflows using configurable rules and network signals

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3021788A1 (fr) * 2014-05-30 2015-12-04 Amadeus Sas
FR3062228A1 (fr) * 2017-01-23 2018-07-27 Amadeus S.A.S. Base de donnees agregative d'enregistrements contexte

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ALOK SINHA: "Client-server computing", COMMUNICATIONS OF THE ACM, ASSOCIATION FOR COMPUTING MACHINERY, INC, UNITED STATES, vol. 35, no. 7, 1 July 1992 (1992-07-01), pages 77 - 98, XP058283551, ISSN: 0001-0782, DOI: 10.1145/129902.129908 *

Also Published As

Publication number Publication date
US20200320038A1 (en) 2020-10-08
US11868316B2 (en) 2024-01-09

Similar Documents

Publication Publication Date Title
US11048530B1 (en) Predictive action modeling to streamline user interface
US20170052652A1 (en) System for high volume data analytics and data ingestion
US10600004B1 (en) Machine-learning based outcome optimization
US20170185904A1 (en) Method and apparatus for facilitating on-demand building of predictive models
US10387536B2 (en) Computerized data-aware agent systems for retrieving data to serve a dialog between human user and computerized system
CN112567394A (zh) 用于在有限的知识领域中构建知识图的技术
US9064212B2 (en) Automatic event categorization for event ticket network systems
US20180005274A1 (en) Management system for high volume data analytics and data ingestion
CN109844781A (zh) 用于从日志文件识别处理流并使流可视化的系统和方法
US20190102791A1 (en) Target user estimation for dynamic assets
US20200159690A1 (en) Applying scoring systems using an auto-machine learning classification approach
US20210263978A1 (en) Intelligent interface accelerating
US20210365611A1 (en) Path prescriber model simulation for nodes in a time-series network
CN115151928A (zh) 使用机器学习技术的用于通信工作流的增强的处理
US20170337601A1 (en) Monetization of interactive network-based information objects
US20190171977A1 (en) Using Machine Learning System to Dynamically Process Events
FR3090926A1 (fr) Procédé et système autoadaptatif d’agrégation de sources de données
Basak et al. Stream Analytics with Microsoft Azure: Real-time data processing for quick insights using Azure Stream Analytics
US11289076B2 (en) Assisting meeting participants via conversation loop detection and resolution using conversation visual representations and time-related topic usage
US11615097B2 (en) Triggering a user interaction with a device based on a detected signal
FR3099613A1 (fr) Systèmes d’apprentissage automatiques et procédés pour le placement de données dans le stockage distribué
FR3094809A1 (fr) Procédé et dispositif pour la gestion d’évènements
US11119734B2 (en) Software detection and modification
US11734586B2 (en) Detecting and improving content relevancy in large content management systems
FR3079040A1 (fr) Systeme et procede de fourniture de produits

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20201009

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6