EP4078495A1 - Procédé et dispositif de gestion d'une autorisation d'accès à un service de paiement fourni à un utilisateur - Google Patents

Procédé et dispositif de gestion d'une autorisation d'accès à un service de paiement fourni à un utilisateur

Info

Publication number
EP4078495A1
EP4078495A1 EP20821056.7A EP20821056A EP4078495A1 EP 4078495 A1 EP4078495 A1 EP 4078495A1 EP 20821056 A EP20821056 A EP 20821056A EP 4078495 A1 EP4078495 A1 EP 4078495A1
Authority
EP
European Patent Office
Prior art keywords
user
holder
delegated
identifier
access
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
EP20821056.7A
Other languages
German (de)
English (en)
Inventor
Fabrice JEANNE
Baptiste François HEMERY
Sandrine LE CALVEZ
Romain TRINQUART
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 EP4078495A1 publication Critical patent/EP4078495A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/229—Hierarchy of users of accounts
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the invention lies in the field of technologies used for the implementation of payment services, and in particular of digital currency, mobile payment, prepaid payment, card or non-card services.
  • the invention relates more particularly to the management of authorization of access by a third party to such a payment system associated with a holder user, in order to carry out payment transactions.
  • Such payment services are for example and without limitation:
  • An online payment and / or money transfer service system An online payment and / or money transfer service system.
  • Such payment services can be associated with a bank account of the user, or based on a prepaid account, or else associated with a means of payment associated with a bank account of the user (for example a card, or a account of a service provider, for example a mobile communications operator).
  • a means of payment associated with a bank account of the user for example a card, or a account of a service provider, for example a mobile communications operator.
  • the providers of these payment services require that before carrying out a payment transaction ordered by the user authenticated with the payment service, the balance of the user's account with payment service is not negative or else a payment method associated with a user's bank account is associated with the user's payment service account. In other words, the user must either transfer from money to their payment service account or else associate a payment method associated with a bank account, in order to be able to carry out a payment transaction via the payment service account.
  • the types of payment services mentioned above allow one-off payment transactions to be carried out.
  • the operating mode of these payment services is not suitable for setting up other services such as direct debit, surety, credit, etc., because it is not possible to anticipate a balance of an account of a user of such a payment service, at a fixed date in the future. Indeed, the account could no longer be funded, or even closed.
  • the use of this type of payment services by users therefore poses a problem of third-party trust vis-à-vis these users ....
  • the identity of a user associated with a payment service account is unique.
  • the invention improves the state of the art. For this purpose, it relates to a method for managing an authorization to access a payment service provided to a user, called the executive user.
  • the method is implemented by a processor of a management device, and comprises:
  • the invention thus allows a holder user to assign to one or more delegated users an authorization to access a payment service provided to him.
  • the owner of the payment service is a user with authentication data allowing him to authenticate with the payment service provider and access the payment service.
  • the payment service can be a mobile payment service based on a prepaid account, or else an online payment service associated with a payment method of the holder user, for example a bank card, or associated with a account authenticated with a service provider, for example a communications network operator.
  • the invention makes it possible to extend the range of services offered by this type of payment service to users of payment services, in particular mobile or online, and to their entourage, while guaranteeing the identification constraints required vis-à-vis. with regard to the regulations in force, a control of the transactions carried out and an increased level of security.
  • the employee user can delegate access rights to the payment service with which he is authenticated in order to allow delegated users to carry out payment transactions.
  • the security of the authentication data of the holder user is guaranteed because the latter does not provide his identifier and secret code to third parties.
  • a user delegated to an authorization to access the payment service of the holder user has temporary access data (identifier and code) generated and provided by the management device and associated with this delegated user.
  • Temporary access data is transmitted to the delegated user, or to another beneficiary user, in the event that the delegated user is not the originator of the payment transactions to be carried out via the payment service provided. to the condominium user.
  • the method of managing a access authorization defined above is used to delegate access rights to the account of the holder user.
  • the request further comprises an indication of a type of access authorization and at least one parameter associated with said type of access authorization.
  • the holder user gives access to a payment service provided to him or to his account for a given type of authorization. For example, access can be given for one type of transaction only, such as a direct debit authorization, joint surety, ...
  • the type of authorization is associated with parameters allowing the management device or a server to control the use of the payment service or the account made by the delegated user.
  • parameters are the authorized amount, the frequency of a payment, the validity period of the authorization, ....
  • the management method further comprises, prior to the transmission of said temporary data:
  • the creation of the access authorization is confirmed by the holder user by sending his confidential code.
  • the management device can thus verify the authenticity of the request to initialize an access authorization received.
  • the generation of temporary data comprises:
  • the public identifier is generated from the identifier of the holder user and an encryption key. This same key is also used to generate the confidential code associated with the generated public identifier.
  • the generated confidential code is not stored by the management device. This confidential code is sent to the delegated user.
  • the management device or a server can decode a received confidential code, using the encryption key and verify whether the delegated user or the other user is properly authorized to access the payment service of the derivative user.
  • the management method comprises beforehand:
  • this particular embodiment of the invention is advantageous in the case where the delegated user wishes theoxy user to stand surety for him.
  • the delegated user can ask several first users to stand surety for him.
  • the delegated user sends as many requests to initialize an access authorization as there are users to whom he wishes to ask to stand surety for him.
  • the management device when the management device receives at least one other request for initialization of at least one access authorization, coming from a terminal of another holder user, and intended to allow said delegated user to access said payment service of said other holder user, said request comprising at least the identifier of said delegated user and an identifier of said other holder user, the method further comprises:
  • This particular embodiment of the invention makes it possible to create an aggregated account for the delegated user from several payment services or accounts of employee users who have authorized him access to the payment service which respectively provided them.
  • the management method further comprises:
  • the invention also relates to a device for managing an authorization to access a payment service provided to a holder user, comprising a memory and a processor configured to: receive, from a terminal of said holder user, a request initialization of at least one access authorization, said access authorization being intended to allow at least one delegated user to access said payment service provided to said holder user, said request comprising at least one identifier of said delegated user and an identifier of said holder user, generating temporary access data to the payment service associated with said delegated user, said temporary data comprising a public identifier associated with said delegated user, and a confidential code associated with said public identifier, transmitted to at least one terminal of the delegated user or of another user said data t emporaries.
  • the aforementioned management device is included in a server.
  • the invention also relates to a computer program comprising instructions for implementing the above management method according to any one of the particular embodiments described above, when said program is executed by a processor.
  • the management 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 may include a storage means, such as a memory.
  • 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 management method in question.
  • FIG. IA illustrates an example of an environment for implementing the invention according to a particular embodiment of the invention
  • FIG. IB illustrates an example of an environment for implementing the invention according to another particular embodiment of the invention
  • FIG. 2A illustrates the steps of the method for managing an authorization to access a payment service provided to a user according to a particular embodiment of the invention
  • FIG. 2B illustrates the steps of the method of managing an authorization to access a payment service provided to a user according to another particular embodiment of the invention
  • FIG. 3 A illustrates other steps of the method for managing an authorization to access a payment service provided to a user according to a particular embodiment of the invention
  • FIG. 3B illustrates other steps of the method for managing an authorization to access a payment service provided to a user according to another particular embodiment of the invention
  • FIG. 4 illustrates an example of a management device according to a particular embodiment of the invention.
  • the invention proposes a method for managing authorizations for access to a payment service provided to a user, also called the holder user hereinafter, to allow third parties (delegated users, beneficiary users) to carry out payment transactions via the payment service provided to the derivative user.
  • the invention makes it possible to widen the range of services offered to payment system users, and in particular to payment systems based on a prepaid account, by guaranteeing the constraints of identification, control of transactions and a level of security. security equivalent to conventional banking transaction mechanisms.
  • the management method described below offers a secure mechanism for setting up a delegation of access rights to a payment service used by a holder user allowing third parties to carry out transactions using the payment service provided to the user. 'titular user while respecting certain constraints and using an identifier and a secret code different from that of theoxy user.
  • the mechanism is thus secure and the transactions carried out are traceable. In other words, the identity of the third party requesting the completion of the transaction is authenticated before the transaction is executed.
  • the management method described below makes it possible to set up a delegation of payment rights. access to the account of the holder user.
  • FIG. 1A An example of an implementation environment of the invention according to a particular embodiment of the invention is described below in relation with FIG. 1A.
  • the environment of FIG. 1A comprises a terminal TPI of a holder user P1.
  • the holder user PI has authenticated access to a payment service provider, for example a mobile payment service.
  • the payment service is based on the use of an account created for each holder user with the service provider, for example, a prepaid account.
  • the payment service can operate without requiring the creation of an account.
  • an authenticated holder user of the payment service associates with his authentication data with the payment service, a means of payment associated with a bank account or with an account of another service provider (for example an operator). communications).
  • the environment includes, for example, one or more payment server (s) SP of the payment service provider.
  • the payment server SP receives and executes payment orders and responds to account balance consultation requests.
  • an account balance consultation request may correspond to a query of a balance availability or of a ceiling authorized by the means of payment which has been associated with the data. authentication of the holder user with the payment service.
  • the entity user here PI
  • the environment also includes a delegate user DI provided, for example, with a TD1 terminal.
  • the delegate user DI does not necessarily have an authenticated account with the payment service provider.
  • this user DI receives, for example on his terminal TD1, provisional access data to the payment service or to the account of the user P1.
  • provisional data include in particular a public alias and an associated secret code. to this public alias.
  • the environment also includes a beneficiary user B1, provided with a terminal TB1.
  • the beneficiary user has authentication data with a provider of payment service, which may be identical or different from the payment service provider with which the holder user PI has authentication data, and an authenticated account as appropriate.
  • the beneficiary user B1 is able to receive a payment ordered by the delegated user DI and paid via the payment service provided to the holder user PL When the payment service is associated with an authenticated account, this payment is paid via the account of the holder user, otherwise via the means of payment associated with the authentication data of the holder user.
  • the beneficiary user B1 can check the solvency of the account of the holder user Pl.
  • the beneficiary user B1 is identical to the delegate user DI.
  • the environment also includes a SERV management device, managed by the payment service provider providing the payment service to the holder user P1.
  • This SERV server implements the authorization to access the payment service.
  • the entity user P1 by the generation and management of public aliases, the generation of associated secret codes and their securing and the management of the specific constraints set for the use of the aliases generated.
  • the SERV management device is included in the server SP of the payment service provider.
  • the SERV server responds to requests:
  • From a delegated user to request the execution of a transaction by providing G received public alias and the associated temporary secret code.
  • the server checks that the conditions of use (thresholds, amount, date, etc.) comply with the conditions set during the implementation of the access authorization, From a beneficiary user: when this user is a user other than a delegated user, to request the execution of a payment / transaction request at maturity by providing the public alias received.
  • the implementation of an authorization to access the payment service provided to the holder user PI can be carried out via the terminals TPI, TD1 and TB1 of the various users in play, for example via a dedicated application provided by the service provider.
  • payment service for the holder user PL Such an application comprises in particular, for the holder, a form for declaring a third party and entering credentials for delegated users.
  • the application when entering for the initialization of an access authorization, can allow the holder user to specify a type of delegation, such as direct debit, deposit, payment card, etc., as well as specific constraints of use such as duration, frequency, maximum amount allocated ...
  • the application also includes, for the beneficiary or the delegatee, one or more forms allowing the entry of an alias instead of the current identification (for example MSISDN) and the secret code associated with this alias, as well as an interface making it possible to request the execution of a payment order or a balance consultation to check an available balance.
  • the terminals TPI, TB1 and TD1 communicate with the server SERV via a communication network RES.
  • the PI holder user can authorize access to his payment service to several Dl delegate users,
  • the same delegate user D1 can be authorized by several holder users PI, P2, ..., PN, to use their payment service.
  • FIG. 1B illustrates an example of implementation of such a particular embodiment of the invention.
  • the environment of FIG. IB comprises for example, in addition to the elements already presented in relation to FIG. IA, a number N of derivative users PI to PN respectively provided with a terminal TPi, i ranging from 1 to N, N being an integer greater than 1.
  • the delegate user DI receives authorization to use the payment service or the account of each of the holder users PI, .. PN.
  • the authorizations received by the delegate user DI on each of the accounts of the holder users PI, ..., PN are aggregated into an aggregated account allowing a beneficiary user B1, for example equipped with a terminal TB1 , to request the execution of a transaction on the aggregated account from the accounts ofoxy users PI, ..., PN.
  • FIG. 2A illustrates the steps of the method of managing an authorization to access a payment service provided to a user according to a particular embodiment of the invention. The method is described here in the case where the payment service is associated with an account.
  • the holder user PI requests the establishment of a debit authorization for the benefit of the delegate user DI.
  • this involves authorizing a service provider to request the execution of a payment due (invoice) to the account of the holder user Pl.
  • the holder user P1 sends, via his terminal TPI, a request to initialize an access authorization.
  • a request comprises in particular an identifier of the delegate user DI and the identifier of the holder user Pl.
  • the holder user Pl indicates the type of authorization requested, here direct debit authorization, and defines optional parameters associated with the type of authorization. For example, the holder user Pl indicates a maximum amount per execution request, a frequency or authorization of an execution of a payment order per unit of time, a period of validity of the authorization, a maximum amount allocated authorization, etc ....
  • the identifier of the delegated user DI provided is an identifier authenticated with the payment service provider with which the principal user P1 is also authenticated.
  • the delegated user has an account authenticated with this operator.
  • the server On receipt of the request, during a step E210, the server generates temporary account access data associated with the delegate user D1.
  • the server generates an alias or also called a public identifier, from the identifier of the holder user PL This alias is associated with the delegate user D1.
  • the server encodes, using a server-specific key, selected from a list of available keys, the authenticated identifier of the holder user PI to produce a public alias in a target format depending on the type of authorization.
  • the server sends the terminal of the holder user PI, a request for confirmation of the access authorization initialization request.
  • the holder user PI confirms his request during a step E230, by sending the server a confirmation message comprising the confidential code (secret code) of the holder user PL
  • the server then generates a temporary secret code associated with the alias generated during step E210.
  • the server encodes, using the selected key, the secret code of the holder user PI to produce a new secret code of the same size associated with this alias in the form of 4 digits for example.
  • the temporary data associated with the delegated user can be of the following form: for the alias: an 8-digit code (in the case of a classic identifier) or a 16-digit code (in the case of 'an identifier corresponding to a “corporate” card identifier - corporate in French -), and for the temporary secret code: 4 digits.
  • the server then records the data associated with this authorization: identifier of the holder user PI alias (public identifier) temporary generated, index of the key used for encoding, the use parameters defined by the derivative user Pl.
  • the server never records the secret code of the holder user PI in clear, nor the temporary secret code generated, but retains a means of decrypting it on the fly during the execution of a transaction. from the data received (alias + associated temporary secret code).
  • the server then broadcasts, via the network RES, to the delegated user DI and the holder user PI, G generated alias, corresponding here for a debit authorization, to an aggregation of the generated alias and the provisional secret code.
  • the public alias is sent by the server, via the RES network, to the holder user PI who is responsible for transmitting it to the beneficiary user, via the RES network or any other suitable communication network.
  • the generated temporary secret code is sent directly by the server by a secure means to the delegated user.
  • the implementation of the authorization to access the account of the PI holder user results in the issuance of an authorization ticket (combination of the associated alias to the delegate user DI and the temporary secret code), not taken from the account of the holder user PL In other words, the sum is always available for the holder user Pl.
  • the delegated user DI wishing to make a payment to the account of the holder user P1, during a step E270, the delegated user DI enters his identifiers on the application of his terminal TD1: the public identifier (alias ) received, the provisional secret code received, the amount of the payment.
  • the public identifier alias
  • the server obtains the encryption key used from the key index which has been stored with the public identifier received. It then obtains the identifier and the confidential code of the derivative user, by decoding the public identifier and the temporary secret code received from the obtained encryption key.
  • the server checks the conditions of use associated with the public alias: validity, amount, payment frequency, etc. If the conditions are valid, during a step E291, the server transmits an execution order for payment of the amount for the benefit of the delegated user D1, via the account of the holder user PL For this, the server SERV transfers the payment request to a payment transaction server SP, with the secret code and the decoded identifier of the holder user PI and requests the execution of the payment on behalf of the user holder PI of the account.
  • the payment transaction server SP transfers the sum of the account of the holder user PI to the account of the delegate holder Dl.
  • the user who owns the account is notified and receives a request for validation of the transaction (not shown in FIG. 3A).
  • step E290 When the conditions verified in step E290 are not valid, the transaction, here a direct debit, is rejected.
  • the server notifies the delegate user Dl and the holder user PL
  • a beneficiary / delegated user can check the solvency of a holder user, for example before making a direct debit request.
  • the beneficiary user enters the temporary data received including the alias and the temporary secret code.
  • the server receives this request and extracts the ID of the holder user and his secret code.
  • the server requests an account and balance verification on behalf of the holder user and transfers the result in an OK / KO form to the beneficiary / delegate user, via the RES network.
  • FIG. 2B illustrates steps of the method for managing an authorization to access an account of a user according to another particular embodiment of the invention.
  • a delegated user Dl requests an access authorization from several principal users Pi, i ranging from 1 to N.
  • an entrepreneur (delegated user Dl) asks investors (users Pi holders) to make a certain amount available to help them develop their business. Investors undertake to provide him with all or part of this sum which will not be withdrawn from their account, nor even blocked, but the sum appears to be virtually available on the entrepreneur's account with the payment service provider.
  • the setting up of the authorizations on the accounts of the derivative users is done in a manner similar to that described in relation to FIG. 2A.
  • the terminal TD1 of the delegate user DI sends the server SERV a request for initializing an authorization to access the account of the holder user Pi, the request comprising the identifier of the delegated user Dl, the identifier of the holder user Pi and a payment transaction amount.
  • the server SERV sends to the terminal of the holder user Pi, a message informing the holder user Pi of the request sent by the delegate user D1 indicating the identifier of the delegate user Dl, and the payment transaction amount.
  • steps E200i, E210i, E220i, E230i, E240i and E250L are carried out. These steps are identical to steps E200, E210, E220, E230, E240 and E250 described in relation to FIG. 2A.
  • the server SERV creates an aggregated account for the delegated user Dl from the aliases generated from each holder user Pi, and the associated temporary confidential codes.
  • This aggregated account then comprises a new alias corresponding to the concatenation of the aliases of each holder user Pi and a temporary secret code generated from the associated temporary confidential codes.
  • This aggregated account also includes a key index concatenation and distribution rules for executing a payment through the aggregated account.
  • the server stores the temporary data of the aggregated account for each type of delegation requested by the delegated user Dl.
  • the SERV server therefore initiates the two types of authorization with the temporary data of the aggregated account. Then, the SERV server broadcasts the temporary data.
  • the server SERV transmits to the terminal of the delegated user Dl, a concatenation of the new alias and temporary secret code of the aggregated account.
  • the terminal of the delegated user Dl transmits these data, during a step E330, to the beneficiary user B1, via the RES network or any other suitable network.
  • the server SERV transmits to the terminal of the delegated user Dl the new alias of the aggregated account. It then transmits, during a step E341, via a secure means, the temporary secret code of the aggregated account to the terminal of the delegated user Dl.
  • the entrepreneur For the deposit or security deposit, at the request of a service provider (beneficiary user Bl), the entrepreneur (delegated user Dl) will provide a guarantee on the basis of the deposit for the supply / G use of a good or a service.
  • the service provider receives a direct debit authorization code (alias and temporary secret code) on the aggregated account allowing it to check the status of the accounts. surety or to execute a payment according to the conditions provided.
  • a direct debit authorization code alias and temporary secret code
  • the entrepreneur uses the company's account for his activity and if he exceeds the limit available on his own account, he has the option of using the cash reserve made available to him by the surety (Pi holder users).
  • the system then distributes the request for the use of the reserve to one or more guarantors.
  • a surety refuses, the requested sum is distributed among the other sureties. If a surety account is not sufficiently funded, the request is rejected for this account and the requested amount is distributed among the other sureties. If all guarantors agree, the money is transferred directly from the surety's accounts to the beneficiary's account. The money is not paid directly into the account of the entrepreneur.
  • the beneficiary B1 wishes to consult the balance of the aggregated account. To do this, during a step E350, it transmits to the server SERV via its terminal TB1 a request for the status of surety, indicating G public alias and the provisional secret code which have been communicated to it. During a step E351, the server SERV extracts from G alias and the provisional secret code, the key indexes used to generate the provisional confidential codes and the public identifiers of each holder user Pi.
  • the server SERV decodes the identifier of the holder user Pi and his secret code and during a step E353i, the server checks with a server SB of the payment service provider the account balance of the holder user Pi.
  • the server SERV sends back to the terminal of the beneficiary user B1 the status of the deposit for each holder user Pi.
  • the server SERV aggregates the surety statuses of all the derivative users questioned and provides the beneficiary user B1 with the overall status of the surety provided by the delegated user D1, for example by verifying that the total sum available on all the accounts of the derivative users is greater than or equal to the amount required in the initial request transmitted during step E350.
  • the delegated user Dl wishes to use his cash reserve to make a payment for the benefit of the beneficiary user B1.
  • the delegated user Dl transmits to the server SERV via his terminal TD1 a request for payment indicating G public alias and the provisional secret code communicated to him, as well as the amount of the payment.
  • the server SERV extracts from G alias and the provisional secret code, the key indexes used to generate the provisional confidential codes and the public identifiers of each holder user Pi.
  • the server SERY decodes the identifier of the holder user Pi and his secret code and during a step E363i, the server checks that the conditions relating to the delegation authorization put in place are valid. If this is the case, during a step E364i, the server SERV transmits to the server SP a payment execution order for part of the amount requested by the delegated user D1. During a step E365Î, the server SP triggers the execution of payment from the account of the holder user Pi to the account of the beneficiary B 1.
  • the beneficiary user B1 wishes to apply the deposit which has been provided to him and request the realization of the payment of the deposit. For this, during a step E370, the beneficiary user B1 transmits to the server SERV via his terminal TB1 a payment request indicating G public alias and the provisional secret code communicated to him, as well as the amount of the payment. The server then proceeds as for example C2 described above.
  • step E365i the server SP triggers the execution of the payment from the account of the holder user Pi to the account of the beneficiary B1.
  • FIG. 4 illustrates an example of a SERV management device according to a particular embodiment of the invention.
  • the management device SERV has the conventional architecture of a computer, and in particular comprises a memory MEM, a processing unit UT, equipped for example with a processor PROC, and controlled. by the computer program PG stored in memory MEM.
  • the computer program PG includes instructions for implementing the steps of the authorization management method which is described above, when the program is executed by the processor PROC.
  • the code instructions of the computer program PG are for example loaded into a memory before being executed by the processor PROC.
  • the processor PROC of the processing unit UT notably implements the steps of the method for managing an authorization according to any one of the particular embodiments described in relation to FIGS. 2A, 2B, 3 A, 3B according to FIGS. PG computer program instructions.
  • the management device SERV also comprises a communication module COM allowing the management device to establish communications, via a communications network, for example a fixed or mobile data network.
  • a communications network for example a fixed or mobile data network.
  • the management device SERV is included in a server, for example a server of a payment service provider.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé et un dispositif de gestion d'une autorisation d'accès à service de paiement fourni à un utilisateur, dit utilisateur titulaire. Une requête d'initialisation d'au moins une autorisation d'accès est reçue en provenance d'un terminal dudit utilisateur titulaire. Une telle autorisation d'accès est destinée à permettre à au moins un utilisateur délégataire d'accéder audit compte dudit utilisateur titulaire, ladite requête comprenant au moins un identifiant dudit utilisateur délégataire et un identifiant dudit utilisateur titulaire. Des données temporaires d'accès au compte associées audit utilisateur délégataire sont générées, lesdites données temporaires comprenant un identifiant public associé audit utilisateur délégataire, et un code confidentiel associé audit identifiant public. Les données temporaires sont transmises vers au moins un terminal de l'utilisateur délégataire ou d'un autre utilisateur.

Description

DESCRIPTION
Procédé et dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur
1. Domaine de l'invention
L’invention se situe dans le domaine des technologies utilisées pour la mise en œuvre de services de paiement, et notamment de services de monnaie numérique, de paiement mobile, de paiement prépayé, par carte ou non. L’invention concerne plus particulièrement la gestion d’autorisation d’accès d’un tiers à un tel système de paiement associé à un utilisateur titulaire, pour réaliser des transactions de paiement.
2. Art Antérieur
Il existe aujourd’hui différents types de services de paiement permettant à des utilisateurs de réaliser des transactions via un service de paiement auprès duquel ils se sont authentifiés au préalable, par exemple via la création d’un compte auprès du service de paiement.
De tels services de paiement sont par exemple et de manière non limitative :
Un service de paiement mobile,
Un service de paiement par carte,
Un service de monnaie numérique,
Un service de paiement par compte prépayé,
Un système de service de paiement en ligne et/ou de transferts d’argent.
De tels services de paiement peuvent être associés à un compte bancaire de l’utilisateur, ou bien basés sur un compte prépayé, ou bien associé à un moyen de paiement associé à un compte bancaire de l’utilisateur (par exemple une carte, ou un compte d’un fournisseur de services, par exemple un opérateur de communications mobiles).
Dans la plupart de ces services de paiement, les fournisseurs de ces services de paiement imposent, qu’avant la réalisation d’une transaction de paiement ordonnée par l’utilisateur authentifié auprès du service de paiement, le solde du compte de l’utilisateur auprès du service de paiement ne soit pas négatif ou bien qu’un moyen de paiement associé à un compte bancaire de l’utilisateur soit associé au compte du service de paiement de l’utilisateur. Autrement dit, l’utilisateur doit soit transférer de l’argent vers son compte du service de paiement ou bien associer un moyen de paiement associé à un compte bancaire, pour pouvoir réaliser une transaction de paiement via le compte du service de paiement.
Les types de services de paiements cités ci-dessus permettent de réaliser des transactions de paiement ponctuelles. Toutefois, le mode de fonctionnement de ces services de paiement n’est pas adapté à la mise en place d’autres services de type prélèvement, caution, crédit, ... car il n’est pas possible d’anticiper un solde d’un compte d’un utilisateur d’un tel service de paiement, à une échéance fixe dans le futur. En effet, le compte pourrait ne plus être approvisionné, voire clôturé. L’utilisation de ce type de services de paiement par des utilisateurs pose donc un problème de confiance des tiers vis-à-vis de ces utilisateurs .... Il est également à noter que pour répondre à des contraintes réglementaires en vigueur, l’identité d’un utilisateur associée à un compte d’un service de paiement est unique. De plus, pour des raisons de sécurité évidentes, il est déconseillé de transférer l’identifiant d’un compte d’un service de paiement ou les données d’authentification d’un utilisateur auprès du service de paiement à des tiers pour leur permettre de réaliser des transactions via ce compte
Il existe donc un besoin d’améliorer la technique pour offrir plus de services aux utilisateurs de ce type de services de paiement.
3. Exposé de l'invention
L'invention vient améliorer l'état de la technique. Elle concerne à cet effet un procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur, dit utilisateur titulaire. Le procédé est mis en œuvre par un processeur d’un dispositif de gestion, et comprend:
La réception, en provenance d’un terminal dudit utilisateur titulaire, d’une requête d’initialisation d’au moins une autorisation d’accès, ladite autorisation d’accès étant destinée à permettre à au moins un utilisateur délégataire d’accéder audit service de paiement fourni audit utilisateur titulaire, ladite requête comprenant au moins un identifiant dudit utilisateur délégataire et un identifiant dudit utilisateur titulaire,
La génération de données temporaires d’accès au service de paiement associées audit utilisateur délégataire, lesdites données temporaires comprenant un identifiant public associé audit utilisateur délégataire, et un code confidentiel associé audit identifiant public,
La transmission vers au moins un terminal de l’utilisateur délégataire ou d’un autre utilisateur desdites données temporaires.
L’invention permet ainsi à un utilisateur titulaire d’attribuer à un ou plusieurs utilisateurs délégataires une autorisation d’accès à un service de paiement qui lui est fourni. L’utilisateur titulaire du service de paiement est un utilisateur possédant des données d’authentification lui permettant de s’authentifier auprès du fournisseur de service de paiement et d’accéder au service de paiement. Par exemple, le service de paiement peut être un service de paiement mobile basé sur un compte prépayé, ou bien un service de paiement en ligne associé à un moyen de paiement de l’utilisateur titulaire, par exemple une carte bancaire, ou associé à un compte authentifié auprès d’un fournisseur de service, par exemple un opérateur de réseau de communications. L’invention permet d’élargir aux utilisateurs de services de paiement, notamment mobile ou en ligne, et à leur entourage, la gamme de services offerts par ce type de services de paiement tout en garantissant des contraintes d’identification requises vis-à-vis de la réglementation en vigueur, un contrôle des transactions réalisées et un niveau de sécurité accru.
Grâce à l’invention, l’utilisateur titulaire peut déléguer des droits d’accès au service de paiement auprès duquel il est authentifié pour permettre à des utilisateurs délégataires de réaliser des transactions de paiement. La sécurité des données d’authentification de l’utilisateur titulaire est garantie car celui-ci ne fournit pas son identifiant et code secret à des tiers. Un utilisateur délégataire d’une autorisation d’accès au service de paiement de l’utilisateur titulaire dispose de données d’accès (identifiant et code) temporaires générés et fournis par le dispositif de gestion et associées à cet utilisateur délégataire.
Les données d’accès temporaires sont transmises à l’utilisateur délégataire, ou à un autre utilisateur bénéficiaire, dans le cas où l’utilisateur délégataire n’est pas le donneur d’ordre des transactions de paiement à réaliser via le service de paiement fourni à l’utilisateur titulaire.
Lorsque le service de paiement fonctionne en association avec un compte créé pour l’utilisateur titulaire, par exemple un compte prépayé, le procédé de gestion d’une autorisation d’accès défini ci-dessus permet de déléguer des droits d’accès au compte de l’utilisateur titulaire.
Selon un mode particulier de réalisation de l'invention, la requête comprend en outre une indication d’un type d’autorisation d’accès et au moins un paramètre associé audit type d’autorisation d’accès. Selon ce mode particulier de réalisation de l’invention, l’utilisateur titulaire donne accès à un service de paiement qui lui est fourni ou à son compte pour un type d’autorisation donné. Par exemple, l’accès peut être donné pour un type de transaction seulement, tel qu’une autorisation de prélèvement, une caution solidaire, ...
De plus, le type d’autorisation est associé à des paramètres permettant au dispositif de gestion ou à un serveur de contrôler l’utilisation du service de paiement ou du compte faite par l’utilisateur délégataire. Par exemple, de tels paramètres sont le montant autorisé, la périodicité d’un paiement, une durée de validité de l’autorisation, ....
Selon un autre mode particulier de réalisation de l'invention, le procédé de gestion comprend en outre, préalablement à la transmission desdites données temporaires :
L’envoi au terminal de l’utilisateur titulaire, d’une demande de confirmation de la requête d’initialisation,
La réception, en provenance du terminal de l’utilisateur titulaire, d’un message de confirmation comprenant un code confidentiel dudit utilisateur titulaire d’accès audit service de paiement.
Selon ce mode particulier de réalisation de l’invention, la création de l’autorisation d’accès est confirmée par l’utilisateur titulaire par l’envoi de son code confidentiel. Le dispositif de gestion peut ainsi vérifier l’authenticité de la requête d’initialisation d’une autorisation d’accès reçue.
Selon un autre mode particulier de réalisation de l'invention, la génération des données temporaires comprend :
• L’encodage dudit identifiant de l’utilisateur titulaire à l’aide d’une clé de chiffrement propre au dispositif de gestion pour former ledit identifiant public associé à l’utilisateur délégataire, • L’encodage dudit code confidentiel de l’utilisateur titulaire à l’aide de ladite clé de chiffrement pour former ledit code confidentiel associé à l’identifiant public associé à l’utilisateur délégataire,
• La mémorisation dudit identifiant public associé à l’utilisateur délégataire et d’un index de clé identifiant ladite clé de chiffrement.
Selon ce mode particulier de réalisation de l’invention, l’identifiant public est généré à partir de l’identifiant de l’utilisateur titulaire et d’une clé de chiffrement. Cette même clé est également utilisée pour générer le code confidentiel associé à l’identifiant public généré. Avantageusement, le code confidentiel généré n’est pas mémorisé par le dispositif de gestion. Ce code confidentiel est transmis à l’utilisateur délégataire. Lors de l’accès au service de paiement de l’utilisateur titulaire par l’utilisateur délégataire ou un autre utilisateur bénéficiaire, le dispositif de gestion ou un serveur pourra décoder un code confidentiel reçu, à l’aide de la clé de chiffrement et vérifier si l’utilisateur délégataire ou l’autre utilisateur est bien autorisé à accéder au service de paiement de l’utilisateur titulaire.
Selon un autre mode particulier de réalisation de l'invention, le procédé de gestion comprend au préalable :
• La réception, en provenance d’un terminal dudit utilisateur délégataire, d’une requête d’initialisation d’une autorisation d’accès au service de paiement fourni à l’utilisateur titulaire, la requête comprenant l’identifiant dudit utilisateur délégataire, l’identifiant dudit utilisateur titulaire et un montant de transaction de paiement,
• L’envoi au terminal de l’utilisateur titulaire, d’un message informant l’utilisateur titulaire de la requête d’initialisation d’une autorisation d’accès envoyée par le terminal de l’utilisateur délégataire, le message comprenant l’identifiant dudit utilisateur délégataire, et un montant de transaction de paiement.
Selon ce mode particulier de réalisation de l’invention, c’est l’utilisateur délégataire qui est à l’origine de la requête d’initialisation d’autorisation d’accès.
Par exemple, ce mode particulier de réalisation de l’invention est intéressant dans le cas où l’utilisateur délégataire souhaite que l’utilisateur titulaire se porte caution pour lui. En variante, l’utilisateur délégataire peut demander à plusieurs premiers utilisateurs de se porter caution pour lui. Dans ce cas, l’utilisateur délégataire envoie autant de requête d’initialisation d’une autorisation d’accès que d’utilisateurs auquel il souhaite demander de se porter caution pour lui.
Selon un autre mode particulier de réalisation de l'invention, lorsque le dispositif de gestion reçoit au moins une autre requête d’initialisation d’au moins une autorisation d’accès, en provenance d’un terminal d’un autre utilisateur titulaire, et destinée à permettre audit utilisateur délégataire d’accéder audit service de paiement dudit autre utilisateur titulaire, ladite requête comprenant au moins l’identifiant dudit utilisateur délégataire et un identifiant dudit autre utilisateur titulaire, le procédé comprend en outre :
• La mémorisation d’un compte agrégé comprenant, pour chaque utilisateur titulaire, l’identifiant public généré à partir de l’identifiant dudit utilisateur titulaire et associé audit utilisateur délégataire, l’index de clé utilisée pour générer le code confidentiel associé à l’identifiant public associé à l’utilisateur délégataire à partir du code confidentiel de l’utilisateur titulaire.
Ce mode particulier de réalisation de l’invention permet de créer un compte agrégé pour l’utilisateur délégataire à partir de plusieurs services de paiement ou comptes d’utilisateurs titulaires qui lui ont autorisé l’accès au service de paiement qui leur ait respectivement fourni.
Selon un autre mode particulier de réalisation de l'invention, le procédé de gestion comprend en outre :
La réception, en provenance d’un terminal d’un utilisateur bénéficiaire, d’une demande d’exécution de paiement comprenant l’identifiant public associé à l’utilisateur délégataire, le code confidentiel associé audit identifiant public et un montant de paiement, le décodage de l’identifiant de l’utilisateur titulaire et du code confidentiel de l’utilisateur titulaire, à partir de l’index de clé mémorisé, de l’identifiant public associé à l’utilisateur délégataire, et du code confidentiel associé audit identifiant public associé à l’utilisateur délégataire, la transmission d’un ordre d’exécution de paiement du montant à l’utilisateur bénéficiaire, via le service de paiement fourni à l’utilisateur titulaire à partir de l’identifiant de l’utilisateur titulaire et du code confidentiel de l’utilisateur titulaire décodés.
L’invention concerne également un dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur titulaire, comprenant une mémoire et un processeur configurés pour : recevoir, en provenance d’un terminal dudit utilisateur titulaire, une requête d’initialisation d’au moins une autorisation d’accès, ladite autorisation d’accès étant destinée à permettre à au moins un utilisateur délégataire d’accéder audit service de paiement fourni audit utilisateur titulaire, ladite requête comprenant au moins un identifiant dudit utilisateur délégataire et un identifiant dudit utilisateur titulaire, générer des données temporaires d’accès au service de paiement associées audit utilisateur délégataire, lesdites données temporaires comprenant un identifiant public associé audit utilisateur délégataire, et un code confidentiel associé audit identifiant public, transmettre vers au moins un terminal de l’utilisateur délégataire ou d’un autre utilisateur lesdites données temporaires.
Selon un mode particulier de réalisation de l'invention, le dispositif de gestion précité est compris dans un serveur.
L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de gestion 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é de gestion 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, telle qu’une mémoire. 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é de gestion en question.
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. IA] La figure IA illustre un exemple d'environnement de mise en œuvre de l'invention selon un mode particulier de réalisation de l'invention,
[FIG. IB] La figure IB illustre un exemple d'environnement de mise en œuvre de l'invention selon un autre mode particulier de réalisation de l'invention,
[FIG. 2A] La figure 2A illustre des étapes du procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur selon un mode particulier de réalisation de l'invention,
[FIG. 2B] La figure 2B illustre des étapes du procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur selon un autre mode particulier de réalisation de l'invention,
[FIG. 3 A] La figure 3 A illustre d’autres étapes du procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur selon un mode particulier de réalisation de l'invention, [FIG. 3B] La figure 3B illustre d’autres étapes du procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur selon un autre mode particulier de réalisation de l'invention,
[FIG. 4] La figure 4 illustre un exemple d’un dispositif de gestion selon un mode particulier de réalisation de l’invention.
5. Description d'un mode de réalisation de l'invention
L’invention propose un procédé de gestion des autorisations d’accès à un service de paiement fourni à un utilisateur, aussi appelé utilisateur titulaire par la suite, pour permettre à des tiers (utilisateurs délégataires, utilisateurs bénéficiaires) de réaliser des transactions de paiement via le service de paiement fourni à l’utilisateur titulaire. En particulier, l’invention permet d’élargir la gamme de services offerts aux utilisateurs de système de paiement, et notamment aux systèmes de paiement basés sur un compte prépayé, en garantissant les contraintes d’identification, le contrôle des transactions et un niveau de sécurité équivalent aux mécanismes de transactions bancaires classiques.
Le procédé de gestion décrit ci-dessous offre un mécanisme sécurisé pour mettre en place une délégation de droits d’accès à un service de paiement utilisé par un utilisateur titulaire permettant à des tiers de réaliser des transactions en utilisant le service de paiement fourni à l’utilisateur titulaire tout en respectant certaines contraintes et en utilisant un identifiant et un code secret différent de celui de l’utilisateur titulaire. Le mécanisme est ainsi sécurisé et les transactions réalisées sont traçables. Autrement dit, l’identité du tiers demandant la réalisation de la transaction est authentifiée avant que la transaction soit exécutée.
Lorsque le fonctionnement du service de paiement est basé sur l’utilisation d’un compte authentifié auprès du fournisseur du service de paiement, compte prépayé ou non, le procédé de gestion décrit ci-dessous permet de mettre en place une délégation de droits d’accès au compte de l’utilisateur titulaire.
On décrit ci-après en relation avec la figure IA un exemple d'environnement de mise en œuvre de l'invention selon un mode particulier de réalisation de l'invention. L’environnement de la figure IA comprend un terminal TPI d’un utilisateur titulaire Pl. L’utilisateur titulaire PI possède un accès authentifié auprès d’un fournisseur de service de paiement, par exemple un service de paiement mobile. Dans le mode particulier de réalisation décrit ici, le service de paiement est basé sur utilisation d’un compte créé pour chaque utilisateur titulaire auprès du fournisseur de service, par exemple, un compte prépayé.
Dans un autre mode particulier de réalisation de l’invention, le service de paiement peut fonctionner sans nécessiter la création d’un compte. Dans ce cas, un utilisateur titulaire authentifié du service de paiement associe à ses données d’authentification auprès du service de paiement, un moyen de paiement associé à un compte bancaire ou à un compte d’un autre fournisseur de service (par exemple un opérateur de communications).
L’environnement comprend par exemple un ou des serveur(s) de paiement SP du fournisseur de service de paiement. Notamment, le serveur de paiement SP reçoit et exécute les ordres de paiement et répond aux demandes de consultation de solde de compte.
Lorsque le service de paiement n’est pas associé à un compte, une demande de consultation de solde de compte peut correspondre à une interrogation d’une disponibilité de solde ou d’un plafond autorisé par le moyen de paiement qui a été associé aux données d’authentification de l’utilisateur titulaire auprès du service de paiement.
Selon l’invention, c’est l’utilisateur titulaire, ici PI, qui autorise un tiers à initier une ou des transactions pour son compte en utilisant le service de paiement qui est fourni à l’utilisateur titulaire. L’environnement comprend également un utilisateur délégataire DI muni par exemple d’un terminal TD1. L’utilisateur délégataire DI ne possède pas obligatoirement de compte authentifié auprès du fournisseur du service de paiement. Selon l’invention, cet utilisateur DI reçoit, par exemple sur son terminal TD1, des données d’accès provisoires au service de paiement ou au compte de l’utilisateur Pl. De telles données provisoires comprennent notamment un alias public et un code secret associé à cet alias public. Lors de la mise en place de la délégation d’accès ou autorisation d’accès, l’utilisateur délégataire DI reçoit le droit d’initier une ou des transactions via le service de paiement de l’utilisateur titulaire Pl.
Selon un mode de réalisation particulier de l’invention, l’environnement comprend également un utilisateur bénéficiaire Bl, muni d’un terminal TB1. L’utilisateur bénéficiaire possède des données d’authentification auprès d’un fournisseur de service de paiement, qui peut être identique ou différent du fournisseur de service de paiement auprès duquel l’utilisateur titulaire PI possède des données d’authentification, et un compte authentifié selon le cas. L’utilisateur bénéficiaire B1 est apte à recevoir un paiement ordonné par l’utilisateur délégataire DI et payé via le service de paiement fourni à l’utilisateur titulaire PL Lorsque le service de paiement est associé à un compte authentifié, ce paiement est payé via le compte de l’utilisateur titulaire, sinon via le moyen de paiement associé aux données d’authentification de l’utilisateur titulaire.
Sous certaines conditions, l’utilisateur bénéficiaire B1 peut vérifier la solvabilité du compte de l’utilisateur titulaire Pl.
Dans un mode particulier de réalisation de l’invention, l’utilisateur bénéficiaire B1 est identique à l’utilisateur délégataire DI.
L’environnement comprend également un dispositif de gestion SERV, géré par le fournisseur de service de paiement fournissant le service de paiement à l’utilisateur titulaire Pl. Ce serveur SERV réalise la mise en place de l’autorisation d’accès au service de paiement fourni à l’utilisateur titulaire Pl par la génération et la gestion d’alias publics, la génération de codes secrets associés et leur sécurisation et la gestion des contraintes spécifiques fixées pour l’utilisation des alias générés.
Dans un mode particulier de réalisation de l’invention, le dispositif de gestion SERV est compris dans le serveur SP du fournisseur de service de paiement.
Le serveur SERV répond aux requêtes:
D’un utilisateur titulaire : pour donner l’autorisation d’accès d’un tiers au service de paiement fourni à l’utilisateur titulaire, en initialisant un (ou des) alias public de l’identifiant personnel de l’utilisateur titulaire diffusable aux utilisateurs délégataires identifiés et un code secret provisoire associé à G alias public/aux alias publics,
D’un utilisateur délégataire : pour demander l’exécution d’une transaction en fournissant G alias public reçu et le code secret provisoire associé. Le serveur vérifie que les conditions d’utilisations (seuils, montant, date ...) sont conformes aux conditions fixées lors de la mise en place de l’autorisation d’accès, D’un utilisateur bénéficiaire : lorsque celui-ci est un utilisateur différent d’un utilisateur délégataire, pour demander l’exécution d’une demande de paiement/transaction à échéance en fournissant l’alias public reçu.
La mise en place d’une autorisation d’accès au service de paiement fourni à l’utilisateur titulaire PI peut être réalisée via les terminaux TPI, TD1 et TB1 des différents utilisateurs en jeu, par exemple via une application dédiée fournie par le fournisseur de service de paiement de l’utilisateur titulaire PL Une telle application comprend notamment, pour le titulaire, un formulaire de déclaration d’un tiers et de saisie d’informations d’identification d’utilisateurs délégataires.
Selon une variante, lors de la saisie pour l’initialisation d’une autorisation d’accès, l’application peut permettre à l’utilisateur titulaire de préciser un type de délégation, tel que prélèvement, caution, carte de paiement..., ainsi que des contraintes spécifiques d’utilisation telles que durée, périodicité, montant maximum alloué... L’application comprend également, pour le bénéficiaire ou le délégataire, un ou des formulaires permettant la saisie d’un alias en lieu et place de l’identification courante (par exemple MSISDN) et du code secret associé à cet alias, ainsi qu’une interface permettant de demander l’exécution d’un ordre de paiement ou une consultation de solde pour vérifier un solde disponible.
Les terminaux TPI, TB1 et TD1 communiquent avec le serveur SERV via un réseau de communication RES.
Selon le mode particulier de réalisation décrit ici, il y a un utilisateur titulaire PI et un utilisateur délégataire DI. Selon d’autres variantes, l’utilisateur titulaire PI peut autoriser l’accès à son service de paiement à plusieurs utilisateurs délégataires Dl,
D2, ...
Selon un autre mode particulier de réalisation décrit, un même utilisateur délégataire Dl peut être autorisé par plusieurs utilisateurs titulaires PI, P2, ..., PN, à utiliser leur service de paiement. La figure IB illustre un exemple de mise en œuvre d’un tel mode particulier de réalisation de l’invention. L’environnement de la figure IB comprend par exemple en plus des éléments déjà présentés en relation avec la figure IA, un nombre N d’utilisateurs titulaires PI à PN munis respectivement d’un terminal TPi, i allant de 1 à N, N étant un nombre entier supérieur à 1. Selon cet exemple, l’utilisateur délégataire DI reçoit l’autorisation d’utiliser le service de paiement ou le compte de chacun des utilisateurs titulaires PI,.. PN.
Selon une variante de réalisation, les autorisations reçues par l’utilisateur délégataire DI sur chacun des comptes des utilisateurs titulaires PI,..., PN sont agrégées en un compte agrégé permettant à un utilisateur bénéficiaire Bl, par exemple équipé d’un terminal TB1, de demander l’exécution d’une transaction sur le compte agrégé issu des comptes des utilisateurs titulaires PI,..., PN.
La figure 2A illustre des étapes du procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur selon un mode particulier de réalisation de l'invention. Le procédé est ici décrit dans le cas où le service de paiement est associé à un compte.
Dans le mode particulier de réalisation de l’invention décrit ici, l’utilisateur titulaire PI demande la mise en place d’une autorisation de prélèvement au bénéfice de l’utilisateur délégataire DI.
Par exemple, il s’agit d’autoriser un fournisseur de services à demander l’exécution d’un paiement à échéance (facture) sur le compte de l’utilisateur titulaire Pl.
Le procédé décrit ci-dessous s’applique bien entendu à d’autres types d’autorisations.
Lors d’une étape E200, l’utilisateur titulaire Pl envoie, via son terminal TPI, une requête d’initialisation d’une autorisation d’accès. Une telle requête comprend notamment un identifiant de l’utilisateur délégataire DI et l’identifiant de l’utilisateur titulaire Pl. Selon la variante décrite ici, l’utilisateur titulaire Pl indique le type d’autorisation demandée, ici autorisation de prélèvement, et définit des paramètres optionnels associés au type d’autorisation. Par exemple, l’utilisateur titulaire Pl indique un montant maximum par demande d’exécution, une périodicité ou autorisation d’une exécution d’un ordre de paiement par unité de temps, une durée de validité de l’autorisation, une somme maximale allouée à l’autorisation, etc....
De préférence, l’identifiant de l’utilisateur délégataire DI fourni est un identifiant authentifié auprès du fournisseur de service de paiement auprès duquel l’utilisateur titulaire Pl est également authentifié. Autrement dit, l’utilisateur délégataire dispose d’un compte authentifié auprès de cet opérateur. Sur réception de la requête, lors d’une étape E210, le serveur génère des données temporaires d’accès au compte associées à l’utilisateur délégataire Dl. En particulier, le serveur génère un alias ou aussi appelé identifiant public, à partir de l’identifiant de l’utilisateur titulaire PL Cet alias est associé à l’utilisateur délégataire Dl.
Pour cela, le serveur encode au moyen d’une clé propre au serveur, sélectionnée parmi une liste de clés disponibles, l’identifiant authentifié de l’utilisateur titulaire PI pour produire un alias public selon un format cible fonction du type d’autorisation. Lors d’une étape E220, le serveur envoie au terminal de l’utilisateur titulaire PI, une demande de confirmation de la requête d’initialisation d’autorisation d’accès. L’utilisateur titulaire PI confirme sa requête lors d’une étape E230, par l’envoi au serveur d’un message de confirmation comprenant le code confidentiel (code secret) de l’utilisateur titulaire PL Ces échanges permettent à l’utilisateur titulaire PI de signer sa requête d’initialisation d’autorisation d’accès.
Lors d’une étape E240, le serveur génère alors un code secret provisoire associé à l’alias généré lors de l’étape E210. Pour cela, le serveur encode, à l’aide de la clé sélectionnée, le code secret de l’utilisateur titulaire PI pour produire un nouveau code secret de même taille associé à cet alias sous la forme de 4 digits par exemple. Par exemple, les données temporaires associées à l’utilisateur délégataire peuvent être de la forme suivante : pour l’alias : un code à 8 chiffres (dans le cas d’un identifiant classique) ou un code à 16 chiffres (dans le cas d’un identifiant correspondant à un identifiant de carte « corporate » - corporative en français-), et pour le code secret temporaire : 4 digits.
Lors d’une étape E250, le serveur enregistre alors les données associées à cette autorisation : identifiant de l’utilisateur titulaire PI alias (identifiant public) temporaire généré, index de la clé utilisée pour l’encodage, les paramètres d’utilisation définis par l’utilisateur titulaire Pl.
Pour des contraintes de sécurité, le serveur n’enregistre jamais en clair le code secret de l’utilisateur titulaire PI, ni le code secret temporaire généré mais conserve un moyen de le déchiffrer à la volée lors de l’exécution d’une transaction à partir des données reçues (alias + code secret temporaire associé). Lors d’une étape E260, le serveur diffuse alors, via le réseau RES, vers l’utilisateur délégataire DI et l’utilisateur titulaire PI, G alias généré, correspondant ici pour une autorisation de prélèvement, à une agrégation de l’ alias généré et du code secret provisoire.
En variante, l’alias public est envoyé par le serveur, via le réseau RES, à l’utilisateur titulaire PI qui se charge de le transmettre à l’utilisateur bénéficiaire, via le réseau RES ou tout autre réseau de communication adapté.
Lorsqu’il n’est pas agrégé à l’alias, le code secret temporaire généré est envoyé directement par le serveur par un moyen sécurisé à l ‘utilisateur délégataire.
A l’issue des étapes décrites ci-dessus, la mise en place de l’autorisation d’accès au compte de l’utilisateur titulaire PI se traduit par l’émission d’un ticket d’autorisation (combinaison de l’alias associé à l’utilisateur délégataire DI et du code secret temporaire), non prélevé sur le compte de l’utilisateur titulaire PL Autrement dit, la somme est toujours disponible pour l’utilisateur titulaire Pl.
On décrit maintenant en relation avec la figure 3A la consommation de ce ticket d’autorisation. Toute demande de consommation de ce ticket est soumise à validation au moment du prélèvement, par exemple vérification du solde disponible, des critères d’utilisation...
L’utilisateur délégataire DI voulant procéder à un paiement sur le compte de l’utilisateur titulaire Pl, lors d’une étape E270, l’utilisateur délégataire DI saisit ses identifiants sur l’application de son terminal TD1: l’identifiant public (alias) reçu, le code secret provisoire reçu, le montant du paiement.
Lors d’une étape E280, le serveur obtient la clé de chiffrement utilisée à partir de l’index de clé qui a été mémorisé avec l’identifiant public reçu. Il obtient ensuite l’identifiant et le code confidentiel de l’utilisateur titulaire, en décodant l’identifiant public et le code secret provisoire reçus à partir de la clé de chiffrement obtenue.
Lors d’une étape E290, le serveur vérifie les conditions d’utilisation associées à l’alias public: validité, montant, périodicité du paiement, etc... Si les conditions sont valides, lors d’une étape E291, le serveur transmet un ordre d’exécution de paiement du montant au bénéfice de l’utilisateur délégataire Dl, via le compte de l’utilisateur titulaire PL Pour cela, le serveur SERV transfère la demande de paiement à un serveur de transaction de paiement SP, avec le code secret et l’identifiant décodés de l’utilisateur titulaire PI et demande l’exécution du paiement au nom de l’utilisateur titulaire PI du compte.
Lors d’une étape E292, le serveur de transaction de paiement SP transfère la somme du compte de l’utilisateur titulaire PI vers le compte du titulaire délégataire Dl.
Selon un mode particulier de réalisation de l’invention, l’utilisateur titulaire du compte est notifié et reçoit une demande de validation de la transaction (non représentés en figure 3A).
Lorsque les conditions vérifiées à l’étape E290 ne sont pas valides, la transaction, ici un prélèvement, est rejetée. Lors d’une étape E292’, le serveur notifie l’utilisateur délégataire Dl et l’utilisateur titulaire PL
Selon un mode particulier de réalisation de l’invention, un utilisateur bénéficiaire/délégataire peut vérifier la solvabilité d’un utilisateur titulaire, par exemple avant d’effectuer une demande de prélèvement.
L’utilisateur bénéficiaire saisit les données temporaires reçues comprenant l’ alias et le code secret provisoire.
Le serveur reçoit cette demande et procède à l’extraction de l’identifiant de l’utilisateur titulaire et de son code secret.
Le serveur demande une vérification de compte et de solde au nom de l’utilisateur titulaire et transfère le résultat sous une forme OK/KO à l’utilisateur bénéficiaire/délégataire, via le réseau RES.
La figure 2B illustre des étapes du procédé de gestion d’une autorisation d’accès à un compte d’un utilisateur selon un autre mode particulier de réalisation de l'invention. Selon ce mode particulier de réalisation de l’invention, un utilisateur délégataire Dl demande une autorisation d’accès à plusieurs utilisateurs titulaires Pi, i allant de 1 à N. Par exemple, un entrepreneur (utilisateur délégataire Dl) demande à des investisseurs (utilisateurs titulaires Pi) de mettre à sa disposition une certaine somme pour l’aider à développer son activité. Les investisseurs s’engagent à lui fournir tout ou partie de cette somme qui ne sera pas prélevée de leur compte, ni même bloquée, mais la somme apparait comme virtuellement disponible sur le compte de l’entrepreneur auprès du fournisseur de service de paiement.
La mise en place des autorisations sur les comptes des utilisateurs titulaires se fait de manière similaire à celle décrite en relation avec la figure 2A.
Pour chaque utilisateur titulaire Pi, les étapes suivantes E180i et E190i sont mises en œuvre.
Lors de l’étape E180i, le terminal TD1 de l’utilisateur délégataire DI envoie au serveur SERV une requête d’initialisation d’une autorisation d’accès au compte de l’utilisateur titulaire Pi, la requête comprenant l’identifiant de l’utilisateur délégataire Dl, l’identifiant de l’utilisateur titulaire Pi et un montant de transaction de paiement. Lors de l’étape E190i, le serveur SERV envoie au terminal de l’utilisateur titulaire Pi, un message informant l’utilisateur titulaire Pi de la requête envoyée par l’utilisateur délégataire Dl en indiquant l’identifiant de l’utilisateur délégataire Dl, et le montant de transaction de paiement.
Si l’utilisateur titulaire Pi accepte la demande d’autorisation d’accès à son compte, il est procédé aux étapes E200i, E210i, E220i, E230i, E240i et E250L Ces étapes sont identiques aux étapes E200, E210, E220, E230, E240 et E250 décrites en relation avec la figure 2A.
Lors d’une étape E300, le serveur SERV crée un compte agrégé pour l’utilisateur délégataire Dl à partir des alias générés à partir de chaque utilisateur titulaire Pi, et des codes confidentiels temporaires associés. Ce compte agrégé comprend alors un nouvel alias correspondant à la concaténation des alias de chaque utilisateur titulaire Pi et un code secret provisoire généré à partir des codes confidentiels temporaires associés. Ce compte agrégé comprend également une concaténation d’index de clés et des règles de répartition pour l’exécution d’un paiement via le compte agrégé.
Lors d’une étape E310, le serveur mémorise les données temporaires du compte agrégé pour chaque type de délégation demandé par l’utilisateur délégataire Dl.
Par exemple, dans le mode particulier de réalisation décrit ici, une autorisation de consultation et une autorisation de paiement ont été demandées. Le serveur SERV initie donc les deux types d’autorisation avec les données temporaires du compte agrégé. Puis, le serveur SERV diffuse les données temporaires.
Pour une autorisation de consultation, lors d’une étape E320, le serveur SERV transmet au terminal de l’utilisateur délégataire Dl, une concaténation du nouvel alias et code secret provisoire du compte agrégé. Le terminal de l’utilisateur délégataire Dl transmet ces données, lors d’une étape E330, à l’utilisateur bénéficiaire Bl, via le réseau RES ou tout autre réseau adapté.
Pour une autorisation de paiement, lors d’une étape E340, le serveur SERV transmet au terminal de l’utilisateur délégataire Dl le nouvel alias du compte agrégé. Il transmet ensuite, lors d’une étape E341, via un moyen sécurisé, le code secret provisoire du compte agrégé au terminal de l’utilisateur délégataire Dl.
On décrit maintenant en relation avec la figure 3B, les étapes d’utilisation des autorisations d’accès mises en place dans l’exemple de réalisation décrit en relation avec la figure 2B. Ici, deux utilisations sont possibles : caution ou dépôt de garantie et réserve de trésorerie.
Pour la caution ou dépôt de garantie, sur demande d’un fournisseur de service (utilisateur bénéficiaire Bl), l’entrepreneur (utilisateur délégataire Dl) va apporter une garantie sur la base de la caution pour la fourniture/G utilisation d’un bien ou d’un service. Pour cela, lors de la phase d’initialisation décrite en relation avec la figure 3 A, le fournisseur de service reçoit un code d’autorisation de prélèvement (alias et code secret provisoire) sur le compte agrégé lui permettant de vérifier le statut des comptes cautionnaires ou d’exécuter un paiement selon les conditions prévues.
Pour la réserve de trésorerie, l’entrepreneur utilise le compte de l’entreprise pour son activité et s’il dépasse le plafond disponible sur son propre compte, il a la possibilité d’utiliser la réserve d’argent mise à sa disposition par les cautionnaires (utilisateurs titulaires Pi). Le système répartit alors la demande d’utilisation de la réserve sur un ou plusieurs cautionnaires.
Si un cautionnaire refuse, la somme demandée est répartie sur les autres cautionnaires. Si un compte cautionnaire n’est pas suffisamment alimenté, la demande est rejetée pour ce compte et la somme demandée est répartie sur les autres cautionnaires. Si tous les cautionnaires acceptent, l’argent est transféré directement depuis les comptes des cautionnaires vers le compte du bénéficiaire. L’argent n’est pas directement versé sur le compte de l’entrepreneur.
On décrit ci-après les étapes mises en œuvre lors de ces deux cas d’usages.
Selon un premier exemple Cl, le bénéficiaire B1 souhaite consulter le solde du compte agrégé. Pour cela, lors d’une étape E350, il transmet au serveur SERV via son terminal TB1 une demande de statut de caution en indiquant G alias public et le code secret provisoire qui lui ont été communiqués. Lors d’une étape E351, le serveur SERV extrait à partir de G alias et du code secret provisoire, les index de clés utilisés pour générer les codes confidentiels provisoires et les identifiants publics de chaque utilisateur titulaire Pi.
Puis, pour chaque utilisateur titulaire Pi, lors d’une étape E352i, le serveur SERV décode l’identifiant de l’utilisateur titulaire Pi et son code secret et lors d’une étape E353i, le serveur vérifie auprès d’un serveur SB du fournisseur de service de paiement le solde du compte de l’utilisateur titulaire Pi. Lors d’une étape E354i, le serveur SERV renvoie au terminal de l’utilisateur bénéficiaire B1 le statut de la caution pour chaque utilisateur titulaire Pi.
En variante, le serveur SERV agrège les statuts des cautions de tous les utilisateurs titulaires interrogés et fournit à l’utilisateur bénéficiaire Bl, le statut global de la caution fournie par l’utilisateur délégataire Dl, par exemple en vérifiant que la somme totale disponible sur tous les comptes des utilisateurs titulaires est supérieure ou égale au montant requis dans la demande initiale transmise lors de l’étape E350.
Selon un deuxième exemple C2, l’utilisateur délégataire Dl souhaite utiliser sa réserve de trésorerie pour réaliser un paiement au bénéfice de l’utilisateur bénéficiaire Bl. Pour cela, lors d’une étape E360, l’utilisateur délégataire Dl transmet au serveur SERV via son terminal TD1 une demande de paiement en indiquant G alias public et le code secret provisoire qui lui ont été communiqués, ainsi que le montant du paiement. Lors d’une étape E361, le serveur SERV extrait à partir de G alias et du code secret provisoire, les index de clés utilisés pour générer les codes confidentiels provisoires et les identifiants publics de chaque utilisateur titulaire Pi.
Puis, pour chaque utilisateur titulaire Pi, lors d’une étape E362i, le serveur SERY décode l’identifiant de l’utilisateur titulaire Pi et son code secret et lors d’une étape E363i, le serveur vérifie que les conditions relatives à l’autorisation de délégation mises en place sont valides. Si c’est le cas, lors d’une étape E364i, le serveur SERV transmet au serveur SP un ordre d’exécution du paiement pour une partie du montant requis par l’utilisateur délégataire Dl. Lors d’une étape E365Î, le serveur SP déclenche l’exécution du paiement du compte de l’utilisateur titulaire Pi vers le compte du bénéficiaire B 1.
Selon un troisième exemple C3, l’utilisateur bénéficiaire B1 souhaite appliquer la caution qui lui a été fournie et demander la réalisation du paiement de la caution. Pour cela, lors d’une étape E370, l’utilisateur bénéficiaire B1 transmet au serveur SERV via son terminal TB1 une demande de paiement en indiquant G alias public et le code secret provisoire qui lui ont été communiqués, ainsi que le montant du paiement. Le serveur procède ensuite comme pour l’exemple C2 décrit ci-dessus.
Lors de l’étape E365i, le serveur SP déclenche l’exécution du paiement du compte de l’utilisateur titulaire Pi vers le compte du bénéficiaire Bl.
La figure 4 illustre un exemple d’un dispositif de gestion SERV selon un mode particulier de réalisation de l’invention. Selon ce mode particulier de réalisation de l'invention, le dispositif de gestion SERV a l'architecture classique d'un ordinateur, et comprend notamment une mémoire MEM, une unité de traitement UT, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur PG stocké en mémoire MEM. Le programme d'ordinateur PG comprend des instructions pour mettre en œuvre les étapes du procédé de gestion d’une autorisation qui est décrit ci- dessus, lorsque le programme est exécuté par le processeur PROC.
A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UT met notamment en œuvre les étapes du procédé de gestion d’une autorisation selon l'un quelconque des modes particuliers de réalisation décrits en relation avec les figures 2A, 2B, 3 A, 3B selon les instructions du programme d'ordinateur PG.
Le dispositif de gestion SERV comprend également un module de communication COM permettant au dispositif de gestion d’établir des communications, via un réseau de communications, par exemple un réseau de données fixes ou mobiles. Selon un mode particulier de réalisation de l’invention, le dispositif de gestion SERV est compris dans un serveur, par exemple un serveur d’un fournisseur de service de paiement.

Claims

REVENDICATIONS
1. Procédé de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur, dit utilisateur titulaire, le procédé étant mis en œuvre par un processeur d’un dispositif de gestion, le procédé comprenant :
- La réception, en provenance d’un terminal dudit utilisateur titulaire, d’une requête d’initialisation d’au moins une autorisation d’accès, ladite autorisation d’accès étant destinée à permettre à au moins un utilisateur délégataire d’accéder audit service de paiement fourni audit utilisateur titulaire, ladite requête comprenant au moins un identifiant dudit utilisateur délégataire et un identifiant dudit utilisateur titulaire,
- La génération de données temporaires d’accès au service de paiement associées audit utilisateur délégataire, lesdites données temporaires comprenant un identifiant public associé audit utilisateur délégataire, et un code confidentiel associé audit identifiant public,
- La transmission vers au moins un terminal de l’utilisateur délégataire ou d’un autre utilisateur desdites données temporaires.
2. Procédé de gestion selon la revendication 1, dans lequel la requête comprend en outre une indication d’un type d’autorisation d’accès et au moins un paramètre associé audit type d’autorisation d’accès.
3. Procédé de gestion selon la revendication 1 ou 2, comprenant en outre, préalablement à la transmission desdites données temporaires :
- L’envoi au terminal de l’utilisateur titulaire, d’une demande de confirmation de la requête d’initialisation,
- La réception, en provenance du terminal de l’utilisateur titulaire, d’un message de confirmation comprenant un code confidentiel dudit utilisateur titulaire d’accès audit service de paiement.
4. Procédé de gestion selon la revendication 3, dans lequel la génération des données temporaires comprend : - L’encodage dudit identifiant de l’utilisateur titulaire à l’aide d’une clé de chiffrement propre au dispositif de gestion pour former ledit identifiant public associé à l’utilisateur délégataire,
- L’encodage dudit code confidentiel de l’utilisateur titulaire à l’aide de ladite clé de chiffrement pour former ledit code confidentiel associé à l’identifiant public associé à l’utilisateur délégataire,
- La mémorisation dudit identifiant public associé à l’utilisateur délégataire et d’un index de clé identifiant ladite clé de chiffrement.
5. Procédé de gestion selon l’une quelconque des revendications 1 à 4, comprenant au préalable :
- La réception, en provenance d’un terminal dudit utilisateur délégataire, d’une requête d’initialisation d’une autorisation d’accès au service de paiement fourni à l’utilisateur titulaire, la requête comprenant l’identifiant dudit utilisateur délégataire, l’identifiant dudit utilisateur titulaire et un montant de transaction de paiement,
- L’envoi au terminal de l’utilisateur titulaire, d’un message informant l’utilisateur titulaire de la requête d’initialisation d’une autorisation d’accès envoyée par le terminal de l’utilisateur délégataire, le message comprenant l’identifiant dudit utilisateur délégataire, et un montant de transaction de paiement.
6. Procédé de gestion selon l’une quelconque des revendications 4 ou 5, dans lequel lorsque le dispositif de gestion reçoit au moins une autre requête d’initialisation d’au moins une autorisation d’accès, en provenance d’un terminal d’un autre utilisateur titulaire, et destinée à permettre audit utilisateur délégataire d’accéder audit service de paiement dudit autre utilisateur titulaire, ladite requête comprenant au moins l’identifiant dudit utilisateur délégataire et un identifiant dudit autre utilisateur titulaire, le procédé comprend en outre :
- La mémorisation d’un compte agrégé comprenant, pour chaque utilisateur titulaire, l’identifiant public généré à partir de l’identifiant dudit utilisateur titulaire et associé audit utilisateur délégataire, l’index de clé utilisée pour générer le code confidentiel associé à l’identifiant public associé à l’utilisateur délégataire à partir du code confidentiel de l’utilisateur titulaire.
7. Procédé de gestion selon l’une quelconque des revendications 2 à 6, comprenant en outre :
- La réception, en provenance d’un terminal d’un utilisateur bénéficiaire, d’une demande d’exécution de paiement comprenant l’identifiant public associé à l’utilisateur délégataire, le code confidentiel associé audit identifiant public et un montant de paiement,
- le décodage de l’identifiant de l’utilisateur titulaire et du code confidentiel de l’utilisateur titulaire, à partir de l’index de clé mémorisé, de l’identifiant public associé à l’utilisateur délégataire, et du code confidentiel associé audit identifiant public associé à l’utilisateur délégataire,
- la transmission d’un ordre d’exécution de paiement du montant à l’utilisateur bénéficiaire, via le service de paiement fourni à l’utilisateur titulaire à partir de l’identifiant de l’utilisateur titulaire et du code confidentiel de l’utilisateur titulaire décodés.
8. Dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur titulaire, comprenant une mémoire et un processeur configurés pour :
- recevoir, en provenance d’un terminal dudit utilisateur titulaire, une requête d’initialisation d’au moins une autorisation d’accès, ladite autorisation d’accès étant destinée à permettre à au moins un utilisateur délégataire d’accéder audit service de paiement fourni audit utilisateur titulaire, ladite requête comprenant au moins un identifiant dudit utilisateur délégataire et un identifiant dudit utilisateur titulaire,
- générer des données temporaires d’accès au compte associées audit utilisateur délégataire, lesdites données temporaires comprenant un identifiant public associé audit utilisateur délégataire, et un code confidentiel associé audit identifiant public,
- transmettre vers au moins un terminal de l’utilisateur délégataire ou d’un autre utilisateur lesdites données temporaires.
9. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de gestion d’autorisation d’accès selon l'une quelconque des revendications 1 à 7, lorsque le programme est exécuté par un processeur.
10. Support d’enregistrement lisible par ordinateur comportant un programme d’ordinateur selon la revendication 9.
EP20821056.7A 2019-12-19 2020-11-26 Procédé et dispositif de gestion d'une autorisation d'accès à un service de paiement fourni à un utilisateur Pending EP4078495A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1914842A FR3105513A1 (fr) 2019-12-19 2019-12-19 Procédé et dispositif de gestion d’une autorisation d’accès à un service de paiement fourni à un utilisateur.
PCT/FR2020/052177 WO2021123527A1 (fr) 2019-12-19 2020-11-26 Procede et dispositif de gestion d'une autorisation d'acces a un service de paiement fourni a un utilisateur

Publications (1)

Publication Number Publication Date
EP4078495A1 true EP4078495A1 (fr) 2022-10-26

Family

ID=70613949

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20821056.7A Pending EP4078495A1 (fr) 2019-12-19 2020-11-26 Procédé et dispositif de gestion d'une autorisation d'accès à un service de paiement fourni à un utilisateur

Country Status (4)

Country Link
US (1) US12481973B2 (fr)
EP (1) EP4078495A1 (fr)
FR (1) FR3105513A1 (fr)
WO (1) WO2021123527A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2025198681A1 (fr) * 2024-03-22 2025-09-25 The Provenance Chain Network, Inc. Utilisation d'un titre transférable unique pour commander l'accès à des données de produit

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009027082A1 (fr) * 2007-08-27 2009-03-05 Nec Europe Ltd Procédé et système pour délégation de ressources

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8086508B2 (en) * 2000-07-24 2011-12-27 Cashedge, Inc. Method and apparatus for delegating authority
US20040015702A1 (en) * 2002-03-01 2004-01-22 Dwayne Mercredi User login delegation
US7717337B2 (en) * 2006-11-15 2010-05-18 Song Yuh-Shen Anti-crime online transaction system
EP2026266B1 (fr) * 2007-07-27 2011-02-16 NTT DoCoMo, Inc. Procédé et appareil pour effectuer des transactions déléguées
US8769642B1 (en) * 2011-05-31 2014-07-01 Amazon Technologies, Inc. Techniques for delegation of access privileges
US20120330784A1 (en) * 2011-06-22 2012-12-27 Broadcom Corporation Mobile Device for Transaction Payment Delegation
US9466051B1 (en) * 2013-02-06 2016-10-11 Amazon Technologies, Inc. Funding access in a distributed electronic environment
US10909518B2 (en) * 2013-03-07 2021-02-02 Paypal, Inc. Delegation payment with picture
US9590992B2 (en) * 2014-04-07 2017-03-07 Marin Litoiu Systems and methods of precision sharing of big data
US10510072B2 (en) * 2014-09-29 2019-12-17 The Toronto-Dominion Bank Systems and methods for administering mobile applications using pre-loaded tokens
US11257085B1 (en) * 2015-12-11 2022-02-22 Wells Fargo Bank, N.A Systems and methods for authentication device-assisted transactions
US10417638B2 (en) * 2016-06-14 2019-09-17 Mastercard International Incorporated Method and system for real time fraud decisioning in transaction processing
KR102028151B1 (ko) * 2017-04-07 2019-10-02 주식회사트러스트홀딩스 장치 인증키를 이용한 데이터 암호화 방법 및 시스템
US20190370802A1 (en) * 2018-06-05 2019-12-05 Enpulz, Llc Payment intermediary device using delegate tokenization
SG11202006574PA (en) * 2019-07-02 2020-08-28 Alibaba Group Holding Ltd System and method for decentralized-identifier authentication
US11928666B1 (en) * 2019-09-18 2024-03-12 Wells Fargo Bank, N.A. Systems and methods for passwordless login via a contactless card

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009027082A1 (fr) * 2007-08-27 2009-03-05 Nec Europe Ltd Procédé et système pour délégation de ressources
EP2208336B1 (fr) * 2007-08-27 2018-03-07 NEC Corporation Procédé et système pour délégation de ressources

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2021123527A1 *

Also Published As

Publication number Publication date
US12481973B2 (en) 2025-11-25
FR3105513A1 (fr) 2021-06-25
WO2021123527A1 (fr) 2021-06-24
US20230009823A1 (en) 2023-01-12

Similar Documents

Publication Publication Date Title
CA3101638C (fr) Systeme de telecommunication et procede de reglement de transactions de session
EP3547203A1 (fr) Méthode et système de gestion d'accès à des données personnelles au moyen d'un contrat intelligent
DK2582115T3 (en) Qualified electronic signature system, associated method and mobile phone to qualified, electronic signature
US20190080321A1 (en) Authorization of use of cryptographic keys
EP1805965B1 (fr) Procede et systeme de communiction entre un dispositif de stockage securise d'informations et au moins un tiers, entite, dispositif et tiers correspondants
US20100223188A1 (en) Online Payment System and Method
EP0616714B1 (fr) Systeme de traitement d'informations utilisant un ensemble de cartes a memoire
US20180152429A1 (en) Systems and methods for publicly verifiable authorization
US11954672B1 (en) Systems and methods for cryptocurrency pool management
WO2002005152A1 (fr) Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
US20240346481A1 (en) Identity attestation using a token
WO2015059389A1 (fr) Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
WO2021123527A1 (fr) Procede et dispositif de gestion d'une autorisation d'acces a un service de paiement fourni a un utilisateur
WO2007125252A1 (fr) Procede et systeme de gestion d'un paiement electronique
FR3037754A1 (fr) Gestion securisee de jetons electroniques dans un telephone mobile
EP4359986B1 (fr) Procédé et dispositif de paiement par chaînes de blocs
EP1299837A1 (fr) Procede de distribution commerciale en ligne de biens numeriques par l'intermediaire d'un reseau de communication et dispositif electronique d'achat de biens numeriques distribues par ce procede
KR20240001416A (ko) 블록체인 기반의 nft를 이용한 음원 플랫폼의 서버에서 수행되는 서비스 제공 방법
EP1413158B1 (fr) Procede d'acces a un service specifique propose par un operateur virtuel et carte a puce d'un dispositif correspondant
FR3114714A1 (fr) Procédé d’accès à un ensemble de données d’un utilisateur.
EP2911365B1 (fr) Procédé et système de sécurisation de transactions offertes par une pluralité de services entre un appareil mobile d'un utilisateur et un point d'acceptation
WO2023247737A1 (fr) Methode et systeme d'assistance d'echanges controles de donnees
WO2012127025A2 (fr) Procede de generation et d'utilisation d'un titre dematerialise dans un dispositif portable et systeme de gestion de titres correspondant
FR3115625A1 (fr) Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte
EP3391316A1 (fr) Procédé de sécurisation d'une transaction depuis un terminal mobile

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

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