FR3090156A1 - Registre distribué - Google Patents

Registre distribué Download PDF

Info

Publication number
FR3090156A1
FR3090156A1 FR1873072A FR1873072A FR3090156A1 FR 3090156 A1 FR3090156 A1 FR 3090156A1 FR 1873072 A FR1873072 A FR 1873072A FR 1873072 A FR1873072 A FR 1873072A FR 3090156 A1 FR3090156 A1 FR 3090156A1
Authority
FR
France
Prior art keywords
vote
remote
proposed update
local
update
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1873072A
Other languages
English (en)
Other versions
FR3090156B1 (fr
Inventor
Mathieu (Philippe) Beynel
Maxime GODEAU
Olivier Cazeaux
Jeremy TEYSSEDRE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Amadeus SAS
Original Assignee
Amadeus SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Amadeus SAS filed Critical Amadeus SAS
Priority to FR1873072A priority Critical patent/FR3090156B1/fr
Priority to US16/716,869 priority patent/US11706018B2/en
Publication of FR3090156A1 publication Critical patent/FR3090156A1/fr
Application granted granted Critical
Publication of FR3090156B1 publication Critical patent/FR3090156B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/187—Voting techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/178—Techniques for file synchronisation in file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/273—Asynchronous replication or reconciliation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G06F9/467—Transactional memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/46—Secure multiparty computation, e.g. millionaire problem
    • H04L2209/463—Electronic voting

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Tourism & Hospitality (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Mining & Analysis (AREA)
  • Accounting & Taxation (AREA)
  • Marketing (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Computing Systems (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Operations Research (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Multi Processors (AREA)
  • Computer And Data Communications (AREA)

Abstract

Un procédé pour tenir à jour un registre distribué au niveau d’un nœud client inclut : le stockage d’un registre distribué définissant une pluralité d’enregistrements, chacun contenant un ensemble de valeurs ; le stockage (i) d’une pondération de vote local correspondant au nœud client et (ii) des pondérations de votes distants pour une pluralité de nœuds clients distants ; l’obtention d’une mise à jour proposée pour un enregistrement du registre distribué ; la génération d’un vote local pour appliquer ou rejeter la mise à jour proposée et la transmission du vote local aux nœuds clients distants ; la réception de votes distants pour appliquer ou rejeter la mise à jour proposée des nœuds clients distants ; la détermination s’il faut permettre la mise à jour proposée sur la base (i) du vote local et de la pondération du vote local et (ii) les votes distants et les pondérations correspondantes de votes distants ; et selon la détermination, l’application de la mise à jour proposée pour le registre distribué ou le rejet de la mise à jour proposée. Figure pour l’abrégé : Fig. 3A

Description

Description
Titre de l’invention : REGISTRE DISTRIBUÉ
[0001] La spécification concerne de façon générale le stockage distribué de données et spécifiquement un système et un procédé pour tenir à jour un registre distribué.
[0002] Divers systèmes, tels que ceux qui sont configurés pour conserver des données de voyage (p. ex. le statut d’un vol, la réservation, les données d’enregistrement, les données d’identification du passager, et d’autres) sont implémentés par une pluralité d’entités distinctes, chacune stockant des sous-ensembles distincts du volume total de données exploitées dans le système. Typiquement, aucune entité seule n’exerce de contrôle sur le volume total de données. Les sous-ensembles susmentionnés peuvent cependant se chevaucher les uns avec les autres à divers degrés et une synchronisation entre les entités peut donc être nécessaire. Une telle synchronisation peut-être réalisée via des requêtes et des réponses bidirectionnelles entre chaque paire d’entités ou via des exportations en masse et des importations subséquentes pour transférer les données entre entités. Les mécanismes susmentionnés peuvent être chronophages, intensifs sur le plan informatique, ou les deux.
[0003] Un aspect de la spécification fournit un dispositif informatique pour implémenter un nœud client d’un registre distribué, le dispositif informatique comprenant : une mémoire stockant (i) un registre distribué définissant une pluralité d’enregistrements, chacun contenant un ensemble de valeurs ; (ii) une pondération de vote local correspondant au nœud client et (iii) des pondérations de votes distants pour une pluralité de nœuds clients distants ; un processeur connecté à la mémoire, le processeur étant configuré pour : obtenir une mise à jour proposée pour un enregistrement du registre distribué ; générer un vote local pour appliquer ou rejeter la mise à jour proposée et transmettre le vote local aux nœuds clients distants ; recevoir des votes distants pour appliquer ou rejeter la mise à jour proposée des nœuds clients distants ; déterminer s’il faut permettre la mise à jour proposée sur la base (i) du vote local et de la pondération du vote local et (ii) des votes distants et des pondérations correspondantes des votes distants ; et selon la détermination, appliquer la mise à jour proposée pour le registre distribué ou rejeter la mise à jour proposée.
[0004] Selon un autre aspect du dispositif informatique, la mise à jour proposée est associée à un type actuel de transaction d’une pluralité de types de transaction ; le processeur étant par ailleurs configuré pour : stocker une pluralité de pondérations de votes locaux en mémoire, la pondération de vote local et les autres pondérations de votes locaux correspondant chacune à un type respectif parmi les types de transactions ; mettre en œuvre la détermination sur la base d’une des pondérations des votes locaux et des autres pondérations de votes locaux correspondant au type actuel de transaction associé à la mise à jour proposée.
[0005] Selon un autre aspect du dispositif informatique, la mise à jour proposée est associée à une valeur actuelle de l’ensemble des valeurs ; le processeur étant par ailleurs configuré pour : stocker une pluralité d’autres pondérations de votes locaux en mémoire, la pondération de vote local et les autres pondérations de votes locaux correspondant chacune à une valeur respective de l’ensemble des valeurs ; et mettre en œuvre la détermination sur la base d’une des pondérations de votes locaux et des autres pondérations de votes locaux correspondant à la valeur actuelle associée à la mise à jour proposée.
[0006] Selon un autre aspect du dispositif informatique, le processeur est configuré pour obtenir la mise à jour proposée en générant la mise à jour proposée.
[0007] Selon un autre aspect du dispositif informatique, le processeur est configuré en réponse à la génération de la mise à jour proposée, pour transmettre la mise à jour proposée aux nœuds clients distants.
[0008] Selon un autre aspect du dispositif informatique, le processeur est configuré pour obtenir la mise à jour proposée en recevant la mise à jour proposée de l’un des nœuds clients distants.
[0009] Selon un autre aspect du dispositif informatique, le processeur est configuré pour générer le vote local en récupérant des données privées distinctes du registre distribué et en évaluant la mise à jour proposée sur la base des données privées.
[0010] Selon un autre aspect du dispositif informatique, le processeur est configuré pour générer le vote local par ailleurs en : identifiant un sous-ensemble des valeurs affectées par la mise à jour proposée ; et sur la base du sous-ensemble en déterminant s’il faut générer le vote local ou un vote blanc local.
[0011] Selon un autre aspect du dispositif informatique, le processeur est par ailleurs configuré pour : stocker une liste d’attente de mises à jour proposées en mémoire ; en réponse à l’obtention de la mise à jour proposée, placer la mise à jour proposée dans la file d’attente pour synchronisation avec les nœuds clients distants ; et pour sortir la mise à jour proposée de la file d’attente et déterminer s’il faut permettre la mise à jour proposée en réponse à la réception des votes distants de tous les clients distants.
[0012] Selon un autre aspect du dispositif informatique, le processeur est par ailleurs configuré pour : lorsqu’un vote distant manquant d’un des clients distants n’est pas reçu dans un délai de temporisation, conserver la mise à jour proposée, le vote local et les votes distants reçus dans la file d’attente pour une synchronisation subséquente avec ledit un des clients distants.
[0013] Selon un autre aspect du dispositif informatique, le processeur est par ailleurs configuré pour : avant de placer la mise à jour proposée dans la file d’attente, déterminer quel vote distant manquant correspond à une pondération de vote distant suffisante pour altérer la détermination qu’il faut, ou non, permettre la mise à jour proposée.
[0014] Selon un autre aspect du dispositif informatique, le processeur est par ailleurs configuré pour : en réponse au placement de la mise à jour proposée dans la file d’attente, mettre en œuvre une détermination initiale pour déterminer s’il faut permettre la mise à jour proposée sur la base (i) du vote local et de la pondération de vote local, et (ii) des votes distants reçus et des pondérations correspondantes de votes distants ; selon la détermination initiale, appliquer la mise à jour proposée au registre distribué ou rejeter la mise à jour proposée et conserver la mise à jour proposée dans la file d’attente ; et en réponse à la réception du vote distant manquant, mettre en œuvre la détermination pour déterminer s’il faut permettre la mise à jour proposée et, lorsque la détermination est en conflit avec la détermination initiale, inverser un résultat de la détermination initiale.
[0015] Selon un autre aspect, un procédé pour tenir à jour un registre distribué au niveau d’un nœud client est fourni, le procédé incluant : le stockage d’un registre distribué définissant une pluralité d’enregistrements, chacun contenant un ensemble de valeurs ; le stockage (i) d’une pondération de vote local correspondant au nœud client et (ii) des pondérations de votes distants respectifs pour une pluralité de nœuds clients distants ; l’obtention d’une mise à jour proposée pour un enregistrement du registre distribué ; la génération d’un vote local pour appliquer ou rejeter la mise à jour proposée et la transmission du vote local aux nœuds clients distants ; la réception de votes distants pour appliquer ou rejeter la mise à jour proposée des nœuds clients distants ; la détermination s’il faut permettre, ou non, la mise à jour proposée sur la base (i) du vote local et de la pondération du vote local et (ii) des votes distants et des pondérations correspondantes de votes distants ; et, selon la détermination, l’application de la mise à jour proposée pour le registre distribué ou le rejet de la mise à jour proposée.
[0016] Selon un autre aspect du procédé, la mise à jour proposée est associée à un type actuel de transaction d’une pluralité de types de transactions ; le procédé comprenant par ailleurs : le stockage d’une pluralité d’autres pondérations de votes locaux, la pondération de vote local et les autres pondérations de votes locaux correspondant chacune à des types respectifs parmi les types de transactions ; et la mise en œuvre de la détermination sur la base d’une des pondérations de votes locaux et des autres pondérations de votes locaux correspondant au type actuel de transaction associé à la mise à jour proposée.
[0017] Selon un autre aspect du procédé, la mise à jour proposée est associée à une valeur actuelle de l’ensemble des valeurs ; le procédé comprenant par ailleurs : le stockage d’une pluralité d’autres pondérations de votes locaux, la pondération de vote local et les autres pondérations de votes locaux correspondant chacune à des valeurs res pectives de l’ensemble des valeurs ; et la mise en œuvre de la détermination sur la base d’une des pondérations de votes locaux et des autres pondérations de votes locaux correspondant à la valeur actuelle associée à la mise à jour proposée.
[0018] Selon un autre aspect du procédé, l’obtention de la mise à jour proposée comprend la génération de la mise à jour proposée au nœud client.
[0019] Selon un autre aspect du procédé, le procédé comprend par ailleurs, en réponse à la génération de la mise à jour proposée, la transmission de la mise à jour proposée aux nœuds clients distants.
[0020] Selon un autre aspect du procédé, l’obtention de la mise à jour proposée comprend la réception de la mise à jour proposée de l’un des nœuds clients distants.
[0021] Selon un autre aspect du procédé, la génération du vote local comprend la récupération de données privées distinctes du registre distribué et l’évaluation de la mise à jour proposée sur la base des données privées.
[0022] Selon un autre aspect du procédé, la génération du vote local comprend par ailleurs : l’identification d’un sous-ensemble des valeurs affectées par la mise à jour proposée ; et sur la base du sous-ensemble, la détermination s’il faut générer le vote local ou un vote blanc local.
[0023] Selon un autre aspect du procédé, le procédé comprend par ailleurs : le stockage d’une liste d’attente de mises à jour proposées ; en réponse à l’obtention de la mise à jour proposée, le placement de la mise à jour proposée dans la file d’attente pour synchronisation avec les nœuds clients distants ; et le retrait de la mise à jour proposée de la file d’attente et la détermination de permettre la mise à jour proposée en réponse à la réception des votes distants de tous les clients distants.
[0024] Selon un autre aspect du procédé, le procédé comprend par ailleurs : lorsqu’un vote distant manquant d’un des clients distants n’est pas reçu dans un délai de temporisation, la conservation de la mise à jour proposée, du vote local et des votes distants reçus dans la file d’attente pour une synchronisation subséquente avec ledit un des clients distants.
[0025] Selon un autre aspect du procédé, le procédé comprend par ailleurs : avant de placer la mise à jour proposée dans la file d’attente, la détermination que le vote distant manquant correspond à une pondération de vote distant suffisante pour altérer la détermination de permettre ou non la mise à jour proposée.
[0026] Selon un autre aspect du procédé, le procédé comprend par ailleurs : en réponse au placement de la mise à jour proposée dans la file d’attente, la mise en œuvre d’une détermination initiale pour déterminer s’il faut permettre la mise à jour proposée sur la base (i) du vote local et la pondération de vote local, et (ii) des votes distants reçus et des pondérations correspondantes des votes distants ; selon la détermination initiale, l’application de la mise à jour proposée au registre distribué ou le rejet de la mise à jour proposée et la conservation de la mise à jour proposée dans la file d’attente ; et en réponse à la réception du vote distant manquant, la mise en œuvre de la détermination pour déterminer s’il faut permettre la mise à jour proposée et, lorsque la détermination est en conflit avec la détermination initiale, l’inversion d’un résultat de la détermination initiale.
[0027] 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 œuvre les étapes du procédé selon l’un quelconque des aspects définis ci-dessus lorsque ledit programme fonctionne sur un ordinateur.
[0028] Les modes de réalisation sont décrits en faisant référence aux figures suivantes, dans lesquelles :
[0029] [fig. 1] décrit un système pour tenir à jour un registre distribué ;
[0030] [fig-2] décrit un procédé pour tenir à jour un registre distribué ;
[0031] [fig.3A] décrit une mise en œuvre du procédé de la Fig. 2 ;
[0032] [fig.3B] décrit une mise en œuvre du procédé de la Fig. 2 ;
[0033] [fig.3C] décrit une mise en œuvre du procédé de la Fig. 2 ;
[0034] [fig.4A] décrit une autre une mise en œuvre du procédé de la Fig. 2 ;
[0035] [fig.4B] décrit une autre mise en œuvre du procédé de la Fig.2 ;
[0036] [fig.4C] décrit une autre mise en œuvre du procédé de la Fig.2 ;
[0037] [fig.5A] décrit une autre mise en œuvre du procédé de la Fig.2 ;
[0038] [fig.5B] décrit une autre mise en œuvre du procédé de la Fig.2 ;
[0039] [fig.5C] décrit une autre mise en œuvre du procédé de la Fig. 2 ; et
[0040] [fig.6] décrit un procédé de récupération suite à une défaillance au niveau d’un des nœuds dans le système de la Fig. 1.
[0041] Fig. 1 décrit un système 100 pour tenir à jour un registre distribué (également appelé technologie de registre distribué, ou DLT). Le système 100 inclut un réseau 104 implémenté sous forme d’une quelconque combinaison appropriée de réseaux locaux et de zone étendue (p. ex. incluant l’Internet), reliant une pluralité de serveurs 108 (également appelés nœuds 108 dans les présentes) lesquels sont illustrés par trois exemples 108-1, 108-2 et 108-3. Les serveursl08 n’ont pas besoin d’être implémentés comme des serveurs individuels 108, mais plutôt sont représentés comme des serveurs individuels 108 dans le but de clarifier l’illustration. Par exemple, chaque serveur 108 peut être implémenté sous forme de sous-système incluant un ou plusieurs autres réseaux, une pluralité de serveurs et d’autres dispositifs informatiques (non illustrés).
[0042] Chaque nœud 108 est typiquement, mais pas nécessairement, exploité par une entité distincte. Dans les exemples discutés ci-dessous, le système 100 est configuré pour tenir à jour un registre distribué contenant des données de voyage (p. ex. des réservations de vol, des enregistrements de passagers, un suivi des plaintes des clients, entre autres). Cependant, il sera apparent pour les hommes de métier que les principes d’exploitation implémentés par le système 100 puissent être appliqués à une large variété d’autres types de données gérés par toute combinaison pertinente d’entités. Dans le présent exemple, le nœud 108-1 est exploité par une compagnie aérienne alors que le nœud 108-2 est exploité par une entité génératrice de profils de clients et que le nœud 108-3 est exploité par une entité de gestion des plaintes.
[0043] Ainsi que noté ci-dessus, les nœuds 108 sont configurés pour tenir à jour un registre distribué contenant des données de voyage. Par conséquent, chaque nœud 108 conserve une copie locale 112-1, 112-2, 112-3 du registre distribué (collectivement appelé simplement le registre 112). Chaque nœud 108 peut initier des mises à jour du registre 112 et les nœuds 108 sont configurés pour implémenter un mécanisme de consensus basé sur le vote pour déterminer s’il faut appliquer ou rejeter (c.-à-d. supprimer) chaque mise à jour proposée au registre 112. Cependant comme cela fera l’objet d’une discussion ci-dessous, par contraste aux mécanismes conventionnels de consensus basés sur le vote, une pondération de vote distincte peut être affectée à chaque nœud 108, donnant plus ou moins d’influence au nœud 108 que les autres nœuds 108 concernant l’acceptation des mises à jour du registre 112.
[0044] Chaque nœud 108 peut aussi stocker des données qui sont conservées en dehors du registre 112 et résident donc seulement sur un nœud 108. Par exemple, le nœud 108-1 (p. ex. exploité par une compagnie aérienne dans le présent exemple) peut contenir des listes des membres d’équipage en opération pour chacun d’une pluralité de vols alors qu’aucun des nœuds 108-2 et 108-3 ne contient de telles informations concernant équipage. Divers autres types de données peuvent être conservés à l’intérieur ou à l’extérieur du registre 112, incluant par exemple, le statut d’embarquement des passagers enregistrés pour un vol donné. Les données conservées en dehors du registre 112 (c.-à-d. les données qui sont accédées uniquement par un seul nœud 108) sont aussi désignées comme données privées dans les présentes. Dans certains modes de réalisation, les données privées peuvent en fait être conservées à l’intérieur du registre 112 avec un accès restreint à un sous-ensemble des nœuds 108 via l’encryption de portions du registre 112. Dans le présent exemple, les données privées sont illustrées comme étant conservées séparément du registre 112. Par conséquent, le nœud 108-1 maintient un dépôt privé 116, le nœud 108-2 maintient un dépôt privé 120 et le nœud 108-3 maintient un dépôt privé 124. La pondération de vote affectée à un nœud donné 108 peut dépendre du contenu des données privées conservées par ce nœud 108.
[0045] Avant de détailler la fonctionnalité implémentée par les nœuds 108 du système 100 pour tenir à jour le registre 112, certains composants internes des nœuds 108-1 seront expliqués en supposant que les nœuds 108-2 et 108-3 incluent des composants équivalents (bien qu’ils ne soient pas nécessairement identiques).
[0046] Le nœud 108-1 inclut au moins un processeur 128, tel qu’une unité de traitement central (CPU) ou autre. Le processeur 128 est relié à une mémoire 132 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 ainsi de suite). Le processeur 128 et la mémoire 132 sont généralement compris d’un ou de plusieurs circuits intégrés (ICs).
[0047] Le processeur 128 est aussi relié à une interface de communication 136 qui permet au nœud 108-1 de communiquer avec les autres dispositifs informatiques du système 100 (incluant les nœuds 108-2 et 108-3) via le réseau 104. L’interface de communications 136 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) pour communiquer via le réseau 104. Les composants spécifiques de l’interface de communications 136 sont sélectionnés en fonction de la nature du réseau 104. Le nœud 108-1 peut aussi inclure des dispositifs d’entrée et de sortie connectés au processeur 128, tels que des claviers, des souris, des écrans, et autres (non illustrés).
[0048] Les composants du nœud 108-1 mentionnés ci-dessus peuvent être déployés dans une seule enceinte ou sous un format distribué. Par conséquent dans certains exemples, le nœud 108-1 inclut une pluralité de processeurs qui peuvent partager la mémoire 132 et l’interface de communications 136, ou qui ont chacun des interfaces de communications et des mémoires associées distinctes.
[0049] La mémoire 132 stocke la copie locale 112-1 du registre 112 mentionné ci-dessus ainsi que le dépôt de données privées 116. La mémoire 132 stocke aussi une pluralité d’instructions de programmation lisibles par ordinateur, exécutables par le processeur 128 sous forme d’applications variées incluant l’application cliente de registre distribué 140-1 et l’application génératrice de votes 144. Les hommes de métier comprendront que le processeur 128 exécute les instructions des applications 140-1 et 144 (et toutes autres applications pertinentes) afin de mettre en œuvre des actions diverses définies par les instructions contenues dans les présentes. Dans la description ci-dessous, le processeur 128 et, de façon plus générale, le nœud 108-1 sont censés être configurés pour mettre en œuvre ces actions. On comprendra qu’ils sont configurés ainsi via l’exécution (par le processeur 128) des instructions des applications stockées dans la mémoire 132. Les nœuds 108-2 et 108-3 stockent des applications clientes de registre distribué 140-2 et 140-3 ainsi que des applications génératrices de votes 148 et 152, respectivement.
[0050] L’exécution des applications clientes 140, comme cela sera expliqué ci-dessous, configure chaque nœud 108 respectif pour échanger des mises à jour proposées au registre 112 avec les autres nœuds, coordonne aussi l’échange des votes avec les autres nœuds et gère l’application des changements au registre 112 (p. ex. lorsque les votes échangés entre les nœuds 108 indiquent qu’une mise à jour proposée doit être appliquée au registre 112). Les votes eux-mêmes sont générés à chaque nœud 108 via l’exécution de l’application génératrice de votes correspondante. Par conséquent le nœud 108-2, par exemple, exécute l’application génératrice de votes 148 pour générer des votes (pour l’acceptation ou le rejet d’une mise à jour). Ainsi qu’indiqué par les numéros de référence appliqués aux applications génératrices de votes 144, 148 et 152, par comparaison aux applications clientes 140, la fonctionnalité des applications clientes 140 est en substance identique à chaque nœud alors que la fonctionnalité implémentée par l’application génératrice de votes 144 n’a pas besoin d’être identique à celle des applications 148 et 152. En d’autres termes, les nœuds 108 implémentent chacun un processus commun (dicté par les applications 140) pour échanger les mises à jour proposées et les votes pour ces mises à jour, mais implémentent chacun des algorithmes distincts pour déterminer les votes actuels. La génération de vote au niveau de chaque nœud 108 peut donc reposer au moins en partie sur les données privées du nœud 108 et peut être mise en œuvre selon des algorithmes qui ne sont pas connus des autres nœuds 108.
[0051] Eaisant maintenant référence à la LIG. 2, certains aspects d’exploitation du système 100 seront décrits de façon plus détaillée. Spécifiquement, la LIG. 2 illustre un procédé 200 pour tenir à jour le registre 112. Le procédé 200 sera décrit conjointement avec sa mise en œuvre dans le système 100 et spécifiquement par chacun des nœuds 108 via l’exécution des applications clientes de DLT 140 et les applications génératrices de votes 144, 148 et 152. C’est-à-dire que le procédé 200 est mis en œuvre parallèlement par chaque nœud 108 dans le système 100.
[0052] Au bloc 205, le nœud 108 est configuré pour stocker des identifiants de nœuds et des pondérations de vote pour chaque nœud 108 dans le système 100. Ainsi, le nœud 108-1 stocke les identifiants du nœud et les pondérations de vote à la fois pour lui-même (désignée comme pondération de vote local) et pour les nœuds 108-2 et 108-3 (désignées comme pondérations de votes distants). Les identifiants de nœuds peuvent inclure des adresses de réseau (p. ex. toute combinaison pertinente d’adresses IP, de nombre de ports, d’identifiants de domaine et d’autres), ou tout autre identifiant pertinent pour établir des communications avec les nœuds 108 sur le réseau 104. Les pondérations de vote, comme cela sera expliqué ci-dessous, définissent le degré d’influence que chaque nœud 108 a sur les décisions d’appliquer ou de rejeter des mises à jour proposées au registre 112. Le tableau 1 illustre un exemple d’ensemble d’identifiants de nœuds et de pondérations de votes correspondantes.
[0053] Identifiants de nœuds et pondérations de votes exemplaires :
[0054] [Tableaux 1]
ID nœud Pondération de vote
108-1 40%
108-2 45 %
108-3 15 %
[0055] Comme on le voit maintenant, chaque nœud 108 stocke les données ci-dessus. Les identifiants de nœuds et les pondérations de vote, tels qu’ils sont stockés à chaque nœud 108 peuvent contenir des indications concernant quel enregistrement représente des données locales et quels nœuds représentent des données distantes. Les pondérations de vote sont exprimées ci-dessus sous forme de pourcentage, mais peuvent être exprimées sous divers autres formats dans d’autres exemples.
[0056] Les pondérations de votes et les identifiants de nœuds sont échangés par les nœuds 108 au cours du déploiement du système 100. Les pondérations de votes sont prédéfinies et sont généralement statiques (bien que dans certains cas il peut-être souhaitable de reconfigurer le système 100, par exemple pour déployer un nœud additionnel 108 nécessitant une mise à jour des pondérations de votes). Les pondérations de vote peuvent être sélectionnées selon un quelconque critère parmi une large variété de critères. Par exemple, une pondération de vote plus importante peut être affectée à un nœud 108 en fonction de l’ampleur des données privées stockées par ce nœud. Dans d’autres modes de réalisation, plusieurs pondérations de vote peuvent être affectées à chaque nœud. Chaque pondération de vote pour un nœud donné peut correspondre à un type de mises à jour de la DLT 112. Par exemple, pour des insertions de nouvelles données dans la DLT 112, un nœud donné peut avoir une première pondération alors que pour éditer des données existantes dans la DLT 112, le même nœud peut avoir une seconde pondération différente de la première pondération. Dans d’autres exemples, les pondérations distinctes affectées à un nœud donné peuvent correspondre à des champs particuliers, des valeurs, ou d’autres éléments de ce genre dans la DLT 112. Par exemple, un nœud exploité par une compagnie aérienne peut avoir une première pondération pour un usage lié à des mises à jour quelconques d’horaires de vol définies dans la DLT 112 et une deuxième pondération (p. ex. une pondération moins importante) pour un usage lié à des mises à jour quelconques des informations de contact pour un passager.
[0057] Au bloc 210, le nœud 108 est configuré pour déterminer si une défaillance locale est survenue pouvant nécessiter un processus de rétablissement pour obtenir des mises à jour au registre 112 qui n’ont pas été reçues. Une défaillance locale, telle qu’elle est désignée dans les présentes, est une quelconque condition ou ensemble de conditions empêchant un nœud 108 d’échanger des données avec les autres nœuds 108. Ainsi, une perte de connectivité, un temps d’arrêt planifié ou non planifié (p. ex. pour la maintenance), entre autres, sont tous des exemples d’une défaillance locale. En bref, suite à une défaillance locale le nœud 108 est configuré pour récupérer des mises à jour effectuées parmi les autres nœuds 108 au cours de la défaillance locale et pour évaluer les mises à jour selon un procédé qui sera expliqué ci-dessous en se référant à la FIG. 6.
[0058] Lorsque la détermination au bloc 210 est négative, la mise en œuvre du procédé 200 avance au bloc 215. Au bloc 215, le nœud 108 est configuré pour obtenir une mise à jour proposée au registre et pour stocker la mise à jour proposée dans une file d’attente (p. ex. dans la mémoire 132) dans l’attente d’un traitement supplémentaire. L’obtention d’une mise à jour proposée inclut soit de recevoir la mise à jour proposée d’un autre nœud 108 via un quelconque mécanisme pertinent de synchronisation de DLT (implémenté par l’application cliente 140), soit de générer la mise à jour localement (auquel cas la mise à jour proposée est aussi transmise aux autres nœuds 108 pour réception lors des mises en œuvre parallèles du bloc 215 dans ces nœuds 108).
[0059] Au bloc 215, le nœud 108 est aussi configuré pour générer un vote local correspondant à la mise à jour proposée. La génération d’un vote local par chaque nœud 108, ainsi que noté précédemment peut être mise en œuvre selon un quelconque critère pertinent qui n’a pas besoin d’être partagé entre les nœuds 108.
[0060] Au bloc 220, le nœud 108 est configuré pour transmettre le vote local généré au bloc 215 aux autres nœuds 108 et pour recevoir des votes (désignés comme votes distants) relatifs à la mise à jour proposée obtenue au bloc 215, des autres nœuds 108. C’est-à-dire que les autres nœuds 108 ayant aussi obtenu la mise à jour proposée via les mises en œuvre respectives du bloc 215 sont aussi configurés pour générer des votes locaux et transmettre les votes locaux via les mises en œuvre respectives du bloc 220. Les FIGS. 3A et 3B illustrent des mises en œuvre exemplaires des blocs 215 et 220. Spécifiquement, la FIG. 3A illustre une mise à jour proposée 300 provenant du nœud 108-3, telle qu’une mise à jour proposée pour enregistrer une plainte relative au service d’un vol lié à un enregistrement donné de passager (p. ex., défini par un nom de passager ou un autre identifiant approprié). La mise à jour proposée 300 est propagée aux nœuds 108-1 et 108-2 comme indiqué par les lignes en pointillés.
[0061] La FIG. 3B illustre la génération et l’échange de votes au bloc 220. Spécifiquement, chaque nœud 108 génère un vote respectif 304-1, 304-2, et 304-3 et transmet le vote 304 aux deux autres nœuds 108. Par exemple, le vote 304-3 est censé être affirmatif (parce que le nœud 108-3 a initié la mise à jour proposée. Cependant, les votes 304-1 et 304-2 sont négatifs dans le présent exemple. Par exemple, le nœud 108-1 peut être configuré pour déterminer si le nom de passager associé à la mise à jour proposée est associé à la réservation d’un vol. Lorsque la détermination est négative, le nœud 108-1 peut être configuré pour voter contre l’application de la mise à jour (p. ex. parce qu’une plainte relative au service de vol n’est vraisemblablement pas valide lorsque le passager correspondant n’a réservé aucun vol). Cependant, le vote 304-2 généré par le nœud 108-2 est également négatif dans le présent exemple. Par exemple, le nœud 108-2 peut être configuré pour déterminer si le nom de passager associé à la mise à jour proposée est enregistré sur un vol quelconque. Etant donné que le passager n’a réservé aucun vol, la détermination est négative.
[0062] Faisant référence à nouveau à la FIG. 2 au bloc 225, suite à un laps de temps prédéfini, chaque nœud 108 est configuré sur la base du vote local généré au bloc 215 et des votes distants reçus au bloc 220 afin de déterminer s’il faut permettre la mise à jour proposée. La détermination au bloc 225 comprend de faire la synthèse des votes en faveur de l’application de la mise à jour et des votes contre l’application de la mise à jour, pondérés selon les pondérations de votes décrites en lien avec le bloc 205 et de déterminer si la majorité du vote pondéré est d’appliquer ou de rejeter la mise à jour proposée. Le tableau 2 ci-dessous illustre un résultat exemplaire de la mise à jour mentionnée ci-dessus en lien avec les FIGS. 3A et 3B.
[0063] Votes et résultats exemplaires
[0064] [Tableaux2]
ID nœud Pondération de vote Vote Résultat
108-1 40% Rejeter 85/100 Rejet
108-2 45 % Rejeter
108-3 15 % Approuver
[0065] Comme on le constate ci-dessus, la majorité du vote pondéré est de rejeter la mise à jour proposée. Bien que les trois nœuds 108 aient généré des votes pour rejeter ou approuver la mise à jour proposée dans l’exemple ci-dessus, dans d’autres exemples un troisième type de vote peut être généré par un ou plusieurs nœuds 108. En particulier, l’algorithme de génération de vote appliqué à un nœud 108 peut spécifier que le nœud 108 manque d’informations suffisantes pour générer un vote pour appliquer ou rejeter des mises à jour de certains enregistrements ou de champs du registre. Par exemple, le nœud 108-3 peut manquer d’informations suffisantes permettant de voter l’application ou le rejet de mises à jour des prix des vols dans le registre 112. L’application 152 peut donc spécifier que pour les mises à jour du champ, relatif au prix, d’un enregistrement définissant un vol, le nœud 108-3 générera un vote d’abstention (également appelé vote blanc). Le vote pondéré dans de telles conditions omet la pondération du nœud 108-3 et est donc évalué à un poids total de 85 plutôt que 100.
[0066] Au bloc 230, chaque nœud 108 est configuré pour déterminer si des votes sont manquants. C’est-à-dire que chaque nœud 108 est configuré pour déterminer si les votes distants reçus au bloc 220 représentent un ensemble complet de votes. Lorsque l’enregistrement des votes assemblé à partir des blocs 215 et 220 est incomplet, indiquant qu’un ou plusieurs votes n’ont pas été reçus pendant le laps de temps mentionné ci-dessus (p. ex. un ou plusieurs nœuds 108 ont subi une défaillance), la mise en œuvre du procédé 200 avance au bloc 240 détaillé ci-dessous. Cependant dans le présent exemple, des votes ont été reçus de chaque nœud 108 et la détermination au bloc 230 est par conséquent négative (c.-à-d. qu’aucun vote n’est manquant quand la détermination est faite au bloc 225). Le nœud 108 avance donc au bloc 235 où la mise à jour proposée est appliquée au registre 112, ou rejetée selon le résultat du bloc 225. Dans le présent exemple, en se référant à la FIG. 3B, le résultat du bloc 225 est que la mise à jour proposée est rejetée. Par conséquent, la mise à jour proposée 300 est sortie de la liste d’attente à chaque nœud 108 et les copies locales 112 du registre restent inchangées. Dans d’autres exemples, les copies locales 112 du registre 112 sont mises à jour pour stocker la mise à jour proposée avec une indication que la mise à jour proposée a été rejetée. Par conséquent, le registre 112 conserve un historique de toutes les mises à jour proposées y compris celles qui ont été rejetées. Chaque nœud revient ensuite au bloc 210.
[0067] Comme noté ci-dessus, lorsque la détermination au bloc 230 est affirmative, indiquant que des votes n’ont pas été reçus de tous les nœuds 108 au cours du laps de temps mentionné en lien avec le bloc 225, chaque nœud 108 avance au bloc 240. Comme on le verra maintenant, bien que le procédé 200 soit décrit ci-dessus comme étant mis en œuvre parallèlement par chaque nœud 108, une détermination affirmative au bloc 230 indique typiquement qu’un ou plusieurs nœuds 108 ont subi une défaillance et ces nœuds 108 ne peuvent donc pas mettre en œuvre le procédé 200 (p. ex. parce qu’ils n’ont pas reçu la mise à jour au bloc 215).
[0068] Au bloc 240, chacun des nœuds restants 108 (c.-à-d. ceux qui n’ont pas été affectés par une défaillance) est configuré pour déterminer, sur la base des votes reçus aux blocs 215 et 220, si le résultat déterminé au bloc 225 est incertain. Un résultat incertain est un résultat qui pourrait être inversé par un vote manquant, si le vote manquant était présent. Par exemple, le tableau 3 liste un ensemble de votes dans lequel aucun vote n’a été reçu en provenance du nœud 108-3. Cependant, puisque les nœuds 108-1 et 108-2 qui ensemble représentent 85 % du vote total pondéré ont tous deux généré des votes locaux favorables à l’application de la mise à jour proposée, la détermination par les nœuds 108-1 et 108-2 au bloc 225 (d’appliquer la mise à jour) n’est pas incertaine parce qu’aucun vote du nœud 108-3 ne pourrait altérer la détermination du bloc 225.
[0069] Votes et résultats exemplaires
[0070] [Tableaux3]
ID nœud Pondération de vote Vote Résultat
108-1 40% Approuver Approuver 85/85
108-2 45 % Approuver
108-3 15 % N/A
[0071] La détermination au bloc 240 est donc négative dans le présent exemple et les nœuds 108-1 et 108-2 avancent chacun au bloc 235 comme indiqué ci-dessus. Les FIGS. 4A-4C illustrent le processus ci-dessus. En particulier, la FIG. 4A décrit une mise à jour proposée 400 générée par le nœud 108-1. Cependant, le nœud 108-3 n’est pas connecté au réseau 104 et par conséquent ne reçoit pas la mise à jour proposée 400. Par conséquent, comme le montre la FIG. 4B, les nœuds 108-1 et 108-2 échangent des votes 404-1 et 404-2, mais aucun vote n’est reçu du nœud 108-3. Finalement, comme le montre la FIG. 4C, les copies locales 112-1 et 112-2 du registre 112 sont mises à jour (apparaissant sous 112-1* et 112-2*) et la mise à jour proposée 400 est sortie de la liste d’attente aux nœuds 108-1 et 108-2, mais la copie locale 112-3 du nœud 108-3 reste inchangée.
[0072] Un autre exemple est illustré dans FIGS. 5A-5C. En particulier, comme le montre la FIG. 5A, une mise à jour proposée 500 provenant du nœud 108-1 ne parvient pas au nœud 108-3. Les nœuds 108-1 et 108-2 stockent donc la mise à jour proposée 500 dans leurs files d’attente respectives et échangent les votes 504-1 et 504-2, mais aucun vote n’est reçu du nœud 108-3. Le tableau 4 montre des votes et des pondérations de votes exemplaires correspondant aux FIGS. 5A-5B. En particulier, la pondération de vote correspondant au nœud 108-3 est 45 %, alors que le poids affecté au nœud 108-2 n’est que 15 %. Par conséquent, à la suite d’une détermination affirmative au bloc 230, la détermination au bloc 240 pour chacun des nœuds 108-1 et 108-2 est affirmative. C’est-à-dire que le résultat montré ci-dessous (rejetant la mise à jour proposée 500 parce que la majorité du vote pondéré disponible est de rejeter la mise à jour) est incertain, car le poids correspondant au nœud 108-3 est suffisant pour altérer la détermination au bloc 225 si un vote du nœud 108-3 était disponible.
[0073] Votes et résultats exemplaires
[0074]
[Tableaux4]
ID nœud Pondération de vote Vote Résultat
108-1 40% Rejeter Rejeter 40/55
108-2 15 % Approuver
108-3 45 % N/A
[0075] Les nœuds 108-1 et 108-2 avancent donc au bloc 245. Au bloc 245, les nœuds 108-1 et 108-2 sont néanmoins configurés pour appliquer ou rejeter la mise à jour proposée 500 selon la détermination au bloc 225 (c.-à-d. que dans le présent exemple, la mise à jour proposée 500 est rejetée). Comme le montre la LIG. 5C, les copies locales 112-1 et 112-2 restent inchangées. Cependant, la mise à jour proposée 500 est maintenue dans la file d’attente ainsi que les votes reçus au bloc 215 et 220. Les nœuds 108-1 et 108-2 peuvent ensuite être configurés pour continuer à traiter d’autres mises à jour en retournant au bloc 210. Cependant, les nœuds 108-1 et 108-2 aussi, parallèlement à ces autres mises à jour proposées, avancent au bloc 250 dans l’attente d’une résolution du résultat incertain identifié au bloc 240. La nature de la résolution est dépendante du vote généré par le nœud 108-3 lui-même et sera détaillée ci-dessous.
[0076] Lorsque la détermination au bloc 210 est affirmative, indiquant qu’un nœud 108 a eu une défaillance récente (p. ex. le nœud 108 peut faire une détermination affirmative au bloc 210 en réponse au rétablissement de la connectivité avec le réseau 104), le nœud 108 procède à la mise en œuvre du procédé 600 montré dans la LIG. 6. En bref, la mise en œuvre du procédé 600 permet au nœud 108 ayant subi une défaillance de récupérer toutes les mises à jour du registre 112 qui ont eu lieu pendant la défaillance et de déterminer s’il faut modifier une quelconque des mises à jour susmentionnées via un vote rétroactif. C’est-à-dire que le procédé 600 permet au nœud 108 doté d’une pondération de vote suffisante pour altérer une mise à jour antérieure (c.-à-d. avec une pondération de vote suffisante pour rendre une mise à jour antérieure incertaine) de réévaluer la mise à jour et, si nécessaire, d’inverser la détermination faite au bloc 225 par les autres nœuds 108 en l’absence du vote du présent nœud.
[0077] En continuant avec l’exemple ci-dessus dans lequel le nœud 108-3 a été déconnecté du réseau 104, au bloc 605, il est supposé que le nœud 108-3 a rétabli la connectivité avec le réseau 104. Le nœud 108-3 est configuré au bloc 605 pour recevoir et appliquer des mises à jour faites au dépôt 112 au cours de la défaillance. Par exemple, le nœud 108-3 peut transmettre une requête aux nœuds 108-1 et 108-2 contenant un horodatage de la transaction la plus récente dans la copie locale 112-3 du registre ou toutes autres données pertinentes pour indiquer la durée pendant laquelle le nœud 108-3 était hors ligne. En réponse à cette reconnexion, le nœud 108-3 est configuré pour obtenir une copie actualisée du registre 112 pour stockage comme copie locale 112-3. La copie locale 112-3 est donc mise à jour pour inclure des enregistrements de toutes les mises à jour qui ont été proposées (qu’elles aient été acceptées ou rejetées) pendant le laps de temps où le nœud 108-3 était déconnecté. Par conséquent dans le présent exemple, bien qu’aucune mise à jour n’ait été appliquée (comme indiqué ci-dessus en lien avec la FIG. 5C), la copie actuelle du registre 112 indique que la mise à jour proposée 500 a été évaluée et rejetée pendant que le nœud 108-3 était déconnecté. La mise à jour proposée 500 est donc également retenue dans les files d’attente à chacun des nœuds 108-1 et 108-2.
[0078] Au bloc 610, le nœud 108-3 est configuré pour déterminer si la copie actuelle du registre 112 (c.-à-d. telle qu’elle est reflétée dans la copie locale 112-3) contient une quelconque des mises à jour traitées sous la forme de mises à jour proposées appliquées ou rejetées ayant fait l’objet d’un vote pendant le laps de temps où le nœud 108-3 était déconnecté. La détermination au bloc 610 peut inclure une détermination des résultats incertains d’une quelconque de ces mises à jour. Lorsque la détermination au bloc 610 est négative, indiquant, soit qu’aucune mise à jour non traitée n’est présente (c.-à-d. qu’il n’y avait pas d’activité dans le registre 112 pendant le laps de temps où le nœud 108-3 était déconnecté), soit que les mises à jour qui sont survenues pendant la défaillance n’étaient pas incertaines (c.-à-d. qu’elles ne pouvaient pas être changées par le vote du nœud qui a subi la défaillance), la mise en œuvre du processus 600 est achevée et le nœud 108-3 retourne au bloc 210. Cependant, lorsque la détermination au bloc 610 est affirmative, comme dans l’exemple du nœud 108-3 mentionné ci-dessus, la mise en œuvre du procédé 600 se poursuit au bloc 615.
[0079] Au bloc 615, le nœud 108-3 est configuré pour ajouter chaque mise à jour non traitée dans le registre 112, dans une file d’attente locale et pour générer un vote local pour chaque mise à jour proposée représentée dans la file d’attente. La file d’attente peut être traitée, par exemple, par ordre chronologique en commençant avec la plus ancienne mise à jour non traitée. C’est-à-dire que lorsque la file d’attente contient plus d’une seule mise à jour proposée (qui selon la discussion précédente est une évidence, ont en fait déjà été appliquées au registre 112 ou rejetées aux nœuds 108-1 et 108-2), le nœud 108-3 est configuré pour générer des votes locaux pour chaque mise à jour proposée dans la file d’attente. La mise en œuvre de la portion restante du procédé 600 est donc répétée pour chaque mise à jour non traitée dans la file d’attente.
[0080] En réponse à la génération d’un vote local pour une mise à jour non traitée, le nœud 108 ayant subi une défaillance est configuré au bloc 620 pour déterminer si le vote local généré au bloc 615 est hé à une mise à jour non traitée dont dépendent d’autres mises à jour non traitées. A titre d’exemple de conflit de dépendance entre les mises à jour non traitée (c.-à-d. celles qui sont dans la file d’attente du nœud 108-3), durant le laps de temps où le nœud du 108-3 était déconnecté, une première mise à jour peut être appliquée au registre 112 pour insérer une réservation de vol pour un passager donné et une deuxième mise à jour peut par la suite être appliquée au registre pour stocker un indicateur d’enregistrement de bagages pour la réservation de vol (p. ex. indiquant que le passager a payé pour un bagage enregistré). Le nœud 108-3 peut être configuré pour déterminer, suite à une génération au bloc 615 d’un vote local pour rejeter la réservation de vol, que l’indicateur de bagage enregistré est dépendant de la réservation de vol. En d’autres termes, en transmettant simplement un vote local pour rejeter la réservation de vol, il pourrait en résulter une incohérence dans le registre 112 qui indiquerait un paiement de bagage enregistré pour une réservation de vol non existante. Dans un tel scénario, la détermination au bloc 620 est affirmative.
[0081] Suite à une détermination affirmative au bloc 620, au bloc 625 le nœud 108-3 est configuré pour générer une mise à jour proposée ou une autre action pertinente pour résoudre le conflit détecté au bloc 620. Par exemple, le nœud 108-3 peut être configuré pour récupérer la mise à jour non traitée qui est en conflit avec la mise à jour non traitée actuelle et pour générer un vote au bloc 615 pour cette mise à jour. En continuant avec l’exemple ci-dessus, le nœud 108-3 peut donc être configuré pour générer un vote local pour l’enregistrement de bagages enregistrés avant d’envoyer le vote local pour la réservation de vol, traitant de ce fait les mises à jour conflictuelles par ordre chronologique inversé. Dans d’autres exemples, le nœud 108-3 peut être configuré pour générer une autre mise à jour proposée pour circulation entre les nœuds 108 et un traitement via le procédé 200 comme expliqué ci-dessus. Certains conflits détectés au bloc 620 peuvent nécessiter l’intervention d’un opérateur pour une résolution et la mise en œuvre du bloc 625 peut donc inclure la réception de données entrées définissant une mise à jour proposée.
[0082] En réponse à la génération d’une mise à jour proposée au bloc 625 d’une détermination négative au bloc 620, au bloc 630 le nœud 108-3 est configuré pour envoyer le vote local généré au bloc 615 (et, le cas échéant, toutes les mises à jour proposées ou autres actions générées au bloc 625) aux autres nœuds 108-1 et 108-3, pour traitement au bloc 250.
[0083] Au bloc 250, chaque nœud 108 est configuré pour déterminer si le vote manquant précédemment (c.-à-d. le vote local généré au bloc 615 par le nœud 108-3) modifie le résultat actuellement reflété dans le registre 112 (c.-à-d. le résultat produit via la mise en œuvre antérieure du bloc 225). Lorsque la détermination au bloc 250 est négative, chaque nœud 108 poursuit au bloc 255 et retire la mise à jour proposée de la file d’attente respective. Ainsi, si le nœud 108-3 génère un vote pour rejeter la mise à jour proposée 500 au bloc 615, la détermination au bloc 250 (telle qu’elle est mise en œuvre par chacun des nœuds 108-1, 108-2, 108-3 maintenant que l’enregistrement du vote complet est disponible) est négative, et chaque nœud du 108 met en œuvre le bloc 250, en retirant la mise à jour proposée 500 de leurs files d’attente respectives. Les nœuds 108 reviennent ensuite au bloc 210.
[0084] D’autre part, quand la détermination au bloc 250 est affirmative, la mise en œuvre du procédé 200 à chaque nœud 108 avance au bloc 260. Par exemple, si le nœud 108-3 génère un vote en faveur de l’application de la mise à jour proposée 500 au bloc 615 (qui est par la suite envoyée aux nœuds 108-1 et 108-2 au bloc 630), l’enregistrement complet du vote correspondant à la mise à jour proposée 500 est montré dans le tableau 5 ci-dessous.
[0085] Votes et résultats exemplaires
[0086] [Tableaux5]
ID nœud Pondération de vote Vote Résultat
108-1 40% Rejeter Approuver 60/100
108-2 15 % Approuver
108-3 45 % Approuver
[0087] Comme on le voit ci-dessus, avec l’addition du vote généré au bloc 615 par le nœud 108-3, le résultat est altéré passant d’une décision de rejeter la mise à jour proposée 500 à une décision d’approuver (c.-à-d. d’appliquer) la mise à jour proposée 500. La détermination au bloc 250 étant affirmative, chaque nœud 108 met donc en œuvre le bloc 260 auquel la mise à jour proposée est réappliquée (si elle avait été rejetée au bloc 225) ou inversée (si elle avait été appliquée au bloc 225).
[0088] En d’autres termes, au bloc 260 chaque nœud 108 est configuré pour inverser le résultat de la détermination au bloc 225 comme le reflète actuellement le registre 112. Ainsi dans cet exemple, dans lequel la mise à jour proposée 500 a été rejetée (c.-à-d. qu’elle n’a pas été appliquée au registre), au bloc 260 chacun des nœuds 108-1, 108-2 et 108-3 est configuré pour appliquer la mise à jour proposée 500 au registre 112. Autrement, lorsque la mise à jour proposée a été précédemment appliquée, chaque nœud 108 est configuré pour appliquer l’inversion de la mise à jour (p. ex. lorsqu’une affectation de siège a été appliquée au registre 112, chaque nœud 108 est configuré pour supprimer l’affectation du siège). Les nœuds 108 peuvent être configurés pour mettre en œuvre la réapplication de façon indépendante. Dans d’autres exemples, le nœud 108-3 peut être configuré pour transmettre une instruction de réévaluation ou de réapplication aux nœuds 108-2 et 108-3 avec le vote local envoyé au bloc 630. L’instruction de réévaluation contient la mise à jour proposée 500 ainsi que l’enregistrement de vote complet montré ci-dessus dans le tableau 5. Dans chaque im plémentation, les nœuds 108-1 et 108-2 ne génèrent pas de votes additionnels en lien avec la réévaluation ou la mise à jour proposée 500. Au lieu de cela, les votes générés précédemment aux blocs 215 et 220 sont utilisés. Faisant référence à la FIG. 2 au bloc 260, les nœuds 108-1 108-2 et 108-3 sont donc configurés pour appliquer la mise à jour proposée 500 au registre 112. Ees nœuds 108-1, 108-2 et 108-3 sont donc configurés pour éliminer la mise à jour proposée 500 de leurs files d’attente respectives au bloc 255 et reviennent au bloc 210.
[0089] Ees hommes de métier apprécieront que dans certains modes de réalisation, la fonctionnalité des applications 140, 144, 148 et 152 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.
[0090] La portée ne pourrait être limitée aux modes de réalisation exposés dans les exemples ci-dessus, mais doit recevoir l’interprétation la plus large conformément à la description dans sa globalité.

Claims (1)

  1. Revendications [Revendication 1] Un dispositif informatique pour implémenter un nœud client d’un registre distribué, le dispositif informatique comprenant : une mémoire stockant (i) un registre distribué définissant une pluralité d’enregistrements chacun contenant un ensemble de valeurs ; (ii) une pondération de vote local correspondant au nœud client, et (iii) des pondérations respectives de votes distants pour une pluralité de nœuds clients distants ; un processeur connecté à la mémoire, le processeur étant configuré pour : obtenir une mise à jour proposée pour un enregistrement du registre distribué ; générer un vote local pour appliquer ou rejeter la mise à jour proposée et transmettre le vote local aux nœuds clients distants ; recevoir des votes distants pour appliquer ou rejeter la mise à jour proposée des nœuds clients distants ; déterminer s’il faut permettre la mise à jour proposée sur la base (i) du vote local et de la pondération du vote local et (ii) des votes distants et des pondérations correspondantes des votes distants ; et selon la détermination, appliquer la mise à jour proposée au registre distribué ou rejeter la mise à jour proposée. [Revendication 2] Le dispositif informatique selon la revendication 2, dans lequel la mise à jour proposée est associée à un type actuel d’une pluralité de types de transaction ; le processeur est par ailleurs configuré pour : stocker une pluralité de pondérations de votes locaux en mémoire, la pondération de vote local et les autres pondérations de votes locaux correspondant chacun respectivement à un des types de transactions ; et mettre en œuvre la détermination sur la base d’une des pondérations de votes locaux correspondant au type actuel de transaction associé à la mise à jour proposée. [Revendication 3] Le dispositif informatique selon la revendication 1 ou la revendication 2, dans lequel la mise à jour proposée est associée à une valeur actuelle de l’ensemble des valeurs ; le processeur est par ailleurs configuré pour : stocker une pluralité de pondérations de votes locaux en mémoire, la pondération de vote local et les autres pondérations de votes locaux correspondant chacune à des valeurs respectives de l’ensemble des valeurs ;
    et mettre en œuvre la détermination sur la base d’une des pondérations de votes locaux et des autres pondérations de votes locaux correspondant à la valeur actuelle associée à la mise à jour proposée. [Revendication 4] Le dispositif informatique selon l’une quelconque des revendications 1 à 3, dans lequel le processeur est configuré pour générer le vote local en récupérant des données privées distinctes du registre distribué et en évaluant la mise à jour proposée sur la base des données privées. [Revendication 5] Le dispositif informatique selon la revendication 4, dans lequel le processeur est configuré pour générer par ailleurs le vote local en : identifiant d’un sous-ensemble des valeurs affectées par la mise à jour proposée ; et sur la base du sous-ensemble, déterminant s’il faut générer le vote local ou un vote blanc local. [Revendication 6] Le dispositif informatique selon l’une quelconque des revendications 1 à 5, dans lequel le processeur est par ailleurs configuré pour : stocker une file d’attente de mises à jour proposées en mémoire ; en réponse à l’obtention de la mise à jour proposée, placer la mise à jour proposée dans la file d’attente pour synchronisation avec les nœuds clients distants ; et sortir la mise à jour proposée de la file d’attente et déterminer s’il faut permettre la mise à jour proposée en réponse à la réception des votes distants de tous les clients distants. [Revendication 7] Le dispositif informatique selon la revendication 6, dans lequel le processeur est par ailleurs configuré pour : lorsqu’un vote distant manquant d’un des clients distants n’est pas reçu dans un délai de temporisation, conserver la mise à jour proposée, le vote local et les votes distants reçus dans la file d’attente pour une synchronisation subséquente avec ledit un des clients distants. [Revendication 8] Le dispositif informatique selon la revendication 7, dans lequel le processeur est par ailleurs configuré pour : avant de placer la mise à jour proposée dans la file d’attente, déterminer que le vote distant manquant correspond à une pondération de vote distant suffisante pour altérer la détermination de permettre ou non la mise à jour proposée. [Revendication 9] Le dispositif informatique selon l’une quelconque des revendications 6 à 8, dans lequel le processeur est par ailleurs configuré pour : en réponse au placement de la mise à jour proposée dans la file
    d’attente, mettre en œuvre une détermination initiale pour déterminer s’il faut permettre la mise à jour proposée sur la base (i) du vote local et de la pondération du vote local et (ii) des votes distants reçus et des pondérations correspondantes des votes distants ;
    selon la détermination, appliquer la mise à jour proposée au registre distribué ou rejeter la mise à jour proposée et conserver la mise à jour proposée dans la file d’attente ; et en réponse à la réception du vote distant manquant, mettre en œuvre la détermination pour déterminer s’il faut permettre la mise à jour proposée et lorsque la détermination est en conflit avec la détermination initiale, inverser un résultat de la détermination initiale.
    [Revendication 10] Un procédé pour tenir à jour un registre distribué au niveau d’un nœud client, comprenant :
    le stockage d’un registre distribué définissant une pluralité d’enregistrements chacun contenant un ensemble de valeurs ;
    le stockage (i) d’une pondération de vote local correspondant au nœud client, et (ii) des pondérations respectives de votes distants pour une pluralité de nœuds clients distants ;
    l’obtention d’une mise à jour pour un enregistrement du registre distribué ;
    la génération d’un vote local pour appliquer ou rejeter la mise à jour proposée et la transmission du vote local aux nœuds clients distants ; la réception des votes distants pour appliquer ou rejeter la mise à jour proposée des nœuds clients distants ;
    la détermination s’il faut permettre la mise à jour proposée sur la base (i) du vote local et de la pondération du vote local et (ii) des votes distants et des pondérations correspondantes des votes distants ; et selon la détermination, l’application de la mise à jour proposée au registre distribué ou le rejet de la mise à jour proposée.
    [Revendication 11] Un produit programme d’ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour mettre en œuvre les étapes du procédé selon la revendication 10 lorsque ledit programme fonctionne sur un ordinateur.
FR1873072A 2018-12-17 2018-12-17 Registre distribué Active FR3090156B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1873072A FR3090156B1 (fr) 2018-12-17 2018-12-17 Registre distribué
US16/716,869 US11706018B2 (en) 2018-12-17 2019-12-17 System and method for maintaining a distributed ledger

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1873072A FR3090156B1 (fr) 2018-12-17 2018-12-17 Registre distribué

Publications (2)

Publication Number Publication Date
FR3090156A1 true FR3090156A1 (fr) 2020-06-19
FR3090156B1 FR3090156B1 (fr) 2022-03-04

Family

ID=67514676

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1873072A Active FR3090156B1 (fr) 2018-12-17 2018-12-17 Registre distribué

Country Status (2)

Country Link
US (1) US11706018B2 (fr)
FR (1) FR3090156B1 (fr)

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10304143B2 (en) * 2016-05-05 2019-05-28 Lance Timothy Kasper Consensus system for manipulation resistant digital record keeping
US20200366495A1 (en) * 2018-01-29 2020-11-19 Ubiquicorp Limited Proof of majority block consensus method for generating and uploading a block to a blockchain
US10701054B2 (en) * 2018-01-31 2020-06-30 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing super community and community sidechains with consent management for distributed ledger technologies in a cloud based computing environment
US10880070B1 (en) * 2018-02-08 2020-12-29 Rockwell Collins, Inc. Distributed blockchain ledger for vehicular systems
US20190251555A1 (en) * 2018-02-12 2019-08-15 Bank Of America Corporation Distributed ledger system for standby guarantee resources
US11494344B2 (en) * 2018-03-06 2022-11-08 International Business Machines Corporation Customized endorsement logic for blockchain
US20190340623A1 (en) * 2018-05-03 2019-11-07 SigmaLedger, Inc. System and method for verifying authenticity of the products based on proof of ownership and transfer of ownership
US11569981B1 (en) * 2018-08-28 2023-01-31 Amazon Technologies, Inc. Blockchain network based on machine learning-based proof of work
US11144657B2 (en) * 2018-10-23 2021-10-12 Motion Matters Inc. System and method of providing a secure inter-domain data management using blockchain technology
US20200137583A1 (en) * 2018-10-24 2020-04-30 Motorola Solutions, Inc. Distributed radio frequency spectrum sharing coordination system
US11392613B2 (en) * 2018-11-01 2022-07-19 Washington University Systems and methods for probabilistic blockchains

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
ABDUL WAHAB ET AL: "Survey of Consensus Protocols", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 8 October 2018 (2018-10-08), XP081416949 *
CHRISTIAN CACHIN ET AL: "Blockchain Consensus Protocols in the Wild", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 6 July 2017 (2017-07-06), XP080774872 *
DAVID MAZ: "The Stellar Consensus Protocol: A Federated Model for Internet-level Consensus", STELLAR DEVELOPMENT FOUNDATION, 1 January 2015 (2015-01-01), XP055393062, Retrieved from the Internet <URL:https://www.stellar.org/papers/stellar-consensus-protocol.pdf> [retrieved on 20170721] *
DAVID SCHWARTZ ET AL: "Ripple Labs Inc, 2014 The Ripple Protocol Consensus Algorithm", 1 January 2014 (2014-01-01), XP055468556, Retrieved from the Internet <URL:https://ripple.com/files/ripple_consensus_whitepaper.pdf> [retrieved on 20180419] *
MARIUS RAFAILESCU ET AL: "Fault tolerant consensus protocol for distributed database transactions", MANAGEMENT ENGINEERING, SOFTWARE ENGINEERING AND SERVICE SCIENCES, ACM, 2 PENN PLAZA, SUITE 701 NEW YORK NY 10121-0701 USA, 14 January 2017 (2017-01-14), pages 90 - 93, XP058326827, ISBN: 978-1-4503-4834-8, DOI: 10.1145/3034950.3035007 *

Also Published As

Publication number Publication date
US20200195422A1 (en) 2020-06-18
US11706018B2 (en) 2023-07-18
FR3090156B1 (fr) 2022-03-04

Similar Documents

Publication Publication Date Title
AU2021203090A1 (en) Method and system for applying dynamic and adaptive testing techniques to a software system to improve selection of predictive models for personalizing user experiences in the software system
KR101429555B1 (ko) 고 가용성 데이터를 제공하기 위한 시스템 및 방법
CN111727428A (zh) 基于区块链的房间库存管理系统
CA2796554A1 (fr) Outil de gestion de ressources et d&#39;infrastructures informatiques et reseaux
FR2780178A1 (fr) Procede de transformation et d&#39;acheminement de donnees entre des serveurs d&#39;agents presents sur des machines et un serveur d&#39;agent central present sur une autre machine
CN101842802A (zh) 富客户端和浏览器客户端之间的电子表格协作
CN108027828A (zh) 与无状态同步节点的托管文件同步
FR2751814A1 (fr) Systeme de controle et de gestion de services
EP2353256A1 (fr) Determination et gestion de reseaux virtuels
US20110252382A1 (en) Process performance using a people cloud
CN110991789A (zh) 置信区间的确定方法和装置、存储介质及电子装置
FR3003368A1 (fr) Procedes et systemes pour diffuser des informations lors d&#39;une prise de decision concertee
US7092973B2 (en) Conflict detection in a distributed system landscape
CA2488194C (fr) Procede de chargement de changements de plannings de vol
FR3090156A1 (fr) Registre distribué
WO2021043599A1 (fr) Migration d&#39;une chaîne de blocs de données
EP3732635B1 (fr) Systeme et procede de gestion de l&#39;entretien au cours d&#39;un rassemblement de masse
US9588745B1 (en) Customizable service delivery system with scalable workflow
US10157377B2 (en) System and method for reservation inventory management
EP3080706B1 (fr) Procédé de sauvegarde de données stockées sur un terminal
FR3062228A1 (fr) Base de donnees agregative d&#39;enregistrements contexte
FR3067490A1 (fr) TRAITEMENT DE MESSAGES MULTlNORMES
FR3090928A1 (fr) Systeme de gestion de donnes synchronise et procede
US20230273915A1 (en) Data conflict resolution in periodically offline systems
FR3067832A1 (fr) Fourniture de services inter-groupements

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20200619

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6