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

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

Info

Publication number
FR2827448A1
FR2827448A1 FR0109312A FR0109312A FR2827448A1 FR 2827448 A1 FR2827448 A1 FR 2827448A1 FR 0109312 A FR0109312 A FR 0109312A FR 0109312 A FR0109312 A FR 0109312A FR 2827448 A1 FR2827448 A1 FR 2827448A1
Authority
FR
France
Prior art keywords
operator
certificate
electronic payment
bank
network
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
FR0109312A
Other languages
English (en)
Other versions
FR2827448B1 (fr
Inventor
Christophe Cornillon
Brigitte Vermelle
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Gemplus SA
Original Assignee
Gemplus Card International SA
Gemplus SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gemplus Card International SA, Gemplus SA filed Critical Gemplus Card International SA
Priority to FR0109312A priority Critical patent/FR2827448B1/fr
Priority to EP02764977A priority patent/EP1412925A1/fr
Priority to CN200910152118A priority patent/CN101655951A/zh
Priority to CNA028178777A priority patent/CN1554078A/zh
Priority to PCT/FR2002/002452 priority patent/WO2003007251A1/fr
Publication of FR2827448A1 publication Critical patent/FR2827448A1/fr
Application granted granted Critical
Publication of FR2827448B1 publication Critical patent/FR2827448B1/fr
Priority to US12/558,937 priority patent/US8136722B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4093—Monitoring of device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption

Abstract

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

Description

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

Claims (11)

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

Priority Applications (6)

Application Number Priority Date Filing Date Title
FR0109312A FR2827448B1 (fr) 2001-07-12 2001-07-12 Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre
EP02764977A EP1412925A1 (fr) 2001-07-12 2002-07-11 Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre
CN200910152118A CN101655951A (zh) 2001-07-12 2002-07-11 特别利用移动电话的电子商务的支付担保方法及实施该方法的系统
CNA028178777A CN1554078A (zh) 2001-07-12 2002-07-11 特别利用移动电话的电子商务的支付担保方法及实施该方法的系统
PCT/FR2002/002452 WO2003007251A1 (fr) 2001-07-12 2002-07-11 Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre
US12/558,937 US8136722B2 (en) 2001-07-12 2009-09-14 Method guaranteeing payment for electronic commerce in particularly by mobile telephone and a system implementing it

Applications Claiming Priority (1)

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

Publications (2)

Publication Number Publication Date
FR2827448A1 true FR2827448A1 (fr) 2003-01-17
FR2827448B1 FR2827448B1 (fr) 2003-12-19

Family

ID=8865442

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0109312A Expired - Fee Related FR2827448B1 (fr) 2001-07-12 2001-07-12 Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre

Country Status (5)

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

Families Citing this family (5)

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

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0696021A2 (fr) * 1994-07-29 1996-02-07 Giesecke & Devrient GmbH Méthode pour déterminer la valeur monétaire actuelle dans un support de données et système pour la mise en oeuvre de cette méthode
EP0818763A1 (fr) * 1996-07-11 1998-01-14 France Telecom Procédé de contrÔle de transactions sécurisées independantes utilisant un dispositif physique unique
WO1998037663A1 (fr) * 1997-02-19 1998-08-27 Telefonaktiebolaget Lm Ericsson Procede de verification d'autorisation
WO1998052151A1 (fr) * 1997-05-15 1998-11-19 Access Security Sweden Ab Transaction electronique
FR2779896A1 (fr) * 1998-06-15 1999-12-17 Sfr Sa PROCEDE POUR PAYER A DISTANCE, AU MOYEN D'UN RADIOTELEPHONIQUE MOBILE, l'ACQUISITION D'UN BIEN ET/OU D'UN SERVICE ET SYSTEME ET RADIOTELEPHONE MOBILE CORRESPONDANTS
FR2779895A1 (fr) * 1998-06-15 1999-12-17 Sfr Sa Procede et systeme pour payer a distance au moyen d'un radiotelephone mobile l'acquisition d'un bien et/ou d'un service
WO2000031699A1 (fr) * 1998-11-22 2000-06-02 Easy Charge Cellular (Pty) Limited Procede et dispositif pour la conduite de transactions electroniques
US6145079A (en) * 1998-03-06 2000-11-07 Deloitte & Touche Usa Llp Secure electronic transactions using a trusted intermediary to perform electronic services

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6285991B1 (en) * 1996-12-13 2001-09-04 Visa International Service Association Secure interactive electronic account statement delivery system
WO1999019846A2 (fr) * 1997-10-14 1999-04-22 Visa International Service Association Personnalisation de cartes a puce
US6092202A (en) * 1998-05-22 2000-07-18 N*Able Technologies, Inc. Method and system for secure transactions in a computer system
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
US6463534B1 (en) * 1999-03-26 2002-10-08 Motorola, Inc. Secure wireless electronic-commerce system with wireless network domain
US6694025B1 (en) * 1999-06-02 2004-02-17 Koninklijke Philips Electronics N.V. Method and apparatus for secure distribution of public/private key pairs
US6377810B1 (en) * 1999-06-11 2002-04-23 Motorola, Inc. Method of operation of mobile wireless communication system with location information
JP2001344537A (ja) * 2000-05-31 2001-12-14 Ntt Docomo Inc 電子バリューシステム、通信端末及びサーバ
US20020044662A1 (en) * 2000-08-22 2002-04-18 Jonathan Sowler Service message management system and method
US20020026578A1 (en) * 2000-08-22 2002-02-28 International Business Machines Corporation Secure usage of digital certificates and related keys on a security token
US6836765B1 (en) * 2000-08-30 2004-12-28 Lester Sussman System and method for secure and address verifiable electronic commerce transactions
US7107248B1 (en) * 2000-09-11 2006-09-12 Nokia Corporation System and method of bootstrapping a temporary public-key infrastructure from a cellular telecommunication authentication and billing infrastructure
US6990471B1 (en) * 2001-08-02 2006-01-24 Oracle International Corp. Method and apparatus for secure electronic commerce
GB2385955A (en) * 2002-02-28 2003-09-03 Ibm Key certification using certificate chains

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0696021A2 (fr) * 1994-07-29 1996-02-07 Giesecke & Devrient GmbH Méthode pour déterminer la valeur monétaire actuelle dans un support de données et système pour la mise en oeuvre de cette méthode
EP0818763A1 (fr) * 1996-07-11 1998-01-14 France Telecom Procédé de contrÔle de transactions sécurisées independantes utilisant un dispositif physique unique
WO1998037663A1 (fr) * 1997-02-19 1998-08-27 Telefonaktiebolaget Lm Ericsson Procede de verification d'autorisation
WO1998052151A1 (fr) * 1997-05-15 1998-11-19 Access Security Sweden Ab Transaction electronique
US6145079A (en) * 1998-03-06 2000-11-07 Deloitte & Touche Usa Llp Secure electronic transactions using a trusted intermediary to perform electronic services
FR2779896A1 (fr) * 1998-06-15 1999-12-17 Sfr Sa PROCEDE POUR PAYER A DISTANCE, AU MOYEN D'UN RADIOTELEPHONIQUE MOBILE, l'ACQUISITION D'UN BIEN ET/OU D'UN SERVICE ET SYSTEME ET RADIOTELEPHONE MOBILE CORRESPONDANTS
FR2779895A1 (fr) * 1998-06-15 1999-12-17 Sfr Sa Procede et systeme pour payer a distance au moyen d'un radiotelephone mobile l'acquisition d'un bien et/ou d'un service
WO2000031699A1 (fr) * 1998-11-22 2000-06-02 Easy Charge Cellular (Pty) Limited Procede et dispositif pour la conduite de transactions electroniques

Also Published As

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

Similar Documents

Publication Publication Date Title
US8417633B1 (en) Enabling improved protection of consumer information in electronic transactions
US8977567B2 (en) Recordation of electronic payment transaction information
EP1014317B1 (fr) Procédé de paiement sécurisé
EP1899950B1 (fr) Procede de securisation d&#39;une transaction avec une carte de paiement et serveur d&#39;activation pour la mise en oeuvre de ce procede
US20090307778A1 (en) Mobile User Identify And Risk/Fraud Model Service
US9552576B2 (en) Networked authentication systems and methods
US20080162318A1 (en) Method of securely transferring funds via a mobile internet enabled device
US20070055635A1 (en) Method and apparatus for performing mobile transactions
US20110238579A1 (en) System and device for facilitating a secure transaction with a validated token
CA2584769A1 (fr) Procedes et systemes permettant d&#39;effectuer des operations de credit au moyen d&#39;un dispositif sans fil
JP2005004764A (ja) 移動ユーザ端末を有する顧客による口座からの支払い方法、および顧客認証網
Hsieh E-commerce payment systems: critical issues and management strategies
EP2579199A1 (fr) Procédé de paiement d&#39;un produit ou d&#39;un service sur un site marchand par l&#39;intermédiaire d&#39;une connexion Internet et terminal correspondant
FR2922669A1 (fr) Dispositif electronique portable pour l&#39;echange de valeurs et procede de mise en oeuvre d&#39;un tel dispositif
FR2923635A1 (fr) Systeme pour des transactions de commerce electronique, dispositif electronique portatif, reseau de communication, produit programme d&#39;ordinateur et methode correspondants.
US8136722B2 (en) Method guaranteeing payment for electronic commerce in particularly by mobile telephone and a system implementing it
US20040039709A1 (en) Method of payment
EP1323140B1 (fr) Procede pour fournir des donnees d&#39;identification d&#39;une carte de paiement a un usager
US20100332349A1 (en) Systems and methods for fund transfers using prepaid calling cards and telephones
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d&#39;ordinateur correspondant
EP1978479A1 (fr) Cryptogramme dynamique
EP1428183A2 (fr) Procede et systeme permettant de valider, en mettant en oeuvre un objet portable d&#39;un utilisateur, une requete aupres d&#39;une entite
EP2724305B1 (fr) Procede de transaction dematerialisee
WO2001015095A1 (fr) Methode et systeme d&#39;achat et de paiement
KR20070011951A (ko) 상품권 운용방법 및 시스템과 이를 위한 상품권운용장치와, 무선 단말 장치와, 기록매체 및 정보 저장매체

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20100331