FR 3096802 A1 20201204 FR 1915437 A 20191223 Description Titre de l'invention : Système et procédé de génération d'objets de données fonctionnelles agrégées [0001] De manière générale, la présente spécification porte sur la génération d'objets de données, et plus particulièrement sur un système et un procédé de génération d'un objet de données fonctionnelles agrégées pour un sous-système de client provenant d'un ensemble d'objets de données de fournisseur ayant différents formats d'objets de données. Contexte [0002] Certaines catégories de produits, incluant les biens et services liés au voyage, peuvent inclure différents types de produits. Par exemple, la catégorie générale de biens et services liés au voyage inclut des produits tels que des vols, réservations d'hôtels, locations de voiture et similaires. De multiples produits au sein d'une catégorie peuvent être achetés en association les uns avec les autres par un utilisateur donné, tels qu'un ou plusieurs vol(s) et une réservation d'hôtel pour un voyage donné. Cependant, les produits individuels peuvent être fournis par des entités de fournisseur distinctes (par ex. des compagnies aériennes, des hôtels et similaires) qui emploient différents formats d'objets de données à stocker et communiquent des objets de données de fournisseur définissant les produits susmentionnés. Par conséquent, l'affichage et l'interaction avec lesdits objets de données de fournisseur utilisant un sous-système de client, tels qu'un système de réservation, nécessitent habituellement que l'utilisateur (ou une entité agissant pour le compte de l'utilisateur, telle qu'une agence de voyage) s'adapte à de multiples protocoles de communication, formats de données et mécanismes de mise à jour distincts, ce qui est coûteux et source d'erreur. Résumé 100031 Un aspect de la spécification prévoit un procédé de génération d'un objet de données fonctionnelles agrégées pour un sous-système de client à partir d'un ensemble d'objets de données de fournisseur ayant différents formats d'objets de données, comprenant : le stockage de l'ensemble d'objets de données de fournisseur selon leurs formats d'objets de données respectifs, chaque objet de donnée de fournisseur incluant une pluralité d'éléments ; la création d'un autre objet de données pour lier les objets de données de fournisseur sélectionnés sur la base des éléments communs desdits éléments partagés entre les objets de données de fournisseur sélectionnés ; et la création de l'objet de données fonctionnelles agrégées en fusionnant et en combinant lesdits éléments communs desdits éléments avec les éléments restants de la pluralité d'éléments provenant des objets de données de fournisseur sélectionnés selon ladite 2 liaison, pour présentation au sous-système de client. [0004] Le procédé peut en outre comprendre : la réception d'une requête d'un sous-système de client pour modifier un des objets de données de fournisseur sélectionnés et, en réponse, l'une ou l'autre de la création, la suppression, la modification d'éléments dudit objet de données de fournisseur des objets de données de fournisseur ; la mise à jour de la liaison pour refléter toute modification desdits éléments communs desdits éléments ; et la création d'un autre objet de données fonctionnelles agrégées en fusionnant et en combinant lesdits éléments communs desdits éléments avec lesdits éléments restants de la pluralité d'éléments provenant des objets de données de fournisseur sélectionnés, incluant ledit objet de données de fournisseur modifié des objets de données de fournisseur sélectionnés, selon la liaison mise à jour, pour présentation au sous-système de client. [0005] Chacun desdits objets de données de fournisseur peut inclure un indicateur de canal de distribution indiquant son format d'objet de données. [0006] Chacun desdits objets de données de fournisseur peut inclure un identifiant d'enregistrement. [0007] Chacun desdits identifiants d'enregistrement peut être conservé dans ledit autre objet de données à la création de l'objet de données fonctionnelles agrégées. [0008] La création des éléments dudit objet de données de fournisseur des objets de données de fournisseur peut comprendre la copie d'un ou de plusieurs éléments d'un autre des objets de données de fournisseur. [0009] L'ensemble d'objets de données de fournisseur et un autre objet de données peuvent utiliser une sérialisation identique. [0010] L'objet fonctionnel agrégé peut être présenté au sous-système de client à l'aide d'une interface de programmation d'application (API) selon un contexte défini par ledit format d'objet de données des formats d'objets de données. [0011] Un autre aspect de la spécification fournit un serveur de traitement de transactions, comprenant : une mémoire stockant : un ensemble d'objets de données de fournisseur stockés selon les formats d'objets de données respectifs, chaque objet de donnée de fournisseur incluant une pluralité d'éléments ; et un processeur interconnecté à la mémoire, le processeur étant configuré pour : créer un autre objet de données pour lier les objets de données de fournisseur sélectionnés sur la base (lesdits éléments communs desdits éléments partagés entre les objets de données de fournisseur sélectionnés ; créer un objet de données fonctionnelles agrégées en fusionnant et en combinant lesdits éléments communs desdits éléments avec les éléments restants de la pluralité d'éléments provenant des objets de données de fournisseur sélectionnés selon ladite liaison ; et présenter l'objet de données fonctionnelles agrégées à un sous-système de client. 3 [0012] Le processeur peut en outre être configure pour : recevoir une demande du sous- système de client pour modifier l'un des objets de données de fournisseur sélectionnés et, en réponse, l'une ou l'autre action parmi créer, supprimer ou modifier les éléments dudit objet de données de fournisseur des objets de données de fournisseur ; mettre à jour la liaison pour refléter toute modification desdits éléments communs desdits éléments ; créer un autre objet de données fonctionnelles agrégées en fusionnant et en combinant les éléments communs desdits éléments avec ceux restants de la pluralité d'éléments provenant des objets de données de fournisseur sélectionnés, incluant ledit objet de données de fournisseur sélectionné modifié des objets de données de fournisseur sélectionnés ; et présenter l'autre objet de données fonctionnelles agrégées à un sous-système de client. [0013] Chacun desdits objets de données de fournisseur peut inclure un indicateur de canal de distribution indiquant son format d'objet de données. [0014] Chacun desdits objets de données de fournisseur peut inclure un identifiant d'enregistrement. [0015] Le processeur peut en outre être configure pour conserver chaque dit identifiant d'enregistrement dans ledit autre objet de données à la création de l'objet de données fonctionnelles agrégées. [0016] Le processeur peut en outre être configure pour créer des éléments dudit objet de données de fournisseur des objets de données de fournisseur peut comprendre la copie d'un ou plusieurs éléments communs d'un autre objet de données de fournisseur des objets de données de fournisseur. [0017] L'ensemble des objets de données de fournisseur et un autre objet de données peuvent utiliser une sérialisation identique. [0018] L'objet fonctionnel agrégé peut être présenté au sous-système de client à l'aide d'une interface de programmation d'application (API) selon un contexte défini par ledit format d'objet de données des formats d'objet de données. [0019] Un autre aspect de la spécification prévoit un produit-programme d'ordinateur comprenant des instructions de programme stockées sur un support lisible par ordinateur, pour générer un objet de données fonctionnelles agrégées pour un sous-système de client provenant d'un ensemble d'objets de données de fournisseur ayant des formats d'objets de données différents, dans lesquels l'exécution des instructions par un serveur de traitement de transactions configure le serveur de traitement de transactions pour : stocker l'ensemble d'objets de données de fournisseur selon leurs formats d'objets de données respectifs, chaque objet de données de fournisseur incluant une pluralité d'éléments ; créer un autre objet de données pour lier les objets de données de fournisseur sélectionnés sur la base des éléments communs (lesdits éléments partagés entre les objets de données de fournisseur sélectionnés ; et créer l'objet de données fonctionnelles agrégées en fusionnant et en combinant lesdits éléments communs desdits éléments avec les éléments restants de la pluralité d'éléments provenant des objets de données de fournisseur selon ladite liaison, pour présentation au sous-système de client. Brèves descriptions des dessins [0020] Les modes de réalisation sont décrits en référence aux figures suivantes, dans lesquelles : [0021] [fig.l] illustre un système de génération d'un objet de données fonctionnelles agrégées selon un aspect de cette spécification ; [0022] [fig.2] illustre certains composants internes d'un processeur de transaction du système présenté à la FIG. 1 ; [0023] [fig.3] illustre un procédé de génération d'un objet de données fonctionnelles agrégées selon le système de la FIG. 1 ; [0024] [fig.4] illustre la réception d'une demande provenant d'un sous-système de client pour récupérer un ou plusieurs objets de données de fournisseur et la génération d'un objet de données agrégées pendant l'exécution du procédé de la FIG. 3. [0025] [fig.5] illustre un procédé de mise à jour d'un élément d'un objet de données fonc- tionnelles agrégées. [0026] [fig.6] illustre la réception d'une requête de la part d'un sous-système de client pour mettre à jour un élément d'un objet de données fonctionnelles agrégées et la génération d'un objet de données agrégées pendant l'exécution du procédé de la FIG. 5. Description détaillée 100271 La FIG. I illustre un système 100 visant à générer un objet de données fonc- tionnelles agrégées pour un sous-système de client à partir d'un ensemble d'objets de données de fournisseur ayant différents formats d'objets de données. Les objets de données, dans les modes de réalisation décrits dans les présentes, définissent des produits tels que des biens et services liés au voyage, comme des vols, des réservations d'hôtels, des locations de véhicules et services connexes (par ex. des services d'enregistrement de bagages pour les vols, l'accès aux salons dans les aéroports, l'accès WiFi pendant les vols ou dans les hôtels, et ainsi de suite). Par exemple, dans le secteur du voyage, un tel objet de données est dénommé Enregistrement de nom de passager (PNR), qui est un enregistrement dans la base de données d'un Système de réservation informatique (CRS) contenant l'itinéraire d'un passager, ou d'un groupe de passagers voyageant ensemble. 100281 11 n'existe pas de norme générale dans le secteur concernant la présentation et le contenu d'un PNR. En pratique, chaque CRS ou système d'hébergement possède ses propres normes propriétaires, bien que les besoins communs du secteur, incluant la nécessité de mapper les données PNR facilement sur des messages ATA/IATA Re-servations Interline Message Procedures (ATRTMP) (Procédure pour la passation des messages de réservation entre compagnies aériennes), aient donné lieu à de nombreuses similitudes globales dans le contenu et le format des données entre les principaux systèmes. [0029] En termes de contenu, un PNR peut inclure le nom du passager ; les coordonnées de l'agent de voyage ou du bureau de la compagnie aérienne (par ex. un code TATA à 8 chiffres de l'agence de voyage ou du bureau de la compagnie aérienne) ; les informations sur la billetterie (par ex. un numéro de billet) ; l'itinéraire d'au moins un segment et le nom de la personne fournissant les informations. Une fois que la réservation est finalisée avec les informations qui précèdent, le CRS émettra un localisateur d'enregistrement alphanumérique unique. [0030] La livraison des produits susmentionnés aux clients est habituellement implémentée par une entité pourvoyeuse, telle qu'une compagnie aérienne pour les vols, une agence de location pour les locations de véhicules, et similaire. Préalablement à la livraison des produits aux clients (par ex. passagers sur un vol), les produits doivent être achetés ou autrement sécurisés pour le compte des clients via une série d'échanges de données. À cette fin, le système 100 inclut un ou plusieurs sous-systèmes de fournisseur, dont deux exemples 104-1 et 104-2 sont présentés (collectivement dénommés sous-systèmes 104, ou simplement fournisseurs 104). Les objets de données conservés par ou pour le compte de chaque fournisseur définissent les produits disponibles à la vente, ou déjà achetés par le fournisseur. Les objets de données susmentionnés sont également dénommés objets de données de fournisseur dans la description ci-dessous. [0031] Les sous-systèmes de fournisseur 104 peuvent, mais ne doivent pas, être exploités par les pourvoyeurs susmentionnés. Par exemple, le fournisseur 104-1 peut, dans le présent exemple, être exploité par une compagnie aérienne (c.-à-d. un pourvoyeur). Par exemple, le fournisseur 104-1 peut échanger des données avec d'autres composants du système 100 pour permettre la fourniture de produits selon la norme Nouvelle capacité de distribution (NDC) basée sur le langage de balisage extensible (XML). La nonne NDC a été développée en 2012 par l'IATA pour permettre aux compagnies aériennes de prendre le contrôle des produits proposés aux utilisateurs finaux ou aux agents de voyage. Le fournisseur 104-1 conserve un répertoire 108-1 définissant un inventaire de produits, tel qu'un Système de gestion de commandes (OMS) contenant des vols exploités par la compagnie aérienne qui sont disponibles à la réservation, ou ont été réservés. [0032] D'autres sous-systèmes de fournisseur 104 peuvent être fournis. Par exemple, le fournisseur 104-2, dans le présent exemple, est un système de gestion des passagers (PSS) de compagnies aériennes qui stocke un inventaire de produits et/ou des ré- 6 servations dans le répertoire 108-2. Le fournisseur 104-2 expose des applications PSS de l'IATA (basées sur la messagerie TTY ou Edifact) pour permettre à d'autres composants du système 100 de créer, mettre à jour et d'afficher des réservations. [0033] Le système 100 peut inclure une grande variété de sous-systèmes de fournisseur 104 supplémentaires, incluant des sous-systèmes GDS supplémentaires, et/ou des sous-systèmes supplémentaires exploités par un pourvoyeur. Par exemple, le système 100 peut inclure un autre fournisseur basé sur un GDS pour les compagnies aériennes à bas coût. [0034] Le système 100 inclut également un sous-système de client 120, par exemple exploité par une agence de voyage ou similaire, configuré pour interagir avec les sous-systèmes de fournisseur 104 via un réseau 128 incluant toute combinaison adaptée de réseaux locaux et étendus (incluant Internet). Le sous-système de client 120, tel que plus décrit plus en détail ci-dessous, est configuré pour obtenir des objets de données de fournisseur provenant des sous-systèmes de fournisseur 104, et demander des mises à jour aux objets de données de fournisseur afin de réserver les produits susmentionnés pour le compte de clients (par ex. particuliers). Les sous-systèmes de client supplémentaires (non présentés) peuvent également être inclus dans le système 100. [0035] Tel que cela apparaît maintenant, le sous-système de client 120 peut interagir avec plusieurs sous-systèmes de fournisseur 104 différents pour le compte de tout client donné. Chaque sous-système de fournisseur 104 peut stocker et échanger des objets de données de fournisseur dans des formats divergents (par ex. selon les différentes normes ou les différents protocoles de communication, et en employant différentes combinaisons et hiérarchies de champs au sein des objets de données). En outre, chaque sous-système de fournisseur 104 peut implémenter différents mécanismes de mise à jour pour acheter (ce qui peut également être dénommé réservation) les produits susmentionnés et pour apporter des changements aux achats existants. [0036] L'hétérogénéité des objets de données de fournisseur et les mécanismes de mise à jour fournis par les sous-systèmes de fournisseur 104 peuvent imposer une importante charge technique au sous-système de client 120 (et tout autre sous-système de client dans le système 100), en exigeant que chaque sous-système de client implémente des mécanismes de communication pour interagir avec chaque sous-système de fournisseur 104. En outre, la nature variable des objets de données de fournisseur conservés par les sous-systèmes de fournisseur 104 peut conduire à une incohérence dans la présentation des informations au niveau du sous-système de client 120, qui, à son tour, peut entraîner la transmission de demandes d'achat erronées ou malformées aux sous-systèmes de fournisseur 104. [0037] Par conséquent, le système 100 inclut également un processeur de transactions 132 configuré pour faire l'intermédiaire entre les sous-systèmes de fournisseur 104 et le 7 sous-système de client 120 (et, plus généralement, tout sous-système de client du système 100), ainsi que coordonner les transactions entre différents systèmes dorsaux 144, comme que décrit ci-dessous. Le processeur de transactions 132, comme décrit plus en détail ci-dessous, est configuré pour obtenir des objets de données de fournisseur provenant d'un ou de plusieurs sous-systèmes de fournisseur 104 (par ex. en réponse à une demande de la part d'un sous-système de client 120). Le processeur de transactions 132 est en outre configure pour générer un objet de données fonctionnelles agrégées provenant d'un ensemble d'objets de données de fournisseur acquise via différentes normes de messagerie, telles que NDC pour les objets de données de fournisseur reçus de la part du fournisseur 104-1, Edifact ou TTY pour les objets de données de fournisseur de contenu aérien reçus de la part du fournisseur 104-2 via la messagerie GDS, ou d'autres protocoles tels que XML, JSON, pour l'autre contenu reçu de la part du fournisseur 104-2 via la messagerie GDS. À cette fin, le processeur de transactions 132 inclut un module de plateforme de voyage 136 et un gestionnaire d'enregistrements virtuels 140. Le module de plateforme de voyage 136 est le point d'entrée vers le processeur de transactions 132 pour le sous-système de client 120 et les sous-systèmes de fournisseur 104. Le module de plateforme de voyage 136 est responsable de la conservation du contexte de l'utilisateur (par ex. agent) selon lequel un utilisateur peut ouvrir une session pour retrouver un PNR ou autre objet de données, exécuter une ou plusieurs entrées sur l'objet de données pendant la session, puis valider la session (à partir de la mémoire vers un stockage à long terme), bien qu'il soit également envisagé que cette interaction avec le module de la plateforme de voyage 136 soit sans état, auquel cas toute action est instantanément validée. Pour une session donnée, son objectif est de connecter la dernière version du contexte et de transmettre les requêtes fonctionnelles aux serveurs d'applications correspondants. Le contexte est stocké en mémoire et récupéré à l'aide d'un identifiant de session. Cependant, conformément à un aspect de la présente spécification, les fonctionnalités du module de plateforme de voyage 136 sont étendues pour stocker de multiples objets de données en mémoire (c.-à-d. contexte multi-dossiers), tels que des entrées NDC et GDS 137 et 138 de formats différents, ainsi qu'un autre objet de données 141, dénommé « dossier » dans les présentes, qui utilise la même structure technique que les autres objets de données. Bien que seules les enregistrements PNR 137 et 138 soient illustrés, on comprendra que tout nombre d'objets de données puisse être stocké. En outre, les principes exposés dans les présentes peuvent être appliqués aux objets de données autres que les enregistrements PNR, qui sont simplement donnés à titre d'exemple. [0038] L'objet de données de dossier 141 stocke des liens entre les divers objets de données 137, 138, etc. Par exemple, l'objet de données de dossier 141 peut stocker un 8 lien pour établir que l'élément de données de passager dans un objet de données identifie la même personne (par ex. M. Toto à la FIG. 1) comme élément de données de passager dans un autre objet de données. [0039] Le gestionnaire d'enregistrements virtuels 140 est configuré pour créer un objet de données agrégées provenant du contexte multi-entrées du module de la plateforme de voyage 136 en prenant des éléments provenant de multiples objets de données 137, 138, etc., et en les agrégeant à l'aide des liens stockés dans l'objet de données de dossier 141. Ainsi, l'objet de données de dossier 141 est utilisé pour déterminer si des éléments communs dans des objets de données disparates doivent être fusionnés (par ex. même passager, etc.) pour générer un objet de données agrégées. Ainsi, l'objet de données de dossier 141 effectue le suivi de l'association des elementlD dans chaque objet de données. [0040] Le processeur de transactions 132 est également configuré pour fournir des opérations de mises à jour agrégées au sous-système de client 120, par ex. sous la forme d'une interface de programmation d'application (API). Le sous-système de client 120 peut par conséquent demander l'une quelconque d'une variété de mises à jour aux objets de données de fournisseur (peu importe le format spécifique d'un objet de données de fournisseur) en transmettant une demande de mise à jour agrégée au processeur de transactions 132. Le processeur de transactions 132 est configuré pour générer une ou plusieurs opérations de mises à jour spécifiques au fournisseur en réponse à la réception d'une demande de mise à jour agrégée provenant du sous-système de client 120, tel que décrit ci-dessous. [0041] Passons à la FIG. 2, avant de discuter des fonctionnalités du système 100 plus en détail, certains composants d'un processeur de transactions 132 seront décrits plus en détail. [0042] Comme montré à la FIG. 2, le processeur de transactions 132 inclut au moins un processeur 200, tel qu'une unité centrale de traitement (CPU) ou similaire. Le processeur 200 est interconnecté avec une mémoire 204, implémentée sous forme de support durable lisible par ordinateur adapté (par ex. une combinaison adaptée de sous-systèmes de mémoire non-volatile et volatile incluant une ou plusieurs des mémoires suivantes : mémoire vive (RAM), mémoire morte (ROM), mémoire morte programmable effaçable électriquement (EEPROM), mémoire flash, mémoire informatique magnétique et similaire). Le processeur 200 et la mémoire 204 sont généralement composés d'un ou de plusieurs circuits intégrés (IC). [0043] Le processeur 200 est également interconnecté avec une interface de commu- nication 208, qui permet au processeur de transactions 132 de communiquer avec les autres dispositifs informatiques du système 100 (c.-à-d. le sous-système de fournisseur 104 et le sous-système de client 120) via le réseau 128. L'interface de com- 9 munication 208 inclut par conséquent tout composant nécessaire (par ex. les contrôleurs d'interface réseau (NIC), les unités radio et similaires) pour communiquer via le réseau 128. Les composants spécifiques de l'interface de communication 208 sont sélectionnés sur la base de la nature du réseau 128. Le processeur de transactions 132 peut également 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 présentés). [0044] Les composants du processeur de transactions 132 susmentionnés peuvent être déployés dans une seule enceinte, ou dans un format distribué. Par conséquent, dans certains exemples, le processeur de transactions 132 inclut une pluralité de processeurs, en partageant la mémoire 204 et l'interface de communication 208, ou chacun ayant des mémoires et des interfaces de communication associées distinctes. [0045] La mémoire 204 stocke les objets de données 137, 138 etc. ainsi que l'objet de données de dossier 141 susmentionné en lien avec la FIG. 1. La mémoire 204 stocke également une pluralité d'instructions de programmation lisibles par ordinateur, exécutables par le processeur 200, sous la forme de diverses applications, incluant une application d'agrégation 212. Comme le comprendront les hommes de métier, le processeur 200 exécute les instructions de l'application 212 (et toute autre applications adaptée) afin d'exécuter diverses actions définies par les instructions contenues dans ladite application. Dans la description ci-dessous, le processeur 200, et plus généralement le processeur de transactions 132, sont réputés être configurés pour exécuter lesdites actions. On comprendra qu'ils sont ainsi configurés via l'exécution (par le processeur 200) des instructions des applications stockées dans la mémoire 204. L'exécution de l'application 212, comme décrit plus en détail ci-dessous, configure le processeur de transactions 132 pour générer un objet de données fonctionnelles agrégées provenant d'un ensemble d'objets de données de fournisseur ayant différents formats d'objets de données, pour présentation au sous-système de client 120. L'exécution de l'application 212 configure également le processeur de transactions 132 pour recevoir les opérations de mises à jour agrégées de la part du sous-système de client 120, qui peuvent être traitées au niveau de l'enregistrement virtuel, ou divisées jusqu'au niveau de l'enregistrement physique, comme discuté plus en détail ci-dessous, pour mettre à jour les objets de données de fournisseur à un ou plusieurs sous-systèmes de fournisseur 104. [0046] Passons à présent à la FIG. 3, certains aspects du fonctionnement du système 100 seront plus décrits plus en détail. Spécifiquement, la FIG. 3 illustre un procédé 300 de génération d'un objet de données fonctionnelles agrégées, selon un mode de réalisation. Le procédé 300 sera décrit conjointement à son exécution dans le système 100, tel qu'illustré à la FIG. 4. Plus particulièrement, les blocs du procédé 300 sont exécutés par le processeur de transactions 132 via l'exécution de l'application 212 du processeur 200. [0047] Au bloc 305, le processeur de transactions 132 est configure pour recevoir une requête du sous-système de client 120 pour récupérer un ou plusieurs objets de données de fournisseur, qui ne nécessitent pas d'être reçus de la part du même fournisseur 104. Par exemple, le sous-système de client 120 peut demander une réservation d'itinéraire pour un passager, M. Toto, où un fournisseur 104-1 fournit un vol alors qu'un autre fournisseur 104-2 fournit un second vol, de sorte que les deux vols font partie de r itinéraire du passager. [0048] Au bloc 310, le module de plateforme de voyage 136 transmet la demande à un système dorsal 144, tel qu'un générateur d'affichage de commandes. Le générateur d'affichage de commandes, au bloc 315, formule une demande au gestionnaire d'enregistrements virtuels 140 pour générer un objet de données fonctionnelles agrégées. En réponse, au bloc 320, le gestionnaire d'enregistrements virtuels 140 récupère les objets de données 137, 138 et 141 et renvoie un objet de données agrégées virtuel. [0049] Dans l'exemple illustré, les objets de données 137 et 138 comprennent des enregis- trements techniques acquis via différentes normes de messagerie, respectivement NDC et Edifact. NDC PNR (137) contient les éléments suivants : un identifiant d'enregistrement : ABCDEF pour identifier un enregistrement PNR, un identifiant d'élément (ID d'élément) pour identifier le passager M. Toto, et un ID d'élément contenant un élément de vol FE 001 provenant d'un fournisseur (par ex. 104-1), où le descripteur « NDC » est un indicateur de canal de distribution visant à indiquer si l'enregistrement technique est acquis via la messagerie NDC. De manière similaire, un PNR GDS technique (138) contient les éléments suivants : un identifiant d'enregistrement ; GHIJKL pour identifier l'entrée GDS, un ID d'élément pour identifier le passager M. Toto, et un ID d'élément contenant un élément de vol FE 002 provenant d'un autre fournisseur (par ex. 104-2), où le descripteur « GDS » est un indicateur de canal de distribution visant à indiquer si l'enregistrement technique est acquis via la messagerie GDS. Bien que les enregistrements techniques 137 et 138 soient similaires en ce qu'ils se rapportent à un contenu aérien communiqué via des canaux de messagerie indépendants, les principes énoncés dans les présentes s'appliquent à d'autres types d'enregistrements techniques se rapportant à un autre contenu (par ex. hôtel, location de véhicule, etc.). [0050] Dans l'exemple, l'objet de données de dossier 141 contient un lien définissant une association des identifiants d'éléments dans chacun des objets de données de fournisseur 137 et 138 pour identifier le passager M. Toto, comme étant un élément commun partagé entre les objets de données. L'objet de données agrégées virtuel 11 généré inclut des éléments de données visant à identifier le passager, M. Toto, et les deux éléments de vol : FE 001 et FE 002. [0051] Au bloc 325, l'objet de données agrégées est renvoyé au système dorsal 144 (générateur d'affichage de commande) qui, au bloc 330, retransmet l'objet de données agrégées au sous-système de client 120 pour affichage, mise à jour, etc. [0052] Concernant la mise à jour, la FIG. 5 illustre un procédé 500 permettant de mettre à jour un élément d'un objet de données fonctionnelles agrégées, selon un mode de réalisation. Le procédé 500 sera décrit conjointement à son exécution au sein du système 600, tel qu'illustré à la FIG. 6. Plus particulièrement, les blocs du procédé 500 sont exécutés par le processeur de transactions 132 via l'exécution de l'application 212 par le processeur 200. [0053] Au bloc 505, le processeur de transactions 132 est configuré pour recevoir une demande du sous-système de client 120 en vue de modifier un ou plusieurs objets de données de fournisseur. Par exemple, le sous-système de client 120 peut demander qu'une remarque liée au contenu NDC FE 001 soit ajoutée à un PNR. [0054] Au bloc 510, le module de plateforme de voyage 136 transmet la requête au ges- tionnaire d'enregistrements virtuels 140 qui, au bloc 515, récupère les objets 137, 138 et 141 et échange des messages avec le système dorsal 144 qui, dans l'exemple illustré, consiste dans un système dorsal de traitement des remarques. Le gestionnaire d'enregistrements virtuels 140 analyse la demande et détermine que la remarque doit seulement être ajoutée au contenu NDC (par ex. en distribuant une requête uniquement à l'enregistrement NDC). Le gestionnaire d'enregistrements virtuels 140 divise ainsi les actions de mise à jour au niveau physique et régénère ensuite la vue agrégée pour ajouter la remarque mise à jour au contenu NDC, au bloc 520, et renvoie l'objet de données mis à jour pour l'enregistrement ABCDEF au module de plateforme de voyage 136 qui, au bloc 525, retransmet l'objet de données fonctionnelles agrégées au sous-système de client 120 pour affichage, mise à jour, etc. [0055] Une personne du métier comprendra qu'une fonctionnalité supplémentaire peut être fournie par le gestionnaire d'enregistrements virtuels 140 énoncé dans les présentes. Par exemple, le fournisseur 104-1 ou 104-2 peut « diviser » un PNR pour ajouter un passager supplémentaire, auquel cas un système conventionnel présenterait deux enregistrements ayant deux localisateurs (par ex. ABCDEF et GHIJKL) à l'utilisateur. Selon le procédé et le système énoncés dans les présentes, le gestionnaire d'enregistrements virtuels 140 agrégera la vue de l'utilisateur montrant les deux passagers avec un seul localisateur. [0056] Les personnes de métier comprendront que dans certains modes de réalisation, la fonctionnalité de l'application 212 au processeur de transactions 132 peut être implémentée à l'aide de matériel ou d'éléments de micrologiciel préprogrammé(s) (par 12 ex. circuits intégrés propres à une application (ASIC), mémoires mortes programmables effaçables électriquement (EEPROM), etc.) ou d'autres composants connexes. En outre, comme le constateront les hommes de métier, les systèmes et procédés décrits ci-dessus peuvent également s'appliquer à divers autres types d'objets de données (à savoir des objets de données définissant une large variété d'autres formes de produits) et ne se limitent pas aux systèmes de réservation de voyage et objets de données qui y sont associés. [0057] La portée de cette spécification ne doit pas se limiter aux modes de réalisation énoncés dans les exemples ci-dessus, mais doit être interprété de la manière la plus large possible en cohérence avec l'ensemble de la description. 13 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] REVENDICATIONSUn procédé de génération d'un objet de données fonctionnelles agrégées pour un sous-système de client provenant d'un ensemble d'objets de données de fournisseur ayant différents formats d'objets de données, comprenant : le stockage de l'ensemble d'objets de données de fournisseur selon leurs formats d'objets de données respectifs, chaque objet de données de fournisseur incluant une pluralité d'éléments ; la création d'un autre objet de données pour lier les objets de données de fournisseur sélectionnés sur la base des éléments communs desdits éléments partagés entre les objets de données de fournisseur sélectionnés ; et la création de l'objet de données fonctionnelles agrégées en fusionnant et en combimun lesdits éléments communs desdits éléments avec les éléments restants de la pluralité d'éléments provenant des objets de données de fournisseur sélectionnés selon ladite liaison, pour présentation au sous-système de client. Le procédé de la revendication 1, comprenant en outre : la réception d'une demande du sous-système de client pour modifier un des objets de données de fournisseur sélectionnés et, en réponse, l'une ou l'autre de la création, la suppression ou la modification des éléments dudit objet de données de fournisseur des objets de données de fournisseur ; la mise à jour de la liaison pour refléter toute modification desdits éléments communs desdits éléments ; et la création d'un autre objet de données fonctionnelles agrégées en fusionnant et en combinant lesdits éléments communs desdits éléments avec lesdits éléments restants de la pluralité d'éléments provemun des objets de données de fournisseur sélectionnés, incluant ledit objet de données de fournisseur modifié des objets de données de fournisseur sélectionnés, selon la liaison mise à jour, pour présentation au sous-système de client. Le procédé de la revendication 2, dans lequel la création des éléments dudit objet de données de fournisseur des objets de données de fournisseur comprend la copie d'un ou plusieurs éléments provenant d'un autre des objets de données de fournisseur. Le procédé de l'une quelconque des revendications 1 à 3, dans lequel 14 [Revendication 5] [Revendication 6] [Revendication 7] [Revendication 8] [Revendication 9] [Revendication 10] chacun desdits ohjets de données de fournisseur inclut un indicateur de canal de distribution indiquant son format d'objet de données. Le procédé de l'une quelconque des revendications 1 à 3, dans lequel chacun desdits ohjets de données de fournisseur inclut un identifiant d'enregistrement. Le procédé de la revendication 5, dans lequel chaque dit identifiant d'enregistrement est conservé dans ledit autre objet de données à la création de l'objet de données fonctionnelles agrégées. Le procédé de l'une quelconque des revendications 1 à 6, dans lequel les formats d'objets de données correspondent aux données acquises via au moins l'une des messageries de nouvelle capacité de distribution (NDC) ou de système de distribution global (GDS). Le procédé de l'une quelconque des revendications 1 à 7, dans lequel l'ensemble d'objets de données de fournisseur et un autre objet de données utilisent une sériai isation identique. Le procédé de l'une quelconque des revendications 1 à 8, dans lequel l'objet fonctionnel agrégé est présenté au sous-système de client à l'aide d'une interface de programmation d'application (API) selon un contexte défini par ledit format d'objet de données des formats d'objets de données. Un serveur de traitement de transactions pour générer un objet de données fonctionnelles agrégées provenant d'un ensemble d'objets de données de fournisseur ayant différents formats d'objets de données, comprenant : une mémoire stockant : i. l'ensemble d'objets de données de fournisseur stockés selon les formats d'objets de données respectifs, chaque objet de données de fournisseur incluant une pluralité d'éléments ; et un processeur interconnecté avec la mémoire, le processeur étant configuré pour : créer un autre objet de données pour lier des objets de données de fournisseur sélectionnés sur la base des éléments communs desdits éléments partagés entre les objets de données de fournisseur sélectionnés ; créer un objet de données fonctionnelles agrégées en fusionnant et en combinant lesdits éléments communs desdits éléments avec les éléments 15 [Revendication 11] [Revendication 12] [Revendication 13] [Revendication 14] [Revendication 15] [Revendication 16] restants de la pluralité d'éléments provenant des objets de données de fournisseur sélectionnés selon ladite liaison ; et présenter l'objet de données fonctionnelles agrégées à un sous-système de client. Le serveur de traitement de transactions de la revendication 10, dans lequel le processeur est en outre configuré pour : recevoir une demande du sous-système de client en vue de modifier l'un des objets de données de fournisseur sélectionnés et, en réponse, l'une ou l'autre action parmi créer, supprimer ou modifier des éléments dudit object de données de fournisseur des objets de données de fournisseur ; mettre à jour la liaison pour refléter toute modification desdits éléments communs desdits éléments ; créer un autre objet de données fonctionnelles agrégées en fusionnant et en combinant lesdits éléments communs desdits éléments avec lesdits éléments restants de la pluralité d'éléments provenant des objets de données de fournisseur sélectionnés, incluant ledit objet de données de fournisseur modifié des objets de données de fournisseur sélectionnés, selon ladite liaison ; et présenter l'autre objet de données fonctionnelles agrégées au sous-système de client. Le serveur de traitement de transactions de la revendication 11, dans lequel la création d'éléments dudit objet de données de fournisseur des objets de données de fournisseur comprend la copie d'un ou de plusieurs éléments communs provenant d'un autre des objets de données de fournisseur. Le serveur de traitement de transactions de l'une quelconque des revendications 10 à 12, dans lequel chacun desdits objets de données de fournisseur inclut un indicateur de canal de distribution indiquant son format d'objet de données. Le serveur de traitement de transactions de l'une quelconque des revendications 10 à 12, dans lequel chacun desdits objets de données de fournisseur inclut un identifiant d'enregistrement. Le serveur de traitement de transactions de la revendication 14, dans lequel le processeur est en outre configuré pour conserver chaque dit identifiant d'enregistrement dans ledit autre objet de données à la création de l'objet de données fonctionnelles agrégées. Le serveur de traitement de transactions de l'une quelconque des revendication 10 à 15, dans lequel les formats d'objets de données cor- 16 [Revendication 17] respondent aux données acquises via au moins l'une des messageries de nouvelle capacité de distribution (NDC) et de système de distribution global (GDS). [Revendication 18] Le serveur de traitement de transactions de l'une quelconque des revendications 10 à 16, dans lequel l'ensemble d'objets de données de fournisseur et un autre objet de données utilisent une sérialisation identique. [Revendication 19] Le serveur de traitement de transactions de l'une quelconque des revendications 10 à 17, dans lequel l'objet fonctionnel agrégé est présenté au sous-système de client à l'aide d'une interface de programmation d'application (API) selon un contexte défini par ledit format d'objets de données des formats d'objets de données. Un produit-programme d'ordinateur comprenant des instructions 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 à 9 lorsque ledit programme est exécuté sur un ordinateur.