Brevet FR3103917A1 — publié le 20210604

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. 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. 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 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 bloc 305 du procédé de la Fig. 3 ; est un diagramme illustrant l’exécution des blocs 310 et 315 du procédé de la Fig. 3 ; est un diagramme illustrant l’exécution du bloc 320 du procédé de la Fig. 3 ; et est un diagramme illustrant l’exécution du bloc 325 du procédé de la Fig. 3. Description détaillée La FIG. 1 illustre un système 100 pour fournir un accès à des données auxiliaires. À l’intérieur du système 100, 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ème 100 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ème 100 et la nature spécifique des données traitées à l’intérieur du système 100 n’est pas particulièrement limitée. Dans l’exemple illustré, le système 100 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 client 104). 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 fournisseur 108. Chacun des sous-systèmes client 104 et des sous-systèmes de fournisseur 108 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éseau 112. Le réseau 112 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ème 104 et un seul sous-système de fournisseur 108 soient montrés dans la FIG. 1, le système 100 peut inclure un plus grand nombre ou un plus petit nombre de sous-systèmes 104 et de sous-systèmes 108 dans d’autres exemples. Le sous-système de fournisseurs 108 peut inclure un sous-système d’offre 116 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’offre 116 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’offre 108 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 fournisseur 108, 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’offre 116 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 fournisseurs 108. Plutôt, dans l’exemple illustré, le système 100 inclut aussi un serveur d’intermédiation 120 qui reçoit les requêtes provenant du sous-système client 104 et transmet ces requêtes au sous-système de fournisseur 108. Le serveur d’intermédiation 120 reçoit aussi des réponses provenant du sous-système de fournisseur 108 et renvoie ces réponses au sous-système client 104. Dans des systèmes qui incluent de multiples sous-systèmes de fournisseurs 108, le serveur d’intermédiation 100 peut donc transmettre une requête donnée du sous-système client 104 à de multiples sous-systèmes de fournisseurs 108, recevoir des réponses de chacun de ces sous-systèmes de fournisseur 108 et combiner les réponses à renvoyer au sous-système client 104. De plus, dans certains exemples le serveur d’intermédiation 120 peut implémenter le sous-système d’offre 116 pour le compte du sous-système de fournisseurs 108 et le sous-système de fournisseur 108 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édiation 120 pour permettre au serveur d’intermédiation 120 d’implémenter le sous-système d’offre 116. 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 fournisseur 108 telle que décrite ci-dessus peut être implémentée conformément à la nouvelle norme de capacité de distribution (NDC) dans le système 100. Le système 100 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 fournisseur 108 peut publier à un répertoire externe maintenu par un sous-système de publication 124, des données telles que des tarifs (c.-à-d. des prix), des informations de programmation et similaire. Le sous-système de publication 124 peut être consulté, par exemple, par le serveur d’intermédiation 120 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édiation 120, 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 fournisseur 108). 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 commande 128. La gestion de la requête de commande peut inclure de transmettre des données au sous-système de fournisseurs 108 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édiation 120. De plus, le traitement d’une commande peut inclure la transmission de données de commande provenant du sous-système de commande 128 au sous-système de fournisseur 108. Plus spécifiquement, le sous-système de fournisseur 108 peut inclure un sous-système en aval 132, tel qu’un module de recettes et de comptabilité. Cette transmission peut être effectuée directement du sous-système de commande 128 au sous-système en aval 132, ou du sous-système de commande 128 au sous-système de rapport 136 qui est configuré pour transmettre les données de commande au sous-système en aval 132. Un exemple du sous-système de rapport 136 est un processeur de programme de règlement et de facturation (BSP). Le sous-système en aval 132 qui dans d’autres exemples peut être implémenté comme un sous-système séparé dans le système 100 (c.-à-d. comme un dispositif informatique séparé physiquement et logiquement ou un ensemble de dispositifs informatiques du sous-système de fournisseur 108), 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 aval 132 est aussi configuré pour récupérer des données du répertoire externe du sous-système de publication 124 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 publication 124 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’offre 116 et dans certains cas aussi la génération de données de commande au sous-système de commande 128 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 publication 124. Par conséquent, le sous-système en aval 132 peut recevoir des données de commande qui sont en conflit avec les données récupérées du sous-système de publication 124. 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 publication 124. Le sous-système en aval 132 peut donc détecter un conflit et nécessiter une intervention humaine, ou il peut générer une sortie erronée. Le système 100 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 aval 132, tout en minimisant le besoin d’altérer des processus existants du système en aval 132 et du sous-système de rapport 136 pour recevoir ces données auxiliaires. La fonctionnalité supplémentaire du système 100 minimise aussi ou évite le besoin pour des modifications au sous-système de publication 124 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 fournisseurs 108 publient des processus propriétaires (p. ex. au sous-système 124) 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édiation 120 inclut aussi un répertoire auxiliaire 140 dans lequel des données d’offre (p. ex. reçues du sous-système d’offre 116) 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 publication 124 qui peut être récupérée par le sous-système en aval 132. De plus, le serveur d’intermédiation 120 actualise le répertoire auxiliaire 140 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 client 104). Le serveur d’intermédiation 120 peut par ailleurs transmettre les données auxiliaires au sous-système de fournisseur 108 (p. ex. au sous-système en aval 132) en réponse à une requête provenant du sous-système de fournisseur 108, ou sans requête, p. ex. concernant un planning convenu auparavant. En d’autres termes, bien que le sous-système 132 puisse nécessiter des modifications techniques pour récupérer les données auxiliaires du serveur d’intermédiation 120 et pour traiter des données auxiliaires, les processus par lesquels le sous-système en aval 132 reçoit les données d’offre primaires et récupère les données du sous-système de publication 124 n’ont pas besoin d’être modifiés. De façon similaire, la modification du sous-système de rapport 136 peut aussi être évitée. Avant d’aller plus loin dans la description de la fonctionnalité des divers composants du système 100, certains composants internes du serveur d’intermédiation et du sous-système de fournisseurs 108 seront exposés en faisant référence à la FIG. 2. Prêtant attention à la FIG.2, le serveur d’intermédiation 120 inclut au moins un processeur 200, tel qu’une unité de traitement centrale (CPU) ou similaire. Le processeur 200 est relié à une mémoire 204 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 processeur 200 et la mémoire 204 sont généralement compris d’un ou de plusieurs circuits intégrés (ICs). Le processeur 200 est aussi interconnecté à une interface de communication 208 qui permet au serveur 120 de communiquer avec les autres dispositifs informatiques du système 100 via le réseau 112. L’interface de communication 208 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éseau 112. Les composants spécifiques de l’interface de communication 208 sont sélectionnés en fonction de la nature du réseau 112. Le serveur 120 peut aussi inclure des dispositifs d’entrée et de sortie connectés au processeur 200, tels que des claviers, des souris, des écrans, et similaires (non illustrés). Les composants du serveur 120 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 serveur 120 inclut une pluralité de processeurs qui peuvent soit partager la mémoire 204 et l’interface de communications 208 ou qui ont chacun des interfaces de communications et des mémoires associées distinctes. La mémoire 204 stocke le répertoire auxiliaire 140 mentionné ci-dessus ainsi que des instructions lisibles par ordinateur, exécutables par le processeur 200 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émoire 204 stocke une application de gestion de commande 212 (également dénommée simplement dans la présente l’application 212). Ainsi qu’illustrée dans la FIG. 2, l’application 212 peut implémenter le sous-système de commande 128 montré dans la FIG. 1. Le processeur 200 exécute les instructions de l’application 212 afin d’effectuer diverses actions définies par les instructions contenues dans la présente. Dans la description ci-dessous, le processeur 200 et de façon plus générale le serveur 120 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 processeur 200) des instructions des applications stockées dans la mémoire 204. En général, le serveur 120 est configuré, via l’exécution de l’application 212, pour implémenter le stockage susmentionné et pour mettre à jour les données de commande dans le répertoire 140 afin de faciliter l’accès aux données de commande auxiliaires par le sous-système en aval 132. Le sous-système de fournisseur 108 tel qu’il est montré dans la FIG. 2 inclut aussi un processeur 220, une mémoire 224 et une interface de communication 228. La mémoire 224 stocke une application de génération d’offre 232 et une application de traitement on aval 236 qui implémente respectivement le sous-système d’offre 116 et le sous-système en aval 132. Faisant maintenant référence à la FIG. 3, certains aspects d’exploitation du système 100 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ème 100 et spécifiquement par le serveur d’intermédiation 120 via l’exécution de l’application 212. Au bloc 305, le serveur d’intermédiation 120 obtient et stocke, p. ex. dans le répertoire 140, 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édiation 120 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 fournisseurs 108) 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’offre 400 sont générées par le sous-système d’offre 116 et envoyées au serveur d’intermédiation 120 pour stockage dans le répertoire 140. Les données d’offre 400 incluent des données primaires 404 et des données auxiliaires 408. Les données primaires 404 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 fournisseurs 108 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 tableau 1, 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 primaires 404, incluant des services auxiliaires tels qu’un enregistrement de bagages, un accès au salon et similaire. Les données primaires 404 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 tableau 1, les données auxiliaires 408 définissent une remise qui a été appliquée à un prix d’origine du vol défini dans les données primaires 404 pour arriver au prix montré dans les données primaires 404. C’est-à-dire que le vol défini par les données primaires 404 a un prix d’origine de 1187,50 $ qui n’est pas reflété explicitement dans les données d’offre 400. La remise peut avoir été appliquée au sous-système d’offre 116 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 auxiliaires 408 peuvent aussi fournir des données supplémentaires (non illustrées) qui indiquent la raison de l’ajustement effectué. Par exemple, les données auxiliaires 408 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 publication 124 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 auxiliaires 408 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ème 124. Les données auxiliaires 408 définissent donc un ajustement entre la donnée primaire 404 (c.-à-d. l’offre actuelle) et la donnée publiée correspondante disponible au sous-système 124. De retour à la FIG. 3, au bloc 310 le serveur d’intermédiation 120 attend une requête de commande associée à l’offre 400. Comme il en ressortira aisément pour les hommes de métier, le serveur d’intermédiation 120 peut recevoir un nombre quelconque d’offres via de multiples exécutions du bloc 305. Des requêtes de commande peuvent être reçues pour seulement un sous-ensemble de ces offres. Lorsque la détermination au bloc 310 est négative parce qu’elle est liée à l’offre 400, le serveur 120 peut continuer à attendre une requête de commande. Dans certains exemples, l’offre 400 peut être supprimée ou autrement marquée comme étant indisponible dans le répertoire 140 après une durée configurable. Lorsque la détermination au bloc 310 est affirmative, indiquant que le sous-système client 104 a envoyé une requête de commande, le serveur 120 poursuit au bloc 315. Au bloc 315, le serveur 120 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 tableau 1 (« 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ème 100. L’identifiant de commande peut être généré par le sous-système de commande 128, ou par le sous-système de fournisseur 108 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édiation 120 met à jour le répertoire 140 avec l’identifiant de commande, ainsi que montré ci-dessous dans le tableau 2. 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 auxiliaires 404 et 408 montrées précédemment, l’enregistrement dans le répertoire 140 correspondant au fait que l’offre 140 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 bloc 315. 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 commande 128 peut encore ajuster le prix et/ou la composition de l’offre initiale. La FIG. 5 illustre des exécutions exemplaires des blocs 310 et 315 dans le système 100. En particulier, une requête de commande 500 est montrée en cours de transmission du sous-système client 104 au serveur d’intermédiation 120 (et spécifiquement au sous-système de commande 128). La requête de commande 500 contient l’identifiant d’offre « 400 » et le sous-système de commande 128 initie donc un flux de traitement pour compléter l’achat du vol montré dans les tableaux 1 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épertoire 140, p. ex. via un message 504, en association à l’enregistrement définissant la commande 400. Ainsi cet enregistrement est actualisé pour contenir aussi une valeur d’identifiant de commande 508. Faisant à nouveau référence à la FIG. 3, au bloc 320 le serveur d’intermédiation 120 (p. ex. le sous-système de commande 128) génère au moins un message de rapport contenant les données de commande pour transmission au sous-système en aval 132 du sous-système de fournisseur 108. Le message de rapport contient les données primaires 404 du répertoire 140, mais omet les données auxiliaires 408. Le serveur 120 envoie ensuite le message de rapport pour livraison au sous-système en aval 132 via un quelconque canal approprié. Dans certains exemples, le message de rapport peut être envoyé directement au sous-système de fournisseur 108 via le réseau 112 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 rapport 136 plutôt que directement au sous-système en aval 132. Un exemple de l’exécution du bloc 320 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 primaires 404 et de l’identifiant de commande 508 du serveur d’intermédiation 120 au sous-système de rapport 136. Le sous-système de rapport 136 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 aval 132 périodiquement. Par exemple, le sous-système de rapport 136 est montré dans la FIG. 6 transmettant un message 600 qui contient les données primaires 404 et l’identifiant de commande 508 (et peut contenir diverses autres données) au sous-système en aval 132. De retour à la FIG. 3, suite à l’exécution du bloc 320, au bloc 325 le serveur d’intermédiation 120 détermine s’il doit envoyer les données auxiliaires au sous-système en aval 132. Ainsi que montré ci-dessus, les données auxiliaires 408 n’ont pas encore été fournies au sous-système en aval 132, 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 bloc 320 ne prennent pas en charge les données auxiliaires. La détermination au bloc 325 peut inclure de déterminer si une requête a été reçue au serveur d’intermédiation 120 en provenance du sous-système en aval 132. Dans d’autres exemples, au bloc 325 le serveur d’intermédiation 120 détermine s’il faut transmettre les données auxiliaires sans attendre une requête. La nature spécifique de la détermination au bloc 325 peut aussi être spécifique aux sous-systèmes de fournisseurs 108. C’est-à-dire que le serveur d’intermédiation 120 peut être configuré pour attendre une requête du sous-système de fournisseur 108, 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 bloc 325, dans lequel le sous-système en aval 132 envoie une requête 700 incluant l’identifiant de commande 508 au serveur d’intermédiation 120. Le sous-système en aval 132 envoie aussi une requête 704 au sous-système de publication 124, p. ex. pour récupérer des données publiées précédemment correspondant aux données primaires 404. Dans d’autres exemples, le sous-système en aval 132 peut omettre la transmission de la requête 704 et reposer seulement sur les données primaires reçues via le message de rapport 600 et les données auxiliaires provenant du serveur d’intermédiation 120. 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 publication 124 ne reflétera pas l’ajustement défini dans les données auxiliaires 408 qui ont résulté des données primaires 404. Par exemple les données récupérées du sous-système de publication 124 pour le vol Paris-NYC, montrées dans les tableaux 1 et 2 peuvent contenir uniquement le prix original sans remise de 1187,50 $ et non le prix défini dans les données primaires 404. Lorsque la détermination au bloc 325 est négative, le serveur d’intermédiation 120 peut répéter l’exécution du bloc 325. Lorsque la détermination au bloc 325 est affirmative, le serveur d’intermédiation 120 poursuit au bloc 330. Au bloc 330, le serveur 120 récupère au moins les données auxiliaires 408 du répertoire 140 et envoie les données auxiliaires 408 au sous-système en aval 132, ainsi que l’identifiant de commande 508. Les données auxiliaires 408 seules peuvent être envoyées au bloc 330, ou l’enregistrement entier (c.-à-d. les données primaires 404 et les données auxiliaires 408) peut être transmis au bloc 330. Le sous-système en aval 132 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 aval 132, soit directement ou via le sous-système de rapport 136. Au bloc 335, suite à la transmission des données auxiliaires au bloc 330, le serveur d’intermédiation 120 peut déterminer s’il doit supprimer l’enregistrement contenant les données primaires 404 et les données auxiliaires 408 dans le répertoire 140. La détermination au bloc 335 peut être basée sur divers critères. Dans certains exemples, la détermination au bloc 335 peut être automatiquement affirmative une fois que les données auxiliaires ont été fournies au sous-système en aval 132. Dans d’autres exemples, la détermination au bloc 335 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épertoire 140. Dans d’autres exemples, une combinaison des critères ci-dessus peut être appliquée. C’est-à-dire, que le serveur d’intermédiation 120 peut déterminer si les données auxiliaires 408 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 bloc 335 est négative, le serveur d’intermédiation 120 peut répéter la détermination ou peut retourner au bloc 325 pour attendre d’autres requêtes pour les données auxiliaires. Par exemple, d’autres composants du système 100 peuvent aussi être capables de demander les données auxiliaires 408 du serveur d’intermédiation 120, incluant le sous-système client 104 et les autres sous-systèmes de fournisseurs (p. ex. les vols interlignes). Le serveur d’intermédiation 120 peut implémenter des contrôles d’accès pour le répertoire 140 de sorte que seulement certaines entités soient autorisées à accéder aux données d’offres 400. Par exemple, le répertoire 140 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 bloc 355 est affirmative, l’enregistrement contenant les données primaires 404, les données auxiliaires 408 et identifiant de commande 508 est supprimé du répertoire 140. Les hommes de métier apprécieront que dans certains modes de réalisation, la fonctionnalité des applications 212, 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. 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 revendication 1, 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 revendication 1 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 revendications 1 à 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 revendications 1 à 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 revendications 1 à 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 revendication 2, 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 revendication 7, 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 revendication 9, 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 revendication 9 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 revendications 9 à 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 revendications 9 à 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 revendications 9 à 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 revendication 10, 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 revendication 15, 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 revendications 1 à 8 lorsque ledit programme fonctionne sur un ordinateur.