EP4107905A1 - Procede et dispositif de controle d'acces a une fonction d'une application inscrite dans une chaine de blocs - Google Patents

Procede et dispositif de controle d'acces a une fonction d'une application inscrite dans une chaine de blocs

Info

Publication number
EP4107905A1
EP4107905A1 EP21710027.0A EP21710027A EP4107905A1 EP 4107905 A1 EP4107905 A1 EP 4107905A1 EP 21710027 A EP21710027 A EP 21710027A EP 4107905 A1 EP4107905 A1 EP 4107905A1
Authority
EP
European Patent Office
Prior art keywords
function
terminal
identifier
request
execution
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
EP21710027.0A
Other languages
German (de)
English (en)
Inventor
Emmanuel Bertin
Julien HATIN
Baptiste HEMERY
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 EP4107905A1 publication Critical patent/EP4107905A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • Title Method and device for controlling access to a function of an application registered in a blockchain.
  • the invention relates to the general field of telecommunications networks, and more specifically to blockchain technology.
  • each decentralized application present within the blockchain is composed of a binary code and an interface exposing methods that can be called, for example by a third party or by other applications.
  • a DApps also has a private data area that it will be able to modify depending on the processing carried out.
  • the business model of such a blockchain is essentially focused on the act of deploying the application. You have to "pay" to deploy the application, that is, pay the people who validate the application and create the block associated with validation at the blockchain level. In addition, people who want to use the application, for example by sending a request to complete a particular task, must also pay for each use according to a predetermined algorithm.
  • the invention improves on the state of the art and proposes a method for controlling access to a function of an application implemented by a device for controlling access to a function of an application, this control device. being registered in a chain of blocks, the method being characterized in that it comprises:
  • a step of sending a response to the access request comprising at least one parameter for accessing said at least one first function and at least one second identifier of at least one second function registered in said chain of blocks , said at least one second identifier being associated with said at least one parameter.
  • the invention proposes to use a blockchain to manage access to an application registered in a blockchain and more specifically to its function (s).
  • the present request is presented in the context of a "blockchain” in English “blockchain” but the expression “block chain” is to be understood as covering any type of DLT (in English Distributed Ledger Technology) capable of hosting decentralized applications known under the name of DApp (Decentralized Applications in English) of which the blockchains themselves constitute a particular element.
  • blockchain technology is a technology for storing and transmitting information without a control organ.
  • it is a distributed database whose information sent by users and internal links to the base are verified and grouped at regular time intervals in blocks, the whole being secured by cryptography, and thus forming chain.
  • a blockchain is a distributed database that maintains a list of records protected against tampering or modification by storage nodes; it is therefore a distributed and secure register of all transactions carried out since the start of the system.
  • Blockchains are characterized in particular in that their content cannot be modified or deleted: information that is published (that is, recorded or saved) in a blockchain remains forever.
  • the invention offers a new mechanism in which, when a request for access to a function of an application registered in a blockchain is sent by a user terminal, the device executing the method access control system then sends back a response with an access parameter associated with the function, such as for example a tariff option and an identifier of a second function, such as a payment function associated with the option.
  • an access parameter associated with the function such as for example a tariff option and an identifier of a second function, such as a payment function associated with the option.
  • this embodiment makes it possible to specify to a user the conditions of access and use of a function registered in a chain of blocks.
  • function is meant a portion of computer code representing a computer subroutine, which performs a particular task or calculation.
  • the function identifier is for example the name given by the programmer when creating it or the signature of the function including parameters.
  • a terminal identifier is understood to mean a sequence of characters that uniquely identifies the terminal such as a MAC address, an IP address, a serial number (eg an IMEI) or a cryptographic key.
  • the identifier of the terminal can also be an identifier of the user entered by the latter via a user interface of the terminal such as a graphical or voice interface, and making it possible to uniquely identify the user of the terminal.
  • the identifier can for example be an e-mail address, an identity card number, a subscriber number, etc.
  • a method as described above is characterized in that the sending step is followed by a first step of publishing in said chain of blocks, said identifier of said first terminal , at least one datum associated with the receiving step and at least one datum associated with the sending step.
  • This publication in the blockchain is carried out to store and share information related to the reception and transmission stages such as the date and time of reception and transmission of requests, elements received or sent such as for example the identifier of the terminal, or the result of processing carried out by the device.
  • a method as described above is characterized in that the emission step is followed:
  • this embodiment allows the user to execute the second function such as for example a payment function allowing the use of the first function.
  • a blockchain post is also performed to store and share the result of performing the second function.
  • the information published can for example be the status of a payment, information related to the request for execution of the second function such as the identifier of the terminal and / or of the user or any other information associated with the. execution of the second function.
  • a method as described above is characterized in that the second publication step is followed by a second step for sending a response to the request.
  • execution comprising at least one piece of data associated with the result of the execution of said at least one second function.
  • this embodiment allows the user to have information on the execution of the second function and its result.
  • the second function is a payment function
  • the user will thus have, for example, information on the status of the payment (accepted, refused or pending) or its transaction number.
  • a method as described above is characterized in that the second publication step is followed:
  • a third step of sending a response to the authorization request comprising at least one second parameter for accessing said at least one first function, said access parameter being a function of the result of the execution of said at least one second function obtained via the data of said payment publication;
  • this embodiment makes it possible to verify that the user does indeed have the right to access the first function.
  • the application will then verify that the second function has been executed by the user's terminal and that the result conforms to what is expected. For example, the application will check that a payment has been made by the user (execution of the second function) and that the payment has been validated (compliant result) before giving access to the first function.
  • Method for controlling the execution of a function of an application implemented by a device for controlling the execution of a function of an application, this control device being registered in a chain of blocks, the method being characterized in that it comprises:
  • this embodiment allows, when a first execution request to a first function of an application registered in a blockchain is sent by a user terminal, to return a response with an identifier of a second function such as for example a function which will make it possible to give additional information to the user on the first function.
  • a method of controlling the execution of a function of an application as described above is characterized in that the sending step is followed by a first step of publication in the blockchain of said identifier of said terminal, at least one datum associated with the receiving step and at least one datum associated with the sending step.
  • This blockchain posting is performed following the issue step of the fulfillment request response to store and share information related to the receive and issue steps such as date and time. time of reception and transmission of requests, of elements received or sent such as for example the identifier of the terminal, or the result of a processing carried out by the device
  • a method of controlling the execution of a function of an application as described above is characterized in that the emission step is followed:
  • this embodiment makes it possible, when a second request for execution of a first function of an application registered in a chain of blocks is sent by a user terminal, to issue a request for authorization of use. and to obtain in return an access parameter to the first function for the user terminal. The execution of the function then depends on the access parameter.
  • a publication in the blockchain is also carried out to store and share information related to the stages of reception, transmission and execution such as the date and time of reception and transmission of requests, elements received or sent as for example the access parameter, or the result of a processing carried out by the device.
  • a method of controlling the execution of a function of an application as described above is characterized in that the second publication step is followed by a third step sending a response to the second execution request comprising at least one piece of data associated with the result of the execution of said at least one first function.
  • this embodiment allows the user to have information on the execution of the first function and its result.
  • the invention also relates to a device for controlling access to a function of an application, said control device being registered in a chain of blocks and comprising:
  • a module for sending a response to the access request comprising at least one parameter for accessing said at least one first function and at least one second identifier at least one second function registered in said chain of blocks, said at least one second identifier being associated with said at least one parameter;
  • a device for controlling access to a function of an application as described above is characterized in that it further comprises:
  • a second module for receiving an execution request, coming from at least a second terminal, of said at least one second function, said execution request comprising at least said identifier of said first terminal;
  • a device for controlling access to a function of an application as described above is characterized in that it further comprises:
  • a third module for receiving a request for authorization of use by said first terminal of said at least one first function, said request coming from said application and comprising at least said identifier of said first terminal and at least said first identifier of said at least one first function;
  • a third module for sending a response to the authorization request comprising at least one second parameter for accessing said at least one first function, said access parameter being a function of the result of the execution of said at least one first function. at least one second function obtained in the data of said payment publication; a third module for publishing, in the blockchain, said at least one second access parameter and said identifier of said first terminal.
  • the invention also relates to a device for controlling the execution of a function of an application, said control device being registered in a chain of blocks and comprising:
  • a device for controlling the execution of a function of an application as described above is characterized in that it further comprises:
  • a second module for receiving a second execution request, coming from said terminal, of said at least one first function, said second execution request comprising at least said first identifier of said at least one first function and at least said identifier of said terminal;
  • a second module for transmitting an execution authorization request, for said terminal, of said at least one first function, said authorization request comprising at least said identifier of said terminal and at least said first identifier of said terminal. said at least one first function;
  • a third module for receiving a response to the authorization request comprising at least one parameter for accessing said at least one first function for said terminal;
  • module can correspond both to a software component and 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 capable of implementing a function or a set of functions as described for the modules concerned.
  • a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .).
  • the invention also relates to a computer program comprising instructions for implementing one or other of the methods defined above according to any one of the particular embodiments described above, when said program is executed. by a processor.
  • the method can be implemented in various ways, in particular in wired form or in software form.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other. desirable shape.
  • the invention also relates to a recording medium or information medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the aforementioned recording media can be any entity or device capable of storing the program.
  • the medium can comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a hard disk.
  • the recording media can correspond to a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the programs according to the invention can in particular be downloaded from an Internet type network.
  • the recording media can correspond to an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • Figure 1 shows the hardware architecture of an access control device to a function according to a particular embodiment
  • Figure 2 shows the hardware architecture of a device for controlling the execution of a function according to a particular embodiment
  • FIG. 3 represents in the form of a flowchart the main steps of a method of controlling access to a function and the main steps of a method of controlling the execution of a function in accordance with the modes of operation. realization of the invention.
  • FIG. 1 represents the hardware architecture of a DCA access control device to a function in accordance with the invention.
  • this device has the hardware architecture of a computer. It notably comprises a processor PROC1, a random access memory MV1, a read only memory MEM1 and a non-volatile flash memory MF1.
  • the read only memory constitutes a recording medium in accordance with the invention, readable by the processor PROC1 and on which is recorded here a computer program PG1 in accordance with the invention, this program comprising instructions for implementing the steps of the process. method of controlling access to a function as described above, when the program is executed by the processor PROC1.
  • the code instructions of the computer program PG1 are for example loaded into a memory before being executed by the processor PROC1.
  • the processor PROC1 of the processing unit UT1 notably implements the steps of the method of controlling access to a function according to any one of the particular embodiments described in relation to FIG. 3, according to the instructions of the program d computer PG1.
  • the DCA device also comprises communication modules COM 11 and COM 12 configured to establish communications with for example an IP network and / or circuit.
  • the communication module COM11 is used to receive requests for access to a first function coming from a terminal and the module COM 12 to send a response comprising access parameters and an identifier of a second function associated with the first function.
  • the DCA device further comprises an OBT1 module capable of publishing in the block chain data related to the reception and transmission steps of the access control method to a function.
  • the modules COM11 and COM12 can be one and the same communication module (COM1).
  • the module COM1 is also able to receive requests for execution of the second function and the module OBT1 is able to publish in the block chain data related to the step of receiving d 'an execution request and its execution.
  • the second function can be executed by the DCA device and its processor PROC1 or via a dedicated module (not shown here).
  • the module COM1 can also be used to send a response to the execution request with data concerning the result of the execution of the second function.
  • the module COM1 can also receive authorization request requests concerning the use of the first function and send a response comprising a second access parameter according to a publication. obtained from the blockchain via the OBT1 module.
  • the module OBT1 can also publish in the block chain data such as the second parameter, an identifier of the terminal or any other data relating to the data received and sent by the module COM1.
  • the requests received and sent by the DCA device are handled by the module COM1.
  • the DCA device can include several communication modules allowing the reception and / or transmission of requests.
  • the OBT1 module manages all the publications made at the blockchain level.
  • the DCA device can include several publication modules allowing the publication and / or the obtaining of the publications at the blockchain level.
  • FIG. 2 shows the hardware architecture of a DCE control device for the execution of a function according to the invention.
  • this device has the hardware architecture of a computer. It comprises in particular a processor PROC2, a random access memory MV2, a read only memory MEM2 and a non-volatile flash memory MF2.
  • the read only memory constitutes a recording medium in accordance with the invention, readable by the processor PROC2 and on which is recorded here a computer program PG2 in accordance with the invention, this program comprising instructions for implementing the steps of the method of controlling the execution of a function as described above, when the program is executed by the processor PROC2.
  • the code instructions of the computer program PG2 are for example loaded into a memory before being executed by the processor PROC2.
  • the processor PROC2 of the processing unit UT2 notably implements the steps of the method for controlling the execution of a function according to any one of the particular embodiments described in relation to FIG. 3, according to the instructions of the computer program PG2.
  • the DCE device also comprises communication modules COM21 and COM22 configured to establish communications with for example an IP network and / or circuit.
  • the communication module COM21 is used to receive requests for execution of a first function from a terminal and the module COM22 to send a response comprising an identifier of a second function registered in a chain of blocks. Note that the response can also include network parameters.
  • the DCE device further comprises an OBT2 module capable of publishing in the block chain data related to the reception and transmission steps of the method for controlling the execution of a function.
  • the modules COM21 and COM22 can be one and the same communication module (COM2).
  • the module COM2 is also able to send a request for authorization to use the first function by the terminal and to receive a response comprising an access parameter to the first function.
  • the OBT2 module can also be used to publish in the blockchain data related to the step of sending the request for authorization of use and to its execution according to an access parameter received in response to the request for authorization of use.
  • the first function can be executed by the DCE device and its processor PROC2 or via a dedicated module (not shown here).
  • the module COM2 can also send, to the terminal, a response to the execution request, the response possibly including data associated with the result of the execution of the first function.
  • the OBT2 module can also publish in the blockchain data such as the result of the execution of the first function, an identifier of the terminal or any other data relating to the data received and sent by the module COM2.
  • the requests received and sent by the DCE device are handled by the module COM2.
  • the DCE device can include several communication modules allowing the reception and / or transmission of requests.
  • the OBT2 module manages all the publications made at the blockchain level.
  • the DCE device can include several publication modules allowing publication and / or obtaining of publications at the blockchain level.
  • FIG. 3 consists of a TRM terminal such as for example a mobile terminal or a computer capable of sending and receiving requests to and from a block chain and DCE and DCA devices registered in a block chain and capable of executing decentralized functions or DApps in the sense of blockchain technology. These applications are in the form of executable code.
  • the DCE device executes a DApps comprising a function F1
  • the DCA device executes a DApps comprising the functions F2 and F3.
  • the TRM terminal sends a request for execution of the function F1 of the DApps to the DCE device.
  • the request comprises for example the identifier of the sending terminal and the identifier of the function F1.
  • the request can also include other data such as tokens, cryptographic keys allowing for example the DCE device to authenticate the TRM terminal or a user identifier that he has previously entered at the level of the TRM terminal via for example a dedicated user interface such as a voice or graphic interface.
  • a dedicated user interface such as a voice or graphic interface.
  • the DCE device On receipt of the request (El 1), the DCE device will process the request and generate a response comprising an identifier of a second function F2. The DCE device will then send this response (El 2) to the TRM terminal. Concretely, the DCE device realizes a redirection to an F2 function of a DApps executed by the DCA device.
  • the DCE device can also publish in the block chain information related to the reception and transmission steps such as the date and time of reception and transmission of requests, elements received or sent such as for example the identifier. of the terminal, or the result of processing carried out by the device.
  • the TRM terminal will generate a request for execution of the function F2 intended for the DCA device.
  • the request is sent to step E20 with for example the same data as the first request sent by the terminal TRM to step E10.
  • the request is then received, in step E21, by the DCA device that will perform the F2 function.
  • the result of the function F2 is for example a list of data pairs of which the first data of each pair is an identifier or a character string indicating a tariff option (ID PA) associated with the execution of the function F1 and the second data, an identifier of a third function (ID F3) associated with the tariff option.
  • ID PA tariff option
  • ID F3 a third function associated with the tariff option
  • the DCA device can also publish in the block chain information related to the reception and transmission steps such as the date and time of reception and transmission of requests, elements received or sent such as for example the identifier. of the terminal, the execution information of the function F2, or the result of the function F2.
  • This publication is called a "tariff publication”.
  • the DCA device may not need to perform function F2. This is the case, for example, if the list is static, that is to say that the tariff options remain unchanged for a fairly long period of time (ex: 1 week, 1 month, 1 year, etc.).
  • a tariff option can be associated with the execution of a function, for example Fl, or with several functions (Fil,
  • a tariff option may depend on the identifier of the terminal. This is the case, for example, when a price for the execution of the function Fl is negotiated by a company for its employees.
  • a tariff option may be associated with a validity period.
  • the user of the TRM terminal will then choose a tariff option from the list according to his needs.
  • the tariff option chosen will make it possible to specify the framework for executing the function Fl for the TRM terminal and its user.
  • the pricing options can for example determine:
  • a subscription that is to say unlimited use of the function F1 for a determined period.
  • a price based on a data external to the block chain such as an energy cost or data sent by an Oracle.
  • an Oracle is a service authorized to enter data into the blockchain at the request of a user.
  • the cost of use may for example vary depending on the duration of the time slot or depending on its start time.
  • the user can, for example, pay less for a time slot starting at night.
  • This makes it possible to encourage users of the Fl function to request its execution for a given period to take into account the load on the server.
  • it is possible to smooth the executions over time and therefore optimize the hardware architectures (memory, processors, etc.) of the servers.
  • the terminal will send a request to execute the F3 function to the DCA device.
  • Function F3 is for example a payment function associated with the chosen tariff option.
  • the DCA device will then execute (E25) the function F3 and proceed to payment using the payment parameters (PAY PARA) received previously.
  • the device can verify that the payment has indeed taken place thanks to the payment parameters (PAY PARA) received previously.
  • These settings can be banking information, proof of purchase information, or blockchain user account information to make or certify a payment.
  • the payment process can be done outside or inside the blockchain. In the event that payment is made outside of the blockchain, the DCA device will, for example, obtain proof of purchase from a third party to determine whether the payment has been made.
  • the payment process can correspond to a sequestration of an amount in anticipation of the execution of the function F1 by the user terminal. The amount is then released at the time of execution of the function Fl with the consequence of making the payment.
  • the DCA device can send a response (E26) to the TRM terminal comprising the result of the payment or its acceptance (PAY RESULT).
  • the result is for example a status concerning the act of payment (payment made or refused or pending) or any other data relating to the act of payment (date, status, transaction number, financial institution, etc.).
  • the DCA device can obtain from the block chain, via the data of the so-called tariff publication, the date on which the DCA device sent the tariff options of the F1 function to the TRM terminal. (E22).
  • the DCA device can verify that the offer is still valid before executing the function F3. This verification is conventionally carried out by comparing the date of receipt of the request E25 with that of the request E22 to which the period of validity is added. If the date of the request E25 is earlier then the tariff option is still valid and the DCA device can execute the function F3. Otherwise, an error message is sent to the TRM terminal, for example during step E26.
  • the DCA device can also publish in the blockchain information related to the reception (E25) and transmission (E26) steps such as the date and time of reception and transmission of requests, elements received or sent. such as for example the identifier of the terminal, the execution information of the function F3, or the result of the function F3.
  • This publication is called a “payment publication”.
  • step E30 the TRM terminal sends the request for execution of function F1 a second time to the DCE device.
  • the request can be enriched with respect to that sent in step E10 with additional data such as a payment transaction number or a counter value.
  • the DCE device On receipt of the request by the DCE device (E31), the latter will check whether this request for execution of the function F1 by the terminal TRM is not the first. For this, the DCE device can consult its history of received and transmitted requests in order to determine whether the request in question is the first. The device can also be based on parameters of the request such as the payment transaction number or the value of the counter. In the case of a counter value, it is the TRM terminal which will increment it during a new transmission of the request for execution of the function F1.
  • the DCE device goes to step E32 to issue a request for authorization to use the function F1 by the terminal TRM to the DCA device.
  • This request comprises for example the identifier of the terminal TRM (ID TRM) and the identifier of the function F1 (ID Fl).
  • the DCA device will then obtain, for example from a private memory, the status of the payment (result of execution of function F3 or proof of purchase) and deduce therefrom an access parameter to function F1 (PARAC) for the terminal TRM.
  • the access parameter can also be a function of other data such as the date or time if the tariff offer chosen by the user is a function of a time slot but also of a value of a counter indicating the number of executions already carried out of function F1 if the tariff offer chosen by the user is a function of a number of executions.
  • the DCA device can get the status of the payment from the blockchain. Obtaining this status can be done via the data of the so-called payment publication and the retrieval of a dedicated parameter or by retrieving the information concerning the execution of the payment function.
  • the PARAC parameter can for example be a Boolean which indicates, when it is for example set to 1 that the TRM terminal has the authorization to execute the Fl function.
  • the PARAC parameter can be a character string or any other set of data making it possible to provide a status on the authorization to execute the function F1 by the terminal TRM.
  • the PARAC parameter can for example be a boolean / character string pair in which the boolean gives information on the authorization to execute the function F1 by the terminal TRM and the character string represents a label such as a code error in the event that the authorization is refused.
  • step E34 the DCA device will return a response to the DCE device comprising the access parameter PARAC, the identifier of the TRM terminal (ID TRM) and the identifier of the function Fl (ID Fl).
  • the DCA device can also publish in the blockchain information related to the reception (E33) and transmission (E34) steps such as the date and time of reception and transmission of requests, elements received or sent.
  • the blockchain information related to the reception (E33) and transmission (E34) steps such as the date and time of reception and transmission of requests, elements received or sent.
  • the identifier of the terminal such as for example the identifier of the terminal, the access parameter PARAC, or the result of a processing carried out by the device.
  • the DCE device When the DCE device receives the response (E35), it will test (E37) the PARAC parameter. If the PARAC parameter indicates that the execution of the function F1 by the terminal TRM is not authorized, then the device DCE sends the parameter PARAC to the terminal TRM. The TRM terminal thus has the information that execution is not possible and the reason why execution cannot be carried out. Conversely, if the PARAC parameter indicates that the execution of the function F1 by the terminal TRM is authorized, then the device will execute the function F1 (E38) and send the result of the execution to the terminal TRM (E39).
  • the DCE device can also publish in the blockchain information related to the reception (E31 and E35) and transmission (E32, E36, E39) steps such as the date and time of reception and transmission of requests. , elements received or sent such as for example the identifier of the terminal, the access parameter PARAC, the execution information of the function F1 or the result of the execution of the function F1.
  • the function F1 can be executed outside the blockchain.
  • the DCE device will send the execution request to an external server via a dedicated blockchain interface.
  • the DCE and DCA devices can be one and the same computer machine executing several DApps implementing the functions F1, F2 and F3.
  • a request is sent from the DCE device to the DCA device comprising a parameter indicating that the execution of the function Fi has failed, the identifier of the terminal TRM and the identifier of the function Fl.
  • the DCA device can then perform by example a partial or total reimbursement of the sum previously paid in step E25.
  • the user can, via his TRM terminal and before step E10, consult a directory of functions in order to choose the function F1 to be executed.
  • the directory can for example be represented at the terminal level in the form of a list of functions or a table of functions with for example a description, the name of the developer and a note for each function, the note being for example the result of an average of the scores given by the users weighted by the availability rate of the function.
  • the directory can for example be retrieved in response to a request sent by the TRM terminal to a DApps registered in a blockchain.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé de contrôle d'accès à une fonction d'une application mis en œuvre par un dispositif de contrôle d'accès à une fonction d'une application, ce dispositif de contrôle étant inscrit à une chaîne de blocs, le procédé étant caractérisé en ce qu'il comprend : - une étape de réception, en provenance d'un premier terminal, d'une première requête d'accès à au moins une première fonction de l'application, ladite application étant inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction et au moins un identifiant dudit premier terminal; - une étape d'émission d'une réponse à la requête d'accès comprenant au moins un paramètre d'accès à ladite au moins une première fonction et au moins un second identifiant d'au moins une seconde fonction inscrite dans ladite chaîne de blocs, ledit au moins un second identifiant étant associé audit au moins un paramètre.

Description

DESCRIPTION
Titre : Procédé et dispositif de contrôle d’accès à une fonction d’une application inscrite dans une chaîne de blocs.
1. Domaine de l'invention
L’invention se rapporte au domaine général des réseaux de télécommunications, et plus précisément à la technologie des chaînes de blocs (en anglais « blockchain »).
2. Art Antérieur
De façon traditionnelle, les chaînes de blocs gèrent des crypto-monnaies (monnaie émise de pair à pair sans intervention d’une banque centrale). On peut citer par exemple la monnaie électronique décentralisée Bitcoin créée en 2009. Cependant, de nouveaux types de chaînes de blocs ont émergé proposant un champ d’applications plus large. C’est par exemple le cas d’Ethereum qui permet l’enregistrement d’applications décentralisées appelées DApps (Decentralized Applications en anglais). Concrètement, chaque application décentralisée présente au sein de la chaîne de blocs est composée d’un code binaire et d’une interface exposant des méthodes pouvant être appelées, par exemple par un tiers ou par d’autres applications. Une DApps dispose également d’une zone de données privée qu’elle va pouvoir modifier en fonction des traitements effectués.
Le modèle économique d’une telle chaîne de blocs est essentiellement axé sur l’acte de déploiement de l’application. Il faut « payer » pour déployer l’application, c’est-à-dire rétribuer les personnes qui valident l’application et qui créent le bloc associé à la validation au niveau de la chaîne de blocs. De plus, les personnes qui souhaitent utiliser l’application, par exemple via l’envoi d’une demande de réalisation d’une tâche particulière, doivent également payer à chaque utilisation en fonction d’un algorithme prédéterminé.
Force est de constater qu’il n’est actuellement pas possible, lorsqu’un tiers souhaite utiliser une application décentralisée, d’adapter et de personnaliser la rétribution du fournisseur de l’application en fonction de son utilisation. En effet, ces méthodes de rémunération restent très simples et ne permettent pas à un fournisseur d’établir des règles d’utilisation de ses applications décentralisées avec des coûts associés. 3. Exposé de l'invention
L’invention vient améliorer l’état de la technique et propose un procédé de contrôle d’accès à une fonction d’une application mis en œuvre par un dispositif de contrôle d’accès à une fonction d’une application, ce dispositif de contrôle étant inscrit à une chaîne de blocs, le procédé étant caractérisé en ce qu’il comprend :
- une étape de réception, en provenance d’un premier terminal, d’une première requête d’accès à au moins une première fonction de l’application, ladite application étant inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction et au moins un identifiant dudit premier terminal ;
- une étape d’émission d’une réponse à la requête d’accès comprenant au moins un paramètre d’accès à ladite au moins une première fonction et au moins un second identifiant d’au moins une seconde fonction inscrite dans ladite chaîne de blocs, ledit au moins un second identifiant étant associé audit au moins un paramètre.
Ainsi, l’invention propose d’utiliser une chaîne de blocs pour gérer l’accès à une application inscrite dans une chaîne de blocs et plus précisément à sa ou ses fonctions. La présente demande est présentée dans le contexte d’une « chaîne de blocs » en anglais « blockchain » mais l’expression « chaîne de blocs » est à comprendre comme couvrant tout type de DLT (en anglais Distributed Ledger Technology) apte à héberger des applications décentralisées connues sous le nom de DApp (Decentralized Applications en anglais) dont les chaînes de blocs à proprement parler constituent un élément particulier.
Comme indiqué dans le document (https://fr.wikipedia.org/wiki/Blockchain), on rappelle que la technologie des chaînes de blocs est une technologie de stockage et de transmission d'informations sans organe de contrôle. Techniquement, il s'agit d'une base de données distribuée dont les informations envoyées par les utilisateurs et les liens internes à la base sont vérifiés et groupés à intervalles de temps réguliers en blocs, l'ensemble étant sécurisé par cryptographie, et formant ainsi une chaîne. Par extension, une chaîne de blocs est une base de données distribuée qui gère une liste d'enregistrements protégés contre la falsification ou la modification par les nœuds de stockage ; c'est donc un registre distribué et sécurisé de toutes les transactions effectuées depuis le démarrage du système. Les chaînes de blocs sont notamment caractérisées en ce que leurs contenus ne peuvent pas être modifiés ou supprimés : une information publiée (c’est-à-dire enregistrée ou sauvegardée) dans une chaîne de blocs le reste pour toujours.
D’un point de vue pratique, l’invention offre un nouveau mécanisme dans lequel, lorsqu’une requête d’accès à une fonction d’une application inscrite dans une chaîne de blocs est envoyée par un terminal utilisateur, le dispositif exécutant le procédé de contrôle d’accès renvoie alors une réponse avec un paramètre d’accès associé à la fonction, comme par exemple une option tarifaire et un identifiant d’une deuxième fonction, telle qu’une fonction de paiement associée à l’option.
Avantageusement, ce mode de réalisation permet de préciser à un utilisateur les conditions d’accès et d’utilisation d’une fonction inscrite dans une chaîne de blocs.
On entend par fonction une portion de code informatique représentant un sous-programme informatique, qui effectue une tâche ou un calcul particulier. L’identifiant de la fonction est par exemple le nom donné par le programmeur lors de sa création ou la signature de la fonction incluant des paramètres.
On entend par identifiant d’un terminal, une suite de caractères qui permet d’identifier de manière unique le terminal tel qu’une adresse MAC, une adresse IP, un numéro de série (ex : un IMEI) ou une clé cryptographique. Alternativement, l’identifiant du terminal peut également être un identifiant de l’utilisateur renseigné par celui-ci via une interface utilisateur du terminal telle qu’une interface graphique ou vocale, et permettant d’identifier de manière unique l’utilisateur du terminal. L’identifiant peut par exemple être une adresse de messagerie, un numéro de carte d’identité, un numéro d’abonné, etc.
Selon un mode de réalisation particulier de l’invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape d’émission est suivie d’une première étape de publication dans ladite chaîne de blocs, dudit identifiant dudit premier terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission. Cette publication dans la chaîne de blocs est réalisée pour stocker et partager des informations liées aux étapes de réception et d’émission telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, ou encore le résultat d’un traitement réalisé par le dispositif. Selon un mode de réalisation particulier de l’invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape d’émission est suivie :
- d’une deuxième étape de réception, en provenance d’au moins un second terminal, d’une requête d’exécution de ladite au moins une seconde fonction, ladite requête d’exécution comprenant au moins ledit identifiant dudit premier terminal ;
- d’une étape d’exécution de ladite au moins une seconde fonction ;
- d’une deuxième étape de publication dans la chaîne de blocs, dite publication de paiement, dudit identifiant dudit premier terminal, d’au moins une donnée associée à ladite deuxième étape de réception et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une seconde fonction.
Avantageusement, ce mode de réalisation permet à l’utilisateur d’exécuter la deuxième fonction comme par exemple une fonction de paiement permettant l’utilisation de la première fonction. Une publication dans la chaîne de blocs est également réalisée pour stocker et partager le résultat de l’exécution de la deuxième fonction. Les informations publiées peuvent par exemple être le statut d’un paiement, des informations liées à la requête d’exécution de la seconde fonction telles que l’identifiant du terminal et/ou de l’utilisateur ou bien toute autre information associée à l’exécution de la seconde fonction.
Selon une première variante de ce mode particulier de réalisation de l’invention, un procédé tel que décrit ci-dessus est caractérisé en ce que la deuxième étape de publication est suivie d’une deuxième étape d’émission d’une réponse à la requête d’exécution comportant au moins une donnée associée au résultat de l’exécution de ladite au moins une seconde fonction.
Avantageusement, ce mode de réalisation permet à l’utilisateur d’avoir de l’information sur l’exécution de la seconde fonction et son résultat. Dans le cas où la deuxième fonction est une fonction de paiement, l’utilisateur aura ainsi par exemple l’information sur le statut du paiement (accepté, refusé ou en attente) ou son numéro de transaction. Selon une deuxième variante de ce mode particulier de réalisation de l’invention, un procédé tel que décrit ci-dessus est caractérisé en ce que la deuxième étape de publication est suivie :
- d’une troisième étape de réception, en provenance de ladite application, d’une requête d’autorisation d’utilisation par ledit premier terminal de ladite au moins une première fonction, ladite requête d’autorisation comprenant au moins ledit identifiant dudit premier terminal et au moins ledit premier identifiant de ladite au moins une première fonction ;
- d’une étape d’obtention depuis ladite chaîne de blocs, en fonction dudit identifiant dudit premier terminal, des données publiées via ladite publication de paiement ;
- d’une troisième étape d’émission d’une réponse à la requête d’autorisation comprenant au moins un second paramètre d’accès à ladite au moins une première fonction, ledit paramètre d’accès étant fonction du résultat de l’exécution de ladite au moins une seconde fonction obtenu via les données de ladite publication de paiement ;
- d’une troisième étape de publication, dans la chaîne de blocs, dudit au moins un second paramètre d’accès et de l’identifiant dudit premier terminal.
Avantageusement, ce mode de réalisation permet de vérifier que l’utilisateur a bien le droit d’accéder à la première fonction. L’application va alors vérifier que la deuxième fonction a bien été exécutée par le terminal de l’utilisateur et que le résultat est bien conforme à ce qui est attendu. Par exemple, l’application va vérifier qu’un paiement a bien été effectué par l’utilisateur (exécution de la deuxième fonction) et que le paiement a été validé (résultat conforme) avant de donner l’accès à la première fonction.
Procédé de contrôle de l’exécution d’une fonction d’une application mis en œuvre par un dispositif de contrôle de l’exécution d’une fonction d’une application, ce dispositif de contrôle étant inscrit à une chaîne de blocs, le procédé étant caractérisé en ce qu’il comprend :
- une étape de réception, en provenance d’un terminal, d’une première requête d’exécution d’au moins une première fonction d’une application inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction et au moins un identifiant dudit terminal ;
- une étape d’émission d’une réponse à la requête d’exécution comprenant au moins un second identifiant d’au moins une seconde fonction inscrite dans ladite chaîne de blocs. Avantageusement, ce mode de réalisation permet, lorsqu’une première requête d’exécution à une première fonction d’une application inscrite dans une chaîne de blocs est envoyée par un terminal utilisateur, de renvoyer une réponse avec un identifiant d’une seconde fonction comme par exemple une fonction qui va permettre de donner de l’information complémentaire à l’utilisateur sur la première fonction.
Selon un mode de réalisation particulier de l’invention, un procédé de contrôle de l’exécution d’une fonction d’une application tel que décrit ci-dessus est caractérisé en ce que l’étape d’émission est suivie d’une première étape de publication dans la chaîne de blocs, dudit identifiant dudit terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission.
Cette publication dans la chaîne de blocs est réalisée à la suite de l’étape d’émission de la réponse à la requête d’exécution pour stocker et partager des informations liées aux étapes de réception et d’émission telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, ou encore le résultat d’un traitement réalisé par le dispositif
Selon un mode de réalisation particulier de l’invention, un procédé de contrôle de l’exécution d’une fonction d’une application tel que décrit ci-dessus est caractérisé en ce que l’étape d’émission est suivie :
- d’une deuxième étape de réception, en provenance dudit terminal, d’une deuxième requête d’exécution de ladite au moins une première fonction, ladite deuxième requête d’exécution comprenant au moins ledit premier identifiant de ladite au moins une première fonction et au moins ledit identifiant dudit terminal ;
- d’une deuxième étape d’émission, d’une requête d’autorisation d’exécution, pour ledit terminal, de ladite au moins une première fonction, ladite requête d’autorisation comprenant au moins ledit identifiant dudit terminal et au moins ledit premier identifiant de ladite au moins une première fonction ;
- d’une troisième étape de réception d’une réponse à la requête d’autorisation comprenant au moins un paramètre d’accès à ladite au moins une première fonction pour ledit terminal ;
- d’une étape d’exécution de ladite au moins une première fonction en fonction dudit au moins un paramètre d’accès reçu ; - d’une deuxième étape de publication dans la chaîne de blocs, dudit au moins un paramètre d’accès, dudit identifiant dudit terminal et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une première fonction.
Avantageusement, ce mode de réalisation permet, lorsqu’une deuxième requête d’exécution à une première fonction d’une application inscrite dans une chaîne de blocs est envoyée par un terminal utilisateur, d’émettre une requête de demande d’autorisation d’utilisation et d’obtenir en retour un paramètre d’accès à la première fonction pour le terminal utilisateur. L’exécution de la fonction est alors fonction du paramètre d’accès.
Une publication dans la chaîne de blocs est également réalisée pour stocker et partager des informations liées aux étapes de réception, d’émission et d’exécution telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple le paramètre d’accès, ou encore le résultat d’un traitement réalisé par le dispositif.
Selon un mode de réalisation particulier de l’invention, un procédé de contrôle de l’exécution d’une fonction d’une application tel que décrit ci-dessus est caractérisé en ce que la deuxième étape de publication est suivie d’une troisième étape d’émission d’une réponse à la deuxième requête d’exécution comprenant au moins une donnée associée au résultat de l’exécution de ladite au moins une première fonction.
Avantageusement, ce mode de réalisation permet à l’utilisateur d’avoir de l’information sur l’exécution de la première fonction et de son résultat.
L’invention concerne également un dispositif de contrôle d’accès à une fonction d’une application, ledit dispositif de contrôle étant inscrit à une chaîne de blocs et comprenant :
- un module de réception d’une première requête d’accès, en provenance d’un premier terminal, à au moins une première fonction de l’application, ladite application étant inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction et au moins un identifiant dudit premier terminal ;
- un module d’émission d’une réponse à la requête d’accès comprenant au moins un paramètre d’accès à ladite au moins une première fonction et au moins un second identifiant d’au moins une seconde fonction inscrite dans ladite chaîne de blocs, ledit au moins un second identifiant étant associé audit au moins un paramètre ;
- un module de publication dans ladite chaîne de blocs, dudit identifiant dudit premier terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission.
Selon un mode de réalisation particulier de l’invention, un dispositif de contrôle d’accès à une fonction d’une application tel que décrit ci-dessus est caractérisé en ce qu’il comporte en outre :
- un deuxième module de réception d’une requête d’exécution, en provenance d’au moins un second terminal, de ladite au moins une seconde fonction, ladite requête d’exécution comprenant au moins ledit identifiant dudit premier terminal ;
- un module d’exécution de ladite au moins une seconde fonction ;
- un deuxième module de publication dans la chaîne de blocs, d’une publication dite de paiement, dudit identifiant dudit premier terminal, d’au moins une donnée associée à ladite deuxième étape de réception et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une seconde fonction.
Selon un mode de réalisation particulier de l’invention, un dispositif de contrôle d’accès à une fonction d’une application tel que décrit ci-dessus est caractérisé en ce qu’il comporte en outre :
- un troisième module de réception, d’une requête d’autorisation d’utilisation par ledit premier terminal de ladite au moins une première fonction, ladite requête étant en provenance de ladite application et comprenant au moins ledit identifiant dudit premier terminal et au moins ledit premier identifiant de ladite au moins une première fonction ;
- un module d’obtention depuis ladite chaîne de blocs, en fonction dudit identifiant dudit premier terminal, des données publiées via ladite publication de paiement ;
- un troisième module d’émission d’une réponse à la requête d’autorisation comprenant au moins un second paramètre d’accès à ladite au moins une première fonction, ledit paramètre d’accès étant fonction du résultat de l’exécution de ladite au moins une seconde fonction obtenu dans les données de ladite publication de paiement ; - un troisième module de publication, dans la chaîne de blocs, dudit au moins un second paramètre d’accès et dudit identifiant dudit premier terminal.
L’invention concerne également un dispositif de contrôle de l’exécution d’une fonction d’une application, ledit dispositif de contrôle étant inscrit à une chaîne de blocs et comprenant :
- un module de réception d’une première requête d’exécution, en provenance d’un terminal, d’au moins une première fonction d’une application inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction et au moins un identifiant dudit terminal ;
- un module d’émission d’une réponse à la requête d’exécution comprenant au moins un second identifiant d’au moins une seconde fonction inscrite dans ladite chaîne de blocs ;
- un module de publication, dans une chaîne de blocs, dudit identifiant dudit terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission.
Selon un mode de réalisation particulier de l’invention, un dispositif de contrôle de l’exécution d’une fonction d’une application tel que décrit ci-dessus est caractérisé en ce qu’il comporte en outre :
- un deuxième module de réception d’une deuxième requête d’exécution, en provenance dudit terminal, de ladite au moins une première fonction, ladite deuxième requête d’exécution comprenant au moins ledit premier identifiant de ladite au moins une première fonction et au moins ledit identifiant dudit terminal ;
- un deuxième module d’émission, d’une requête d’autorisation d’exécution, pour ledit terminal, de ladite au moins une première fonction, ladite requête d’autorisation comprenant au moins ledit identifiant dudit terminal et au moins ledit premier identifiant de ladite au moins une première fonction ;
- un troisième module de réception d’une réponse à la requête d’autorisation comprenant au moins un paramètre d’accès à ladite au moins une première fonction pour ledit terminal ;
- un module d’exécution de ladite au moins une première fonction en fonction dudit au moins un paramètre d’accès reçu ; - un deuxième module de publication dans la chaîne de blocs, dudit au moins un paramètre d’accès, dudit identifiant dudit terminal et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une première fonction.
Le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre de l’un ou l’autre des procédés définis ci-dessus selon l’un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Le procédé peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L’invention vise aussi un support d’enregistrement ou support d’informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci- dessus. Les supports d’enregistrement mentionnés ci-avant peuvent être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D’autre part, les supports d’enregistrement peuvent correspondre à un support transmissible tel qu’un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d’autres moyens. Les programmes selon l’invention peuvent être en particulier téléchargés sur un réseau de type Internet. Alternativement, les supports d’enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution du procédé en question.
Ces dispositifs de contrôle d’accès à une fonction d’une application, de contrôle de l’exécution d’une fonction d’une application et ces programmes d’ordinateur présentent des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec les procédés de contrôle d’accès à une fonction d’une application et de contrôle de l’exécution d’une fonction d’une application.
4. Liste des figures
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
[Fig 1] La figure 1 représente l’architecture matérielle d’un dispositif de contrôle d’accès à une fonction selon un mode particulier de réalisation ;
[Fig 2] La figure 2 représente l’architecture matérielle d’un dispositif de contrôle de l’exécution d’une fonction selon un mode particulier de réalisation ;
[Fig 3] La figure 3 représente sous forme d’organigramme les principales étapes d’un procédé de contrôle d’accès à une fonction et les principales étapes d’un procédé de contrôle de l’exécution d’une fonction conformes aux modes de réalisation de l’invention.
5. Description d'un mode de réalisation de l'invention
La figure 1 représente l’architecture matérielle d’un dispositif de contrôle d’accès DCA à une fonction conforme à l’invention. Dans le mode de réalisation décrit ici, ce dispositif a l’architecture matérielle d’un ordinateur. Il comprend notamment un processeur PROC1, une mémoire vive MV1, une mémoire morte MEM1 et une mémoire flash non volatile MF1. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici. La mémoire morte constitue un support d’enregistrement conforme à Finvention, lisible par le processeur PROC1 et sur lequel est enregistré ici un programme d’ordinateur PG1 conforme à Finvention, ce programme comportant des instructions pour mettre en œuvre les étapes du procédé de contrôle d’accès à une fonction tel que décrit précédemment, lorsque le programme est exécuté par le processeur PROC1.
A l'initialisation, les instructions de code du programme d'ordinateur PG1 sont par exemple chargées dans une mémoire avant d’être exécutées par le processeur PROC1. Le processeur PROC1 de l'unité de traitement UT1 met notamment en œuvre les étapes du procédé de contrôle d’accès à une fonction selon l’un quelconque des modes particuliers de réalisation décrits en relation avec la figure 3, selon les instructions du programme d’ordinateur PG1.
Le dispositif DCA comprend également des modules de communication COM 11 et COM 12 configuré pour établir des communications avec par exemple un réseau IP et/ou circuit. Le module de communication COM11 est utilisé pour recevoir des requêtes d’accès à une première fonction en provenance d’un terminal et le module COM 12 pour émettre une réponse comprenant des paramètres d’accès et un identifiant d’une deuxième fonction associés à la première fonction. Le dispositif DCA comprend de plus un module OBT1 apte à publier dans la chaîne de blocs des données liées aux étapes de réception et d’émission du procédé de contrôle d’accès à une fonction.
Selon un mode particulier de réalisation de l’invention, les modules COM11 et COM12 peuvent être un seul et même module (COM1) de communication.
Selon un mode particulier de réalisation de l’invention, le module COM1 est également apte à recevoir des requêtes d’exécution de la deuxième fonction et le module OBT1 apte à publier dans la chaîne de blocs des données liées à l’étape de réception d’une requête d’exécution et à son exécution. La deuxième fonction pouvant être exécutée par le dispositif DCA et son processeur PROC1 ou via un module dédié (non représenté ici).
Selon un mode particulier de réalisation de l’invention, le module COM1 peut aussi être utilisé pour émettre une réponse à la requête d’exécution avec des données concernant le résultat de l’exécution de la deuxième fonction.
Selon un mode particulier de réalisation de l’invention, le module COM1 peut de plus recevoir des requêtes de demande d’autorisation concernant l’utilisation de la première fonction et émettre une réponse comprenant un deuxième paramètre d’accès en fonction d’une publication obtenue depuis la chaîne de blocs via le module OBT1. Le module OBT1 peut de plus publier dans la chaîne de blocs des données telles que le second paramètre, un identifiant du terminal ou toute autre donnée relative aux données reçues et émises par le module COM1. A noter que dans le mode de réalisation décrit ci-dessus, les requêtes reçues et émises par le dispositif DCA sont prises en charge par le module COM1. Alternativement le dispositif DCA peut comprendre plusieurs modules de communication permettant la réception et/ou l’émission des requêtes.
De même, dans le mode de réalisation décrit ci-dessus, le module OBT1 gère l’ensemble des publications réalisées au niveau de la chaîne de blocs. Alternativement, le dispositif DCA peut comprendre plusieurs modules de publication permettant la publication et/ou l’obtention des publications au niveau de la chaîne de blocs.
La figure 2 représente l’architecture matérielle d’un dispositif de contrôle DCE de l’exécution d’une fonction conforme à l’invention. Dans le mode de réalisation décrit ici, ce dispositif a l’architecture matérielle d’un ordinateur. Il comprend notamment un processeur PROC2, une mémoire vive MV2, une mémoire morte MEM2 et une mémoire flash non volatile MF2. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici. La mémoire morte constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC2 et sur lequel est enregistré ici un programme d’ordinateur PG2 conforme à l’invention, ce programme comportant des instructions pour mettre en œuvre les étapes du procédé de contrôle de l’exécution d’une fonction tel que décrit précédemment, lorsque le programme est exécuté par le processeur PROC2.
A l'initialisation, les instructions de code du programme d'ordinateur PG2 sont par exemple chargées dans une mémoire avant d’être exécutées par le processeur PROC2. Le processeur PROC2 de l'unité de traitement UT2 met notamment en œuvre les étapes du procédé de contrôle de l’exécution d’une fonction selon l’un quelconque des modes particuliers de réalisation décrits en relation avec la figure 3, selon les instructions du programme d'ordinateur PG2.
Le dispositif DCE comprend également des modules de communication COM21 et COM22 configuré pour établir des communications avec par exemple un réseau IP et/ou circuit. Le module de communication COM21 est utilisé pour recevoir des requêtes d’exécution d’une première fonction en provenance d’un terminal et le module COM22 émettre une réponse comprenant un identifiant d’une deuxième fonction inscrite dans une chaîne de blocs. A noter que la réponse peut également comprendre des paramètres réseaux. Le dispositif DCE comprend de plus un module OBT2 apte à publier dans la chaîne de blocs des données liées aux étapes de réception et d’émission du procédé de contrôle de l’exécution d’une fonction.
Selon un mode particulier de réalisation de l’invention, les modules COM21 et COM22 peuvent être un seul et même module (COM2) de communication.
Selon un mode particulier de réalisation de l’invention, le module COM2 est également apte à émettre une requête d’autorisation d’utilisation de la première fonction par le terminal et à recevoir une réponse comprenant un paramètre d’accès à la première fonction. Le module OBT2 peut aussi être utilisé pour publier dans la chaîne de blocs des données liées à l’étape d’envoi de la requête d’autorisation d’utilisation et à son exécution en fonction d’un paramètre d’accès reçu en réponse à la requête d’autorisation d’utilisation. La première fonction pouvant être exécutée par le dispositif DCE et son processeur PROC2 ou via un module dédié (non représenté ici).
Selon un mode particulier de réalisation de l’invention, le module COM2 peut également émettre, à destination du terminal, une réponse à la requête d’exécution, la réponse pouvant comprendre une donnée associée au résultat de l’exécution de la première fonction. Le module OBT2 peut de plus publier dans la chaîne de blocs des données telles que le résultat de l’exécution de la première fonction, un identifiant du terminal ou toute autre donnée relative aux données reçues et émises par le module COM2.
A noter que dans le mode de réalisation décrit ci-dessus, les requêtes reçues et émises par le dispositif DCE sont prises en charge par le module COM2. Alternativement le dispositif DCE peut comprendre plusieurs modules de communication permettant la réception et/ou l’émission des requêtes.
De même, dans le mode de réalisation décrit ci-dessus, le module OBT2 gère l’ensemble des publications réalisées au niveau de la chaîne de blocs. Alternativement, le dispositif DCE peut comprendre plusieurs modules de publication permettant la publication et/ou l’obtention des publications au niveau de la chaîne de blocs.
En référence à la figure 3, nous allons maintenant décrire : les principales étapes E21, E22, E25, E26, E33 et E34 d’un procédé de contrôle d’accès à une fonction d’une application ; les principales étapes Eli, E12, E31, E32, E35, E37, E38 et E39 d’un procédé de contrôle de l’exécution d’une fonction d’une application.
La figure 3 est constitué d’un terminal TRM comme par exemple un terminal mobile ou un ordinateur apte à émettre et recevoir des requêtes vers et depuis une chaîne de blocs et des dispositifs DCE et DCA inscrits à une chaîne de blocs et aptes à exécuter des fonctions décentralisées ou DApps au sens de la technologie des chaînes de blocs. Ces applications se présentent sous la forme d’un code exécutable. Dans le cas décrit à l’appui de la figure 3 le dispositif DCE exécute une DApps comprenant une fonction Fl et le dispositif DCA exécute une DApps comprenant les fonctions F2 et F3.
Au cours d’une première étape E10, le terminal TRM envoie une requête d’exécution de la fonction Fl de la DApps au dispositif DCE. La requête comprend par exemple l’identifiant du terminal émetteur et l’identifiant de la fonction Fl. La requête peut aussi comprendre d’autres données comme des jetons, des clés cryptographiques permettant par exemple au dispositif DCE d’authentifier le terminal TRM ou un identifiant de l’utilisateur qu’il a préalablement renseigné au niveau du terminal TRM via par exemple une interface utilisateur dédiée telle qu’une interface vocale ou graphique. Bien évidement il est supposé que le terminal TRM et son utilisateur sont déjà connus et enregistrés au sein de la chaîne de blocs.
A la réception de la requête (El 1) le dispositif DCE va traiter la demande et générer une réponse comprenant un identifiant d’une seconde fonction F2. Le dispositif DCE va ensuite envoyer cette réponse (El 2) au terminal TRM. Concrètement, le dispositif DCE réalise une redirection vers une fonction F2 d’une DApps exécutée par le dispositif DCA. Le dispositif DCE peut également publier dans la chaîne de blocs des informations liées aux étapes de réception et d’émission telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, ou encore le résultat d’un traitement réalisé par le dispositif.
Une fois la réponse (El 3) à sa première requête reçue, le terminal TRM va générer une requête d’exécution de la fonction F2 à destination du dispositif DCA. La requête est envoyée à l’étape E20 avec par exemple les mêmes données que la première requête envoyée par le terminal TRM à l’étape E10. La requête est alors reçue, à l’étape E21, par le dispositif DCA qui va exécuter la fonction F2. Le résultat de la fonction F2 est par exemple une liste de couples de données dont la première donnée de chaque couple est un identifiant ou une chaîne de caractère indiquant une option tarifaire (ID PA) associé à l’exécution de la fonction Fl et la deuxième donnée, un identifiant d’une troisième fonction (ID F3) associée à l’option tarifaire. Le résultat de l’exécution de la fonction F2 est ensuite envoyé par le dispositif DCA (E22) puis reçu par le terminal TRM à l’étape E23.
Le dispositif DCA peut également publier dans la chaîne de blocs des informations liées aux étapes de réception et d’émission telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, les informations d’exécution de la fonction F2, ou encore le résultat de la fonction F2. Cette publication est appelée « publication tarifaire ».
Alternativement, à l’étape E21, le dispositif DCA peut ne pas avoir besoin d’exécuter la fonction F2. C’est par exemple le cas si la liste est statique, c’est-à-dire que les options tarifaires restent inchangées pendant un laps de temps assez long (ex : 1 semaine, 1 mois, 1 an, etc.).
Selon un mode particulier de réalisation de l’invention, une option tarifaire peut être associée à l’exécution d’une fonction, par exemple Fl, ou à plusieurs fonctions (Fil,
F12,..., Fin).
Selon un mode particulier de réalisation de l’invention, une option tarifaire peut être fonction de l’identifiant du terminal. C’est par exemple le cas lorsqu’un prix à l’exécution de la fonction Fl est négocié par une entreprise pour ses salariés.
Selon un mode particulier de réalisation de l’invention, une option tarifaire peut être associée à un délai de validité.
L’utilisateur du terminal TRM va ensuite choisir une option tarifaire dans la liste en fonction de ses besoins. L’option tarifaire choisie va permettre de préciser le cadre d’exécution de la fonction Fl pour le terminal TRM et son utilisateur. Les options tarifaires peuvent par exemple déterminer :
- un prix en fonction d’un quota d’exécution de la fonction Fl ;
- un prix en fonction d’une plage horaire pendant laquelle il est possible d’exécuter la fonction Fl ;
- un abonnement c’est-à-dire une utilisation illimitée de la fonction Fl pour une durée déterminée. - un prix en fonction d’une donnée extérieur à la chaîne de bloc telle qu’un coût énergétique ou des données émises par un Oracle. On rappelle qu’un Oracle est un service autorisé à entrer une donnée dans la chaîne de blocs à la demande d’un utilisateur.
Dans le cas d’une plage horaire, le coût d’utilisation peut par exemple varier en fonction de la durée de la plage horaire ou en fonction de son heure de début. L’utilisateur peut par exemple payer moins cher pour une plage horaire débutant la nuit. Cela permet d’inciter les utilisateurs de la fonction Fl à demander son exécution pendant une période donnée pour tenir compte de la charge du serveur. Ainsi, il est possible de lisser dans le temps les exécutions et par conséquent d’optimiser les architectures matérielles (mémoire, processeurs, etc.) des serveurs.
Une fois l’option choisie par l’utilisateur (E24), le terminal va envoyer une requête d’exécution de la fonction F3 au dispositif DCA. La Fonction F3 est par exemple une fonction de paiement associée à l’option tarifaire choisie. Le dispositif DCA va alors exécuter (E25) la fonction F3 et procéder au paiement grâce aux paramètres de paiement (PAY PARA) reçus précédemment. Alternativement, dans le cas où le paiement est fait à priori, le dispositif peut vérifier que le paiement a bien eu lieu grâce aux paramètres de paiement (PAY PARA) reçus précédemment. Ces paramètres peuvent être des informations bancaires, des informations liées à une preuve d’achat ou des informations liées au compte de l’utilisateur de la chaîne de blocs permettant d’effectuer ou d’attester un paiement. Le processus de paiement peut être réalisé en dehors de la chaîne de blocs ou bien en son sein. Dans le cas où le paiement est fait en dehors de la chaîne de blocs, le dispositif DCA va par exemple obtenir une preuve d’achat auprès d’un tiers pour déterminer si le paiement a bien été réalisé.
Alternativement, le processus de paiement peut correspondre à une mise sous séquestre d’une somme en prévision de l’exécution de la fonction Fl par le terminal utilisateur. La somme est alors débloquée au moment de l’exécution de la fonction Fl avec pour conséquence la réalisation du paiement.
Selon un mode particulier de réalisation de l’invention, le dispositif DCA peut envoyer une réponse (E26) au terminal TRM comprenant le résultat du paiement ou son acceptation (PAY RESULT). Le résultat est par exemple un statut concernant l’acte de paiement (paiement effectué ou refusé ou en attente) ou bien toute autre donnée relative à l’acte de paiement (date, statut, numéro de transaction, établissement financier, etc.). Selon un mode particulier de réalisation de l’invention, le dispositif DCA peut obtenir depuis la chaîne de blocs, via les données de la publication dite tarifaire, la date à laquelle le dispositif DCA a envoyé au terminal TRM les options tarifaires de la fonction Fl (E22). Ainsi, dans le cas où l’option tarifaire choisie par le terminal TRM est associée à une durée de validité (par exemple 2 jours), le dispositif DCA peut vérifier que l’offre est toujours valide avant d’exécuter la fonction F3. Cette vérification est classiquement effectuée en comparant la date de réception de la requête E25 avec celle de la requête E22 à laquelle on ajoute la durée de validité. Si la date de la requête E25 est antérieure alors l’option tarifaire est toujours valide et le dispositif DCA peut exécuter la fonction F3. Dans le cas contraire un message d’erreur est envoyé au terminal TRM, par exemple lors de l’étape E26.
Le dispositif DCA peut également publier dans la chaîne de blocs des informations liées aux étapes de réception (E25) et d’émission (E26) telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, les informations d’exécution de la fonction F3, ou encore le résultat de la fonction F3. Cette publication est appelée « publication de paiement ».
A l’étape E30 le terminal TRM émet une deuxième fois la requête de demande d’exécution de la fonction Fl à destination du dispositif DCE. La requête peut être enrichie par rapport à celle émise à l’étape E10 de données supplémentaires telles qu’un numéro de transaction de paiement ou une valeur de compteur. A la réception de la requête par le dispositif DCE (E31), celui-ci va vérifier si cette requête de demande d’exécution de la fonction Fl par le terminal TRM n’est pas la première. Pour cela le dispositif DCE peut consulter son historique de requêtes reçues et émises afin de déterminer si la requête en question est la première. Le dispositif peut aussi se baser sur des paramètres de la requête tels que le numéro de transaction de paiement ou la valeur du compteur. Dans le cas d’une valeur de compteur, c’est le terminal TRM qui va venir l’incrémenter lors d’une nouvelle émission de la requête de demande d’exécution de la fonction Fl.
Dans le cas où la requête ne serait pas la première, le dispositif DCE va à l’étape E32 émettre une demande d’autorisation d’utilisation de la fonction Fl par le terminal TRM à destination du dispositif DCA. Cette requête comprend par exemple l’identifiant du terminal TRM (ID TRM) et l’identifiant de la fonction Fl (ID Fl). Le dispositif DCA va alors obtenir, par exemple depuis une mémoire privée, le statut du paiement (résultat de l’exécution de la fonction F3 ou une preuve d’achat) et en déduire un paramètre d’accès à la fonction Fl (PARAC) pour le terminal TRM.
Le paramètre d’accès peut également être fonction d’autres données telles que la date ou l’heure si l’offre tarifaire choisie par l’utilisateur est fonction d’une plage horaire mais aussi d’une valeur d’un compteur indiquant le nombre d’exécutions déjà effectuées de la fonction Fl si l’offre tarifaire choisie par l’utilisateur est fonction d’un nombre d’exécutions. Alternativement, le dispositif DCA peut obtenir le statut du paiement depuis la chaîne de blocs. L’obtention de ce statut peut se faire via les données de la publication dite de paiement et la récupération d’un paramètre dédié ou bien en reprenant les informations concernant l’exécution de la fonction de paiement.
Le paramètre PARAC peut par exemple être un booléen qui indique, lorsqu’il est par exemple positionné à 1 que le terminal TRM a l’autorisation d’exécuter la fonction Fl. Alternativement, le paramètre PARAC peut être une chaîne de caractère ou tout autre ensemble de données permettant de fournir un statut sur l’autorisation d’exécuter la fonction Fl par le terminal TRM. Ainsi le paramètre PARAC peut par exemple être un couple booléen/chaîne de caractère dans lequel le booléen donne l’information sur l’autorisation d’exécuter la fonction Fl par le terminal TRM et la chaîne de caractère représente un libellé tel qu’un code d’erreur dans le cas où l’autorisation serait refusée.
A l’étape E34, le dispositif DCA va retourner une réponse au dispositif DCE comprenant le paramètre d’accès PARAC, l’identifiant du terminal TRM (ID TRM) et l’identifiant de la fonction Fl (ID Fl).
Le dispositif DCA peut également publier dans la chaîne de blocs des informations liées aux étapes de réception (E33) et d’émission (E34) telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, le paramètre d’accès PARAC, ou encore le résultat d’un traitement réalisé par le dispositif.
Lorsque le dispositif DCE reçoit la réponse (E35), celui-ci va tester (E37) le paramètre PARAC. Si le paramètre PARAC indique que l’exécution de la fonction Fl par le terminal TRM n’est pas autorisée, alors le dispositif DCE envoie le paramètre PARAC au terminal TRM. Le terminal TRM a ainsi l’information que l’exécution n’est pas possible et la raison pour laquelle l’exécution ne peut pas être réalisée. Inversement, si le paramètre PARAC indique que l’exécution de la fonction Fl par le terminal TRM est autorisée, alors le dispositif va exécuter la fonction Fl (E38) et envoyer le résultat de l’exécution au terminal TRM (E39).
Le dispositif DCE peut également publier dans la chaîne de blocs des informations liées aux étapes de réception (E31 et E35) et d’émission (E32, E36, E39) telles que la date et l’heure de réception et d’émission des requêtes, des éléments reçus ou envoyés comme par exemple l’identifiant du terminal, le paramètre d’accès PARAC, les informations d’exécution de la fonction Fl ou encore le résultat de l’exécution de la fonction Fl.
Selon un mode particulier de réalisation de l’invention, la fonction Fl peut être exécutée en dehors de la chaîne de blocs. Dans ce cas le dispositif DCE va envoyer la demande d’exécution à un serveur externe via une interface dédiée de la chaîne de blocs.
Selon un mode particulier de réalisation de l’invention, les dispositifs DCE et DCA peuvent être une seule et même machine informatique exécutant plusieurs DApps mettant en œuvre les fonctions Fl, F2 et F3.
Selon un mode particulier de réalisation de l’invention (non décrit ici), si l’exécution de la fonction Fl échoue, par exemple suite à une indisponibilité (problème de mémoire, problème de charge du serveur/ordinateur, ou autre), alors une requête est émise depuis le dispositif DCE à destination du dispositif DCA comprenant un paramètre indiquant que l’exécution de la fonction Fi a échoué, l’identifiant du terminal TRM et l’identifiant de la fonction Fl. Le dispositif DCA pourra alors effectuer par exemple un remboursement partiel ou total de la somme précédemment payée à l’étape E25.
Selon un mode particulier de réalisation de l’invention, l’utilisateur peut, via son terminal TRM et avant l’étape E10, consulter un annuaire de fonctions afin de choisir la fonction Fl à exécuter. L’annuaire peut par exemple être représenté au niveau du terminal sous forme d’une liste de fonctions ou d’un tableau de fonctions avec par exemple une description, le nom du développeur et une note pour chaque fonction, la note étant par exemple le résultat d’une moyenne des notes données par les utilisateurs pondérée par le taux de disponibilité de la fonction. L’annuaire peut par exemple être récupéré en réponse suite à une requête envoyée par le terminal TRM à destination d’une DApps inscrite dans une chaîne de blocs.
Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l’homme de l’art sans pour autant sortir du cadre de l’invention.

Claims

REVENDICATIONS
1. Procédé de contrôle d’accès à une fonction d’une application mis en œuvre par un dispositif de contrôle d’accès à une fonction d’une application, ce dispositif de contrôle étant inscrit à une chaîne de blocs, le procédé étant caractérisé en ce qu’il comprend :
- une étape de réception (E21), en provenance d’un premier terminal, d’une première requête d’accès à au moins une première fonction (Fl) de l’application, ladite application étant inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction (ID Fl) et au moins un identifiant dudit premier terminal (ID TRM) ;
- une étape d’émission (E22) d’une réponse à la requête d’accès comprenant au moins un paramètre d’accès (ID PA) à ladite au moins une première fonction et au moins un second identifiant d’au moins une seconde fonction (ID F3) inscrite dans ladite chaîne de blocs, ledit au moins un second identifiant étant associé audit au moins un paramètre.
2. Procédé de contrôle d’accès selon la revendication 1, dans lequel l’étape d’émission est suivie d’une première étape de publication dans ladite chaîne de blocs, dudit identifiant dudit premier terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission.
3. Procédé de contrôle d’accès selon la revendication 1, dans lequel l’étape d’émission est suivie :
- d’une deuxième étape de réception, en provenance d’au moins un second terminal, d’une requête d’exécution de ladite au moins une seconde fonction, ladite requête d’exécution comprenant au moins ledit identifiant dudit premier terminal ;
- d’une étape d’exécution de ladite au moins une seconde fonction ;
- d’une deuxième étape de publication dans la chaîne de blocs, dite publication de paiement, dudit identifiant dudit premier terminal, d’au moins une donnée associée à ladite deuxième étape de réception et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une seconde fonction.
4. Procédé de contrôle d’accès selon la revendication 3, dans lequel la deuxième étape de publication est suivie d’une deuxième étape d’émission d’une réponse à la requête d’exécution comportant au moins une donnée associée au résultat de l’exécution de ladite au moins une seconde fonction.
5. Procédé de contrôle d’accès selon la revendication 3, dans lequel la deuxième étape de publication est suivie :
- d’une troisième étape de réception, en provenance de ladite application, d’une requête d’autorisation d’utilisation par ledit premier terminal de ladite au moins une première fonction, ladite requête d’autorisation comprenant au moins ledit identifiant dudit premier terminal et au moins ledit premier identifiant de ladite au moins une première fonction ;
- d’une étape d’obtention depuis ladite chaîne de blocs, en fonction dudit identifiant dudit premier terminal, des données publiées via ladite publication de paiement ;
- d’une troisième étape d’émission d’une réponse à la requête d’autorisation comprenant au moins un second paramètre d’accès à ladite au moins une première fonction, ledit paramètre d’accès étant fonction du résultat de l’exécution de ladite au moins une seconde fonction obtenu via les données de ladite publication de paiement ;
- d’une troisième étape de publication, dans la chaîne de blocs, dudit au moins un second paramètre d’accès et de l’identifiant dudit premier terminal.
6. Procédé de contrôle de l’exécution d’une fonction d’une application mis en œuvre par un dispositif de contrôle de l’exécution d’une fonction d’une application, ce dispositif de contrôle étant inscrit à une chaîne de blocs, le procédé étant caractérisé en ce qu’il comprend :
- une étape de réception (Eli), en provenance d’un terminal, d’une première requête d’exécution d’au moins une première fonction d’une application (Fl) inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction (ID Fl) et au moins un identifiant dudit terminal (ID TRM) ;
- une étape d’émission d’une réponse à la requête d’exécution comprenant au moins un second identifiant d’au moins une seconde fonction (ID F2) inscrite dans ladite chaîne de blocs.
7. Procédé de contrôle de l’exécution selon la revendication 6, dans lequel l’étape d’émission est suivie d’une première étape de publication dans la chaîne de blocs, dudit identifiant dudit terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission.
8. Procédé de contrôle de l’exécution selon la revendication 6, dans lequel l’étape d’émission est suivie :
- d’une deuxième étape de réception, en provenance dudit terminal, d’une deuxième requête d’exécution de ladite au moins une première fonction, ladite deuxième requête d’exécution comprenant au moins ledit premier identifiant de ladite au moins une première fonction et au moins ledit identifiant dudit terminal ;
- d’une deuxième étape d’émission, d’une requête d’autorisation d’exécution, pour ledit terminal, de ladite au moins une première fonction, ladite requête d’autorisation comprenant au moins ledit identifiant dudit terminal et au moins ledit premier identifiant de ladite au moins une première fonction ;
- d’une troisième étape de réception d’une réponse à la requête d’autorisation comprenant au moins un paramètre d’accès à ladite au moins une première fonction pour ledit terminal ;
- d’une étape d’exécution de ladite au moins une première fonction en fonction dudit au moins un paramètre d’accès reçu ;
- d’une deuxième étape de publication dans la chaîne de blocs, dudit au moins un paramètre d’accès, dudit identifiant dudit terminal et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une première fonction.
9. Procédé de contrôle de l’exécution selon la revendication 8, dans lequel la deuxième étape de publication est suivie d’une troisième étape d’émission d’une réponse à la deuxième requête d’exécution comprenant au moins une donnée associée au résultat de l’exécution de ladite au moins une première fonction.
10. Dispositif de contrôle d’accès à une fonction d’une application, ledit dispositif de contrôle étant inscrit à une chaîne de blocs et comprenant :
- un module de réception (COM11) d’une première requête d’accès, en provenance d’un premier terminal, à au moins une première fonction de l’application, ladite application étant inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction et au moins un identifiant dudit premier terminal ;
- un module d’émission (COM12) d’une réponse à la requête d’accès comprenant au moins un paramètre d’accès à ladite au moins une première fonction et au moins un second identifiant d’au moins une seconde fonction inscrite dans ladite chaîne de blocs, ledit au moins un second identifiant étant associé audit au moins un paramètre ; - un module de publication (OBT1) dans ladite chaîne de blocs, dudit identifiant dudit premier terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission.
11. Dispositif de contrôle d’accès selon la revendication 10 caractérisé en ce qu’il comporte en outre :
- un deuxième module de réception d’une requête d’exécution, en provenance d’au moins un second terminal, de ladite au moins une seconde fonction, ladite requête d’exécution comprenant au moins ledit identifiant dudit premier terminal ;
- un module d’exécution de ladite au moins une seconde fonction ;
- un deuxième module de publication dans la chaîne de blocs, d’une publication dite de paiement, dudit identifiant dudit premier terminal, d’au moins une donnée associée à ladite deuxième étape de réception et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une seconde fonction.
12. Dispositif de contrôle d’accès selon la revendication 11 caractérisé en ce qu’il comporte en outre :
- un troisième module de réception, d’une requête d’autorisation d’utilisation par ledit premier terminal de ladite au moins une première fonction, ladite requête étant en provenance de ladite application et comprenant au moins ledit identifiant dudit premier terminal et au moins ledit premier identifiant de ladite au moins une première fonction ;
- un module d’obtention depuis ladite chaîne de blocs, en fonction dudit identifiant dudit premier terminal, des données publiées via ladite publication de paiement ;
- un troisième module d’émission d’une réponse à la requête d’autorisation comprenant au moins un second paramètre d’accès à ladite au moins une première fonction, ledit paramètre d’accès étant fonction du résultat de l’exécution de ladite au moins une seconde fonction obtenu dans les données de ladite publication de paiement ;
- un troisième module de publication, dans la chaîne de blocs, dudit au moins un second paramètre d’accès et dudit identifiant dudit premier terminal.
13. Dispositif de contrôle de l’exécution d’une fonction d’une application, ledit dispositif de contrôle étant inscrit à une chaîne de blocs et comprenant :
- un module de réception (COM21) d’une première requête d’exécution, en provenance d’un terminal, d’au moins une première fonction d’une application inscrite dans ladite chaîne de blocs, ladite requête comprenant au moins un premier identifiant de ladite au moins une première fonction et au moins un identifiant dudit terminal ;
- un module d’émission (COM22) d’une réponse à la requête d’exécution comprenant au moins un second identifiant d’au moins une seconde fonction inscrite dans ladite chaîne de blocs ;
- un module de publication (OBT2), dans une chaîne de blocs, dudit identifiant dudit terminal, d’au moins une donnée associée à l’étape de réception et d’au moins une donnée associée à l’étape d’émission.
14. Dispositif de contrôle de l’exécution d’une fonction selon la revendication 13 caractérisé en ce qu’il comporte en outre :
- un deuxième module de réception d’une deuxième requête d’exécution, en provenance dudit terminal, de ladite au moins une première fonction, ladite deuxième requête d’exécution comprenant au moins ledit premier identifiant de ladite au moins une première fonction et au moins ledit identifiant dudit terminal ;
- un deuxième module d’émission, d’une requête d’autorisation d’exécution, pour ledit terminal, de ladite au moins une première fonction, ladite requête d’autorisation comprenant au moins ledit identifiant dudit terminal et au moins ledit premier identifiant de ladite au moins une première fonction ;
- un troisième module de réception d’une réponse à la requête d’autorisation comprenant au moins un paramètre d’accès à ladite au moins une première fonction pour ledit terminal ;
- un module d’exécution de ladite au moins une première fonction en fonction dudit au moins un paramètre d’accès reçu ;
- un deuxième module de publication dans la chaîne de blocs, dudit au moins un paramètre d’accès, dudit identifiant dudit terminal et d’au moins une donnée associée au résultat de l’exécution de ladite au moins une première fonction.
15. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de contrôle d’accès à une fonction et du procédé de contrôle de l’exécution d’une fonction selon l’une quelconque des revendications 1 à 5, 6 à 9, lorsque ledit programme est exécuté par un processeur.
EP21710027.0A 2020-02-19 2021-02-17 Procede et dispositif de controle d'acces a une fonction d'une application inscrite dans une chaine de blocs Pending EP4107905A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2001661A FR3107417A1 (fr) 2020-02-19 2020-02-19 Procédé et dispositif de contrôle d’accès à une fonction d’une application inscrite dans une chaîne de blocs.
PCT/FR2021/050276 WO2021165612A1 (fr) 2020-02-19 2021-02-17 Procede et dispositif de controle d'acces a une fonction d'une application inscrite dans une chaine de blocs

Publications (1)

Publication Number Publication Date
EP4107905A1 true EP4107905A1 (fr) 2022-12-28

Family

ID=72470405

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21710027.0A Pending EP4107905A1 (fr) 2020-02-19 2021-02-17 Procede et dispositif de controle d'acces a une fonction d'une application inscrite dans une chaine de blocs

Country Status (4)

Country Link
US (1) US12367319B2 (fr)
EP (1) EP4107905A1 (fr)
FR (1) FR3107417A1 (fr)
WO (1) WO2021165612A1 (fr)

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA3027741C (fr) * 2016-06-17 2020-07-21 Jonathan WEIMER Systemes de chaines de blocs et procedes d'authentification d'utilisateur
MX2019007034A (es) * 2016-12-14 2019-08-22 Walmart Apollo Llc Sistemas y metodos para controlar el acceso a un espacio bloqueado utilizando claves criptograficas almacenadas en una cadena de bloques.
US11544708B2 (en) * 2017-12-29 2023-01-03 Ebay Inc. User controlled storage and sharing of personal user information on a blockchain
US11531783B2 (en) * 2018-03-27 2022-12-20 Workday, Inc. Digital credentials for step-up authentication
CN108632284B (zh) * 2018-05-10 2021-02-23 网易（杭州）网络有限公司 基于区块链的用户数据授权方法、介质、装置和计算设备
US10693716B2 (en) * 2018-05-29 2020-06-23 At&T Mobility Ii Llc Blockchain based device management
US20200020440A1 (en) * 2018-07-12 2020-01-16 Appley Health, Inc. Computer-assist method using distributed ledger technology for operating and managing an enterprise
US11489816B2 (en) * 2018-07-31 2022-11-01 Ezblock Ltd. Blockchain joining for a limited processing capability device and device access security
US11276056B2 (en) * 2018-08-06 2022-03-15 Inveniam Capital Partners, Inc. Digital contracts in blockchain environments
WO2020055384A1 (fr) * 2018-09-11 2020-03-19 Visa International Service Association Système, procédé, et produit de programme d'ordinateur pour la gestion des fraudes avec carte de hachage partagée
US11277261B2 (en) * 2018-09-21 2022-03-15 Netiq Corporation Blockchain-based tracking of program changes
EP3881270A4 (fr) * 2018-11-13 2022-08-17 Banqu, Inc. Définition et gestion de formulaires dans un réseau de confiance de registre distribué
US10958421B2 (en) * 2018-11-20 2021-03-23 International Business Machines Corporation User access control in blockchain
ES2880455T3 (es) * 2018-11-27 2021-11-24 Advanced New Technologies Co Ltd Plataforma de función como servicio (FAAS) en redes de cadena
US11263315B2 (en) * 2018-12-03 2022-03-01 Ebay Inc. System level function based access control for smart contract execution on a blockchain
US10325079B1 (en) * 2018-12-04 2019-06-18 Capital One Services, Llc Version management platform
US11030297B2 (en) * 2019-01-04 2021-06-08 Comcast Cable Communications, Llc Systems and methods for device and user authorization
US11368441B2 (en) * 2019-01-29 2022-06-21 Mastercard International Incorporated Method and system for general data protection compliance via blockchain
JP2020528224A (ja) * 2019-04-26 2020-09-17 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ 信頼できる実行環境におけるスマート契約動作のセキュアな実行
US11132460B2 (en) * 2019-06-07 2021-09-28 Mo Ac Blockchain Tech Inc. Apparatus and method for controlling access to user information
US11734616B2 (en) * 2019-07-12 2023-08-22 Mastercard International Incorporated Method and system for access control of shared spaces through blockchain

Also Published As

Publication number Publication date
WO2021165612A1 (fr) 2021-08-26
US20230177214A1 (en) 2023-06-08
US12367319B2 (en) 2025-07-22
FR3107417A1 (fr) 2021-08-20

Similar Documents

Publication Publication Date Title
EP1299838A1 (fr) Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
EP1164529A1 (fr) Système et procédé de couponnage électronique
EP1314143A1 (fr) Dispositif et procede de sauvegarde d'information de transaction en ligne
CA2999731A1 (fr) Procede de traitement de donnees par un terminal de paiement, terminal de paiement et programme correspondant
WO2020128240A1 (fr) Traitement d'un service de tickets electroniques
EP4359986B1 (fr) Procédé et dispositif de paiement par chaînes de blocs
EP3485451B1 (fr) Procédé de traitement d'au moins une donnée de moyen de paiement, terminal de paiement et programme d'ordinateur correspondant
EP4107905A1 (fr) Procede et dispositif de controle d'acces a une fonction d'une application inscrite dans une chaine de blocs
FR3062499A1 (fr) Procede de reduction de la taille d'une base de donnees repartie de type chaine de blocs, dispositif et programme correspondant
EP4099249A1 (fr) Procédé et dispositif de transmission d'un identifiant d'un utilisateur lors d'un paiement électronique réalisépar l utilisateur
EP4032057A1 (fr) Procede de transmission d'une information complementaire relative a une transaction financiere
CA3143068A1 (fr) Systeme d'applications de service pour terminaux de paiement
EP3928501B1 (fr) Procédé de gestion d'accès d'un utilisateur à un service vocal, dispositif, système et programmes correspondants
WO2023001846A1 (fr) Procédé de transaction entre un organisme et un établissement sur une chaîne de blocs
FR2862782A1 (fr) Procede d'acces a un contenu multimedia et plate-forme pour la mise en oeuvre du procede
EP3926566A1 (fr) Validation d'une transaction relative a une offre d'un bien ou d'un service à un utilisateur
WO2008020123A1 (fr) Procédé et système de paiement à l'aide d'un téléphone mobile
WO2002005226A1 (fr) Systeme et procede de gestion de transaction de micropaiement dispositifs client, marchand et intermediaire financier
FR2962830A1 (fr) Serveur, terminal et procede de transaction securisee
FR3140184A1 (fr) Procédé et dispositif d’attribution d’un NFT
WO2024188823A1 (fr) Procédé et dispositif de vérification d'au moins une donnée obtenue depuis un service de fourniture de données
FR2881006A1 (fr) Systeme de communication pour jeu mobile
FR3163472A1 (fr) Procédés et dispositifs d’authentification et de validation biométrique d’un utilisateur
FR3143143A1 (fr) Procédé de connexion à un compte personnel sur un service en ligne au moyen d’une chaîne de blocs
WO2003098433A2 (fr) Systemes et procedes pour commander selectivement et comptabiliser l'utilisation effective de logiciels

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

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

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