Personal Data Management Methods, Terminal, and Server

Abstract

Processes, terminal and server for managing personal data A process for creating a personal data history (PDA) of a user is implemented by a user terminal (TA).It comprises: - a step of obtaining a symmetric encryption key (KSA) associated with a user profile; - a step (E50) of collecting the user's personal data (DPA); - as this personal data is collected: (i) a step (E52) of encrypting this personal data with the user's symmetric encryption key (KSA); and (ii) a step of recording (E56), in a general database (BDC), blocks (Bi) containing said encrypted data ([BiA]), said blocks (Bi) being organized according to a blockchain constituting a subgraph (SGA) of a general graph (GC) whose topology is defined by a pre-established data model, a root block of said subgraph (SGA) being associated with a public key of a digital wallet assigned to this user. Figure for the abstract: Fig. 5.

Description

Title of the invention: Methods, terminal and server for managing personal data. Prior art.

[0001] The invention relates to the general field of protection and management of users' personal data in a telecommunications network.

[0002] In this document, the "notion of personal data" is to be understood in a broad sense and refers to any data which a user wishes to be able to retain control over.

[0003] By way of non-limiting examples, the identity or address of a natural person, the data of a banking transaction carried out by a natural or legal person, a message exchanged on a telecommunications network, geolocation data of an individual, photographs or videos acquired by an individual or received from a third party, a digital contract constitute personal data within the meaning of the invention.

[0004] In the current state of the art, a user's personal data is generally managed by service providers to which the user subscribes.

[0005] For example, for a user who has a bank account and an account on a social network, it is common for the user to provide personal data to the bank on the one hand and personal data to the social network operator on the other hand.

[0006] As a result, the user loses control of his personal data, since it is very difficult for him to determine the processing carried out by service providers on this data. Description of the invention

[0007] According to a first aspect, the invention relates to a method for creating a history of a user's personal data, this method being implemented by a user terminal and comprising: - a step of obtaining a symmetric encryption key associated with a user profile; - a step involving the collection of the user's personal data; - as the user's personal data is collected: (i) a step of encrypting this personal data with the user's symmetric encryption key; and (ii) a step of recording, in a general database, blocks containing said encrypted data, said blocks being organized according to a chain of blocks constituting a subgraph of a general graph whose topology is defined by a pre-established data model, a root block of said subgraph being associated with the public key of a digital wallet of that user.

[0008] According to a second aspect, the invention relates to a management method, implemented by a computer system, for managing the personal data of a plurality of users, this method comprising the management of a general database in which blocks are recorded, each block containing said encrypted personal data of said user, said blocks containing the encrypted personal data of the same user being organized according to a chain of blocks constituting a subgraph of the same general graph whose topology is defined by a pre-established data model, a root block of said subgraph being associated with the public key of a digital wallet of this user.

[0009] The invention also relates to a management method, implemented by a personal data management server for a plurality of users, this method comprising the management of a general database in which blocks are recorded, each block containing said encrypted personal data of said user, said blocks containing the encrypted personal data of the same user being organized according to a chain of blocks constituting a subgraph of the same general graph whose topology is defined by a pre-established data model, a root block of said subgraph being associated with a public key of the digital wallet of this user.

[0010] Thus, and more generally, the invention proposes to store a history of users' personal data in a blockchain and to associate the history of a user's personal data with the public key of a digital wallet that they hold. For the purposes of the invention, users may include natural or legal persons.

[0011] Hereinafter, we define a "digital wallet" as a hardware or software device for the secure storage and management of digital files in the broadest sense and digital files uniquely associated with a user, such as cryptocurrency units and / or non-fungible tokens. As such, a digital wallet includes a public key associated with the user. Such a digital wallet can, for example, allow the user to conduct electronic transactions with another party by exchanging cryptocurrency units.

[0012] Thus, in accordance with the invention, a public key of a digital wallet points to the input node of a graph representing the history of a user's personal data according to a mapping defined by the pre-established data model.

[0013] The fact of associating all personal data in a block graph makes it possible, thanks to its probative value, to guarantee the immutability of the history of this data.

[0014] Associating all of a user's personal data with the public key of a digital wallet that he or she holds also allows a user to ensure the portability of his or her data in heterogeneous environments and to considerably simplify that user's access to new services.

[0015] Indeed, when a user's knowledge (KYC, "Know Your Customer") has been established by verifying the user's documents associated with the public key of a digital wallet in a first environment (for example, identity verification, credentials verification, eligibility verification, etc.) for a first service (for example, opening a bank account) and the proof of the result of this verification is integrated into the data associated with this public key, obtaining this public key allows, in a second environment, for the direct allocation of rights to this user for a second service (reservation of a vehicle, for example), without repeating the verification of their documents.

[0016] The invention thus proposes to use the public key of the digital wallet as an element of proof of the identity of the user, able to prove with the help of his private key associated with his public key that the digital wallet and therefore the associated data belong to him.

[0017] The use of a digital wallet's public key in the invention makes it possible to track the activity of a natural or legal person regardless of the environment. For example, if the public key of a digital wallet is held by a press organization (legal entity) and the digital content produced by this press organization is recorded in the general graph associated with this public key of a digital wallet, it is very simple, in any environment, to prove that one of these digital contents originates from this press organization.

[0018] In implementation, the proof of ownership constituted by the public key of a digital wallet can be managed either explicitly with a visible identity of the user, whether a natural or legal person, or completely anonymously. A user can disseminate digital information linked to the public key of a digital wallet anonymously, although third parties are able to verify that this information is indeed associated with said public key of a digital wallet.

[0019] In one embodiment, the blockchain is a ledger distributed within a peer network, the terminal being a peer of said network configured to store locally at least a part of said subgraph, said blocks being stored in a local database of said terminal.

[0020] The creation and consultation of a user's personal data history by that user's terminal can be carried out asynchronously, off-network, and resynchronized without degradation of the functionality and security of the solution.

[0021] In one embodiment, the data model defines that branches of said subgraph include blocks whose encrypted personal data correspond to time-stamped geolocation data of said terminal during a detected movement of said terminal.

[0022] In this embodiment of the invention, a user's terminal detects movements. When a new movement is detected, a new branch is created in the user's subgraph, linked blocks containing encrypted time-stamped geolocation data are integrated into the branch as the movement occurs, and when the terminal's position is detected to remain unchanged for a predetermined duration, the branch stops.

[0023] In one embodiment, the data model defines that blocks whose encrypted personal data correspond to a digital activity of the terminal on a given date or to data received from a third party on a given date are attached, in the user subgraph, to a block whose encrypted personal data correspond to geolocation data of said terminal time-stamped on said given date.

[0024] This embodiment advantageously allows for the dating and geolocation of all a user's digital activities. For example, it makes it possible to guarantee that a photograph acquired by a user's terminal was acquired on a given date and while the terminal was in a given location.

[0025] In a particular embodiment of the invention, personal geolocation data can be associated with evidence of the presence of the terminal at the given position at a given time, this evidence being, for example, evidence signed and provided by a telecommunications operator capable of validating this evidence by boundary marking.

[0026] In one embodiment, the process for creating a user's personal data includes a step of integrating into the user's subgraph a digital contract to which that user is a party, the contract being encrypted by a public key of the user's terminal, a public key of at least one other party to the contract and a public key of a digital trust environment, said contract comprising at least: - the user's symmetric encryption key encrypted with a public key from the digital trust environment; and - instructions that can be executed by said digital trust environment for: (i) decrypt at least part of said personal data of the user with the symmetric encryption key; (ii) verify that the public key of the digital wallet associated with the root block of the subgraph belongs to said user; (iii) analyze the decrypted personal data; and (iv) provide a result of said analysis to at least one party to the contract.

[0027] In this embodiment of the invention, the method for managing the personal data of a plurality of users includes a step of managing a set of instances of a digital trust environment, said instance being configured to: - execute instructions defined in a digital contract to analyze a part of the personal data of at least one said user party to the contract, said contract including a symmetric encryption key of said at least one party to the contract encrypted with a public key of said digital trust environment instance, said symmetric encryption key being able to be used by said instance to decrypt said personal data to be analyzed; - to provide a result of said analysis to at least one party to the contract.

[0028] According to this aspect, the invention proposes that contracts analyzing users' personal data be executed in a trusted environment, and not by the terminals of the contracting parties, so as not to expose their personal data. Execution in a trusted environment is also known to those skilled in the art by the English expression "confidential computing".

[0029] In a preferred embodiment, these contracts incorporate delegations of access to encrypted personal data intended exclusively for the trust environment in which this data is analyzed, this trust environment being configured to decrypt all or part of the personal data of a party to the contract, analyze it and transmit the results of the analysis to one or more parties to the contract.

[0030] This embodiment of the invention advantageously enables the execution of contracts between parties with heterogeneous environments. In particular, the invention allows for the portability of a user's data within the Metaverse (registered trademark), including the execution, within the Metaverse, of digital contracts requiring analysis of the parties' personal data while ensuring the protection of this personal data.

[0031] The invention also relates to a terminal comprising a processor configured to put in use: - a step of obtaining a symmetric encryption key associated with a user profile; - a step involving the collection of the user's personal data; and - as the user's personal data is collected: (i) a step of encrypting this personal data with that user's symmetric encryption key; and (ii) a step of recording, in a general database, blocks containing said encrypted data, said blocks being organized according to a chain of blocks constituting a subgraph of a general graph whose topology is defined by a pre-established data model, a root block of said subgraph being associated with the public key of a digital wallet of that user.

[0032] The invention also relates to a personal data management server for a plurality of users, this server comprising a processor configured to manage a general database in which blocks are recorded, each block containing encrypted personal data of a user, the blocks containing the encrypted personal data of the same user being organized according to a chain of blocks constituting a subgraph of the same general graph whose topology is defined by a pre-established data model, a root block of said subgraph being associated with the public key of a digital wallet of this user.

[0033] The general database used in the invention can be centralized (for example administered by the personal data management server) or distributed.

[0034] The invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer. This program includes instructions adapted to the implementation of a method for creating a history of personal data as described above.

[0035] The invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer. This program includes instructions adapted to the implementation of a method for managing the personal data of a set of users as described above.

[0036] Each of these programs can use any programming language, and be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0037] The invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions from the first or second or third computer program as mentioned above.

[0038] Information or recording media can be any entity or device capable of storing programs. For example, media can include a storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a hard drive, or a flash memory.

[0039] On the other hand, information or recording media can be transmissible media such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio link, by wireless optical link or by other means.

[0040] The programs according to the invention can in particular be downloaded onto an Internet-type network.

[0041] Alternatively, each information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of one of the methods according to the invention. Brief description of the drawings

[0042] Other features and advantages of the present invention will become apparent from the description below, with reference to the accompanying drawings, which illustrate an example of an embodiment without being limiting in any way. In the figures:

[0043] [Fig-1] [Fig.1] represents terminals, a data management server personal and instances of a digital trust environment that can be used in a particular mode of implementation of the invention;

[0044] [Fig.2A] [Fig.2A] represents a general graph that can be implemented in a particular embodiment of the invention;

[0045] [Fig.2B] [Fig.2B] represents a subgraph of the general graph of [Fig.2A] ;;

[0046] [Fig.3A] [Fig.3A] illustrates a contract proposal established by a first part;

[0047] [Fig.3B] [Fig.3B] illustrates a contract formed after acceptance of the contract proposal of [Fig.3A] by a second party;

[0048] [Fig.4] [Fig.4] illustrates the creation of a user account in a particular mode realization of the invention;

[0049] [Fig. 5] [Fig. 5] represents the main steps implemented for the creation of a user's personal data history;

[0050] [Fig.6] [Fig.6] represents the main steps implemented by the terminal of a user for the consultation of that user's personal data;

[0051] [Fig.7] [Fig.7] represents the main steps implemented for the establishment of a contract;

[0052] [Fig.8] The [Fig.8] represents the main steps implemented for the execution of a contract;

[0053] [Fig.9] [Fig.9] represents the hardware architecture of a terminal conforming to a particular embodiment of the invention; and

[0054] [Fig. 10] [Fig. 10] represents the hardware architecture of a server conforming to a particular embodiment of the invention; Description of the implementation methods

[0055] Fig. 1 represents the TA terminal of a user A, the TSP terminal of a service provider SP, an SDP server for managing the personal data of a plurality of users and ECN instances; of an ECN digital trust environment linked together by a NET telecommunication network.

[0056] In the embodiment described herein, the SDP personal data management server is configured to provide: - a HIST service for recording personal data; and - a GES-CONT digital contract management service using all or part of this personal data.

[0057] As described in detail below, the HIST personal data history service allows a user who subscribes to this service to create and maintain, from their mobile terminal, a history of their personal data, to give this history probative value and to ensure its portability by associating this history with the public key of a digital wallet held by this user.

[0058] The GES-CONT contract management service enables the execution, within a trusted digital environment (DNE), of a digital contract between at least two parties, without exposing the personal data of those parties. To this end, and as described later, the digital contracts managed by the invention incorporate a delegation of access to the user's personal data for the DNE.

[0059] In the embodiment described here, the SDP server for managing personal data further includes a GES-ECN module for managing this ECN digital trust environment.

[0060] This ECN digital trust environment constitutes a protected environment (in English, Trusted Execution Environment) in which contracts formed between two or more parties (natural or legal persons, service providers, ...) can be executed.

[0061] In the embodiment described herein, the GES-ECN module for managing a digital trust environment of the SDP personal data management server is configured to dynamically administer a number of ECN instance variable; ECNj of the ECN digital trust environment depending on the number of contracts to be executed.

[0062] In the embodiment described here, these ECNi, ECNj instances of the digital trust environment are cloned by the GES-ECN module. These cloned instances all include the same EXEC-CONT module for executing a contract and the same key pair comprising a public key KPUBECN and an associated private key KPRIVecn stored in rewritable non-volatile memory MECn-

[0063] In the embodiment described here, the TA terminal is a mobile phone.

[0064] In this example, we will assume that user A has downloaded and installed in his TA terminal an APP application from the SDP personal data management server, this application allowing user A to access the services offered by the server, in particular the HIST personal data history service and the GES-CONT digital contract management service.

[0065] The APP application includes an MCY cryptographic module.

[0066] In the embodiment described here, we will assume that the APP application further includes a GEN-CONT contract generation module allowing the user of the TA terminal to form contracts with one or more other parties for execution within the ECN digital trust environment. These operations are detailed later with reference to [Fig. 7].

[0067] Figure 1 represents the TA terminal after user A has opened an account with the SDP personal data management server to subscribe to the HIST service for recording their personal data. Steps E40 to E45 implemented by the TA terminal to open this account will be described later with reference to Figure 4. Following the opening of this account, a rewritable non-volatile memory MA of the TA terminal contains, in this example: - LOG / MP credentials (login, password) to allow user A to access their account via the local APP application; - a key pair consisting of a private key KPRIVA and a public key KPUBA; - a KSA symmetric encryption key; and - a unique confidential IDA identifier.

[0068] In the embodiment described here, the TA terminal includes an MDD module for detecting the movements of the TA terminal.

[0069] In this example, the MDD displacement detection module includes an AI artificial intelligence, a GPS geolocation module and an MVT motion detector including, for example, an accelerometer and a gyroscopic sensor to measure the linear acceleration, orientation and angular velocity of the TA terminal.

[0070] This MDD displacement detection module is configured to generate time-stamped personal geolocation data DPGE0A of user A, this data including positions P; occupied by terminal TA in the real world at dates T;.

[0071] In the embodiment described herein, the TA terminal also includes a CAM camera and a PAY payment application. Photographs acquired by the CAM camera and transactions carried out with the PAY application will be considered as DPDigActA personal data of user A, representative of digital activities performed by user A. Other digital activities may be envisaged, for example, sending or receiving messages (emails, text messages, etc.) carried out with messaging applications on the TA terminal not shown.

[0072] In the embodiment described here, the TA terminal is also configured to handle DP3rdPA personal data acquired from third parties, for example from an administrative service, a bank, an insurance company, a business, ...

[0073] Generally speaking, DPA will be denoted as the personal data of user A, which may, for example, include, but is not limited to, DPGeoA geolocation personal data, DPDigActA personal data representing digital activities and DP3rdPA personal data acquired from third parties.

[0074] In the embodiment described here, the SDP server includes a centralized general database BDC which stores the history of encrypted personal data of all users who have subscribed to the HIST service.

[0075] In the embodiment described here, the encrypted personal data of users is organized according to an n-dimensional blockchain.

[0076] In the embodiment described here, this n-dimensional block chain takes the form of a general direct acyclic graph Gc whose topology is defined by a pre-established data model which will be described below with reference to Figures 2A and 2B.

[0077] This blockchain constitutes a distributed ledger that can be updated within a peer network.

[0078] In the embodiment described herein, the terminal of a user who has subscribed to the HIST service for logging their personal data is a peer on this network. For example, the TA terminal maintains locally: - a local BDA database containing its own encrypted personal data; and - a copy of an SGA subgraph of the general graph Gc which contains the history of its own encrypted DPA personal data.

[0079] The TA terminal can thus work offline and asynchronously by exploiting the property of graphs.

[0080] Thus, in the embodiment described here, and as described later with reference to [Fig.5], when the TA terminal detects new DPA personal data to be recorded, this data is encrypted by the MCY cryptographic module of the TA terminal, stored in the BDA local database of the TA terminal, integrated by the TA terminal into the SGA subgraph local to the TA terminal before being synchronized, when a connection allows it, with the blockchain of the general graph Gc.

[0081] Synchronization between peers is ensured by the general database BDC. When a peer creates or receives a new block, it adds it to its copy of the register and then transmits it to its peer nodes. When the peer nodes receive it, they verify that the new block is valid. If the block is valid, they then integrate it into their register and transmit it in turn to their peers.

[0082] Fig. 2A illustrates an example of a general graph Gc representing the organization of encrypted personal data of all users TA, Tk of the HIST history service stored in the general database BDC managed by the SDP personal data management server.

[0083] In the example illustrated here, the general graph Gc includes in particular a subgraph SGa which represents the organization of the encrypted DPA personal data of user A in the general database BDC or in the local database BDa, assuming that these databases are synchronized.

[0084] As mentioned previously, the topology of the general graph Gc (and therefore in particular of the subgraph SGA) is defined by a pre-established data model.

[0085] Figure 2B illustrates more precisely the SGA subgraph which represents the organization of encrypted DPA personal data of user A in accordance with a particular data model.

[0086] In the particular case of this data model, the SGA subgraph is a direct acyclic graph. It includes, in particular, a root BRA and a set of branches made up of blocks connected to each other by arcs.

[0087] In the embodiment described here, the MDD displacement detection module of the TA terminal is configured to detect a type of movement of the TA terminal in the real world, for example, movement by car or movement on foot.

[0088] In the embodiment described here, and in accordance with the pre-established data model, the subgraph of a user's personal data includes, in particular, a branch for each of the detected movements of that user.

[0089] For example, in [Fig.2B]: - each of the branches Fl to F3 contains encrypted blocks with time-stamped personal geolocation data DPGE0A acquired during a car journey detected from terminal TA; - each of branches F4 to F5 contains encrypted blocks with time-stamped personal geolocation data DPGE0A acquired during a detected walk from terminal TA.

[0090] This example is not limiting, and other types of displacements not shown may be considered.

[0091] As more precisely represented for branch F5, each branch associated with a displacement comprises a set of blocks, each block B; comprising a geolocation P; and a date T;, encrypted which indicate that during the displacement associated with this branch F5, the terminal TA was located at position P; at time Tj.

[0092] When the MDD displacement detection module detects that a displacement has ended, for example, when the position of terminal TA is detected as unchanged for a predetermined duration, the branch stops. If a new displacement is detected, a new branch is created.

[0093] In the example of [Fig.2B] three blocks Bu, B have been shown in more detail; , Bi+i containing positions Pu, P, Pi+i at successive times Tu, T, Ti+i of terminal TA during a walk. Note that, as in accordance with the blockchain mechanism, each block B contains, in addition to its own encrypted data, an output hash H([BmA]) of the preceding block. This characteristic of hash functions makes any modification of the content of a block immediately visible in subsequent blocks.

[0094] According to the particular data model described here, the branches associated with the detected movements of a user's terminal constitute the main skeleton of a user's subgraph.

[0095] In the embodiment described here, the SGA subgraph may also include blocks containing encrypted DPDigActA personal data of user A acquired during digital activities carried out by terminal TA.

[0096] In the embodiment described here, the SGA subgraph may also include blocks containing encrypted DP3rdPA personal data of user A acquired from third parties.

[0097] In the embodiment described here, a block containing data associated with a digital activity or received from a third party on a given date is attached, in the SGa subgraph, to a block including that date and the geolocation of the TA terminal on that date.

[0098] Thus, by way of example, the following is shown in [Fig.2B]: - a node Bk containing an encrypted PIX photograph acquired by the CAM camera at time Tm when the terminal was at position Pu; - a node Br containing an encrypted AG contract received from a third party at time Ti+i while the terminal was at position Pi+i

[0099] This subgraph evolves dynamically, enriching itself with the user's personal data.

[0100] In a very advantageous way, the SGA subgraph of the blockchain containing the personal data DPA of a user A, guarantees the immutability of the history of this data and its authenticity when validated by an external trusted third party.

[0101] As is known to those skilled in the art, to give the graph its probative value, it is necessary, for example at regular intervals, to integrate into it data produced by an external trusted third party (for example, another blockchain). For example, terminals can transmit the hash of the last block of the graph to this trusted third party, the trusted third party produces information from this hash, and this information, signed by the trusted third party, is integrated into the graph.

[0102] In a particular embodiment, the history of a user's personal data is attached by the SDP personal data management server to a dynamic non-fungible token title.

[0103] For example, and as described later, with reference to [Fig.4], an output hash of the root block of a user's historical data subgraph can be associated by the SDP server with a public key of a digital wallet, said key being assigned by that server to that user.

[0104] The invention thus allows the user to link their personal data history to this KPUBWDA public key.

[0105] We will now assume that user A and service provider SP have subscribed to the GES-CONT digital contract management service and that they wish to establish a digital contract AGECNAjSp intended to be executed by an ECN instance; of the ECN digital trust environment so as not to expose the personal data of the parties to the contract during the execution of the contract.

[0106] We will assume that the TSP terminal of the service provider SP has downloaded a GEN-CONT contract generation application from the SDP server, compatible with that of the APP application downloaded by the TA terminal.

[0107] We will assume that a user of the SDP terminal used the GEN-CONT application to open an account with the SDP personal data management server to subscribe to the GES-CONT contract management service

[0108] Following the opening of this account, a non-volatile rewritable memory (MSP) of the TSP terminal includes, in this example: - LOG / MP credentials (login, password) to allow the user to access their account via the local GEN-CONT application; - a key pair consisting of a private key KPRIVSP and a public key KPUBSP; - a KSSP symmetric encryption key; and - a unique confidential identifier IDSP.

[0109] In the embodiment described here, the service provider SP uses its GEN-CONT application to establish a contract proposal denoted AGecn*a,sp- In the embodiment described here, the analyses to be carried out on the user data, their frequency, the duration of the contract, the format of the results, the rules for disseminating the result are explicitly described in the contract proposal.

[0110] An example of a proposed AGecn*a,sp contract is shown in [Fig. 3A]. This proposal includes: - a literal description interpretable by an ECN instance; of the ECN digital trust environment and / or a CODE executable by this ECN instance; to perform analyses on A's DPA personal data; - a DDP description of the DPA personal data of A on which the ECN digital trust environment must perform this analysis, for example the category of personal data (time-stamped geolocation data, photographs, messages, ...) and the time range concerned (personal data detected between such and such a date ...) - the start date DD, the end date DF and a periodicity PER of contract execution; - a format FORM in which the digital trust environment must return the result of the analyses to the different parties A, SP; - the KSSP encryption key of the SP part encrypted with the KPUBECN public key common to ECN instances; of the digital trust environment configured to execute the contract; and - a SIGSP signature of this contract proposal with the service provider's KPRIVSP private key.

[0111] The KSSP encryption key encrypted with the KPUBECn public key is denoted [KSspecn]•

[0112] When the TA terminal obtains this encrypted contract proposal, it verifies the SIGSP signature with the KPUBSP public key of the service provider SP.

[0113] If user A of terminal TA accepts the contract proposal, they insert their KSA encryption key encrypted with the KPUBECN public key common to ECN instances; from the digital trust environment, they sign this completed proposal with his private key KPRIVA, and inserts his SIGA signature into the contract proposal to form the AGecna> Sp contract. The KSA encryption key encrypted with the public key KPUBEcn is noted [KSAECN].

[0114] The AGecna> Sp contract thus formed is represented in [Fig.3B]. It incorporates delegations of encrypted personal data from parties A and SP exclusively to the ECN bodies; and to the ECN digital trust environment in which this data is analyzed.

[0115] In the embodiment described herein, the AGecnAjSp contract is signed with the KPUBA and KPUBSP public keys of parties A and SP to the contract, and with the KPUBEcn public key common to all ECN instances of the digital trust environment. Each of parties A and SP and any ECN instance of the ECN digital trust environment can thus decrypt the contract using its single private key.

[0116] The execution of the contract by an instance of the digital trust environment is described with reference to [Fig.8].

[0117] Figure 4 illustrates the main steps implemented in a particular embodiment of the invention to create a user account and assign a public key for a digital wallet. For illustrative purposes, consider the creation of a user A's account from their TA terminal and the creation of their KPUBWDA digital wallet public key by the SDP personal data management server.

[0118] During step E40, user A of terminal TA creates their account with the HIST personal data history service provided by the SDP server. In the embodiment described here, user A uses a local application APP previously downloaded by their terminal TA from the SDP personal data management server to obtain and store in the MA memory of terminal Ta: - LOG / MP credentials (login, password) to access their account via the local APP application; - a key pair consisting of a private key KPRIVA and a public key KPUBA; - a KSA symmetric encryption key; and - a unique confidential IDA identifier.

[0119] These elements (identifiers, key pair, symmetric encryption key, unique identifier) ​​are preferentially generated by the TA terminal, for example by the local application APP.

[0120] They are preferentially stored in a MA memory of the TA terminal.

[0121] During step E42, the terminal TA integrates its unique confidential identifier IDa into the root block BRA of its SGA data structure, and encrypts the root block BRa with its symmetric encryption key KSA. This encrypted data block is denoted [BRAA]. An output hash H([BRAA]) of the root block is calculated by applying the hash function H to the encrypted data block [BRAA].

[0122] During an E43 step, the root block BRA is associated with a DESC RA descriptor of this block, also encrypted with the symmetric encryption key KSA of terminal Ta. This encrypted descriptor is denoted [DESCRAA].

[0123] The DESC^ descriptor of the root block BRA is, for example, the string "Root block". This descriptor allows anyone who possesses the symmetric encryption key KSA to retrieve the root block BRA of user A's data structure.

[0124] The choice of descriptor can be arbitrary. However, in a preferred embodiment of the invention, the choice of descriptor is defined in the pre-established data model. This model contains, for example, a convention on the descriptors to be used.

[0125] In the embodiment described here, the root block does not have a hash linking it to one or more previous data blocks.

[0126] During step E44, the encrypted root block [BRAA] is stored in the local database BDA of terminal TA in association with its ciphertext descriptor [DESCraA]. The encrypted root block [BRA], and its associated ciphertext descriptor [DESCraA], are sent to the SDP server when a network connection is available. They are recorded in the general database BDC, and the encrypted root block [BRA] is synchronized with the general graph Gc.

[0127] During an E45 step, the TA terminal transmits the output hash H([BRAA]) of the root block BRA of its SGA graph to the SDP personal data management server.

[0128] During an E46 step, the SDP personal data management server creates a digital wallet public key KPUBWDA, grants ownership to user A, and associates the output hash H([BRAA]) of the root block with this KPUBWDA public key.

[0129] It should be noted that the output hash H([BRAA]) cannot be found in the different encrypted blocks and therefore cannot be associated with the data of user A unless one holds the symmetric encryption key KSA of that user.

[0130] Fig. 5 represents the main steps implemented for the creation of a user's DPA personal data history, for example for those of user A.

[0131] In the embodiment described here, the data can be of any type. For example, it can be declarative data, or data accompanied by evidence, for example a digital signature, or embedded secure links.

[0132] As mentioned previously, this DPA personal data may be time-stamped DPGE0A geolocation personal data of the TA terminal, acquired during detected movements of the TA terminal, for example during mobility activities (walking, cycling, running, traveling by vehicle, etc.). Such data includes, for example, GPS positions P, h, P, Pi+i at successive times Th, T, Ti+i of the TA terminal during a movement.

[0133] As mentioned previously, this DPA personal data may be DPDigActA personal data corresponding to digital activities carried out on the TA terminal, for example taking a photograph or video, exchanging messages, interacting with an application on the TA terminal.

[0134] As mentioned previously, this DPA personal data may be DP3rdPA personal data acquired from third parties, for example from an administrative service, a bank, an insurance company, a business, ...

[0135] In the embodiment described herein, the personal data (DPA) of user A is automatically integrated into the user's history as soon as it is detected by terminal TA. Alternatively, at least some data is integrated only with the express consent of the user on their terminal.

[0136] It is assumed that the TA terminal detects, during an E50 step, a personal data DPA to be integrated into the personal data history of user A.

[0137] During a step E52, the personal data DPA is integrated into a block B; of the SGA graph, the position of this block in the graph being defined by a pre-established data model.

[0138] As described previously with reference to Figure 2, this block B; comprises: - except for the root block BRA, the output hash Hk of each of the blocks Bk upstream of block B; in the SGA graph; and - the personal data DPA.

[0139] Terminal TA encrypts block B; with its symmetric encryption key KSA. This encrypted data block is denoted [Ba]. An output hash H([BA]) of block B; is calculated by applying the hash function H to the encrypted data block [BA].

[0140] During step E54, the ciphertext block B; is associated with a DESC; descriptor of this block, for example chosen according to the convention of the pre-established data model. This DESC; descriptor is also encrypted with the symmetric encryption key KSA of terminal TA. This ciphertext descriptor is denoted [DESCA].

[0141] For example: - the DESC descriptor; associated with a data block B; containing time-stamped DPGeoA personal geolocation data of the TA terminal, acquired during a car journey from the TA terminal on June 4, 2021 can be the string of characters "2021 / 06 / 04 II By car"; - the DESC descriptor; associated with a data block B; containing personal data DPDigActA corresponding to a digital activity of the terminal TA on 27 / 07 / 2021 can be the string of characters "2021 / 07 / 27 II photo" or "2021 / 07 / 27 II mail"; - the DESC descriptor; associated with a data block B; containing personal data DP3rdPA acquired from third parties by the TA terminal on 08 / 04 / 2022 can be the string of characters "2022 / 04 / 08 II bank".

[0142] During step E56, the encrypted data block [BA] is stored in the local database BDA of terminal TA in association with the encrypted descriptor [DESCa]. The encrypted data block [BA], associated with the encrypted descriptor [DESCA], is synchronized with the general graph Gc when a network connection is available.

[0143] It should be noted that the entire SGA graph representing the history of user A's personal data does not have to be permanently stored on terminal Ta. The regular updating of a collection of blocks in terminal TA's local BDA database can, for example, be defined by the data model and the current state of the graph. The strategy for retaining a partial history on terminal TA may depend on functional choices (data necessary for operation and for building a non-repudiable history) and performance considerations (latency of block access in the local database vs. online access).

[0144] The creation and consultation of the DPA personal data history by the TA terminal can be carried out asynchronously, off-network, and resynchronized without degradation of the functionality and security of the solution.

[0145] Figure 6 illustrates the main steps implemented by a user's terminal to access that user's personal data. The steps implemented by user A's terminal TA to access that user's personal data DPA are detailed as an example.

[0146] It is recalled that every encrypted block [BA] recorded in the blockchain, encrypted by a symmetric key KSA, is associated with a descriptor [DESCA] of this block, also encrypted with this same symmetric encryption key KSA.

[0147] Conversely, access to a data block B; is done from the associated descriptor DESC;.

[0148] Suppose that user A wishes to consult the blocks associated with a DESQ descriptor, for example consisting of the string "2021 / 06 / 04 II By car".

[0149] During an E60 step, the user chooses a descriptor in accordance with the convention of the pre-established data model.

[0150] During an E62 step, this DESQ descriptor is encrypted with the user's symmetric key KSa to produce an encrypted descriptor [DESCA].

[0151] During an E64 step, the cipher blocks [BA] corresponding to the cipher descriptor [DESCa] are identified.

[0152] During a step E66, the ciphertext blocks [BA] identified in the previous step (E64) are decrypted with the symmetric key KSA of terminal TA to produce the decrypted blocks B;.

[0153] Depending on the user's needs, the content of the decrypted blocks B can be presented to user A during a step E68. The SGA graph of the personal data DPa can be reconstructed using the hierarchy (parent-child links) between the blocks of the SGA graph, this hierarchy being able to be deduced from the hashes included in the data blocks.

[0154] It should be noted that the structure of the SGA subgraph can appear before or, advantageously, after decryption of DPA personal data.

[0155] The integrity of the SGA graph can be verified by the TA terminal.

[0156] Figure 7 represents the main steps implemented for the establishment of a contract between at least two parties. As an example, consider the establishment of an AGecnAjSp contract between a user A and a service provider SP who wishes to perform analyses on A's personal data DPA, this contract being intended to be executed in a digital trust environment ECN.

[0157] In the embodiment described here, during a general step E700, the SDP personal data management server manages a set of ECN, ECNj instances of the digital trust environment cloned from each other. As described previously, these instances all have the same EXEC-CONT module for executing a contract and the same public key pair KPUBECn, private key pair KPRIVECn. In the embodiment described here, instances are created or destroyed depending on the number of contracts recorded in the general graph Gc.

[0158] During a step E70, the SP party prepares a proposal for an AGECN*A Sp contract between the SP party and the A party.

[0159] This AG™*A, sp contract proposal includes, as shown in [Fig. 3A]: - a literal description interpretable by an ECN instance; of the ECN digital trust environment and / or a CODE that will be executed by this ECNi instance to perform analyses on A's DPA personal data; - a literal description interpretable by an ECN instance; of the ECN digital trust environment and / or a CODE executable by this ECN instance; to perform analyses on A's DPA personal data; - a DDP description of the DPA personal data of A on which the ECN digital trust environment must perform this analysis, for example the category of personal data (time-stamped geolocation data, photographs, messages, ...) and the time range concerned (personal data detected between such and such a date ...) - the start date DD, the end date DF and a periodicity PER of contract execution; - a format FORM in which the digital trust environment must return the result of the analyses to the different parties A, SP; - the KSSP encryption key of the SP part encrypted with the KPUBECN public key common to ECN instances; of the digital trust environment configured to execute the contract.

[0160] During step E71, the SP party signs the AGecn*AjSp contract proposal with its KPRIVSP private key. This signature is denoted SIGSP.

[0161] During an E72 step, the SP party transmits the AGecn*AjSP contract proposal and the SIGSP signature to the A party.

[0162] If party A accepts the AGecn*Aj SP contract proposal, during an E73 step, the TA terminal signs the AGecn*Aj SP contract proposal, with A's KPRIVA private key. This signature is noted as SIGA.

[0163] During an E74 step, the TA terminal inserts this SIGA signature into the AGecn*Aj SP contract proposal along with its public KPUBA encrypted with the KPUBECn public key common to the different ECN instances; of the digital trust environment. The KPUBA public key encrypted with the KPUBECN public key is denoted [KPUBAECN].

[0164] The AGecn*Aj SP contract proposal initiated by party SP and thus accepted by party A can then be classified as an AGecna> SP contract formed between parties A and SP.

[0165] During step E75, the AGECNA SP contract containing the two signatures SIGSP, SIGa is asymmetrically encrypted with the parties' public keys KPUBA, KPUBSP A and SP and with the public key KPUBECN common to the different ECN instances; of the digital trust environment. The encrypted contract is denoted [AGecnAjSp].

[0166] During an E76 step, the AGecna,sp contract is associated with a DESCecn A>Sp descriptor, for example the string "Contract between A and SP". This DESCecnAj Sp descriptor is encrypted with the public keys KPUBA, KPUBSP of parties A and SP and with the public key KPUBECN common to the different ECN instances; of the digital trust environment. The encrypted descriptor is denoted [DESCecnAj Sp].

[0167] Each of the parties A and SP and any ECN instance; of the ECN digital trust environment can thus decrypt the contract using its single private key KPRIVA, KPRIVSP, KPRIVECN-

[0168] During a step E78, the encrypted contract [AGECNAjSp] and its encrypted descriptor [DESCecnAjsp] are integrated into the SGA graph of user A and the general graph Gc.

[0169] The cipher contract [AGecnAjSp] is indistinguishable in the general graph Gc.

[0170] In the embodiment described here, the SP server is notified (E79) that the contract encrypted [AGecna> Sp] is available in the general GC graph and that this contract has been incorporated into the SGSP graph of this server.

[0171] Figure 8 illustrates the main steps implemented for the execution of a contract in accordance with a particular embodiment of the invention. By way of example, we will consider the implementation of an AGecnAjSp contract established between a user A and a service provider SP, this contract being intended to be executed by an ECN instance within a digital trust environment.

[0172] As mentioned previously, the encrypted contracts are recorded in the SGA, SGSp graphs of users A, SP, ... and in the general graph Gc.

[0173] In one embodiment of the invention, users check whether contracts appear in their SGA, SGSp graph or in the general Gc graph. For this purpose, and as described previously with reference to [Fig. 6], they use descriptors that allow the identification of contracts in the blockchain, for example, descriptors consisting of the string "Contract".

[0174] Alternatively, it is the ECN instances; of the digital trust environment that perform these checks in the general graph Gc.

[0175] During a step E80 which is repeated for example at regular intervals, the terminal TA searches, from their descriptors, for encrypted contracts [AG] which appear in its graph SGA or in the general graph Gc.

[0176] If the TA terminal identifies an encrypted contract [AGecna> Sp], it decrypts it with its KPRIVA private key during an E81 step.

[0177] During step E82, the TA terminal determines, based on the contract start date DD, the contract end date DF, and the contract periodicity PER, whether a contract execution is scheduled. If so, the TA terminal notifies an ECN instance of the digital trust environment during step E83.

[0178] During an E84 step, this ECN instance of the digital trust environment obtains the encrypted contract [AGecnAjSp] and decrypts it with its private key KPRIVecn.

[0179] As described previously with reference to [Fig.3B], the encrypted contract AGECN A> sp has the symmetric KSA, KSSp encryption keys of each of the parts encrypted with the public key KPUBECN of the ECN instance; (denoted respectively [KSaecn], [KSspecn]).

[0180] During an E85 step, the ECN instance decrypts the encryption keys encrypted with its private key KPRIVECn, and obtains the KSA, KSSP encryption keys from each of the parties.

[0181] The contract is executed by the ECNi instance of the digital trust environment according to the terms of the contract.

[0182] During an E86 step, the ECNi instance determines, based on the DDP description, which personal data of the parties must be analyzed, and then performs its analysis by interpreting the interpretable literal description DLII or by executing the CODE code included in the contract. During this analysis, the necessary personal data of the parties is decrypted by the ECN instance using the parties' symmetric encryption keys.

[0183] By following the parent-child relationships defined by the blockchain hashes for a party's subgraph, the ECN instance can verify that the digital wallet public key KPUBWDA associated with the root block BRA of the subgraph SGa belongs to user A (e.g. associated with user A's public key KPUBA in a database) and reconstruct the entire history of that party's personal data and perform an analysis on the personal data covered by the DDP description.

[0184] During step E87, the ECN instance formats the RES result of the analysis according to the FORM format defined in the contract. It encrypts this result with the public keys KPUBa, KPUBsp of parties A, SP. The encrypted result is denoted [RES].

[0185] During an E88 step, the RES result is associated with a DESCrbs descriptor, for example the string "Result of execution of the Contract between A and SP". This DESCrbs descriptor is encrypted with the public keys KPUBA, KPUSp of parties A, SP. The encrypted descriptor is denoted [DESCrbs].

[0186] During a step E89, the encrypted result [RES] and its encrypted descriptor [DESCres] are integrated into the general graph Gc and synchronized with the subgraphs SGa, SGsp of the contract parties, and the terminals of the parties are notified.

[0187] As described previously with reference to [Fig.4], when user A of terminal TA creates his account with the HIST personal data history service provided by the SDP server, the SDP personal data management server creates a KPUBWDA digital wallet public key, grants ownership to user A, and associates the history of encrypted personal data with this key.

[0188] Figure 9 shows the hardware architecture of a terminal according to the invention. It includes in particular a processor 10, a read-only memory 11 (of the "ROM" type), a rewritable non-volatile memory 12 (of the "EEPROM" or "NAND Flash" type for example), a rewritable volatile memory 13 (of the "RAM" type), and a communication interface 14.

[0189] The read-only memory 11 constitutes a storage medium according to an exemplary embodiment of the invention, readable by the processor 10, and on which a first computer program PI is stored according to an exemplary embodiment of the invention. Alternatively, the first computer program PI is stored in the rewritable non-volatile memory 12.

[0190] The first PI computer program enables the terminal to implement a method for creating a history of personal data in accordance with the invention.

[0191] Figure 10 shows the hardware architecture of a personal data management server according to the invention. It includes in particular a processor 20, a read-only memory 21 (of the "ROM" type), a rewritable non-volatile memory 22 (of the "EEPROM" or "NAND Flash" type for example), a rewritable volatile memory 23 (of the "RAM" type), and a communication interface 24.

[0192] The read-only memory 21 constitutes a storage medium according to an exemplary embodiment of the invention, readable by the processor 20, and on which a second computer program P2 is stored according to an exemplary embodiment of the invention. Alternatively, the second computer program P2 is stored in the rewritable non-volatile memory 12.

[0193] The second computer program P2 enables the personal data management server to implement a method for managing the personal data of a plurality of users in accordance with the invention.

Claims

Demands

1. A method for constructing a history of personal data (PD) of a user (A), this method being implemented by a terminal (TA) of the user (A) and comprising: - a step (E40) of obtaining a symmetric encryption key (KSa) associated with a profile of the user (A); - a step (E50) of collecting personal data (PD) of the user; - as said personal data (PD) of the user (A) is being collected: (i) a step (E52) of encrypting this personal data with the symmetric encryption key (KSa) of this user; and (ii) a step of recording (E56), in a general database (BDC), blocks (B1A) containing said encrypted data ([B1A]), said blocks (B1A)) being organized according to a chain of blocks constituting a subgraph (SGA) of a general graph (Gc) whose topology is defined by a pre-established data model, a root block (BRA) of said subgraph (SGA) being associated with a public key (KPUBWDA) of a digital wallet, said key (KPUBWDa) being assigned to this user (A).;

2. A method for constructing a history of personal data according to claim 1, wherein said blockchain is a ledger distributed within a peer network, said terminal (TA) being a peer of said network configured to locally store at least a portion of said subgraph (SGA), said blocks (B;) being stored in a local database (BDA) of said terminal (TA

3. )• Method of constructing a history of personal data according to claim 1 or 2, wherein said data model defines that branches of said subgraph (SGA) comprise blocks (B;) whose encrypted personal data correspond to time-stamped geolocation data of said terminal (TA) during a detected movement of said terminal (TA).

4. A method for creating a history of personal data according to claim 3, wherein said data model defines blocks (Bk, Br) containing encrypted personal data correspond to a digital activity of the terminal on a given date or to data received from a third party on a given date is attached in said subgraph (SGA) to a block (B;) whose encrypted personal data corresponds to geolocation data of said terminal (TA) time-stamped on said given date.

5. A method for constructing a personal data history according to any one of claims 1 to 4, said method comprising a step (E78) of integrating into said subgraph (SGa) a digital contract ([AGECNAjSp]) to which said user (A) is a party, said contract being encrypted by a public key (KPUBa) of said terminal (TA), a public key (KPUBSp) of at least one other party to the contract and a public key (KPUBECn) of a digital trust environment, said contract comprising at least: - the symmetric encryption key ([KSA]) of user (A) encrypted with a public key (KPUBECn) of the digital trust environment; and - instructions (DLII, CODE) that can be executed by said digital trust environment to: (i) decrypt at least a part of said personal data (DPA) of said user with said symmetric encryption key (KSA);(ii) verify that the digital wallet public key (KPUBWDA) associated with the root block (BRA) of the subgraph (SGA) belongs to said user (A); (iii) analyze said decrypted personal data; and (iv) provide a result of said analysis to at least one party to the contract.

6. A method for managing the personal data of multiple users, implemented by a server (SDP), this method includes the management of a general database (BDC) in which blocks (B;) are stored, each block (B;) containing said personal data of said user encrypted with a symmetric encryption key (KSA) of that user, said blocks (Bi) containing the encrypted personal data of the same user being organized according to a chain of blocks constituting a subgraph (SGA) of the same general graph (Gc) whose topology is defined by a pre-established data model, a root block (BRa) of said subgraph (SGA) being associated with a public key (KPUBWDa) of digital wallet of this user (A).

7. A management method according to claim 6, said method comprising a step (E700) of managing a set of instances of a digital trust environment, said instance being configured to: - execute instructions (DLII, CODE) defined in a digital contract (AGECNAjSp) to analyze a portion of said personal data (DPA) of at least one said user party to the contract, said contract comprising a symmetric encryption key ([KSA]) of said at least one party to the contract encrypted with a public key (KPUBECN) of said instance of digital trust environment, said symmetric encryption key (KSA) being able to be used by said instance to decrypt said personal data to be analyzed; - provide a result of said analysis to at least one party to the contract.

8. Terminal (TA) comprising a processor configured to implement: - a step of obtaining a symmetric encryption key (KSA) associated with a user profile (A); - a step of collecting personal data (DPA) of the user; and - as said personal data (DPA) of user (A) is collected: (i) a step (E52) of encrypting this personal data with the symmetric encryption key (KSA) of this user; and (ii) a step of recording (E56), in a general database (BDC), blocks (B1A) containing said encrypted data ([B1A]), said blocks (B1A)) being organized according to a chain of blocks constituting a subgraph (SGA) of a general graph (Gc) whose topology is defined by a pre-established data model, a root block (BRA) of said subgraph (SGA) being associated with a public key (KPUBWDA) of a digital wallet, said key (KPUBWDa) being assigned to this user (A).;

9. A server (SDP) for managing the personal data of multiple users, this server comprising a configured processor to manage a general database (BDC) in which blocks (B;) are recorded, each block (B;) containing said personal data of said user encrypted with a symmetric encryption key (KSA) of that user, said blocks (Bi) containing the encrypted personal data of the same user being organized according to a chain of blocks constituting a subgraph (SGa) of the same general graph (Gc) whose topology is defined by a pre-established data model, a root block (BRA) of said subgraph (SGa) being associated with a public key (KPUBWDA) of a digital wallet, said key (KPUBWDA) being assigned to that user (A).

10. Computer program (IP) comprising instructions for carrying out a method of constructing a personal data history according to any one of claims 1 to 5 when said program is executed by a computer.

11. Computer program (P2) comprising instructions for carrying out a method of managing the personal data of a plurality of users according to one of claims 6 or 7 when said program is executed by a computer.

Images