FR2807247A1 - Systeme de paiement permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi-public - Google Patents
Systeme de paiement permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi-public Download PDFInfo
- Publication number
- FR2807247A1 FR2807247A1 FR0003889A FR0003889A FR2807247A1 FR 2807247 A1 FR2807247 A1 FR 2807247A1 FR 0003889 A FR0003889 A FR 0003889A FR 0003889 A FR0003889 A FR 0003889A FR 2807247 A1 FR2807247 A1 FR 2807247A1
- Authority
- FR
- France
- Prior art keywords
- party
- buyer
- merchant
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (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. Les deux utilisateurs sont enregistrés par la Tierce Partie qui est aussi capable d'identifier les deux utilisateurs. L'un des deux utilisateurs sera appelé " Marchand " et l'autre " Acheteur ".Quand l'Acheteur a fait sa sélection des biens ou services auprès du Marchand, le Marchand contacte la Tierce Partie en demandant de valider la transaction. La Tierce Partie (1) se met en relation avec l'Acheteur 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) envoie à l'Acheteur un code de confirmation sur un appareil possédé par l'Acheteur; le code de confirmation est modifié par l'Acheteur selon une méthode pré-enregistrée, et est renvoyé par l'Acheteur à la Tierce Partie; (3) vérifie avec la Banque de l'Acheteur que le paiement est possible; et (4) vérifie la validité du code de confirmation renvoyé par l'Acheteur. Quand ces étapes du processus se terminent de façon réussie, la Tierce Partie donne au Marchand l'autorisation de confirmer la transaction.
Description
<I>Description de l'état de l'art</I> Différents systèmes utilisent le réseau public et quasi-public pour permettre le paiement entre un Acheteur et un Marchand.
<B>1.1</B> Interface avec le système bancaire La Tierce Partie propose un ensemble de logiciels qui vont permettre à l'Acheteur et au Marchand d'effectuer le transfert de fonds via le système bancaire en place. Un logiciel gratuit ou payant est distribué à tous les Acheteurs potentiels.
Dans une première étape , un compte Acheteur est créé chez la Tierce Partie via un formulaire rempli par l'Acheteur et renvoyé par courrier à 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. Lorsque le compte Acheteur est mis en place, il est possible d'y lier un certain nombre de cartes de crédit .
Lorsqu'une décision d'achat est prise, le serveur du Marchand envoie une demande de paiement à l'application de la Tierce Partie. Cette dernière active la deuxième étape . L'Acheteur doit alors indiquer l'identifiant et le mot de passe correspondant à son compte Acheteur . Une fois l'identification effectuée, l'Acheteur choisit le mode de paiement qu'il souhaite utiliser. Un message de paiement crypté est alors envoyé au serveur Tierce Partie. Ce dernier valide -ou non- la transaction avec la Banque, tout comme avec un lecteur de carte de crédit et retourne à l'Acheteur, en cas de succès, un message signé indiquant la réussite de la transaction. Ce message est ensuite retransmis de l'Acheteur vers le Marchand qui considère que l'achat est effectué ( dans un autre dispositif, le message est envoyé directement de la Tierce Partie au Marchand ). Pour que ce système se généralise, il faut que les systèmes bancaires acceptent les requêtes en provenance des Tierces Parties.
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. II 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 l'Acheteur 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 représentée, la signature de l'émetteur (la Banque) et une partie de l'identifiant du compte de l'Acheteur, 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 de l'Acheteur , 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 Marchand 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 Mise en place de boutiques électroniques clef en main La Tierce Partie offre une gamme de services particulièrement étendue permettant la mise en place de serveurs prenant en charge les transactions financières les plus diverses, les statistiques de consultations et d'achats, les prises de commandes et même la mise en place de véritables galeries commerciales. L'Acheteur peut fournir un identifiant de carte bancaire avec un logiciel spécifique pour crypter les données, et un logiciel sur le serveur du Marchand gère automatiquement la liaison avec des organismes de traitement bancaire partenaires pour obtenir les différentes autorisations et effectuer le virement.
1.5 Organisation de ventes de biens électroniques (informations, images, programmes ...) Ce système ne nécessite aucun logiciel spécifique ni le besoin de crypter des informations sensibles. Pour l'Acheteur , il suffit de posséder une adresse Courrier électronique individuelle, un navigateur internet et une carte de crédit. L'originalité du système réside dans le fait que les identifiants de cartes bancaires ne circuleront jamais sur le réseau. La demande de création de compte Acheteur par la Tierce Partie peut être faite travers le réseau quasi-public mais le numéro de carte bancaire est fourni par téléphone. Lorsque le compte Acheteur est créé, son identifiant est envoyé par Courrier électronique au propriétaire. Si un Acheteur veut acheter quelque chose sur un serveur, il fournit son nom et son identifiant. Le Marchand peut vérifier la validité du compte sur un serveur Tierce Partie destiné à cet effet. II envoie ensuite un message électronique à la Tierce Partie précisant l'identifiant de l'Acheteur le montant facturé. A la réception de la demande de facture, le serveur Tierce Partie retourne un Courrier électronique à l'Acheteur lui demandant d'accepter ou de refuser la transaction ou même de déclarer une fraude. Si la transaction est validée, la Tierce Partie s'occupe des virements entre comptes bancaires concernés par les moyens traditionnels.
1.6 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. L'Acheteur se procure ce lecteur gratuitement ou à titre onéreux. Au moment du paiement des achats effectués via le réseau quasi public, l'Acheteur indique qu'il possède un terminal de paiement, insère sa carte de crédit dans le lecteur et tape son code personnel.
1.7 Téléphone mobile a lecteur de carte intégré L'Acheteur se procure appareil téléphonique muni d'un lecteur de carte de crédit utilisé comme terminal de paiement. Au moment du paiement des achats effectués via le réseau quasi public, l'Acheteur 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. <I>Brève Description des figures</I> 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-1 à 2 décrivent les séquences et le mécanisme de sécurité du processus de paiement suivant la présente invention.
<I>Sommaire l'invention</I> Pour le commerce électronique, l'invention permet de résoudre le problème de l'envoi d'information personnelle ou commerciale un réseau ouvert à la fraude.
Pour l'Acheteur l'invention résout le problème des faux sites Marchands, 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 l'Acheteur. L'invention permet à l'Acheteur de rester anonyme vis à vis du Marchand, point important pour le respect des libertés individuelles liées au commerce en général.
Pour le Marchand l'invention supprime le 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 stocke l'identité des Marchands qui se sont enregistrés 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. Les Acheteurs doivent être inscrits auprès de la compagnie de télécommunication qui leur a donné une adresse téléphonique pour l'appareil personnel 40 - ils doivent aussi être enregistrés auprès de la Tierce Partie qui leur donne une clé personnelle d'identification , ils conviennent avec la Tierce Partie d'un algorithme AG ;ils ont aussi une façon d'accéder au réseau quasi public.
<B><I>Description détaillée du dispositif préféré</I></B> Selon la figure 1 , la présente invention inclut l'échange d'informations entre un Acheteur connecté à un reseau quasi public à travers un terminal 10, un site Marchand 20, un centre Tierce Partie 30, un appareil personnel 40 possédé par l'Acheteur, une compagnie de télécommunications ( appelée Telco par abréviation ) 60 capable de présenter des messages à l'appareil 40, une Banque 50.
Si l'appareil personnel 40 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 et l'autre est le terminal 10, ces deux unités logiques étant capables de fonctionner indépendamment et/ou simultanément.
La description détaillée de l'invention est donnée en faisant référence à la figure 2 et aux figures 3-1 et 3-2 . Dans l'opération 201 l'Acheteur à la recherche de biens ou de services ouvre une session 101 entre le terminal (ou l'unité logique) 10 et le serveur d'information 20a du Marchand via le réseau quasi public.
Le serveur d'information 20a attribue dans l'opération 202 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 Marchand que de l'Acheteur , de la Banque et de la Compagnie de télécommunications, et sera utilisé pour la synchronisation des transactions par la Tierce Partie. Le code de transaction TC est généré de façon unique par le Marchand selon une formule secrète prédéterminée entre le Marchand et la Tierce Partie. Dans l'opération 203 l'Acheteur utilise le terminal 10 pour sélectionner les biens ou services qui l'interessent . Dans l'opération 204 le serveur d'information du Marchand établit la liste des biens et/ou services sélectionnés par 1 `Acheteur, en utilisant ,par exemple, la base de données 20e à travers le serveur de données 20b.
Dans l'opération 205 l'Acheteur démarre la procédure d'établissement de la facture à partir du terminal 10.
Dans l'operation 206 le serveur d'information 20a prépare la note de paiement et propose à l'Acheteur un paiement sécuritaire via la Tierce Partie. Les informations pour contacter le Tierce Partie sont incluses lors de cet échange ainsi que le numéro de transaction TC .
Dans l'opération 207 l'Acheteur utilise le terminal 10 pour confirmer au Marchand qu'il désire utiliser le paiement ' la Tierce Partie. Lors de cette même opération, l'Acheteur initie une connexion avec la Tierce Partie à l'aide des informations fournies par le Marchand. Lors de cette connexion est aussi transmis a la Tierce Partie le numéro TC, pour permettre de retrouver la transaction Marchand correspondante.
Dans l'opération 208 le module de paiement 20d du Marchand (partie séparée ou non du serveur d'information 20a ) s'identifie, auprès du serveur d'information 30a de la Tierce Partie, comme partie intégrante du site du Marchand ; la méthode d'identification ne fait pas partie de l'invention, ce peut être un échange signatures électroniques, ou n'importe quelle méthode équivalente. La base de données 30c du serveur d'information 30a contient des informations relatives au Marchand qui permettent à la Tierce Partie d'identifier celui ci . Ces informations ont été enregistrées au moment où le Marchand s'est enregistré auprès de la Tierce Partie. Le module 20d envoie au serveur 30a pendant la session 101 l'adresse du terminal 10 , le contenu et le montant de la commande et le numéro de transaction TC.
Le serveur d'information 20a attend en état 212 que le serveur d'information 30a lui renvoie l'information que la transaction est valide.
Dans l'opération 209 le serveur d'information 30a utilise la base de données 30c via le serveur de données 30b pour vérifier l'authenticité et la validité du site Marchand 20.
Dans l'opération 210 le serveur d'information 30a utilise les informations reçues à l'étape 207 et 208 pour synchroniser les données entre le site du Marchand et le terminal 10 ; quand c `est fait, le serveur d'information 30a demande à l'utilisateur du terminal 10 de s'identifier en utilisant sa clé personnelle d'identification PIK (PIK est composé au moins d'un code d'identification 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ù l'Acheteur 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 l'Acheteur.
L'utilisateur du terminal 10 reçoit la demande à l'étape 211 et donne la clé PIK personnelle à l'étape 213. Dans l'opération 214 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 215 la Tierce Partie utilise l'information reçue en 208 et l'information stockée dans la base de données 30c pour établir un formulaire contenant les différents modes de paiement la disponibilité de l'Acheteur ; ces différents modes de paiement avaient été communiqués à la Tierce Partie par l'Acheteur, 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 peut être étendu pour montrer à nouveau les informations relatives au contenu de la transaction (nom du Marchand, montant, biens et services commandés, tous détails qui avaient été envoyés à l'étape 208) . Dans l'opération 215 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.
Dans l'opération<B>216</B> l'utilisateur du terminal 10 vérifie que les informations qui viennent de lui être envoyées sont correctes, sélectionne le mode de paiement parmi ceux qui sont proposés, et dans l'opération 217 renvoie ces informations au serveur d'information 30a.
Le serveur d'information 30a reçoit du terminal 10 les informations sur le mode de paiement et dans l'opération 219 démarre une requête d'autorisation de paiement auprès de la Banque , via le module d'interface bancaire 30d, le lien sécurisé 104 et le système bancaire 50a. La base de données<B>30e</B> du serveur d'information 30a contient des informations relatives au Marchand , permettant à la Tierce Partie de faire des opérations bancaires au nom du Marchand. . Ces informations ont été enregistrées au moment où le Marchand s'est enregistré auprès de la Tierce Partie. L'echange 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 d'Acheteur à débiter préalablement stockée dans la base de données 30c.
Dans l'opération 220 système bancaire 50a utilise les données reçues en 219, des données préalablement enregistrées permettant d'identifier la Tierce Partie en tant que client de la Banque, et ses propres données relatives à l'Acheteur, pour établir l'autorisation de paiement qui est renvoyée au module d'interface bancaire 30d dans l'opération 228. La Tierce Partie est enregistrée auprès de l'établissement bancaire pour que la Tierce Partie soit reconnue comme un client de cet établissement.
Dans l'opération 229 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 221 le serveur d'information 30a prépare un message à l'Acheteur contenant au moins un code de confirmation CC généré de façon unique pour chaque transaction, l'identité du Marchand, et le montant de la transaction. Ce code de confirmation CC constitue le deuxième niveau de sécurité pour l'Acheteur.
Le serveur 30 a cherche aussi dans la base de données 30c le numéro de référence RN qui identifie l'Acheteur 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) . . La Tierce Partie est s'enregistrée auprès de la compagnie de télécommunication pour que la Tierce Partie obtienne un numéro de référence RN de l'Acheteur et puisse envoyer des messages à l'Acheteur à travers le réseau de télécommunications. 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 222 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 223 le message est envoyé au terminal 40 par le serveur de messages 60b en utilisant un canal de communication spécialement ouvert à cette occasion Dans l'opération 225 le document de validation du paiement est préparé.
Dans l'opération 226 le serveur d'information 30a envoie au terminal 10 le document de validation de paiement et demande l'utilisateur du terminal 10 de lire le message arrivant sur l'appareil 40 et d'entrer le code de confirmation à partir de celui contenu dans le message.
Dans l'opération 224 l'Acheteur prend connaissance sur l'appareil 40 du message qui lui a été envoyé à l'étape 223.
Dans l'opération 227 l'utilisateur du terminal 10 doit avoir utilisé l'appareil 40 et lu code de confirmation CC contenu dans le message.
Dans l'opération 230 l'Acheteur utilise le terminal 10 pour entrer manuellement le code de confirmation modifié CC 1 : cette modification du code de confirmation est réalisé par un algorithme AG sur lequel l'Acheteur 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 l'Acheteur peut mémoriser. L'algorithme AG de modification du code de confirmation CC n'est connu que de l'Acheteur et de la Tierce Partie , et il est de la responsabilité de l'Acheteur de garder cette information confidentielle. L'algorithme AG constitue le troisième niveau de sécurité pour l'Acheteur.
Dans l'opération 231 le serveur d'information 30a vérifie que le code CC1 envoyé le terminal 10 correspond au code de validation CC selon les règles préétablies dans l'algorithme AG.
Dans l'opération 232 le serveur d'information 30a utilise les résultats des étapes 231 et 229 pour valider définitivement la transaction et 30a envoie l'information de validation de la transaction au serveur de paiement 20d et au serveur d'information 20a du Marchand via la session 101 sur le réseau quasi public .
Dans l'opération 233 le serveur d'information 20a reçoit l'information de validation de la transaction et l'utilise pour sortir de l'état d'attente 212 ; le serveur d'information 20a établit un sommaire de la transaction , avec en plus des informations additionnelles telles que méthode de livraison, date de livraison, adresse de livraison, et les envoie vers le terminal 10 dans l'opération 234.
Dans l'opération 235 l'Acheteur peut maintenant se déconnecter de la session 101.
Dans l'opération 236 le serveur d'information 20a envoie l'information de fermeture de la transaction au serveur d'information 30a via le module de paiement 20d et la session 101.
Dans l'opération 238 le serveur d'information 30a prépare un message de confirmation de fin de transaction contenant l'identité du Marchand, le montant de la transaction, et optionnellement d'autres données relatives à la transaction , associe le message au numéro de référence RN et envoie le tout vers l'interface telco 60a..
Dans l'opération 239 l'interface telco 60a convertit le numéro de référence RN en une adresse téléphonique, en utilisant la base de données 60d via le serveur de données 60c et le message est prêt être envoyé. Dans l'opération 240 le message est envoyé à l'appareil 40 par le serveur de messages 60b.
Dans l'opération 241 l'Acheteur reçoit l'information de fermeture de transaction contenue dans le message.
Dans l'opération 242 la Tierce Partie notifie la Banque d'effectuer le transfert de fonds entre les comptes de l'Acheteur et du Marchand.
Il est à noter que durant les opérations 201 à 242 aucune information financière 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 à l'Acheteur n'est communiquée au Marchand.
L'opération 214 valide PIK qui constitue le premier niveau de sécurité pour l'Acheteur; l'opération 221 crée le code de confirmation CC qui constitue le deuxième niveau de sécurité pour l'Acheteur ; l'opération 231 valide CC1 qui correspond au code validation CC selon les règles préétablies dans l'algorithme AG. Deux des trois 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 2l4 et 231 sur chacun des trois niveaux de sécurité est détectée et enregistrée par la Tierce Partie rapportée à .l'Acheteur.
<I>Autre dispositif</I> possible<I>de l'invention- 1</I> Un autre dispositif de l'invention peut omettre les étapes 238 à 241 <I>Autre dispositif possible de l'invention- 2</I> L'invention peut être utilisée pour sécuriser des opérations menées à distance par l'Acheteur vers son propre site Marchand.
Dans ce cas l'Acheteur possède un site Marchand personnel utilisé pour faire des opérations définies par l'Acheteur. L'Acheteur a enregistré son site Marchand auprès de la Tierce Partie , et a défini auprès d'elle les types de transactions valides. transactions peuvent inclure ou non l'intervention de l'établissement bancaire 50.
Depuis le réseau quasi public l'Acheteur peut lancer des opérations sur son site Marchand et la sécurité sera obtenue par l'utilisation des clés PIK, AK et CC 1 et par l'utilisation de l'appareil personnel 40.
Les étapes 203 à 208 sont modifiées pour devenir des étapes pendant lesquelles l'Acheteur prépare la transaction qu'il désire effectuer. Les étapes 215 à 218 sont aussi modifiées pour tenir compte du type de transaction choisi par l'Acheteur. Les étapes<B>219,</B> 220, 228, 229 , 242 existent ou non selon le type de transaction défini par l'Acheteur au moment de l'enregistrement auprès de la Tierce Partie. Les autres étapes sont inchangées.
Claims (9)
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 PK1 - un code de confirmation CC - un algorithme de transformation AG - un code de confirmation CC 1 issue de la transformation de CC par l'algorithme AG - un code de transaction TC - une base de données 30c - un numéro de référence RN - un Marchand, un Acheteur, une Tierce Partie, un établissement bancaire, une société télécommunication
2) Système de paiement selon la revendication (1) caractérisé en ce que - la clé d'identification personnelle PIK est composée au moins d'un code d'identification et d'un mot de passe, - la clé d'identification personnelle PIK a été établie au moment où l'Acheteur 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 qui 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 CC 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 CC est envoyé à l'appareil personnel 40 possédé par l'Acheteur par le serveur de messages 60b en utilisant un canal de communication spécialement ouvert à cette occasion, - l'Acheteur envoie à la Tierce Partie un code CC1 résultat de la transformation du CC par l'algorithme AG - la Tierce Partie vérifie que le code CC l envoyé par le terminal 10 correspond au code de validation CC selon les règles préétablies dans l'algorithme AG, avant de valider définitivement transaction.
4) Système selon la revendication (1) caractérisé en ce que - II y a un algorithme de transformation AG sur lequel l'Acheteur et la Tierce Partie se sont d'accord au moment de l'enregistrement ou ensuite lors d'une mise à jour - l'algorithme de transformation AG n'est connu que de l'Acheteur et de la Tierce Partie , et il est la responsabilité de l'Acheteur de garder cette information confidentielle.
5) Système selon la revendication (1) caractérisé en ce que - le code de transaction TC est généré de façon unique par le Marchand selon une formule prédéterminée entre le Marchand et la Tierce Partie, - le code de transaction TC est transmis par le Marchand au serveur 30a de la Tierce Partie - le code de transaction TC est transmis par le Marchand à l'Acheteur qui le retransmet à son tour à la Tierce Partie lors de la connexion, - numéro de transaction TC , qui servira à référencer évènements et données pour la durée de cette transaction aussi bien du coté du Marchand que de l'Acheteur , de la Banque et de la Compagnie de télécommunications, et sera utilisé pour la synchronisation des transactions par la Tierce Partie
6) 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 Marchand permettent à la Tierce Partie d'identifier celui ci . Ces informations ont été enregistrées au moment où le Marchand s'est enregistré auprès de la Tierce Partie. - La base de données 30c de la Tierce Partie contient des informations relatives au Marchand permettant à la Tierce Partie de faire des opérations bancaires au nom du Marchand. Ces informations ont été enregistrées au moment où le Marchand 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 client de cet établissement. - La Tierce Partie est enregistrée auprès d'une compagnie de télécommunication pour que la Tierce Partie obtienne un numéro de référence RN de l'Acheteur et puisse envoyer des messages à l'Acheteur à travers le réseau de télécommunications.
7) Système selon la revendication (1) caractérisé en ce que - aucune information financière n'est échangée sur le réseau quasi public - aucune information financière relative à l'Acheteur n'est communiquée au Marchand
8) Système selon la revendication (1) caractérisé en ce que la Tierce Partie - utilise les informations stockées dans sa base de données et relatives à l'Acheteur pour demander une autorisation de paiement à l'établissement bancaire dans le but de valider la transaction avec le Marchand. Les différents modes de paiement à la disposition de l'Acheteur avaient été communiqués à la Tierce Partie par l'Acheteur, au moment de l'enregistrement ou ensuite lors d'une mise à jour - .envoie l'information de validation de la transaction au Marchand
9) Système selon la revendication (1) caractérisé en ce qu'il triple la sécurité pour l'Acheteur par les moyens suivants - la clé personnelle d'identification PIK , - le code de confirmation reçu sur un appareil possédé par l'Acheteur, - l'algorithme AG de modification du code de confirmation déposé auprès de la Tierce Partie et mémorisé par 1 `Acheteur, - 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 trois niveaux de sécurité est détectée et enregistrée par la Tierce Partie et rapportée à .l'Acheteur.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0003889A FR2807247B1 (fr) | 2000-03-28 | 2000-03-28 | Systeme de paiement permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi-public |
| AU48418/01A AU4841801A (en) | 2000-03-28 | 2001-03-23 | Payment system not revealing banking information on the public or quasi-public network |
| PCT/FR2001/000894 WO2001073706A1 (fr) | 2000-03-28 | 2001-03-23 | Systeme de paiement 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 |
|---|---|---|---|
| FR0003889A FR2807247B1 (fr) | 2000-03-28 | 2000-03-28 | Systeme de paiement permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi-public |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2807247A1 true FR2807247A1 (fr) | 2001-10-05 |
| FR2807247B1 FR2807247B1 (fr) | 2003-01-31 |
Family
ID=8848557
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0003889A Expired - Fee Related FR2807247B1 (fr) | 2000-03-28 | 2000-03-28 | Systeme de paiement permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi-public |
Country Status (3)
| Country | Link |
|---|---|
| AU (1) | AU4841801A (fr) |
| FR (1) | FR2807247B1 (fr) |
| WO (1) | WO2001073706A1 (fr) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6990471B1 (en) * | 2001-08-02 | 2006-01-24 | Oracle International Corp. | Method and apparatus for secure electronic commerce |
| GB2379525A (en) * | 2001-09-08 | 2003-03-12 | Int Computers Ltd | Electronic payment authorisation |
| GB2393806A (en) * | 2002-10-05 | 2004-04-07 | Simos Symeou | Method for confirming authorisation of access to an account |
| US20040103060A1 (en) * | 2002-11-22 | 2004-05-27 | Pitney Bowes Incorporated | Secure payment system and method having one-time use authorization |
| GB2401209B (en) * | 2003-04-30 | 2005-10-26 | Hewlett Packard Development Co | Method and system for facilitation of a remote transaction |
| JP4737974B2 (ja) * | 2004-11-26 | 2011-08-03 | 株式会社東芝 | オンラインショッピングシステムとそのユーザ管理装置、ネット店舗装置及びユーザ端末装置 |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0590861A2 (fr) * | 1992-09-29 | 1994-04-06 | AT&T Corp. | Authorisation à haute sécurité d'une carte de débit/crédit |
| WO1996000485A2 (fr) * | 1994-06-24 | 1996-01-04 | Telefonaktiebolaget Lm Ericsson | Procede et appareil d'authentification d'un utilisateur |
| WO1997016897A1 (fr) * | 1995-11-01 | 1997-05-09 | First Virtual Holdings, Inc. | Systeme de paiement informatise pour l'achat de biens et de services sur internet |
| EP0813325A2 (fr) * | 1996-06-12 | 1997-12-17 | AT&T Corp. | Mécanisme permettant des transactions électroniques sécurisées sur Internet |
| WO1998040809A2 (fr) * | 1997-03-13 | 1998-09-17 | Cha! Technologies, Inc. | Procede et systeme de traitement protege de transaction en direct |
| US5883810A (en) * | 1997-09-24 | 1999-03-16 | Microsoft Corporation | Electronic online commerce card with transactionproxy number for online transactions |
| WO1999023617A2 (fr) * | 1997-11-04 | 1999-05-14 | Gilles Kremer | Procede de transmission d'information et serveur le mettant en oeuvre |
| US6026166A (en) * | 1997-10-20 | 2000-02-15 | Cryptoworx Corporation | Digitally certifying a user identity and a computer system in combination |
-
2000
- 2000-03-28 FR FR0003889A patent/FR2807247B1/fr not_active Expired - Fee Related
-
2001
- 2001-03-23 WO PCT/FR2001/000894 patent/WO2001073706A1/fr not_active Ceased
- 2001-03-23 AU AU48418/01A patent/AU4841801A/en not_active Abandoned
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0590861A2 (fr) * | 1992-09-29 | 1994-04-06 | AT&T Corp. | Authorisation à haute sécurité d'une carte de débit/crédit |
| WO1996000485A2 (fr) * | 1994-06-24 | 1996-01-04 | Telefonaktiebolaget Lm Ericsson | Procede et appareil d'authentification d'un utilisateur |
| WO1997016897A1 (fr) * | 1995-11-01 | 1997-05-09 | First Virtual Holdings, Inc. | Systeme de paiement informatise pour l'achat de biens et de services sur internet |
| EP0813325A2 (fr) * | 1996-06-12 | 1997-12-17 | AT&T Corp. | Mécanisme permettant des transactions électroniques sécurisées sur Internet |
| WO1998040809A2 (fr) * | 1997-03-13 | 1998-09-17 | Cha! Technologies, Inc. | Procede et systeme de traitement protege de transaction en direct |
| US5883810A (en) * | 1997-09-24 | 1999-03-16 | Microsoft Corporation | Electronic online commerce card with transactionproxy number for online transactions |
| US6026166A (en) * | 1997-10-20 | 2000-02-15 | Cryptoworx Corporation | Digitally certifying a user identity and a computer system in combination |
| WO1999023617A2 (fr) * | 1997-11-04 | 1999-05-14 | Gilles Kremer | Procede de transmission d'information et serveur le mettant en oeuvre |
Non-Patent Citations (1)
| Title |
|---|
| PAYS P ET AL: "An intermediation and payment system technology", COMPUTER NETWORKS AND ISDN SYSTEMS,NL,NORTH HOLLAND PUBLISHING. AMSTERDAM, vol. 28, no. 11, 1 May 1996 (1996-05-01), pages 1197 - 1206, XP004018220, ISSN: 0169-7552 * |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2807247B1 (fr) | 2003-01-31 |
| AU4841801A (en) | 2001-10-08 |
| WO2001073706A1 (fr) | 2001-10-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0820620B1 (fr) | Procede de paiement electronique permettant d'effectuer des transactions liees a l'achat de biens sur un reseau informatique | |
| EP1153376B1 (fr) | Procede de telepaiement et systeme pour la mise en oeuvre de ce procede | |
| EP1330798B1 (fr) | Procede de paiement par telematique securise | |
| US6748367B1 (en) | Method and system for effecting financial transactions over a public network without submission of sensitive information | |
| CA2223079C (fr) | Agent securise pour la distribution ouverte d'argent electronique | |
| US7043025B2 (en) | Method and apparatus for secured electronic commerce | |
| JP4480189B2 (ja) | 転送資金を支払うための自動預金支払機を使う資金電子転送システム及び方法 | |
| US20030061163A1 (en) | Method and apparatus for verification/authorization by credit or debit card owner of use of card concurrently with merchant transaction | |
| WO2001086538A1 (fr) | Systeme de reception de commerce mobile | |
| JP2003515822A (ja) | 電子商業システムで用いるための支払システムおよび方法 | |
| EP1854059A2 (fr) | Paiement non frauduleux d'achats sur internet | |
| EP1360665A1 (fr) | Procede et systeme de telepaiement | |
| CA2324114A1 (fr) | Procede d'utilisation d'une carte telephonique pour des transactions commerciales | |
| RU2452020C2 (ru) | Способ осуществления платежей (варианты) и система для осуществления способа | |
| JP2004507000A (ja) | Wapにより資金記憶装置から電子的な金額を伝送するための方法及び装置 | |
| WO2001073706A1 (fr) | Systeme de paiement permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi-public | |
| JP2002288427A (ja) | 取引実行方法 | |
| WO2021116627A1 (fr) | Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication | |
| KR100542375B1 (ko) | 통신판매 결제 시스템 및 그 방법과 그 방법에 대한컴퓨터 프로그램을 저장한 기록매체 | |
| EP1490851A1 (fr) | Procede et systeme de securisation d un paiement par carte d e credit | |
| FR2823882A1 (fr) | Procede et systeme de validation de paiement | |
| CA2496076A1 (fr) | Procede et systeme de securisation de transmission d'informations sur des reseaux de telecommunication | |
| FR2830100A1 (fr) | Systeme de paiement securise entre particuliers permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi public | |
| FR2831361A1 (fr) | Jeton informatique | |
| WO2005088568A1 (fr) | Procede et systeme de micropaiement |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse | ||
| FC | Decision of inpi director general to approve request for restoration | ||
| RN | Application for restoration | ||
| ST | Notification of lapse |
Effective date: 20071130 |