INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
En outre, la section de pied S p s’étend sur un secteur angulaire de pied SECTAp entre la direction diamétrale D d et une direction diamétrale D p passant par le centre du cercle défini par le rayon de courbure RAtI du coude 21 de la section de tête S t , la section de tête S t s’étendant sur un secteur angulaire de tête SECTAt entre la direction diamétrale D p et la direction diamétrale D b passant par l’extrémité extérieure 19b, ledit secteur angulaire de tête étant inférieur audit secteur angulaire de pied.
Par ailleurs, l’amplitude radiale Ap de la section de pied S p suivant le rayon RAp dans lequel le sommet du coude 20 est inscrit peut-être maximisée, notamment en prévoyant un jeu JAp réduit entre ledit coude et la bague extérieure 6.
En relation avec les figures, chacune des branches 19 présente : un pied s’étendant en largeur Lbp autour de l’extrémité intérieure 19a, ledit pied se raccordant à la bague intérieure 5 par deux portées de pied respectivement amont 22 et aval 23 suivant le sens de rotation ; et une tête s’étendant en largeur Lbt autour de l’extrémité extérieure 19b, ladite tête se raccordant à la bague extérieure 6 par deux portées de tête respectivement amont 24 et aval 25 suivant le sens de rotation.
En particulier, la portée de tête amont 24 est inscrite dans un rayon RtH qui est supérieur à un rayon RtB dans lequel est inscrite la portée de tête aval 25, l’extrémité extérieure 19b de la branche 19 étant disposée selon le rayon RtH en définissant une épaisseur minimale respectivement EPtHmin et EPtBmin au niveau de respectivement la portée de tête amont 24 et la portée de tête aval 25. De façon avantageuse, l’épaisseur EPtHmin est inférieure à l’épaisseur EPtBmin pour maximiser la l’amplitude At entre le sommet du coude 21 et l’extrémité extérieure 19b.
Par ailleurs, les portées de tête amont 24 et aval 25 s’étendent chacune suivant un rayon RStH, RStB, les portées de pied amont 22 et aval 23 s’étendant chacune suivant un rayon RSpI, RSpE. En relation avec la , le rayon RSpI est supérieur au rayon RSpE, les rayons RStH et RStB étant de valeur analogue.
En relation avec la , chacune des branches 19 présente une portion de raccordement avec la bague extérieure 6, ladite portion ayant une face aval s’étendant suivant une direction radiale et une face amont formant un angle ANGtb avec ladite direction radiale, dans un souci de réduction des contraintes, en définissant une largeur de branche 19 minimale Lbmin.
Par ailleurs, chacune des branches 19 s’étend depuis le pied dans une enveloppe formée par une superposition de cercles comprenant un premier cercle de diamètre Cp1 tangent à l’extrémité intérieure 19a et un deuxième cercle de diamètre Cp2, ledit diamètre Cp1 étant supérieur au diamètre Cp2.
En outre, la direction D c passant par les centres des cercles de diamètre Cp1 et Cp2 est inclinée d’un angle ANGpb par rapport à la direction diamétrale D d , par exemple d’un angle de +/- 5° afin de pouvoir réaliser les branches 19 avec un premier cercle de diamètre Cp1 important dans un souci de réduction des contraintes.
"Empreinte numérique" d’un fichier numérique désigne une donnée produite par une fonction permettant de garantir l'intégrité du contenu du fichier, de sorte que si un octet du fichier est modifié, l’empreinte numérique sera modifiée. En outre, la probabilité que deux fichiers différents aient la même empreinte est très faible. Cette fonction peut être non inversible telle que notamment une fonction de hachage cryptographique appliquée à tout ou partie du contenu du fichier. Une empreinte numérique est parfois nommée somme de contrôle, empreinte, hash, résumé de message, condensé, condensat ou encore empreinte cryptographique. La fonction de calcul d’empreinte peut combiner une fonction de hachage et une fonction de signature numérique appliquée au résultat de la fonction de hachage.
"Signature numérique" désigne une empreinte numérique traitée par un algorithme de signature numérique utilisant une clé privée d’une paire de clés publique/privée et d’un programme cryptographique asymétrique, tel que DSA (Digital Signature Algorithm) ou ECDSA (Elliptic Curve DSA). Une signature numérique permet de garantir l’authenticité d’une preuve d'intégrité d'un fichier et d'en identifier et authentifier le signataire, par analogie avec la signature manuscrite d'un document papier.
"Insertion réalisée de manière contrôlée" désigne une insertion de donnée quelle qu’elle soit dans un fichier, en un emplacement que l’utilisateur peut choisir aussi librement que le permet le type de fichier concerné. Toutefois, ceci n’exclut pas que le choix de cet emplacement puisse être réalisé par un programme, ou être normalisé.
"Insertion réalisée de manière non-destructive" désigne une insertion d’une donnée quelle qu’elle soit dans un fichier numérique, réalisée sans affecter les propriétés du fichier, c’est-à-dire sans affecter notamment son ouverture, son affichage ou impression, et son exécution si le fichier contient des instructions de programme, par les mêmes outils qu’avant cette insertion.
"Registre" désigne un dispositif fournissant une présomption d’un ordre chronologique séquentiel précis de modifications d'état d'un objet. Un registre peut être opéré par un tiers de confiance, qu'il soit ou non certifié ou agréé. Les données mémorisées dans un tel registre peuvent être plus ou moins vérifiables et/ou publiquement accessibles. Dans le cas où le registre est accessible de façon dématérialisée par exemple par internet, il peut être rendu accessible par des requêtes offrant différents services, comme des services d’interrogation, d’écriture et d’authentification. Un registre peut s’affranchir d’un tiers de confiance en se reposant sur une solution de type chaine de blocs ("blockchain"), publique ou privée, permettant ou non l'exécution de contrats intelligents ("smart contracts") et/ou le stockage de données.
Etat de la technique Dans le contexte de l’utilisation généralisée de fichiers numériques, il est souhaitable de pouvoir remplacer les documents imprimés ou manuscrits par des fichiers numériques offrant des garanties analogues en termes de force probante. Par exemple, il est souhaitable que de tels fichiers puissent être utilisés en tant que preuves dans le cadre de transactions portant notamment sur des valeurs matérielles ou des relations contractuelles.
Le brevet US10 218 714 décrit un procédé permettant de déterminer si tout ou partie d’un fichier numérique a été modifié, grâce à l’insertion dans le fichier d’une empreinte calculée à partir de toutes les données formant le contenu du fichier pouvant inclure des métadonnées, à l’exclusion d’une zone où est insérée l’empreinte. Ainsi, si le contenu du fichier est modifié, l’empreinte calculée sur le contenu modifié du fichier est différente de l’empreinte insérée dans le fichier. Si l’empreinte est remplacée par une signature portant sur l’empreinte, ou si le fichier contient une empreinte et une signature de cette empreinte, et si la clé publique du signataire attendu figure dans les données participant au calcul de l'empreinte, seul le signataire attendu a pu générer cette signature.
Par ailleurs, dans le domaine de la gestion électronique de documents, il a été proposé un cadre conceptuel appelé "lignée de données" ("data lineage") visant à permettre de tracer le cycle de vie d’une donnée en vue de permettre de déterminer la source de cette donnée et les transformations qu’elle a subies. Ce concept de lignée de données permet par exemple d’associer à une donnée une classification de confidentialité pouvant évoluer au cours du temps, des versions successives de la donnée ou des dates de destruction obligatoire de la donnée. Ce procédé peut être déployé à l’intérieur d’une infrastructure ou d’une organisation, par des systèmes usuels de gestion électronique de documents, notamment pour tracer les auteurs, les versions et les responsables de documents.
Cependant, il n’existe aucun outil permettant de réaliser ces opérations de suivi entre infrastructures et entre organisations. En effet, une fois que le document est extrait de son système de gestion électronique de documents, il perd tous ses attributs permettant les opérations de traçage précitées. Il n’est pas non plus possible d’assurer un suivi de versions d’un même document lorsque ce dernier est sorti de son système de gestion de documents.
Il a également été proposé sous la forme d'une loi type un concept général de documents électroniques transférables (MLETR - "Loi Type sur les Documents Electroniques Transférables) permettant de tracer les propriétaires successifs et les versions d'un document ayant une valeur marchande. Aucune implémentation n'est toutefois suggérée dans ce contexte pour donner de manière irrévocable aux documents numériques un statut comparable à celui du papier signé de façon manuscrite.
Il a également été proposé d'utiliser un registre pour tracer les versions successives de documents sous des contraintes imposant un format particulier de fichiers et que toute version permette de régénérer l'unique version antérieure. Ce cadre ne décrit ni comment attacher des propriétés à un fichier existant, ni comment attester l'existence d'une pluralité de versions, ni comment permettre que les versions soient de formats et constructions distinctes, ni enfin comment désigner de manière irrévocable le registre considéré pour cette traçabilité.
Il a également été proposé d’utiliser la technique du NFT ("Non-Fungible Token" ou jeton non fongible) pour tracer la titularité d’un document, typiquement une œuvre d’art, en utilisant la technologie des contrats intelligents. Cette technique consiste à générer une donnée comprenant un jeton cryptographique représentant un objet numérique (par exemple une œuvre d’art) et une identité numérique relative au propriétaire de l’objet numérique. Cette donnée qui peut ainsi constituer un titre de propriété est stockée et authentifiée grâce à un protocole de chaine de blocs, dans un registre numérique décentralisé. Cependant, rien n’empêche qu’un document soit ainsi associé à plusieurs chaines de blocs identifiant ainsi plusieurs propriétaires simultanés.
Il est donc souhaitable de pouvoir lier de manière fiable et non falsifiable toutes les copies d’un fichier à une même donnée variable et de pouvoir déterminer toutes les données variables liées au fichier.
Des modes de réalisation concernent un procédé d’association de données variables à un fichier, le procédé comprenant des étapes consistant à : rechercher, par un processeur, un premier emplacement d’insertion d’une donnée dans un fichier ; insérer, par le processeur, au premier emplacement dans le fichier un identifiant d’un bloc de donnée d’un registre accessible depuis un serveur distant, le bloc de données mémorisant une donnée variable relative au fichier ; calculer, par le processeur, une première empreinte cryptographique portant sur une partie du contenu du fichier incluant l’identifiant du bloc de données, à l’aide d’une fonction de calcul d’empreinte, la première empreinte dépendant de tous les octets de la partie du contenu du fichier ; et transmettre la première empreinte par le processeur au serveur distant, la donnée variable étant accessible par une requête transmise au serveur distant, contenant la première empreinte.
De cette manière, il n’est pas possible de lier le fichier à un autre bloc de donnée sans modifier l’empreinte du fichier. Si le fichier est modifié, son empreinte est également modifiée. Il en résulte que le lien entre le fichier et la donnée variable dans le registre est rompu, puisque ce lien est basé sur l’empreinte du fichier. Par ailleurs, si la modification du bloc de donnée contenant la donnée variable ne peut être effectuée que par une entité habilitée, seule cette entité peut modifier la donnée variable. En d’autres termes, l’empreinte interdit de modifier l’identifiant du bloc de donnée présent dans le bloc de donnée qui contient l’empreinte, et l’empreinte ne peut pas être obtenue à partir d’un autre contenu que celui du fichier. La lecture du contenu du fichier ne peut pas permettre d’accéder à un bloc de donnée autre que celui qui est désigné par l’identifiant présent dans le fichier. Cette liaison entre le fichier et le registre est présente dans toutes les copies ou occurrences du fichier.
Selon un mode de réalisation, le procédé comprend des étapes consistant à : recevoir par serveur distant une requête d’accès au bloc de donnée contenant la première empreinte du fichier ; déterminer par le serveur distant si un bloc de donnée contenant la première empreinte est accessible ; et exécuter par le serveur distant la requête d’accès, et fournir par le serveur distant à un émetteur de la requête d’accès un compte-rendu d’exécution de la requête d’accès.
La ﬁgure 4 représente schématiquement un ensemble d’étapes d’un procédé de vérification de l’intégrité d’un fichier et d’écriture de données variables associées au fichier, selon un mode de réalisation.
Description détaillée La ﬁgure 1 représente des étapes S1 à S5 d’un procédé de création d’un fichier à partir d’un fichier existant FL1. Le procédé peut être mis en œuvre par un terminal T1 et un serveur SRV interconnectés, par exemple par l’intermédiaire d’un réseau NT de transmission de données. Ainsi, le terminal T1 et le serveur SRV peuvent établir entre eux une relation client-serveur. La ﬁgure 2 représente le fichier FL1 et un registre RG1. Initialement, le fichier FL1 peut être vide ou plein.
Les étapes S1 à S4 sont exécutées successivement par le terminal T1. A l’étape S1, le terminal T1 insère une référence BCI1 à un bloc de donnée BC1 du registre RG1 dans le fichier FL1. Cette insertion est réalisée de manière contrôlée et potentiellement non-destructive, par exemple en encapsulant la référence BCI1 dans une métadonnée. La référence BCI1 contient les informations permettant de retrouver le registre RG1 et le bloc de données BC1 dans le registre. Selon les cas, ces informations peuvent comprendre notamment une donnée d’identification (par exemple l’adresse) du serveur SRV afin de permettre de déterminer à quel serveur il convient de s’adresser pour avoir accès au bloc de donnée BC1.
A l’étape S2, le terminal T1 calcule une empreinte HS1 du fichier FL1 à l’aide d’une fonction HSH de calcul d’empreinte recevant en entrée tout ou partie du contenu du fichier, y compris la référence BCI1 ou la métadonnée incluant cette référence et le cas échéant, la donnée d’identification du serveur SRV. La fonction HSH peut être une fonction de hachage cryptographique et/ou une fonction de signature numérique. A l’étape S3, le terminal T1 insère l’empreinte HS1 dans le fichier FL1 en un emplacement qui ne sera pas pris en compte pour le calcul de l’empreinte du fichier FL1. L’étape S3 est optionnelle et donc peut être omise, sachant que l’empreinte HS1 du fichier FL1 peut être recalculée à partir du fichier FL1 seul.
L’empreinte HS1 peut être associée à un repère permettant de retrouver son emplacement et son étendue dans le fichier FL1. L’empreinte HS1 peut être signée numériquement préalablement à son insertion dans le fichier FL1. La fonction de calcul d’empreinte peut être appliquée à tout ou partie du fichier FL1.
A l’étape S4, le terminal T1 transmet l’empreinte HS1 au serveur SRV. L’empreinte HS1 peut être transmise au serveur SRV sous la forme d’une requête de mise à jour du bloc de donnée BC1, incluant éventuellement l’identifiant BCI1 du bloc BC1 où elle doit être enregistrée dans le registre RG1, et éventuellement une signature numérique de l’empreinte HS1. A l’étape S5, le serveur SRV reçoit l’empreinte HS1 et l’insère dans le bloc de donnée BC1 du registre RG1.
De cette manière, la consultation du registre RG1 permet d’identifier le fichier FL1 et réciproquement, la consultation du fichier FL1 permet d’identifier le registre RG1. Lorsque l’étape S3 d’insertion de l'empreinte HS1 dans le fichier FL1 est exécutée, l’empreinte peut être utilisée pour trouver une occurrence du fichier FL1 sur les espaces de stockage de l'utilisateur par des outils informatiques système. Par ailleurs, que l’empreinte HS1 soit insérée ou non dans le fichier FL1, elle peut être confirmée en interrogeant le serveur SRV, à l’aide de l’identifiant BCI1 figurant dans le fichier FL1.
Le bloc de donnée BC1 peut contenir une donnée relative au fichier FL1, qui peut être modifiée. Ainsi, une consultation du registre RG1 sur la base de l’identifiant BCI1 trouvé dans le fichier FL1 donne accès à cette donnée modifiable. En revanche, si la référence BCI1 est modifiée dans le fichier FL1, l’empreinte calculée sur le fichier ainsi modifié est différente de l’empreinte HS1. Il n’est donc pas possible d’accéder au bloc de donnée BCI1 à partir du fichier modifié, ni de retrouver le fichier modifié à partir de l’empreinte HS1 se trouvant dans le bloc de donnée BC1 du registre. Par conséquent, l’existence de l’empreinte HS1 interdit la modification de l’identifiant BCI1 dans le fichier FL1. Par ailleurs, l’identifiant BCI1 identifie de manière certaine le bloc de donnée BC1 dans le registre RG1, lequel contient l’empreinte HS1 qui identifie de manière certaine le fichier FL1. Il est à noter qu’il est extrêmement difficile de générer un fichier ayant une empreinte prédéfinie, et qu’il est extrêmement peu probable (probabilité inférieure à 10 -77 ) que deux fichiers aient la même empreinte. Il est donc extrêmement probable que l’empreinte HS1 n’a pas été insérée dans le bloc de donnée BC1 avant qu’elle soit calculée sur le fichier FL1 après insertion de l’identifiant BCI1.
Les liens formés par les données BCI1 et HS1 entre le fichier FL1 et le registre RG1 ne dépendent pas d’un emplacement physique de stockage du fichier ou du registre ou d’un système de fichiers tel que NTFS (New Technology File System) ou FAT (File Allocation Table). Ces liens peuvent être vérifiés quels que soient la copie du fichier FL1 considérée et l’emplacement physique où cette copie est stockée.
L’accès en écriture au registre RG1 réalisé à l’étape S5 peut être limité à une ou plusieurs personnes dûment habilitées.
Selon un mode de réalisation, le fichier FL1, éventuellement avec son empreinte HS1 embarquée, est publié sur une plateforme identifiant les fichiers par leur empreinte, par exemple sur le modèle de IPFS ("InterPlanetary File System") pour des empreintes calculées sur la totalité du fichier.
La ﬁgure 3 représente des étapes S11 à S18 d’un procédé d’accès en lecture à des données variables associées à un fichier tel que le fichier FL1, après avoir été traité durant les étapes S1 et S2 et éventuellement S3, pour recevoir un identifiant de bloc de donnée BCI1 et pour le calcul de l’empreinte HS1. Le terminal T1 exécute tout d’abord les étapes S11 à S14. A l’étape S11, le terminal T1 calcule une empreinte HS2 du fichier en appliquant la fonction de calcul d’empreinte HSH utilisée à l’étape S2 au contenu du fichier FL1. Si l’empreinte HS1 a été insérée dans le fichier FL1, celle-ci est exclue du contenu du fichier auquel est appliquée la fonction HSH. A cet effet, la position de l’empreinte HS1 dans le fichier peut être repérée à l’aide d’un repère. Le repère peut spécifier une ou plusieurs zones exclues du contenu du fichier, sur lequel le calcul d’empreinte doit être appliqué, ou spécifier la ou les zones du contenu du fichier auxquelles le calcul d’empreinte est appliqué. L’étape S12 est optionnelle, notamment si l’empreinte HS1 ne figure pas dans le fichier FL1. A l’étape S12, le terminal T1 compare l’empreinte calculée HS2 avec l’empreinte HS1 préalablement associée au fichier FL1. Si les empreintes HS1 et HS2 correspondent ou sont identiques, le contenu du fichier FL1 sur lequel porte le calcul d’empreinte n’a pas été modifié depuis le calcul de l’empreinte HS1. Dans le cas contraire, le fichier FL1 peut avoir été modifié, ou la fonction de calcul d’empreinte utilisée ne correspond pas à celle utilisée pour le calcul de l’empreinte HS1, ou encore l’étendue du contenu du fichier sur lequel porte le calcul d’empreinte ne correspond pas à celui pris en compte pour le calcul de l’empreinte HS1. L’étape S12 peut comprendre d’autres vérifications comme la vérification d’une signature numérique permettant de déterminer l’authenticité du fichier.
L’exécution des étapes S13, S14 peut être conditionnée au succès de la comparaison des empreintes HS1 et HS2 à l’étape S12. A l’étape S13, le terminal T1 lit dans le fichier FL1 l’identifiant BCI1 du bloc de donnée BC1 du registre RG1 où sont stockées les données relatives au fichier FL1. A cette étape, l’identifiant BCI1 peut être considéré comme authentique si l’étape S12 de comparaison a été exécutée et avec succès. A l’étape S14, le terminal T1 peut transmettre au serveur SRV une requête de lecture RQR d’informations relatives au fichier FL1 stockées dans le registre RG1. A cet effet, la requête RQR contient une information permettant d’identifier le fichier FL1, telle que l’empreinte HS2, et éventuellement tout ou partie de identifiant BCI1 du bloc de donnée BC1. A l’étape S15, le serveur SRV reçoit cette requête et détermine si un bloc de donnée du registre RG1 contient bien l’empreinte HS2 transmise à l’étape S14, et éventuellement que l’empreinte HS2 se trouve bien dans un bloc de donnée du registre RG1, correspondant le cas échéant à la partie de l’identifiant BCI1 reçue. L’étape S15 permet de déterminer que l’empreinte HS2 reçue a bien été précédemment associée au bloc de donnée BC1 du registre RG1, éventuellement correspondant à la partie de l’identifiant BCI1 reçue à l’étape S14. La vérification effectuée à l’étape S15 permet indirectement de déterminer que le fichier FL1 est intègre si l’empreinte reçue HS2 a bien été calculée à partir du contenu du fichier FL1. Si Si le test effectué à l’étape S15 est positif, alors le serveur SRV exécute les étapes S16 et S17. A l’étape S16, le serveur SRV lit les informations contenues dans le bloc de donnée BC1 où se trouve l’empreinte HS2. A l’étape S17, le serveur SRV transmet les informations Inf(BC1,HS2) lues dans le bloc de donnée BC1 au terminal T1. A l’étape S18, le terminal T1 reçoit et exploite les informations Inf(BC1,HS2) reçues.
Selon un mode de réalisation, les informations Inf(BC1,HS2) comprennent une liste d’identifiants (d’empreintes) de fichiers correspondant à différentes versions du fichier FL1. Ceci présuppose qu’à chaque création d’une nouvelle version du fichier FL1, les étapes S1 à S5 sont exécutées en utilisant le même identifiant BCI1 de bloc de donnée BC1 et en remplaçant l’empreinte figurant dans le fichier par la nouvelle empreinte calculée sur la nouvelle version du fichier. Ainsi le bloc de donnée BC1 comprend pour chaque version du fichier FL1 un enregistrement comportant l’empreinte de la version du fichier. Ainsi la donnée variable associée au fichier FL1 dans le bloc de donnée BC1 est l'empreinte de la plus récente version connue (ou selon les modalités techniques la liste des versions connues) du fichier FL1, enregistrées successivement dans le bloc de donnée BC1. Le choix fait par l'utilisateur de considérer qu'un fichier constitue une version nouvelle d'un autre fichier est arbitraire et ne dépend ni des modalités de production, ni du format du fichier. Le registre RG1 peut fournir la liste des empreintes de versions d’un même fichier, mais ne donne pas accès au contenu de ces versions.
Selon un mode de réalisation, les informations Inf(BC1,HS2) comprennent un ou plusieurs états de contrat intelligent. Selon un exemple de réalisation, le fichier FL1 contient une œuvre d’art numérique, et le bloc de donnée BC1 contient un ou plusieurs états de contrat intelligent contenant des données relatives au propriétaire du fichier FL1 comme des données d’identification du propriétaire et des données relatives à l’achat par le propriétaire de l’œuvre d’art numérique comme la date d’achat et le prix d’achat. Ainsi, la donnée variable associée au fichier FL1 dans le bloc de donnée BC1 comprend la liste des transactions de transfert de propriété de l’œuvre d’art, enregistrées successivement dans le bloc de donnée ou BC1. Chaque transaction peut rassembler des données telles que la date de la transaction, des informations sur l’identité du nouveau propriétaire, et le montant de la transaction.