FR2830100A1 - Systeme de paiement securise entre particuliers permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi public - Google Patents

Systeme de paiement securise entre particuliers permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi public Download PDF

Info

Publication number
FR2830100A1
FR2830100A1 FR0112268A FR0112268A FR2830100A1 FR 2830100 A1 FR2830100 A1 FR 2830100A1 FR 0112268 A FR0112268 A FR 0112268A FR 0112268 A FR0112268 A FR 0112268A FR 2830100 A1 FR2830100 A1 FR 2830100A1
Authority
FR
France
Prior art keywords
party
debtor
creditor
transaction
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR0112268A
Other languages
English (en)
Inventor
Philippe Agnelli
Roger Reynier
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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to FR0112268A priority Critical patent/FR2830100A1/fr
Publication of FR2830100A1 publication Critical patent/FR2830100A1/fr
Withdrawn 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/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction

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

Méthode de paiement électronique entre deux utilisateurs, à travers un réseau quasi-public, en utilisant des informations personnelles préalablement enregistrées auprès d'une Tierce Partie, et un code de confirmation choisi au hasard par cette Tierce Partie. L'un des deux utilisateurs sera appelé " Créancier " et l'autre " Débiteur ". Les deux uthsateurs sont enregistrés par la Tierce Partie qui est aussi capable d'identifier les deux utilisateurs. Quand le Débiteur veut acquitter sa dette auprès du Créancier, le Débiteur contacte la Tierce Partie par le réseau quasi-public en demandant d'initialiser une transaction. La Tierce Partie (1) se met en relation avec le Débiteur pour qu'il s'identifie lui même avec la clé personnelle d'identification qui lui a été donnée au moment où il s'est enregistré auprès de la Tierce Partie; (2) demande au Débiteur la somme, le mode de paiement et l'identifiant du Créancier; (3) vérifie que le paiement est possible; (4) envoie au Débiteur un code de confirmation sur un appareil possédé par le Débiteur; le code de confirmation est modifié par le Débiteur selon une méthode préenregistrée, et est renvoyé par le Débiteur à la Tierce Partie; (5) vérifie la validité du code de confirmation renvoyé par le Débiteur; (6) envoie au Créancier l'information du paiement proposé et un code de confirmation sur un appareil possédé par le Créancier; le code de confirmation est modifié par le Créancier selon une méthode préenregistrée, et est renvoyé par le Créancier à la Tierce Partie; (7) vérifie la validité du code de confirmation renvoyé par le Créancier. Quand ces étapes du processus se terminent de façon réussie, la Tierce Partie donne au Créancier et au Débiteur l'information que la transaction est réussie et terminée. Une méthode alternative est aussi décrite, dans laquelle le Créancier n'est pas initialement enregistré auprès de la Tierce Partie.Une autre variante est aussi décrite, dans laquelle la transaction est initiée par le Créancier. Une autre variante est aussi décrite, dans laquelle un utilisateur peut faire des opérations de débit ou crédit entre ses différents comptes enregistrés auprès de la Tierce Partie. Une autre variante est aussi décrite, dans laquelle le code de confirmation est envoyé par courrier au Débiteur et / ou au Créancier.

Description

<Desc/Clms Page number 1>
Description de l'état de l'art Différents systèmes utilisent le réseau public et quasi-public pour permettre le paiement entre un Débiteur et un Créancier.
1.1 Interface avec le système bancaire La Tierce Partie propose un ensemble de logiciels qui vont permettre au Débiteur et au Créancier d'effectuer le transfert de fonds via le système bancaire en place, en utilisant leur téléphone portable. Dans une première étape, un compte Débiteur est créé chez la Tierce Partie via un formulaire rempli par le Débiteur et renvoyé par courrier ou courriel à la Tierce Partie. L'information relative au compte est stockée sur un serveur appartenant à la Tierce Partie et possède un identifiant et un mot de passe.
Lorsqu'une décision d'achat est prise, le Créancier envoie à la Tierce Partie un message qui contient le numéro de téléphone portable ou l'identifiant du Débiteur et le montant de la transaction, via la réseau téléphonique. La Tierce Partie envoie au Débiteur un message lui demandant de confirmer la transaction. Le Débiteur doit alors indiquer identifiant et le mot de passe correspondant à son compte Débiteur dans un message renvoyé à la Tierce Partie. Une fois l'identification confirmée par la Tierce Partie, celle ci effectue le transfert de monnaie entre les comptes bancaires du Débiteur et du Créancier.
1.2 Création d'argent électronique Le souhait est de mettre en place un système de monnaie entièrement électronique pour lequel des Banques pourraient offrir une parité avec la monnaie classique.
La marche à suivre est la suivante. Il faut ouvrir un compte dans une"Banque digitale"sur l'Internet, et l'approvisionner. Pendant la phase expérimentale, les comptes se voient automatiquement attribuer une somme de monnaie électronique. Ensuite le Débiteur peut faire des retraits de la Banque et obtenir de la monnaie électronique. Cette monnaie est représentée par des suites de nombres, l'équivalent de pièces de monnaie. Ces nombres sont générés par des algorithmes mathématiques sophistiqués. Chaque nombre contient la somme
Figure img00010001

représentée, la signature de l'émetteur (la Banque) et une partie de l'identifiant du compte du Débiteur, le tout crypté avec un sceau confidentiel. Chaque nombre ne peut être généré qu'une fois. Cette monnaie digitale, stockée sur le disque dur du Débiteur, peut être échangée tout comme de l'argent liquide avec n'importe qui.
Cela réalise la non-traçabilité des échanges financiers. Néanmoins des mécanismes de protection complexes permettent en théorie d'interdire tout usage abusif du système.
1.3 Transfert d'identifiant de carte de crédit sur l'Internet C'est un système de transmission cryptée du numéro de cartes de crédit via l'Internet. Le logiciel serveur du Créancier reçoit un numéro de carte de crédit crypté qu'il utilise ensuite pour effectuer une transaction classique avec un centre de traitement. L'étape suivante consistera à installer le centre de paiement directement sur l'Internet.
1.4 Installation de lecteur de carte de crédit Ce système permet de valider les transactions électroniques avec un lecteur de carte de crédit utilisé comme terminal de paiement.. Le Débiteur se procure ce lecteur gratuitement ou à titre onéreux. Au moment du paiement des achats effectués via le réseau quasi public, le Débiteur indique qu'il possède un terminal de paiement, insère sa carte de crédit dans le lecteur et tape son code personnel. Ce dispositif nécessite l'utilisation de carte de crédit à puce ; le coût du terminal de paiement doit être supporté par le Débiteur ou sa banque.
<Desc/Clms Page number 2>
1.5 Téléphone mobile a lecteur de carte intégré Le Débiteur se procure un appareil téléphonique muni d'un lecteur de carte de crédit utilisé comme terminal de paiement. Au moment du paiement, le Débiteur indique qu'il possède un terminal de paiement, insère sa carte de crédit dans le lecteur et tape son code personnel. L'appareil téléphonique fonctionne alors en terminal de paiement. Ce dispositif nécessite l'utilisation de carte de crédit à puce ; le coût du téléphone à terminal de paiement doit être supporté par le Débiteur, sa banque, ou son opérateur de télécommunications.
1.6 Téléphone mobile à carte intégrée Le Débiteur se procure un appareil téléphonique muni d'un circuit électronique intégré sur lequel sont enregistrés des informations bancaires protégées par une clé connue du Débiteur seul. L'appareil téléphonique peut alors fonctionner comme terminal de paiement.
1.7 Paiement électronique sur internet Débiteur et Créditeur ont ouvert un compte auprès d'une Tierce Partie et ont initialement alimenté ce compte par chèque ou carte de crédit. Ils possèdent un accès à leur compte sécurisé par mot de passe et leur identification se fait par une adresse courriel. Ensuite les transactions se font en donnant des ordres de transfert, protégés par mot de passe, entre les comptes, en se connectant à la Tierce Partie par le réseau quasi-public.
Brève Description des figures Figure 1 est un diagramme schématique des parties principales du système contenant la présente invention.
Figure 2 est un diagramme schématique montrant les modules principaux utilisés dans l'invention.
Les Figures 3 à 10 décrivent les séquences et le mécanisme de sécurité du processus de paiement suivant la présente invention.
Sommaire de l'invention
Figure img00020001

Pour le commerce électronique, l'invention permet de réaliser de façon sécurisée les transactions financières entre Débiteur et Créancier, en résolvant le problème de l'envoi d'information personnelle et commerciale sur un réseau ouvert à la fraude.
Pour le Débiteur, l'invention résout le problème des faux sites Créanciers, elle supprime le risque d'avoir des données financières privées capturées lorsqu'elles transitent sur le réseau quasi public, elle fournit la sécurité en cas de vol de la clé personnelle d'identification et en cas de vol de l'appareil personnel, en cas de vol simultané de la clé personnelle d'identification et de l'appareil personnel, le système reste inviolable sans l'algorithme personnalisé par le Débiteur. L'invention permet au Débiteur de s'identifier vis à vis du Créancier, et assure le Débiteur que l'identité du Créancier n'a pas été usurpée.
Pour le Créancier l'invention permet de formellement accepter d'être crédité d'une somme, et supprime le
Figure img00020002

risque de recevoir des informations financières qui auraient été obtenues frauduleusement, elle certifie que le paiement des biens et des services sera effectué.
L'invention montre un agent Tierce Partie qui peut stocker l'identité des personnes (Créanciers et Débiteurs) qui se sont enregistrées auprès de la Tierce Partie ; La Tierce Partie s'est enregistrée elle même auprès des Banques, et préférablement auprès d'une ou plusieurs compagnies de télécommunications. La Tierce Partie peut offrir aussi l'ouverture de comptes de monnaie électronique à ses clients. Les Débiteurs et les Créanciers doivent être inscrits auprès de la compagnie de télécommunication qui leur a donné une adresse pour les appareils personnels 15 et 25 ; ils doivent aussi être enregistrés auprès de la Tierce Partie qui leur donne une clé personnelle
<Desc/Clms Page number 3>
d'identification PIK ; ils conviennent avec la Tierce Partie d'un algorithme AG ; ils ont aussi une façon d'accéder au réseau quasi public.
Description détaillée du dispositif préféré- Dispositif 1 Selon la figure 1, la présente invention inclut l'échange d'informations entre un Débiteur qui peut se connecter à un réseau quasi public à travers un terminal 10, un Créancier qui peut se connecter à un réseau quasi public à travers un terminal 20, un centre Tierce Partie 30, un appareil personnel 15 possédé par le Débiteur, un appareil personnel 25 possédé par le Créancier, une compagnie de télécommunications 60 (appelée Telco par abréviation) capable de présenter des messages à l'appareil 15 et à l'appareil 25, une Banque 50.
Si l'appareil personnel 15 est capable d'être connecté au réseau quasi public en même temps qu'il est connecté au réseau téléphonique, il peut être considéré comme deux unités logiques différentes : l'une est le terminal 15 et l'autre est le terminal 10, ces deux unités logiques étant capables de fonctionner indépendamment et/ou simultanément. Il en est de même pour 20 et 25.
La description détaillée de l'invention est donnée en faisant référence à la figure 2 et aux figures 3,4 et 5.
Dans l'opération 201 le Débiteur ouvre une session 101 entre le terminal (ou l'unité logique) 10 et le serveur d'information 30a de la Tierce Partie 30 via le réseau quasi public.
Dans l'opération 202 le serveur d'information 30a répond par une demande d'identification de l'opération demandée. Dans l'opération 203 le Débiteur précise qu'il veut effectuer un paiement, et le serveur d'information 30a répond dans l'opération 204 en envoyant un formulaire permettant à l'utilisateur du terminal 10 de s'identifier en utilisant sa clé personnelle d'identification PIK (PIK est composé au moins d'un identifiant et d'un mot de passe, ou bien c'est un type de signature électronique qui peut être envoyé avec le terminal 10) ; PIK a été établi au moment où le Débiteur s'est enregistré auprès de la Tierce Partie ou ensuite lors d'une mise à jour. La clé d'identification personnelle PIK constitue le premier niveau de sécurité pour le Débiteur.
L'utilisateur du terminal 10 reçoit la demande à l'étape 205 et donne la clé PIK personnelle à l'étape 206.
Dans l'opération 207 le serveur d'information 30a utilise la base de données 30c via le serveur de données 30b pour valider la clé d'identification reçue du terminal 10. Si la clé est validée, l'utilisateur du terminal 10 est considéré comme étant en possession du PIK d'un des clients enregistrés auprès de la Tierce Partie.
Dans l'opération 208 la Tierce Partie utilise l'information reçue en 207 et l'information stockée dans la base de données 30c pour établir un formulaire contenant les différents modes de paiement à la disposition du Débiteur ; ces différents modes de paiement avaient été communiqués à la Tierce Partie par le Débiteur, au moment de l'enregistrement ou ensuite lors d'une mise à jour, grâce à un moyen sécurisé qui ne fait pas partie de l'invention. Le formulaire demande aussi les informations relatives au contenu de la transaction (identifiant du Créancier, montant). Le serveur de données 30b attribue aussi dans l'opération 208 un numéro de transaction TC, valide pour cette transaction seulement, et qui servira à référencer évènements et données pour la durée de cette transaction aussi bien du coté du Créancier que du Débiteur, de la Banque et de la Compagnie de télécommunications, et sera utilisé pour la synchronisation des transactions par la Tierce Partie. Le numéro de transaction TC est généré de façon unique par la Tierce Partie selon une formule secrète qui lui est propre. Le numéro de transaction TC est joint au formulaire.
Dans l'opération 209 le formulaire est envoyé au terminal 10, et le serveur d'information 30a reste en attente de la réponse sur le mode de paiement, et les autres informations demandées.
Dans l'opération 210 l'utilisateur du terminal 10 sélectionne le mode de paiement parmi ceux qui sont proposés,
<Desc/Clms Page number 4>
et fournit les informations qui viennent de lui être demandées. Comme identification du Créancier, le Débiteur utilise un identifiant ID que le Créancier lui a communiqué, et que le Créancier a déposé auprès de la Tierce Partie au moment de son enregistrement ou ensuite lors d'une mise à jour, grâce à un moyen sécurisé qui ne fait pas partie de l'invention. Cet identifiant ID peut être, par exemple, le numéro d'appel de l'appareil 25.
Dans l'opération 211 le Débiteur renvoie au serveur d'information 30a l'identifiant du Créancier, la somme, le mode de paiement, et TC.
Dans l'opération 212 le serveur d'information 30a, qui a reçu du terminal 10 les informations sur le mode de paiement, démarre dans l'opération 212 une requête d'autorisation de paiement auprès de l'établissement bancaire dans le but de valider la transaction avec le Créancier, via le module d'interface bancaire 30d, le lien sécurisé 104 et le système bancaire 50a. La base de données 30c du serveur d'information 30a contient des informations relatives au Créancier qui peuvent être retrouvées grâce à l'identifiant reçu à l'étape 211, permettant à la Tierce Partie de faire des opérations bancaires au nom du Créancier. Ces informations ont été enregistrées au moment où le Créancier s'est enregistré auprès de la Tierce Partie. L'échange d'informations entre le module d'interface bancaire 30d et le système bancaire 50a se fait suivant le protocole d'échange interbancaire. Le module d'interface bancaire 30d envoie aussi au système bancaire 50a le montant de la facture, l'information sur le mode de paiement et sur le compte du Débiteur à débiter qui avait été préalablement stockée dans la base de données 30c.
Dans l'opération 213 le système bancaire 50a utilise les données reçues en 212, des données préalablement enregistrées permettant d'identifier la Tierce Partie en tant que partenaire de la Banque, et ses propres données relatives au Débiteur, pour établir l'autorisation de paiement qui sera renvoyée au module d'interface bancaire 30d dans l'opération 214. La Tierce Partie est enregistrée auprès de l'établissement bancaire pour que la Tierce Partie soit reconnue comme un partenaire de cet établissement.
Dans l'opération 215 le module d'interface bancaire 30d reçoit du système bancaire 50a l'autorisation de paiement et l'envoie au serveur d'information 30a.
Dans l'opération 216 le serveur d'information 30a va utiliser la base de données 30c via le serveur de données 30b pour initier la vérification de l'authenticité et la validité du Débiteur 10. Le serveur d'information 30a prépare un message au Débiteur contenant au moins un code de confirmation CCA généré de façon unique pour chaque transaction, l'identité du Créancier, le montant de la transaction et le numéro de transaction TC. Ce code de confirmation CCA constitue le deuxième niveau de sécurité pour le Débiteur, car il va permettre de confirmer l'identité du Débiteur comme possédant l'appareil 15.
Le serveur 30a cherche aussi dans la base de données 30c le numéro de référence RN qui identifie le Débiteur pour la compagnie de télécommunication (ce numéro de référence donné par la compagnie de télécommunication 60 à la Tierce Partie 30 est de préférence différent du numéro d'adresse téléphonique pour maintenir l'anonymat entre Tierce Partie et compagnie de téléphone, mais ce n'est pas obligatoire, pour tenir compte de cas particuliers tels que téléphone connecté à des compagnies autres que Telco 60). La Tierce Partie s'est enregistrée auprès de la compagnie de télécommunication pour que la Tierce Partie (1) possède un numéro de référence RN du Débiteur, et (2) puisse envoyer des messages au Débiteur à travers le réseau de télécommunications de la Telco 60.
Le message avec ce numéro de référence RN est envoyé à la compagnie de télécommunication par le module d'interface telco 30e vers l'interface telco 60a via le lien sécurisé 106.
Dans l'opération 217 l'interface telco 60a. convertit le numéro de référence RN en une adresse de
<Desc/Clms Page number 5>
Figure img00050001

télécommunication, utilisant la base de données 60d via le serveur de données 60c.
Dans l'opération 218 le message est envoyé à l'appareil 15 par le serveur de messages 60b en utilisant un canal de communication spécialement ouvert à cette occasion.
Dans l'opération 219 le Débiteur prend connaissance sur son appareil 15 du message qui lui a été envoyé à l'étape 216. L'appareil 15 doit avoir été utilisé, et le Débiteur a lu le code de confirmation CCA contenu dans le message. Cela constitue le deuxième niveau de sécurité pour le Débiteur.
Dans l'opération 220 le Débiteur utilise le terminal 10 pour entrer manuellement le code de confirmation modifié CCA1 : cette modification du code de confirmation CCA est réalisé par un algorithme AGA sur lequel le Débiteur et la Tierce Partie se sont mis d'accord au moment de l'enregistrement ou ensuite lors d'une mise à jour (grâce à un moyen sécurisé qui ne fait pas partie de l'invention) et que le Débiteur peut mémoriser.
L'algorithme AGA de modification du code de confirmation CCA n'est connu que du Débiteur et de la Tierce Partie, et il est de la responsabilité du Débiteur de garder cette information confidentielle. L'algorithme AGA constitue le troisième niveau de sécurité pour le Débiteur.
Dans l'opération 221 le serveur d'information 30a vérifie que le code CCA1 envoyé par le terminal 10 correspond au code de validation CCA selon les règles préétablies dans l'algorithme AGA. L'identité du Débiteur est maintenant confirmée pour la Tierce Partie : La transaction peut continuer.
Dans l'opération 222 le serveur d'information 30a prépare un message au Créancier contenant au moins un code de confirmation CCB généré de façon unique pour chaque transaction, l'identité du Débiteur, le montant de la transaction, l'adresse intemet de la Tierce Partie et le numéro de transaction TC.
Le serveur 30a cherche aussi dans la base de données 30c le numéro de référence RN qui identifie l'appareil 25 du Créancier pour la compagnie de télécommunication (ce numéro de référence donné par la compagnie de télécommunication 60 à la Tierce Partie 30 est de préférence différent du numéro d'adresse téléphonique pour maintenir l'anonymat entre Tierce Partie et compagnie de téléphone, mais ce n'est pas obligatoire, pour tenir compte de cas particuliers tels que téléphone connecté à des compagnies autres que Telco 60). La Tierce Partie s'est enregistrée auprès de la compagnie de télécommunication pour que la Tierce Partie (1) possède un numéro de référence RN du Créancier, et (2) puisse envoyer des messages au Créancier à travers le réseau de télécommunications de la Telco 60.
Le message avec ce numéro de référence RN est envoyé à la compagnie de télécommunication par le module d'interface telco 30e vers l'interface telco 60a..
Dans l'opération 223 l'interface telco 60a. convertit le numéro de référence RN en une adresse de télécommunication de l'appareil 25, utilisant la base de données 60d via le serveur de données 60c.
Dans l'opération 224 le message est envoyé à l'appareil 25 par le serveur de messages 60b en utilisant un canal de communication spécialement ouvert à cette occasion.
Dans l'opération 225 le Créancier prend connaissance sur son appareil 25 du message qui lui a été envoyé à l'étape 216. Cela constitue le quatrième niveau de sécurité pour le Débiteur, car il va permettre de confirmer l'identité du Créancier comme possédant réellement l'appareil 25.
Dans l'opération 226 l'appareil 25 doit avoir été utilisé, et le Créancier a lu le code de confirmation CCB contenu dans le message.
Dans l'opération 227 le Créancier ouvre une session avec la Tierce Partie par le terminal 20.
Dans l'opération 228 le serveur d'information 30a répond par une demande d'identification de l'opération demandée.
<Desc/Clms Page number 6>
Dans l'opération 229 le Créancier précise qu'il veut effectuer un encaissement, et le serveur d'information 30a répond dans l'opération 230 en envoyant un formulaire permettant à l'utilisateur du terminal 20 de s'identifier en utilisant sa clé personnelle d'identification PIK (PIK est composé au moins d'un identifiant et d'un mot de passe, ou bien c'est un type de signature électronique qui peut être envoyé avec le terminal 20) ; PIK a été établi au moment où le Débiteur s'est enregistré auprès de la Tierce Partie ou ensuite lors d'une mise à jour. La clé d'identification personnelle PIK constitue le premier niveau de sécurité pour le Créancier. Le formulaire demande aussi le code de confirmation, le compte à créditer et le numéro de transaction TC.
Dans l'opération 231 l'utilisateur du terminal 20 reçoit la demande et donne la clé PIK personnelle. Ensuite le Créancier utilise le terminal 20 pour entrer manuellement le code de confirmation modifié CCB1 : cette modification du code de confirmation CCB est réalisé par un algorithme AGB sur lequel le Créancier et la Tierce Partie se sont mis d'accord au moment de l'enregistrement ou ensuite lors d'une mise à jour (grâce à un moyen sécurisé qui ne fait pas partie de l'invention) et que le Créancier peut mémoriser. L'algorithme AGB de modification du code de confirmation CCB n'est connu que du Créancier et de la Tierce Partie, et il est de la responsabilité du Créancier de garder cette information confidentielle. L'algorithme AGB constitue le cinquième niveau de sécurité pour le Débiteur. Il constitue un deuxième niveau de sécurité pour le Créancier, dans l'acceptation de la transaction. Le Créancier indique ensuite quel compte est à créditer et donne TC.
Dans l'opération 232 le serveur d'information 30a utilise la base de données 30c via le serveur de données 30b pour valider la clé d'identification PIK reçue du terminal 20. Si la clé est validée, l'utilisateur du terminal 20 est considéré comme étant en possession du PIK d'un des clients enregistrés auprès de la Tierce Partie. Le serveur d'information 30a vérifie que le code CCB1 envoyé par le terminal 20 correspond au code de validation CCB selon les règles préétablies dans l'algorithme AGB. L'identité du Créancier est maintenant confirmée pour la Tierce Partie : La transaction peut continuer.
Dans l'opération 233 le serveur d'information 30a utilise les résultats des étapes 230 et 232 pour réaliser complètement la transaction : la Tierce Partie notifie la Banque d'effectuer le transfert de fonds entre les comptes du Débiteur et du Créancier dans l'opération 234.
Dans l'opération 235 le serveur d'information 30a prépare un message au Créancier via le terminal 20 contenant au moins le résumé de la transaction, l'identité du Débiteur, le montant de la transaction et le numéro de transaction TC.
Il est à noter que durant les opérations 201 à 235 aucune information financière autre que la somme définie par le Débiteur n'est échangée sur le réseau quasi public, c'est à dire du début à la fin du processus. De même aucune information financière relative au Débiteur n'est communiquée au Créancier et vice-versa.
L'opération 207 valide PIK qui constitue le premier niveau de sécurité pour le Débiteur ; l'opération 216 prépare un message contenant le code de confirmation CCA qui constitue le deuxième niveau de sécurité pour le
Débiteur, car il va être reçu sur un appareil possédé par le Débiteur et va permettre de confirmer l'identité du
Débiteur comme possédant l'appareil 15 ; l'opération 221 valide CCA1 qui correspond au code de validation
CCA selon les règles préétablies dans l'algorithme AGA et constitue le troisième niveau de sécurité pour le
Débiteur en garantissant l'identité du Débiteur ; l'opération 222 prépare un message contenant le code de confirmation CCB qui constitue le quatrième niveau de sécurité pour le Débiteur, car il va être reçu sur un appareil possédé par le Créancier et va permettre de confirmer l'identité du Créancier comme possédant l'appareil 25 ; l'opération 232 valide CCB1 qui correspond au code de validation CCB selon les règles préétablies dans l'algorithme AGB et constitue le cinquième niveau de sécurité pour le Débiteur en
<Desc/Clms Page number 7>
garantissant l'identité du Créancier.
Deux des cinq niveaux de sécurité peuvent être dérobés sans que la sécurité de la transaction soit affectée.
Toute anomalie détectée durant les opérations 207,221 et 232 sur PIK, CCAI et CCB1, est détectée et enregistrée par la Tierce Partie et rapportée au Débiteur. Toute anomalie détectée sur l'opération 232 est enregistrée par la Tierce Partie et rapportée au Créancier.
Autre dispositif possible de l'invention- Dispositif 2 Cet autre dispositif de l'invention décrit le cas où le Créancier n'est pas encore connu de la Tierce Partie.
Pour le Débiteur, les opérations décrites dans les figures 3,4 et 5 sont inchangées pour les opérations 201 à 229.
La suite des opérations est décrite dans la figure 6.
Dans l'opération 250 il est précisé que la transaction peut continuer même si le Créancier n'est pas encore enregistré auprès de la Tierce Partie, que la somme sera créditée à un compte temporaire dont le nom est donné au Créancier à condition qu'il s'enregistre auprès de la tierce partie, et CCB et TC sont demandés. Il est aussi proposé de refuser la transaction.
Dans l'opération 251 le Créancier donne CCB et TC. Si le Créancier ne veut pas continuer, il le notifie à la Tierce Partie dans l'opération 260.
En cas de refus par le Créancier lors de l'opération 260, dans l'opération 261 la Tierce Partie bloque la transaction et notifie la banque ; dans l'opération 262 la banque annule la transaction en cours ; dans les opérations 263 et 264 le Créancier est informé de l'annulation de la transaction ; dans les opérations 265,266, 267,268 la Tierce Partie envoie vers l'appareil personnel 15 du Débiteur un message indiquant que la transaction est refusée par le Créancier.
Si le Créancier accepte la transaction, dans l'opération 252 la Tierce Partie crée le compte temporaire référencé par CCB et TC et l'adresse de l'appareil 25, et se prépare à le créditer de la somme correspondant à la transaction. Dans l'opération 253 la Tierce Partie présente un formulaire d'inscription que le Créancier remplit dans l'opération 254.
Dans l'opération 255 le serveur d'information 30a transmet au serveur de données 30b les informations d'enregistrement du Créancier ; une clé d'identification personnelle PIK est attribuée au Créancier par le serveur de données 30b, et l'ensemble des informations est enregistré dans la base de données 30c. Le serveur d'information 30a transmet PIK au terminal 20.
Dans l'opération 256 le serveur d'information 30a utilise les résultats des étapes 252 et 255 pour réaliser complètement la transaction : la Tierce Partie notifie la Banque d'effectuer le transfert de fonds entre les comptes du Débiteur et du Créancier dans l'opération 257.
Dans l'opération 258 le serveur d'information 30a prépare un message au Créancier via le terminal 20 contenant au moins le résumé de la transaction, l'identité du Débiteur, le montant de la transaction et le numéro de transaction TC, le numéro de compte temporaire, et notification que les données relatives à son enregistrement auprès de la Tierce Partie lui seront transmises par une voie séparée.
Autre dispositif possible de l'invention- Dispositif 3 Un autre dispositif de l'invention fait initier la transaction par le Créancier. La suite des opérations est décrite avec référence aux figures 7,8, 9 et 10.
Les étapes 301 à 306 sont conduites par le Créancier, en utilisant l'unité logique 20 ; à l'étape 303 le Créancier
<Desc/Clms Page number 8>
indique qu'il veut recouvrer une somme due, et il s'identifie par son PIK à l'étape 306.
Dans l'opération 307 le serveur d'information 30a utilise la base de données 30c via le serveur de données 30b pour valider la clé d'identification reçue du terminal 20. Si la clé est validée, l'utilisateur du terminal 20 est considéré comme étant en possession du PIK d'un des clients enregistrés auprès de la Tierce Partie.
Dans l'opération 308 la Tierce Partie utilise l'information reçue en 307 et l'information stockée dans la base de données 30c pour établir un formulaire contenant : une demande d'identification du Débiteur, le montant de la transaction, le compte à créditer, et un numéro de transaction TC. Le numéro de transaction TC est généré de façon unique par la Tierce Partie selon une formule secrète qui lui est propre, est valide pour cette transaction seulement, servira à référencer évènements et données pour la durée de cette transaction aussi bien du coté du Créancier que du Débiteur, de la Banque et de la Compagnie de télécommunications, et sera utilisé pour la synchronisation des transactions par la Tierce Partie.
Dans l'opération 309 le formulaire est envoyé au terminal 20, et le serveur d'information 30a reste en attente de la réponse sur les informations demandées.
Dans l'opération 310 l'utilisateur du terminal 20 fournit les informations qui viennent de lui être demandées. Comme identification du Débiteur, le Créancier utilise un identifiant ID que le Débiteur lui a communiqué, et que le Débiteur a déposé auprès de la Tierce Partie au moment de son enregistrement ou ensuite lors d'une mise à jour, grâce à un moyen sécurisé qui ne fait pas partie de l'invention. Cet identifiant ID peut être, par exemple, le numéro d'appel de l'appareil 15.
Dans l'opération 311 le serveur d'information 30a analyse l'identifiant du Débiteur, la somme, le compte à créditer, et TC.
Dans l'opération 316 le serveur d'information 30a va utiliser la base de données 30c via le serveur de données 30b pour initier la vérification de l'authenticité et la validité du Créancier. Le serveur d'information 30a prépare un message au Créancier contenant au moins un code de confirmation CCB généré de façon unique pour chaque transaction, l'identité du Débiteur, le montant de la transaction et le numéro de transaction TC. Ce code de
Figure img00080001

confirmation CCB constitue le deuxième niveau de sécurité pour le Créancier, car il va permettre de confirmer l'identité du Créancier comme possédant l'appareil 25.
Le serveur 30a cherche aussi dans la base de données 30c le numéro de référence RN qui identifie le Créancier pour la compagnie de télécommunication (ce numéro de référence donné par la compagnie de télécommunication 60 à la Tierce Partie 30 est de préférence différent du numéro d'adresse téléphonique pour maintenir l'anonymat entre Tierce Partie et compagnie de téléphone, mais ce n'est pas obligatoire, pour tenir compte de cas particuliers tels que téléphone connecté à des compagnies autres que Telco 60). La Tierce Partie s'est enregistrée auprès de la compagnie de télécommunication pour que la Tierce Partie (1) possède un numéro de référence RN du Créancier, et (2) puisse envoyer des messages au Créancier à travers le réseau de télécommunications de la Telco 60.
Le message avec ce numéro de référence RN est envoyé à la compagnie de télécommunication par le module d'interface telco 30e vers l'interface telco 60a..
Dans l'opération 317 l'interface telco 60a. convertit le numéro de référence RN en une adresse de télécommunication, utilisant la base de données 60d via le serveur de données 60c.
Dans l'opération 318 le message est envoyé à l'appareil 25 par le serveur de messages 60b en utilisant un canal de communication spécialement ouvert à cette occasion.
Dans l'opération 319 le Créancier prend connaissance sur son appareil 25 du message qui lui a été envoyé à
<Desc/Clms Page number 9>
Figure img00090001

l'étape 316. L'appareil 25 doit avoir été utilisé, et le Créancier a lu le code de confirmation CCB contenu dans le message. Cela constitue le deuxième niveau de sécurité pour le Créancier.
Dans l'opération 320 le Créancier utilise le terminal 20 pour entrer manuellement le code de confirmation modifié CCB1 : cette modification du code de confirmation CCB est réalisé par un algorithme AGB sur lequel le Créancier et la Tierce Partie se sont mis d'accord au moment de l'enregistrement ou ensuite lors d'une mise à jour (grâce à un moyen sécurisé qui ne fait pas partie de l'invention) et que le Créancier peut mémoriser.
L'algorithme AGB de modification du code de confirmation CCB n'est connu que du Créancier et de la Tierce Partie, et il est de la responsabilité du Créancier de garder cette information confidentielle. L'algorithme AGB constitue le troisième niveau de sécurité pour le Créancier.
Dans l'opération 321 le serveur d'information 30a vérifie que le code CCB1 envoyé par le terminal 20 correspond au code de validation CCB selon les règles préétablies dans l'algorithme AGB. L'identité du Créancier est maintenant confirmée pour la Tierce Partie : La transaction peut continuer.
Dans l'opération 322 le serveur d'information 30a prépare un message au Débiteur contenant au moins un code de confirmation CCA généré de façon unique pour chaque transaction, l'identité du Créancier, le montant de la transaction, l'adresse interne ! de la Tierce Partie et le numéro de transaction TC.
Le serveur 30a cherche aussi dans la base de données 30c le numéro de référence RN qui identifie l'appareil 15 du Débiteur pour la compagnie de télécommunication (ce numéro de référence donné par la compagnie de télécommunication 60 à la Tierce Partie 30 est de préférence différent du numéro d'adresse téléphonique pour maintenir l'anonymat entre Tierce Partie et compagnie de téléphone, mais ce n'est pas obligatoire, pour tenir compte de cas particuliers tels que téléphone connecté à des compagnies autres que Telco 60).. La Tierce Partie s'est enregistrée auprès de la compagnie de télécommunication pour que la Tierce Partie (1) possède un numéro de référence RN du Débiteur, et (2) puisse envoyer des messages au Débiteur à travers le réseau de télécommunications de la Telco 60.
Le message avec ce numéro de référence RN est envoyé à la compagnie de télécommunication par le module d'interface telco 30e vers l'interface telco 60a..
Dans l'opération 323 l'interface telco 60a. convertit le numéro de référence RN en une adresse de télécommunication de l'appareil 15, utilisant la base de données 60d via le serveur de données 60c.
Dans l'opération 324 le message est envoyé à l'appareil 15 par le serveur de messages 60b en utilisant un canal de communication spécialement ouvert à cette occasion.
Dans l'opération 325 le Débiteur prend connaissance sur son appareil 15 du message qui lui a été envoyé à l'étape 322. Cela constitue le quatrième niveau de sécurité pour le Créancier, car il va permettre de confirmer l'identité du Débiteur comme possédant réellement l'appareil 15.
Dans l'opération 326 l'appareil 15 doit avoir été utilisé, et le Débiteur a lu le code de confirmation CCA contenu dans le message.
Dans l'opération 327 le Débiteur ouvre une session avec la Tierce Partie par le terminal 10.
Dans l'opération 328 le serveur d'information 30a répond par une demande d'identification de l'opération demandée.
Dans l'opération 329 le Débiteur précise qu'il veut effectuer un paiement, et le serveur d'information 30a répond dans l'opération 330 en envoyant un formulaire permettant à l'utilisateur du terminal 0 de s'identifier en utilisant sa clé personnelle d'identification PIK (PIK est composé au moins d'un identifiant et d'un mot de passe, ou bien c'est un type de signature électronique qui peut être envoyé avec le terminal 20) ; PIK a été établi
<Desc/Clms Page number 10>
au moment où le Débiteur s'est enregistré auprès de la Tierce Partie ou ensuite lors d'une mise à jour. La clé d'identification personnelle PIK constitue le premier niveau de sécurité pour le Débiteur. Le formulaire demande aussi le code de confirmation et le compte à débiter et le numéro de transaction TC.
Dans l'opération 331 l'utilisateur du terminal 10 reçoit la demande et donne la clé PIK personnelle. Ensuite le Débiteur utilise le terminal 10 pour entrer manuellement le code de confirmation modifié CCA1 : cette modification du code de confirmation CCA est réalisé par un algorithme AGA sur lequel le Débiteur et la Tierce Partie se sont mis d'accord au moment de l'enregistrement ou ensuite lors d'une mise à jour (grâce à un moyen sécurisé qui ne fait pas partie de l'invention) et que le Débiteur peut mémoriser. L'algorithme AGA de modification du code de confirmation CCA n'est connu que du Débiteur et de la Tierce Partie, et il est de la responsabilité du Débiteur de garder cette information confidentielle. L'algorithme AGA constitue le cinquième niveau de sécurité pour le Créancier. Il constitue un deuxième niveau de sécurité pour le Débiteur, dans l'acceptation de la transaction. Le Débiteur indique ensuite quel compte est à débiter et donne TC.
Dans l'opération 332 le serveur d'information 30a utilise la base de données 30c via le serveur de données 30b pour valider la clé d'identification reçue du terminal 10. Si la clé est validée, l'utilisateur du terminal 10 est considéré comme étant en possession du PIK d'un des clients enregistrés auprès de la Tierce Partie. Le serveur d'information 30a vérifie que le code CCA1 envoyé par le terminal 10 correspond au code de validation CCA selon les règles préétablies dans l'algorithme AGA. L'identité du Débiteur est maintenant confirmée pour la Tierce Partie : La transaction peut continuer.
Dans l'opération 333 le serveur d'information 30a utilise les résultats des étapes 330 et 332 pour réaliser complètement la transaction : la Tierce Partie notifie la Banque d'effectuer le transfert de fonds entre les comptes du Débiteur et du Créancier dans l'opération 334.
Dans l'opération 335 le serveur d'information 30a prépare un message au Débiteur via le terminal 10 contenant au moins le résumé de la transaction, l'identité du Créancier, le montant de la transaction et le numéro de transaction TC.
I1 est à noter que durant les opérations 301 à 335 aucune information financière autre que la somme définie par le Créancier n'est échangée sur le réseau quasi public, c'est à dire du début à la fin du processus. De même aucune information financière relative au Débiteur n'est communiquée au Créancier et vice-versa.
Autre dispositif possible de l'invention- Dispositif 4 L'invention peut être utilisée pour sécuriser des opérations financières menées à distance par un usager enregistré auprès de la Tierce Partie, et qui a défini auprès d'elle les types de transactions valides. L'utilisateur peut faire des opérations de débit ou crédit entre ses différents comptes enregistrés auprès de la Tierce Partie.
Ces transactions peuvent inclure ou non l'intervention de l'établissement bancaire 50, suivant que les comptes impliqués dans la transaction sont des comptes bancaires ou un compte bancaire et un compte de monnaie électronique. L'usager prend successivement les rôles de Débiteur ou de Créancier, le terminal 20 est remplacé par le terminal 10, L'appareil personnel 25 est remplacé par l'appareil 15.
Depuis le réseau quasi public le Débiteur peut lancer des opérations entre ses différents comptes et la sécurité sera obtenue par l'utilisation des clés PIK, AK et CCA1 et par l'utilisation de l'appareil personnel 15 et du terminal 10.
Selon les figures 3,4 et 5, les opérations commencent à l'étape 201. Les étapes 201 à 221 sont inchangées, sauf
<Desc/Clms Page number 11>
qu'à l'étape 216 le l'appareil personnel 15 est choisi à la place de l'appareil personnel 25. Les étapes 222 à 232 sont omises. Les étapes 233 à 236 sont ensuite effectuées ; l'opération 235 se fait vers le terminal 10.
Autre dispositif possible de l'invention- Dispositif 5 Pour effectuer la vérification de l'authenticité et la validité du Débiteur 10, le code de confirmation CCA généré de façon unique pour chaque transaction est envoyé au Débiteur par courriel (courrier électronique). Le débiteur en prend connaissance, par le terminal 10 renvoie le code de confirmation modifié CCA1 : cette modification du code de confirmation CCA est réalisé par un algorithme AGA sur lequel le Débiteur et la Tierce Partie se sont mis d'accord au moment de l'enregistrement ou ensuite lors d'une mise à jour (grâce à un moyen sécurisé qui ne fait pas partie de l'invention) et que le Débiteur peut mémoriser.
Pour effectuer la vérification de l'authenticité et la validité du Créancier 20, le code de confirmation CCB généré de façon unique pour chaque transaction est envoyé au Créancier par courriel (courrier électronique). Le Créancier en prend connaissance, par le terminal 20 renvoie le code de confirmation modifié CCB1 : cette modification du code de confirmation CCB est réalisé par un algorithme AGB sur lequel le Créancier et la Tierce Partie se sont mis d'accord au moment de l'enregistrement ou ensuite lors d'une mise à jour (grâce à un moyen sécurisé qui ne fait pas partie de l'invention) et que le Créancier peut mémoriser.
Le reste des opérations se fait comme dans les dispositifs décrits précédemment.

Claims (13)

Revendications
1) Système de paiement permettant de ne pas divulguer d'information bancaire sur le réseau public et quasi- public, caractérisé en ce qu'il comporte une clé d'identification personnelle PIK un code de confirmation CC - un algorithme de transformation AG un code de confirmation CC1 issue de la transformation de CC par l'algorithme AG un numéro de transaction TC une base de données 30c un numéro de référence RN un Créancier, un Débiteur, une Tierce Partie, un établissement bancaire, une société de télécommunication
2) Système de paiement selon la revendication (1) caractérisé en ce que la clé d'identification personnelle PIK, composée au moins d'un identifiant et d'un mot de passe, a été établie au moment où le Débiteur (ou le Créancier) s'est enregistré auprès de la Tierce Partie ou ensuite lors d'une mise à jour, au moment de s'identifier, l'utilisateur donne la clé PIK personnelle au serveur d'information 30a et celui ci utilise la base de données 30c via le serveur de données 30b pour valider la clé d'identification reçue.
3) Système selon la revendication (1) caractérisé en ce que le code de confirmation CCA est généré par le serveur d'information 30a de la Tierce Partie de façon unique pour chaque transaction, - le code de confirmation CCA est envoyé à l'appareil personnel 15 possédé par le Débiteur par le serveur de messages 60b en utilisant un canal de communication spécialement ouvert à cette occasion, le Débiteur envoie à la Tierce Partie un code CCA1 résultat de la transformation du CCA par l'algorithme AGA la Tierce Partie vérifie que le code CCA1 envoyé par le terminal 10 correspond au code de validation
CCA selon les règles préétablies dans l'algorithme AGA, avant de valider définitivement la transaction.
4) Système selon la revendication (1) caractérisé en ce que - le code de confirmation CCB est généré par le serveur d'information 30a de la Tierce Partie de façon unique pour chaque transaction, le code de confirmation CCB est envoyé à l'appareil personnel 25 possédé par le Créancier par le serveur de messages 60b en utilisant un canal de communication spécialement ouvert à cette occasion, le Créancier envoie à la Tierce Partie un code CCB1 résultat de la transformation du CCB par l'algorithme AGB - la Tierce Partie vérifie que le code CCB1 envoyé correspond au code de validation CCB selon les règles préétablies dans l'algorithme AGB, avant de valider définitivement la transaction
5) Système selon la revendication (1) caractérisé en ce que
Il y a un algorithme de transformation AGB sur lequel le Créancier et la Tierce Partie se sont mis d'accord au moment de l'enregistrement ou ensuite lors d'une mise à jour
<Desc/Clms Page number 13>
1 l'algorithme de transformation AGB n'est connu que du Créancier et de la Tierce Partie, et il est de la responsabilité du Créancier de garder cette information confidentielle.
Figure img00130001
6) Système selon la revendication (1) caractérisé en ce que II y a un algorithme de transformation AGA sur lequel le Débiteur et la Tierce Partie se sont mis d'accord au moment de l'enregistrement ou ensuite lors d'une mise à jour l'algorithme de transformation AGA n'est connu que du Débiteur et de la Tierce Partie, et il est de la responsabilité du Débiteur de garder cette information confidentielle.
7) Système selon la revendication (1) caractérisé en ce que - le numéro de transaction TC est généré de façon unique par la Tierce Partie selon une formule secrète qui lui est propre.
Débiteur s'est enregistré auprès de la Tierce Partie.
La base de données 30c de la Tierce Partie contient des informations relatives au Débiteur qui permettent à la Tierce Partie d'identifier celui ci. Ces informations ont été enregistrées au moment où le
Le numéro de transaction TC servira à référencer évènements et données pour la durée de cette transaction aussi bien du coté du Créancier que du Débiteur, de la Banque et de la Compagnie de télécommunications, et sera utilisé pour la synchronisation des transactions par la Tierce Partie
8) Système selon la revendication (1) caractérisé en ce que
La base de données 30c de la Tierce Partie contient des informations relatives au Débiteur, permettant à la Tierce Partie de faire des opérations bancaires au nom du Débiteur. Ces informations ont été enregistrées au moment où le Débiteur s'est enregistré auprès de la Tierce Partie.
La Tierce Partie est enregistrée auprès de l'établissement bancaire pour que la Tierce Partie soit reconnue comme un partenaire de cet établissement.
Débiteur à travers le réseau de télécommunications.
Partie (1) possède un numéro de référence RN du Débiteur, et (2) puisse envoyer des messages au
La Tierce Partie s'est enregistrée auprès de la compagnie de télécommunication pour que la Tierce
9) Système selon la revendication (1) caractérisé en ce que
La base de données 30c de la Tierce Partie contient des informations relatives au Créancier qui permettent à la Tierce Partie d'identifier celui ci. Ces informations ont été enregistrées au moment où le
Créancier s'est enregistré auprès de la Tierce Partie.
La base de données 30c de la Tierce Partie contient des informations relatives au Créancier, permettant à la Tierce Partie de faire des opérations bancaires au nom du Créancier. Ces informations ont été enregistrées au moment où le Créancier s'est enregistré auprès de la Tierce Partie.
La Tierce Partie est enregistrée auprès de l'établissement bancaire pour que la Tierce Partie soit reconnue comme un partenaire de cet établissement.
Créancier à travers le réseau de télécommunications.
Partie (1) possède un numéro de référence RN du Créancier, et (2) puisse envoyer des messages au
La Tierce Partie s'est enregistrée auprès de la compagnie de télécommunication pour que la Tierce
10) Système selon la revendication (1) caractérisé en ce que aucune information financière autre que la somme définie n'est échangée sur le réseau quasi public aucune information financière relative au Débiteur n'est communiquée au Créancier et vice-versa
11) Système selon la revendication (1) caractérisé en ce que la Tierce Partie
<Desc/Clms Page number 14>
Tierce Partie par le Débiteur, au moment de l'enregistrement ou ensuite lors d'une mise à jour envoie l'information de validation de la transaction au Débiteur.
Créancier. Les différents modes de paiement à la disposition du Débiteur avaient été communiqués à la
lt utilise les informations stockées dans sa base de données et relatives au Débiteur pour demander une autorisation de paiement auprès de l'établissement bancaire dans le but de valider la transaction avec le
Figure img00140001
12) Système selon la revendication (1) caractérisé en ce qu'il quintuple la sécurité pour le Débiteur par les moyens suivants : - la clé personnelle d'identification PIK, - le code de confirmation CCA reçu sur un appareil possédé par le Débiteur - le code de confirmation CCA modifié par le Débiteur selon l'algorithme AGA de modification du code de confirmation déposé auprès de la Tierce Partie et mémorisé par le Débiteur, le code de confirmation CCB reçu sur un appareil possédé par le Créancier le code de confirmation modifié CCB1 : cette modification du code de confirmation CCB est réalisé par un algorithme AGB sur lequel le Créancier et la Tierce Partie se sont mis d'accord au moment de l'enregistrement et que le Créancier peut mémoriser.
Deux des cinq niveaux de sécurité peuvent être dérobés sans que la sécurité de la transaction soit affectée.
- Toute anomalie détectée sur PIK, CCA1 et CCB1 est détectée et enregistrée par la Tierce Partie et rapportée au Débiteur.
13) Système selon la revendication (1) caractérisé en ce qu'il garantit la véracité de l'identité du Créancier, par les moyens suivants : - L'identifiant PIK du Créancier, le code de confirmation CCB reçu sur un appareil possédé par le Créancier, le code de confirmation modifié CCB1, modifié par le Créancier selon l'algorithme AGB de modification du code de confirmation déposé auprès de la Tierce Partie et mémorisé par le Créancier. deux des trois niveaux de sécurité ci-dessus peuvent être dérobés sans que la sécurité de la transaction soit affectée, - Toute anomalie détectée sur chacun des niveaux de sécurité est détectée et enregistrée par la Tierce
Partie et rapportée au Créancier.
FR0112268A 2001-09-24 2001-09-24 Systeme de paiement securise entre particuliers permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi public Withdrawn FR2830100A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0112268A FR2830100A1 (fr) 2001-09-24 2001-09-24 Systeme de paiement securise entre particuliers permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi public

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0112268A FR2830100A1 (fr) 2001-09-24 2001-09-24 Systeme de paiement securise entre particuliers permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi public

Publications (1)

Publication Number Publication Date
FR2830100A1 true FR2830100A1 (fr) 2003-03-28

Family

ID=8867546

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0112268A Withdrawn FR2830100A1 (fr) 2001-09-24 2001-09-24 Systeme de paiement securise entre particuliers permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi public

Country Status (1)

Country Link
FR (1) FR2830100A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1995927A1 (fr) 2007-05-24 2008-11-26 Alcatel Lucent Procédé, dispositif de transfert et modules pour l'authentification d'un utilisateur dans une application commerciale sur Internet

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996000485A2 (fr) * 1994-06-24 1996-01-04 Telefonaktiebolaget Lm Ericsson Procede et appareil d'authentification d'un utilisateur
WO1998040809A2 (fr) * 1997-03-13 1998-09-17 Cha! Technologies, Inc. Procede et systeme de traitement protege de transaction en direct
WO1999023617A2 (fr) * 1997-11-04 1999-05-14 Gilles Kremer Procede de transmission d'information et serveur le mettant en oeuvre
WO2000033271A2 (fr) * 1998-12-02 2000-06-08 Gary Shkedy Procede et appareil permettant de faciliter des ordres d'achat emis par un acheteur dans un systeme de reseau commercial

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1996000485A2 (fr) * 1994-06-24 1996-01-04 Telefonaktiebolaget Lm Ericsson Procede et appareil d'authentification d'un utilisateur
WO1998040809A2 (fr) * 1997-03-13 1998-09-17 Cha! Technologies, Inc. Procede et systeme de traitement protege de transaction en direct
WO1999023617A2 (fr) * 1997-11-04 1999-05-14 Gilles Kremer Procede de transmission d'information et serveur le mettant en oeuvre
WO2000033271A2 (fr) * 1998-12-02 2000-06-08 Gary Shkedy Procede et appareil permettant de faciliter des ordres d'achat emis par un acheteur dans un systeme de reseau commercial

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1995927A1 (fr) 2007-05-24 2008-11-26 Alcatel Lucent Procédé, dispositif de transfert et modules pour l'authentification d'un utilisateur dans une application commerciale sur Internet

Similar Documents

Publication Publication Date Title
US8285648B2 (en) System and method for verifying a user&#39;s identity in electronic transactions
JP5575935B2 (ja) 金融手段を確認するためのシステムおよび方法
EP1014317B1 (fr) Procédé de paiement sécurisé
RU2452020C2 (ru) Способ осуществления платежей (варианты) и система для осуществления способа
US20030061163A1 (en) Method and apparatus for verification/authorization by credit or debit card owner of use of card concurrently with merchant transaction
US20090070263A1 (en) Peer to peer fund transfer
US20070005467A1 (en) System and method for carrying out a financial transaction
US20060173776A1 (en) A Method of Authentication
US20090319425A1 (en) Mobile Person-to-Person Payment System
JP2005524184A (ja) 電気通信事業者の金融取引サービスを可能にするシステムおよびそのような取引を実施する方法
KR20030019466A (ko) 정보의 안전한 수집, 기억, 전송 방법 및 장치
CA2324114A1 (fr) Procede d&#39;utilisation d&#39;une carte telephonique pour des transactions commerciales
JP2004523021A (ja) 預金メモリから電子マネーを送金するための方法及び装置
JP2004506997A (ja) 資金メモリから電子的な金額を伝送する方法および装置
US20020156728A1 (en) Method and arrangement for the transmission of an electronic sum of money from a credit reserve by wap
WO2001073706A1 (fr) Systeme de paiement permettant de ne pas divulguer d&#39;information bancaire sur le reseau public et quasi-public
EP4074005A1 (fr) Procede, serveur et systeme d&#39;authentification de transaction utilisant deux canaux de communication
FR2830100A1 (fr) Systeme de paiement securise entre particuliers permettant de ne pas divulguer d&#39;information bancaire sur le reseau public et quasi public
WO2001098955A1 (fr) Système de paiement protégé par mot de passe secondaire
CA2325895C (fr) Procede de paiement securise
RU2351984C2 (ru) Способ снятия денежных средств из банкомата без использования пластиковой карты посредством платежного поручения через службу смс
CN114026587A (zh) 通过区块链网络处理支付交易的系统及方法
WO2010085166A1 (fr) Système de fourniture de services à des abonnés de téléphones mobiles
EP1417656A1 (fr) Procede d&#39;inscription d&#39;un acheteur aupres d&#39;un serveur de paiement et procede de telepaiement fonde sur cette inscription
FR2912579A1 (fr) Procede de transfert securise via un reseau de communication d&#39;un flux monetaire, systeme de transfert et produit programme correspondants

Legal Events

Date Code Title Description
ST Notification of lapse