FR2912579A1 - Procede de transfert securise via un reseau de communication d'un flux monetaire, systeme de transfert et produit programme correspondants - Google Patents

Abstract

L'invention concerne un procédé de transfert sécurisé via un réseau de communication d'un flux monétaire d'un premier compte en banque d'un premier utilisateur dans une première banque (16) vers un second compte en banque d'un second utilisateur dans une seconde banque (15).Ce procédé comprend les étapes suivantes : première transmission, par un dispositif gestionnaire (13), d'une information de validation du transfert dudit flux monétaire au second utilisateur ; seconde transmission, par ledit second utilisateur, de ladite information de validation au premier utilisateur ; troisième transmission, par ledit premier utilisateur, de ladite information de validation à la première banque (16) ; et transfert du flux monétaire de la première banque (16) à la seconde banque (15) si chacune des première, seconde et troisième transmissions a eu lieu.

Description

Procédé de transfert sécurisé via un réseau de communication d'un flux

monétaire, système de transfert et produit programme correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui des transferts sécurisés de flux monétaires via un réseau de communication, par exemple le réseau Internet. Plus précisément, l'invention s'applique notamment, mais non exclusivement, aux paiements sécurisés dans le cadre du commerce électronique et aux virements sécurisés de flux monétaires banque à banque. 2. Solutions de l'art antérieur Grâce au développement fulgurant du commerce électronique via le réseau de communication Internet, les sites de vente par Internet ont développé de multiples modes de paiement en ligne (encore appelé paiement par Internet) selon le type d'achat effectué par l'utilisateur. Ainsi, certains sites Internet de commerce électronique offrent la possibilité aux acheteurs de payer leur achat par téléphone. En effet, l'acheteur appelle un numéro spécial affiché sur une page du site Internet (sur lequel il veut effectuer son achat) pour que lui soit attribué un code d'accès. Une fois son code d'accès obtenu, il peut l'utiliser pour effectuer son achat (un tel code permettant par exemple l'accès à certains services tels que le téléchargement de logos, sonneries, musique, ...). Ainsi, selon ce mode de paiement, l'achat est facturé sur la facture de téléphone de l'acheteur. Il n'y a, à aucun moment de la transaction, la transmission sur le réseau Internet des coordonnées de l'acheteur. Une variante de ce mode de paiement consiste à envoyer un message instantané à l'aide d'un téléphone portable (encore appelé SMS) au numéro de téléphone indiqué sur le site de commerce électronique, et de recevoir en retour un nouveau message instantané comprenant le code d'accès correspondant. Ainsi, bien que les coordonnées bancaires de l'acheteur ne soient transmises ni sur le site Internet ni lors de l'obtention du code d'accès, ce mode de paiement par téléphone présente l'inconvénient de ne pas être suffisamment sécurisé. En effet, une personne malveillante (en possession d'un téléphone qui ne lui appartient pas) peut utiliser ce mode de paiement à l'insu du propriétaire du téléphone et se livrer à des achats en ligne frauduleux.

Par ailleurs, un tel mode de paiement est uniquement mis en oeuvre pour des paiements d'un faible montant (encore appelés micros paiements), et n'est donc pas applicable à des achats sur Internet d'objets plus onéreux tel que du matériel hifi/vidéo. Les sites de commerce électronique ont également mis en place un système de paiement par carte bancaire afin qu'un acheteur effectue le règlement de ses achats en transmettant directement les coordonnées de sa carte bancaire au site de commerce électronique. Un tel mode de paiement nécessite la sécurisation de la transaction bancaire effectuée sur le réseau Internet. Une telle sécurisation repose notamment sur quatre conditions : - l'authentification des parties : il faut s'assurer de l'identité de l'acheteur (encore appelé client) et du site de commerce électronique (encore appelé site e-marchand) afin d'éviter tout utilisation frauduleuse des coordonnées bancaires d'une carte de paiement que ce soit par un acheteur ou part un site e-marchand ; - la confidentialité des données bancaires: il est nécessaire de rendre les données confidentielles (numéros de carte bancaire, date d'échéance, code de sécurité, ...) et illisibles des tiers non-autorisés. Une telle confidentialité est généralement obtenue en utilisant par exemple un protocole de communication de transfert de fichier sécurisé (par exemple HTTPS (pour en anglais HyperText Transfer Protocol Secure ) selon le protocole de cryptage SSL (pour en anglais Secure Socket Layer ) à 128 bits) ; - l'intégrité des données bancaires : il faut s'assurer que les données confidentielles transmises n'ont pas été altérées accidentellement ou frauduleusement lors de leur transmission ; -l'archivage des données bancaires : il faut s'assurer que les données confidentielles sont conservées et stockées de manière sécurisée dans un endroit protégé afin de prévenir toute utilisation frauduleuse et toute modification accidentelle. Cependant, malgré les précautions et mesures de sécurisation établies par les sites de commerce en ligne, un inconvénient de cette technique de l'art antérieur est qu'il existe encore aujourd'hui de nombreuses utilisations frauduleuses des coordonnées bancaires des clients de ces sites de commerce en ligne, celles-ci ayant été interceptées (ou piratées) lors de leur transmission sur le réseau Internet.

Ainsi, pour pallier le piratage des données bancaires et leur utilisation frauduleuse, un acheteur peut aujourd'hui faire appel à un opérateur tiers mettant à disposition un serveur (encore appelé plateforme technique). L'acheteur fournit à cet opérateur tiers (et non plus directement au site e-marchand) ses coordonnées bancaires (numéros de carte, code de sécurité, date d'échéance, ...) que ce dernier recueille et stocke de manière sécurisée. Ainsi, lorsqu'un acheteur effectue un achat sur un site de commerce en ligne, il fait appel à cet opérateur tiers (auquel il a préalablement fourni ses coordonnées bancaires) qui se charge alors de la demande d'autorisation de paiement de l'achat avec la banque de l'acheteur. Une telle demande d'autorisation de paiement est renouvelée pour chaque nouvel achat de l'acheteur. Aussi, ce mode de paiement en ligne indirect (utilisation d'un opérateur tiers) met en oeuvre une seule et unique transmission des coordonnées bancaires (de l'acheteur au serveur de l'opérateur tiers, et non plus au site e-marchand) lors de la souscription réduisant ainsi le risque de piratage.

Cependant, un inconvénient de cette technique de l'art antérieur est que la communication des coordonnées bancaires via le réseau Internet, même une seule fois, ne diminue en rien le risque de piratage ou d'altération accidentelle ou volontaire des coordonnées bancaires lorsqu'elles transitent de l'acheteur vers le serveur de l'opérateur tiers. Ainsi ce type de paiement pose des problèmes de sécurité.

Par ailleurs, un autre inconvénient de cette technique de l'art antérieur est qu'il subsiste toujours des risques de piratage du serveur de l'opérateur tiers où sont stockées les coordonnées bancaires de l'acheteur. Par ailleurs, la mise en oeuvre d'un virement inter-bancaire (c'est-à-dire le transfert d'argent d'un premier compte bancaire domicilié dans une première banque vers un second compte bancaire domicilié dans une seconde banque) est actuellement complexe. En effet, si le client A d'une banque A souhaite bénéficier d'un virement bancaire de la part d'un client B d'une banque B, le client A fournit au client B son numéro de compte international IBAN ainsi que le montant du virement. Une fois ces informations reçues, le client B peut par exemple émettre un ordre de virement à sa banque B (dans lequel sont récapitulés les informations du client A ainsi que le montant du virement) et le confirmer à sa banque B pour valider l'ordre de virement.

Lorsque le client B ne peut apporter la confirmation de son ordre de virement directement auprès du guichet de sa banque (par exemple par ce qu'il est en déplacement), il se voit dans l'obligation de faire parvenir cette confirmation écrite à sa banque par courrier ce qui allonge d'autant le délai d'exécution du virement.

Une fois la confirmation de l'ordre de virement reçue par la banque B, le virement est définitivement réalisé lors de son acceptation par le client A (l'absence de protestation de sa part, après réception d'un avis de crédit ou de son relevé, suffit à faire présumer cette acceptation). Ainsi, outre le problème de la complexité de mise en oeuvre et le fait que le délai depuis la demande de virement à son exécution peut être important dans certains cas (par exemple dans le cas précité), un autre inconvénient de cette technique de l'art antérieur concerne le problème de sécurité au moment de l'émission et de la confirmation d'un ordre de virement. En effet, rien n'empêche une personne mal intentionnée (connaissant les coordonnées bancaires du client d'une banque) de contrefaire ou d'imiter un ordre de virement (ainsi que sa confirmation) du compte de ce client vers un compte bancaire destinataire (le sien, celui d'un site de commerce électronique, ...). 3. Objectifs de l'invention L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur.

Plus précisément, un objectif de l'invention, dans au moins un de ses modes de réalisation, est de fournir une technique de transfert de flux monétaires sur un réseau de communication tel qu'Internet qui soit plus simple et plus sûre que les techniques classiques. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui permette de réaliser un paiement sécurisé sur Internet sans avoir à transmettre ses coordonnées bancaires. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui permette d'éviter le stockage des coordonnées bancaires sur les serveurs mis en oeuvre lors d'un paiement sur Internet.

Un autre objectif de l'invention, dans au moins un (le ses modes de réalisation, est de mettre en oeuvre une telle technique qui permette de réaliser un virement d'un premier compte bancaire domicilié dans une première banque vers un second compte bancaire domicilié dans une seconde banque qui soit plus simple et plus sûre à mettre en oeuvre que les techniques classiques. L'invention, dans au moins un de ses modes de réalisation, a encore pour objectif de mettre en oeuvre une telle technique qui ne nécessite pas d'adaptation du fonctionnement des banques classiques. L'invention, dans au moins un de ses modes de réalisation, a encore pour objectif de mettre en oeuvre une telle technique qui soit simple et peu coûteuse. 4. Exposé de l'invention Conformément à un mode de réalisation particulier, l'invention concerne un procédé de transfert sécurisé via un réseau de communication d'un flux monétaire d'un premier compte en banque d'un premier utilisateur dans une première banque vers un second compte en banque d'un second utilisateur dans une seconde banque Selon l'invention, un tel procédé comprend les étapes suivantes : -première transmission, par un dispositif gestionnaire, d'une information de validation du transfert dudit flux monétaire au second utilisateur ; seconde transmission, par ledit second utilisateur, de ladite information de validation au premier utilisateur ; troisième transmission, par ledit premier utilisateur, de ladite information de validation à la première banque ; transfert du flux monétaire de la première banque à la seconde banque si chacune des première, seconde et troisième transmissions a eu lieu. Le principe général de l'invention repose sur la communication non pas de cordonnées bancaires afin de mettre en oeuvre le transfert d'un flux monétaire via un réseau de communication par exemple de type Internet, mais plutôt d'une information de validation ne présentant pas une confidentialité élevée. Ainsi, l'invention permet de fournir une technique de transfert de flux monétaires sur un réseau de communication tel qu'Internet qui soit plus simple et plus sûre que les techniques classiques.

Par ailleurs, la mise en oeuvre de l'invention ne nécessite pas d'adaptation du fonctionnement des banques classiques.

Un dispositif gestionnaire peut par exemple servir d'interface entre la banque du premier utilisateur et le second utilisateur. Préférentiellement, le procédé comprend également une étape de quatrième transmission, par le dispositif gestionnaire, de l'information de validation au premier utilisateur simultanément ou après la seconde transmission (en redondance avec la seconde transmission). Préférentiellement, le procédé comprend une étape de transmission, par la première banque au dispositif gestionnaire, d'une information indiquant que le flux monétaire a été transféré à la seconde banque, dite information de transfert avec succès.

Préférentiellement, le procédé comprend une étape de transmission, par le dispositif gestionnaire au second utilisateur et/ou au premier utilisateur, de l'information de transfert avec succès. Avantageusement, le procédé de transfert sécurisé comprend également une étape d'obtention, par la première banque, d'au moins une information représentative du montant du flux monétaire et d'au moins une information représentative du second compte afin de pouvoir mettre en oeuvre ladite étape de transfert. Ainsi, par exemple, la première banque établit une connexion avec le dispositif gestionnaire via une liaison conforme à un protocole bancaire normalisé (par exemple les protocoles de cryptage bancaire CBSA ou CBPR sur X25) afin de collecter certaines informations relatives à la commande du premier utilisateur (par exemple le numéro de commande, le montant total de la commande, le numéro de compte du second utilisateur,

Préférentiellement, le procédé comprend également au moins une des étapes suivantes : - vérification que le montant du flux monétaire est disponible sur le premier compte ; - vérification qu'une opposition n'a pas été effectuée sur le premier compte. Selon un premier mode de réalisation de l'invention, le procédé de transfert sécurisé est un procédé de paiement sécurisé d'un produit et/ou service par le premier utilisateur, dit utilisateur acheteur, au second utilisateur, dit utilisateur vendeur, ledit utilisateur acheteur et ledit utilisateur vendeur mettant en oeuvre une transaction en commerce électronique sur le réseau de communication pour la vente dudit produit et/ou service, ledit procédé comprenant l'étape préalable de sélection dudit produit et/ou service par l'utilisateur acheteur au moyen d'une interface d'un serveur vendeur de l'utilisateur vendeur. Ainsi, le procédé de transfert selon l'invention permet de réaliser un paiement sécurisé sur Internet sans avoir à transmettre ses coordonnées bancaires. En effet, les utilisateurs acheteurs n'ont plus besoin de transmettre leurs coordonnées bancaires par le réseau Internet. De façon avantageuse, le procédé de transfert sécurisé comprend également une étape préalable de transmission, par l'utilisateur vendeur au dispositif gestionnaire, d'au moins une information représentative dudit produit et/ou service. Ainsi, par exemple, l'utilisateur vendeur envoie au moins une information relative à la commande de l'utilisateur acheteur, par exemple les références des différents articles commandés, le prix à l'unité de chacun des articles, le nombre d'articles commandés, le montant total de la commande, le type de devise utilisée. La transmission de l'ensemble de ces informations peut être réalisée grâce à un logiciel gestionnaire installé sur le serveur du site Internet de l'utilisateur vendeur. La transmission peut se faire via une liaison HTTPS. Selon une caractéristique avantageuse du premier mode de réalisation de l'invention, le procédé de transfert sécurisé comprend également les étapes suivantes : - prélèvement dudit montant sur le premier compte ; - stockage temporaire dudit montant dans la première banque ; - vérification d'une condition avant de mettre en oeuvre ladite étape de transfert du flux monétaire de la première banque à la seconde banque. Ainsi, par exemple, le montant de la commande de l'utilisateur vendeur est débité du compte du premier utilisateur et bloqué au sein de la première banque. Le déblocage ou non de la somme bloquée au sein de la première banque peut être soumis à des conditions particulières qui garantissent notamment l'expédition de la commande à l'utilisateur acheteur. Avantageusement, ladite condition est l'une au moins des conditions appartenant au groupe comprenant les conditions suivantes : un délai prédéterminé entre la troisième transmission et une fourniture du produit et/ou service au premier utilisateur n'est pas écoulé ; - un délai prédéterminé entre la seconde transmission et la troisième transmission n'est pas écoulé ; - le premier utilisateur n'a pas annulé ladite transaction ; - le produit et/ou service est disponible en stock.

Ainsi, par exemple, si au bout de sept jours après la troisième transmission (qui correspond à une confirmation du transfert par le premier utilisateur), le produit et/ou service n'a toujours pas été reçu par le premier utilisateur, alors le transfert du flux monétaire n'est pas mis en oeuvre. Selon un autre exemple, si au bout de dix jours après la seconde transmission, le premier utilisateur n'a toujours pas mis en oeuvre la troisième transmission, alors le transfert n'est pas mis en oeuvre. Selon encore un autre exemple, si le premier utilisateur a effectué une demande d'annulation de la transaction dans les dix jours suivant la seconde transmission, alors le transfert n'est pas mis en oeuvre.

Préférentiellement, le procédé comprend une étape de transmission, par le second utilisateur au dispositif gestionnaire, d'une information indiquant que le produit et/ou service a été fourni au premier utilisateur, dite information de fourniture, et une étape de transmission, par le dispositif gestionnaire à la banque du premier utilisateur, de l'information de fourniture.

Selon une mise en oeuvre avantageuse du premier mode de réalisation de l'invention, la troisième transmission, par ledit premier utilisateur, de ladite information de validation à la première banque est mise en oeuvre au moyen d'un distributeur automatique de billet appartenant à ladite première banque. Ainsi, le procédé de transfert selon l'invention est compatible avec le fonctionnement des banques classiques. Avantageusement, la troisième transmission, par ledit premier utilisateur, de ladite information de validation à la première banque est mise en oeuvre au moyen d'un terminal de validation appartenant à ladite première banque. Le terminal de validation peut par exemple être une borne de paiement comportant notamment un écran d'affichage, un clavier ainsi qu'un lecteur de carte bancaire, pour que le premier utilisateur puisse confirmer son paiement.

De façon avantageuse, la troisième transmission, par ledit premier utilisateur, de ladite information de validation à la première banque comprend les étapes suivantes - transmission, par le premier utilisateur au dispositif gestionnaire, d'un message électronique comprenant ladite information de validation - transmission par le dispositif gestionnaire à la première banque, de ladite information de validation. Ainsi, par exemple le message électronique est un message texte envoyé par un téléphone portable ou un courriel. Préférentiellement, cette troisième transmission ne peut être effectuée que si le premier utilisateur a demandé l'activation d'une option correspondante. Selon un second mode de réalisation de l'invention, ledit procédé de transfert sécurisé étant un procédé de virement bancaire sécurisé du flux monétaire depuis le premier compte bancaire vers le second compte bancaire, l'information de validation comprend au moins une information d'identification du second compte bancaire et au moins une information représentative du montant du flux monétaire. Ainsi, le procédé de transfert selon l'invention permet de réaliser un virement d'un premier compte bancaire domicilié dans une première banque vers un second compte bancaire domicilié dans une seconde banque qui soit plus simple et plus sûre à mettre en oeuvre que les techniques classiques. Il est plus simple par exemple du fait que du point de vue du second utilisateur, il n'est plus nécessaire d'envoyer de courrier écrit pour confirmer l'ordre de virement. De façon avantageuse, le procédé de transfert sécurisé comprend une étape de stockage d'au moins une information représentative d'un transfert d'un flux monétaire entre la première banque et la seconde banque.

Ainsi, ces informations peuvent être transmises (notamment au moyen d'un cryptage), par exemple quotidiennement, à la seconde banque. Par ailleurs, le second utilisateur peut consulter (par exemple au moyen d'une connexion sécurisée et sous réserve de s'être préalablement authentifié auprès du dispositif gestionnaire) ces informations.

Selon une caractéristique avantageuse du second mode de réalisation de l'invention, le réseau de communication est le réseau Internet.

Bien entendu, le réseau de communication peut être tout autre réseau tel que par exemple, un réseau de type LAN (pour Local Area Network ) ou un réseau métropolitain. De façon avantageuse, au moins certaines desdites informations sont échangées sous forme cryptée. Ainsi, par exemple : - les échanges entre le dispositif gestionnaire et la première banque sont effectués sous forme cryptée grâce au protocole de cryptage bancaire CBSA ou CBPR sur X25 ; - les échanges entre le dispositif gestionnaire et le second utilisateur sont effectués sous forme cryptée grâce au protocole de cryptage SSL sur 128 bits. L'invention concerne également un système de transfert sécurisé via un réseau de communication d'un flux monétaire d'un premier compte en banque d'un premier utilisateur dans une première banque à un second compte en banque d'un second utilisateur dans une seconde banque qui comprend : - des premiers moyens de transmission d'une information de validation du transfert dudit flux monétaire au second utilisateur, lesdits premiers moyens de transmission appartenant à un dispositif gestionnaire ; - des seconds moyens de transmission, par le second utilisateur, de ladite information de validation au premier utilisateur ; - des moyens de réception de ladite information de validation, lesdits moyens de réception appartenant à la première banque ; - des moyens de transfert du flux monétaire de la première banque à la seconde banque.

L'invention concerne encore un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké par un ordinateur et/ou exécutable par un microprocesseur qui comprend des instructions de code de programme pour l'exécution des étapes du procédé de transfert sécurisé tel que précédemment décrit, lorsque ledit programme est exécuté sur un ordinateur, L'invention concerne encore un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de transfert sécurisé tel que précédemment décrit. 5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs modes de réalisation, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : les figures 1-A et 1-B présentent un premier (figure 1-A) et un second (figure 1-B) exemple d'architecture globale de réseau dans lequel est mis en oeuvre l'invention selon un premier mode de réalisation ; - la figure 2 présente les étapes principales d'un algorithme de commande mis en oeuvre dans le cadre du premier mode de réalisation de l'invention ; la figure 3 présente les étapes principales d'un algorithme de paiement mis en oeuvre dans le cadre du premier mode de réalisation de l'invention ; la figure 4 décrit présente une illustration d'un exemple d'architecture globale de réseau dans lequel est mis en oeuvre l'invention selon une variante du premier mode de réalisation ; la figure 5 présente les étapes principales d'un algorithme de paiement mis en oeuvre dans le cadre d'une variante du premier mode de réalisation de l'invention ; la figure 6 présente une illustration d'un exemple d'architecture globale de réseau dans lequel est mis en oeuvre l'invention selon un second mode de réalisation ; la figure 7 présente les étapes principales d'un algorithme de virement mis en oeuvre dans le cadre du second mode de réalisation de l'invention ; la figure 8 présente une illustration d'un exemple d'architecture globale de réseau dans lequel est mis en oeuvre l'invention selon une variante du second mode de réalisation ; la figure 9 présente les étapes principales d'un algorithme de virement mis en oeuvre dans le cadre d'une variante du second mode de réalisation de l'invention. 6. Description de modes de réalisation de l'invention On se place ci-après dans le cadre de procédés de transfert sécurisé via un réseau de 30 communication, par exemple le réseau Internet, de flux monétaires d'un premier compte en banque d'un premier utilisateur dans une première banque vers un second compte en banque d'un second utilisateur dans une seconde banque. Bien entendu, le réseau de communication peut être tout autre réseau tel que, par exemple, un réseau LAN (pour local Area Network ) ou un réseau métropolitain.

Les deux modes de réalisation décrits par la suite concernent, pour le premier, le paiement d'une commande passée sur un site e-marchand directement auprès d'un distributeur automatique de billet (ou DAB), et pour le second, la validation d'un virement bancaire auprès d'un DAB par un utilisateur. Les procédés de transfert sécurisé selon l'invention ci-après décrits peuvent être mis en oeuvre sous la forme d'un logiciel et/ou d'une pluralité de sous logiciels (comprenant une pluralité d'algorithmes décrits ci-après) qui est (sont) exécuté(s) dans une ou plusieurs machines du réseau précité, par exemple dans le serveur du site e-marchand, le serveur gestionnaire, le serveur de la banque DAB décrits ci-après. 6.1-Paiement sécurisé via un réseau de communication On présente ci-après un premier mode de réalisation de l'invention concernant un procédé de paiement sécurisé (qui est un procédé de transfert sécurisé d'un flux monétaire banque à banque) d'un produit et/ou service via un réseau (le communication, par exemple le réseau Internet. Un tel procédé de paiement sécurisé met en oeuvre notamment les deux phases suivantes : une première phase de commande par le premier utilisateur (ou utilisateur acheteur encore appelé acheteur) d'un produit et/ou d'un service à un second utilisateur (ou utilisateur vendeur encore appelé vendeur) par exemple via un site de commerce électronique (encore appelé site e-marchand) appartenant au vendeur ; - une seconde phase de paiement du produit ou du service sélectionné. Ainsi, l'acheteur et le vendeur mettent en oeuvre une transaction en commerce électronique sur Internet pour la vente dudit produit et/ou service. La figure 1-A présente un premier exemple d'architecture globale de réseau dans lequel sont mises en oeuvre les phases de commande et paiement d'un produit et/ou service sur un site e-marchand selon un premier mode de réalisation. L'architecture globale de réseau de ce premier exemple comprend notamment : - un terminal 11 (par exemple un ordinateur) ; - un serveur 12 d'un site e-marchand (ou serveur vendeur de l'utilisateur vendeur) ; - un dispositif gestionnaire 13 (par exemple sous la forme d'un serveur informatique encore appelé serveur gestionnaire) ; - un distributeur automatique de billets 14 (ou DAB) ; la banque 16 du DAB 14 ; - un dispositif de contrôle 17 (mis en oeuvre, par exemple, par une banque individuelle et/ou par un Groupement d'Intérêt Economique (ou GIE) des cartes bancaires) ; et - la banque du site e-marchand 15. Selon le premier exemple d'architecture globale de réseau conforme au premier mode de réalisation de l'invention, le dispositif gestionnaire 13 est par exemple localisé à l'extérieur de la banque DAB 16, mais peut échanger des informations avec celle-ci. Des adaptations peuvent être nécessaires pour établir une connexion entre le serveur de labanque 16 et le dispositif gestionnaire 13. Bien entendu, selon une variante de ce premier exemple d'architecture de réseau globale, le dispositif gestionnaire 13 peut être intégré au sein du réseau bancaire de la banque 16. La figure 1-B présente un second exemple d'architecture globale de réseau dans lequel sont mises en oeuvre les phases de commande et paiement d'un produit et/ou service sur un site e-marchand selon le premier mode de réalisation. L'architecture globale de réseau de ce second exemple est identique à celle du premier exemple, à l'exception du DAB 14 qui est remplacé par un terminal de validation 102, et de la banque 16 du DAB 14 qui est remplacée par la banque 101 du terminal 102.

Selon ce second exemple d'architecture globale de réseau conforme au premier mode de réalisation de l'invention, le dispositif gestionnaire 13 est par exemple localisé à l'extérieur de la banque 101 du terminal 102., mais peut échanger des informations avec celle-ci. Des adaptations peuvent être nécessaires pour établir une connexion entre le serveur de la banque 101 et le dispositif gestionnaire 13.

Selon une variante de ce second exemple d'architecture globale de réseau, le dispositif gestionnaire 13 peut faire partie intégrante de la banque 101. a-Phase de commande On décrit ci-après, en relation avec la figure 2, les différentes étapes intervenant lors de la phase de commande d'un service et/ou d'un service sur un site de commerce électronique selon le premier mode de réalisation de l'invention.

Lors d'une première étape 21, l'acheteur peut par exemple se connecter au site e-marchand de son choix par l'intermédiaire du navigateur Web installé sur son ordinateur 11 via une liaison 121 HTTP classique (en anglais HyperText Transfer Protocol ). Il peut dès lors naviguer au sein de la boutique virtuelle du site e-marchand et sélectionner un ou plusieurs articles proposés (produit, service, ...) au moyen d'un logiciel de boutique virtuelle spécifique (ou interface du serveur vendeur). Par exemple, chaque article sélectionné est alors déposé dans un panier virtuel simulant le remplissage d'un charriot. Une fois la sélection d'articles achevée, l'acheteur poursuit par exemple sa commande en remplissant, au cours d'une étape 22, un formulaire interactif qui s'affiche sur une des pages du site e-marchand. Le formulaire peut par exemple comprendre les champs suivants (encore appelés informations personnelles): nom, prénom ; adresse postale d'expédition ; numéro de téléphone portable (s'il en dispose) ; - e-mail ;

Lorsqu'il a renseigné les champs précités, l'acheteur peut valider le formulaire interactif qui est alors traité, lors d'une sous-étape de traitement, par le logiciel de boutique virtuelle.

Lors de cette sous-étape de traitement, le logiciel de boutique virtuelle effectue par exemple les actions suivantes : vérification des informations fournies par l'acheteur (par exemple l'oubli d'un champ, ...) ; contrôle du stock et/ou des méthodes de livraison ; - calcul des éventuels frais annexe (par exemple le port, la TVA, ...) ; Lorsque l'acheteur a par exemple oublié de renseigner un champ, le logiciel de boutique virtuelle lui demande de compléter ce champ, puis de valider de nouveau le formulaire afin d'exécuter la sous-étape de traitement. Une fois le formulaire validé, le serveur 12 du site e-marchand établit par exemple une connexion (par exemple via une liaison 122 HTPPS selon le protocole de cryptage SSL à 128 bits qui crypte l'ensemble des informations échangées) avec le serveur informatique gestionnaire 13 lors d'une étape 23. Au cours de l'établissement de la connexion, une première sous-étape (de l'étape 23) d'authentification du serveur du site e-marchand peut être mise en oeuvre par le serveur gestionnaire 13 pour vérifier l'identité du site e-marchand. Une fois authentifié, le serveur 12 du site e-marchand peut par exemple transmettre, au dispositif gestionnaire, lors d'une seconde sous étape de l'étape 23, des informations représentatives dudit produit et/ou service telles que des informations relatives à la commande (par exemple les références des différents articles commandés, le prix à l'unité de chacun des articles, le nombre d'articles commandés, le montant total de la commande, le type de devise utilisée, ...), les informations personnelles de l'acheteur, ainsi que des informations concernant le site e-marchand lui-même (par exemple le numéro de commerçant). La transmission de l'ensemble de ces informations est par exemple réalisée au moyen d'un logiciel gestionnaire installé sur le serveur. 12 du site e-marchand via la liaison 122 HTTPS. Lors d'une étape 24 le serveur gestionnaire 13 peut par exemple générer un numéro de commande unique (encore appelé information de validation) qu'il envoie (première transmission) alors au serveur 12 du site e-marchand appartenant au vendeur, via une liaison 122 HTTPS selon le protocole de cryptage SSL à 128 bits. Le numéro de commande envoyé est par exemple récupéré par le logiciel gestionnaire installé sur le serveur 12 du site e-marchand, puis stocké sur le serveur 12. Au cours d'une étape 25, le logiciel de boutique virtuelle du site e-marchand (appartenant à l'utilisateur vendeur) peut par exemple récupérer le numéro de commande unique stocké sur le serveur 12 du site e-marchand pour le transmettre (seconde transmission) à l'acheteur avec le récapitulatif de sa commande (articles commandés, montant total de la commande, délai et type de livraison, ...). L'acheteur peut par exemple visualiser l'ensemble de ces informations sur une page de son navigateur Web affichée sur l'écran de son ordinateur 11. Optionnellement, le numéro unique de commande peut être transmis (quatrième transmission) directement à l'acheteur par le serveur gestionnaire 13 soit simultanément soit ultérieurement à l'étape 25. Il peut alors exister une redondance avec la seconde transmission. L'acheteur peut alors confirmer ou annuler sa commande lors d'une étape 26. Il peut également la modifier, mais cela nécessite le retour à l'étape 22. Lorsque l'acheteur décide d'annuler sa commande (par exemple en cliquant sur l'onglet Annuler ), cette dernière est par exemple automatiquement annulée. Lorsque l'acheteur confirme sa commande (par exemple en cliquant sur l'onglet Valider ), il peut par exemple activer l'opération de validation de ses achats, et peut recevoir, lors d'une étape 27, un e- mail et/ou SMS de confirmation de la commande. Cet e-mail et/ou SMS (contenant par exemple le numéro de la commande, le délai de paiement, l'adresse de livraison, ...) marque la fin de la phase de commande. Dés la fin de la phase de commande, l'acheteur peut disposer de quelques jours (par exemple un délai de sept jours) pour mettre en oeuvre la phase de paiement qui débute par exemple par le règlement de la commande par l'acheteur dans un Distributeur Automatique de Billets (ou DAB) selon le mode premier mode de réalisation de l'invention.

Sans validation par l'acheteur de la commande auprès d'un DAB 14 durant le délai de paiement prédéterminé, elle est par exemple automatiquement annulée. b-Phase de paiement On présente ci-après, en relation avec la figure 3, les différentes étapes intervenant lors de la phase de paiement selon le premier mode de réalisation de l'invention.

Par exemple, la phase de paiement n'est mise en oeuvre que dans le délai de paiement indiqué sur le site e-marchand et précisé dans l'e-mail de confirmation (envoyé lors de l'étape 27). Une fois ce délai expiré la commande est annulée et ne pourra dès lors plus être payée. Préalablement au déclenchement de la phase de paiement, lorsque le délai de paiement n'a pas encore expiré, l'acheteur peut par exemple insérer sa carte bancaire dans un distributeur automatique de billets 14 (ou DAB) relié à la banque 16 (encore appelée banque DAB), et ensuite composer son numéro confidentiel de carte bancaire. La phase de paiement est alors amorcée une fois le code confidentiel validé. Selon une variante, le DAB peut être remplacé par un terminal de validation 101 (par exemple sous forme d'une borne comportant notamment un écran d'affichage, un clavier ainsi qu'un lecteur de carte bancaire, pour que l'acheteur puisse confirmer son paiement) appartenant à une banque 102 tel qu'illustré sur la figure 1-B. Un tel terminal peut par exemple être disponible dans n'importe quel centre commercial. À la différence du DAB 14, le terminal de validation 101 ne peut pas distribuer d'argent aux utilisateurs, mais met cependant en oeuvre l'ensemble des étapes de validation de paiement réalisées par le DAB 14 selon le premier mode de réalisation. L'acheteur peut par exemple effectuer ces opérations préalables dans un DAB 14 quelconque, qui peut appartenir à une banque différente de celle du compte de l'acheteur, sous réserve qu'elle mette en oeuvre le logiciel gestionnaire. La mise en oeuvre du logiciel gestionnaire peut notamment nécessiter des adaptations de l'interface graphique des distributeurs automatiques de billets. Ces adaptations sont par exemple réalisées par les banques elles-mêmes.Dans une étape 31, l'acheteur peut par exemple sélectionner le mode de paiement appelé paiement commande Internet contrôlé par le serveur gestionnaire 13. Ensuite, lorsque le mode précité a été sélectionné, l'acheteur peut par exemple entrer son numéro de commande qui lui a été transmis lors de l'étape 25 (et présent dans l'e-mail envoyé à l'acheteur lors de l'étape 27). Le numéro de commande entré par l'acheteur peut par exemple être transmis (troisième transmission) du DAB à la banque DAB 16 via une liaison 124 mettant en oeuvre un protocole bancaire normalisé (par exemple les protocoles de cryptage bancaire CBSA ou CBPR sur 25X). Ensuite, lors d'une étape 32, un contrôle du compte bancaire de l'acheteur peut par exemple être réaliser par un dispositif de contrôle 17 afin de vérifier (au même titre que pour un retrait d'argent classique), une opposition éventuelle sur le compte bancaire et demander l'autorisation de débiter le compte (ce qui correspond à vérifier que le montant du flux monétaire est disponible sur le compte l'acheteur). L'échange d'information entre la banque DAB 16 et le dispositif de contrôle 17 s'effectue par exemple au moyen d'une liaison 126 conforme à un protocole bancaire normalisé, par exemple les protocoles de cryptage bancaire CBSA ou CBPR sur X25. Après l'envoi de l'autorisation de paiement par le dispositif de contrôle 17, la banque DAB 16 peut par exemple établir une connexion avec le serveur gestionnaire 13 via une liaison conforme à un protocole bancaire normalisé (par exemple les protocoles de cryptage bancaire CBSA ou CBPR sur X25) afin de collecter (sous-étape d'obtention) certaines informations relatives à la commande de l'acheteur (par exemple le numéro de commande, le montant total de la commande (information représentative du montant flux monétaire), le numéro de compte du site e-marchand (information représentative du second compte), ...). Lorsque la banque DAB 16 a récupéré les informations relatives à la commande, elle peut par exemple envoyer un récapitulatif de la commande au DAB 14 qui la présente à l'acheteur via son interface graphique. Ainsi, à la lecture de ce récapitulatif, l'acheteur a par exemple la possibilité de payer sa commande en sélectionnant l'onglet Payer commande ce qui confirme le paiement, ou peut également annuler la commande en sélectionnant l'onglet Annuler commande , lorsque le récapitulatif contient par exemple une erreur. Lorsque l'acheteur choisit d'annuler sa commande, une requête d'annulation est par exemple envoyée du DAB 14 à la banque DAB 16 lors d'une sous-étape d'annulation. La requête d'annulation peut ensuite transiter par le serveur gestionnaire 13 pour finalement être transmise au serveur e-marchand 12 qui se charge d'annuler la commande. L'acheteur n'a alors plus la possibilité de valider sa commande à aucun moment ni d'aucune manière que ce soit. Par exemple, lorsque l'acheteur valide sa commande, une information de validation peut être envoyée à la banque DAB 16, et le compte bancaire de l'acheteur peut être débité classiquement d'un montant d'un montant égal à celui de la commande. Cependant, le montant de la commande (encore appelé montant du flux monétaire), bien que débité du compte de l'acheteur, n'est pas viré sur le compte de bancaire du site e-marchand. En effet, il est par exemple bloqué et stocké temporairement (étape de stockage temporaire) au niveau de la banque DAB 16.

Lors d'une étape 33, l'information montant bloqué peut par exemple être envoyée de la banque DAB 16 vers le serveur gestionnaire 13 via la liaison 123, pour ensuite être transmise au serveur e-marchand 12. Une fois l'information montant bloqué reçu, le site e-marchand dispose par exemple d'un premier délai d'expédition (par exemple sept jours) prédéterminé (qui dépend du type de produite ou de service) pour expédier la commande à l'acheteur. Selon le premier mode de réalisation de l'invention, l'acheteur n'a par exemple plus la possibilité d'annuler sa commande une fois la confirmation de paiement effectuée au DAB jusqu'à l'expiration du premier délai d'expédition. Bien entendu, selon une variante, l'acheteur peut annuler sa commande avant la fin du premier délai d'expiration. Dès l'expédition de la commande, le serveur 12 du site e-marchand établit par exemple une connexion avec le serveur gestionnaire 13 au cours d'une étape 34 (étape de transmission) pour lui transmettre l'information commande expédiée (encore appelé information de fourniture).

Lors d'une étape 35, l'information commande expédiée peut être relayée par le serveur e-marchand 12 vers la banque DAB 16. Une fois l'information commande expédiée reçue par la banque DAB 16, celle-ci effectue le virement (encore appelé transfert du flux monétaire) du montant de la commande (qu'elle avait bloqué) vers la banque du site e-marchand au cours d'une étape 36 (transfert du flux monétaire de la banque DAB 16 vers la banque du vendeur) après télécollecte de toutes les informations de confirmation de paiement stockées (étape de stockage) sur le serveur gestionnaire 13. Les virements sont effectifs au moment de la télécollecte effectuée par exemple une fois par jour (en fonction des paramètres donnés par la banque) via une connexion sécurisée selon un protocole normalisé (par exemple le protocole de cryptage bancaire CB2A). Ainsi, le transfert du flux monétaire n'a lieu que si chacune des première, seconde et troisième transmissions précitées a eu lieu. Une confirmation de virement (encore appelé information de transfert avec succès ) peut être envoyée au serveur gestionnaire 13 par exemple par la banque DAB 16 pour chaque virement effectif.

Ensuite, au cours d'une étape 37, le serveur gestionnaire 13 peut envoyer une information de transfert avec succès au serveur du site e-marchand afin de l'informer que son compte bancaire a été crédité. Il est par ailleurs envisageable que le bénéficiaire puisse se connecter au serveur gestionnaire 13, via un mot de passe et un login, pour contrôler et visualiser en direct les paiements des commandes effectuées sur son site e-marchand, les commandes annulées, ainsi que les commandes en attente de paiement. De manière optionnelle, un e-mail et/ou un SMS peut être envoyé à l'acheteur pour lui informer que le virement a été effectué sur le compte du site e-marchand lors d'une étape 38. Lorsque la commande n'a pas été expédiée dans un premier délai d'expédition prédéterminé (par exemple sept jours), l'acheteur peut annuler sa commande au DAB 14 à la fin du délai d'expédition de façon similaire à la sous-étape d'annulation de l'étape 32. Le montant bloqué par la banque DAB 16 est par exemple débloqué et crédité sur le compte en banque de l'acheteur. Lorsque la commande n'a pas été expédiée sous un second délai d'expédition prédéterminé (supérieur au premier délai d'expédition, par exemple dix jours) ni annulé par l'acheteur après la fin du premier délai d'expédition, la commande est par exemple alors automatiquement annulée. Le montant bloqué par la banque DAB 16 peut par exemple être débloqué et crédité sur le compte en banque de l'acheteur. Ainsi, le virement du montant de la commande (ou transfert du flux monétaire) sur le compte en banque du vendeur est par exemple soumis à une étape de vérification d'au moins une des conditions suivantes : - un délai prédéterminé entre la troisième transmission et l'expédition de la 25 commande (correspondant à la fourniture du produit et/ou service commandé par l'acheteur) par le vendeur n'est pas écoulé ; - un délai prédéterminé entre la seconde transmission et la troisième transmission n'est pas écoulé ; - l'acheteur n'a pas annulé la transaction ; 30 - le produit et/ou service est disponible en stocke.

Par ailleurs, on peut prévoir une étape de rétribution de l'organisme propriétaire du dispositif gestionnaire 13, par exemple sous la forme du versement d'une commission pour chaque commande payée. Selon une variante du premier mode de réalisation, l'acheteur peut déclencher la phase de paiement par l'envoi classique d'un SMS au serveur gestionnaire 13 via son téléphone portable, tel qu'illustré sur la figure 4. Cependant, le paiement de la commande par téléphone portable n'est par exemple possible que lorsque l'acheteur s'est préalablement enregistré et a souscrit un contrat de paiement par téléphone avec sa banque personnelle 42 (figure 4). Lors de la souscription du contrat de paiement par téléphone, la banque personnelle 42 peut par exemple fournir à l'acheteur un code secret permettant son authentification. On décrit ci-après, en relation avec la figure 5, les différentes étapes mises en oeuvre lors de la phase de paiement, selon la variante du premier mode de réalisation de l'invention.

Ainsi, lors d'une étape 51, l'acheteur envoie par exemple, au serveur gestionnaire 13, un SMS comprenant le numéro de commande ainsi que le code secret de l'acheteur. Dans une étape 52, le serveur gestionnaire 13 peut par exemple demander la vérification du code secret contenu dans le SMS auprès de la banque 42 pour authentifier l'acheteur.

Lorsque l'acheteur est authentifié, un contrôle du compte bancaire de l'acheteur peut être réalisé par le dispositif de contrôle 17 pour vérifier une opposition éventuelle sur le compte bancaire et demander l'autorisation de débiter le compte, de manière similaire à ce qui a été décrit dans l'étape 32. Après l'envoi de l'autorisation de paiement par le dispositif de contrôle 17, la banque 42 de l'acheteur établit par exemple une connexion avec le serveur gestionnaire 13 via une liaison conforme à un protocole bancaire normalisé (par exemple les protocoles de cryptage bancaire CBSA ou CBPR sur X25) afin de collecter certaines informations relatives à la commande de l'acheteur (par exemple le numéro de commande, le montant total de la commande, le numéro de compte du site e-marchand,

.)...DTD: Le compte bancaire de l'acheteur est par exemple débité (étape de prélèvement) d'un montant d'un montant égal à celui de la commande. Cependant, le montant de la commande, bien que débité du compte de l'acheteur, peut ne pas être viré sur le compte de bancaire du site e-marchand. En effet, il peut par exemple être bloqué et stocké au niveau de la banque 42 de l'acheteur. La suite du paiement de la commande par téléphone est identique à ce qui a été décrit précédemment lors des étapes 32 à 38 pour le paiement de la commande via un distributeur automatique de billet 14, excepté le fait que la banque DAB 16 est remplacée par la banque personnelle 42 de l'acheteur. Le mode de paiement par téléphone, variante du premier mode de réalisation de l'invention, ne permet pas à l'acheteur d'annuler sa commande, elle s'annulera d'elle-10 même s'il ne se manifeste pas dans un délai de paiement prédéterminé. Ainsi, l'invention permet notamment de supprimer le risque de piratage car aucune information confidentielle (par exemple le numéro de carte bancaire) ne transite sur le réseau Internet. Par exemple, seules des données relatives à la commande de l'acheteur sont communiquées via le réseau Internet, que ce soit lors de la phase de commande ou lors de 15 la phase de paiement. Par ailleurs, un tel procédé de paiement sécurisé permet également de garantir à l'acheteur l'expédition de sa commande. En effet, le virement du montant de la commande sur le compte en banque du site e-marchand n'est par exemple effectué qu'une fois le ou les articles de la commande expédiés. 20 Ainsi, grâce au procédé de paiement sécurisé conforme à l'invention, les acheteurs n'ont plus besoin de transmettre leurs coordonnées bancaires via le réseau Internet. Par conséquent, les coordonnées bancaires de l'acheteur ne sont à aucun moment stockées sur les serveurs (serveur gestionnaire 13, serveur e-marchand 12) mis en oeuvre au cours des phases de commande et de paiement du procédé de paiement sécurisé selon l'invention. 25 L'invention s'adresse donc notamment aux commerçants (par exemple la vente par correspondance, les sites de courtage, les sites portefeuilles et banques virtuelles, les hébergeurs, les gérants de galerie virtuelles, les créateurs de sites,

.) désirant commercialiser des produits ou services sur Internet en sécurisant leurs transactions de paiement tout en conservant leur banque actuelle...DTD: Elle s'adresse également aux acheteurs d'articles commercialisés sur des sites de commerce électronique, soucieux de la sécurité et de la confidentialité de leurs paiements ainsi que de la garantie de l'expédition des articles commandés. Par ailleurs, l'invention s'adresse aux établissements bancaires désirant répondre aux besoins de leurs clients tout en gardant une monétique traditionnelle utilisant des protocoles bancaires normalisés et des contrats standards tels que ceux mis en oeuvre dans le cas des ventes à distance. 6.2-Virement bancaire sécurisé d'un flux monétaire On présente un second mode de réalisation de l'invention concernant un procédé de virement bancaire sécurisé d'un flux monétaire (qui est un procédé de transfert sécurisé d'un flux monétaire banque à banque) via un réseau de communication d'un premier compte en banque d'un premier utilisateur dans une première banque vers un second compte en banque d'un second utilisateur dans une seconde banque. Le procédé de virement bancaire sécurisé de flux monétaire met en oeuvre notamment les deux phases suivantes : une première phase de demande de virement bancaire d'un flux monétaire par le second utilisateur (appelé bénéficiaire) au premier utilisateur (appelé émetteur) ; une seconde phase de virement effectif du flux monétaire du compte en banque de l'émetteur au compte en banque du bénéficiaire.

Tel qu'illustré sur la figure 6, dans les phases de demande de virement et de virement effectif selon le second mode de réalisation de l'invention sont notamment mis en oeuvre : un distributeur automatique de billets 14 (ou DAB) ; - la banque 16 du DAB 14 ; - un dispositif gestionnaire 13 (par exemple sous la forme d'un serveur informatique encore appelé serveur gestionnaire) ; la banque 64 du bénéficiaire ; un dispositif de contrôle 17 (mis en oeuvre, par exemple, par une banque individuelle et/ou par un Groupement d'Intérêt Economique (ou GIE) des cartes bancaires) ; et un terminal 66 (par exemple un ordinateur).

Selon le second mode de réalisation de l'invention, le dispositif gestionnaire 13 est par exemple localisé à l'extérieur de la banque DAB 16, mais peut échanger des informations avec celle-ci. Des adaptations peuvent être nécessaires pour établir une connexion entre le serveur de la banque 16 et le dispositif gestionnaire 13.

Bien entendu, selon une variante du second mode de réalisation, le dispositif gestionnaire 13 peut être intégré au réseau bancaire de la banque 16. a-Phase de demande Préalablement à la demande de virement, le bénéficiaire peut par exemple se connecter, via une liaison 144 mettant oeuvre un protocole de communication de transfert de fichier sécurisé (par exemple HTTPS selon le protocole de cryptage SSL à 128 bits), au site Internet du serveur gestionnaire 13 pour s'inscrire et s'enregistrer. Au cours de l'inscription, le bénéficiaire fournit par exemple son numéro de compte international (ou numéro IBAN), son nom, son adresse postale, son adresse e-mail, ... Lorsque l'inscription a été validée par le serveur gestionnaire 13, des identifiants de connexion (par exemple un login, un mot de passe ...) ainsi qu'un numéro unique client (encore appelé information de validation) permettant d'identifier le compte en banque à créditer lors du virement sont par exemple envoyés (première transmission) au bénéficiaire par le serveur gestionnaire 13. Le numéro unique client est encore appelé information d'identification du bénéficiaire.

Dès lors, s'il le désire, le bénéficiaire peut demander à l'émetteur de lui virer de l'argent. Il lui suffit par exemple pour cela de fournir (seconde transmission) son numéro unique client (qui correspond à un numéro de compte bancaire), ainsi que le montant de la somme à virer sur son compte en banque (encore appelé montant du flux monétaire). Le numéro unique client ainsi que le montant de la somme à virer peuvent être transmis à l'émetteur par exemple par e-mail, courrier postale, téléphone, SMS, fax, ... Bien entendu, selon une variante, le bénéficiaire peut se connecter au site Internet du serveur gestionnaire 13 pour effectuer une demande de virement à l'émetteur en entrant des informations relatives à l'émetteur comme par exemple son numéro de téléphone, son adresse e-mail, son numéro de fax, son adresse postale ... Le serveur gestionnaire 13 peut par exemple se charger de relayer (par exemple par e-mail) la demande de virement auprès de l'émetteur en lui communiquant par exemple le numéro unique client du bénéficiaire, ainsi que le montant du virement (information représentative du montant du flux monétaire). b-Phase de virement On présente ci-après, en relation avec la figure 7, les différentes étapes intervenant lors de la phase de virement d'un flux monétaire selon le second mode de réalisation de l'invention. Préalablement au déclenchement de la phase de paiement, l'émetteur peut par exemple insérer sa carte bancaire dans un distributeur automatique de billets 14 (ou DAB) relié à la banque 16 (encore appelée banque DAB), et ensuite composer son numéro confidentiel de carte bancaire. La phase de virement débute par exemple une fois que le code confidentiel a été validé. L'émetteur peut effectuer ces opérations préalables dans un DAB 14 quelconque, qui peut appartenir à banque différente de celle du compte de l'émetteur, sous réserve qu'elle mette en oeuvre le programme gestionnaire du dispositif gestionnaire.

La mise en oeuvre du logiciel gestionnaire peut notamment nécessiter des adaptations de l'interface graphique des DAB. Ces adaptations sont par exemple réalisées par les banques elles-mêmes. Dans une étape 71, l'émetteur peut par exemple sélectionner le mode de paiement appelé virement d'argent contrôlé par le serveur gestionnaire 13. Lorsque le mode précité a été sélectionné, l'émetteur peut par exemple saisir le numéro unique de client qu'il a reçu ainsi que le montant du virement demandé par le bénéficiaire, puis peut par exemple valider ces informations en sélectionnant l'onglet Valider virement . Les informations numéro unique de client du bénéficiaire (qui correspond à une information représentative du second compte) et montant du virement (encore appelé information représentative du montant du flux monétaire)sont par exemple transmises (troisième transmission et étape d'obtention) à la banque DAB 16 via une liaison 140 mettant en oeuvre un protocole bancaire normalisé, par exemple les protocoles de cryptage bancaire CBSA ou CBPR sur 25X. Ensuite, lors d'une étape 72, un contrôle du compte bancaire de l'émetteur peut par exemple être réalisé par un dispositif de contrôle 17 afin de vérifier une opposition éventuelle sur le compte bancaire et demander l'autorisation de débiter le compte (ce qui consiste à vérifier que le montant du flux monétaire est disponible sur le compte l'acheteur). L'échange d'information entre la banque DAB 16 et le dispositif de contrôle 17 s'effectue par exemple au moyen d'une liaison 126 conforme à un protocole bancaire normalisé, par exemple les protocoles de cryptage bancaire CBSA ou CBPR sur X25. Après l'envoi de l'autorisation de paiement par le dispositif de contrôle 17, la banque DAB 16 peut par exemple établir, au cours d'une étape 73, une connexion avec le serveur gestionnaire 13 via une liaison conforme à un protocole bancaire normalisé (par exemple les protocoles de cryptage bancaire CBSA ou CBPR sur X25) pour authentifier le bénéficiaire du virement. La banque DAB 16 peut par exemple transmettre le numéro unique client du bénéficiaire.

Lorsque le bénéficiaire a été authentifié, le serveur gestionnaire 13 envoie par exemple en retour à la banque DAB 16, au cours d'une étape 74, des informations relatives au bénéficiaire (par exemple le numéro de compte international IBAN). Au cours d'une étape 75, la banque DAB 16 peut par exemple débiter le compte en banque de l'émetteur du montant indiqué pour en effectuer le virement sur le compte en banque du bénéficiaire dans la banque 64. La procédure de virement (encore appelé transfert du flux monétaire) mise en oeuvre au cours de l'étape 75 peut correspondre à une procédure de fonctionnement classique entre banques. Simultanément, la banque DAB 16 transmet par exemple une confirmation de virement (encore appelé information de transfert avec succès ) au serveur gestionnaire 13.

Il est par ailleurs envisageable que le bénéficiaire puisse se connecter au serveur gestionnaire 13, via ses identifiants de connexion, pour contrôler et visualiser en direct les virements effectués sur son compte en banque domicilié dans la banque 64. Par ailleurs, toutes les informations de confirmation de virement (information représentative d'un transfert de flux monétaire inter-bancaire) peuvent être stockées (étape de stockage) sur le serveur gestionnaire 13. De manière optionnelle, lors d'une étape 76, le serveur gestionnaire 13 envoie un message au bénéficiaire (par exemple un e-mail ou un SMS) pour l'informer que le virement a bien été effectué sur son compte en banque (information de transfert avec succès ).

Selon une variante du second mode de réalisation,, l'émetteur peut déclencher la phase de virement par l'envoi classique d'un SMS à la banque personnelle 65 via son téléphone portable 67, tel qu'illustré sur la figure 8. Cependant, la confirmation de virement de la commande par téléphone portable n'est par exemple possible que lorsque l'émetteur s'est préalablement enregistré et a souscrit un contrat de confirmation de virement par téléphone avec sa banque personnelle 65 (où est domicilié son compte). Lors de la souscription d'un contrat de confirmation de virement par téléphone , la banque personnelle 65 peut par exemple fournir à l'émetteur un code secret permettant son authentification (encore appelé code secret émetteur). On décrit ci-après, en relation avec la figure 9, les différentes étapes mises en oeuvre lors de la phase de virement, selon la variante du second mode de réalisation de l'invention. Ainsi, lors d'une étape 91, l'émetteur envoie par exemple, au serveur gestionnaire 13, un SMS comprenant le numéro unique client du bénéficiaire, le code secret émetteur ainsi que le montant du virement. Dans une étape 92 d'authentification, la banque personnelle 65 peut par exemple vérifier le code secret émetteur contenu dans le SMS pour authentifier l'émetteur. La suite du virement selon la variante du second mode de réalisation est identique à ce qui a été décrit précédemment lors des étapes 72 à 76 de la confirmation de virement via un distributeur automatique de billet 14, excepté le fait que la banque DAB 16 est remplacée par la banque personnelle 65. Par ailleurs, on peut prévoir une étape de rétribution de l'organisme propriétaire du dispositif gestionnaire 13, par exemple sous la forme du versement d'une commission pour chaque virement effectué. Bien entendu, l'invention n'est pas limitée aux exemples de réalisation mentionnés ci-dessus. En particulier, l'Homme du Métier pourra apporter toute variante au procédé de transfert sécurisé d'un flux monétaire de l'invention.

En effet, l'invention s'applique également au règlement des factures quotidiennes (par exemple d'eau, de gaz, d'électricité, ...), mais également des contraventions.

L'invention s'applique bien sûr au paiement d'une commande Internet en plusieurs fois. En outre, l'invention s'applique aux clients utilisant des portefeuilles électroniques ou des banques virtuelles (par exemple PAYPAL marque déposée, PAYNOVA marque déposée, ...) afin qu'ils puissent alimenter leurs comptes virtuels en utilisant le serveur gestionnaire de l'invention et en validant ces opérations au I)AB ou par SMS.

Claims (16)

REVENDICATIONS

1. Procédé de transfert sécurisé via un réseau de communication d'un flux monétaire d'un premier compte en banque d'un premier utilisateur dans une première banque (16) vers un second compte en banque d'un second utilisateur dans une seconde banque (15), caractérisé en ce qu'il comprend les étapes suivantes : - première transmission (24), par un dispositif gestionnaire (13), d'une information de validation du transfert dudit flux monétaire au second utilisateur ; - seconde transmission (25), par ledit second utilisateur, de ladite information de validation au premier utilisateur ; - troisième transmission (31 ; 71), par ledit premier utilisateur, de ladite information de validation à la première banque ; -transfert (36 ; 75) du flux monétaire de la première banque à la seconde banque si chacune des première, seconde et troisième transmissions a eu lieu.

2. Procédé de transfert sécurisé selon la revendication 1, caractérisé en ce qu'il comprend également une étape d'obtention, par la première banque, d'au moins une information représentative du montant du flux monétaire et d'au moins une information représentative du second compte afin de pouvoir mettre en oeuvre ladite étape de transfert (36 ; 75).

3. Procédé de transfert sécurisé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ledit procédé de transfert sécurisé est un procédé de paiement sécurisé d'un produit et/ou service par le premier utilisateur, dit utilisateur acheteur, au second utilisateur, dit utilisateur vendeur, ledit utilisateur acheteur et ledit utilisateur vendeur mettant en oeuvre une transaction en commerce électronique sur le réseau de communication pour la vente dudit produit et/ou service, ledit procédé comprenant l'étape préalable suivante : - sélection (21) dudit produit et/ou service par l'utilisateur acheteur au moyen d'une interface d'un serveur vendeur de l'utilisateur vendeur.

4. Procédé de transfert sécurisé selon la revendication 3, caractérisé en ce qu'il comprend également l'étape préalable suivante : - transmission (23), par l'utilisateur vendeur au dispositif gestionnaire, d'au moins une information représentative dudit produit et/ou service.

5. Procédé de transfert sécurisé selon l'une quelconque des revendications 3 et 4, caractérisé en ce qu'il comprend également les étapes suivantes : - prélèvement (32) dudit montant sur le premier compte ; - stockage (32) temporaire dudit montant dans la première banque ; - vérification d'une condition avant de mettre en oeuvre ladite étape de transfert du flux monétaire de la première banque à la seconde banque.

6. Procédé de transfert sécurisé selon la revendication 5, caractérisé en ce que ladite condition est l'une au moins des conditions appartenant au groupe comprenant les conditions suivantes : - un délai prédéterminé entre la troisième transmission et une fourniture du produit et/ou service au premier utilisateur n'est pas écoulé ; - un délai prédéterminé entre la seconde transmission et la troisième transmission n'est pas écoulé ; - le premier utilisateur n'a pas annulé ladite transaction ; - le produit et/ou service est disponible en stock.

7. Procédé de transfert sécurisé selon l'une quelconque des revendications 3 à 6, caractérisé en ce que la troisième transmission (31), par ledit premier utilisateur, de ladite information de validation à la première banque (16) est mise en oeuvre au moyen d'un distributeur automatique de billet (14) appartenant à ladite première banque.

8. Procédé de transfert sécurisé selon l'une quelconque des revendications 3 à 6, caractérisé en ce que la troisième transmission (31), par ledit premier utilisateur, de ladite information de validation à la première banque (16) est mise en oeuvre au moyen d'un terminal de validation appartenant à ladite première banque.

9. Procédé de transfert sécurisé selon l'une quelconque des revendications 3 à 6, caractérisé en ce que la troisième transmission (31), par ledit premier utilisateur, de ladite information de validation à la première banque (16) comprend les étapes suivantes - transmission (51), par le premier utilisateur au dispositif gestionnaire (13), d'un message électronique comprenant ladite information de validation - transmission (52) par le dispositif gestionnaire (13) à la première banque (16), de ladite information de validation.

10. Procédé de transfert sécurisé selon l'une quelconque des revendications 1 et 2, ledit procédé de transfert sécurisé étant un procédé de virement bancaire sécurisé du flux monétaire depuis le premier compte bancaire vers le second compte bancaire, caractérisé en ce que l'information de validation comprend au moins une information d'identification du second compte bancaire et au moins une information représentative du montant du flux monétaire.

11. Procédé de transfert sécurisé selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il comprend une étape de stockage d'au moins une information représentative d'un transfert d'un flux monétaire entre la première banque et la seconde banque.

12. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce que le réseau de communication est le réseau Internet.

13. Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce qu'au moins certaines desdites informations sont échangées sous forme cryptée.

14. Système de transfert sécurisé via un réseau de communication d'un flux monétaire d'un premier compte en banque d'un premier utilisateur dans une première banque (16) à un second compte en banque d'un second utilisateur dans une seconde banque (15), caractérisé en ce qu'il comprend : des premiers moyens de transmission d'une information de validation du transfert dudit flux monétaire au second utilisateur, lesdits premiers moyens de transmission 20 appartenant à un dispositif gestionnaire (13) ; - des seconds moyens de transmission, par le second utilisateur, de ladite information de validation au premier utilisateur ; des moyens de réception de ladite information de validation, lesdits moyens de réception appartenant à la première banque ; 25 - des moyens de transfert du flux monétaire de la première banque à la seconde banque.

15. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké par un ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution 30 des étapes du procédé de transfert sécurisé selon l'une quelconque des revendications 1 à 13, lorsque ledit programme est exécuté sur un ordinateur.

16. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de transfert sécurisé selon l'une quelconque des revendications 1à13.5