OA17954A - Method for implementing a transaction via a mobile terminal - Google Patents

Description

The present invention relates to the field of electronic banking.

More specifically, it relates to a method of implementing a transaction by mobile phone.

STATE OF THE ART

Whether by personal vehicle or public transport, getting around requires the payment at regular intervals of small lump sums: in personal vehicles it is most often tolls or 15 parking lots, and in public transport it is necessary. is tickets.

In either case, counters and now automatic kiosks make it possible to complete the transaction and collect these sums.

The automatic terminals are generally automatic machines capable of receiving coins, notes or bank cards.

Alternatively or in addition, the terminals can accept subscription cards (in particular NFC contactless cards) which trigger a payment, for example monthly for an associated user, so as to free the latter from paying each time he takes transportation. This "dematerialized" payment simplifies and speeds up the transaction, which is important in view of the large number of daily users of the means of transport concerned.

There are also known means of payment via mobile terminal of the smartphone type, which allow dematerialized payment while avoiding the need to have a dedicated card. Connected to the internet, these smartphones establish wireless communication with the terminal (or alternatively display a QR code barcode that the terminal can read) so as to authenticate the user and trigger an online payment.

Smartphone payment methods are satisfactory but are not yet accessible to everyone since they require the possession of a recent and expensive mobile terminal. Many users still have a simple GSM type terminal without internet access and with a basic screen. In addition, payment methods by smartphone are not possible if the quality of the network is insufficient, and therefore remain completely impossible in certain regions of the world.

It would therefore be desirable to have a paperless payment method that overcomes the above difficulties and allows paperless payment that is easy, secure, and without technical constraints.

PRESENTATION OF THE INVENTION

The present invention thus relates according to a first aspect to a method of implementing a transaction via a mobile terminal connected to an operator network, characterized in that it comprises steps of:

(a) Sending from the terminal to a server of the operator network of a request containing identification information of the terminal;

(b) Generation by the server of a payment token based on data associated with the terminal stored in a database of the server;

(c) Sound transcription of the token by the server into a sound signal transmitted to the terminal;

(d) Emission of said sound signal by a loudspeaker of the terminal so as to be picked up by sound capture means of payment equipment;

(e) Reverse transcription of the sound signal by a processing module of the equipment into the payment token;

(f) Verification of the token by the processing module, and authorization of the transaction according to the result of the verification.

According to other advantageous and non-limiting characteristics:

• step (b) comprises the time stamp of the token by the server, step (f) comprising comparing said time stamp with the current time;

• step (b) comprises the encryption of the token by the server with a public key of the payment equipment, step (f) comprising the prior decryption of the token by the processing module with a private key of the payment equipment;

• step (b) further comprises encryption of the token by the server with a private key of the operator, step (f) comprising the prior decryption of the token by the processing module with a public key of the operator;

• step (b) comprises the prefixing of the encrypted token with an identifier of the operator, step (f) comprising the extraction of said identifier of the operator by the processing module so as to choose the public key for decryption of the token;

• said terminal identification information includes a terminal telephone number;

• step (a) consists of dialing a server telephone number so as to establish telephone communication between the terminal and the server;

• step (b) is implemented after pressing a predetermined key on the terminal (1) during said telephone conversation;

• the data associated with the terminal stored in the server database are representative of a counter of remaining tokens, step (b) being implemented only if said counter has a non-zero value, step (b) comprising, where appropriate, the decrement of said counter;

• step (f) comprises comparing the token with a list of expired tokens, the method comprising a step (g) of adding said verified token to said list of expired tokens;

• the equipment is connected to the server via the Internet network, the method comprising a step (h) of issuing a transaction report to the server;

• step (f) includes the activation of a mechanical element of the equipment if the transaction is authorized;

• the mechanical element is chosen from a mobile barrier and a printer.

According to a second aspect, the invention relates to payment equipment, comprising a data processing module and sound capture means, characterized in that the data processing module is configured to implement, following the initiation of a transaction from a mobile terminal including a loudspeaker:

- A module for receiving a sound transcription of a payment token associated with the terminal into a sound signal emitted by the speaker and picked up by the sound capture means;

- A module for the reverse transcription of the sound signal into the payment token;

- A token verification module, and transaction authorization based on the result of the verification.

According to a third aspect, the invention relates to a transaction implementation system comprising at least one payment equipment according to the second aspect of the invention and at least one server of the operator network, the server being configured to generate a token of payment, on request containing identification information of a terminal, as a function of data associated with the terminal stored in a database of the server, and implementing a sound transcription of the token into a sound signal transmitted to the terminal.

According to a fourth and a fifth aspect, the invention relates to a computer program product comprising code instructions for the execution of a method according to the first aspect of the invention of implementing a transaction via a terminal mobile; and computer equipment readable storage means on which a computer program product includes code instructions for performing a method according to the first aspect of implementing a transaction via a mobile terminal.

PRESENTATION OF FIGURES

Other characteristics and advantages of the present invention will become apparent on reading the following description of a preferred embodiment. This description will be given with reference to the accompanying drawings in which:

- Figure 1 is a diagram of a network architecture for implementing the method according to the invention;

- Figure 2 illustrates the credit of a payment token counter by a user;

- Figure 3 shows the implementation of a preferred embodiment of the method according to the invention;

- Figure 4 illustrates a final step of a preferred embodiment of the method according to the invention.

DETAILED DESCRIPTION

Architecture

With reference to the drawings and in particular to FIG. 1, the invention relates to a method of implementing a transaction via a mobile terminal 1 connected to an operator network 21. The operator network 21 can be any network of mobile telephony, in particular an old generation (2G) network of the GSM (“Global System for Mobile Communications”) or EDGE (“Enhanced Data Rates for GSM Evolution”) type, even if it is quite possible that this or a more recent and more powerful network of the 3G or 4G type. The operator network 21 includes at least one server 2 of the mobile telephone operator and is connected to the internet network 20.

It will be understood that there may be several networks 21 of various operators, each having its own server 2, so as to allow the implementation of the method regardless of the user's operator.

Similarly to the operator network 21, the mobile terminal 1 can be any terminal capable of connecting to the network 21, including old portable telephones that do not have complex functionalities (as opposed to smartphones) or partially broken terminals. . In particular, it is sufficient for the terminal 1 to allow a telephone conversation (and therefore for it to include a loudspeaker 10) for the present method to be able to be implemented, and it is for example not necessary for it to have an internet connection, Wi-Fi connectivity, or even a screen.

The present method aims to allow a transaction between the user of the terminal 1 and a payment device 3. The term “transaction” means transmission of sufficient information to electronically prove a payment on the part of the user, so as to unblock a payment. service at the level of the equipment 3. In particular, the latter comprises a mechanical element 32, which is activated when the transaction is authorized. The equipment 3 can thus be for example a POS type payment terminal (the mechanical element 32 is then a printer which prints a receipt), a validator (the mechanical element 32 is a mobile barrier preventing entry to non-users. -authorized), etc. By validator is meant a device making it possible to verify that a user has paid for access to a service (parking, cinema, library, park, etc.), in particular a mode of transport (metro gantry, toll booth, etc.) . In the remainder of the present description, the example of the toll will be taken, element 32 thus being the toll barrier which opens when the user has paid for his access.

In all cases, it is sufficient for the present equipment 3 to include a data processing module 30 such as a processor, possibly a data storage module such as a memory (example of a hard disk), and means sound capture 31.

The sound pickup means 31 consist at least of a microphone capable of acquiring sound, possibly placed in a suitable enclosure to promote sound reception (in terms of intensity and clarity).

The system further comprises a server 2 of the operator network 21 (capable of communicating with the terminal 1), the server being advantageously also connected to the internet network 20. The server 2 is here the main element in the implementation of the transaction. . It comprises data processing means such as a processor and data storage means such as a memory. The server 2 thus stores a database relating to the subscribers of the operator, each user being identified via his terminal 1 (in particular the telephone number of this terminal, but alternatively a MAC address, IMEI, etc.). These data make it possible to determine whether the terminal user has the right to carry out the transaction. They can be representative of a balance in a currency, or a counter of "remaining tokens", also called "tickets".

The tickets represent a prepaid voucher for the transaction. They are particularly useful if Terminal 1 is used to repeatedly implement a constant price transaction, such as paying for tolls or accessing public transport. A ticket is consumed (in the form of a token, which will be described later) each time the transaction is required to be implemented.

Referring to Figure 2, tickets can be acquired prior to the implementation of the present method, in a variety of ways. For example, he can buy tickets on the Internet from a computer, from his phone by dialing an operator's number (tickets are then billed with his telephone subscription bill), in the store via prepaid cards (a scratching reveals a code, entered on the phone), etc.

Each of the above actions increments its remaining token counter (or credits its balance by a predetermined amount if the data is in this form) at the operator's server 2.

Implementation of the process

With reference to FIG. 3, the present method begins with a step (a) for sending from the terminal 1 to a server 2 of the operator network 21 of a request containing identification information for the terminal 1. As explained, these are typically the telephone number of terminal 1, but other possibilities exist (MAC address, IMEI, etc.).

The request can take a plurality of forms, but preferably it consists of a telephone call to a telephone number of the server 2. Mention will also be made of the sending of an SMS (“Short Message Service”) type message to a. such server phone number 2.

These two techniques work for any type of operator network 21 and terminal 1, including the older ones, and automatically convey the telephone number of terminal 1.

In the remainder of this description, we will take the example of the call. Thus, at the end of step (a), a telephone communication between terminal 1 and server 2 is established.

Then follows a second step (b) of generation by the server 2 of a payment token based on data associated with the terminal 1 stored in a database of the server 2.

It should be noted that this step (b) can be triggered following the pressing of a predetermined key of the terminal 1 during said telephone conversation. In particular as seen in Figure 3, the server 2 can respond to the terminal 1 (for example via a pre-recorded voice message) by indicating a key to press to continue the process. This has many advantages: it makes it possible to acknowledge receipt of the transaction request, to establish an additional validation (the user may have dialed the number by mistake. If he does not press the key, the process will never be continued), and to allow the user to choose precisely when to trigger step (b). We will see why a little later.

By "token" is meant a secure computer element representative of a ticket, i.e. a unique code understandable from the equipment 3 as proof of the user's ability to implement the transaction. More precisely, the token is generated only if said data associated with the terminal 1 stored in a database is representative of a sufficient balance or of a counter of tokens remaining non-zero. Said data is then modified, for example by decrementing the counter. Alternatively, in the case of a subscription where the user can use the equipment 3 at will, for example a metro card or a toll badge, it is sufficient that the data is representative of the possession of this subscription (the data are not modified following the generation of the token in this case).

Such a generation is known to those skilled in the art. It will be understood that it includes, for example, the generation of a unique code (and possibly its timestamp, i.e. the addition of a code representative of the generation time), and its encryption for security reasons.

In particular, step (b) can comprise a first encryption of the token by the server 2 with a public key of the payment equipment 3, and / or a second encryption of the token by the server 2 with a private key of the 'operator. In the case of this second encryption, it is desirable to prefix the encrypted token with an operator identifier to allow its subsequent decryption (we will see how below).

At this stage, the method comprises a step (c) of sound transcription of the token (encrypted) by the server 2 into a sound signal transmitted to the terminal 1. In other words, the server 2 will convert the binary data of the token into a signal representative of a sound, for example using the vocal frequencies (Code DTMF, “dual-tone multi-frequency”, which associates with each hexadecimal character (ie each group of four bits) a pair of audible frequencies which are played simultaneously). These frequencies can be recognized by electronic devices and are commonly used to make voice servers.

This sound signal can then be emitted in a step (d) by a loudspeaker 10 of the terminal 1 so as to be picked up by the sound capture means 31 of the payment equipment 3. It suffices for example that the user holds out his phone at the toll booth. This use of sound makes it possible to implement the method with any terminal having only the "telephone" function. No NFC function, internet, high definition screen, etc. is required. Likewise, it suffices for the network 21 to be basic (and allow voice). It will be understood that it is also possible, for efficiency issues, if the network 21 allows internet data, to transmit the sound signal in the form of a sound file, for example of mp3 type.

This sound technique is known, for example application WO2011 / 010052 which uses it in another context (opening a lock).

The subsequent step (e) consists of the reverse transcription of the sound signal by a processing module 30 of the equipment 3 into the payment token, for example by frequency recognition.

The token is then verified, that is to say processed for the final validity, by the processing module 30 in step (f). For this, it is decrypted if necessary.

The extraction of the operator identifier (which has been prefixed) makes it possible to choose a public key of the operator (among a plurality of public keys associated with various operators) for a first decryption of the token with this public key operator (this first decryption is the reverse operation of the second encryption with the private key of the operator).

Then, a second decryption is implemented with a private key of device 3 (this second decryption is the reverse of the first encryption with the public key of device 3). This is the best means of security here because this private key of equipment 3 cannot be known by a third party who would intercept the token and would attempt to use it fraudulently.

Once the token is completely decrypted, its code is verified, for example using an algorithm verifying a mathematical property. Preferably, the token is "self-supporting", that is to say it contains all the information necessary for its validation. Alternatively or in addition, the token can be compared with a list of expired tokens, i.e. already used (and must be absent for its validity to be confirmed).

If the token has been time stamped, step (f) also includes comparing the time stamp with the current time. Indeed, it is desirable to define an expiration period of the generated and played tokens (for example one minute), so as to prevent even more fraudulent use of the tokens (case of someone who would record the sound played to replay it. later). This embodiment makes it very useful that step (b) is conditioned on pressing a key. This makes it possible to generate the token only when the user is ready and in position (terminal 1 oriented towards the capture means 31), so as to allow the shortest possible window of validity for the token.

If the token is verified, then the transaction is authorized. This leads, where appropriate, to a reaction from the equipment 3, in particular an actuation of the element 32. In the case of a toll, the mobile toll barrier is raised and the user can move forward. A ticket can also be printed.

If the data processing module 30 uses a list of expired tokens, then the method comprises a step (g) of adding said verified token to said list of expired tokens. Note that the data processing module 30 can alternatively use a list of authorized tokens: during the verification, the module 30 verifies that the token is compliant and that it is indeed present in this list, step (g) then consists in deleting said verified token from the list of authorized tokens.

Billing and management of tokens used

At this point, the payment equipment 3 has authorized the transaction, but the actual payment has not yet been made. Indeed, it is the network operator 21 who received the payment, and the latter must manage a transfer to the owner of the equipment 3.

For this, the method advantageously comprises a step (h), illustrated by FIG. 4, of sending a transaction report to the server 2. This is possible if the equipment 3 is connected to the server 2 via the internet network 20.

This step (h) is not necessarily in the wake of the rest of the method, and can for example be implemented periodically, for example every evening, so as to transmit all of the transaction reports of the day.

This step has two objectives: to indicate to server 2 which tokens have actually been consumed (server 2 advantageously maintains its own list of authorized tokens, and the tokens actually consumed will be deleted from it), and to invoice the telephone operator so as to obtain the payment of transactions conducted.

Platform and system

According to a second aspect, the invention relates in particular to the payment equipment 3 used for the implementation of the present method.

As explained above, the payment equipment 3 comprises a data processing module 30 and sound capture means 31 (and where appropriate a mechanical element 32). Its data processing module 30 is configured to implement, following the initiation of a transaction from a mobile terminal 1 comprising a speaker 10:

- A module for receiving a sound transcription of a payment token associated with the terminal 1 into a sound signal emitted by the speaker 30 and picked up by the sound capture means 31;

- A module for the reverse transcription of the sound signal into the payment token;

- A token verification module (including, if applicable, the decryption of the token), and authorization of the transaction according to the result of the verification.

According to a third aspect, the transaction implementation system is proposed. It comprises at least one payment device 3 as described, and at least one server 2 of the operator network 21.

As explained, the server 2 is configured to generate a payment token, on request containing identification information of a terminal 1, as a function of data associated with the terminal 1 stored in a database of the server 2, and put in implements a sound transcription of the token into a sound signal transmitted to terminal 1.

The system can also include the terminal (s) 1.

Computer program product

According to a fourth and a fifth aspects, the invention relates to a computer program product comprising code instructions for execution (on processing means in particular of the server 2, but also of the equipment 3, ie the module 30) of a method for implementing a transaction via a mobile terminal 1 according to the first aspect of the invention, as well as storage means readable by computer equipment (for example a memory of the equipment 3 ) on which this computer program product is found.

Claims (15)

1. A method of implementing a transaction via a mobile terminal (1) connected to an operator network (21), characterized in that it comprises the steps of: (a) Sending from the terminal (1) to a server (2) of the operator network (21) of a request containing identification information of the terminal (1) consisting of the dialing of a telephone number the server (2) so as to establish a telephone communication between the terminal (1) and the server (2), said identification information of the terminal (1) comprising a telephone number of the terminal (1); (b) Generation by the server (2) of a payment token based on data associated with the terminal (1) stored in a database of the server (2); (c) Sound transcription of the token by the server (2) into a sound signal transmitted to the terminal (1); (d) Emission of said sound signal by a loudspeaker (10) of the terminal (1) so as to be picked up by sound capture means (31) of a payment equipment (3); (e) Reverse transcription of the sound signal by a processing module (30) of the equipment (3) into the payment token; (f) Verification of the token by the processing module (30), and authorization of the transaction according to the result of the verification. 2. The method of claim 1, wherein step (b) comprises the time stamp of the token by the server (2), step (f) comprising comparing said time stamp with the current time. 3. Method according to one of claims 1 and 2, wherein step (b) comprises the encryption of the token by the server (2) with a public key of the payment equipment (3), step ( f) comprising the prior decryption of the token by the processing module (30) with a private key of the payment equipment (3). 4. The method of claim 3, wherein step (b) further comprises encryption of the token by the server (2) with a private key of the operator, step (f) comprising the prior decryption of the token. by the processing module (30) with a public key of the operator. 5. The method of claim 4, wherein step (b) comprises prefixing the encrypted token with an identifier of the operator, step (f) comprising the extraction of said identifier of the operator by the module. processing (30) so as to choose the public key for decryption of the token. 6. Method according to one of claims 1 to 5, wherein step (b) is implemented after pressing a predetermined key of the terminal (1) during said telephone conversation. 7. Method according to one of claims 1 to 6, wherein the data associated with the terminal (1) stored in the database of the server (2) are representative of a counter of remaining tokens, step (b) being implemented only if said counter has a non-zero value, step (b) optionally comprising the decrement of said counter. 8. Method according to one of claims 1 to 7, wherein step (f) comprises comparing the token with a list of expired tokens, the method comprising a step (g) of adding said verified token to said list. of expired tokens. 9. Method according to one of claims 1 to 8, wherein the equipment (3) is connected to the server (2) via the internet network (20), the method comprising a step (h) of sending a transaction report to the server (2) 10. Method according to one of claims 1 to 9, wherein step (f) comprises the activation of a mechanical element (32) of the equipment (3) if the transaction is authorized. 11. The method of claim 10, wherein the mechanical element (32) is selected from a movable barrier and a printer. 12. Transaction implementation system comprising at least one payment device (3) comprising a data processing module (30) and sound pickup means (31), characterized in that the data processing module ( 30) is configured to implement, following the initiation of a transaction from a mobile terminal (1) comprising a loudspeaker (10): - A module for receiving a sound transcription of a payment token associated with the terminal (1) into a sound signal emitted by the speaker (30) and picked up by the sound capture means (31); - A module for the reverse transcription of the sound signal into the payment token; - A token verification module, and transaction authorization depending on the result of the verification; and at least one server (2) of the operator network (21), the server (2) being configured to generate a payment token, upon request consisting in the composition of a telephone number of the server (2) so as to establish a telephone communication between the terminal (1) and the server (2) and containing identification information of a terminal (1) comprising a telephone number of the terminal (1), according to data associated with the terminal (1) stored in a database of the server (2), and implement a sound transcription of the token into a sound signal transmitted to the terminal (1). 13. Computer program product comprising program code instructions for executing the steps of the method of implementing a transaction via a mobile terminal (1) according to one of claims 1 to 11 when said program is. executed on a 10 computer .. 14. A storage medium readable by computer equipment on which a computer program product includes code instructions for the execution of a method of implementing a 15 transaction via a mobile terminal (1) according to one of claims 1 to 11.