WO2001015095A1 - Methode et systeme d'achat et de paiement - Google Patents

Methode et systeme d'achat et de paiement Download PDF

Info

Publication number
WO2001015095A1
WO2001015095A1 PCT/FR2000/002353 FR0002353W WO0115095A1 WO 2001015095 A1 WO2001015095 A1 WO 2001015095A1 FR 0002353 W FR0002353 W FR 0002353W WO 0115095 A1 WO0115095 A1 WO 0115095A1
Authority
WO
WIPO (PCT)
Prior art keywords
code
services
paying
purchasing
goods
Prior art date
Application number
PCT/FR2000/002353
Other languages
English (en)
Inventor
Jacques Seneca
Jean-François SCHREIBER
Original Assignee
Gemplus
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gemplus filed Critical Gemplus
Priority to AU70153/00A priority Critical patent/AU7015300A/en
Publication of WO2001015095A1 publication Critical patent/WO2001015095A1/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/28Pre-payment schemes, e.g. "pay before"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/342Cards defining paid or billed services or quantities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/385Payment protocols; Details thereof using an alias or single-use codes
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/02Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices
    • G07F7/025Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices by means, e.g. cards, providing billing information at the time of purchase, e.g. identification of seller or purchaser, quantity of goods delivered or to be delivered

Definitions

  • a method and system for purchasing and paying for a merchant service is provided.
  • the user is associated with an identifier which is in the SIM card of his GSM mobile phone.
  • This identifier will be recognized when the user "recharges” his communication credit, and the credit for this precise identifier will be updated in a database.
  • the account is a bank account, and the user must enter data such as the number of a credit card and its expiration date.
  • This solution is not satisfactory because in the event of computer hacking the risks incurred are significant, and many potential users are reluctant to transmit this information on the Internet, for security reasons.
  • the user opens a prepayment account which he funds in some way. The user must then also identify himself when he wishes to make a purchase, often by means of a password, and a verification of the supply of the account is made. This solution is quite complex which implies high costs and too high costs when the purchase amounts are low.
  • This problem is solved according to the invention thanks to a method of purchasing and paying for goods or services to a merchant service, by means of cards on which there are codes covered by one or more concealment means, comprises a step of revealing the code after suppression of the occultation means, and is characterized in that it also comprises steps of transmitting the code to the merchant service or to the code management service, of verifying the validity of the code and credit associated with it and validation of the sale and payment if the code is valid and if the credit associated with the code is sufficient.
  • this problem is also solved by means of a system for purchasing and paying for goods or services to a merchant service, by means of cards on which there are codes covered by one or more concealment means, comprising: means for transmitting a code to the merchant service or to the code management service, means for verifying the validity of the transmitted code and the credit associated therewith means of validation of the sale and payment if the code transmitted is valid and if the credit associated with the code is sufficient.
  • a method or a system of purchase and payment according to the invention uses prepayment cards on which there are codes which are obscured, for example by a scratch surface or by a removable cover or envelope system .
  • Such cards are similar to those used for prepaid telephony without subscription.
  • a large number of these cards must therefore be offered in numerous points of sale, with a purchase value of small amount, for example fifty, one hundred and two hundred francs or ten, twenty and fifty euros or dollars.
  • the user will obtain one or more cards at a point of sale, the codes then being obscured.
  • the merchant service When the user will want to buy and pay for a good or a service remotely (11), the merchant service will ask him for a code (12). The user will display the code for example by scraping the blackout surface, removing the cover or by opening the envelope.
  • the user then transmits only the code by means of the communication device which he uses (12) to reach the merchant service.
  • the communication device which he uses (12) to reach the merchant service.
  • the merchant service is also the code management service, it suffices to check that the code is valid (13) and that the purchase credit to which this code gives entitlement corresponds to the amount of the desired purchase (14). If the code is invalid or if the purchase credit is insufficient, the merchant service sends a failure notification to the user (15). Otherwise, the purchase and payment are validated (16) and the code is invalidated
  • the merchant service can give this information to
  • the amount of the card corresponds exactly to the amount of the purchase.
  • the amount of one hundred francs associated with certain cards will give entitlement to the purchase of an audio CD, or a video cassette, or a meal delivered to the home for two people, et cetera. In this case the code is invalidated and can no longer be used.
  • This implementation corresponds to a voucher type application that we can offer.
  • FIG. 2 represents another embodiment of the invention in which the merchant service and the service for managing the codes and associated credits are distinct. Steps (20) to (27) are similar to steps 10 to 17 in Figure 1. During the step that is added (28), the merchant service contacts the code and credit management service, to find out if the code is valid and if the purchase credit it provides corresponds to the desired amount. The verification of the validity of the code (23) is therefore carried out by the management service and no longer by the merchant service.
  • Credit verification can be carried out either by the merchant service or by the management service.
  • the management service In the first case the management service must indicate to the merchant service which credit is associated with the code, and in the second case the merchant service must indicate to the management service what is the amount of the purchase.
  • the second case ensures better confidentiality of data.
  • the test step (13) consists in checking whether the credit associated with the code is greater than or equal to the amount M of the desired purchase.
  • step (37) either the credit is updated by being reduced by the amount M in the case where the credit is greater than the amount M, or the code is invalidated in the case where the credit and the amount M are equal.
  • Steps (30) to (36) in Figure 3 are similar to steps (20) to (26) in Figure 2.
  • the merchant service when the purchase credit associated with the code is insufficient, the merchant service takes into account the code and invites the user to give one or more other codes additional. The credits which are associated with the successive codes are added until the desired amount M is reached. If the user no longer provides a code when the amount M is not yet reached, the transaction has failed
  • Each code gives rise to a verification of its validity, and to the verification of the credit associated with it.
  • the entry of all codes can be done at once as shown in Figure 4, the user then sending a list of codes to the merchant service. In this case, the validity test (43) is carried out for all the codes whose associated credit is necessary to reach the amount M.
  • the entry of the codes can also be done iteratively, the validity tests of the code (43 ) and credit (44) being made each time a new code is entered.
  • step (47) the management service updates the credits associated with the code or codes used, by checking whether there is any residual credit which will then be associated with the card or the last of the cards whose code has been indicated, residual credit which is equal to the credit initial or the sum of the initial credit of the cards, minus the amount M of the purchase made.
  • the codes of all cards whose amounts have been used in full are invalidated.
  • the transaction is only validated (16, 26, 36, 46) when the sum of the credits associated with one or more cards, whose code or codes are valid, equal or exceeds the amount of the purchase M.
  • the user can be informed by the merchant service of the residual credit when it is known by the merchant service.
  • the merchant service is always able to inform that a code is invalidated when the credit associated with it has been used in full, since there is no longer any confidential data to protect.
  • these user information phases are not essential for the implementation of the invention, and can perfectly be carried out without any merchant transaction, by directly contacting the service for managing codes and credits which their are associated.
  • the code can be directly requested by the management service, at the request of the merchant service.
  • the merchant service only indicates the amount M of the transaction, and the user transmits the code directly to the management service, without giving it to the merchant service.
  • a last alternative, particularly suitable for the Internet, is that the code passes through the merchant service in an encoded or encrypted form. The merchant service then does not have access to the code itself.
  • the system simply checks whether the number indicated corresponds to a card issued, and what is the credit associated with this card and the code it carries. .Therefore the system is extremely easy to implement, with a reduced operating cost, and is particularly suitable for paying small amounts.
  • the methods and systems according to the invention therefore solve the problems posed by existing methods and systems well, without requiring the opening of user accounts and passwords, with minimum risk both for the merchant system and for the 'user.

Abstract

L'invention concerne une méthode et un système de paiement de biens ou de services à un service marchand au moyen de cartes sur lesquelles se trouvent des codes recouverts par un ou des moyens d'occultation. L'invention prévoit que le code est révélé après suppression du ou des moyens d'occultation, puis que ce code est transmis au service marchand, et que la validité de ce code est vérifiée ainsi que le crédit qui lui est associé. La transaction et le paiement sont validés si le code est valide et si le crédit associé au code est suffisant.

Description

METHODE ET SYSTEME D'ACHAT ET DE PAIEMENT
L'invention concerne une méthode et un système d'achat et de paiement à un service marchand.
Des systèmes de paiement utilisant des cartes à gratter sont déjà connus. Un exemple parmi les plus connus est celui de la téléphonie mobile sans abonnement, utilisant un compte prépayé qui est rechargé au moyen de cartes à gratter.
Dans ce système, l'utilisateur est associé à un identificateur qui se trouve dans la carte SIM de son portable GSM. Cet identificateur va être reconnu lorsque l'utilisateur " recharge " son crédit de communication, et le crédit pour cet identificateur précis va être mis à jour dans une base de donnée. Il y a donc un système très spécifique mais parfaitement adapté à la téléphonie mobile car utilisant les ressources du téléphone mobile.
Il existe également des systèmes de paiement permettant d'acheter des services ou des produits à distance, et en particulier au moyen d'Internet. Tous les systèmes actuels utilisent un compte qui est associé à un utilisateur, lequel doit s'identifier lorsqu'il veut le débiter. Cette identification se fait fréquemment au moyen d'un mot de passe .
Dans certain cas, le compte est un compte bancaire, et l'utilisateur doit entrer des données telles que le numéro d'une carte de crédit et sa date limite de validité. Cette solution n'est pas satisfaisante car en cas de piratage informatique les risques encourus sont importants, et de nombreux utilisateurs potentiels sont réticents à transmettre ces informations sur Internet, pour des raisons de sécurité. Dans d'autres systèmes destinés à limiter les risques encourus, l'utilisateur ouvre un compte de pré paiement qu'il alimente d'une façon quelconque. L'utilisateur doit alors également s'identifier lorsqu'il souhaite faire un achat, souvent au moyen d'un mot de passe, et une vérification de l'approvisionnement du compte est faite. Cette solution est assez complexe ce qui implique des coûts importants et des frais trop élevés lorsque les montants d'achats sont faibles.
Il est donc nécessaire de trouver une solution simple à mettre en œuvre pour les opérateurs et les commerçants de façon à limiter les frais et permettre ainsi des achats de faible montant, et qui soit également pratique pour l'utilisateur et avec des risques limités à la fois pour les commerçants, les opérateurs et l'utilisateur.
Ce problème est résolu selon l'invention grâce à une méthode d' achat et de paiement de biens ou de services à un service marchand, au moyen de cartes sur lesquelles se trouvent des codes recouverts par un ou des moyens d'occultation, comporte une étape de révélation du code après suppression du ou des moyens d'occultation, et est caractérisée en ce qu'elle comporte également des étapes de transmission du code au service marchand ou au service de gestion du code, de vérification de la validité du code et du crédit qui lui est associé et de validation de la vente et du paiement si le code est valide et si le crédit associé au code est suffisant.
Selon l'invention, ce problème est également résolu grâce à un système d'achat et de paiement de biens ou de services à un service marchand, au moyen de cartes sur lesquelles se trouvent des codes recouverts par un ou des moyens d'occultation, comprenant : des moyens de transmission d'un code au service marchand ou au service de gestion du code, des moyens de vérification de la validité du code transmis et du crédit qui lui est associé des moyens de validation de la vente et du paiement si le code transmis est valide et si le crédit associé au code est suffisant .
Des caractéristiques additionnelles de perfectionnement de la méthode et du système selon l'invention sont également décrites dans l'exemple de mise en œuvre qui suit .
L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles-ci ne sont données qu'à titre indicatif et nullement limitatif de l'invention. Les figures montrent :
- figure 1 : un premier mode de mise en œuvre de l' invention figure 2 : un deuxième mode de réalisation de l' invention - figure 3 : un troisième mode de réalisation de l' invention figure 4 : un quatrième mode de réalisation de l' invention figure 5 : un cinquième mode de réalisation de l'invention
Une méthode ou un système d' achat et de paiement selon l'invention utilise des cartes de pré paiement sur lesquelles se trouvent des codes qui sont occultés, par exemple par une surface à gratter ou par un système de cache amovible ou encore d'enveloppe. De telles cartes sont similaires à celles utilisées pour la téléphonie pré payée sans abonnement.
Un grand nombre de ces cartes doit donc être proposé dans de nombreux points de vente, avec une valeur d'achat de faible montant, par exemple cinquante, cent et deux cents francs ou bien dix, vingt et cinquante euros ou dollars .
Naturellement l'invention est applicable à tout système monétaire, et les valeurs citées précédemment ne le sont qu'à titre d'exemples non limitatifs.
L'utilisateur va se procurer une ou plusieurs cartes dans un point de vente, les codes étant alors occultés.
Lorsque l'utilisateur va vouloir acheter et payer un bien ou un service à distance (11), le service marchand va lui demander un code (12). L'utilisateur fera apparaître le code par exemple en grattant la surface occultante, en enlevant le cache ou bien en ouvrant l'enveloppe.
L'utilisateur transmet alors uniquement le code au moyen de l'appareil de communication qu'il utilise (12) pour joindre le service marchand. Ainsi, avec un téléphone, il entre le code au moins du clavier téléphonique et s'il est connecté sur Internet, il entre le code au moyen de son clavier d'ordinateur.
Sur la Figure 1, le service marchand est également le service de gestions des codes, il lui suffit de vérifier que le code est valide (13) et que le crédit d'achat auquel ce code donne droit correspond au montant de l'achat souhaité (14) . Si le code est invalide ou si le crédit d'achat est insuffisant, le service marchand envoie une notification d'échec à l'utilisateur (15). Sinon, l'achat et le paiement sont validés (16) et le code est invalidé
(17) . Le service marchand peut donner ces informations à
1' utilisateur.
Dans une première mise en œuvre de l'invention représentée Figure 1, le montant de la carte correspond exactement au montant de l'achat. Par exemple, le montant de cent francs associé à certaines cartes donnera droit à l'achat d'un CD audio, ou bien d'une cassette vidéo, ou encore d'un repas livré à domicile pour deux personnes, et caetera. Dans ce cas le code est invalidé et il ne pourra plus être utilisé. Cette mise en œuvre correspond à une application de type bons d'achat que l'on peut offrir.
La Figure 2 représente un autre mode de réalisation de l'invention dans lequel le service marchand et le service de gestion des codes et des crédits associés sont distincts. Les étapes (20) à (27) sont similaires aux étapes 10 à 17 de la Figure 1. Lors de l'étape qui est ajoutée (28), le service marchand contacte le service de gestion des codes et des crédits, pour savoir si le code est valide et si le crédit d'achat qu'il procure correspond au montant souhaité. La vérification de la validité du code (23) est donc effectuée par le service de gestion et non plus le service marchand.
La vérification du crédit peut être effectuée soit par le service marchand, soit par le service de gestion. Dans le premier cas le service de gestion doit indiquer au service marchand quel est le crédit associé au code, et dans le second cas le service marchand doit indiquer au service de gestion quel est le montant de l'achat. Le second cas permet d' assurer une meilleure confidentialité des données.
Dans le mode de réalisation schématisé par la Figure 2, comme dans celui schématisé par la Figure 1, le montant de l'achat doit correspondre au crédit associé au code. En revanche, dans le mode de réalisation représenté par la Figure 3, l'étape de test (13) consiste à vérifier si le crédit associé au code est supérieur ou égal au montant M de l'achat souhaité. Lors de l'étape (37), soit le crédit est mis à jour en étant minoré du montant M dans lé cas ou le crédit est supérieur audit montant M, soit le code est invalidé dans le cas ou le crédit et le montant M sont égaux . Les étapes (30) à (36) de la Figure 3 sont similaires aux étapes (20) à (26) de la Figure 2.
Dans l'exemple de mise en œuvre de l'invention représentée par la Figure 4, lorsque le crédit d'achat associé au code est insuffisant, le service marchand prend en compte le code et invite l'utilisateur à donner un ou plusieurs autres codes additionnels. Les crédits qui sont associés aux codes successifs sont additionnés jusqu'à ce que le montant souhaité M soit atteint. Dans le cas où l'utilisateur ne fournirait plus de code alors que le montant M n'est pas encore atteint, la transaction a échoué
(45) .
Chaque code donne lieu à une vérification de sa validité, et à la vérification du crédit qui lui est associé. L'entrée de tous les codes peut se faire en une seule fois tel que représenté sur la Figure 4, l'utilisateur envoyant alors une liste de codes au service marchand. Dans ce cas, le test de validité (43) est effectué pour tous les codes dont le crédit associé est nécessaire pour atteindre le montant M. L'entrée des codes peut également se faire de manière itérative, les tests de validité du code (43) et du crédit (44) étant effectués à chaque entrée d'un nouveau code.
Sur les Figures 3 et 4 , les services marchand et de gestion sont distincts. Bien entendu, dans le cas où le service marchand et le système de gestion des codes et des crédits associés ne font qu'un, le système marchand effectue directement les tests de vérification des codes (33, 43) et des crédits qui leurs sont associés (34, 44).
Lors de l'étape (47), le service de gestion met à jour les crédits associés au code ou aux codes utilisés, en vérifiant s'il reste un crédit résiduel qui sera alors associé à la carte ou à la dernière des cartes dont le code à été indiqué, crédit résiduel qui est égal au crédit initial ou à la somme des crédits initiaux des cartes, minoré du montant M de l'achat effectué. On invalide les codes de toutes les cartes dont les montants ont été utilisés en totalité.
Dans tous les modes de mise en œuvre de l'invention, la transaction n'est validée (16, 26, 36, 46) que lorsque la somme des crédits associés à une ou plusieurs cartes, dont le ou les codes sont valides, égale ou dépasse le montant de l'achat M.
L' utilisateur peut être informé par le service marchand du crédit résiduel lorsque celui-ci est connu par le service marchand. Le service marchand est toujours en mesure d'informer qu'un code est invalidé lorsque le crédit qui lui est associé a été utilisé dans sa totalité, puisqu'il n'y a plus alors de données confidentielles à protéger. Néanmoins ces phases d'information de l'utilisateur ne sont pas indispensables à la mise en œuvre de l'invention, et peuvent parfaitement être réalisées en dehors de toute transaction marchande, en contactant directement le service de gestion des codes et des crédits qui leurs sont associés.
De même, ainsi qu'il est représenté sur la Figure 5, le code peut être directement demandé par le service de gestion, sur requête du service marchand. Dans ce cas le service marchand n' indique que le montant M de la transaction, et l'utilisateur transmet le code directement au service de gestion, sans le donner au service marchand. Une dernière alternative, particulièrement adaptée à l'Internet, est que le code transite chez le service marchand sous une forme codée ou cryptée. Le service marchand n'a alors pas accès au code même. Ces alternatives permettent d'augmenter la sécurité d'un système de paiement selon l'invention dans le cas où les services marchand et de gestion sont distincts, en séparant les différentes tâches . On voit bien qu'une méthode ou un système selon l'invention procure deux avantages par rapport aux méthodes et systèmes existants :
l'utilisateur n'a pas besoin d'entrer de mot de passe ni de créer un compte. Le système vérifie simplement si le numéro indiqué correspond bien à une carte émise, et quel est le crédit associé à cette carte et au code qu'elle porte. .Par conséquent le système est extrêmement facile à mettre en œuvre, avec un coût de fonctionnement réduit, et est particulièrement adapté au paiement de faibles montants .
Comme les sommes associées aux cartes porteuses des codes sont elles aussi de faibles montants, les risques encourus sont très limités. Au pire, un pirate pourrait détecter un code lors de sa transmission sur Internet ou par téléphone lors d'une transaction, mais dans ce cas il n'aura accès qu'au crédit résiduel, ce qui ne justifie pas l'effort nécessaire pour avoir accès frauduleusement au code.
Les méthodes et systèmes selon l'invention résolvent donc bien les problèmes posés par les méthodes et systèmes existants, sans nécessiter d'ouverture de comptes d'utilisateurs et de mots de passe, avec un risque minimum aussi bien pour le système marchand que pour l'utilisateur.

Claims

REVENDICATIONS
1. Méthode d'achat et de paiement de biens ou de services à un service marchand, au moyen de cartes sur lesquelles se trouvent des codes recouverts par un ou des moyens d'occultation, comportant l'étape suivante : révélation du code après suppression du ou des moyens d'occultation, caractérisée en ce qu' elle comporte également les étapes suivantes : transmission du code au service marchand ou au service de gestion du code, vérification de la validité du code et du crédit qui lui est associé validation de la vente et du paiement si le code est valide et si le crédit associé au code est suffisant
2. Méthode d'achat et de paiement de biens ou de services à un service marchand selon la revendication 1 caractérisée en ce que la transmission du code s'effectue au moyen d'un téléphone
3. Méthode d'achat et de paiement de biens ou de services à un service marchand selon la revendication 1 caractérisée en ce que la transmission du code s'effectue sur Internet
4. Méthode d'achat et de paiement de biens ou de services à un service marchand selon l'une quelconque des revendications précédentes, caractérisée en ce que le moyen d' occultation est une surface opaque destinée à être grattée pour faire apparaître le code
Méthode d'achat et de paiement de biens ou de services à un service marchand selon l'une quelconque des revendications précédentes, caractérisée en ce que si le crédit associé au code est insuffisant, d'autres codes se trouvant sur d'autres cartes sont mis à jour, transmis et vérifiés, jusqu'à ce que la somme des crédits associés à ces codes soit suffisante.
6. Méthode d'achat et de paiement de biens ou de services à un service marchand selon l'une quelconque des revendications précédentes, caractérisée en ce qu'elle comporte également une étape de mise à jour du crédit associé au code - ou au dernier code utilisé si plusieurs codes ont été utilisés et d' invalidation de tous les codes dont les crédits associés ont été utilisés dans leur totalité.
7. Méthode d'achat et de paiement de biens ou de services à un service marchand selon l'une quelconque des revendications précédentes, caractérisée en ce qu'elle comporte également une étape de codage ou cryptage du code avant l'étape de transmission.
8. Système d'achat et de paiement de biens ou de services à un service marchand, au moyen de cartes sur lesquelles se trouvent des codes recouverts par un ou des moyens d'occultation, comprenant : - des moyens de transmission d'un code au service marchand ou au service de gestion du code, des moyens de vérification de la validité du code transmis et du crédit qui lui est associé des moyens de validation de la vente et du paiement si le code transmis est valide et si le crédit associé au code est suffisant
9. Système d'achat et de paiement de biens ou de services à un service marchand selon la revendication 8 caractérisé en ce que le moyen de transmission du code est un téléphone
10. Système d'achat et de paiement de biens ou de services à un service marchand selon la revendication 8 caractérisé en ce que le moyen de transmission du code est l' Internet
11. Système d'achat et de paiement de biens ou de services à un service marchand selon l'une quelconque des revendications 8 à 10, caractérisé en ce que le moyen d' occultation est une surface opaque destinée à être grattée pour faire apparaître le code
12. Système d'achat et de paiement de biens ou de services à un service marchand selon l'une quelconque des revendications 8 à 11, caractérisé en ce qu' il comporte également des moyens de mise à jour du crédit associé à un code utilisé et des moyens d' invalidation des codes dont les crédits associés ont été utilisés dans leur totalité .
13. Système d'achat et de paiement de biens ou de services à un service marchand selon l'une quelconque des revendications 8 à 12, caractérisé en ce qu' il comporte également des moyens de codage ou de cryptage pour coder ou crypter le code avant sa transmission par les moyens de transmission.
PCT/FR2000/002353 1999-08-25 2000-08-21 Methode et systeme d'achat et de paiement WO2001015095A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU70153/00A AU7015300A (en) 1999-08-25 2000-08-21 Method and system of purchase and payment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9910893A FR2798028B1 (fr) 1999-08-25 1999-08-25 Methode et systeme de paiement avec cartes a gratter
FR99/10893 1999-08-25

Publications (1)

Publication Number Publication Date
WO2001015095A1 true WO2001015095A1 (fr) 2001-03-01

Family

ID=9549413

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2000/002353 WO2001015095A1 (fr) 1999-08-25 2000-08-21 Methode et systeme d'achat et de paiement

Country Status (3)

Country Link
AU (1) AU7015300A (fr)
FR (1) FR2798028B1 (fr)
WO (1) WO2001015095A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1262898A2 (fr) * 2001-06-02 2002-12-04 Baby Croesus S.A. Système de "Carte Web"
ES2201865A1 (es) * 2001-07-04 2004-03-16 Castaver Asesores, S.L.L. Sistema de tarjetas prepago desechables para transaccion a traves de redes de datos y en concreto internet.

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2812739A1 (fr) * 2000-08-02 2002-02-08 Ride I Procede et systeme permettant aux utilisateurs d'un reseau de communication, notamment du type internet, d'effectuer des paiements securises
FR2823882A1 (fr) * 2001-04-23 2002-10-25 New Access Sa Procede et systeme de validation de paiement
FR2827978A1 (fr) * 2001-07-27 2003-01-31 Daniel Louis Sionis Dispositif de paiement securise pour regler des achats de biens et de services a distance
WO2004066223A1 (fr) * 2002-12-18 2004-08-05 Thierry Baillie Systeme, procede a carte d'acces ou de prepaiement pour internet

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2252270A (en) * 1991-01-30 1992-08-05 Wren Hilton Giles Martin Credit or phone card
WO1995034161A1 (fr) * 1994-06-06 1995-12-14 Call Processing, Inc. Procede et systeme de pre-paiement par cartes
FR2747962A1 (fr) * 1995-12-19 1997-10-31 Ittah Aaron Titre de paiement sur tous les types de reseaux electroniques et en particulier le reseau internet

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2252270A (en) * 1991-01-30 1992-08-05 Wren Hilton Giles Martin Credit or phone card
WO1995034161A1 (fr) * 1994-06-06 1995-12-14 Call Processing, Inc. Procede et systeme de pre-paiement par cartes
FR2747962A1 (fr) * 1995-12-19 1997-10-31 Ittah Aaron Titre de paiement sur tous les types de reseaux electroniques et en particulier le reseau internet

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1262898A2 (fr) * 2001-06-02 2002-12-04 Baby Croesus S.A. Système de "Carte Web"
EP1262898A3 (fr) * 2001-06-02 2004-02-11 Baby Croesus S.A. Système de "Carte Web"
ES2201865A1 (es) * 2001-07-04 2004-03-16 Castaver Asesores, S.L.L. Sistema de tarjetas prepago desechables para transaccion a traves de redes de datos y en concreto internet.

Also Published As

Publication number Publication date
FR2798028B1 (fr) 2001-10-05
AU7015300A (en) 2001-03-19
FR2798028A1 (fr) 2001-03-02

Similar Documents

Publication Publication Date Title
EP0820620B1 (fr) Procede de paiement electronique permettant d'effectuer des transactions liees a l'achat de biens sur un reseau informatique
EP1014317B1 (fr) Procédé de paiement sécurisé
US20010007983A1 (en) Method and system for transaction of electronic money with a mobile communication unit as an electronic wallet
US20030061163A1 (en) Method and apparatus for verification/authorization by credit or debit card owner of use of card concurrently with merchant transaction
EP1873704A1 (fr) Procédé etsystème déterminant si l'origine d'une demande de paiement est une source de réseau de commerce électronique spécifique
US20170161730A1 (en) Payment system based on a global database of invoices
EP2369780B1 (fr) Procédé et système de validation d'une transaction, terminal transactionnel et programme correspondants.
WO2001015095A1 (fr) Methode et systeme d'achat et de paiement
EP1323140B1 (fr) Procede pour fournir des donnees d'identification d'une carte de paiement a un usager
FR3080934A1 (fr) Procede et systeme pour effectuer un echange de donnees securise
FR2750273A1 (fr) Procede de rechargement de cartes prepayees virtuelles
EP4074005A1 (fr) Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication
EP1354288B1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
EP1428183A2 (fr) Procede et systeme permettant de valider, en mettant en oeuvre un objet portable d'un utilisateur, une requete aupres d'une entite
FR2823882A1 (fr) Procede et systeme de validation de paiement
FR2829647A1 (fr) Procede et systeme permettant a un utilisateur d'authentifier une transaction relative a l'acquisition de biens ou de services, au moyen d'un terminal nomade
EP1978479A1 (fr) Cryptogramme dynamique
WO2001073706A1 (fr) Systeme de paiement permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi-public
EP1412925A1 (fr) Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre
FR2815439A1 (fr) Procede pour effectuer une transaction commerciale sur reseau
CA2865268A1 (fr) Systeme et procede permettant de faciliter les prets sur salaire
AU2018101938A4 (en) An Electronic Payment System for Transport
FR2945881A1 (fr) Procede et systeme de transaction de biens et/ou de services au moyen d'un terminal via un reseau de communication
FR2830100A1 (fr) Systeme de paiement securise entre particuliers permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi public
KR20170118661A (ko) 카드도용결제를 차단하는 온/오프라인 금융거래 결제 방법

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP