Brevet FR2956233A1 — publié le 20110812

PROCEDE DE PAIEMENT EN LIGNE ANONYME ENCADRE DONT LA SECURITE S'APPUIE SUR UN SYSTEME DE REPUTATION La présente invention, concernant le domaine des paiements en ligne, assure l'anonymat de l'acheteur tout en offrant un encadrement sur les biens et services pouvant être achetés. Dans la présente invention, la sécurité des paiements s'appuie sur la sécurisation de la chaîne de liaison technique ainsi que sur un système de réputation résultant de l'analyse du comportement des utilisateurs du système, acheteurs et vendeurs. La présente invention permet, après une procédure préalable d'enregistrement, de procéder aux paiements en un seul clic en garantissant l'anonymat de l'acheteur et le paiement du vendeur. Tout en garantissant l'anonymat, la présente invention permet au vendeur d'élaborer des offres personnalisées. Un paiement peut être annulé par la suite par le payeur, sur simple déclaration, et sans préjudice pour le bénéficiaire du paiement. Cette faculté d'annulation constitue une garantie « satisfait ou remboursé » assurée par l'opérateur de paiement. Le suivi des annulations et de leur nature permet de bâtir une réputation pour les utilisateurs et, en limitant les abus, du côté des vendeurs et des acheteurs. La présente invention permet d'intégrer des fonctions supplémentaires d'encadrement des autorisations de paiement, comme la protection des mineurs, ce qui contribue à la confiance et à la sécurité nécessaires à tout système de paiement. Ces fonctions d'encadrement peuvent faire intervenir des tiers certificateurs. ETAT DE LA TECHNIQUE ANTERIEURE Le paiement de biens et services en ligne fait l'objet de plusieurs procédés qui sont principalement l'adaptation des moyens de paiement classiques aux usages internet. Le procédé le plus courant est celui de la gestion d'un panier d'achats par le site marchand. Lorsque le client a terminé ses achats, il est routé vers le site d'un opérateur de paiement auprès duquel il saisit les informations sécurité de son compte de paiement, compte bancaire ou autre. Après validation de ces informations, l'opérateur de paiement informe le site marchand de la bonne exécution du paiement. Le site marchand peut alors procéder à la délivrance du contenu du panier. Compte tenu de sa relative lourdeur, nécessitant plusieurs clics et le remplissage d'un formulaire de saisie, cette procédure est mal adaptée aux paiements de petits montants. Ce procédé est alors souvent simplifié, du point de vue du client, en utilisant les techniques de pré-enregistrement des informations relatives au client associées aux techniques de type cookie permettant de stocker des informations sur le terminal de l'utilisateur. Lorsqu'un utilisateur est reconnu au moyen du cookie, les formulaires de paiement peuvent être pré-remplis et l'utilisateur a seulement à cliquer un nombre limité de fois pour valider l'exactitude de ces informations. Cette simplification peut être poussée à l'extrême jusqu'à permettre de payer en un seul clic sans demander à l'utilisateur de saisir un code de sécurité de vérification de son identité. L'inconvénient est que l'utilisateur ne prouve pas son identité au moment du paiement, se contentant de valider l'utilisation d'un moyen de paiement préalablement mémorisé sur le terminal qu'il utilise. Ce procédé s'accompagne de mesures de sécurité visant à s'assurer que l'internaute cliquant sur le paiement en un clic est bien le détenteur du compte associé, notamment la désactivation de cette possibilité d'achat en un clic au bout d'un certain délai. Pour que ce procédé fonctionne, l'acheteur doit faire suffisamment confiance au site marchand pour lui communiquer son numéro de carte bancaire et lui permettre de le conserver pour des achats futurs. Ce procédé est donc réservé aux sites marchands avec une bonne notoriété et pour des clients réguliers. Cette technique de mémorisation des informations de paiement associée à la reconnaissance du client au moyen d'un cookie peut également être mise en oeuvre par un opérateur de paiement. Le vendeur, désirant utiliser un tel procédé, saisit le catalogue de tous ses produits, avec leur prix, auprès de l'opérateur de paiement. Le vendeur intègre ensuite, sur son site marchand, des liens vers l'opérateur de paiement contenant la référence du produit proposé. En cliquant sur un tel lien, l'acheteur est redirigé vers l'opérateur de paiement qui l'authentifie et qui procède au paiement selon le prix paramétré par le vendeur. Cette technique nécessite un travail de paramétrage important de la part du vendeur. La mise à jour des prix et la création de nouvelles offres nécessitent une intervention de la part du vendeur sur le site de l'opérateur de paiement. Pour couvrir les besoins propres aux paiements de petits montants, d'autres 25 solutions existent. Un procédé de paiement en ligne de petits montants est celui de l'appel d'un numéro payant ou de l'envoi d'un SMS surtaxé. Le client reçoit en retour un code à usage unique qu'il saisit sur le site pour accéder au contenu payant. L'inconvénient est que le numéro à appeler, ou vers lequel envoyer son SMS, est différent d'un pays à l'autre. Le site 30 vendeur doit donc gérer autant de numéros d'appel que de pays pour lesquels il souhaite vendre. Cette procédure est très mal adaptée à l'informatique nomade lorsque l'utilisateur utilise son Smartphone pour naviguer sur internet. Le client ne peut pas annuler son paiement en cas de problème. 11 n'y a pas de protection des mineurs. Une autre solution de sécurité s'appuie sur le fournisseur d'accès internet. 35 Lorsque le client utilise ce moyen de paiement, le vendeur est payé par le fournisseur d'accès internet de son client. L'acheteur est débité par son fournisseur sur sa facture internet. Cette solution est limitée aux fournisseurs d'accès internet qui mettent en oeuvre ce schéma, ce qui limite le nombre d'acheteurs potentiels pour les vendeurs. Ce procédé ne garantit pas l'anonymat de l'acheteur. Il existe également des cartes prépayées qui permettent de procéder à des achats anonymes sur internet en saisissant le numéro unique d'une carte achetée auprès d'un revendeur. Le numéro de carte comprend en général une dizaine de chiffres qu'il faut saisir à chaque acte d'achat. Le caractère fastidieux de la saisie de plusieurs chiffres alourdit le processus d'achat. Les sites désireux de faire payer des contenus à faible valeur unitaire, peuvent proposer un abonnement à leurs internautes : abonnement dans la durée ou prépaiement d'un lot de contenus. Par exemple, certains journaux proposent à leurs visiteurs de payer pour l'accès illimité à leur contenu pendant une certaine durée, ou de payer pour un lot de 25 articles payants à lire sans limite de délai. Cette méthode est bien adaptée aux clients réguliers mais ne permet pas de traiter les clients occasionnels. Les systèmes existants ne permettent pas l'annulation du paiement pour la consommation immédiate d'un bien comme le téléchargement d'une musique ou la lecture d'un article. Seuls les systèmes de paiement carte bancaire et cartes prépayées permettent d'offrir une protection des mineurs en interdisant certains achats. EXPOSE DE L'INVENTION L'invention permet à un client de payer anonymement auprès d'un vendeur en ligne en passant par un opérateur de paiement. La figure 1 montre les trois acteurs : le client [CLI], le vendeur [VEN] et l'opérateur de paiement [OP]. Le paiement n'est possible que pour un client et un vendeur qui ont chacun au préalable ouvert un compte auprès de l'opérateur de paiement. Le client utilise un terminal standard pour accéder au site du vendeur. Le terminal peut être un ordinateur, un téléphone mobile ou tout autre dispositif connecté à internet capable d'accéder au site du vendeur. Le client peut aussi utiliser un programme, ou tout autre dispositif informatique, intégrant la présente invention comme moyen de paiement. Le vendeur intègre librement dans la programmation des pages de son site une « offre de prix » pour chaque bien ou service qu'il propose à la vente. Une « offre de prix » est un ensemble de paramètres non directement affichables. La figure 2 montre une page (1) telle qu'elle est élaborée par le vendeur. Elle intègre une liste de produits (P1) (Pi) et (Pn) proposés au client. A chaque produit, correspond une offre de prix (2.1), (2.i), (2.n). Une offre de prix est une liste de paramètres dont certains sont obligatoires, d'autres facultatifs et 2956233 -4 d'autres enfin laissés libres pour permettre au vendeur de traiter les opérations d'achat. Parmi les paramètres obligatoires, il y a le prix exprimé dans une ou plusieurs devises et l'identifiant d'un compte vendeur valide. Parmi les paramètres facultatifs, il y a la catégorie du service ou du bien proposé à la vente ainsi que les options de paiement souhaitées par le 5 vendeur. La catégorie peut être simplement déclarée par le vendeur ou être certifiée par un organisme tiers garantissant la conformité du contenu avec la catégorie revendiquée. La surveillance et l'analyse du comportement des vendeurs et des acheteurs peuvent amener l'opérateur de paiement à interdire à certains vendeurs de revendiquer certaines catégories. Dans une des possibilités de mise en oeuvre de la présente invention, le prix peut être 10 exprimé directement par son montant et sa devise, ou faire l'objet d'un code prix selon une convention passée entre le vendeur et l'opérateur de paiement. Lorsque le vendeur élabore son offre de prix, il n'a besoin d'aucune connaissance préalable sur les clients qui vont visiter le site. Le vendeur n'a pas besoin de paramétrer son catalogue de biens et services sur les systèmes de l'opérateur de paiement. 15 Il peut changer ses prix à tout moment et dynamiquement pour faire des promotions limitées dans le temps par exemple. La totalité du site comprend autant d'offres de prix que souhaitées. Pour chaque offre de prix, il est possible d'ajouter autant de paramètres que souhaité. Les paramètres, leur signification, leur valeur par défaut et leur caractère obligatoire ou facultatif sont décidés par l'opérateur de paiement. Le vendeur renseigne ces 20 paramètres dans ses offres de prix en fonction de ses besoins et des instructions données par l'opérateur de paiement. Lorsqu'un client visite le site du vendeur, le terminal du client charge la page contenant la description des produits ainsi que les offres de prix. Une offre de prix n'est pas directement affichable. Pour élaborer l'affichage correspondant à une offre de prix, le 25 terminal du client l'envoie sur le site l'opérateur de paiement. Cet envoi est enrichi d'informations complémentaires présentes sur le terminal. A réception de chaque offre de prix, l'opérateur de paiement va utiliser les paramètres contenus dans l'offre de prix ainsi que les informations complémentaires présentes sur le terminal pour élaborer un « affichage actif ». Cet affichage actif est retourné sur le terminal de l'acheteur et apparaît sur la page. 30 L'apparence et le comportement de l'affichage actif sont ainsi conçus par l'opérateur de paiement. L'affichage est qualifié « d'actif » pour signifier que le client peut cliquer sur cet affichage pour procéder à l'acte d'achat. La figure 3 illustre le résultat de cette opération. La page (1) qui est affichée sur le terminal du client contient les affichages actifs (3.1), (3.i) et (3.n). Techniquement, l'envoi de l'offre de prix auprès de l'opérateur de paiement peut être 35 réalisé par un navigateur standard en utilisant les possibilités du langage HTML. L'envoi de 2956233 5- l'offre de prix auprès de l'opérateur de paiement peut également être réalisé par un développement informatique spécifique au sein d'un programme, ou d'un dispositif informatique, utilisant la présente invention comme moyen de paiement. Pour pouvoir être traitée, l'offre de prix doit être rapprochée d'un compte client 5 ouvert auprès de l'opérateur de paiement. Deux cas de figure peuvent se présenter : Le terminal utilisé par le client n'a pas de trace de l'identifiant de compte du client ; Le client a préalablement enregistré son identifiant de compte sur le terminal utilisé. 10 La figure 4 donne l'ordinogramme qui détermine l'élaboration de l'affichage actif. Dans le premier cas (le terminal n'a pas de trace de l'identifiant du compte du client), l'opérateur de paiement ne dispose pas des informations nécessaires pour produire un chèque numérique valide. Il élabore alors un affichage actif invitant le client à s'identifier auprès de l'opérateur de paiement. En cliquant, ou sélectionnant, cette option, le client est 15 conduit sur une page du site de l'opérateur de paiement. Il peut alors s'identifier auprès de l'opérateur de paiement et communiquer les informations sur le compte à utiliser. Le terminal dispose de la trace de l'identifiant de compte du client, c'est-à-dire qu'il se trouve dans le second cas décrit ci-dessous. Dans le second cas (le terminal dispose d'une trace de l'identifiant de compte du 20 client), l'identifiant de compte fait partie des informations ajoutées à l'offre de prix lors de l'envoi à l'opérateur de paiement. Cet envoi simultané peut être réalisé par un navigateur standard, par exemple en utilisant un cookie. L'envoi simultané de l'offre de prix et de l'identifiant de compte peut également être réalisé par un développement informatique spécifique au sein d'un programme, ou d'un dispositif informatique, utilisant la présente 25 invention comme moyen de paiement. D'autres informations présentes sur le terminal peuvent être ajoutées, selon les besoins de l'opérateur de paiement. La trace de l'identifiant de compte client peut, par exemple, être enregistrée en utilisant un cookie. La trace peut également être obtenue en lisant sur le dispositif utilisé par le client un identifiant unique propre au terminal et associé, de manière unique, avec un 30 identifiant de compte client dans les bases de l'opérateur de paiement. Par exemple, l'identifiant de compte client peut être associé à un numéro de téléphone ou un numéro de carte SIM lu sur le Smartphone utilisé pour l'acte d'achat. L'affichage actif est associé à un « chèque numérique » calculé par l'opérateur de paiement. Ce chèque numérique est envoyé au vendeur lorsque le client clique sur 35 l'affichage actif. Le chèque numérique est calculé par l'opérateur de paiement en rapprochant les paramètres de l'offre de prix faite par le vendeur avec les préférences du vendeur et du client et en appliquant un certain nombre de règles. La présente invention ne donne aucune limite au nombre et à la nature des règles appliquées. Ces règles se fondent sur les informations à la disposition de l'opérateur de paiement, à savoir : - les paramètres liés au vendeur ; les paramètres liés à l'acheteur ; les paramètres spécifiques à l'offre de prix ; les paramètres complémentaires présents sur le terminal de l'acheteur au moment de l'envoi de l'offre de prix à l'opérateur de paiement, comme par exemple la localisation de l'acheteur si cette information est disponible ; les paramètres de contexte comme la date et l'heure de l'achat. L'application des règles par l'opérateur de paiement lui permet ou non de produire un chèque numérique. Lorsque les règles ne lui permettent pas de produire un chèque numérique, l'affichage qui est produit décrit la nature de l'impossibilité. La figure 5 illustre la lecture des paramètres nécessaire à l'élaboration du chèque numérique. En 1, l'offre de prix [OFF] contient l'identifiant du vendeur [IDV] avec d'autres paramètres [PRM1]. Cette offre de prix est enrichie par le terminal client avec l'identifiant du client [IDC] ainsi que d'autres paramètres [PRM2]. En 2, l'opérateur de paiement utilise l'identifiant de client [IDC] pour récupérer les paramètres [PRM3] propres à ce client. Enfin, en 3, l'opérateur de paiement récupère également les paramètres [PRM4] propres au vendeur à partir de l'identifiant vendeur [IDV]. Les paramètres de contexte ne sont pas représentés dans ce schéma. Les paramètres fournis par le vendeur peuvent être signés numériquement par un organisme tiers. Par exemple, le vendeur peut proposer à la vente un contenu conforme à un label de développement durable signé numériquement par un organisme certificateur. La figure 6 donne l'ordinogramme d'utilisation de ces paramètres pour produire un affichage. Les règles s'appliquent sur les quatre familles de paramètres [PRM1], [PRM2], [PRM3] et [PRM4], les paramètres de contexte comme la date et l'heure ne sont pas représentés. Le résultat est la production ou non d'un chèque numérique. Selon ce résultat, l'opérateur de paiement retourne un affichage actif lié au chèque ou un affichage d'information sur la nature de l'impossibilité à produire le chèque numérique. Les règles suivantes, listées de manière non exhaustive, peuvent être mises en oeuvre dans le cadre de la présente invention : - la devise du paiement est déterminée en fonction des devises acceptées par le vendeur, celles disponibles du côté du client et des options de change disponibles et acceptées ; le paiement peut être impossible pour une insuffisance de solde sur le compte client ; la possibilité de payer peut être refusée en rapprochant la catégorie de service proposée par le vendeur avec les catégories permises du côté du client. Une telle règle permet de mettre en place un dispositif de protection des mineurs. Le compte client peut ainsi être paramétré pour interdire explicitement certaines catégories de contenu. Lorsque la catégorie apparaissant dans l'offre de prix du vendeur n'est pas autorisée, le prix n'est pas affiché, un message d'information sur l'interdiction est affiché à la place ; le contrôle des catégories pouvant faire l'objet d'un paiement peut être renforcé avec l'intervention d'un organisme certificateur. Un organisme certificateur garantit la conformité du contenu avec la catégorie donnée dans l'offre de prix au moyen d'un mécanisme de signature électronique. La signature peut être vérifiée par l'opérateur de paiement avant de produire le chèque numérique. Par exemple, le compte client peut n'autoriser que les achats de biens ou services certifiés par un organisme de formation particulier ; le prix peut faire l'objet d'une réduction lorsque le compte client dispose de caractéristiques particulières considérées par le vendeur comme donnant droit à une réduction de prix. Ces caractéristiques clients peuvent être par exemple un montant cumulé d'achats ou la détention de certificats numériques particuliers ; le paiement peut être refusé par des règles de limitation de montant total dans une certaine catégorie de bien ; une autre règle permet d'afficher un prix nul lorsque le bien ou service a déjà été payé par le client. Ce type de règle nécessite de gérer des paramètres de date et de durée de validité de l'achat ; une autre règle porte sur la durée de validité de l'offre. Le vendeur se protège ainsi contre les offres qui pourraient être utilisées au-delà d'un délai raisonnable. Le vendeur peut utiliser cette fonctionnalité pour faire des promotions limitées dans le temps. Lorsque l'opérateur de paiement ne peut pas construire un « chèque 35 numérique », l'affichage actif affiche un message, un code ou un symbole représentant le type d'impossibilité rencontrée. Lorsque les règles permettent de construire un prix, l'opérateur de paiement élabore un « chèque numérique » qui comprend : tous les paramètres de l'offre de prix. Cela permet au vendeur de procéder au contrôle des éléments constitutifs du prix affiché sur le chèque ; le prix du service exprimé dans une certaine devise ; des informations optionnelles que l'opérateur de paiement souhaite communiquer au vendeur ; une zone secrète permettant à l'opérateur de paiement d'associer au chèque numérique des informations qui lui sont réservées ; une signature numérique scellant toutes ces informations pour en garantir l'intégrité. La figure 7 montre le contenu d'une offre de prix (OFF) et d'un chèque numérique (CHQ). Le chèque ne comprend pas d'information sur l'acheteur ce qui garantit l'anonymat du moyen de paiement. Il est possible, de manière optionnelle, d'ajouter dans le chèque certaines informations sur l'acheteur permettant au vendeur de mettre en oeuvre des offres commerciales ciblées. Par exemple, sans rompre l'anonymat, l'opérateur de paiement peut communiquer au vendeur le total du chiffre d'affaires réalisé par cet acheteur sur une certaine période. Dans certains cas d'usage, l'opérateur de paiement peut lever l'anonymat du client en donnant des informations sur l'identité du client dans cette zone. Ce « chèque numérique » est associé à l'affichage actif qui affiche le prix au client. Lorsque le client clique sur l'affichage actif, le chèque numérique est envoyé au site du vendeur. A réception, le vendeur « encaisse » ce chèque numérique auprès de l'opérateur de paiement en le lui envoyant. L'opérateur de paiement vérifie la validité du chèque numérique et, en cas de validité, opère le débit du compte client et le crédit du compte vendeur. Il retourne sa réponse au vendeur. En cas de validation de la part de l'opérateur de paiement, le vendeur peut retourner au client le bien ou service qu'il vient d'acheter. La signature du chèque numérique est conçue de manière à en garantir l'authenticité. L'unicité est garantie par le secret que l'opérateur de paiement intègre dans le chèque numérique. Un chèque numérique utilisé ne pourra pas être réutilisé. Cette limitation empêche ainsi un commerçant indélicat de présenter deux fois un chèque numérique auprès de l'opérateur de paiement. Le chèque numérique reprend toute l'offre de prix initiale émise par le vendeur. A réception du chèque numérique, le vendeur peut ainsi vérifier que les éléments envoyés n'ont pas été altérés, par exemple par modification du prix. Comme c'est le vendeur qui appelle l'opérateur de paiement pour vérifier le chèque numérique, cela garantit au vendeur qu'il a bien affaire à l'opérateur de paiement. Les possibilités de fraudes basées sur le remplacement de l'opérateur de paiement acceptant les demandes de validation par un site frauduleux sont ainsi très limitées. La figure 8 schématise les sept échanges se tenant dans l'opération de paiement. La numérotation des échanges est la même que dans la figure 1. Les échanges 1 à 3 ont lieu préalablement à l'activation de l'affichage actif par le client. Les échanges 4 à 7 s'enchaînent lorsque le client active l'affichage actif pour demander le paiement. L'échange 1 représente l'envoi par le vendeur d'une page contenant au moins une offre de prix [OFF]. Avec l'échange 2, le navigateur client, ou le programme utilisant la présente invention comme moyen de paiement, envoie cette offre [OFF] avec l'identifiant client [CLI], ainsi que d'autres paramètres optionnels, résidant sur le terminal du client. Une mise en oeuvre typique s'appuie sur un cookie contenant l'identifiant du client ainsi qu'une signature numérique en garantissant l'authenticité. L'échange 3 représente l'envoi de l'affichage actif (AA) associé au chèque numérique (CHQ) au terminal du client qui affiche alors l'affichage actif. L'échange 4 est l'envoi au vendeur du chèque numérique (CHQ) lorsque le client active l'affichage actif. Le vendeur encaisse ce chèque en l'envoyant à l'opérateur de paiement au moyen de l'échange 5. L'opérateur de paiement vérifie ce chèque. Si le chèque est valide, il effectue le mouvement du compte client vers le compte vendeur. II retourne, échange 6, le résultat de la validation avec une validation ou une non validation. Avec l'échange 7, selon le résultat, le vendeur envoie au client un message d'erreur ou le bien et service qu'il vient d'acheter. Les sept échanges de la chaîne de liaison ainsi décrits ne garantissent pas la livraison du produit. En effet, si un incident survient sur un des échanges 6 ou 7, le débit a été opéré mais le service n'est pas délivré. Lorsque la durée de validité de l'achat le permet, l'acheteur pourra faire une nouvelle tentative d'accéder au bien avec une valeur zéro comme décrit plus haut. Parfois, le problème technique peut durer plus longtemps que la durée de validité de l'achat. La présente invention permet donc à l'acheteur d'annuler toute opération d'achat sur simple déclaration. Pour se faire, il se connecte sur son compte ouvert auprès de l'opérateur de paiement. Une page lui affiche les derniers achats qu'il peut annuler. Il lui suffit de sélectionner les dépenses qu'il veut annuler. La présente invention identifie plusieurs raisons d'annulation. Le détenteur d'un compte doit utiliser une des raisons proposées pour annuler. Trois raisons peuvent par 35 exemple être proposées : 2956233 -10- problème technique : en choisissant cette raison, l'acheteur indique qu'il n'a pas eu accès au bien ou service désiré. Dans ce cas il est remboursé, et le crédit du vendeur est annulé ; service non satisfaisant en choisissant cette raison, l'acheteur indique que le 5 bien ou service décrit préalablement à l'achat ne correspondait pas à ce qui a été délivré après le paiement. Cette annulation constitue ainsi une garantie « satisfait ou remboursé ». Cette garantie contribue à la sécurité du paiement puisque l'acheteur peut annuler son opération ; suspicion de fraude : en choisissant cette raison, l'acheteur indique qu'il n'est 10 pas à l'origine de l'achat en question. Lorsque cette raison est invoquée, l'utilisateur est invité à changer son mot de passe. Le nombre de raisons pouvant être invoquées par l'acheteur peut être enrichi par l'opérateur de paiement. L'annulation se traduit par le remboursement de l'acheteur, sauf lors le système de réputation amène l'opérateur de paiement à limiter le droit d'annulation de 15 certains utilisateurs. L'annulation peut ou non se traduire par l'annulation du crédit sur le compte du vendeur. Par exemple, lorsque la raison d'annulation invoquée par l'acheteur est un problème technique, le crédit du vendeur est annulé. La possibilité d'annuler son achat fait partie de la sécurité de l'opération de paiement objet de la présente invention. Pour limiter les abus, la présente invention s'appuie 20 sur des règles comportementales qui interdisent un trop grand nombre d'annulations par période de temps. L'analyse des causes d'annulation permet également de détecter les sites commerçants ayant un mauvais niveau de service. Le niveau de service technique est considéré comme non satisfaisant lorsque le nombre d'annulations pour raisons techniques est anormalement élevé. Le niveau de service qualitatif est considéré comme non 25 satisfaisant lorsque le nombre d'annulations pour insatisfaction est anormalement élevé. L'analyse du comportement des vendeurs et des acheteurs permet ainsi de construire un système de réputation permettant à l'opérateur de prendre des mesures incitatives ou pénalisantes auprès des vendeurs et des acheteurs. La réputation des vendeurs peut être affichée dans l'affichage actif de manière à créer la confiance auprès des acheteurs et 30 inciter parallèlement les vendeurs à faire progresser la qualité technique et qualitative de leurs prestations. La présente invention peut également être mise en oeuvre en faisant intervenir deux opérateurs de paiements, comme illustré sur la figure 9 : - un opérateur de paiement, [OPC] celui du client, calcule le chèque numérique et l'affichage actif affiché sur le terminal du client ; 2956233 -11- un opérateur de paiement, [OPV] celui du vendeur, vérifie la validité du chèque numérique. Cette alternative nécessite que les deux opérateurs de paiement s'accordent sur des conventions communes concernant les échanges de données et leur sécurisation par 5 des méthodes cryptographiques. Les opérateurs de paiement procèdent ensuite régulièrement à la compensation financière résultant de l'ensemble des opérations de paiements auxquelles ils ont procédé. L'opérateur de paiement peut décider de demander à l'acheteur de saisir son mot de passe même si un identifiant de compte client est présent sur le terminal. Cette 10 décision peut être prise en application d'une règle, ou d'une combinaison de règles, comme : - l'enregistrement de l'identifiant de compte client est valide pour une durée limitée. Au bout de cette durée, le client doit renouveler son inscription ; l'enregistrement de l'identifiant de compte client ne peut être faite que sur un terminal à la fois : l'inscription d'un nouveau terminal rend caduque 15 l'inscription sur le précédent terminal utilisé ; - la réputation du client relève d'une catégorie à risques ; la demande de mot de passe est imposée pour les montants dépassant un certain seuil. La demande de mot de passe peut être faite à différentes étapes de la chaîne de 20 liaison décrite, notamment avant ou après l'élaboration du chèque numérique. La demande de mot de passe peut également être une demande de renouvellement de mot de passe. La sécurité peut être renforcée par l'envoi de mails au détenteur du compte client. La sécurité peut également être renforcée en mettant en oeuvre d'autres systèmes d'authentification que la demande de mot de passe, par exemple l'utilisation de certificats 25 électroniques. PRESENTATION DES FIGURES La figure 1 représente les trois acteurs impliqués dans la présente invention : l'opérateur de paiement (OP), l'acheteur (CLI) et le vendeur (VEN). Les sept échanges intervenant durant l'opération de paiement sont représentés par des flèches indiquant d'où 30 part l'information et où elle arrive. Les flèches en pointillés représentent les échanges intervenant avant la validation de l'achat par l'acheteur et les flèches en trait plein représentent les échanges intervenant après cette activation. La figure 2 schématise le code source d'une page telle qu'elle est conçue par un vendeur. Il intègre des offres de prix (2.1) à (2.n) dans sa page. Ces offres de prix sont des 35 informations non affichables. 2956233 -12- La figure 3 représente une page affichée telle qu'elle est vue par l'acheteur potentiel : les offres de prix de la figure 2 sont transformées en affichages actifs (3.1) à (3.n). La figure 4 représente l'ordinogramme de décision du contenu de l'affichage actif selon que le terminal est enregistré ou non. 5 La figure 5 illustre comment sont collectés tous les paramètres nécessaires à l'élaboration d'un chèque numérique. L'offre de prix [OFF] contient l'identifiant [IDV] ainsi que les paramètres de l'offre. Lorsqu'elle est envoyée à l'opérateur de paiement, l'offre de prix est complétée de l'identifiant du client [IDC] ainsi que d'autres paramètres présents sur le terminal. Les deux identifiants [IDC] et [IDV] permettent de récupérer les paramètres 10 propres, respectivement, au client et au vendeur. La figure 6 représente l'ordinogramme de production d'un affichage actif en fonction des quatre familles de paramètres ainsi collectés, les paramètres de contexte comme la date et l'heure ne sont pas représentés. La figure 7 illustre le contenu d'une offre de prix (OFF) et d'un chèque numérique 15 (CHQ). Le chèque numérique comprend le prix validé par l'acheteur dans une certaine devise. La signature numérique calculée par l'opérateur de paiement porte sur l'ensemble des données. La figure 8 est une représentation des flux intervenant entre les trois acteurs (VEND, (CLI) et (OP). 20 La figure 9 est une représentation des schémas de la présente invention faisant intervenir deux opérateurs de paiement au lieu d'un seul comme dans la figure 1. L'échange numéroté 8 entre les deux opérateurs [OPV] et [OPC] représente la compensation intervenant postérieurement aux achats réalisés. EXEMPLE D'UN MODE DE REALISATION 25 Un mode de réalisation simple consiste en l'utilisation de la balise IFRAME faisant partie du langage HTML standard. Tous les paramètres des échanges sont passés dans les adresses URL selon la méthode GET. Pour chaque offre de prix, le vendeur intègre une balise IFRAME dans les pages de son site, à l'endroit où il souhaite que l'affichage actif apparaisse. La balise IFRAME 30 prend comme paramètre une adresse URL qui est celle utilisée par l'opérateur de paiement pour élaborer l'affichage actif. Le vendeur place dans cette URL les paramètres de son offre de prix. Lorsque le navigateur de l'internaute traite-le contenu HTML de la page du vendeur, la norme HTML prévoit qu'il appelle automatiquement l'adresse contenue dans la balise IFRAME. L'opérateur de paiement analyse les paramètres passés dans l'URL et lit le 35 contenu d'un cookie. Le cookie contient, de manière sécurisée, l'identifiant de l'acheteur. Si 2956233 -13- ce n'est pas le cas, l'opérateur de paiement retourne un lien URL vers une adresse permettant à l'internaute de créer un tel cookie. Lorsque le cookie contient un identifiant client, l'opérateur peut procéder à l'élaboration du chèque numérique avec l'application de toutes les règles et contrôles nécessaires. 5 Le résultat de cette étape est du code HTML qui sera affiché dans le cadre réservé à cet effet, selon la norme HTML. Lorsqu'il ne s'agit pas d'un cas d'erreur ou d'impossibilité, le code HTML affiche le prix dans la devise de l'acheteur et un lien HTML vers une adresse prévue par le vendeur, passée en paramètre dans l'URL contenu dans la balise IFRAME. 10 Lorsque l'acheteur clique sur ce lien, il appelle l'adresse URL vendeur. Le site du vendeur lit le chèque numérique passé en paramètre dans l'adresse URL. Il envoie ces données sur le site de l'opérateur de paiement, à une adresse convenue, qui procède à son encaissement. Lorsque le chèque est bien validé, l'opérateur de paiement envoie un acquittement. Le site vendeur peut donc retourner à l'acheteur le contenu qu'il vient 15 d'acheter. L'opérateur de paiement met en place un site permettant à ses clients de suivre leurs opérations, de procéder aux annulations voulues et, par exemple, de charger leur compte lorsque l'opérateur utilise la technique du prépaiement. De même, il met à disposition des vendeurs un site de gestion et de suivi de leurs ventes. 20 L'opérateur tient à jour l'historique des opérations annulées et non annulées qu'il exploite de manière statistique afin de tenir à jour la réputation des acheteurs et des vendeurs en détectant les abus et les fraudes. Il utilise ces résultats pour limiter les possibilités d'annulation pour certains clients et inciter les vendeurs à une meilleure qualité de service. 25 APPLICATION INDUSTRIELLE La présente invention est particulièrement adaptée à la vente de contenus délivrés en ligne et à faible valeur unitaire comme les articles de journaux, la consultation de bases de données, la consultation de base de connaissances, l'accès à des blogs spécialisés, la location de fonctions logicielles, les paris en ligne, l'accès des contenus 30 multimédias comme les clips vidéo, les musiques ou les images, la participation à des univers virtuels. La présente invention est également particulièrement adaptée au versement de subventions dont l'usage doit être limité à certains contenus et service. Elle permet par exemple la gestion de subventions de formation ne pouvant être utilisées que sur des sites de formation agréés. REVENDICATIONS1) Méthode de paiement en ligne faisant intervenir un opérateur de paiement, un acheteur et un vendeur, ces deux derniers détenant chacun un compte auprès dudit opérateur, caractérisée en ce que l'opérateur produit un chèque numérique préalablement à l'acte d'achat en se basant sur une offre de prix soumise par le vendeur, chèque numérique qui est envoyé au vendeur par activation d'un affichage actif par l'acheteur, chèque qui est encaissé par le vendeur auprès de l'opérateur de paiement. 2) Méthode selon la revendication 1 caractérisée en ce que l'opérateur de paiement applique des règles pouvant l'amener à interdire, diminuer ou limiter le paiement en utilisant des paramètres compris dans l'offre de prix du vendeur et des paramètres liés à l'acheteur et au vendeur. 3) Méthode selon l'une quelconque des revendications précédentes caractérisée en ce qu'elle utilise des paramètres, liés à l'acheteur ou au vendeur, qui sont certifiés par un organisme tiers en faisant intervenir des mécanismes comme la signature électronique. 4) Méthode selon l'une quelconque des revendications précédentes caractérisée en ce que l'opérateur de paiement applique des règles pouvant l'amener à afficher un prix nul lorsque l'acheteur a déjà acquitté le paiement. 5) Méthode selon l'une quelconque des revendications précédentes caractérisée 20 en ce que l'acheteur peut librement annuler les opérations de paiement réalisées préalablement en indiquant le motif de son annulation. 6) Méthode selon l'une quelconque des revendications précédentes caractérisée en ce que l'opérateur de paiement renforce la sécurité en imposant une nouvelle authentification de l'acheteur. 25 7) Méthode selon l'une quelconque des revendications précédentes caractérisée en ce que l'opérateur de paiement communique au vendeur des informations sur l'acheteur. 8) Méthode selon l'une quelconque des revendications précédentes caractérisée en ce que l'opérateur de production du chèque numérique est différent de l'opérateur de validation dudit chèque. 30 9) Méthode selon la revendication 5 caractérisée en ce que l'opérateur exploite les informations liées aux opérations d'annulation pour limiter les usages abusifs desdites annulations. 10) Méthode selon la revendication 5 caractérisée en ce que l'opérateur de paiement exploite les informations liées aux opérations d'annulation pour noter la qualité des 35 biens et services proposés par les vendeurs.