FR2827724A1 - Procede d'inscription d'un acheteur aupres d'un serveur de paiement et procede de telepaiement fonde sur cette inscription - Google Patents
Procede d'inscription d'un acheteur aupres d'un serveur de paiement et procede de telepaiement fonde sur cette inscription Download PDFInfo
- Publication number
- FR2827724A1 FR2827724A1 FR0109639A FR0109639A FR2827724A1 FR 2827724 A1 FR2827724 A1 FR 2827724A1 FR 0109639 A FR0109639 A FR 0109639A FR 0109639 A FR0109639 A FR 0109639A FR 2827724 A1 FR2827724 A1 FR 2827724A1
- Authority
- FR
- France
- Prior art keywords
- buyer
- payment
- server
- message
- secure module
- 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
Links
Classifications
-
- 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/305—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wired telephone networks
-
- 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
- G06Q20/4014—Identity check for transactions
Abstract
L'invention concerne un procédé d'inscription au cours duquel un acheteur (A) adresse un message confidentiel à un serveur (T) par l'intermédiaire d'un premier équipement de télécommunications (El), ledit message comprenant des informations relatives au module sécurisé (1) et au numéro d'abonné téléphonique (N) de l'acheteur. Le serveur vérifie les informations contenues dans ledit message, affecte au numéro (N), dans le cas où le résultat de cette vérification est positif, les informations relatives audit module, et adresse à l'acheteur une clé (K) destinée à être authentifiée par le serveur (T) lors d'un paiement effectué par l'acheteur. Au cours du procédé de télépaiement fondé sur cette inscription, l'acheteur adresse à un vendeur (V), par l'intermédiaire d'un troisième équipement de télécommunications (E3), soit ledit numéro (N), soit les informations relatives audit module (1), soit des informations relatives à un pseudonyme dudit module. Le vendeur adresse au serveur, d'une part, des informations relatives à la transaction et, d'autre part, soit ledit numéro (N), soit les informations relatives audit module, soit les informations relatives audit pseudonyme. Le serveur compose alors ledit numéro (N) et adresse à l'acheteur lesdites données relatives à la transaction, ce dernier adressant sa clé en réponse au serveur. Ce dernier vérifie l'exactitude de la clé et, si le résultat de cette vérification s'avère positif, valide le paiement.
Description
<Desc/Clms Page number 1>
La présente invention concerne un procédé d'inscription d'une première entité dite "l'acheteur" auprès d'une seconde entité dite"serveur de paiement".
Plus particulièrement, l'invention concerne un procédé d'inscription dans lequel l'acheteur dispose d'un numéro d'abonné à un réseau téléphonique et d'un module sécurisé.
Le module sécurisé consiste généralement en une carte bancaire remise à l'acheteur par sa banque.
Historiquement, les cartes bancaires sont munies : - d'un visuel intégrant des informations sur le porteur dont le nom, et des informations d'identification de la carte bancaire elle-même (le numéro de la carte bancaire et sa date d'expiration de validité).
- d'une piste magnétique reprenant les informations précédemment décrites ainsi que des informations complémentaires dont le code confidentiel lié à la carte bancaire présent de façon chiffré.
La présente invention concerne également un procédé de télépaiement fondé sur le procédé d'inscription selon l'invention, ledit procédé de télépaiement impliquant une troisième entité dite "le vendeur" disposant d'un second équipement de télécommunications qui est apte à établir une liaison avec le serveur de paiement, le procédé de télépaiement comprenant un échange préliminaire qui est établi entre l'acheteur et le vendeur, en vue de l'aboutissement d'une transaction,
Actuellement, les procédés de télépaiement qui utilisent une telle carte bancaire se déroulent selon les deux alternatives suivantes : - le serveur de paiement utilise des informations contenues dans le visuel pour réaliser le procédé de télépaiement. Ce procédé est qualifié en France de procédure Vente A Distance. Seules les informations numéro de carte bancaire et date d'expiration de validité sont utilisées pour constituer ledit
Actuellement, les procédés de télépaiement qui utilisent une telle carte bancaire se déroulent selon les deux alternatives suivantes : - le serveur de paiement utilise des informations contenues dans le visuel pour réaliser le procédé de télépaiement. Ce procédé est qualifié en France de procédure Vente A Distance. Seules les informations numéro de carte bancaire et date d'expiration de validité sont utilisées pour constituer ledit
<Desc/Clms Page number 2>
procédé. Ce type de procédé est utilisé couramment aujourd'hui sur Internet mais également dans le cadre du commerce à distance (Vente Par Correspondance) ; - le serveur de paiement utilise des informations contenues dans la piste magnétique pour réaliser le procédé de télépaiement. Ce procédé n'existe plus en France dans le cadre du commerce de proximité, sauf dans le cas de traitement des cartes bancaires étrangères ou lors d'une défaillance de la puce (à voir). Il existait, il y a quelques années encore, des automates (notamment pompes à essence) qui utilisaient ce procédé en vérifiant le code confidentiel présenté par le porteur. Dans un tel cas, l'automate était équipé d'un circuit spécialisé pourvu des secrets nécessaires pour réaliser cette vérification. Ce procédé est communément utilisé hors de France.
Un inconvénient majeur des procédés décrits ci-dessus réside dans le fait qu'un acheteur malhonnête peut facilement dupliquer une telle carte bancaire ou récupérer le numéro et la date d'expiration de validité de cette dernière, ou encore utiliser de manière frauduleuse la véritable carte bancaire d'un acheteur.
De ces inconvénients découlent les importants taux de fraude relevés actuellement dans le monde bancaire.
Afin de remédier à cet inconvénient, la communauté bancaire française a décidé l'introduction de la carte bancaire à puce dans le système commerçant français. Cette carte a la capacité : - d'authentifier l'acheteur à chaque paiement par présentation et vérification locale d'un code confidentiel propre à la carte à puce et connu uniquement de l'acheteur, - et, à la suite de quoi, de générer des preuves sur l'acte d'achat à l'aide des secrets personnalisés qu'elle contient.
Le procédé de télépaiement basé sur l'utilisation d'une telle carte bancaire est certes avantageux d'un point de vue confidentialité de l'achat.
Cependant, si les terminaux de traitement de la carte bancaire à puce sont fortement déployés dans le commerce de proximité (cette procédure étant la seule à apporter par contrat la garantie de paiement au vendeur), ce n'est pas le cas dans le cadre du télépaiement.
<Desc/Clms Page number 3>
En effet, pour ce faire, il conviendrait de déployer chez tous les acheteurs impliqués dans un procédé de télépaiement un lecteur de carte bancaire pouvant réaliser dans des conditions de sécurité raisonnables les procédés de télépaiement.
A l'heure actuelle, il existe deux types de terminal intégrant un tel lecteur. Soit il s'agit d'un lecteur branché sur l'ordinateur personnel PC de l'acheteur, lequel ordinateur est connecté au réseau Internet via lequel est effectué le procédé de télépaiement. Soit il s'agit d'un terminal mobile bi-fente connecté à un réseau de télécommunications auquel est abonné l'acheteur et via lequel est effectué le procédé de télépaiement.
Mais il s'avère que le déploiement à grande échelle de terminaux intégrant ce type de lecteurs est difficile à mettre en place, notamment en raison du fait que, d'une part, l'acheteur impliqué dans le procédé de télépaiement ne détient pas forcément ce type de terminal, et que, d'autre part, l'installation d'un tel lecteur chez un acheteur détenant déjà ce type de terminal est coûteuse.
Il existe aujourd'hui des sociétés qui proposent des solutions de façon à sécuriser l'emploi de la carte bancaire sans puce dans le contexte Internet.
Celles-ci sont majoritairement fondées sur la non-circulation du numéro de carte en ligne. C'est le cas notamment : - en général des plates-formes de commerce électronique qui proposent aux acheteurs détenteurs d'une carte bancaire d'inscrire définitivement leur numéro de carte bancaire sur le serveur de ces plates-formes et d'utiliser un pseudonyme, tel que par exemple un code d'identification de l'acheteur qui lui permet d'être identifié par le serveur de paiement lors de sa connexion à ce dernier, ou encore un mot de passe propre à l'acheteur qui est parfois agrémenté d'un questionnaire complémentaire, ledit pseudonyme ne circulant alors plus en ligne ; - des systèmes plus élaborés qui substituent au véritable numéro de carte bancaire de l'acheteur un numéro temporaire parfaitement formé, lequel est collecté auprès d'un centre d'autorisation spécialisé. Ce numéro est utilisé par
<Desc/Clms Page number 4>
l'acheteur lors de son achat auprès d'un vendeur. Du fait qu'il apparaît comme un véritable numéro de carte bancaire, il transite sans difficulté sur le serveur du vendeur. Il remonte ensuite vers un centre d'autorisation dédié qui traite alors la transaction financière associée en substituant au numéro de carte bancaire temporaire le véritable numéro de carte bancaire et en renvoyant la transaction financière vers le véritable centre d'autorisation des transactions financières de la banque de l'acheteur.
Dans tous les cas, les procédés de télépaiement décrits ci-dessus, s'il est vrai qu'il contournent effectivement le problème de la captation en ligne du numéro de carte bancaire et de sa date d'expiration de validité, ne peuvent résoudre le problème de leur obtention frauduleuse par d'autres circuits et de leur utilisation en ligne.
La présente invention a notamment pour but de remédier aux inconvénients précités.
A cet effet, le procédé d'inscription selon l'invention est caractérisé en ce qu'il comprend les étapes suivantes : - l'acheteur adresse un message confidentiel au serveur par l'intermédiaire d'un premier équipement de télécommunications, ledit message comprenant des informations relatives au module sécurisé de l'acheteur et au numéro d'abonné téléphonique de l'acheteur, - le serveur vérifie les informations contenues dans ledit message confidentiel, - le serveur affecte au numéro d'abonné téléphonique de l'acheteur les informations relatives au module sécurisé de l'acheteur, dans le cas où le résultat de cette vérification est positif, - le serveur adresse à l'acheteur un code de paiement (clé) destiné à être authentifié par le serveur lors d'un paiement effectué par l'acheteur.
L'inscription de l'acheteur auprès du serveur de paiement est ainsi sécurisée puisqu'elle est liée aux informations du module sécurisé de l'acheteur.
Dans des modes de réalisation préférés du procédé selon l'invention, on a recours à l'une et/ou à l'autre des dispositions suivantes :
<Desc/Clms Page number 5>
- le code de paiement ou clé est le même pour chaque paiement ; - le code de paiement ou clé varie à chaque paiement ; - lors d'un ième paiement, 1 < i < n, l'acheteur adresse au serveur un ième code de paiement K" ledit code étant un élément d'une série Un = {Ko, Ki, ..., K.,..., Kn-1, Kn}.
- Kn = f (Ko), Kn-1 = f (kan), K, ksi = f (K2), f étant une fonction non inversible et Ko un code de paiement racine fourni par le serveur à l'acheteur ; - Ki = E (Ko), K2 = E (Ki),...., K. = E (KI-1),..., Kn = E (Kn-1), E est un algorithme de chiffrement et Ko un code de paiement racine fourni par le serveur à l'acheteur ; - le premier équipement de télécommunications est une cabine téléphonique publique comprenant un moyen de lecture dudit module sécurisé de l'acheteur ; - le serveur de paiement adresse à l'acheteur, en plus du code de paiement ou clé, des informations relatives à un pseudonyme du module sécurisé de l'acheteur.
Pour ce qui est du procédé de télépaiement basée sur l'inscription selon l'invention, il est caractérisé en ce que à la suite de l'échange préliminaire entre l'acheteur et le vendeur, il comprend au moins les échanges suivants : - l'acheteur adresse au vendeur, par l'intermédiaire d'un troisième équipement de télécommunications, un message comprenant soit le numéro d'abonné téléphonique de l'acheteur, soit des informations relatives au module sécurisé de l'acheteur, soit des informations relatives à un pseudonyme du module sécurisé de l'acheteur, - le vendeur adresse au serveur un message comprenant, d'une part, des informations relatives à la transaction et, d'autre part, soit ledit numéro d'abonné téléphonique, soit les informations relatives au module sécurisé de l'acheteur, soit les informations relatives au pseudonyme du module sécurisé de l'acheteur, - le serveur compose le numéro d'abonné téléphonique de l'acheteur
<Desc/Clms Page number 6>
et lui adresse un message d'informations comprenant lesdites données relatives à la transaction, - l'acheteur adresse en réponse au serveur son code de paiement ou clé, - le serveur vérifie l'exactitude dudit code de paiement ou clé et, si le résultat de cette vérification s'avère positif, valide le paiement.
D'autres caractéristiques et avantages de l'invention apparaîtront au cours de la description suivante d'une de ses formes de réalisation, donnée à titre d'exemple non limitatif, en regard des dessins annexés.
Sur les dessins : - la figure 1 illustre de façon schématique le procédé d'inscription d'un acheteur auprès d'un serveur de paiement, conformément à une première forme de réalisation ; - la figure 2A illustre un schéma d'obtention, par le serveur de paiement de la figure 1, du code de paiement remis à l'acheteur au moment de son inscription, - la figure 2B représente une variante du schéma de la figure 2B, - la figure 3A illustre de façon schématique une première forme de réalisation du procédé de télépaiement basé sur le procédé d'inscription représenté figure 1, - la figure 3B illustre de façon schématique une seconde forme de réalisation du procédé de télépaiement basé sur le procédé d'inscription représenté figure 1, - la figure 3C illustre de façon schématique une troisième forme de réalisation du procédé de télépaiement basé sur le procédé d'inscription représenté figure 1, - la figure 3D illustre de façon schématique une quatrième forme de réalisation du procédé de télépaiement basé sur le procédé d'inscription représenté figure 1.
Sur la figure 1 annexée, la référence numérique 1 désigne un module sécurisé appartenant à un acheteur A qui possède un numéro N d'abonné à
<Desc/Clms Page number 7>
réseau téléphonique fixe ou mobile, la référence alphanumérique E1 désigne un premier équipement de télécommunications, notamment un terminal qui comporte un lecteur 2 apte à lire les informations contenues dans le module sécurisé 1, et la référence alphabétique T désigne un serveur de paiement auprès duquel l'acheteur A doit s'inscrire préalablement à toute étape de télépaiement. De façon connue en tant que telle, le serveur de paiement T est destiné à enregistrer le paiement et à mettre à jour les comptes respectifs de l'acheteur A.
Dans la forme de réalisation représentée, le module sécurisé 1 de l'acheteur A est une carte bancaire à puce à laquelle est affecté un code de paiement confidentiel C, un numéro NC et une date DE d'échéance de validité de ladite carte. L'équipement de télécommunications E1 consiste quant à lui en une cabine téléphonique publique, laquelle présente l'avantage d'être accessible à tout acheteur, et en particulier à ceux qui ne possèdent ni ordinateur personnel, ni terminal mobile bi-fente. Dans ce cas, le serveur de paiement T comporte une liaison de type téléphonique avec l'acheteur A.
A titre de variante, l'équipement de télécommunications E1 consiste en un ordinateur appartenant au vendeur impliqué dans le procédé de télépaiement, ledit ordinateur étant alors muni d'un dispositif de lecture doté de deux fentes respectivement prévues pour recevoir le module sécurisé 1 de l'acheteur A et le module sécurisé du vendeur.
Selon une autre variante, l'équipement de télécommunications E1 consiste en un ordinateur appartenant à l'acheteur A, ledit ordinateur étant connecté à un dispositif de lecture du module sécurisé 1 de l'acheteur A,.
Selon encore une autre variante, l'équipement de télécommunications E1 consiste en un terminal mobile bi-fente.
Le procédé d'inscription de l'acheteur A auprès du serveur de paiement T se déroule de la façon suivante.
1) l'acheteur A compose le numéro de téléphone du serveur de paiement T ;
2) le serveur de paiement T envoie un message vocal ou de données
2) le serveur de paiement T envoie un message vocal ou de données
<Desc/Clms Page number 8>
à l'acheteur A du type :"insérez votre carte bancaire 1 dans le dispositif de lecture 2, tapez votre code confidentiel C et votre numéro de téléphone N" ;
3) l'acheteur A introduit sa carte bancaire 1 dans le dispositif de lecture 2 et saisit sur le clavier du téléphone publique E1 son code confidentiel C et son numéro de téléphone N et, éventuellement, un code confidentiel supplémentaire si sa carte bancaire en est dotée. L'étape de saisie du code confidentiel C est par
exemple effectuée à l'aide d'un algorithme de saisie stocké dans le téléphone public E1 ;
4) le téléphone public E1 vérifie localement le code confidentiel C et si cette vérification s'avère exacte génère une signature électronique d'acheteur à l'aide d'un algorithme et d'une clé présents dans la carte bancaire ;
5) cette signature électronique, le numéro NC de la carte bancaire 1, la date d'échéance DE de validité de cette dernière, de même que le numéro de téléphone N de l'acheteur A, sont remontés vers le serveur de paiement T qui vérifie ou fait vérifier la signature électronique d'acheteur au moyen d'un module de vérification 3 ;
6) si la vérification de cette signature s'avère exacte, le serveur de paiement T affecte le numéro de carte bancaire NC et la date d'échéance de validité DE de la carte bancaire 1 de l'acheteur A au numéro de téléphone N de l'acheteur A et mémorise cette correspondance dans une base de données 4 prévue à cet effet dans le serveur de paiement T ;
7) le serveur de paiement T calcule un code de paiement ou clé K et adresse cette donnée à l'acheteur A, via le téléphone public El, ladite donnée étant éventuellement complétée par un numéro de pseudonyme NCP de la carte bancaire 1 de l'acheteur A, ce numéro étant accompagné d'une date d'échéance de validité DEP dudit pseudonyme.
3) l'acheteur A introduit sa carte bancaire 1 dans le dispositif de lecture 2 et saisit sur le clavier du téléphone publique E1 son code confidentiel C et son numéro de téléphone N et, éventuellement, un code confidentiel supplémentaire si sa carte bancaire en est dotée. L'étape de saisie du code confidentiel C est par
exemple effectuée à l'aide d'un algorithme de saisie stocké dans le téléphone public E1 ;
4) le téléphone public E1 vérifie localement le code confidentiel C et si cette vérification s'avère exacte génère une signature électronique d'acheteur à l'aide d'un algorithme et d'une clé présents dans la carte bancaire ;
5) cette signature électronique, le numéro NC de la carte bancaire 1, la date d'échéance DE de validité de cette dernière, de même que le numéro de téléphone N de l'acheteur A, sont remontés vers le serveur de paiement T qui vérifie ou fait vérifier la signature électronique d'acheteur au moyen d'un module de vérification 3 ;
6) si la vérification de cette signature s'avère exacte, le serveur de paiement T affecte le numéro de carte bancaire NC et la date d'échéance de validité DE de la carte bancaire 1 de l'acheteur A au numéro de téléphone N de l'acheteur A et mémorise cette correspondance dans une base de données 4 prévue à cet effet dans le serveur de paiement T ;
7) le serveur de paiement T calcule un code de paiement ou clé K et adresse cette donnée à l'acheteur A, via le téléphone public El, ladite donnée étant éventuellement complétée par un numéro de pseudonyme NCP de la carte bancaire 1 de l'acheteur A, ce numéro étant accompagné d'une date d'échéance de validité DEP dudit pseudonyme.
De préférence, le numéro de pseudonyme NCP est calculé automatiquement par le serveur de paiement T qui doit, à cet effet, posséder préalablement le nombre BIN (abréviation anglaise de Bank Identification Number) situé en tête du numéro NC de la carte bancaire 1 de l'acheteur A et
<Desc/Clms Page number 9>
calculer correctement une clé appelée "clé de Luhn"qui est en fait le dernier digit du numéro NC de la carte bancaire 1 de l'acheteur A.
Selon une autre variante, le numéro de pseudonyme NCP intègre le numéro de téléphone N de l'acheteur A, à la condition que le serveur de paiement T possède préalablement le nombre BIN et calcule correctement la clé de Luhn.
Selon encore une autre variante, le numéro de pseudonyme NCP intègre un chiffré du numéro de téléphone N de l'acheteur A à la condition que le serveur de paiement T possède préalablement le nombre BIN et calcule correctement la clé de Luhn.
Suite à l'étape 7), la phase d'inscription de l'acheteur A auprès du serveur de paiement T est alors considérée comme terminée.
A l'étape 6), si la vérification ne s'avère pas exacte, le serveur de paiement T adresse au système de gestion des cartes bancaires une notification pour suspicion de fraude de ladite carte bancaire 1. Le serveur de paiement T affecte tout de même le numéro de carte bancaire et la date d'échéance de validité de la carte bancaire de l'acheteur A au numéro de téléphone N de l'acheteur A et mémorise cette correspondance dans ladite base de données avec une indication de suspicion de fraude.
A l'étape 7), le serveur de paiement T a la possibilité d'adresser le code ou la clé K via un équipement de télécommunications autre que le téléphone public E1, notamment un équipement de télécommunications appartenant à l'acheteur A. Le code ou la clé K peut par exemple être adressé sous forme d'un message électronique à l'ordinateur personnel PC de l'acheteur A ou sous forme d'un message court sur le téléphone mobile de ce dernier, etc....
Le code de paiement ou clé K est destiné à être présenté par l'acheteur A lors du procédé de télépaiement basé sur l'inscription décrite cidessus et dont une description détaillée sera donnée dans la suite de la description.
<Desc/Clms Page number 10>
Selon une première forme de réalisation, la clé K est fixe. L'avantage d'une telle disposition réside dans la simplicité de sa mise en oeuvre puisqu'elle ne nécessite aucun équipement particulier, matériel ou logiciel, chez l'acheteur A, lequel a simplement la contrainte de se souvenir de cette clé. Ainsi, lors d'un paiement quelconque suivant l'inscription, l'acheteur A adresse la clé K au serveur de paiement T qui la compare avec celle mémorisée localement lors de la phase d'inscription afin d'accepter ou de refuser la transaction, selon le résultat de cette comparaison.
Selon une seconde forme de réalisation, la clé K est variable à chaque paiement, c'est à dire que lors d'un ième paiement, 1 < i < n, l'acheteur A présente au serveur de paiement T une ième clé Ki générée dans un ordre défini, ladite clé Ki étant un élément d'une série Un = {Ko, Ki,.... K,,..., Kn-i, Kn}.
Cette seconde forme de réalisation présente l'avantage de faire varier continuellement la clé K présenté par l'acheteur A à chaque paiement. Elle nécessite par ailleurs l'implémentation d'un programme de calcul et de traitement de données sur le téléphone de l'acheteur A. De plus, le nombre maximal de paiement est limité à n, ce qui peut être un avantage sécuritaire. Ainsi, lorsque l'acheteur A a épuisé les n+1 clés de la série au bout du nième paiement, il se représente sur un équipement de télécommunications E1 comprenant un lecteur de carte à puce sécurisé pour recréer une nouvelle série Un.
Selon une première variante représentée sur la figure 2A, Kn = f (Ko), Kn-
1 = f (Kn),..... K, = f (KI+1),..., K1 = f (K2), f étant une fonction non inversible et Ko une clé racine fourni par le serveur T à l'acheteur A à l'étape 7) ci-dessus.
1 = f (Kn),..... K, = f (KI+1),..., K1 = f (K2), f étant une fonction non inversible et Ko une clé racine fourni par le serveur T à l'acheteur A à l'étape 7) ci-dessus.
Au cours d'un premier paiement de rang, l'acheteur A saisit la clé racine Ko sur le clavier de son téléphone. Un programme prévu dans le téléphone de l'acheteur A est alors généré pour calculer Kn = f (Ko). L'acheteur A adresse la clé Kn au serveur de paiement T qui calcule f1 (Kn) et compare f1 (Kn) avec la clé Ko mémorisée localement lors de la phase d'inscription afin d'accepter ou de refuser la transaction, selon le résultat de cette comparaison. Il convient de noter qu'à cette étape, la clé Ko peut être oubliée par l'acheteur A étant donné qu'elle ne servira plus par la suite.
<Desc/Clms Page number 11>
Au cours d'un second paiement de rang 2, l'acheteur fait à nouveau appel au programme présent sur son téléphone qui lui fournit alors la clé de rang n-1 Kn-1 = f (Kn). L'acheteur A adresse la clé Kn-1 au serveur de paiement T qui calcule f-1 (Kn-1) et compare f\Kn-i) avec la clé Kn adressée par l'acheteur A lors du paiement de rang 1, ceci afin d'accepter ou de refuser la transaction, selon le résultat de cette comparaison.
Des étapes de paiement similaires à celles décrites ci-dessus sont ainsi itérées jusqu'au paiement de rang n.
Dans le cas où par exemple, au cours d'un paiement de rang i, l'acheteur A adresse au serveur de paiement T la clé Kl-1 à la place de la clé 1\ attendue, il est fait en sorte que le programme de calcul installé chargé dans le serveur tolère des décalages de rang en fonction de paramètres liés au degré de sécurité qu'il s'est fixé.
Selon une seconde variante représentée sur la figure 2B, Ki = E (Ko), K2 = E (K1), ...., K, = E (I\-1),..., Kn = E (kan,), E étant un algorithme de chiffrement implémenté dans le téléphone de l'acheteur A et Ko une clé racine fourni par le serveur T à l'acheteur A à l'étape 7) ci-dessus.
Au cours d'un premier paiement de rang, l'acheteur A saisit la clé racine Ko sur le clavier de son téléphone. L'algorithme est alors généré pour calculer K1 = E (Ko). L'acheteur A adresse la clé K1 au serveur de paiement T qui calcule E-1(K1) et compare E-1 (K1) avec la clé Ko mémorisée localement lors de la phase d'inscription afin d'accepter ou de refuser la transaction, selon le résultat de cette comparaison. Il convient de noter qu'à cette étape, la clé Ko peut être oubliée par l'acheteur A étant donné qu'elle ne servira plus par la suite.
Au cours d'un second paiement de rang 2, l'acheteur A génère à nouveau l'algorithme de chiffrement E présent sur son téléphone qui lui fournit alors la clé de rang 2 K2 = f (Ki). L'acheteur A adresse la clé K2 au serveur de paiement T qui calcule E-1 (K2) et compare E-1(K2) avec la clé K1 adressée par l'acheteur A lors du paiement de rang 1, ceci afin d'accepter ou de refuser la transaction, selon le résultat de cette comparaison.
<Desc/Clms Page number 12>
Des étapes de paiement similaires à celles décrites ci-dessus sont ainsi itérées jusqu'au paiement de rang n.
La phase d'inscription qui vient d'être décrite ci-dessus est éventuellement complétée par une phase d'inscription complémentaire sur un serveur Web (non représenté) connecté au serveur de paiement T.
Au cours de cette phase d'inscription complémentaire, l'acheteur A fournit des informations complémentaires au serveur Web telles que par exemple son adresse de livraison. Une telle information ne peut bien sûr être validée par le serveur Web qu'après présentation, au moyen du téléphone de l'acheteur A, de la clé K adressée à l'étape 7).
Le déroulement d'une telle phase d'inscription complémentaire se déroule de la façon suivante. L'acheteur A se connecte au serveur Web. Le serveur de paiement T compose alors le numéro de téléphone N de l'acheteur A et l'invite à présenter sa clé K ou Ko selon la forme de réalisation mise en oeuvre.
Le serveur Web invite l'acheteur A à poursuivre la saisie des informations complémentaires dans des grilles d'inscription affichées sur une page Web du serveur Web à la seule condition que la clé K ou Ko soit authentifiée par le serveur de paiement T.
On va maintenant décrire, en référence aux figures 3A à 3D, le procédé de télépaiement fondée sur l'inscription qui vient d'être décrite ci-dessus.
L'opération de télépaiement qui concerne plus spécialement l'invention est précédée d'un échange ou négociation préliminaire entre le vendeur V et l'acheteur A. Cette négociation peut avoir été réalisée à distance (par téléphone, par le réseau Internet, etc...) ou simplement avoir été réalisée au cours d'une entrevue entre l'acheteur et le vendeur. L'aboutissement de la négociation consiste en un accord par l'acheteur A du paiement d'un montant MT d'une prestation due par le vendeur V.
On va maintenant décrire une première forme de réalisation du procédé de télépaiement selon l'invention en référence à la figure 3A.
Sur la figure 3A, la référence alphabétique T désigne le serveur de paiement auprès duquel l'acheteur A s'est inscrit préalablement de la façon
<Desc/Clms Page number 13>
décrite ci-dessus. Le serveur de paiement T est en outre connecté : - à un équipement de télécommunications E2 appartenant à un vendeur V abonné au serveur de paiement T et avec lequel l'acheteur A a conclu la transaction, - à un équipement de télécommunications E3 appartenant à l'acheteur A, - et à la banque B1 de l'acheteur A.
Les flèches symbolisent les échanges entre tous ces équipements.
Dans la forme de réalisation représentée, l'équipement E2 consiste par exemple en un serveur Web hébergeant un ou plusieurs sites de vente à distance. L'équipement E3 consiste quant à lui en, par exemple, un ordinateur personnel PC.
Suite à la négociation mentionnée ci-dessus, le vendeur V envoie un message à l'acheteur A lui demandant de lui adresser son numéro de téléphone N. Le procédé de télépaiement se déroule alors de la façon suivante :
1) l'acheteur A adresse son numéro de téléphone N au serveur E2,
2) le serveur E2 adresse au serveur de paiement T des informations relatives à la transaction en cours, telles que par exemple le montant MT dû par l'acheteur A, ainsi que le numéro de téléphone N de l'acheteur A,
3) le serveur de paiement T compose le numéro de téléphone N de l'acheteur A, lui adresse les informations reçues à l'étape 2) et l'invite à présenter la clé remise au moment de l'inscription décrite ci-dessus,
4) l'acheteur A adresse au serveur T la clé K ou Ko, en fonction de la forme de réalisation mise en oeuvre,
5) le serveur de paiement T vérifie ladite clé de la façon décrite cidessus et si le résultat de cette vérification s'avère positif, le serveur de paiement T fait correspondre le numéro de téléphone N de l'acheteur A avec le numéro de la carte bancaire 1 de l'acheteur,
6) le serveur de paiement T adresse à la banque B1 de l'acheteur A une autorisation pour débiter le compte bancaire de l'acheteur A conformément à procédure appelée"Vente A Distance",
1) l'acheteur A adresse son numéro de téléphone N au serveur E2,
2) le serveur E2 adresse au serveur de paiement T des informations relatives à la transaction en cours, telles que par exemple le montant MT dû par l'acheteur A, ainsi que le numéro de téléphone N de l'acheteur A,
3) le serveur de paiement T compose le numéro de téléphone N de l'acheteur A, lui adresse les informations reçues à l'étape 2) et l'invite à présenter la clé remise au moment de l'inscription décrite ci-dessus,
4) l'acheteur A adresse au serveur T la clé K ou Ko, en fonction de la forme de réalisation mise en oeuvre,
5) le serveur de paiement T vérifie ladite clé de la façon décrite cidessus et si le résultat de cette vérification s'avère positif, le serveur de paiement T fait correspondre le numéro de téléphone N de l'acheteur A avec le numéro de la carte bancaire 1 de l'acheteur,
6) le serveur de paiement T adresse à la banque B1 de l'acheteur A une autorisation pour débiter le compte bancaire de l'acheteur A conformément à procédure appelée"Vente A Distance",
<Desc/Clms Page number 14>
7) la banque 81 adresse au serveur de paiement T un message d'acquittement de ladite autorisation,
8) le serveur de paiement T adresse au serveur E2 un message selon lequel le montant MT a bien été acquitté par l'acheteur A.
8) le serveur de paiement T adresse au serveur E2 un message selon lequel le montant MT a bien été acquitté par l'acheteur A.
Le procédé de télépaiement décrit ci-dessus implique que le serveur E2 comprend des moyens logiciels conçus pour : - réaliser la saisie du numéro de téléphone N de l'acheteur A en lieu et place du numéro de la carte bancaire 1 de l'acheteur A, - transmettre au serveur de paiement T le numéro de téléphone N de l'acheteur et les informations relatives à la transaction en cours, - traiter le message reçu en provenance du serveur de paiement T à l'étape 8).
On va maintenant décrire une troisième forme de réalisation du procédé de télépaiement selon l'invention en référence à la figure 3C.
Le procédé de télépaiement selon cette troisième forme de réalisation se distingue de celle de la figure 3B par le fait que suite à la négociation entre l'acheteur A et le vendeur V, le vendeur V envoie un message à l'acheteur A lui demandant de lui adresser, au lieu de son numéro de carte bancaire NC et de la date d'échéance DE de validité de ladite carte, un numéro NCP de pseudonyme de la carte bancaire 1 de l'acheteur A et une date d'échéance DEP de validité dudit pseudonyme.
Le procédé de télépaiement se déroule alors de la façon suivante :
1) l'acheteur A adresse au serveur E2 le numéro de pseudonyme de carte bancaire NCP ainsi que la date d'échéance DEP de validité dudit pseudonyme,
2) le serveur E2 adresse au serveur de paiement T des informations relatives à la transaction en cours, telles que par exemple le montant MT dû par l'acheteur A, le numéro de pseudonyme NPC ainsi que la date d'échéance DEP,
3) le serveur de paiement T fait correspondre le numéro NPC reçu avec le numéro de téléphone N de l'acheteur A, compose le numéro de téléphone N de l'acheteur A, lui adresse les informations relatives à la transaction
1) l'acheteur A adresse au serveur E2 le numéro de pseudonyme de carte bancaire NCP ainsi que la date d'échéance DEP de validité dudit pseudonyme,
2) le serveur E2 adresse au serveur de paiement T des informations relatives à la transaction en cours, telles que par exemple le montant MT dû par l'acheteur A, le numéro de pseudonyme NPC ainsi que la date d'échéance DEP,
3) le serveur de paiement T fait correspondre le numéro NPC reçu avec le numéro de téléphone N de l'acheteur A, compose le numéro de téléphone N de l'acheteur A, lui adresse les informations relatives à la transaction
<Desc/Clms Page number 15>
en cours reçues à l'étape 2) et l'invite à présenter la clé remise au moment de l'inscription décrite ci-dessus,
4) l'acheteur A adresse au serveur T la clé K ou Ko, en fonction de la forme de réalisation mise en oeuvre,
5) le serveur de paiement T vérifie ladite clé de la façon décrite cidessus et si le résultat de cette vérification s'avère positif, le serveur de paiement T fait correspondre le numéro de pseudonyme NCP avec le numéro de la carte bancaire 1 de l'acheteur A,
6) le serveur de paiement T adresse à la banque B1 de l'acheteur A une autorisation pour débiter le compte bancaire de l'acheteur A conformément à procédure appelée "Vente A Distance",
7) la banque B1 adresse au serveur de paiement T un message d'acquittement de ladite autorisation,
8) le serveur de paiement T adresse au serveur E2 un message selon lequel le montant MT a bien été acquitté par l'acheteur A.
4) l'acheteur A adresse au serveur T la clé K ou Ko, en fonction de la forme de réalisation mise en oeuvre,
5) le serveur de paiement T vérifie ladite clé de la façon décrite cidessus et si le résultat de cette vérification s'avère positif, le serveur de paiement T fait correspondre le numéro de pseudonyme NCP avec le numéro de la carte bancaire 1 de l'acheteur A,
6) le serveur de paiement T adresse à la banque B1 de l'acheteur A une autorisation pour débiter le compte bancaire de l'acheteur A conformément à procédure appelée "Vente A Distance",
7) la banque B1 adresse au serveur de paiement T un message d'acquittement de ladite autorisation,
8) le serveur de paiement T adresse au serveur E2 un message selon lequel le montant MT a bien été acquitté par l'acheteur A.
Le procédé de télépaiement décrit ci-dessus implique que le serveur E2 comprend des moyens logiciels conçus pour : - transmettre au serveur de paiement T le numéro de pseudonyme NCP de l'acheteur A, la date d'échéance DEP de validité dudit pseudonyme, et les informations relatives à la transaction en cours, - traiter le message reçu en provenance du serveur de paiement T à l'étape 8).
En ce qui concerne les trois formes de réalisations décrites ci-dessus, le serveur de paiement T peut, de façon connue en tant que telle, placer, à la suite de l'étape 6), le montant MT en remise, ou bien soumettre ce montant en remise dans l'attente que le vendeur V adresse au serveur de paiement T un message de confirmation selon lequel le bien acheté par l'acheteur A au vendeur V a bien été livré par ce dernier.
On va maintenant décrire une quatrième forme de réalisation du procédé de télépaiement selon l'invention en référence à la figure 3D.
Le procédé de télépaiement selon cette quatrième forme de réalisation
<Desc/Clms Page number 16>
implique les mêmes équipements que ceux représentés sur les figures 3A à 3C.
La différence principale par rapport aux trois formes de réalisation précédentes réside dans le fait que le vendeur V n'est pas abonné au serveur de paiement T.
Le procédé de télépaiement se déroule alors de la façon suivante :
1) l'acheteur A adresse au serveur E2 le numéro de pseudonyme de carte bancaire NCP ainsi que la date d'échéance DEP de validité dudit pseudonyme,
2) le serveur E2 adresse à sa banque B2 des informations relatives à la transaction en cours, telles que par exemple le montant MT dû par l'acheteur A, le numéro de pseudonyme NPC ainsi que la date d'échéance DEP,
3) la banque B2 adresse, via un réseau d'autorisation, les informations reçues à l'étape 2) à un centre d'autorisation bancaire (non représenté) associé au serveur de paiement T,
4) le serveur de paiement T effectue la conversion entre le numéro de pseudonyme NCP de carte bancaire de l'acheteur A et le numéro de téléphone N de l'acheteur A, ainsi que la conversion entre ce numéro NCP et le numéro de carte bancaire NC de l'acheteur A, compose le numéro de téléphone N de l'acheteur A, lui adresse les informations relatives à la transaction en cours reçues à l'étape 3) et l'invite à présenter la clé remise au moment de l'inscription décrite ci-dessus,
5) l'acheteur A adresse au serveur T la clé K ou Ko, en fonction de la forme de réalisation mise en oeuvre,
6) le serveur de paiement T vérifie ladite clé de la façon décrite cidessus,
7) si le résultat de cette vérification s'avère positif, le serveur de paiement T adresse à la banque 81 de l'acheteur A une autorisation pour débiter le compte bancaire de l'acheteur A conformément à procédure appelée"Vente A Distance",
8) la banque 81 adresse au serveur de paiement T un message d'acquittement de ladite autorisation,
9) le serveur de paiement T adresse à la banque B2 du vendeur V un
1) l'acheteur A adresse au serveur E2 le numéro de pseudonyme de carte bancaire NCP ainsi que la date d'échéance DEP de validité dudit pseudonyme,
2) le serveur E2 adresse à sa banque B2 des informations relatives à la transaction en cours, telles que par exemple le montant MT dû par l'acheteur A, le numéro de pseudonyme NPC ainsi que la date d'échéance DEP,
3) la banque B2 adresse, via un réseau d'autorisation, les informations reçues à l'étape 2) à un centre d'autorisation bancaire (non représenté) associé au serveur de paiement T,
4) le serveur de paiement T effectue la conversion entre le numéro de pseudonyme NCP de carte bancaire de l'acheteur A et le numéro de téléphone N de l'acheteur A, ainsi que la conversion entre ce numéro NCP et le numéro de carte bancaire NC de l'acheteur A, compose le numéro de téléphone N de l'acheteur A, lui adresse les informations relatives à la transaction en cours reçues à l'étape 3) et l'invite à présenter la clé remise au moment de l'inscription décrite ci-dessus,
5) l'acheteur A adresse au serveur T la clé K ou Ko, en fonction de la forme de réalisation mise en oeuvre,
6) le serveur de paiement T vérifie ladite clé de la façon décrite cidessus,
7) si le résultat de cette vérification s'avère positif, le serveur de paiement T adresse à la banque 81 de l'acheteur A une autorisation pour débiter le compte bancaire de l'acheteur A conformément à procédure appelée"Vente A Distance",
8) la banque 81 adresse au serveur de paiement T un message d'acquittement de ladite autorisation,
9) le serveur de paiement T adresse à la banque B2 du vendeur V un
<Desc/Clms Page number 17>
- L/ message selon lequel le montant MT a bien été acquitté par l'acheteur A,
10) la banque B2 du vendeur V transmet ce message au serveur E2 du vendeur V.
10) la banque B2 du vendeur V transmet ce message au serveur E2 du vendeur V.
D'une manière analogue à ce qui été décrit ci-dessus en référence aux figures 3A à 3C, le serveur de paiement T peut, de façon connue en tant que telle, soumettre, à la suite de l'étape 7), le montant MT de la transaction en remise, à condition que l'étape 5) ci-dessus soit correctement effectuée.
Les procédés d'inscription sécurisée et de télépaiement qui viennent d'être décrits ci-dessus sont destinés à être appliqués en particulier dans le commerce électronique via le réseau Internet, tel que par exemple les enchères à distance. D'une façon plus générale, de tels procédés sont destinés à être appliqués dans tout service de télépaiement impliquant au moins deux personnes disposant chacune d'un équipement de télécommunications approprié, l'une étant l'acheteur et l'autre le vendeur.
Claims (12)
1. Procédé d'inscription d'une première entité dite'l'acheteur" (A), disposant d'un numéro (N) d'abonné à un réseau téléphonique et d'un module sécurisé (1), auprès d'une seconde entité dite"serveur de paiement (T)", caractérisé en ce qu'il comprend au moins les étapes suivantes : - l'acheteur (A) adresse un message confidentiel au serveur (T) par l'intermédiaire d'un premier équipement de télécommunications (E1), ledit message comprenant des informations (NC, DE) relatives au module sécurisé de l'acheteur et au numéro d'abonné téléphonique de l'acheteur, - le serveur vérifie les informations contenues dans ledit message confidentiel, - le serveur affecte au numéro d'abonné téléphonique de l'acheteur les informations relatives au module sécurisé de l'acheteur, dans le cas où le résultat de cette vérification est positif, - le serveur adresse à l'acheteur un code de paiement ou clé (K) destiné à être authentifié par le serveur (T) lors d'un paiement effectué par l'acheteur.
2. Procédé selon la revendication 1, dans lequel le code de paiement ou clé (K) est le même pour chaque paiement.
3. Procédé selon la revendication 1, dans lequel le code de paiement ou clé (K) varie à chaque paiement.
4. Procédé selon la revendication 3, dans lequel lors d'un ième paiement, 1 < i < n, l'acheteur (A) adresse au serveur (T) un ième code de paiement (Ki), ledit code Ki étant un élément d'une série Un = {Ko, Ki,..., K,,..., Kn-i, Kn}.
5. Procédé selon la revendication 4, dans lequel Kn = f (Ko), Kn-1 = f (Kn), ...., K, = f (K, +i),..., Ki = f (K2), f étant une fonction non inversible et Ko un code de paiement racine fourni par le serveur (T) à l'acheteur (A).
6. Procédé selon la revendication 4, dans lequel Ki = E (Ko), K2 = E (K1),.. ", K. = E (K'-1),..., Kn = E (Kn-i), E est un algorithme de chiffrement et Ko un
<Desc/Clms Page number 19>
code de paiement racine fourni par le serveur (T) à l'acheteur (A).
7. Procédé selon la revendication 1, dans lequel le premier équipement de télécommunications (E1) est une cabine téléphonique publique comprenant un moyen de lecture dudit module sécurisé de l'acheteur.
8. Procédé selon la revendication 1, le serveur de paiement (T) adresse à l'acheteur (A), en plus du code de paiement ou clé (K), des informations (NCP, DEP) relatives à un pseudonyme du module sécurisé (1) de l'acheteur (A).
9. Système de télépaiement comprenant un équipement de télécommunications (E3) appartenant à une première entité dite l'acheteur (A) , ladite première entité disposant d'un numéro (N) d'abonné à un réseau téléphonique et d'un module sécurisé (1), une seconde entité dite serveur de
paiement (T) , et un équipement de télécommunications (E2) appartenant à une troisième entité dite "le vendeur (V)"et apte à établir une liaison avec le serveur de paiement (T), ladite première entité étant inscrite auprès de la seconde entité conformément au procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que : l'équipement de télécommunications (E2) appartenant au vendeur (V) comprend : - des moyens de réception de message en provenance de l'acheteur (A), le message comprenant soit le numéro d'abonné téléphonique (N) de l'acheteur (A), soit des informations (NC, DE) relatives au module sécurisé (1) de l'acheteur (A), soit des informations (NCP, DEP) relatives à un pseudonyme du module sécurisé (1) de l'acheteur (A), - des moyens d'émission de message, en direction du serveur de paiement (T), ledit message comprenant, d'une part, des informations (MT) relatives à la transaction et, d'autre part, soit ledit numéro d'abonné téléphonique (N), soit les informations relatives au module sécurisé (1) de l'acheteur (A), soit les informations relatives au pseudonyme du module sécurisé (1) de l'acheteur (A), et en ce que le serveur de paiement (T) comprend :
<Desc/Clms Page number 20>
- des moyens d'émission de message, en direction de l'équipement de télécommunications (E3) appartenant à l'acheteur (A), ledit message comprenant les informations (MT) relatives à la transaction, - des moyens de réception de message en provenance de l'équipement de télécommunications (E3) appartenant à l'acheteur (A), ledit message comprenant un code de paiement ou clé (K) appartenant à l'acheteur (A), - des moyens de vérification de l'exactitude dudit code de paiement ou clé (K).
10. Système selon la revendication 9, caractérisé en ce que lorsque le vendeur (V) est inscrit auprès du serveur de paiement (T), l'émission du message en direction de ce dernier, par les moyens d'émission de l'équipement de télécommunications (E2), est directe.
11. Système selon la revendication 9, caractérisé en ce que lorsque le vendeur (V) n'est pas inscrit auprès du serveur de paiement (T), le message émis par les moyens d'émission de l'équipement de télécommunications (E2), en direction du serveur de paiement (T), est préalablement transmis par une quatrième entité (B2).
12. Système selon la revendication 11, caractérisé en ce que la quatrième entité (B2) est une banque.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0109639A FR2827724B1 (fr) | 2001-07-18 | 2001-07-18 | Procede d'inscription d'un acheteur aupres d'un serveur de paiement et procede de telepaiement fonde sur cette inscription |
| PCT/FR2002/002421 WO2003009242A1 (fr) | 2001-07-18 | 2002-07-10 | Procede d'inscription d'un acheteur aupres d'un serveur de paiement et procede de telepaiement fonde sur cette inscription |
| EP02787147A EP1417656A1 (fr) | 2001-07-18 | 2002-07-10 | Procede d'inscription d'un acheteur aupres d'un serveur de paiement et procede de telepaiement fonde sur cette inscription |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0109639A FR2827724B1 (fr) | 2001-07-18 | 2001-07-18 | Procede d'inscription d'un acheteur aupres d'un serveur de paiement et procede de telepaiement fonde sur cette inscription |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2827724A1 true FR2827724A1 (fr) | 2003-01-24 |
| FR2827724B1 FR2827724B1 (fr) | 2003-12-12 |
Family
ID=8865689
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0109639A Expired - Fee Related FR2827724B1 (fr) | 2001-07-18 | 2001-07-18 | Procede d'inscription d'un acheteur aupres d'un serveur de paiement et procede de telepaiement fonde sur cette inscription |
Country Status (3)
| Country | Link |
|---|---|
| EP (1) | EP1417656A1 (fr) |
| FR (1) | FR2827724B1 (fr) |
| WO (1) | WO2003009242A1 (fr) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6000832A (en) * | 1997-09-24 | 1999-12-14 | Microsoft Corporation | Electronic online commerce card with customer generated transaction proxy number for online transactions |
| EP1028401A2 (fr) * | 1999-02-12 | 2000-08-16 | Citibank, N.A. | Méthode et système pour exécuter une transaction avec cartes bancaires |
| WO2000049586A1 (fr) * | 1999-02-18 | 2000-08-24 | Orbis Patents Limited | Systeme et procede de carte de credit |
| WO2001026062A1 (fr) * | 1999-10-01 | 2001-04-12 | Cardinalcommerce.Com, Inc. | Systeme de traitement de paiement sur et efficace |
-
2001
- 2001-07-18 FR FR0109639A patent/FR2827724B1/fr not_active Expired - Fee Related
-
2002
- 2002-07-10 EP EP02787147A patent/EP1417656A1/fr not_active Withdrawn
- 2002-07-10 WO PCT/FR2002/002421 patent/WO2003009242A1/fr not_active Application Discontinuation
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6000832A (en) * | 1997-09-24 | 1999-12-14 | Microsoft Corporation | Electronic online commerce card with customer generated transaction proxy number for online transactions |
| EP1028401A2 (fr) * | 1999-02-12 | 2000-08-16 | Citibank, N.A. | Méthode et système pour exécuter une transaction avec cartes bancaires |
| WO2000049586A1 (fr) * | 1999-02-18 | 2000-08-24 | Orbis Patents Limited | Systeme et procede de carte de credit |
| WO2001026062A1 (fr) * | 1999-10-01 | 2001-04-12 | Cardinalcommerce.Com, Inc. | Systeme de traitement de paiement sur et efficace |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1417656A1 (fr) | 2004-05-12 |
| WO2003009242A1 (fr) | 2003-01-30 |
| FR2827724B1 (fr) | 2003-12-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1153376B1 (fr) | Procede de telepaiement et systeme pour la mise en oeuvre de ce procede | |
| EP1014317B1 (fr) | Procédé de paiement sécurisé | |
| BRPI0615554A2 (pt) | método para construir um banco de dados de impressões de vozes, sistema de pagamento para contruir um banco de dados de impressões de vozes | |
| AU2005201681A1 (en) | Method and apparatus for conducting commerce between individuals | |
| EP1360665A1 (fr) | Procede et systeme de telepaiement | |
| WO2005124708A1 (fr) | Procede de paiement anonyme et securise sur internet et mobiles | |
| WO2001043092A1 (fr) | Procede et systeme de gestion d'une transaction securisee a travers un reseau de communication | |
| EP1323140B1 (fr) | Procede pour fournir des donnees d'identification d'une carte de paiement a un usager | |
| Alfuraih et al. | Using trusted email to prevent credit card frauds in multimedia products | |
| GB2476054A (en) | Voice authentication of bill payment transactions | |
| WO2019002703A1 (fr) | Contrôle de validité d'une interface de paiement à distance | |
| EP2824625B1 (fr) | Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant | |
| WO2003010720A2 (fr) | Procede et systeme permettant de valider, en mettant en oeuvre un objet portable d'un utilisateur, une requete aupres d'une entite | |
| FR2914763A1 (fr) | Cryptogramme dynamique | |
| EP1354288B1 (fr) | Procede utilisant les cartes de paiement electroniques pour securiser les transactions | |
| GB2369800A (en) | Cash card with scratch off surfaces | |
| FR2827724A1 (fr) | Procede d'inscription d'un acheteur aupres d'un serveur de paiement et procede de telepaiement fonde sur cette inscription | |
| FR3104760A1 (fr) | Procede, serveur et systeme d’authentification de transaction utilisant deux canaux de communication | |
| EP2800072A2 (fr) | Procédé de délivrance par un automate de cartes de téléphonie mobile SIM à abonnement prépayé ou postpayé | |
| CA2325895C (fr) | Procede de paiement securise | |
| WO2002046984A1 (fr) | Procede securise de transaction entre un acheteur et un vendeur | |
| FR2750275A1 (fr) | Procede de gestion dans un systeme telematique distribue et systeme de mise en oeuvre de ce procede | |
| FR2837952A1 (fr) | Procede de paiement en ligne | |
| WO2002052517A1 (fr) | Procede et systeme de paiement et equipements de telecommunications mis en oeuvre dans ce systeme | |
| FR2819127A1 (fr) | Procede et installation de securisation de transactions a distance par confirmation de transaction |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20130329 |