FR3084947A1 - Systèmes et procédés de contrôle des mises à jour des données de réservation - Google Patents
Systèmes et procédés de contrôle des mises à jour des données de réservation Download PDFInfo
- Publication number
- FR3084947A1 FR3084947A1 FR1857434A FR1857434A FR3084947A1 FR 3084947 A1 FR3084947 A1 FR 3084947A1 FR 1857434 A FR1857434 A FR 1857434A FR 1857434 A FR1857434 A FR 1857434A FR 3084947 A1 FR3084947 A1 FR 3084947A1
- Authority
- FR
- France
- Prior art keywords
- data
- server
- purchase
- product
- reservation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 64
- 238000012544 monitoring process Methods 0.000 title description 3
- 230000000977 initiatory effect Effects 0.000 claims abstract description 131
- 230000004044 response Effects 0.000 claims abstract description 36
- 230000002452 interceptive effect Effects 0.000 claims abstract description 32
- 230000005540 biological transmission Effects 0.000 claims abstract description 24
- 238000001514 detection method Methods 0.000 claims description 63
- 230000008569 process Effects 0.000 claims description 13
- 238000010200 validation analysis Methods 0.000 claims description 4
- 238000012790 confirmation Methods 0.000 description 23
- 230000015654 memory Effects 0.000 description 23
- 230000010006 flight Effects 0.000 description 12
- 238000004891 communication Methods 0.000 description 10
- 238000011160 research Methods 0.000 description 7
- 230000007246 mechanism Effects 0.000 description 6
- 238000012545 processing Methods 0.000 description 5
- 230000009471 action Effects 0.000 description 4
- 238000013145 classification model Methods 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 238000003058 natural language processing Methods 0.000 description 3
- RZVAJINKPMORJF-UHFFFAOYSA-N Acetaminophen Chemical compound CC(=O)NC1=CC=C(O)C=C1 RZVAJINKPMORJF-UHFFFAOYSA-N 0.000 description 2
- 241000699670 Mus sp. Species 0.000 description 2
- 238000013528 artificial neural network Methods 0.000 description 2
- 238000013475 authorization Methods 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000012549 training Methods 0.000 description 2
- 230000001052 transient effect Effects 0.000 description 2
- 241000699666 Mus <mouse, genus> Species 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 239000003086 colorant Substances 0.000 description 1
- 238000013527 convolutional neural network Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000010801 machine learning Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
Classifications
-
- 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
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
- G06Q30/0635—Processing of requisition or of purchase orders
- G06Q30/0637—Approvals
-
- 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
- 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/10—Office automation; Time management
- G06Q10/109—Time management, e.g. calendars, reminders, meetings or time accounting
- G06Q10/1093—Calendar-based scheduling for persons or groups
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- 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
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0623—Item investigation
-
- 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
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
- G06Q50/14—Travel agencies
-
- 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/10—Office automation; Time management
- G06Q10/107—Computer-aided management of electronic mailing [e-mailing]
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Accounting & Taxation (AREA)
- General Business, Economics & Management (AREA)
- Human Resources & Organizations (AREA)
- Tourism & Hospitality (AREA)
- Finance (AREA)
- Economics (AREA)
- Marketing (AREA)
- Entrepreneurship & Innovation (AREA)
- Development Economics (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Evolutionary Computation (AREA)
- Medical Informatics (AREA)
- Computer Security & Cryptography (AREA)
- Artificial Intelligence (AREA)
- General Engineering & Computer Science (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Primary Health Care (AREA)
- Information Transfer Between Computers (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
Un procédé de contrôle des mises à jour des données de réservation correspondant à des produits achetables comprend, au niveau d'un serveur intermédiaire connecté à un serveur de réservation : l'obtention et le stockage de données d'initiation d'achat comprenant un identifiant de transaction et un identifiant de client ; la transmission d'une demande de définitions de produit au serveur de réservation, selon les données d'initiation d'achat ; la réception et le stockage d'une définition de produit du serveur de réservation en association avec les données d'initiation d'achat ; la génération d'un message interactif contenant des données de définition de produit sélectionnables, et la transmission du message interactif en fonction de l'identifiant d'adressage du client ; la réception d'une sélection de produit, en réponse à la sélection des données de définition de produit dans le message interactif sur un dispositif du client ; et la génération d'une instruction d'achat correspondant à la définition de produit et l'envoi de l'instruction d'achat au serveur de réservation amenant le serveur de réservation à mettre à jour les données de réservation pour refléter un achat correspondant à l'identifiant d'adressage du client.
Description
SYSTÈMES ET PROCÉDÉS DE CONTRÔLE DES MISES À JOUR DES DONNÉES DE RÉSERVATION
DOMAINE [0001] La spécification concerne de façon générale le traitement des données de réservation correspondant à des produits achetables, et plus particulièrement à des systèmes et procédés de contrôle des mises à jour de ces données de réservation.
CONTEXTE [0002] Certains produits (p. ex. les services de voyage tels que les billets d'avion, de train et d'autobus, les réservations d'hôtel et autres) peuvent être achetés par voie électronique par le biais de sessions internet, au cours desquelles un dispositif informatique du client exploité par un utilisateur cherchant à acheter un produit communique avec un serveur Web hébergeant les données de réservation. Les sessions internet mentionnées ci-dessus expirent généralement après des périodes de temps relativement courtes, ce qui peut conduire à des sessions incomplètes et à l'abandon de transactions ou à la répétition d'initiations de transactions consommatrices de ressources, ou aux deux.
RÉSUMÉ [0003] Un aspect de la spécification fournit un procédé de contrôle des mises à jour d'un serveur de réservation conservant les données de réservation correspondant aux produits achetables, le procédé comprenant : au niveau d’un serveur intermédiaire connecté au serveur de réservation, l’obtention de données d'initiation d'achat comprenant un identifiant de transaction et un identifiant d'adressage du client ; le stockage des données d'initiation d'achat dans un dépositaire sur le serveur intermédiaire ; sur le serveur intermédiaire, la génération et la transmission d’une demande de définition de produit au serveur de réservation, selon les données d'initiation d'achat ; la réception d’une définition de produit du serveur de réservation, et le stockage de la définition de produit dans le dépositaire en association avec les données d'initiation d'achat ; la génération d’un message interactif contenant des données de définition de produit sélectionnables, et la transmission du message interactif en fonction de l'identifiant d'adressage du client ; la réception d’une sélection de produit sur le serveur intermédiaire, en réponse à la sélection des données de définition de produit dans le message interactif sur un dispositif du client correspondant à l'identifiant d'adressage du client ; et en réponse à la réception de la sélection de produit, la génération d’une instruction d'achat correspondant à la définition de produit et l’envoi d’instruction d'achat au serveur de réservation, amenant le serveur de réservation à mettre à jour les données de reservation pour refléter un achat correspondant à l'identifiant d'adressage du client. [0004] Dans un autre mode de réalisation, le procédé comprend par ailleurs, avant de stocker les données d'initiation d'achat, la validation des données d'initiation d'achat. Dans encore un autre mode de réalisation, l'obtention des données d'initiation d'achat comprend la réception des données d'initiation d'achat sur le serveur intermédiaire à partir du serveur de réservation ou la réception des données d’initiation d'achat à partir d'un serveur de détection.
[0005] Dans un autre mode de réalisation, le procédé comprend par ailleurs, au niveau du serveur de detection : la réception des données d'entrée brutes du dispositif du client ; la classification des données d'entrée brutes pour déterminer si les données d'entrée brutes indiquent un événement d'intention d'achat ; lorsque la classification indique un événement d'intention d'achat, l'extraction des paramètres d'initiation d'achat à partir des données d'entrée brutes ; et la transmission des paramètres d'initiation d'achat au serveur intermédiaire.
[0006] Dans un autre mode de réalisation, les données d'entrée brutes comprennent au moins une des données de messagerie et des données de calendrier. Dans encore un autre mode de réalisation, les données de définition de produit sélectionnables contiennent des données de génération de commandes, amenant le dispositif du client, en réponse à la sélection des données de définition de produit, à générer une commande contenant la sélection de produit pour transmission au serveur intermédiaire.
[0007] Dans un mode de réalisation, le procédé comprend par ailleurs, au niveau du serveur intermédiaire : avant de générer et de transmettre la demande de définitions de produits, de déterminer si les données d'initiation d'achat contiennent un sous-ensemble minimum de paramètres d’initiation d'achat ; et lorsque la détermination est négative, de générer un message de retour contenant une invite pour au moins l'un des sousensembles minimums, pour transmission au dispositif du client.
[0008] Dans un autre mode de réalisation, le procédé comprend par ailleurs : la récupération d un identifiant d’approbation d'adressage ; la génération et la transmission d un message de demande d'approbation en fonction de l'identifiant d'autorisation d adressage, le message de demande d'autorisation contenant un élément d'approbation sélectionnable correspondant à la sélection du produit ; et la réception d'une sélection de l'élément d'approbation.
[0009] Dans un autre mode de réalisation, la génération du message de demande d approbation comprend par ailleurs : la récupération d'une sélection de produit supplémentaire correspondant à l'identifiant d'approbation d’adressage ; et la génération d'un message de demande agrégé contenant l'élément d'approbation sélectionnable et un élément d'approbation supplémentaire sélectionnable correspondant à la sélection de produit supplémentaire.
[0010] Un autre aspect de la spécification prévoit un système de contrôle des mises à jour d'un serveur de réservation conservant des données de réservation correspondant aux produits achetables, le système comprenant : un serveur intermédiaire connecté au serveur de réservation et configuré pour : obtenir des données d'initiation d'achat comprenant un identifiant de transaction et un identifiant d’adressage du client ; stocker les données d initiation d'achat ; générer et transmettre une demande de définitions de produit au serveur de réservation, en fonction des données d'initiation d'achat ; recevoir une définition de produit du serveur de réservation et stocker la définition de produit en association avec les données d'initiation d'achat ; générer un message interactif contenant des données de définition de produit sélectionnables, et transmettre le message interactif selon l'identifiant d'adressage du client ; recevoir une sélection de produit sur le serveur intermédiaire, en réponse à la sélection des données de définition de produit dans le message interactif sur un dispositif du client correspondant à l'identifiant d'adressage du client ; et en réponse à la réception de la sélection de produit, générer une instruction d achat correspondant à la définition de produit et envoyer l'instruction d'achat au serveur de réservation permettant au serveur de réservation de mettre à jour les données de réservation pour refléter un achat correspondant à l'identifiant d'adressage du client.
[0011] Dans un autre mode de réalisation, le serveur intermédiaire est en outre configuré, avant de stocker les données d'initiation d'achat, pour valider les données d'initiation d'achat et/ou dans lequel le serveur intermédiaire est en outre configuré pour obtenir les données d'initiation d'achat en recevant les données d'initiation d'achat du serveur de réservation. Dans un autre mode de réalisation, le système comprend en outre : un serveur de détection ; dans lequel le serveur intermédiaire est configuré pour obtenir les données d'initiation d'achat en recevant les données d'initiation d'achat du serveur de détection.
[0012] Dans encore un autre mode de réalisation, le serveur de détection est configuré pour : recevoir les données d'entrée brutes du dispositif du client ; classifier les données d entrée brutes pour déterminer si les données d'entrée brutes indiquent un événement d'intention d'achat ; lorsque la classification indique un événement d'intention d'achat, extraire les paramètres d’initiation d'achat des données d'entrée brutes ; et transmettre les paramètres d'initiation d'achat au serveur intermédiaire.
[0013] Dans un autre mode de réalisation, les données d'entrée brutes comprennent au moins une des données de messagerie et des données de calendrier. Dans encore un autre mode de réalisation, les données de définition de produits sélectionnables contiennent des données de génération de commandes, permettant au dispositif du client, en réponse à la sélection des données de définition de produit, de générer une commande contenant la sélection de produit pour transmission au serveur intermédiaire. [0014] Dans un autre mode de réalisation, le serveur intermédiaire est en outre configuré pour : avant de générer et de transmettre la demande de définitions de produit, déterminer si les données d'initiation d'achat contiennent un sous-ensemble minimum de paramètres d'initiation d'achat ; et lorsque la détermination est négative, générer un message de retour contenant une invite pour au moins l'un des sous-ensembles minimums, pour transmission au dispositif du client.
[0015] Dans un autre mode de réalisation, le serveur intermédiaire est en outre configuré pour : récupérer un identifiant d'adressage d'approbation ; générer et transmettre un message de demande d'approbation en fonction de l'identifiant d'adressage d'approbation, le message de demande d'approbation contenant un élément d'approbation sélectionnable correspondant à la sélection du produit ; et recevoir une sélection de l'élément d'approbation.
[0016] Dans un autre mode de réalisation, le serveur intermédiaire est en outre configuré pour générer le message de demande d'approbation en : récupérant une sélection de produit supplémentaire correspondant à l'identifiant d'adressage d'approbation ; et en générant un message de demande agrégé contenant l'élément d approbation sélectionnable et un élément d'approbation supplémentaire sélectionnable correspondant à la sélection de produit supplémentaire.
BREVE DESCRIPTION DES DESSINS [0017] Des modes de réalisation sont décrits en référence aux figures suivantes, dans lesquelles :
[0018] La FIG. 1 décrit un système de contrôle des mises à jour des données de réservation [0019] Les FIGS. 2A et 2B décrivent certains composants internes d'un serveur intermédiaire et un serveur de détection du système de la FIG. 1 ;
[0020] La FIG. 3 décrit un procédé pour contrôler les mises à jour des données de réservation ;
[0021] La FIG. 4 décrit un procédé pour détecter les événements initiant l’exécution du procédé de la FIG. 3 ;
[0022] La FIG. 5 illustre une exécution du procédé de la FIG. 4 ;
[0023] La FIG. 6A décrit un autre exemple d'événement pour initier l’exécution du procédé de la FIG. 3 ;
[0024] Les FIGS. 6B, 7A et 7B décrivent des exemples de messages transmis par le serveur intermédiaire lors de l'exécution du procédé de la FIG. 3 ;
[0025] La FIG. 8 décrit un procédé d'obtention d'approbation pour les transactions initiées via le procédé de la FIG. 3 ; et [0026] La FIG. 9 décrit un exemple de message transmis par le serveur intermédiaire lors de l'exécution du procédé de la FIG. 8.
DESCRIPTION DÉTAILLÉE [0027] La FIG. 1 décrit un système 100 pour contrôler les mises à jour des données de réservation correspondant aux produits achetables. Le système 100 comprend un serveur de réservation 104 qui conserve les données de réservation susmentionnées dans un dépositaire 108. La structure du serveur de réservation 104 et le dépositaire 108 ne sont spécifiquement limités. Par exemple, le dépositaire 108 peut être implémenté sous la forme d'une pluralité de bases de données ou d'autres structures de stockage de données appropriées. En général, le dépositaire 108 contient des données définissant n’importe quelle variété de produits achetables (p. ex. des biens et/ou services). Dans la discussion ci-dessous, les produits achetables représentés par les données de réservation comprennent les services de voyage, tels que les billets d'avion (également appelés simplement vols). Dans d'autres exemples, divers autres services de voyage peuvent être représentés dans les données de réservation en plus ou à la place des vols. Par exemple, les données de réservation dans le dépositaire 108 peuvent définir les réservations d'hôtel, les billets de train, les billets d'autobus, les réservations de taxi, etc. Une grande variété d'autres biens et/ou services, généralement appelés produits dans le présent document, apparaîtront pour les hommes de métier comme étant des produits définissables dans le dépositaire 108.
[0028] Les données de réservation dans le dépositaire 108 définissent également I inventaire disponible correspondant aux produits mentionnés ci-dessus, ainsi que les registres d'achat indiquant les produits qui ont été achetés. Dans le contexte des vols pouvant être achetés, le dépositaire 108 définit donc non seulement les vols disponibles (p. ex. par lieux de départ et d'arrivée, dates et heures, prix, etc.), mais aussi le nombre de sièges disponibles à l'achat sur chacun des vols susmentionnés, ainsi que les données d'identification correspondant aux sièges ayant été achetés (p. ex. les identifiants de client, les informations de paiement et autres). Comme indiqué plus haut, le dépositaire 108 peut être implémenté sous la forme d'une pluralité de bases de données distinctes dans certains modes de réalisation, et l'inventaire peut donc être conservé séparément des définitions de produits ou des registres d'achats. La structure spécifique du serveur de réservation 104 et du dépositaire 108 dépasse le cadre de la présente révélation et n est donc pas abordée de manière plus détaillée dans le présent document.
[0029] Comme le verront désormais clairement les hommes de métier, les achats des produits susmentionnés nécessitent une mise à jour du dépositaire 108, par exemple pour tenir compte des changements dans les stocks disponibles, pour stocker d'autres documents d'achat, et autres. Comme on le verra aussi clairement, le serveur de réservation 104 ou un serveur associé (non illustré) peut héberger un site Web par l'intermédiaire duquel les produits définis dans le dépositaire 108 peuvent être achetés via des interactions entre le serveur de réservation 104 et un dispositif informatique du client 112, tel qu'un smartphone, un ordinateur de bureau ou similaire, sur un réseau 116. Le système 100 peut inclure une pluralité de dispositifs du client, mais un seul dispositif du client 112 est illustré par souci de simplicité. Le réseau 116 peut comprendre toute combinaison appropriée de réseaux locaux et de réseaux étendus (p. ex. incluant Internet), implémentés sous la forme de toute combinaison appropriée de réseaux câblés et/ou sans fil.
[0030] La plate-forme d'achat en ligne susmentionnée peut toutefois exiger qu'une transaction (c'est-à-dire le processus visant à demander des définitions de produits auprès du serveur 104, à sélectionner et acheter un ou plusieurs produits) soit effectuée sur une durée relativement limitée et continue (p. ex. de cinq à dix minutes), au-delà de laquelle une transaction incomplète est annulée et doit être recommencée. En plus de la plate-forme Web, le système 100 comprend donc un serveur intermédiaire 120 connecté au réseau 116 et configuré pour servir d'intermédiaire entre le dispositif du client 112 et le serveur de réservation 104. Spécifiquement, le serveur intermédiaire 120 met en œuvre une fonctionnalité permettant de conserver au moins une partie de ia progression d'une transaction à la suite d'interruptions de la transaction sur des périodes plus longues que les périodes relativement courtes mentionnées ci-dessus (c.-à-d. pour permettre aux transactions d'être terminées de manière asynchrone). De plus, le serveur intermédiaire
120 peut implémenter une fonctionnalité permettant de déclencher automatiquement ou semi-automatiquement les transactions. En d'autres termes, le serveur intermédiaire 120 est configuré pour contrôler la mise à jour des données de réservation dans le dépositaire 108 afin d'atténuer l'incidence des transactions annulées (ce qui peut conduire à des transactions supplémentaires identiques imposant une charge de calcul supplémentaire au système 100, et en particulier au serveur de réservation 104).
[0031] À cette fin, comme nous le verrons plus en détail ci-après, le serveur intermédiaire 120 conserve un dépositaire de transactions 124 contenant des registres définissant chacun une transaction en attente ou terminée. Sur la base des interactions avec le serveur de réservation 104, le dispositif du client 112 et éventuellement d'autres dispositifs informatiques qui seront également abordés dans le présent document, le serveur intermédiaire 120 est configuré pour mettre à jour les registres des transactions en attente mentionnés ci-dessus et pour appliquer les mises à jour correspondantes aux données de réservation dans le dépositaire 108 sous certaines conditions.
[0032] Le serveur intermédiaire 120 peut également inclure une file d'attente d'initiation 128, qui, bien que désignée ici comme une file d'attente, n'a pas besoin d’être structurée spécifiquement comme une file d'attente (p. ex. une structure premier entré premier sorti ou une autre structure de file d'attente appropriée). Plus généralement, la file d attente d initiation 128 stocke les données d'initiation d'achat obtenues par le serveur intermédiaire 120 pour initier des transactions correspondant aux produits représentés dans les données de réservation du dépositaire 108. Les données d'initiation d'achat reçues sur le serveur intermédiaire 120 pour le stockage dans la file d'attente 128 avant la poursuite du traitement peuvent être reçues, par exemple, d'un serveur de détection 132 connecté au réseau 116. Le serveur de détection 132 est configuré pour obtenir et traiter les données associées au dispositif du client 112, pour détecter automatiquement les événements d intention d'achat (c'est-à-dire les indications de transactions souhaitées pour acheter des produits représentés dans le dépositaire 108). Le serveur de détection 132 conserve donc un dépositaire de données brutes 136 configuré pour stocker les données susmentionnées associées au dispositif du client 112 avant de passer à la détection des événements liés à l'intention d'achat.
[0033] De plus, le système 100 comprend également un serveur de messagerie 140 qui conserve un dépositaire de messagerie 144. Le serveur de messagerie 140 peut implémenter une ou plusieurs d’une variété de technologies de messagerie adaptées à l'échange de données avec le dispositif du client 112. Dans les exemples abordés cidessous, le serveur de messagerie 140 est un serveur de messagerie, et le dépositaire de messagerie 144 contient donc des messages électroniques correspondant au dispositif du client 112 (ou, plus précisément, à un compte de messagerie accessible depuis le dispositif du client 112). Le dépositaire 144 peut également contenir des messages électroniques correspondant à d'autres dispositifs des clients (non affichés) et est généralement configuré à la fois pour transmettre les messages entrants reçus d'autres entités (p. ex. le serveur intermédiaire 120) au dispositif du client 112 et pour transmettre les messages sortants du dispositif du client 112 à ces autres entités. Les messages entrants et sortants, dans certains modes de réalisation, n'ont pas besoin d'être des messages électroniques, mais peuvent être à la place des commandes pour mettre à jour le contenu des messages électroniques ou des commandes résultant de l'interaction avec les messages électroniques au niveau du dispositif du client 112, comme nous l’aborderons plus en détail ci-dessous.
[0034] Le système 100 peut également inclure un serveur d'entreprise 148, par exemple associé à un employeur d'un opérateur du dispositif du client 112. Le serveur d’entreprise 148 peut conserver une base de données de profils 152 contenant des enregistrements de profils correspondant au dispositif du client 112 (et à tout autre dispositif du client 112 dans le système 100). Les enregistrements de profil peuvent inclure des informations d'identification correspondant à l'opérateur du dispositif du client 112 (p. ex. nom, adresse postale, adresse électronique, informations de paiement et autres), ainsi que des indicateurs de politique correspondant à l'opérateur du dispositif du client 112, telles que les destinations de voyage autorisées ou d'autres conditions imposées sur les achats de produits par l'opérateur, les indications sur le fait que ces achats de produits nécessitent l'approbation d'une autre entité, etc. Le serveur d’entreprise 148 peut également conserver un dépositaire de dépenses d’entreprise 156 configuré pour stocker des enregistrements définissant les dépenses à approuver, ou d'autres demandes soumises à l'approbation de la direction au sein de l'entreprise, comme nous l'aborderons plus en détail ci-dessous. Le dépositaire des dépenses 156 peut également, comme nous l’aborderons plus en détail ci-dessous, suivre les exigences en matière d'approbation et/ou le statut d'approbation des transactions d'achat, et peut inclure un ou plusieurs identifiants d'approbateur correspondant aux parties approuvant les transactions d'achat initiées en association avec l'opérateur du dispositif 112.
[0035] Dans d'autres exemples, le serveur d'entreprise 148 peut être omis. Dans de tels exemples, les données en matière de profil et/ou de politique mentionnées ci-dessus peuvent être omises ou stockées dans un ou plusieurs autres emplacements, tels que le dispositif du client 112 et/ou le serveur de réservation 104. Dans certains exemples, le serveur intermédiaire 120 lui-même peut stocker de telles données de profil et/ou de politique.
[0036] Faisant référence aux FIGS. 2A et 2B, avant d'aborder plus en détail la fonctionnalité du système 100, certains composants du serveur intermédiaire 120 et du serveur de détection 132 seront abordés plus en détail.
[0037] Faisant référence à la FIG. 2A, le serveur intermédiaire 120 comprend au moins un processeur 200, tel qu'une unité centrale de traitement (CPU) ou similaire. Le processeur 200 est interconnecté avec une mémoire 204, implémentée en tant que support non transitoire lisible par ordinateur (p. ex. une combinaison appropriée de soussystèmes de mémoire non volatile et volatile comprenant une ou plusieurs mémoires à accès aléatoire (RAM), une mémoire à lecture seule (ROM), une mémoire à lecture exclusivement programmable et effaçable électriquement (EEPROM), une mémoire flash, un stockage magnétique sur ordinateur, etc.) Le processeur 200 et la mémoire 204 sont généralement composés d'un ou de plusieurs circuits intégrés (Cl).
[0038] Le processeur 200 est également interconnecté avec une interface de communication 208, ce qui permet au serveur 120 de communiquer avec les autres dispositifs informatiques du système 100 via le réseau 116. L'interface de communication 208 comprend donc tous les composants nécessaires (p. ex. les contrôleurs d'interface réseau (NIC), les unités radio et autres) pour communiquer via le réseau 116. Les composants spécifiques de l'interface de communication 208 sont sélectionnés en fonction de la nature du réseau 116. Le serveur intermédiaire 120 peut également inclure des dispositifs d'entrée et de sortie connectés au processeur 200, tels que claviers, souris, écrans, et similaires (non illustrés).
[0039] Les composants du serveur intermédiaire 120 mentionné ci-dessus peuvent être déployés dans une enveloppe unique, ou dans un format distribué. Dans certains exemples, donc, le serveur intermédiaire 120 comprend une pluralité de processeurs, soit partageant la mémoire 204 et l'interface de communication 208, soit chacun ayant des mémoires distinctes associées et des interfaces de communication.
[0040] La mémoire 204 stocke le dépositaire 124 et la file d’attente 128 telle qu'elle a été présentée en rapport avec la FIG. 1. La mémoire 204 stocke également une pluralité d instructions de programmation lisibles par ordinateur, exécutables par le processeur 200, sous la forme de diverses applications, y compris une application d’orchestrateur 212 et une application génératrice de messages 216. Comme l'entendront les hommes de métier, le processeur 200 exécute les instructions des applications 212 et 216 (et toute autre application appropriée) afin d'effectuer diverses actions définies par les instructions qui y sont contenues. Dans la description ci-dessous, le processeur 200, et plus généralement le serveur intermédiaire 120, sont dits être configurés pour effectuer ces actions. Il sera entendu qu'ils sont ainsi configurés via l'exécution (par le processeur 200) des instructions des applications stockées dans la mémoire 204. L’exécution de I application d orchestrateur 212, comme nous l’aborderons plus loin, configure le serveur intermédiaire 120 pour récupérer les données d'initiation d'achat de la file d'attente 128 (et éventuellement, pour valider les données d'initiation d'entrée avant de stocker les données dans la file d'attente 128), et pour interagir avec le serveur de réservation 104 pour récupérer les données de définition de produit du dépositaire 108 et, sous certaines conditions, pour appliquer les mises à jour au dépositaire 108.
[0041] L'application d’orchestrateur 212 peut également implémenter une ou plusieurs interfaces de programmation d'application (API) exposées à d'autres dispositifs informatiques via le réseau 116, pour recevoir diverses données relatives aux transactions représentées dans le dépositaire 124. L'exécution de l'application du générateur de messages 216 configure le serveur intermédiaire 120 pour générer et transmettre des messages au dispositif du client 112 (p. ex., via le serveur de messagerie
140) en réponse aux activités implémentées par l'application d’orchestrateur 212. Dans le présent exemple, I application du générateur de messages 216 configure le serveur intermédiaire 120 pour générer des messages électroniques. En particulier, comme on le verra plus loin, l'application du générateur de messages 216 configure le serveur intermédiaire 120 pour générer des messages électroniques contenant des éléments interactifs, tels que des « messages actionnables » à utiliser dans l'infrastructure de messagerie Microsoft™ Outlook.
[0042] Faisant référence à la FIG. 2B, le serveur de détection 132 comprend au moins un processeur 250, tel qu’une unité centrale de traitement (UCT) ou similaire. Le processeur 250 est interconnecté avec une mémoire 254, implémentée en tant que support non transitoire lisible par ordinateur (p. ex. une combinaison appropriée de soussystèmes de mémoire non volatile et volatile comprenant une ou plusieurs mémoires à accès aléatoire (RAM), une mémoire à lecture seule (ROM), une mémoire à lecture exclusivement programmable et effaçable électriquement (EEPROM), une mémoire flash, un stockage magnétique sur ordinateur, et ainsi de suite). Le processeur 250 et la mémoire 254 sont généralement composés d'un ou de plusieurs circuits intégrés (Cl).
[0043] Le processeur 250 est également interconnecté avec une interface de communication 258, ce qui permet au serveur 132 de communiquer avec les autres dispositifs informatiques du système 100 via le réseau 116. L'interface de communication 258 comprend donc tous les composants nécessaires (p. ex. les contrôleurs d'interface réseau CIR), les unités radio et autres) pour communiquer via le réseau 116. Les composants spécifiques de l'interface de communication 258 sont sélectionnés en fonction de la nature du réseau 116. Le serveur de détection 132 peut également inclure des dispositifs d’entrée et de sortie connectés au processeur 250, tels que claviers, souris, écrans, et autres (non illustrés).
[0044] Les composants du serveur de détection 132 mentionné ci-dessus peuvent être déployés dans une seule enveloppe ou dans un format distribué. Dans certains exemples, donc, le serveur de détection 132 comprend une pluralité de processeurs, soit partageant la mémoire 254 et l'interface de communication 258, soit chacun ayant des mémoires et des interfaces de communication associées distinctes.
[0045] La mémoire 254 stocke le dépositaire de données brutes 136 tel que présenté en rapport avec la FIG. 1. La mémoire 254 stocke également une pluralité d'instructions de programmation lisibles par ordinateur, exécutables par le processeur 250, sous la forme de diverses applications, y compris une application de détection de l'intention d'achat 262 (appelée également de manière simple l’application de détection 262). L'application de détection 262, lorsqu'elle est exécutée par le processeur 250, configure le processeur 250 (et le serveur 132 plus généralement) pour recevoir et stocker divers types de données associées au dispositif du client 112 dans le dépositaire 136, et pour traiter ces données afin de détecter les événements liés à l'intention d'achat. De plus, le serveur 132 est configuré, via l'exécution de l'application de détection 262, pour générer des données d initiation d'achat en réponse à la détection d'un événement d'intention d'achat, pour transmission au serveur intermédiaire 120.
[0046] Faisant maintenant référence à la FIG. 3, certains aspects du fonctionnement du système 100 seront décrits plus en détail. Plus précisément, la FIG. 3 illustre un procédé 300 de contrôle des mises à jour du serveur de réservation 104 (plus précisément, au dépositaire 108 des données de réservation). Le procédé 300 sera décrit en conjonction avec ses exécutions au sein du système 100. En particulier, les blocs du procédé 300 sont effectués par le serveur intermédiaire 120 via l'exécution de (application d’orchestrateur 212 et l'application de générateur de messages 216 par le processeur 200. D'autres aspects du fonctionnement du système 100 (en particulier la fonctionnalité implémentée par le serveur de détection 132) seront abordés plus loin dans le présent document.
[0047] Au bloc 305, le serveur intermédiaire est configuré pour obtenir les données d'initiation d'achat et stocker les données d'initiation d'achat dans la file d'attente 128. Les données d'initiation d'achat peuvent provenir de diverses sources de données d'initiation, y compris le serveur de détection 132, le serveur de réservation 104 et le serveur intermédiaire 120 lui-même (c'est-à-dire que les données d'initiation d'achat peuvent être reçues par le biais d'une génération interne). Les données d'initiation d'achat comprennent au moins un identifiant d'adressage du client approprié pour diriger les messages vers le dispositif du client 112 (p. ex. une adresse électronique, un numéro de téléphone, un identifiant interne attribué par l'entreprise, comme un identifiant de connexion ou autre). Typiquement, les données d'initiation d'achat comprennent également au moins un ensemble prédéfini de paramètres définissant une ou plusieurs caractéristiques du produit. Des exemples de caractéristiques de produit, dont d'autres exemples apparaîtront clairement dans la discussion ci-dessous, comprennent les lieux d'origine et de destination des produits liés au voyage, tels que les vols.
[0048] Les données d initiation d'achat proviennent d'un événement lié à l'intention d'achat. Un événement d'intention d'achat est une indication selon laquelle l'opérateur du dispositif du client 112 a l'intention, ou a probablement l'intention d'acheter un produit défini dans les données de réservation du dépositaire 108. Divers mécanismes sont envisagés pour la génération de données sur l’initiation d'achat en réponse aux événements d intention d'achat. Dans le présent exemple, un événement d'intention d achat est détecté par le serveur de détection 132 et les données d'initiation d'achat générées correspondant à l'événement d'intention d'achat sont générées par le serveur de détection 132 pour transmission au serveur intermédiaire 120 et stockage dans la file d'attente 128. Avant de continuer l’implémentation du procédé 300, la détection des événements d’intention d'achat et la génération de données d’initiation d'achat seront abordées plus en détail dans le cadre de la FIG. 4.
[0049] La FIG. 4 illustre un procédé 400 de détection des événements d’intention d'achat et de production de données d’initiation d’achat en réponse à une telle détection. Le procédé 400 sera abordé en conjonction avec ses exécutions dans le système 100, et en particulier par le serveur de détection 132. Au bloc 405, le serveur de détection 132 est configuré pour obtenir des données brutes du dispositif du client 112. La nature des données brutes n'est pas spécifiquement limitée et peut inclure l'une quelconque, ou toute combinaison, des données de message (p. ex. courriel, messagerie instantanée et autres), des données de calendrier (p. ex. des chaînes de texte définissant les événements et les dates correspondantes), etc. Les données brutes peuvent être obtenues via l'exécution d'une application de surveillance exécutée par le dispositif du client 112, configurant le dispositif du client 112 pour transmettre des copies de messages et/ou de données de calendrier au serveur de détection 132 pour stockage dans le dépositaire de données brutes 136. Dans d'autres exemples, le serveur de détection 132 peut déclencher un chatbot (ou agent de conversation) (p. ex. un service de messagerie instantanée autonome ou semi-autonome) configuré pour recevoir et répondre aux messages provenant du dispositif du client 112, et pour stocker le contenu de ces messages dans le dépositaire de données brutes 136.
[0050] Au bloc 410, le serveur de détection 132 est configuré pour récupérer un élément de données brutes du dépositaire 136 (p. ex. un message électronique et/ou un fil de messages électroniques, un fil de messagerie instantanée, un événement de calendrier ou autre) et pour classer l'élément de données brutes. Comme on le verra désormais clairement, le bloc 410 et les blocs restants du procédé 400 sont exécutés pour chaque élément des données brutes dans le dépositaire 136. Les éléments de données brutes dans le dépositaire 136 peuvent être traités de manière séquentielle comme avancé ci-dessous, en parallèle ou selon une combinaison de ces éléments.
[0051] Le serveur de détection 132 est configuré, au bloc 410, pour classer l'élément courant de données brutes comme indicatif ou non indicatif d'un événement d'intention d'achat. La production au bloc 410 peut être une étiquette de classification (p. ex. « intention d'achat » ou « aucune intention d'achat »), un niveau de confiance associé à une étiquette (p. ex. une probabilité de 92 % d'intention d'achat) ou autre. La classification au bloc 410 comprend deux étapes dans le présent exemple. Dans la première étape, le serveur de détection 132 est configuré pour analyser l'élément de données brutes, par exemple pour tokéniser le texte dans l'élément de données brutes, rejeter les mots moins significatifs, etc. Une variété de mécanismes d'analyse appropriés (p. ex. ceux qui sont disponibles par le biais de diverses suites de traitement du langage naturel) sera proposée aux hommes de métier. Dans la deuxième étape, le serveur de détection 132 est configuré pour appliquer un modèle de classification aux données brutes analysées afin d'attribuer une classification à l'élément de données brutes. Le modèle de classification est basé sur n'importe quel modèle d'apprentissage automatique approprié, dont des exemples incluent une machine vectorielle de soutien (MVS), un champ aléatoire conditionnel, un réseau neuronal (p. ex. un réseau neuronal convolutif ou un réseau neuronal profond), etc. Le modèle de classification est stocké dans le serveur de détection 132 (p. ex. en tant que composant de l’application 262), après avoir été généré par un processus de formation basé sur un ensemble de données brutes étiquetées avec des classifications correctes (c'est-à-dire indiquant correctement si chaque donnée brute de l'ensemble de formation correspond ou non à un événement d'intention d'achat).
[0052] Au bloc 415, après avoir classé l'élément de données brutes, le serveur de détection 132 est configuré pour déterminer si l'élément de données brutes indique un événement d'intention d'achat. Par exemple, la détermination au bloc 415 peut comprendre la comparaison d'un niveau de confiance généré au bloc 410 avec un seuil prédéfini (p. ex. 75 %, bien que clairement des seuils inférieurs et supérieurs à 75 % puissent également être appliqués). Lorsque le niveau de confiance dépasse le seuil, la détermination au bloc 415 est affirmative, et lorsque le niveau de confiance ne dépasse pas le seuil, la détermination au bloc 415 est négative.
[0053] Une détermination négative au bloc 415 indique que l'élément de données brutes n'indique pas une intention d'acheter un produit et que l’exécution du procédé 400 se termine. Une décision affirmative au bloc 415, cependant, indique que les données brutes indiquent une intention d'acheter un produit, et le serveur de détection passe au bloc 420. Au bloc 420, le serveur de détection 132 est configuré pour extraire les paramètres d’initiation d’achat (qui, comme cela a déjà été mentionné, définissent une ou plusieurs caractéristiques du produit) de l'élément de données brutes (plus précisément, de la version analysée générée au bloc 410, dans le présent exemple).
[0054] Les paramètres d’initiation d’achat sont extraits au bloc 420 selon un ensemble de définitions de paramètres appliqués à l'élément de données brutes par le biais de toute opération de traitement du langage naturel (NLP) appropriée (ou un ensemble de celleci). Les paramètres d’initiation d’achat comprennent l'identifiant d'adressage du client mentionné ci-dessus. D'autres paramètres d’initiation d’achat peuvent également être extraits au bloc 420. Par exemple, pour les services liés au voyage tels que les vols, l'application 262 peut inclure des définitions des lieux d'origine et de destination. D'autres exemples de paramètres d’initiation d’achat de services liés aux voyages comprennent les dates de voyage (p. ex. des dates de départ et de retour), la raison du voyage (p. ex. un voyage pour affaires ou pour motif personnel), le fournisseur privilégié (p. ex. des identifiants de compagnies aériennes) etc. Comme on le verra clairement, le procédé 400 peut être déployé pour détecter les événements d'intention d'achat associés à une large variété d'autres biens et/ou services (p. ex. électronique, réservations de restaurants, etc.) Un exemple simplifié de définition d'un lieu d'origine comprend la présence d'une chaîne de texte identifiant un emplacement dans l'élément de données brutes, précédée du mot « de ». Une large variété d'autres définitions de paramètres apparaîtra également aux hommes de métier. La détection des mots identifiant les lieux peut être réalisée, par exemple, en comparant chaque mot de l'élément de données brutes à un dictionnaire de lieux prédéfinis stocké sur le serveur de détection 132.
[0055] L'extraction des paramètres d'initiation des achats au bloc 420 peut inclure, dans certains exemples, la conversion des lieux détectés dans l'élément de données brutes en codes d'aéroport. Par exemple, en réponse à la détection d'un lieu dans l'élément de données brutes, le serveur de détection 132 peut être configuré pour obtenir (p. ex. en interne ou par l'intermédiaire d'une demande à un service de conversion externe, dont des exemples seront fournis aux hommes de métier) un code d'identification de l'aéroport correspondant à l'aéroport le plus proche du lieu. La recherche du code d'identification de l'aéroport peut comprendre la conversion du lieu en coordonnées géographiques (p. ex. latitude et longitude) avant d'identifier l'aéroport le plus proche et obtenir le code d'aéroport correspondant.
[0056] Au bloc 425, le serveur de détection 132 est configuré pour générer et envoyer un message contenant les paramètres d'initiation de l'achat au serveur intermédiaire 120 (p. ex. via un appel à ΓΑΡΙ susmentionnée exposée par le serveur intermédiaire 120) à des fins de stockage dans la file d'attente 128 et pour un traitement ultérieur. Le message envoyé au bloc 425 peut inclure, par exemple, les données d'initiation d'achat formatées selon le format de notation d'objet de script java (JavaScript Object Notation ou JSON), ou tout autre format approprié (p. ex. le langage de balisage extensible (XML) ou similaire).
[0057] Faisant référence à la FIG. 5, une exécution du procédé 400 est illustrée en rapport avec un élément de données brutes sous la forme d'un courriel 500 obtenu à partir du dispositif du client 112 et stocké dans le dépositaire 136. Comme le montre la FIG. 5, le contenu du courriel indique une intention de voyager, ainsi que les lieux (p. ex. Boston et Nice). La classification au bloc 410 du courriel 500 donne donc un niveau de confiance de 92 %, ce qui indique une probabilité élevée que le courriel 500 indique une intention d'achat. Dans d'autres exemples, il n'est pas nécessaire que les données brutes traduisent explicitement l'intention d'achat, comme dans l'exemple de la FIG. 5. C'est-àdire que le serveur de détection 132 peut être configuré pour identifier les données brutes indiquant explicitement l'intention d'achat, et peut également être configuré pour identifier l'intention d'achat implicite ou spéculative. Par exemple, et notamment dans le cas de l'achat de services de voyage, le serveur de détection 132 peut classer les données brutes comme indiquant l'intention d'achat en fonction des caractéristiques des données brutes telles qu'un certain nombre de courriels dans un fil continu, les sentiments exprimés (p. ex. frustration, confusion ou autre), etc. De telles caractéristiques peuvent indiquer que le souhait de voyager concerne une réunion en personne, même si les parties qui communiquent n'ont pas exprimé une intention de voyager. Dans certains exemples, le serveur de détection 132 peut implémenter une telle classification prédictive en tant que phase de classification secondaire au bloc 410. C'est-à-dire que le serveur de détection 132 peut produire deux niveaux de confiance au bloc 410, le premier indiquant la probabilité que l'intention d'achat explicite soit exprimée dans les données brutes, et le second indiquant la probabilité que l'intention d'achat implicite ou prévue soit exprimée. Des seuils distincts peuvent être appliqués à chaque niveau de confiance au bloc 415 (p. ex. l'intention d'achat explicite peut être requise pour atteindre un seuil inférieur à l'intention d'achat prévue).
[0058] Au bloc 420, le serveur de détection 132 est configuré pour extraire les paramètres d’initiation d’achat en vue de leur transmission dans un objet de données structuré approprié, tel qu'un objet JSON 504. Les paramètres d'initiation comprennent, dans le présent exemple, un identifiant d'adressage du client 508 (p. ex. une adresse électronique), un lieu d'origine 512, un lieu de destination 516, une date de début (c.-à-d. de départ) 520, une date de fin (c.-à-d. de retour) 524, un identifiant de compagnie aérienne privilégiée 528 et une préférence de type de vol 532 indiquant une préférence pour un vol direct. Comme on le verra désormais clairement, chaque valeur assignée à un paramètre d'initiation dans l'objet de données 504 apparaît dans le courriel 500. Certains paramètres d'initiation, tels que les dates de début et de fin 520 et 524, ne sont pas renseignés car aucune date n'est mentionnée dans le courriel 500 à extraire. Dans certains exemples, cependant, le serveur de détection 132 est configuré pour extraire ces dates à partir des données d'en-tête ou d'autres métadonnées associées au message. Par exemple, le serveur de détection 132 peut être configuré pour extraire une date de début qui équivaut à la date d'envoi du courriel 500, incrémentée d'un intervalle prédéterminé (p. ex. une semaine).
[0059] Ainsi, en ce qui concerne la FIG. 3, au bloc 305, le serveur intermédiaire 120 est configuré pour recevoir, par exemple, l'objet de données 504 du serveur de détection 132 et stocker l’objet de données 504 dans la file d'attente 128. Le serveur intermédiaire 120 peut être configuré, en réponse à la réception des données d'initiation d'achat mais avant de stocker les données d'initiation d’achat dans la file d'attente 128, pour valider les données d'initiation d'achat par rapport à un ou plusieurs critères de validation. Par exemple, les données d'initiation d'achat qui ne comprennent pas d'identifiant d adressage du client peuvent être rejetées (p. ex. en retournant une erreur à la source des données d'initiation d'achat) et supprimées plutôt que stockées dans la file d'attente 128.
[0060] D'autres mécanismes permettant d'obtenir des données d'initiation d’achat en vue de leur stockage dans la file d'attente 128 sont également envisagés, en plus ou à la place de la détection automatisée abordée plus haut dans le cadre des FIG. 4 et 5. Par exemple, le dispositif du client 112 peut être configuré pour demander la génération et la transmission des données d'initiation d'achat au serveur intermédiaire 120. Plus précisément, le dispositif du client 112 peut être configuré pour demander une page Web hébergée par un ou plusieurs des serveurs de réservation 104, le serveur de détection 132 ou le serveur intermédiaire 120 lui-même, et contenant une interface de recherche de produit.
[0061] Concernant la FIG. 6A, un exemple d'interface de recherche 600 comprend une pluralité d'invites d'entrées sélectionnables (p. ex. via n'importe quel ensemble d entrées approprié du dispositif du client 112, tel qu'une souris, un écran tactile, un clavier ou similaire), chacune correspondant à un paramètre d'initiation d'achat. Dans l'exemple illustré, l'interface 600 comprend des invites correspondant à un ensemble de sept entrées de recherche. Les invites sont généralement appelés « champs » dans la discussion ci-dessous, bien qu'il soit entendu qu'une grande variété de formats (p. ex. champs de texte, menus déroulants et autres) peut être utilisée pour recueillir des données de recherche. En particulier, un premier champ de recherche 604 comprend une paire de boutons radio sélectionnables (généralement de manière mutuellement exclusive, de sorte que seul un des boutons peut être marqué comme sélectionné à la fois) pour indiquer si un vol retour ou un vol aller simple doit être demandé. Les deuxième et troisième champs de recherche 608 et 612 sont des champs dans lesquels un lieu d'origine et un lieu de destination sont respectivement fournis. Les quatrième et cinquième champs 616 et 620 sont des champs dans lesquels les dates de départ et de retour (le cas échéant, en fonction de la sélection associée au champ 604) sont respectivement fournies. Un sixième champ 624 reçoit des données d'entrée spécifiant si la recherche doit être limitée aux vols directs uniquement (« Oui ») ou si la recherche doit également renvoyer des vols avec un ou plusieurs arrêts (« Non »). Comme le verront les hommes de métier, divers autres champs de recherche peuvent également être fournis. Par exemple, l'interface de recherche peut inclure d'autres champs pour un ou plusieurs d'une indication quant à restreindre ou non la recherche aux vols sans escale (c'est-à-dire directs), une préférence de classe, une préférence de compagnie aérienne, etc.
[0062] L'interface 600 comprend un élément de recherche sélectionnable 632 pour soumettre une demande de recherche au serveur 104 contenant les entrées fournies dans les champs 600-628. Comme on le verra désormais clairement, la sélection de l'élément 632 déclenche généralement une session de transaction limitée dans le temps avec le serveur de réservation 104. En outre, l’interface 600 comprend un élément sélectionnable 636. La sélection de l'élément 636, plutôt que d'initier la session de transaction mentionnée ci-dessus, demande au serveur hébergeant l'interface 600 de générer et de transmettre les données d'initiation d'achat au serveur intermédiaire 120 (p. ex. via un appel API, comme mentionné précédemment) pour un stockage dans la file d'attente 128. Lorsque, dans l'interface 600, il n'y a pas d'invite pour un identifiant d'adressage de client tel qu'une adresse électronique, la sélection de l'élément 636 peut générer une telle invite. En d'autres termes, la fourniture de l'élément 636 dans l'interface 600 adapte l'interface 600 pour initier soit une session de transaction conventionnelle sur le Web, soit un processus de transaction persistante conservé par le serveur intermédiaire 120.
[0063] Concernant la FIG. 3, au bloc 310, le serveur intermédiaire 120 est configuré pour récupérer un ensemble de données d'initiation d'achat de la file d’attente 128 et pour déterminer si les données d'initiation d'achat sont complètes. La détermination au bloc 310 consiste à déterminer si un sous-ensemble prédéterminé de l'ensemble prédéfini de paramètres définissant les produits dans les données de réservation du dépositaire 108 est présent dans les données d'initiation d'achat. Le sous-ensemble prédéterminé, en d'autres termes, est le sous-ensemble minimal de paramètres avec lequel un processus de transaction peut continuer. Le sous-ensemble spécifique de paramètres n'est pas spécifiquement limité et varie au moins selon le type de produit(s) représenté(s) dans le dépositaire 108. Dans le présent exemple, où les produits sont des vols, le sousensemble de paramètres requis pour une détermination positive au bloc 310 comprend les lieux d'origine et de destination, une date de départ et soit une date de retour, soit une indication qu'un vol aller simple est recherché. D'autres exemples de sous-ensembles de paramètres requis apparaîtront également aux hommes de métier.
[0064] Poursuivant avec l'exemple de données d'initiation illustré dans la FIG. 6A et en supposant que la date de retour est un paramètre nécessaire pour procéder à une transaction, la détermination au bloc 310 est négative. Le serveur intermédiaire 120 passe donc au bloc 313, où le serveur intermédiaire 120 est configuré pour générer et envoyer un message interactif demandant des données d'initiation d'achat supplémentaires. Les messages interactifs, tels que mentionnés ici, sont des messages contenant des éléments qui peuvent être sélectionnés au niveau du dispositif du client 112, et qui comprennent des données amenant le dispositif du client 112 à transmettre des instructions au serveur intermédiaire 120 lorsque les éléments sont sélectionnés. Les messages interactifs peuvent être, par exemple, des messages Microsoft™, mais d'autres formes de messages interactifs peuvent aussi être envoyés à des hommes de métier. En général, les éléments sélectionnables des messages interactifs servent à demander à l'opérateur du dispositif du client 112 d'autres données associées à une transaction en attente et à relayer les données supplémentaires au serveur intermédiaire 120 (p. ex. via le serveur de messagerie 140, dans le présent exemple). Lorsqu’ils sont implémentés à l’aide de la technologie de messages actionnables indiquée ci-dessus, les éléments sélectionnâmes sont également appelés « cartes adaptatives, « cartes de message » ou simplement « cartes ».
[0065] Au bloc 313, le serveur intermédiaire 120 est configuré pour générer (via l'application du générateur 216) et transmettre un message interactif basé sur les données d'initiation d'achat dans le dépositaire 124. En particulier, le serveur intermédiaire 120 est configuré pour générer un message adressé en fonction de l'identifiant d'adressage du client mentionné ci-dessus (p. ex. l'adresse de courriel « bob@xyz.com »). De plus, le message généré au bloc 313 comprend un élément sélectionnable pour chaque paramètre d'initiation d'achat requis pour compléter les données d'initiation d'achat.
[0066] Le tableau 1 ci-dessous illustre un exemple d'enregistrement de transaction stocké dans le dépositaire 124. Comme on le verra clairement dans la discussion cidessous, chaque enregistrement de transaction dans le dépositaire 124 correspond à une transaction initiée en lien avec un identifiant d'adressage du client particulier, et peut être complétée par des données supplémentaires en fonction de l'état de la transaction. Le tableau 1 illustre l'enregistrement des transactions après l’exécution du bloc 305. L'enregistrement ne contient donc que les données relatives à l’initiation d’achat, qui (comme indiqué ci-dessus) ne comporte pas de date de retour.
Tableau 1 : Enregistrement de transaction (Initiation)
| ID de transaction | 6536758345 | |
| Utilisateur | Adresse de courriel | bob@xyz.com |
| Recherche | De | NCE |
| À | BOS | |
| Départ | 21/11/2018 | |
| Retour | ||
| Direct | Exact |
[0067] Comme on l'a vu plus haut, en plus de l'identifiant d'adressage du client et des paramètres d'initiation d’achat, l'enregistrement de la transaction comprend un identifiant de transaction, qui est généralement généré par le serveur intermédiaire 120. Dans d'autres exemples, l'identifiant de transaction peut être généré en externe et reçu avec les données d'initiation des achats au bloc 305.
[0068] Au bloc 313, le serveur intermédiaire 120 est configuré pour générer un message interactif contenant un élément sélectionnable demandant une date de retour. Le contenu du message interactif peut être défini dans le dépositaire 124 lui-même ou dans toute autre structure de données appropriée sur le serveur intermédiaire 120. C'està-dire que le serveur intermédiaire stocke les caractéristiques restituables pour les éléments sélectionnâmes utilisés dans les messages interactifs (c'est-à-dire définissant comment les éléments sélectionnâmes sont présentés sur un affichage du dispositif du client 112), y compris les noms de champs et le texte d'accompagnement (p. ex. les instructions à l'intention de l’utilisateur sur l'interaction requise avec l'élément sélectionnable), les données de position et les graphiques associés à l’élément (p. ex. les couleurs, les images à afficher avec l'élément, etc.) Le dépositaire 124, ou une autre structure de données appropriée sur le serveur intermédiaire 120, spécifie également quels paramètres correspondent à quels éléments sélectionnâmes, ainsi que des indications sur les paramètres s’avérant obligatoires (c'est-à-dire quels paramètres sont membres du sous-ensemble susmentionné). En outre, chaque élément sélectionnable comprend également des instructions lisibles par ordinateur, amenant le dispositif à rendre l’élément sélectionnable (p. ex. le dispositif du client 112) pour lancer une ou plusieurs instructions, telles que les appels API, vers le serveur intermédiaire 120.
[0069] Concernant la FIG. 6B, un exemple de message interactif sous la forme d'un courriel 650 est illustré, tel qu'affiché par le dispositif du client 112. Comme le montre la figure FIG. 6B, le courriel 650 est adressé en fonction de l'identifiant d'adressage du client dans l'enregistrement de la transaction, et peut également inclure une section résumant les données d'initiation d'achat disponibles dans l'enregistrement de transaction. De plus, pour chaque paramètre d’initiation d'achat obligatoire (dans le présent exemple, simplement la date de retour), le message 650 comprend un élément sélectionnable 658 (p. ex. un champ texte, un calendrier déroulant pour la sélection d'une donnée, ou autre), éventuellement accompagné d'une description 660. L'élément sélectionnable 658 accepte les données d'entrée au niveau du dispositif du client 112, dans le présent exemple représentant une date de retour. Le courriel 650 peut inclure (p. ex. en tant que paramètre définissant l'élément 658, ou de toute autre manière appropriée) des données définissant les critères de validation à respecter avant que la sélection de l'élément 662 ne soit acceptée. Par exemple, l'élément 662 peut devenir disponible pour la sélection uniquement lorsqu'une date correctement formatée a été saisie à l'élément 658.
[0070] De plus, le courriel 650 comprend un élément sélectionnable 662 sous la forme d’un bouton « submit » (soumettre), dont la sélection amène le dispositif du client 112 à transmettre une instruction au serveur intermédiaire 120. Dans le présent exemple, la sélection du bouton 662 amène le dispositif du client 112 à transmettre (p.ex. via le même appel API que celui utilisé par le serveur de détection 132 pour transmettre les données d'initiation d'achat au bloc 425) un message contenant au moins une date de retour saisie dans le champ défini par l'élément 658. Le message peut également contenir tous les paramètres d'initiation d'achat représentés dans le courriel 650, et inclut généralement l'identifiant de transaction.
[0071] Le courriel 650, dans l'exemple illustré, comprend également un autre élément sélectionnable 666 sous la forme d'un bouton indiquant que l'opérateur du dispositif du client 112 n'a pas l'intention d'initier une transaction. Lorsque le message 650 se rapporte à un enregistrement de transaction initié par la réception de données du serveur de détection 132, la sélection de l'élément 666 indique que la détection d'un événement d'intention d'achat par le serveur de détection 132 peut s’être avérée incorrecte. En réponse à la sélection de l'élément 666, le dispositif du client 112 est configuré pour transmettre un message au serveur intermédiaire 120 pour effacer l'enregistrement de transaction. Le serveur intermédiaire peut également, après réception d'une instruction d’effacement de la transaction, transmettre au serveur de détection 132 un message contenant l'enregistrement de transaction et une indication selon laquelle l'enregistrement de transaction correspond à une fausse détection d'un événement d’initiation d'achat. Comme on le verra désormais clairement, le serveur de détection 132 peut collecter ces enregistrements de détection erronés pour la formation périodique ultérieure du modèle de classification employé au bloc 410. Dans certains exemples, le serveur intermédiaire 120 peut être configuré pour transmettre un message interactif au bloc 313 même lorsque les données d'initiation d'achat sont complètes, pour demander au dispositif du client 112 la confirmation selon laquelle l'utilisateur souhaite poursuivre la transaction.
[0072] Après la saisie d'une date de retour à l'élément 658 et la sélection de l'élément de soumission 662 au niveau du dispositif du client 112, le dispositif du client 112 renvoie les paramètres d'initiation d'achat mis à jour au serveur intermédiaire 120, comme indiqué ci-dessus. Ainsi, à la suite d'une autre exécution du bloc 305, l'enregistrement de la transaction est mis à jour comme indiqué ci-dessous dans le tableau 2.
Tableau 2 : Enregistrement de la transaction (Retour d’information)
| ID de transaction | 6536758345 | |
| Utilisateur | Adresse de courriel | bob@xyz.com |
| Recherche | De | NCE |
| À | BOS | |
| Départ | 21/11/2018 | |
| Retour | 25/11/2018 | |
| Direct | Exact |
[0073] Dans une exécution supplémentaire du bloc 310, la détermination est affirmative, car la date de retour a été remplie. Le serveur intermédiaire passe ainsi au bloc 315, où le serveur intermédiaire 120 est configuré pour transmettre au serveur de réservation 104 une demande de définitions de produits correspondant aux données d'initiation d'achat. La demande transmise au bloc 315, en d'autres termes, est une recherche d'un ou plusieurs produits définis dans le dépositaire 108 correspondant aux paramètres d'initiation d'achat stockés dans l'enregistrement de transaction du dépositaire 124. Le formatage et le mécanisme de transmission (p. ex. protocoles de transmission et autres) sont choisis en fonction des capacités et des exigences du serveur de réservation 104 ; une variété de formats appropriés pour la demande au bloc 315 sera présentée aux hommes de métier. En réponse à la demande, le serveur intermédiaire 120 est configuré pour recevoir une ou plusieurs définitions de produit du serveur de réservation 104, chacune définissant un produit (p. ex. un vol dans l'exemple présent) correspondant aux paramètres d'initiation d'achat. Les définitions des produits comprennent les paramètres de définition des produits, y compris ceux qui figurent au moins dans les données d’initiation d’achat. Les définitions de produits peuvent inclure des paramètres supplémentaires, tels que (dans l'exemple des produits de vol) les identifiants de compagnies aériennes, les heures de départ et de retour des vols, les prix, etc.
[0074] En réponse à la réception des définitions de produits au bloc 315, le serveur intermédiaire 120 est configuré pour stocker les définitions de produits, que l'on peut également appeler offres, dans le dépositaire 124. Notamment, le serveur intermédiaire 120 est configuré pour mettre à jour l'enregistrement de transaction avec les définitions de produit. Le tableau 3, ci-dessous, illustre une version mise à jour de l'enregistrement de transaction des tableaux 1 et 2, avec deux définitions de produits qui y sont stockées.
Tableau 3 : Enregistrement de transaction mis à jour (Définitions de produit)
| ID de transaction | 6536758345 | |
| Utilisateur | Adresse de courriel | bob@xyz.com |
| Recherche | De | NCE |
| À | BOS | |
| Départ | 21/11/2018 | |
| Retour | 25/11/2018 | |
| Direct | Exact | |
| Offre | ID de l’offre | BFS86 |
| Description de l'offre | ||
| Offre | ID de l’offre | GD875 |
| Description de l'offre | ... |
[0075] Comme indiqué ci-dessus, chaque définition de produit (c'est-à-dire les données stockées dans un bloc « Offre » de l'enregistrement de transaction) comprend un identifiant de définition de produit (ou identifiant d'offre), qui peut être attribué au serveur intermédiaire 120 ou reçu du serveur de réservation 104. De plus, chaque définition de produit comprend une description de produit, qui est représentée comme un seul fichier par souci de simplicité ci-dessus, mais peut inclure n'importe quel nombre approprié de champs, qui peuvent être structurés dans un format similaire aux données d'initiation d'achat (c.-à-d. le bloc « Recherche » de l’enregistrement de transaction). Bien que deux définitions de produits soient illustrées ci-dessus, le serveur intermédiaire 120 peut recevoir un plus ou moins grand nombre de définitions de produits au bloc 315 dans d'autres exemples. Dans certaines implémentations, le serveur intermédiaire 120 peut inclure dans la demande au serveur de réservation un nombre maximum de définitions de produits, par exemple pour renvoyer les cinq (ou tout autre nombre approprié) qui correspondent le mieux aux données d'initiation d'achat.
[0076] Au bloc 320, le serveur intermédiaire 120 est configuré pour générer et envoyer un message interactif (p. ex. un courriel pouvant faire l'objet d'une action, comme mentionné ci-dessus) contenant des données de définition de produit sélectionnables correspondant aux définitions de produit reçues au bloc 315. Les données de définition de produit sélectionnables sont encapsulées dans, par exemple, un élément sélectionnable pour chaque définition de produit, et comprennent à la fois des données pouvant être rendues (p. ex. une partie ou la totalité de la description de l'offre) et des données non rendues (p. ex. l'identifiant de transaction, les identifiants d'offre et autres) qui sont incluses dans le message mais qui ne nécessitent pas d'être affichées sur le dispositif du client 112.
[0077] Concernant la FIG. 7A, un exemple de message 700 généré par le serveur intermédiaire 120 et affiché sur le dispositif du client 112 est affiché. Comme pour le message 650 abordé ci-dessus, le message 700 est fourni en fonction de l'identifiant d'adressage du client dans l'enregistrement de transaction (dans ce cas, l'adresse électronique bob@xyz.com). Le message 700 comprend les premier et deuxième éléments de définition de produit 704-1 et 704-2, chacun contenant au moins un sousensemble des paramètres de définition de produit stockés dans l'enregistrement de transaction. Le message 700 comprend également, en association avec chaque élément de définition de produit 704, un élément sélectionnable 708-1, 708-2 qui peut être sélectionné au niveau du dispositif du client 112 pour générer et transmettre une sélection de produit au serveur intermédiaire 120 (p. ex. via le serveur de messagerie 140). Le format du message 700 tel qu'illustré dans la figure FIG. 7A est à titre d'illustration uniquement ; comme le verront les hommes de métier, une grande variété d'autres formats peut être utilisée pour fournir les éléments 704 et 708. Par exemple, les vols aller et retour peuvent être présentés dans des éléments séparés.
[0078] Le message 700 peut également inclure, comme indiqué dans la FIG. 7A, un élément de redirection sélectionnable 712. La sélection de l'élément 712 amène le dispositif du client 112 à transmettre une demande de redirection pour poursuivre la transaction via une session de transaction basée sur le Web, par exemple, hébergée par le serveur de réservation 104 lui-même. La demande de redirection peut être transmise directement au serveur de réservation 104. Dans de tels exemples, le message 700 comprend un localisateur de ressources uniforme (URL) ou un autre identifiant de réseau correspondant à l'élément 712 et incluant des paramètres de transmission au serveur de réservation 104 pour récupérer une page Web (comme celle illustrée dans la FIG. 6A) pour affichage sur le dispositif du client 112 qui fournit les définitions de produit représentées par les éléments 704. Dans d'autres exemples, la demande de redirection peut être transmise au serveur intermédiaire 120, qui en réponse peut récupérer (p. ex. en demandant au serveur de réservation 104) ou générer une URL ou un autre identifiant de réseau et renvoyer l'identifiant de réseau au dispositif du client 112 dans une commande de redirection, amenant ainsi le dispositif du client 112 à transmettre une demande au serveur de réservation 104 contenant l'identifiant de réseau.
[0079] Concernant la FIG. 3, au bloc 325, le serveur intermédiaire 120 est configuré pour attendre une réponse au message envoyé au bloc 320. Comme on le verra désormais clairement, la réponse n'est généralement pas un message de retour du même type que celui envoyé au bloc 320 (p. ex. un courriel, dans le présent exemple). Au lieu de cela, la réponse peut être un appel API ou une autre instruction générée par le dispositif du client 112 ou le serveur de messagerie 140 selon les données contenues dans le message envoyé au bloc 320. Comme on le verra aussi clairement, il n'est pas nécessaire que la réponse reçue au bloc 325 suive de près la transmission du message au bloc 320. C'est-à-dire que la transmission au bloc 320 et la réponse reçue au bloc 325 peuvent être asynchrones.
[0080] Lorsque la réponse reçue au bloc 325 indique une mise à jour des données d'initiation d’achat, le serveur intermédiaire revient au bloc 305 (comme indiqué ci-dessus en relation avec le bloc 313). Dans certains exemples, le message envoyé au bloc 320 peut permettre la sélection de paramètres d’initiation d'achat révisés au niveau du dispositif du client 112. Dans d'autres exemples, cependant, cette fonctionnalité peut être omise et, par conséquent, le retour au bloc 305 peut également être omis.
[0081] Lorsque la réponse reçue au bloc 325 comprend une sélection de produits (p. ex. un appel API pour déclencher l'achat d'une des définitions de produits incluses dans le message du bloc 320), le serveur intermédiaire 120 passe au bloc 330. Au bloc 330, le serveur intermédiaire 120 est configuré pour vérifier si le produit correspondant à la sélection de produits reste disponible à l'achat. Comme indiqué cidessus, la livraison des définitions de produits au dispositif du client 112 et la réception des sélections de produits peuvent être asynchrones, et un délai suffisant peut donc s'être écoulé entre les blocs 320 et 325 pour que l’inventaire représenté dans le dépositaire 108 ait changé. Ainsi, au bloc 330, le serveur intermédiaire 120 est configuré pour transmettre une demande au serveur de réservation 104 afin de déterminer si le produit sélectionné dans la réponse au bloc 325 est disponible à l'achat. Différentes formes de demande peuvent être utilisées au bloc 330. Par exemple, lorsque les identifiants d'offre indiqués dans le tableau 2 sont reçus du serveur de réservation 104 au bloc 315, la demande peut inclure l'identifiant d'offre correspondant à la sélection reçue au bloc 325 (par exemple, l'ID d'offre « BFS86 » si la réponse reçue au bloc 325 indiquait une sélection de l'élément 708-1 au niveau du dispositif du client 112). Lorsque l'identifiant d'offre est attribué au serveur intermédiaire 120 lui-même, et n'est donc pas stocké dans le dépositaire 108, la demande au bloc 330 peut inclure une demande de recherche similaire à celle envoyée au bloc 315, à la suite de quoi le serveur intermédiaire 120 est configuré pour recevoir les définitions de produits et déterminer si l'une des définitions de produits correspond à l'offre sélectionnée.
[0082] Lorsque la détermination au bloc 330 est négative, indiquant que la définition de produit sélectionnée ne peut pas être achetée (p. ex. parce que le produit correspondant n'est plus disponible), le serveur intermédiaire 120 revient au bloc 315 pour obtenir d’autres définitions de produit, et l’exécution des blocs 320 et 325 est répétée. Lorsque la détermination au bloc 330 est affirmative, le serveur intermédiaire 120 passe au bloc 335.
[0083] Au bloc 335, le serveur intermédiaire 120 est configuré pour déterminer si l'approbation pour initier un achat du produit sélectionné a été obtenue. Dans certains exemples, qui seront examinés plus en détail ci-dessous, l'approbation d'une partie autre que celle correspondant à l'identifiant d'adressage du client peut être requise avant de finaliser toute transaction (c'est-à-dire avant d'envoyer une instruction d'achat au serveur de réservation 104). Dans d'autres exemples, le bloc 335 peut être omis (ce qui signifie en fait que la détermination au bloc 335 est toujours affirmative, car aucune approbation n'est requise). De plus, dans certains exemples, l'approbation peut être requise pour certains identifiants d’adressage de client mais pas pour d'autres, pour certains types d'achat (p. ex. certains biens ou services peuvent nécessiter une approbation, alors que d'autres peuvent être achetés sans approbation) mais pas pour d'autres, ou des combinaisons de ces éléments. Le serveur intermédiaire 120 peut donc être configuré pour transmettre une demande au serveur d’entreprise 148 avec l'identifiant d'adressage du client et recevoir en réponse une indication (p. ex. stockée dans la base de données du profil 152) sur la nécessité ou non d'une approbation avant de procéder à l'exécution du procédé 300. L’implémentation d'un processus d'approbation par le serveur intermédiaire 120 sera abordé ci-dessous en rapport avec la FIG. 8.
[0084] Lorsque la détermination au bloc 335 est affirmative (ou lorsque le bloc 335 est simplement omis), le serveur intermédiaire 120 est configuré pour passer au bloc 340 et générer et envoyer une instruction d'achat au serveur de réservation 104, amenant ainsi le serveur de réservation 104 à mettre à jour les données de réservation dans le dépositaire 108 pour refléter un achat du produit sélectionné au bloc 325, correspondant à l'identifiant d'adressage du client. Le contenu et le formatage de l'instruction d'achat envoyée au bloc 340 sont sélectionnés en fonction de la configuration du serveur de réservation 104. Le serveur intermédiaire 120 peut être configuré pour récupérer les données de l'une ou des deux bases de profil 152 et de données des dépenses 156, à travers une demande au serveur d'entreprise 148 de générer l'instruction d'achat. Par exemple, les données extraites du serveur de l'entreprise 148 peuvent inclure un nom légal complet associé à l'identifiant d’adressage du client, des données relatives aux documents de voyage (p. ex. un numéro de passeport), des informations relatives au paiement (p. ex. un numéro de carte de crédit) et ainsi de suite.
[0085] Après la transmission de l'instruction d'achat au bloc 340, le serveur intermédiaire 120 est configuré pour recevoir les données de confirmation du serveur de réservation 104. Les données de confirmation peuvent inclure, par exemple, un solde payé, une description du produit acheté (qui peut être identique à la description dans la définition du produit abordée précédemment) et un identifiant de confirmation. Le serveur intermédiaire 120 est configuré, après réception des données de confirmation, pour stocker les données de confirmation dans le dépositaire 124 et passer ensuite au bloc 345. Le tableau 4, ci-dessous, illustre l’enregistrement de la transaction après la réalisation d'une transaction pour acheter le produit correspondant à l'élément 704-1 illustré dans la FIG. 7A.
Tableau 4 : Enregistrement de transaction mis à jour (confirmation)
| ID de transaction | 6536758345 | |
| Utilisateur | Adresse de courriel | bob@xyz.com |
| Recherche | De | NCE |
| À | BOS | |
| Départ | 21/11/2018 | |
| Retour | 25/11/2018 | |
| Direct | Exact | |
| Confirmation | ID de confirmation | BFS86 |
| Description de la réservation | . . . |
[0086] Comme illustré ci-dessus, les définitions de produit précédemment stockées ont été supprimées de l'enregistrement de transaction et remplacées par un bloc de confirmation contenant un identifiant de confirmation (p. ex. une référence de réservation générée par le serveur de réservation 104) et un ou plusieurs paramètres définissant le produit acheté (la « description de la réservation »). Dans d'autres exemples, les définitions de produits (c'est-à-dire les blocs d’« offre » abordés plus haut) sont conservées dans l’enregistrement de transaction, ce qui permet d'effectuer des réservations ultérieures sans initier un nouveau processus de transaction au bloc 305 (p. ex. en cas d'annulation de la présente réservation).
[0087] Au bloc 345, le serveur intermédiaire 120 est configuré pour générer et transmettre un autre message interactif au dispositif du client 112, en fonction de l'identifiant d'adressage du client, contenant des données de confirmation telles que la définition du produit et l'identifiant de confirmation mentionné ci-dessus. Faisant référence à la FIG. 7B, un exemple de message de confirmation 750 est affiché, sous la forme d'un autre courriel pouvant faire l'objet d'une action. Le message 750 comprend un élément de confirmation 754 contenant les données de définition de produit et l'identifiant de confirmation illustrés dans le tableau 4.
[0088] Le message de confirmation envoyé au bloc 345 peut également inclure un ou plusieurs éléments sélectionnables configurés, lors de la sélection sur le dispositif du client 112, pour initier d autres mises à jour des données de réservation dans le dépositaire 108, reflétant les modifications apportées à la transaction terminée. Comme le montre la figure FIG. 7B, par exemple, le message 750 comprend les éléments sélectionnables 758, 762 et 766 configurés pour envoyer des instructions au serveur intermédiaire 120 pour, respectivement, annuler la transaction, initier un processus d'enregistrement et rafraîchir les données de définition de produit indiquées dans I élément 754. La sélection de l'élément d'annulation 758 sur le dispositif du client 112 amène le dispositif du client 112 à transmettre une commande d'annulation (p. ex. un appel API) au serveur intermédiaire 120, qui est ensuite configuré pour envoyer une instruction d'annulation au serveur de réservation 104, contenant au moins l'identifiant de confirmation indiqué ci-dessus. L'instruction d'annulation amène le serveur de réservation 104 à mettre à jour le dépositaire 108 pour supprimer une indication selon laquelle le produit concerné a été acheté par l'utilisateur associé à l'identifiant d'adressage du client. L'instruction d'enregistrement peut amener le serveur intermédiaire 120 à rediriger le dispositif du client 112 vers une URL d'enregistrement hébergée par le serveur de réservation 104, tandis que l’instruction de rafraîchissement peut amener le serveur intermédiaire 120 à récupérer une définition de produit mise à jour du serveur de réservation 104 (p. ex. reflétant tout changement d'horaire pour le vol indiqué dans la FIG. 7B) et générer un message de confirmation supplémentaire contenant la définition du produit mise à jour.
[0089] Plus généralement, diverses modifications peuvent être apportées à l'opération après confirmation, comme l'illustre la ligne en pointillés repassant du bloc 345 au bloc 340. D'autres exemples d'actions qui peuvent être effectuées dans le cadre d'une transaction terminée comprennent l'initiation d'une transaction supplémentaire pour un produit connexe (p. ex. une réservation d'hôtel ou un autre bien et/ou service auxiliaire), via la génération de données d'initiation d'achat supplémentaires (initiation d'une autre exécution du procédé 300).
[0090] Faisant maintenant référence à la FIG. 8, un procédé 800 d’obtention des données d'approbation pour les transactions en attente est illustré. L’exécution du procédé 800 sera décrite en rapport avec son exécution au sein du système 100, et en particulier par le serveur intermédiaire 120 pour obtenir des approbations pour les transactions initiées via l’exécution du procédé 300. Dans d'autres exemples, cependant, le procédé 800 peut être déployé indépendamment du procédé 300, afin d'obtenir des approbations pour des transactions initiées via d'autres mécanismes.
[0091] Au bloc 805, le serveur intermédiaire 120 est configuré pour déterminer s'il faut générer des messages de demande d'approbation, par exemple associés à des transactions en attente ayant atteint le bloc 335 du procédé 300. La détermination au bloc 805 peut être basée, par exemple, sur un planning prédéterminé. Par exemple, le serveur intermédiaire 120 peut être configuré pour exécuter le procédé 800 une fois par jour, à un moment prédéterminé de la journée. Dans d'autres exemples, un dispositif informatique distinct peut être configuré pour demander périodiquement au serveur intermédiaire 120 (p. ex. via le réseau 116) d'exécuter le procédé 800. Dans de tels exemples, la détermination au bloc 805 est simplement une détermination de réception ou non d’une instruction pour obtenir des approbations.
[0092] Lorsque la détermination au bloc 805 est négative, le serveur intermédiaire 120 répète la détermination. Comme on le verra clairement, un ou plusieurs cas du procédé 300 peuvent être exécutés en parallèle avec le procédé 800, et donc, en attendant une décision positive au bloc 805, le serveur intermédiaire 120 peut générer et mettre à jour des enregistrements de transaction comme abordé ci-dessus.
[0093] Lorsque la détermination au bloc 805 est affirmative, le serveur intermédiaire 120 passe au bloc 810, pour récupérer les transactions en attente pour lesquelles des sélections de produits ont été effectuées (p. ex. par des dispositifs de client tels que le dispositif du client 112) et pour lesquelles l'approbation est en attente (c'est-à-dire pour lesquelles une détermination positive au bloc 335 n’a pas encore été effectuée). Le tableau 5 illustre l'enregistrement de transaction tel qu'indiqué dans le tableau 3, avec un champ d'état supplémentaire associé à l'identifiant d'offre « BFS86 » inséré dans l'enregistrement de transaction à la suite d'une sélection de produits reçue au bloc 325.
Tableau 5 : Enregistrement de transaction mis à jour (approbation en attente)
| ID de transaction | 6536758345 | |
| Utilisateur | Adresse de courriel | bob@xyz.com |
| Recherche | De | NCE |
| À | BOS | |
| Départ | 21/11/2018 | |
| Retour | 25/11/2018 | |
| Direct | Exact | |
| Offre | ID de l’offre | BFS86 |
| Description de l'offre | . - - | |
| Statut | Approbation en attente | |
| Offre | ID de l’offre | GD875 |
| Description de l'offre | · |
[0094] En particulier, tel que constaté plus haut, la définition du produit sélectionné comprend un indicateur de statut indiquant que l'approbation n'a pas encore été obtenue pour continuer la transaction (c'est-à-dire pour passer au 340). Au bloc 810, le serveur intermédiaire 120 est configuré pour récupérer chaque enregistrement de transaction ayant un indicateur d’état indiquant que l'approbation est en attente. Comme on le verra désormais clairement, une pluralité d'enregistrements de transactions peuvent être stockés dans le dépositaire 124 à tout moment, et une pluralité de ces enregistrements de transactions peuvent avoir un statut d'approbation en attente.
[0095] Au bloc 810, le serveur intermédiaire 120 est également configuré pour récupérer les identifiants des approbateurs (p. ex. les identifiants d'adressage des approbateurs, comme les adresses électroniques) correspondant à chaque transaction en attente identifiée dans le dépositaire 124. La récupération des identifiants d'approbateur peut inclure, par exemple, la transmission d'une demande au serveur de l'entreprise 148 contenant les identifiants d'adressage du client associés à chaque transaction en attente. Le serveur d'entreprise 148 peut contenir, par exemple dans la base de données des dépenses 156, des identifiants d'approbateur correspondant à chaque identifiant d'adressage du client.
[0096] Au bloc 815, le serveur intermédiaire 120 est configuré, pour chaque identifiant d'approbateur obtenu au bloc 810, afin d'agréger les transactions en attente récupérées au bloc 810 pour lesquelles l'approbation de l'identifiant d'approbateur est requise. Par exemple, un identifiant d'approbateur donné (p. ex. « sara@xyz.com ») peut être reçu du serveur d'entreprise 148 en tant qu'identifiant d'approbateur correspondant à la transaction en attente indiquée dans le tableau 5, ainsi qu'une autre transaction en attente associée à l'identifiant d'adressage du client « alice@xyz.com ». Ainsi, au bloc 815, le serveur intermédiaire 120 est configuré pour générer un message interactif agrégé adressé à l'approbateur (dans l'exemple illustré, sara@xyz.com). Le message agrégé comprend des éléments d'approbation sélectionnables pour chaque transaction en attente correspondant à l'identifiant d’approbateur.
[0097] Faisant référence à la FIG. 9, un exemple de message de demande d'approbation agrégée 900 est indiqué, sous la forme d'un courriel pouvant faire l'objet d'une action. Le message 900 comprend les éléments de définition de produit 904-1,9042 pour chacune des transactions en attente identifiées au bloc 810, y compris au moins un sous-ensemble de données de définition de produit associé à ces transactions en attente. De plus, le message 900 comprend les éléments d’approbation sélectionnables 908-1, 908-2 et les éléments de rejet sélectionnables 912-1, 912-2. La sélection d'un élément d'approbation 908 amène un dispositif du client associé à l'identifiant de l'approbateur à transmettre une instruction d'approbation contenant l'identifiant de transaction pertinent au serveur intermédiaire 120 (p. ex. sous la forme d'un appel API). En réponse à la réception de l'instruction d'approbation au bloc 820, le serveur intermédiaire 120 est configuré pour mettre à jour l'enregistrement de transaction correspondant afin d'indiquer un statut approuvé, et pour ensuite passer au bloc 340 comme abordé ci-dessus.
[0098] En réponse à la réception d'une instruction de rejet au bloc 820, le serveur intermédiaire peut être configuré pour supprimer l'enregistrement de transaction ou pour mettre à jour l'enregistrement de transaction afin d'indiquer un statut en tant que rejeté. Le serveur intermédiaire 120 peut également être configuré, au bloc 825, pour générer et transmettre un message de rejet à l'identifiant d'adressage du client associé à la transaction rejetée, informant le destinataire que l'achat demandé a été rejeté. Le message de rejet peut également inclure un commentaire fourni dans la réponse de l'approbateur reçu au bloc 820 (p. ex. dans un champ interactif du message 900, non affiché). Comme on le verra désormais clairement, suite à un rejet l'exécution du procédé
300 pour la transaction rejetée ne passe pas au bloc 340, et aucune mise à jour des données de réservation n’est donc effectuée dans le dépositaire 108.
[0099] Des variations par rapport aux systèmes et procédés ci-dessus sont envisagées. Dans certains exemples, la génération et la transmission de messages interactifs, telles qu’abordées plus haut, peuvent être effectuées en mettant à jour les messages transmis précédemment plutôt que de générer de nouveaux messages. Par exemple, après une détermination négative au bloc 330 et un retour aux blocs 315 et 320, le serveur intermédiaire 120 peut être configuré pour transmettre une instruction au serveur de messagerie 140 pour mettre à jour le contenu du message envoyé à cas précédent du bloc 320, par exemple pour remplacer les définitions de produit précédentes par les définitions de produit actuelles. À cette fin, les messages envoyés au bloc 320 peuvent se voir attribuer des identifiants de message conservés dans l'enregistrement de transaction et au serveur de messagerie 140, et permettre au serveur intermédiaire 120 d ordonner au serveur de messagerie 140 de récupérer et de modifier un message précédent pour y insérer des éléments sélectionnables mis à jour (comme les définitions de produits). Dans certains exemples, une combinaison des approches ci-dessus peut être implémentée, dans laquelle certains messages (p. ex. les messages de confirmation) sont générés sous forme de nouveaux messages, tandis que d'autres (p. ex. les messages contenant des offres) sont transmis en tant que mises à jour des messages précédents, lorsqu'un message précédent est disponible pour la même transaction.
[00100] Bien que les données d'entrée du dispositif du client abordées ci-dessus en rapport avec le procédé 300 soient décrites comme étant reçues du dispositif du client 112 associé à l'identifiant d'adressage du client, dans d'autres exemples, les sélections (p. ex. les sélections de produits reçues au bloc 325) peuvent être reçues d'un dispositif du client distinct associé à un identifiant d'adressage différent. Par exemple, le message 700 peut être transféré à une adresse électronique distincte associée à un autre dispositif du client, et la sélection de produits mentionnée ci-dessus peut être reçue de cet autre dispositif du client. Il sera toutefois entendu que la sélection de produits reste associée à l'identifiant du client « bob@xyz.com », et que les messages suivants sont remis au même identifiant du client quelle que soit l'origine des sélections. En d'autres termes, des parties de l'opération peuvent être déléguées (p. ex. au sein d'une organisation) sans affecter l'identifiant du client auquel l'opération est associée.
[00101] Dans d'autres variantes, le mécanisme d'approbation décrit ci-dessus, lorsqu'il est appliqué aux achats initiés à travers l’exécution du procédé 300, peut être invoqué après le bloc 340 plutôt que le bloc 330. Dans de tels exemples, le bloc 335 est exécuté après la transmission de l'instruction d’achat et la réception des données de confirmation au bloc 340, mais avant l'envoi d'un message de confirmation au dispositif du client 112 au bloc 345. Dans ces exemples, comme on le verra désormais clairement, si l'approbation n'est pas accordée au bloc 820, d'autres mises à jour peuvent être nécessaires au dépositaire 108 pour annuler la transaction confirmée au bloc 340. Ainsi, le serveur 120 peut être configuré pour transmettre une instruction d'annulation lorsqu'un rejet est reçu au bloc 820.
Claims (18)
- REVENDICATIONS1. Un procédé de contrôle des mises à jour d'un serveur de réservation conservant des données de réservation correspondant à des produits achetables, le procédé comprenant :au niveau d’un serveur intermédiaire connecté au serveur de réservation, l’obtention des données d’initiation d'achat comprenant un identifiant de transaction et un identifiant d'adressage du client ;le stockage des données d’initiation d'achat sur le serveur intermédiaire ;au niveau du serveur intermédiaire, la génération et la transmission d’une demande de définitions de produits au serveur de réservation, en fonction des données d'initiation d'achat ;la réception d’une définition de produit du serveur de réservation, et le stockage de la définition de produit en association avec les données d'initiation d'achat ;la génération d'un message interactif contenant des données de définition de produit sélectionnables, et la transmission du message interactif en fonction de l'identifiant d'adressage du client ;la réception d'une sélection de produits sur le serveur intermédiaire, en réponse à la sélection des données de définition de produit dans le message interactif sur un dispositif du client correspondant à l'identifiant d'adressage du client ; et en réponse à la réception de la sélection de produits, la génération d’une instruction d'achat correspondant à la définition du produit et l’envoi de l'instruction d'achat au serveur de réservation, amenant le serveur de réservation à mettre à jour les données de réservation pour refléter un achat correspondant à l'identifiant d'adressage du client.
- 2. Le procédé selon la revendication 1 comprenant par ailleurs : avant de stocker les données d'initiation à l'achat, la validation des données d'initiation d’achat.
- 3. Le procédé selon la revendication 1 ou 2, dans lequel l’obtention des données d’initiation d’achat comprend :la réception des données d'initiation d'achat sur le serveur intermédiaire du serveur de réservation ou la réception des données d'initiation d'achat d’un serveur de détection.
- 4. Le procédé selon la revendication 3, comprenant par ailleurs, au niveau du serveur de détection :la réception des données d’entrée brutes du dispositif du client ;le classement des données d'entrée brutes pour déterminer si les données d'entrée brutes indiquent un événement d’intention d'achat ;lorsque la classification indique un événement d’intention d'achat, en extrayant les paramètres d’initiation d’achat des données d'entrée brutes ; et la transmission des paramètres d'initiation d’achat au serveur intermédiaire.
- 5. Le procédé selon la revendication 4, dans lequel les données d'entrée brutes comprennent au moins l'une des données de messagerie et des données de calendrier.
- 6. Le procédé de l'une quelconque des revendications 1 à 5, dans lequel les données de définition de produit sélectionnables contiennent des données de génération de commande amenant le dispositif du client, en réponse à la sélection des données de définition de produit, à générer une commande contenant la sélection de produit pour transmission au serveur intermédiaire.
- 7. Le procédé selon l'une quelconque des revendications 1 à 6, comprenant par ailleurs, au niveau du serveur intermédiaire :avant de produire et de transmettre la demande de définitions de produits, la détermination selon laquelle les données d’initiation d'achat contiennent ou non un sous-ensemble minimal de paramètres d’initiation d'achat ; et lorsque la détermination est négative, la génération d’un message de retour d’information contenant une invite pour au moins l'un des sous-ensembles minimaux, pour transmission au dispositif du client.
- 8. Le procédé selon l'une quelconque des revendications 1 à 7, comprenant par ailleurs :la récupération d'un identifiant d'adressage d'approbation ;la génération et la transmission d’un message de demande d'homologation conformément à l'identifiant d'adressage de l’approbation, le message de demande d'approbation contenant un élément d'homologation sélectionnable correspondant à la sélection du produit ; et la réception d’une sélection de l'élément d'approbation.
- 9. Le procédé selon la revendication 8, dans lequel la génération du message de demande d’approbation comprend par ailleurs :la récupération d'une sélection de produits supplémentaires correspondant à l'identifiant d'adressage d’approbation ; et la génération d'un message de demande agrégée contenant l'élément d'approbation sélectionnable et un élément d'approbation sélectionnable supplémentaire correspondant à la sélection de produit supplémentaire.
- 10. Un système de contrôle des mises à jour d'un serveur de réservation conservant des données de réservation correspondant à des produits achetables, le système comprenant :un serveur intermédiaire connecté au serveur de réservation et configuré pour : obtenir des données d’initiation d’achat, y compris un identifiant de transaction et un identifiant d'adressage du client ;enregistrer les données d’initiation d’achat ;générer et transmettre une demande de définition de produit au serveur de réservation, en fonction des données d'initiation d'achat ;recevoir une définition de produit du serveur de réservation et stocker la définition de produit en association avec les données d'initiation d'achat ;générer un message interactif contenant des données de définition de produit sélectionnables et transmettre le message interactif en fonction de l'identifiant d'adressage du client ;recevoir une sélection de produits sur le serveur intermédiaire, en réponse à la sélection des données de définition de produit dans le message interactif sur un dispositif du client correspondant à l'identifiant d'adressage du client ; et en réponse à la réception de la sélection de produits, générer une instruction d'achat correspondant à la définition du produit et envoyer l'instruction d'achat au serveur de réservation, amenant le serveur de réservation à mettre à jour les données de réservation pour refléter un achat correspondant à l'identifiant d'adressage du client.
- 11. Le système de la revendication 10, dans lequel le serveur intermédiaire est par ailleurs configuré, avant de stocker les données d'initiation d'achat, pour valider les données d'initiation d'achat et/ou dans lequel le serveur intermédiaire est par ailleurs configuré pour obtenir les données d'initiation d'achat en recevant les données d'initiation d'achat du serveur de réservation.
- 12. Le système de la revendication 10 ou 11 comprenant par ailleurs :un serveur de détection ;dans lequel le serveur intermédiaire est configuré pour obtenir les données d'initiation d'achat en recevant les données d'initiation d'achat du serveur de détection.
- 13. Le système de la revendication 12 dans lequel le serveur de détection est configuré pour :recevoir les données d'entrée brutes du dispositif du client ;classer les données brutes d'entrée pour déterminer si les données brutes d'entrée indiquent un événement d’intention d'achat ;lorsque la classification indique un événement d'intention d'achat, extraire les paramètres d’initiation d'achat à partir des données d'entrée brutes ; et transmettre les paramètres d’initiation d'achat au serveur intermédiaire.
- 14. Le système de la revendication 13, dans lequel les données d'entrée brutes comprennent au moins une des données de messagerie et des données de calendrier.
- 15. Le système de l'une quelconque des revendications 10 à 14, dans lequel les données de définition de produit sélectionnables contiennent des données de génération de commande amenant le dispositif du client, en réponse à la sélection des données de définition de produit, à générer une commande contenant la sélection de produit pour transmission au serveur intermédiaire.
- 16. Le système de l’une quelconque des revendications 10 à 15, dans lequel le serveur intermédiaire est par ailleurs configuré pour :avant de produire et de transmettre la demande de définitions de produits, déterminer si les données d’initiation d'achat contiennent un sous-ensemble minimal de paramètres d’initiation d'achat ; et lorsque la détermination est négative, générer un message de retour d information contenant une invite pour au moins l'un des sous-ensembles minimaux, pour transmission au dispositif du client.
- 17. Le système de l’une quelconque des revendications 10 à 16, dans lequel le serveur intermédiaire est par ailleurs configuré pour :récupérer un identifiant d'adressage d'approbation ;générer et transmettre un message de demande d'homologation conformément à l'identifiant d'adressage d'approbation, le message de demande d'approbation contenant un élément d'approbation sélectionnable correspondant à la sélection du produit ; et recevoir une sélection de l'élément d'approbation.
- 18. Le système de la revendication 17, dans lequel le serveur intermédiaire est par ailleurs configuré pour générer le message de demande d'approbation par :la récupération d'une sélection de produits supplémentaires correspondant à l'identifiant d'adressage d’approbation ; et la génération d'un message de demande agrégée contenant l'élément d'approbation sélectionnable et un élément d'approbation sélectionnable supplémentaire correspondant à la sélection de produit supplémentaire.
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1857434A FR3084947B1 (fr) | 2018-08-10 | 2018-08-10 | Systèmes et procédés de contrôle des mises à jour des données de réservation |
| US17/267,081 US20210312529A1 (en) | 2018-08-10 | 2019-08-02 | Systems and methods for controlling updates to booking data |
| EP19745628.8A EP3834143A1 (fr) | 2018-08-10 | 2019-08-02 | Systèmes et procédés de commande de mises à jour sur des données de réservation |
| PCT/EP2019/070857 WO2020030539A1 (fr) | 2018-08-10 | 2019-08-02 | Systèmes et procédés de commande de mises à jour sur des données de réservation |
| AU2019319010A AU2019319010A1 (en) | 2018-08-10 | 2019-08-02 | Systems and methods for controlling updates to booking data |
| CN201980052007.9A CN112585630A (zh) | 2018-08-10 | 2019-08-02 | 用于控制对预订数据的更新的系统和方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1857434A FR3084947B1 (fr) | 2018-08-10 | 2018-08-10 | Systèmes et procédés de contrôle des mises à jour des données de réservation |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3084947A1 true FR3084947A1 (fr) | 2020-02-14 |
| FR3084947B1 FR3084947B1 (fr) | 2022-03-25 |
Family
ID=65494228
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1857434A Active FR3084947B1 (fr) | 2018-08-10 | 2018-08-10 | Systèmes et procédés de contrôle des mises à jour des données de réservation |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20210312529A1 (fr) |
| EP (1) | EP3834143A1 (fr) |
| CN (1) | CN112585630A (fr) |
| AU (1) | AU2019319010A1 (fr) |
| FR (1) | FR3084947B1 (fr) |
| WO (1) | WO2020030539A1 (fr) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11113615B2 (en) | 2018-09-11 | 2021-09-07 | ZineOne, Inc. | Real-time event analysis utilizing relevance and sequencing |
| US11846749B2 (en) | 2020-01-14 | 2023-12-19 | ZineOne, Inc. | Network weather intelligence system |
| EP4027291A1 (fr) | 2021-01-06 | 2022-07-13 | Amadeus S.A.S. | Système informatique distribué pour la fourniture de données |
| EP4033718A1 (fr) * | 2021-01-22 | 2022-07-27 | Amadeus S.A.S. | Mise à jour de données par canal direct dans des systèmes d'échange de données médiés |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150032486A1 (en) * | 2013-07-29 | 2015-01-29 | Amadeus S.A.S. | Processing information queries in a distributed information processing environment |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| MX2016003061A (es) * | 2013-09-13 | 2016-10-28 | Fishberg Keith | Sistema de reservacion para la busqueda y compra de comodidades, servicios especiales y comidas/bebidas. |
| WO2015134665A1 (fr) * | 2014-03-04 | 2015-09-11 | SignalSense, Inc. | Classification de données à l'aide d'enregistrements neuronaux d'apprentissage profond raffinés de façon incrémentale via des entrées d'experts |
| EP3195145A4 (fr) * | 2014-09-16 | 2018-01-24 | VoiceBox Technologies Corporation | Commerce vocal |
| US10552796B1 (en) * | 2014-12-19 | 2020-02-04 | Amazon Technologies, Inc. | Approval service in a catalog service platform |
| US10623342B2 (en) * | 2016-02-19 | 2020-04-14 | Kik Interactive Inc. | System and method for integrating messaging network and external service providers |
-
2018
- 2018-08-10 FR FR1857434A patent/FR3084947B1/fr active Active
-
2019
- 2019-08-02 AU AU2019319010A patent/AU2019319010A1/en active Pending
- 2019-08-02 US US17/267,081 patent/US20210312529A1/en active Pending
- 2019-08-02 WO PCT/EP2019/070857 patent/WO2020030539A1/fr unknown
- 2019-08-02 CN CN201980052007.9A patent/CN112585630A/zh active Pending
- 2019-08-02 EP EP19745628.8A patent/EP3834143A1/fr not_active Withdrawn
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150032486A1 (en) * | 2013-07-29 | 2015-01-29 | Amadeus S.A.S. | Processing information queries in a distributed information processing environment |
Also Published As
| Publication number | Publication date |
|---|---|
| EP3834143A1 (fr) | 2021-06-16 |
| AU2019319010A1 (en) | 2021-03-04 |
| WO2020030539A1 (fr) | 2020-02-13 |
| CN112585630A (zh) | 2021-03-30 |
| US20210312529A1 (en) | 2021-10-07 |
| FR3084947B1 (fr) | 2022-03-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11102156B2 (en) | Presentation of organized personal and public data using communication mediums | |
| US11971936B2 (en) | Analyzing web pages to facilitate automatic navigation | |
| FR3084947A1 (fr) | Systèmes et procédés de contrôle des mises à jour des données de réservation | |
| US8812525B1 (en) | Local SQL files for mobile clients | |
| US8671001B1 (en) | Real-time attendance reporting | |
| US9064212B2 (en) | Automatic event categorization for event ticket network systems | |
| US11113696B2 (en) | Methods and systems for a virtual assistant | |
| US20080201197A1 (en) | System and Method for Peer Person- And Situation-Based Recommendations | |
| US10728294B2 (en) | Systems and methods for providing dynamic and interactive content in a chat session | |
| US20140143352A1 (en) | User profile and geography-based meetings | |
| CN111034157B (zh) | 用于动态投递内容的系统和方法 | |
| US20200404054A1 (en) | Computerized system, method and computer program product, facilitating real estate transactions | |
| US20080300926A1 (en) | Method and system for allowing user check-in | |
| US11257029B2 (en) | Pickup article cognitive fitment | |
| US20130066700A1 (en) | Group transaction processing using a social stream | |
| CN106663246A (zh) | 用于偏置任务辅助自动完成建议的系统和方法 | |
| US20120179750A1 (en) | Method and system for coordinating personnel for an event | |
| US11263678B2 (en) | System, method, and computer-readable storage medium for interactive kiosks | |
| US10872486B2 (en) | Enriched polling user experience | |
| US20140136370A1 (en) | System and Method for Optimization of Lease Management and Operation | |
| US11475221B2 (en) | Techniques for selecting content to include in user communications | |
| FR3080472A1 (fr) | Controle de la generation des resultats de recherche a entrees multiples | |
| CN115917578A (zh) | 用于自动暂存和获取房地产谈判的系统和方法 | |
| US20240232815A1 (en) | Method, apparatus and non-transitory media to provide options based on determining a user intends to travel to a destination | |
| FR3062228A1 (fr) | Base de donnees agregative d'enregistrements contexte |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20200214 |
|
| 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 |