FR2815203A1 - Mandataire de paiement securise internet avec validation par telephone mobile - Google Patents

Mandataire de paiement securise internet avec validation par telephone mobile Download PDF

Info

Publication number
FR2815203A1
FR2815203A1 FR0012706A FR0012706A FR2815203A1 FR 2815203 A1 FR2815203 A1 FR 2815203A1 FR 0012706 A FR0012706 A FR 0012706A FR 0012706 A FR0012706 A FR 0012706A FR 2815203 A1 FR2815203 A1 FR 2815203A1
Authority
FR
France
Prior art keywords
client
validation
customer
payment
card number
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.)
Withdrawn
Application number
FR0012706A
Other languages
English (en)
Inventor
Jacki Montiel
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.)
NTSYS
Original Assignee
NTSYS
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 NTSYS filed Critical NTSYS
Priority to FR0012706A priority Critical patent/FR2815203A1/fr
Priority to PCT/FR2001/003072 priority patent/WO2002029742A1/fr
Priority to AU2001293955A priority patent/AU2001293955A1/en
Publication of FR2815203A1 publication Critical patent/FR2815203A1/fr
Withdrawn 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
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • 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/385—Payment protocols; Details thereof using an alias or single-use codes
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation

Abstract

Serveur Internet agissant comme mandataire de paiement sécurisé, c'est-à-dire relayant des requêtes de paiement vers des systèmes de paiement par carte bancaire demandant la saisie du numéro de carte. Le client s'enregistre une fois sur le serveur en fournissant entre autres son numéro de carte bancaire et en installant un certificat X509 standard sur son terminal, protégé par un code sécurité connu de lui seul. Lors d'un achat depuis son PC initialisé, la requête de paiement est relayée vers le serveur mandataire qui authentifie le client à travers son certificat X509, provoquant la demande du code de sécurité sur le terminal client. Le client utilisant un tel système sécurisé, accepte de ne pas contester d'achat passé par le mandataire. Une requête d'achat passée depuis un PC anonyme (c'est-à-dire non initialisé) au mandataire, est bloquée sur le mandataire jusqu'à ce qu'une procédure de validation sécurisée soit effectuée. Trois procédures de validation sont proposée :1. validation depuis du téléphone mobile WAP2. validation depuis un téléphone mobile normal3 validation depuis du téléphone mobile WAP avec module WIM.

Description

<Desc/Clms Page number 1>
Mandataire de paiement sécurisé Internet avec validation par le téléphone mobile
Problématique ciblée et Etat de l'art
Une des problématiques du paiement sur Internet est de réduire les contestations de transactions passées en ligne, en mettant en place des solutions garantissant la sécurité et la non répudiation par le client.
Par ailleurs, les solutions sécurisées existantes sont essentiellement basées sur un accès par terminal PC. Le développement du marché des mobiles, crée de nouveaux besoins d'achat en ligne multi-terminaux et disposer d'un système cohérent unique permettant de payer des achats en boutique depuis son PC, depuis un PC anonyme, ou depuis son téléphone mobile serait un avantage certain.
Les solutions proposées aujourd'hui en termes de paiement en ligne depuis les PC avec navigateur utilisent l'un des moyens suivants :
1. introduction d'un terminal sécurisé auxiliaire disposant d'un lecteur de carte bancaire (système du type de celui proposé par la société CyberCOMM),
2. utilisation de certificats électroniques, comme SET
3. transmission du numéro de carte en ligne sur une liaison chiffrée (ex : en utilisant un protocole comme
SSL exploitant de la cryptographie publique du type Diffie-Helmann)
La première approche nécessite la mise en place d'un terminal spécifique (écran, clavier, processeur) chez le client utilisant la carte bancaire à puce comme les terminaux d'achat classiques. Ce moyen est considéré comme non répudiable.
La deuxième approche est basée sur des certificats non standards et n'est pas strictement non répudiable car basé sur du logiciel installé sur des postes très ouverts comme les PC des clients.
La troisième approche est la plus utilisée aujourd'hui car ne nécessitant aucune installation de la part du client, mais c'est elle qui déclenche le plus de fraudes parce que le numéro de carte est transmis sans authentification du client. Le fait de disposer d'un numéro de carte bancaire (information semi-confidentielle) suffit pour passer des ordres au nom d'une personne. Un générateur de numéro cohérents de cartes bancaires peut être utilisé à cet effet.
Les solutions de paiement sécurisé par carte bancaire sur Internet s'appuyant sur la troisième approche, mettent en oeuvre aujourd'hui des intermédiaires de paiement sécurisé par carte (notés IPSC). Un IPSC assure l'interface entre l'Internet et un réseau de cartes bancaire.
La communication entre le client et l'intermédiaire bancaire utilise un des principes suivants : le numéro de carte est transmis par le client à chaque échange (figure 1) le numéro de carte est stocké sur le terminal client et c'est un logiciel qui se charge de réaliser la transaction avec le serveur intermédiaire bancaire du vendeur le client est enregistré auprès de l'IPSC, qui conserve son numéro de carte et qui interroge le réseau cartes bancaires à chaque transaction.
Pour ce qui est du paiement par les mobiles les solutions proposées restent limitées à la gestion du système d'information de l'opérateur de mobile.
Définitions
On entend par faiblement non répudiable, un dispositif transactionnel qui en utilisation normale utilise des informations connues du seul client pour signer la transaction et ne pouvant être transmises vers un hôte extérieur que si le client réalise une opération non autorisée, pouvant créer un trou de sécurité comme la mise en place d'un espion dans son système de signature électronique.
Un système faiblement non répudiable, si le client s'engage à ne pas opérer certaines opérations et en accepte les règles contractuellement, devient non répudiable par le client.
<Desc/Clms Page number 2>
Objectif du dispositif L'objectif principal du dispositif est d'apporter une amélioration aux solutions de type transmission du numéro de carte systématique, permettant de limiter les risques de fraude à une fraction négligeable des transactions en introduisant la qualité de"non répudiation faible". Le deuxième objectif est de permettre des transactions unifiées
Web/téléphone mobile.
Description du dispositif
Le dispositif proposé utilise un serveur Internet (8/2) agissant comme mandataire de paiement orienté client et intervenant en intermédiaire dans les échanges entre des systèmes IPSC (6/2) et le terminal client (7/2). Le serveur mandataire peut également effectuer des demandes d'autorisation vers des systèmes de paiement autres. Ce dispositif utilise un mécanisme de signature faiblement non répudiable pour authentifier les requêtes de paiement en provenance des clients. Son originalité est qu'il s'appuie sur des accès multi-terminaux. On distinguera 4 types de terminaux : le PC fixe (étant supposé à domicile) le PC occasionnel, dit PC anonyme (ex : borne multimédia publique) - le téléphone mobile simple te téléphone mobile de type WAP, avec ou sans module WIM.
Lorsque la prise de commande est faite sur un terminal anonyme, le serveur mandataire de paiement requiert une validation par un terminal téléphone mobile.
Dans l'utilisation de base, c'est-à-dire depuis un PC fixe personnel, le client installe un certificat standard délivré par le mandataire de paiement à l'inscription comprenant entre autres une clé privée à importer dans le navigateur du PC. Lors de l'importation, le client choisit : un code personnel appelé code de sécurité (CODES) qui protège l'usage de son certificat un code de validation (CODE~V) qui sera utilisé pour valider les transactions.
Le bouton achat d'un transaction en ligne comprend en paramètres signés par le site vendeur : le contenu de la transaction, le prix, le code vendeur et consiste en un lien vers une demande de paiement vers le serveur mandataire.
L'action sur ce bouton déclenche une liaison SSL entre le poste client et le mandataire de paiement et le passage des paramètres précédents. Le passage en mode SSL provoque l'accès au certificat client et donc une demande d'entrée du code de sécurité pour son déverrouillage local. Si le code est correct la liaison est établie et le serveur mandataire authentifie le client.
Le code vendeur passé en paramètre sert à établir le relais vers le bon IPSC (celui du vendeur) et à vérifier que cet IPSC accepte bien le mode de paiement du client. L'agent de sécurité dispose de plusieurs interfaces pour simuler les échanges d'un client avec les divers IPSC.
Lorsque le client intervient sur une borne anonyme ou chez un commerçant qui saisit en ligne la prise de commande pour son compte, celle-ci a été initialisée pour ne pas accéder au certificat. Dans ce cas les paramètres sont passés simplement en clair vers le serveur mandataire qui bloque le relayage en attente de validation par téléphone mobile et en affichant sur le poste client un numéro de transaction fixé par lui.
Pour chaque achat à valider, ce numéro unique identifie la transaction (vendeur, commande, client) et doit être signé par le serveur mandataire.
Trois cas de validation sont traités :
1. Cas du téléphone simple (figure 3)
2. Cas du téléphone WAP simple (figure 4)
3. Cas du téléphone WAP avec module WIM : authentification forte du client (figure 5) Note :
Le téléphone mobile peut être à la fois considéré comme un terminal de prise de commande et de déclenchement de paiement. La prise de commande se fait comme sur un terminal de type PC.
<Desc/Clms Page number 3>
Figure img00030001

Fonctionnement détaillé
Figure img00030002

Inscription/Installation
L'inscription du client auprès du serveur mandataire (figure 2-b) est réalisée de manière strictement confidentielle : on peut utiliser un enregistrement en ligne avec SSL par exemple ou un enregistrement au guichet.
Une procédure de validation par les exploitants du serveur mandataire, peut-être demandée. Elle doit assurer que les informations relevées à l'inscription sont valides.
Si le client a demandé un enregistrement pour PC fixe, le serveur mandataire produit un certificat électronique à base de clés publiques de type X509 émis avec sa clé privée au client par messagerie (10/2). Le certificat est encapsulé dans un format qui déclenche l'auto-installation sur le PC client. A l'installation du certificat, le client est invité à définir son code de protection des clés CODE S, connu de lui seul et utilisé localement.
Si le client a demandé la validation par mobile, il fournit son numéro de mobile et choisit un autre code de sécurité, appelé code de validation CODEV connu de lui seul et du serveur mandataire. Les données fournies par le client et conservées sur le serveur mandataire sont : l'identité (nom, prénom) son numéro de carte l'adresse de livraison habituelle - optionnellement : numéro de GSM - le CODEV.
Validation de l'identité client
Suivant la rigueur de la procédure souhaitée, il peut y avoir validation manuelle ou automatique, ou simplement aucune validation (acceptation de toutes les inscriptions) sauf des contrôles de non ré-inscription. En particulier des contrôles de réutilisation sur les messages électroniques et numéro de carte permettent de réduire les effets de ré-inscription.
Transactions
Depuis son PC initialisé
Les achats sont réalisés par un simple hyperlien vers le serveur mandataire par le protocole HTTP, les données de la transaction étant passées en paramètres. Ces données sont signées par le vendeur pour garantir l'intégrité vis-à-vis du vendeur.
La requête de paiement reçue au serveur mandataire permet d'authentifier le client de manière certaine, car la requête en mode SSL provient d'un PC fixe avec certificat. Dans ce cas, la requête est automatiquement validée et immédiatement relayée.
Depuis un PC anonyme
Si la requête est émise depuis un PC anonyme, le relayage est bloqué sur le serveur mandataire en attente de validation par le canal mobile (l'agent n'a pas authentifié de client). Le serveur mandataire demande l'identité du client et émet un numéro de transaction unique signé par lui pour la validation qui s'opère selon un des 3 modes autorisés.
Validation
1. Validation par téléphone
Le client appelle un numéro fixe, qui le met en communication avec un serveur vocal interactif ; il est invité à entrer le numéro unique de transaction, affiché sur l'écran de prise de commande ; le serveur restitue par synthèse vocale le descriptif de la commande ; si celui-ci est correct, le client entre son code de validation CODEV.
La passerelle envoie une requête de paiement chiffrée et signée par elle contenant : l'identificateur de transaction et le CODEZ introduit.
2. Validation WAP simple :
Dans ce cas le client établit une connexion WAP/SSL vers le service validation du serveur mandataire de paiement ; le client s'identifie par son nom et prénom puis entre son code de validation CODEV
<Desc/Clms Page number 4>
3. Validation WAP avec module WIM ("WAP Identity Module") Ce cas est identique sur le principe au cas 2, sauf que le terminal WAP dispose d'une capacité de signature électronique garantissant l'authentification du client ; dans ce cas, le CODE V est signé par le module WIM avec les paramètres de la transaction.
Note : Dans les cas 2 et 3 (validation WAP), la passerelle peut utiliser une méthode de mémorisation de l'identité client par Cookie. Le Cookie est un enregistrement en clair ASCII comprenant le nom, prénom du client signé par le serveur mandataire.
Exemple d'implémentation
Ce dispositif a été implémenté sur un serveur sous système Linux avec un pare-feu frontal sous Linux, et un IPSC opérationnel. Le système utilise HTTPS pour les échange SSL entre le PC client et l'agent de sécurité.
La validation par mobile a été réalisée par un terminal WAP, selon le mode d'accès simple.
L'authentification depuis le téléphone mobile s'opère par nom prénom, puis introduction du code de sécurité passé en session SSL.

Claims (3)

Revendications
1. Dispositif de mandatement pour les paiements sécurisés en ligne sur Internet sur des boutiques qui utilisent le chiffrement SSL pour la transmission du numéro de carte sans authentification du client vers un serveur d'autorisation bancaire, caractérisé en ce qu'il - comprend un moyen d'inscription des clients permettant de transmettre au mandataire le numéro de carte une seule fois à l'inscription, et ceci de manière sécurisée par liaison SSL - s'interpose au cours d'une transaction d'achat dans les échanges entre le terminal client et le serveur d'interrogation du réseau cartes bancaires de la boutique, d'une part en identifiant et authentifiant le client grâce à un mécanisme propre de signature électronique, et d'autre part en transmettant le numéro de carte client, mémorisé à l'inscription client, vers l'intermédiaire bancaire par la liaison SSL habituelle, sans authentification du mandataire de la part de l'intermédiaire bancaire.
2. Dispositif de mandatement de paiement selon les revendications 1, caractérisé par le fait qu'il utilise pour chaque client un certificat X509 standard généré sur le serveur mandataire à l'inscription client et transmis par messagerie avec la clé privée associée pour être importé dans le navigateur client, puis utilisé ensuite pour authentifier les clients dans les liaisons HTTP dans les transactions de paiement.
3. Dispositif de mandatement de paiement selon les revendications 1, caractérisé par le couplage possible à un dispositif auxiliaire permettant la validation par le téléphone mobile simple ou WAP, exploitant l'authentification du client par ce système auxiliaire et l'usage d'un code de validation connu seulement du client et du serveur mandataire.
FR0012706A 2000-10-05 2000-10-05 Mandataire de paiement securise internet avec validation par telephone mobile Withdrawn FR2815203A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR0012706A FR2815203A1 (fr) 2000-10-05 2000-10-05 Mandataire de paiement securise internet avec validation par telephone mobile
PCT/FR2001/003072 WO2002029742A1 (fr) 2000-10-05 2001-10-05 Mandataire de paiement securise internet avec validation par telephone mobile
AU2001293955A AU2001293955A1 (en) 2000-10-05 2001-10-05 Secure internet paying agent with mobile telephone validation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0012706A FR2815203A1 (fr) 2000-10-05 2000-10-05 Mandataire de paiement securise internet avec validation par telephone mobile

Publications (1)

Publication Number Publication Date
FR2815203A1 true FR2815203A1 (fr) 2002-04-12

Family

ID=8855016

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0012706A Withdrawn FR2815203A1 (fr) 2000-10-05 2000-10-05 Mandataire de paiement securise internet avec validation par telephone mobile

Country Status (3)

Country Link
AU (1) AU2001293955A1 (fr)
FR (1) FR2815203A1 (fr)
WO (1) WO2002029742A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007121631A1 (fr) * 2006-04-24 2007-11-01 Beijing E-Hengxin Authentication Science & Technology Co. Ltd. Système et procédé de certification bancaire électronique sécurisée

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2869176B1 (fr) * 2004-04-16 2006-07-21 Sagem Procede de verification dans un terminal radio de l'authenticite de certificats numeriques et systeme d'authentification
KR100606748B1 (ko) * 2005-05-27 2006-08-01 엘지전자 주식회사 메시지 인증을 위한 방법과, 그를 위한 단말기 및 시스템
CN101938520B (zh) * 2010-09-07 2015-01-28 中兴通讯股份有限公司 一种基于移动终端签名的远程支付系统及方法
WO2014146286A1 (fr) * 2013-03-22 2014-09-25 Wong Hoiling Système et procédé de paiement sécurisé pour une carte bancaire à l'aide d'une communication en temps réel
CN103368978B (zh) * 2013-08-02 2016-06-08 公安部第三研究所 实现智能移动终端应用漏洞和通信安全检测的方法
CN105376059B (zh) * 2014-08-15 2019-04-02 中国电信股份有限公司 基于电子钥匙进行应用签名的方法和系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999014711A2 (fr) * 1997-09-17 1999-03-25 Andrasev Akos Procede de controle de l'utilisation legitime d'une carte de debit ou d'un moyen similaire donnant droit a disposer d'un compte bancaire
US6014650A (en) * 1997-08-19 2000-01-11 Zampese; David Purchase management system and method
US6026166A (en) * 1997-10-20 2000-02-15 Cryptoworx Corporation Digitally certifying a user identity and a computer system in combination
EP1028401A2 (fr) * 1999-02-12 2000-08-16 Citibank, N.A. Méthode et système pour exécuter une transaction avec cartes bancaires

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6014650A (en) * 1997-08-19 2000-01-11 Zampese; David Purchase management system and method
WO1999014711A2 (fr) * 1997-09-17 1999-03-25 Andrasev Akos Procede de controle de l'utilisation legitime d'une carte de debit ou d'un moyen similaire donnant droit a disposer d'un compte bancaire
US6026166A (en) * 1997-10-20 2000-02-15 Cryptoworx Corporation Digitally certifying a user identity and a computer system in combination
EP1028401A2 (fr) * 1999-02-12 2000-08-16 Citibank, N.A. Méthode et système pour exécuter une transaction avec cartes bancaires

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
VAN THANH D: "Security issues in mobile ecommerce", DATABASE & EXPERT SYSTEMS APPLICATIONS, DEXA,WIEN,AT, 4 September 2000 (2000-09-04), pages 412 - 425, XP002158270 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007121631A1 (fr) * 2006-04-24 2007-11-01 Beijing E-Hengxin Authentication Science & Technology Co. Ltd. Système et procédé de certification bancaire électronique sécurisée

Also Published As

Publication number Publication date
AU2001293955A1 (en) 2002-04-15
WO2002029742A1 (fr) 2002-04-11

Similar Documents

Publication Publication Date Title
EP1153376B1 (fr) Procede de telepaiement et systeme pour la mise en oeuvre de ce procede
US7337229B2 (en) Method and apparatus for authorizing internet transactions using the public land mobile network (PLMN)
JP5216594B2 (ja) 無線インターネットでのサービスサーバーの認証方法及びこれを用いた決済方法
EP2139218A1 (fr) Procédé et système pour gérer une décision d&#39;achat effectuée par un acheteur au moyen d&#39;un radiotéléphone mobile
FR2820853A1 (fr) Procede et systeme de telepaiement
WO2006056669A1 (fr) Procede de securisation d&#39;un terminal de telecommunication connecte a un module d&#39;identification d&#39;un utilisateur du terminal
FR2823400A1 (fr) Dispositif securise d&#39;echange de donnees
FR2809260A1 (fr) Procede d&#39;approvisionnement d&#39;un compte prepaye
FR2815203A1 (fr) Mandataire de paiement securise internet avec validation par telephone mobile
WO2001041093A1 (fr) Systeme et procede permettant de realiser une transaction financiere
EP1323140B1 (fr) Procede pour fournir des donnees d&#39;identification d&#39;une carte de paiement a un usager
KR20020010160A (ko) 무선 전자 상거래 지불 서비스 시스템 및 방법
EP1354288B1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
EP1490851A1 (fr) Procede et systeme de securisation d un paiement par carte d e credit
WO2004017269A1 (fr) Procede et systeme de securisation de transmission d&#39;informations sur des reseaux de telecommunication
FR2850772A1 (fr) Procede et dispositif de securisation de transactions electroniques effectuees sur un terminal non securise
FR2828966A1 (fr) Procede pour communiquer de facon securisee des donnees d&#39;identification d&#39;une carte de paiement
WO2021028639A1 (fr) Procede de transmission d&#39;une information numerique
FR2818778A1 (fr) Procede et systeme de paiement, et equipements de telecommunications mis en oeuvre dans ce systeme
WO2012022856A1 (fr) Procédé d&#39;authentification d&#39; un utilisateur du réseau internet
CA2204547A1 (fr) Methode permettant de proteger de bout en bout les transactions de services de paiement et de transfert electronique de fonds sur tout reseau non protege et non fiable
FR2850813A1 (fr) Dispositif de securisation de transactions electroniques effectuees sur un terminal non securise
FR2790122A1 (fr) Terminal telematique de cartes de paiement par emulation-clavier
FR2807593A1 (fr) Procede de paiement securise a distance faisant intervenir une collaboration entre banques
KR20090081744A (ko) 가맹점 온라인 계좌 연동처리 방법과 이를 위한 기록매체

Legal Events

Date Code Title Description
ST Notification of lapse
RN Application for restoration
FC Decision of inpi director general to approve request for restoration
ST Notification of lapse