FR2819127A1 - Procede et installation de securisation de transactions a distance par confirmation de transaction - Google Patents

Procede et installation de securisation de transactions a distance par confirmation de transaction Download PDF

Info

Publication number
FR2819127A1
FR2819127A1 FR0100018A FR0100018A FR2819127A1 FR 2819127 A1 FR2819127 A1 FR 2819127A1 FR 0100018 A FR0100018 A FR 0100018A FR 0100018 A FR0100018 A FR 0100018A FR 2819127 A1 FR2819127 A1 FR 2819127A1
Authority
FR
France
Prior art keywords
terminal
confirmation
transaction
merchant
identifier
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.)
Pending
Application number
FR0100018A
Other languages
English (en)
Inventor
Yves Eonnet
Vincent Rigal
Evrard Guelton
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.)
Smart Design
Original Assignee
Smart Design
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 Smart Design filed Critical Smart Design
Priority to FR0100018A priority Critical patent/FR2819127A1/fr
Publication of FR2819127A1 publication Critical patent/FR2819127A1/fr
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/42Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Une installation permet de sécuriser l'utilisation d'identifiants primaires d'acheteur lors de transactions entre des acheteurs et des terminaux marchands (2) via un réseau de communication. Chaque identifiant primaire désigne un compte d'acheteur et est associé à un dispositif communiquant (9) associé à un identifiant auxiliaire. Un acheteur sélectionne des objets et/ ou services proposés par un terminal marchand, ouis lui communique sa sélection et un identifiant secondaire représentatif de son identifiant primaire. Le terminal marchand (2) génère pour un terminal de paiement (3) une requête d'autorisation de transaction (R1) comportant l'identifiant secondaire, le montant de la transaction et un identifiant de compte marchand, et comporte des moyens (10) agencés pour générer une requête de confirmation de transaction (R2) comportant un identifiant de traitement, représentatif de l'identifiant secondaire reçu, et destinée à un terminal de confirmation (11), comportant une table de correspondance identifiants de traitementlidentifiants auxiliaires, de sorte qu'il établisse une liaison avec le dispositif communiquant associé à l'identifiant de traitement en vue d'obtenir de l'acheteur une confirmation de transaction (C2). Le terminal marchand (2) valide la transaction lorsqu'une autorisation de transaction (A1) issue du terminal de paiement (3) et une confirmation de transaction (C2) issue du terminal de confirmation (11) ont été émises.

Description

<Desc/Clms Page number 1>
L'invention concerne la sécurisation des transactions effectuées via un réseau de communication et impliquant une transmission d'au moins un identifiant primaire.
On entend ici par identifiant primaire (PAN) tout type de code alphanumérique associé soit directement à un utilisateur, soit indirectement à un utilisateur par le biais d'un support qui lui appartient.
Le mot support désigne ici tout type de carte dès lors que cette carte est associée à un identifiant primaire, généralement inscrit dessus, et à un dispositif électronique communiquant, tel qu'un radiotéléphone, muni d'un identifiant auxiliaire. Il pourra donc s'agir d'une carte de paiement, par exemple à bande magnétique ou à circuit intégré, ou d'une carte de santé, ou d'un portemonnaie électronique, ou encore d'une carte d'accès à une installation protégée, et analogue.
Par ailleurs, on entend par transmission tout type de communication, qu'il s'agisse d'une communication par écrit, par exemple sous la forme d'un courrier, ou bien d'une communication téléphonique, électronique ou par voie d'ondes.
L'une des méthodes proposées pour sécuriser la transmission de l'identifiant primaire lors d'une transaction, par exemple entre un marchand et un acheteur, consiste à localiser la position du radiotéléphone associé à l'identifiant primaire communiqué par l'acheteur et à n'autoriser la transaction qu'en cas d'identité entre le lieu de la transaction et la position du radiotéléphone, ou bien lorsque l'utilisateur du radiotéléphone, bien qu'éloigné du lieu de la transaction, donne son autorisation pour effectuer ladite transaction. Une telle méthode est décrite dans la demande de brevet FR 2792143.
Cette méthode est bien adaptée aux transactions locales, mais elle ne convient pas aux transactions à distance qui font l'objet du plus grand nombre de fraudes. En effet, dans ce cas elle s'avère trop lente pour permettre le rejet de l'autorisation de transaction, si bien qu'elle ne peut empêcher que le marchand
<Desc/Clms Page number 2>
livre le produit sélectionné, alors même que le propriétaire du support est en train de signaler qu'une fraude est en cours. En d'autres termes la répudiation d'une transaction par le propriétaire d'un support n'est généralement pas prise en compte. Par ailleurs, cette méthode ne permet pas d'éviter qu'un acheteur peu scrupuleux refuse une livraison correspondant à une transaction qu'il a initiée.
En d'autres termes, il existe un besoin réel de non répudiation de transaction pour les marchands. Enfin, ce type de méthode ne peut être mis en oeuvre que dans des zones couvertes par des services de localisation.
L'invention a donc pour but d'apporter une solution à tout ou partie des inconvénients précités.
Elle propose à cet effet un procédé de sécurisation de transactions dans lequel on prévoit les étapes mentionnées ci-après.
Dans une première étape a), l'acheteur (éventuellement via un terminal d'acheteur) sélectionne au moins un objet et/ou service proposé (s) par un terminal marchand, en association avec un montant de transaction, puis il communique au terminal marchand sa sélection et un identifiant secondaire représentatif de son identifiant primaire pour effectuer une transaction avec le marchand.
On entend ici par communiquer tout type de liaison établie entre un acheteur et un marchand, qu'il s'agisse d'une liaison par courrier (vente par correspondance avec transmission d'un identifiant primaire ou secondaire), ou bien d'une communication téléphonique, électronique ou par voie d'ondes. Par ailleurs, on entend par terminal marchand un lieu désigné par une adresse de correspondance (vente par correspondance), ou un serveur informatique raccordé à un réseau téléphonique ou informatique.
Dans une seconde étape b), on génère une requête d'autorisation de transaction destinée à un terminal de paiement (appartenant à un centre de paiement tel qu'une banque ou à un tiers de confiance ou encore à un terminal dédié) et comportant l'identifiant secondaire, le montant de transaction et un identifiant de compte marchand désignant un compte marchand associé au terminal marchand, et on adresse à un terminal de confirmation, muni d'une table de correspondance entre des identifiants auxiliaires, désignant des
<Desc/Clms Page number 3>
dispositifs communiquant, et des identifiants de traitement (identifiants secondaires ou numéros d'abonné représentatifs d'identifiants secondaires), au moins une requête de confirmation de transaction comportant l'identifiant de traitement, pour que ce terminal de confirmation établisse une liaison avec le dispositif communiquant qui est associé à l'identifiant de traitement en vue d'obtenir une confirmation de transaction de son utilisateur.
Dans une troisième étape c), on autorise le terminal marchand qui a requis l'autorisation à valider la transaction lorsque l'on a reçu une autorisation de transaction du terminal de paiement et une confirmation de transaction du terminal de confirmation, de sorte que le compte d'acheteur désigné par l'identifiant secondaire transmis à l'étape b) soit débité du montant de la transaction au profit du compte marchand désigné par l'identifiant de compte marchand.
On entend ici par identifiant secondaire soit directement l'identifiant primaire, soit une transformée de celui-ci. Mais, dans tous les cas, cet identifiant est au format de l'identifiant primaire de manière à être reconnu par le terminal marchand, sans adaptation.
Ainsi, l'identifiant secondaire associé à un support, dont un identifiant représentatif est enregistré dans la table, circule de façon traditionnelle dans le réseau, mais il ne peut en aucune façon être utilisé sans l'accord du propriétaire du support.
Préférentiellement, à l'étape b) la requête d'autorisation n'est communiquée au terminal de paiement qu'une fois que l'on a reçu la confirmation de transaction du terminal de confirmation.
De nombreuses variantes peuvent être envisagées : * A l'étape b) la requête de confirmation peut être adressée au terminal de confirmation directement par le terminal marchand (adapté à cet effet), et la confirmation de transaction est adressée directement au terminal marchand par le terminal de confirmation, de sorte qu'il décide lui-même de valider la transaction une fois en possession de l'autorisation bancaire et de la confirmation de l'acheteur.
<Desc/Clms Page number 4>
* A l'étape b) la requête d'autorisation de transaction peut être transmise au terminal de paiement via un terminal intermédiaire, ce dernier étant chargé de générer et adresser la requête de confirmation au terminal de confirmation, et la confirmation de transaction étant adressée par le terminal de confirmation au terminal intermédiaire. Les autorisation et confirmation de transaction peuvent être transmises au terminal marchand, mais il est préférable que ce soit le terminal intermédiaire qui se charge de transmettre l'autorisation de transaction au terminal marchand une fois qu'il a reçu l'autorisation émanant du terminal de paiement et la confirmation de transaction émanant du terminal de confirmation.
* A l'étape b) la requête de confirmation peut être adressée au terminal de confirmation par le terminal de paiement consécutivement à la réception de la requête d'autorisation de transaction, la confirmation de transaction étant adressée au terminal de paiement par le terminal de confirmation. Les autorisation et confirmation de transaction peuvent être transmises au terminal marchand, mais il est préférable que ce soit le terminal de paiement qui se charge de transmettre l'autorisation de transaction au terminal marchand une fois qu'il a reçu la confirmation émanant du terminal de confirmation et qu'il a décidé d'autoriser la transaction.
* A l'étape b) on peut adresser des première et seconde requêtes de confirmation au terminal de confirmation respectivement par le terminal marchand et par le terminal de paiement, le terminal de confirmation adressant des première et seconde confirmations de transaction respectivement au terminal marchand et au terminal de paiement, et l'autorisation de transaction étant adressée au terminal marchand en cas de réception de la seconde confirmation de transaction.
Dans les variantes mentionnées ci-avant, le terminal de paiement peut appartenir à un tiers de confiance raccordé, via un réseau sécurisé, aux terminaux de paiement bancaires des marchands et des acheteurs.
Dans une autre variante le terminal de paiement est un premier terminal de paiement bancaire appartenant à la banque où se trouve le compte marchand, et qui est agencé pour transmettre à un second terminal de paiement bancaire, appartenant à la banque où se trouve le compte de l'acheteur, une autre requête d'autorisation de transaction. A l'étape b), la requête de confirmation est alors adressée au terminal de confirmation par le second
<Desc/Clms Page number 5>
terminal bancaire consécutivement à la réception de la requête d'autorisation de transaction, et l'autorisation de transaction n'est adressée au terminal marchand qu'une fois que le second terminal bancaire a reçu une confirmation de transaction.
Dans une autre variante, le terminal de paiement est également un premier terminal de paiement bancaire connecté au second terminal de paiement bancaire de l'acheteur. A l'étape b) on adresse des première et seconde requêtes de confirmation au terminal de confirmation respectivement par le terminal marchand et par le second terminal bancaire, et le terminal de confirmation adresse des première et seconde confirmations de transaction respectivement au terminal marchand et au second terminal bancaire, l'autorisation de transaction étant alors adressée au terminal marchand en cas de réception de la seconde confirmation de transaction.
Dans une autre variante, la requête d'autorisation de transaction est transmise lors de l'étape b) au terminal de paiement via un terminal intermédiaire, et on adresse des première et seconde requêtes de confirmation au terminal de confirmation respectivement par le terminal intermédiaire et par le terminal de paiement, le terminal de confirmation adressant des première et seconde confirmations de transaction respectivement au terminal intermédiaire et au terminal de paiement, et l'autorisation de transaction étant adressée au terminal intermédiaire en cas de réception de la seconde confirmation de transaction par le terminal de paiement. Cette autorisation de transaction n'est communiquée au terminal marchand, par le terminal intermédiaire, qu'en cas de réception de la première confirmation et de l'autorisation de transaction émanant du terminal de paiement.
Dans une autre variante, la requête d'autorisation de transaction est transmise à l'étape b) au terminal de paiement via un terminal intermédiaire, le terminal de paiement étant un premier terminal bancaire de marchand raccordé au second terminal bancaire d'acheteur. Toujours lors de cette étape b), on adresse des première et seconde requêtes de confirmation au terminal de confirmation respectivement par le terminal intermédiaire et par le second terminal bancaire, et le terminal de confirmation adresse des première et seconde confirmations de transaction respectivement au terminal intermédiaire et au second terminal bancaire, une autorisation de transaction étant adressée au
<Desc/Clms Page number 6>
terminal intermédiaire en cas de réception de la seconde confirmation de transaction par le second terminal bancaire. Cette autorisation de transaction n'est communiquée au terminal marchand, par le terminal intermédiaire, qu'en cas de réception de la première confirmation et de l'autorisation de transaction intermédiaire.
Selon une autre caractéristique de l'invention, on prévoit une étape complémentaire dans laquelle on communique à chaque terminal de génération de requête de confirmation une liste comportant les identifiants de traitement (identifiants secondaires ou numéros d'abonnés). Lorsqu'il s'agit de numéros d'abonnés, ceux-ci sont de préférence obtenus par conversion des identifiants secondaires associés à l'aide d'une fonction de conversion. Préférentiellement, certains au moins des terminaux de génération de requête de confirmation sont agencés pour appliquer aux identifiants secondaires reçus la fonction de conversion de manière à le transformer en numéro d'abonné, puis pour comparer ce numéro à ceux stockés dans la liste, ou bien le transmettre au terminal de confirmation dans la requête de confirmation. Egalement de préférence, la fonction de conversion est de type dit irréversible, sans collision .
Lorsque l'identifiant secondaire comporte au moins un identifiant de banque d'acheteur (ou de groupe de banques d'acheteur) et un numéro de compte, on peut appliquer la fonction de conversion à l'identifiant secondaire pour obtenir en sortie un résultat que l'on concatène à l'identifiant de banque d'acheteur de manière à former le numéro d'abonné. Le numéro d'abonné peut être généré par le terminal marchand, puis être communiqué au terminal de confirmation pour qu'il détermine l'identifiant auxiliaire associé à l'aide de la table de correspondance et/ou de la liste.
Par ailleurs, avant d'intégrer un numéro d'abonné dans la liste, on procède à une certification de sa correspondance avec l'identifiant secondaire associé. Cette certification est par exemple effectuée par la banque de l'acheteur ou par un terminal dédié comme le terminal de confirmation.
D'autre part, à l'étape b) la confirmation de transaction peut s'effectuer par transmission au terminal de confirmation d'un code secret alphanumérique propre au dispositif interrogé. En variante, la confirmation de transaction peut
<Desc/Clms Page number 7>
s'effectuer par transmission à un opérateur lié au terminal de confirmation, éventuellement via un serveur téléphonique, d'une confirmation verbale et/ou d'un code secret alphanumérique propre au dispositif interrogé.
L'invention propose également une installation de sécurisation permettant de mettre en oeuvre le procédé présenté ci-dessus. Plus précisément, elle concerne une installation de sécurisation de l'utilisation d'identifiants primaires d'acheteurs lors de transactions entre des acheteurs et des terminaux marchand, via un réseau de communication connecté à au moins un terminal de paiement, dans laquelle chaque identifiant primaire désigne au moins un compte d'acheteur et est associé à un identifiant auxiliaire désignant un dispositif électronique communiquant (ainsi qu'éventuellement associé à un support), et chaque transaction comportant, d'une part, la sélection par un acheteur d'au moins un objet et/ou service proposé (s) par un terminal marchand, associé (s) à un montant de transaction, et d'autre part, la communication au terminal marchand, par l'acheteur, de la sélection et d'un identifiant secondaire représentatif de son identifiant primaire, de sorte que ledit terminal marchand (2) adresse à un terminal de paiement (3,4, 5) une requête d'autorisation de transaction (R1) comportant l'identifiant secondaire (PANS), le montant de transaction et un identifiant de compte marchand, de sorte que le terminal marchand adresse à un terminal de paiement une requête d'autorisation de transaction comportant l'identifiant secondaire, le montant de transaction et un identifiant de compte marchand.
Cette installation se caractérise notamment par le fait qu'elle comprend également : * un terminal de confirmation i) comportant une table de correspondance entre, d'une part, des identifiants de traitement (identifiants secondaires ou numéros d'abonné représentatifs d'identifiants secondaires), et d'autre part, des identifiants auxiliaires désignant des dispositifs communiquants, et ii) agencé, à réception d'un identifiant de traitement (identifiant secondaire ou numéro d'abonné), pour établir une liaison avec le dispositif communiquant qui est associé dans sa table à cet identifiant de traitement et générer une confirmation de transaction en cas d'accord de l'utilisateur du dispositif, et 'des moyens de génération de requête agencés pour :
<Desc/Clms Page number 8>
Figure img00080001

* générer, à l'attention du terminal de confirmation, au moins une requête de confirmation de transaction comportant un identifiant de traitement représentatif d'un identifiant secondaire reçu par un terminal marchand, et . à réception d'une confirmation de transaction émanant du terminal de confirmation et d'une autorisation de transaction émanant du terminal de paiement, en réponse à une requête de transaction émanant du terminal marchand, autoriser ce terminal marchand à valider la transaction, de sorte que le compte d'acheteur désigné par l'identifiant secondaire soit débité du montant de la transaction au profit du compte marchand désigné par l'identifiant de compte marchand.
L'invention propose en outre un dispositif électronique communiquant comprenant une touche dédiée pour transmettre une confirmation de transaction prédéfinie dans les installations et les procédés présentés ci-avant. Ce dispositif est de préférence un radiotéléphone (pouvant éventuellement servir de terminal
Figure img00080002

d'acheteur), et encore plus préférentiellement un radiotéléphone fonctionnant selon un mode choisi dans un groupe comprenant le GSM et l'UMTS. Il peut par ailleurs être muni d'une carte SIM, qui peut avantageusement stocker le code secret alphanumérique.
L'installation, le dispositif et le procédé selon l'invention sont tout particulièrement adaptés aux transactions s'effectuant via un réseau de communication public de type Internet ; les terminaux marchands constituants alors des sites web .
D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés, sur lesquels : ta figure 1 illustre schématiquement une installation selon l'invention, dans un premier mode de réalisation, ta figure 2 est une première variante de l'installation de la figure 1, ta figure 3 est une seconde variante de l'installation de la figure 1, ta figure 4 est une troisième variante de l'installation de la figure 1, ta figure 5 illustre schématiquement une installation selon l'invention, dans un second mode de réalisation, ta figure 6 est une première variante de l'installation de la figure 5,
<Desc/Clms Page number 9>
Figure img00090001

ta figure 7 est une seconde variante de l'installation de la figure 5, la figure 8 est une troisième variante de l'installation de la figure 5, ta figure 9 illustre schématiquement un exemple de conversion d'un identifiant secondaire en numéro d'abonné et la certification de la correspondance entre ce numéro d'abonné et l'identifiant secondaire associé.
Les dessins annexés sont, pour l'essentiel, de caractère certain. En conséquence, ils pourront non seulement servir à compléter l'invention, mais aussi contribuer à sa définition, le cas échéant.
Dans la description qui suit, on se réfère à une installation permettant à des acheteurs d'effectuer des transactions, à partir de terminaux d'acheteurs 1, avec des terminaux marchands 2, via un réseau tel que le réseau public Internet.
Bien entendu, le réseau pourrait être d'un autre type, et notamment de type privé, comme par exemple un réseau Intrant. Par ailleurs, la transaction pourrait être initiée directement sur un terminal marchand muni de moyens de saisie/sélection. En outre, la transaction pourrait s'effectuer par correspondance, l'acheteur passant une commande à un marchand par l'intermédiaire d'un courrier ou d'un appel téléphonique, par exemple.
De plus, dans ce qui suit, on considère que les terminaux d'acheteurs 1 sont des terminaux fixes, tels que des ordinateurs individuels (ou PC). Mais, il pourrait s'agir de tout autre type de terminal susceptible d'être raccordé à un réseau pour échanger des informations en vue d'une transaction. Par conséquent, les terminaux d'acheteurs 1 pourraient être portables, comme c'est le cas par exemple des (radio) téléphones portables fonctionnant selon le protocole WAP (pour Wireless Application Protocol ) ou SMS, ou tout autre type de protocole permettant une connexion à un réseau (comme par exemple le protocole UMTS), ou des ordinateurs individuels portables propres à se connecter à un réseau choisi.
On se réfère tout d'abord à la figure 1 pour décrire un premier mode de réalisation d'une installation selon l'invention.
Bien que cela ne soit pas illustré sur les figures, l'installation comporte une multiplicité de terminaux d'acheteurs 1 raccordés au réseau Internet (ou susceptibles d'y être raccordés), un ou plusieurs terminaux marchands 2
<Desc/Clms Page number 10>
(définissant des sites Internet (ou sites Web )), et un ou plusieurs terminaux de paiement 3 également raccordés au réseau, ou bien raccordés aux terminaux marchands via un réseau privé.
On entend ici par terminal de paiement 3 tout type de terminal destiné à assurer des mouvements entre des comptes bancaires d'acheteurs et des comptes bancaires marchands. Par conséquent, il pourra s'agir soit d'un terminal de paiement bancaire ou interbancaire, soit d'un terminal de paiement d'un tiers de confiance servant d'intermédiaire de transaction entre des acheteurs ou des sites marchands et des banques, soit encore un terminal d'une société de crédit. Bien entendu, comme indiqué précédemment, dans le cas d'une vente par correspondance, le terminal marchand peut être un endroit désigné par une adresse, et accessible par courrier ou par téléphone, ou encore par une messagerie électronique.
Dans l'exemple illustré sur la figure 1, on considère que le terminal de paiement 3 est un terminal de tiers de confiance qui est raccordé aux premiers 4 et seconds 5 terminaux bancaires appartenant aux banques dans lesquelles les marchands et les acheteurs ont leurs comptes bancaires, respectivement. Un tel terminal de paiement 3 assure, par exemple, toutes les fonctions transactionnelles, à savoir la vérification et le débit du compte d'acheteur, la vérification et le crédit du compte marchand, et éventuellement l'authentification de la carte de paiement, c'est-à-dire de son code PIN et/ou du fait qu'il s'agit effectivement d'une carte de paiement (cela concerne plus particulièrement les cas où le dispositif électronique communiquant 9 (qui sera décrit plus loin) sert également de terminal d'acheteur à lecteur de carte de paiement ou TPE).
Un acheteur qui souhaite effectuer une transaction, ici sur Internet, commence par connecter son terminal d'acheteur 1 au réseau, puis tente d'établir une connexion entre son terminal d'acheteur 1 et un site marchand 2 choisi qui propose à la vente une multiplicité de produits et/ou services. Une fois cette connexion établie, l'acheteur peut consulter sur l'écran 7 de son terminal d'acheteur 1 les produits et/ou services proposés par le site marchand 2, puis sélectionner à l'aide de moyens de saisie 14 un ou plusieurs produits et/ou services. Lorsque sa sélection est terminée, une page de paiement s'affiche sur
<Desc/Clms Page number 11>
son écran. Cette page comporte un certain nombre de zones d'informations qui doivent être remplies par l'acheteur. L'acheteur doit généralement fournir son nom, son adresse, la date de validité de sa carte de paiement (ou support) 8, ainsi qu'un identifiant secondaire PANS (ou identifiant de carte de paiement 8), composé généralement d'un identifiant de banque ou de centre de paiement IIN, d'un identifiant de compte d'acheteur AAN et souvent d'un code complémentaire CC (voir figure 9). Dans le cas d'une carte de paiement, l'identifiant de banque IIN, l'identifiant de compte d'acheteur AAN et le code complémentaire CC sont inscrits sur la face avant de la carte, et constituent un identifiant primaire. Selon l'invention, l'identifiant secondaire PANS qui est transmis pour effectuer la transaction est soit identique à l'identifiant primaire PAN, soit une transformée de celui-ci, afin de renforcer encore la sécurité de la transaction. Mais, dans tous les cas, cet identifiant secondaire PANS est au format de l'identifiant primaire PAN de manière à être reconnu par le terminal marchand, sans adaptation.
Dans ce qui suit, on considère que l'identifiant primaire PAN et l'identifiant secondaire PANS sont identiques et désignent un numéro inscrit sur un support de type carte de paiement.
La page de paiement comporte également une zone réservée au montant cumulé des objets et/ou services sélectionnés, qui doit faire l'objet de la transaction entre le compte de l'acheteur qui est désigné par le numéro de carte PANS (ou identifiant secondaire) et un compte marchand associé au site marchand concerné. Le terminal d'acheteur 1 peut être éventuellement équipé d'un lecteur de carte de paiement, destiné à vérifier le code PIN de la carte et son authenticité.
Selon l'invention, chaque acheteur dispose non seulement d'au moins une carte de paiement 8 (ou plus généralement d'un support associé à un identifiant secondaire PANS), mais également d'un dispositif électronique communiquant 9, associé, d'une part, à sa carte de paiement 8 et par conséquent à son identifiant secondaire PANS et, d'autre part, à un identifiant auxiliaire IA.
Le dispositif électronique 9 est équipé d'un système de communication. Il s'agit préférentiellement d'un radiotéléphone, notamment de type GSM, ou de type UMTS. Il pourrait également s'agir d'un dispositif communiquant fonctionnant selon un protocole de type WAP ou UMTS, par exemple, et de ce fait assurant
<Desc/Clms Page number 12>
également la fonction de terminal d'acheteur 1. Bien entendu, le dispositif communiquant pourrait être un simple récepteur dédié, muni par exemple d'un afficheur de message, et éventuellement capable de fonctionner en émetteur pour communiquer des confirmations de transaction prédéfinies.
De façon particulièrement avantageuse, on stocke dans une base de données (non représentée et sur laquelle on reviendra plus loin) tous les identifiants secondaires PANS des supports dont les propriétaires sont abonnés au service de sécurisation offert par l'invention, en correspondance des identifiants auxiliaires IA de dispositif 9 associés. On entend ici par identifiant auxiliaire de dispositif aussi bien un numéro de téléphone qu'un code (ou identifiant) alphanumérique désignant un numéro de téléphone dans un annuaire.
Dans ce qui suit, on considère que les dispositifs 9 sont des radiotéléphones, par exemple de type GSM. On considère par ailleurs qu'ils sont indépendants des terminaux d'acheteurs 1.
Lorsque toutes les zones de transaction ont été remplies dans la fenêtre de saisie du terminal d'acheteur 1, celui-ci transmet la commande au terminal marchand 2 du site marchand.
Le terminal marchand 2 génère alors une requête de demande de confirmation de transaction R2, destinée à un terminal de confirmation 11 et comportant au moins un identifiant de traitement sous la forme de l'identifiant secondaire PANS reçu, ou de cet identifiant secondaire complété d'un ou plusieurs signes alphanumériques, ou encore d'un numéro d'abonné associé à cet identifiant secondaire, ainsi que de préférence l'identifiant du terminal émettant la requête R2. Le terminal marchand 2 comporte pour ce faire un module 10 agencé pour générer des requêtes de confirmation de transaction R2 à partir d'un identifiant secondaire PANS reçu.
Le terminal de confirmation 11 est, dans cet exemple, raccordé aux différents terminaux marchands, de préférence via le réseau Internet 1. Il comporte une mémoire dans laquelle se trouve stockée une table de correspondance entre les identifiants de traitement (identifiants secondaires PANS ou numéros d'abonné NA associés aux identifiants secondaires) et des identifiants auxiliaires IA désignant des dispositifs 9, et un module de
<Desc/Clms Page number 13>
communication capable d'extraire de la requête de confirmation R2 l'identifiant secondaire PANS ou le numéro d'abonné NA qu'elle comporte pour déterminer dans la table l'identifiant auxiliaire IA associé. Bien entendu, lorsque l'identifiant secondaire ou le numéro d'abonné n'est pas répertorié dans la table, il n'est pas donné suite à la requête R2. Pour éviter que cette situation ne se produise, il est avantageux de stocker dans les terminaux marchands 2 une liste représentative des identifiants de traitement (identifiants secondaires PANS ou, plus préférentiellement, numéros d'abonnés NA), contenus dans la table de correspondance.
Préférentiellement, ces numéros d'abonnés NA résultent d'une conversion des identifiants secondaires PANS à l'aide d'une fonction de conversion. Plus préférentiellement encore, la fonction de conversion est de type dit irréversible, sans collision)). Il s'agit par exemple d'un algorithme de hachage de type SHA ou MD5, bien connu de l'homme du métier. De la sorte, il n'est pas possible à une personne malintentionnée qui aurait réussi à pénétrer dans la mémoire d'un terminal marchand de remonter aux identifiants secondaires à partir des numéros d'abonnés NA.
La génération d'un numéro d'abonné NA peut s'effectuer, par exemple, par une concaténation de l'identifiant de banque ou de groupe de banques d'acheteur au résultat de l'application de la fonction de conversion à l'identifiant secondaire PANS.
Egalement de préférence, avant intégration d'un numéro d'abonné NA dans la liste, on procède à une certification préalable de sa correspondance avec l'identifiant secondaire PANS associé. En fait, du fait de la correspondance qui existe entre chaque identifiant secondaire PANS et un identifiant auxiliaire IA associé, la certification identifiant secondaire/numéro d'abonné revient à certifier le lien qui existe entre un numéro d'abonné NA et un identifiant auxiliaire IA. Comme illustré sur la figure 9, cette certification peut, par exemple, consister à générer un couple comportant le numéro d'abonné NA, obtenu à l'aide de la fonction de conversion précitée, par exemple de type SHA ou MD5, et l'identifiant auxiliaire IA (ou numéro de téléphone), puis à appliquer aux deux éléments de ce couple une clé de cryptage privée K de manière à délivrer un certificat.
<Desc/Clms Page number 14>
Préférentiellement, cette certification est effectuée par la banque de l'acheteur à l'aide d'un module de conversion et certification. Cette solution est avantageuse, dans la mesure où l'acheteur intéressé par le service de sécurisation s'inscrit dans sa banque, et celle-ci, après avoir généré un certificat, adresse, d'une part, au terminal de confirmation 11 une table de correspondance mise à jour, et d'autre part, aux terminaux marchands 3 une liste d'abonnés également mise à jour. En variante, une fois que l'acheteur s'est inscrit dans sa banque, celle-ci adresse au terminal de confirmation 11 un ordre d'inscription, de préférence en utilisant un lien sécurisé, comportant le nouveau numéro d'abonné NA qu'elle a déterminé, de sorte que ce terminal de confirmation effectue luimême la certification. Dans cette variante, il est bien évident que c'est le terminal de confirmation 11 qui assure la mise à jour périodique des différents sites marchands s'ils comportent une table de correspondance (et de façon plus générale tous les terminaux comportant une liste ou une table de correspondance).
Lorsque le terminal marchand 3 est équipé d'un module de conversion et de certification, il est particulièrement avantageux que la connexion entre ce terminal marchand et le terminal de confirmation 11 s'effectue via un lien sécurisé. Cela permet de garantir l'identité du marchand vis-à-vis des acheteurs, ainsi que de prévenir des attaques du type"man in the middle"permettant à un fraudeur d'intercepter des requêtes de confirmation et de remplacer un vrai numéro d'abonné NA par un autre.
On détermine si l'acheteur est abonné au service de sécurisation soit dans le terminal marchand 2, soit dans le terminal de confirmation 11. La seconde solution est préférée car elle évite que chaque terminal marchand stocke une table de correspondance, ce qui n'est pas conseillé pour des raisons de sécurité. Dans ce cas, il est avantageux que les terminaux marchands 2 soient capables de transformer les identifiants secondaires PANS en numéros d'abonnés NA qu'ils transmettent au terminal de confirmation 11 de sorte qu'ils les compare aux numéros contenus dans une liste d'abonnés qui lui a été communiquée ou bien directement dans la table de correspondance lorsqu'il s'agit d'une table numéros d'abonné/numéros auxiliaires. Dans cette situation,
<Desc/Clms Page number 15>
les terminaux marchands 2, et de préférence leurs modules de génération 10, comportent un module de conversion 12. Ce dernier 12 applique à l'identifiant secondaire PANS reçu la fonction de conversion précitée de manière à le transformer en numéro d'abonné NA, puis il est transmis au terminal de confirmation 11 dans la requête de confirmation R2. A réception de ce numéro d'abonné NA, le terminal de confirmation détermine dans sa table de correspondance et/ou dans sa liste s'il existe un identifiant auxiliaire IA associé.
Si cela n'est pas le cas, la transaction s'effectue de façon classique, c'est-à-dire sans confirmation selon l'invention. Bien entendu, le module de conversion 12 peut n'être contenu que dans le terminal de paiement qui génère les requêtes de confirmation ou dans le terminal de confirmation 11. Dans ce dernier cas, la requête de confirmation R2 qui est transmise au terminal de confirmation 11 comporte l'identifiant secondaire PANS reçu et celui-ci est soit converti en numéro d'abonné, soit directement utilisé, pour déterminer dans la table l'identifiant auxiliaire associé, selon que la table comporte une correspondance numéros d'abonné/identifiants auxiliaires ou identifiants secondaires/identifiants auxiliaires.
Lorsque l'identifiant secondaire PANS ou le numéro d'abonné est dans la table de correspondance et que l'identifiant auxiliaire IA du dispositif 9 associé a été extrait, le terminal de confirmation 11 tente d'établir une liaison téléphonique avec ce dispositif 9, en vue d'obtenir une confirmation de transaction de la part de son utilisateur.
La confirmation de transaction entre l'acheteur et le terminal de paiement 3 peut s'effectuer par transmission d'un code secret alphanumérique personnel, soit par saisie directe par l'acheteur, soit par actionnement d'une touche dédiée gérant l'accès à une mémoire du dispositif communiquant 9. Dans ce dernier cas, la transmission peut être subordonnée à la saisie par l'acheteur d'un autre code secret alphanumérique personnel, qui déverrouille l'accès à la touche dédiée. Cette mémoire peut être contenue dans la carte SIM, lorsque le radiotéléphone en est équipé.
En variante, l'accord de confirmation de l'acheteur peut s'effectuer par transmission à un opérateur lié au terminal de confirmation 11 d'une confirmation
<Desc/Clms Page number 16>
Figure img00160001

verbale eUou d'un code secret alphanumérique personnel. Cette transmission peut s'effectuer via un serveur téléphonique. Dans ce cas, le serveur téléphonique procède selon un mode de synthèse vocale automatisée. Par exemple, on adresse au dispositif communiquant 9 un message spécifique (de préférence de type SMS lorsque le dispositif communiquant est un radiotéléphone de type GSM) destiné à signaler à son utilisateur qu'une confirmation de transaction est requise. Le message spécifique peut comporter soit un numéro d'appel constitué pour la transaction, et permettant par conséquent d'identifier immédiatement l'abonné lorsqu'il le compose, soit un numéro dédié à toutes les transactions, et dans ce cas l'abonné doit décliner son identité ou fournir un identifiant. Le dispositif communiquant peut comporter une touche dédiée permettant, lorsqu'elle est actionnée après réception d'un message spécifique de confirmation, de composer le numéro reçu ou bien un numéro stocké dans une mémoire du dispositif 9. Une fois la liaison établie entre l'abonné et le serveur, ou bien l'opérateur, l'abonné peut transmettre son accord soit par la voix, soit par actionnement de touche de saisie (par exemple l'actionnement de la touche 1 signifie un accord de transaction, tandis que l'actionnement de la touche 2 signifie un refus de transaction ; l'actionnement de la touche 0 peut éventuellement signifier que l'abonné souhaite être raccordé à un opérateur pour discuter de la transaction).
Bien entendu, dans l'hypothèse où la transmission consiste à communiquer un code secret personnel, il est particulièrement avantageux que ce code secret soit stocké dans la table de correspondance en compagnie de l'identifiant de traitement (identifiant secondaire PANS ou numéro d'abonné NA), et de l'identifiant auxiliaire IA associés. Dans cette hypothèse il est préférable que la table de correspondance ne soit stockée que dans le terminal de confirmation 11, les terminaux marchands ou terminaux intermédiaire ou de paiement ne possédant éventuellement qu'un module de conversion 12.
Les modules de génération 10 et de conversion 12 peuvent être réalisés sous la forme d'un ou plusieurs module (s) logiciel ( software ) ou d'un ou plusieurs module-circuit (s) ( hardware ), ou encore d'une ou plusieurs combinaison (s) logiciel/circuit, par exemple, implanté (es) dans une carte
<Desc/Clms Page number 17>
électronique du terminal concerné.
Une fois en possession de la confirmation de l'utilisateur, le terminal de confirmation 11 adresse au terminal marchand, et plus précisément à son module de génération 10, via le réseau, une confirmation de transaction C2,
Une fois en possession de la confirmation de transaction C2, le terminal marchand 2 génère une requête d'autorisation de transaction R1 qu'il adresse, via le réseau 1 (ici Internet), au terminal de paiement qui est désigné par l'identifiant secondaire PANS reçu. Cette requête R1 comporte au moins l'identifiant secondaire PANS, un identifiant de compte marchand et le montant de la transaction, ainsi qu'éventuellement des informations complémentaires comme par exemple la date et l'heure de la transaction et/ou la date de validité du support 8 (ou carte de paiement de l'acheteur).
Une fois en possession de l'identifiant de compte d'acheteur AAN et de l'identifiant de compte marchand, le terminal de paiement vérifie si ces identifiants correspondent effectivement à des comptes d'acheteur et marchand répertoriés. Si tel est le cas, le terminal de paiement 3 adresse au terminal marchand 2 concerné et plus précisément à son module de génération 10, une autorisation de transaction A1, et se met en attente de confirmation de transaction.
Bien entendu, en variante, la requête d'autorisation R1 peut être adressée sensiblement dans le même temps ou avant la requête de confirmation R2.
Une fois en possession de l'autorisation de transaction A1 et de la confirmation de transaction C2, le module de génération 10 accepte la transaction. Le terminal marchand 3 est alors autorisé à valider la transaction. Ce dernier adresse alors au terminal de paiement 3 une confirmation finale de transaction CF de sorte qu'il gère l'opération de débit du compte d'acheteur au profit du compte marchand transmis précédemment, en même temps que les informations de transaction.
Une fois la transaction bancaire effectuée, le terminal de paiement 3 envoie au site marchand 2 un accusé de transaction, de sorte qu'il adresse à son tour au terminal d'acheteur 1 un accusé de transaction (de type facture) qui peut être édité sur une imprimante à laquelle il est connecté.
Bien entendu, lorsque le module de génération 10 du terminal marchand 2
<Desc/Clms Page number 18>
ne possède pas la confirmation d'autorisation C2 et/ou l'autorisation Al, il en avertit le terminal marchand dans lequel il est ici implanté, de sorte qu'il invalide (ou rejette) la transaction. Cet avertissement peut survenir après une durée d'attente déterminée et/ou en cas de refus bancaire ou d'absence de confirmation par l'acheteur (ou par le terminal de confirmation). Afin d'éviter un refus de transaction lors d'une impossibilité de communication entre le terminal de confirmation et le terminal ayant émis la demande de confirmation (terminal marchand, terminal de paiement ou terminal intermédiaire), par exemple en raison d'une saturation d'appel, on peut envisager d'utiliser non pas un numéro d'appel, mais deux.
On peut également envisager, lorsque l'acheteur dispose d'un terminal équipé d'une messagerie électronique, de type e-mail, que le terminal marchand et/ou le terminal de paiement adresse (nt) automatiquement au terminal de l'acheteur un message électronique de compte-rendu de transaction une fois celleci terminée. On peut envisager, de même, que le terminal de l'acheteur adresse automatiquement au terminal marchand et/ou au terminal de paiement un message électronique de compte-rendu de transaction une fois celle-ci terminée.
Cela permet de disposer d'une preuve de transaction retraçant tout l'historique, ainsi qu'éventuellement l'objet, de celle-ci.
On peut également envisager que la confirmation, ou l'infirmation, d'une transaction soit transmise par l'abonné au terminal de confirmation par le biais d'un courrier électronique.
Par ailleurs, lorsque le dispositif électronique communiquant 9 sert également de terminal d'acheteur à lecteur de carte de paiement intégré, on peut utiliser le terminal de paiement 3 pour vérifier l'authenticité de la carte, et notamment le fait qu'il s'agit véritablement d'une carte de paiement, et son code PIN, saisi par l'acheteur.
On se réfère maintenant aux figures 2 à 4 pour décrire trois variantes de l'installation décrite ci-avant.
Dans l'exemple illustré sur la figure 2, le terminal de paiement est en fait le terminal bancaire 4 du marchand (plus précisément il s'agit du terminal qui gère le compte marchand associé au terminal marchand 2 qui émet une requête de
<Desc/Clms Page number 19>
transaction). Ici, ce n'est donc plus un terminal de paiement unique qui gère l'intégralité de la transaction entre le compte du marchand et le compte de l'acheteur. A réception de la requête d'autorisation R1 émise par le terminal marchand 2, le terminal bancaire 4 du marchand renvoie une autre requête d'autorisation de transaction au terminal bancaire 5 de l'acheteur pour qu'il vérifie si la transaction peut être effectuée, par exemple en vérifiant le montant disponible sur le compte de l'acheteur. A réception de l'autorisation bancaire de l'acheteur, le terminal bancaire 4 du marchand adresse au terminal marchand 2 une autorisation de transaction A1. Le reste de la transaction est identique à ce qui a été décrit en référence à la figure 1.
Dans la variante de réalisation illustrée sur la figure 3, la confirmation de transaction ne s'effectue plus entre le terminal marchand 2 et le terminal de confirmation 11, mais entre le terminal de paiement 3, ou le terminal bancaire 5 de l'acheteur, et le terminal de confirmation 11.
Par conséquent, dans ce mode de réalisation, les moyens de génération de requête de confirmation R2 (module 10), et éventuellement le module de conversion 12, lorsque le terminal ne possède que la liste d'abonnés et non pas la table de correspondance, sont logés dans le terminal bancaire qui communique avec le terminal de confirmation 11. Dans l'exemple illustré, il s'agit du terminal bancaire 5 de l'acheteur. Par conséquent, à réception de la requête d'autorisation de transaction R1 routée (ou répliquée) par le terminal de paiement 3 (ou en variante par le terminal bancaire 4 du marchand), le module de génération 10 détermine si l'acheteur est abonné (par interrogation de la table de correspondance stockée dans sa mémoire, et/ou après conversion de l'identifiant secondaire PANS reçu en numéro d'abonné NA, à l'aide du module de conversion 12, lorsqu'il ne possède pas la table de correspondance) puis génère une requête de confirmation de transaction R2 qu'il adresse au terminal de confirmation 11. En cas d'accord de l'acheteur, le terminal de confirmation 11 transmet au terminal bancaire 5 de l'acheteur une confirmation de transaction C2. Puis, le terminal bancaire 5 de l'acheteur transmet son autorisation de transaction au terminal de paiement 3 ou 4 si et seulement si il a reçu la confirmation de transaction C2 et s'il est d'accord pour débiter le compte de son client (l'acheteur). Le terminal de
<Desc/Clms Page number 20>
paiement 3 ou 4 peut alors transmettre au terminal marchand 2 l'autorisation de transaction Al. Le reste de la procédure de transaction est identique à ce qui a été décrit en référence aux figures 1 et 2.
Bien entendu, et comme matérialisé sur la figure 3 par une double flèche en pointillés, les moyens de génération de requête de confirmation 10 peuvent être implantés dans le terminal de paiement 3 ou le terminal bancaire 4 du marchand.
Dans ce cas, la requête de confirmation R2 est tout d'abord adressée au terminal de confirmation 11, puis, lorsque le terminal de paiement 3 (ou 4) reçoit du terminal de confirmation 11 la confirmation de transaction C2, il adresse la requête d'autorisation R1 (ou sa réplique) au terminal bancaire 5 de l'acheteur.
L'autorisation de transaction A1 n'est délivrée par le terminal de paiement 3 ou 4 qu'à condition qu'il ait reçu l'autorisation du terminal bancaire 5 de l'acheteur et la confirmation de transaction C2.
On se réfère maintenant à la figure 4 pour décrire une troisième variante de l'installation de la figure 1.
Dans cette variante, on effectue une double confirmation de transaction en utilisant deux terminaux différents, par exemple le terminal marchand 2 et le terminal bancaire 5 de l'acheteur, ou bien le terminal marchand 2 et le terminal de paiement 3 ou le terminal bancaire 4 du marchand.
Pour ce faire, les deux terminaux précités sont équipés de moyens de génération de requête de confirmation, et comportent de ce fait un module de génération 10, ainsi que de préférence un module de conversion 12 lorsqu'ils ne possèdent pas la table de correspondance. Une unique requête d'autorisation de transaction R1 est transmise du terminal marchand 2 vers le terminal de paiement 3 ou 4 et le terminal bancaire 5 de l'acheteur, et deux requêtes de confirmation R2 et R3 sont adressées au terminal de confirmation 11, respectivement par le terminal marchand 2 et le terminal bancaire 5 (ici celui de l'acheteur, mais comme indiqué précédemment il pourrait s'agir du terminal de paiement 3 ou du terminal bancaire 4 du marchand). A réception des première R2 et/ou seconde R3 requêtes de confirmation, le terminal de confirmation 11 interroge le dispositif 9 de l'acheteur et en cas d'accord il transmet au terminal marchand 2 et au terminal bancaire 5 de l'acheteur des première C2 et seconde C3 confirmations de transaction.
<Desc/Clms Page number 21>
Dans le mode de réalisation où les deux requêtes R2 et R3 sont requises, la non réception de l'une des deux requêtes provoque le rejet de la transaction, et il est préférable que le dispositif 9 ne soit interrogé qu'une fois les deux requêtes reçues.
Lorsqu'une unique requête (R2 ou R3) est requise, il est avantageux de prévoir une détection de doublons pour éviter que le terminal de confirmation 11 n'appelle deux fois le dispositif 9 pour une même transaction.
Les première C2 et seconde C3 confirmations de transaction sont de préférence identiques. De même, les première R2 et seconde R3 requêtes de confirmation sont de préférence identiques.
A réception de la seconde confirmation de transaction C3, le terminal de paiement 3 (ou 4) adresse la requête d'autorisation R1 (ou sa réplique) au terminal bancaire de l'acheteur 5. L'autorisation de transaction A1 n'est adressée au terminal marchand 2 par le terminal de paiement 3 ou 4 qu'à condition que ce dernier ait reçu l'autorisation du terminal bancaire 5 de l'acheteur et la seconde confirmation de transaction C3, et qu'il soit lui-même d'accord pour effectuer la transaction. Celle-ci est communiquée au module de génération 10 qui est censé avoir reçu (ou recevoir) du terminal 11 la première confirmation de transaction C2.
Si tel est le cas, le module de génération 10 donne son accord de transaction et le terminal marchand 2 peut valider la transaction comme décrit précédemment.
On se réfère maintenant aux figures 5 à 8 pour décrire plusieurs variantes d'un autre mode de réalisation de l'invention.
Plus précisément, dans ce mode de réalisation, on utilise en complément des terminaux précédemment décrits un terminal intermédiaire (ou passerelle) 13. Cette passerelle 13 est raccordée, d'une part, aux terminaux marchand 2 et aux terminaux de paiement 3 via le réseau (ici Internet) et, d'autre part, au terminal de confirmation 11, soit via le réseau Internet, soit via un réseau sécurisé.
Dans le mode de réalisation illustré sur la figure 5, la passerelle 13 comporte les moyens de génération 10, et éventuellement le module de conversion 12, par exemple lorsqu'elle ne possède que la liste d'abonnés et non pas la table de correspondance ou bien lorsque la requête de confirmation transmise au terminal de confirmation 11 doit comporter un numéro d'abonné NA à
<Desc/Clms Page number 22>
la place d'un identifiant secondaire PANS.
La requête d'autorisation de transaction R1 est toujours émise par le terminal marchand 2, mais cette fois-ci en direction de la passerelle 13. Le module de génération 10 de la passerelle 13 génère la requête de confirmation de transaction C2 destinée au terminal de confirmation 11. Si le terminal de confirmation 11 donne son accord de transaction en adressant une confirmation de transaction C2 au terminal intermédiaire 13, alors ce dernier route (ou génère une réplique de) la requête d'autorisation R1 vers le terminal de paiement 3. Si le terminal de paiement 3 est d'accord pour effectuer la transaction, il renvoie à la passerelle 13 une autorisation (intermédiaire) de transaction A1. Celle-ci est transmise au module de génération 10. Lorsque le module de génération 10 du terminal intermédiaire 13 est en possession de l'autorisation de transaction A1 et de la confirmation de transaction C2, il adresse au terminal marchand 2 une autorisation finale de transaction AF. Ledit terminal marchand 2 peut alors valider la transaction et adresser à la passerelle 13 une confirmation finale CF de sorte que le compte de l'acheteur soit débité au profit du compte marchand.
Dans la variante d'installation illustrée sur la figure 6, le terminal de paiement 3 est le terminal bancaire 4 du marchand. L'installation est donc sensiblement identique à celle décrite en référence à la figure 2, avec en plus un terminal intermédiaire 13 du type de celui qui vient d'être décrit en référence à la figure 5.
Dans la variante illustrée sur la figure 7, la confirmation de la transaction s'effectue entre le terminal bancaire de l'acheteur 5 et le terminal de confirmation 11 ou bien entre le terminal de paiement 3 ou 4 (terminal bancaire du marchand) et le terminal de confirmation 11. Ce mode de réalisation est sensiblement identique à celui décrit en référence à la figure 3, avec en plus le terminal intermédiaire 13. Cependant, contrairement aux modes de réalisation décrits en référence aux figures 5 et 6, la passerelle 13 n'a pas besoin de posséder de module de génération de confirmation. En effet, seul le terminal bancaire 5 (ou 4 ou 3) a besoin de posséder un module de génération de requête de confirmation 10, et éventuellement un module de conversion 12 lorsqu'il ne possède que la liste d'abonnés et non pas la table de correspondance.
<Desc/Clms Page number 23>
Ici, la passerelle 13 ne sert donc que d'intermédiaire entre le terminal marchand 2 et un terminal de paiement. Elle peut être utilisée, par exemple, pour stocker la liste de numéros d'abonnés NA, par exemple pour ajouter à la requête d'autorisation de transaction R1 une information spécifiant que l'acheteur est abonné au service de sécurisation, ou bien pour générer un numéro d'abonné NA représentatif de l'identifiant secondaire reçu, destiné à remplacer dans la requête de confirmation l'identifiant secondaire PANS.
Dans la variante illustrée sur la figure 8, on effectue une double confirmation de transaction, du type de celle qui a été décrite en référence à la figure 4. De préférence, comme dans les variantes illustrées sur les figures 5 et 6, on prévoit un terminal intermédiaire 13 équipé d'un module de génération de requête de confirmation 10, et éventuellement d'un module de conversion 12 lorsqu'il ne possède que la liste d'abonnés et non pas la table de correspondance. En d'autres termes, les requêtes de confirmation et les confirmations de transaction sont échangées, d'une part, entre le terminal intermédiaire 13 et le terminal de confirmation 11 et, d'autre part, entre le terminal de paiement 3 ou 4 et le terminal de confirmation 11 (comme illustré).
Lorsque le module de génération 10 de la passerelle 13 est en possession de l'autorisation de transaction A1, qui résulte, d'une part, de l'accord de transaction du terminal bancaire 5 de l'acheteur et de l'accord C3 de l'acheteur via le terminal de confirmation 11 et, d'autre part, de l'accord de l'autre terminal de paiement 3 ou 4, ainsi que de la première confirmation C2 émanant du terminal de confirmation 11, il adresse une autorisation finale AF au terminal marchand 2 qui peut alors valider la transaction puis générer une confirmation finale CF à destination des terminaux bancaires, via la passerelle 13.
Le fait d'intégrer les moyens de génération de requête de confirmation dans les terminaux de paiement ou dans un terminal intermédiaire permet de ne pas avoir à modifier ou adapter les terminaux marchands. Cela renforce également la sécurisation dans la mesure où aucune information, représentative des identifiants secondaires associés aux supports des acheteurs, n'a réellement besoin d'être mémorisée dans les terminaux marchand.
L'invention porte également sur un procédé de sécurisation qui peut être
<Desc/Clms Page number 24>
mis en oeuvre dans une installation du type de celle qui vient d'être décrite, en référence aux figures 1 à 9.
Ce procédé de sécurisation comporte au moins les étapes résumées ciaprès, mais, plus généralement, toutes les étapes qui ressortent de la description de l'installation.
Dans une première étape, l'acheteur sélectionne (éventuellement à l'aide d'un terminal d'acheteur 1 l'un au moins des objets et/ou services qui sont proposés par un site marchand (éventuellement par un terminal marchand 2 de ce site). La sélection est communiquée au site marchand (éventuellement via le terminal d'acheteur 1 et le terminal marchand 2), accompagnée d'un identifiant secondaire PANS représentatif d'un identifiant primaire PAN associé à l'acheteur (éventuellement associé à un support 8 qui lui appartient), et un montant de transaction est associé à la sélection.
Dans une seconde étape, on génère une requête d'autorisation de transaction R1 destinée à un terminal de paiement 3,4 (appartenant à un centre de paiement tel qu'une banque ou à un tiers de confiance ou encore à un terminal dédié) et comportant l'identifiant secondaire PANS reçu, le montant de transaction et un identifiant de compte marchand désignant un compte marchand associé au terminal marchand, et on adresse à un terminal de confirmation 11, muni d'une table de correspondance entre des identifiants de traitement (identifiants secondaires PANS ou numéros d'abonné NA représentatifs d'identifiants secondaires), et des identifiants auxiliaires IA désignant des dispositifs communiquants 9, au moins une requête de confirmation de transaction R2, R3 comportant l'identifiant de traitement (identifiant secondaire PANS ou numéro d'abonné NA représentatif de cet identifiant secondaire), pour que ce terminal de confirmation 11 établisse une liaison avec le dispositif communiquant 9 qui est associé à l'identifiant secondaire PANS ou au numéro d'abonné NA en vue d'obtenir une confirmation de transaction de son utilisateur.
Dans une troisième étape, on autorise le terminal marchand 2 qui a requis l'autorisation à valider cette transaction lorsque l'on a reçu une autorisation de transaction A1 du terminal de paiement 3,4 et une confirmation de transaction C2, C3 du terminal de confirmation 11, de sorte que le compte
<Desc/Clms Page number 25>
d'acheteur désigné par l'identifiant secondaire transmis à la seconde étape soit débité du montant de la transaction au profit du compte marchand désigné par l'identifiant de compte marchand.
Comme mentionné ci-avant, tout ce qui a été indiqué dans la partie décrivant l'installation selon l'invention s'applique également au procédé selon l'invention, et notamment le fait qu'à la seconde étape on transmet préférentiellement la requête d'autorisation R1 au terminal de paiement 3,4 après avoir reçu du terminal de confirmation 11 la confirmation de transaction C2. Par ailleurs, la requête de confirmation peut être adressée au terminal de paiement via un terminal intermédiaire 13. En outre, une (ou des) requête (s) de confirmation peu (ven) t être générée (s) dans le terminal marchand 2 ou dans le terminal intermédiaire 13 et/ou dans l'un des terminaux de paiement 3-5. D'autre part, on peut prévoir une étape complémentaire dans laquelle on transmet aux terminaux marchands ou au terminal intermédiaire 13 ou encore au terminal de confirmation 11 une liste de numéros d'abonnés NA. Cette étape complémentaire peut être précédée d'une étape de certification de la correspondance entre les numéros d'abonnés NA et les identifiants secondaires associés PANS.
Dans ce qui précède, on a décrit une installation, un dispositif et un procédé dans lesquels la transaction entre un acheteur et un terminal marchand s'effectue via un terminal d'acheteur, indépendant du dispositif électronique communiquant ou combiné à celui-ci en un unique ensemble. Mais, l'invention concerne également les transactions qui s'effectuent directement dans le terminal marchand, sans utiliser un terminal d'acheteur. Dans ce cas, il est clair que le terminal marchand comporte des moyens de saisie (ou d'enregistrement, ou encore de synthèse vocale) pour permettre à l'acheteur d'effectuer sa sélection et éventuellement de fournir son identifiant secondaire et ses coordonnées personnelles.
L'invention ne se limite pas aux modes de réalisation d'installation et de procédé décrits ci-avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ci-après.

Claims (58)

REVENDICATIONS
1. Procédé de sécurisation de l'utilisation d'identifiants primaires d'acheteurs lors de transaction entre des acheteurs et des terminaux marchands (2) via un réseau de communication, chaque identifiant primaire (PAN) désignant au moins un compte d'acheteur et étant associé à un identifiant auxiliaire (ira) désignant un dispositif électronique communiquant (9), caractérisé en ce qu'il comprend les étapes suivantes : a) sélectionner au moins un objet et/ou service proposé (s) par un terminal marchand (2), en association avec un montant de transaction, puis communiquer audit terminal marchand (2) la sélection et un identifiant secondaire (PANS) représentatif d'un identifiant primaire (PAN) de l'acheteur, b) générer une requête d'autorisation de transaction destinée à un terminal de paiement (3,4, 5) et comportant l'identifiant secondaire (PANS), le montant de transaction et un identifiant de compte marchand désignant un compte marchand associé au terminal marchand (2), et adresser à un terminal de confirmation (11), muni d'une table de correspondance entre des identifiants de traitement représentatifs d'identifiants secondaires et des identifiants auxiliaires (via) désignant des dispositifs (9), au moins une requête de confirmation de transaction (R2) comportant l'identifiant de traitement, de sorte que le terminal de confirmation établisse une liaison avec le dispositif communiquant (9) associé dans la table à cet identifiant de traitement en vue d'obtenir une confirmation de transaction de son utilisateur, et c) autoriser ledit terminal marchand (2) à valider la transaction en cas de réception d'une autorisation de transaction (Al, AF) émanant du terminal de paiement (3,4, 5) et d'une confirmation de transaction (C2) émanant du terminal de confirmation (11), de sorte que le compte d'acheteur désigné par l'identifiant secondaire (PANS) soit débité du montant de la transaction au profit du compte marchand désigné par l'identifiant de compte marchand.
2. Procédé selon la revendication 1, caractérisé en ce qu'à l'étape b) on communique au terminal de paiement (3) la requête d'autorisation de transaction (R1), générée par le terminal marchand (2), à réception de la confirmation de transaction émanant du terminal de confirmation (11).
<Desc/Clms Page number 27>
3. Procédé selon l'une des revendications 1 et 2, caractérisé en ce qu'à l'étape b) ladite requête de confirmation (R2) est adressée au terminal de confirmation (11) par ledit terminal marchand, et ladite confirmation de transaction (C2) est adressée au terminal marchand (2) par ledit terminal de confirmation (11).
4. Procédé selon l'une des revendications 1 et 2, caractérisé en ce qu'à l'étape b) i) ladite requête d'autorisation de transaction (R1) est transmise au terminal de paiement (3,4, 5) via un terminal intermédiaire (13), ii) ladite requête de confirmation (R2) est adressée au terminal de confirmation (11) par ledit terminal intermédiaire (13), et iii) ladite confirmation de transaction (C2) est adressée au terminal intermédiaire (13) par ledit terminal de confirmation (11).
5. Procédé selon la revendication 1, caractérisé en ce qu'à l'étape b) ladite requête de confirmation (R2) est adressée au terminal de confirmation (11) par ledit terminal de paiement (3,4, 5) consécutivement à la réception de la requête d'autorisation de transaction (R1), et ladite autorisation de transaction (A1) est transmise au terminal marchand (2) par le terminal de paiement (3,4) à réception de la confirmation de transaction (C2) et après avoir autorisé la transaction.
6. Procédé selon l'une des revendications 1 et 2, caractérisé en ce qu'à l'étape b) on adresse des première (R2) et seconde (R3) requêtes de confirmation au terminal de confirmation (11) respectivement par ledit terminal marchand (2) et par ledit terminal de paiement (3,4, 5), et ledit terminal de confirmation (11) adresse une première confirmation de transaction (C2) au terminal marchand (2) et une seconde confirmation de transaction (C3) au terminal de paiement (3,4, 5), ladite autorisation de transaction (A1) étant alors adressée au terminal marchand (2) en cas de réception de la seconde confirmation de transaction (C3).
7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que le terminal de paiement (3) appartient à un tiers de confiance raccordé via un réseau sécurisé aux terminaux de paiement bancaires des marchands (4) et des acheteurs (5).
8. Procédé selon l'une des revendications 1 et 2, caractérisé en ce qu'à l'étape b) le terminal de paiement est un premier terminal de paiement bancaire (4) appartenant à la banque où se trouve le compte marchand, ce
<Desc/Clms Page number 28>
premier terminal bancaire (4) étant agencé pour transmettre à un second terminal de paiement bancaire (5) appartenant à la banque où se trouve le compte de l'acheteur une autre requête d'autorisation de transaction (R1), ladite requête de confirmation (C1) étant adressée au terminal de confirmation (11) par ledit second terminal bancaire (5) consécutivement à la réception de la requête d'autorisation de transaction (R1), et ladite autorisation de transaction (A1) étant adressée au terminal marchand (2) en cas de réception d'une confirmation de transaction (C2) par le second terminal bancaire (5) ayant adressé la requête de confirmation (R2).
9. Procédé selon l'une des revendications 1 et 2, caractérisé en ce qu'à l'étape b) i) le terminal de paiement est un premier terminal de paiement bancaire (4) appartenant à la banque où se trouve le compte marchand, ce premier terminal bancaire (4) étant agencé pour transmettre à un second terminal de paiement bancaire (5) appartenant à la banque où se trouve le compte de l'acheteur une autre requête d'autorisation de transaction (R1), ii) on adresse des première (R2) et seconde (R3) requêtes de confirmation au terminal de confirmation (11) respectivement par ledit terminal marchand (2) et par ledit second terminal bancaire (5), et iii) ledit terminal de confirmation (11) adresse une première confirmation de transaction (C2) au terminal marchand (2) et une seconde confirmation de transaction (C3) au second terminal bancaire (5), ladite autorisation de transaction (A1) étant alors adressée au terminal marchand (2) en cas de réception de la seconde confirmation de transaction (C3).
10. Procédé selon l'une des revendications 1 et 2, caractérisé en ce qu'à l'étape b) i) ladite requête d'autorisation de transaction (R1) est transmise au terminal de paiement (3,4, 5) via un terminal intermédiaire (13), ii) on adresse des première (R2) et seconde (R3) requêtes de confirmation au terminal de confirmation (11) respectivement par ledit terminal intermédiaire (13) et par ledit terminal de paiement (3,4, 5), et iii) ledit terminal de confirmation (11) adresse une première confirmation de transaction (C2) au terminal intermédiaire (13) et une seconde confirmation de transaction (C3) au terminal de paiement (3,4, 5), une autorisation de transaction intermédiaire (A1) étant alors adressée au terminal intermédiaire (13) en cas de réception de la seconde confirmation de transaction (C3) par le terminal de paiement (3,4, 5), et l'autorisation finale de transaction (AF) étant communiquée au terminal marchand (2) par le terminal
<Desc/Clms Page number 29>
intermédiaire (13) en cas de réception de la première confirmation (C2) et de l'autorisation de transaction intermédiaire (A1).
11. Procédé selon l'une des revendications 1 et 2, caractérisé en ce qu'à l'étape b) i) ladite requête d'autorisation de transaction (R1) est transmise au terminal de paiement (4) via un terminal intermédiaire (13), ledit terminal de paiement étant un premier terminal de paiement bancaire (4) appartenant à la banque où se trouve le compte marchand, ce premier terminal bancaire (4) étant agencé pour transmettre à un second terminal de paiement bancaire (5) appartenant à la banque où se trouve le compte de l'acheteur une autre requête d'autorisation de transaction (R1), ii) on adresse des première (R2) et seconde (R3) requêtes de confirmation au terminal de confirmation (11) respectivement par ledit terminal intermédiaire (13) et par ledit second terminal bancaire (5), et iii) ledit terminal de confirmation (11) adresse une première confirmation de transaction (C2) au terminal intermédiaire (13) et une seconde confirmation de transaction (C3) au second terminal bancaire (5), une autorisation de transaction intermédiaire (A1) étant alors adressée au terminal intermédiaire (13) en cas de réception de la seconde confirmation de transaction (C3) par le second terminal bancaire (5), et l'autorisation finale de transaction (AF) étant communiquée au terminal marchand (2) par le terminal intermédiaire (13) en cas de réception de la première confirmation de transaction (C2) et de l'autorisation de transaction intermédiaire (A1).
12. Procédé selon l'une des revendications 1 à 11, caractérisé en ce que ladite table de correspondance est gérée par un terminal choisi parmi le terminal de confirmation, le terminal de paiement (3) et le second terminal bancaire (5).
13. Procédé selon l'une des revendications 1 à 12, caractérisé en ce qu'à l'étape a) on communique au terminal marchand (2) la sélection, un identifiant secondaire (PANS) représentatif d'un identifiant primaire (PAN), et une information spécifiant que l'identifiant de traitement est répertorié dans la table de correspondance, ladite information étant communiquée à chaque terminal destiné à émettre une requête de confirmation (R2, R3) à l'étape b).
14. Procédé selon l'une des revendications 1 à 13, caractérisé en ce que les identifiants de traitement sont des numéros d'abonné (NA) résultant
<Desc/Clms Page number 30>
d'une conversion des identifiants secondaires (PANS) à l'aide d'une fonction de conversion.
15. Procédé selon l'une des revendications 1 à 14, caractérisé en ce qu'il comprend une étape complémentaire dans laquelle on communique à l'un au moins des terminaux (2,3, 4,5, 13), agencés pour émettre une requête de confirmation (R2, R3), une liste représentative des identifiants de traitement contenus dans ladite table de correspondance.
16. Procédé selon la combinaison des revendications 14 et 15, caractérisé en ce qu'à réception d'un identifiant secondaire (PANS) chaque terminal équipé de moyens de génération de requête de confirmation (2,3, 4,5, 13) est agencé pour appliquer à cet identifiant secondaire ladite fonction de conversion de manière à le transformer en numéro d'abonné (NA), puis à comparer ce numéro à ceux stockés dans la liste.
17. Procédé selon l'une des revendications 14 à 16, caractérisé en ce qu'à réception d'un identifiant secondaire (PANS) chaque terminal équipé de moyens de génération de requête de confirmation (2,3, 4,5, 13) est agencé pour appliquer à cet identifiant secondaire ladite fonction de conversion de manière à le transformer en numéro d'abonné (NA), puis à le communiquer dans la requête de confirmation (R2, R3) au terminal de confirmation 11 de sorte qu'il détermine dans la table de correspondance l'identifiant auxiliaire (via) associé.
18. Procédé selon l'une des revendications 14 à 17, caractérisé en ce que ladite fonction de conversion est de type dit irréversible, sans collision .
19. Procédé selon l'une des revendications 14 à 18, dans lequel l'identifiant secondaire (PANS) comporte au moins un identifiant de banque d'acheteur ou de groupe de banque d'acheteur (UN) et un identifiant de compte d'acheteur (MN), caractérisé en ce que ladite fonction de conversion est appliquée à l'identifiant secondaire (PANS) pour obtenir en sortie un résultat destiné à être concaténé à l'identifiant de banque ou de groupe de banque d'acheteur (ion) de manière à former ledit numéro d'abonné (NA).
20. Procédé selon l'une des revendications 14 à 19, caractérisé en ce que l'on procède à une certification de la correspondance entre chaque numéro d'abonné (NA) et l'identifiant secondaire (PANS) associé avant d'intégrer ledit numéro d'abonné dans ladite liste et/ou ladite table de correspondance.
<Desc/Clms Page number 31>
21. Procédé selon l'une des revendications 1 à 13, caractérisé en ce que chaque requête de confirmation (R2, R3) est une copie de la requête d'autorisation (R1), comportant un identifiant de traitement sensiblement identique à l'identifiant secondaire (PANS) reçu.
22. Procédé selon l'une des revendications 1 à 21, caractérisé en ce qu'à l'étape b) la confirmation de transaction s'effectue par transmission au terminal de confirmation (11) d'un code secret alphanumérique propre au dispositif communiquant interrogé (9).
23. Procédé selon l'une des revendications 1 à 22, caractérisé en ce qu'à l'étape b) la confirmation de transaction s'effectue par transmission à un opérateur lié au terminal de confirmation (11) d'une confirmation verbale et/ou d'un code secret alphanumérique propre au dispositif communiquant interrogé (9).
24. Procédé selon la revendication 23, caractérisé en ce qu'à l'étape b) la transmission à l'opérateur s'effectue via un serveur téléphonique.
25. Procédé selon l'une des revendications 1 à 24, caractérisé en ce qu'à l'étape a) la sélection et la communication s'effectuent après une connexion entre un terminal d'acheteur et le terminal marchand (2).
26. Installation de sécurisation de l'utilisation d'identifiants primaires d'acheteurs lors de transactions entre des acheteurs et des terminaux marchand (2) via un réseau de communication connecté à au moins un terminal de paiement (3,4, 5), chaque identifiant primaire (PAN) désignant au moins un compte d'acheteur (AAN) et étant associé à un identifiant auxiliaire (tua) désignant un dispositif électronique communiquant (9), chaque transaction comportant i) une sélection par un acheteur d'au moins un objet et/ou service proposé (s) par un terminal marchand (2), associé (s) à un montant de transaction, et ii) une communication audit terminal marchand (2), par ledit acheteur, de la sélection et d'un identifiant secondaire (PANS) représentatif d'un identifiant primaire (PAN), de sorte que ledit terminal marchand (2) adresse à un terminal de paiement (3,4, 5) une requête d'autorisation de transaction (R1) comportant l'identifiant secondaire (PANS), le montant de transaction et un identifiant de compte marchand, caractérisée en ce qu'elle comprend également :
<Desc/Clms Page number 32>
* un terminal de confirmation (11) comportant une table de correspondance entre des identifiants de traitement, représentatifs d'identifiants secondaires (PANS), et des identifiants auxiliaires (via) désignant des dispositifs communiquants (9), et agencé, à réception d'un identifiant de traitement pour établir une liaison avec un dispositif communiquant (9) associé dans la table à cet identifiant de traitement et générer une confirmation de transaction (C2, C3) en cas d'accord de l'utilisateur du dispositif, et * des moyens de génération de requête (10) agencés pour : générer, à l'attention du terminal de confirmation (11), au moins une requête de confirmation de transaction (R2) comportant un identifiant de traitement représentatif d'un identifiant secondaire (PANS) reçu par un terminal marchand, et 'à réception d'une confirmation de transaction (C2, C3) émanant dudit terminal de confirmation (11) et d'une autorisation de transaction (Al, AF) émanant du terminal de paiement (3,4) en réponse à une requête de transaction (R1) émanant dudit terminal marchand (2), autoriser ledit terminal marchand (2) à valider ladite transaction, de sorte que le compte d'acheteur désigné par l'identifiant secondaire (PANS) soit débité du montant de la transaction au profit du compte marchand désigné par l'identifiant de compte marchand.
27. Installation selon la revendication 26, caractérisée en ce que lesdits moyens de génération (10) sont agencés pour communiquer au terminal de paiement (3) la requête d'autorisation de transaction (R1), générée par un terminal marchand (2), à réception de la confirmation de transaction émanant du terminal de confirmation (11).
28. Installation selon l'une des revendications 26 et 27, caractérisée en ce que lesdits moyens de génération (10) sont logés dans lesdits terminaux marchand (2), ces derniers étant raccordés au terminal de confirmation (11) de sorte que les requêtes de confirmation (R2) et les confirmations de transaction (C2, C3) soient échangées directement entre les terminaux marchand (2) et le terminal de confirmation (11).
29. Installation selon l'une des revendications 26 et 27, caractérisée en ce que lesdits moyens de génération (10) sont logés dans un terminal intermédiaire (13) raccordé aux terminaux marchand (2) et de paiement (3,4, 5),
<Desc/Clms Page number 33>
ainsi qu'au terminal de confirmation (11), les requêtes d'autorisation de transaction (R1) et les requêtes de confirmation (R2, R3) étant transmises respectivement au terminal de paiement (3,4, 5) et au terminal de confirmation (11) par le terminal intermédiaire (13), l'autorisation de transaction étant transmise par le terminal de paiement au terminal intermédiaire (13) et ladite confirmation de transaction (C2, C3) étant adressée par le terminal de confirmation (11) au terminal intermédiaire (13).
30. Installation selon la revendication 29, caractérisée en ce que les moyens de génération (10) du terminal intermédiaire (13) sont agencés pour transmettre une autorisation de transaction finale (AF) au terminal marchand en cas d'autorisation de transaction (A1) et de la confirmation de transaction (C2).
31. Installation selon l'une des revendications 26 et 27, caractérisée en ce que lesdits moyens de génération (10) sont logés dans ledit terminal de paiement (3,4, 5), ce dernier étant raccordé au terminal de confirmation (11) de sorte que les requêtes de confirmation (R2, R3) et les confirmations de transaction (C2, C3) soient échangées entre les terminaux de paiement (3,4, 5) et de confirmation (11), ladite autorisation de transaction (A1) étant transmise au terminal marchand (2) par le terminal de paiement (3,4) à réception de la confirmation de transaction (C2) et après avoir autorisé la transaction.
32. Installation selon l'une des revendications 26 et 27, caractérisée en ce que lesdits terminaux marchand (2) et de paiement (3,4, 5) comprennent respectivement des premiers et des seconds moyens de génération (10), agencés pour générer des première (R2) et seconde (R3) requêtes de confirmation, et raccordés respectivement au terminal de confirmation (11), ledit terminal de confirmation (11) étant agencé pour adresser des premières (C2) et secondes (C3) confirmations de transaction (C2) respectivement aux terminaux marchand (2) et aux terminaux de paiement (3,4, 5), et lesdits seconds moyens de génération (10) étant en outre agencés pour transmettre aux terminaux marchands (2) des autorisations de transaction (A1) en cas de réception d'une seconde confirmation de transaction (C3).
33. Installation selon l'une des revendications 26 à 32, caractérisée en ce que le terminal de paiement (3) appartient à un tiers de confiance raccordé via un réseau sécurisé aux terminaux de paiement bancaires des marchands (4) et des acheteurs (5).
<Desc/Clms Page number 34>
Figure img00340001
34. Installation selon l'une des revendications 26 et 27, caractérisée en ce qu'elle comprend une multiplicité de terminaux de paiement, chacun étant un premier terminal de paiement bancaire (4) appartenant aux banques des comptes marchand et étant raccordé à une multiplicité de seconds terminaux de paiement bancaire (5) appartenant aux banques des comptes d'acheteur et comportant des moyens de génération (10) agencés pour transmettre au terminal de confirmation (11) une requête de confirmation (R2, R3) à réception d'une requête d'autorisation de transaction (A1) reçue d'un premier terminal bancaire (4), et lesdits moyens de génération (10) étant agencés pour transmettre au premier terminal (4) concerné une autorisation de transaction à réception d'une seconde confirmation de transaction (C3).
35. Installation selon l'une des revendications 26 et 27, caractérisée en ce qu'elle comprend des premiers moyens de génération (10) logés dans les terminaux marchand (2) et agencés pour générer des premières requêtes de confirmation (R2) et une multiplicité de terminaux de paiement, formant premiers terminaux de paiement bancaire (4) appartenant aux banques des comptes marchand et raccordés à une multiplicité de seconds terminaux de paiement bancaire (5) appartenant aux banques des comptes d'acheteur et comportant des seconds moyens de génération (10) agencés pour transmettre au terminal de confirmation (11) une seconde requête de confirmation (R3) à réception d'une requête d'autorisation de transaction (A1) reçue d'un premier terminal bancaire (4), et les seconds moyens de génération (10) de second terminal bancaire (5) étant agencés pour transmettre au premier terminal bancaire (4) concerné une autorisation de transaction à réception d'une seconde confirmation de transaction (C3).
36. Installation selon l'une des revendications 26 et 27, caractérisée en ce qu'elle comprend des premiers moyens de génération (10) logés dans un terminal intermédiaire (13) raccordé aux terminaux marchand (2) et à une multiplicité de terminaux de paiement (3,4, 5), ainsi qu'au terminal de confirmation (11), et agencés pour générer des premières requêtes de confirmation (R2), chaque terminal de paiement étant un premier terminal de paiement bancaire (4) appartenant aux banques des comptes marchand et étant raccordé à une multiplicité de seconds terminaux de paiement bancaire (5) appartenant aux banques des comptes d'acheteurs et comportant des seconds moyens de
<Desc/Clms Page number 35>
génération (10) agencés pour transmettre au terminal de confirmation (11) une seconde requête de confirmation (R3) à réception d'une requête d'autorisation de transaction (RI) reçue d'un premier terminal bancaire (4), et les seconds moyens de génération (10) de second terminal bancaire (5) étant agencés pour transmettre au premier terminal bancaire (4) concerné une autorisation de transaction à réception d'une seconde confirmation de transaction (C3), et en ce que les premiers moyens de génération (10) du terminal intermédiaire (13) sont en outre agencés pour transmettre l'autorisation de transaction finale (AF) au terminal marchand (2) concerné en cas de réception de la première confirmation (C2) et de l'autorisation de transaction (A1) émanant d'un premier terminal bancaire (4).
37. Installation selon l'une des revendications 26 à 36, caractérisée en ce que certains au moins des identifiants secondaires sont associés à des supports (8).
38. Installation selon l'une des revendications 26 à 37, caractérisée en ce que l'un au moins des terminaux, choisis parmi le terminal de confirmation (11) et les terminaux de paiement (3,4) et seconds terminaux bancaires (5), munis de moyens de génération (10), comporte ladite table de correspondance.
39. Installation selon l'une des revendications 26 à 38, caractérisée en ce que l'un au moins des terminaux choisis parmi le terminal de confirmation, le terminal de paiement (3) et les seconds terminaux bancaires (5) est agencé pour gérer la table de correspondance.
40. Installation selon l'une des revendications 26 à 39, caractérisée en ce que la sélection et l'identifiant secondaire (PANS) représentatif d'un identifiant primaire (PAN) sont accompagnés d'une information spécifiant que l'identifiant de traitement est répertorié dans ladite table de correspondance, ladite information étant communiquée au terminal concerné, équipé de moyens de génération (10).
41. Installation selon l'une des revendications 26 à 40, caractérisée en ce que les moyens de génération (10) sont agencés pour placer dans les requêtes de confirmation (R2, R3) des identifiants de traitement sous la forme de numéros d'abonné (NA) résultant d'une conversion des identifiants secondaires reçuc (PANS) à l'aide d'une fonction de conversion.
<Desc/Clms Page number 36>
42. Installation selon l'une des revendications 26 à 41, caractérisée en ce que l'un au moins des terminaux (2, 3, 4, 5, 13), équipés de moyens de génération de requête de confirmation (R2, R3), comprend une liste représentative des identifiants de traitement contenus dans ladite table de correspondance.
43. Installation selon la combinaison des revendications 41 et 42, caractérisé en ce que chaque terminal équipé de moyens de génération de requête de confirmation (2,3, 4,5, 13) comporte des moyens de conversion (12) agencés pour appliquer à un identifiant secondaire reçu la fonction de conversion de manière à le transformer en numéro d'abonné (NA), puis à comparer ce numéro à ceux stockés dans la liste.
44. Installation selon l'une des revendications 41 et 42, caractérisée en ce que chaque terminal équipé de moyens de génération de requête de confirmation (2,3, 4,5, 13) comporte des moyens de conversion (12) agencés pour appliquer à un identifiant secondaire reçu la fonction de conversion de manière à le transformer en numéro d'abonné (NA), de sorte qu'il soit communiqué dans la requête de confirmation (R2, R3) au terminal de confirmation 11 pour que ledit terminal de confirmation (11) détermine dans la table de correspondance l'identifiant auxiliaire (via) associé.
45. Installation selon l'une des revendications 41 à 44, caractérisée en ce que ladite fonction de conversion est de type dit irréversible, sans collision .
46. Installation selon l'une des revendications 41 à 45, dans laquelle l'identifiant secondaire (PANS) comporte au moins un identifiant de banque ou de groupe de banques d'acheteur (IIN) et un identifiant de compte (MN), caractérisée en ce que ladite fonction de conversion est appliquée à l'identifiant secondaire (PANS) pour obtenir en sortie un résultat destiné à être concaténé à l'identifiant de banque ou de groupe de banques d'acheteur (UN) de manière à former ledit numéro d'abonné (NA).
47. Installation selon l'une des revendications 41 à 46, caractérisée en ce que chaque numéro d'abonné (NA) est intégré dans ladite liste après une certification de sa correspondance avec un identifiant secondaire (PANS).
48. Installation selon l'une des revendications 26 à 40, caractérisée en ce que chaque requête de confirmation (R2, R3) est une copie de la requête
<Desc/Clms Page number 37>
d'autorisation (R1), comportant un identifiant de traitement sensiblement identique à l'identifiant secondaire (PANS) reçu.
49. Installation selon l'une des revendications 26 à 48, caractérisée en ce que chaque dispositif communiquant (9) est agencé pour transmettre au terminal de confirmation (11) une confirmation de transaction comportant un code secret alphanumérique.
50. Installation selon l'une des revendications 26 à 49, caractérisée en ce qu'elle comprend un serveur téléphonique raccordé au terminal de confirmation (11), l'acheteur transmettant la confirmation de transaction au terminal de confirmation (11) via ledit serveur téléphonique.
51. Installation selon l'une des revendications 26 à 50, caractérisée en ce qu'elle comprend une multiplicité de terminaux d'acheteur (1) comportant des moyens de saisie raccordés, via ledit réseau, auxdits terminaux marchand (2) et agencés pour permettre à un acheteur de sélectionner les objets et/ou services proposés par le terminal marchand (2) et à saisir l'identifiant secondaire (PANS) représentatif de son identifiant primaire (PAN).
52. Dispositif électronique communiquant, caractérisé en ce qu'il comprend une touche dédiée propre à transmettre une confirmation de transaction prédéfinie dans une installation et un procédé selon l'une des revendications précédentes, en cas d'actionnement.
53. Dispositif selon la revendication 52, caractérisé en ce qu'il assure la fonction de terminal d'acheteur (1).
54. Dispositif selon l'une des revendications 52 et 53, caractérisé en ce qu'il est de type radiotéléphone (9).
55. Dispositif selon la revendication 54, caractérisé en ce qu'il fonctionne selon un mode choisi dans un groupe comprenant le GSM et l'UMTS
56. Dispositif selon l'une des revendications 54 et 55, caractérisé en ce qu'il est muni d'une carte SIM.
57. Dispositif selon la revendication 56, caractérisé en ce que la carte SIM comporte un module agencé pour stocker le code secret.
58. Utilisation de l'installation, du dispositif et du procédé selon l'une des revendications précédentes, dans des transactions via un réseau de communication public de type Internet, lesdits terminaux marchands (2) constituant des sites web.
FR0100018A 2001-01-02 2001-01-02 Procede et installation de securisation de transactions a distance par confirmation de transaction Pending FR2819127A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0100018A FR2819127A1 (fr) 2001-01-02 2001-01-02 Procede et installation de securisation de transactions a distance par confirmation de transaction

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0100018A FR2819127A1 (fr) 2001-01-02 2001-01-02 Procede et installation de securisation de transactions a distance par confirmation de transaction

Publications (1)

Publication Number Publication Date
FR2819127A1 true FR2819127A1 (fr) 2002-07-05

Family

ID=8858476

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0100018A Pending FR2819127A1 (fr) 2001-01-02 2001-01-02 Procede et installation de securisation de transactions a distance par confirmation de transaction

Country Status (1)

Country Link
FR (1) FR2819127A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200126080A1 (en) * 2008-02-20 2020-04-23 Collective Dynamics LLC Method and System for Multi-Modal Transaction Authentication
US11816665B2 (en) 2008-02-20 2023-11-14 Stripe, Inc. Method and system for multi-modal transaction authentication

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996013814A1 (fr) * 1994-10-28 1996-05-09 Behruz Vazvan Systeme de telepaiement en temps reel
EP0745961A2 (fr) * 1995-05-31 1996-12-04 AT&T IPM Corp. Système d'autorisation et d'alarme pour transactions
US5757917A (en) * 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
WO2000014662A1 (fr) * 1998-09-04 2000-03-16 Fortoak Limited Systeme de passation de commande
US6088683A (en) * 1996-08-21 2000-07-11 Jalili; Reza Secure purchase transaction method using telephone number
FR2790162A1 (fr) * 1999-02-19 2000-08-25 France Telecom Procede de telepaiement et systeme pour la mise en oeuvre de ce procede
FR2792143A1 (fr) 1999-04-12 2000-10-13 Sarl Smart Design Procede et systeme de securisation de l'utilisation de cartes comportant des moyens d'identification et/ou d'authentification

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996013814A1 (fr) * 1994-10-28 1996-05-09 Behruz Vazvan Systeme de telepaiement en temps reel
EP0745961A2 (fr) * 1995-05-31 1996-12-04 AT&T IPM Corp. Système d'autorisation et d'alarme pour transactions
US5757917A (en) * 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
US6088683A (en) * 1996-08-21 2000-07-11 Jalili; Reza Secure purchase transaction method using telephone number
WO2000014662A1 (fr) * 1998-09-04 2000-03-16 Fortoak Limited Systeme de passation de commande
FR2790162A1 (fr) * 1999-02-19 2000-08-25 France Telecom Procede de telepaiement et systeme pour la mise en oeuvre de ce procede
FR2792143A1 (fr) 1999-04-12 2000-10-13 Sarl Smart Design Procede et systeme de securisation de l'utilisation de cartes comportant des moyens d'identification et/ou d'authentification

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200126080A1 (en) * 2008-02-20 2020-04-23 Collective Dynamics LLC Method and System for Multi-Modal Transaction Authentication
US11501298B2 (en) * 2008-02-20 2022-11-15 Stripe, Inc. Method and system for multi-modal transaction authentication
US11816665B2 (en) 2008-02-20 2023-11-14 Stripe, Inc. Method and system for multi-modal transaction authentication

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é
FR2820853A1 (fr) Procede et systeme de telepaiement
EP1110186B1 (fr) Procede de paiement electronique
WO2009027607A2 (fr) Procede et systeme de fourniture de services
JP2004507000A (ja) Wapにより資金記憶装置から電子的な金額を伝送するための方法及び装置
EP1323140B1 (fr) Procede pour fournir des donnees d&#39;identification d&#39;une carte de paiement a un usager
FR2816736A1 (fr) Procede et installation de securisation de l&#39;utilisation de supports associes a des identifiants et a des dispositifs electroniques
FR2819127A1 (fr) Procede et installation de securisation de transactions a distance par confirmation de transaction
JP2004523814A (ja) 資金記憶装置から電子的な金額を伝送する方法及び装置
FR2867650A1 (fr) Procede et terminaux communicants pour l&#39;identification d&#39;eligibilite d&#39;un utilisateur par un code a barres
FR2829647A1 (fr) Procede et systeme permettant a un utilisateur d&#39;authentifier une transaction relative a l&#39;acquisition de biens ou de services, au moyen d&#39;un terminal nomade
EP1490851A1 (fr) Procede et systeme de securisation d un paiement par carte d e credit
EP2800072A2 (fr) Procédé de délivrance par un automate de cartes de téléphonie mobile SIM à abonnement prépayé ou postpayé
FR2828966A1 (fr) Procede pour communiquer de facon securisee des donnees d&#39;identification d&#39;une carte de paiement
WO2003007251A1 (fr) Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre
CA2325895C (fr) Procede de paiement securise
WO2002075674A2 (fr) Systeme et methode de renouvellement de donnees d&#39;identification sur un dispositif de transaction portatif
BE1019350A3 (fr) Usage d&#39;une carte d&#39;identite electronique en tant que carte d&#39;affiliation.
CN117501263A (zh) 用于集成身份提供商的方法和系统
FR2818778A1 (fr) Procede et systeme de paiement, et equipements de telecommunications mis en oeuvre dans ce systeme
WO2001089148A2 (fr) Installation perfectionnee d&#39;echange de donnees dans un reseau, et carte de paiement et procede associes
FR2976385A1 (fr) Procede pour definir une transaction a effectuer au moyen d&#39;un serveur
FR2827724A1 (fr) Procede d&#39;inscription d&#39;un acheteur aupres d&#39;un serveur de paiement et procede de telepaiement fonde sur cette inscription
FR3033915A1 (fr) Systeme de paiement de factures externalise et procedes associes