A method for registering digital objects on at least one blockchain

Abstract

A method for registering digital objects on at least one blockchain (BCN1), comprising the steps of creating a first off-chain object container (OC1(AG1), OF1(AG1)) associated with a reconciliation agent; receiving, between a first and a second time, requests (R1(AG1)) to register objects in the first object container issued by a first operator (OP1) and designating a first reconciliation agent (AG1); using the first reconciliation agent, generating reconciliation objects based on the off-chain object registrations that occurred between two times, and generating a reconciliation request (R2(AG1)); receiving, via the management platform, the reconciliation request and registering the reconciliation objects in a reconciliation wallet (SW1(AG1)) on the blockchain. Abbreviated figure: Fig. 1

Description

Title of the invention: Method for registering digital objects on at least one blockchain technical field

[0001] The present invention relates to the field of blockchain technologies, and more specifically to methods and systems for securing and processing off-chain transactions before their recording on a blockchain. It is particularly applicable to environments requiring secure and reliable management of off-chain transactions involving multiple operators, while guaranteeing the integrity and authenticity of the off-chain transactions. Background

[0002] With the increasing adoption of blockchains in various sectors such as finance, logistics, data management, identity management, and smart contracts, the need to secure off-chain operations has become paramount. Off-chain operations improve efficiency and reduce the costs associated with transactions on the main blockchain by offloading certain operations from the main network. However, this approach also introduces significant security challenges, including the need to ensure that off-chain operations are authentic, unaltered, and properly validated before being recorded on the blockchain.

[0003] Existing solutions in this area include the use of multi-signature mechanisms, hardware security modules (HSMs) for the secure management of cryptographic keys, and transaction aggregation processes to optimize resources. Despite these advances, these approaches have limitations in terms of flexibility, management complexity, and security level, particularly when it comes to coordinating the approval and validation of transactions by multiple entities or security devices.

[0004] More specifically, current methods of securing off-chain operations on blockchain have the following drawbacks:

[0005] - complexity of managing authorizations: coordination between multiple systems Security and operator approval for each transaction can become complex, error-prone, and difficult to manage on a large scale.

[0006] - Insufficient security: existing processes may not offer protection sufficient against attempts to falsify or alter transactions before they are recorded on the blockchain, thus increasing the risk of fraud.

[0007] - limited operational efficiency: the process of validating operations may generating delays and excessive resource consumption, thus limiting the overall efficiency of the system and increasing operational costs.

[0008] - lack of flexibility for modifications: known methods do not allow not easy management of modifications or deletions of off-chain operations once they are carried out, compromising the responsiveness and adaptability of the system to changing needs.

[0009] - absence of aggregation or processing of certain types of confidential data before their recording on a blockchain, for example measurements of physical quantities recorded on commissioned blockchains, hence an occupation of non-optimized memory space on the blockchain.

[0010] Thus, it might be desirable to strengthen the security and integrity of off-chain operations on a blockchain, which represents a technical challenge in the field of blockchain technologies.

[0011] It might be particularly desirable to provide a process for processing and securing off-chain digital objects for the purpose of registering objects on at least one blockchain, based on a hierarchical and redundant security architecture, and involving different parties to provide and process all types of off-chain objects before proceeding with registrations on blockchains. Summary

[0012] Embodiments relate to a method for registering digital objects on at least one blockchain, comprising the steps of: (i) providing at least one first operator and at least one first reconciliation agent; (ii) providing a system comprising an off-chain object management platform run by a server, a hardware security module connected to the management platform, and memory accessible to the hardware security module; (iii) providing the management platform with the address on the blockchain of a first reconciliation wallet; (iv) using the hardware security module, creating in memory a first off-chain object container associated with the first reconciliation agent;(v) receive, between a first instant and a second instant, via the management platform, object registration requests in the first object container issued by the first operator and designating the first reconciliation agent, an object registration request to add, modify or delete objects in the first off-chain object container; (vi) for each object registration request designating the first reconciliation agent, update the first object container according to the request using the hardware security module; (vii) using the first reconciliation agent, generate reconciliation objects according to the off-chain object registrations that occurred between the first and the second instant; secondly, and generate a reconciliation request containing the reconciliation objects and send it to the management platform; (viii) receive, via the management platform, the reconciliation request, and

[0013] (ix) using the management platform and the hardware security module, record the reconciliation objects in the first reconciliation wallet on the blockchain.

[0014] According to one embodiment, the step of generating reconciliation objects based on off-chain object entries that occurred between the first and second time points includes the steps of, by means of the first reconciliation agent: (i) evaluating the off-chain object entries that occurred between the first and second time points, based on at least one criterion chosen from among the times when off-chain object additions, modifications or deletions occurred, the nature of the off-chain objects added, modified or deleted, the content of the off-chain objects added, modified or deleted, and (ii) generating reconciliation objects based on the selected criteria.

[0015] According to one embodiment, the method comprises the steps of: (i) generating a private key and a public key; (ii) creating in memory an off-chain object management account defined by the private key and the public key and including the first object container in the off-chain object management account, and (iii) creating on the blockchain an object management wallet linked to the off-chain object management account and designated by an address generated from the public key of the object management account, and wherein the step of registering the reconciliation objects in the first reconciliation wallet on the blockchain includes the step of transferring, by means of the hardware security module, objects present in the object management wallet into the first reconciliation wallet.

[0016] According to one embodiment, the process also includes, in response to a reconciliation request, a step consisting of transferring objects present in the first reconciliation portfolio into the object management portfolio instead of transferring objects present in the object management portfolio into the first reconciliation portfolio.

[0017] According to one embodiment, (i) the objects are of the same type; (ii) the registration of objects in the first object container corresponds to modifications of the number of objects present in the first object container; (iii) the reconciliation request mentions a number of objects to be modified, and (iv) the step of registering the reconciliation objects in the first reconciliation wallet on the blockchain is carried out only if the reconciliation request mentions a number of objects to be deleted in the first object container.

[0018] According to one embodiment, the method also includes the step of, using the hardware security module and after receiving the reconciliation request, updating the first object container by modifying the objects it contains.

[0019] According to one embodiment, the method includes the step of providing at least a second operator to approve or reject a request to register objects in the first object container issued by the first operator and designating the first reconciliation agent, wherein the hardware security module is configured not to execute a request to register objects issued by the first operator without having received the approval of the second operator or without having received the approval of the second operator and that of the first reconciliation agent.

[0020] According to one embodiment, the second operator can also issue object registration requests in the first object container, and the hardware security module is configured not to execute an object registration request issued by the second operator without having received approval from the first operator or without having received approval from the first operator and that of the first reconciliation agent.

[0021] According to one embodiment, the method comprises the steps of using the hardware security module to: (i) encrypt the first container of objects in memory using an encryption key specific to the hardware security module;(ii) upon receiving a request to write objects to the first object container issued by the first operator and designating the first reconciliation agent, read the first object container from memory and decrypt it, write the request to write objects to it, re-encrypt the first object container and store it in memory, establish a secure communication channel with the second operator, provide it with the objects contained in the first object container and request its approval of the request to write objects, or establish secure communication channels with the second operator and the first reconciliation agent, provide them with the objects contained in the first object container and request their approval of the request to write objects, and (iii) receive approvals issued by the second operator or by the second operator and the first reconciliation agent, via the secure communication channels.

[0022] According to one embodiment, the method comprises, upon receipt of the first reconciliation request, the steps of using the hardware security module to (i) read the first object container from memory and decrypt it, writing the first reconciliation request to it; (ii) re-encrypt the first object container and store it in memory; (iii) establish secure communication channels with the first operator and the second operator, and provide them with the first container of objects and ask them to approve the reconciliation request; (iv) receive approvals issued by the first operator and the second operator via secure communication channels, and (v) read the first container of objects into memory and decrypt it, delete the record of the first reconciliation request, re-encrypt the first container of objects and store it in memory.

[0023] According to one embodiment, the method includes forecasting at least one second reconciliation agent and the steps of (i) providing the management platform with the address on the blockchain of a second reconciliation wallet; (ii) using the hardware security module, creating a second object container associated with the second reconciliation agent, and including the second object container in the off-chain object management account; (iii) receiving, between a third and a fourth time, via the management platform, requests to register objects in the second object container issued by the first operator and designating the second reconciliation agent, (iv) for each request to register objects designating the second reconciliation agent, updating the second object container using the hardware security module according to the request;(v) using the second reconciliation agent, generate reconciliation objects based on off-chain object registrations that occurred between the third and fourth time points, and generate a reconciliation request containing the reconciliation objects and send it to the management platform; (vi) receive, via the management platform, the reconciliation request issued by the second reconciliation agent; (vii) using the management platform and the hardware security module, register the reconciliation objects in the second reconciliation wallet on the blockchain.

[0024] According to one embodiment, upon receiving a request to register objects in the first object container, the hardware security module provides the second operator, or the second operator and the first reconciliation agent, with all the objects contained in the first object container and the objects contained in the second object container before asking them to approve the request to register objects.

[0025] According to one embodiment, at least one of the operators and reconciliation agent includes a personal security device equipped with a secure element, and a host device for the personal security device, capable of connecting to the management platform, the secure element being configured to connect to the hardware security module via a channel secured by an ephemeral session key which is known only to the secure element and the hardware security module.

[0026] According to one embodiment, at least one of the operators and reconciliation agent comprises a computer device including a program interface application allowing it to connect to the hardware security module via a channel secured by an ephemeral session key which is known only to the secured element and the hardware security module.

[0027] According to one embodiment, the method is applied to at least one of the following objects: values ​​of physical quantities measured by sensors or instruments, contract clauses, contracts, as well as smart contracts, digital security tokens, electronic records, identity documents, financial data, digital works in the form of NFTs, official documents such as notarized documents, and medical data or medical records, crypto-asset units, cryptocurrency units, digital assets.

[0028] According to one embodiment, a reconciliation agent is a crypto-asset exchange management platform that remunerates off-chain transactions.

[0029] According to one embodiment, a reconciliation agent includes an object analysis management platform configured to automatically generate new objects from the objects present in the first object container at the time of reconciliation and taking into account the object registrations that occurred in the first object container between the first and second instants. Brief description of the drawings

[0030] Embodiments of the process will be described below by way of non-limiting reference in relation to the accompanying figures, among which:

[0031] - Fig. 1 shows the architecture of a system in which the process is implemented. artwork,

[0032] - [Fig.2] shows the organization of off-chain object counts in a memory of the system of [Fig.1],

[0033] - Fig. 3A and Fig. 3B show two examples of embodiments of members of the system of the [Fig.1],

[0034] - Figure 4 describes the steps for approving requests within the system of the [Fig.l],

[0035] - Figure 5 describes steps in processing requests within the system of the [Fig.1], including approval steps described by [Fig.4],

[0036] - Fig. 6A, Fig. 6B, Fig. 6C, Fig. 6D and Fig. 6E illustrate certain processing steps described in [Fig. 5], and

[0037] - Figures [Fig. 7A], [Fig. 7B], and [Fig. 7C] illustrate other processing steps described by [Fig.5]. Detailed description

[0038] Figure 1 shows an example of a system for implementing the method. The system comprises an SRV1 server connected to an HSM1 hardware security module comprising an internal memory MEM1 and equipped with an external memory MEM2.

[0039] The process involves at least one operator OP1 and one reconciliation agent AGI. The operator OP1 and the reconciliation agent AGI, as well as the server SRV1, can have access to at least one blockchain, here a plurality of blockchains BCN1,... BCNi... BCNn.

[0040] The operator OP1 sends off-chain object registration requests to the system, specifying the AGI agent and a particular blockchain. These off-chain object registration requests will be referred to hereafter as "RI type requests". The reconciliation agent AGI sends off-chain object reconciliation requests to the system, which will be referred to hereafter as "R2 type requests".

[0041] In one embodiment of the process, other reconciliation agents AG2, AG3 are provided. Each agent can be designated in RI type queries and send R2 type queries to the system.

[0042] In some embodiments, a second operator OP2 is provided, or even a third operator OP3 or more. The additional operator OP2 can, like the operator OP1, be provided to address RL type requests to the system. In other embodiments, the operator OP2 is only provided to approve or reject RI type requests issued by the operator OP1 and / or to approve or reject R2 type requests issued by the agent AGI or other agents AG2, AG3.

[0043] Each operator or reconciliation agent may comprise a plurality of members, with operator OP1 comprising MB1 members, operator OP2 comprising MB2 members, reconciliation agent AGI comprising MB11 members, reconciliation agent AG2 comprising MB12 members and reconciliation agent AG3 comprising MB13 members. Each member is connected or can connect to the PTF platform via a secure private or public link, for example an https link established via the internet or a virtual private tunnel VPN.

[0044] The SRV 1 server comprises an OS1 operating system and runs a PTF software platform that relies on the hardware security module for processing off-chain digital objects and related RI, R2 type queries. The HSM1 hardware security module comprises an OS2 operating system and runs an OMPGR program for managing off-chain objects and processing the aforementioned queries.

[0045] Off-chain object registration (RI) queries are intended to add, modify, or delete off-chain digital objects stored by the system. RI queries are issued to a specific reconciliation agent and will be denoted R1(AG1), R1(AG2), R1(AG3) to distinguish them. Furthermore, each query of type RI is issued in relation to a single blockchain BCN1,... BCNi... BCNn and concerns only that blockchain.

[0046] R2 type requests are sent to the platform by one of the reconciliation agents AGI, AG2, AG3 and are denoted R2(AG1), R2(AG2), R2(AG3). Like RI type requests, each R2 type request concerns only one blockchain.

[0047] Since the various blockchains are generally independent of each other and operate as autonomous networks without direct connection, aspects of the process described below in relation to one of the blockchains are assumed to be applicable to the other blockchains. However, different implementations of the process may be envisaged for different types of blockchains, depending on the intended application, the nature of the blockchain concerned, and the digital objects being manipulated.

[0048] RI requests allow operators to send requests to the platform to add, modify, or delete off-chain digital objects in a general off-chain object management account denoted ACC. This account is managed by the hardware security module HSM1 and is stored in MEM2 memory in encrypted form using an encryption key specific to the hardware security module. These off-chain digital objects have a form and content defined by the application in which the process is implemented, examples of which are provided later. They also have a form and content compatible with the BCNI,... BCNi... BCNn blockchain to which they are linked.

[0049] By means of the OMPGR object management program, the HSM1 hardware security module ensures, in addition to the management of the ACC account, the secure execution of RI or R2 type requests, the management of an approval process for these requests via secure communication channels, the signing of orders for the transfer of reconciliation objects on a blockchain, as well as various other tasks, some of which are described below.

[0050] Due to the independence of the different blockchains and to facilitate the processing of requests, the hardware security module is configured here to divide the memory space of the general account ACC into several particular off-chain object management accounts OACC1,... OACCi,... OACCn, each particular account being associated with a blockchain BCNI,... BCNi... BCNn.

[0051] The reconciliation requests R2(AG1), R2(AG2), R2(AG3) issued by the reconciliation agents AGI, AG2, AG3 communicate to the platform reconciliation objects provided by these agents after analysis of the additions, modifications or deletions of off-chain objects caused by the execution of RL type requests. The R2 requests are processed by the platform with the help of the hardware security module, so as to transfer the reconciliation objects to the relevant blockchain and thus transform them into on-chain objects.

[0052] In some embodiments, off-chain reconciliation objects are transferred to a reconciliation wallet specific to each reconciliation agent, the address of which has been communicated to the platform. Figure 1 schematically illustrates this:

[0053] - SW1(AG1), SW1(AG2), SW1(AG3) reconciliation portfolios specific to AGI, AG2, and AG3 reconciliation agents are present on the BCN1 blockchain.

[0054] - SWi(AG1), SWi(AG2), SWi(AG3) reconciliation portfolios specific to reconciliation agents AGI, AG2, AG3 and present on the BCNi blockchain, and

[0055] - SWn(AG1), SWn(AG2), SWn(AG3) reconciliation portfolios specific to reconciliation agents AGI, AG2, AG3 and present on the BCNn blockchain.

[0056] In certain embodiments and as also shown in [Fig.1], off-chain reconciliation objects can, according to indications in a reconciliation request, be transferred to one of the reconciliation wallets or to an object management wallet OW1,... OWi,... OWn provided in each BCNI, ... BCNi... BCNn blockchain, whose private key has been generated and is held by the hardware security module.

[0057] In other embodiments, reconciliation objects can be transferred from an object management wallet to a reconciliation wallet or vice versa. For this purpose, the platform uses the HSM1 hardware security module to sign a transfer order for the reconciliation objects to the reconciliation wallet. The platform generates the transfer order, the hardware security module signs the transfer order, and then the platform transmits the transfer order to a BCAST broadcast service included in the platform.

[0058] In order to sign reconciliation object transfer orders, the hardware security module may generate a master key KO associated with the general account ACC, and then generate, from the master key KO, private and public key pairs {pKl, PKI],... {pKi, PKi],... {pKn, PKn] each associated with an object management account OACC1,... OACCi,... OACCn, as shown in [Fig. 1]. Then, from the public key PKI,... PKi,... PKn of each key pair, the hardware security module generates an address ADDPK1, ADDPKi, ADDPKn of the object management wallet OWI,... OWi,... OWn provided in each blockchain BCNI,... BCNi... BCNn. Thus, the hardware security module has the private key pKl... pKi,... pKn of each OACCI,... OACCi,... OACCn object management account and can sign orders to transfer objects from these accounts to other accounts on the relevant blockchain.

[0059] In conclusion, as shown in [Fig. 1] and summarized in the table below, each off-chain object management account is associated, in the relevant blockchain, with an object management wallet whose hardware security module knows the private key, as well as reconciliation accounts at least one per reconciliation agent, whose respective addresses have been communicated to the hardware security module.

[0060] [Tables 1] MEM2 Blockchain memory (1) (2) (3) (4) (5) (6) (7) (8) BCNI OACC 1 pKl,PKl OW1 ADDPK 1 SWl(AGl) SW1(AG2) SW1(AG3) BCNi OACCi pKi, PKi OWi ADDPK i SWi(AGl) SWi(AG2) SWi(AG3) BCNn OACC n pKn, PKn OWn ADDPK n SWn(AGl) SWn(AG2) SWn(AG3)

[0061] Column descriptions: (1) Relevant blockchain; (2) Off-chain object management account; (3) Key pair associated with the off-chain object management account; (4) Object management wallet on the blockchain; (5) Address of the object management wallet on the blockchain; (6) AGI agent reconciliation wallet; (7) AG2 agent reconciliation wallet; (8) AG3 agent reconciliation wallet

[0062] For security reasons, the KO key is stored in the internal MEM1 memory of the hardware security module, although it is symbolically represented in MEM2 memory in [Fig. 1] to illustrate its assignment to the general ledger account ACC. Similarly, the key pairs {pKl, PKI],... {pKi, PKi],... {pKn, PKn] are never stored in MEM2 memory, although they are also represented there in [Fig. 1] to illustrate their assignment to the accounts OACC1,... OACCi,... OACCn. In practice, the key pairs {pKl, PKI],... {pKi, PKi],... {pKn, PKn] are preferentially recalculated by the hardware security module from the KO master key when required.

[0063] Figure 2 shows in more detail an example of the organization of the general off-chain object management account ACC in memory MEM2. The general ACC account, as indicated above, is subdivided into off-chain object management accounts OACCI, ... OACCi, ... OACCn, each associated with a particular blockchain BCN1, ... BCNi, ... BCNn, and to which the private and public key pairs {pKl, PKl], ... {pKi, PKi], ... {pKn, PKn} have been assigned.

[0064] The ACC general account includes an ACCDT account data field in which the operators OP1, OP2 and reconciliation agents AGI, AG2, AG3 are recorded, as well as governance rules, including issuance rules and Approval of RI or R2 type requests for each member MB1, MB2, MB11, MB12, MB13 of the reconciliation operators and agents. We can therefore distinguish between request originators and request approvers, as well as administrator members who can assign the role of originator or approver to other members; a member can hold several of these roles simultaneously.

[0065] Each OACC1,... OACCi, ... OACCn account is itself subdivided into off-chain object containers, one container per reconciliation agent. Thus:

[0066] - the OACCI account associated with the BCN1 blockchain includes an object container off-chain OC 1 (AGI) associated with the reconciliation agent AGI, an OC1(AG2) container associated with the agent AG2, and an OC1(AG3) container associated with the agent AG3,

[0067] - the OACCi account associated with the BCNi blockchain includes an OCi(AG1) container associated with the AGI agent, an OCi(AG2) container associated with the AG2 agent, and an OCi(AG3) container associated with the AG3 agent, and

[0068] - the OACCn account associated with the BCNn blockchain includes a container OCn(AG1) associated with the AGI agent, an OCn(AG2) container associated with the AG2 agent and an OCn(AG3) container associated with the AG3 agent.

[0069] Furthermore, each container OCl(AGl), OC1(AG2), OC1(AG3) includes an off-chain object field OFl(AGl), OF1(AG2), OF1(AG3) in which the hardware security module records off-chain objects and manages off-chain object registrations requested by RI type queries, as well as any modifications resulting from the execution of R2 queries.

[0070] Each field of off-chain objects OF1(AG1), OF1(AG2), OF1(AG3) being associated with a reconciliation agent and a blockchain, it is modified by the hardware security module only in response to RI type requests designating this agent and concerning this blockchain, or, where appropriate, in the context of the execution of R2 type requests issued by this same agent and for this same blockchain.

[0071] Similarly:

[0072] - each container OCi(AG1), OCi(AG2), OCi(AG3) includes a field of objects off-chain OFi(AG1), OFi(AG2), OFi(AG3) in which the hardware security module records off-chain objects in relation to the BCNi blockchain, and

[0073] - each container OCn(AG1), OCn(AG2), OCn(AG3) includes a field of objects off-chain OFn(AG1), OFn(AG2), OFn(AG3) in which the hardware security module records off-chain objects in relation to the BCNn blockchain.

[0074] In embodiments where the execution of RI and R2 type queries is subject to approval, the hardware security module also uses each off-chain object container to record RI and / or R2 type queries in pending approval. In some embodiments, only RI type requests or only R2 type requests can be submitted for approval.

[0075] Thus, the hardware security module records in the OC 1 (AGI) container the pending confirmation RI (AGI) requests designating the AGI agent and concerning the BCN1 blockchain, or the pending confirmation R2 (AG1) requests issued by the AGI agent and concerning the BCN1 blockchain. Similarly, the hardware security module:

[0076] - stores in container OC1(AG2) the R1(AG2) queries waiting for confirmation designating agent AG2 and concerning blockchain BCN1, or R2(AG2) requests awaiting confirmation issued by agent AG2 and concerning blockchain BCN1,

[0077] - stores in the OC1(AG3) container the R1(AG3) requests waiting for confirmation designating agent AG3 and concerning blockchain BCN1, or R2(AG3) requests awaiting confirmation issued by agent AG3 and concerning blockchain BCN1,

[0078] - stores in the OCi(AGl) container the Rl(AGl) requests waiting for confirmation designating the AGI agent and concerning the BCNi blockchain, or R2(AG1) requests awaiting confirmation issued by the AGI agent and concerning the BCNi blockchain,

[0079] - and so on.

[0080] Each off-chain object management account OACC1,... OACCi,... OACCn also includes an account data field ACCDT1,... ACCDTi,... ACCDTn containing information and governance rules specific to the relevant blockchain. This information and these governance rules enable the hardware security module HSM1 to verify received commands, for example, to determine whether they were issued by a member of the operators or reconciliation agents authorized to issue them, and which members are authorized to approve them, as well as the quorum applicable to approvals. Each field ACCDTI to ACCDTn also includes the public addresses of the reconciliation wallets specific to the agents AGI, AG2, AG3 on each blockchain.

[0081] When both operators OP1 and OP2 can each issue RI type requests, several scenarios must be distinguished:

[0082] (i) the two operators OP1, OP2 issue requests which concern the same OACCI off-chain object management accounts,... OACCi,... OACCn. In this case, operators OP1 and OP2 are "associated" and share the same process, the purpose of which is to register on-chain objects representing the off-chain requests issued by each operator and the approvals they have granted each other. Conversely, if an approval process is planned. Examples will be described later.

[0083] (ii) Operator OP1 issues queries concerning the off-chain object management accounts OACC1, ..., OACCi, ..., OACCn, while operator OP2 issues queries concerning other off-chain object management accounts, not shown in the figures. In this case, operators OP1 and OP2 are independent and each is not affected by the other's actions; the system manages several off-chain object management accounts in parallel. This scenario is equivalent to the simple simultaneous execution of the process described herein.

[0084] (iii) In a "hybrid" scenario combining cases (i) and (ii), each operator issues type 1 queries concerning its own off-chain object management accounts, but has approval rights over type 1 queries issued by the other operator, and / or approval rights over type 2 queries issued by reconciliation agents in response to type 1 queries issued by the other operator. This scenario, as before, amounts to the simple simultaneous execution of the process described herein. However, what is described with respect to query approvals applies to this scenario.

[0085] In embodiments where RI and / or R2 type requests must be approved, this approval is generally required from members other than those of the entity, operator, or reconciliation agent that issued them. For security reasons, however, it may be stipulated that RI or R2 type requests also be approved by the members of the entity that issued them. Indeed, as just discussed, the governance rules specific to each entity may provide for members authorized to issue requests and members authorized to approve them. Furthermore, it may be desirable for the entity issuing a request to be required to approve it to prevent a malicious person impersonating that entity from sending fraudulent requests to the platform.To simplify the description, requests for approval of a request sent to members of the operator or agent who issued the request will not be described below but may be considered implied, although not in themselves mandatory for the functional implementation of the process.

[0086] Figure 3A illustrates an embodiment of a member MB1, MB2, MB11, MB12, or MB13. The member comprises a natural person user (USR) equipped with a personal security device (PSD) associated with a host device (HDV) running a companion application (HSW). In one embodiment, the PSD personal security device includes a secure integrated circuit element (SE). The host device (HDV) is configured to connect to the PTF platform via a secure link, for example, HTTPS, and the secure element (SE) is configured to Establish a secure SCP communication channel with the HSM1 hardware security module via the HDV host device running the companion application. This type of security device is marketed, for example, by the applicant under the names "Ledger Blue"™ or "Ledger Stax"™, or an equivalent device. In this embodiment, request approvals provided by members are controlled by individuals.

[0087] Figure 3B represents another embodiment of a member MB1, MB2, MB11, MB12, or MB13 that can be used in the case of full process automation. The member comprises an ITD computer device running an APPGR application program designed to issue requests and request approvals, and an API application interface program enabling the APPGR application program, after it has connected to the PTF platform via a secure link, for example, HTTPS, to establish a secure SCP communication channel with the HSM1 hardware security module.

[0088] The creation of secure channels between the hardware security module and members MB1, MB2, MB11, MB12, MB13 can, in one embodiment, be ensured by means of a public key infrastructure (PKI) managed by a certification authority (CA). The members and the hardware security module each possess a private key, a public key, a certificate signed by the certification authority, or static certificate, as well as the public key of the certification authority, for example:

[0089] pL: private key of the certification authority

[0090] PL: public key of the certification authority

[0091] pD: member's private key

[0092] PD: Member's public key

[0093] CD = [PD, Sign(pL, PD)] : member certificate (static certificate), including its public key PD and a signature of its public key using the private key pL of the certification authority

[0094] pH: private key of the hardware security module

[0095] PH: hardware security module public key

[0096] CH = [PH, Sign(pL, PH)]: certificate of the hardware security module (static certificate), including its public key PH and a signature of its public key using the private key pL of the certification authority. The "Sign" signature function is, for example, generated using an ECDSA signature algorithm based on elliptic curves ("Elliptic Curve Digital Signature Algorithm").

[0097] To implement a secure communication channel, a key exchange is planned between the member concerned and the hardware security module, in order to generate a kH session key. This key exchange is, for example, a Diffie-Hellman key exchange performed according to the following steps:

[0098] i) The hardware security module generates a pair of ephemeral private keys (peH) and public keys (peH) using an asymmetric key generator, and then communicates its ephemeral public key (peH) to the member in an ephemeral certificate (CeH) that it has signed with its private key (pH), as well as its certificate (CH) signed by the trusted authority:

[0099] CeH = [PeH, Sign (pH, PeH)]

[0100] CH = [PH, Sign(pL, PH)]

[0101] ii) The member generates his own ephemeral private key pair (peD) and public key pair (peD), then communicates his ephemeral public key (peD) to the hardware security module in an ephemeral certificate (CeD) that he has signed with his private key (pD), as well as his CD certificate signed by the trusted authority:

[0102] CeD = [PeD, Sign(pD, PeD)]

[0103] CD = [PD, Sign(pL, PD)]

[0104] iii) The hardware security module verifies the signature of the member's ephemeral public key PeD using the public key PD present in its CD certificate, then verifies the signature of the public key PD present in the CD certificate using the public key PL of the certification authority, or vice versa (verification of the signature of the public key PD before verification of the signature of the ephemeral public key PeD).

[0105] iv) Similarly, the member verifies the signature of the ephemeral public key PeH of the hardware security module using the public key PH present in the certificate CH, then verifies the signature of the public key PH present in the certificate CH using the public key PL of the certification authority, or vice versa.

[0106] v) The hardware security module generates an ephemeral session key kH from its ephemeral private key peH and the ephemeral public key PeD of the member, using a key exchange function such as the ECDH function (elliptic curve-based Diffie-Hellman key exchange), i.e.:

[0107] kH = ECDH(peH, PeD)

[0108] vi) The member generates the ephemeral session key kH from its ephemeral private key peD and the ephemeral public key PeH of the hardware security module, using the same function:

[0109] kH = ECDH(peD, PeH)

[0110] The shared session key can then be used to secure approvals of RI or R2 type requests issued by members. In one embodiment, the hardware security module collects approval of an RI or R2 request from each member designated as an approver by a governance rule as follows:

[0111] i) The hardware security module generates a C challenge for request approval:

[0112] C = RandomBytes(32)

[0113] "RandomBytes(32)" being a known function that generates a 32-byte (256-bit) string of random data.

[0114] ii) The hardware security module creates a secure channel with the PSD personal security device or the member API interface, in the manner described above.

[0115] iii) The hardware security module sends the request description and challenge C to the member.

[0116] If the user USR ([Fig.3A]) or the computer device ITD ([Fig.3B]) approves the request, it signs the challenge C with its private key pD:

[0117] S = Sign(pD, C)

[0118] In one variant, the query description is concatenated with the challenge, or any other data:

[0119] S = Sign(pD, C II R)

[0120] iv) The member sends the signed challenge to the hardware security module.

[0121] v) The hardware security module verifies the S signature of the challenge.

[0122] vi) If the member rejects the request, it returns an error message to the module of physical security instead of returning the signature S.

[0123] Fig. 4 is a flowchart showing the use of RI and R2 type queries and illustrating query approval steps.

[0124] At a RIO step, a member sends a time-stamped RI or R2 type request on behalf of their organization. This member may be a member of operator OP1, a member of operator OP2 if the latter is intended to issue requests, or a member of one of the agents AGI, AG2, or AG3.

[0125] At an RI 1 step, the hardware security module establishes a secure channel with each approving member designated by the applicable governance rule, using a session key specific to the secure channel established with the member.

[0126] At step R12, the hardware security module sends the time-stamped request and a challenge to each recipient entity. A timeout, which can range from a few seconds to several hours depending on the target application, is initialized and then counted down by the hardware security module.

[0127] If, at an R13 step, before the timeout expires, the hardware security module receives an error message, the request is considered to have been refused.

[0128] If, at an R14 stage, the waiting period is exceeded, the request is also considered to be refused.

[0129] If, at an R15 step, the hardware security module receives a valid encryption of the challenge from the member concerned, it considers the request to be approved.

[0130] When all required approvals are received, at an R16 stage, the hardware security module sends each relevant member a time-stamped confirmation of receipt of all required approvals.

[0131] Figure 5 describes off-chain object management steps conducted by the hardware security module HSM1 in relation to the off-chain object container OC 1 (AGI) associated with the AGI reconciliation agent in the off-chain object management account OACC1 linked to the BCN1 blockchain. Figures 6A, 6B, 6C, 6D, and 6E illustrate some of these steps, and Figures 7A, 7B, and 7C illustrate a final step of converting off-chain objects to on-chain objects. In this example, it is assumed that: (i) both operators OP1 and OP2 are planned; (ii) each operator OP1 and OP2 can issue RI requests; and (iii) each operator must approve RI requests issued by the other operator. (iv) that each operator OP1, OP2 must approve R2 type requests issued by a reconciliation agent AGI, AG2, AG3; and (v) that each reconciliation agent AGI, AG2, AG3 must approve RI type requests issued by operators OP1, OP2.

[0132] During the execution of the steps shown in [Fig. 5], similar steps can be performed by the hardware security module in relation to the OC1(AG2) and OC1(AG3) containers associated with the AG2 and AG3 agents in the same OACC1 account. Similar steps can also be performed in relation to other off-chain object containers managed by the hardware security module, for example, the OCi(AG1), OCi(AG2), and OCi(AG3) containers associated with the OACCi account linked to the BCNi blockchain, or the OCn(AG1), OCn(AG2), and OCn(AG3) containers associated with the OACCn account linked to the BCNn blockchain.

[0133] At an IF step, the OF1(AG1) off-chain object field of container OC1(AGI) is in an initial state and contains OCOB1 off-chain objects, as illustrated in [Fig. 6A]. At the same time, the OF1(AG2) field of container OC1(AG2) contains OCOB2 objects, and the OF1(AG3) field of container OC1(AG3) contains OCOB3 objects.

[0134] In some embodiments, the OFl(AGl) field may be empty in the initial state. In other embodiments, the OFl(AGl) field may have been previously provisioned with OCOB1 objects by the HSM1 hardware security module. In other cases, the OCOB1 objects may be the result of previous RI (AGI) requests sent by one of the OP1 or OP2 operators.

[0135] As illustrated in [Fig. 6A], the OFl(AGl) field is linked to the OW1 object wallet on the BCNI blockchain by the fact that the ADDPK1 address on the BCNI blockchain of the OW1 wallet is generated from the PKI public key of the OACCI account to which the OC 1 (AGI) container in which the OFl(AGl) field is located is attached. The hardware security module is able to generate the address ADDPK1 and knowing the private key pKl, it is also able to sign off-chain object transfer orders from the OW1 wallet to the SWl(AGl) reconciliation wallet.

[0136] At a step S2, [Fig.5], the hardware security module is waiting for a request Rl(AGl) or R2(AG1).

[0137] After step S2, the hardware security module can therefore receive either of these requests. Figure 5 describes the case where the hardware security module processes three RI (AGI) requests received at times T1, T1', and T1", the set of processing steps for a request forming a processing loop S100 which is therefore executed at times T1, T1', and T1". Figure 5 also describes the case where the hardware security module receives a request R2 (AG1) at time T2 occurring after the processing of the RI (AGI) requests received at times T1, T1', and T1". The processing steps for request R2 (AG1) form an SI step 10 of converting off-chain objects into on-chain objects.

[0138] S100 loop for processing Rl(AGl) requests:

[0139] At an S3 step, the hardware security module receives a request Rl(AGl) issued by the operator OP1, containing off-chain objects and intended to modify objects in the container OCl(AGl). As illustrated in [Fig. 6B], in some embodiments, the request Rl(AGl) includes modifying off-chain objects M0C0B1 intended to be added to or subtracted from OCOB1 objects already present in the OFl(AGl) field. In other embodiments, the M0C0B1 objects in the request may also be intended to replace existing OCOB1 objects in the OFl(AGl) field.

[0140] At an S4 step, the hardware security module reads the OACC1 account from MEM2 memory and decrypts it.

[0141] At an S5 step, the hardware security module records the Rl(AGl) request in the OC 1 (AGI) container.

[0142] At an S6 step, the hardware security module encrypts the OACC1 account and stores it in MEM2 memory.

[0143] At an S7 step, the hardware security module requires approval from MB2 members of the OP2 operator and MB11 members of the AGI reconciliation agent designated as approvers by a governance rule. To this end, and as also illustrated in [Fig. 6B], the hardware security module provides them with an approval request for the RI (AGI) query, including the MOCOB1 objects it contains, as well as the full content of the OFl(AGl) field, i.e., the OCOB1 objects:

[0144] APPRO VE[R 1 (AG 1)] [MOCOB1] [OCOB1]

[0145] In one variant, the hardware security module provides the entire content of each field OF1(AG1), OF1(AG2), OF1(AG3) present in the OACC1 account, i.e. the objects OCOB1, OCOB2, OCOB3:

[0146] APPROVE[R1 (AG 1)] [MOCOB1 ] [OCOB1 ] [OCOB2] [OCOB3]

[0147] The hardware security module then activates the timeout in step R12, [Fig.4]. It is assumed in the following that the rejection cases of approval requests as referred to in steps R13 and R14 of [Fig.4] do not occur.

[0148] At step S8, the hardware security module receives approval from all solicited MB 11 members, according to the secure approval process described above. The hardware security module reads the OACC1 account from MEM2 memory and decrypts it.

[0149] At step S9, the hardware security module updates the OFl(AGl) field by modifying the objects it contains according to the Rl(AGl) query, and then clears the Rl(AGl) query. As illustrated in [Fig. 6C], the OFl(AGl) field now contains modified OCOB1' objects.

[0150] At an S10 step, the hardware security module encrypts the OACC1 account and stores it in MEM2 memory, then returns to the S2 wait step.

[0151] As indicated above, it is assumed here that the hardware security module receives two further Rl(AGl) requests at times Tl' and Tl" and therefore repeats the processing loop S100 comprising steps S3 to S10, then returns to the waiting step S2. As illustrated in [Fig. 6D], the OFl(AGl) field contains, after time Tl", modified objects OCOB1".

[0152] SI step 10 of converting off-string objects to on-string objects:

[0153] At a step SI 1 occurring at time T2 after executing the S100 processing loops, the hardware security module receives a request R2(AG1) issued by the reconciliation agent AGI and containing SOB reconciliation objects ("Settlement Objects"), as illustrated in [Fig.6D].

[0154] It should be noted that the hardware security module can be configured to cancel a pending RI request if it receives an approved R2 request from the issuing agent, and conversely, to cancel a pending R2 request if it receives an approved RI request from the issuing operator. To address these request synchronization issues, the platform can be configured to prevent an operator from creating an RI request if an R2 request is pending approval for the relevant blockchain, or conversely, to prevent an agent from creating an R2 request if an RI request is pending approval for the relevant blockchain.

[0155] At an S12 step, the hardware security module reads the OACC1 account from MEM2 memory and decrypts it.

[0156] At an S13 step, the hardware security module HSM1 records the request R2(AG1) in the container OC 1 (AGI).

[0157] At an S14 step, the hardware security module encrypts the OACC1 account and stores it in MEM2 memory.

[0158] At a step S15, also illustrated in [Fig.6D], the hardware security module requires the approval of approving members of OP1 and OP2, and provides them with the query R2(AG1) and the SOB reconciliation objects it contains, as well as the full content of the OFl(AGl) field, i.e. the OCOB1 objects:

[0159] APPROVE[R2(AG 1)] [SOB] [OCOB1 "]

[0160] In one variant, the hardware security module provides the entire content of each field OF1(AG1), OF1(AG2), OF1(AG3) present in the OACC1 account, i.e. the data OCOB1", OCOB2, OCOB3:

[0161] APPRO VE[R2(AG 1)] [OCOB 1” ] [OCOB2] [OCOB 3]

[0162] The hardware security module then activates the timeout in step R12, [Fig.4]. It is again assumed in what follows that the cases of rejection of approval requests as referred to in steps R13 and R14 of [Fig.4] do not occur.

[0163] At an S16 step, the hardware security module receives approvals from operators OP1, OP2, then reads the OACC1 count from MEM2 memory and decrypts it.

[0164] At step S17, the hardware security module erases the R2(AG1) query in the OC1 (AGI) container before re-encrypting and storing it in MEM2 memory, as illustrated in [Fig. 6E]. In some embodiments or under certain circumstances, the hardware security module also updates the OF1(AG1) field in the OCl(AG1) container, based on the SOB reconciliation objects, so that after this operation the container contains OCOB1 off-chain objects instead of OCOB1 objects. In other embodiments, or under other circumstances, the execution of the R2(AG1) query does not modify the OCOB1 off-chain objects.

[0165] At a step S18, the PTF platform registers the SOB reconciliation objects in the SW1(AG1) reconciliation wallet, either by object transfer or direct object registration. In one embodiment of this step illustrated in [Fig. 7A], the platform uses the hardware security module to sign, with the private key pK1 it holds, a transfer order for the SOB objects from the OW1 object wallet to the SW1 reconciliation wallet. In another embodiment illustrated in [Fig. 7B], the hardware security module uses the private key pK1 of the OW1 wallet to sign a direct registration order for the SOB objects in the SW1 reconciliation wallet, without transfer from the OW1 wallet. This embodiment is applicable, for example, with certain Private and permissioned blockchains allow new objects to be sent to a blockchain address without necessarily performing a wallet-to-wallet transfer, but the existence of the OW1 wallet linked to the private key pKl must be verifiable on the blockchain for the signed registration order to be executed. In yet another embodiment illustrated in [Fig. 7C], applicable particularly to certain private and permissioned blockchains, the hardware security module uses the private key pKl to sign a direct registration order for SOB objects in the SW1 wallet, without the prior creation of the OW1 wallet on the blockchain. Its existence is verified in the transfer order by the mention of the ADDPK1 address generated from the public key PKl or by the mention of the public key PKl itself.

[0166] Returning to [Fig. 5], in certain embodiments, the approval of the reconciliation request R2(AG1) at step S16 may, according to indications in request R2(AG1), be followed by:

[0167] - either of step S18 which has just been described, during which the objects of SOB reconciliations are recorded in the SWl(AGl) reconciliation portfolio, by transfer or direct registration.

[0168] - either of an S19 step during which the SOB objects are registered in The OW1 object wallet is transferred or recorded directly, instead of being recorded in the SW1(AG1) reconciliation wallet. In some embodiments, this step is performed by the AGI reconciliation agent, for example, by transferring the object from the SW1(AG1) reconciliation wallet if the latter belongs to the AGI agent, in other words, if it holds the private key for that wallet. In other embodiments, this step is performed by the hardware security module by directly recording the object in the OW1 wallet, or by transferring it from the SW1(AG1) reconciliation wallet if it holds the private key, which is feasible in some embodiments.

[0169] In one embodiment, the request is issued by operator OP2 at step S3. In this case, at step S7, the hardware security module requires the approval of operator OP1 and not that of operator OP2.

[0170] The process just described is susceptible to numerous other embodiments and applications. In one embodiment, operator OP2 has only an approval function and does not issue any requests. In this case, only operator OP1 can issue the RI-type request in step S3. In another embodiment, operator OP1 has only an approval function and does not issue any requests, while operator OP2 can issue requests. Figure 5 also applies to this embodiment, considering that the request is issued by operator OP2 in step S3 and that the approval of operator OP1 is required in step S7 instead of OP2. In another embodiment, operator OP2 is not required. In this case, at step S7, the hardware security module only awaits approval from the AGI agent, and at step S15, it only awaits approval from operator OP1. In yet another embodiment, operator OP2 is required as an approver, but no approval is requested from the reconciliation agents AGI, AG2, and AG3. In this case, at step S7, the hardware security module only awaits approval from operator OP2. In yet another embodiment, no approval is required from the hardware security module. In this case, steps S5 to S8 are removed and at step S9 the hardware security module updates the OFl(AGl) field by modifying the objects it contains in accordance with the RI (AGI) query, but does not need to write and then delete the Rl(AGl) query since it is executed without prior approval.Similarly, steps S13 to S16 are removed and the hardware security module does not need to clear the R2(AG1) request in step S17 since it did not register it in step S13.

[0171] The blockchains BCN1,... BCNi,... BCNn to which the off-chain objects are attached, as well as the queries which allow these objects to be manipulated, can be of various types.Each blockchain can be one of the following types: a public blockchain, open to all, decentralized, with a native cryptocurrency; a private and permissioned blockchain offering restricted access and centralized governance, not necessarily having a native cryptocurrency; a consortium blockchain, managed by a group of organizations, offering limited access to its members and shared governance; a hybrid blockchain, combining public and private networks, offering flexible data control and potential use of cryptocurrency; a blockchain without a native cryptocurrency, focused on data management, used in a private environment; or a specialized blockchain, designed for specific uses and which may have its own structures or mechanisms, etc.

[0172] The objects manipulated by the process can be of different kinds. They can include, for example:

[0173] - values ​​of physical quantities measured by sensors or instruments,

[0174] - contract clauses,

[0175] - contracts,

[0176] - smart contracts,

[0177] - digital security tokens,

[0178] - electronic files,

[0179] - identity documents,

[0180] - financial data,

[0181] - digital works in NFT format,

[0182] - official documents, for example notarized documents,

[0183] - medical data or medical records,

[0184] - units of crypto-assets or cryptocurrencies,

[0185] - digital assets, etc.

[0186] To generate off-chain reconciliation objects based on off-chain object registrations that occurred between two reconciliation queries (for example, between time T1 at step S3 and time T2 at step SI1 in [Fig. 5]), the reconciliation agents AGI, AG2, and AG3 evaluate the additions, modifications, or deletions of off-chain objects made between these two steps. This evaluation is performed based on at least one criterion chosen from the following criteria or a combination thereof:

[0187] - the times when additions, modifications or deletions of out-of-chain objects have occurred place,

[0188] - the nature of the off-chain objects added, modified or deleted,

[0189] - the content of out-of-chain objects that have been added, modified, or deleted.

[0190] Example 1: the presence of confidential documents of various kinds, submitted by Accessing a patient's medical record through RI-type queries (such as various medical documents) can lead to an automated diagnosis by a reconciliation agent powered by artificial intelligence. The first reconciliation objective, the medical diagnosis, is established based on the medical content of the documents in the record, including an assessment of a potential health problem (content-based analysis). The second reconciliation objective involves calculating a reliability rate for the diagnosis, based on the nature of the documents provided and their medical probative value (X-rays, scans, blood tests, issuing laboratory, age, and issue dates).The approval of these two reconciliation objects – the diagnosis on the one hand and its reliability on the other – leads to their registration on a specialized blockchain by the hardware security module, thus definitively sealing the diagnosis without disclosing the confidential documents from which it was developed.

[0191] Example 2: In the context of a negotiation, operators OP1 and OP2 propose contract clauses via RI requests. An artificial intelligence robot, acting as a reconciliation agent (AGI), then proposes, via an R2 request, a draft contract aimed at satisfying each operator. If the draft is approved by them, its recording on a blockchain definitively seals the agreement reached, without revealing the confidential data from which it was developed. In one embodiment, this example is implemented through a smart contract involving interactions between the AGI agent and operators OP1 and OP2, generating a need for reconciliation. operations. In one variant, operator OP1 is a company and operator OP2 is a trading platform. Agents AGI, AG2, and AG3 are law firms responsible for negotiating the clauses according to their area of ​​expertise.

[0192] Example 3: Off-chain and confidential cryptocurrency investments are made throughout the day by operator OP1 and are notified by the hardware security module to the AGI agent, acting here as an exchange agent accepting the off-chain investments. At the time of reconciliation, these investments result in a positive (gain) or negative (loss) result depending on the cryptocurrency's price movement throughout the day and the times the investments were made. The AGI agent therefore sends an R2 request to the platform, recording the gain or loss and containing a reconciliation object in the form of a quantity of cryptocurrency. In the event of a loss, as soon as the R2 request is accepted, the reconciliation object is automatically transferred by the hardware security module to the agent's SW1 wallet, using a cryptocurrency transfer order from the operator's OW1 wallet.

[0193] The examples mentioned above show that the rights to reject RI or R2 requests granted to members of operators and reconciliation agents designated as approvers by governance rules can be used in different ways. This can be a rejection on the merits, related to the nature of the requested change. For example:

[0194] - a non-negotiable clause proposed by an operator in an RI request and refused by the other.

[0195] - a reconciliation clause presented by an AGI, AG2 or AG3 agent in a R2 type query, which obviously contains an arbitration error and a bad aggregation of the clauses previously proposed by operators OP1, OP2.

[0196] - an unacceptable amount of crypto-assets that operator OP1 mentions in a RI type request aimed at performing an off-chain placement operation in the OACC1 account, because it is greater than the amount of cryptocurrency that the operator holds in the OW1 wallet on the BCN1 blockchain.

[0197] - a value of a physical quantity that is aberrant or in conflict with other values.

[0198] Rejections of RI or R2 type requests may also be issued due to a formal defect in the request. For example:

[0199] - an amending or reconciliation clause not conforming to a predefined format,

[0200] - a unit of physical quantity not accepted by the reconciliation agents,

[0201] - a poorly organized contract or file, etc.

[0202] The hardware security module itself can be equipped with the ability to control and reject RI or R2 type requests. In particular, it can verify that the requests are correctly formulated and contain all the information necessary to their processing, but also to exercise more in-depth control based on the information it holds about the ongoing process.

[0203] Depending on the intended applications, the process is susceptible to various implementation variations. The number of operators may be greater than two, but a single operator may also be required in certain applications. The number of reconciliation agents may vary, ranging from a single agent to a large number of agents for the same blockchain. The roles of the operators in the implemented process may also differ.

[0204] For example, the first operator OP1 may be a controlling administrator, owner of the ACC account, who introduces the second operator OP2 to the platform and connects them with exchange agents AGI, AG2, and AG3. The OACC1 account, defined by the private key pKl and the public key PKI ([Fig. 2]), is created by operator OP1 on behalf of operator OP2, who can use it via the hardware security module under governance rules established by operator OP1. The OW1, OWi, and OWn wallets on the BCN1, BCNi, and BCNn blockchains allow operator OP2 to deposit collateral funds and then send requests to the platform to provision the off-chain accounts OACC1, OACCi, and OACCn. The OP1 operator can control these movements and oppose them if these funds do not correspond with the funds in the OWI, OWi, OWn portfolios.Similarly, operator OP1 and the relevant exchange agents can verify that each modification of funds held in off-chain accounts OACCI, OACCi, OACCn, requested by operator OP2 via RI queries, is supported by sufficient credits in wallets OWI, OWi, OWn. In such an application, only operator OP2 is able to issue RI-type queries, while operator OP1 can reject these queries if necessary.

[0205] In this application example, the objects are of the same type, namely each object is a unit of cryptocurrency. Registering objects in the object container OCl(AGl) corresponds to adding, modifying, or deleting units of cryptocurrency in the object container. In case of loss, the reconciliation request R2(AG1) specifies a number of cryptocurrency units to be deleted from the off-chain object container OCl(AGl). The step of transferring the off-chain reconciliation objects SOB to the reconciliation wallet SWl(AGl), i.e., in this case, the transfer of a number of cryptocurrency units, is only performed if the operator has lost money.

[0206] In other embodiments, for example in the context of confidential contract negotiations by three operators OP1, OP2, OP3 considering being co-contractors, each operator has the right to send RI-type requests to the platform and to refuse RI-type requests sent by the other operators, or to reject the reconciliation clauses proposed by the AGI agent using artificial intelligence. In this case, the AGI agent does not have the right to reject RI-type requests or may do so under certain conditions (for example, clauses contrary to applicable law).

[0207] Embodiments of the method may also relate to process control based on information provided by smart sensors or instruments declared on the platform as operators OP1, OP2, OP3, etc. The method can, for example, be applied to monitoring the operation of the core of a nuclear power plant. An AGI agent equipped with artificial intelligence analyzes the data provided by the sensors and instruments via RI-type queries and, without revealing this confidential information, establishes a diagnosis of the operating state of the core, which is permanently recorded on a blockchain and may potentially be made public.An additional operator controller (OPm) can be provided to verify the consistency of measurements provided by sensors and instruments, and to prevent the hardware security module from recording inconsistent measurements in the OCl(AGl) off-chain object container, or even trigger an alert and dispatch experts to the site.

[0208] The process of the invention can be automated by using, as operators and agents, computer systems equipped with an API interface as illustrated in [Fig.3B].

[0209] In certain embodiments, the operators OP1, OP2 and any other operators, as well as the agents AGI, AG2, AG3, may consist of only one member MB1, MB2, MB11, MB12, MB13 ([Fig. 1]). In this case, each unique member of each entity can issue and approve requests.

[0210] In general, the process allows for the manipulation of confidential digital objects off-chain in a secure environment through the use of a hardware security module. The objective is to record reconciliation objects on a blockchain that depend on these confidential objects without disclosing them. In certain applications, these reconciliation objects can be made public, meaning they are not recorded in encrypted form on the relevant blockchain.

[0211] In some applications, the implementation of the process is advantageous because it addresses the need to aggregate objects before they are recorded on a blockchain. In other cases, the process is valued for the off-chain object reconciliation algorithms it uses, which are based on artificial intelligence. In still other applications, the process is particularly useful because it enables the automation of off-chain crypto-asset placement operations on different blockchains.

[0212] Other notable features of the process and the system implementing it include:

[0213] - the provision of an integrated system comprising a management platform off-chain operations executed by a server, a hardware security module (HSM) connected to the operations management platform, an off-chain object storage means (MEM2 memory) accessible to the hardware security module, secure storage through systematic data encryption, and secure connection means for each operator and reconciliation agent;

[0214] - the creation and management of containers by the hardware security module operations: receiving requests to create off-chain operation containers, creating digital containers containing specific identifiers and operation control parameters, securely encrypting the containers and storing them in the data storage medium;

[0215] - a secure process for validating operations: for each request for When an off-chain operation is performed, the hardware security module reads and decrypts the container, adds a description of the operation including an identifier of the designated execution reconciliation agent, establishes a secure communication channel with the control operator and the execution reconciliation agent, and requests their approval. Once the approvals are received, the container is updated to indicate acceptance of the operation, then is re-encrypted and stored;

[0216] - Dynamic management of off-chain object registrations: the process allows receive and process requests to add, modify or delete off-chain objects in containers, following a similar approval process to ensure the security and integrity of changes;

[0217] - reconciliation of off-chain operations: it makes it possible to reconcile off-chain operations designating a specific reconciliation agent, removing the corresponding operations from the container and recording them on the blockchain via a secure digital signature;

[0218] - multi-platform security: the process is also applicable to the Securing operations across multiple blockchains, enabling the simultaneous management of transaction flows across different blockchains.

[0219] The process offers various advantages in addition to those previously mentioned:

[0220] - enhanced security: the use of secure communication channels by Ephemeral session keys and the integration of a hardware security module ensure robust protection against attempts to falsify and alter off-chain operations;

[0221] - efficient and flexible operations management: the process allows for management centralized and secure operations, facilitating batch processing of transactions and offering the possibility to modify or delete operations in a controlled and secure manner;

[0222] - resource optimization: by grouping operations into containers encrypted, the process optimizes resource utilization and reduces costs associated with managing transactions on the main blockchain;

[0223] - multi-blockchain adaptability: the ability to secure conducted operations Simultaneously, on a plurality of blockchains, the process is adaptable to various environments and specific needs, offering a versatile solution for managing off-chain operations;

[0224] - Compliance and traceability: the process of validating multi-party requests and timed ensures complete traceability of operations, facilitating audits and guaranteeing compliance with applicable regulations.

[0225] Thus, the present invention offers a complete solution for securing off-chain operations on blockchains, overcoming the limitations of existing methods by offering increased security, efficient management and improved operational flexibility.

Claims

1. Demands A method for registering digital objects (SOBs) on at least one blockchain (BCN1), comprising the steps of: (i) providing at least one first operator (OP1) and at least one first reconciliation agent (AGI), (ii) providing a system comprising: - an off-chain object management platform (PTF) run by a server (SRV1), - a hardware security module (HSM1) connected to the management platform, and - a memory (MEM2) accessible to the hardware security module, (iii) provide the management platform with the address on the blockchain (BCN1) of a first reconciliation wallet (SWl(AGl)), (iv) using the hardware security module (HSM1), create in the memory (MEM2) a first off-chain object container (OCl(AGl), OFl(AGl)) associated with the first reconciliation agent, (v) receive (S3), between a first time (Tl) and a second time (T2), via the management platform, object registration requests (Rl(AGl)) in the first object container issued by the first operator (OP1) and designating the first reconciliation agent, an object registration request aimed at adding, modifying or deleting objects in the first off-chain object container, (vi) for each object registration request (Rl(AGl)) designating the first reconciliation agent, update (S9) using the hardware security module the first object container according to the request, (vii) by means of the first reconciliation agent: - generate reconciliation objects (SOBs) based on off-chain object registrations that occurred between the first and second instants, and - generate a reconciliation request (R2(AG1)) containing the reconciliation objects (SOB) and send it to the management platform, (viii) receive (SI 1), via the management platform, the reconciliation request (R2(AG1)), and (ix) using the management platform and hardware security module, register (S 18) the reconciliation objects in the first reconciliation wallet (SWl(AGl)) on the blockchain (BCN1).

2. A method according to claim 1, wherein the step of generating reconciliation objects (SOBs) based on off-chain object registrations that occurred between the first and second instants comprises the steps of, by means of the first reconciliation agent (AGI): (i) evaluating the off-chain object registrations that occurred between the first and second instants, based on at least one criterion selected from: - the instants at which additions, modifications or deletions of off-chain objects occurred, - the nature of the off-chain objects added, modified or deleted, - the content of the off-chain objects added, modified or deleted, and (ii) generating reconciliation objects (SOBs) based on the selected criteria.

3. A method according to any one of claims 1 and 2, comprising the steps of: (i) generating a private key (pKl) and a public key (PKI), (ii) creating in memory (MEM2) an off-chain object management account (OACC1) defined by the private key (pKl) and the public key (PKl), and including the first object container (OC1(AGI), OF1(AGl)) in the off-chain object management account (OACC1), and (iii) creating on the blockchain (BCN1) an object management wallet (OW1) linked to the off-chain object management account (OACC1) and designated by an address (ADDPK1) generated from the public key (PKl) of the object management account, wherein the step (S18) of registering the reconciliation objects (SOB) in the first reconciliation wallet (SW1(AGl)) on the blockchain (BCN1) includes the step of using the hardware security module,transfer objects from the object management portfolio (OW1) into the first reconciliation portfolio (SWl(AGl)).

4. A method according to claim 3, further comprising, in response to a reconciliation request (R2(AG1)), a step consisting transfer objects from the first reconciliation portfolio (SWl(AGl)) into the object management portfolio (OW1) instead of transferring objects from the object management portfolio (OW1) into the first reconciliation portfolio (SWl(AGl)).

5. A method according to any one of claims 3 and 4, wherein: (i) the objects are of the same type, (ii) the registration of objects in the first object container (OCl(AGl), OFl(AGl)) corresponds to changes in the number of objects present in the first object container, (iii) the reconciliation request (R2(AG1)) mentions a number of objects to be modified, and (iv) the step of registering the reconciliation objects (SOB) in the first reconciliation wallet (SW 1(AG1)) on the blockchain (BCN1) is conducted only if the reconciliation request (R2(AG1)) mentions a number of objects to be deleted in the first object container.

6. A method according to any one of claims 1 to 5, also comprising step (S 16) of, by means of the hardware security module (HSM1) and after receipt of the reconciliation request (R2(AG1)), updating (S 17) the first object container (OCl(AGl), OFl(AGl)) by modifying the objects it includes.

7. A method according to any one of claims 1 to 6, comprising the step of providing at least a second operator (OP2) to approve or reject an object registration request (Rl(AGl)) in the first object container issued by the first operator (OP1) and designating the first reconciliation agent, wherein the hardware security module (HSM1) is configured not to execute (R17) an object registration request issued by the first operator (OP1) without having received (S7) the approval of the second operator (OP2) or without having received (S7) the approval of the second operator (OP2) and that of the first reconciliation agent (AGI).

8. A method according to claim 7, wherein the second operator (OP2) can also issue object registration requests (Rl(AGl)) in the first object container, and the hardware security module (HSM1) is configured not to execute (R17) an object registration request issued by the second operator (OP2) without having received (S7) approval from the first operator (OP1) or without having received (S7) approval from the first operator (OP1) and that of the first reconciliation agent (AGI).

9. A method according to any one of claims 7 and 8, comprising the steps of, using the hardware security module (HSM1): (i) encrypting the first object container (OC1(AGI), OF1(AG1)) in memory (MEM2) using an encryption key specific to the hardware security module, (ii) upon receiving an object write request (R1(AG1)) in the first object container issued by the first operator (OP1) and designating the first reconciliation agent (AGI): - reading (S4) the first object container (OC1(AG1), OF1(AG1)) from memory (MEM2) and decrypting it, writing (S5) the object write request (R1(AG1)) to it, re-encrypting (S6) the first object container and storing it in memory (MEM2), - establishing a secure communication channel (SCP) with the second operator (OP2), provide it with the objects contained in the first object container (OCl(AGl),(OFI(AGI)) and request that it approve the object registration request (RI(AGI)), or establish (S7, RII) secure communication channels (SCPs) with the second operator (OP2) and the first reconciliation agent (AGI), provide them with the objects contained in the first object container (OCI(AGI), OFI(AGI)) and request that they approve the object registration request (RI(AGI)), and (iii) receive (S8) approvals issued by the second operator (OP2) or by the second operator (OP2) and the first reconciliation agent (AGI), via the secure communication channels (SCPs).

10. A method according to any one of claims 7 to 9, comprising, upon receipt of the first reconciliation request (R2(AG1)), the steps of, by means of the hardware security module (HSM1): (i) reading (S 12) the first object container in memory (MEM2) and decrypting it, writing (S 13) the first reconciliation request (R2(AG1)) to it, (ii) re-encrypting (S 14) the first object container and storing it in memory (MEM2), (iii) establish (S15, R11) secure communication channels (SCP) with the first operator (OP1) and the second operator (OP2), provide them with the first object container and request their approval of the reconciliation request (R2(AG1)), (iv) receive (S16) approvals issued by the first operator (OP1) and the second operator (OP2) via the secure communication channels (SCP), and (v) read (S16) the first object container into memory (MEM2) and decrypt it, delete (S17) the record of the first reconciliation request (R2(AG1)), re-encrypt the first object container and store it in memory (MEM2).

11. A method according to any one of claims 1 to 10, comprising the provision of at least one second reconciliation agent (AG2) and comprising the steps of: (i) providing the management platform with the blockchain address (BCN1) of a second reconciliation wallet (SW1(AG2)), (ii) using the hardware security module (HSM1), creating a second object container (OC1(AG2), OF1(AG2)) associated with the second reconciliation agent (AG2), and including the second object container (OC1(AG2), OF1(AG2)) in the off-chain object management account (OACC1), (iii) receiving (S3), between a third time (T1) and a fourth time (T2), via the management platform, requests to register objects in the second object container (OC1(AG2), OF1(AG2)) issued by the first operator (OP1) and designating the second reconciliation agent (AG2),(iv) for each object registration request designating the second reconciliation agent (AG2), update (S9) using the hardware security module the second object container (OC1(AG2), OF1(AG2)) according to the request, (v) using the second reconciliation agent (AG2): - generate reconciliation objects based on off-chain object registrations that occurred between the third and fourth time points, and - generate a reconciliation request (R2(AG2)) containing the reconciliation objects and send it to the management platform, (vi) receive (SI 1), via the management platform, the reconciliation request (R2(AG2)) issued by the second reconciliation agent (AG2), (vii) using the management platform and the hardware security module, record (S 18) the reconciliation objects (SOB) in the second reconciliation wallet (SW1(AG2)) on the blockchain (BCN1).

12. A method according to claims 9 and 11, wherein, upon receiving a request to register objects in the first object container (OCl(AGl), OFl(AGl)), the hardware security module (HSM1) provides (S7) to the second operator (OP2) or to the second operator (OP2) and the first reconciliation agent (AGI), all the objects contained in the first object container (OCl(AGl), OFl(AGl)) and the objects contained in the second object container (OC1(AG2), OF1(AG2)) before asking them to approve the request to register objects.

13. A method according to any one of claims 1 to 12, wherein at least one of the operators (OP1) and reconciliation agent (AGI) comprises: - a personal security device (PSD) equipped with a secure element (SE), and - a host device (HDV) of the personal security device, capable of connecting to the management platform, the secure element (SE) being configured to connect to the hardware security module (HSM1) via a secure channel (SCP) by means of an ephemeral session key which is known only to the secure element (SE) and the hardware security module.

14. A method according to any one of claims 1 to 13, wherein at least one of the operators (OP1) and reconciliation agent (AGI) comprises a computer device (ITD) including an application program interface (API) enabling it to connect to the hardware security module (HSM1) via a secure channel (SCP) by means of an ephemeral session key known only to the secure element and the hardware security module.

15. A method according to any one of claims 1 to 14, applied to at least one of the following: values ​​of physical quantities measured by sensors or instruments, contract clauses, contracts, smart contracts, tokens digital security, electronic records, identity documents, financial data, digital works in the form of NFTs, official documents such as notarized documents, and medical data or medical records, crypto-asset units, cryptocurrency units, digital assets.

16. A method according to any one of claims 1 to 15, wherein a reconciliation agent is a crypto-asset exchange management platform that remunerates off-chain transactions.

17. A method according to any one of claims 1 to 15, wherein a reconciliation agent includes an object analysis management platform configured to automatically generate new objects from the objects present in the first object container (OC 1 (AGI), OF1(AG1)) at the time of reconciliation and taking into account object registrations that occurred in the first object container between the first (T1) and second (T2) instant.

Images