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/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/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/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)
• General Physics & Mathematics (AREA)
• Physics & Mathematics (AREA)
• Strategic Management (AREA)
• General Business, Economics & Management (AREA)
• Theoretical Computer Science (AREA)
• Finance (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Computer Networks & Wireless Communication (AREA)
• Marketing (AREA)
• Microelectronics & Electronic Packaging (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=8852225

Family Applications (1)

Country Status (7)

Families Citing this family (20)

Citations (2)

Family Cites Families (19)

• 2000
  • 2000-07-07 FR FR0008867A patent/FR2811451B1/fr not_active Expired - Fee Related
• 2001
  • 2001-07-09 EP EP01951781A patent/EP1299838A1/fr not_active Ceased
  • 2001-07-09 WO PCT/FR2001/002203 patent/WO2002005152A1/fr active Application Filing
  • 2001-07-09 KR KR10-2003-7000047A patent/KR20030029607A/ko not_active Application Discontinuation
  • 2001-07-09 KR KR1020097001501A patent/KR20090031588A/ko not_active Application Discontinuation
  • 2001-07-09 AU AU2001272633A patent/AU2001272633A1/en not_active Abandoned
  • 2001-07-09 JP JP2002508691A patent/JP2004503018A/ja active Pending
  • 2001-07-09 US US10/332,158 patent/US20040034597A1/en not_active Abandoned

Patent Citations (2)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events