FR3103917A1

FR3103917A1 - Système et procédé d’accès à des données auxiliaires

Info

Publication number: FR3103917A1
Application number: FR1913438A
Authority: FR
Inventors: Corinne Francoise Pascale LANDRA; Michael Dominique Raymond GALOPO
Original assignee: Amadeus SAS
Current assignee: Amadeus SAS
Priority date: 2019-11-29
Filing date: 2019-11-29
Publication date: 2021-06-04
Anticipated expiration: 2039-11-29
Also published as: FR3103917B1

Abstract

Un procédé pour fournir à un sous-système de fournisseur un accès à des données auxiliaires inclut : le stockage des données d’offre correspondant à un article, les données d’offre incluant (i) des données primaires, et (ii) des données auxiliaires définissant un ajustement entre les données primaires et les données publiées correspondantes stockées dans un répertoire externe ; le stockage des données d’offre dans un répertoire auxiliaire en réponse à une demande de commande provenant d’un sous-système client ; l’obtention d’un identifiant de commande correspondant aux données d’offre ; et la mise à jour du répertoire auxiliaire pour stocker l’identifiant de commande en association aux données d’offre ; en réponse à l’obtention de l’identifiant de commande, la génération d’un message de rapport pour transmission à un sous-système de fournisseur, le message de rapport contenant les données primaires et omettant les données auxiliaires ; et subséquemment à la génération du message de rapport, la récupération des données d’offre dans le répertoire auxiliaire et l’envoi d’au moins les données auxiliaires au sous-système du fournisseur.

Description

Système et procédé d’accès à des données auxiliaires

La spécification concerne de façon générale des systèmes de communication et spécifiquement un système et un procédé permettant l’accès à des données auxiliaires.

Contexte

La mise en œuvre de tâches diverses telles que la fourniture d’articles (p. ex. des produits et des services liés au voyage) des fournisseurs aux consommateurs peut impliquer une interaction entre un nombre de sous-systèmes informatiques distincts gérés par différentes entités. Des altérations à des mécanismes par lesquels certains des sous-systèmes mentionnés ci-dessus fonctionnent peuvent impacter négativement les opérations d’autres sous-systèmes qui peuvent nécessiter des modifications coûteuses aux autres sous-systèmes.

Résumé

Un aspect de la spécification fournit un procédé pour donner un accès à des données auxiliaires à un sous-système de fournisseur comprenant: le stockage de données d’offre correspondant à un article, les données d’offre incluant (i) des données primaires, et (ii) des données auxiliaires définissant un ajustement entre les données primaires et les données publiées correspondantes stockées dans un répertoire externe ; le stockage des données d’offre dans un répertoire auxiliaire ; en réponse à une demande de commande provenant d’un sous-système client: l’obtention d’un identifiant de commande correspondant aux données d’offre ; et la mise à jour du répertoire auxiliaire pour stocker l’identifiant de commande en association aux données d’offre ; en réponse à l’obtention de l’identifiant de commande, la génération d’un message de rapport pour transmission à un sous-système de fournisseur, le message de rapport contenant les données primaires et omettant les données auxiliaires ; et subséquemment à la génération du message de rapport, la récupération des données d’offre à partir du répertoire auxiliaire et l’envoi d’au moins les données auxiliaires au sous-système du fournisseur.

L’envoi d’au moins les données auxiliaires au sous-système de fournisseur peut inclure: la réception, du sous-système de fournisseur, d’une requête contenant l’identifiant de commande ; et en réponse à la requête, la récupération des données d’offre dans le répertoire auxiliaire et l’envoi d’au moins les données auxiliaires au sous-système de fournisseur.

L’envoi d’au moins les données auxiliaires à un sous-système de fournisseur peut inclure de récupérer automatiquement des données d’offre dans le répertoire auxiliaire et d’envoyer au moins les données auxiliaires au sous-système de fournisseur.

Les données primaires peuvent définir au moins une des données de composition et un prix pour l’article, et dans lequel les données auxiliaires définissent au moins un (i) d’une remise ou d’une majoration d’un prix et (ii) une modification des données de composition.

Le procédé peut par ailleurs envoyer un message de rapport directement au sous-système de fournisseur, préalablement à la récupération des données d’offre dans le répertoire auxiliaire, et envoyer au moins les données auxiliaires.

Le procédé peut par ailleurs envoyer le message de rapport à un sous-système de rapport pour livraison au sous-système de fournisseur.

Le procédé peut par ailleurs inclure: la détection qu’un critère de suppression d’un enregistrement auxiliaire a été satisfait ; et en réponse à la détection, la suppression des données d’offre du répertoire auxiliaire.

Le critère de suppression d’enregistrement auxiliaire peut inclure la réception de la requête contenant l’identifiant de commande.

Un autre aspect de la spécification fournit un serveur d’intermédiation pour donner à un sous-système de fournisseur un accès à des données auxiliaires, comprenant: une interface de communication ; une mémoire stockant un répertoire auxiliaire contenant les données d’offre correspondant à un article, les données d’offre incluant (i) des données primaires, et (ii) des données auxiliaires définissant un ajustement entre les données primaires et les données publiées correspondantes stockées dans un répertoire externe ; et un processeur connecté à l’interface de communication, et la mémoire, le processeur étant configuré pour: en réponse à une demande de commande provenant d’un sous-système client: obtenir un identifiant de commande correspondant aux données d’offre ; et mettre à jour le répertoire auxiliaire pour stocker l’identifiant de commande en association aux données d’offre ; en réponse à l’obtention de l’identifiant de commande, générer un message de rapport pour transmission à un sous-système de fournisseur, le message de rapport contenant les données primaires et omettant les données auxiliaires ; et subséquemment à la génération du message de rapport, récupérer les données d’offre dans le répertoire auxiliaire et envoyer au moins les données auxiliaires au sous-système de fournisseur.

Le processeur peut par ailleurs être configuré, afin d’envoyer au moins les données auxiliaires au sous-système de fournisseur, pour: recevoir, du sous-système de fournisseur une requête contenant l’identifiant de commande ; et en réponse à la requête, la récupération des données d’offre dans le répertoire auxiliaire et l’envoi d’au moins les données auxiliaires au sous-système de fournisseur.

Le processeur peut par ailleurs être configuré, afin d’envoyer au moins les données auxiliaires à un sous-système de fournisseur, pour récupérer automatiquement les données d’offre dans le répertoire auxiliaire et envoyer au moins les données auxiliaires au sous-système de fournisseur.

Les données primaires peuvent définir au moins une des données de composition et un prix pour l’article, et les données auxiliaires définissent au moins un (i) d’une remise ou d’une majoration d’un prix et (ii) une modification des données de composition.

Le processeur peut par ailleurs être configuré pour envoyer le message de rapport directement au sous-système de fournisseur, préalablement à la récupération des données d’offre dans le répertoire auxiliaire.

Le processeur peut par ailleurs envoyer le message de rapport à un sous-système de rapport pour livraison au sous-système de fournisseur.

Le processeur peut par ailleurs être configuré pour: détecter qu’un critère de suppression d’enregistrement auxiliaire a été satisfait ; et en réponse à la détection, supprimer les données d’offre dans le répertoire auxiliaire.

Un autre aspect de la spécification fournit un programme d’ordinateur comprenant un code de programme pour exécuter les étapes du procédé décrit dans la présente lorsque ledit programme est exécuté sur un ordinateur.

Les modes de réalisation sont décrits en faisant référence aux figures suivantes, dans lesquelles:

est un diagramme illustrant un système pour fournir un accès à des données auxiliaires ;

est un diagramme illustrant certains composants internes du sous-système client et du sous-système de fournisseur de la FIG.1 ;

est un organigramme d’un procédé pour fournir un accès à des données auxiliaires ;

est un diagramme illustrant l’exécution du bloc305 du procédé de la Fig.3 ;

est un diagramme illustrant l’exécution des blocs310 et 315 du procédé de la Fig.3 ;

est un diagramme illustrant l’exécution du bloc320 du procédé de la Fig.3 ; et

est un diagramme illustrant l’exécution du bloc325 du procédé de la Fig.3.

Description détaillée

La FIG.1 illustre un système100 pour fournir un accès à des données auxiliaires. À l’intérieur du système100, divers sous-systèmes informatiques interagissent pour générer et traiter des données relatives à quelconque d’une grande variété d’activités. Dans les exemples décrits ci-dessous, les sous-systèmes du système100 interagissent pour générer et traiter des données relatives à la livraison d’articles à des clients. Les articles dans les exemples sont des produits et des services liés au voyage, tels que des billets d’avion, des réservations d’hôtel, des réservations de location de véhicule, et similaires. Une grande variété d’autres activités peuvent être permises par l’échange de données entre les sous-systèmes montrés du système100 et la nature spécifique des données traitées à l’intérieur du système100 n’est pas particulièrement limitée.

Dans l’exemple illustré, le système100 inclut un sous-système client 104, gérés par une entité cliente qui peut aussi être désignée comme étant un vendeur. Le vendeur peut par exemple être une agence de voyages. Le sous-système client 140 génère des requêtes, p. ex. pour le compte de clients, pour des articles de voyage. Les requêtes spécifient divers attributs des articles de voyage, tels qu’un le lieu d’origine et de destination, des horaires et des dates de voyages, et similaires. Les réponses aux requêtes du sous-système client 104 sont générés par pour le compte d’entités qui fournissent les articles, désignées dans la présente comme étant des fournisseurs. Par conséquent, dans le présent exemple les fournisseurs sont des entités telles que des lignes aériennes, des gestionnaires hôteliers ou similaires qui délivrent les articles au client suite à l’achat des articles (p. ex. via le sous-système client104).

Dans l’exemple illustré, les fournisseurs génèrent aussi les réponses susmentionnées aux requêtes provenant du sous-système client 104. Dans ce but, chaque entité fournisseuse gère un sous-système de fournisseur108. Chacun des sous-systèmes client 104 et des sous-systèmes de fournisseur108 est implémenté comme au moins un dispositif informatique avec des assemblages d’entrée et de sortie et des dispositifs de communication pour échanger des données via un réseau112. Le réseau112 peut inclure une quelconque combinaison appropriée de réseaux de zone locale et de zone étendue, incluant l’Internet. Bien qu’un seul sous-système104 et un seul sous-système de fournisseur108 soient montrés dans la FIG.1, le système100 peut inclure un plus grand nombre ou un plus petit nombre de sous-systèmes104 et de sous-systèmes108 dans d’autres exemples.

Le sous-système de fournisseurs108 peut inclure un sous-système d’offre116 qui génèrent des données pour répondre aux requêtes provenant du sous-système client 104. En réponse à une quelconque requête donnée reçue à un sous-système de fournisseur108, le sous-système d’offre116 peut générer des données de réponse pour renvoyer au sous-système client 104, définissant un ou plusieurs articles ou ensembles d’articles qui sont sélectionnables pour achat au sous-système client 104. En général, la génération de données de réponse par un sous-système d’offre108 implique de faire une sélection parmi l’ensemble d’articles (p. ex. des vols) fourni par l’entité gérant le sous-système de fournisseur108, un plusieurs articles ayant des caractéristiques qui correspondent à au moins à certains des options et attributs dans la requête.

Bien que le sous-système d’offre116 génère des réponses aux requêtes provenant du sous-système client 104, les requêtes n’ont pas besoin d’être transmises directement du sous-système client 104 au sous-système de fournisseurs108. Plutôt, dans l’exemple illustré, le système100 inclut aussi un serveur d’intermédiation120 qui reçoit les requêtes provenant du sous-système client 104 et transmet ces requêtes au sous-système de fournisseur108. Le serveur d’intermédiation120 reçoit aussi des réponses provenant du sous-système de fournisseur108 et renvoie ces réponses au sous-système client 104.

Dans des systèmes qui incluent de multiples sous-systèmes de fournisseurs108, le serveur d’intermédiation100 peut donc transmettre une requête donnée du sous-système client 104 à de multiples sous-systèmes de fournisseurs108, recevoir des réponses de chacun de ces sous-systèmes de fournisseur108 et combiner les réponses à renvoyer au sous-système client 104. De plus, dans certains exemples le serveur d’intermédiation120 peut implémenter le sous-système d’offre116 pour le compte du sous-système de fournisseurs108 et le sous-système de fournisseur108 lui-même peut donc ne pas être directement impliqué dans la génération de réponses aux requêtes du sous-système client 104, fournissant au lieu de cela les donner de configuration périodiquement au serveur d’intermédiation120 pour permettre au serveur d’intermédiation120 d’implémenter le sous-système d’offre116.

Comme il en ressortira aisément aux hommes de métier, la génération d’offre par ou pour le compte du sous-système de fournisseur108 telle que décrite ci-dessus peut être implémentée conformément à la nouvelle norme de capacité de distribution (NDC) dans le système100. Le système100 peut aussi implémenter d’autres mécanismes de distribution d’offre, tels que le procédé hérité de système de distribution mondial (GDS), ainsi que le mécanisme décrit ci-dessus. Par exemple, le sous-système de fournisseur108 peut publier à un répertoire externe maintenu par un sous-système de publication124, des données telles que des tarifs (c.-à-d. des prix), des informations de programmation et similaire. Le sous-système de publication124 peut être consulté, par exemple, par le serveur d’intermédiation120 pour générer des offres en réponse à des requêtes provenant du sous-système client 104.

Suite au retour des données de réponse au sous-système client 104, via le serveur d’intermédiation120, le sous-système client 104 peut sélectionner un ou plusieurs articles pour achat. Une telle sélection peut aussi être désignée comme étant une requête de commande (c.-à-d. commander un article qui était offert par le sous-système de fournisseur108). La requête de commande est reçue au serveur d’intermédiation120 est traitée par un sous-système de gestion de commande également désignée simplement comme étant un sous-système de commande128. La gestion de la requête de commande peut inclure de transmettre des données au sous-système de fournisseurs108 pour initier des processus pour la provision actuelle (c.-à-d. la livraison et la réalisation) des articles pertinents pour le client par le fournisseur. Ces processus peuvent inclure de demander des informations de paiement, de stocker des informations d’identification de clients et de mettre à jour une liste de passagers pour un vol, par exemple. Le traitement d’une commande peut conduire à la génération d’un identifiant de commande, tel qu’un numéro de billet électronique qui peut être renvoyé au sous-système client 104 via le serveur d’intermédiation120.

De plus, le traitement d’une commande peut inclure la transmission de données de commande provenant du sous-système de commande128 au sous-système de fournisseur108. Plus spécifiquement, le sous-système de fournisseur108 peut inclure un sous-système en aval132, tel qu’un module de recettes et de comptabilité. Cette transmission peut être effectuée directement du sous-système de commande128 au sous-système en aval132, ou du sous-système de commande128 au sous-système de rapport136 qui est configuré pour transmettre les données de commande au sous-système en aval132. Un exemple du sous-système de rapport136 est un processeur de programme de règlement et de facturation (BSP).

Le sous-système en aval132 qui dans d’autres exemples peut être implémenté comme un sous-système séparé dans le système100 (c.-à-d. comme un dispositif informatique séparé physiquement et logiquement ou un ensemble de dispositifs informatiques du sous-système de fournisseur108), consomme les données de commande susmentionnées et effectue diverses actions en utilisant les données de commande. Des exemples de ces actions incluent la proratisation de recettes entre le fournisseur et le vendeur, entre le fournisseur et d’autres fournisseurs (p. ex. pour des vols interlignes) et similaire. Le sous-système en aval132 est aussi configuré pour récupérer des données du répertoire externe du sous-système de publication124 mentionné ci-dessus afin d’effectuer les actions ci-dessus.

Dans les systèmes fonctionnant selon les normes héritées (p. ex. le procédé GPS indiqué précédemment) il y a peu de déviation entre les données stockées par le système de publication124 et les données d’offre et de commande. Cependant, dans les systèmes fonctionnant selon d’autres normes, telles que la norme NDC, la génération de données d’offre au sous-système d’offre116 et dans certains cas aussi la génération de données de commande au sous-système de commande128 peuvent inclure des ajustements dynamiques. Ces ajustements peuvent inclure des ajustements aux prix des articles, une composition d’offre (p. ex. pour inclure des articles supplémentaires) et similaire. Ces ajustements peuvent ne pas être reflétés dans le sous-système de publication124. Par conséquent, le sous-système en aval132 peut recevoir des données de commande qui sont en conflit avec les données récupérées du sous-système de publication124. Par exemple, les données de commande peuvent définir un prix qui a été réduit par rapport au prix pour le même article récupéré du sous-système de publication124. Le sous-système en aval132 peut donc détecter un conflit et nécessiter une intervention humaine, ou il peut générer une sortie erronée.

Le système100 implémente une fonctionnalité supplémentaire pour permettre la provision de données auxiliaires définissant les ajustements ci-dessus au sous-système en aval132, tout en minimisant le besoin d’altérer des processus existants du système en aval132 et du sous-système de rapport136 pour recevoir ces données auxiliaires. La fonctionnalité supplémentaire du système100 minimise aussi ou évite le besoin pour des modifications au sous-système de publication124 lui-même, p. ex. pour accommoder le stockage de données définissant des ajustements dynamiques. Par ailleurs, les modifications susmentionnées, même si elles sont mises en œuvre, peuvent nécessiter que des fournisseurs108 publient des processus propriétaires (p. ex. au sous-système124) définissant comment des ajustements sont faits aux données d’offre. Cette publication peut ne pas être désirable.

Dans ce but, le serveur d’intermédiation120 inclut aussi un répertoire auxiliaire140 dans lequel des données d’offre (p. ex. reçues du sous-système d’offre116) sont stockées. Les données d’offre stockées incluent à la fois des données d’offre primaires définissant les attributs d’une offre, tels que le prix, le type et le nombre des articles, et similaire, et des données d’offre auxiliaires définissant des ajustements qui ont été appliqués afin de générer les données d’offre primaires. La donnée auxiliaire peut donc définir, par exemple, une remise qui a été appliquée pour obtenir la donnée d’offre primaire. En d’autres termes, les données auxiliaires fournissent une définition ou une explication d’une quelconque différence existante entre la donnée d’offre primaire et une quelconque donnée dans le système de publication124 qui peut être récupérée par le sous-système en aval132.

De plus, le serveur d’intermédiation120 actualise le répertoire auxiliaire140 pour stocker des identifiants de commande associés aux articles commandés (c’est-à-dire des offres qui ont été commandées par le sous-système client104). Le serveur d’intermédiation120 peut par ailleurs transmettre les données auxiliaires au sous-système de fournisseur108 (p. ex. au sous-système en aval132) en réponse à une requête provenant du sous-système de fournisseur108, ou sans requête, p. ex. concernant un planning convenu auparavant. En d’autres termes, bien que le sous-système132 puisse nécessiter des modifications techniques pour récupérer les données auxiliaires du serveur d’intermédiation120 et pour traiter des données auxiliaires, les processus par lesquels le sous-système en aval132 reçoit les données d’offre primaires et récupère les données du sous-système de publication124 n’ont pas besoin d’être modifiés. De façon similaire, la modification du sous-système de rapport136 peut aussi être évitée.

Avant d’aller plus loin dans la description de la fonctionnalité des divers composants du système100, certains composants internes du serveur d’intermédiation et du sous-système de fournisseurs108 seront exposés en faisant référence à la FIG.2.

Prêtant attention à la FIG.2, le serveur d’intermédiation120 inclut au moins un processeur200, tel qu’une unité de traitement centrale (CPU) ou similaire. Le processeur200 est relié à une mémoire204 implémentée comme un support non transitoire, lisible par ordinateur (p. ex. une combinaison appropriée de sous-systèmes de mémoires volatiles et non volatiles incluant une quelconque ou plusieurs mémoires à accès aléatoire [RAM], mémoires à lecture seule [ROM], mémoires programmables à lecture seule effaçables électriquement [EEPROM], mémoires flash, stockage informatique magnétique, et similaire). Le processeur200 et la mémoire204 sont généralement compris d’un ou de plusieurs circuits intégrés (ICs).

Le processeur200 est aussi interconnecté à une interface de communication208 qui permet au serveur120 de communiquer avec les autres dispositifs informatiques du système100 via le réseau112. L’interface de communication208 inclut donc tous les composants nécessaires (p. ex. des contrôleurs d’interface de réseau [NICs] des unités de radio, et autres similaires) pour communiquer via le réseau112. Les composants spécifiques de l’interface de communication208 sont sélectionnés en fonction de la nature du réseau112. Le serveur120 peut aussi inclure des dispositifs d’entrée et de sortie connectés au processeur200, tels que des claviers, des souris, des écrans, et similaires (non illustrés).

Les composants du serveur120 mentionnés ci-dessus peuvent être déployés dans une seule enceinte ou dans un format distribué. Par conséquent dans certains exemples, le serveur120 inclut une pluralité de processeurs qui peuvent soit partager la mémoire204 et l’interface de communications208 ou qui ont chacun des interfaces de communications et des mémoires associées distinctes.

La mémoire204 stocke le répertoire auxiliaire140 mentionné ci-dessus ainsi que des instructions lisibles par ordinateur, exécutables par le processeur200 pour implémenter diverses fonctionnalités. Les instructions lisibles par ordinateur peuvent aussi être désignées comme étant des applications et dans l’exemple illustré, la mémoire204 stocke une application de gestion de commande212 (également dénommée simplement dans la présente l’application212). Ainsi qu’illustrée dans la FIG.2, l’application212 peut implémenter le sous-système de commande128 montré dans la FIG.1. Le processeur200 exécute les instructions de l’application212 afin d’effectuer diverses actions définies par les instructions contenues dans la présente. Dans la description ci-dessous, le processeur200 et de façon plus générale le serveur120 sont censés effectuer ou être configurés pour effectuer ces actions. On comprendra qu’ils sont configurés ainsi via l’exécution (par le processeur200) des instructions des applications stockées dans la mémoire204. En général, le serveur120 est configuré, via l’exécution de l’application212, pour implémenter le stockage susmentionné et pour mettre à jour les données de commande dans le répertoire140 afin de faciliter l’accès aux données de commande auxiliaires par le sous-système en aval132.

Le sous-système de fournisseur108 tel qu’il est montré dans la FIG.2 inclut aussi un processeur220, une mémoire224 et une interface de communication228. La mémoire224 stocke une application de génération d’offre232 et une application de traitement on aval 236 qui implémente respectivement le sous-système d’offre116 et le sous-système en aval132.

Faisant maintenant référence à la FIG.3, certains aspects d’exploitation du système100 seront décrits de façon plus détaillée. Spécifiquement, la FIG.3 illustre un procédé300 pour permettre l’accès à des données auxiliaires. L’exécution du procédé300 sera exposée conjointement avec son exécution dans le système100 et spécifiquement par le serveur d’intermédiation120 via l’exécution de l’application212.

Au bloc305, le serveur d’intermédiation120 obtient et stocke, p. ex. dans le répertoire140, des données d’offre en réponse à une requête provenant du sous-système client 104. Par exemple, ainsi que noté précédemment, le serveur d’intermédiation120 peut recevoir une requête d’un sous-système client 104, relayer la requête à un ou plusieurs fournisseurs (p. ex. aux sous-systèmes de fournisseurs108) et recevoir des données d’offre des fournisseurs. Dans le présent exemple, ainsi que le montre la FIG.4, les données d’offre400 sont générées par le sous-systèmed’offre 116 et envoyées au serveur d’intermédiation120 pour stockage dans le répertoire140. Les données d’offre400 incluent des données primaires404 et des données auxiliaires408.

Les données primaires404 définissent des caractéristiques d’un ou de plusieurs articles (p. ex. des produits et des services liés au voyage) offerts par le gestionnaire du sous-système de fournisseurs108 pour achat, p. ex. par le consommateur représenté par le sous-système client 104. Par exemple, ainsi que décrit ci-dessous dans le tableau1, les données primaires définissent un vol de Paris à New York le 18 décembre 2019 à un prix de 950$. Diverses autres caractéristiques peuvent aussi être définies dans les données primaires404, incluant des services auxiliaires tels qu’un enregistrement de bagages, un accès au salon et similaire. Les données primaires404 peuvent aussi définir un itinéraire consistant de plus d’un seul vol.

ID d’offre	Primaire	Auxiliaire	ID de commande
400	Origine: Paris Dest.: NYC Date: 18/12/2019 Prix: 950$	Remise: 20%
...	...	...	...

Comment on le voit aussi dans le tableau1, les données auxiliaires408 définissent une remise qui a été appliquée à un prix d’origine du vol défini dans les données primaires404 pour arriver au prix montré dans les données primaires404. C’est-à-dire que le vol défini par les données primaires404 a un prix d’origine de 1187,50$ qui n’est pas reflété explicitement dans les données d’offre400. La remise peut avoir été appliquée au sous-système d’offre116 pour une quelconque d’une grande variété de raisons (p. ex. un programme de fidélisation de client). Diverses autres modifications aux prix d’origine sont aussi envisagées, incluant des remises plus ou moins grandes et des majorations (c.-à-d. des augmentations plutôt que des diminutions du prix). Les données auxiliaires408 peuvent aussi fournir des données supplémentaires (non illustrées) qui indiquent la raison de l’ajustement effectué. Par exemple, les données auxiliaires408 peuvent inclure une référence de transaction, un identifiant de règle ou similaire.

Il faut noter particulièrement que si le système de publication124 contient des données concernant le vol montré ci-dessus, le prix contenu dans la présente peut être le prix non modifié de 1187, 50$ parce que la remise reflétée dans les données auxiliaires408 a été appliquée de façon dynamique (p. ex. sur la base de l’identité du sous-système client 104 ou du client sous-jacent) et n’a donc pas été publiée au sous-système124. Les données auxiliaires408 définissent donc un ajustement entre la donnée primaire404 (c.-à-d. l’offre actuelle) et la donnée publiée correspondante disponible au sous-système124.

De retour à la FIG.3, au bloc310 le serveur d’intermédiation120 attend une requête de commande associée à l’offre400. Comme il en ressortira aisément pour les hommes de métier, le serveur d’intermédiation120 peut recevoir un nombre quelconque d’offres via de multiples exécutions du bloc305. Des requêtes de commande peuvent être reçues pour seulement un sous-ensemble de ces offres. Lorsque la détermination au bloc310 est négative parce qu’elle est liée à l’offre400, le serveur120 peut continuer à attendre une requête de commande. Dans certains exemples, l’offre400 peut être supprimée ou autrement marquée comme étant indisponible dans le répertoire140 après une durée configurable. Lorsque la détermination au bloc310 est affirmative, indiquant que le sous-système client 104 a envoyé une requête de commande, le serveur120 poursuit au bloc315.

Au bloc315, le serveur120 obtient un identifiant de commande et met à jour le répertoire auxiliaire pour stocker identifiant de commande associée aux données d’offre. L’identifiant de commande est un identifiant distinct de l’identifiant d’offre indiqué ci-dessus dans le tableau1 (« 400 » dans le présent exemple). L’identifiant de commande peut être, par exemple, un numéro de billet électronique et est généralement un identifiant utilisé pour d’autres fonctions dans le système100. L’identifiant de commande peut être généré par le sous-système de commande128, ou par le sous-système de fournisseur108 lui-même. La génération de l’identifiant de commande peut dépendre de l’accomplissement de diverses autres phases de traitement qui ne sont pas directement pertinentes à cette divulgation, telles que le règlement d’un paiement par le client pour l’article(s) commandé. À la réception de l’identifiant de commande, le serveur d’intermédiation120 met à jour le répertoire140 avec l’identifiant de commande, ainsi que montré ci-dessous dans le tableau2.

ID d’offre	Primaire	Auxiliaire	ID de commande
400	Origine: Paris Dest.: NYC Date: 12/18/2019 Prix: 950$	Remise: 20%	1.234.567
...	...	...	...

Comme on le voit ci-dessus, en plus des données primaires et auxiliaires404 et 408 montrées précédemment, l’enregistrement dans le répertoire140 correspondant au fait que l’offre140 a été actualisée pour inclure l’identifiant de commande « 1.234.567 ». Dans certains exemples, les données primaires et/ou auxiliaires peuvent aussi être obtenues au bloc315. C’est-à-dire, que dans certains cas l’achat des articles offerts inclut la génération d’un prix final et/ou d’un ensemble final d’articles, pendant lequel le sous-système de commande128 peut encore ajuster le prix et/ou la composition de l’offre initiale.

La FIG.5 illustre des exécutions exemplaires des blocs310 et 315 dans le système100. En particulier, une requête de commande500 est montrée en cours de transmission du sous-système client 104 au serveur d’intermédiation120 (et spécifiquement au sous-système de commande128). La requête de commande500 contient l’identifiant d’offre« 400 » et le sous-systèmede commande 128 initie donc un flux de traitement pour compléter l’achat du vol montré dans les tableaux1 et 2 par le sous-système client 104. La nature spécifique de ce flux de traitement ne rentre pas dans le champ d’application de la présente divulgation, cependant, un des résultats du processus de commande est la génération de l’identifiant de commande susmentionné. L’identifiant de commande est stocké dans le répertoire140, p. ex. via un message504, en association à l’enregistrement définissant la commande400. Ainsi cet enregistrement est actualisé pour contenir aussi une valeur d’identifiant de commande508.

Faisant à nouveau référence à la FIG.3, au bloc320 le serveur d’intermédiation120 (p. ex. le sous-système de commande128) génère au moins un message de rapport contenant les données de commande pour transmission au sous-système en aval132 du sous-système de fournisseur108. Le message de rapport contient les données primaires404 du répertoire140, mais omet les données auxiliaires408. Le serveur120 envoie ensuite le message de rapport pour livraison au sous-système en aval132 via un quelconque canal approprié.

Dans certains exemples, le message de rapport peut être envoyé directement au sous-système de fournisseur108 via le réseau112 selon un quelconque d’une variété de formats appropriés, incluant ceux qui sont définis par le guide de spécification d’échange de données (DISH) dans le contexte des articles liés au voyage. Dans d’autres exemples, le message de rapport est envoyé au sous-système de rapport136 plutôt que directement au sous-système en aval132. Un exemple de l’exécution du bloc320 selon le rapport indirect susmentionné est montré dans la FIG.6. Comme il en ressortira aisément pour les hommes de métier, des formats tels que DISH peuvent ne pas être capables d’accommoder de façon efficace les données auxiliaires. Les données auxiliaires sont donc omises du message de rapport pour être transmises séparément comme ceci sera exposé ci-dessous.

La FIG.6 illustre la transmission de données primaires404 et de l’identifiant de commande508 du serveur d’intermédiation120 au sous-système de rapport136. Le sous-système de rapport136 peut être configuré, par exemple, pour traiter un nombre de ces messages de rapport et pour en transmettre les données au sous-système en aval132 périodiquement. Par exemple, le sous-système de rapport136 est montré dans la FIG.6 transmettant un message600 qui contient les données primaires404 et l’identifiant de commande508 (et peut contenir diverses autres données) au sous-système en aval132.

De retour à la FIG.3, suite à l’exécution du bloc320, au bloc325 le serveur d’intermédiation120 détermine s’il doit envoyer les données auxiliaires au sous-système en aval132. Ainsi que montré ci-dessus, les données auxiliaires408 n’ont pas encore été fournies au sous-système en aval132, par exemple parce que les canaux de communication (p. ex. APIs, formats de fichier et similaire) utilisés pour relayer le message(s) de rapport au bloc320 ne prennent pas en charge les données auxiliaires.

La détermination au bloc325 peut inclure de déterminer si une requête a été reçue au serveur d’intermédiation120 en provenance du sous-système en aval132. Dans d’autres exemples, au bloc325 le serveur d’intermédiation120 détermine s’il faut transmettre les données auxiliaires sans attendre une requête. La nature spécifique de la détermination au bloc325 peut aussi être spécifique aux sous-systèmes de fournisseurs108. C’est-à-dire que le serveur d’intermédiation120 peut être configuré pour attendre une requête du sous-système de fournisseur108, mais peut aussi être configuré pour transmettre automatiquement les données auxiliaires à un autre sous-système de fournisseur, sans attendre une requête. Cette transmission, de type pousser, des données auxiliaires peut être effectuée périodiquement selon une quelconque programmation appropriée.

La FIG.7 illustre une exécution exemplaire du bloc325, dans lequel le sous-système en aval132 envoie une requête700 incluant l’identifiant de commande508 au serveur d’intermédiation120. Le sous-système en aval132 envoie aussi une requête704 au sous-système de publication124, p. ex. pour récupérer des données publiées précédemment correspondant aux données primaires404. Dans d’autres exemples, le sous-système en aval132 peut omettre la transmission de la requête704 et reposer seulement sur les données primaires reçues via le message de rapport600 et les données auxiliaires provenant du serveur d’intermédiation120. Comme il en ressortira aisément pour les hommes de métier, une quelconque donnée récupérée du sous-système de publication124 ne reflétera pas l’ajustement défini dans les données auxiliaires408 qui ont résulté des données primaires404. Par exemple les données récupérées du sous-système de publication124 pour le vol Paris-NYC, montrées dans les tableaux1 et 2 peuvent contenir uniquement le prix original sans remise de 1187,50$ et non le prix défini dans les données primaires404.

Lorsque la détermination au bloc325 est négative, le serveur d’intermédiation120 peut répéter l’exécution du bloc325. Lorsque la détermination au bloc325 est affirmative, le serveur d’intermédiation120 poursuit au bloc330. Au bloc330, le serveur120 récupère au moins les données auxiliaires408 du répertoire140 et envoie les données auxiliaires408 au sous-système en aval132, ainsi que l’identifiant de commande508. Les données auxiliaires408 seules peuvent être envoyées au bloc330, ou l’enregistrement entier (c.-à-d. les données primaires404 et les données auxiliaires408) peut être transmis au bloc330.

Le sous-système en aval132 est donc approvisionné avec les données auxiliaires sans aucune modification aux mécanismes de rapport utilisés pour relayer les données primaires au sous-système en aval132, soit directement ou via le sous-système de rapport136.

Au bloc335, suite à la transmission des données auxiliaires au bloc330, le serveur d’intermédiation120 peut déterminer s’il doit supprimer l’enregistrement contenant les données primaires404 et les données auxiliaires408 dans le répertoire140. La détermination au bloc335 peut être basée sur divers critères. Dans certains exemples, la détermination au bloc335 peut être automatiquement affirmative une fois que les données auxiliaires ont été fournies au sous-système en aval132. Dans d’autres exemples, la détermination au bloc335 inclut de déterminer si une durée configurable (p. ex. cinq ans) s’est écoulée depuis la création de l’enregistrement correspondant dans le répertoire140. Dans d’autres exemples, une combinaison des critères ci-dessus peut être appliquée. C’est-à-dire, que le serveur d’intermédiation120 peut déterminer si les données auxiliaires408 ont été demandées et si la durée configurable s’est écoulée, avec une détermination affirmative résultant seulement lorsque les deux critères sont satisfaits.

Lorsque la détermination au bloc335 est négative, le serveur d’intermédiation120 peut répéter la détermination ou peut retourner au bloc325 pour attendre d’autres requêtes pour les données auxiliaires. Par exemple, d’autres composants du système100 peuvent aussi être capables de demander les données auxiliaires408 du serveur d’intermédiation120, incluant le sous-système client 104 et les autres sous-systèmes de fournisseurs (p. ex. les vols interlignes). Le serveur d’intermédiation120 peut implémenter des contrôles d’accès pour le répertoire140 de sorte que seulement certaines entités soient autorisées à accéder aux données d’offres400. Par exemple, le répertoire140 peut inclure des indications précisant quelles entités sont autorisées à accéder à chaque enregistrement contenu dans celui-ci.

Lorsque la détermination au bloc355 est affirmative, l’enregistrement contenant les données primaires404, les données auxiliaires408 et identifiant de commande 508 est supprimé du répertoire140.

Les hommes de métier apprécieront que dans certains modes de réalisation, la fonctionnalité des applications212, 232 et 236 puisse être implémentée en utilisant du matériel préprogrammé ou des éléments micrologiciels (p. ex. des circuits intégrés spécifiques aux applications [ASICs], des mémoires à lecture seule programmables et effaçables électriquement [EEPROMs], etc. ou d’autres composants associés.

Claims

Un procédé pour fournir un accès à des données auxiliaires à un sous-système de fournisseur parmi multiples sous-systèmes de fournisseurs, dans lequel le procédé est mise en œuvre dans un serveur d’intermédiation communiquant avec un sous-système client et les multiples sous-systèmes de fournisseurs, dans lequel un format spécifié pour la transmission au sous-système de fournisseur n’est pas capable d’accommoder de façon efficace les données auxiliaires, comprenant:
le stockage de données d’offre correspondant à un article, les données d’offre incluant (i) des données primaires, et (ii) des données auxiliaires définissant un ajustement entre les données primaires et les données publiées correspondantes stockées dans un répertoire externe ;
le stockage des données d’offre dans un répertoire auxiliaire ;
en réponse à une demande de commande provenant du sous-système client:
l’obtention d’un identifiant de commande correspondant aux données d’offre ; et

la mise à jour du répertoire auxiliaire pour stocker l’identifiant de commande en association aux données d’offre ;
en réponse à l’obtention de l’identifiant de commande, la génération d’un message de rapport pour transmission à un sous-système de fournisseur, le message de rapport contenant les données primaires et omettant les données auxiliaires ; et
subséquemment à la génération du message de rapport, la récupération des données d’offre à partir du répertoire auxiliaire et l’envoi d’au moins les données auxiliaires au sous-système de fournisseur.
Le procédé de la revendication1, dans lequel l’envoi d’au moins les données auxiliaires au sous-système de fournisseur inclut:
la réception, du sous-système de fournisseur d’une requête contenant l’identifiant de commande ; et
en réponse à la requête, la récupération des données d’offre dans le répertoire auxiliaire et l’envoi d’au moins les données auxiliaires au sous-système de fournisseur.
Le procédé de la revendication1 ou 2, dans lequel l’envoi d’au moins les données auxiliaires à un sous-système de fournisseur inclut, automatiquement, la récupération des données d’offre à partir du répertoire auxiliaire et l’envoi d’au moins les données auxiliaires au sous-système de fournisseur.
Le procédé de l’une quelconque des revendications1 à 3, dans lequel les données primaires définissent au moins une des données de composition et un prix pour l’article, et dans lequel les données auxiliaires définissent au moins un (i) d’une remise ou d’une majoration à un prix et (ii) une modification des données de composition.
Le procédé de l’une quelconque des revendications1 à 4, comprenant par ailleurs l’envoi d’un message de rapport directement au sous-système de fournisseur, préalablement à la récupération des données d’offre dans le répertoire auxiliaire, et l’envoi d’au moins les données auxiliaires.
Le procédé de l’une quelconque des revendications1 à 5, comprenant par ailleurs l’envoi du message de rapport à un sous-système de rapport pour livraison au sous-système de fournisseur.
Le procédé de la revendication2, comprenant par ailleurs:
la détection qu’un critère de suppression d’un enregistrement auxiliaire a été satisfait ; et
en réponse à la détection, la suppression des données d’offre du répertoire auxiliaire.
Le procédé de la revendication7, dans lequel le critère de suppression d’enregistrement auxiliaire inclut la réception de la requête contenant l’identifiant de commande.
Un serveur d’intermédiation pour fournir un accès à des données auxiliaires à un sous-système de fournisseur parmi multiples sous-systèmes de fournisseurs, dans lequel un format spécifié pour la transmission au sous-système de fournisseur n’est pas capable d’accommoder de façon efficace les données auxiliaires, comprenant:
une interface de communication communiquant avec un sous-système client et les multiples sous-systèmes de fournisseurs;
une mémoire stockant un répertoire auxiliaire contenant les données d’offre correspondant à un article, les données d’offre incluant (i) des données primaires, et (ii) des données auxiliaires définissant un ajustement entre les données primaires et les données publiées correspondantes stockées dans un répertoire externe ; et
un processeur connecté à l’interface de communication et à la mémoire, dans lequel le processeur est configuré pour:
en réponse à une demande de commande provenant du sous-système de client:

obtenir un identifiant de commande correspondant aux données d’offre ; et

la mise à jour du répertoire auxiliaire pour stocker l’identifiant de commande en association aux données d’offre ;

en réponse à l’obtention de l’identifiant de commande, générer un message de rapport pour transmission à un sous-système de fournisseur, le message de rapport contenant les données primaires et omettant les données auxiliaires ; et

subséquemment à la génération du message de rapport, la récupération des données d’offre dans le répertoire auxiliaire et l’envoi d’au moins les données auxiliaires au sous-système de fournisseur.
Le serveur d’intermédiation de la revendication9, dans lequel le processeur est par ailleurs configuré, afin d’envoyer au moins les données auxiliaires au sous-système de fournisseur, pour:
recevoir, du sous-système de fournisseur une requête contenant l’identifiant de commande ; et
en réponse à la requête, récupérer les données d’offre dans le répertoire auxiliaire et envoyer au moins les données auxiliaires au sous-système de fournisseur.
Le serveur d’intermédiation de la revendication9 ou 10, dans lequel le processeur est par ailleurs configuré, dans le but d’envoyer au moins les données auxiliaires à un sous-système de fournisseur, pour récupérer automatiquement les données d’offre dans le répertoire auxiliaire et pour envoyer au moins les données auxiliaires au sous-système de fournisseur.
Le serveur d’intermédiation de l’une quelconque des revendications9 à 11, dans lequel les données primaires définissent au moins une des données de composition et un prix pour l’article, et dans lequel les données auxiliaires définissent au moins un (i) d’une remise ou d’une majoration à un prix et (ii) une modification des données de composition.
Le serveur d’intermédiation de l’une quelconque des revendications9 à 12, dans lequel le processeur est par ailleurs configuré pour renvoyer le message de rapport directement au sous-système de fournisseur, préalablement à la récupération des données d’offre dans le répertoire auxiliaire.
Le serveur d’intermédiation de l’une quelconque des revendications9 à 13, dans lequel le processeur est par ailleurs configuré pour envoyer le message de rapport à un sous-système de rapport pour livraison au sous-système de fournisseur.
Le serveur d’intermédiation de la revendication10, dans lequel le processeur est par ailleurs configuré pour:
détecter qu’un critère de suppression d’enregistrement auxiliaire a été satisfait ; et
en réponse à la détection, supprimer les données d’offre dans le répertoire auxiliaire.
Le serveur d’intermédiation de la revendication15, dans lequel le critère de suppression d’enregistrement auxiliaire inclut la réception de la requête contenant l’identifiant de commande.
Un programme d’ordinateur comprenant des instructions pour exécuter les étapes du procédé selon les revendications1 à 8 lorsque ledit programme fonctionne sur un ordinateur.