FR2798028A1 - METHOD AND SYSTEM OF PAYMENT WITH SCRAPING CARDS - Google Patents

Abstract

The invention relates to a method and a system for paying a trading service for goods or services using cards on which there are codes that are covered by one or more blanking-out elements. The code is then transmitted to the trading service and the validity of the code and the credit associated with it are verified. The transaction and the payment are only validated if the code is valid and if the credit associated with the code is sufficient.

Description

 METHOD AND SYSTEM OF PURCHASE AND PAYMENT The invention relates to a method and system for purchasing and paying to <<B> <B> <B> <B> <B> <B> <B> <B> <B> / B> a merchant service.

Payment systems using scratch cards are already known. One of the best-known examples is the non-subscription mobile phone, using a prepaid account that is reloaded with scratch cards.

In this system, the user associated with an identifier that is in the SIM card of his GSM mobile phone. This identifier will be recognized when the user <B> "</ B> reloads <B>" its credit communication, and the credit for that particular identifier will be set <B> to </ B> day in a database. It <B> y </ B> therefore has a very specific system but perfectly suited <B> to </ B> mobile because it uses the resources of the mobile phone.

There are also payment systems for purchasing services or products <B> at </ B> distance, and especially through the Internet. All current systems use an account that is associated with a user, who must identify himself when he wants to debit. This identification is frequently done by means of a password.

In some cases, the account is a bank account, and the user must enter data such as a credit card number and its expiration date validity. This solution is not satisfactory because in the event of hacking the risks involved, are important, and many potential users are reluctant <B> to </ B> transmit this information on the Internet, for security reasons. In other systems intended to limit the risks involved, the user opens a pre-payment account that feeds in some way. The user must 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 significant costs and costs too high when the purchase amounts are low.

It is therefore necessary to find a simple solution to implement for operators and merchants so as to limit costs and thus allow small purchases, and which is also convenient for the user and with limited risks <B> to </ B> times for traders, operators and the user.

This problem is solved according to the invention through a method of buying and paying for goods or services to a merchant service, by means of cards on which are found codes covered by one or means occultation, comprises a step of revealing the code after removal of the occultation means or means and is characterized in that it also comprises steps for transmitting the code to the merchant service or the code management service, checking the validity the code and credit associated with it and validating the sale and payment if the code is valid and the credit associated with the code is sufficient.

According to the invention, this problem is also solved by <B> at </ B> a system <B> of </ B> purchase and payment of goods or services <B> to </ B> a merchant service , by means of cards on which are codes covered by one or more means of occultation, including means for transmitting a code to the merchant service or the code management service, means for verifying the validity of the code transmitted and associated credit means validation wind-e and payment if the transmitted code is valid and credit code is sufficient.

Additional features of refinement of the method and system according to the invention are also described in the following implementation example.

The invention will be better understood from reading the description which follows and from examining the figures which accompany it. These are given only as an indication and in no way limit the invention. The figures show <B> - </ B> figure <B> 1 </ B> a first embodiment of the invention <B> - </ B> figure 2 a second embodiment of the invention <B> - < FIG. 4 A fourth embodiment of the invention FIG. 4 A fifth embodiment of the invention FIG. 4 A fifth embodiment of the invention FIG. method or system of purchase and payment according to the invention uses pre-payment cards on which are located codes that are obscured, for example a surface <B> to </ B> scrape or by a removable cache system or envelope. Such cards are similar to those used for prepaid non-subscription telephony.

A large number of these cards must therefore be offered in many outlets, with a purchase value of small amount, for example fifty, one hundred and two hundred francs or ten, twenty and fifty euros or dollars.

Naturally, the invention is applicable to any monetary system, and the values mentioned above are only by way of non-limiting examples.

The user will get one or more cards in a point of sale, the codes then being hidden. When the user is going to want to buy and pay for a good or service <B> at </ B> distance <B> (11), </ B> the merchant service will ask him for a code (12). The user will display the sample code by scratching the blackout surface, removing the cover or opening the envelope.

The user then transmits only the code by means of the communication device that he uses (12) to reach the merchant service. Thus, with a telephone, he enters at least the code of the telephone keypad and if he is connected on the Internet, he enters the code by means of his computer keyboard.

Figure <B> 1, </ B> the merchant service is also the service management of the co <B>, </ B> of, it is sufficient to check that code is valid <B> (13) </ B> and that the purchase credit to which this code gives entitlement corresponds to the amount of the desired purchase (14) <B>. </ B> If the code is invalid or if the purchase credit is insufficient, the merchant service sends a notification <B> from </ B> failure <B> to </ B> the user <B> (15). </ B> Otherwise, the purchase and payment are validated <B> (16) </ B> and the code is invalidated <B> (17). </ B> Merchant Service can give this information <B> to the </ B> user.

In a first implementation of the invention shown in Figure <B> 1, </ B> the amount of the card corresponds exactly to the amount of the purchase. For example, the amount of one hundred francs associated with certain cards will entitle you to the purchase of an audio CD, or a videotape, <B> or </ B> another meal delivered <B> to </ B> home for two people, and so on. In this case the code is invalidated and it can not be used anymore. This implementation corresponds to a voucher-type application that can be offered.

Figure 2 shows another embodiment of the invention in which the merchant service management service codes and associated credits are distinct. Steps (20) <B> to (27) </ B> are similar to steps <B> 10 to 17 </ B> in Figure <B> 1. </ B> At the step that is added <B> (28), </ B> the merchant service contacts the code and credit management service to see if the code is valid and whether the purchase credit it provides matches the desired amount. The verification of the validity of the code <B> (23) </ B> is done by the management service and not the merchant service.

Credit verification can be done either by the merchant service or by the management department. 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 makes it possible to ensure a better confidentiality of the data.

In the embodiment shown diagrammatically in FIG. 2, as in the diagram shown in FIG. 1, the amount of the purchase must correspond to the associated credit code. On the other hand, in the embodiment represented by Figure <B> 3, </ B> the test step <B> (13) </ B> consists of checking for credit. the code is greater than or equal to M amount of the desired purchase. In step <B> (37), the credit is <B> to </ B> day minus the amount M in the case where the credit is greater than said amount M, or code is invalidated in the case where the credit and the amount M are equal. Steps <B> (30) to (36) </ B> in Figure <B> 3 </ B> are similar to steps (20) <B> to (26) </ B> in Figure 2.

In the exemplary implementation of the invention shown in Figure 4, when the purchase credit associated with the code is insufficient, the merchant service takes into account the code and invites the user <B> to </ B > give one or more additional codes. The credits that are associated with the successive codes are added up until the desired amount M is reached. In case the user does not provide any code while the amount M has not yet been reached, the transaction has failed. Each code gives place to a verification of its validity, and <B> to </ B>. / B> the credit check associated with it. The entry of all codes can be done in a single <B> '</ B> time as shown in Figure 4, 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 <B> at </ B> each entry of a new è-, ode.

In Figures <B> 3 </ B> and 4, the market and management services are distinct. Of course, in cases where the merchant service and the associated code and credit management system are one, the merchant system directly performs the code verification tests (33, 43) and associated credits (34, 44).

In step (47), the management service sets the credits associated with the code or codes used to <B> to </ B> day, checking whether there is still a residual credit will be associated <B> to < The card or the last card whose <B> to </ B> has been entered, residual credit that is equal to the original credit or <B> to </ B> sum of initial credits cards, minus the amount M of the purchase made. We invalidate the codes of all cards whose amounts were used in full.

In all modes of implementation of the invention, the transaction is validated <B> (16, 26, 36, </ B> 46) only when the sum of the credits associated <B> to </ B > one or more cards, whose codes are valid, equal to or greater than 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 its entirety, since nry then has no more confidential data to <B> protect. Nevertheless, these phases of user information are not essential to the implementation of the invention, and can perfectly be realized outside any commercial transaction, by directly contacting the management service of the user. codes and credits associated with them.

Similarly, as shown in Figure 5, the code can be directly requested by the management service, upon request from the merchant service. In this case the merchant service only indicates the amount 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 adapted to the Internet, is that the code transits at the merchant service in a coded or encrypted form. merchant service does not have access to the code itself. These alternatives make it possible to increase the security of a payment system according to the invention in the case where the market and management services are separate, by separating the different tasks. It will be seen that a method or system according to the invention provides two advantages over existing methods and systems. The user does not need to enter a password or create an account. The system simply checks to see if the indicated number matches a card issued, and what credit is associated with that card and the code it carries. Therefore the system is extremely easy to implement, with a reduced running cost, and is particularly suitable for the payment of small amounts.

Since the sums associated with the cards bearing the codes are also small amounts, the risks incurred are very limited. At worst, a hacker could detect a code when it is transmitted over the Internet or by telephone during a transaction, but in this case he will only have access to the residual credit, which does not justify the effort necessary to have Fraudulent access to the code.

The methods and systems according to the invention therefore solve the problems posed by the existing methods and systems, without requiring the opening of user accounts and passwords, with a minimum risk also <U> well </ U> for the merchant system than for the user.

Claims (1)

CLAIMS <B> 1. </ B> Method of purchase and payment of goods or services <B> to </ B> a commercial service, by means of cards on which are found codes covered by one or means of occultation, comprising the following step <B>: </ B> revelation of the code after suppression or means of occultation, characterized in that it also comprises the following steps <B>: </ B> transmission of the code to the merchant service or the code management service, verification of the validity of the code and credit associated with it validation of the sale and payment the valid code and if the credit associated with the code is sufficient 2. Method of purchase and payment .de goods or services <B> to </ B> a merchant service according to claim <B> 1 </ B> characterized in that the transmission of the code is effected by means of a telephone <B> 3. </ B> Method of purchase and payment of goods or services <B> to </ B> a merchant service according to claim <B> 1 </ B> erected in that the transmission code is carried out on the Internet 4. Method purchase and payment of goods or services <B> to </ B> a merchant service according to any one of the preceding claims, characterized in that the means blackout is an opaque surface destined to be scraped off to reveal code <B> 5. </ B> Purchase and payment method of goods or services <B> to </ B> a merchant service according to any one of the preceding claims, characterized in that if the credit associated with the code is insufficient, other codes on other cards are transmitted to the same day and verified, until that the amount of credits associated with these codes is sufficient. <B> 6. </ B> Method of purchase and payment of goods or services <B> to </ B> a merchant service according to any preceding claim, characterized in that it also includes a step of setting <B> to </ B> credit day associated with the code or last code used if more than one code has been used and invalidation of any codes whose associated credits have been used in their entirety. <B> 7. </ B> Method of purchase and payment of goods or services to a merchant service according to any preceding claim, characterized in that it also comprises a step of coding or encryption code before step of transmission. <B> 8. </ B> Purchasing system and payment of goods or services <B> to </ B> a merchant service, by means of cards on which are codes covered by one or more means of occultation , comprising <B>: means for transmitting a code to the merchant service or the code management service, means for verifying the validity of the transmitted code and the credit associated with it, means for validating the sale and payment if the transmitted code is valid and the credit associated with the code is sufficient <B> 9. </ B> Purchasing system and payment of goods or services <B> to </ B> a merchant service according to the claim <B> 8 </ B> characterized in that the means for transmitting the code is a telephone 1O.System for the purchase and payment of goods or services <B> to </ B> a merchant service according to claim < B> 8 </ B> characterized in that the means of transmission of the code is the Internet Il.System of purchase and payment of goods or services <B> to </ B> a service m Archand according to any one of claims 8 to 10, characterized in that the occulting means is an opaque surface intended to be scraped to reveal the code 12. System for the purchase and payment of goods or services <B> to </ B> a merchant service according to any one of claims <B> 8 to 11, </ B> characterized in that also comprises means from <B> to </ B> day credit associated <B> to </ B> a code used and means invalidation codes whose associated credits were used in their entirety. 13.System of purchase and payment of goods or services <B> to </ B> a merchant service according to any one of claims <B> 8 to </ B> 12, characterized in that also comprises coding or encryption means for coding or encrypting the code before transmission by means of transmission.