FR2821225A1 - Systeme de paiement electronique a distance - Google Patents

Systeme de paiement electronique a distance Download PDF

Info

Publication number
FR2821225A1
FR2821225A1 FR0102262A FR0102262A FR2821225A1 FR 2821225 A1 FR2821225 A1 FR 2821225A1 FR 0102262 A FR0102262 A FR 0102262A FR 0102262 A FR0102262 A FR 0102262A FR 2821225 A1 FR2821225 A1 FR 2821225A1
Authority
FR
France
Prior art keywords
authentication
server
key
transaction
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0102262A
Other languages
English (en)
Other versions
FR2821225B1 (fr
Inventor
Christophe Dolique
Eric Barbier
Carles Guillot
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
MOBILEWAY
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 FR0102262A priority Critical patent/FR2821225B1/fr
Priority to EP02714264A priority patent/EP1362466A1/fr
Priority to US10/468,476 priority patent/US20040139013A1/en
Priority to PCT/FR2002/000626 priority patent/WO2002067534A1/fr
Publication of FR2821225A1 publication Critical patent/FR2821225A1/fr
Application granted granted Critical
Publication of FR2821225B1 publication Critical patent/FR2821225B1/fr
Priority to US12/411,800 priority patent/US20090182676A1/en
Priority to US12/940,281 priority patent/US20110047082A1/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)

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

<Desc/Clms Page number 1>
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é portefeuit ! e étectronique ( 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
<Desc/Clms Page number 2>
Figure img00020001

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 oeuvre 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'i ! 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 ;
<Desc/Clms Page number 3>
Figure img00030001

- 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
Figure img00030002

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
Figure img00030003

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,
<Desc/Clms Page number 4>
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.
<Desc/Clms Page number 5>
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 celuici a été bloqué, par exemple après trois saisies d'un numéro d'identification personnel erroné.
Figure img00050001
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 cidessus ; -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.
<Desc/Clms Page number 6>
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 oeuvre un mécanisme d'authentification à
Figure img00060001

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 oeuvre 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 serveur 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é.
<Desc/Clms Page number 7>
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.
<Desc/Clms Page number 8>
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 cidessus ; -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
<Desc/Clms Page number 9>
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 S ! tvi, traditionneiiement 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.
<Desc/Clms Page number 10>
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 ; - ! a 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 ; - ! a 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
<Desc/Clms Page number 11>
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 M100 comporte un deuxième champ M120 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 M130 permet de s'assurer que la requête d'authentification M100 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 M100.
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 Mol 00 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 M100. Ces moyens utilisent en particulier le premier code d'authentification Mol 30 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.
<Desc/Clms Page number 12>
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 oeuvre 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
Figure img00120001

les détails de la transaction contenus dans le champ M 110 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
<Desc/Clms Page number 13>
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 M130 de la requête d'authentification M100.
De retour à la figure 3, les moyens 330 de vérification sont
Figure img00130001

é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 à incrémenter, 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 M100, à 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
<Desc/Clms Page number 14>
Figure img00140001

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, u 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.
<Desc/Clms Page number 15>
Figure img00150001
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 à
Figure img00150002

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
<Desc/Clms Page number 16>
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
Figure img00160001

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.
<Desc/Clms Page number 17>
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 Es 110 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 Es 110 est négatif. Ce test est alors suivi par une étape Ei 120 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 M 100 en provenance d'un serveur d'authentification 900. Cette première requête d'authentification
Figure img00170001

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 Es 150 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 MI 30 de la requête d'authentification reçue à l'étape E1130, ainsi que la première clef d'authentification 342.
<Desc/Clms Page number 18>
Figure img00180001
Lorsque cette requête n'est pas valide, le résultat du test Es 150 est négatif. Ce test est alors suivi par une étape Es 160, au cours de laquelle le champ M210 du message retour d'authentification M200 créé à l'étape Es 135 est initialisé avec un code d'erreur MACNG 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.
Figure img00180002
Lorsque la requête d'authentification M100 est valide, le résultat du test Es 150 est positif. Ce test est alors suivi par un test Es 170 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 Ei 170 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 Es 190. Au cours de cette étape,
Figure img00180003

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
Figure img00180004

contenues dans le champ M110 de la requête d'authentification M100 reçue à l'étape Es 130.
<Desc/Clms Page number 19>
Figure img00190001
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 Ei 135.
L'étape E1210 est suivie par une étape E1220, au cours de 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 Ei 135.
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, 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.
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 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 (45)

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 (mm 00), en provenance dudit serveur d'authentification (900) ; -des moyens (330) de vérification de la validité de ladite requête d'authentification (M100) ; -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 (M100) 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
<Desc/Clms Page number 21>
(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 an 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).
<Desc/Clms Page number 22>
Figure img00220001
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).
<Desc/Clms Page number 23>
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).
<Desc/Clms Page number 24>
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, 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).
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 ; -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).
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.
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 ; -des moyens (910) de stockage dudit enregistrement d'authentification (M700) ;
<Desc/Clms Page number 25>
-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 (M100), à 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 :
<Desc/Clms Page number 26>
- envoi (E1280) d'un message retour d'authentification (M200), vers ledit serveur d'authentification (900).
Figure img00260002
- 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 (M100) ; -validation (E1190), par l'utilisateur, de ladite transaction ; - contrôle (E1170) de l'identité dudit utilisateur ; et
Figure img00260001
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).
<Desc/Clms Page number 27>
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 (es 110) 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).
FR0102262A 2001-02-20 2001-02-20 Systeme de paiement electronique a distance Expired - Lifetime FR2821225B1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
FR0102262A FR2821225B1 (fr) 2001-02-20 2001-02-20 Systeme de paiement electronique a distance
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
PCT/FR2002/000626 WO2002067534A1 (fr) 2001-02-20 2002-02-19 Systeme de paiement electronique a distance
US12/411,800 US20090182676A1 (en) 2001-02-20 2009-03-26 Remote Electronic Payment System
US12/940,281 US20110047082A1 (en) 2001-02-20 2010-11-05 Remote Electronic Payment System

Applications Claiming Priority (1)

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

Publications (2)

Publication Number Publication Date
FR2821225A1 true FR2821225A1 (fr) 2002-08-23
FR2821225B1 FR2821225B1 (fr) 2005-02-04

Family

ID=8860211

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0102262A Expired - Lifetime FR2821225B1 (fr) 2001-02-20 2001-02-20 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 (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1461897A1 (fr) * 2001-12-04 2004-09-29 Conceptm Company Limited Systeme et procede pour faciliter les transactions financieres electroniques a l'aide d'un dispositif de telecommunication mobile
US11004015B2 (en) * 2001-08-21 2021-05-11 Bookit Oy Authentication method and system

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2002349173B2 (en) * 2001-12-04 2005-04-28 Conceptm Company Limited System and method for facilitating electronic financial transactions using a mobile telecommunication device
WO2004023712A1 (fr) * 2002-09-09 2004-03-18 U.S. Encode Corporation Systemes et procedes d'authentification securisee de transactions electroniques
US20070143230A1 (en) * 2003-06-30 2007-06-21 Selvanathan Narainsamy Transaction verification system
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
US8923827B2 (en) 2007-01-09 2014-12-30 Visa U.S.A. Inc. Mobile payment management
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
US8744940B2 (en) 2008-01-03 2014-06-03 William O. White System and method for distributing mobile compensation and incentives
US8589267B2 (en) 2008-01-03 2013-11-19 Mocapay, Inc. System and method for re-distributing and transferring mobile gift cards
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
EP3008678A4 (fr) * 2013-06-14 2016-12-21 Point Of Pay Pty Ltd Saisie et affichage de donnees securises pour dispositif de communication
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
JP3367675B2 (ja) * 1993-12-16 2003-01-14 オープン マーケット インコーポレイテッド オープンネットワーク販売システム及び取引トランザクションのリアルタイムでの承認を行う方法
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
DE69829938T2 (de) * 1997-12-26 2006-02-23 Nippon Telegraph And Telephone Corp. Verfahren zum Einführen von elektronischem Geld für einen Emittent mit elektronischen Saldo-Zählern, entsprechende Vorrichtung und Speicherelement mit gespeichertem Programm zur Durchführung des Verfahrens
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
CA2404014A1 (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
KR101015341B1 (ko) * 2000-04-24 2011-02-16 비자 인터내셔날 써비스 어쏘시에이션 온라인 지불인 인증 서비스
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
WO2002082387A1 (fr) * 2001-04-04 2002-10-17 Microcell I5 Inc. Procede et systeme pour effectuer une transaction electronique
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
AU2002313435B2 (en) * 2002-08-16 2008-02-14 Togewa Holding Ag Method and system for GSM authentication during 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 (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11004015B2 (en) * 2001-08-21 2021-05-11 Bookit Oy Authentication method and system
EP1461897A1 (fr) * 2001-12-04 2004-09-29 Conceptm Company Limited Systeme et procede pour faciliter les transactions financieres electroniques a l'aide d'un dispositif de telecommunication mobile
EP1461897A4 (fr) * 2001-12-04 2007-05-02 Conceptm Company Ltd Systeme et procede pour faciliter les transactions financieres electroniques a l'aide d'un dispositif de telecommunication mobile

Also Published As

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

Similar Documents

Publication Publication Date Title
FR2821225A1 (fr) Systeme de paiement electronique a distance
CN108496382A (zh) 用于个人身份认证的安全信息传输***和方法
EP2008483A1 (fr) Procede de securisation de l&#39;acces a un module de communication de proximite dans un terminal mobile
FR2854303A1 (fr) Procede de securisation d&#39;un terminal mobile et applications de procede, l&#39;execution d&#39;applications necessitant un niveau de securite eleve
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
EP1008257A2 (fr) Procede et systeme pour securiser les centres de gestion d&#39;appels telephoniques
CN101124593A (zh) 用于提供银行服务的电子***
FR3028639A1 (fr) Procede de securisation d&#39;un jeton de paiement
EP1724720B1 (fr) Procédé de paiement de service d&#39;affranchissement dans une machine de traitement de courrier en libre accès
WO2001088861A1 (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
WO2016207715A1 (fr) Gestion securisee de jetons électroniques dans un telephone mobile.
EP2053553B1 (fr) Procédé et dispositif pour l&#39;échange de valeurs entre entités électroniques portables personnelles
EP2369780A1 (fr) Procédé et système de validation d&#39;une transaction, terminal transactionnel et programme correspondants.
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.
EP3095223B1 (fr) Méthode de transmission de données chiffrées, méthode de réception, dispositifs et programmes d&#39;ordinateur correspondants
Cervera Analysis of j2me for developing mobile payment systems
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
FR2932296A1 (fr) Procedes et dispositif pour entites electroniques pour l&#39;echange et l&#39;utilisation de droits
US20240127242A1 (en) Methods and systems for processing customer-initiated payment transactions
EA018591B1 (ru) Способ осуществления платежных операций пользователем мобильных устройств электронной связи и компьютерная система безналичного расчета для его осуществления
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
Wafula Muliaro et al. Enhancing Personal Identification Number (Pin) Mechanism To Provide Non-Repudiation Through Use Of Timestamps In Mobile Payment Systems.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 16

PLFP Fee payment

Year of fee payment: 17

PLFP Fee payment

Year of fee payment: 18

PLFP Fee payment

Year of fee payment: 20