Brevet FR2811451A1 — publié le 20020111

Le domaine de l'invention est celui de la gestion des transactions de micropaiement. Plus précisément, I'invention concerne un système et un procédé de gestion de transactions de micropaiement mettant en oeuvre au moins un intermédiaire financier, au moins un client, et au moins un marchand de biens et/ou de services. Par micropaiement, on entend ici un paiement d'un montant réduit, par exemple de quelques fractions de centimes à quelques dizaines ou centaines de francs (ou un montant réduit dans toute autre monnaie d'échange). Il peut notamment mettre en oeuvre un échange de jetons constituant une monnaie de transaction électronique. L'émergence des systèmes de transactions de micropaiement et/ou de macropaiement mis en oeuvre par le biais de réseaux de communication, tels que par exemple le réseau mondial Intemet, a soulevé le problème de la sécurité des transactions entre clients et marchands, ainsi que de la sécurité des informations échangées au cours de ces transactions. Notamment, I'un des problèmes principaux de la sécurité des transactions est la possibilité pour un marchand et/ou un client du système de copier un jeton (ou toute autre unité de monnaie d'échange) et de l'utiliser frauduleusement pour deux transactions distinctes. De nombreux systèmes de gestion des transactions électroniques ont été proposés pour résoudre ce problème de sécurité, ou à tout le moins accroître la sécurité des transactions. Ces systèmes sont par exemple décrits dans l'ouvrage intitulé " Electronic Payment Systems " publié chez Artech House en 1997, et co-rédigé par Donal O'Mahony, Michael Peirce, et Hitesh Tewari. Cet ouvrage distingue, d'une part, les systèmes de paiement électronique en espèces, tels que le système Ecash développé par la société DigiCash (marques déposées), le projet CAFE (en anglais " Conditional Access for Europe " signifiant littéralement " Accès Conditionnel pour l'Europe "), ou encore les systèmes NetCash, CyberCoin ou Mondex (marques déposées). Il mentionne, d'autre part, des systèmes spécifiques de micropaiement, tels que Millicent, SubScrip, PayWord, MicroMint, ou encore le protocole de micropaiement iKP (marques déposées). Dans l'ensemble des systèmes de paiement électronique en espèces existants, la sécurité des transactions est assurée par le biais d'une utilisation intensive de la cryptographie, aussi bien symétrique qu'asymétrique. Ainsi, dans le système Ecash (marque déposée), par exemple, de nombreuses signatures cryptees de la banque et/ou de l'intermédiaire financier, associées à de nombreux calculs de décryptage, sont mis en oeuvre pour vérifier que chaque jeton circulant dans le système n'a été utilisé qu'une seule et unique fois. Par ailleurs, la banque et/ou l'intermédiaire financier opère une vérification systématique de la validité des jetons, au cours de chacune des transactions, en comparant le numéro de série des jetons à une base de données volumineuse regroupant l'ensemble des numéros de série de tous les jetons émis par le système. Un inconvénient de cette technique de l'art antérieur est donc que la sécurité des transactions est assurée au prix de la mise en ceuvre de très nombreux calculs et cryptages, qui surchargent le système et le rendent coûteux, et donc inadapté aux transactions de micropaiement. Un autre inconvénient de cette technique de l'art antérieur est qu'il est nécessaire de gérer une importante base de données regroupant tous les numéros de série des jetons émis par le système, ce qui est coûteux et complexe. Dans le projet CAFE (en anglais " Conditional Access for Europe "), par exemple, la sécurité des transactions est assurée grâce à la mise en oeuvre de terminaux résistants à toute falsification, et d'une cryptographie complexe. Un observateur, qui protège les intérêts de la banque et/ou de l'intermédiaire financier, est intégré dans le portefeuille de chaque client. Son rôle est d'assurer la validité de toutes les transactions entreprises par un client, si bien que ce dernier ne peut mettre en oeuvre une transaction sans obtenir l'accord de l'observateur. Un inconvénient de cette technique de l'art antérieur, ainsi que des autres systèmes de paiement électronique en espèces tels que NetCash, CyberCoin ou Mondex (marques déposées), est la lourdeur de la cryptographie mise en oeuvre, ainsi que la complexité des terminaux utilisés, qui sont inadaptées aux transactions de micropaiement. L'ouvrage " Electronic Payment Systems " présente par ailleurs des systèmes de gestion de transactions de micropaiement. Le système appelé Millicent (marque déposée) met en oeuvre trois acteurs: un client, un marchand, et un intermédiaire financier. Des jetons, spécifiques à un marchand donné, sont échangés au cours de transactions de micropaiement. Un client peut se procurer des jetons d'un type donné, qui lui permettent de payer un marchand particulier, auprès d'un intermédiaire financier, en échange d'un macropaiement. Ces jetons sont ensuite stockés dans le porte-monnaie du client. Le système de gestion des transactions de micropaiement appelé SubScrip (marque déposée), en revanche, ne fait pas intervenir de banque ou d'intermédiaire financier. Un client utilise un procédé de macropaiement pour ouvrir un compte temporaire prépayé chez un marchand donné. Un inconvénient de ces deux techniques de l'art antérieur est qu'elles ne sont pas adaptées aux transactions mises en oeuvre entre un unique client et une pluralité de marchands. En effet, dans le système Millicent (marque déposée), un client doit se procurer autant de jetons différents que le nombre de marchands auxquels il souhaite acheter un bien et/ou un service. De même, dans le système SubScrip (marque déposée), un client doit ouvrir un compte prépayé chez chacun des marchands avec lesquels il souhaite entreprendre des transactions de micropaiement. Le système PayWord (marque déposée) pallie cet inconvénient en accordant une autorisation de crédit au client, auprès d'un intermédiaire financier et/ou d'une banque, qui garantit ensuite le paiement aux marchands. Il apparaît clairement qu'un inconvénient de cette technique de l'art antérieur est le manque de sécurité des transactions, notamment pour l'intermédiaire financier et/ou la banque, un grand nombre d'achats pouvant être effectué par un client sans que ce dernier ne dispose des fonds nécessaires sur son compte bancaire. Dans le protocole de gestion des transactions de micropaiement iKP, la sécurité des transactions est accrue par rapport au système PayWord (marques déposées), notamment grâce à une authentification du client auprès d'un marchand, préalable à toute transaction. Un inconvénient de cette technique est qu'une telle authentification nécessite de nombreux échanges de messages qui alourdissent et ralentissent le protocole, et rendent les transactions coûteuses. L'efficacité des transactions de micropaiement du système MicroMint est supérieure à celle du protocole iKP (marques déposées), mais cette efficacité est acquise aux dépens de la sécurité des transactions de micropaiement. Un intermédiaire financier et/ou une banque fournit des jetons à un client, qui peuvent être utilisés auprès de tous les marchands. Aucune vérification de la validité des jetons n'est entreprise au cours des transactions, rendant possible une utilisation répétée d'un même jeton. Un inconvénient de cette technique de l'art antérieur est donc que les transactions ne sont pas sécurisées, ni pour le client, ni pour le marchand, qui peuvent recevoir en paiement des jetons non valides, car déjà précédemment utilisés. Il existe donc de nombreux systèmes et procédés de gestion des transactions de micropaiement, présentant des niveaux de sécurité et de complexité divers, dans lesquels un client dispose soit d'un portemonnaie électronique, soit d'une autorisation de crédit, soit d'un compte prépayé chez un marchand. Mais on ne connaît à ce jour aucun système ou protocole de mise en oeuvre simple, présentant une sécurité satisfaisante pour les différents acteurs des transactions (intermédiaire financier, client, marchand). 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 est de fournir un système et un procédé de gestion des transactions de micropaiement qui soient simples, faciles d'utilisation, et peu coûteux à mettre en oeuvre. L'invention a notamment pour objectif de mettre en oeuvre un système de gestion des transactions de micropaiement, dans lequel le terminal du client et l'équipement du marchand sont simples d'utilisation et de fabrication, et peu coûteux. Un autre objectif de l'invention est de mettre en oeuvre un système et un procédé de gestion des transactions de micropaiement, dans lesquels l'argent peut circuler dans le sens opposé au sens classique, à savoir d'un marchand vers un client. Plus précisément, un objectif de l'invention est de fournir un système et un procédé de gestion des transactions de micropaiement, dans lesquels un marchand peut rembourser un client, et/ou transmettre à un client une somme, correspondant à un gain du client, acquis par exemple en participant à un jeu ou à une loterie. L'invention a encore pour objectif de mettre en oeuvre un procédé de gestion des transactions de micropaiement, dans lequel toutes les transactions entre un client et/ou un marchand et/ou un intermédiaire financier sont sécurisées, sans nécessiter la mise en oeuvre d'une cryptographie complexe. Un autre objectif de l'invention est de mettre en oeuvre un système et un procédé de gestion des transactions de micropaiement permettant aisément à un client d'entreprendre des transactions de micropaiement avec une pluralité de marchands. Encore un autre objectif de l'invention est de fournir un procédé de gestion des transactions de micropaiement, dans lequel les jetons échangés au cours d'une transaction présentent une validité accrue par rapport aux techniques de l'art antérieur. L'invention a encore pour objectif de mettre en oeuvre un système de gestion des transactions de micropaiement, dans lequel il est possible de réaliser un audit des jetons échangés, de manière à accroître la sécurité des transactions. Encore un autre objectif de l'invention est de fournir un procédé de gestion des transactions de micropaiement, dans lequel la sécurité des transactions est garantie, avec un nombre de calculs réduit par rapport aux techniques de l'art antérieur. Ces objectifs, ainsi que d'autres qui apparaîtront par la suite sont atteints selon l'invention, à l'aide d'un système de gestion de transactions de micropaiement comprenant au moins un intermédiaire financier, au moins un client, et au moins un marchand de biens et/ou de services, lesdites transactions mettant en oeuvre des échanges de jetons. Selon l'invention, dans un tel système, chacun des clients dispose d'au moins deux premières zones de stockage de jetons distinctes, deux desdites premières zones de stockage étant deux porte-monnaie dudit client, un porte-monnaie principal et un porte-monnaie secondaire, ledit porte-monnaie principal pouvant comprendre des jetons fournis par ledit 6 2811451 intermédiaire financier audit client, et ledit porte-monnaie secondaire pouvant comprendre des jetons fournis par ledit au moins un marchand audit client. Ainsi, I'invention repose sur une approche tout à fait nouvelle et inventive de la gestion des transactions de micropaiement. En effet, un client peut ainsi disposer d'une zone de stockage de jetons fiable, contenant des jetons dont la validité est assurée, et d'une zone de stockage de jetons pouvant être assimilée à un crédit, accordé au client par un ou plusieurs marchands, et pouvant contenir en outre des informations sur les transactions effectuées avec le ou les marchands. La sécurité des transactions est ainsi accrue pour le client, qui est assuré de disposer d'une ressource de jetons valides, à savoir son porte- monnaie principal, sans craindre, par exemple, que ces jetons n'aient été frauduleusement copiés et utilisés deux fois par un marchand. Le client dispose également avantageusement d'une ressource complémentaire de jetons, correspondant à un crédit qu'il peut utiliser auprès d'un ou plusieurs marchands, à savoir son porte-monnaie secondaire. Selon une caractéristique avantageuse de l'invention, chacun desdits marchands dispose d'au moins deux deuxièmes zones de stockage de jetons distinctes. Préférentiellement, deux desdites deuxièmes zones de stockage sont un porte-monnaie dudit marchand et un fichier de consignation dudit marchand, ledit porte-monnaie dudit marchand pouvant comprendre des jetons fournis par ledit intermédiaire financier audit marchand, et ledit fichier de consignation pouvant comprendre des jetons fournis par ledit au moins un client audit marchand. Ainsi, chez le marchand, les jetons provenant de l'intermédiaire financier sont séparés des jetons fournis par le ou les client(s), de sorte que la validité du contenu du porte-monnaie du marchand est garantie, la sécurité des transactions étant ainsi accrue. L'invention concerne également un procédé de gestion de transactions de micropaiement dans un système tel que décrit précédemment. Selon un aspect de l'invention, au cours du paiement d'un bien et/ou d'un service acquis par ledit client auprès dudit marchand, ledit client transmet audit marchand un premier nombre de jetons, correspondant au prix dudit bien et/ou dudit service, et provenant: - dudit porte-monnaie principal, s'il contient une quantité de jetons supérieure ou égale audit premier nombre; - dudit porte-monnaie secondaire, si ledit porte-monnaie principal ne contient aucun jeton; - desdits porte-monnaie principal et secondaire, si ledit porte- monnaie principal contient une quantité de jetons inférieure audit premier nombre; et ledit marchand stocke ledit premier nombre de jetons transmis dans ledit fichier de consignation. Le client utilise ainsi prioritairement les jetons qu'il s'est procurés auprès de l'intermédiaire financier pour payer le marchand, mais il peut également effectuer une partie ou la totalité du paiement à l'aide des jetons contenus dans le porte-monnaie secondaire, qui représentent un crédit qu'il peut utiliser auprès du marchand. La validité des jetons fournis par le client au marchand ne pouvant être garantie, ce dernier ne stocke pas les jetons reçus dans son porte-monnaie, mais dans un fichier de consignation. Dans un mode de réalisation avantageux de l'invention, lorsque ledit marchand souhaite rembourser une somme audit client, ledit procédé comprend les étapes consistant à: - prélever un second nombre de jetons correspondant à ladite somme, dudit porte-monnaie dudit marchand; - vérifier que ledit second nombre, ajouté aux jetons dudit porte- monnaie secondaire, ne dépasse pas un maximum prédéterminé; - ledit maximum n'étant pas dépassé, stocker ledit second nombre dans ledit portemonnaie secondaire; sinon: - interrompre ledit procédé, et rembourser ledit client en mettant en oeuvre un procédé de macropaiement; ou envoyer un message audit client lui demandant de vider son porte-monnaie secondaire afin de pouvoir être remboursé. Ainsi, la transaction de remboursement est sécurisée, d'une part, par l'utilisation de jetons extraits du porte-monnaie du marchand (le client est ainsi assuré de la validité des jetons qu'il reçoit du marchand), et d'autre part, par le stockage des jetons reçus dans le porte-monnaie secondaire du client (le porte-monnaie principal reste réservé aux jetons dont la validité est directement garantie par l'intermédiaire financier). Par ailleurs, I'invention prévoit avantageusement que le nombre maximum de jetons pouvant être stockés dans le porte-monnaie secondaire du client est limité, de manière à plafonner le crédit accordé par le ou les marchand(s) à un client donné. Une telle disposition permet donc de réduire les risques encourus par le marchand, et notamment les risques de paiement frauduleux. Avantageusement, un tel procédé comprend en outre une étape de transfert de jetons dudit porte-monnaie secondaire vers ledit porte- monnaie principal, comprenant les sous-étapes suivantes: - ledit client demande audit intermédiaire financier de transférer lesdits jetons contenus dans ledit porte-monnaie secondaire vers ledit porte-monnaie principal; - ledit intermédiaire financier vérifie la validité de ladite demande dudit client, d'une part, et desdits jetons contenus dans ledit porte- monnaie secondaire, d'autre part; - ladite validité étant vérifiée, ledit intermédiaire financier transfert lesdits jetons dudit porte-monnaie secondaire vers ledit porte- monnaie principal. Ainsi, selon l'invention, une telle étape de transfert des jetons du porte-monnaie secondaire vers le porte-monnaie principal s'accompagne toujours d'une validation des jetons par l'intermédiaire financier. Selon un mode de réalisation préférentiel de l'invention, une telle étape de transfert est mise en oeuvre au cours de chaque transaction entre le client et l'intermédiaire financier, de façon à garantir une vérification régulière de la validité des jetons fournis par le ou les marchand(s). Préférentiellement, lorsque ledit client souhaite acheter des jetons audit intermédiaire financier, ledit procédé comprend les étapes suivantes: ledit intermédiaire financier transmet lesdits jetons achetés vers ledit porte-monnaie principal; - ledit porte-monnaie secondaire contenant des jetons, ledit intermédiaire financier vérifie la validité desdits jetons, et, lesdits jetons étant valides, transfert lesdits jetons dudit porte-monnaie secondaire vers ledit porte-monnaie principal. De façon avantageuse, lorsque ledit marchand souhaite que son portemonnaie soit débité de la valeur de N jetons pour les créditer sur son compte bancaire, N étant un nombre entier prédéterminé, ledit procédé comprend les étapes suivantes: - ledit intermédiaire financier vérifie que ledit porte-monnaie dudit marchand contient au moins N jetons; - la vérification étant effectuée, et ledit fichier de consignation contenant M jetons, M étant un nombre entier prédéterminé, ledit intermédiaire financier crédite le compte bancaire dudit marchand de la valeur de (N+M) jetons, vide ledit fichier de consignation, et retire N jetons dudit porte-monnaie dudit marchand. Ainsi, outre l'opération requise par le marchand, I'intermédiaire financier procède systématiquement à une vérification et au vidage du fichier de consignation, ce qui est particulièrement avantageux pour le marchand. De façon préférentielle, lorsque ledit client souhaite que son compte bancaire soit crédité de la valeur d'au moins un jeton contenu dans ledit porte-monnaie principal, et ledit porte-monnaie secondaire contenant au moins un jeton, ledit intermédiaire financier procède à une étape de vérification de la validité dudit au moins un jeton contenu dans ledit porte- monnaie secondaire et, en cas de vérification positive, transfert ledit au moins un jeton dudit porte-monnaie secondaire vers ledit porte-monnaie principal. Ainsi, outre l'opération requise par le client, l'intermédiaire financier vérifie automatiquement le contenu du porte- monnaie secondaire de manière à en transférer le contenu vers le porte- monnaie principal, ce qui est avantageux pour le client. Dans un mode de réalisation avantageux de l'invention, ledit intermédiaire financier, ledit marchand et ledit client détiennent chacun une paire de clefs asymétriques, lesdites clefs permettant de signer lesdites transactions mettant en oeuvre un compte bancaire dudit client et/ou dudit marchand. En effet, les transactions mettant en oeuvre un compte bancaire de l'une des parties traitent d'argent " réel ", et non de monnaie électronique telle que les jetons. Elles nécessitent par conséquent de fortes propriétés de non-répudiation, en cas de conflit entre l'intermédiaire financier et l'une des autres parties, qui sont garanties par l'utilisation d'une cryptographie asymétrique. Avantageusement, un message échangé au cours d'une desdites transactions entre deux parties est authentifié à l'aide d'une clef symétrique dérivée, déterminée à partir d'une clef maîtresse et de l'identité d'au moins l'une desdites deux parties. Ainsi, dans le cas d'une transaction à laquelle participe un client, la clef est dérivée de l'identité du client. Dans le cas o la transaction fait intervenir l'intermédiaire financier et le marchand, la clef est dérivée de l'identité du marchand. De cette façon, il n'est pas nécessaire de stocker de clef maîtresse dans un terminal du client, et seules quelques clefs maîtresses doivent être stockées dans un équipement du marchand. Préférentiellement, chacune desdites transactions est mise en oeuvre à l'aide d'une clef symétrique spécifique, ladite clef spécifique ne pouvant être utilisée que pour l'une des transactions appartenant au groupe comprenant: - ledit intermédiaire financier transmet au moins un jeton vers ledit porte-monnaie principal dudit client; - ledit intermédiaire financier transmet au moins un jeton vers ledit porte- monnaie dudit marchand; - ledit marchand demande le paiement d'un bien et/ou d'un service audit client; - ledit client paye un bien et/ou un service audit marchand; - ledit client présente une preuve d'achat audit marchand; ledit marchand rembourse ledit client; - ledit intermédiaire financier rachète au moins certains des jetons dudit client; - ledit intermédiaire financier rachète au moins certains des jetons dudit marchand. De cette façon, chaque transaction de micropaiement utilisant une clef différente, la sécurité du procédé est fortement accrue: en effet, la compromission d'une seule clef ne compromettra pas l'intégralité du procédé, mais seulement la transaction correspondant à la clef compromise. Selon une technique avantageuse de l'invention, lesdites clefs symétriques détenues par ledit client et/ou ledit marchand ne peuvent être utilisées que pour l'une des opérations suivantes: la production d'une donnée permettant d'authentifier l'origine et I'intégrité d'un message échangé au cours d'une desdites transactions; - la vérification de ladite donnée, de façon à garantir une non-répudiation de ladite donnée. L'utilisation sélective d'une clef pour la production ou la vérification d'une donnée d'authentification (en anglais MAC, 'Message Authentification Code'), qui permet de garantir la non-répudiation de cette donnée, est rendue possible, selon un mode de réalisation préférentiel de l'invention par le stockage des clefs du client (respectivement du marchand) sur une carte à puce du client (respectivement du marchand). L'impossibilité de modifier le code exécutable d'une carte à puce permet de destiner sélectivement une clef à la production ou à la vérification de la donnée d'authentification. Ainsi, tant qu'une clef n'est pas compromise, un MAC ne peut avoir été généré que par une seule carte à puce, empêchant ainsi un client de répudier un paiement par exemple. Si, contrairement à la technique mise en oeuvre selon l'invention, les clefs symétriques pouvaient être utilisées aussi bien pour la génération que pour la vérification des MAC, au moins deux cartes à puce (respectivement une chez le client et une chez le marchand) pourraient avoir généré un MAC donné, ce qui permettrait à un client de réfuter un paiement. L'invention concerne encore un terminal de client, dans un système de gestion de transactions de micropaiement, lesdites transactions mettant en oeuvre des échanges de jetons entre au moins un intermédiaire financier et/ou au moins un marchand de biens et/ou de services et/ou ledit client, ledit terminal comprenant au moins deux zones de stockage de jetons distinctes, correspondant à au moins un porte- monnaie principal et à au moins un porte-monnaie secondaire, ledit portemonnaie principal pouvant comprendre des jetons fournis par ledit au moins un intermédiaire financier audit client, et ledit porte-monnaie secondaire pouvant comprendre des jetons fournis par ledit au moins un marchand audit client. Avantageusement, lesdites deux zones de stockage sont localisées dans un processeur sécurisé contenu dans ledit terminal ou dans un support de données pouvant être lu par ledit terminal. Notamment, un tel support de données peut être une carte à puce, ou tout autre support de données sécurisé. L'invention concerne également un équipement de marchand dans un système de gestion de transactions de micropaiement, lesdites transactions mettant en ceuvre des échanges de jetons entre au moins un intermédiaire financier et/ou au moins un client, et/ou ledit marchand, ledit équipement comprenant au moins deux zones de stockage de jetons distinctes. Préférentiellement, deux desdites zones de stockage sont un porte- monnaie dudit marchand et un fichier de consignation dudit marchand, ledit porte-monnaie dudit marchand pouvant comprendre des jetons foumrnis par ledit intermédiaire financier audit marchand, et ledit fichier de consignation pouvant comprendre des jetons foumrnis par ledit au moins un client audit marchand. D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels: - la figure 1 présente un synoptique des transactions mises en oeuvre selon l'invention, lorsqu'un client souhaite effecteur un achat de bien et/ou de service auprès d'un marchand; - la figure 2 présente un synoptique des transactions mises en oeuvre entre les différents acteurs de la figure 1, lorsqu'un marchand souhaite rembourser un client; - la figure 3 illustre les transactions mises en oeuvre entre les différents acteurs de la figure 1, lorsqu'un client et/ou un marchand souhaite transférer le contenu de son porte-monnaie vers son compte bancaire. Le principe général de l'invention repose sur l'existence de deux zones de stockage de jetons distinctes, pour chaque client d'un système de gestion de transactions de micropaiement. Ces deux zones de stockage correspondent à un porte-monnaie principal du client, contenant des jetons fournis par un intermédiaire financier, et un porte-monnaie 13 l2811451 secondaire, dans lequel le client stocke les jetons qu'il a reçu d'un ou plusieurs marchands, par exemple pour le remboursement d'une marchandise non disponible, ou comme gain d'un jeu auquel le client a participe. À chacun de ces deux porte-monnaie est associée une somme maximale prédéterminee correspondant au nombre maximum de jetons que chacun des porte-monnaie peut contenir. On présente, en relation avec la figure 1, un mode de réalisation d'une transaction de micropaiement d'un client 2 vers un marchand 3, mise en oeuvre, par exemple, par l'intermédiaire du réseau mondial Internet. Pour participer à une transaction de micropaiement, un client 2 utilise un terminal, qui peut par exemple être constitué de deux entités: - une carteà puce, utilisée comme moyen de stockage de données sécurisé, et comme moyen d'authentification du client 2. On peut aussi envisager que cette carte à puce ait d'autres fonctionnalités, telles que la gestion du paiement de chaînes de télévision; - un décodeur numérique multimédia, comprenant un lecteur de carte à puce, et pouvant communiquer avec un marchand 3 et un intermédiaire financier 1. Le client 2 peut aussi mettre en oeuvre une transaction de micropaiement selon l'invention à partir de tout autre type de terminal adapté (intégrant par exemple les moyens de la carte à puce). On notera que le bloc référencé 4 de la figure 1 représente, par souci de simplification, la banque du client 2 et/ou du marchand 3. On peut bien sûr envisager que le marchand 3 et le client 2 soient clients de la même banque 4 ou de banques 4 différentes. Avant tout achat, si son porte-monnaie principal et son porte- monnaie secondaire sont vides, le client 2 doit se procurer des jetons auprès d'un intermédiaire financier 1. Dans ce dessein, le client 2 envoie, au cours d'une étape référencée 12, à l'intermédiaire financier 1, une autorisation de débiter un compte bancaire qui lui est propre dans une banque 4, d'un montant égal à la valeur des jetons qu'il souhaite acquérir. Par exemple, le client 2 signe un chèque électronique à l'intermédiaire financier 1. L'autorisation de paiement transmise par le client 2 donne à l'intermédiaire financier 1 toutes les informations nécessaires pour se faire payer par la banque 4 du client 2. Après avoir été payé par la banque 4, l'intermédiaire financier 1 envoie au client 2, au cours d'une étape référencée 13, les jetons souhaités. Au cours d'étapes non-représentées sur la figure 1, le client 2 sélectionne le bien et/ou le service qu'il souhaite acquérir auprès du marchand 3, remplit un bon de commande et l'envoie au marchand 3. Par exemple, le client 2 remplit un bon de commande accessible depuis le site Web du marchand 3. Le marchand 3 demande alors le paiement du bien et/ou du service au client 2. Pour participer à une transaction de micropaiement selon l'invention, on peut envisager que le marchand 3 dispose d'un équipement comprenant plusieurs entités du type: - une ou plusieurs cartes à puce, et/ou processeurs sécurisés, utilisés comme zones de stockage de données sécurisés, et/ou comme moyens d'authentification du marchand 3, et/ou comme moyens de cryptage de données; - un serveur, capable de traiter les transactions mises en oeuvre simultanément avec plusieurs clients 2. Le client 2 procède alors au micropaiement du bien et/ou du service commandé au cours de l'étape référencée 14. Dans ce dessein, le client 2 envoie au marchand 3 un nombre de jetons correspondant à la valeur du bien et/ou du service acquis, qu'il aura prélevé de son porte-monnaie principal si ce dernier contient suffisamment de jetons. Dans le cas contraire, le client 2 prélève des jetons de son porte-monnaie principal, jusqu'à ce que ce dernier soit vide. Le cas échéant, le client 2 prélève le nombre de jetons manquant de son porte- monnaie secondaire afin de procéder au micropaiement. Après réception du micropaiement, le marchand 3 délivre au client 2 le bien et/ou le service commandé au cours d'une étape référencée 15. Les jetons qu'il a reçus du client 2 sont stockés dans un fichier de consignation. Le marchand 3 peut alors souhaiter qu'un compte bancaire dont il dispose dans une banque 4 soit crédité d'un montant correspondant à la valeur des jetons reçus du client 2. On peut aussi envisager que le marchand 3 conserve les jetons reçus du client 2, jusqu'à disposer d'un nombre de jetons prédéterminé, avant de créditer son compte bancaire de la valeur correspondante. Le marchand 3 présente alors les jetons contenus dans le fichier de consignation, ou une partie de ces jetons, à l'intermédiaire financier 1, au cours d'une étape référencée 16. Le marchand 3 peut aussi présenter, en outre, des jetons contenus dans son porte-monnaie. L'intermédiaire financier 1 vérifie la validité des jetons reçus. Après vérification, au cours d'une étape référencée 11, l'intermédiaire financier 1 envoie à la banque 4 un ordre de virement sur le compte du marchand 3, d'une somme correspondant à la valeur des jetons valides reçus. L'intermédiaire financier 1 transmet également au marchand 3, au cours d'une étape référencée 17, une copie de l'ordre de virement adressé à la banque 4, pour l'assurer que son compte bancaire sera bien crédité. On décrit désormais, en relation avec la figure 2, les transactions mises en oeuvre selon l'invention lorsqu'un marchand 3 souhaite rembourser un client 2, ou lui transmettre un nombre de jetons correspondant, par exemple, au gain du client 2 pour un jeu et/ou une loterie auxquels il a participé chez le marchand 3. Le marchand 3 commence par remplir son porte-monnaie de jetons, qu'il acquière auprès de l'intermédiaire financier 1. En effet, seuls les jetons qu'il achète auprès de l'intermédiaire financier 1 peuvent être utilisés pour rembourser un client 2. Le marchand 3 ne peut pas utiliser d'éventuels jetons qui seraient stockes dans son fichier de consignation pour rembourser le client 2, ce qui présente une sécurité supplémentaire pour le client 2. Dans ce dessein, le marchand 3 envoie, au cours d'une étape référencée 12, une autorisation de paiement à l'intermédiaire financier 1. Cette autorisation fournit à l'intermédiaire financier 1 toutes les informations nécessaires pour demander à la banque 4 du marchand 3 de prélever de l'argent d'un compte bancaire du marchand, au cours d'une étape référencée 11. L'intermédiaire financier 1 envoie alors au marchand 3, au cours d'une étape référencée 13, un nombre de jetons correspondant à la somme qu'il a reçue en paiement, de la banque 4. Ces jetons sont 16 d2811451 stockés, par le marchand 3, dans son porte-monnaie. Par exemple, le porte-monnaie du marchand est contenu dans une carte à puce. Le client 2 fournit une preuve d'achat au marchand 3, au cours d'une étape référencée 21, afin de justifier qu'il doit bien être remboursé, ou afin de présenter, par exemple, le ticket de loterie gagnant dont il dispose. Le marchand 3 peut alors procéder au micropaiement du client 2, au cours d'un étape référencée 14. Il transmet au client 2 un nombre de jetons correspondant à la somme à rembourser, ou à la valeur du gain du client 2. On peut envisager, que préalablement à cette transmission, le marchand 3 vérifie que le nombre de jetons qu'il souhaite transmettre au client 2 est inférieur au nombre maximum de jetons pouvant être stockés dans le porte-monnaie secondaire du client, ou que la somme de ce nombre de jetons et des jetons déjà éventuellement contenus dans le porte-monnaie secondaire du client n'excède pas le nombre maximum de jetons autorisé. Dans le cas contraire, on peut par exemple envisager que le marchand 3 rembourse le client 2 en mettant en oeuvre un procédé de macropaiement ne faisant pas l'objet de la présente invention. On peut aussi envisager que le marchand 3 envoie un message au client 2 lui demandant de vider son porte-monnaie secondaire, afin de pouvoir être remboursé, ou afin d'obtenir son gain. Ces jetons sont stockés dans le porte-monnaie secondaire du client 2, qui peut aussi être contenu dans une carte à puce par exemple. La validité de ces jetons est vérifiée au cours de la première transaction mise en ceuvre, par la suite, entre le client 2 et l'intermédiaire financier 1. Le client 2 présente alors les jetons contenus dans son porte-monnaie secondaire à l'intermédiaire financier 1, au cours d'une étape référencée 16. Après vérification de la validité des jetons, I'intermédiaire financier 1 transmet le nombre de jetons valides au client 2 au cours d'une étape référencée 22. Ces jetons vérifiés sont alors stockés par le client 2 dans son porte-monnaie principal. Selon une variante de réalisation, le client 2 peut préférer qu'un compte bancaire dont il dispose dans une banque 4 soit crédité d'un montant correspondant à la valeur des jetons valides. L'intermédiaire financier envoie alors au cours d'une étape référencée 11 un ordre de virement à la banque 4 du client 2. On peut alors envisager qu'il transmette au client 2 une copie de cet ordre de virement pour l'assurer que son compte bancaire sera bien crédité. La validité des jetons contenus dans le porte-monnaie secondaire du client 2 peut en outre être vérifiée par l'intermédiaire financier 1 au cours de chaque transaction faisant intervenir le client 2 et l'intermédiaire financier 1. On présente en relation avec la figure 3 les transactions mises en oeuvre lorsque le client 2 ou le marchand 3 souhaite que l'intermédiaire financier 1 lui rachète tout ou partie des jetons contenus dans son porte- monnaie. Au cours d'une étape référencée 31, le client 2 ou le marchand 3 transmet à l'intermédiaire financier 1 une demande de rachat d'un nombre N de jetons. Au cours d'une étape référencée 32, I'intermédiaire financier 1 transmet alors au client 2 et/ou au marchand 3 une confirmation de rachat des N jetons. Au cours d'une étape référencée 11, I'intermédiaire financier envoie par ailleurs à la banque 4 du client 2 et/ou du marchand 3 un ordre de virement, de façon à ce que le compte bancaire du client 2 et/ou du marchand 3 soit crédité d'une somme correspondant à la valeur du nombre N de jetons rachetés. Ces N jetons peuvent provenir du porte-monnaie principal et/ou secondaire du client 2, ainsi que du porte-monnaie et/ou du fichier de consignation du marchand 3. Les jetons provenant du porte-monnaie secondaire du client 2 et du fichier de consignation du marchand 3 font l'objet d'une vérification de la part de l'intermédiaire financier 1, qui détermine leur validité avant de créditer les comptes bancaires du client 2 et/ou du marchand 3 d'une somme correspondant à leur valeur. On notera que l'invention facilite la traçabilité des jetons, du fait de l'existence de seulement quatre chemins possibles pour un jeton donné. Une telle traçabilité permet avantageusement d'accroître la sécurité des transactions entreprises entre les différents acteurs, à savoir I'intermédiaire financier 1, et/ou le client 2, et/ou le marchand 3. En effet, chaque jeton est créé par l'intermédiaire financier 1, et retourne à ce dernier en fin de vie, selon l'un des mécanismes suivants: au cours d'une transaction de micropaiement, un jeton est émis par l'intermédiaire financier 1, transmis au client 2, puis au marchand 3, qui le renvoie alors à l'intermédiaire financier 1; - au cours d'un remboursement, un jeton est émis par l'intermédiaire financier 1, transmis au marchand 3, puis au client 2, qui le renvoie alors à l'intermédiaire financier 1; - en cas de rachat du contenu du porte- monnaie du client 2, un jeton créé par l'intermédiaire financier 1, puis stocké dans le porte- monnaie principal du client 2, est renvoyé à l'intermédiaire financier 1; - enfin, un jeton créé par l'intermédiaire financier 1, et stocké dans le porte-monnaie du marchand 3, peut être racheté par l'intermédiaire financier 1. On peut envisager, selon un mode de réalisation préférentiel de l'invention, qu'un audit de jetons soit mis en ceuvre de la manière suivante: - lorsqu'il transmet des jetons à un acteur donné (le client 2 et/ou le marchand 3), I'intermédiaire financier 1 enregistre le nombre total de jetons décerné à cet acteur, et met ce nombre à jour lorsqu'il rachète des jetons à ce dernier; - lorsqu'il vérifie la validité de jetons, I'intermédiaire financier 1 connaît l'identité de l'acteur auquel il a initialement décemé ces jetons. Il enregistre le nombre total de jetons qu'il a vérifiés pour cet acteur; - I'intermédiaire financier 1 compare ce nombre total de jetons vérifiés au nombre total de jetons décernés. Si l'acteur considéré est le marchand 3, le nombre total de jetons vérifiés doit être inférieur au nombre total de jetons décernés. Si l'acteur considéré est le client 2, le nombre total de jetons vérifiés doit être inférieur à la somme du nombre total de jetons décemés et du nombre maximum de jetons pouvant être stocké dans le porte-monnaie secondaire du client 2. Dans le cas contraire, I'invention permet avantageusement de déterminer que des jetons ont été créés par l'acteur considéré (le client 2 et/ou le marchand 3). Selon l'invention, un procédé de cryptographie peut par ailleurs être mis en ceuvre pour sécuriser au moins certains des échanges entre l'intermédiaire financier 1 et/ou le marchand 3 et/ou le client 2. Par exemple, toutes les transactions faisant intervenir un compte bancaire du client 2 et/ou du marchand 3 sont protégées à l'aide d'une cryptographie asymétrique. En effet, de telles transactions mettent en ceuvre de " véritables " sommes d'argent (par opposition à un nombre de jetons), et doivent donc présenter de fortes propriétés de nonrépudiation. Selon un mode de réalisation préférentiel de l'invention, toutes les autres transactions seront protégées par cryptographie symétrique. Pour toutes les transactions illustrées par les figures 1 à 3, mettant en oeuvre un compte bancaire, l'intermédiaire financier 1 et/ou le marchand 3 et/ou le client 2 utilisent une paire de clefs asymétriques dont ils disposent. Pour authentifier un message échangé au cours d'une transaction (ne mettant pas en oeuvre un compte bancaire) entre deux acteurs (l'intermédiaire financier 1 et/ou le client 2 et/ou le marchand 3), on utilise préférentiellement une clef symétrique, dérivée à partir de l'identité de l'un des deux acteurs et d'une clef maîtresse. Par exemple, au cours d'une transaction faisant intervenir le client 2, une clef est dérivée à partir de l'identité de ce dernier. Au cours d'une transaction faisant intervenir le marchand 3 et l'intermédiaire financier 1, une clef est dérivée à partir de l'identité du marchand 3. Selon un mode de réalisation préférentiel de l'invention, chaque clef symétrique est utilisée spécifiquement pour un type de transaction et/ou de vérification prédéterminé, tel que: - le stockage de jetons dans le porte-monnaie principal du client 2 par l'intermédiaire financier 1; - le stockage de jetons dans le porte-monnaie du marchand 3 par I'intermédiaire financier 1; - la demande de paiement du marchand 3 au client 2; - le micropaiement d'un achat au marchand 3 à partir du porte- monnaie principal et/ou secondaire du client 2; - la validation d'une preuve d'achat du client 2; - le remboursement du client 2 par le marchand 3; - le rachat des jetons d'un client 2 par l'intermédiaire financier 1; le rachat des jetons d'un marchand 3 par l'intermédiaire financier 1; etc. Selon un mode de réalisation préférentiel de l'invention, un système de gestion de messages d'erreurs est également mis en ceuvre au cours de toutes les transactions illustrées par les figures 1 à 3. On peut par exemple envisager que des messages d'erreurs soient émis à destination du client 2 et/ou de l'intermédiaire financier 1 et/ou du marchand 3 si une erreur survient au cours d'une transaction, telle que: - une erreur d'authentification des données; - au cours d'un micropaiement, le client 2 ne dispose pas du nombre de jetons suffisant pour payer le marchand 3; la preuve d'achat présentée par le client 2 au marchand 3 n'est pas valide, au cours d'une transaction de remboursement; - au cours d'une validation de jetons par l'intermédiaire financier 1, certains jetons ne sont pas valides; - etc. REVENDICATIONS 1. Système de gestion de transactions de micropaiement comprenant au moins un intermédiaire financier (1), au moins un client (2), et au moins un marchand de biens et/ou de services (3), lesdites transactions mettant en oeuvre des échanges de jetons, caractérisé en ce que chacun desdits clients (2) dispose d'au moins deux zones de stockage de jetons distinctes, au moins une première zone de stockage de jetons correspondant à au moins un porte-monnaie principal et au moins une deuxième zone de stockage de jetons correspondant à un porte-monnaie secondaire, ledit porte-monnaie principal pouvant comprendre des jetons fournis par ledit intermédiaire financier (1) audit client (2), et ledit porte-monnaie secondaire pouvant comprendre des jetons fournis par ledit au moins un marchand (3) audit client (2). 2. Système selon la revendication 1, caractérisé en ce que chacun desdits marchands (3) dispose d'au moins deux zones de stockage de jetons distinctes. 3. Système selon la revendication 2, caractérisé en ce que au moins une première zone de stockage de jetons dudit marchand correspond à un portemonnaie dudit marchand (3) et au moins une deuxième zone de stockage de jetons dudit marchand correspond à un fichier de consignation dudit marchand (3), ledit porte-monnaie dudit marchand (3) pouvant comprendre des jetons fournis par ledit intermédiaire financier (1) audit marchand (3), et ledit fichier de consignation pouvant comprendre des jetons fournis par ledit au moins un client (2) audit marchand (3). 4. Procédé de gestion de transactions de micropaiement dans un système selon la revendication 3, caractérisé en ce qu'au cours du paiement d'un bien et/ou d'un service acquis par ledit client (2) auprès dudit marchand (3), ledit client (2) transmet (14 - Fig. 1) audit marchand (3) un premier nombre P de jetons, correspondant au prix dudit bien et/ou dudit service; - ledit premier nombre P de jetons provenant de la première zone de stockage de jetons dudit client, correspondant à son porte-monnaie principal et susceptible de contenir des jetons fournis par ledit intermédiaire financier (1), si ledit porte-monnaie principal contient une quantité de jetons supérieure ou égale à P; - si ledit porte-monnaie principal contient une quantité de jetons X, inférieure à P, ledit client transmet: - X jetons provenant dudit porte-monnaie principal; et - P - X jetons provenant de la deuxième zone de stockage de jetons dudit client, correspondant à son porte-monnaie secondaire et susceptible de contenir des jetons fournis par ledit marchand (3); et en ce que ledit marchand (3) stocke ledit premier nombre P de jetons transmis dans sa deuxième zone de stockage de jetons, correspondant audit fichier de consignation. 5. Procédé selon la revendication 4, caractérisé en ce que, ledit marchand (3) souhaitant rembourser (14 - Fig. 2) une somme audit client (2), ledit procédé comprend les étapes consistant à: - prélever un second nombre de jetons correspondant à ladite somme, de ladite première zone de stockage dudit marchand (3) correspondant à son porte-monnaie; - vérifier que ledit second nombre, ajouté aux jetons dudit porte- monnaie secondaire dudit client, ne dépasse pas un maximum prédéterminé; ledit maximum n'étant pas dépassé, stocker ledit second nombre dans ledit porte-monnaie secondaire dudit client; sinon: - interrompre ledit procédé, et rembourser ledit client en mettant en ceuvre un procédé de macropaiement; ou - envoyer un message audit client lui demandant de vider son porte- monnaie secondaire afin de pouvoir être remboursé. 6. Procédé selon l'une quelconque des revendications 4 ou 5, caractérisé en ce qu'il comprend en outre une étape de transfert de jetons dudit porte-monnaie secondaire vers ledit porte-monnaie principal, comprenant les sous-étapes suivantes: - ledit client (2) demande audit intermédiaire financier (1) de transférer lesdits jetons contenus dans ledit porte-monnaie secondaire vers ledit porte-monnaie principal; - ledit intermédiaire financier (1) vérifie la validité de ladite demande dudit client (2), d'une part, et desdits jetons contenus dans ledit portemonnaie secondaire, d'autre part; - ladite validité étant vérifiée, ledit intermédiaire financier (1) transfère lesdits jetons dudit porte-monnaie secondaire vers ledit porte- monnaie principal. 7. Procédé selon l'une quelconque des revendications 4 à 6, caractérisé en ce que, ledit client (2) souhaitant acheter des jetons audit intermédiaire financier (1), ledit procédé comprend les étapes suivantes: - ledit intermédiaire financier (1) transmet (13) lesdits jetons achetés vers ledit porte-monnaie principal; - ledit porte-monnaie secondaire contenant des jetons, ledit intermédiaire financier (1) vérifie la validité desdits jetons, et, lesdits jetons étant valides, transfert lesdits jetons dudit porte-monnaie secondaire vers ledit porte-monnaie principal. 8. Procédé selon l'une quelconque des revendications 4 à 7, caractérisé en ce que, ledit marchand (3) souhaitant que son porte- monnaie soit débité de la valeur de N jetons pour les créditer sur son compte bancaire, N étant un nombre entier prédéterminé, ledit procédé comprend les étapes suivantes: - ledit intermédiaire financier (1) vérifie que ledit porte-monnaie dudit marchand (3) contient au moins N jetons; la vérification étant effectuée, et ledit fichier de consignation contenant M jetons, M étant un nombre entier prédéterminé, ledit intermédiaire financier (1) crédite (11) le compte bancaire dudit marchand (3) de la valeur de (N+M) jetons, vide ledit fichier de consignation, et retire N jetons dudit porte-monnaie dudit marchand. 9. Procédé selon l'une quelconque des revendications 4 à 8, caractérisé en ce que, ledit client (2) souhaitant que son compte bancaire soit crédité de la valeur d'au moins un jeton contenu dans ledit porte- monnaie principal, et ledit porte-monnaie secondaire contenant au moins un jeton, ledit intermédiaire financier (1) procède à une étape de vérification de la validité dudit au moins un jeton contenu dans ledit porte- monnaie secondaire et, en cas de vérification positive, transfert ledit au moins un jeton dudit porte-monnaie secondaire vers ledit porte-monnaie principal. 10. Procédé selon l'une quelconque des revendications 4 à 9, caractérisé en ce que ledit intermédiaire financier (1), ledit marchand (3) et ledit client (2) détiennent chacun une paire de clefs asymétriques, lesdites clefs permettant de signer lesdites transactions mettant en oeuvre un compte bancaire dudit client (2) et/ou dudit marchand (3). 11. Procédé selon l'une quelconque des revendications 4 à 10, caractérisé en ce qu'un message échangé au cours d'une desdites transactions entre deux parties est authentifié à l'aide d'une clef symétrique dérivée, déterminée à partir d'une clef maîtresse et de l'identité d'au moins l'une desdites deux parties. 12. Procédé selon l'une quelconque des revendications 4 à 11, caractérisé en ce que chacune desdites transactions met en oeuvre une clef symétrique spécifique, ladite clef spécifique ne pouvant être utilisée que pour l'une des transactions appartenant au groupe comprenant: - ledit intermédiaire financier (1) transmet (13 - Fig. 1, 22 - Fig. 2) au moins un jeton vers ledit porte-monnaie principal dudit client (2); - ledit intermédiaire financier (1) transmet (13 - Fig. 2) au moins un jeton vers ledit porte-monnaie dudit marchand (3); - ledit marchand (3) demande le paiement d'un bien et/ou d'un service audit client (2); - ledit client (2) paye (14 - Fig. 1) un bien et/ou un service audit marchand (3); - ledit client (2) présente une preuve d'achat (21) audit marchand (3); - ledit marchand (3) rembourse (14 - Fig. 2) ledit client (2); - ledit intermédiaire financier (1) rachète au moins certains des jetons dudit client (2); - ledit intermédiaire financier (1) rachète au moins certains des jetons dudit marchand (3). 13. Procédé selon l'une quelconque des revendications 11 et 12, caractérisé en ce que lesdites clefs symétriques détenues par ledit client (2) et/ou ledit marchand (3) ne peuvent être utilisées que pour l'une des opérations suivantes: - la production d'une donnée permettant d'authentifier l'origine et l'intégrité d'un message échangé au cours d'une desdites transactions; - la vérification de ladite donnée, de façon à garantir une non-répudiation de ladite donnée. 14. Terminal de client, dans un système de gestion de transactions de micropaiement, lesdites transactions mettant en oeuvre des échanges de jetons entre au moins un intermédiaire financier (1) et/ou au moins un marchand (3) de biens et/ou de services et/ou ledit client (2), caractérisé en ce qu'il comprend au moins deux zones de stockage de jetons distinctes, correspondant à au moins un porte-monnaie principal et à au moins un porte-monnaie secondaire, ledit porte-monnaie principal pouvant comprendre des jetons fournis par ledit au moins un intermédiaire financier (1) audit client (2), et ledit porte- monnaie secondaire pouvant comprendre des jetons fournis par ledit au moins un marchand (3) audit client (2). 15. Terminal de client selon la revendication 14, caractérisé en ce que lesdites deux zones de stockage sont localisées dans un processeur sécurisé contenu dans ledit terminal ou dans un support de données pouvant être lu par ledit terminal. 16. Équipement de marchand dans un système de gestion de transactions de micropaiement, lesdites transactions mettant en oeuvre des échanges de jetons entre au moins un intermédiaire financier (1) et/ou au moins un client (2), et/ou ledit marchand (3), caractérisé en ce qu'il comprend au moins deux zones de stockage de jetons distinctes. 17. Équipement de marchand selon la revendication 16, caractérisé en ce que deux desdites zones de stockage sont un porte- monnaie dudit marchand (3) et un fichier de consignation dudit marchand (3), ledit porte-monnaie dudit marchand (3) pouvant comprendre des jetons fournis par ledit intermédiaire financier (1) audit marchand (3), et ledit fichier de consignation pouvant comprendre des jetons fournis par ledit au moins un client (2) audit marchand (3).