WO2020193773A1 - Procede de negociation de contrat entre deux parties dans un reseau de telecommunications et dispositifs mettant en oeuvre ce procede - Google Patents

Procede de negociation de contrat entre deux parties dans un reseau de telecommunications et dispositifs mettant en oeuvre ce procede Download PDF

Info

Publication number
WO2020193773A1
WO2020193773A1 PCT/EP2020/058810 EP2020058810W WO2020193773A1 WO 2020193773 A1 WO2020193773 A1 WO 2020193773A1 EP 2020058810 W EP2020058810 W EP 2020058810W WO 2020193773 A1 WO2020193773 A1 WO 2020193773A1
Authority
WO
WIPO (PCT)
Prior art keywords
contract
party
scga
bob
proposal
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.)
Ceased
Application number
PCT/EP2020/058810
Other languages
English (en)
Inventor
Emmanuel Bertin
Julien HATIN
Julien ZIMMERMANN
Baptiste HEMERY
Fabrice JEANNE
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
Priority to US17/598,516 priority Critical patent/US12051128B2/en
Priority to EP20713051.9A priority patent/EP3948627A1/fr
Publication of WO2020193773A1 publication Critical patent/WO2020193773A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • 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
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • 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
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/18—Legal services
    • G06Q50/188—Electronic negotiation
    • 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
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • 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
    • 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/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • 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
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/18—Legal services
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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
    • 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
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the invention relates to the general field of telecommunications networks, and more specifically to the technology of blockchains (in English "blockchain”).
  • blockchain technology is a technology for storing and transmitting information without a control organ.
  • it is a distributed database whose information sent by users and internal links to the base are verified and grouped at regular time intervals in blocks, the whole being secured by cryptography, and thus forming chain.
  • a blockchain is a distributed database that maintains a list of records protected against tampering or modification by storage nodes; it is therefore a distributed and secure register of all transactions carried out since the start of the distributed system ”.
  • This technology is used in particular as a register to record crypto-currency transactions.
  • the invention proposes to extend the use of blockchain technology to the drafting and negotiation phase of contracts.
  • the invention proposes a method of broadcasting, in a telecommunications network, a contract proposal proposed by a first party, this method comprising:
  • step of generating a smart contract comprising:
  • a contract generation method configured to generate a personalized contract between the first party and a second party and to request the registration of this personalized contract in the blockchain, this personalized contract being generated from parameters included in the transaction and representative of a willingness of said second party to accept the terms of the contract proposal;
  • the invention relates to a device for broadcasting, in a telecommunications network, a contract proposal proposed by a first party, this device comprising:
  • a module for generating a smart contract comprising:
  • a subscription method allowing at least a second party to broadcast a transaction in said network to subscribe to the contract proposal;
  • a contract generation method configured to generate a personalized contract between the first party and a said second party and to request the registration of this personalized contract in the blockchain, this personalized contract being generated from parameters included in the transaction and representative of a willingness of the second party to accept the terms of the contract proposal;
  • the invention relates to a method of accepting a contract proposal broadcast over a telecommunications network, this method being implemented by the terminal of a user and comprising:
  • this smart contract comprising:
  • a contract generation method configured to generate a personalized contract between the first party and a said second party and request the registration of the personalized contract in the blockchain, this personalized contract being generated from parameters included in the transaction and representative of a willingness of the second party to accept the terms of the contract proposal; a step of obtaining parameters representative of a user's desire to accept the terms of the contract proposal;
  • the invention relates to a device for accepting a contract proposal broadcast over a telecommunications network, this device being implemented in a user's terminal and comprising:
  • this smart contract comprising:
  • a subscription method allowing at least a second party to broadcast a transaction in said network to subscribe to said contract proposal
  • a contract generation method configured to generate a personalized contract between the first party and a said second party and to request the registration of the personalized contract in the blockchain, this personalized contract being generated from parameters included in the transaction and representative of a willingness of the second party to accept the terms of the contract proposal;
  • the invention also relates to a process for negotiating a contract between two parties in a telecommunications network, this process comprising:
  • a contract generation method configured to generate a personalized contract between the first party and the second party and to request the registration of the personalized contract in the blockchain, this personalized contract being generated from parameters included in the transaction and representative of a willingness of the second party to accept the terms of the contract proposal;
  • a step of obtaining the smart contract by the second party a step of obtaining parameters representative of a will of said second party to accept the terms of said contract proposal;
  • an execution step implemented by a blockchain mining device, of the method for generating a personalized contract, with these parameters to generate a personalized contract between the parties, to save it in the chain of blocks and rebroadcast the blockchain.
  • the "address" of a resource in the blockchain is a pointer to a resource in the blockchain.
  • a smart contract is an autonomous computer program, which once started, automatically executes conditions defined in advance and registered in the blockchain (https://blockchainfrance.net/2017/01 / 28 / applications-smart-contracts /).
  • the decentralized applications of the Ethereum project dApps constitute smart contracts within the meaning of the invention.
  • a transaction (including the TR_AB and TR_AC transactions of the detailed description) are transactions within the meaning of blockchain technology, that is, records in the blockchain.
  • a contract personalized by one party includes elements representative of that party's willingness to accept the terms of the contract.
  • the invention proposes a mechanism allowing the negotiation of contracts in a network in which the following are recorded in a chain of blocks: - a contract proposal distributed to all participants in the blockchain, at the initiative of a first user, owner of the contract proposal and party to the contract;
  • the method is remarkable in that the contract proposal is recorded in the blockchain as a smart contract and that the personalized contract is generated by one method of this smart contract, following a transaction broadcast by the second. party wishing to subscribe to the contract, by which this second party disseminates to the users of the blockchain, parameters representative of its willingness to accept the terms of the contract proposal.
  • the invention uses blockchain to establish an immutable link between the contract proposal and the personalized contract. This is because the custom contract is generated by the smart contract itself, which can be verified by users of the blockchain at any time.
  • the personalized contract is, in the blockchain, the property of the smart contract (that is to say of the contract proposal) and not of the second party to the contract.
  • the personalized contract obtained by the invention may consist of a set of static data.
  • the personalized contract is a smart contract.
  • This smart contract may contain computer code configured to execute during or after the execution of the personalized contract between the parties.
  • the subscription generation method is configured to obtain conditions for accepting the subscription. contract proposal by the second party, these acceptance conditions being part of the parameters included in the transaction to generate the personalized contract.
  • the contract generation method can be configured to check whether these acceptance conditions are compatible with the terms of the contract proposal before generating the specific contract.
  • the method of broadcasting a contract proposal according to the invention comprises a step of downloading an IT agent from a server, this agent comprising:
  • the diffusion device according to the invention comprises:
  • this agent comprising the contract generation module, the signature module and the broadcasting module of the broadcasting device.
  • This agent is remarkable in that it allows to assist the user in the drafting of the contract proposal, and in that it carries out, in a transparent way for the user, its implementation in a smart contract and the registration of this contract in the blockchain.
  • the Applicant has in fact observed that in the current state of the art, the owners of data recorded in the blockchains were computer experts.
  • the invention is aimed at an online contract negotiation solution that does not require knowledge of blockchain technology.
  • this agent further comprises a module for signing the smart contract with the private key of the first party.
  • the smart contract can be signed with the private key of the first party by a cryptographic module of its terminal and supplied signed to the agent for distribution in the blockchain.
  • the various steps of the contract proposal broadcasting process, of the contract proposal acceptance process and of contract negotiation are determined by computer program instructions.
  • the invention is also aimed at a computer program on an information medium, this program being capable of being implemented in a computer, this program comprising instructions adapted to the implementation of the steps of a process as described above.
  • 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 shape.
  • the invention also relates to an information or recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information or recording medium can be any entity or device capable of storing the program.
  • the medium may include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a hard disk.
  • the information or recording medium can be 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 program according to the invention can in particular be downloaded from an Internet type network.
  • the information or recording medium can be 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.
  • Figure 1 shows the hardware architecture of a contract proposal distribution device in accordance with a particular embodiment of the invention
  • FIG. 2 shows the hardware architecture of a device for accepting a contract proposal in accordance with a particular embodiment of the invention
  • FIG. 3 illustrates in flowchart form the main steps of the processes in accordance with a particular embodiment of the invention
  • FIG. 4 shows a contract proposal drafting form that can be used in the invention
  • FIG. 5 illustrates a smart contract that can be used in the invention
  • - Figure 7 illustrates a transaction that can be used in the invention
  • - Figure 8 shows a chain of blocks comprising blocks generated by the invention 8.
  • FIG. 1 represents the hardware architecture of a DA device for distributing a contract proposal in accordance with a particular embodiment of the invention.
  • this DA device is integrated into the TA terminal of a user Alice.
  • This DA device comprises in particular a processor 13, a random access memory 14, a hard disk 15 as well as communication means 17 allowing it to communicate over a telecommunications network, in particular with terminals.
  • These means of communication include for example a WIFI interface, a network card, etc. depending on the nature of the network.
  • the hard disk 15 constitutes a recording medium according to the invention, readable by the processor 13 and on which is recorded here a computer program PROGA according to the invention.
  • this PROGA computer program comprises an Internet browser NAV and an IT agent AG downloaded from a server SRV_COMP in the network offering a contract proposal composition service.
  • the PROGA computer program defines functional modules (and software here), configured to implement the steps of a process for disseminating a contract proposal according to the invention.
  • FIG. 2 represents the hardware architecture of a device DB for accepting a contract proposal in accordance with a particular embodiment of the invention.
  • this DB device is integrated in the terminal TB of a user Bob and in the terminal TC of a user Charly.
  • This device DB comprises in particular a processor 23, a random access memory 24, a hard disk 25 as well as means of communication 27 on the telecommunications network.
  • the hard disk 25 constitutes a recording medium according to the invention, readable by the processor 23 and on which is recorded here a computer program PROGB according to the invention.
  • the PROGB computer program defines functional modules (and software here), configured to implement the steps of a contract proposal acceptance process according to the invention.
  • the user Alice uses her terminal TA to subscribe to the contract composition service with an SRV_COMP server.
  • the TA terminal downloads the AG agent from the SRV_COMP server and installs this AG agent on the hard disk 15 of the DA device.
  • this AG agent comprises:
  • an AG_DIFF module configured to generate an intelligent contract from data received from the AG_REDA module and to broadcast the intelligent contract in the network to request its registration in a chain of blocks CB.
  • this agent AG when Alice installs the agent AG in her terminal TA, during a step A20, this agent AG:
  • the AG_REDA module for generating cryptographic keys can be external to the agent, for example installed in a remote server.
  • ⁇ can be obtained by any means known from the state of the art.
  • step A30 Alice wishes to post a new contract proposal to the CB blockchain.
  • Alice uses the AG_REDA extension module installed as an extension module for its Internet browser NAV.
  • This plug-in downloads a web page from the SRV_COMP composition server that constitutes a FORM_PC contract proposal writing assistance form and displays it in Alice's NAV browser.
  • This FORM_PC form is represented in figure 4.
  • the FORM_PC form comprises:
  • this part A comprising:
  • the second part B specified by Alice includes: - a "Cond" field in which the second part B can specify the conditions for accepting the contract proposal;
  • This validation has the effect of generating, during a step A40, a SCGA smart contract represented in FIG. 5.
  • This SCGA contract is an executable computer code which translates the contract proposal drafted by Alice by means of the FORM_PC form and which comprises:
  • a computer method for generating the GEN_CTRT_SPEC contract configured to generate a personalized contract between Alice and this third party and to request its registration in the chain of blocks CB.
  • the computer method of generating the GEN_CTRT_SPEC contract is further configured to verify a signature of said transaction by this third party.
  • agent AG
  • the FORM_PC form for help with drafting a contract proposal does not include the date fields "Date” and signature "Sign”, and the validation OK button is configured for, when is activated, automatically generate a date to sign it, and insert it into the SCGA smart contract.
  • all chain users including Alice, Bob, Charly receive the new CB blockchain.
  • the execution of this method generates the display of a FORM_CS form in the NAV browser of Bob's TB terminal shown in figure 6. It comprises, in this embodiment:
  • the validation button OK can also be used by Bob to broadcast a transaction to subscribe to the contract proposal.
  • the FORM_CS form does not include the date fields "Date” and signature "Sign”, and the validation OK button is configured to, when it is activated, automatically generate a date, sign it. , and insert it into the TR_AB transaction.
  • the FORM_CS form does not include the date fields "Date” and signature "Sign", and pressing the "OK” button only results in the broadcast of the TR_AB transaction.
  • This TR_AB transaction transmitted in the blockchain CB includes proof of Bob's willingness to have a mining device execute the GEN_CTRT_SPEC method of the SCGA smart contract to generate a SCAB personalized contract.
  • the identifier GEN_CTRT_SPEC of the method of the contract to be executed to generate a SBAB personalized contract is also used to verify a signature of said transaction (TR_AB) by the second party.
  • the verification of the signature of the TR_AB transaction is implemented by means of the execution of the GEN_CTRT_SPEC method.
  • the GEN_CTRT_SPEC method is also executed to verify the signature of the TR_AB transaction with the public key of Bob KEYB PUB and to save the generated SCAB custom contract.
  • all users of the chain including Alice, Bob, Charly receive the new blockchain CB; Alice can thus learn about the personalized SCAB contract concluded with Bob.
  • the GEN_CTRT_SPEC method checks that the conditions of the COND field set by Bob are acceptable before generating the SCAB personalized contract.
  • the owner of the SCAB contract in the blockchain is the SCGA smart contract and not Bob.
  • the SCAB contract is not signed with Bob's private key KEYBPRIV.
  • the SCAB contract is finalized by the SCGA smart contract based on Bob's specific conditions, but Bob's TB terminal is not involved in generating the SCAB custom contract or registering it in the blockchain.
  • the SCGA smart contract can always be verified since it is registered in the CB blockchain.
  • Executing this method then generates the display of the FORM_CS Web form in the browser of Charly's terminal.
  • Charly can set its own acceptance conditions and broadcast a TR_AC transaction, signed with its private key KEYCPRIV to blockchain users.
  • This TR_AC transaction is similar to Bob's TR_AB transaction. It involves :
  • the GEN_CTRT_SPEC identifier of the method of the contract to be executed is also used to verify the transaction, and to record the generated SCAC contract.
  • the owner of the SCAC contract in the blockchain is the SCGA smart contract and not Charly; the SCAC contract is not signed with Charly's private key KEYCPRIV.
  • FIG 8 shows the chain of blocks CB. It is fundamental to note that it includes:
  • a copy of this chain is stored by the terminals TA, TB, TC and Ui.
  • @A is a pointer to find Alice's KEYA PUB key in the blockchain.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Tourism & Hospitality (AREA)
  • Accounting & Taxation (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Technology Law (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Finance (AREA)
  • Primary Health Care (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Data Mining & Analysis (AREA)
  • Development Economics (AREA)
  • Bioethics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Procédé de négociation de contrat entre deux parties dans un réseau de télécommunications et dispositifs mettant en œuvre ce procédé Ce procédé de négociation de contrat comporte : - la diffusion, par une première partie (A), d'un contrat intelligent (SCGA) comportant : - une méthode de souscription (SUBS_SCGA) permettant à une deuxième partie de diffuser une transaction (TR_AB) pour souscrire à la proposition de contrat; - une méthode (GEN_CTRT_SPEC) pour générer un contrat personnalisé (SCAB) entre les parties et demander son enregistrement dans la chaîne de blocs (CB), le contrat personnalisé (SCAB) étant généré à partir de paramètres compris dans ladite transaction (TR_AB); - une étape (B70) d'exécution de ladite méthode de souscription (SUBS_SCGA) par un terminal (TB) de ladite deuxième partie, ladite exécution déclenchant la diffusion (B80) d'une transaction (TR_AB) comportant des paramètres représentatifs de l'acceptation de la proposition de contrat par la deuxième partie; - une étape (U90) d'exécution par un dispositif (Ui) de minage de ladite méthode (GEN_CTRT_SPEC) de génération de contrat personnalisé avec ces paramètres.

Description

Titre de l'invention : Procédé de négociation de contrat entre deux parties dans un réseau de télécommunications et dispositifs mettant en œuvre ce procédé
Technique antérieure
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 »).
Comme indiqué dans le document (https://fr.wikipedia.org/wiki/Blockchain), on rappelle que « la technologie des chaînes de blocs est une technologie de stockage et de transmission d'informations sans organe de contrôle. Techniquement, il s'agit d'une base de données distribuée dont les informations envoyées par les utilisateurs et les liens internes à la base sont vérifiés et groupés à intervalles de temps réguliers en blocs, l'ensemble étant sécurisé par cryptographie, et formant ainsi une chaîne. Par extension, une chaîne de blocs est une base de données distribuée qui gère une liste d'enregistrements protégés contre la falsification ou la modification par les nœuds de stockage ; c'est donc un registre distribué et sécurisé de toutes les transactions effectuées depuis le démarrage du système réparti».
Cette technologie est utilisée notamment comme registre pour enregistrer des transactions en crypto-monnaie.
L’utilisation de la technologie des chaînes de blocs pour enregistrer des contrats a été envisagée. Dans ce contexte, l’utilisation d’une chaîne de blocs est particulièrement avantageuse car elle permet de s’assurer qu’un contrat enregistré dans la chaîne ne pourra pas être falsifié.
L’invention propose d’étendre l’usage de la technologie des chaînes de blocs à la phase d’élaboration et de négociation des contrats.
Elle peut notamment être mise en œuvre dans toute chaîne de bloc offrant un mécanisme connu de l’homme du métier sous le nom de « contrat intelligent » (en anglais Smart Contract), notamment et de façon non limitative, dans la chaîne de blocs Ethereum (marque déposée). Exposé de l’invention
Plus précisément, selon un premier aspect, l’invention propose un procédé de diffusion, dans un réseau de télécommunications, d’une proposition de contrat proposée par une première partie, ce procédé comportant :
- une étape de génération d’un contrat intelligent comportant :
- l’adresse d’un registre comportant une clé publique de la première partie dans une chaîne de blocs ;
- des données représentatives des termes de la proposition de contrat ;
- une méthode de souscription permettant à au moins une deuxième partie de diffuser une transaction dans le réseau pour souscrire à la proposition de contrat ;
- une méthode de génération de contrat configurée pour générer un contrat personnalisé entre la première partie et une deuxième partie et pour demander l’enregistrement de ce contrat personnalisé dans la chaîne de blocs, ce contrat personnalisé étant généré à partir de paramètres compris dans la transaction et représentatifs d’une volonté de ladite deuxième partie d’accepter les termes de la proposition de contrat ;
- une étape de signature du contrat intelligent avec une clé privée de la première partie ; et
- une étape de diffusion dans le réseau du contrat intelligent signé pour demander son enregistrement dans la chaîne de blocs.
Corrélativement, l’invention concerne un dispositif de diffusion, dans un réseau de télécommunications, d’une proposition de contrat proposée par une première partie, ce dispositif comportant :
- un module de génération d’un contrat intelligent comportant :
- l’adresse d’un registre comportant une clé publique de la première partie dans une chaîne de blocs ;
- des données représentatives des termes de la proposition de contrat ; - une méthode de souscription permettant à au moins une deuxième partie de diffuser une transaction dans ledit réseau pour souscrire à la proposition de contrat ;
- une méthode de génération de contrat configurée pour générer un contrat personnalisé entre la première partie et une dite deuxième partie et pour demander l’enregistrement de ce contrat personnalisé dans la chaîne de blocs, ce contrat personnalisé étant généré à partir de paramètres compris dans la transaction et représentatifs d’une volonté de la deuxième partie d’accepter les termes de la proposition de contrat ;
- un module de signature du contrat intelligent avec une clé privée de la première partie ; et
- un module de diffusion dans le réseau du contrat intelligent signé pour demander son enregistrement dans la chaîne de blocs.
Selon un deuxième aspect, l’invention concerne un procédé d’acceptation d’une proposition de contrat diffusée dans un réseau de télécommunications, ce procédé étant mis en oeuvre par le terminal d’un utilisateur et comportant :
- une étape d’obtention d’un contrat intelligent enregistré dans une chaîne de blocs, ce contrat intelligent comportant :
- l’adresse, dans la chaîne de blocs, d’un registre comportant une clé publique d’une première partie propriétaire de la proposition de contrat ;
- des données représentatives de termes de la proposition de contrat ;
- une méthode de souscription permettant à au moins une deuxième partie de diffuser une transaction dans le réseau pour souscrire à la proposition de contrat ;
- une méthode de génération de contrat configurée pour générer un contrat personnalisé entre la première partie et une dite deuxième partie et demander l’enregistrement du contrat personnalisé dans la chaîne de blocs, ce contrat personnalisé étant généré à partir de paramètres compris dans la transaction et représentatifs d’une volonté de la deuxième partie d’accepter les termes de la proposition de contrat ; - une étape d’obtention de paramètres représentatifs d’une volonté de l’utilisateur d’accepter les termes de la proposition de contrat ;
- une étape d’exécution de la méthode de souscription, cette exécution déclenchant la diffusion dans le réseau d’une transaction, signée avec une clé privée de l’utilisateur, et comportant :
- l’adresse d’une clé publique de l’utilisateur dans la chaîne de blocs ; l’adresse du contrat intelligent dans la chaîne de blocs ;
- un identifiant de la méthode de génération de contrat; et
- les paramètres précités.
Corrélativement, l’invention vise un dispositif d’acceptation d’une proposition de contrat diffusée dans un réseau de télécommunications, ce dispositif étant mis en oeuvre dans le terminal d’un utilisateur et comportant :
- - un module d’obtention d’un contrat intelligent enregistré dans une chaîne de blocs, ce contrat intelligent comportant :
- l’adresse, dans la chaîne de blocs, d’un registre comportant une clé publique d’une première partie propriétaire de la proposition de contrat ;
- des données représentatives de termes de la proposition de contrat ;
- une méthode de souscription permettant à au moins une deuxième partie de diffuser une transaction dans ledit réseau pour souscrire à ladite proposition de contrat ;
- une méthode de génération de contrat configurée pour générer un contrat personnalisé entre la première partie et une dite deuxième partie et pour demander l’enregistrement du contrat personnalisé dans la chaîne de blocs, ce contrat personnalisé étant généré à partir de paramètres compris dans la transaction et représentatifs d’une volonté de la deuxième partie d’accepter les termes de la proposition de contrat ;
- un module d’obtention de paramètres représentatifs d’une volonté de l’utilisateur d’accepter les termes de ladite proposition de contrat ; - un module d’exécution de la méthode de souscription, cette exécution déclenchant la diffusion dans le réseau d’une transaction, signée avec une clé privée de l’utilisateur, et comportant :
- l’adresse d’une clé publique de l’utilisateur dans la chaîne de blocs ;
- l’adresse du contrat intelligent dans la chaîne de blocs ;
- un identifiant de la méthode de génération de contrat; et
- les paramètres précités.
L’invention vise également un procédé de négociation de contrat entre deux parties dans un réseau de télécommunications, ce procédé comportant :
- la génération d’une proposition de contrat par la première partie, sous la forme d’un contrat intelligent comportant :
- l’adresse d’un registre comportant une clé publique de la première partie dans une chaîne de blocs;
- des données représentatives des termes de la proposition de contrat ;
- une méthode de souscription permettant à la deuxième partie de diffuser une transaction dans le réseau pour souscrire à cette proposition de contrat ;
- une méthode de génération de contrat configurée pour générer un contrat personnalisé entre la première partie et la deuxième partie et pour demander l’enregistrement du contrat personnalisé dans la chaîne de blocs, ce contrat personnalisé étant généré à partir de paramètres compris dans la transaction et représentatifs d’une volonté de la deuxième partie d’accepter les termes de la proposition de contrat;
- une étape de signature du contrat intelligent avec une clé privée de la première partie ;
- une étape de diffusion du contrat intelligent signé dans ledit réseau pour demander son enregistrement dans la chaîne de blocs ;
- une étape d’obtention du contrat intelligent par la deuxième partie ; - une étape d’obtention de paramètres représentatifs d’une volonté de ladite deuxième partie d’accepter les termes de ladite proposition de contrat ;
- une étape d’exécution de la méthode de souscription par un terminal de la deuxième partie, cette exécution déclenchant la diffusion dans le réseau d’une transaction, signée avec une clé privée de la deuxième partie, et comportant :
- l’adresse d’une clé publique de l’utilisateur dans la chaîne de blocs ;
- l’adresse du contrat intelligent dans la chaîne de blocs ;
- un identifiant de ladite méthode de génération de contrat; et
- les paramètres précités; et
- une étape d’exécution, mise en oeuvre par un dispositif de minage de la chaîne de blocs, de la méthode de génération d’un contrat personnalisé, avec ces paramètres pour générer un contrat personnalisé entre les parties, l’enregistrer dans la chaîne de blocs et rediffuser la chaîne de blocs.
Au sens de l’invention, l’« adresse » d’une ressource dans la chaîne de blocs est un pointeur vers une ressource dans la chaîne de blocs.
On rappelle qu’un contrat intelligent (en anglais Smart Contract) est un programme informatique autonome, qui une fois démarré, exécute automatiquement des conditions définies au préalable et inscrites dans la chaîne de blocs (https://blockchainfrance.net/2016/01/28/applications-smart-contracts/). Les applications décentralisées dApps du projet Ethereum constituent des contrats intelligents au sens de l’invention.
Dans l’invention, une transaction (notamment les transactions TR_AB et TR_AC de la description détaillée) sont des transactions au sens de la technologie des chaînes de blocs, à savoir des enregistrements dans la chaîne de blocs.
Au sens de l’invention un contrat personnalisé par une partie comporte des éléments représentatifs de la volonté de cette partie d’accepter les termes du contrat.
Ainsi, et d’une façon générale, l’invention propose un mécanisme permettant la négociation de contrats dans un réseau dans lequel on enregistre dans une chaîne de blocs : - une proposition de contrat diffusée à l’ensemble des participants à la chaîne de blocs, à l’initiative d’un premier utilisateur, propriétaire de la proposition de contrat et partie au contrat ;
- une transaction représentant la volonté d’un autre utilisateur de la chaîne de blocs, une deuxième partie, de souscrire à la proposition de contrat,
et
- un contrat personnalisé, généré à partir de cette proposition de contrat, entre ce premier utilisateur, et la deuxième partie au contrat.
Le procédé est remarquable en ce que la proposition de contrat est enregistrée dans la chaîne de blocs sous forme d’un contrat intelligent et en ce que le contrat personnalisé est généré par une méthode de ce contrat intelligent, suite à une transaction diffusée par la deuxième partie souhaitant souscrire au contrat, par laquelle cette deuxième partie diffuse aux utilisateurs de la chaîne de blocs, des paramètres représentatifs de sa volonté d’accepter les termes de la proposition de contrat.
De façon remarquable, l’invention utilise la chaîne de blocs pour établir un lien immuable entre la proposition de contrat et le contrat personnalisé. En effet, le contrat personnalisé est généré par le contrat intelligent lui-même, celui-ci pouvant être vérifié à tout moment par les utilisateurs de la chaîne de blocs.
Conformément à l’invention, et contrairement aux méthodes de l’art antérieur, le contrat personnalisé est, dans la chaîne de blocs, la propriété du contrat intelligent (c’est-à-dire de la proposition de contrat) et non de la deuxième partie au contrat.
Le contrat personnalisé obtenu par l’invention peut être constitué par un ensemble de données statiques.
Dans un mode préféré de réalisation de l’invention, le contrat personnalisé est un contrat intelligent. Ce contrat intelligent peut contenir un code informatique configuré pour s’exécuter lors ou après l’exécution du contrat personnalisé entre les parties.
Dans un mode particulier de réalisation de l’invention, la méthode de génération de souscription est configurée pour obtenir des conditions d’acceptation de la proposition de contrat par la deuxième partie, ces conditions d’acceptation faisant partie des paramètres compris dans la transaction pour générer le contrat personnalisé.
Dans un mode particulier de réalisation, la méthode de génération de contrat peut être configurée pour vérifier si ces conditions d’acceptation sont compatibles avec les termes de la proposition de contrat avant de générer le contrat spécifique.
Dans un mode de réalisation, le procédé de diffusion de proposition de contrat selon l’invention comporte une étape de téléchargement d’un agent informatique auprès d’un serveur, cet agent comportant :
- un module pour obtenir, de la première partie, des données représentatives des termes de la proposition de contrat ; et
- un module pour générer le contrat intelligent à partir de ces données et pour diffuser le contrat intelligent dans le réseau.
Corrélativement, dans ce mode de réalisation, le dispositif de diffusion selon l’invention comporte :
- un module de communication apte à télécharger un agent à partir d’un serveur ;
- un module de traitement apte à installer cet agent dans le dispositif ;
- cet agent comportant le module de génération de contrat, le module de signature et le module de diffusion du dispositif de diffusion.
Cet agent est remarquable en ce qu’il permet d’assister l’utilisateur dans la rédaction de la proposition de contrat, et en ce qu’il réalise, de façon transparente pour l’utilisateur, son implémentation dans un contrat intelligent et l’enregistrement de ce contrat dans la chaîne de blocs. La Demanderesse a en effet constaté que dans l’état actuel de la technique les propriétaires de données enregistrées dans les chaînes de blocs étaient des experts en informatique.
L’invention vise au contraire une solution de négociation de contrats en ligne qui ne nécessite pas de connaissance dans la technologie des chaînes de blocs.
Dans un mode de réalisation de l’invention, cet agent comporte en outre un module pour signer le contrat intelligent avec la clé privée de la première partie. En variante, le contrat intelligent peut être signé avec la clé privée de la première partie par un module cryptographique de son terminal et fourni signé à l’agent pour diffusion dans la chaîne de blocs.
Dans un mode particulier de réalisation, les différentes étapes du procédé de diffusion de proposition de contrat, du procédé d’acceptation de proposition de contrat et de négociation de contrat sont déterminées par des instructions de programmes d’ordinateurs.
En conséquence, l’invention vise aussi un programme d’ordinateur sur un support d’informations, ce programme étant susceptible d’être mis en œuvre dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé tel que décrit ci-dessus.
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'informations ou d’enregistrement lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations ou d’enregistrement peut ê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, le support d'informations ou d’enregistrement peut être 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. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations ou d’enregistrement peut être 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. Brève description des dessins
D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : la figure 1 représente l’architecture matérielle d’un dispositif de diffusion de proposition de contrat conforme à un mode particulier de réalisation de l’invention ;
- la figure 2 représente l’architecture matérielle d’un dispositif d’acceptation d’une proposition de contrat conforme à un mode particulier de réalisation de l’invention;
- la figure 3 illustre sous forme d’ordinogramme, les principales étapes des procédés conformes à un mode particulier de réalisation de l’invention ;
- la figure 4 représente un formulaire de rédaction de proposition de contrat pouvant être utilisé dans l’invention ;
- la figure 5 illustre un contrat intelligent pouvant être utilisé dans l’invention ;
- la figure 6 représente un formulaire de rédaction d’acceptation de proposition de contrat pouvant être utilisé dans l’invention ;
- la figure 7 illustre une transaction pouvant être utilisée dans l’invention ; et - la figure 8 représente une chaîne de blocs comportant des blocs générés par l’invention 8.
Description des modes de réalisation
La figure 1 représente l’architecture matérielle d’un dispositif DA de diffusion de proposition de contrat conforme à un mode particulier de réalisation de l’invention. Dans le mode de réalisation décrit ci-après ce dispositif DA est intégré dans le terminal TA d’un utilisateur Alice.
Ce dispositif DA comprend notamment un processeur 13, une mémoire vive 14, un disque dur 15 ainsi que des moyens de communication 17 lui permettant de communiquer sur un réseau de télécommunications, notamment avec des terminaux. Ces moyens de communication incluent par exemple une interface WIFI, une carte réseau, etc. en fonction de la nature du réseau.
Le disque dur 15 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 13 et sur lequel est enregistré ici un programme d’ordinateur PROGA conforme à l’invention.
Dans le mode de réalisation décrit ici, ce programme d’ordinateur PROGA comporte un navigateur Internet NAV et un agent informatique AG téléchargé depuis un serveur SRV_COMP du réseau offrant un service de composition de proposition de contrats.
Le programme d’ordinateur PROGA définit des modules fonctionnels (et logiciels ici), configurés pour mettre en œuvre les étapes d’un procédé de diffusion d’une proposition de contrat selon l’invention.
La figure 2 représente l’architecture matérielle d’un dispositif DB d’acceptation d’une proposition de contrat conforme à un mode particulier de réalisation de l’invention. Dans le mode de réalisation décrit ci-après ce dispositif DB est intégré dans le terminal TB d’un utilisateur Bob et dans le terminal TC d’un utilisateur Charly.
Ce dispositif DB comprend notamment un processeur 23, une mémoire vive 24, un disque dur 25 ainsi que des moyens de communication 27 sur le réseau de télécommunications.
Le disque dur 25 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 23 et sur lequel est enregistré ici un programme d’ordinateur PROGB conforme à l’invention.
Le programme d’ordinateur PROGB définit des modules fonctionnels (et logiciels ici), configurés pour mettre en œuvre les étapes d’un procédé d’acceptation de proposition de contrat selon l’invention.
En référence à la figure 3, nous allons maintenant décrire :
- les principales étapes A10 à A50 d’un procédé de diffusion d’une proposition de contrat selon l’invention mises en œuvre par le terminal TA d’Alice, - les principales étapes B70 et B80 d’un procédé d’acceptation d’une proposition de contrat mises en œuvre par le terminal TB de Bob et par le terminal TC de Charly ; et
- les principales étapes A10 à A50, U60, B70, B80 et U90 d’un procédé de négociation de contrat mises en œuvre conjointement par le terminal TA d’Alice, le terminal TB de Bob ou celui TC de Charly et le terminal U1 d’un mineur de la chaîne de blocs.
Au cours d’une étape A10, l’utilisateur Alice (ci-après Alice) utilise son terminal TA pour souscrire au service de composition de contrats auprès d’un serveur SRV_COMP. Le terminal TA télécharge l’agent AG auprès du serveur SRV_COMP et installe cet agent AG sur le disque dur 15 du dispositif DA.
Dans le mode de réalisation décrit ici, cet agent AG comporte :
- un module AG_GENKEY de génération de clés cryptographiques ;
- un module AG_SIGN de signature cryptographique ;
-un module AG_REDA d’aide à la rédaction de propositions de contrats ; et
- un module AG_DIFF configuré pour générer un contrat intelligent à partir de données reçues du module AG_REDA et pour diffuser le contrat intelligent dans le réseau pour demander son enregistrement dans une chaîne de blocs CB.
Dans le mode de réalisation décrit ici, lorsqu’Alice installe l’agent AG dans son terminal TA, au cours d’une étape A20, cet agent AG :
- génère une paire de clés {KEYAPUB (clé publique), KEYAPRIV (clé privée)} pour Alice en utilisant son module AG_GENKEY de génération de clés cryptographiques ;
- enregistre la clé publique KEYAPUB d’Alice dans la chaîne de blocs CB;
- mémorise la paire de clés {KEYAPUB, KEYAPRIV} sur le disque dur 15 du dispositif DA ; et
- installe le module AG_REDA d’aide à la rédaction de propositions de contrats en tant que module d’extension (en anglais plug-in) du navigateur NAV du terminal TA. Dans un autre mode de réalisation, le module AG_GENKEY de génération de clés cryptographiques peut être extérieur à l’agent, par exemple installé dans un serveur distant. La paire de clés {KEYAPUB, KEYAPR| } peut être obtenue par tout moyen connu de l’état de la technique.
Nous supposerons que d’autres utilisateurs Bob et Charly, Uij=i , ...N se sont déjà enregistrés dans la chaîne de blocs CB lors d’une phase d’inscription et que leurs clés publiques KEYBPUB, KEYCPUB, KEYUÎPUB sont enregistrées dans la chaîne de blocs CB.
Au cours d’une étape A30, Alice souhaite publier une nouvelle proposition de contrat dans la chaîne de blocs CB. Elle utilise pour cela le module d’extension AG_REDA installé dans forme de module d’extension de son navigateur Internet NAV.
Ce module d’extension télécharge depuis le serveur de composition SRV_COMP une page Web qui constitue un formulaire FORM_PC d’aide à la rédaction de proposition de contrat et l’affiche dans le navigateur NAV d’Alice. Ce formulaire FORM_PC est représenté à la figure 4.
Dans le mode de réalisation décrit ici, le formulaire FORM_PC comporte :
- une partie A à remplir par la première partie au contrat, ici Alice, pour proposer un nouveau contrat, cette partie A comportant :
- un champ « Termes » pour définir les termes de la proposition de contrat,
- un champ « Date » de date et un champ « Sign » de signature permettant à la première partie au contrat de dater la proposition de contrat et de la signer avec un stylo électronique ;
- un bouton de validation « OK » utilisable par la première partie au contrat pour demander l’enregistrement de la proposition de contrat dans la chaîne de blocs CB ;
- une partie B permettant de définir les informations devant être fournies par une deuxième partie pour accepter cette proposition de contrat, certaines (marquées d’un astérisque) étant optionnelles. Dans l’exemple décrit ici, la deuxième partie B spécifiée par Alice comporte : - un champ « Cond » dans laquelle la deuxième partie B peut préciser des conditions d’acceptation de la proposition de contrat ;
- un champ « Date » de date et un champ « Sign » de signature permettant à la deuxième partie au contrat de dater l’acceptation de contrat et de la signer avec un stylo électronique. Alice décide que ces champs « Date » et « Sign » doivent nécessairement être renseignés.
Nous supposerons qu’Alice :
- remplit le champ « Termes » avec une offre de service et un prix associé, par exemple, « la société Alice recherche une personne pour livrer des pizzas sur Paris, chaque livraison étant rémunérée 10 euros » ;
- date la proposition de contrat dans le champ « Date » ;
-signe la proposition de contrat avec un stylet électronique dans le champ « Sign » ; et
valide sa proposition de contrat au contrat en utilisant le bouton « OK ».
Cette validation a pour effet de générer, au courant d’une étape A40, un contrat intelligent SCGA représenté à la figure 5. Ce contrat SCGA est un code informatique exécutable qui traduit la proposition de contrat rédigée par Alice au moyen du formulaire FORM_PC et qui comporte :
- l’adresse @A du registre comportant la clé publique d’Alice KEYAPUB dans la chaîne de blocs CB ;
- des données TERMES, DATE, SIGN signées avec la clé privée KEYAPRIV d’Alice et qui reprennent les champs de la partie A du formulaire FORM_PC remplis par Alice ;
- une méthode informatique SUBS_SCGA de souscription permettant à un tiers souhaitant souscrire à la proposition de contrat, de diffuser une transaction dans le réseau à cet effet; et
- une méthode informatique de génération de contrat GEN_CTRT_SPEC configurée pour générer un contrat personnalisé entre Alice et ce tiers et pour demander son enregistrement dans la chaîne de blocs CB. La méthode informatique de génération de contrat GEN_CTRT_SPEC est en outre configurée pour vérifier une signature de ladite transaction par ce tiers.
Au cours d’une étape A50, l’agent AG :
- signe le contrat intelligent SCGA avec la clé privée d’Alice KEYAPRIV en utilisant le module AG_SIGN ; et
- diffuse le contrat intelligent SCGA signé dans la chaîne de blocs CB en utilisant le module AG_DIFF pour demander son enregistrement dans la chaîne de blocs.
Dans un autre mode de réalisation, le formulaire FORM_PC d’aide à la rédaction de proposition de contrat ne comporte pas les champs de date « Date » et de signature « Sign », et le bouton OK de validation est configuré pour, lorsqu’il est activé, générer automatiquement une date la signer, et l’insérer dans le contrat intelligent SCGA.
Conformément à la technologie des chaînes de blocs, tous les utilisateurs de la chaîne, et notamment Alice, Bob, Charly, Ui reçoivent ce contrat intelligent et peuvent en prendre connaissance.
La proposition de contrat SCGA ayant été signée avec la clé privée d’Alice, cette proposition de contrat est, dans la chaîne de blocs CB, la propriété d’Alice. On notera que l’agent AG n’est pas authentifié dans la chaîne de blocs CB.
Nous supposerons qu’un utilisateur Ui joue le rôle de mineur dans la chaîne de blocs CB, et qu’au cours d’une étape U60, il vérifie la signature du contrat intelligent SCGA avec la clé publique d’Alice KEYAPUB, insère le contrat intelligent SCGA dans un bloc d’adresse @SCGA dans la chaîne de blocs CB et rediffuse la chaîne de blocs CB.
Conformément à la technologie des chaînes de blocs, tous les utilisateurs de la chaîne, et notamment Alice, Bob, Charly reçoivent la nouvelle chaîne de blocs CB.
Nous supposerons que Bob prend connaissance de la proposition de contrat d’Alice au cours d’une étape B70 et décide d’y souscrire en invoquant la méthode de souscription SUBS_SCGA du contrat intelligent SCGA.
L’exécution de cette méthode génère l’affichage d’un formulaire FORM_CS dans le navigateur NAV du terminal TB de Bob représenté à la figure 6. Il comporte, dans ce mode de réalisation :
- une partie A reconstituée à partir des informations fournies par Alice et contenues dans les champs TERMES, DATE, SIGN du contrat intelligent SCGA ;
- une partie B qui reprend :
- des champs « Cond », « Date » et « Sign » tels que définis par Alice dans son formulaire FORM_PC et qui peuvent être édités par Bob pour générer des données représentatives de sa volonté d’accepter les termes de la proposition de contrat, ces données devant comporter une date et une signature et éventuellement des conditions d’acceptation de la proposition de contrat ; et
- un bouton de validation OK utilisable par Bob pour demander la génération et l’enregistrement d’un contrat personnalisé SCAB entre Alice et Bob dans la chaîne de blocs CB.
Le bouton de validation OK est en outre utilisable par Bob pour diffuser une transaction pour souscrire à la proposition de contrat.
Nous supposerons que Bob, au cours d’une étape B80, définit ses conditions dans le champ « Cond », date, signe le formulaire FORM_CS avec un stylet électronique et valide sa demande de transaction avec le bouton « OK ». Cette validation entraîne la diffusion d’une transaction TR_AB, signée avec la clé privée KEYBPRIV de Bob à destination des utilisateurs de la chaîne de blocs, dont Alice, Charly et Ui.
Dans un autre mode de réalisation, le formulaire FORM_CS ne comporte pas les champs de date « Date » et de signature « Sign », et le bouton OK de validation est configuré pour, lorsqu’il est activé, générer automatiquement une date, la signer, et l’insérer dans la transaction TR_AB.
Dans un autre mode de réalisation, le formulaire FORM_CS ne comporte pas les champs de date « Date » et de signature « Sign », et l’appui sur le bouton « OK » entraîne seulement la diffusion de la transaction TR_AB.
Cette transaction TR_AB transmise dans la chaîne de blocs CB comporte la preuve de la volonté de Bob de vouloir faire exécuter par un dispositif de minage la méthode GEN_CTRT_SPEC du contrat intelligent SCGA pour générer un contrat personnalisé SCAB. Cette transaction TR_AB représentée à la figure 7 et comporte :
- l’adresse @B de la clé publique de Bob KEYBPUB dans la chaîne de blocs CB ;
- l’adresse @SCGA du contrat intelligent SCGA dans la chaîne de blocs CB ;
- un identifiant GEN_CTRT_SPEC de la méthode de ce contrat à exécuter pour générer un contrat personnalisé SCAB;
- des champs COND, DATE et SIGN qui reprennent les conditions, la date et la signature de Bob édités dans les champs « Cond », « Date » et « Sign » du formulaire FORM_SC et qui serviront de paramètres à la méthode GEN_CTRT_SPEC pour générer le contrat personnalisé SCAB.
L’identifiant GEN_CTRT_SPEC de la méthode de du contrat à exécuter pour générer un contrat personnalisé SBAB est aussi utilisé pour vérifier une signature de ladite transaction (TR_AB) par la deuxième partie.
Au cours d’une étape U90, un utilisateur Ui qui joue le rôle de mineur dans la chaîne de blocs CB :
- vérifie la signature de la transaction TR_AB avec la clé publique de Bob KEYBRUB ;
- exécute, pour générer le contrat personnalisé SCAB, la méthode GEN_CTRT_SPEC du contrat intelligent SCGA en prenant pour paramètres les données des champs COND, DATE et SIGN de la transaction TR_AB ;
- insère le contrat personnalisé SCAB dans un registre d’adresse @SCAB de la chaîne de blocs CB ; et
- rediffuse la chaîne de blocs CB.
La vérification de la signature de la transaction TR_AB est mise en œuvre au moyen de l’exécution de la méthode GEN_CTRT_SPEC. En d’autres termes, la méthode GEN_CTRT_SPEC est aussi exécuté pour vérifier la signature de la transaction TR_AB avec la clé publique de Bob KEYBPUB et enregistrer le contrat personnalisé SCAB généré.
Conformément à la technologie des chaînes de blocs, tous les utilisateurs de la chaîne, et notamment Alice, Bob, Charly reçoivent la nouvelle chaîne de blocs CB ; Alice peut ainsi prendre connaissance du contrat SCAB personnalisé conclu avec Bob.
Dans le mode de réalisation décrit ici, la méthode GEN_CTRT_SPEC vérifie que les conditions du champ COND posées par Bob sont acceptables avant de générer le contrat personnalisé SCAB.
Il est fondamental de constater que le propriétaire du contrat SCAB dans la chaîne de blocs est le contrat intelligent SCGA et non pas Bob. En particulier, le contrat SCAB n’est pas signé avec la clé privée KEYBPRIV de Bob. Le contrat SCAB est finalisé par le contrat intelligent SCGA à partir des conditions spécifiques de Bob mais le terminal TB de Bob n’intervient ni pour la génération du contrat personnalisé SCAB ni pour son enregistrement dans la chaîne de blocs. L’homme du métier des chaînes de blocs comprendra que le contrat intelligent SCGA peut toujours être vérifié puisqu’il est enregistré dans la chaîne de blocs CB.
Nous supposons maintenant qu’un autre utilisateur inscrit dans la chaîne des blocs, par exemple Charly, décide, comme Bob à l’étape B70, de répondre à la proposition de contrat d’Alice en invoquant la méthode de souscription SUBS_SCGA du contrat intelligent SCGA.
L’exécution de cette méthode génère alors l’affichage du formulaire Web FORM_CS dans le navigateur du terminal de Charly.
Au cours d’une étape similaire à l’étape B80 précédemment décrite, Charly peut fixer ses propres conditions d’acceptation et diffuser une transaction TR_AC, signée avec sa clé privée KEYCPRIV à destination des utilisateurs de la chaîne de blocs.
Cette transaction TR_AC est similaire à celle TR_AB de Bob. Elle comporte :
- l’adresse @C de la clé publique de Charly KEYCPUB dans la chaîne de blocs CB
- l’adresse @SCGA du contrat intelligent SCGA dans la chaîne de blocs CB ;
- l’identifiant GEN_CTRT_SPEC de la méthode de ce contrat à exécuter pour générer SCAC; - des champs COND, DATE et SIGN qui reprennent les conditions, la date et la signature de Charly édités dans les champs « Cond », « Date » et « Sign » du formulaire FORM_SC et qui devront servir de paramètres à la méthode GEN_CTRT_SPEC pour générer un contrat personnalisé SCAC entre Alice et Charly.
L’identifiant GEN_CTRT_SPEC de la méthode du contrat à exécuter est utilisé aussi pour vérifier la transaction, et enregistrer le contrat SCAC généré.
Bien entendu, si les termes de la proposition de contrat lui conviennent tels quels, Charly peut ne pas fixer de conditions d’acceptation.
Au cours d’une étape similaire à l’étape U90 déjà décrite, un utilisateur Ui jouant le rôle de mineur dans la chaîne de blocs CB :
- vérifie la signature de la transaction TR_AC avec la clé publique de Charly KEYCPUB ;
- exécute la méthode GEN_CTRT_SPEC du contrat intelligent SCGA avec les données des champs COND, DATE et SIGN de la transaction TR_AC ;
- insère le contrat personnalisé SCAC dans un registre d’adresse @SCAC de la chaîne de blocs CB ; et
- rediffuse la rediffuse la chaîne de blocs CB.
Conformément à la technologie des chaînes de blocs, tous les utilisateurs de la chaîne, et notamment Alice, Bob, Charly reçoivent la nouvelle chaîne de blocs CB ; Alice peut ainsi prendre connaissance du contrat personnalisé SCAC conclu avec Charly.
Le propriétaire du contrat SCAC dans la chaîne de blocs est le contrat intelligent SCGA et non pas Charly ; le contrat SCAC n’est pas signé avec la clé privée KEYCPRIV de Charly.
La figure 8 représente la chaîne de blocs CB. Il est fondamental de constater qu’elle comporte :
- la proposition de contrat SCGA d’Alice ;
- les transactions TRA_AB et TR_AC ; - deux contrats personnalisés SCAB, SCAC, générés par SCGA, et propriétés de SCGA.
Une copie de cette chaîne est mémorisée par les terminaux TA, TB, TC et Ui.
A titre d’exemple, @A est un pointeur permettant de retrouver la clé KEYAPUB d’Alice dans la chaîne de blocs.

Claims

Revendications
1. Procédé de diffusion, dans un réseau de télécommunications, d'une
proposition de contrat (SCGA) proposée par une première partie (A), ce procédé comportant :
- une étape (A40) de génération d'un contrat intelligent (SCGA) comportant :
- l'adresse (@A) d'un registre comportant une clé publique
(KEYAPUB) de ladite première partie (Alice) dans une chaîne de blocs (CB) ;
- des données (TERMES) représentatives des termes de ladite proposition de contrat ;
- une méthode de souscription (SUBS_SCGA) permettant à au moins une deuxième partie (Bob, Charly) de diffuser une transaction (TR_AB) dans ledit réseau pour souscrire à ladite proposition de contrat ;
- une méthode de génération de contrat (GEN_CTRT_SPEC) configurée pour générer un contrat personnalisé (SCAB) entre ladite première partie (Alice) et une dite deuxième partie (Bob, Charly) et pour demander l'enregistrement dudit contrat personnalisé (SCAB) dans la chaîne de blocs (CB), ledit contrat personnalisé (SCAB) étant généré à partir de paramètres (COND, DATE, SIGN) compris dans ladite transaction (TR_AB) et représentatifs d'une volonté de ladite deuxième partie (Bob, Charly) d'accepter les termes de la proposition de contrat ;
- une étape (A50) de signature dudit contrat intelligent (SCGA) avec une clé privée (KEYAPRIV) de ladite première partie (Alice) ; et
- une étape (A50) de diffusion dudit contrat intelligent (SCGA) signé dans ledit réseau pour demander son enregistrement dans la chaîne de blocs.
2. Procédé de diffusion d'une proposition de contrat selon la revendication 1 dans lequel ledit contrat personnalisé est un contrat intelligent.
3. Procédé de diffusion d'une proposition de contrat selon la revendication 1 ou 2 dans lequel ladite méthode de génération de souscription (SUBS_SCGA) est configurée pour obtenir des conditions d'acceptation (Cond) de la proposition de contrat par ladite deuxième partie (Bob, Charly), lesdites conditions d'acceptation faisant partie des paramètres compris dans ladite transaction (TR_AB) utilisés pour générer ledit contrat personnalisé (SCAB).
4. Procédé de diffusion d'une proposition de contrat selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte une étape (A10) de téléchargement d'un agent informatique (AG) auprès d'un serveur (SRV_COMP), cet agent comportant :
- un module (AG_REDA) pour obtenir, de ladite première partie (A), lesdites données (TERMES) représentatives des termes de ladite proposition de contrat ; et
- un module (AG_DIFF) pour générer ledit contrat intelligent (SCGA) à partir desdites données (TERMES) et pour diffuser ledit contrat intelligent (SCGA) dans ledit réseau.
5. Procédé de diffusion d'une proposition de contrat selon la revendication 4, caractérisé en ce que ledit agent comporte en outre un module (AG_SIGN) pour signer ledit contrat intelligent (SCGA) avec la clé privée (KEYAPRIV) de ladite première partie (Alice).
6. Programme d'ordinateur (PROGA) comportant des instructions pour l'exécution des étapes du procédé de diffusion d'une proposition de contrat selon l'une quelconque des revendications 1 à 5 lorsque ledit programme est exécuté par un ordinateur (TA).
7. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de diffusion d'une proposition de contrat selon l'une quelconque des revendications 1 à 5.
8. Procédé d'acceptation d'une proposition de contrat diffusée dans un réseau de télécommunications, ce procédé étant mis en œuvre par un terminal (TB) d'un utilisateur (Bob) et comportant :
- une étape (B70) d'obtention d'un contrat intelligent (SCGA) enregistré dans une chaîne de blocs (CB), ledit contrat intelligent comportant :
- l'adresse (@A), dans ladite chaîne de blocs (CB), d'un registre comportant une clé publique (KEYAPÜB) d'une première partie (Alice) propriétaire de ladite proposition de contrat ; - des données (TERMES) représentatives de termes de ladite proposition de contrat ;
- une méthode de souscription (SUBS_SCGA) permettant à au moins une deuxième partie (Bob, Charly) de diffuser une transaction (TR_AB) dans ledit réseau pour souscrire à ladite proposition de contrat ;
- une méthode de génération de contrat (GEN_CTRT_SPEC) configurée pour générer un contrat personnalisé (SCAB) entre ladite première partie (Alice) et une dite deuxième partie (Bob, Charly) et pour demander l'enregistrement dudit contrat personnalisé (SCAB) dans la chaîne de blocs (CB), ledit contrat personnalisé (SCAB) étant généré à partir de paramètres (COND, DATE, SIGN) compris dans ladite transaction (TR_AB) fournis par ladite deuxième partie (Bob, Charly) et représentatifs d'une volonté de ladite deuxième partie (Bob, Charly) d'accepter les termes de la proposition de contrat;
- une étape d'obtention de paramètres (COND, DATE, SIGN) représentatifs d'une volonté dudit utilisateur (Bob) d'accepter les termes de ladite proposition de contrat ;
- une étape (B70) d'exécution de ladite méthode de souscription (SUBS_SCGA), ladite exécution déclenchant la diffusion (B80) dans le réseau d'une transaction (TR_AB), signée avec une clé privée (KEYBPRIV) dudit utilisateur (Bob) et comportant :
- l'adresse (@B) d'une clé publique (KEYBPÜB) dudit utilisateur (Bob) dans la chaîne de blocs (CB) ;
- l'adresse (@SCGA) dudit contrat intelligent (SCGA) dans la chaîne de blocs (CB) ;
- un identifiant de ladite méthode (GEN_CTRT_SPEC) de génération de contrat ; et
- lesdits paramètres.
9. Programme d'ordinateur (PROGB) comportant des instructions pour l'exécution des étapes du procédé d'acceptation de proposition de contrat selon la revendication 8 lorsque ledit programme est exécuté par un ordinateur (TB).
10. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé d'acceptation d'une proposition de contrat selon la revendication 8.
11. Dispositif de diffusion, dans un réseau de télécommunications, d'une proposition de contrat (SCGA) proposée par une première partie (A), ce dispositif comportant :
- un module (AG_DIFF) de génération d'un contrat intelligent (SCGA)
comportant :
- l'adresse (@A) d'un registre comportant une clé publique (KEYAPUB) de ladite première partie (Alice) dans une chaîne de blocs (CB) ;
- des données (TERMES) représentatives des termes de ladite proposition de contrat ;
- une méthode de souscription (SUBS_SCGA) permettant à au moins une deuxième partie (Bob, Charly) de diffuser une transaction (TR_AB) dans ledit réseau pour souscrire à ladite proposition de contrat ;
- une méthode de génération de contrat (GEN_CTRT_SPEC) configurée pour générer un contrat personnalisé (SCAB) entre ladite première partie (Alice) et une dite deuxième partie (Bob, Charly) et pour demander l'enregistrement dudit contrat personnalisé (SCAB) dans la chaîne de blocs (CB), ledit contrat personnalisé (SCAB) étant généré à partir de paramètres (COND, DATE, SIGN) compris dans ladite transaction (TR_AB) et représentatifs d'une volonté de la deuxième partie (Bob, Charly) d'accepter les termes de la proposition de contrat ;
- un module (AG_DIFF) de signature dudit contrat intelligent (SCGA) avec une clé privée (KEYAPRIV) de ladite première partie (Alice) ; et
- un module (AG_DIFF) de diffusion dudit contrat intelligent (SCGA) signé dans ledit réseau pour demander son enregistrement dans la chaîne de blocs.
12. Dispositif de diffusion selon la revendication 11, caractérisé en ce qu'il comporte :
- un module de communication (COM) apte à télécharger un agent (AG) à partir d'un serveur (SRV_COMP) ;
- un module (11) de traitement apte à installer ledit agent (AG) dans ledit dispositif (TA, TB) ; - ledit agent (AG) comportant ledit module de génération (DIFF), ledit module de signature (DIFF) et ledit module de diffusion (DIFF).
13. Dispositif (DB) d'acceptation d'une proposition de contrat diffusée dans un réseau de télécommunications, ce dispositif étant mis en œuvre dans le terminal (TB) d'un utilisateur (Bob) et comportant :
- un module (27) d'obtention d'un contrat intelligent (SCGA) enregistré dans une chaîne de blocs (CB), ledit contrat intelligent comportant :
- l'adresse (@A), dans ladite chaîne de blocs (CB), d'un registre comportant une clé publique (KEYAPUB) d'une première partie (Alice)
propriétaire de ladite proposition de contrat ;
- des données (TERMES) représentatives de termes de ladite proposition de contrat ;
- une méthode de souscription (SUBS_SCGA) permettant à au moins une deuxième partie (Bob, Charly) de diffuser une transaction (TR_AB) dans ledit réseau pour souscrire à ladite proposition de contrat ;
- une méthode de génération de contrat (GEN_CTRT_SPEC) configurée pour générer un contrat personnalisé (SCAB) entre ladite première partie (Alice) et une dite deuxième partie (Bob, Charly) et pour demander l'enregistrement dudit contrat personnalisé (SCAB) dans la chaîne de blocs (CB), ledit contrat personnalisé (SCAB) étant généré à partir de paramètres (COND, DATE, SIGN) compris dans ladite transaction (TR_AB) et représentatifs d'une volonté de ladite deuxième partie (Bob, Charly) d'accepter les termes de la proposition de contrat ;
- un module (NAV) d'obtention de paramètres (COND, DATE, SIGN)
représentatifs d'une volonté dudit utilisateur (Bob) d'accepter les termes de ladite proposition de contrat ;
- un module (23) d'exécution de ladite méthode de souscription (SUBS_SCGA), ladite exécution déclenchant la diffusion (B80) dans le réseau d'une transaction (TR_AB), signée avec une clé privée (KEYBPRIV) dudit utilisateur (Bob) et comportant :
- l'adresse (@B) d'une clé publique (KEYBPUB) dudit utilisateur (Bob) dans la chaîne de blocs (CB) ; - l'adresse (@SCGA) dudit contrat intelligent (SCGA) dans la chaîne de blocs (CB) ;
- un identifiant de ladite méthode (GEN_CTRT_SPEC) de génération de contrat; et
- lesdits paramètres.
14. Procédé de négociation de contrat entre deux parties (Alice, Bob) dans un réseau de télécommunications, ledit procédé comportant:
- la génération d'une proposition de contrat (SCGA) par ladite première partie (A), sous la forme d'un contrat intelligent (SCGA) comportant :
- l'adresse (@A) d'un registre comportant une clé publique (KEYAPUB) de ladite première partie (Alice) dans une chaîne de blocs (CB) ;
- des données (TERMES) représentatives des termes de ladite proposition de contrat ;
- une méthode de souscription (SUBS_SCGA) permettant à la deuxième partie (Bob, Charly) de diffuser une transaction (TR_AB) dans ledit réseau pour souscrire à ladite proposition de contrat ;
- une méthode de génération de contrat (GEN_CTRT_SPEC) configurée pour générer un contrat personnalisé (SCAB) entre ladite première partie (Alice) et la dite deuxième partie (Bob, Charly) et pour demander l'enregistrement dudit contrat personnalisé (SCAB) dans la chaîne de blocs (CB), ledit contrat
personnalisé (SCAB) étant généré à partir de paramètres (COND, DATE, SIGN) compris dans ladite transaction (TR_AB) et représentatifs d'une volonté de la deuxième partie (Bob, Charly) d'accepter les termes de la proposition de contrat;
- une étape (A50) de signature dudit contrat intelligent (SCGA) avec une clé privée (KEYAPRIV) de ladite première partie (Alice) ;
- une étape (A50) de diffusion dudit contrat intelligent (SCGA) signé dans ledit réseau pour demander son enregistrement dans la chaîne de blocs ;
- une étape (B70) d'obtention dudit contrat intelligent (SCGA) par la deuxième partie (Bob) ;
- une étape d'obtention de paramètres (COND, DATE, SIGN) représentatifs d'une volonté de ladite deuxième partie (Bob) d'accepter les termes de ladite
proposition de contrat ; - une étape (B70) d'exécution de ladite méthode de souscription (SUBS_SCGA) par un terminal (TB) de ladite deuxième partie (Bob), ladite exécution
déclenchant la diffusion (B80) dans le réseau d'une transaction (TR_AB), signée avec une clé privée (KEYBPRIV) de ladite deuxième partie (Bob) et comportant :
- l'adresse (@B) d'une clé publique (KEYBPUB) dudit utilisateur (Bob) dans la chaîne de blocs (CB) ;
- l'adresse (@SCGA) dudit contrat intelligent (SCGA) dans la chaîne de blocs (CB) ;
- un identifiant de ladite méthode (GEN_CTRT_SPEC) de génération de contrat; et
- lesdits paramètres;
- une étape (U90) d'exécution, mise en œuvre par un dispositif (Ui) de minage de la chaîne de blocs, de ladite méthode (GEN_CTRT_SPEC) de génération d'un contrat personnalisé, avec lesdits paramètres, pour générer un contrat personnalisé (SCAB) entre lesdites parties (Alice, Bob), l'enregistrer dans la chaîne de blocs (CB) et rediffuser la chaîne de blocs (CB).
PCT/EP2020/058810 2019-03-28 2020-03-27 Procede de negociation de contrat entre deux parties dans un reseau de telecommunications et dispositifs mettant en oeuvre ce procede Ceased WO2020193773A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US17/598,516 US12051128B2 (en) 2019-03-28 2020-03-27 Method for negotiating a contract between two parties in a telecommunications network and devices implementing said method
EP20713051.9A EP3948627A1 (fr) 2019-03-28 2020-03-27 Procede de negociation de contrat entre deux parties dans un reseau de telecommunications et dispositifs mettant en oeuvre ce procede

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1903298A FR3094519A1 (fr) 2019-03-28 2019-03-28 Procédé de négociation de contrat entre deux parties dans un réseau de télécommunications et dispositifs mettant en œuvre ce procédé
FRFR1903298 2019-03-28

Publications (1)

Publication Number Publication Date
WO2020193773A1 true WO2020193773A1 (fr) 2020-10-01

Family

ID=67514854

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/058810 Ceased WO2020193773A1 (fr) 2019-03-28 2020-03-27 Procede de negociation de contrat entre deux parties dans un reseau de telecommunications et dispositifs mettant en oeuvre ce procede

Country Status (4)

Country Link
US (1) US12051128B2 (fr)
EP (1) EP3948627A1 (fr)
FR (1) FR3094519A1 (fr)
WO (1) WO2020193773A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210065317A1 (en) * 2019-08-30 2021-03-04 EnergyXchain, LLC Managing energy transactions using distributed ledger technology
US12238101B2 (en) * 2021-03-09 2025-02-25 Oracle International Corporation Customizing authentication and handling pre and post authentication in identity cloud service
US12518329B1 (en) * 2021-11-10 2026-01-06 Amdocs Development Limited System, method, and computer program for selectively amending a large customer agreement

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180314809A1 (en) * 2017-04-28 2018-11-01 Accenture Global Solutions Limited Entitlement management system

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10720232B2 (en) * 2016-04-13 2020-07-21 Accenture Global Solutions Limited Distributed healthcare records management
CA3058919A1 (fr) * 2017-04-12 2018-10-18 Royal Bank Of Canada Plateforme d'encheres a l'aide de contrats intelligents et de registre distribue
US20190164157A1 (en) * 2017-11-28 2019-05-30 American Express Travel Related Services Company, Inc. Transaction authorization process using blockchain
US20200118092A1 (en) * 2018-03-13 2020-04-16 Paul Gauvreau Built by Blockchain: A Universal API for Nonnative Cross Chain Smart Contracts
US20190385215A1 (en) * 2018-06-19 2019-12-19 American Express Travel Related Services Company, Inc. Buyer-centric marketplace using blockchain

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180314809A1 (en) * 2017-04-28 2018-11-01 Accenture Global Solutions Limited Entitlement management system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JACKSON NG: "Creating Smart Contracts with Smart Contract", 23 July 2018 (2018-07-23), medium.com, XP055640717, Retrieved from the Internet <URL:https://web.archive.org/web/20180805140054/https://medium.com/coinmonks/creating-smart-contracts-with-smart-contract-d54e21d26e00> [retrieved on 20191108] *

Also Published As

Publication number Publication date
FR3094519A1 (fr) 2020-10-02
US20220180461A1 (en) 2022-06-09
US12051128B2 (en) 2024-07-30
EP3948627A1 (fr) 2022-02-09

Similar Documents

Publication Publication Date Title
EP1909462B1 (fr) Procédé de mise à disposition cloisonnée d&#39;un service électronique
EP3665609B1 (fr) Procédé et serveur de certification d&#39;un document électronique
WO2006021661A2 (fr) Procede d&#39;authentification securisee pour la mise en œuvre de services sur un reseau de transmission de donnees
EP3948627A1 (fr) Procede de negociation de contrat entre deux parties dans un reseau de telecommunications et dispositifs mettant en oeuvre ce procede
EP2294776A1 (fr) Procede et systeme d&#39;acces par un utilisateur a au moins un service offert par au moins un autre utilisateur
EP3812945B1 (fr) Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associé
EP2928124B1 (fr) Procédé de construction d&#39;un message par un terminal
EP4359986B1 (fr) Procédé et dispositif de paiement par chaînes de blocs
EP4099249A1 (fr) Procédé et dispositif de transmission d&#39;un identifiant d&#39;un utilisateur lors d&#39;un paiement électronique réalisépar l utilisateur
EP1637989A1 (fr) Procédé et système de séparation de comptes de données personnelles
WO2003003691A1 (fr) Procede et dispositif de securisation des communications dans un reseau informatique
EP4128700A1 (fr) Procede et dispositif d&#39;authentification d&#39;un utilisateur aupres d&#39;une application
EP4100905B1 (fr) Plateforme de gestion des préférences en matière de données personnelles
FR2812424A1 (fr) Procede et systeme pour effectuer des transactions securisees de biens et de services au moyen d&#39;un telephone mobile via un reseau de communication cellulaire
FR3140184A1 (fr) Procédé et dispositif d’attribution d’un NFT
EP3110109A1 (fr) Procédé et dispositif de mise à jour des capacités d&#39;un objet connecté à un réseau de communications
FR2972882A1 (fr) Procede de transfert et de comptabilisation de tags, et dispositif correspondant
WO2021165612A1 (fr) Procede et dispositif de controle d&#39;acces a une fonction d&#39;une application inscrite dans une chaine de blocs
WO2021234255A1 (fr) Procede et systeme d&#39;authentification d&#39;un utilisateur aupres d&#39;un serveur d&#39;authentification
FR3121764A1 (fr) Méthode de contrôle d’accès à un bien ou service distribué par un réseau de communication de données
WO2007048967A2 (fr) Procede de renouvellement de cles cryptographiques, procede d&#39;obtention d&#39;une cle publique et dispositif de gestion de cles
CA2874207C (fr) Procede de traitement de flux de donnees imap, serveurs de courriels et programmes d&#39;ordinateur mettant en oeuvre de tels procedes
FR2901381A1 (fr) Systeme informatique a gestion universelle et collaborative de fichiers utilisateurs
WO2017089710A1 (fr) Procédé de distribution de droits sur un service et plateforme de service
EP1282090A1 (fr) Procédé et dispositif de sécurisation des transactions

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20713051

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020713051

Country of ref document: EP

Effective date: 20211028