WO2002005152A1 - Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants - Google Patents

Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants Download PDF

Info

Publication number
WO2002005152A1
WO2002005152A1 PCT/FR2001/002203 FR0102203W WO0205152A1 WO 2002005152 A1 WO2002005152 A1 WO 2002005152A1 FR 0102203 W FR0102203 W FR 0102203W WO 0205152 A1 WO0205152 A1 WO 0205152A1
Authority
WO
WIPO (PCT)
Prior art keywords
tokens
merchant
wallet
customer
client
Prior art date
Application number
PCT/FR2001/002203
Other languages
English (en)
Inventor
Alain Durand
Original Assignee
Thomson Licensing 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 Thomson Licensing Sa filed Critical Thomson Licensing Sa
Priority to JP2002508691A priority Critical patent/JP2004503018A/ja
Priority to AU2001272633A priority patent/AU2001272633A1/en
Priority to KR10-2003-7000047A priority patent/KR20030029607A/ko
Priority to US10/332,158 priority patent/US20040034597A1/en
Priority to EP01951781A priority patent/EP1299838A1/fr
Publication of WO2002005152A1 publication Critical patent/WO2002005152A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/29—Payment schemes or models characterised by micropayments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3572—Multiple accounts on card
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0866—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means by active credit-cards adapted therefor

Definitions

  • the field of the invention is that of managing micropayment transactions.
  • the invention relates to a system and method for managing micropayment transactions using at least one financial intermediary, at least one customer, and at least one merchant of goods and / or services.
  • micropayment is meant here a payment of a reduced amount, for example from a few fractions of cents to a few tens or hundreds of francs (or a reduced amount in any other currency of exchange). It can in particular implement an exchange of tokens constituting an electronic transaction currency.
  • micropayment and / or macropayment transaction systems implemented through communication networks, such as for example the global Internet network, has raised the problem of the security of transactions between customers and merchants, as well as the security of the information exchanged during these transactions.
  • one of the main problems of transaction security is the possibility for a merchant and / or a client of the system to copy a token (or any other unit of currency) and to use it fraudulently for two transactions distinct.
  • micropayment systems such as Millicent, SubScrip, PayWord, MicroMint, or the iKP micropayment protocol (registered trademarks).
  • CyberCoin or Mondex registered trademarks
  • Millicent registered trademark
  • Tokens specific to a given merchant, are exchanged during micropayment transactions.
  • a customer can obtain tokens of a given type, which allow him to pay a particular merchant, from a financial intermediary, in exchange for a macropayment. These tokens are then stored in the customer's wallet.
  • the micropayment transaction management system called
  • SubScrip does not involve a bank or financial intermediary.
  • a customer uses a macropayment process to open a temporary prepaid account with a given merchant.
  • a disadvantage of these two techniques of the prior art is that they are not suitable for transactions implemented between a single customer and a plurality of merchants.
  • Millicent registered trademark
  • a customer must obtain as many different tokens as the number of merchants from whom he wishes to purchase a good and / or service.
  • SubScrip registered trademark
  • a customer must open a prepaid account with each of the merchants with which he wishes to undertake micropayment transactions.
  • the PayWord (registered trademark) system overcomes this drawback by granting credit authorization to the customer, with a financial intermediary and / or a bank, which then guarantees payment to merchants.
  • MicroMint is superior to that of the iKP (registered trademarks) protocol, but this efficiency is acquired at the expense of the security of micropayment transactions.
  • a financial intermediary and / or a bank provides tokens to a customer, which can be used with all merchants. No verification of the validity of the tokens is undertaken during the transactions, making it possible to repeatedly use the same token.
  • a disadvantage of this technique of the prior art is therefore that the transactions are not secure, neither for the customer, nor for the merchant, who can receive in payment invalid tokens, because already previously used.
  • an object of the invention is to provide a system and a method for managing micropayment transactions which are simple, easy to use, and inexpensive to implement.
  • the invention relates to a micropayment transaction management system comprising at least one financial intermediary, at least one customer, and at least one merchant of goods and / or services, said transactions implementing token exchanges .
  • each of the customers has at least two separate token storage areas, these storage areas corresponding to two of the client's purses: a main purse and a secondary purse .
  • the primary wallet may include tokens provided by the financial intermediary to the customer, and the secondary wallet may include tokens provided by the merchant to the customer.
  • a client can thus have a reliable token storage area, containing tokens whose validity is assured, and a token storage area which can be assimilated to a credit, granted to the client by one or more merchants, and which may also contain information on transactions made with the merchant (s).
  • the security of transactions is thus increased for the customer, who is assured of having a resource of valid tokens, namely his main wallet, without fear, for example, that these tokens have been fraudulently copied and used two times by a merchant.
  • the customer also advantageously has an additional resource of tokens, corresponding to a credit which he can use with one or more merchants, namely his secondary wallet.
  • each of said merchants has at least two separate token storage areas.
  • at least a first merchant token storage zone corresponds to a merchant's wallet and at least a second merchant token storage zone corresponds to a merchant consignment file.
  • the merchant's wallet may include tokens provided by the financial intermediary to the merchant
  • the log file may include tokens provided by the customer to the merchant.
  • the tokens from the financial intermediary are separated from the tokens provided by the customer (s), so that the validity of the content of the merchant's wallet is guaranteed, the security of transactions being thus increased.
  • the invention also relates to a method for managing micropayment transactions in a system as described above.
  • the customer transmits to the merchant a first number P of tokens, corresponding to the price of the good and / or service, the first number P of tokens comes from the customer's first token storage area, corresponding to his main wallet and likely to contain tokens provided by the financial intermediary, if said main wallet contains a quantity of tokens greater than or equal to P; if said main purse contains a quantity of X tokens, less than P, the client transmits:
  • the customer thus primarily uses the tokens he has obtained from the financial intermediary to pay the merchant, but he can also make part or all of the payment using the tokens contained in the secondary wallet , which represent a credit he can use with the merchant.
  • the validity of the tokens supplied by the customer to the merchant cannot be guaranteed, the latter does not store the tokens received in his wallet, but in a consignment file.
  • the method comprises the steps consisting in: take a second number of tokens corresponding to said sum, from the first storage area of the merchant corresponding to his wallet; verify that said second number, added to the tokens of the customer's secondary wallet, does not exceed a predetermined maximum; said maximum not being exceeded, storing said second number in the customer's secondary wallet; if not:
  • the reimbursement transaction is secured, on the one hand, by the use of tokens extracted from the merchant's wallet (the customer is thus assured of the validity of the tokens he receives from the merchant), and on the other part, by the storage of the tokens received in the secondary wallet of the customer (the main wallet remains reserved for the tokens whose validity is directly guaranteed by the financial intermediary).
  • such a method further comprises a step of transferring tokens from the secondary wallet of the client to his main purse, comprising the following substeps: the client requests the financial intermediary to transfer the tokens contained in the secondary wallet to the main wallet; the financial intermediary checks the validity of said client request, on the one hand, and of said tokens contained in the secondary wallet, on the other hand; said validity being verified, the financial intermediary transfers the tokens from said secondary wallet to the main wallet.
  • such a step of transferring the tokens from the secondary wallet to the main wallet is always accompanied by validation of the tokens by the financial intermediary.
  • such a transfer step is implemented during each transaction between the client and the financial intermediary, so as to guarantee regular verification of the validity of the tokens provided by the or the merchands).
  • the method comprises the following steps: - the financial intermediary transmits the purchased tokens to the main wallet; the secondary wallet containing tokens, the financial intermediary checks the validity of said tokens, and, said tokens being valid, transfers said tokens from the secondary wallet to the main wallet.
  • the method comprises the following steps: - the financial intermediary verifies that the merchant's wallet contains at least N tokens; the verification being carried out, and the consignment file containing M tokens, M being a predetermined whole number, the financial intermediary credits the merchant's bank account with the value of (N + M) tokens, empties the consignment file, and withdraws No merchant wallet tokens.
  • the financial intermediary systematically performs a verification and emptying of the consignment file, which is particularly advantageous for the merchant.
  • the financial intermediary proceeds to a step of checking the validity of said at least one token contained in the secondary wallet and, in the event of positive verification, transfers said to minus one token from the secondary wallet to the primary wallet.
  • the financial intermediary automatically checks the content of the secondary wallet so as to transfer the content to the main wallet, which is advantageous for the customer.
  • the financial intermediary, the merchant and the client each hold a pair of asymmetric keys, said keys making it possible to sign the transactions implementing a bank account of the client and / or the merchant.
  • a message exchanged during one of said transactions between two parties is authenticated using a symmetric derivative key, determined from a master key and the identity of at least one of said two parts.
  • the key is derived from the client's identity.
  • the key is derived from the identity of the merchant. In this way, it is not necessary to store a master key in a customer terminal, and only a few master keys must be stored in merchant equipment.
  • each of said transactions is implemented using a specific symmetric key, said specific key can only be used for one of the transactions belonging to the group comprising: the financial intermediary transmits at least one token to the client's main wallet; the financial intermediary transmits at least one token to the merchant's wallet; the merchant requests payment of goods and / or services from the customer; the customer pays for goods and / or services to the merchant; the customer presents proof of purchase to the merchant; - the merchant reimburses the customer; the financial intermediary purchases at least some of the client's tokens; the financial intermediary redeems at least some of the merchant's tokens.
  • said symmetrical keys held by the customer and / or the merchant can only be used for one of the following operations: the production of data allowing authentication of the origin and the integrity of a message exchanged during one of said transactions; the verification of said data, so as to guarantee non-repudiation of said data.
  • a MAC can only have been generated by a single smart card, thus preventing a customer from repudiating a payment for example.
  • the symmetric keys could be used both for the generation and for the verification of MACs, at least two smart cards (respectively one at the customer and one at the merchant) could have generated a given MAC, which would allow a customer to refute a payment.
  • the invention also relates to a client terminal, in a micropayment transaction management system as described above, said transactions implementing token exchanges between at least one financial intermediary and / or at least one goods merchant and / or services and / or said customer.
  • the terminal comprises at least two separate token storage areas, corresponding to at least one main purse and at least one secondary purse, the main purse can include tokens supplied by the financial intermediary to said customer, and the secondary wallet may include tokens provided by the merchant to said customer.
  • said two storage areas are located in a secure processor contained in the terminal or in a data medium that can be read by the terminal.
  • such a data carrier can be a smart card, or any other secure data carrier.
  • the invention also relates to merchant equipment in a micropayment transaction management system as described above, said transactions implementing token exchanges between at least one financial intermediary and / or at least one customer, and / or said merchant, the equipment comprising at least two separate token storage areas.
  • two of said storage areas are a merchant purse and a merchant deposit file
  • the merchant purse can include tokens provided by the financial intermediary to the merchant
  • the consignment file can include tokens supplied by the customer to the merchant.
  • Figure 1 shows a block diagram of the transactions implemented according to the invention, when a customer wishes to make a purchase of goods and / or services from a merchant
  • Figure 2 shows a block diagram of the transactions implemented between the different players in Figure 1, when a merchant wishes to reimburse a customer
  • FIG. 3 illustrates the transactions implemented between the different actors in FIG. 1, when a customer and / or a merchant wishes to transfer the content of his wallet to his bank account.
  • the general principle of the invention is based on the existence of two separate token storage areas, for each client of a micropayment transaction management system. These two storage areas correspond to a main wallet of the customer, containing tokens supplied by a financial intermediary, and a secondary wallet, in which the customer stores the tokens which he has received from one or more merchants, for example for the reimbursement of unavailable merchandise, or as a prize in a game in which the client participated.
  • each of these two purses is associated with a predetermined maximum sum corresponding to the maximum number of tokens that each of the purses can contain.
  • an embodiment of a micropayment transaction from a client 2 to a merchant 3 is presented, implemented, for example, via the global Internet network.
  • a client 2 uses a terminal, which can for example consist of two entities: - a smart card, used as a means of secure data storage, and as a means of authenticating client 2. It is also conceivable that this smart card has other functionalities, such as the management of payment for television channels; a multimedia digital decoder, comprising a smart card reader, and capable of communicating with a merchant 3 and a financial intermediary 1.
  • Client 2 can also implement a micropayment transaction according to the invention from any other type of suitable terminal (including, for example, the means of the smart card).
  • block referenced 4 in FIG. 1 represents, for the sake of simplification, the bank of client 2 and / or of merchant 3. It can of course be envisaged that merchant 3 and client 2 are clients of the same bank 4 or from 4 different banks.
  • client 2 Before any purchase, if his primary purse and his secondary purse are empty, client 2 must obtain tokens from a financial intermediary 1. For this purpose, client 2 sends, during a stage referenced 12, to the financial intermediary 1, an authorization to debit his own bank account in a bank 4, for an amount equal to the value of the tokens he wishes to acquire. For example, client 2 signs an electronic check at the financial intermediary 1. The payment authorization transmitted by the client 2 gives the financial intermediary 1 all the information necessary to be paid by the bank 4 of the client 2.
  • the financial intermediary 1 After being paid by the bank 4, the financial intermediary 1 sends the client the desired tokens during a step referenced 13.
  • the customer 2 selects the good and / or the service that he wishes to acquire from the merchant 3, completes an order form and sends it to the merchant 3. For example, customer 2 completes an order form accessible from the merchant's website 3.
  • the merchant 3 requests payment for the good and / or service from customer 2.
  • the merchant 3 has equipment comprising several entities of the type: one or more smart cards, and / or secure processors, used as secure data storage areas, and / or as means of authentication of the merchant 3, and / or as data encryption means; a server, capable of processing transactions implemented simultaneously with several clients 2.
  • the customer 2 then proceeds to micropayment of the good and / or the service ordered during the step referenced 14.
  • the customer 2 sends to the merchant 3 a number of tokens corresponding to the value of the good and / or the service acquired, which he will have taken from his main wallet if the latter contains enough tokens. Otherwise, customer 2 takes tokens from his main wallet, until the latter is empty. If necessary, customer 2 takes the missing number of tokens from their secondary wallet in order to proceed to micropayment.
  • the merchant 3 After receiving the micropayment, the merchant 3 delivers to the customer 2 the good and / or the service ordered during a step referenced 15.
  • the tokens he received from the customer 2 are stored in a consignment file.
  • the merchant 3 may then wish that a bank account which he has in a bank 4 be credited with an amount corresponding to the value of the tokens received from the client 2. It is also conceivable that the merchant 3 keeps the tokens received from the client 2 , until you have a predetermined number of tokens, before crediting your bank account with the corresponding value.
  • the merchant 3 then presents the tokens contained in the consignment file, or a part of these tokens, to the financial intermediary 1, during a step referenced 16.
  • the merchant 3 can also present, in addition, tokens contained in his wallet.
  • Financial intermediary 1 checks the validity of the tokens received. After verification, during a step referenced 11, the financial intermediary 1 sends to the bank 4 a transfer order to the merchant's account 3, of an amount corresponding to the value of the valid tokens received.
  • the financial intermediary 1 also transmits to the merchant 3, during a step referenced 17, a copy of the transfer order addressed to the bank 4, to assure him that his bank account will be well credited.
  • the merchant 3 begins by filling his wallet with tokens, which he acquires from the financial intermediary 1. In fact, only the tokens which he purchases from the financial intermediary 1 can be used to reimburse a customer 2 The merchant 3 cannot use any tokens which would be stored in his consignment file to reimburse the client 2, which presents additional security for the client 2. For this purpose, the merchant 3 sends, during a step referenced 12, an authorization to pay to the financial intermediary 1. This authorization provides the financial intermediary 1 with all the information necessary to ask the bank 4 of the merchant 3 to withdraw money from a bank account of the merchant, during a step referenced 11.
  • the financial intermediary 1 then sends the merchant 3, during a step referenced 13, a number of tokens corresponding to the amount he received in payment, from the bank 4. These tokens are stored, by the merchant 3 , in his wallet.
  • the merchant's wallet is contained in a smart card.
  • the customer 2 provides proof of purchase to the merchant 3, during a step referenced 21, in order to justify that he must be reimbursed, or in order to present, for example, the winning lottery ticket available to him.
  • the merchant 3 can then micropay the client 2, during a step referenced 14. He transmits to the client 2 a number of tokens corresponding to the sum to be reimbursed, or to the value of the gain of the client 2.
  • the merchant 3 verifies that the number of tokens he wishes to transmit to the customer 2 is less than the maximum number of tokens that can be stored in the secondary wallet of the customer, or that the sum of this number of tokens and any tokens already contained in the customer's secondary wallet does not exceed the maximum number of tokens authorized. Otherwise, we can for example consider that the merchant 3 reimburses the customer 2 by implementing a method of macropayment not forming the subject of the present invention. We can also consider that the merchant 3 sends a message to the client 2 asking him to empty his secondary wallet, in order to be reimbursed, or in order to obtain his winnings. These tokens are stored in the customer's secondary wallet
  • the financial intermediary 1 After checking the validity of the tokens, the financial intermediary 1 transmits the number of valid tokens to the client 2 during a step referenced 22. These verified tokens are then stored by the client 2 in their main purse.
  • the client 2 may prefer that a bank account which he has in a bank 4 be credited with an amount corresponding to the value of the valid tokens.
  • the financial intermediary then sends during a step referenced 11 a transfer order to the bank 4 of the client 2. It can then be envisaged that he transmits to the client 2 a copy of this transfer order to assure him that his bank account will be well credited.
  • the validity of the tokens contained in the secondary wallet of the client 2 can also be verified by the financial intermediary 1 during each transaction involving the client 2 and the financial intermediary 1.
  • the transactions implemented are presented when the client 2 or the merchant 3 wishes the financial intermediary 1 to redeem all or part of the tokens contained in his wallet.
  • the client 2 or the merchant 3 transmits to the financial intermediary 1 a request to redeem a number N of tokens.
  • the financial intermediary 1 transmits to the client 2 and / or to the merchant 3 a confirmation of redemption of the N tokens.
  • the financial intermediary also sends to bank 4 of client 2 and / or of the merchant 3 a transfer order, so that the bank account of client 2 and / or of the merchant 3 be credited with a sum corresponding to the value of the number N of tokens redeemed.
  • N tokens can come from the main and / or secondary wallet of customer 2, as well as from the wallet and / or from the merchant's consignment file 3.
  • Tokens from the secondary wallet of customer 2 and from the Consignment of the merchant 3 is subject to verification by the financial intermediary 1, which determines their validity before crediting the bank accounts of the client 2 and / or of the merchant 3 with an amount corresponding to their value.
  • the invention facilitates the traceability of tokens, due to the existence of only four possible paths for a given token.
  • Such traceability advantageously makes it possible to increase the security of transactions undertaken between the different actors, namely the financial intermediary 1, and / or the client 2, and / or the merchant 3.
  • each token is created by the financial intermediary 1, and returns to the latter at the end of its life, according to one of the following mechanisms: - during a micropayment transaction, a token is issued by the intermediary financier 1, transmitted to client 2, then to merchant 3, who then refers him to financial intermediary 1; during a refund, a token is issued by the financial intermediary 1, transmitted to the merchant 3, then to the customer 2, who then returns it to the financial intermediary 1; in the event of redemption of the contents of client 2's wallet, a token created by financial intermediary 1, then stored in client's main purse 2, is returned to the financial intermediary
  • an audit of tokens is implemented in the following manner: when it transmits tokens to a given actor (customer 2 and / or merchant 3), financial intermediary 1 records the total number of tokens awarded to this actor, and updates this number when it buys tokens to the latter; - When verifying the validity of tokens, the financial intermediary 1 knows the identity of the actor to whom it initially awarded these tokens. He records the total number of tokens he has checked for this actor; financial intermediary 1 compares this total number of verified tokens with the total number of awarded tokens. If the actor considered is merchant 3, the total number of tokens verified must be less than the total number of tokens awarded.
  • the total number of tokens verified must be less than the sum of the total number of tokens awarded and the maximum number of tokens that can be stored in the secondary wallet of client 2.
  • the invention advantageously makes it possible to determine that tokens have been created by the actor considered (the client 2 and / or the merchant 3).
  • a cryptography method can also be implemented to secure at least some of the exchanges between the financial intermediary 1 and / or the merchant 3 and / or the client 2.
  • the financial intermediary 1 and / or the merchant 3 and / or the client 2 use a pair of asymmetric keys which they have.
  • a symmetric key is preferably used, derived from the identity of the a of the two actors and of a master key. For example, during a transaction involving client 2, a key is derived from the latter's identity. During a transaction involving the merchant 3 and the financial intermediary 1, a key is derived from the identity of the merchant 3.
  • each symmetric key is used specifically for a predetermined type of transaction and / or verification, such as: the storage of tokens in the main wallet of client 2 by the financial intermediary 1; storing tokens in the merchant's wallet 3 through the financial intermediary 1; the request for payment from the merchant 3 to the customer 2; micropayment of a purchase to the merchant 3 from the customer's primary and / or secondary wallet 2; validation of proof of purchase from client 2; the reimbursement of customer 2 by the merchant 3; the redemption of a client's tokens 2 by the financial intermediary 1; the redemption of a merchant's tokens 3 by the financial intermediary 1; - etc.
  • an error message management system is also implemented during all of the transactions illustrated in FIGS. 1 to 3.
  • error messages be sent to client 2 and / or financial intermediary 1 and / or merchant 3 if an error occurs during a transaction, such as: an error d 'authentication of data; during a micropayment, the client 2 does not have the number of tokens sufficient to pay the merchant 3; - the proof of purchase presented by the customer 2 to the merchant 3 is not valid, during a refund transaction; during a validation of tokens by the financial intermediary 1, some tokens are not valid; etc.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Marketing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un système et un procédé de gestion de transactions de micropaiement comprenant au moins un intermédiaire financier (1), au moins un client (2), et au moins un marchand (3) de biens et/ou de services, lesdites transactions mettant en oeuvre des échanges de jetons. Selon l'invention, chacun desdits clients (2) dispose d'au moins deux premières zones de stockage de jetons distinctes, correspondant à au moins un porte-monnaie principal et à au moins un porte-monnaie secondaire, ledit porte-monnaie principal pouvant comprendre des jetons fournis par ledit intermédiaire financier (1) audit client (2), et ledit porte-monnaie secondaire pouvant comprendre des jetons fournis par ledit au moins un marchand (3) audit client (2).

Description

Système et procédé de gestion de transactions de micropaiement, terminai de client et équipement de marchand correspondants.
Domaine de l'invention Le domaine de l'invention est celui de la gestion des transactions de micropaiement.
Plus précisément, l'invention concerne un système et un procédé de gestion de transactions de micropaiement mettant en œuvre au moins un intermédiaire financier, au moins un client, et au moins un marchand de biens et/ou de services.
Par micropaiement, on entend ici un paiement d'un montant réduit, par exemple de quelques fractions de centimes à quelques dizaines ou centaines de francs (ou un montant réduit dans toute autre monnaie d'échange). Il peut notamment mettre en œuvre un échange de jetons constituant une monnaie de transaction électronique.
Etat de la technique
L'émergence des systèmes de transactions de micropaiement et/ou de macropaiement mis en œuvre par le biais de réseaux de communication, tels que par exemple le réseau mondial Internet, a soulevé le problème de la sécurité des transactions entre clients et marchands, ainsi que de la sécurité des informations échangées au cours de ces transactions.
Notamment, l'un des problèmes principaux de la sécurité des transactions est la possibilité pour un marchand et/ou un client du système de copier un jeton (ou toute autre unité de monnaie d'échange) et de l'utiliser frauduleusement pour deux transactions distinctes.
De nombreux systèmes de gestion des transactions électroniques ont été proposés pour résoudre ce problème de sécurité, ou à tout le moins accroître la sécurité des transactions. Ces systèmes sont par exemple décrits dans l'ouvrage intitulé « Electronic Payment Systems » publié chez Artech House en 1997, et co-rédigé par Donal O'Mahony, Michael Peirce, et Hitesh Tewari.
Cet ouvrage distingue, d'une part, les systèmes de paiement électronique en espèces, tels que le système Ecash développé par la société DigiCash (marques déposées), le projet CAFE (en anglais « Conditional Access for Europe » signifiant littéralement « Accès Conditionnel pour l'Europe »), ou encore les systèmes NetCash, CyberCoin ou Mondex (marques déposées).
Il mentionne, d'autre part, des systèmes spécifiques de micropaiement, tels que Millicent, SubScrip, PayWord, MicroMint, ou encore le protocole de micropaiement iKP (marques déposées).
Dans l'ensemble des systèmes de paiement électronique en espèces existants, la sécurité des transactions est assurée par le biais d'une utilisation intensive de la cryptographie, aussi bien symétrique qu'asymétrique. Ainsi, dans le système Ecash (marque déposée), par exemple, de nombreuses signatures cryptées de la banque et/ou de l'intermédiaire financier, associées à de nombreux calculs de décryptage, sont mis en œuvre pour vérifier que chaque jeton circulant dans le système n'a été utilisé qu'une seule et unique fois. Par ailleurs, la banque et/ou l'intermédiaire financier opère une vérification systématique de la validité des jetons, au cours de chacune des transactions, en comparant le numéro de série des jetons à une base de données volumineuse regroupant l'ensemble des numéros de série de tous les jetons émis par le système. Un inconvénient de cette technique de l'art antérieur est donc que la sécurité des transactions est assurée au prix de la mise en œuvre de très nombreux calculs et cryptages, qui surchargent le système et le rendent coûteux, et donc inadapté aux transactions de micropaiement.
Un autre inconvénient de cette technique de l'art antérieur est qu'il est nécessaire de gérer une importante base de données regroupant tous les numéros de série des jetons émis par le système, ce qui est coûteux et complexe.
Dans le projet CAFE (en anglais « Conditional Access for Europe »), par exemple, la sécurité des transactions est assurée grâce à la mise en œuvre de terminaux résistants à toute falsification, et d'une cryptographie complexe. Un observateur, qui protège les intérêts de la banque et/ou de l'intermédiaire financier, est intégré dans le portefeuille de chaque client. Son rôle est d'assurer la validité de toutes les transactions entreprises par un client, si bien que ce dernier ne peut mettre en œuvre une transaction sans obtenir l'accord de l'observateur. Un inconvénient de cette technique de l'art antérieur, ainsi que des autres systèmes de paiement électronique en espèces tels que NetCash,
CyberCoin ou Mondex (marques déposées), est la lourdeur de la cryptographie mise en œuvre, ainsi que la complexité des terminaux utilisés, qui sont inadaptées aux transactions de micropaiement.
L'ouvrage « Electronic Payment Systems » présente par ailleurs des systèmes de gestion de transactions de micropaiement.
Le système appelé Millicent (marque déposée) met en œuvre trois acteurs : un client, un marchand, et un intermédiaire financier. Des jetons, spécifiques à un marchand donné, sont échangés au cours de transactions de micropaiement. Un client peut se procurer des jetons d'un type donné, qui lui permettent de payer un marchand particulier, auprès d'un intermédiaire financier, en échange d'un macropaiement. Ces jetons sont ensuite stockés dans le porte-monnaie du client. Le système de gestion des transactions de micropaiement appelé
SubScrip (marque déposée), en revanche, ne fait pas intervenir de banque ou d'intermédiaire financier. Un client utilise un procédé de macropaiement pour ouvrir un compte temporaire prépayé chez un marchand donné. Un inconvénient de ces deux techniques de l'art antérieur est qu'elles ne sont pas adaptées aux transactions mises en œuvre entre un unique client et une pluralité de marchands. En effet, dans le système Millicent (marque déposée), un client doit se procurer autant de jetons différents que le nombre de marchands auxquels il souhaite acheter un bien et/ou un service. De même, dans le système SubScrip (marque déposée), un client doit ouvrir un compte prépayé chez chacun des marchands avec lesquels il souhaite entreprendre des transactions de micropaiement.
Le système PayWord (marque déposée) pallie cet inconvénient en accordant une autorisation de crédit au client, auprès d'un intermédiaire financier et/ou d'une banque, qui garantit ensuite le paiement aux marchands.
II apparaît clairement qu'un inconvénient de cette technique de l'art antérieur est le manque de sécurité des transactions, notamment pour l'intermédiaire financier et/ou la banque, un grand nombre d'achats pouvant être effectué par un client sans que ce dernier ne dispose des fonds nécessaires sur son compte bancaire.
Dans le protocole de gestion des transactions de micropaiement iKP, la sécurité des transactions est accrue par rapport au système PayWord (marques déposées), notamment grâce à une authentification du client auprès d'un marchand, préalable à toute transaction.
Un inconvénient de cette technique est qu'une telle authentification nécessite de nombreux échanges de messages qui alourdissent et ralentissent le protocole, et rendent les transactions coûteuses. L'efficacité des transactions de micropaiement du système
MicroMint est supérieure à celle du protocole iKP (marques déposées), mais cette efficacité est acquise aux dépens de la sécurité des transactions de micropaiement. Un intermédiaire financier et/ou une banque fournit des jetons à un client, qui peuvent être utilisés auprès de tous les marchands. Aucune vérification de la validité des jetons n'est entreprise au cours des transactions, rendant possible une utilisation répétée d'un même jeton.
Un inconvénient de cette technique de l'art antérieur est donc que les transactions ne sont pas sécurisées, ni pour le client, ni pour le marchand, qui peuvent recevoir en paiement des jetons non valides, car déjà précédemment utilisés.
Il existe donc de nombreux systèmes et procédés de gestion des transactions de micropaiement, présentant des niveaux de sécurité et de complexité divers, dans lesquels un client dispose soit d'un porte-monnaie électronique, soit d'une autorisation de crédit, soit d'un compte prépayé chez un marchand. Mais on ne connaît à ce jour aucun système ou protocole de mise en œuvre simple, présentant une sécurité satisfaisante pour les différents acteurs des transactions (intermédiaire financier, client, marchand). L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur.
Plus précisément, un objectif de l'invention est de fournir un système et un procédé de gestion des transactions de micropaiement qui soient simples, faciles d'utilisation, et peu coûteux à mettre en œuvre. Exposé de l'invention
A cet effet, l'invention concerne un système de gestion de transactions de micropaiement comprenant au moins un intermédiaire financier, au moins un client, et au moins un marchand de biens et/ou de services, lesdites transactions mettant en œuvre des échanges de jetons. Selon l'invention, dans un tel système, chacun des clients dispose d'au moins deux zones de stockage de jetons distinctes, ces zones de stockage correspondant à deux porte-monnaie du client : un porte- monnaie principal et un porte-monnaie secondaire. Le porte-monnaie principal peut comprendre des jetons fournis par l'intermédiaire financier au client, et le porte-monnaie secondaire peut comprendre des jetons fournis par le marchand au client.
Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la gestion des transactions de micropaiement. En effet, un client peut ainsi disposer d'une zone de stockage de jetons fiable, contenant des jetons dont la validité est assurée, et d'une zone de stockage de jetons pouvant être assimilée à un crédit, accordé au client par un ou plusieurs marchands, et pouvant contenir en outre des informations sur les transactions effectuées avec le ou les marchands. La sécurité des transactions est ainsi accrue pour le client, qui est assuré de disposer d'une ressource de jetons valides, à savoir son porte- monnaie principal, sans craindre, par exemple, que ces jetons n'aient été frauduleusement copiés et utilisés deux fois par un marchand. Le client dispose également avantageusement d'une ressource complémentaire de jetons, correspondant à un crédit qu'il peut utiliser auprès d'un ou plusieurs marchands, à savoir son porte-monnaie secondaire.
Selon une caractéristique avantageuse de l'invention, chacun desdits marchands dispose d'au moins deux zones de stockage de jetons distinctes. Préférentiellement, au moins une première zone de stockage de jetons du marchand correspond à un porte-monnaie du marchand et au moins une deuxième zone de stockage de jetons du marchand correspond à un fichier de consignation du marchand. Le porte-monnaie du marchand peut comprendre des jetons fournis par l'intermédiaire financier au marchand, et le fichier de consignation peut comprendre des jetons fournis par le client au marchand. Ainsi, chez le marchand, les jetons provenant de l'intermédiaire financier sont séparés des jetons fournis par le ou les client(s), de sorte que la validité du contenu du porte-monnaie du marchand est garantie, la sécurité des transactions étant ainsi accrue. L'invention concerne également un procédé de gestion de transactions de micropaiement dans un système tel que décrit précédemment.
Selon un aspect de l'invention, au cours du paiement d'un bien et/ou d'un service acquis par le client auprès du marchand, le client transmet au marchand un premier nombre P de jetons, correspondant au prix du bien et/ou du service, le premier nombre P de jetons provient de la première zone de stockage de jetons du client, correspondant à son porte-monnaie principal et susceptible de contenir des jetons fournis par l'intermédiaire financier, si ledit porte-monnaie principal contient une quantité de jetons supérieure ou égale à P ; si ledit porte-monnaie principal contient une quantité de jetons X, inférieure à P, le client transmet :
X jetons provenant du porte-monnaie principal ; et - P - X jetons provenant de la deuxième zone de stockage de jetons du client, correspondant à son porte-monnaie secondaire et susceptible de contenir des jetons fournis par le marchand ; et le marchand stocke ledit premier nombre P de jetons transmis dans sa deuxième zone de stockage de jetons, correspondant au fichier de consignation.
Le client utilise ainsi prioritairement les jetons qu'il s'est procurés auprès de l'intermédiaire financier pour payer le marchand, mais il peut également effectuer une partie ou la totalité du paiement à l'aide des jetons contenus dans le porte-monnaie secondaire, qui représentent un crédit qu'il peut utiliser auprès du marchand. La validité des jetons fournis par le client au marchand ne pouvant être garantie, ce dernier ne stocke pas les jetons reçus dans son porte-monnaie, mais dans un fichier de consignation.
Dans un mode de réalisation avantageux de l'invention, lorsque le marchand souhaite rembourser une somme au client, le procédé comprend les étapes consistant à : prélever un second nombre de jetons correspondant à ladite somme, de la première zone de stockage du mardhand correspondant à son porte-monnaie ; vérifier que ledit second nombre, ajouté aux jetons du porte- monnaie secondaire du client, ne dépasse pas un maximum prédéterminé ; ledit maximum n'étant pas dépassé, stocker ledit second nombre dans le porte-monnaie secondaire du client ; sinon:
- interrompre le procédé, et rembourser le client en mettant en œuvre un procédé de macropaiement; ou
- envoyer un message au client lui demandant de vider son porte- monnaie secondaire afin de pouvoir être remboursé.
Ainsi, la transaction de remboursement est sécurisée, d'une part, par l'utilisation de jetons extraits du porte-monnaie du marchand (le client est ainsi assuré de la validité des jetons qu'il reçoit du marchand), et d'autre part, par le stockage des jetons reçus dans le porte-monnaie secondaire du client (le porte-monnaie principal reste réservé aux jetons dont la validité est directement garantie par l'intermédiaire financier).
Par ailleurs, l'invention prévoit avantageusement que le nombre maximum de jetons pouvant être stockés dans le porte-monnaie secondaire du client est limité, de manière à plafonner le crédit accordé par le ou les marchand(s) à un client donné. Une telle disposition permet donc de réduire les risques encourus par le marchand, et notamment les risques de paiement frauduleux. Avantageusement, un tel procédé comprend en outre une étape de transfert de jetons du porte-monnaie secondaire du client vers son porte- monnaie principal, comprenant les sous-étapes suivantes : le client demande à l'intermédiaire financier de transférer les jetons contenus dans le porte-monnaie secondaire vers le porte-monnaie principal ; l'intermédiaire financier vérifie la validité de ladite demande du client, d'une part, et desdits jetons contenus dans le porte-monnaie secondaire, d'autre part ; ladite validité étant vérifiée, l'intermédiaire financier transfère les jetons dudit porte-monnaie secondaire vers le porte-monnaie principal. Ainsi, selon l'invention, une telle étape de transfert des jetons du porte-monnaie secondaire vers le porte-monnaie principal s'accompagne toujours d'une validation des jetons par l'intermédiaire financier. Selon un mode de réalisation préférentiel de l'invention, une telle étape de transfert est mise en œuvre au cours de chaque transaction entre le client et l'intermédiaire financier, de façon à garantir une vérification régulière de la validité des jetons fournis par le ou les marchand(s).
Préférentiellement, lorsque le client souhaite acheter des jetons à l'intermédiaire financier, le procédé comprend les étapes suivantes : - l'intermédiaire financier transmet les jetons achetés vers le porte- monnaie principal ; le porte-monnaie secondaire contenant des jetons, l'intermédiaire financier vérifie la validité desdits jetons, et, lesdits jetons étant valides, transfert lesdits jetons du porte-monnaie secondaire vers le porte-monnaie principal.
De façon avantageuse, lorsque ledit marchand souhaite que son porte-monnaie soit débité de la valeur de N jetons pour les créditer sur son compte bancaire, N étant un nombre entier prédéterminé, le procédé comprend les étapes suivantes : - l'intermédiaire financier vérifie que le porte-monnaie du marchand contient au moins N jetons ; la vérification étant effectuée, et le fichier de consignation contenant M jetons, M étant un nombre entier prédéterminé, l'intermédiaire financier crédite le compte bancaire du marchand de la valeur de (N+M) jetons, vide le fichier de consignation, et retire N jetons du porte-monnaie du marchand.
Ainsi, outre l'opération requise par le marchand, l'intermédiaire financier procède systématiquement à une vérification et au vidage du fichier de consignation, ce qui est particulièrement avantageux pour le marchand.
De façon préférentielle, lorsque le client souhaite que son compte bancaire soit crédité de la valeur d'au moins un jeton contenu dans son porte-monnaie principal, et son porte-monnaie secondaire contenant au moins un jeton, l'intermédiaire financier procède à une étape de vérification de la validité dudit au moins un jeton contenu dans le porte- monnaie secondaire et, en cas de vérification positive, transfère ledit au moins un jeton du porte-monnaie secondaire vers le porte-monnaie principal.
Ainsi, outre l'opération requise par le client, l'intermédiaire financier vérifie automatiquement le contenu du porte-monnaie secondaire de manière à en transférer le contenu vers le porte-monnaie principal, ce qui est avantageux pour le client.
Dans un mode de réalisation avantageux de l'invention, l'intermédiaire financier, le marchand et le client détiennent chacun une paire de clefs asymétriques, lesdites clefs permettant de signer les transactions mettant en œuvre un compte bancaire du client et/ou du marchand.
En effet, les transactions mettant en œuvre un compte bancaire de l'une des parties traitent d'argent « réel », et non de monnaie électronique telle que les jetons. Elles nécessitent par conséquent de fortes propriétés de non-répudiation, en cas de conflit entre l'intermédiaire financier et l'une des autres parties, qui sont garanties par l'utilisation d'une cryptographie asymétrique.
Avantageusement, un message échangé au cours d'une desdites transactions entre deux parties est authentifié à l'aide d'une clef symétrique dérivée, déterminée à partir d'une clef maîtresse et de l'identité d'au moins l'une desdites deux parties.
Ainsi, dans le cas d'une transaction à laquelle participe un client, la clef est dérivée de l'identité du client. Dans le cas où la transaction fait intervenir l'intermédiaire financier et le marchand, la clef est dérivée de l'identité du marchand. De cette façon, il n'est pas nécessaire de stocker de clef maîtresse dans un terminal du client, et seules quelques clefs maîtresses doivent être stockées dans un équipement du marchand.
Préférentiellement, chacune desdites transactions est mise en œuvre à l'aide d'une clef symétrique spécifique, ladite clef spécifique ne pouvant être utilisée que pour l'une des transactions appartenant au groupe comprenant : l'intermédiaire financier transmet au moins un jeton vers le porte- monnaie principal du client ; l'intermédiaire financier transmet au moins un jeton vers le porte- monnaie du marchand ; le marchand demande le paiement d'un bien et/ou d'un service au client ; le client paye un bien et/ou un service au marchand ; le client présente une preuve d'achat au marchand ; - le marchand rembourse le client ; l'intermédiaire financier rachète au moins certains des jetons du client ; l'intermédiaire financier rachète au moins certains des jetons du marchand. De cette façon, chaque transaction de micropaiement utilisant une clef différente, la sécurité du procédé est fortement accrue : en effet, la compromission d'une seule clef ne compromettra pas l'intégralité du procédé, mais seulement la transaction correspondant à la clef compromise. Selon une technique avantageuse de l'invention, lesdites clefs symétriques détenues par le client et/ou le marchand ne peuvent être utilisées que pour l'une des opérations suivantes : la production d'une donnée permettant d'authentifier l'origine et l'intégrité d'un message échangé au cours d'une desdites transactions ; la vérification de ladite donnée, de façon à garantir une non-répudiation de ladite donnée.
L'utilisation sélective d'une clef pour la production ou la vérification d'une donnée d'authentification (en anglais MAC, 'Message Authentification Code'), qui permet de garantir la non-répudiation de cette donnée, est rendue possible, selon un mode de réalisation préférentiel de l'invention par le stockage des clefs du client (respectivement du marchand) sur une carte à puce du client (respectivement du marchand). L'impossibilité de modifier le code exécutable d'une carte à puce permet de destiner sélectivement une clef à la production ou à la vérification de la donnée d'authentification.
Ainsi, tant qu'une clef n'est pas compromise, un MAC ne peut avoir été généré que par une seule carte à puce, empêchant ainsi un client de répudier un paiement par exemple. Si, contrairement à la technique mise en œuvre selon l'invention, les clefs symétriques pouvaient être utilisées aussi bien pour la génération que pour la vérification des MAC, au moins deux cartes à puce (respectivement une chez le client et une chez le marchand) pourraient avoir généré un MAC donné, ce qui permettrait à un client de réfuter un paiement.
L'invention concerne encore un terminal de client, dans un système de gestion de transactions de micropaiement tel que décrit précédemment, lesdites transactions mettant en œuvre des échanges de jetons entre au moins un intermédiaire financier et/ou au moins un marchand de biens et/ou de services et/ou ledit client. Le terminal comprend au moins deux zones de stockage de jetons distinctes, correspondant à au moins un porte-monnaie principal et à au moins un porte-monnaie secondaire, le porte-monnaie principal peut comprendre des jetons fournis par l'intermédiaire financier audit client, et le porte-monnaie secondaire peut comprendre des jetons fournis par le marchand audit client. Avantageusement, lesdites deux zones de stockage sont localisées dans un processeur sécurisé contenu dans le terminal ou dans un support de données pouvant être lu par le terminal.
Notamment, un tel support de données peut être une carte à puce, ou tout autre support de données sécurisé. L'invention concerne également un équipement de marchand dans un système de gestion de transactions de micropaiement tel que décrit précédemment, lesdites transactions mettant en œuvre des échanges de jetons entre au moins un intermédiaire financier et/ou au moins un client, et/ou ledit marchand, l'équipement comprenant au moins deux zones de stockage de jetons distinctes.
Préférentiellement, deux desdites zones de stockage sont un porte- monnaie du marchand et un fichier de consignation du marchand, le porte- monnaie du marchand pouvant comprendre des jetons fournis par l'intermédiaire financier au marchand, et le fichier de consignation pouvant comprendre des jetons fournis par le client au marchand.
Brève description des dessins
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un synoptique des transactions mises en œuvre selon l'invention, lorsqu'un client souhaite effecteur un achat de bien et/ou de service auprès d'un marchand ; la figure 2 présente un synoptique des transactions mises en œuvre entre les différents acteurs de la figure 1, lorsqu'un marchand souhaite rembourser un client ; la figure 3 illustre les transactions mises en œuvre entre les différents acteurs de la figure 1 , lorsqu'un client et/ou un marchand souhaite transférer le contenu de son porte-monnaie vers son compte bancaire.
Description détaillée de modes de réalisation de l'invention
Le principe général de l'invention repose sur l'existence de deux zones de stockage de jetons distinctes, pour chaque client d'un système de gestion de transactions de micropaiement. Ces deux zones de stockage correspondent à un porte-monnaie principal du client, contenant des jetons fournis par un intermédiaire financier, et un porte-monnaie secondaire, dans lequel le client stocke les jetons qu'il a reçus d'un ou plusieurs marchands, par exemple pour le remboursement d'une marchandise non disponible, ou comme gain d'un jeu auquel le client a participé.
Λ chacun de ces deux porte-monnaie est associée une somme maximale prédéterminée correspondant au nombre maximum de jetons que chacun des porte-monnaie peut contenir.
On présente, en relation avec la figure 1, un mode de réalisation d'une transaction de micropaiement d'un client 2 vers un marchand 3, mise en œuvre, par exemple, par l'intermédiaire du réseau mondial Internet.
Pour participer à une transaction de micropaiement, un client 2 utilise un terminal, qui peut par exemple être constitué de deux entités : - une carte à puce, utilisée comme moyen de stockage de données sécurisé, et comme moyen d'authentification du client 2. On peut aussi envisager que cette carte à puce ait d'autres fonctionnalités, telles que la gestion du paiement de chaînes de télévision ; un décodeur numérique multimédia, comprenant un lecteur de carte à puce, et pouvant communiquer avec un marchand 3 et un intermédiaire financier 1.
Le client 2 peut aussi mettre en œuvre une transaction de micropaiement selon l'invention à partir de tout autre type de terminal adapté (intégrant par exemple les moyens de la carte à puce).
On notera que le bloc référencé 4 de la figure 1 représente, par souci de simplification, la banque du client 2 et/ou du marchand 3. On peut bien sûr envisager que le marchand 3 et le client 2 soient clients de la même banque 4 ou de banques 4 différentes.
Avant tout achat, si son porte-monnaie principal et son porte- monnaie secondaire sont vides, le client 2 doit se procurer des jetons auprès d'un intermédiaire financier 1. Dans ce dessein, le client 2 envoie, au cours d'une étape référencée 12, à l'intermédiaire financier 1 , une autorisation de débiter un compte bancaire qui lui est propre dans une banque 4, d'un montant égal à la valeur des jetons qu'il souhaite acquérir. Par exemple, le client 2 signe un chèque électronique à l'intermédiaire financier 1. L'autorisation de paiement transmise par le client 2 donne à l'intermédiaire financier 1 toutes les informations nécessaires pour se faire payer par la banque 4 du client 2.
Après avoir été payé par la banque 4, l'intermédiaire financier 1 envoie au client 2, au cours d'une étape référencée 13, les jetons souhaités.
Au cours d'étapes non-représentées sur la figure 1 , le client 2 sélectionne le bien et/ou le service qu'il souhaite acquérir auprès du marchand 3, remplit un bon de commande et l'envoie au marchand 3. Par exemple, le client 2 remplit un bon de commande accessible depuis le site Web du marchand 3. Le marchand 3 demande alors le paiement du bien et/ou du service au client 2. Pour participer à une transaction de micropaiement selon l'invention, on peut envisager que le marchand 3 dispose d'un équipement comprenant plusieurs entités du type : une ou plusieurs cartes à puce, et/ou processeurs sécurisés, utilisés comme zones de stockage de données sécurisés, et/ou comme moyens d'authentification du marchand 3, et/ou comme moyens de cryptage de données ; un serveur, capable de traiter les transactions mises en œuvre simultanément avec plusieurs clients 2.
Le client 2 procède alors au micropaiement du bien et/ou du service commandé au cours de l'étape référencée 14. Dans ce dessein, le client 2 envoie au marchand 3 un nombre de jetons correspondant à la valeur du bien et/ou du service acquis, qu'il aura prélevé de son porte-monnaie principal si ce dernier contient suffisamment de jetons. Dans le cas contraire, le client 2 prélève des jetons de son porte-monnaie principal, jusqu'à ce que ce dernier soit vide. Le cas échéant, le client 2 prélève le nombre de jetons manquant de son porte- monnaie secondaire afin de procéder au micropaiement.
Après réception du micropaiement, le marchand 3 délivre au client 2 le bien et/ou le service commandé au cours d'une étape référencée 15. Les jetons qu'il a reçus du client 2 sont stockés dans un fichier de consignation.
Le marchand 3 peut alors souhaiter qu'un compte bancaire dont il dispose dans une banque 4 soit crédité d'un montant correspondant à la valeur des jetons reçus du client 2. On peut aussi envisager que le marchand 3 conserve les jetons reçus du client 2, jusqu'à disposer d'un nombre de jetons prédéterminé, avant de créditer son compte bancaire de la valeur correspondante.
Le marchand 3 présente alors les jetons contenus dans le fichier de consignation, ou une partie de ces jetons, à l'intermédiaire financier 1 , au cours d'une étape référencée 16. Le marchand 3 peut aussi présenter, en outre, des jetons contenus dans son porte-monnaie. L'intermédiaire financier 1 vérifie la validité des jetons reçus. Après vérification, au cours d'une étape référencée 11 , l'intermédiaire financier 1 envoie à la banque 4 un ordre de virement sur le compte du marchand 3, d'une somme correspondant à la valeur des jetons valides reçus. L'intermédiaire financier 1 transmet également au marchand 3, au cours d'une étape référencée 17, une copie de l'ordre de virement adressé à la banque 4, pour l'assurer que son compte bancaire sera bien crédité.
On décrit désormais, en relation avec la figure 2, les transactions mises en œuvre selon l'invention lorsqu'un marchand 3 souhaite rembourser un client 2, ou lui transmettre un nombre de jetons correspondant, par exemple, au gain du client 2 pour un jeu et/ou une loterie auxquels il a participé chez le marchand 3.
Le marchand 3 commence par remplir son porte-monnaie de jetons, qu'il acquière auprès de l'intermédiaire financier 1. En effet, seuls les jetons qu'il achète auprès de l'intermédiaire financier 1 peuvent être utilisés pour rembourser un client 2. Le marchand 3 ne peut pas utiliser d'éventuels jetons qui seraient stockés dans son fichier de consignation pour rembourser le client 2, ce qui présente une sécurité supplémentaire pour le client 2. Dans ce dessein, le marchand 3 envoie, au cours d'une étape référencée 12, une autorisation de paiement à l'intermédiaire financier 1. Cette autorisation fournit à l'intermédiaire financier 1 toutes les informations nécessaires pour demander à la banque 4 du marchand 3 de prélever de l'argent d'un compte bancaire du marchand, au cours d'une étape référencée 11.
L'intermédiaire financier 1 envoie alors au marchand 3, au cours d'une étape référencée 13, un nombre de jetons correspondant à la somme qu'il a reçue en paiement, de la banque 4. Ces jetons sont stockés, par le marchand 3, dans son porte-monnaie. Par exemple, le porte-monnaie du marchand est contenu dans une carte à puce.
Le client 2 fournit une preuve d'achat au marchand 3, au cours d'une étape référencée 21, afin de justifier qu'il doit bien être remboursé, ou afin de présenter, par exemple, le ticket de loterie gagnant dont il dispose. Le marchand 3 peut alors procéder au micropaiement du client 2, au cours d'un étape référencée 14. Il transmet au client 2 un nombre de jetons correspondant à la somme à rembourser, ou à la valeur du gain du client 2.
On peut envisager, que préalablement à cette transmission, le marchand 3 vérifie que le nombre de jetons qu'il souhaite transmettre au client 2 est inférieur au nombre maximum de jetons pouvant être stockés dans le porte-monnaie secondaire du client, ou que la somme de ce nombre de jetons et des jetons déjà éventuellement contenus dans le porte-monnaie secondaire du client n'excède pas le nombre maximum de jetons autorisé. Dans le cas contraire, on peut par exemple envisager que le marchand 3 rembourse le client 2 en mettant en œuvre un procédé de macropaiement ne faisant pas l'objet de la présente invention. On peut aussi envisager que le marchand 3 envoie un message au client 2 lui demandant de vider son porte-monnaie secondaire, afin de pouvoir être remboursé, ou afin d'obtenir son gain. Ces jetons sont stockés dans le porte-monnaie secondaire du client
2, qui peut aussi être contenu dans une carte à puce par exemple. La validité de ces jetons est vérifiée au cours de la première transaction mise en œuvre, par la suite, entre le client 2 et l'intermédiaire financier 1. Le client 2 présente alors les jetons contenus dans son porte-monnaie secondaire à l'intermédiaire financier 1 , au cours d'une étape référencée 16.
Après vérification de la validité des jetons, l'intermédiaire financier 1 transmet le nombre de jetons valides au client 2 au cours d'une étape référencée 22. Ces jetons vérifiés sont alors stockés par le client 2 dans son porte-monnaie principal.
Selon une variante de réalisation, le client 2 peut préférer qu'un compte bancaire dont il dispose dans une banque 4 soit crédité d'un montant correspondant à la valeur des jetons valides. L'intermédiaire financier envoie alors au cours d'une étape référencée 11 un ordre de virement à la banque 4 du client 2. On peut alors envisager qu'il transmette au client 2 une copie de cet ordre de virement pour l'assurer que son compte bancaire sera bien crédité.
La validité des jetons contenus dans le porte-monnaie secondaire du client 2 peut en outre être vérifiée par l'intermédiaire financier 1 au cours de chaque transaction faisant intervenir le client 2 et l'intermédiaire financier 1.
On présente en relation avec la figure 3 les transactions mises en œuvre lorsque le client 2 ou le marchand 3 souhaite que l'intermédiaire financier 1 lui rachète tout ou partie des jetons contenus dans son porte- monnaie.
Au cours d'une étape référencée 31 , le client 2 ou le marchand 3 transmet à l'intermédiaire financier 1 une demande de rachat d'un nombre N de jetons.
Au cours d'une étape référencée 32, l'intermédiaire financier 1 transmet alors au client 2 et/ou au marchand 3 une confirmation de rachat des N jetons. Au cours d'une étape référencée 11 , l'intermédiaire financier envoie par ailleurs à la banque 4 du client 2 et/ou du marchand 3 un ordre de virement, de façon à ce que le compte bancaire du client 2 et/ou du marchand 3 soit crédité d'une somme correspondant à la valeur du nombre N de jetons rachetés.
Ces N jetons peuvent provenir du porte-monnaie principal et/ou secondaire du client 2, ainsi que du porte-monnaie et/ou du fichier de consignation du marchand 3. Les jetons provenant du porte-monnaie secondaire du client 2 et du fichier de consignation du marchand 3 font l'objet d'une vérification de la part de l'intermédiaire financier 1, qui détermine leur validité avant de créditer les comptes bancaires du client 2 et/ou du marchand 3 d'une somme correspondant à leur valeur.
On notera que l'invention facilite la traçabilité des jetons, du fait de l'existence de seulement quatre chemins possibles pour un jeton donné. Une telle traçabilité permet avantageusement d'accroître la sécurité des transactions entreprises entre les différents acteurs, à savoir l'intermédiaire financier 1 , et/ou le client 2, et/ou le marchand 3.
En effet, chaque jeton est créé par l'intermédiaire financier 1 , et retourne à ce dernier en fin de vie, selon l'un des mécanismes suivants : - au cours d'une transaction de micropaiement, un jeton est émis par l'intermédiaire financier 1, transmis au client 2, puis au marchand 3, qui le renvoie alors à l'intermédiaire financier 1 ; au cours d'un remboursement, un jeton est émis par l'intermédiaire financier 1 , transmis au marchand 3, puis au client 2, qui le renvoie alors à l'intermédiaire financier 1 ; en cas de rachat du contenu du porte-monnaie du client 2, un jeton créé par l'intermédiaire financier 1 , puis stocké dans le porte- monnaie principal du client 2, est renvoyé à l'intermédiaire financier
1 ; - enfin, un jeton créé par l'intermédiaire financier 1 , et stocké dans le porte-monnaie du marchand 3, peut être racheté par l'intermédiaire financier 1.
On peut envisager, selon un mode de réalisation préférentiel de l'invention, qu'un audit de jetons soit mis en œuvre de la manière suivante : lorsqu'il transmet des jetons à un acteur donné (le client 2 et/ou le marchand 3), l'intermédiaire financier 1 enregistre le nombre total de jetons décerné à cet acteur, et met ce nombre à jour lorsqu'il rachète des jetons à ce dernier ; - lorsqu'il vérifie la validité de jetons, l'intermédiaire financier 1 connaît l'identité de l'acteur auquel il a initialement décerné ces jetons. II enregistre le nombre total de jetons qu'il a vérifiés pour cet acteur ; l'intermédiaire financier 1 compare ce nombre total de jetons vérifiés au nombre total de jetons décernés. Si l'acteur considéré est le marchand 3, le nombre total de jetons vérifiés doit être inférieur au nombre total de jetons décernés. Si l'acteur considéré est le client 2, le nombre total de jetons vérifiés doit être inférieur à la somme du nombre total de jetons décernés et du nombre maximum de jetons pouvant être stocké dans le porte-monnaie secondaire du client 2. Dans le cas contraire, l'invention permet avantageusement de déterminer que des jetons ont été créés par l'acteur considéré (le client 2 et/ou le marchand 3).
Selon l'invention, un procédé de cryptographie peut par ailleurs être mis en œuvre pour sécuriser au moins certains des échanges entre l'intermédiaire financier 1 et/ou le marchand 3 et/ou le client 2.
Par exemple, toutes les transactions faisant intervenir un compte bancaire du client 2 et/ou du marchand 3 sont protégées à l'aide d'une cryptographie asymétrique. En effet, de telles transactions mettent en œuvre de « véritables » sommes d'argent (par opposition à un nombre de jetons), et doivent donc présenter de fortes propriétés de non-répudiation. Selon un mode de réalisation préférentiel de l'invention, toutes les autres transactions seront protégées par cryptographie symétrique.
Pour toutes les transactions illustrées par les figures 1 à 3, mettant en œuvre un compte bancaire, l'intermédiaire financier 1 et/ou le marchand 3 et/ou le client 2 utilisent une paire de clefs asymétriques dont ils disposent.
Pour authentifier un message échangé au cours d'une transaction
(ne mettant pas en œuvre un compte bancaire) entre deux acteurs (l'intermédiaire financier 1 et/ou le client 2 et/ou le marchand 3), on utilise préférentiellement une clef symétrique, dérivée à partir de l'identité de l'un des deux acteurs et d'une clef maîtresse. Par exemple, au cours d'une transaction faisant intervenir le client 2, une clef est dérivée à partir de l'identité de ce dernier. Au cours d'une transaction faisant intervenir le marchand 3 et l'intermédiaire financier 1 , une clef est dérivée à partir de l'identité du marchand 3.
Selon un mode de réalisation préférentiel de l'invention, chaque clef symétrique est utilisée spécifiquement pour un type de transaction et/ou de vérification prédéterminé, tel que : le stockage de jetons dans le porte-monnaie principal du client 2 par l'intermédiaire financier 1 ; le stockage de jetons dans le porte-monnaie du marchand 3 par l'intermédiaire financier 1 ; la demande de paiement du marchand 3 au client 2 ; le micropaiement d'un achat au marchand 3 à partir du porte- monnaie principal et/ou secondaire du client 2 ; la validation d'une preuve d'achat du client 2 ; le remboursement du client 2 par le marchand 3 ; le rachat des jetons d'un client 2 par l'intermédiaire financier 1 ; le rachat des jetons d'un marchand 3 par l'intermédiaire financier 1 ; - etc.
Selon un mode de réalisation préférentiel de l'invention, un système de gestion de messages d'erreurs est également mis en œuvre au cours de toutes les transactions illustrées par les figures 1 à 3.
On peut par exemple envisager que des messages d'erreurs soient émis à destination du client 2 et/ou de l'intermédiaire financier 1 et/ou du marchand 3 si une erreur survient au cours d'une transaction, telle que : une erreur d'authentification des données ; au cours d'un micropaiement, le client 2 ne dispose pas du nombre de jetons suffisant pour payer le marchand 3 ; - la preuve d'achat présentée par le client 2 au marchand 3 n'est pas valide, au cours d'une transaction de remboursement ; au cours d'une validation de jetons par l'intermédiaire financier 1 , certains jetons ne sont pas valides ; etc.

Claims

REVENDICATIONS
1. Système de gestion de transactions de micropaiement comprenant au moins un intermédiaire financier (1), au moins un client (2), et au moins un marchand de biens et/ou de services (3), lesdites transactions mettant en œuvre des échanges de jetons, caractérisé en ce que chacun desdits clients (2) dispose d'au moins deux zones de stockage de jetons distinctes, au moins une première zone de stockage de jetons correspondant à au moins un porte-monnaie principal et au moins une deuxième zone de stockage de jetons correspondant à un porte-monnaie secondaire, ledit porte-monnaie principal pouvant comprendre des jetons fournis par ledit intermédiaire financier (1) audit client (2), et ledit porte-monnaie secondaire pouvant comprendre des jetons fournis par ledit au moins un marchand (3) audit client (2).
2. Système selon la revendication 1 , caractérisé en ce que chacun desdits marchands (3) dispose d'au moins deux zones de stockage de jetons distinctes.
3. Système selon la revendication 2, caractérisé en ce que au moins une première zone de stockage de jetons dudit marchand correspond à un porte-monnaie dudit marchand (3) et au moins une deuxième zone de stockage de jetons dudit marchand correspond à un fichier de consignation dudit marchand (3), ledit porte-monnaie dudit marchand (3) pouvant comprendre des jetons fournis par ledit intermédiaire financier (1) audit marchand (3), et ledit fichier de consignation pouvant comprendre des jetons fournis par ledit au moins un client (2) audit marchand (3).
4. Procédé de gestion de transactions de micropaiement dans un système selon la revendication 3, caractérisé en ce qu'au cours du paiement d'un bien et/ou d'un service acquis par ledit client (2) auprès dudit marchand (3), ledit client (2) transmet (14 - Fig. 1) audit marchand (3) un premier nombre P de jetons, correspondant au prix dudit bien et/ou dudit service; ledit premier nombre P de jetons provenant de la première zone de stockage de jetons dudit client, correspondant à son porte-monnaie principal et susceptible de contenir des jetons fournis par ledit intermédiaire financier (1), si ledit porte-monnaie principal contient une quantité de jetons supérieure ou égale à P ; si ledit porte-monnaie principal contient une quantité de jetons X, inférieure à P, ledit client transmet :
X jetons provenant dudit porte-monnaie principal ; et P - X jetons provenant de la deuxième zone de stockage de jetons dudit client, correspondant à son porte-monnaie secondaire et susceptible de contenir des jetons fournis par ledit marchand (3) ; et en ce que ledit marchand (3) stocke ledit premier nombre P de jetons transmis dans sa deuxième zone de stockage de jetons, correspondant audit fichier de consignation.
5. Procédé selon la revendication 4, caractérisé en ce que, ledit marchand (3) souhaitant rembourser (14 - Fig. 2) une somme audit client
(2), ledit procédé comprend les étapes consistant à : prélever un second nombre de jetons correspondant à ladite somme, de ladite première zone de stockage dudit marchand (3) correspondant à son porte-monnaie ; - vérifier que ledit second nombre, ajouté aux jetons dudit porte- monnaie secondaire dudit client, ne dépasse pas un maximum prédéterminé ; ledit maximum n'étant pas dépassé, stocker ledit second nombre dans ledit porte-monnaie secondaire dudit client ; sinon: - interrompre ledit procédé, et rembourser ledit client en mettant en œuvre un procédé de macropaiement; ou - envoyer un message audit client lui demandant de vider son porte-monnaie secondaire afin de pouvoir être remboursé.
6. Procédé selon l'une quelconque des revendications 4 ou 5, caractérisé en ce qu'il comprend en outre une étape de transfert de jetons dudit porte-monnaie secondaire vers ledit porte-monnaie principal, comprenant les sous-étapes suivantes : ledit client (2) demande audit intermédiaire financier (1) de transférer lesdits jetons contenus dans ledit porte-monnaie secondaire vers ledit porte-monnaie principal ; ledit intermédiaire financier (1) vérifie la validité de ladite demande dudit client (2), d'une part, et desdits jetons contenus dans ledit porte-monnaie secondaire, d'autre part ; ladite validité étant vérifiée, ledit intermédiaire financier (1) transfère lesdits jetons dudit porte-monnaie secondaire vers ledit porte- monnaie principal.
7. Procédé selon l'une quelconque des revendications 4 à 6, caractérisé en ce que, ledit client (2) souhaitant acheter des jetons audit intermédiaire financier (1), ledit procédé comprend les étapes suivantes : - ledit intermédiaire financier (1) transmet (13) lesdits jetons achetés vers ledit porte-monnaie principal ; ledit porte-monnaie secondaire contenant des jetons, ledit intermédiaire financier (1) vérifie la validité desdits jetons, et, lesdits jetons étant valides, transfert lesdits jetons dudit porte-monnaie secondaire vers ledit porte-monnaie principal.
8. Procédé selon l'une quelconque des revendications 4 à 7, caractérisé en ce que, ledit marchand (3) souhaitant que son porte- monnaie soit débité de la valeur de N jetons pour les créditer sur son compte bancaire, N étant un nombre entier prédéterminé, ledit procédé comprend les étapes suivantes : ledit intermédiaire financier (1) vérifie que ledit porte-monnaie dudit marchand (3) contient au moins N jetons ; la vérification étant effectuée, et ledit fichier de consignation contenant M jetons, M étant un nombre entier prédéterminé, ledit intermédiaire financier (1) crédite (11) le compte bancaire dudit marchand (3) de la valeur de (N+M) jetons, vide ledit fichier de consignation, et retire N jetons dudit porte-monnaie dudit marchand.
9. Procédé selon l'une quelconque des revendications 4 à 8, caractérisé en ce que, ledit client (2) souhaitant que son compte bancaire soit crédité de la valeur d'au moins un jeton contenu dans ledit porte- monnaie principal, et ledit porte-monnaie secondaire contenant au moins un jeton, ledit intermédiaire financier (1) procède à une étape de vérification de la validité dudit au moins un jeton contenu dans ledit porte- monnaie secondaire et, en cas de vérification positive, transfert ledit au moins un jeton dudit porte-monnaie secondaire vers ledit porte-monnaie principal.
10. Procédé selon l'une quelconque des revendications 4 à 9, caractérisé en ce que ledit intermédiaire financier (1), ledit marchand (3) et ledit client (2) détiennent chacun une paire de clefs asymétriques, lesdites clefs permettant de signer lesdites transactions mettant en œuvre un compte bancaire dudit client (2) et/ou dudit marchand (3).
11. Procédé selon l'une quelconque des revendications 4 à 10, caractérisé en ce qu'un message échangé au cours d'une desdites transactions entre deux parties est authentifié à l'aide d'une clef symétrique dérivée, déterminée à partir d'une clef maîtresse et de l'identité d'au moins l'une desdites deux parties.
12. Procédé selon l'une quelconque des revendications 4 à 113, caractérisé en ce que chacune desdites transactions met en œuvre une clef symétrique spécifique, ladite clef spécifique ne pouvant être utilisée que pour l'une des transactions appartenant au groupe comprenant : ledit intermédiaire financier (1) transmet (13 - Fig. 1 , 22 - Fig. 2) au moins un jeton vers ledit porte-monnaie principal dudit client (2) ; ledit intermédiaire financier (1) transmet (13 - Fig. 2) au moins un jeton vers ledit porte-monnaie dudit marchand (3) ; ledit marchand (3) demande le paiement d'un bien et/ou d'un service audit client (2) ; ledit client (2) paye (14 - Fig. 1) un bien et/ou un service audit marchand (3) ; - ledit client (2) présente une preuve d'achat (21) audit marchand
(3) ; ledit marchand (3) rembourse (14 - Fig. 2) ledit client (2) ; ledit intermédiaire financier (1) rachète au moins certains des jetons dudit client (2) ; - ledit intermédiaire financier (1) rachète au moins certains des jetons dudit marchand (3).
13. Procédé selon l'une quelconque des revendications 11 et 12, caractérisé en ce que lesdites clefs symétriques détenues par ledit client (2) et/ou ledit marchand (3) ne peuvent être utilisées que pour l'une des opérations suivantes : la production d'une donnée permettant d'authentifier l'origine et l'intégrité d'un message échangé au cours d'une desdites transactions ; la vérification de ladite donnée, de façon à garantir une non-répudiation de ladite donnée.
14. Terminal de client, dans un système de gestion de transactions de micropaiement, lesdites transactions mettant en œuvre des échanges de jetons entre au moins un intermédiaire financier (1) et/ou au moins un marchand (3) de biens et/ou de services et/ou ledit client (2), caractérisé en ce qu'il comprend au moins deux zones de stockage de jetons distinctes, correspondant à au moins un porte-monnaie principal et à au moins un porte-monnaie secondaire, ledit porte-monnaie principal pouvant comprendre des jetons fournis par ledit au moins un intermédiaire financier (1) audit client (2), et ledit porte- monnaie secondaire pouvant comprendre des jetons fournis par ledit au moins un marchand (3) audit client (2).
15. Terminal de client selon la revendication 14, caractérisé en ce que lesdites deux zones de stockage sont localisées dans un processeur sécurisé contenu dans ledit terminal ou dans un support de données pouvant être lu par ledit terminal.
16. Équipement de marchand dans un système de gestion de transactions de micropaiement, lesdites transactions mettant en œuvre des échanges de jetons entre au moins un intermédiaire financier (1) et/ou au moins un client (2), et/ou ledit marchand (3), caractérisé en ce qu'il comprend au moins deux zones de stockage de jetons distinctes.
17. Équipement de marchand selon la revendication 16, caractérisé en ce que deux desdites zones de stockage sont un porte- monnaie dudit marchand (3) et un fichier de consignation dudit marchand (3), ledit porte-monnaie dudit marchand (3) pouvant comprendre des jetons fournis par ledit intermédiaire financier (1) audit marchand (3), et ledit fichier de consignation pouvant comprendre des jetons fournis par ledit au moins un client (2) audit marchand (3).
PCT/FR2001/002203 2000-07-07 2001-07-09 Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants WO2002005152A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2002508691A JP2004503018A (ja) 2000-07-07 2001-07-09 少額決済処理を管理するためのシステム及び方法、並びに対応するクライアント端末及び小売商装置
AU2001272633A AU2001272633A1 (en) 2000-07-07 2001-07-09 System and method for managing micropayment transactions, corresponding client terminal and trader equipment
KR10-2003-7000047A KR20030029607A (ko) 2000-07-07 2001-07-09 마이크로지불 트랜젝션을 관리하는 시스템 및 방법 및이에 대응하는 고객용 단말기 및 판매인용 단말기
US10/332,158 US20040034597A1 (en) 2000-07-07 2001-07-09 System and method for managing micropayment transactions, corresponding client terminal and trader equipment
EP01951781A EP1299838A1 (fr) 2000-07-07 2001-07-09 Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0008867A FR2811451B1 (fr) 2000-07-07 2000-07-07 Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
FR00/08867 2000-07-07

Publications (1)

Publication Number Publication Date
WO2002005152A1 true WO2002005152A1 (fr) 2002-01-17

Family

ID=8852225

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/002203 WO2002005152A1 (fr) 2000-07-07 2001-07-09 Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants

Country Status (7)

Country Link
US (1) US20040034597A1 (fr)
EP (1) EP1299838A1 (fr)
JP (1) JP2004503018A (fr)
KR (2) KR20090031588A (fr)
AU (1) AU2001272633A1 (fr)
FR (1) FR2811451B1 (fr)
WO (1) WO2002005152A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013066910A1 (fr) * 2011-10-31 2013-05-10 Roam Data Inc Système et procédé d'incorporation de jetons à usage unique, de bons et de systèmes de récompense dans des systèmes de caisse de point de vente de marchand
US9076174B2 (en) 2007-02-26 2015-07-07 Zepfrog Corp. Method and service for providing access to premium content and dispersing payment therefore
US9195983B2 (en) 2011-04-05 2015-11-24 Roam Data Inc. System and method for a secure cardholder load and storage device
US10580049B2 (en) 2011-04-05 2020-03-03 Ingenico, Inc. System and method for incorporating one-time tokens, coupons, and reward systems into merchant point of sale checkout systems
EP3792857A1 (fr) * 2019-09-11 2021-03-17 Nxp B.V. Monnaie électronique efficace pouvant être partiellement dépensée

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8190893B2 (en) * 2003-10-27 2012-05-29 Jp Morgan Chase Bank Portable security transaction protocol
US8027918B2 (en) * 2004-08-30 2011-09-27 Google Inc. Micro-payment system architecture
US7640193B2 (en) * 2005-12-09 2009-12-29 Google Inc. Distributed electronic commerce system with centralized virtual shopping carts
US7949572B2 (en) * 2006-06-27 2011-05-24 Google Inc. Distributed electronic commerce system with independent third party virtual shopping carts
GB201105765D0 (en) * 2011-04-05 2011-05-18 Visa Europe Ltd Payment system
US9846799B2 (en) 2012-05-18 2017-12-19 Apple Inc. Efficient texture comparison
US9135496B2 (en) * 2012-05-18 2015-09-15 Apple Inc. Efficient texture comparison
US9715616B2 (en) 2012-06-29 2017-07-25 Apple Inc. Fingerprint sensing and enrollment
US10068120B2 (en) 2013-03-15 2018-09-04 Apple Inc. High dynamic range fingerprint sensing
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
WO2015179637A1 (fr) 2014-05-21 2015-11-26 Visa International Service Association Authentification hors ligne
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
JP6853422B1 (ja) * 2018-04-17 2021-03-31 ゴ カン，チャン オンライン取引情報保護システムおよびオンライン取引情報保護方法
KR102645868B1 (ko) * 2018-04-17 2024-03-07 강찬고 온라인 거래정보 보안 시스템 및 온라인 거래정보 보안방법
CA3147800A1 (fr) * 2019-09-10 2021-03-18 Karim Micheal SANFORD Systemes et procedes de gestion de fonds de competition

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999046720A1 (fr) * 1998-03-11 1999-09-16 Cha Technologies Services, Inc. Procede d'intermediation a appel automatique pour achats par reseau
US6016484A (en) * 1996-04-26 2000-01-18 Verifone, Inc. System, method and article of manufacture for network electronic payment instrument and certification of payment and credit collection utilizing a payment
EP0987642A2 (fr) * 1998-09-15 2000-03-22 Citibank, N.A. Méthode et système pour commercialiser une plate-forme de paiement électronique tel qu'un porte-monnaie électronique avec une marque existante

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3594727A (en) * 1968-04-16 1971-07-20 Edward L Braun Credit card banking system
JPH05324998A (ja) * 1992-05-19 1993-12-10 Dainippon Printing Co Ltd Ｉｃカードを用いた代金精算システム
JP3334013B2 (ja) * 1994-05-02 2002-10-15 日本電信電話株式会社 電子現金流通方法
JP3334018B2 (ja) * 1994-09-20 2002-10-15 日本電信電話株式会社 電子現金方法及び電子現金システム
US5710887A (en) * 1995-08-29 1998-01-20 Broadvision Computer system and method for electronic commerce
JPH09305666A (ja) * 1996-05-16 1997-11-28 Nippon Telegr & Teleph Corp <Ntt> 電子決済方法ならびにシステム
JP3599493B2 (ja) * 1996-09-10 2004-12-08 日本銀行 発行機関分離型番号登録式電子現金方法および利用者装置
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
GB9624127D0 (en) * 1996-11-20 1997-01-08 British Telecomm Transaction system
EP0972276A1 (fr) * 1997-03-26 2000-01-19 BRITISH TELECOMMUNICATIONS public limited company Systeme transactionnel
IL120585A0 (en) * 1997-04-01 1997-08-14 Teicher Mordechai Countable electronic monetary system and method
US6128391A (en) * 1997-09-22 2000-10-03 Visa International Service Association Method and apparatus for asymetric key management in a cryptographic system
JPH11110461A (ja) * 1997-10-01 1999-04-23 Fujitsu Ltd 二重財布を有する電子財布システム、その電子財布システムに適用されるｉｃカード、二重財布を有するｉｃカード取引装置、二重財布を有するｉｃカード取引システムおよびそのｉｃカード取引システムに適用されるｉｃカード
JP3483441B2 (ja) * 1997-10-16 2004-01-06 富士通株式会社 電子マネーの管理所有装置および管理所有方法
JP3396638B2 (ja) * 1997-12-26 2003-04-14 日本電信電話株式会社 利用者署名を用いた電子現金方法、その装置及び記録媒体
JP2000148936A (ja) * 1998-11-16 2000-05-30 Nippon Conlux Co Ltd 電子マネーの精算方法および装置
US7177838B1 (en) * 2000-01-26 2007-02-13 Paybyclick Corporation Method and apparatus for conducting electronic commerce transactions using electronic tokens
US7127236B2 (en) * 2001-12-26 2006-10-24 Vivotech, Inc. Micropayment financial transaction process utilizing wireless network processing

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6016484A (en) * 1996-04-26 2000-01-18 Verifone, Inc. System, method and article of manufacture for network electronic payment instrument and certification of payment and credit collection utilizing a payment
WO1999046720A1 (fr) * 1998-03-11 1999-09-16 Cha Technologies Services, Inc. Procede d'intermediation a appel automatique pour achats par reseau
EP0987642A2 (fr) * 1998-09-15 2000-03-22 Citibank, N.A. Méthode et système pour commercialiser une plate-forme de paiement électronique tel qu'un porte-monnaie électronique avec une marque existante

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
See also references of EP1299838A1 *
SIRBU M ET AL: "NETBILL: AN INTERNET COMMERCE SYSTEM OPTIMIZED FOR NETWORK- DELIVERED SERVICES", IEEE PERSONAL COMMUNICATIONS,IEEE COMMUNICATIONS SOCIETY,US, vol. 2, no. 4, 1 August 1995 (1995-08-01), pages 34 - 39, XP000517588, ISSN: 1070-9916 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9076174B2 (en) 2007-02-26 2015-07-07 Zepfrog Corp. Method and service for providing access to premium content and dispersing payment therefore
US9195983B2 (en) 2011-04-05 2015-11-24 Roam Data Inc. System and method for a secure cardholder load and storage device
US10580049B2 (en) 2011-04-05 2020-03-03 Ingenico, Inc. System and method for incorporating one-time tokens, coupons, and reward systems into merchant point of sale checkout systems
WO2013066910A1 (fr) * 2011-10-31 2013-05-10 Roam Data Inc Système et procédé d'incorporation de jetons à usage unique, de bons et de systèmes de récompense dans des systèmes de caisse de point de vente de marchand
EP3792857A1 (fr) * 2019-09-11 2021-03-17 Nxp B.V. Monnaie électronique efficace pouvant être partiellement dépensée
US11651354B2 (en) 2019-09-11 2023-05-16 Nxp B.V. Efficient partially spendable e-cash

Also Published As

Publication number Publication date
KR20030029607A (ko) 2003-04-14
EP1299838A1 (fr) 2003-04-09
FR2811451B1 (fr) 2002-11-29
JP2004503018A (ja) 2004-01-29
US20040034597A1 (en) 2004-02-19
AU2001272633A1 (en) 2002-01-21
KR20090031588A (ko) 2009-03-26
FR2811451A1 (fr) 2002-01-11

Similar Documents

Publication Publication Date Title
EP0865010B1 (fr) Systéme de paiement électronique sécurisé et procédé de mise en oeuvre
WO2002005152A1 (fr) Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants
US5956699A (en) System for secured credit card transactions on the internet
US6339765B1 (en) Method and apparatus for defining private currencies
JP2001524233A (ja) バーチャルプロパティシステム
EP1360665A1 (fr) Procede et systeme de telepaiement
WO1997033404A1 (fr) Procede et systeme de facturation pour reseaux de transmission de donnees
EP0814440B1 (fr) Procédé de rechargement de cartes prépayées virtuelles
EP0731580A1 (fr) Procédé de paiement dans une application télématique et dispositif de mise en oeuvre de ce procédé
EP2724305B1 (fr) Procede de transaction dematerialisee
EP1354288B1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
FR2811452A1 (fr) Systeme et procede de gestion de transaction de micropaiement, dispositifs client, marchand et intermediaire financier
EP2824625A1 (fr) Méthode de réalisation de transaction, terminal et programme d&#39;ordinateur correspondant
WO2004049273A1 (fr) Systeme de paiement electronique entre homologues
WO2005088568A1 (fr) Procede et systeme de micropaiement
WO2002046984A1 (fr) Procede securise de transaction entre un acheteur et un vendeur
WO2023099496A1 (fr) Procédé de traitement de preuve numérique, système et programme correspondant
KR20200040434A (ko) 엔터테인먼트 분야에서 이용되는 블록체인 플랫폼
WO2002023497A1 (fr) Billet electronique de valeur fiduciaire, protocole de paiement d&#39;achats par commerce electronique et systeme serveur correspondant
FR3074946A1 (fr) Methodes et systemes de transaction electronique
FR2831361A1 (fr) Jeton informatique
FR2787224A1 (fr) Systeme de transactions electroniques
FR2808144A1 (fr) Procede et systeme de paiement electronique
WO2009095747A1 (fr) Systeme informatique de modelisation et d&#39;exploitation de documents publics
WO2006005838A1 (fr) Systeme de paiement par suite de jetons

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 10332158

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 1020037000047

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2001951781

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2001951781

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1020037000047

Country of ref document: KR

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642