FR3101991A1 - Système et méthode d'authentification et d'assurance d’objets - Google Patents

Abstract

Un système d’authentification d’objets détenus par son propriétaire ou détenteur, fait intervenir au moins un groupe manufacturier 201, un groupe d’assureurs 103 et un groupe d’usagers 104. Son intégrité et l’absence de conflits d’intérêt est garanti par un processus de gestion comprenant au moins deux ledgers distribués MDL (fig. 2).

Description

Système et méthode d'authentification et d'assurance d’objets

La présente invention concerne une méthode et un système d'authentification, respectueux de la vie privée des utilisateurs, rentable, économe en temps de traitement, efficace et sécurisé, d'un produit/objet détenu par son propriétaire/titulaire dans un cadre particulier qui est celui de l'assurance d’un produit/objet authentique. La notion générale d’objet recouvre aussi bien des produits physiques réalisés par l’activité humaine, ou artefacts, que des objets abstraits mais susceptibles d’authenticité et d’assurabilité. Lesdits artefacts peuvent être réalisés par des robots, ou des procédés divers tels qu’impression 3D : la notion d’activité humaine est considérée au sens le plus large. Dans toute la suite, le terme produit sera entendu comme couvrant également la notion plus générale d’objet.
Les produits authentiques sont décrits par des données pouvant être échangées de machine à machine, via un contrat dénommé smart-contract, ou par tout autre moyen.

La plupart des systèmes connus font appel à des méthodes manuelles, non automatisées et sont de ce fait peu efficaces. De nombreuses parties doivent interagir pour procurer une garantie d’authenticité. Un tel système requiert que tous les intervenants, tels que mais sans limitation, l’assureur, le fabricant, le revendeur et dans certains cas un expert, se mettent d’accord sur le fait que le produit est authentique et peut être assuré pour un coût déterminé avec des termes et conditions spécifiques. Ces termes et conditions sont précisés dans le smart-contract.

De là, une fois que les parties sont d’accord, qu’un acheteur est intéressé à acheter un bien ou objet qui bénéficie d’une garantie d’authenticité, et que cet acheteur peut l’assurer pour en protéger la valeur, l’objet ainsi que son propriétaire doivent être tracés pour pouvoir gérer un sinistre conformément aux termes et conditions du smart-contract. La plupart du temps, les coûts associés avec un tel processus sont prohibitifs et le rendent de fait non économique. Le coût de gestion de ce processus est trop élevé vis-à-vis de ce que l’acheteur potentiel est prêt à payer. De plus, quand le risque se révèle non quantifiable, il est de ce fait non assurable.

Récemment, une technologie de chaîne de blocs a été développée, dans laquelle une chaîne de blocs est un grand livre public sous la forme d'une base de données distribuée contenant une pluralité de blocs de données et qui maintient une liste sans cesse croissante d'enregistrements de données. La notion de liste sans cesse croissante est connue en soi dans la technologie de la blockchain et fréquemment désignée par le terme anglais append-only. Cette technologie de chaîne de blocs est renforcée ou durcie par des moyens cryptographiques contre toute tentative de modification ou de falsification. Une des applications les plus importantes de la technologie blockchain est la devise virtuelle Bitcoin utilisée pour les transactions monétaires sur Internet. Une autre plateforme connue de blockchain est fournie par exemple par le projet Ethereum, dans le cadre de la rédaction et du codage des smart-contract et/ou d’Azure pour le déploiement des registres multi-distribués. De manière générale, une blockchain peut être décrite comme un protocole décentralisé pour la journalisation des transactions entre les parties, qui capture et stocke de manière transparente toute modification apportée à sa base de données répartie et les enregistre pour une durée correspondant à la durée de vie de la blockchain. Le stockage d'informations dans une blockchain implique la signature numérique des informations à stocker dans un bloc de la blockchain.

Un premier objectif de cette invention est de supprimer la majeure partie du processus de traitement des frais généraux et d'automatiser de telles transactions avec une intervention humaine minimale, afin de le rendre compétitif et abordable.

Un second objectif de l’invention est de faire en sorte que ce nouveau processus soit résistant à la falsification, évolutif dans le sens où il est compatible avec un changement d’échelle, et résilient dans le sens de robuste. Le processus selon l’invention doit de plus respecter toutes les réglementations locales applicables, sans toutefois s’y limiter, comme le RGPD de l’Union européenne, ou GDPR dans la terminologie anglaise, par exemple mais pas uniquement.

Un troisième objectif de l’invention est de connaître sans risque d’erreur le nombre de produits ou objets authentiques fabriqués, avec un contrôle permanent.

Plus précisément, l'invention concerne un système sécurisé multi-composants pour la traçabilité d’objets, lesdits objets pouvant être des produits physiques, authentiques et originaux (sans toutefois se limiter à ces objets physiques), qui consiste en :

1. un premier procédé garantissant une authentification efficace, sécurisée et évolutive tout au long du cycle de vie d’un objet sur un réseau de communication,
2. un second procédé comprenant un système de gestion de la propriété dudit objet, et notamment :
   • la propriété voire la détention par un titulaire/propriétaire intégrant le souci de préserver la vie privée dudit propriétaire / titulaire, définissant le type d’assurance de l’objet authentique. A titre d’exemple, l’assurance peut être une assurance contre le vol et le dommage pour un laps de temps déterminé, pour une zone géographique particulière, ou tout autre spécification au contrat.

Concernant le cycle de vie des objets ou produits, une mise à jour de l'information sur l’objet ou produit comprendra préférentiellement son évolution dans le temps : sac vendu, montre volée mais retrouvée, peinture endommagée..., l'assurance n'est pas renouvelée, … objet contrefait…
La suite fera appel à la notion de ledger multi-distribué, abrégé en MDL. Le sigle MDL désignera le concept de registre distribué, couvrant également la notion comptable de Grand Livre ou livre des écritures, ou la définition Wikipedia d’un ensemble de données digitales dupliquées, partagées et synchronisées et réparties géographiquement sur de multiples sites, pays ou institutions.

Outre les deux procédés précités, l'invention comprend les étapes ou processus suivants qui sont renforcés par une multiplicité de facteurs de sécurité et rendent le système unique. Les facteurs de sécurité précités peuvent être redondants, ceci pouvant s’illustrer par l’expression du langage courant : ceinture et bretelles. Ces facteurs de sécurité peuvent être des méthodes d’authentification et de respect des données personnelles connues en soi, mais combinées dans un environnement particulier au sein d’une technologie blockchain. Parmi ces facteurs de sécurité, citons notamment :

1. Un registre multi-distribué (MDL), comprenant au moins 2 grands livres : un premier grand livre stockant les données relatives aux objets, la preuve de leur authenticité ainsi que d'autres données spécifiques à l’un quelconque de ces objets, un 2e grand livre qui enregistre la transaction d'assurance ainsi que le bénéficiaire de la transaction, mais analysé de manière indépendante, ce qui permet de se conformer à l'article 17 du RGP UE "Droit à l'oubli".
2. une fonction physique non-clonable (dont l’acronyme anglais est PUF) qui est attachée à l'objet et permet de caractériser cet objet, Une PUF, qui comprend un mécanisme de défi-réponse (traduction de l’anglais « Challenge/Response » ou C/R), peut être décrite comme une fonction avec bruit de type gaussienne, ce qui est une traduction de l’anglais « noisy function ». Ceci se comprend par opposition à un bruit blanc (type de fonction gaussienne). En effet, de manière connue, le bruit est biaisé par le fait que les C/R donnent des réponses voisines dans 90% des cas. Dans toute la suite, on parlera de CRP pour Challenge-Response Protocol ou protocole de défi et réponse.
3. un mécanisme de consensus prédéfini et décentralisé, en présence d'un comportement byzantin qui sera décrit plus bas au paragraphe 12, qui est utilisé pour valider les nouvelles entrées de données au moyen d’une technique CRP de défis et de réponses. Ces nouvelles entrées sont ajoutées à la blockchain et forment ainsi un nouveau bloc de cette blockchain.
4. Un jeton protégeant chaque nouvelle entrée de données, c’est-à-dire un enregistrement de transaction, en ce que cet enregistrement est "haché", au sens de l’anglais hash, ce qui signifie qu’une fonction de hachage cryptographique est appliquée au message original et que ce message ne peut pas être modifié.

À cette fin, les actions suivantes doivent être réalisées :
1. Au cours du processus de fabrication de chaque objet, une étiquette, ou encore balise, associée à un mécanisme de communication sans fil tel que RFID, une puce NFC, un QR code, ou tout autre mécanisme approprié, est intégrée à chaque objet. Ces mécanismes sont associés à la fonction PUF précitée. Lorsque cela n'est pas faisable, un autre mécanisme approprié est fourni, tel que, sans toutefois s'y limiter, un numéro de série, par exemple, spécifique au fabricant (voir paragraphes 8 et 9).
2. Au moment de l'envoi de l'objet à son premier utilisateur, qui peut être un distributeur, exclusif ou non, un client particulier, une place de marché, ou autre, le mécanisme de communication sans fil est utilisé (le canal RFID par exemple) et l'étiquette contenant un ensemble complet d'informations est lue et identifiée afin de vérifier le fichier PUF susmentionné. L’authentification de l'objet est faite en activant la confirmation de la signature (défi/réponse ou encore, en anglais, Challenge / Response) de la fonction physique non clonable (PUF), puis en constituant le premier identifiant de l'objet (OID).
3. Un utilisateur est caractérisé par son appartenance à un Users Group et est défini par son identifiant UID. Le nom d'utilisateur est crypté dans un bloc, réputé immuable, et qui prend la forme d’un code d'utilisateur unique qu’on appellera MID, abréviation de l’identifiant de membre Member ID, dans toute la suite. Ce code MID sera stocké dans le "grand livre de l'utilisateur" du grand livre multi-distribué (MDL). Ce bloc ne sera accessible que par l'utilisateur ayant le code secret ou passcode qu'il a lui-même choisi, et qu'il est seul à connaître, pour lire son UID et accéder à son compte. Cela évite que le nom d'utilisateur apparaisse en clair dans un grand livre. Ce nom d’utilisateur est chiffré ou encrypté avec la clé de hachage (le passcode ou code d'accès) que seul le client connaît, dans le grand livre ou registre consacré ou dédié aux transactions, et apparaît comme un UID dans le grand livre consacré au produit. Ce code d'authentification peut également accueillir toute clé publique / privée, symétrique / asymétrique, mais une entité virtuelle d'administration jouant le rôle d'autorité de certification externe est nécessaire pour préserver la clé publique. Seul l'utilisateur connaît la clé privée. De tels systèmes offrent une protection difficile à casser et sont considérés comme inviolables par des experts en cryptographie.
4. Avant de stocker des enregistrements, il y a lieu de qualifier tout nouveau bloc. Le grand livre multi-distribué utilise dans ce but un processus dit byzantin qui utilisera une famille de protocoles de consensus pour les crypto-monnaies, en étant adapté à un changement d’échelle, en anglais scalable. Il utilisera aussi un consensus BFT, dans le sens de byzantin avec tolérance d’erreurs, évolutif et de plus probabiliste sans chef par métastabilité, la métastabilité étant définie par les deux seules possibilités oui ou non, aussi désignées dans la suite par Y/N. Ce BFT est dérivé du protocole Avalanche (voir plus loin) pour authentifier l'objet qui est caractérisé / identifié dans le grand livre par les informations contenues dans le bloc du ledger objet relié à l'étiquette. Dans la suite, le concept de tolérance d’erreur pourra aussi être désignée par tolérance de panne ou tolérance à la faute.
5. Les détails de la transaction, y compris l'OID de l'objet précédent et l'UID du bénéficiaire de la transaction en cours, sont chiffrés dans un autre bloc dit immuable sous la forme d'un code de transaction unique (relié à l’OID) qui sera stocké dans un bloc du ledger des transactions du grand livre d'un multi -Groupe distribué et connecté au grand livre de l'utilisateur en utilisant l'objet OID dans le grand livre de l'utilisateur.
6. Au moment de chaque nouvelle transaction, les OID et les UID seront horodatés et stockés dans de nouveaux blocs dits immuables complétant les chaînes de blocs.
7. En outre, dans le cadre particulier de l'assurance des objets authentiques, l'assureur veut, lorsqu'il vend une assurance, s'assurer que l'objet est authentique, autrement dit que ce n'est pas une falsification ou contrefaçon, et qu'il a une valeur marchande de x qui servira de base au calcul de l'indemnité en cas de réclamation. Le processus sera basé uniquement sur la balise ou étiquette non-clonable / unique, conçue pour certifier l'authenticité de l'objet sans le voir. Dans ce contexte, les étapes suivantes devront être suivies :
a. L'utilisateur sélectionne un mot de passe, ou code d’accès, ou jeton (traduction de l’anglais token), pour chiffrer son nom dans le grand livre enregistrant les transactions / paiements d'assurance pour un bien vendu. Le nom du bénéficiaire est crypté dans le bloc immuable qui contient le smart-contract (ou contrat d’assurance intelligente), qui contient un lien vers l’autre entrée du grand livre de l’utilisateur sous la forme d’un code de contrat d’assurance unique (IID).
b. Le système crée un nouveau bloc dans le grand livre qui enregistre le bénéficiaire des opérations d'assurance, dans lequel le nom du bénéficiaire est crypté dans le bloc immuable qui contient le smart-contrat, ou contrat d'assurance intelligent, et le lien avec le grand livre de l'utilisateur. Dans les deux blocs, le nom est crypté, tout le reste est lisible en clair.
c. L’IID du contrat d’assurance intelligent est incorporé à l’OID précédent, chiffré dans un autre bloc dit immuable sous la forme d’un nouveau code unique de l’objet (OID) qui sera stocké dans les transactions du grand livre à distribution multiple MDL, et sera connecté au grand livre de l'utilisateur via l'OID de l'objet, dans le grand livre de l'utilisateur.
d. En cas de réclamation, appelé aussi claim ou demande dans toute la suite, le bénéficiaire fournit le mot de passe ou code d'authentification, et son nom. Le système décrypte le nom dans le bloc. Si les noms correspondent au nom enregistré dans le registre des utilisateurs, on passe à l'étape suivante.
e. Le système demande le bloc dans l'autre livre associé à la transaction d'assurances, récupère le bloc, déchiffre le nom et, si les noms correspondent, lance le traitement des demandes, dans un nouveau bloc lié à la demande ou claim (CID) est enregistré dans le livre de transaction.
f. Pour valider les nouvelles entrées de données qui sont ajoutées à la blockchain et qui forment ainsi de nouvelles entrées dans le grand livre, le système traite les demandes avec le vote des participants sur les points suivants : {objet identifié : Y | N ; objet assuré : Y | N ; demande valide (ou invalide) : Y | N}. Pour autant que toutes les réponses soient Y, un nouveau bloc relatif à la réclamation est ajouté dans le livre de transactions. Une fois la demande validée, l'assureur procède au paiement (ou pas) et un nouveau bloc lié à la transaction, le cas échéant (par exemple paiement au bénéficiaire), est enregistré dans le grand livre de l'utilisateur.
g. Ce grand livre à un moment donné connaît le nom du bénéficiaire, mais ce nom n’est jamais enregistré. Il est contenu dans un fichier temporaire. Un fichier temporaire est défini comme un fichier créé par le programme pour y stocker des informations qui ne sont utiles que pendant la durée dudit programme, typiquement des données qui ne peuvent pas rester en mémoire. Ces fichiers temporaires sont effacés à la fin de l’exécution du programme. L’entrée du nom dans le programme est simplement utilisée pour prouver que le code d’accès est correct.
8. Dans l’hypothèse où la balise ou étiquette ou tag n'est pas incorporée dans l'objet, mais où le fabricant existe toujours et est prêt à incorporer une balise dans l'objet ; l'objet est renvoyé au fabricant pour l'intégration d’une étiquette. Si après vérification l'objet est authentifié par le fabricant, une étiquette (puce RFID / NFC ou autre) est intégrée par le fabricant et le processus suit alors les étapes 2 à 7 précédemment décrites.
9. Examinons maintenant l’hypothèse où la balise n’est pas intégrée à l’objet et où le fabricant n’existe plus, ou encore n’est pas prêt à certifier l’authenticité de l’objet et / ou à intégrer une balise à l’objet. Une étiquette peut toujours être intégrée sous la responsabilité d'une autorité de certification telle qu'une maison de vente aux enchères réputée ou un expert, à condition que le propriétaire actuel puisse fournir des preuves de l'authenticité de l'objet à ladite autorité de certification, y compris, mais sans s'y limiter nécessairement, la propriété du produit. Une facture du détenteur actuel de l’objet, avec la valeur originale et date d'achat, ou une facture de l'ancien titulaire avec la valeur et la date d'achat, des photographies de l'objet pouvant servir de preuve du fabricant d'origine, d’autres moyens de preuve fournies par des forces de police, les douanes ou un expert, par exemple, afin que l’autorité de certification puisse générer au moins une preuve publique indépendante qui puisse permettre de certifier l’origine. Cette demande détaille le type de vérifications qui ont été effectuées et qui peuvent être produites à tout acheteur potentiel, en ligne ou sous forme imprimée, et qui peuvent être utilisés pour effectuer une transaction.
10. Si l'objet est authentifié par l'autorité de certification, une étiquette (puce RFID / NFC / QR code infalsifiable ou tout autre moyen) est intégrée sous la responsabilité de l'autorité de certification, puis le processus suit les étapes 2 à 7 ci-dessus.
11. Un aspect de l'invention concerne aussi la manière d’utiliser le système pour pouvoir fournir une base de données publique et un moteur de recherche donnant à chaque produit sa valeur estimée basée sur le dernier prix / cours acheteur pour un produit de même marque, de la même année et dans un état équivalent. Le système offre des possibilités de recherche et de tri permettant au propriétaire, à l’acheteur potentiel, à l’assureur, etc. d’obtenir une information transparente de marché sur les objets authentiques enregistrés, y compris une description publique de l’objet et le prix public des transactions validées sur des produits authentiquement enregistrés. Ceci permet au système de publier une évaluation du prix de chaque objet enregistré authentique dans une plage de prix min-max. En outre, le système peut fournir une base de données publique sur les prix des offres et des offres pour les produits authentiques enregistrés.
12. L’architecture du système comprend une base de données et un réseau de nœuds, les nœuds correspondant aux utilisateurs anonymes, dans lesquels la base de données est une base de données partagée, distribuée, tolérante aux pannes ou erreurs. Cette base de données est constituée uniquement d'ajouts, et est également définie comme append-only. Ceci garantit l’enchaînement des blocs. De plus, l'approche par consensus choisie n'inclut aucun type de ressources mais utilise le consensus de blockchain basé sur l'approche byzantine de tolérance aux pannes ou BFT. Dans cette approche, tout d'abord, un leader est sélectionné et convenu entre les nœuds. Le responsable décide de la validation des transactions et publie un bloc sur tous les nœuds du réseau blockchain. Une transaction est validée dans un nouveau bloc uniquement si les deux tiers des nœuds dits minés vérifient son exactitude. Dans l’utilisation de la technologie blockchain pour les Bitcoins, la notion de nœud miné est connue en soi ; le minage est la validation d'un bloc par un des membres du réseau ou nœud. Un bloc est un groupe d'opérations, qui vont être groupées entre elles, et mises à la suite de la chaîne de blocs (ie la blockchain), constituant ainsi un nouveau maillon à cette chaîne.
Le chef, ou leader, change fréquemment. Par conséquent, l'approche n'est pas considérée comme centralisée. Jusqu'en 2018, un protocole de tolérance aux pannes byzantines, mis au point par Barbara Liskov et Miguel Castro était plus rapide que d'autres méthodes ; toutefois, il présente des problèmes d’évolutivité, plus exactement d’adaptation au changement d’échelle ou scalabilité, dus à la surcharge de communication qui en résulte.
Depuis 2018, le Pr Emin Gün Sirer de l’Université Cornell a introduit une famille de protocoles de tolérance de panne byzantine sans leader, construits autour d’un mécanisme métastable via un sous-échantillonnage du réseau. Ces protocoles offrent une garantie de sécurité probabiliste forte en présence d'adversaires byzantins, tandis que leur nature simultanée et sans leader leur permet d'atteindre un débit et une évolutivité élevés. Ces nouveaux protocoles de consensus résolvent les problèmes d’évolutivité mentionnée précédemment pour la précédente la méthode Liskov - Castro.
La gestion des conflits en présence d'un comportement byzantin peut se faire par l'utilisation d'une famille de protocoles de consensus, Ces protocoles fournissent une garantie de sécurité probabiliste, en utilisant des paramètres de sécurité réglables pour rendre la possibilité d'un échec consensuel arbitrairement faible. Une explication y relative, et l'application de AVA, est divulguée dans "Snowflake to Avalanche : A Novel Metastable Consensus Protocol Family for Cryptocurrencies, Team Rocket, 2018" disponible sur Internet à l'hyperlien suivant :
https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV

Description de l'invention

Le système et la méthode d'authentification et d'assurance des objets authentiques de la présente invention a pour but de remédier aux inconvénients de toutes les techniques, systèmes et méthodologies précédemment connus concernant la preuve d'authenticité des objets assurés, de garantir l'anonymat exigé par les réglementations de l'UE sur les données personnelles des citoyens. Il a de plus pour but de garantir l'existence d'un contrat d'assurance lié à l'objet tout au long de son cycle de vie, et plus généralement l'intégrité et la provenance des données, l'enregistrement, la vérification, l'accès, le contrôle et la gestion des informations relatives à divers objets.

L'invention se compose de :
Une méthode et un système pour une authentification efficace, sécurisée et évolutive tout au long du cycle de vie d'un objet sur un réseau de communication,
Une méthode et un système de gestion de la propriété de l'objet détenu, tout en préservant la protection des données personnelles de son propriétaire ou détenteur, et en particulier :
Une méthode et un système pour définir l'assurance des objets authentiques dont le bénéficiaire est gardé secret dans le grand livre, mais qui doit se faire connaître au moment où il achète une assurance et ou moment où il fait une réclamation.

Essentiellement, dans diverses formes de réalisation de celui-ci, le système et la méthode selon l’invention fournissent avantageusement au moins une preuve d'authenticité d'objets assurés sur la base d'un marquage de sécurité composite pour un objet physique comprenant : un tag intégré dans l'objet physique, caractérisée en ce que l'étiquette comprend une fonction physique non clonable (PUF) pour se protéger contre la falsification et la subversion par substitution.
Dans l’invention, cette étiquette contient au moins une représentation signée numériquement de l'objet et/ou un pointeur indiquant un l'emplacement où ladite représentation de l'objet signée numériquement peut être consultée. De plus, la représentation de l'objet peut être signée numériquement soit par le seul fabricant d'origine, soit par une signature multiple par plusieurs entités impliquées dans la chaîne d'approvisionnement y compris jusqu’au marché secondaire.

Par ailleurs, la signature numérique signe numériquement une valeur de hachage résultant de l'application d'une fonction de hachage cryptographique prédéterminée, appliquée aux données représentant une réponse générée par le PUF en réaction au défi d’un schéma d’authentification de défi-réponse prédéterminé (en anglais : CRP pour challenge-response protocol).

De plus, le PUF comprend un code d'identification unique (OID) attribué à chaque produit; dans l’invention, les données représentant une réponse générée par le PUF en réaction à un défi d'un système d'authentification de réponse de défi prédéterminé pour ledit OID; et l'étiquette peut être authentifiée, même sans alimentation électrique externe, par des appareils mobiles, qui sont eux-mêmes capables de vérifier la signature et de lire l'historique transactionnel de l'objet dans au moins un grand livre distribué ou une chaîne de blocs.

Pour surmonter les inconvénients des problèmes d'évolutivité et/ou pour prévenir les attaques de Sybil comme la possibilité de déni de service (en anglais : DOS) et d'attaques de rediffusion, le système ajoute au PUF un protocole pour parvenir à un consensus en présence de failles byzantines dans un réseau. Une attaque Sybil est définie comme une attaque au sein d’un système de réputation qui est renversé par la création de fausses identités dans un réseau informatique de pair à pair.

Chaque objet de la blockchain est caractérisé par son OID. L’OID est une clé unique qui ne contient pas d’informations cachées. Cette clé identifie le champ d’information qui est dans le bloc. Elle peut être vue comme un index unique dans une base de données. Elle peut inclure tout ce qui permet de vérifier l'authenticité de l'objet tel que l'origine du produit, le nom du fabricant, le numéro de série du fabricant, le site de production, la date de production, le lien vers le code d'identification crypté, ou UID, du propriétaire, contrat d'assurance, réclamations, etc. Ces informations sont habituellement intégrées, stockées ou enregistrées dans les blocks du ledger associés au tag du produit. Ce tag peut être consulté à distance par un mécanisme de communication sans fil, y compris, mais pas nécessairement limité à NFC qui nécessite une utilisation en d’un RFID, d'un code QR, d'un code à barres, de tout motif ou symbole, etc.

Ces informations sont toujours associées à l'un ou l'autre des OID comme une preuve d'authenticité et d’origine d’un objet enregistré et stocké dans un ou plusieurs entrées de produits particuliers dans un registre multidistribué MDL sur au moins un réseau de communication (câblé, sans fil, accès à distance, etc.) et associé à un propriétaire caractérisé par son UID ou Code d'identification utilisateur (UID) stocké dans un registre des propriétaires du registre Multi-Distribué MDL. La figure 2 illustre ce registre distribué par la référence 219.

L'UID peut être imprimé, intégré et/ou inséré à un endroit spécifique tel qu'étiquette ou tag, carte, surface, l'intérieur, tableau principal au sens de mainboard dans la terminologie anglaise, module, panneau de processeur, panneau de commande, panneau de communication, panneau d'affichage, panneau de circuit intégré ou IC, panneau de capteur, circuit imprimé flexible (ou FPCB pour Flexible Printed Circuit Board), circuit imprimé (PCB), RFID, inlay, processeur, puce, IC tel que défini précédemment, ou capteur, pour fournir et/ou diffuser et/ou transmettre des informations selon l'UID à des fins prédéterminées.

Avantageusement, et conformément à diverses formes de réalisation de l’invention, le système et la méthode selon invention garantissent l'anonymat des données personnelles des citoyens de l'UE sur la base d'un grand livre multi-distribué (MDL), comprenant : un grand livre de stockage des données relatives au propriétaire et/ou au bénéficiaire de l'opération. Ce livre est encrypté et désigné par Ledger 2 dans la figure 2. Les informations encryptées de ce Ledger 2 sont liées à, et intégrées dans, au moins un autre registre, désigné dans la figure 2 comme Ledger 1, dans lequel sont stockés tous les enregistrements relatifs aux transactions, mais analysés indépendamment, ce qui permet de garantir la conformité avec l'article 17 du RGPD, ou GDPR dans la terminologie anglaise, de l'UE " Droit à l'oubli ».

Le grand livre multi-distribué MDL est construit avec une blockchain publique (ledger 1 dans la figure 2) pour les données publiques, et une blockchain privée (ledger 2 dans la figure 2) pour les données privées. On parle dans cet exemple d’une forme de réalisation avec uniquement deux ledgers.

Le grand livre multi-distribué MDL est construit avec l'exigence qu'il doit toujours y avoir un enregistrement des transactions ou du propriétaire/bénéficiaire sur les deux blockchains afin de valider un bloc/transaction, sachant que le grand livre privé est le seul à connaître le nom du propriétaire/bénéficiaire, mais que ce nom n'est jamais enregistré. Il est simplement utilisé comme une preuve que le code d'accès est correct.

Chaque section de ce MDL est construite spécifiquement pour la partie publique ou privée du certificat numérique qui est présenté au nouveau propriétaire et/ou à l'assureur. Cette double approche signifie qu'il existe deux registres distribués qui fonctionnent spécifiquement pour les données publiques ou privées.

Bien que dans la partie publique de l'architecture du système qui consiste en le ledger 1 de la figure 2, à savoir le registre des transactions, les blocs sont accessibles par tous les utilisateurs de la blockchain. Ils ne peuvent pas être supprimés ou modifiés par eux. Les blocs sont connectés les uns aux autres dans une chaîne dans laquelle chaque bloc a la valeur de hachage de son prédécesseur, chaque bloc contient plusieurs transactions vérifiées, de manière que chaque bloc comprend un horodatage indiquant l’heure et la date de la création de ce bloc.

Le registre des transactions Ledger 1 est conçu pour prendre en charge uniquement les données publiques : un vaste ensemble d'informations qui peuvent être lues et authentifiées par un système de contrôle, ou lecteur, et qui constitue le premier identifiant de l'objet (OID). Cependant le nom du propriétaire / nom du bénéficiaire n'apparaît pas clairement dans le registre des transactions, il est crypté via une clé de hachage avec un code qui est la seule information du propriétaire enregistrée dans le registre consacré aux transactions. Il apparaît comme un UID dans ce registre des transactions consacré au produit.

N'importe qui peut accéder à l'information sur ces ledger 1 et 2 et voir le flux en cours, la valeur, l'OID des parties impliquées dans les transactions, mais pas leur nom. Il n’existe aucun moyen d’obtenir ce nom qui n’est pas enregistré.

Dans la partie privée de l'architecture du système, le registre du propriétaire stocke des informations confidentielles et chiffrées sur le propriétaire/bénéficiaire. Il n'est accessible qu'aux personnes autorisées avec un processus d'identification basé sur son nom et un code d'accès qui lui permettra de déchiffrer son nom dans le bloc si les noms correspondent. Le nom n'est jamais enregistré, il est simplement utilisé comme une preuve que le code d'accès est correct. Pour de nombreux utilisateurs, la nature privée de ce registre des propriétaires est l'avantage principal du système selon l’invention, car il maintient la confidentialité des noms des propriétaires sans prendre le risque que cette nature confidentielle diminue la sécurité.

En utilisant un mécanisme multi-ledger (MDL), les deux parties bénéficient d'un processus de transaction plus rationalisé, avec des coûts réduits et une validation de transaction qui peut être réalisée en quelques secondes. Les deux registres, le grand livre des transactions et le grand livre des propriétaires, mettent en œuvre un mécanisme de consensus qui évite la validation basée sur le calcul à forte intensité de ressources et permet une évolutivité élevée. Le plus grand avantage est qu'aucun individu ou entreprise n'a le contrôle sur l'information, de sorte que le système ne peut pas être manipulé. Ni le propriétaire de la blockchain, ni aucune autre partie, ne peut modifier unilatéralement les informations contenues dans le registre. Les utilisateurs n'ont pas besoin d’utiliser une tierce partie de confiance pour utiliser la blockchain.

En outre, dans le cadre particulier de l'assurance des objets authentiques, l'assureur quand il vend de l'assurance, veut être sûr que l'objet est authentique, c’est-à-dire qu’il ne s’agit pas d’une contrefaçon, et qu'il a une valeur marchande de x sur la base de laquelle sera définie l'indemnité en cas de sinistre, en se basant uniquement sur l'étiquette unique et non clonable pour authentifier l'authenticité de l'objet sans le voir.

Avantageusement, conformément à diverses formes de réalisation, le système et la méthode selon l’invention fournissent une preuve d'authenticité des objets enregistrés dans le registre multi-distribué, caractérisée en ce que le bénéficiaire de la police d'assurance peut utiliser son nom et son code d'accès pour déchiffrer le nom crypté dans le bloc lié au propriétaire de l'objet à assurer dans le registre des utilisateurs Ledger 2, puis faire une requête dans le registre des objets, pour vérifier si l'objet est dans le grand livre Ledger 1. L'utilisateur acquiert alors la preuve de l'authenticité de l’objet et l'existence d'un contrat d'assurance relatif à l'objet. Cette information sera accessible à l'assureur pour cotation ; en outre et à condition que le prix estimatif de l'objet soit enregistré dans le registre des objets, l'assureur peut également être informé de la valeur estimée du produit au moment de la transaction ; l'identification/authentification du produit est réalisée en utilisant l'approche byzantine tolérante aux défauts déjà décrite, et schématiquement représentée à la Figure 3.
L'assureur enverra alors sa cotation à l'utilisateur et, si cette cotation est acceptée, le contrat est conclu et le paiement pourra être effectué. Un nouveau bloc OID sera créé dans le registre des objets qui comprend l'ID d'assurance (IID) associé au produit. En cas de réclamation à la suite d’un sinistre, le bénéficiaire utilise son nom et son code d'accès pour décrypter l’identifiant du nom encrypté dans le bloc du Ledger 2 relatif au propriétaire de l'objet, pour obtenir l’IID, qui constitue la preuve du contrat d'assurance crypté dans l'OID. Cette preuve sera jointe à la réclamation faite à son assureur, qui traitera ensuite le paiement. À ce stade, un nouveau bloc OID sera créé dans le registre des objets, qui comprend l'ID de réclamation de résolution d'assurance, ci-après désigné par CID, qui est associé au produit et qui a été enregistré dans le Ledger 2.

Dans une forme particulière de réalisation de l’invention, lorsque l’objet ou produit est marqué, lors de sa fabrication, par l’intégration d’une puce ou tag ou balise (ci-après : puce), un numéro est attaché à chacune de ces puces qui ne peuvent être enlevées du produit sans démontage. Dans cette forme, le système est capable d’enregistrer ce numéro en l’enregistrant dans l’OID du ledger object. Par conséquent, il est impossible d’ajouter discrètement un faux dans la distribution, car le numéro serait alors manquant ce qui est facilement repérable. Cette caractéristique limite grandement les risques de contrefaçon. De plus, la possibilité pour un membre d’un groupe de contrôler le produit ou objet par un moyen simple, tel que par exemple, mais sans s’y limiter, un téléphone portable, offre une facilité supplémentaire de contrôle. Si par exemple un acheteur d’un sac souscrit l’assurance proposée dans le cadre du système selon l’invention, puis décide de le déclarer frauduleusement comme volé, dans le but de toucher l’indemnité, le système peut détecter ce sac, l’assureur peut lancer une alerte et la tentative de fraude est déjouée.

D’autres avantages de l’invention, appelée Alethia dans certaines figures, apparaîtront à la lecture de la description détaillée qui va suivre, en liaison avec le dessin dont une liste des figures est fournie ci-après.

: Les parties au système, ou en anglais stakeholders, et leurs droits/privilèges

: MDL ou Multi-Distributed Ledger

: Processus byzantin

: Ajout d'un nouveau bloc/nouvel objet au "Object" Ledger

: Ajout d'un nouveau bloc/nouvel objet physique au Ledger "Objet" utilisant la fonction PUF intégrée pour garantir l'authenticité

: Ajout d'un nouveau bloc/nouvel objet physique au Ledger "Objet" utilisant d'autres propriétés pour garantir l'authenticité

: Gestion des codes de hachage ou des clés de chiffrement

: Utilisation du système pour fournir une base de données publique et un moteur de recherche donnant pour chaque produit sa valeur estimée.

Les figures 9 à 15 concernent les diverses opérations relatives à une forme préférée de l’invention.

, intitulée « In store, first registry »

, intitulée « In store, following registration at shop » ;

, intitulée « Online purchase (Alethia exchange) » ;

, intitulée « Third beneficiary purchases »  ;

, intitulée « Offer creation » ;

, intitulée « Insurance procedure » ;

, intituée “Statistics”.
Description détaillée des formes de réalisation préférées

Les caractéristiques de l'invention dans des formes de réalisation préférées sont énoncées ci-après, ainsi que dans les revendications et sous-revendications annexées. L'invention sera mieux comprise par référence à la description détaillée suivante.

La FIG. 1 définit et précise les droits et privilèges de chaque partie au système selon l’invention, également appelé stakeholder, intervenant voire même actionnaire, au sein du système de gestion d'authenticité. Elle illustre également un système pouvant être basé sur le cloud pour l'authentification et l'assurance d'objets authentiques 100.
Le système comprend six groupes d’intervenants, à savoir :
Le groupe des fabricants ou manufacturier, ou Manufacturers group 101.
Un autre groupe 102 comprend des tierces parties.
Un groupe 103 comprend des assureurs ou Insurers.
Un Groupe 104 comprend des users ou utilisateurs.
Puis deux entités virtuelles :
Les "experts byzantins » qui sont le groupe 105, et
Le groupe des Administrateurs ou Administrators, qui sont le groupe 106 .

Le groupe des fabricants 101 comprend les fabricants, magasin, marché du commerce électronique, lieu d'enchères. Ce groupe gère le registre des « objets » : chaque objet du registre des « objets » est un objet authentique. Chaque membre du groupe 101 peut ajouter un bloc supplémentaire à un bloc existant. Ceci contribue à la traçabilité du cycle de vie du produit.

De plus, seuls les fabricants peuvent créer un nouveau bloc lié à un nouvel objet sans l'accord des autres membres du groupe à l'exception de quelques membres du groupe 102.

Le groupe 102 des tierces parties intègre des entités de confiance (public/privé) qui peuvent garantir / authentifier si oui ou non un objet est véritable, sur la base d'informations qu'elles possèdent. À la demande de l’un quelconque des membres du groupe 102 des tierces parties, un nouvel objet peut être ajouté au registre des objets. Ceci revient à créer un nouveau bloc. La création de ce nouveau bloc dans le registre des objets est ensuite soumise au vote du groupe d'experts « byzantins » pour approbation.

Le groupe des assureurs 103 comprend tous les assureurs. Ce groupe Assureurs gère le registre des « contrats » ou smart-contracts ou contrats de garantie ou d’assurance. A chaque objet du registre est associé un tel contrat. Chaque membre du groupe peut ajouter un bloc à un bloc existant (nouveau contrat, prolongation/réclamation). Chaque membre du groupe 103 peut créer un nouveau bloc lié à un nouvel objet.

Le groupe utilisateurs 104 comprend tous les utilisateurs d’un système cloud ou en nuage pour l’authentification et l'assurance d’objets authentiques 100. Chaque utilisateur a seulement accès aux informations publiques du grand livre d'objets Ledger 1, ainsi qu’à ses propres informations sur le registre des contrats (UID/IID/CID) Ledger 2.

Le groupe des experts byzantins 105 est une entité virtuelle qui comprend l’ensemble ou un sous-ensemble de membres du groupe des administrateurs 106 et un sous-ensemble du groupe des tierces parties 102. Ce groupe 105 gère le processus et participe à toute décision "byzantine" concernant l'ajout d'un nouvel objet ou la validation d'une réclamation. Ceci est vrai sauf pour les fabricants sous certaines conditions : Quand il n’y a pas de PUF associe au produit, on introduit les « 3rd party » (c’est-à-dire les tierces parties 102) et un processus byzantin…. Mais quand les fabricants ajoutent un produit avec PUF, il n’y a pas de vote, et le produit est ajouté automatiquement. Ceci est détaillé aux paragraphes (056) et (057).

Le groupe des administrateurs ou Administrators groupe 106, qui est également une entité virtuelle, comprend un sous-ensemble de Insurers group 103 et du Manufacturers group 101. Il peut également comprendre d’autres membres selon besoin. Ce groupe virtuel est un groupe qui a autorité pour :

• Ajouter un nouveau membre à n'importe quel groupe et délivre un MID (Member ID) qui est unique
• Définir/gérer toutes les clés publiques pour les données chiffrées
• Afficher les clés publiques pour chaque groupe (chaque groupe a une clé publique différente)
• Gérer la liste des personnes appartenant aux différents groupes et leur livre leurs clés privées.

La FIG. 2 montre une forme particulière réalisation de l’invention, dans laquelle est décrite l'infrastructure Multi-Distributed Ledger (MDL) 200 du système cloud pour l'authentification et l'assurance des objets authentiques où les produits, les étiquettes, les données, le lecteur de balises, les registres distribués, etc. sont connectés les uns aux autres sur un réseau de communication basé sur le cloud.

Le système d'authentification du produit est une plate-forme garantissant l'authenticité pour au moins accéder, contrôler, vérifier, gérer, interagir, diffuser, etc. avec des objets, des comptes d'utilisateur et des données associées aux objets et aux utilisateurs, y compris, mais pas nécessairement, les propriétaires et assureurs d'objets.

Avant de commencer l'identification des objets authentiques et de créer de nouveaux blocs dans les registres, le groupe des Administrateurs 106 doit définir et gérer les clés pour encrypter les données 201 sous forme chiffrée, faire l’affichage 202 des clés publiques pour chaque groupe, gérer comme en 203 le problème de l’appartenance de chacun des utilisateurs à chaque groupe. Ceci comprend notamment le groupe byzantin 204 donnant les autorisations.

Puis un membre du groupe des fabricants 101 insère une étiquette unique identifiable 211 dans l'objet physique 212, caractérisé en ce que cette étiquette comprend une fonction physique non-clonable (PUF) 213 pour se protéger contre la falsification et la subversion par substitution.

Dans cette opération, cette étiquette contient au moins une représentation signée numériquement de l'objet 214 (cette représentation est un bloc contenant un ensemble d’informations spécifique à l’objet) et/ou un pointeur 215 indiquant au moins un endroit où ladite représentation de l'objet signée numériquement peut être consultée; dans laquelle la représentation de l'objet peut être signée numériquement soit par le fabricant d'origine seul, soit par une multi-signature de plusieurs entités impliquées dans la chaîne d'approvisionnement (magasin, intermédiaire de marché généralement désigné par le terme market place ...); dans laquelle la signature numérique qui signe numériquement une valeur de hachage résultant de l'application d'une fonction de hachage cryptographique prédéterminée 216 à des données représentant une réponse générée par le PUF en réaction à un protocole d'authentification par réponse à un défi prédéterminé (CRP) ; dans laquelle le PUF comprend un code d'identification unique 217 (OID) attribué à chaque produit ; dans laquelle lesdites données représentent une réponse générée par le PUF en réaction au défi d’un schéma de défi-réponse prédéterminé pour ledit OID 217 ; et dans laquelle l'étiquette peut être authentifiée, même sans alimentation externe, par des appareils mobiles notamment des lecteurs, qui sont eux-mêmes capables de vérifier la signature et de lire l'historique transactionnel de l'objet dans au moins un grand livre distribué ou la chaîne de bloc 200.

Pour surmonter les inconvénients résultant des problèmes d'évolutivité et/ou pour prévenir les attaques de Sybil comme la possibilité de déni de service et d'attaques par rejeu, c.-à-d. attaque de rediffusion dans laquelle une transmission est malicieusement répétée par un attaquant qui a intercepté la transmission, le système peut ajouter au PUF un protocole pour parvenir à un consensus en présence de failles byzantines 218.

Cet OID 217 peut inclure tout ce qui permet de vérifier l'authenticité de l'objet tel que l'origine du produit, le nom du fabricant, le numéro de série du fabricant, le site de production, la date de production, le lien 215 dans le registre 223 des contrats vers le code d'identification du propriétaire crypté (UID) 219, et vers le contrat d'assurance crypté (IID) 220, vers les réclamations chiffrées (CID) 221, etc.

Cet OID 217 est intégré, incorporé, stocké ou enregistré dans le tag 211. Ce tag 211 peut être par exemple, mais sans limitation à cette notion, un tag NFC (Near Field Communication) nécessitant donc une lecture en champ proche entre l'objet et un appareil mobile.

Ce tag 211 peut également être un QR code, RFID, QR, code à barres, motifs ou symboles variés, etc.

Le tag 211 est précédemment attribué pour une chose et /ou une chose avec ses propres caractéristiques (par exemple, le modèle d'objet, les caractéristiques physiques, la caractéristique morphologique, ...), où l'OID de chaque objet authentique est enregistré et stocké dans un ou plusieurs produits particuliers du registre 222 dans un MDL situé dans au moins un réseau de communication (câblé, sans fil, accès à distance, etc.) et associé à un code d'identification crypté (UID) d'un propriétaire stocké dans un registre des propriétaires 219 de le grand livre multi-distribué 200.

Les champs sont encryptés avec la clé publique du groupe d’assureurs et avec la clé privée de l'assureur qui a passé le contrat. De cette manière, seul cet assureur précis peut déchiffrer le contrat en question.

Dans le cas où l'étiquette n'est pas intégrée dans l'objet, mais où le membre du groupe des fabricants 101 qui a fabriqué l'objet existe toujours et est prêt à intégrer une balise dans l'objet, l'objet est retourné au fabricant pour l'intégration de l'étiquette. L'objet est soumis à vérification et ainsi authentifié par le fabricant, puis une étiquette ou tag 211 (RFID / puce NFC) est intégrée par le fabricant dans l'objet, puis le processus suit les étapes du flux de processus décrivant l'étape de configuration d'authentification ici en dessous.

Dans le cas où un membre du groupe des fabricants 101 n'est pas en capacité ou ne veut pas intégrer une étiquette unique identifiable dans l'objet physique, un membre du groupe 102 peut garantir si oui ou non un objet est authentique sur la base des informations qu'il possède. Ainsi, à la demande d'un membre du groupe 102, un nouvel objet peut être ajouté au registre des objets par création d’un nouveau bloc selon référence 224. La création du nouveau bloc dans le registre des objets est ensuite soumise au groupe d'experts "byzantin" 105 qui utilisera un procédé byzantin 218 pour identifier l'objet comme authentique et pour qualifier comme valide le nouveau bloc.

On définit ci-après la notion d’étiquette alternative 211bis. A condition que l'objet soit identifié comme authentique et qualifié/validé pour la création d'un nouveau bloc, une étiquette peut encore être intégrée sous la responsabilité et à la demande d'un membre du groupe 102, comme, mais non limité à, une maison de vente aux enchères ou un expert bien connu, agissant en tant qu'autorité de certification à condition que le propriétaire actuel puisse fournir des preuves d'authenticité de l'objet à l'autorité de certification, y compris, mais pas nécessairement limité à, la propriété de l'objet prouvée par une facture avec la valeur et la date d'achat, une facture du titulaire précédent avec la valeur et la date d'achat, des images photographiques de l'objet, et éventuellement d’autres moyens de preuve que peut produire le fabricant d'origine, les forces de police, les douanes ou un expert, par exemple, afin que l'autorité de certification puisse exercer son rôle et générer au moins une preuve publique indépendante qui puisse servir de preuve. Cette demande détaille le type de vérifications qui ont été faites et peuvent être affichées publiquement à tout acheteur potentiel, sous forme numérique ou imprimée, et peut être utilisée pour réaliser une transaction. Si l'objet est authentifié par l'autorité de certification, une étiquette 211bis (RFID / puce NFC ou autre capteur ou traceur) est intégrée dans l'objet 212 sous la responsabilité de l'autorité de certification et puis le processus suit les étapes du flux de processus décrivant l'étape de configuration d'authentification.

Dans le cadre de l'assurance des objets authentiques, le système d'authenticité fournit une police d'assurance décentralisée et un mécanisme de réclamation pour les objets enregistrés. Chaque membre du groupe d’Assureurs 103 peut créer un contrat d'assurance 234 lié à un objet enregistré ou un groupe d'objets enregistrés avec un membre du groupe d'utilisateurs 104 et peut ajouter un bloc à un bloc existant, notamment un nouveau contrat 234, ou une extension de contrat, ou un sinistre générant une déclaration de sinistre 236, ou encore peut créer un nouveau bloc lié à un nouveau contrat. Il devra suivre les étapes suivantes :

Le membre du groupe Utilisateurs utilisera son nom et son code d'accès 241, géré par le groupe 106 des administrateurs, pour accéder à son UID dans le registre des utilisateurs 202. Si son nom et son code d'accès correspondent à un UID dans le registre des contrats ou ledger 2 (référencé 223 en figure 2), il/elle aura accès à son compte qui lui permettra d'obtenir la liste de ses produits authentiques enregistrés dans le grand livre de produits, ou ledger 1, référencé 222. A l’intérieur de sa liste de produits authentiques stockés dans le livre de produits 222, il / elle va cocher la boîte du produit qu'il / elle veut assurer. Il/elle transférera ensuite le produit OID qui inclut les données associées à chaque produit authentique à l'assureur, et demandera un devis.

Avant de recevoir les données et la demande de devis, l'assureur devra être inscrit au groupe des assureurs 103. En retour, l'assureur enverra un contrat intelligent ou smart-contract 234 à signer. Si l'utilisateur et l'assureur s'entendent sur les termes du contrat, celui-ci sera signé numériquement par les deux parties. Ensuite le système crée un nouveau bloc 237 dans le registre des contrats 223, enregistrant les conditions du contrat 235, le contrat d'assurance IID 220, le bénéficiaire des transactions d'assurance dans lesquelles le nom est déjà crypté dans le bloc immuable sous son UID 219. Ce bloc contient le contrat d'assurance intelligent et le lien 215 vers le grand livre d'objets 222 dans lequel un nouveau bloc 239 mettra à jour la blockchain existante. Dans les deux blocs, le nom est crypté, tout le reste est lisible. L'IID du smart-contract d'assurance 220 est intégré dans l'information d’objet authentique précédente du bloc 238, crypté dans un autre bloc "immuable" sous la forme d'une nouvelle information d’objet authentique du bloc 239 qui sera stocké dans le registre des produits 222 du livre multi-distribué MDL et connecté au registre des contrats 223 par le biais du lien 215 de l’OID du livre de contrats où sont enregistrés l'UID crypté 219 et l’IID 220.

En cas de déclaration de sinistre, désigné comme claim ou réclamation 236 dans la figure 2, le bénéficiaire fournit son nom et son code d'accès, géré par le groupe Administrateurs 106, pour accéder à son UID 219 / IID 220 dans le livre de contrat 223. Le système va alors décrypter le nom dans les blocs du registre des utilisateurs. Si le nom du bénéficiaire correspond au nom stocké dans le grand livre où l'IID du contrat d'assurance intelligente est intégré, il passe à l'étape suivante. À l'aide du lien 215 de l’OID, le système demande le bloc dans le grand livre des produits, il obtient le bloc 238 avec le code d'objet unique OID, décrypte le nom et si le nom correspond, démarre le processus de réclamations et un nouveau bloc lié à la réclamation (CID) 221 est enregistré dans le registre des transactions et ajouté à un nouvel OID.

Pour valider les nouvelles entrées de données qui sont ajoutées à la blockchain et ainsi former de nouvelles entrées dans le grand livre, le système de traitement des déclarations de sinistre ou claims, ou revendications est validé par le vote des experts byzantins 218 : objet identifié Y ou N, objet assuré Y ou N, réclamation valide (ou invalide) : Y ou N.

A la condition que toutes les réponses soient Y, un nouveau bloc au sujet de la réclamation est ajouté dans le registre des contrats. Si la réclamation d’assurance est valide, le processus amène l'assureur à générer un paiement (ou non) au bénéficiaire et un nouveau block 240 lié à la transaction le cas échéant est inscrit dans le registre du contrat 223. Seul le registre de l'utilisateur à un moment donné connaît le nom du bénéficiaire, mais le nom n'est jamais enregistré ; simplement utilisé comme une preuve que le code d'accès est correct.

La FIG. 3 montre un flux de processus de prise de décision pour identifier un objet authentique à travers un processus de votes dans un environnement byzantin et pour qualifier, en vue de validation, un nouveau bloc ou un bloc ajouté.

Un membre X d'un groupe G demande une décision du groupe 106 des administrateurs, groupe qui est également une entité virtuelle. Le groupe d’Administrateurs 106 diffuse la demande à tous les groupes, à savoir le Manufacturers Group 101, le groupe 102, le Groupe Assureurs 103 et le Groupe Utilisateurs 104.

Tous les membres utilisent la clé publique byzantine. Les membres désignés du groupe byzantin sont les seuls qui peuvent lire/décrypter le message à l'aide de leur clé privée byzantine. Les membres du groupe des experts byzantins décryptent le message et le système exécute une nouvelle famille de protocole de consensus métastable dérivée du protocole Avalanche pour prendre une décision binaire comme Oui ou Non. Ensuite, la décision est retransmise à tous les groupes / tous les membres en utilisant la clé publique du groupe G d'origine. Le membre du groupe G d’origine décrypte la décision et met à jour le ledger si nécessaire, ou engage toute autre action adéquate comme l'ajout d'un membre à un groupe, etc.… ou retire la demande.

La FIG. 4 affiche un flux de processus pour ajouter un nouveau bloc/nouvel objet au ledger "Objet".
Chaque fois qu'un membre du groupe Fabricant 101 souhaite créer un nouvel objet (c-à-d ajouter un nouveau bloc au grand livre d'objets) ou mettre à jour la blockchain existante liée à un objet préexistant, le membre devra utiliser le système pour diffuser la demande à tous les membres du Groupe des fabricants 101 en utilisant la clé publique du fabricant. Tous les membres du Groupe 101 des Fabricants, y compris magasins physiques ou Stores, sites d’e-commerce, place de marché, etc. vont recevoir la demande cryptée. Tous peuvent mettre à jour la blockchain existante. Les fabricants sont les seuls qui peuvent créer un nouveau bloc. Les membres utilisant la clé publique du fabricant mettent à jour le ledger selon les besoins, et quand le nouveau bloc est créé, la demande est retirée.

Cette opération est toujours sérialisée afin d'éviter une collision entre deux versions du grand livre distribué MDL.

On décrit dans la suite le cas où un membre du groupe Assureurs 103 souhaite créer un nouveau bloc.

Si l'objet à assurer est créé par un membre du groupe Fabricant 101, le processus sera le même que celui décrit pour un membre de ce groupe Fabricant qui souhaite créer un nouvel objet ou un nouveau bloc.

Si l'objet à assurer est créé par un membre d'un lieu d'enchères ou salle de ventes ou un autre membre du groupe 102, alors une nouvelle blockchain doit être créée. A cette fin, le système exécutera une nouvelle famille de protocole de consensus métastable dérivé du protocole Avalanche pour prendre une décision binaire comme Oui ou Non, ou comme en anglais (Y/N) dans la FIG 3.

Ensuite, la décision est de nouveau retransmise à tous les groupes / tous les membres utilisant la clé publique d’origine du groupe G. Le membre du groupe d’origine décrypte la décision et met à jour le ledger si nécessaire, ou fait toute autre action adéquate comme l'ajout d'un membre à un groupe, etc.… puis retire la demande.

La FIG. 5 affiche un flux de processus pour ajouter un nouveau bloc/nouvel objet physique au Ledger d’objets en utilisant la fonction PUF intégrée pour garantir l'authenticité de l’objet.

Un membre du groupe Fabricant 101 souhaite créer un nouveau bloc pour un nouvel objet.
Pendant le processus de fabrication, le nouvel objet a une étiquette intégrée qui fait partie d'une fonction physique non-clonable (PUF). L'étiquette est un circuit intégré inséré dans une carte ou un autocollant en plastique qui est attaché à l'objet à identifier, et qui peut être une puce RFID / NFC ou tout autre mécanisme approprié tel que, mais sans s'y limiter, un numéro de série. Ce Tag contient un vaste ensemble d'informations qui sont utilisées pour le protocole CRP déjà décrit précédemment et utilisé par le PUF mentionné ci-dessus. Par là il authentifie l'objet en permettant la confirmation de la signature par l’appariement du couple Défi/Réponse du CRP de la fonction physique non-clonable (PUF).

L'utilisation d'un lecteur Tag, d'un smartphone, d'un scanner ou de tout autre appareil permettant de lire les informations écrites dans l'étiquette et de communiquer avec le système permet de vérifier si un défi spécifique correspond à sa réponse correspondante.
Au moment d'envoyer l'objet à son premier utilisateur, le membre du groupe 101 va mettre à jour la balise existante avec des informations supplémentaires, comme par exemple ajouter le code QR à l'étiquette.

A cette fin, le système va réaliser l’appariement du couple Défi/Réponse du CRP de la fonction physique non-clonable PUF. Il devra créer un OID à partir du succès de l’appariement du défi/réponse du PUF, créer un code hachage, lire les informations contenues dans le Tag ou balise ou étiquette, comme les autres informations d’horodatage et de numéro de série, etc.., insérer l’OID créé dans un nouveau bloc temporaire avec copie de l'information lue dans l'étiquette dans le même nouveau bloc temporaire.

Ce nouveau bloc temporaire inclura l'index défini dans le graphique comme Next block Index, l'OID (tag/PUF/...), le bloc informations sur les objets authentiques (claires ou cryptées), le timestamp ou horodatage et le code de hachage actuel. Entre-temps, le membre du groupe Fabricant 101 demande à l'Administrateur 106 une clé de chiffrement symétrique si nécessaire, ajoutera une information supplémentaire dans le bloc, qui pourra être cryptée avec la clé symétrique si besoin, ajouter l'horodatage, verrouiller le bloc avec du code de hachage et copier le bloc temporaire dans le nouveau bloc avec d'autres informations claires / cryptées. Ensuite, le système met à jour le registre des objets – voir figure 2 - puis retirer la demande.

La FIG. 6 affiche un flux de processus pour ajouter un nouveau bloc/nouveau objet physique au Ledger 1 objets, en utilisant d'autres propriétés pour garantir l'authenticité

Un membre du groupe Fabricants 101 ou de tout groupe tiers souhaite créer un nouveau bloc pour un nouvel objet. Le nouvel objet physique ou virtuel a une description d'objet qui décrit l'objet et ses propriétés et un certificat d'authenticité comportant par exemple un numéro d’identification VIN (Vehicle Identification Number), son pendant européen EUID, numéro de série...

Le système envoie une demande au groupe d’Administrators 106 ou au groupe d'experts byzantins 105 (voir FIG 2) pour prendre une décision binaire comme Oui ou Non.

En supposant que la réponse est Oui, un code de hachage dit hh est demandé au groupe Administrateurs 106 pour créer un bloc temporaire, puis un unique OID.

(082) Ce nouveau bloc temporaire inclura le nouveau index next block, intitulé comme Next block index dans le graphique, l'OID (l'objet et ses propriétés et un certificat d’authenticité...), le bloc des informations sur les objets authentiques (cryptées ou non cryptées), l’horodatage et le code Hash actuel. Entre-temps, le membre du groupe des fabricants 101 ou du groupe 102, Other 3rd party group, demande au groupe des Administrators 106 une clé de chiffrement symétrique si nécessaire, ajoute des informations supplémentaires (qui peuvent être cryptées avec la clé symétrique) dans le bloc, ajoute l'horodatage, verrouille le bloc avec le code de hachage hh et copie le bloc temporaire dans le nouveau bloc, avec d'autres informations cryptées ou non cryptées. Ensuite, le système met à jour le registre des objets - voir FIG 2 - et retire la demande.

La FIG. 7 décrit la gestion des codes de hachage ou des clés de chiffrement. Cette gestion comprend un générateur de nombres aléatoires et de nombre premiers, qui sont utilisés pour le chiffrement et le hashing.
Le groupe Administrateurs 106 est un groupe virtuel qui a autorité pour fournir les services suivants :

• Fournir les Codes de hachage pour tout ID unique (OID, UID, IID, CID et MID) ;
• Servir la demande d'identification unique demandée soit par un propriétaire inscrit dans le ledger ; les autres demandeurs sont refusés.
• Fournir et afficher les clés publiques pour tous les groupes, délivrer les clés privées à tous les membres afin qu'ils puissent déchiffrer les données qui leur sont diffusées ;
• Fournir des clés symétriques aux membres de tout groupe qui veulent protéger leurs données.

La FIG. 8 montre un diagramme de flux d’un aspect particulier de l’invention décrivant comment utiliser le système objet de l’invention pour fournir une base de données publique et un moteur de recherche associé, donnant pour chaque produit sa valeur estimée. Cette valeur estimée est basée sur le dernier prix pratiqué ou le dernier prix offert, pour un produit de même marque, de la même année, dans un état équivalent, et enregistré dans le système d’authentification et d’assurance des objets authentiques selon l’invention.

Pour la description détaillée en relation avec les figures 9 à 16, on admettra que dans ce contexte :

1. Tous les vendeurs possèdent un coffre-fort électronique qui leur est propre. Au sein de ce coffre-fort seront listés tous les objets dont le vendeur a la propriété et qu’il souhaite vendre. Les produits listés seront soit publiés sur le site de vente, soit mis en attente.
2. Toutes les offres en ligne sont publiées dans un site marchand de commerce en ligne tel que, par exemple, Amazon ou similaire. Il est à noter que certains produits, normalement vendus uniquement en magasin, peuvent être également publiés sur ces sites en ligne. On désignera par W (comme wallet) ou éventuellement W1, le portefeuille des produits publiés, et par W2 le wallet ou portefeuille des produits en attente de publication.

Figure 9 avec titre « In store, first registry »:
Au moment où le consommateur achète un produit X en magasin, il installe l’application du système d’authentification sur son mobile, si ce n’est déjà fait. L’application initialise alors le coffre-fort électronique de l’utilisation. Il va ensuite scanner le produit et les informations relatives à son achat seront instantanément enregistrées dans l’application.

Dans l’éventualité où le consommateur ne veut pas immédiatement télécharger l’application, il aura toujours la possibilité de l’installer plus tard, via un lien dédié qui lui aura été donné au moment du paiement.

Une fois l’application téléchargée et le produit scanné, les informations relatives à son achat seront instantanément enregistrées dans l’application.

Figure 10, avec titre « In store, following registration at shop »:
Une fois l’application téléchargée, tous les achats ultérieurs pourront être scannés et ils seront immédiatement enregistrés dans l’application et associé à la liste de produits de son coffre-fort numérique.

Dans l’éventualité où le produit ne serait pas conforme à ce qui a été contracté (par exemple, un acompte pour livraison différée d’une commande spéciale), un rapport sera généré par l’application sur la base des informations contradictoires communiquées par l’acheteur. Ces informations seront renvoyées automatiquement au vendeur pour règlement du problème.

Figure 11, avec titre « Online purchase (Alethia exchange) » :
Lors d’achats en ligne, aussi appelés Online purchases, la carte de paiement de l’acheteur va être débitée au moment de la commande, mais les fonds nécessaires au paiement sont conservés dans un compte séquestre jusqu'à la validation par scan de la réception du produit par l'acheteur.

Une fois le produit scanné par l’acheteur le paiement du produit sera immédiatement réalisé ainsi que le transfert de propriété du produit authentique du coffre-fort électronique du vendeur à celui de l’acheteur au sein de l’application.

Si le produit a été reçu par l’acheteur, mais non scanné sous un certain délai, et si aucune réclamation n’est portée par l’acheteur, le compte de l’acheteur sera débité et la propriété du produit authentique sera simultanément transférée du coffre-fort électronique du vendeur à celui de l’acheteur au sein de l’application, et ce même si le produit n’est pas scanné.

Dans l’éventualité où le produit ne serait pas conforme, la procédure de claim sera engagée : voir la Figure 14, pour laquelle la description figure plus bas.

Figure 12, avec titre « Third beneficiary purchases »:

Lorsque l’acheteur n’achète pas le produit pour son propre compte mais pour un tiers bénéficiaire (cadeau par exemple), l’application permet de transmettre le certificat de propriété du vendeur dans un compte temporaire de l’application associé à la liste de produits du coffre-fort numérique de l’acheteur, afin que celui-ci puisse transmettre ultérieurement son droit de propriété sur ce produit à son destinataire final, au moment où ce dernier scannera le produit reçu avec l’autorisation de transfert gracieux de l’acheteur.

Ledit produit sera alors immédiatement enregistré dans la liste de produits du coffre-fort numérique du bénéficiaire.

Figure 13, avec titre « Offer creation » :

Lors du processus de création d’une offre, l’offre générée sur le site marchand va suivre les étapes suivantes :

1. L’offre est directement publiée dans l’application site de vente depuis la liste de produits du coffre-fort numérique W1.
2. Le vendeur a alors accès à des statistiques liées au produit pour l’aider à définir son prix de vente.
3. Si l’utilisateur est hésitant quant à publier son offre, il peut choisir d’en enregistrer le brouillon, désigné aussi comme draft dans le graphique, dans son coffre-fort numérique W2 défini plus haut.

Figure 14, avec titre « Claim management » :

Deux cas peuvent se produire dans le processus de gestion des réclamations :

• Cas numéro 1 : Le processus de réclamation entre acheteurs et vendeurs.
  Si l’acheteur n’est pas satisfait par l’objet reçu, il va suivre la procédure de retour du site marchand.
• Cas numéro 2 : Leprocessusde déclaration d’un sinistre assuré s’effectue comme suit.
  1. La déclaration de sinistres entre l’assuré et l’assureur est faite par l’acheteur.
     1. Une vérification est faite dans le ledger assurance pour vérifier si :
        • Le sinistre est-il couvert, ou non ?
        • Le contrat existe-t-il ?
        • Le contrat couvre, ou ne couvre, pas le sinistre ?
        • L’assuré est-il couvert pour le sinistre déclaré ?
     2. Une fois la vérification prédécrite réalisée, l’assuré doit apporter la preuve du sinistre. Cette preuve peut consister, à titre d’exemples non limitatifs, en des photos, vidéos, scans et autres compléments d’information.
     3. Les dommages sont ensuite enregistrés dans le ledger de l’assurance.
     4. Le système met automatiquement à jour le ledger de l’assurance avec une transmission automatique de l’information à l’assurance.
     5. L’assureur détermine ensuite l’indemnité, conformément aux termes et condition du contrat, telles que définies et enregistrées dans le smart contract du Ledger 2 fig. 2.

Dans le cas numéro 1, si la réclamation est reconnue comme valide par le système, l’acheteur pourra demander au vendeur, la reprise dudit objet, ou une réduction de prix, selon les termes et conditions d’utilisation du système.
Dans le cas contraire, alors la vente sera déclarée parfaite et le paiement a déjà été réalisé.

Dans le cas numéro 2, si la réclamation est reconnue comme valide par le système, l’acheteur pourra demander à l’assureur un dédommagement de son sinistre, selon les termes et conditions d’utilisation du système. Dans le cas contraire le claim sera rejeté.

Figure 15, avec titre « Statistics – 07-1».

La procédure décrite par le graphique de la figure 15 explique comment les stocks de produits authentiques peuvent être suivis dans le système.

Le produit authentifié par un membre du groupe des fabricants ou une autorité de certification, désignée par Authenticator dans le graphique, est enregistré dans le système. De plus, une valeur va lui être attribuée dans une base de données auxiliaire qui va recenser le nombre des produits et leur valeur.

Cette création d’un nouveau produit dans le système va incrémenter un compteur d’un nouvel élément avec l’ensemble de ses caractéristiques.

Si au cours du cycle de vie du produit les informations relatives au produit ou à son authenticité venaient à changer, ou encore si son statut, tel qu’enregistré dans l’OID du produit, venait également à changer, alors ledit produit serait considéré comme n’étant pas authentique et le compteur sera incrémenté d’un 0. L’insertion de ce 0 va exclure le produit du système et ainsi réduire le nombre d’objets authentiques en stocks.

Le système fournit des capacités de recherche et de tri permettant au propriétaire utilisateur, à l'acheteur potentiel, à l'assureur, etc. d'obtenir des informations transparentes pour les utilisateurs du système.

Ces informations concernent le marché des objets authentiques enregistrés dans le système selon l’invention.

Elles comprennent une description publique d'un objet ainsi que le prix observé sur des transactions, qui ont été validées sur des produits enregistrés authentiques, permettant ainsi au système de publier une évaluation du prix de chaque objet enregistré authentique, en particulier dans une fourchette de prix min-max.

En outre, le système peut fournir une base de données publique pour les prix offerts et demandés pour les produits authentiques enregistrés.

À cette fin, le système prend les valeurs mises à jour (1) dans le grand livre des produits, tel que précédemment décrites, ainsi que valeurs des offres utilisateurs, afin d'envoyer ces données dans une base de données dite Product Value Database, pour un produit spécifique (2) – voir Ledger 1 aussi sur la figure 2.

C’est de ce Ledger 1 qu’est extraite la valeur des produits qui va mettre à jour la base de données des produits. Cette Product Value Database va ensuite servir à alimenter l’App Index défini comme suit.

L’App Index est un ensemble d’indices de prix qui va recenser pour chaque produit/modèle sa valeur telle que renseignée dans le Product Value Database. Cette information d’indice de prix sera ensuite disponible, sur simple requête, pour les utilisateurs du système, les assureurs, les vendeurs potentiels et toute autre partie intéressée telle que, en particulier, les groupes 101, 102.

Ces indices des prix App Index peuvent être transmis publiquement ou diffusé aux consommateurs, aux assureurs et aux vendeurs pour qu'ils puissent en tenir compte dans leurs propositions de valeur et de leurs options d'achat.

Les trois paragraphes qui suivent détaillent des avantages de l’application aux assurances de l’invention.

Le système selon l’invention, comprenant le suivi d’éléments authentifiés, peut être un puissant et réel outil qui va rendre plus fluides, plus efficaces et plus sûrs les échanges entre les compagnies d’assurances et les assurés.

1. Le client crée son espace personnel dans le système selon l’invention, soit via une application (solution qui est normalement préconisée) soit sur le site internet Alethia selon l’invention.
2. Il souscrit son contrat d’assurance auprès d’une compagnie qui adhère à la plateforme.
3. La création du contrat et son enregistrement par la compagnie génère le premier maillon de la chaîne.
4. Le client reçoit sur son espace personnel les informations liées à son contrat ; en acceptant cette opération il scelle la relation.
5. Quand un client souhaite faire une modification simple sur son contrat, il lui suffit de la saisir dans son espace personnel et elle est automatiquement transmise à son assureur. Celui-ci enregistre la demande du client, la valide et renvoie le résultat, un « dont acte » ou l’avenant correspondant à la modification.
6. En cas de volonté de changement d’assureur le client génère à un instant T un QR code, un fichier infalsifiable, ou tout autre mécanisme qui permette d’établir l’authenticité et l’unicité d’un objet, ce qui fige la situation du client. Cette image contiendra toutes les informations essentielles et nécessaires au futur assureur, qui pourra apprécier le risque en toute sécurité ; ainsi la fausse déclaration devient quasi impossible.
7. Le nouvel assureur envoie le contrat au client et une attestation de prise de garantie au précédent assureur pour satisfaire aux obligations de continuité de couverture du risque.
8. Seul le transfert de propriété ou la destruction du bien entraîne la fin de la chaîne.

On peut par ailleurs écrire un algorithme qui calcule la sinistralité des produits assurés par type de produits, zone d’acquisition ou de détention, groupe auquel appartient l’assuré, ou similaire.
Et, par exemple en matière d’assurance automobile, il est possible de calculer la moyenne du bonus en cas de possession de plusieurs véhicules. De la même façon on peut facilement reconstituer le bonus d’un client qui change fréquemment d’assureur.
Un tel système peut constituer un véritable outil statistique à long terme pour le comportement des assurés, et ce par groupes homogènes d’assurés ; l’agrégation en groupes permettant de préserver l’anonymat de chaque assuré.

Les dix-neuf paragraphes qui suivent décrivent plus spécifiquement des caractéristiques en matière d’indemnisation de sinistres. Ces caractéristiques présupposent que le client aura utilisé le système selon l’invention, ou système Alethia, dans tous les cas.

le système selon l’invention peut procurer un avantage unique, en tant que seul au monde à proposer une véritable et avantageuse solution d’assurance pour les victimes de contrefaçon, qu’elles soient professionnelles ou privées.

Cela est rendu possible en intégrant la transaction dans une blockchain et en proposant un outil de suivi de la distribution.

L’objectif est de couvrir les utilisateurs du système selon l’invention contre la perte financière entraînée par l’acquisition de bonne foi d’un produit contrefait. Il appartiendra cependant à l’acquéreur de prouver qu’il a acheté un faux lors de l’utilisation de bonne foi de ce système.

La solution technique et assurantielle permet de créer un lien de confiance entre le vendeur et l’acquéreur en garantissant financièrement l’authenticité du bien.

Cette couverture assurancielle étant rattachée au bien, elle couvre celui-ci toute sa vie. Des critères de vétusté devront cependant être mis en place pour évaluer correctement la valeur du bien.

il est également proposé aux utilisateurs une assurance optionnelle contre la perte du bien suite à un vol ou une destruction.

Une compagnie d’assurance utilisant la solution selon l’invention développera son image au niveau mondial en étant associée à chaque transaction utilisant ce système.

En matière de Big Data, cette innovation permettra à l’assureur ou aux assureurs d’obtenir une masse de données agrégées par groupes homogènes de produits assurés, par type de produits, par zone d’acquisition/détention, par groupe auquel appartiennent les assurés, ainsi que sur les profils des consommateurs tout en respectant scrupuleusement la protection de la vie privée, notamment par anonymisation.

Ces informations, traitées efficacement notamment à l’aide de technologie de Machine Learning, permettront d’améliorer efficacement le calcul des primes et donc la rentabilité des contrats d’assurances.

L’outil proposé permettra également des réductions de coûts dans le traitement des sinistres, par exemple en supprimant, ou réduisant fortement, l’intervention de l’expert qui était jusqu’alors chargé de l’évaluation des biens.

Caractéristiques de la Garantie Contrefaçon selon l’invention.

1. Aux professionnels :
   1. Le professionnel sera couvert en cas de détection de produits contrefaits dans son stock.
   2. S’il prouve qu’il a parfaitement respecté la procédure d’acquisition par l’outil proposé, il aura la possibilité d’être dédommagé selon les termes et conditions du système, comme à titre d’exemple :
      1. De se faire rembourser le prix d’achat des articles contrefaits. Ce prix devra correspondre au prix normalement pratiqué dans ces conditions (intermédiaires officiels ou non) et à l’échelon auquel se trouve l’intermédiaire professionnel dans le circuit de distribution (grossiste, demi-grossiste, détaillant…).
      2. De faire remplacer les produits contrefaits par des produits authentiques, à conditions que les critères ci-dessus soient respectés.
2. Aux consommateurs :
   1. Le client final pourra, dans les mêmes conditions que le professionnel, être dédommagé selon les termes et conditions du système, comme à titre d’exemple :
      1. Se faire rembourser le prix d’achat du produit contrefait. La condition est que le prix d’acquisition payé par le client corresponde aux prix normalement pratiqués, compte également tenu de son état au moment de l’acquisition (neuf ou occasion).
      2. Se faire remplacer le produit contrefait par un produit authentique si le produit acheté était vendu pour neuf au moment de l’acquisition.

Le coût de cette garantie pourra être inclus dans le prix du bien payé par les clients qui utiliseront le système selon l’invention, et rajouté à chaque étape de la chaîne de distribution.

On traitera ci-après des caractéristiques des Garanties Dommages proposées par le système selon l’invention :

1. Aux professionnels
   1. Il y a lieu de mettre optionnellement en place une couverture sur le stock possédé par l’intermédiaire. La solution permettrait de connaître sa valeur en temps réel et donc d’ajuster la prime. Les garanties proposées sont notamment la Garantie Incendie, Dégâts des eaux, et Vol.
2. Aux consommateurs
   1. Plusieurs garanties peuvent être mises en place, notamment : a) Garantie en cas de destruction totale par incendie, attentats ou inondation de l'habitation ou du lieu de résidence ; b) Garantie en cas de disparition par vol avec violence ou effraction ; c) Garantie en cas de détérioration accidentelle.
   2. Dans chacun des cas qui peuvent donner lieu à garantie notamment en cas de destruction totale ou de disparition, le consommateur devra apporter la preuve du sinistre. Ces preuves peuvent comprendre, sans limitation : rapport d'intervention des pompiers, procès-verbal de police, photos authentiques. Dans le domaine des photos authentiques, un aspect de l’invention concerne la prise de photos non modifiables, avec indication de lieu et de temps.

Dans une forme particulière de réalisation de l’invention, il existe notamment la possibilité d'un remboursement soit au client directement, soit à la marque.

• Remboursement au client :

Dans ce cas le client est indemnisé en valeur déclarée et une vétusté est calculée au moment du sinistre ; un barème devra être établi par un expert. Le système selon l’invention, une fois suffisamment pourvu en data, pourra établir des cotes moyennes.

• Remboursement à la marque :

Dans ce cas Alethia indemnisera directement le détenteur des droits de marque (ci-après : la marque). La marque aura la charge de proposer à son client le même produit ou un article de valeur équivalente. La marque devra accepter dans ce cas d'être indemnisée non pas sur la base du prix de vente mais sur la base du coût de revient.
Cette solution aura bien évidemment la préférence de l'assureur car cela lui permettra de réduire le coût du sinistre (remboursement hors taxe, et hors marge du vendeur). Cette solution devrait aussi contenter le client qui aura dans ce cas un remboursement plus important. Elle aura pour la marque l'avantage de conserver le client, qui avec une indemnisation financière aurait pu changer de marque, et de lui proposer une vente additionnelle.
Pour ce qui concerne la garantie en cas de détérioration, en cas de détérioration accidentelle partielle le client aura la possibilité de voir son bien réparé, si le coût de la réparation est inférieur à sa valeur à dire d'expert. La marque établira un devis et sera indemnisée sur la base du coût de réparation.
En cas de détérioration réputée totale, une impossibilité de réparer complètement le bien ne permettra pas une indemnisation au titre des biens détruits.
En ce qui concerne le coût de l’assurance, en visant l'indemnisation des clients dans les meilleures conditions, compte tenu du caractère haut de gamme de la solution proposée, le coût pourrait se situer entre 3% et 4% de la valeur du bien à couvrir.
Une tarification par tranche de valeur peut être envisagée.

Les paragraphes suivants décrivent à titre d’exemple les étapes de souscription proposées dans la solution d’assurance selon l’invention, ainsi que les étapes d’une déclaration de sinistre.

Avant toute souscription, intervient l’acte d’achat, en boutique ou sur internet, et la création du compte personnel de l’utilisateur.

Une fois l’achat effectué, l’étape suivante consiste à rattacher l’article acheté, en cas de souscription, au compte du nouveau propriétaire, et à intégrer l’article à la plateforme.

Dans le cas d’une vente en boutique, le vendeur de ladite boutique, qui ne doit préférentiellement pas être un vendeur spécialisé dans la vente d’assurance, peut suggérer l’ouverture du compte sur un ordinateur personnel ou assimilé, ou mieux encore le téléchargement de l’application pour permettre l’enregistrement de l’article.

Le vendeur en boutique sera dans une position privilégiée pour expliquer le fonctionnement général de l’application, avec ouverture du compte et enregistrement de l’article, et ses fonctionnalités, notamment la garantie d’authenticité, la possibilité de revendre l’article ou de trouver un article authentique à acheter, la disponibilité de divers réseaux sociaux, et enfin la possibilité d’assurance de l’article, détaillée ci-après dans une forme de réalisation préférée.

Le client, ayant acheté son bien, créé son compte et enregistré son article, peut alors l’assurer à l’aide des neuf étapes suivantes.

1. Il sélectionne son bien.
2. Il clique sur la fonction Assurer Mon Bien. Ceci détaille la garantie proposée par l’ouverture d’une fenêtre d’explication ou Pop-up.
3. Une fenêtre s’ouvre et détaille le coût de l’assurance, le montant et l’objet de la garantie.
4. Il clique sur le bouton Souscrire l’assurance.
5. Une fenêtre s’ouvre et détaille les conditions générales du contrat, que le client accepte par clic.
6. A l’arrivée sur la partie paiement de la garantie, il est indiqué préférentiellement que le paiement se fait pour l’année. On remarquera que certains téléphones ne nécessitent pas d’entrer les renseignements de la carte ; sur certains modèles comme l’iPhone X, un simple double-clic déclenche le paiement ce qui accélère le processus.
7. Le contrat est alors souscrit.
8. Un message automatique sera préférentiellement généré chaque année à la date anniversaire, proposant un renouvellement selon une forme préférée, par exemple sauf action contraire, ou acceptant une résiliation.
9. Il reçoit un exemplaire de son contrat sur son espace personnel.

En cas de sinistre, les étapes de la déclaration de sinistre sont détaillées ci-après, toujours sous une forme préférée de réalisation de l’invention, et à la première personne étant donné que le client a choisi la fonction Assurer Mon Bien. Ces étapes se font concrètement dans l’application ou sur l’espace personnel sur l’ordinateur personnel ou assimilé.

1. Je déclare le sinistre avec un clic, sur « J’ai un sinistre », dans l’espace Gestion des Sinistres.
2. Si j’ai tous les éléments requis pour faire ma déclaration de sinistre, comme listé précédemment : PV de police, photos, rapport des pompiers etc, je les scanne via l’application et j’envoie mon dossier.
3. Si au contraire je n’ai pas encore tous les éléments requis, le simple fait d’avoir cliqué sur « J’ai un sinistre » génère un numéro de sinistre et ouvre un dossier qui permettra l’envoi ultérieur des éléments manquants.
4. Je reçois dans les deux cas un accusé de réception de ma déclaration de sinistre. Je peux répondre à d’éventuelles questions de l’assureur.
5. Si le sinistre donne lieu à indemnité, un message m’informe du virement sur mon compte.

Claims (2)

1. Méthode et un système d'authentification rentable, économe en temps de traitement, efficace, sécurisé et respectueux de la vie privée d'un produit/objet détenu par son propriétaire/titulaire dans un cadre particulier qui est celui de l'assurance d’un produit/objet authentique, l'intégrité du système et l'absence de conflit d'intérêts et de manipulations étant garantie au travers d’un processus d'administration dans un livre distribué sans chef, en combinant :
   La création de blocs non mutables dans un grand livre distribué ou blockchain qui deviendra le tiers de confiance qui peut être décrit comme un protocole décentralisé pour les transactions d'enregistrement entre les parties, qui capture et stocke de manière transparente toute modifications apportées à sa base de données distribuées et les enregistre,
   la création d'une étiquette particulière spécifique non-clonable avec un code d'identification unique qui identifie le produit/objet (OID) mais aussi d'une étiquette particulière avec un autre code d'identification unique qui représente le contrat d'assurance (IID),
   l'assurance qui est spécifique à l'objet mais aussi à la personne physique, avec un code d'identification unique (UID) qui est le bénéficiaire du contrat d'assurance,
   le suivi des informations publiques contenues dans les blocs non mutables pré-décrits ainsi que celles, privées, relatives au bénéficiaire de la police d'assurance,
   la mise à jour de l'information avec son évolution dans le temps,
   un groupe spécifique de caractéristiques de sécurité, notamment connues sous le nom de fonctions physiques non clonables PUF.
   un système de registre multi-distribué qui signifie littéralement que le grand livre stockant les données relatives au bénéficiaire de la transaction est intégré dans le registre dans lequel sont stockés tous les enregistrements des transactions, mais analysés indépendamment ce qui permet d’être en conformité avec l'article 17 du GDPR de l'UE sur le Droit à l'oubli,
   et enfin un système pour fournir une base de données publique et un moteur de recherche donnant pour chaque produit, en fonction de ses propres caractéristiques, sa valeur estimée par rapport à un indice de produit, cet indice étant généré en utilisant les valeurs des produits enregistrés dans le système, pouvant être publié ou relayé aux consommateurs, aux assureurs et aux vendeurs pour qu'ils puissent en tenir compte dans leur proposition de valeur de vente.
2. Système selon revendication 1, caractérisé par une gestion des conflits en présence d'un comportement byzantin.