EP1412925A1 - Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre - Google Patents

Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre

Info

Publication number
EP1412925A1
EP1412925A1 EP02764977A EP02764977A EP1412925A1 EP 1412925 A1 EP1412925 A1 EP 1412925A1 EP 02764977 A EP02764977 A EP 02764977A EP 02764977 A EP02764977 A EP 02764977A EP 1412925 A1 EP1412925 A1 EP 1412925A1
Authority
EP
European Patent Office
Prior art keywords
operator
bank
electronic payment
network
certificates
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP02764977A
Other languages
German (de)
English (en)
Inventor
Christophe Cornillon
Brigitte Vermelle
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales DIS France SA
Original Assignee
Gemplus Card International SA
Gemplus 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 Gemplus Card International SA, Gemplus SA filed Critical Gemplus Card International SA
Publication of EP1412925A1 publication Critical patent/EP1412925A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • 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/10—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 together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • 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
    • 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/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities
    • 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/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • 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/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4093—Monitoring of device authentication
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • 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/018—Certifying business or products
    • 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/04—Billing or invoicing
    • 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/10—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 together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption

Definitions

  • the invention relates to a payment method providing a guarantee of payment to the merchant in the context of electronic commerce practiced from an electronic device such as a microcomputer, a mobile telephone, a personal assistant.
  • Electronic commerce consists of sending orders to a merchant from electronic equipment linked by a network to the merchant's electronic equipment.
  • Today trade is practiced more and more from the internet.
  • the first problem is to ensure security for the payer because the latter is required to communicate his credit card or bank account number so that a debit from his account can be carried out.
  • the second problem is to provide a guarantee of payment for the seller, that is to say for the merchant who provides goods or services to the customer.
  • the merchant sends a payment request to a financial institution, the latter sends this request to the mobile operator.
  • the payer receives a short SMS message on his mobile phone, enters his identification code (PIN code) and the transaction is signed by a secret key recorded in the subscriber identification card of the phone (SIM card).
  • SIM card subscriber identification card of the phone
  • the operator's server verifies the signature and sends an approval to the financial institution.
  • the settlement is managed by the financial institution.
  • the drawback of this payment circuit is that the authentication key used to sign the transaction is generated and known to the telephone operator. This means that the financial institution cannot give a payment guarantee to the merchant insofar as the signature can be reproduced by a third party.
  • a second known solution is the MOTO payment system, internet payment.
  • the MOTO: Mail Order Telephone Order system is the simplest system for making payments over the Internet. In fact, the system consists in communicating the credit card number by voice (on the telephone) or through the Internet, to the merchant when ordering.
  • This solution exists for electronic devices such as PCs and can of course be reproduced for transactions made with a mobile phone.
  • the disadvantage of this method comes from the fact that the presence of the card is not proven by the merchant because the authentication of the card holder is not carried out during the transaction. In this case either the payment guarantee is not insured for the merchant. And unfortunately there are a large number of frauds worldwide with the MOTO payment system which has just been described.
  • a third solution is known for payments on the Internet, this is the SET procedure: Secure Electronic Transaction.
  • This procedure corresponds to a payment protocol which has been developed by a consortium of companies such as Visa, MasterCard, Europay, IBM.
  • the SET protocol is dedicated to Internet commerce and provides a payment guarantee for the merchant.
  • This solution requires a very heavy logistical implementation for the merchant's server and for loading the payer's certificates.
  • the MOTO system (Mail Order Telephone Order) is, as we have seen, the traditional mode allowing remote payments to be made. Fraud with the MOTO system across the Internet and mobile phone networks (mainly for the prepaid market) has been growing faster in recent years. The payment card is considered not to be present for such purchases and thus, the bank cannot guarantee payment to merchants.
  • the proposed solution allows for the payment of goods and services. It is independent of the channel used to "place the order", ie microcomputer (PC) on the Internet or "face to face” in a shop, mobile phone, landline phone, personal assistant or mail.
  • PC microcomputer
  • the solution can also be used in countries for which bank credit cards are not yet widely developed.
  • the present invention aims to remedy the aforementioned drawbacks.
  • the present invention relates to a "global circuit" of payment from an electronic payment device allowing a guarantee of payment for the merchant.
  • the invention aims to remedy the problems stated by providing a solution based on existing technologies, but making it possible to drastically limit fraud in the case of mail-order sales.
  • the solution consists more particularly in providing two keys for authentication of the payer, a key dedicated to the telephone operator and a key dedicated to the financial organization. It can be a bank or any other organization, for example insurance. We will however talk in the following about banking to simplify and about banking key.
  • the two keys allow the creation of two certificates certl, cert2.
  • transaction certificates is meant a set of data characterizing the transaction unequivocally, the parties involved (in practice, the client and the merchant) and attesting that the client has been authenticated. In practice, this is data representative of the transaction and the merchant (amount, timestamp, merchant identifier, currency used %) and an electronic signature calculated on a fingerprint (i.e. a condensed) of these data and to ensure the integrity of the "transaction and to authenticate the client.
  • the certificate certl is therefore obtained with the key K1 and the certificate cert2 is obtained with the key K2.
  • the telephone operator can only verify the certificate with the operator key.
  • this solution can be applied to other networks allowing electronic commerce: purchase on the Internet, purchase by voice command and payment from a mobile telephone network (GSM or other).
  • GSM mobile telephone network
  • the subject of the invention is therefore a method of electronic payment of a merchant using a means of communication using a network of an operator and a financial organization mainly characterized in that it consists in a transaction to develop two certificates, one from a key operator, the other using a bank key, to transmit the first certificate to the operator and place the other certificate under the control of the other certificate in a secure manner.
  • certificates are produced by a smart card and in that the second certificate is stored on this card.
  • the second certificate is transmitted to the operator who keeps it on a database under the control and / or with the approval of the financial body.
  • the second certificate is sent to the bank either by the smart card or by the operator.
  • the means of payment is a mobile phone.
  • the mobile telephone comprises a subscriber identification smart card (for example SIM on a GSM network, UIM on a CDMA network, USIM on a 3G network), the network of the telecommunications operator is equipped with a server.
  • management and invoicing the process consisting: for the mobile telephone: to send the two certificates to the telecommunications operator, - for the management and invoicing server: to authenticate the card holder from the first certificate and send payment authorization to the financial institution.
  • Another object of the present invention relates to an electronic payment device comprising means allowing access to a network, mainly characterized in that it comprises at least two keys, an operator key K1, a bank key K2, for develop two certificates representative of a transaction.
  • the electronic payment device consists of a microcomputer or a mobile phone or a personal assistant.
  • the device constitutes a secure electronic chip support.
  • the device is able to prepare the certificates.
  • the subject of the invention is also a management and invoicing server connected to a network of a telecommunications operator for the invoicing of goods or services supplied by a merchant to a customer carrying out electronic transactions on the network by means of 'An electronic payment means, mainly characterized in that it comprises means for processing operator certificates relating to transactions, and in that it comprises means for checking bank certificates relating to said transactions.
  • Figure 1 illustrates the exchanges between the client's equipment, its bank and the telephone operator for the phase of registering a client with its bank and its telephone operator to enable electronic commerce;
  • FIG. 2 illustrates the exchanges between the equipment of the bank, the smart card personalization center and the mobile operator, for the card personalization phase
  • FIG. 3 illustrates the exchanges between the client's equipment, that of the telephone operator with which he is registered and that of his bank during a transaction
  • Figure 4 illustrates the exchanges between all the parties involved in the event of a payment dispute by the customer.
  • the example described below concerns electronic commerce with a mobile phone.
  • the proposed solution uses a Sim payment application
  • STK ToolKit
  • the SIM Tool Kit payment application program is loaded into a customer's SIM card during the card personalization step. This program can also be downloaded using the wireless network, this depending on the technical characteristics of the SIM card used.
  • the card holder's bank can format, sign and send payment requests using short messages.
  • Transactions carried out by the card holder are signed after presentation of the payment PIN by the customer.
  • the algorithm used for the preparation of certificates and in this case the generation of signatures is stored in a program memory of the card. It can be an algorithm implementing symmetric cryptography with the DES or 3DES algorithm or asymmetric cryptography with the RSA algorithm.
  • the point-of-sale reader body implements two main security functions: the authentication of the payment card involving the card and the reader and the authentication of the holder of this card.
  • the authentication of the bank card is based on a preliminary registration of the client, this is done once and for all.
  • the exchanges which are carried out during this recording step between the various equipment of the speakers are recalled in the following is illustrated by FIG. 1.
  • the authentication of the card holder is carried out with each transaction through or at least by means of the identification code dedicated to the card holder, this code having to be entered by the card holder.
  • This identification code also known as PINcode (Personal Identifier Number) will be called bank code in the rest of the description because it is provided by the bank to its client.
  • PINcode Personal Identifier Number
  • the STK program is preferably loaded into the SIM card at the time of personalization and this by the manufacturer of the card.
  • This program could be downloaded (Over The Air) on a terminal at a point of sale.
  • the customer cannot use this payment application until it is registered with the bodies involved in the payment circuit.
  • the main objectives of the registration are as follows: ensure that the bank details provided by the customer are valid (for example, the bank details of the account to be taken or the number of the bank card to be used and its expiration date ).
  • This information is sent either electronically or by post.
  • the customer sends a form (electronic on a secure link or paper) to his bank. This sending is symbolized by the exchange between the equipment A and B in FIG. 1. the storage of the data of the bank card and of the telephone numbers in the database 10 of the customer's bank and on the management system and invoicing 20 of the equipment C of the telecommunications operator, allowing the customer to know the bank identification code PIN code.
  • the customer has completed a paper or electronic form and sent it to his bank.
  • the customer card can then be authenticated.
  • the issuing bank is responsible for authenticating the card holder. Then, through the authentication mechanism which must be accepted by both parties (namely the bank and the telecommunications operator), the bank must inform the telecommunications operator concerned. The telecommunications operator is then able to activate the STK payment application over a radio link. This can be done locally (for example, by phone) through a dedicated STK menu and an activation code which can be bank identification code (PIN code).
  • PIN code bank identification code
  • the card holder knows his code at this stage and can then enter it from the keypad of his mobile phone.
  • the customer needs to know the bank identification code, ie his PIN code, to be able to use it later to carry out electronic commerce.
  • this bank identification code is an additional security in the proposed process since it is necessary to trigger the signatures of a transaction. It thus protects access to the signature keys Kl, K2 stored in the SIM card.
  • FIG. 2 illustrates a possible solution of the steps leading to the generation of the PIN code during the personalization of the SIM card and the generation of the signature keys K1 and K2.
  • the PIN code is generally diversified from a master identification code generated by the bank 100.
  • the personalization center 400 then generates the PIN code from the master code and a personal number of the card, namely the ICCid code (identification number of the integrated circuit of the card) or the IMSI code (International Mobile Subscriber Identifier) of the SIM card or any other possible identifier linked to the SIM card.
  • ICCid code identification number of the integrated circuit of the card
  • IMSI code International Mobile Subscriber Identifier
  • the issuing bank is able to calculate the bank identification code (PIN code) and send it by email to the card holder .
  • a better solution derived from the latter can be based on diversification from the master identification code and telephone number of the subscriber.
  • the bank code can be changed by the end customer (as is already the case for mobile phones. But in this case, the non-final code is in any case managed by the issuing bank and not by the bank). telecommunications operator.
  • FIG. 3 A functional diagram of the exchange mechanism carried out in the equipment A, B, C of the three parties, namely the card holder, the telephone operator and the banking organizations, is shown in FIG. 3.
  • the management and billing system 20 sends a payment request (1) to the mobile phone 2 through a server 21 capable of converting this information into short messages SMS (2) or any other transport protocol supported by the mobile to the phone mobile.
  • the holder of the mobile phone and rather, the card holder accepts the transaction and for this purpose enters his PIN code. This makes it possible to trigger the process of calculating the two signatures relating to the data characteristic of the accepted transaction.
  • An SMS message is sent by the mobile telephone to the server 21. This message contains the certificates certl and cert2, that is to say the data characteristic of the transaction and the two signatures calculated by the SIM card. One signature was calculated with the key Kl and the other with the key K2.
  • each client has two personal signature keys used for the generation of the signature relating to characteristics of the transaction.
  • the characteristic data of a transaction are for example the amount of the transaction, the date, the time, the identification of the merchant and the telephone number.
  • the secret banking key must not be known to the telecommunications operator.
  • the use of this K2 key is protected by the PINcode inside the SIM card. Payment requests can be managed by the classic MOTO system with offline validation.
  • the transaction can be carried out like a classic MOTO transaction.
  • the mobile telephone operator must additionally store the data of the digital transaction including the digital signature certl, in a dedicated database. It is expected that in the event of a dispute, the telecommunications operator will be able to return the digital signature cert2 of the digital transaction to the customer's bank.
  • the immediate advantage of the proposed solution is that the existing infrastructures for payment authorization requests do not need to be modified.
  • the digital signature cert2 is proof of payment by the card holder.

Landscapes

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

Abstract

L'invention concerne un procédé de paiement électronique d'un commerçant à l'aide d'un moyen de communication utilisant un réseau d'un opérateur et un organisme financier (banque, assurance...). Selon l'invention le procédé consiste lors d'une transaction à élaborer deux certificats, l'un à partir d'une clé opérateur, l'autre à partir d'une clé bancaire, à transmettre à l'opérateur le premier certificat et à placer sous contrôle de l'organisme financier l'autre certificat de manière sécurisée.

Description

PROCEDE ASSURANT UNE GARANTIE DE PAIEMENT POUR LE
COMMERCE ELECTRONIQUE NOTAMMENT PAR TELEPHONE MOBILE ET
SYSTEME DE MISE EN OEUVRE
L'invention concerne un procédé de paiement assurant une garantie de paiement au commerçant dans le cadre du commerce électronique pratiqué à partir d'un dispositif électronique tel qu'un micro-ordinateur, un téléphone mobile, un assistant personnel.
Le commerce électronique consiste à envoyer des commandes à un commerçant à partir d'un équipement- électronique relié par un réseau à l'équipement électronique du commerçant . Aujourd'hui le commerce est pratiqué de plus en plus à partir du réseau internet.
Deux problèmes sont alors rencontrés.
En effet, dans le cas du commerce électronique il est prévu que les paiements se fassent également de façon électronique c'est à dire à travers le réseau.
Le premier problème est d'assurer une sécurité pour le payeur car ce dernier est amené à communiquer son numéro de carte de crédit ou de compte bancaire pour qu'un débit de son compte puisse être réalisé. Le deuxième problème est d'assurer une garantie de paiement pour le vendeur c'est à dire pour le commerçant qui fournit une marchandise ou un service au client .
On s'intéresse dans ce qui suit à ce deuxième problème.
On va détailler maintenant un mécanisme de paiement avec un téléphone mobile.
Le commerçant envoie une demande de paiement à une institution financière, cette dernière envoie cette requête à l'opérateur de téléphonie mobile. Le payeur reçoit un message court SMS sur son téléphone mobile, il entre son code d'identification (code PIN) et la transaction est signée par une clé secrète enregistrée dans la carte d'identification d'abonné du téléphone (carte SIM). Le serveur de l'opérateur téléphonique vérifie la signature et envoie une approbation à l'institution financière. Le règlement est géré par l'institution financière. L' inconvénient de ce circuit de paiement vient de ce que la clé d' authentification utilisée pour la signature de la transaction est générée et connue de l'opérateur téléphonique. Ceci signifie que l'institution financière ne peut pas donner une garantie de paiement au commerçant dans la mesure où la signature peut être reproduite par un tiers.
Le manque de garantie du paiement pour le marchand est l'inconvénient majeur de ce mécanisme.
Une deuxième solution connue est le système de paiement MOTO, paiement par internet. Le système MOTO : Mail Order Téléphone Order est le système le plus simple pour effectuer des paiements par Internet. En effet le système consiste à communiquer le numéro de carte de crédit de façon vocale (au téléphone) ou à travers le réseau Internet, au commerçant lors de la commande. Cette solution existe pour des dispositifs électroniques tel que des PC et peut bien entendu être reproduite pour des transactions passées avec un téléphone mobile. L'inconvénient de cette méthode provient du fait que la présence de la carte n'est pas prouvée par le commerçant car 1 ' authentification du titulaire de la carte n'est pas réalisée pendant la transaction. Dans ce cas non plus la garantie de paiement n'est pas assurée pour le commerçant. Et malheureusement on dénombre un grand nombre de fraudes dans le monde entier avec le système de paiement MOTO qui vient d'être décrit. Une troisième solution est connue pour les paiements sur Internet, il s'agit de la procédure SET : Secure Electronic Transaction. Cette procédure correspond à un protocole de paiement qui a été développé par un consortium d'entreprises telles que Visa, MasterCard, Europay, IBM. Le protocole SET est dédié au commerce par Internet et fournit une garantie de paiement pour le commerçant. Cette solution nécessite une implémentation logistique très lourde pour le serveur du commerçant et pour le chargement des certificats du payeur.
L'inconvénient de cette méthode vient du fait qu'elle nécessite une lourde logistique impossible à implémenter sur des dispositifs portables tels qu'un assistant personnel ou un téléphone mobile GSM ou autre ni sur un téléphone WAP nouvelle technologie.
Bien entendu une quatrième solution classiquement utilisée en dehors du commerce électronique consiste à payer directement chez le commerçant avec sa carte de crédit. On comprend que cette solution n'est pas adaptée au paiement à distance.
Le système MOTO (Mail Order Téléphone Order) est comme on l'a vu le mode traditionnel permettant de réaliser des paiements à distance. La fraude avec le système MOTO à travers le réseau Internet et les réseaux des téléphones mobiles (principalement pour le marché du prépayé) a une croissance qui s'accélère depuis les dernières années. La carte de paiement est considérée comme n'étant pas présente pour des tels achats et ainsi, la banque ne peut garantir le paiement aux commerçants.
Seule la solution standard qui fournit une garantie de paiement pour le commerçant est la solution SET pour le commerce électronique. Mais, comme cela a été souligné, cette solution nécessite une implémentation logistique lourde pour le chargement des certificats pour les payeurs et le déploiement de cette solution est encore très lent . Tous les schémas de paiement en particulier à partir d'un téléphone mobile, présentent à ce jour chacun des inconvénients techniques.
La solution proposée permet de réaliser le paiement de biens et de services. Elle est indépendante du canal utilisé pour « passer la commande » à savoir microordinateur (PC) sur Internet ou « face à face » dans une boutique, téléphone mobile, téléphone fixe, assistant personnel ou courrier.
La solution peut également être utilisée dans des pays pour lesquels les cartes de crédit bancaires ne sont pas encore très développées.
La présente invention a pour but de remédier aux inconvénients précités. La présente invention concerne un « circuit global » de paiement à partir d'un dispositif électronique de paiement permettant une garantie de paiement pour le commerçant .
En effet, l'invention vise à remédier aux problèmes énoncés en apportant une solution basée sur des technologies existantes, mais permettant de limiter de façon drastique la fraude dans le cas de vente par correspondance . La solution consiste plus particulièrement à prévoir deux clés pour 1 ' authentification du payeur, une clé dédiée à l'opérateur téléphonique et une clé dédiée à l'organisme financier. Il peut s'agir d'une banque ou tout autre organisme par exemple une assurance. On parlera cependant dans la suite de banque pour simplifier et de clé bancaire.
Les deux clés permettent d'élaborer deux certificats certl, cert2. On entend par certificats de la transaction un ensemble de données caractérisant de façon non équivoque la transaction, les parties en présence (en pratique, le client et le commerçant) et attestant que le client a été authentifié. En pratique, il s'agit de données représentatives de la transaction et du commerçant (montant, horodatage, identifiant du commerçant, monnaie utilisée ...) et d'une signature électronique calculée sur une empreinte (c'est à dire d'un condensé) de ces données et permettant d'assurer l'intégrité de la "transaction et d'authentifier le client .
Le certificat certl est donc obtenu avec la clé Kl et le certificat cert2 est obtenu avec la clé K2. On parlera dans la suite de façon indifférente de certificats ou de signatures électroniques.
L'opérateur téléphonique ne pourra vérifier le certificat qu'avec la clé opérateur.
Seule la banque du titulaire de la carte SIM (banque du client) pourra vérifier le certificat réalisé avec la clé qui lui est dédiée. On a ainsi deux certificats élaborés à partir de clés distinctes dont l'une est une clé bancaire. Le commerçant ou l'opérateur téléphonique ne peuvent reproduire le certificat dédié à la banque puisqu'ils ne disposent pas de la clé bancaire. Le paiement est considéré comme garanti pour le commerçant par l'organisme bancaire.
Ceci nécessite que la clé de signature soit chargée de façon sécurisée par exemple dans une carte SIM, sans intervention de l'opérateur téléphonique.
La présente invention procure les avantages suivants :
-Il n'y a pas besoin de modifier le réseau d'autorisation bancaire. La signature réalisée avec la. clé bancaire est vérifiée par l'organisme bancaire uniquement en cas de contestation du payeur, dans l'exemple décrit, il s'agira du titulaire de la carte SIM.
-Il n'y a pas besoin de modifier la technique usuelle de personnalisation des cartes SIM. Il est seulement nécessaire de rajouter une procédure de chargement des données secrètes liées à la signature numérique (clé bancaire) .
-Une garantie de paiement est assurée au commerçant .
-Il n'est pas nécessaire de changer le téléphone mobile pour la mise en œuvre de ce mécanisme de paiement garanti.
-En outre cette solution peut s'appliquer à d'autres réseaux permettant le commerce électronique : achat sur Internet, achat par commande vocale et paiement à partir d'un réseau de téléphonie mobile (GSM ou autre) .
L'invention a donc pour objet un procédé de paiement électronique d'un commerçant à l'aide d'un moyen de communication utilisant un réseau d'un opérateur et un organisme financier principalement caractérisé en ce qu'il consiste lors d'une transaction à élaborer deux certificats, l'un à partir d'une clé opérateur, l'autre à partir d'une clé bancaire, à transmettre à l'opérateur le premier certificat et à placer sous contrôle de l'organisme financier l'autre certificat de manière sécurisée. Selon une variante, certificats sont élaborés par une carte à puce et en ce que le deuxième certificat est stocké sur cette carte.
Selon une autre variante, le deuxième certificat est transmis à l'opérateur qui le conserve sur une base de données sous le contrôle et/ou avec approbation de l'organisme financier.
Selon une autre variante, le deuxième certificat est envoyé à la banque soit par la carte à puce soit par l'opérateur. Selon un mode de mise en œuvre, le moyen de paiement est un téléphone mobile.
Avantageusement, le téléphone mobile comporte une carte à puce d'identification d'abonné (par exemple SIM sur réseau GSM, UIM sur réseau CDMA, USIM sur réseau 3G) , le réseau de l'opérateur de télécommunication est équipé d'un serveur de gestion et de facturation, le procédé consistant : pour le téléphone mobile : à envoyer à l'opérateur de télécommunication les deux certificats, - pour le serveur de gestion et de facturation : à authentifier le titulaire de la carte à partir du premier certificat et envoyer une autorisation de paiement à l'organisme financier.
Un autre objet de la présente invention concerne un dispositif de paiement électronique comportant des moyens permettant d'accéder à un réseau, principalement caractérisé en ce qu'il comporte au moins deux clés, une clé opérateur Kl, une clé bancaire K2 , pour élaborer deux certificats représentatifs d'une transaction.
Selon l'invention, le dispositif de paiement électronique est constitué d'un micro-ordinateur ou d'un téléphone mobile ou d'un assistant personnel.
Avantageusement, le dispositif constitue un support à puce électronique sécurisé.
Selon un mode de réalisation, le dispositif est apte à élaborer les certificats. L'invention a également pour objet, un serveur de gestion et de facturation relié à un réseau d'un opérateur de télécommunication pour la facturation de biens ou de services fournis par un commerçant à un client effectuant des transactions électroniques sur le réseau au moyen d'un moyen de paiement électronique, principalement caractérisé en ce qu'il comporte des moyens de traitement de certificats opérateur relatifs des transactions, et en ce qu'il comporte des moyens de mise sous contrôle de certificats bancaires relatifs auxdites transactions.
D'autres particularités et avantages de l'invention apparaîtront clairement dans la description suivante faite à titre d'exemple non limitatif en regard des figures annexées qui représentent :
La figure 1, illustre les échanges entre les équipements du client, de sa banque et l'opérateur téléphonique pour la phase d'enregistrement d'un client auprès de sa banque et de son opérateur téléphonique pour permettre le commerce électronique ;
La figure 2, illustre les échanges entre les équipements de la banque, du centre de personnalisation des cartes à puce et de l'opérateur mobile, pour la phase de personnalisation des cartes ; La figure 3, illustre les échanges entre les équipements du client, ceux de l'opérateur téléphonique auprès duquel il est enregistré et ceux de sa banque pendant une transaction; La figure 4, illustre les échanges entre l'ensemble des intervenants dans le cas d'une contestation du paiement par le client.
L'exemple décrit dans la suite concerne le commerce électronique avec un téléphone mobile. La solution proposée utilise une application de paiement Sim
ToolKit (STK) , c'est à dire un programme d'application
STK chargé dans une carte SIM.
Le programme d'application de paiement SIM Tool Kit est chargé dans la carte SIM d'un client au moment de l'étape de personnalisation de la carte. Ce programme peut également être téléchargé en utilisant le réseau hertzien, ceci dépendant des caractéristiques techniques de la carte SIM utilisée.
Une fois cette application activée, la banque du titulaire de la carte peut formater, signer et envoyer des requêtes de paiement au moyen de messages courts
SMS à destination du téléphone mobile équipé de cette carte .
Les transactions effectuées par le titulaire de la carte (dénommé également client) sont signées après présentation du PIN de paiement par le client. L'algorithme utilisé pour l'élaboration des certificats et en l'occurrence la génération des signatures, est stocké dans une mémoire de programme de la carte. Il peut s'agir d'un algorithme mettant en œuvre la cryptographie symétrique avec l'algorithme DES ou 3DES ou la cryptographie asymétrique avec l'algorithme RSA.
On rappelle que pendant une transaction chez un commerçant, l'organe lecteur point de vente met en œuvre deux fonctions de sécurité principales : 1' authentification de la carte de paiement mettant en jeu la carte et le lecteur et 1 ' authentification du titulaire de cette carte. Dans le monde des téléphones mobiles, 1' authentification de la carte bancaire repose sur un enregistrement préliminaire du client, ceci est réalisé une fois pour toutes. Les échanges qui sont opérés durant cette étape d'enregistrement entre les différents équipements des intervenants sont rappelés dans la suite est illustrés par la figure 1.
En outre, 1 ' authentification du titulaire de la carte est réalisée à chaque transaction à travers ou du moins au moyen du code d'identification dédié au titulaire de la carte, ce code devant être entré par le titulaire de la carte. Ce code d'identification, encore connu sous l'appellation PINcode (Personal Identifier Number) sera appelé code bancaire dans le reste de la description car il est fourni par la banque à son client. On peut noter dès à présent que l'on parlera de clé bancaire à ne pas confondre avec le PIN code qui sera en principe différent de la clé bancaire et qui protège l'accès à la clé bancaire.
Le mécanisme fonctionnel d'enregistrement d'un client est illustré par la figure 1.
Comme on vient de le voir, le programme STK est de préférence chargé dans la carte SIM au moment de la personnalisation et ceci par le fabricant de la carte. Ce programme pourrait être téléchargé (Over The Air) sur un terminal dans un point de vente. Cependant, le client ne peut pas utiliser cette application de paiement tant qu'il n'est pas enregistré auprès des organes intervenant dans le circuit de paiement. On rappelle que les objectifs principaux de l'enregistrement sont les suivants : assurer que les données bancaires fournies par le client sont valides (par exemple, le RIB du compte à prélever ou le numéro de la carte bancaire à utiliser et sa date d'expiration). Ces informations sont envoyées soit de façon électronique soit par voie postale. Le client envoie à cette fin, un formulaire (électronique sur une liaison sécurisée ou papier) à sa banque. Cet envoi est symbolisé par l'échange entre l'équipement A et B sur la figure 1. le stockage des données de la carte bancaire et des numéros de téléphone dans la base de données 10 de la banque du client et sur le système de gestion et de facturation 20 de l'équipement C de l'opérateur de télécommunications, permettre au client de connaître le code d'identification bancaire PIN code.
Le client a rempli un formulaire papier ou électronique et l'a envoyé à sa banque. La carte client pourra alors être authentifiée.
La banque émettrice a la responsabilité d'authentifier le titulaire de la carte. Ensuite, à travers le mécanisme d' authentification qui doit être accepté par les deux parties (à savoir la banque et l'opérateur de télécommunications), la banque doit informer l'opérateur de télécommunications concerné. L'opérateur de télécommunications est alors capable d'activer l'application de paiement STK à travers une liaison hertzienne. Ceci peut être réalisé localement (par exemple, par le téléphone) à travers un menu STK dédié et un code d'activation qui peut être le code d'identification bancaire (PIN code). Le titulaire de la carte connaît à ce stade son code et peut alors le rentrer à partir du clavier de son téléphone mobile. Comme cela a été précisé, une fois enregistré, le client a besoin de connaître le code d'identification bancaire c'est à dire son PIN code, pour pourvoir l'utiliser par la suite pour effectuer du commerce électronique. En outre ce code d'identification bancaire est une sécurité supplémentaire dans le procédé proposé puisqu' il est nécessaire pour déclencher les signatures d'une transaction. Il protège ainsi l'accès aux clefs de signature Kl, K2 stockées dans la carte SIM.
Or pour assurer la garantie de paiement, les banques doivent être sûres que ce code PIN (code d'identification bancaire) n'est pas connu par l'opérateur de télécommunication. La gestion de ce code et des clés Kl et K2 de signature est détaillée dans ce qui suit. La figure 2 illustre une solution possible des étapes conduisant à la génération du code PIN lors de la personnalisation de la carte SIM et la génération des clés Kl et K2 de signature.
A cette étape (génération des clés) , le client final n'est pas connu. Le code PIN est généralement diversifié à partir d'un code d'identification maître généré par la banque 100. Le centre de personnalisation 400 génère alors le code PIN à partir du code maître et d'un numéro personnel de la carte, à savoir le code ICCid (numéro d'identification du circuit intégré de la carte) ou du code IMSI (International Mobile Subscriber Identifier) de la carte SIM ou tout autre identifiant possible lié à la carte SIM. Ces codes sont les codes d'identification d'un abonné au réseau de téléphonie mobile international.
Lorsque cela est nécessaire grâce à un logiciel dédié et au code ICCid ou IMSI de la carte SIM, la banque emettrice est capable de calculer le code d'identification bancaire (PIN code) et de l'envoyer par courrier électronique au titulaire de la carte.
Une meilleure solution dérivée de cette dernière peut être basée sur une diversification à partir du code d'identification maître et du numéro de téléphone de 1 ' abonné .
De façon optionnelle, le code bancaire peut être modifié par le client final (comme c'est déjà le cas pour les téléphones mobiles. Mais dans ce cas, le code non définitif est de toute façon, géré par la banque emettrice et non par l'opérateur de télécommunication.
On va maintenant détailler la gestion des transactions .
Un schéma fonctionnel du mécanisme d'échanges effectués en les équipements A, B, C des trois intervenants, à savoir titulaire de la carte, l'opérateur téléphonique et les organismes bancaires, est représenté sur la figure 3.
Le système de gestion et de facturation 20 envoi une demande paiement (1) au téléphone mobile 2 à travers un serveur 21 apte à convertir cette information en messages courts SMS (2) ou tout autre protocole de transport supporté par le mobile à destination du téléphone mobile. Le titulaire du téléphone mobile et plutôt, le titulaire de la carte accepte la transaction et à cette fin entre son PIN code. Ceci permet de déclencher le processus de calcul des deux signatures portant sur les données caractéristiques de la transaction acceptée. Un message SMS est émis par le téléphone mobile à destination du serveur 21. Ce message contient les certificats certl et cert2 c'est à dire les données caractéristiques de la transaction et les deux signatures calculées par la carte SIM. Une signature a été calculée avec la clé Kl et l'autre avec la clé K2.
Comme on l'a vu, chaque client a deux clefs de signature personnelles utilisée pour la génération de la signature portant sur des caractéristiques de la transaction. Les données caractéristiques d'une transaction sont par exemple le montant de la transaction, la date, l'heure, l'identification du commerçant et le numéro de téléphone.
Pour empêcher l'opérateur de télécommunications de générer des transactions truquées, la clef secrète bancaire ne doit être connue de l'opérateur de télécommunications. Comme cela a été dit, l'utilisation de cette clef K2 est protégée par le PINcode à l'intérieur de la carte SIM. La gestion des requêtes de paiement peut être réalisée par le système MOTO classique avec validation hors ligne « off line ».
En effet, entre l'opérateur téléphonique et la banque réceptrice la transaction peut être réalisée comme une transaction MOTO classique.
L'opérateur de téléphonie mobile doit en plus stocker les données de la transaction numérique incluant la signature numérique certl, dans une base de données dédiée. II est prévu qu'en cas de contestation, l'opérateur de télécommunication soit capable de renvoyer la signature numérique cert2 de la transaction numérique à la banque du client. L'avantage immédiat de la solution proposée est que les infrastructures existantes pour les requêtes d'autorisation de paiement n'ont pas besoin d'être modifiées .
Mais en cas de contestation du titulaire d'une carte, cette contestation doit être gérée de façon différente .
La signature numérique cert2 est la preuve du paiement par le titulaire de la carte.

Claims

REVENDICATIONS
1. Procédé de paiement électronique d'un commerçant à l'aide d'un moyen de communication utilisant un réseau d'un opérateur et un organisme financier (banque, assurance...), caractérisé en ce qu'il consiste lors d'une transaction à élaborer deux certificats, l'un à partir d'une clé opérateur, l'autre à partir d'une clé bancaire, à transmettre à l'opérateur le premier certificat et à placer sous contrôle de l'organisme financier l'autre certificat de manière sécurisée.
2. Procédé de paiement électronique selon la revendication 1, caractérisé en ce que les certificats sont élaborés par une carte à puce et en ce que le deuxième certificat est stocké sur cette carte.
3. Procédé de paiement électronique selon la revendication 1, caractérisé en ce que le deuxième certificat est transmis à l'opérateur qui le conserve sur une base de données sous contrôle et/ou avec approbation de l'organisme financier.
4. Procédé de paiement électronique selon les revendications 2 et 3, caractérisé en ce que le deuxième certificat est envoyé à l' organisme financier soit par la carte à puce soit par l'opérateur.
5. Procédé de paiement électronique selon l'une quelconque des revendications précédentes, caractérisé en ce le moyen de paiement est un téléphone mobile.
6. Procédé de paiement électronique selon la revendication 5, caractérisé en ce que le téléphone mobile comporte une carte à puce d'identification d'abonné (par exemple SIM sur réseau GSM, UIM sur réseau CDMA, USIM sur réseau 3G) , en ce que le réseau de l'opérateur de télécommunication est équipé d'un serveur de facturation, et en ce qu'il consiste: pour le téléphone mobile : à envoyer à l'opérateur de télécommunication les deux certificats, - pour le serveur de facturation : à authentifier le titulaire de la carte à partir du premier certificat et envoyer une autorisation de paiement à l' organisme financier.
7. Dispositif de paiement électronique comportant des moyens permettant d'accéder à un réseau, caractérisé en ce qu'il comporte au moins deux clés, une clé opérateur Kl, une clé bancaire K2 , pour élaborer deux certificats représentatifs d'une transaction.
8. Dispositif de paiement électronique selon la revendication 7, caractérisé en ce qu'il est constitué d'un micro-ordinateur ou d'un téléphone mobile ou d'un assistant personnel.
9. Dispositif de paiement électronique selon la revendication 7, caractérisé en ce qu'il constitue un support à puce électronique sécurisé.
10. Dispositif de paiement électronique selon les revendications 7 à 9, caractérisé en ce qu'il est apte à élaborer les certificats.
11. Serveur de facturation relié à un réseau d'un opérateur de télécommunication pour la facturation de biens ou de services fournis par un commerçant à un client effectuant des transactions électroniques sur le réseau au moyen d'un moyen de paiement électronique, caractérisé en ce qu' il comporte des moyens de traitement de certificats opérateur relatifs des transactions, et en ce qu'il comporte des moyens de mise sous contrôle de certificats bancaires relatifs audites transactions.
FIGUό 1
EP02764977A 2001-07-12 2002-07-11 Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre Ceased EP1412925A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0109312 2001-07-12
FR0109312A FR2827448B1 (fr) 2001-07-12 2001-07-12 Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre
PCT/FR2002/002452 WO2003007251A1 (fr) 2001-07-12 2002-07-11 Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre

Publications (1)

Publication Number Publication Date
EP1412925A1 true EP1412925A1 (fr) 2004-04-28

Family

ID=8865442

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02764977A Ceased EP1412925A1 (fr) 2001-07-12 2002-07-11 Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre

Country Status (5)

Country Link
US (1) US8136722B2 (fr)
EP (1) EP1412925A1 (fr)
CN (2) CN1554078A (fr)
FR (1) FR2827448B1 (fr)
WO (1) WO2003007251A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200840305A (en) * 2007-03-20 2008-10-01 Game Flier Internat Corp Account security system with communication mechanism
US20120171996A1 (en) * 2010-12-30 2012-07-05 Sierra Wireless, Inc. Method for enabling operation of a wireless modem
EP3013014A1 (fr) * 2014-10-21 2016-04-27 Gemalto Sa Procédé pour l'accès à un service, premier dispositif correspondant, deuxième dispositif et système
CN104850811B (zh) * 2015-05-22 2017-12-05 东信和平科技股份有限公司 一种基于stk菜单对软件进行授权的方法及系统
US10749684B2 (en) * 2016-09-30 2020-08-18 Entrust, Inc. Methods and apparatus for providing blockchain participant identity binding

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4427039C2 (de) * 1994-07-29 2003-06-12 Giesecke & Devrient Gmbh Verfahren zur Bestimmung des aktuellen Geldbetrages in einem Datenträger und System zur Durchführung des Verfahrens
FR2751104B1 (fr) * 1996-07-11 1998-12-31 Stoffel Laurent Procede de controle de transactions securisees independantes utilisant un dispositif physique unique
US6285991B1 (en) * 1996-12-13 2001-09-04 Visa International Service Association Secure interactive electronic account statement delivery system
SE508844C2 (sv) * 1997-02-19 1998-11-09 Postgirot Bank Ab Förfarande för behörighetskontroll med SIM-kort
SE512748C2 (sv) * 1997-05-15 2000-05-08 Access Security Sweden Ab Förfarande, aktivt kort, system samt användning av aktivt kort för att genomföra en elektronisk transaktion
CA2306139C (fr) * 1997-10-14 2007-04-17 Visa International Service Association Personnalisation de cartes a puce
US6145079A (en) * 1998-03-06 2000-11-07 Deloitte & Touche Usa Llp Secure electronic transactions using a trusted intermediary to perform electronic services
US6092202A (en) * 1998-05-22 2000-07-18 N*Able Technologies, Inc. Method and system for secure transactions in a computer system
FR2779895B1 (fr) * 1998-06-15 2000-08-11 Sfr Sa Procede et systeme pour payer a distance au moyen d'un radiotelephone mobile l'acquisition d'un bien et/ou d'un service
FR2779896B1 (fr) * 1998-06-15 2000-10-13 Sfr Sa PROCEDE POUR PAYER A DISTANCE, AU MOYEN D'UN RADIOTELEPHONIQUE MOBILE, l'ACQUISITION D'UN BIEN ET/OU D'UN SERVICE ET SYSTEME ET RADIOTELEPHONE MOBILE CORRESPONDANTS
AU1069400A (en) * 1998-11-22 2000-06-13 Easy Charge Cellular (Pty) Limited Method of, and apparatus for, conducting electronic transactions
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
US6463534B1 (en) * 1999-03-26 2002-10-08 Motorola, Inc. Secure wireless electronic-commerce system with wireless network domain
US6694025B1 (en) * 1999-06-02 2004-02-17 Koninklijke Philips Electronics N.V. Method and apparatus for secure distribution of public/private key pairs
US6377810B1 (en) * 1999-06-11 2002-04-23 Motorola, Inc. Method of operation of mobile wireless communication system with location information
JP2001344537A (ja) * 2000-05-31 2001-12-14 Ntt Docomo Inc 電子バリューシステム、通信端末及びサーバ
US20020026578A1 (en) * 2000-08-22 2002-02-28 International Business Machines Corporation Secure usage of digital certificates and related keys on a security token
US20020044662A1 (en) * 2000-08-22 2002-04-18 Jonathan Sowler Service message management system and method
US6836765B1 (en) * 2000-08-30 2004-12-28 Lester Sussman System and method for secure and address verifiable electronic commerce transactions
US7107248B1 (en) * 2000-09-11 2006-09-12 Nokia Corporation System and method of bootstrapping a temporary public-key infrastructure from a cellular telecommunication authentication and billing infrastructure
US6990471B1 (en) * 2001-08-02 2006-01-24 Oracle International Corp. Method and apparatus for secure electronic commerce
GB2385955A (en) * 2002-02-28 2003-09-03 Ibm Key certification using certificate chains

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
CN101655951A (zh) 2010-02-24
CN1554078A (zh) 2004-12-08
US20100235281A1 (en) 2010-09-16
US8136722B2 (en) 2012-03-20
FR2827448A1 (fr) 2003-01-17
FR2827448B1 (fr) 2003-12-19
WO2003007251A1 (fr) 2003-01-23

Similar Documents

Publication Publication Date Title
US8417633B1 (en) Enabling improved protection of consumer information in electronic transactions
US8977567B2 (en) Recordation of electronic payment transaction information
EP1899950B1 (fr) Procede de securisation d'une transaction avec une carte de paiement et serveur d'activation pour la mise en oeuvre de ce procede
US20090307778A1 (en) Mobile User Identify And Risk/Fraud Model Service
US9552576B2 (en) Networked authentication systems and methods
US20070055635A1 (en) Method and apparatus for performing mobile transactions
US20080162318A1 (en) Method of securely transferring funds via a mobile internet enabled device
JP2005004764A (ja) 移動ユーザ端末を有する顧客による口座からの支払い方法、および顧客認証網
CA2584769A1 (fr) Procedes et systemes permettant d'effectuer des operations de credit au moyen d'un dispositif sans fil
FR2731536A1 (fr) Procede d'inscription securisee d'informations dans un support portable
FR2795262A1 (fr) Certificat du fabricant de module d'identite de protocole d'application sans fil
EP2579199A1 (fr) Procédé de paiement d'un produit ou d'un service sur un site marchand par l'intermédiaire d'une connexion Internet et terminal correspondant
EP2053554A1 (fr) Dispositif electronique portable pour l'echange de valeurs et procédé de mise en oeuvre d'un tel dispositif
US8136722B2 (en) Method guaranteeing payment for electronic commerce in particularly by mobile telephone and a system implementing it
US20040039709A1 (en) Method of payment
EP1323140B1 (fr) Procede pour fournir des donnees d'identification d'une carte de paiement a un usager
US20100332349A1 (en) Systems and methods for fund transfers using prepaid calling cards and telephones
FR2750273A1 (fr) Procede de rechargement de cartes prepayees virtuelles
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
WO2003010720A2 (fr) Procede et systeme permettant de valider, en mettant en oeuvre un objet portable d'un utilisateur, une requete aupres d'une entite
EP1978479A1 (fr) Cryptogramme dynamique
EP2724305B1 (fr) Procede de transaction dematerialisee
WO2001015095A1 (fr) Methode et systeme d'achat et de paiement
FR2819662A1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
KR20070011951A (ko) 상품권 운용방법 및 시스템과 이를 위한 상품권운용장치와, 무선 단말 장치와, 기록매체 및 정보 저장매체

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040212

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17Q First examination report despatched

Effective date: 20061027

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

Owner name: GEMALTO SA

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20131209