FR2826755A1

FR2826755A1 - Procede de transaction en ligne

Info

Publication number: FR2826755A1
Application number: FR0108739A
Authority: FR
Inventors: Karim Benjelloun; Eric Mouyal
Original assignee: MUCASH
Current assignee: MUCASH
Priority date: 2001-06-29
Filing date: 2001-06-29
Publication date: 2003-01-03

Abstract

Le procédé de transaction électronique à distance est mis en oeuvre entre un acheteur muni d'un premier équipement informatique (C) et un vendeur muni d'un deuxième équipement informatique (B). Il fait aussi intervenir un tiers gérant des comptes à l'aide d'un troisième équipement informatique (A). Le procédé comprend les étapes successives suivantes :a) envoi par le deuxième équipement (B) vers le troisième équipement (A) d'un projet de transaction comprenant un identifiant du marchand et le prix de la transaction;b) mémorisation par le troisième équipement (A) du projet de transaction et d'un identifiant de transaction spécifique au projet de transaction;c) envoi par le premier équipement (C) vers le troisième équipement (A) de l'identifiant de transaction et d'au moins un identifiant de compte;d) décrémentation par le troisième équipement (A) du compte correspondant à l'identifiant de compte d'un montant correspondant à au moins une partie du prix de la transaction. Le procédé est particulièrement adapté au cas de comptes anonymes gérés par le tiers.

Description

/""...

PROCEDE DE TRANSACTION EN LIGNE
La présente invention concerne un procédé de transaction électronique à distance, utilisant par exemple le réseau Internet, entre un acheteur et un vendeur avec l'intervention d'un tiers gérant des comptes, en particulier, des comptes prépayés anonymes.

Un but de l'invention est de proposer un procédé de transaction électronique qui présente une grande sécurité à l'encontre des risques de fraude.

Un autre but de l'invention est que le procédé soit apte à mettre les parties à la transaction en confiance l'une vis-à-vis de l'autre, c'est-à-dire qu'il permette notamment d'assurer le paiement effectif du prix de la transaction et qu'il soit de nature à éviter les contestations sur l'objet et/ou les modalités de la transaction.

A cette fin, la présente invention propose un procédé de transaction électronique à distance entre un acheteur utilisant un premier équipement informatique et un vendeur utilisant un deuxième équipement informatique, avec l'intervention d'un tiers gérant des comptes à l'aide d'un troisième équipement informatique, le procédé comprenant les étapes successives suivantes : a) envoi par le deuxième équipement vers le troisième équipement d'un projet de transaction comprenant un identifiant du marchand et le prix de la transaction ; b) mémorisation par le troisième équipement du projet de transaction et d'un identifiant de transaction spécifique au projet de transaction ; c) envoi par le premier équipement vers le troisième équipement de l'identifiant de transaction et d'au moins un identifiant de compte ; d) décrémentation par le troisième équipement du compte correspondant à l'identifiant de compte d'un montant correspondant à au moins une partie du prix de la transaction.

Le compte correspondant à l'identifiant de compte peut être anonyme.

Selon un mode de réalisation préféré, l'envoi-dans l'étape a)-par le deuxième équipement vers le troisième équipement du projet de transaction est accompagné d'une signature électronique du vendeur.

Selon un autre mode de réalisation préféré, l'étape b) comprend en outre la définition de l'identifiant de transaction par le troisième équipement et l'envoi par le troisième équipement vers le deuxième équipement de l'identifiant de transaction. Le troisième équipement peut définir l'identifiant de transaction suivant une numérotation discontinue des projets de transaction, l'identifiant de transaction étant de préférence défini indépendamment de celui défini précédemment, et plus avantageusement, l'identifiant de transaction est défini de façon aléatoire. Par ailleurs, l'envoi par le troisième équipement vers le deuxième équipement de

l'identifiant de transaction est de préférence faite par une liaison sécurisée assurant la confidentialité de l'identifiant de transaction. Le procédé peut aussi comprendre entre l'étape b) et l'étape c), l'étape suivante : bl) envoi par le deuxième équipement vers le premier équipement de l'identifiant de transaction, cet envoi se faisant de préférence par une liaison sécurisée assurant la confidentialité de l'identifiant de transaction.

Suivant une variante, l'étape a) comprend en outre la définition de l'identifiant de transaction par le deuxième équipement et l'envoi par le deuxième équipement vers le troisième équipement de l'identifiant de transaction.

Selon ecore un autre mode de réalisation préféré, l'étape c) comprend les sous- étapes suivantes : cl) envoi par le premier équipement vers le troisième équipement de l'identifiant de transaction ; c2) envoi par le troisième équipement vers le premier équipement du projet de transaction ; c3) envoi par le premier équipement vers le troisième équipement de l'identifiant de compte ;
Selon encore un autre mode de réalisation préféré, le troisième équipement ne réalise pas l'étape d) s'il n'a pas reçu du premier équipement l'identifiant de transaction envoyé selon l'étape c) dans un délai de temps prédéterminé.

Selon encore un autre mode de réalisation préféré, le procédé comprend, entre l'étape c) et l'étape d), une étape e) de : el) vérification par le troisième équipement que l'identifiant de compte envoyé par le premier équipement suivant l'étape c) correspond à un compte géré par lui ; et e2) si la vérification de la sous-étape el) est négative, envoi par le troisième équipement vers le premier équipement d'un message indiquant que l'identifiant de compte envoyé n'est pas valable.

De préférence, dans la sous-étape e2), le troisième équipement n'autorise l'envoi d'un autre identifiant de compte qu'après un certain temps depuis la réception de l'identifiant de compte, ce temps augmentant en fonction du nombre d'identifiants de comptes envoyés précédemment en relation avec cet identifiant de transaction et dont la vérification suivant la sous-étape el) était négative.

En variante, l'étape e) comprend la sous-étape suivante : e3) si la vérification de la sous-étape el) est négative et qu'ensuite le troisième équipement reçoit un autre identifiant de compte pour ledit identifiant de transaction, le troisième équipement ne réalise l'étape d) que si cet autre identifiant de compte est reçu après un certain temps depuis la réception de l'identifiant de compte envoyé précédemment et dont la vérification selon la sous-étape el) était négative, ce temps

augmentant en fonction du nombre d'identifiants de comptes envoyés précédemment en relation avec cet identifiant de transaction et dont la vérification selon la sous- étape el) était négative.

Selon encore un autre mode de réalisation préféré, entre la réception par le troisième équipement de l'identifiant de transaction envoyé par le premier équipement selon l'étape c) jusqu'à la réalisation de l'étape d) ou de la sous-étape e2) ou e3), le troisième équipement n'autorise pas la réalisation mutadis mutandis de l'étape c) par un quatrième équipement informatique et/ou n'effectue pas l'étape d) pour l'identifiant de compte envoyé par ce quatrième équipement.

Selon encore un autre mode de réalisation préféré, dans l'étape a), le projet de transaction comprend en outre l'identification de l'objet et/ou des modalités de la transaction.

Selon encore un autre mode de réalisation préféré, l'étape d) comprend en outre l'envoi par le troisième équipement vers le deuxième équipement, et de préférence aussi vers le premier équipement, d'un message indiquant la réalisation de la transaction.

L'invention propose également un équipement informatique mettant en oeuvre les étapes exécutées par le troisième équipement informatique dans le procédé selon l'invention.

L'invention propose enfin un équipement informatique mettant en oeuvre les étapes exécutées par le deuxième équipement informatique dans le procédé selon l'invention.

D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d'un mode de réalisation préféré de l'invention, donnée à titre d'exemple et en référence au dessin annexé.

La figure 1 illustre le flux des données entre les équipements informatiques intervenant dans la mise en oeuvre du procédé de l'invention selon un mode de réalisation préféré.

La lettre B correspond à un équipement informatique mettant à disposition sur le réseau Internet-avantageusement un site Internet-un catalogue de produits et/ou de services d'un marchand. Ces produits ou services seront pas la suite désignés par le mot articles .

La lettre C correspond à un équipement informatique connecté à Internet dont un intemaute va se servir pour acheter en ligne. Il s'agit typiquement d'un ordinateur de type courant tel qu'un ordinateur compatible PC, équipé d'un navigateur Internet existant et supportant SSL (abréviation anglaise de Secure Socket Layer ) tel que Microsoft Internet Explorera ou Netscape Navigator@.

La lettre A représente l'équipement informatique d'un tiers connecté à Internet, typiquement un serveur, qui assure la gestion pécuniaire de comptes prépayés virtuels anonymes.

Un compte prépayé virtuel anonyme consiste en un identifiant d'un compte détenu chez le tiers. Le solde du compte et éventuellement d'autres informations (date de validité...) liées au compte sont gérées par le serveur A. En revanche, le titulaire du compte n'est pas identifié auprès du tiers. Autrement dit, le tiers gestionnaire n'a aucune information lui permettant d'établir l'identité du titulaire du compte : ce dernier reste donc anonyme. L'identifiant de compte est généralement constitué d'un premier numéro, appelé numéro de série , et d'un deuxième numéro, appelé code secret qui garantit l'authentification du compte. Le code secret peut être le résultat d'un algorithme de chiffrage appliqué au numéro de série de la carte, mais il est préférable qu'il en soit décorrélé.

L'intemaute pourra par exemple acquérir le compte sous forme d'une carte prépayée auprès d'un distributeur. Le compte correspondant à la carte est initialement crédité d'un montant égal-en principe-à son prix d'achat.

L'identifiant de compte est généralement inscrit sur le support physique que constitue la carte, qui indique également sa valeur, c'est-à-dire le montant crédité sur le compte correspondant. Pour éviter qu'il ne soit accessible à quiconque avant l'achat de la carte, l'identifiant de compte, ou au moins le code secret, est généralement recouvert d'un film opaque grattable. Ainsi, après l'avoir acheté, l'intemaute gratte le film pour connaître l'identifiant de compte et est assuré d'être le seul à le connaître.

Par ailleurs, le marchand ayant son catalogue sur le serveur B est référencé chez le tiers gestionnaire de comptes A.

Une transaction électronique a lieu comme suit en plusieurs phases. Sur la figure 1, à chaque échange de données correspond une flèche numérotée.

Dans une phase préalable (flèche 0), l'intemaute se connecte avec son équipement C au serveur B du marchand pour visiter son site et consulter son catalogue d'articles. Le site Internet du marchand permet à l'intemaute de sélectionner les articles qu'il souhaite acheter, ce qui peut être réalisé de façon connue en soi. Cette phase préalable peut éventuellement être réalisée par le biais d'une première liaison sécurisée pour rendre l'échange de données inintelligible aux tiers. Il pourra s'agir classiquement d'une liaison SSL.

Quand il a fini sa sélection d'articles et qu'il souhaite régler son achat à l'aide de son compte prépayé virtuel, l'intemaute sélectionne par exemple un bouton dans la page Internet du site du marchand. Le serveur B envoie alors vers le serveur A des données concernant la transaction en cours qui comprennent un identifiant du

marchand et le prix total des articles choisis par l'intemaute (flèche 1). Ces données concernant la transaction en cours envoyées par le serveur B au serveur A peuvent être avantageusement accompagnées de la signature électronique du vendeur. Par signature électronique, l'on entend classiquement des données sous forme électronique contenues dans le message de données, ou jointes et logiquement associées audit message, et pouvant être utilisées pour identifier le signataire du message, et indiquer qu'il approuve l'information qui y est contenue. Il pourra s'agir typiquement d'une signature numérique, en particulier, telle que définie dans la norme ISO 7498-2. A titre d'exemple, il peut être recouru au système de cryptage PGP@ (ou Pretty Good Privacy ) pour générer la signature numérique. Le fait que les données de la transaction en cours soit signée électroniquement permet d'assurer classiquement l'authenticité de l'origine des données ainsi que leur intégrité, et donc la non-répudiation de ces données par le vendeur. De ce fait, le tiers gestionnaire de comptes pourra jouer le rôle d'un tiers neutre pouvant fournir à titre de preuve les donnée relatives à la transaction en cas de contestation ultérieur entre le vendeur et l'acquéreur. Cet aspect du procédé tend à augmenter la confiance à la fois des vendeurs et des acquéreurs dans le procédé de transaction.

Par ailleurs, étant donné que le projet de transaction est envoyé du serveur B au serveur A sans passer par l'intermédiaire de l'ordinateur C, l'intemaute n'a aucune possibilité de modifier de façon frauduleuse le projet de transaction avant qu'il soit reçu et mémorisé par le serveur A.

Bien que cela ne soit pas indispensable, le serveur B peut envoyer ces données vers le serveur A par une deuxième liaison sécurisée-par exemple du type SSL-si l'on souhaite assurer la confidentialité de la transaction.

Après la réception des données concernant la transaction et après leur décryptage le cas échéant, le serveur A définit un identifiant spécifique à cette transaction. Autrement dit, l'identifiant de transaction permet au serveur A d'identifier précisément chaque transaction parmi l'ensemble de toutes les transactions qui lui ont été transmises par tous les vendeurs affiliés auprès du tiers gestionnaire de comptes. Cet identifiant est avantageusement un nonce contraction de l'anglais no-once used . Un nonce est un numéro qui n'a jamais été utilisé jusque-là. Il est de préférence défini pour être difficilement devinable. Il est avantageux que le nonce soit un nombre tiré au hasard, par exemple, sur 128 bits par le serveur A.

Le serveur A associe l'identifiant de transaction aux données concernant la transaction et mémorise le tout. Par ailleurs, il envoie l'identifiant de transaction vers le serveur B (flèche 2). Cet envoi se fait de préférence à travers une liaison sécurisée

- par exemple du type SSL-pour assurer la confidentialité de l'identifiant de transaction, et donc éviter que des tiers puissent en prendre connaissance.

A réception de l'identifiant de transaction, le serveur B le transmet à l'ordinateur C (flèche 3) également de préférence à travers une liaison sécurisée telle qu'une liaison SSL, pour continuer à assurer la confidentialité de l'identifiant de transaction ; il pourra s'agir de la première liaison sécurisée précitée.

L'ordinateur C envoie l'identifiant de transaction au serveur A de préférence par le biais d'une troisième liaison sécurisée (flèche 4). En fait, il est avantageux que cette liaison soit établie et l'identifiant de transaction envoyé au serveur A, sans l'intervention de l'intemaute. Pour cela, le serveur B peut provoquer une redirection HTTPS (adaptation de HTTP sur SSL).

En pratique, il est préférable que le serveur A considère que la transaction en cours est abandonnée si l'identifiant de transaction ne lui est pas présenté via Internet dans un délai prédéterminé à compter du moment où il a reçu du serveur B les données relatives à la transaction en cours ou, en variante, à partir du moment où il a communiqué l'identifiant de transaction correspondant au serveur B. Si la transaction est considérée comme abandonnée, le serveur A inscrit dans sa mémoire ce statut et en informe de préférence le serveur B. Dans ce cas, le serveur A ne permettra pas à l'intemaute ou qui que ce soit d'autre, de finaliser la transaction-de la manière décrite qui suit-dans le cas où il présente ultérieurement au serveur A l'identifiant de transaction concerné ; il sera simplement informé que la transaction est abandonnée et l'intemaute devra recommencer depuis le début le processus de transaction (flèche 0).

Si l'identifiant de transaction est reçue par lui en temps voulu, le serveur A envoie en réponse un formulaire à l'ordinateur C par exemple sous la forme d'une page web (flèche 5). Ce formulaire contient les données-de préférence au moins le nom du marchand et le montant de la transaction à régler-concernant la transaction correspondant à cet identifiant de transaction ou, en variante, permet à l'intemaute de consulter ces données en sélectionnant un bouton de la page web. Par ailleurs, le formulaire présente un champ pour recevoir un ou plusieurs identifiants de comptes prépayés virtuels.

Si l'intemaute souhaite effectivement finaliser la transaction et donc payer, il rempli ce formulaire avec le ou les identifiants de comptes prépayés qu'il a préalablement achetés. L'ordinateur C retourne le formulaire rempli au serveur A via la troisième liaison sécurisée (flèche 6).

Le serveur A vérifie alors l'authenticité de ou des identifiants de comptes, puis si le solde de ce ou ces comptes sont suffisants pour payer le montant de la transaction concernée.

Dans l'affirmative, le serveur A peut d'abord envoyer un message à l'ordinateur C pour informer l'intemaute que la transaction peut être finalisée et attend en retour un message de l'ordinateur C pour confirmer l'accord de l'intemaute pour réaliser la transaction. Cette étape est optionnelle car il est possible de considérer que le seul fait pour l'intemaute de fournir un identifiant de compte vaut accord de sa part pour réaliser la transaction. Le serveur A envoie alors au serveur B une confirmation de la transaction avec l'identifiant de la transaction à travers la deuxième liaison sécurisée (flèche 7). Le marchand sait alors que la transaction est finalisée et qu'il doit mettre à disposition ou livrer les articles faisant l'objet de la transaction.

Avantageusement, le serveur B accuse réception au serveur A de la confirmation de la transaction avec l'identifiant de la transaction via le deuxième liaison sécurisée (flèche 8). Dans le cas où le serveur A ne reçoit pas l'accusé de réception du serveur B, le serveur A réenvoie régulièrement la confirmation de la transaction avec l'identifiant de la transaction jusqu'au moment où il recevra effectivement cet accusé de réception.

Par ailleurs, le serveur A envoie à l'ordinateur C via la troisième liaison sécurisée une page web contenant une confirmation de la transaction ainsi que le nouveau solde de ses comptes prépayés (flèche 7bis). Par ailleurs, elle peut contenir un lien HTML pour permettre de revenir sur le site du marchand géré par le serveur B dans le cas où c'est une redirection HTTPS qui l'a mis en liaison avec le serveur A. Il est ainsi mis fin à la troisième liaison sécurisée car la transaction ne nécessite plus d'interaction entre l'intemaute et le gestionnaire de compte.

L'envoi de la confirmation de transaction et du nouveau solde des comptes à l'ordinateur C (flèche 7bis) peut être effectué, soit déjà avant, soit uniquement après réception par le serveur A de l'accusé de réception envoyé par le serveur B (flèche 8). Dans ce dernier cas, le système assure qu'il n'y a plus aucun obstacle à la transaction lorsque la confirmation de transaction est adressée à l'ordinateur C.

Par ailleurs, à réception de l'accord pour réaliser la transaction qui lui est envoyé par l'ordinateur C, le serveur A débite le ou les comptes du montant de la transaction au profit du marchand et éventuellement pour une partie du montant, au profit du gestionnaire de comptes. Le versement des sommes correspondantes au profit du marchand peut par exemple avoir lieu automatiquement par le serveur A par inscription sur un compte ouvert au marchand auprès du gestionnaire de comptes ou par virement vers un compte bancaire du marchand. Par ailleurs, le serveur A met en mémoire une indication de ce que la transaction est réalisée.

Dans le cas où les articles achetés par l'intemaute consiste dans des données numériques telles que des logiciels, des fichiers de musique numérisée..., il peut être

prévu que le serveur B adjoigne à son accusé de réception adressé au serveur A une adresse sur le réseau à laquelle l'intemaute pourra obtenir livraison des articles en les téléchargeant. Le serveur A transmettra alors cette adresse à l'ordinateur C en même temps que la confirmation de la transaction et le nouveau solde de ses comptes.

Il est possible de prévoir une possibilité de paiement partiel dans le cas où les soldes de comptes prépayés fournis par l'intemaute ne couvre pas le montant intégral de la transaction. Dans ce cas, le serveur A peut demander à l'ordinateur C de compléter le paiement par un autre moyen de paiement telle que par carte bancaire.

En variante, le serveur A peut aussi indiquer au serveur B qu'il y a paiement partiel. Dans ce cas, c'est le serveur B qui demande à l'ordinateur C de compléter le paiement par un autre moyen de paiement. A défaut du paiement du complément par ce biais, le serveur B pourra envoyer au serveur C un message lui indiquant d'annuler la transaction et de recréditer les comptes prépayés correspondants.

Dans une variante avantageuse, le serveur B envoie vers le serveur A non seulement un identifiant du marchand et le prix total des articles choisis par l'intemaute (flèche 1), mais encore d'autres données concernant la transaction en cours permettant de définir l'objet de la transaction et/ou des modalités de la transaction. En particulier, il pourra s'agir de la liste détaillée des articles choisis. Il peut également lui envoyer le prix de chacun de ces articles, les conditions générales de vente, une adresse de livraison postale ou Internet et/ou une référence de transaction définie par le vendeur, etc. L'ensemble de ces informations est mémorisée par le serveur A avec l'identifiant de transaction qu'il aura défini. Par ailleurs, ces informations sont transmises par le serveur A à l'ordinateur C à l'attention de l'intemaute en même temps que l'identification du marchand et le montant total de la transaction (flèche 5). L'intemaute peut ainsi vérifier si les articles et le montant total de la transaction-et les autres modalités de la transaction selon les informations fournis en plus-correspondent à ce qu'il avait choisi sur le site du marchand. Dans l'affirmative, l'intemaute enverra au serveur A son ou ses identifiants de compte comme décrit précédemment pour finaliser la transaction.

Dans ce mode de réalisation, le gestionnaire de comptes peut donc avantageusement remplir le rôle d'un tiers neutre certifiant l'objet de la transaction en cas de différents survenant entre le marchand et l'acheteur car les informations concernant la transaction sont conservées en mémoire du serveur A aussi longtemps que souhaité et peuvent donc être produites par le gestionnaire de comptes à titre de preuve. Autrement dit, l'internaute et le marchand peuvent réaliser la transaction en toute confiance grâce au gestionnaire de comptes.

Les comptes gérés par le serveur A bénéficie de plusieurs niveaux de sécurisation contre des tentatives de fraude.

Un premier niveau est lié à l'emploi de l'identifiant de transaction. Pour qu'un intemaute puisse envoyer un identifiant de compte au serveur A, il faut qu'il lui envoie préalablement un identifiant de transaction valide. En d'autres termes, le serveur A vérifie si l'identifiant de transaction envoyé par l'intemaute correspond effectivement à un identifiant déjà affecté à une transaction dans sa mémoire et s'il correspond à une transaction qui est encore en cours, c'est-à-dire pour lequel il n'y a pas l'indication de réalisation ou d'abandon de la transaction en mémoire. Dans la négative, le serveur A ne permettra pas à l'intemaute de lui envoyer d'identifiants de comptes et par conséquent, l'intemaute ne peut pas essayer d'entrer des numéros de comptes au hasard pour essayer d'en trouver un qui soit valide.

De plus, lorsque comme décrit plus haut, la durée pendant laquelle un intemaute peut valablement présenter un identifiant de transaction au serveur C à compter de son attribution par celui-ci est limitée et qu'au-delà la transaction est considérée comme abandonnée, il est extrêmement difficile pour un éventuel fraudeur de découvrir un identifiant de transaction correspondant à une transaction encore en cours.

De ce point de vue, la sécurité est accrue du fait que les identifiants de transaction sont difficilement devinables. Ainsi, un intemaute qui initie une transaction sur le site d'un vendeur pourra obtenir un identifiant de transaction correspondant sans pour autant pouvoir déterminer les identifiants de transaction précédents ou suivants. Ainsi, l'on évite une tentative de fraude consistant pour un intemaute à utiliser parallèlement plusieurs ordinateurs connectés à Internet et adressant au serveur C chacun un identifiant de transaction qui a été deviné pour ensuite tester auprès du serveur C des numéros de compte hypothétiques pour en trouver au moins un qui soit valable.

Enfin, il est avantageux que le serveur C soit programmé pour éviter que plusieurs ordinateurs d'internautes puissent lui faire parvenir chacun des identifiants de comptes de façon parallèle pour un même identifiant de transaction valable.
Autrement dit, dès lors qu'il reçoit un identifiant de transaction valable envoyée par un ordinateur C, le serveur A lui enverra le formulaire de saisie d'un identifiant de compte (flèche 5). Tant que durera le traitement de cette transaction entre le serveur
A et cet ordinateur C, aucun autre ordinateur C ne pourra obtenir le formulaire de saisie d'identifiant de compte pour ce même identifiant de transaction. Cela évite qu'un internaute initie une transaction sur le site d'un vendeur dans le but d'obtenir un identifiant de transaction qui est ensuite présenté simultanément au serveur C par

plusieurs ordinateurs dont chacun présente ensuite une série de numéros de comptes hypothétiques pour essayer d'en découvrir un ou plusieurs qui soient valables.

Un deuxième niveau de protection est lié à l'authentification de l'identifiant de compte. Lorsque l'intemaute a fourni un identifiant de transaction valide, le serveur A lui demande de lui faire parvenir au moins un identifiant de compte. Sur réception de ce dernier, le serveur A vérifie l'authenticité de l'identifiant de compte. Si l'identifiant fourni n'est pas valide, le serveur A enverra un message à l'ordinateur C pour en informer l'intemaute et lui demander de ressaisir son identifiant de compte et ainsi de suite. Néanmoins, le serveur A pourra déterminer un temps minimal depuis l'envoi d'un premier identifiant de compte non valide avant d'autoriser l'ordinateur C de lui réenvoyer un autre identifiant de compte. Ce temps minimal peut en outre être augmenté à chaque nouvel identifiant de compte erroné qui aura été envoyé. L'augmentation du temps minimal peut être faite par exemple en multipliant par deux le temps précédent. Le temps minimal entre le premier essai et le second peut être en pratique de l'ordre de quelques secondes. Il en résulte qu'au fur et à mesure des essais, le temps minimal séparant deux essais successifs devient très rapidement énorme. Par conséquent, le nombre d'essais possibles devient très rapidement limité en pratique en raison du temps d'attente croissant. De la sorte, il n'est pas possible à un éventuel fraudeur de faire réaliser de façon automatique à son ordinateur C une recherche systématique pour essayer de trouver un identifiant de compte valable par exemple par simple incrémentation d'un nombre.

Par ailleurs, un avantage du procédé de l'invention est de pouvoir être mis en oeuvre pour ce qui concerne l'ordinateur C en ne recourant qu'aux navigateurs Internet classiques du marché. L'intemaute n'a donc pas besoin de se procurer un logiciel dédié à la mise en oeuvre du procédé.

Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art. Ainsi, l'invention peut par exemple être mise en oeuvre avec tout réseau numérique de transmission de données autre que Internet.

Par ailleurs, l'identifiant de transaction a été décrit comme étant défini par le serveur A du gestionnaire de compte. En variante, cet identifiant peut être défini par le serveur B du marchand. Le serveur B l'enverra alors via le réseau à la fois au serveur A pour mémorisation avec les autres données concernant la transaction et à l'ordinateur C pour le porter à la connaissance de l'intemaute. L'identifiant de transaction inclut dans ce cas un identifiant du marchand pour assurer que les identifiants de transaction mémorisés par le serveur A soient uniques par rapport à

l'ensemble des transactions transmis au serveur C par les vendeurs affiliés. Le reste du processus de transaction est identique.

Dans un autre mode de réalisation, l'étape d'envoi de l'identifiant de transaction du serveur B à l'ordinateur C (flèche 3) est supprimée. Dans ce cas, le vendeur informera l'intemaute de l'identifiant de transaction par tout moyen adéquat tel que par exemple un courrier postal. L'intemaute se connectera alors avec son ordinateur C au serveur A pour lui envoyer l'identifiant de transaction comme précédemment (flèche 5) et le procédé se poursuit comme déjà décrit. Ce mode de réalisation permet par exemple au vendeur d'envoyer par courrier postal ou autre des propositions commerciales personnalisées à des clients en y indiquant l'identifiant de transaction avec la date limite de validité. Au préalable, le serveur B du vendeur aura envoyé la proposition de transaction au serveur A et qui en réponse lui aura retourné l'identifiant de transaction correspondant (flèches 1 et 2) de la même manière que pour le mode de réalisation décrit précédemment.

Le procédé de l'invention n'est évidemment pas limité au cas où les comptes du tiers sont du type prépayé anonyme. Il pourrait également s'agir de comptes nominatifs non prépayés. Ainsi, l'équipement informatique A du tiers gestionnaire de comptes pourrait gérer des paiements par des moyens de paiements autres tels que des cartes bancaires du type Carte Bleue@ ou Eurocard Mastercard@. Dans ce cas, l'identifiant de compte s'entend alors des données classiquement requises pour payer avec ce type de moyen de paiement, par exemple les nom et prénom du titulaire de la Carte Bleuet, le numéro de celle-ci et sa date d'expiration. Bien entendu, l'équipement informatique A pourra en pratique correspondre à un seul et unique serveur informatique, mais aussi à plusieurs serveurs ou ordinateurs communiquant entre eux dont chacun a la charge d'effectuer certaines des tâches dévolues à l'équipement informatique A. Ainsi, un premier serveur peut gérer et mémoriser les projets de transactions alors que le traitement du paiement par Carte Bleue (D et des comptes bancaires correspondant est déféré par le premier serveur à un deuxième serveur dédié à cette tâche. En pratique, le premier serveur pourra par exemple être mis en oeuvre par un premier acteur économique qui sous-traite le paiement par Carte Bleue@ à une banque ou un établissement financier institutionnel qui met en oeuvre de façon classique le paiement par Carte Bleuet sur son propre serveur informatique.

Bien entendu, l'équipement informatique A pourrait à la fois gérer des comptes prépayés anonymes et aussi proposer le paiement par des moyens de paiement nominatifs comme précité.

De manière générale, l'on comprendra que l'équipement informatique A du tiers peut correspondre à un seul serveur informatique, mais aussi à plusieurs

serveurs ou ordinateurs qui communiquent entre eux et se partagent les tâches pour mettre en oeuvre les étapes du procédé correspondant à cet équipement informatique. Par ailleurs, l'on comprendra que, au sens du brevet, le tiers gestionnaire de comptequi utilise l'équipement informatique A pour mettre en oeuvre le procédé-peut correspondre en réalité à plusieurs acteurs économiques qui collaborent pour mettre en oeuvre les aspects du procédé concernant l'équipement A.

Claims

REVENDICATIONS

1. Procédé sécurisé de transaction électronique à distance entre un acheteur utilisant un premier équipement informatique (C) et un vendeur utilisant un deuxième équipement informatique (B), avec l'intervention d'un tiers gérant des comptes à l'aide d'un troisième équipement informatique (A), le procédé comprenant les étapes successives suivantes : a) envoi par le deuxième équipement (B) vers le troisième équipement (A), sans passer par l'intermédiaire du premier équipement informatique (C), d'un projet de transaction comprenant un identifiant du marchand et le prix de la transaction ; b) mémorisation par le troisième équipement (A) du projet de transaction et d'un identifiant de transaction spécifique au projet de transaction ; c) envoi par le premier équipement (C) vers le troisième équipement (A) d'un identifiant de transaction et d'au moins un identifiant de compte ; d) décrémentation par le troisième équipement (A) du compte correspondant à l'identifiant de compte d'un montant correspondant à au moins une partie du prix de la transaction ; et dans lequel l'étape c) comprend le constat par le troisième équipement (A) de ce que l'identifiant de transaction envoyé par le premier équipement (C) correspond à l'identifiant de transaction spécifique au projet de transaction qui a été mémorisé par le troisième équipement.

2. Procédé selon la revendication 1, caractérisé en ce que le compte correspondant à l'identifiant de compte est anonyme.

3. Procédé selon la revendication 1 ou 2, caractérisé en ce que dans l'étape a), l'envoi par le deuxième équipement (B) vers le troisième équipement (A) du projet de transaction est accompagné d'une signature électronique du vendeur.

4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'étape b) comprend en outre la définition de l'identifiant de transaction par le troisième équipement (A) et l'envoi par le troisième équipement (A) vers le deuxième équipement (B) de l'identifiant de transaction.

5. Procédé selon la revendication 4, caractérisé en ce que le troisième équipement (A) défini l'identifiant de transaction suivant une numérotation discontinue des projets de transaction, l'identifiant de transaction étant de préférence

défini indépendamment de celui défini précédemment, et plus avantageusement, l'identifiant de transaction est défini de façon aléatoire.

6. Procédé selon la revendication 4 ou 5, caractérisé en ce que l'envoi par le troisième équipement (A) vers le deuxième équipement (B) de l'identifiant de transaction est faite par une liaison sécurisée assurant la confidentialité de l'identifiant de transaction.

7. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'étape a) comprend en outre la définition de l'identifiant de transaction par le deuxième équipement (B) et l'envoi par le deuxième équipement (B) vers le troisième équipement (A) de l'identifiant de transaction.

8. Procédé selon l'une quelconque des revendications 4 à 6, caractérisé en ce qu'il comprend entre l'étape b) et l'étape c), l'étape suivante : bl) envoi par le deuxième équipement (B) vers le premier équipement (C) de l'identifiant de transaction, cet envoi se faisant de préférence par une liaison sécurisée assurant la confidentialité de l'identifiant de transaction.

9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que l'étape c) comprend les sous-étapes suivantes : cl) envoi par le premier équipement (C) vers le troisième équipement (A) de l'identifiant de transaction ; c2) envoi par le troisième équipement (A) vers le premier équipement (C) du projet de transaction ; c3) envoi par le premier équipement (C) vers le troisième équipement (A) de l'identifiant de compte ;

10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que le troisième équipement (A) ne réalise pas l'étape d) s'il n'a pas reçu du premier équipement (C) l'identifiant de transaction envoyé selon l'étape c) dans un délai de temps prédéterminé.

11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il comprend, entre l'étape c) et l'étape d), une étape e) de : el) vérification par le troisième équipement (A) que l'identifiant de compte envoyé par le premier équipement (C) suivant l'étape c) correspond à un compte géré par lui ; et

e2) si la vérification de la sous-étape el) est négative, envoi par le troisième équipement vers le premier équipement d'un message indiquant que l'identifiant de compte envoyé n'est pas valable.

12. Procédé selon la revendication 11, caractérisé en ce que dans la sous- étape e2), le troisième équipement (A) n'autorise l'envoi d'un autre identifiant de compte qu'après un certain temps depuis la réception de l'identifiant de compte, ce temps augmentant en fonction du nombre d'identifiants de comptes envoyés précédemment en relation avec cet identifiant de transaction et dont la vérification suivant la sous-étape el) était négative.

13. Procédé selon la revendication 11, caractérisé en ce que l'étape e) comprend la sous-étape suivante : e3) si la vérification de la sous-étape el) est négative et qu'ensuite le troisième équipement reçoit un autre identifiant de compte pour ledit identifiant de transaction, le troisième équipement (A) ne réalise l'étape d) que si cet autre identifiant de compte est reçu après un certain temps depuis la réception de l'identifiant de compte envoyé précédemment et dont la vérification selon la sous-étape el) était négative, ce temps augmentant en fonction du nombre d'identifiants de comptes envoyés précédemment en relation avec cet identifiant de transaction et dont la vérification selon la sous-étape el) était négative.

14. Procédé selon l'une quelconque des revendications 1 à 13, caractérisé en ce que, entre la réception par le troisième équipement (A) de l'identifiant de transaction envoyé par le premier équipement selon l'étape c) jusqu'à la réalisation de l'étape d) ou de la sous-étape e2) ou e3), le troisième équipement (A) n'autorise pas la réalisation mutadis mutandis de l'étape c) par un quatrième équipement informatique et/ou n'effectue pas l'étape d) pour l'identifiant de compte envoyé par ce quatrième équipement.

15. Procédé selon l'une quelconque des revendications 1 à 14, caractérisé en ce que, dans l'étape a), le projet de transaction comprend en outre l'identification de l'objet et/ou des modalités de la transaction.

16. Procédé selon l'une quelconque des revendications 1 à 15, caractérisé en ce que l'étape d) comprend en outre l'envoi par le troisième équipement (A) vers le deuxième équipement (B), et de préférence aussi vers le premier équipement (C), d'un message indiquant la réalisation de la transaction.

17. Equipement informatique mettant en oeuvre les étapes exécutées par le troisième équipement informatique (A) dans le procédé selon l'une quelconque des revendications 1 à 16.

18. Equipement informatique mettant en oeuvre les étapes exécutées par le deuxième équipement informatique (B) dans le procédé selon l'une quelconque des revendications 1 à 16.