FR 3096799 A1 20201204 FR 1905718 A 20190529 Description Titre de l'invention : AGRÉGATION ET MISE À JOUR D'OBJETS DE DONNÉE HÉTÉROGÈNES [0001] La spécification concerne de façon générale la transmission et l'altération d'objets de donnée, et spécifiquement un système et un procédé pour agréger et actualiser des objets de donnée hétérogènes. [0002] Certaines catégories de produits, incluant par exemple des marchandises et des services liés au voyage peuvent inclure un nombre de types de produits différents. Par exemple, la catégorie générale de marchandises et services liés au voyage inclut des produits tels que des vols, des réservations d'hôtel, des locations de voiture et autres produits similaires. Dc multiples produits dans une catégorie peuvent être achetés en association les uns avec les autres par un utilisateur donné, tels qu'un ou plusieurs vols et une réservation d'hôtel pour un voyage donné. Les produits individuels peuvent cependant être fournis par des entités fournisseuses discrètes (p. ex. des compagnies aériennes, des hôtels et autres entités de cc genre) qui utilisent des infrastructures distinctes d'échange de données pour stocker et communiquer des données définissant les produits susmentionnés. Par conséquent, la récupération et la modification de données définissant les produits nécessitent typiquement que l'utilisateur (ou une entité agissant pour le compte de l'utilisateur, telle qu'une agence de voyages) accommode de multiples types dc protocoles de communication distincts, de formats de donnée et de mécanismes de mise à jour, cc qui est coûteux et peut entraîner des erreurs. [0003] Un aspect de la spécification fournit un procédé pour agréger et actualiser des objets de donnée hétérogènes pour un sous-système client, le procédé étant mis en oeuvre par un serveur et incluant : le stockage d'un ensemble dc définitions d'objets de donnée, chaque définition d'objet de donnée fournissant un mappage entre un format d'objet de donnée agrégé et und pluralité de formats d'objets de donnée de fournisseur ; le stockage d'un ensemble de définitions de mise à jour, chaque définition dc mise à jour fournissant un mappage entre l'opération de mise à jour agrégée et une pluralité de mécanismes de mise à jour de fournisseur ; la réception d'un objet dc donnée dans un des formats d'objets de donnée; la sélection, basée sur le format d'objet de donnée du fournisseur de l'objet de donnée reçu, d'une des définitions d'objets de donnée et la génération d'objets de donnée agrégés conformément à la définition d'objet de donnée sélectionnée; la présentation des objets de donnée agrégés générés au sous-système client ; la réception, du sous-système client, d'une opération de mise à jour agrégée pour mettre à jour l'objet de donnée agrégé ; et la sélection, basée sur l'opération de mise à jour agrégée reçue, d'une des définitions de mise à jour, et l'initiation d'un 2 mécanisme de mise à jour de fournisseur conformément à la définition de mise àjour sélectionnée. [0004] Dans un autre aspect, chaque format d'objet de donnée de fournisseur correspond à un indicateur de chaîne de distribution et à un type d'objet de donnée. [0005] Dans un autre aspect, le format d'objets de donnée agrégés inclut un champ d'identifiant de fournisseur ; le procédé comprenant par ailleurs le stockage d'une pluralité d'identifiants de fournisseurs et des indicateurs correspondants de chaîne de distribution. [0006] Dans un autre aspect, le procédé comprend : la répétition de la réception, de la sélection et de la génération pour un autre objet de donnée agrégé ; et le stockage de l'objet de donnée agrégé et de l'autre objet de donnée agrégé dans un enregistrement de donnée agrégé avant la présentation. [0007] Dans un autre aspect, le format d'objet de donnée agrégé inclut une portion fournisseur mappée par la définition d'objet de donnée correspondant à la pluralité des formats d'objet de donnée de fournisseur et une portion client qui n'est pas mappée par la définition d'objet de donnée correspondante. [0008] Dans un autre aspect, chaque mécanisme de mise à jour de fournisseur correspond à un indicateur de chaîne de distribution et à un type d'objet de donnée. [0009] Dans un autre aspect, au moins un mécanisme de mise àjour de fournisseur inclut une séquence d'opérations de mise à jour mappées à l'opération de mise à jour agrégée. [0010] Dans un autre aspect, l'initiation du mécanisme de mise à jour du fournisseur comprend : sur la base de la définition d'objet de donnée con-espondant à l'objet de donnée agrégé, la génération des données de charge utile de mise à jour dans le format d'objet de donnée du fournisseur ; et la transmission des données de charge utile de mise à jour conformément au mécanisme de mise à jour du fournisseur. [0011] Dans un autre aspect, les objets de donnée définissent les éléments de voyage. [0012] Selon un autre aspect, un serveur agrégateur pour agréger et actualiser des objets de donnée hétérogènes pour un sous-système client comprend : une mémoire stockant : un ensemble de définitions d'objets de donnée, chaque définition d'objet de donnée fournissant un mappage entre un format d'objet de donnée agrégé et une pluralité de formats d'objet de donnée de fournisseurs; et un ensemble de définitions de mise à jour, chaque définition de mise à jour fournissant un mappage entre l'opération de mise à jour agrégée et une pluralité de mécanismes de mise à jour de fournisseurs un processeur interconnecté avec la mémoire, le processeur étant configuré pour : recevoir un objet de donnée dans un des formats d'objet de donnée de fournisseur ; sélectionner, basée sur le format d'objet de donnée du fournisseur de l'objet de donnée reçu, d'une des définitions d'objet de donnée et la génération d'un objet de donnée agrégé 3 conformément à la définition d'objet de donnée sélectionnée ; présenter des objets de donnée agrégés générés au sous-système client ; recevoir une opération de mise àjour agrégée du sous-système client pour mettre à jour l'objet de donnée agrégé ; et sélectionner, sur la base de l'opération de mise àjour agrégée reçue, d'une des définitions de mise àjour et l'initiation d'un mécanisme de mise àjour de fournisseur conformément à la définition de mise à jour sélectionnée. [0013] Dans un autre aspect, le serveur agrégateur est agencé pour mettre en oeuvre le procédé de l'un quelconque des autres aspects du procédé énoncés ci-dessus. [0014] Toujours selon un autre aspect, il est fourni un produit programme d'ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour mettre en oeuvre les étapes du procédé selon l'un quelconque des aspects du procédé énoncés ci-dessus lorsque ledit programme fonctionne sur un ordinateur. [0015] Des modes de réalisation sont décrits en faisant référence aux figures suivantes, dans lesquelles : [0016] [fig.1] décrit un système pour agréger et mettre à jour des objets de donnée hé- térogènes ; [0017] [fig.2] décrit certains composants internes du serveur agrégateur de la FIG. 1 ; [0018] [Fig. 3] décrit un procédé pour agréger et mettre à jour des objets de donnée hé- térogènes dans le système de la Fig. 1 ; [0019] [Fig. 4] décrit la réception d'objets de donnée de fournisseur par le serveur agrégateur de la Fig. 1 au cours de la mise en oeuvre du procédé de la Fig. 3. [0020] [Fig. 5A] illustre le mappage d'objets de donnée de fournisseurs sur des objets de donnée agrégés. [0021] [Fig. 5B] illustre le mappage d'objets de donnée de fournisseurs sur des objets de donnée agrégés. [0022] [Fig. 6] illustre un exemple d'enregistrement de donnée agrégé pour présentation au sous-système client de la Fig. 1. [0023] [Fig. 7] illustre un enregistrement de donnée, actualisé. [0024] [Fig. 8] illustre un exemple d'opérations de mise à jour effectuées par le serveur agrégateur de la Fig. 1. [0025] La [Fig. 9] illustre un exemple d'opérations de mise à jour effectuées par le serveur agrégateur de la Fig. 1. [0026] La FIG. 1 décrit un système 100 pour agréger et actualiser des objets de donnée hé- térogènes. Les objets de donnée, dans les modes de réalisation exposés dans la présente, définissent des produits tels que des marchandises et des services liés au voyage tels que des vols, des réservations d'hôtel, des locations de voiture et des services associés (p. ex. des services d'enregistrement de bagages pour des vols, l'accès au salon dans les aéroports, l'accès au Wifi sur des vols ou dans des hôtels, et ainsi de suite). Cependant, comme le rcconnaitront les hommes de métier, les systèmes et les procédés exposés ci-dessus peuvent aussi être appliqués à divers autres types d'objets de donnée (c'est-à-dire, des objets de donnée définissant une grande variété d'autres formes de produits). [0027] La remise des produits mentionnés ci-dessus aux clients est typiquement im- plémentée par une entité fournisseuse, telle qu'une compagnie aérienne pour les vols, une agence de location pour les locations de véhicules, et autres entités similaires. Avant la remise des produits aux clients (p. ex. des passagers sur un vol), les produits doivent être achetés ou autrement assurés pour le compte des clients, via une série d'échanges de données. Dans ce but, le système 100 inclut un ou plusieurs sous-systèmes de fournisseurs, dont deux exemples 104-1 et 104-2 sont montrés (désignés collectivement comme sous-systèmes de fournisseurs 104, ou simplement les fournisseurs 104). Les objets de donnée conservées par, ou pour le compte de, chaque fournisseur définissent les produits disponibles à la vente, ou déjà achetés auprès du fournisseur. Les objets de donnée mentionnés ci-dessus sont également désignés comme objets de donnée de fournisseur dans la discussion qui suit. [0028] Les sous-systèmes de fournisseurs 104 peuvent être, mais ne le sont pas néces- sairement, gérés par les fournisseurs mentionnés ci-dessus. Par exemple, le fournisseur 104-1 est géré dans le présent exemple par une compagnie aérienne (c.-à-d. un fournisseur). Par exemple, le fournisseur 104-1 peut échanger des données avec d'autres composants du système 100 afin de permettre la fourniture de produits selon la norme de nouvelle capacité de distribution (NDC) basée sur le langage de balisage extensible (XML). Le fournisseur 104-1 maintient un dépôt 108-1 définissant un inventaire de produits, tels que des vols assurés par la compagnie aérienne qui sont disponibles à la réservation, ou qui ont été réservés. [0029] D'autres sous-systèmes de fournisseurs 104 peuvent être gérés par des tiers qui ne sont pas directement responsables pour la fourniture des produits aux clients. Par exemple, le fournisseur 104-2, dans le présent exemple est un système mondial de distribution (GDS) géré par un tiers qui stocke un dépôt 108-2 définissant un inventaire de produits et/ou de réservations. Le fournisseur 104-2 peut récupérer des données pour l'entrepôt 108-2 à partir de divers autres composants du système 100, incluant, par exemple, un système central de réservations (CRS) 112 contenant des données d'inventaire pour un autre prestataire 116 (p. ex. une autre compagnie aérienne) et un entrepôt de tarifs ou de prix 118. En effet, comme le montre la FIG. 1, le CRS 112 peut aussi contenir des données d'inventaire récupérées auprès du fournisseur 104-1 lui-même. C'est-à-dire que le fournisseur gérant le sous-système 104-1 peut prendre des dispositions pour fournir les produits par l'intermédiaire de plus d'une seule chaîne de distribution. [0030] Le système 100 peut inclure une grande variété de sous-systèmes 104, incluant des sous-systèmes GDS supplémentaires, et/ou des sous-systèmes supplémentaires gérés par un fournisseur. Par exemple, le système 100 peut inclure un autre fournisseur basé sur le GDS pour les compagnies aériennes low colt. [0031] Le système 100 inclut également un sous-système client 120, géré par exemple par une agence de voyages ou entité similaire, configuré pour interagir avec les sous-systèmes fournisseurs 104 via un réseau 128 incluant une quelconque combinaison appropriée de réseaux locaux et de zone étendue (incluant l'Internes). Le sous-système client 120 qui sera décrit de façon plus détaillée ci-dessous, est configuré pour obtenir des objets de donnée de fournisseurs à partir des sous-systèmes fournisseurs 104 et pour demander des mises à jour des objets de donnée de fournisseurs afin de réserver les produits susmentionnés pour le compte des clients (p. ex. des particuliers). Des sous-systèmes clients supplémentaires (non illustrés) peuvent aussi être inclus dans le système 100. [0032] Il en ressort maintenant que le sous-système client 120 peut interagir avec un nombre de sous-systèmes fournisseurs 104 pour le compte d'un quelconque client donné. Chaque sous-système fournisseur 104 peut stocker et échanger des objets de donnée dans des formats divergents (p. ex. selon des normes ou des protocoles de communication différents et utiliser différentes combinaisons et hiérarchies de champs à l'intérieur des objets de donnée). Par ailleurs, chaque sous-système fournisseur 104 peut implémenter divers mécanismes de mise à jour pour acheter (on peut aussi parler de réserver) les produits susmentionnés et pour modifier des achats existants. [0033] La nature hétérogène des objets de donnée de fournisseurs et les mécanismes de mise à jour fournis par les sous-systèmes fournisseurs 104 peuvent imposer une charge technique importante au sous-système client 120 (et un quelconque autre sous-système client dans le système 100) en exigeant que chaque sous-système client implémente des mécanismes de communication pour interagir avec chaque sous-système fournisseur 104. Par ailleurs, la nature variable des objets de donnée de fournisseurs maintenus par les sous-systèmes fournisseurs 104 peut entraîner une présentation incohérente des informations au sous-système client 120, ce qui peut à son tour entraîner la transmission de demandes d'achat erronées ou difformes aux sous-systèmes fournisseurs 104. Les approches antérieures pour servir des données provenant de multiples sous-systèmes fournisseurs 104 au sous-système client 120 implémentent un sous-système intermédiaire qui récupère des données de multiples sous-systèmes fournisseurs 104 et présentent les données au sous-système client 120, par exemple sous la forme d'un enregistrement combiné de nom de passager (PNR) (p. ex. l'enregistrement complet de voyage, TTR, fourni par Amadeus S.A.S.). Cependant, ces enregistrements 6 combinés peuvent encore présenter des données de divers fournisseurs dans des formats distincts spécifiques aux fournisseurs. Par ailleurs, comme cela sera exposé ci-dessous, dans ces systèmes, la mise à jour nécessite typiquement l'usage de mécanismes de mise à jour différents, spécifiques aux fournisseurs. [0034] Le système 100 inclut donc aussi un serveur agrégatcur 132, également désigné simplement comme l'agrégateur 132 dans la présente, configuré pour servir d'intermédiaire entre les sous-systèmes fournisseurs 104 et le sous-système client 120 (et de façon générale, un quelconque sous-système client du système 100). L'agrégateur 132 qui sera décrit plus en détail ci-dessous est configuré pour obtenir des objets de donnée de fournisseurs, d'un ou de plusieurs sous-systèmes 104 (p. ex. en réponse à une requête provenant du sous-système client 120). L'agrégateur 132 est par ailleurs configuré pour générer des objets de donnée agrégés correspondant aux objets de donnée de fournisseurs sur la base d'un ensemble de définitions d'objets de donnée 136. Les objets de donnée agrégés sont stockés au niveau de l'agrégateur 132 dans un entrepôt 140. [0035] De façon générale, les définitions d'objets de donnée 136 définissent des [nappages entre les divers formats d'objet de donnée de fournisseurs notés ci-dessus et un format unique d'objet de donnée agrégé. La génération d'objets de donnée agrégés permet à r agregatcur 132 de présenter des objets de donnée d'une pluralité de fournisseurs différents au sous-système client 120 dans un format cohérent en réduisant la charge technique sur le sous-système client 120 qui aurait autrement été imposée par le besoin d'accommoder de multiples formats d'objet de donnée de fournisseurs. Par exemple, chaque sous-système client 120 n'a besoin d'être implémenté que pour interpréter, stocker et manipuler les objets de donnée agrégés. Le déploiement et l'opération des sous-systèmes clients sont donc simplifiés en centralisant la complexité d'interprétation de multiples formats d'objets de donnée de fournisseurs au niveau de l'agrégateur 132. [0036] L'agrégateur 132 est également configuré pour fournir un ensemble d'opérations de mise à jour agrégée au sous-système client 120, p. ex. sous la forme d'une interface de programmation d'application (API). Le sous-système client 120 peut donc demander une quelconque d'une variété de mises à jour des objets de donnée de fournisseurs (quel que soit le format particulier d'un objet de donnée de fournisseur donné) en transmettant une demande de mise à jour agrégée à l'agrégateur 132. L'agrégateur 132 est configuré, sur la base d'un ensemble de définitions de mise à jour 144, pour générer une ou plusieurs opérations de mise à jour spécifiques au fournisseur en réponse à la réception d'une requête de mise à jour agrégée provenant du sous-système client 120. En d'autres termes, l'agrégateur 132 est configuré pour initier un ou plusieurs des mécanismes de mise à jour mentionnés précédemment, spécifiés par les fournisseurs 104 7 en réponse à la requête du sous-système client 120. Le sous-système client 120 à son tour n'a pas besoin d'implémenter de multiples mécanismes de mise à jour indépendants pour provoquer des mises à jour devant être faites aux objets de donnée de fournisseurs. [0037] Par contraste aux approches antérieures mentionnées précédemment, l'implémentation d'un ensemble commun de mécanismes de mise à jour agrégée pour usage par tous les sous-systèmes clients simplifie les communications entre les sous-systèmes 120 et l'agrégateur 132 (p. ex. en réduisant le nombre de transactions entre les sous-systèmes clients 120 et l'agrégateur 132 pour mettre à jour des données à un sous-système fournisseur 104). Par exemple, chacun des mécanismes à étape unique ou à étapes multiples requis par les divers sous-systèmes fournisseurs 104 peut être initié avec la même requête commune par un sous-système client 120. Cet arrangement simplifie aussi l'intégration de sous-systèmes fournisseurs 104 supplémentaires dans le système 100, car seul l'agrégateur 132 nécessite la mise à jour pour prendre en compte tous mécanismes de mise à jour supplémentaires. Pendant ce temps, les sous-systèmes clients 120 continuent à utiliser le même ensemble commun d'opérations de mise à jour agrégée. [0038] Faisant maintenant référence à la Fig. 2, avant d'exposer en détail les fonctionnalités du système 100, certains composants de l'agrégateur 132 vont maintenant être décrits de façon plus détaillée. [0039] Comme le montre la FIG. 2, l'agrégateur 132 inclut au moins un processeur 200, tel qu'une unité centrale de traitement (CPU) ou autre élément similaire. Le processeur 200 est interconnecté à une mémoire 204 implémentée comme un support non transitoire, lisible par ordinateur (p. ex. une combinaison appropriée de sous-systèmes de mémoires volatiles et non volatiles incluant une quelconque ou plusieurs mémoires à accès aléatoire [RAM], mémoires à lecture seule [ROM], mémoires programmables à lecture seule effaçables électriquement [EEPROM], mémoires flash, stockage informatique magnétique, et autres de ce genre). Le processeur 200 et la mémoire 204 sont généralement compris d'un ou de plusieurs circuits intégrés (ICs). [0040] Le processeur 200 est aussi relié à une interface de communication 208 qui permet à l'agrégateur 132 de communiquer avec les autres dispositifs informatiques du système 100 (c.-à-d. le sous-système fournisseur 104 et le sous-système client 120) via le réseau 128. L'interface de communication 208 inclut donc tous les composants nécessaires (p. ex. des contrôleurs d'interface de réseau [NICs] des unités de radio, et autres similaires) pour communiquer via le réseau 128. Les composants spécifiques de l'interface de communication 208 sont sélectionnés en fonction de la nature du réseau 128. L'agrégateur 132 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 dis- 8 positifs similaires (non illustrés). [0041] Les composants de l'agrégateur 132 mentionnés ci-dessus peuvent être déployés dans une seule enceinte ou sous un format distribué. Par conséquent dans certains exemples, l'agrégateur 132 inclut une pluralité de processeurs qui peuvent partager la mémoire 204 et l'interface dc communications 208 ou qui ont chacun des interfaces de communications et des mémoires associées distinctes. [0042] La mémoire 204 stocke les définitions d'objets de donnée 136, l'entrepôt d'objets de donnée agrégés 140 et les définitions de mise à jour 144 mentionnées ci-dessus en référence à la FIG. 1. La mémoire 204 stocke aussi une pluralité d'instructions de programmation lisibles par ordinateur, exécutables par le processeur 200 sous forme d'applications variées, incluant une application d'agrégation 212. Les hommes de métier comprendront que le processeur 200 exécute les instructions de l'application 212 (et toute autre application pertinente) afin de mettre en oeuvre des actions diverses définies par les instructions contenues dans celle-ci. Dans la description ci-dessous, le processeur 200 et de façon plus générale l'agrégateur 132 sont censés être configurés pour mettre en oeuvre 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. L'exécution de l'application 212, comme cela sera décrit ci-dessous, configure l'agrégateur 132 pour générer des objets dc donnée agrégés à partir d'objets de donnée de fournisseurs, conformément aux définitions d'objet de donnée 136, pour présentation au sous-système client 120. L'exécution de l'application 212 configure également l'agrégateur 132 pour recevoir des opérations de mise à jour agrégée du sous-système client 120 et, sur la base des définitions de mise à jour 144, pour initier des mécanismes de mise à jour spécifiques aux fournisseurs afin de mettre à jour les objets de donnée des fournisseurs à un ou plusieurs des sous-systèmes fournisseurs 104. [0043] Faisant maintenant référence à la FIG. 3, certains aspects d'exploitation du système 100 seront décrits de façon plus détaillée. Spécifiquement, la FIG. 3 illustre un procédé 300 d'agrégation et de mise à jour d'objets de donnée hétérogènes. Le procédé 300 sera décrit conjointement avec sa mise en oeuvre dans le système 100. En particulier, les blocs du procédé 300 sont mis en oeuvre par l'agrégateur 132 via l'exécution de l'application 212 par le processeur 200. [0044] Au bloc 305, l'agrégateur 132 est configuré pour recevoir un ou plusieurs objets de donnée de fournisseur formatés selon un des formats de fournisseur mentionnés ci-dessus. Les objets de donnée reçus au bloc 305 n'ont pas besoin d'être reçus du même fournisseur 104 et n'ont pas besoin d'être reçus simultanément. Par exemple, les objets de donnée reçus au bloc 305 peuvent être reçus en réponse à une ou plusieurs requêtes transmises de l'agrégateur 132 (p. ex. à la suite d'une requête d'un sous-système client 9 120) à un ou plusieurs fournisseurs 104. Dans le présent exemple qui sera exposé de façon plus détaillée ci-dessous et, tel qu'il est illustré dans la FIG. 4, quatre objets de donnée sont reçus au bloc 305. Spécifiquement, deux objets de donnée 400 et 404 sont reçus par l'agrégateur 132 en provenance du sous-système fournisseur 104-1 et deux objets de donnée 408 et 412 sont reçus par l'agrégateur 132 en provenance du sous-système fournisseur 104-2. [0045] Au bloc 310, en réponse à la réception des objets de donnée de fournisseur, l'agrégateur 132 est configuré, pour un premier objet de donnée de fournisseur, pour sélectionner une des définitions d'objets de donnée 136. Spécifiquement, les définitions d'objets de donnée 136 contiennent des définitions distinctes pour chaque paire d'une chaîne de distribution et d'un type d'objet. L'agrégatcur 132 est configuré pour déterminer la chaîne de distribution et le type d'objet pour chaque objet de donnée reçu sur la base de l'un ou des deux, l'expéditeur de l'objet de donnée, et des contenus de l'objet de donnée lui-même. Par exemple, l'agrégateur 132 peut stocker les données de profil de fournisseurs dans la mémoire 204 qui contient, pour chaque fournisseur 104, un identifiant de fournisseur et un indicateur de chaîne de distribution correspondante. Dans d'autres exemples, la chaîne de distribution peut être dérivée de l'objet de donnée lui-même. Par exemple, dans le cadre des objets de donnée 408 et 412, l'agrégatcur 132 peut être configuré pour déterminer que les objets de donnée 408 et 412 sont structurés conformément à la norme EDWACT et que la chaîne de distribution associée aux objets de donnée 408 et 412 est par conséquent un GDS. Cependant, comme le comprendront les hommes de métier, la structure de donnée des objets de donnée peut ne pas dicter nécessairement la chaîne de distribution. [0046] Les types d'objets peuvent, par exemple, être déterminés en examinant le contenu d'un objet de donnée. Par exemple, un objet de donnée contenant la chaîne «. AIR» concerne une réservation de compagnie aérienne, alors qu'un objet de donnée contenant la chaîne «. HTL» concerne une réservation d'hôtel. Une grande variété d'autres chaînes ou indicateurs peut aussi être détectée par l'agrégateur 132 pour déterminer des types d'objets. Il en ressortira maintenant pour les hommes de métier que les types d'objets de donnée correspondent à des types de produits (p. ex. des réservations de vols, des réservations d'hôtel et autres similaires). [0047] Aux blocs 315 et 320, l'agrégateur 132 est configuré pour générer un ou plusieurs objets de donnée agrégés à partir des objets de donnée reçus au bloc 305. Comme décrit de façon plus détaillée ci-dessous, l'agrégateur 132 n'a pas nécessairement besoin de générer le même nombre d'objets de donnée agrégés que le nombre d'objets de donnée de fournisseurs reçus. Plus spécifiquement, au bloc 315 l'agrégateur 132 est configuré pour appliquer la définition d'objet de donnée sélectionnée à un objet de donnée reçu et au bloc 320 l'agrégateur 132 est configuré pour déterminer s'il reste un quelconque objet de donnée à traiter. Lorsque la détermination au bloc 320 est affirmative, la mise en oeuvre du bloc 310 (sélection d'une définition d'objet de donnée) et du bloc 320 (génération d'objets de donnée agrégés selon la définition de la sélection) est répétée jusqu'à atteindre une détermination négative au bloc 320. [0048] Faisant référence aux FIGS. 5 A et SB, la génération d'objets de donnée agrégés cor- respondant aux objets de donnée de fournisseurs 400 / 404 et 408 / 412 respectivement, sera décrite pour illustrer la mise en oeuvre des blocs 310-320 ainsi que la nature des définitions d'objets de donnée 136. Faisant d'abord référence à la FIG. SA, les contenus des objets de donnée de fournisseurs 400 et 404 sont illustrés schématiquement. Les hommes de métier reconnaitront que les objets de donnée de fournisseurs 400 et 404 ne sont pas typiquement transmis dans la forme graphique montrée dans la FIG. SA, mais dans une structure prédéfinic appropriée telle qu'une série de paires nom/valeur XML arrangée selon une hiérarchie prédéfinic. [0049] Comme illustré dans la FIG. SA, l'objet de donnée de fournisseur 400 contient une pluralité d'éléments, incluant un premier et un deuxième descripteur de service 500 et 504, et un premier et un deuxième élément de prix 508 et 512. Les descripteurs de services 500 et 504 peuvent contenir un ou plusieurs champs définissant des propriétés du produit correspondant. Par exemple, le descripteur de service 500 peut définir un vol en partance et donc contenir un lieu d'origine, un lieu de destination, un identifiant de la compagnie aérienne, des horaires de départ et d'arrivée, et autres éléments similaires. Le descripteur de service 504 peut définir un vol de retour et donc inclure des propriétés similaires à celles exposées ci-dessus en lien avec le descripteur de service 504. Les éléments de prix 508 et 512 contiennent des informations de prix pour les descripteurs de service 500 et 504 respectivement. Ainsi, l'élément de prix 508 contient un prix pour le vol en partance mentionné ci-dessus, tel que défini par le descripteur de service 500 alors que l'élément de prix 512 contient un prix pour le vol de retour défini par le descripteur de service 504. L'objet de donnée de fournisseur 404 inclut un descripteur de service 516 qui définit par exemple un produit d'enregistrement de bagages (p. ex. associé à un ou aux deux vols définis dans l'objet de donnée de fournisseur 400). L'objet de donnée de fournisseur 404 inclut aussi un élément de prix 520. [0050] Le mappage des objets de donnée de fournisseurs 400 et 404 sur des objets de donnée agrégés est illustré schématiquement par des flèches indiquant quelle information des objets de donnée 400 et 404 est mappée et à quels objets de donnée agrégés. En particulier, comme illustré dans la FIG. 5A la définition d'objet de donnée pour les objets de donnée liés au transport aérien reçus du sous-système fournisseur 104-1 amène l'agrégateur 132 à générer trois objets de donnée agrégés (qui peuvent aussi être désignés comme éléments de voyage) contenant les données dans les 11 deux objets de donnée de fournisseur 400 et 404. Spécifiquement, un premier objet de donnée agrégé 524 contient un descripteur de service 528 correspondant au descripteur de service 500 et définit un prix 532 pour le service récupéré à partir de l'élément de prix 508. Le descripteur de service agrégé 528 peut être identique au descripteur de service 500 ou les champs dans le descripteur de service 500 peuvent être mappés à des champs prédéfinis dans le descripteur de service agrégé 528 qui sont équivalents, niais pas identiques (p. ex. des champs peuvent être renommés, des unités peuvent être converties, et ainsi suite), conformément à la définition de l'objet de donnée. [0051] Un deuxième objet de donnée agrégé 536 inclut un descripteur de service agrégé 540 correspondant au descripteur de service 504 ainsi qu'un prix 544 correspondant à l'élément de prix 512. C'est-à-dire, que les contenus de l'objet de donnée 400 ont été divisés, via la mise en oeuvre du bloc 315, en deux objets de donnée agrégés. Plus spécifiquement, dans le présent exemple, les définitions d'objets de donnée 136 amènent r agregatcur 132 à mapper chaque paire d'un élément de service et d'un prix sur un objet de donnée agrégé séparé, de sorte qu'un objet de donnée agrégé représente un produit avec un prix (contrairement à la représentation de deux produits avec des prix distincts, tels que l'objet de donnée de fournisseur 400). Lorsque le mappage a pour conséquence la génération de plus d'un seul objet de donnée agrégé pour un seul objet de donnée de fournisseur, comme c'est le cas dans la FIG. SA, l'agrégateur 132 est également configuré pour générer et stocker un lien 546 associant les objets de donnée agrégés 524 et 536. Le lien 546 peut être stocké à l'intérieur d'un (ou des deux) des objets de donnée agrégés 524 et 536, dans un entrepôt séparé, ou autre de ce genre. Le lien 546 indique en général que les objets de donnée agrégés 524 et 536 sont connectés par les besoins du sous-système fournisseur 104-1 et doivent être mis à jour simultanément. Le sous-système fournisseur 104-1 peut, par exemple, permettre que des mises à jour soient faites uniquement à un objet de donnée dans sa globalité plutôt qu'à des éléments individuels à l'intérieur de l'objet de donnée. Le lien 546 sert donc, comme cela sera exposé de façon plus détaillée ci-dessous, à permettre à l'agrégateur 132 de générer correctement des requêtes de mises à jour formulées au cas où le sous-système client 120 demanderait une mise à jour à un seul des objets de donnée agrégés 524 et 536. [0052] Un troisième objet de donnée agrégé 548 contient un descripteur de service agrégé 552 correspondant au descripteur de service 516 et définit un prix 556 correspondant à l'élément de prix 520. Aucun lien ne connecte l'objet de donnée agrégé 548 aux objets de donnée 524 ou 536 parce que le sous-système fournisseur 104-1 (comme on le voit sur le côté gauche de la FIG. SA) n'a pas spécifié que les objets de donnée 400 et 404 sont liés. C'est-à-dire, que chaque objet de donnée 400 et 404 peut être mis à jour indépendamment. Dans d'autres exemples 12 cependant, dans lesquels le sous-système fournisseur 104-1 a transmis les objets de donnée 400 et 404 comme offre unique, indiquant que les objets de donnée 400 et 404 doivent être manipulés simultanément, l'agrégatcur 132 peut aussi générer un ou plusieurs liens supplémentaires, tels qu'un lien 550 connectant les objets de donnée agrégés 524 et 536 à l'objet de donnée agrégé 548. [0053] Les liens mentionnés ci-dessus (p. ex. le lien 550) peuvent contenir des paramètres supplémentaires au-delà des identifiants des objets de donnée liés. Des exemples de ces paramètres incluent, dans le cas de liens indiquant des associations imposées par le fournisseur entre les objets de donnée, des laps de temps pendant lesquels une offre est valable, des identifiants d'offre (p. ex. reçus du fournisseur fournisseur 104-1) et ainsi de suite. [0054] Faisant référence à la FIG. 5B, les objets de donnée de fournisseur 408 et 412 (reçus du sous-système fournisseur 104-2) sont illustrés, ainsi que leur mappage sur des objets de donnée agrégés 560 et 564. Les objets de donnée de fournisseur 408 et 412 incluent chacun un descripteur de service 568 et 572 respectivement, définissant à la fois un service et un prix pour le service. Le descripteur de service 568 peut par exemple définir un vol et le descripteur de service 572 peut définir un produit de sélection de siège correspondant au vol précité. [0055] Comme le montre la FIG. 5B, les définitions d'objets de donnée 136 définissent un mappage pour les objets de donnée liés au transport aérien à partir du sous-système fournisseur 104-2 qui mappe chaque objet de donnée 408 et 412 sur un objet de donnée agrégé distinct puisque les objets de donnée 408 et 412 (et plus généralement, un quelconque objet de donnée du sous-système fournisseur 104-2) contiennent des descripteurs de service uniques avec des informations de prix. Par conséquent, les objets de donnée agrégés 560 et 564 incluent des descripteurs de service 576 et 580 ainsi que des prix respectifs 584 et 588. [0056] 11 en ressort maintenant que les différents mappages appliqués conformément aux dé- finitions d'objets de donnée 136 donnent lieu à un ensemble d'objets de donnée agrégés avec certaines caractéristiques communes qui ne sont pas nécessairement présentes dans les objets de donnée du fournisseur reçus au bloc 305. Par exemple, les objets de donnée agrégés 524, 536, 548, 560 et 564 définissent chacun un service unique ayant un prix unique. D'autres caractéristiques variées peuvent aussi être normalisées entre les objets de donnée agrégés. Par exemple, certains sous-systèmes fournisseurs 104 peuvent stocker des identifiants de clients (p. ex. des noms de passager) dans des champs séparés pour le prénom et nom de famille alors que d'autres sous-systèmes peuvent stocker ces identifiants dans des champs uniques. Les définitions d'objets de donnée 136 peuvent aussi spécifier un format commun (p. ex. un champ unique de nom) pour les identifiants de clients. 13 [0057] Revenant à la FIG. 3, suite à la génération des objets de donnée agrégés précités, la détermination au bloc 320 est négative et la mise en oeuvre du procédé 300 poursuit au bloc 325. Au bloc 325, l'agrégateur 132 est configuré pour présenter les objets de donnée, générés via les blocs 310-320 au sous-système client 120. Par exemple, comme le montre la FIG. 6, l'agrégateur 132 peut être configuré pour générer un enregistrement de donnée agrégé 600 contenant les objets de donnée 524, 536, 548, 560 et 564. Les objets de donnée agrégés peuvent être collectés dans des enregistrements de donnée agrégés tels que l'enregistrement 600 illustré sur la base de critères variés. [0058] Dans le présent exemple, il est supposé que chacun des objets de donnée agrégés 524, 536, 548, 560 et 564 contient le même identifiant de client. C'est-à-dire que chacun des objets de donnée agrégés précités définit des produits récupérés pour le compte de (p. ex. avant de réserver et d'acheter), acheté par, ou autrement associé à un client donné du sous-système client 120. Cependant, l'identifiant de client n'a pas besoin d'être le critère (ou du moins le seul critère) définissant quels objets de donnée agrégés sont combinés dans un enregistrement de donnée agrégé. Par ailleurs, dans certains modes de réalisation les objets de donnée agrégés peuvent être combinés dans un enregistrement de donnée agrégé sur la base d'attributs autres qu'un identifiant de client. Par exemple, un enregistrement de donnée agrégé peut contenir des objets de donnée pour une pluralité d'identifiants de clients (p. ex. correspondant aux membres d'une famille, des individus associés à une entreprise commune, et ainsi suite). [0059] La présentation des enregistrements de donnée agrégées 600 au sous-système client 120 peut inclure la transmission de l'enregistrement de donnée agrégé 600 au sous-système client 120 via le réseau 128, p. ex. en réponse à une requête provenant du sous-système client 120. Suite à la réception de l'enregistrement de donnée agrégé 600, le sous-système client 120 peut être configuré pour afficher, imprimer ou autrement générer l'enregistrement de donnée agrégé 600, ou pour transmettre par ailleurs l'enregistrement de donnée agrégé 600, p. ex. à un dispositif informatique client (non illustré). Comme il en ressort sui la FIG. 6, le mappage des objets de donnée de fournisseur sur les objets de donnée agrégés permet à l'agrégateur 132 de présenter les informations de prix et de service, reçues des fournisseurs 104, au sous-système client 120 dans un format cohérent. [0060] Revenant à la FIG. 3, au bloc 330 l'agrégateur 132 est configuré pour déterminer si une demande de mise à jour a été reçue en provenance du sous-système client 120 en association avec un quelconque des objets de donnée agrégés transmis au bloc 325. Lorsque la détermination au bloc 330 est négative, l'agrégateur 132 attend une demande de mise à jour (c.-à-d. qu'il répète le bloc 330). L'agrégateur 132 peut aussi recevoir d'autres objets de donnée de fournisseurs ; c'est-à-dire qu'une ou plusieurs instances supplémentaires du procédé 300 peuvent être mises en oeuvre simultanément 14 (p. ex. pour des objets de donnée associés à des clients différents). [0061] Lorsque la détermination au bloc 330 est affirmative, l'agrégateur 132 est configure pour mettre en oeuvre un des blocs 335 et 340, conformément à la nature de la requête de mise à jour. Les opérations de mise à jour agrégée mentionnées antérieurement incluent des opérations de mise àjour relatives aux portions client des objets de donnée agrégés et des opérations de mise à jour relatives aux portions-fournisseur des objets de donnée agrégés. Les contenus des objets de donnée, exposés ci-dessus, en lien avec les FIGS. 5A-5B et 6, sont dérivés entièrement des objets de donnée de fournisseur et sont par conséquent contenus dans des portions-fournisseur des objets de donnée agrégés. Cependant, les objets de donnée agrégés peuvent aussi inclure des portions client qui contiennent des données qui ne sont, ni reçues des fournisseurs 104 ni envoyées à ceux-ci. Une grande variété de données peut être stockée dans les portions client des objets de donnée agrégés. Des exemples de donnée de client incluent des majorations de prix facturées par le sous-système client 120 (et par conséquent conservées avec le prix payé aux fournisseurs, tel que les prix 532 et 544 mentionnés ci-dessus), des notes libres et des identifiants de forfaits reliant les objets de donnée agrégés. [0062] Chacune des formes de donnée de portion client mentionnées ci-dessus est insérée dans les objets de donnée agrégés, ou modifiée si elle a été insérée précédemment, via des opérations dédiées de mise àjour agrégée (p. ex. des sollicitations d'API). Cependant, les opérations de mise à jour agrégée qui con-espondent aux donnée stockées dans des portions client des enregistrements de donnée agrégées ne sont pas mappées à des mécanismes de mise à jour de fournisseur. C'est-à-dire, que seulement certaines sollicitations d'API sont mappées à des mécanismes de mise à jour de fournisseur (les sollicitations d'API relatives aux donnée stockées dans les portions-fournisseur des enregistrements de donnée agrégées). [0063] La FIG. 7 illustre un exemple de mise à jour de l'enregistrement de donnée 600 effectuée via une mise en oeuvre du bloc 335. En particulier, au bloc 330 il est supposé que le sous-système client 120 transmet une requête à l'agrégateur 132 pour relier les objets de donnée agrégés 560 et 564 (qui, comme mentionné antérieurement, définissent un vol et une sélection de siège ; les objets de donnée 560 et 564 peuvent cependant définir un quelconque d'une grande variété de produits qui n'ont pas besoin de provenir des mêmes sous-systèmes fournisseurs 104). Le fait de relier les objets de donnée agrégés permet au sous-système client 120 de créer des services forfaitaires qui peuvent être achetés par les utilisateurs finaux uniquement sous forme d'ensemble forfaitaire. Par exemple, les liens générés par le sous-système client 120 peuvent être utilisés pour implémenter un interligne virtuel dans le système 100. Dans un exemple d'implémentation d'interligne virtuelle, le sous-système client 120 peut mettre à jour l'enregistrement de donnée agrégé avec un lien entre les objets de donnée agrégés, chacun définissant des segments distincts d'un vol, d'un lieu d'origine à un lieu de destination, via au moins un lieu intermédiaire. Chaque objet de donnée agrégé, (c.-à-d. chaque segment du vol) peut provenir d'un fournisseur distinct et donc les objets de donnée agrégés tels qu'ils sont reçus des sous-systèmes fournisseurs 140 peuvent ne pas spécifier un quelconque lien. Cependant, le sous-système client 120 peut imposer les liens pour assembler les segments afin de former un vol unique destiné à la vente. Dans d'autres exemples, un tel forfait peut inclure des objets de donnée agrégés supplémentaires liés, tels qu'un objet définissant un service d'assurance offert par le sous-système client 120 (p. ex. fournissant un remboursement au cas où l'utilisateur final, en raison d'un retard sur un segment de vol, raterait un segment de vol subséquent). [0064] Ces liens peuvent aussi permettre au sous-système client de créer des ensembles de produits suivis qui peuvent toujours être achetés séparément, mais qui sont initialement présentés ensemble aux utilisateurs finaux. L'agrégateur 132, au bloc 335, est configuré pour stocker un lien 700 entre les objets de donnée agrégés 560 et 564 en réponse à la requête reçue au bloc 330. Ainsi qu'illustré schématiquement dans la FIG. 7, le lien 700 se distingue du lien 546 (p. ex. par un indicateur de type de lien) pour éviter que le lien 700 soit imposé par le client plutôt qu'imposé par le fournisseur. C'est-à-dire, que le lien 700 est considéré comme faisant partie de la portion client des enregistrements de donnée 560 et 564 et peut donc être modifié ou retiré par le sous-système client 120 sans nécessiter de communications avec le sous-système fournisseur 104-2. [0065] Suite à la mise en oeuvre du bloc 335, la mise en oeuvre du procédé 300 revient au bloc 330 pour attendre une autre requête de mise à jour. Suite à une requête du sous-système client 120 pour mettre à jour une portion fournisseur d'un objet de donnée agrégé au bloc 330, l'agrégateur 132 poursuit au bloc 340. Au bloc 340, l'agrégateur 132 est configuré selon les définitions de mise à jour 144 pour sélectionner un ou plusieurs mécanismes de mise à jour de fournisseurs qui correspondent à la mise à jour demandée. Les définitions de mise à jour définissent, pour chaque combinaison de chaîne de distribution et de type d'objet (ou simplement pour chaque fournisseur 104) un mécanisme de mise à jour, ou un ensemble de mécanismes, qui implémente chaque sollicitation d'API (c.-à-d. chaque demande de mise à jour disponible au sous-système client 120). L'agrégateur 132 est donc configuré pour déterminer la chaîne de distribution et le type d'objet de l'objet de donnée agrégé auquel s'applique la mise à jour et pour sélectionner le mécanisme de mise à jour correspondant. Comme il sera évident aux hommes de métier, une demande de mise à jour peut affecter de multiples objets de donnée agrégés (p. ex. lorsque les objets de donnée sont liés) et la réception d'une requête de mise à jour peut donc conduire à la sélection 16 et à l'exécution de plus d'un seul mécanisme de mise à jour de fournisseur. [0066] Des exemples de demandes de mises àjour reçues au bloc 330 qui conduisent au bloc 340 incluent les demandes de réservations (c.-à-d. des confirmations) pour une offre définie par un objet de donnée agrégé, des demandes pour supprimer un objet de donnée agrégé (p. ex. un service réservé précédemment), et autres demandes similaires. Dans le présent exemple, la requête reçue au bloc 330 est censée être une requête pour réserver / confirmer le produit défini par l'objet de donnée agrégé 524. À la réception de la demande de mise àjour, l'agrégateur 132 est configuré pour récupérer les définitions de mise àjour et pour sélectionner un mécanisme de mise à jour de fournisseur basé sur la chaîne de distribution et le type d'objet de l'objet de donnée agrégé 524. Ayant sélectionné le mécanisme de mise à jour de fournisseur, r agregatcur 132 est configuré pour initier le mécanisme de mise à jour de fournisseur au bloc 345 en générant des données de charge utile de mise à jour pour une transmission au sous-système fournisseur pertinent dans un plusieurs messages formatés et séquences selon le mécanisme de mise àjour de fournisseur sélectionné. [0067] Faisant référence à la FIG. 8, une mise en oeuvre exemplaire des blocs 340 et 345 est illustrée faisant suite à la réception d'une requête 800 du sous-système 120 pour confirmer l'objet de donnée agrégé 524. En réponse à la requête 800, ragregatcur 132 est configuré pour sélectionner un mécanisme de mise àjour de fournisseur correspondant au fournisseur 104-1 (c.-à-d. le fournisseur 104 correspondant à l'objet de donnée agrégé 524). Par exemple, la chaîne de distribution utilisée par le fournisseur 104-1 peut être NDC et, comme noté précédemment, l'objet de donnée agrégé 524 définit un produit relatif au transport aérien. Par conséquent, au bloc 340 l'agrégateur 132 est configuré pour sélectionner un mécanisme de mise à jour exigeant la transmission d'un message de modification de commande 804. Le message 804 peut inclure diverses données de charge utile, telles qu'un identifiant de l'objet de donnée 400 (à partir duquel l'objet de donnée agrégé 524 a été généré), des données de paiement, et autres données similaires. En réponse au message 804, l'agrégateur 132 peut recevoir un message de confirmation du fournisseur 104-1, p. ex. incluant un identifiant de commande qui peut être stocké dans l'objet de donnée agrégé 524. Spécifiquement, l'identifiant de commande peut être stocké comme attribut du lien 546. Il en ressort maintenant que la mise à jour ci-dessus a pour conséquences de confirmer à la fois les objets de donnée agrégés 524 et 536 qui proviennent du même objet de donnée de fournisseur 400. [0068] Faisant référence à la FIG. 9, une mise en oeuvre exemplaire des blocs 340 et 345 est illustrée faisant suite à la réception d'une requête 900 du sous-système 120 pour confirmer l'objet de donnée agrégé 560. La chaîne de distribution utilisée par le fournisseur 104-2 peut être un GDS comme mentionné précédemment et l'objet de 17 donnée agrégé 560 définit un produit lié au transport aérien. Par conséquent, au bloc 340 l'agrégateur 132 est configuré pour sélectionner un mécanisme de mise à jour correspondant aux produits de transport aérien basés sur le GDS. Comme le montre la FIG. 9, le mécanisme de mise àjour inclut une première demande 904 provenant de r agregatcur 132 au fournisseur 104-2 pour obtenir une référence de réservation et une deuxième demande 908 pour fournir un paiement pour la réservation. D'autres séquences de requêtes peuvent aussi être implémentées par l'agrégateur 132 (p. ex. des requêtes distinctes pour obtenir respectivement une référence de réservation et des informations de prix, suivies par une autre requête pour initier le paiement). À la suite d'une transmission réussie des deux requêtes 904 et 908, l'agrégateur 132 peut par exemple recevoir une référence de réservation et un numéro de billet électronique, chacun d'eux pouvant être stocké dans l'objet de donnée agrégé 560 (p. ex. selon la définition d'objet de donnée pertinente). [0069] Les hommes de métier verront que dans les exemples illustrés par les FIGS. 8 et 9, l'utilisation d'une opération unique de mise à jour agrégée par le sous-système client 120 (qui est utilisé par l'agrégateur 132 pour initier des mécanismes de mise àjour, distincts et dans certains cas à étapes multiples, avec le sous-système fournisseur pertinent 104) peut réduire le volume de communications entre le sous-système client 120 et l'agrégateur 132. En outre, cet arrangement simplifie le déploiement des sous-systèmes client 120 et l'intégration de nouveaux sous-systèmes fournisseurs 104, ainsi que noté antérieurement. [0070] Également cités antérieurement, les systèmes et les procédés discutés ci-dessus peuvent s'appliquer à une grande variété d'objets de donnée, au-delà des objets liés au voyage, exposés dans les exemples ci-dessus. C'est-à-dire, que les systèmes et procédés exposés dans les présentes peuvent réduire la complexité de déploiement et la charge de communications lors de la récupération de la mise à jour des données, indépendamment de la nature des données qui sont mises à jour. [0071] Les hommes de métier apprécieront que dans certains modes de réalisation la fonc- tionnalité des applications 212 au niveau de l'agrégateur 132 puisse être implémentée en utilisant du matériel préprogrammé ou des éléments micrologiciels (p. ex. des circuits intégrés spécifiques aux applications (ASICs), des mémoires à lecture seule programmables et effaçables électriquement (EEPROMs, etc.) ou d'autres composants associés. [0072] Le champ d'application des revendications ne saurait être limité par les modes de réalisation exposés ci-dessus dans les exemples, mais doit recevoir l'interprétation la plus large conformément à la description dans sa globalité. 18 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] REVENDICATIONSUn procédé pour agréger et mettre à jour des objets de donnée hétérogènes pour un sous-système client, le procédé comprenant, au niveau du serveur : le stockage d'un ensemble de définitions d'objets de donnée, chaque définition d'objet de donnée fournissant un mappage entre un format d'objet dc donnée agrégé et une pluralité de formats d'objets de donnée de fournisseur ; le stockage d'un ensemble de définitions dc mise à jour, chaque définition de mise à jour fournissant un mappage entre l'opération de mise à jour agrégée et une pluralité de mécanismes de mise à jour de fournisseurs; la réception d'un objet de donnée dans un des formats d'objets de donnée ; la sélection, basée sur le format d'objet de donnée du fournisseur de l'objet de donnée reçu, d'une des définitions d'objet de donnée et la génération d'objets de donnée agrégés conformément à la définition d'objet de donnée sélectionnée ; la présentation des objets de donnée agrégés générés au sous-système client ; la réception d'une opération de mise à jour agrégée du sous-système client pour mettre à jour l'objet de donnée agrégé ; et la sélection, basée sur l'opération de mise à jour agrégée reçue, d'une des définitions de mise à jour et l'initiation d'un mécanisme de mise à jour de fournisseur conformément à la définition de mise à jour sélectionnée. Le procédé de la revendication 1, dans lequel chaque format d'objet de donnée de fournisseur correspond à un indicateur de chaîne de distribution et à un type d'objet de donnée. Le procédé de la revendication 2, dans lequel le format d'objet de donnée agrégé inclut un champ d'identifiant de fournisseur ; le procédé comprenant par ailleurs le stockage d'une pluralité d'identifiants de fournisseurs et des indicateurs correspondants de chaîne de distribution. Le procédé de l'une quelconque des revendications 1 à 3, comprenant par ailleurs : la répétition de la réception, de la sélection et de la génération pour un autre objet de donnée agrégé ; et 19 [Revendication 5] [Revendication 6] [Revendication 7] [Revendication 8] [Revendication 9] [Revendication 10] le stockage de l'objet de donnée agrégé et de l'autre objet de donnée agrégé dans un enregistrement de donnée agrégé avant la présentation. Le procédé de l'une quelconque des revendications 1 à 4, dans lequel le format d'objet de donnée agrégé inclut une portion fournisseur mappée par la définition d'objet de donnée correspondant à la pluralité des formats d'objet de donnée de fournisseur et une portion client qui n'est pas mappée par la définition d'objet de donnée correspondante. Le procédé de l'une quelconque des revendications 1 à 5, dans lequel chaque mécanisme de mise à jour de fournisseur correspond à un indicateur de chaîne de distribution et à un type d'objet de donnée. Le procédé de l'une quelconque des revendications 1 à 6, dans lequel au moins un mécanisme de mise à jour de fournisseur inclut une séquence d'opérations de mise à jour mappécs à l'opération de mise à jour agrégée. Le procédé de l'une quelconque des revendications 1 à 7, dans lequel l'initiation du mécanisme de mise à jour de fournisseur comprend : sur la hase de la définition d'objet de donnée correspondant à l'objet de donnée agrégé, la génération de données de charge utile de mise à jour dans le format d'objet de donnée du fournisseur; et la transmission des données de charge utile de mise à jour conformément au mécanisme de mise à jour du fournisseur. Le procédé de la revendication 1, dans lequel les objets de donnée définissent des éléments de voyage. Un serveur agrégateur pour agréger et actualiser des objets de donnée hétérogènes pour un sous-système client comprenant : une mémoire stockant : un ensemble de définitions d'objets de donnée, chaque définition d'objet de donnée fournissant un mappage entre un format d'objet de donnée agrégé et une pluralité de formats d'objets de donnée de fournisseurs ; un ensemble de définitions de mise à jour, chaque définition de mise à jour fournissant un mappage entre l'opération de mise à jour agrégée et une pluralité de mécanismes de mise à jour de fournisseur; un processeur interconnecté avec la mémoire, le processeur étant configuré pour : recevoir un objet de donnée dans un des formats d'objets de donnée sélectionner, sur la base du format d'objet de donnée du fournisseur de l'objet de donnée reçu, une des définitions d'objet de donnée et la génération d'un objet de donnée agrégé conformément à la définition 20 [Revendication 11] [Revendication 12] d'objet de donnée sélectionnée; présenter l'objet de donnée agrégé généré au sous-système client ; recevoir une opération de donnée agrégée du sous-système client pour mettre à jour l'objet de donnée agrégé; et sélectionner, sur la hase de l'opération de mise àjour agrégée reçue, une des définitions de mise àjour et initier un mécanisme de mise à jour de fournisseur conformément à la définition de mise àjour sélectionnée. L'agrégateur serveur de la revendication 10 étant agencé pour mettre en oeuvre le procédé de l'une quelconque des revendications 2 à 9. Un produit programme d'ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour mettre en oeuvre les étapes du procédé selon l'une quelconque des revendications 1 à 9 lorsque ledit programme fonctionne sur un ordinateur.