WO2002067534A1 - Systeme de paiement electronique a distance - Google Patents

Systeme de paiement electronique a distance Download PDF

Info

Publication number
WO2002067534A1
WO2002067534A1 PCT/FR2002/000626 FR0200626W WO02067534A1 WO 2002067534 A1 WO2002067534 A1 WO 2002067534A1 FR 0200626 W FR0200626 W FR 0200626W WO 02067534 A1 WO02067534 A1 WO 02067534A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
server
key
transaction
request
Prior art date
Application number
PCT/FR2002/000626
Other languages
English (en)
Inventor
Christophe Dolique
Eric Barbier
Carles Guillot
Original Assignee
Mobileway
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 Mobileway filed Critical Mobileway
Priority to EP02714264A priority Critical patent/EP1362466A1/fr
Priority to US10/468,476 priority patent/US20040139013A1/en
Publication of WO2002067534A1 publication Critical patent/WO2002067534A1/fr
Priority to US12/940,281 priority patent/US20110047082A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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/102—Bill distribution or payments
    • 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/401—Transaction verification
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal

Definitions

  • the present invention relates to a remote electronic payment system.
  • the invention relates in particular to an authentication device with an authentication server in a remote payment system, making it possible to trigger transactions from a mobile telephone.
  • references of a means of payment such as a credit card.
  • These references are, in known manner, encrypted and transmitted to the remote supplier.
  • Such electronic devices must include a user interface allowing easy entry of these references. This is in particular not the case for mobile telephones, whose keyboard and screen are generally of reduced size. . Mobile phones are also known which include an integrated credit card reader. This solution effectively eliminates the entry of the aforementioned references. It also allows authentication prior to a payment transaction. However, this solution requires complex and expensive components. 'It also appears that most consumers are reluctant to provide the references of a means of payment to their supplier, which is moreover through a communication network.
  • remote electronic payment systems for which the references of a means of payment are stored on a server called electronic wallet ("server based electronic wallet").
  • server based electronic wallet the user authenticates with the server remote electronic wallet, from a client terminal, for example a personal computer (“PC”) comprising authentication means, typically integrated into an Internet browser.
  • PC personal computer
  • the present invention aims to solve this problem, in particular by proposing an authentication device adapted to be incorporated into a portable telephone.
  • the present invention provides an authentication device with an authentication server in a remote payment system, the authentication being prior to a transaction by a user, the device being characterized in that it includes:
  • the subject of the invention is an authentication method with an authentication server in a remote payment system, the authentication being prior to a transaction by a user, the method being characterized in that it comprises the following steps: reception of a first authentication request, coming from the authentication server;
  • the invention first of all authenticates the user before the validation of the transaction.
  • the authentication return message is sent after a verification of the validity of the authentication request. This measure ensures that the authentication return message is not sent to a malicious recipient.
  • the authentication request comprises a description of the transaction, an identifier of the transaction and a first authentication code of the authentication server, the verification means of the authentication device being adapted to verify the validity the authentication request from the first authentication code and a first authentication key.
  • This authentication key mechanism makes it possible to verify, with excellent reliability, the validity of the authentication request.
  • the authentication device further comprises means for generating a second authentication code, the means for sending the authentication return message being adapted to insert this second authentication code into the authentication return message.
  • This mechanism makes it possible, at the authentication server level, to ensure that the authentication return message actually comes from the authentication device.
  • the means for sending the authentication return message are adapted to insert a response depending on the validation of the transaction in the authentication return message.
  • the authentication return message may for example contain data representative of the acceptance of the transaction by the user, which may be transmitted by the authentication server to a financial institution.
  • the means of checking the identity of the user use a personal identification number.
  • This personal identification number which the user will have received for example by mail, will prevent the use of the authentication device by a third party.
  • the means of checking the identity of the user can for example be adapted to block the authentication device after three entries of an incorrect personal identification number.
  • the authentication device also comprises means for decrypting the first authentication request from a transport key, and / or means for encrypting the authentication return message from a transport key.
  • the transaction comprising a payment transaction
  • the device comprises means for selecting a payment option for the transaction and the means for sending the authentication return message are adapted to insert this option in the message authentication return.
  • the authentication device further comprises a transaction counter used by the generation means and the second authentication code and inserted by the means for sending the authentication return message in the authentication return message.
  • the authentication device comprises means for receiving, from an activation server, a key delivery message, the key delivery message comprising the first authentication key.
  • the authentication key is thus provided by a server, preferably in a manner transparent to the user, which makes it possible to reinforce the security of the system.
  • the key delivery message further includes a personal unlocking identification number.
  • this unlocking personal identification number is used to unlock the authentication device when it has been blocked, for example after three entries of an incorrect personal identification number.
  • the authentication device further comprises means for verifying the validity of the key delivery message, from a third authentication code contained in the key delivery message.
  • the invention also relates to an activation server, in a remote payment system, characterized in that it comprises: means for receiving an activation request from a server of user accounts , the activation request comprising an identifier of an authentication device as described above;
  • the identifier is a telephone number.
  • the activation server also comprises means for saving the first authentication key in a secure database.
  • the activation server thus keeps a copy of the first authentication key.
  • This key can be transmitted later to an authentication server which can implement a symmetric key authentication mechanism (in English "Symmetrical Key Infrastructure") with the authentication device.
  • the activation server comprises means for generating a second authentication key, from the first authentication key, and comprises means for saving this second authentication key in the database secure data.
  • the activation server comprises means for calculating a third authentication code, this third authentication code being inserted in the key delivery message.
  • This mechanism allows the authentication device to ensure the validity of the key delivery message.
  • the activation scent inserts a personal unlocking identification number in the key delivery message.
  • the activation server also comprises means for encrypting the key delivery message, from a transport key.
  • the activation server also comprises means for obtaining the transport key and a personal identification number for unlocking from a pre-activation database.
  • This transport key can also be used for the calculation of the third authentication code.
  • This pre-activation database is typically a generic database, updated for each creation of an authentication device. This allows in particular the operator of the payment system to keep control over the authentication devices.
  • the activation server comprises means for sending an authentication record, intended for an authentication server, the authentication record comprising the transport key and the number d personal identification.
  • the authentication server will thus have the transport key enabling it to exchange, in a secure manner, the messages relating to the transactions with the authentication device.
  • the invention relates to a user account server, in a remote payment system, characterized in that it comprises:
  • a user account is thus created for any user in possession of an authentication device as described above and who actually wishes to use (for example via a subscription) such a remote electronic payment system.
  • the user account server sends an activation request to the activation server, which generates and provides the authentication key to the user.
  • a user account comprises an identifier of the authentication device (for example a telephone number) and at least one option for payment of the transaction.
  • the invention also relates to an authentication server, in a remote payment system, characterized in that it comprises:
  • Such an authentication server thus receives, upon activation of the service, an authentication record containing the transport key and the personal identification number for unlocking associated with an authentication device. For each transaction, it then receives an authentication request from a user account server. He can then send a first authentication request to an authentication device incorporated in a client terminal, and receive in return a validation of the transaction from the user as well as a means of payment. This latter information is thus transmitted in a transaction confirmation message to the user account server which ends the transaction itself.
  • the invention relates to a remote payment system, characterized in that it comprises an authentication device, an activation server, a server of user accounts and an authentication server as described above.
  • the remote payment system uses an infrastructure of a mobile telephone network, for example that of a GSM network.
  • An authentication device can thus be incorporated into a mobile client terminal.
  • the messages and requests described above conform to the SMS format of the GSM network.
  • the invention also relates to a smart card and a SIM card comprising an authentication device as defined above.
  • the invention also relates to a telephone comprising means adapted to receive a SIM card as defined above.
  • the telephone can thus be used as an authentication client terminal with an electronic wallet server.
  • the telephone according to the further comprises means for entering the personal identification number.
  • the user can enter his personal identification number, this number having for example been received by mail in confirmation of the subscription.
  • FIG. 1 schematically represents an authentication request according to the invention, in a particular embodiment
  • FIG. 2 represents an authentication return message according to the invention, in a particular embodiment
  • FIG. 3 represents an authentication device according to the invention, in a particular embodiment
  • FIG. 4 represents a key delivery message according to the invention, in a particular embodiment
  • FIG. 5 represents an activation server according to the invention, in a particular embodiment
  • FIG. 6 represents an activation request according to the invention, in a particular embodiment
  • FIG. 7 represents an authentication record according to the invention, in a particular embodiment
  • FIG. 8 represents a server of user accounts according to the invention, in a particular embodiment
  • FIG. 9 represents an authentication server according to the invention, in a particular embodiment
  • FIG. 10 represents a remote electronic payment system according to the invention, in a particular embodiment.
  • FIG. 11 represents a flow diagram of an authentication method according to the invention, in a particular embodiment.
  • FIG. 1 represents an M100 authentication request according to the invention.
  • Such an authentication request M100 comprises a first field M110 comprising the details of a transaction. These details are by example the references of a supplier, the amount of the transaction and different payment options 831, 832 illustrated in FIG. 8.
  • the authentication request M 100 has a second field
  • This first authentication code M 130 makes it possible to ensure that the authentication request M 100 has been issued by a valid authentication server.
  • FIG. 2 represents an authentication return message M200 according to the invention.
  • Such an authentication return message M200 includes a first user response field M210, representative of the acceptance or rejection of the transaction described in the field M110 of an authentication request M 100.
  • the authentication return message M200 also includes a field M220 containing an option for payment of the transaction. This field is of course useful only in the case where the user response field M210 is representative of the acceptance of the transaction.
  • the authentication return message also includes, in a field M230, the value of a transaction counter 348 as described later with reference to FIG. 3.
  • the authentication return message M200 finally comprises a second authentication code in a M240 field, this code being similar to the first authentication code M130 of the authentication request M100.
  • FIG. 3 represents an authentication device 300 according to the invention.
  • the authentication device 300 includes means 310 for receiving an authentication request M100 as described with reference to FIG. 1. These reception means 310 are adapted to store the authentication request M100 received in a random access memory 320 (RAM).
  • RAM random access memory
  • the authentication device 300 includes means 330 for verifying the validity of the authentication request M 100. These means use in particular the first authentication code M130 contained in the authentication request M100 and a first key authentication 342 stored in a register of a non-volatile memory (EEPROM) 340. This first authentication key 342 is for example received from an activation server 500 as described later with reference to FIG. 5.
  • the method implemented by the verification means 330 are known to those skilled in the art. trade and will not be described here. These verification means 330 are of course adapted to verify any other request received by the authentication device 300 and in particular an activation request M600 as described later with reference to FIG. 6.
  • the authentication device 300 includes means 350 for validating a transaction. These means are for example adapted to display the details of the transaction contained in the field M110 of the request M100 and to collect a user response 322 representative of the acceptance or rejection of the transaction by the user. This user response 322 is stored in the RAM 320 by the means 350 for validating a transaction.
  • the authentication device 300 also includes means 360 for selecting a payment option 324 from among the payment options 831, 832. These means are in particular suitable for providing a list of the payment options 831, 832 present in the field. M110 of the M100 authentication request. These means 360 for selecting a payment option are also suitable for storing, in a register of the RAM 320, the payment option 324 retained by the user.
  • the authentication device 300 also includes means 370 for checking the identity of the user. These means are for example suitable for verifying, in a known manner, a personal identification number (PIN) 344 stored in a register of the non-volatile memory 340. These means 370 for checking the identity of the user are also suitable to block the authentication device 300 when the user enters, on three occasions, a personal identification number different from the personal identification number 344. The device 300 can then be unlocked by entering an identification number unlocking personnel 346, stored in non-volatile memory 340.
  • PIN personal identification number
  • This personal unlocking identification number 346 and the first authentication key 342 are respectively received by the device.
  • authentication 300 in fields M410 and M420 of a key delivery message M400 shown in FIG. 4.
  • the key delivery message M400 finally includes a third authentication code M430 similar to the first authentication code M 130 of the M100 authentication request.
  • the verification means 330 are also adapted to verify the validity of the key delivery message M400, from the third authentication code.
  • the authentication device 300 also includes means 380 for sending an authentication return message M200, as described above with reference to FIG. 2. These means 380 for sending an authentication return message are adapted to increment, before each sending of an authentication return message M200, a transaction counter 348, contained in a register of the non-volatile memory 340.
  • They are also suitable for generating a second authentication code 326 and for storing it in a register of the RAM 320.
  • the means 380 of sending an authentication M200 return messages are also suitable to build such a message from the user response 322, the payment option 324, transaction counter 348 and the second code 326 authentication, these values respectively filling the fields M210, M220, M230 and M240.
  • the means 380 for sending an authentication return message are also suitable for sending a message M200 to an authentication server 900, as described later with reference to FIG. 9.
  • the authentication device 300 also comprises encryption and decryption means 390, adapted respectively to encrypt an authentication return message M200 and to decrypt an authentication request M 100, from a transport key 349 stored in a memory register not volatile 340. This transport key 349 is supplied at the time of personalization of the authentication device 300.
  • FIG. 5 represents an activation server 500 according to the invention.
  • An activation server 500 includes reception means 510 of an M600 activation request shown in FIG. 6.
  • Such an M600 activation request comprises a field M610 containing an identifier of an authentication device 300.
  • the means 510 of reception read the identifier 522 of an authentication device 300 in the field M610 of this request for activation M600 and store it in a register 522 of a random access memory (RAM) 520.
  • the request of activation M600 comes from a user account server 800 which will be described later with reference to FIG. 8.
  • the activation server 500 also includes means 530 for generating an authentication key. These means 530 for generating an authentication key are in particular suitable for generating the first authentication key 342 described with reference to FIG. 3.
  • They are also adapted, in another embodiment, to generate a second authentication key 542, from the first authentication key 342.
  • the activation server also includes means 550 for sending a message. These message sending means 550 are in particular adapted to send an activation request M600 as shown in FIG. 6.
  • the message sending means 550 are also suitable for constructing and sending, to the authentication device 300, on receipt of a response to the activation request M600, a key delivery message M400, as described in reference to FIG. 4. To construct this message, they first write a personal unlocking identification number 346, read in a pre-activation database 560, in the field M410 of the key delivery message M400 . The message sending means 550 then place the first authentication key 342 in the field M420, then generate a third authentication code and place it in the field M430.
  • the key delivery message M400 is encrypted by encryption means 570 of the activation server 500, before sending by the sending means 550.
  • the encryption means 570 use in particular the transport key 349 read in the pre-activation database 560.
  • the transport key 349 is also used by the message sending means 550 to generate the third authentication code.
  • the message sending means 550 are also suitable for sending an authentication record M700 shown in FIG. 7 to an authentication server 900 described below with reference to FIG. 9.
  • the authentication record M700 comprises two fields M710 and M720 respectively intended to contain the transport key 349 and the personal identification number 346.
  • the activation request M600, the key delivery message M400 and the authentication record M700 can be stored in the random access memory 520 of the activation server 500.
  • FIG. 8 represents a server of user accounts 800 according to the invention.
  • a user account server 800 includes means
  • creation means 810 for creating user accounts. These creation means 810 are in particular adapted to create a user account 830 and to store it in a storage area 820.
  • a user account 830 includes an identifier 522 of an authentication device 300 and various payment options 831, 832.
  • the user account server 800 also includes means 840 for sending a request. These means 840 for sending a request are in particular suitable for sending an activation request M600, as described with reference to FIG. 6, intended for an activation server 500. They are also suitable for sending a second authentication request to an authentication server 900 which will now be described.
  • FIG. 9 represents an authentication server 900 according to the invention.
  • An authentication server 900 includes means 910 for receiving an authentication record M700 from a activation server 500. These reception means 910 are adapted to store an authentication record M700 received in an area for storing authentication records 920.
  • the reception means 910 are also adapted to receive a second authentication request coming from a user account server 800.
  • the authentication server 900 comprises sending means 930 adapted to send a first activation request M100, described in relation to FIG. 1, intended for an authentication device 300.
  • the reception means 910 are also adapted to receive an authentication return message M200 from the authentication device 300.
  • the sending means 930 are finally adapted to send a transaction confirmation message (not shown here), intended for an account server users 800.
  • FIG. 10 represents a remote electronic payment system 10 according to the invention.
  • Such a system 10 includes an authentication device 300, an activation server 500, a user account server 800 and an authentication server 900.
  • the authentication device 300 is incorporated in a SIM card 20 adapted to be inserted into a slot 32 of a mobile telephone 30.
  • the remote electronic payment system 10 uses an infrastructure of a mobile telecommunications network 40 of GSM type for transporting authentication requests M100 , M200 authentication return messages, M400 key delivery messages and M600 activation requests. More specifically, M100, M200, M400 and M600 messages and requests conform to the SMS format of the GSM protocol.
  • the mobile telephone 30 also comprises input means 34, for example in the form of a keyboard, of a personal identification number 344.
  • the identifier 522 of the authentication device 300 is the telephone number of the mobile telephone 30, associated with the SIM card 20.
  • FIG. 11 represents a flow diagram of an authentication method according to the invention.
  • An authentication method according to the invention comprises a first step E1100 of reception of a key delivery message M400.
  • This M400 key delivery message is received from an activation server 500.
  • This M400 message contains an authentication key 342, a personal unlocking identification number 346 and a third authentication code in a field. M430.
  • Step E1100 is followed by a test E1110 during which the validity of the key delivery message M400 is checked. This verification uses in particular the third authentication code received during step E1100.
  • the E1110 test result is negative.
  • This test is then followed by a step E1120 during which an information message is sent to the activation server 500.
  • the result of the test E1110 is positive.
  • This test is then followed by a step E1130 of receiving a first authentication request M100 coming from an authentication server 900.
  • This first authentication request comprises, inter alia, a description of the transaction and a first authentication code.
  • This step E1130 is followed by a step E1135 for creating an authentication return message M200, the fields M210, M220, M230 and M240 of which are empty.
  • Step E1135 is followed by a step E1140 for decrypting the first authentication request M100, received during step E1130.
  • This decryption step E1140 uses a transport key 349, typically provided during a personalization step not shown here.
  • Step E1140 is followed by a test E1150 during which the validity of the authentication request is tested.
  • This test E1150 uses in particular the first authentication code contained in the field M 130 of the authentication request received in step E1130, as well as the first authentication key 342. When this request is not valid, the result of the E1150 test is negative.
  • This test is then followed by a step E1160, during which the field M210 of the authentication return message M200 created in step E1135 is initialized with an error code "MAC_NG" representative of the receipt of a request d authentication not valid.
  • Step E1160 is then followed by a step E1270 which will be described later.
  • step E1170 consists in comparing a personal identification number entered by the user, with a personal identification number 344, for example received by mail. In the event that the user enters an incorrect personal identification number, for example three times, the result of the test E1170 is negative.
  • step E1180 during which the field M210 of the authentication return message M200 created in step E1135 is initialized with an error code "PIN_NG" representative of an invalid user.
  • Step E1180 is then followed by a step E1270 which will be described later.
  • step E1170 When the user enters a personal identification number identical to personal identification number 344, the result of the test E1170 is positive. This test is then followed by a step E1190. During this step, the user accepts or refuses the transaction described in field M110 of the authentication request M100 received in step E1130.
  • a “Response” variable 322 is initialized with the value NG and step E1190 is followed by a step E1220 which will be described later.
  • step E1190 is followed by a step E1200 for selecting a payment option 324.
  • This payment option 324 is chosen from various payment options 831, 832 contained in the field M110 of the authentication request M100 received in step E1130. This payment option is then inserted during step E1210 in the field M220 of the authentication return message M200 created in step E1135.
  • Step E1210 is followed by a step E1220, during which the value of the “Response” variable 322 is inserted in the field M210 of the authentication return message M200 created in step E1135.
  • Step E1220 is followed by a step E1230, during which a transaction counter 348 is incremented.
  • the value of this transaction counter 348 is inserted, during the next step E1240,
  • Step E1240 is followed by a step E1250 of generating a second authentication code, inserted during the next step E1260 in the field M240 of the authentication return message created in step E1135.
  • 15- Step E1260 is followed by a step E1270 of encryption of the authentication return message M200 created during step E1135.
  • This message encryption step E1270 uses in particular the transport key 349.
  • Step E1270 is followed by a step E1280 of sending the authentication return message M200, intended for the authentication server 900, at the origin of the authentication request M100 received during the step E1130.

Abstract

Ce système de paiement électronique à distance comporte un dispositif d'authentification (300) auprès d'un serveur d'authentification dans un système de paiement à distance, l'authentification étant préalable à une transaction par un utilisateur, le dispositif (300) étant caractérisé en ce qu'il comporte: -des moyens (310) de réception d'une première requête d'authentification, en provenance du serveur d'authentification; -des moyens (330) de vérification de la validité de la requête d'authentification; -des moyens (350) de validation, par l'utilisateur, de la transaction; -des moyens (370) de contrôle de l'identité dudit utilisateur ; et -des moyens (380) d'envoi d'un message retour d'authentification, vers le serveur d'authentification (900).

Description

"Système de paiement électronique à distance"
La présente invention concerne un système de paiement électronique à distance. L'invention vise notamment un dispositif d'authentification auprès d'un serveur d'authentification dans un système de paiement à distance, permettant de déclencher des transactions à partir d'un téléphone portable.
Il n'existe actuellement pas de procédé permettant d'authentifier un utilisateur préalablement à une opération de paiement à distance qui s'affranchisse d'un lecteur de carte à puce.
Par ailleurs, dans une première catégorie connue d'appareils électroniques permettant de réaliser des transactions à distance, il est demandé à l'utilisateur de saisir des références d'un moyen de paiement, tel qu'une carte de crédit. Ces références sont, de façon connue, cryptées et transmises au fournisseur distant.
De tels appareils électroniques doivent comporter une interface utilisateur permettant une saisie facile de ces références. Ce n'est en particulier pas le cas pour les téléphones portables, dont le clavier et l'écran sont généralement de taille réduite. . On connaît également des téléphones portables comportant un lecteur de carte de crédit intégré. Cette solution permet effectivement de supprimer la saisie des références précitées. Elle permet en outre une authentification préalable à une opération de paiement. Mais cette solution nécessite en revanche des composants complexes et coûteux. ' Il apparaît de plus que la plupart des consommateurs hésitent à fournir les références d'un moyen de paiement à leur fournisseur, qui plus est à travers un réseau de communication.
On connaît également, dans le domaine du commerce électronique sur Internet, des systèmes de paiement électronique à distance, pour lesquels les références d'un moyen de paiement sont stockées sur un serveur appelé portefeuille électronique (« server based electronic wallet » en anglais). Dans un tel système, l'utilisateur s'authentifie auprès du serveur portefeuille électronique distant, depuis un terminal client, par exemple un ordinateur personnel (« PC ») comportant des moyens d'authentification, typiquement intégrés à un butineur Internet (« Internet browser » en anglais).
La plupart des téléphones portables, en particulier ceux ne comportant pas de butineur Internet, ne fournissent pas de tels moyens d'authentification. Les téléphones portables qui mettent en œuvre le protocole WAP ("Wireless Access Procol" en anglais) ne fournissent pas non plus de tels moyens. Ils ne peuvent donc pas servir de terminal client permettant à un utilisateur de s'authentifier auprès d'un serveur portefeuille électronique. La présente invention a pour but de résoudre ce problème, en proposant en particulier un dispositif d'authentification adapté à être incorporé dans un téléphone portable.
Dans ce but, la présente invention propose un dispositif d'authentification auprès d'un serveur d'authentification dans un système de paiement à distance, l'authentification étant préalable à une transaction par un utilisateur, le dispositif étant caractérisé en ce qu'il comporte :
-des moyens de réception d'une première requête d'authentification, en provenance du serveur d'authentification ;
-des moyens de vérification de la validité de la requête d'authentification ;
-des moyens de validation, par l'utilisateur, de la transaction ;
-des moyens de contrôle de l'identité de l'utilisateur ; et
-des moyens d'envoi d'un message retour d'authentification, vers le serveur d'authentification. Corrélativement, l'invention a pour objet un procédé d'authentification auprès d'un serveur d'authentification dans un système de paiement à distance, l'authentification étant préalable à une transaction par un utilisateur, le procédé étant caractérisé en ce qu'il comporte les étapes suivantes : -réception d'une première requête d'authentification, en provenance du serveur d'authentification ;
-vérification de la validité de la requête d'authentification ; -validation, par l'utilisateur, de la transaction ;
-contrôle de l'identité de l'utilisateur ; et
-envoi d'un message retour d'authentification, vers le serveur d'authentification. Les caractéristiques particulières et les avantages du procédé d'authentification étant similaires à ceux du dispositif d'authentification, ils ne sont pas énumérés ici.
Ainsi, l'invention permet tout d'abord d'authentifier l'utilisateur avant la validation de la transaction. De plus, l'envoi du message retour d'authentification se fait après une vérification de la validité de la requête d'authentification. Cette mesure permet de s'assurer que le message retour d'authentification n'est pas envoyé à un destinataire mal intentionné.
Selon une caractéristique particulière, la requête d'authentification comprend une description de la transaction, un identifiant de la transaction et un premier code d'authentification du serveur d'authentification, les moyens de vérification du dispositif d'authentification étant adaptés à vérifier la validité de la requête d'authentification à partir du premier code d'authentification et d'une première clef d'authentification.
Ce mécanisme à clef d'authentification permet de vérifier, avec une excellente fiabilité, la validité de la requête d'authentification.
Selon une autre caractéristique particulière, le dispositif d'authentification comporte en outre des moyens de génération d'un deuxième code d'authentification, les moyens d'envoi du message retour d'authentification étant adaptés à insérer ce deuxième code d'authentification dans le message retour d'authentification.
Ce mécanisme permet, au niveau du serveur d'authentification, de s'assurer que le message retour d'authentification provient effectivement du dispositif d'authentification.
Selon une caractéristique préférée, les moyens d'envoi du message retour d'authentification sont adaptés à insérer une réponse fonction de la validation de la transaction dans le message retour d'authentification. Le message retour d'authentification pourra par exemple contenir des données représentatives de l'acceptation de la transaction par l'utilisateur, qui pourront être transmises par le serveur d'authentification à un établissement financier. Selon une caractéristique préférée, les moyens de contrôle de l'identité de l'utilisateur utilisent un numéro d'identification personnel.
Ce numéro d'identification personnel, que l'utilisateur aura par exemple reçu par courrier, empêchera l'utilisation du dispositif d'authentification par un tiers. De façon connue, les moyens de contrôle de l'identité de l'utilisateur peuvent par exemple être adaptés à bloquer le dispositif d'authentification après trois saisies d'un numéro d'identification personnel erroné.
Selon une caractéristique préférée, le dispositif d'authentification comporte en outre des moyens de déchiffrement de la première requête d'authentification à partir d'une clef de transport, et/ou des moyens de chiffrement du message retour d'authentification à partir d'une clef de transport.
Cette caractéristique avantageuse augmente considérablement la confidentialité de la transaction.
Selon une autre caractéristique, la transaction comportant une opération de paiement, le dispositif comporte des moyens de sélection d'une option de paiement de la transaction et les moyens d'envoi du message retour d'authentification sont adaptés à insérer cette option dans le message retour d'authentification.
Ceci permet en particulier d'offrir un service de paiement électronique à distance indépendant d'une option de paiement. Il est même tout à fait envisageable que ces moyens de paiement soient virtuels, ou dédiés à ce service de paiement électronique à distance. Même piratés, ils ne sont dans ce cas d'aucune utilité pour un utilisateur mal intentionné, ce qui renforce encore la sécurité du système. Selon une autre caractéristique particulière, le dispositif d'authentification comporte en outre un compteur de transactions utilisé par les moyens de génération et du deuxième code d'authentification et inséré par les moyens d'envoi du message retour d'authentification dans le message retour d'authentification.
Cet identificateur permet ainsi d'identifier, de manière unique, chaque message retour d'authentification. Selon une autre caractéristique particulière, le dispositif d'authentification comporte des moyens de réception, en provenance d'un serveur d'activation, d'un message de livraison de clefs, le message de livraison de clefs comportant la première clef d'authentification.
La clef d'authentification est ainsi fournie par un serveur, de préférence de façon transparente pour l'utilisateur, ce qui permet de renforcer la sécurité du système.
Selon une autre caractéristique particulière, le message de livraison de clefs comporte en outre un numéro d'identification personnel de déblocage. De façon classique, ce numéro d'identification personnel de déblocage est utilisé pour débloquer le dispositif d'authentification lorsque celui- ci a été bloqué, par exemple après trois saisies d'un numéro d'identification personnel erroné.
Selon une autre caractéristique particulière, le dispositif d'authentification comporte en outre des moyens de vérification de la validité du message de livraison de clefs, à partir d'un troisième code d'authentification contenu dans le message de livraison de clefs.
L'invention vise également un serveur d'activation, dans un système de paiement à distance, caractérisé en ce qu'il comporte : -des moyens de réception d'une requête d'activation en provenance d'un serveur de comptes d'utilisateurs, la requête d'activation comportant un identificateur d'un dispositif d'authentification tel que décrit ci- dessus ;
-des moyens de génération de la première clef d'authentification ; et
-des moyens d'envoi, sur réception d'une réponse à la requête d'activation, du message de livraison de clefs au dispositif d'authentification. La génération de la clef d'authentification est ainsi sous la responsabilité du serveur d'activation.
Selon une caractéristique particulière, l'identificateur est un numéro de téléphone. Selon une autre caractéristique particulière, le serveur d'activation comporte en outre des moyens de sauvegarde de la première clef d'authentification dans une base de données sécurisée.
Le serveur d'activation garde ainsi une copie de la première clef d'authentification. Cette clef pourra être transmise ultérieurement à un serveur d'authentification qui pourra mettre en œuvre un mécanisme d'authentification à clef symétrique (en anglais « Symmetrical Key Infrastructure ») avec le dispositif d'authentification.
Selon une autre caractéristique, le serveur d'activation comporte des moyens de génération d'une deuxième clef d'authentification, à partir de la première clef d'authentification, et comporte des moyens de sauvegarde de cette deuxième clef d'authentification dans la base de données sécurisée.
Cette deuxième clef pourra alors être transmise ultérieurement à un serveur d'authentification qui pourra mettre en œuvre un mécanisme d'authentification à clef asymétrique avec le dispositif d'authentification. Selon une autre caractéristique particulière, le serveur d'activation comporte des moyens de calcul d'un troisième code d'authentification, ce troisième code d'authentification étant inséré dans le message de livraison de clefs.
Ce mécanisme permet au dispositif d'authentification de s'assurer de la validité du message de livraison de clefs.
Selon une autre caractéristique particulière, le senteur d'activation insère un numéro d'identification personnel de déblocage dans le message de livraison de clefs.
Comme décrit précédemment, ce numéro d'identification personnel de déblocage est utilisé pour débloquer le dispositif d'authentification lorsque celui-ci a été bloqué, par exemple après trois saisies d'un numéro d'identification personnel erroné. Selon une autre caractéristique particulière, le serveur d'activation comporte en outre des moyens de chiffrement du message de livraison de clefs, à partir d'une clef de transport.
Cette caractéristique avantageuse augmente considérablement la confidentialité du message d'activation.
Selon une autre caractéristique particulière, le serveur d'activation comporte en outre des moyens d'obtention de la clef de transport et d'un numéro d'identification personnel de déblocage à partir d'une base de données de pré-activation. Cette clef de transport peut en outre être utilisée pour le calcul du troisième code d'authentification.
Cette base de données de pré-activation est typiquement une base de données générique, mise à jour pour chaque création d'un dispositif d'authentification. Cela permet en particulier à l'opérateur du système de paiement de garder une maîtrise sur les dispositifs d'authentification.
Selon une autre caractéristique particulière, le serveur d'activation comporte des moyens d'envoi d'un enregistrement d'authentification, à destination d'un serveur d'authentification, l'enregistrement d'authentification comportant la clef de transport et le numéro d'identification personnel de déblocage.
Le serveur d'authentification possédera ainsi la clef de transport lui permettant d'échanger, de façon sécurisée, les messages relatifs aux transactions avec le dispositif d'authentification.
Corrélativement, l'invention vise un serveur de comptes utilisateurs, dans un système de paiement à distance, caractérisé en ce qu'il comporte :
-des moyens de création et de stockage d'au moins un compte utilisateur associé à un dispositif d'authentification tel que décrit ci-dessus ;
-des moyens d'envoi d'une requête d'activation, à destination d'un serveur d'activation tel que décrit ci-dessus ; et
-des moyens d'envoi d'une deuxième requête d'authentification à destination d'un serveur d'authentification. Un compte utilisateur est ainsi créé pour tout utilisateur en possession d'un dispositif d'authentification tel que décrit ci-dessus et désirant effectivement utiliser (par exemple via un abonnement) un tel système de paiement électronique à distance. Après création de ce compte, le serveur de comptes utilisateurs envoie une requête d'activation à destination du serveur d'activation qui génère et fournit la clef d'authentification à l'utilisateur.
Selon une caractéristique particulière, un compte utilisateur comporte un identificateur du dispositif d'authentification (par exemple un numéro de téléphone) et au moins une option de paiement de la transaction. L'invention vise aussi un serveur d'authentification, dans un système de paiement à distance, caractérisé en ce qu'il comporte :
-des moyens de réception d'au moins un enregistrement d'authentification en provenance d'un serveur d'activation tel que décrit ci- dessus ; -des moyens de stockage de l'enregistrement d'authentification ;
-des moyens de réception d'une deuxième requête d'authentification en provenance d'un serveur de comptes utilisateurs tel que décrit ci-dessus ;
-des moyens d'envoi de la première requête d'authentification, à destination d'un dispositif d'authentification tel que décrit ci-dessus, à réception de la deuxième requête d'authentification ;
-des moyens de réception d'un message retour d'authentification, en provenance du dispositif d'authentification ; et
-des moyens d'envoi d'un message de confirmation de transaction au serveur de comptes utilisateurs, sur réception du message retour d'authentification.
Un tel serveur d'authentification reçoit ainsi, à l'activation du service, un enregistrement d'authentification contenant la clef de transport et le numéro d'identification personnel de déblocage associés à un dispositif d'authentification. Pour chaque transaction, il reçoit alors une requête d'authentification provenant d'un serveur de comptes utilisateurs. Il peut alors envoyer une première requête d'authentification à un dispositif d'authentification incorporé dans un terminal client, et recevoir en retour une validation de la transaction de l'utilisateur ainsi qu'un moyen de paiement. Ces dernières informations sont ainsi transmises dans un message de confirmation de transaction au serveur de comptes utilisateurs qui termine la transaction proprement dite.
Corrélativement, l'invention vise un système de paiement à distance, caractérisé en ce qu'il comporte un dispositif d'authentification, un serveur d'activation, un serveur de comptes utilisateurs et un serveur d'authentification tels que décrits ci-dessus. Selon une caractéristique particulière, le système de paiement à distance utilise une infrastructure d'un réseau de téléphonie mobile, par exemple celle d'un réseau GSM.
Un dispositif d'authentification peut ainsi être incorporé dans un terminal client mobile. Selon une autre caractéristique particulière, les messages et requêtes décrits ci-dessus sont conformes au format SMS du réseau GSM.
Cette caractéristique permet avantageusement de ne pas développer un protocole de communication spécifique pour le déploiement d'un tel service de paiement électronique à distance. L'invention vise aussi une carte à puce et une carte SIM comportant un dispositif d'authentification tel que défini ci-dessus.
Ceci permet avantageusement d'utiliser les moyens de chiffrement et de déchiffrement de la carte SIM, traditionnellement dédiés au chiffrement et au déchiffrement de messages de télécommunication, pour le chiffrement et le déchiffrement de messages associés à un paiement électronique à distance.
L'invention vise également un téléphone comportant des moyens adaptés à recevoir une carte SIM telle que définie ci-dessus.
Ainsi, un tel téléphone peut ainsi être utilisé comme terminal client d'authentification auprès d'un serveur portefeuille électronique. Selon une caractéristique particulière, le téléphone selon la comporte en outre des moyens de saisie du numéro d'identification personnel. Ainsi, et de façon connue, l'utilisateur peut saisir son numéro d'identification personnel, ce numéro ayant été par exemple reçu par courrier en confirmation de l'abonnement.
D'autres aspects et avantages de la présente invention apparaîtront plus clairement à la lecture de la description de modes particuliers de réalisation qui va suivre, cette description étant donnée uniquement à titre d'exemple non limitatif et faite en référence aux dessins annexés sur lesquels :
-la figure 1 représente schématiquement une requête d'authentification selon l'invention, dans un mode particulier de réalisation ; -la figure 2 représente un message retour d'authentification selon l'invention, dans un mode particulier de réalisation ;
-la figure 3 représente un dispositif d'authentification selon l'invention, dans un mode particulier de réalisation ;
-la figure 4 représente un message de livraison de clefs selon l'invention, dans un mode particulier de réalisation ;
-la figure 5 représente un serveur d'activation selon l'invention, dans un mode particulier de réalisation ;
-la figure 6 représente une requête d'activation selon l'invention, dans un mode particulier de réalisation ; -la figure 7 représente un enregistrement d'authentification selon l'invention, dans un mode particulier de réalisation ;
-la figure 8 représente un serveur de comptes utilisateurs selon l'invention, dans un mode particulier de réalisation ;
-la figure 9 représente un serveur d'authentification selon l'invention, dans un mode particulier de réalisation ;
-la figure 10 représente un système de paiement électronique à distance selon l'invention, dans un mode particulier de réalisation ; et
-la figure 11 représente un organigramme d'un procédé d'authentification selon l'invention, dans un mode particulier de réalisation. La figure 1 représente une requête d'authentification M100 selon l'invention. Une telle requête d'authentification M100 comporte un premier champ M110 comportant les détails d'une transaction. Ces détails sont par exemple les références d'un fournisseur, le montant de la transaction et différentes options de paiement 831 , 832 illustrées sur la figure 8.
La requête d'authentification M 100 comporte un deuxième champ
M 120 d'identification de la transaction, par exemple sous la forme d'un numéro de transaction. Elle comporte enfin un premier code d'authentification M130. Ce premier code d'authentification M 130 permet de s'assurer que la requête d'authentification M 100 a été émise par un serveur d'authentification valide.
La figure 2 représente un message retour d'authentification M200 selon l'invention. Une tel message retour d'authentification M200 comporte un premier champ M210 de réponse utilisateur, représentatif de l'acceptation ou du rejet de la transaction décrite dans le champ M110 d'une requête d'authentification M 100.
Le message retour d'authentification M200 comporte également un champ M220 contenant une option de paiement de la transaction. Ce champ est bien entendu utile uniquement dans le cas où le champ réponse utilisateur M210 est représentatif de l'acceptation de la transaction.
Le message retour d'authentification comporte également, dans un champ M230, la valeur d'un compteur de transactions 348 tel que décrit ultérieurement en référence à la figure 3. Le message retour d'authentification M200 comporte enfin un deuxième code d'authentification dans un champ M240, ce code étant similaire au premier code d'authentification M130 de la requête d'authentification M100.
La figure 3 représente un dispositif d'authentification 300 selon l'invention. Le dispositif d'authentification 300 comporte des moyens 310 de réception d'une requête d'authentification M100 comme décrit en référence à la figure 1. Ces moyens de réception 310 sont adaptés à stocker la requête d'authentification M100 reçue dans une mémoire vive 320 (RAM).
Le dispositif d'authentification 300 comporte des moyens 330 de vérification de la validité de la requête d'authentification M 100. Ces moyens utilisent en particulier le premier code d'authentification M130 contenu dans la requête d'authentification M100 et une première clef d'authentification 342 stockée dans un registre d'une mémoire non volatile (EEPROM) 340. Cette première clef d'authentification 342 est par exemple reçue en provenance d'un serveur d'activation 500 tel que décrit ultérieurement en référence à la figure 5. Le procédé mis en œuvre par les moyens de vérification 330 sont connus de l'homme du métier et ne seront pas décrits ici. Ces moyens de vérification 330 sont bien entendu adaptés à vérifier toute autre requête reçue par le dispositif d'authentification 300 et en particulier une requête d'activation M600 telle que décrite ultérieurement en référence à la figure 6.
Le dispositif d'authentification 300 comporte des moyens 350 de validation d'une transaction. Ces moyens sont par exemple adaptés à afficher les détails de la transaction contenus dans le champ M110 de la requête M100 et à recueillir une réponse utilisateur 322 représentative de l'acceptation ou du rejet de la transaction par l'utilisateur. Cette réponse utilisateur 322 est stockée dans la RAM 320 par les moyens 350 de validation d'une transaction.
Le dispositif d'authentification 300 comporte également des moyens 360 de sélection d'une option de paiement 324 parmi les options de paiement 831 , 832. Ces moyens sont en particulier adaptés à fournir une liste des options de paiement 831 , 832 présentes dans le champ M110 de la requête d'authentification M100. Ces moyens 360 de sélection d'une option de paiement sont également adaptés à stocker, dans un registre de la mémoire vive 320, l'option de paiement 324 retenue par l'utilisateur.
Le dispositif d'authentification 300 comporte également des moyens 370 de contrôle de l'identité de l'utilisateur. Ces moyens sont par exemple adaptés à vérifier, de façon connue, un numéro d'identification personnel (PIN) 344 stocké dans un registre de la mémoire non volatile 340. Ces moyens 370 de contrôle de l'identité de l'utilisateur sont également adaptés à bloquer le dispositif d'authentification 300 lorsque l'utilisateur saisit, à trois reprises, un numéro d'identification personnel différent du numéro d'identification personnel 344. Le dispositif 300 peut alors être débloqué par la saisie d'un numéro d'identification personnel de déblocage 346, stocké dans la mémoire non volatile 340.
Ce numéro d'identification personnel de déblocage 346 et la première clef d'authentification 342 sont respectivement reçus par le dispositif d'authentification 300 dans les champs M410 et M420 d'un message de livraison de clefs M400 représenté sur la figure 4. Le message de livraison de clefs M400 comporte enfin un troisième code d'authentification M430 similaire au premier code d'authentification M 130 de la requête d'authentification M100. De retour à la figure 3, les moyens 330 de vérification sont également adaptés à vérifier la validité du message de livraison de clef M400, à partir du troisième code d'authentification. Le dispositif d'authentification 300 comporte également des moyens 380 d'envoi d'un message retour d'authentification M200, tel que décrit précédemment en référence à la figure 2. Ces moyens 380 d'envoi d'un message retour d'authentification sont adaptés à incrementer, avant chaque envoi d'un message retour d'authentification M200, un compteur de transactions 348, contenu dans un registre de la mémoire non volatile 340.
Ils sont également adaptés à générer un deuxième code d'authentification 326 et à le stocker dans un registre de la mémoire vive 320.
Les moyens 380 d'envoi d'un message retour d'authentification M200 sont aussi adaptés à construire un tel message, à partir de la' réponse utilisateur 322, de l'option de paiement 324, du compteur de transactions 348 et du deuxième code d'authentification 326, ces valeurs remplissant respectivement les champs M210, M220, M230 et M240.
Les moyens 380 d'envoi d'un message retour d'authentification sont également adaptés à envoyer un message M200 à destination d'un serveur d'authentification 900, tel que décrit ultérieurement en référence à la figure 9. Le dispositif d'authentification 300 comporte également des moyens de chiffrement et de déchiffrement 390, adaptés respectivement à chiffrer un message retour d'authentification M200 et à déchiffrer une requête d'authentification M 100, à partir d'une clef de transport 349 stockée dans un registre de la mémoire non volatile 340. Cette clef de transport 349 est fournie au moment de la personnalisation du dispositif d'authentification 300.
La figure 5 représente un serveur d'activation 500 selon l'invention. Un serveur d'activation 500 comporte des moyens 510 de réception d'une requête d'activation M600 représentée sur la figure 6. Une telle requête d'activation M600 comporte un champ M610 contenant un identificateur d'un dispositif d'authentification 300. Sur réception d'une requête d'activation M600, les moyens 510 de réception lisent l'identificateur 522 d'un dispositif d'authentification 300 dans le champ M610 de cette requête d'activation M600 et le stockent dans un registre 522 d'une mémoire vive (RAM) 520. La requête d'activation M600 provient d'un serveur de comptes utilisateurs 800 qui sera décrit ultérieurement en référence à la figure 8.
De retour à la figure 5, le serveur d'activation 500 comporte également des moyens 530 de génération d'une clef d'authentification. Ces moyens 530 de génération d'une clef d'authentification sont en particulier adaptés à générer la première clef d'authentification 342 décrite en référence à la figure 3.
Ils sont également adaptés, dans un autre mode de réalisation, à générer une deuxième clef d'authentification 542, à partir de la première clef d'authentification 342.
Ces moyens 530 de génération d'une clef d'authentification sont également adaptés à stocker les clefs d'authentification 342 et 542 générées dans une base de données sécurisée 540. Le serveur d'activation comporte également des moyens 550 d'envoi de message. Ces moyens 550 d'envoi de message sont en particulier adaptés à envoyer une requête d'activation M600 telle que représentée sur la figure 6.
Les moyens 550 d'envoi de message sont également adaptés à construire et à envoyer, au dispositif d'authentification 300, sur réception d'une réponse à la requête d'activation M600, un message M400 de livraison de clefs, tel que décrit en référence à la figure 4. Pour construire ce message, ils écrivent tout d'abord un numéro d'identification personnel de déblocage 346, lu dans une base de données de pré-activation 560, dans le champ M410 du message de livraison de clefs M400. Les moyens 550 d'envoi de message placent ensuite la première clef d'authentification 342 dans le champ M420, puis génèrent un troisième code d'authentification et le placent dans le champ M430. Dans un mode préféré de réalisation, le message de livraison de clefs M400 est chiffré par des moyens de chiffrement 570 du serveur d'activation 500, avant l'envoi par les moyens d'envoi 550. Les moyens de chiffrement 570 utilisent en particulier la clef de transport 349 lue dans la base de données de pré-activation 560. Dans un mode particulier de réalisation, la clef de transport 349 est également utilisée par les moyens 550 d'envoi de message pour générer le troisième code d'authentification.
Les moyens 550 d'envoi de message sont également adaptés à envoyer un enregistrement d'authentification M700 représenté sur la figure 7 à un serveur d'authentification 900 décrit plus loin en référence à la figure 9. L'enregistrement d'authentification M700 comporte deux champs M710 et M720 destinés respectivement à contenir la clef de transport 349 et le numéro d'identification personnel de déblocage 346.
La requête d'activation M600, le message M400 de livraison de clefs et l'enregistrement d'authentification M700 peuvent être mémorisés dans la mémoire vive 520 du serveur d'activation 500.
La figure 8 représente un serveur de comptes utilisateurs 800 selon l'invention. Un serveur de comptes utilisateurs 800 comporte des moyens
810 de création de comptes utilisateurs. Ces moyens de création 810 sont en particulier adaptés à créer un compte utilisateur 830 et à le stocker dans une zone de stockage 820.
Un compte utilisateur 830 comporte un identificateur 522 d'un dispositif d'authentification 300 et différentes options de paiement 831 , 832.
Le serveur de comptes utilisateurs 800 comporte également des moyens 840 d'envoi d'une requête. Ces moyens 840 d'envoi d'une requête sont en particulier adaptés à envoyer une requête d'activation M600, telle que décrite en référence à la figure 6, à destination d'un serveur d'activation 500. Ils sont également adaptés à envoyer une deuxième requête d'authentification à destination d'un serveur d'authentification 900 qui va maintenant être décrit. La figure 9 représente un serveur d'authentification 900 selon l'invention. Un serveur d'authentification 900 comporte des moyens 910 de réception d'un enregistrement d'authentification M700 en provenance d'un serveur d'activation 500. Ces moyens de réception 910 sont adaptés à stocker un enregistrement d'authentification M700 reçu dans une zone de stockage d'enregistrements d'authentification 920.
Les moyens de réception 910 sont également adaptés à recevoir une deuxième requête d'authentification en provenance d'un serveur de comptes utilisateurs 800.
Le serveur d'authentification 900 comporte des moyens d'envoi 930 adaptés à envoyer une première requête d'activation M100, décrite en relation avec la figure 1 , à destination d'un dispositif d'authentification 300. Les moyens de réception 910 sont également adaptés à recevoir un message retour d'authentification M200 en provenance du dispositif d'authentification 300. Les moyens d'envoi 930 sont enfin adaptés à envoyer un message de confirmation de transaction (non représenté ici), à destination d'un serveur de comptes utilisateurs 800. La figure 10 représente un système 10 de paiement électronique à distance selon l'invention. Un tel système 10 comporte un dispositif d'authentification 300, un serveur d'activation 500, un serveur de comptes utilisateurs 800 et un serveur d'authentification 900. Dans le mode de réalisation décrit ici, le dispositif d'authentification 300 est incorporé dans une carte SIM 20 adaptée à être insérée dans une fente 32 d'un téléphone portable 30. Le système 10 de paiement électronique à distance utilise une infrastructure d'un réseau 40 de télécommunications mobiles de type GSM pour le transport des requêtes d'authentification M100, des messages retour d'authentification M200, des messages de livraison de clefs M400 et des requêtes d'activation M600. Plus précisément, les messages et requêtes M100, M200, M400 et M600 sont conformes au format SMS du protocole GSM. Le téléphone portable 30 comporte en outre des moyens de saisie 34, par exemple sous forme d'un clavier, d'un numéro d'identification personnel 344. Dans ce mode de réalisation, l'identificateur 522 du dispositif d'authentification 300 est le numéro de téléphone du téléphone mobile 30, associé à la carte SIM 20.
La figure 11 représente un organigramme d'un procédé d'authentification selon l'invention. Un procédé d'authentification selon l'invention comporte une première étape E1100 de réception d'un message M400 de livraison de clefs. Ce message de livraison de clefs M400 est reçu en provenance d'un serveur d'activation 500. Ce message M400 contient une clef d'authentification 342, un numéro d'identification personnel de déblocage 346 et un troisième code d'authentification dans un champ M430.
L'étape E1100 est suivie par un test E1110 au cours duquel la validité du message de livraison de clefs M400 est vérifiée. Cette vérification utilise en particulier le troisième code d'authentification reçu au cours de l'étape E1100.
Lorsque ce message de livraison de clefs n'est pas valide, le résultat du test E1110 est négatif. Ce test est alors suivi par une étape E1120 au cours de laquelle un message d'information est envoyé au serveur d'activation 500. Dans le cas où le message de livraison de clefs M400 est valide, le résultat du test E1110 est positif. Ce test est alors suivi par une étape E1130 de réception d'une première requête d'authentification M100 en provenance d'un serveur d'authentification 900. Cette première requête d'authentification comporte, entre autres, une description de la transaction et un premier code d'authentification.
Cette étape E1130 est suivie par une étape E1135 de création d'un message retour d'authentification M200, dont les champs M210, M220, M230 et M240 sont vides.
L'étape E1135 est suivie par une étape E1140 de déchiffrement de la première requête d'authentification M100, reçue au cours de l'étape E1130. Cette étape de déchiffrement E1140 utilise une clef de transport 349, typiquement fournie lors d'une étape de personnalisation non représentée ici.
L'étape E1140 est suivie par un test E1150 au cours duquel la validité de la requête d'authentification est testée. Ce test E1150 utilise en particulier le premier code d'authentification contenu dans le champ M 130 de la requête d'authentification reçue à l'étape E1130, ainsi que la première clef d'authentification 342. Lorsque cette requête n'est pas valide, le résultat du test E1150 est négatif. Ce test est alors suivi par une étape E1160, au cours de laquelle le champ M210 du message retour d'authentification M200 créé à l'étape E1135 est initialisé avec un code d'erreur « MAC_NG » représentatif de la réception d'une requête d'authentification non valide. L'étape E1160 est alors suivie par une étape E1270 qui sera décrite ultérieurement.
Lorsque la requête d'authentification M 100 est valide, le résultat du test E1150 est positif. Ce test est alors suivi par un test E1170 au cours duquel l'identité de l'utilisateur est vérifiée. De façon connue, l'étape E1170 consiste à comparer un numéro d'identification personnel saisi par l'utilisateur, avec un numéro d'identification personnel 344, par exemple reçu par courrier. Dans le cas où l'utilisateur saisit un numéro d'identification personnel erroné, par exemple à trois reprises, le résultat du test E1170 est négatif. Ce test est alors suivi par une étape E1180 au cours de laquelle le champ M210 du message retour d'authentification M200 créé à l'étape E1135 est initialisé avec un code d'erreur « PIN_NG » représentatif d'un utilisateur non valide. L'étape E1180 est alors suivie par une étape E1270 qui sera décrite ultérieurement.
Lorsque l'utilisateur saisit un numéro d'identification personnel identique au numéro d'identification personnel 344, le résultat du test E1170 est positif. Ce test est alors suivi par une étape E1190. Au cours de cette étape, l'utilisateur accepte ou refuse la transaction décrite dans le champ M110 de la requête d'authentification M100 reçue à l'étape E1130.
Lorsque cette transaction est refusée, une variable « Réponse » 322 est initialisée avec la valeur NG et l'étape E1190 est suivie par une étape E1220 qui sera décrite ultérieurement.
Lorsque cette transaction est acceptée, la variable « Réponse » 322 est initialisée avec la valeur OK. L'étape E1190 est dans ce cas suivie par une étape E1200 de sélection d'une option de paiement 324. Cette option de paiement 324 est choisie parmi différentes options de paiement 831 , 832 contenues dans le champ M110 de la requête d'authentification M100 reçue à l'étape E1130. Cette option de paiement est ensuite insérée au cours de l'étape E1210 dans le champ M220 du message retour d'authentification M200 créé à l'étape E1135.
L'étape E1210 est suivie par une étape E1220, au cours de 5 laquelle la valeur de la variable « Réponse » 322 est insérée dans le champ M210 du message retour d'authentification M200 créé à l'étape E1135.
L'étape E1220 est suivie par une étape E1230, au cours de laquelle un compteur de transactions 348 est incrémenté. La valeur de ce compteur de transactions 348 est insérée, au cours de l'étape suivante E1240,
10 dans le champ M230 du message retour d'authentification M200 créé à l'étape
E1135.
L'étape E1240 est suivie par une étape E1250 de génération d'un deuxième code d'authentification, inséré au cours de l'étape suivante E1260 dans le champ M240 du message retour d'authentification créé à l'étape E1135. 15- L'étape E1260 est suivie par une étape E1270 de chiffrement du message retour d'authentification M200 créé au cours de l'étape E1135. Cette étape E1270 de chiffrement de message utilise en particulier la clef de transport 349.
L'étape E1270 est suivie par une étape E1280 d'envoi du 20. message retour d'authentification M200, à destination du serveur d'authentification 900, à l'origine de la requête d'authentification M100 reçue au cours de l'étape E1130.

Claims

REVENDICATIONS
1. Dispositif d'authentification (300) auprès d'un serveur d'authentification (900) dans un système de paiement à distance (10), ladite authentification étant préalable à une transaction par un utilisateur, ledit dispositif (300) étant caractérisé en ce qu'il comporte :
-des moyens (310) de réception d'une première requête d'authentification (M100), en provenance dudit serveur d'authentification (900) ; -des moyens (330) de vérification de la validité de ladite requête d'authentification (M 100) ;
-des moyens (350) de validation, par l'utilisateur, de ladite transaction ;
-des moyens (370) de contrôle de l'identité dudit utilisateur ; et -des moyens (380) d'envoi d'un message retour d'authentification (M200), vers ledit serveur d'authentification (900).
2. Dispositif d'authentification (300) selon la revendication 1 , ladite requête d'authentification (M 100) comprenant une description de ladite transaction, un identifiant de ladite transaction et un premier code d'authentification dudit serveur d'authentification (900), ledit dispositif (300) étant caractérisé en ce que lesdits moyens (330) de vérification sont adaptés à vérifier la validité de ladite requête d'authentification (M100) à partir dudit premier code d'authentification et d'une première clef d'authentification (342).
3. Dispositif d'authentification (300) selon la revendication 1 ou 2, caractérisé en ce qu'il comporte en outre des moyens (380) de génération d'un deuxième code d'authentification (326), et en ce que lesdits moyens (380) d'envoi du message retour d'authentification (M200) sont adaptés à insérer ledit deuxième code d'authentification (326) dans ledit message retour d'authentification (M240).
4. Dispositif d'authentification (300) selon l'une quelconque des revendications 1 à 3, caractérisé en ce que lesdits moyens (380) d'envoi du message retour d'authentification (M200) sont adaptés à insérer une réponse (322) dans ledit message retour d'authentification (M200), ladite réponse (322) étant fonction de ladite validation de la transaction.
5. Dispositif d'authentification (300) selon l'une quelconque des revendications 1 à 4, caractérisé en ce que lesdits moyens (370) de contrôle de l'identité dudit utilisateur utilisent un numéro d'identification personnel (344).
6. Dispositif d'authentification (300) selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comporte en outre des moyens (390) de déchiffrement de ladite première requête d'authentification (M100), à partir d'une clef de transport (349).
7. Dispositif d'authentification (300) selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comporte en outre des moyens (390) de chiffrement dudit message retour d'authentification (M200), à partir d'une clef de transport (349).
8. Dispositif d'authentification (300) selon l'une quelconque des revendications 1 à 7, ladite transaction comportant une opération de paiement, ledit dispositif étant caractérisé en ce qu'il comporte en outre des moyens (360) de sélection d'une option de paiement (324) de ladite transaction et en ce que lesdits moyens (380) d'envoi du message retour d'authentification (M200) sont adaptés à insérer ladite option (324) dans ledit message retour ' d'authentification (M220).
9. Dispositif d'authentification (300) selon l'une quelconque des revendications 3 à 8, caractérisé en ce qu'il comporte en outre un compteur de transactions (348) utilisé par lesdits moyens (380) de génération dudit deuxième code d'authentification (326), et en ce que lesdits moyens (380) • d'envoi du message retour d'authentification (M200) sont adaptés à insérer ledit compteur de transactions (348) dans ledit message retour d'authentification (M230).
10. Dispositif d'authentification (300) selon l'une quelconque des revendications 2 à 9, caractérisé en ce qu'il comporte en outre des moyens (310) de réception, en provenance d'un serveur d'activation (500), d'un message de livraison de clefs (M400), ledit message de livraison de clefs (M400) comportant ladite première clef d'authentification (342).
11. Dispositif d'authentification (300) selon la revendication 10, caractérisé en ce ledit message de livraison de clefs (M400) comporte en outre un numéro d'identification personnel de déblocage (346).
12. Dispositif d'authentification (300) selon la revendication 10 ou 11 , caractérisé en ce qu'il comporte en outre des moyens (330) de vérification de la validité dudit message de livraison de clefs (M400), à partir d'un troisième code d'authentification contenu dans ledit message de livraison de clefs (M430).
13. Carte à puce, caractérisée en ce qu'elle comporte un dispositif d'authentification (300) selon l'une quelconque des revendications 1 à 12.
14. Carte SIM (20), caractérisée en ce qu'elle comporte un dispositif d'authentification (300) selon l'une quelconque des revendications 1 à 12.
15. Téléphone (30), caractérisé en ce qu'il comporte des moyens (32) adaptés à recevoir une carte SIM (20) selon la revendication 14.
16. Téléphone (30) selon la revendication 15, la carte SIM (20) comportant un dispositif d'authentification (300) selon l'une quelconque des revendications 5 à 12, ledit téléphone (30) étant caractérisé en ce qu'il comporte en outre des moyens (34) de saisie dudit numéro d'identification personnel (344).
17. Serveur d'activation (500), dans un système de paiement à distance (10), caractérisé en ce qu'il comporte :
-des moyens (510) de réception d'une requête d'activation (M600) en provenance d'un serveur de comptes d'utilisateurs (800), ladite requête d'activation (M600) comportant un identificateur (522) d'un dispositif d'authentification (300) selon l'une quelconque des revendications 10 à 12 ;
-des moyens (530) de génération de ladite première clef d'authentification (342) ; et
-des moyens (550) d'envoi, sur réception d'une réponse à ladite requête d'activation (M600), dudit message de livraison de clefs (M400) audit dispositif d'authentification (300).
18. Serveur d'activation (500) selon la revendication 17, caractérisé en ce que ledit identificateur (522) est un numéro de téléphone.
19. Serveur d'activation (500) selon la revendication 17 ou 18, caractérisé en ce qu'il comporte en outre des moyens (530) de sauvegarde de ladite première clef d'authentification (342) dans une base de données sécurisée (540).
20. Serveur d'activation (500) selon l'une quelconque des revendications 17 à 19, caractérisé en ce qu'il comporte en outre des moyens (530) de génération d'une deuxième clef d'authentification (542), à partir de ladite première clef d'authentification (342) et en ce qu'il comporte des moyens de sauvegarde (530) de ladite deuxième clef d'authentification (542) dans une base de données sécurisée (540).
21. Serveur d'activation (500) selon l'une quelconque des revendications 17 à 20, caractérisé en ce qu'il comporte en outre des moyens (550) de calcul d'un troisième code d'authentification, et en ce que lesdits moyens d'envoi (550) sont adaptés à insérer ledit troisième code d'authentification dans ledit message de livraison de clefs (M430).
22. Serveur d'activation (500) selon l'une quelconque des revendications 17 à 21 , ladite requête d'activation (M600) comportant un identificateur d'un dispositif d'authentification (522) selon la revendication 11 ou 12, ledit serveur d'activation (500) étant caractérisé en ce que lesdits moyens (550) d'envoi sont adaptés à insérer ledit numéro d'identification personnel de déblocage (346) dans ledit message de livraison de clefs (M410).
23. Serveur d'activation (500) selon la revendication 21 , caractérisé en ce qu'il comporte en outre des moyens (570) de chiffrement dudit message de livraison de clefs (M400), à partir d'une clef de transport (349).
24. Serveur d'activation (500) selon la revendication 23, caractérisé en ce qu'il comporte en outre des moyens (550) d'obtention de ladite clef de transport (349) et d'un numéro d'identification personnel de déblocage (346) à partir d'une base de données de pré-activation (560).
25. Serveur d'activation (500) selon la revendication 23 ou 24, caractérisé en ce que lesdits moyens (550) de calcul sont adaptés à calculer ledit troisième code d'authentification à partir de ladite clef de transport (349).
26. Serveur d'activation (500) selon la revendication 24 ou 25, 5 caractérisé en ce qu'il comporte en outre des moyens (550) d'envoi d'un enregistrement d'authentification (M700), à destination d'un serveur d'authentification (900), ledit enregistrement d'authentification (M700) comportant ladite clef de transport (349) et ledit numéro d'identification personnel de déblocage (346). 10.
27. Serveur de comptes utilisateurs (800), dans un système de paiement à distance (10), caractérisé en ce qu'il comporte :
-des moyens (810) de création et de stockage d'au moins un compte utilisateur (830) associé à un dispositif d'authentification (300) selon l'une quelconque des revendications 1 à 12 ; 15 -des moyens (840) d'envoi d'une requête d'activation (M600), à destination d'un serveur d'activation (500) selon l'une quelconque des revendications 17 à 26 ; et
-des moyens (840) d'envoi d'une deuxième requête d'authentification à destination d'un serveur d'authentification (900). 20
28. Serveur de comptes utilisateurs (800) selon la revendication
27, caractérisé en ce que ledit compte utilisateur comporte :
-un identificateur (522) dudit dispositif d'authentification (300) ; et -au moins une option de paiement (831 , 832) de ladite transaction. 25
29. Serveur d'authentification (900), dans un système de paiement à distance (10), caractérisé en ce qu'il comporte :
-des moyens (910) de réception d'au moins un enregistrement d'authentification (M700) en provenance d'un serveur d'activation (500) selon la revendication 26 ; 30 -des moyens (910) de stockage dudit enregistrement
• d'authentification (M700) ; -des moyens (910) de réception d'une deuxième requête d'authentification en provenance d'un serveur de comptes utilisateurs (800) selon la revendication 27 ou 28 ;
-des moyens (930) d'envoi de ladite première requête d'authentification (M 100), à destination d'un dispositif d'authentification (300) selon l'une quelconque des revendications 1 à 12, sur réception de ladite deuxième requête d'identification;
-des moyens (910) de réception d'un message retour d'authentification (M200), en provenance dudit dispositif d'authentification (300) ; et
-des moyens (930) d'envoi d'un message de confirmation de transaction audit serveur de comptes utilisateurs (800), sur réception dudit message retour d'authentification (M200).
30. Système de paiement à distance (10), caractérisé en ce qu'il comporte un dispositif d'authentification (300) selon l'une quelconque des revendications 1 à 12, un serveur d'activation (500) selon l'une quelconque des revendications 17 à 26, un serveur de comptes utilisateurs (800) selon la revendication 27 ou 28 et un serveur d'authentification (900) selon la revendication 29.
31. Système de paiement à distance (10) selon la revendication
30, caractérisé en ce qu'il utilise une infrastructure d'un réseau (40) de téléphonie mobile.
32. Système de paiement à distance (10) selon la revendication
31 , caractérisé en ce que ledit réseau mobile (40) est un réseau GSM.
33. Système de paiement à distance (10) selon la revendication
32, caractérisé en ce que lesdits messages et lesdites requêtes sont conformes au format SMS du protocole GSM.
34. Procédé d'authentification auprès d'un serveur d'authentification (900) dans un système de paiement à distance (10), ladite authentification étant préalable à une transaction par un utilisateur, ledit procédé étant caractérisé en ce qu'il comporte les étapes suivantes : -réception (E1130) d'une première requête d'authentification (M100), en provenance dudit serveur d'authentification (900);
-vérification (E1150) de la validité de ladite requête d'authentification (M 100); -validation (E1190), par l'utilisateur, de ladite transaction ;
-contrôle (E1170) de l'identité dudit utilisateur ; et
-envoi (E1280) d'un message retour d'authentification (M200), vers ledit serveur d'authentification (900).
35. Procédé d'authentification selon la revendication 34, ladite requête d'authentification (M100) comprenant une description de ladite transaction, un identifiant de ladite transaction et un premier code d'authentification dudit serveur d'authentification (900), ledit procédé étant caractérisé en ce que la validité de ladite requête d'authentification est vérifiée en utilisant ledit premier code d'authentification et une première clef d'authentification (342), au cours de ladite étape de vérification (E1150).
36. Procédé d'authentification selon la revendication 34 ou 35, caractérisé en ce qu'il comporte en outre une étape (E1250) de génération d'un deuxième code d'authentification, ledit deuxième code d'authentification étant inséré dans ledit message retour d'authentification (M240) au cours d'une première étape d'insertion (E1260).
37. Procédé d'authentification selon l'une quelconque des revendications 34 à 36, caractérisé en ce qu'une réponse (322), dépendante de ladite validation de la transaction, est insérée dans ledit message retour d'authentification (M210) au cours d'une deuxième étape d'insertion (E1220).
38. Procédé d'authentification selon l'une quelconque des revendications 34 à 37, caractérisé en ce qu'un numéro d'identification personnel (344) est utilisé au cours de ladite étape de contrôle de l'identité dudit utilisateur (E1170).
39. Procédé d'authentification selon l'une quelconque des revendications 34 à 38, caractérisé en ce qu'il comporte en outre une étape (E1140) de déchiffrement de ladite première requête d'authentification (M100), à partir d'une clef de transport (349). 21
40. Procédé d'authentification selon l'une quelconque des revendications 34 à 39, caractérisé en ce qu'il comporte en outre une étape de chiffrement (E1270) dudit message retour d'authentification (M200), à partir d'une clef de transport (349).
41. Procédé d'authentification selon l'une quelconque des revendications 34 à 40, ladite transaction comportant une opération de paiement, ledit procédé étant caractérisé en ce qu'il comporte en outre une étape (E1200) de sélection d'une option de paiement (324) de ladite transaction, ladite option (324) étant insérée dans ledit message retour d'authentification (champ M220 de M200) au cours d'une étape (E1210) d'insertion d'une option de paiement.
42. Procédé d'authentification selon l'une quelconque des revendications 36 à 41 , caractérisé en ce que ladite étape (E1250) de génération dudit deuxième code d'authentification utilise un compteur de transactions (348), ledit compteur de transactions (348) étant inséré dans ledit message retour d'authentification (M230), au cours d'une étape (E1240) d'insertion d'un compteur de transactions.
43. Procédé d'authentification selon l'une quelconque des revendications 35 à 42, caractérisé en ce qu'il comporte en outre une étape (E1100) de réception d'un message de livraison de clefs (M400), ledit message de livraison de clefs (M400) comportant ladite première clef d'authentification (342).
44. Procédé d'authentification selon la revendication 43, caractérisé en ce que ledit message de livraison de clefs (M400) comporte en outre un numéro d'identification personnel de déblocage (346).
45. Procédé d'authentification selon la revendication 43 ou 44, caractérisé en ce qu'il comporte en outre une étape (E1110) de vérification de la validité dudit message de livraison de clefs (M400), à partir d'un troisième code d'authentification contenu dans ledit message de livraison de clefs (M430).
PCT/FR2002/000626 2001-02-20 2002-02-19 Systeme de paiement electronique a distance WO2002067534A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP02714264A EP1362466A1 (fr) 2001-02-20 2002-02-19 Systeme de paiement electronique a distance
US10/468,476 US20040139013A1 (en) 2001-02-20 2002-02-19 Remote electronic payment system
US12/940,281 US20110047082A1 (en) 2001-02-20 2010-11-05 Remote Electronic Payment System

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0102262A FR2821225B1 (fr) 2001-02-20 2001-02-20 Systeme de paiement electronique a distance
FR01/02262 2001-02-20

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/411,800 Continuation US20090182676A1 (en) 2001-02-20 2009-03-26 Remote Electronic Payment System

Publications (1)

Publication Number Publication Date
WO2002067534A1 true WO2002067534A1 (fr) 2002-08-29

Family

ID=8860211

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2002/000626 WO2002067534A1 (fr) 2001-02-20 2002-02-19 Systeme de paiement electronique a distance

Country Status (4)

Country Link
US (3) US20040139013A1 (fr)
EP (1) EP1362466A1 (fr)
FR (1) FR2821225B1 (fr)
WO (1) WO2002067534A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003049364A1 (fr) * 2001-12-04 2003-06-12 Conceptm Company Limited Systeme et procede pour faciliter les transactions financieres electroniques a l'aide d'un dispositif de telecommunication mobile
AU2002349173B2 (en) * 2001-12-04 2005-04-28 Conceptm Company Limited System and method for facilitating electronic financial transactions using a mobile telecommunication device
EP1547298A1 (fr) * 2002-09-09 2005-06-29 U.S. Encode Corporation Systemes et procedes d'authentification securisee de transactions electroniques
EP1639535A2 (fr) * 2003-06-30 2006-03-29 Selvanathan Narainsamy Systeme de verification de transaction

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI20011680A (fi) * 2001-08-21 2003-02-22 Bookit Oy Ajanvarausmenetelmä ja -järjestelmä
DK1680720T3 (da) * 2003-11-07 2012-05-07 Telecom Italia Spa Fremgangsmåde og system til autentificering af en bruger af et databehandlingssystem
WO2006053191A2 (fr) * 2004-11-10 2006-05-18 Mastercard International Incorporated Procede et systeme permettant d'effectuer une transaction a l'aide d'un code d'autorisation dynamique
US20060258397A1 (en) * 2005-05-10 2006-11-16 Kaplan Mark M Integrated mobile application server and communication gateway
FI20051023L (fi) * 2005-10-11 2007-04-12 Meridea Financial Software Oy Menetelmä, laitteet ja järjestely yhteyden autentikoimiseksi kannettavan laitteen avulla
US8611856B2 (en) * 2005-10-18 2013-12-17 Google Inc. Identifying spurious requests for information
DE102006014350A1 (de) * 2005-11-04 2007-05-10 Siemens Ag Verfahren und Server zum teilnehmerspezifischen Aktivieren eines netzbasierten Mobilitätsmanagements
US20070156517A1 (en) * 2005-12-29 2007-07-05 Mark Kaplan System and method for redemption of a coupon using a mobile cellular telephone
US7657489B2 (en) 2006-01-18 2010-02-02 Mocapay, Inc. Systems and method for secure wireless payment transactions
BRPI0806457A2 (pt) 2007-01-09 2011-09-06 Visa Usa Inc método, telefone móvel, e, sistema
US20080299970A1 (en) * 2007-05-30 2008-12-04 Shoptext, Inc. Consumer Registration Via Mobile Device
US20090063312A1 (en) * 2007-08-28 2009-03-05 Hurst Douglas J Method and System for Processing Secure Wireless Payment Transactions and for Providing a Virtual Terminal for Merchant Processing of Such Transactions
US8589267B2 (en) 2008-01-03 2013-11-19 Mocapay, Inc. System and method for re-distributing and transferring mobile gift cards
US8744940B2 (en) 2008-01-03 2014-06-03 William O. White System and method for distributing mobile compensation and incentives
US8374588B2 (en) * 2008-06-02 2013-02-12 Mocapay, Inc. Method and system for sending marketing messages to mobile-device users from a mobile-commerce platform
US20090307140A1 (en) * 2008-06-06 2009-12-10 Upendra Mardikar Mobile device over-the-air (ota) registration and point-of-sale (pos) payment
IT1398518B1 (it) * 2009-09-25 2013-03-01 Colombo Safe milano
US10255591B2 (en) * 2009-12-18 2019-04-09 Visa International Service Association Payment channel returning limited use proxy dynamic value
US8862767B2 (en) 2011-09-02 2014-10-14 Ebay Inc. Secure elements broker (SEB) for application communication channel selector optimization
US20130060708A1 (en) * 2011-09-06 2013-03-07 Rawllin International Inc. User verification for electronic money transfers
CN103426113A (zh) * 2012-05-25 2013-12-04 动信科技股份有限公司 一种金融讯息处理系统及方法
US20140006276A1 (en) * 2012-06-28 2014-01-02 Bank Of America Corporation Mobile wallet account number differentiation
CN105408924A (zh) * 2013-06-14 2016-03-16 支付点公司 用于通信设备的安全数据输入和显示
US8930274B1 (en) 2013-10-30 2015-01-06 Google Inc. Securing payment transactions with rotating application transaction counters
US10387846B2 (en) 2015-07-10 2019-08-20 Bank Of America Corporation System for affecting appointment calendaring on a mobile device based on dependencies
US10387845B2 (en) 2015-07-10 2019-08-20 Bank Of America Corporation System for facilitating appointment calendaring based on perceived customer requirements
US10740760B2 (en) 2017-05-10 2020-08-11 Sap Se Framework for managing online transactions in internet of things (IoT)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5406628A (en) * 1993-03-04 1995-04-11 Bell Communications Research, Inc. Public key authentication and key agreement for low-cost terminals
US5784463A (en) * 1996-12-04 1998-07-21 V-One Corporation Token distribution, registration, and dynamic configuration of user entitlement for an application level security system and method
EP0862104A2 (fr) * 1997-02-28 1998-09-02 Casio Computer Co., Ltd. Système d'authentification au moyen d'un réseau

Family Cites Families (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE470519B (sv) * 1992-11-09 1994-06-27 Ericsson Telefon Ab L M Anordning för tillhandahållande av tjänster såsom telefonkommunikation datakommunikation, etc omfattande en terminalenhet och en accessenhet
DE69431306T2 (de) * 1993-12-16 2003-05-15 Open Market Inc Datennetzgestütztes zahlungssystem und verfahren zum gebrauch eines derartigen systems
US5434919A (en) * 1994-01-11 1995-07-18 Chaum; David Compact endorsement signature systems
US5668876A (en) * 1994-06-24 1997-09-16 Telefonaktiebolaget Lm Ericsson User authentication method and apparatus
US5999711A (en) * 1994-07-18 1999-12-07 Microsoft Corporation Method and system for providing certificates holding authentication and authorization information for users/machines
US5722067A (en) * 1994-12-23 1998-02-24 Freedom Wireless, Inc. Security cellular telecommunications system
JPH1165439A (ja) * 1996-08-09 1999-03-05 Nippon Telegr & Teleph Corp <Ntt> Ｎ進表現暗号による通信および認証方法、ならびにそれらの装置、およびｎ進表現暗号による通信および認証プログラムを格納した記憶媒体
US6061650A (en) * 1996-09-10 2000-05-09 Nortel Networks Corporation Method and apparatus for transparently providing mobile network functionality
US6175922B1 (en) * 1996-12-04 2001-01-16 Esign, Inc. Electronic transaction systems and methods therefor
US6069957A (en) * 1997-03-07 2000-05-30 Lucent Technologies Inc. Method and apparatus for providing hierarchical key system in restricted-access television system
US6681017B1 (en) * 1997-09-03 2004-01-20 Lucent Technologies Inc. Simplified secure shared key establishment and data delivery protocols for electronic commerce
US6148405A (en) * 1997-11-10 2000-11-14 Phone.Com, Inc. Method and system for secure lightweight transactions in wireless data networks
EP0926637B1 (fr) * 1997-12-26 2005-04-27 Nippon Telegraph and Telephone Corporation Méthode d'implémentation de monnaie électronique pour un émetteur ayant des compteurs de solde de monnaie électronique, équipement émetteur correspondant et support d'enregistrement contenant un programme d'exécution de la méthode
US7089214B2 (en) * 1998-04-27 2006-08-08 Esignx Corporation Method for utilizing a portable electronic authorization device to approve transactions between a user and an electronic transaction system
US6816968B1 (en) * 1998-07-10 2004-11-09 Silverbrook Research Pty Ltd Consumable authentication protocol and system
KR100300629B1 (ko) * 1998-11-07 2001-09-07 윤종용 코드분할다중접속방식 서비스지역에서 심카드를 사용하기 위한시스템 및 방법
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
FI991105A (fi) * 1999-05-14 2000-11-15 Nokia Networks Oy Menetelmä ja digitaalinen matkaviestinjärjestelmä
JP4503143B2 (ja) * 1999-07-14 2010-07-14 パナソニック株式会社 電子チケットシステムとサービスサーバとモバイル端末
FI109445B (fi) * 1999-08-06 2002-07-31 Nokia Corp Menetelmä käyttäjän tunnistetietojen välitämiseksi langattomaan viestimeen
US7636696B1 (en) * 1999-11-19 2009-12-22 Megasoft Consultants, Inc. System, method, and computer program product for maintaining consumer privacy and security in electronic commerce transactions
JP2002247029A (ja) * 2000-02-02 2002-08-30 Sony Corp 認証装置、認証システムおよびその方法、処理装置、通信装置、通信制御装置、通信システムおよびその方法、情報記録方法およびその装置、情報復元方法およびその装置、その記録媒体
US7685423B1 (en) * 2000-02-15 2010-03-23 Silverbrook Research Pty Ltd Validation protocol and system
US20010037254A1 (en) * 2000-03-09 2001-11-01 Adi Glikman System and method for assisting a customer in purchasing a commodity using a mobile device
WO2001075549A2 (fr) * 2000-03-30 2001-10-11 Cygent, Inc. Systeme et procede permettant d'etablir des systemes de commerce electronique pour le support du commerce par des services de communication
EP2278538A1 (fr) * 2000-04-24 2011-01-26 Visa International Service Association Service d'authentification d'un payeur en ligne
US7050993B1 (en) * 2000-04-27 2006-05-23 Nokia Corporation Advanced service redirector for personal computer
JP2001313636A (ja) * 2000-04-28 2001-11-09 Sony Corp 認証システム、認証方法、認証装置及びその方法
US20020038287A1 (en) * 2000-08-30 2002-03-28 Jean-Marc Villaret EMV card-based identification, authentication, and access control for remote access
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
JP2002158650A (ja) * 2000-11-21 2002-05-31 Fujitsu Ltd 認証・暗号化処理代行用のサーバ、アクセスカード、プログラム記録媒体及び携帯端末
US20020077993A1 (en) * 2000-12-18 2002-06-20 Nokia Corporation Method and system for conducting wireless payments
FR2818474B1 (fr) * 2000-12-18 2003-02-21 Richard Toffolet Procede de lutte contre le vol de dispositifs "nomades", dispositif et installation correspondante
US20030115452A1 (en) * 2000-12-19 2003-06-19 Ravi Sandhu One time password entry to access multiple network sites
US20030055738A1 (en) * 2001-04-04 2003-03-20 Microcell I5 Inc. Method and system for effecting an electronic transaction
US20030005317A1 (en) * 2001-06-28 2003-01-02 Audebert Yves Louis Gabriel Method and system for generating and verifying a key protection certificate
US7181015B2 (en) * 2001-07-31 2007-02-20 Mcafee, Inc. Method and apparatus for cryptographic key establishment using an identity based symmetric keying technique
US7146009B2 (en) * 2002-02-05 2006-12-05 Surety, Llc Secure electronic messaging system requiring key retrieval for deriving decryption keys
US7054613B2 (en) * 2002-05-03 2006-05-30 Telefonaktiebolaget Lm Ericsson (Publ) SIM card to mobile device interface protection method and system
RS20050149A (en) * 2002-08-16 2007-02-05 Togewa Holding Ag., Method and system for gsm authentication wlan roaming
DE102007000589B9 (de) * 2007-10-29 2010-01-28 Bundesdruckerei Gmbh Verfahren zum Schutz einer Chipkarte gegen unberechtigte Benutzung, Chipkarte und Chipkarten-Terminal
CN101232378B (zh) * 2007-12-29 2010-12-08 西安西电捷通无线网络通信股份有限公司 一种无线多跳网络的认证接入方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5406628A (en) * 1993-03-04 1995-04-11 Bell Communications Research, Inc. Public key authentication and key agreement for low-cost terminals
US5784463A (en) * 1996-12-04 1998-07-21 V-One Corporation Token distribution, registration, and dynamic configuration of user entitlement for an application level security system and method
EP0862104A2 (fr) * 1997-02-28 1998-09-02 Casio Computer Co., Ltd. Système d'authentification au moyen d'un réseau

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BRANDS S: "ELECTRONIC CASH ON THE INTERNET", PROCEEDINGS OF THE SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY, XX, XX, 1995, pages 64 - 84, XP000567597 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003049364A1 (fr) * 2001-12-04 2003-06-12 Conceptm Company Limited Systeme et procede pour faciliter les transactions financieres electroniques a l'aide d'un dispositif de telecommunication mobile
AU2002349173B2 (en) * 2001-12-04 2005-04-28 Conceptm Company Limited System and method for facilitating electronic financial transactions using a mobile telecommunication device
US7379920B2 (en) 2001-12-04 2008-05-27 Gary Leung System and method for facilitating electronic financial transactions using a mobile telecommunication device
EP1547298A1 (fr) * 2002-09-09 2005-06-29 U.S. Encode Corporation Systemes et procedes d'authentification securisee de transactions electroniques
EP1547298B1 (fr) * 2002-09-09 2016-12-14 U.S. Encode Corporation Systemes et procedes d'authentification securisee de transactions electroniques
EP1639535A2 (fr) * 2003-06-30 2006-03-29 Selvanathan Narainsamy Systeme de verification de transaction
EP1639535A4 (fr) * 2003-06-30 2007-01-03 Selvanathan Narainsamy Systeme de verification de transaction

Also Published As

Publication number Publication date
US20090182676A1 (en) 2009-07-16
FR2821225A1 (fr) 2002-08-23
US20110047082A1 (en) 2011-02-24
EP1362466A1 (fr) 2003-11-19
FR2821225B1 (fr) 2005-02-04
US20040139013A1 (en) 2004-07-15

Similar Documents

Publication Publication Date Title
WO2002067534A1 (fr) Systeme de paiement electronique a distance
EP0950303B1 (fr) Procede et systeme pour securiser les prestations de service a distance des organismes financiers
CN108496382A (zh) 用于个人身份认证的安全信息传输系统和方法
EP1008257A2 (fr) Procede et systeme pour securiser les centres de gestion d&#39;appels telephoniques
EP1690240A1 (fr) Procede et systeme de location automatique de bicyclettes
EP1724720B1 (fr) Procédé de paiement de service d&#39;affranchissement dans une machine de traitement de courrier en libre accès
EP1285411A1 (fr) Procede d&#39;approvisionnement d&#39;un compte prepaye
EP2053554A1 (fr) Dispositif electronique portable pour l&#39;echange de valeurs et procédé de mise en oeuvre d&#39;un tel dispositif
EP1008256A1 (fr) Procede et systeme pour securiser les prestations de service diffusees sur un reseau informatique du type internet
EP2369780B1 (fr) Procédé et système de validation d&#39;une transaction, terminal transactionnel et programme correspondants.
WO2016207715A1 (fr) Gestion securisee de jetons électroniques dans un telephone mobile.
WO2007006771A1 (fr) Procede et dispositif d&#39;autorisation de transaction
FR2832829A1 (fr) Procede, systeme et dispositif permettant d&#39;authentifier des donnees transmises et/ou recues par un utilisateur
FR3096481A1 (fr) Procédé et dispositif d&#39;authentification d&#39;un utilisateur.
EP2053553B1 (fr) Procédé et dispositif pour l&#39;échange de valeurs entre entités électroniques portables personnelles
EP1415283B1 (fr) Procede et systeme permettant de garantir formellement un paiement, en mettant en oeuvre un telephone portable
FR2829647A1 (fr) Procede et systeme permettant a un utilisateur d&#39;authentifier une transaction relative a l&#39;acquisition de biens ou de services, au moyen d&#39;un terminal nomade
EP2048632A1 (fr) Procédé de transmission d&#39;un code confidentiel, terminal lecteur de cartes, serveur de gestion et produits programme d&#39;ordinateur correspondants
FR2812424A1 (fr) Procede et systeme pour effectuer des transactions securisees de biens et de services au moyen d&#39;un telephone mobile via un reseau de communication cellulaire
EA018591B1 (ru) Способ осуществления платежных операций пользователем мобильных устройств электронной связи и компьютерная система безналичного расчета для его осуществления
EP4099249A1 (fr) Procédé et dispositif de transmission d&#39;un identifiant d&#39;un utilisateur lors d&#39;un paiement électronique réalisépar l utilisateur
BE1016964A3 (fr) Methode et systeme de paiements electroniques entre porte-monnaies electroniques.
FR2831361A1 (fr) Jeton informatique
FR2860622A1 (fr) Procede et dispositif d&#39;autorisation d&#39;utilisation de ressource
Hansmann et al. Smart Cards and e-business

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

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

AL Designated countries for regional patents

Kind code of ref document: A1

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

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

Ref document number: 2002714264

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2002714264

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWE Wipo information: entry into national phase

Ref document number: 10468476

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP