EP4681141A1 - Procédé et dispositif de paiement confidentiel sur chaîne de blocs - Google Patents

Procédé et dispositif de paiement confidentiel sur chaîne de blocs

Info

Publication number
EP4681141A1
EP4681141A1 EP24709400.6A EP24709400A EP4681141A1 EP 4681141 A1 EP4681141 A1 EP 4681141A1 EP 24709400 A EP24709400 A EP 24709400A EP 4681141 A1 EP4681141 A1 EP 4681141A1
Authority
EP
European Patent Office
Prior art keywords
electronic
address
payment
tokens
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24709400.6A
Other languages
German (de)
English (en)
Inventor
Julien HATIN
Tiphaine HENRY
Emmanuel Bertin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4681141A1 publication Critical patent/EP4681141A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the invention relates to the general field of telecommunications networks, and more specifically to blockchain technology.
  • Blockchain is a trusted execution system, for example, ensuring the integrity and transparency of the execution of a business process.
  • Blockchain smart contracts can enable the management of the execution of tasks and/or workflows of a business process and the allocation of these tasks in a decentralized and reliable manner.
  • a smart contract is a small computer program that allows token transactions to be carried out under certain conditions. The aim of these smart contracts is to replace paper contracts with computer code in order to digitize processes.
  • the invention allows the payment of a transaction carried out between two persons (physical and/or moral) in a confidential manner.
  • this solution protects the participants (i.e. the sender and the receiver of the funds) by not disclosing the amount of the transaction to third parties (the participants are the only ones to know the amount).
  • the method obtains pairs of data, each pair comprising an electronic address of a financial institution (for example a bank electronic address) to be involved in the transaction and an associated parameter.
  • the method also obtains an address of a smart contract associated with the payment of the transaction and a number of tokens to be generated by the financial institutions.
  • the parameters are determined so that the sum of the parameters corresponds to the amount of the transaction divided by the number of tokens to be generated.
  • the process issues a token generation request to the financial institutions involved, including the address of the smart contract, the number of tokens to be generated, and the parameter associated with the financial institution (e.g. the bank’s email address).
  • the financial institution receives this request, it converts funds belonging to the issuer into tokens for a value equivalent to the number of tokens received multiplied by the parameter received, and then feeds the smart contract with the generated tokens.
  • each financial institution carries out a part of the transaction without knowing the total amount.
  • the confidentiality of the transaction amount is then total. Only the participants know the exact amount of the transaction.
  • a financial institution email address is a sequence of characters and/or binary data that serves to uniquely identify a financial institution (bank, financial agent, broker, etc.). Such an address is, for example, composed of an IP address, a MAC address or a URI/URL.
  • a smart contract email address is a sequence of characters and/or binary data that serves to uniquely identify a smart contract registered in a blockchain. Such an address is, for example, composed of an IP address, a MAC address or a URI/URL.
  • a smart transaction contract is a smart contract created specifically to manage the payment of a transaction made between a sender and a receiver.
  • An electronic token is a unique sequence of characters and/or binary data associated with a certain financial value.
  • An electronic token is, for example, a consumption unit that does not contain any reference to a price. However, it is linked to usage parameters that allow its value to be determined.
  • a method as described above is characterized in that the obtaining step comprises a reception step, from said receiver and/or said transmitter, of all or part of said set of data.
  • This embodiment allows the triggering of the process by the issuer (i.e. the payer) and/or the receiver (i.e. the person receiving the payment).
  • a method as described above is characterized in that said electronic address of said smart transaction contract is obtained in response to the sending, to a blockchain, of a request to create said smart transaction contract.
  • This embodiment allows the method to be at the origin of the creation of the smart contract associated with the payment of the transaction.
  • the method has all the information/data (private and/or public encryption key(s), etc.) allowing communication with a blockchain for the purpose of creating and managing a smart contract dedicated to the payment of a transaction in progress between the sender and the receiver.
  • the method is for example implemented by a computer module accessible only by the sender and the receiver (pooling of the computer resources used to interact with the blockchain).
  • a method as described above is characterized in that said creation request comprises the number of financial institution electronic addresses of said plurality and/or an address of a smart contract of said recipient.
  • This embodiment makes it possible to proceed with the payment of the recipient once the smart contract detects that all the financial institutions involved in the payment have generated and/or transferred the tokens at the smart contract level.
  • the number of financial institution email addresses indicates for example the number of banks involved in the payment and consequently the number of requests containing tokens to be expected by the smart contract.
  • the smart contract verifies that it has received all the expected requests.
  • the creation request may include an address of a smart contract of said receiver.
  • the process will proceed to pay the receiver via a transfer of tokens to the smart contract of said receiver.
  • a method as described above is characterized in that said first emission step is followed by a second step of emission of a payment request to said smart transaction contract.
  • This embodiment allows, for example, payment to be made to the receiver when the issuer decides (increased security). To do this, the issuer sends a payment request to said smart transaction contract via the confidential payment method.
  • a method as described above is characterized in that said payment request comprises an address of a smart contract of said receiver.
  • This embodiment makes it possible to specify that the payment of the receiver must be made via a transfer of tokens to a smart contract of said receiver whose address is contained in the payment request.
  • a method as described above is characterized in that the data of said data set is encrypted and in that the data of said data set included in said generation request is encrypted.
  • the data exchanged between the receiver/sender and a financial institution can be encrypted from end to end.
  • the data can be encrypted between the receiver/sender and the confidential payment device and then decrypted by the confidential payment device to be re-encrypted by the confidential payment device before being sent to the financial institutions.
  • This allows the use of different encryption keys between the receiver/sender and the confidential payment device and between the confidential payment device and the financial institutions.
  • the encryption can use one or more symmetrical or asymmetrical encryption keys or any encryption method according to state-of-the-art encryption technologies.
  • module may correspond to a software component as well as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms or more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
  • a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc.).
  • a device as described above is characterized in that it is understood by an electronic terminal of the user.
  • the invention also relates to a computer program comprising instructions for implementing the above method according to any of the particular embodiments described above, when said program is executed by a processor.
  • the method can be implemented in various ways, in particular in hard-wired form or in software form.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.
  • the invention also relates to a recording medium or information medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the recording media mentioned above can be any entity or device capable of storing the program.
  • the medium can comprise 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 disk.
  • the recording media can correspond to a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the programs according to the invention can in particular be downloaded on a network such as the Internet.
  • the recording media may correspond to an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • This confidential payment device and this computer program have characteristics and advantages similar to those described above in relation to the confidential payment method.
  • the environment represented in comprises a terminal S belonging to the issuer of a payment and a terminal R belonging to the recipient of said payment.
  • the environment also comprises a terminal D which integrates a confidential payment device DISP capable of implementing the confidential payment method according to the present invention.
  • the DISP device may be located within the transmitter terminal S or within the receiver terminal R.
  • the R, S and D terminals are, for example, smartphone-type terminals (smartphone in English), tablets, servers, connected televisions, connected objects, on-board computers in cars, personal computers or any other terminal capable of communicating (sending and/or receiving requests) using state-of-the-art technologies, for example via an IP network (100), the network being able to be private or public.
  • smartphone-type terminals smart phone in English
  • tablets tablets
  • servers connected televisions
  • connected objects connected objects
  • on-board computers in cars personal computers or any other terminal capable of communicating (sending and/or receiving requests) using state-of-the-art technologies, for example via an IP network (100), the network being able to be private or public.
  • IP network 100
  • BC blockchain which includes at least one SC1 smart contract.
  • the BC blockchain can be hosted by one or more computer servers.
  • terminals are for example servers, personal computers or any other terminal capable of communicating (sending and/or receiving requests) according to state-of-the-art technologies via for example an IP network (100), the network being able to be private or public.
  • IP network 100
  • the device DISP configured to implement the confidential payment method according to a particular embodiment of the invention.
  • the device DISP has the conventional architecture of a computer, and notably comprises a memory MEM, a processing unit UT, equipped for example with a processor PROC, and controlled by the computer program PG stored in memory MEM.
  • the computer program PG comprises instructions for implementing the steps of the confidential payment method as described later in support of the , when the program is executed by the processor PROC.
  • the code instructions of the computer program PG are for example loaded into a memory before being executed by the processor PROC.
  • the processor PROC of the processing unit UT implements in particular the steps of the confidential payment method according to any one of the particular embodiments described in relation to the and according to the instructions of the PG computer program.
  • the DISP device comprises an OBT obtaining module capable of obtaining a set of data comprising an electronic address of a smart transaction contract, the electronic addresses of the financial institutions involved in the payment of the transaction which is in progress between the receiver and the sender, each electronic address of the financial institution being associated with a parameter, and a number of electronic tokens to be generated by the financial institutions enabling the payment. It should be noted that the sum of the parameters received and associated with the electronic addresses of the financial institutions corresponds to the cost of the payment divided by said number of electronic tokens;
  • the DISP device further comprises an SND1 transmission module capable of transmitting to the electronic addresses of the financial institutions a request for the generation of electronic tokens.
  • the request for the generation of tokens transmitted to each financial institution comprises the number of electronic tokens to be generated by the financial institution, the parameter associated with the financial institution (i.e. associated with its electronic address) and the electronic address of the smart transaction contract.
  • the DISP device may comprise a second SND2 emission module capable of issuing a payment request to a smart transaction contract.
  • the payment request makes it possible to trigger the process of transferring the amount of the transaction (for example in the form of electronic tokens) and/or to trigger the conversion of the tokens into a particular currency.
  • the SND1 and/or SND2 and/or OBT modules can be a single communication module (for example IP).
  • the issuer S carries out a transaction with the recipient R for an amount S of €1,000.
  • the confidential payment method is executed by the terminal of the issuer S.
  • the method may be executed by the terminal of the recipient R, by a third-party terminal (other than the terminal of R and S), or in a distributed manner between several terminals (for example between the terminal of R and S).
  • the first parameter is the value of the token V.
  • the value of the token V is set by both parties (i.e. the issuer and the recipient of the payment) at €2.
  • the second parameter is used to determine the financial intermediaries / financial institutions to be involved in the transaction (at least 2).
  • Terminal S obtains, for example via a database or via terminal R, for each bank involved in the transaction, an email address of the bank in question.
  • the third parameter is a parameter X i assigned to each bank (X 1 for bank B1, X 2 for bank B2 and X 3 for bank B3). These parameters are determined so that:
  • the determination of the Xi can be random or not (for example determined by the receiver and/or the transmitter).
  • step E11 S issues a request to create a smart contract (SC1) to the blockchain BC.
  • the creation request may include a parameter N corresponding to the number of financial intermediaries involved in the transaction.
  • N a parameter corresponding to the number of financial intermediaries involved in the transaction.
  • the confidential payment method executed by the terminal of S has all the elements, for example cryptographic, allowing communication with the blockchain BC in order to create and manage the smart contract SC1 dedicated to the payment of the transaction in progress between the sender and the receiver.
  • the request to create the smart contract is issued by R (i.e. the receiver).
  • the request to create the smart contract SC1 can also include the address (@R) of a smart contract SCR of R.
  • the smart contract SC1 is created.
  • the access interface to the smart contract is of the ERC20 type.
  • a notification indicating that the creation of the smart contract SC1 was successful is sent by the blockchain BC to S.
  • This notification includes at least the address of the smart contract @SC1.
  • the notification indicating that the creation of the smart contract SC1 has been successfully completed is sent to R.
  • the receiver R transmits, after receiving the notification, the address of the smart contract @SC1 to the transmitter S via a dedicated request (not shown).
  • the smart contract (SC1) is created prior to the execution of the confidential payment method and its address is obtained by the terminal S during step E10.
  • the terminal of the issuer S issues, during step E11, a request for provisioning the smart contract SC1 with the address @R and/or the parameter N.
  • the issuer S sends to the 3 banks B1, B2 and B3, via the email addresses obtained during step E10, a token creation request with the address of the smart contract @SC1 as a parameter, the number T of tokens to be created and the parameter X i assigned to each bank.
  • the parameter X 1 0.6
  • the parameter X 2 0.5
  • Token creation requests are received by the banks at steps E33, E44 and E55 respectively.
  • an acknowledgment of receipt of the token creation request is sent to the issuer S by each bank involved (B1, B2 and B3) in the transaction (not shown).
  • acknowledgements of receipt of token creation requests are issued to the recipient R by the banks involved (B1, B2 and B3) in the transaction (not shown).
  • each bank generates and/or transfers T tokens for a value equal to T x X i .
  • bank B1 generates and/or transfers 500 tokens for a value of €300 (500 x 0.6)
  • bank B2 generates and/or transfers 500 tokens for a value of €250 (500 x 0.5)
  • bank B3 generates and/or transfers 500 tokens for a value of €450 (500 x 0.9).
  • a notification of generation and/or transfer of tokens is sent to the issuer S by each bank involved (B1, B2 and B3) in the transaction (not shown).
  • token generation and/or transfer notifications are issued to the recipient R by the banks involved (B1, B2 and B3) in the transaction (not shown).
  • Tokens are registered (added) to the smart contract SC1 during steps E66, E67 and E68 respectively.
  • S When S wishes to trigger the payment, for example at the end of the transaction, S issues a payment request (E19) to the smart contract SC1.
  • the payment request may also include the address (@R) of R's smart contract SCR.
  • the smart contract SC1 transfers the tokens (E692) to the smart contract SCR of R.
  • This request includes at least the number of tokens T generated by each bank (i.e. 500), the addresses of the 3 financial institutions (banks) issuing the tokens (B1, B2 and B3), and the address of the smart contract SC1 (@SC1).
  • the payment can be triggered directly by the smart contract SC1 when it determines that all the banks (financial institutions) involved in the payment have generated and/or transferred the tokens to the smart contract SC1.
  • the smart contract verifies that it has received N requests containing tokens to add.
  • the smart contract SC1 then transfers the tokens (E692) to the smart contract SCR of R.
  • This request includes at least the number of tokens T generated by each bank (i.e. 500), the addresses of the 3 financial institutions (banks) issuing the tokens (B1, B2 and B3), and the address of the smart contract SC1 (@SC1).
  • R When R wishes to convert its tokens (not shown) into a non-electronic currency (for example in Euro), it issues a request to each bank with the address of the smart contract @SC1 and the number of tokens T as parameters. Each bank can then, using the address @SC1, find the X i to apply to T to obtain the amount to be credited, for example, to a bank account denominated in € belonging to R. Alternatively, each bank can keep in memory the value of the T tokens generated/transferred and re-credit this amount to a bank account denominated in € belonging to R.
  • the requests/data exchanged between the receiver, the transmitter and the banks can be partially or totally encrypted.
  • the encryption may require the use of one or more symmetrical or asymmetrical encryption keys or any encryption method according to the state-of-the-art encryption technologies.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé permettant un paiement confidentiel entre un émetteur et un receveur caractérisé en ce qu'il comprend : - une étape d'obtention d'un ensemble de données comprenant un nombre de jetons électroniques à générer, une adresse électronique d'un contrat intelligent de transaction et une pluralité d'adresses électroniques de banque, chaque adresse électronique de banque étant associée à un paramètre, la somme desdits paramètres correspondant au coût dudit paiement divisé par ledit nombre de jetons électroniques; et pour chaque adresse électronique de banque de ladite pluralité - une première étape d'émission à destination de ladite adresse électronique de banque d'une requête de génération de jetons électroniques, ladite requête de génération comprenant ledit au moins un nombre de jetons électroniques, ladite au moins une adresse électronique dudit contrat intelligent de transaction et ledit au moins un paramètre associé à ladite adresse électronique de banque.

Description

    Procédé et dispositif de paiement confidentiel sur chaîne de blocs
  • 1. Domaine de l'invention
  • L’invention se rapporte au domaine général des réseaux de télécommunications, et plus précisément à la technologie des chaînes de blocs (en anglais « blockchain »).
  • 2. Art Antérieur
  • La chaîne de bloc est un système d'exécution de confiance, garantissant par exemple l'intégrité et la transparence de l'exécution d’un processus commercial. Les contrats intelligents (en anglais « smart contract ») des chaînes de bloc peuvent permettre la gestion de l'exécution de tâches et/ou de flux de travail d’un processus commercial et l'attribution de ces tâches de manière décentralisée et fiable. Concrètement, un contrat intelligent est un petit programme informatique qui permet de réaliser des transactions de jetons (« tokens » en anglais) sous certaines conditions. L'objectif de ces contrats intelligents est de remplacer les contrats papiers par un code informatique afin de digitaliser les processus.
  • Les transactions au sein de la chaîne de bloc sont publiques et accessibles à l’ensemble des participants (i.e. des utilisateurs inscrits à la chaîne de bloc). Se pose alors la question de la confidentialité des données utilisées par ces contrats intelligents lorsque ceux-ci sont liés à un processus commercial. En effet, la confidentialité peut être souhaitée dans ce genre d’opération notamment lorsque l’une des parties ne souhaite pas révéler le montant d’une transaction. Ce problème est bien connu et des solutions existent pour y répondre. Cependant, ces solutions ne permettent pas une confidentialité totale. En effet, dans l'exemple du paiement d’un service, l’intervenant financier (par exemple une banque) qui réalise et/ou participe au transfert des fonds a la connaissance du montant de la transaction financière. Or les participants peuvent ne pas être disposés à révéler la valeur exacte de la transaction même à leur intervenant financier.
  • 3. Exposé de l'invention
  • L'invention vient améliorer l'état de la technique et propose à cet effet un procédé de paiement confidentiel, ledit paiement étant initié par un émetteur à destination d’un receveur, le procédé étant mis en œuvre par un dispositif de paiement confidentiel et caractérisé en ce qu’il comprend :
    • une étape d’obtention d’un ensemble de données comprenant un nombre de jetons électroniques à générer, une adresse électronique d’un contrat intelligent de transaction et une pluralité d’adresses électroniques d’établissement financier, chaque adresse électronique d’établissement financier étant associée à un paramètre, la somme desdits paramètres correspondant au coût dudit paiement divisé par ledit nombre de jetons électroniques ;
  • et pour chaque adresse électronique d’établissement financier de ladite pluralité
    • une première étape d’émission à destination de ladite adresse électronique d’établissement financier d’une requête de génération de jetons électroniques, ladite requête de génération comprenant ledit au moins un nombre de jetons électroniques, ladite au moins une adresse électronique dudit contrat intelligent de transaction et ledit au moins un paramètre associé à ladite adresse électronique d’établissement financier.
  • Avantageusement, l’invention permet le paiement d’une transaction réalisée entre deux personnes (physique et/ou morale) de manière confidentielle. En effet, cette solution, protège les intervenants (c’est-à-dire l’émetteur et le receveur des fonds) en ne divulguant pas le montant de la transaction à des tiers (les intervenants sont les seuls à connaître le montant). Concrètement, le procédé obtient des couples de données, chaque couple comprenant une adresse électronique d’un établissement financier (par exemple une adresse électronique de banque) à impliquer dans la transaction et un paramètre associé. Le procédé obtient également une adresse d’un contrat intelligent associé au paiement de la transaction et un nombre de jeton à générer par les établissements financiers. A noter que les paramètres sont déterminés de façon à ce que la somme des paramètres corresponde au montant de la transaction divisé par le nombre de jetons à générer.
  • Une fois les données obtenues, le procédé émet, à destination des établissements financiers impliqués, une requête de génération de jetons comprenant l’adresse du contrat intelligent, le nombre de jetons à générer et le paramètre associé à l’établissement financier (par exemple l’adresse électronique de la banque). Lorsque l’établissement financier reçoit cette requête, celui-ci convertit des fonds appartenant à l’émetteur en jetons pour une valeur équivalente au nombre de jetons reçu multiplié par le paramètre reçu puis alimente le contrat intelligent avec les jetons générés.
  • Ainsi chaque établissement financier réalise une partie de la transaction sans connaître le montant total. En outre, la valeur des jetons générés par chaque établissement financier pouvant être différente, la confidentialité du montant de la transaction est alors totale. Seuls les intervenants connaissent le montant exact de la transaction.
  • On entend par adresse électronique d’établissement financier une suite de caractères et/ou de données binaires qui sert à identifier de façon certaine un établissement financier (banque, mandataire financier, courtier, etc.). Une telle adresse est par exemple composée d’une adresse IP, une adresse MAC ou bien une URI/URL.
  • On entend par adresse électronique d’un contrat intelligent une suite de caractères et/ou de données binaires qui sert à identifier de façon certaine un contrat intelligent inscrit à une chaîne de blocs. Une telle adresse est par exemple composée d’une adresse IP, une adresse MAC ou bien une URI/URL.
  • On entend par contrat intelligent de transaction, un contrat intelligent créé spécifiquement afin de gérer le paiement d’une transaction réalisée entre un émetteur et un receveur.
  • On entend par jeton électronique une suite de caractères et/ou de données binaires unique associée à une certaine valeur financière. Un jeton électronique est, par exemple, une unité de consommation ne contenant aucune référence à un prix. Il est par contre lié à des paramètres d’utilisation permettant d’en déterminer la valeur.
  • Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape d’obtention comprend une étape de réception, en provenance dudit receveur et/ou dudit émetteur, de tout ou partie dudit ensemble de données.
  • Ce mode de réalisation permet le déclenchement du procédé par l’émetteur (c’est-à-dire le payeur) et / ou le receveur (c’est-à-dire la personne qui reçoit le paiement).
  • Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite adresse électronique dudit contrat intelligent de transaction est obtenue en réponse à l’émission, à destination d’une chaîne de blocs, d’une requête de création dudit contrat intelligent de transaction.
  • Ce mode de réalisation permet au procédé d’être à l’origine de la création du contrat intelligent associé au paiement de la transaction. Bien entendu, cela suppose que le procédé dispose de toutes les informations/données (clef(s) de chiffrement privée et/ou public, etc.) permettant la communication avec une chaîne de blocs dans le but de créer et de gérer un contrat intelligent dédié au paiement d’un transaction en cours entre l’émetteur et le receveur. Le procédé est par exemple mis en œuvre par un module informatique accessible uniquement par l’émetteur et le receveur (mutualisation des ressources informatiques utilisées pour interagir avec la chaîne de blocs).
  • Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite requête de création comprend le nombre d’adresses électroniques d’établissement financier de ladite pluralité et/ou une adresse d’un contrat intelligent dudit receveur.
  • Ce mode de réalisation permet de procéder au paiement du receveur une fois que le contrat intelligent détecte que l’ensemble des établissements financiers impliqués dans le paiement ont généré et/ou transféré les jetons au niveau du contrat intelligent. Concrètement, le nombre d’adresses électroniques d’établissement financier indique par exemple le nombre de banques impliquées dans le paiement et par conséquent le nombre de requêtes contenant des jetons à attendre par le contrat intelligent. Ainsi, avant de procéder au paiement du receveur, le contrat intelligent vérifie qu’il a bien reçu l’ensemble des requêtes attendues.
  • A noter que la requête de création peut comprendre une adresse d’un contrat intelligent dudit receveur. Dans ce cas le procédé procèdera au paiement du receveur via un transfert des jetons à destination du contrat intelligent dudit receveur.
  • Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite première étape d’émission est suivie d’une seconde étape d’émission d’une requête de paiement à destination dudit contrat intelligent de transaction.
  • Ce mode de réalisation permet par exemple de procéder au paiement du receveur lorsque l’émetteur le décide (sécurité accrue). Pour cela l’émetteur envoie une requête de paiement à destination dudit contrat intelligent de transaction par l’intermédiaire du procédé de paiement confidentiel.
  • Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite requête de paiement comprend une adresse d’un contrat intelligent dudit receveur.
  • Ce mode de réalisation permet de préciser que le paiement du receveur doit se faire via un transfert des jetons à destination d’un contrat intelligent dudit receveur dont l’adresse est contenue dans la requête de paiement.
  • Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que les données dudit ensemble de données sont chiffrées et en ce que les données dudit ensemble de données comprises dans ladite requête de génération sont chiffrées.
  • Ce mode de réalisation permet une sécurité accrue. En effet, les données échangées entre le receveur/émetteur et un établissement financier peuvent être chiffrées de bout en bout. Alternativement, les données peuvent être chiffrées entre le receveur/émetteur et le dispositif de paiement confidentiel puis déchiffrées par dispositif de paiement confidentiel pour être rechiffrées par dispositif de paiement confidentiel avant leur envoi à destination des établissements financiers. Cela permet l’utilisation de clefs de chiffrement différentes entre le receveur/émetteur et le dispositif de paiement confidentiel et entre le dispositif de paiement confidentiel et les établissements financiers. Le chiffrement peut utiliser une ou plusieurs clefs de chiffrement symétriques, asymétriques ou bien n’importe quel procédé de chiffrement selon les technologies de chiffrement de l’état de l’art.
  • L'invention concerne également un dispositif de paiement confidentiel, ledit paiement étant initié par un émetteur à destination d’un receveur, ledit dispositif étant caractérisé en ce qu’il comprend :
    • un module d’obtention d’un ensemble de données comprenant un nombre de jetons électroniques à générer, une adresse électronique d’un contrat intelligent de transaction et une pluralité d’adresses électroniques d’établissement financier, chaque adresse électronique d’établissement financier étant associée à un paramètre, la somme desdits paramètres correspondant au coût dudit paiement divisé par ledit nombre de jetons électroniques ;
    • un premier module d’émission à destination d’une dite adresse électronique de d’établissement financier d’une requête de génération de jetons électroniques, ladite requête de génération comprenant ledit au moins un nombre de jetons électroniques, ladite au moins une adresse électronique dudit contrat intelligent de transaction et ledit au moins un paramètre associé à ladite adresse électronique de banque.
  • Le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
  • Selon un mode de mise en œuvre particulier de l'invention, un dispositif comme tel que décrit ci-dessus est caractérisé en ce qu’il est compris par un terminal électronique de l’utilisateur.
  • L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé ci-dessus selon l'un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Le procédé peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
  • L'invention vise aussi un support d'enregistrement ou support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.
  • Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
  • Ce dispositif de paiement confidentiel et ce programme d'ordinateur présentent des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le procédé de paiement confidentiel.
  • 4. Liste des figures
  • D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
  • La illustre un exemple d'environnement de mise en œuvre de l'invention selon un mode particulier de réalisation de l'invention,
  • La représente l’architecture matérielle d’un dispositif de paiement confidentiel selon un mode particulier de réalisation ;
  • La représente sous forme d’organigramme les principales étapes d’un procédé de paiement confidentiel selon un mode particulier de réalisation de l’invention.
  • 5. Description d'un mode de réalisation de l'invention
  • La illustre un exemple d'environnement de mise en œuvre de l'invention selon un mode particulier de réalisation. L’environnement représenté en comprend un terminal S appartenant à l’émetteur d’un paiement et un terminal R appartenant au receveur dudit paiement. L’environnement comprend également un terminal D qui intègre un dispositif de paiement confidentiel DISP apte à mettre en œuvre le procédé de paiement confidentiel selon la présente invention.
  • Selon un autre mode de réalisation, le dispositif DISP peut être situé au sein du terminal de l’émetteur S ou au sein du terminal du receveur R.
  • Les terminaux R, S et D sont par exemple des terminaux de type smartphone (téléphone intelligent en anglais), tablette, serveur, télévision connectée, objet connecté, ordinateur de bord d’une voiture, ordinateur personnel ou tout autre terminal apte à communiquer (émettre et/ou recevoir des requêtes) selon les technologies de l’état l’art via par exemple un réseau IP (100), le réseau pouvant être privé ou public.
  • La comprend également une chaîne de blocs BC qui comprend au moins un contrat intelligent SC1.
  • Selon un mode particulier de réalisation de l'invention, la chaîne de blocs BC peut être hébergée par un ou plusieurs serveurs informatiques.
  • La comprend en outre une pluralité de terminaux d’établissement financier (B1, B2 et B3). Ces terminaux sont par exemple des serveurs, des ordinateurs personnels ou tout autre terminal apte à communiquer (émettre et/ou recevoir des requêtes) selon les technologies de l’état l’art via par exemple un réseau IP (100), le réseau pouvant être privé ou public.
  • La illustre un dispositif DISP configuré pour mettre en œuvre le procédé de paiement confidentiel selon un mode particulier de réalisation de l'invention. Le dispositif DISP a l'architecture classique d'un ordinateur, et comprend notamment une mémoire MEM, une unité de traitement UT, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur PG stocké en mémoire MEM. Le programme d'ordinateur PG comprend des instructions pour mettre en œuvre les étapes du procédé de paiement confidentiel tel que décrit ultérieurement à l’appui de la , lorsque le programme est exécuté par le processeur PROC.
  • A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UT met notamment en œuvre les étapes du procédé de paiement confidentiel selon l'un quelconque des modes particuliers de réalisation décrits en relation avec la et selon les instructions du programme d'ordinateur PG.
  • Le dispositif DISP comprend un module d’obtention OBT apte à obtenir un ensemble de données comprenant une adresse électronique d’un contrat intelligent de transaction, les adresses électroniques des établissements financiers impliqués dans le paiement de la transaction qui est en cours entre le receveur et l’émetteur, chaque adresse électronique d’établissement financier étant associée à un paramètre, et un nombre de jetons électroniques à générer par les établissements financiers permettant le paiement. A noter que la somme des paramètres reçus et associés aux adresses électroniques des établissements financiers correspond au coût du paiement divisé par ledit nombre de jetons électroniques ;
  • Le dispositif DISP comprend en outre un module d’émission SND1 apte à émettre à destination des adresses électroniques des établissements financiers une requête de génération de jetons électroniques. A noter que la requête de génération de jetons émise à destination de chaque établissement financier comprend le nombre de jetons électroniques à générer par l’établissement financier, le paramètre associé à l’établissement financier (i.e. associée à son adresse électronique) et l’adresse électronique du contrat intelligent de transaction.
  • Selon un mode particulier de réalisation de l'invention, le dispositif DISP peut comprendre un second module d’émission SND2 apte à émettre une requête de paiement à destination d’un contrat intelligent de transaction. La requête de paiement permet de déclencher le processus de transfert du montant de la transaction (par exemple sous forme de jetons électronique) et/ou de déclencher la conversion des jetons dans une monnaie particulière.
  • Selon un mode particulier de réalisation, les modules SND1 et/ou SND2 et/ou OBT peuvent être un seul et même module de communication (par exemple IP).
  • La illustre des étapes du procédé de paiement confidentiel selon un mode particulier de réalisation de l'invention en lien avec l’environnement de mise en œuvre décrit à l’appui de la .
  • Dans la suite de l’exemple nous faisons l’hypothèse que l’émetteur S réalise avec le receveur R une transaction pour un montant S de 1000€. En outre, dans cet exemple, le procédé de paiement confidentiel est exécuté par le terminal de l’émetteur S. Alternativement, le procédé peut être exécuté par le terminal du receveur R, par un terminal tiers (autre que le terminal de R et de S), ou bien de façon répartie entre plusieurs terminaux (par exemple entre le terminal de R et de S).
  • Lors des étapes E10, E20 les deux parties prenantes à la transaction se mettent d’accord sur un certain nombre de paramètres. Le premier paramètre est la valeur du jeton V. Dans l’exemple décrit ci-après on considère que la valeur du jeton V est fixée par les deux parties (c’est-à-dire l’émetteur et le receveur du paiement) à 2€. Ainsi pour effectuer la transaction il y aura besoin d’un total de jetons T de 1000/2 soit 500 jetons (T=S/V).
  • Le deuxième paramètre permet de déterminer les intermédiaires financiers / les établissements financiers à impliquer dans la transaction (au moins 2). Dans cet exemple nous considérons 3 banques (B1, B2 et B3). Le terminal S obtient, par exemple via une base de données ou via le terminal R, pour chaque banque impliquée dans la transaction, une adresse électronique de la banque en question.
  • Le troisième paramètre est un paramètre Xi attribué à chaque banque (X1 pour la banque B1, X2 pour la banque B2 et X3 pour la banque B3). Ces paramètres sont déterminés de façon à ce que :
  • A noter que la détermination des Xi peut être aléatoire ou non (par exemple déterminés par le receveur et/ou l’émetteur).
  • Lors de l’étape E11, S émet une requête de création d’un contrat intelligent (SC1) à destination de la chaîne de blocs BC. A noter que la requête de création peut comprendre un paramètre N correspondant au nombre d’intermédiaires financiers impliqués dans la transaction. Bien entendu, on suppose que le procédé de paiement confidentiel exécuté par le terminal de S dispose de tous les éléments par exemple cryptographiques permettant la communication avec la chaîne de blocs BC dans le but de créer et de gérer le contrat intelligent SC1 dédié au paiement de la transaction en cours entre l’émetteur et le receveur.
  • Alternativement, la requête de création du contrat intelligent est émise par R (i.e. le receveur).
  • Selon un mode particulier de réalisation de l’invention, la requête de création du contrat intelligent SC1 peut également comprendre l’adresse (@R) d’un contrat intelligent SCR de R.
  • Une fois la requête reçue (E61) par la chaîne de blocs BC, le contrat intelligent SC1 est créé. Selon un mode particulier de réalisation de l’invention, l’interface d’accès au contrat intelligent est du type ERC20.
  • Lors de l’étape E62 une notification indiquant que la création du contrat intelligent SC1 s’est correctement déroulée est envoyée par la chaîne de blocs BC à destination de S. Cette notification comprend au moins l’adresse du contrat intelligent @SC1.
  • Alternativement ou cumulativement, la notification indiquant que la création du contrat intelligent SC1 s’est correctement déroulée est envoyée à destination de R. Dans le cas où cette notification est émise par le procédé uniquement à destination de R, le receveur R transmet, après réception de la notification, l’adresse du contrat intelligent @SC1 à l’émetteur S via une requête dédiée (non représenté).
  • Alternativement, le contrat intelligent (SC1) est créé préalablement à l’exécution du procédé de paiement confidentiel et son adresse est obtenue par le terminal S lors de l’étape E10. Dans ce cas, le terminal de l’émetteur S émet, lors de l’étape E11, une requête de provisionnement du contrat intelligent SC1 avec l’adresse @R et/ou le paramètre N.
  • Lors des étapes E13, E14 et E15 l’émetteur S émet à destination des 3 banques B1, B2 et B3, via les adresses électroniques obtenues lors de l’étape E10, une requête de création de jetons avec en paramètre l’adresse du contrat intelligent @SC1, le nombre T de jetons à créer et le paramètre Xi attribué à chaque banque.
  • Par exemple, pour la banque B1 le paramètre X1 = 0.6, pour la banque B2 le paramètre X2 = 0.5 et pour la banque B3 le paramètre X3 est égale à 0.9 (0.6 + 05 + 0= V= 2).
  • Les requêtes de création de jetons sont reçues par les banques respectivement aux étapes E33, E44 et E55.
  • Selon un mode particulier de réalisation de l’invention, un accusé de réception de la requête de création de jetons est émis à destination de l’émetteur S par chaque banque impliquée (B1, B2 et B3) dans la transaction (non représenté).
  • Alternativement ou cumulativement, les accusés de réception des requêtes de création de jetons sont émis à destination du receveur R par les banques impliquées (B1, B2 et B3) dans la transaction (non représenté).
  • Lors des étapes E36, E47 et E58 chaque banque génère et/ou transfère T jetons pour une valeur égale à T x Xi. Concrètement, la banque B1 génère et/ou transfère 500 jetons pour une valeur de 300€ (500 x 0.6), la banque B2 génère et/ou transfère 500 jetons pour une valeur de 250€ (500 x 0.5) et la banque B3 génère et/ou transfère 500 jetons pour une valeur de 450€ (500 x 0.9).
  • Selon un mode particulier de réalisation de l’invention, une notification de génération et / ou de transfert de jetons est émise à destination de l’émetteur S par chaque banque impliquée (B1, B2 et B3) dans la transaction (non représenté).
  • Alternativement ou cumulativement, les notifications de génération et / ou de transfert de jetons sont émises à destination du receveur R par les banques impliquées (B1, B2 et B3) dans la transaction (non représenté).
  • Les jetons sont inscrits (ajoutés) au contrat intelligent SC1 respectivement lors des étapes E66, E67 et E68.
  • Lorsque S souhaite déclencher le paiement, par exemple à l’issue de la transaction, S émet une requête de paiement (E19) à destination du contrat intelligent SC1. Selon un mode particulier de réalisation de l’invention, la requête de paiement peut également comprendre l’adresse (@R) du contrat intelligent SCR de R.
  • Une fois la requête de paiement reçue par SC1 (E691) le contrat intelligent SC1 transfert les jetons (E692) à destination du contrat intelligent SCR de R. Cette requête comprend au moins le nombre de jetons T généré par chaque banque (c’est-à-dire 500), les adresses des 3 établissements financiers (banques) émetteurs des jetons (B1, B2 et B3), et l’adresse du contrat intelligent SC1 (@SC1).
  • Alternativement, le déclenchement du paiement peut être réalisé directement par le contrat intelligent SC1 lorsque celui-ci détermine que l’ensemble des banques (établissements financiers) impliqués dans le paiement ont généré et/ou transféré les jetons au niveau du contrat intelligent SC1. Concrètement, contrat intelligent vérifie qu’il a bien reçu N requêtes contenant des jetons à ajouter. Le contrat intelligent SC1 transfert alors les jetons (E692) à destination du contrat intelligent SCR de R. Cette requête comprend au moins le nombre de jetons T généré par chaque banque (c’est-à-dire 500), les adresses des 3 établissements financiers (banques) émetteurs des jetons (B1, B2 et B3), et l’adresse du contrat intelligent SC1 (@SC1).
  • Lorsque R souhaite convertir ses jetons (non représenté) dans une monnaie non électronique (par exemple en Euro), il émet une requête à destination de chaque banque avec en paramètre l’adresse du contrat intelligent @SC1 et le nombre de jetons T. Chaque banque peut alors, grâce à l’adresse @SC1 retrouver le Xi à appliquer à T pour obtenir la somme à créditer par exemple sur un compte bancaire libellé en € appartenant à R. Alternativement, chaque banque peut garder en mémoire la valeur des T jetons générés / transférés et recréditer cette somme sur un compte bancaire libellé en € appartenant à R.
  • Selon un mode particulier de réalisation de l’invention, les requêtes /données échangées entre le receveur, l’émetteur et les banques peuvent être chiffrées partiellement ou totalement. Le chiffrement peut nécessiter l’utilisation d’une ou plusieurs clefs de chiffrement symétriques, asymétriques ou bien n’importe quel procédé de chiffrement selon les technologies de chiffrement de l’état de l’art.

Claims (9)

  1. Procédé de paiement confidentiel, ledit paiement étant initié par un émetteur (S) à destination d’un receveur (R), le procédé étant mis en œuvre par un dispositif (DISP) de paiement confidentiel et caractérisé en ce qu’il comprend :
    - une étape d’obtention (E10, E12) d’un ensemble de données comprenant un nombre (T) de jetons électroniques à générer, une adresse électronique d’un contrat intelligent (@SC1) de transaction et une pluralité d’adresses électroniques d’établissement financier (B1, B2,B3), chaque adresse électronique d’établissement financier étant associée à un paramètre (Xi), la somme desdits paramètres correspondant au coût dudit paiement divisé par ledit nombre de jetons électroniques ;
    et pour chaque adresse électronique d’établissement financier de ladite pluralité
    - une première étape d’émission (E13,E14,E15) à destination de ladite adresse électronique d’établissement financier d’une requête de génération de jetons électroniques, ladite requête de génération comprenant ledit au moins un nombre de jetons électroniques (T), ladite au moins une adresse électronique dudit contrat intelligent de transaction (SC1) et ledit au moins un paramètre (Xi) associé à ladite adresse électronique d’établissement financier.
  2. Procédé selon la revendication 1 dans lequel l’étape d’obtention comprend une étape de réception, en provenance dudit receveur et/ou dudit émetteur, de tout ou partie dudit ensemble de données.
  3. Procédé selon la revendication 1 dans lequel ladite adresse électronique dudit contrat intelligent de transaction (@SC1) est obtenue en réponse à l’émission, à destination d’une chaîne de blocs (BC), d’une requête de création dudit contrat intelligent de transaction.
  4. Procédé selon la revendication 1 dans lequel ladite requête de création comprend le nombre (N) d’adresses électroniques d’établissement financier de ladite pluralité et/ou une adresse d’un contrat intelligent dudit receveur (@R).
  5. Procédé selon la revendication 1 dans lequel ladite première étape d’émission est suivie d’une seconde étape d’émission (E19) d’une requête de paiement à destination dudit contrat intelligent de transaction (SC1).
  6. Procédé selon la revendication 1 dans lequel ladite requête de paiement comprend une adresse d’un contrat intelligent dudit receveur (@R).
  7. Procédé selon la revendication 1 dans lequel les données dudit ensemble de données sont chiffrées et en ce que les données dudit ensemble de données comprises dans ladite requête de génération sont chiffrées.
  8. Dispositif de paiement confidentiel, ledit paiement étant initié par un émetteur (S) à destination d’un receveur (R), ledit dispositif étant caractérisé en ce qu’il comprend :
    - un module d’obtention (OBT) d’un ensemble de données comprenant un nombre de jetons électroniques à générer (T), une adresse électronique d’un contrat intelligent de transaction (@SC1) et une pluralité d’adresses électroniques d’établissement financier (B1,B2,B3), chaque adresse électronique d’établissement financier étant associée à un paramètre (Xi), la somme desdits paramètres correspondant au coût dudit paiement divisé par ledit nombre de jetons électroniques ;
    - un premier module d’émission (SND1) à destination d’une dite adresse électronique de d’établissement financier d’une requête de génération de jetons électroniques, ladite requête de génération comprenant ledit au moins un nombre de jetons électroniques (T), ladite au moins une adresse électronique dudit contrat intelligent de transaction (@SC1) et ledit au moins un paramètre associé à ladite adresse électronique de banque (Xi).
  9. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de paiement confidentiel selon l'une quelconque des revendications 1 à 7, lorsque le programme est exécuté par un processeur.
EP24709400.6A 2023-03-14 2024-03-07 Procédé et dispositif de paiement confidentiel sur chaîne de blocs Pending EP4681141A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2302331A FR3146738A1 (fr) 2023-03-14 2023-03-14 Procédé et dispositif de paiement confidentiel sur chaîne de blocs
PCT/EP2024/056086 WO2024188822A1 (fr) 2023-03-14 2024-03-07 Procédé et dispositif de paiement confidentiel sur chaîne de blocs

Publications (1)

Publication Number Publication Date
EP4681141A1 true EP4681141A1 (fr) 2026-01-21

Family

ID=86764810

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24709400.6A Pending EP4681141A1 (fr) 2023-03-14 2024-03-07 Procédé et dispositif de paiement confidentiel sur chaîne de blocs

Country Status (3)

Country Link
EP (1) EP4681141A1 (fr)
FR (1) FR3146738A1 (fr)
WO (1) WO2024188822A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109074580B (zh) * 2016-02-23 2022-09-30 区块链控股有限公司 在区块链上安全转移实体的方法和系统
FR3124340A1 (fr) * 2021-06-22 2022-12-23 Orange procédé et dispositif de paiement par chaînes de blocs

Also Published As

Publication number Publication date
FR3146738A1 (fr) 2024-09-20
WO2024188822A1 (fr) 2024-09-19

Similar Documents

Publication Publication Date Title
EP3446436B1 (fr) Procédé d'obtention par un terminal mobile d'un jeton de sécurité
EP3403213A2 (fr) Procédés et systèmes mis en oeuvre dans une architecture en réseau de noeuds susceptibles de réaliser des transactions basées sur messages
US11750570B1 (en) Decentralized messaging inbox
US11816661B2 (en) Centralized digital currency transactions utilizing a digital wallet
FR3107416A1 (fr) Tokenisation aléatoire efficace dans un environnement dématérialisé
FR3065606A1 (fr) Procedes pour le partage de donnees de localisation entre un dispositif source et un dispositif destinataire, serveur, dispositifs source et destinataire et programme d'ordinateur correspondants.
WO2020128240A1 (fr) Traitement d'un service de tickets electroniques
EP3394812A1 (fr) Procédé d'authentification
WO2024188822A1 (fr) Procédé et dispositif de paiement confidentiel sur chaîne de blocs
FR3062499A1 (fr) Procede de reduction de la taille d'une base de donnees repartie de type chaine de blocs, dispositif et programme correspondant
EP4359986B1 (fr) Procédé et dispositif de paiement par chaînes de blocs
EP4074005A1 (fr) Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication
CA3143068A1 (fr) Systeme d'applications de service pour terminaux de paiement
EP4099249A1 (fr) Procédé et dispositif de transmission d'un identifiant d'un utilisateur lors d'un paiement électronique réalisépar l utilisateur
FR3140184A1 (fr) Procédé et dispositif d’attribution d’un NFT
EP4441954B1 (fr) Procédé de traitement de preuve numérique, système et programme correspondant
US12621273B2 (en) Decentralized messaging inbox
EP4348483B1 (fr) Procédé de gestion d'un registre local d'un noeud appartenant a un ensemble de noeuds contribuant a un registre distribué
US20250037163A1 (en) Automated brand authentication in metaverse
WO2018172669A1 (fr) Procédé et dispositif de gestion du stockage de documents numériques
EP3948596B1 (fr) Procédé d'exécution de code sécurisé, dispositifs, système et programmes correspondants
TWM582171U (zh) Inter-row transaction failure notification system based on blockchain
FR3031609A1 (fr) Procede de traitement d'une transaction a partir d'un terminal de communication
EP4075358A1 (fr) Gestion de la mémoire dans un dispositif de traitement de transactions
FR3126831A1 (fr) Procédé de fourniture de service mis en œuvre par ordinateur dans une chaîne de blocs, nœud d’un réseau de chaîne de blocs et programme d’ordinateur correspondants.

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250926

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR