Brevet FR3092678A1 — publié le 20200814

Description Titre de l'invention : REGISTRE DISTRIBUÉ [0001] La spécification concerne généralement la synchronisation de données, et pré- cisément un système et procédé de synchronisation des enregistrements de données en réponse à des notifications de mise à jour variables. [0002] La fourniture de différents produits, incluant par exemple des biens et des services liés au voyage (par ex., des vols, des réservations d'hôtel et similaires) requièrent typiquement diverses entités distinctes pour échanger des données définissant divers aspects des produits. Des exemples de telles entités, dans le contexte des produits liés au voyage, incluent, les compagnies aériennes, les agences de voyages, les utilisateurs finaux, les systèmes de réservation et similaires. Bien que de telles entités puissent être conligurées pour échanger des données selon un format standardisé (par ex., selon la norme de capacité de distribution (NDC) basée sur le langage de balisage extensible (XML) dans le contexte de produits liés au voyage), elles peuvent néanmoins employer différents mécanismes pour initier l'échange de données. La variabilité des mécanismes de synchronisation peut conduire à des synchronisations non réussies, ainsi qu'à une configuration chronophage et coûteuse de la part de chaque entité pour expliquer les variations des mécanismes de synchronisation. [0003] Un aspect de la spécification fournit un procédé de synchronisation des enregis- trements de données en réponse à des notifications de mise à jour variables, le procédé comprenant : la réception, au niveau d'un serveur agrégateur, à partir d'un système fournisseur, d'une notification de mise à jour correspondant à un objet de données maître conservé par le système fournisseur ; en réponse à la réception de la notification de mise à jour, la récupération d'un enregistrement au niveau du serveur agrégateur contenant un objet de donnée local qui correspond à l'objet de données maître ; le fait de déterminer si la notification de mise à jour contient des définitions de mise à jour identifiant des modifications de l'objet de données maître ; la sélection entre un mode de synchronisation delta, lorsque la détermination est affirmative et un mode de synchronisation de comparaison d'objets, lorsque la détermination est négative ; lorsque le mode de synchronisation delta est sélectionné, la mise à jour de l'objet de données local selon les définitions de mise à jour ; lorsque le mode de synchronisation de comparaison d'objets est sélectionné, l'obtention d'une copie de l'objet de données maître et la mise à jour l'objet de données local basé sur une comparaison entre l'objet de données local et la copie de l'objet de données maître ; et le stockage de l'objet de données local mis à jour dans l'enregistrement au niveau de l'agrétateur. [0004] Dans certains modes de réalisation, le procédé comprend la transmission d'une noti- fication provenant du serveur agrétateur à un système client. 2 [0005] Dans certains modes de réalisation, le procédé comprend le stockage d'une indication de mise àjour dans une file d'attente au niveau du serveur agrégateur pour récupération par le système client. [0006] Dans certains modes de réalisation, l'obtention d'une copie de l'objet de données maître consiste à déterminer si la notification de mise à jour contient la copie de l'objet de données maître ; si la notification de mise àjour ne contient pas la copie de l'objet de données maître, demander la copie de l'objet de données maître provenant du système fournisseur. [0007] Dans certains modes de réalisation, le procédé comprend par ailleurs la demande de la copie de l'objet de données maître en réponse à la réception d'une demande de l'enregistrement provenant d'un système client. [0008] Dans certains modes de réalisation, le procédé comprend par ailleurs la demande de la copie de l'objet de données maître en réponse à la sélection du mode de synchronisation de comparaison d'objets, avant de recevoir une demande de l'enregistrement provenant d'un système client. [0009] Dans certains modes de réalisation, le procédé consiste par ailleurs, en réponse à la sélection du mode de synchronisation delta et avant la mise àjour de l'objet de données local, à déterminer si les définitions de mise à jour et l'objet de données local sont compatibles. [0010] Dans certains modes de réalisation, le fait de déterminer si les définitions de mise à jour et l'objet de données local sont compatibles comprend, lorsque les définitions de mise à jour identifient un champ et définissent l'une d'une modification ou d'une annulation correspondant au champ : détecter si l'objet de données local contient le champ identifié dans les définitions de mise à jour ; et si l'objet de données local ne contient pas le champ, générer une notification d'en-eur. [0011] Dans certains modes de réalisation, le procédé comprend par ailleurs en réponse à la mise à jour de l'objet de données local selon les définitions de mise à jour suivant la sélection du mode de synchronisation delta, le fait de déterminer si d'autres modifications sur l'objet de données local sont requises. [0012] Dans certains modes de réalisation, le fait de déterminer si d'autres modifications sur l'objet de données local sont requises consiste à : sélectionner et réaliser le mode de synchronisation de comparaison d'objets. [0013] Un autre aspect de la spécification fournit un serveur agrégateur pour synchroniser les enregistrements de données en réponse à des notifications de mise à jour variables, le serveur agrégateur comprenant : une interface de communication ; une mémoire stockant une pluralité d'objets de données locaux correspondant aux objets de données maîtres respectifs conservés par un système fournisseur externe au serveur agrégateur ; et un processeur interconnecté à l'interface de communication et à la mémoire ; le 3 processeur configuré pour : recevoir, via l'interface de communication à partir du système fournisseur, une notification de mise à jour correspondant à un dès objets de données maîtres mis à jour ; en réponse à la réception de la notification de mise à jour, récupérer un des objets de données locaux sélectionnés, qui correspond à l'objet de données maître mis à jour ; déterminer si la notification de mise à jour contient des définitions de mise à jour identifiant des modifications entre l'objet de données maître mis à jour et l'objet de données local ; sélectionner entre un mode de désynchronisation delta, lorsque la détermination est affirmative, et un mode de synchronisation de comparaison d'objets, lorsque la détermination est négative ; lorsque le mode de synchronisation delta est sélectionné, mettre à jour l'objet de données local sélectionné selon les définitions de mise à jour ; lorsque le mode de synchronisation de comparaison d'objets est sélectionné, obtenir une copie de l'objet de données maître mis à jour, et mettre à jour l'objet de données local basé sur une comparaison entre l'objet de données local sélectionné et la copie de l'objet de données maître mis à jour ; et le stockage l'objet de données local mis à jour dans la mémoire. [0014] Dans certains modes de réalisation, le processeur du serveur agrégateur est par ailleurs configure pour : transmettre une notification à un système client. [0015] Dans certains modes de réalisation, le processeur du serveur agrégateur est par ailleurs configure pour : stocker une indication de mise à jour dans une file d'attente pour récupération par un système client. [0016] Dans certains modes de réalisation, le processeur du serveur agrégateur est configuré pour obtenir une copie de l'objet de données maître en : déterminant si la notification de mise à jour contient la copie de l'objet de données maître ; si la notification de mise à jour ne contient pas la copie de l'objet de données maître, demandant la copie de l'objet de données maître provenant du système fournisseur. [0017] Dans certains modes de réalisation, le processeur du serveur agrégateur est par ailleurs configuré pour : demander la copie de l'objet de données maître en réponse à la réception d'une demande de l'enregistrement provenant d'un système client. [0018] Dans certains modes de réalisation, le processeur du serveur agrégateur est par ailleurs configuré pour : demander la copie de l'objet de données maître en réponse à la sélection du mode de synchronisation de comparaison d'objets, avant de recevoir une demande de l'enregistrement provenant d'un système client. [0019] Dans certains modes de réalisation, le processeur du serveur agrégateur est par ailleurs configuré pour : en réponse à la sélection du mode de synchronisation delta et avant la mise à jour de l'objet de données local, déterminer si les définitions de mise à jour est l'objet de données local sont compatibles. [0020] Dans certains modes de réalisation, le processeur du serveur agrégateur est par ailleurs configuré pour déterminer si les définitions de mise à jour et l'objet de données local sont compatibles, lorsque les définitions de mise àjour identifient un champ et définissent l'une des modifications ou une annulation correspondant au champ : en détectant si l'objet de données local contient le champ identifié dans les définitions de mise à jour ; et lorsque l'objet de données local ne contient pas le champ, en générant une notification d'erreur. [0021] Dans certains modes de réalisation, le processeur du serveur agrégateur est par ailleurs configuré pour : en réponse à la mise à jour de l'objet de données local selon les définitions de mise àjour suivant la sélection du mode de synchronisation delta, déterminer si d'autres modifications de l'objet de données local sont requises. [0022] Dans certains modes de réalisation, le processeur du serveur agrégateur est par ailleurs configuré pour déterminer si d'autres modifications de l'objet de données local sont requises en : sélectionnant et réalisant le mode de synchronisation de comparaison d'objets. [0023] Un autre aspect de la spécification fournit un support lisible par ordinateur non transitoire stockant un programme informatique ayant des instructions qui, lorsqu'il est exécuté par un dispositif ou système informatique, amène le dispositif ou système informatique à réaliser le procédé de l'un quelconque des modes de réalisation exposés ci-dessus. [0024] Un autre aspect de la spécification fournit un produit de programme informatique comprenant des instructions de programme stockées sur un support lisible par ordinateur pour exécuter les étapes du procédé selon l'un quelconque des modes de réalisation exposés ci-dessus, lorsque ledit programme est exécuté sur un ordinateur. [0025] Les modes de réalisation sont décrits en référence aux figures suivantes dans lesquelles : [0026] [fig.1] représente un système de synchronisation des enregistrements de données. [0027] [fig.2] représente certains composants internes du serveur agrégateur de la FIG. 1. [0028] [fig.3] représente un procédé de synchronisation des enregistrements de données en réponse à des notifications de mise à jour variables dans le système de la FIG. 1. [0029] [fig.4] représente une partie du système de la FIG. 1 pendant la réalisation des blocs 305-315 du procédé de la FIG. 3. [0030] [fig.5] représente une partie du système de la FIG. 1 à la fin du procédé de la FIG. 3. [0031] [fig.6] représente une partie du système de la FIG. 1 pendant une autre réalisation des blocs 305-315 du procédé de la FIG. 3. [0032] [fig.7] représente une partie du système de la FIG. 1 pendant une autre réalisation des blocs 305-315 et 335 du procédé de la FIG. 3. [0033] La FIG. 1 représente un système 100 de synchronisation des enregistrements de données. Les enregistrements de données, dans les modes de réalisation examinés dans les présentes, correspondent aux produits tels que des produits et services liés au voyage (par ex., des vols, des réservations d'hôtel, des locations de voiture et similaires). Plus précisément, les produits examinés dans les exemples ci-dessous sont des billets d'avion et des services liés (par ex., les services de contrôle des bagages, de la nourriture en vol, des divertissements et similaires). Cependant, comme cela sera évident pour les hommes de métier, les systèmes et procédés examinés ci-dessous peuvent également être appliqué à divers autres types d'enregistrement de données. [0034] La fourniture des produits mentionnés ci-dessus est typiquement contrôlée par une entité fournisseur, telle qu'une compagnie aérienne dans le cas de produits examinés en rapport avec les exemples fournis dans les présentes. Le système 100 inclus un système fournisseur 104 (par ex., un ou plusieurs serveurs ou autres dispositifs informatiques appropriés), qui dans cet exemple est exploité par l'entité fournisseur. Le système 100 peut inclure une pluralité de systèmes fournisseurs 104, chacun exploité par des entités fournisseur respectives (par ex., d'autres compagnies aériennes), bien que seul un système fournisseur 104 soit représenté à des fins d'illustration. Le système fournisseur 104 stocke un référentiel 108 contenant une pluralité d'objets de données maîtres. Les objets de données maîtres peuvent également être appelés enregistrements de noms de passagers (PNR) dans le contexte d'un échange de données basé sur un système de distribution globale (GDS) ou d'Autres enregistrements dans le contexte d'un échange de données basé sur un NDC. [0035] Chaque objet de données maître définit un produit, ou une combinaison de produits, qui a été acheté(e) (par ex. par des utilisateurs finaux de produits). Ainsi, dans les exemples examinés ci-dessous, chaque objet de données maître définit un vol exploité par l'entité fournisseur, et/ou des services auxiliaires associés au vol. Chaque objet de données maître contient par conséquents différents champs. Certains champs définissent des attributs du produit, tels que les identifiants du produit (par ex., les identifiants de service, les identifiants d'articles et similaires), les lieux, les dates et hem-es correspondant aux produits (par ex., les heures de vol et autres données d'itinéraire). D'autres champs de l'objet de données maître définisse les attributs du client, tels que les identifiants du client (par ex., identifiant le voyageur, en cas de produits liés au voyage tels que les vols susmentionnés), les données de paiement, et similaires. [0036] Les objets de données maîtres sont générés pour être stockés dans le référentiel 108 en réponse aux demandes d'achat (qui peuvent également être appelées ordres) reçues au niveau du système fournisseur 104 à partir d'autres éléments du système 100. Par exemple, les demandes peuvent être reçues à partir d'un système client 112, via un réseau 116 (par ex., toute combinaison de réseaux locaux et étendus, incluant Internet). Le système client 112, dans le présent exemple, est exploité par une agence de voyages et génère et transmet par conséquent des demandes pour acheter des produits au système fournisseur 108 pour le compte d'utilisateurs finaux (par ex., des voyageurs). 6 Le système 100 peut inclure une pluralité de systèmes clients 112, bien que seulement un système client 112 soit représenté à la FIG. 1 à des fins d'illustration. [0037] Divers autres mécanismes pour initier la création d'objets de données maîtres dans le référentiel 108 sont également envisagés. Par exemple, les utilisateurs finaux (via des dispositifs informatiques supplémentaires non illustrés à la FIG. 1) peuvent initier la création d'objets de données maîtres via l'interaction directe avec un site Web hébergé par le système fournisseur 104, plutôt que par l'intermédiaire du système client 112. Divers mécanismes de création d'objets de données maîtres dans le référentiel 108 seront évidents pour les hommes de métier, tels que le mécanisme d'« offre » et d'« ordre » par la norme NDC. La création d'objets de données maîtres en réponse aux demandes d'achat de produits n'est pas examinée plus en détail dans les présentes. [0038] Le système client 112 est configuré pour obtenir des données contenues dans les objets de données maîtres stockés dans le référentiel 108. Les données obtenues par le système client 112 peuvent être présenté aux utilisateurs desservis par le système client 112, et peuvent être également manipulés au niveau du système client 112 pour initier des demandes de mises à jour pour transmission au système fournisseur 104 (par ex., pour modifier une réservation de vol). En d'autres ternies, le système 100 permet au système client 112 initié des mises à jour des objets de données maîtres du référentiel 108. Le système client 112 peut être configuré pour initier de telles mises à jour en transmettant des demandes, directement ou indirectement, au système fournisseur 104. Une grande variété de mises à jour peut être demandée par le système client 112 selon tout mécanisme d'échange de données approprié, tels que ceux précisés par la nonne NDC. Des exemples de telles mises à jour incluent les annulations, les modifications de dates et/ou de l'heure correspondant à un billet acheté, l'achat de produits supplémentaires tels que les services auxiliaires d'un vol, et similaires. [0039] Des mises à jour des objets de données maîtres dans le référentiel 108 peuvent également être initiées par le système fournisseur 104 lui-même, en l'absence d'une demande provenant du système client 112. De telles mises à jour peuvent inclure la replanification d'un vol, des annulations et similaires. De telles mises à jour peuvent typiquement être communiquées au système client 112 pour permettre au système client 112 de notifier les utilisateurs finaux, de demander d'autres modifications pour recevoir les mises à jour initiées par le fournisseur, et similaires Comme noté ci-dessus, le système 100 peut inclure une pluralité de systèmes fournisseurs 104. Chaque système fournisseur 104 peut mettre en oeuvre un mécanisme différent pour communiquer les mises à jour initiées par le fournisseur au système client pertinent 112. Le système 100 inclut également par conséquent un serveur agrégateur 120, mis en oeuvre comme un ou plusieurs (par ex. réparti(s) géographiquement) dispositifs informatiques reliés de manière logique. Le serveur agrégateur 120, également appelé simplement 7 dans les présentes l'agrégateur 120, est configuré pour faire l'intermédiaire entre les systèmes fournisseurs (par ex., le système fournisseur 104) les systèmes clients (par ex., le système 112). [0040] Comme examiné ci-dessous, précisément dans le contexte de mises àjour initiées par le fournisseur, plutôt que de mises à jour du référentiel 108 étant communiquées directement au système client 112, les mises à jour sont communiquées à l'agrégateur 120 à partir du système fournisseur 104. L'agrégatcur 120, à son tour, est configuré pour détecter quel mécanisme de mises à jour est employé par le système fournisseur 104, et pour traiter les données mises à jour en conséquence pour les fournir au système client 112. Le système client 112 est par conséquent libéré de l'obligation de recevoir divers mécanismes de mise àjour et a au lieu de cela besoin de récupérer uniquement les données provenant de l'agrégateur 120 pour les présenter et les manipuler. [0041] L'agrégateur 120 conserve un référentiel local 124. Le référentiel local 124 contient des copies locales (également appelées objets de données locaux dans les présentes) d'au moins un sous-ensemble d'objets de données maîtres dans le référentiel 108. Comme examiné plus en détail ci-dessous, l'agrégatcur 120 est configuré, en réponse aux mises àjour du référentiel 108 initiées par le fournisseur, pour synchroniser les objets de données locaux avec les objets de données maîtres, permettant la fourniture d'objets de données locaux mis àjour au système client 112. En particulier, l'agrégateur 120 est configuré pour détecter un d'un nombre de mécanismes de synchronisation employés par le fournisseur 104, et pour traiter les notifications de mise à jour provenant du système fournisseur 104 selon la détection, permettant aux mises à jour d'être acheminées jusqu'au système client 112 selon un mécanisme cohérent, quel que soit le mécanisme de notification de mises à jour qu'emploie le système fournisseur 104 (ou tout autre système fournisseur). [0042] En retournant à la FIG. 2, avant d'examiner la fonctionnalité du système 100 plus en détail, certains composants de l'agrégateur 120 seront examinés plus en détail. [0043] Comme illustré à la FIG. 2, l'agrégateur 120 inclus au moins un processeur 200, tel qu'une unité centrale de traitement (CPU) ou similaire. Le processeur 200 être interconnecté à une mémoire 204, mise en oeuvre comme un support lisible par ordinateur non transitoire approprié (par ex., une combinaison appropriée de sous-systèmes de mémoire volatiles et non volatiles, incluant l'un quelconque ou plusieurs parmi une mémoire vive (RAM), une mémoire morte (ROM), une mémoire morte programmable effaçable électriquement (EEPROM), une mémoire flash, le stockage informatique magnétique, et similaire. Le processeur 200 et la mémoire 204 sont en général composés d'un ou de plusieurs circuits intégrés (CI). [0044] Le processeur 200 est aussi interconnecté à une interface de communication 208, qui 8 permet à l'agrégateur 120 de communiquer avec les autres dispositifs informatiques du système 100 (par ex., système fournisseur 104 et le système client 112) via le réseau 116. L'interface de communication 208 inclut par conséquent tout composant nécessaire (par ex., les contrôleurs d'interface réseau (NIC), les unités de radio, et similaires) pour communiquer via le réseau 116. Lcs composants spécifiques de l'interface de communication 208 sont sélectionnés sur la hase de la nature du réseau 116. L'agrégateur 120 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 illustrés). [0045] Les composants de l'agrégateur 120 mentionnés ci-dessus peuvent être déployés dans un même boîtier, ou dans un format distribué. Dans certains exemples, l'agrégateur 120 inclut par conséquent une pluralité de processeurs, soit en partageant la mémoire 204 et l'interface de communication 208, soit chacune ayant des mémoires et des interfaces de communications associées distinctes. [0046] La mémoire 204 stocke le référentiel local 124 introduit en rapport avec la FIG. 1. La mémoire 204 stocke également une pluralité d'instructions de programmation lisible par ordinateur, exécutables par le processeur 200 sous la forme d'applications diverses, incluant une application de synchronisation 212. Comme le comprendront les hommes de métier, le processeur 200 exécute les instructions de l'application 212 (et toute autre application appropriée) afin de réaliser diverses actions définies par les instructions contenues dans celui-ci. Dans la description ci-dessous, le processeur 200 et plus généralement l'agrégateur 120 sans censés être configurés pour réaliser ces 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 de synchronisation 212, comme examiné ci-dessous, configure l'agrégateur 120 pour recevoir des notifications de mise à jour provenant du système fournisseur 104 définissant les mises à jour initiées par le fournisseur du référentiel 108, et pour traiter les notifications de mise à jour pour synchroniser le référentiel local 124 avec le référentiel 108. L'exécution de l'application de synchronisation 212 configure par ailleurs l'agrégateur 120 pour notifier le système client 112 lorsque le processus de synchronisation susmentionné est terminé. [0047] En retournant à la FIG. 3, certains aspects du fonctionnement du système 100 seront décrits plus en détail. Spécifiquement, la FIG. 3 illustre un procédé 300 de synchronisation des enregistrements de données synchronisées en réponse à des notifications de mise à jour variables. Le procédé 300 sera décrit en rapport avec sa réalisation dans le système 100. En particulier, les blocs du procédé 300 sont réalisées par l'agrégateur 120 via l'exécution de l'application de synchronisation 212 par le processeur 200. [0048] Au bloc 305, l'agrégateur 120 est configuré pour recevoir une notification de mise à 9 jour provenant du système fournisseur 104. La notification de mise àjour correspond à l'un des objets de données maîtres conservés par le système fournisseur 104 dans le référentiel 108. En général, la notification de mise àjour contient au moins un identifiant (qui peut également être appelé un identifiant d'ordre ou ID d'ordre) de l'objet de données maître correspondant. Comme examiné ci-dessous plus en détail, selon le mécanisme de mise à jour employé par le système fournisseur 104, la notification de mise à jour peut, mais ne doit pas nécessairement, contenir également d'autres données. [0049] En réponse à la réception de la notification de mise à jour au bloc 305, l'agrégateur 120 est configuré pour récupérer un enregistrement provenant du référentiel local 124 qui contient l'objet de données local correspondant à l'objet de données maître identifié dans la notification de mise àjour. Les objets de donnés locaux dans le répertoire local 124, comme noté ci-dessus, contiennent des copies des objets de données maîtres dans le répertoire 108, et au bloc 310 l'agrégateur 120 est ainsi configuré pour récupérer l'objet de données local ayant le même ID d'ordre que l'ID d'ordre dans la notification de mise à jour. Si le référentiel local 124 ne contient pas d'objet de données local ayant l'ID d'ordre pertinent, l'agrégateur 120 peut être configuré pour générer un message d'erreur, par ex., pour transmission à un administrateur. [0050] Ayant récupéré avec succès l'objet de données local pertinent au bloc 310, r agregatcur 120 est configuré pour passer au bloc 315. Au bloc 315, l'agrégateur 120 est configuré pour sélectionner entre des modes de synchronisation distincts, basés sur le contenu de la notification de mise à jour provenant du bloc 305. Comme discuté plus en détail ci-dessous, dans certaines réalisations du procédé 300, la notification de mise à jour peut contenir des définitions de mise à jour identifiant ds modifications de l'objet de données maitre. Les définitions de mise à jour identifient des attributs individuels dans l'objet de données maître qui ont été altérés par le système fournisseur 104. Dans d'autres exemples, cependant, la notification de mise à jour ne peut pas contenir de telles définitions de mise à jour. Au lieu de cela, la notification de mise à jour peut simplement contenir une copie complète de l'objet de données maître (incluant à la fois les attributs à jour et les attributs qui n'ont pas été mis à jour). Dans d'autres exemples, la notification de mise à jour ne peut contenir ni des définitions de mise à jour, ni une copie pleine de l'objet de donné maître. [0051] Au bloc 315, l'agrégateur 120 est configuré pour déterminer si la notification de mise à jour inclut des définitions de mise à jour, comme mentionné ci-dessus. Les définitions de mise à jour sont typiquement indiquées dans la notification de mise à jour, par exemple entre des éléments de formatage prédéfinis (par ex., des champs spécifiques dans un format à base XML), et l'agrégateur 120 est par conséquent configuré, au bloc 315, pour examiner la présence de tels éléments de formatage prédéfinis dans la notification de mise à jour. Dans certains modes de réalisation, la réalisation du bloc 315 peut précéder la réalisation du bloc 310. C'est-à-dire qu'il n'est pas nécessaire de récupérer l'objet de donnés local pertinent avant de réaliser le bloc 315. Lorsque la notification de mise à jour contient des définitions de mise à jour (c.-à-d. lorsque la détermination au bloc 315 est affirmative), l'agrégateur 120 est configure pour sélectionner un mode de synchronisation delta pour traiter la notification de mise à jour. Lorsque, d'un autre côté, la notification de mise à jour ne contient pas de définitions de mise à jour (c.-à-d. lorsque la détermination au bloc 315 est négative), l'agrégateur 120 est configuré pour sélectionner un mode de synchronisation de comparaison d'objets pour traiter la notification de mise à jour. Les de modes susmentionnés seront examinés en détail ci-dessous. [0052] En référence à la FIG. 4, une partie du système 100 (excluant le système client 112) est illustrée, illustrant une réalisation exemplaire des blocs 300, 310 et 315. Particulier, le système fournisseur 104 est supposée avoir mis à jour un objet de données maître 400 stocké dans le référentiel 108. En particulier, l'objet de données maître 400 définit une réservation de vol pour un utilisateur nommé Alice Smith. Le vol est exploité par la compagnie aérienne ACME (supposée être également l'opérateur du système fournisseur 104), et part de Toronto (YYZ) le 21 décembre 2018 pour Nice (NCE). L'objet de données maître 400 est supposé avoir été mis à jour pour changer l'heure de départ du vol de 16h10 à 17h00. Comme cela est à présent évident, de nombreux autres objets de données maîtres dans le référentiel 108, correspondant à toutes les autres réservations pour le même vol, seront également mis à jour en réponse à la modification de l'heure de départ. Parce que la mise à jour de l'heure départ n'a pas encore été synchronisée avec le référentiel local 124 au niveau de l'agrégateur 120, un objet de données local correspondant 406 contient encore l'heure de départ à présent obsolète de 16h30. [0053] Comme également illustré à la FIG. 4, l'objet de données local 406 contient une copie (bien qu'une copie obsolète) de l'objet de données maître 400, mais peut également contenir des données supplémentaires telles qu'un identifiant local attribué à l'enregistrement de données local 406 par l'agrégateur 120. Divers autres champs peuvent également être contenus dans l'enregistrement de données local, incluant l'information fournie à l'agrégateur 406 par le système client 112. Une telle information est stockée dans l'enregistrement de données local 406, mais est exempte de mécanismes de synchronisation examinés dans les présentes. [0054] Le système fournisseur 104 est configuré pour générer une notification de mise à jour 408 pour la transmettre à l'agrégateur 120 via le réseau 116 en réponse à la mise à jour susmentionnée de l'objet de données maître 400. Comme illustré à la FIG. 4, dans cet exemple la notification de mise à jour ne contient pas l'objet de données maître 11 complet 400. Au lieu de cela, la notification de mise à jour contient l'ID d'ordre de l'objet de données maître 400, et les définitions de mise àjour marquées par l'élément « », indiquant que l'heure de départ du vol a été mise àjour. Par exemple, l'élément « » indique une modification d'un attribut existant (par ex., le champ « heure »). D'autres éléments, tels qu'un élément « », « » ou autre élément approprié peuvent être employés pour signaler la suppression d'un attribut produit (c.-à-d. un ensemble d'attributs) de l'objet de données maître 400. Encore d'autres éléments, tels qu'un élément « », peuvent être employés pour indiquer l'ajout d'un attribut à l'objet de données maître 400 qui n'était pas présent auparavant. La détermination au bloc 315 dans le présent exemple est par conséquente affirmative, et l'agrégatcur 120 est configuré pour sélectionner le mode de synchronisation delta pour traiter la notification de mise àjour 408. [0055] En retournant à la FIG. 3, ayant sélectionné le mode de synchronisation delta au bloc 315 (c.-à-d. une détermination « oui » comme illustré à la FIG. 3), l'agrégatcur 120 est configuré pour mettre à jour l'objet de données local 406 selon les définitions de mise à jour. En particulier, l'agrégatcur 120 est configuré pour passer au bloc 320, et déterminer si les définitions de mise à jour dans la notification 408 sont compatibles avec l'objet de données local 406. La détermination au bloc 320 cherche à détecter la désynchronisation de l'objet de données local 406 avec l'objet de données maître 400 prédatant la notification de mise à jour 408. En particulier, au bloc 320 l'agrégatcur 120 est configuré pour déterminer si l'objet de données local 406 contient le champ identifié dans les définitions de mise à jour de la notification 408. Dans le présent exemple, comme vu à la FIG. 4, la notification de mise à jour 408 définit un changement du champ « Heure », qui est également contenu dans l'objet de données local 406. La détermination au bloc 320 est par conséquent affirmative, et la réalisation du procédé 300 passe au bloc 325. [0056] Une détermination négative au bloc 320 est effectuée lorsque les définitions de mises à jour précisent une modification ou une suppression (par ex., une annulation d'un service) d'un champ qui n'existe pas dans l'objet de données local 406. Par exemple, une notification de mise à jour définissant une modification d'un service de contrôle des bagages pour le vol présenté à la FIG. 4 (par ex, d'un sac contrôlé à deux sacs contrôlés) est déterminée comme incompatible, dans la mesure où l'objet de données local 406 ne contient aucune indication d'un service de bagages contrôlés. La détermination au bloc 320 dans cet exemple est négative, et l'agrégateur 120 est configuré pour initier une procédure de traitement d'erreur. La procédure de traitement d'erreur peut inclure l'obtention d'une copie complète de l'objet de données maître 400 générant une alerte à l'attention d'un administrateur et/ou du système client 112 ou similaire. 12 [0057] Comme il sera à présent évident, d'autres définitions de mise à jour peuvent préciser des insertions dans l'objet de données maître 400, qui requiert l'insertion de champs non présents auparavant dans l'objet de données local 406 pour synchroniser l'objet de données local 406 avec l'objet de données maître. L'évaluation de la compatibilité des insertions peut inclure la détection d'une incompatibilité lorsque le champ correspondant existe déjà dans l'objet de données local 406. [0058] En continuant avec l'exemple de la FIG. 4, dans lequel la détermination au bloc 320 est affirmative, au bloc 325 l'agrégateur 120 est configuré pour déterminer s'il faut ou non contrôler d'autres modifications non synchronisées. Les modifications non synchronisées, dans cette discussion, sont des modifications apportées de l'enregistrement de données maître 400 qui ne sont pas reflétées dans la notification de mise à jour 408. Par exemple, une précédente erreur de synchronisation (par ex., en raison d'une perte de communication entre le système fournisseur 104 et l'agrégatcur 120) peut avoir donné lieu à une modification de l'objet de données maître 400 n'étant pas synchronisé avec succès dans le référentiel local 124. La détermination au bloc 325 peut se baser sur l'un quelconque d'une variété de facteurs. Par exemple, dans certains modes de réalisation l'agrégatcur 120 est configuré pour toujours contrôler les modifications non synchronisées (par ex., la détermination au bloc 325 le est automatiquement affirmative). Dans d'autres modes de réalisation, la détermination peut se baser sur un temps écoulé depuis le précédent contrôle des modifications non synchronisées. [0059] Dans d'autres modes de réalisation, la détermination au bloc 325 est effectué sur la base des contenus de la notification de mise à jour reçu au bloc 305. Spécifiquement, lorsque la notification de mise à jour reçue au bloc 305 contient non seulement les définitions de mise à jour susmentionnées, mais aussi une copie de l'objet de données maître 400, la détermination au bloc 325 est affirmative. En revanche, lorsque la notification de mise à jour contient des définitions de mise à jour mais ne contient pas une copie de l'objet de données maître 400 (comme illustré à la FIG. 4), la détermination au bloc 325 est négative. Suite à une détermination affirmative au bloc 325, l'agrégateur 120 est configuré pour passer au bloc 335, ce qui sera examiné ci-dessous comme un élément d'un mode de synchronisation de comparaison d'objets. Suite à une détermination négative au bloc 325, l'agrégateur 120 est configuré pour passer au bloc 330 du procédé 300. [0060] Au bloc 330, l'agrégateur 120 est configuré pour appliquer les mises à jour - dans le présent exemple, les mises à jour précisées par les définitions de mise à jour dans la notification 408 - et pour stocker une copie locale mise à jour de l'objet de données maître 400. Comme illustré à la FIG. 5, suite à la réalisation du bloc 330, le référentiel local 124 contient un objet de données local mis à jour 406' à la place de l'objet de données local 406 illustré à la FIG. 4. Comme vu à la FIG. 5, l'objet de données local 13 mis à jour 406' contient l'heure de départ mise àjour de 17h00, comme précisé dans la notification de mise à jour 408. [0061] Au bloc 330, l'agrégateur 120 peut également être configuré pour notifier le système client 112 des mises à jour appliqués au référentiel local 124. Par exemple, en référence à la FIG. 5, l'agrégateur 120 peut être configuré pour transmettre une notification 500 au système client 112. La notification 500 peut contenir l'objet de données local mis àjour 406', peut simplement contenir un indicateur selon lequel l'objet de données local 406' a été mis à jour, en invitant le système client 112 à récupérer ensuite l'objet de données local 406'. Diverses formes de notifications peuvent être employées, telles que la génération d'un e-mail pour le transmettre à une adresse e-mail associée au système client 112. Dans d'autres exemples, l'agrégateur 120 peut placer un indicateur (par ex., l'ordre d'ID de l'objet de données local 406') dans une file d'attente 504 pour récupération périodique par le système client 112. En d'autres termes, la transmission de l'objet de données local au système client 112 peut être tirée par le système client 112 plutôt que poussée vers le système client 112. [0062] En retournant à la FIG. 3, le mode de synchronisation de comparaison d'objets mentionné ci-dessus sera examiné plus en détail. Lorsque la détermination au bloc 315 est négative, indiquant que la notification de mise àjour reçue au bloc 305 ne contient aucune définition de mise à jour, l'agrégateur 120 passe au bloc 335 au lieu du bloc 320. En référence à la FIG. 6, les mêmes objets de données locaux et maîtres 400 et 406 respectivement, sont illustrés à la FIG. 4. Cependant, plutôt que la notification de mise à jour 408 contenant des définitions de mise à jour (mais aucune copie de l'objet de données maître 400), dans l'exemple de la FIG. 6, le système fournisseur 104 transmet une notification de mise à jour 600 à l'agrégateur 104 contenant une copie complète de l'objet de données maître 400. D'une note particulière, tandis que la notification de mise à jour 600 inclut une copie de l'objet de données maitre 400, la notification de mise à jour 600 ne contient pas de définitions de mise à jour précisant quelles modifications ont précipité la transmission de la notification de mise à jour 600 (c.-à-d. La modification de l'heure de départ, dans le présent exemple). [0063] La détermination au bloc 315 est par conséquent négative, et l'agrégateur 120 sé- lectionne le mode de synchronisation delta pour traiter la notification de mise à jour 600. Dans le mode de synchronisation de comparaison d'objets, l'agrégateur 120 est configuré pour obtenir une copie actuelle de l'objet de données maître 400 au bloc 335. Divers mécanismes sont envisagés, via lesquels l'agrégateur 120 obtient l'objet de données maître 400. Dans l'exemple de la FIG. 6, l'objet de données maître 400 est reçu avec la notification de mise à jour 600 elle-même, et par conséquent la réalisation du bloc 335 nécessite seulement l'extraction de l'objet de données maître 400 à partir de la notification de mise à jour 600. 14 [0064] Dans d'autres exemples, comme illustré à la FIG. 7, la notification de mise à jour ne contient aucune copie de l'objet de données maître 400. Comme illustré à la FIG. 7, en réponse aux mêmes modifications susmentionnées, le système fournisseur 104 transmet une notification de mise à jour 700 à l'agrégatcur 120. La notification de mise à jour 700 ne contient pas de définitions dc mise à jour, menant à une détermination négative au bloc 315 (et à la sélection du mode de synchronisation de comparaison d'objets). La notification de mise à jour 700 ne contient cependant aucune copie de l'objet de données maître 400. Au bloc 335, l'agrégatcur 120 et par conséquent configuré pour obtenir la copie de l'objet de données maître 400 en transmettant une demande 704 au système fournisseur 104, par ex. contenant l'ID d'ordre de la notification de mise à jour 700. [0065] La transmission de la demande 704 ne doit pas immédiatement suivre la déter- mination négative au bloc 315. Dans certains exemples, l'agrégatcur 120 est configure pour notifier le système client 112 qu'une mise à jour s'est produite (par ex., via la notification poussée 500 ou le placement d'une notification dans la file d'attente 504 comme discuté en rapport avec la FIG. 5). L'agrégatcur 120 est alors configuré pour attendre jusqu'à ce que le système client 112 demande à l'objet de données local 406 de transmettre la demande 704. [0066] En retournant à la FIG. 3, ayant obtenu la copie de l'objet dc données maître 400, l'agrégatcur 120 est configuré pour réaliser le bloc 340. Au bloc 340 r agregatcur 120 compare l'objet de données maître 400 à l'objet de données local 406 pour détecter les mises à jour non reflétées actuellement dans l'objet de données local 406. C'est-à-dire que chaque champ de l'objet de données maître est comparé au champ correspondant de l'objet de données local 406 et vice versa, pour identifier tout changement, ajout, suppression, et similaires qui doivent être synchronisés avec l'objet de données local 406. Ayant détecté et appliqué toute mise à jour sur l'objet de données local 406 (c.-à-d. pour produire l'objet de données local mis à jour 406' comme illustré à la FIG. 5), l'agrégateur 120 est configuré pour passer au bloc 330, comme examiné ci-dessus. [0067] Les hommes de métier apprécieront que dans certains modes de réalisation, la fonc- tionnalité de l'application 212 puisse être mise en oeuvre en utilisant des éléments micrologiciels ou matériels préprogrammés (par ex., des circuits intégrés spécifiques à l'application (ASIC), des mémoires mortes programmables effaçables électriquement (EEPROM), etc.), ou d'autres composants liés. [0068] L'étendue ne devrait pas être limitée par les modes de réalisation exposés dans les exemples ci-dessus, mais l'interprétation la plus large possible devrait lui être donné de manière cohérente avec la description dans son ensemble. [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4]