FR3076366A1 - Procede d'horodatation absolue de representations numeriques de grandeurs analogiques grace a des consignes d’acquisition probantes fondees sur une blockchain - Google Patents

Abstract

Procédé d'horodatation de fichier (203, 204) de phénomènes physiques (ondes électromagnétiques, mécaniques,..) numérisés d'objet (101) dans son environnement (207, 206) grâce à des consignes d'acquisition (103 à 107) prouvant : - l'inexistence préalable dudit fichier à une date de début (201) de création car elles : • portent sur un paramètre (103, 104, 106, 107) à numériser fondée sur l'aléa horodaté (201) de production d'un bloc (209) d'une blockchain (202), • sont appliquées avant la conversion analogique/numérique du capteur (111), - l'existence dudit fichier avant une date postérieure de fin (214) après : • sa notarisation (données 213, 212, 205, 211) dans un bloc subséquent (210), • validation de l'intervalle de temps de sa création par recalcule desdites consignes sur la base des données de notarisation et dudit fichier analysé selon l'état de l'art.

Description

La présente invention concerne un procédé permettant d’horodater de façon absolue, probante et sans tiers de confiance, l’intervalle de temps autour de la numérisation par un capteur et dans un fichier, d’un phénomène physique (ondes électromagnétiques, ondes mécaniques, ...), grâce à des consignes d’acquisitions probantes. La nature absolue de l’horodatation renvoie aux caractéristiques suivantes : elle est chiffrée et exprimée en unité de temps ; elle porte sur les bornes temporelles de la création d’un fichier : une date de début et une date de fin; elle manipule des données qui sont toutes cryptographiquement vérifiables : il n’y a pas besoin de tiers de confiance ; elle est assortie d'un niveau de certitude quantifiable que le fichier ne préexistait pas avant sa création à une date initiale et il existe avant une date finale postérieure. Ces consignes probantes de numérisation dans un fichier par un capteur fournissent ainsi :

- la preuve mesurée de l’inexistence du fichier avant une date courante initiale ou de façon équivalente la preuve de son existence après cette date initiale,

- la preuve cryptographique de son existence avant une date finale,

Ces deux dates, initiale et finale, définissent donc l’intervalle : date de début et date de fin, du moment et de la durée de la création dudit fichier. La date finale est postérieure à la date initiale sur l’échelle temporelle absolue donnée par deux blocs horodatés d’une chaîne de blocs (blockchain). Les consignes de l'invention sont consituées de telle sorte que l'analyse du fichier horodaté crée permet de retrouver une valeur brute aléatoire et horodatée sur laquelle elles sont fondées. Les consignes sont appliquées avant la phase de conversion analogique/numérique du capteur qui alimente la création du fichier. Ladite valeur brute aléatoire et horodatée et celle d'un bloc de blockchain : le bloc dateur qui donne la date de début. Après sa création, le fichier est notarisé dans un bloc subséquent qui donne la date de fin. Une consigne est donc constituée d'une partie brute avec l'aléa horodaté, et d'une partie normalisée (fonction de mesure) avec les données (domaine fréquentiel, temporel, spatial et ses référentiels; portées des consignes,..) permettant de numériser un paramètre. Ce paramètre consigné est par exemple les coordonnées dans le référentiel d'une photo d'un objet identifiable dans cette photo; une vitesse ou un trajet consigné identifiable dans une vidéo par extraction des vecteurs de mouvement, une séquence vocale temporelle consignée dans un fichier audio, une séquence consignée de forme de signal radio. La numérisation d'un paramètre selon des consignes portant avant la phase de conversion/analogique le rend indépendant du contenu informationel (visage, voiture, voix, ...) numérisé du fichier. Ces paramètres non limitatifs sont chacun exemplifiés par des figures. La présente invention (l’invention) est une solution technique au problème technique d’horodatation absolue et probante de tels fichiers ; elle n’existe pas dans l’état de l’art. On défini un fichier comme un ensemble de données binaires. Un fichier est par exemple une seule ou plusieurs photographies ou une vidéo avec plusieurs enregistrements audio. La notarisation d'un fichier consiste à graver une valeur d'ancrage dans une blockchain. Une valeur d'ancrage est univoquement associée au fichier qu'elle notarise car les calculs (cryptographiques) sur le fichier à l'aide des références de notarisation permet de retrouver cette valeur. Pour horodater la date de début, l'invention consiste à faire de la valeur aléatoire d'un bloc la valeur d'ancrage du fichier à créer grâce à des consignes définies comme un élément de références de notarisation sous la forme de fonction mesurable de l'espace probabilisé des valeurs aléatoires (des blocs) vers l'espace mesuré de l'ensemble des fichiers numérisant un paramètre indépendamment du contenu du fichier. La notarisation du fichier créer dans un bloc subséquent donne la date de fin de sa création. A titre de synthèse : L'invention consiste ainsi à notariser le fichier par une valeur d'ancrage qui est celle aléatoire et horodatée produite par un bloc dateur d'une chaîne de blocs; puis de notariser le fichier ainsi produit dans un bloc subséquent. Pour ce faire, le procédé est en trois phase de définition, exploitation et validation :

- les consignes sont définies comme une mesure et elles constituent les valeurs numériques de base de références de notarisation,

- leurs exploitations s'appliquent avant la phase de conversion analogique/numérique du capteur qui alimente le fichier, donc sur la position/orientation ou sur une commande du capteur, pour produire une suite de numérisation (le fichier horodaté),

- leur validation sur la base du fichier notarisé produit, par identification du paramètre numérisé avec la valeur d'aléa horodaté (la valeur d'ancrage), donne à ce dernier son horodatation absolue; le paramètre est identifié à la valeur de l'aléa avec ou sans l'analyse de l'objet numérisé.

Fondamentalement, le fichier à horodater est une représentation d'informations analogiques et numériques mais aléatoires qui n'a pas d'existence (sous forme de fichier) avant sa création ! L'invention permet de réduire les coûts liés à l’aléa moral et l’asymétrie d’information dans le domaine de la vente de bien et de service en ligne comme par exemple celui de l’assurance avec l’horodatation probante de photographie de l'objet (véhicule, œuvre, bâtiment, local,...) couvert par la garantie. Elle permet l’absence des infrastructures à clé publique, d'horodatage et d’archivage avec l’horodatation probante de photo, d’audio ou de vidéo selfies, dans une chaîne de blocs, à titre de signature électronique biométrique. Elle apporte aux objets connectés (webcam, drone, loT : Internet of Things,..) les moyens techniques pour la fourniture de preuves cryptographiques d’horodatation de mesures physiques diverses. Elle est donc susceptible d'industrialisation et de commercialisation à grande échelle. L'activité inventive de l’invention consiste à exploiter les performances des capteurs et de l’analyse numérique de l’état de l’art, la nature et les fonctionnalités de la blockchain et plus profondément : la nature des informations analogiques et des informations aléatoires. Les informations analogiques et numériques aléatoires n'ont pas d'existence avant une date donnée. Les informations analogiques, ici celles relatives au transfert d'énergie (ondes électromagnétiques dans le spectre visible et radioélectrique, ondes mécaniques sonores, ...), constitue une quantité infinie d'information. De quantité infinie, elles ne sont donc pas stockables en particulier sous forme numérique (fichiers) : elles n'ont pas de représentation, soit d'existence préalable, sur un support matériel. Les informations numériques aléatoires sont par définition inconnues avant une date donnée. C'est en particulier le cas, en effet de bord qu'exploite l'invention, des empreintes des blocs des blockchains dont le consensus décentralisé est en particulier de type preuve de travail. Les consignes d'acquisition probantes de l'invention sont donc construites sur l’aléa horodaté de production des blocs d'une blockchain et sont appliquées directement sur l'information analogique soit : avant la phase de conversion analogique/numérique réalisée par le capteur (photographique, vidéographique, audiographique, ..). Les consignes d'acquisition probante pour la production d'un fichier portent donc soit :

- sur la localisation/orientation spatiale ou temporelle du capteur,

- sur les commandes (transduction, conditionnement, filtrage, amplification, contrôle des linéarités,....) du capteur.

L’intégrité de la totalité des données et traitements d’exploitation du présent procédé est cryptographiquement vérifiable, en termes non technique : il n’y a pas besoin de tiers de confiance. Cette intégrité est assurée par :

- l'exploitation d’empreintes cryptographiques des blocs et des fichiers produits; ces empreintes sont notarisées dans les blocs dateur (date de début) et subséquents (date de fin) de la blockchain exploitée,

- la blockchain elle-même (ses blocs) qui est par construction intègre et qui est exploitée (lues et écrites) par l'invention à l’aide soit :

o d’un client lourd : serveur manipulant la totalité de la blockchain, o d’un client léger : sur terminal/smartphone et ne manipulant que les blocs utiles et intègres par la technique cryptographique des arbres de Merkle.

Pour finir cette présentation générale de l'invention, si l'information analogique n'a pas d'existence préalable (au sens sus-donné), il reste à s'assurer qu'une représentation numérique qui satisferait les consignes de l'invention, ne préexiste pas ou du moins, ne préexiste pas selon un niveau de confiance voulu. Le niveau de confiance relatif à l'inexistence préalable du fichier à produire est quantifiable. Il est défini selon l'état de l'art dans le domaine d'application. En mathématiques, une mesure est une fonction qui associe une grandeur numérique à certains sous-ensembles d'un ensemble donné. Sur cette base, il est ci-après ébauchée une modélisation quantitative de l'expérience aléatoire que représente une horodatation selon l'invention. On précise quelques axiomes : une consigne brute à une valeur aléatoire extraite d'un bloc. Un paramètre à numériser a une valeur fondée sur de l'aléa numérique (une consigne brute) de telle sorte que la taille minimale du fichier résultant augmente avec l'étendue de la plage de valeur de l'aléa; la taille du fichier comme la plage de l'aléa s'exprime en bits d'information. On assimile un fichier à un ensemble ouvert dans la mesure où, satisfaisant une consigne brute, il peut toujours être indéfiniment parcouru par des données non signifiantes : il n'a pas de frontière. Sur cette base, on ne considère que les fichiers de taille minimale et non nulle pour l'identification, en fonction de l'état de l'art, d'un paramètre numérisé. Ainsi, on défini l'espace probabilisé (Q,F,P) et l'espace mesuré (E, S, μ). L'univers Ω est l'ensemble des valeurs numériques aléatoires. Les évènements F, partie de Ω, regroupe l'ensemble des valeurs numériques aléatoires sur un nombre donné de bits d'information, dans les faits ceux exploités pour la consigne brute. La probabilité P est celle associée aux évènements élémentaires de F, celle d'obtenir une valeur aléatoire horodatée donnée, extraite d'un bloc dateur sur le nombre donné de bits d'information. L'espace E, est l'ensemble infini dénombrable de tous les fichiers numérisant un paramètre donné (trajet, vitesse, position, séquence temporelle ou fréquentielle,..) selon la valeur d'une consigne brute, pour un même objet (visage, voiture, signal, données quelconques non signifiantes,...) et dont la taille est minimale. Sur deux fichiers numérisant le même paramètre selon la même valeur d'aléa horodaté d'une consigne brute, seul celui ayant la taille la plus petite appartient à E. Si ils sont égaux en taille, on considère un fichier comme un ensemble ordonné de bits et on prend celui représentant la valeur la plus faible. La tribu 8, partie de E, est celle des fichiers dont le paramètre numérisé satisfait (est égal à) une consigne brute à valeur dans F. 8 est une sorte de tribu borélienne numérique (!). L'espace E est complétée d'une mesure définie sur 8 qui est la taille de fichier. La mesure μ est additive et monotone. On a alors la variable aléatoire discrète de Ω vers E, fonction mesurable X de Ω vers E associée à une mesure μ. La fonction mesurable X est la partie normalisée des consignes. Dans ce cadre modélisé, l'horodatation de l'invention peut être vue comme, à postériori, l'expérience aléatoire d'un évènement certain, donc:

- soit on connaît la valeur de la consigne brute et le fichier horodaté a une taille minimale donnée, car P (consigne brute) = 1,

- soit on ne connaît pas la valeur de la consigne brute et le fichier horodaté à la taille de toute sa tribu 8, car P (F) = 1,

Ainsi, frauduleusement horodater un fichier est l'expérience aléatoire de l'évènement certain : le fichier préexiste et satisfait la consigne, c'est la tribu 8 et il a sa taille en octets ou bits d'information. Hors, selon l'invention, on peut à loisir augmenter la plage de valeur de consigne brute pour faire en sorte que les capacités de stockage de l'état de l'art ne permettent pas de stocker la tribu. La confiance en l'inexistence préalable du fichier à horodater est alors de 100%. On peut horodater à postériori un fichier en prenant par exemple la valeur aléatoire d'un bloc datant de deux ans à titre de date de début, le problème sera alors que la date de fin sera celle courante deux ans plus tard car le fichier produit doit être notarisé. C'est à celui auquel est destiné le fichier d'apprécier le fait qu'il à fallu deux ans (!) pour le créer quand le procédé de l'invention donne des intervalles de création de quelques dizaines de secondes entre la date de début et la date de fin. On ne peut pas horodater à priori car comme on va le développer, la plage de valeur de la consigne brute peut être aussi étendue (en bits d'information) qu'on le souhaite et le nombre de paramètre à numériser peut être augmenté à loisir pour un même objet. Le niveau de confiance évoqué est la taille minimale, en bits d’information, d’un fichier qui serait une représentation numérique existante d'un objet et d'un paramètre identifiable par l’état de l’art et qui satisferait de façon certaine les consignes applicables avant qu’elles ne soient appliquées. Si ce fichier existe déjà, il doit être stocké quelque part. En 2017, la capacité totale mondiale de stockage est estimée (étude de International Data Corp.) à 7,235 zettaoctets, soit 5,788 * 10²² bits d'information. Un niveau de confiance de 100% de l’inexistence du fichier à produire, chiffré en ordre de grandeur, est donc ici de 23; 10²³ bits d'information étant la taille de ce fichier qui ne peut pas exister. Il ne peut pas, en effet, selon l'état de l'art, être stocké quelque part. Il est aisé, grâce au procédé de l’invention, de définir des consignes d’acquisition assorti d’un niveau de confiance de 100% concernant l’inexistence préalable du fichier à produire. Les calculs sont développés plus loin. Il est même possible, sur la base d’un stockage d’un bit par atome (société IBM, mars 2017 : Reading and Writing Single-Atom Magnets - Fabian D. Natterer, Kai Yang, William Paul, Philip Willke, Taeyoung Choi, Thomas Greber, Andréas J. Heinrich, and Christopher P. Lutz) et du nombre postulé de 10⁸° particules dans l’univers, de définir des consignes d’acquisition telles que toutes les particules de l’univers ne suffiraient pas à stocker un fichier préexistant tel que consigné. Bien sûr, la série de consignes définit imposerait dans ce cas particulier un mode opératoire de plusieurs minutes d'acquisition pour l'utilisateur du procédé de l'invention. Cette dernière permet ainsi la production de preuve cryptographique de la date de début et de la date de fin de création d'un fichier alimenté par la conversion analogique/numérique d'un capteur quelconque et pour diverses grandeurs physiques. A titre d’exemple, dans le domaine particulier des ondes électromagnétiques dans le spectre visible (la lumière) numérisées dans un fichier par le capteur photographique d’un smartphone : l’invention permet de prouver qu’une photographie a été prise entre deux dates donnés représentant un intervalle de temps de typiquement quelques dizaines de secondes. L’invention intéresse particulièrement les domaines pour lesquels une preuve d’existence d’un objet (d’un sujet, d’un phénomène, d’un évènement,...) dans un état donné et à un moment donné est utile. Dans ses domaines d’application, l’invention permet de réduire considérablement les coûts liés à l’aléa moral et l’asymétrie d’information. Dans un mode préférentiel de mise en œuvre pour l'utilisateur, l'invention est implémentée sous la forme d’une application pour équipements informatiques mobiles (smartphone, tablette,..) pour l’horodatage de photo, de vidéo ou d'audio avec une fonctionnalité additionnelle de signature biométrique. Les domaines pertinents sont, pour exemples non limitatifs, ceux de la location, le prêt, la création, la vente ou l’assurance de biens pour la réalisation de photo de constat (bon état, accident, dégradation, malfaçon, bonne réception, état courant, ...). Par exemple, concernant l’assurance temporaire de véhicule, une ou plusieurs photos horodatées du véhicule assuré permettent de déclencher la garantie contractualisée pour la durée choisie. Cela réduit considérablement le niveau de fraude consistant à assurer temporairement un véhicule après, et non avant, d’avoir subi un dommage. La présente invention permet à un locataire, au moment de son arrivé, de procéder seul à l’état du lieu (location de vacances, bureau temporaire, ....) sans la présence du loueur. Elle permet à tout utilisateur de produire l'enregistrement sonore, la photo ou la vidéo d'un constat (nuisance sonore, photo de dégradation, vidéo de constat d'abandon de domicile conjugale,...) sans la présence d'un huissier de justice. Chacun de ces fichiers peut être de surcroît, au besoin, biométriquement signé par un enregistrement audio et/ou photo et/ou vidéo. L’invention permet encore de rigoureusement horodater toutes séquences de vidéosurveillance, par exemple celles produite par une webcam ou un drone. La webcam pour constater à distance un état météorologique (enneigement, ensoleillement,..) ou environnemental à un moment donnée d’un lieu donné. Le drone pour constater les effets d’un évènement climatique (inondation, sécheresse, grêle,...) dans le contexte de garanties assurantielles ou constater à distance l'état d'un chantier pour son suivi. Au-delà d'un drone, l'invention adresse les domaines des capteurs intelligents et des objets autonomes connectés dont les domaines applicatifs sont très vastes. Elle permet d’apporter la preuve cryptographique d’horodatage de mesures physiques diverses acquises et transmises par un tel capteur/objet autonome. Actuellement, la véracité des mesures de ces objets connectés repose sur un identifiant unique lié à l'objet et attribué par le constructeur tiers de confiance, donc théoriquement et pratiquement falsifiable, ce qui n’est pas le cas grâce à l’invention qui n'a besoin d'aucun tiers de confiance. En effet, la phase de définition des consignes permet d’exploiter le procédé avec un niveau de certitude choisi, chiffré et aussi élevé que l’on souhaite, quand à la préexistence d’un fichier consigné. L’invention permet de fournir le cas échéant à la justice, des preuves cryptographiques de la date d’un état ou d’un évènement. Dans une mise en œuvre particulière, l'invention permet de produire des signatures électroniques biométriques grâce à l'utilisation d'audio, photo ou de vidéo selfie ainsi horodatées par l’invention. Les signatures biométriques ainsi produites ont plus de force probante que les signatures manuscrites (elles incorporent plus de matière ou d'information biométriques) ou électroniques de l’état de l’art mais surtout, elles ne requièrent aucune infrastructure à clé publique, aucune gestion de la sécurité qui est externalisée par la bockchain, aucune infrastructure d’horodatage probant et aucune infrastructure d’archivage probant puisque ces signatures biométriques sont notarisées dans la blockchain. L'horodatation absolue de fichier de l'invention permet en fait, pour l'authentification et la signature électronique biométriques, d'exploiter des certificats autoproduits. L’invention est donc susceptible de commercialisation à très grande échelle et au bénéfice tant des institutions, des professionnels que du grand public.

Description détaillée de l'invention

Dans la suite de présent document est présenté :

- une description fonctionnelle de l’invention et l’état de l’art de l'horodatation et des chaînes de blocs ;

- les solutions apportées par l'invention ;

- des exemplifications et des illustrations par des figures en développant sept propriétés des consignes d'acquisition probantes de l'invention.

Concernant l’état de l’art, les procédés existants permettent de prouver l’antériorité (l’existence) de la création d’un fichier antérieurement à une date donnée. Ils le peuvent avec ou sans tiers de confiance. A ce jour, il n’existe pas de procédé automatisé permettant de prouver la postériorité de la création d’un fichier à une date donnée et d'en prouver la création dans un intervalle de temps horodaté et d'en garantir de façon chiffrée le niveau de certitude relatif à son inexistence préalable à sa création, le tout sans le recours à un tiers de confiance. C’est l’objet de la présente invention avec son procédé en trois phases (définition, exploitation, validation). Le non recours à une autorité de confiance est valable en phase de production du fichier, grâce à l'exploitation de l'aléa horodaté d'une chaîne de bloc. Il est aussi valable en phase de validation de l'horodatage du fichier grâce à l'exploitation de nœud complet (client lourd) ou de client dit léger pour l'interfaçage avec ladite blockchain. En phase de production il est possible de contrer le déni de service en obtenant l'aléa horodaté en connexion avec la blockchain avec un client lourd ou léger. Plus précisément, l’invention consiste à faire varier les conditions d’acquisition d’une grandeur physique analogique, par exemple un objet dans son environnement pour une photographie, selon une valeur aléatoire horodatée, pour produire un fichier de telle sorte que l’analyse ultérieure de son contenu permette d'une part de recalculer et vérifier la valeur de desdites consignes après identification de l'objet et d'autre part de vérifier que l'empreinte du fichier est notarisée à une date ultérieure à celle associée auxdites consignes. Plus en détail, l’invention consiste à faire varier, par des consignes, les conditions d’acquisition (le paramètre) d’une grandeur physique analogique :

- avant l'étape de conversion analogique/numérique (transduction, conditionnement, filtrage, amplification, position/orientation spatiale du capteur,...) pour la production d'un fichier ; les grandeurs analogiques/continues représentent une quantité infini d’information et ne sont donc pas stockables sous aucune forme, elles sont donc « non préalablement stockées >> et non manipulables, frauduleusement ou non, par un programme informatique, elles sont in fine inaccessibles à la connaissance (cf. indétermination de Heisenberg) donc antérieurement inexistantes, dans le sens sans représentation numérique avant la date de l'acquisition; pour s'assurer de cette inexistence préalable, avec un niveau de confiance aussi élevé que l'on veut, on exploite une série de plusieurs consignes d'acquisition définis en fonction de l’état de l’art et portant sur un ou plusieurs paramètres;

- selon des consignes d’acquisition fondées sur l’aléa horodaté d’une chaîne de blocs (blockchain), ledit aléa étant public, séquentiellement produit dans chaque nouveau bloc et gravé dans ladite blockchain ; une valeur aléatoire est par définition « inexistante » (inconnue) avant qu’elle ne soit révélée à un moment donné, c’est en particulier la caractéristique (en effet de bord) de la valeur de la preuve de travail accompli par les mineurs pour les blockchains dont le consensus décentralisé est de type preuve de travail (proof-of-work), de telle sorte que l’analyse du contenu du fichier produit :

- après la notarisation horodatée de son empreinte au moins dans ladite blockchain, une empreinte, typiquement selon la fonction de hachage SHA-256 (Secure Hash Algorithm sur 256 bits), étant univoquement liée à un fichier et un seul et sa notarisation constituant une preuve cryptographique de son existence avant la date de notarisation ;

- avec l'identification calculatoire du paramètre numérisé, typiquement, pour ce qui concerne la photographie, par toutes les techniques d'analyse d'images permettant d'identifier un objet et sa position dans son environnement, le paramètre étant la suite des coordonnées de la position de l'objet dans une série de photographies de cet objet; les photographies étant la numérisation d'un phénomène physique ondulatoire : la lumière, permet de recalculer et vérifier la valeur desdites consignes. Concernant la phase suivante de validation, le procédé est donc le suivant :

- à partir de l’analyse du fichier pour identification du paramètre à la valeur de la consigne fondée sur de l'aléa horodaté, on prouve que le fichier a été créer postérieurement à une date d1 donnée (par exemple avec l’empreinte courante d’un bloc de la blockchain) puisque la consigne est corrélée à une valeur publique, séquentiellement produite, notarisée, horodatée et surtout de nature aléatoire, et puisque les consignes ont été établies de façon à s'assurer qu'il n'existait aucune représentation numérique, telle que consignée (avec un niveau de certitude voulu),

- après le calcul de l'empreinte (valeur d'ancrage) du fichier et l'égalité constatée avec celle notarisée, on prouve son existence antérieurement à une date d2 qui est postérieure à la date d1, puisqu'une empreinte n'est cryptographiquement liée qu'à un seul fichier et que sa notarisation horodatée est postérieure à la date de sa création, on obtient alors l’horodatage absolu (résultat chiffré exprimé en unité de temps, chaque bloc étant de surcroît daté en temps universel), probant (que l’on peut prouver) et sans tiers de confiance (l’intégrité de la totalité des données manipulée est vérifiable), de l’intervalle de temps (entre d1 et d2) de la création dudit fichier. L’horodatage, en informatique, est le fait de lier une date et une heure précise par l’intermédiaire d’une horloge de référence à un évènement, une information ou une donnée informatique. Le fait d’horodater un document informatique confère à celui-ci une valeur probante. L’horodatage garantit l’existence et l’intégrité du document. Il est la preuve de la non-altération du document, du respect des délais légaux ou preuve d’antériorité, de l’opposabilité et de la traçabilité des actions menées sur le document. Dans l’état de l’art on distingue ici quatre cas :

- l’horodatation probante d’antériorité de la création d’un fichier (préexistence) avec un tiers de confiance,

- l’horodatation probante d’antériorité sans tiers de confiance,

- l’horodatation probante de postériorité (preuve de création après une date donnée) avec un tiers de confiance,

- l’horodatation probante de postériorité sans tiers de confiance.

Pour le premier cas, l’homme de l’art connaît les services proposés par les autorités d’horodatage. Elles relèvent par exemple en France du Référentiel Général de Sécurité (RGS) formalisé par l’Etat et doivent aujourd’hui être conformes au règlement européen n°910/2014 du 23 juillet 2014 dit elDAS (Electronic Identification and Signature). Ce règlement a pour ambition d'accroître la confiance dans les transactions électroniques au sein du marché intérieur européen : l'authentification et la signature électronique biométrique de l'invention le permet. Pour l’horodatage comme pour les signatures électroniques, la confiance est donc ici in fine apportée par le tiers étatique et ceux certifiés par lui. Ce qui est le cas général au niveau mondial. Cette intermédiation a un coût, tant financier qu’en terme de mode opératoire (processus d’horodatation, accessibilité et vérification des informations horodatées, conservation, maintient en conditions opérationnelles des installations,......).

Pour le deuxième cas, on exploite la nature des informations manipulées (écrites, lues, modifiées) dans une blockchain. Ce domaine technique étant nouveau, il est développé ci-après pour que l’auteur de la présente invention (qui exploite opérationnellement les blockchains, à titre personnel, depuis l’année 2014) et l’homme de l’art, partagent bien les mêmes références techniques, fonctionnelles et de vocabulaire car ce dernier n'est pas toujours stabilisé. On évoque de façon équivalente : les chaînes de blocs, les blockchains, voir les DLT (Distributed Ledger Technology). Le terme blockchain est généralement employé de façon générique et englobante en renvoyant aux technologies qu'elle met en œuvre. Ainsi, la blockchain réunie en particulier des procédés cryptographiques, des standards, des équipements informatiques, des logiciels, des modules, des librairies, des interfaces de programmation (API), la base de données « chaîne de blocs « proprement dite, des outils et environnements logiciels ouverts et publics (pour les blockchain ouvertes), .... La définition donnée par la chercheuse Primavera de Filippi est : une technologie qui permet à des individus ainsi qu'à des machines, de se coordonner et d'échanger de la valeur, de façon décentralisée et parfaitement sécurisé, sans passer par un intermédiaire de confiance. Une autre définition est : La blockchain est un registre actif, chronologique, distribué, vérifiable et protégé contre la falsification par un système de confiance répartie. L’aspect important est ici, outre la chronologie (l’horodatage) des blocs, l’absence de tiers de confiance. Le terme de notariser des données va être abondement employé, il va donc être ci-après abondement précisé. Notariser une donnée consiste à écrire dans une chaîne de blocs une information univoquement liées à ladite donnée. Ce lien univoque est généralement cryptographique. On peut distinguer trois types d’éléments : les références de notarisation, les données d’ancrage et les données notarisées. Les références de notarisation et l’ancrage sont les informations qui permettent de prouver que les données notarisées, par exemple un fichier, sont cryptographiquement et univoquement liées à la valeur d’ancrage. Les références de notarisation sont typiquement la chaîne de bloc exploitée, la référence (généralement l’empreinte) de la transaction de notarisation dans la chaîne de blocs exploitée et les traitements cryptographiques exploités pour calculer la valeur d’ancrage. La référence de la transaction apporte un horodatage car elle est univoquement associée à un bloc de la chaîne de blocs exploitée. De façon générale, une information écrite dans une chaîne de blocs hérite des propriétés que lui apporte la chaîne de blocs. Les propriétés que l'on retient ici, valables sans l'intervention d'un tiers de confiance, sont :

- un horodatage associé au bloc ou unité cryptographique (en référence aux blockchains structurées en graphe orienté acyclique (DAG : Directed Acyclic Graph) telles que Byteball ou IOTA ou aux futures blockchains dites Mimblewimble) dans laquelle elle est écrite,

- un caractère permanent (immuable, sécurisé, intègre),

- la capacité à être publiquement consultée sans tiers de confiance, à partir d’un client lourd ou léger ; sachant que la consultation publique est toujours possible, pour les blockchains publiques, avec un quelconque explorateur de blockchain donc via un tiers de confiance ;

- une référence qui est typiquement un numéro (une empreinte ou un hash) de transaction,

- le fait d’avoir fait l’objet d’un consensus décentralisé qui représente une source d’entropie publiquement partagée.

Il faut comprendre que le coût de stockage de l'information dans une blockchain est extrêmement élevé (par exemple plusieurs centaines de milliers de dollars par giga octets). Ce coût est élevé car la blockchain est volumineuse et maintenue à l'identique sur un grand nombre de serveurs (de nœuds) et parce que le mécanisme de consensus décentralisé est très onéreux en termes de puissance de calcul, du moins quand il s'agit de la preuve de travail. Donc, on ne notarise pas directement le fichier de l'invention mais son empreinte ou l'empreinte de son empreinte ou toutes autres formes de données d’ancrage. Ainsi, à titre d’exemple, l’auteur de la présente invention a, depuis 2014, opérationnellement exploité, à titre personnel, la notarisation de données selon trois modes (le 2ème et 3ème seront exploités dans l'invention) :

- de son contenu directement,

- de l'empreinte de son contenu,

- de l'empreinte de l'empreinte de son contenu.

Concernant le premier mode (notarisation de l'information elle-même), l’homme de l’art consultera cette transaction du 12 janvier 2015 sur la blockchain Bitcoin : 42e48044940601 c0ae56562d0884c667829bba734bf384251609fcb27102c534.

Elle contient dans sa partie donnée la chaîne de caractère BIENVENUE A LEANORE NE LE 9 JANVIER 2015 (40 octets maximum, il fallait sacrifier une lettre

I). En attendant un contradicteur, l’auteur de la présente invention (qui attendait sans doute un garçon I) prêtant être le premier à avoir gravé dans la blockchain l’événement de la naissance de sa fille pour en faire une citoyenne du monde. Pour ce premier mode, les références de notarisation sont la référence citée de la transaction et, associé, les références de la blockchain exploitée. L’ancrage et les données notarisées sont confondues.

Concernant le deuxième mode (notarisation de l'empreinte de l'information), l'auteur a développé un site Internet : lapreuve.net mis en ligne fin 2014. Il s’agit du premier site offrant cette fonctionnalité avec un paiement en monnaies fiat (euro). Le premier étant Proof of Existence” de Manuel Araoz en 2013 mais où il fallait (et il faut toujours) payer en Bitcoin avec la lourdeur associée pour s’en procurer. Aujourd’hui, beaucoup de société proposent ce service à grande échelle (Factom, Tierion, ..), le site lapreuve.net n'a donc plus de valeur ajoutée, au moins économique, et n’est actuellement pas actif. La mention du site « LaPreuve >> figure dans quelques publications scientifiques, par exemple An empirical analysis of Smart contracts: platforms, applications, and design patterns» et «An analysis of Bitcoin OP RETURN metadata” - de Massimo Bartoletti and Livio Pompianu - Universita degli Studi di Cagliari, Cagliari, Italy. Grâce au site lapreuve.net, le haché (SHA-256) d’un document est inséré dans la partie donnée d’une transaction (avec l’instruction OP_RETURN) Bitcoin. Il est précédé de la chaîne de caractère (tag) LaPreuve. Ainsi scellée, cette empreinte de 40 octets est visible de tous avec un explorateur de blockchains (blockchain.info, chain.so,..), comme cette transaction du 7 décembre 2014, sur la blockchain Bitcoin permet de l’illustrer :

485aec49540f7ab01 cd3a61282bd8be6d9517c351 e2dba474a68ba36317f37d2. Elle inclut LaPreuve/ce815a7f44bc33d7fcbd3f3e1 ad746ed0c651383572dc7b6d 2c87124529153da. La chaîne de caractères LaPreuve est décodée ASCII (American Standard Code for Information Interchange) soit LaPreuve = 4c61507265757665. Le haché de 256 bits notarisés est ce81...53da. Pour ce deuxième mode, les références de notarisation sont : la référence citée de la transaction, la référence de la blockchain exploitée, les références (SHA-256) des traitements permettant de produire l'empreinte du fichier et le tag LaPreuve qui renvoi à la fonctionnalité et l’intention. L’ancrage est la valeur de l’empreinte (ce81...53da). Les données notarisées sont le fichier dont la valeur de l’ancrage est l’empreinte.

Concernant le troisième mode (notarisation de l'empreinte de l'empreinte des données à notariser), on exploite typiquement la technique des arbres de Merkle. Une des feuilles est l'empreinte de l'information à notariser mais seule la racine de Merkle est écrite (gravée) dans la blockchain. Cette racine est la valeur d’ancrage. Par cette technique, on peut notariser autant de fichiers voulus, quelques soient leur volume et en une seule transaction dans la blockchain. Chaque fichier a sa propre feuille. Quand l’arbre de Merkle est constitué, on écrit la valeur de sa racine dans la blockchain. Les références de notarisation sont le numéro de la transaction, la blockchain exploitée, l'information selon laquelle c'est la technique des arbres de Merkle qui est exploitée, le chemin de Merkle de la feuille à juste avant la racine ainsi que les traitements de production des empreintes des feuilles. C'est typiquement ce que décrit le format ouvert Chainpoint (chainpoint.org). Les données notarisées sont chaque fichier dont l’empreinte est une feuille de Merkle. A noter que l’ancrage est typiquement un haché (ou condensé) de l'information mais il peut être toute données cryptographiques qui lui sont univoquement liée. Concernant les signatures numériques biométriques de la présente invention (développées plus loin), l’ancrage est la signature produite s’il s’agit de notariser l’acte de signature sur un document donné. L’ancrage peut aussi être la clé publique dérivée des identifiants de l’auteur du selfie, s’il s’agit de notariser une vidéo selfie horodatée de l’invention ; la vidéo produisant la clé privée. Les références de notarisation sont alors les informations permettant de prouver le lien cryptographique univoque avec les données notarisées. Sur ce troisième mode, l'homme de l'art consultera une des transactions du Smart Contrat sur la blockhain Ethereum dont la référence (l'empreinte) est donnée par la valeur 0x050726187780a34dDfF0e7D636dD3b0aEf23d962 développé par l'auteur. Par exemple la transaction dont la référence (l'empreinte) est donnée par la valeur : 0xfcb62c48f1 bb1 da194e0c87a88ecddd1 dae2f9f4ace11612a77f7c67f6a05b8c dans sa partie Event Logs. Le Smart Contract cité permet de vérifier (vérification cryptographique) et de notariser des signatures numériques valides ECDSA (Elliptic Curve Digital Signature Algorithm) sur la courbe elliptique secp256k1 avec un bi-clé dérivable BIP-0032. Le matériel cryptographique associé à chaque signature est notarisé dans les données d'historique (Event Log) ou fichiers Log. Ils ne font pas directement l'objet du consensus décentralisé (Proof-of-Work). Mais les Log sont référencés in fine par la racine de Merkle receiptsRoot contenu dans chaque bloc objet du consensus. De plus, les Log sont indexés avec un mécanisme de filtre de bloom avec la variable logsBIoom également présente dans chaque bloc. Pour des explications techniques exhaustives, l'homme de l'art se référera utilement au Yellow paper d'Ethereum : Ethereum: a secure decentralised generalised transaction ledger notamment dans sa partie 4.3. Il existe d'autre façon de notariser un contenu par l'empreinte de son empreinte. Une est exploitée dans l'invention avec un Smart Contract qui se déboucle sur réception d'une valeur attendue de valeur d'ancrage. Cette exploitation est identique à celle ayant permis aux 137 étudiants de l'université de Nicosie de certifier leur diplôme avec la blockchain. Le document de la liste des dipômés de l'université européenne de Nicosie (cf : http://digitalcurrency.s3.amazonaws.com/dfin511 -indexl -final.pdf) contient l'empreinte (SHA-256) du diplôme (format PDF) de chaque diplômé. L'empreinte (SHA-256) de cette liste des diplômés est égale à cette valeur 71 f8291827ae0806619cddbbd648d4b82ffb2115f5f0d0224e13ad3e7b06a32d.

Dans cette transaction du 29 décembre 2014 sur la blockchain Bitcoin : a3518d55d200f629dd85f89b657fb0d8e7ea9ad83e1 acde21278a778d607dac7, on lit, précédé du tag LaPreuve, la valeur de l'empreinte de ladite liste. Ainsi, chacun des étudiants lauréats peut désormais prouver à tout moment et auprès de n'importe quel interlocuteur partout dans le monde, l'authenticité de son diplôme. Il le fait en lui envoyant son diplôme (PDF) et les références sus-citées. Concernant les consensus décentralisés, ils sont actuellement majoritairement de type preuve de travail (Proof-of-Work) ou preuve de participation (Proof-ofStake). Des sites Internet de jeux de hasard en ligne fondé sur la blockchain exploitent typiquement la source d’entropie que représente le mécanisme de consensus. En effet, concernant les blockchains à preuve de travail, chaque bloc inclut une empreinte qui peut être considérée comme aléatoire puisque personne (aucun mineur) ne la connaît avant de l'avoir calculée et d'en être alors rémunéré s’il est le premier à l’avoir fait et l’avoir fait savoir au réseau. C'est le principe de la preuve de travail fondée sur le mécanisme hashcash proposé notamment par Adam Back en 1997. Ce mécanisme de production d’aléa, qui est un effet de bord du consensus décentralisé, est ici exploité comme source de hasard séquencé, horodaté, archivé et publiquement vérifiable. Il est exploité dans le cadre de l'invention car certes, il est perfectible, mais adaptés aux applications de l'invention et surtout, il ne nécessite pas l'intervention d'un tiers de confiance contrairement à l'état de l'art (NIST beacon, random.org, ..). L'homme de l'art se référera à la publication On Bitcoin as a public randomness source de Joseph

Bonneau, Jeremy Clark et Steven Goldfeder et concernant la perfectibilité, à la publication Trust, and public entropy: a unicorn hunt de Arjen K. Lenstra et Benjamin Wesolowski. A noter que l'entité demanderesse exploitant le procédé de l'invention peut toujours introduire plus d'entropie par ses propres moyens, par exemple en produisant un nonce cryptographique à exploiter par l’utilisateur pour la numérisation d’un objet. Pour exploiter l'invention sans tiers de confiance, on utilisera un client lourd ou un client léger. Le client lourd exploite la blockchain en la téléchargeant entièrement, ce qui est long à initialiser et volumineux à manipuler. Le principal intérêt est qu'il peut opérer sans tiers de confiance. Concernant le client léger, il ne nécessite lui aussi aucune confiance pour l’exploitation des procédés de l’invention, de la blockchain et le cas échéant des Smart Contracts de l'invention. Le client léger est exploité en connexion pair à pair, et grâce à un protocole spécifique, obtient des pairs des réponses cryptographiquement vérifiables. Les clients légers ne téléchargent pas la totalité de la blockchain contrairement au client lourd. De fait, ils ne disposent pas non plus de la totalité des fonctionnalités associées. Les clients légers téléchargent les entêtes de blocs et vérifient de petites portions de ce qui doit être vérifié pour l'usage considéré en utilisant une table de hachage distribuée. Il interagi avec la blockchain dans une version réduite mais intègre grâce à la technique des arbres de Merkle (Patricia Merkle Tree pour Ethereum, simple arbre de Merkle pour Bitcoin pour implémenter le Simplified Payment Vérification). Pour Ethereum, le client léger permet de charger des contrats, d’interagir avec eux sans avoir à réaliser une transaction payante si le résultat de l’exécution du contrat n’entraine pas de modification de l’état de la blockchain (dans les faits, il s’agit des appels aux contrats pour obtenir la valeur d’une des variables gérées dans son espace de stockage propre). Le client léger permet aussi d’accéder au « Log « intègres produits. Des clients légers pour ordinateurs et pour Ethereum sont notamment Geth ou Parity. Il en existe aussi pour smartphone comme Status. A l'issue de cette présentation des technologies liées aux blockchains, on a vu la façon avec laquelle on procède à l'horodatage probant d'antériorité sans tiers de confiance selon notre deuxième cas. On y procède selon les trois différents modes présentés : notarisation du contenu de l'information, de l'empreinte de son contenu ou de l'empreinte de l'empreinte de son contenu. Ces opérations peuvent s'effectuer sans interaction avec un tiers de confiance à l’aide d’un client lourd ou léger.

Pour le troisième cas d’horodatation de postériorité (preuve de création après une date donnée) avec un tiers de confiance, il consiste le plus simplement à faire appel à un tiers, par exemple un huissier de justice, certifié in fine par un Etat, qui fera en présence, état de la date de création d'un fichier numérisant un phénomène physique (photo, vidéo, audio, pollution, température,...). De façon plus élaborée, il peut s'agir d'un mécanisme à base d'horloge certifiée in fine par un Etat, qui procédé le moment venu à la production d'un fichier. C’est par exemple le cas des radars automatique le long des routes et autoroutes pour relever et verbaliser la vitesse excessive des véhicules assorti d’une photographie du véhicule. Pour ce troisième cas, on note que l'on ne dispose d'aucune information relative au fait que le fichier produit existait déjà ou n'existait pas.

Pour le dernier cas d’horodatation probante de postériorité sans tiers de confiance, une méthode connue de l'homme de l'art consiste le plus simplement, concernant la photographie, à prendre une photo incorporant un journal du jour. Les journaux papiers font ici office de dateur sans tiers de confiance unique. Les procédés d’horodatation probante de postériorité ne sont pas automatisée ; il faudrait qu’existe un archivage quotidien de tous les journaux du monde qui devrait cependant être officiel, s'il est centralisé, donc réintroduire un tiers. Accessoirement, la datation ne serait généralement qu’au jour près, et finalement, le contenu de telles photos reste falsifiable. Une solution nouvelle, exploitée au moins une fois, consiste à produire une preuve de vie photographique en faisant figurer dans la photographie un numéro de bloc d’une chaîne de blocs. C’est ce qu’a fait Vitalik Buterin, un des principaux inventeurs de la blockchain Ethereum. En juin 2017, des rumeurs le disaient décédé dans un accident de voiture. Cette rumeur risquait d’affecter gravement le cours de l’Ether et de ses développements. Vitalik Buterin a donc publié une photo avec un papier blanc dans sa main gauche. Sur ce papier est écrit Block 3,930,000 = 0xe2f1fc56da1d... L’homme de l’art, à partir d’un explorateur de la blockchain Ethereum, pourra constater que le bloc numéro 3930000 a bien pour empreinte (hash) les douze digits figurant sur la photo. Ce bloc est associé à la date « Jun25-2017 11:09:41 PM +UTC ». On notera qu’il est toujours possible de falsifier le contenu de la photo concernant les informations figurant sur le papier. Si l’on ne dispose pas du fichier photographique brut (raw), il faudra en particulier veiller à garder cohérent les coefficients de la table de quantification (la photo est au format JPEG) face au test « Error Level Analysis >> et accessoirement garder cohérentes les métadonnées. On notera aussi que cette technique, au demeurant non automatisée, ne donne aucun intervalle de temps mais simplement une date de postériorité mais aucune date d’antériorité : cette photo peut très bien avoir été prise (si elle n’a pas été falsifiée) entre le 26 juin 2017 et la veille de la date du jour où le lecteur, homme de l'art, est en train de lire ces lignes. On note pour finir, que frauduleuse ou non, cette photo peut toujours encore etre falsifiée car elle numérise un paramètre numérique qui est le numéro d'un bloc, donc in fine, rien ne permet de prouver que ce fichier était inexistant avant le 25 juin 2017, contrairement au procédé de l'invention car les consignes portent sur la numérisation d'un paramètre selon de l'information analogique avant la phase de conversion analogique/numérique, donc indépendant du contenu numérique informationel du fichier et dont on est absolument et mathématiquement certain qu'elle n'avaient pas d'existence ou de représentation numérique avant la date de leur numérisation.

Brève description des dessins et présentation des solutions de l'invention

D'autres caractéristiques et avantages de l'invention ressortiront de la description faite ci-dessous, notamment en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvu de tout caractère limitatif. Sur les figures :

- la figure 1 représente un smartphone, soit un capteur photographique et son écran de prévisualisation pour l'assistance à la création d'un fichier horodaté selon les consignes d'acquisition probantes de l'invention ;

- la figure 2 représente le procédé d'exploitation des consignes d'acquisition probantes avec l'aléa horodaté d'un bloc dateur (date initiale) d'une chaîne de bloc et la notarisation dans un bloc subséquent (date finale) du fichier des photographies obtenues ;

- la figure 3 représente le trajet consigné d'un drone pour la réalisation d'une vidéo à horodater selon l'invention, trajet élaboré avec l'aléa horodaté d'un bloc dateur ;

- la figure 4 représente le traitement (mesure) d'élaboration des consignes d'acquisition probantes normalisées qui visent à faire parcourir au drone un trajet entre un point de départ et un point d'arrivé malgré la valeur aléatoire horodatée du bloc dateur ;

- la figure 5 représente la valeur de l'aléa horodaté du bloc dateur et son application sur le trajet à effectuer par le drone ;

- la figure 6 représente l'analyse (méthode d'analyse d'image ASIFT) du fichier horodaté des photographies produites en vue de recalculer, après la notarisation dudit fichier, les consignes d'acquisition probantes ;

- les figures 7 et 8 représentent le même procédé que celui de la figure 2 :

• la figure 7 concerne la date initiale et représente la production d'une vidéo (image et son) selfie horodatée en vue d'une exploitation pour l'authentification ou la signature électronique biométrique ;

• la figure 8 concerne la date finale et représente différentes exploitations de la valeur d'ancrage de notarisation :

- pour la réalisation et l'archivage probant de signature biométrique,

- pour la signature biométrique selon la cryptographie asymétrique,

- pour la signature biométrique sans la cryptographie asymétrique,

- la figure 9 représente la production horodatée selon l'invention d'un fichier audio où les consignes d'acquisition probantes sont appliquées non pas sur la position spatiale du capteur comme dans les exemples précédents, mais sur les commandes du capteur d'ondes radioélectriques (récepteur FM) et en fonction de l'aléa horodaté d'un bloc dateur ;

- la figure 10 représente les valeurs numériques lors des différentes étapes de signature biométrique sur la blockchain Bitcoin,

- la figure 11 représente les valeurs numériques lors des différentes étapes finales de signature biométrique sur la blockchain Ethereum.

Les solutions de l'invention sont un procédé d’horodatation des bornes de l’intervalle de temps (dates de début 201, 501, 702, dates de fin 214, 716) de la numérisation dans un fichier (203 et 204, 601 et 602, 701,903) et par un capteur (111, 907), de phénomènes physiques (ondes électromagnétiques, ondes mécaniques, ..) caractérisé en ce que l’horodatation est absolue et probante sans tiers de confiance grâce à des consignes d’acquisition probantes (103 à 108, ou 301,401 à 404 ou 705 à 713 ou 904, 905) :

- fondées sur l’aléa horodaté (201, 501, 702) de blocs (209, 703) d’une chaîne de blocs (202, 714),

- définies selon la taille d'un hypothétique fichier existant qui les satisferait,

- appliquées avant la conversion analogique/numérique dudit capteur (111, 907),

- portant sur au moins un paramètre postérieurement identifiable (coordonnées 103,104,106,107, trajet 301, séquence temporelle 705 à 708, trajet 709 à 712, séquence de forme de signal radio 904 et 905) sur la base de références de notarisation (202, 210, 211 ou 714, 704, 811) dudit fichier, de ses valeurs d'ancrage (201 ou 501 ou 702; 205 ou 809) et de son contenu (203 et 204, 601 et 602, 701,903),

- définies, exploitées et validées en trois phases de définition, d'exploitation et de validation :

- en phase de définition, on défini les consignes comme élément de références de notarisation sous la forme d'une fonction mesurable de l'espace probabilisé des valeurs aléatoires des blocs dans l'espace mesuré des fichiers numérisant au moins un paramètre, on défini :

• la portée (orientation/localisation du capteur 111 ou commande sur le capteur 907) des consignes, • la nature dudit paramètre (position 103, 104; 106,107, trajet 301, séquence temporelle 705 à 708 ou séquence de forme de signal 904, 905,..) à numériser et le référentiel local associé (109, 202, 714, 901); ledit paramètre étant univoquement corrélée à la valeur de l'aléa horodaté (201, 501, 702) d'un bloc dateur (209, 703) d'une chaîne de bloc (202, 714), • les traitements d'assistance (105, 108, 110 ou 401 à 404 ou 705 à 708, 713) à la numérisation à l'adresse d'un opérateur ou des commandes dudit capteur,

- en phase d'exploitation, à l'aide d'un client lourd ou léger, on lit ladite valeur aléatoire horodatée (201, 501, 702) dudit bloc dateur (209, 703) et on élabore lesdites consignes (103 à 108, ou 301, 401 à 404 ou 705 à 713 ou 904, 905) telle que définies puis on les exploite lors d’une suite de numérisations (203, 204, 601, 602, 701, 903) assistées (105, 108, 110, 705 à 708, 713, 904, 905) avant la phase de conversion analogique/numérique du capteur (111,907) pour numériser ledit paramètre (103,104,106,107, 301, 705 à 708, 709 à 712, 904 et 905) et on notarise par une transaction (211, 811) le fichier obtenu (203 et

204, 601 et 602, 701, 903) avec une valeur d'ancrage (205, 809) écrite dans un bloc subséquent (210, 704) ;

- en phase de validation, on valide lesdites consignes en identifiant l'aléa (201, 501, 702) sur lequel elle sont fondées, par l’analyse numérique (603 à 606) appliquée sur le contenu dudit fichier (203 et 204, 601 et 602, 701,903) notarisé dans lequel on identifie ledit paramètre numérisé (103,104,106,107, 301, 705 à 708, 709 à 712, 904 et 905) pour établir que ledit fichier (203 et 204, 601 et 602, 701, 903) n'existait pas, selon le niveau de certitude choisi, avant la date initiale définie par ledit bloc dateur (201 ou 501 ou 702) et existait avant la date finale définie par ledit bloc subséquent (214 ou 716), lesdites dates initiale et finale horodatant de façon absolue le moment et la durée de la création dudit fichier (203 et 204, 601 et 602, 701,903).

Le procédé est aussi caractérisé en ce que lesdites trois phases comprennent chacune les étapes suivantes :

- en phase préalable de définition, on fixe les référentiels (109, 202, 714, 901) et les traitements (ex : 401 à 404) associés auxdites consignes (103 à 108, ou 301, 401 à 404 ou 705 à 713 ou 904, 905) selon la taille minimale, en bit d’information, que devrait avoir un fichier les satisfaisant :

• on sélectionne une chaîne de bloc (202, 714) pour laquelle d’une part la suite des références (201,214, 702, 716) des blocs (209, 210, 703, 704) est défini comme le référentiel temporel absolu et d’autre part dont l'aléa (201, 214, 501,702, 716) horodaté lié à la production desdits blocs est exploité comme source d'entropie ;

• on défini un système de coordonnées (109 ou 305 ou 901) dans un référentiel local qui est spatiale (109, 305) ou fréquentiel ou temporel (901) et dans lequel chaque groupe de bits d'information dudit aléa (201, 214, 501, 702) extrait est univoquement associé au paramètre à numériser (103,104,106,107, 301,705 à 708, 709 à 712, 904 et 905), • on élabore les données et les traitements de formatage permettant d’extraire et formater ledit aléa (201, 214, 501, 702) pour construire les consignes brutes (103, 104, 106, 107 ou 301 ou 709 à 712);

• on élabore les données et les traitements de normalisation permettant de normaliser (105, 108 ou 401 à 404 ou 705 à 708 et 713 ou 904, 905) leur application dans leur domaine d’application et selon leurs portées et la nature du paramètre à numériser (103,104,106,107, 301,705 à 708, 709 à 712, 904 et 905), • on élabore les traitements d'assistance à la numérisation selon la portée desdites consignes (103 à 108 ou 301,401 à 404 ou 705 à 713 ou 904, 905):

- soit sur la localisation spatiale (incrustations 105, 108, 110, 713) ou temporelle (705 à 708) du capteur (111);

- soit sur la commande (904, 905) du capteur (907) ;

- en phase d’exploitation, on élabore et on applique lesdites consignes probatoires (103 à 108, ou 301, 401 à 404 ou 705 à 713 ou 904, 905) d'horodatation de l'intervalle de temps de création dudit fichier (203 et 204, 601 et 602, 701,903) :

• on lit dans le bloc courant dateur (209, 703) : d’une part la valeur fournie (201, 501, 702) par ladite source d'entropie et d’autre part sa référence (201, 501, 702) qui définit la date de début, ces valeurs (201, 501, 702), éventuellement identique, peuvent être acquises sans tiers de confiance à l’aide d’un client lourd ou léger, pour en garantir l'intégrité;

• on calcul et on formate, grâce auxdits traitements de formatage et de normalisation, lesdites consignes brutes (103, 104, 106, 107 ou 301 ou 709 à 712) en les corrélant à ladite valeur fournie (201 ou 501 ou 702), puis on les normalise en les affectant à la position spatiale (105, 108 ou 401 à 404), fréquentielle, temporelle (705 à 708) ou aux commandes (904, 905) du capteur (111,907) numérisant ledit paramètre (103,104,106,107, 301, 705 à 708, 709 à 712, 904 et 905) dans ledit système de coordonnées (109 ou 305 ou 901), • on procède à une suite de numérisation (203, 204 ou 601, 602 ou 701 ou 903) assistée (incrustations 105, 108, 110 ou 705, 706, 707, 708, 713) par ledit traitement d'assistance et conformément auxdites consignes (103 à 108, ou 301,401 à 404 ou 705 à 713 ou 904, 905) pour obtenir ledit fichier (203 et 204 ou 601 et 602 ou 701 ou 903), • on calcule une valeur d’ancrage (205 ou 809) dudit fichier (203 et 204 ou 701 ) selon une seule (212, 808) ou plusieurs (1001, 1005, 1007, 1009, 1011, 1013 ou 1001, 1003, 1005, 1007, 1009, 1011, 1013, 1014) fonctions cryptographiques lorsqu’une fonctionnalité additionnelle est associée à ladite valeur d’ancrage (809) ;

• on génère au moins une transaction de notarisation (211, 811) dudit fichier (203 et 204, 701) dans un bloc subséquent (210, 704) audit bloc dateur (209, 703), la référence (214, 716) dudit bloc subséquent (210, 704) définit la date de fin, • on génère les références de notarisation qui inclut au moins la référence de la transaction (211,811) de notarisation, une référence (213, 718) audit bloc dateur (209, 703) étant liée à ladite transaction de notarisation (211,811) ;

- en phase de validation de l’intervalle de temps horodaté on authentifie, sans aucun tiers de confiance, lesdites consignes probantes (103 à 108, ou 301,401 à 404 ou 705 à 713 ou 904, 905) sur la base dudit fichier (203 et 204, 601 et 602, 701,903) et desdites références de notarisation :

• on vérifie l’intégrité du contenu des blocs dateurs (209, 501, 703) et subséquents (210, 704) en mettant en œuvre un client lourd ou un client léger pour accéder à ladite blockchain (202 ou 714) ;

• on vérifie l’intégrité dudit fichier (203 et 204, 601 et 602, 701, 903) sur la base de son contenu, en relançant les calculs d’obtention de la valeur d’ancrage (205 ou 809) puis en la comparant avec celle enregistrée (205 ou 809) dans la blockchain (202, 714) ;

• on relève l’horodatage de l’intervalle de temps de création (209 à 214 ou 702 à 716) dudit fichier (203 et 204, 701) dans lesdits blocs dateurs (209, 703) et subséquents (210, 704) et on lit la valeur de l'aléa fournie (201,501,702), • on recalcule, grâce auxdits traitements de formatage et de normalisation, lesdites consignes (103 à 108, ou 301,401 à 404 ou 705 à 713 ou 904, 905) d’acquisition sur la base de ladite valeur d'aléa fournie (201, 501, 702), • on vérifie, à l’aide de toutes analyses numériques pertinentes de l'état de l'art, que ledit paramètre est numérisé (103,104,106,107, 301, 705 à 708, 709 à 712, 904 et 905) selon lesdites consignes normalisées (103 à 108, ou 301,401 à 404 ou 705 à 713 ou 904, 905) et selon ledit référentiel local (109 ou 305 ou 901) dans chaque élément de ladite suite (203, 204 ou 601, 602 ou 701 ou 903) de numérisation, • on valide, à l’issue des vérifications conformes précédentes que ledit objet (101, 603, 604, 715, 903) a été pour la première fois numérisé dans ledit fichier (203 et 204, 601 et 602, 701, 903) dans l'intervalle de temps borné défini comme :

- postérieur à ladite date absolue de début (201, 501, 702), dudit bloc dateur (209, 703), ledit fichier étant antérieurement inexistant;

- antérieur à ladite date absolue de fin (214, 716) dudit bloc subséquent (210, 704).

Le procédé permet l'horodatation d'une unique photographie d'un objet. Le niveau de confiance pour ce cas particulier est développé et chiffré plus loin. Le procédé est alors caractérisé en ce qu’il est mis en œuvre avec une suite d’au moins une seule numérisation (203), dans le domaine de la photographie numérique exploitant les capacités calculatoires et les performances des capteurs (111) photographiques des équipements informatiques mobiles (smartphones, Tablette,..) et l’état de l’art en matière de traitement d’image, pour la prise de vue assistée d’un objet identifiable (101) selon ces contenus d’étapes: - en phase de définition :

• on définit l'empreinte des blocs (201,214) d'une chaîne de bloc choisie (202) à la fois comme référentiel temporel absolu et comme source d'entropie, ces empreintes sont univoquement liée à une date exprimée en temps universel, • on définit comme référentiel local spatiale : la photographie (203) incluant l’objet (101) dans son environnement (206) et le système de coordonnées (109) en deux dimensions est donné par la définition de la photographie à produire (203), • on élabore le traitement de formatage des consignes brutes d'acquisition avec l'affectation des bits d'information du bloc dateur (201) aux coordonnées (103, 104) d’un cadre de consigne (105) dans lequel doit figurer l’objet (101) dans une (distance) proportion (108) minimale indiquée; les consignes brutes, pour une même surface dudit cadre (105), peuvent s'étendre à sa forme et son orientation;

• on élabore le traitement de normalisation des consignes d'acquisition en fixant les dimensions dudit cadre (105) et dudit cercle (108) de proportion en cohérence avec le niveau de certitude souhaitée de non préexistence du contenu de la photographie à produire selon l’état de l’art en matière de traitement d’image et de capacité des capteurs (111) photographique, • on élabore le traitement d'assistance à la numérisation avec la fonctionnalité d'incrustation dans l'écran de prévisualisation dudit terminal (111) : dudit cadre (105) de consigne, de son cercle de proportion (108) et d'une croix de centrage (110);

- en phase d'exploitation :

• on lit dans le bloc courant dateur (209), la valeur d'aléa fournie (201) par la source d'entropie qui est sa référence (201) et la date de début, • on élabore, grâce auxdits traitements de formatage et de normalisation, à l’aide de bits d’information de la valeur de l’empreinte (201) du bloc dateur (209) lu, la consigne brute d’acquisition (103, 104) affectée prioritairement aux coordonnées du cadre de consigne (105) associée à une proportion (108) applicables à la représentation numérique de l’objet (101) dans ledit système de coordonnées (109), • on procède à la numérisation (203) assistée (incrustations 105, 108, 110) conformément auxdites consignes (103, 104, 105, 108) pour obtenir ledit fichier (203), le rectangle de consigne est dessiné dans la photographie (203) obtenue ainsi qu’une zone d’information contenant des références (213) telles qu’un code matriciel encodant un lien hypertexte et/ou des références (213) relatives au présent procédé, notamment celle dudit bloc dateur (213);

• on calcule une valeur d’ancrage (205) dudit fichier (203) avec au moins la valeur produite par une fonction de hachage (212);

• on génère au moins une transaction de notarisation (211) dudit fichier (203) dans un bloc subséquent (210) audit bloc dateur (209), la référence (214) dudit bloc subséquent (210) définit la date de fin ;

• on génère les références de notarisation qui inclut au moins la référence de la transaction (211) de notarisation et la blockchain exploitée (202);

- en phase de validation :

• on vérifie l’intégrité du contenu dudit bloc dateur (209) et subséquents (210) à l'aide d'un client lourd ou d'un client léger ;

• on vérifie l’intégrité dudit fichier (203) sur la base de son contenu, en relançant les calculs d’obtention de la valeur d’ancrage (205) puis en la comparant avec celle enregistrée (205) dans la blockchain (202) ;

• on relève l’horodatage de l’intervalle de temps de création (201 à 214) dudit fichier (203) dans ledit bloc dateur (209) et subséquent (210) et on lit la valeur de l'aléa fournie (201 ), • on recalcule, grâce auxdits traitements de formatage et de normalisation, lesdites consignes (103, 104, 105, 108) d’acquisition sur la base de ladite valeur d'aléa fournie (201 ), • on identifie, à l’aide de programme informatique implémentant toutes techniques d’imagerie pertinentes de l'état de l'art, ledit objet (101) dans ladite photographie (203), • on vérifie dans la photographie (203) qu'au moins les coordonnées (103, 104) du cadre de consigne (105) sont conformes et que la représentation numérique de l’objet (101) y est normalisée (105, 108), l'ensemble selon les consignes calculées (103, 104, 105, 108), • on valide, les vérifications précédentes étant conformes, que l'objet (101) a été numérisé pour la première fois dans un intervalle de temps borné :

- postérieur à ladite date absolue de début (201) dudit bloc dateur (209) ,

- antérieur à ladite date absolue de fin (214) dudit bloc subséquent (210) .

Le procédé permet l'horodatation de plusieurs photographies du même objet pour accroître jusqu'à 100% le niveau de certitude de l'inexistence préalable du fichier (des photos produites) résultant. Le procédé est alors caractérisé en ce que ladite suite est étendue à plusieurs numérisations (601, 602) avec les contenus d'étapes complémentaires suivant :

- en phase de définition :

• on définit des contraintes de forme et de surface minimale pour la zone de recouvrement entre deux photos successives (203, 204 ou 601,602), • on définit une valeur minimale de distance entre les positions successives du cadres de consigne (105) dans le référentiel local (109) de façon à ce que le contenu (203, 204, 601, 602, 603, 604) des fichiers à produire soit identifiable par référence interne entre deux contenus distincts :

- le contenu de deux cadres de consigne, soit l’objet numérisé (603) dans le cadre de consigne d'un fichier (601) et une autre représentation numérique du même objet (604) dans le cadre de consigne d'un autre fichier (602),

- le contenu d'un cadre de consigne d'une photographie avec le contenu d'une photographie complète, soit l’objet (604) dans le cadre de consigne d'une photographie (602) représenté dans une autre photographie complète (601) au sein de son environnement (605),

- le contenu de deux photographie complète, soit l'objet (603, 604) et la zone de recouvrement (606) entre une photographie complète (601) et une autre photographie complète (602), • on élabore, pour chaque numérisation supplémentaire (204, 602), une consigne d’acquisition dédiée pour laquelle on extrait des bits d’information complémentaires de l’empreinte (201) dudit bloc dateur (209),

- en phase d'exploitation :

• l’assistance informatique peut être étendue à la prise de vue (204, 602) automatique grâce à un programme de reconnaissance d’image (image matching) dont la référence est le contenu numérisée de l'objet (101, 603) et/ou son environnement (206, 605) dans au moins l'un des cadres de consignes ou photographies (203, 601) précédents;

- en phase de validation :

• on identifie ledit objet sur les prises de vues successives (203, 204 ou 603, 604) à l’aide d’au moins un traitement de comparaison et de reconnaissance d’image (librairies OpenCV, ORB, ASIFT, SURF,..), ce traitement est étendue aux zones de recouvrement (605) et au calcul de la distance entre les cadres de consigne, • on valide l’horodatage lorsque l’analyse des photographies (203, 204 ou 601, 602) donne un nombre d’appariement (matches) dans des bornes minimales (de similarité) et maximales (d'identité), il est alors établi qu’elles (203, 204 ou 601, 602) ont été créés postérieurement à la date donnée (201) par ledit bloc dateur (209) de numérisation et antérieurement à la date donnée (214) par ledit bloc subséquent (210) de notarisation.

Le procédé permet l'horodatation d'une vidéo. Le procédé est alors caractérisé en ce que ladite suite de consignes s’appliquent à l’acquisition d'un vidéographie horodatée d’un objet/sujet pour lequel on élabore, à l’aide des bits d’information de l'aléa horodaté extrait (501 ou 702) d’un bloc dateur, des consignes d’acquisition selon les contenus complémentaires d'étape suivants :

- en phase d'exploitation, on élabore une série de positions (301) ou d'angle de prise de vue (709, 710 et 711,712) du capteur, série définie dans un système de coordonnées (109 ou 305) du référentiel local associé ;

- en phase de validation, les vecteurs de mouvement extraits de la vidéo produite sont avantageusement exploités pour valider la conformité de ladite série de consignes (301 ou 709, 710 et 711,712).

Le procédé permet l'horodatation d'un capteur en mouvement en consignant son déplacement. Le procédé est alors caractérisé en ce qu’il est mis en œuvre pour la réalisation de vidéo horodatée à partir d'un capteur en déplacement autonome (drone,...) pour lequel, en phase de définition, le parcours (301) est défini de telle sorte que l'aléa horodaté extrait (501) soit traité pour que le trajet (301) soit parcouru entre au moins un point de départ (302) et un point d'arrivé (303) dans une zone (304) à vidéographier couverte par un système de coordonnées (305) et dans laquelle est défini des sous-ensembles (bords 306 et 307, surfaces 308 et 309) respectivement chacun associé à une règle de déplacement (401, 404, 402, 403) permettant de fixer les probabilités du déplacement du capteur vers un point fixé, typiquement sur la ligne médiane (310) joignant le point de départ (302) et le point d'arrivé (303).

Le procédé permet l'horodation d'un fichier audio. Le procédé est alors caractérisé en ce que ladite suite de consignes s’appliquent à l’acquisition d'un fichier audio pour lequel on définit, exploite et valide une séquence temporelle (705 à 708 ou 904, 905) ou fréquentielle portant sur la nature et/ou la forme (904, 905) et/ou le contenu informationnel dont le support analogique est typiquement :

- des ondes radioélectriques de signaux (902) radiodiffusés,

- des ondes mécaniques sonores, préférentiellement vocalisées.

Le procédé permet l'horodatation d'un fichier audio en exploitant les performances des smartphones pour la phase d'assistance. Le procédé est alors caractérisé en ce qu’il est mis en œuvre pour la réalisation assistée d'un fichier audio horodaté grâce au microphone et à l'écran de visualisation d'un équipement informatique mobile (smartphone) et pour lequel, en étape de numérisation : on consigne une séquence audio temporelle sur l'acquisition du contenu informationnel d'ondes sonores vocalisées par l'utilisateur dudit équipement mobile, d'une suite de digits d'information quelconque (705, 706, 707, 708) pour lesquels l'assistance consiste en un marquage (masquage/démasquage, soulignement, colorisation,.....) temporalisé desdits digits, selon des écarts de temps corrélés aux valeurs de l'aléa extrait (702) du bloc dateur (703) de la chaîne de blocs (714).

Le procédé permet l'horodatation de fichier biométrique. Le procédé est alors caractérisé en ce qu’il est mis en œuvre pour créer un fichier (701) biométrique (selfie) horodaté d'authentification biométrique et/ou de signature électronique biométrique pour lequel une empreinte (805 ou 806 ou 812 ou 1002 ou 1008 ou 1012) est exploitée comme valeur d’ancrage (809) d’un certificat autoproduit :

- pour l’authentification biométrique (1002),

- pour la signature électronique biométrique en cryptographie asymétrique avec la clé publique (806) et/ou la clé privée (1008, 1012) associée(s) et/ou le condensât de signature (805) produit ;

- pour la signature électronique biométrique sans cryptographie asymétrique (812) ;

Le procédé exploite l’horodatation absolue qu'il permet avec des fonctionnalités étendues grâce aux contrats intelligents (Smart Contract). Le mode de notarisation est celui de l'empreinte de l'empreinte de contenu tel qu'expliqué plus haut avec la certification des diplômes. Le procédé est alors caractérisé en ce qu'en plus, en phase d'exploitation, en début de l'étape de génération de ladite transaction de notarisation (211,811):

• on calcul une valeur d'ancrage (205, 809) permettant de déboucler un contrat intelligent (Smart Contract), cette valeur d'ancrage de débouclage (205, 809) est typiquement celle d'un document (contrat d'assurance, contrat d'achat/service, ...) incluant l'empreinte dudit fichier (203 et 204, 601 et 602, 701,903) ;

• on produit et on implémente ledit contrat intelligent dans la blockchain exploitée, on génère ladite transaction de notarisation (211, 811) qui déboucle ledit contrat intelligent uniquement si la valeur d'ancrage (205, 809) est égale à la ladite valeur de débouclage précédemment calculée. Ce débouclage permet tout à la fois et au moins : la signature d'un contrat entre des parties, l’horodatage et l'archivage probant d'un document contractuel sans aucune infrastructure dédiée et l’horodatage probant d'un fichier selon l'invention.

Ilustrations des solutions par des exemples et les figures, autour des propriétés des consignes d'acquisition probantes de l'invention

On détaille ci-après le périmètre de l'invention, en précisant les caractéristiques (propiétés/natures/champ d'application) des consignes d'acquisition (consignes).

Ces caractéristiques sont ensuite exemplifiées et pour la première et les pour les trois dernières, illustrées par les figures citées. Les consignes comprennent au moins les caractéristiques suivantes :

- premièrement, il est toujours possible de donner une suite de consignes qui permettent d'avoir la garanti, avec un niveau de certitude aussi élevé que l'on veut, qu'il ne préexiste aucune représentation numérique telle que consignée, de la ou des grandeurs analogiques identifiables pour lesquelles on veut horodater la création d'un fichier ; cette première caractéristique importante sera longuement développée ;

- deuxièmement, les consignes peuvent s’étendre au-delà de l'étape de conversion analogique/numérique mais dans des conditions qui permettent de s’assurer de l’inexistence préalable (ou du niveau de certitude choisi de cette inexistence) du fichier obtenu ;

- troisièmement, une consigne peut porter sur l'acquisition d'informations numériques, et non analogique, mais à la condition que ces informations numériques possèdent une nature aléatoire et que l'on peut démontrer l’inexistence préalable du fichier ainsi obtenu ;

- quatrièmement, en plus de l'aléa fourni par une chaîne de bloc, une consigne peut être élaborée avec une valeur numérique connue (non aléatoire) à la condition qu'elle soit notarisée, avant ou après la production du fichier à horodater, la date de début reste celle liée au bloc ayant fourni l’aléa ;

- cinquièmement, en plus de l'aléa fourni par une chaîne de bloc, une consigne peut être élaborée avec la valeur numérique d'une acquisition analogique si on peut garantir l’absence de représentation numérique préalable du fichier résultant;

- sixièmement, une suite de consigne, comme une seule d'entre elles, peut porter sur une seule ou plusieurs grandeurs physiques. Les grandeurs physiques sont typiquement associées à un transfert d’énergie (ondes électromagnétique, onde mécaniques, ...). Les domaines sont non limitativement : la cinématique, la thermodynamique, la mécanique statistique, l'électromagnétisme, l'optique,...

- septièmement, au-delà de l'environnement du capteur (position spatiale, temporelle, une consigne peut adresser une commande directement sur l'une ou plusieurs des caractéristiques d'un capteur telle que non limitativement : son étendue de mesure, sa sensibilité, sa résolution, sa précision, ses linéarités et non linéarités, sa rapidité, sa bande passante, ses hystérésis, .... L’essentiel étant qu’une telle commande modifie les caractéristiques du capteur avant la phase de conversion analogique/numérique.

Pour exemplifier la première caractéristique, dans tous les domaines de l'invention, comme ci-après dans le domaine de la photographie, il est toujours possible, en phase de définition du présent procédé, d'imposer une suite de consignes telles qu'aucune photo préexistante, aussi gigantesque soit sa définition et quel que soit le nombre de photos prises de la même scène, ne permettent à un traitement informatique de frauduleusement horodater la création. De façon générale, la quantité d'information d'une grandeur analogique (ici ondes électromagnétiques dans le spectre visible) représentative d'un objet dans son environnement est infini. Sur ces bases, le volume en octets de toutes les représentations numériques dudit objet identifiable dans son environnement, produit par les capteurs de l’état de l’art, est, sinon infini, au moins non stockable et inaccessible à tout traitement. Il est donc toujours possible de définir une suite de consigne qui garantissent avec un niveau de certitude souhaité, qu'il ne préexiste pas de représentation numérique dont on pourrait postérieurement horodater la création selon l’invention. Ce niveau de certitude est formellement la quantité minimale d’information (en bits d’information) d’un fichier préexistant qui satisferait de façon certaine et selon l’état de l’art, les consignes d’acquisition portant sur la production du fichier sur la base duquel l'objet numérisé est identifiable dans son environnement. Les consignes sont dans cet exemple, illustrées sur les figures 1,2 et 6. Pour les numéros de référence des figures, la valeur des centaines indiquent le numéro de figure. Sur la figure 1, les consignes sont une suite de positions distinctes (103, 104 et 106, 107) de l'objet (101) à l'intérieur d'un cadre de consignes (105) dans la photographie à produire. Ce cadre de consigne (105) est dessiné en incrustation dans un écran de prévisualisation et a une position dans le référentiel donnée par la définition de la photographie (203, 204, 601, 602). L’objet est un pot avec sa plante (101, 603 et 604). Il est photographié dans un cadre un consigne (105) de 640 pixels par 480 pixels au sein de photos (203, 204, 601, 602) d'une définition, par exemple imposée, de 9,59 Mpx (méga pixels) au moins, soit 4128 pixels sur 2322 pixels. La dimension du cadre de consigne (105) est donnée suffisante pour identifier l'état de l'objet (101,603, 604) pour les usages considérés. Elle peut être accrue.

Les photos (203, 204, 601, 602) sont prises du même endroit mais de fait avec des angles de vues chacun légèrement différents. Ces consignes sont associées à une distance du capteur (111 dans le smartphone) et une orientation du capteur (111) constituée de deux angles en coordonnées sphériques. On ne précise pas de convention de coordonnées sphériques mais on considère une sphère autour de l’objet (101) à photographier qui en occupe le centre et un point sur la sphère où se situe le capteur photographique (capteur du smartphone

111). La distance est le rayon de la sphère. Les orientations sont toutes les droites dans le plan tangent à la sphère au niveau dudit point. Les angles de prise de vue sont toutes les droites sécantes qui passe par ledit point. Ainsi, la photo de définition gigantesque existerait en fichier brut (raw : non comprimé) qu'elle ne représenterait pas ces différents angles de prise vues. Même si ces derniers étaient indétectables (non pris en compte) dans le cadre de l'invention, la suite de consignes (103, 104, 105, 106, 107, 108) pourrait toujours être allongée (le cas échéant avec l'aléa de plusieurs blocs et dans plusieurs blockchains) et la définition de 9,59 Mpx augmentée de telle sorte qu'une potentielle action frauduleuse nécessiterait une définition hors de portée de l'état de l'art et même des capacités de stockage de l'univers ! C'est ce que nous allons démontrer, plutôt empiriquement illustrer avec la finalité première de décrire le procédé de l'invention. On évoque les capacités de stockage car si les hypothétiques photos frauduleuses existent déjà alors elles doivent être stockées quelque part. On se base sur les meilleures performances de l'état de l'art en matière de stockage et les performances standards en matière de reconnaissance d'image et de capacité des smartphones. Concernant le stockage, il est estimé (étude du cabinet d'analyste IDC) que la capacité totale de stockage en 2017 est de 7,235 zettaoctets, soit 5,788 * 10²² bits d'information. Concernant les smartphones, on retient une définition moyenne de 9,59 mégapixels. Concernant l’analyse (ici la comparaison) d’image, on prend les performances de l’état de l’art avec la méthode ASIFT (Affine-Scale-Invariant Feature Transform). ASIFT a l’intérêt d’être plus performante que la méthode SIFT (Scale-lnvariant Feature Transform) dans la mesure où en plus d’être invariante au zoom, à la rotation et à la translation, elle est aussi invariante à l’inclinaison (jusqu'à 80 degrés !). Pour la mise en œuvre, ASIFT requière plus de ressource de calcul mais dans le cadre de l'invention il n'y a pas de contraintes matérielles ou de temps réel sur des analyses effectuées après l'horodatation. ASIFT a été introduit en 2009 par J-M. Morel and G. Yu. L’homme de l’art se référera au document J-M. Morel and G. Yu. : Asift : A new framework for fully affine invariant image comparaison. II existe beaucoup d’autres méthodes d’analyse d’image. Elles reposent sur la description locale basées sur les points d’intérêt avec deux outils étroitement liés : les détecteurs et les descripteurs. Leur utilisation combinée permet d’obtenir une description robuste des images permettant d’identifier des points d’intérêt identiques dans des images décrivant une même scène ou un même objet ayant subi diverses transformations. Ici les scènes sont les zones de recouvrement entre au moins deux photos (203, 204 et 601, 602) et l’objet qui est le pot (101, 603, 604). On dit alors que les détecteurs et les descripteurs possèdent des propriétés d’invariance à ces transformations. Les transformations peuvent être de différentes natures : géométriques, photométriques, colorimétriques ou encore au bruit. Hormis SIFT et ASIFT, ces méthodes sont par exemple SURF (Speeded-Up Robust Features), CSIFT (Color-SIFT), ORB (Oriented FAST and Rotated BRIEF). Cette dernière, très performante, est intéressante pour l’implémentation de l’invention avec les librairies graphiques libres OpenCV (pour Open Computer Vision). Les librairies OpenCV sont même exploitées par de nombreuses applications (disponibles sur les stores) pour smartphone, applications mise au point et produites dans des environnements de développement opérationnels et ouvert. L'homme de l'art dispose ainsi de toutes les informations nécessaires à l'implémentation de l'invention. On prend donc deux photos (203, 204 et 601,602) de l'objet (101) qui est un pot (603 et 604). Selon l'invention, l'objet (101) doit figurer dans un cadre de consigne (105). II doit y figurer selon une proportion/une distance recommandée ou consignée pour laquelle une assistance visuelle est apportée avec l'incrustation dans l'écran de prévisualisation du smartphone du cercle 108. L'assistance visuelle est aussi le dessin incrusté du cadre de consigne (105) ainsi que d'une croix de centrage (110). La taille de l'objet (101) numérisé doit ainsi être, quel que soit l’orientation, d'un diamètre dudit cercle (108). A l'aide de la méthode ASIFT, il est comparé deux représentations numériques :

- la représentation numérique 604 du pot dans son cadre de consigne et extrait de la photographie 602 : c'est la photo en bas à gauche de la figure 6,

- la photo 601 dans son ensemble dans laquelle est inclut l'autre représentation numérique (603) du même pot : c'est la photo en haut à gauche de la figure 6.

Les deux photos sont présentées l'une au-dessus de l'autre à gauche dans la figure 6. Les segments de droite de couleur blanche dans les photos de la figure 6 représentent l’appariement (matches) donnés par ASIFT des points d’intérêts entre les deux photos différentes. L'analyse ASIFT trouve 60514 points d'intérêt (keypoints) dans la photo 601 et 55203 dans l'autre. En résultat de l'analyse, 359 de ces points d'intérêt sont appariés (mises en correspondance) l'un à l'autre avec la méthode ASIFT alors que seulement 16 le sont avec la méthode SIFT. Une performance remarquable est qu'aucun des points d’intérêt de la photo restreinte (604) au cadre de consigne (en bas) n'est apparié avec un point d'intérêt de la photo 601 dans son ensemble en dehors de la zone (le cadre de consigne 105) où figure le pot 603. On déduit de cette expérimentation que selon l'état standard de l'art, un objet (101) dans un cadre de consigne (105) de 640 pixels sur 480 pixels est identifiable dans une photo d'ensemble de 9,59 méga pixels et avec une précision de l'ordre du pixel. En effet, la position calculée du cadre de consigne (105) dans la photo 601 se déduit des 359 appariements. Bien évidemment, un opérateur humain ne peut pas avoir la précision de placer ainsi un objet (101) dans un cadre de consigne (105) avec une précision, d'asservissement manuelle, de l'ordre du pixel. Cependant, on peut apporter une assistance consistant, après la prise d'une première photo (601) de référence selon la consigne, d'automatiser la prise des photos suivantes (602) dès que l'objet (603) est détecté dans le cadre de consigne suivant dans l'écran de prévisualisation. La référence est le contenu (603) du cadre de consigne (105) de la première photo 601 prise. On a évoqué que les librairies openCV sont implémentées sur smartphone. Cependant, pour des contraintes de calcul en temps réel sur des smartphones qui seraient très restreint en ressource, on peut exploiter la technique plus basique des empreintes perceptuelles (perceptual hashing) telles que pHash, dHash, aHash,.. Sur ces bases et sachant que ('essentielles des photos sont dans un format JPEG (Joint Photographie Experts Group) qui traite selon des matrices (MCU : Minimum Coded Unit) de 8 pixels sur 8 pixels, c'est la définition (l’unité) minimale que l'on retient. Dans notre exemple de cadre de consigne (105) de 640 pixels par 480 pixels au sein d'une photo (203, 204, 601, 602) d'une définition de 9,59 Mpx, le nombre de positions distinctes du cadre de consigne (105), avec une précision de 8 pixels, est de (4128-640)/8*(2322-480)/8=100280 (0x187B8 en hexadécimal) soit environ 10⁵ en décimal. Soit une consigne de position (103, 104 ou 106, 107) du cadre (105) qui n'occupe que 17 bits : 9 bits pour les abscisses 104 et 107, entre 0x000 et 0x1 B4 et 8 bits pour les ordonnées 103 et 106, entre 0x00 et 0xE6. Formulé autrement, une consigne d’à peine plus de 2 octets (17 bits) impose la préexistence frauduleuse de cent mille photos différentes d'un objet (101) identifiable ; sachant que les photos de l’objet (101) ne sont prises qu'à partir d’une seule position fixe du capteur. Le poids moyen d’une photo de 9,59 Mpx en format JPEG, sur la base d'un taux de compression de 75%, est de 57511296 bits (4128*2322*24/4). Formulé encore autrement, 1 bit de consigne brute annihile la préexistence (le stockage) de 5767232762880 bits d'information (57511296 bits par photo * 100280 photos / 17 bits de consigne) d'un fichier numérisant un objet identifiable dans son environnement, soit une différence de douze ordres de grandeur. On note que le procédé requiert une zone de recouvrement entre deux photos. Selon la taille de cette zone, le nombre de position distinctes (100280) du cadre (105) est un peu moins élevée. Le procédé n’est pas limité en nombre de positions différentes, ni relativement à l'exigence de la définition des photos. On se centre donc plus sur le principe et on retient dans cet exemple que 1 bit de consigne brute chiffre un niveau de certitude de non préexistence à 10 ordres de grandeur : 10¹⁰. Ce postulat n'est bien sûr valable que pour le cas de l'espèce. On évoque une consigne brute et pas une consigne normalisée. Une consigne est normalisée selon le domaine ou est appliqué l'invention. Les données jointes aux consignes brutes ne sont pas aléatoires et ne sont pas extraites d'une blockchain. Les informations de normalisation ont pour but d'assurer la correspondance univoque, selon le domaine, entre l'aléa exploité et le contenu des fichiers à produire. Dans cet exemple, il s'agit des informations complémentaires de taille (640*480) de cadre de consigne (105), de la distance de l'objet (108), d’une suite standard de coordonnées sphériques de position, d’orientation et d’angle de prise de vue du capteur (111) voir de la définition de la photo pour exploiter les limites de l’état de l’art, par exemple au regard des performances des vidéos, comme détaillé ciaprès. A noter que la dimension du cadre de consigne (105) peut être calculée, et non imposée, selon les performances connues du smartphone de l'utilisateur. Par exemple de telle sorte que le cadre (105) soit d'une dimension minimale fixée, d'un rapport hauteur sur longueur borné et qu'il soit susceptible d’occuper un nombre minimal fixé de positions distinctes dans le référentiel local (109) qui est donné par les deux dimensions de la définition de la photographique produite par le smartphone. On peut imaginer une unique photo préexistante d’une définition gigantesque de 10000 méga pixels (taille inexistante dans l'état de l'art) dans laquelle l’objet (101) serait centré. Il suffirait alors pour répondre aux consignes (103, 104, 105, 106, 107, 108, 110) d’extraire de cette photo préexistante, deux photos qui les satisfassent. Le problème serait alors que l’objet (101) sur les deux photos extraites d’une seule ne pourrait pas représenter deux angles de vues différents. A l'analyse, le nombre de matches serait beaucoup trop grand. C'est la raison pour laquelle on introduit une borne minimale et une borne maximale de matches entre deux photos. La borne minimale pour l'identification et la borne maximale pour la discrimination de deux photos identiques. On peut aussi imaginer que ces 5767232762880 bits d'information soient stockés de façon compressée, typiquement selon les techniques de compression de vidéo puisqu'il s'agit de 100280 photos différentes mais de la même scène. On se base sur l'état de l'art des smartphones. A ce jour seuls quelques modèles permettent de produire une vidéo en format ultra HD 4K. Selon ce standard, les vidéos produites sont de format 3840 * 2160 pixels. Cette définition ne permet tout simplement pas de produire une photo de 4128 * 2322 pixels. Ainsi, les consignes (103, 104, 105, 106, 107, 108, 110) peuvent être élaborées selon les limites connues de l'état de l'art. Plus simplement, une vidéo comprimée visualisée reconstruit les scènes (les photos) sur la base d'images de référence (ou de portion d'image) ce qui ne permet pas de reconstruire deux images sous un angle de vue différent qui ne soit pas détectable avec l'analyse de l’état de l'art. Ici encore, il est possible de définir deux consignes de position du cadre (105) suffisamment proches (ou éloignées) pour que deux photos extraites d’une vidéo ne puisse pas être produites par les normes vidéo de l’état de l’art sans être détectables comme identique par les méthodes connues d’analyses d’image. Cette détection prendrait par exemple la forme d'une borne maximale de matches dépassée. Pour une vidéo non comprimée en format 8K (7680 x 4320 pixels) à 30 frames par seconde, 12 bits par couleur et 10 secondes de vidéo pour filmer l'objet dans les quatre coins de la vidéo on obtient un fichier de quelques 120259084288 bits. On note que la vidéo ne serait frauduleusement exploitable que relativement à une série de consigne basées sur une seule distance de l’objet (101). Même pour une seule distance, avec 120259084288 bits d’information, on reste, en volume, dans le même ordre de grandeur que pour nos 100280 photos. Nos consignes sont deux positions distinctes (103, 104 et 106, 107) de l'objet (101). On peut allonger et complexifier à loisir les consignes avec de la distance, de l'orientation, de l'angle de prise de vue, ... Pour la distance, si on la réduit, cela à une incidence sur le nombre de positions distincts du cadre (105) mais pas l’orientation sur tous les points de la sphère dont l’objet (101) est le centre. On peut ajouter des consignes pour la production d’une vidéo de l’objet (101). Ces consignes portent par exemple sur la vitesse (assistée) de prise de vue. Ces vitesses sont ensuite analysées par extraction des vecteurs de mouvement de la vidéo ainsi produite. De plus, l’invention concerne l’objet mais aussi son environnement. L'environnement analogique d'un objet (101) à une position donnée et une date donnée ne se limite pas à la lumière. Le cas échéant, on peut aussi joindre à la numérisation d'onde électromagnétique lumineuse, la numérisation d'onde radioélectrique dans différentes bandes de fréquence comme cela est illustré plus loin et sur la figure 9. Il s’agirait donc, en plus des photos consignées de l’objet (101, 603, 604), de produire une vidéo consignée de l’objet et de produire un enregistrement consigné d’onde radioélectrique à la position du capteur (111). Les smartphones sont en effet dotés de récepteur FM (Frequency Modulation), 2G (Global System for Mobile), 3G (Universal Mobile Télécommunications System), 4G (IMT-Advanced), Wifi (Wireless Fidelity),.. Malgré le caractère empirique des calculs ci-dessus, on retient pour la forme qu’un seul bit de consigne brute peut permettre d’exclure (l’exploitation frauduleuse de) 10¹⁰ bits d’information préexistantes. On peut allonger les consignes par exemple à une suite fixée de position du capteur (111) avec en plus pour chaque position du capteur (111) différents angles de prise de vue et orientation. Ces paramètres étant détectable par l’état de l’art au degré près (cf « An Approach for Determining Angle of Rotation of a Gray Image Using Weighted Statistical Régression >> Joydev Hazra, Aditi Roy Chowdhury, Paramartha Dutta). L’aléa fourni par chaque bloc (par exemple avec son empreinte) d’une blockchain dont le consensus décentralisé est la preuve de travail est typiquement de 32 octets soit 256 bits (en toute rigueur l'aléa le plus pur est celui de la nonce du bloc et débute systématiquement par un nombre de 0 fixé selon la difficulté ajustée de la preuve de travail). Pour l’horodatation de l’invention, la blockchain Ethereum produit un bloc toute les 15 secondes. On note que l’on peut exploiter un minimum de 256 bits différents toutes les 15 secondes, soit directement, soit par exemple en faisant le ou exclusif de l’empreinte des dix derniers blocs (pour accroître la qualité de l’aléa). 256 bits d’aléa permettent de produire 15 consignes brutes de 17 bits. C’est déjà plus qu’il n’en faut pour exclure un fichier que ne pourrait stocker toutes les particules de l’univers (1O⁸⁰) à un bit par particule. C'est plus qu'il n'en faut pour la capacité maximale mondiale de stockage actuelle retenue (5,788*10²² bits d'information). De plus, il existe des centaines de blockchain produisant de l’aléa qui peut alimenter le procédé de l’invention pour accroître encore cette certitude très au-delà de 100% (!) si cela avait un sens. Pour conclure sur cette première caractéristique, le procédé de l’invention permet d’élaborer des consignes brutes d’acquisition que ne peut satisfaire aucun fichier préexistant. Si un tel fichier existait, il aurait une taille telle qu'il ne pourrait pas être stocké selon l’état de l’art. Plus concrètement, les consignes peuvent être calculées de façon à ce que le coût d'une contrefaçon dépasse largement les bénéfices qui peuvent en être tirés. Ainsi, une petite série de consignes en variation de position du cadre (105) est :

- soit impossible à contrefaire, par calcul et selon les limites de l'état de l'art,

- soit nécessiterais du temps, des capacités de stockage et de traitement prohibitif au regard de potentiels bénéfices pour l’usage considéré.

C'est dans cet esprit qu'il est revendiqué la création horodatée d'une représentation analogique avec une seule consigne de position du cadre (105). Cela restreint simplement le nombre d’objets identifiables (vélo, voiture, moto, objets vendus en ligne, local,...) qui doivent alors être identifiés à l’aide d’un logiciel de reconnaissance d’objets disposant d’une base de référence d’objets. Cette unique consigne peut être complétée, pour une surface donnée du cadre (105), par une orientation et une forme particulière du cadre (105) précisée par l'aléa (209) extrait du bloc dateur (201). Au-delà d’une seule consigne, le procédé de l’invention peut alors ne traiter que sur les bases du fichier (203, 204) résultant et toujours sans l’intervention d’un tiers de confiance.

Pour exemplifier la deuxième caractéristique, pour le domaine de la photographie, les consignes peuvent éventuellement s’étendre à la sensibilité (ISO), la correction gamma, la balance des blancs, l’histogramme, .....ou tout autre aspect « assez proche » des caractéristiques des capteurs. Pour l’exemple, les consignes de base concernent différents angles de prise de vue et/ou de niveau zoom (zoom expressément optique et non numérique) alors elles peuvent aussi s’étendre à l’exigence d’une forme particulière pour l’histogramme ou une balance des blancs fixée. Cette dernière fait l’objet d’un traitement informatique à partir du fichier brut (raw) donc après la phase de conversion analogique/numérique et non avant. Pour autant, ce complément de consignes est acceptable dans la mesure ou les consignes de bases (position, angle de prise de vue et/ou zoom) permettent d’avoir la garantie vvoulue de l’inexistence préalable du fichier à produire.

Pour détailler la troisième caractéristique, l’invention concerne l’acquisition d’information analogique dont la quantité d’information est infini. Cependant, l’invention peut s’appliquer à l’acquisition de valeur numérique aléatoire. Hormis la production d'aléa sur la base des technologies quantiques, l'homme de l'art connaît les limites de production d'une information totalement aléatoire. Ainsi, dans cadre de l'invention, si des valeurs pseudo-aléatoires sont exploitées (acquises), alors les caractéristiques du générateur incluant la date de production des données aléatoires (par exemple avec une graine dont l’aléa d’une blockchain est la source), sont supposées être connues des exploitants. Elles en fixent les limites opérationnelles. Pour être plus clair, l'invention reste totalement pertinente mais ses résultats opérationnels restent liés aux caractéristiques du générateur d'aléa, comme d'ailleurs tous les procédés existants qui reposent sur de l'aléa. Sur cet aspect, les contours de l'exploitation d'une blockchain comme source d'entropie ont été évoquées.

Pour exemplifier la quatrième caractéristique, une assurance temporaire doit être prise pour un camion de transport de marchandises actuellement sur un navire en mer faisant la liaison entre le Maghreb et Marseille en France. Le transport de marchandise doit être assuré pour un trajet routier de Marseille à Moscou. Sur le bateau, il n’y a pas de connexion possible au réseau Internet pour le smartphone du chauffeur, juste une liaison de type GSM (Global System for Mobile). L’assurance exige une photo du camion, du certificat d’immatriculation du camion et du permis de conduire du chauffeur, une photo du chargement ainsi qu’un certain nombre de renseignements textuels administratifs. La procédure de l’invention est alors la suivante : le chauffeur présent sur le bateau reçoit la valeur de l’empreinte du bloc courant par SMS (Short Message Service). Sur la base de cette valeur sont calculées les consignes pour la photo de constat de l'état actuel du camion. Les cinq autres photos du permis de conduire (recto/verso), du certificat d'immatriculation du camion (recto/verso) et du chargement sont librement produites (sans consignes). Il est procédé au calcul de l'empreinte, nommé haché, de l'ensemble des données numériques constitués des cinq photos non consignées et du fichier des renseignements administratifs. La consigne d'acquisition (pour la photo de l'état du camion uniquement) est calculée en liant le haché obtenue, typiquement par un « ou exclusif >> (XOR), avec la valeur de l'empreinte du bloc. A noter qu'il n'y a qu'une seule consigne qui est par exemple la position d'un cadre de consigne (105) dans l'écran de prévisualisation du smartphone (111) du chauffeur photographe. L'assurance temporaire débute à partir du moment où le camion a débarqué à Marseille et le chauffeur ayant retrouvé une connexion Internet a procédé à la notarisation de l'empreinte de la photo de constat. Les six photos et les données textuelles doivent aussi être transmises pour l'étape de validation. Avantageusement, les photos peuvent être stockées selon les protocoles IPFS (InterPlanetary File System). Ces derniers sont un adressage par contenu. Le lien (URL : Uniform Ressource Locator) pointant sur la photo est donné par son empreinte précédemment calculée. Cela assure une confidentialité (par obfuscation), la garanti de l'intégrité, puisque le lien est l'empreinte et libère de la gestion des noms de fichiers. Cet exemple illustre que :

- une consigne peut être élaborée, en plus de l'aléa fourni par un bloc, avec une valeur numérique notarisée (l'aléa ne disparait jamais !); à noter qu'il peut être exploité l'aléa de bloc qui n'est pas celui du bloc courant mais antérieur; la date de début sera celle de l'aléa du bloc exploité : le bloc antérieur;

- accessoirement, le procédé peut être initié sans connexion Internet et avec pour seule information, la valeur de l'empreinte d'un bloc et il exploite avantageusement un protocole d'adressage par contenu (IPFS).

Pour exemplifier les trois dernières (5eme, 6eme et 7eme) caractéristiques, il est développé un exemple compliqué (pas très opérationnel) mais essentiellement à vocation illustrative. Cet exemple est illustré par les figures 3, 4, 5 et 9. Dans le cadre d’un constat d’assurance et selon l’invention, un drone produit une vidéo d’un champ de culture dégradé par un évènement climatique (sécheresse, grêle, inondation,...). Le champ n’est pas forcément identifiable, il n’est pas évident de distinguer deux champs de blé dégradés à deux endroits différents sur la Terre ! De plus, on a évoqué que le contenu informationel est indépendant du paramètre à numériser. Pour associer une géolocalisation au champ à vidéographier on peut lier à la production de la vidéo l’objet « signature radioélectrique >> du lieu du champ. En effet, les coordonnées GPS (Global Positioning System) sont falsifiables alors que la signature radioélectrique est bien analogique et propre à un lieu (sur un territoire donnée). Ainsi, sur le drone, un minuscule et standard récepteur (907) FM/RDS (Fréquence Modulation/Radio Data System) peut être exploité en faisant l’acquisition des RSSI (Received Signal Strength Indication) sur le lieu du champ. Le RSSI est une mesure de la puissance en réception d'un signal reçu d'une antenne, ici de chaque fréquence reçue dans la bande FM sur le lieu du champ. Le capteur RDS (907) donne de surcroît l’identification (code PI : Program Identification : code unique attribué à chaque station) des émetteurs de radiodiffusion de masse dont la localisation et la puissance de radiodiffusion sont connues. La précision de cette géolocalisation est au mieux de plusieurs centaines de mètres mais le constat ainsi fait grâce à l’invention, sans l’intervention sur place de l’assureur ou de son représentant, permet de discriminer le champ dégradé couvert par la garantie entre des milliers d’autres champs dégradés distants de 10 à 12 000 kilomètres et non couvert par la garantie ! Cet exemple de champ n'est qu'illustratif, un exemple bien plus simple et très opérationnel est la production d'une vidéo horodatée de l'état d'un chantier quelconque pour en faire son suivi. Pour revenir au champ, la signature radioélectrique, donc la géolocalisation, est statique. Selon l'invention, on doit s'assurer que le phénomène physique ne préexiste pas sous une forme numérique avant d'en faire l'acquisition. On va donc définir un autre objet plus dynamique sans référence externe et que le procédé de l'invention va numériser sur plusieurs séquences selon des consignes fondées sur la valeur de l'empreinte d'un bloc courant de la blockchain exploitée (la valeur du bloc). On va se baser sur cet sorte de capteur intelligent qu'est le récepteur FM/RDS (907). Beaucoup disposent de DSP (Digital Signal Processor) très performant sur un composant de quelques millimètres de surface. C'est le cas de la série Si47XX (3x3 mm) de la société Silabs, qui équipe beaucoup de smartphone. Avec ces récepteurs, il est possible de commander une multitude de caractéristiques de réception : rapport signal/bruit, fréquence d'échantillonnage, seuil de réception mono/audio, contrôle automatique du gain pour l'attaque (904) et le relâchement (905) (attack / release), gain LNA (Low Noise Amplifier),..... Ces commandes se situent généralement au-delà de la phase de conversion analogique/numérique car on exploite un DSP, mais on a mentionné dans la deuxième caractéristique que les consignes peuvent s'étendre à cette phase. En restant après la phase de conversion analogique/numérique, on peut définir l'objet à identifier comme une succession temporelle consignée puis enregistrée avec la vidéo : de son mono et de son stéréo. Cette succession temporelle est consignées par la valeur du bloc appliquée sur un, deux et/ou trois métriques : rapport signal/bruit (SNR), RSSI et les interférences par trajets multiples (multipath interférence) que l'on peut programmer. L'homme de l'art connaît l'occupation spectrale du signal MPX (multiplex) en mode de diffusion stéréo et il pourra utilement se référer au document AN332 : Si47XX programming guide notamment dans son chapitre 5.2. En phase finale du procédé, on relèvera dans la partie audio (903) de la vidéo que la succession des temps d'enregistrement en mono et stéréo est conforme aux consignes et que le son enregistré reste cohérent : de la musique et/ou de la voix. En se plaçant cette fois avant la phase de conversion analogique/numérique (c'est la base) on peut définir l'objet forme du signal (903). Par exemple en réglant l’attaque (904) et le relâchement (905) du control de gain automatique (AGC : Automatic Gain Control). L'AGC est un circuit de régulation en boucle fermée qui permet de contrôler l'amplitude du signal de sortie (903) en dépit des variations de l'amplitude du signal en entrée (906). Ainsi, la façon dont le gain (rapport entre la sortie et l'entrée) est corrigé conditionne la forme du signal de sortie (903) qui est enregistré avec la vidéo produite par le drone. Une fois enregistré dans la partie audio de la vidéo, il sera alors possible, par analyse du signal audio numérisé (903), de vérifier si la consigne a été respectée et ainsi horodater de façon absolu la création du fichier. C'est cet objet forme du signal (903) que l'on choisit ici. Dans cet exemple, la valeur aléatoire (501) du bloc courant de la blockchain ainsi que la valeur numérique d'une acquisition analogique, le RSSI, sont traitées pour définir un trajet (301 dans la figure 3 et en valeur numérique dans la figure 5) du drone équipé de son GPS et muni de sa caméra au-dessus du champ. Les deux premiers octets (501) de la valeur (0x04deb601) du bloc vont consigner le déplacement du drone. Les deux premiers bits (0b11, 0b signifie binaire) de la plus grande valeur de RSSI va permettre de consigner sur une des quatre règles (401, 402, 403, 404) de déplacement pour le premier mouvement (312). Cela permet d'exemplifier une consigne produite sur la base d'une acquisition analogique. Sur ce parcours (301), il est défini une zone rectangulaire (304) nécessaire pour vidéographier le champ. Sur cette zone (304) plane est appliqué un système (305) de coordonnées dans une base orthonormée sur un espace euclidien avec un point d'origine en bas à gauche (311). Entre chaque point de coordonnées entières, la distance est par exemple relative à la précision moyenne du GPS qui équipe le drone. Il est défini dans cette zone (304) un point de départ (302) et un point d'arrivé (303). Il est défini deux surfaces (308 et 309) et deux bords (306 et 307). La surface 308 est le demi rectangle inférieur, la surface 309 est le demi rectangle supérieur. Les deux demi rectangles ont un coté commun qui est la ligne médiane, soit le segment sur la droite qui joint le point de départ 302 et le point d’arrivé 303. Le bord 306 est le segment « bas >> sur la droite des ordonnées égale à zéro. Le bord 307 est le segment sur la droite d’ordonnée égale à dix. Sur chacun de ces quatre ensembles, la règle du déplacement du drone est distincte. Ces quatre règles (401, 402, 403, 404) ont chacune vocation, sur la base de l'aléa de la valeur du bloc, à ramener le drone vers la ligne médiane (301). A chaque déplacement l'abscisse est systématiquement augmentée d’une unité, c'est la règle de déplacement (401, 402, 403 ou 404) qui définit la prochaine ordonnée. Chaque déplacement est effectué sur la base de la valeur des deux bits courants traités de la valeur aléatoire et horodatée (501 : 0x04deb601) du bloc. On commence par les bits de poids fort. Le détail de l'application des règles de déplacement est le suivant :

- au point de départ (302), pour seulement le premier déplacement, la règle est celle (404) donnée par la valeur des deux premiers bits de poids fort du RSSI dont la valeur acquise est la plus élevée,

- sur les points du bord bas (306), c'est la règle numéro 0 (401) qui s'applique,

- sur les points dans la surface basse (308), c'est la règle numéro 1 (402) qui s'applique,

- sur les points de la ligne médiane (310), c'est la règle précédente qui s'applique,

- sur les points de la surface haute (309), c'est la règle numéro 2 (403) qui s'applique,

- sur les point du bord haut (307), c'est la règle numéro 3 (404) qui s'applique,

- quand l'abscisse est égale à celle du point d'arrivé (314), le drone rejoint le point d'arrivé (303).

Au final, grâce à ces règles, en dépit d'une valeur aléatoire qui régi les déplacements du drone, on le contraint à se déplacer entre deux points (302, 303) choisis. On le fait en fixant les probabilités d'un déplacement vers la ligne médiane. Par exemple pour la règle numéro 1 (402) quand le drone est dans la zone basse (308), la probabilité, alimentée par la valeur aléatoire des deux bits courant, est deux fois plus élevée de rejoindre la ligne médiane que de s'en éloigner (deux flèches vers le haut et une seule vers le bas). D'autre modes de déplacement sont possibles, comme ne définir que deux bords qui ramènent immédiatement le drone sur la ligne médiane, cela revient à fixer les probalités à 100% de revenir sur la ligne médiane mais uniquement en atteignant les bords. Le drone est en stationnaire au point de départ (302). II fait l'acquisition des RSSI de l'ensemble des fréquences reçues et de sa position GPS et enregistre les résultats dans la partie métadonnées de la vidéo à produire. Cela donne deux sources d'information de géolocalisation. Le drone commence alors son déplacement consigné par les valeurs (501 : 0x04deb601) des bits du bloc. Le premier octet (0x04) consigne les quatre premiers déplacements. Les quatre valeurs de ce premier octet sont : ObOO, ObOO, 0b01 et ObOO. Pour le premier déplacement, les deux bits du RSSI le plus élevé acquis sont 0b11 (3 en décimal). On prend donc la règle de déplacement numéro 3 (404) pour le premier déplacement du drone. La valeur des deux premiers bits du bloc est ObOO. L'ordonnée va donc être diminué de 3 unités (valeur de ObOO avec la règle de déplacement numéro 3). On passe donc du point de départ (302) de coordonnées (2,5) au point (312) de coordonnées (3,2). Le quatrième déplacement, ObOO selon la règle numéro 1 (402) fait arriver le drone sur le bord bas (306) au point de coordonnées (6,0). C'est donc maintenant la règle de déplacement numéro 0 (401) qui s'applique. La cinquième valeur des deux bits du bloc est 0b11. Le déplacement arrive donc au point de coordonnées (7,3). Le drone poursuit ainsi son déplacement consigné jusqu'au point de même abscisse que le point d'arrivé. Son dernier déplacement (314), selon les règles fixées, le font arriver au point d'arrivé (303).

Pendant le déplacement, il est enregistré dans la partie audio (903) de la vidéo, le signal radioélectrique en provenance de la fréquence FM dont le RSSI est le plus élevé. Cet enregistrement audio (903) est consigné avec le taux d'attaque (904) et de relâchement (905) de l'AGC. Cette consigne est représentée sur la figure 9 par la pente de la droite 904 pour l’attaque et la pente de la droite 905 pour le relâchement. Par exemple pour tout nouvel octet de la valeur du bloc, donc tous les quatre déplacements du drone, on modifie les deux taux (904 et 905) avec la même nouvelle valeur de l'octet. Sur les récepteurs (907) cités, cette valeur varie avec des pas de 4 sur les bornes 4 à 248 modifiable à l'initialisation. On adapte donc le traitement pour ramener la valeur de l'octet sur celle requise. On peut exploiter les valeurs de RSSI acquissent au point de départ (302) pour syntoniser le tuner sur la fréquence FM la plus apte à faire réagir l’AGC selon la consigne. Après ses acquisitions, il est calculé l'empreinte de la vidéo produite. Cette empreinte est la valeur d’ancrage. Après la notarisation du fichier de la vidéo (inscription de son empreinte dans la blockchain), l’analyse du fichier pour retrouver les consignes (le parcours du drone) peut très avantageusement être automatisée avec l’extraction des vecteurs de mouvement de la vidéo produite et dont l'empreinte est notarisée. Le vecteur de mouvement est un élément clé en compression vidéo. Il s'agit d'un vecteur qui représente le mouvement d'un macro bloc ou d'un simple bloc d'une image source depuis une image passée ou future de la séquence vidéo (image de référence). L'ensemble des vecteurs de mouvement sur une séquence permet de retrouver automatiquement le déplacement du drone dans l'intervalle de temps traité ; et ainsi la valeur des consignes. Le traitement des métadonnées de la vidéo permet de géolocaliser le drone, d'une part sur la base des données GPS et d'autre part sur la base de la géolocalisation, de la fréquence et de la puissance des émetteurs FM. Ces caractéristiques sont disponibles sur de nombreux sites étatiques ou non (fmscan.org). L'analyse de la partie audio (903) permet de corréler le signal enregistré (903) avec l'attaque (904) et le relâchement (905) consignés sur l'AGC (analyse des variations d'amplitude en dB/s). Pour finir, les images de la vidéo font le constat de l'état horodaté du champ. Bien évidemment, le mode de construction de cette vidéo est connu des exploitants du procédé de l'invention. Cet exemple compliqué mais illustratif de drone montre que :

- les consignes portent sur plusieurs objets analogiques : champs radio électrique statique (902), séquence temporelle sur une nature ou une forme (903) de signal radioélectrique et onde électromagnétique lumineuse (images) dans la vidéo produite ;

- les consignes peuvent intégrer des valeurs numériques issues d'acquisitions de phénomènes physiques, ici une valeur de RSSI pour le premier déplacement (312) ;

- les consignes peuvent s'étendre à des commandes sur les capteurs, après mais surtout avant (904 et 905) la phase de conversion analogique/numérique ; ici l'AGC. C'est une consigne très illustrative, autant qu'aurait pu être une consigne sur le LNA. Cette consigne adresse une commande sur un capteur avant la phase de conversion analogique/numérique ce qui permet d’avoir la certitude qu'il ne préexiste pas de représentation numérique du fichier à produire. Une consigne plus simple peut concerner un ordre des fréquences à syntoniser par le tuner (907), ainsi l'enregistrement audio (903) date l’acquisition ; certes c'est associé à un lieu et un contrôle appronfondi suppose l'intervention d'un tiers, typiquement étatique, qui dispose des enregistrements audio archivés et horodatés de toutes les radiodiffusions sur le territoire national.

- accessoirement, l'identification des consignes exploitent avantageusement les mécanismes qui permettent de produire le fichier dont la création est à horodater : ici l'analyse des vecteurs de mouvement de la vidéo produite sur des consignes de déplacement : le parcours (301) du drone.

Lorsque les consignes sont à l'adresse d'un opérateur humain, elles sont plutôt associées à une position et une orientation spatiale du capteur. On peut ainsi exploiter tous les applicatifs qui permettent de mieux contrôler l'acquisition, typiquement, concernant les photos (601, 602) et vidéo (701), par des incrustations (105, 108, 110, 705 à 708, 713) dans l'écran de prévisualisation. L’invention peut exploiter avantageusement les capteurs de mouvements (gyroscope, inclinaison) équipant les smartphone (111) : soit pour une assistance à la production du fichier, soit pour une nature de consigne, soit les deux. Il peut s’agir de la vitesse consignée à laquelle l’opérateur doit balayer un objet en produisant une vidéo, ou d’un angle de prise de vue ou une orientation pour une photo. Lorsque la consigne adresse la commande (904, 905) d'un capteur, l'invention peut être pertinente pour les domaines de la régulation, de l'asservissement ou ceux pour lesquels les capteurs sont déjà équipés de dispositifs permettant de stabiliser ou compenser les grandeurs d'influences. Il s'agit de grandeurs physiques autres que le mesurande (grandeur à mesurer). Plus généralement l'invention s'adresse là aux domaines dans lesquels sont exploités des capteurs dit intelligents. Ils ont la capacité à tenir compte de leur environnement et à définir leurs états de fonctionnement. Ils s'adaptent au signal mesuré (amplificateur à gain variable, filtre à fréquence de coupure variable,...). Ils sont miniaturisés, bon marché, associés à des modules de traitement du signal mis en place à proximité de la source de données pour n'obtenir que l'information utile. Précisément, dans le cadre de l'invention, il pourrait être utile d'obtenir cette information inutile (!) que les capteurs intelligents ne transmettent pas ; notamment s'il s'agit de bruit pour lequel on dispose d'une connaissance statistique ou de signature de tout ordre. Au-delà de module de traitement du signal (907), les capteurs intelligents sont ici appréhendés comme communiquant (associé à un module de transmission bidirectionnelle à distance d'information). C'est une caractéristique essentielle pour l'invention pour la transmission des consignes d’acquisition et un retour de fichier (ou au moins sont empreinte) produit par conversion analogique/numérique. Pour ce domaine des capteurs intelligents, la blockchain IOTA peut être pertinente. Cette dernière est plus spécifiquement dédiée aux objets connectés. Les transactions sont sans frais et susceptibles d'être produite de façon autonome par de tels objets. Cela requiert tout de même la capacité calculatoire pour produire une transaction et en valider deux du réseau par un mécanisme similaire à la preuve de travail.

Une application particulière est basée sur les capacités du procédé de l’invention à permettre la production d’un fichier non préexistent puis horodaté, d'un sujet identifiable, qui plus est, sans tiers de confiance. Il s’agit de l’authentification biométrique en ligne et la signature électronique biométrique en ligne. Cette application est illustrée sur les figures 7, 8, 10 et 11. Les deux figures 7 et 8 illustrent rigoureusement le même procédé que sur les figures 1 et 2, sauf qu'il ne s'agit pas de fichiers photographiques (203, 204) mais vidéographique : celui d'une vidéo selfie (701). Les figures 10 et 11 détaillent un exemple de procédure de signature électronique biométrique (805) respectant les techniques de la cryptographies asymétrique et accompagnée des valeurs numériques. La figure 10 sur la blockchain Bitcoin, la figure 11 sur la blockchain Ethereum. La blockchain et les stockages décentralisés seront à terme largement exploités pour les écosystèmes de l’identité numérique. Externaliser l’exploitation, la gestion et la sécurité est leur grand intérêt opérationnel. Ce n’est actuellement pas le cas. Le principe général centralisé des Infrastructure à Clé Publique (ICP ou PKI : Public Key Infrastructure en anglais) est d'associer une clé publique (806) à une identité (803) par l’intermédiaire d’un certificat. Une ICP gère le cycle de vie de ces certificats numériques ou certificats électroniques. Les services d’une ICP sont les suivants : enregistrement des utilisateurs (ou équipement informatique), génération de certificats, renouvellement de certificats, révocation de certificats, publication de certificats, publication des listes de révocation (comprenant la liste des certificats révoqués), identification et authentification des utilisateurs, archivage, séquestre et recouvrement des certificats. Ces différents services sont associés à différentes autorités. L'Autorité de Certification (AC ou CA en anglais) est la plus critique. Elle signe les demandes de certificat (CSR : Certificate Signing Request) et les listes de révocation (CRL : Certificate Révocation List). Fonctionnellement, le détenteur (803) de l'identité (803) est le seul à pouvoir manipuler la clé privée (1008 ou 1012) correspondante à la clé publique (806) mentionnée dans le certificat qui l’identifie. Avec cette clé privée racine (1008) ou cette clé privée dérivée (1012) il peut signer tous documents numériques. Les problèmes de l'état de l'art sont les suivants. Une ICP nécessite des infrastructures de gestion de certificats, une centralisation des données, des coûts de maintenance, de mise en œuvre, de maintien en condition opérationnelle et de sécurité. L'ICP implique une lourdeur dans la mise en œuvre opérationnelle pour les utilisateurs. De plus, il est également nécessaire de disposer d'une infrastructure d'archivage probant pour les signatures électroniques produites. L’invention apporte une solution nouvelle : un fichier biométrique (701) horodaté selon l’invention fait office de certificat, typiquement temporaire, autoproduit. L’archivage probant est apporté par la blockchain. II n’y a donc ici plus aucune des infrastructures d’une ICP, plus aucune autorité et plus aucun tiers de confiance. Ce n’est pas une autorité de certification qui atteste de mon identité, c’est toute l’information, la « matière >> biométrique incorporée dans un fichier horodaté et non préexistant selon l’invention. Cela consiste essentiellement à exploiter la valeur d'ancrage (809) ; autrement dit, horodater et notariser des informations (701,717, 803, 804, 805, 806) avec le fichier horodaté produit (701) lorsque ce dernier est biométrique, sachant que le procédé de l’invention apporte la garanti que ce fichier biométrique n’existait pas avant une date donnée. C'est une sécurité très importante pour l'authentification car un utilisateur en ligne peut toujours transmettre des fichiers biométriques (de son iris, de son visage, de ses empreintes digitales,..) qui préexistes déjà, donc qui ne sont éventuellement pas les siens, mais des fichiers biométrique existant appartement à une autre personne. Après un contact humain par téléphone, la procédure de signature ou d'authentification peut être poursuivie par un serveur vocal interactif. De plus, grâce au fait que le fichier ne préexiste pas, il est donc en particulier possible, au moment de sa création, d’y insérer des informations échangées lors d’une communication téléphonique pour signer un contrat, par exemple un nonce cryptographique en équivalence des actuels numéros reçus par SMS pour signer un contrat. Ce nonce est ici par exemple les quatre digits 705, 706, 707, 708 ou il peut être une information complémentaire à la référence 213 ou 718. Cela réduit de beaucoup le besoin d’infrastructure que nécessite en particulier la solution RecordSign de la société Vocalcomm. RecordSign est une solution multicanale de souscription vocale qui regroupe dans le même appel le contrat vocal, sa notarisation, la gestion électronique du mandat SEPA (Single European Payments Area) et la signature électronique des documents dématérialisés. Cette solution, aussi intégrée soit elle, regroupe un certain nombre de canaux (courriel et SMS) pour procéder à la signature et au paiement et requière des infrastructures notamment pour l’archivage à valeur probante. Avec l’invention, on couvre le contrat vocal, sa notarisation et la signature électronique avec son archivage. Il ne manque que le paiement mais les cryptomonnaies sont nativement implémentées sur la blockchain (202 ou 714) exploitée comme sur la quasi-totalité des blockchains. Dans le cadre de l’invention, le fichier biométrique (701) peut alors être exploité selon trois usages :

- Pour l’authentification biométrique, directement comme support (701) d’authentification ou indirectement car horodaté et notarisé par son empreinte (1002),

- Pour la signature électronique biométrique en cryptographie asymétrique (pour un meilleur interfaçage avec les systèmes actuels) :

o comme base de production de clé publique (806) notarisée (809) de signature électronique biométrique (805) pour un usage immédiat ou différé, o comme archivage probant notarisé de signature électronique biométrique (805), o comme base de production de clé privée (1012) notarisée (809) ou non, de signature électronique biométrique (805),

- Pour la signature électronique biométrique sans cryptographie asymétrique: comme élément d’un ensemble (801) d’information notarisée (809) de signature électronique biométrique (812).

Ces usages sont préférentiellement uniques avec un fichier biométrique (701) produit dans l'instant. Ce fichier (701) peut aussi n’être que audio ou photographique. Grâce à l'invention, la signature biométrique (805 ou 812) produites ont plus de force probante qu'une signature manuscrite et sans aucune infrastructure relevant d’une ICP. Une signature devant généralement selon les lois, identifier celui qui l'appose. Une identification biométrique vocale, photographique ou vidéographique incorpore plus de matière biométrique qu’un dessin manuscrit de signature à la main. Il est de plus horodaté, notarisé et non préexistant. Sur ces trois usages, le procédé, autour de la production et l’exploitation de la valeur d’ancrage (809), est alors respectivement le suivant :

- Pour l’authentification biométrique : la valeur d’ancrage (809) est l’empreinte (1002) de la vidéo selfie (701) horodatée selon l’invention.

- Pour la signature électronique biométrique en cryptographie asymétrique selon un des trois modes suivants :

o La valeur d’ancrage (809) est la clé publique (806) issue de la vidéo selfie (701). Le signataire est sa propre autorité de certification pour opérer des signatures électroniques biométrique en ligne. Il le fait par exemple auprès d’organisme pour lesquels il est déjà authentifié (sa banque, son entreprise, ...). Il peut signer de suite ou de façon différée. Pour un usage unique, la clé publique, qui est une adresse publique sur la blockchain (202, 714), peut être créditée (en cryptomonnaie) du seul montant des frais de transaction. Après une transaction, le solde est à zéro, plus aucune transaction n’est possible. Si c'est une Autorité de Certification (AC) qui réalimente le crédit (c'est formellement détecté avec la valeur de l'adresse de l'AC) alors ladite adresse peut être exploitée au moins une nouvelle fois.

o La valeur d’ancrage (809) est le condensât (805) produit en signant l’empreinte (804) du document numérique (717) avec la clé privée (1012). Il s’agit d’une signature électronique biométrique effectuée selon les standards de la cryptographie asymétrique. La clé publique et la clé privée du signataire sont produites sur les bases de la vidéo selfie (701) et des identifiants (803) du signataire. On exploite l’empreinte (1010) des identifiants (803) formatée selon le standard JSON (JavaScript Objet Notation). Cette empreinte (1010) est la dérivation effectuée sur la clé privée racine issue de la vidéo selfie (701). Cette dérivation peut être complété par un nonce cryptographique recueilli lors d’une communication téléphonique comme précédemment évoqué.

o Quelques soit la valeur d’ancrage (809), la clé privée racine (1008) ou la clé privée dérivée (1012) des identifiants (1006) du signataire (803) sont l’une et l’autre produites avec comme source de donnée : la vidéo selfie (701) horodatée et notarisée (809).

- Pour la signature électronique biométrique sans cryptographie asymétrique : la valeur d’ancrage (809) est l’empreinte (812) produite avec un ensemble d’information (801) incluant la vidéo selfie (701). Lorsque cet ensemble (801) inclus : la vidéo selfie (701), le document numérique (717) à signer et les identifiants (803) textuels du signataire alors on obtient fonctionnellement une signature électronique biométrique mais sans exploiter les techniques de la cryptographie asymétrique : il n’y a pas de clé publique ou privée.

On va donc exploiter le fait que le procédé de l’invention permet la production d’un fichier non préexistent (701) puis horodaté d'un sujet (803) identifiable : une vidéo selfie (701). Cette vidéo selfie (701) horodatée pour laquelle, pour exemple, en étape de numérisation il a été définit deux cadres de consigne dont les coordonnées dans le référentiel local (la vidéo produite) sont (709, 710) et (711, 712). Pour rajouter de la matière biométrique, il est aussi consigné une séquence audio temporelle sur la vocalisation de l'utilisateur. Il s'agit d'une suite de digits d'information (705, 706, 707, 708). Ces quatre digits peuvent être n'importe quel type d'information (cf nonce cryptographique évoqué plus haut). Ce qui est important est qu'ils sont vocalisés selon un temporalité corrélée à la valeur de l'aléa (702) produit par un bloc (703) d'une chaîne de blocs (714) qui est la référence temporelle absolue. On peut aussi demander à l'utilisateur de prolonger la vocalisation d'un digit tant que le suivant n'est pas démasqué. Pour une signature électronique en ligne, ces quatre digits peuvent être les quatre premiers digits de l'empreinte (715) du document (717) à signer. L'assistance (dessin 105, 108 et 110 dans la figure 1) consiste en un démasquage progressif desdits digits (705, 706, 707, 708), tous initialement masqués dans l'incrustation de l'écran de contrôle de la vidéo (701 ) en production par le smartphone (111). Ils sont progressivement démasqués (705 et 706 alors que 707 et 708 sont encore masqués) selon des écarts de temps corrélés aux valeurs de l'aléa (702) extrait du bloc dateur (703) de la chaîne de blocs (714). Les écarts de temps de démasquage tiennent compte des temps de latence moyen introduit par le cerveau humain pour analyser une information visuelle et vocaliser une information. Cet aléa sert aussi de base à la valeur des coordonnées des deux cadres de consigne suscitées (709, 710, 711, 712). Les quatre digits (705, 706, 707, 708) comme la valeur de l'aléa (702) figurent (718) dans la vidéo (701) produite. Le mode opératoire classique pour la signature électronique en ligne est illustré sur la figure 8 et précisé et détaillé avec des valeurs numériques sur les figures 10 et 11. Il s'agit pour le signataire (803) de chiffrer (fonction 1014) l'empreinte (804) du document numérique (717) à signer avec sa clé privée (1012) pour produire un condensât (805). Il transmet alors en ligne ce condensât (805) et sa clé publique (806) au cocontractant. Le cocontractant, qui dispose déjà du document à signer (717), peut vérifier que le condensât (805) est cryptographiquement lié à l'empreinte du document à signer et à la clé publique (806) transmise puis, grâce à l'ICP (sans l'invention), à la certitude que cette clé publique (806) est bien associée à l'identité du signataire (803) qui manipule seul sa clé privée (1012) ayant produit le condensât (805). Ici, il n’y a pas d’ICP puisque la signature repose sur de l’information biométrique dont l’horodatation est absolu et probante. La figure 8 illustre le procédé pour la signature biométrique électronique en ligne selon l’usage avec la cryptographie asymétrique. Un des trois modes précités est sélectionnés avec la fonction ou (810). Comme illustré sur la figure 2 avec la valeur d’ancrage 205, la notarisation des données avec la valeur d’ancrage 809 permet de prouver l'existence du fichier 701 avant une date de fin donnée par la valeur de l'empreinte 716 du bloc 704. Sa date de création est celle de l'aléa horodaté du bloc 703. Sur la figure 10 est numériquement exemplifiée une signature biométrique en cryptographie asymétrique. La particularité est ici, comme l'usage est préférentiellement unique, que l'on n'exploite pas de secret lié au signataire (803). En quelque sorte, le secret (la clé privée) est construit sur le champs et il s'agit de la vidéo selfie 701. On produit l'empreinte (1002) de la vidéo selfie (701) et celle (804) du document numérique à signer (717) avec les fonctions de hachage SHA-256 (1001 et 1003). On produit (1005) les identifiants formatés (1006) du signataire (803). Le format exploité est le JSON : JavaScript Objet Notation. L'intérêt est que ce format est très répandu. Par exemple, les identifiants de l'application gouvernementale française d'authentification en ligne France Connect sont dans ce format et selon ces libellés de champs. Ces identifiants (1006) vont servir de base à la dérivation de la clé privée racine (1008) produite selon la norme BIP-0032 (Bitcoin Improvement Proposai « hierarchical deterministic wallets »). Elle (1008) est produite avec l'empreinte 1002 à l'aide de la fonction (1007) HMAC-SHA512 (keyed-Hash Message Authentication Code exploité avec la fonction itérative de hachage SHA produisant une sortie sur 512 bits). On calcul l'empreinte (1010) des identifiants formatés (1006) à l'aide de la fonction de hachage SHA-256 (1009). Cette empreinte 1010 va être exploitée pour dériver la clé privée racine 1008. L'intérêt est d'intégrer, en plus de la vidéo selfie 701, les identifiants (1006) du signataire (803) au condensât (805) final. On peut aussi y intégrer d’autre informations comme un nonce cryptographique évoqué plus haut. Les portemonnaies hiérarchiques déterministes BIP-0032 utilisent une fonction de dérivation de clé fille (CKD: Child Key Dérivation) pour dériver les clés filles des clés parents. La fonction de dérivation de clé fille est basée sur une fonction de hachage à sens unique qui combine : une clé parent publique ou privée (1008), une graine appelée code chaîne (256 bits), un numéro d'index (entier sur 32 bits). L'index, ou numéro de clé, utilisé par la fonction de dérivation est un entier sur 32 bits. On distingue les clés normales et les clés durcies. Ces dernières ne permettent plus de remonter à une clé parente. Pour pouvoir distinguer facilement les clés normales des clés durcies, la plage des index est coupée en deux : de 0 à 2³¹-1 (0x0 à 0x7fffffff) pour les index normaux, et de 2³¹ à 2³²-1 (0x80000000 à Oxffffffff) pour les index durcis. Dans la figure 10, on utilise des clés non durcies. La dérivation de la clé 1008 va exploiter la totalité des 256 bits de l'empreinte 1010. On va donc prendre, en partant des bits de poids faible de l'empreinte 1010, onze groupes : 10 groupes de 3 octets chacun et le dernier groupe de 2 octets (0x654D : 25933 en décimal). On va ensuite procéder à 11 dérivations successives (1011) pour obtenir la clé privée de signature 1012. Ces 11 dérivations figurent pour information en décimal, entre parenthèse sous la valeur hexadécimale de la dérivation 1010. La clé privée (xprv...QSsR) de signature 1012 est donnée selon la norme BIP-0032. Son équivalent en hexadécimal, hors formalisme BIP-0032, est donné en dessous (0x7e9b....3ddd). C'est cette clé 1012 en hexadécimal qui sera exploitée sur la figure 11 pour une signature selon les protocoles de la blockchain Ethereum. Pour finir, on procède (1014) à la signature de l'empreinte (804) du document (717) à signer. Le protocole de signature est celui de la blockchain Bitcoin et Ethereum sur la courbe elliptique secp256k1 (signature ECDSA : Elliptic Curve Digital Signature Algorithm). Les trois informations (bloc 802) de la signature sont l'empreinte 804 du document signé, la clé publique dérivée 806 et le condensât de signature 805. La figure 11 est une signature sur la blockchain Ethereum. Les trois informations de la signature sont l'empreinte 1102 codée en ASCII du document signé, la clé publique dérivée 1104 et le condensât de signature 1105. Concernant les calculs des figures 10 et 11 et leur vérification, l'homme de l'art pourra utilement, entre autres, se référer au sites Internet : bip32.org (production de clés BIP-0032), coinig.com (vérification de signature Bitcoin) et etherchain.org (vérification de signature Ethereum). Les calculs illustrés des figures 10 et 11 permettent indifféremment de créer un identifiant biométrique (1002), une clé publique biométrique (806 ou 1104) ou une clé privée asymétrique racine (1008) ou dérivée (1012) sur la base d'un fichier (701) biométrique et horodatée selon l'invention. On peut avantageusement exploiter le fait que les clé publiques biométriques 806 ou 1104 sont aussi des adresses publiques, soit un compte créditable en cryptomonnaie, sur la blockchain exploitée. En résumé, lorsque le fichier horodaté selon l’invention à une nature biométrique (selfie, enregistrement audio,..), il permet l'authentification biométrique en ligne et la signature électronique biométrique en ligne sans les infrastructures (d’horodatage probant, d’archivage probant, de gestion des certificats, ...) des infrastructures à clé publique et sans tiers de confiance. Le certificat de l’état de l’art associé à l’authentification et la signature est ici autoproduit.

Une fonctionnalité pertinente associe l'exploitation de contrat intelligent (Smart Contract) et le haché d'un fichier (203 et 204, 601 et 602, 701, 903) horodaté selon l'invention. Il s'agit d'exploiter la valeur d'ancrage (205 ou 809) et la notarisation selon un des trois modes (empreinte de l'empreinte de contenu) exposé plus haut : celui de certification des diplômes. Un tel contrat est soit existant soit est à chaque usage, produit et implémenté à la volé (en temps réel) dans la blockchain exploitée. Il est implémenté en phase d'exploitation du procédé, juste avant la transaction de notarisation (211 ou 811). Ce contrat est typiquement à usage unique (s'il n'est pas préexistant). Il est activé (ou débouclé) sur réception d'une empreinte dont la valeur est celle attendue. Il produit alors une transaction sur la blockchain exploitée. Cette empreinte attendue est celle d'un vrai contrat numérisé dans un document et ce document indu la valeur de l'empreinte d'un fichier (203 et 204,601 et 602,701, 903) horodaté selon l'invention. Ce document est par exemple un contrat d'assurance temporaire pour un véhicule. Le fichier est alors une photographie du véhicule à assurer. Le propriétaire du véhicule (ou le courtier en assurance du réseau), à l'aide de l'application smartphone de l'invention, à saisie toutes les informations utiles pour acheter une garantie d'assurance temporaire pour le véhicule. Le serveur de l'application (ou le Smartphone) génère alors le document contractuel (par exemple en format PDF). Ce document contractuel inclut en annexe la valeur de l'empreinte de la photographie du véhicule. Il peut même inclure une signature biométrique vocale de l'invention. Le serveur calcule alors l'empreinte, nommé haché de ce document contractuel. La valeur de ce haché est fonction de la valeur de l'empreinte de la photographie du véhicule, c'est un principe des fonctions de hachage (cf certification des diplômes sus-décrite). Le serveur produit alors le Smart Contract. Il a pour objectif de générer une transaction sur la blockchain à la condition expresse que la valeur d'ancrage reçue (205 ou 809) de la transaction de notarisation (211 ou 811) soit exactement celle du haché que le serveur vient de calculer. Ainsi, une seule transaction sur la blockckain produit :

- la signature d'un contrat entre au moins deux parties,

- l’horodatage et l'archivage probant d'un document contractuel sans aucune infrastructure dédiée,

- l’horodatage probant de la photographie du véhicule selon l'invention,

- optionnellement, le transfert de tokens (jetons) de cryptomonnaie pour chacun des intermédiaires (grossistes en assurance, courtiers en assurance, ...) impliqués dans cette vente et selon un montant correspondant à leur marges respectives. Le token a une convertibilité fixe (une unité de token égale un euro) et peut être compensé à tout moment. Le courtier final peut liquider immédiatement sa marge s'il reçoit des espèces de l'assuré et règle en tokens à l'assureur final. C'est un concept original de l'auteur, nommable : tokenisation des marges, nonobstant les problèmes juridiques qu'il implique.

Ce Smart Contract et la présente invention apporte ici la traçabilité et l'auditabilité maintenant exigée par les réglementations Etatiques. II apporte la confiance entre les intermédiaires et réduit drastiquement l'asymétrie d'information du réseau et l'aléa moral avec le client final. Pour la mise en oeuvre, au moins une blockchain implémente des Smart Contracts simplifiés, avec des transactions rapides aux frais réduits qui plus est, avec des tokens dont les montants transférés sont masqués pour une légitime confidentialité.

La présente invention d'horodatation absolue de fichiers permet de substituer la confiance en un tiers par la confiance algorithmique apportée par les blockchains. A ce titre, par son usage, elle peut fluidifier les échanges économiques et restituer à tous ses acteurs, une grande partie de la valeur de cet actif des plus précieux : la confiance.

Claims (10)

1. REVENDICATIONS

   1 - Procédé d’horodatation des bornes de l’intervalle de temps (dates de début 201, 501, 702, dates de fin 214, 716) de la numérisation dans un fichier (203 et 204, 601 et 602, 701,903) et par un capteur (111,907), de phénomènes physiques (ondes électromagnétiques, ondes mécaniques, ..) caractérisé en ce que l’horodatation est absolue et probante sans tiers de confiance grâce à des consignes d’acquisition probantes (103 à 108, ou 301, 401 à 404 ou 705 à 713 ou 904, 905) :

   - fondées sur l’aléa horodaté (201, 501, 702) de blocs (209, 703) d’une chaîne de blocs (202, 714),

   - définies selon la taille d'un hypothétique fichier existant qui les satisferait,

   - appliquées avant la conversion analogique/numérique dudit capteur (111, 907),

   - portant sur au moins un paramètre postérieurement identifiable (coordonnées 103,104,106,107, trajet 301, séquence temporelle 705 à 708, trajet 709 à 712, séquence de forme de signal radio 904 et 905) sur la base de références de notarisation (202, 210, 211 ou 714, 704, 811) dudit fichier, de ses valeurs d'ancrage (201 ou 501 ou 702; 205 ou 809) et de son contenu (203 et 204, 601 et 602, 701,903),

   - définies, exploitées et validées en trois phases de définition, d'exploitation et de validation :

   - en phase de définition, on défini les consignes comme élément de références de notarisation sous la forme d'une fonction mesurable de l'espace probabilisé des valeurs aléatoires des blocs vers l'espace mesuré des fichiers numérisant au moins un paramètre, on défini :

   • la portée (orientation/localisation du capteur 111 ou commande sur le capteur 907) des consignes, • la nature dudit paramètre (position 103, 104; 106,107, trajet 301, séquence temporelle 705 à 708 ou séquence de forme de signal 904, 905,..) à numériser et le référentiel local associé (109, 202, 714, 901); ledit paramètre étant univoquement corrélée à la valeur de l'aléa horodaté (201, 501, 702) d'un bloc dateur (209, 703) d'une chaîne de bloc (202, 714), • les traitements d'assistance (105, 108, 110 ou 401 à 404 ou 705 à 708, 713) à la numérisation à l'adresse d'un opérateur ou des commandes dudit capteur,

   - en phase d'exploitation, à l'aide d'un client lourd ou léger, on lit ladite valeur aléatoire horodatée (201, 501, 702) dudit bloc dateur (209, 703) et on élabore lesdites consignes (103 à 108, ou 301, 401 à 404 ou 705 à 713 ou 904, 905) telle que définies puis on les exploite lors d’une suite de numérisations (203, 204, 601,602, 701,903) assistées (105, 108, 110, 705 à 708, 713, 904, 905) avant la phase de conversion analogique/numérique du capteur (111, 907) pour numériser ledit paramètre (103,104,106,107, 301, 705 à 708, 709 à 712, 904 et 905) et on notarisé par une transaction (211, 811) le fichier obtenu (203 et 204, 601 et 602, 701, 903) avec une valeur d'ancrage (205, 809) écrite dans un bloc subséquent (210, 704) ;

   - en phase de validation, on valide lesdites consignes en identifiant l'aléa (201, 501, 702) sur lequel elle sont fondées, par l’analyse numérique (603 à 606) appliquée sur le contenu dudit fichier (203 et 204,601 et 602,701, 903) notarisé dans lequel on identifie ledit paramètre numérisé (103,104,106,107, 301, 705 à 708, 709 à 712, 904 et 905) pour établir que ledit fichier (203 et 204, 601 et 602, 701, 903) n'existait pas, selon le niveau de certitude choisi, avant la date initiale définie par ledit bloc dateur (201 ou 501 ou 702) et existait avant la date finale définie par ledit bloc subséquent (214 ou 716), lesdites dates initiale et finale horodatant de façon absolue le moment et la durée de la création dudit fichier (203 et 204, 601 et 602, 701,903).
2. 2 - Procédé, selon la revendication 1, caractérisé en ce que lesdites trois phases comprennent chacune les étapes suivantes :

   - en phase préalable de définition, on fixe les référentiels (109, 202, 714, 901) et les traitements (ex : 401 à 404) associés auxdites consignes (103 à 108, ou 301, 401 à 404 ou 705 à 713 ou 904, 905) selon la taille minimale, en bit d’information, que devrait avoir un fichier les satisfaisant :

   • on sélectionne une chaîne de bloc (202, 714) pour laquelle d’une part la suite des références (201,214, 702, 716) des blocs (209, 210, 703, 704) est défini comme le référentiel temporel absolu et d’autre part dont l'aléa (201, 214, 501,702, 716) horodaté lié à la production desdits blocs est exploité comme source d'entropie ;

   • on défini un système de coordonnées (109 ou 305 ou 901) dans un référentiel local qui est spatiale (109, 305) ou fréquentiel ou temporel (901) et dans lequel chaque groupe de bits d'information dudit aléa (201, 214, 501, 702) extrait est univoquement associé au paramètre à numériser (103,104,106,107, 301,705 à 708, 709 à 712, 904 et 905), • on élabore les données et les traitements de formatage permettant d’extraire et formater ledit aléa (201, 214, 501, 702) pour construire les consignes brutes (103, 104, 106, 107 ou 301 ou 709 à 712);

   • on élabore les données et les traitements de normalisation permettant de normaliser (105, 108 ou 401 à 404 ou 705 à 708 et 713 ou 904, 905) leur application dans leur domaine d’application et selon leurs portées et la nature du paramètre à numériser (103,104,106,107, 301,705 à 708, 709 à 712, 904 et 905), • on élabore les traitements d'assistance à la numérisation selon la portée desdites consignes (103 à 108 ou 301,401 à 404 ou 705 à 713 ou 904, 905):

   - soit sur la localisation spatiale (incrustations 105, 108, 110, 713) ou temporelle (705 à 708) du capteur (111);

   - soit sur la commande (904, 905) du capteur (907) ;

   - en phase d’exploitation, on élabore et on applique lesdites consignes probatoires (103 à 108, ou 301, 401 à 404 ou 705 à 713 ou 904, 905) d'horodatation de l'intervalle de temps de création dudit fichier (203 et 204, 601 et 602, 701,903) :

   • on lit dans le bloc courant dateur (209, 703) : d’une part la valeur fournie (201, 501, 702) par ladite source d'entropie et d’autre part sa référence (201, 501, 702) qui définit la date de début, ces valeurs (201, 501, 702), éventuellement identique, peuvent être acquises sans tiers de confiance à l’aide d’un client lourd ou léger, pour en garantir l'intégrité;

   • on calcul et on formate, grâce auxdits traitements de formatage et de normalisation, lesdites consignes brutes (103, 104, 106, 107 ou 301 ou 709 à 712) en les corrélant à ladite valeur fournie (201 ou 501 ou 702), puis on les normalise en les affectant à la position spatiale (105, 108 ou 401 à 404), fréquentielle, temporelle (705 à 708) ou aux commandes (904, 905) du capteur (111,907) numérisant ledit paramètre (103,104,106,107, 301, 705 à 708, 709 à 712, 904 et 905) dans ledit système de coordonnées (109 ou 305 ou 901), • on procède à une suite de numérisation (203, 204 ou 601, 602 ou 701 ou 903) assistée (incrustations 105, 108, 110 ou 705, 706, 707, 708, 713) par ledit traitement d'assistance et conformément auxdites consignes (103 à 108, ou 301,401 à 404 ou 705 à 713 ou 904, 905) pour obtenir ledit fichier (203 et 204 ou 601 et 602 ou 701 ou 903), • on calcule une valeur d’ancrage (205 ou 809) dudit fichier (203 et 204 ou 701 ) selon une seule (212, 808) ou plusieurs (1001, 1005, 1007, 1009, 1011, 1013 ou 1001, 1003, 1005, 1007, 1009, 1011, 1013, 1014) fonctions cryptographiques lorsqu’une fonctionnalité additionnelle est associée à ladite valeur d’ancrage (809) ;

   • on génère au moins une transaction de notarisation (211, 811) dudit fichier (203 et 204, 701) dans un bloc subséquent (210, 704) audit bloc dateur (209, 703), la référence (214, 716) dudit bloc subséquent (210, 704) définit la date de fin, • on génère les références de notarisation qui inclut au moins la référence de la transaction (211,811) de notarisation, une référence (213, 718) audit bloc dateur (209, 703) étant liée à ladite transaction de notarisation (211,811) ;

   - en phase de validation de l’intervalle de temps horodaté on authentifie, sans aucun tiers de confiance, lesdites consignes probantes (103 à 108, ou 301,401 à 404 ou 705 à 713 ou 904, 905) sur la base dudit fichier (203 et 204, 601 et 602, 701,903) et desdites références de notarisation :

   • on vérifie l’intégrité du contenu des blocs dateurs (209, 501, 703) et subséquents (210, 704) en mettant en œuvre un client lourd ou un client léger pour accéder à ladite blockchain (202 ou 714) ;

   • on vérifie l’intégrité dudit fichier (203 et 204, 601 et 602, 701, 903) sur la base de son contenu, en relançant les calculs d’obtention de la valeur d’ancrage (205 ou 809) puis en la comparant avec celle enregistrée (205 ou 809) dans la blockchain (202, 714) ;

   • on relève l’horodatage de l’intervalle de temps de création (209 à 214 ou 702 à 716) dudit fichier (203 et 204, 701) dans lesdits blocs dateurs (209, 703) et subséquents (210, 704) et on lit la valeur de l'aléa fournie (201,501,702), • on recalcule, grâce auxdits traitements de formatage et de normalisation, lesdites consignes (103 à 108, ou 301,401 à 404 ou 705 à 713 ou 904, 905) d’acquisition sur la base de ladite valeur d'aléa fournie (201, 501, 702), • on vérifie, à l’aide de toutes analyses numériques pertinentes de l'état de l'art, que ledit paramètre est numérisé (103,104,106,107, 301, 705 à 708, 709 à 712, 904 et 905) selon lesdites consignes normalisées (103 à 108, ou 301,401 à 404 ou 705 à 713 ou 904, 905) et selon ledit référentiel local (109 ou 305 ou 901) dans chaque élément de ladite suite (203, 204 ou 601, 602 ou 701 ou 903) de numérisation, • on valide, à l’issue des vérifications conformes précédentes que ledit objet (101, 603, 604, 715, 903) a été pour la première fois numérisé dans ledit fichier (203 et 204, 601 et 602, 701, 903) dans l'intervalle de temps borné défini comme :

   - postérieur à ladite date absolue de début (201, 501, 702), dudit bloc dateur (209, 703), ledit fichier étant antérieurement inexistant;

   - antérieur à ladite date absolue de fin (214, 716) dudit bloc subséquent (210, 704).
3. 3 - Procédé selon la revendication 2 précédente caractérisé en ce qu’il est mis en œuvre avec une suite d’au moins une seule numérisation (203), dans le domaine de la photographie numérique exploitant les capacités calculatoires et les performances des capteurs (111) photographiques des équipements informatiques mobiles (smartphones, Tablette,..) et l’état de l’art en matière de traitement d’image, pour la prise de vue assistée d’un objet identifiable (101) selon ces contenus d’étapes :

   - en phase de définition :

   • on définit l'empreinte des blocs (201,214) d'une chaîne de bloc choisie (202) à la fois comme référentiel temporel absolu et comme source d'entropie, ces empreintes sont univoquement liée à une date exprimée en temps universel, • on définit comme référentiel local spatiale : la photographie (203) incluant l’objet (101) dans son environnement (206) et le système de coordonnées (109) en deux dimensions est donné par la définition de la photographie à produire (203), • on élabore le traitement de formatage des consignes brutes d'acquisition avec l'affectation des bits d'information du bloc dateur (201) aux coordonnées (103, 104) d’un cadre de consigne (105) dans lequel doit figurer l’objet (101) dans une (distance) proportion (108) minimale indiquée; les consignes brutes, pour une même surface dudit cadre (105), peuvent s'étendre à sa forme et son orientation;

   • on élabore le traitement de normalisation des consignes d'acquisition en fixant les dimensions dudit cadre (105) et dudit cercle (108) de proportion en cohérence avec le niveau de certitude souhaitée de non préexistence du contenu de la photographie à produire selon l’état de l’art en matière de traitement d’image et de capacité des capteurs (111) photographique, • on élabore le traitement d'assistance à la numérisation avec la fonctionnalité d'incrustation dans l'écran de prévisualisation dudit terminal (111) : dudit cadre (105) de consigne, de son cercle de proportion (108) et d'une croix de centrage (110);

   - en phase d'exploitation :

   • on lit dans le bloc courant dateur (209), la valeur d'aléa fournie (201) par la source d'entropie qui est sa référence (201) et la date de début, • on élabore, grâce auxdits traitements de formatage et de normalisation, à l’aide de bits d’information de la valeur de l’empreinte (201) du bloc dateur (209) lu, la consigne brute d’acquisition (103, 104) affectée prioritairement aux coordonnées du cadre de consigne (105) associée à une proportion (108) applicables à la représentation numérique de l’objet (101) dans ledit système de coordonnées (109), • on procède à la numérisation (203) assistée (incrustations 105, 108, 110) conformément auxdites consignes (103, 104, 105, 108) pour obtenir ledit fichier (203), le rectangle de consigne est dessiné dans la photographie (203) obtenue ainsi qu’une zone d’information contenant des références (213) telles qu’un code matriciel encodant un lien hypertexte et/ou des références (213) relatives au présent procédé, notamment celle dudit bloc dateur (213);

   • on calcule une valeur d’ancrage (205) dudit fichier (203) avec au moins la valeur produite par une fonction de hachage (212);

   • on génère au moins une transaction de notarisation (211) dudit fichier (203) dans un bloc subséquent (210) audit bloc dateur (209), la référence (214) dudit bloc subséquent (210) définit la date de fin ;

   • on génère les références de notarisation qui inclut au moins la référence de la transaction (211) de notarisation et la blockchain exploitée (202);

   - en phase de validation :

   • on vérifie l’intégrité du contenu dudit bloc dateur (209) et subséquents (210) à l'aide d'un client lourd ou d'un client léger ;

   • on vérifie l’intégrité dudit fichier (203) sur la base de son contenu, en relançant les calculs d’obtention de la valeur d’ancrage (205) puis en la comparant avec celle enregistrée (205) dans la blockchain (202) ;

   • on relève l’horodatage de l’intervalle de temps de création (201 à 214) dudit fichier (203) dans ledit bloc dateur (209) et subséquent (210) et on lit la valeur de l'aléa fournie (201 ), • on recalcule, grâce auxdits traitements de formatage et de normalisation, lesdites consignes (103, 104, 105, 108) d’acquisition sur la base de ladite valeur d'aléa fournie (201 ), • on identifie, à l’aide de programme informatique implémentant toutes techniques d’imagerie pertinentes de l'état de l'art, ledit objet (101) dans ladite photographie (203), • on vérifie dans la photographie (203) qu'au moins les coordonnées (103, 104) du cadre de consigne (105) sont conformes et que la représentation numérique de l’objet (101) y est normalisée (105, 108), l'ensemble selon les consignes calculées (103, 104, 105, 108), • on valide, les vérifications précédentes étant conformes, que l'objet (101) a été numérisé pour la première fois dans un intervalle de temps borné :

   - postérieur à ladite date absolue de début (201) dudit bloc dateur (209) ,

   - antérieur à ladite date absolue de fin (214) dudit bloc subséquent (210) .
4. 4 - Procédé selon la revendication 3 précédente caractérisé en ce que ladite suite est étendue à plusieurs numérisations (601, 602) avec les contenus d'étapes complémentaires suivant :

   - en phase de définition :

   • on définit des contraintes de forme et de surface minimale pour la zone de recouvrement entre deux photos successives (203, 204 ou 601,602), • on définit une valeur minimale de distance entre les positions successives du cadres de consigne (105) dans le référentiel local (109) de façon à ce que le contenu (203, 204, 601, 602, 603, 604) des fichiers à produire soit identifiable par référence interne entre deux contenus distincts :

   - le contenu de deux cadres de consigne, soit l’objet numérisé (603) dans le cadre de consigne d'un fichier (601) et une autre représentation numérique du même objet (604) dans le cadre de consigne d'un autre fichier (602),

   - le contenu d'un cadre de consigne d'une photographie avec le contenu d'une photographie complète, soit l’objet (604) dans le cadre de consigne d'une photographie (602) représenté dans une autre photographie complète (601) au sein de son environnement (605),

   - le contenu de deux photographie complète, soit l'objet (603, 604) et la zone de recouvrement (606) entre une photographie complète (601) et une autre photographie complète (602), • on élabore, pour chaque numérisation supplémentaire (204, 602), une consigne d’acquisition dédiée pour laquelle on extrait des bits d’information complémentaires de l’empreinte (201) dudit bloc dateur (209),

   - en phase d'exploitation :

   • l’assistance informatique peut être étendue à la prise de vue (204, 602) automatique grâce à un programme de reconnaissance d’image (image matching) dont la référence est le contenu numérisée de l'objet (101, 603) et/ou son environnement (206, 605) dans au moins l'un des cadres de consignes ou photographies (203, 601) précédents;

   - en phase de validation :

   • on identifie ledit objet sur les prises de vues successives (203, 204 ou 603, 604) à l’aide d’au moins un traitement de comparaison et de reconnaissance d’image (librairies OpenCV, ORB, ASIFT, SURF,..), ce traitement est étendue aux zones de recouvrement (605) et au calcul de la distance entre les cadres de consigne, • on valide l’horodatage lorsque l’analyse des photographies (203, 204 ou 601, 602) donne un nombre d’appariement (matches) dans des bornes minimales (de similarité) et maximales (d'identité), il est alors établi qu’elles (203, 204 ou 601, 602) ont été créés postérieurement à la date donnée (201) par ledit bloc dateur (209) de numérisation et antérieurement à la date donnée (214) par ledit bloc subséquent (210) de notarisation.
5. 5 - Procédé selon la revendication 2 caractérisé en ce que ladite suite de consignes s’appliquent à l’acquisition d'un vidéographie horodatée d’un objet/sujet pour lequel on élabore, à l’aide des bits d’information de l'aléa horodaté extrait (501 ou 702) d’un bloc dateur, des consignes d’acquisition selon les contenus complémentaires d'étape suivants :

   - en phase d'exploitation, on élabore une série de positions (301) ou d'angle de prise de vue (709, 710 et 711,712) du capteur, série définie dans un système de coordonnées (109 ou 305) du référentiel local associé ;

   - en phase de validation, les vecteurs de mouvement extraits de la vidéo produite sont avantageusement exploités pour valider la conformité de ladite série de consignes (301 ou 709, 710 et 711,712).
6. 6 - Procédé selon la revendication 5 caractérisé en ce qu’il est mis en œuvre pour la réalisation de vidéo horodatée à partir d'un capteur en déplacement (drone,...) pour lequel, en phase de définition, le parcours (301) est défini de telle sorte que l'aléa horodaté extrait (501) soit traité pour que le trajet (301) soit parcouru entre au moins un point de départ (302) et un point d'arrivé (303) dans une zone (304) à vidéographier couverte par un système de coordonnées (305) et dans laquelle est défini des sous-ensembles (bords 306 et 307, surfaces 308 et 309) respectivement chacun associé à une règle de déplacement (401, 404, 402, 403) permettant de fixer les probabilités du déplacement du capteur vers un point fixé, typiquement sur la ligne médiane (310) joignant le point de départ (302) et le point d'arrivé (303).
7. 7 - Procédé selon selon la revendication 2 caractérisé en ce que ladite suite de consignes s’appliquent à l’acquisition d'un fichier audio pour lequel on définit, exploite et valide une séquence temporelle (705 à 708 ou 904, 905) ou fréquentielle portant sur la nature et/ou la forme (904, 905) et/ou le contenu informationnel dont le support analogique est typiquement :

   - des ondes radioélectriques de signaux (902) radiodiffusés,

   - des ondes mécaniques sonores, préférentiellement vocalisées.
8. 8 - Procédé selon la revendication 7 caractérisé en ce qu’il est mis en œuvre pour la réalisation assistée d'un fichier audio horodaté grâce au microphone et à l'écran de visualisation d'un équipement informatique mobile (smartphone) et pour lequel, en étape de numérisation, on consigne une séquence audio temporelle sur l'acquisition du contenu informationnel d'ondes sonores vocalisées par l'utilisateur dudit équipement mobile, d'une suite de digits d'information quelconque (705, 706, 707, 708) pour lesquels l'assistance consiste en un marquage (masquage/démasquage, soulignement, colorisation,.....) temporalisé desdits digits, selon des écarts de temps corrélés aux valeurs de l'aléa extrait (702) du bloc dateur (703) de la chaîne de blocs (714).
9. 9 - Procédé selon les revendications 3 ou 4 ou 5 ou 7 ou 8 caractérisé en ce qu’il est mis en œuvre pour créer un fichier (701) biométrique (selfie) horodaté d'authentification biométrique et/ou de signature électronique biométrique pour lequel une empreinte (805 ou 806 ou 812 ou 1002 ou 1008 ou 1012) est exploitée comme valeur d’ancrage (809) d’un certificat autoproduit :

   - pour l’authentification biométrique (1002),

   - pour la signature électronique biométrique en cryptographie asymétrique avec la clé publique (806) et/ou la clé privée (1008, 1012) associée(s) et/ou le condensât de signature (805) produit ;

   - pour la signature électronique biométrique sans cryptographie asymétrique (812) ;
10. 10 - Procédé selon la revendication 2 caractérisé en ce qu'en plus, en phase d'exploitation, en début de l'étape de génération de ladite transaction de notarisation (211,811) :

    • on calcul une valeur d'ancrage (205, 809) permettant de déboucler un contrat intelligent (Smart Contract), cette valeur d'ancrage de débouclage (205, 809) est typiquement celle d'un document (contrat d'assurance, contrat d'achat/service, ...) incluant au moins l'empreinte dudit fichier (203 et 204, 601 et 602, 701,903) ;

    • on produit et implémente ledit contrat intelligent dans la blockchain exploitée, • on génère ladite transaction de notarisation (211, 811) qui déboucle ledit contrat intelligent uniquement si la valeur d'ancrage (205, 809) est égale à la ladite valeur de débouclage précédemment calculée.