Brevet FR3096800A1 — publié le 20201204

Description Titre de l'invention : Système et procédé pour intégrer des objets de données hétérogènes [0001] De manière générale, la spécification concerne des systèmes informatiques, et spéci- fiquement un système et. procédé pour intégrer des objets de données hétérogènes. Contexte [0002] L'obtention de certains types de données générées peut s'effectuer via deux ou plus mécanismes de génération distincts impliquant des sous-systèmes informatiques séparés, des protocoles de communication et similaires. Cependant, des sous-ensembles de telles données générées obtenus via différents mécanismes peuvent néanmoins être associés. Par exemple, en rapport avec des éléments tels que des produits et services liés au voyage (par ex., des vols, des réservations d'hôtels et similaires), un itinéraire pour un client donné peut inclure une pluralité de vols, dont certains sont obtenus via un premier mécanisme de génération et d'autre sont obtenus via un deuxième mécanisme de génération. Parce que les mécanismes de génération sont indépendants les uns des autres, l'affichage et l'application de mises à jour aux sous-ensembles de données en résultant peuvent être arrangés par des interfaces indépendantes. Résumé 100031 Un aspect de la spécification fournit un procédé d'intégration d'objets de données, le procédé comprenant : le stockage, à un serveur d'intermédiation, (i) d'un enregistrement d'origine contenant un premier identifiant unique et un premier ensemble de champs de données définissant un premier élément fourni par un premier fournisseur, et (ii) un enregistrement de destination contenant un deuxième identifiant unique et un deuxième ensemble de champs de données définissant un deuxième élément fourni par un deuxième fournisseur ; la réception au serveur d'intermédiation, à partir d'un dispositif client, d'une instruction pour fusionner l'enregistrement d'origine dans l'enregistrement de destination, la demande contenant les premier et deuxième identifiants uniques ; en réponse à la réception de l'instruction, la mise à jour de l'enregistrement de destination en : (i) comparant le premier ensemble de champs de données au deuxième ensemble de champs de données ; et (ii) pour chaque champ de données du premier ensemble qui correspond à un champ de données correspondant du deuxième ensemble, en marquant le champ donné correspondant du deuxième ensemble comme étant un champ partagé ; et en envoyant l'enregistrement de destination mis à jour au dispositif client pour affichage. 100041 La comparaison du premier ensemble de champs de données au deuxième ensemble 2 de champs de données peut inclure : la récupération d'un mappage de champ identifiant, pour chacun du premier ensemble de champs de données, un champ correspondant du deuxième ensemble ; et la comparaison de chacun du premier ensemble de champs de données au champ correspondant du deuxième ensemble, selon le mappagc de champ. [0005] Le procédé peut par ailleurs inclure le stockage du premier identifiant unique en as- sociation avec l'enregistrement de destination mis à jour. [0006] Le procédé peut par ailleurs inclure : pour chaque champ de données du premier ensemble qui ne correspond pas à un champ de données correspondant du deuxième ensemble selon la comparaison, la création d'un champ de données fusionné dans l'enregistrement de destination. [0007] Le procédé peut par ailleurs inclure le stockage, dans chaque champ de données fusionné, d'une indication selon laquelle le champ des données fusionné est associé à l'enregistrement d'origine. [0008] L'indication selon laquelle le champ des données fusionné est associé à l'enregistrement d'origine peut inclure le premier identifiant unique. [0009] Le marquage du champ de données correspondant du deuxième ensemble comme étant un champ partagé peut inclure l'une des actions suivantes : (i) stocker une balise dans le champ de données correspondant du deuxième ensemble ; et (ii) stocker, dans un enregistrement d'intégration distincte de l'enregistrement d'origine et de l'enregistrement de destination, des identifiants du champ de données du premier ensemble et du champ de données correspondant du deuxième ensemble. [0010] La comparaison peut inclure : la détermination, pour chaque champ de données du premier ensemble et le champ de données correspondant du deuxième ensemble, d'une métrique de similarité ; et la détection d'une correspondance entre le champ des données du premier ensemble et le champ de données correspondant du deuxième ensemble lorsque la métrique de similarité est au-dessus d'un seuil. [0011] Un aspect de la spécification fournit un serveur d'intermédiation comprenant : une interface de communication ; une mémoire stockant (i) un enregistrement d'origine contenant un premier identifiant unique et un premier ensemble de champs de données définissant un premier élément fourni par un premier fournisseur, et (ii) un enregistrement de destination contenant un deuxième identifiant unique et un deuxième ensemble de champs de données définissant un deuxième élément fourni par un deuxième fournisseur ; et un processeur connecté à l'interface de communication et à la mémoire, le processeur configuré pour : recevoir, à partir d'un dispositif client via l'interface de communication, une instruction pour fusionner l'enregistrement d'origine dans l'enregistrement de destination, la demande contenant les premier et deuxième identifiants uniques ; en réponse à la réception de l'instruction, afin de 3 mettre à jour l'enregistrement de destination : (i) comparer le premier ensemble de champs de données au deuxième ensemble de champs de données ; et (ii) pour chaque champ de données du premier ensemble qui correspond à un champ de données correspondant du deuxième ensemble, marquer le champ données correspondant du deuxième ensemble comme étant un champ partagé ; et envoyer l'enregistrement de destination mise à jour au dispositif client pour affichage. [0012] Le processeur peut par ailleurs être configuré, afin de comparer le premier ensemble de champs de données au deuxième ensemble de champs de données pour : récupérer un mappage de champ identifiant, pour chacun du premier ensemble de champs de données, un champ correspondant du deuxième ensemble ; et comparer chacun du premier ensemble de champs de données au champ correspondant du deuxième ensemble, selon le mappage de champ. [0013] Le processeur peut par ailleurs être configuré pour stocker, dans la mémoire, le premier identifiant unique en association avec l'enregistrement de destination mis à jour. [0014] Le processeur peut par ailleurs être configuré pour : pour chaque champ de données du premier ensemble qui ne correspond pas à un champ de données correspondant du deuxième ensemble selon la comparaison, créer un champ de données fusionné dans l'enregistrement de destination. [0015] Le processeur peut par ailleurs être configuré pour stocker, dans chaque champ de données fusionné, une indication selon laquelle le champ des données fusionné est associé à l'enregistrement d'origine. [0016] L'indication selon laquelle le champ des données fusionné est associé à l'enregistrement d'origine peut inclure le premier identifiant unique. [0017] Le processeur peut par ailleurs être configuré, afin de marquer le champ de données correspondant du deuxième ensemble comme étant un champ partagé; pour exécuter l'une des actions suivantes : (i) stocker une balise dans le champ de données correspondant du deuxième ensemble ; et (ii) stocker, dans un enregistrement d'intégration distinct de l'enregistrement d'origine et de l'enregistrement de destination, des identifiants du champ de données du premier ensemble et du champ de données correspondant du deuxième ensemble. [0018] Le processeur est par ailleurs configuré pour, afin de comparer le premier ensemble de champs de données au deuxième ensemble de champs de données, pour : déterminer, pour chaque champ de données du premier ensemble et le champ de données correspondant du deuxième ensemble, une métrique de similarité ; et détecter une correspondance entre le champ des données du premier ensemble et le champ des données correspondant du deuxième ensemble lorsque la métrique de similarité est au-dessus d'un seuil. 100191 Un aspect de la spécification fournit un support durable lisible par ordinateur stockant les instructions lisibles par ordinateur, exécutables par un processeur d'un serveur d'intermédiation pour : stocker, à un serveur d'intermédiation, (i) un enregistrement d'origine contenant un premier identifiant unique et un premier ensemble de champs de données définissant un premier élément fourni par un premier fournisseur, et (ii) un enregistrement. de destination contenant un deuxième identifiant unique et un deuxième ensemble de champs de données définissant un deuxième élément fourni par un deuxième fournisseur ; et. recevoir à partir d'un dispositif client via une interface de communication du serveur d'intermédiation, une instruction pour fusionner l'enregistrement d'origine dans l'enregistrement de destination, la demande contenant les premier et deuxième identifiants uniques ; en réponse à la réception de l'instruction, afin de mettre à jour l'enregistrement de destination : (i) comparer le premier ensemble de champs de données au deuxième ensemble de champs de données ; et (ii) pour chaque champ de données du premier ensemble qui correspond à un champ de données correspondant du deuxième ensemble, marquer le champ donné correspondant du deuxième ensemble comme étant un champ partagé ; et envoyer l'enregistrement de destination mis à jour au dispositif client pour affichage. [0020] Les instructions lisibles par ordinateur peuvent par ailleurs amener le processeur du serveur d'intermédiation à implémenter les étapes du procédé scion l'un quelconque des aspects du procédé exposés ci-dessus. [0021] Un autre aspect de la spécification fournit un produit programme d'ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour exécuter les étapes du procédé selon l'un quelconque des aspects du procédé exposés ci-dessus lorsque ledit programme est exécuté sur un ordinateur. Brève description des dessins [0022] Des modes de réalisation sont décrits en références aux figures suivantes, dans lesquels : [0023] [fig.1] est un diagramme illustrant un système pour fournir un accès aux données aux il iaires. [0024] [fig.2] est un diagramme illustrant certains composants internes du sous-système de client et du sous-système de fournisseur de la FIG. 1. [0025] [fig.3] est un organigramme d'un procédé d'intégration d'objets de données hé- térogènes ; [0026] [fig.4] est un diagramme illustrant une exécution du bloc 305 du procédé de la FIG. 3. [0027] [fig.5] est un diagramme illustrant un autre aspect de l'exécution du bloc 305 du procédé de la FIG. 3. 100281 Ifig.61 est un diagramme illustrant une exécution du bloc 330 du procédé de la FIG. 3. [0029] [fig.7] est un diagramme illustrant une exécution du bloc 335 du procédé de la FIG. 3. [0030] [fig.8] est un diagramme illustrant une exécution du bloc 345 du procédé de la FIG. 3; et [0031] [fig.9] est un diagramme illustrant une autre implémentation exemplaire du procédé de la FIG. 3. Description détaillée [0032] La FIG. 1 décrit un système 100 pour intégrer des objets de données hétérogènes. Dans le système 100, divers sous-systèmes informatiques interagissent pour générer et traiter des données concernant l'une quelconque d'une grande variété d'activités. Dans les exemples discutés ci-dessous, les sous-systèmes du système 100 interagissent pour générer et traiter des données liées à la fourniture d'éléments aux clients. Les éléments, dans les exemples ci-dessous, sont des produits et services liés au voyage, tels que des billets d'avion, des réservations d'hôtel, des réservations de location de véhicules, et similaires. Une grande variété d'autres activités peut être activée par l'échange de données entre les sous-systèmes présentés du système 100, la nature spécifique des données traitées dans le système 100 n'est pas particulièrement limitée. [0033] Dans l'exemple illustré, le système 100 inclut un sous-système de client 104, exploité par une entité de client qui peut également être appelée un vendeur. Le vendeur peut être, par exemple, une agence de voyages. Le sous-système de client 104 génère des demandes, par ex. pour le compte de clients, d'éléments de voyage. Les demandes précises diverses caractéristiques des éléments de voyage, tels que les lieux d'origine et de destination, les heures et les dates de voyage, et similaires. Les réponses aux demandes provenant du sous-système de client 104 sont générées par, ou pour le compte, des entités qui fournissent les éléments, appelés dans les présentes fournisseurs. Par conséquent, dans le présent exemple, les fournisseurs sont des entités telles que des compagnies aériennes, des exploitants d'hôtels ou similaires qui fournissent les éléments au client, ou à d'autres entités pour fourniture éventuelle au client, suite à l'achat des éléments (ledit achat étant effectué, par exemple, via le sous-système de client 104). [0034] Chaque entité de fournisseur exploite un sous-système de fournisseur 108 ; deux sous-systèmes de fournisseur exemplaires 108-1 et 108-2 sont présentés à la FIG. 1. Chacun du sous-système de client 104 et des sous-systèmes de fournisseur 108 sont implémentés comme étant au moins un dispositif informatique avec des ensembles d'entrée et de sortie et des dispositifs de communication pour échanger des données 6 via un réseau 112. Le réseau 112 peut inclure une quelconque combinaison appropriée de réseaux locaux et étendus, y compris Internet. Bicn qu'un seul sous-système de client 104 et deux sous-systèmes de fournisseur 108 soient présentés à la FIG. 1, le système 100 peut inclure un plus grand ou un plus petit nombre de sous-systèmes de clients 104 et sous-systèmes de fournisseur 108 dans d'autres exemples. [0035] La génération de réponses aux demandes provenant du sous-système de client 104 peut prendre diverses formes. Dans l'exemple illustré, les sous-systèmes de fournisseur 108-1 est supposée générer des réponses à de telles demandes localement, bien que, comme on le verra ci-dessous, les demandes ne soient pas transmises directement du sous-système de client 104 au sous-système de fournisseur 108-1. C'est-à-dire que, le sous-système de fournisseur 108-1 inclut un module de génération d'offres (par ex., les instructions lisibles par ordinateur et le matériel d'exécution correspondant, ainsi que diverses données stockées destinées à être utilisées dans la génération de réponses) qui permet au sous-système de fournisseur 108-1 de générer des données de réponse basées sur les caractéristiques précisées dans la demande provenant du sous-système de client 104. Les données de réponse peuvent également être appelées « données d'offres », et définissent un ou plusieurs éléments qui correspondent ou correspondent partiellement aux caractéristiques demandées. [0036] D'autres sous-systèmes de fournisseur 108, tels que les sous-systèmes de fournisseur 108-2 dans le présent exemple, ne peuvent pas générer des réponses aux demandes provenant du sous-système de client 104. Au lieu de cela, de telles réponses peuvent être générées par un sous-système de distribution 116. Le sous-système de fournisseur 108-2 peut, par exemple, envoyer des données définissant les éléments offerts par l'entité de fournisseur qui exploite le sous-système de fournisseur 108-2 à un sous-système de publication 120. Le sous-système de publication 120 peut être exploité par une tierce partie (c.-à-d. distincte des entités de fournisseur susmentionnées), et peut recevoir des données d'éléments publiés telles que des horaires de vols, des tarifs et similaires, provenant d'un ou de plusieurs sous-systèmes de fournisseur 108. Le sous-système de distribution 120, à son tour, peut récupérer des données provenant du système de publication 120 destinées à être utilisées pour générer des réponses aux demandes provenant du sous-système de client 104 pour le compte du sous-système de fournisseur 108-2. [0037] Dans certains exemples, les sous-systèmes de fournisseur 108 ne doivent pas être limités à l'utilisation d'un mécanisme ou de l'autre. Par exemple, les éléments représentant des données fournis par l'exploitant du sous-système de fournisseur 108-1 peuvent être obtenus via l'un ou l'autre des mécanismes susmentionnés. Dans d'autres exemples, le sous-système de fournisseur 108-2 peut également être capable de générer des réponses aux demandes des clients localement. 7 [0038] Comme cela apparaîtra maintenant aux hommes de métier, la génération et la transmission de demandes par le dispositif client 104 et la génération de données de réponse par ou pour les sous-systèmes de fournisseur 108 peuvent être exécutés selon l'un ou l'autre des dcux mécanismes distincts. Le premier mécanisme implique la génération de données de réponse localement par un sous-système de fournisseur 108, et le deuxième mécanisme implique la génération de données de réponse par une tierce partie (par ex., le sous-système de distribution 116), par exemple sur la base des données précédemment publiées par le sous-système de fournisseur 108 (par ex., stockées par le système de publication 120). [0039] De plus, les mécanismes distincts par lesquels les données de réponse peuvent être générées et fournies au sous-système de client 104 peuvent impliquer l'utilisation de normes d'échange de données distinctes, de protocoles de communication et similaires. Par exemple, le premier mécanisme susmentionné, dans lequel les données de réponse sont générées par le sous-système de fournisseur 108-1 lui-même, peut être implémenté selon la Nouvelle norme de Capacité de Distribution (NDC). La norme NDC précise un format de données basé sur le langage de Balisage eXtensible (XML) (par ex. la précision d'une syntaxe de message, d'appels API et similaires) pour des messages échangés entre les sous-systèmes de client 104 et les sous-systèmes de fournisseur 108. Le deuxième mécanisme, en revanche, dans lequel les données de réponse sont générées par le sous-système de distribution 116, peut être implémenté sous la forme d'un Système de Distribution Global (GDS). Le deuxième mécanisme, par conséquent, peut employer une syntaxe de message, le séquençage et similaire comme précisé par la norme sur l'Échange de données électroniques pour l'administration, le commerce et le transport (EDIFACT). [0040] En d'autres termes, les éléments définissant des données peuvent être obtenus par le sous-système de client 104 via l'un ou l'autre ou les deux mécanismes distincts, chacun d'entre eux implique des interactions par des sous-systèmes informatiques distincts selon des protocoles de communication séparés, la syntaxe de message et similaires. Par conséquent, les données définissant de tels éléments ne peuvent pas être disponibles sur le sous-système de client 104 dans un format cohérent. Le sous-système de client 104 peut par conséquent acquérir des données définissant un premier sous-ensemble d'éléments via le premier mécanisme, et des données définissant le deuxième sous-ensemble d'éléments via le deuxième mécanisme. Cependant, de telles données peuvent être obtenues pour le compte d'un client commun ; dans un système précédent, le sous-système de client 104 peut être incapable d'afficher ou de présenter autrement les données ci-dessus simultanément. [0041] Le système 100 implémente par conséquent une fonctionnalité supplémentaire pour permettre au sous-système de client 104 de récupérer et d'afficher, simultanément, un 8 ensemble de données liées qui étaient générées via l'un ou l'autre ou les deux mécanismes ci-dessus. C'est-à-dire que le système 100 permet la fourniture d'une interface commune au sous-système de client 104 pour voir les données obtenues via ou l'autre ou les deux mécanismes. Le système 100 permette également au sous-système de client 104 de faire des mises à jour des données d'éléments à partir de l'interface commune, quel que soit le mécanisme par lequel les données ont été générées (et par conséquent quel que soit le mécanisme employé pour mettre à jour les données). [0042] Comme noté ci-dessus, le sous-système de client 104 n'interagit pas directement avec le sous-système de fournisseur 108-1. Dans le présent exemple, le sous-système de client 104 n'interagit pas non plus directement avec le sous-système de distribution 116. Le système 100 inclut plutôt un serveur d'intermédiation 124, et les demandes générées par le sous-système de client 104 sont transmises via le réseau 112 au serveur d'intermédiation 124. Le serveur d'intermédiation 124 reçoit des demandes provenant du sous-système de client 104, et passe de telles demandes aux sous-systèmes de fournisseur 108 et/ou au sous-système de distribution 116. Le serveur d'intermédiation 124 reçoit également des réponses provenant des sous-systèmes de fournisseur 108 et/ou du sous-système de distribution 116, pour retour au sous-système de client 104. [0043] Le serveur d'intermédiation 124, dans l'exemple illustré, héberge des données dé- finissant des éléments pour le sous-système de client 104, en plus de relayer les données entre le sous-système de client 104 et d'autres sous-systèmes présentés à la FIG. 1. Le sous-système de client 104, en d'autres termes, ne peut pas stocker des copies persistantes de données définissant des éléments localement. Au lieu de cela, le sous-système de client 104 peut (par ex., suite à un quelconque processus d'authentification approprié) accéder à de telles données stockées au serveur d'intermédiation 124. Le serveur d'intermédiation 124 conserve deux répertoires 128 et 132, chacun contenant des enregistrements de données d'éléments générées via le premier et le deuxième mécanisme, respectivement. Par exemple, le répertoire 128 dans le présent exemple contient des données d'éléments obtenues via le premier mécanisme (par ex. selon la norme NDC susmentionnée), et le répertoire 132 contient des données d'éléments obtenues via le deuxième mécanisme (par ex. selon la norme GDS susmentionnée). [0044] Dans d'autres exemples, le serveur d'intermédiation 124 peut stocker les données d'éléments ci-dessus dans un seul répertoire, avec chaque enregistrement incluant une balise ou autre indicateur du mécanisme par lequel les données dans ledit répertoire ont été acquises. Dans un quelconque événement, comme discuté plus en détail ci-dessous, le serveur d'intermédiation 124 peut intégrer un enregistrement à partir du deuxième 9 répertoire 132 dans un enregistrement provenant du premier répertoire 128 pour permettre la présentation des données à partir des deux enregistrements au sous-système de client 104 dans une interface commune. [0045] Avant de discuter plus amplement des fonctionnalités des divers composants du système 100, certains composants internes du serveur d'intermédiation 124 seront décrits en lien avec la FIG. 2. [0046] Passons à la FIG. 2, le serveur d'intermédiation 124 inclut au moins un processeur 200, tel qu'une unité de traitement centrale (CPU) ou similaire. Le processeur 200 est interconnecté à une mémoire 204 implémentée sous la forme d'un support durable, lisible par ordinateur (par 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 similaires). Le processeur 200 et la mémoire 204 sont généralement composés d'un ou de plusieurs circuits intégrés (ICs). [0047] Le processeur 200 est également interconnecté à une interface de commu- nication 208, qui permet au serveur 124 de communiquer avec les autres dispositifs informatiques du système 100 via le réseau 112. L'interface de communication 208 inclut par conséquent tous les composants nécessaires (par ex. des contrôleurs d'interface de réseau (NICs), des unités de radio, et similaires) pour communiquer via le réseau 112. Les composants spécifiques de l'interface de communication 208 sont sélectionnés sur la base de la nature du réseau 112. Le serveur 124 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 autres similaires (non présentés). [0048] Les composants du serveur 124 mentionnés ci-dessus peuvent être déployés dans une seule enceinte ou sous un format distribué. Par conséquent dans certains exemples, le serveur 124 inclut une pluralité de processeurs qui partagent la mémoire 204 et l'interface de communication 208, ou qui ont chacun des interfaces de communication et des mémoires associées distinctes. [0049] La mémoire 204 stocke les répertoires 128 et 132 susmentionnés, ainsi que des ins- tructions lisibles par ordinateur, exécutables par le processeur 200 pour implémenter diverses fonctionnalités. Les instructions lisibles par ordinateur peuvent également être appelées applications, et dans l'exemple illustré, la mémoire 204 stocke une application de traitement des demandes 212 est une application d'intégration de contenu 216 (également appelées simplement dans les présentes les applications 212 et 216, respectivement). Dans la description ci-dessous, le processeur 200, et plus généralement le serveur 124, sont conçus pour exécuter, ou pour être configurés pour exécuter, 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. [0050] L'exécution de l'application 212 par le processeur 200 configure le serveur 124 pour recevoir des demandes provenant du sous-système de client 104 et interagir avec un ou plusieurs des sous-systèmes de fournisseur 108 et du sous-système de distribution 116 pour obtenir des données de réponse pour les stocker dans le répertoire 128 et/ou 132. L'exécution de l'application 212 configure également le serveur 124 pour fournir l'interface commune susmentionnée au sous-système de client 104, à partir duquel l'interface client peut générer des demandes de données d'éléments (ou des demandes de mise à jour des données d'éléments) via l'un ou l'autre des mécanismes mentionnés précédemment. [0051] Via l'exécution de l'application 212, par exemple, le serveur d'intermédiation 124 peut implémenter une fonctionnalité comme exposé dans l'application également en attente du Demandeur n°FR 1905718 pour fournir l'interface commune. Une telle fonctionnalité inclut la fourniture de définitions d'objets de données et la mise à jour de définitions qui permettent de stocker des données dans un format commun, agrégé quelle que soit la source desdites données (c.-à-d. si les données ont été acquises via le premier mécanisme ou le deuxième mécanisme). Par exemple, les données peuvent être stockées dans un format commun, quel que soit le mécanisme d'origine, dans le répertoire 128. Le répertoire 128 peut par conséquent être appelé le répertoire primaire ou de destination dans la discussion ci-dessous [0052] Cependant, dans d'autres exemples, le sous-système de client 104 peut initier l'acquisition de données d'éléments via le deuxième mécanisme mentionné plus tôt (par ex. via le GDS). Le serveur d'intermédiation 124 , par exemple, également inclure une autre application (non présentée) qui permet au sous-système de client 104 de demander explicitement des données d'éléments obtenues via le sous-système de distribution 116 qui est stocké dans le répertoire 132 et n'est par conséquent pas disponible via l'interface commune susmentionnée. [0053] Le serveur 124 est par conséquent également configuré, via l'exécution de l'application d'intégration 216, pour intégrer des données provenant du répertoire 132 dans le répertoire 128 sur les instructions du sous-système de client 104. Une quelconque donnée intégrée par l'application 216 est rendue disponible via l'interface commune susmentionnée, et peut par conséquent être vue et mise à jour par le sous-système de client 104 en même temps que les données obtenues via le premier mécanisme (par ex. NDC). [0054] Passons à présent à la FIG. 3, certains aspects de l'exploitation du système 100 seront décrits plus en détail. Spécifiquement, la FIG. 3 illustre un procédé 300 d'intégration d'objets de données hétérogènes. L'exécution du procédé 300 sera discutée en rapport avec son exécution dans le système 100et spécifiquement par le serveur 11 d'intermédiation 124 via l'exécution de l'application d'intégration 216. [0055] Au bloc 305, le serveur 124 reçoit une demande, à l'interface de communication 208, provenant du sous-système de client 104 pour fusionner ou intégrer des enregistrements contenant des données générées via des mécanismes distincts. En particulier, la demande inclut une instruction pour fusionner un enregistrement à partir du répertoire 128 avec un enregistrement provenant du répertoire 132. L'enregistrement provenant du répertoire 128 est également appelé l'enregistrement de destination, dans la mesure où le produit final de l'opération de fusion sera stocké dans l'enregistrement de destination. Pendant ce temps, l'enregistrement provenant du répertoire 132 est également appelé enregistrement d'origine, dans la mesure où les données provenant de l'enregistrement d'origine sont importées dans l'enregistrement de destination (par ex. comme indiqué par les flèches connectant l'application 216 aux répertoires 128 et 132 à la FIG. 2). [0056] Passons brièvement à la FIG. 4, une exécution exemplaire du block 305 est présentée. Le système 100 est présenté sous une forme simplifiée à la FIG. 4, omettant tout sauf le sous-système de client 104, le réseau 112 et le serveur 124. Une demande 400 est transmise à partir du sous-système de client 104 au serveur 124 via le réseau 112, contenant un identifiant d'enregistrement d'origine « GHiJKL » et un identifiant d'enregistrement de destination « ABCDEF ». La demande peut avoir une grande variété de formats au-delà de ceux présentés à la FIG. 4. [0057] Les enregistrements avec les identifiants ci-dessus sont également présentés à la FIG. 4. En particulier, le répertoire 128 contient un enregistrement 402 (enregistrement de destination), ayant un identifiant d'enregistrement 404 et des champs ou sous-ensembles de champs 408 et 412. De plus, l'enregistrement 402 contient un champ indicateur de type de contenu 416 indiquant quel mécanisme de génération a été employé pour générer les données dans le champ ou l'ensemble 412. Le répertoire 132 contient un enregistrement 418 ayant un identifiant d'enregistrement 420 et des champs ou ensembles de champs 424 et 428. Le contenu des enregistrements 402 et 418 sera discuté plus en détail. En général, la demande 400 est une instruction au serveur 124 pour intégrer dans l'enregistrement 402 les données stockées dans l'enregistrement 418, afin de permettre la visualisation et la mise à jour des données à partir des deux enregistrements 402 et 418 via l'interface commune susmentionnée. [0058] Revenons à la FIG. 3, ayant reçu la demande au bloc 305, le serveur 124 récupère les enregistrements pertinents (c.-à-d. les enregistrements 402 et 414 dans l'exemple illustré à la FIG. 4) les stocks identifiant d'enregistrement d'origine 420 dans l'enregistrement de destination 402: Ainsi, dans le présent exemple, comme présenté à la FIG. 5, un enregistrement de destination mis à jour 402a est généré à partir de l'enregistrement de destination 402. L'enregistrement de destination mis à jour 402a 12 inclut les contenus précédents de l'enregistrement 402, ainsi qu'un identifiant d'enregistrement d'origine 500. L'identifiant d'enregistrement d'origine 500 permette au serveur 124 de continuer à interagir avec, par exemple, le sous-système de distribution 116 pour mettre à jour les données importées de l'enregistrement 418 même après que l'intégration soit terminée. [0059] Au bloc 310, le serveur 124 sélectionne un ensemble de champs à partir de l'enregistrement 418 pour l'intégrer dans l'enregistrement 402a. Par exemple, le serveur 124 peut sélectionner le champ « nom » 424 pour intégration lors d'une première exécution du bloc 310. Au bloc 315, le serveur 124 détermine si le champ sélectionné dans l'enregistrement d'origine 418 correspond à un champ correspondant dans l'enregistrement de destination 402a. Le champ correspondant dans l'enregistrement de destination 402a peut être identifié au moyen d'un mappage de champ stocké, conservé au serveur 124. Chacun des enregistrements du répertoire 128 a la même population de champs, bien que le contenu de ces champs varie d'un enregistrement à l'autre, et certains champs peuvent être répétés à plusieurs reprises (par ex. pour représenter de multiples éléments liés). De manière similaire, chacun des enregistrements du répertoire 132 a la même population de champs, bien que la structure de ces champs puisse varier à partir des champs des enregistrements dans le répertoire 128. [0060] Le serveur 124 peut stocker un mappage de champ préconfiguré qui établit quels champs d'un quelconque enregistrement donné dans le répertoire 128 correspondent à quels champs d'un quelconque enregistrement donné dans le répertoire 132. En d'autres termes, le mappage de champ indique quels champs dans les répertoires 128 et 132 contiennent des données de types correspondants. Par exemple, le mappage de champ dans le présent exemple peut indiquer que les champs 408 dans le répertoire 128 (contenant des noms de voyageurs) mappent sur les champs 424 dans le répertoire 132 (qui contient également des noms de voyageurs). [0061] Ainsi, au bloc 315, le serveur 124 compare les contenus du champ 408 comme illustré aux FIGS. 4 et 5 avec les contenus du champ 424 comme illustré aux FIGS. 4 et 5. La détermination au bloc 315 peut déterminer si les champs correspondent exactement. Cependant, dans le présent exemple le serveur 124 est également configuré pour détecter des collisions de donnés éventuelles, dans lesquelles les champs qui ne correspondent pas exactement devraient en fait être fusionnés en un seul champ. Par conséquent, au bloc 315 le serveur 124 peut générer une métrique de similarité (par ex. également appelée une fonction de distance de chaîne) à partir des champs sélectionnés. Par exemple, la métrique peut indiquer en pourcentage à quel point le contenu des champs comparés est similaire, 100 % indiquant une correspondance exacte. La détermination au bloc 315 peut être affirmative lorsque la 13 métrique de similarité dépasse un seuil prédéfini (par ex. 80 %), et autrement négative. [0062] Comme vu à la FIG. 5, dans le présent exemple, la détermination est supposée être affirmative parce que, bien que les noms présentés dans les champs 408 et 424 ne correspondent pas exactement, ils sont séparés uniquement par trois caractères (« R », un point et un espace entre le premier et le dernier nom « Adam » et « Toto »). Le serveur 124 passe par conséquent au bloc 320. [0063] Au bloc 320, le serveur 124 détermine si les champs sélectionnés correspondent exactement. Par exemple, le serveur 124 peut déterminer si la métrique susmentionnée est 100 %. Lorsque la détermination au bloc 320, comme dans l'exemple illustré aux FIGS. 4 et 5, le serveur 124 passe au bloc 325. Au bloc 325, le serveur 124 peut générer un avertissement, tel qu'une invitation envoyée au sous-système de client 104 demandant une action de l'exploitant pour selectionner une des valeurs disponibles (par ex. « Adam Toto » ou « Adam R. Toto ») pour la stocker dans l'enregistrement fusionné. Le serveur 124 attend une entrée provenant du sous-système de client 104 qui effectue une telle sélection. [0064] Dans la présente exécution exemplaire du procédé 300, on suppose que le sous- système de client 104, en réponse à l'invitation générée au bloc 325, transmet une sélection de la chaîne « Adam R. Toto » pour être utilisée dans le champ fusionné. Par conséquent, au bloc 330, le serveur 124 ne met pas à jour les contenus du champ 408, niais marque le champ 408 comme étant un champ partagé, par exemple avec une balise 600, comme présenté à la FIG. 6. La FIG. 6 illustre une autre version mise à jour de l'enregistrement 402, appelée 402b. La balise 600 indique que le champ 408 est associé au contenu obtenu via les cieux mécanismes susmentionnés. Dans certains exemples, serveur 124 peut également être configuré pour envoyer une instruction via le deuxième (par ex. basé sur un GDS) mécanisme pour mettre à jour le nom stocké dans le champ 424 afin de refléter le nom tel que stocké dans le champ 408. Lorsque les deux versions du nom (par ex. comme présenté dans les champs 408 et 424) sont retenues, une quelconque instruction envoyée via le deuxième mécanisme utilise le nom tel que présenté dans le champ 424. [0065] Suite à l'exécution du bloc 330, le serveur 124 passe au bloc 340 et détermine si des champs ou ensembles de champs restent à traiter. Lorsque la détermination est affirmative au bloc 340, serveur 124 passe au bloc 310 et sélectionne le prochain champ dans l'enregistrement d'origine 418, par ex. le champ 428. Dans le présent exemple, le mappage de champ est supposé indiquer que les champs « segment » dans les enregistrements d'origine du répertoire 132 correspondent aux champs « éléments » dans les enregistrements de destination du répertoire 128. Par conséquent, au bloc 315 le champ 428 est comparé au champ 412 comme décrit ci-dessus en rapport avec les champs 424 et 408. 14 [0066] Comme cela est visible à partir des FIGS. 4-6, les valeurs stockées dans les champs 428 et 412 ont peu en commun. Le champ 412 stocke un identifiant pour un vol Lufthansa, tandis que le champ 428 stocke un identifiant pour un vol British Airways. Les champs 412 et 428 peuvent inclure des sous-champs ou champs associés contenant, par exemple, des informations tarifaires, les lieux d'origine et de destination, et similaires. De tels champs peuvent également être comparés selon le mappage de champ. Cependant, dans d'autres exemples, seulement une valeur principale (telle que les identifiants de vol susmentionnés) peut être comparée au bloc 315, et les sous-champs ou champs associés peuvent tous être traités selon la détermination basée sur le champ principal. [0067] Suite à une détermination négative au bloc 315, serveur 124 passe au bloc 335. Au bloc 335, le serveur 124 génère un nouveau champ fusionné dans l'enregistrement de destination 402, et y insère le contenu du champ d'origine (c.-à-d. le champ 428 dans cet exemple) La FIG. 7 illustre le résultat d'une exécution du bloc 335. En particulier, l'enregistrement 402h a été mis à jour en un enregistrement 402c, contenant (en plus du contenu mentionné précédemment) un champ 700 qui contient l'identifiant de vol importé à partir du champ 428 de l'enregistrement 418. De plus, comme le montre la FIG. 7, le serveur 124 peut marquer le champ fusionné 700 comme étant associé à l'enregistrement d'origine. Dans l'exemple illustré, le marquage est exécuté en stockant une balise 704 avec le champ 700 qui indique le canal de distribution (c.-à-d. le mécanisme de génération) via lequel le contenu du champ 700 a été obtenu. Cependant, d'autres manières de marquer le champ 700 sont également observées. Par exemple, l'identifiant « GHIJKL » lui-même de l'enregistrement 418 peut être utilisé comme une balise associée au champ 700. [0068] La création d'un champ tel que le champ 700 au bloc 335 peut inclure la trans- formation des données dans le champ 428 selon les exigences de format et de syntaxe du répertoire 128. Une telle transformation peut être exécutée selon les définitions d'objets de données susmentionnées est décrite en détail dans l'application également en attente FR 1905718. [0069] Le processus ci-dessus est répété jusqu'à ce qu'une détermination négative résulte du bloc 340, indiquant que la totalité de l'enregistrement d'origine 418 a été intégrée dans l'enregistrement de destination 402. Le serveur 124 passe alors au bloc 345, auquel le serveur 124 peut transmettre l'enregistrement mis à jour 402c au sous-système de client 104 pour l'affichage simultané du contenu obtenu via les deux mécanismes de génération. Dans certains exemples, l'enregistrement 418 est éliminé ou marqué comme étant inactif lorsque la génération de l'enregistrement 402c est terminée. [0070] Le système 100 permet par conséquent la visualisation commune et l'édition des données au sous-système de client 104 pour les données qui étaient initialement générées via des mécanismes de génération de données distincts, conventionnellement incompatibles. De plus, les processus ci-dessus permettent la mise à jour continue des données via de tels mécanismes de génération en marquant des portions de l'enregistrement de données intégré avec une indication de leur mécanisme de génération associé. [0071] Des variations des systèmes et procédés ci-dessus sont observées. Par exemple, à la réception d'une demande au bloc 305 le serveur 124 peut appliquer des politiques de sécurité à la demande, par ex. pour déterminer si le sous-système de client 104 a accès aux deux enregistrements identifiés dans la demande. Par exemple, chaque enregistrement dans les répertoires 128 et 132 peut inclure des identifiants d'entités avec accès aux enregistrements, et le serveur 124 peut être configure pour vérifier que le sous-système de client 104 apparaît dans de tels identifiant dans les deux enregistrements identifiés par la demande. [0072] Dans d'autres implémentations, les données provenant d'un enregistrement d'origine tel que l'enregistrement 418 ne sont pas fusionnées directement dans un enregistrement de destination tel que l'enregistrement 402. En d'autres termes, dans de telles implémentations un enregistrement tel que l'enregistrement 402c n'est pas produit via l'exécution du procédé 300. Au lieu de cela, comme illustré à la FIG. 9, le serveur d'intermédiation peut conserver un répertoire supplémentaire 900. Plutôt que de fusionner les données provenant de l'enregistrement 418 dans l'enregistrement 402 pour produire une version mise à jour de l'enregistrement (par ex. l'enregistrement 402c comme illustré à la FIG. 8), le serveur d'intermédiation crée un enregistrement d'intégration 904 dans le répertoire 900 et y stocke des informations permettant à l'enregistrement 402c d'être produit à la volée pour transmission au sous-système de client 104 sur demande. [0073] Plus spécifiquement, l'enregistrement 904 contient un identifiant d'enregistrement maître 908, correspondant à l'enregistrement 402, et un identifiant d'enregistrement fusionné 912 correspondant à l'enregistrement 418. En d'autres termes, l'identifiant d'enregistrement fusionné prend la place de l'identifiant d'enregistrement d'origine 500 mentionné plus tôt. De plus, l'enregistrement 904 contient un ou plusieurs ensembles de champs indiquant des relations partagées entre des champs des enregistrements 402 et 418. Par conséquent, dans l'exemple illustré, l'enregistrement 904 contient un ensemble de champs incluant un identifiant de champ de destination 916, un identifiant de champ d'origine 920, et une balise 924 similaire à la balise 600 mentionnée plus tôt. Dans certains exemples, la balise 924 peut être omise, dans la mesure où la présence des identifiants 916 et 920 implique que ces champs sont partagés. L'enregistrement 904 peut également contenir un identifiant d'une entité de commande, tels que le sous-système de fournisseur 108-1. 16 [0074] Si une demande est par la suite reçue pour l'identifiant d'enregistrement « ABCDEF », le serveur d'intermédiation 124 récupère l'enregistrement 400 lui-même, ainsi que l'enregistrement 900, et génère l'enregistrement 402e basé sur les enregistrements 402, 900 et 418 pour transmission à l'entité requérante. Cependant, l'enregistrement 402c ne doit pas être stocké en permanence. [0075] Dans le cas d'une détermination négative au bloc 320, l'identifiant d'enregistrement maître dans l'enregistrement 904 impose la « version » de données conflictuelles qu'il faut utiliser. Le sous-système de client 104 peut cependant être invité à éditer l'un ou l'autre des enregistrements 402 et 418 pour supprimer la collision. [0076] Dans d'autres exemples, l'exécution des blocs 320 à 330 peut être omise pour certaines portions d'un enregistrement. Par exemple, dans le présent exemple dans lequel certains champs de chaque enregistrement définissent des éléments, la probabilité de collision de tels champs (c.-à-d. contenant des données définissant le même élément) peut être faible, et les blocs 320 à 330 peuvent par conséquent être exécutés uniquement pour des champs d'identification de clients tels que les champs 408 et 424. En d'autres termes, pour certains champs la détermination au bloc 315 peut être automatiquement négative, libérant ainsi le serveur 124 de la nécessité d'exécuter les calculs de similarité mentionnés plus tôt. Le mappage de champ peut indiquer quels champs s'appliquent au raccourci ci-dessous. [0077] Les personnes de métier apprécieront que dans certains modes de réalisation, les fonctionnalités des applications 212 et 216 peuvent être implémentées à l'aide d'éléments matériels ou micrologiciels préprogramrnés (par ex., (les circuits intégrés spécifiques à une application (ASIC), des mémoires mortes programmables électriquement effaçables (EEPROMs),etc.), ou autres composants liés. [0078] La portée ne devrait pas être limitée par les modes (le réalisation exposés dans les exemples ci-dessus mais l'interprétation la plus large possible devrait être faite conformément à la description dans son ensemble. 17 [Revendication I] REVENDICATIONSUn procédé d'intégration d'objets de données, le procédé comprenant : le stockage, à un serveur d'intermédiation, (i) d'un enregistrement d'origine contenant un premier identifiant unique et un premier ensemble dc champs dc données définissant un premier élément fourni par un premier fournisseur, et (ii) un enregistrement de destination contenant un deuxième identifiant unique et un deuxième ensemble de champs de données définissant un deuxième élément fourni par un deuxième fournisseur ; la réception au serveur d'intermédiation, à partir d'un dispositif client, d'une instruction pour fusionner l'enregistrement d'origine dans l'enregistrement de destination, la demande contenant les premier et deuxième identifiants uniques ; en réponse à la réception de l'instruction, la mise à jour de l'enregistrement de destination en : i. comparant le premier ensemble de champs de données avec le deuxième ensemble de champs de données ; et ii. pour chaque champ de données du premier ensemble qui correspond à un champ de données correspondant du deuxième ensemble, le marquage du champ de données correspondant du deuxième ensemble comme étant un champ partagé ; et [Revendication 2] [Revendication 3] l'envoi de l'enregistrement de destination mis à jour au dispositif client pour affichage. Lc procédé de la revendication 1, dans lequel la comparaison du premier ensemble de champs de données au deuxième ensemble de champs de données inclut : la récupération d'un mappage de champ identifiant, pour chacun du premier ensemble de champs de données, un champ correspondant du deuxième ensemble ; et la comparaison de chacun du premier ensemble de champs de données avec le champ correspondant. du deuxième ensemble, selon le mappage de champ. Le procédé de la revendication 1 ou de la revendication 2, comprenant par ailleurs le stockage du premier identifiant unique en association avec 18 [Revendication 4] [Revendication 5] [Revendication 6] [Revendication 7] [Revendication 8] [Revendication 9] l'enregistrement de destination mis à jour. Le procédé de l'une quelconque des revendications 1 à 3, comprenant par ailleurs : pour chaque champ de données du premier ensemble qui ne correspond pas à un champ de données correspondant du deuxième ensemble selon la comparaison, la création d'un champ de données fusionné dans l'enregistrement de destination. Le procédé de la revendication 4, comprenant par ailleurs le stockage, dans chaque champ de données fusionné, d'une indication selon laquelle le champ de données fusionné est associé à l'enregistrement d'origine. Le procédé de la revendication 5, dans lequel l'indication selon laquelle le champ des données fusionné est associé à l'enregistrement d'origine inclut le premier identifiant unique. Le procédé de l'une quelconque des revendications 1 à 6, dans lequel le marquage du champ de données correspondant du deuxième ensemble comme étant un champ partagé inclut l'une des actions suivantes : le stockage d'une balise dans le champ de données correspondant du deuxième ensemble ; et le stockage dans un enregistrement d'intégration distinct de l'enregistrement d'origine et l'enregistrement de destination, des identifiants du champ de données du premier ensemble et du champ de données correspondant du deuxième ensemble. Le procédé de l'une quelconque des revendications 1 à 7, dans lequel la comparaison inclut : la détermination, pour chaque champ de données du premier ensemble et le champ de con-espondant du deuxième ensemble, d'une métrique de similarité ; et la détection d'une correspondance entre le champ de données du premier ensemble et le champ de données correspondant du deuxième ensemble lorsque la métrique de similarité est au-dessus d'un seuil. un serveur d'intermédiation pour intégrer des objets de données, comprenant : une interface de communication ; une mémoire stockant CO un enregistrement d'origine contenant un premier identifiant unique et un premier ensemble de champs de données définissant un premier élément fourni par un premier fournisseur, et (ii) un enregistrement de destination contenant un deuxième identifiant unique et un deuxième ensemble de champs de 19 données définissant un deuxième élément fourni par un deuxième fournisseur ; et un processeur connecté à l'interface de communication et à la mémoire, le processeur configuré pour : i. recevoir, à partir d'un dispositif client via l'interface de com- munication, une instruction pour fusionner l'enregistrement d'origine dans l'enregistrement de destination, la demande contenant les premier et deuxième identifiants uniques ; ii. en réponse à la réception de l'instruction, afin de mettre à jour l'enregistrement de destination : 1. comparer le premier ensemble de champs de données au deuxième ensemble de champs de données ; 2. pour chaque champ de données du premier ensemble qui correspond à un champ de données correspondant du deuxième ensemble, marquer le champ de données correspondant du deuxième ensemble comme étant un champ partagé ; et envoyer l'enregistrement de destination mis à jour au dispositif client pour affichage. [Revendication 10] [Revendication 11] [Revendication 12] Le serveur d'intermédiation de la revendication 9, dans lequel le processeur est par ailleurs configure, afin de comparer le premier ensemble de champs de données au deuxième ensemble de champs de données, pour : récupérer un mappage du champ identifiant, pour chacun du premier ensemble de champs de données, un champ correspondant du deuxième ensemble ; et comparer chacun du premier ensemble de champs de données au champ correspondant du deuxième ensemble, selon le mappage de champ. Le serveur d'intermédiation de la revendication 9 ou la reven- dication 10, dans lequel le processeur est par ailleurs configuré pour stocker, dans la mémoire, le premier identifiant unique en association avec l'enregistrement de destination mis à jour. Le serveur d'intermédiation de l'une quelconque des revendications 9 à 11, dans lequel le processeur est par ailleurs configuré pour : pour chaque champ de données du premier ensemble qui ne correspond pas à un champ de correspondant du deuxième ensemble selon la com- 20 [Revendication 13] [Revendication 14] [Revendication 15] [Revendication 16] [Revendication 17] paraison, créer un champ de données fusionné dans l'enregistrement de destination. Le serveur d'intermédiation de la revendication 12, dans lequel le processeur est par ailleurs configuré pour stocker, dans chaque champ de données fusionné, une indication selon laquelle le champ de données fusionné est associé à l'enregistrement d'origine. Le serveur d'intermédiation de la revendication 13,dans lequel l'indication selon laquelle le champ de données fusionné est associé à l'enregistrement d'origine inclut le premier identifiant unique. Le serveur d'intermédiation de l'une quelconque des revendications 9 à 14, dans lequel le processeur est par ailleurs configuré, afin de marquer le champ de données correspondant du deuxième ensemble comme étant un champ partagé, pour exécuter l'une des actions suivantes : stocker une balise dans le champ de données correspondant du deuxième ensemble ; et stocker, dans un enregistrement d'intégration distinct de l'enregistrement d'origine et de l'enregistrement de destination, des identifiants du champ de données du premier ensemble et du champ de données correspondant du deuxième ensemble. Le serveur d'intermédiation de l'une quelconque des revendications 9 à 15, dans lequel le processeur est par ailleurs configuré, afin de comparer le premier ensemble de champs de données au deuxième ensemble de champs de données, pour : déterminer, pour chaque champ de données du premier ensemble et le champ de données correspondant du deuxième ensemble, une métrique de similarité ; et détecter une correspondance entre le champ de données du premier ensemble et le champ de données correspondant du deuxième ensemble lorsque la métrique de similarité est au-dessus d'un seuil. Un produit programme d'ordinateur comprenant les instructions de code de programme stockées sur un support lisible par ordinateur pour exécuter les étapes du procédé selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté sur un ordinateur.