EP4275166A1 - Procede de fourniture de service mis en oeuvre par ordinateur dans une chaine de blocs, noeud d'un reseau de chaine de blocs et programme d'ordinateur correspondants - Google Patents

Procede de fourniture de service mis en oeuvre par ordinateur dans une chaine de blocs, noeud d'un reseau de chaine de blocs et programme d'ordinateur correspondants

Info

Publication number
EP4275166A1
EP4275166A1 EP22702752.1A EP22702752A EP4275166A1 EP 4275166 A1 EP4275166 A1 EP 4275166A1 EP 22702752 A EP22702752 A EP 22702752A EP 4275166 A1 EP4275166 A1 EP 4275166A1
Authority
EP
European Patent Office
Prior art keywords
service
chain
blocks
communication network
computer
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
EP22702752.1A
Other languages
German (de)
English (en)
Inventor
Nassim Laga
Tiphaine HENRY
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 EP4275166A1 publication Critical patent/EP4275166A1/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/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0611—Request for offers or quotes
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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
    • G06Q30/00—Commerce
    • G06Q30/01—Customer relationship services
    • G06Q30/015—Providing customer assistance, e.g. assisting a customer within a business location or via helpdesk
    • G06Q30/016—After-sales
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0631—Recommending goods or services

Definitions

  • TITLE Blockchain computer-implemented service provision method, blockchain network node and corresponding computer program.
  • the field of the invention is that of computer-implemented technologies, and more particularly, the exchange of goods or services based on a decentralized information storage technology of the blockchain type. More specifically, the invention relates to a mechanism, implemented by a smart contract (“smart contract”) of a chain of blocks, for the selection and the decentralized linking of a service provider and a customer.
  • a smart contract implemented by a smart contract (“smart contract”) of a chain of blocks
  • the "blockchain”, or in French chain of blocks, is a technology for storing and transmitting information that is transparent, secure, and operates without a central control body. More precisely, a blockchain is a distributed database, which contains the history of all the exchanges carried out between its users since its creation: the information sent by the users and the internal exchanges in the database are checked and grouped at regular time intervals in blocks, thus forming a chain. Everything is secured by cryptography.
  • transactions made between network users are grouped into blocks. Each block is validated by the nodes of the network, according to cryptographic techniques which depend on the type of blockchain. Once the block is validated, it is timestamped and added to the blockchain, which all users have access to. The transaction is then visible for the receiver, as well as for all the nodes of the network. Once added to the chain, a block can no longer be modified or deleted, which guarantees the authenticity and security of the network.
  • Smart contracts can be defined as autonomous programs that automatically execute the conditions and terms of a contract, without requiring human intervention.
  • a smart contract is a compiled computer program that carries a set of characteristics allowing it to execute automatically and independently at least some of the specific clauses of the contract it carries. The emergence of these smart contracts opens up new applications for blockchains, particularly in the field of the exchange of goods and services.
  • matchmaking platforms are based on an allocation of resources to tasks according to a double auction mechanism, which places the main emphasis on the price during the negotiation phases.
  • connection platforms are all dedicated to specific use cases, and therefore offer little or no modularity.
  • resource selection and sorting algorithms are not optimal, in that the task or resource is almost always assigned to the first bidder.
  • the invention meets these different needs by proposing a method for providing a service implemented by computer in a chain of blocks.
  • a method for providing a service implemented by computer in a chain of blocks comprises steps, implemented by a smart contract of the blockchain, of:
  • the invention is based on an entirely new and inventive approach to linking principals and service providers, based on blockchain technology.
  • the method according to the invention makes it possible, in one embodiment, to link, in a transparent and objective manner, tasks and resources.
  • the selection of candidate service offers can be carried out in an objective and transparent manner, according to a history recorded in a secure and tamper-proof manner in the blockchain, and on the basis of selection criteria established in the service request.
  • implementing a blockchain can help ensure the integrity of quality of service data associated with different service offerings, which can help select a service offering candidate suited to the service request on the basis of reliable and objective quality of service criteria (for example the service offer best suited to the service request).
  • said smart contract can help reduce contracting and payment times, thanks to the autonomous execution of these rules at the execution of the service.
  • said smart contract involves receiving a plurality of service requests.
  • said smart contract implements a reception of a plurality of service requests sent by a plurality of client devices of said communication network.
  • At least one client device issuing said at least one service request and/or at least one provider device of at least one of said service offers recorded in said blockchain interacts with said smart contract via at least one at least one API type request (for "Application Programming Interface” according to English terminology or, in French, application programming interface) using at least one function implemented by said smart contract and belonging to the following group:
  • said functions of said smart contract implement consensus rules.
  • the service offers sent are sorted according to a quality of service score calculated for a candidate service offer, from said at least one quality of service rule on the one hand, and service history, associated with the candidate service offer. It is thus very easy for the customer to make an informed and objective selection of the best service offer, according to his selection criteria.
  • said at least one quality of service rule is a weighted combination of service selection criteria recorded in the block chain.
  • the customer can thus assign greater weights to the criteria which seem to him the most important, and easily identify the offer most likely to meet his expectations.
  • the service request also includes a period of validity of the service request. Thus, when this duration expires, consideration of the service request ceases automatically.
  • the identification of candidate service offers is iterated, according to a relaunch periodicity parameter associated with the service request for example, and until the end of the validity period, as long as no offer service candidate has been identified.
  • the reminder periodicity parameter can advantageously be defined, by the customer or directly within the blockchain, to optimize the relationship between principal and service provider. In such an embodiment, the sender of the service request can thus be assured that a candidate service offer is sought, as long as his need has not been satisfied.
  • a history service may be stored in the blockchain in association with a set of values assigned to service selection criteria for the service.
  • all the conditions of execution of past services can be recorded in a secure and tamper-proof manner in the blockchain, which constitutes an effective assurance, for the issuer of the service request, of the reliability of the evaluation of the candidate service offerings.
  • the quality of service score is calculated by weighted or exponential moving average of the values of the services of the history, according to said at least one quality of service rule.
  • the quality of service score is for example calculated by weighted average of the values of the selection criteria entering into the quality of service rule.
  • the service quality score associated with the selected service offer is for example updated by calculating a weighted or exponential moving average, so as for example to give more importance to the services rendered the more recently, but without however removing the effect of the values of the oldest services.
  • the method according to one embodiment of the invention upon election of one of the candidate service offers sent, implements a step of generating a contract linking the service request and the service offer elected, and a step of registering the contract in the blockchain.
  • These steps can in particular be executed autonomously by the smart contract of the blockchain, which can help to improve their speed of execution, compared to certain techniques of the prior art.
  • the method comprises steps of: - receiving and recording, in the blockchain, values assigned to the service selection criteria for the service provided;
  • the service request also comprises at least one contextual parameter for inciting the supply of the service, and on election of one of the candidate service offers sent, the method implements a step of placing the the incentive to provide the service, in the blockchain.
  • an incentive may consist, for example, of a deposit or a gratuity, which advantageously pushes the service provider to offer the best quality of service possible.
  • the updated service implements a step of paying a provider of the service and, if applicable, of releasing the inducement placed in escrow.
  • these steps can for example be implemented autonomously and automatically by the smart contract of the blockchain, which helps to improve their speed of execution compared to certain techniques of the prior art, and constitutes therefore an interesting incentive guarantee for the service provider.
  • such a method also comprises steps, implemented by a smart contract of the blockchain, of:
  • the invention also relates to a node belonging to a blockchain network, configured to execute a blockchain smart contract.
  • a node belonging to a blockchain network, configured to execute a blockchain smart contract.
  • Such a node includes:
  • At least one computer-readable memory coupled to said at least one processor and in which are recorded program code instructions executable by said at least one processor to implement the service provision method as described previously.
  • the invention also relates to a computer program product comprising program code instructions for implementing a method as described previously, when it is executed by a processor.
  • the invention also relates to a client device of a communication network, which comprises:
  • the transmission module is also configured to transmit values assigned to the service selection criteria for a provided service, intended to be recorded in the chain of blocks.
  • the invention also relates to a provider device of a communication network, which comprises:
  • a module for issuing a service offer comprising at least one service selection criterion and intended to be recorded in a chain of blocks of the communication network;
  • - a module for receiving a contract linking a service request recorded in the block chain and the service offer sent, selected, from service offers recorded in the block chain, according to at least one rule of quality of service contained in the service request on the one hand, and of a history of services, associated with the provider device, and recorded in the chain of blocks, on the other hand.
  • the invention also relates to a recording medium readable by a computer on which is recorded a computer program comprising program code instructions for the execution of the steps of the service provision method according to the invention as described above. - above.
  • Such recording medium can be any entity or device capable of storing the program.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a USB key or a hard disk.
  • such a recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means, so that the program computer it contains is executable remotely.
  • the program according to the invention can in particular be downloaded onto a network, for example the Internet network.
  • the recording medium may be an integrated circuit in which the program is incorporated, the circuit being suitable for executing or for being used in the execution of the aforementioned service provision method.
  • the client device and the provider device, the node and the corresponding computer program mentioned above have at least the same advantages as those conferred by the service provision method according to the present invention.
  • FIG. 1 presents in the form of a block diagram an architecture of the service provision system according to one embodiment of the invention
  • FIG. 2 illustrates in block form a preliminary phase of instantiation of the platform for linking offers and needs according to one embodiment of the invention
  • FIG. 3 describes in the form of a block diagram a phase for recording service offers in the platform for linking offers and needs according to one embodiment of the invention
  • FIG. 4 presents in the form of a block diagram the steps implemented within the platform for linking offers and needs according to one embodiment of the invention, when a client terminal sends a service request;
  • FIG. 5 presents in the form of a block diagram the steps implemented within the platform for linking offers and needs according to one embodiment of the invention, after provision of a service;
  • FIG. 6 proposes a sequential diagram of the various interactions between service provider, principal and platform for linking offers and needs according to one embodiment of the invention.
  • the general principle of the invention is based on the use of a block chain structure, in a communication network, to design a platform for connecting customers and service providers, helping with decentralized, transparent allocation. and/or objective service offers to service requests made by customers.
  • Such a system comprises a blockchain network 100, also called blockchain network 100 hereafter, comprising a plurality of nodes N1 to N5 interconnected to each other.
  • the structure of the NI node is illustrated in more detail.
  • Each node N2 to N5 has an architecture similar to that of the node NI, although this has not been detailed, for the sake of simplification, in Figure 1.
  • the node NI may comprise:
  • Ethereum is a decentralized exchange protocol allowing the creation, by users, of smart contracts thanks to a Turing-complete language;
  • the byte code (in English “bytecode”) of the smart contract SC 11 i.e. the deterministic code executable on the blockchain network 100, whose variables can be stored on the network 100, and whose functions can be called for funds enough.
  • the backend system (or “backend”) of the service provision platform is thus decentralized, and resides in the intelligent contract SC 11 implementing a panel of functions necessary for linking service providers and principals. As will be seen in more detail later, these functions that can be implemented by the smart contract SC 11 are the following:
  • Register() for registering service requests or service offers in the blockchain network 100
  • Filter() for filtering service offers based on service selection criteria listed in a service request
  • Sort() for sorting service offers that meet the criteria stipulated in the service request; generateContract(), for establishing a contract between a service provider and a principal; updateQoSQ, for recording in the blockchain network 100 a quality of service corresponding to a service provided.
  • the users of the platform are for example the service providers 101 and the principals, or customers, 102. They can interact with the platform via their interface, or frontend.
  • API requests allow the interaction between the users 101, 102 on the one hand, and the smart contract SC 11 deployed on the blockchain network 100 on the other hand. somewhere else.
  • the client device of a principal 102 may comprise an RX/TX transmission/reception module 1020, configured to transmit service requests to the platform 100 as well as an evaluation of a service provided, and to receive candidate service offers, selected by the platform 100.
  • Such a client device may include in particular one or several processors, configured to execute program code instructions for sending and receiving such data, in particular conforming to the programming languages HTML (for “HyperText Markup Language”), and JS (for Java Script).
  • the provider device of a service provider 101 comprises an RX/TX send/receive module 1010, configured to send service offers to the platform 100, and to receive contracts, established by the platform 100 when a service offer has been elected to respond to a service request from a client device 102.
  • Such a provider device notably comprises one or more processors, configured to execute program code instructions for the transmission and reception of such data, in particular conforming to the programming languages HTML (for “HyperText Markup Language”), and JS (for Java Script).
  • Consensus rules can help limit malicious nodes, and identify invalidated transactions.
  • Cryptographic rules can help ensure pseudo-anonymity of transactions and users, and authenticity of provider service history 101.
  • node can 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 subroutines or more generally to any element of a program able to implement a function or a set of functions.
  • a node Ni comprises a random access memory (for example a RAM memory), a processing unit equipped for example with a processor, and controlled by a computer program, representative of the code instructions of the smart contract SC 11, stored in a read only memory (for example a ROM memory or a hard disk).
  • a computer program representative of the code instructions of the smart contract SC 11, stored in a read only memory (for example a ROM memory or a hard disk).
  • the code instructions of the computer program are for example loaded into the random access memory before being executed by the processor of the processing unit.
  • Figure 1 illustrates only one particular way, among several possible, of making a node Ni, so that it performs the steps of the method detailed below, in relation to Figures 2 to 6 (in any one of the different modes embodiment, or in a combination of these embodiments). Indeed, these steps can be carried out either on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated calculation machine (for example a set of logic gates like an FPGA or an ASIC, or any other hardware module).
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a program for example a set of logic gates like an FPGA or an ASIC, or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) can be stored in a removable storage medium (such as for example a diskette, a CD-ROM or a DVD-ROM) or not, this storage medium being partially or totally readable by a computer or a processor.
  • a removable storage medium such as for example a diskette, a CD-ROM or a DVD-ROM
  • the linking platform 100 is intended to be generic, in the sense that it does not fit into a particular use case, but can find applications in various fields, such as agriculture, maritime logistics, road transport logistics, personal services, industrial production, energy, etc. As illustrated by FIG. 2, it may therefore be necessary, before the platform 100 becomes fully operational, to provide an instantiation time for the platform 100 to adapt it, for example, to the field of application desired by the user. .
  • the opening of the network 100 can be adjustable at instantiation (from the public block chain to the permitted block chains, and to the private block chains).
  • this user can be a private actor in the case of a private blockchain, or a consortium of actors, in the case of a consortium blockchain.
  • the instantiation of the platform 100 can be carried out by a consortium of transport companies, in the case of a platform dedicated to the transport of goods.
  • FIG. 2 illustrates this instantiation time by a user, referred to as a mother user, which could be noted in English as “Field Authority” FA 20.
  • this mother user FA 20 is the consortium of transport companies, which have previously agreed on the instantiation parameters of the platform 100.
  • the parent user FA 20 can for example specify:
  • This contract body CONT 22 is stored in the smart contract SC 11.
  • the selection criteria P can comprise: the weight of the parcel to be delivered; the volume of the parcel to be delivered; the geographical area in which the package is picked up (for example in the form of GPS coordinates for “Global Positioning System”); the geographical delivery area of the parcel (for example in the form of GPS coordinates for “Global Positioning System”); the type of equipment used for the delivery; the price ; the time that elapses between pick-up and delivery of the package; an identifier of the deliverer (for example his IMSI for "International Mobile Subscriber
  • the platform 100 is operational to record the resources offered by different suppliers of goods or services 101, as illustrated by the synoptic diagram of FIG. 3.
  • the service providers 101 interested and authorized by the parent user FA 20 can offer their services to the platform 100, so that they are referenced in a catalog of services recorded in the blockchain.
  • This recording of service offers in the blockchain constitutes strong security for potential customers 102, because it guarantees them that service providers 101 cannot modify the parameters of the service offer they offer (price, deadline, quantity, type of equipment, etc.) after contractualisation.
  • the service provider 101-1 sends to the linking platform 100 a description of its service offer, according to the set P of the various selection criteria CSEL 23 defined during the platform instantiation phase; similarly, during a step Add_NR 32, the service provider 101-2 sends the connection platform 100 a description of its service offer, according to the set P of selection criteria.
  • the service provider 101-1 can, during the step Add_NR 31, describe a service offer that complies with the following selection criteria P: the weight of the package to be delivered: less than or equal to 150 kg; the volume of the package to be delivered: less than or equal to 2 m 3 ; the geographical area in which the package is picked up: an area with a radius of 30 km around a city A; the geographic area of delivery of the package: an area of 200km radius around town A; the type of equipment used for the delivery: a hybrid or 100% electric truck equipped for the transport of fresh products, identified by its model and its manufacturer reference; the price, expressed for example in € per kilometer; the time that elapses between the pick-up and the delivery of the package, for example a guarantee of delivery in 48 hours; an identifier of the deliverer (for example his IMSI for “International Mobile Subscriber Identity”); the deliverer's certifications (eg transport of fresh products / chemical products / international delivery authorization etc.).
  • P the weight of the package to be delivered: less than or equal to
  • the intelligent contract SC 11 can save the offers received from the service providers 101-1 and 102-2 in the chain of blocks 100, during an Update_RC step 33.
  • the catalog of resources saved in the chain of blocks can specify, for at least some of them (for example each), the selection criteria values P specified in the offers transmitted by the service providers 101.
  • a service provider 101 may have a pseudo-identity on blockchain 100, which is associated with a history of services previously provided by it.
  • the updating of the catalog of resources and service offers illustrated by FIG. 3 can be done continuously, throughout the duration of operation of the linking platform 100: from new service providers can offer their resources; similarly, service providers already registered on the platform 100 can update their service offers, and in particular the values assigned to the various selection criteria P (for example updating the price, the guaranteed time, or the type of 'equipment).
  • a client (or instructing party) 102 wishes to make a service request, he can send a service request 40 to the platform 100, as illustrated by FIG. 4.
  • This service request 40 which can be denoted Req[S,, T, dT, R, I], can include selection criteria [S,, T, dT], where:
  • - dT is the frequency of relaunch in the event of absence of allocation of a service provider to the execution of the service request 40.
  • the reminder frequency dT can be defined by the mother user during the instantiation of the platform.
  • the latter may only be interested, in the formulation of his request, in a subset S i , namely: the weight of the package to be delivered: 40 kg; the volume of the package to be delivered: 1 m 3 ; the geographical area where the parcel is picked up: city A; the geographical delivery area of the package: city B; the price, which must be less than €100; the type of truck, which must be electric; the certifications of the deliverer, who must be authorized for the transport of fresh products.
  • the duration of the delivery, and the identifier of the deliverer may be secondary for the customer 102, who may therefore not specify the value of some of these selection criteria CSEL 23 in his service request 40.
  • the originator 102 can specify, in the service request 40, minimum quality of service rules, or QoS, desired, denoted R.
  • N be the number of selection criteria CSEL defining the set P of selection criteria instantiated on the platform 100.
  • a QoS rule R can for example be a Boolean combination of the selection criteria of P where V j e
  • a QoS rule R in which a weight of 1 will be assigned to the selection criteria of P corresponding to delivery time and price, and a zero weight will be assigned to the other selection criteria of set P.
  • the values of the deliverer metrics can both be normalized between 0 and 1.
  • the QoS score of the delivery person for the rule R will be:
  • the service request 40 can also contain optional incentives I, offered by the originator 102 to encourage the service provider who will be selected to provide the best quality of service possible.
  • incentives optional I can take the form, for example, of a gratuity from the service provider in the event of customer satisfaction (for example if the service is rendered in advance), of a call for an audit service in the event of a dispute , or a deposit requested for the payment of the service.
  • An example of an optional incentive is a deposit from the service provider when picking up the service (for example, a deposit of 0.3 times the value of the goods picked up in the truck). It can be placed in sequestration, for example, until the execution of the requested service.
  • the deposit can be returned in full to the service provider. Otherwise, in the event that the service provider disappears with the goods, these can be paid automatically to the principal. Such an incentive therefore encourages favorable performance of the service.
  • the intelligent contract SC 11 can carry out a filtering 41 of the resources available in the catalog of resources updated during the referenced step 33, on the basis in particular of the criteria of selection S, specified in request 40.
  • the intelligent contract SC 11 can reiterate the filtering 41 after a time interval dT, corresponding for example to the frequency of the relaunch in the event of failure of the resource allocation at the client 102.
  • this iteration of filtering 41 can be repeated a number M of times (M strictly positive integer) or as long as the lifetime T of the service request has not expired.
  • dT can be set to zero, either in the service request 40, or during the instantiation of the platform. In this case, the filtering is not repeated, and if no candidate service offer is identified during the step referenced 42, the service request is canceled, and the principal 102 is notified by the platform. 100.
  • the smart contract SC 11 identifies several service offers satisfying the selection criteria S, specified in the service request 40 , he can proceed, during a step referenced 43, to a multi-objective sorting (SORTQ) to obtain a profile (for example to obtain the best profile) among all the service offers identified.
  • SORTQ multi-objective sorting
  • This sorting 43 can be based for example on at least some of the QoS R rules set by the principal 102. For example, for each of the candidate offers identified during the referenced step 42, the values of the selection criteria entering in the calculation of QoS R rules can be extracted from the log of events recorded in the chain of blocks 100 for the service provider 101 having issued the candidate service offer. The calculation of the QoS score assigned to candidate service offers is done for example by calculating a weighted average, based on the selection criteria entering into the QoS rule R. For example, if ten services have already been provided by the service provider 101 and recorded in a service history of this provider in the block chain 100, they can all be taken into account for the calculation of the QoS score assigned to it.
  • the sorting 43 of the QoS scores of the candidate offers can be obtained for example with the following formula:
  • the QoS parameters are first normalized for each of the candidate offers, for example for each of the deliverers (Normj(Qij)).
  • Sorting 43 in descending order therefore gives [QoS3, QoSl, QoS2, QoS4]
  • a quality of service score (for example QoS3 for the delivery person 3) is calculated as a function of the values which have been assigned to the various selection criteria P, for example on the occasion of services previously rendered by the service providers, and whose evaluation has been recorded in the chain of blocks 100.
  • the service offers can be sorted on the basis of this quality of service score.
  • the candidate service offers thus sorted (Deliveryman 3>Deliveryman 1>Deliveryman 2>Deliveryman 4) can be sent by the platform 100 to the principal 102, who can then make a choice, and elect the service offer he wishes to retain.
  • the election of the service offer is autonomous, and can be carried out directly by the platform 100, which retains for example the offer presenting the best quality of service score (in the previous example , the delivery man 3).
  • the smart contract 11 can generate, during a GEN_CONT step 44, a contract C, linking the elected service offer to the principal 102
  • This contract C can be generated for example from the contract model CONT which was chosen during the step referenced 22 of FIG. 2, during the instantiation phase of the platform.
  • This contract G is recorded in the blockchain 100.
  • the service request 40 included one or more optional incentives, they can be placed in escrow during a step referenced 45.
  • the service requested can be provided by the service provider 101.
  • the principal 102 can for example call the feedback function (in French, return, reaction or comment) FB of the smart contract SC 11, during a step referenced 50, as illustrated by Figure 5.
  • the principal 102 thus transmits to the platform 100 a certain number of parameters relating to the execution of the service rendered, corresponding to values assigned to the service selection criteria P: effective duration of the delivery, customer satisfaction score , integrity of the goods delivered, etc.
  • the principal 102 can indicate whether the packaging was damaged, and, if necessary, provide photos attesting to their condition on delivery.
  • the data transmitted by the ordering party 102 can be normalized before recording in the block chain 100.
  • this feedback of information can be carried out by a certain number of connected objects (loT) associated with the ordering party 102 or to the service provider 101, which can provide the platform 100 with information on the service performed, such as the execution time for example.
  • LoT connected objects
  • Such connected objects can be, for example, a door opening detector, a temperature sensor, a humidity sensor, or even a weight sensor, which make it possible to provide information on the integrity and quality of the goods delivered (for example on the respect of the cold chain for the transport of fresh products).
  • the sensors of temperature and humidity can, for example, transmit to the platform 100 temperature and humidity diagrams corresponding to the information that they have noted during the delivery period.
  • Such connected objects can still correspond to RFI D or 5G type labels allowing identification of batches of goods.
  • the function FB of the intelligent contract SC 11 can then operate two updates in the chain of blocks 100: an update 51 of the status of the requested service STAT; and/or an update 52 of the quality of service QoS associated with the service rendered by the service provider, for example by calculating an exponential moving average.
  • the status of the STAT task corresponds to its execution in compliance with the rules specified in the smart contract SC 11 (positive status - e.g. delivery on time, with the right goods, and with a set of environmental and respected) or its non-respect (negative status - e.g. in the case of a threshold temperature exceeded for example).
  • the evaluation of the STAT status is therefore dependent on the execution of the terms of the contract.
  • the intelligent contract SC 11 can implement different actions.
  • the smart contract SC 11 can for example proceed, during a PAY step 54, to release the funds associated with the execution of the contract: the service provider 101 receives payment for the service performed, and possibly the optional gratuity I provided for in the service request 40, if these conditions for obtaining are met.
  • the smart contract SC 11 can for example send, during a step REF referenced 55, the deposit from the service provider 101 to the ordering party 102, as compensation for non-performance of the contract.
  • the progress of the service is traced, immutably, on the chain of blocks 100.
  • the information contained in these traces may be used, on the occasion of a future service request, in the provider selection mechanism described previously in relationship with Figure 4.
  • FIG. 6 illustrates, in the form of a sequential diagram, an end-to-end connection between an originator 102 and a service provider 101, in an embodiment of the platform 100.
  • dT 0
  • Figure 6 illustrates the different sequences of interaction between the service provider 101, the originator 102, and the smart contract SC 11.
  • the service provider 101 registers its service offer with the platform 100, by specifying the values that it has fixed for the various selection criteria P instantiated on the platform.
  • the intelligent contract SC 11 saves them in the chain of blocks 100, and thus updates the catalog of resources associated with the platform 100. It sends, during a step referenced 63, a acknowledgment of receipt to the service provider 101, to confirm to him the registration of his service offer.
  • a principal 102 sends a service request 40 to the platform 100, specifying selection criteria, and quality of service rules, as previously described in relation to FIG.
  • the intelligent contract SC 11 sorts, during a step referenced 65, all the service offers recorded on the platform to identify the candidate offer(s), which satisfy the selection criteria specified by the client 102. For each, it calculates a quality of service score, taking into account for example the history of the services recorded for each service provider in the chain of blocks 100. It thus sorts the candidate offers according to their QoS score, and sending this sorted list of candidate offers to the principal 102, during a step referenced 66.
  • the principal 102 elects one of these offers, during the step referenced 67, and informs the intelligent contract SC 11 thereof. As indicated above, as a variant, the election can be carried out automatically, directly by the smart contract SC 11, without the intervention of the client 102.
  • the intelligent contract SC 11 then generates, during a step referenced 68, the contract framing the provision of the requested service, and informs 69 the service provider that it has been selected to respond to the request of the customer 102.
  • the provider of service confirms to the smart contract SC11 that it agrees to render the service for which its offer has been elected, during a step referenced 70.
  • the smart contract SC 11 Upon receipt of this agreement, the smart contract SC 11 initializes 71 the process of supplying the service, and sends acknowledgments 72 and 73 to the principal 102 and to the service provider 101.
  • the service provider 101 executes the service for which it has been chosen. It notifies (75) the client 102 of this. The latter can then send its feedback 76 to the smart contract SC 11, giving for example an indication relating to its satisfaction (appreciation, satisfaction rating, etc.) on the service rendered, and by specifying for example the assigned values for this service to the different selection criteria P.
  • the return 76 sent by the customer 102 can also consist of a classification carried out by an artificial intelligence (AI) brick.
  • AI artificial intelligence
  • the intelligent contract SC 11 then updates, during a step referenced 77, the status of the service, and the quality of service QoS of the service provider 101. Depending on the status of the service, as explained above in relation to FIG. 5, he releases funds (step 79) to pay the service provider 101, if the status of the service is positive, or he transmits (step 78) to the customer 102 the guarantee of the service provider 101, if the status of the service is negative.
  • the principal 102 is looking for a deliverer 101 available for a given period T, whose truck is equipped for the transport of fresh products.
  • the order is critical, he wants to recruit a reliable 101 delivery person, who has had a minimum of delays during the past year.
  • the deposit required from the carrier can be specified, as well as a tip if the delivery is ahead of schedule.
  • the principal 102 can therefore post a delivery request 40 with this set of criteria, weighted as desired.
  • S would be [M the price, W the minimum available weight, V the minimum volume, E the equipment, city A, city B], R would be [minimum delay, minimum distance, minimum carbon footprint] .
  • the optional incentives would be [D the deposit, t the tip].
  • the sorting algorithm applies the selection criteria [Si, T] to the registered resource base. If no resource corresponds to the requested profile, a callback is performed after a period dT. These parameters are sent to the filtering function of the intelligent contract SC 11. The filtering becomes positive when at least one resource, here a carrier, fulfills the filtering criteria.
  • the request is put on hold and reinstantiated until the date T at each period dT specified by the originator 102.
  • the originator 102 has the possibility of canceling the process connection at all times.
  • the choice of the resource can be autonomous.
  • the resource with the best QoS score will be assigned to the request.
  • the assignment is performed randomly.
  • a standard e-CMR contract (legal document for the transport of goods by road) is generated on the blockchain 100.
  • the deposit and the gratuity can also be placed in escrow.
  • the principal 102 gives feedback on the delivery.
  • the status of the task is updated, the QoS score (here the reputation) of the deliverer 101 is updated. If the delivery has been made without incident, the deposit, and all or part of the gratuity are sent to the deliverer.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé de fourniture de service mis en œuvre par ordinateur dans une chaîne de blocs. Selon l'invention, un tel procédé comprend des étapes, mises en œuvre par un contrat intelligent (11) de la chaîne de blocs, de : ‐ réception (64) d'une requête de service, la requête comprenant au moins un critère de sélection de service et au moins une règle de qualité de service; ‐ identification (65) d'au moins une offre de service satisfaisant ledit au moins un critère de sélection de service, dite offre de service candidate, parmi des offres de service enregistrées dans la chaîne de blocs; ‐ envoi (66) d'au moins une des offres de service candidates, ladite au moins une offre de service envoyée étant sélectionnée en fonction de ladite au moins une règle de qualité de service d'une part, et d'un historique de services, associés auxdites offres de service candidates, et enregistrés dans ladite chaîne de blocs, d'autre part.

Description

DESCRIPTION
TITRE : 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.
Domaine technique
Le domaine de l’invention est celui des technologies mises en œuvre par ordinateur, et plus particulièrement, de l'échange de biens ou de services reposant sur une technologie de stockage décentralisé d'informations de type chaîne de blocs. Plus précisément, l’invention concerne un mécanisme, mis en œuvre par un contrat intelligent (en anglais « smart contract ») d'une chaîne de blocs, pour la sélection et la mise en relation décentralisée d'un fournisseur de service et d'un client.
Art antérieur
La « blockchain », ou en français chaîne de blocs, est une technologie de stockage et de transmission d'informations transparente, sécurisée, et fonctionnant sans organe central de contrôle. Plus précisément, une chaîne de blocs est une base de données distribuée, qui contient l'historique de tous les échanges effectués entre ses utilisateurs depuis sa création : les informations envoyées par les utilisateurs et les échanges internes à la base de données sont vérifiés et groupés à intervalles de temps réguliers en blocs, formant ainsi une chaîne. L'ensemble est sécurisé par cryptographie.
Plus précisément, les transactions effectuées entre les utilisateurs du réseau sont regroupées par blocs. Chaque bloc est validé par les nœuds du réseau, selon des techniques cryptographiques qui dépendent du type de blockchain. Une fois le bloc validé, il est horodaté et ajouté à la chaîne de blocs, à laquelle tous les utilisateurs ont accès. La transaction est alors visible pour le récepteur, ainsi que pour l'ensemble des nœuds du réseau. Une fois ajouté à la chaîne, un bloc ne peut plus être ni modifié ni supprimé, ce qui garantit l'authenticité et la sécurité du réseau.
Il existe des chaînes de blocs publiques, ouvertes à tous, et des chaînes de blocs privées, ou de consortium, dont l'accès et l'utilisation sont limitées à un certain nombre d'acteurs définis à l'avance.
Les premières chaînes de blocs ont trouvé des applications dans le domaine de la monnaie numérique, telle que le bitcoin, qui est un exemple de monnaie programmable. Cependant, le caractère décentralisé de la chaîne de blocs, couplé avec sa sécurité et sa transparence, laisse entrevoir des applications bien plus larges que le seul domaine monétaire.
Les infrastructures de chaînes de blocs se sont ainsi récemment enrichies de contrats intelligents, ou « smart contracts », que l'on peut définir comme des programmes autonomes qui exécutent automatiquement les conditions et termes d'un contrat, sans nécessiter d'intervention humaine. En d'autres termes, un contrat intelligent est un programme informatique compilé qui porte un ensemble de caractéristiques lui permettant d'exécuter automatiquement et en autonomie au moins certaines des clauses spécifiques du contrat qu'il porte. L'émergence de ces contrats intelligents ouvre de nouvelles applications aux chaînes de blocs, notamment dans le domaine de l'échange de biens et de services.
En effet, le recours aux places de marché (i.e. aux plateformes de mise en relation entre un fournisseur de service et un demandeur de service) pour la sous-traitance de tâches rencontre à ce jour un certain nombre de problématiques techniques, auxquelles l'infrastructure de chaîne de blocs, couplée à l'utilisation de contrats intelligents, pourrait apporter des solutions efficaces : une numérisation hésitante : le panel d'utilisateurs de la plateforme peut être large et diversifié, ce qui implique souvent que la plateforme de mise en relation soit de préférence simple d'usage et accessible. Elle doit de plus permettre aux acteurs de s'assurer que standards et réglementation en vigueur soient respectés, pour la génération électronique de contrats par exemple. Elle doit par ailleurs prendre en compte l'hétérogénéité des systèmes d'information des systèmes en présence ; une problématique de manque de transparence dans la gestion des données : à ce jour, la mise en relation est le plus souvent effectuée par des plateformes tierces, centralisées. Ces dernières sont souvent enclines à un manque de transparence vis à vis du stockage des informations des acteurs. Elles peuvent également revendre à leur compte les informations extraites de l'agrégation de traces d'évènements. Cette asymétrie des relations peut ainsi favoriser certains monopoles, au détriment d'une gouvernance transparente ; des procédures longues et fastidieuses : le poids des procédures est souvent pointé du doigt. Certaines étapes peuvent être redondantes, peu appropriées, induisent une redondance d'information. Ce poids des procédures génère une lassitude et un coût en ressources monétaires et temporelles. Par ailleurs, les étapes de publication d'offre, de mise en relation, de contractualisation, et de mise en paye induisent un interfaçage en pointillé de chaque étape. Des délais d'exécution en découlent donc ; des processus peu flexibles : le traitement unitaire des tâches, la difficulté d'accès aux données des tâches en cours d'exécution, une qualité de traçage des connexions (en anglais « log ») variable, et l'aspect fastidieux de la génération des tâches, limitent l'optimisation des ressources, pour un re-routage par exemple. Dans ce contexte, une affectation flexible des tâches est donc difficilement envisageable.
Pour répondre à ces différentes problématiques, il a été envisagé, dans certains domaines particuliers tels que la gestion de l'énergie ou l'allocation de ressources informatiques, de concevoir des plateformes de mise en relation utilisant une infrastructure de chaîne de blocs. Ainsi, dans le domaine de la délégation de tâches de calcul, Wang et al. proposent, dans l'article « Permissioned blockchain for efficient and secure resource sharing in vehicular edge computing » (arXiv preprint arXiv:1906.06319), d'utiliser une technique de chaîne de blocs et de contrats intelligents pour un partage efficace et sécurisé de ressources dans le domaine de l'informatique en périphérie appliquée aux véhicules (en anglais « Vehicular Edge Computing »).
Yan et al., dans l'article "Nebula: A blockchain based decentralized sharing computing platform" (In: International Conférence on Blockchain and Trustworthy Systems, pp. 715-731. Springer (2019)), proposent quant à eux une plateforme décentralisée reposant sur une technologie de chaîne de blocs pour le partage de ressources informatiques.
Dans ces deux cas, l'affectation des tâches de calcul aux ressources disponibles se fait selon un algorithme de meilleure répartition. Notamment, Yan et al. proposent d'utiliser l'algorithme hongrois pour résoudre ce problème d'affectation.
Dans le domaine du partage d'énergie (en anglais « smart grids »), on peut citer les travaux de : Troncia et al. (2019), "Distributed ledger technologies for peer-to-peer local markets in distribution networks", Energies, 12(17), 3249 ;
Li, et al. (2017), "Consortium blockchain for secure energy trading in industrial internet of things", IEEE transactions on industrial informatics, 14(8), 3690-3700 ;
Myung, et al. "Ethereum smart contract-based automated power trading algorithm in a microgrid environment", The Journal of Supercomputing76(7), 4904-4914 (2020).
Ces plateformes de mise en relation reposent sur une affectation des ressources aux tâches selon un mécanisme de double enchère, qui met l'accent principal sur le prix lors des phases de négociation.
Si ces différentes solutions de l'art antérieur sont intéressantes en ce qu'elles montrent l'intérêt de l'utilisation des chaînes de blocs et de contrats intelligents dans un contexte de mise en relation de fournisseurs de services et de clients, elles ne permettent pas de répondre à l'ensemble des problématiques mentionnées ci-avant.
Notamment, ces plateformes de mise en relation sont toutes dédiées à des cas d'usage précis, et n'offrent donc pas ou peu de modularité. En outre, les algorithmes de sélection et de tri des ressources ne sont pas optimaux, en ce sens que la tâche ou la ressource est presque toujours affectée au premier offrant.
Il existe donc un besoin d’une technique de mise en relation de fournisseurs de services et de clients, ou de tâches et de ressources, qui ne présente pas l'ensemble des différents inconvénients de l'art antérieur, et qui vise à répondre à aux moins certaines de ces différentes problématiques. Notamment, il existe un besoin d'une telle technique qui aide par exemple à une mise en relation décentralisée, transparente et/ou objective d'une ressource à un besoin donné. Il existe également un besoin d'une telle technique qui aide par exemple à réduire les délais de contractualisation et de paiement par rapport aux plateformes de mise en relation de l'art antérieur. Il existe encore un besoin d'une telle technique qui s'appuie avantageusement sur une infrastructure de chaîne de blocs et de contrats intelligents. Il existe enfin un besoin d'une telle technique qui aide à améliorer la finesse de sélection et de tri des différentes offres de service à des fins de mise en relation optimisée des clients et des fournisseurs.
Exposé de l'invention
L'invention répond à ces différents besoins en proposant un procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs. Selon l'invention, un tel procédé comprend des étapes, mises en oeuvre par un contrat intelligent de la chaîne de blocs, de :
- réception d'une requête de service, la requête comprenant au moins un critère de sélection de service et au moins une règle de qualité de service ;
- identification d'au moins une offre de service satisfaisant ledit au moins un critère de sélection de service, dite offre de service candidate, parmi des offres de service enregistrées dans la chaîne de blocs ;
- envoi d'au moins une des offres de service candidates, ladite au moins une offre de service envoyée étant sélectionnée en fonction de ladite au moins une règle de qualité de service d'une part, et d'un historique de services, associés aux offres de service candidates, et enregistrés dans la chaîne de blocs, d'autre part.
Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la mise en relation de donneurs d'ordre et de fournisseurs de service, reposant sur une technologie de chaîne de blocs. En effet, le procédé selon l'invention permet, dans un mode de réalisation, de mettre en relation, de manière transparente et objective, tâches et ressources. Contrairement aux techniques de l'art antérieur, la sélection d'offres de service candidates peut s'effectuer de façon objective et transparente, en fonction d'un historique enregistré de manière sécurisée et infalsifiable dans la chaîne de blocs, et sur la base de critères de sélection établis dans la requête de service. Dans au moins certains modes de réalisation, la mise en oeuvre d'une chaîne de blocs peut aider à garantir l'intégrité des données relatives à la qualité de service associée aux différentes offres de service, ce qui peut aider à sélectionner une offre de service candidate adaptée à la requête de service sur la base de critères de qualité de service fiables et objectifs (par exemple l'offre de service la plus adaptée à la requête de service).
De plus, l'utilisation de la technologie de contrat intelligent de la chaîne de blocs peut aider à réduire les délais de contractualisation et de mise en paiement, grâce à l'exécution autonome de ces règles à l'exécution du service. Dans certains modes de réalisation, ledit contrat intelligent met en oeuvre une réception d'une pluralité de requêtes de services.
Dans certains modes de réalisation, ledit contrat intelligent met en oeuvre une réception d'une pluralité de requêtes de services émises par une pluralité de dispositifs clients dudit réseau de communication.
Dans certains modes de réalisation, au moins un dispositif client émetteur de ladite au moins une requête de service et/ou au moins un dispositif fournisseur d'au moins une desdites offres de service enregistrées dans ladite chaîne de blocs interagit avec ledit contrat intelligent via au moins une requête de type API (pour « Application Programming Interface » selon la terminologie anglaise ou, en français, interface de programmation d'application) utilisant au moins une fonction implémentée par ledit contrat intelligent et appartenant au groupe suivant :
- une fonction d'enregistrement d'au moins une requête de services et/ou d'au moins une offre de service dans ladite chaîne de blocs;
- une fonction de filtrage d'offres de service enregistrées en fonction d'au moins un critère de sélection de service compris dans au moins une requête de service ;
- une fonction de tri d'offres de service répondant au au moins un critère de sélection compris dans au moins une requête de service ;
- une fonction d'établissement d'un contrat entre un dispositif fournisseur d'au moins une desdites offres de service et un dispositif éclient émetteur d'au moins une desdites requêtes de service;
- une fonction d'enregistrement dans ladite chaîne de blocs d'une qualité de service correspondant à un service fourni.
Dans certains modes de réalisation, lesdites fonctions dudit contrat intelligent mettent en oeuvre des règles de consensus.
Selon un premier aspect, les offres de service envoyées sont triées en fonction d'un score de qualité de service calculé pour une offre de service candidate, à partir de ladite au moins une règle de qualité de service d'une part, et de l'historique de services, associés à l'offre de service candidate. Il est ainsi très facile pour le client d'opérer une sélection avisée et objective de la meilleure offre de service, selon ses critères de choix.
En effet, selon un autre aspect, ladite au moins une règle de qualité de service est une combinaison pondérée de critères de sélection de service enregistrés dans la chaîne de blocs. Le client peut ainsi affecter des poids plus importants aux critères qui lui semblent les plus importants, et identifier facilement l'offre la plus susceptible de répondre à ses attentes. Selon encore un autre aspect, la requête de service comprend également une durée de validité de la requête de service. Ainsi, à expiration de cette durée, la prise en compte de la requête de service cesse automatiquement.
Selon un aspect complémentaire, l'identification d'offres de service candidates est itérée, selon un paramètre de périodicité de relance associé à la requête de service par exemple, et jusqu'à la fin de la durée de validité, tant qu'aucune offre de service candidate n'a été identifiée. Le paramètre de périodicité de relance peut avantageusement être défini, par le client ou directement au sein de la chaîne de blocs, pour optimiser la mise en relation entre donneur d'ordre et fournisseur de service. Dans un tel mode de réalisation, l'émetteur de la requête de service peut ainsi être assuré qu'une offre de service candidate soit recherchée, tant que son besoin n'a pas été satisfait.
Selon un mode de réalisation, un service de l'historique peut être enregistré dans la chaîne de blocs en association avec un ensemble de valeurs affectées aux critères de sélection de service pour le service. Ainsi, toutes les conditions d'exécution de services passés peuvent être enregistrées de façon sécurisée et infalsifiable dans la chaîne de blocs, ce qui constitue une assurance efficace, pour l'émetteur de la requête de service, de la fiabilité de l'évaluation des offres de service candidates.
Selon un mode de réalisation, le score de qualité de service est calculé par moyenne mobile pondérée ou exponentielle des valeurs des services de l'historique, en fonction de ladite au moins une règle de qualité de service.
Notamment, lors de l'évaluation des offres de service candidates, le score de qualité de service est par exemple calculé par moyenne pondérée des valeurs des critères de sélection entrant dans la règle de qualité de service. Après exécution du service, le score de qualité de service associé à l'offre de service sélectionnée est par exemple mis à jour par calcul d'une moyenne mobile pondérée ou exponentielle, de façon par exemple à donner plus d'importance aux services rendus les plus récemment, mais sans supprimer cependant l'effet des valeurs des services les plus anciens.
Selon une autre caractéristique, sur élection d'une des offres de service candidates envoyées, le procédé selon un mode de réalisation de l'invention met en oeuvre une étape de génération d'un contrat liant la requête de service et l'offre de service élue, et une étape d'enregistrement du contrat dans la chaîne de blocs. Ces étapes peuvent notamment être exécutées en autonomie par le contrat intelligent de la chaîne de blocs, ce qui peut aider à améliorer leur rapidité d'exécution, par rapport à certaines techniques de l'art antérieur.
Selon encore un autre aspect, après fourniture du service requis, le procédé comprend des étapes de : - réception et enregistrement, dans la chaîne de blocs, de valeurs affectées aux critères de sélection de service pour le service fourni ;
- mise à jour, dans la chaîne de blocs, d'un statut du service requis.
Ainsi, à chaque nouveau service fourni, ses conditions d'exécution sont enregistrées de façon infalsifiable dans la chaîne de blocs, ce qui permet une mémorisation intègre de la qualité de service associée à chaque offre de service, et constitue donc une assurance, pour un émetteur de requête de service, que la sélection d'une offre de service candidate est fondée sur des critères objectifs, en fonction notamment d'un historique effectif de service.
Selon un autre aspect, la requête de service comprend également au moins un paramètre contextuel d'incitation à la fourniture du service, et sur élection d'une des offres de service candidates envoyées, le procédé met en oeuvre une étape de mise sous séquestre de l'incitation à la fourniture du service, dans la chaîne de blocs. Une telle incitation peut consister par exemple en une caution ou une gratification, qui pousse avantageusement le fournisseur de service à offrir la meilleure qualité de service possible.
Selon encore un autre aspect, en fonction du statut du service mis à jour, il met en oeuvre une étape de paiement d'un fournisseur du service et, le cas échéant, de libération de l'incitation mise sous séquestre. A nouveau, ces étapes peuvent être par exemple mises en oeuvre de façon autonome et automatique par le contrat intelligent de la chaîne de blocs, ce qui aide à améliorer leur rapidité d'exécution par rapport à certaines techniques de l'art antérieur, et constitue donc une garantie incitative intéressante pour le fournisseur de service.
Selon encore une autre caractéristique, un tel procédé comprend également des étapes, mises en oeuvre par un contrat intelligent de la chaîne de blocs, de :
- réception d'une offre de service ;
- enregistrement de l'offre de service dans la chaîne de blocs.
Ainsi, l'émetteur d'une requête de service est assuré que les conditions associées à une offre de service ne puissent être modifiées après que l'offre ait été formulée, ce qui constitue une garantie supplémentaire.
L'invention concerne également un nœud appartenant à un réseau de chaîne de blocs, configuré pour exécuter un contrat intelligent de la chaîne de blocs. Un tel nœud comprend :
- au moins un processeur ; et
- au moins une mémoire lisible par ordinateur couplée audit au moins un processeur et dans laquelle sont enregistrées des instructions de code de programme exécutables par ledit au moins un processeur pour mettre en œuvre le procédé de fourniture de service tel que décrit précédemment. L'invention concerne encore un produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé tel que décrit précédemment, lorsqu'il est exécuté par un processeur.
L'invention concerne encore un dispositif client d'un réseau de communication, qui comprend :
- un module d'émission d'une requête de service, la requête comprenant au moins un critère de sélection de service et au moins une règle de qualité de service ;
- un module de réception d'au moins une offre de service candidate, satisfaisant ledit au moins un critère de sélection de service, et sélectionnée, parmi des offres de service enregistrées dans une chaîne de blocs du réseau de communication, en fonction de ladite au moins une règle de qualité de service d'une part, et d'un historique de services, associés aux offres de service candidates, et enregistrés dans la chaîne de blocs, d'autre part.
Selon un aspect d'un tel dispositif client, le module d'émission est également configuré pour émettre des valeurs affectées aux critères de sélection de service pour un service fourni, destinées à être enregistrées dans la chaîne de blocs.
L'invention vise encore un dispositif fournisseur d'un réseau de communication, qui comprend :
- un module d'émission d'une offre de service comprenant au moins un critère de sélection de service et destinée à être enregistrée dans une chaîne de blocs du réseau de communication ;
- un module de réception d'un contrat liant une requête de service enregistrée dans la chaîne de blocs et l'offre de service émise, sélectionnée, parmi des offres de service enregistrées dans la chaîne de blocs, en fonction d'au moins une règle de qualité de service contenue dans la requête de service d'une part, et d'un historique de services, associés au dispositif fournisseur, et enregistrés dans la chaîne de blocs, d'autre part.
L'invention vise également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de fourniture de service selon l'invention tel que décrit ci- dessus.
Un tel support 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 une clé USB ou un disque dur.
D’autre part, un tel support 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, de sorte que le programme d'ordinateur qu'il contient est exécutable à distance. Le programme selon l’invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet. Alternativement, le support 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é de fourniture de service précité.
Le dispositif client et le dispositif fournisseur, le nœud et le programme d'ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé de fourniture de service selon la présente invention.
Présentation des figures
D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
La figure 1 présente sous forme de schéma synoptique une architecture du système de fourniture de service selon un mode de réalisation de l'invention ;
La figure 2 illustre sous forme synoptique une phase préliminaire d'instanciation de la plateforme de mise en relation d'offres et de besoins selon un mode de réalisation de l'invention ;
La figure 3 décrit sous forme de schéma synoptique une phase d'enregistrement d'offres de service dans la plateforme de mise en relation d'offres et de besoins selon un mode de réalisation de l'invention ;
La figure 4 présente sous forme de schéma synoptique les étapes mises en œuvre au sein de la plateforme de mise en relation d'offres et de besoins selon un mode de réalisation de l'invention, lorsqu'un terminal client émet une requête de service ;
La figure 5 présente sous forme de schéma synoptique les étapes mises en œuvre au sein de la plateforme de mise en relation d'offres et de besoins selon un mode de réalisation de l'invention, après fourniture d'un service ;
La figure 6 propose un diagramme séquentiel des différentes interactions entre fournisseur de service, donneur d'ordre et plateforme de mise en relation d'offres et de besoins selon un mode de réalisation de l'invention.
Description détaillée de modes de réalisation de l'invention
Le principe général de l'invention repose sur l'utilisation d'une structure de chaînes de blocs, dans un réseau de communication, pour concevoir une plateforme de mise en relation de clients et de fournisseurs de service, aidant à une affectation décentralisée, transparente et/ou objective d'offres de service aux demandes de service formulées par les clients.
On présente désormais, en relation avec la figure 1, l'architecture d'un système de fourniture de service à base de chaîne de blocs selon un mode de réalisation de l'invention. Un tel système comprend un réseau de chaînes de blocs 100, également appelé par la suite réseau blockchain 100, comprenant une pluralité de nœuds NI à N5 interconnectés les uns aux autres. La structure du nœud NI est illustrée plus en détail. Chaque nœud N2 à N5 présente une architecture similaire à celle du nœud NI, bien que cela n'ait pas été détaillé, par souci de simplification, sur la figure 1. Ainsi, dans certains modes de réalisation, le nœud NI peut comprendre :
- une machine virtuelle Ethereum EVM 10, qui est l'environnement d'exécution des contrats intelligents dans Ethereum. On rappelle qu'Ethereum est un protocole d'échanges décentralisés permettant la création, par les utilisateurs, de contrats intelligents grâce à un langage Turing- complet ;
- une zone de stockage de données STOR 12 ;
- le code à octets (en anglais « bytecode ») du contrat intelligent SC 11, i.e. le code déterministe exécutable sur le réseau blockchain 100, dont les variables peuvent être stockées sur le réseau 100, et dont les fonctions peuvent être appelées moyennant des fonds suffisants.
Le système dorsal (ou « backend ») de la plateforme de fourniture de service est ainsi décentralisé, et réside dans le contrat intelligent SC 11 implémentant un panel de fonctions nécessaires à la mise en relation de fournisseurs de service et de donneurs d'ordre. Comme on le verra plus en détail par la suite, ces fonctions qui peuvent être implémentées par le contrat intelligent SC 11 sont les suivantes :
Register(), pour l'enregistrement de requêtes de services ou d'offres de service dans le réseau blockchain 100 ;
Filter(), pour le filtrage des offres de service en fonction de critères de sélection de service listés dans une requête de service ;
Sort(), pour le tri des offres de service répondant aux critères stipulés dans la requête de service ; generateContract(), pour l'établissement d'un contrat entre un fournisseur de service et un donneur d'ordre ; updateQoSQ, pour l'enregistrement dans le réseau blockchain 100 d'une qualité de service correspondant à un service fourni.
Les utilisateurs de la plateforme sont par exemple les fournisseurs de service 101 et les donneurs d'ordre, ou clients, 102. Ils peuvent interagir avec la plateforme via leur interface, ou frontend.
Des requêtes API (pour « Application Programming Interface », en français, interface de programmation d'application) permettent l'interaction entre les utilisateurs 101, 102 d'une part, et le contrat intelligent SC 11 déployé sur le réseau blockchain 100 d'autre part.
Le dispositif client d'un donneur d'ordre 102 peut comprendre un module d'émission/réception RX/TX 1020, configuré pour émettre des requêtes de service à destination de la plateforme 100 ainsi qu'une évaluation d'un service fourni, et pour recevoir des offres de service candidates, sélectionnées par la plateforme 100. Un tel dispositif client peut comprendre notamment un ou plusieurs processeurs, configurés pour exécuter des instructions de code de programme pour l'émission et la réception de telles données, notamment conformes aux langages de programmation HTML (pour « HyperText Markup Language »), et JS (pour Java Script).
Le dispositif fournisseur d'un fournisseur de service 101 comprend un module d'émission/réception RX/TX 1010, configuré pour émettre des offres de service à destination de la plateforme 100, et pour recevoir des contrats, établis par la plateforme 100 lorsqu'une offre de service a été élue pour répondre à une requête de service d'un dispositif client 102. Un tel dispositif fournisseur comprend notamment un ou plusieurs processeurs, configurés pour exécuter des instructions de code de programme pour l'émission et la réception de telles données, notamment conformes aux langages de programmation HTML (pour « HyperText Markup Language »), et JS (pour Java Script).
Les transactions répertoriées et validées entre les fournisseurs de service 101 et les clients 102 peuvent être stockées sous forme de blocs dans les noeuds NI à N5 de la chaîne de blocs 100. Des règles de consensus peuvent aider à limiter les noeuds malveillants, et à repérer les transactions invalidées. Des règles cryptographiques peuvent aider à assurer un pseudo-anonymat des transactions et des utilisateurs, et l'authenticité de l'historique de services des fournisseurs 101.
Le terme nœud 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.
Plus généralement, un nœud Ni comprend une mémoire vive (par exemple une mémoire RAM), une unité de traitement équipée par exemple d’un processeur, et pilotée par un programme d’ordinateur, représentatif des instructions de code du contrat intelligent SC 11, stocké dans une mémoire morte (par exemple une mémoire ROM ou un disque dur). A l’initialisation, les instructions de code du programme d’ordinateur sont par exemple chargées dans la mémoire vive avant d’être exécutées par le processeur de l’unité de traitement.
La figure 1 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser un nœud Ni, afin qu'il effectue les étapes du procédé détaillé ci-après, en relation avec les figures 2 à 6 (dans l'un quelconque des différents modes de réalisation, ou dans une combinaison de ces modes de réalisation). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Dans le cas où le nœud Ni est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Selon un mode de réalisation de l'invention, la plateforme de mise en relation 100 se veut générique, en ce sens qu'elle ne s'inscrit pas dans un cas d'usage particulier, mais peut trouver des applications dans des domaines divers, tels que l'agriculture, la logistique maritime, la logistique de transport routier, les services à la personne, la production industrielle, l'énergie, etc. Comme illustré par la figure 2, il peut donc être nécessaire, avant que la plateforme 100 ne devienne pleinement opérationnelle, de prévoir un temps d'instanciation de la plateforme 100 pour l'adapter par exemple au domaine d'application souhaité par l'utilisateur. Notamment, l'ouverture du réseau 100 peut être réglable à l'instanciation (de la chaîne de blocs publique aux chaînes de blocs permissionnées, et aux chaînes de blocs privées). Ainsi, cet utilisateur peut être un acteur privé dans le cas d'une chaîne de blocs privée, ou un consortium d'acteurs, dans le cas d'une chaîne de blocs de consortium. Par exemple, l'instanciation de la plateforme 100 peut être réalisée par un consortium d'entreprises de transport, dans le cas d'une plateforme dédiée au transport de marchandises.
La figure 2 illustre ce temps d'instanciation par un utilisateur, qualifié d'utilisateur mère, que l'on pourrait noter en anglais « Field Authority » FA 20. Dans l'exemple donné ci-avant, cet utilisateur mère FA 20 est le consortium d'entreprises de transport, qui se sont préalablement mises d'accord sur les paramètres d'instanciation de la plateforme 100.
Ainsi, au cours d'une phase d'initialisation INIT 21 des règles de la plateforme 100, l'utilisateur mère FA 20 peut par exemple spécifier :
- le corps de contrat légal attendu CONT 22, par exemple une lettre de voiture dans le cas d'un transport de marchandise. Ce corps de contrat CONT 22 est stocké dans le contrat intelligent SC 11. Il s'agit d'un contrat type, correspondant au type de fourniture de service auquel la plateforme 100 va être dédiée, que l'on pourra noter par la suite C ;
- l'ensemble P des critères de sélection objectifs CSEL 23 pouvant être choisis par les donneurs d'ordre 102 pour formuler une requête de service adressée à la plateforme 100. Les fournisseurs de service 101 devront renseigner ces différents critères de sélection lors de la proposition d'une ressource, ou offre de service, sur la plateforme de mise en relation 100.
Par exemple, dans l'exemple d'une application logistique pour des entreprises de transport, les critères de sélection P peuvent comprendre : le poids du colis à livrer ; le volume du colis à livrer ; la zone géographique de prise en charge du colis (par exemple sous forme de coordonnées GPS pour « Global Positioning System ») ; la zone géographique de livraison du colis (par exemple sous forme de coordonnées GPS pour « Global Positioning System ») ; le type d'équipement utilisé pour la livraison ; le prix ; le temps qui s'écoule entre la prise en charge et la livraison du colis ; un identifiant du livreur (par exemple son IMSI pour « International Mobile Subscriber
Identity »).
Dans le mode de réalisation illustré, après finalisation de cette phase d'instanciation, la plateforme 100 est opérationnelle pour procéder à un enregistrement des ressources proposées par différents fournisseurs de biens ou de services 101, comme illustré par le schéma synoptique de la figure 3.
En effet, les fournisseurs de service 101 intéressés et autorisés par l'utilisateur mère FA 20 peuvent proposer leurs services à la plateforme 100, pour qu'ils soient référencés dans un catalogue de services enregistré dans la chaîne de blocs. Cet enregistrement des offres de service dans la chaîne de blocs constitue une sécurisation forte pour les clients 102 potentiels, car elle leur garantit que les fournisseurs de service 101 ne puissent pas modifier les paramètres de l'offre de service qu'ils proposent (prix, délai, quantité, type d'équipement, etc.) après contractualisation.
Ainsi, au cours d'une étape Add_NR 31, le fournisseur de service 101-1 adresse à la plateforme de mise en relation 100 un descriptif de son offre de service, selon l'ensemble P des différents critères de sélection CSEL 23 définis lors de la phase d'instanciation de la plateforme ; de même, au cours d'une étape Add_NR 32, le fournisseur de service 101-2 adresse à la plateforme de mise en relation 100 un descriptif de son offre de service, selon l'ensemble P de critères de sélection. Par exemple, dans l'exemple précédent d'une application logistique pour des entreprises de transport, le fournisseur de service 101-1 peut, au cours de l'étape Add_NR 31, décrire une offre de service conforme aux critères de sélection P suivants : le poids du colis à livrer : inférieur ou égal à 150 kg ; le volume du colis à livrer : inférieur ou égal à 2 m3 ; la zone géographique de prise en charge du colis : une zone de 30km de rayon autour d'une ville A ; la zone géographique de livraison du colis : une zone de 200km de rayon autour de la ville A ; le type d'équipement utilisé pour la livraison : un camion hybride ou 100 % électrique équipé pour le transport de produits frais, identifié par son modèle et sa référence constructeur ; le prix, exprimé par exemple en € par kilomètre ; le temps qui s'écoule entre la prise en charge et la livraison du colis, par exemple une garantie de livraison en 48h ; un identifiant du livreur (par exemple son IMSI pour « International Mobile Subscriber Identity ») ; les certifications du livreur (e.g. transport de produits frais / produits chimiques / autorisation de livraison à l'international etc.).
A réception, le contrat intelligent SC 11 peut enregistrer les offres reçues des fournisseurs de service 101-1 et 102-2 dans la chaîne de blocs 100, au cours d'une étape Update_RC 33. Le catalogue de ressources enregistré dans la chaîne de blocs peut spécifier, pour au moins certaines d'entre elles (par exemple chacune), les valeurs de critères de sélection P spécifiés dans les offres transmises par les fournisseurs de service 101. En outre, dans certains modes de réalisation, un fournisseur de service 101 peut disposer d'une pseudo-identité sur la chaîne de blocs 100, qui est associée à un historique de services précédemment fournis par ses soins.
Dans certains modes de réalisation, la mise à jour du catalogue de ressources et d'offres de service illustrée par la figure 3 peut se faire en continu, tout au long de la durée d'opération de la plateforme de mise en relation 100 : de nouveaux fournisseurs de service peuvent proposer leurs ressources ; de même, des fournisseurs de service déjà enregistrés sur la plateforme 100 peuvent mettre à jour leurs offres de service, et notamment les valeurs affectées aux différents critères P de sélection (par exemple mise à jour du prix, du délai garanti, ou du type d'équipement). Lorsqu'un client (ou donneur d'ordre) 102 souhaite formuler une demande de service, il peut adresser une requête de service 40 à la plateforme 100, comme illustré par la figure 4.
Cette requête de service 40, que l'on peut noter Req[S,, T, dT, R, I], peut comprendre des critères de sélection [S,, T, dT], où :
- S, est un sous-ensemble des critères de sélection P définis lors de l'instanciation de la plateforme 100, correspondant aux critères de sélection retenus par le donneur d'ordre 102 pour répondre à son besoin,
- T est la durée de vie de la requête de service, et
- dT est la fréquence de relance en cas d'absence d'allocation d'un fournisseur de service à l'exécution de la requête de service 40.
On notera qu'en variante, la fréquence de relance dT peut être définie par l'utilisateur mère lors de l'instanciation de la plateforme. Par exemple, parmi l'ensemble des critères P permettant de définir les besoins du client 102, celui-ci peut ne s'intéresser, dans la formulation de sa requête, qu'à un sous-ensemble S,, à savoir : le poids du colis à livrer : 40 kg ; le volume du colis à livrer : 1 m3 ; la zone géographique de prise en charge du colis : ville A ; la zone géographique de livraison du colis : ville B ; le prix, qui doit être inférieur à 100€ ; le type de camion, qui doit être électrique ; les certifications du livreur, qui doit être habilité pour le transport de produits frais.
En revanche, la durée de la livraison, et l'identifiant du livreur peuvent être secondaires pour le client 102, qui peut donc ne pas spécifier la valeur de certains de ces critères de sélection CSEL 23 dans sa requête de service 40.
En outre, dans certains modes de réalisation, le donneur d'ordre 102 peut spécifier, dans la requête de service 40, des règles de qualité de service, ou QoS, minimales souhaitées, notées R. Notons N le nombre de critères de sélection CSEL définissant l'ensemble P de critères de sélection instanciés sur la plateforme 100. Une règle de QoS R peut être par exemple une combinaison booléenne des critères de sélection de P où V j e | [0, N ] | , Pj peut être pondéré d'un facteur Xj e [0,1]. Par exemple, si le client 102 est attaché à ce que le délai de livraison soit respecté et que le coût reste maîtrisé, il peut spécifier une règle R de QoS, dans laquelle un poids de 1 sera affecté aux critères de sélection de P correspondant à la durée de livraison et au prix, et un poids nul sera affecté aux autres critères de sélection de l'ensemble P.
Dans un autre exemple, une règle R de QoS est construite à partir de deux métriques (N=2), à savoir l'expérience du livreur, et le respect des délais de livraison. Le client 102 affecte par exemple un poids pl=0,6 à la métrique Q1 relative au critère PI d'expérience du livreur et un poids p2=0,8 à la métrique Q2 relative au critère P2 de respect des délais (). Les valeurs des métriques du livreur peuvent toutes deux être normalisées entre 0 et 1. La règle R de QoS peut alors s'exprimer sous la forme : R = (pl.Ql + p2.Q2)/N
Si la métrique relative à l'expérience du livreur Q1 vaut 0,7 et que la métrique Q2 relative au respect des délais Q2 vaut 1 (il n'y a jamais eu de retard), alors le score de QoS du livreur pour la règle R sera :
QoS = (pl.Ql + p2.Q2)/N = (0,6 x 0,7 + 0,8xl)/2=0,61
Enfin, dans certains modes de réalisation, la requête de service 40 peut également contenir des incitations optionnelles I, proposées par le donneur d'ordre 102 pour inciter le fournisseur de services qui sera sélectionné à fournir la meilleure qualité de service possible. Ces incitations optionnelles I peuvent prendre la forme par exemple d'une gratification du fournisseur de service en cas de satisfaction du client (par exemple si le service est rendu à l'avance), d'un appel à un service d'audit en cas de litige, ou encore d'une caution demandée pour la prise en charge du service.
Un exemple d'incitation optionnelle est une caution du fournisseur de service lors de la prise en charge du service (par exemple, une caution de 0,3 fois la valeur de la marchandise prise en charge dans le camion). Elle peut être mise sous séquestre par exemple jusqu'à l'exécution du service demandé.
Si la livraison se passe sans encombre, la caution peut être reversée dans son intégralité au fournisseur de service. Sinon, dans l'hypothèse où le fournisseur de service disparaît avec la marchandise, celle-ci peut être versée automatiquement au donneur d'ordre. Une telle incitation encourage donc ainsi une exécution favorable du service.
Lors de ou après la réception de la requête de service 40, le contrat intelligent SC 11 peut procéder à un filtrage 41 des ressources disponibles dans le catalogue de ressources mis à jour lors de l'étape référencée 33, sur la base notamment des critères de sélection S, spécifiés dans la requête 40.
Dans certains modes de réalisation, si, lors d'une étape 42 d'identification des offres de service compatibles avec la requête de service 40, aucune offre de service répertoriée dans le catalogue enregistré sur la chaîne de blocs 100 ne correspond à l'ensemble des critères de sélection S, spécifiés par le client 102, le contrat intelligent SC 11 peut réitérer le filtrage 41 après un intervalle de temps dT, correspondant par exemple à la fréquence de la relance en cas d'échec de l'allocation de ressource au client 102. Selon les modes de réalisation, cette itération du filtrage 41 peut être répétée un nombre M de fois (M entier strictement positif) ou tant que la durée de vie T de la requête de service n'a pas expiré. On notera que dT peut être fixé à zéro, soit dans la requête de service 40, soit lors de l'instanciation de la plateforme. Dans ce cas, le filtrage n'est pas réitéré, et si aucune offre service candidate n'est identifiée lors de l'étape référencée 42, la demande de service est annulée, et le donneur d'ordre 102 en est notifié par la plateforme 100.
Si, en revanche, lors de l'étape 42 d'identification des offres de service compatibles avec la requête de service 40, le contrat intelligent SC 11 identifie plusieurs offres de service satisfaisant les critères de sélection S, spécifiés dans la requête de service 40, il peut procéder, au cours d'une étape référencée 43, à un tri multi-objectifs (SORTQ) pour obtenir un profil (par exemple obtenir le meilleur profil) parmi l'ensemble des offres de service identifiées.
Ce tri 43 peut être fondé par exemple sur au moins certaines des règles de QoS R fixées par le donneur d'ordre 102. Par exemple, pour chacune des offres candidates identifiées lors de l'étape référencée 42, les valeurs des critères de sélection entrant dans le calcul des règles R de QoS peuvent être extraites du journal des évènements enregistrés dans la chaîne de blocs 100 pour le fournisseur de service 101 ayant émis l'offre de service candidate. Le calcul du score de QoS affecté à des offres de service candidates se fait par exemple par calcul d'une moyenne pondérée, à partir des critères de sélection entrant dans la règle de QoS R. Par exemple, si dix services ont déjà été rendus par le fournisseur de service 101 et enregistrés dans un historique de services de ce fournisseur dans la chaîne de blocs 100, ils peuvent être tous dix pris en compte pour le calcul de la note de QoS qui lui est affectée.
Le tri 43 des scores de QoS des offres candidates peut s'obtenir par exemple avec la formule suivante :
SORT(Q) = DESCENDING_SORT([ åj pij Normj(Qij) V i e Offres de service])
Plus précisément, on normalise d'abord les paramètres de QoS pour chacune des offres candidates, par exemple pour chacun des livreurs (Normj(Qij)).
Une fois cette normalisation obtenue, on applique une moyenne pondérée (åj pij Normj(Qij)).
On vient effectuer un tri par ordre décroissant (DESCENDING_SORT) de la liste obtenue. On peut alors en extraire la note maximale.
On considère par exemple une règle de QoS R, dans laquelle entrent en compte trois métriques correspondant à trois critères de sélection PI, P2 et P3, et pour laquelle les critères de pondération associés sont les suivants : [pl=0,6, p2=0,4, p3=0,7].
On suppose que quatre livreurs répondent aux critères de sélection établis par le donneur d'ordre 102 pour une livraison de marchandise, et que, pour les trois critères de sélection PI, P2 et P3, chacun des livreurs est noté de la façon suivante :
Livreur 1 = [Qu=l, QI2=2, Qis=3]
Livreur 2 = [Q2i=2, Q22=4, Q 3=2]
Livreur 3 = [Q3i=16, Q32=4, Q33=4]
Livreur 4 = [Oii=6, Qi2=4, Qi3=4]
Après normalisation de ces paramètres de qualité de service, et pondération, on obtient, selon la formule ci-dessus, la liste des QoS suivante (en %), pour chacun des livreurs 1 à 4 : [QoSl=31, QoS2=26, QoS3=62, QoS4=10]
Le tri 43 par ordre décroissant donne donc [QoS3, QoSl, QoS2, QoS4]
On calcule ainsi, pour au moins certaines des offres de service candidates (par exemple toutes), un score de qualité de service (par exemple QoS3 pour le livreur 3), en fonction des valeurs qui ont été affectées aux différents critères de sélection P, par exemple à l'occasion de services précédemment rendus par les fournisseurs de service, et dont l'évaluation a été enregistrée dans la chaîne de blocs 100. Les offres de service peuvent être triées sur la base de ce score de qualité de service. Dans une première variante de réalisation, les offres de service candidates ainsi triées (Livreur 3 > Livreur 1 > Livreur 2 > Livreur 4) peuvent être envoyées par la plateforme 100 au donneur d'ordre 102, qui peut alors opérer un choix, et élire l'offre de service qu'il souhaite retenir.
Dans une deuxième variante de réalisation, l'élection de l'offre de service est autonome, et peut être effectuée directement par la plateforme 100, qui retient par exemple l'offre présentant le meilleur score de qualité de service (dans l'exemple précédent, le livreur 3).
Le choix de l'une ou l'autre de ces variantes dépend d'une règle qui peut être spécifiée dans le contrat intelligent.
Dans certains modes de réalisation, lorsqu'une offre de service candidate a été élue, le contrat intelligent 11 peut générer, au cours d'une étape GEN_CONT 44, un contrat C, liant l'offre de service élue au donneur d'ordre 102. Ce contrat C, peut être généré par exemple à partir du modèle de contrat CONT qui a été choisi lors de l'étape référencée 22 de la figure 2, pendant la phase d'instanciation de la plateforme. Ce contrat G est enregistré dans la chaîne de blocs 100. Dans certains modes de réalisation, si la requête de service 40 comprenait une ou plusieurs incitations optionnelles, elles peuvent être mises sous séquestre au cours d'une étape référencée 45.
A l'issue de cette phase d'élection et de contractualisation, le service demandé peut être rendu par le fournisseur de service 101. Dans certains modes de réalisation, lors ou après exécution du service, le donneur d'ordre 102 peut par exemple appeler la fonction feedback (en français, retour, réaction ou commentaire) FB du contrat intelligent SC 11, au cours d'une étape référencée 50, comme illustré par la figure 5.
Le donneur d'ordre 102 transmet ainsi à la plateforme 100 un certain nombre de paramètres relatifs à l'exécution du service rendu, correspondant à des valeurs affectées aux critères de sélection de service P : durée effective de la livraison, note de satisfaction du client, intégrité de la marchandise livrée, etc. Par exemple, le donneur d'ordre 102 peut indiquer si les emballages étaient abîmés, et, le cas échéant, fournir des photos attestant de leur état à la livraison.
Les données transmises par le donneur d'ordre 102 peuvent être normalisées avant enregistrement dans la chaîne de blocs 100. Notamment, cette remontée d'informations peut être effectuée par un certain nombre d'objets connectés (loT) associés au donneur d'ordre 102 ou au fournisseur de service 101, qui peuvent fournir à la plateforme 100 des informations sur le service effectué, telles que le temps d'exécution par exemple.
De tels objets connectés (loT) peuvent être par exemple un détecteur d'ouverture de porte, un capteur de température, un capteur d'humidité, ou encore un capteur de poids, qui permettent de fournir des informations sur l'intégrité et la qualité de la marchandise livrée (par exemple sur le respect de la chaîne de froid pour un transport de produits frais). Ainsi, les capteurs de température et d'humidité peuvent par exemple transmettre à la plateforme 100 des diagrammes de température et d'humidité correspondant aux informations qu'ils ont relevées pendant la durée de la livraison.
De tels objets connectés peuvent encore correspondre à des étiquettes de type RFI D ou 5G permettant une identification des lots de marchandise.
La fonction FB du contrat intelligent SC 11 peut opérer alors deux mises à jour dans la chaîne de blocs 100 : une mise à jour 51 du statut du service requis STAT ; et/ou une mise à jour 52 de la qualité de service QoS associée au service rendu par le fournisseur de service, par exemple par calcul de moyenne mobile exponentielle.
On notera que le statut de la tâche STAT correspond à son exécution dans le respect des règles spécifiées dans le contrat intelligent SC 11 (statut positif - e.g. livraison en temps et en heure, avec la bonne marchandise, et avec un ensemble de contraintes environnementales et contextuelles respectées) ou à son non-respect (statut négatif - e.g. dans le cas d'une température seuil dépassée par exemple). L'évaluation du statut STAT est donc dépendant de l'exécution des termes du contrat.
En fonction d'une évaluation 53 du statut, le contrat intelligent SC 11 peut mettre en oeuvre différentes actions.
Si le statut est positif, le contrat intelligent SC 11 peut par exemple procéder, au cours d'une étape PAY 54, au déblocage des fonds associés à l'exécution du contrat : le fournisseur de service 101 reçoit le paiement du service effectué, et éventuellement la gratification optionnelle I prévue dans la requête de service 40, si ces conditions d'obtention sont remplies.
Dans le cas contraire, le contrat intelligent SC 11 peut par exemple envoyer, au cours d'une étape REF référencée 55, la caution du fournisseur de service 101 au donneur d'ordre 102, à titre de dédommagement de l'inexécution du contrat.
Le déroulement du service est tracé, de manière immuable, sur la chaîne de blocs 100. Les informations contenues dans ces traces pourront être utilisées, à l'occasion d'une future requête de service, dans le mécanisme de sélection de fournisseur décrit précédemment en relation avec la figure 4.
La figure 6 illustre, sous forme d'un diagramme séquentiel, une mise en relation de bout en bout entre un donneur d'ordre 102 et un fournisseur de service 101, dans un mode de réalisation de la plateforme 100. Dans l'exemple de la figure 6, on considère que dT=0 , i.e. l'identification d'offres de service candidates répondant aux critères de sélection du donneur d'ordre s'effectue une seule fois : en cas d'absence de candidat, la demande est annulée. La figure 6 illustre les différentes séquences d'interaction entre le fournisseur de service 101, le donneur d'ordre 102, et le contrat intelligent SC 11.
Au cours d'une étape référencée 61, le fournisseur de service 101 enregistre son offre de service auprès de la plateforme 100, en spécifiant les valeurs qu'il a fixées pour les différents critères de sélection P instanciés sur la plateforme. Au cours d'une étape 61, le contrat intelligent SC 11 les enregistre dans la chaîne de blocs 100, et met ainsi à jour le catalogue de ressources associé à la plateforme 100. Il adresse, au cours d'une étape référencée 63, un accusé de réception au fournisseur de service 101, pour lui confirmer l'enregistrement de son offre de service.
Au cours d'une étape référencée 64, un donneur d'ordre 102 adresse une requête de service 40 à la plateforme 100, en spécifiant des critères de sélection, et des règles de qualité de service, comme décrit précédemment en relation avec la figure 4. Le contrat intelligent SC 11 trie alors, au cours d'une étape référencée 65, l'ensemble des offres de service enregistrées sur la plateforme pour identifier la ou les offres candidates, qui satisfont les critères de sélection spécifiés par le client 102. Pour chacune, il calcule un score de qualité de service, en tenant compte par exemple de l'historique des services enregistrés pour chaque fournisseur de service dans la chaîne de blocs 100. Il trie ainsi les offres candidates en fonction de leur score de QoS, et envoi cette liste triée d'offres candidates au donneur d'ordre 102, au cours d'une étape référencée 66.
On suppose ici qu'il existe une ou plusieurs offres candidates susceptibles de répondre au besoin du client 102. Dans le cas contraire, la demande de service est annulée, conformément à l'étape référencée 80.
Le donneur d'ordre 102 élit l'une de ces offres, au cours de l'étape référencée 67, et en informe le contrat intelligent SC 11. Comme indiqué précédemment, en variante, l'élection peut être effectuée de manière automatique, directement par le contrat intelligent SC 11, sans intervention du client 102.
Le contrat intelligent SC 11 génère alors, au cours d'une étape référencée 68, le contrat encadrant la fourniture du service requis, et informe 69 le fournisseur de service qu'il a été sélectionné pour répondre à la requête du client 102. Le fournisseur de service confirme au contrat intelligent SC11 qu'il accepte de rendre le service pour lequel son offre a été élue, au cours d'une étape référencée 70. A réception de cet accord, le contrat intelligent SC 11 initialise 71 le processus de fourniture du service, et adresse des accusés de réception 72 et 73 au donneur d'ordre 102 et au fournisseur de service 101.
Au cours d'une étape référencée 74, le fournisseur de service 101 exécute le service pour lequel il a été choisi. Il en notifie (75) le client 102. Ce dernier peut adresser alors son retour 76 au contrat intelligent SC 11, en donnant par exemple une indication relative à sa satisfaction (appréciation, note de satisfaction, etc.) sur le service rendu, et en spécifiant par exemple les valeurs affectées pour ce service aux différents critères de sélection P. Le retour 76 adressé par le client 102 peut encore consister en une classification effectuée par une brique d'intelligence artificielle (IA). Suivant les traces d’exécution d’un service donné, un réseau préalablement entraîné peut en effet attribuer un label au fournisseur de service 101 (eg: débutant / intermédiaire / expert ...)
Le contrat intelligent SC 11 met alors à jour, au cours d'une étape référencée 77 le statut du service, et la qualité de service QoS du fournisseur de service 101. En fonction du statut du service, comme exposé ci-avant en relation avec la figure 5, il débloque des fonds (étape 79) pour payer le fournisseur de service 101, si le statut du service est positif, ou il transmet (étape 78) au client 102 la caution du fournisseur de service 101, si le statut du service est négatif.
La logistique est un cas d'application de cette plateforme 100 de mise en relation par contrat intelligent SC 11. Prenons l'exemple d'une livraison de colis.
Le donneur d'ordre 102 est à la recherche d'un livreur 101 disponible pour une période T donnée, dont le camion est équipé pour le transport de produits frais. La commande est critique, il souhaite recruter un livreur 101 fiable, qui a eu un minimum de retard durant l'année écoulée. La caution exigée de la part du transporteur peut être spécifiée, ainsi qu'un pourboire si la livraison a de l'avance.
Le donneur d'ordre 102 peut donc poster une demande 40 de livraison avec cet ensemble de critères, pondéré à souhait.
Dans ce scénario de fret, S, serait [M le prix, W le poids disponible minimum, V le volume minimum, E l’équipement, ville A, ville B], R serait [retard minimum, distance minimum, empreinte carbone minimum]. Les incitations facultatives seraient [D le dépôt, t le pourboire]. L’algorithme de tri applique les critères de sélection [Si, T] à la base de ressources enregistrée. Si aucune ressource ne correspond au profil demandé, un rappel est effectué après une période dT. Ces paramètres sont envoyés à la fonction de filtrage du contrat intelligent SC 11. Le filtrage devient positif lorsqu'au moins une ressource, ici un transporteur, remplit les critères de filtrage.
Si ce n'est pas le cas, la demande est mise en attente et réinstanciée jusqu'à la date T à chaque période dT spécifiée par le donneur d'ordre 102. Le donneur d'ordre 102 a la possibilité d'annuler le processus de mise en relation à chaque instant.
Supposons le filtrage positif. Les ressources sont triées suivant leur score de qualité de service QoS. Deux possibilités sont à considérer :
- Le choix de la ressource peut être manuelle, effectuée par le donneur d'ordre
- Le choix de la ressource peut être autonome. La ressource possédant le meilleur score de QoS sera affectée à la demande. A scores de QoS égaux, l'affectation est effectuée de manière aléatoire. Un contrat type e-CMR (document légal pour le transport de marchandise sur route) est généré sur la chaîne de blocs 100. La caution et la gratification peuvent également être mis sous séquestre.
Une fois la livraison effectuée, le donneur d'ordre 102 donne son feedback sur la livraison. Le statut de la tâche est mis à jour, le score de QoS (ici la réputation) du livreur 101 est mis à jour. Si la livraison a été effectuée sans encombre, la caution, et tout ou partie de la gratification sont envoyées au livreur.

Claims

REVENDICATIONS
1. Procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs (100) d'un réseau de communication, caractérisé en ce qu'il comprend des étapes, mises en oeuvre par un contrat intelligent (11) de ladite chaîne de blocs, de :
- réception (64) d'au moins une requête de service (40) comprenant au moins un critère de sélection de service et au moins une règle de qualité de service ;
- identification (42 ; 65) d'au moins une offre de service satisfaisant ledit au moins un critère de sélection de service, dite offre de service candidate, parmi des offres de service enregistrées dans ladite chaîne de blocs ;
- envoi (66) d'au moins une desdites offres de service candidates, ladite au moins une offre de service envoyée étant sélectionnée en fonction de ladite au moins une règle de qualité de service d'une part, et d'un historique de services, associés auxdites offres de service candidates, et enregistrés dans ladite chaîne de blocs (100), d'autre part.
2. Procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs d'un réseau de communication selon la revendication 1 caractérisé en ce que ledit contrat intelligent met en oeuvre une réception d'une pluralité de requêtes de services.
3. Procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs d'un réseau de communication selon la revendication 2 caractérisé en ce que ledit contrat intelligent met en oeuvre une réception d'une pluralité de requêtes de services émises par une pluralité de dispositifs clients dudit réseau de communication.
4. Procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs d'un réseau de communication selon l'une quelconque des revendications 1 à 3 caractérisé en ce qu'au moins un dispositif client émetteur de ladite au moins une requête de service et/ou au moins un dispositif fournisseur d'au moins une desdites offres de service enregistrées dans ladite chaîne de blocs interagit avec ledit contrat intelligent via au moins une requête de type API
(« Application Programming Interface ») utilisant au moins une fonction implémentée par ledit contrat intelligent et appartenant au groupe suivant :
- une fonction d'enregistrement d'au moins une requête de services et/ou d'au moins une offre de service dans ladite chaîne de blocs;
- une fonction de filtrage d'offres de service enregistrées en fonction d'au moins un critère de sélection de service compris dans au moins une requête de service ;
- une fonction de tri d'offres de service répondant au au moins un critère de sélection compris dans au moins une requête de service ; - une fonction d'établissement d'un contrat entre un dispositif fournisseur d'au moins une desdites offres de service et un dispositif éclient émetteur d'au moins une desdites requêtes de service;
- une fonction d'enregistrement dans ladite chaîne de blocs d'une qualité de service correspondant à un service fourni.
4. Procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs d'un réseau de communication selon la revendication 4 caractérisé en ce que lesdites fonctions dudit contrat intelligent mettent en oeuvre des règles de consensus.
5. Procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs d'un réseau de communication selon l'une quelconque des revendications 1 à 5, caractérisé en ce que lesdites offres de service envoyées sont triées (43) en fonction d'un score de qualité de service calculé pour une offre de service candidate, à partir de ladite au moins une règle de qualité de service d'une part, et dudit historique de services, associés à ladite offre de service candidate.
6. Procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs d'un réseau de communication selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite au moins une règle de qualité de service est une combinaison pondérée de critères de sélection de service enregistrés dans ladite chaîne de blocs.
7. Procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs d'un réseau de communication selon l’une quelconque des revendications 1 à 7, caractérisé en ce que ladite au moins une requête de service comprend également une durée de validité de ladite au moins une requête de service.
8. Procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs d'un réseau de communication selon la revendication 8, caractérisé en ce que ladite identification d'offres de service candidates est itérée jusqu'à la fin de ladite durée de validité, tant qu'aucune offre de service candidate n'a été identifiée.
9. Procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs d'un réseau de communication selon l’une quelconque des revendications 1 à 9, caractérisé en ce qu'un service dudit historique est enregistré dans ladite chaîne de blocs en association avec un ensemble de valeurs affectées auxdits critères de sélection de service pour ledit service.
10. Procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs d'un réseau de communication selon l'une quelconque des revendications 6 à 9, caractérisé en ce que ledit score de qualité de service est calculé par moyenne mobile pondérée ou exponentielle desdites valeurs desdits services dudit historique, en fonction de ladite au moins une règle de qualité de service.
11. Procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs d'un réseau de communication selon l’une quelconque des revendications 1 à 9, caractérisé en ce que, après fourniture du service requis, ledit procédé comprend des étapes de :
- réception (76) et enregistrement, dans ladite chaîne de blocs, de valeurs affectées auxdits critères de sélection de service pour ledit service fourni ;
- mise à jour (77), dans ladite chaîne de blocs, d'un statut dudit service requis.
12. Procédé de fourniture de service mis en oeuvre par ordinateur dans une chaîne de blocs d'un réseau de communication selon l’une quelconque des revendications précédentes, caractérisé en ce qu'il comprend également des étapes, mises en oeuvre par un contrat intelligent de ladite chaîne de blocs, de :
- réception (61 ; 31-32) d'une offre de service ;
- enregistrement (62 ; 33) de ladite offre de service dans ladite chaîne de blocs.
13. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de fourniture de service selon l’une quelconque des revendications 1 à 13.
14. Nœud (N1-N5) appartenant à un réseau de chaîne de blocs (100), configuré pour exécuter un contrat intelligent (11) de ladite chaîne de blocs, caractérisé en ce que ledit nœud comprend :
- au moins un processeur (10) ; et
- au moins une mémoire (12) lisible par ordinateur couplée audit au moins un processeur et dans laquelle sont enregistrées des instructions de code de programme exécutables par ledit au moins un processeur pour mettre en œuvre le procédé de fourniture de service selon l’une quelconque des revendications 1 à 13.
15. Dispositif client d'un réseau de communication, ledit dispositif client comprenant :
- un module d'émission d'au moins une requête de service, l'au moins une requête de service comprenant au moins un critère de sélection de service et au moins une règle de qualité de service ;
- un module de réception d'au moins une offre de service candidate satisfaisant ledit au moins un critère de sélection de service et sélectionnée, parmi des offres de service enregistrées dans une chaîne de blocs du réseau de communication, en fonction de ladite au moins une règle de qualité de service d'une part, et d'un historique de services, associés aux offres de service candidates, et enregistrés dans la chaîne de blocs, d'autre part.
16. Dispositif client d'un réseau de communication selon la revendication 15 dans lequel ledit module d'émission est configuré pour émettre des valeurs affectées aux critères de sélection de service pour un service fourni, destinées à être enregistrées dans ladite chaîne de blocs.
17. Dispositif fournisseur d'un réseau de communication, ledit dispositif client comprenant :
- un module d'émission d'une offre de service comprenant au moins un critère de sélection de service et destinée à être enregistrée dans une chaîne de blocs du réseau de communication ;
- un module de réception d'un contrat liant une requête de service enregistrée dans la chaîne de blocs et l'offre de service émise, sélectionnée, parmi des offres de service enregistrées dans la chaîne de blocs, en fonction d'au moins une règle de qualité de service contenue dans la requête de service d'une part, et d'un historique de services, associés au dispositif fournisseur, et enregistrés dans la chaîne de blocs, d'autre part.
EP22702752.1A 2021-01-07 2022-01-06 Procede de fourniture de service mis en oeuvre par ordinateur dans une chaine de blocs, noeud d'un reseau de chaine de blocs et programme d'ordinateur correspondants Pending EP4275166A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2100122A FR3118674A1 (fr) 2021-01-07 2021-01-07 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
PCT/FR2022/050032 WO2022148929A1 (fr) 2021-01-07 2022-01-06 Procede de fourniture de service mis en oeuvre par ordinateur dans une chaine de blocs, noeud d'un reseau de chaine de blocs et programme d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP4275166A1 true EP4275166A1 (fr) 2023-11-15

Family

ID=76375111

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22702752.1A Pending EP4275166A1 (fr) 2021-01-07 2022-01-06 Procede de fourniture de service mis en oeuvre par ordinateur dans une chaine de blocs, noeud d'un reseau de chaine de blocs et programme d'ordinateur correspondants

Country Status (4)

Country Link
US (1) US20240070664A1 (fr)
EP (1) EP4275166A1 (fr)
FR (1) FR3118674A1 (fr)
WO (1) WO2022148929A1 (fr)

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140365327A1 (en) * 2010-10-01 2014-12-11 Google Inc. Reverse auction for real-time services
US10438269B2 (en) * 2013-03-12 2019-10-08 Mastercard International Incorporated Systems and methods for recommending merchants
US11250493B2 (en) * 2014-03-31 2022-02-15 Monticello Enterprises LLC System and method for performing social media cryptocurrency transactions
EP3669282B1 (fr) * 2017-09-20 2022-11-02 Samsung Electronics Co., Ltd. Procédé et appareil pour gérer une requête de service dans un réseau de chaîne de blocs
US20190102850A1 (en) * 2017-09-29 2019-04-04 David McMakin Wheeler Smart city commodity exchange with smart contracts
US20200302563A1 (en) * 2019-03-18 2020-09-24 Hewlett Packard Enterprise Development Lp Negotiating service level objects and agreements through blockchain
US11257079B2 (en) * 2019-04-30 2022-02-22 Banco Bilbao Vizcaya Argentaria, S.A. Systems, methods, and interfaces for smart contract based exchanges via a blockchain
US11556923B2 (en) * 2019-05-24 2023-01-17 Visa International Service Association Blockchain enabled service request system
US11622252B2 (en) * 2019-11-08 2023-04-04 Huawei Technologies Co., Ltd. Methods and systems for management and control of communication network

Also Published As

Publication number Publication date
FR3118674A1 (fr) 2022-07-08
US20240070664A1 (en) 2024-02-29
WO2022148929A1 (fr) 2022-07-14

Similar Documents

Publication Publication Date Title
CA3166041C (fr) Systèmes et méthodes de gestion des événements de biens numériques capables d’adaptation en cas de congestion du réseau de la chaîne de blocs
US12278740B2 (en) Automating cloud services lifecycle through semantic technologies
Valtanen et al. Blockchain-powered value creation in the 5G and smart grid use cases
US20250390866A1 (en) Software architecture for efficient blockchain transactions
US11049081B1 (en) Video revenue sharing program
WO2010042100A1 (fr) Système et procédé d'établissement de prix et d'échange de contenu
EP4315742B1 (fr) Systèmes de réseaux informatiques pour opérations basées sur des jetons et sécurisées par cryptographie et leurs procédés d'utilisation
Gupta et al. A decentralized IoT data marketplace
Ludwig Clonal selection based genetic algorithm for workflow service selection
US20240086897A1 (en) Hybrid organizational system for data management and tracking
US20200302496A1 (en) Value-based data reputation management in data marketplace environment
EP4275166A1 (fr) Procede de fourniture de service mis en oeuvre par ordinateur dans une chaine de blocs, noeud d'un reseau de chaine de blocs et programme d'ordinateur correspondants
CN109829593B (zh) 目标对象的信用度确定方法、装置、存储介质及电子装置
US20130275265A1 (en) Business to business integration services marketplace
US20200273044A1 (en) Shared Customer Relationship Management (CRM) System and Method using Event Based Normalization
US12236548B2 (en) System and method for negotiation and permanence management of metaverse mashups
EP4659407A1 (fr) Détermination d'un consensus pour l'ajout d'un bloc à une chaîne de blocs
Habes et al. Towards a fairer negotiation for dynamic resource allocation in cloud by relying on trustworthiness
CN116883170A (zh) 基于区块链的api服务调用存证结算方法
WO2021198615A1 (fr) Plateforme électronique collaborative pour la prédiction de défauts de paiement entre entreprises et procédé associé
Yoon et al. Decentralized identifiers and NFT-driven Blockchain solution for personal data trading
WO2022243939A1 (fr) Systèmes et procédés pour preuve de propriété marquée
Pitta et al. Market design for iot data and services the emergent 21th century commodities
EP3189483A1 (fr) Procédé de traitement d'une transaction récurrente, dispositif et programme correspondant
Rasolroveicy et al. IntelliChain: An Intelligent and Scalable Framework for Decentralized Applications on Public Blockchain Technologies: An NFT Marketplace Case Study

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: 20230630

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 MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20250916