INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Dans le mode de réalisation décrit ici, le dispositif client 2, les serveurs DNS 3 et les nœuds relais 4 ont l’architecture matérielle d’un ordinateur 8 telle que représentée schématiquement dans la . Cette architecture matérielle s’appuie sur un processeur PROC, une mémoire vive MEM, une mémoire morte ROM, une mémoire non volatile NVM, et des moyens COM de communication permettant à chacun des dispositifs précités de communiquer notamment avec les autres dispositifs du système 1. Ces moyens COM de communication peuvent notamment s’appuyer sur une interface de communication filaire ou sans fil, connue en soi et non décrite en détail ici, et/ou sur une ou plusieurs interfaces logicielles telles qu’une interface de programmation applicative (ou API pour « Application Programming Interface » en anglais) ou une interface de communication point-à-point, etc., et mettre en œuvre un ou plusieurs schémas de chiffrement comme évoqué précédemment.
La mémoire non volatile NVM (ou en variante la mémoire morte ROM) de l’ordinateur 8 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC, et sur lequel est enregistré un programme d’ordinateur conforme à l’invention.
Dans le cas d’un serveur DNS 3 conforme à l’invention, ce programme d’ordinateur est référencé par PROG3 et comporte des instructions définissant les principales étapes d’un procédé de traitement d’une (première) requête de résolution de nom selon l’invention. Dans le cas du dispositif client 2 conforme à l’invention, ce programme d’ordinateur est référencé par PROG2 et comporte des instructions définissant les principales étapes d’un procédé de communication selon l’invention. Enfin, dans le cas d’un nœud relais 4 conforme à l’invention, ce programme d’ordinateur est référencé par PROG4 et comporte des instructions définissant les principales étapes d’un procédé de traitement de messages selon l’invention.
Le programme d’ordinateur PROG3 définit les modules fonctionnels d’un serveur DNS 3 conforme à l’invention, qui s’appuient ou commandent les éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 8. Dans le mode de réalisation décrit ici, ces modules fonctionnels comprennent notamment comme illustré par la : un module 3A de réception, configuré pour recevoir des requêtes REQ-DNS de résolution de noms (requêtes DNS dans l’exemple envisagé ici) envoyées par des dispositifs clients, et notamment par le dispositif client 2 ; un module 3B traitement, configuré pour traiter (autrement dit résoudre) les requêtes REQ-DNS reçues par le module 3A de réception et élaborer des réponses REP-DNS à ces requêtes ; un module 3C de fourniture, configuré pour fournir à chaque dispositif client ayant sollicité le serveur DNS 3, supportant (et incidemment sollicitant) la mise en œuvre du mécanisme AD ASTRA, une pluralité d’éléments AD ASTRA-ELTS en plus des informations classiquement fournies en réponse à une requête REQ-DNS, comme détaillé davantage ultérieurement. Dans le mode de réalisation décrit ici, la pluralité d’éléments AD ASTRA-ELTS est fournie à un dispositif client ayant adressé une requête REQ-DNS au serveur DNS 3 dans la réponse REP-DNS à cette requête, par exemple dans une option EDNS (pour « Extension Mechanisms for DNS » en anglais) comme expliqué plus en détail ultérieurement. Ces hypothèses ne sont toutefois pas limitatives et on peut envisager que la pluralité d’éléments AD ASTRA-ELTS soit fournie au dispositif client à l’aide d’un ou plusieurs messages distincts de la réponse REP-DNS ; et un module 3D d’envoi, configuré pour envoyer aux dispositifs clients ayant sollicité le serveur DNS 3, les réponses REP-DNS élaborées par le module 3B de traitement ainsi que la pluralité d’éléments AD ASTRA-ELTS fournie par le module 3C de fourniture.
Le module 3B de traitement procède, pour résoudre une requête REQ-DNS reçue d’un dispositif client, de façon conventionnelle en établissant, à partir d’enregistrements RR dont dispose le serveur DNS 3 ou auxquels il peut accéder (via un ou plusieurs autres serveurs DNS organisés de façon hiérarchique), une correspondance entre le nom sur lequel porte la requête REQ-DNS (par exemple, le nom de domaine « service-s.com » permettant d’accéder au service S) et une ressource IP (par exemple une adresse IP) d’un serveur associé à ce nom (le serveur 5 dans l’exemple du nom de domaine « service-s.com »).
Dans l’exemple envisagé ici, par souci de simplification, on se limite à des enregistrements RR de type A (établissant une correspondance entre un nom et une adresse IPv4 d’un serveur associé à ce nom) et des enregistrements RR de type AAAA (établissant une correspondance entre un nom et une adresse IPv6 d’un serveur associé à ce nom), un serveur associé à un nom pouvant être identifié par une adresse IPv4 et/ou une adresse IPv6 (et donc correspondre à un enregistrement de type A et/ou à un enregistrement de type AAAA). Il convient de noter que l’invention ne se limite toutefois pas à ces deux types d’enregistrements et s’applique également à d’autres types d’enregistrements RR comme des enregistrements RR de type SVCB (pour « Service Binding » en anglais), SRV (pour « Service resource record » en anglais), CNAME, etc., qui peuvent associer à des noms d’autres ressources qu’une adresse IP, comme par exemple un alias, un autre nom, une URI, etc.
La réponse REP-DNS à la requête REQ-DNS élaborée par le module 3B de traitement comprend ainsi au moins une information contenue dans un enregistrement RR relatif à un serveur (désigné ici par « serveur destinataire ») associé au nom sur lequel porte la requête REQ-DNS, et résultant de la résolution de la requête REQ-DNS par le module 3B de traitement. Dans l’exemple envisagé ici d’enregistrements RR de types A et AAAA, cette information comprend au moins une adresse IP (IPv4 et/ou IPv6) du serveur destinataire.
D'un point de vue technique, un NFT correspond à un enregistrement, sur une chaine de blocs, d'un code d’authentification associé à des conditions de transmission du code d’authentification. Ces conditions de transmission sont appelées « smart contrat » dans la littérature anglo-saxonne et sont implémentées selon une norme prédéfinie, par exemple la norme ESDT pour la cryptomonnaie Elrond ou encore la norme ERC-721 pour la cryptomonnaie Ethereum.
Pour vendre classiquement une œuvre numérique, un artiste doit posséder un portefeuille numérique, appelé « wallet » dans la littérature anglo-saxonne, et déposer son œuvre numérique sur son portefeuille numérique. Pour ce faire, des plateformes de vente de NFTs proposent de collecter des informations sur : - l’œuvre numérique ; - les droits associés à la possession de l’œuvre numérique ; - le portefeuille numérique de l’artiste ; - le code d’authentification de l’œuvre numérique ; et - les conditions de transmission.
Ainsi, les acheteurs potentiels peuvent consulter ces plateformes de vente de NFTs et visualiser des représentations des différentes œuvres numériques proposées par de multiples artistes. Pour chaque œuvre numérique, les acheteurs peuvent consulter les droits associés à la possession de l’œuvre numérique.
Par exemple, l'artiste peut autoriser le propriétaire du NFT à utiliser l'œuvre numérique associée au NFT pour réaliser une reproduction ou encore des actions publicitaires.
Lorsqu’un acheteur a détecté une œuvre numérique avec des conditions intéressantes en termes de droits et de prix, il peut remplir les conditions de transmission, typiquement le payement d’un prix fixe ou d’un prix déterminé par une méthode d’enchère, afin d’obtenir une transmission du code d’authentification depuis le portefeuille numérique de l’artiste vers le portefeuille numérique de l’acheteur.
Une chaine de blocs est très fiable pour assurer l’authenticité de la transmission du code d’authentification si bien que le détenteur du portefeuille numérique d’un code d’authentification associé à une œuvre numérique particulière peut se prévaloir des droits associés à l’œuvre numérique. En outre, en garantissant la transmission du code d’authentification entre uniquement deux portefeuilles numériques, il est également possible de garantir l’unicité d’un NFT.
Cependant, même s’il est très facile à l'aide d’une chaine de blocs de contrôler l'unicité d’un NFT, il est particulièrement délicat de contrôler que seul le propriétaire du NFT ne réalise une représentation physique de l’œuvre numérique associée à son NFT. Par ailleurs, de nombreuses personnes peuvent consulter les plateformes de vente de NFTs pour extraire des images et tenter d'obtenir des représentations physiques des œuvres numériques associées à des NFTs qu'elles ne possèdent pas.
Il s'ensuit qu'il existe certainement un grand nombre de copies illicites d'œuvres numériques enregistrées sous la forme de NFTs et qu'il est difficile de garantir l'authenticité d'une œuvre physique associée à une œuvre numérique enregistrée sous la forme d’un NFT.
En ce qui concerne les œuvres physiques, telles que les tableaux, il est également connu d'utiliser les NFT pour former un certificat d'authenticité de l'œuvre en appliquant sur le tableau un code crypté et en déposant un code crypté dans un NFT associé à l'œuvre. La personne qui veut se prévaloir de l'authenticité de l'œuvre physique peut alors démontrer qu’elle possède le portefeuille numérique du NFT et la corrélation entre le code crypté présent sur son œuvre physique et le code crypté présent dans son NFT.
Pour ce faire, des plateformes d’authentification sont utilisées pour vérifier ces éléments. Plus précisément, chaque plateforme d’authentification intègre un algorithme spécifique permettant de démontrer la corrélation entre le code crypté présent sur son œuvre physique et le code crypté présent dans son NFT.
Cependant, si un pirate informatique arrive à retrouver l’algorithme de corrélation d’une plateforme d’authentification, il pourrait réaliser une copie illicite d’une œuvre physique.
Pour ce faire, le pirate informatique pourrait simplement appliquer un code sur une contrefaçon d’une œuvre physique, déposer un code dans une chaine de blocs et dans un portefeuille numérique qu’il possède, de sorte à tromper un acheteur sur l’authenticité de la contrefaçon.
Le problème technique de l’invention est donc d’améliorer l’authentification un produit physique à l’aide de jetons non fongibles.
Pour répondre à ce problème technique, l'invention propose d'associer deux NFTs à chaque produit physique : un NFT pictural et un NFT de certification. Sur le produit physique, au moins un premier code d’authentification crypté est appliqué. Ce premier code d’authentification crypté du produit physique est associé à un premier code d’authentification crypté intégré dans le NFT de certification. Le NFT pictural intègre un second code d’authentification associé à un processus de vérification mis en place sur une plateforme d’authentification.
Ainsi, même si un pirate informatique venait à obtenir l’algorithme de corrélation entre le premier code appliqué sur le produit physique et le premier code du NFT de certification, il devrait également déjouer l’authentification du second code réalisé par la plateforme d’authentification. En outre, il serait plus complexe pour un pirate informatique de démontrer qu’il possède effectivement les deux NFTs permettant l’authentification : le NFT pictural et le NFT de certification.
L’invention concerne donc un système d'authentification d'un produit physique, sur lequel au moins un premier code d’authentification crypté est appliqué, le système d'authentification comportant : - une base de données associant à chaque produit physique au moins un jeton non fongible pictural, le jeton non fongible pictural intégrant une œuvre d’art numérique et un second code d’authentification crypté ; et - une plateforme d’authentification sur laquelle un utilisateur peut se connecter pour démontrer l’authenticité d’un produit physique au moyen dudit jeton non fongible pictural et d’un jeton non fongible de certification, le jeton non fongible de certification intégrant le premier code d’authentification crypté ; la preuve de l’authenticité d’un produit physique étant apportée par ladite plateforme d’authentification en vérifiant : que l’utilisateur possède au moins un portefeuille numérique sur lequel le jeton non fongible pictural et le jeton non fongible de certification sont stockés ; que le premier code crypté appliqué sur le produit physique correspond au premier code crypté intégré au jeton non fongible de certification ; et que le second code du jeton non fongible pictural est associé dans la base de données avec le produit physique.
Si la requête REQ-DNS ne contient pas l’option EAO (réponse « non » à l’étape test F20), le serveur DNS 3-1 traite (c’est-à-dire résout) par l’intermédiaire de son module de traitement 3B la requête REQ-DNS de façon conventionnelle et connue de l’homme du métier, à partir des enregistrements RR dont il dispose ou en interrogeant un ou plusieurs autres serveurs DNS comme évoqué précédemment (étape F30), puis envoie sa réponse REP-DNS-0 au dispositif client 2 (étape F40). Cette réponse REP-DNS-0 comprend ici l’adresse IP notée @IP5 du serveur 5 associé au nom de domaine « service-s.com ».
Si la requête REQ-DNS contient l’option EAO (réponse « oui » à l’étape test F20), comme c’est le cas dans l’exemple envisagé ici, le serveur DNS 3-1 traite (résout) via son module de traitement 3B la requête REQ-DNS de façon conventionnelle et connue de l’homme du métier, à partir des enregistrements RR dont il dispose ou en interrogeant un ou plusieurs autres serveurs DNS (étape F50). Ce traitement est identique à celui réalisé lors de l’étape F30.
Le module 3B de traitement du serveur DNS 3-1 obtient en résolvant la requête REQ-DNS, l’enregistrement RR du serveur 5 (serveur destinataire au sens de l’invention) associé au nom de domaine « service-s.com » et plus particulièrement son adresse IP @IP5 qui est contenue dans cet enregistrement RR (information relative au serveur destinataire résultant de la résolution de la requête REQ-DNS au sens de l’invention). Il inclut l’adresse @IP5 dans la réponse REP-DNS à la requête REQ-DNS.
Par ailleurs, conformément à l’invention, le serveur DNS 3-1, supportant le mécanisme AD ASTRA, sélectionne via son module 3C de fourniture au moins un nœud relais 4 pour le serveur destinataire 5 (étape F60). Dans l’exemple envisagé ici, il sélectionne le nœud relais 4-1. Le nœud relais 4-1 ainsi sélectionné est destiné à être utilisé par le dispositif client 2 pour lui adresser les messages qu’il souhaite envoyer au serveur destinataire 5, dans le cadre de son accès au service S (au lieu de les envoyer directement au serveur destinataire 5). Le nœud relais 4-1 est chargé ensuite de relayer ces messages vers le serveur destinataire 5, directement ou par l’intermédiaire d’un autre nœud relais 4 lorsque des nœuds relais sont déployés en cascade.
Il convient de noter que si la requête REQ-DNS est adressée par le dispositif client 2 à un serveur DNS de confiance ne supportant pas le mécanisme AD ASTRA et en particulier l’option EAO (par exemple lorsque la liste L-DNS comprend à la fois des serveurs DNS de confiance supportant le mécanisme AD ASTRA et des serveurs DNS de confiance ne le supportant pas), alors celui-ci répond au dispositif client 2 en lui envoyant un message d’erreur. Sur réception du message d’erreur, le dispositif client 2 peut solliciter un autre serveur DNS, renvoyer la requête au même serveur mais sans l’option EAO, mettre fin à la communication et générer une notification locale (application, utilisateur, etc.) indiquant l’échec de la tentative de résolution, etc.
Pour sélectionner un nœud relais 4 pour un serveur destinataire 5 et un dispositif client 2, le module 3C de fourniture du serveur DNS 3-1 peut tenir compte d’un ou de plusieurs critères de sélection. Notamment, le module 3C de fourniture peut sélectionner un nœud relais 4 vérifiant une ou plusieurs conditions parmi les conditions suivantes : empêcher l’établissement d’une corrélation entre le nœud relais 4 sélectionné et le serveur destinataire. Typiquement, le module 3C de fourniture doit éviter qu’un nœud relais 4 ne soit sélectionné que pour un unique serveur destinataire, ou pour des communications distinctes entre le dispositif client 2 et le serveur destinataire, il peut sélectionner des nœuds relais 4 différents ; maximiser le nombre de dispositifs clients utilisant un nœud relais 4 sélectionné ; optimiser les dispositifs clients utilisant un nœud relais 4 sélectionné en fonction d’au moins un critère donné, comme par exemple des considérations de charge, des considérations géographiques, etc. ; disposer (déjà) d’une route depuis le nœud relais 4 sélectionné vers le serveur destinataire. Cette information peut être obtenue par le module 3C de fourniture en interrogeant les nœuds relais 4 du système 1 pour obtenir les tables de routage maintenues par ces derniers ; etc.
Dans un autre mode de réalisation, le module 3C de fourniture du serveur DNS 3-1 peut sélectionner de façon aléatoire un nœud relais 4 parmi une liste de nœuds relais avec laquelle il a été préalablement configuré.
Par ailleurs, comme évoqué précédemment, le serveur DNS 3-1 peut également sélectionner une pluralité de nœuds relais en appliquant les critères évoqués précédemment, chaque nœud relais étant destiné à être utilisé par le dispositif client 2 pendant une durée déterminée (par exemple, la durée d’une connexion).
En outre, si l’option EAO de la requête REQ-DNS comprend un identifiant AID d’un nœud relais précédemment sélectionné pour le dispositif client 2 et le serveur destinataire 5 associé au service S, le serveur DNS 3-1 peut tenir compte de cet identifiant AID lors de la sélection du nœud relais (et le cas échéant de la préférence associée à cet identifiant AID indiquée par le dispositif client 2). Par exemple, si le dispositif client 2 a inséré dans l’option EAO un identifiant AID d’un nœud relais 4, le serveur DNS 3-1 peut sélectionner un nœud relais 4 de façon à éviter d’associer un même nœud relais avec un même serveur destinataire pour ce dispositif client 2, de sorte à minimiser le risque de traçage des communications DNS du dispositif client 2 par une entité malveillante (une telle entité éprouverait en effet une grande difficulté alors à établir une corrélation entre le serveur destinataire et l’identifiant du nœud relais). En variante, il peut décider de sélectionner un nœud relais coïncidant avec celui identifié dans l’identifiant AID de la requête REQ-DNS.
Il convient toutefois de noter qu’en fonction de sa configuration, le serveur DNS 3-1 peut ignorer les indications fournies par le dispositif client 2 dans le paramètre « AID » de l’option EAO de la requête REQ-DNS.
Suite à la sélection d’au moins un nœud relais 4 (le nœud relais 4-1 dans l’exemple illustratif envisagé), le module 3C de fourniture insère, dans une option EDNS EAO de la réponse REP-DNS à la requête REQ-DNS, une adresse du (ou des) nœud(s) relais sélectionné(s) (étape F70). Dans le mode de réalisation décrit ici, cette adresse est une adresse IP (adresse IPv4 ou adresse IPv6). Elle fait partie de la pluralité d’éléments AD ASTRA-ELTS fournie par le module 3C de fourniture au dispositif client 2.
En variante, on peut envisager de fournir un nom de domaine associé à chaque nœud relais sélectionné comme adresse de joignabilité, au lieu d’une adresse IP. L’utilisation d’une adresse IP présente l’avantage de ne pas nécessiter de résolution de nom supplémentaire (ce qui permet au dispositif client 2 d’accéder plus rapidement au service S).
Dans une autre variante encore, l’adresse insérée par le module 3C de fourniture est une adresse de transport du nœud relais 4 et comprend une adresse IP du nœud relais 4 ainsi qu’un numéro de port à utiliser.
La figure 9B illustre un exemple de format de l’option EAO insérée par le serveur DNS 3-1 dans sa réponse REP-DNS (qui fait écho à l’option EAO insérée par le dispositif client 2 dans sa requête REQ-DNS). Comme représenté sur cette figure, le champ OPTION-DATA de l’option EAO comprend plusieurs paramètres, dont notamment un paramètre « relay-locators », dans lequel l’adresse IP du nœud relais 4-1 sélectionné (ou les adresses IP des nœuds relais sélectionnés) est (sont) insérée(s).
Par ailleurs, conformément à l’invention, le module 3C de fourniture insère également dans l’option EAO de la réponse REP-DNS, dans la pluralité d’éléments AD ASTRA-ELTS qu’il fournit au dispositif client 2, au moins une instruction de brouillage INST devant être appliquée par celui-ci aux messages qu’il va adresser au nœud relais 4-1 et qui sont destinés au serveur destinataire.
Dans le mode de réalisation décrit ici, l’instruction de brouillage INST consiste en une instruction de bourrage (ou encore de remplissage ou de « padding ») des messages envoyés par le dispositif client 2 avant leur envoi au nœud relais 4-1. Elle est insérée dans un paramètre « padding » du champ OPTION-DATA de l’option EAO, comme illustré sur la . Cette instruction de bourrage est une instruction de compléter les messages destinés au serveur destinataire que le dispositif client 2 envoie au nœud relais 4-1 de sorte à homogénéiser leurs tailles. Le ou les motifs de bourrage appliqués par le dispositif client 2, notés PATT, sont choisis par exemple de sorte à rendre uniforme le gabarit des messages envoyés par plusieurs dispositifs clients. Ceci permet avantageusement de renforcer davantage l’anonymat des communications des dispositifs clients en question.
Toutefois, à l’étape 600, si l’une des premières valeurs de test CM est supérieure ou égale au premier seuil k 2 , les moyens de traitement 12 retirent à l’étape 600a la pseudo-distance dont la deuxième innovation IM(i) est associée à la première valeur de test CM(i) la plus élevée.
Les moyens de traitement 12 retirent également la première innovation associée Inno(i) du set des premières innovations Inno destinées à calibrer le filtre de Kalman 6.
Suite à cette étape, les moyens de traitement 12 mettent en œuvre une série d’étapes de traitement relatives aux premières innovations restantes.
Plus précisément, dans l’étape 600b, les moyens de traitement 12 mettent à jour chaque première innovation Inno(i) en fonction de la moyenne de l’ensemble des premières innovations Inno restantes.
Autrement dit, les moyens de traitement 12 effectuent le calcul suivant pour chaque première innovation Inno(i), i représentant N-1 premières innovations :
où i représente l’ordre d’une première innovation définie et, IR(i) une troisième innovation à laquelle on associe une variance VR(i)
Les moyens de traitement 12 calculent ensuite à l’étape 600c, selon la formule suivante, un deuxième groupe de deuxièmes valeurs de test CR en fonction desdites troisièmes innovations IR et de leurs variances respectives VR :
où i représente l’ordre de chaque première valeur de test CR.
Les moyens de traitement 12 comparent ainsi chaque deuxième valeur de test CR audit premier seuil k 2 à l’étape 600d
Les moyens de traitement 12 maintiennent, à l’étape 600e les pseudo-distances restantes de manière à calibrer le filtre de Kalman 6 si l’ensemble des deuxièmes valeurs de test CR est inférieur à k 2 .
Dans le cas contraire, à l’étape 600f, les moyens de traitement 12 émettent un signal d’alarme au système de navigation 2 si au moins une deuxième valeur de test (CR) est supérieure audit premier seuil prédéterminé.
Le signal d’alarme permet par exemple au système de navigation 2 de paramétrer le filtre de Kalman 6 selon des conditions ionosphériques dégradées.
En variante, le signal d’alarme permet au système de navigation 2 d’exclure pendant une durée ajustable le satellite 4 dont la pseudo-distance a été retirée.
Bien évidemment, l’invention n’est pas limitée aux modes de réalisation et de mise en œuvre décrits précédemment et fournis uniquement à titre d’exemple.
Un substrat POI 220 illustré à l’étape e) de la est réalisé par le procédé de transfert d’une couche piézoélectrique selon l’invention et comprend un substrat support final 210, une couche 216 et une couche piézoélectrique 208 d’une épaisseur comprise entre 50nm et 1µm, en particulier de l’ordre de 600nm.