Method for enhanced recording of a digital file

Abstract

The invention relates to a method for recording a digital file (FI) using a blockchain method, on a first terminal (SSC) provided with a device for acquiring an item of monitoring data (DS) from the terminal (SSC). According to the invention, the digital file (FI) is recorded on the blockchain in the form of a proof capsule (CP) comprising the file (FI) associated with an item of monitoring data (DS) acquired by the device (CAPD) when the file (FI) was recorded.

Description

Description Title of the invention: Enhanced recording method for a digital file technical field

[0001] The invention relates to the technical field of computerized storage of digital files and in particular to recording methods implementing blockchain methods. Previous art

[0002] In the legal field, digital files can be used as evidence, for example, to prove that a contract was indeed signed by the parties. A digital photograph can also help prove that an event took place on a given date and at a given location, because the digital file of the photograph includes metadata such as a timestamp and geolocation data.

[0003] However, computer technologies allow for the easy modification of digital files, making them easily contestable and therefore difficult to accept as evidence, as their probative value is insufficient. They are only considered as preliminary evidence.

[0004] There are secure terminals where hardware monitoring is performed, for example, using sensors placed on the terminal. However, it is the server itself that is monitored, not the data stored on it. Some courts therefore refuse to consider files from such servers as evidence, because they believe the files may have been falsified before being stored on the server, even if the storage is done using blockchain methods, or between the time the file is downloaded from the server and the time it is presented in court.

[0005] Furthermore, when the file storage server is located in a different country or state than the one where the dispute is being heard, the specific jurisdiction of the state where the dispute is being heard can make obtaining acceptance extremely complicated. said file as sufficient proof: territorial conditions and location of data storage may be predominant.

[0006] Finally, there are methods for storing a digital file using blockchain technology, in which the file is divided into chunks whose data volume is defined by the data volume of a block in the chain, according to the blockchain method used. These chunks are then stored in different blocks. However, these methods use public blockchains where the location of the servers (or computers) is random and therefore uncontrolled. Consequently, a digital file stored in this way may not be admissible in the jurisdiction of a given territory, especially since this method is sometimes illegal in certain countries depending on whether or not mining is implemented. Description of the invention

[0007] One of the aims of the invention is to overcome the disadvantages of the prior art by proposing a method of recording a digital file guaranteeing its authenticity, that is to say guaranteeing that this file has not been falsified.

[0008] Another objective of the invention is to be able to provide legally admissible digital files that can be used as evidence, including in an international context.

[0009] To this end, a method for recording a digital file using a blockchain method has been developed, on a first terminal equipped with a device for acquiring terminal monitoring data.

[0010] According to the invention, the recording of the digital file on the blockchain is done in the form of a proof capsule comprising the file associated with monitoring data acquired by the device during the recording or storage of the file.

[0011] In this way, the authenticity of the digital file is ensured by associating the file and the surveillance data within the same chain, which confers the expected probative force: indeed, it is no longer possible to modify or falsify the digital file and its surveillance data without it being detectable, because the digital fingerprints of the subsequent blocks in the chain do not would correspond more closely to that of the block containing modified data. Indeed, since falsification of files recorded using the method according to the invention is not possible, the "balance of probabilities" used by the majority of courts or jurisdictions therefore allows these files to be used as evidence.

[0012] The term "digital file" refers to the digital file itself, or its digital fingerprint (or "hash"). Smaller files can be stored directly on the blockchain. However, larger files can slow down blockchain transfers and copies because the blockchain's storage capacity increases too rapidly as new proof hashes are recorded.

[0013] It is possible to save either a file or its hash to the chain, depending on a test of the file size to be stored. For example: - we store the file if it weighs less than 512KB, or else - We store the digital fingerprint if the file weighs more than 512KB.

[0001] In the remainder of the document, the "digital file" is described, whether it is the file itself or its digital fingerprint.

[0015] Surveillance data means any type of data relating to the terminal (such as a serial number or MAC address), or its environment (such as its geolocation or environmental conditions), or its use (such as the timestamp of the recording or an identification of its user, for example a biometric fingerprint).

[0016] It is understood that a capsule comprises at least one digital file, but may also contain several. These could be, for example, photographs of each page of a contract or files of different types such as photographs, videos, or a database. The method implemented for the invention is a proof-of-authority type for its private blockchains, so that the registration of new blocks does not require mining, but that the registration of new blocks can only be done on terminals after validation by the approved and controlled proof-of-authority method. Thus, with the proof-of-authority method, trust in the deposited proof files rests on a system based on prior verification of the participants' identities. In general, blockchain methods with consensus algorithms are known in themselves and will not be detailed further.

[0017] Unlike a public blockchain method, the process according to the invention does not require a large number of nodes or multiple replications of the blockchain to prove its authenticity: its authenticity relies on the integrity of the proof of authority, which is private. This allows, among other things, a substantial saving in storage space, as the blockchain is not unnecessarily duplicated on an excessive number of servers.

[0018] In one particular embodiment, the file and at least one additional monitoring data point are acquired on a second terminal, such as a smartphone, and then transmitted to the first terminal, such as a server, where the evidence capsule is recorded. This capsule includes the file, the additional monitoring data from the second terminal, and the monitoring data from the first terminal. File acquisition can therefore be performed at multiple sites, and the recording is centralized, facilitating its protection and the monitoring of its integrity.

[0019] To ensure that the data is not tampered with before being recorded on the first terminal, the proof capsule is recorded on a remote blockchain on the second terminal before being transmitted to the first terminal, which records it on a local blockchain. Recording the data on a blockchain immediately upon acquisition prevents tampering from the moment of acquisition.

[0020] Because the blockchain method is private, it is possible to generate multiple chains in parallel, with the authenticity of each chain guaranteed by the integrity of the proof of authority. The remote blockchain can therefore be created and evolve independently of the local blockchain.

[0021] For added security, the evidence capsule includes an opening block and / or a closing block, each issued by the first terminal. These blocks are integrated into the capsule when it is saved on the second terminal, and they enclose the file and the additional monitoring data. In this way, the evidence capsule cannot be saved on the second terminal without the first terminal's authorization, through the issuance of an opening block and / or... A closing block. The use of the opening and closing blocks also allows the first terminal to monitor the status of the second terminal. For example, it is possible to detect if a second terminal has not been synchronized for too long.

[0022] The local blockchain and the remote blockchain each evolve in parallel, but mix the data from the local blockchain with that of the remote blockchain, thereby strengthening the overall security.

[0023] By "opening block," we mean a block in the chain that defines the beginning of a new evidence capsule. It is not a "genesis block," which corresponds to the first block in a chain according to the commonly used definition in this field.

[0024] To ensure the digital file is admissible in the jurisdictions of multiple states or countries, the evidence capsule is transmitted simultaneously from the second terminal to the first terminal and to several auxiliary terminals located in different jurisdictions. These auxiliary terminals are similar to the first terminal and function identically. The term "auxiliary terminal" is used only to distinguish these additional terminals from the first, but in practice, the first terminal and the auxiliary terminals are equivalent. They preferably operate in parallel, without a master / slave hierarchy.

[0025] In cases where the process involves auxiliary terminals, the proof capsule further comprises opening and / or closing blocks, each issued by the auxiliary terminals. The proof capsule cannot be generated without the involvement of the terminal present in each of the relevant jurisdictions. Its probative value is further enhanced by increasing the amount of data contained in the capsule's blockchain. Falsifying the capsule would require intervention on each terminal, which is not practically feasible. Moreover, since the proof capsule is considered to originate from the country where it is registered, it is deemed directly admissible in each jurisdiction where one of these terminals is located, without the need to implement multilateral treaties such as the Hague Convention of March 18, 1970.

[0026] To facilitate the communication of the evidence capsule to a third party, such as a judge or an insurer, each terminal is configured to issue a token corresponding to the evidence capsule—that is, a unique digital file corresponding to said capsule. The issuance of a token is recorded on the blockchain. Preferably, each token is unique and non-fungible. For the same storage volume reasons mentioned above: - the token may include the proof capsule if its volume is limited, or - the token may include identification data to attest to its correspondence with the proof capsule, if the volume of the proof capsule is too large.

[0027] Advantageously, in one embodiment, the file and monitoring data are erased from the second terminal's memory after being transmitted to the first terminal. This ensures the protection of sensitive data, such as personal data, in case the second terminal is stolen. It also helps manage the saturation of the second terminal's storage memory.

[0028] To verify the proper integrity of the terminals, the acquired monitoring data is compared to an expected monitoring data, and a difference between the acquired monitoring data and the expected monitoring data triggers an alert to a proof of authority of the blockchain.

[0029] In one embodiment, the proof capsule includes identification data comparable to the identification data of another capsule. This allows for the creation of a database of proof capsule identification data, and comparing the identification data of the capsules makes it possible to verify whether capsules are compatible with each other, thus defining a contract.

[0030] To ensure traceability of issued tokens, the storage of the token on a device is recorded on a blockchain in the form of a holding capsule. This capsule includes a unique identifier for the token proof capsule and the identity of the device owner, and preferably monitoring data from a device acquisition system acquired during token storage. The token owner's identity can be the identity of the owner of the device, or the identity of the user who opened a user session on the device or on the server that issued the token.

[0031] The invention also relates to a secure terminal comprising: - means of receiving evidence data, such as a photo sensor or a network card; - means of acquiring monitoring data, such as a GPS sensor; - means of data storage, such as a hard drive or an SD card; - blockchains recorded on storage devices - a computer program programmed to implement a process according to the aforementioned characteristics.

[0032] The invention also relates to a digital token from a digital file storage terminal, the terminal being equipped with a device for acquiring surveillance data, and the file being stored according to a blockchain method, the token comprising a proof capsule including the file associated with surveillance data acquired by the device during file storage.

[0033] Such a token makes it possible to guarantee that the contained file has not been falsified since its acquisition. Brief description of the drawings

[0034] [Fig. 1] illustrates a first embodiment of the invention, using only one terminal.

[0035] [Fig. 2] illustrates a second embodiment in which a first terminal and a second terminal are used.

[0036] [Fig. 3] illustrates another mode, in which the file and monitoring data are recorded on a remote blockchain before the capsule is recorded on the first terminal.

[0037] [Fig. 4] illustrates a mode where the first terminal emits an opening block and a closing block recorded on the remote blockchain.

[0038] [Fig. 5] illustrates a mode where the capsule is recorded on a first terminal and on an auxiliary terminal, each of them having emitted an opening block and a closing block.

[0039] [Fig. 6] illustrates the tracking of token possession. Detailed description of the invention

[0040] With reference to figure 1, the method according to the invention essentially consists of recording within the same blockchain (BU) a digital file (Fl) as well as a monitoring data (DS).

[0041] In practice, several surveillance data points (SDs) are used to build a body of evidence. The more complete the body of evidence, the stronger the probative value of the digital file (Fl).

[0042] Monitoring data (MD) may therefore include, but is not limited to: - reading a fingerprint sensor from the first terminal (SSC), allowing verification of who was the user of the terminal (SSC) when the file (Fl) was acquired; - a MAC address of the first terminal (SSC), making it possible to detect the generation of a falsified file from another terminal (SSC); - a geolocation of the first terminal (SSC); or a combination of several data points.

[0043] The first terminal (SSC) is therefore equipped with means for acquiring monitoring data (CAPD), for example any suitable sensor or reading means.

[0044] The first terminal (SSC) is also equipped with means of file acquisition (CAPF), for example a photographic sensor, or a means of communication enabling it to receive the digital file (Fl).

[0045] Of course, the first terminal (SSC) includes a rewritable storage memory (DQ) to record the digital file (Fl) as well as the monitoring data (DS), and runs a computer program programmed to perform the described acquisitions, recordings and process steps.

[0046] The computer program may include subroutines or run third-party applications, for example to drive sensors (CAPF, CAPD) from file (Fl) and / or monitoring data (DS).

[0047] The first terminal (SSC) is capable, by means of the program it executes, of issuing proof tokens (NFPs) comprising the proof capsule (CP). token (NFP) also includes additional data (DAdd), which may be, for example, a timestamp of the token issuance, an identifier of the user session that ordered the token (NFP) issuance, etc.

[0048] Multiple tokens (NFPs) of the same capsule (CP) can be issued, but each is a copy, and each token (NFP) is non-fungible because it contains unique additional data (DAdd). The tokens (NFPs) are, however, transferable.

[0049] With reference to Figure 2, the method implements a second terminal (APP) that acquires the file (Fl) as well as additional monitoring data (Fl'). The second terminal (APP) is similar to the first terminal (SSC) in that it includes means for acquiring the digital file (CAPF), means for acquiring the monitoring data (CAPF), a rewritable storage memory (DQ), and it executes a computer program programmed to implement the steps described.

[0050] To simplify the following explanations, the first terminal (SSC) will be referred to as the "server," and the second terminal (APP) as the "device." Indeed, although the first terminal (SSC) and the second terminal (APP) can be of any suitable type, a preferred method is to use a server (SSC) to which several mobile devices (APPs), such as smartphones, are connected. The connection between the device (APP) and the server (SSC) is preferably made via the internet and / or a mobile network.

[0051] Preferably, the device (APP) is also capable of issuing tokens (NFP).

[0052] Using a device (APP) allows the files (Fl) to be acquired remotely, possibly using several devices (APP), but to be saved centrally on the server (SSC).

[0053] In the mode illustrated in Figure 2, the device (APP) does not save the file (Fl) and the monitoring data (DS) as a blockchain and transmits them directly to the server (SSC).

[0054] With reference to Figure 3, the illustrated mode is similar to that of Figure 2 except that the device (APP) records the file (Fl) and the monitoring data (DS) on a remote blockchain (MBL), in a memory of the device (APP).

[0055] In this mode, the evidence capsule (CP) is therefore generated directly on the device (APP), and the file (Fl) and the monitoring data (DS) are transmitted to the server (SSC) in the form of an evidence capsule (CP).

[0056] This mode ensures that the file (Fl), from the moment it is acquired on the device (APP), is not falsified without this being detectable by the analysis of the capsule's blockchain (CP).

[0057] When the capsule (CP) is transmitted to the server (SSC), the server records it on its local blockchain (BU).

[0058] Figure 3 shows that when the capsule (CP) is issued, the device (APP) preferentially adds additional data (DAdd) in a similar manner to the additional data (DAdd) added when a token (NFP) is issued.

[0059] The capsule (CP) is thus dynamic: each transaction performed, for example the transfer of the capsule (CP) from one terminal (APP, SSC) to another, is recorded and traceable using this additional data (DAdd). When a token (NFP) is issued, it is therefore possible to trace the entire blockchain contained in the token (NFP) and know on which terminal (APP, SSC) the capsule (CP) was acquired, stored, when each transaction took place, etc.

[0060] Figure 3: - At the beginning, the capsule (CP) is generated on the device (APP) and includes only the file (Fl) and the additional monitoring data (Fl'). - Next, the transmission of the capsule (CP) to the server (SSC) adds a first block of additional data (DAdd). - Then the recording of the capsule (CP) on the server (SSC) completes the capsule (CP) with monitoring data (DS) from the server (SSC).

[0061] Figure 4 illustrates an embodiment in which the recording of the capsule (CP) on the device (APP) further includes an opening block (Op) and / or a closing block (Cl), each issued by the server (SSC).

[0062] By this intertwining of blocks generated by the server (SSC) and by the device (APP), falsification of the file (Fl) on the device (APP) is not possible.

[0063] The opening block (Op) and closing block (Cl) are also recorded on the server's local blockchain (BU) during their emission, which allows a trace to be kept even if the device (APP) does not send back a capsule (CP).

[0064] The opening block (Op) and the closing block (Cl) can be complete blocks of the local blockchain (BU). Alternatively, the entanglement of the local blockchain (BU) and the remote blockchain (MBL) can be achieved by exchanging only digital fingerprints (hashes), in order to limit the volume of data exchanged. In the remainder of this document, the terms "opening block" and "closing block" encompass both of these implementations.

[0065] This method allows the proof of authority of the blockchain to verify the behavior of the device (APP).

[0066] For example, the creation of a new capsule (CP) may only be possible if the server (SSC) issues the opening block (Op). A stolen device (APP) could therefore be rendered inoperable, ceasing to function if the server (SCC) stops providing it with opening blocks (Op).

[0067] Similarly, the use of a closure block (Cl) allows the return of a capsule (CP) to the server (SSC) only if control operations have been carried out: for example, if the device (APP) does not include biometric data sensors, the identity of the user of the device (APP) could be verified by another means before triggering the sending of the closure block (Cl) by the server (SSC).

[0068] The use of an opening block (Op) and a closing block (Cl) also makes it possible to verify that the capsule (CP) was indeed generated during a predefined time window, which further strengthens the security and probative value of the generated capsules (CP).

[0069] This mode also allows for the preparation of evidence capsules (CP) on the device (APP) even if it is offline and cannot communicate with the server (SSC): - The opening block (Op) is generated and then recorded on the remote blockchain (MBL) when the connection is established; then - The file (Fl) and the monitoring data (DS) are added to the remote blockchain (MBL) even if the device (APP) is offline; then - the closing block (Cl) is recorded on the remote blockchain (MBL) when the connection between the device (APP) and the server (SSC) is restored. The evidence capsule (EC) is only uploaded to the server (SSC) when the connection is restored.

[0070] Evidence capsules (CP) can therefore be prepared offline on the device (APP), by acquiring files (Fl) and monitoring data (DS), pending completion of the capsules (CP) with the closing block (Cl) as soon as the connection with the server (SSC) is restored.

[0071] Figure 5 illustrates a preferred embodiment in which: - the capsule (CP) is registered on several servers, namely a server (SSCI) and an auxiliary terminal (SSC2); - the file (Fl) is acquired on a device (APP), which records it with the monitoring data (DS) on a remote blockchain (MBL); - the recording of the capsule (CP) is subject to the emission of opening (Op) and closing (Cl) blocks by each of the servers (SSC).

[0072] In practice, the secondary terminal (SSC2) is preferably another server equivalent to the first terminal (SSCI). There is no hierarchy between these servers (SSCI, SSC2), and they function similarly.

[0073] Since the capsule (CP) is recorded on several servers (SSC), it is duplicated and there are now as many capsules (CP) as there are servers (SSC).

[0074] This mode guarantees: - that capsule (CP) generation was authorized, because the opening blocks (Op) were issued by the servers (SSC); - that the integrity of the device (APP) was recognized, because the closure blocks (Cl) were issued by the servers (SSC); - that the file (Fl) will be admissible as evidence in each State where the servers (SSC) are located, because each of these servers (SSC) participated in the generation of the capsule (CP): * since its origin, via the emission of opening blocks (Op); and * until it is recorded on the servers (SSC), via the issuance of closing blocks (Cl).

[0075] When a token (NFP) is issued by one of the servers (SSC), we see that it includes: - the file (Fl) whose authenticity is to be proven; - the monitoring data (DI) of the device (APP) that acquired the file (Fl); - each opening and closing block (Op, Cl) of each of the servers (SSC) involved; - monitoring data (DS) guaranteeing the integrity of the server (SSC2) from which the token (NFP) originates; - Additional data (DAdd) added during the issuance of the token (NFP).

[0076] Such a digital token (NFP) therefore includes the file (Fl) whose authenticity is to be proven, and a set of evidence bundles mixing surveillance data (DS), each transaction from the authorization of the acquisition of the file (Fl) on the device (APP) until its production in court being proven by the opening, closing and additional blocks (Op, Cl, DAdd).

[0077] Such a token (NFP) therefore makes it possible to obtain, within each State where a server (SSC) is located, a file (Fl) admissible as proof.

[0078] In one embodiment, the evidence capsule (EP) includes capsule identification data (TAG) that is comparable to the capsule identification data (TAG) of another capsule (EP). Matching the capsule identification data (TAG) of multiple capsules (EPs) determines whether these capsules (EPs) are compatible with each other. This matching can be managed: - by using the same capsule identification data (TAG) for several capsules (CP), in which case we verify that the capsule identification data (TAG) are identical; - by using different capsule identification data (TAGs), but sharing the same root (or an identical range), in which case we check that the capsule identification data (TAGs) share this common root; - using only unique capsule identification data (TAG), and for which the authorized matches are recorded in a matching database, in which case it is checked within the database whether the capsule identification data (TAG) of a first capsule (CP) corresponds to the capsule identification data (TAG) of the second capsule (CP).

[0079] This compatibility allows for the definition of pairings, or "contracts" between several capsules (CP).

[0080] In a first example, it involves checking the compatibility between a given piece of equipment and the consumable intended to power that equipment.

[0081] In a second example, it is a matter of verifying the adequacy between the action that a practitioner must perform, and the training he has received.

[0082] In a third example, it involves verifying the correspondence between a shipping slip for equipment, issued by a carrier, and a receiving slip.

[0083] In a fourth example, it is a matter of ensuring the correspondence between the obligations of the parties to a contract and their material or immaterial execution.

[0084] . In all cases, the capsule identification data (TAG) of a first capsule (CP) is compared to the capsule identification data (TAG) of a second capsule (CP), using a dedicated application.

[0085] If the capsule identification data (TAG) are compatible, then the contract is executed (with the previous examples: the consumable can be used on the equipment, the practitioner's action is authorized, or the goods are declared received).

[0086] On the other hand, if they are not compatible, the contract is not executed and the dedicated application can report the incompatibility, or even prevent pairing (with the previous examples: the operation of the equipment is prevented until a compatible consumable is presented, the practitioner's action is not authorized and / or the event is reported to a training organization).

[0087] Once a contract is executed, it can become expired in the capsule identification data (TAG) database, for example by changing a binary field in the database, which changes the contract from "to be executed" to "executed".

[0088] With reference to Figure 6, one embodiment provides that it is possible to track the holding, or ownership, of tokens (NFP).

[0089] When a token (NFP) is issued, it includes a unique identifier (Uld), for example within the additional data (DAdd).

[0090] The token (NFP) is transmitted to a first owner (P1), who stores it on their third-party device (AT). Preferably, the registration on the third-party device (AT) involves the acquisition of monitoring data (DS), similar to the servers (SSC) and devices (APP) mentioned above. Advantageously, identification data (Pld1) for the first owner (P1) is also acquired.

[0091] The identification data (Pld1) can be a photo or scan of an identity document, or the connection (via a username and password) to the third-party device (AT) receiving the token (NFP), or to the server (SSC) or device (NFP) issuing the token (NFP).

[0092] The unique identifier (Uld) of the token (NFP), the monitoring data (DS) of the third-party device (AT) and the identification data (Pld1) are recorded within a holding capsule (CD), which allows the ownership of said token (NFP) to be attested without, however, recovering all of its contents.

[0093] Similar to the aforementioned operations, the detention capsule (DC) can be created directly on the third-party device (TPD), or on a server (SSC).

[0094] If the token (NFP) is transferred to a second owner (P2), then monitoring data (DS) and identification data (Pld2) as well as the unique identifier (Uld) are recorded within a new detention capsule (CD2).

[0095] The detention capsules (CDs) are recorded on the server's blockchain (BU) to ensure the authenticity of the records, and participation in proof of authority.

[0096] To ensure the protection of owners' personal data (P1, P2), detention capsules (DCs) may be stored on a confidential server (SSC-CONF). This confidential server (SSC-CONF) maintains a detention blockchain (DB) on which the detention capsules (DCs) are recorded, in order to ensure their traceability and authenticity.

[0097] The confidential server (SSC-CONF) transmits anonymized detention capsules (CD') to the other servers (SSC) in the process; that is, the identifying data (P Id) is censored or partially removed. The anonymized detention capsules (CD') nevertheless contain identifying data. sufficient to be able to make the correspondence between the anonymized detention capsules (CD') and the original detention capsules (CD), by querying the detention block chain (BD) for example.

[0098] The tracking of successive detentions can be carried out by consulting the local chain (BU), by consulting the detention chain (BD) if implemented, or by consulting detention tokens (DH) issued by the server (SSC), which contain the unique identifier (ULD) of the token (NFP), and identification data (PLD) of the successive owners. The presence of monitoring data (DS) increases the probative value of the detentions.

[0099] In all cases, a comparison between the acquired monitoring data (DS) and an expected monitoring data (DS ref) is possible, and allows verification of the integrity of the terminal used, whether it is the device (APP), the server (SSC) or a third-party device (AT).

[0100] The comparison could be, for example: - a difference between the timestamp contained in the monitoring data (DS) of the terminal (SCC) and the timestamp contained in the additional data (DAdd) of the capsule (CP) transmission: too large a difference may mean that the device time (APP) has been changed, for example in order to backdate a capsule (CP); - a comparison between the opening and / or closing blocks (Op, Cl) issued by the server (SSC) and those contained in the capsules (CP) issued by the device (APP): if the same block (Op, Cl) comes back several times, this may mean that a malicious user is trying to send back to the server (SSC) fake capsules (CP) whose generation has not been authorized.

[0101] When a discrepancy is detected, an alert is issued to the proof of authority. This authority can then lock or quarantine the offending device (APP) or server (SSC).

[0102] It is understood that, since the blockchain method implemented is a "private method," all servers and devices used must be approved by proof of authority to execute the programs necessary for the implementation of the process. The installation and / or operation of programs installed on the servers (SSC), devices (APP), and third-party devices (AT) is therefore subject to proof of authority which authorizes or prevents the registration of blocks on the different chains (BU, MBL, BD).

[0103] Furthermore, the method and the token (NFP) can be shaped differently from the examples given without departing from the scope of the invention, which is defined by the claims.

[0104] In an unrepresented variant, the file (Fl) and the monitoring data (DI) are deleted from the device (APP) after being transmitted to the server (SSC), whether the device (APP) includes a remote blockchain (MBL) or not.

[0105] In the first case, the remote blockchain (MBL) may be completely removed from the device, in which case a new remote blockchain (MBL) initialization block must be provided to the device (APP) by proof of authority.

[0106] Otherwise, only the blocks including the file (Fl) and the monitoring data (DS) are deleted (as well as any downstream blocks in the chain), so that a new sequence of blocks can be created based on the remaining remote block chain (MBL).

[0107] In cases where the files (Fl) contain personal information, deleting the file (Fl) from the device (APP) facilitates compliance of the process with the General Data Protection Regulation (GDPR).

[0108] To protect the confidentiality of the file (Fl), the data can be saved in encrypted form.

[0109] Furthermore, the technical features of the various embodiments and variants mentioned above can be combined, in whole or in part. Thus, the invention can be adapted in terms of cost, functionality, and performance.

Claims

Demands [Claims 1] Method of recording a digital file (Fl) according to a blockchain method, on a first terminal (SSC) equipped with a device for acquiring monitoring data (DS) of the terminal (SSC) characterized in that the recording of the digital file (Fl) on the blockchain is done in the form of a proof capsule (CP) comprising the file (Fl) associated with monitoring data (DS) acquired by the device (CAPD) during the recording of the file (Fl). [Claims 2] A method according to claim 1, wherein the file (Fl) and additional monitoring data (DS) are acquired on a second terminal (APP), then transmitted to the first terminal (SSC) on which the recording of the evidence capsule (CP) is carried out, comprising the file (Fl), the monitoring data (DS) from the second terminal (APP) and from the first terminal (SSC). [Claims 3] A method according to claim 2, wherein the proof capsule (CP) is recorded on a remote blockchain (MBL) on the device (APP), before being transmitted to the first terminal (SSC) which records it in a local blockchain (BU). [Claims 4] A method according to claim 3, wherein the evidence capsule (CP) comprises an opening block (Op) and / or a closing block (Cl) each emitted by the first terminal (SSC), which are integrated into the capsule (CP) when it is registered on the device (APP), and which frame the file (Fl) and the monitoring data (DS) of the second terminal (APP). [Claims 5] A method according to any one of claims 2 to 4, wherein the evidence capsule (CP) is transmitted from the device (APP) to several auxiliary terminals located in several jurisdictions. [Claims 6] A method according to claim 5, wherein the proof capsule (CP) further comprises opening blocks (Op) and closing blocks (Cl) each emitted by the auxiliary terminals. [Claims 7] A method according to any one of claims 2 to 6, wherein each terminal (APP, SSC) is configured to issue a token (NFP) comprising the proof capsule (CP). [Claims 8] A method according to any one of claims 2 to 7, wherein the file (Fl) and the monitoring data (DS) are erased from a memory (DQ) of the second terminal (APP) after being transmitted to the first terminal (SSC). [Claims 9] A method according to any one of claims 2 to 8, wherein the acquired monitoring data (DS) is compared to an expected monitoring data (DS ref), and a difference between the acquired monitoring data (DS) and the expected monitoring data (DS ref) triggers an alert to a proof of authority of the blockchain. [Claims 10] A method according to any one of claims 2 to 9, wherein the evidence capsule (CP) includes capsule identification data (TAG) comparable with capsule identification data (TAG) of another capsule (CP). [Claims 11] A method according to any one of claims 2 to 10, wherein the storage of the token (NFP) on a third-party device (AT) is recorded on a blockchain in the form of a holding capsule (CD) comprising a unique identifier of the proof capsule contained in the token (NFP) and an identity data (Pld) of the owner of the third-party device (AT), and preferably a monitoring data (DS) acquired by an acquisition device of the third-party device (AT) during the storage of the token (NFP). [Claims 12] Secure terminal including: - means of receiving evidence data, such as a photo sensor or a network card; - means of acquiring monitoring data, such as a GPS sensor; - means of data storage, such as a hard drive or an SD card; - blockchains recorded on storage devices - a computer program programmed to implement a method according to one of the preceding claims. [Claims 13] A digital token (NFP) issued from a digital file storage terminal, the terminal being equipped with a data acquisition device surveillance, and the file being stored according to a blockchain method, characterized in that the token includes a proof capsule comprising the file associated with surveillance data acquired by the device during the recording of the file.

Images